UNIT-II

PROCESS MODELS
Process Models help in the software development

They Guide the software team through a set of framework activities

Process Models may be linear, incremental or evolutionary

THE WATERFALL MODEL

Used when requirements are well understood in the beginning

Also called classic life cycle model.

A systematic, sequential approach to Software development

Begins with customer specification of Requirements and progresses through planning,

modeling, construction and deployment

Disadvantages:

Real projects rarely follow the sequential flow since they are always iterative

The model requires requirements to be explicitly spelled out in the beginning, which is
often difficult

A working model is not available until late in the project time span.

THE INCREMENTAL PROCESS MODEL

Linear sequential model is not suited for projects which are iterative in nature

Incremental model suits such projects

Used when initial requirements are reasonably well-defined and compelling need to
provide limited functionality to users quickly and then refine and expand on that
functionality in later releases

It combines elements of waterfall model in an iterative fashion.

The incremental model applies linear sequences in a staggered ashion as calendar time
progresses.Each linear sequence provides deliverable increments of software.For ex word
processing sotware developed sing incremental paradigm might deliver basic file
management,editing,and document production functions in 1st increment ;more sophisticated
editing and document production capabilities in 2nd increment;spelling and grammar
checking in 3rd increment; etc

1st increment constitutes Core product

 Basic requirements are addressed

Core product undergoes detailed evaluation by the customer

As a result, plan is developed for the next increment Plan addresses the modification of
core product to better meet the needs of customer

Process is repeated until the complete product is produced

The incremental process model unlike prototyping and other evolutionary approaches,is
iterative in nature.But unlike prototyping,the incremental model focuses on delivery of an
operational product with each increment.

This model is particularly useul when staffing is unavailable for a complete implementation
by business deadline that has been established for the project.

THE RAD MODEL

(Rapid Application Development)

Rapid Application Development (RAD) is an incremental software process model that emphasizes
a short development cycle.

RAD is a high-speed adaptation of the waterfall model, in which rapid development is

achieved by using a component based construction approach. Creates a fully functional
system within a very short span time of 60 to 90 days.

Multiple software teams work in parallel on different functions

Modeling encompasses three major phases: Business modeling, Data modeling and
process modeling

Construction uses reusable components, automatic code generation and testing

Problems in RAD

Requires a number of RAD teams

Requires commitment from both developer and customer for rapid-fire completion of
activities otherwise it fails

If system cannot be modularized properly project will fail.

Not suited when technical risks are high

EVOLUTIONARY PROCESS MODEL

Software evolves over a period of time

Business and product requirements often change as development proceeds making a

straight-line path to an end product unrealistic

Evolutionary models are iterative and as such are applicable to modern day applications

Types of evolutionary models

Prototyping
Spiral model
Concurrent development model
1.4.1 Prototyping
Customers often define a set of general objectives for Software, but doesnt identify
detailed input, processing, or input requirements.

Prototyping paradigm assists the Software engineering and the customer to better
understand what is to be built when requirements are fuzzy.
The prototyping paradigm begins with communication where requirements and goals of
Software are defined.

Prototyping iteration is planned quickly and modeling in the form of quick design occurs.

The quick design focuses on a representation of those aspects of the Software that will be
visible to the customer Human interface.

The quick design leads to the Construction of the Prototype.

The prototype is deployed and then evaluated by the customer.

Feedback is used to refine requirements for the Software.

Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while
enabling the developer to better understand what needs to be done.

The prototype can serve as the first system. Both customers and developers like the
prototyping paradigm as users get a feel for the actual system, and developers get to
build Software immediately. Yet, prototyping can be problematic:

1. The customer sees what appears to be a working version of the Software,

unaware that the prototype is held together with chewing gum. Quality,
long-term maintainability. When informed that the product is a prototype,
the customer cries foul and demands that few fixes be applied to make it a
working product. Too often, Software development management relents.
2. The developer makes implementation compromises in order to get a
prototype working quickly. An inappropriate O/S or programming language
used simply b/c its available and known. After a time, the developer may
become comfortable with these choices and forget all the reasons why they
were inappropriate.

The key is to define the rules of the game at the beginning. The customer and the
developer must both agree that the prototype is built to serve as a mechanism for
defining requirements.

1.4.2 The 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 waterfall model.

It has two distinguishing features:

a. A cyclic approach for incrementally growing a systems degree of

definition and implementation while decreasing its degree of risk.
b. A set of anchor point milestones for ensuring stakeholder commitment to
feasible and mutually satisfactory solutions.

Using the spiral model, Software is developed in a series of evolutionary releases.

During early stages, the release might be a paper model or prototype.

During later iterations, increasingly more complete versions of the engineered system
are produced.

A spiral model is divided into a set of framework activities divided by the Software
engineering team.

As this evolutionary process begins, the Software team performs activities that are
implied by a circuit around the spiral in a clockwise direction, beginning at the center.
 Risk is considered as each revolution is made.

Anchor-point milestones a combination of work products and conditions that are

attained along the path of the spiral- are noted for each evolutionary pass.

The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a prototype
and then progressively more sophisticated versions of the Software.

Each pass through the planning region results in adjustments to the project plan. Cost
and schedule are adjusted based on feedback derived from the customer after delivery.

Unlike other process models that end when Software is delivered, the spiral model can
be adapted to apply throughout the life of the Software.

planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback test

1.4.3 The concurrent Development Model

