Вы находитесь на странице: 1из 13

Lesson 2


a common mistake people make concerning software is

assuming that the majority of software development is
programming. When they think of programming, their
minds conjure up the image of a late-night hacker
pounding out code on an old computer in the basement of a musty
apartment. While this is certainly one approach to programming, it
is hardly the norm and definitely not the way the majority of current
software is developed. In fact, programming is only a fraction of
the software development process. Today, many other steps are
involved in the successful development and deployment of
computer software. Taken together, all these steps are referred to
as the software life cycle. Often models called software life cycle
models describe these steps. In the next two lessons we will
examine two of these models: the waterfall model and the spiral
model. First, however, we need to describe the basic processes
that make up the software life cycle.

The Meaning of Process

When we provide a service or create a product, whether it be
developing software, writing a report, or taking a business trip, we
always follow a sequence of steps to accomplish a set of tasks. The
tasks are usually performed in the same order each time; for
example, you do not usually put up the drywall before the wiring for
a house is installed or bake a cake before all the ingredients are
mixed together. We can think of a set or ordered tasks as a
process; a series of steps involving activities, constraints, and
resources that produce an intended output of some kind.

A process usually involved a set of tools and techniques. Any

process has the following characteristics:

The process prescribes all of the major process activities.

The process uses resources, subject of a set of constraints
(such as a schedule), and produces intermediate and final
The process may be composed of subprocesses that are
linked in some way. The process may be defined as a
hierarchy of processes, organized so that each subprocess
has its own process model.
Lesson 2: Software Processes

Each process activity has entry and exit criteria, so that

we know when the activity begins and ends.
The activities are organized in a sequence, so that it is
11 clear when one activity is performed relative to the other
Every process has a set of guiding principles that explain
the goals of each activity.
Constraints or controls may apply to an activity, resource,
or product. For example, the budget or schedule may
constrain the length of time an activity may take or a tool
may limit the way in which a resource may be used.

Processes are important because they impose consistency and

structure on a set of activities. These characteristics are useful
when we know how to do something well and we want to ensure
that others do it the same way. Similarly, a software development
process can be described in flexible ways that allow people to
design and build software using preferred techniques and tools; a
process model may require design to occur before coding, but may
allow many different design techniques to be used. For this reason,
the process helps to maintain a level of consistency and quality in
products or services that are produced by many different people.

The process structure guides our actions by allowing us to examine,

understand, control, and improve the activities that comprise the
process. Processes are also important for enabling us to capture
our experiences and pass them along to others. Just as master
chefs pass on their favorite recipes to their colleagues and friends,
master craftspeople can pass along documented processes and
procedures. Indeed, the notions of apprenticeship and mentoring
are based on the idea that we share our experience so we can pass
down our skills from senior people to junior ones.

In the same way, we want to learn from our past development

projects, document development process so we can understand,
control, and improve what happens as we build products for our
customers. Most models of the software life cycle include the
following six processes: requirements engineering, design,
programming, integration, delivery, and maintenance. The list
below gives a description of each process and will be discussed in
details in the succeeding lessons.

Requirements Engineering
During this process, developers and clients meet to discuss ideas
for the new software product. Developers use a variety of
techniques in order to assess the real needs of the client. One such
technique is rapid prototyping in which a prototype program is built
that can mimic the functionality of the desired software. Using this
prototype, clients can better understand how the final product will
behave and can determine whether this behavior is what they really

Software Project Management

___________________________________________________ Software Engineering: A Computer
Science Approach

need. Unless the requirements engineering process is done

properly, the resulting software will not be useful to the client even
though it may run correctly. The requirements engineering process
is completed when the specifications for the new software product
are written in a formal document called the requirements
specification document.

During this process, the developers decide how they will construct
the software so that it meets the specifications agreed upon in the
requirements specification document. Usually the design of the
software goes through several stages in which it becomes
progressively more detailed. This approach to design is called
stepwise refinement, and it allows the developers to manage the
complexity of software by postponing decisions about details as late
as possible in order to concentrate on other important design
issues. When the design is complete, it is recorded in the design
specification document.

During this process, teams of programmers write the actual code of
the software. The software is divided into separate units called
modules in order to handle the complexity of the programming
process. Not only are these teams responsible for coding their
modules, they are also responsible for proper documentation
describing their code and for testing the code to insure correctness.

During this process, the individual modules of the software product
are combined to form the integrated software product. Since the
modules were developed separately, testing is crucial to the
integration process. Even with a good design, incompatibilities
between modules are likely to exist. These problems need to be
identified and corrected to complete the integration.

