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