Software Engineering For Students: A Programming Approach Part 37 pdf

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.. The UP consists of four phases: inception,

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 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 strucarchitec-ture 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

■ 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 runntrain-ing 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 incepelabora-tion and transielabora-tion 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

Elaboration

Construction

Transition Inception

Figure 27.1 The phases of the unified process

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

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, repeataccommodat-edly assess-ing the cost of changes and makassess-ing 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

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

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

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

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.

F PROJECT MANAGEMENT

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 Teams

This chapter explains:

■ the principles behind team working

■ how functional teams and project teams operate

■ how the chief programmer team operates