What is Software Engineering?

Software engineering is a modeling activity. Software engineers deal with complexity through modeling,
by focusing at any one time on only the relevant details and ignoring everything else. In the course of
development, software engineers build many different models of the system and of the application domain.

Software engineering is a problem-solving activity. Models are used to search for an acceptable solution.
This search is driven by experimentation. Software engineers do not have infinite resources and are
constrained by budget and deadlines. Given the lack of a fundamental theory, they often have to rely on
empirical methods to evaluate the benefits of different alternatives.

Software engineering is a knowledge acquisition activity. In modeling the application and solution
domain, software engineers collect data, organize it into information, and formalize itinto knowledge.
Knowledge acquisition is not sequential, as a single piece of additional data caninvalidate complete
models.

Software engineering is a rationale-driven activity. When acquiring knowledge and making decisions
about the system or its application domain, software engineers also need to capture the context in which
decisions were made and the rationale behind these decisions. Rationale information, represented as a set
of issue models, enables software engineers to understand the implication of a proposed change when
revisiting a decision.

1.2.1 Modeling

One of the basic methods of science is modeling. A model is an abstract representation of a system that
enables us to answer questions about the system. Models are useful when dealing with systems that are too
large, too small, too complicated, or too expensive to experience firsthand. Models also allow us to
visualize and understand systems that either nolonger exist or that are only claimed to exist.

First, software engineers need to understand the environment in which the system has to operate. For a
train trafficcontrol system, software engineers need to know train signaling procedures. For a stock trading
system, software engineers need to know trading rules.

Second, software engineers need to understand the systems they could build, to evaluate different solutions
and trade-offs. Most systems are too complex to be understood by any one person, and most systems are
expensive to build.

Object-oriented methods combine the application domain and solution domain modelling activities into
one. The application domain is first modeled as a set of objects and relationships. This model is then used
by the system to represent the real-world concepts it manipulates. A train traffic control system includes
train objects representing the trains it monitors. A stock trading system includes transaction objects
representing the buying and selling of commodities. Then, solution domain concepts are also modeled as
objects. The set of lines used to depict a train or a financial transaction are objects that are part of the
solution domain. The idea of object-oriented methods is that the solution domain model is a transformation
of the application domain model. Developing software translates into the activities necessary to identify
and describe a system as a set of models that addresses the end user’s problem.

1.2.2 Problem Solving

Engineering is a problem-solving activity. Engineers search for an appropriate solution, often by trial and
error, evaluating alternatives empirically, with limited resources and incomplete knowledge. In its simplest
form, the engineering method includes five steps:
1. Formulate the problem.
2. Analyze the problem.
3. Search for solutions.
4. Decide on the appropriate solution.
5. Specify the solution.
Software engineering is an engineering activity. It is not algorithmic. It requires experimentation, the reuse of
pattern solutions, and the incremental evolution of the system toward a solution that is acceptable to the client.
Knowledge acquisition is a nonlinear process. The addition of a new piece of information may invalidate all
the knowledge we have acquired for the understanding of a system. Even if we had already documented this
understanding in documents and code (“The system is 90% coded, we will be done next week”), we must be
mentally prepared to start from scratch.

Rationale
For software engineers, the situation is different. Assumptions that developers make about a system change
constantly. Even though the application domain models eventually stabilize once developers acquire an
adequate understanding of the problem, the solution domain models are in constant flux. Design and
implementation faults discovered during testing and usability problems discovered during user evaluation
trigger changes to the solution models. Changes can also be caused by new technology

Software Engineering Concepts

[Link], Methods, and Methodologies

[Link] and Nonfunctional Requirements
[Link], Tasks, and Resources
[Link] Products
[Link] and Models
[Link] and Roles

Participants and Roles

