Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
CHAPTER 27 This chapter explains: ■ the aims of the unified process ■ the techniques involved in the unified process ■ how to use the unified process. 27.1 ● Introduction The unified process (UP) is a process model for developing software. In common with other available process models, it provides an overall plan for a software development project. It also incorporates some recommendations for the techniques to be used as part of the process. The UP provides a general purpose strategy that can be tailored for an individual project – large or small, straightforward or risky. The UP is sometimes known as the rational unified process or RUP after the company that first promoted it. The word “Rational” was the company name and, of course, it also implies rationality. The “Unified” part of its name derives from the same source as the unified modeling language (UML). The founders of UML, Booch, Rumbaugh and Jacobson, were formerly rivals, but later collaborated (and were then termed the three amigos) to devise UML and the UP. UML is the notation; the UP is the process. The UP is the most recent process model to be widely used. As we shall see, the UP incorporates many of the ideas we have met in other chapters in this book. 27.2 ● Overview UP primarily aims to: ■ meet user needs ■ accommodate risks. The unified process
338 Chapter 27 ■ The unified process Meeting the user’s needs requires no explanation. The second aim of the UP recognizes 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 system provides for the user. A collection of use cases specify the requirements for a system. (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 architecture 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. 27.3 ● Phases of the UP 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 iterations. The four phases are, in outline: Phase 1, inception This consists of a feasibility study to establish whether the proposed system is worthwhile. (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
- Page 309 and 310: 286 Chapter 20 ■ Groups Of course
- Page 311 and 312: 288 Chapter 20 ■ Groups • Exerc
- Page 314 and 315: CHAPTER 21 This chapter explains: 2
- Page 316 and 317: Stage Input Output 21.3 Feedback be
- Page 318 and 319: Summary The essence and the strengt
- Page 320 and 321: CHAPTER 22 This chapter: 22.1 ● I
- Page 322 and 323: 22.2 The spiral model 299 to try to
- Page 324 and 325: 22.4 ● Discussion Exercises 301 A
- Page 326 and 327: CHAPTER 23 Prototyping This chapter
- Page 328 and 329: Therefore, in summary: ■ the prod
- Page 330 and 331: 23.5 Evolutionary prototyping 307 U
- Page 332 and 333: Reuse components 23.6 Rapid prototy
- Page 334 and 335: Pitfalls For users, the problems of
- Page 336 and 337: Answers to self-test questions 313
- Page 338 and 339: 24.2 ● Big-bang implementation 24
- Page 340 and 341: Tested component Figure 24.1 Top-do
- Page 342 and 343: 24.7 ● Use case driven implementa
- Page 344 and 345: ■ middle-out ■ use case based.
- Page 346 and 347: SELF-TEST QUESTION 25.1 What is the
- Page 348 and 349: sharing of software or their own re
- Page 350 and 351: Summary 327 Inappropriate patches,
- Page 352 and 353: Further reading 329 Cathedral and t
- Page 354 and 355: These are qualified by the statemen
- Page 356 and 357: 26.3 Extreme programming 333 develo
- Page 358 and 359: SELF-TEST QUESTION 26.3 Which of th
- Page 362 and 363: Figure 27.1 The phases of the unifi
- Page 364 and 365: 27.5 ● Iteration 27.6 Case study
- Page 366 and 367: The transition phase Summary 343 Th
- Page 368: PART F PROJECT MANAGEMENT
- Page 371 and 372: 348 Chapter 28 ■ Teams The commun
- Page 373 and 374: 350 Chapter 28 ■ Teams Level of s
- Page 375 and 376: 352 Chapter 28 ■ Teams A chief pr
- Page 377 and 378: 354 Chapter 28 ■ Teams benefits o
- Page 379 and 380: 356 Chapter 28 ■ Teams • Furthe
- Page 381 and 382: 358 Chapter 29 ■ Software metrics
- Page 383 and 384: 360 Chapter 29 ■ Software metrics
- Page 385 and 386: 362 Chapter 29 ■ Software metrics
- Page 387 and 388: 364 Chapter 29 ■ Software metrics
- Page 389 and 390: 366 Chapter 29 ■ Software metrics
- Page 391 and 392: 368 Chapter 29 ■ Software metrics
- Page 393 and 394: CHAPTER 30 This chapter: 30.1 ● I
- Page 395 and 396: 372 Chapter 30 ■ Project manageme
- Page 397 and 398: 374 Chapter 30 ■ Project manageme
- Page 399 and 400: 376 Chapter 30 ■ Project manageme
- Page 401 and 402: 378 Chapter 30 ■ Project manageme
- Page 403 and 404: 380 Chapter 30 ■ Project manageme
- Page 405 and 406: 382 Chapter 30 ■ Project manageme
- Page 408 and 409: CHAPTER 31 This chapter: 31.1 ● I
338 Chapter 27 ■ The unified process<br />
Meeting the user’s needs requires no explanation. The second aim of the UP recognizes<br />
that there are always risks associated with a development. Examples are changes<br />
in user requirements and deadline overruns <strong>for</strong> components of the software. These can<br />
seriously disrupt a project or even cause it to be abandoned.<br />
To meet its aims, the UP makes use of a number of techniques including use cases,<br />
iteration and emphasis on the architecture of the software.<br />
A use case describes (in natural language) a small self-contained function that the system<br />
provides <strong>for</strong> the user. A collection of use cases specify the requirements <strong>for</strong> a system.<br />
(Use cases were discussed in Chapter 4 on requirements engineering.)<br />
The UP mechanism <strong>for</strong> coping with risk is to proceed iteratively. This means that an<br />
initial plan is constructed. Then some small amount of development is carried out.<br />
Next, the outcome is assessed. In the light of the evaluation, a new plan is devised (or,<br />
in the worst case, the project is abandoned).<br />
The UP also emphasizes getting the architecture of the software right. By architecture<br />
is meant the grand-scale structure of the software. For example, in a web-based<br />
solution, what components run on the server and what components run on the client?<br />
What type of database is to be used?<br />
In summary the method makes heavy use of:<br />
■ use cases<br />
■ iteration<br />
■ software architecture.<br />
The UP consists of four phases: inception, elaboration, construction and transition.<br />
We will now explore what they involve.<br />
27.3 ● Phases of the UP<br />
The UP consists of four phases: inception, elaboration, construction and transition, as<br />
shown in Figure 27.1. We shall see later that within each phase are a number of iterations.<br />
The four phases are, in outline:<br />
Phase 1, inception<br />
This consists of a feasibility study to establish whether the proposed system is worthwhile.<br />
(We discussed how to carry out feasibility studies in Chapter 3.) An outline of the<br />
major requirements is established. A decision is made to commit to the project, or not.<br />
Phase 2, elaboration<br />
During this phase:<br />
■ the list of requirements is completed<br />
■ the general architecture of the system is devised