Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
27.5 ● Iteration 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 accommodated more easily. Thus the UP accommodates change by taking small steps, repeatedly assessing 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 iteration, 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. 27.6 ● Case study 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 requirements. 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 architecture of the system, identifying and assessing the major risks and drawing up and agreeing 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 working 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 acceptable. 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 functionality 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 assessment 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.
- 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 360 and 361: CHAPTER 27 This chapter explains:
- Page 362 and 363: Figure 27.1 The phases of the unifi
- 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
- Page 410 and 411: 31.3 Case study - assessing verific
- Page 412 and 413: 31.5 A single development method? 3
342 Chapter 27 ■ The unified process<br />
The inception phase<br />
The goal of this phase is to understand the scope of the project, build a business case<br />
and obtain stakeholder agreement.<br />
Understanding the scope involves interviewing the client and recording their requirements.<br />
The functional requirements are recorded as use cases and we saw in Chapter 4<br />
on requirements how to accomplish this activity <strong>for</strong> the ATM system.<br />
Building a business case means carrying out a calculation of the financial costs and<br />
benefits, which was outlined (<strong>for</strong> the ATM) in Chapter 3 on the feasibility study. This<br />
calculation reveals that the system is hugely cost effective.<br />
Obtaining stakeholder agreement means checking with the identified groups that<br />
they are happy and committed to the project. In the case of the ATM, the stakeholders<br />
may include the client, the bank workers, the bank’s customers, the senior management<br />
of the bank, the bank IT department and relevant public authorities. Let us assume that<br />
these various groups are happy <strong>for</strong> the project to go ahead.<br />
The elaboration phase<br />
This involves completing the statement of requirements, devising the general architecture<br />
of the system, identifying and assessing the major risks and drawing up and agreeing<br />
a plan <strong>for</strong> the development.<br />
For the ATM, the user functions can be established and documented as use cases.<br />
For the ATM, a decision about the division of labor between ATM software and<br />
server software needs to be made. The protocol <strong>for</strong> the communication between ATMs<br />
and server needs establishing. Then the architecture is checked by constructing a working<br />
skeletal system.<br />
Now that the requirements are well established and the architecture is trustworthy,<br />
there is greater certainty in the project. However, an assessment is made of any risks to<br />
the project and plans made accordingly.<br />
Now, a detailed plan <strong>for</strong> the remainder of the project can be drawn up.<br />
The construction phase<br />
This phase constitutes the actual construction of the software.<br />
This consists of four iterations. The first is an implementation of the user interface<br />
(with no functionality). This establishes that the design of the user interface is acceptable.<br />
It also confirms that it will provide the desired functionality.<br />
The second iteration is a program to interface with the database on the server, in<br />
order to ascertain that a satisfactory connection can be made, providing the functionality<br />
required by the ATM application.<br />
The next iteration is a full implementation of the system, but using only a single<br />
ATM. This establishes that the system is technically feasible <strong>for</strong> a single user.<br />
Finally a multi-user system is constructed.<br />
This account of the four iterations assumes that all goes well. In practice, the assessment<br />
at the end of an iteration might reveal that there is a problem. This would need to<br />
be solved by such measures as rescheduling the project or using an alternate technology.