1. 1 Software Process Models Lawrence ChungSoftware Engineering

2. 2 What is a Process?  Given input, transforms it into output  Consist of a set of activities  Ordering among the activities (a partial order)  Software Process  Also called methodology sometimes  People are everything  Involves use of “resources”, such as ???  Software process models ~~ software lifecycle models  Process descriptions are also specifications  Should be as complete, consistent and clear

3. 3 Why Software Process? Quality of product Quality of Process Product ProcessProcess So, know the input sources, specify process & specify product  Garbage in garbage out, so get the right requirements  thru garbage, garbage out, so get the right process Good Process: Input -> Software Good Process: Input -> Software Input -> Software Input -> Software Bad Process: Input -> Software Input -> Software

4. 4 Software lifecycle models: Generic software process models The waterfall model The waterfall model Separate and distinct phases of specification and development Separate and distinct phases of specification and development Incremental development (w. evolutionary) Incremental development (w. evolutionary) Each increment represents one functionality; Each increment represents one functionality; Specification and development can be interleaved Specification and development can be interleaved The Spiral model The Spiral model Each loop in the spiral represents an incremental phase in the process. Each loop in the spiral represents an incremental phase in the process. Formal systems development Formal systems development A mathematical system model is formally transformed to an implementation A mathematical system model is formally transformed to an implementation Reuse-based development Reuse-based development The system is assembled from existing components The system is assembled from existing components

5. 5 Waterfall model 1 [aka Royce1970] Systems Engineering Software Req. Analysis Project Planning Design Implementation Testing/Verification Release Operation/Maintenance Separate and distinct phases of specification and development

6. 6 Waterfall model 2 [Sommerville2000]

7. 7 Waterfall model – pros and cons Inflexible partitioning of the project into distinct stages Inflexible partitioning of the project into distinct stages This makes it difficult to respond to changing customer requirements This makes it difficult to respond to changing customer requirements This model is only appropriate when the requirements are well-understood This model is only appropriate when the requirements are well-understood Big design up front - time spent early on making sure that requirements and design are correct is very useful in economic terms (it will save you much time and effort later) Big design up front - time spent early on making sure that requirements and design are correct is very useful in economic terms (it will save you much time and effort later) Simplicity and controllability Simplicity and controllability

8. 8 Incremental development Development and delivery is broken down into increments Development and delivery is broken down into increments Each increment delivers part of the required functionality Each increment delivers part of the required functionality Requirements are prioritised and the highest priority requirements are included in early increments Requirements are prioritised and the highest priority requirements are included in early increments Once the development of an increment is started, the requirements are frozen Once the development of an increment is started, the requirements are frozen Requirements for later increments can continue to evolve Requirements for later increments can continue to evolve

9. 9 Incremental development advantages System functionality is available earlier and customer does not have to wait as long System functionality is available earlier and customer does not have to wait as long Early increments act as a prototype to help elicit requirements for later increments Early increments act as a prototype to help elicit requirements for later increments Lower risk of overall project failure Lower risk of overall project failure The highest priority system services tend to receive the most testing The highest priority system services tend to receive the most testing

10. 10 Spiral development Process is represented as a spiral rather than as a sequence of activities with backtracking Process is represented as a spiral rather than as a sequence of activities with backtracking Each loop in the spiral represents a phase in the process. Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required Risks are explicitly assessed and resolved throughout the process Risks are explicitly assessed and resolved throughout the process

11. 11 Spiral model Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integration test Acceptance test Service Develop, verify next-level product Evaluate alternatives identify, resolve risks Determine objectives alternatives and constraints Plan next phase Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW

12. 12 Formal systems development Based on the transformation of a mathematical specification through different representations to an executable program Based on the transformation of a mathematical specification through different representations to an executable program Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification Embodied in the ‘Cleanroom’ approach to software development Embodied in the ‘Cleanroom’ approach to software development No need to test for defects No need to test for defects

13. 13 Formal systems development

14. 14 Formal systems development Problems Problems Need for specialised skills and training to apply the technique Need for specialised skills and training to apply the technique Difficult to formally specify some aspects of the system such as the user interface Difficult to formally specify some aspects of the system such as the user interface Changes require new transformations and proofs Changes require new transformations and proofs Typically does not scale Typically does not scale Applicability Applicability Critical systems (e.g., in terms of safety or security) Critical systems (e.g., in terms of safety or security)

