SOFTWARE ENGINEERING

SOFTWARE ENGINEERING
THEORY AND PRACTICE

FOURTH EDITION

Shari Lawrence Pfleeger

RAND Corporation

Joanne M. Atlee
University of Waterloo

Upper Saddle River Boston Columbus San Francisco New York

Indianapolis London Toronto Sydney Singapore Tokyo Montreal
Dubai Madrid Hong Kong Mexico City Munich Paris Amsterdam Cape Town
 Modeling the Process
2 and Life Cycle

In this chapter, we look at

• what we mean by a “process”
• software development products,
processes, and resources
• several models of the software
development process
• tools and techniques for process
modeling

We saw in Chapter 1 that engineering software is both a creative and a step-by-step

process, often involving many people producing many different kinds of products. In
this chapter, we examine the steps in more detail, looking at ways to organize our activi-
ties, so that we can coordinate what we do and when we do it. We begin the chapter by
defining what we mean by a process, so that we understand what must be included
when we model software development. Next, we examine several types of software
process models. Once we know the type of model we wish to use, we take a close look at
two types of modeling techniques: static and dynamic. Finally, we apply several of these
techniques to our information systems and real-time examples.

2.1 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 of ordered tasks as a process: a series of steps involving activities, constraints, and
resources that produce an intended output of some kind.

45
46 Chapter 2 Modeling the Process and Life Cycle

A process usually involves a set of tools and techniques, as we defined them in

Chapter 1. Any process has the following characteristics:
• The process prescribes all of the major process activities.
• The process uses resources, subject to a set of constraints (such as a schedule), and
produces intermediate and final products.
• 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 sub-
process has its own process model.
• Each process activity has entry and exit criteria, so that we know when the activ-
ity begins and ends.
• The activities are organized in a sequence, so that it is clear when one activity is
performed relative to the other activities.
• 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.
When the process involves the building of some product, we sometimes refer to the
process as a life cycle. Thus, the software development process is sometimes called the
software life cycle, because it describes the life of a software product from its concep-
tion to its implementation, delivery, use, and maintenance.
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. For example, if Sam is a good
bricklayer, he may write down a description of the bricklaying process he uses so that
Sara can learn how to do it as well. He may take into account the differences in the way
people prefer to do things; for instance, he may write his instructions so that Sara can
lay bricks whether she is right- or left-handed. Similarly, a software development pro-
cess 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 rea-
son, the process helps to maintain a level of consistency and quality in products or ser-
vices that are produced by many different people.
A process is more than a procedure. We saw in Chapter 1 that a procedure is like
a recipe: a structured way of combining tools and techniques to produce a product. A
process is a collection of procedures, organized so that we build products to satisfy a set
of goals or standards. In fact, the process may suggest that we choose from several pro-
cedures, as long as the goal we are addressing is met. For instance, the process may
require that we check our design components before coding begins. The checking can
be done using informal reviews or formal inspections, each an activity with its own pro-
cedure, but both addressing the same goal.
The process structure guides our actions by allowing us to examine, understand,
control, and improve the activities that comprise the process. To see how, consider the
process of making chocolate cake with chocolate icing. The process may contain several
procedures, such as buying the ingredients and finding the appropriate cooking utensils.
 Section 2.1 The Meaning of Process 47

The recipe describes the procedure for actually mixing and baking the cake. The recipe
contains activities (such as “beat the egg before mixing with other ingredients”), con-
straints (such as the temperature requirement in “heat the chocolate to the melting
point before combining with the sugar”), and resources (such as sugar, flour, eggs, and
chocolate). Suppose Chuck bakes a chocolate cake according to this recipe. When the
cake is done, he tastes a sample and decides that the cake is too sweet. He looks at the
recipe to see which ingredient contributes to the sweetness: sugar. Then, he bakes
another cake, but this time he reduces the amount of sugar in the new recipe. Again he
tastes the cake, but now it does not have enough chocolate flavor. He adds a measure of
cocoa powder to his second revision and tries again. After several iterations, each time
changing an ingredient or an activity (such as baking the cake longer, or letting the
chocolate mixture cool before combining with the egg mixture), Chuck arrives at a cake
to his liking. Without the recipe to document this part of the process, Chuck would not
have been able to make changes easily and evaluate the results.
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
the practices that work best to produce high-quality software, and follow a software
development process so we can understand, control, and improve what happens as we
build products for our customers. We saw in Chapter 1 that software development usu-
ally involves the following stages:
• requirements analysis and definition
• system design
• program design
• writing the programs (program implementation)
• unit testing
• integration testing
• system testing
• system delivery
• maintenance
Each stage is itself a process (or collection of processes) that can be described as a
set of activities. And each activity involves constraints, outputs, and resources. For
example, the requirements analysis and definitions stage need as initial input a state-
ment of desired functions and features that the user expresses in some way. The final
output from this stage is a set of requirements, but there may be intermediate products
as the dialog between user and developer results in changes and alternatives. We have
constraints, too, such as a budget and schedule for producing the requirements docu-
ment, and standards about the kinds of requirements to include and perhaps the nota-
tion used to express them.
Each of these stages is addressed in this book. For each one, we will take a close look
at the processes, resources, activities, and outputs that are involved, and we will learn how
48 Chapter 2 Modeling the Process and Life Cycle

they contribute to the quality of the final product: useful software.There are many ways to
address each stage of development; each configuration of activities, resources, and outputs
constitutes a process, and a collection of processes describes what happens at each stage.
For instance, design can involve a prototyping process, where many of the design decisions
are explored so that developers can choose an appropriate approach, and a reuse process,
where previously generated design components are included in the current design.
Each process can be described in a variety of ways, using text, pictures, or a com-
bination. Software engineering researchers have suggested a variety of formats for such
descriptions, usually organized as a model that contains key process features. For the
remainder of this chapter, we examine a variety of software development process mod-
els, to see how organizing process activities can make development more effective.

2.2 SOFTWARE PROCESS MODELS

Many process models are described in the software engineering literature. Some are
prescriptions for the way software development should progress, and others are
descriptions of the way software development is done in actuality. In theory, the two
kinds of models should be similar or the same, but in practice, they are not. Building a
process model and discussing its subprocesses help the team understand the gap
between what should be and what is.
There are several other reasons for modeling a process:
• When a group writes down a description of its development process, it forms a
common understanding of the activities, resources, and constraints involved in
software development.
• Creating a process model helps the development team find inconsistencies,
redundancies, and omissions in the process and in its constituent parts. As these
problems are noted and corrected, the process becomes more effective and
focused on building the final product.
• The model should reflect the goals of development, such as building high-quality
software, finding faults early in development, and meeting required budget and
schedule constraints. As the model is built, the development team evaluates can-
didate activities for their appropriateness in addressing these goals. For example,
the team may include requirements reviews, so that problems with the require-
ments can be found and fixed before design begins.
• Every process should be tailored for the special situation in which it will be used.
Building a process model helps the development team understand where that tai-
loring is to occur.
Every software development process model includes system requirements as
input and a delivered product as output. Many such models have been proposed over
the years. Let us look at several of the most popular models to understand their com-
monalities and differences.

Waterfall Model
One of the first models to be proposed is the waterfall model, illustrated in Figure 2.1,
where the stages are depicted as cascading from one to another (Royce 1970). As the
 Section 2.2 Software Process Models 49

REQUIREMENTS
ANALYSIS

SYSTEM
DESIGN

PROGRAM
DESIGN

CODING

UNIT & INTE-

GRATION TESTING

SYSTEM
TESTING

ACCEPTANCE
TESTING
OPERATION
& MAINTENANCE

FIGURE 2.1 The waterfall model.

figure implies, one development stage should be completed before the next begins.
Thus, when all of the requirements are elicited from the customer, analyzed for
completeness and consistency, and documented in a requirements document, then the
development team can go on to system design activities. The waterfall model presents a
very high-level view of what goes on during development, and it suggests to developers
the sequence of events they should expect to encounter.
The waterfall model has been used to prescribe software development activities
in a variety of contexts. For example, it was the basis for software development deliver-
ables in U.S. Department of Defense contracts for many years, defined in Department
of Defense Standard 2167-A. Associated with each process activity were milestones
and deliverables, so that project managers could use the model to gauge how close the
project was to completion at a given point in time. For instance, “unit and integration
testing” in the waterfall ends with the milestone “code modules written, tested, and
integrated”; the intermediate deliverable is a copy of the tested code. Next, the code
can be turned over to the system testers so it can be merged with other system compo-
nents (hardware or software) and tested as a larger whole.
The waterfall model can be very useful in helping developers lay out what they
need to do. Its simplicity makes it easy to explain to customers who are not familiar
with software development; it makes explicit which intermediate products are neces-
sary in order to begin the next stage of development. Many other, more complex
50 Chapter 2 Modeling the Process and Life Cycle

models are really just embellishments of the waterfall, incorporating feedback loops
and extra activities.
Many problems with the waterfall model have been discussed in the literature,
and two of them are summarized in Sidebar 2.1. The biggest problem with the waterfall
model is that it does not reflect the way code is really developed. Except for very well-
understood problems, software is usually developed with a great deal of iteration.
Often, software is used in a solution to a problem that has never before been solved or
whose solution must be upgraded to reflect some change in business climate or operat-
ing environment. For example, an airplane manufacturer may require software for a
new airframe that will be bigger or faster than existing models, so there are new chal-
lenges to address, even though the software developers have a great deal of experience
in building aeronautical software. Neither the users nor the developers know all the
key factors that affect the desired outcome, and much of the time spent during require-
ments analysis, as we will see in Chapter 4, may be devoted to understanding the items
and processes affected by the system and its software, as well as the relationship
between the system and the environment in which it will operate. Thus, the actual soft-
ware development process, if uncontrolled, may look like Figure 2.2; developers may

