Chapter :Software Process Model

Chapter : Topic Covered

 About software process model
 Build and Fix Model
 Why Models are needed?
 Process as a "black box“ & Problem
 Process as a “white box“ & Advantage
 Prescriptive Model
 Waterfall Model or Linear Sequential
 Incremental Process Models
 Incremental Model
 RAD Model
 Evolutionary Process Models
 Prototyping
 Spiral Model
The Four Ps: People, Project,
Product, and Process
in Software Development

 People: The architects, developers,

testers, and their supporting
management, plus users, customers,
and other stakeholders are the prime
movers in a software project
 Project: The organizational element
through which software development
is managed. The outcome of a project
is a released product.
 Product: Artifacts that are created
during the life of the project, such as
models source code, exécutables,
and documentation
 Process: A software engineering
process is a definition of the complete
set of activities needed to transform
users’ requirements into a product. A
process is a template for creating
projects
The 4 Ps in software
development.
Software process model
 Process models prescribe a distinct set of activities,
actions, tasks, milestones, and work products required
to engineer high quality software.
 Process models are not perfect, but provide roadmap for
software engineering work.
 Software models provide stability, control, and
organization to a process that if not managed can easily
get out of control
 Software process models are adapted to meet the needs
of software engineers and managers for a specific
project.
Build and Fix Model
Build and Fix Model
The earlier approach
 Product is constructed without specification or any
attempt at design.
 developers simply build a product that is reworked as
many times as necessary to satisfy the client.
 model may work for small projects but is totally
unsatisfactory for products of any reasonable size.
 Maintenance is high.
 Source of difficulties and deficiencies
 impossible to predict
 impossible to manage
Why Models are needed?
 Symptoms of inadequacy: the software crisis
 scheduled time and cost exceeded
 user expectations not met
 poor quality
Process as a "black box"

Informal
Requirements
Process

Product

Quality?
Uncertain /
Incomplete requirement
In the beginning
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
Process as a "white box"

Informal
Requirements
Process

Product

feedback
Advantages
 Reduce risks by improving visibility
 Allow project changes as the project
progresses
 based on feedback from the customer
Prescriptive Model
 Prescriptive process models advocate an orderly approach to software
engineering
 Organize framework activities in a certain order
 Process framework activity with set of software engineering actions.
 Each action in terms of a task set that identifies the work to be
accomplished to meet the goals.
 The resultant process model should be adapted to accommodate the
nature of the specific project, people doing the work, and the work
environment.
 Software engineer choose process framework that includes activities
like;
 Communication
 Planning
 Modeling
 Construction
 Deployment
Prescriptive Model
 Calling this model as “Prescribe”
because it recommend a set of
process elements, activities, action
task, work product & quality.
 Each elements are inter related to
one another (called workflow).
Waterfall Model or Classic Life
Cycle
Waterfall Model or Classic Life
Cycle
 Requirement Analysis and Definition: What - The systems services, constraints
and goals are defined by customers with system users.
 Scheduling tracking -
 Assessing progress against the project plan.
 Require action to maintain schedule.
 System and Software Design: How –It establishes and overall system
architecture. Software design involves fundamental system abstractions and
their relationships.
 Integration and system testing: The individual program unit or programs are
integrated and tested as a complete system to ensure that the software
requirements have been met. After testing, the software system is delivered to
the customer.
 Operation and Maintenance: Normally this is the longest phase of the software
life cycle. The system is installed and put into practical use. Maintenance involves
correcting errors which were not discovered in earlier stages of the life-cycle.
 Limitations of the waterfall
model
 The nature of the requirements will not change very much During
development; during evolution
 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 implies that once the product is finished, everything else is
maintenance.
 Surprises at the end are very expensive
 Some teams sit ideal for other teams to finish
 Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.
Problems:
1. Real projects are rarely follow the sequential model.
2. Difficult for the customer to state all the requirement explicitly.
3. Assumes patience from customer - working version of program will not
available until programs not getting change fully.

21
When to use the waterfall
model:

 This model is used only when the

requirements are very well known, clear
and fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise
are available freely
 The project is short.

22
The V-Model
A variation of waterfall model
depicts the relationship of
quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.

Team first moves down the left

side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.

23
 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.
24
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.
25
 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.
26
Incremental Process Model

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

Delivers software in small but usable pieces, each piece builds on

pieces already delivered
The Incremental Model
 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.
 First Increment is often core product
 Includes basic requirement
 Many supplementary features (known & unknown) remain
undelivered
 A plan of next increment is prepared
 Modifications of the first increment
 Additional features of the first increment
 It is particularly useful when enough staffing is not available for the
whole project
 Increment can be planned to manage technical risks.
 Incremental model focus more on delivery of operation product with
