An Overview of Project Management 579

performance, monitoring actions taken and results achieved, addressing problems

encountered, and sharing information with people interested in the project. If a
substantial deviation occurs between the planned work and the actual work, the project
manager needs to reallocate resources, change the schedule, or renegotiate the
outcome.
• Terminating. This activity is concerned with finishing the project. It involves delivering
the system to the client according to the acceptance criteria defined in the project
agreement, installing the accepted system at the customer site, reviewing the project
history to extract lessons learned from the project, and modifying of project templates
for the next iteration of the project or for a new project.

From a dynamic point of view, a project can be in one of several phases. which we have
already mentioned in Chapter 3. We refine this model by adding another state, Conception (see
Figure 14-1).

GoAhead ScopeDefined
Conception Start
do/FormulateIdea do/Infrastructure Setup
do/Cost-BenefitAnalysis Definition do/Skill Identification
do/FeasibilityStudy do/Team Formation
do/Review do/Problem Statement do/Project Kickoff
do/Software Architecture
do/Software Plan
Termination
do/Client Acceptance Steady State Infrastructure
do/Delivery New Technology Setup Completed
do/Post Mortem New Need do/Develop System &&
do/Controlling Teams Assembled
do/Risk Management
System Done do/Replanning

Figure 14-1 Phases of a Software Project (UML state machine diagram).

Project conception. During this phase, also called concept phase, the idea for the project is
born. In a software project this is usually a new requirement triggered by the need of an existing
a market or a new technology. The concept phase is handled in many different ways. For a small
project it may consist of an informal discussion between interested people and a go-ahead
decision based on a verbal agreement.
In a larger project, the idea is investigated thoroughly, usually with a cost–benefit analysis
and a technical feasibility study. The cost–benefit analysis is a comparative assessment of all
costs that will be incurred to perform the project and of all benefits anticipated from the project’s
outcome. Some benefits can be reduced operating costs or increased revenue. Other benefits
might include improved morale, reduced turnover, increased productivity, or fewer absences.
580 Chapter 14 • Project Management

The technical feasibility study investigates if the outcome is technically feasible. A typical issue
to be addressed is whether the required innovation can be made available in time during the
duration of the project. Proceeding to the next phase usually requires a formal review and a
formal go-ahead decision.
Project definition. During this phase, the project manager, a client, and the software architect
are involved. The project manager can be one of the interested people from the concept phase or,
as it is quite common, brought in from the outside at the beginning of this phase. The project
definition phase includes the following activities:

• Problem definition. During this activity, the client and the project manager define the
scope of the system in terms of functionality, constraints, and deliverables. The client
and the project manager also agree on acceptance criteria and target dates. The
resulting document, called the problem statement, serves as the starting point of the
Requirements Analysis Document (RAD), which is developed during the steady state
phase.
• Initial Software Project Management Plan (SPMP). During this activity, the project
manager provides an overview of the project, a description of the results to be
produced, a work breakdown structure, roles and responsibilities, a project schedule,
budgets for required resources, and a description of how risks will be identified and
managed.
• Initial software architecture. This activity is performed in parallel to the development
of the SPMP. The focus is on the software architecture, in particular on the
decomposition of the system into subsystems. The software architecture is crucial for
managing the project, because it also serves as the basis for the initial team
organization. It therefore requires a close interaction between the software architect and
the project manager. The software architect revises the subsystem decomposition
during the steady state phase. The initial software architecture document will expand
into the System Design Document (SDD).
• Project Agreement definition. The client and the project manager formally agree on
the scope of the system and the delivery date as baselined in the Project Agreement
document.

Project start. During this phase, the project manager sets up the project infrastructure, hires
participants, organizes them in teams, and kicks off the project. Project start includes the
following activities:

• Infrastructure set-up. In project-based organizations, it cannot be assumed that the

infrastructure exists. The project manager must therefore define the requirements for
the infrastructure of the project. These requirements address the communication
channels for project participants like bulletin boards, web sites, and meeting
An Overview of Project Management 581

management procedures, tools for configuration management, building and testing

environments and workflows for the authoring and reviews of documents. The project
manager can then give this infrastructure specification to an infrastructure team, which
will set up this infrastructure and maintain it throughout the project.1
• Skill identification. During this activity, the project manager identifies the skills and
interests of the developers and records them in a skills matrix.
• Team assembly. The project manager uses the skill matrix to assign the participants to
teams for each subsystem defined in the initial software architecture document, defines
cross-functional teams, and selects team leaders. The project manager and the team
leaders together then assign roles and responsibilities to participants. When skills and
roles do not match, the project manager identifies additional training needs and
tutorials for the team members during this phase. Finally, the project manager assigns
work packages to the teams.
• Project kick-off. The project manager, the team leaders, and the client officially start
the project in a kick-off meeting with all developers being present. The purpose of the
kick-off meeting is to share with all the project participants the scope of the project, the
communication infrastructure, and the responsibilities of each team. After project kick-
off, the project enters steady state.

Project steady state. During project definition and project start, most decisions are made by
the project manager. During the steady state, team leaders are taking over some management
functions. In particular, they are responsible for tracking the status of their team and identifying
problems in team meetings. Team leaders report the status of their team to the project manager,
who then evaluates the status of the complete project. Team leaders respond to deviations from
the plan by reallocating tasks to developers or obtaining additional resources from the project
manager. The project manager is responsible for the interaction with the client, obtaining formal
agreements and renegotiating resources and deadlines. Steady state project management
includes the following activities:

• Project scope definition. Once the analysis model is stable, the client and the project
manager formally agree on the functional and nonfunctional requirements of the
system, which might lead to an update in the Project Agreement document.
• Controlling. Throughout the remaining project phases, team leaders and the project
manager monitor status in a weekly meeting and compare it with the planned schedule
from the SPMP. The team leaders are responsible for collecting status information
through meetings, reviews, problem reports, and work product completion. They are
also responsible to report status to the project manager.

1. Depending on the size and complexity of the project, financial and personal management systems are set up as well.
These systems are not covered in this book.
582 Chapter 14 • Project Management

• Risk management. During this activity, project participants identify additional

potential problems that could cause delays in the schedule and budget overruns. The
project manager and the team leaders identify, analyze, and prioritize risks, and prepare
contingency plans.
• Project replanning. Whenever the project deviates from the schedule or when a
contingency plan is activated, the project manager needs to revise the schedule and
reallocates resources to meet the delivery deadline. The project manager can hire new
staff, create new teams, or merge existing teams. Project replanning can also be
triggered when the client changes the requirements.

Project termination. During this phase, the project outcome is delivered to the customer and
the project history is collected. Most of the developers’ involvement with the project ends just
before this phase when they clean up models and code and complete the documentation. A
handful of key developers, the technical writers, and the team leaders are involved with
wrapping up the system for installation and acceptance and collecting the project history for
future use.

• Delivery. This activity consists of two subactivities, the client acceptance test and
installation, usually in that order.

• Client acceptance test. The software system is evaluated with the client according
to the acceptance criteria set forth in the Project Agreement. Functional and
nonfunctional requirements are demonstrated and tested using scenarios defined in
the Project Agreement. The client formally accepts the product at this stage.
• Installation. The system is deployed in the target environment and documents are
delivered. The installation may include user training and a roll-out phase, during
which data is migrated from the previous system to the new system.

• Postmortem. The project manager and the team leaders collect the history of the
project to allow the organization to learn from it. By capturing the history of major and
minor failures and by analyzing their causes, an organization can avoid repeating
mistakes and improve its practice.

Each of the states allows significant parallelism of the project management activities. This
is modeled in the activity diagram in Figure 14-2. In the following we describe these activities in
more detail. In the next section we describe project management models used for the various
project phases, in particular for the work to be performed, schedules, and team-based
organizations. We also describe how to document these models in a software project
management plan.
An Overview of Project Management 583

Conception

Formulate Idea Cost-Benefit Analysis

Feasibility Study

Definition

Problem Statement Initial Software

Initial Software
Definition Project Management Plan
Architecture

Project agreement
Start

Skill Infrastructure setup

Identification Team assembly

Project kickoff
Steady state

Controlling Risk management

Project replanning Scope agreement

Termination

Installation Client acceptance test Postmortem

Figure 14-2 Management activities in a software project (UML activity diagram).

584 Chapter 14 • Project Management

14.3 Project Management Concepts

The basic assumption of project planning is that the project outcome cannot be produced in a
single monolithic activity. If this could be done, we would not need a project, we would just do
the work instead of planning it. Because we cannot do this, we use a divide-and-conquer
approach to decompose the work into smaller, more doable pieces.
One of the key tasks in project planning is therefore the decomposition of the total work
package into smaller tasks. This involves two things: identifying appropriate tasks and
identifying dependencies between tasks. We will first talk about tasks and how to identify them.
A hierarchical representation of all the tasks in a project is called the work breakdown
structure (WBS). We then talk about the representation of the temporal dependencies between
tasks, which is called the task model or network diagram. The task model is then mapped onto a
time line which is the project schedule.

14.3.1 Tasks and Activities

A task is a well-defined work assignment for a project participant or a team. A task is the
smallest unit of work that is subject to project management. A task includes a description and a
duration, and is assigned to a role filled by a participant. Tasks consume resources and produce one
or more a work products. They often consume work products produced by other tasks. Table 14-1
provides simple examples of tasks.
Table 14-1 Examples of tasks for the realization of the database subsystem.

Assigned
Task name Description Task input Task output
role

Database subsystem System Elicit requirements from Team Database API,

requirements designer subsystem teams about liaisons persistent
elicitation
storage needs, identify object analysis
persistent objects model
Database subsystem Subsystem Design the database Subsystem Database
design design subsystem, recommend API subsystem
commercial product design
Database subsystem Implementor Implements the database Subsystem Database sub-
implementation subsystem design system code
Database subsystem Implementor Conducts a code Subsystem List of
inspection inspection of the source code discovered
database subsystem defects
Database subsystem Tester Develops a test suite for Subsystem Tests and test
test plan the database subsystem source code plan
Database subsystem Tester Executes the test suite for Subsystem Test results, list
test the database subsystem test plan of defects
Project Management Concepts 585

Related tasks are grouped into activities. Activities are larger units of work. Their duration
is often the same as a development phase, such as requirements analysis or system design. When
activities span the whole duration of a project, they are called project functions. Examples of
project functions are configuration management and project management itself (Figure 14-3).

Work
*

Task Activity

«invariant»
Project Function duration = project.duration

Figure 14-3 Tasks, Activities, and Project Functions (UML class diagram).

14.3.2 Work Products, Work Packages, and Roles

A manager assigns tasks, activities, and project functions to participants or a team, who carry it
out, while the manager monitors the progress and completion of the work. In a small project this
can be done informally, often with a shake of hands. In larger projects, this must be spelled out
more explicitly in form of a work package (Figure 14-4). A work package describes the work
products to be produced, the resources needed to perform the work, the expected duration,
dependencies on inputs, which are work products produced by other tasks as well as
dependencies on other tasks. It also specifies the acceptance criteria and the name of the
responsible individual or organizational unit.

Work Package
describes

* * produced-by
Outcome Work
*

Set of Work Products Work Product Task Activity

Internal Work Product Project Deliverable Project Function

Figure 14-4 Relationship between Outcome, Work, and Work Packages (UML class diagram).
586 Chapter 14 • Project Management

Work packages are important management artifacts, because we assign them to participants
to do the work. We can specify a work package right after the tasks have been identified. An
example of a small work package is an action item, which contains only the name of the
participant, the description of the task to be performed, and the time by which it must be
completed. Examples of larger work packages are descriptions for creating an object model, a class
diagram, source code, a document section, or a document. For example, each section of the
requirements analysis document can correspond to a work package specifying who has to write the
section and by when.
Any work product to be delivered to the customer is called a deliverable. The software
system and the accompanying documentation, such as the user manual, are deliverables. All
other types of work products consumed only by other project participants are called internal
work products. For example, action items are internal work products.

14.3.3 Work Breakdown Structure

The hierarchical representation of all the tasks in a project is called the work breakdown
structure (WBS). The work breakdown structure is a very simple model of the work to be
performed, because it uses only aggregation to model all the identified tasks (see Figure 14-5).
Figure 14-6 depicts a partial work breakdown structure for building a house. The activities
on the right can be assigned to different companies. The cost of an aggregate activity (e.g.,
Build Structure) is computed by aggregating the cost of its children (e.g., Build Foundation,
Build Walls, Build Roof). The node at the root of the hierarchy (e.g., Build House) represents
all the work that is required to complete the project. Note that a work breakdown structure does
not denote the sequencing of activities. For example, in Figure 14-6, Install Sewer Pipes and
Build House are accomplished in parallel, even though they are part of different branches of the
hierarchy. Temporal dependencies are captured in the task model, which we describe next.

14.3.4 Task Model

Tasks are related by temporal dependencies. An example of a temporal dependency is that the
Build Roof task cannot start before the Build Walls task is completed. The set of tasks and
their dependencies is called the task model or network diagram. Figure 14-7 depicts in UML the
task model corresponding to Figure 14-6.

Work Breakdown Structure Work

* *

Task Activity

Figure 14-5 The Work Breakdown Structure is the aggregation of all the work to be performed in a
project (UML class diagram).
Project Management Concepts 587

Build Foundation

Build Structure Build Walls

Build Roof

Install Sewer Pipes

Build House:WBS Install Plumbing Install Supply Pipes

Install Tubs & Sinks

Install Heating

Install Electric

Figure 14-6 Partial work breakdown structure for a house (UML instance diagram).

Database subsystem
req. elicitation

Database subsystem
design

Database subsystem
implementation
Database subsystem
test plan

Database subsystem
inspection

Database subsystem
test

Figure 14-7 An example of a task model with temporal dependencies for the database subsystem example
of Table 14-1 (UML activity diagram).
588 Chapter 14 • Project Management

Tasks have a duration, which corresponds to the actual time needed to complete the task
given the number of required participants. Durations are estimated by the project manager
before the project starts. Once dependencies among tasks and task durations are known, the
project manager can compute the shortest possible time in which the project can be completed.
This is simply the longest path in the task model, called critical path, that proceeds from the
first task in the project to the last, where the length of the path is computed by adding the task
durations. The project manager focuses particularly on the tasks on the critical path, as any delay
in these tasks results in delays of the overall project and missed deadlines. A task’s slack time is
the maximum amount of time a task can be postponed without delaying the rest of the project.
By definition, tasks on the critical path have a zero slack time.
Time constraints can be used to specify the start or end of a task independent from the
relationship of the task to other tasks. Time constraints are usually the result of an interaction of
the project manager with the client. If the system must be finished in the first week of December,
it has an MFO constraint. If a task T must start on a Monday, it has an MSO (see Table 14-2)
constraint. ASAP is the most commonly used constraint by people ordering tasks; ALAP is the
most commonly used constraint by people receiving tasks.
Table 14-2 Time constraints.

Constraint Definition

ASAP Start the task as soon as possible

ALAP As late as possible

FNET Finish no earlier than

SNET Start no earlier than

FNLT Finish no later than

SNLT Start no later than

MFO Must finish on

MSO Must start on

14.3.5 Skill Matrix

Once the work breakdown structure has been formulated, the project manager has to find the
right participants to perform the individual tasks. This is difficult because project managers must
work with people they may not know well.
Making a special effort to identify skills, knowledge, and interests helps the manager to
make more appropriate use of any special talents and improves the morale and productivity of
the project team.
Project Management Concepts 589

A skills matrix is a convenient form of relating the skills, knowledge, and interests of
people to the tasks to be performed in the project. The rows of a skill matrix (see Table 14-3)
denote the units of work—tasks, activities, and project functions—from the work breakdown
structure. The columns denote project participants. An entry in the matrix identifies the skill and
knowledge level of the particular participant for the task. We distinguish three types of entries:
primary skill, a secondary skill, and an interest. A primary skill or knowledge qualifies a person
to lead a unit of work. A secondary skill or knowledge qualifies a person to participate in a task.
Interest means the person is interested but has no skill in a task.

Table 14-3 Example of a skill matrix with 4 tasks and 4 participants.

primary skill secondary skill interest

Tasks\ Participant Bill Mary Sue Ed

Control Design

Database Design

User Interface Design

Configuration Management

14.3.6 The Software Project Management Plan

The management models described so far are summarized in Figure 14-8. This is a refinement of
the model we defined in Chapter 3. We added three composite patterns to generalize the classes
WorkProduct, Task, and Participant. We also added the Work Breakdown Structure and the
Organization classes, which are usually not visible to the developers.
The project management models are summarized in the Software Project Management
Plan (SPMP) [IEEE Std. 1058-1998]. In waterfall projects, this document is created before the
project kick-off by the project manager. In architecture-centric projects, it is created after the
software architecture is defined. In agile projects, this document is updated after each iteration.
Figure 14-9 depicts an example outline for the SPMP.
The audience of the SPMP includes the management and the developers. The SPMP
documents all issues related to client requirements (such as deliverables and acceptance criteria),
the project goals, the project organization, the division of labor into tasks, and the allocation of
resources and responsibilities. The first three sections of the SPMP provide background
information for the rest for the document. It briefly describes the project, the client deliverables,
the project milestones, and expected document changes. This section contains the hard
constraints from the Project Agreement that are relevant to the developers.
The fourth section of the SPMP describes the Project organization. The section describes
the organizational structure of subsystem teams and cross-functional teams. The boundaries of
590 Chapter 14 • Project Management

Equipment
Project
* Facility
Resource
Fund
* Organi-
Work zation
Breakdown

es
Structure Work
s

sum
Schedule
ibe Package
r *

con
sc

e
*

bl
* * de

si
produces Organizational
Outcome

on
Work Unit *
*

sp
*
plays

re
depends
Role
Set of Work Work
Products Product Activity Task Participant Staff

Internal Project
Project Function Department Team
Work Product Deliverable

Figure 14-8 Model of a Project from a project manager’s point of view. This is a refinement of the model
used in Chapter 3: we have added three composite patterns to generalize the classes WorkProduct, Task and
Participant (UML class diagram).

each team and of the management are defined and responsibilities assigned. Communication
roles, such as liaisons, are also described in this section. By reading this section, developers are
able to identify the participants in other teams they need to communicate with.
The fifth section of the SPMP, Managerial process plans, describes how management
deals with project initiation, steady state, and termination, and how it addresses unforeseen
problems. Anticipated risks and contingency plans are made public.
The sixth section of the SPMP, Technical process plans, describes the technical standards
that all teams are required to adopt. These cover the process model, development methodology,
the coding guidelines, infrastructure, and the product acceptance plan.
The seventh section of the SPMP, Supporting process plans, includes provisions for each
of the supporting processes, such as configuration management, verification and validation,
documentation, quality assurance, reviews and audits, problem reporting, subcontractor
management, and process improvement.
An initial version of the SPMP should be written by the project manager during the project
definition phase, and it should be coordinated with its companion document, the initial software
architecture document.
We call the software project management plan and the software architecture initial,
because the documents should not be finalized until the beginning of the project steady state
Project Management Concepts 591

Software Project Management Plan (SPMP)

1. Overview
1.1 Project summary
1.2 Evolution of the plan
2. References
3. Definitions
4. Project organization
4.1 External interfaces
4.2 Internal structure
4.3 Roles and responsibilities
5. Managerial process plans
5.1 Start-up plan
5.2 Work plan
5.3 Control plan
5.4 Risk management plan
5.5 Closeout plan
6. Technical process plans
6.1 Process model
6.2 Methods, tools, and techniques
6.3 Infrastructure plan
6.4 Product acceptance plan
7. Supporting process plans
7.1 Configuration management plan
7.2 Verification and validation plan
7.3 Documentation plan
7.4 Quality assurance plan
7.5 Reviews and audits
7.6 Problem resolution plan
7.7 Subcontractor management plan
7.8 Process improvement plan
8. Additional plans

Figure 14-9 An example of a template for the SPMP.

phase. In fact, we recommend a baseline of these documents only after the requirements analysis
phase. Only then will all the project participants be able to understand the impact of the
requirements on the work.
The completed SPMP document should be reviewed both by management and by
developers to ensure that the plans are feasible and realized in the project.
The evolution section of the SPMP provides a history of changes, including the author
responsible for the change, date of change, and a brief description of the change. The SPMP
should be updated whenever decisions that effect the outcome are made or problems are
discovered. In very large-scale projects this project function continues during the duration of the
592 Chapter 14 • Project Management

project. In this case updating all aspects of the SPMP is assigned to a separate person employed
as a planner.
In smaller projects, the role of the planner is usually played by the project manager.
Keeping the SPMP constantly up-to-date might become impossible because of the high
workload. In this case, we recommend that the project manager create three versions of the
SPMP: an initial version as the basis for project planning, the baselined version after the project
agreement is signed, and a final version at the end of the project termination as the basis for the
postmortem session.

14.4 Classical Project Management Activities

In this section, we describe the activities of a project manager managing a team-based software
project. Omitting the concept phase activities, our focus begins with the project definition phase.
The main activities of the project manager during project definition are to define the
organization structure, and to identify work products, tasks, schedule, and roles. Team leaders
join the project at the end of the project definition phase and their main effort is spent in
monitoring and managing teams during steady state. Team leaders should be aware, however, of
the project activities preceding their involvement and of the interaction with the client. We
discuss the following management activities:

• Planning the Project (Section 14.4.1): defining the problem, identifying the initial task
model and organization structure, estimating needed resources such as personnel and
funds.
• Organizing the Project (Section 14.4.2): hiring participants, skill identification,
mapping roles and responsibilities to participants, and organizing tutorials and the
project kick-off meeting.
• Controlling the Project (Section 14.4.3): project monitoring, risk management, and the
project agreement.
• Terminating the Project (Section 14.4.4): the client acceptance test, installation, and
project postmortem.

In this section, we focus on classical projects, in which the scope of the product is
relatively well defined at the beginning of the project and the goal of the project is to deliver
within a specific deadline and budget. In Section 14.5, we revisit these activities for an agile
project, in which the scope and requirements of the product are defined as the project progresses,
and the product is delivered in increments.

14.4.1 Planning the Project

Project planning focuses on the definition phase—the definition of the problem, planning a
solution, and estimating resources— and results in the following work products (Figure 14-10):
Classical Project Management Activities 593

• The problem statement is a short document describing the problem the system should
address, the target environment, client deliverables, and acceptance criteria. The
problem statement is an initial description and is the seed for the Project Agreement,
formalizing the common understanding of the project by the client and management,
and for the Requirements Analysis Document (RAD), a precise description of the
system under development.
• The top-level design represents the initial decomposition of the system into
subsystems. It is used to assign subsystems to individual teams. The top-level design
will be the seed for the System Design Document (SDD), a precise description of the
software architecture.
• The Software Project Management Plan (SPMP) describes all the managerial
aspects of the project, in particular the work breakdown structure, the schedule,
organization, work packages, and budget.

Deliverables
Project Planning Products
Project Agreement

Problem Statement
Requirements Analysis
Document (RAD)

System Design
Top-level Design Document (SDD)

Organization

Software Project
Task Model Management Plan (SPMP)

Schedule

Figure 14-10 Work products generated during project planning and their relationship with typical project
deliverables (UML class diagram).

Moving the design of the software architecture to the beginning is called architecture-
centric project management. Designing the top-level design and the SPMP in parallel is highly
desirable. However, pushing the design of the subsystem decomposition into the project
594 Chapter 14 • Project Management

organization phase is a deviation from long-standard software project management practices. In

university environments and in small company projects, the software project manager and
software architect roles are often assumed by the same person. Because the work load is high,
this requires a technically competent and highly motivated manager. In large projects the roles
should be assumed by different people. The software architect and project manager should work
closely together as a decision-making team, dividing responsibilities between management and
technical decisions [Paulish, 2001].

Developing the problem statement

The Problem Statement is developed by the project manager and the client as a mutual
understanding of the problem to be addressed by the system. The problem statement describes
the current situation, the functionality it should support, and environment in which the system
will be deployed. It also defines the deliverables expected by the client, together with delivery
dates and a set of acceptance criteria. The problem statement may also specify constraints on the
development environment, such as the programming language to be used. The problem
statement is not a precise or complete specification of the system. Instead, it is a high-level
summary of two project documents yet to be developed, the RAD and the SPMP.
The problem statement is developed iteratively by the project manager and the client.
Developing the problem statement is both a negotiation activity and an information-gathering
activity during which each party learns the expectations and constraints of the other. The
problem statement contains a high-level description of the functionality of the system. It should
also provide concrete examples to ensure that both parties are sharing the same vision. Scenarios
are used for describing both the current situation and the future situation (see Chapter 4,
Requirements Elicitation).
Figure 14-11 is an example outline for a problem statement. The first section describes the
problem domain. Section 2 of the problem statement provides example scenarios describing the
interaction between users and the system for the essential functionality. Scenarios are used for
describing both the current situation and the future situation. Section 3 summarizes the
functional requirements of the system. Section 4 summarizes the nonfunctional requirements
including constraints placed by the client, such as the choice of the programming language,
component reuse, or selection of a separate testing team. Section 5 describes the deployment
environment, including platform requirements, a description of the physical environment, users,
and so on. Section 6 lists client deliverables and their associated deadlines.

Defining the top-level design

The top-level design describes the software architecture of the system. The top-level
design should be done by the software architect. A project manager assuming the role of the
software architect must have enough technical expertise to accomplish this.
Classical Project Management Activities 595

PROBLEM STATEMENT
1. Problem domain
2. Scenarios
3. Functional requirements
4. Nonfunctional requirements
5. Target environment
6. Deliverables & deadlines

Figure 14-11 Outline of problem statement document. Note that the sections 2, 3, and 4 are not a complete
or precise specification of the system. They provide the basis for requirements elicitation. Section 6,
however, describes contractual deliverables and their associated due dates.

The subsystem decomposition should be high level, focusing on functionality. It should be

kept constant until the analysis phase produces a stable system model. The subsystem
decomposition can and should be revisited during subsystem design, and new subsystems are
usually created during the system design phase. In this case the organization might have to be
changed to reflect the new design. The software architect identifies the major subsystems and
their services, but does not yet define their interfaces at this point. The subsystem decomposition
is refined and modified later during system design (see Chapter 6, System Design: Decomposing
the System).
Later, during the project start phase, the subsystem decomposition serves as the basis of
the organizational units. Each subsystem is assigned to a team that is responsible for its
definition and realization. Teams who work on dependent subsystems will negotiate individual
services and their interfaces as these become necessary.

Identifying the work breakdown structure

There are several different approaches to developing the work breakdown structure (WBS)
for a project. The most commonly used approach is functional decomposition based on the
software process. For example, the work breakdown structure in Table 14-4 is based on a
functional breakdown of the work to be performed.
A functional decomposition based on the functions of the product itself can also be used to
define the tasks. This is often used in a high-risk projects where the system functionality is
released incrementally in a set of prototypes. For example, if a software system provides three
main functions, a system function–oriented work breakdown structure could consist of tasks that
build and deliver these system functions in a series of three prototypes.
An object-oriented work breakdown structure is also possible. For example, if a product
consists of five components, an object-oriented WBS would include five tasks associated with
the construction of each of these components. Specifying the development of these subsystems
of the software architecture as tasks comes quite naturally in object-oriented software projects.
596 Chapter 14 • Project Management

Table 14-4 Example of functional work breakdown structure for a simple ATM.

Use case Work breakdown structure

Authenticate 1. Realize authentication use case

1.1. Develop user interface forms (Login, change PIN)
1.2. Realize authentication protocol with server
1.3. Develop initial account creation

Withdraw Money 2. Develop money withdrawal use case

2.1. Develop user interface forms (Select Account,
Specify Amount)
2.2. Realize communication with server
2.3. Develop business logic for approving withdrawal
2.4. Develop interface with cash distributor

Deposit Check 3. Develop deposit check use case

3.1. Develop user interface forms (Specify Check, Insert Check)
3.2. Realize communication with server
3.3. Develop business logic for recording the deposit
3.4. Develop interface with label printer

Subsystem decomposition Work Breakdown Structure

UserInterface Develop
System

Develop Develop Control

Control UserInterface Subsystem

Develop Database
Database Subsystem

Figure 14-12 An example of an object-oriented work breakdown structure where the subsystem
decomposition is used to identify high-level activities and tasks (UML object diagram).

Figure 14-12 shows such a work breakdown structure for a system consisting of three
subsystems.
Another decomposition is based on geographical areas. If the project has developer teams
in different geographical regions, the tasks might be identified for each of these regions. Another
Classical Project Management Activities 597

WBS is based on organizational units. These can be the organizational units of the company
(marketing, operations, and sales) or they can be based on the people in the project.
No matter what approach is used, the ultimate goal is to decompose the total work into
tasks that are small enough to be doable, whose duration can easily be estimated, and that can be
assigned to a single person.2
When creating a work breakdown structure, the following heuristics are quite useful for
the project manager:

• Reuse an existing WBS. Consult people who have worked on similar projects.
Incorporate the information into the work breakdown structure.
• Involve key developers. Developers with knowledge about the solution domain should
participate in the development of the work breakdown structure. If they join the project
after the work breakdown structure is developed, they should be able to review and
critique it before they begin to work on their assigned tasks.
• Identify work gaps. All work to be performed in the project must be mapped onto tasks.
Work that is associated with an activity must eventually be addressed by at least one
task. If new work appears, an activity should be found or newly defined that includes
this task.
• Identify work overlaps. The same task should not be included in more than one activity.
For example, the project manager should not let the developers do subsystem testing, if
all subsystems tests are performed by a separate testing team.

Creating the initial schedule

After the temporal dependencies are established in the task model, we can create a
schedule. This requires the estimation of durations for each of the tasks. Estimating task
durations is quite difficult. Estimated times can of course be based on prior experience of the
manager or the estimator, but they often do not give the needed precision. It is impossible to
come up with a precise model for the complete project. One solution is to start with an initial
schedule representing deadlines mutually agreed by the client and the project manager. These
dates are generous enough that, even in the event of change, they can still be met.
Initially, the project manager should create a schedule that is detailed enough for the first
weeks of the project, showing events for the project kick-off meetings, the initial team meetings,
and tutorials. The rest of the project schedule should not be more detailed than the schedule in
the problem statement. The initial version of the SPMP should be viewed as a proposed version

2. There are things you have to do in a project such as coming to work, eating food, etc., which are usually not
considered tasks. That is, the project participant is not responsible to report the status of these things to the project
manager or team leader. Managers who try to turn these things into tasks as well are often called “micro-managers”
because they get too involved and manage low-level details.
598 Chapter 14 • Project Management

to be reviewed by the software architecture and subsystem teams before it can be considered
binding for all project participants.
The individual teams should start working on a revision of the initial version of the
subsystem decomposition right after the initial team meeting, focusing on their subsystem and
work breakdown structure for the development of the subsystem.
This planning activity has to be done by the team in parallel with ongoing requirements
analysis and system design activities. The newly found tasks should be presented during a
formal planning review scheduled during or near the end of the analysis phase. The result of the
planning review should be a revised work breakdown structure and software architecture. This
revision, in turn, is the basis for the second version of the SPMP, which should be baselined and
used as the basis for the project agreement with the client.
Scheduling requires a continuing trade-off between resources, time, and implemented
functionality and should be done regularly by the project manager. However, creating and
updating schedules are complicated activities, especially when people have to juggle between
commitments on more than one project. Resolving overloaded resources is a topic that is beyond
the scope of this book.

14.4.2 Organizing the Project

During project start, project management assembles the teams according to the top-level design
described in the software architecture, sets up the communication infrastructure, and then kicks
off the project by organizing the first two meetings. Once all participants are assigned tasks and
status reporting mechanisms are in place, the project is considered to be in steady state.
Project start activities are crucial for project-based organizations and are usually
performed under time pressure. The main problem is that the project members don’t yet know
each other. They have not yet had time to discover their different personalities and different
working styles. Getting to know the diversity of the responsibilities within the project is another
issue that needs to be addressed by the project manager.

Setting up the communication infrastructure

Clear and accurate communication is critical for the success of a development project.
Moreover, communication becomes crucial when the number of project participants increases.
Consequently, setting up the communication infrastructure for a project must occur as early as
possible. The project manager needs to address the following modes of communication:

• Scheduled modes of communication. These include planned milestones, such as client

and project reviews, team status meetings, inspections, and so on. Scheduled modes of
communication are the formal means through which project participants gather and
share information. These are best supported by synchronous or face-to-face
communication, such as meetings, formal presentations, video conferences, and
Classical Project Management Activities 599

telephone conference calls. The manager schedules dates and designates facilitators for
each of these interactions.
• Event-based modes of communication. These include problem reports, change requests,
issue discussion, and resolution. Event-based modes usually arise from unforeseen
problems and crises. Asynchronous mechanisms such as E-mail, groupware, and
problem databases need to be set up early, and participants need to be trained to use
them. When the number of participants is large, centralized infrastructures, such as
Web sites and bulletin boards, are preferable as they make information visible to more
people than E-mail or bilateral conversations.

Identifying skills
Once the initial work breakdown structure and task models have been created, the project
manager knows the type of skills required for each task. For example, tasks related to
requirements elicitation require application domain knowledge. Tasks that involve discussions
with the client require effective communication skills. Tasks related to testing require attention
to detail and quality-oriented thinking. In general, a software engineering development project
requires a variety of skills:

• Application domain skills. These include knowledge of the application domain, such as
banking terms and procedures and credit rating formulae in the context of banking
applications.
• Communication skills. These include the ability to communicate with stakeholders who
are not familiar with software development or with the application domain, the ability
to summarize and present complex ideas, and the ability to negotiate and achieve
consensus.
• Technical skills. These include knowledge of specific technology used in the project,
such as programming skills or knowledge of a specific component, the ability to assess
risks and bottlenecks in a software design, and the ability to find workarounds to
unexpected problems.
• Quality skills. These include attention to detail, the ability to identify boundary cases
and generate the corresponding test cases, and the ability follow procedures.
• Management skills. These include the ability to assess personal skills, motivate, provide
feedback, and assess project-level risks.

The task of the project manager, when organizing the project, is to identify individuals
with the right combination of skills for each task using a skill matrix (see Section 14.3.5). The
rows of the skill matrix come from the required skills for each tasks. The columns come from
the pool of available staff. In project-based organizations, the skills of each individual are
recorded in a profile, as the individual gains experience through projects and attends specific
courses. For resources hired from outside the organization (e.g., freelancers), a profile can be
600 Chapter 14 • Project Management

reconstituted from a combination of self-assessment (e.g., the individual’s resume) and from the
organization’s own assessment (e.g., interviews, tests). The set of profiles available to an
organization represents the competence of the organization.

Assigning management roles

Management roles are assigned to individual participants. A role such as team leader
cannot be filled effectively if is shared. First, a team leader fills a communication function by
acting as a liaison between higher-level management and developers and thus must be able to
communicate a consistent picture of status back and forth. Second, although a team leader
usually seeks the consensus of developers, he or she occasionally has to impose time-critical
decisions. Other management roles, such as liaisons between teams, also require the same
degree of consistency and thus are assigned to a single individual.
A good project manager seeks three skills in a participant when assigning management
roles: the ability to communicate, the ability to recognize risks early, and the discipline to
separate management decisions from technical ones. Such skills often come from experience in
previous projects. Having experience with teams is an important prerequisite for a team leader.

Assigning technical roles

In projects with small resources, the role of the software architect is often assumed by the
project manager. The advantage is a tight coordination of managerial and high-level technical
activities. The disadvantage is the additional time required by the project manager, which often
leads to task overload. The two roles should be assigned to different people.
Technical roles can be assigned to a team of participants. Complex software projects, for
example, can have a separate testing team composed of only testers. Once the project manager has
defined the responsibilities of the teams, it is the task of the team leader to assign individual tasks
to each team member based on availability or skill. Technical roles do not require the same level of
consistency as management roles do, given that their tasks are better defined and that they rely on
management and liaisons for coordination.

Dealing with skill shortages

In general, there are rarely sufficient skills for a given project (that is, not all rows in the
matrix can be assigned to a column), in part because of the rapid evolution of technology. The
project manager generates a training plan when skills are missing. This can include in-house
training, courses by vendors, and on-the-job training. Formal training can become expensive for
an organization, so in practice, much training happens on the job. The project manager should
distribute new or inexperienced staff across the project such that each team has at least one
experienced developer. Experienced developers provide technical leadership and can often serve
as mentors for the unexperienced developers who then gain experience more quickly. For
example, peer-programming techniques in which two developers share a computer and
collaborate on a single development task are advocated in the extreme programming life cycle
Classical Project Management Activities 601

process (see Chapter 15, Software Life Cycle) as a means to disseminate skills through the
organization with minimal formal training.
Formal training and learning by practice is a trade-off the project manager evaluates
within the given project time constraints. Formal training enables developers to become more
productive earlier; however, it is expensive and constitutes a longer-term investment benefiting
future projects.

Selecting team sizes

Although technical roles can be assigned to teams, the size of a single team is constrained
by management and communication overhead. When there are more participants on a team, then
the communication overhead is higher and team effectiveness is lower. The observations below
are adapted from [Kayser, 1990], who originally applied these heuristics to the formation of
subgroups during meetings. Given that team meetings are a significant tool for collecting status,
negotiation, and decision making, constraints on the number of participants in meetings are the
upper limits on the team size:

• Three members. During meetings, every member has a chance to speak. Issues are
discussed thoroughly and resolved easily. A possible problem with this team size is that
one member can dominate the other two. Also, small teams suffer from the cumulation
of multiple roles for each participant (“too many hats” syndrome).
• Four members. Starting with teams of this size allows the team to continue to function
even if a participant drops out. Reaching consensus with a team of even numbers can be
problematic since there can be a tie when voting. As a result, resolving issues can take
a relatively long time.
• Five and six members. This is the ideal size for a software development team. Members
can still meet face to face. Diverse perspectives, supported by a mix of ideas, opinions,
and attitudes, promotes creative thinking. Single roles can be assigned to each member,
creating a mini-organization in which each member complements the others.
• Seven members. This is still a relatively effective team size, but team meetings tend to
become long. Reviewing the status requires more than half an hour. If teams of seven
are necessary, it is advisable to form subteams during the formal team meetings, each
having the task to discuss and resolve a subset of the open issues from the agenda.
• Eight and more members. Teams of this size become difficult to manage. The internal
structure often starts to break down into subteams. Coalitions and side conversations
often occur during formal meetings. Members have more opportunities to compete than
to cooperate. Although results are usually satisfactory, the time to reach these results is
longer than with a team of smaller size.
602 Chapter 14 • Project Management

Assembling the teams

The next step in the project organization phase is to assemble the teams who will produce
the deliverables. The project manager selects the team leaders before the teams are formed. In
addition to being capable of understanding the team status, the team leader needs to be able to
communicate effectively, recognize pending crises (technical or social), and make trade-offs
taking into account project level concerns.
The project start phase is an ideal time for training team leaders and familiarizing them
with project procedures and ground rules. The team leader role is distinct from the role of
technical leader. The technical leader, usually the liaison to the architecture team, interacts with
the chief architect and the architecture liaisons from the other teams and has final say on the
technical decisions within the team. The role of architecture liaison requires excellent technical
skill and development experience.
In a training context, such as a university project course or an industrial pilot project
exploring a new software method, the team leader can be split into two roles. A coach trains,
explains, advises the team and acts as a liaison to the project manager. A team leader trainee fills
all other responsibilities of the team leader, including facilitating status meetings and assigning
tasks. In a university project course, this role can be filled by the instructor or an experienced
teaching assistant, whereas the architecture liaison can be filled by a student. In a development
project at a company, the team leader is filled by a developer who has experience and knowledge
with the organization’s management procedures, whereas the architecture liaison is filled by a
developer who has strong technical skills.
Developers who will work for the project can be assigned to the project all at once (flat
staffing), or the project can be gradually ramped up by hiring people as needed (gradual
staffing). On the one hand, gradual staffing is motivated by saving resources in the early part of
the project. Requirements elicitation and analysis do not require as many people as coding and
testing. Moreover, analyst and implementor are roles requiring different skills and thus should
be assigned to different people. On the other hand, flat staffing has the advantage of establishing
teams early and the social environment necessary for spontaneous communication. Some of the
developers can be assigned to the analysis activities with the analysts, and the others may
already start other activities such as setting up the configuration management environment,
technology survey and evaluation, and training. With shorter projects and market deadlines, flat
staffing is becoming the preferred staffing scheme. The dilemma between gradual staffing and
flat staffing has been discussed in length by Brooks [Brooks, 1995].

Kick-off meeting

The project manager, the team leaders, and the client officially start the project in a kick-
off meeting with all developers present. The purpose of kick-off meetings is to share information
with all the project participants about the scope of the project, the communication infrastructure,
and the responsibilities of each team. The presentation should be split between client and project
Classical Project Management Activities 603

manager. The client presents the requirements and the scope of the project. The project manager
presents the project infrastructure, top-level design and team responsibilities.

Agreeing on project scope

This document formally defines the scope, duration, cost, and deliverables for the project.
The Project Agreement can be in the form of a contract, a statement of work, a business plan, or
a project charter. The Project Agreement is typically finalized after the analysis model is
stabilized and the planning of the rest of the project is underway.
A Project Agreement should contain at least the following:

• list of deliverable documents

• criteria for demonstrations of functional requirements
• criteria for demonstrations of nonfunctional requirements, including accuracy,
reliability, response time, and security
• criteria for acceptance.

The Project Agreement represents the baseline of the client acceptance test. Any change in
the functionality to be delivered, the nonfunctional requirements, the deadlines, or the budget of
the project requires the renegotiation of the Project Agreement.
After the completion of the project kick-off and agreement in the project scope, the project
enters steady state.

14.4.3 Controlling the Project

To make effective decisions in the steady state phase of the project, the project manager needs
accurate status information. Unfortunately, collecting accurate status information is difficult.
While a complex system is difficult to understand in itself, the status of its components and its
impact on future deliveries are even more difficult to understand. Developers will not report to
their team leader any problem they believe they can address in time. However, small departures
from the schedule, not worth reporting independently, aggregate and degenerate into large
departures much later in the schedule. By the time team leaders discover and report a major
problem to the project manager, it has already caused a substantial delay in the project.
Several tools are available to collect status information. Because none of them are accurate
or reliable alone, team leaders and project managers need to use a combination of these. Below
we review their advantages and disadvantages.

Meetings

• Periodic status meetings. Status meetings conducted at the team level have the best
potential for reporting status and information required for corrective decisions. Status
meetings, however, can also provide inaccurate status information if team members do
not cooperate. Participants are naturally reluctant to report problems or mistakes. They
604 Chapter 14 • Project Management

cooperate only if they can trust a manager not to step into problems that they can
resolve themselves. Managers need to make problem reporting beneficial to developers
by intervening only when necessary.
• Sharp milestones. Progress can be measured by determining if developers deliver work
products on time. Managers can increase the accuracy of this method by defining sharp
milestones such that they can be accurately monitored. For example, the “coding
completed” milestone is not a sharp milestone, because it does not take into account the
quality of the code delivered. The code could contain few or many defects and the
milestone would be considered completed in either case. Conversely, defining a
milestone as the completion of the test, demonstration, documentation, and integration
of a specific feature yields better status information. When defining and monitoring
sharp milestones, managers do not need the cooperation of developers.
• Project reviews. A project review is a means for all participants to exchange status and
plan information about all the teams with formal presentation. Project reviews suffer
from similar problems as status meetings. If participants are already reluctant to admit
problems in front of their team leader, they definitively will not admit problems in a
public forum.
• Code inspections. Formal peer review of code is an effective method for discovering
defects early. When performed frequently, results can also be used as an indication of
progress.
• Prototype demonstrations. Prototype demonstrations are partial implementations of the
system for evaluating technology or functionality. They usually do not illustrate how
borderline cases are dealt with or how robust the implementation is. They are good for
measuring initial progress, but are not sharp measures of completion.

Metrics

It is difficult to manage the evolution of a product without objective measures. Although

meetings and inspections help assess the status of a project, they rely on the perception of
selected participants and their willingness to communicate what they know. The optimism of a
single participant can lead to the belief that the project has progressed much further than it has.
Software metrics are quantitative measures of selected aspects of the process or the system.
Instrumenting the process and the evolving system with automated metrics attempts to provide a
tool for measuring progress objectively.
Many software metrics have been proposed, such as the number of lines of source code,
the number of branching points [McCabe, 1976], the number of variables and operators
[Halstead, 1977], and the number of functional requirements [Albrecht & Gaffney, 1983]. Using
software metrics as a management tool has been difficult, as many work products are not
software items, and the values and trends observed require much interpretation from the
manager. Many project or product parameters have a potential impact on the metric being
Classical Project Management Activities 605

measured. For example, if the size of a subsystem in lines of source code increases rapidly,
maybe the developers assigned to the subsystem are productive, or they maybe are duplicating
code. With iterative and architecture-centric approaches, however, software components to test
and measure become available much earlier. Moreover, metrics can also measure attributes of
the process, such as deviations with the schedule, resources expended, and number of
participants leaving prematurely.

• Measuring financial status. Comparing planned costs against actual costs in the context
of actual progress enables a manager to assess the financial health of the project.
Software development projects are labor intensive; consequently, most of the cost
associated with the project is staffing. The planned staffing profile of the project over
time provides a cost baseline against which to compare actual costs. In addition, the
task model and the schedule provides us with the estimated effort and the deadline for
each task. An earned value assessment enables us to assess both the cost and schedule
situation of a project using one chart. For example, in Figure 14-13, the thin line
depicts the planned costs of the project over time. A project that is on budget and on
schedule would follow the same line very closely. The thick line represents the actual
costs of the project over time. In the example of Figure 14-13, we actually spent less
than planned. However, if we only looked at these two curves, we would not be able to
assess whether or not the project is in a good financial state. The project could be under
cost because we accomplished the planned work for less money, or because we did not
accomplish as much as planned. Consequently, we plot a third curve, the earned value,
which represents the value of the work we completed so far. The earned value is
measured by adding the planned costs of the tasks that have been completed. In this
example, the earned value is between the actual cost and the planned cost, indicating
that the project is under budget and late. If the earned value had been above the planned
costs, the project would have been under budget and early.

• Measuring technical progress. While measuring financial status is well understood in

software engineering and in project management in general, software development
projects introduce a special challenge when determining what tasks have actually been
accomplished. Measuring technical progress requires size metrics for each team. For
the development team, this can include the number of lines of source code under
baseline or the number of closed change requests. For the testing team, this can include
the number of defects found or the number of open change requests. For the
architecture team, it might be the number of critical use cases that have been
demonstrated. Size metrics, however, must be viewed in combination with quality
metrics to ensure that participants are not locally optimizing their numbers. For
example, change requests should be considered closed only after all regression tests
related to the change do not discover new defects.
606 Chapter 14 • Project Management

Planned cost

Earned value

Actual cost

Time
Current
time

Figure 14-13 Assessing the financial status of a project using earned value. An earned value above actual
costs indicates that more work was accomplished for the same a mount of money (i.e., the project is under
budget). An earned value below planned costs indicates that not as much work was completed as planned
(i.e., the project is late).

• Measuring stability. Once an initial version of the system is baselined, change requests
are issued to control and track changes to the baseline. Measuring the rate of new
change requests corresponding to defects in the system indicates how stable the system
becomes over time. Measuring the rate of change requests to the requirements similarly
indicates how stable the requirements have become in the view of the client. If work
completion indicates that the project is almost finished but the rate of change requests
is still high, the project may not be achieving its target quality goals.
• Measuring modularity. Breakage is a measure of the impact of a change on the baseline
(which can be measured in terms of lines of code, number of files, function points, or
any size metric that is appropriate in the context of the project). It is expected that early
changes affect more source code than later ones, as the architecture should become
more modular over the project time. Measuring breakage can encourage this trend and
make visible early any architectural issues (e.g., identifying specific types of changes
that yield high breakage). Increasing breakage indicates a degrading modularity over
the lifetime of the project, probably resulting from an inadequate architecture or
specific nonfunctional requirements that are difficult to meet.
• Measuring maturity. Mean time between failures measures the time between
discovered defects during testing. As the project nears delivery, the number of
discovered defects should decrease, indicating an increasing maturity of the product. A
decreasing maturity can indicate that developers are under pressure to address open
change requests and do not pay sufficient attention to quality. Decreasing maturity can
also result from a lack of stability (see measuring stability, above).
Classical Project Management Activities 607

Finally, independently of the methods used for determining status, the project manager,
the team leaders, and the developers need to communicate status information in understandable
terms. Next, we describe risk management as a method for controlling projects, communicating
potential problems, and planning contingencies.

Managing risk

The focus of risk management is to identify possible problems in the project and address
them before they can significantly affect the delivery date or the budget. The key element of risk
management is to set up the appropriate information flows such that risks and problems are
accurately reported in a timely manner. Many projects fail either because simple problems were
reported too late or because the wrong problem was addressed. In this section, we focus on the
activities of risk management for identifying, analyzing, and addressing risks. For more details
on risk management in software engineering, we refer the reader to the specialized literature
(e.g., [Boehm, 1991] and [Charette, 1989]).
The first step of risk management is to identify risks. Risks are potential problems that
result from an area of uncertainty. Risks can be managerial or technical. Managerial risks
include any uncertainty related to the organization, work products, roles, or task plan. Technical
risks include any uncertainty related to the system models, including changes of the
functionality of the system, the nonfunctional requirements, the architecture, or the
implementation of the system. In particular, technical risks include defects discovered late in the
development. Table 14-5 depicts examples of risks in a software project.

Table 14-5 Examples of risks identified in the OWL project.

Risk Risk type

Behavior of a commercial off-the-shelf (COTS) component does not comply with Technical
published standard.

COTS components delivery date is later than planned. Managerial

Users are not willing to use chosen user interface to interact with system. Technical

Selected middleware is too slow to meet performance requirement for data logging. Technical

Development of subsystems takes more time than scheduled. Managerial

Developers are often aware of the risks applicable to their tasks. The challenge is to
encourage developers to report risks so they can be managed. This entails rewarding developers
for reporting risks and problems and making the risk management activities directly beneficial
to developers. Spontaneous risk reporting is usually not sufficient. Project participants, including
the client, the developers, and the managers, are usually reluctant to communicate potential
608 Chapter 14 • Project Management

failures or shortcomings and are too optimistic about their outcome. A more systematic
approach to risk identification is to interview the project participants using a structured
questionnaire. Participants are asked in group sessions to list the risks they anticipate with
respect to specific tasks. Figure 14-14 depicts example questions from the Taxonomy-Based
Risk Identification process [Carr et al., 1993]. In this example, the interviewer attempts to
determine if there are any risks related to nonfunctional requirements. Depending on the answer
to the first question, the interviewer can ask follow-up questions to make sure no other related
risks are present. The rationale behind this questionnaire is to cover all the areas of development
in which risks are typically found.

1. Requirements
...
d. Performance
...
[23] Has a performance analysis been done?
(Yes) (23.a) What is your level of confidence in the performance analysis?
(Yes) (23.b) Do you have a model to track performance through design and implementation?

Figure 14-14 Questions for eliciting performance risks in the Taxonomy-Based Risk Identification
process. If the question to question 23 is positive, questions 23.a and 23.b are asked of the developers [Carr
et al., 1993].

Systematic risk identification produces a large number of managerial and technical risks,
some of them critical, others unimportant. Prioritizing risks allows managers to focus on the
critical risks. Risks are characterized by the likelihood they can become problems and by their
potential impact to the project when they become problems. By using these two attributes, risks
can be assigned to one of four categories:

• likely, high potential impact

• unlikely, high potential impact
• likely, low potential impact
• unlikely, low potential impact.

Managers should worry about the risks of the first category: likely, high potential impact.
For these risks, developers and managers should draw contingency plans and monitor the risk
carefully. If the likelihood of the risk increases, managers can activate the contingency plan and
address the problem in time. Moreover, managers should monitor the risks of the second
category: unlikely, high potential impact. Contingency plans do not need to be drawn for them
unless their likelihood increases. Finally, the risks in the third and fourth categories can be
ignored unless sufficient resources are available for monitoring them. Table 14-6 orders the risks
presented in Table 14-5.
Classical Project Management Activities 609

Table 14-6 Prioritized risks for a project.

Risk Likelihood Potential impact

Behavior of a COTS component does not Not likely High

comply with published standard.

New COTS component delivery date is later Likely High

than planned.

Users are not willing to use user interface. Likely for users spending less High
than 2 hours per day in front of
a computer

Selected middleware is too slow to meet Not likely, low sampling High
performance requirement for data logging. frequency

Development of components takes more time Likely, first occurrence High

than scheduled.

Once risks have been identified and prioritized, mitigation strategies should be designed
for the critical risks. Mitigation strategies can include lowering the likelihood of the risk or
decreasing its potential impact. Risks are usually caused by an area of uncertainty, such as
missing information or lack of confidence in some information. Developers decrease the
likelihood of a risk by further investigating the causes of the risk, by changing suppliers or
components, or by selecting a redundant supplier or component. Similarly, developers reduce
the impact of the risk on the project by developing an alternate or redundant solution. In most
cases, however, mitigating a risk incurs additional resources and cost. Table 14-7 describes
mitigation strategies for the risks presented in Table 14-5.
Once risks are identified, prioritized, and mitigated, the risk management plan should be
communicated to all concerned. Risk management relies on timely communication.
Spontaneous and timely reporting of potential problems should be encouraged. Risk
management plans and technical documents are communicated using the same channels.
Developers and other project participants review risks at the same time they review the technical
content of the project. As mentioned earlier, communication is the most significant barrier when
dealing with uncertainty.

14.4.4 Terminating the Project

In the project termination phase the project manager prepares for the client acceptance test,
manages the system integration, testing, and installation at the client’s site. Finally the project
manager oversees the project postmortem.
610 Chapter 14 • Project Management

Table 14-7 Mitigation strategies for a project.

Risk Mitigation strategy

Behavior of a COTS component does not comply • Run benchmarks to identify nonconformance.
with published standard. • Investigate if nonconforming functions can be
avoided.

COTS component delivery date later than • Monitor risk by asking manufacturer for
planned. intermediate status reports.

Users are not willing to use user interface. • Perform usability studies using mock-ups.
• Develop alternate interface.

Selected middleware is too slow to meet • Monitor risk. Plan for a performance
performance requirement for data logging. evaluation prototype.

Development of components takes more time than • Increase the priority of this task with respect to
scheduled. other implementation tasks.
• Assign key developers to this task.

Accepting the system

The purpose of the client acceptance test is the presentation of the system and the approval
of the client according to acceptance criteria set forth in the Project Agreement. The result is the
formal acceptance (or rejection) of the system by the client. Installation of the system and field
tests by the client may already have occurred. The client acceptance test constitutes the visible
end of the project.
The client acceptance test is conducted as a series of presentations of functionality and
novel features of the system. Important scenarios from the Problem Statement are exercised and
demonstrated by the developers or by future users. Additional demonstrations focus on the
nonfunctional requirements of the system such as accuracy, reliability, response time, or
security. If installation and user evaluations occurred prior to the client acceptance test, their
results are presented and summarized. Finally, the client acceptance test also serves as a
discussion forum for subsequent activities such as maintenance, knowledge transfer, or system
enhancement.

Installation

The installation phase of a project includes the field test of the system, the comparison of
the system results with the legacy system, the rollout of the legacy system, and the training of
users. The installation may be conducted by the supplier, by a contractor, or by the client,
depending on the Project Agreement.
Agile Project Management Activities 611

To minimize risks, installation and field testing are usually done incrementally, with
noncritical sites used as a field test environment. When the client is convinced that the disruption
to his business will be minimal, the delivered system enters full-scale operation. Replacement
systems and upgrades are rarely introduced in a “big-bang” fashion because the largest number
of problems are discovered during the first few days of operation.

Postmortem

Every project uncovers new problems, unforeseen events, and unexpected failures. Each
project, therefore, constitutes an opportunity for learning and anticipating new risks. Many
software companies conduct a postmortem study of each project after its completion. The
postmortem includes collecting data about planned vs. actual delivery dates and number of
defects discovered, qualitative information about technical and managerial problems
encountered, and suggestions for future projects. Although this phase is the least visible in the
life cycle, the company depends on it for learning and improving its efficiency.

14.5 Agile Project Management Activities

The project management method described in the previous section evolved out of the
management of large complex projects, in which the goal of project management was to develop
repeatable and predictable processes as a basis for planning and decision making. While such
methods are appropriate for well-defined requirements and mature technology, they lead to
organizations that are rigid and slow to respond to unexpected events or ill-defined requirements
typical of new product developments.
Agile methods deal better with ill-defined requirements and emerging solution
technologies, which are characterized by frequent change. Requirements change as new insights
are gained by the client and the users, software architecture changes as new technologies are
adopted or discarded, thus straining the classical approaches in which change is controlled or
even discouraged. Agile methods attempt to deal with these challenges by focusing on small
product increments that are developed in short time bursts. After each product increment,
progress is reviewed, lessons are learned, the project organization or goals are adjusted
accordingly.
In this section, we describe Scrum [Schwaber & Beedle, 2002], an example of agile
project management method, and contrast it with the previous section. Note that many activities
described in the previous section, such as skill management, risk management, system
installation, are relevant in both approaches.

14.5.1 Planning the Project: Create Product and Sprint Backlogs

The Scrum approach is characterized by short iterations, called sprints, during which a release
candidate is developed. In Scrum, this is called a potentially deliverable product increment.
Consequently, Scrum is an example of vertical integration (see Section 11.4.4).
612 Chapter 14 • Project Management

The project is started with a project kick off meeting, during which the product owner
and the Scrum master brainstorm a first version of the requirements. At the end of the kick off,
the requirements are prioritized into a list called the product backlog. The project backlog starts
as a vision formulated in terms of business requirements, and is updated and refined in terms of
system requirements as the team makes progress in realizing the product. The project backlog
reflects the current understanding of the product between the client and the project, rather than a
fixed contract specifying the final product.
A sprint starts with a sprint planning meeting, during which the stakeholders (the client,
management, and the team) select which items of the product backlog should be considered for
the next product increment. The team then determines a set of tasks, together with an effort
estimate, for realizing the selected requirements. The list of tasks and their effort estimates
constitute the sprint backlog. At the end of the sprint planning meeting, the team takes
responsibility for the sprint backlog and commits to delivering the product increment at the end
of the sprint. A sprint is timeboxed to typically 30 days. At the end of the sprint, the product
increment is reviewed and the scope of the next sprint is defined. Any unfinished work is
returned to the product backlog.
The items in the product backlog are grouped into releases with planned release dates. As
sprints result into completed increments, the product owner has three options:

1. decide whether to turn the sprint result into a product increment

2. declare the project finished and deliver the final product
3. adjust the release planning by shifting items between releases or adjusting release
dates, based on the team’s progress

14.5.2 Organizing the Project

Scrum defines three roles:

• The product owner is responsible for the requirements. The product owner
participates in the creation of the product backlog, and prioritizes the product backlog
before each sprint. The product owner represents the client and users with a single
voice. The product owner changes and re-prioritizes the product backlog before each
sprint to reflect lessons learned. The product owner is solely responsible for the product
backlog and has no influence on the team during the sprint.
• The Scrum master is a management role responsible for the process. The Scrum
master sets up and enforces the rules and practices of the project. The Scrum master
facilitates the daily Scrum meetings, monitors progress, and removes obstacles
preventing the team to do its work. The Scrum master is the interface between the
Scrum team and the product owner, ensures the team productivity, and shields the team
from distractions.
Agile Project Management Activities 613

• The Scrum team is responsible for developing the product increment. The team is
cross functional including all the skills required to build the product increment. The
team is self organizing in that each member commits to work based on their own skills
and availability. There are no roles or job descriptions assigned to specific members,
such as analysts, programmers, or testers. Members learn and adapt their skills based
on the work to be done. The team participates in the sprint planning meeting and
commits to the list of tasks defined in the sprint backlog.

14.5.3 Controlling the Project: Daily Scrums and Burn Down Charts
The Scrum master monitors the progress of the project with daily Scrum meetings and burn
down charts.
The daily Scrum meeting takes place at the beginning of the work day, and lasts at most
15 minutes. During the daily Scrum meeting, each team member reports individually:

• status: work done since the last daily Scrum meeting

• new issues: obstacles that are preventing them to accomplish their work
• new action items: work promised for the rest of the day

Reporting on these three points allows the Scrum master to monitor the progress of each
member and to identify corrective actions, such as:

• Planning new work that was not identified in the sprint planning meeting or in the
previous daily Scrum meetings
• Reallocation of tasks between members due to mismatch of skills or lack of interest
• Removing obstacles

Compared to the meeting templates presented in Chapter 3, Project Organization and

Communication (Section 3.4.3) and in Chapter 12, Rationale Management (Section 12.4.2),
Scrum uses a meeting template reduced to the absolute minimum. For example, discussion and
resolution of new issues is postponed to follow-up meetings scheduled later in the day in which
only the relevant stakeholders participate. The Scrum approach thus minimizes the time
developers spend in unnecessary meetings, by timeboxing status reporting and by sparing them
from discussions that are not relevant to them. The daily occurrence of the Scrum meetings
allows the team to identify unexpected issues early and make decisions quickly.
The daily Scrum meetings provide a short-term view of the sprint. To review progress and
assess trends, the Scrum master uses a burn down chart, which depicts the estimated remaining
effort as a function of time (see Figure 14-15). Each backlog item in the sprint log contains an
informal estimate in hours necessary to complete the item. The team members update their
estimates daily, based on the work they have accomplished so far and on the insights gained.
Work completed decreases the remaining effort in the sprint backlog. New work or a revised
614 Chapter 14 • Project Management

estimate for a task that turned out to be more complex increases the remaining effort in the
sprint. As the sprint burn down chart plots the cumulative estimated amount of work for the
sprint backlog, the Scrum master can assess the general trend of the sprint and identify any need
for corrective actions

Remaining
effort
[hours]
2000

1000

Time [days]
3 6 9 12 15 18 21 24 27 30

Figure 14-15 Assessing progress trend with a burn down chart. An increase corresponds to an upward
revision of estimated work (new work, tasks initially underestimated). A decrease corresponds to a
downward estimate of remaining work (work completed, obsolete tasks taken out of the plan).

Similarly, a release burn down chart, updated at the end of every sprint, shows the
remaining effort in days for releases, based on estimates of product backlog items in days.

14.5.4 Terminating the Project: Sprint Reviews

While the daily progress of the team is highly visible (e.g., daily Scrum meetings, daily sprint
backlog updates), the product owner cannot interfere with the team during the sprint. After the
sprint planning meeting, the team assumes complete authority for the product increment and is
left to its own devices while the Scrum master is responsible for removing obstacles raised by
the team. At the end of the sprint, management may adjust team composition or the product
owner may change requirements based on past team performance. If the goals of a sprint
become obsolete or not reachable, the sprint may also be terminated abnormally by the team or
by management. As sprints are normally short, abnormal termination occurs rarely.
With the end of each sprint, the product owner may renegotiate the product backlog with
the client. Based on the latest product increment, the product owner may propose to revise
specific requirements or assign new priorities. Based on the performance of the team, the
product owner may propose a release schedule or change the allocation of requirements to
releases.
Figure 14-16 shows an overview of the Scrum process.
Agile Project Management Activities 615

Scrum Team Scrum Master Product Owner Client

:Problem Statement

Kick off Project

:Product Backlog

Plan Sprint

:Sprint Backlog

Daily Scrum:
Review Actions, Identify Obstacles

:Action Items :Obstacles

Do Work Remove Obstacles

:Product Increment

[continue sprint]

[end sprint]

Review Sprint

[new increment]

[new release]

Deliver
Product Release

:Product Release

Figure 14-16 Overview of a Scrum process (UML activity diagram).

616 Chapter 14 • Project Management

14.6 Further Readings

A good overview of generic project management concepts can be found in Portny
[Portny, 2001]. Teams are the key to many project-based organizations. Katzenbach provides a
categorization of different team types, ranging from working groups to high-performing teams
[Katzenbach & Smith, 1994]. The IEEE-1058 described in this chapter is under revision and to
be approved in 2009. Royce describes the early role of a software architect during the
development of a software system using the Unified Process [Royce, 1998].
Paulish’s book on architecture-centric project management contains a detailed description
of the opportunities and challenges when the software architecture is formulated simultaneously
with the software project management plan [Paulish, 2001].
Estimation of software development effort is difficult, and few approaches yield accurate
results in the general case. COCOMO II is a statistical model that provides effort and time
estimates based on a large number of parameters [Boehm et al., 2000].
On the other end of the spectrum of estimation, Planning Poker [Grenning, 2002] is a
consensus-driven estimation method, in which the stakeholders estimate and discuss effort in a
moderated discussion. Consensus-driven methods aim to leverage from the experience of the
stakeholders while reconciling conflicting goals. Consensus-based methods have been made
popular by agile development [Cohn, 2006].
Scrum, which was co-developed by Ken Schwaber and Jeff Sutherland in the early 1990s
[Schwaber, 1995], is one of the earliest agile management methods. The Scrum development
method is described in [Schwaber & Beedle, 2002]. Many books have followed on this topic,
including adoption patterns for agile methods [Elssamadisy, 2009] and best practices
[Schwaber, 2004].
Of historical interest are two software project organization forms proposed by Brooks and
Weinberg. The chief programmer organization [Brooks, 1995] is a hierarchical organization
that assigns all team decisions to the team leader, called the chief programmer. The chief
programmer is responsible for the design and development of the subsystem and delegates
programming tasks to a pool of specialists. In contrast, egoless programming [Weinberg, 1971]
takes a democratic structure, adopted by the self organizing Scrum teams. For people interested
in organizations, we recommend the book from Wigand, Picot, and Reichwald [Wigand et
al., 1997].
Exercises 617

14.7 Exercises
14-1 In Figure 14-1, we modeled the phases of a project with a state chart. Use the state pat-
tern by making each of these phases a different class. Use the project management
activities introduced in this chapter to make them public operations on these classes.
Assume a team-based project organization.
14-2 What are the relative advantages of flat staffing versus gradual staffing?
14-3 What is the difference between reporting status and making decisions in a meeting?
Should they always be kept separate in a meeting?
14-4 Why should the software architect and project leader be different people?
14-5 Draw a UML model of the team organization of the ARENA project for each the main
phases (i.e., conception, definition, start, steady state, termination).
14-6 Draw a task model of the system design of the MyTrip system presented in Chapter 6,
System Design: Decomposing the System.
14-7 Estimate the time to complete each task of the task model produced in Exercise 14-6
and determine the critical path.
14-8 Identify, prioritize, and plan for the top five risks related to the system design of MyTrip
presented in Chapter 6, System Design: Decomposing the System.
14-9 Identify, prioritize, and plan for the top five risks related to the user interface subsystem
of CTC presented in Chapter 12, Rationale Management.
14-10 Linux, developed using the bazaar model, is more reliable and more responsive than
many operating systems running on Intel PCs. Make a case why the bazaar model
should or should not be used for the Space Shuttle control software.
14-11 Organize the project participants into teams of four people. Each team has the
following resources available: 2 eggs, 1 roll of TESA film, 1 roll of toilet paper, a cup
with water, a bucket with two liters of sand, 20 foam balls (each about 1 cm diameter),
1 table whose surface is about 1 meter above the ground. Each team has 25 minutes
time to build and test an artifact that allows an egg to be released 75 cm above the table
such that the egg falls on the table without cracking. Each team has another 5 minutes
to demonstrate the artifact to project management.
14-12 Organize the project into teams of four people. Each team has the following resources
available: 2 buckets of DUPLO pieces, 2 tables separated by a distance of 1.50 meters.
Each team has 25 minutes time to build and test a bridge solely out of the available
DUPLO pieces that hangs free for at least one minute between the two table surfaces.
Each team has another 5 minutes to demonstrate the artifact to project management.
14-13 Specify all management models for the icebreaker project described in Exercise 14-11.
14-14 Write an SPMP for the icebreaker project described in Exercise 14-11.
14-15 What does a flat section in a burn down chart mean (for example the section between
days 3 and 6 in Figure 14-15)?
618 Chapter 14 • Project Management

References
[Albrecht & Gaffney, 1983] A. J. Albrecht & J. E. Gaffney, Jr., “Software function, source lines of code, and
development effort prediction: A software science validation,” IEEE Transactions on
Software Engineering, Vol. SE-9, No. 6, November 1983.
[Boehm, 1991] B. Boehm, “Software risk management: Principles and practices,” IEEE Software,
Vol. 1, pp. 32–41, 1991.
[Boehm et al., 2000] B. Boehm, E. Horowitz, R. Madachy, D. Reifer, B. K. Clark, B. Steece, A. W. Brown,
S. Chulani, & C. Abts, Software Cost Estimation with COCOMO II, Prentice Hall,
Upper Saddle River, NJ, 2000.
[Brooks, 1995] F. P. Brooks, The Mythical Man Month, Anniversary Edition: Essays on Software
Engineering, Addison-Wesley, Reading, MA, 1995.
[Carr et al., 1993] M. J. Carr, S. L. Konda, I. Monarch, F. C. Ulrich, & C. F. Walker, Taxonomy-Based
Risk Identification, Technical Report CMU/SEI-93-TR-6, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, PA, 1993.
[Charette, 1989] R. N. Charette, Software Engineering Risk Analysis and Management, McGraw-Hill,
New York, 1989.
[Cohn, 2006] M. Cohn, Agile Estimating and Planning, Pearson, Upper Saddle River, NJ, 2006.
[Elssamadisy, 2009] A. Elssamadisy, Agile Adoption Patterns, Addison-Wesley, Reading, MA, 2009.
[Grenning, 2002] J. Grenning, Planning Poker, http://www.planningpoker.com/ 2002.
[Halstead, 1977] M. H. Halstead, Elements of Software Science, Elsevier, New York, 1977.
[IEEE Std. 1058-1998] IEEE Standard for Software Project Management Plans, IEEE Computer Society,
New York, 1998.
[Katzenbach & Smith, 1994] J. R. Katzenbach & D. K. Smith, The Wisdom of Teams: Creating The High-
Performance Organization, Harper Business, 1994.
[Kayser, 1990] T. A. Kayser, Mining Group Gold, Serif, El Segundo, CA, 1990.
[McCabe, 1976] T. McCabe, “A software complexity measure,” IEEE Transactions on Software
Engineering, Vol. 2, No. 12, December 1976.
[Paulish, 2001] D. J. Paulish, Architecture-Centric Software Project Management: A Practical Guide,
SEI Series in Software Engineering, Addison-Wesley, Reading, MA, 2001.
[Portny, 2001] S. E. Portny, Project Management for Dummies, John Wiley & Sons, 2000.
[Rogers et al., 1986] The Presidential Commission on the Space Shuttle Challenger Accident Report.
Washington, DC, June 6, 1986.
[Royce, 1998] W. Royce, Software Project Management: A Unified Framework, Addison-Wesley,
Reading, MA, 1998.
[Schwaber, 1995] K, Schwaber, “Scrum Development Process,” Business Object Design and
Implementation Workshop, OOPSLA’95, Austin, TX, October 1995.
[Schwaber & Beedle, 2002] K. Schwaber & M. Beedle, Agile Software Development with Scrum, Prentice Hall,
Upper Saddle River, 2002.
[Schwaber, 2004] K. Schwaber, Agile Project Management With Scrum, Microsoft, Redwood, 2004.
[Vaughan, 1996] D. Vaughan, The Challenger Launch Decision: Risky Technology, Culture, and
Deviance at NASA, The University of Chicago Press, Chicago, 1996.
[Weinberg, 1971] G. M. Weinberg, The Psychology of Computer Programming, Van Nostrand, New
York, 1971.
[Wigand et al., 1997] R. T. Wigand, A. Picot, & R. Reichwald, Information, Organization and Management:
Expanding Markets and Corporate Boundaries, John Wiley & Sons, London, 1997.
This page intentionally left blank
15

15.1 Introduction: Polynesian Navigation 622

15.2 IEEE 1074: Standard for Developing Life Cycle Processes 626
15.2.1 Processes and Activities 626
15.2.2 Life Cycle Modeling 628
15.2.3 Project Management 628
15.2.4 Pre-Development 629
15.2.5 Development 630
15.2.6 Post-Development 631
15.2.7 Integral Processes (Cross-Development) 632
15.3 Characterizing the Maturity of Software Life Cycle Models 633
15.4 Life Cycle Models 636
15.4.1 Sequential Activity-Centered Models 637
15.4.2 Iterative Activity-Centered Models 639
15.4.3 Entity-Centered Models 644
15.5 Further Readings 647
15.6 Exercises 648
References 649

620
 15
Software Life Cycle

There must always be a discrepancy between concepts and

reality, because the former are static while the latter is dynamic
and flowing.
—Robert Pirsig, in Lila

A software life cycle model represents all the activities and work products necessary to
develop a software system. Life cycle models enable managers and developers to deal with the
complexity of the process of developing software in the same way as an analysis model or a
system design model enables developers to deal with the complexity of a software system. In the
case of software systems, the reality being modeled includes phenomena such as watches,
accidents, trains, sensors, and buildings. In the case of software development, the reality
includes phenomena such as participants, teams, activities, and work products. Many life cycle
models have been published in the literature in an attempt to better understand, measure, and
control the development process. Life cycle models make the software development activities
and their dependencies visible and manageable.
In this chapter, we revisit the activities described in previous chapters from the perspective
of life cycle modeling. The modeling techniques we used for modeling software systems can
also be used to represent life cycles. Whereas life cycle models are usually represented with ad
hoc notations, we try to use UML diagrams whenever possible. First, we describe the typical
activities and work products of a software life cycle as defined by the IEEE standard 1074 [IEEE
Std. 1074-2006]. Next, we introduce the Capability Maturity Model, a framework for assessing
the maturity of organizations and their life cycles. We then discuss different life cycle models
that have been proposed for developing complex software systems; these include the waterfall
model, the spiral model, the V-model, and the unified software process. We also discuss a life cycle
model called the issue-based model, in which products and activities are modeled as a set of
issues stored in a knowledge base. The issue-based model is an entity-centered view of the
software life cycle that can accommodate frequent changes over the duration of a project.

621
622 Chapter 15 • Software Life Cycle

15.1 Introduction: Polynesian Navigation

Polynesian navigation
Polynesia is a large set of islands roughly forming a triangle with Tahiti at the center, Hawaii at the
north, Easter Island at the east, and New Zealand at the southwest. Polynesians came from southeast
Asia, settling Pacific islands systematically from west to east. Polynesians had already completed their
settlement several hundreds of years before Columbus arrived in the Caribbean. They reached Tahiti in
1400 B.C., Hawaii in 500 A.D., and New Zealand sometime between 500 A.D. and 1100 A.D.
Polynesian fishermen would discover a new island opportunistically, identify its location, and tell
people back home. The settlement of the new island was deliberate, involving the transplantation of
families, plants such as bananas, sugar cane, and yams, and domesticated animals such as dogs, pigs,
and chickens.
What makes this feat even more remarkable was that Polynesians were technologically in the Stone
Age. They built multi-hulled canoes with tools of bones and stones and without using any metal. Their
canoes were designed to stay on a specific course and withstand storms, and could sail significantly
faster than the European ships of the time. They transmitted knowledge of seafaring and the location of
islands by word of mouth from one generation to the next.
Polynesians navigated without instruments, relying on the rising and setting of stars, the direction of the
wind, and the swell of the ocean to maintain a course. The people of the island of Truk in Micronesia,
east of Polynesia, have preserved these ancient navigation skills and enable us to speculate about how
Polynesians managed to travel several thousands of kilometers by canoe. Near the equator, stars rise and
set around a north–south axis. Altair, for example, rises in the east and sets in the west. Some stars rise
and set further north: Vega rises in the northeast and sets in the northwest. Other stars rise and set further
south: Antares rises in the southeast and sets in the southwest. When facing the rising point of Vega, the
navigator would turn his back on the setting point of Antares. By memorizing the relative position of 16
stars, the Polynesian navigator could always find a visible star to adjust his course. During the day or
overcast nights, the navigator would use the direction of the wind and the swell of the ocean, which he
would have memorized in relationship with these stars.
Near landfall, the shape and sound of the waves would change. At that point, they looked for specific
species of land-based birds that would fly out to sea in the morning to fish and return to land in the
evening. When spotting these birds in the evening, they would follow their flight. When spotting them
in the morning, they would sail toward their point of origin.
By contrast, the shipbuilders of the age of Columbus had mastered the use of metal for several
thousands of years. Columbus’s logs indicate that he was not a celestial navigator. Instead of following
stars, he used dead reckoning: the helmsman held course by looking at a magnetic compass. Every hour,
the speed of the boat was measured by throwing a piece of flotsam in the water and by measuring the
time it took to clear the length of the ship. By knowing the direction and the speed of the ship at all
times, Columbus could compute the distance he had sailed since leaving port. We know from records
that he did not use a corrected compass, as his course towards America drifted to the south. On his way
back, his course drifted by the same amount to the north, so he did not notice the limitations of the
magnetic compass.
Introduction: Polynesian Navigation 623

The example above illustrates how similar goals can be accomplished with very different
processes. Polynesians evolved their craft of navigation and their knowledge of the stars during
increasingly long ocean trips, as the distance between islands increased significantly as they
moved toward the east. They invented and refined a process that could be repeated accurately
every time a new island was discovered. At the time of Columbus, most navigators stayed close
to the coast, as they sailed toward the East Indies around Africa using dead reckoning. Columbus
applied an existing navigation process to cross the Atlantic. In both cases, the navigator had a
goal (e.g., settling a specific island, finding a transatlantic route to the Indies) and a set of
survival skills applied to local situations that eventually supported that goal (e.g., recognizing
the proximity of islands, ability to set a course, ability to correct a course). If Columbus and the
Polynesians had met and been able to communicate, each could have learned a range of new
skills and modified their respective processes accordingly. This transfer of knowledge, however,
assumes that Columbus and the Polynesians would have been able to share a common model of
navigation.
In the previous chapters, we used UML as a modeling language for describing and
communicating about systems. In this chapter, we focus on models of the software development
process, called software life cycle models. Modeling the software life cycle is a difficult
undertaking because it is a complex and changing system. Like software systems, software life
cycles can be described by several different models. Most proposed life cycle models have
focused on the activities of software development and represented them explicitly as class
objects. This view of the software life cycle is called activity centered. Another view of the
software life cycle is to focus on the work products created by these activities. This other view is
called entity centered. The activity-centered view leads participants to focus on how work
products are created. The entity-centered view leads participants to focus on the content and
structure of the work products. Figure 15-1 depicts a simple life cycle for software development
using three activities: Problem definition, System development, and System operation.
Figure 15-2 shows an activity-centered view of this simplistic life cycle model. The
associations between the activities show a linear time dependency, which is implied by the use of
the activity diagram notation: the problem statement precedes system development, which in
turn precedes system operation. Other time dependencies are possible.
For example, in the software life cycle of Figure 15-3, the activities System development
and Market creation can be done concurrently.
Figure 15-4 is an entity-centered view of the model depicted by Figure 15-2. Software
development produces four entities: a Market survey document, a Requirements
specification document, an Executable system, and a Lessons learned document.
The activity-centered and entity-centered views are complementary, as illustrated by
Figure 15-5. Every product is generated by one or more activities. The Problem definition
activity uses a Market survey document as input and generates a Requirements
specification document. The System development activity takes the Requirements
specification document as input and produces an Executable system. System operation
624 Chapter 15 • Software Life Cycle

Software development
«include» «include»
«include»

Problem definition System development System operation

Client Project manager Developer Administrator End user

Figure 15-1 Simple life cycle for software development (UML use case diagram).

Problem System System

definition development operation
activity activity activity

Figure 15-2 Simple life cycle for software development (UML activity diagram).

System
development
activity
System
upgrade
activity
Market
creation
activity

Figure 15-3 Another simple life cycle (UML activity diagram).

generates a Lessons learned document that could be used during the development of the next
product. Alternatively, every activity generates one or more products.
In Section 15.2, we describe the life cycle activities defined by the IEEE 1074 standard
[IEEE Std. 1074-2006]. This standard introduces precise definitions that enable project
participants to understand and communicate effectively about the life cycle. In this section, we
also describe the information flows between activities.
Introduction: Polynesian Navigation 625

Software Development

Market survey Lessons learned

document document

Requirements specification
document Executable system

Figure 15-4 Entity-centered view of software development (UML class diagram).

Activity Work product

Market survey
consumes document
Problem definition
activity
produces
Specification
consumes document
System development
activity
produces
Executable system
consumes
System operation
activity
produces Lessons learned
document

Figure 15-5 Activities and products of the simple life cycle of Figure 15-2 (UML class diagram).

In Section 15.3, we describe the Capability Maturity Model, a framework for assessing the
maturity of organizations and their life cycles. This framework enables organizations and
projects to be compared based on the activities of their life cycles.
In Section 15.4, we survey several activity-centered life cycle models that propose
different orderings of activities. We discuss two sequential models, the waterfall model [Royce,
1970] and the V-model [Jensen & Tonies, 1979], and two iterative models, the spiral model
[Boehm, 1987] and the Unified Software Process [Jacobson et al., 1999]. We also describe an
entity-based life cycle model based on issues.
626 Chapter 15 • Software Life Cycle

15.2 IEEE 1074: Standard for Developing Life Cycle Processes

The IEEE Standard for Software Life Cycle Processes describes the set of activities and
processes that are mandatory for the development and maintenance of software [IEEE Std.
1074-2006]. Its goal is to establish a common framework for developing life cycle models and
provide examples for typical situations. In this section, we describe the main activities
introduced by the standard and clarify its fundamental concepts using UML diagrams.

15.2.1 Processes and Activities

A process is a set of activities that is performed toward a specific purpose (e.g., requirements,
management, delivery). The IEEE standard lists a total of 17 processes, grouped into higher
levels of abstractions called process groups (Table 15-1). Examples of process groups are
project management, pre-development, development, and post-development. Examples of
processes in the development process group include

• the Requirements Process during which the developers develop the system models
• the Design Process during which developers decompose the system into components
• the Implementation Process during which developers realize each component.

Table 15-1 Software processes in IEEE 1074.

Process group Processes

Life Cycle Modeling Selection of a Life Cycle Model

Project Management Project Initiation

Project Monitoring and Control
Software Quality Management

Pre-Development Concept Exploration

System Allocation

Development Requirements
Design
Implementation

Post-Development Installation
Operation and Support
Maintenance
Retirement

Integral Verification and Validation

Software Configuration Management
Documentation Development
Training
IEEE 1074: Standard for Developing Life Cycle Processes 627

Each process is composed of activities. An activity is a task or group of subactivities that

are assigned to a team or a project participant to achieve a specific purpose. The Requirements
Process, for example, is composed of three activities:

• Define and Develop Software Requirements during which the functionality of the
system is defined precisely
• Define Interface Requirements during which the interactions between the system and
the user are defined precisely
• Prioritize and Integrate Software Requirements during which all requirements are
integrated for consistency and prioritized by client preference.

Tasks consume resources (e.g., personnel, time, money) and produce a work product.
During planning, activities are decomposed into project-specific tasks, are given a start and
ending date, and are assigned to a team or a project participant (Figure 15-6). During the project,
actual work is tracked against planned tasks, and resources are reallocated to respond to
problems.

Software Life Cycle

Money
*

Process Group Time

Participant
*

Process *
Resource

*
Work Unit

consumed by *
*
Activity Task Work Product
produces

Figure 15-6 Model of the software life cycle (UML class diagram). A software life cycle consists of
process groups, which in turn consist of processes. A process accomplishes a specific purpose (e.g.,
requirements, design, installation). A process consists of activities, which in turn consist of subactivities or
tasks. Tasks represent the smallest piece of work that is relevant to management. Tasks consume resources
and produce one or more work products. A project is an instance of a software life cycle.
628 Chapter 15 • Software Life Cycle

The processes required by IEEE 1074 are listed in Table 15-1. From the developers’ point
of view, the first six processes (i.e., the Life Cycle Modeling, the Project Management, and the
Pre-Development Processes) have often already been initiated before their involvement with the
project.

15.2.2 Life Cycle Modeling

During Life Cycle Modeling, the project manager customizes the activities defined in IEEE 1074
for a specific project (i.e., for an instance of a life cycle model). Not all projects require the same
activities and the same sequencing of activities. For example, projects that do not deal with a
persistent storage do not need to execute the activity Design Data Base. The selected life cycle
model serves as input to the Project Initiation Process described in the next section.

15.2.3 Project Management

During Project Management, the project manager initiates, monitors, and controls the project
throughout the software life cycle. Project Management consists of three processes (Table 15-2).
The Project Initiation Process creates the infrastructure for the project. During this
process, the task plan, schedule, budget, organization, and project environment are defined. The
project environment includes project standards, communication infrastructure, meeting and
reporting procedures, development methodology, and development tools. Most of the
Table 15-2 Project management processes.

Process Clausea Activities

Project Initiation 3.1.3 Map Activities to Software Life Cycle Model

3.1.4 Allocate Project Resources
3.1.5 Establish Project Environment
3.1.6 Plan Project Management

Project Monitoring and Control 3.2.3 Analyze Risks

3.2.4 Perform Contingency Planning
3.2.5 Manage the Project
3.2.6 Retain Records
3.2.7 Implement Problem Reporting Model

Software Quality Management 3.3.3 Plan Software Quality Management

3.3.4 Define Metrics
3.3.5 Manage Software Quality
3.3.6 Identify Quality Improvement Needs

a. The Clause Column in this table and the other tables in this chapter refers to a clause number in IEEE 1074.
This is a cross-reference to the standards document as published in [IEEE Std. 1074-2006].
IEEE 1074: Standard for Developing Life Cycle Processes 629

information generated during this process is documented in the Software Project Management
Plan (SPMP). The Project Initiation Process is complete as soon as a stable environment for the
project is established.
The Project Monitoring and Control Process ensures that the project is executed
according to the task plan and budget. If the project manager observes any deviation from the
schedule, she will take corrective action such as reallocating some of the resources, changing
procedures, or replanning the schedule. The SPMP is updated to reflect any of these changes.
The Project Monitoring and Control Process is active throughout the life cycle.
The Software Quality Management Process ensures that the system under construction
meets the required quality standards (which were selected during Project Initiation). This
process is executed by a separate quality management team to avoid conflicts of interest (i.e., the
goal of the developers is to complete the system on time, and the goal of the quality management
team is to ensure that the system is not considered complete until it meets the required quality
standard). The Software Quality Management Process is active throughout most of the life cycle.
We described in Chapter 14, Project Management, the activities of Project Initiation and
Project Monitoring and Control that are related to planning, organization, and tracking. The
activity Establish Project Environment requires particular attention in the context of a team-
based project. One of the critical parts of the project environment is the communication
infrastructure that will support the dissemination of information among the participants. To be
able to react rapidly to changes and report problems without introducing unreasonable
overhead, all project participants need to be aware of the information flow through the project
and the mechanisms for disseminating information. We described in Chapter 3, Project
Organization and Communication, the activities related to defining and using the
communication infrastructure. Note that to define the development team structure, and thereby
the communication infrastructure, the initial system architecture (produced by the System
Allocation Process described in the next section) must first be defined.

15.2.4 Pre-Development
During Pre-Development, management (or marketing) and a client identify an idea or a need.
This can be addressed with a new development effort (greenfield engineering), or a change to the
interface of an existing system (interface engineering), or software replacement of an existing
business process (reengineering). The System Allocation Process establishes the initial system
architecture and identifies hardware, software, and operational requirements. Note that the
subsystem decomposition is the foundation of the communication infrastructure among the
project members. The requirements, subsystem decomposition, and communication
infrastructure are described in the Problem Statement,1 which serves as input for the
Development process. The Pre-Development processes are depicted in Table 15-3.

1. The Statement of Need mentioned in the IEEE 1074 standard is similar to the Problem Statement, but does not
contain any project organization information.
630 Chapter 15 • Software Life Cycle

Table 15-3 Pre-development processes.

Process Clause Activities

Concept Exploration 4.1.3 Identify Ideas or Needs

4.1.4 Formulate Potential Approaches
4.1.5 Conduct Feasibility Studies
4.1.6 Plan System Transition (if Applicable)
4.1.7 Refine and Finalize the Idea or Need

System Allocation 4.2.3 Analyze Functions

4.2.4 Develop System Architecture
4.2.5 Decompose System Requirements

15.2.5 Development
Development consists of the processes directed toward the construction of the system
(Table 15-4).
The Requirements Process starts with the informal description of the requirements and
defines the system requirements in terms of high-level functional requirements, producing a
complete specification of the system and a prioritization of the requirements. We describe the
Requirements Process in Chapter 4, Requirements Elicitation, and Chapter 5, Analysis.
The Design Process takes the architecture produced during the System Allocation Process
and the specification from the Requirements and produces a coherent and well-organized
representation of the system. The activities Perform Architectural Design and Design Interfaces
Table 15-4 Development processes.

Process Clause Activities

Requirements 5.1.3 Define and Develop Software Requirements

5.1.4 Define Interface Requirements
5.1.5 Prioritize and Integrate Software Requirements

Design 5.2.3 Perform Architectural Design

5.2.4 Design Data Base (if Applicable)
5.2.5 Design Interfaces
5.2.6 Select or Develop Algorithms (if Applicable)
5.2.7 Perform Detailed Design

Implementation 5.3.3 Create Test Data

5.3.4 Create Source
5.3.5 Generate Object Code
5.3.6 Create Operating Documentation
5.3.7 Plan Integration
5.3.8 Perform Integration
IEEE 1074: Standard for Developing Life Cycle Processes 631

refine the subsystem decomposition. This also includes the allocation of requirements to
hardware and software systems, the description of boundary conditions, the selection of off-the-
shelf components, and the definition of design goals. The detailed design of each subsystem is
done during the Perform Detailed Design activity. The Design Process results in the definition
of design objects, their attributes and operations, and their organization into packages. By the
end of this activity, all methods and their type signatures are defined. New classes are introduced
to take into account nonfunctional requirements and component-specific details. The Design
process used in this book is described in Chapter 6, System Design: Decomposing the System,
Chapter 8, Object Design: Reusing Pattern Solutions, and Chapter 9, Object Design: Specifying
Interfaces.
The Implementation Process takes the design model and produces an equivalent
executable representation. The Implementation Process includes integration planning and
integration activities. Note that tests performed during this process are independent of those
performed during quality control or Verification and Validation. We describe in Chapter 11,
Testing, the testing and integration aspects of the Implementation.

15.2.6 Post-Development
Post-Development consists of the installation, maintenance, operation and support, and
retirement processes (Table 15-5).
During Installation, the system software is distributed and installed at the client site. The
installation culminates with the client acceptance test according to the criteria defined in the
Project Agreement. Operation and Support is concerned with user training and operation of the
system. Maintenance is concerned with the resolution of software errors, faults, and failures
after the delivery of the system. Maintenance requires a ramping of the software life cycle
Table 15-5 Post-development processes.

Process Clause Activities

Installation 6.1.3 Plan Installation

6.1.4 Distribution of Software
6.1.5 Installation of Software
6.1.7 Accept Software in Operational Environment

Operation and Support 6.2.3 Operate the System

6.2.4 Provide Technical Assistance and Consulting
6.2.5 Maintain Support Request Log

Maintenance 6.3.3 Reapply Software Life Cycle

Retirement 6.4.3 Notify Users

6.4.4 Conduct Parallel Operations (If Applicable)
6.4.5 Retire System
632 Chapter 15 • Software Life Cycle

processes and activities into a new project. Retirement removes an existing system, terminating
its operations or support; this occurs when the system is upgraded or replaced by a new system.
To ensure a smooth transition between the two systems, both systems are often run in parallel
until the users have gotten used to the new system. Except for client delivery and acceptance, we
do not address the post-development processes in this book.

15.2.7 Integral Processes (Cross-Development)

Several processes take place during the complete duration of the project. These are called
Integral processes (we also use the term cross-development processes) and include Validation
and Verification, Software Configuration Management, Documentation Development, and
Training (Table 15-6).
Verification and Validation includes verification and validation tasks. Verification tasks
focus on showing that the system models comply with the specification. Verification includes
reviews, audits, and inspections. Validation tasks ensure that the system addresses the client’s
needs and includes system testing, beta testing, and client acceptance testing. Verification and
Validation activities occur throughout the life cycle with the intent of detecting anomalies as
early as possible. For example, each model could be reviewed against a checklist at the end of
the process that generated it. The review of a model, say the design model, may result in the
modification of a model generated in other processes, say the analysis model. The activity
Table 15-6 Integral processes (also called cross-development processes).

Process Clause Activities

Verification and Validation 7.1.3 Plan Verification and Validation

7.1.4 Execute Verification and Validation Tasks
7.1.5 Collect and Analyze Metric Data
7.1.6 Plan Testing
7.1.7 Develop Test Requirements
7.1.8 Execute the Tests

Software Configuration 7.2.3 Plan Configuration Management

Management 7.2.4 Develop Configuration Identification
7.2.5 Perform Configuration Control
7.2.6 Perform Status Accounting

Documentation Development 7.3.3 Plan Documentation

7.3.4 Implement Documentation
7.3.5 Produce and Distribute Documentation

Training 7.4.3 Plan the Training Program

7.4.4 Develop Training Materials
7.4.5 Validate the Training Program
7.4.6 Implement the Training Program
Characterizing the Maturity of Software Life Cycle Models 633

Collect and Analyze Metric Data generates project data that can also serve for future projects
and contribute to the knowledge of the organization. The activities Plan Testing and Develop
Test Requirements can be initiated as early as after the completion of the requirements. In large
projects, these tasks are performed by different participants than the developers. We describe
mechanisms for reviews, audits, and inspections in Chapter 3, Project Organization and
Communication. We describe specific reviews associated with requirements elicitation, analysis,
and system design in Chapters 4, 5, and 6, respectively. We describe testing activities in
Chapter 11, Testing.
The Configuration Management Process focuses on the tracking and control of changes of
work products. Items under configuration management include the source code for the system,
all development models, the software project management plan, and all documents visible to the
project participants. We describe configuration management in Chapter 13, Configuration
Management.
The Documentation Process deals with the work products (excluding code), documenting
the results produced by the other processes. Document templates are selected during this
activity. The IEEE 1074 standard, however, does not prescribe any specific document or
template. Development and cross-development specific documentation issues are discussed in
chapters where documents are produced (e.g., Chapter 5, Analysis, discusses the Requirements
Analysis Document; Chapter 13, Configuration Management, discusses the Software
Configuration Management Plan).

15.3 Characterizing the Maturity of Software Life Cycle Models

In the previous section we introduced the activities and artifacts that constitute a software life
cycle. Which of these activities and artifacts are chosen for a specific project is not defined by
the standard. One of the goals of the Capability Maturity Model (CMM) is to provide
guidelines for selecting life cycle activities. The CMM assumes that the development of
software systems is made more predictable when an organization uses a well-structured life
cycle process, visible to all project participants, and when the organization adapts to change.
CMM uses the following five levels to characterize the maturity of an organization [Paulk et al.,
1995]:
Level 1: Initial. An organization on the initial level applies ad hoc activities to develop
software. Few of these activities are well defined. The success of a project on this maturity level
usually depends on the heroic efforts and skills of key individuals. From the client’s point of
view, the software life cycle model, if it exists at all, is a black box: after providing the problem
statement and negotiating the project agreement, the client must wait until the end of the project
to inspect the deliverables of the project. During the duration of the project, the client has
effectively no way to interact with project management.
Level 2: Repeatable. Each project has a well-defined software life cycle model. Models,
however, differ among projects, reducing the opportunity for teamwork and reuse of know-how.
634 Chapter 15 • Software Life Cycle

Basic project management processes are used to track cost and schedule. New projects are based
on the experience of the organization with similar previous projects and success is predictable
for projects in similar application domains. The client interacts with the organization at well-
defined points in time, such as client reviews and the client acceptance test, allowing some
corrections before delivery.

Level 3: Defined. This level uses a documented software life cycle model for all managerial
and technical activities across the organization. A customized version of the model is produced
at the beginning of each project during the Life Cycle Modeling activity. The client knows the
standard model and the model selected for a specific project.

Level 4: Managed. This level defines metrics for activities and deliverables. Data are
constantly collected during the duration of the project. As a result, the software life cycle model
can be quantitatively understood and analyzed. The client is informed about risks before the
project begins and knows the measures used by organization.

Level 5: Optimized. The measurement data are used in a feedback mechanism to improve the
software life cycle model over the lifetime of the organization.The client, project managers, and
developers communicate and work together during the development of the project.
To be able to measure the maturity of an organization, a set of key process areas (KPA)
has been defined by the Software Engineering Institute (SEI). To achieve a specific level of
maturity, the organization must demonstrate that it addresses all the key process areas defined
for that level. Some of these key process areas go beyond activities defined in the IEEE 1074
standard. Table 15-7 shows a mapping between maturity level and key process areas.
Table 15-7 Mapping process maturity level and key process areas.

Maturity Level Key Process Area

1. Initial Not applicable

2. Repeatable Focus: Establish basic project management controls.

• Requirements management: Requirements are baselined in a project agreement
and maintained during the project.
• Project planning and tracking: A software project management plan is established
at the beginning of the project and is tracked during the project.
• Subcontractor management: The organization selects and effectively manages
qualified software subcontractors.
• Quality assurance management: All deliverables and process activities are
reviewed and audited to verify that they comply with standards and guidelines
adopted by the organization.
• Configuration management: A set of configuration management items is defined
and maintained throughout the entire project.
Characterizing the Maturity of Software Life Cycle Models 635

Table 15-7 Continued.

Maturity Level Key Process Area

3. Defined Focus: Establish an infrastructure that allows a single effective software life cycle
model across all projects.
• Organization process focus: The organization has a permanent team to constantly
maintain and improve the software life cycle model.
• Organization process definition: A standard software life cycle model is used for
all projects in the organization. A database is used for software life cycle-related
information and documentation.
• Training program: The organization identifies the needs for training for specific
projects and develops training programs.
• Integrated software management: Each project team can its tailor its specific
process from the standard process.
• Software product engineering: The software is built in accordance with the
defined software life cycle, methods, and tools.
• Intergroup coordination: The project teams interact with each other to address
requirements and issues.
• Peer reviews: Developers examine each other’s deliverables to identify potential
defects and areas where changes are needed.

4. Managed Focus: Quantitative understanding of the software life cycle process and deliverables.
• Quantitative process management: Productivity and quality metrics are defined
and constantly measured across the project. It is critical that these data are not
immediately used during the project, in particular to assess the performance of
developers, but are stored in a database to allow for comparison with other
projects.
• Quality management: The organization has defined a set of quality goals for
software products. It monitors and adjusts the goals and products to deliver high-
quality products to the user.

5. Optimized Focus: Keep track of technology and process changes that may cause changes in the
system model or deliverables, even during a project.
• Defect prevention: Failures in past projects are analyzed, using data from the
metrics database. If necessary, specific actions are taken to prevent those defects
from occurring again.
• Technology change management: Technology enablers and innovations are
constantly investigated and shared throughout the organization.
• Process change management: The software process is constantly refined and
changed to deal with inefficiencies identified by the software process metrics.
Constant change is the norm, not the exception.
636 Chapter 15 • Software Life Cycle

15.4 Life Cycle Models

Figure 15-7 depicts the information flow among processes in the IEEE 1074 standard. The
complexity of the standard is significant as can be seen in the many dependencies among the
processes. Each association represents a work product that is generated by one process and
consumed by another process. Each association also represents a formal communication channel
between project participants supported by the exchange of documents, models, or code.

Development processes Management processes Integral processes

Concept
Exploration
Process

System
Allocation
Process

Requirements Project Configuration

Process Initiation Management
Process Process

Design
Process

Implementation Project Documentation

Process Monitoring & Development
Ctrl Process Process

Installation
Process

Operation S/W Quality Training

& Support Management Process
Process Process

Maintenance
Process Verification
& Validation
Process

Retirement
Process

Figure 15-7 Process interrelationships in the IEEE 1074 standard (UML activity diagram, adapted from
[IEEE Std. 1074-2006]). As suggested by this picture, dependencies among processes and activities are
complex and seldom allow a sequential execution of processes.
Life Cycle Models 637

In this section we review several life cycle models. Most of these models focus on the
development processes exclusively.

15.4.1 Sequential Activity-Centered Models

We start with activity-centered life cycle models. The oldest software life cycle model is the
waterfall model, which prescribes a sequential execution of the activities. The V-model is a
variation of the waterfall model that introduces different levels of abstractions for the activities.

Waterfall model

The waterfall model, first described by Royce [Royce, 1970], is an activity-centered life
cycle model that prescribes sequential executions of subsets of the development processes and
management processes described in the previous section (Figure 15-8).

Project
Initiation
Process

Concept
Exploration
Process

System
Allocation
Process

Requirements
Process

Design
Process

Implementation
Process

Verification
& Validation
Process

Installation
Process

Operation &
Support Process

Figure 15-8 The waterfall model of software development is an activity-centered view of the software life
cycle. Software development activities are performed in sequence (UML activity diagram adapted from
[Royce, 1970] using IEEE 1074 names; project management and cross-development processes are omitted).
638 Chapter 15 • Software Life Cycle

All requirements activities are completed before the system design activity starts. The goal
is never to turn back once an activity is completed. The key feature of this model is the constant
verification activity (called “verification step” by Royce) which ensures that each development
activity does not introduce unwanted or delete mandatory requirements. This model provides a
simple (or even simplistic) view of software development that measures progress by the number
of tasks that have been completed. The model assumes that software development can be
scheduled as a step-by-step process that transforms user needs into code.

V-Model

The V-model is a variation of the waterfall model that makes explicit the dependency
between development activities and verification activities. The difference between the waterfall
model and the V-model is that the latter depicts the level of abstraction. All activities from
requirements to implementation focus on building an increasingly detailed representation of the
system, whereas all activities from implementation to operation focus on validating the system.
Figure 15-9 depicts the V-model.

System
Requirements Operation
Analysis

Software Client
Requirements Acceptance
Elicitation

Requirements System
Analysis Integration
& Test

Preliminary Component
Design Integration
& Test

Detailed Unit
Design Test

Implementation

Figure 15-9 V-model of software development (UML activity diagram; adapted from [Jensen & Tonies,
1979]). The horizontal object flow denotes the information flow between activities at the same abstraction
level. The V-shape layout of the activities was conserved to reflect the original drawing. However, the layout
of the activities has no semantics in UML.
Life Cycle Models 639

Higher levels of abstractions of the V-model deal with the requirements in terms of
elicitation and operation. The middle level of the V-model focuses on mapping the problem into a
software architecture. The lower level of the V-model focuses on details such as the assembly of
software components and the coding of new ones. For example, the goal of the Unit Test activity
is to validate units against their description in the detailed design. The Component Integration
and Test activity validates functional components against the preliminary (or high-level) design.
In many aspects, the waterfall model and its variants are simplistic abstractions of the software
development process. The weakness of these models is that they assume that after an activity is
finished and reviewed, the associated work product can be baselined. Such an idealized model is
appropriate only if the specification of the requirements is highly reliable and stable. In practice,
system development rarely conforms to this ideal model. Changes during an activity often
require reworking a prior activity.

15.4.2 Iterative Activity-Centered Models

Boehm’s spiral model and the more recent Unified Process model are based on the iterative
execution of activities.

Spiral model
Boehm’s spiral model [Boehm, 1987] is an activity-centered life cycle model that was
devised to address the source of weaknesses in the waterfall model, in particular, to
accommodate infrequent change during the software development. It is based on the same
activities as the waterfall model; however, it adds several activities such as risk management,
reuse, and prototyping to each activity. These extended activities are called cycles or rounds.
The spiral model focuses on addressing risks incrementally, in order of priority. Each
round is composed of four phases (Figure 15-10). During the first phase (upper left quadrant),
developers explore alternatives, define constraints, and identify objectives. During the second
phase (upper right quadrant), developers manage risks associated with the solutions defined
during the first phase. During the third phase (lower right quadrant), developers realize and
validate a prototype or the part of the system associated with the risks addressed in this round.
The fourth phase (lower left quadrant) focuses on planning the next round based on the results of
the current round. The last phase of the round is usually conducted as a review involving the
project participants, including developers, clients, and users. This review covers the products
developed during the previous and current rounds and the plans for the next round. Boehm’s
spiral model distinguishes the following rounds: Concept of Operation, Software Requirements,
Software Product Design, Detailed Design, Code, Unit Test, Integration and Test, Acceptance
Test, and Implementation.2

2. Note that the figure illustrates only the first three activities (Concept of Operation, Software Requirements, and
Software Product Design). The rounds for the remaining activities—Detailed Design, Code, Unit Test, Integration
and Test, Acceptance Test—are not shown in detail, but only as blocks at the end of the last layer of the spiral.
640 Chapter 15 • Software Life Cycle

Each round follows the waterfall model and includes the following activities:

1. Determine objectives
2. Specify constraints
3. Generate alternatives
4. Identify risks
5. Resolve risks
6. Develop and verify next-level product
7. Plan.

The first two activities define the problem addressed by the current cycle. The third
activity, Generate alternatives, defines the solution space. The activities Identify risks and
Resolve risks identify future problems that may result in high cost or cancellation of the project.
The activity Develop and verify next-level product is the realization of the cycle. The activity
Plan is a management activity to prepare for the next cycle. These rounds can be viewed in a

Determine objectives, Evaluate alternatives,

alternatives, & constraints identify & resolve risks

Risk
analysis

Risk
analysis
Risk
analysis
P1
Prototype3
Prototype2
Prototype1
Concept of
Requirements operation
plan
Software System
Requirements Product Detailed
Design Design
Development Requirements
plan validation
P2
Code

Integration Design Unit Test

plan validation Develop & verify
Plan next phase next level product
Integration & Test
Acceptance
Test

Figure 15-10 Boehm’s spiral model (adapted from [Boehm, 1987]). The distance from the origin
represents the cost accumulated by the project. The angle from the horizontal represents the type of activity.
For example, the project P1 is currently in the risk analysis activity associated with software requirements.
The project P2 is in the development of the system product design.
Life Cycle Models 641

polar-coordinate system shown in Figure 15-10. The first round, Concept of Operation, starts in
the upper left quadrant. Subsequent rounds are represented as additional layers on the spiral. The
notation makes it easy to determine the status of the project at any time. The distance from the
origin is the cost accumulated by the project. The angular coordinate indicates the progress
accomplished within each phase.

Unified Software Development Process

The Unified Software Development Process (also called the Unified Process) is a life
cycle model proposed by Booch, Jacobson, and Rumbaugh [Jacobson et al., 1999]. The unified
process distinguishes important time ranges called cycles in the lifetime of a software system.
Note that these are different from the cycles in the spiral model: they can be thought of as
characterizing the stage of maturity of the software system during its lifetime. Cycles have no
specific names. However, starting with the “birth” of the system, we can think of the system to
be in the “childhood,” “adulthood,” or “retirement” cycle until it “dies.” A cycle generally ends
with a release of the system as a product to a customer. Each cycle can be in one of four states
called phases: Inception, Elaboration, Construction, and Transition (see Figure 15-11). During
the inception phase, the scope of the system is established, in particular what should be included
and not included. This phase also identifies the use cases that will drive the trade-off decisions
between conflicting design goals; these use cases are also called the core use cases. At least one
candidate software architecture is identified, and the core use cases are demonstrated against this
architecture. A first estimation and schedule for the entire project, including detailed estimates
for the elaboration phase, are also established during this phase.
During the elaboration phase, the user’s view of the requirements is captured in a
repository. The software architecture is designed, and an initial set of build vs. buy decisions is
made, so that cost, schedule, and resource estimates can be derived. During the construction
phase, components are bought or built, and the release is compared with the acceptance criteria.
The transition phase is entered when the baselined system is mature enough for deployment to
the user community.

Inception Elaboration

Transition Construction

Figure 15-11 States of a software system called phases in the Unified Process. The Unified Process
distinguishes four phases: inception, elaboration, construction, and transition (UML state machine diagram).
642 Chapter 15 • Software Life Cycle

Each phase can consist of a number of iterations. Each iteration addresses a set of related
use cases or mitigates some of the risks identified at the beginning of the iteration. An iteration
in the Unified Process is generally associated with a project as we defined it in Chapter 14,
Project Management.
For the duration of each iteration, several activities are performed in parallel. To
emphasize the parallelism and the fact that they are active across the complete iteration, these
activities are called workflows in the Unified Process.3 Development-oriented workflows are
called engineering workflows. The Unified Process distinguishes between Requirements,
Design, Implementation, and Test as engineering workflows (Figure 15-12). These workflows
have already been described in previous chapters of this book. The Requirements workflow
involves analysis of the application domain and creation of requirements artifacts such as the
analysis model (see Chapter 5). The Design workflow focuses on the creation of solution and
design artifacts such as the system design model (see Chapter 6) or the object design model (see
Chapter 8). The Implementation workflow realizes the solution in source code (see Chapter 10).
The Test workflow is involved in the testing of the models and the maintenance of
implementation and deployment artifacts (source code) (see Chapter 11).
The Unified Process distinguishes four cross-functional activities called supporting
workflows: Management, Environment, Assessment, and Deployment. The Management
workflow addresses all planning aspects for the software system as described in Chapter 14. The
Environment workflow is concerned with the automation of the software process itself and

Management Unified Process

Software Life cycle
Environment
releases
Requirements Product
*
Design Workflow Cycle
*
Inception
Implementation 4
Phase Elaboration
Assessment
Construction
Deployment *
Artifact * Iteration Transition

Figure 15-12 Workflows in the unified software life cycle used by Royce [Royce, 1998] (UML class
diagram).

3. The Unified Process does not follow the naming conventions in the IEEE standard. Workflows can be considered as
special activities spanning more than one iteration (project). Engineering workflows are project functions because
their duration is the same as the duration of an iteration, i.e., the project. The term supporting workflow can be
equated with integral process.
Life Cycle Models 643

maintenance of the development environment, in particular the infrastructure for communication

and configuration management. The Assessment workflow assesses processes and products
needed for reviews, walkthroughs, and inspections. The Deployment workflow enables the
transition of the software system to the end user.
The Unified Process emphasizes the staging of resources for each of the workflows during
phases and iterations, thereby coupling project management issues very closely with software
life cycle issues (see Figure 15-13). This is done by managing each iteration as a software
project, as described in Chapter 14, Project Management. Because the duration of the workflows
is the duration of the project, they can be seen as project functions with differing phase-specific
needs. For example, during the Elaboration phase, the Requirements workflow needs most of
the resources, while the Implementation workflow resource requirements are less. During the
Construction phase, the resource needs for the Requirements workflow diminish, and the Design
and Implementation workflows need increasingly more resources.
Figure 15-14 shows an entity-centered view of the Unified Process as a set of models. The
requirements are captured in the use case model. The analysis model describes the system as a
set of classes. The design model defines the structure of the system as a set of subsystems and
interfaces, and the deployment model defines the distribution across. The implementation model
maps the classes to components, and the test model verifies that the executable system provides
the functionality described in the use case model.

Inception Elaboration Construction Transition

Iter.#1 Iter.#2 Iter.#1 Iter.#2 Iter.#3 Iter.#1 Iter.#2 Iter.#1 Iter.#2

Management Workflow

Environment Workflow

Requirements Workflow

Design Workflow

Implementation Workflow

Assessment Workflow

Deployment Workflow
Time

Figure 15-13 The seven workflows in the Unified Process–Management, Environment, Requirements,
Design, Implementation, Assessment, and Deployment–are project functions performed during the entire
lifetime of a system. Each of the workflows has different resource needs depending on the phase and
iteration of the software system. The histograms for each workflow indicate the amount of work per
iteration—the higher the block, the more resources are consumed by the workflow in that iteration (adapted
from [Jacobson et al., 1999] and [Royce, 1998]).
644 Chapter 15 • Software Life Cycle

All models are related to each other through traceability dependencies. A model element
can be traced to at least one element in an associated model. For example, every use case has a
traceable relationship with at least one class in the analysis model. Traceability allows us to
understand the effect of change in one model on other models, in particular, it allows us to
provide traceability in the requirements.
The dependencies between the models in Figure 15-14 can be maintained in different
ways. During forward engineering, analysis and design models are established from the use
case model, and the implementation model and test models are then generated from these
models. During reverse engineering, the analysis and design models are extracted or updated
from existing code. Round-trip engineering is a combination of reverse and forward
engineering. It allows the developer to switch between these development modes at any time,
depending on which model is undergoing the most amount of change.

Use case model

specified by

realized by
Analysis model
distributed by

Design model
implemented by

Deployment model
verified by
Implementation
model

Test model

Figure 15-14 Entity-centered life cycle view of the models of the Unified Process (UML class diagram).
The dependencies depict traceability. There are dependencies between all models. Only the dependencies
between the use case model and the other models are shown [Jacobson et al., 1999].

15.4.3 Entity-Centered Models

If the time between changes is significantly smaller than the duration of an activity, and if
changes can occur in the application domain as well as in the solution domain, both the waterfall
model and the spiral model exhibit problems. For example, assume that the development team
selects the hardware platform and that new platforms appear every three to four years. As long
as the project time is significantly less than three years, the knowledge of the development team
at the beginning of the project is usually sufficient to select a platform once during system
design. However, if a new platform appears every three to four months and the duration of the
Life Cycle Models 645

project is also three or four months, the platform decision will probably have to be reconsidered
during the project.
In this section, we describe an entity-centered life cycle model, called the issue-based life
cycle model, that aims at dealing with frequent changes. This model is based on the rationale
behind the system as an issue model (Chapter 12, Rationale Management). Each project starts
with a set of issues. If the project starts from scratch, these issues are drawn from the project
manager’s experience or from a standard template. In a reengineering or interface project, issues
may be available from the rationale of the previous project. If the project has a long history, the
rationale should be well populated. Examples of issues are What should be the initial teams?
Should the mechanic have access to driver-specific information? What is the appropriate
middleware? What software architecture should we use? and Which implementation language
should we use? All issues are stored in an issue base accessible to project participants.
The status of an issue can be closed or open. A closed issue is an issue that has been
resolved. For example, a closed issue can be a decision about the platform on which the system
should run (e.g., Solaris). Closed issues can be reopened, however, as changes occur in the
application or solution domain. For example, if we need to support additional platforms (e.g.,
Linux and Windows NT), we reopen the issue, reevaluate the alternatives, and provide a new
resolution. Open issues are resolved by discussion and negotiation among project participants
(see Chapter 3, Project Organization and Communication). An issue i2 depends on another
issue i1 if the resolution of i1 constrains the alternatives available for i2. Tracking the
dependencies among issues enables developers to assess the impact of revisiting a given issue.
The issue base also tracks dependencies among issues. Figure 15-15 shows a snapshot of the
issue base of a project, depicting the issue status and dependencies.

i1:Issue
status={Closed} i4:Issue
status = {Open}
i2:Issue
status = {Open} i5:Issue
status={Closed}

i3:Issue
status = {Open}

i6:Issue
status = {Open}

Figure 15-15 Snapshot of a project issue base (UML object diagram). Issues i1 and i5 have been
resolved, whereas all other issues are still open. Dependencies among issues indicate that the resolution of
an issue can constrain the alternatives for dependent issues.
646 Chapter 15 • Software Life Cycle

Issues can be mapped to the activities of life cycle models described earlier. For example,
assume the activities Planning and System Design are part of the selected life cycle model. How
do we set up the initial teams? can be categorized as a planning issue, and What software
architecture shall we use? can be categorized as a system design issue. The status of issues can
then be used to track the status of each activity. If any system design issues are still open, the
System Design activity has not yet been completed. The life cycle models we described earlier
can then be seen as special cases of the issue-based model. In the Waterfall model, for example,
developers completely resolve the issues associated with an activity before moving to the next
activity. Figure 15-16 depicts the state of a project during System Design.
In Boehm’s spiral model, risks correspond to issues that are evaluated and reopened at the
beginning of each round. Issues are resolved in the order of their priority as defined during risk
analysis. Note, however, that “issue” is a more general concept than “risk.” For example, the
issue Which access control model should we use? is a design problem, not a risk.
In the general case (Figure 15-17), all activities may still have associated open issues,
which means that all activities must be managed concurrently. The goal of the project manager is
to keep the number of open issues small and manageable without imposing time or activity-
based constraints on the resolution of issues. Using issues and their dependencies for managing
the life cycle activities allows all life cycle activities to proceed concurrently.

Req. Elicitation Analysis

i1:Issue i4:Issue
status={Closed} status={Closed}

i2:Issue
i5:Issue
status={Closed}
status={Closed}

i3:Issue
status={Closed} System Design

i6:Issue
status = {Open}

Figure 15-16 The waterfall model as a special case of the issue-based life cycle model (UML object
diagram). All issues that belong to the same issue category are contained in the same UML package. In the
project status shown in the figure, all the requirements elicitation and analysis issues have been closed; that
is, the requirements elicitation and analysis activities have been completed.
Further Readings 647

Req. Elicitation Analysis

i1:Issue i4:Issue
status={Open} status={Open}

i2:Issue
i5:Issue
status={Closed}
status={Closed}

i3:Issue
status={Closed} System Design

i6:Issue
status = {Open}

Figure 15-17 In a complex project state, all activities can still have some open issues, which means that
all activities need to be managed concurrently.

15.5 Further Readings

Waterfall-based software life cycle models are still widely used. Into the 1990s, software
companies contracted by the U.S. Department of Defense, for example, were required to use the
2167A standard [DoD-STD-2167A], which was based on the waterfall model. The sawtooth
model [Rowen, 1990] was an attempt to improve the V-model by solving discrepancies between
the user and software developer’s perception of the system at different levels of abstractions over
time.
ISO/IEC 12207: 1995 Standard for Information Technology–Software life cycle processes
[ISO/IEC 12207, 1995] is a framework for software life cycle processes, with well-defined
terminology, processes, activities, and tasks to be applied during the acquisition, supply,
development, operation, and maintenance of software. This standard is occasionally (and
erroneously) thought to be a replacement for IEEE 1074, the standard covered in this chapter
[IEEE Std. 1074-2006]. ISO/IEC 12207 is a high-level description of the activities needed in a
two-party relationship, one acquiring software, the other supplying software. It describes an
architecture for software life cycles, but does not specify details about how particular activities
should be implemented or performed. The IEEE 1074 standard is at a lower level of abstraction,
as it is targeted for the user who needs to build a specific software life cycle for project or set of
projects. For example, IEEE 1074 specifies dependencies and interfaces between the activities in
terms of documents and work products. IEEE has subsequently adopted ISO/IEC 12207 as
648 Chapter 15 • Software Life Cycle

IEEE/EIA 12207.0-1996 with the addition of guidance and clarifications and revised IEEE 1074
in 1997 so that both standards are compatible [IEEE/EIA, 1996].
The Unified Process is becoming the de facto standard for iterative activity-centered
software life cycle models. It has its roots in the Objectory process described in [Jacobson et al.,
1992] and [Jacobson et al., 1995]. Objectory was the basis for the Rational Unified Process
[Kruchten, 1998], which in turn formed the basis for the Unified Process.

15.6 Exercises
15-1 Model as classes the activities of Figure 15-2 and the work products of Figure 15-4 and
draw a UML class diagram depicting the relationships between activities and work
products.
15-2 Assume that the waterfall model shown in Figure 15-8 has been derived from the IEEE
standard model in Figure 15-7 during the activity Life Cycle Modeling. What processes
and activities have been omitted in the waterfall model?
15-3 Redraw Boehm’s spiral model in Figure 15-10 as a UML activity diagram. Compare
the readability of the original figure with the activity diagram.
15-4 Draw a UML activity diagram describing the dependency between activities for a life
cycle in which requirements, design, implementation, test, and maintenance occur
concurrently. (This is called an evolutionary life cycle.)
15-5 Describe how testing activities can be initiated well before implementation activities.
Explain why this is desirable.
15-6 In project management, a relationship between two tasks is usually interpreted as a
precedence relationship; that is, one task must complete before the next one is initiated.
In a software life cycle, a relationship between two activities is a dependency; that is,
one activity uses a work product from another activity. Discuss this different. Provide
an example in the context of the V-model.
15-7 Assume you are part of the IEEE committee that will revise the IEEE 1074 standard.
You have been assigned the task of modeling communication as an explicit integral
process. Make a case for the activities that would belong to this process.
References 649

References
[Boehm, 1987] B. Boehm, “A spiral model of software development and enhancement,” Software
Engineering Project Management, pp. 128-142, 1987.
[DoD-STD-2167A] DoD-STD-2167A, Military Standard, Defense Systems Software Development, US
Department of Defense, Washington, DC, 1988.
[IEEE Std. 1074-2006] IEEE Standard for Developing Software Life Cycle Processes, IEEE Computer
Society, New York, 2006.
[IEEE/EIA, 1996] IEEE/EIA 12207.0-1996. Industry Implementation of International Standard ISO/
IEC 12207: 1995 Standard for Information Technology–Software life cycle
processes, IEEE Computer Society & Electronic Industries Association, March
1998.
[ISO/IEC 12207, 1995] ISO/IEC 12207, Information technology–Software life cycle processes, International
Organization for Standardization & International Electrotechnical Commission,
August 1995.
[Jacobson et al., 1992] I. Jacobson, M. Christerson, P. Jonsson, & G. Overgaard, Object-Oriented Software
Engineering—A Use Case Driven Approach, Addison-Wesley, Reading, MA, 1992.
[Jacobson et al., 1995] I. Jacobson, M. Ericsson, & A. Jacobson, The Object Advantage: Business Process
Reengineering with Object Technology, Addison-Wesley, Reading, MA, 1995
[Jacobson et al., 1999] I. Jacobson, G. Booch, & J. Rumbaugh, The Unified Software Development Process,
Addison-Wesley, Reading, MA, 1999.
[Jensen & Tonies, 1979] R. W. Jensen & C. C. Tonies, Software Engineering, Prentice Hall, Englewood
Cliffs, NJ, 1979.
[Kruchten, 1998] P. Kruchten, The Rational Unified Process: An Introduction, Addison-Wesley,
Reading, MA, 1998.
[Paulk et al., 1995] M. C. Paulk, C. V. Weber, & B. Curtis (eds.), The Capability Maturity Model:
Guidelines for Improving the Software Process, Addison-Wesley, Reading, MA,
1995.
[Rowen, 1990] R. B. Rowen, “Software project management under incomplete and ambiguous
specifications,” IEEE Transactions on Engineering Management, Vol. 37, No. 1,
1990.
[Royce, 1970] W. W. Royce, “Managing the development of large software systems,” in Tutorial:
Software Engineering Project Management, IEEE Computer Society, Washington,
DC, pp. 118–127, 1970.
[Royce, 1998] W. Royce, Software Project Management: A Unified Framework, Addison-Wesley,
Reading, MA, 1998.
16

16.1 Introduction: The First Ascent of K2 652

16.2 Project Environment 655
16.3 Methodology Issues 657
16.3.1 How Much Planning? 657
16.3.2 How Much Reuse? 658
16.3.3 How Much Modeling? 659
16.3.4 How Much Process? 661
16.3.5 How Much Control and Monitoring? 661
16.3.6 When to Redefine Project Goals? 662
16.4 A Spectrum of Methodologies 662
16.4.1 Royce’s Methodology 663
16.4.2 Extreme Programming 669
16.4.3 Rugby methodologies 673
16.5 Case Studies 680
16.5.1 XP Project: ATRACT 681
16.5.2 Local King Client: FRIEND 684
16.5.3 Distributed Project: JAMES 691
16.5.4 Case Studies Summary 698
16.6 Further Readings 703
16.7 Exercises 703
References 704

650
 P 16
Methodologies:
Putting It All Together
We should be careful to get out of an experience only the
wisdom that is in it—and stop there; lest we be like the cat that
sits down on a hot stove-lid. She will never sit down on a hot
stove-lid again—and that is well; but also she will never sit
down on a cold one anymore.
—Mark Twain, Following the Equator: A Journey
Around the World

I n the previous chapters, we described a range of development and management methods

covering many different aspects of complex and changing software systems. For dealing with
system and application domain complexity, we described methods such as use case modeling,
object modeling, applying architectural styles, reusing design patterns, and mapping of models
to source code. For communicating knowledge about the system, we discussed UML diagrams,
issue models, informal communication mechanisms, and documents. For dealing with change,
we examined a variety of organizations, processes, and life cycles.
By now, you have an overview of the current state of the art of methods in object-oriented
software engineering, which you can view as a thick cookbook of recipes. In practice, however,
a cookbook is rarely enough for the novice to cook a complete meal. Moreover, not all
ingredients are always available, and the cook has to improvise to bridge the gaps.
In this chapter, we present methodologies as guidance for the manager to select and
customize the recipe to the specific project environment. The discussion about the right
methodology for software development is far from over. We present a design space ranging from
light-weight approaches to heavy-weight approaches. The idea is to help you understand this
space for yourself when organizing and running software projects. Although we cannot replace
experience with a book, we provide actual project examples to illustrate how trade-offs are made
when defining, setting up, and running a software project.
We also present case studies conducted as software engineering project courses that cover
a wide range from a four-month, two-developer project collocated with the client to a
distributed, one-year, 100-person project with a remote client. In each of these case studies we
describe the selection of specific methods and techniques. All of our case studies involve actual
clients and developers who are technically fluent with respect to programming, but new to
software engineering concepts.

651
652 Chapter 16 • Methodologies: Putting It All Together

16.1 Introduction: The First Ascent of K21

When Mount Everest (8,850 m) was successfully climbed with oxygen in 1953—after many
unsuccessful attempts without oxygen—it was assumed that one had to use oxygen to reach a summit in
such an extreme altitude. When the second highest peak K2 (8,611 m) was attempted by an Italian
expedition in 1954, oxygen was included in the equipment list.
Unplanned bivouac on K2
On July 30, 1954, Walter Bonatti and high-altitude porter Mahdi started at Camp 8 with a crucial carry
of oxygen to Camp 9. The oxygen load was for the lead climbers Achille Compagnoni and Lino
Lacedelli, who had arrived at Camp 9 earlier. The expedition leader had selected them as candidates for
the final summit push, and the oxygen was intended to help them climb in the extreme altitude. When
Bonatti and Mahdi arrived at the location of the agreed Camp 9 spot, they could not find anybody.
Constantly searching for Compagnoni and Lacedelli, they eventually established voice communication
with the lead climbers, but they were not able to join them. Around 9:30 P.M. they were forced to
bivouac.
An unplanned bivouac at an altitude of 8,100 m is a very serious affair. Bonatti and Mahdi endured a
horrible night in a snow blizzard without any protection from the winds. Unbelievably, Bonatti came out
of the ordeal unhurt, but Mahdi got severe frostbite and eventually had to undergo various amputations
on his fingers and toes. The next day, Bonatti and Mahdi left their load at the bivouac site and stumbled
down to Camp 8. Compagnoni and Lacedelli left their tent, went to the bivouac site to pick up the
oxygen and started for the summit. In the official account of the climb, Compagnoni and Lacedelli ran
out of oxygen about 200 m below the summit, which they reached at 6 P.M. Some of the summit pictures
show the oxygen packs at their feet.
Discussion
The fact that Bonatti was unscathed from the bivouac led to many accusations, in particular that he had
tried to climb K2 against the order of the expedition leader.
Compagnoni and Lacedelli claimed they ran out of oxygen early because Bonatti had used up part of the
oxygen supply during the unplanned bivouac so he would stay strong enough for the summit attempt.
Bonatti did not have a respirator mask with him, so he could have not possibly used oxygen. A detailed
analysis of the summit pictures in 1993 demonstrated that Compagnoni and Lacedelli had worn their
oxygen masks all the way up to the summit of K2 [Marshall, 2001]. Why did they lie? Marshall thinks
that Compagnoni must have been horrified when going back to Camp 8 after the successful summit
push to discover what happened the night before. He must have worried he would be blamed,
particularly if he felt even partially responsible for the unplanned bivouac. He must have also felt
threatened when he was questioned by the expedition leader about Mahdi’s injuries.
Mahdi told his liaison officer, who in turn relayed it to the expedition leader, that Bonatti had intended
to reach the summit. Bonatti cannot possibly have told his intentions to Mahdi, because he spoke only
Italian and Mahdi spoke only Urdu. But how did Mahdi arrive at this conclusion?

1. This discussion leaves out many of the fascinating details of the problems that occurred during the first ascent of
K2. To fully appreciate the complex interdependencies between equipment, motivations, reward structures, hidden
agendas, expectations, novices and experts, and different view points, we refer the reader to the K2 chapters in
Bonatti’s book [Bonatti, 2001].
Introduction: The First Ascent of K2 653

Before the Second World War, all 8,000-m summit attempts were made with the help of experienced
high-altitude Sherpas from Nepal. Even expeditions to K2 and Nanga Parbat, located in the Karakorum,
hired Sherpas. After the war, Karakorum expeditions would get their climbing permit only if they hired
local porters. The Hunzas in the north of Pakistan were the obvious choice. Hunzas are highly capable
mountain people, but at that time they were still rather inexperienced in high-altitude expeditions.
In 1953, the Hunza Mahdi was hired as a rookie porter during the first ascent of Nanga Parbat. The
Nanga Parbat expedition started as a traditional fixed-rope expedition with a hierarchical organization,
but the final summit push was made by Hermann Buhl in a heroic 40-hour solo climb. Buhl did this
against the order of the expedition leader [Buhl, 1956].
By observing Buhl’s method, Mahdi must have concluded how successful climbing of 8,000-m peaks
had to be done. He had reason to assume that Bonatti was attempting to copy Buhl’s feat, instead of
simply delivering oxygen bottles to the lead climbers so they could reach the summit.
Mahdi’s (false) allegation, that Bonatti had plotted to reach the summit first, must have produced quite
an explosive reaction in Compagnoni because this was in violation of the expedition leader’s orders.
Compagnoni now thought he had a perfect excuse to lay the entire blame for Mahdi’s injuries on
Bonatti. To protect themselves further from being responsible for Mahdi’s injuries, Compagnoni and
Lacedelli most probably invented the story of the early loss of oxygen as well.

An expedition leader has to make several key decisions to create a successful expedition:
which mountain should be climbed, what process should be used, what type of tools, and who
should be part of the team. The answers to these questions lead to a variety of styles. The fixed-
rope style focuses on the creation of a base camp followed by several high camps. These camps
are then connected by fixed ropes that allow the climbers to move fast between these camps. In
the Alpine style, climbers do not use fixed ropes at all. The climbers carry everything they need,
setting up camp only when the night falls or when the weather stops them.
After the failures on Mount Everest and K2 in the 1920s and 1930s, it became an almost
universal opinion that Mount Everest and K2 could not be climbed without oxygen. After Mount
Everest was climbed with oxygen in 1953, oxygen was seen as fundamental to a successful
climb. In 1978, Reinhold Messner and Peter Habeler climbed Mount Everest without oxygen.
Even the question whether an expedition leader is needed at all can be answered in
different ways. From the early 1920s to the late 1960s, many expeditions were organized almost
like the military. They used a hierarchical organization with an expedition leader, several lead
climbers, a support team, many porters, and a liaison officer, whose task was to resolve difficult
communication problems between the porters and the rest of the expedition members. The 1954
expedition to K2 involved more than 300 porters. In 1980, Reinhold Messner went to Mt.
Everest with a support team of two people who accompanied him only to base camp. From there
he went solo without oxygen all the way to the summit and back in one single push.
Like an expedition leader, the project manager of a software project must deal with key
decisions about project goals, software life cycle, project organization, tools, methods, and team
members. Although some of these decisions are made by other people or even imposed by the
organization, the character of the project and the ability for the project manager to respond to
654 Chapter 16 • Methodologies: Putting It All Together

unexpected events are strongly formed by these decisions. In Chapter 14, Project Management,
we discussed project management decisions such as those related to time, schedule, cost, and
project organization. In Chapter 15, Software Life Cycle, we discussed project-independent
decisions, such as process model, dependencies among activities, process maturity, and process
improvement. To deal with the complexity of the material, we discussed these issues separately
in Chapters 14 and 15. During a project, however, the manager has to deal with these issues
together, as they depend on the project context and are strongly interdependent. In this chapter,
we discuss how to approach these decisions within a coherent framework. To facilitate this
discussion, we distinguish between project goals, environment, methods, tools, and software
engineering methodologies (Table 16-1).
The project goals include the criteria that are used to evaluate the success of a project. The
project goal may be simply the on-time delivery of the specified system. In other cases, project
goals can include broader strategic aspects, such as ensuring repeat business from the client or
decreasing business costs.

Table 16-1 Examples of goals, environments, methods, and methodologies in mountain climbing and in
software engineering.

Mountain climbing Software engineering

Goal Mount Everest The delivery of an emergency

information system within quality,
K2
budget, and schedule constraints.
Nanga Parbat

Environment Clear, cold weather Local client

Porters Novice developers
Climbing permit requirement Project duration
Project distribution
Emergency response plan

Method Free climbing Use case modeling

Belaying & repelling Design pattern reuse
Liaison officer Project-based organization

Tool Oxygen bottles CASE tool

Rope Version control tool

Methodology Alpine style Extreme Programming

Fixed rope style Royce’s methodology
Project Environment 655

The environment includes the elements present at the beginning of the project. In
software development, the environment is defined by the client and by the current state of the
development organization. The environment constrains the project manager. Examples includes
the participants’ background, the problem type, and the location of the project.
Methods are recipes that the project manager can freely select to bring the project to a
successful end in the given environment. Examples include the methods we described so far in
this book, such as use case requirements elicitation or design pattern reuse. Different methods
work in different environments; an expedition using oxygen needs more porters.
Tools are devices or programs that support specific activities. Mountaineering tools
include oxygen bottles, ropes, pitons, tents, and so on. Software engineering tools include
modeling tools, compilers, debuggers, change tracking tools, and version control tools.
Developers often rely on specific tools to automate steps stipulated by the methods they use.
A software engineering methodology is a collection of methods and tools for developing
and managing a software system to achieve a specific goal in a given environment. It specifies
when methods or tools should be used and what to do when unexpected events occur.
Section 16.2 describes typical elements of the environment that have a high impact on the
project. Section 16.3 discusses typical issues that are addressed by methodologies considering a
given environment and a set of available methods. Section 16.4 describes two general software
engineering methodologies, Extreme Programming [Beck & Andres, 2005] and Royce’s
software engineering unified methodology [Royce, 1998], to illustrate the spectrum of
methodologies available to a software project manager. Section 16.5 discusses the typical
methodology issues in the context of three case studies.

16.2 Project Environment

During a software development project, many factors can influence the selection of methods. In
this section, we consider the following aspects of the environment, which have a substantial
impact on the initiation of the project: participants’ expertise, client type, end users,
technological climate, distribution, and project duration.
Participants’ expertise. The background of the client, project manager, and developers can
constrain or open the field of methods that can be used during the project. Expertise includes the
familiarity with the application domain, the solution domain, and with various development
techniques and management practices.
Client type. The client type affects the nature and amount of feedback during requirements
elicitation and the speed of decisions when changes are requested. The client type includes two
aspects: the ability to make decisions and knowledge of the application domain. Hence, we
distinguish between four types of clients (Table 16-2):

• The local king client is a client who can answer developer questions and make
decisions without having to ask anybody else. The local king has deep knowledge of
656 Chapter 16 • Methodologies: Putting It All Together

the application domain and is usually collocated with the project. Local kings do not
report to anybody else and can effectively collaborate with the developers and the
project manager.
• The proxy client stands in for the real client. Proxy clients are sent by the real client,
either because of lack of time or because of physical distance would make
collaboration with an organization difficult. Proxy clients have sufficient knowledge of
the application domain to answer clarification questions from the developers, but do not
have sufficient power of representation to make major decisions.
• The pseudo client is a member of the development organization (e.g., the marketing
department) who acts as a client, because the system is targeted at a new market
segment, as opposed to a single individual or company. Pseudo clients can make
decisions within a short time and can collaborate well with the development
organization, but have a limited knowledge of the application domain. Often developers
act as pseudo clients.
• No client. Many projects start without a client, for example, when a visionary product
is developed before a market segment is opened. In most cases, however, the project
selects a pseudo client, so that the stakes of the developers can be balanced against the
stakes of the future user.

Table 16-2 Types of clients, decision power, and knowledge of the application domain.

Domain knowledge High Low

Decision power

High Local king client Pseudo client

Low Proxy client No client

End user access. Although clients may have deep domain knowledge, they have different
stakes than the end user. Clients are usually interested in an early delivery date, with as much
functionality as possible, and low cost. End users are interested in a system with a user interface
that they are familiar with or is easy to learn and that supports their specific task well. When the
stakes of the client and the end user are different, the project success may also depend on a
usability test conducted by end users.

Technological climate. Depending on the requirements expressed by the client, a project may
be constrained in the technological components it has to use. A project improving a legacy
system deals with well-known and mature technology. A project developing a first-of-a-kind
prototype based on a technology enabler may have to deal with preliminary versions of
components and immature technology.
Methodology Issues 657

Geographical distribution. Projects where all participants are located in a single room are
the easiest to manage, as all participants can get to know each other and much of the important
coordination can occur informally. However, there are many situations when single-room
projects are not possible or not desirable. The organization may have resulted from the merger or
acquisition of several individual companies with different skills. In other situations, the
development organization is a consortium or a temporary alliance of several subcontractors,
located in different geographical locations. In yet other situations, some part of the development
organization may need to be collocated with the client. While geographical distribution
increases the availability of skill, it also introduces new challenges, such as slower
communication, lower awareness among teams, and loss of information between sites. In the
first successful ascent of K2, the organization was highly distributed, which contributed to the
information loss: the expedition leader remained in the base camp, the lead climbers were in
Camp 9, and the support climbers bringing the last bottles of oxygen were in Camp 8.
Project duration vs. rate of change. The relationship between the project duration and the
rate of requirements and technological change affects which life cycles can be selected for the
project. A short project in which requirements do not change does not require extensive
configuration management or rationale management. Conversely, a multi-year project with
many requirement changes and staff turnover benefits from systematic configuration
management and rationale management approaches.

16.3 Methodology Issues

Methodologies provide general principles and strategies for selecting methods. Such high-level
guidance is also useful when dealing with new situations. In this section, we present selected
issues for which methodologies typically provide guidance. These include

• How much planning should be done in advance? (Section 16.3.1)

• How much of the design should result from reusing past solutions? (Section 16.3.2)
• How much of the system should be modeled before it is coded? (Section 16.3.3)
• In how much detail should the process be defined? (Section 16.3.4)
• How often should the work be controlled and monitored? (Section 16.3.5)
• When should the project goals be redefined? (Section 16.3.6)

16.3.1 How Much Planning?

Software project management plans are one of the keys in running a successful project.
However, plans have limitations. Thomas Gladwin has demonstrated this in an article in which
he compared the methods by which the Polynesians and the Europeans navigate the open sea
([Gladwin, 1964] as cited by [Suchman, 2007]). The European navigator begins with a plan of
the course. His effort throughout the voyage is directed to following the plan. If unexpected
events occur, the plan is altered and corrective activities are introduced to still achieve the
planned goal. This type of planning and controlling works well for assembly productions similar
658 Chapter 16 • Methodologies: Putting It All Together

to those described by Taylor in the early 1920s [Taylor, 1911] for the production of many
identical cars, but not for building systems that require creative problem solving and reactivity to
change.
The Polynesian navigator begins with an objective instead of a plan. He sets off toward the
objective and responds to conditions as they arise in an ad hoc fashion. He uses his skills and
experience by observing the wind, the waves, the tides and currents, the fauna, the stars, the
clouds, the sound of the water on the side of the boat, to figure out the direction of his objective
or the proximity of land. If asked, he can point to his objective at any moment, but he cannot
describe his course. This type of project management is the key element of agile methodologies
and can be used with advantage in projects exploring new technology—projects whose purpose
is break existing paradigms.
Another limitation of plans is described in [Suchman, 2007]: “In planning to run a series
of rapids in a canoe, one is very likely to sit for a while above the falls and plan one’s descent.
The plan might go something like: ‘I’ll get as far over to the left as possible, try to make it
between those large rocks, then backferry hard to the right to make it around that next bunch.’ ...
But, however detailed, the plan stops short of the actual business of getting your canoe through
the falls. When it really comes down to the details of responding to currents and handling a
canoe, you effectively abandon the plan and fall back on whatever embodied skills are available
to you.”
In general, software project management plans are especially useful to kick off a software
project and to stay on course when no major changes are expected. They are limited in helping
the project manager or developers control the project when unexpected change occurs. In this
case a project manager generally cannot anticipate an alternative activity, or its consequence,
until some course of action is already under way. “It is frequently only on acting in a present
situation that its possibilities become clear, and we often do not know ahead of time, or at least
not with any specificity, what future state we desire to bring about” [Suchman, 2007].

16.3.2 How Much Reuse?

Reusing architectures, design patterns, and off-the-shelf components can significantly reduce the
development effort required to deliver a system (Chapters 6 through 8). This assumes, however,
that finding the appropriate solution or component to reuse can be done efficiently and reliably,
and that participants understand the reused elements sufficiently well to assess their impact on
the rest of the system. Moreover, while reuse decreases development time, it does not decrease
significantly the time needed to test the system and may increase the time to repair defects. For
commercial components, reuse also introduces risks associated with the amount and length of
support provided by the vendor.
In general, the project manager faces three different trade-offs:

• Architecture reuse. In this case, the project participants adopt a preexisting system
design and adapt it to the system (Chapter 6). As no actual software is reused, assessing
Methodology Issues 659

an existing architecture is not more difficult than assessing an ad hoc architecture built
from scratch. Given an architecture that fits the needs of the system, selecting an
existing architecture is always more advantageous than recreating one from scratch.
The challenge in this approach, however, is to select an architecture that will enable
participants to meet the nonfunctional requirements of the system.
• Design pattern reuse. Similar to architecture reuse, design pattern reuse does not
involve existing software (Chapter 8). However, design patterns provide solutions to
partial design problems. Hence, developers will reuse, adapt, and combine many
different design patterns during object design. This can lead to an over-engineered
system when design patterns are used only for the sake of using design patterns. In
particular, the project manager and the chief architect should ensure that the
nonfunctional requirements and design goals are not hurt by the introduction of specific
patterns.
• Framework and component reuse. The reuse of a framework or a set of components
constrains the system design and may force developers to use specific design patterns
(Chapter 8). Moreover, components are usually black boxes provided by a vendor, and
they cannot be modified. The project manager must carefully assess the risks associated
with the reuse. In general, framework assessments are shared among several projects in
the organization, enabling projects to reduce the overhead associated with selecting a
framework.

In the end, the project environment is the determining factor for selecting a reuse strategy.
For well-defined application domains and flexible client requirements, a component-based
approach may be the most cost effective. For new systems, building from scratch may be the
only solution.

16.3.3 How Much Modeling?

Modeling constructs an abstraction of the system focusing only on the relevant aspects and
ignoring all other. Modeling enables developers to deal with complexity by reasoning with
simpler concepts. As development goes on, models are often refined to include more and more
details, and if one is not careful, the complexity of the models may become comparable to the
complexity of the system being modeled. Modeling makes implicit knowledge about the system
explicit and formalizes it so that a number of participants can share this knowledge without
misunderstanding. Models can support three different types of activities:

• Design. Models provide a representation that enables developers to reason about the
system. The models also form the basis for coding, as CASE tools are able to convert
models into source code templates.
• Communication. Models provide a common vocabulary that enables developers to
discuss specific design details, even though the corresponding system has not yet been
660 Chapter 16 • Methodologies: Putting It All Together

realized. Models can support a broad range of communication activities, from

exchanging models on paper napkins during lunch to formal inspections in the meeting
room.
• Archive. Models provide a compact representation for storing the design and its
rationale for future reference. Successful systems have extended life cycles, requiring
several generations of developers to become familiar with early decisions.

A project manager can use modeling to support one or more of the activities above. In
general, modeling presents several challenges to the manager:

• Formalizing knowledge is expensive. It takes time and effort from developers, and
requires validation and consensus so that every participant agrees on the same
meanings.
• Models introduce redundancy. If changes are made to the system, the models must be
updated as well. If several models depict the same aspects of the system, all must be
updated. If one model becomes out of sync, it loses its value.
• Models become complex. As the model complexity becomes similar to the complexity
of the system, the benefit of having a model is reduced significantly.

The project manager can choose to create activities dedicated to maintaining model
consistency and correctness or to minimize the amount of modeling by redirecting effort towards
coding and testing. In general, the trade-off depends on the project environment. On the one
hand, in a single-site project with a local king client, writing a complete requirements model is
not as critical, since the client is continuously involved in the project and available for questions.
The client can be seen as a “walking” specification of the system instead of a written
specification. On the other hand, a distributed project requires knowledge about requirements
and system design to be made as explicit as possible, as participants may have different stakes in
the project and have no opportunities to communicate this knowledge informally. Developing a
detailed use case model annotated with scenarios enables participants to converge toward a
single-system concept and to document the decisions and commitments they made (Chapter 4).
Similarly, a long-running project can challenge participants’ memories and suffer a high staff
turnaround, in which case making knowledge explicit for long-term use is an investment. In such
cases, methods such as rationale management (Chapter 12) and configuration management
(Chapter 13) enable participants to capture the justifications behind decisions and the history of
decisions, respectively.
Deciding whether or not to externalize knowledge can also depend on control factors.
Participants can make themselves indispensable to the project by refusing to share their know-
how with other participants. In the first ascent of the K2, the expedition leader actually kept
Mahdi’s account secret, because he was angry that a participant of the organization had worked
against his order (or at least that is how it seemed). As a result, for many years Bonatti actually
Methodology Issues 661

did not know why he was avoided by the fellow expedition members, who thought of him as a
liar who would sell his grandmother to get to the summit.

16.3.4 How Much Process?

Modeling the software life cycle presents similar benefits and challenges as modeling the
system. On the one hand, it enables participants to reason over a simplified representation of the
process, devise and implement improvements, and, consequently, share this knowledge across
projects with the rest of the organization. On the other hand, process knowledge is difficult to
make explicit and to keep up to date.
The trade-off faced by the project manager ranges from no modeling to a detailed and
continuously refined model, depending on how many resources can be expended in this activity.
The project manager selects a specific solution based on the project environment. A well-known
application or solution domain leads to repeatable processes [Paulk et al., 1995], increasing the
benefit of modeling the process and attempting to share it across projects. In distributed
organizations, sharing process knowledge enables a high degree of standardization and, hence, a
lower level of miscommunication. For example, having a single well-defined configuration
management and change control process (Chapter 13) enables a manager to easily track the
status of individual changes and anticipate the rate of change for the near future. Rapid
prototyping efforts and concept exploration usually exhibit a much more chaotic process that
resembles brainstorming. There is less benefit in capturing or trying to control such a process as
it is usually not repeated and of much shorter duration. In such situations, the project could
follow either an entity-based life cycle or no explicit life cycle.
When modeling a software life cycle process and reusing it in a different project, the
project manager should make sure that the correct knowledge is being generalized and reused. In
the first ascent of the K2, Mahdi had experienced one climb (Nanga Parbat), which started as a
hierarchical, fixed-rope expedition. At the end he saw one climber (Buhl) refusing to listen to the
expedition leader and going solo for the summit (in Alpine style, so to speak). He concluded that
this was the way such expeditions were conducted.

16.3.5 How Much Control and Monitoring?

A detailed software life cycle model can lead to a detailed plan that can then be checked against
actual progress. On one end of the spectrum, a plan could be so detailed as to plan and monitor
the progress of each participant on each day. At the other end of the spectrum, a plan could
include a single milestone indicating the delivery, leaving participants to plan their own work
accordingly. Although both approaches are unreasonable, the project manager must choose a
point somewhere in between that fits the project environment.
In general, both planning and assessing the actual progress requires experience.
Consequently, novice participants are poor judges of their progress. Similarly, the lack of
precedents make it difficult to plan innovative systems. To deal with novices, a project manager
can select a hierarchical reporting organization with more experienced participants in the middle
662 Chapter 16 • Methodologies: Putting It All Together

levels. The project manager can also define milestones as demonstration and scenario-based
reviews (as opposed to documents) to force participants to confront difficult issues early. To
control an innovative development, a project manager can increase the frequency of milestones
while leaving their exact content flexible to provide more opportunities for project goals to be
refined and redirected. Conversely, a project manager could leverage the knowledge of
experienced developers by enabling them to revise the project plan or the process model. For a
project with a mixture of experienced and novice participants, the project manager can select
peer-reviews, walkthroughs, and peer programming techniques to facilitate the transfer of
knowledge from experts to novices and to create a web of informal communication channels.
In the first ascent of the K2, the hierarchical organization led to thin communication
channels, which contributed to several miscommunications. For example, Mahdi talked with the
liaison officer, who relayed his statements to the expedition leader. However, the expedition
leader did not talk to Bonatti to confirm Mahdi’s statements.

16.3.6 When to Redefine Project Goals?

Sometimes a project goal is too ambitious or the original goal is simply wrong. When this
situation occurs, it is best to admit the failure and do a thorough analysis to understand what
went wrong. It requires a certain psychological capability from the manager to admit that the
goal cannot be achieved. After all, from the beginning of the project to the point of failure, the
main job of the manager was to convince everybody that the project was doable. One way to deal
with this is to declare the outcome of the project as a successful failure. Instead of focusing on
the failure, the manager focuses on an analysis of the project and determines lessons learned.
Many lessons cannot be learned in a successful project. The insights resulting from this analysis
can often be used to improve the next project, or to recognize dangerous obstacles in the future
that are suddenly now so clearly visible.
Although declaring a successful failure is a way to cancel a project and learn from one’s
mistakes, this option is not always available. Another possibility is to redefine the status at the
end of the project as the original goal. Sometimes this redefinition allows the project manager
and the developers to deal with unexpected outcomes and to reach an intermediate, less
ambitious goal that should have been defined as the original goal. In other cases, the original
goal becomes irrelevant, and the redefinition of the project goal is a way to recycle the work that
has been achieved so far.

16.4 A Spectrum of Methodologies

A software engineering methodology is a coherent set of principles for addressing the issues we
described in the previous section. In mountaineering, fixed-rope styles and Alpine styles are
methodologies. Once an expedition leader selects one of these styles, the selection of many
methods follows. For example, humans cannot sustain the lack of oxygen at high altitudes. As
the fixed-rope style requires the incremental establishment of a large number of camps,
complete with tents, sleeping bags, food supplies, and fuel, many climbers and porters will be
A Spectrum of Methodologies 663

exposed to high altitudes longer than sustainable without oxygen. Most fixed-rope style
expeditions of 8,000-m summits will then count on supplying the highest camps with oxygen
bottles. Conversely, an Alpine-style expedition can plan a quick enough attempt at the summit to
avoid prolonged exposure at critical altitudes.
In the same way, different styles of software development consist of the combinations of
different project organizations and software life cycles. Traditionally, software engineering
methodologies have evolved out of large complex, one-time projects, leading to an extensive
planning phase, detailed modeling (i.e., documentation), a hierarchical organization, and fine-
grained planning. This requires high overhead that is not always justified for shorter or routine
projects. As a reaction to these heavier methodologies, agile methodologies, such as Extreme
Programming [Beck & Andres, 2005], Feature-Driven Design [Palmer & Felsing, 2002], and
Scrum [Schwaber & Beedle, 2002], have appeared in recent years. In these more agile
methodologies, planning is accomplished incrementally, the source code is treated as the only
model of interest, and loose teams of experienced programmers are given the freedom to plan
and organize their own work. Another advantage of agile methodologies is that they can adapt to
fundamental changes in requirements [Cockburn, 2001]. A well-accepted definition of agility is
“the ability to both create and respond to change in order to profit in a turbulent business
environment” [Highsmith, 2004].
As in mountaineering, the environment constrains the set of methods that can be selected.
An Alpine-style expedition may be a way to conquer a mountain at high speed, but it is certainly
not the best way to bring paying customers to the top of Mt. Everest. Similarly, agile
methodologies can achieve spectacular results with the right set of skills, but may not be
appropriate without a critical mass of experience among participants.
In Section 16.4.1, we describe Royce’s methodology [Royce, 1998], the software
engineering equivalent of the fixed-rope climbing. Royce follows the Unified Process and
provides many project management heuristics for estimating, controlling, and monitoring
projects. In Section 16.4.2, we describe Extreme Programming (XP) [Beck & Andres, 2005], an
early agile methodology and the software engineering equivalent of Alpine climbing. XP
minimizes the generation of models and documentation by focusing on methods for making the
design of the system explicit in the source code and for disseminating knowledge among the
organization through peers. In Section 16.4.3, we describe the evolution of agile methodologies
starting with the Rugby approach from Takeuchi and Nonaka [Takeuchi & Nonaka, 1986], to
modern agile methodologies with a main focus on Scrum [Schwaber & Beedle, 2002]. Rugby
methodologies are the software engineering equivalent of expedition climbing to unknown
summits.

16.4.1 Royce’s Methodology

Royce’s methodology is based on the Unified Process life cycle described in Chapter 15. It is
iterative, focuses on risk management and change management, and departs significantly from
664 Chapter 16 • Methodologies: Putting It All Together

the conventional waterfall approaches typical of large projects. Key principles of the
methodology include

• Architecture-first approach. Focus on critical use cases, significant architecture

decisions, and life cycle plans before committing resources for full-scale development.
Address requirements, architecture, and plan together at the beginning of each iteration.
• Iterative life cycle process that confronts risks early. Focus on critical use cases, high
architectural risks, and planning uncertainties as early as possible. Each iteration
should focus on a specific risk and move the requirements, the architecture, and the
planning in a balanced manner.
• Component-based development. Minimize number of human-generated lines of code.
This includes the reuse of commercial components, the use of code-generating tools,
and the use of high-level programming languages.
• Change management environment. Introduce controlled baselines and automated
change processes to deal with changes introduced by the iterative life cycle process.
• Round-trip engineering. Use automation to more tightly couple models and source
code, thereby decreasing the cost of change.
• Objective quality control. Use automated metrics and quality indicators to assess
progress as an architecture evolves toward a finished product.
• Visual modeling languages. Use visual languages such as UML to support modeling,
communication, and documentation.
• Demonstration-based approach. Identify and follow performance issues early and
assess intermediate artifacts.

In the following, we describe how Royce’s methodology addresses the issues of planning,
modeling, reuse, process, and control.

How much planning?

In Royce’s methodology a project plan is developed iteratively, similar to the software.

Plans are detailed and refined as the stakeholders increase their knowledge of the application and
solution domains. Planning errors are like software defects: the earlier they are resolved, the less
impact they have on project success.
Royce’s methodology organizes the work breakdown structure around software life cycle
activities. The first-level elements in the work breakdown structure represent the life cycle
workflows—management, requirements, design, implementation, assessment, and deployment.
The second-level elements represent phases—inception, elaboration, construction, and
transition. Finally, the third-level elements correspond to artifacts that are produced during the
phase. Complex projects add levels to group sets of related artifacts within a phase. The
A Spectrum of Methodologies 665

organization of the work breakdown structure around the life cycle instead of the system shields
it from changes to the system.
While recognizing that estimation of new projects is difficult, Royce suggests to compute
the initial estimate with a model, such as COCOMO II [Boehm et al., 2000], and refine it with
the project manager, developers, and testers. This enables multiple points of view to be factored
into the estimate. Moreover, this enables the project participant to feel ownership of the estimate.
After each iteration, the plan is revised to reflect the performance of the project and to repair any
planning error.

How much reuse?

A key principle in Royce’s methodology is to minimize the amount of human-generated

source code, by reusing commercial components, using code generation tools, and using high-
level visual programming languages. Royce treats reuse as a return-on-investment decision.
Using any of these methods decreases development time. Mature components and tools also
reduce time to repair defects; immature components and tools can increase quality problems so
drastically that they offset any economic benefit. Hence, buy-versus-build decisions are treated
as risks that should be confronted early in the life cycle (e.g., in the first iterations of the
elaboration phase). When components are reused in more than one project, the return on
investment can be further increased.

How much modeling?

Royce organizes artifacts based on the activities of the Unified Process (Section 15.4.2):

• The management set captures the artifacts associated with planning and monitoring
activities. These artifacts use ad hoc notations to capture the “contracts” among project
participants and other stakeholders. Specific artifacts included in this set are the
problem statement, the software process management plan, the configuration
management plan, and status descriptions.
• The requirements set consists of artifacts describing the visionary scenarios, prototypes
for user interfaces, and the requirements analysis model.
• The design set consists of artifacts describing software architecture and interface
specifications.
• The implementation set consists of source code, components, and executables needed
for testing the components and the system.
• The deployment set includes all the deliverables negotiated between the project
manager and the client: in general, the executable code, the user manual, and the
administrator manual.
666 Chapter 16 • Methodologies: Putting It All Together

Test artifacts resulting from the assessment workflow are part of each of the above sets.
The management set includes the test plan and procedures. Test specifications are part of the
requirements set. Tests are simply viewed as an integral part of the system, and the same tools
and techniques are used for developing tests.
The diagram of all artifact sets generated over the phases of a software system is called the
artifact road map. Figure 16-1 shows an example of an artifact map for managing a large
software project according to Royce’s methodology.

Inception Elaboration Construction Transition

Management Set
1. Problem Statement
2. WBS
3. SPMP
4. SCMP
5. Project Agreement
6. Test plan
Requirements Set
1. RAD
Design Set
1. SDD
2. ODD
Implementation Set
1. Source code
2. Test cases
Deployment Set
1. User Manual
2. Administrator Manual

Figure 16-1 Example of an artifact road map of work products in a project using the Unified Process as
a software life cycle model. The artifact names are the ones used in this book. Informal releases are shown
as hollow triangles, baselined artifacts are shown as solid triangles, dotted lines represent the end of a phase
(adapted from [Royce, 1998]).

How much process?

Royce’s methodology includes heuristics and guidelines for tailoring the life cycle process
based on the technical and managerial complexity of the project. Royce considers the following
factors when tailoring the process:

• Scale. The number of participants in a project is the single most important factor in
determining the process. Small projects (1 to 5 participants) require much less
A Spectrum of Methodologies 667

management overhead than larger projects (>100 participants). In smaller projects,

performance is highly dependent on the technical skills of each participant and on the
tools they use. In larger projects, the management skills of team leaders becomes a
primary performance bottleneck. With small projects, management can be informal,
with focus on the technical artifacts, few milestones, and no formal processes. Larger
projects must be much more formal, with well-defined milestones and focus on change
management artifacts, such as change requests and baselines.

• Stakeholder cohesion. A cooperative set of stakeholders allows a flexible plan and

informal agreements. For example, projects with a few stakeholders who share a
common goal (e.g., the development of an off-the-shelf product by a start-up company)
often have cooperative stakeholders. This enables plans and requirements to be refined
at the beginning of each iteration. Conversely, contention among stakeholders requires
more formal agreements and well-defined processes to achieve consensus. For
example, projects accomplished by a consortium of organizations often feature
contentious sets of stakeholders with conflicting goals. A contentious set of
stakeholders results in more emphasis on use case modeling and demonstration-based
reviews. The assessment workflow becomes critical, and review and quality ensuring
activities take precedence over other workflows to ensure stakeholder acceptance.

• Process flexibility. The rigor of the contract binding the client with the development
organization determines the rigor of the process definition. A rigorous contract, typical
in one-time, custom development contracts for the government, requires precise and
detailed process definitions, whereas internal developments, such as experimental
prototypes, enjoy much more flexibility.

• Process maturity. Organizations with mature processes are easier to manage than
organizations with immature processes. Mature organizations have achieved a level of
experience and process definition that enables precise planning and a high degree of
process automation.

• Architectural risk. Ideally, the feasibility of the architecture should be demonstrated

before full-scale commitment to develop the system. However, it is not always possible
to eliminate all architectural risks before the start of the construction phase. For
example, because the architecture is new and untested, higher architectural risk during
construction results in higher levels of implementation and rework. Addressing this risk
earlier results in more design effort during elaboration and more emphasis on
demonstrations.

• Domain experience. An organization that includes participants with domain expertise

shortens the earlier phases of the life cycle by increasing the reuse of experience and
processes from previous projects. A team of participants that has developed similar
systems in the past requires fewer elaboration iterations and fewer status assessments.
668 Chapter 16 • Methodologies: Putting It All Together

When initiating a project, a project manager assesses all of these factors when deciding the
level of detailed process definition and the amount of effort to budget for each phase.

How much control?

A software development project is difficult to manage if its current status cannot be
measured objectively. This is one of the reasons why conventional software projects are difficult
to manage, as most intermediate artifacts are documents. An iterative life cycle addresses this
problem in part, as many more technical artifacts than just documents are available early. The
goals of software metrics are to provide an accurate picture to the development and management
team of the progress to date and the current quality of evolving software products, so that budget
and schedule accuracy can be improved over time.
At the beginning of each iteration, the plan, the requirements, and the architecture are
updated. Moreover, each new iteration results in change requests for baselined work products to
accommodate the resolution of new risks. Hence, change management is critical during an
iterative process. The change process needs to track changes from request through approval and
to assignment and implementation. The amount of code scraped or reworked, the size of the
change, and other such metrics are critical to control the overall quality of the system. Royce’s
methodology focuses on three management metrics and four quality metrics:

• Management metrics:
• Work: How many tasks have been completed compared to the plan?
• Costs: How many resources have been consumed compared to the budget?
• Team dynamics: How many participants leave the project prematurely, and how
many new participants are added?
• Quality metrics:
• Change traffic: How many change requests are issued over time?
• Breakage: How much source code is reworked per change?
• Rework: How much effort is needed to implement a change?
• Mean time between failures: How many defects are discovered per hour of testing?

When metric collection is automated or otherwise accomplished with minimal human

intervention, the project manager can rely on an increasingly accurate picture of the current
status of the system and its quality. For example, the number of change requests over time can be
computed when a change-tracking tool is used. Breakage and other code metrics can be
computed when changes are completed and checked into a version control tool. Mean time
between failures can be computed from data entered in a defect-tracking tool.

Summary
Table 16-3 below summarizes the methods used by Royce’s methodology for each
methodological issue.
A Spectrum of Methodologies 669

Table 16-3 Methods in Royce’s methodology categorized by methodological issues.

Issues Methods

Planning Evolutionary WBS

Initial model-based estimation of cost and schedule (e.g., COCOMO II)
Iteration planning, including all stakeholders

Modeling Critical use cases and driving requirements first

Architecture first
UML
Round-trip engineering

Reuse Buy vs. build decisions during elaboration

Focus on mature components for reducing amount of human-generated source
code

Process Scale
Stakeholder cohesion
Process flexibility
Process maturity
Architectural risk
Domain experience

Control Management indicators (work, cost, team dynamics)

Quality indicators (change traffic, breakage, rework, MTBF)

16.4.2 Extreme Programming

Extreme Programming (XP) is a methodology targeted at small teams of developers who need
to develop software quickly in a changing environment. It aims at making the design of the
system as explicit as possible in the source code, hence reducing the need for documentation and
the risk of inconsistencies among different documents. System design is approached in an
incremental way. Only features that are needed for the requirement under consideration are
implemented. The developers do not first design a general extensible architecture that could deal
with future requirements. Instead, requirements are addressed one at a time: The existing code is
first refactored to improve the system design in light of the current requirement. The refactored
code is tested; tests for the current requirements are then written. Finally, the requirement is
implemented. In short, system design is improved for extensibility only immediately before the
system needs to be extended.
XP contains a collection of project management heuristics. For example, code is not
owned by a specific developer, but rather owned by the team. Every line of code must actually be
written by a pair of programmers who match themselves dynamically for a specific task. The
driver has the control of the keyboard and mouse and the partner watches the driver over her
shoulder. After the task is done, the pair disassembles. Afterward, anybody can change the code;
670 Chapter 16 • Methodologies: Putting It All Together

there is no “owner” with sole authority to make the necessary changes. This form of ownership
is quite close to the egoless programming scheme originally proposed by Weinberg [Weinberg,
1971].
XP can be boiled down into five key principles:

• Rapid feedback. Confronting issues early results in more time for resolving issues. This
applies both to client feedback and feedback from testing.
• Simplicity. The design should focus on the current requirements. As many changes will
occur and few of them can be predicted, it is easier to deal with new requirements when
they occur. A simple design is easier to understand and to change than a complex one
with many layers of indirection for protecting against anticipated changes.
• Incremental change. It is easier to deal with changes one at the time instead of many
concurrent changes. Changes should be integrated one by one with the current baseline.
• Embracing change. Change is inevitable and frequent in XP projects. It should be
treated as a normal phenomenon and not as an exception to be avoided.
• Quality work. XP focuses on rapid projects where progress is demonstrated frequently.
Nevertheless, each incremental change should be implemented carefully and
completely. Investing time to do excellent work the first time will reduce scrap and
rework later.

Next, we describe how XP addresses the issues of planning, reuse, modeling, process, and
control.

How much planning?

In XP, planning is driven by requirements and their relative priorities. Requirements are
elicited by writing stories with the client. Stories are high-level use cases that encompass a set of
coherent features. Developers then decompose each story in terms of the development tasks
needed to realize the features of the story. Developers estimate the duration of each task in terms
of days; if a task is planned for more than a couple of weeks, it is further decomposed into
smaller tasks. After estimating the effort needed for each story, the client and the developers
meet to assign specific stories to releases, which correspond to versions of the system that will
be deployed to the end user. The user stories are organized into stacks of related functionality.
The client prioritizes the stacks so that essential requirements can be addressed early and
optional requirements later. This leads to the release plan: it specifies which story will be
implemented for which release and when it will be deployed to the end user. Releases are
scheduled frequently (e.g., every one or two months) to ensure rapid feedback from the end
users.
The effort needed to realize user stories is initially estimated in terms of ideal weeks. An
ideal week is a week in which all work time is dedicated to this single purpose. When estimating
A Spectrum of Methodologies 671

the cost of a release, this number is then adjusted by a factor to reflect such overhead activities as
meetings, holidays, and sick days. This factor also takes into account uncertainties associated
with planning. For new teams with no previous experience in XP, authors recommend starting
with a default factor of three—three actual weeks are needed to accomplish the work of a single
ideal week. This factor can be lowered as time progresses. The inverse of this factor—how many
ideal weeks can be accomplished during a fixed amount of time—is called the project velocity.
Every release is made up of a number of smaller iterations that typically last for two or
three weeks. Each iteration produces a promotion of the system, which is submitted to the client
for acceptance testing. By exposing the client to small increments of functionality, the client has
the opportunity to introduce changes many times during development. Each iteration represents
a small step toward a release, so changes are small and can easily be undone if necessary.
The beginning of an iteration starts with the so-called “planning game,” in which the client
selects the stories to be implemented. The ordering and priority of each user story scheduled for
the current release is also decided with the client. The client then specifies acceptance tests for
each story. An acceptance test is a scenario that exercises the system and is used to validate a
specific story. Acceptance tests are also used for system regression testing before each release.
At the end of an iteration, the team computes the actual project velocity by adding the
ideal weeks of the completed user stories (i.e., that passed the acceptance tests). During the next
iteration, the client can only select a set of stories whose estimated effort does not exceed the
number of ideal weeks accomplished during the previous iteration. This enables the client to
trade off functionality for cost, and developers to transparently justify the cost of each feature.
The planning for an iteration also includes time to address any acceptance tests that failed at the
end of the previous iteration. If the project velocity deviates substantially from the original plan
for more than two iterations, a new release planning meeting is called with the client to adjust
the schedule.
From a project management point of view, stories can be thought of as work packages in a
work breakdown structure. The difference with respect to traditional project management is that
the task estimations come from the developers, not from the project manager.

How much reuse?

XP does not emphasize reuse as a key method for increasing productivity. And although
XP does not rule out the use of design patterns, developers are encouraged to select the simplest
solution that addresses the user story currently being implemented. Design patterns might be
introduced as a result of refactoring, when changes are actually implemented. In this respect, XP
differs from conventional methodologies in that it does not focus on the system architecture,
which would allow such reuse to be planned at the onset. Instead, the system architecture is
refined and discovered one story at the time, as the prototype evolves toward the complete
system.
672 Chapter 16 • Methodologies: Putting It All Together

How much modeling?

XP minimizes documentation. The assumption is that fewer deliverables reduces the

amount of work and duplication of issues. Instead, knowledge is communicated directly among
participants—for example, the client is a walking specification, the design is discussed during
CRC card sessions, all developers can modify any part of the code. The system design is made
as explicit as possible in the source code by using explicit names and by decomposing methods
into many simpler ones, each with a descriptive name. Refactoring is used to improve design
incrementally. Coding standards further help developers communicate using only source code.

How much process?

XP follows a simple life cycle process consisting of four activities: planning, design,
coding, and testing. Planning occurs at the beginning of each iteration. Design, coding, and
testing occur incrementally in rapid succession. There are only a few constraints on these
activities, which are summarized below:

• Test first. Unit tests are written by the developer and before units are written. This
enables the developer to refine the API (Application Programmer Interface) to the class
and ensures the existence of unit tests early.

• Write tests for each new bug. When defects are discovered, a unit test is created to
reproduce the defect. Then the defect is repaired and all unit tests are run again.

• Refactor before extending. When new features are implemented, refactoring may be
necessary to create a design that accommodates the change. The refactoring is done
first, then the extension is implemented. This ensures that the design does not decay as
new features are added. As ownership of the code is shared, refactoring may affect code
that the developer did not initially write.

• Production code is written in pairs. Whereas individual developers may write

prototypes for experiments or proof of concepts, production code (i.e., code that is part
of a release) is written in pairs to ensure fewer defects, an improved design, and shared
knowledge about the design.

• Integrate often. Source code from developers is integrated into the main branch, one
contribution at the time. Unit tests for all integrated units are used for regression
testing.

XP encourages developers to improve on this process when necessary. There are, however,
no formal process instrumentation or process improvement activities; they are unnecessary given
the small project sizes for which XP is suited.
A Spectrum of Methodologies 673

How much control?

XP attempts to reduce the number of meetings developers need to attend so that they can
spend more time writing tests, coding, and refactoring. Status is communicated in the team by
means of a daily stand-up meeting. All project participants stand up in a circle and take turns
briefly updating the team about the tasks they completed the previous day, the tasks they are
currently working on, and the open issues they are facing. No discussions are allowed, to keep
the meeting short. If any discussion is necessary, only the participants involved meet informally
later that day.
The need for inspections and peer review is eliminated by using pair programming. Since
all production code (including unit tests) are written in pairs, the review occurs during the code
writing. As code is not owned by any specific pair, many programmers become familiar with any
specific piece of code. Moreover, pairs are rotated often to enable a better distribution of
knowledge throughout the project.
XP replaces the command and control structure of large projects, such as those found in
Royce’s methodology, by a self-organizing system [Highsmith & Orr, 2000]. A leader (as
opposed to a manager) communicates a vision of system requirements and architecture,
cultivates an environment where innovative ideas can be promoted and elaborated, and
encourages risk taking. The leader must encourage an environment where participants can
collaborate, share information, and develop mutual trust. The leader must still make the hard
decisions to ensure that participants pull in the same direction, and get the product shipped. The
leader must be able to decide when to build consensus and when to dictate. The leader is like the
Polynesian navigator guiding his boat toward an objective, as opposed to managing his project
according to a rigid step-by-step plan.

Summary

Table 16-4 summarizes the methods used by XP for each issue.

16.4.3 Rugby Methodologies

In 1986, Takeuchi and Nonaka published a methodology to address the specific problems that
occur in new product development [Takeuchi & Nonaka, 1986]. They named it the Rugby
approach, because the rugby game requires all team members to go the distance as a unit,
passing the ball back and forth while moving simultaneously. This approach was in contrast to
the methodologies that existed at that time, which Takeuchi and Nonaka compared with a relay
race, where one runner moves at a time, passing the baton to the next runner. For many
situations, these relay-based methodologies were seen as too slow, too heavy, and not able to
react well to change.
In rugby, the normal flow of the game is stopped after an infringement occurs, for example
after the ball is passed forward (which is not allowed in Rugby) or after the ball has been
trapped. The game is then restarted with a formation called the scrum, which is quite a physical
674 Chapter 16 • Methodologies: Putting It All Together

Table 16-4 XP methods by methodological issues.

Issue Methods

Planning Write user stories with the client.

Plan frequent small releases (every 1 to 2 months).
Create schedule with release planning.
Kick off an iteration with iteration planning.

Modeling Select the simplest design that addresses the current story.
Use a system metaphor to model difficult concepts.
Use CRC cards for the initial object decomposition.
Write code that adheres to standards.
Refactor whenever possible.

Process Code the unit test first.

Code unit tests for all production code.
Do not release before all unit tests pass.
Write a new test for each uncovered bug.
Do not add functionality early.
Collocate the project with the client.
Program all production code in pairs.
Integrate code one pair at the time.

Control Code is owned collectively.

Adjust schedule.
Rotate pairs.
Start the day with a stand-up status meeting.
Run acceptance tests often and publish the results.

event where injuries can occur. In software development, agile methodologists argue that
developers should also stop and review the situation whenever change has occurred, such as
changes in the requirements. To reduce the risk of overlooking unexpected changes, agile
methodologists propose to meet as regularly as possible to identify these changes as early as
possible. So while heavyweight methodologists tried to avoid unexpected change, agile
methodologists regard unexpected change as the normal situation to be accepted at regular
points during project-runtime.
XP described in the previous section was one of the first “light-weight” methodologies to
address the slowness and bureaucracy of these methodologies [Beck & Andres, 2005]. Based on
the Rugby approach, Ken Schwaber published the Scrum approach in 1995 [Schwaber, 1995].
Other light-weight methodologies with similar goals emerged during the same time such as
Adaptive Software Development (ASD) [Highsmith & Orr, 2000], Crystal Clear [Cockburn,
2004]. In 2005, Martin Fowler published an overview of these methodologies [Fowler, 2005].
In 2000 a group of XP experts and other methodologists discussed the relationship of XP
with other “light-weight” methodologies. During that meeting, the name agile methodology was
A Spectrum of Methodologies 675

chosen instead of light-weight methodology, because the term light-weight was considered to
evoke the wrong idea of being “light-headed”. The key points of an agile methodology were
then published with four so-called value statements in the Agile Alliance Manifesto
[AgileManifesto, 2001]:

• Individuals and interactions over processes and tools. The most important factor in a
software project are the people and how they work together. Software development is
better done by a social network of self-organizing people than an organizational
hierarchy with strict lines of authority, processes with fixed roles and sophisticated
tools.
• Working software over comprehensive documentation. The goal of software
development is to create software, not documentation.
• Customer collaboration over contract negotiation. Having a contract with the customer
is important, but it is not a substitute for communication. Successful developers work
closely with their customers to discover what they need, and they educate their
customers along the way.
• Responding to change over following a plan. A good software project should start with
a plan, but that does not mean it must be followed literally, it must be changeable if the
situation changes and change is a reality in software development. As work progresses,
the understanding of the application and solution domain, the business environment
and the underlying technology changes and developers should be able to respond to
these changes.

In this section, we describe elements of Rugby methodologies not covered by XP,

addressing the five methodological questions in this chapter.

How much planning?

Agile methodologies have had a poor reputation with respect to planning. Critics of agile
methodologies often say that “agile teams don't plan” or “agile teams won't commit to dates and
features.” In fact, agile methodologies advocate a lot of planning, but not all of it at the
beginning of a project. Agile planning is iterative and refines estimates as requirements stabilize
and more experience is gained by the team. In a deterministic model of development, the SPMP
is developed up front, in a nondeterministic model of development, the SPMP is developed
incrementally and iteratively, and adapts to the current situation.
Iterative planning implies that the agile planner is always prepared to acknowledge that
the plan itself is wrong instead of trying to get the project back to the planned course. This can
happen as a response to change, for example, when requirements change or when promising new
technology appears in the middle of the project. At the start of a project the plan may state that a
product should fulfill a specific set of requirements, but in the middle of the project the client
decides that a different set of requirements would increase the value of the product significantly.
676 Chapter 16 • Methodologies: Putting It All Together

This uncertainty is also reflected in the estimate models used for incremental planning.
Cohn, for example, advocates three distinct estimates: The order of magnitude estimate, done at
the beginning of the project, which can be off by as much as an order of magnitude from the
eventual values. The next level estimate is the budgetary estimate with a precision of +25% to
-10%. Late in the project follows the definite estimate, with a precision of +10% to -5%
[Cohn, 2006].
Closely related to agile planning is agile estimation, such as Planning Poker
[Grenning, 2002]. Planning Poker involves a moderator and the team members. It starts with a
list of features of the system to be developed. These can be the functional or nonfunctional
requirements, often presented in terms of user stories or scenarios. Each team member gets a
deck of cards containing a set of different values, for example 1, 2, 3, 5, 8, 13, 20, 40, 100. For
each feature on the list, the team members discuss their difficulty and privately choose a value
card that they think represents the correct estimate. Then the moderator asks that all the cards are
simultaneously revealed. In general, there will not be an immediate consensus about the
estimates and the team members with the highest and lowest estimates are asked to justify their
choices. This usually leads to another round of discussion and another estimation. This process
is repeated until a consensus is reached. There are different ways to reach a consensus. For
example, the developer who is responsible for the requirement may have more weight in the
consensus vote, the moderator may also get more power to negotiate the consensus.
As agile estimation is iterative, planners improve their estimates as they gain a better
understanding of the development team and the application domain.

How much reuse?

Rugby methodologies are used with advantage in new product development, in our
terminology greenfield engineering, where the focus is not so much on the reuse of models or
existing processes, but more on the reuse of knowledge.
Knowledge acquisition is encouraged on the individual level as well as on the team level.
Team level learning takes place on the technical level in terms of tutorials and training programs
as well as on the social level. Furthermore, the team members are encouraged to accumulate
experience in areas other than their own. This allows team members to speak with people from
other domains, an important aspect for the elicitation of requirements and the discovery of
innovative designs.
Subsequently, knowledge is transferred between projects by reassigning key experts to
different teams. While organizations learn by converting individual project successes to standard
practice, institutionalization often creates a problem when the project environment changes
significantly. In such a situation, standard practices established from previous projects are rarely
applicable. In contrast, Takeuchi and Nonaka claim that learning from mistakes is more helpful
than learning from success. Project managers as well as developers can usually learn more from
mistakes than from successes [Petroski, 1992]. Allowing mistakes during a project is an
A Spectrum of Methodologies 677

important aspect of the Scrum methodology: the key is to find the mistakes early and having the
time to correct them. This is made possible by the daily Scrum meetings.

How much modeling?

Throughout the book we have introduced the concept of modeling as a key to solve
software engineering problems. UML has become one of the dominating languages to model
applications and software systems. We use UML to specify requirements with functional models
for the customer (use case models), we realize the dynamic behavior (workflows) with state
chart and activity diagrams, and we use deployment diagrams to describe a software installation.
We have emphasized the need for keeping the models consistent which each other
(Section 4.3.3). Ambler advocates to update models only “when it hurts” [Ambler, 2002], that is,
developers should not try to make models consistent with each other after a change in one of the
models. Agile Modeling also assumes that there are many ways to model the same concept.
Ambler also proposes to create several models in parallel, drawing models with the simplest
notations and using the simplest tools. For example, in Scrum tasks are written on slips of paper
and organized on a white board.
One particularly simple modeling technique is paper prototyping, where end users are
asked to perform realistic tasks by interacting with a paper version of the interface [Norman,
2002]. The user interface is executed by a person playing the computer, who doesn’t explain
how the user interface is going to be implemented. Paper prototyping can be used for usability
testing of any type of human-computer interaction, but is mostly used for testing Web-browsers,
and hand-held devices. Its purpose is to get quick feedback from users while the user interface
design is still in the drawing stage. User interface paper prototypes can be hand-drawn drawings
or screen shots, often changed with the help of drawing or photo-editing tools.
To encourage natural behavior, the developers often prefer to do these tests without the
end user knowing that the system is not yet implemented. This can be done with the Wizard of
Oz technique, where a human (the wizard, usually sitting in another room) simulates the
behavior of the system by intercepting all communications between the end user and the system.
That is, the end user does not know that a human generates the responses. The Wizard of Oz
technique can provide valuable information on which to base future designs, by gathering
information about the nature of the interaction, testing the interaction of a device before building
a functional model and identifying problems users will have with the devices and interactions.
For example, the user types a search query, and the wizard provides the result as if it
comes from a real search engine. This allows testing the user interface, in particular query
formulation and filtering of results, before implementing it. The Wizard of Oz technique can
also be used with advantage when designing natural language interfaces: The design and syntax
of the command language of the eventual system is driven by the actual language and
formulations used by the users during the tests [Kelly, 1984].
678 Chapter 16 • Methodologies: Putting It All Together

How much process?

A deterministic process model, also called “defined process control model” by Tunde
[Tunde & Ray, 1994] assumes that, given a well-defined set of inputs, the same outputs can be
generated every time. Deterministic models have their roots in the early 1900s, when Frederick
Taylor formulated his ideas of scientific management [Taylor, 1911]. Taylor said that any
process based upon tradition, heuristics and rules of thumb should be replaced by precise
procedures. With the advancement of statistical methods, his approach was later called quality
control and quality management. Total quality management (TQM) in the 1980s was another
attempt to make production deterministic by reducing and, if possible, eliminating variations in
the process so that greater consistency in the desired product could be obtained [Deming, 1982].
The waterfall software life cycle model can be seen as an attempt to treat software
development as a deterministic process. However, trying to model software development as a
deterministic process has led to many projects with incomplete products, loss of control, and
clients receiving the wrong product in spite of frozen requirements. Software development is
better modeled with a non-deterministic model, also called “empirical process control model”
[Tunde & Ray, 1994]. The use of such a model in software development is justified by the fact
that software processes exhibit too much complexity to be fully understood where changes with
unpredictable impact can occur at any time. Project managers using a non-deterministic model
accept these unexpected events and deals with them through frequent inspection. For example,
in Scrum, the next “Sprint” is planned based on the experience of the last iteration. While
planning this Sprint, a redirection of the project goals and requirements by the client is explicitly
allowed. That is, Scrum empirically responds to any changes, that is, it is based on the empirical
process control model.

How much control?

Control in agile methodologies is based on the concept called subtle control by Takeuchi
and Nonaka. On the one hand, the team commits to challenging goals. On the other hand, the
team is self-organizing. This tension, between challenge and freedom creates a built-in
instability in which innovative solutions can by rapidly developed. Takeuchi and Nonaka call
teams self-organizing if they are:

• autonomous: each team can make its own decisions, independent from its place in the
organizational hierarchy.
• self-transcendent: the teams establish their own goals and pursue their own ideas
independent from the current patterns and knowledge used in the application as well as
solution domains. Teams are encouraged to think out of the box. Contradictory goals
are allowed, even encouraged to overcome the current way of thinking and to prepare
for the discovery of new ideas.
• multi-disciplinary: each of the team members is selected with respect to different skills
needed for the project.
A Spectrum of Methodologies 679

Scrum teams are self organizing. Although the teams are encouraged to work on their
own, they are not uncontrolled. Management establishes enough checkpoints to prevent
instability turning into chaos. But the control is not based on externally imposed rigid schemes
and deadlines but on self-control. That is, the project monitoring is done by the teams
themselves, for example through peer pressure. This can be done by controlling the group
dynamics of the team, by selecting the team members based on their experience and their energy,
or by adding more experienced team members to a team of beginners. Important is the ability of
the project manager to tolerate and anticipate errors.
To be able react to upcoming problems, issues must be identified as early as possible.
Scrum advocates the daily Scrum meeting, in which the team members regularly share their
work progress and problems they have encountered. This allows the team to identify obstacles as
early as they appear, and react to them.

Summary

Table 16-5 summarizes the methods used by Rugby for each issue.
Table 16-5 Rugby methods by methodological issues.

Issue Methods

Planning Plan project as a prioritized list of high-level requirement.

Define consensus goals of the current iteration.
Agree on a consensus effort estimate; a precise estimate is only done for the
current iteration.
Revise estimates daily, based on newly identified work and progress.

Modeling Sketches
Paper prototype
Wizard of Oz

Reuse Reuse knowledge, not models.

Reassign key experts to other projects to disseminate knowledge within the
organization.

Process Overlap development activities.

Integrate completed items into a potentially deliverable product increment.
Return incomplete items to the global todo list.

Control Conduct brief daily status meetings.

Assess trends with burn down charts.
Review iteration results with product owner and client.
Readjust team for next iteration, if necessary.
680 Chapter 16 • Methodologies: Putting It All Together

16.5 Case Studies

Novice project managers tend to be strict about the decisions made at the beginning of a project,
and are usually not willing to adjust to the challenges of new situations that occur in any real
project, whether technical or managerial. This unwillingness often has its roots in the
inexperience of the manager with the methods and techniques applied in the project. A project
manager needs to view himself as a continual apprentice, exploring the possibilities of applying
tools and methods in a project as an n-dimensional parameter space. In this space each project
occupies a point or a subspace spanned by the particular choice of values for the project
parameters.
To get experience, a novice project manager should start with simple project parameters;
for example, a team of five people, focusing on a single project parameter, either an unknown
requirement, a new technology, a new method, or a new methodology. It is not recommended to
change more than one of these parameters. It is not advisable to start with a large project with
unknown requirements, new experimental technologies and 50 team members. For example, we
do not recommend experimenting with a new methodology when addressing a new requirement
from the client. With more and more project experience, managers and developers can advance
to larger and larger projects with more degrees of freedom.
In this section, we provide three case studies of projects from the point of view of a novice
project manager. All three projects involved a set of senior software engineering students and a
real client:

• ATRACT (Automated Test and RAtionale Capture Tool) is a six-month XP project

focusing on the development of a test infrastructure for a middleware environment
(Section 16.5.1). ATRACT featured one requirement iteration followed by three
development iterations.
• FRIEND (First Responder Interactive Emergency Navigational Database) is a five-
iteration project with a collocated king client focusing on an emergency response
system (Section 16.5.2). We describe the first iteration as a single project, then how the
combination of five iterations formed another project.
• JAMES (Java Architecture for Mobile Extended Services) is a distributed, two-iteration
project focusing on the use of smart card applications for the car driver
(Section 16.5.3).

Note that these projects are all student projects. Students are often concurrently pursuing
other instructional courses during the period of the software development. This is similar to a
matrix development organization in which each individual can be working on a number of
projects. For each project, we examine the project goals, the project environment, the methods
selected to address planning, reuse, modeling, process, and control, and the lessons learned.
Case Studies 681

16.5.1 XP Project: ATRACT

Project goal

The goal of ATRACT was to provide a framework for writing and executing tests for a
middleware environment specialized for small wireless devices, such as cell phones and MP3
players. The framework had to provide services for moving files between devices. Devices,
based on the type of file received, could either process, store, or ignore the files. As many new
types of devices and files had to be supported, the vendor of the middleware environment had a
need for a testing environment for specifying and automating tests. As the development and
execution of tests could involve several developers, the tool also had to include features for
discussing tests using an issue-based model.
The goal for the first release was to achieve a robust testing environment with at least the
minimum amount of functionality and documentation needed for conducting actual tests. An
additional goal for all participants was to learn about XP and evaluate its effectiveness for small
projects conducted in pairs.

Project environment

Local king client. The client of this project was the middleware vendor. He was familiar with
both the technology and the platform.
Novice participants. In addition to the client, two developers and a supervisor took part in the
project. All participants had taken part in software development projects; however, all were new
to XP. The developers relied on the advice of an external participant for the application and
customization of XP.
Mature technology. Because the platform for the system was Java, developers were able to
select relatively mature components for developing the test infrastructure.
End user access. The client of the project was also an end user.
Project located at the client site. The developers were collocated at the client site and had
unrestricted access to the client. The client was able to make immediate decisions and did not
have to refer questions to other members of the company.
Project duration. As the developers were familiar with use case modeling and the
requirements tool that was used, the project was divided into two phases: In a first two-month
phase that focused only on requirements, a set of vertical prototypes and a use case model of the
visionary system were developed. The developers validated the mock-ups with the client and
used the use case model for tracking requirements issues. The second phase, which lasted for
four months, was dedicated to realizing the first release of the system according to an XP
process. At the beginning of the second phase, the use case model was converted into user
stories that were used by the developers and the client for requirements prioritization and
682 Chapter 16 • Methodologies: Putting It All Together

estimation. This two-phase approach enabled us to minimize the risks associated with using a
new methodology (XP) by restricting its use to the construction phase of the project.

How much planning?

The milestones of the project were fixed from the start, due to constraints on the developer
and management side. Previous experience in such projects (six months, few developers, new
client), suggested a requirements phase of about 6 to 8 weeks. The end of the requirements
phase also coincided with the beginning of the year, which made it easier to schedule in the
client’s calendar. The release plan and the decomposition of the first release into three iterations
was decided only after the requirements phase was completed. The developers chose a high-
velocity schedule from the start, confident in their ability to produce (an ideal week was
estimated to take only about 1.5 actual weeks). To the surprise of most participants, the velocity
did not change during the project.

How much reuse?

Initially, the developers did not plan to reuse any software packages because of the short
time constraints associated with the development phase. Much of the project time was already
spent understanding the application domain, in particular the existing middleware and
infrastructure. While implementing the user stories, however, the developers found themselves
writing a custom interpreter for creating tests scripts, including setting variables, specifying
loops, and manipulating files. As the custom language for the test script became more complex,
the developers decided to discard their custom interpreter and reused, instead, an open-source
implementation based on Javascript. This actually put the project back on schedule and resulted
in additional functionality for the client and a lower learning curve for end users.

How much modeling?

The requirements were initially represented as use cases for the first phase. After the start
of the second phase, only user stories and tasks were written down on index cards, which were
also used to track actual effort. The use case model was not kept up to date after the switch to
XP. Otherwise, no visual models were constructed. All system and object design knowledge was
embedded into the code as source code comments and as method and class names. The lack of a
model was not an issue given that only one pair of developers worked on the project and for a
short period of time.

How much process?

During iteration 2, the XP process, including the activities iteration planning, refactoring,
writing tests, realizing user stories, and test, was followed closely by the developers. The client,
however, did not write user stories or acceptance tests directly, due to lack of time; instead, the
developers would write the stories and the tests based on meetings with the client. As there were
Case Studies 683

no schedule deviations or difficult issues, the manager turned into an observer and did not
participate very much past the requirements phase.

How much control?

The developers met the manager shortly before the end of each iteration, before meeting
with the client, to demonstrate the current status of the code and to assess any open issues. As
the project followed the initial schedule closely and there were few open issues at the end of an
iteration, the meetings were used mostly to bring the manager up to date on the application
domain. The meeting was then followed a few days later by a meeting with the client for the
iteration acceptance test.

Outcome

The project ended on time, delivering the required user documentation, installation scripts,
source, and executable code. A brief post-development phase led to the update of the use case
model to reflect the changes that had been made to the requirements. The client was satisfied
with the result, and most importantly, his expectations were in line with the outcome because he
had closely followed the complete development process.

Lessons learned

Training the client. Even though the project was collocated with the client organization, the
client did not have enough resources to dedicate to writing user stories and acceptance tests. The
organization was too small to spare that much time for an infrastructure project. Hence, the
client did not learn as much about the process as originally planned. In this situation, the first
two months of requirements paid off as developers were able to elicit and validate a stable set of
requirements from a small number of meetings with the client, using scenarios, mock-ups, and
use cases. For a longer running project, it is critical that the client understand the ground rules of
XP when prioritizing user stories, estimating effort, and readjusting the schedule as a result of
velocity changes. Put in Royce’s terms, an XP project works for cohesive sets of stakeholders.

Training the developers about the process. XP requires a core of experienced developers.
Experience enables developers to produce accurate estimates, to localize changes, and to make
judgement calls about when to communicate issues with other participants. ATRACT was a small
enough project where both developers knew all that needed to be known about the current status
of the project. In a larger project, the rotation of pairs can be used to bring new developers, in
particular beginners, up to date and introduce redundancy into the system. We anticipate,
however, that running a larger project with only novice developers following XP would entail a
severe learning curve before the project reached a steady state of changes.
684 Chapter 16 • Methodologies: Putting It All Together

16.5.2 Local King Client: FRIEND

Project goal
The FRIEND system is an emergency management system for coordinating field units
working on an accident. When the FRIEND project started in 1992, accident management was
accomplished mostly with paper-based processes. The appearance of technology enablers such
as digital wireless technology and PDAs (personal digital assistants) led to the goal of replacing
the paper process with an electronic process. FRIEND was designed for various types of
accidents, from minor traffic accidents to such major incidents as fires and storms. The project
was structured in five iterations demonstrating increasingly more complex prototypes. Many
examples of Chapter 4 are taken from this project.
Each development iteration of the project was executed as a one-semester software
engineering course with senior students as developers. The goal of the project was to develop a
demonstration prototype of the FRIEND system. A second goal was to expose the students to
state-of-the-art software engineering methods and tools. Although FRIEND did not follow closely
Royce’s methodology, it started with many of its elements, including a project-based
organization, well-defined change processes, and similar artifact sets.

Project environment
Local king client. The client for FRIEND was the police chief of a local community. He
initially did not have any background in software engineering or wireless technology. He had
detailed knowledge about the application domain, and could make immediate decisions about
the scope and the direction of the project.
Novice participants. The project included an average of 40 participants, mostly novice
developers, with strong technical skills but little experience in projects of this scale.
Management had conducted several projects of this scale. The application domain was new to all
the participants.
End user accessible. The client was also an end user. Moreover, a selected set of other end
users was available for usability testing.
State-of-the-art technology. FRIEND focused on wireless technology and PDAs as a platform
for the prototype. Although the technology used was relatively stable, it was new and required
additional training for the students before working code could be produced.
Single-site project. The project occurred in one location. All students had access to a single
lab. The client was available on short notice.
Project duration. The project initially included two months of preparation, followed by a
four-month development iteration. As the results of the first iteration were successful, the project
led to four successor projects that further refined the concept and architecture of the system, and
a spin-off company that realized a product. The overall project eventually lasted three years.
Case Studies 685

How much planning?

As FRIEND was a concept exploration project, the functionality and the platform of the
prototypes were not specified in detail. The milestones, however, were fixed from the start. As
the participants had little experience in large-scale development, the schedule of the project was
based on the waterfall model. The requirements, system design, object design, and coding were
each planned for approximately four weeks, with a formal review at the end of each
development activity.

How much reuse?

Both the application domain (accident management) and the technology enablers (Apple
Newtons, wireless Motorola modems) used for the project were new to the students. Little reuse
was possible for the domain-specific parts of the system. Off-the-shelf packages were used for
the graphical user interface and the networking subsystems. In general, the short duration of the
project limited the complexity and the number of off-the-shelf packages that could be used.

How much modeling?

The project produced three artifact sets: a client set, a management set and a system set.
The system set corresponds to the requirements, design, implementation, and deployment set in
Royce’s methodology. The client set included the documents under the client’s responsibility
and written in collaboration with project management. This included the Problem Statement and
the Initial Schedule (Table 16-6).
Table 16-6 Client documents. The problem statement was handed out to the students at the beginning of
the project.

Document Purpose Produced by

Problem Statement Describes the needs, visionary scenarios, target Concept Exploration
environment, requirements and constraints

Initial Schedule Describes major milestones Project Initiation

Task models representing management information were constructed during project

initiation by management and revised throughout the project. They were documented in the
Software Project Management Plan, the Software Configuration Management Plan, and the Top-
Level Design document that was used to set up the initial teams (Table 16-7).
System models represent the system at different levels of abstraction and from different
perspectives. The use case model describes the system from the user’s point of view. The
analysis model describes entities modeling the accident management domain . The system and
object design models represent the software architecture and the solution objects based on the
686 Chapter 16 • Methodologies: Putting It All Together

Table 16-7 Management documents.

Document Purpose Produced by

Top-Level Design Describes the preliminary software Top-Level Design

architecture, in particular the subsystem
decomposition.

Software Project The controlling document to manage the Project Initiation

Management Plan project
Project Monitor and Control

Software The controlling document describing the Software Configuration

Configuration software configuration management activities Management
Management Plan

chosen technology of PDA and wireless communication. The analysis models were documented
in the Requirements Analysis Document (Table 16-8).
The system design was documented in the System Design Document. The object design
model was documented in the Object Design Document. Models in the analysis and object
design phase were written in OMT [Rumbaugh et al., 1991] and entered into a small CASE tool
called OMTool. The OMT models were used both for generating the initial code fragments as
well as figures in the design documents.
The purpose of models in FRIEND was primarily to support design and communication. As
the goal of FRIEND was to demonstrate a prototype, we expected the system to evolve rapidly,
making it costly and difficult to maintain consistency between models and the system. Hence,
archiving was not a primary goal. Instead, we expected knowledge to be transmitted across
iterations by way of the prototype and the implicit knowledge carried by the students who
continued with the project.

How much process?

The life cycle model included three phases. During the pre-development phase,
preliminary requirements and the initial software architecture were developed. Infrastructure
choices were also made, in particular a single room was chosen and dedicated solely for the
students working on the project. Only the client, project manager, and coaches were involved in
this phase. At the beginning of the development phase, all students were assigned to a team to
work toward the construction of the system. The goal of the development phase was to validate
the architecture of the system and expose the participants to all aspects of an iterative software
life cycle. The requirements, design, implementation, and test cases were developed
incrementally. Core functionality was developed during the development phase. Some optional
functionality was added during the post-development phase. The rationale for this approach was
to deliver a system with required functionality on time, as opposed to delivering a complete
Case Studies 687

Table 16-8 System documents for FRIEND.

Document Purpose Produced by

Requirements Describes the functional and global Requirements

Analysis Document requirements of the system as well as four
(RAD) models: use case, object, functional, and
dynamic models.

User Manual Describes the use of the system (in the form of Requirements
a tutorial).

System Design Describes design goals, trade-offs made System Design

Document (SDD) between design goals, high-level decomposition
of the system, concurrency identification,
hardware/software platform, data management,
global resource handling, software control, and
boundary conditions.

Object Design Describes the system in terms of refined object Object Design
Document (ODD) models, in particular the chosen data structures
and algorithms, as well as full signatures for all
public methods. This document results in the
detailed specification of each class used by the
programmers during the implementation phase.

Test Manual Describes testing strategy—the unit and system Testing

tests performed on the system along with
expected and actual results.

Administrator Describes the administrative procedures to Install Software

Manual install, operate, and bring down the system.
Also contains a list of error codes, and failure
and termination conditions.

system late. Table 16-9 describes the three phases in the terminology of the IEEE 1074 life cycle
model.
Note that the life cycle did not include operation and support activities because the goal of
the project was to develop only a demonstration prototype.

How much control?

Because of the large number of participants (42 students, 5 coaches) and their lack of
experience in large-scale development, we adopted a hierarchical project organization and strict
control. During pre-development, a preliminary top-level design of the system was created to
serve as a basis for team decomposition. The project team was organized in five subsystem
688 Chapter 16 • Methodologies: Putting It All Together

Table 16-9 Software life cycle activities for FRIEND.

Phase Purpose Activities IEEE 1074 activities

Pre- Initiate project Project Initiation 3.1 Project Initiation

development Concept Exploration 4.1 Concept Exploration
Top-Level Design 4.2 System Allocation

Development Validate Project Management 3.2 Project Monitor & Control

architecture Requirements Elicitation 5.1 Requirements
Analysis
Train
Analysis Review
participants
System Design 5.2 Design
Demonstrate System Design Review
core Object Design 5.2.7 Perform Detailed Design
requirements Object Design Review
Implementation 5.3 Implementation
Demonstrate Unit Testing 7.1 Verification & Validation
feasibility System Integration Testing
System Testing (alpha test)
Configuration Management 7.2 Software Configuration
Management
Tutorials 7.4 Training

Post- Demonstrate Project Management 3.2 Project Monitor & Control

development optional Refinement 6.3 Maintenance
requirements Install Software 6.1.5 Install Software
Client Acceptance Test 6.1.6 Accept Software
Deliver
Field Testing (beta test) 7.1 Verification & Validation
prototype
Configuration Management 7.2 Software Configuration
Client Management
acceptance

teams (Campus, Communication, Database, EMOC, and UI), each responsible for one
subsystem (Figure 16-2). A cross-functional architecture team was composed of liaisons from
each subsystem team. A tool team was responsible for providing the infrastructure to the other
teams, including build scripts, configuration management, and test harness. For the initial
assignment of students to teams, we used a skill matrix considering programming knowledge,
knowledge of specific tools, wishes, and interests. The identification of the skills and interests
was based on information provided by the students.
During the first week of the project, we trained the students to use a well-defined process
for reporting status and conducting reviews. Each team met weekly to discuss status. The
weekly team meeting was facilitated by a coach, who posted a meeting agenda prior to the
meeting. A student would record the meeting content in meeting minutes and action items and
post them shortly after the meeting. The coaches of the teams also met weekly with the project
Case Studies 689

Management
(6)

Campus Communi- Database(7) EMOC (7) UI (7)

(6) cation (7)

Architecture Documen- Tools

(8) tation (2) (6)
Legend
Liaison from management
Liaison to cross-functional team

Figure 16-2 Team organization of FRIEND during iteration 1 (CMU Fall course 15-413, 1992). White
rectangles indicate subsystem teams; gray rectangles, cross-functional teams. The numbers in parentheses
indicate the number of team members.

manager. Progress was assessed in monthly project reviews. During the first month, the project
manager and the coaches ensured that the status reporting and meeting process was followed
rigorously. This resulted in the project status being visible for all students, thus allowing them to
recognize the value of such information. Moreover, during the first two months, roles within
teams were rotated, enabling each student to facilitate a status meeting, act as a liaison to the
architecture team, and specialize in a tool role. The motivation for role rotation was
pedagogical—each student had the opportunity to learn most roles; it also acted as a selection
mechanism—students who performed well in a specific role often ended up serving in that role
for the rest of the project.
After the system design review (i.e., the second project review), both process enforcement
and role rotation were relaxed. Students were told to keep the tools and methods that worked,
and discard those that got in the way. As a result, the status reporting process remained in place,
but increasingly more decisions were made locally as coding progressed. Students who
displayed communication skills usually ended up in the liaison roles. Students who excelled at
technical tasks ended up carrying the technical tasks of the team. Conflicts and interface
problems discovered during builds were resolved face to face in the lab. Only major integration
issues resulted in ad hoc meetings.
In essence, the organization of the project evolved from hierarchical to a series of XP
subprojects, one for each subsystem. Each subproject treated the other teams using the
subsystem as collocated clients. This organization was only possible once a solid architectural
concept was in place, defining the responsibilities of each team.

Outcome

The project produced a conceptual prototype that demonstrated how Geographical

Information Systems could be used to organize and display incident information. The success of
690 Chapter 16 • Methodologies: Putting It All Together

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

Jul. Sep. Nov. Jan. Mar. May Jul. Sep. Nov. Jan. Mar. May Jul.
1993 1994

Legend:

Predevelopment Development

Figure 16-3 Iterations in the FRIEND project.

the first project led to four more iterations exploring a variety of technologies and functionality
(Figure 16-3):

• Iteration 2 focused on consolidating the feedback from the client into the prototype. It
included a subset of the students who had worked on the first prototype, and followed
an iterative software life cycle process focusing on the prototype. Each review focused
on new functionality to be added to the working prototype.
• Iteration 3 started from scratch with a new set of students and a more ambitious
problem statement. The scope of the system was extended to include Emergency
Operations Plan functionality for disasters that would need to be coordinated at the
state level. This iteration reverted to a waterfall process, as there were many novice
developers.
• Iteration 4 consolidated the feedback from the client and investigated technological
issues, such as the use of WaveLAN networks and cellular phone modems. A prototype
of the system was demonstrated using Newton PDAs. Iteration 4 included a subset of
students who took part in iteration 3 and followed an iterative software life cycle.
• Iteration 5 investigated the use of NeXTStep’s Distributed Objects as middleware
technology for managing all communication among nodes.

A company was spun off after iteration 5 to turn FRIEND into a product.

Lessons learned

Training the client. At the beginning of the project the client did not have any computer
background. However, the client invested quite a bit of time in the project and learned how to
communicate with the developers directly. By the fourth prototype, the client could understand
and criticize high-level class diagrams. In general, developers should not expect this to happen,
as clients usually do not plan time to learn about the project infrastructure. However, for a long-
term project with a collocated client, it is worthwhile to identify ways to train them.
Case Studies 691

Training the developers about the application domain. The students were able to learn the
main concepts of the application domain fairly quickly, as the client was available on short
notice for clarifying ambiguities and misunderstandings. Projects without a collocated client
have to find other ways to validate requirements and carefully track questions, ambiguities, and
changes.

Setting up a dedicated lab. The project benefited from a dedicated lab for students to
program, meet, prepare demonstrations, drink coffee, and conduct client presentations. A white
board was used for tracking current issues, task assignments, and project status, and was often
more up to date than the project web site. Having a single dedicated lab enabled informal
communication to take place and many design and management issues to be uncovered early and
resolved quickly.

Maintaining the infrastructure. The project organization chose to set up a tool team whose
responsibility was to find new development tools and existing class libraries and thereby to
support the infrastructure of the project. Because the participants of the tool team were
novices—which is typical for a student project course—they had little understanding of the
requirements of an infrastructure for supporting a large project. Moreover, as they did not
participate in the main development effort, they did not have much credibility with the other
students and were sidelined. We recommend instead to assign the responsibility of the
infrastructure to an administrative group independent of the specific project. Even in project-
based organizations, there is a need for project-independent support functions such as
infrastructure maintenance. Having a permanent infrastructure group makes it easier to reuse the
infrastructure across projects and increase the return on investment. The infrastructure group
also gains credibility with the developers with the accumulated experience from multiple
projects.

Using version control as an integration tool. The early set-up of a version control scheme
and build infrastructure in pre-development provided the teams with a concrete mechanism for
detecting and resolving conflicts early. Beginning with the pre-development phase of iteration 2
of this project, a “Hello World” prototype with corresponding build and test scripts was checked
into the version control repository. This practice is also being followed by many software
development companies, such as Microsoft [Cusumano & Selby, 1997].

16.5.3 Distributed Project: JAMES

Project goal

Smart card technology has opened up a vast range of applications. Some of the key
applications include pay phones, mobile communications, electronic cash, parking, health care
and network access. Another important application is the use of the smart card for the
automotive industry as a value-added service.
692 Chapter 16 • Methodologies: Putting It All Together

The goals of the JAMES project were twofold: First, to investigate JavaCard technology and
assess if it can be used to host multiple applications on the same card, the purpose being to
reduce the number of cards each individual needs to carry around. Second, to define a system
architecture that would enable users to select a combination of applications and dynamically
store them on their cards. This allows the car manufacturer to offer new services and
applications that could be added even after the purchase of the vehicle.
To accomplish these two goals, JAMES was to demonstrate a technology prototype that
included three smart card applications: Travel, a system for planning and following routes on an
onboard digital street map; Bonus, a reward system similar to a frequent flier mileage program;
and VIP, a system for storing and customizing individual preferences, such as seat position,
radio station, and audio volume settings.

Project environment

Proxy client. A proxy client from DaimlerChrysler was available full time during the project.
The proxy client presented the problem statement to the students during a kick-off meeting.
After the kick-off meeting, all communication with the client was through the proxy client. A
separate Lotus Notes database was set up exclusively for communication between the proxy
client and the students.

Novice participants. The developers of the JAMES project were drawn from the same pool of
senior students as the FRIEND project. The client and the proxy client came from the information
technology department of DaimlerChrysler and had knowledge of the application domain and
the software engineering methods used in the project.

No end user access. There was no access to the end user. Vehicle owners among the
developers and the proxy client were used as semi-representative end users.

Immature technology. The technology under evaluation (the Cyberflex kit developed by
Schlumberger [Schlumberger]) was in beta release. The JavaCard API it implemented was also
new, which resulted in a general lack of developer documentation and substantial time spent
working around bugs.

Three-site project. The project was distributed among three sites. One set of students was
working in Carnegie Mellon University (CMU), Pittsburgh, PA. The other set was working in
Technical University Munich (TUM), Germany. The client was located at Stuttgart, Germany,
and the proxy client for iteration 1 was located in Pittsburgh, collocated with the first team of
students. The proxy client returned to Stuttgart for the remaining iterations.

Project duration The project included three iterations, each lasting approximately four
months. The first was initiated at CMU; iteration 2 involved both the CMU and the TUM sites;
iteration 3 involved only the CMU site (Figure 16-4). The overall project, including pre- and
post-development, lasted 11 months.
Case Studies 693

Iteration 1 (CMU)
Iteration 2 (TUM)
Iteration 3 (CMU)

Jul. Sep. Nov. Jan. Mar. May

1998

Legend:

Predevelopment Development Postdevelopment

Figure 16-4 Iterations in the JAMES project.

How much planning?

The goal of the project was the demonstration of a conceptual prototype. Unlike FRIEND,
the demonstration environment was known in advance and constrained the development kit used
for programming the smart cards. This required more planning to take place earlier than in the
FRIEND project, as the project often worked with pre-release versions of the development tools.
Iteration 1 was planned as a waterfall iteration, similar to FRIEND. Fixed milestones delimited the
requirements, system design, implementation, and coding activities. Iteration 2 featured an
iterative prototyping approach, with prototypes of increasing functionality demonstrated every
month. The TUM and the CMU sites worked on different subsystems, but shared the same
architecture.

How much reuse?

The conceptual prototype was required to interact with an existing software system for
accessing dealer data. The existence of this legacy system and the short iteration times reduced
the opportunity to reuse components that were not already part of the existing infrastructure.

How much modeling?

Distributed software development can have several advantages. For example, a project can
leverage specific combinations of skills without relocating participants within the organization.
In JAMES, a substantial amount of knowledge needed to be transferred between sites at the
beginning of the second development phase. At CMU, most students participating in iteration 3
had participated in iteration 1. Hence, the knowledge transfer from iteration 1 to iteration 3 was
not an issue at CMU. At TUM, however, none of the participants were familiar with the system,
except for the instructor and one of the coaches. The participants at TUM were given access to
all the deliverables of iteration 1 and could communicate with the CMU team via Lotus Notes
694 Chapter 16 • Methodologies: Putting It All Together

and E-mail. To encourage further information exchange between both sites, two members from
the TUM team traveled to Pittsburgh early in iteration 2, and one member of the CMU team
traveled to Munich for the integration phase and the client acceptance test.
As in FRIEND, models in JAMES were used primarily as a basis for design and for
communication. The archival value of the documents produced by iteration 1 was limited, as
they were not consistent with the current version of the prototype. Students at the TUM site
reverse-engineered the first prototype system to recover an up-to-date model of the system,
correcting inconsistencies and omissions in the accompanying documentation. The result of this
activity, which we called Inventory Analysis, was an Inventory Analysis Document describing
the components of the first prototype and their implementation status (Table 16-10).
Table 16-10 Inventory documents.

Document Purpose Produced by

Inventory Analysis Describes the models and components that have Inventory Analysis
Document been realized, their status, and the problems
associated with them

How much process?

We refined the life cycle of the FRIEND project to include a second development iteration
and added activities focused on transferring knowledge from one site to the other (Table 16-11).
Both development iterations were structured in the same way, such that the same documents,
methods, and procedures could be used. The second development iteration, however, was an
improvement iteration that produced a refined version of the Requirements Analysis Document,
the System Design Document, the Object Design Document, and the prototype system.
Since the project relied on the JavaCard technology, one team on the TUM site was
responsible for developing focused technology prototypes showing how specific risks associated
with the prerelease state of the technology could be addressed. The technology team interacted
directly with the technology provider (Schlumberger’s smart card division), reported on its
current list of issues, and demonstrated its prototypes during the monthly reviews associated
with each document. These prototypes were subsequently used by other teams as sample code
for implementing their own subsystems.
In general, the process in iteration 2 evolved into an entity-based process—a process
focusing on the prototype, open issues, and changes, as opposed to focusing on the activities
(Section 15.4)—as issues associated with the JavaCard environment presented the highest risks.

How much control?

As in FRIEND, the JAMES project organization started as a strict hierarchical organization.
During iteration 1, 41 participants were organized into five teams (see Figure 16-5) each
responsible for a subsystem (Logbook, Maintenance, Travel, VIP and Vehicle). Two cross-
 Case Studies 695

Table 16-11 Activities for JAMES. Differences from FRIEND highlighted in italics.

Phase Purpose Activities IEEE 1074 activities

Pre- Initiate project Project Initiation 3.1 Project Initiation

development Concept Exploration 4.1 Concept Exploration
phase Top-level Design 4.2 System Allocation
First Validate Project Management 3.2 Project Monitor & Control
development architecture Requirements Elicitation 5.1 Requirements
phase Analysis
Train
System Design 5.2 Design
participants of
Object Design 5.2.7 Perform Detailed Design
first site
Implementation 5.3 Implementation
Demonstrate Unit Testing 7.1 Verification & Validation
core System Integration Testing
requirements System Testing (alpha test)
Configuration Management 7.2 Software Configuration
Demonstrate Management
feasibility Lectures & Tutorials 7.4 Training
Second Improve Inventory Analysis
development architecture Inventory Review
phase Project Management 3.2 Project Monitor & Control
Train
Requirements Elicitation 5.1 Requirements
participants of
Analysis
second site
Requirements Review
Demonstrate System Design 5.2 Design
extensibility System Design Review
Object Design 5.2.7 Perform Detailed Design
Demonstrate Object Design Review
desirable Implementation 5.3 Implementation
requirements Unit Testing 7.1 Verification & Validation
System Integration Testing
System Testing (alpha test)
Configuration Management 7.2 Software Configuration
Management
Tutorials 7.4 Training
Post- Demonstrate Project Management 3.2 Project Monitor & Control
development complete Refinement 6.3 Maintenance
phase functionality Install Software 6.1.5 Install Software
Client Acceptance Test 6.1.6 Accept Software
Deliver
Field Testing (beta test) 7.1 Verification & Validation
prototype
Configuration Management 7.2 Software Configuration
Client Management
acceptance
696 Chapter 16 • Methodologies: Putting It All Together

Management
(7)

Logbook Mainte- Travel (7) VIP (6) Vehicle (6)

(6) nance (7)

Architecture HCI Infrastructure

(6) (6) (2)
Legend
Liaison from management
Liaison to cross-functional team

Figure 16-5 Team organization of the development teams in Pittsburgh during iteration 1 (CMU Fall
course 15-413, 1997). White rectangles indicate subsystem teams; gray rectangles, cross-functional teams.
The numbers in parentheses indicate the number of team members.

functional teams, Architecture and HCI, composed of liaisons from the subsystem teams, were
responsible for coordinating issues related to system architecture and user interface,
respectively. Each team met weekly to report status and resolve open issues. Coaches of the
teams met with the project manager weekly.
During iteration 2, the two subsystem teams Bonus and VIP were located at TUM (23
participants), and the subsystem team Travel was at CMU (10 participants). The HCI and
Architecture teams were located at TUM and made into subsystem teams (as opposed to being a
cross-functional team). The team coaches reported to a site manager, who then reported to the
project manager. The coaches met weekly with the site manager. The project manager traveled
between sites every three weeks to coordinate and synchronize development at both sites.
As in FRIEND, the process was relaxed after two months into the iteration. During
iterations 1 and 2, this lead to similar results, with students finding roles in which they
performed best and a sustained meeting process that externalized status knowledge on the
bulletin boards. In the third iteration, however, the CMU team was sufficiently small that all
members could meet face to face in the same room. Consequently, it did not follow the meeting
process and posted fewer and fewer information on the bulletin boards, making it difficult to
communicate with the other site.

Outcome

The JAMES project ended in the successful demonstration of a prototype illustrating the
potential of automotive applications using the JavaCard technology. The demonstrated prototype
was not integrated, however: the final CMU and TUM demonstrations were based on different
versions of the architecture. The CMU team had simply ignored the revisions performed by the
TUM team and continued working on a branch dating back to the first development iteration.
Case Studies 697

This being our first experience with distributed projects, we encountered many difficult
issues that would have been simple to resolve in a non-distributed setting. For example, the final
client acceptance test was conducted on March 30, 1998, via a three-way video conference
between Pittsburgh, Munich, and Stuttgart. It was originally scheduled for 9 A.M. Pittsburgh
time and 3 P.M. German time. Unfortunately, Germany had switched to daylight saving time the
previous weekend, but the United States was to switch the following weekend. An American
student traveling to Munich caught the mistake (i.e., 3 P.M. CED was 8 A.M. EST), less than
48 hours before the meeting. Such miscalculations and misunderstandings cost the project quite
a bit in resources and additional stress.

Lessons learned
Training the client. Collaboration with the client turned out to be much more complicated
than originally expected for two reasons:

• During iteration 1, the proxy client was physically present at the development site and
always available. The proxy client quickly became familiar with the project process
and infrastructure, but she often had to forward information to the client for decisions.
The proxy client had the background and time to learn to use the infrastructure, but the
modeling information put out by the students was not at the right level of abstraction
for briefings at the client organization. Instead, all materials had to be translated and
summarized by the proxy client, which led to delayed responses from the client. A
scenario-based briefing approach, which we introduced at the end of the project,
improved this situation.
• During iteration 2, the proxy client was not physically present at either site. Electronic
communication and video conferencing during formal reviews were the only
communication medium during most of the iteration. Although this made it difficult for
the TUM team to come up to speed on the application domain, having the proxy client
back in her organization made it easier for the project to promote its results.

Training the developers about the process. In short iterations with students, quickly
teaching the software life cycle process know-how is critical to setting up the organization.
Starting with iteration 2, coaches were recruited from the best students of the previous iterations,
which made such quick ramp-up possible. Coaches were also able to disseminate application
domain knowledge and catch requirements problems early. Short iterations and high staff
turnover limit the number of tools that could be introduced. In general, changing the tools used
in the process and changes in the process itself are easier to accomplish between projects (as
opposed to during the project). For long-running projects, infrastructure and process changes
should occur only between releases.
Iteration overlap. The amount of time overlap between iterations in distributed projects
presents a critical project management trade-off. A small overlap prevents sufficient knowledge
698 Chapter 16 • Methodologies: Putting It All Together

to be transferred: participants from the second site will have to learn most of the knowledge
from work products only. A large overlap provides more opportunities for knowledge transfer in
the form of targeted questions and answers. If the second development phase starts too early,
however, participants of the second site interfere with the participants of the first site, who are
still in the process of creating the knowledge to be transferred.
Transferring implicit knowledge. Informal communication was not possible across sites,
because participants from different sites did not know each other. This prevented the
spontaneous information exchanges necessary for resolving issues and transferring implicit
knowledge. The only mechanism that worked effectively was travelling to the other sites.
Version control as an integration tool. In FRIEND, version control served as an integration
mechanism for teams to communicate. Occasionally, when a hand-over was necessary before a
change was fully integrated or debugged, incomplete versions were created for the sole purpose
of transferring files from one team to another. This use of the version control system, and more
generally, any informal use of a tool for communication, was not possible across sites.

16.5.4 Case Studies Summary

The projects we presented in this section spanned a broad spectrum in size, duration, and clients.
ATRACT included four participants; JAMES, more than 80. ATRACT was completed within six
months; FRIEND lasted two years. The types of clients each project interacted with also varied
significantly, from a chief of police with little experience of software engineering to an
information technology specialist with car manufacturing domain knowledge. Table 16-12
summarizes the variations in the project environment in all three projects.

Table 16-12 Summary of the project environment for the three case studies.

Problem Client Duration Distribution

ATRACT Test environment King 6 months Local client

for middleware

FRIEND Emergency King 4 months Local client

response system
(2 years, including
(Greenfield
follow-on projects)
engineering &
reengineering)

JAMES Smart card vehicle Proxy 11 months Remote client,

Applications 2 developer sites

As a result, each project selected different methods with different results. In the following
sections we discuss heuristics that we extracted from the three case studies in the areas of
planning, modeling, process, and control. Table 16-13 summarizes the decisions made by each
Case Studies 699

Table 16-13 Summary of the methods selected in the three case studies.

Planning Modeling Process Control

ATRACT XP-based planning Use cases Requirements Client

after detailed phase followed by demonstrations at
User stories
requirements three XP the end of each
development iteration
iterations

FRIEND Royce-based Client, Waterfall, followed Weekly team

iteration planning management, and by four unified meetings, monthly
system artifact sets process iterations client reviews
OMT

JAMES Royce-based Client, Waterfall, then Weekly team

iteration planning management, and unified process meetings, monthly
system artifact sets iterations project reviews,
monthly
UML
management
travel, inventory
analysis

project for these aspects. We do not discuss reuse since there was not a significant amount of
reuse in any of the three projects.

How much planning?

The milestones to plan and the level of detail in describing them depends on the project
goal. ATRACT produced a detailed functional specification within two months that enabled client
and developers to prioritize requirements, because the goal of the ATRACT project was a tool that
the client could use in a production environment. In iteration 1 of FRIEND, neither the client nor
the developers knew enough of each other’s domain to plan anything. Instead, demonstration
and review dates were agreed upon that provided flexibility in milestone content. As the project
made progress and the knowledge of both client and developers improved, more detailed plans
were developed.
In general, detailed planning should not be done before client and developers agree on
functionality and architecture. If the functionality or the architecture is still subject to substantial
change, then detailed planning is possible only for the next iteration. In all cases, it is important
to involve the client and the developers in the planning and ensure that likely planning changes
are made visible.
700 Chapter 16 • Methodologies: Putting It All Together

How much modeling?

The amount of modeling depends on the amount of knowledge that must be made explicit
and transferred among participants. In ATRACT, participants wrote use cases until they were
relatively confident that they understood the client’s requirements and that the client could
picture the system to be developed. After that point, no modeling took place as all three
participants shared the same location and could provided changes to the requirements
informally.
In FRIEND, detailed object models of the application domain and the system were
constructed; these were used to generate code. The application domain was much more foreign
to the developers than in ATRACT, and there were many more participants to bring up to speed.
The models were used primarily as a basis for design and for communication, but not for
archiving, as the prototype evolved rapidly.
In the distributed JAMES project, transferring knowledge across sites required that more
knowledge be made explicit. As in FRIEND, the models and the system were not kept consistent,
as the prototype evolved rapidly. Instead, students recovered the design of iteration 1 with
inventory analysis. Building detailed models would have been well worth the effort because of
the need to share knowledge across continents. However, this was difficult, given the fast pace of
changes and the scarce amount of resources. Moreover, detailed modeling was perceived as an
overhead activity benefiting the other site, and as contention developed between the sites, it was
not perceived as a critical activity. Sending developers across sites so they could meet in person
was more effective in sharing knowledge and in reducing contention than keeping detailed
models up to date.
In general, the cost of formalizing knowledge and keeping it up to date is high. It should
be viewed as an investment for

• enabling the validation of requirements or architectural decisions

• enabling participants of a single site to converge on a single-system concept
• supporting participants traveling among multiple sites.

The return on the investment is lowest for short projects and few participants. In this
situation, peer reviews seem to be a much more effective way to transfer knowledge.

How much process?

ATRACT followed an entity-based life cycle throughout development. FRIEND and JAMES
started with a waterfall iteration and switched to an entity-based life cycle after the client
reviewed the first prototype. At the beginning of the FRIEND and JAMES projects, iteration 1 was
necessary to train novice developers. By the end of all three projects, however, developers were
following a life cycle similar to XP with short iterations and daily builds. All three projects were
small enough that they could maintain a small team atmosphere locally. Note that in the case of
JAMES, the entity life cycle was not integrated across sites. Although JAMES met its goals and was
Case Studies 701

considered successful, it failed to keep the system design at both sites in sync. An activity-based
life cycle for managing cross-site issues would have been necessary in a project developing
production code to enable sufficient control. Entity-based life cycles require close collaboration
and informal communication to enable developers to resolve problems discovered in daily
builds.

How much control?

The amount of control evolved and spanned the entire spectrum during the life cycle of
each project. FRIEND and JAMES started with strict hierarchical organizations in the first two
months of the iteration. This enabled the systematic rotation of roles in the project and a large
amount of status and technical information made explicit on the bulletin board. Consequently, by
the time coding was started (usually around Thanksgiving), students with leadership and
communication skills naturally assumed team leader and liaisons roles, respectively. Moreover,
the procedures that yielded benefits (e.g., writing meeting minutes) were deemed worth the
overhead associated with them, so they were kept by the students. In our experience, this enabled
us to relax the enforcement of procedures when students came back from Thanksgiving break,
leading to an agile, entity-based process. Technical decisions were made locally within teams,
and conflicts and issues could be dealt with faster than they could be communicated to
management.
In other words, the first two months of the iteration were used to set up a consistent vision
of the requirements and the architecture. Once these seeds were firmly planted, project
management could be relaxed. The project then evolved as a living organism, using natural
selection and self-organization. The team structure, the communication paths set up by the
liaison, and the meeting procedures usually survived the transition. The increasing deadline
pressure associated with the client acceptance test (which could not be rescheduled) ensured that
the project remained focused and that all teams worked in the same direction. Although the level
of experience and the number of participants prevented us from starting with a self-organizing
project, we were able to evolve into one by planting the appropriate seeds early in the iteration.
In FRIEND, this was possible because all developers had access to the client, who was able to
provide a coherent picture of the application domain. In JAMES, the distribution of the project
made a coherent evolution toward the client acceptance test much more difficult.
In general, an agile organization can function when all key participants share the same
goal and the same architectural concept, either because they are provided with the same vision
from the client or because the system concept is strong enough to herd them in a single direction.
Hierarchical organizations become necessary when stakeholders put forward many conflicting
criteria and contend for a limited amount of resources.
702 Chapter 16 • Methodologies: Putting It All Together

Methodological Heuristics
Be prepared to change the system. Changes to the software system will occur throughout the project.
The changes come from the client side (unforeseen usability issues, new requirements) as well as from
the development side (unforeseen technical issues, new architectural decisions). Trying to freeze the
specification may be desirable to make a project predictable, but it usually leads to an inferior product
that doesn’t meet the end users’ expectations. Instead, accept the concept that requirements and
architecture change throughout the project and define change management processes.
Be prepared to change the organization. Hierarchical projects and self-organizing projects have
different strengths. Hierarchical organizations are more predictable and more effective for getting a
project off the ground. Self-organizing projects foster more innovation and can lead to superior
products, with appropriate guidance. After developer expertise in the software life cycle increases and
after a common vision for the system requirements and architecture emerges, one should consider
delegating decision making to the individuals who have the knowledge to make the decision. This in
turn requires increased ability to assess actual progress with quality indicators and management metrics.
Be prepared to change the process. Expertise and common vision also facilitates adapting the process.
The software life cycle model can evolve from an activity-based process to an entity-based process in
which work is assigned in terms of changes to the baseline. As the core requirements are completed, the
project can be driven by time (e.g., release on a certain date) instead of by feature (e.g., release when
specific features are completed).
Shorten client decision time. The client must often be involved when dealing with major changes in the
project (new functionality, new release plan). Shortening the time needed for such critical decisions is
key to preventing the project from moving in the wrong direction. This requires an effective
communication mechanism for providing information to the client and resolving the issue with the right
decision maker. Local king clients are ideal for this. For projects without local kings, responsive
information and decision channels need to be put in place between the client and the project.
Build trust. Participants are reluctant to report bad news, especially if it stems from their own mistakes.
Moreover, if they believe they might be punished for making or reporting mistakes, the issue will simply
be covered up. Knowing about these mistakes early, however, is often the difference between a success
and a failure. Conversely, providing the resources and control to participants to address the reported,
unexpected problems helps keep the focus on a successful project outcome.
Learn the right lessons and nothing more. Delegating decision making can lead to perceived short-term
successes, which can result in the wrong lessons being learned. A solo heroic effort can be the
difference between meeting a milestone and missing it. However, the concentration of knowledge in a
limited number of participants can hurt the project and may lead to more serious failures down the road.
Moving from a command-and-control organization to a leadership-and-collaboration organization
requires the manager to become a teacher. Often, mistakes have to be made to ensure that the right
lessons are learned.
Further Readings 703

16.6 Further Readings

The word is still open to whether Scrum scales up to very large projects with multiple
development teams. Proposals to solve this challenge include Scrums of Scrums which
include representatives of each development team, starting the project with a single Scrum
and seeding new teams with members of the first Scrum [Larman & Vodde, 2008].
Some researchers argue that software development is chaotic (in the sense of the
mathematical chaos theory); that is, small variations can have a big influence on the outcome of
a software project. Gleick has written a very readable introduction to chaos theory [Gleick,
1987]. Dee Hock introduced the notion of chaordic systems to describe organizations in which
the chaos of competition and the order of cooperation coexist and thrive [Hock, 1999].
Petroski has described the critical role that failure plays in successful designs ([Petroski,
1994]). In particular, he argues that technological innovation is often a response to the failures of
existing products. His books are written from the point of view of civil engineering, but many
observations are applicable to software engineering as well.

16.7 Exercises
16-1 What is the difference between a software life cycle and a methodology?
16-2 You are improving a legacy system. You need to customize a software life cycle for
your project. Which activities would you need? In which order?
16-3 Royce uses a management metric that counts the number of participants who leave the
project or join the project. You are managing a multi-team project and notice that the
staff turnover in one team is high. Hypothesize what causes could lead to such a
symptom. For each cause, propose a remedy.
16-4 The heuristics we outlined in Section 16.5.4 indicate that the need for models is higher
in distributed organizations. Open-source projects are highly distributed projects that
follow an entity-based life cycle and typically do not have requirements or system
design documents. Provide examples of how modeling knowledge is made explicit and
transferred among participants in such cases.
16-5 Royce’s methodology considers six project factors (scale, stakeholder cohesion,
process flexibility, process maturity, architectural risk, and domain experience) when
tailoring a process for a specific project (Section 16.4.1). Use these factors to describe
which types of projects could use XP as an appropriate methodology. Justify your
choice for each factor.
16-6 While working with Staphylococcus bacteria in 1928, Sir Alexander Fleming
accidently dropped some bread crumbs on one of the dishes. After a week the bacteria
on this dish did not grow as expected. Fleming noticed a bacteria-free circle around a
mold that was contaminating the staphylococcus culture. Instead of throwing the dish
away because the planned experiment had failed, he isolated the mold, grew it in a fluid
medium, and discovered a substance that prevented growth of the bacteria even when it
704 Chapter 16 • Methodologies: Putting It All Together

was diluted 800 times. Discuss the discovery of penicillin using the terminology and
issues introduced in this chapter.
16-7 Based on the assumption that the earth was round, Columbus’s goal was to find a
shorter way to India by going west instead of east. He encountered America instead of
India. Discuss the discovery of America by Columbus using the terminology and issues
introduced in this chapter.
16-8 Select a project you have been involved with. Using the methodological categories
defined in this chapter, describe the trade-offs that occurred in the project.

References
[AgileManifesto, 2001] http://www.agilemanifesto.org.
[Aguanno, 2005] K. Aguanno, Managing Agile Projects, Multi-Media Publications, Ontario, 2005.
[Ambler, 2002] S. Ambler, Agile Modeling: Effective Practices for Extreme Programming and the
Unified Process, John Wiley & Sons, 2002.
[Beck & Andres, 2005] K. Beck & C. Andres, Extreme Programming Explained: Embrace Change, 2nd ed.,
Addison-Wesley, Reading, MA, 2005.
[Boehm et al., 2000] B. Boehm, E. Horowitz, R. Madachy, D. Reifer, B. K. Clark, B. Steece, A. W. Brown,
S. Chulani, & C. Abts, Software Cost Estimation with COCOMO II, Prentice Hall,
Upper Saddle River, NJ, 2000.
[Bonatti, 2001] W. Bonatti, The Mountains of My Life, Modern Library, Random House, New York,
2001.
[Buhl, 1956] H. Buhl, Nanga Parbat Pilgrimage, Hodder & Stoughton, London, 1956.
[Cockburn, 2001] A. Cockburn, Agile Software Development, Addison-Wesley, Reading, MA, 2001.
[Cohn, 2006] M. Cohn, Agile Estimating and Planning, Pearson, Upper Saddle River, NJ, 2006.
[Cusumano & Selby, 1997] M. A. Cusumano & R. W. Selby, “How Microsoft Builds Software,” Communications
of the ACM, Vol. 40, No. 6, pp. 53–61, 1997.
[Deming, 1982] E. W. Deming, Out of the Crisis, MIT Press, Cambridge, MA, 1982. 2ed. published
2000.
[Fowler, 2005] M. Fowler, The new methodology,
http://www.martinfowler.com/articles/newMethodology.html. Revised 2005.
[Gleick, 1987] J. Gleick, Chaos - Making a New Science, Penguin Books Ltd, Harmondsworth,
Middlesex, 1987.
[Gladwin, 1964] T. Gladwin, “Culture and logical process,” in W. Goodenough (ed.), Explorations in
Cultural Anthropology: Essays Presented to George Peter Murdock, McGraw-Hill,
New York, 1964.
[Grenning, 2002] J. Grenning, Planning Poker, http://www.planningpoker.com/ 2002.
[Highsmith & Orr, 2000] J. Highsmith & K. Orr, Adaptive Software Development: A Collaborative Approach to
Managing Complex Systems, Dorset House, 2000.
[Highsmith, 2004] J. Highsmith, Agile Project Management, Pearson Education, Boston, 2004.
[Hock, 1999] D. Hock, Birth of the Chaordic Age, Berrett-Koehler Publishers, San Francisco, 1999.
[Kelly, 1984] J. F. Kelly, “An iterative design methodology for user-friendly natural language office
information applications,” ACM Transactions on Information Systems, Vol. 2, No. 1,
January 1984.
References 705

[Larman & Vodde, 2008] C. Larman & B. Vodde, Scaling Lean & Agile Development: Thinking and
Organizational Tools for Large-Scale Scrum, Addison-Wesley, Reading, MA, 2008.
[Marshall, 2001] R. Marshall, What really happened at K2? Chapter 24 in [Bonatti, 2001].
[Norman, 2002] D. A. Norman, The Design of Everyday Things, Basic Books, New York, 2002.
[Palmer & Felsing, 2002] S. Palmer & J. Felsing, A Practical Guide to Feature-Driven Development, Prentice
Hall, Upper Saddle River, NJ, 2002.
[Paulk et al., 1995] M. C. Paulk, C. V. Weber, B. Curtis (eds.), The Capability Maturity Model: Guidelines
for Improving the Software Process, Addison-Wesley, Reading, MA, 1995.
[Petroski, 1992] H. Petroski, To Engineer is Human, Vintage Books, Random House, New York, 1992.
[Petroski, 1994] H. Petroski, The Evolution of Useful Things, Vintage Books, Random House, New
York, 1994.
[Royce, 1998] W. Royce, Software Project Management: A Unified Framework, Addison-Wesley,
Reading, MA, 1998.
[Rumbaugh et al., 1991] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, & W. Lorensen, Object-Oriented
Modeling and Design, Prentice Hall, Englewood Cliffs, NJ, 1991.
[Schlumberger] Schlumberger, http://www.cyberflex.com/.
[Schwaber, 1995] K, Schwaber, “Scrum Development Process,” Business Object Design and
Implementation Workshop, OOPSLA’95, Austin, TX, October 1995.
[Schwaber & Beedle, 2002] K. Schwaber & M. Beedle, Agile Software Development with Scrum, Prentice Hall,
Upper Saddle River, NJ, 2002.
[Suchman, 2007] L. A. Suchman, Human-Machine Reconfiguration: Plans and Situated Actions, 2nd
ed. Cambridge University Press, 2007.
[Takeuchi & Nonaka, 1986] H. Takeuchi &I. Nonaka. “The New New Product Development Game” Harward
Business Review, 1986.
[Taylor, 1911] F. W. Taylor, The Principles of Scientific Management, Harper Bros., New York, 1911.
[Tunde & Ray, 1994] A. O. Babatunde & W. H. Ray, Process Dynamics, Modeling and Control, Oxford
University Press, 1994.
[Weinberg, 1971] G. M. Weinberg, The Psychology of Computer Programming, Van Nostrand, New
York, 1971.
This page intentionally left blank
PART IV
Appendices
This page intentionally left blank
 A P P E N D I X A

Design Patterns

D esign patterns are partial solutions to common problems, such as separating an interface
from a number of possible implementations, wrapping around a set of legacy classes, or
protecting a caller from changes associated with specific platforms. A design pattern is
composed of a small number of classes that, through delegation and inheritance, provide a
robust and modifiable solution. These classes can be adapted and refined for the specific system
under construction. In addition, design patterns provide examples of inheritance and delegation.
Since the publication of the first book on design patterns for software [Gamma et al.,
1994], many additional patterns have been proposed for a broad variety of problems, including
analysis [Fowler, 1997] [Larman, 2005], system design [Buschmann et al., 1996], middleware
[Mowbray & Malveau, 1997], process modeling [Ambler, 1998], dependency management
[Feiler & Tichy, 1998], configuration management [Brown et al., 1999], and methodology
adoption [Elssamadisy, 2009]. The term itself has become a buzzword attributed to many
different definitions. In this book, we focused only on the original catalog of design patterns, as
it provides a concise set of elegant solutions to many common problems. This appendix
summarizes the design patterns we use in the book and natural language heuristics for applying
them. For each pattern, we provide pointers to the examples in the book. Our goal is to provide a
quick reference. We assume from the reader a basic knowledge of design patterns, object-
oriented concepts, and UML class diagrams.

709
710 Appendix A • Design Patterns

A.1 Abstract Factory: Encapsulating Platforms

Name Abstract Factory Design Pattern

Problem description Shield the client from different platforms that provide different implementations
for the same set of concepts.
Solution A platform (e.g., a windowing system) is represented as a set of
AbstractProducts, each representing a concept (e.g., a button) that is
supported by all platforms. An AbstractFactory class declares the operations
for creating each individual product. A specific platform is then realized by a
ConcreteFactory and a set of ConcreteProducts (one for each
AbstractProduct). A ConcreteFactory depends only on its related
ConcreteProducts. The Client depends only on the AbstractProducts and
the AbstractFactory classes, making it easy to substitute platforms.
Client AbstractFactory

createProductA()
createProductB()

ConcreteFactory1 ConcreteFactory2

createProductA() createProductA()
createProductB() createProductB()

AbstractProductA AbstractProductB

ProductA1 ProductA2 ProductB1 ProductB2

Consequences • Client is shielded from concrete product classes.

• Substituting families at runtime is possible.
• Adding new products is difficult since new realizations for each factory must
be created.
Examples • Statically encapsulating incompatible infrastructures for intelligent houses
(Section 8.4.4)
• Game independence in ARENA (Section 8.6.1)
Related concept • Specification inheritance and implementation inheritance (Section 8.3.2).

Figure A-1 The Abstract Factory design pattern (adapted from [Gamma et al., 1994]).
Appendix A • Design Patterns 711

A.2 Adapter: Wrapping Around Legacy Code

Name Adapter Design Pattern

Problem description Convert the interface of a legacy class into a different interface expected by the
client, so that the client and the legacy class can work together without changes.
Solution An Adapter class implements the ClientInterface expected by the client.
The Adapter delegates requests from the client to the LegacyClass and
performs any necessary conversion.

Client

ClientInterface LegacyClass

Request() ExistingRequest()
adaptee

Adapter

Request()

Consequences • Client and LegacyClass work together without modification of either

Client or LegacyClass.
• Adapter works with LegacyClass and all of its subclasses.
• A new Adapter needs to be written for each specialization (e.g., subclass) of
ClientInterface.

Example • Sorting instances of an existing String class with an existing sort()

method (Section 8.4.2): MyStringComparator is an Adaptor for bridging
the gap between the String class and the Comparator interface used by the
Array.sort() method.

Related concept • The Bridge (Section A.3) fills the gap between an interface and its
implementations.

Figure A-2 The Adapter design pattern (adapted from [Gamma et al., 1994]).
712 Appendix A • Design Patterns

A.3 Bridge: Allowing for Alternate Implementations

Name Bridge Design Pattern

Problem description Decouple an interface from an implementation so that implementations can be
substituted, possibly at runtime.
Solution The Abstraction class defines the interface visible to the client. The
Implementor is an abstract class that defines the lower-level methods available
to Abstraction. An Abstraction instance maintains a reference to its
corresponding Implementor instance. Abstraction and Implementor can be
refined independently.

Client

imp
Abstraction Implementor

Concrete Concrete
RefinedAbstraction ImplementorA ImplementorB

Consequences • Client is shielded from abstract and concrete implementations.

• Interfaces and implementations can be refined independently.
Example • Testing different implementations of the same interface (Section 8.4.1).
Related concept • The Adapter pattern (Section A.2) fills the gap between two interfaces.

Figure A-3 The Bridge design pattern (adapted from [Gamma et al., 1994]).
Appendix A • Design Patterns 713

A.4 Command: Encapsulating Control Flow

Name Command Design Pattern

Problem description Encapsulate requests so that they can be executed, undone, or queued
independently of the request.
Solution A Command abstract class declares the interface supported by all
ConcreteCommands. ConcreteCommands encapsulate a service to be applied to
a Receiver. The Client creates ConcreteCommands and binds them to specific
Receivers. The Invoker actually executes or undoes a command.

Invoker Command
invokes
execute()
execute()

Client

«binds»
Receiver ConcreteCommand1
action1()
action2() execute()

ConcreteCommand2

execute()

Consequences • The object of the command (Receiver) and the algorithm of the command
(ConcreteCommand) are decoupled.
• Invoker is shielded from specific commands.
• ConcreteCommands are objects. They can be created and stored.
• New ConcreteCommands can be added without changing existing code.
Examples • Providing an undo stack for user commands: All user-visible commands are
refinements of the Command abstract class. Each command is required to
implement the do(), undo(), and redo() methods. Once a command is
executed, it is pushed onto an undo stack. If the user wishes to undo the last
command, the Command object on the top of the stack is sent the message
undo().
• Decoupling interface objects from control objects (Section 8.4.5, see also
Swing Actions, [JFC, 2009]): All user-visible commands are refinements of
the Command abstract class. Interface objects, such as menu items and
buttons, create and send messages to Command objects. Only Command
objects modify entity objects. When the user interface is changed (e.g., a
menu bar is replaced by a tool bar), only the interface objects are modified.
• Decoupling Moves from Games in ARENA (Section 8.6.2)
Related concept • MVC architecture (Figure 6-15).

Figure A-4 The Command design pattern (adapted from [Gamma et al., 1994]).
714 Appendix A • Design Patterns

A.5 Composite: Representing Recursive Hierarchies

Name Composite Design Pattern

Problem description Represent a hierarchy of variable width and depth so that leaves and composites
can be treated uniformly through a common interface.
Solution The Component interface specifies the services that are shared among Leaf and
Composite (e.g., move(x,y) for a graphic element). A Composite has an
aggregation association with Components and implements each service by
iterating over each contained Component (e.g., the Composite.move(x,y)
method iteratively invokes the Component.move(x,y)). The Leaf services do
the actual work (e.g., Leaf.move(x,y) modifies the coordinates of the Leaf
and redraws it).
Component
*

Leaf Composite
leaves

Consequences • Client uses the same code for dealing with Leaves or Composites.
• Leaf-specific behavior can be modified without changing the hierarchy.
• New classes of Leaves can be added without changing the hierarchy.
Examples • Groups of drawable elements: Drawable elements can be organized in
groups that can be moved and scaled uniformly. Groups can also contain
other groups.
• Hierarchy of files and directories (Figure 2-28): Directories can contain files
and other directories. The same operations are available for moving,
renaming, and removing files as well as directories.
• Describing subsystem decomposition (Figure 6-3): We use a Composite
pattern to describe subsystem decomposition. A subsystem is composed of
classes and other subsystems. Note that subsystems are not actually
implemented as Composites to which classes are dynamically added.
• Describing hierarchies of tasks (Figure 6-8): We use a Composite pattern to
describe the organizations of Tasks (Composites) into Subtasks
(Components) and ActionItems (Leaves).We use a similar model to
describe Phases, Activities, and Tasks (Figure 15-6).
Related concept • Facade pattern (Section A.6).

Figure A-5 The Composite design pattern (adapted from [Gamma et al., 1994]).
Appendix A • Design Patterns 715

A.6 Facade: Encapsulating Subsystems

Name Facade Design Pattern

Problem description Reduce coupling between a set of related classes and the rest of the system.
Solution A single Facade class implements a high-level interface for a subsystem by
invoking the methods of lower-level classes. A Facade is opaque in the sense
that a caller does not access the lower-level classes directly. The use of Facade
patterns recursively yields a layered system.

Compiler
Compiler

compile(s)

CodeGenerator Lexer

create() getToken()

Optimizer Parser

create() generateParseTree()

ParseTree

create()

Consequences • Shields a client from the low-level classes of a subsystem.

• Simplifies the use of a subsystem by providing higher-level methods.
Example • Subsystem encapsulation (Figure 6-30): A Compiler is composed of Lexer,
Parser, ParseTree, a CodeGenerator, and an Optimizer. When compiling
a string into executable code, however, a caller deals only with the Compiler
class, which invokes the appropriate methods on the contained classes.
Related concept • Coupling and cohesion (Section 6.3.3), layers and partitions (Section 6.3.4),
Composite patterns (Section A.5).

Figure A-6 The Facade design pattern (adapted from [Gamma et al., 1994]).
716 Appendix A • Design Patterns

A.7 Observer: Decoupling Entities from Views

Name Observer Design Pattern

Problem description Maintain consistency across the states of one Publisher and many Subscribers.
Solution A Publisher (called a Subject in [Gamma et al., 1994]) is an object whose
primary function is to maintain some state—for example, a matrix. One or more
Subscribers (called Observers in [Gamma et al., 1994]) use the state
maintained by a Publisher—for example, to display a matrix as a table or a
graph. This introduces redundancies between the states of the Publisher and
the Subscribers. To address this issue, Subscribers invoke the subscribe()
method to register with a Publisher. Each ConcreteSubscriber also defines
an update() method to synchronize the state between the Publisher and the
ConcreteSusbcriber. Whenever the state of the Publisher changes, the
Publisher invokes its notify() method, which iteratively invoke each
Subscriber.update() method.
subscribers
Publisher Subscriber
1 *
filename
subscribe(Subscriber) update()
unsubscribe(Subscriber)
notify()

ConcretePublisher ConcreteSubscriber
state observerState
getState() update()
setState()

Consequences • Decouples a Publisher from the Subscribers.

• Can result in many spurious broadcasts when the state of a Publisher
changes.
Examples • The Observer interface and Observable class are used in Java to realize an
Observer pattern ([JFC, 2009]).
• The Observer pattern can be used for realizing subscription and notification
in a Model/View/Controller architecture (Figure 6-15).
• Decoupling Match state from MatchView in ARENA (Section 8.6.3).
Related concept • Entity, interface, control objects (Section 5.3.2).

Figure A-7 The Observer design pattern (adapted from [Gamma et al., 1994]).
Appendix A • Design Patterns 717

A.8 Proxy: Encapsulating Expensive Objects

Name Proxy Design Pattern

Problem description Improve the performance or the security of a system by delaying expensive
computations, using memory only when needed, or checking access before
loading an object into memory.
Solution The ProxyObject class acts on behalf of a RealObject class. Both classes
implement the same interface. The ProxyObject stores a subset of the
attributes of the RealObject. The ProxyObject handles certain requests
completely (e.g., determining the size of an image), whereas others are
delegated to the RealObject. After delegation, the RealObject is created and
loaded in memory.
Object
filename
op1()
op2()

ProxyObject RealObject
1 0..1
filename data:byte[]
op1() op1()
op2() op2()

Consequences • Adds a level of indirection between Client and RealObject.

• The Client is shielded from any optimizations for creating RealObjects.
Examples • Protection proxy (Figure 7-9): An Access association class contains a set of
operations that a Broker can use to access a Portfolio. Every operation in
the PortfolioProxy first checks with isAccessible() if the invoking
Broker has legitimate access. Once access has been granted,
PortfolioProxy delegates the operation to the actual Portfolio object. If
access is denied, the actual Portfolio object is not loaded into memory.
• Storage proxy (Figure 10-7): An ImageProxy object acts on behalf of an
Image stored on disk. The ImageProxy contains the same information as the
Image (e.g., width, height, position, resolution) except for the Image
contents. The ImageProxy services all content-independent requests. Only
when the Image contents must be accessed (e.g., when the Image is drawn
on the screen) does the ImageProxy create the RealImage object and load
its contents from disk.
Related concept • Caching expensive computations (Section 10.4.1).

Figure A-8 The Proxy design pattern (adapted from [Gamma et al., 1994]).
718 Appendix A • Design Patterns

A.9 Strategy: Encapsulating Algorithms

Name Strategy Design Pattern

Problem description Decouple a policy-deciding class from a set of mechanisms so that different
mechanisms can be changed transparently from a client.
Solution A Client accesses services provided by a Context. The Context services are
realized using one of several mechanisms, as decided by a Policy object. The
abstract Strategy class describes the interface that is common to all
mechanisms that Context can use. The Policy class creates a Concrete–
Strategy object and configures the Context to use it.

Client Policy

Context Strategy

contextInterface() algorithmInterface()

ConcreteStrategyA ConcreteStrategyB

Consequences • ConcreteStrategies can be substituted transparently from Context.

• Policy decides which Strategy is best, given the current circumstances
(e.g., speed vs. space trade-off).
• New algorithms can be added without modifying Context or Client.
Example • Network switching in mobile applications (Section 8.4.3): A mobile
application needs to deal with a variety of network access protocols (phone,
wireless, LAN), depending on the context of the user (location,
communication costs, etc.). To decouple the policy from selecting a network
from the network interface, we encapsulate the network access protocol
implementations with a Strategy pattern.
Related concept Adaptor pattern (Section A.2) and Bridge pattern (Section A.3).

Figure A-9 The Strategy design pattern (adapted from [Gamma et al., 1994]).
Appendix A • Design Patterns 719

A.10 Heuristics for Selecting Design Patterns

Natural language heuristics for selecting design patterns

Design patterns address specific design goals and nonfunctional requirements. Similar to Abbott’s
heuristics described in Chapter 5, Analysis, key phrases can be used to identify candidate design
patterns. Below are examples for the patterns covered in this chapter.

Phrase Design Pattern

• “Manufacturer independence” Abstract Factory

• “Platform independence”

• “Must comply with existing interface” Adapter

• “Must reuse existing legacy component”

• “Must support future protocols” Bridge

• “All commands should be undoable” Command

• “All transactions should be logged”

• “Must support aggregate structures” Composite

• “Must allow for hierarchies of variable depth
and width”

• “Policy and mechanisms should be decoupled” Strategy

• “Must allow different algorithms to be
interchanged at runtime”
720 Appendix A • Design Patterns

References
[Ambler, 1998] S. W. Ambler, Process Patterns: Building Large-Scale Systems Using Object
Technology, Cambridge University Press, New York, 1998.
[Brown et al., 1999] W. J. Brown, H. W. McCormick, & S. W. Thomas, AntiPatterns and Patterns in
Software Configuration Management, Wiley, New York, 1999.
[Buschmann et al., 1996] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, & M. Stal, Pattern-Oriented
Software Architecture: A System of Patterns, Wiley, Chichester, U.K., 1996.
[Elssamadisy, 2009] A. Elssamadisy, Agile Adoption Patterns, Addison-Wesley, Reading, MA, 2009.
[Feiler & Tichy, 1998] P. Feiler & W. Tichy, “Propagator: A family of patterns,” Proceedings of
TOOLS-23’97, July 28–August 1 1997, Santa Barbara, CA.
[Fowler, 1997] M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, Reading,
MA, 1997.
[Gamma et al., 1994] E. Gamma, R. Helm, R. Johnson, & J. Vlissides, Design Patterns: Elements of
Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1994.
[JFC, 2009] Java Foundation Classes, JDK Documentation, Javasoft, 2009.
[Larman, 2005] C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design, 3rd ed., Prentice Hall, Upper Saddle River, NJ, 2005.
[Mowbray & Malveau, 1997] T. J. Mowbray & R. C. Malveau, CORBA Design Patterns, Wiley, New York, 1997.
 A P P E N D I X B

Glossary

abstract class Superclass that is used only for specialization and never instantiated. Abstract
class names are italicized.
abstract data type A data type defined by an implementation-independent specification.
abstraction The classification of phenomena into concepts. See also modeling.
acceptance testing A system testing activity during which the client decides whether the
system meets the acceptance criteria.
access control list A representation of the access control matrix in which legitimate rights are
represented as a list of (actor, operation) pairs attached to the class that is controlled.
access right A cell in the access control matrix that represents which operations a specific
actor may invoke on a specific class.
accuracy A quantitative measure of the magnitude of error.
action A fundamental unit of behavior. Actions can take a set of inputs, produce a set of
outputs, and change the state of the system. Actions are fundamental in the sense that they are
not decomposed further. Actions can be associated with specific points in a state machine, such
as transitions, state entry, and state exit. Actions normally take a short amount of time to execute
and cannot be interrupted.
action item A task assigned to a participant with a completion date, usually as a result of an
issue resolution.
activity In a software life cycle, a set of tasks performed toward a specific purpose. Activities
can include few or many tasks, depending on their goal. Examples of activities include
requirements elicitation, object identification, and unit testing. See also process.

721
722 Appendix B • Glossary

In a state machine diagram, a behavior executed as long as an object resides in some state.
Whereas an action is short and non-interruptible, an activity can take a substantial amount of
time and is interrupted when a transition exiting the state is fired. Contrast with action.
activity-centered software life cycle model A software life cycle model that represents
primarily the activities of development. Contrast with entity-centered software life cycle model.
activity diagram UML notation representing the behavior of a system in terms of activities.
An activity is a state that represents the execution of a set of operations. The completion of these
operations then triggers a transition to another activity. Activity diagrams are used to illustrate
combinations of control and data flow.
activity partition See swimlane.
actor External entity that needs to exchange information with the system. An actor can
represent either a user role or another system.
adaptability The ability to change the system to deal with additional application domain
concepts.
aggregation An association denoting a whole–part relationship between two classes. For
example, a System is composed of Subsystems is an aggregation association.
alternative See proposal.
ambiguity Property of a model indicating whether a concept corresponds to two or more
unrelated phenomena.
analysis An activity during which developers ensure that the system requirements are correct,
complete, consistent, and unambiguous. Analysis produces the analysis model.
analysis model A model of the system that aims to be correct, complete, consistent, and
unambiguous. The analysis model consists of the functional model, the analysis object model,
and the dynamic model.
analysis object model The object model produced during analysis. The analysis object model
describes the application domain concepts that the system manipulates and the user-visible
interfaces of the system.
analyst The role of the developers who elicit application domain information from users and
clients and construct a use case model of the system under development.
API See Application Programmer Interface.
API engineer A role concerned with defining the API of a subsystem. This role is often
combined with the role of architecture liaison.
application domain Represents all aspects of the user’s problem. This includes the physical
environment in which the system will run, the users, and their work processes. The application
domain is represented by the analysis model during requirements and analysis activities. The
application domain is also called the problem domain. Contrast with solution domain.
Appendix B • Glossary 723

application domain specialist A consultant role responsible for providing application domain
expertise to a project.
application framework A reusable partial application that can be specialized to produce
custom applications. See also class libraries.
application object Object in the analysis model that represents an application domain
concept. The application object is also called the application domain object.
Application Programmer Interface (API) Set of fully specified operations provided by a
subsystem.
architect The role of the developers who make strategic system decisions and construct the
system design model.
architectural pattern See architectural style.
architectural style A general system design model that can be used as a starting point for
system design. Examples of architectural styles include client/server, peer to peer, pipe and
filter, and model/view/controller.
architecture See system design model.
architecture liaison The role of the developers who represent a subsystem team in the
architecture team. They convey information from their team, negotiate interface changes, and
ensure the consistency of APIs across the system.
argument Value passed along with a message.
argumentation The debate among participants to resolve an issue.
as-is scenario Scenario that describes an existing system. As-is scenarios can be used to
validate the developers’ understanding of the system with users.
association A relationship between two or more classes denoting the possible links between
instances of the classes. An association has a name and can have multiplicity and role
information attached to each of its ends.
association class An association with attributes and operations.
attribute A named property of a class defining a range of the values an object can contain. For
example, time is an attribute of the class Watch.
attribute type See type.
attribute visibility Specifies whether or not the attribute can be accessed by other classes.
auditing Validation of versions before a release to ensure consistent and complete delivery.
auditor The role responsible for selecting and evaluating promotions for release.
authentication The process of associating a person with access rights.
724 Appendix B • Glossary

availability The degree to which a system or component is operational and accessible when
required for use.
base class See superclass.
baseline A version of a configuration item that has been formally reviewed and agreed on.
bazaar model A project organization that includes a dynamic and distributed set of
collaborating groups. Contrast with cathedral model.
big bang testing An integration testing strategy in which all components are tested together as
a whole after they have been unit tested.
blackbox framework A framework that relies on well-defined interfaces for extensibility.
Contrast with whitebox framework.
blackbox test A test which focuses on the input/output behavior of a component without
considering its implementation. Contrast with whitebox test.
bottom-up testing An integration testing strategy in which components are incrementally
integrated starting at the lowest level. Bottom-up testing does not require any test stubs. Contrast
with top-down testing, sandwich testing.
boundary object An object that represents the interactions between the user and the system.
boundary condition A special condition the system must handle. Boundary conditions
include start-up, shutdown, and exceptions.
boundary use case A use case for dealing with a boundary condition.
brainstorming A scheduled communication event during which participants generate a large
number of alternatives.
branch A concurrent development path under configuration management.
bug See fault.
build management Tool support for automatically rebuilding the system when new versions
are added.
buried association A foreign key used to represent a one-to-many or a many-to-many
association when mapping an object model to a relational schema.
callback An operation that is temporary and dynamically registered with a class, usually for
the purpose of notification. For example, the subject object in the observer pattern invokes
callbacks to notify subscribed observers.
candidate key In a database management system, a set of attributes that could be used as a
primary key.
capability A representation of access control in which legitimate rights are represented as
(class, operation) pairs attached to an actor. Examples of capabilities include a door key, a
smart card, and a theater ticket.
Appendix B • Glossary 725

Capability Maturity Model (CMM) Framework for assessing the maturity of organizations
characterized by five levels of maturity.
cathedral model A project organization emphasizing planning, system architecture, and
hierarchical control. The chief programmer team is an example of cathedral model. Contrast
with bazaar model.
Centralized Traffic Control (CTC) Procedures and systems enabling dispatchers to monitor
and control train traffic remotely from a central location.
change The adaptation of an aspect of the system, such as the addition or modification of a
requirement, or the substitution of a component for another. See also delta.
change control A process of approving or rejecting a change request to ensure that system
evolution is consistent with project goals.
change control board Team approving change requests in the context of a formal change
process.
change request An unscheduled communication event during which a participant requests a
modified or a new feature in a work product. In configuration management, a formal report
requesting the modification of a configuration item.
change set A set of deltas indicating the differences between two configurations.
chief programmer organization A hierarchical project organization in which the team leader
makes all the critical technical decisions.
clarity See ambiguity.
class An abstraction of a set of objects with the same attributes, operations, relationships, and
semantics. Classes are different than abstract data types in that a class can be defined by
specializing another class. For example, programming languages such as Modula and Ada
provide mechanisms for defining abstract data types; object-oriented languages such as Java,
C++, or Smalltalk provide mechanisms for defining classes.
class diagram UML notation representing the structure of the system in terms of objects,
classes, attributes, operations, and associations. Class diagrams are used to represent object
models during development.
class extender A developer that realizes specializations of the class under consideration.
Although, like class implementors, class extenders may invoke operations provided by the class
of interest, class extenders focus on specialized versions of the same services.
class implementor A developer that realizes the class under consideration. Class
implementors are responsible for designing the internal data structures and implementing the
code for each publication operation.
class user A developer that invokes the operations provided by the class under consideration
during the realization of another class, called the client class.
726 Appendix B • Glossary

client A role representing the person or company paying for the development of the system.
client class In a design pattern, a class that accesses the pattern interface.
client review A scheduled communication event during which a client monitors the status of a
project.
client/server architectural style An architectural style in which user interactions are
managed by simple client programs and functionality is delivered by a central server program.
closed architecture A layered system in which a layer can depend only on layers immediately
below it. Contrast with open architecture.
closed issue An issue that has been resolved.
CM aggregate See configuration management aggregate.
CMM See Capability Maturity Model.
cohesion The strength of dependencies within a subsystem or a class. High coherence is
desirable as it keeps related classes together so they can be modified consistently.
communication An activity during which developers exchange information, either
synchronously or asynchronously, and either spontaneously or according to a schedule.
communication diagram UML notation representing the behavior of the system as a series of
interactions among a group of objects. Each object is depicted as a rectangle in an instance
diagram. Interactions are depicted as lines between objects, annotated with the name of the
message sent. The order of interactions is represented with numbers next to the message names.
See also sequence diagram.
communication event A type of information exchange that has a defined objective and scope.
A communication event can be scheduled or event driven. Examples of communication events
include client reviews, status reviews, and problem reports.
communication mechanism A tool or a procedure that can be used to transmit and receive
information. Communication mechanisms support one or more communication events.
Examples of communication mechanisms include telephone, fax, E-mail, and groupware.
Communication mechanisms can be either synchronous or asynchronous, depending whether or
not the sender and receiver need to be available at the same time.
communication relationship A type of relationship in a use case diagram denoting the flow
of information between an actor and a use case.
completeness The property of a model describing whether or not all relevant phenomena are
modeled. A model is incomplete if one or more relevant phenomena do not have a
corresponding concept in the model.
component A physical and replaceable part of the system that complies to an interface.
Examples of components include class libraries, frameworks, and binary programs.
Appendix B • Glossary 727

component expert A role of the developers responsible for providing detailed knowledge
about using a specific component.
component inspection A testing technique that finds faults in a component through the
manual inspection of the source code.
composition aggregation An aggregation relationship in which the existence of the parts
depends on the whole. Contrast with shared aggregation.
concept An abstraction of a set of phenomena with common properties. For example, this
book, my black watch, and the Valley Fisherman’s Club are phenomena. Textbooks on object-
oriented software engineering, black watches, and fisherman’s clubs are concepts. Contrast with
phenomenon.
configuration A version of a configuration management aggregate.
configuration item A work product that is treated as a single entity for the purpose of
configuration management and that needs to be baselined. See also configuration management
aggregate.
configuration management An activity during which developers monitor and control
changes to the system or its models. Goals of configuration management include saving enough
information so that it is possible to restore the system to a prior version; preventing changes that
are not consistent with project goals; and managing concurrent development paths aimed at
evaluating competing solutions.
configuration management aggregate (CM aggregate) An aggregate of related configura-
tion items.
configuration manager A role of the developers responsible for tracking, baselining, and
archiving work products.
consistency The property of a model that indicates whether or not it contradicts itself. A
model is inconsistent if it provides several incompatible views of the system.
constraint A rule attached to a UML element restricting its semantics. Constraints can be
depicted by a note containing natural language text or an expression in a formal language (e.g.,
OCL).
consultant role Any role that is concerned with providing temporary and specialized support
where project participants lack expertise. Consultant roles include the user, the client, the
technical consultant, and the application domain specialist.
contract A set of constraints on a class or a component allowing the caller and the callee to
share the same assumptions about the class or the component. See also invariant, precondition,
and postcondition.
contract inheritance The propagation of the contract of the superclass to its subclasses.
control flow The sequence of execution of operations in the system. Contrast with data flow.
728 Appendix B • Glossary

control node In an activity diagram, nodes that coordinate the control flow in a diagram. See
decision, fork node, join node.
control object An object that represents a task performed by the user and supported by the
system.
controller In the Model/View/Controller architectural style, a type of subsystem or object
that manages the sequence of interactions with the user.
correction A change to a component for the purpose of repairing a fault.
correctness The property of a model that indicates if it accurately represents the system that
the client needs and that the developers intend to build.
cost criterion A design goal related to the cost of developing, operating, or installing the
system.
coupling The strength of the dependencies between two subsystems or two classes. Low
coupling results in subsystems that can be modified with minimal impact on other subsystems.
CRC card An index card representing a class. The name of the Class is depicted on the top,
its Responsibilities in the left column, and the names of the classes (called Collaborators) it
needs to accomplish its responsibilities are depicted in the right column.
criterion A measure of goodness used when evaluating alternatives for an issue.
critical path The longest path in the task model. Delays on critical path tasks directly result in
a delay in the overall schedule.
cross-development A process group that includes processes that occur throughout the project
and that ensure the completion and quality of project functions. Examples of cross-development
processes include validation and verification, configuration management, documentation, and
training. Also called integral processes.
cross-functional role Any role concerned with coordinating the work of more than one team.
Examples of cross-functional roles include the configuration manager, the architecture liaison,
the tester, and the document editor.
cross-functional team A team responsible for supporting a subsystem team during a cross-
functional activity such as configuration management, integration, or testing. Contrast with
subsystem team.
CTC See centralized traffic control.
data flow The sequence in which data is transferred, used, and transformed in the system.
Contrast with control flow.
data type An abstraction of a set of values in the context of a programming language. For
example, int is the Java data type that abstracts all the integer values.
Appendix B • Glossary 729

debugging A fault detection technique that attempts to find a fault from an unplanned failure
by stepping through successive states of the system.
decision In the context of activity diagrams, a branch in the control flow of an activity
diagram. A decision denotes alternative transitions based on a condition. In the context of issue
modeling, an issue resolution.
Decision Representation Language (DRL) An issue model extending IBIS to represent the
qualitative elements of decision making.
defect See fault.
delegation A mechanism for code reuse in which an operation merely resends (i.e., delegates)
a message to another class to accomplish the desired behavior.
deliverable A work product destined for the client.
delta A set of differences between two successive versions. Also called change.
dependability The property of a computer system that describes how reliably it performs.
dependability criterion A design goal related to minimizing the number of system crashes
and the consequences of a system crash. Examples of dependability criteria include robustness,
reliability, availability, fault tolerance, security, and safety.
deployment diagram A UML diagram representing run-time components and their
assignments to hardware nodes.
derived class See subclass.
design goal A quality that the system should optimize. Design goals are often inferred from
nonfunctional requirements and are used to guide design decisions. Examples of design goals
include usability, reliability, security, and safety.
design object See solution object.
design pattern A template solution that developers have refined over time to solve a range of
recurring problems. A design pattern includes a name, a problem description, a solution, and a
set of consequences. Specific design patterns are described in Appendix A.
designer See object designer.
developer Any role that is concerned with specifying, designing, and constructing
subsystems. Examples of development roles include the analyst, the system architect, the object
designer, and the implementor.
different time, different place groupware See groupware.
document editor A role of the person who integrates the documents.
domain object See application object.
DRL See Decision Representation Language.
730 Appendix B • Glossary

dynamic access control An access control policy that can be set at runtime. Contrast with
static access control.
dynamic model Describes the components of the system that have interesting behavior. In this
book, we represent the dynamic model with state machine diagrams, sequence diagrams, and
activity diagrams.
egoless programming A project organization in which responsibilities are assigned to a team
instead of individuals. Roles within a team are interchangeable.
encryption A translation of a message, called plaintext, into an encrypted message, called
ciphertext, such that it cannot be understood by unauthorized persons.
end user A role of the people who will use the delivered system.
end user criterion A design goal related to user-visible attributes of the system not yet
covered under a dependability or performance criterion.
enterprise application framework An application-specific framework used for enterprise
business activities.
entity-centered software life cycle model A software life cycle model that primarily
represents the work products produced during development. Contrast with activity-centered
software life cycle model.
entity object An object that represents persistent or long-lived information tracked by the
system.
entry condition A condition that needs to be satisfied before a use case is initiated.
environment The elements that are present at the beginning of a project.
erroneous state State of the system such that further processing will lead to a failure.
error See erroneous state.
evaluation scenario Scenario that describes an instance of a user task against which the
system is to be evaluated.
event A relevant occurrence in the system. An event is an instance of an event class. Examples
of events include a stimulus from an actor, a time-out, or the sending of a message between two
objects.
event class An abstraction representing a set of events for which the system has a common
response.
event-driven control A control flow paradigm in which a main loop waits for an event and
dispatches it to the appropriate object.
exception An unexpected event that occurs during the execution of the system.
exception handling A mechanism by which a system treats an exception.
exit condition A condition that are satisfied after the completion of a use case.
Appendix B • Glossary 731

extend relationship A type of relationship in a use case diagram denoting that one use case
extends the flow of events of another one. Extends relationships are typically used for modeling
exceptional behavior, such as exception handling and help functionality.
extender class The class that specializes an implementor class to provide a different
implementation or an extended behavior of the design pattern.
extensibility The quality of a system indicating how easily the system can be changed to
accommodate new functionality.
external behavior The behavior of the system from the user’s point of view. The use case
model describes the external behavior of the system.
Extreme Programming (XP) A methodology targeted for small teams of developers who
need to develop software quickly in a changing environment. Extreme Programming aims at
making the design of the system as explicit as possible in the source code, hence reducing the
need for documentation and the risk of inconsistencies among different documents.
facilitator A meeting management role responsible for organizing and executing a meeting.
The primary facilitator writes the meeting agenda, notifies the meeting participants, and ensures
during the meeting that the agenda is followed. A secondary facilitator supports the primary
facilitator’s role in keeping the meeting on track.
failure Deviation of the observed behavior from the specified behavior.
falsification The process of explicitly trying to demonstrate that a model has faults (e.g., the
model omits relevant details or represents relevant details incorrectly). Prototype and testing are
examples of falsification.
fault The mechanical or algorithmic cause of an error. Also called a bug or a defect.
fault avoidance A method aimed at preventing the insertion of faults while building the
system. Examples of fault avoidance techniques include development methodologies,
configuration management, verification, and reviews.
fault detection A method aimed at discovering faults in the running system. Examples of
fault detection techniques include debugging and testing.
fault tolerance A method aimed at constructing systems that do not fail in the presence of
faults. The ability to withstand faults without failing.
field testing See pilot testing.
firewall A packet filter that allows or denies network packets to go through based on their
source and destination.
flow of events A sequence of events in a use case describing the interactions between the actor
and the system.
foreign key In a database management system, an attribute (or a set of attributes) that
references the primary key of another table.
732 Appendix B • Glossary

fork node In an activity diagram, a control node that represents the spilling of the control flow
into multiple threads.
forward engineering The process of applying a transformation to a set of model elements,
resulting in a set of corresponding source code statements, such as a class declaration, a Java
expression, or a database schema. Contrast with reverse engineering.
four-tier architectural style An architectural style that organizes the system into four layers:
presentation client, presentation server, application logic, and storage.
framework A set of classes providing a general solution that can be refined to provide an
application or a subsystem.
functional model Describes the functionality of the system from the user’s point of view. In
this book, we represent the functional model with use cases.
functional requirement An area of functionality the system must support. The functional
requirements describe the interactions between the actors and the system independent of the
realization of the system.
functional testing A system testing activity during which developers find differences between
the observed functionality and the use case model.
Gantt chart A notation for representing the schedule of a software project along the time axis.
A Gantt chart is a bar graph in which the horizontal axis represents time and the vertical axis
represents the different tasks to be done. Tasks are represented as bars whose lengths correspond
to the planned duration of the task.
generalization A modeling activity that results in identifying abstract concepts from lower-
level ones.
generalization-specialization relationship See inheritance relationship.
global access table A representation of access rights in which every legitimate right is
represented as an (actor, class, operation) tuple.
goal A high-level principle used to guide the project. Goals define the important attributes of
the system: for example, safety in a transportation vehicle, low cost in shrinkwrapped software.
goodness measure A qualitative or quantitative criterion used to assess a proposal. See also
criterion.
greenfield engineering A development project that starts from scratch. See also re-
engineering, interface engineering.
groupware Any software tool supporting the exchange of information among a set of
participants. Same time, different place groupware supports synchronous exchanges. Different
time, different place groupware supports asynchronous exchanges.
hallway conversation A synchronous mechanism of communication during which
participants meet face to face accidentally.
Appendix B • Glossary 733

hierarchical decomposition A subsystem decomposition that yields an ordered set of layers.

See also layer.
hierarchical organization An organization in which reporting and decision-making
structures are hierarchical; that is, decisions are made at the root of the organization and
communicated down to the team leaders and the team members. See also cathedral model.
hook method A method provided by a framework class that is meant to be overwritten in a
subclass to specialize the framework.
horizontal prototype A prototype that partially implements a broad range of functionality, for
example, only the interface objects for a number of use cases.
ideal week In Extreme Programming, a week in which all work time is dedicated to the
implementation of a user story. See also project velocity.
imperative language See procedural language.
implementation An activity during which developers translate the object model into code.
implementation decision A design decision that does not affect the public interface of a class
or a subsystem.
implementation domain See solution domain.
implementation inheritance Inheritance used solely as a mechanism for reuse, and violating
Liskov’s Substitution Principle.
implementation requirement A constraint on the implementation of the system, including
the use of specific tools, programming languages, or hardware platforms.
implementor See class implementor.
implementor class A class that provides the lower-level behavior of the pattern. In many
patterns, a number of collaborating implementor classes are needed to realize the pattern
behavior.
include relationship A type of relationship in a use case diagram denoting that a use case
invokes another use case. A use case inclusion is analogous to a method invocation.
infrastructure framework A framework used to realize an infrastructure subsystem, such as
a user interface or a storage subsystem.
inheritance A reusability technique in which a child class inherits all the attributes and
operations of a parent class. Inheritance is the mechanism used to realize an inheritance
relationship.
inheritance relationship The relationship between a general class and a more specialized
class. The specialized class adds semantics and functionality to the general class. The
specialized class is called the subclass and the general class is called the superclass.
734 Appendix B • Glossary

inspection A scheduled communication event during which developers formally peer review a
work product with respect to a list of pre-defined criteria. See also walkthrough.
installation An activity during which the system is installed and tested in its operating
environment. Installation can also include the training of users.
installation testing A system testing activity during which developers and the client test the
system in the operational environment.
instance Member of a specific data type. For example, 1291 is an instance of the data type
int. 3.14 is an instance of the data type float.
integral processes See cross-development.
integration testing A testing activity during which developers find faults by combining a
small number of subsystems or objects.
interaction diagram UML notation for representing the system’s behavior in terms of
interactions among a set of objects. Interaction diagrams are used to identify objects in the
application and implementation domains. Interaction diagrams is a general term for referring to
communication diagrams and sequence diagrams.
interface engineering A development project in which the interface of a system is redesigned
and reimplemented, and the core functionality is left untouched. See also greenfield engineering,
reengineering.
interface inheritance See specification inheritance.
interface requirement Constraint imposed by external systems, including legacy systems and
interchange formats.
internal transition A transition that does not leave the state. Internal transitions are triggered
by events and can have associated actions. However, firing an internal transition does not result
in executing any exit or entry actions. See also action, transition.
internal work product A work product destined only for the internal consumption of the
project.
invariant A predicate that is always true for all instances of a class.
IBIS See Issue-based information system.
issue A critical problem that has no clear solution.
Issue-Based Information System (IBIS) An issue model proposed by Kunz Rittel composed
of three types of nodes: issue, position, and argument.
issue-based development See issue-based life cycle model.
issue-based life cycle model An entity-based software life cycle model in which an issue
model is used to monitor and control progress in the project.
Appendix B • Glossary 735

issue model A model representing the rationale of one or more decisions as a graph. Nodes of
an issue model typically includes issues, proposals, arguments, criteria, and resolutions.
issue resolution An unscheduled communication event during which participants reach a
consensus or a decision on an issue.
join node In an activity diagram, a control node that denotes the synchronization of multiple
threads of control into a single thread.
Joint Application Design (JAD) A requirements elicitation technique involving the
collaboration of clients, users, and developers in constructing a requirements specification
through a week-long working meeting.
Key Process Area (KPA) A set of activities that achieve a goal considered important for
attaining a given level of process maturity. Examples of KPA include configuration
management, requirements change management, and risk management.
kick-off meeting A meeting including all project participants that marks the end of the project
initiation phase and the beginning of steady state.
knowledge acquisition The activity of collecting data, organizing it into information, and
formalizing it into knowledge.
KPA See key process area.
layer A subsystem in a hierarchical decomposition. A layer can depend only on lower-level
layers and has no knowledge of the layers above it.
legal requirement Constraint concerned with licensing, regulation, and certification issues.
An example of a legal requirement is that software developed for the U.S. federal government
must comply with Section 508 of the Rehabilitation Act of 1973, which requires that
government information systems be accessible to people with disabilities.
liaison A communication role responsible for the information flow between two teams. For
example, an architecture liaison represents a subsystem team at the architecture team.
life cycle See software life cycle.
link An instance of an association. A link connects two objects.
Liskov Substitution Principle Formal definition for specification inheritance. It essentially
states that, if a client code uses the methods provided by a superclass, then developers should be
able to add new subclasses without having to change the client code.
local king client A client who can answer developer questions and make decisions without
having to ask anybody else. The local king has deep knowledge of the application domain and is
usually collocated with the project.
maintainability The ability to change the system to deal with new technology or to fix
defects.
736 Appendix B • Glossary

maintenance criterion A design goal related to the difficulty of changing or upgrading the
system after it has been delivered.
management role Any role that is concerned with planning, monitoring, and controlling the
project. Examples of management roles include project manager and team leader. See also
project management.
many-to-many association An association with 0..n or 1..n multiplicity on both ends.
mapping A mathematical correspondence that assigns an element (or a set of elements) of one
model to each element of another model.
master directory A library of promotions.
meeting A synchronous mechanism of communication during which participants present,
discuss, negotiate, and resolve issues, either face-to-face or via telephone or videoconferencing.
meeting agenda Document used to prepare and conduct a meeting. A meeting agenda usually
consists of at least three sections: a header identifying the planned meeting location, time, and
participants; a list of items participants will report on; and a list of issues to be discussed and
resolved.
meeting minutes A document used to record the content and decisions of a meeting. Meeting
minutes usually consist of three sections that correspond to the sections of the agenda, as well as
action items and decision items.
message A mechanism by which a sending object requests the execution of an operation in the
receiving object. A message is composed of a name and a number of arguments. The receiving
object matches the name of the message to one or more operations and passes the arguments to
the operation. The message send ends when the results of the operation are returned to the
sending object.
method In the context of development, a repeatable technique for solving a specific problem.
For example, a recipe is a method for cooking a specific dish. In the context of a class or an
object, the implementation of an operation. For example, SetTime(t) is a method of the class
Watch.

methodology A collection of methods for solving a class of problems. A seafood cookbook is

a methodology for preparing seafood. This book describes a methodology for dealing with
complex and changing systems.
middleware framework A framework used to integrate distributed applications and
components.
minute taker A meeting role responsible for recording a meeting, in particular, the resolutions
that participants have agreed on and their implementation in terms of action items.
model An abstraction of a system aimed at simplifying the reasoning about the system by
omitting irrelevant details. For example, if the system of interest is a ticket distributor for a train,
Appendix B • Glossary 737

blue prints for the ticket distributor, schematics of its electrical wiring, and object models of its
software are models of the ticket distributor.
model object See entity object model/view/controller architectural style.
model transformation A transformation that is applied to an object model and results in
another object model. The purpose of object model transformation is to simplify or optimize the
original model, bringing it closer to a system that complies with all requirements in the
specification.
Model/View/Controller (MVC) architectural style A three-tier architectural style in which
domain knowledge is maintained by model objects, displayed by view objects, and manipulated
by control objects. In this book, model objects are called entity objects and view objects are
called boundary objects.
modeling An activity during which participants construct an abstraction of a system by
focusing on interesting aspects and omitting irrelevant details. What is interesting or irrelevant
depends on the task in which the model is used. See also abstraction.
modifiability The quality of a system describing how easily existing models can be modified.
multiplicity A set of integers attached to an association end indicating the number of links that
can legitimately originate from an instance of the class at the association end. For example, an
association denoting that a Car has four Wheels has a multiplicity of 1 on the Car end and 4 on
the Wheel end.
MVC See Model/View/Controller.
name In a class, a mandatory string identifying the class within a subsystem. The class name
is unique within the subsystem. In an association, an optional string describing the association
between two classes. In an attribute, a mandatory string identifying the attribute within the class.
The attribute name is unique within the class.
navigation Direction in which an association can be followed.
nested state A state within a nested state machine.
nested state machine A state machine that models the behavior of a single state as a set of
nested states, internal transitions, and actions.
NFR Framework A method for tracking the relevant nonfunctional requirements for each
decision, evaluated alternative, and interaction between nonfunctional requirements.
nonfunctional requirement A user-visible constraint on the system. Nonfunctional
requirements describe user-visible aspects of the system that are not directly related with the
functionality of the system. See also design goal.
notation A graphical or textual set of rules for representing a model. For example, the Roman
alphabet is a notation for representing words; UML is a graphical notation for representing
system models.
738 Appendix B • Glossary

note A comment attached to a UML diagram.

object An instance of a class. An object has an identity and stores attribute values.
Object Constraint Language (OCL) A formal language defined as part of the UML used for
expressing constraints.
object design An activity during which developers define custom objects to bridge the gap
between the analysis model and the hardware/software platform. This includes specifying object
and subsystem interfaces, selecting off-the-shelf components, restructuring the object model to
attain design goals, and optimizing the object model for performance. Object design results in
the object design model.
Object Design Document (ODD) A document describing the object design model. The
object design model is often generated from comments embedded in the source code.
object design model A detailed object model representing the application and solution objects
that make up the system. The object design model includes detailed class specifications,
contracts, types, signatures, and visibilities for all public operations.
object designer A role of developers who refine and specify the interface of classes during
object design.
object diagram A class diagram that includes only instances.
object model Describes the structure of a system in terms of objects, attributes, associations,
and operations. During requirements and analysis, the object model starts as the analysis object
model and describes the application concepts relevant to the system. During system design, the
object model is refined into the system design object model and includes descriptions of the
subsystem interfaces. During object design, the object model is refined into the object design
model and includes detailed descriptions of solution objects.
object-oriented analysis An activity concerned with modeling the application domain with
objects.
object-oriented design An activity concerned with modeling the solution domain with
objects.
OCL See Object Constraint Language.
OCL bag An OCL collection representing an unordered multi-set (i.e., a set that can contain
the same element several times). OCL bags are used to represent the result of navigating a series
of associations.
OCL collection An OCL abstract type representing a group of objects.
OCL sequence An OCL collection representing an ordered list. OCL sequences are used to
represent the result of navigating a single ordered association.
OCL set An OCL collection representing a mathematical set. OCL sets are used to represent
the result of navigating a single association.
Appendix B • Glossary 739

ODD See Object Design Document.

one-to-many association An association that has a multiplicity of 1 on one end and a 0..n or
a 1..n multiplicity on the other end.
one-to-one association An association with multiplicity of 1 on each end.
open architecture A layered architecture in which a layer may make use of services in any
layer below it (as opposed to only the layer immediately below it). Contrast with closed
architecture.
open issue An issue that has not yet been resolved.
operation An atomic piece of behavior that is provided by a class. A calling object triggers the
execution of an operation by sending a message to the object on which the operation should be
executed.
operations requirement Constraint on the administration and management of the system in
the operational setting.
organization A set of teams, roles, communication paths, and reporting structure tailored to a
specific project (project organization) or a class of projects (division or corporate organization).
package A UML grouping concept denoting that a set of objects or classes are related.
Packages are used in use case and class diagrams to deal with the complexity associated with
large numbers of use cases or classes.
packaging requirement Constraint on the actual delivery of the system (e.g., constraint on
the installation media for setting up the software).
participant Any person involved with a software development project.
participating actor An actor interacting with a use case.
participating actor instance An actor instance interacting with a scenario.
participating object An analysis object that is involved in a given use case.
partition A subsystem in a peer-to-peer architectural style.
pattern expert A role of the developers responsible for providing detailed knowledge about
specific patterns.
pattern interface That part of the design pattern visible to the client class. Often, the pattern
interface is realized by an abstract class or an interface.
peer-based communication structure A communication structure in which developers from
different teams communicate directly.
peer review A scheduled communication event during which team members identify defects
and find solutions in preliminary work products. See also inspection, walkthrough.
peer-to-peer architectural style A generalization of the client/server architectural style in
which subsystems can act either as clients or servers.
740 Appendix B • Glossary

performance Any quantifiable attribute of the system, such as response time, throughput,
availability, and accuracy.
performance criterion A design goal related to the speed or space attributes of a system.
Examples of performance criteria include response time, throughput, and memory space.
performance testing A system testing activity during which developers find differences
between nonfunctional requirements and system performance.
persistent data Data that outlive a single execution of the system.
PERT chart A notation representing a schedule as an acyclic graph of tasks.
phase Often used as a synonym for activity or process.
phenomenon An object of a reality as perceived by the modeler. Modeling consists of
selecting the phenomena of a reality that are of interest, identifying their common properties,
and abstracting them into concepts. Contrast with concept.
pilot testing A testing activity during which a selected set of users exercises the system in the
deployment environment.
pipe and filter architectural style An architectural style in which subsystems sequentially
process data from a set of inputs and send their results to other subsystems via a set of outputs.
Associations between subsystems are called pipes. Subsystems are called filters. Filters do not
depend on each other and can thus be rearranged in different orders and configurations.
portability The ease with which a system or component can be transferred from one hardware
or software environment to another.
postmortem review A scheduled communication event during which participants capture the
lessons learned during the project.
postcondition A predicate that must be true after an operation is invoked.
precondition A predicate that must be true before an operation is invoked.
primary facilitator See facilitator.
primary key In a database management system, a set of attributes whose values uniquely
identify the data records in a table.
problem definition A scheduled communication event during which the client and manager
define the scope of the system.
problem domain See application domain.
problem inspection A scheduled communication event during which developers gather
information from the problem statement, the client, and the user about their needs and the
application domain.
problem presentation A scheduled communication event during which the client and the
manager communicate the high-level requirements of the system to the project participants.
Appendix B • Glossary 741

problem solving A search activity that includes the generation and evaluation of alternatives
addressing a given problem, often by trial and error.
problem statement A document cooperatively written by the client and project management
that briefly describes the scope of the system, including high-level requirements, target
environment, deliverables, and acceptance criteria. See also Project Agreement.
procedural language A programming language in which the developer specifies an explicit
sequence of steps to produce a result. Also known as an imperative language.
procedure-driven control A control flow paradigm in which operations wait for input. The
sequencing of operations is otherwise done explicitly through sending messages.
process A set of activities that is performed toward a specific purpose. Examples of processes
include requirements elicitation, analysis, project management, and testing. A process is
synonymous with a high-level activity. See also activity.
process group A group of related processes. Examples of process groups include
management, pre-development, development, and post-development.
process management In configuration management, a set of policies dictating how versions
should be created and documented, including policies for notifying developers when new
versions are created or when a build fails.
project agreement A document that formally defines the scope, duration, cost, and
deliverables of a project. Requirements are often categorized into core requirements (which the
system must meet when delivered), desirable requirements (which must be satisfied eventually),
and optional requirements (which may or may not be required in the future). The Project
Agreement subsumes the Problem Statement.
project-based organization A corporate organization in which work is divided according to
projects; that is each participant works on exactly one project at any one time.
project conception phase The first phase of a project during which the idea for the project is
born. In a software project this is usually a new requirement triggered by the need of an existing
market or a new technology.
project definition phase The phase of a project, during which a possible client, the project
manager, and the software architect are involved in agreeing on an initial problem statement,
schedule, and software architecture.
project initiation In IEEE 1074, a project management activity during which the project
scope and resources are defined. In this book, project initiation is called project start phase.
project management An activity during which managers plan, budget, monitor, and control
the development process. Project management ensures that constraints and project goals are met.
project member See participant.
742 Appendix B • Glossary

project review A scheduled communication event during which a project manager monitors
the status of a project.
project start phase A project phase that occurs after the client and the project manager
commit to the project. During the start phase, the project manager sets up the project
infrastructure, hires participants, organizes them in teams, defines the major milestones, and
kicks off the project.
project steady state A management activity during which management monitors and controls
the progress of the project.
project termination A management activity during which the project is concluded: the
system is delivered and accepted by the client.
project velocity In Extreme Programming, a factor indicating how many ideal weeks can be
accomplished during a fixed amount of time.
promotion A version that has been made available internally to other developers in the
project. See also release.
proposal A possible resolution of an issue.
prototyping A process of designing and realizing a simplified version of the system for
evaluation with the user or the manager. For example, a usability prototype evaluates the
usability of different interfaces. A performance prototype assesses the performance of different
alternatives.
proxy client A participant who stands in for the real client. Proxy clients have sufficient
knowledge of the application domain to answer clarification questions from the developers, but
do not have sufficient power to make major decisions.
pseudo client A member of the development organization who acts as a client because the
system is targeted at a new market segment, as opposed to a single individual or company.
Pseudo clients can make decisions within a short time and can collaborate well with the
development organization, but have a limited knowledge of the application domain.
pseudo requirement A nonfunctional requirement that can be in the implementation,
interface, operation, packaging, or legal domains.
QOC See Questions, Options, and Criteria.
qualification A technique for reducing the multiplicity of associations by replacing many-to-
many or one-to-many associations with qualified associations.
qualified association An association in which one end is indexed by an attribute. For
example, the association between Directory and File is a qualified association indexed by a
filename on the Directory end.
qualifier Attribute used to index the qualified end of a qualified association.
Appendix B • Glossary 743

questionnaire A synchronous mechanism of communication during which information is

elicited from a participant with a structured set of questions.
Questions, Options, and Criteria (QOC) An issue model, proposed by McLean et al.,
extending IBIS to represent criterion and assessment information.
RAD See Requirements Analysis Document.
rationale The justification of decisions. For example, selecting myDBMS as a database
management system is a system design decision. Stating that myDBMS is reliable and responsive
enough to attain the project’s goals is part of the rationale for this design decision. Also called
design rationale.
rationale editor A role responsible for collecting and organizing rationale information.
rationale management An activity during which developers create, capture, update, and
access rationale information.
rationale model See issue model.
readability The quality of a system describing how easy it can be understood from its source
code.
realizability The property of a model indicating whether the system it represents can be
realized.
reengineering A development project in which a system and its accompanying business
processes are redesigned and reimplemented. See also greenfield engineering, interface
engineering.
refactoring Transformation of the source code that improves its readability or modifiability
without changing the behavior of the system. Refactoring aims at improving the design of a
working system by focusing on a specific field or method of a class.
refined class See subclass.
regression testing A testing activity during which integration tests are rerun to ensure that the
system does not regress after a change; that is, the system passes all the integration tests it did
before the change.
release In communication, a scheduled communication event during which a developer makes
available to the rest of the project a new version of a work product. See also promotion. In
configuration management, a version that has been made available externally, that is, to the
client or the users.
reliability Ability of a system or component to perform its required functions under stated
conditions for a specified period of time. Reliability requirements include, for example, an
acceptable mean time to failure, the ability to detect specified faults, or to withstand specified
security attacks. Reliability includes dependability, robustness, and safety.
reporting structure The structure representing the chain of control and status reporting.
744 Appendix B • Glossary

repository In a repository architectural style, the central subsystem that manages persistent
data. In configuration management, a library of releases.
repository architectural style An architectural style in which persistent data is managed and
stored by a single subsystem. Peripheral subsystems are relatively independent and interact only
through the central subsystem.
request for change See change request.
request for clarification An unscheduled communication event during which a participant
requests more information.
requirement A function that the system must have (a functional requirement) or a user-visible
constraint on the system (nonfunctional requirement).
Requirements Analysis Document (RAD) The document describing the analysis model.
requirements elicitation An activity during which project participants define the purpose of
the system. Requirements elicitation produces the functional model.
requirements engineering An activity that includes requirements elicitation and analysis.
requirements specification A complete and precise description of the system from the user’s
point of view. A requirements specification, unlike the analysis model, is understandable to the
user. In object-oriented software engineering, the requirements specification includes use cases
and scenarios.
requirements testing See functional testing.
response time An attribute of the system denoting how quickly it can react to a user input.
resolution The proposal selected by participants to close an issue.
resources Assets that are used to accomplish work, including time, equipment, and labor.
reverse engineering The process of applying a transformation to a set of source code
elements, resulting in a set of model elements. The purpose of reverse engineering is to recreate
the model for an existing system, either because the model was lost, never created, or because it
became out of sync with the source code. Contrast with forward engineering.
reviewer A role of people validating work products for quality criteria such as completeness,
correctness, consistency, and clarity.
risk An area of uncertainty that can lead to a deviation in the project plan (e.g., late delivery,
requirements not met, cost above budget), including the failure of the project.
risk-based development A software life cycle driven by the identification and resolution of
risks. See also Spiral model.
risk management A management method for identifying and addressing areas of uncertainty
before they negatively affect the schedule of the project or the quality of the system.
Appendix B • Glossary 745

robustness The degree to which a system or component can function correctly in the presence
of invalid inputs or stressful environment conditions.
role In the context of an organization, a set of responsibilities in the project assigned to a
person or a team. A person can fill one or more roles. Examples of roles include analyst, system
architect, tester, developer, manager, reviewer. In the context of an association end, a string
indicating the role of the class at the association end with respect to the association.
round-trip engineering A model maintenance activity that combines forward and reverse
engineering. Changes to the implementation model are propagated to the analysis and design
models through reverse engineering. Changes to the analysis and design models are propagated
to the implementation model through forward engineering.
Royce’s methodology An iterative risk-driven methodology proposed by Royce based on the
Unified Process life cycle.
safety A measure of the absence of catastrophic consequences to the environment.
same time, different place groupware See groupware
sandwich testing An integration testing strategy that combines top-down and bottom-up
testing.
schedule A map of a task model on a time line. A schedule represents work in terms of
calendar time.
schema In a database management system, a meta-model for the data.
scenario Instance of a use case. A scenario represents a concrete sequence of interactions
between one or more actors and the system.
SCMP See Software Configuration Management Plan.
SDD See System Design Document.
secondary facilitator See facilitator.
security Property of a system indicating its ability to protect the resources against
unauthorized use, whether malicious or accidental.
sequence diagram UML notation representing the behavior of the system as a series of
interactions among a group of objects. Each object is depicted as a column in the diagram. Each
interaction is depicted as an arrow between two columns. Sequence diagrams are used during
analysis to identify missing objects, attributes, or relationships. Sequence diagrams are used
during object design to refine the specification of classes. See also communication diagram.
service A set of related operations offered by a subsystem.
shared aggregation An aggregation relationship in which the whole and the part can exist
independently. Contrast with composition aggregation.
746 Appendix B • Glossary

signature Given an operation, the tuple made up of the types of its parameters and the type of
the return value. Operation signatures are specified during object design.
slack time For a task, the maximum amount of time a task can be delayed without affecting
the overall project schedule.
software architecture See system design model.
Software Configuration Management Plan (SCMP) A document defining the procedures
and conventions associated with the configuration management of a project. These include
identifying configuration items, accounting for their status, approving change requests, and
auditing.
software library A store of versions with facilities to track the status of changes.
software life cycle All activities and work products necessary for the development of a
software system.
software life cycle model An abstraction representing the development of software for the
purpose of understanding, monitoring, or controlling it. Examples of software life cycle models
include the waterfall model, the V-model, Boehm’s spiral model, the Unified Process, and the
issue-based life cycle model.
Software Project Management Plan (SPMP) The controlling document of a software
project. The SPMP defines the activities, work products, milestones, and resources allocated to
the project. Also defined in the SPMP are the management procedures and conventions
applicable to the project such as status reporting, risk management, and contingency
management.
software reliability The property of a software system indicating the probability that the
software will not cause a failure of the system for a specified duration.
solution domain The space of all possible systems. The solution domain is the focus of the
system design, object design, and implementation activities. Contrast with application domain.
solution domain specialist A consultant role responsible for providing knowledge about
solutions to implement the system. This can include the development method, the process,
implementation technology, or the development environment.
solution object An object in the system design or object design model that represents a
solution domain concept. Also called design object.
specialization A modeling activity that results in identifying more specific concepts from a
high-level one.
specification inheritance Inheritance used as a means of subtyping.
spiral model An iterative and incremental software life cycle model centered around risk
management.
SPMP See Software Project Management Plan.
Appendix B • Glossary 747

state A condition that is satisfied by the attribute values of an object or a subsystem.

state machine diagram UML notation representing the behavior of an individual object as a
number of states and transitions between these states. A state represents a particular set of values
for an object. Given a state, a transition represents a future state the object can move to and the
conditions associated with the change of state. State machine diagrams are used during analysis
to describe objects with state-dependent behavior.

static access control An access control policy that can be set only at compile time. Contrast
with dynamic access control.

status accounting In configuration management, the tracking of change requests, change

approval, and rationale for change.

status meeting A scheduled communication event during which team leaders monitor the
status of their team.

status review See status meeting.

stereotype An extension mechanism to classify model elements in UML. A stereotype is

represented by a string enclosed by guillemets (e.g., «control») and attached to the model
element to which it applies, such as a class or an association. Formally, attaching a stereotype to
a model element is semantically equivalent to creating a new class in the UML meta-model (i.e.,
the model that represents the constructs of UML). For example, the stereotype «control»
attached to an object denotes a control object.

stimulus A message sent to an object or to the system by an actor or another object; it usually
results in the invocation of an operation. Examples of stimuli include clicking on a user interface
button, selecting a menu item, typing a command, or sending a network packet.

strict inheritance An inheritance relationship that complies with the Liskov Substitution
Principle.

structural testing A testing activity that finds differences between the system and the system
design model.

structured interview An interview, following a questionnaire, whose purpose is to clarify

incomplete or ambiguous answers.

subclass The specialized class in a generalization relationship. See also generalization.

subsystem In general, a smaller, simpler part of a larger system; in system design, a well-
defined software component that provides a number of services to other subsystems. Examples
of subsystems include storage subsystems (managing persistent data), user interface subsystems
(managing the interaction with the user), networking subsystems (managing the communication
with other subsystems over a network).
748 Appendix B • Glossary

subsystem decomposition The division of the system into subsystems. Each subsystem is
described in terms of its services during system design and its API during object design.
Subsystem decomposition is part of the system design model.
subsystem interface The set of operations of a subsystem that is publicly available to other
subsystems.
subsystem team A team responsible for developing a subsystem. Contrast with cross-
functional team.
superclass The general class in a generalization relationship. See also generalization.
supportability The ease of changing the system after deployment.
swimlane A UML grouping concept denoting activities that are carried out by the same object
or set of objects.
synchronicity See communication mechanism, groupware.
system An organized set of communicating parts designed for a specific purpose. For
example, a car, composed of four wheels, a chassis, a body, and an engine, is designed to
transport people. A watch, composed of a battery, a circuit, wheels, and hands, is designed to
measure time.
system architect See architect.
system design An activity during which developers define the system design model, including
the design goals of the project, and decompose the system into smaller subsystems that can be
realized by individual teams. System design also leads to the selection of the hardware/software
platform, persistent data management strategy, global control flow, access control policy, and
boundary condition strategies.
System Design Document (SDD) A document describing the system design model.
system design model A high-level description of the system, including design goals,
subsystem decomposition, hardware/software platform, persistent storage strategy, global
control flow, access control policy, and boundary condition strategies. The system design model
represents the strategic decisions made by the architecture team that allow subsystem teams to
work concurrently and cooperate effectively.
system model The set of all models built during development to reason about the system. The
system model includes the analysis model, the system design model, the object design model,
and the source code.
system testing A testing activity during which developers test all the subsystems as a single
system. System testing includes functional testing, performance testing, acceptance testing, and
installation testing.
task An atomic unit of work that can be managed. Tasks consume resources and produce one
or more work products.
Appendix B • Glossary 749

task model A model of work for a project represented as tasks and their interdependencies.
team A set of participants who work on a common problem in a project.
team-based organization An organization in which project participants are assigned to teams
that are responsible for specific subsystems or project functions. Participants in a team-based
organization are allocated full-time to the project.
team leader A management role responsible for planning, monitoring, and controlling a
single team.
technical consultant A consultant role that provides solution domain expertise to the project.
technical writer See document editor.
test case A set of inputs and expected results that exercises a component with the purpose of
causing failures.
test driver A partial implementation of a component that exercises the tested component. Test
drivers are used during unit and integration testing.
Test Manual A document describing the test cases used to test the system, along with their
results.
test planning An activity that allocates resources for tests and schedules testing activities.
test stub A partial implementation of a component on which the tested component depends.
Test stubs are used to isolate components during unit and integration testing and allow
components to be tested even when their dependent components have not yet been implemented.
tester A role concerned with the planning, design, execution, and analysis of tests.
testing An activity during which developers find differences between the system and its
models by executing the system (or parts of it) with sample input data sets. Testing includes unit
testing, integration testing, system testing, and usability testing.
thread A control flow paradigm in which the system creates an arbitrary number of threads to
handle an arbitrary number of input channels.
three-tier architectural style An architectural style that organizes the system into an
interface layer, an application logic layer, and a storage layer.
throughput An attribute of the system denoting how much work it can accomplish within a
specified amount of time.
timekeeper A meeting role responsible for tracking time so that the primary facilitator can
accelerate the resolution of an issue (or table it) if necessary.
top-down testing An integration testing strategy in which components are incrementally
integrated together starting with the highest level components. Top down testing does not require
any test drivers. Contrast with bottom-up testing, sandwich testing.
750 Appendix B • Glossary

top-level design Initial subsystem decomposition used for team organization and initial
planning.
traceability The property of a model describing whether a model element can be traced to the
original requirement or rationale that motivated its existence.
training scenario Tutorial scenario used for introducing new users to the system. These are
step-by-step instructions designed to hand-hold the user through common tasks.
transformation A mapping from one model to another that aims at improving one aspect of
the transformed model (e.g., its modularity) while preserving all of its other properties (e.g., its
functionality). A transformation is usually localized, affects a small number of classes,
attributes, and operations, and is executed in a series of small steps.
transition A possible change of state associated triggered by events, conditions, or time.
tuple An ordered set of values. Common uses for the tuple are representing a set of value
attributes in a relational database and representing an access right.
type In an attribute or a variable: describes the legal values the attribute or variable can take.
UML state machine See state machine diagram.
unambiguous requirement See ambiguity.
Unified Modeling Language (UML) A standard set of notations for representing models.
Unified Process See Unified Software Development Process.
Unified Software Development Process An iterative software life cycle model characterized
by cycles of four phases, called Inception, Elaboration, Construction, and Transition.
unit testing Testing individual components.
usability Ease with which a user can learn to operate, prepare inputs for, and interpret outputs
of a system or component.
usability testing The validation of a system or a model through the use of prototypes and
simulations by a user.
use case A general sequence of interactions between one or more actors and the system. See
also scenario.
use case diagram UML notation used during requirements elicitation and analysis to
represent the functionality of the system. A use case describes a function of the system in terms
of a sequence of interactions between an actor and the system. A use case also includes entry
conditions that must be true before executing the use case and the exit conditions that are true at
the completion of the use case.
user See end user.
User Manual A document describing the user interface of the system such that a user
unfamiliar with the system can use it.
Appendix B • Glossary 751

V-model A variation of the waterfall model that makes explicit the dependencies between
development processes and verification processes.
validation An activity that ensures that the system addresses the client’s needs.
variant Versions that are intended to coexist. For example, if a system can be executed on
different platforms, the system has a variant for each platform (e.g., a Windows variant, a
Macintosh variant, a Linux variant).
verifiability The property of a model indicating whether or not it can be falsified.
verification A set of formal methods that attempt to detect faults without executing the
system.
version A state of a configuration item or a CM aggregate at a well-defined point in time. The
version of a CM aggregate is called a configuration.
version identifier A number or a name that uniquely identifies a version.
vertical prototype A prototype that completely implements a restricted functionality, for
example, all the interface, control, and entity objects for one use case.
view In modeling, a subset of a model. Views focus on selected model elements to make them
more understandable. In the Model/View/Controller architectural style, a type of object or
subsystem responsible for displaying to the user information from model objects or subsystems.
visibility See attribute visibility.
visionary scenario Scenario that describes a future system. Visionary scenarios are used both
as a point in the modeling space by developers as they refine their ideas of the future system and
as a communication medium to elicit requirements from users.
walkthrough A scheduled communication event during which a developer presents a work
product line by line and other developers ask questions and challenge the work product. See also
inspection.
waterfall model A software life cycle model in which all development processes occur
sequentially.
WBS See work breakdown structure.
whitebox framework A framework that relies on inheritance and dynamic binding for
extensibility. Contrast with blackbox framework.
whitebox test A test that focuses on the internal structure of a component. Contrast with
blackbox test.
Work Breakdown Structure (WBS) A hierarchical decomposition of project work into
tasks. Leaves represent tasks that are assigned to participants. Aggregates represent the work
associated with a work product.
work package A specification of work to be accomplished in completing a task or activity.
752 Appendix B • Glossary

work product An artifact produced during development. Examples of work products include
the Requirements Analysis Document, the System Design Document, user interface prototypes,
market surveys, as well as the delivered system.
workflow In the Unified Process, a thread of cohesive and mostly sequential activities that
produce the artifacts. Engineering workflows (Requirements, Design, Implementation,
Assessment, Deployment) focus on development activities. Supporting workflows (Management,
Configuration and Change, Environment) focus on overhead activities needed to coordinate the
development activities.
workspace In configuration management, a library of promotions.
XP See Extreme Programming.
 A P P E N D I X C

Bibliography

[Abbott, 1983] R. Abbott, “Program design by informal English descriptions,”

Communications of the ACM, Vol. 26, No. 11, 1983.
[Adams, 2000] D. N. Adams, Mostly Harmless, Ballantine Books, 2000.
[Aguanno, 2005] K. Aguanno, Managing Agile Projects, Multi-Media Publications, Ontario,
2005.
[AgileManifesto, 2001] http://www.agilemanifesto.org.
[Albrecht & Gaffney, 1983] A. J. Albrecht & J. E. Gaffney Jr., “Software function, source lines of code,
and development effort prediction: A software science validation,” IEEE
Transactions on Software Engineering, Vol. SE-9, No. 6, November 1983.
[Allen, 1985] T. J. Allen, Managing the Flow of Technology: Technology Transfer and the
Dissemination of Technological Information within the R&D Organization,
2nd ed., MIT Press, Cambridge, MA, 1995.
[Ambler, 1998] S. W. Ambler, Process Patterns: Building Large-Scale Systems Using Object
Technology, Cambridge University Press, New York, 1998.
[Ambler, 2002] S. Ambler, Agile Modeling: Effective Practices for Extreme Programming
and the Unified Process, John Wiley & Sons, 2002.
[Apache] Apache, http://www.apache.org/.
[Babich, 1986] W. A. Babich, Software Configuration Management, Addison-Wesley,
Reading, MA, 1986.
[Baker et al., 2008] P. Baker, Z. R. Dai, & R. Grabowski, Model-Driven Testing: Using the UML
Testing Profile, Springer, Berlin, 2008.
[Barone & Switzer, 1995] J.T.T. Barone & J. Switzer, Interviewing: Art and Skill, Allyn & Bacon, 1995.
[Bass et al., 2003] L. Bass, P. Clements, & R. Kazman, Software Architecture in Practice, 2nd
ed., Addison-Wesley, Reading, MA, 2003.
[BEA] BEA WebLogic Platform, http://www.bea.com/products/weblogic/platform.
[Beck & Andres, 2005] K. Beck & C. Andres, Extreme Programming Explained: Embrace Change,
2nd ed., Addison-Wesley, Reading, MA, 2005.

753
754 Appendix C • Bibliography

[Beck & Cunningham, 1989] K. Beck & W. Cunningham, “A laboratory for teaching object-oriented
thinking,” OOPSLA’89 Conference Proceedings, New Orleans, LA, October
1–6, 1989.
[Berliner, 1990] B. Berliner, “CVS II: Parallelizing software development,” Proceedings of the
1990 USENIX Conference, Washington, DC, pp. 22–26, January 1990.
[Bersoff et al., 1980] E. H. Bersoff, V. D. Henderson, & S. G. Siegel, Software Configuration
Management: An Investment in Product Integrity, Prentice Hall, Englewood
Cliffs, NJ, 1980.
[Bezier, 1990] B. Bezier, Software Testing Techniques, 2nd ed., Van Nostrand, New York,
1990.
[Binder, 2000] R. V. Binder, Testing Object-Oriented Systems: Models, Patterns, and Tools,
Addison-Wesley, Reading, MA, 2000.
[Birrer, 1993] E. T. Birrer, “Frameworks in the financial engineering domain: An experience
report,” ECOOP’93 Proceedings, Lecture Notes in Computer Science, No.
707, 1993.
[Blaha & Premerlani, 1998] M. Blaha & W. Premerlani, Object-Oriented Modeling and Design for
Database Applications, Prentice Hall, Upper Saddle River, NJ, 1998.
[Boehm, 1987] B. Boehm, “A spiral model of software development and enhancement,”
Software Engineering Project Management, pp. 128–142, 1987.
[Boehm, 1991] B. Boehm, “Software risk management: Principles and practices,” IEEE
Software, Vol. 1, pp. 32–41, 1991.
[Boehm et al., 1998] B. Boehm, A. Egyed, J. Kwan, D. Port, A. Shah, & R. Madachy, “Using the
WinWin spiral model: A case study,” IEEE Computer 31(7): 33–44, 1998.
[Boehm et al., 2000] B. Boehm, E. Horowitz, R. Madachy, D. Reifer, B. K. Clark, B. Steece, A. W.
Brown, S. Chulani, C. Abts, Software Cost Estimation with COCOMO II,
Prentice Hall, Upper Saddle River, NJ, 2000.
[Bonatti, 2001] W. Bonatti, The Mountains of My Life, Modern Library, Random House, New
York, 2001.
[Booch, 1994] G. Booch, Object-Oriented Analysis and Design with Applications, 2nd ed.,
Benjamin/Cummings, Redwood City, CA, 1994.
[Booch et al., 2005] G. Booch, J. Rumbaugh, & I. Jacobson, The Unified Modeling Language
User Guide, Addison-Wesley, Reading, MA, 2005.
[Borghoff & Schlichter, 2000] U. W. Borghoff & J. Schlichter, Computer Supported Cooperative Work: An
Introduction into Distributed Applications, Springer-Verlag, 2000.
[Borning, 1981] A. Borning. “The programming language aspects of ThingLab, a constraint-
oriented simulation laboratory,” in ACM TOPLAS 3(4), October 1981.
[Brooks, 1995] F. P. Brooks, The Mythical Man Month: Anniversary Edition: Essays on
Software Engineering, Addison-Wesley, Reading, MA, 1995.
[Brown et al., 1999] W. J. Brown, H. W. McCormick, & S. W. Thomas, AntiPatterns and Patterns
in Software Configuration Management, Wiley, New York, 1999.
[Bruegge, 1992] B. Bruegge, “Teaching an industry-oriented software engineering course,”
Software Enginering Education, SEI Conference, Lecture Notes in Computer
Sciences, Vol. 640, Springer-Verlag, San Diego, CA, pp. 65–87, October
1992.
[Bruegge, 1994] B. Bruegge, “From toy systems to real system development,” Improvements in
Software Engineering Education, Workshop of the German Chapter of the
ACM, B.G. Teubner Verlag, Stuttgart, pp. 62–72, February 1994.
Appendix C • Bibliography 755

[Bruegge & Coyne, 1993] B. Bruegge & R. Coyne, “Model-based software engineering in larger scale
project courses,” IFIP Transactions on Computer Science and Technology,
Vol. A-40, pp. 273–287, 1993.
[Bruegge & Coyne, 1994] B. Bruegge & R. Coyne, “Teaching iterative object-oriented development:
Lessons and directions,” in Jorge L. Diaz-Herrera (ed.), 7th Conference on
Software Engineering Education, Lecture Notes in Computer Science,
Vol. 750, Springer-Verlag, pp. 413–427, January 1994.
[Bruegge et al., 1992] B. Bruegge, J. Blythe, J. Jackson, & J. Shufelt, “Object-oriented system
modeling with OMT,” Conference Proceedings OOPSLA ’92 (Object-
Oriented Programming Systems, Languages, and Applications), pp. 359–376,
October 1992.
[Bruegge et al., 1993] B. Bruegge, T. Gottschalk, & B. Luo, “A framework for dynamic program
analyzers,” OOPSLA’ 93 (Object-Oriented Programming Systems,
Languages, and Applications), Washington, DC, pp. 65–82, September 1993.
[Bruegge et al., 1994] B. Bruegge, K. O’Toole, & D. Rothenberger, “Design considerations for an
accident management system,” in M. Brodie, M. Jarke, & M. Papazoglou
(ed.), Proceedings of the Second International Conference on Cooperative
Information Systems, University of Toronto Press, Toronto, pp. 90–100, May
1994.
[BSCW] Basic Support for Cooperative Work, http://bscw.gmd.de.
[Buckingham Shum & Hammond, 1994] S. Buckingham Shum & N. Hammond, “Argumentation-based design
rationale: What use at what cost?” International Journal of Human-Computer
Studies, Vol. 40, pp. 603–652, 1994.
[Buhl, 1956] H. Buhl, Nanga Parbat Pilgrimage, Hodder & Stoughton, London, 1956.
[Buschmann et al., 1996] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, & M. Stal,
Pattern-Oriented Software Architecture: A System of Patterns, Wiley,
Chichester, U.K., 1996.
[Campbell & Islam, 1993] R. H. Campbell & N. Islam, “A technique for documenting the framework of
an object-oriented system,” Computing Systems, 6, pp. 363–389, 1993.
[Carr et al., 1993] M. J. Carr, S. L. Konda, I. Monarch, F. C. Ulrich, & C. F. Walker, Taxonomy-
Based Risk Identification, Technical Report CMU/SEI-93-TR-6, Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1993.
[Carroll, 1995] J. M. Carroll (ed.), Scenario-Based Design: Envisioning Work and
Technology in System Development, Wiley, New York, 1995.
[Charette, 1989] R. N. Charette, Software Engineering Risk Analysis and Management,
McGraw-Hill, New York, 1989.
[Chung et al., 1999] L. Chung, B. A. Nixon, E. Yu & J. Mylopoulos, Non-Functional
Requirements in Software Engineering, Kluwer Academic, Boston, 1999.
[Clements et al., 2002] P. Clements, R. Kazam, & M. Klein. Evaluating Software Architectures:
Methods and Case Studies, SEI Series in Software Engineering, Addison-
Wesley, Reading, MA, 2002.
[Coad et al., 1995] P. Coad, D. North, & M. Mayfield, Object Models: Strategies, Patterns, &
Applications, Prentice Hall, Englewood Cliffs, NJ, 1995.
[Cockburn, 2001a] A. Cockburn, Writing Effective Use Cases, Addison-Wesley, Reading, MA,
2001.
[Cockburn, 2001b] A. Cockburn, Agile Software Development, Addison-Wesley, Reading, MA,
2001.
756 Appendix C • Bibliography

[Cohn, 2006] M. Cohn, Agile Estimating and Planning, Pearson, Upper Saddle River, NJ,
2006.
[Conklin & Burgess-Yakemovic, 1991] J. Conklin & K. C. Burgess-Yakemovic, “A process-oriented approach to
design rationale,” Human-Computer Interaction, Vol. 6, pp. 357–391, 1991.
[Conradi & Westfechtel, 1998] R. Conradi & B. Westfechtel, “Version models for software configuration
management,” ACM Computing Surveys, Vol. 30, No. 2, June 1998.
[Constantine & Lockwood, 1999] L. L. Constantine & L. A. D. Lockwood, Software for Use, Addison-Wesley,
Reading, MA, 1999.
[Constantine & Lockwood, 2001] L. L. Constantine & L. A. D. Lockwood, “Structure and style in use cases for
user interface design,” in M. van Harmelen (ed.), Object-Oriented User
Interface Design, 2001.
[Contract4J] http://www.contract4j.org/
[Coyne et al., 1995] R. Coyne, B. Bruegge, A. Dutoit, & D. Rothenberger, “Teaching more
comprehensive model-based software engineering: Experience with
Objectory’s use case approach,” in Linda Ibraham (ed), 8th Conference on
Software Engineering Education, Lecture Notes in Computer Science,
Springer-Verlag, Berlin, pp. 339–374, April 1995.
[CruiseControl] http://cruisecontrol.sourceforge.net/.
[Curtis et al., 1988] B. Curtis, H. Krasner, & N. Iscoe, “A field study of the software design
process for large systems,” Communications of the ACM, 31(11), pp. 1268–
87, 1988.
[Cusumano & Selby, 1997] M. A. Cusumano, R. W. Selby, “How Microsoft Builds Software,”
Communications of the ACM, Vol. 40, No. 6, pp. 53–61, 1997.
[Dart, 1991] S. Dart, “Concepts in configuration management systems,” Third
International Software Configuration Management Workshop, ACM, June
1991.
[Date, 2004] C. J. Date, An Introduction to Database Systems, 8th ed., Addison-Wesley,
Reading, MA, 2004.
[Day & Zimmermann, 1983] J. D. Day & H. Zimmermann, “The OSI Reference Model,” Proceedings of
the IEEE, Vol. 71, pp. 1334–1340, December 1983.
[De Marco, 1978] T. De Marco, Structured Analysis and System Specification, Yourdon, New
York, 1978.
[Dijkstra, 1968] E. W. Dijkstra, “The Structure of the ‘T.H.E’ Multiprogramming System,”
Communication of the ACM, 18(8), pp. 453–457, 1968.
[Dijkstra, 1976] E. W. Dijkstra, A Discipline of Programming, Prentice-Hall, Englewood
Cliffs, NJ, 1976.
[DoD-STD-2167A] DoD-STD-2167A, Military Standard, Defense Systems Software
Development, US Department of Defense, Washington, DC, 1988.
[Douglass, 1999] B.P. Douglass, Doing Hard Time: Using Object Oriented Programming and
Software Patterns in Real Time Applications, Addison-Wesley, Reading, MA,
1999.
[Doyle & Straus, 1982] M. Doyle, & D. Straus, How to make meetings work, The Berkeley Publishing
Group, New York, NY, 1982.
[D’Souza & Wills, 1999] D. F. D’Souza & A. C. Wills, Objects, Components, and Frameworks with
UML: The Catalysis Approach, The Addison-Wesley Object Technology
Series, Addison-Wesley, Reading, MA, 1999.
[Dumas & Redish, 1998] Dumas & Redish, A Practical Guide to Usability Testing, Ablex, NJ, 1993.
Appendix C • Bibliography 757

[Dutoit & Bruegge, 1998] A. H. Dutoit & B. Bruegge, “Communication metrics for software
development,” IEEE Transactions on Software Engineering, August 1998.
[Dutoit & Paech, 2001] A. H. Dutoit & B. Paech. “Rationale management in software engineering,” in
S.K. Chang (ed.), Handbook of Software Engineering and Knowledge
Engineering, Vol. 1, World Scientific Publishing, 2001.
[Dutoit & Paech, 2002] A. H. Dutoit & B. Paech. “Rationale-based use case specification,”
Requirements Engineering Journal, 7(1), pp. 3–19, 2002.
[Dutoit et al., 1996] A. H. Dutoit, B. Bruegge, & R. F. Coyne, “The use of an issue-based model in
a team-based software engineering course,” Conference Proceedings of
Software Engineering: Education and Practice (SEEP’96), Dunedin, NZ,
January 1996.
[Dutoit et al., 2006] A. H. Dutoit, R. McCall, I. Mistrik, B. Paech (eds.) Rationale Management in
Software Engineering, Springer-Verlag, Heidelberg.
[Duval et al., 2007] P. Duval, S. Matyas, & A. Glover, Continuous Integration: Improving
Software Quality and Reducing Risk, Addison-Wesley, Reading, MA, 2007.
[Elssamadisy, 2009] A. Elssamadisy, Agile Adoption Patterns, Addison-Wesley, Reading, MA,
2009.
[Erl, 2005] T. Erl, Service-Oriented Architectures:Concepts, Technology, and Design,
Prentice Hall, Upper Saddle River, NJ, 2005.
[Erman et al., 1980] L. D. Erman, F. Hayes-Roth, et al., “The Hearsay-II Speech-Understanding
System: Integrating knowledge to resolve uncertainty,” ACM Computing
Surveys, Vol. 12, No. 2, pp. 213–253, 1980.
[Fagan, 1976] M. E. Fagan, “Design and code inspections to reduce errors in program
development,” IBM System Journal, Vol. 15, No. 3, pp. 182–211, 1976.
[Fayad & Hamu, 1997] M. E. Fayad & D. S. Hamu, “Object-oriented enterprise frameworks: Make
vs. buy decisions and guidelines for selection,” The Communications of ACM,
1997.
[Feiler & Tichy, 1998] P. Feiler & W. Tichy, “Propagator: A family of patterns,” in Proceedings of
TOOLS-23’97, Santa Barbara, CA, July 28–August 1 1997.
[Feynman, 1988] R. P. Feynman, “Personal observations on the reliability of the Shuttle,” in
[Rogers et al., 1986]. This article is also available on the Web, e.g.,http://
www.virtualschool.edu/mon/SocialConstruction/
FeynmanChallengerRpt.html.
[Fisher et al., 1991] R. Fisher, W. Ury, & B. Patton, Getting to Yes: Negotiating Agreement
Without Giving In, 2nd ed., Penguin Books, 1991.
[Floyd, 1967] R. W. Floyd, “Assigning Meanings to Programs,” in Proceedings of the
American Mathematics Society Symposium in Applied Mathematics, Vol. 19,
pp. 19–31, 1967.
[Fowler, 1997] M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley,
Reading, MA, 1997.
[Fowler, 2000] M. Fowler. Refactoring: Improving The Design of Existing Code, Addison-
Wesley, Reading, MA, 2000.
[Fowler, 2003] M. Fowler & K. Scott, UML Distilled: A Brief Guide To The Standard Object
Modeling Language, 3rd ed., Addison-Wesley, Reading, MA, 2003.
[Fowler, 2005] M. Fowler, The new methodology,
http://www.martinfowler.com/articles/newMethodology.html. Revised 2005.
758 Appendix C • Bibliography

[Freeman-Benson, 1990] B. Freeman-Benson. “Kaleidoscope: Mixing Objects, Constraints, and

Imperative Programming.” In OOPSLA/SIGPLAN Notices 25 (10): 77:88,
October 1990.
[FRIEND, 1994] FRIEND Project Documentation, School of Computer Science, Carnegie
Mellon University, Pittsburgh, PA, 1994.
[Gamma et al., 1994] E. Gamma, R. Helm, R. Johnson, & J. Vlissides, Design Patterns: Elements of
Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1994.
[Gantt, 1910] H. L. Gantt, “Work, wages, and profits,” The Engineering Magazine, New
York, 1910.
[Gleick, 1987] J. Gleick, Chaos - Making a New Science, Penguin Books Ltd,
Harmondsworth, Middlesex, 1987.
[Gladwin, 1964] T. Gladwin, “Culture and logical process,” in W. Goodenough (ed.),
Explorations in Cultural Anthropology: Essays Presented to George Peter
Murdock, McGraw-Hill, New York, 1964.
[Goldberg & Kay, 1976] A. Goldberg & A. Kay, Smalltalk-72 Instruction Manual, Xerox Palo
Alto,CA, 1976.
[Grady, 1992] R. Grady, Practical Software Metrics for Project Management and Process
Improvement, Prentice Hall, Englewood Cliffs, NJ, 1992.
[Grenning, 2002] J. Grenning, Planning Poker, http://www.planningpoker.com/ 2002.
[Grudin, 1988] J. Grudin, “Why CSCW applications fail: Problems in design and evaluation
of organization interfaces,” Proceedings of CSCW’88, Portland, OR, 1988.
[Grudin, 1990] J. Grudin, “Obstacles to user involvement in interface design in large product
development organizations,” Proceedings of IFIP INTERACT’90 Third
International Conference on Human-Computer Interaction, Cambridge, U.K.,
August 1990.
[Halstead, 1977] M. H. Halstead, Elements of Software Science, Elsevier, New York, 1977.
[Hammer & Champy, 1993] M. Hammer & J. Champy, Reengineering The Corporation: A Manifesto for
Business Revolution, Harper Business, New York, 1993.
[Harel, 1987] D. Harel, “Statecharts: A visual formalism for complex systems,” Science of
Computer Programming, pp. 231–274, 1987.
[Hartkopf et al., 1997] V. Hartkopf, V. Loftness, A. Mahdavi, S. Lee, & J. Shankavarm, “An
integrated approach to design and engineering of intelligent buildings—The
Intelligent Workplace at Carnegie Mellon University, Automation in
Construction, Vol. 6, pp. 401–415, 1997.
[Herbert, 1985] F. Herbert, Chapterhouse: Dune, Orion Publishing, 1985.
[Highsmith, 2004] J. Highsmith, Agile Project Management, Pearson Education, Boston, 2004.
[Highsmith & Orr, 2000] J. Highsmith, & K. Orr, Adaptive Software Development: A Collaborative
Approach to Managing Complex Systems, Dorset House, 2000.
[Hoare, 1969] C. A. R. Hoare, “An axiomatic basis for computer programming,”
Communications of the ACM, Vol. 20, No. 6, pp. 576–580, October 1969.
[Hoare, 1980] C. A. R. Hoare, “The emperor’s old clothes,” Turing Award Lecture, 1980.
[Hofmeister, 2000] C. Hofmeister, R. Nord, & D. Soni, Applied Software Architecture, Object
Technology Series, Addison-Wesley, 2000.
[Hopper, 1981] G. M. Hopper, “The First Bug,” Annals of the History of Computing, 3, pp.
285–286, 1981.
Appendix C • Bibliography 759

[Horn, 1992] B. Horn, “Constraint patterns as a basis for object-oriented programming,” in

Proceedings of the OOPSLA’92, Vancouver, Canada, 1992.
[Humphrey, 1989] W. Humphrey, Managing the Software Process, Addison-Wesley, Reading,
MA, 1989.
[IBM] IBM, WebSphere Software Platform for E-Business,
http://www.ibm.com/websphere/.
[IEEE Std. 610.12-1990] Institute of Electrical and Electronics Engineers, IEEE Standard Computer
Dictionary: A Compilation of IEEE Standard Computer Glossaries, New
York, NY, 1990.
[IEEE Std. 828-2005] IEEE Standard for Software Configuration Management Plans, IEEE
Standards Board, August 2005.
[IEEE Std. 829-2008] IEEE Standard for Software Test Documentation, IEEE Standards Board, July
2008.
[IEEE Std. 830-1998] IEEE Standard for Software Requirements Specification, IEEE Standards
Board, June 1998.
[IEEE Std. 982.2-1988] IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce
Reliable Software, IEEE Standards Board, June 1988.
[IEEE Std. 1042-1987] IEEE Guide to Software Configuration Management, IEEE Standards Board,
September 1987.
[IEEE Std. 1058-1998] IEEE Standard for Software Project Management Plans, IEEE Computer
Society, New York, December 1998.
[IEEE Std. 1074-2006] IEEE Standard for Developing Software Life Cycle Processes, IEEE
Computer Society, New York, July 2006.
[IEEE/EIA, 1996] IEEE/EIA 12207.0-1996, Industry Implementation of International Standard
ISO/IEC 12207: 1995 Standard for Information Technology–Software life
cycle processes, IEEE Computer Society & Electronic Industries Association,
March 1998.
[ISO Std. 9126] International Standards Organization. Software engineering -- Product
quality. ISO/IEC-9126, Geneva, Switzerland, 2001.
[ISO/IEC 12207, 1995] ISO/IEC 12207. Information technology–Software life cycle processes.
International Organization for Standardization & International
Electrotechnical Commission, August 1995.
[JavaEE, 2009] Java Platform, Enterprise Edition, Javasoft, 2009, http://java.sun.com/.
[Jackson, 1995] M. Jackson, Software Requirements & Specifications: A Lexicon of Practice,
Principles and Prejudices, Addison-Wesley, Reading, MA, 1995.
[Jacobson et al., 1992] I. Jacobson, M. Christerson, P. Jonsson, & G. Overgaard, Object-Oriented
Software Engineering—A Use Case Driven Approach, Addison-Wesley,
Reading, MA, 1992.
[Jacobson et al., 1995] I. Jacobson, M. Ericsson, & A. Jacobson, The Object Advantage: Business
Process Reengineering with Object Technology, Addison-Wesley, Reading,
MA, 1995.
[Jacobson et al., 1999] I. Jacobson, G. Booch, & J. Rumbaugh, The Unified Software Development
Process, Addison-Wesley, Reading, MA, 1999.
[Jarke, 1998] M. Jarke, “Requirements Tracing,” Communications of the ACM, Vol. 41,
No. 12, December 1998.
[Javadoc, 2009a] Sun Microsystems, Javadoc homepage, http://java.sun.com/j2se/javadoc/.
760 Appendix C • Bibliography

[Javadoc, 2009b] Sun Microsystems, “How to write doc comments for Javadoc,” http://
java.sun.com/j2se/writingdoccomments/.
[jContractor] http://jcontractor.sourceforge.net/
[JDBC, 2009] JDBCTM—Connecting Java and Databases, JDK Documentation, Javasoft,
2009.
[Jensen & Tonies, 1979] R. W. Jensen & C. C. Tonies, Software Engineering, Prentice Hall,
Englewood Cliffs, NJ, 1979.
[JFC, 2009] Java Foundation Classes, JDK Documentation, Javasoft, 2009.
[Johnson, 1992] P. Johnson, Human Computer Interaction: Psychology, Task Analysis and
Software Engineering, McGraw-Hill International, London, 1992.
[Johnson & Foote, 1988] R. Johnson & B. Foote, “Designing reusable classes,” Journal of
Object-Oriented Programming, Vol. 1, No. 5, pp. 22–35, 1988.
[Jones, 1977] T. C. Jones, “Programmer quality and programmer productivity,” IBM
Technical Report TR–02.764, 1977.
[JUnit, 2009] JUnit, http://www.junit.org/.
[Katzenbach & Smith, 1994] J. R. Katzenbach & D. K. Smith, The Wisdom of Teams: Creating The High-
Performance Organization, Harper Business, 1994.
[Kayser, 1990] T. A. Kayser, Mining Group Gold, Serif, El Segundo, CA, 1990.
[Kelly, 1984] J. F. Kelly, “An iterative design methodology for user-friendly natural
language office information applications,” ACM Transactions on Information
Systems, Vol. 2, No. 1, January 1984.
[Kemerer, 1997] C. F. Kemerer, Software Project Management: Readings and Cases,
Irwin/McGraw-Hill, Boston, MA 1997.
[Knuth, 1986] D. E. Knuth, The TeXbook, Addison-Wesley, Reading, MA, 1986.
[Kotonya & Sommerville, 1996] G. Kotonya & I. Sommerville, “Requirements Engineering with Viewpoints,”
Software Engineering Journal 11(1), 1996.
[Kramer, 1998] R. Kramer, “iContract—The Java Design by Contract Tool,” Technology of
Object-Oriented Languages and Systems, IEEE Computer Society Press,
1998, p.295.
[Kraut & Streeter, 1995] R. E. Kraut, & L. A. Streeter, “Coordination in software development,”
Communications of the ACM, Vol. 38, No. 3, March 1995.
[Kruchten, 1998] P. Kruchten, The Rational Unified Process: An Introduction, Reading, MA,
Addison-Wesley 1998.
[Kunz & Rittel, 1970] W. Kunz & H. Rittel, “Issues as elements of information systems,” Working
Paper No. 131, Institut für Grundlagen der Plannung, Universität Stuttgart,
Germany, 1970.
[Larman, 2005] C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design, 3rd ed., Prentice Hall, Upper Saddle River, NJ, 2005.
[Leblang, 1994] D. Leblang, “The CM challenge: Configuration management that works,” in
W. F. Tichy (ed.), Configuration Management, Vol. 2, Trends in Software,
Wiley, New York, 1994.
[Lee, 1990] J. Lee, “A qualitative decision management system,” in P. H. Winston &
S. Shellard (eds.), Artificial Intelligence at MIT: Expanding Frontiers, MIT
Press, Cambridge, MA, Vol. 1, pp. 104–33, 1990.
[Lee, 1997] J. Lee, “Design rationale systems: Understanding the issues,” IEEE Expert,
May/June 1997.
Appendix C • Bibliography 761

[Leveson, 1995] N. G. Leveson, Safeware: System Safety And Computers, Addison-Wesley,

Reading, MA, 1995.
[Lions, 1996] J.-L. Lions, ARIANE 5 Flight 501 Failure: Report by the Inquiry Board, http:/
/ravel.esrin.esa.it/docs/esa-x-1819eng.pdf, 1996.
[Liskov, 1988] B. Liskov, “Data abstraction and hierarchy,” SIGPLAN Notices, Vol. 23,
No. 3, May, 1988.
[Liskov & Guttag, 1986] B. Liskov & J. Guttag, Abstraction and Specification in Program
Development, MIT Press, McGraw-Hill, New York, 1986.
[Lotus] Lotus, http://www.lotus.com/.
[Macaulay, 1996] L. Macaulay, Requirements Engineering, Springer-Verlag, London, 1996.
[MacLean et al., 1991] A. MacLean, R. M. Young, V. Bellotti, & T. Moran, “Questions, options, and
criteria: Elements of design space analysis,” Human-Computer Interaction,
Vol. 6, pp. 201–250, 1996.
[Marshall, 2001] R. Marshall, What really happened at K2? Chapter 24 in [Bonatti 2001].
[Martin & Odell, 1992] J. Martin & J. J. Odell, Object-Oriented Analysis and Design, Prentice Hall,
Englewood Cliffs, NJ, 1992.
[Mayhew, 1999] D. J. Mayhew, The Usability Engineering Lifecycle: A Practitioner’s
Handbook for User Interface Design, Morgan Kaufmann, 1999.
[McCabe, 1976] T. McCabe, “A software complexity measure,” IEEE Transactions on
Software Engineering, Vol. 2, No. 12, December 1976.
[Mellor & Shlaer, 1998] S. Mellor & S. Shlaer, Recursive Design Approach, Prentice Hall, Upper
Saddle River, NJ, 1998.
[Meyer, 1997] B. Meyer, Object-Oriented Software Construction, 2nd ed., Prentice Hall,
Upper Saddle River, NJ, 1997.
[Microsoft] Microsoft, http://www.microsoft.com/.
[MIL Std. 480] MIL Std. 480, U.S. Department of Defense, Washington, DC.
[Miller, 1956] G. A. Miller, “The magical number seven, plus or minus two: Some limits on
our capacity for processing information.” Psychological Review, Vol. 63, pp.
81–97, 1956.
[Minsky, 1975] M. Minsky, “A framework for representing knowledge,” in P. Winston (ed.),
The Psychology of Computer Vision, McGraw-Hill , 1975.
[Moran & Carroll, 1996] T. P. Moran & J. M. Carroll (eds.), Design Rationale: Concepts, Techniques,
and Use, Lawrence Erlbaum Associates, Mahwah, NJ, 1996.
[Mowbray & Malveau, 1997] T. J. Mowbray & R. C. Malveau, CORBA Design Patterns, Wiley, New York,
1997.
[Mozilla] Mozilla, http://www.mozilla.org/.
[Myers, 1979] G. J. Myers, The Art of Software Testing, Wiley, New York, 1979.
[Neumann, 1995] P. G. Neumann, Computer-Related Risks, Addison-Wesley, Reading, MA,
1995.
[Nielsen, 1993] J. Nielsen, Usability Engineering, Academic, New York, 1993.
[Nielsen & Mack, 1994] J. Nielsen & R. L. Mack (eds.), Usability Inspection Methods, Wiley, New
York, 1994.
[Norman, 2002] D. A. Norman, The Design of Everyday Things, Basic Books, New York,
2002.
762 Appendix C • Bibliography

[OMG, 2005] Object Management Group UML Testing Profile Version 1.0. 05-07-07.
http://www.omg.org/ 2005.
[OMG, 2006] Object Management Group, Object Constraint Language OMG Available
Specification Version 2.0. http://www.omg.org 2006.
[OMG, 2008] Object Management Group, Common Object Request Broker Architecture
(CORBA) Specification: Version 3.1. http://www.omg.org/ 2008.
[OMG, 2009] Object Management Group, OMG Unified Modeling Language
Superstructure, Version 2.2. http://www.omg.org/ 2009.
[OWL, 1996] OWL Project Documentation, School of Computer Science, Carnegie Mellon
Univ., Pittsburgh, PA, 1996.
[Palmer & Felsing, 2002] S. Palmer, & J. Felsing, A Practical Guide to Feature-Driven Development,
Prentice Hall, Upper Saddle River, NJ, 2002.
[Parnas, 1972] D. Parnas, “On the criteria to be used in decomposing systems into modules,”
Communications of the ACM, 15(12), pp. 1053–1058, 1972.
[Parnas & Weiss, 1985] D. L. Parnas & D. M. Weiss, “Active design reviews: principles and practice,”
Proceedings of the Eighth International Conference on Software Engineering,
London, England. pp 132–136, August 1985.
[Partsch, 1990] H. Partsch, Specification and Transformation of Programs, Springer-Verlag,
1990.
[Paulish, 2001] D. J. Paulish, Architecture-Centric Software Project Management: A
Practical Guide, SEI Series in Software Engineering, Addison-Wesley,
Reading, MA, 2001.
[Paulk et al., 1995] M. C. Paulk, C. V. Weber, & B. Curtis (eds.), The Capability Maturity Model:
Guidelines for Improving the Software Process, Addison-Wesley, Reading,
MA, 1995.
[Perforce] http://www.perforce.com/.
[Perlis, 1982] A. Perlis, “Epigrams in Programming,” ACM, SIGPLAN, 1982.
[Petroski, 1992] H. Petroski, To Engineer is Human, Vintage Books, Random House, New
York, 1992.
[Petroski, 1994] H. Petroski, The Evolution of Useful Things, Vintage Books, Random House,
New York, 1994.
[Pfleeger, 1991] S. L. Pfleeger, Software Engineering: The Production of Quality Software,
2nd ed., Macmillan, 1991.
[Pirsig, 1984] R. M. Pirsig, Zen and the Art of Motorcycle Maintenance, Bantam Books,
1984.
[Pirsig, 1991] R. M. Pirsig, Lila: An Inquiry into Morals, Bantam Doubleday Dell, 1991.
[Popper, 1992] K. Popper, Objective Knowledge: An Evolutionary Approach, Clarendon,
Oxford, 1992.
[Porter et al., 1997] A. A. Porter, H. Siy, C. A. Toman, & L. G. Votta, “An experiment to assess the
cost-benefits of code inspections in large scale software development,” IEEE
Transactions on Software Engineering, Vol. 23, No. 6, pp. 329–346, June
1997.
[Portny, 2001] S. E. Portny, Project Management for Dummies, John Wiley & Sons, 2000.
[POSIX, 1990] Portable Operating System Interface for Computing Environments, IEEE Std.
1003.1, IEEE, 1990.
Appendix C • Bibliography 763

[Potts, 1996] C. Potts, “Supporting software design: Integrating design methods and design
rationale,” in T. P. Moran & J. M. Carroll (eds.), Design Rationale: Concepts,
Techniques, and Use, Lawrence Erlbaum Associates, Mahwah, NJ, 1996.
[Potts & Bruns, 1988] C. Potts & G. Bruns, “Recording the Reasons for Design Decisions,” in
Proceedings of the 10th International Conference on Software Engineering,
pp. 418–427, 1988.
[Potts et al., 1994] C. Potts, K. Tkahashi, & A. I. Anton, “Inquiry-based requirements analysis,”
IEEE Software, Vol. 11, No. 2, pp. 21–32, 1994.
[Pressman, 2009] R. S. Pressman, Software Engineering: A Practitioner’s Approach, 7th ed.,
McGraw-Hill, 2009.
[Purvis et al., 1996] M. Purvis, M. Purvis, & P. Jones, “A group collaboration tool for software
engineering projects,” Conference Proceedings of Software Engineering:
Education and Practice (SEEP’96), Dunedin, NZ., January 1996.
[Rational] Rationale, http://www.rational.com.
[Rational, 2002] Rationale Rose, Rational Software Corp., Cupertino, CA, 2002.
[Raymond, 1998] E. Raymond, “The cathedral and the bazaar,” http://www.tuxedo.org/~esr/
writings/cathedral-bazaar/cathedral-bazaar.html, 1998.
[Ritchie & Thompson, 1974] D. M. Ritchie & K. Thompson, “The Unix Time-sharing System,”
Communications of the ACM, Vol. 17, No. 7, pp. 365–37, July 1974.
[RMI, 2009] Java Remote Method Invocation, JDK Documentation, Javasoft, 2009.
[Rochkind, 1975] M.J. Rochkind, “The Source Code Control System,” IEEE Transactions on
Software Engineering, SE-1(4), p. 255–265., 1975.
[Rogers et al., 1986] The Presidential Commission on the Space Shuttle Challenger Accident
Report, Washington, DC, June 1986.
[Rowen, 1990] R. B. Rowen, “Software project management under incomplete and
ambiguous specifications,” IEEE Transactions on Engineering Management,
Vol. 37, No. 1, 1990.
[Royce, 1970] W. W. Royce, “Managing the development of large software systems,” in
Tutorial: Software Engineering Project Management, IEEE Computer
Society, Washington, DC, pp. 118–127, 1970.
[Royce, 1998] W. Royce, Software Project Management: A Unified Framework, Addison-
Wesley, Reading, MA, 1998.
[Rubin, 1994] J. Rubin, Handbook of Usability Testing, Wiley, New York, 1994.
[Rumbaugh et al., 1991] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, & W. Lorensen,
Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, NJ,
1991.
[Schlumberger] Schlumberger, http://www.cyberflex.com/
[Schmidt, 1997] D. C. Schmidt, “Applying design patterns and frameworks to develop
object-oriented communication software,” in P. Salus (ed.), Handbook of
Programming Languages, Vol. 1, MacMillan Computer, 1997.
[Schwaber & Beedle, 2002] K. Schwaber & M. Beedle, Agile Software Development with Scrum, Prentice
Hall, Upper Saddle River, NJ, 2002.
[Schwaber, 2004] K. Schwaber, Agile Project Management With Scrum, Microsoft, Redwood,
2004.
[Shaw & Garlan, 1996] M. Shaw & D. Garlan, Software Architecture: Perspectives on an Emerging
Discipline, Prentice Hall, Upper Saddle River, NJ, 1996.
764 Appendix C • Bibliography

[Shipman & McCall, 1997] F. M. Shipman III & R. J. McCall, “Integrating different perspectives on
design rationale: Supporting the emergence of design rationale from design
communication,” Artificial Intelligence in Engineering Design, Analysis, and
Manufacturing, Vol. 11, No. 2, 1997.
[Siewiorek & Swarz, 1992] D. P. Siewiorek & R. S. Swarz, Reliable Computer Systems: Design and
Evaluation, 2nd ed., Digital, Burlington, MA, 1992.
[Simon, 1970] H. A. Simon, The Sciences of the Artificial, MIT Press, Cambridge, MA,
1970.
[Sommerville, 2006] I. Sommerville, Software Engineering, 8th ed., Addison-Wesley, 2006.
[Spivey, 1992] J. M. Spivey, The Z Notation, A Reference Manual, 2nd ed., Prentice Hall
International, Hertfordshire, U.K., 1992.
[Steelman, 1978] Requirements for High Order Computer Programming Languages: Steelman,
U.S. Department of Defense, Washington, DC, 1978.
[Subrahmanian et al., 1997] E. Subrahmanian, Y. Reich, S. L. Konda, A. Dutoit, D. Cunningham,
R. Patrick, M. Thomas, & A. W. Westerberg, “The n-dim approach to
building design support systems,” Proceedings of ASME Design Theory and
Methodology DTM’97, ASME, New York, 1997.
[Suchman, 2007] L. A. Suchman, Human-Machine Reconfiguration: Plans and Situated
Actions, 2nd ed. Cambridge University Press, 2007.
[Sun, 2009] Sun Microsystems Code Conventions for the Java Programming Language.
http://www.java.sun.com/docs/codeconv/ 2009.
[Tanenbaum, 1996] A. S. Tanenbaum, Computer Networks, 3rd ed. Prentice Hall, Upper Saddle
River, NJ, 1996.
[Taylor, 1911] F. W. Taylor, The Principles of Scientific Management, Harper Bros., New
York, 1911.
[Telelogic] Telelogic, http://www.telelogic.se.
[Tichy, 1985] W. Tichy, “RCS—A system for version control,” Software Practice and
Experience, Vol. 15, No. 7, 1985.
[TogetherSoft, 2002] TogetherSoft, Together Control Center, Raleigh, NC, 2002,
http://www.togethersoft.com.
[Tolkien, 1995] J.R.R. Tolkien, The Lord of The Rings, Harper Collins, 1995.
[Tunde & Harmon Ray, 1994] A. Ogunnaike Babatunde & W. Harmon Ray, Process Dynamics, Modeling
and Control, Oxford University Press, 1994.
[Turner & Robson, 1993] C. D. Turner & D. J. Robson, “The state-based testing of object-oriented
programs,” Conference on Software Maintenance, pp. 302–310, September
1993.
[Twain, 1897] M. Twain, Following the Equator: A Journey Around the World, American
Publishing Co., Hartford, 1897, BoondocksNet Edition, 2003.
[Vaughan, 1996] D. Vaughan, The Challenger Launch Decision: Risky Technology, Culture,
and Deviance at NASA, The University of Chicago Press, Chicago, 1996.
[Viller & Sommerville, 1999] S. Viller & I. Sommerville, “Social analysis in the requirements engineering
process: from ethnography to method,” International Symposium on
Requirements Engineering (ISRE’99), Limerick, Ireland, June 1999.
[Warmer & Kleppe, 2003] J. Warmer & A. Kleppe, The Object Constraint Language: Getting Your
Modes Ready for MDA, 2nd ed., Addison-Wesley, Reading, MA, 2003.
Appendix C • Bibliography 765

[Weinand et al., 1988] A. Weinand, E. Gamma, & R. Marty, “ET++—An object-oriented application
framework in C++,” in Object-Oriented Programming Systems, Languages,
and Applications Conference Proceedings, San Diego, CA, September 1988.
[Weinberg, 1971] G. M. Weinberg, The Psychology of Computer Programming, Van Nostrand,
New York, 1971.
[Wigand et al., 1997] R. T. Wigand, A. Picot, & R. Reichwald, Information, Organization and
Management: Expanding Markets and Corporate Boundaries, John Wiley &
Sons, London, 1997.
[Wilson & Ostrem, 1999] G. Wilson & J. Ostrem, WebObjects Developer’s Guide, Apple Computers,
Cupertino, CA, 1998.
[Wirfs-Brock, 1995] R. Wirfs-Brock, “Design objects and their interactions: A brief look at
responsibility-driven design,” in J. M. Carroll (ed.), Scenario-Based Design:
Envisioning Work and Technology in System Development, Wiley, New York,
1995.
[Wirfs-Brock et al., 1990] R. Wirfs-Brock, B. Wilkerson, & L. Wiener, Designing Object-Oriented
Software, Prentice Hall, Englewood Cliffs, NJ, 1990.
[Wood & Silver, 1989] J. Wood & D. Silver, Joint Application Design®, Wiley, New York, 1989.
[Wordsworth, 1992] J. B. Wordsworth, Software Development with Z: A Practical Approach to
Formal Methods in Software Engineering, Addison-Wesley, Reading, MA,
1992.
[Yourdon & Constantine, 1979] E. Yourdon & L. Constantine, Structured Design, Prentice Hall, Englewood
Cliffs, NJ, 1979.
[Wiki] Wiki, http://c2.com/cgi/wiki?WikiWikiWeb.
[Yahoo] Yahoo, http://groups.yahoo.com.
[Zultner, 1993] R. E. Zultner, “TQM for technical teams,” Communications of the ACM,
Vol. 36, No. 10, pp. 79–91, 1993.
This page intentionally left blank
Index

A actor 44, 722

heuristics 132
Abbott’s heuristics 180
abstract class 38, 721 identifying 124, 130
abstract data type 38, 721 identifying relationships 140
Abstract Factory design pattern 328, 342, 710 adaptability 126, 251, 722
abstraction 721 Adapter design pattern 318, 323, 711
acceptance testing 442, 475, 721 administration cost 251
access control 269– 275 agenda 736
access control list 270, 721 aggregation 56, 192, 722
access path composition 192
optimizing 403 shared 192, 745
access right 270, 721 Airbus A320 family 538
accuracy 126, 721 alpha testing 475
action 63, 721 alternative 495, 722
action item 504, 586, 721 ambiguity 128, 143, 174, 722
activities 88 analysis 16, 173– 206, 722
activity 585, 627, 721 activities 179
in a software life cycle 13 communicating about 201
in a state machine 64 concepts 176
in an activity diagram 66 documenting 199
activity diagram 44, 65, 722 iterating over 203
applying 68 managing 199
activity partition 66, 722 roles 200
activity-centered software life cycle model 623, analysis model 123, 175– 198, 722
637, 722 reviewing 196

767
768 Index

analysis object realizing 411

heuristics for initial set 145 association table 419
identifying initial set 143 asynchronous groupware 108
analysis object model 175, 176, 722 ATRACT 681– 683
analyst 201, 722 attribute 39, 193, 723
API 230, 311, 722 description 193
API engineer 87, 722 heuristics 194
application domain 41, 722 identifying 193
application domain specialist 88, 723 identifying missing 366
application framework 332, 723 name 193
application logic layer 244 attribute type 723
application object 313, 723 attribute visibility 723
application programmer interface 230 auditing 540, 723
architect 723 auditor 568, 723
during analysis 201 authentication 273, 723
during object design 381, 424 availability 126, 250, 724
during system design 286
architectural pattern 723 B
architectural risk 667 ball-and-socket connectors 230
architectural style 723 base class 313, 724
architecture first 664 baseline 543, 724
architecture liaison 723 bazaar model 724
during object design 381, 424 benchmark test 475
during system design 286 beta testing 475
ARENA 23 big bang testing 466, 724
analysis 206– 218 blackbox framework 333, 724
design patterns 341– 344 blackbox test 450, 724
mapping to code 424– 432 blooper 308
requirements elicitation 153– 168 Boehm’s spiral model 639
specifying interfaces 382– 388 Boeing 747 538
system design 290– 302 bottom-up testing 466, 724
argument 59, 503, 723 boundary condition 279, 724
argumentation 495, 723 identifying 279
Ariane 501 78 boundary object 177, 724
as-is scenario 133, 723 heuristics 183
assembly connector 230 identifying 182
assessment 502 boundary testing 456
association 52, 190, 723 boundary use case 279, 724
heuristics 191 brainstorming 97, 724
identifying 190 branch 546, 724
name 190 branch management 557
association class 53, 723 Bridge design pattern 321, 712
bug 724
Index 769

build management 540, 724 Command design pattern 329, 342, 713
buried association 418, 724 communication 726
burn down chart 613 activity 21
communication diagrams 61, 726
C communication event 726
callback 244, 724 communication infrastructure
candidate keys 417, 724 setting up 598
capability 271, 724 communication mechanism 102, 726
Capability Maturity Model 633, 725 communication relationship 46, 726
cathedral model 725 competitor testing 475
centralized traffic control 498, 725 completeness 128, 726
change 548, 725 of the system design 283
change control 540, 725 component 726
change control board 568, 725 encapsulating 323
change management 565, 664 inspecting 451
change request 541, 544, 725 logical 229
change set 548, 725 physical 229
changed-based view 548 component champion 340
chief programmer organization 616, 725 component expert 727
chronological minutes 517 component inspection 727
ciphertext 274 component-based development 664
clarity 128, 725 Composite design pattern 330, 714
class 35, 38, 50, 725 composition aggregation 192, 727
class diagram 43, 725 concept 727
applying 59 configuration 542, 543, 727
class extender 353, 725 configuration item 541, 542, 727
class implementor 353, 725 identifying 540, 552
class user 353, 725 configuration management 727
ClearCase 548 activities 550
client 88, 242, 726
documenting 567
during analysis 200
managing 566
client class 318, 353, 726
planning 568
client review 81, 95, 726
roles 568
client sign-off 204
client type 655 tools 548
client/server 242, 726 configuration management aggregate 541, 727
closed architecture 235, 726 configuration manager 87, 568, 727
closed issue 645, 726 during analysis 201
CM aggregate 541, 542, 726 during object design 381
identifying 552 during reuse 340
CMM 633 during system design 286
See Capability Maturity Model conflict resolution 531
cohesion 228, 231, 726 consistency 128, 727
770 Index

of the system design 283 Decision Representation Language 505, 507, 729
constraint 70, 727 defect 729
heuristics 373 delegation 316, 729
consultant role 88, 727 deliverable 13, 90, 586, 729
continuous integration 569 delta 548, 729
contract 356, 727 dependability criterion 126, 250, 729
inheriting 374 deployment cost 251
contract inheritance 374, 727 deployment diagram 262, 729
control flow 275, 727 derived class 729
encapsulating 329 derived classes 313
control node 66, 728 design goal 729
control object 177, 728 addressing 264
heuristics 184 identifying 249
identifying 184 design pattern 317, 709– 718, 729
controller 728 developer 729
correction 445, 451, 728 during configuration management 568
correctness 128, 728 during object design 424
of the system design 282 development cost 251
correctness debugging 441 development processes 630
cost criterion 250, 728 development role 86
coupling 228, 230, 728 different time, different place groupware 108
coverage (in equivalence testing) 455 discount usability engineering 453
CRC card 189– 190, 672, 728 disjointedness (in equivalence testing) 456
criterion 495, 502, 728 distribution 657
critical path 588, 728 document editor 87, 729
cross development 728 during analysis 201
cross-functional role 87, 728 during system design 286
cross-functional team 85, 109, 728 DoD Std 2167A 647
CTC 498, 510, 728 domain experience 667
See also Centralized Traffic Control domain object 729
CVS 548 double test 465
cycle 639 DRL 505
dynamic access control 273, 730
D dynamic model 30, 175, 176, 730
daily Scrum meeting 613
data flow 728 E
data record 416 egoless programming 616, 730
data type 35, 37, 728 encryption 274, 730
DCOM 333 end user 88, 656, 730
debugging 441, 729 during analysis 200
decision 495, 729 end user criterion 251, 730
in an activity diagram 66 enterprise application framework 333, 730
decision rationale 507 entity object 177, 730
Index 771

heuristics 181 flat file 268

identifying 180 flat staffing 602
entity-centered software life cycle model 623, floor plan example 224
644, 730 flow of events 731
entry condition 45, 730 in a scenario 50
environment 730 in a use case 46
equivalence testing 455 fly-by-wire 538
erroneous state 440, 444, 730 foreign key 417, 731
error 440, 730 fork node 66, 732
evaluation scenario 133, 730 forward engineering 376, 400, 644, 732
event 40, 730 four-tier 245, 732
event class 40, 730 framework 332, 732
event-driven control 276, 730 identifying and adjusting 332
exception 730 FRIEND 49, 62, 68, 131, 684
exception handling 280– 281, 730 functional model 30, 175, 732
exit condition 46, 730 functional requirements 125, 732
expensive computation functional testing 442, 472, 732
caching the result of 405 FURPS+ 126
delaying 405
extend relationship 47, 140, 731 G
heuristics 143 Gantt chart 90, 732
extender class 318, 731 generalization 49, 178, 732
extensibility 251, 731 generalization-specialization 179, 732
external behavior 44, 731 gIBIS 507
Extreme Programming 669– 673, 731 global access table 270, 732
global control flow 275
F goal 732
Facade design pattern 253, 715 goodness measure 502, 732
facilitator 105, 731, 740 gradual staffing 602
failure 440, 444, 731 greenfield engineering 129, 732
falsification 43, 731 groupware 732
fault 440, 444, 731 different time, different place 108, 729
interface misuse 4 same time different place 108, 745
leap year 4
security 4 H
year 1900 4 hallway conversation 104, 732
fault avoidance 440, 731 ham 494
fault detection 441, 731 hardware configuration 264
fault tolerance 250, 441, 731 hierarchical decomposition 235
field testing 475, 731 hierarchical organization 84, 733
filter 245 hook method 333, 733
Final Document (JAD) 150 horizontal mapping 420
firewall 271, 731 horizontal prototype 289, 454, 733
772 Index

I issue model 735

issue resolution 81, 101, 735
IBIS 506, 734
issue-based development 9, 734
ideal week 670, 733
Issue-Based Information System 505, 734
IEEE Std 1042 540, 541
issue-based life cycle model 645, 734
IEEE Std 1058.1 589
IEEE Std 1074 626
J
IEEE Std 828 567
imperative language 733 JAD
implementation 20, 733 See also Joint Application Design
implementation decision 38, 733 JAMES 691
implementation domain 733 join node 66, 735
See also solution domain Joint Application Design 124, 148, 735
implementation inheritance 315, 733 JUnit 483
implementation requirements 127, 733
implementor class 318, 733 K
include relationship 46, 47, 141, 733 K2 652
heuristics 143 key process area 634, 735
infrastructure framework 333, 733 kick-off meeting 602, 735
inheritance 38, 57, 178, 195, 733 knowledge acquisition 5, 8, 735
inheritance relationship 733 KPA 735
inspection 96, 441, 734 See key process area
installation 610, 734
installation test 476 L
installation testing 442, 476, 734
late and over budget 4
instance 35, 37, 734
layer 228, 235, 735
integral processes 632
leap year bug 4
integration testing 442, 451, 465, 734
legal requirements 127, 735
strategies 466
liaison 85, 87, 735
interaction diagram 43, 59, 734
liaison-based communication 85
interface engineering 130, 734
life cycle 735
interface inheritance 315, 734
light rail system 350
interface layer 244
link 52, 735
interface misuse 4
Liskov Substitution Principle 317, 735
interface requirements 127, 734
local king client 655, 735
internal transition 64, 734
Lord Of The Rings, The 394
internal work product 90, 586, 734
invariant 356, 371, 734
M
ISO 9126 126
issue 495, 499, 734 maintainability 126, 735
closed 499 maintenance cost 251
maintenance criterion 251, 736
consequent 499
management role 86, 600, 736
open 499
many-to-many association 54, 736
subissue 499
Index 773

realizing 409 O
mapping 736
object 35, 39, 50, 738
master directory 542, 545, 736
collapsing 404
meeting 105, 736
meeting agenda 105 interactions 185
meeting minutes 105 Object Constraint Language 357, 738
memory 250 object design 19, 310, 738
merge 546 activities 320, 365, 402
message 40, 58, 59, 736 concepts 313, 352, 396
method 15, 58, 655, 736 documenting 375
methodological heuristics 702 managing 337, 375, 422
methodology 15, 655, 736 roles 340, 381, 424
metrics 604, 604– 607, 668 Object Design Document 375– 381, 738
middleware framework 333, 736 template 378
MIL Std 480 542 object design model 738
minute taker 105, 528, 736 object designer 381, 738
minutes 736 object diagram 738
model 12, 35, 736 object model 30, 738
model object 737 object-oriented analysis 41, 738
model transformation 397, 737 object-oriented database 268
Model/View/Controller 240, 737 object-oriented design 41, 738
modeling 5, 6, 35, 659, 737 Observer design pattern 242, 343, 716
models 659 OCL 357, 738
modifiability 251, 737 OCL bag 364, 738
modified sandwich testing 469 OCL collection 363, 738
multiplicity 54, 191, 737 OCL sequence 363, 738
MVC 737 OCL set 363, 738
myCarParts 550 ODD 739
myTrip 247 See also Object Design Document
on time delivery 4
N one-to-many association 54, 739
name 737 realizing 408
navigation 52, 737 one-to-one association 54, 739
negotiation 530 realizing 406
nested state 65, 737 open architecture 235, 739
nested state machine 65, 737 open issue 645, 739
NFR Framework 505, 508, 737 operation 39, 58, 739
nonfunctional requirements 126, 737 identifying missing 366
identifying 146 operations requirements 127, 739
notation 15, 37, 737 optical illusion 174
note 738 organization 739
in UML 69 OWL
client acceptance test agenda 95
774 Index

Problem Statement 94 precondition 356, 369, 740

pre-development processes 630
P preparation (JAD) 150
package (UML) 68, 739 primary key 416, 740
packaging requirements 127, 739 problem definition 580, 740
pair programming 669, 672 problem domain 740
participant 11, 79, 739 problem inspection 81, 740
participating actor 739 problem presentation 93, 740
participating actor instance 739 problem solving 5, 8, 741
participating actors Problem Statement 741
in a scenario 50 developing 594
in a use case 45 template 595
participating object 32, 143, 739 problem statement 580, 593
procedural language 741
cross checking with use cases 146
procedure-driven control 275, 741
partition 228, 237, 739
process 626, 741
path testing 458
process flexibility 667
pattern expert 739
process group 626, 741
pattern interface 318, 739
process management 541, 741
patterns champion 340
process maturity 667
peer review 81, 739
product owner 612
peer-based communication 86, 739
product test 454
peer-to-peer 243, 739
Project Agreement 589, 741
Perforce 548
project backlog 612
performance criterion 250, 740
project communication 92
performance debugging 441
project conception phase 741
performance testing 442, 473, 740
project definition (JAD) 150
persistent data 266, 740
project definition phase 80, 741
persistent data store
project environment 655
defining 266
project function 585
PERT chart 92, 740
project goal 654
phase 13, 740
project initiation 592, 741
phenomenon 740
project management 23, 577, 741
pilot testing 475, 740
activities 592
pipe and filter 245, 740
project management processes 628
plaintext 274
project member 79, 741
planned communication event 92
project review 81, 95, 742
platform 264
project scale 666
polymorphism testing 463
project start phase 80, 742
portability 126, 251, 740
project steady state 742
postcondition 356, 369, 740
project steady state phase 80
post-development processes 631
project termination 81, 592, 742
postmortem review 98, 611, 740
project velocity 671, 742
potentially deliverable product increment 611
project-based organization 741
Index 775

promotion 542, 544, 742 realism 129

promotion management 554 of the system design 283
proposal 500, 742 realizability 743
prototype test 454 recovery tests 474
prototyping 43, 742 reengineering 129, 743
proxy client 656, 742 refactor 672
Proxy design pattern 265, 273, 405, 717 refactoring 398, 743
pseudo client 656, 742 refined class 743
pseudo requirements 127, 742 regression test 481
regression testing 743
Q relation 416
QOC 505, 507, 742, 743 relational database 268
quadruple test 465 release 81, 97, 542, 545, 743
qualification 56, 742 release management 555
qualified association 57, 742 reliability 126, 250, 440, 743
realizing 410 reporting structure 84, 743
qualifier 57, 742 repository 239, 542, 545, 744
quality requirements 127 repository architectural style 239, 744
representation (in equivalence testing) 456
in a use case 46
request for change 81, 100, 744
questionnaire 104, 743
request for clarification 81, 99, 744
Questions, Options, and Criteria 505, 507, 743
requirements 744
functional 14, 125
R
nonfunctional 14, 126
RAD 199, 594, 743 identifying 124
See also Requirements Analysis Document Requirements Analysis Document 151– 153, 199,
rationale 6, 10, 495, 743 744
activities 510 template 152
capturing asynchronously 519 requirements elicitation 16, 123, 744
capturing in meetings 511 activities 130
capturing when discussing change 520 concepts 125
communicating about 529 documenting 151
concept 497 managing 148
documenting 526 requirements engineering 744
management 9, 22, 526 requirements specification 123, 744
reconstructing 524 requirements testing 472
roles 528 resolution 504, 744
rationale editor 528, 743 resources 14, 744
rationale management 493– 532, 743 response time 126, 250, 744
rationale model 526, 743 reverse engineering 377, 401, 644, 744
RCS 548 review 441
readability 251, 743 reviewer 528, 744
of the system design 283 during analysis 201
776 Index

during system design 286 specifying 368

risk 744 skill
risk management 607– 609, 744 identifying 599
risk-based development 9, 744 slack time 588, 746
robustness 126, 250, 745 software architecture 238, 746
role 745 software configuration management 22, 537– 569
in an association 54, 191 Software Configuration Management Plan 567–
in an organization 11 568, 746
round 639 template 567
round-trip engineering 644, 664, 745 software engineering methodology 655
Royce’s methodology 663, 745 software library 542, 545, 746
Rubin 174 software life cycle 23, 626, 746
software life cycle model 623, 746
S Software Project Management Plan 589– 592,
746
safety 126, 250, 745
software reliability 440, 746
sandwich testing 467, 745
solution domain 41, 746
SatWatch 125
solution object 313, 746
sawtooth model 647
Space Shuttle
scenario 50, 135, 745
computer redundancy 260
heuristics 134, 139
Space Shuttle Challenger 576
identifying 124
Space Shuttle Columbia 438
scenario test 454
Space Shuttle Discovery 122
schedule 79, 745
specialization 178, 746
creating initial 597 specification inheritance 315, 746
schema 268, 416, 745 Speed 308
SCMP 745 spiral model 746
See also Software Configuration Management SPMP 594, 746
Plan
See also Software Project Management Plan
Scrum master 612
sprint 611
Scrum team 613
sprint backlog 612
SDD 442, 745
sprint planning meeting 612
See also System Design Document staged build 570
secondary facilitator 745 stakeholder cohesion 667
security 4, 250, 745 stand up meeting 673
security testing 474 Star Wars Trilogy 308
sequence diagram 32, 59, 185, 745 state 62, 747
heuristics 189 state machine diagram 44, 62, 747
server 242 applying 65
service 228, 230, 745 state-based testing 461
session (JAD) 150 state-based view 548
shadow testing 475 static access control 272, 747
shared aggregation 192, 745 status accounting 540, 747
signature 354, 746 status meeting 81, 747
Index 777

status review 96 T
stereotype 70, 747
tables 416
stimulus 747
tame problem 506
storage layer 244
task 14, 80, 88, 584, 748
Strategy design pattern 325, 718
task model 586, 749
streetcar system 350
team 109, 602, 749
stress testing 474
team leader 749
strict inheritance 317, 747
team-based organization 83, 749
structural testing 747
technical consultant 88, 746, 749
structured interview 104, 747
technical role 600
structured minutes 518
technical writer 749
STS-51L 576
during object design 381
Stuttgart 350
subclass 38, 57, 747 during reuse 340
subclasses 313 test case 444, 448, 484, 749
subsystem 35, 228, 747 Test Case Specification 478
allocating to node 265 template 480
test component 444, 484
encapsulating 253
test context 484
identifying 253
test driver 444, 450, 749
subsystem decomposition 748
test first 672
subsystem interface 230, 748
test harness 484
subsystem team 109, 748
Test Incident Report 478
subtype 317
Test Manual 749
superclass 38, 57, 313, 748
test objective 484
supportability 126, 748
Test Plan 478
swimlane 66, 748
template 478
Swing 236
test planning 442, 749
SYBIL 507
Test Report Summary 478
system 12, 35, 748
test stub 444, 450, 749
system design 19, 223– 302, 748
Test Summary Report 478
activities 247, 264
test system 484
communicating 287
tester 88, 749
concepts 228, 262 testing 20, 440, 749
documenting 284 concepts 444
iterating 288 managing 476
managing 284 thread 276, 749
reviewing 282 three-tier 244, 749
System Design Document 284, 748 throughput 126, 250, 749
system design model 748 time constraint 588
system model 35, 36, 748 timekeeper 105, 749
system structure testing 442 timing tests 474
system testing 442, 452, 471, 748 Titanic 308
system under test 484 Tolkien, J.R.R. 394
778 Index

top-down testing 466, 749 V

top-level design 593, 750
validation 751
defining 594
variant 542, 543, 751
traceability 124, 129, 251, 750
variant management 562
maintaining 150 verdict 484
training scenario 133, 750 verifiability 129, 751
transformation 395, 750 verification 751
transition 62, 750 version 542, 543, 751
internal transition 64, 734 version identifier 545, 751
triple test 465 vertical mapping 420
tuple 750 vertical prototype 289, 454, 751
type 750 view 36, 751
of an attribute 194, 354 visibility 354
specifying 368
U visionary scenario 133, 751
U2TP 484 V-model 638, 751
UML profile 484 volume testing 474
UML state machine 750
unambiguous requirement 750 W
Unified Modeling Language (UML) 30, 750 walkthrough 96, 441, 751
Unified Process 641, 663, 750 waterfall model 637, 751
Unified Software Development Process 641, 750 WBS 751
unit testing 442, 451, 455, 750 WebObjects 335
unnecessary complexity 4 whitebox framework 333, 751
unplanned communication event 99 whitebox test 450, 751
upgrade cost 251 wicked problem 506
usability 126, 252, 750 wizard of Oz prototype 454
examples 122 work breakdown structure 586, 751
usability testing 442, 451, 453– 487, 750 work package 90, 585, 751
use case 44, 135, 750 work product 13, 79, 88, 585, 752
cross checking with participating objects 146 deliverable 13
heuristics 139 internal 13
identifying 124, 135 workflow 752
identifying relationships 124, 140 workspace 545, 752
refining 124, 138
use case diagram 31, 43, 750 X
user 750 XP 669, 731
user interface prototype 454
User Manual 750 Y
utility 252
year 1900 bug 4
year 2000 bug 494
Dealing with complexity

problem
statement

Requirements
elitation (Ch.4)

nonfunctional functional
requirements model use case diagram

Analysis (Ch.5)

analysis object
class diagram
model statechart diagram

dynamic model

System design (Ch.6 & 7)

sequence diagram

subsystem
decomposition

system design
object model

design goals
Object design (Ch.8 & 9)

object design
class diagram
model

Implementation (Ch.10)
source code

Test (Ch.11)

deliverable system
Managing change
Rationale (Ch.12)

assesses
Criterion Proposal

* * *

solvable-by
Issue based-on

resolved-by Resolution

Testing (Ch.11)
implementedBy
Test suite
exercises is-revised-by
* * 1…n

Test case Component Correction

* *
finds * * repairs
* * * *
Failure Error Fault
is-caused-by is-caused-by

Project
Management (Ch.14)

Project

Resource

*
Outcome Work
*

*
Set of
work products Work product Activity Task

Configuration
Management (Ch.13)

*
Controlled item

CM Aggregate Configuration item Version

Promotion Release
Design patterns
Abstract Factory (328, 341, 710) this pattern shields a system from the concrete classes provided by
a specific platform, such as a windowing style or an operating system.
Adapter (319, 711) This pattern encapsulates a piece of legacy code that was not designed to work
with the system. It also limits the impact of substituting the piece of legacy code for a different
component.
Bridge (321, 712) This pattern decouples the interface of a class from its implementation. Unlike the
Adapter pattern, the developer is not constrained by an existing piece of code.
Command (329, 342, 713) This pattern enables the encapsulation of control objects so that user
requests can be treated uniformly, independent of the specific request. This pattern protects
these objects from changes required by new functionality.
Composite (55, 228, 233, 330, 714) This pattern represents a hierarchy which has dynamic width and
depth. The services related to the hierarchy are factored out using inheritance, allowing a system
to treat leaves and intermediate composite nodes uniformly.
Facade (254, 715) This pattern reduces dependencies among classes by encapsulating a subsystem
with a simple unified interface.
Observer (240, 342, 716) This pattern allows to maintain consistency across the states of one
Publisher and many Subscribers.
Proxy (274, 405, 717) This pattern improves the performance or the security of a system by delaying
expensive computations, using memory only when needed, or checking access before loading
an object into memory.
Strategy (325, 463, 718) This pattern decouples a policy from a set of mechanisms or a context from a
set of implementations. Depending on the policy or context, the mechanisms or
implementations can be changed at runtime transparently from the client.

Notations
UML use case diagrams (31, 44) Use case diagrams are used to represent the functionality of the
system, as seen by an actor.
UML class diagrams (32, 50) Class diagrams are used to represent the structure of the system, in
terms of subsystems, classes, attributes, operations, and associations.
UML sequence diagrams (32, 59) Sequence diagrams represent behavior in terms of a series of
interactions among a set of objects.
UML statechart diagrams (33, 62) Statechart diagrams represent behavior of a single object as a
state machine in terms of events and transitions.
Activity diagrams (33, 65) Activity diagrams are flow diagrams which represent behavior of a set of
objects as activities and transitions.
UML deployment diagrams (228) Deployment diagrams represent the mapping of software
components to hardware nodes.
Issue models (497) Issue models represent the justification of decisions in terms of issues, proposals,
arguments, criteria, and resolutions.
PERT charts (90) PERT charts represent the division of work into tasks and ordering constraints.
Example systems
2Bwatch and SatWatch (125) 2Bwatch is a digital watch with two buttons. SatWatch is a digital
watch that uses GPS satellites to select the correct time zone. Except for a display, it provides no
interface for its user. Both are systems that are simple enough for introducing basic
requirements elicitation concepts.
FRIEND (131, 181) FRIEND is a distributed information system for managing accidents. It allows
field officers, dispatchers, and authorities to communicate and allocate resources to an
emergency. FRIEND is a much more complex system than either 2Bwatch or SatWatch. It
illustrates how requirements elicitation and analysis methods scale up to a real system. FRIEND
was realized in CMU between 1992 and 1994.
myTrip (247) myTrip enables users to plan a trip and download its information into their car. Once in
the car, users can execute their trip and receive directions. This example was inspired from the
JAMES system which was realized in CMU and in TUM in 1997 and 1998. We use the myTrip
system to illustrate system design methods.
CTC (510) CTC is a centralized traffic control system for trains. It enables dispatchers to monitor and
direct trains remotely. Such systems usually have a long life and high availability requirements.
We use the access control mechanisms of CTC for illustrating rationale management methods.
myCarParts (550) myCarParts is a web-based electronic catalog of car parts. It enables novice users
and mechanics to browse, search, and order parts. myCarParts is a client server system in which
both the server and the client are incrementally improved. We use myCarParts to illustrate the
activities of configuration management. myCarParts was inspired by PAID, a system realized at
CMU and TUM in 1998 and 1999.
ARENA (153, 206, 290, 341, 382, 424) ARENA is a multi-user, Web-based system for organizing and
conducting tournaments. ARENA is game independent in the sense that organizers can adapt a
new game to the ARENA game interface, upload it to the ARENA server, and immediately announce
and conduct tournaments with players and spectators located anywhere on the Internet.
Organizers can also define new tournament styles, describing how players are mapped to a set of
matches and how to compute an overall ranking of players by adding up their victories and
losses (hence, figuring out who won the tournament). To recoup their operational costs,
organizers can also invite potential sponsors to display advertisement banners during games.
ARENA has been realized at TUM and the University of Otago in 2002 and 2003.