SIDEBAR 2.1 DRAWBACKS OF THE WATERFALL MODEL

E ver since the waterfall model was introduced, it has had many critics. For example,
McCracken and Jackson (1981) pointed out that the model imposes a project manage-
ment structure on system development. “To contend that any life cycle scheme, even with
variations, can be applied to all system development is either to fly in the face of reality or to
assume a life cycle so rudimentary as to be vacuous.”
Notice that the waterfall model shows how each major phase of development terminates
in the production of some artifact (such as requirements, design, or code). There is no insight
into how each activity transforms one artifact to another, such as requirements to design.
Thus, the model provides no guidance to managers and developers on how to handle changes
to products and activities that are likely to occur during development. For instance, when
requirements change during coding activities, the subsequent changes to design and code are
not addressed by the waterfall model.
Curtis, Krasner, Shen, and Iscoe (1987) note that the waterfall model’s major shortcoming is
its failure to treat software as a problem-solving process. The waterfall model was derived from
the hardware world, presenting a manufacturing view of software development. But manufactur-
ing produces a particular item and reproduces it many times. Software is not developed like that;
rather, it evolves as the problem becomes understood and the alternatives are evaluated. Thus,
software is a creation process, not a manufacturing process. The waterfall model tells us nothing
about the typical back-and-forth activities that lead to creating a final product. In particular, cre-
ation usually involves trying a little of this or that, developing and evaluating prototypes, assess-
ing the feasibility of requirements, contrasting several designs, learning from failure, and
eventually settling on a satisfactory solution to the problem at hand.
 Section 2.2 Software Process Models 51

REQUIREMENTS
ANALYSIS
MAINTENANCE
SYSTEM
DESIGN

DELIVERY

PROGRAM
DESIGN
SYSTEM
TESTING

PROGRAM
IMPLEMENTATION
INTEGRATION
TESTING UNIT
TESTING

FIGURE 2.2 The software development process in reality.

thrash from one activity to the next and then back again, as they strive to gather knowl-
edge about the problem and how the proposed solution addresses it.
The software development process can help to control the thrashing by including
activities and subprocesses that enhance understanding. Prototyping is such a sub-
process; a prototype is a partially developed product that enables customers and devel-
opers to examine some aspect of the proposed system and decide if it is suitable or
appropriate for the finished product. For example, developers may build a system to
implement a small portion of some key requirements to ensure that the requirements
are consistent, feasible, and practical; if not, revisions are made at the requirements
stage rather than at the more costly testing stage. Similarly, parts of the design may be
prototyped, as shown in Figure 2.3. Design prototyping helps developers assess alterna-
tive design strategies and decide which is best for a particular project. As we will see in
Chapter 5, the designers may address the requirements with several radically different
designs to see which has the best properties. For instance, a network may be built as a
ring in one prototype and a star in another, and performance characteristics evaluated
to see which structure is better at meeting performance goals or constraints.
Often, the user interface is built and tested as a prototype, so that the users can
understand what the new system will be like, and the designers get a better sense of how
the users like to interact with the system. Thus, major kinks in the requirements are
addressed and fixed well before the requirements are officially validated during system
testing; validation ensures that the system has implemented all of the requirements,
so that each system function can be traced back to a particular requirement in the
specification. System testing also verifies the requirements; verification ensures that each
function works correctly. That is, validation makes sure that the developer is building the
52 Chapter 2 Modeling the Process and Life Cycle

REQUIREMENTS Validate
ANALYSIS
Verify
SYSTEM
DESIGN

PROGRAM
DESIGN

CODING

PROTOTYPING UNIT & INTE-

GRATION TESTING

SYSTEM
TESTING

ACCEPTANCE
TESTING OPERATION
& MAINTENANCE

FIGURE 2.3 The waterfall model with prototyping.

right product (according to the specification), and verification checks the quality of the
implementation. Prototyping is useful for verification and validation, but these activities
can occur during other parts of the development process, as we will see in later chapters.

V Model
The V model is a variation of the waterfall model that demonstrates how the testing
activities are related to analysis and design (German Ministry of Defense 1992). As
shown in Figure 2.4, coding forms the point of the V, with analysis and design on the
left, testing and maintenance on the right. Unit and integration testing addresses the
correctness of programs, as we shall see in later chapters. The V model suggests that
unit and integration testing can also be used to verify the program design. That is, dur-
ing unit and integration testing, the coders and test team members should ensure that
all aspects of the program design have been implemented correctly in the code. Simi-
larly, system testing should verify the system design, making sure that all system design
aspects are correctly implemented. Acceptance testing, which is conducted by the cus-
tomer rather than the developer, validates the requirements by associating a testing
step with each element of the specification; this type of testing checks to see that all
requirements have been fully implemented before the system is accepted and paid for.
The model’s linkage of the left side with the right side of the V implies that if
problems are found during verification and validation, then the left side of the V can be
reexecuted to fix and improve the requirements, design, and code before the testing
steps on the right side are reenacted. In other words, the V model makes more explicit
some of the iteration and rework that are hidden in the waterfall depiction. Whereas
 Section 2.2 Software Process Models 53

OPERATION
REQUIREMENTS Validate requirements
& MAINTENANCE
ANALYSIS

ACCEPTANCE
TESTING
SYSTEM
DESIGN
SYSTEM
Verify design TESTING

PROGRAM UNIT & INTE-

DESIGN GRATION TESTING

CODING

FIGURE 2.4 The V model.

the focus of the waterfall is often documents and artifacts, the focus of the V model is
activity and correctness.

Prototyping Model
We have seen how the waterfall model can be amended with prototyping activities to
improve understanding. But prototyping need not be solely an adjunct of a waterfall; it
can itself be the basis for an effective process model, shown in Figure 2.5. Since the

LIST OF LIST OF LIST OF

REVISIONS REVISIONS REVISIONS

revise user/
prototype customer
review

PROTOTYPE PROTOTYPE PROTOTYPE

REQUIREMENTS DESIGN SYSTEM TEST

SYSTEM
REQUIREMENTS DELIVERED
(sometimes informal SYSTEM
or incomplete)
FIGURE 2.5 The prototyping model.
54 Chapter 2 Modeling the Process and Life Cycle

prototyping model allows all or part of a system to be constructed quickly to under-

stand or clarify issues, it has the same objective as an engineering prototype, where
requirements or design require repeated investigation to ensure that the developer,
user, and customer have a common understanding both of what is needed and what is
proposed. One or more of the loops for prototyping requirements, design, or the system
may be eliminated, depending on the goals of the prototyping. However, the overall
goal remains the same: reducing risk and uncertainty in development.
For example, system development may begin with a nominal set of requirements
supplied by the customers and users. Then, alternatives are explored by having inter-
ested parties look at possible screens, tables, reports, and other system output that are
used directly by the customers and users. As the users and customers decide on what
they want, the requirements are revised. Once there is common agreement on what the
requirements should be, the developers move on to design. Again, alternative designs
are explored, often with consultation with customers and users.
The initial design is revised until the developers, users, and customers are happy
with the result. Indeed, considering design alternatives sometimes reveals a problem
with the requirements, and the developers drop back to the requirements activities to
reconsider and change the requirements specification. Eventually, the system is coded
and alternatives are discussed, with possible iteration through requirements and design
again.

Operational Specification
For many systems, uncertainty about the requirements leads to changes and problems
later in development. Zave (1984) suggests a process model that allows the developers and
customers to examine the requirements and their implications early in the development
process, where they can discuss and resolve some of the uncertainty. In the operational
specification model, the system requirements are evaluated or executed in a way that
demonstrates the behavior of the system.That is, once the requirements are specified, they
can be enacted using a software package, so their implications can be assessed before
design begins. For example, if the specification requires the proposed system to handle
24 users, an executable form of the specification can help analysts determine whether that
number of users puts too much of a performance burden on the system.
This type of process is very different from traditional models such as the waterfall
model. The waterfall model separates the functionality of the system from the design
(i.e., what the system is to do is separated from how the system does it), intending to
keep the customer needs apart from the implementation. However, an operational speci-
fication allows the functionality and the design to be merged. Figure 2.6 illustrates how an
operational specification works. Notice that the operational specification is similar to pro-
totyping; the process enables user and developer to examine requirements early on.

Transformational Model
Balzer’s transformational model tries to reduce the opportunity for error by eliminat-
ing several major development steps. Using automated support, the transformational
process applies a series of transformations to change a specification into a deliverable
system (Balzer 1981a).
 Section 2.2 Software Process Models 55

Execute and
Revise

OPERATIONAL TRANSFORMED
SPECIFICATION SPECIFICATION TEST
(problem-oriented) (implementation-
oriented)
DELIVERED
SYSTEM
SYSTEM
REQUIREMENTS
(sometimes informal
or incomplete)
FIGURE 2.6 The operational specification model.

Sample transformations can include

• changing the data representations
• selecting algorithms
• optimizing
• compiling
Because many paths can be taken from the specification to the delivered system, the
sequence of transformations and the decisions they reflect are kept as a formal devel-
opment record.
The transformational approach holds great promise. However, a major impedi-
ment to its use is the need for a formal specification expressed precisely so the transfor-
mations can operate on it, as shown in Figure 2.7. As formal specification methods
become more popular, the transformational model may gain wider acceptance.

