cmsc 345, version 1/03 an overview of software processes reference: software engineering, by ian...
TRANSCRIPT
CMSC 345, Version 1/03
An Overview ofSoftware 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
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
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
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
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
Sub-systemtesting
Moduletesting
Unittesting
Systemtesting
Acceptancetesting
Componenttesting
Integration testing Usertesting
CMSC 345, Version 1/03
V-Model of Test Planning
Requirementsspecification
Systemspecification
Systemdesign
Detaileddesign
Module andunit codeand tess
Sub-systemintegrationtest plan
Systemintegrationtest plan
Acceptancetest plan
ServiceAcceptance
testSystem
integration testSub-system
integration test
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
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
Prototyping
Requirements
Implementation
Design
Testing
Design
Implementation
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
Incremental Development
Valida teincrement
Develop systemincrement
Design systemarchitecture
Integrateincrement
Valida tesystem
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
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
Spiral Model
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
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