Software Process Models

A software process model is a simplified description of a software process which is

presented from a particular perspective. Models, by their very nature, are
simplifications so a software process model is an abstraction of the actual process
which is being described. Process models may include activities which are part of
the software process, software products and the roles of people involved in software
engineering.

Process model
What is it?
They define a distinct set of activities, actions, tasks, milestones, and work products that are
required to engineer high-quality software
They are not perfect but they provide a useful roadmap for SW engineering work
Who does it?
SW engineers, and their managers adopts it, also the people who requested the software
Why it is important?
They are important because they provide stability, control, and organization to an activity that
can, if left uncontrolled, become quite chaotic
What are the steps?
The process guides a SW team through a set of framework activities that are organized into a
process flow that may be linear, incremental, or evolutionary
What is the work product?
The work products are the programs, documents, and data that are produced as a consequence
of the activities and tasks defined by the process
How do I ensure that I have done it right?
The quality, timeliness, and long term viability of the product you build are the best indicators
of the efficacy of the process that you use
Prescriptive Models
Every SW engineering organization should describe a unique set of framework activities for
the SW process it adopts
Each framework activity is populated with a set of SW engineering actions
Each action is defined in terms of a task set that identifies the work (and work products) to be
accomplished to meet development goals
Resultant process model is adapted to accommodate specific nature of each project, people
who do the work, environment in which work is conducted
SW engineers have traditionally chosen a generic process framework that encompasses the
following framework activities: communication, planning, modeling, construction, and
deployment
All SW process models can accommodate the generic framework activities, but each applies a
different emphasis to these activities and defines a workflow that invokes each framework
activity in a different manner
The Waterfall Model

Used when requirements well understood, when work flows from communication
through deployment in a reasonably linear fashion

Waterfall model, sometimes called classic life cycle, suggests a systematic, sequential
approach to software development that begins with customer specification of requirements and
progresses through various phases, culminating in on-going support of the completed software
Problems with Waterfall Model

Real projects rarely follow the sequential flow that the model proposes

It is often difficult for the customer to state all requirements explicitly

The customer must have patience. A working version of the program will not be
available until late in the project time-span

The Incremental process Models

They are used when initial requirement are reasonably well-defined but the over all scope
precludes a purely linear process , and need to provide software functionality to user quickly
The Incremental Model

It combines elements of the waterfall model applied in an iterative fashion

It delivers a series of releases, called increments, that provide progressively more

functionality for customer as each increment is delivered

When it is used, the first increment is often a core product. That is, basic requirements
are addressed, but many supplementary features remain undelivered

The core product is used by customer. As a result, a plan is developed for next
increment

Unlike prototyping, the incremental model focuses on the delivery of an operational

product with each increment

Incremental development is particularly useful when staffing is unavailable for a

complete implementation by the business deadline. Early increments can be implemented with
fewer people, and additional staff can be added to later increments

Increments can be planned to manage technical risks

The RAD Model
Rapid application development is a software development methodology, which involves iterative
development and the construction of prototypes. It is a merger of various structured techniques,
especially the data driven Information Engineering with prototyping techniques to accelerate software
systems development
The main objective of Rapid Application Development is to avoid extensive pre-planning, generally
allowing software to be written much faster and making it easier to change requirements. The Rapid
Application Development methodology was developed to respond to the need to deliver systems very
fast. The RAD approach is not appropriate to all projects - an air traffic control system based on RAD
would not instill much confidence. Project scope, size and circumstances all determine the success of a
RAD approach. The following categorize indicates suitability for a RAD approach:
PROJECT SCOPE
Suitable for RAD - Focused scope where the business objectives are well defined and narrow.
Unsuitable for RAD - Broad scope where the business objectives are obscure or broad.
PROJECT DATA
Suitable for RAD - Data for the project already exists (completely or in part). The project largely
comprises analysis or reporting of the data.
Unsuitable for RAD - Complex and voluminous data must be analyzed, designed and created within
the scope of the project.
PROJECT DECISIONS
Suitable for RAD - Decisions can be made by a small number of people who are available and
preferably co-located.
Unsuitable for RAD - Many people must be involved in the decisions on the project, the decision
makers are not available on a timely basis or they are geographically dispersed.
PROJECT TEAM
Suitable for RAD - The project team is small (preferably six people or less).
Unsuitable for RAD - The project team is large or there are multiple teams whose work needs to be
coordinated.