Phased Development: Increments and Iterations

In the early years of software development, customers were willing to wait a long time
for software systems to be ready. Sometimes years would pass between the time the
requirements documents were written and the time the system was delivered, called
the cycle time. However, today’s business environment no longer tolerates long delays.
Software helps to distinguish products in the marketplace, and customers are always
looking for new quality and functionality. For example, in 1996, 80 percent of Hewlett-
Packard’s revenues were derived from products introduced in the previous two years.
Consequently, new process models were developed to help reduce cycle time.
One way to reduce cycle time is to use phased development, as shown in Figure 2.8.
The system is designed so that it can be delivered in pieces, enabling the users to have
some functionality while the rest is being developed. Thus, there are usually two systems
functioning in parallel: the production system and the development system. The
56 Chapter 2 Modeling the Process and Life Cycle

Compare with
requirements; FORMAL DEVELOPMENT RECORD
update as needed
Sequence of transformations
plus rationale for them
TRANSFORM N
•
•
•

FORMAL TRANSFORM 2
SPECIFICATION TEST
TRANSFORM 1

DELIVERED
SYSTEM SYSTEM
REQUIREMENTS
(sometimes informal
or incomplete)
FIGURE 2.7 The transformational model.

operational or production system is the one currently being used by the customer and
user; the development system is the next version that is being prepared to replace the cur-
rent production system. Often, we refer to the systems in terms of their release numbers:
the developers build Release 1, test it, and turn it over to the users as the first operational
release. Then, as the users use Release 1, the developers are building Release 2. Thus, the
developers are always working on Release n  1 while Release n is operational.
There are many ways for the developers to decide how to organize development
into releases. The two most popular approaches are incremental development and itera-
tive development. In incremental development, the system as specified in the require-
ments documents is partitioned into subsystems by functionality. The releases are
defined by beginning with one small, functional subsystem and then adding functionality

Development systems
DEVELOPERS

Build Release 1 Build Release 2 Build Release 3

Time
USERS

Use Release 1 Use Release 2 Use Release 3

Production systems
FIGURE 2.8 The phased-development model.
 Section 2.2 Software Process Models 57

INCREMENTAL DEVELOPMENT

ITERATIVE DEVELOPMENT

FIGURE 2.9 The incremental and iterative models.

with each new release.The top of Figure 2.9 shows how incremental development slowly
builds up to full functionality with each new release.
However, iterative development delivers a full system at the very beginning and
then changes the functionality of each subsystem with each new release. The bottom of
Figure 2.9 illustrates three releases in an iterative development.
To understand the difference between incremental and iterative development,
consider a word processing package. Suppose the package is to deliver three types of
functionality: creating text, organizing text (i.e., cutting and pasting), and formatting
text (such as using different type sizes and styles). To build such a system using incre-
mental development, we might provide only the creation functions in Release 1, then
both creation and organization in Release 2, and finally creation, organization, and for-
matting in Release 3. However, using iterative development, we would provide primi-
tive forms of all three types of functionality in Release 1. For example, we can create
text and then cut and paste it, but the cutting and pasting functions might be clumsy or
slow. So in the next iteration, Release 2, we have the same functionality, but have
enhanced the quality; now cutting and pasting are easy and quick. Each release
improves on the previous ones in some way.
In reality, many organizations use a combination of iterative and incremental
development. A new release may include new functionality, but existing functionality
from the current release may have been enhanced.These forms of phased development
are desirable for several reasons:
1. Training can begin on an early release, even if some functions are missing. The
training process allows developers to observe how certain functions are executed,
suggesting enhancements for later releases. In this way, the developers can be
very responsive to the users.
2. Markets can be created early for functionality that has never before been offered.
3. Frequent releases allow developers to fix unanticipated problems globally and
quickly, as they are reported from the operational system.
4. The development team can focus on different areas of expertise with different
releases. For instance, one release can change the system from a command-driven
58 Chapter 2 Modeling the Process and Life Cycle

one to a point-and-click interface, using the expertise of the user-interface spe-

cialists; another release can focus on improving system performance.

Spiral Model
Boehm (1988) viewed the software development process in light of the risks involved,
suggesting that a spiral model could combine development activities with risk manage-
ment to minimize and control risk. The spiral model, shown in Figure 2.10, is in some
sense like the iterative development shown in Figure 2.9. Beginning with the require-
ments and an initial plan for development (including a budget, constraints, and alterna-
tives for staffing, design, and development environment), the process inserts a step to
evaluate risks and prototype alternatives before a “concept of operations” document is
produced to describe at a high level how the system should work. From that document, a
set of requirements is specified and scrutinized to ensure that the requirements are as
complete and consistent as possible.Thus, the concept of operations is the product of the
first iteration, and the requirements are the principal product of the second. In the third
iteration, system development produces the design, and the fourth enables testing.
With each iteration, the risk analysis weighs different alternatives in light of the
requirements and constraints, and prototyping verifies feasibility or desirability before a
particular alternative is chosen. When risks are identified, the project managers must
decide how to eliminate or minimize the risk. For example, designers may not be sure
whether users will prefer one type of interface over another. To minimize the risk of
choosing an interface that will prevent productive use of the new system, the designers can
prototype each interface and run tests to see which is preferred, or even choose to include

DETERMINE GOALS, EVALUATE ALTERNATIVES

ALTERNATIVES, AND RISKS
ints 4
CONSTRAINTS C o ns t r a Risk analysis 4

es 4 ints 3 Risk analysis 3

t iv Constra
na
t er ints 2
Al Constra
ive
s3
Risk analysis 2
s atC
l t at e rn
ive
2 onst
r
A ern Alte aints Risk analysis1 Proto-
Alt rnati Proto- Proto-
ve s
Prototype 1 type 2 type 3 type 4
1

Budget4 Budget3 Budget2 Budget 1 1

start
Requirements, Concept of are nts Detailed
Dev
elo life-cycle plan operation o ftwreme design
plan pment S ui
sig e
de ftwar

In req
n

and tegrat ated

Validrements
So

test ion i Code

plan requ
ated,
Valid design Unit test
ied
verif System
Implementation Acceptance test
PLAN plan test
DEVELOP AND TEST

FIGURE 2.10 The spiral model.

 Section 2.2 Software Process Models 59

two different interfaces in the design, so the users can select an interface when they log on.
Constraints such as budget and schedule help to determine which risk-management strat-
egy is chosen.We will discuss risk management in more detail in Chapter 3.

Agile Methods
Many of the software development processes proposed and used from the 1970s
through the 1990s tried to impose some form of rigor on the way in which software is
conceived, documented, developed, and tested. In the late 1990s, some developers who
had resisted this rigor formulated their own principles, trying to highlight the roles that
flexibility could play in producing software quickly and capably. They codified their
thinking in an “agile manifesto” that focuses on four tenets of an alternative way of
thinking about software development (Agile Alliance 2001):
• They value individuals and interactions over processes and tools. This philosophy
includes supplying developers with the resources they need and then trusting
them to do their jobs well. Teams organize themselves and communicate through
face-to-face interaction rather than through documentation.
• They prefer to invest time in producing working software rather than in pro-
ducing comprehensive documentation. That is, the primary measure of success is
the degree to which the software works properly.
• They focus on customer collaboration rather than contract negotiation, thereby
involving the customer in key aspects of the development process.
• They concentrate on responding to change rather than on creating a plan and
then following it, because they believe that it is impossible to anticipate all
requirements at the beginning of development.
The overall goal of agile development is to satisfy the customer by “early and continuous
delivery of valuable software” (Agile Alliance 2001). Many customers have business
needs that change over time, reflecting not only newly discovered needs but also the need
to respond to changes in the marketplace. For example, as software is being designed and
constructed, a competitor may release a new product that requires a change in the soft-
ware’s planned functionality. Similarly, a government agency or standards body may
impose a regulation or standard that affects the software’s design or requirements. It is
thought that by building flexibility into the development process, agile methods can
enable customers to add or change requirements late in the development cycle.
There are many examples of agile processes in the current literature. Each is
based on a set of principles that implement the tenets of the agile manifesto. Examples
include the following.
• Extreme programming (XP), described in detail below, is a set of techniques for
leveraging the creativity of developers and minimizing the amount of administra-
tive overhead.
• Crystal is a collection of approaches based on the notion that every project needs
a different set of policies, conventions, and methodologies. Cockburn (2002), the
creator of Crystal, believes that people have a major influence on software qual-
ity, and thus the quality of projects and processes improves as the quality of the
60 Chapter 2 Modeling the Process and Life Cycle

people involved improves. Productivity increases through better communication

and frequent delivery, because there is less need for intermediate work products.
• Scrum was created at Object Technology in 1994 and was subsequently commer-
cialized by Schwaber and Beedle (2002). It uses iterative development, where
each 30-day iteration is called a “sprint,” to implement the product’s backlog of
prioritized requirements. Multiple self-organizing and autonomous teams imple-
ment product increments in parallel. Coordination is done at a brief daily status
meeting called a “scrum” (as in rugby).
• Adaptive software development (ASD) has six basic principles.There is a mission
that acts as a guideline, setting out the destination but not prescribing how to get
there. Features are viewed as the crux of customer value, so the project is orga-
nized around building components to provide the features. Iteration is important,
so redoing is as critical is doing; change is embraced, so that a change is viewed
not as a correction but as an adjustment to the realities of software development.
Fixed delivery times force developers to scope down the requirements essential
for each version produced. At the same time, risk is embraced, so that the devel-
opers tackle the hardest problems first.