each increment.
The Incremental Model
 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.
 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.
 When to use the Incremental model:
 This model can be used when the
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.
30
Rapid Application Development
(RAD) Model

Makes heavy use of reusable software components with an

extremely short development cycle
RAD model
 Communication – to understand business problem.
 Planning – multiple s/w teams works in parallel on diff.
system.
 Modeling –
 Business modeling – Information flow among
business is working.
Ex. What kind of information drives?
Who is going to generate information?
From where information comes and goes?
 Data modeling – Information refine into set of data
objects that are needed to support business.
 Process modeling – Data object transforms to
information flow necessary to implement business.
 Construction – it highlighting the use of pre-existing
software component.
 Deployment – Deliver to customer basis for
subsequent iteration.
 RAD model emphasize a short development cycle.
 “High speed” edition of linear sequential model.
 If requirement are well understood and project scope is
constrained then it enable development team to create “
fully functional system” within a very short time period.
RAD Model

 If application is modularized (“Scalable Scope”), each

major function to be completed in less than three
months.
 Each major function can be addressed by a separate
team and then integrated to form a whole.
Drawback:
 For large but scalable projects
 RAD requires sufficient human resources
 Projects fail if developers and customers are not
committed in a much shortened time-frame
 Problematic if system can not be modularized
 Not appropriate when technical risks are high ( heavy
use of new technology)
Evolutionary Process Model
 Produce an increasingly more
complete version of the software with
each iteration.
 Evolutionary Models are iterative.
 Evolutionary models are:
 Prototyping
 Spiral Model
 Concurrent Development Model
 Fourth Generation Techniques (4GT)
Evolutionary Process Models :
Prototyping
Prototyping
 Best approach when:
 Objectives defines by customer are general but does not have details like
input, processing, or output requirement.
 Developer may be unsure of the efficiency of an algorithm, O.S., or the
form that human machine interaction should take.
 It can be used as standalone process model.
 Model assist software engineer and customer to better understand what is to
be built when requirement are fuzzy.
 Prototyping start with communication, between a customer and software
engineer to define overall objective, identify requirements and make a
boundary.
 Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
 Quick design leads to prototype construction.
 Prototype is deployed and evaluated by the customer/user.
 Feedback from customer/end user will refine requirement and that is how
iteration occurs during prototype to satisfy the needs of the customer.
Prototyping (cont..)
 Prototype can be serve as “the first system”.
 Both customers and developers like the prototyping paradigm.
 Customer/End user gets a feel for the actual system
 Developer get to build something immediately.

Problem Areas:
 Customer cries foul and demand that “a few fixes” be applied to make
the prototype a working product, due to that software quality suffers as
a result.
 Developer often makes implementation in order to get a prototype
working quickly without considering other factors in mind like OS,
Programming language, etc.

Customer and developer both must be agree that the prototype is built to
serve as a mechanism for defining requirement.
The Spiral

39
What is it?
 The Spiral Development ( or Lifecycle)
Model is a systems development method
used in information technology.
 It combines the features of the
prototyping model and the waterfall
model.
 It is favored for large, expensive, and
complicated models.

40
Steps of the Spiral Model
1. Define the problem with as much detail
as possible by interviewing the client
and potential users of the system, as
well as, studying any existing system.
2. A preliminary design is created for the
new system.
3. A first prototype of the new system is
constructed from the preliminary
design and is a scaled down version of
the final product.
41
Steps of the Spiral Model
4. A second prototype is derived by the
following procedure
 Evaluate the first prototype for
strengths, weaknesses and risks
 Define the requirements of the 2nd
prototype
 Plan and design the 2nd prototype
 Construct and test the 2nd prototype

42
Steps of the Spiral Model
5. At this point the customer may
decide to scrap the whole project if
the risk is too high.
 Development cost overruns
 Operating-cost miscalculation
 Other factors that might result in a
substandard product

43
Steps of the Spiral Model
6. Evaluate the current prototype in the
same way as the previous prototype
and create another one if needed
7. Iterate the proceeding steps until the
customer is satisfied that the current
prototype represents the final
product.
8. Construct the final system

44
Steps of the Spiral Model
9. The final system is thoroughly
evaluated and tested and routine
maintenance is carried out for the
life of the product.

45
Advantages
 Estimates of the budget and schedule become
more realistic as work progresses because of the
questions that have been raised
 Easier to cope with the changes inherent to
software development
 Software engineers can start working on the
project earlier rather than wading through a
lengthy early design process.
 Re-evaluation after each step allows changes in
user perspectives, technology advances, or
financial perspectives
 Estimation of budget and schedule gets realistic
as the work progressses

46
Disadvantages
 Estimates of budget and time are
harder to judge at the beginning of
the project since the requirements
evolve through the process

47
When to use Spiral model:
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because
of potential changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and
exploration)

48
Thank You