Process Models

Perspective Process Models

 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
 Prescriptive Process Models
• Prescriptive process models organize framework activities in a
certain order
• Software engineer choose process framework that includes
activities like;
– Communication
– Planning
– Modeling
– Construction
– Deployment
• Calling this model as “Prescribe” because it recommend a set
of process elements, activities, action task, work product &
quality.
Waterfall Model / Classic Life Cycle
 Waterfall Model or Classic Life
Cycle
• It suggests a systematic, sequential approach to software
development that begins with customer specification of
requirements and progress through
=> Planning
=> Modeling
=> Construction and
=> Deployment
• Requirement Analysis and Definition
• Scheduling tracking
• System and Software Design
• Integration and system testing
• Operation and Maintenance
V-model

• Variation in the representation of waterfall model is

called the V-model.
• It depicts the relationship of quality assurance to
actions in framework activities.
• Software team moves down of left side of V and
team moves up right side of V
• V-model provides a way of visualizing the verification
and validation actions are applied.
V-model
 Limitations of the waterfall model
• Real projects rarely follow the sequential flow. As a
result changes cause confusion as the project team
proceeds
• It is difficult for the customer to state all requirements
explicitly
• The customer must have patience
• The linear nature of the water fall model leads to
“ Blocking State” in which some project team
members must wait for other members of the team to
complete dependent task
• The water fall model can serve as a useful process model
in situations where => Requirements are fixed and work
is to proceed to completion in a linear manner
 Incremental Process Model

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
Cont…
• It is particularly useful when enough staffing is not
available for the whole project
• Increment can be planned to manage technical risks, and
focus more on delivery of operation product with each
increment.
• User requirements are prioritised and the highest
priority requirements are included in early increments.
• 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.
 Evolutionary Process Models
• Like all computer systems software also evolve over a period
of time
• Suppose if a set of core product (or) system requirement is
well understood, but the details of product (or) system
extensions have not yet to be defined.
• These case, a software engineer needs a process model that
has been designed to accommodate a product that evolves
over time.
• The evolutionary process models are iterative, it enables to
develop increasingly more complete versions of the software.
• There are two common Evolutionary process models.
Prototyping
 Prototyping
• The prototype model may offer the best approach, if
=> Customer defines a set of objectives for software, but does
not identify detailed input, processing (or) output
requirements
=> In other cases, the developer may be unsure of the
efficiency of an algorithm (or) the form that human-machine
interaction should take
Communication:
• The prototype model begins with communication
• The software engineer and customer meet and define the
overall objectives for the software
=> Identify what ever requirements are known
=> Outline areas where further definition is mandatory
cont..
Quick design:
•The quick design focuses on a representation of those aspects
of the software that will be visible to the customer / end user
Example:
•Human interface Layout (or) Output display formats
Construction :
• Ideally the prototype serves as a mechanism for identifying
software requirements
• If the working prototype is built, the developer uses the
existing programs fragments that ensure working programs to
be generated quickly
cont..
Deployment:
• The prototype is deployed and evaluated by the customer
• Feedback is used to refine requirements for the software

Both customers and developers like the prototyping paradigm.

 Customer/End user gets a feel for the actual system
 Developer get to build something immediately.
Evolutionary Model: Spiral Model
 Spiral Model
• Introduced by Barry Boehm is a risk driven process model.
• It is evolutionary software process model that combines the
iterative nature of prototyping with the controlled and
systematic aspect of the water fall model
• Using spiral, software developed as series of evolutionary
release.
– Early iteration, release might be on paper or prototype.
– Later iteration, more complete version of software.
Two main features
1. A cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing
its degree of risk
2. An anchor point mile stones for ensuring stake holders
commitment to feasible and mutually satisfactory system
solutions
Cont…
• Evolutionary process begins in a clockwise direction,
beginning at the center risk.
• First circuit around the spiral might result in
development of a product specification. Subsequently,
develop a prototype and then progressively more
sophisticated version of software.
• Cost and Schedule are adjusted based on feedback
derived from the customer after delivery.
• Unlike other process models that end when software is
delivered, It can be adapted to apply throughout the life
of software.
Spiral Model
Cont..
Concept Development Project:
• Start at the core and continues for multiple iterations until it is
complete.
• If concept is developed into an actual product, the process
proceeds outward on the spiral.
New Product Development Project:
• New product will evolve through a number of iterations around the
spiral.
• Later, a circuit around spiral might be used to represent a “Product
Enhancement Project”
Product Enhancement Project:
• There are times when process is dormant or software team not
developing new things but change is initiated, process start at
appropriate entry point.
 Unified Processes
• The unified process emphasizes the important
role of software architecture and help the
architect focus on,
-Right goals
-Understandability
-Reliance to future changes
-Reuse
• It suggests a process flow that is iterative and
incremental providing the evolutionary feel
Unified Processes Model
(1) Inception Phase:
• This phase combines both customer communication and
planning activities
• By combining these the
=> Business requirements for the software are
identified
=> A rough architecture for the system is proposed
=> A plan for the iterative, incremental nature of
ensuring project is developed
• In general a use-case describes a sequence of actions
that are performed by an actor [e.g. a person, a machine]
• Use-case helps to identify the scope of the project and
provide a basis for project planning
(2) Elaboration Phase:
• It refines and expands the preliminary use-cases that
were developed on inception phase
• It expands the architectural representation to include
five different views of the software:
=> Use-case model
=> Analysis Model
=> Design Model
=> Implementation Model
=> Deployment Model
• The modification to the plan may be made at this
time
(3) Construction Phase:

• This phase develops (or) acquires the software

components that will make each use-case
operational for end users
• All necessary and required features and functions of
software release are implemented in source code
• After implementing components, unit tests are
designed and executed for each.
• Integration activities are conducted.
(4) Transition Phase:

• The software is given to end-users for Beta testing

• The users feedback reports both defects and
necessary changes
• This phase allow software team creates the
necessary support information
Example:
=> User Manuals
=> Trouble shooting guides
=> Installation procedures
(5) Production Phase:

• During these phase the

=> On going use of the software is monitored
=> Support for the operating environment
[infrastructure] is provided
=> Defect reports and requests for changes
are submitted and evaluated
THANK YOU