Software Engineering For Students: A Programming Approach Part 37 pdf

338 Chapter 27 ■ The unified process
Meeting the user’s needs requires no explanation. The second aim of the UP recog-
nizes that there are always risks associated with a development. Examples are changes
in user requirements and deadline overruns for components of the software. These can
seriously disrupt a project or even cause it to be abandoned.
To meet its aims, the UP makes use of a number of techniques including use cases,
iteration and emphasis on the architecture of the software.
A use case describes (in natural language) a small self-contained function that the sys-
tem provides for the user. A collection of use cases specify the requirements for a sys-
tem. (Use cases were discussed in Chapter 4 on requirements engineering.)
The UP mechanism for coping with risk is to proceed iteratively. This means that an
initial plan is constructed. Then some small amount of development is carried out.
Next, the outcome is assessed. In the light of the evaluation, a new plan is devised (or,
in the worst case, the project is abandoned).
The UP also emphasizes getting the architecture of the software right. By architec-
ture is meant the grand-scale structure of the software. For example, in a web-based
solution, what components run on the server and what components run on the client?
What type of database is to be used?
In summary the method makes heavy use of:
■ use cases
■ iteration
■ software architecture.
The UP consists of four phases: inception, elaboration, construction and transition.
We will now explore what they involve.
The UP consists of four phases: inception, elaboration, construction and transition, as
shown in Figure 27.1. We shall see later that within each phase are a number of itera-
tions. The four phases are, in outline:
Phase 1, inception
This consists of a feasibility study to establish whether the proposed system is worth-
while. (We discussed how to carry out feasibility studies in Chapter 3.) An outline of the
major requirements is established. A decision is made to commit to the project, or not.

Phase 2, elaboration
During this phase:
■ the list of requirements is completed
■ the general architecture of the system is devised
27.3
●
Phases of the UP
BELL_C27.QXD 1/30/05 4:27 PM Page 338
27.4 Techniques 339
■ the major risks are identified and assessed
■ a plan for the development is drawn up and agreed.
Phase 3, construction
This is the actual system development.
Phase 4, transition
This phase means putting the system into use. This may involve such measures as train-
ing or running the new system in parallel with a former system. Other methods call this
phase implementation.
Usually the construction phase consumes the most effort, followed by the elabora-
tion phase. Both inception and transition usually take up much less effort.
The UP uses several practical techniques designed to ensure successful projects. They are:
Iteration
The UP proceeds in an iterative fashion in order to accommodate ongoing risks. We
discuss this in a separate section below.
27.4
●
Techniques
Elaboration
Construction
Transition
Inception

Figure 27.1 The phases of the unified process
BELL_C27.QXD 1/30/05 4:27 PM Page 339
340 Chapter 27 ■ The unified process
Use cases
Meeting user’s needs is accomplished by employing use cases to record user’s functional
requirements. Use cases also drive the project – the developers are always aware of the use
cases. Use cases are discussed in Chapter 4 on requirements engineering.
Focus on providing executable code
Many projects create pages of documentation – such as specifications, UML diagrams
and test schedules – at the expense of working code. The problem is that users do not
understand these products and cannot understand how they contribute to the product.
The UP emphasizes the overwhelming need to create and show the client demonstrable
products.
Establishing a working architecture early on
The architecture is the grand-scale structure of the software. The UP emphasizes the
need to devise a good structure early in the development process. Many current appli-
cations are internet based and this means that there is usually client software and server
software. But there are many options. One option is the balance of work between the
client and server. Other options are whether to use applets, servlets, RPC, CGI, ASP,
web services, etc. The choice of technologies will be determined by performance, inter-
operability, scalability, security, expertise and cost. The decision determines the archi-
tecture for the software.
Using components
Using such encapsulated components as Java beans, .Net components or simply classes
means that local changes do not disrupt the remainder of the software.
Establishing an effective team
In an effective team, developers communicate effectively and are committed to the
project. The UP recommends setting up a single project team, devoted to the project,
rather than using a number of functional teams. (These differences are discussed in
Chapter 28 on teams.)