The project manager plans and budgets the project and coordinates the developers and the client. The
end users are supported by the system. We refer to all the persons involved in the project as participants.
We refer to a set of responsibilities in the project or the system as a role. A role is associated with a set of
tasks and is assigned to a participant. The same participant can fill multiple roles.

Systems and Models

We use the term system as a collection of interconnected parts. Modeling is a way to deal with
complexity by ignoring irrelevant details. We use the term model to refer to any abstraction of the system.
A TicketDistributor for an underground train is a system. Blueprints for the TicketDistributor, schematics
of its electrical wiring, and object models of its software are models of the TicketDistributor. Note that a
development project is itself a system that can be
modeled. The project schedule, its budget, and its planned deadlines are models of the development
project.

Work Products
A work product is an artifact that is produced during the development, such as a document or a
piece of software for other developers or for the client. We refer to a work product for the project’s internal
consumption as an internal work product. We refer to a work product that must be delivered to a client as
a deliverable. Deliverables are generally defined prior to the start of the project and specified by a contract
binding the developers with the client.

Activities, Tasks, and Resources

An activity is a set of tasks that is performed toward a specific purpose. For example, requirements
elicitation is an activity whose purpose is to define with the client what the system will do. Delivery is an
activity whose purpose is to install the system at an operational location. Management is an activity whose
purpose is to monitor and control the project such that it meets its goals (e.g., deadline, quality, budget).
Activities can be composed of other activities. The delivery activity includes a software installation activity
and an operator training activity. Activities are also sometimes called phases.

A task represents an atomic unit of work that can be managed: A manager assigns it to a developer, the
developer carries it out, and the manager monitors the progress and completion of the task. Tasks consume
resources, result in work products, and depend on work products produced by other tasks.

Resources are assets that are used to accomplish work. Resources include time, equipment, and labor.
When planning a project, a manager breaks down the work into tasks and assigns them to resources.

Functional and Nonfunctional Requirements

Requirements specify a set of features that the system must have. A functional requirement is a
specification of a function that the system must support, whereas a nonfunctional requirement is a
constraint on the operation of the system that is not related directly to a function of the system.

Notations, Methods, and Methodologies

A notation is a graphical or textual set of rules for representing a model. The Roman alphabet is a
notation for representing words.

A method is a repeatable technique that specifies the steps involved in solving a specific problem. A recipe
is a method for cooking a specific dish. A sorting algorithm is a method for ordering elements of a list.

A methodology is a collection of methods for solving a class of problems and specifies how and when
each method should be used.

Software Engineering Development Activities

Development activities deal with the complexity by constructing and validating models of the
application domain or the system. Development activities include
1. Requirements Elicitation
2. Analysis
3. System Design
4. Object Design
5. Implementation
6. Testing).
Requirements Elicitation

During requirements elicitation, the client and developers define the purpose of the system. The
result of this activity is a description of the system in terms of actors and use cases. Actors represent the
external entities that interact with the system. Actors include roles such as end users, other computers the
system needs to deal with and the environment. Use cases are general sequences of events that describe all
the possible actions between an actor and the system for a given piece of functionality.

Analysis
During analysis, developers aim to produce a model of the system that is correct, complete,
consistent, and unambiguous. Developers transform the use cases produced during requirements elicitation
into an object model that completely describes the system. During this activity, developers discover
ambiguities and inconsistencies in the use case model that they resolve with the client. The result of
analysis is a system model annotated with attributes, operations, and associations. The system model can
be described in terms of its structure and its dynamic interoperation.

System Design
 During system design, developers define the design goals of the project and decompose the system
into smaller subsystems that can be realized by individual teams. Developers also select strategies for
building the system, such as the hardware/software platform on which the system will run, the persistent
data management strategy, the global control flow, the access control policy, and the handling of boundary
conditions. The result of system design is a clear description of each of these strategies, subsystem
decomposition, and a deployment diagram representing the hardware/software mapping of the system.