Often, the phrase “extreme programming” is used to describe the more general con-
cept of agile methods. In fact, XP is a particular form of agile process, with guiding prin-
ciples that reflect the more general tenets of the agile manifesto. Proponents of XP
emphasize four characteristics of agility: communication, simplicity, courage, and feed-
back. Communication involves the continual interchange between customers and
developers. Simplicity encourages developers to select the simplest design or imple-
mentation to address the needs of their customers. Courage is described by XP creators
as commitment to delivering functionality early and often. Feedback loops are built
into the various activities during the development process. For example, programmers
work together to give each other feedback on the best way to implement a design, and
customers work with developers to perform planning exercises.
These characteristics are embedded in what are known as the twelve facets of XP.

• The planning game: In this aspect of XP, the customer, who is on-site, defines what
is meant by “value,” so that each requirement can be assessed according to how
much value is added by implementing it. The users write stories about how the
system should work, and the developers then estimate the resources necessary to
realize the stories. The stories describe the actors and actions involved, much like
the use cases we define in more detail in Chapters 4 and 6. Each story relates one
requirement; two or three sentences are all that is needed to explain the value of
the requirement in sufficient detail for the developer to specify test cases and esti-
mate resources for implementing the requirement. Once the stories are written,
the prospective users prioritize requirements, splitting and merging them until
consensus is reached on what is needed, what is testable, and what can be done
with the resources available. The planners then generate a map of each release,
documenting what the release includes and when it will be delivered.
• Small releases: The system is designed so that functionality can be delivered as soon
as possible. Functions are decomposed into small parts, so that some functionality
 Section 2.2 Software Process Models 61

can be delivered early and then improved or expanded on in later releases. The
small releases require a phased-development approach, with incremental or itera-
tive cycles.
• Metaphor: The development team agrees on a common vision of how the system
will operate. To support its vision, the team chooses common names and agrees
on a common way of addressing key issues.
• Simple design: Design is kept simple by addressing only current needs.This approach
reflects the philosophy that anticipating future needs can lead to unnecessary func-
tionality. If a particular portion of a system is very complex, the team may build a
spike—a quick and narrow implementation—to help it decide how to proceed.
• Writing tests first: To ensure that the customer’s needs are the driving force behind
development, test cases are written first, as a way of forcing customers to specify
requirements that can be tested and verified once the software is built. Two kinds
of tests are used in XP: functional tests that are specified by the customer and exe-
cuted by both developers and users, and unit tests that are written and run by
developers. In XP, functional tests are automated and, ideally, run daily. The func-
tional tests are considered to be part of the system specification. Unit tests are
written both before and after coding, to verify that each modular portion of the
implementation works as designed. Both functional and unit testing are described
in more detail in Chapter 8.
• Refactoring: As the system is built, it is likely that requirements will change.
Because a major characteristic of XP philosophy is to design only to current
requirements, it is often the case that new requirements force the developers to
reconsider their existing design. Refactoring refers to revisiting the requirements
and design, reformulating them to match new and existing needs. Sometimes
refactoring addresses ways to restructure design and code without perturbing the
system’s external behavior. The refactoring is done in small steps, supported by
unit tests and pair programming, with simplicity guiding the effort.We will discuss
the difficulties of refactoring in Chapter 5.
• Pair programming: As noted in Chapter 1, there is a tension between viewing
software engineering as an art and as a science. Pair programming attempts to
address the artistic side of software development, acknowledging that the
apprentice–master metaphor can be useful in teaching novice software develop-
ers how to develop the instincts of masters. Using one keyboard, two paired pro-
grammers develop a system from the specifications and design. One person has
responsibility for finishing the code, but the pairing is flexible: a developer may
have more than one partner on a given day.We will see in Chapter 7 how pair pro-
gramming compares with the more traditional approach of individuals working
separately until their modules have been unit-tested.
• Collective ownership: In XP, any developer can make a change to any part of the
system as it is being developed. In Chapter 11, we will address the difficulties in
managing change, including the errors introduced when two people try to change
the same module simultaneously.
• Continuous integration: Delivering functionality quickly means that working sys-
tems can be promised to the customer daily and sometimes even hourly. The
62 Chapter 2 Modeling the Process and Life Cycle

emphasis is on small increments or improvements rather than on grand leaps

from one revision to the next.
• Sustainable pace: XP’s emphasis on people includes acknowledging that fatigue
can produce errors. So proponents of XP suggest a goal of 40 hours for each work
week; pushing developers to devote heroic amounts of time to meeting deadlines
is a signal that the deadlines are unreasonable or that there are insufficient
resources for meeting them.
• On-site customer: Ideally, a customer should be present on-site, working with the
developers to determine requirements and providing feedback about how to test
them.
• Coding standards: Many observers think of XP and other agile methods as provid-
ing an unconstrained environment where anything goes. But in fact XP advocates
clear definition of coding standards, to encourage teams to be able to understand
and change each other’s work. These standards support other practices, such as
testing and refactoring. The result should be a body of code that appears to have
been written by one person, and is consistent in its approach and expression.
Extreme programming and agile methods are relatively new. The body of evidence for
its effectiveness is small but growing. We will revisit many agile methods and concepts,
and their empirical evaluation, in later chapters, as we discuss their related activities.
The process models presented in this chapter are only a few of those that are used
or discussed. Other process models can be defined and tailored to the needs of the user,
customer, and developer.As Sidebar 2.3 notes, we should really capture the development
process as a collection of process models, rather than focusing on a single model or view.

SIDEBAR 2.2 WHEN IS EXTREME TOO EXTREME?

A s with most software development approaches, agile methods are not without their crit-
ics. For example, Stephens and Rosenberg (2003) point out that many of extreme pro-
gramming’s practices are interdependent, a vulnerability if one of them is modified. To see
why, suppose some people are uncomfortable with pair programming. More coordination and
documentation may be required to address the shared vision that is missing when people
work on their own. Similarly, many developers prefer to do some design before they write
code. Scrum addresses this preference by organizing around monthly sprints. Elssamadissy
and Schalliol (2002) note that, in extreme programming, requirements are expressed as a set
of test cases that must be passed by the software.This approach may cause customer represen-
tatives to focus on the test cases instead of the requirements. Because the test cases are a
detailed expression of the requirements and may be solution oriented, the emphasis on test
cases can distract the representatives from the project’s underlying goals and can lead to a sit-
uation where the system passes all the tests but is not what the customers thought they were
paying for. As we will see in Chapter 5, refactoring may be the Achilles heel of agile methods;
it is difficult to rework a software system without degrading its architecture.
 Section 2.3 Tools and Techniques for Process Modeling 63

SIDEBAR 2.3 COLLECTIONS OF PROCESS MODELS

W e saw in Sidebar 2.1 that the development process is a problem-solving activity, but few
of the popular process models include problem solving. Curtis, Krasner, and Iscoe
(1988) performed a field study of 17 large projects, to determine which problem-solving fac-
tors should be captured in process models to aid our understanding of software development.
In particular, they looked at the behavioral and organizational factors that affect project out-
comes. Their results suggest a layered behavioral model of software development, including
five key perspectives: the business milieu, the company, the project, the team, and the individ-
ual. The individual view provides information about cognition and motivation, and project
and team views tell us about group dynamics. The company and business milieu provide infor-
mation about organizational behavior that can affect both productivity and quality. This
model does not replace traditional process models; rather, it is orthogonal, supplementing the
traditional models with information on how behavior affects the creation and production
activities.
As the developers and customers learn about the problem, they integrate their knowl-
edge of domains, technology, and business to produce an appropriate solution. By viewing
development as a collection of coordinating processes, we can see the effects of learning, tech-
nical communication, customer interaction, and requirements negotiation. Current models
that prescribe a series of development tasks “provide no help in analyzing how much new
information must be learned by the project staff, how discrepant requirements should be nego-
tiated, how a design team can resolve architectural conflicts, and how these and similar factors
contribute to a project’s inherent uncertainty and risk” (Curtis, Krasner, and Iscoe 1988). How-
ever, when we include models of cognitive, social, and organizational processes, we begin to see
the causes of bottlenecks and inefficiency. It is this insight that enables managers to understand
and control the development process. And by aggregating behavior across layers of models, we
can see how each model contributes to or compounds the effects of another model’s factors.

No matter what process model is used, many activities are common to all. As we
investigate software engineering in later chapters, we will examine each development
activity to see what it involves and to find out what tools and techniques make us more
effective and productive.

2.3 TOOLS AND TECHNIQUES FOR PROCESS MODELING

There are many choices for modeling tools and techniques, once you decide what you
want to capture in your process model; we have seen several modeling approaches in
our model depictions in the preceding section. The appropriate technique for you
depends on your goals and your preferred work style. In particular, your choice for
notation depends on what you want to capture in your model.The notations range from
textual ones that express processes as functions, to graphical ones that depict processes
64 Chapter 2 Modeling the Process and Life Cycle

as hierarchies of boxes and arrows, to combinations of pictures and text that link the
graphical depiction to tables and functions elaborating on the high-level illustration.
Many of the modeling notations can also be used for representing requirements and
designs; we examine some of them in later chapters.
In this chapter, the notation is secondary to the type of model, and we focus on
two major categories, static and dynamic. A static model depicts the process, showing
that the inputs are transformed to outputs. A dynamic model enacts the process, so the
user can see how intermediate and final products are transformed over time.

Static Modeling: Lai Notation

