Chapter 3
Prescriptive Process Models
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman
Raheela Nasim 1
Software process model
• Attempt to organize the software life cycle by
• defining activities involved in software production
• order of activities and their relationships
• Goals of a software process
– standardization, predictability, productivity, high
product quality, ability to plan time and budget
requirements
Raheela Nasim 2
Code&Fix
The earliest approach
• Write code
• Fix it to eliminate any errors that have been detected,
to enhance existing functionality, or to add new
features
• Source of difficulties and deficiencies
– impossible to predict
– impossible to manage
Raheela Nasim 3
Models are needed
• Symptoms of inadequacy: the software
crisis
– scheduled time and cost exceeded
– user expectations not met
– poor quality
• The size and economic value of software
applications required appropriate "process
models"
Raheela Nasim 4
Process model goals
(B. Boehm 1988)
"determine the order of stages involved in
software development and evolution,
and to establish the transition criteria for
progressing from one stage to the next.
These include completion criteria for the current
stage plus choice criteria and entrance criteria
for the next stage. Thus a process model addresses
the following software project questions:
What shall we do next?
How long shall weRaheela
continue
Nasim
to do it?" 5
Process as a "black box"
Informal
Requirements
Process
Product
Quality?
Uncertain /
Incomplete
requirement
In the beginning Raheela Nasim 6
Problems
• The assumption is that requirements can be fully
understood prior to development
• Interaction with the customer occurs only at the
beginning (requirements) and end (after delivery)
• Unfortunately the assumption almost never holds
Raheela Nasim 7
Process as a "white box"
Informal
Requirements
Process
Product
feedback
Raheela Nasim 8
Advantages
• Reduce risks by improving visibility
• Allow project changes as the project
progresses
– based on feedback from the customer
Raheela Nasim 9
The main activities of software
production
• They must be performed independently of the
model
• The model simply affects the flow among
activities
Raheela Nasim 10
The Waterfall Model
Raheela Nasim 11
Waterfall Model Assumptions
1. It is also referred to as a linear-sequential life cycle model.
2. In a waterfall model, each phase must be completed fully before the
next phase can begin.
3. This type of model is basically used for the for the small and large
project which is and there are no uncertain requirements.
4. At the end of each phase, a review takes place to determine if the
project is on the right path and whether or not to continue or discard
the project.
5. In this model the testing starts only after the development is complete.
6. In waterfall model phases do not overlap.
Raheela Nasim 12
Advantages of waterfall model:
• This model is simple and easy to understand and use.
• It is easy to manage due to the rigidity of the model – each phase
has specific deliverables and a review process.
Disadvantages of waterfall model:
• Once an application is in the testing stage, it is very difficult to go
back and change something that was not well-thought out in the
concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects..
• Not suitable for the projects where requirements are at a moderate
to high risk of changing.
Raheela Nasim 13
• Among the problems that are sometimes encountered when the waterfall
model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly. As a
result, changes can cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The
waterfall model requires this and has difficulty accommodating the natural
uncertainty that exists at the beginning of many projects.
3. The customer must have patience. A working version of the program(s) will not
be available until late in the project time span. A major blunder, if undetected
until the working program is reviewed, can be disastrous.
14
The V Model
If we rely on testing alone, defects created first are detected last
Raheela Nasim 15
• The V model is an extension of waterfall model.
• The V-model provides a way of visualizing how verification and validation
actions are applied to earlier engineering work.
• As stated, left arm of V model is conventional waterfall model of the
development and right arm is for corresponding testing phases. Each
verification activity (such as requirement specification verification,
functional Design verification etc.) has its corresponding validation activity
(such as Functional validation/testing, code validation/testing,
System/integration validation etc.)
• The major purpose of acceptance testing is to validate /confirm that system
meets business requirements and provides confidence before it is delivered
to the end user.
• This testing involves user representative and testing team members.
• Once the entire system has been developed then it has to be tested
against the “system specification” to validate if it delivers the features
required. In short, system testing is not about checking the individual parts
of the design, but about checking the system as a whole.
Raheela Nasim 16
Advantages of V-model:
Simple and easy to use.
Testing activities like planning, test designing happens well before coding. This saves a lot of
time. Hence higher chance of success over the waterfall model.
Proactive defect tracking – that is defects are found at early stage.
Avoids the downward flow of the defects.
Works well for small projects where requirements are easily understood.
Disadvantages of V-model:
Very rigid and least flexible.
Software is developed during the implementation phase, so no early prototypes of the software
are produced.
If any changes happen in midway, then the test documents along with requirement documents
has to be updated.
When to use the V-model:
The V-shaped model should be used for small to medium sized projects where requirements
are clearly defined and fixed.
The V-Shaped model should be chosen when ample technical resources are available with
needed technical expertise.
High confidence of customer is required for choosing the V-Shaped model approach. Since, no
prototypes are produced, there is a very high risk involved in meeting customer expectations
.
Raheela Nasim 17
• In an interesting analysis of actual projects, it is found that the
linear nature of the classic life cycle leads to “blocking states” in
which some project team members must wait for other members
of the team to complete dependent tasks.
• In fact, the time spent waiting can exceed the time spent on
productive work! The blocking states tend to be more prevalent at
the beginning and end of a linear sequential process.
• Today, software work is fast-paced and subject to a never-ending
stream of changes (to features, functions, and information
content). The waterfall model is often inappropriate for such work.
• However, it can serve as a useful process model in situations where
requirements are fixed and work is to proceed to completion in a
linear manner.
Raheela Nasim 18
Incremental Models: Incremental
Raheela Nasim 19
• The system is put into production when the first increment is delivered.
• The first increment is often a core product where the basic requirements are
addressed, and supplementary features are added in the next increments.
• Once the core product is analyzed by the client, there is plan development for
the next increment.
• System development is broken down into many mini development projects
• Partial systems are successively built to produce a final total system
• Highest priority requirement is tackled first
Raheela Nasim 20
Advantages of Incremental model:
Generates working software quickly and early during the software life cycle.
More flexible – less costly to change scope and requirements.
Easier to test and debug during a smaller iteration.
Customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during it’d iteration.
Disadvantages of Incremental model:
Needs good planning and design.
Needs a clear and complete definition of the whole system before it can be broken down and
built incrementally.
Total cost is higher than waterfall.
When to use the Incremental model:
Requirements of the complete system are clearly defined and understood.
Major requirements must be defined; however, some details can evolve with time.
There is a need to get a product to the market early.
A new technology is being used
Resources with needed skill set are not available
There are some high risk features and goals.
Raheela Nasim 21
Incremental Models: RAD Model
Raheela Nasim 22
• Business modeling: The information flow is identified between various
business functions.
Data modeling: Information gathered from business modeling is used to
define data objects that are needed for the business.
Process modeling: Data objects defined in data modeling are converted to
achieve the business information flow to achieve some specific business
objective. Description are identified and created for CRUD of data objects.
Application generation: Automated tools are used to convert process
models into code and the actual system.
Testing and turnover: Test new components and all the interfaces.
Raheela Nasim 23
Advantages of the RAD model:
Reduced development time.
Increases reusability of components
Quick initial reviews occur
Encourages customer feedback
Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD model:
Depends on strong team and individual performances for identifying business requirements.
Only system that can be modularized can be built using RAD
Requires highly skilled developers/designers.
High dependency on modeling skills
Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.
When to use RAD model:
RAD should be used when there is a need to create a system that can be modularized in 2-3
months of time.
It should be used if there’s high availability of designers for modeling and the budget is high
enough to afford their cost along with the cost of automated code generating tools.
RAD SDLC model should be chosen only if resources with high business knowledge are
available and there is a need to produce the system in a short span of time (2-3 months).
Raheela Nasim 24