Ministry of Higher Education and Scientific Research

University of Technology
Computer Engineering Department

Prototyping
Information Systems
‫ﻧظم اﻟﻣﻌﻠوﻣﺎت‬

‫ وﺳﺎم ﻟؤي طﻲ‬: ‫اﺳم اﻟطﺎﻟب‬

‫ ﻣﻌﻠوﻣﺎت‬:‫اﻻﺧﺗﺻﺎص‬
‫ اﻟﺛﺎﻟﺛﺔ‬: ‫اﻟﻣرﺣﻠﺔ‬
‫ اﻟﻣﺳﺎﺋﻲ‬: ‫اﻟدراﺳﺔ‬
2020 / 9 / 2 : ‫ﺗﺎرﯾﺦ اﻟﺗﺳﻠﯾم‬

2019 - 2020
 ABSTRACT

Prototyping" is frequently cited as an effective alternative technic[ue to traditional

approaches for the development of systems. This paper reviews recent literature on the
subject and categorizes prototyping techniques that appear to be widely used, A large
number of tools have been used for prototyping and they are discussed in relation to
the technique employed and other factors in the programming environment.

INTRODUCTION

Although the concept of the prototype is widely referenced in the recent computing
literature, there appears to be little if any agreement on what a "prototype" is.
In broad terms, the prototype attempts to present the user of a system with a relatively
realistic view ofthe system as it will eventually appear.
Users are thus able to relate what they see in the form Of prototype directly to their
requirements.
The use of prototypes appears to have advantages in user communication but raises
other issues in system development.
Different, nontraditional development tools may be required; the initial cost for the
requirements phase ofthe development cycle may be greater; and there is the possibility
of loss of distinction between phases and the development process.
Despite such issues, there appears to be a growing consensus that prototypes form an
effective component of an application development methodology.

Prototypes and system requirements

It is well understood that undetected errors that occur in the requirements phase of
system development are the most costly to repair in later stages.
User approval of a requirement specification is mandated by most data processing
managements as a means of correcting the requirement specification.
Depending upon the application environment and the development methodology, the
user may have access to a variety of developer-produced materials before certifying
that his requirements have been correctly defined. Software blueprints'^* and SREM*^*
are examples of specialized languages as a part of tjhe users/developer interface for
real time applications.
These requirements languages
presuppose sophisticated user representatives operating within the development methodology.
In conventional data processing environments, user participants in the development
phase are normally middle managers, and reliance upon such specialized skills is not
appropriate.
describe other differences between environments that affect the user /developer interface.)
 Improved functional requirements

The prototype system reflects the developer's interpretation of the user's needs, captured
previously in either formal or informal communication.
When this communication has been distorted by various preconceptions or general
unfamiliarity with the environment on either side, the prototype will frequently reveal
how the misunderstanding will affect the product.
This is particularly necessary for users with limited exposure to information system
technology.
The degree to which the prototype uncovers errors in functional logic, in addition to
the range and type of function to be performed, is dependent on the particular technique
employed,

Improved interaction requirements

The interaction requirements for a system are not always directly addressed in requirements
specification. This is especially true if the clients are not the (direct) users.
While the system may contain the correct functions, the design of the user interface
may either discourage its use or introduce errors in usage.
A useful evaluative model for the user interface is Foley's*'^'** top-down interface
design model. This model partitions the interface structure into successively more
specific components: conceptual level, semantic level, syntactic level, and lexical level.
On the conceptual level one is concerned with the basic set of concepts underlying the
user's view of the application. An example of a flaw in requirements at this level occurred
in our development of a small application in which the recjuirements document specified
certain files and certain tables of code interpretation.
When the users began to interact with a preliminary version of the system, it became
clear that the developer had conceptually separated the files and the tables, but the
users did not distinguish them.
They were surprised when the tables failed to function as files.
The semantic level deals with the information content that must pass between the user
and the (machine) system, without specific regard for its format.
When working through a demonstration, the user frequently notes that information
is being requested that is not applicable to a given transaction type; Another common
flaw at this level is a lack of information from the system for help or error recovery.
While a
prototype need not be expected to embody all the assistance features of the final program
product, the developer can note where more information is likely to be needed.
The syntactic level deals with the structure and format of the interactions, including
command syntax and screen layouts.
Typical corrections to be incorporated include decreased space for titles, movement
of total lines, syntax allowing for multiple report requests, etc.
 A CLASSIFICATION OF PROTOTYPING TECHNIQUES

Our literature survey and discussion with system developers* have led us to identify
three categories of prototype techniques: scenarios or simulations, demonstration
systems, and "version 0"<2i) limited working systems.
A scenario or simulation presents to the user an example of actual system usage but
only simulates the processing of user data or queries.
That is, the eventual application logic is not developed, but a script is created that
drives the screen for certain fixed entries, as if the system existed.
Depending upon the tool used to build the scenario, some of the development work on
the scenario may be applied to the production system, as seen in the next section.
A demonstration system processes a limited range of user queries or data, using
limited files.
Frequently, some portion of the system, especially screen displays, is carried over to
the production system; these portions are commonly linked by a skeletal processing
code, which will be replaced in the final product. Alternatively, the entire demonstration
can be coded as a throw-away, as described by Gomaa and Scott^^®'.
In any case, the user chooses queries and data from a specified type or range.
A version 0 prototype is a working release of the system intended to receive use under
conditions approaching the production environment.
While it is specifically designed as a test release, it is usually expected that the final
product will build on version 0 by completing the implementation of functions, adding
requested alterations, and generating the required documentation, etc.
to convert the program into a product.
TThe three technique categories are clearly points of reference on a spectrum, but the
distinction seems to be worth making.
It clarifies the intent ofa prototype and its expected benefits. A scenario will be expected
to address interaction requirements and some functional requirements, although it
cannot shed much light on application logic.
A demonstration is likely to provide more insight into processing logic but may not
be as useful for evolutionary requirements, because the user's exposure is of necessity
lirnited.
A related technique, incremental deliveries, has been described by Gilb''*^', who
distinguishes it from use of demonstrations and version 0.
 TOOLS USED EOR PROTOTYPING