RAD is an incremental SW process model that emphasizes a short development cycle

RAD model is a high-speed adaptation of the waterfall model, in which rapid
development is achieved by using a component-based construction approach

If requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a fully functional system within a very short time
period

Time constraints imposed on a RAD project demand scalable scope

If a business application can be modularized in a way that enables each major function
to be completed in less than 3 months, it is a candidate for RAD

Each major function can be addressed by a separate RAD team and then integrated to
form a whole
Drawback of RAD
1. For large, but scalable projects, RAD requires sufficient human resources to create right
number of RAD teams
2. If developers and customers are not committed to the rapid-fire activities necessary, RAD
projects will fail
3. If a system cannot be properly modularized, building the components necessary for RAD will
be problematic
4. RAD may not be appropriate when technical risks are high

Evolutionary Process Models

Evolutionary models are iterative. They are characterized in a manner that enables SW
engineers to develop increasingly more complete versions of the software
Evolutionary Models: Prototyping

Although it can be used as a standalone process model, it is more commonly used as a

technique that can be implemented within the context of other process models

The prototyping paradigm assists the SW engineer and the customer to better
understand what is to be built when requirements are fuzzy(customer identify general objective
but not defines the details of input ,processing , and processing so the developer becomes
unsure about efficiency , algorithms and so on to solve this problem prototype is used )

Ideally, the prototype serves as a mechanism for identifying SW requirement

Drawbacks of Prototyping

The customer sees what appears to be a working version of SW, unaware that in the
rush to get it working we havent considered overall quality or long-term maintainability

The developer often makes implementation compromises in order to get prototype

working quickly
The Spiral
It is an evolutionary SW process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model
It is a risk-driven process model generator that is used to guide multi-stakeholder concurrent
engineering of SW intensive systems
Using this model software is developed in a series of evolutionary releases. The releases might
be paper model, or prototype.
The model is divided into a set of framework activities defined by SE team
It has distinguishing features: (1) A cyclic approach for incrementally growing the systems
degree of definition & implementation while decreasing its degree of risk, (2) a set of anchor
point milestones(combination of work product and conditions that are attained along the path
of the spiral)
Unlike other models that ends when software delivered, but it can be adapted to apply through
out the life of software. So the first circle represents "concept development project", the later
represents "new product development" and "product enhancement"

 It a realistic model that can be used to be used to develop large scale system and software
Problems with Spiral Model

Difficult to convince customers that evolutionary approach is controllable

Demands considerable risk assessment expertise and relies on this expertise for success

If major risks are uncovered and managed, problems will occur

Specialized process models
Component based development
the process to apply when reuse is a development objective
o CBM incorporate the following steps
o Available component product are researched and evaluated for the application domain
in the question
o Component integration issue are considered
o Software architecture is designed to accommodate the component
o Component are integrated with the architecture
o Comprehensive testing is conducted to ensure proper functionality
Formal methods
o It emphasizes the mathematical specification of requirements
o The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software.
o Formal methods enable a software engineer to specify, develop, and verify a computerbased system by applying a rigorous, mathematical notation. A variation on this
approach, called cleanroom software engineering [MIL87, DYE92], is currently applied
by some software development organizations.
o Although it is not destined to become a mainstream approach, the formal methods
model offers the promise of defect-free software. Yet, the following concerns about its
applicability in a business environment have been voiced:
1. The development of formal models is currently quite time consuming and
expensive.
2. Because few software developers have the necessary background to apply
formal methods, extensive training is required.
3. It is difficult to use the models as a communication mechanism for
technically
unsophisticated customers.