There are many ways to model a process statically. In the early 1990s, Lai (1991) devel-
oped a comprehensive process notation that is intended to enable someone to model
any process at any level of detail. It builds on a paradigm where people perform roles
while resources perform activities, leading to the production of artifacts. The process
model shows the relationships among the roles, activities, and artifacts, and state tables
show information about the completeness of each artifact at a given time.
In particular, the elements of a process are viewed in terms of seven types:
1. Activity: Something that will happen in a process. This element can be related to
what happens before and after, what resources are needed, what triggers the
activity’s start, what rules govern the activity, how to describe the algorithms and
lessons learned, and how to relate the activity to the project team.
2. Sequence: The order of activities. The sequence can be described using triggers,
programming constructs, transformations, ordering, or satisfaction of conditions.
3. Process model: A view of interest about the system. Thus, parts of the process
may be represented as a separate model, either to predict process behavior or to
examine certain characteristics.
4. Resource: A necessary item, tool, or person. Resources can include equipment,
time, office space, people, techniques, and so on. The process model identifies how
much of each resource is needed for each activity.
5. Control: An external influence over process enactment. The controls may be
manual or automatic, human or mechanical.
6. Policy: A guiding principle. This high-level process constraint influences process
enactment. It may include a prescribed development process, a tool that must be
used, or a mandatory management style.
7. Organization: The hierarchical structure of process agents, with physical grouping
corresponding to logical grouping and related roles. The mapping from physi-
cal to logical grouping should be flexible enough to reflect changes in physical
environment.
The process description itself has several levels of abstraction, including the software
development process that directs certain resources to be used in constructing specific
modules, as well as generic models that may resemble the spiral or waterfall models.
Lai’s notation includes several templates, such as an Artifact Definition Template,
which records information about particular artifacts.
 Section 2.3 Tools and Techniques for Process Modeling 65

Lai’s approach can be applied to modeling software development processes; later

in this chapter, we use it to model the risk involved in development. However, to
demonstrate its use and its ability to capture many facets of a complex activity, we
apply it to a relatively simple but familiar process, driving an automobile. Table 2.1 con-
tains a description of the key resource in this process, a car.
Other templates define relations, process states, operations, analysis, actions, and
roles. Graphical diagrams represent the relationships between elements, capturing the
main relationships and secondary ones. For example, Figure 2.11 illustrates the process
of starting a car. The “initiate” box represents the entrance conditions, and the “park”
box represents an exit condition. The left-hand column of a condition box lists artifacts,
and the right-hand column is the artifact state.

TABLE 2.1 Artifact Definition Form for Artifact “CAR” (Lai 1991)

Name Car
Synopsis This is the artifact that represents a class of cars.
Complexity type Composite
Data type (car c, user-defined)
Artifact-state list
parked ((state_of(car.engine) = off) Car is not moving, and engine is not running.
(state_of(car.gear) = park)
(state_of(car.speed) = stand))

initiated ((state_of(car.engine) = on) Car is not moving, but the engine is running.
(state_of(car.key_hole) = has-key)
(state_of(car-driver(car.)) = in-car)
state_of(car.gear) = drive)
(state_of(car.speed) = stand))

