PRESCRIPTIVE PROCESS MODELS

• They prescribe a set of process elements—framework activities,

software engineering actions, tasks, work products, quality assurance,
and change control mechanisms for each project.

• Each process model also prescribes a process flow (also called a work
flow)—that is, the manner in which the process elements are
interrelated to one another
 WATERFALL MODEL

• There are times when the requirements for a problem are well understood—when
work flows from communication through deployment in a reasonably linear fashion.

• The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification
of requirements and progresses through planning, modeling, construction, and
deployment, culminating in ongoing support of the completed software (Figure 2.3).
Among the problems that are sometimes encountered when the waterfall model is
applied are:
1. Real projects rarely follow the sequential flow that the model proposes. Although
the linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds
2. It is often difficult for the customer to state all requirements explicitly. The waterfall
model requires this and has difficulty accommodating the natural uncertainty that exists at
the beginning of many projects.

3. The customer must have patience. A working version of the program(s) will not be
available until late in the project time span. A major blunder, if undetected until the working
program is reviewed, can be disastrous.
 V-MODEL

• A variation in the representation of the waterfall model is called the V-model.

Represented in Figure 2.4, the V-model depicts the relationship of quality
assurance actions to the actions associated with communication,
modeling, and early construction activities.
• As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and technical
representations of the problem and its solution.
• Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that
validate each of the models created as the team moved down the left side.
• In reality, there is no fundamental difference between the classic life cycle and
the V-model. The V-model provides a way of visualizing how verification and
validation actions are applied to earlier engineering work.
 INCREMENTAL PROCESS MODELS
• There may be a compelling need to provide a limited set of software functionality to users
quickly and then refine and expand on that functionality in later software releases.
• For example, word-processing software developed using the incremental paradigm might
deliver basic file management, editing, and document production functions in the first
increment; more sophisticated editing and document production capabilities in the second
increment; spelling and grammar checking in the third increment; and advanced page
layout capability in the fourth increment.
• It should be noted that the process flow for any increment can incorporate the prototyping
Paradigm.
• When an incremental model is used, the first increment is often a core product. That is,
basic requirements are addressed but many supplementary features (some known, others
unknown) remain undelivered. The core product is used by the customer (or undergoes detailed
evaluation). As a result of use and/or evaluation, a plan is developed for the next
increment.
• The plan addresses the modification of the core product to better meet the needs
of the customer and the delivery of additional features and functionality. This process is
repeated following the delivery of each increment, until the complete product is
produced.

• Incremental development is particularly useful when staffing is unavailable for a

complete implementation by the business deadline that has been established for the
project.
 Evolutionary Process Models

• Process model that has been explicitly designed to accommodate a product that evolves
over time.

• Evolutionary models are iterative.

• They are characterized in a manner that enables you to develop increasingly more
complete versions of the software.
 PROTOTYPING
• Often, a customer defines a set of general objectives for software, but does not
identify detailed requirements for functions and features.
• In other cases, the developer may be unsure of the efficiency of an algorithm,
the adapt ability of an operating system, or the form that human-machine
interaction should take.
• In these, and many other situations, a prototyping paradigm may offer the best
approach. The prototyping paradigm (Figure 2.6) begins with communication.
• You meet with other stakeholders to define the overall objectives for the software,
identify whatever requirements are known, and outline areas where further
definition is mandatory.
A prototyping iteration is planned quickly, and modeling (in the form of a “quick
design”) occurs. A quick design focuses on a representation of those aspects of the
software that will be visible to end users (e.g., human interface layout or output
display formats).

The quick design leads to the construction of a prototype. The prototype is

deployed and evaluated by stakeholders, who provide feedback that is used to
further refine requirements.

Iteration occurs as the prototype is tuned to satisfy the needs of various

stakeholders, while at the same time enabling you to better under stand what needs
to be done.

Although some prototypes are built as “throwaways,” others are evolutionary in

the sense that the prototype slowly evolves into the actual system.
 The Spiral Model
• Originally proposed by Barry Boehm, 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 provides the potential for rapid development of increasingly more complete versions of
the software.
• Using the spiral model, software is developed in a series of evolutionary releases.
• During early iterations, the release might be a 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 defined by the software
engineering team. For illustrative purposes, the generic framework activities.
• Each of the framework activities represent one segment of the spiral path illustrated in
Figure 2.7. 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.
• In addition, the project manager adjusts the planned number of iterations required to
complete the software. The spiral model can be adapted to apply throughout the life of the
computer software.
• Therefore, the first circuit around the spiral might represent a “concept development
project” that starts at the core of the spiral and continues for multiple iterations until
concept development is complete.
• If the concept is to be developed into an actual product, the process proceeds
outward on the spiral and a “new product development project” commences.

• The new product will evolve through a number of iterations around the spiral.
Later, a circuit around the spiral might be used to represent a “product
enhancement project.” In essence, the spiral, when characterized in this way,
remains operative until the software is retired.

• There are times when the process is dormant, but whenever a change is
initiated, the process starts at the appropriate entry point (e.g., product
enhancement).
 Concurrent Models
• Figure 2.8 provides a schematic representation of one software engineering activity
within the modeling activity using a concurrent modeling approach. The activity—
modeling—may be in any one of the states noted at any given time.
• Similarly, other activities, actions, or tasks (e.g., communication or construction) can be
represented in an analogous manner.
• All software engineering activities exist concurrently but reside in different states.
• For example, early in a project the communication activity (not shown in the figure) has
completed its first iteration and exists in the awaiting changes state. The modeling
activity which existed in the inactive state while initial communication was completed,
now makes a transition into the under development state.
• If, however, the customer indicates that changes in requirements must be made, the
modeling activity moves from the under development state into the awaiting changes
state.
• Concurrent modeling defines a series of events that will trigger transitions
from state to state for each of the software engineering activities, actions, or
tasks.
• For example, during early stages of design (a major software engineering action
that occurs during the modeling activity), an inconsistency in the requirements
model is uncovered.
• This generates the event analysis model correction, which will trigger the
requirements analysis action from the done state into the awaiting changes
state.