15. 15 Reuse-oriented development Based on systematic reuse where systems are integrated from existing components or COTS systems Based on systematic reuse where systems are integrated from existing components or COTS systems Process stages Process stages Component analysis Component analysis Requirements modification Requirements modification System design with reuse System design with reuse Development and integration Development and integration Becoming important but still limited experience with it Becoming important but still limited experience with it

16. 16 Extreme programming New approach to development based on the development and delivery of very small increments of functionality New approach to development based on the development and delivery of very small increments of functionality Relies on constant code improvement, user involvement in the development team and pairwise programming Relies on constant code improvement, user involvement in the development team and pairwise programming Recently included into ‘agile methods’ since ‘extreme’ had a negative connotation Recently included into ‘agile methods’ since ‘extreme’ had a negative connotation

17. 17 Capability Maturity Model [SEI] Developed in 1986 with leadership from the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU), CMU-SEI. Developed in 1986 with leadership from the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU), CMU-SEI. For assessing and improving software processes For assessing and improving software processes As a guidance for measuring software process maturity As a guidance for measuring software process maturity 5 - Optimizing 4 - Managed 3- Defined 2 - Repeatable 1 - Initial Disciplined process Standard, Consistent process Predictable process Continuously Improving process

18. 18 Some CMM Observations…  The number of companies using CMM to assess their software management practices more than doubles every 5 years  Software Quality Assurance is the biggest obstacle for organizations trying to move from level 1 to level 2.  Organization Process Definition is one of the biggest obstacles for organization trying to move from level 2 to level 3.  On average, it takes an organization: 25 months to move from level 1 to 2 25 months to move from level 1 to 2 22 months to move from level 2 to 3 22 months to move from level 2 to 3 36.5 months to move from level 3 to 4 36.5 months to move from level 3 to 4  Only 1.2% of companies engaged in CMM have IT departments with over 2000 employees. Of these large companies, 40% are at CMM levels 3, 4 or 5.  About 80% of companies engaged in CMM have IT departments with less than over 300 employees. Of these smaller companies, 21% are at CMM levels 3, 4, or 5.  About 1/3 of companies engaged in CMM are located overseas (primarily India), and are 3 times more likely to reach CMM level 4 or 5 than US organizations.  Only about 23% of organizations surveyed eventually move from level 2 to level 3 or higher.

19. 19 CMMI-SE/SW/IPPD/SS - Staged Initial (1) Defined (3) Managed (2) Ad hoc, chaotic processes Quantitatively Managed (4) Optimizing (5) Process Standardization (11 PAs ) Continuous Process Improvement (2 PAs) Organization Environment for Integration (OEI) Integrated Teaming (IT) * Additional PA goals and activities added for IPPD Requirements Management (REQM) Project Planning (PP) Project Monitoring and Control (PMC) Supplier Agreement Management (SAM) Measurement and Analysis (M&A) Process and Product Quality Assurance (PPQA) Configuration Management (CM) Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organization Training (OT) Integrated Project Management (IPM) * Risk Management (RSKM) Decision Analysis and Resolution (DAR) Organizational Process Performance (OPP) Quantitative Project Management (QPM) Organizational Innovation and Deployment (OID) Causal Analysis and Resolution (CAR) Integrated Supplier Management (ISM) Basic Project Management (7 PAs) Quantitative Management (2 PAs) Focus

20. 20 Software Process Variability Many Variety …and Evolution is inevitable Software processes may vary radically from one organisation to another Software processes may vary radically from one organisation to another Factors contributing to this variability include Factors contributing to this variability include Technical maturity Technical maturity Disciplinary involvement Disciplinary involvement Organisational culture Organisational culture Application domain Application domain … There is therefore no ‘ideal’ software engineering process [KotonyaSummerville98] There is therefore no ‘ideal’ software engineering process [KotonyaSummerville98]

21. 21 Points to Ponder What kind of software process are you using for doing your course project now? And why? What kind of software process are you using for doing your course project now? And why? Have you ever reused any software components? If so, what kind of software process was used during the reuse? Have you ever reused any software components? If so, what kind of software process was used during the reuse? When you carry out testing, what would be the criteria to say a line of program is an error? When you carry out testing, what would be the criteria to say a line of program is an error?