The WINWIN Spiral Model

The spiral model suggests a framework activity that addresses customer communication.

 The objective of this activity is to elicit project requirements from the customer.

 In an ideal context, the developer simply asks the customer what is required and

the customer provides sufficient detail to proceed. Unfortunately, this rarely happens.

In reality, the customer and the developer enter into a process of negotiation,

 where the customer may be asked to balance functionality,

performance, and other product or system characteristics against cost and

time to market.

The best negotiations strive for a “win-win” result. That is, the customer wins by

getting the system or product that satisfies the majority of the customer’s needs and

the developer wins by working to realistic and achievable budgets and deadlines.

Boehm’s WINWIN spiral model  defines a set of negotiation activities at

the beginning of each pass around the spiral. Rather than a single customer communication

activity, the following activities are defined:

1. Identification of the system or subsystem’s key “stakeholders.”

2. Determination of the stakeholders’ “win conditions.”

3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of

win-win conditions for all concerned (including the software project team).

Successful completion of these initial steps achieves a win-win result, which becomes

the key criterion for proceeding to software and system definition.

In addition to the emphasis placed on early negotiation, the WINWIN spiral model

introduces three process milestones, called anchor points , that help establish

the completion of one cycle around the spiral and provide decision milestones

before the software project proceeds.

In essence, the anchor points represent three different views of progress as the

project traverses the spiral. The first anchor point, life cycle objectives (LCO), defines

a set of objectives for each major software engineering activity. For example, as part

of LCO, a set of objectives establishes the definition of top-level system/product

requirements. The second anchor point, life cycle architecture (LCA), establishes objectives

that must be met as the system and software architecture is defined. For example,

as part of LCA, the software project team must demonstrate that it has evaluated

the applicability of off-the-shelf and reusable software components and considered

their impact on architectural decisions. Initial operational capability (IOC) is the third

anchor point and represents a set of objectives associated with the preparation of the

software for installation/distribution, site preparation prior to installation, and assistance

required by all parties that will use or support the software.

The Spiral Model

The spiral model, originally proposed by Boehm , is an evolutionary software

process model that couples the iterative nature of prototyping with the controlled and

systematic aspects of the linear sequential model. It provides the potential for rapid

development of incremental versions of the software. Using the spiral model, software

is developed in a series of incremental releases. During early iterations, the

incremental 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 number of framework activities, also called task

regions.6 Typically, there are between three and six task regions. A spiral model

 that contains six task regions:

• Customer communication—tasks required to establish effective communication

between developer and customer.

• Planning—tasks required to define resources, timelines, and other projectrelated

information.

• Risk analysis—tasks required to assess both technical and management

risks.

• Engineering—tasks required to build one or more representations of the

application.

• Construction and release—tasks required to construct, test, install, and

provide user support (e.g., documentation and training).

• Customer evaluation—tasks required to obtain customer feedback based

on evaluation of the software representations created during the engineering

stage and implemented during the installation stage.

Each of the regions is populated by a set of work tasks, called a task set, that are

adapted to the characteristics of the project to be undertaken. For small projects, the

number of work tasks and their formality is low. For larger, more critical projects,

each task region contains more work tasks that are defined to achieve a higher level

of formality

.

As this evolutionary process begins, the software engineering team moves around

the spiral in a clockwise direction, beginning at the center. 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 customer evaluation. In addition, the project manager adjusts

the planned number of iterations required to complete the software.

Unlike classical process models that end when software is delivered, the spiral

model can be adapted to apply throughout the life of the computer software. An alternative

view of the spiral model can be considered by examining the project entry point

axis. Each cube placed along the axis can be used to represent

the starting point for different types of projects. A “concept development

project” starts at the core of the spiral and will continue (multiple iterations occur

along the spiral path that bounds the central shaded region) until concept development

is complete. If the concept is to be developed into an actual product, the process

proceeds through the next cube (new product development project entry point) and

a “new development project” is initiated. The new product will evolve through a number

of iterations around the spiral, following the path that bounds the region that has

somewhat lighter shading than the core. 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 .

The spiral model is a realistic approach to the development of large-scale systems

and software. Because software evolves as the process progresses, the developer and

customer better understand and react to risks at each evolutionary level. The spiral model

uses prototyping as a risk reduction mechanism but, more important, enables the developer

to apply the prototyping approach at any stage in the evolution of the product. It

maintains the systematic stepwise approach suggested by the classic life cycle but incorporates

it into an iterative framework that more realistically reflects the real world. The

spiral model demands a direct consideration of technical risks at all stages of the project

and, if properly applied, should reduce risks before they become problematic.

But like other paradigms, the spiral model is not a panacea. It may be difficult to

convince customers (particularly in contract situations) that the evolutionary approach

is controllable. It demands considerable risk assessment expertise and relies on this

expertise for success. If a major risk is not uncovered and managed, problems will

undoubtedly occur. Finally, the model has not been used as widely as the linear

sequential or prototyping paradigms. It will take a number of years before efficacy of

this important paradigm can be determined with absolute certainty.

The Incremental Model

The incremental model combines elements of the linear sequential model (applied

repetitively) with the iterative philosophy of prototyping.  the

incremental model applies linear sequences in a staggered fashion as calendar time

progresses. Each linear sequence produces a deliverable “increment” of the software

. 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 review). 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.

The incremental process model, like prototyping  and other evolutionary

approaches, is iterative in nature. But unlike prototyping, the incremental

model focuses on the delivery of an operational product with each increment. Early