Incorporating quality throughout
The main quality goals are to ensure that the software meets its user’s needs and works
properly. The UP aims to ensure quality by carrying out validation and verification at
every cycle.
BELL_C27.QXD 1/30/05 4:27 PM Page 340
27.6 Case study 341
Iteration is a major feature of the UP and it is the mechanism for controlling risks. The
UP recognizes that problems (risks) will arise as a project proceeds. Examples are:
■ changes to requirements – because they were recorded incorrectly in the first place
and because users change and clarify their ideas
■ the architecture of the software needs modification
■ implementation errors are discovered requiring correction
■ difficulty integrating with a legacy system.
If a software project takes large steps, then any problems are hidden for a long time – and
their effects can be devastating. If a project employs small steps, each concluding with an
evaluation, then progress is more visible and the effects of any changes can be accommodat-
ed more easily. Thus the UP accommodates change by taking small steps, repeatedly assess-
ing the cost of changes and making explicit decisions about whether to make changes.
We have seen that the UP consists of four phases. Each of the four phases of the UP
consists of one or more iterations. Smaller projects usually require fewer iterations and
bigger projects more iterations. Typically the inception phase might employ one itera-
tion, the elaboration phase two, the construction phase three and the transition two.
The number of iterations is carefully planned – as is the goal of each iteration. At the
end of every iteration, an assessment is carried out.
Each iteration consists of analysis, design, coding and testing. Earlier iterations
emphasize analysis and design, while later iterations emphasize coding and testing. Each
iteration produces working software that is part of the target system.
The ATM (Appendix A) is a medium-sized project, network based with many clients
and a server. At the outset of a project of this kind, the project manager can identify
a number of obvious risks. These threats are anything that might adversely affect the

project success, deadline or cost. These might include:
■ the specialized devices (e.g. the card reader) do not work according to the specification
■ the communications protocol between ATM and server does not function properly
■ requirements change
■ there is difficulty interfacing with the database on the server.
It is also likely that unforeseen eventualities will occur, for example, late delivery of
some of the specialized ATM hardware. However, small iterations mean that damage to
the project is controlled and limited.
27.6
●
Case study
27.5
●
Iteration
BELL_C27.QXD 1/30/05 4:27 PM Page 341
342 Chapter 27 ■ The unified process
The inception phase
The goal of this phase is to understand the scope of the project, build a business case
and obtain stakeholder agreement.
Understanding the scope involves interviewing the client and recording their require-
ments. The functional requirements are recorded as use cases and we saw in Chapter 4
on requirements how to accomplish this activity for the ATM system.
Building a business case means carrying out a calculation of the financial costs and
benefits, which was outlined (for the ATM) in Chapter 3 on the feasibility study. This
calculation reveals that the system is hugely cost effective.
Obtaining stakeholder agreement means checking with the identified groups that
they are happy and committed to the project. In the case of the ATM, the stakeholders
may include the client, the bank workers, the bank’s customers, the senior management
of the bank, the bank IT department and relevant public authorities. Let us assume that
these various groups are happy for the project to go ahead.

The elaboration phase
This involves completing the statement of requirements, devising the general architec-
ture of the system, identifying and assessing the major risks and drawing up and agree-
ing a plan for the development.
For the ATM, the user functions can be established and documented as use cases.
For the ATM, a decision about the division of labor between ATM software and
server software needs to be made. The protocol for the communication between ATMs
and server needs establishing. Then the architecture is checked by constructing a work-
ing skeletal system.
Now that the requirements are well established and the architecture is trustworthy,
there is greater certainty in the project. However, an assessment is made of any risks to
the project and plans made accordingly.
Now, a detailed plan for the remainder of the project can be drawn up.
The construction phase
This phase constitutes the actual construction of the software.
This consists of four iterations. The first is an implementation of the user interface
(with no functionality). This establishes that the design of the user interface is accept-
able. It also confirms that it will provide the desired functionality.
The second iteration is a program to interface with the database on the server, in
order to ascertain that a satisfactory connection can be made, providing the function-
ality required by the ATM application.
The next iteration is a full implementation of the system, but using only a single
ATM. This establishes that the system is technically feasible for a single user.
Finally a multi-user system is constructed.
This account of the four iterations assumes that all goes well. In practice, the assess-
ment at the end of an iteration might reveal that there is a problem. This would need to
be solved by such measures as rescheduling the project or using an alternate technology.
BELL_C27.QXD 1/30/05 4:27 PM Page 342
Summary 343
The transition phase