Object Design
During object design, developers define solution domain objects to bridge the gap between the
analysis model and the hardware/software platform defined during system design. This includes precisely
describing object and subsystem interfaces, selecting off-the-shelf components, restructuring the object
model to attain design goals such as extensibility or understand ability, and optimizing the object model for
performance. The result of the object design activity is a detailed object model annotated with constraints
and precise descriptions for each element.

Implementation
During implementation, developers translate the solution domain model into source code. This
Includes implementing the attributes and methods of each object and integrating all the objects such that
they function as a single system. The implementation activity spans the gap between the detailed object
design model and a complete set of source code files that can be compiled.

Testing
During testing, developers find differences between the system and its models by executing the
system (or parts of it) with sample input data sets. During unit testing, developers compare the object
design model with each object and subsystem. During integration testing, combinations of subsystems are
integrated together and compared with the system design model. During system testing, typical and
exception cases are run through the system and compared with the requirements model. The goal of testing
is to discover as many faults as possible such that they can be repaired before the delivery of the system.

Managing Software Development

Management activities focus on planning the project, monitoring its status, tracking changes, and
coordinating resources such that a high-quality product is delivered on time and within budget.
Management activities not only involve managers, but also most of the other project participants as well.
Management activities include
1. Communication
2. Rationale Management
3. Software Configuration Management
4. Project Management
5. Software Life Cycle

Communication
Communication is the most critical and time-consuming activity in software engineering.
Communication includes the exchange of models and documents about the system and its application
domain, reporting the status of work products, providing feedback on the quality of work products, raising
and negotiating issues, and communicating decisions. To deal with communication issues, project
participants have many tools available.

Rationale Management
Rationale is the justification of decisions. Rationale is the most important information developers
need when changing the system. If a criterion changes, developers can re-evaluate all decisions that depend
on this criterion. If a new alternative becomes available, it can be compared with all the other alternatives
that were already evaluated. If a decision is questioned, they can recover its rationale to justify it.

Software Configuration Management

Software configuration management is the process that monitors and controls changes in work
products. Configuration management enables developers to track changes. The system is represented as a
number of configuration items that are independently revised. Configuration management also enables
developers to control change.

Project Management
Project management includes the oversight activities that ensure the delivery of a high-quality system
on time and within budget. This includes planning and budgeting the project during negotiations with the
client, hiring developers and organizing them into teams, monitoring the status of the project, and
intervening when deviations occur.

Software Life Cycle

The process of developing software can also be viewed as a complex system with inputs, outputs,
activities, and resources. A general model of the software development process is called a software life
cycle.

UML

The goal of UML is to provide a standard notation that can be used by all object-oriented methods and to
select and integrate the best elements of precursor notations. UML also includes new concepts that were
not present in other major methods at the time, such as extension mechanisms and a constraint language.
UML has been designed for a
broad range of applications. Hence, it provides constructs for a broad range of systems and activities.

The functional model, represented in UML with use case diagrams, describes the functionality of the
system from the user’s point of view.
The object model, represented in UML with class diagrams, describes the structure of the system in terms
of objects, attributes, associations, and operations.
The dynamic model, represented in UML with interaction diagrams, state machine diagrams, and activity
diagrams, describes the internal behaviour of the system.

Modeling Concepts

Systems, Models, and Views

A system is an organized set of communicating parts. Parts of a system can in turn be considered as
simpler systems called subsystems. Modeling is a means for dealing with this complexity. Complex
systems are generally described by more than one model, each focusing on a different aspect or level of
accuracy. Modeling means constructing an abstraction of a system that focuses on interesting aspects and
ignores irrelevant details. A view focuses on a subset of a model to make it understandable UML describes
a system in terms of classes, events, states, interactions, and activities.

Data Types, Abstract Data Types, and Instances

A data type is an abstraction in the context of a programming language. A data type has a unique name
that distinguishes it from other data types. It denotes a set of values that are members of the data typeand
defines the structure and the operations valid in all instances of the data type. Data types are used in typed
languages to ensure that only valid operations are applied to specific instances.

