1.2 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 it

Chapter 1 • Introduction to Software Engineering

into knowledge. Knowledge acquisition is not sequential, as a single piece

of additional data can

invalidate 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.

In this section, we describe in more detail software engineering from the

perspectives of

modeling, problem solving, knowledge acquisition, and rationale. For each

of these activities,

software engineers have to work under people, time, and budget

constraints. In addition, we

assume that change can occur at any time.

1.3 Software Engineering Concepts

So far, we have presented a high-level view of software engineering from

the perspectives of

modeling, problem solving, knowledge acquisition, and rationale. In this

section, we describe

the main terms and concepts we use throughout the book.2 A Project,
whose purpose is to

develop a software system, is composed of a number of Activities. Each

Activity is in turn

composed of a number of Tasks. A Task consumes Resources and produces

a WorkProduct. A

WorkProduct can be either a System, a Model, or a Document. Resources

are either

Participants, Time, or Equipment. A graphical representation of these

concepts is shown in

Figure 1-1. Each rectangle represents a concept. The lines among the
rectangles represent

different relationships between the concepts. For example, the diamond

shape indicates

aggregation: a Project includes a number of Activities, which includes a

number of Tasks.

The triangle shape indicates a generalization relationship; Participants,

Time, and Equipment

are specific kinds of Resources. Figure 1-1 is represented in the Unified

Modeling Language
(UML) notation. We use UML throughout the book to represent models of
software and other

systems. Intuitively, you should be able to understand this diagram

without full knowledge of the

UML semantics. Similarly, you can also use UML diagrams when
interacting with a client or a

user, even though they may not have any knowledge of UML. We describe
the semantics of

these diagrams in detail in Chapter 2, Modeling with UML.

2. As much as possible, we follow the definitions of the IEEE standards on

Software Engineering [IEEE Std. 610.12-

1990].

Software Engineering Concepts

1.3.1 Participants and Roles

Developing a software system requires the collaboration of many people

with different

backgrounds and interests. The client orders and pays for the system. The
developers construct

the system. 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.

Consider a TicketDistributor system:

Treating the development of this TicketDistributor as a software

engineering project,

Table 1-1 provides examples of roles for this example.

Figure 1-1 Software engineering concepts depicted as a UML class
diagram [OMG, 2009].

TicketDistributor is a machine that distributes tickets for trains. Travelers

have the option of

selecting a ticket for a single trip or for multiple trips, or selecting a time
card for a day or a week. The

TicketDistributor computes the price of the requested ticket based on the

area in which the trip will

take place and whether the traveler is a child or an adult. The

TicketDistributor must be able to

handle several exceptions, such as travelers who do not complete the

transaction, travelers who attempt

to pay with large bills, and resource outages, such as running out of
tickets, change, or power.

consumes

Project

Activity

WorkProduct Task Resources

Equipment

Time

Participant

Document

Model

System

is produced by *

**

Chapter 1 • Introduction to Software Engineering

1.3.2 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.

Table 1-1 Examples of roles in software engineering for the

TicketDistributor project.

Role Responsibilities Examples

Client The client is responsible for providing the highlevel

requirements on the system and for defining

the scope of the project (delivery date, budget,

quality criteria).

Train company that

contracts the

TicketDistributor.

User The user is responsible for providing domain

knowledge about current user tasks. Note that the

client and the user are usually filled by different

persons.

Travelers

Manager A manager is responsible for the work

organization. This includes hiring staff, assigning

them tasks, monitoring their progress, providing

for their training, and generally managing the

resources provided by the client for a successful

delivery.

Alice (boss)

Human Factors

Specialist

A human factors specialist is responsible for the

usability of the system.

Zoe (Human Computer

Interaction specialist)

Developer A developer is responsible for the construction of

the system, including specification, design,

implementation, and testing. In large projects, the

developer role is further specialized.

John (analyst), Marc

(programmer), & Zoe

(tester)a

Technical Writer The technical writer is responsible for the

documentation delivered to the client. A technical

writer interviews developers, managers, and users

to understand the system.

John

a. As TicketDistributor is a small project, Zoe fills both the human factor

specialist and the tester roles,

and John fills the analyst and the technical writer roles.

10

Software Engineering Concepts

