A PROTOTYPING METHODOlOGY AND lTS TOOl

Paul Tavolato and Karl Vincena

Technical University
Institut fûr Praktische Informatik

Argentinierstr. 8/180
A - 1040 Wien
Austria

Abstract

Af ter explaining some reasons for the prototype-approach to software development and
af ter giving a short classification of such approaches this paper tries to clarify
the concept of PROTOTYPING. We suggest a clear distinction between a MODEL and a
PROTOTYPE. Based on this distinction a new methodology of software development making
use of models and a prototype is presented. The application of this methodology needs
an interactive and highly flexible programming environment and a set of special soft-
ware tools.

The authors suggest the use of an APl environment and describe a prototyping tool -
APE (Application Prototype Environment) - in this paper. Af ter that an example of the
application of this methodology is given and experiences are reported.

Keywords: Software engineering, prototyping, software tools

1. Some General Notes on Software-Prototyping

1.1 Why Prototypjng?

In recent years prototyping has appeared on the software-engineering scene as an

alternative to the traditional software life-cycle concept. So what is wrong with the
life-cycle concept giving need for an alternative?

Exaggerating a bit one could say that in the traditional life-cycle concept there is,
one phase in the beginning - namely requirements analysis - wh ere the user is allowed
to say what he wants. Af ter that the software engineers do their job and deliver
- usually some months af ter the deadline - the final product. Practlce shows that it
doesn't work this way. The users do not know exactly what they want in the beginning,
what they say they want is not consistent, the software engineer misunderstands the
user and the requirements change over time. There are numerous jokes about this

R. Budde et al. (eds.), Approaches to Prototyping

© Springer-Verlag Berlin Heidelberg 1984
 435

problem roaming the scene.

In short: the life-cycle concept assumes that there is a stable set of requirements
at the beginning of the project; that these requirements can be written down as un-
ambiguous and consistent; and that they don't change during the rest of the software
development. In most cases this assumption does not hold.

Additionally one can look at it from a quantitative point of view: A fairly common
distribution of effort for the development and operation of software is as follows
[ZELKOWITZ79]:

.------- - - - Module- and Inte-

gration Test 15%
~..----Code 7%

A=1M'fIr--- Des i gn 5 %

Requirements and
Specifications 6%

- - - Maintenance 67%

Fig.1: Distribution of effort for the development of software.

This means: most of the capacity (personnel and other resources) is used for cor-
recting errors, adapting programs to changing environments, refining programs for
effectiveness and for user-demanded enhancements.

Taking a closer look at errors reveals the following situation (Source: Tom De Marco,
1978)

r---- - Requirements 56%

Other 10%

_L..-- -- Code 7%
Design 27%

Fig.2: Origin of errors.

436

r - - - R e qu i rements 82%

ill,===COde
O t her 4 %

1%
Des i gn 13%

Fig.3: Co st of fixing these errors.

In short: Most of the errors (S6?) are committed during requirements analysis; and
those errors are the most expensive to correct! Thus analyzing and specifying the
requirements of a system is THE crucial task in software engineering.

This means that we need techniques and methods to improve the analysis and specifi-
cation of system requirements. We need something that helps the user to find out wh at
he really wants, helps the software engineer to clarify requirements and validate
functional specifications.

It is generally understood that a high degree of participation of the endusers is

needed to improve requirements analysis. This can be achieved - among others - by
giving the user the possibility of hands-on experience with a working system. Such
experiences are extremely motivating for the user and provide him with an opportunity
of learning a lot about his requirements.

The methods, techniques and tools proposed for such improvements are generally
summarized under the not ion of prototyping.

1. 2 Overview of Prototyping Approaches

In scann i ng the scientific literature on SOFTWARE-PROTOTYPING one finds out that the
word prototyping is used rather freely for very different concepts (see for example
[ZELKOWITZ82]). On taking a closer look three different methodological approaches are
termed prototyping:
 437

• Plug-in strategy or incremental delivery approach

• Evolutionary development method

• Throw-it-away approach.

