An Overview of Software Processes Reference Software Engineering

  • Slides: 26
Download presentation
An Overview of Software Processes Reference: Software Engineering, by Ian Sommerville, 6 th edition,

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

Objectives l l To introduce the general phases of the software (development) life cycle

Objectives l l 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 l The phases necessary to develop and maintain a software system.

Software Life Cycle l The phases necessary to develop and maintain a software system. These phases include: • • • l 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 l l The process of establishing • what services are required of the

Requirements l l 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

A Generic Requirements Process CMSC 345, Version 1/03

Design l l The process of converting the system specification (requirements) into a software

Design l l 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

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

Implementation l l Translating a design into a program and removing errors from that

Implementation l l 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 l l l Verification and validation is intended to show that a system

Testing l l l 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

A Generic Testing Process CMSC 345, Version 1/03

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

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

System Maintenance l l l Software is inherently flexible and can change (as opposed

System Maintenance l l l 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 l l Waterfall model (Royce, 1970) Prototyping • Throwaway • Evolutionary

Software Process Models l l 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

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

Observations l l The following phase should not start until the previous phase has

Observations l l The following phase should not start until the previous phase has finished. In practice, • • l 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 Pros Cons CMSC 345, Version 1/03

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

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

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

Observations l l Used for requirements elicitation and validation A “working” model (prototype) of

Observations l l 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 Pros Cons CMSC 345, Version 1/03

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

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

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

Incremental Development CMSC 345, Version 1/03

Incremental Development CMSC 345, Version 1/03

Observations l l l Development and delivery is broken down into increments with each

Observations l l l 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 Pros Cons CMSC 345, Version 1/03

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

Spiral Model CMSC 345, Version 1/03

Spiral Model CMSC 345, Version 1/03

Observations l l l Process is represented as a spiral rather than as a

Observations l l l 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 l l What about modifying existing software? What about using

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