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
Concurrent Development Model
Fourth Generation Techniques (4GT)
Component based development (CBD)
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.
Advantages
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.
In this model phases are processed and
completed one at a time. Phases do not
overlap.
Waterfall model works well for smaller projects
where requirements are very well understood.
Disadvantages
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.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements
are at a moderate to high risk of changing.
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.
Advantages
Generates working software quickly and early
during the software life cycle.
This model is more flexible less costly to
change scope and requirements.
It is easier to test and debug during a smaller
iteration.
In this model customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are
identified and handled during its 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.
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 cohesive
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.
Evolutionary Model: Spiral
Model
Spiral Model
Couples iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model
It provide potential for rapid development of increasingly more
complete version of the software.
Using spiral, software developed in as series of evolutionary
release.
Early iteration, release might be on paper or prototype.
Later iteration, more complete version of software.
Divided into framework activities (C,P,M,C,D). Each activity
represent one segment.
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.
Unlike other process models that end when software is delivered.
It can be adapted to apply throughout the life of software.
Spiral Model
 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.
 Spiral models uses prototyping as a risk reduction
mechanism but, more important, enables the developer
to apply the prototyping approach at each stage in the
evolution of the product.

It maintains the systematic stepwise approach

suggested by the classic life cycle but also incorporates it
into an iterative framework activity.
If risks cannot be resolved, project is immediately
terminated
Problem Area:
It may be difficult to convince customers (particularly in
contract situations) that the evolutionary approach is
controllable.
If a major risk is not uncovered and managed, problems
will undoubtedly occur.
Agile Model
Agile development model is also a type
of Incremental model.
Software is developed in incremental, rapid
cycles. This results in small incremental
releases with each release building on
previous functionality.
Each release is thoroughly tested to
ensure software quality is maintained. It is
used for time critical applications.
Advantages
Customer satisfaction by rapid, continuous
delivery of useful software.
People and interactions are emphasized rather
than process and tools. Customers, developers
and testers constantly interact with each other.
Working software is delivered frequently (weeks
rather than months).
Face-to-face conversation is the best form of
communication.
Close, daily cooperation between business people
and developers.
Disadvantages
In case of some software deliverables,
especially the large ones, it is difficult to
assess the effort required at the beginning of
the software development life cycle.
There is lack of emphasis on necessary
designing and documentation.
The project can easily get taken off track if
the customer representative is not clear what
final outcome that they want.
Concurrent Development Model
Concurrent Development Model
It represented schematically as series of major technical activities,
tasks, and their associated states.
It is often more appropriate for system engineering projects where
different engineering teams are involved.
The activity-modeling may be in any one of the states for a given
time.
All activities exist concurrently but reside in different states.
E.g.
The analysis activity (existed in the none state while initial
customer communication was completed) now makes a transition
into the under development state.
Analysis activity moves from the under development state into
the awaiting changes state only if customer indicates changes in
requirements.
Series of event will trigger transition from state to state.
E.g. During initial stage there was inconsistency in design which was
uncovered. This will triggers the analysis action from the Done
state into Awaiting Changes state.
Concurrent Development (Cont.)
Visibility of current state of project
It define network of activities
Each activities, actions and tasks on
the network exists simultaneously
with other activities ,actions and
tasks.
Events generated at one point in the
process network trigger transitions
among the states.
Fourth Generation Techniques(4GT)
4GT
Like all other models, 4GT begins with a requirements
gathering phase.
Ideally, the customer would describe the requirements, which
are directly translated into an operational prototype.
Practically, however, the client may be unsure of the
requirements, may be ambiguous in his specs or may be
unable to specify information in a manner that a 4GT tool can
use.
For small applications, it may be possible to move directly from
the requirements gathering phase to the implementation phase
using a nonprocedural fourth generation language.
However for larger projects a design strategy is necessary.
Otherwise, the same difficulties are likely to arise as with
conventional approaches.
4GT
To transform a 4GT implementation into a product, the
developer must conduct thorough testing, develop meaningful
documentation.
In addition, the 4GT developed software must be built in a
manner that enables maintenance to be performed quickly.
Merits:
Dramatic reduction in software development time. (For small
and intermediate application)
Improved productivity for software developers.
Demerits:
Not much easier to use as compared to programming
languages
The maintainability of large software systems built using 4GT is
open to question.
4GT
4GT Software tool is used to generate the source code
for a software system from a high level specification
representation
Commonly used 4GT in development models are
mentioned below:
Report Generation
Data base query language
Data Manipulation
Screen definition and interaction
Code Generation
Web engineering Tools
high-level graphics
Component Based Development
component-based development (CBD) model
incorporates many of the characteristics of the
spiral model.
It is evolutionary by nature and iterative
approach to create software.
CBD model creates applications from
prepackaged software components (called
classes).
CBD Model
CBD model (cont.)
Modeling and construction activities begin with identification of
candidate components.
Classes created in past software engineering projects are
stored in a class library or repository.
Once candidate classes are identified, the class library is
searched to determine if these classes already exist.
If class is already available in library extract and reuse it.
If class is not available in library, it is engineered or developed
using object-oriented methods.
Any new classes built to meet the unique needs of the
application.
Now process flow return to the spiral activity.
CBD model (cont.)
CBD model leads to software
reusability.
Based on studies, CBD model leads to
70 % reduction in development cycle
time.
84% reduction in project cost.
Productivity is very high.