Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
23.5 Evolutionary prototyping 307 Users should resist the temptation to turn a throwaway prototype into a delivered system that is put into use. The reasons for this are: 1. important system characteristics, such as performance, security and reliability, will probably have been ignored during prototype development 2. during the prototype development, the prototype will have been changed to reflect user needs. It is likely that these changes will have been made in an uncontrolled way and not properly documented other than in the prototype code 3. the changes made during prototype development will probably have degraded the architectural structure of the software. Therefore the software may be difficult and expensive to maintain. 23.5 ● Evolutionary prototyping This type of prototyping is based on the idea of developing an initial implementation, exposing it to user comment and refining it through repeated stages until an adequate system has been developed. To be effective, evolutionary prototyping is carried out within a systematic framework. Evolutionary prototype development is shown in Figure 23.2. Note the similarities and differences between this figure and Figure 23.1. Draw up initial specification [User happy] Figure 23.2 Evolutionary prototyping Construct prototype Check with user Deliver the working system [User requires change] Refine prototype
308 Chapter 23 ■ Prototyping The stages are: 1. requirements definition (initial specification) – a stage of thorough analysis is used to create an initial specification for the software. 2. prototype construction – a prototype is built in a quality manner, including design, documentation, and thorough verification. 3. evaluation (check with the user) – during evaluation, problems in the developer’s perception of the customer requirements are uncovered. The prototypes are the communication medium that enables the developer and customer to communicate with each other. 4. iteration (refine the prototype) – evaluation is carried out repeatedly until the prototype meets the objectives. The specification is updated with every iteration. The product is a fully working system. SELF-TEST QUESTION 23.1 What are the differences between throwaway and evolutionary prototyping? 23.6 ● Rapid prototyping techniques A throwaway prototype needs to be created quickly so that users can comment on it at an early stage. A prototype also needs to be altered quickly to incorporate the users’ views as the prototype changes to meet their requirements. What we really need is some magical tool that would enable us to create prototypes at high speed. But there are no magical tools. If there were, we would use them for everything. Instead we use whatever tools and methods that are suitable. Here are some techniques for fast prototyping. Use a high-level language High-level languages include many facilities which normally have to be built from more primitive constructs in other languages. Smalltalk is a language that can be used to prototype adventurous GUIs with very little programmer effort. A drawback of Smalltalk is that it can be a massive consumer of processor time and memory, so that after prototyping it may be necessary to rewrite the system in some other language. So Smalltalk may only be usable for throwaway prototyping. Visual Basic has features for rapid software development, including the capacity to create a GUI using drag-and-drop from a palette.
- 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 328 and 329: Therefore, in summary: ■ the prod
- 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
- Page 379 and 380: 356 Chapter 28 ■ Teams • Furthe
23.5 Evolutionary prototyping 307<br />
Users should resist the temptation to turn a throwaway prototype into a delivered<br />
system that is put into use. The reasons <strong>for</strong> this are:<br />
1. important system characteristics, such as per<strong>for</strong>mance, security and reliability, will<br />
probably have been ignored during prototype development<br />
2. during the prototype development, the prototype will have been changed to reflect<br />
user needs. It is likely that these changes will have been made in an uncontrolled<br />
way and not properly documented other than in the prototype code<br />
3. the changes made during prototype development will probably have degraded the<br />
architectural structure of the software. There<strong>for</strong>e the software may be difficult and<br />
expensive to maintain.<br />
23.5 ● Evolutionary prototyping<br />
This type of prototyping is based on the idea of developing an initial implementation,<br />
exposing it to user comment and refining it through repeated stages until an adequate<br />
system has been developed.<br />
To be effective, evolutionary prototyping is carried out within a systematic framework.<br />
Evolutionary prototype development is shown in Figure 23.2. Note the similarities<br />
and differences between this figure and Figure 23.1.<br />
Draw up initial<br />
specification<br />
[User happy]<br />
Figure 23.2 Evolutionary prototyping<br />
Construct<br />
prototype<br />
Check with<br />
user<br />
Deliver the working<br />
system<br />
[User requires change]<br />
Refine<br />
prototype