Software Engineering For Students: A Programming Approach Part 34 pdf

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 fin

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

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?

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)

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

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

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

•

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?

Answers to self-test questions

23.1

23.2 Advantage: early validation of user requirements

Disadvantage: need for suitable tool

starting point unclear requirements outline specification

construction quick and dirty quality

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

CHAPTER

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

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

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

316 Chapter 24 ■Incremental development

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

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