increments are stripped down versions of the final product, but they do provide capability

that serves the user and also provide a platform for evaluation by the user.

Incremental development is particularly useful when staffing is unavailable for a

complete implementation by the business deadline that has been established for the

project. Early increments can be implemented with fewer people. If the core product

is well received, then additional staff (if required) can be added to implement the next

increment. In addition, increments can be planned to manage technical risks.

 For example, a major system might require the availability of new hardware that is under

development and whose delivery date is uncertain. It might be possible to plan early

increments in a way that avoids the use of this hardware, thereby enabling partial

functionality to be delivered to end-users without inordinate delay.

Rapid application development (RAD)

Rapid application development (RAD) is an incremental software development process

model that emphasizes an extremely short development cycle. The RAD model is a

“high-speed” adaptation of the linear sequential model in which rapid development

is achieved by using component-based construction. If requirements are well understood

and project scope is constrained, the RAD process enables a development team

to create a “fully functional system” within very short time periods (e.g., 60 to 90 days)

. Used primarily for information systems applications, the RAD approach

encompasses the following phases :

Business modeling. The information flow among business functions is modeled in

a way that answers the following questions: What information drives the business

process? What information is generated? Who generates it? Where does the information

go? Who processes it?

Data modeling. The information flow defined as part of the business modeling phase

is refined into a set of data objects that are needed to support the business. The char-

acteristics (called attributes) of each object are identified and the relationships between

these objects defined.

Process modeling. The data objects defined in the data modeling phase are transformed

to achieve the information flow necessary to implement a business function.

Processing descriptions are created for adding, modifying, deleting, or retrieving a

data object.

Application generation. RAD assumes the use of fourth generation techniques

(Section 2.10). Rather than creating software using conventional third generation

programming languages the RAD process works to reuse existing program components

(when possible) or create reusable components (when necessary). In all cases,

automated tools are used to facilitate construction of the software.

Testing and turnover. Since the RAD process emphasizes reuse, many of the program

components have already been tested. This reduces overall testing time. However,

new components must be tested and all interfaces must be fully exercised.

Model.  Obviously, the 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 three months (using the approach described previously), it is a candidate

for RAD. Each major function can be addressed by a separate RAD team and then

integrated to form a whole.

Like all process models, the RAD approach has drawbacks:

• For large but scalable projects, RAD requires sufficient human resources to

create the right number of RAD teams.

• RAD requires developers and customers who are committed to the rapid-fire

activities necessary to get a system complete in a much abbreviated time

frame. If commitment is lacking from either constituency, RAD projects will

fail.

• Not all types of applications are appropriate for RAD. If a system cannot be

properly modularized, building the components necessary for RAD will be

problematic. If high performance is an issue and performance is to be

achieved through tuning the interfaces to system components, the RAD

approach may not work.

• RAD is not appropriate when technical risks are high. This occurs when a new

application makes heavy use of new technology or when the new software

requires a high degree of interoperability with existing computer programs.

 

Prototype Model

Often, a customer defines a set of general 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, the adaptability 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.5) begins with requirements gathering. Developer
and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is
mandatory. A "quick design" then occurs. The quick design focuses on a representation
of those aspects of the software that will be visible to the customer/user (e.g.,
input approaches and output formats). The quick design leads to the construction of
a prototype. The prototype is evaluated by the customer/user and used to refine
requirements for the software to be developed. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer, while at the same time enabling the developer
to better understand what needs to be done.

Ideally, the prototype serves as a mechanism for identifying software requirements.
If a working prototype is built, the developer attempts to use existing program fragments
or applies tools (e.g., report generators, window managers) that enable working
programs to be generated quickly.

 

But what do we do with the prototype when it has served the purpose just
described? Brooks [BRO75] provides an answer:
In most projects, the first system built is barely usable. It may be too slow, too big, awkward
in use or all three. There is no alternative but to start again, smarting but smarter, and build
a redesigned version in which these problems are solved . . . When a new system concept
or new technology is used, one has to build a system to throw away, for even the best planning
is not so omniscient as to get it right the first time. The management question, therefore,
is not whether to build a pilot system and throw it away. You will do that. The only
question is whether to plan in advance to build a throwaway, or to promise to deliver the
throwaway to customers . . .
The prototype can serve as "the first system." The one that Brooks recommends
we throw away. But this may be an idealized view. It is true that both customers and
developers like the prototyping paradigm. Users get a feel for the actual system and
developers get to build something immediately. Yet, prototyping can also be problematic
for the following reasons:

1. The customer sees what appears to be a working version of the software,
unaware that the prototype is held together “with chewing gum and baling
wire,” unaware that in the rush to get it working no one has considered overall
software quality or long-term maintainability. When informed that the
product must be rebuilt so that high levels of quality can be maintained, the
customer cries foul and demands that "a few fixes" be applied to make the
prototype a working product. Too often, software development management
relents.

2. The developer often makes implementation compromises in order to get a
prototype working quickly. An inappropriate operating system or programming
language may be used simply because it is available and known; an
inefficient algorithm may be implemented simply to demonstrate capability.
After a time, the developer may become familiar with these choices and forget
all the reasons why they were inappropriate. The less-than-ideal choice
has now become an integral part of the system.

Although problems can occur, prototyping can be an effective paradigm for software
engineering. The key is to define the rules of the game at the beginning; that is,
the customer and developer must both agree that the prototype is built to serve as a
mechanism for defining requirements. It is then discarded (at least in part) and the
actual software is engineered with an eye toward quality and maintainability.