This phase means putting the system into use. It involves installing the ATM hardware,
the software and communication lines. It means arranging for the ATMs to be serviced,
supplied with cash and printer paper. It means installing the server software.
Rather than install a whole number of ATMs at once, it makes sense to install just
one in some convenient location to act as a beta test. This first iteration, once success-
fully concluded, is followed by the installation of multiple ATMs.
The UP is not a single process model. It is a framework from which a project manager
can select a process model suitable for a particular project. So the model can be applied
to large and small projects, involving a few developers or many.
27.7
●
Discussion
Summary
The UP is a process model that primarily aims to:
■ meet user requirements
■ accommodate risks.
The process consists of four phases:
1. inception
2. elaboration
3. construction
4. transition.
Each phase consists of one or more iterations. Each iteration consists of analysis,
design, coding and testing. The purpose of iteration is to accommodate risks.
The UP employs a number of techniques:
■ iteration
■ use cases
■ focus on providing executable code
■ establishing a working architecture early on
■ using components
■ establishing an effective team

■ incorporating quality throughout.
BELL_C27.QXD 1/30/05 4:27 PM Page 343
344 Chapter 27 ■ The unified process
27.1 Assess the UP.
27.2 Compare and contrast the UP with the waterfall model, extreme programming and the
spiral model.
27.3 Create an outline plan for developing each of the systems in Appendix A, using the UP.
27.4 Evaluate the UP using the following criteria:
■ capability to accommodate risk
■ capability to meet user requirements
■ capability to respond to changed requirements
■ visibility of the progress of the project.
27.5 Identify the main goals and the main techniques of each of the following process
models:
■ waterfall
■ spiral
■ prototyping
■ incremental
■ open source
■ XP
■ UP.
Exercises
•
Further reading
•
The following book clearly explains the RUP. It also compares it with waterfall, agile
methods and heavyweight approaches: Per Kroll and Philippe Kruchten, The Rational
Unified Process Made Easy, Addison-Wesley, 2003.
Another straightforward read: Philippe Kruchten, The Rational Unified Process, an
Introduction, Addison-Wesley, 3rd edn, 2004.

BELL_C27.QXD 1/30/05 4:27 PM Page 344
PART
F
PROJECT
MANAGEMENT
BELL_CPARTF.QXD 1/30/05 4:31 PM Page 345
BELL_CPARTF.QXD 1/30/05 4:31 PM Page 346
Software developers seldom work alone. More commonly, several developers share an
office, working on different projects or collaborating on larger projects. The process of
establishing requirements usually involves significant face-to-face meetings. So software
development is essentially a social activity.
This chapter is about structures that are formally set up to organize a team or group
of software developers.
We begin by analyzing some of the problems of group work. We go on to explain
techniques for software team organization – functional teams, project teams, chief pro-
grammer teams and OO teams.
Two major aspects of team activity are:
1. the communication between the people in the team
2. deciding who does what work.
These issues are now discussed in turn.
28.2
●
The principles of teams
28.1
●
Introduction
CHAPTER
28
Teams
This chapter explains:

■ the principles behind team working
■ how functional teams and project teams operate
■ how the chief programmer team operates.
BELL_C28.QXD 1/30/05 4:28 PM Page 347