This is of course a somewhat generalizing classification ([FLOYD] gives a different,

less technical, and more purpose-oriented classification) but it serves its purpose
of clearing up methodological misunderstandings. A similar classification was given
by [GILB]. [PATTON] identifies the second and third approach, [BALLY] the first and
second.

The plug-in strategy or incremental delivery approach assumes a conventional

software-life-cycle procedure, up to and including functional specifications. Then
parts of the system are finished and delivered one af ter the other. The user gets a
system which is slowly growing by more and more parts being PLUGGED-JN. The experi-
ences of the user with the initially delivered parts might have effects on the imple-
mentation of successively delivered parts. This strategy incorporates only a small
portion of the original prototyping idea and is restricted to systems which can be
split into meaningful operational parts.

The evolutionary development method assumes that a prototype (a first system version)
is built and delivered to the user for experimentation; then this prototype is modi-
fied in close co-operation between the enduser and the analyst in a step-by-step
fashion to incorporate the experiences of the experimentation. This is done in such a
way that the prototype evolves gradually into the final product. The approach is
primarily iterative. The problem with this evolutionary development is that of ten
modifications really mean a redesign of the basic system architecture (and this is no
more compatible with a GRADUAL EVOLUTJOh).

Tne throw-it-away approach assumes that a rapid prototype is constructed and

delivered to the user for experimentation. Subsequently the prototype is adapted to
the user's actual requirements (which he is supposed to discover while experimenting
with the prototype); it is then regarded as a working - and formal - specification of
the user's requirements and taken as the basis for the development of the product ion
system. Afterwards the prototype is discarded. There is no agreement in the litera-
ture as to what extent the prototype should cover the desired system (containing all
functions or only some, simulating some processing or actually doing it, dealing with
real data or only with a restricted subset, having actual performance characteristics
or not, and so on). And this is the problem with the approach: if the prototype does
not cover some aspects of the final system, the requirements regarding these aspects
cannot be clarified or corrected; and a prototype covering all aspects of the final
system is practically the final system and cannot be constructed rapidly.
438

1.3 Clarification of Concepts

In order to avoid ambiguities and misunderstandings the concepts PROTOTYPE and MODEL
shall be clarified. We will mainly follow some considerations from [WILEDEN] and base
our definitions on semantic descriptions of the words found in dictionaries of the
English language.

Webster's Third New International Dictionary has - among others - the following
descriptions:

PROTOTYPE: the first full-scale model of a new type or design of furniture,

machinery or vehicle, e.g. a prototype airplane: the first full-scale
piloted flying model of a new type of airplane.

MODEL a usually miniature representation of something existing in nature or

constructed or to be constructed; also: structural design.

The keyword in the prototype definition is FULL-SCALE; the prototype is a first or

original example of something from which others will be reproduced, but has to be
fully functional and operational. Small scale copies of something which cover only
important aspects of the final product, however, should be termed MODEL. Nevertheless
one must have in mind that the word 'model' has a variety of different meanings
depending on the context. Therefore both words - PROTOTYPE and MODEL - must be used
very carefully and only with respect to the context.

Transfered to the software area the concept of a model can be used quite generally.
Any type of functional specifications (using text, formal specification languages or
graphical methods) can be cal led a model. On the other hand MODEL mayalso designate
an operational software system which - though somehow limited - gives an impression
of how the final system will work. (In some languages this sematic distinction is
reflected by the use of different words, e.g. in French: "mod~le" and "maquette" or
in Finnish: "kaava" and "malli".) For the purposes of this paper we shall, however,
restriet the term MODEL to mean a working model (a piece of software). The model may
not cover all functions of the modelled system, may work on a limited set of test
data only, may simulate some processing instead of actually carrying it out and so
on. The important issue with a model is that it can be constructed rapidly and modi-
fied instantly.

A prototype on the other hand must be a full-scale example of the final system. It
must not only cover all functions but it should also be possible to conduct per-
formance considerations with the prototype. We will use the term prototype ONLY for
such systems.
 439

