Software Process Models
Software Process Models
Software process models are general
approaches for
organizing a project into activities.
Help the project manager and his or her team to
decide:
What work should be done;
In what sequence to perform the work.
The models should be seen as aids to thinking,
not rigid prescriptions of the way to do things.
Each project ends up with its own unique plan.
The opportunistic approach
The opportunistic approach
OK for small, informal projects
Inappropriate for complex software
Inappropriate for professional environments where
on-time
delivery and high quality are expected
Requirements and design not worked out before
implementation
The design of software deteriorates faster if it is not well
designed.
Since there are no plans, there is nothing to aim towards.
No explicit recognition of the need for systematic testing
The above problems make the cost of developing and
maintaining software very high.
The Waterfall Model
The Waterfall Model
The classic way of looking at S.E. that
accounts for the importance of
requirements, design and quality assurance.
The model suggests that software engineers
should work in a series of stages.
Before completing each stage, they should
perform quality assurance (verification and
validation).
The waterfall model also recognizes, to a limited
extent, that you sometimes have to step back to
earlier stages.
Limitations of the waterfall
model
The model implies that you should attempt to complete
a given stage before moving on to the next stage
Does not account for the fact that requirements constantly
change.
It also means that customers can not use anything until the
entire system is complete.
The model makes no allowances for prototyping.
It implies that you can get the requirements right by
simply writing them down and reviewing them.
The entire functionality is developed and then tested all
together at
the end. Major design problems may not be detected till
very late.
The model implies that once the product is finished,
everything else is maintenance.
Incremental Models:
Incremental
Incremental Development
Development occurs as a succession of releases with
increasing functionality.
Customers provide feedback on each release
Used in deciding requirements and improvements for next
release
There is no “maintenance” phase – each version includes
both problem fixes as well as new features
May also include “re-engineering” – changing the
design and implementation of existing functionality, for
easier maintainability
The “phased release” and “evolutionary” models
discussed in the text are incremental development
approaches
Incremental Process Models
(2)
Combines elements of the waterfall model applied in an
iterative fashion
The first increment is often a core product
The core product is used by the customer (or undergoes
detailed evaluation)
Based on evaluation results, a plan is developed for the
next increment
10
Advantages of incremental
development
Customers get usable functionality earlier than
with waterfall
Getting early feedback improves likelihood of
producing a product that satisfies customers
Reduces market risk: if customers hate the product, find
out early before investing too much effort and
money
The quality of the final product is better
The core functionality is developed early and tested
multiple times (during each release)
Only a relatively small amount of functionality added in
each release: easier to get it right and test it thoroughly
Detect design problems early and get a chance to
redesign
The Limitations
As product is delivered in parts total
development cost is higher.
Well defined interfaces are required
to connect modules developed with
each phase.
The model requires well defined
project planning schedule to
distribute the work properly.
Prototyping model
Prototyping Model
(Description)
Follows an evolutionary and iterative approach
Used when requirements are not well understood
Serves as a mechanism for identifying software
requirements
Focuses on those aspects of the software that are
visible to the customer/user
Feedback is used to refine the prototype
14
Prototyping Model
(Potential Problems)
The customer sees a "working version" of the
software, wants to stop all development and then
buy the prototype after a "few fixes" are made
Developers often make implementation
compromises to get the software running quickly
(e.g., language choice, user interface, operating
system choice, inefficient algorithms)
15
Spiral Model
The Spiral Model is an evolutionary software
process model that couples the iterative
nature of prototyping with the controlled
and systematic aspects of the Linear
Sequential Model.
Using the Spiral Model the software is developed
in a series of incremental releases. Unlike the
Iteration Model where in the first product is a core
product, in the Spiral Model the early iterations
could result in a paper model or a prototype.
However, during later iterations more complex
functionalities could be added.
The Spiral Model
Advantages of the Spiral
Model
Realistic approach to the development because the
software evolves as the process progresses. In
addition, the developer and the client better
understand and react to risks at each evolutionary
level.
The model uses prototyping as a risk reduction
mechanism and allows for the development of
prototypes at any stage of the evolutionary
development.
It maintains a systematic stepwise approach, like the
classic waterfall model, and also incorporates into it
an iterative framework that more reflect the real
world.
Disadvantages of the Spiral
Model
One should possess considerable risk-
assessment expertise
It has not been employed as much proven
models (e.g. the Waterfall Model) and
hence may prove difficult to ‘sell’ to the
client.
Project’s success is highly dependent on
the risk analysis phase.
Doesn’t work well for smaller projects.
The RAD Model
Rapid Application Development
Emphasizes a short development cycle
A “high speed” adaptation of the
waterfall model
Uses a component-based construction
approach
May deliver software within a very short
time period (e.g. , 60 to 90 days) if
requirements are well understood and
project scope is constrained
20
The RAD Model
Team # n
Modeling
Modeling
business modeling
business modeling
data modeling
data modeling
process modeling
process modeling
Construction
Construction
Team # 2 component reuse
component reuse
Modeling automatic code
Modeling automatic code
Communication business modeling generation
Communication generation
business modeling testing
data modeling testing
data modeling
process modeling
process modeling
Planning
Planning Construction
Construction Deployment
Team # 1 component reuse Deployment
component reuse integration
Modeling automatic code integration
Modeling automatic code delivery
business modeling generation delivery
generation
business modeling testing feedback
data modeling testing feedback
data modeling
process modeling
process modeling
Construction
Construction
component reuse
component reuse
automatic code
automatic code
generation
generation
testing
testing
21
60 – 90 days
The RAD Model
The time constraints imposed on a
RAD project demand “scalable
scope”
The application should be
modularized and addressed by
separate RAD teams
22
Unified Process Model
The Unified Process (UP) is a process for
building object-oriented systems.
The goal of the UP is to enable the production of
high quality software that meets users needs
within predictable schedules and budgets.
A software process that is:
use-case driven
architecture-centric
iterative and incremental
Closely aligned with the Unified Modeling
Language (UML)
The system grows incrementally over time,
iteration by iteration.
The system may not be eligible for production
deployment until after many iterations.
UP process
A UP project organizes the work and iterations
across four major phases:
Inception - Define the scope of project.
Elaboration - Plan project, specify features,
baseline architecture.
Construction - Build the product
Transition - Transition the product into end
user community
Unified Process Model
UP process
Each phase and iteration has some risk
mitigation focus, and concludes with a well-
defined milestone.
The milestone review provides a point in time
to assess how well key goals have been met
and whether the project needs to be
restructured in any way to proceed.
The end of each iteration is a minor release,
a stable executable subset of the final
product.
UP Work Products
What is
“Agility”?
Rapid and adaptive response to
change
Effective communication among all
stakeholders
Drawing the customer onto the team
Organizing a team so that it is in
control of the work performed
Yielding …
Rapid, incremental delivery of software
Agile Teams
are responsive to changes during
project development
recognize that project plans must
be flexible
eliminates the separation between
customers and developers
Agility
encourages team structures that make
communication among developers and
customers easier
emphasizes importance of rapid delivery of
operational software and de-emphasizes
importance of intermediate work products
can be applied to any software process as long
as the project team is allowed to streamline
tasks and conduct planning in way that
eliminate non-essential work products
An Agile Process
Is driven by customer descriptions of
what is required (scenarios)
Recognizes that plans are short-lived
Develops software iteratively with a
heavy emphasis on implementation
Delivers multiple ‘software
increments’
Adapts as changes occur
Component-based Development
Model
Commercial off-the-shelf (COTS) software components, developed
by vendors who offer them as products, provide targeted
functionality with well-defined interfaces that enable the
component to be integrated into the software that is to be built
Consists of the following process steps
Available component-based products are researched and
evaluated for the application domain in question
Component integration issues are considered
A software architecture is designed to accommodate the
components
Components are integrated into the architecture
Comprehensive testing is conducted to ensure proper
functionality
Capitalizes on software reuse, which leads to documented
savings in project cost and time
32
Choosing a process model
Waterfall approach is OK for small projects,
and when requirements & design can be
done near-perfectly upfront
Most complex real-world projects these days
use an incremental approach with multiple
phases
We can borrow ideas from different process
models and create an approach that is suited
to the characteristics of our particular project