moving ((state_of(car.engine) = on) Car is moving forward or backward.

(state_of(car.keyhole) = has-key)
(state_of(car-driver(car.)) = driving)
((state_of(car.gear) = drive) or
(state_of(car.gear) = reverse))
((state_of(car.speed) = stand) or
(state_of(car.speed) = slow)
or (state_of(car.speed) = medium) or
(state_of(car.speed) = high))

Subartifact list
doors The four doors of a car
engine The engine of a car
keyhole The ignition keyhole of a car
gear The gear of a car
speed The speed of a car

Relations list
car-key This is the relation between a car and a key.

car-driver This is the relation between a car and a driver.

66 Chapter 2 Modeling the Process and Life Cycle

elec_on
car.engine off elec_off
driver. out_car on car.engine car.engine on turn_off off car.engine
go
driver. in_car
key. in_pocket open_door in_car driver. get_off out_car driver.
key. in_purse drive car.gear car.gear drive ready_to_park park car.gear
close_door
car.gear park stand car.speed car.speed stand stand car.speed
lock open_door
car.speed stand release_key park close_door
initiate put_key_in
take_key_out
drive
turn_key_in_to_init
unlock
ready_for_tow
back
forward
uphill
car.engine on on car.engine
drive
driver. in_car in_car driver.
speed_up
car.gear drive drive car.gear
slow_down
car.speed stand stand car.speed
open_door
drive close_door
lock
unlock

FIGURE 2.11 The process of starting a car (Lai 1991).

Transition diagrams supplement the process model by showing how the states are
related to one another. For example, Figure 2.12 illustrates the transitions for a car.
Lai’s notation is a good example of how multiple structures and strategies can be
used to capture a great deal of information about the software development process.
But it is also useful in organizing and depicting process information about user require-
ments, as the car example demonstrates.

FIGURE 2.12 Transition diagram for a car

(Lai 1991).
PARKED

initiate

get-out

stop
INITIATED MOVING
go
 Section 2.3 Tools and Techniques for Process Modeling 67

Dynamic Modeling: System Dynamics

A desirable property of a process model is the ability to enact the process, so that we
can watch what happens to resources and artifacts as activities occur. In other words,
we want to describe a model of the process and then watch as software shows us how
resources flow through activities to become outputs. This dynamic process view enables
us to simulate the process and make changes before the resources are actually
expended. For example, we can use a dynamic process model to help us decide how
many testers we need or when we must initiate testing in order to finish on schedule.
Similarly, we can include or exclude activities to see their effects on effort and schedule.
For instance, we can add a code-review activity, making assumptions about how many
faults we will find during the review, and determine whether reviewing shortens test
time significantly.
There are several ways to build dynamic process models. The systems dynamics
approach, introduced by Forrester in the 1950s, has been useful for simulating diverse
processes, including ecological, economic, and political systems (Forrester 1991).
Abdel-Hamid and Madnick have applied system dynamics to software development,
enabling project managers to “test out” their process choices before imposing them on
developers (Abdel-Hamid 1989; Abdel-Hamid and Madnick 1991).
To see how system dynamics works, consider how the software development pro-
cess affects productivity. We can build a descriptive model of the various activities that
involve developers’ time and then look at how changes in the model increase or decrease
the time it takes to design, write, and test the code. First, we must determine which factors
affect overall productivity. Figure 2.13 depicts Abdel-Hamid’s understanding of these

Fraction of staff
experienced
Percent of
New staff nominal project completed
Experienced staff nominal potential productivity
potential productivity
Learning multiplier
Average nominal
potential productivity
Potential
productivity

Software development
productivity

Actual fraction Motivation and

of person-day communication Communication
on project losses overhead

Over/under work tolerances Schedule pressure

Staff size
FIGURE 2.13 Model of factors contributing to productivity (Abdel-Hamid 1996).
68 Chapter 2 Modeling the Process and Life Cycle

factors. The arrows indicate how changes in one factor affect changes in another. For
example, if the fraction of experienced staff increases from one-quarter to one-half of the
people assigned to the project, then we would expect the average potential productivity
to increase, too. Similarly, the larger the staff (reflected in staff size), the more time is
devoted to communication among project members (communication overhead).
The figure shows us that average nominal potential productivity is affected by
three things: the productivity of the experienced staff, the fraction of experienced staff,
and the productivity of the new staff. At the same time, new staff must learn about the
project; as more of the project is completed, the more the new staff must learn before
they can become productive members of the team.
Other issues affect the overall development productivity. First, we must consider
the fraction of each day that each developer can devote to the project. Schedule pres-
sures affect this fraction, as do the developers’ tolerances for workload. Staff size
affects productivity, too, but the more staff, the more likely it is that time will be needed
just to communicate information among team members. Communication and motivation,
combined with the potential productivity represented in the upper half of Figure 2.13,
suggest a general software development productivity relationship.
Thus, the first step in using system dynamics is to identify these relationships,
based on a combination of empirical evidence, research reports, and intuition. The next
step is to quantify the relationships. The quantification can involve direct relationships,
such as that between staff size and communication. We know that if n people are
assigned to a project, then there are n(n  1)/2 potential pairs of people who must com-
municate and coordinate with one another. For some relationships, especially those
that involve resources that change over time, we must assign distributions that describe
the building up and diminishing of the resource. For example, it is rare for everyone on
a project to begin work on the first day. The systems analysts begin, and coders join the
project once the significant requirements and design components are documented.
Thus, the distribution describes the rise and fall (or even the fluctuation, such as avail-
ability around holidays or summer vacations) of the resources.
A system dynamics model can be extensive and complex. For example, Abdel-
Hamid’s software development model contains more than 100 causal links; Figure 2.14
shows an overview of the relationships he defined. He defined four major areas that
affect productivity: software production, human resource management, planning, and
control. Production includes issues of quality assurance, learning, and development
rate. Human resources address hiring, turnover, and experience. Planning concerns
schedules and the pressures they cause, and control addresses progress measurement
and the effort required to finish the project.
Because the number of links can be quite large, system dynamics models are sup-
ported by software that captures both the links and their quantitative descriptions and
then simulates the overall process or some subprocess.
The power of system dynamics is impressive, but this method should be used with
caution. The simulated results depend on the quantified relationships, which are often
heuristic or vague, not clearly based on empirical research. However, as we will see in
later chapters, a historical database of measurement information about the various
aspects of development can help us gain confidence in our understanding of relation-
ships, and thus in the results of dynamic models.
 Section 2.3 Tools and Techniques for Process Modeling 69

SOFTWARE PRODUCTION HUMAN RESOURCE MANAGEMENT

Process losses
Potential
productivity
Error detection Software
and correction development Hiring rate Turnover rate
rate Actual
Quality productivity Workforce
Workforce
assurance experience
effort Error rate Learning mix

Schedule Perceived
pressure productivity
Scheduled Level of
Forecasted Project tasks
Workforce completion accuracy
level completion perceived complete in measuring
date
perceived date progress
needed
Adjustments Effort perceived Perceived
to workforce still needed project
and schedule state

PLANNING
CONTROL
FIGURE 2.14 Structure of software development (Abdel-Hamid 1996).

SIDEBAR 2.4 PROCESS PROGRAMMING

I n the mid-1980s, Osterweil (1987) proposed that software engineering processes be specified
using algorithmic descriptions. That is, if a process is well-understood, we should be able to
write a program to describe the process, and then run the program to enact the process. The
goal of process programming is to eliminate uncertainty, both by having enough understand-
ing to write software to capture its essence, and by turning the process into a deterministic
solution to the problem.
Were process programming possible, we could have management visibility into all pro-
cess activities, automate all activities, and coordinate and change all activities with ease. Thus,
process programs could form the basis of an automated environment to produce software.
However, Curtis, Krasner, Shen, and Iscoe (1987) point out that Osterweil’s analogy to
computer programming does not capture the inherent variability of the underlying develop-
ment process. When a computer program is written, the programmer assumes that the imple-
mentation environment works properly; the operating system, database manager, and
hardware are reliable and correct, so there is little variability in the computer’s response to an
instruction. But when a process program issues an instruction to a member of the project
team, there is great variability in the way the task is executed and in the results produced. As
70 Chapter 2 Modeling the Process and Life Cycle

we will see in Chapter 3, differences in skill, experience, work habits, understanding the cus-
tomer’s needs, and a host of other factors can increase variability dramatically. Curtis and his
colleagues suggest that process programming be restricted only to those situations with min-
imal variability. Moreover, they point out that Osterweil’s examples provide information only
about the sequencing of tasks; the process program does not help to warn managers of
impending problems. “The coordination of a web of creative intellectual tasks does not
appear to be improved greatly by current implementations of process programming, because
the most important source of coordination is to ensure that all of the interacting agents share
the same mental model of how the system should operate” (Curtis et al. 1987).

2.4 PRACTICAL PROCESS MODELING

Process modeling has long been a focus of software engineering research. But how
practical is it? Several researchers report that, used properly, process modeling offers
great benefits for understanding processes and revealing inconsistencies. For example,
Barghouti, Rosenblum, Belanger, and Alliegro (1995) conducted two case studies to
determine the feasibility, utility, and limitations of using process models in large orga-
nizations. In this section, we examine what they did and what they found.

Marvel Case Studies

In both studies, the researchers used MSL, the Marvel Specification Language, to define
the process, and then generated a Marvel process enactment environment for it (Kaiser,
Feiler, and Popovich 1988; Barghouti and Kaiser 1991). MSL uses three main constructs—
classes, rules, and tool envelopes—to produce a three-part process description:
1. a rule-based specification of process behavior
2. an object-oriented definition of the model’s information process
3. a set of envelopes to interface between Marvel and external software tools used
to execute the process.
The first case study involved an AT&T call-processing network that carried
phone calls, and a separate signaling network responsible for routing the calls and bal-
ancing the network’s load. Marvel was used to describe the Signaling Fault Resolution
process that is responsible for detecting, servicing, and resolving problems with the sig-
naling network. Workcenter 1 monitored the network, detected faults, and referred the
fault to one of the two other workcenters. Workcenter 2 handled software or human
faults that required detailed analysis, and Workcenter 3 dealt with hardware failures.
Figure 2.15 depicts this process. Double dashed lines indicate which activity uses the
tool or database represented by an oval. A rectangle is a task or activity, and a diamond
is a decision. Arrows indicate the flow of control. As you can see, the figure provides an
overview but is not detailed enough to capture essential process elements.
Consequently, each of the entities and workcenters is modeled using MSL.
Figure 2.16 illustrates how that is done. The upper half of the figure defines the class
 Section 2.4 Practical Process Modeling 71

Monitoring tool WORKCENTER 1 WORKCENTER 2 SUBPROCESS

SUBPROCESS
Detect trouble Database

Initiate process Create ticket

Create ticket Database Diagnose

Diagnose yes
Workcenter 3: Fix Facility
equipment problem failure?

Terminal no no
equipment Refer to Workcenter 2 Refer to Workcenter 3
failure?
yes Transm.
yes failure?

Refer to Workcenter 3

no Resolve problem
yes
Resolved? Close ticket
Close ticket

FIGURE 2.15 Signaling Fault Resolution process (Barghouti et al. 1995).

TICKET:: superclass ENTITY FIGURE 2.16 Examples of Marvel

status: (initial, open, referred_out, referral_done, commands (Barghouti et al. 1995).
closed, fixed) = initial; Class
diagnostics : (terminal, non_terminal, none) = none; definition
level : integer; for trouble
description : text; tickets
referred_to : link WORKCENTER;
referrals : set_of link TICKET;
process : link PROC_INST;
end

diagnose [?t: TICKET]:

(exists PROC_INST ?p suchthat (linkto [?t.process ?p]))
:
(and (?t.status = open}(?t.diagnostics = none)) Rule for
{TICKET_UTIL diagnose ?t.Name} diagnosing
(and (?t.diagnostics = terminal) ticket
(?p.last_task = diagnose)
(?p.next_task = refer_to_WC3));
(and (?t.diagnostics = non_terminal)
(?p.last_task = diagnose)
(?p.next_task = refer_to_WC2));
72 Chapter 2 Modeling the Process and Life Cycle

TICKET, where a ticket represents the trouble ticket (or problem report) written when-
ever a failure occurs. As we will see in the chapters on testing, trouble tickets are used to
track a problem from its occurrence to its resolution.The entire network was represented
with 22 such MSL classes; all information created or required by a process was included.
Next, the model addressed behavioral aspects of the Signaling Fault Resolution
process. The lower half of Figure 2.16 is an MSL rule that corresponds loosely to the
box of Figure 2.15 labeled “Diagnose.” Thus, the MSL describes the rule for diagnosing
open problems; it is fired for each open ticket. When the process model was done, there
were 21 MSL rules needed to describe the system.
The second case study addressed part of the software maintenance process for
AT&T’s 5ESS switching software. Unlike the first case study, where the goal was pro-
cess improvement, the second study aimed only to document the process steps and
interactions by capturing them in MSL. The model contained 25 classes and 26 rules.
For each model, the MSL process descriptions were used to generate “process enact-
ment environments,” resulting in a database populated with instances of the information
model’s classes. Then, researchers simulated several scenarios to verify that the models
performed as expected. During the simulation, they collected timing and resource utiliza-
tion data, providing the basis for analyzing likely process performance. By changing the
rules and executing a scenario repeatedly, the timings were compared and contrasted,
leading to significant process improvement without major investment in resources.
The modeling and simulation exercises were useful for early problem identifica-
tion and resolution. For example, the software maintenance process definition uncov-
ered three types of problems with the existing process documentation: missing task
inputs and outputs, ambiguous input and output criteria, and inefficiency in the process
definition. The signaling fault model simulation discovered inefficiencies in the sepa-
rate descriptions of the workcenters.
Barghouti and his colleagues note the importance of dividing the process model-
ing problem into two pieces: modeling the information and modeling the behavior. By
separating these concerns, the resulting model is clear and concise. They also point out
that computer-intensive activities are more easily modeled than human-intensive ones,
a lesson noted by Curtis and his colleagues, too.

Desirable Properties of Process Modeling Tools and Techniques

There are many process modeling tools and techniques, and researchers continue to
work to determine which ones are most appropriate for a given situation. But there are
some characteristics that are helpful, regardless of technique. Curtis, Kellner, and Over
(1992) have identified five categories of desirable properties:
1. Facilitates human understanding and communication. The technique should be
able to represent the process in a form that most customers and developers can
understand, encouraging communication about the process and agreement on its
form and improvements. The technique should include sufficient information to
allow one or more people to actually perform the process. And the model or tool
should form a basis for training.
2. Supports process improvement. The technique should identify the essential compo-
nents of a development or maintenance process. It should allow reuse of processes
 Section 2.5 Information Systems Example 73

or subprocesses on subsequent projects, compare alternatives, and estimate the

impact of changes before the process is actually put into practice. Similarly, the tech-
nique should assist in selecting tools and techniques for the process, in encouraging
organizational learning, and in supporting continuing evolution of the process.
3. Supports process management. The technique should allow the process to be
project-specific. Then, developers and customers should be able to reason about
attributes of software creation or evolution. The technique should also support
planning and forecasting, monitoring and managing the process, and measuring
key process characteristics.
4. Provides automated guidance in performing the process. The technique should
define all or part of the software development environment, provide guidance
and suggestions, and retain reusable process representations for later use.
5. Supports automated process execution. The technique should automate all or part
of the process, support cooperative work, capture relevant measurement data,
and enforce rules to ensure process integrity.
These characteristics can act as useful guidelines for selecting a process modeling
technique for your development project. Item 4 is especially important if your organi-
zation is attempting to standardize its process; tools can help prompt developers about
what to do next and provide gateways and checkpoints to assure that an artifact meets
certain standards before the next steps are taken. For example, a tool can check a set of
code components, evaluating their size and structure. If size or structure exceeds pre-
defined limits, the developers can be notified before testing begins, and some compo-
nents may be reviewed and perhaps redesigned.

2.5 INFORMATION SYSTEMS EXAMPLE

Let us consider which development process to use for supporting our information sys-
tem example, the Piccadilly Television advertising program. Recall that there are many
constraints on what kinds of advertising can be sold when, and that the regulations may
change with rulings by the Advertising Standards Authority and other regulatory bodies.
Thus, we want to build a software system that is easily maintained and changed. There is
even a possibility that the constraints may change as we are building the system.
The waterfall model may be too rigid for our system, since it permits little flexi-
bility after the requirements analysis stage is complete. Prototyping may be useful for
building the user interface, so we may want to include some kind of prototyping in our
model. But most of the uncertainty lies in the advertising regulations and business con-
straints. We want to use a process model that can be used and reused as the system
evolves. A variation of the spiral model may be a good candidate for building the Pic-
cadilly system, because it encourages us to revisit our assumptions, analyze our risks,
and prototype various system characteristics. The repeated evaluation of alternatives,
shown in the upper-left-hand quadrant of the spiral, helps us build flexibility into our
requirements and design.
Boehm’s representation of the spiral is high-level, without enough detail to direct
the actions of analysts, designers, coders, and testers. However, there are many tech-
niques and tools for representing the process model at finer levels of detail. The choice
74 Chapter 2 Modeling the Process and Life Cycle

of technique or tool depends in part on personal preference and experience, and in part
on suitability for the type of process being represented. Let us see how Lai’s notation
might be used to represent part of the Piccadilly system’s development process.
Because we want to use the spiral model to help us manage risk, we must include
a characterization of “risk” in our process model. That is, risk is an artifact that we must
describe, so we can measure and track risk in each iteration of our spiral. Each potential
problem has an associated risk, and we can think of the risk in terms of two facets: prob-
ability and severity. Probability is the likelihood that a particular problem will occur,
and severity is the impact it will have on the system. For example, suppose we are con-
sidering the problem of insufficient training in the development method being used to
build the Piccadilly system. We may decide to use an object-oriented approach, but we
may find that the developers assigned to the project have little or no experience in
object orientation. This problem may have a low probability of occurring, since all new
employees are sent to an intensive, four-week course on object-oriented development.
On the other hand, should the problem actually occur, it would have a severe impact on
the ability of the development team to finish the software within the assigned schedule.
Thus, the probability of occurrence is low, but the severity is large.
We can represent these risk situations in a Lai artifact table, shown in Table 2.2.
Here, risk is the artifact, with subartifacts probability and severity. For simplicity, we

TABLE 2.2 Artifact Definition Form for Artifact “Risk”

Name Risk (ProblemX)

Synopsis process This is the artifact that represents the risk that problem X will occur and have a
negative affect on some aspect of the development process.
Complexity type Composite
Data type (risk_s, user_defined)

Artifact-state list
low ((state_of(probability.x) = low) Probability of problem is low, severity
(state_of(severity.x) = small) problem impact is small.

high-medium ((state_of(probability.x) = low) Probability of problem is low, severity

(state_of(severity.x) = large)) problem impact is large.

low-medium ((State_of(probability.x) = high) Probability of problem is high, severity

(state_of(severity.x) = small)) problem impact is small.

high ((state_of(probability.x) = high) Probability of problem is high, severity

(state_of(severity.x) = large)) problem impact is large.

Subartifact list

probability.x The probability that problem X will

occur.

severity.x The severity of the impact should

problem X occur on the project.
 Section 2.6 Real-Time Example 75

have chosen only two states for each subartifact: low and high for probability, and small
and large for severity. In fact, each of the subartifacts can have a large range of states
(such as extremely small, very small, somewhat small, medium, somewhat high, very
high, extremely high), leading to many different states for the artifact itself.
In the same way, we can define the other aspects of our development process and
use diagrams to illustrate the activities and their interconnections. Modeling the pro-
cess in this way has many advantages, not the least of which is building a common
understanding of what development will entail. If users, customers, and developers par-
ticipate in defining and depicting Piccadilly’s development process, each will have
expectations about what activities are involved, what they produce, and when each
product can be expected. In particular, the combination of spiral model and risk table
can be used to evaluate the risks periodically. With each revolution around the spiral,
the probability and severity of each risk can be revisited and restated; when risks are
unacceptably high, the process model can be revised to include risk mitigation and
reduction techniques, as we will see in Chapter 3.

2.6 REAL-TIME EXAMPLE

The Ariane-5 software involved the reuse of software from Ariane-4. Reuse was
intended to reduce risk, increase productivity, and increase quality. Thus, any process
model for developing new Ariane software should include reuse activities. In particu-
lar, the process model must include activities to check the quality of reusable compo-
nents, with safeguards to make sure that the reused software works properly within the
context of the design of the new system.
Such a process model might look like the simplified model of Figure 2.17. The
boxes in the model represent activities. The arrows entering the box from the left are
resources, and those leaving on the right are outputs. Those entering from the top are
controls or constraints, such as schedules, budgets, or standards. And those entering
from below are mechanisms that assist in performing the activity, such as tools, data-
bases, or techniques.
The Ariane-4 reuse process begins with the software’s mission, namely, control-
ling a new rocket, as well as software from previous airframes, unmet needs, and other
software components available from other sources (such as purchased software or
reuse repositories from other projects). Based on the business strategy of the aerospace
builder, the developers can identify reusable subprocesses, describe them (perhaps
with annotations related to past experience), and place them in a library for considera-
tion by the requirements analysts. The reusable processes will often involve reusable
components (i.e., reusable requirements, design or code components, or even test cases,
process descriptions, and other documents and artifacts).
Next, the requirements analysts examine the requirements for the new airframe
and the reusable components that are available in the library. They produce a revised
set of requirements, consisting of a mix of new and reused requirements. Then, the
designers use those requirements to design the software. Once their design is complete,
they evaluate all reused design components to certify that they are correct and consis-
tent with the new parts of the design and the overall intention of the system as
described in the requirements. Finally, the certified components are used to build or
76 Chapter 2 Modeling the Process and Life Cycle

Business strategies
(Changing)
Missions Reusable
Identify Subprocesses subprocesses
Software from previous reusable Describe
airframe subprocesses sub-
process 1
Reusable and nonreusable
components
Unmet domain needs Experience base

Requirements
Populate Requirements Revised requirements
for new airframe
domain
analysis
library Potential reusable
components

Evaluate
Design Build or
Design and certify Certified components
airframe change Software
selected
software software
reusable
components

FIGURE 2.17 Reuse process model for new airframe software.

change the software and produce the final system. As we will see in later chapters, such
a process might have prevented the destruction of Ariane-5.

2.7 WHAT THIS CHAPTER MEANS FOR YOU

In this chapter, we have seen that the software development process involves activities,
resources, and products. A process model is useful for guiding your behavior when you
are working with a group. Detailed process models tell you how to coordinate and col-
laborate with your colleagues as you design and build a system. We have also seen that
process models include organizational, functional, behavioral, and other perspectives,
so you can focus on particular aspects of the development process to enhance your
understanding or guide your actions.

2.8 WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

A process model has clear advantages for your development team, too. A good model
shows each team member which activities occur when, and by whom, so that the division
of duties is clear. In addition, the project manager can use process tools to enact the pro-
cess, simulating activities and tracking resources to determine the best mix of people and
activities in order to meet the project’s budget and schedule. This simulation is done
before resources are actually committed, so time and money are saved by not having to
 Section 2.11 Key References 77

backtrack or correct mistakes. Indeed, iteration and incremental development can be

included in the process model, so the team can learn from prototyping or react to evolv-
ing requirements and still meet the appropriate deadlines.

2.9 WHAT THIS CHAPTER MEANS FOR RESEARCHERS

Process modeling is a rich field of research interest in software engineering. Many soft-
ware developers feel that, by using a good process, the quality of the products of develop-
ment can be guaranteed.Thus, there are several areas into which researchers are looking:
• Process notations: How to write down the process in a way that is understandable
to those who must carry it out
• Process models: How to depict the process, using an appropriate set of activities,
resources, products, and tools
• Process modeling support tools: How to enact or simulate a process model, so that
resource availability, usage, and performance can be assessed
• Process measurement and assessment: How to determine which activities,
resources, subprocesses, and model types are best for producing high-quality
products in a specified time or environment
Many of these efforts are coordinated with process improvement research, an
area we will investigate in Chapter 13.

2.10 TERM PROJECT

It is early in the development process of the Loan Arranger system for FCO. You do
not yet have a comprehensive set of requirements for the system. All you have is an
overview of system functionality, and a sense of how the system will be used to support
FCO’s business. Many of the terms used in the overview are unfamiliar to you, so you
have asked the customer representatives to prepare a glossary. They give you the
description in Table 2.3.
This information clarifies some concepts for you, but you are still far from having
a good set of requirements. Nevertheless, you can make some preliminary decisions
about how the development should proceed. Review the processes presented in this
chapter and determine which ones might be appropriate for developing the Loan
Arranger. For each process, make a list of its advantages and disadvantages with
respect to the Loan Arranger.

2.11 KEY REFERENCES

As a result of the Fifth International Software Process Workshop, a working group chaired
by Kellner formulated a standard problem, to be used to evaluate and compare some of
the more popular process modeling techniques. The problem was designed to be complex
enough so that it would test a technique’s ability to include each of the following:
• multiple levels of abstraction
• control flow, sequencing, and constraints on sequencing
78 Chapter 2 Modeling the Process and Life Cycle

TABLE 2.3 Glossary of Terms for the Loan Arranger

Borrower: A borrower is the recipient of money from a lender. Borrowers may receive loans jointly; that
is, each loan may have multiple borrowers. Each borrower has an associated name and a unique borrower
identification number.
Borrower’s risk: The risk factor associated with any borrower is based on the borrower’s payment history.
A borrower with no loans outstanding is assigned a nominal borrower’s risk factor of 50. The risk factor
decreases when the borrower makes payments on time but increases when a borrower makes a payment late
or defaults on a loan. The borrower’s risk is calculated using the following formula:

Risk = 50 - [10 * 1number of years of loans in good standing2]

+ [20 * 1number of years of loans in late standing2]
+ [30 * 1number of years of loans in default standing2]

For example, a borrower may have three loans. The first loan was taken out two years ago, and all payments
have been made on time. That loan is in good standing and has been so for two years. The second and third
loans are four and five years old, respectively, and each one was in good standing until recently. Thus, each
of the two late-standing loans has been in late standing only for one year. Thus, the risk is

50 - [10 * 2] + [20 * 11 + 12] + [30 * 0] = 70.

The maximum risk value is 100, and the minimum risk value is 1.
Bundle: A bundle is a collection of loans that has been associated for sale as a single unit to an investor.
Associated with each bundle is the total value of loans in the bundle, the period of time over which the loans
in the bundle are active (i.e., for which borrowers are still making payments on the loans), an estimate of the
risk involved in purchasing the bundle, and the profit to be made when all loans are paid back by the
borrowers.
Bundle risk: The risk of a loan bundle is the weighted average of the risks of the loans in the bundle, with
each loan’s risk (see loan risk, below) weighted according to that loan’s value. To calculate the weighted
average over n loans, assume that each loan Li has remaining principal Pi and loan risk Ri. The weighted
average is then
n

a PiRi
i=1
n

a Pi
i=1

Discount: The discount is the price at which FCO is willing to sell a loan to an investor. It is calculated
according to the formula

Discount = 1principal remaining2 * [1interest rate2 * 10.2 + 1.005 * 1101 - 1loan risk2222]
Interest rate type: An interest rate on a loan is either fixed or adjustable. A fixed-rate loan (called an FM)
has the same interest rate for the term of the mortgage. An adjustable rate loan (called an ARM) has a rate
that changes each year, based on a government index supplied by the U.S. Department of the Treasury.
Investor: An investor is a person or organization that is interested in purchasing a bundle of loans from
FCO.
Investment request: An investor makes an investment request, specifying a maximum degree of risk at
which the investment will be made, the minimum amount of profit required in a bundle, and the maximum
period of time over which the loans in the bundle must be paid.
Lender: A lender is an institution that makes loans to borrowers. A lender can have zero, one, or many
loans.
Lender information: Lender information is descriptive data that are imported from outside the application.
Lender information cannot be changed or deleted. The following information is associated with each lender:
lender name (institution), lender contact (person at that institution), phone number for contact, a unique
lender identification number. Once added to the system, a lender entry can be edited but not removed.
(continues)
 Section 2.11 Key References 79

TABLE 2.3 (continued)

Lending institution: A synonym for lender. See lender.

Loan: A loan is a set of information that describes a home loan and the borrower-identifying information
associated with the loan. The following information is associated with each loan: loan amount, interest rate,
interest rate type (adjustable or fi
f xed), settlement date (the date the borrower originally borrowed the
money from the lender), term (expressed as number of years), borrower, lender, loan type (jumbo or
regular), and property (identiffied by the address of the property). A loan must have exactly one associated
lender and exactly one associated borrower. In addition, each loan is identiffied with a loan risk and a loan
status.
Loan analyst: The loan analyst is a professional employee of FCO who is trained in using the Loan
Arranger system to manage and bundle loans. Loan analysts are familiar with the terminology of loans and
lending, but they may not have all the relevant information at hand with which to evaluate a single loan or
collection of loans.
Loan risk: Each loan is associated with a level of risk, indicated by an integer from 1 to 100. 1 represents
the lowest-risk loan; that is, it is unlikely that the borrower will be late or default on this loan. 100 represents
the highest risk; that is, it is almost certain that the borrower will default on this loan.
Loan status: A loan can have one of three status designations: good, late, or default. A loan is in good
status if the borrower has made all payments up to the current time. A loan is in late status if the borrower’s
last payment was made but not by the payment due date. A loan is in default status if the borrower’s last
payment was not received within 10 days of the due date.
Loan type: A loan is either a jumbo mortgage, where the property is valued in excess of $275,000, or a
regular mortgage, where the property value is $275,000 or less.
Portfolio: The collection of loans purchased by FCO and available for inclusion in a bundle. The repository
maintained by the Loan Arranger contains information about all of the loans in the portfolio.

• decision points
• iteration and feedback to earlier steps
• user creativity
• object and information management, as well as flow through the process
• object structure, attributes, and interrelationships
• organizational responsibility for specific tasks
• physical communication mechanisms for information transfer
• process measurements
• temporal aspects (both absolute and relative)
• tasks executed by humans
• professional judgment or discretion
• connection to narrative explanations
• tasks invoked or executed by a tool
• resource constraints and allocation, schedule determination
• process modification and improvement
• multiple levels of aggregation and parallelism
80 Chapter 2 Modeling the Process and Life Cycle

Eighteen different process modeling techniques were applied to the common problem,
and varying degrees of satisfaction were found with each one. The results are reported
in Kellner and Rombach (1990).
Curtis, Kellner, and Over (1992) present a comprehensive survey of process mod-
eling techniques and tools. The paper also summarizes basic language types and con-
structs and gives examples of process modeling approaches that use those language
types.
Krasner et al. (1992) describe lessons learned when implementing a software pro-
cess modeling system in a commercial environment.
Several Web sites contain information about process modeling.

• The U.S. Software Engineering Institute (SEI) continues to investigate process

modeling as part of its process improvement efforts. A list of its technical reports
and activities can be found at http://www.sei.cmu.edu. The information at http://
www.sei.cmu.edu/collaborating/spins/ describes Software Process Improvement
Networks, geographically-based groups of people interested in process improve-
ment who often meet to hear speakers or discuss process-related issues.
• The European Community has long sponsored research in process modeling and
a process model language. Descriptions of current research projects are available
at http://cordis.europa.eu/fp7/projects_en.html.
• The Data and Analysis Centre for Software Engineering maintains a list of
resources about software process at https://www.thedacs.com/databases/url/key/39.

More information about Lai notation is available in David Weiss and Robert
Lai’s book, Software Product Line Engineering: A Family-based Software Develop-
ment Process (Weiss and Lai 1999).
The University of Southern California’s Center for Software Engineering has
developed a tool to assist you in selecting a process model suitable for your project’s
requirements and constraints. It can be ftp-ed from ftp://usc.edu/pub/soft_engineering/
demos/pmsa.zip, and more information can be found on the Center’s Web site: http://
sunset.usc.edu.
Journals such as Software Process—Improvement and Practice have articles
addressing the role of process modeling in software development and maintenance.
They also report the highlights of relevant conferences, such as the International Soft-
ware Process Workshop and the International Conference on Software Engineering.
The July/August 2000 issue of IEEE Software focuses on process diversity and has sev-
eral articles about the success of a process maturity approach to software development.
There are many resources available for learning about agile methods. The Agile
Manifesto is posted at http://www.agilealliance.org. Kent Beck’s (1999) is the seminal
book on extreme programming, and Alistair Cockburn (2002) describes the Crystal
family of methodologies. Martin Beck (1999) explains refactoring, which is one of the
most difficult steps of XP. Two excellent references on agile methods are Robert C.
Martin’s (2003) book on agile software development, and Daniel H. Steinberg and
Daniel W. Palmer’s (2004) book on extreme software engineering. Two Web sites
providing additional information about extreme programming are http://www.
xprgramming.com and http://www.extremeprogramming.org.
 Section 2.12 Exercises 81

2.12 EXERCISES
1. How does the description of a system relate to the notion of process models? For
example, how do you decide what the boundary should be for the system described by a
process model?
2. For each of the process models described in this chapter, what are the benefits and draw-
backs of using the model?
3. For each of the process models described in this chapter, how does the model handle a
significant change in requirements late in development?
4. Draw a diagram to capture the process of buying an airplane ticket for a business trip.
5. Draw a Lai artifact table to define a module. Make sure that you include artifact states
that show the module when it is untested, partially tested, and completely tested.
6. Using the notation of your choice, draw a process diagram of a software development
process that prototypes three different designs and choose the best from among them.
7. Examine the characteristics of good process models described in Section 2.4. Which char-
acteristics are essential for processes to be used on projects where the problem and solu-
tion are not well understood?
8. In this chapter, we suggested that software development is a creation process, not a manu-
facturing process. Discuss the characteristics of manufacturing that apply to software
development and explain which characteristics of software development are more like a
creative endeavor.
9. Should a development organization adopt a single process model for all of its software
development? Discuss the pros and cons.
10. Suppose your contract with a customer specifies that you use a particular software devel-
opment process. How can the work be monitored to enforce the use of this process?
11. Consider the processes introduced in this chapter. Which ones give you the most flex-
ibility to change in reaction to changing requirements?
12. Suppose Amalgamated, Inc., requires you to use a given process model when it contracts
with you to build a system. You comply, building software using the prescribed activities,
resources, and constraints. After the software is delivered and installed, your system expe-
riences a catastrophic failure. When Amalgamated investigates the source of the failure,
you are accused of not having done code reviews that would have found the source of the
problem before delivery. You respond that code reviews were not in the required process.
What are the legal and ethical issues involved in this dispute?