1.3.3 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. Table 1-2

describes examples of work products for the TicketDistributor example.

1.3.4 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.

Table 1-2 Examples of work products for the TicketDistributor project.

Work product Type Description

Specification Deliverable The specification describes the system from

the user’s point of

view. It is used as a contractual document between the project

and the client. The TicketDistributor specification

describes in detail how the system should appear to the traveler.

Operation

manual

Deliverable The operation manual for the TicketDistributor is used by

the staff of the train company responsible for installing and

configuring the TicketDistributor. Such a manual describes,

for example, how to change the price of tickets and the

structure of the network into zones.

Status report Internal work

product

A status report describes at a given time the tasks that have

been completed and the tasks that are still in progress. The

status report is produced for the manager, Alice, and is usually

not seen by the train company.

Test manual Internal work

product

The test plans and results are produced by the tester, Zoe. These

documents track the known defects in the prototype

TicketDistributor and their state of repair. These documents

are usually not shared with the client.

11

Chapter 1 • Introduction to Software Engineering

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.

Table 1-3 describes examples of activities, tasks, and resources in

software engineering.
1.3.5 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.

For example, The user must be able to purchase tickets and The user
must be able to

access tariff information are functional requirements. The user must be

provided feedback in less

than one second and The colors used in the interface should be consistent
with the company

Table 1-3 Examples of activities, tasks, and resources for the

TicketDistributor project.

Example Type Description

Requirements elicitation Activity The requirements elicitation activity

includes

obtaining and validating requirements and domain

knowledge from the client and the users. The

requirements elicitation activity produces the

specification work product (Table 1-2).

Develop “Out of Change”

test case for

TicketDistributor

Task This task, assigned to Zoe (the tester) focuses on

verifying the behavior of the ticket distributor

when it runs out of money and cannot give the

correct change back to the user. This activity

includes specifying the environment of the test, the

sequence of inputs to be entered, and the expected

outputs.

Review “Access Online

Help” use case for usability

Task This task, assigned to John (the human factors

specialist) focuses on detecting usability issues in

accessing the online help features of the system.

Tariff Database Resource The tariff database includes an example of

tariff

structure with a train network plan. This example

is a resource provided by the client for

requirements and testing.

12

Software Engineering Concepts

colors are nonfunctional requirements. Other nonfunctional requirements

may include using

specific hardware platform for the system, security requirements, how the
system should deal

with failures and faults, and how to provide backward compatibility with
an old system that the

client is unwilling to retire.

1.3.6 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. UML (Unified Modeling Language [OMG,

2009]), the

notation we use throughout this book, is a notation for representing

object-oriented models. The

use of notations in software engineering is common and predates object-

oriented concepts. Data

flow diagrams [De Marco, 1978] is a notation for representing systems in

terms of data sources,
data sinks, and data transformations. Z [Spivey, 1989] is a notation for
representing systems

based on set theory.

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. Rationale management is a method for

justifying change.

Configuration management is a method for tracking change.

A methodology is a collection of methods for solving a class of problems

and specifies

how and when each method should be used. A seafood cookbook with a
collection of recipes is

a methodology for preparing seafood if it also contains advice on how

ingredients should be

used and what to do if not all ingredients are available. Royce’s

methodology [Royce, 1998], the

Object Modeling Technique (OMT [Rumbaugh et al., 1991]), the Booch

methodology [Booch,

1994], and Catalysis [D’Souza & Wills, 1999] are object-oriented

methodologies for developing

software.

Software development methodologies decompose the process into

activities. OMT

provides methods for three activities: Analysis, which focuses on

formalizing the system

requirements into an object model, System Design, which focuses on

strategic decisions, and

Object Design, which transforms the analysis model into an object model
that can be

implemented. The OMT methodology assumes that requirements have

already been defined and
does not provide methods for eliciting requirements. The Unified Software
Development

Process also includes an Analysis activity and treats System Design and
Object Design as a

single activity called Design. The Unified Process, unlike OMT, includes a
Requirements

Capture activity for eliciting and modeling requirements. Catalysis, while

using the same

notations as the Unified Process, focuses more on reuse of design and

code using patterns and

frameworks. All of these methodologies focus on dealing with complex

systems.