An abstract data type is a data type defined by an implementation-independent specification. Abstract

data types enable developers to reason about a set of instances without looking at a specific
implementation of the abstract data type.

Classes, Abstract Classes, and Objects

A class is an abstraction in object-oriented modeling and in object-oriented programming Languages
classes can be defined in terms of other classes by using inheritance. This type of relationship between a
base class and a refined class is called inheritance. The generalization class (e.g., Watch) is called the
superclass, the specialized class (e.g., CalculatorWatch) is called the subclass.

A Deeper View into UML

We now describe in detail the five main UML diagrams we use in this book.
• Use case diagrams represent the functionality of the system from a user’s point of view. They define the
boundaries of the system (Section 2.4.1).
• Class diagrams represent the static structure of a system in terms of objects, their attributes, operations,
and relationships (Section 2.4.2).
• Interaction diagrams represent the system’s behavior in terms of interactions among a set of objects.
They are used to identify objects in the application and implementation domains (Section 2.4.3).
State machine diagrams represent the behavior of nontrivial objects (Section 2.4.4).
• Activity diagrams are flow diagrams used to represent the data flow or the control flow through a system
(Section 2.4.5).

Use Case Diagrams

Use cases and actors
Actors are external entities that interact with the system. Examples of actors include a
user role (e.g., a system administrator, a bank customer, a bank teller) or another system (e.g., a
central database, a fabrication line). Actors have unique names and descriptions.
Use cases describe the behavior of the system as seen from an actor’s point of view.
Behavior described by use cases is also called external behavior. A use case describes a
function provided by the system as a set of events that yields a visible result for the actors.
Actors initiate a use case to access system functionality. The use case can then initiate other use
cases and gather more information from the actors. When actors and use cases exchange
information, they are said to communicate. We will see later that we represent these exchanges
with communication relationships.
For example, in an accident management system, field officers (such as a police officer or
a fire fighter) have access to a wireless computer that enables them to interact with a dispatcher.
The dispatcher in turn can visualize the current status of all its resources, such as police cars or
trucks, on a computer screen and dispatch a resource by issuing commands from a workstation.

The name of the use case is unique across the system so that developers (and project
participants) can unambiguously refer to the use case
.
• Participating actors are actors interacting with the use case.

• Entry conditions describe the conditions that need to be satisfied before the use case is
initiated.
The flow of events describes the sequence of interactions of the use case, which are to be numbered for
reference. The common case (i.e., cases that are expected by the user) and the exceptional cases (i.e., cases
unexpected by the user, such as errors and unusual conditions) are described separately in different use
cases for clarity.

Exit conditions describe the conditions satisfied after the completion of the use case.

• Quality requirements are requirements that are not related to the functionality of the system. These
include constraints on the performance of the system, its implementation, the hardware platforms it runs
on, and so on.

