©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 1
CSC 221 – Introduction to Software Engineering
software processes
extract from Sommerville’s chapter 3 slides
Alan Dix
www.hcibook.com/alan/teaching/CSC221/
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 2
Software Processes
λ
Coherent sets of activities for specifying, designing, implementing and testing software systems
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 3
The software process
λ
A structured set of activities required to develop a software system
• Specification
• Design
• Validation
• Evolution
λ
A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 4
Generic software process models
λ
The waterfall model
• Separate and distinct phases of specification and development
λ
Evolutionary development
• Specification and development are interleaved
λ
Formal systems development
• A mathematical system model is formally transformed to an implementation
λ
Reuse-based development
• The system is assembled from existing components
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 5
Waterfall model
Requirements definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 6
Waterfall model phases
λ
Requirements analysis and definition
λ
System and software design
λ
Implementation and unit testing
λ
Integration and system testing
λ
Operation and maintenance
λ
The drawback of the waterfall model is the
difficulty of accommodating change after the
process is underway
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 7
Waterfall model problems
λ
Inflexible partitioning of the project into distinct stages
λ
This makes it difficult to respond to changing customer requirements
λ
Therefore, this model is only appropriate when the requirements are well-understood
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 8
Evolutionary development
λ
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 9
Evolutionary development
Validation Final
version
Development Intermediate
versions
Specification Initial
version
Outline description
Concurrent activities
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 10
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
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
λ
Embodied in the ‘Cleanroom’ approach to software development
N.B. really about replacing/ augmenting/supporting the design and implementation phase of software development
Formal systems development
Requirements
definition Formal
specification
Formal transformation
Integration and system testing
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 13
Formal transformations
Formal R2
specification R3 Executable
program
P2 P3 P4
T1 T2 T3 T4
Proofs of transformation correctness Formal transformations
R1
P1
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 14
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 or security case must be made before the system is put into operation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 15
Reuse-oriented development
λ
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 more important but still limited experience with it
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 16
Reuse-oriented development
Requirements specification
Component analysis
Development and integration
System design with reuse Requirements
modification
System validation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 17
Process iteration
λ
System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems
λ
Iteration can be applied to any of the generic process models
λ
Two (related) approaches
• Incremental development
• Spiral development
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 18
Incremental development
λ
Rather than deliver the system as a single delivery, 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 though requirements
for later increments can continue to evolve
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 19
Incremental development
Validate increment Develop system
increment
Design system architecture
Integrate increment
Validate system Define outline
requirements Assign requirements to increments
System incomplete
Final system
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 20
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 21
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 22
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
Spiral model of the software process
Risk analysis Risk analysis Risk analysis
Risk analysis Proto-
type 1 Prototype 2
Prototype 3 Opera- tional protoype
Concept of Operation
Simulations, models, benchmarks
S/W requirements Requirement
validation Design V&V
Product design Detailed
design Code Unit test Integration Acceptance test
Service test Develop, verify next-level product Evaluate alternatives identify, resolve risks Determine objectives
alternatives and constraints
Plan next phase
Integration and test plan Development plan Requirements plan
Life-cycle plan REVIEW
Spiral model sectors
λ
Objective setting
• 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
λ
Planning
• The project is reviewed and the next phase of the spiral is planned
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 25 λ
waterfall model
λ
evolutionary development
λ
formal development
λ
reuse-oriented development
summary
normative process models
mainly effect design and implementation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 26 λ
requirements and specification
λ
design and implementation
• architectural design, detailed and sub-system design, integration of components, deployment
λ
testing, verification and validation
λ
evolution
• deployment, maintenance, changing requirements
summary similar activities
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 27 λ
waterfall model
• each activity in sequence
• whole system within each activity
λ
incremental development
• each ‘slice’ of system in sequence
• all activities for each part
λ
spiral development
• when it seems right!
summary
... but different timings
R&S D&I V&V E
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 (extract) Slide 28