One might argue that in software-engineering such a prototype is equivalent to the

final system, and hence a concept without useful meaning (as [WILEDEN] does).
Practice, however, shows that there are - not so small - differences between a full-
scale, fully functional, working version of a software system and a product ion qual-
ity version ready for operation and eventually distribution. These differences com-
prise issues like program quality, error rate, performance tuning and documentation.
Furthermore the prototype of a system which is to be operated in many places can be
used for clarifying the requirements of the organizational context necessary for the
system (organizational prototyping). Therefore an approach to software development
which makes use of a prototype is - at least in some situations - a meaningful and
promising undertaking.

2 A Software Development Methodology Usjng Models and Prototypes

In this chapter we are suggesting a software development methodology which makes use
of the concepts MODEL and PROTOTYPE as powerful development tools. The methodology is
primarily aimed at the development of large scale application systems which are going
to be production systems (generally in more than just one place).

As an integral part of the requirements analysis a MODEL is rapidly constructed. In

close co-operation with the user this model is modified and adapted to meet the
requirements (to the extent covered by the model). The model is generally less than
full size and lacks some characteristics of the final system. It may not cover all
functions, may be operable only on a restricted set of test data, may only simulate
some operations, and may not show realistic performance characteristics.

The construction of the model has to be accomplished really rapidly - that means in a
few days. Corrections are to be made instantly (in some minutes).

T~e enduser can gain first hands-on experience with the model and hence verify (at
least parts of) the requirements. Misunderstandings between the enduser and the soft-
ware engineer can be clarified, ambiguities eliminated and omissions corrected.

From this model a working prototype is constructed. The prototype - as opposed to the
model - is a first full-size version possessing all characteristics of the final sys-
tem: it is fully functional, uses real data and shows comparable performance charac-
teristics. The prototype is used to gain experience with the application, for user
education and training, for probationary operations and for performance analysis by
the software engineer.

According to the experiences with the prototype the final application system is
developed. If the prototype has no deficiencies at all it can be regarded as the fi-
nal system when supplemented by the appropriate tests and documentation. If there are
deficiencies, they can be corrected and the final system evolves gradually from the
440

prototype. If the functionality of the prototype is ok., but the performance is not
satisfactory, performance measurements and tuning can take place. Generally a lot
will have to be done to improve program quality and reliability.

In some cases a major redesign will be necessary and parts of the system (or the
whole) will have to be rewritten.

The main advantages of this methodology are that the requirements analysis and speci-
fication is improved immensely by the involvement and participation of the enduser.
Model and prototype are efficient means of communication between the enduser and the
software engineer - and his management. The intensive participation of the enduser
makes use of the creativity resources of these users and increases their responsibil-
ity for the final system and hence promotes overall system quality.

For the rapid construct ion of the model and the prototype a special toolset is
necessary. In the next chapter such a toolset based on APL is presented.

3 APE (Application Prototype Environment) - Overview

This chapter gives a short description of the facilities provided with Application
Prototype Environment. Further information on the Application Prototype Environment
IBM International Field Program (S796-RAB) can be found in [IBMa] and [IBMb].

3.1 Main Functions

The purpose of the functions in Applications Prototype Environment is to enable users

to easily design data move ment in an application. The functions are a set of COVER
FUNCTIONS that extend VS APL with very flexible screen and file handling capabilities
as commands to describe the communication of data. Further these functions relieve
the user from trivial problems in data conversion. The functions work on top of a set
of specifications describing the physical representation of data. Driven by these
specifications all movements of variables between files, display screens, and the VS
APL workspace are automated.

Figure 4 shows the basic functions related to screen and file handling in a general
interactive system. These functions are further described below.

For both display screen handling and file handling two groups of functions are
provided:

• A specification phase that describes the layout and appearance of display screens
and files.
• A set of functions that describe the operational characteristics of the appli-
cat ion.
 441

Data communication, as viewed from the application, is implemented through the