Include relationships
When describing a complex system, its use case model can become quite complex and can contain
redundancy. We reduce the complexity of the model by identifying commonalities in different use cases.
Two use cases are related by an include relationship if one of them includes the second one in its flow of
events. In use case diagrams, include relationships are depicted by a dashed open arrow originating from
the including use case (see Figure 2-15). Include relationships are labeled with the string «include».
Extend relationships
Extend relationships are an alternate means for reducing complexity in the use case model. A use case
can extend another use case by adding events. An extend relationship indicates that an instance of an
extended use case may includebehavior specified by the extending use case. A typical application of
extend relationships is the specification of exceptional behavior. For example (Figure 2-17), assume that
the network connection between the Dispatcher and the FieldOfficer can be interrupted at any time. (e.g., if
the FieldOfficer enters a tunnel).
Inheritance relationships
An inheritance relationship is a third mechanism for reducing the complexity of a model. One use case
can specialize another more general one by adding more detail. For example, FieldOfficers are required to
authenticate before they can use FRIEND. During early stages of requirements elicitation, authentication is
modeled as a high-level Authenticate use case. Later, developers describe the Authenticate use case in
more detail and allow for several different hardware platforms. This refinement activity results in two more
use cases: AuthenticateWithPassword which enables FieldOfficers to login without any specific hardware,
and AuthenticateWithCard which enables FieldOfficers to login using a smart card. The two new use cases
are represented as specializations of the Authenticate use case
Scenarios
A use case is an abstraction that describes all possible scenarios involving the described
functionality. A scenario is an instance of a use case describing a concrete set of actions.
Scenarios are used as examples for illustrating common cases; their focus is on
understandability. Use cases are used to describe all possible cases; their focus is on
completeness. We describe a scenario using a template with three fields:
• The name of the scenario enables us to refer to it unambiguously. The name of a
scenario is underlined to indicate that it is an instance.
• The participating actor instances field indicates which actor instances are involved in
this scenario. Actor instances also have underlined names.
• The flow of events of a scenario describes the sequence of events step by step.

Class Diagrams
Classes and objects
Class diagrams describe the structure of the system in terms of classes and objects.
Classes are abstractions that specify the attributes and behavior of a set of objects. A class is a
collection of objects that share a set of attributes that distinguish the objects as members of the
collection. Objects are entities that encapsulate state and behavior. Each object has an identity:
it can be referred individually and is distinguishable from other objects.
In UML, classes and objects are depicted by boxes composed of three compartments. The
top compartment displays the name of the class or object. The center compartment displays its
attributes, and the bottom compartment displays its operations. The attribute and operation
compartments can be omitted for clarity. Object names are underlined to indicate that they are
instances. By convention, class names start with an uppercase letter. Objects in object diagrams
may be given names (followed by their class) for ease of reference.
Associations and links
A link represents a connection between two objects. Associations are relationships between
classes and represent groups of links.
In UML, associations can be symmetrical (bidirectional) or asymmetrical (unidirectional).
All the associations in Figure 2-22 are symmetrical. Figure 2-24 depicts an example of onedirectional
association between Polygon and Point. The navigation arrow at the Point end of
the association indicates that the system only supports navigation from the Polygon to the
Point. In other words, given a specific Polygon, it is possible to query all Points that make up.

