Software Process Models

1. Software Process Models Lawrence Chung Software Engineering

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. Why Software Process? Quality of product Quality of Process • Garbage in garbage out, so get the right requirements Good Process: Input -> Software Input -> Software Bad Process: Input -> Software Input -> Software P r o c e s s • thru garbage, garbage out, so get the right process Product So, know the input sources, specify process & specify product

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

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

6. Waterfall model 2 [Sommerville2000]

7. Waterfall model – pros and cons • Inflexible partitioning of the project into distinct stages • This makes it difficult to respond to changing customer requirements • 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) • Simplicity and controllability

8. Incremental development • Development and delivery is broken down into increments • Each increment delivers part of the required functionality • 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 • Requirements for later increments can continue to evolve

9. Incremental development advantages • 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 • Lower risk of overall project failure • The highest priority system services tend to receive the most testing

10. Spiral development • 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. • 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

11. D e t e r m i n e o b j e c t i v e s E v a l u a t e a l t e r n a t i v e s a l t e r n a t i v e s a n d i d e n t i f y , r e s o l v e r i s k s c o n s t r a i n t s R i s k a n a l y s i s R i s k a n a l y s i s R i s k O p e r a - a n a l y s i s P r o t o t y p e 3 t i o n a l p r o t o y p e P r o t o t y p e 2 Risk P r o t o - anal ysis R E V I E W t y p e 1 R e q u i r e m e n t s p l a n S i m u l a t i o n s , m o d e l s , b e n c h m a r k s L i f e - c y c l e p l a n C o n c e p t o f O p e r a t i o n S / W P r o d u c t r e q u i r e m e n t s D e t a i l e d d e s i g n d e s i g n R e q u i r e m e n t D e v e l o p m e n t v a l i d a t i o n p l a n C o d e U n i t t e s t D e s i g n I n t e g r a t i o n V & V I n t e g r a t i o n a n d t e s t p l a n P l a n n e x t p h a s e t e s t A c c e p t a n c e t e s t D e v e l o p , v e r i f y S e r v i c e n e x t - l e v e l p r o d u c t Spiral model

12. Formal systems development • 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 • Embodied in the ‘Cleanroom’ approach to software development • No need to test for defects

13. Formal systems development

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

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

16. Extreme programming • 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 • Recently included into ‘agile methods’ since ‘extreme’ had a negative connotation

17. Capability Maturity Model [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 • As a guidance for measuring software process maturity Continuously Improving process 5 - Optimizing Predictable process 4 - Managed Standard, Consistent process 3- Defined 2 - Repeatable Disciplined process 1 - Initial

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 • 22 months to move from level 2 to 3 • 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. Quantitatively Managed (4) Optimizing (5) Defined (3) Managed (2) Initial (1) CMMI-SE/SW/IPPD/SS - Staged Focus • Organizational Innovation and Deployment (OID) • Causal Analysis and Resolution (CAR) Continuous Process Improvement (2 PAs) • Organizational Process Performance (OPP) • Quantitative Project Management (QPM) Quantitative Management (2 PAs) • 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) • Organization Environment • for Integration (OEI) • Integrated Teaming (IT) Process Standardization (11 PAs) • Integrated Supplier • Management (ISM) Basic Project Management (7 PAs) • 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) * Additional PA goals and activities added for IPPD Ad hoc, chaotic processes

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

21. Points to Ponder • 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? • When you carry out testing, what would be the criteria to say a line of program is an error?