1. An Overview of Software Processes
Reference: Software Engineering, by Ian Sommerville, 6th edition, Chapter 3
CMSC 345, Version 1/03

2. Objectives
To introduce the general phases of the software (development) life cycle
To describe various generic software process models and their pros and cons
CMSC 345, Version 1/03

3. Software Life Cycle
The phases necessary to develop and maintain a software system. These phases include:
Requirements (Specification)
Design
Implementation (Coding)
Testing (Validation)
Maintenance (Evolution)
A software process model is an abstract representation of how these phases can be addressed.
CMSC 345, Version 1/03

4. Requirements The process of establishing
what services are required of the system
the constraints on the system’s operation and development
The “what” of the software life cycle
CMSC 345, Version 1/03

5. A Generic Requirements Process
CMSC 345, Version 1/03

6. Design
The process of converting the system specification (requirements) into a software structure that realizes that specification
The “how” of the software life cycle
CMSC 345, Version 1/03

7. A Generic Software Design Process
CMSC 345, Version 1/03

8. Implementation
Translating a design into a program and removing errors from that program
Programming is a personal activity - there is no generic programming process.
Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.
The activities of design and implementation are closely related and may be interleaved.
CMSC 345, Version 1/03

9. Testing
Verification and validation is intended to show that a system conforms to its specification and meets the requirements of the system customer.
Involves checking and review processes and system testing
System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.
CMSC 345, Version 1/03

10. A Generic Testing Process
CMSC 345, Version 1/03

11. V-Model of Test Planning
CMSC 345, Version 1/03

12. System Maintenance
Software is inherently flexible and can change (as opposed to hardware).
In the past, there has been a demarcation between development and evolution (maintenance). This is increasingly irrelevant as fewer and fewer systems are completely new.
Software engineering should be thought of as an evolutionary process where software is continually changed over its lifetime in response to customer needs.
CMSC 345, Version 1/03

13. Software Process Models
Waterfall model (Royce, 1970)
Prototyping
Throwaway
Evolutionary
Incremental development
Spiral model (Boehm, 1988)
CMSC 345, Version 1/03

14. Waterfall Model Requirements Design Implementation Testing Maintenance
CMSC 345, Version 1/03

15. Observations
The following phase should not start until the previous phase has finished.
In practice,
Phases overlap
May return to a previous phase
Still widely used, especially on very large projects
CMSC 345, Version 1/03

16. Waterfall Model Pros and Cons
CMSC 345, Version 1/03

17. Prototyping Requirements Design Design Implementation Implementation
Testing
Testing
Maintenance
CMSC 345, Version 1/03

18. Observations Used for requirements elicitation and validation
A “working” model (prototype) of the final system is developed during requirements
Is an iterative process
Prototype can be thrown away or evolved into the final system (evolutionary prototyping)
CMSC 345, Version 1/03

19. Prototyping Pros and Cons
CMSC 345, Version 1/03

20. Throwaway vs. Evolutionary
Throwaway pros
Evolutionary pros
CMSC 345, Version 1/03

21. Incremental Development
CMSC 345, Version 1/03

22. Observations
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.
Is an iterative process
CMSC 345, Version 1/03

23. Incremental Pros and Cons
CMSC 345, Version 1/03

24. Spiral Model
CMSC 345, Version 1/03

25. Observations
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.
Uses prototyping
CMSC 345, Version 1/03

26. Things to Think About What about modifying existing software?
What about using existing software?
In-house modules
COTS (Commercial Off-The-Shelf)
CMSC 345, Version 1/03