Software Engineering - Process Models
Software Engineering - Process Models
Types of Models
1. Descriptive Models
Describes the history of how a particular system was developed.
Used as a basis for understanding and improving s/w process.
Used for building prescriptive models.
2. Prescriptive Models
Prescribes how software should be developed.
Used as guidelines to organize and structure how s/w activities should be performed, and in
what order
Advantages
Does not waste time in planning and documentation.
Page 1
Disadvantages
Underestimate project attributes
Difficult to evaluate success
Waterfall Model
o
o
o
o
o
Requirements
Engineering
Software Design
Implementation and Unit
Testing
Integration and system testing
Maintenance
Evolutionary prototype
o Objective is to work with customers and to evolve a final system from an initial outline
specification.
Page 2
It should start with well-understood requirements and add new features as proposed by
the customer.
Prototyping
Outline
description
Specification
Initial version
Development
Intermediate version
Validation
Final version
Advantages of prototypes
The resulting system is easy to use and maintain.
User needs are better accommodated
The design is of higher quality
The development incurs less effort.
Problems are detected earlier
Disadvantages of prototypes
The resulting system harder to maintain.
The performance of the resulting system is worse.
The design is of less quality
The development incurs more effort.
The approach requires more experienced team members
Spiral Model
Evolutionary model with iterative nature of prototyping and systematic aspects of waterfall
model.
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.
Page 3
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 (Risk driven).
Model sectors
1. Objective setting
Specific objectives for the phase are identified.
2. Risk assessment and reduction
Risks are assessed and activities put in place to reduce the key risks.
Prototyping is used to clarify things.
3. Development and validation
A development model for the system is chosen which can be any of the generic models.
The software is developed
4. Planning
The project is reviewed and the next phase of the spiral is planned.
Outline
specification
Develop
system
increments
Assign requirements to
increments
Validate
increments
Integrate
increments
Design System
Architecture
Validate
system
Page 4
Elements of RAD
i.
ii.
iii.
iv.
v.
Prototyping
Reuse can use already existing components
Use of automated tools use tools to develop the software
Small development teams enhances good communication between the developers and
stakeholders
Employs time block a fixed time frame for each working product to be delivered
Advantages of RAD
Its fast
High level user interaction
High communication
Drawbacks of RAD
For large but scalable projects, RAD requires sufficient human resources to create the right
number of RAD teams.
Page 5
RAD requires developers and customers who are committed to the rapid-fire activities necessary
to get a system complete in a much abbreviated time frame. If commitment is lacking from either
constituency, RAD projects will fail.
System need to be properly modularised
RAD is not appropriate when technical risks are high. This occurs when a new application makes
heavy use of new technology or when the new software requires a high degree of interoperability
with existing computer programs.
Not for high performance systems
Its construction is based on systematic reuse where systems are integrated from existing
components or COTS (Commercial-off-the-shelf) components.
Phases
Requirements Engineering
System design with reuse
Component analysis/Qualification
Adaptation
Assembly and integration components tested together.
Evolution and maintenance
Page 6