Software Engineering For Students: A Programming Approach Part 34 pdf

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