308 Chapter 23 ■ Prototyping 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 what- ever 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 pro- totype 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 pro- totyping 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. 23.6 ● Rapid prototyping techniques 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 pro- totype 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 proto- typing? BELL_C23.QXD 1/30/05 4:26 PM Page 308 23.6 Rapid prototyping techniques 309 Reuse components The time needed to develop a prototype can be reduced if many parts of the system can be reused rather than designed and implemented. Prototypes can be constructed quick- ly if there is a library of reusable components and some mechanism to combine the components into systems. The reusable components may also be used in the final sys- tem, thus reducing its development cost. An example of this approach to prototyping is found in the Unix operating system (Chapter 18 on Scripting). The success of Smalltalk as a prototyping language is as much due to its reusable component libraries as to the inbuilt language facilities. Use a stand-alone machine It is often possible to construct a system that appears realistic, but is in fact massively incomplete. For example, if a network solution is to be developed, a prototype running on a stand-alone computer is created. This simulates the complete system for the pur- pose of validation. But the developer is freed from considerations of networking, large data volumes and possible performance problems that would need to be considered in the production version of the system. Ignore error handling In many systems as much as one-half of the software is concerned with error handling. This includes: ■ validation of user data input from keyboards ■ handling input-output device errors ■ exception handling software ■ fault tolerant software. Omit features It may be that some features can simply be omitted in a prototype. Examples are log- ging software, security and authentication features. These components of a production- quality system can be significantly costly in development effort and so their omission makes construction of a prototype quicker. Ignore functionality This type of prototype is aimed simply at establishing an acceptable user interface. For example, suppose we were setting out to develop a new word processor (Appendix A). We could, very quickly, create a mock-up of what would appear on the screen, while the actual functions of the word processor are simply not implemented. This type of pro- totype is often used during the design of the user interface (see Chapter 5). BELL_C23.QXD 1/30/05 4:26 PM Page 309 310 Chapter 23 ■ Prototyping Advantages What are the advantages of prototyping? During requirements specification, the devel- oper can show the user a suggested working system at a very early stage. Users are not always certain what they want a system to do. It is difficult for users to understand prop- erly and be able to state detailed functional requirements unambiguously before they have an opportunity to experiment interactively with the options. A prototype gives the user a very clear picture of what the system will look like and what it will do. By exam- ining options in the various versions of the prototype, the users are stimulated to dis- cover requirements that they might not have thought of until after full implementation using any other method. The user is able to tell the developer their views about the sys- tem, and modifications can be made. The value lies in better communication between user and analyst and validation is carried out early in the life of the project. Thus pro- totyping can eliminate many of the requirement errors in the very early stages of a proj- ect. The greatest savings in time and effort stem from avoiding the work in changing a system that does not do what the user really wanted. Prototyping promotes a participatory approach to development, and when users are involved, they often gain confidence in a system. They see first hand the problems and errors, but they also see the mistakes being resolved quickly. The advantages of prototyping can be: ■ enables developers to cope with lack of clarity in requirements ■ gives the user the opportunity to change their mind before commitment to the final system ■ user requirements are easier to determine ■ systems are developed faster ■ development effort is reduced because the resultant system is the right system ■ maintenance effort is reduced because the system meets the users’ needs ■ end user involvement is facilitated ■ user-developer communication is enhanced ■ users are not frustrated while they wait for the final system, because they can see a working system ■ increased chance that a system will be more user friendly ■ systems are easier for end users to learn and use because users know what to expect ■ enables a system to be gradually introduced into an organization ■ facilitates user training while development is going on ■ increased customer satisfaction with the delivered software. The question about prototyping is whether the cost of constructing the prototypes is offset by the savings. 23.7 ● Discussion BELL_C23.QXD 1/30/05 4:26 PM Page 310 23.7 Discussion 311 Pitfalls For users, the problems of prototyping are: ■ because prototyping is carried out in an artificial environment, users may miss some of the shortcomings ■ undue user expectations – the ability of the developers to create a prototype quick- ly may raise undue expectations that the final system will soon be complete. They see a partial system and may not understand that it is not the finished system ■ inconsistencies between a prototype and the final system – if the prototype is a throwaway, the end product may not be exactly like the prototype. In other words, what the user sees may not be what the user gets ■ users who are never satisfied because they are given too much opportunity to change the development of the system. For software engineers, the problems can be: ■ incomplete analysis – because prototypes are produced quickly, developers may be tempted to plunge into prototyping before sufficient requirements analysis has taken place. This may result in a system that has a good user interface but is not properly functional. This is how the reputation of prototypes which are quick but dirty came about. ■ iteration is not easily accepted by some designers, because it necessitates discarding their own work ■ omission of non-functional requirements, since a prototype focuses only on func- tionality. The project management problems of using prototyping may be: ■ estimating, planning and managing a prototyping project can be difficult because it can be hard to predict how many iterations of prototyping will take place ■ procedures for change and configuration management may be unsuitable for con- trolling the rapid change inherent in prototyping ■ many project management structures are set up assuming a process model, like the waterfall model, that generates regular deliverables to assess progress. However, prototypes usually evolve so quickly that it is not cost effective to keep pace with the documentation. Maintenance of a system constructed using evolutionary prototyping can be difficult and costly because continual change tends to corrupt the structure of the prototype. Prototyping may not always be an appropriate technique, for example, in: ■ embedded software ■ real-time control software ■ scientific and engineering numerical computational software. BELL_C23.QXD 1/30/05 4:26 PM Page 311 312 Chapter 23 ■ Prototyping 23.1 Draw up a prototyping model for preparing a meal, including buying the ingredi- ents and washing up afterwards. Don’t forget to identify the product at each stage. 23.2 Draw up a prototyping model for a large civil engineering project, such as building a road bridge across the channel between England and France. Identify similarities and differences between this project and a large software development project. 23.3 Validation and verification are clearly important during software development. Identify where validation and verification are carried out in prototyping. 23.4 Compare and contrast throwaway with evolutionary prototyping. 23.5 Review the advantages of prototyping. 23.6 Review the techniques that are available for constructing a prototype easily and quickly. 23.7 Assess whether and how prototyping might be used in the development of each of the systems described in Appendix A. SELF-TEST QUESTION 23.2 Identify one advantage and one disadvantage of prototyping. Summary The central goal of prototyping is to satisfy users’ requirements. The key feature of the prototyping process model is the repeated demonstration of prototypes to users. There are two approaches to prototyping – evolutionary and throwaway: ■ in evolutionary prototyping an initial prototype evolves as requirements are clarified so that it becomes the final system ■ throwaway prototyping uses rapid techniques to construct prototypes that are thrown away once users’ requirements have been established. It is important to establish the goal of using prototyping as part of a particular project. Although the goal is usually clarifying requirements, prototyping can also be used to design the user interface, demonstrate feasibility, verify that new tech- nology will work or provide a training system. Exercises • BELL_C23.QXD 1/30/05 4:26 PM Page 312 Answers to self-test questions 313 23.8 Compare and contrast the process models waterfall, spiral, extreme programming and prototyping using the following criteria: ■ capability to accommodate risk ■ capability to respond to changed requirements ■ capability to meet user requirements. 23.9 How is prototyping different from hacking? Throwaway Evolutionary Answers to self-test questions 23.1 23.2 Advantage: early validation of user requirements. Disadvantage: need for suitable tool. product specification system starting point unclear requirements outline specification construction quick and dirty quality BELL_C23.QXD 1/30/05 4:26 PM Page 313 This chapter looks at approaches to developing software bit by bit. The appeal of these approaches is reduced risk and a product that appears (at least in part) earlier. The risks that can be accommodated include changed requirements and delays to deadlines. Piecemeal product delivery is a great morale booster and helps ensure that requirements are being met. Some of these approaches address the whole of software development, while others concentrate on system integration and testing. There are several approaches to incremental implementation: ■ top-down ■ bottom-up ■ middle-out ■ use case based. 24.1 ● Introduction CHAPTER 24 Incremental development This chapter: ■ explains the need for incremental development ■ explains how to carry out top-down development ■ explains how to carry out bottom-up development ■ explains how to carry out middle-out development ■ explains how to carry out use case based development. BELL_C24.QXD 1/30/05 4:26 PM Page 314 24.3 Test beds 315 Here is a possible scenario: a client and a developer establish a requirements specifica- tion and a deadline for some software. The two part company until some time later, near the deadline. Then they have this conversation: Client: “How is it going?” Developer: “Very well. It is 95% complete.” Client: “What can you show me.” Developer: “Well, er, nothing.” This is somewhat frustrating for the client. Some time has passed but there is noth- ing visible. There may well be some design documents, such as UML diagrams, but they are unintelligible to the client. The client has to continue to trust that the developer will deliver the goods. Incremental development avoids this unfortunate conversation. There is another problem scenario. Anyone who has ever written a sizeable program knows that if you code the whole thing, compile it and run it, there is a gigantic prob- lem of testing and debugging. Similarly with software, if all the components are put together simultaneously, it is almost impossible to locate the bugs. Instead some piece- meal strategy is essential. Why is it that system testing is so time-consuming? After all, if all the individual com- ponents work correctly, why don’t they all work when they are combined? The answer is, of course, that it is precisely in their interaction that errors will be exposed. For example, there may be a discrepancy in understanding the exact task of a method or the nature of the parameters to be supplied. Thus we have seen that there are problems with big bang approaches. We have established the need to construct software in an incremental fashion and we will look at four approaches. We will look at each of these in turn, after we have exam- ined the problem of test beds. When a bridge or a building is being constructed, scaf- folding is used. It has two purposes – to enable access to the structure and to support the structure. For example, an arched stone bridge needs considerable support as it is being built. Similarly, software needs support structures as it is being integrated. An early and essential task is to construct a test harness or test bed for individual components. This is specially constructed software whose sole function is to invoke a component under test in a way that is consistent with its eventual role in the com- plete system. A test bed consists of drivers to call the methods of the components, and stubs to substitute for methods not yet integrated into the testing. Once unit testing has been completed, further support software is required as the system is integrated. Rather than bring all the components together at once, which is a big bang approach, it is probably better to assemble them one by one. But then we need stubs to stand in for the missing components. 24.3 ● Test beds 24.2 ● Big-bang implementation BELL_C24.QXD 1/30/05 4:26 PM Page 315 Considerable time can be spent on the construction of test harnesses. Worse still, they are usually thrown away when testing is complete. This is like a carpenter who spe- cially makes a new set of tools to build a new house, and then destroys the tools when the house is complete. (The analogy is intended to demonstrate the waste of effort that is involved.) Finding out exactly where a fault is located is easier using incremental implementa- tion. This is because components are incorporated one at a time. Thus there is a high probability that any fault lies in the single new component or in its interface with the existing components This starts with the architectural design for the software. Top-down development is an incremental approach that starts with the top components of the software. Now object-oriented systems do not usually possess a top – object-oriented software does not naturally possess a hierarchical structure. But while most object-oriented systems are non-hierarchical, some are. Chapter 12 on software patterns describes an archi- tecture in which the software consists of layers. However, arguably, the user interface is the top-most component of object-oriented software. It is the layer of software that calls up the functionality provided by the remainder of the software. So top-down development starts with the implementation of the user interface. Stubs are used to stand in for called but as yet unwritten lower-level components. Test data is con- structed, the system is assembled and tested. An immediate outcome is that we can very quickly have something that works. Not only that but it is the most visible part of the system. We also can have something that can be demonstrated to the client as performing an imitation of the total system. Implementation proceeds by selecting lower-level components (formerly stubs) for coding and incorporation into the system. In general, at any stage in the development there are (see Figure 24.1): ■ higher-level components which have already been tested ■ the single component which is under test ■ stubs. The strengths of top-down implementation are: ■ drivers are not required (the system acts as its own drivers), so time is saved ■ there is an early visible (but non-functional) product ■ some components of the system are repeatedly tested. The weaknesses of top-down implementation are: ■ stubs are needed at nearly every stage ■ not all systems are hierarchical. 24.4 ● Top-down implementation 316 Chapter 24 ■ Incremental development BELL_C24.QXD 1/30/05 4:26 PM Page 316 24.5 Bottom-up implementation 317 Tested component Tested component Component under test Tested component Stub Stub Stub Figure 24.1 Top-down implementation This type of implementation starts with an architectural design for the software. Bottom-up implementation starts with the lowest-level components of the system. These are the components that everything else depends on, but that don’t use anything themselves. In an OOD design these are the shared, reusable classes that form a com- mon library for the application to use. In many systems this is the software that access- es the database. The bottom-up implementation starts with the lowest-level components of the sys- tem. These are the components that everything else uses, but that don’t use anything themselves. The first task is to construct a test bed for each component. Figure 24.2 shows two components at the lowest level of a system and their test beds. When the lowest level components have been tested in this manner, components are combined into subsystems that are tested in a similar manner, again using a test bed (Figure 24.3). The procedure continues until the complete system is finally assembled and tested as a whole. Bottom-up implementation suffers from the following drawbacks: ■ drivers are required during almost all the development 24.5 ● Bottom-up implementation Component 1 under test Component 2 under test Test bed 1 Test bed 2 Figure 24.2 Bottom-up testing of the lowest-level components BELL_C24.QXD 1/30/05 4:26 PM Page 317 . risk and a product that appears (at least in part) earlier. The risks that can be accommodated include changed requirements and delays to deadlines. Piecemeal product delivery is a great morale. handling software ■ fault tolerant software. Omit features It may be that some features can simply be omitted in a prototype. Examples are log- ging software, security and authentication features 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. 23.6 ● Rapid prototyping