following operations.
NOTE: only a subset of the functions is briefly described here. The full set is
described in [18MbJ.

Based on Based on
DECLARATIONS PANELS

driven by driven by
DECLARE EDESIGN

~
DATA
--FGET
- A
P
P
-SINP---+
END
USERS
BASES -FGETHO L D - L

~
~
I

I
C SMOD
A
Ot her -FSET T
External I Display
Data 0 Terminal
- F S E T- - - N ---SOUT_

Fig.4: Formal Data Communication: The basic screen and file handling functiöns per-
formed in all interactive systems.

3.2 pisplay Screen Handljng

Specification Phase

EDESIGN The process of designing a panel

The display is always formatted according to the definitions in a PANEL. The panel
describes the fixed text and windows for variables to place on the display, when the
panel is employed. A graphics field on an alphanumeric panel can have achart func-
tion assigned. Attributes, e.g. color, are also part of the panel definition.

CDESIGN The process of designing achart function

A graphical presentation of data in a window on a panel can be created using aCHART

FUNCTION. The chart function describes the graphical principle, annotation, layout,
etc. to employ.
442

Operational Characteristics:

The following functions work under control of a panel, which is specified as argu-
ment:

SINP Reading input from a display

SOUT Writing data on a display

SMOD Placing data on a display for modification by the user.

3.3 File Handling

Specification Phase

DECLARE The process of designing the physical Layout and access method for given
data.

A fiLe is always formatted according to the definitions in a DECLARATION. The decLa-

ration describes the pLace, type and Length of variables within the LogicaL fiLe
record. Furthermore, the declaration describes the access method to employ wh en using
the fiLe. During the declare process the possible access paths to the physicaL file
are alsodefined.

Application Prototype Environment supports a range of access methods. For testing and
design purposes a file can be simuLated as a matrix in the APL workspace (called an
INSTORAGE FILE). A compLete dummy file is aLso provided that accepts all data written
to it and returns predefined information when referenced. These two features are
especiaLly usefuL for the rapid construction of modeLs.

OPERATIONAL CHARACTERISTICS: The operations shown in the Figure as seen from the Data
Bases are formaLly the same as those between the Application and the DispLay Termi-
nal. However, being controlled from the Application the logic is different.

The following functions work under control of a declaration. As argument for the
functions specify the name of an access path. Through the access it is determined
which file declaration to use:

FGET Retrieving information to the application

 443

FSET Defining information from the applieation

FGETHOLD Retrieving information for update in the applieation (reset by

redefining the information through FSET).

3.4 General Capabilities

The eommands will automatieally assoeiate fields in reeords with equally named
variables in the VS APL workspaee. Likewise, named windows in panels will automati-
eally be read and written to equally named variables in the workspaee.

When using the eommands as building bloeks for applieations in VS APL, the user ean
very easily design any interaetive applieation, whieh - of eourse - will be opera-
tional.

3.5 Online Tutorials

The availability of good online tutorials is a preeondition for intensive user

partieipation. Applieation Prototype Environment provides a general tutorial faeil-
ity. The basie assumption is, that A PAGE IN A MANUAL ean be viewed as a formatted
display: a panel. The applieation designer is allowed to plaee stubs in this appli-
eation that assoeiate a speeifie page in a manual (that is, a panel) with that part
of the applieation. All the display sereen handling funetions that ean await input
and aetions from the display operator, allow the operator to press the HELP key. The
panel named in the last stub passed in the applieation eode will then be displayed.
Further, the implementation allows the eonstruetion of a BOOK as being a set of
panels in a predefined sequenee.

The funetion used is:

The tutorial stub. Names the eurrent tutorial book and speeifie page.

4 Example

In the following the development of a small interaetive applieation using the before
mentioned methodology is briefly deseribed.
The applieation is an interaetive system for operating and maintaining a large list
of members of a eertain éommunity, namely a pension file of a Soeial Seeurity System.
The pension file eontained data about persons sueh as names, addresses, birthdays and
various other pension-related data. The transaetions required eomprised inquiry,
update, addition, and deletion of members, browsing the whole file and some types of
reealeulation of the pension amount af ter ehanging the pension base. The applieation
444

had to be embedded into the existing general information system at the user's site.

The requirements of the application had been provided by the user in form of a short
text and some oral communication. They were rather vague and general. As a first step
a working model of the application, including panel and file layout, was developed
using APL and APE. The file access was simulated with a so called IHSTORAGE FILE in-
stead of accessing actual keysequenced data sets. It worked on a limited set of
prepared test data provided by the user. This model was developed and tested by a
skilled VS APL and APE user in ONE day.

Af ter a short demonstration, the user was urged to experiment with it. This experi-
mentation and some discussion about their results led to a redesign of the model on
the NEXT day. The main changes in the model were the inclusion of a graphics solution
(which was not included in the user's original plans) and some variations of the in-
put panels.

Af ter agreement was reached with the user about the behaviour of the model, it was
upgraded to become a prototype of the desired application model. All functions were
fully implemented, input checks included, the IHSTORAGE FILE replaced by actual data
sets, and the system was applied to the actual data. The replacement of the simulated
file is no great problem as the file access interface is the same and need not be
changed in APE. The prototype was used to resolve some minor design problems and to
give valuable hints on system tuning. It was also used for training purposes of the
endusers.

The last step from prototype to product ion system included: a reimplementation of the
system in another programming language as it had to be run on a hardware where no APL
is available; the embedding of the application into the existing information system;
extensive testing; and the product ion of the necessary documentation.

The estimated effort for developing this simple application with a conventional
method using a higher programming language (like COBOL or PL/I) was ABOUT TWO
staffmonths. Using the methodology described in this paper the effort was not in-
creased but the product quality and user satisfaction reached a very high level which
led to considerably reduced maintenance costs.

5 Conclusions

Transfering concepts from other disciplines into a new one is of ten a meaningful and
helpful undertaking. But if the new one is a discipline that has to rely heavily on
communication and co-operation with other (older) disciplines - like computer
science - then great care must be taken in order to avoid misunderstandings. The con-
cepts MODEL and PROTOTYPE do have special meanings in the traditional engineering
sciences. So in transfering them to software engineering one should use them very
carefully and should not assign new meanings to them which are too far away from the
established ones. Nevertheless we think these two concepts can be transfered to soft-
ware engineering and lead to a practical software development methodology described
in this paper.

Summing up our experiences with this software development methodology leads to the
following statements:

A high degree of co-operation between users and the developers is necessary for
this methodology.

The financial advantages of the methodology are due to reduced maintenance costs.

In good system development the organizational environment of the application sys-

tem must not be left out; a prototype can be helpful in this issue.

For building models and prototypes a toolset embedded in a (very) high level lan-
guage is necessary.

APE plus APL is very well suited for modelling and prototyping systems with a
large amount of data movement and with operations that are easily described by
mathematical operations and algorithms.

Literature

BALLY, L., J. BRITTAN, AND K. WAGNER:

A Prototype Approach to Information Systems Design and Development.
Information and Management. 1 (1977).

FLOYD, C.:
A Systemat;c Look at Prototyp;ng.
(In this volume).

GILB, T.:
Evolyt;onary Deyelopment.
ACM SIGSOFT Software Engineering Notes. ~ (1981).

IBM:
Appl;cat;on Prototype Environment Ava;lab;l;ty Not;ce.
IBM Form. No. GB11-5668 (1982a).
446

IBM:
Application Prototype Environment Program Descriptjon and Operations Manual.
IBM Form. No. SB11-5669 (1982b).

PATTON, B.:
Prototyping - a Nomenclature problem.
ACM SIGSOFT Software Engineering Notes. ~ (1983).

WILEOEN, J. C.:
Prototype or Model?
in: ZELKOWITZ82.

ZELKOWITZ, M., A. SHAW, ANO J. GANNON:

Principles of Software Engineering and Design.
Prentice Hall 1979.

ZELKOWITZ, M., ANO M. BRANSTAO (EOS.):

Software Engineering Symposium: Rapid Prototyping.
Columbia, Maryland 1982.