Multiplicity
Each end of an association can be labeled by a set of integers indicating the number of
links that can legitimately originate from an instance of the class connected to the association
end. This set of integers is called the multiplicity of the association end.
In UML, an association end can have an arbitrary set of integers as a multiplicity. For
example, an association could allow only a prime number of links and thus, would have a
multiplicity 1, 2, 3, 5, 7, 11, 13, and so forth. In practice, however, most of the associations we
encounter belong to one of the following three types (see Figure 2-27):
• A one-to-one association has a multiplicity 1 on each end. A one-to-one association
between two classes (e.g., PoliceOfficer and BadgeNumber) means that exactly one
link exists between instances of each class (e.g., a PoliceOfficer has exactly one
BadgeNumber, and a BadgeNumber denotes exactly one PoliceOfficer).
• A one-to-many association has a multiplicity 1 on one end and 0..n (also represented
by a star) or 1..n on the other. A one-to-many association between two classes (e.g.,
FireUnit and FireTruck) denotes composition (e.g., a FireUnit owns one or more
FireTrucks, a FireTruck is owned exactly by one FireUnit).
• A many-to-many association has a multiplicity 0..n or 1..n on both ends. A manyto-
many association between two classes (e.g., FieldOfficer and IncidentReport)
denotes that an arbitrary number of links can exist between instances of the two classes
(e.g., a FieldOfficer can write many IncidentReports, an IncidentReport can be
written by many FieldOfficers). This is the most complex type of association.
Interaction Diagrams
Interaction diagrams describe patterns of communication among a set of interacting objects.
An object interacts with another object by sending messages. The reception of a message by an
object triggers the execution of a method, which in turn may send messages to other objects.
Arguments may be passed along with a message and are bound to the parameters of the
executing method in the receiving object. In UML, interaction diagrams can take one of two
forms: sequence diagrams or communication diagrams.
Sequence diagrams represent the objects participating in the interaction horizontally and
time vertically. For example, consider a watch with two buttons (hereafter called 2Bwatch).
Setting the time on 2Bwatch requires the actor 2BWatchOwner to first press both buttons
simultaneously, after which 2Bwatch enters the set time mode. In the set time mode, 2Bwatch
blinks the number being changed (e.g., the hours, minutes, seconds, day, month, or year).
Initially, when the 2BWatchOwner enters the set time mode, the hours blink. If the actor presses
the first button, the next number blinks (e.g, if the hours are blinking and the actor presses the
first button, the hours stop blinking and the minutes start blinking). If the actor presses the
second button, the blinking number is incremented by one unit. If the blinking number reaches
the end of its range, it is reset to the beginning of its range (e.g., assume the minutes are blinking
and its current value is 59, its new value is set to 0 if the actor presses the second button). The
actor exits the set time mode by pressing both buttons simultaneously
State Machine Diagrams
A UML state machine is a notation for describing the sequence of states an object goes through
in response to external events. UML state machines are extensions of the finite state machine
model. On one hand, state machines provide notation for nesting states and state machines (i.e.,
a state can be described by a state machine). On the other hand, state machines provide notation
for binding transitions with message sends and conditions on objects.

A state is a condition satisfied by the attributes of an object. A transition represents a change of state
triggered by events, conditions, or time.

Activity Diagrams
UML activity diagrams represent the sequencing and coordination of lower level behaviors. An
activity diagram denotes how a behavior is realized in terms of one or several sequences of activities and
the object flows needed for coordinating the activities. Activity diagrams are
hierarchical: an activity is made out of either an action or a graph of subactivities and their
associated object flow. Rounded rectangles represent actions and activities. Edges between activities
represent control flow. An activity can be executed only after all predecessor activities
completed.

Project Organization Concepts

• Project Organizations
• Roles
• Tasks and Work
• Schedule

Project Organizations
An important part of any project organization is to define the relationships among participants
and between them and tasks, schedule, and work products. In a team-based organization
(Figure 3-3), the participants are grouped into teams, where a team is a small set of participants
working on the same activity or task. We distinguish teams from other sets of people, in
particular groups and committees. A group, for example, is a set of people who are assigned a
common task, but they work individually without any need for communication to accomplish
their part of the task. A committee is comprised of people who come together to review and
critique issues and propose actions.
Project participants interact with each other. The three major types of interaction in a
project are:
• Reporting. This type of interaction is used for reporting status information. For
example, a developer reports to another developer that an API (Application
Programmer Interface) is ready, or a team leader reports to a project manager that an
assigned task has not yet been completed.
• Decision. This type of interaction is used for propagating decisions. For example, a
team leader decides that a developer has to publish an API, a project manager decides
that a planned delivery must be moved up in time. Another type of decision is the
resolution of an issue.
• Communication. This type of interaction is used for exchanging all the other types of
information needed for decision or status. Communication can take many flavors.
Examples are the exchange of requirements or design models or the creation of an
argument to support a proposal. An invitation to eat lunch is also a communication.

