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

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

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

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

A Generic Requirements Process CMSC 345, Version 1/03

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

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

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

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

A Generic Testing Process CMSC 345, Version 1/03

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

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

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

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

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

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

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

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

Prototyping Pros and Cons CMSC 345, Version 1/03

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

Incremental Development CMSC 345, Version 1/03

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

Incremental Pros and Cons CMSC 345, Version 1/03

Spiral Model CMSC 345, Version 1/03

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

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