The concurrent development model, sometimes called concurrent engineering, can be
represented schematically as a series of framework activities, Software engineering
actions of tasks, and their associated states.

The concurrent model is often more appropriate for system engineering projects where
different engineering teams are involved.

none

Modeling activity

represents the state

Under of a software engineering
activity or task
development

A waiting
changes

Under review

Under
revision

Baselined

Done
Figure above provides a schematic representation of one Software engineering task within the
modeling activity for the concurrent process model. The activity modeling- may be in any one
of the states noted at any given time.

All activities exist concurrently but reside in different states.

For example, early in the project the communication activity has completed its first iteration and
exists in the awaiting changes state. The modeling activity which existed in the none state while
initial communication was completed now makes a transition into underdevelopment state.

If, however, the customer indicates the changes in requirements must be made, the modeling
activity moves from the under development state into the awaiting changes state.

The concurrent process model defines a series of events that will trigger transitions from state to
state for each of the Software engineering activities, actions, or tasks.

UNIFIED PROCESS MODEL

This model is proposed by ivan jacobson,grady booch,rumbaugh

This is a use-case driven,architecture-centric,iterative and incremental software process.
This is a framework for object-oriented software engineering sing UML.
The inception phase of Unified Process(UP) encompasses oth customer communication
and planning activities.By colloborating with customer,business requirements for the
software are identified.Fundamental business requirements are expressed through a set of
preliminary use-cases that describes what features and functions are desired by major
class of sers. Architecture at this point is nothing but outline of features and
functions.Planning identifies resources,assesses major risks,defines a schedule.
The elaboration phase encompasses communication,planning and modelling.Elaboration
reines and expands preliminary use-cases

that were developed as part of inception phase.Expands architectural representation to

include ive different views of software.the use-case model,the analysis model,the design
model,the implementation model and the deployment model.Modification to the plan may be
made at tis time

Construction of UP is identical to constuction activity of generic process models.All

necessary features and functions are implemented in souce code.As components are
being developed unit test is bein conducted.
The transition phase of UP encompasses later stages of construction activity and first
part of deployment activity.Softwareis given to end-users for beta-testing.In addition
software team creates installation procedres,user manuals etc.
 The prodction phase cooincides with deployment activity .During tis phase on-going
use of software is monitored,and defect reports and request for changes are submitted
and evaluated.

Specialized Process Models

3.5.1 Component Based Development

Commercial off-the-shelf (COTS) Software components, developed by vendors who offer them
as products, can be used when Software is to be built. These components provide targeted
functionality with well-defined interfaces that enable the component to be integrated into the
Software.

The component-based development model incorporates many of the characteristics of the spiral
model.

The component-based development model incorporates the following steps:

Available component-based products are researched and evaluated for the application
domain in question.
Component integration issues are considered.
Software architecture is designed to accommodate the components.
Components are integrated into the architecture.
Comprehensive testing is conducted to ensure proper functionality.

The component-based development model leads to Software reuse, and reusability provides
Software engineers with a number of measurable benefits.

3.5.1 The Formal Methods Model

The Formal Methods Model encompasses a set of activities that leads to formal mathematical
specifications of Software.

Formal methods enable a Software engineer to specify, develop, and verify a computer-based
system by applying a rigorous, mathematical notation.

A variation of this approach, called clean-room Software engineering is currently applied by some
software development organizations.

http://www.sei.cmu.edu/str/descriptions/cleanroom.html

Although not a mainstream approach, the formal methods model offers the promise of defect-
free Software. Yet, concern about its applicability in a business environment has been voiced:

The development of formal models is currently quite time-consuming and expensive.

B/C few software developers have the necessary background to apply formal methods,
extensive training is required.
It is difficult to use the methods as a communication mechanism for technically
unsophisticated customers.

3.5.3 Aspect-Oriented Software Development

Regardless of the software process that is chosen, the builders of complex software invariably
implement a set of localized features, functions, and information content. For further
information read book page 61.

3.6.2 Phases of the Unified Process

The figure below depicts the phases of the UP and relates them to the generic activities.

The Inception phase of the UP encompasses both customer communication and planning
activities.

By collaborating with the customer and end-users, business requirements for the software are
identified, a rough architecture for the system is proposed, and a plan for the iterative,
incremental nature of the ensuing project is developed.

Elaboration

Inception

construction
Release
transition
software increment

production

A use-case describes a sequence of actions that are performed by an actor (person, machine,
another system) as the actor interacts with the Software.

The elaboration phase encompasses the customer communication and modeling activities of the
generic process model. Elaboration refines and expands the preliminary use-cases that were
developed as part of the inception phase and expands the architectural representation to include
five different views of the software - the use-case model, the analysis model, the design model,
the implementation model, and the deployment model.
 The construction phase of the UP is identical to the construction activity defined for the generic
software process.

Using the architectural model as input, the construction phase develops or acquires the software
components that will make each use-case operational for end-users.

The transition phase of the UP encompasses the latter stages of the generic construction activity
and the first part of the generic deployment activity.

Software is given to end-users for beta testing, and user feedback reports both defects and
necessary changes.

At the conclusion of the transition phase, the software increment becomes a usable software
release user manuals, trouble-shooting guides, and installation procedures.)

The production phase of the UP coincides with the development activity of the generic process.

The on-going use of the software is monitored, support for the operating environment is
provided and defect reports and requests for changes are submitted and evaluated.

A Software Engineering workflow is distributed across all UP phases.

UP Phases
Inception Elaboration Construction Transition Production

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n