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