Roles
A role defines the set of technical and managerial tasks that are expected from a participant or team. In a
team-based organization, we assign tasks to a person or a team via a role. For example, the role of tester of
a subsystem team consists of the tasks to define the test suites for the subsystem under development, for
executing these tests, and for reporting discovered defects back to the developers.
In a software project we distinguish between the following four types of roles: management roles,
development roles, cross-functional roles, and consultant roles (Figure 3-7).
Management roles (e.g., project manager, team leader) are concerned with the organization and execution
of the project within constraints. We describe this type of role in more detail in Chapter 14, Project
Management.
Development roles are concerned with specifying, designing, and constructing subsystems. These roles
include the analyst, the system architect, the object designer, the implementor, and the tester.
Cross-functional roles are concerned with coordination among teams. Developers filling these roles are
responsible for exchanging information relevant to other teams and negotiating interface details. The cross-
functional role is also called liaison. The liaison is responsible for disseminating information along the
communication structure from one team to another. In some cases (such as the API engineer), a liaison
functions as a representative of a subsystem team and may be called to resolve inter-team issues. There are
four types of liaisons:
• The API engineer is responsible for the interface definition of the assigned subsystem.
The interface has to reflect the functionality already assigned to the subsystem and to accommodate the
needs of the dependent subsystems. When functionality is traded off with other subsystems, resulting in
subsystem changes, the API engineer is responsible for propagating changes back to the subsystem team.
• The document editor is responsible for integrating documents produced by a team. A document editor
can be seen as a service provider to other teams that depend on a given subsystem team. A document editor
also manages information released internally to the team, such as the meeting agendas and minutes.
• The configuration manager is responsible for managing different versions of documents, models, and
code produced by a team. For simple configuration management policies (e.g., single hardware platform,
single branch), this role may be assumed by the team leader.
• A tester is responsible for ensuring that each subsystem works as specified by the designer. Often,
development projects have a separate team responsible only for testing. Separating the roles of designer,
implementor, and tester leads to more effective testing.
Consultant roles are concerned with providing temporary support in areas where the project participants
lack expertise. The users and the client act in most projects as consultants on the application domain.
Technical consultants may bring expertise on new technologies or methods. Non-technical consultants can
help to address legal and marketing issues. We distinguish the following types of consultant roles.
• The client, also called customer, is responsible for the formulation of scenarios and the requirements.
This includes functional and nonfunctional requirements, as well as constraints. The client is expected to
be able to interact with the other developers.
• The end user is the person who will be using the delivered system. Sometimes the project does not have
access to an end user, or the end user is still unknown. In this case, the end user is represented by the client
or even developer of the system.
• The application domain specialist is responsible for providing domain knowledge about a specific
functional area of the system. Whereas the client has a global view of the required functionality, the
application domain specialist has detailed knowledge of a specific problem area.
• The solution domain specialist is responsible for providing knowledge about solutions to implement the
system. This can include the development method, the process, implementation technology, or the
development environment.
3.3.3 Tasks and Work Products
A task is a well-defined work assignment for a role. Groups of related tasks are called activities.
The project manager or team leader assigns a task to a role. The participant who is assigned the role carries
out the task, and the manager monitors its progress and completion. A work product is a tangible item that
results from a task. Examples of work products include an object model, a class diagram, a piece of source
code, a document, or parts of documents. Work products result from tasks, are subject to deadlines, and
feed into other tasks. For example, the test planning activity for the database subsystem results in a work
product including a number of test suites and their expected results.

Schedule
A schedule is the mapping of tasks onto time: each task is assigned start and end times. This allows us to
plan the deadlines for individual deliverables. The two most often used diagrammatic notations for
schedules are PERT and Gantt charts [Gantt, 1910]. A Gantt chart is a compact way to present the
schedule of a software project along the time axis. A Gantt chart is a bar graph on which the horizontal axis
represents time and the vertical axis lists the different tasks to be done. Tasks are represented as bars whose
length corresponds to the planned duration of the task.
Project Communication Concepts
Planned Communication
Planned communication events are scheduled points in time during which participants exchange
information on a specific topic or review a work product. Such events are formalized and structured to
maximize the amount of information communicated and to minimize the time participants spend on
communication. Typical planned communication events include
• Problem presentation
• Client reviews
• Project reviews
• Peer reviews
• Status reviews
• Brainstorming
• Releases
• Postmortem reviews.

