1 / 45

SOFTWARE PROCESS

SOFTWARE PROCESS. Overview. Software process phases Improving the software process. Software Process. Software process is the way software is produced

odette-hardy
Télécharger la présentation

SOFTWARE PROCESS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOFTWARE PROCESS

  2. Overview • Software process phases • Improving the software process

  3. Software Process • Software process is the way software is produced • When you build a product, it is important to go through a series of predictable steps, a roadmap that helps you create a high quality product, timely • The process depends on the software product –the process appropriate for an avionics system is entirely different for the process appropriate for creation of a Web site • “A process defines who is doing what, when, and how to reach a certain goal.” Ivar Jacobson, Grady Booch and James Rumbaugh

  4. Software Process vs. Software Engineering • Software process is the approach that is taken as software is engineered • Software engineering also encompasses technologies that populate the process –technical methods and automated tools • Methods provide the technical HOW TO for building software • Tools provide automated or semi-automated support for the process and the methods • Software process is the glue

  5. Client, Developer, and User • Client – individual or organization that wants a product to be developed • Developers – member of the organization responsible for building that product • Users – persons on whose behalf the client has commissioned the product and who will utilize the software

  6. Client, Developer, and User (contd.) • Software development - all the aspects of software production before the maintenance phase • Internal software development – both the client and developers are the part of the same organization • Contract software – the client and developers are totally independent organizations • Custom software versus Components-off-the-shelf(COTS)

  7. Software Process Phases • Requirements phase • Specification phase • Design phase • Implementation phase • Integration phase (in parallel with 4) • Maintenance phase • Retirement Testing and documentation are activities that take place through all phases

  8. Requirements Phase • Software being considered is economically justifiable • Concept exploration • Determine what the client needs • Determine what constraints exist • Deadline • Cost • Reliability, Availability, Safety, Security, Performance • Moving target problem

  9. Requirements Phase (contd.) • Rapid prototyping • Software that incorporates much of the functionality of the target product but omits aspects invisible to the client (e.g. file updating or exception handling) • Client and users experiment with the prototype to determine whether it meets their needs • Requirements document • Checked by the client, selected users, and the development team

  10. Software Process Phases • Requirements phase • Specification phase • Design phase • Implementation phase • Integration phase (in parallel with 4) • Maintenance phase • Retirement Testing and documentation are activities that take place through all phases

  11. Specification Phase • Specifications document (or specifications) • Exactly describes the functionality of the product • Lists any constraints that the product have • Includes the inputs to the product and the required outputs • Legal document • Must not have phrases like “suitable”, “optimal,” or “98% complete”

  12. Specification Phase (contd.) • Specifications must not be • Ambiguous • Incomplete • Contradictory • Once the specifications are complete, detailed planning and estimating commences • How long it will take • How much it will cost

  13. Specification Phase (contd.) • Software project management plan (SPMP) is drawn up that reflects the separate phases of the development process and shows which members are involved in each task, as well as the deadlines for completing each task • Major components of the SPMP • Deliverables – what the client is going to get • Milestones – when the client gets them • Budget – how much it will cost

  14. Specification Phase (contd.) • SPMP includes • Life-cycle model to be used • Organizational structure • Project responsibilities • Managerial objectives and priorities • CASE tools to be used • Detailed schedules • Budgets • Resource allocations

  15. Specification Phase (contd.) • Software Quality Assurance (SQA) group must check the specifications carefully • Look for contradictions, ambiguities, and incompleteness • Ensure that the specifications are feasible • Trace every statement of the specification back to the requirements document and rapid prototype • Check by review (walkthroughs and inspections) – SQA, specification team, and client • SQA group must also check the SPMP • Documentation - specification document and SPMP

  16. Software Process Phases • Requirements phase • Specification phase • Design phase • Implementation phase • Integration phase (in parallel with 4) • Maintenance phase • Retirement Testing and documentation are activities that take place through all phases

  17. Design Phase • Specification — what? • Design — how? • Architectural design • Decompose the product into modules (independent pieces of code with well defined interfaces to the rest of the product) • Detailed design • Design each module: data structures, algorithms

  18. Design Phase (contd.) • Retain design decisions • When a dead-end is reached – backtrack & redesign • For the maintenance team • Ideally, the design should be open-ended – allows adding new modules or replacing existing modules

  19. Design Phase (contd.) • SQA group must check the design • Look for logic faults, interface faults, lack of exception handling, nonconformance to the specification • Trace every part of the design to a statement in specification document • Review –SQA and design team • Documentation • architecture design • detailed design

  20. Software Process Phases • Requirements phase • Specification phase • Design phase • Implementation phase • Integration phase (in parallel with 4) • Maintenance phase • Retirement Testing and documentation are activities that take place through all phases

  21. Implementation Phase • Implement the detailed design in code • Testing • Code review • Running test cases • Informal testing done by the programmer (desk checking) • Testing by SQA group • Documentation • Source code with suitable comments • Test cases against which the code was tested

  22. Software Process Phases • Requirements phase • Specification phase • Design phase • Implementation phase • Integration phase (in parallel with 4) • Maintenance phase • Retirement Testing and documentation are activities that take place through all phases

  23. Integration Phase • Integrate the modules –performed in parallel with implementation • Integration testing • Testing module interfaces • Product testing – SQA group • Correctness • Robustness • Acceptance testing - client

  24. Integration Phase (contd.) • Once the product testing is complete, the software is supplied to selected possible future users for testing on site – alpha version • Corrected alpha version is called beta version • Documentation • Commented source code • Test cases for the product as a whole • User manual, operator manual, database manual

  25. Software Process Phases • Requirements phase • Specification phase • Design phase • Implementation phase • Integration phase (in parallel with 4) • Maintenance phase • Retirement Testing and documentation are activities that take place through all phases

  26. Maintenance Phase • Maintenance - any change once the client has accepted the software • Entire software development should be carried out in such a way as to minimize the future maintenance • Common problem – not updated documentation or lack of documentation

  27. Maintenance Phase (contd.) • Regression testing – the product must be tested against previous test cases to make certain that the functionality of the rest of the product has not been compromised • Documentation • Record of all the changes made, together with reasons • Regression test cases

  28. Software Process Phases • Requirements phase • Specification phase • Design phase • Implementation phase • Integration phase (in parallel with 4) • Maintenance phase • Retirement Testing and documentation are activities that take place through all phases

  29. Retirement • Software becomes un-maintainable because • A drastic change in design is proposed • The product must be implemented on a totally new hardware/operating system • Documentation is missing or inaccurate • It may be cheaper to rewrite the software from scratch than to modify it

  30. Overview • Software process phases • Improving software process

  31. Improving Software Process • Software Engineering Institute (www.sei.cmu.edu) • Carnegie Mellon University in Pittsburgh • Capability maturity model (CMM) http://www.sei.cmu.edu/cmmi/ • International Standards Organization • ISO 9000 • ISO/IEC 15504 - standard on software process assessment http://www.sei.cmu.edu/cmmi/faq/15504-faq.html • Comparison of ISO 9001 and CMM http://www.sei.cmu.edu/publications/documents/94.reports/94.tr.012.html

  32. Capability Maturity Model • Improvement of software process, irrespective of the life-cycle model • SW–CMM for software • P–CMM for human resources (“people”) • SE–CMM for systems engineering • IPD–CMM for integrated product development • SA–for software acquisition • These strategies are being unified into CMMI (capability maturity model integration)

  33. SW–CMM • Improving software process, 1986 • Fundamental ideas: • Improving the software process leads to • Improved software quality • Delivery on time, within budget • Improved management leads to • Improved techniques • Incremental improvements • Five levels of maturity are defined • Organization advances stepwise from level to level

  34. Maturity level 1 -Initial Level • Ad hoc (occasionally even chaotic) approach • Depends totally on the current stuff • Entire process is unpredictable • Management consists of responses to crises • Unfortunately, most organizations world-wide are at level 1

  35. Maturity level 2 -Repeatable Level • Basic project management is established to track cost, schedule, and functionality • Planning and management based on previous experience with similar products • Measurements are made • Tracking of costs and schedules • These can be used for • Detecting problems and taking immediate corrective action • Making cost and duration predictions in future project

  36. Maturity level 3 -Defined Level • Software process for both management and engineering activities is fully documented and standardized • Managerial and technical aspects are clearly defined • Continual efforts are made to improve quality & productivity • Reviews are used to improve software quality • CASE environments are applicable (not at levels 1 or 2) • A number of organizations have achieved maturity levels 2 and 3, but few have reached levels 4 and 5

  37. Maturity level 4 -Managed Level • Detailed measures of both software product and process quality are collected • Quality and productivity are continually monitored • Statistical quality controls are in place

  38. Maturity level 5 -Optimizing Level • Continuous process improvement • Statistical quality and process controls • Knowledge gained from each project is utilized in future projects

  39. Summary of SW-CMM • For each maturity level there are key process areas (KPA) • Within each KPA are between two and four related goals

  40. Experience with SW-CMM • It takes • 3 to 5 years to get from level 1 to level 2 • 1.5 to 3 years from level 2 to level 3 • SEI questionnaires highlight shortcomings, suggest ways to improve the process • Original idea -Defense contracts would be awarded only to capable firms (level 3)

  41. Other Initiatives • ISO 9000 – series of standards applicable to wide variety of industrial activities, including design, development, production, installation, and servicing • ISO/IEC 15504 – international standard on software process assessment

  42. ISO 9000 series • Adopted by over 60 countries • Set of five standards for industrial activities • ISO 9001 for quality systems • ISO 9000-3, guidelines to apply ISO 9001 to software • There is an overlap with CMM, but they are not identical • ISO 9000 philosophy –adherence to the standard does not guarantee a high-quality product; it reduces the risk of a poor-quality product • ISO 9000 is required to do business with the E.U. • More and more U.S. businesses are ISO 9000 certified

  43. ISO/IEC 15504 • Software Process Improvement Capability determination (SPICE) • Started by British Ministry of Defense (MOD) • Taken over by ISO and IEC it became an international process improvement initiative • Extends and improves both CMM and ISO 9000 • Framework for assessment methods, not a stand alone method or model • CMM and ISO 9000 conform to this framework • Now referred to as ISO/IEC 15504 or just 15504

  44. Improvement Data • SEI report on 13 organizations which used a variety of process improvement techniques, not just SW–CMM

  45. Improvement Data (contd.) • Results of 34 Motorola Government Electronics Division projects

More Related