1. Software Processes (a)
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 Risk assessment and reduction
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