Software Process Models and Generic Models in Software Development

1. Lesson 2 Software Processes (a)

2. Objectives • To introduce software process models • To describe three generic process models and when they may be used • To describe outline process models for requirements engineering, software development, testing and evolution • To explain the Rational Unified Process model • To introduce CASE technology to support software process activities

3. Topics covered • Software process models • Process iteration • Fundamental process activities • Rational Unified Process • CASE

4. What is a software process model? • A simplified representation of a software process, presented from a specific perspective • Examples of process perspectives are • Workflow perspective - sequence of activities • Data-flow perspective - information flow • Role/action perspective - who does what • Generic process models • Waterfall • Iterative development • Formal transformation • Integration from reusable components

5. What is a software process? • A set of activities and associated results whose goal is the development or evolution of a software product • Generic activities in all software processes are: • Specification - what the system should do and its development constraints • Development - production of the software system • Validation - checking that the software is what the customer wants • Evolution - changing the software in response to changing demands

6. The software process • A structured set of activities (and associated results) required to develop (evolve) a software system • Specification • Design and implementation • Validation • Evolution • A software process model is an abstract representation of a process. • presents a description of a process from a particular perspective • a simplified representation

7. The software process… • Software development is a complex process needing human judgement and creativity • therefore could not be fully automated • There is no ‘ideal’ software process • Many diverse processes exist • There is room for improvement! • Organizations select software processes based on: • capabilities of people in the organization • characteristics of the system to be developed etc.

8. Generic software process models • The waterfall model • Separate and distinct phases of specification and development • Evolutionary development • Specification, development and validation are interleaved • Component-based software engineering • The system is assembled from existing components. • There are many variants of these models • formal development - a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design.

9. Waterfall model

10. Waterfall model phases • Requirements analysis and definition • System and software design • Implementation and unit testing • Integration and system testing • Operation and maintenance

11. Waterfall model… • Each stage produces documents at the end • Next stage starts only after signing-off the previous stage • non-overlapping stages (but in reality, they do overlap) • A number of iterations • e.g. requirement errors identified during design, go back and correct them • Due to the high-cost involved in rework, stages are frozen after a few iterations. • problems identified later are left to be resolved later or worked around in programming -> may lead to badly structured systems

12. Waterfall model: advantages • It is a well understood mature process • Easy to manage projects • Produces robust, well-structured systems • High process visibility

13. Waterfall model: problems • Inflexible partitioning of the project into distinct stages • Makes it difficult to respond to changing customer requirements • Therefore, this model is only appropriate when • The requirements are well-understood • Requirement changes are limited

14. Evolutionary development • Underlying idea • Give an initial implementation to the users and then refinine it through many versions based on user feedback • Exploratory development • Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements • Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements

15. Evolutionary development…

16. Evolutionary development… • Problems • Lack of process visibility • Systems are often poorly structured • Special skills (e.g. in languages for rapid prototyping) may be required • Applicability • For small or medium-size interactive systems • For parts of large systems (e.g. the user interface) • For short-lifetime systems

17. Component-based software engineering • Reuse occurs informally in almost all software projects • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Process stages • Component analysis • Requirements modification • System design with reuse • Development and integration • This approach is becoming increasingly used as component standards have emerged

18. Component-based software engineering..

19. Component-based software engineering.. • Advantages • reduces the amount of software to develop • reduces cost and risks • faster delivery • Disadvantages • requirement compromises • lose control of system evolution (because component evolution is not controllable)

20. 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 • Design, implementation and unit-testing phases are replaced by a transformational development process

21. Formal systems development… (iterations have been excluded)

22. Formal transformations

23. 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 • Applicability • Critical systems especially those where a safety, reliability and security requirements are important • e.g. Patient monitoring system, airplane engine control system

24. Process iteration and hybrid models • LARGE SYSTEMS need different approaches for different parts • System requirements always evolve during a project • So process iteration where earlier stages are reworked is always part of the process for large systems • Two (related) approaches • Incremental development • Spiral development

25. Incremental development • The development and delivery is broken down into increments with each increment delivering part of the required functionality • User 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 • But requirements for later increments can continue to evolve

26. Incremental development…

27. Incremental development… • Advantages • Customer value can be delivered with each increment so system functionality is available earlier • 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 • Different processes can be used for increments • Disadvantages • Difficult to map user requirements into increments which can deliver functionality • Difficult to identify small increments (<20,000 LOC) • Difficulty of identifying the common facilities needed by all sub-systems

28. 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 • Good for small teams

29. 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

30. Spiral model of the software process

31. Spiral model sectors • Objective setting • Specific objectives for the phase are identified • Risk assessment and reduction • Risks are assessed and activities put in place to reduce the key risks • Development and validation • A development model for the system is chosen which can be any of the generic models • Develop and validate the system in the current phase • Planning • The project is reviewed and the next phase of the spiral is planned

32. Spiral model… • Identifies probable risks in advance and tries to minimize them • e.g. if it is decided to use a new programming language, the compilers available may not be reliable • Occurrence of a risk item could result in project delay, exceeding cost or even failure • Different processes maybe used for different loops in the spiral