The use of prototypes has been advocated as cost-effective even in the absence of any
special tools to support the various techniques.
But a number of tools do exist to support version 0, demonstrations, and scenario
prototypes - some indirectly as by-products of higher-level languages or programming
support environments and at least one directly as a requirements tool.
The time and cost of an initial version 0 of an application can be substantially reduced
using higher level languages (also known as non-procedural, fourth-generation, even
fifth-generation languages).
These support applications data aggregates as primitive data types with appropriate
built-in operations. When there is a good fit between these predefined structures
and the application structure, these tools reduce the amount of programming required
to develop an application over a traditional procedural language such as COBOL
or piVl.
The most f requently referenced tool in the authors" literature search was API/~ ' '^'^•-'^>.
Although this choice may be due more to the nature of the APL community than
any other factors, ADF^^^^ and various other languages^^^''^-'* are also proposed
for a first working version.
The distinction between a version 0 prototype and a demonstration is as much the
result of the environment in which it receives use as it is the functions provided.
Thus, one would expect that demonstration prototypes could be conveniently constructed
with tools such as ADF^^^' avid APi/^^\ On the other hand, Berrisford and Wetherbe
''^' found it productive to use a relational data base system to implement demonstrations,
and several sources construct demonstrations essentially as by-products of programming
support environments. This can provide facilities for macro commands (which are
replaced once a design is verified) and program stubs to be later enhanced^'" or
application generators based on traditional procedural languages'^^'""^
The construction of a scenario prototype, since it provides less functionality than
a demonstration prototype, must cost less than a demonstration if it is to be worth while.
Using tools similar to those above, one can implement simple case logic to provide
the desired actions when the values in the script are entered (and to ignore or reject
all others).
Alternatively, one can use a special-purpose tool, which accepts example actions
and automatically constructs the appropriate case logic.
 METHODOLOGY ISSUES RAISED BY PROTOTYPING

The traditional system life cycle—requirements, design, implementation, test, integration,

maintenance — reflects recognition of the need for an organized approach to system
development with attendant milestones and approvals.
Prototypes can be :
1. incorporated into this cycle at the requirements phase (aU techniques),
2. used to bridge or merge the first two or three phases using demonstrations or version
0 in an iterative development, or
3. used to avoid the cycle altogether, when employed by end-users to
create their own systems with little or no involvement from professional systems developers
(version 0).
The issues raised by these choices are not trivial, and include using a prototype as
"throwaway" code or building upon it; preserving Brook's distinction between a program
and a system product; the use of a prototype in documentation and maintenance;
and the roles of development staff and users. In this section we discuss some of these
issues.

CONCLUSION

We have examined some of the published accounts of prototypes as employed in

information system development, and tried, to categorize the techniques, tools and
methodologies employed.
The particular combination to be used in a given situation is determined by the application
structure, the skills of the developers and users, and the tools and management practices
available.
Any prototype should be developed with a clear idea of the kinds of advantages it is
hoped to achieve.
The current emphasis on prototyping represents, we believe, a return to basics in systems
development, particularly in the domain of business information systems.
Interest in prototyping reflects a recognition that traditional approaches to the
management and conduct of systems development are not adequate.
Prototyping, however loosely defined, reflects a renewed effort to meet user requirements
for ever more complex system function in a more timely and productive manner.
It is our feeling that the prototyping approaches to system development should be
expected to differ in different application domains.
In the domain of business information systems there is reason to be optimistic that
integrated tools that will have this desired effect are available and evolving .
 REFERENCES

(1)A.I. Wasserman, Information system design methodology, J. of ASIS 3/(1), 1980

(3) M.V. Zelkowitz, A case study in rapid prototyping," Soft. Pr. and Exp. 10, 1980

(4) R.A. Zahniser, "How to navigate the user fog," Computerworld, March 16, 1981

(5) P.H. Baucom, "Software blueprints," Proc. ACM Conference, 1978, 385-92

(6) L. Scharer, "Pinpointing requirements," Datamation, April 1981

(7) L.J. Peters and L.L. Tripp, "A model of software engineering," Proc. ICSE 3, 1978

(8) D. Harel, "On folk theorems," CACM 23(7), 1980

(9) Anon., Programming work-stations," EDP Analyzer 17(10), 1979

(10) E. Keppel and D. Kropp, "Interactive programming by end-users," Proc. APL 77

(11) E.R. McLean, "The use of APL for production applications," Proc. APL 1976, 303-7

(12) B.R. Martin, "Improving productivity with APL," Proc. Share 53, 1979

(13) L. Peters, "Relating software requirements and design," Proc. NCC 1980

(14) N.S. Read and D.L. Harmon, "Assuring MIS success," Datamation 27(2), 1981