Unplanned Communication
We call the communication resulting from such crises unplanned communication events. They include
• Requests for clarification
• Requests for changes
• Issue resolution.
We describe unplanned communication events in more detail next.
Request for clarification
Requests for clarification represent the bulk of the communication among developers, clients, and users.
Requests for clarification are unplanned. A participant may request clarification about any aspect of the
system that seems ambiguous. Requests for clarification may occur during informal meetings, phone calls,
E-mail, or any other communication mechanism available to the project. Situations in which most
information needs are handled through requests for clarifications are symptoms of a defective
communication infrastructure. Such projects often face serious failures downstream resulting from
misunderstandings and missing and misplaced information.

Request for change

During a request for change, a participant reports a problem and, in some cases, proposes solutions. The
participant reports a problem with the system itself, its documentation, the development process, or the
project organization. Requests for change are often formalized when the number of participants and the
system size is substantial.
Issue resolution
Once problems have been reported and solutions proposed and evaluated, a single solution must be
selected, communicated, and implemented. A flat organization may select a solution through the
brainstorming process.

Communication Mechanisms
A communication mechanism refers to a tool or procedure that can be used to transmit and receive
information and support a communication event. Smoke signals and fax machines are communication
mechanisms. Communication mechanisms are synchronous if they require both sender and receivers to be
available at the same time. Otherwise, communication mechanisms are called asynchronous. Smoke
signals are synchronous, whereas fax machines are asynchronous

Organizational Activities
We now examine the activities of a developer when joining a project organization and its communication
infrastructure. The activities include
• Joining a Team (Section 3.5.1)
• Joining the Communication Infrastructure (Section 3.5.2)
• Attending Team Status Meetings (Section 3.5.3)
• Organizing Client and Project Reviews (Section 3.5.4).

Joining a Team
During the project definition phase, the project manager identified a subsystem team for each subsystem
in the initial decomposition of the software architecture. Additionally, crossfunctional teams (e.g.,
architecture team, integration team) are formed to support the subsystem teams. Each team has a team
leader who was also already selected during the project definition phase. An important activity during the
project start phase is now the assignments of participants to teams.
Joining the Communication Infrastructure
Two sets of forums are created to support project and team communication, respectively. Members
subscribe to all project forums and to their team’s forums. Project forums include
• Announce. Major events (e.g., review agendas, releases) are announced by management by posting to this
forum. Only management can post announcements to this forum; project members can post replies and
read all documents.
• Discuss. Project-level requests for clarification and requests for change are posted in this forum.
Discussion about the requests (e.g., arguments and alternate solutions) are posted as replies to the original
messages. All project members can post to this forum and read its documents.
• Issues. Open issues and their current state are posted in this forum. All project members can post to this
forum and read its documents. Documents. The latest versions of the project deliverables (e.g.,
Requirements Analysis
Document, System Design Document) and other internal project documents (e.g.,
Software Project Management Plan) are posted in this forum. Only the documentation team can post
documents to this forum. All project members can post replies (i.e., annotations to the documents) and read
the documents.
• Equipment list. This forum contains descriptions of equipment and its status (e.g.,
availability, current borrower). Only the equipment manager can post to this forum.

Attending Team Status Meetings

An important part of a software project is the weekly team meeting. It allows all teams to participate in
status reviews, brainstorming, and issue resolution. them are familiar with formal meeting roles and
procedures. Management takes the opportunity of the first weekly team meeting to introduce meeting
procedures, explain the importance of these procedures, and motivate team members in their use. Figure 3-
24 displays the agenda posted by the management for the first meeting.

Organizing Client and Project Reviews

Client reviews are conducted after the release of the requirements analysis document and after the delivery
of the system. Project reviews are conducted to review the system design documents, the detailed object
design, and the test. A project review may also be conducted before delivery as a dry run for the client
acceptance test.