Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
Therefore, in summary: ■ the product of a throwaway prototype is a specification ■ the product of an evolutionary prototype is a system. 23.4 ● Throwaway prototyping 23.4 Throwaway prototyping 305 The starting point for throwaway prototyping is an outline specification for the software. A throwaway prototype implements only those requirements that are poorly understood. It is discarded after the desired information is learned. After the prototype is complete, the developer writes a full specification, incorporating what was learned, and then constructs a full-scale system based on that specification. Thus the purpose of throwaway prototyping is the formulation of a validated specification. Throwaway prototyping is sometimes called rapid prototyping and as the name suggests, a rapid prototype should cost very little and take very little time to develop. The emphasis is on using whatever methods are available to produce a system that can be demonstrated to the user. Typically the only noticeable difference between the prototype and the desired system is its performance, or in the volumes of data that it handles. Rapid prototyping seems to contradict the idea of using systematic, careful methods during development; a prototype is produced in as quick (and perhaps as dirty) a manner as possible. To be effective, throwaway prototyping is carried out within a systematic framework. An overview of throwaway prototype development is shown in Figure 23.1. The stages of throwaway prototyping are: 1. draw up an outline specification – the first step in throwaway prototyping is the creation of an initial, often partial, specification. This specification contains areas of uncertainty. 2. establish objectives – what is the prototype to be used for? What aspects of the proposed system should it reflect? What can be learned from the prototype? The objective may be to develop a system to prototype the user interface, to validate functional requirements, to explore uncertain new technologies or to demonstrate the feasibility of the application to management. The same prototype cannot meet all objectives. The areas that are most often prototyped are the user interface, and uncertain or vague functions. 3. select functions – the next stage is to decide what to put into and what to leave out of the prototype. This is determined by the objectives of the system. If the purpose of prototyping is to clarify users’ requirements, then the uncertain areas are the candidates for prototyping. The development of a working model allows the developers to make sure that the solution they are proposing will satisfy the requirements and perform effectively. Depending on the objectives, it may be decided to prototype all system functions but at reduced level. Alternatively a subset of system functions may be included in the prototype.
306 Chapter 23 ■ Prototyping Draw up an outline specification [User happy] Figure 23.1 Throwaway prototyping Construct prototype Check with user Deliver the specification [User requires change] Refine prototype 4. construct prototype – speed and cost of construction of the prototype is crucial. Fast, low-cost construction is normally achieved by ignoring the normal quality requirements for the final product (a “quick and dirty” approach), unless this is in conflict with the objectives. 5. evaluate (check with the user) – the users use the prototype. This is more effective than watching a demonstration of the software. During evaluation, inconsistencies and shortcomings in the developer’s perception of the customer requirements are uncovered. The prototype acts as an effective communication medium between the developer and customer. 6. iterate (refine) – the prototype is rapidly modified, evaluation is carried out and the process repeated until the prototype meets the objectives (usually an agreed specification). 7. deliver the specification – the product of the prototyping process is a specification that meets the users’ requirements. Since the working prototype has been validated through interaction with the client, it is reasonable to expect that the resultant specification document will be correct. When the requirements are clearly established, the prototype is thrown away. At this stage, a different software process model, such as the waterfall model, is employed to develop the software.
- Page 277 and 278: 254 Chapter 17 ■ Software robustn
- Page 279 and 280: 256 Chapter 17 ■ Software robustn
- Page 281 and 282: 258 Chapter 17 ■ Software robustn
- Page 283 and 284: 260 Chapter 18 ■ Scripting GNU/Li
- Page 285 and 286: 262 Chapter 18 ■ Scripting In sum
- Page 288: PART D VERIFICATION
- Page 291 and 292: 268 Chapter 19 ■ Testing We begin
- Page 293 and 294: 270 Chapter 19 ■ Testing within a
- Page 295 and 296: 272 Chapter 19 ■ Testing Test num
- Page 297 and 298: 274 Chapter 19 ■ Testing if (a >=
- Page 299 and 300: 276 Chapter 19 ■ Testing 3. apply
- Page 301 and 302: 278 Chapter 19 ■ Testing made con
- Page 303 and 304: 280 Chapter 19 ■ Testing 19.3 Dev
- Page 305 and 306: 282 Chapter 19 ■ Testing 19.2 The
- Page 307 and 308: 284 Chapter 20 ■ Groups The term
- 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 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 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
306 Chapter 23 ■ Prototyping<br />
Draw up an outline<br />
specification<br />
[User happy]<br />
Figure 23.1 Throwaway prototyping<br />
Construct<br />
prototype<br />
Check with<br />
user<br />
Deliver the<br />
specification<br />
[User requires change]<br />
Refine<br />
prototype<br />
4. construct prototype – speed and cost of construction of the prototype is crucial. Fast,<br />
low-cost construction is normally achieved by ignoring the normal quality requirements<br />
<strong>for</strong> the final product (a “quick and dirty” approach), unless this is in conflict<br />
with the objectives.<br />
5. evaluate (check with the user) – the users use the prototype. This is more effective<br />
than watching a demonstration of the software. During evaluation, inconsistencies<br />
and shortcomings in the developer’s perception of the customer requirements are<br />
uncovered. The prototype acts as an effective communication medium between the<br />
developer and customer.<br />
6. iterate (refine) – the prototype is rapidly modified, evaluation is carried out and<br />
the process repeated until the prototype meets the objectives (usually an agreed<br />
specification).<br />
7. deliver the specification – the product of the prototyping process is a specification<br />
that meets the users’ requirements. Since the working prototype has been<br />
validated through interaction with the client, it is reasonable to expect that the<br />
resultant specification document will be correct. When the requirements are<br />
clearly established, the prototype is thrown away. At this stage, a different software<br />
process model, such as the waterfall model, is employed to develop the<br />
software.
Change language