During this process, the developers deliver the completed software
to the clients. Usually the clients will conduct acceptance testing
on the software to determine whether or not it meets the
specifications agreed upon in the requirements specification
document. Once the software is accepted, it is installed and used
by the client.

During this process, the software undergoes various changes after
delivery in order to fix bugs, add new functionality, port the
software to new platforms, or adapt the software to new
technologies. Although it may seem that the software should be
finished after delivery, this is far from true. All successful software
_________________________________________________________________ Software Project
Lesson 2: Software Processes

products evolve over time to meet the changing needs of the


Approximate relative costs of the phases of the software life cycle [Schach 1999]
You may be surprised to discover that of all these processes,
maintenance dominates the cost of the life cycle. The graph on the
previous page shows the relative cost of the processes that make
up the software life cycle. Because maintenance costs are so
important, many developers are beginning to use design
approaches that result in software that is easier to maintain. At the
end of this module we will examine one of these approaches: the
object-oriented paradigm.

Many different models have been created to represent the software

life cycle. Although these models use various names for the
processes of the life cycle, they all include the six processes
described above in one way or another. In addition, these models
usually emphasize some other aspect of software development
such as a particular design technique (e.g., rapid prototyping),
management technique (e.g., risk management), or the model
describes a limited domain of software development (e.g., real-time

The Waterfall Model

The Waterfall Model is the classic software life cycle model.
According to Schach [1999], this model was the only widely
accepted life cycle model until the early 1980s. This model
represents the software life cycle using processes and products.
Each process transforms a product to produce a new product as
output. Then the new product becomes the input of the next
process. The table below lists the processes and products of the
Waterfall Model.

Input Product Process Output Product

Software Project Management

___________________________________________________ Software Engineering: A Computer
Science Approach

Communicated Requirements
Requirements Engineering
Requirements Specification Design Specification
Document Document
Design Specification Executable Software
Document Modules
Executable Software Integrated Software
Modules Product
Integrated Software Delivered Software
Product Product
Delivered Software Changed
Product Requirements

Notice that the output product on the right becomes the input
product on the left of the process at the next lowest level. The
general formula for describing the transformation of products by
processes can be written as follows:

A gray box represents each product and a solid arrow connecting

the boxes represents each process. To learn more about these
processes and products, view the Waterfall Model illustrations on
the Appendices part.

In addition to the six processes and seven products that make up

the Waterfall Model, several other important development activities
and characteristics are represented in the model. One of these
activities is testing. According to Schach, "inherent in every phase
of the Waterfall Model is testing. Testing is not a separate phase to
be performed only after the product has been constructed; it is not
to be performed only at the end of each phase. Instead...testing
should proceed continuously throughout the software process."
[Schach 1999]

Testing actually involves two steps: verification and validation.

Verification is substantiating that the software has been
transformed from one form into another as intended with sufficient
accuracy. For example, the design process transforms the design
specification document into the executable software modules.
Verification in this case is determining that the software modules
really are the entities that the design document describes.
Verification answers the question "Are we building the software
_________________________________________________________________ Software Project
Lesson 2: Software Processes

Validation is substantiating that the software functions with

sufficient accuracy with respect to its requirements specification.
Using the same example as before, validating the executable
software modules is determining that they behave as described in
the requirements specification. Validation answers the question
"Are we building the right software?" [Balci 1998]

Testing involving verification and validation should be conducted in

parallel with the development of the software product. In order to
represent the testing activity as an ongoing process, the V&V boxes
appear under each product of the Waterfall Model.

Verification deals with building the software right.

Validation deals with building the right software.
V&V of testing

One important characteristic of the Waterfall Model is the iteration

arrows that join the processes together. These arrows show how
the development of one product can influence the development of
previous products. A good example of this is the programming
process loop. In the diagram on the next page, notice how the
programming process and the accompanying iteration arrow form a
15 loop between the design specification document and the executable
software modules.

It is possible that design flaws will be revealed during the

programming of the software. When this happens, the design
specification must be changed to reflect the correction, these
changes must be tested, and finally the new design must be
entered into the programming process again. This loop is repeated
for all the design flaws that are discovered during programming.
Notice that in the complete Waterfall Model diagram (see
Appendices), the iteration arrows connect all the processes with the
exception of the delivery process. Like the programming process,
requirements engineering, design, and integration are all iterative
processes that involve progressive refinement of the resulting
Software Project Management
___________________________________________________ Software Engineering: A Computer
Science Approach

Another important characteristic of the Waterfall Model is the

maintenance arrows that connect the delivered software product to
the various other products in the life cycle. Remember that any
changes made to the software product after deliveries are
considered maintenance. A small change such as the correction of
a programming error may only require a change in the code of the
software. The arrow connecting the delivered software product with
the executable software modules represents these types of
changes. Other changes such as the addition of new functionality
require a change in the requirements specification of the software.
The arrow going to the Changed Requirements product represents
these types of changes. Notice that a change in the requirements
affects almost the entire life cycle since these requirements
become input to the design process and so on.

While the Waterfall Model presents a straightforward view of the

software life cycle, this view is only appropriate for certain classes
of software development.

Specifically, the Waterfall Model works well when the software

requirements are well understood (e.g., software such as compilers
or operating systems) and the nature of the software development
involves contractual agreements. The Waterfall Model is a natural
fit for contract-based software development since this model is
document driven; that is, many of the products such as the
requirements specification and the design are documents. These
documents then become the basis for the software development

According to Boehm, however, this model "does not work well for
many classes of software, particularly interactive end-user
applications." Specifying the requirements for such applications is
notoriously difficult since interface design is highly subjective and
clients rarely ever understand the real needs the software should 16
meet. As a result, "document-driven standards have pushed many
projects to write elaborate specifications of poorly understood user
interfaces and decision-support functions, followed by the design
and development of large quantities of unusable code"
[Boehm 1988]. The problem is that a contract is signed before the
real requirements of the system are properly understood.

In addition to this shortcoming, the Waterfall model provides no

means for risk assessment and management during the life cycle.
Consider the case of the baggage-handling system at the Denver
International Airport (DIA) again. Initially, DIA had intended that
each individual airline would be responsible for building its own
baggage-handling system. However, when American Airlines (AA)
decided to use DIA as its second-largest hub airport, AA
commissioned BAE Automatic Systems to develop an automated
_________________________________________________________________ Software Project
Lesson 2: Software Processes

baggage-handling system efficient enough to allow AA to turn

aircraft around in under thirty minutes. As the construction of the
airport progressed, a larger vision emerged "for the inclusion of an
airport-wide integrated baggage-handling system that could
provide a major improvement in the efficiency of luggage delivery."
To accommodate the vision, DIA negotiated a new contract with
BAE to develop the airport-wide baggage system. This new plan,
however, "underestimated the high complexity of the expanded
system, the newness of the technology, and the high level of
coordination required among the entities housed at DIA that were to
be served by the system" [Montealegre 1996]. Despite the
enormous change in the specifications of the project, no one gave
any thought to risk assessment. Had the developers considered the
risks involved with changing the system requirements radically at a
late stage of development, they may have concluded that the
expanded plan was infeasible. In the end, DIA had to settle with a
much less ambitious plan, and Montealegre reports "six months
after the de-scaling of the system, the airport was able to open and
operate successfully."

The Spiral Method

In 1988, Barry Boehm proposed a more comprehensive life cycle
model called the Spiral Model to address the inadequacies of the
Waterfall Model. According to Boehm, "the major distinguishing
feature of the Spiral Model is that it creates a risk-driven approach
to the software process rather than a primarily document-driven or
code-driven process. It incorporates many of the strengths of other
models and resolves many of their difficulties" [Boehm 1988].
Software projects encompass many different areas of risk such as
project cost overruns, changed requirements (e.g., the DIA baggage
system), loss of key project personnel, delay of necessary
hardware, competition from other software developers,
technological breakthroughs that obsolete the project, and many
others. The essential concept of the Spiral Model is "to minimize
risks by the repeated use of prototypes [emphasis added] and other

Unlike other models, at every stage risk analysis is performed... The

Spiral Model works by building progressively more complete
versions of the software by starting at the center of the spiral and
working outwards. With each loop of the spiral, the customer
evaluates the work and suggestions are made for its modification.
Additionally, with each loop of the spiral, a risk analysis is
performed which results in a 'go / no-go' decision. If the risks are
determined to be too great then the project is terminated"
[Frankovich 1998]. Thus, the Spiral Model addresses the problem of
Software Project Management
___________________________________________________ Software Engineering: A Computer
Science Approach

requirements engineering through development of prototypes, and

it addresses the need for risk management by performing risk
analysis at each step of the life cycle (See Appendix for details).

_________________________________________________________________ Software Project

Lesson 2: Software Processes

In order to manage the risk of a single phase in the Spiral Model

(i.e., one loop of the spiral), Boehm [1988] used the template below
for risk assessment during the development of a software
productivity tool.

The rows of the template represented various management

elements of the project. For each new phase, he created a new
instance of the template to review the status of the project and
decided whether the risks were too great to continue. To illustrate
the use of the template, the rows have been filled with a fictitious
example phase [Sommerville 1996].
Template Explanation Example Phase
The goals of the
Objectives Significantly improve software quality
software project
Within three years
Limitations which the
Constraints Without large-scale capital investment
project must meet
Without radical change to company standards
Reuse existing certified software
Possible ways to achieve
Alternatives Introduce formal specification and verification
the objectives
Invest in testing and validation tools
No cost effective quality improvement possible
Quality improvements may increase costs
Potential risks for this
Risks excessively
New methods might cause existing staff to
Literature survey, Pilot project, Survey of
Risk Strategies for reducing potential reusable components, Assessment of
Resolution the risks available tool support, Staff training and
motivation seminars
Experience of formal methods is limited - very
hard to quantify improvements
Results of applying risk Limited tool support available for company
resolution strategies standard development system
Reusable components available but little reuse
tool support
Explore reuse option in more detail
Development plans for
Plans Develop prototype reuse support tools
the next phase
Explore component certification scheme
Commitment Resources needed to Fund further 18-month study phase

Software Project Management

___________________________________________________ Software Engineering: A Computer
Science Approach

achieve the plans

Spiral Model Template

In the example above, software company A has the objective of

significantly improving the quality of their software. In order to
meet this goal, the company evaluates three alternatives and three
risks. One of the alternatives is the use of formal specification and
verification. This alternative, however, may incur the risk of
causing existing staff to leave since they prefer to use more familiar
methods of software development. To resolve this risk, staff
training and motivation seminars are conducted to show the
benefits of these new methods and determine the current level of
expertise in formal methods. As a result, Company A discovers that
the staff knows very little about these methods. Therefore, it is
difficult to estimate what type of benefit the company might receive
from using this alternative to meet its objective. Since this option
seems too risky, the plans for the next phase focus on another
alternative that is more promising: the reuse of software

The model on Appendices illustrates how the eight management

elements of the Spiral Model template are organized in each phase.

The final phase of the Spiral Model is analogous to the Waterfall

Model. At this point in the project, the software requirements
should be well understood through the development of several
prototypes. The project should also have resolved the major risks
involved with building the final version of the software. With these
19 issues resolved, the detailed design of the software enters the last
three processes of the Waterfall Model, and the software is created.
Although some of the labels in the Spiral Model are different, the
same processes are represented. The table below shows the
correspondence between the final phase of the Spiral Model and the
Waterfall model.

Waterfall Model Spiral Model

Design Specifications Detailed design
Programming Code, Unit test
Integration and
Acceptance test,

Notice, however, that the maintenance process that appeared as

dashed lines in the complete Waterfall Model seems to be missing
from the Spiral Model. What happened to this process? Boehm
_________________________________________________________________ Software Project
Lesson 2: Software Processes

[1988] explains: "The answer to [this question] involves an

observation that the spiral model applies equally well to
development or [maintenance] efforts. In either case, the spiral
gets started by a hypothesis that a particular operational mission
could be improved by a software effort." Thus maintenance simply
becomes another spiral or phase in the life cycle of the software.
Like the previous phase, the maintenance efforts undergo risk
assessment to evaluate whether changes are feasible.

1. What is the software life cycle?

2. List the six processes of the software life cycle.

3. What is stepwise refinement and how does it help during the

development of software?

4. Which process consumes the most resources during the life


5. What are the two important elements of the Waterfall Model?

Explain why.

6. What are the seven products described by the Waterfall Model?

7. When is software testing performed in the Waterfall Model?

8. What is software verification? 20

9. What is software validation?

10.Explain the purpose of iteration in the Waterfall Model.

11.Which process is the only process that does not involve


12.When is the Waterfall Model an appropriate software life cycle

model to use?

13.What major shortcoming of the Waterfall Model does the Spiral

Model address?

14.How does the Spiral Model address the need of accurately

determining the software requirements?

15.How does the Spiral Model handle the need for risk

Software Project Management

___________________________________________________ Software Engineering: A Computer
Science Approach

16.What are the eight management elements of the Spiral Model?

17.How many spirals does the Spiral Model contain?

18.How does the Spiral Model represent maintenance?

19.Giving reasons for your answer based on the type of system

being developed, suggest the most appropriate generic software
process model that might be used as a basis for managing the
development of the following systems:

a system to control anti-lock braking in a car;

a virtual reality system to support software maintenance;
a university accounting system that replaces an existing
an interactive system for railway passengers that finds
train times from terminals installed in stations.

20.Explain how both the waterfall model of the software process

and the prototyping model can be accommodated in the spiral
process model.

_________________________________________________________________ Software Project