Skip to main content

Full text of "The software engineering prototype."

See other formats


'iCj:.VV',V«',."'''j-i.'','I /" 



Monterey, California 




Michael R. Kirchner 

June 1983 


isis Advisor: Gordon C. 



Approved for public release; distribution unlimited 


t*A ^ 


Monterey, CA 93943 






4. TITLE (and Subtltlt) 

The Software Engineering Prototype 


Master's Thesis 


7. AUTHORr«> 

Michael R. Kirchner 



Naval Postgraduate School 
Monterey, California 93940 



Naval Postgraduate School 
Monterey, California 


June, 1983 



U. MONITORING AGENCY NAME ft AODRESSCi/ d<//*ran( Irom ConUoltlng Oltlem) 

15. SECURITY CLASS, (of thia roport) 




Approved for public release; distribution unlimited 

17. DISTRIBUTION STATEMENT (of lh» mtattmct anffd /n Block 30, It dlUartH /ram Rmport) 


19. KEY WORDS fConlinu* on fvtf aid* It n»e»aaarr and Idantlty br block numbar) 

software engineering, software prototype, software design, 
design theories, software engineering environments, case 
studies, software development, information systems development, 
system development life cycle 

20. ABSTRACT (CoitUnua on ravarao alda It naeaaaarr and Idantlty by block numbar) 

Experience has shown that the traditional method of software de- 
velopment often has poor results. Recently, a new approach to 
software development, the prototype approach, has been proposed. 
This thesis presents an integrated view of general design theorie^ 
and relates that view to software design and development. The 
current thought on prototypes is described and the basic require- 
ments for a software engineering environment are presented . (Cont) 




S/N 0)02-LF. 014- 6601 



ABSTRACT (Continued) Block # 20 

Software prototypes are shown to support the integrated view of 
designs. Four case studies of using prototypes are presented 
and recommendations for further study are made. 

S'N 0102- LF- 014-660) 


Approved for public release; distribution unlimited 

The Software Engineering Prototype 


Michael R. Kirchner 
B.S., Illinois Benedictine College, 1973 

Submitted in parxial fulfillment of the 
requirements for the degree of 


from the 

June 1983 


Experisnce has shown that zhe -craditional method of 
software development oftei: has poor results. Recently, a 
new approach to software development, -he prototype 
approach, has been proposed. This thesis presents an inte- 
grated view of general design theories and relates that view 
to software design and development. The current thought on 
prototypes is described and the basic reguirements for a 
software engineering environment are presentad. Software 
prototypes are showc to support the integrated view of 
design. Four case studies cf using prototypes are presented 
and recommendations for further study are made. 







1. Design is Argumentative 18 

2. Patterns in Design 18 

3. Design as Learning 19 

4. Design is Satisficing 20 



















1. The 'Methodology* Strategy 53 

2. Executable Specifications 53 

3. Automatic Programming ". . 54 


1. To Clarify the Oser's Requirements .... 55 

2. To Verify the Feasibility of Design ... 56 

3. To Create the Final Sysxem 56 


1. Prototyping is a Symmetrical and Adaptable 
Process 57 

2. Prototyping 'Tames' the Wicked Problem . . 57 

3. Software Prototyping is Satisficing ... 59 

U. Prototyping is Communicating 59 

5- The Software Prototype is a Learning Aid . 60 

6. The Prototype Processs Accounrs for 
Organizational Issues 61 

7. The Prototype Process is Evolurionary . . 62 






1. Development Supporr Tasks 66 

2. Integrated 67 

3. Uniform 67 

a. Support a Solution Strategy 67 

5. Adaptable 68 

6. Functionally Unique 68 

7. Interactive 6 8 

8. Recent Developments 68 



1. Technical Components 69 

2. Support for Software Design 72 

3. Support for the Prototype Process . . -. . 74 

















I. Design Methodclogiss 31 

II. Hypc-^heses Tested in the Experiment 3U 

III. Results of the Experiment 34 


2.1 alexander's Eesign Phases 14 

3.1 Kolb*s Learning Cycle Model 37 

3.2 A Constructive Conflict Model for Oser 
Involvement 39 

3.3 lypical Life Cycle Representation 45 

4.1 Ihe Prototype Model 52 

4.2 Evolution of Prototypes 63 


Current software engineering practices are bas«=d on a 
development modal which is 10 to 15 years old.. This model 
is often referred to as the waterfall model. The waterfall 
model shows the development of software as a series of 
discrete steps [ Ref . 1r 2, 3, 4, and 5]. 

Experience indicates, however, that software development 
is net as discrete as the model indicates, so the model has 
teen rsfined by adding loops between each of the steps. 
Furthermore, as software maintenance has gained recognition, 
there is increased pressure to refine the waterfall model to 
show the added importance of maintenance in the software 

The software engineering profession's concern about 
software maintenance, which is more properly termed refine- 
ment and enhancement, has prompted several conjectures. 
Dodd [Hef. 20] has suggested that the current cycl€ of 
develop, inplement, refine and enhance, implement, refine 
and enhance, implement, and so on is really the construction 
and refinement of a prototype system. 

Several other authors have suggested that we should 
develop software prototypes as an alternative to the tradi- 
tional, or waterfall, approach to software development 
[Ref. 68, 36, 62]. Their principal argument is that the 
process of software development is really iterative, slowly 
expanding toward a ccmpleted system. Other reasons include 
enhanced communications between the user and designer, fewer 
requirements problems, quicker turnaround between initial 
system need and initial system implementation, to name a 


The process of devslcping a software prototype has 
significart inruitive appeal for asers and managsrs; they 
can try a system cut before comcQitting "chemselves" to a 
system which is either unsatisfactory or undelivered. Aside 
from this appeal and the benefits often cited, there seems 
to be little discussion about the principles underlying the 
development of software prototypes. 

This thesis presents one view of how the process of 
developing software prototypes supports some basic elements 
of general design theory and software design specifically. 
Chapter II develops an integrated set of design elements 
based en several published models of the general design 
process. Chapter III relates these design elements tc soft- 
ware development by citing examples from the computing and 
information science literature. The purpose is to show that 
software design is similar to other fields of design.' 

Chapter IV introduces the software prototype. The 

process of developing software prototypes, their roles as 
iDodels, construction strategies, and the principal uses of 
prototypes are described. The chapter concludes by shewing 
how prototypes support the design elements from Chapters II 
and III. Chapter V briefly describes the essential features 
of software engineering environments, especially those 
features which are needed for developing software proto- 
types. Chapter VI presents four case examples which illus- 
trate the process of developing a software prototype. These 
cases were chosen because in each of them there was an 
explicit decision to use prototypes. Chapters VII and VIII 
present Conclusions and Recommendations for Further Study. 

'To paraphrase Gertrude Stein: Design is design is 
design is design. 




Th€ ideas about design and design methods have undergone 
some significant changes in the last 20 years. The early 
models placed their emphasis on the process of design. 
These models had a rational, discrete notion of design in 
which the design process was thought to be a sequence of 
wall-defined, highly structured activities, Many theorists 
applied the ideas and principles of the scientific methcd to 
the process. Alexander [Rsf. 6] was one of the earliest of 
the design theorists to carefully explain design. His three 
most significant contributions were: 

1. The symmetry cf the design problem — that is, design 
has two symmetical parts, the form (the solution to 
the problem) and the c ont ext (the setting which 
defines the prcblem) . "... adapta-icn is a mutual 
phencmenon referring to the context's adaptation to 
the form as much as the form's adaptation to it's 
context ..." The design problem is an effort to 
achieve "fitness" between the form and it's context. 
[Hef . 6] 

2. The formal decomposition of a se-c of requirements 
into successively smaller subuni-cs. 

3. The importance of diagrams in design. A diagram, for 
Alexander, is "[a]ny pat-ern which, by being 
abstracted from a real situation, conveys the phys- 
ical influence of certain demands or forces ..." 
[Bef- 6: p. 85] 


Alexander chose tc emphasize the process of deccnpos'^-ior. 
in his early work. This process was divided into two 

phases, analysis and synthesis. 

In analysis, the designer, faced with a problen, derives 
a mental picture — often vague and unsatisf actory--of the 
demands of the context, and then decomposes that picture 
into sets (a mathematical picture) . Synthesis begins by 
developing diagrams (tased on the sets) , using the diagrams 
to form a design, and then deriving the form (see Figure 
2.1). Alexander also discussed evaluation (he calls it 

"goodness of fit"). Goodness of fit is determined by one of 
two criteria, experimental or non-experimental. The experi- 
mental criterion is trial and error where "[ t ]he experiment 
of putting a prototype form in the context itself is the 
real criterion of fit." [Ref- 6: p» 21]. The ncn- 

experimental criterion is "(a] complete unitary description 
of the demands made ty the context ..." [Ref. 6: p. 21]. 
Alexander believes that: 1) trial and error is toe expensive 
and too slow and 2) there is no theory which can express 
"... a unitary description of the varied phenomena of a 
particular context." [Refo 6: p. 20]. For these reasons 

he concentrates on the proc ess of decomposition. 2 

Alexander's structured view was shared by many theorists 
during the early 1960«s. [Ref. 8, 7]. Archer [Ref. 7] 

thought of design as a goal-directed activity. The goals or 
objectives cf the problem define the properties required in 
the sclution. The details cf the design are the designer's 
decisions about how tc implement those properties [Ref. 7: 
p. 286]. 

2 Alexander devotes an entire Appendix to the 
"Mathematical Treatment of Decomposition." 






















Figure 2.1 Alexander's Design Phases. 


Archer identifies three components of the design 

1. The advance through the project and through tim-e; 

2. The branching cf xhe problem into its logical parts; 

3. A problem-solving process cyclically moving through 
subproblems (using a 30-st9p reiterative operational 
model) . 

Jones [Bef. 8] called the thrae stages in his view of 
the design process divergence, transformation, and conver- 
gence. He was quite convinced that designers should think 
cf these stages as separate: 

...there is little doubt that thair separation is prere- 
quisite to whatever changes of methodology are necessary 
at each stage before they can be reintearated to form a 
process that works well at the systems level. [Ref. 8: 
P- 64] 


These early models ware often criticized. One critique 
suggested that design problems are "wicked problems" and are 
not, therefore, amenable tc structured analysis (and deccm- 
pcsiticn) . The term "wicked problem" refers to a 

. . . . class of social system problems which are ill- 
formulated, where the information is confusing, where 
there are many clients and decision-makers with 
conflicting values, and where the ramifications in the 
whcle system are thoroughly confusing. [Ref. 9] 

Wicked problems have the following properties : 

1. Wicked problems ae ill-formulated. They have no 

definitive formulation and any formulation will 
correspond tc the formulation of the solution. This 
means that any time a formulation is made, additional 


questions can be asked and more information can be 
requested. This also means rhat the information 

needed to understand the problem is determined by 
one's idea or plan cf a solution. In other wcrds, 

whenever a wicked problem is formulated there must 
already be a solution in mind. 
2- Wicked problems have no stopping rule. Any time a 
solution is fcrmulated, it could be improved or 
worked on more. One can stop only because one has 

run cut of resources, patience, etc. (An architect 
cculd keep modifying and improving a design solution 
fcrev€r--he steps because ne has exhausted his fee, 
because the building has to be finally built, or 
because he has exhausted some other resource.) 

3. Solutions to wicked problems cannot be correct or 
false. They can only be good or bad. (There is no 
correct or false building: there can only be a "gocd" 
building or a "bad" building.) 

4. In solving wicked problems therr is no exhaustive 
list of admissable operations. Any conceivable plan, 
strategy or act is permissable in finding a solution 
and ncne can be perscribed as mandatory. 

5. For every wicked problem there is always mere than 
cne possible explanation. The selection of an expla- 
nation depends on the employed world-view; the expla- 
nation also determines the solution to the problem. 
(The high cost of construction of a building may be 
attributed to the "expensive" design, to the high 
cost of materials, to the wages demanded by unions, 
to high interest rates and inflation, etc.) 

6. Every wicked problem is a symptom of another' "higher 
level" problem. (If the maintenance of the residence 
is "too expensive" to its inhabitants, this indicates 
that there is a problem with the income of its inhab- 
itants. ) 


7. No wicJced problem and no solution to it has a defini- 
tive test. In ether words, any time any tast is 
"successfully" passed it is still possible that the 
solution will fail in some other respect. (If large 
windows are designed for a residence to provide the 
desired views, the heating of the residence may 
become too expensive.) 

8. Each wicked picblem is a "one shot" operation. There 
is nc room for trial and error, and there is no 
possibility fcr experimentation. (A house is 
designed and built- -there is no going back to the 
beginning to redesign and rebuild it.) 

9. Every wicked problem is unique. No two problems are 
exactly alike and no solutions or strategies leading 
tc solutions can readily be copied for the next 
prcblem. (Even if two residences are designed for 
the same family, under the same geographical condi- 
tions they will never be identical.) 

10. The wicked problem solver has nc right tc be 
wrcng — he is fully responsible for his action. 

If design problems are considered as wicked problems, 
they are certainly incompatible with the early lodels of 
design. The early models clearly separated the problem from 
its solution. With wicked problems, one cannot "define the 
problem"--they have no definitive formulation. If one 

followed the procedures of the early models of iesign, one 
should be able to establish when a solution was clearly 
found. Wicked problems, however, have no stopping rule. 
Some cf the proponents of the early models of design devised 
tests for design solutions. Alexander argued that trial and 
error shculd eventually lead to "good fit"; unfortunately, 
each tiiE€ a solution is tried, the problem is also changed. 



''• Design is Argu mentative 

Oth-rT design models were proposed following the criti- 
cisms of the early, structured models of design. Rittel 
[Ref. 13] views the whole design process as sequential 
problem solving in which the cycles form networks. An 

essential parr of this model is the continuous feedback 
between tke designer and the problems environment. Rittel 
calls this •argumentation': 

. . . . the designer [is] arguing toward a solution with 
himself and with ether parties involved in the project. 
He builds a case leading to a better understanding of 
what is to be acccmDlisn ed. In izs course, sclu-rion 
principles are developed, evaluated in view of their 
expected performance and decided upon. The parties 
commit themselves to specific courses of action and to 
the risks involved in them. In this way, better formu- 
lations of tha problem are being developed simultane- 
ously with a clearer and clearer image of the solution. 
[Ref: 13 : p. 19-20] 

If arguments are improved procedurally, their content may 
improve and the products of the design — design 

decisions — may also be expected to improve. While 'argu- 

ing', the parties may gain new insights about the issue, 
expand their world-view, modify challenged positions, and 
learn more about other world-views. 

2» Patterns in Cesign 

Alexander introducsd the concept of pictoral 
diagrams in design in 1964 [Ref. 6]. Significantly, 

Alexander believed that the design diagrams were produced b^ 
foSl^l, rigorous anal ysi s, a design process founded en math- 
ematical decomposition. Since then, Alexander and others 
[Ref- 10] have concentrated on the diagrams (or Patterns) 
rather than the process. 


Alexander's patterns are not a resalt of rigorous 
analysis. Rather, design is a process of acquirir.g knowl- 
edge and then making decisions which reflect that knowledge. 
The crucial issue for Alexander is the availability of 
knowledge. That is, the design decision depends on the 
accuiDulatsd knowledge of the designer. Patterns help to 
provide the designer with the necessary knowledge to solve 
the problem. The pattern forms the basis of communication 
between the designer and the client. A pattern — a diagram 
of what the designer knows and believes important for the 
problem — is designed and then passed to the client. The 
client either accepts or does not accept the pattern. In 
either case, both the client and the designer gain new 
knowledce: if the pattern is not accepted, the designer 
proceeds to change the design. 

^ • Design as Lear ning 

Eazjanac [ Ref . 15] views the design process as 
formulating the problem and proceeding with a search for the 
definition cf -he solution. He emphasizes that the forirula- 
tion cf the problem is not final. The formulation reflects 
the understanding of the problem, based on the designer's 
knowledge, at that time. 

Any solution ... is already basically determined by the 
definition of the problem. So the "search for solution" 
is then the search for the definition of the specific 
solution which best fits the knowledge the desianer has 
at that time. Once the specific solution is defined it 
is documented. Documentation may start during the defi- 
nition cf the problem and continue sporadically during 
the definition of the solution--in fact, all three 
phases may at tiroes take place simultaneously. The 

ultimate purpose of the documentation is to communicate 
the definitions of the problem and the solution; its 
immediate purpose is to aid the designer in the defini- 
tion cf the problem and the solution--to help him detect 
new aspects of the problem and the solution and to 
detect inconsistencies in his view. [Ref. 15] 


During the search and redefinition, the designer 
keeps learning more atout the problem and the solution. The 
designer gains new insights which ultimately lead to a new 
view-- redefinition. The process (fo rmulate the prctlem, 

sear ch for the definition of the solution, document the 
specific solution) is repetitive. The designer continues to 
re-define and document new formula-cions until 1) the incre- 
mental gain in icnowledge becomes insignificant and cannot 
change the formulation enough to warrent redefinition, 2) 
the incremental gain becomes zoo costly, or 3) the designer 
exhausts available resources (especially time). 

** • nesiqn is Satisf icing 

As the designer and user learn more atout the 
problem and as the sclution becomes clearer, more and more 
design decisions are negotiated [Bef. 13, 15]. Since these 
design decisions are reached through compromise, they cannot 
be called optimal, in the sense of management science and 
operations research, 

Simon [ Ref . ^H] has introduced the idea of satis- 
ficii^g tc describe these kinds of negotiared decisions. 

Normative economics has shown that exact solutions to 

iplexity the real-world business firm turns tc p: 
dures that find gccd enough answers tc questions whose 
best answers are unknowable. ... man is ... a satis- 
ficer, a perscn whc accepts "good enough" alternatives, 
not because he prefers less to more bur because he has 
no choice. [Ref. 1U: p. 36] 



Cross and others [ Ref . 16] have proposed a vi.ew cf 
design which requires the explicit acknowledgement of the 
organization's role in design. 

•Technclogv* ... clearly denotes more than just hard- 
ware, and involves, at the very least, consideration of 
the organizational systems within which machinery is 
desiqnea, commissioned, operated and paid for. 

•Technological* achievements, whether those of building 
a irajcr bridge or cutting a man on the moon, are as much 
organizational feats as technical ones. [Ref- 16: p. 

These ccnsideraticns lead to their view that a "satis- 
factory" definition cf technology has the following charac- 

1. Tschnoiogy is oriented toward practical tasks. 

2. Tschnoiogy relies on different kinds of organized 
knowledge, of which scientific knowledge is only one. 
Craft knowledge, design knowledge, and organizational 
and managerial skill are others. 

3. Technological activity takes place in an crganiza- 
ticnal context. [Ref. 16: p. 198] 

Cross and ethers devcte a great deal of space to 
highlight the difference between knowing "what to do" 
(scientific knowledge) and knowing "how to do" (design and 
craft knowledge) . Their main point cannot be ignored: the 
organizaticr plays as large a role in design as does the 


The early mcdels of design were frequently criticized for 
their linear, step-by-step view of design. Page [Ref. 11] 
warned that the design process is not executed straight from 
analysis to evaluation: 

21 the majority of practical design situations, by 
th-G time you have produced this and found out that and 
made a synthesis, you realize you have forgotten to 
analyze something else here, and you have to gc arxDund 
the cycle and produce a modified synthesis, and so on. 
In practice, you gc around several times. 

Ellinger stated that the iterative approach to design ".-- 
is pariculaily suited to novel projects of some complexity." 
[Eef . 12: p. vi ] 

Smithies [Ref. 17] has suggested that rhere are a number 
of essential stages in design. The first stage, design 

analysis, is the statement cf the problem, ?. The nex"c 
stage consists of finding one or more tentative solutions, 
IS. This sclution is then criticized, C. When the d*fsigner 
criticizes the solution, he or she admits that the problem 
statement was inadeguate. So, the designer re-states the 
problem and begins anew. 

E1-TS1-C1-P2-.. .-?n. 

Smithies attributes his views about design to Pepper 
[Ref. 18]. Popper believes that the process or activity of 
understanding can be represented by a genaral scheme of 
Ii2^J:J2 solving h^ c oje c tur e and criti cism . Popper's 

scheme, adapted by Scithies, is this: 


PI is the initial crcblem statement; TT, the • 
theory', is the conjecture. EE, 'error elimination', is the 
critical examination of the conjecture. P2 is the new 

problem statement which emerges from the examination. It 
leads to ancther attempt, and so on [Hef. 18 : p. 164]. 
Smithies' design stages and Popper's problem-solving scheme 
are very much like Polya's [Ref. 19] method for solving 
problems. Software designers should take note: Polya is a 
mathenatician. Popper is a philosopher, and Smithies is an 


architect, yet -sach approaches the solution to a prcblsm in 
the same way. 

The progress of the designer through these stages is 
marked by increased knowledge and shifting priorities. 
Clearly that progress is not linear and should be called 


Several points about design have been made in the 
proceeding sections: 

1. Design is symnetrical and adaptive; 

2. The interesting (i.e., large, complex) design frcblams 
can be considered as wicked problems; 

3. Cc mm uni cations with the end user are crucial and 
depend to a large degree on pat-erns which bridge the 
communications barrier between designer and end user; 

4. Design is a learning process — each party brings a 
different perspectiv e to the problem (and the solu- 
ticn!) and leaves (or should leave) with an augmented 

5. Design is satisficing; 

6. Design takes flace in an organiza-ional context; 

7. Design is evcluticnary. 

The separation of "chese poinds should not be miscon- 
strued. Each cf these aspects is interrelated and to a 
certain extent mutually dependent on one another. When we 
say that design is evolutionary, we also imply that design 
is symmetrical and adaptive. When we say that design is an 
organizational activity, we also imply that there will be 
extensive ccmmunicaticn during design. Whenever we try to 

understand the problem, to learn mors about our tentative 
solution, we are raising a problem of understanding, or 
posing a higher level problem, which implies that design 
problems are wicked problems. 


This interrelated set of design elements forms the tack- 
drop for the remainder of this work. The following chapter 
presents evidence from the literature that each of the 
design elements described above is a factor in software 




Several instances in th€ literature point to the 
symmetry cf the software design problem. That is, the solu- 
tion not only depends on the problem, but the problem 
depends en the solution. Solution and problem are no* sepa- 
rare issues, rather they are intertwined, much like the 
figure and ground in a painting or picture. Each depends on 
the other. Unfortunately, most people associated with soft- 
ware design do net appreciate this point. Peters points cut 
that software designers complain bitterly that requirements 
are poorly defined while customers and analysts often 
complain that the design is not responsive to "he problem or 
problems as they see them. [Ref. 23 : p. 67]. Peters 
wasn't tte first to recognize this, though. Podolsky wrote 
a humorous article in 1977 [Ref. 24] where he states "Peer's 

?e er j s Law 
The solution to a problem changes the problem. 

Several ether authors [Ref. 25, 26, and 27] have also recog- 
nized that the problem definition tends to evolve as the 
designers try to bound the problem, or modify the require- 
ments. Mccracken and Jackson [Ref. 27] have gone so far to 
say that this dependence is analogous to the Heisenberg 
Principle: Any system development activity inevitably 

changes the environment out cf which the need for the sys-cem 
arose . 


Much affort is currently devotsd to requirements defini- 
tion and yet inccmpleteness , ambiguity, and poor definitions 
in requirements documents are often pointed to as the" fore- 
most prcblems facing software designers today. The effort 
which is spent on completely specifying the user^s require- 
ments will gain nothing if software design is adaptive. 

Mccracken and Jackson believe that systems requirements 
can never be stated fully in advance. To assert otherwise 
is to ignore the fact that the development process itself 
changes the user's perceptions of what is possible, 
increases insights into the applications environment, and 
often changes the environment itself [Eef. 27: p. 31], 
Peters says that although requirments may have been very 
fixed at the beginning, they tend to change and evolve with 
time. If for no othsr reason, the user's perception of the 
problem changes as dees the designer's perception of that 
problem [Bef. 23: p, 70], 

Change is inevitable during software design, and yet 
"planning for change" has long bean given lip-service, at 
best. Neumann believes that planning for change is slowly 
being recognized as an important end in itself--and one that 
usually cannot be achieved by retrofits into an inflexible 
design [Bef. 28]. 


Mcst computer system developers will immediately argue 
this point. Developers of military systems would argue the 
longest and hardest. Why should the idea of satisficing be 
so controversial? Parhaps the answer lies in the past, when 
machine time was expensive and computer memory limited. 
These limitations do not exist at the same level today. In 
fact, satisficing occurs all the time. Conn states that the 
requirements for state-of-the-art systems are often scaled 


dcwn to respond to the need to cut the overall expense of 
the project or to meet time limitations [Hef. 26: p. '♦03], 
Designers are, or should be, constantly aware of the -trade- 
offs that are made in systems development, especially the 
classic trade-off, ccst versus performance. 

Several authors point out that a user should, in fact 
must, sacrifice an cptimum design for a design which can 
cope at a satisfactory level [ Bef . 29, 30]- John Munsun has 
been quoted as saying: 

Users iiii:sx look at the economics involved in automation 
as a software- productivity solution. If a user can buy 
a payrcll program xhat is almost what he needs for 
$10,000 cr one that exactly fits his needs for $1 
million- he must look at the trade-offs and reduce his 
expectaticns. [ Ref . 30 : p. 66] 

Satisficing has to do with more than economics. 
Lawrence Peters has said that the trade-offs for execution 
efficiency and ease of change must be evaluated and a 
comprcmiss made. [Ref. 30]. Lockett emphasizes the role of 
user satisfaction when evaluating rrade-cffs. For her, user 
satisfaction is not based solely on the functional capa- 
bility of a sysrem, but on useability, reliability, and 
performance as well. Often the user cannot have everything 
(for example, both performance and functional capability) he 
cr she wants in a system. The final product may be the 
result of ccmpromise. Certain functional capabilities may 
te eliminated to achieve specific performance goals or, on 
the other hand, the user may be willing to sacrifice 
performance to obtain some functional capability [Ref. 31 : 
p. 157]. 

Several ether authors emphasize the role of agreement, 
concensus, and negotiation [Hef. 32, 39, 33]- These authors 
conxend that as system design progresses, alternatives are 
proposed and evaluated. The exact definition of a system 


may net be as important as the concensus on the inexact 
definition which is attained. An example from Land serves 
to illustrate the inportance of sazisficing in sofr,vfars 

. . . . the designer has to be aware that building flex- 
ibility into, systems can also be expensive, both in 

to the needs existirg at the time or implementation, tut 
which may be incapable of modification, and may have tc 
be replaced if requirements change. [Ref- 29 : p. 67] 

Satisficing may also involve psychological trade-offs as 
well as zechnical trade-offs. Madnicic and Donovan reia-e an 
instance where two possible algorithms could have b«=en used. 
The inefficient algorithm was chosen because the designer 
could not stand the suspense of waiting [Ref. 22: p. U91]. 


Hcrsx Rirrel has suggested -chat design problems are 
wicked problems [Ref. 13, 9]. These problems are ill- 

formulated, have confusing information, have many clients 
and decision-makers with conflicting values, and have rami- 
fications in the whole system which are thoroughly 
confusing. Peters and Tripp have suggested that software 
design is a wicked problem. Th^y believed that a comparison 
of the attributes and problems associated with software 
design and the characteristics of wicked problems make it 
apparent that software design is itself a wicked problem 
[Ref. 37]. A review of the properties of wicked problems 
and their relation tc software design should help tc put 
this notion in perspective. 


wicked iroblams have nc d efini t ive formal ax ion. Any 

time a foriulation is made, additional questions can be 
asked and mere information can be requested. Our inability 
to define system requirements completely and unambiguously 
is a symptom of this problem. Currem: efforts in software 
devalcpment seem to be aimed at the symptom rather than the 

Several authors raise the possibility that a complete 
set cf requirements is impossible, that a stat9-cf-the-art 
system is almost by definition on>= for which there remains 
some degree of uncertainty at the time requirements are 
preparsd. Under these conditions, it is hard to imagine a 
set of "complete" requirements, since the knowledge of the 
eventual system at that point can only be incomple-e 
[Ref. 26 : p. 403]. 

Wicked problems have no stopp ing rule. Any time a solu- 
tion is formulated, it can be improved or worked on more. 
Cne stops only because one has run out of resouces, 
ps.tienci, cr something slse , Few would argu5 -hat ther== are 
clear stopping rules for software design. (Else why are 
there innumerable examples of cosu and schedule overruns?) 

Scluxions to wicked pro ble ms cannot be correct or f alse . 
They can only be gocd or bad. This notion can be quite 

controversial among computer scientists. Granted, a 

computer system must work properly, especially in life- 
critical cr lif e-thr satening circumstances (hospital equip- 
ment or nuclear reactors, for example). But '^work properly" 
has different meanings to different people, or groups of 
people, just as do "correct" or "true". 3 * 

^Mortimer J. Adler discusses the idea of "truth", an 
idea we judce by, in Six Great Ideas, aacmillan Publishing 
Co., Inc., New York, 1^B7. 


Perhaps "good" and "bad" are poor choices as well, yst 
most of us readily acknowledge the differences, when 
presented with "good or bad, for whom?" The distinction 
could be thought of in terms of 'technical success* and 
•psychological success'. Technical success is the degree to 
which the actual performance of the system matches its spec- 
ification, while psychological success is the degree to 
which the end user has confidence in th"*' final system 
[Ref. 36]. 

Another distinction can be made from the observer's 
point of view of a system: a system exists and is defined 

by the perscn(s) observing it. It is as acceptable, perhaps 
even laudable, as the observer perceives it to* be. If a 
system wciks in the eyes of those who use it^, then to those 
users that system is a good one. Conversely, if a system is 
cbserved as not working by those same users, then it is not 
good regardless of any ether attribute it may have. 
[Ref- 33]. 

Ii2 aSlZiM w ic k e d problems thara is no exha ustive list 
of adaissable operati ons . Any conceivable plan, strategy, 
or act is permissable in finding a solution and none can be 
prescribed as mandatory. Anyone in the profession car. see 
that this certainly applies to software design (granted, 
there are at present a finite number of "design methodolo- 
gies", yet each year this number continues to increase). 
The literature is replete with references to design methcd- 
clogies: object-oriented design, data-or ianted design, 

design based on finite-state machines, and so on. 
See Table I for a large, and certainly incomplete, list of 
design methodologies. 

Not only are we faced with many alternatives for a 
design "met hcdolcgy" , but we also are faced with innumerable 
alternatives for solving the subproblems in the particular 
design case at hand. There may ba more than one way in 


C€sign Hethodologies 

MneiDcriic F ull Nams of M athodoloqy 

ACM/PCM Active and Passive Component Modelling 

DAEES Data Oriented Design 

DSSAD Data Structured Systems Analysis and 

DSSD Data Structured Systems Development 

EEM Evolutionary Design Methodology 

GEIS Gradual Evolution of Information Systems 

HOS Higher Order Software 

IBMFSB-SEP Adaptation of IBM Federal Systems Division 

Software Engineering Practices 
lESM Information Engineering Specification 

ISAC Information Systems Work and Analysis 

of Changes 
JSD Jackson System Development 

NIAM Nijssen*s Information Analysis Method 

SAET Structured Analysis 5 Design Technique 

SABA System ARchitect's Apprentice 

SD System Developer 

SA-SE Structured Analysis and Structured Design 

SDM System Development Methodology 

SEEN Software Engineering Procedures Notebook 

SREM Software Requirements Engineering Methc- 

STRADIS STRuctured Analysis, Design and Implemen- 

tation of Information Systems 
USE User Software Engineering 

which a target system development process can proceed simply 
because there are alternatie approaches available at the 
time the requirements are written. A decision between these 
alternatives may not be possible [Ref- 26 : p. U03]. 

ISI SJJJI^ w ick ed problem there is alw ays more than one 
possible e xpl anation. The selection of an explanation 

depends en the perspective, or world-view, used. The expla- 
nation also determines the solution to the problem. (For 
example, the high cost of software is often attributed to 
labor-intensive design and programming; poor requirements 
definition is often blamed for software "failures".) 


Nc wicked £r cblem and no s olutio n to it has a defi nit ive 
test. In ether words, any time any test is "successfully" 
passed it is still possible that the solution will fail in 
some other respect. This characteristic of wicked prcblams 
is tied very closely to the idea of satisfied ng. If 

computer systems are tuilt to be flexible, their design must 
fce generalized. The aspect of flexibility is gained at the 
expense of efficiency (not that this is bad!). So, the 

system "passes" the test for flexibility but is very ineffi- 

Jl£^ wi cke d problem is a "one shot" operatio n. There is 
no room for trial and error , and there is no possibility for 
experimentation. Many large-scale computer systems have 

this characteristic. In fact, software development is some- 
times compared to building a bridge--once it is built there 
is nc going back to the beginning to redesign and rebuild it 
(for any number of reasons) . 

E13.E1 w i ck 6 d p rcfclem is unique. No two problems are 

exactly alike and no two solutions or strategies leading to 
solution can readily be copied for the next problem. This 
characteristic is very evident in software design. Military 
systems, for example, are certainly unique. Commercial or 
industrial problems are no less unique. Each organization 
has a unique structure, set of goals and objectives, set of 
interactions with the environment, cast of people, and set 
of needs.* 

TJ3€ wicksd problem solver has no right to be wrong -- 
he/she is fully respcn sible for his/ her a ction . There has 
been a growing skepticism among users regarding the abili- 
ties cf software designers. Users have every reason to 
believe that the software designer "knows" the job. 

lems, for obvious reasons. 


clearly, the designer mast be aware of many of the factors 
which could affect the design. The designer must also be 
aware of the effects of design decisions- Allowances will 
and can b€ made for unusual unforeseen difficulties. But to 
hide behind the "This system meets the specifications you 
approved and signed" statement is going (and has gone) too 


Perhaps the single, most widely noted problem area in 
software design is the problem of communication between the 
user and the designer. The recent literature emphasizes the 
need for extensive ccmmunications [Ref- 25, 29, 30, 35, 39, 
and 40]- The most common reason given for the problem is 
that users and designers speak with different vocabularies 
and find it difficult to completely undersxand each crher. 

Much of the literature which cites the need fcr closer 
communication is based on empirical and ancedotal reports. 
King and Hodriquez [ Bef . 41 ], however, report an assessment 
of participation (and communication) in system development 
in an experimental context. The experiment tested four 
specific hypotheses (see Table II) about participative 
design which were stated in null form.s 

The experimental results (see table III) indicate that 
participative design makes a difference, especially when 
viewing the "worth of the system". 

SThis only means that the 'claim', i.e.. "accepted 
wisdcm" in systems design, was set up as the alternative to 
the hypothesis, in accord with traditional"" Hypothesis 


Hypotheses Tested in the Experiaent 

HI: Participation in the dav^lopment of rhe systsm has 
no effect on the user's perception of the worth cf the 

H2: Participation in the development of the system has 
no effect on the amount of use which is made or the 
systeiE when the user is faced with strategic issues for 
which the system was designsd to provide support. 

H3: The substantive inputs provided by participants in 
the design process will not be reflected in their usage 
cf the system. 

H4: The decision performance of participants in the 
design process will not be different from that 
of non-participants. 

Results of the Experiment 

HI: The null hypothesis is rejected. 

This result indicates that managers who are involved in 
the development effort tend to perceive the system to 
be more worthwhile than managers who are merely given a 
pre-designed system to which they had no input. 

H2: Cannot reject the null hypothesis, 
conclude that the use of the system in terms of number 
of queries is not significantly different for design 
participants and ncn- par ticipants. 

H3: The null hypcthesis was rejected. 

it indicates that the substantive inputs provided by the 
participant group in the design and development phase 
of the information system are reflected in their 
actual use of the system. 

H'*: Cannot reject the null hypothesis. 


As King and Eodriquez put it, the 

. ... experiment provides some support for "participa- 
tive design theory": (a) The inputs provided by partic- 
ipants appear to have been made use of in their use of 
the system, and (fc) some positive attitudinal impact-- 
in terms of systems "worth" — seems to be achieved 
through participation. [ Bef . 41] 

The experiment seems to confirm some deeply held convic- 
tions that participation in, and responsibility for, design 
implementaticn can result in elimination or reduction of 
communicaticn problems [Ref. 29: p. 65]. 

There may be seme reason to believe that the real 
problsm viith communication is not whether it takes place but 
whether tie media of communication is appropriate. The fact 
that the designer has produced a comprehensive specification 
and that the user has • signed off the specification after 
due study, is not a guarantee that the designer has under- 
stood the user's needs, or the user the designer's specifi- 
cation [Eef. 29 : p. 65]. Stucki has suggested that charts, 
graphics, color pictures, and other aids should be used to 
enhance communications between users and designers; verbal 
descriptions alone are just as inadequate for describing 
software as they are for an architect building a house. 
[Ref. 30]- So, although communications may be a significant 
problem, its form may be equally as important. 


Software design is learning, just ask any experienced 
program nanager. They want someone with design experience 


to head the design team [Hef- 46], Without explicitly 
acknowledging it, these managers place value in the ejcperi- 
ence learned from previous worlc. This "learning from 
doing" also takes place during the design of a system: 

The reason for the discovery aspects of software design 
is the designer's learning curve. As the system is 
studied, analyzed, and a design formulated, certain 
features are recognized as needing attention while 
others are overlocked. As it becomes ^.j^parent which 
features are lacking, priorities shift. [Her. 37] 

If we accept that learning is an element of design, just 
how importact is learning to design? In an experiment, 
Alavi and Henderson [Ref. 55] evaluated two strategies for 
systems development: evolutionary and traditional. By 
their definition, the evolutionary strategy emphasized the 
role of individual learning. They reported that the find- 
ings support the hypothesis that an evolutionary implementa- 
tion strategy is more effective than a traditional strategy 
[Ref. 55]. 

They try to explain their findings this way: 

A model which offers an explanation for the findings is 
Kolt'3 experimental learning model [see Figure 3.1J. 
Kolt suggests that for a learner to be effective he/sne 
must have the ability to engage in four types of activi- 
ties: (1) invclveirent in new, concrete experiences, (2) 
observation and reflection of these experiences, (3) 
creation cf concepts that integrate these observations 
into theories, ana (U) usage of these theories to make 
decisions and solve problems. . . . The evolutionary 
strategy maps directly with a starting point at concrete 
experiences. In contrast, the traditional approach 
began with the development of a theory. ... An expla- 
nation of the findings may rest in the support that the 
evolutionary strategy had for the learning process. 
CRef- 55] 

This model has some important implications for soft- 
ware design. For example, the perspective or world-view 
that the designers (and users) bring to a project become 
important (after all, we are starting from concrete 
















Figure 3.1 Kolb« s Learning Cycle Model- 
experiences). Greenspan and others believe that the ability 
to efficiently design appropriate computer systems and 
enable them to evolve over their lifetime depends en the 
extent tc which real world knowledge can be captured 
[Hef. tlS]. Wasserman [fief. 35] takes the thought further by 
suggesting that memters of the different groups concerned 
with design perceive the function of an information system 
differently. Misunderstandings of objectives can and do 
occur, many times leading tc project failure. 


Land [Bef. 29] also states that there ara different 
ideologies and perspectives among the different interests 
involved in a systems study. Land suggests that managers 
meet this challenge by setting up a design team which 
contains representatives of all the aajor interast groups, 
maicing it possible for the different ideologiss and perspec- 
tives of the participants to be made explicit, and for the 
different members of the group to learn ^rom each others 
different view points [Ref. 29]. 

Hew migh-c rhe participation of users in the systam 
design enhance oi promote learning and real-world knowledge? 
Pobey [Ref. 42] conducted an experiment -hat explored a 
model of constructive conflict in the MIS development 
process. - His model (presented in Figure 3.2) is described 
here : 

User par tic ipation should lead to co nfl icts , which 
should ""^ITen "5a satisfactorily resolved . However, 

conflict and its resolution are more Tixely to occur 
whan users can exercise their infl uenc e in the develcp- 
asnt PICC3SS. Conflict itselT"* '^oas not lead to i-ts 

rescluricn: rather the increase in conflict makes reolu- 
ticn more difficult. It is only through participation 
and influence that conflict can ba successfully resolved 
in this model. [Ref. 42] 

There is other research which supports Rotey's 
"constructive conflict". Boland [Ref. 54] compared two 

different processes of interaction in system design: 

1. traditional--the designer conducts a traditional 
interview of the user 

2. alternative-- the designer and user share ideas, 
present mutual suggestions, and critigue their 

His results are significant: 

1. The alternative process produced higher quality 
designs with important implementation advantages. 






Figure 3.2 A Constructive conflict aodel for User Involvement. 

2. The two processes produced designs which used 
different organizational con-rol strategies. 

3. Different processes may help to define different 
problems and thereby produce different, but squally 
rational, solutions. [ Bef . 54] 

Boland likens the prctlem solving process to a dance during 
which the designer punctuates his inreraction with the user 


in a series of tga chin g , sugges t inq, and critiquing. ^ 
Eoland asks us to accept the notion of learning and the 
importance cf real wcrld knowledge: 

Let us accept that the viewpoint and implicit models 
held ty designers will color their collection and inter- 
pretaticn cf data about the needs of the oraanization 
they are designing for. This study suggests that under- 
standing how that viewpoint builds a coherent design 
statement requires an understanding cf how the designer 
interacts and exhanges information with his cli-^^nt. The 
interaction prctoccls may then be seen as mediating the 
process cf completing the designer's "point of view" 
(creating the design statement). [ Hef . 54: p. 896] 

Rcbry's experiment lends support to Boland's findings: 
"It appears that participation does lead to perceived influ- 
ence in . . . system development" [Ref- 42]. Robey's find- 
ings suggest that influence is used constructively to 
resolve conflict and that users learn how to exert influ- 
ence towards conflict resolution as well as conflict genera- 
tion as the development process proceeds [Hef. 42 : p. 82]. 

As we have seen, there is support that learning, argu- 
mentation, and a designer's world-view are iirpcrtdnt 
elements in software design. 


At first glance, the casual reader is apt to say "lou 
are stating the obvious." Yet much of the current work in 
software design igncres the obvious. Land provides seme 
evidence for this: 

1. Users are uncertain about the affect the final system 
will have on their individual roles in the organiza- 
tion and on them personally. 

^Compare Boland's "dance" and Robey's "constructive 
conflict" for software design to Rittel's "argumentation" in 
design (Chapter II) . 


2. The cbservaticn that the user operates within formal 
systems and that the formal procedure of the existing 
systems have teen overtaken by less formal (but often 
mere effective) unauthorized procedures. 

3. The fact that those who are involved in the analysis 
Ficcess--DP specialists and users — are often not 
aware of strategic decisions made by senior manage- 
ment which could have an important bearing on the 
workability of the syst9m. 

4. New systems almost certainly include innovations; 
users and analyst/designers cannot predict managers* 
responses to innovations. Conjectures about peofle^s 
behavior are no substitute for knowledge, and in 
innovation, such knowledge is not ordinarily avail- 
able. [Ref, 29: p. 64] 

Although Land cited these points as reasons for communi- 
cations problems, they can egually serve as indictments 
against current software design. That is, org anizational 
aspects cf software design are often ignored. 

Wasserman points out that organizations and computing 
environments are highly dynamic and that information systems 
must be designed for a changing organization [Ref. 35]. 
Chafin states that as computer systems become more deeply 
involved in the operations of organizations, they have 
larger social effects on these organizations. A new 

computer system may change the organization structure, the 
power structure, or the overall information flow structure 
in an organization [ Hef - 40]- 


Zmud and Cox rsccgnized the organizational aspects of 
software design in their discussion of a "change" approach 
to design and implementation: 

The change approach to MIS implementation strives to 
create an environment in which change will be accepted 
through the active involvement of affected organiza- 

;y ^ _ 

trust and committment must develop between participants 
so that a free exchange of beliefs and opinions is 
possible. [Eef- 53 : p. 37] 

Zmud and Cox make no reference to wiclced problems, yet 
their change process is recommended when (1) the organiza- 
tional activity involved is ill-defined, (2) the MIS must 
interface with other organizational systems, and (3) 
substantial organizational change is expected. Compare 

these characteristics to Horst Rittel's characteristics of 
wicked problems (Chapter II). 

Although there are several articles and references to 
organizational aspects of software design, two authors stand 
cut. Kling and Scacchi have written two extensive articles, 
[Ref. 59 and 60], which stress the need for an awareness of 
and attention to organizational and social aspects of system 
design. Their latest work [Ref. 60], develops a family of 
models (called web mcdels) which they believe helps tc "make 
tetter predictions of the outcomes of using socially complex 
computing developments". These models are contrasted to 

•discrete-entity' — rational and traditional — models. Their 
work attempts to abstract a set of principles, 
characteristic of web models, from analyses published in the 


Kling and Scacchi stress the importance of perspective 
in the "social analyses of ccmputing". They identify six 
perspectives, four of which predominate: 

1. Formal-rational 

2. Structural 

3. Interact ionist 
U. Pclitical 

Their point in discussing these perspectives is that each 
"casts a different light" on the significant aspects of the 
design problem. ^ 

Further discussion of the work of Kling and Scacchi is 
beyond the scope of this work. The point to be made of 
their work is that software design is conducted in an orga- 
nizational framework: 

In contrast tc the discrete-entity models, which gain 
simplicity by ignoring the social context of computing 
develof ments, web models make explicit the salient 
conections between a focal technology and its social and 
political contexts. [ Ref • 60 : p. 3j 


Much cf the current practice in software design is 

constrained by a model popularly termed the • waterfall* 

model. Tcir Gilb aptly sums up the attitudes of most soft- 
ware professionals: 

It seems that they recognize, as yet, only one tyoe of 
life cycle. In particular, they seem to be speaking of 
a revolutionary life cycle (like the birth or a human) 
as opposed to a mere evolutionary life cycle (such as 
the development of the human species). [Ref- 34j 

'Kling and Scacchi present an extensive discussion of 
the social dynamics cf system design in [Bef. 59]. Their 
discussion is based on the four perspectives mentioned as 
well as two others: human relations and class politics. 


ether authors also complain about the current life cycle 
model. Brittan is concerned that the serial definition of 
the project development cycle, known as the linear strategy, 
embodies cne fundamental concept: that an activity follows 
logically from its predecessor so that each stage is 
complete before the next begins [Ref. 36]- McCracken and 

Jackson seem to be the most critical of the current life 
cycle model. They believe -chat any form of life-cycle is a 
project management structure imposed on system development. 
Furthermcrs, they fcint out that the current life cycle 
modal is either a very much simplified model (which is 
worthless) or unrealistic [Ref. 27]. Podolsky [Ref. 2^* ] 

argues that the current model (which he terms 'Classic 
Development') is "very, very good" when it is successful, 
but thax when it fails, "it's horrid". He attributes the 
success and failure cf Classic Development to the type of 
problem which will be solved: classic development is good 

for well-defined, highly structured, change-resistant prob- 
lems; it fails when presented with an ill-defined prcblem, 
changing participants, and changing requirements. 

Zvegintzov [Ref. 57] has twc objections to the current life 
cycle mcdel. First, it does not portray a systems life, 
only the creation, development, or youth of a system. It 
does not include adulthood and is vague about operation and 
maintenance. Second, it is noz a cycle, it portrays a 
linear path and does not, as a cycle must, return tc its 
beginning [Ref. 57]. Gladden even goes so far to say that 
the software life cycle may be harmful to the software 
profession. See Figure 3.3 for Gladden's representation. 

These arguments, and others, begin -co raise a question 
about the validity of the linear strategy. The linear 
strategy places a great deal of reliance on the studies and 
efforts lade in the earlier 'stages' of software develop- 
ment. Yet this strategy ignores the fundamental aspects of 







Figure 3-3 Typical Life Cycle Sepresentation, 


design described ir Chapter II. Brittan places this 

predicanient in perspective: 

In a majority cf cases, particularly when the organiza- 
tier. lespcnsible for designing ana implementing the 
system has experience of similar systems and when the 
users are clear about what taey want, the linear 
strategy is pefectly satisfactory and produces gcod 
regults. Too often, a project starts on the linear 
strategy but the initial requirement is vague, over- 
ambiticus or fails to meet the real need: in fact the 
requirement is still fluid. The project then proceeds 

in a series of shcit locps as the requirement solidi- 
fies. . . . [Bef. 36] 

Now it becomes clear why Gladdan's representation in Figure 
3.3 appears as it does. To make up for the reality of soft- 
ware design, the practice is to use a 'loopy linear* 
strategy. That is, to proceed in a series of relatively 
haphazard and short-term locps. Again from Brittan: 

Some loops are inevitable- One of the symptoms of 
excessive loopiness is a feeling of antipathy between 
the different grcups associated with the project. 

.n g what - n e y 

be anncyed by the apparent lack of good project manage- 
ment as the system overruns its budget in both time and 
cost. [Ref. 36] 

Brittan gives other reasons why the linear strategy is pocr: 

1- when analysts refine the requirements of a system, 

their investigations and studies frequently threw up 

problems which were not suspected at the outset. 

2. the linear strategy can only be based on studies and 

investigations made by analysts; users, who determine 

the success of the system, are not usually adept at 

the conjecture and extrapolation needed to understand 

these studies. 

Land [Ref. 29], Brooks [Ref. 46], Podolsky [Ref- 24], Zave 

[Ref.. 32], and Lehman [Ref. 47], to name a few, have all 

argued that a system will require substantial, continuing 


changes after the client begins to use the system. We tsnd 
tc relegate this phenomenon to * Maintenance* . But this 
isn't enough. Consider this comment by Land: 

The conventional model of the systems life cycle assumes 
that an analysis and feasibility stage precedes the 
detailed design stage and that this will be followed by 
a specificiaticn and agreement of the specification for 
the system. At that point the design of the system is 
often frozen. For a typical information system the 
staaes precedina the design freeze take between 20^ and 
35 ?{ of the total time required for the develoment of the 
system. For between 65% and 80% of this time the design 
of the system is not to be modified, even though tne 
"world" is changing all the time. In practice, even a 
frozen design gets modified if the system is seen tc be 
becoming irrelevant to real requirements. Further, 

inconsistencies in design are discovered during the 
construction chase as a result of "systems queries". 
[Ref. 29 : p. 58] 

Software design, no matter how hard we try otherwise, is 
simply net linear. The literature clearly supports an 

evolutionary strategy, yet our practice has not recognized 


The preceeding discussion shows that there is support in 
the literature for reassessing our view of software design. 
Software design is symmetrical, but we currently do little 
to recognize that symmetry. Software design is satisficing, 
yet there is constant amphasis on optimization, often for 
its own sake and forsaking approaches that enhance th^ 
useability or quality of the software. Perhaps, without 

consciously noting it, we are also concerned with the "test" 
design and dooming the project to mediocrity, at best, and 
perhaps catastrophe. 

Software design, especially for large-scale systems, is 
certainly a "wicked problem." All the evidence is there; it 
only remains to acknowledge that fact. We are well aware 
that communications between the designer and user are 


all-impcrtant. Yet, we have not really given much thought 
to the medium of exchange. Software design is a learning 
experience. Designers learn that projects are more complex 
than expected and users learn never to trust designers. 
This may he a harsh critique, but the point is well illus- 
trated: all parties gain something from the experience of 
software design. Let us recognize the worth of this- 

Tfce organizational context of software design has long 
been ignored, particularly in military systems. We must not 
forget that the computers are to help the people in a s yste m 
l2 ESlJSIJ wel l, not to control the people as a part of the 
system. Finally, we are beginning to racognize that soft- 
ware design is evolutionary. There really is no "snd" to a 
projecx, simply a restatement of rhe goals originally iden- 

although seven characteristics have been seated and 
discussed, their irterdependencies are obvious. Non-^ of 

these characteristics is munually exclusive of another. 
Rather, €ach builds en the ether. Although there ar« innum- 
erable implications in that statement, the remainder of this 
work will examine one approach which may help us to consider 
the sever characteristics of design in software design. 




For the last 35 years, systems software developicent has 
taen based en the sc-called •system development cycle.* As 
shown in the last chapter , there are several arguments 
against such a cycle. Perhaps the most -ailing argument 
lies in cur process controls. Several authors [Hef. 61 , 
62] have pointed out that in response ro uncertainty and 
increased complexity, there is a tendency to define and 
structure (and increase!) management controls. 

Correspondingly, precise requirements definitions have been 
emphasized. Berrisford and Wetherbe [Ref. 61] believe that 
there is a major conceptual flaw in the traditional view of 
systems development. This is that system design assunies 

that management knows what information is needed and it is 
difficult, if net unrealistic, to ask managers to d<=fine 
their information requirements on paper. 

Hew do software designers cope with this problem? Rich 
and Waters [Ref. 63] have explored this luestion and 
theorize that software designers cope with complex design 
problems by using several mental tools, one of which 
involves simplifying assumptions. The use of simplifying 
assumptions is both necessary and commonly used when 
constructing large and complex systems: 

Given a ccmplex programming problem, expert programmers 
typically choose simplifying assumprions which, thouah 
false, allow them to arrive rapidly at a program which 
addresses the important features of the problem without 
beina distracted by all of its details. The simplifying 
assumptions are then incrementally ^retracted with corre- 
sponding lEodif icaticns to the initial program. Often 
the mam questions can be answered using only the 
initial program. [Ref. 63 : p. 150] 


This us€ * of simplifying assumptions in software design 
is very much like the idea cf the tentative solution, - which 
was introduced in Chapter II. Such a tentative solution is 
only a simplified system. Earl [Ref. 64] calls these 
simplified systems prototypes. Carrying this one step 
farther, Naumann and Jenkins define a prototype system as 
"a system that captures the essent ial fea ture s of a later 
system." [Bef. 62]. The sections wnich follow will 

describe the prototype process, the role of prototypes as 
models, the ways in which prototypes are used and concludes 
by showing how the set of seven desing elements are 
supported by software prototypes. 


The terms protc typ e and p rotot ype systems have become 
rather ccmmon lately, found in both the management litera- 
ture (Harvard Business Review, for example) and the software 
engineering literature (proceedings of conferences and work- 
shops especially). Although i:he term prc noty pe has become 
standard, early descriptions of the process were called 
"heuristic development" and "iterative enhancement" 

[Ref. 61, 65]. 

Regardless of how each of us may use the term, there is 
general agreement that the main purpose of prototype systems 
is exploration and experimentation; "the aim of the early 
prototype is to learn, to find out, to discover." [Ref. 68, 
64, 66]- In keeping with their purpose, prototypes are 
relatively inexpensive, flexible, and simplified systems. 
Bally, Brittan, and Wagner describe the prototype process: 

In the prototype strategy, an initial and usually highly 
simplified prototype verson of the system is designed, 
implemented, tested and brought into operation. Based 
on the experience gained in rhe operation of the first 
prototype, a revised reguirment is esrablished, and a 
second prototype designed and implemented. The cycle is 
repeated as often as is necessary to achieve a 


satisfactcry operational system, bearing in mind the 
possibly escalating cost or each subsequent cycle; it 
may welj. be that orly one prototype is necessary before 
producing the final system. [ Bef . 68: p. 23] 

From this description, four steps are evident [ Ref - 62]: 

1. Identify the user's basic information requirements. 

2. Develop a working prototype. 

3. Iirplement and use the prototype. 

4. R€vis€ and enhance the prototype. 
Figure 4.1 illustrates the prototype process- 

A prototype system must be implemented quickly, perhaps 
in hours or days, certainly no more than two or thrae weeks. 
The advantage here is in the user-designer interactions: 
the user is given a working system to operate and criticize, 
the designer receives responses based on the user's experi- 
ences. The quick response of the designer guarantees that 
the first prototype will be incomplete. This aspect is 

important: there is an explicit understanding between the 
user and designer that zhe system will be incomplete, that 
a prototype is msant to be modified, expanded, supplemented, 
or supplanted [Ref. 62]. 


Many authors consider prototypes to be models [Ref. 64, 
82r 69]. As models, prototypes reduce risk and test alter- 
native designs through live operation. [Ref- 64]. 

Three aspects of prototypes as models are imporxant. 
First, models are abstract: 

The critical skill cf system design is . . . claimed tc 
be explication of the implicit models in managers* 
minds, of their decision-makina processes and views cf 
their organisation and environment. [Ref. 64 : p. 163] 


Figure 1.1 The Prototype Model. 

Second, managers prefer siaiple modals at first. As they 
begin to understand the models, they become involved with 
the design and implementation to build more realistic 
systems. [Bef. 6U]. 

Third, a prototype is subject, to modelling effects. 
That is, as a model, the prototype is only a limited version 
of the final system. So, a prototype is one kind of scale 
model, accurate in some ways, inaccurate in others 
[Ref. 69]. 



Three strategies are generally recognized for producing 

prototypes, 1) methodologies (in current use) , 2) executable 

specifications (state-of-rhe-art and research issues) , and 
3) automatic programning (a research topic) . 

'' • I^S 'Methodolcqy * Strategy 

There are three basic methodologies which are used 
to produce software prototypes. First, in screen and repcrt 
formatting, the designer produces a set of user interfaces 
which will be similar to the final sys-em. Second, in 

partial and incomplete implementation, the designer and user 
identify only a subset of the total problem. Third, for 
selective iiplementation , the designer develops components 
of The final system and then integra"te the components. 
[Ref. 71] 

2 • Hxecutable S£6ci fie ations 

The executable specification, -he second tschnigue 
for prototyping, is a current 'hot' ropic in the computer 
science literature. Davis [ Hef . 72] describes a software 

tool, the Feature Simulator, which "executes" formally 
writter requirements specifications for real-time systems. 
Feather [Ref. 73] proposes a methodology for developing 
prototypes from specifications based on the transformation 
of "specification constructs" into an implementation. 
Perhaps the most ambitious work on executable specifications 
is that reported by Cohen and others. They believe that "a 
prototype serves to mitigate both imperfect communication 
and lack of forsight (sic)." [Ref. 74] 

Ihe solution Cchen and others have adopted separates 
the imperfect communication and lack of foresight issues by 
having a formal specification language which unambigiously 


describes systems, and a separate tool (symbolic execution 
system) which helps the reader to understand any particular 
specification. This tool can be used by the specification 
writer to validate the specification and by the implsmentor 
(or buyer) to understand what exactly has been specified 
(i.e., hew the pieces interact). "Given the specification 
and the tool, a prototype will not be needed." That is, if 
the designers can ccmpletely specify the requirements and 
they then use the symbolic execution system, Cohen and 
others believe that ii: is no longer useful to develop a 
prototype . 

Eut consider the following comment by Taylor and 

. . . . having a precise specification language is of no 
help, since tha user really doesn^t know what statements 
to make in such a language — that is, he can't articu- 
late his needs if he doesn't know what they are reaard- 
less of whether or not there is a precise language for 
stating them. [Hef. 78 : p. 160] 

Executable specifications clearly are controversial, 
especially when they concern prototypes. Whether such a 
technique gains prominence will depend on advances in soft- 
ware engineering tools. 

3 • Autcnatic Prcgramming 

Automatic programming is probably farther away, 
technically, than the exacutable specification. Automatic 
programming can be thought of as programs that help people 
write programs. The general goal of automatic programming 
is tc allow the software designer to think cf the problem 
abstractly, in a way which is natural and comfortable. 
Automatic programming systems are characterized by specifi- 
cation methcds (formal, 'by example', or natural language), 
the target language (the language in which the system writes 


ths finished program) , the problem area (area of intended 
applicazicn) , and the method of operation (theorem-proving, 
program transformation, knowledge-engineering, or tradi- 
tional ficblem solving) [Ref* 100]. One advantage cf auto- 
matic programming is that it could allow for more 
informality than an executable specification language 
[Ref. 70]. 


Generally, there are three uses of prototypes, 1) to 
clarify user requirements, 2) to verify the feasibility of a 
design, and 3) to create a final system. [Ref. 75]. 

1 . To Clarify the J se r * s Requirements 

Ey far, the most popular use of prototypes is to 
clarify the user's requirements. McCracken [Ref. 67] 

believes that traditional written specifications do not 
bridge the communications gap between the designer and the 
user. He states that prototypes en c ourag e users to change 
their minds about what they want, until the system is 

To highlight the problems encountered in require- 
ments documentation. Mason and Carey [Ref. 76] make a 
distinction among three types of documentation: 

1 . A textual list of requirements (the most commonly 

2. An interpretive model (gaining in popularity, espe- 
cially in military systems) 

3. A working model — a prototype 

The textual list, the traditional method of 
describing requirements, has a distinct disadvantage. There 
is a psychological distance between a textual list and what 
the users will eventually receive. A lengthy (often boring) 


document does not easily convey a realistic ssnse of hew the 
system will operate and suit the user's needs [Ref- 76.]. 

Interpretive models include SADT and USE. Th=se 

models use top-down decomposition to manage the complexity 
cf large systems, Ihe more detailed these tools are (or 
become), the mor^ specialized the language used. This pres- 
ents a significant learning burden to the user [Ref. 76]. 

Erotctypes, en the other hand, present a more real- 
istic view cf the system to the users. The users can easily 
relate their experience with -he prototype to thair 

2- 12 Verify the F eas ibility of Design 

When prototypes are used to verify the feasibility 
of a design, the designers and users are evaluating the 
internal design of the software [Ref. 75]. After the proto- 
type is developed, several aspects of the design could be 
evaluated: the prototype could be used to implement and 
evaluate certain design decisions; the prototype could be 
used to develop and test a production system; the efficiency 
cf the prototype could be examined; or the prototype could 
be developed on one machine, and the final system imple- 
mented en the target (or production) machine, when it 
becomes available. 

3 • I5 Create the Final Syst em 

Prototypes may be used to create the final system. 
This means that part or all of the final version of the 
prototype may beccme part of the production system 
[Ref- 75]- Examples of this technique might include data- 
base managenment system (DBMS) applications. For example, 
once created, the prototype might remain unchanged espe- 
cially if the system efficiency is satisfactory. On the 
other hand, critical (or perhaps all) of the system would be 


r€Cod€d for efficiency, either in the DBMS language, in a 
host language, or in assembly language. 


'' • Prototyping is a Symmetri cal and Adaptabl e Process 

Prototypes explicitly address the symmetry and adap- 
tation necessary in software design. Naumann and Jenkins 
[Ref. 62] believe that prototypes provide an appropriate 
response to changes in the development process (protlems to 
solve and available resources) as well as to changes in the 
environment. Bally, Brittan, and iJagnar state that the 
prototype strategy is an admission of failure, an admission 
that there will be circumstances when we will be unable to 
develop the right system on the first attempt [Hef- 68]. 
Earl's comment perhaps best expresses the overall idea of 
symmetry and adaptation: 

The prototype 3ysts=ni . . . allows . . . d^siar. bj 

disc over y as much as by prediction, where the unexpectea 
results niay be as significant for design as the 
expected, (emphasis added) [ Bef . 64 : p. 166]. 

2- Prot oty ping 'Tames' the Wicked Proble m 

In Chapter II wicked problems were described as 
problems where the information is Gonfusi::ig, where there are 
many clients with conflicting values, and where the raniifi- 
caticns in the whcle system are thorougly confusing. 
Compare those characteristics to the experiences of Asner 
and King: 

. . . . the prototype approach works when users do not 
know their specific requirements, [where] the effective- 
ness of any on particular approach cannot be easily 
assessed without rsal-life experience, . . . [where] 
the system will be an integral part of the day-to-day 
activities of the users. . . . [Ref- 79 : p. 30] 


Developing prototypes does more than recognize 
wicked frcblems. The designers and users of prototypes 
explicitly acknowledge such things as: 

1. Wicked problems have no definitive solution — as Eally 
and others have stated, prototypes are an admission 
that more questions can be always asked and more 
information can be requested. 

2. Every fornulaticn of the wicked problem corresponds 
to the foriulation of the solution (and vice 
v€rsa)--there is an explicit understanding between 
the desinger and user about basic assumptions that 
will be made when designing a prototype, especially 
the first version; the protcype strategy is designed 
tc cope with a fluid situation and fuzzy requirements 
[Bef, 68]- 

3. Wicked prcblens have no stopping rule — designers and 
users realize that prototypes may be continually 
modified or refined until some exxernal limit (time, 
resources, production need, user satisfaction, etc.) 
is reached. 

U. Solutions to wicked problems cannot be correct or 
false. They can only be good or bad--protctyping 
explicitly recognizes the notions of "technically" 
correct and "psychologically" correct. Users contin- 
ually ask for refinements until they become satisfied 
(i.e., where the system is technically and psycho- 
logically correct) . 

5. In solving wicked problems there is no exhaustive 
list of adiiissable operations — prototypes allow 
designers and users the freedom to explore and exper- 

6. No wicked problem and no solution to it has a defini- 
tive test — designers and users become quickly aware 
that prototypes clearly identify tradeoffs. The 


pictctype may te flexible and sacrifice (i.e., "fail" 
the test for) efficiency. 

3* Sof twa re Prototyping is Satis ficin g 

Recall from Chapter II Simon's argument that people 
accept alternatives which are good enough, not because they 
want to, tut because they have no choice. In Chapter III 
evidence was presented which clearly shows that software 
designers constantly balance trade-offs and are fcrced to 
accept satisfactory alternatives, rather than an optimal 

The process cf developing a prototype explicitly 
deals with satis ficing by recognizing the interaction among 
the user, designer, and system. Conflicting goals and 
priorities are inevitable. Negotiation between the designer 
and user will lead tc a satisfactory system. 

In the prototyping process, the designer constructs 
successive versions of the system, compromising and 

resolving conflicts tetw^ien "che context (-hat is, user n9€ds 
and desires) and the form, as constrained by technology and 
economics [Bef. 62 : p. 37]. 

^ - Prototyping is C omm unic atinq 

The prototype facilitates communication between the 
designer and the useri The basic model of the prctoype 

process shows that ccmmunication is a necessary element of 
the process. Without communication there is no prototype. 
Mason and Cary £Ref. 76] believe that prototyping overcomes 
the fundamental problems of ccmmunication between users and 
designers. Naumann and Jenkins [Bef. 62] emphasize the 

roles participants have and believe that prototyping 
stresses the interactions between the user and the designer. 


Farticipatior in software design can be pai^.ful 
[Ref. 6 4], yet 

Users play more active roles in prototyping than is 
possible with traditional development methods. Users 
set the development pace by the time they spend using 
and evaluating the prototype. They decide when the 
cycle cf evaluation and refinement ends. [Ref. 62 : p. 
37] L r 

The prototype approach exploits the interaction 
between the designer and user. Contrast this with the care- 
fully mcnitored interaction in the tradirional approach. 

5. The Sof twa re Prototype is a Learning Aid 

Several authcrs [Ref. 64, 68, 66] agree that the 
very purpose of the prototype is to allow the user tc learn 
about the system; experience with the system is the most 
valuable product. When prototyping, both designers and 

users learn, developing a system which is more realistic in 
its econcmic purpose, organizational context, and technical 
performance [Ref- 64 : p. 166]. 

Earl [Ref. 64] believes that prototype systems 
permit action learning and that there are few other vehicles 
available for live and flexible organizational development. 
As a vehicle for learning. 

. . . . the protoype model is the most effective repre- 
sentation possible since it enables evaluation of the 
proposed design in con -cext . The prototype model is the 
representation tEat an"^cipates evaluation of the design 
in its operating environment. [Ref. 62 : p. 33] 


6 • lii Ft o t ot y p € Processs Accounts for Organizat iona l 

As pointed out in Chapter III, the organizaitcnal 
context is an important consideration in systems and soft- 
ware desicn. Informal organizational structures and the 
sub-elements of organizations play large roles in the 
success cr failure of a system. As an experiment, the 
prototype provides an opportunity to test the impact of a 
systeu and experiment en the organization's interfaces, at 
least reducing the risk of a nonviable system and also 
providing opportunities for introducing and monitoring job 
satisfaction improvements, organization development, and the 
like [Ref. 6U: p, 164]. Earl believes that prototypes are 
relevant to organizations because of individual differences 
among pecple in the organization: 

- . . . the prototype methodology mav be relevant, for 
different values, perceptions and perspectives do exist 
■ among different interest groups, but the different 
implications and impact of a system design mav net be 
apcrsciated until it is implemented; indeed'all the 
options may not be apparent." With a working prctotvpe 
system design values mav be explicated and stakehciders 
counter the technical thrust of the specialists. . 
[R€f. 64 : p. 165] 

To say that prototyping "solves" the organizational 
issues in software design is, however, going too far. 
Prototyping deals expl icit ly with the issues, yet requires 
quite a bit of "orchestration". The management cf the 

process is not without political consequences [Ref- 66]. 

Hew do we measure the worth of a prototype as it 
contributes to our design of software? Earl answers this 
question with the following statement: 

Possibly the most valuable contribution of the prototype 
methcdclogy is to foster a climate of system apprecia- 
ticn, user creativity and experimentation, intelligent 
use and organisational learning. [ Ref . 64 : p. 166] 


"^ » li® Prototype Proc ess is Evol utionary 

That the process of protoyping is incremental and 
evolutionary shold ccne as no surprise. The important point 
is that the prototype process, again, explicitly deals with 
the issue. Software design has been shown to be evolu- 

tionary, yet traditional software development is unable to 
deal with it. Naumann and Jenkins [Ref, 62] state, as a 

•principle', that "[p]rot otyping represents and parallels 
the dynamic process of growth, change, and evolution 
existing in any living system." 

A survey of the literature reveals an interesting 
pattern among the models for prototyping. Although most 

authors will agree that the traditional life cycle is not 
evolutionary, with the exception of Naumann and Jenkins 
[Bef. 62], (see also figure 4.1) Basili [Ref- 65], Bally and 
ethers [Bef- 68], Earl [Bef. 64], Mason and Carey [Ref. 76], 
and Zvegintzov [Ref. 57] all attempt tc force a c ycli c 
structure on software development, 

Perhaps a review of evolution is in order. When 
some thing (animal, crganizaiton, or design) evolves, it 
begins simply (a few cells, a few people, a few details and 
many simplifying assumptions) and grows in complexity, often 
changing remarkably from ixs humble beginnings. This 

process is clearly net cyclic. Rather, a betner image is 

the spiral, much like the spiral coil of the shell of the 
Nautilus, growing in size yet maintaining the essential 
nature it began with. 

Figure 4.2 illustrates the evolutionary nature of 
prototypes. Each "chamber" can be considered to be a single 
prototype, the wall of the "chamber" denoting the point of 
refinement and enhancement. The only restrictions on the 
number of "chambers" (prototypes) are in the environment 
(exhausted resources, end of time, too complex or unwieldy, 
and so en) . 


Figur« 4.2 Evolution of Prototypes- 


This chapter has explored the multi-faceted aspect of 
the software prototype: the process, its role as a model, 
construction strategies, and uses. The chaptsr concludes 

with a persuasive argument that prototypes explicitly 
support the seven design slements. 


Several conclusicns can be stated at this time. First, 
the current practice cf software engineering only recognizes 
a few cf the design elements described in Chapter II. 
Software design completely ignores the fact thax: these 
elements are interrelated and mutually dependent. The 

traditional method of software development only worsens the 

Second, the prototype approach to software design and 
development naturally supports the set of design elements. 
For example, the prototype approach encourages, requires, 
and exploits the interaction and communication between the 
user and designer. Ey making this explicit, prototypes will 
lead to a better design. 

Third, developing better systems, delivering them on 
time and within budgets are in our best interests. The 
prototype approach will allow software engineers and 
designers to achieve these goals. 

The next chapter briefly describes software engineering 
environments and how such an environment could and should 
support software prototyping. 




Most authors agree that prototyping has become possible 
through recent develcpments in computer technology [Ref. 61, 
62]. Ccllectively, this technology is called the software 
engineering environment (SE2) [aef. 83], the programming 
support environment [Eef. 107, 105], or the software devel- 
opment environment [ Bef . 84 ]. 

There are as many definitions for, as there are 
references to, a software engineering environment. The 

definition offered by Hausen and Muellerburg s^ems to be the 
most satisfying: 

[A Software Engineering Environment is ] an instrumented 
and organized software development laboratory where many 
people cooperate viith each other in a fully organized 
worxina orocess, in the design^ construction, examina- 
tion, tuning and maintenance or software. [Ref. 83 : p. 
147]. '■ 

Generally speaking, the literature cites two approaches 
to computer-aided design for software development: 1) the 
SE2 is a systematic approach, and 2) toolboxes or toolkits 
which support specific software development activities 
[Eef* 85]. The UNIX development environment is an excellent 
example of -^he toolkit approach [Ref. 86]. The facilities 
of UNIX may be thought of as a "tool kit" from which the 
developer can select tools that are appropriate for a 
specific task. Detailed discussions of the UNIX environment 
and available tools can be found in [Ref- 87 , 88]. 

The toolkit approach, however, has been criticized 


1. Tools are not organized to support specific software 
d€V6lcpment methodologies; 

2. Tools do not capture management or control data for 
software development; and, 

3. Individual tools are largely uncoordinated [Ref- 89]. 
Lauber has reviewed 11 tool systems in practical use and 
finds that only two systems (PSL/PSA and PDL) are m wide 
use. 8 

There are several "programming" environments in active 
use (for example, Interlisp [Ref. 90 , 86 , 91] ), or 
planned (for example, the Ada programming support environ- 
ment (APSE) [Ref. 93] ). Unfortunately, there is no 3E2 
which specifically supports the prototype process. This 

chapter will first describe some general characteristics of 
SE2s and then explain those elements of SS^s which are 
needed to support software design and prototyping. 


'' • development Suppor t Task s 

There is general agreement that an SE^ supports 
three development "tasks": 1) software production manage- 
ment, 2) technical aspects of software development, and 3) 
user participation in applications development [Ref. 83, 94 
, 95]. An SE2 aids software management by "capturing" 

information about design decisions and the progress of the 
development itself. An SE2 supports software development by 
providing automated tools. During rhe developmen*: of 

specific applications, the SE2 places special emphasis on 
the rcle of user-designer interaction. 

^Erofclem Statement Language/Problem Statement Analyzer 
and Prcgiam Design language. A derailed review of the 
various tools and environments in current use can be found 
in S^ffl^csium on Softw are Eng ineering Env ironmen ts , Huenke, 
edi'^Eor. ~ 


2. Int*; grated 

An integrated SE^ will support the three development 
tasks by unifying the tasks into an ensemble. Integration 
applies to the ease of using and the ease of documenting 
those activities associated with individual tools [Ref- 84]. 
Perhaps cne of the mere important characteristics of an SE^, 
integration makes it easier to combine various tools in 
order to perform a specific function. 

3. Uni for m 

A variety of automated tools are used by the SS2 to support 
the thrse development tasks. For reliable operation, the 

tools must be consistent with one another [Eef. 8U, 9U , 95 
, 96]. If one tool is consistent wirh the rest, the SE^ 
will be easier to use. It is easier to learn and use 

special formats and command structures when they are consis- 
tent among all of rhe tools. 

^ • Sup por t a Sol ution S trat egy 

Ihe technical aspects of software development 
require the SE2 to support two solution strategies, cne 
gensral and the ether specific. Generally, Soni and others 
believe that the SE^ must support different ways of solving 
the problem. [Ref- 84]. That is, the SE^ should support 
many different ways of solving problems. It should be flex- 
ible enough any problem-solving strategy. For the specific 
strategy, Wasserman and others believe that an SE^ must 
support both the software life cycle model (the • waterfall* 
model) and any particular software development methodology 
which does not diverge very much from that model [Bef. 94, 
95, 97]. In either case, the objective is the same: to 
arrive at a solution. 


5 . Adactabl-s 

For practical reasons, an SE^ should be adaptable. 
In most organizations, each of the development tasks is 
covered by different organizational groups, each wixh their 
own styles, attitudes, and so on. Also, the individuals 
within each group bring different perspectives to the job. 
With such a wide range of personalities, a collection of 
tools should bs flexible, changeable, even extensible 
[Ref. 8U]. The SE2 should be able to adapt to the design- 
er's (or user's) sophistication and should provide defaults. 
Defaults cculd be easily changed as users become more 
sophisticated [Ref . SU, 95, 96]. 

6 • Functionally Dnigu e 

Within each development task, there are a number of 
unique functions. To reduce ambiguity, misunderstanding, 
and errors, tools within an SE2 must be functionally unique. 
That is, they must have a singular purpose [Ref- 84, 94, 95, 
96]. Each tool must te limited to a single design function. 

"7 • I Int era ctive 

An SE2 must have interactive system capabilities. 
[Ref. 85, 84, 94, 95, 98]. There are two reasons for this: 
interactive systems aid communication among the participants 
in design, and designers can work at their own pace (inter- 
actively) rather than someone else's (batch) . User partici- 
pation, cne of the development tasks, is simplified when 
using interactive systems. 

8 • Rec ent D eve 1 c^meiits 

Two ideas about SE2s, personal development systems 
and a software engineering knowledge base, seem to unify the 
three development tasks and embody the characteristics just 


statfrd. Personal development systems have all of the char- 
acteristics discussed (integrated, uniform, support a solu- 
tion strategy, adaptable, functionally unique, and 
interactive) . Their most important feature, though, is the 
dedicated support to a single designer [Ref- 89 , 9U , 95]. 
A software environment knowledge base would capture informa- 
tion about the design activity (for example, design deci- 
sions) as well as the development process (a continuous 
effort) for managers, designers, and users [Ref. 96]. This 
knowledge base would make the information easily available 
and wculd be done autcmatically. 


Mcst authors agree that a 'successful* SE^ must support 
a certain view of the design process [Ref. 85, 94, 95, 97]. 
Following the lead of Lauber [Ref. 85], a collection of 
tools, or components, which support the set of seven design 
elements of Chapters II and III, and which suppcrt the 
develop me r.t of prototypes, covered in Chapter IV, is 
presented. This is followed by descriptions of how such 
components suppcrt software design principles and proto- 

1 . Technical Co tt£onent s 

There are several components which should be 
included in an SE2 [Ref. 62, 75, 79, 83, 101]. 

a. Database Management Systems (DBMS) 

A DBMS serves two purposes in an SE2. First, 
the DBMS enables storing and retrieving information about 
the design as well as the development process. For example, 
a record could be kept of when each version of the prototype 
was released, who designed it, relevant design decisions. 


and so on. Second, a DBMS allows for •quick' design and 

programaing of data handling features [Ref- 62, 61, 83]. 
Becall that the ability for quick turnaround of a working 
system to the user is a necessary feature in many proto- 
typing situations. 

b. Generalized Input and Output Software 

Query languages, report generators, and report 
writers are often features of a DBMS (for example, FCCOS, 
RAMIS II, and NOMAD provide these features) , These features 
allow for easy data retrieval and data update. Report 

generators can produce complicated reports with minimal 
programming effort [ Hef . 61, 62, 79, 101]- 

c. Graphics Tools 

Graphics are ideal for representing the large, 
and often complex, s-ructures of non-trivial software 
designs. These tools are particularly suited for the ireth- 
odolcgies which use structure charts. For exampl-^, Delisle 
[Ref. 102] describes a set of graphics- based tools, an Edit 
tool, an Evaluate tocl, a Format tool, and a Clean-up tool, 
which were developed to support Structured Analysis) . 

d. High-level Languages 

High-level languages (variously described as 
non-procedural languages, formal specification languages, 
and so on) have one objective, flexibility [Ref- 62, 83, 
101 ]- Such languages enable the designer to describe" what 
to do" rather than "hew to do" it. The system resolves the 
procedure and should produce executable machine code. The 
designer, given such a tool, can use abstraction to its 
fullest extent (the Gamma software engineering system 
(Ref- 103], for example, specifically supports abstraction). 


€. Interactive Systems 

I^vices and equipment (for example, w-orking 
stations) which support interaction are essential [Hef. 61, 
62, 83, 98]. Interactive terminals give users and designers 
the perception of rapid and efficient operarion and revi- 
sion. Generally, these facilities are adapted from the host 
computer or network of the SE2. (Personal development 
systems cculd be thought of as extensions of interactive 
systems. ) 

f, Applicaticn-ori ented Models 

Models are an important feature of an SE^. They 
are used to support human decision making [Ref. 61, 62]. 
Examples of models which are potentially useful are finan- 
cial lodels (as in FOCUS) or simulation models. Real-world 
modelling [Bef. U3 ] is also an important element in the SE^, 

g. Tools fci Software Testing 

There is clearly a need for tools which siiclify 
software testing [Ref. 83, 101]- Hausen and Mu«=llerburg 
report that most tools of this type concentrate on verifica- 
tion and validation, that is convincing ourselves that the 
program will execute properly. They argue that software 

tools fcr prcgram testing should cover more than just veri- 
fication and validation. They recommend a philosophy of 
quality improvement which includes quality assurance 
(defining software standards and controlling their cbserva- 
tion) , acceptance testing (demonstrating to the user that 
the software is acceptable for operation) , and verification 
and validation. 


2 . Su^£ort for Sc ftwa re Design 

Any SE2 aiust te based on a particular view of- soft- 
ware design. [Ref. 65, 94, 95, 97]. The view presented in 
Chapters II and III is unique, although elements of that 
view may be supported in different ways by different 

Ihe SE2 must recognize, and provide facilities for, 
the symmetrical and adaptable process of design. If the 

solution to a problem changes the problem, features of the 
SE2 must allow revision, interactive use by clients (it is 
their problem, after all), and record-keeping, especially of 
decisions. 9 

The satisficing aspect of design may best be met by 
using the modelling tools of the SE^ , Simulatior. tools can 
help answer "what if" and performance questions. Financial 
models can help decide economic questions. Planning, 

contrcl, and estimating models can also help to decide on 
the wcrth of various tradeoffs. 

The "wicked problem" aspecr is particularly vexing 
in the SE^. High-level languages can help by allowing an 

abstract description as a formulation of the problem. The 
abstract statements are then transformed by the system into 
concrete (that is, executable) code [ Ref . 105, 106, 107]. 

Communications between the user and the designer is 
aided by interactive systems. Graphics also aid user (and 
designer) comprehension. Alexander and others have shown 
how the notion of patterns helps bridge the communication 
gap. Kuc, and others, IRef. 80, 84, 108, 109, 110, 111] 
have adopted this concept in their "forms- based" software 
development environment. The 'forms' within the system are 

'White [Ref. 1041 oresents a model for recording rele- 
vant information acout design decisions durina software 
develop me Et . 


used tc identify and define 'patterns* that are afcovs the 
level of prcgramming language constructs. Although a full 
discussion cf the TRIAD (TRee-based Information Analyzer and 
Developer) system is teyond the scope of this work, it is an 
excellent candidate for an SE^ which supports software 

The interactive facilities and modelling features of 
the SE2 will help tc aid the learning process in design. 
The notion of 'learning by doing* was introduced in Chapter 
III. Tc support that notion, the SE2 should allow the 
designer to learn, early, the consequences of a design deci- 
sion. The designer trust then be given the chance to revise 
his decision, based en the 'operation* experience. 

Organizational issues must be explicitly recogrized 
in ary SZ2, First, there are organizational resources which 
are needed to support the SE^: programmers, operators, 

managers, space and facilities, and the computer hardware 
assocated with the SE2, Second, the work patterns and work 
skills cf the people who work in the SE2 are likely to 
change. Unfortunately, most current development environ- 
ments stress the environment over the users of the environ- 
ment [Ref. 98]. Typically, those environments have "quirks" 
which require people to adjust. The system should adjust to 
the skills and the preferences of the designers who use it 
(using, for example, custom default features). If we 
consider the SE2 as an element of a complex organization 
[Hef. 59, 60, 98], the environment's interaction with people 
is crucial; without that interaction, the SE2 is useless in 
any practical sense. 

Finally, the SE2 must explicitly recognize the 
evolutionary aspect of software design. The current systems 
support the waterfall model of software development 
[Ref. SU, 95]. The database management system, interactive 
facilities, and high-level languages will easily support the 


evolutionary concept of design. Report generators and 

report writers should aid the documenration process as the 
design evolves. 

3. SupFort for the Prototype Pro cess 

The process of developing a software prototype was 
covered in Chapter IV. There are four steps in that 

process; 1) identifying the user's basic requirenents, 2) 
developing a working prototype, 3) implementing and using 
the prototype, and 4) revising and enhancing the prototype. 

An existing database of the SE^ is ideal for identi- 
fiying the user's initial requirements. Hcwever, there are 
problems if the database is empty, Kangasallo [Ref, 112] 

presents a model in which information requirements are 
interpreted as a set of complex queries by the database 
management system. Additional features of that ircdel 

include a 'program constructor' which generates code based 
on the queries. A working prototype is a result of this 
model • 

Another method depends not only on the database 
management system but also en the automated tools within the 
SE2. Cheatham [Ref- 105] presents a system in which the 
designer and user develop an abstract model of the prcblsm 
(possibly from the database). Transformation refinement is 
applied (by the automated tools) which results in executable 
code--a working prototype. 

In both of these instances, the SE2 supports the 
development of the user's basic requirments followed fcy an 
automated process of developing a working prototype. It is 
important that some effort be made to analyze the user's 
requirements so that reasonable queries can be made and 
reasonable codels (of the problem) can be developed. 


other systems are available which help to develop a 
basic set of user requirements. Some ara quixe complsx 
[Ref. 32] acd might be difficult to integrate with the SE^. 

Developing a working prototype, quiclcly, should not 
be difficult to accomplish in the SE^ . High-level 

languages; code generators; transformation refinement 

(mentioned above); application development systems, such as 
ACT/1 [Be£. 76] and, application generators [Ref. 75] make 
it easier to develcp working prototypes. Ideally, the 
system would be completely automated. 

An abstract model allows the designer to focus mcr? 
easily on the results of his or her decisions, rather than 
the implementation details. An abstract model also promotes 
flexibility when it is reused. [Ref. 105] 

Inplementing and using the prototype becomes much 
easier wlren interactive systems are used. User interaction 
is essential and interactive terminals allow the user to 
perceive rapid operation and revision. They also help to 
speed user evaluation [Ref. 62]. 

Bevision and enhancement are facilitated in th? SE^ 
by using the database management system, high-level 
languages (and abstract models) , the generalized input and 
output tools, and graphics tools. The database contains a 
record of past designs and design decisions, changes are 
easily made to abstract models and high-level language 
constructs, default values of the generalized input and 
output tools are easily adjusted, and the graphics tocls 
will enable both users and designers to spot patterns 
quickly. The user is quickly accommodated, the database 
management system automatically tracks versions and design 
decisions, and the designer is able to defer low-pricrity 
details without fear of compromising the design: the SE2 

relieves the designer of much, if not all, of the drudgery 
normally associated with software design. 



The preceding sections have reviewed the characteristics 
needed in a software engineering environment, have identi- 
fied the components of a software engineering environment, 
and have described hew the components interrelate to support 
both software design and t.he prototype process. 

It is dcubtful that there are any software engineering 
environments which support completely the idea of proto- 
typing- Tc a limited degree, commercial systems, such as 
FOCUS, NCMAD, fiCT/1, to name a few, support particular 
aspects cf the prototype process. For example, FOCUS and 
NOMAD facilitate applications programming in the business 
community by allowing the designer to customize reports or 
other appplications for a specific user, or group, based on 
an already existing databa se--th6 vice-president of sales 
might be interested in the sales of a parxicular product in 
a particular geographical area. ACT/1, and other similar 
products, make it easiar for designers to customize the 
formats cf terminal screens for the user. 

The products mentioned here are three of several hundred 
commercial and research systems and environments. This 
chapter has purposely avoided a lengthy review of any of 
those hundreds, and mentions a few by way of example only. 



The four cases which follow were chosen because in each 
there was an explicit decision began to develop and use 
software prototypes before the project began. 


Heckel [Bef. 113] describes the process of developing a 
ptototype while designing the Craig translator. The project 
team explicitly chose to develop prototypes for several 
reasons. First, they were concerned about the problems 
which users would a ctuall y experience, rather than these 
problems which the designers imagined might be important. 
This concern is directly related to the symmetry aspect in 
design. That is, the solution and problem interrelate such 
that the solution depends critically upon the context of the 
problem. In this case, the context is the consumer's use of 
the Translator. If the product does not perform as 

"expected", it will net sell. 

Second, the project team was interested in postponing 
decisions about restraints on the final system until they 
had to. In other words, their design evolved. The 

designers ignored certain restrictions which had been placed 
on memory size, as long as they carefully considered the 
effects of their decisions on the production version of the 

Third, the project team planned to use the prototype as 
the software specification. Because they had two "versions" 
of the prototype, a black box translator and the program 
listing, they thought that they would avoid the traditional 
misunderstandings and contradictions often found in written 


software specif icaticns. In this case, the designers were 
concerned atout communications, not only between the "user" 
and the "designer" but also among themselves. 

Heckel's description shows that the prototypes (there 
were 30 versions!) were used to clarify requirements and to 
verify the feasibility of the design. Heckel states that if 
they had been forced to make a particular design decision 
earlier than they did, they probably would have made a less 
satisfactory decision. 

The project was judged a success, although progress 
seemed slew and painft:!. Heckel identifies four benefits of 
developing prototypes: 

1. The project team could keep trying new things; 

2. The prototype was a good model of the final product, 
sc everyone had similar expectations about what the 
product would do; 

3. Several decisions could be postponed without 
affecting the schedule; and, 

U. The designers focused their efforts on opportunities 
rather than problems. 
The development process had some disappointments: soft- 
ware development took longer than expected and the final 
product took more menory than expected. Heckel did not 

speculate on whether these "disappointments" could have been 
avoided. One interpretation is that the designers were 

unable tc meet all of their objectives and when time ran out 
their design was judged to be good enough. Thus, the 
"disappoir.tments" can be attributed to the satisficing 
aspect of design, especially the need for more memory. The 
designers obviously made a trade-off between the "goodness" 
of the product and the amount of memory they had originally 


Ihi^ case illu strat ed how the use of proto type s 
addresses the symmetry, evol ution , c ommunic ations,- and 
satis f icing aspects of d esi gn. 


Hemenway and McCusker [ Bef . 116] describe an exploratory 

project which is leading to the development of an order 

negotiation and entry support sys-em for telephone service 

(the Bell system). The project is the development of the 

user interface and the supporting software for the system. 

There are two reasons given for building an operational 
prototype: 1) to evaluate the user interface and 2) to 
assess the feasibility of a particular software architec- 
ture. Even though the reasons coincide with two uses of 
prototypes (that is, to clarify user requirements and to 
verify the feasibility of a design) they are related tc two 
aspects cf design. The aspects are learning and communica- 
tion fcetween the designer and 'iser. 

Prototypes of the software were daveloped to determine 
whether a table-driven system could be designed. Prototypes 
cf the user-interface were used to determine whether the 
user-interface would substantially increase the length of 
time service representatives spend on orders (compared to 
manual order entry and search). 

The case concludes by stating that the results of the 
prototype evaluation led to making several recommendations 
to the designers of the first release of the system. H ence , 
the prototype served to hel£ the designers l earn m ore about 
their sclut icn and th eir problem . 



Jenkins [Ref. 114] discusses how the decision tc develop 
a prototype led to successful development of an automated 
data processing facility for the Congressional Budget 

Two aspects of software design are apparent in this 
case: 1) communications between users and designers and 2) 
the organizational context of the system. Communications 
between the designers and users was greatly improved by 
using a prototype. Bather than try to decide on the design- 
er's effectiveness ty reviewing written specifications, 
managers witnessed operating demonstrations. The prototype 
also showed non-technical users what it was possible to do 
in their application areas with the new tools. 

By far the most important aspect illustrated by this 
case, is the concern of the designers for organizational 
issues. The Congressional Budget Office serves the needs of 
the Congress, admittedly a ccmplax organization. So, the 
designers needed immediate responses to Congressional 
inquiries, because when information is needed, it is often 
needed iiiiediately or its value is lost. 

This organizational aspect is also closely related to 
wicked problems. Secall that wicked problems refer to 
social system problems which are ill-formulated, where the 
infornaticn is confusing, where there are many clients and 
decision-makers with conflicting values, and where the 


ramifications in the whole system ara thoroughly ccnfusing. 
Clearly Congress is faced with these kinds of problems. 
There is every reason -o expecr that the Congrss'sional 
Budget Office deals with similar problems when responding to 
Congressicnal inquiries, lo 

Ih^ casg presented b^ Je nkins ill ustra tes how proto types 
can aid software des ign when faced with critica l organiza- 
tional issues and wic ked problem s . 


Groner and others [ Ref . 115] present a case of using 
prototypes to clarify the user's requirements. The case is 
unusual because it started with a proposal from outside the 
user's ccmmunity. The designers set out to determine if and 
how computer tachnclogy could meet the information 
processing needs of medical researchers. 

This case is a clear illustration of the importance of 
communications between the designer and the user and the 
representation used for communicating. 

Prototypes were required in the requirements analysis 
phase because without concrete, working examples our 
potential 'osers could not be sura that computer systems 
are needed, what functions they should perform, or how 
they wculd use them. [Ref. 115 : p. 100*] 

Less clearly stated is the implication of learning 
during the design process. The intitial design of the 
prototype was based on the designer's knowledge about 

loconsider the fluctuations from Congress to Congress, 
chairman to chairman, committee to committee; from year to 
year, week to week, and even from hour to nour during the 
Budget Committee markup sessions [Ref. 114 : p. 22]- 


infornaticn processing needs for medical rssearch. 
Subsequent versions were improved based on use by and 
comments from clinical researchers. The project partici- 

. . . agreed to learn about each other^s disciplines, 
then define prcblems and attempt -co devise and evaluate 
solutions in collaboration with others in the -araet 
user community. [ Bef • 115 : p. 101] 

The project used an incremental implementation strategy 
(evcluticn) under which major software releases ware sched- 
uled approximately every four months. Several hundred soft- 
ware changes were made over a period of a year and half. 
This case shows how prototypes can be used to create the 
final system. I ' 

Ih^ £§^f pr ese nted by G roner and others is an exce llen r 
S^J£2^ 2J hsa c cm m u n i ca ti o n s , le ar ning* an d evolution are 
inte rtwined in software des ign . The development cf proto- 
types helped all of the de sig n participants cope with thos e 
aspects CI s of t. y ar e design . 


These cases illustrate how prototypes help designers 
cope with the seven aspects of design which were covered in 
Chapters II and III. In each of the cases, the authors 
point to success. For Heckel, the prototypes led to a 
product that was easy to use, had a number of useful 
features, and was implemented on a single-chip micropro- 

i^The case description leads the readar to think that a 
"production" system was not developed. Every indication is 
that the prototypes evolved into tne production system. 


Hsmenway and McCusker say only that prototype evaluation 
led to reccinmendations to the designers. From this, w^ can 
safely infer that the prototype aided the designer* s 'ander- 
sranding of the froblem. 

Fcr Jenkins, the overall assessment to the prototype was 
positive. Managers liked the idea of a prototype because 
there was nc prior commitment to a particular course of 

Groner and others believe that the greatest benefi- of 
the prototype is that the prototypes are concrete, working 
examples cf computer systems which are meeting everyday 
needs . 



A new view of design was presented in Chapter II. This 
view identifies a set of seven interrelated and mutually 
dependent elements which were found in the literature. 
Support for these elements was found throughout the computer 
and information science literature. The set of seven 
elements explains how best to cope with the problems, ambi- 
guity, and uncertainty associated with software design. 

The process of developing a software prototype is 
presented as the most appropriate way to incorporate the 
design elements into software design. In fact, the proto- 
type process exploits certain elements, such as communica- 
tion between the user and designer, to improve the overall 
design of the software. 

One of the more important conclusions is that software 
designers, especially designers of large-scale systems, have 
much to learn from designers in other fields. The software 
design literature shews little evidenca of influence from 
other design fields. This wcrk is a start -oward that 

needed transfer cf knowledge. 

The software prototype may be the sensible way tc design 
large-scale systems. Recall that complex design problems 

have been called wicked problems. If some large-scale 

system developments are 'more wicked* than others, then 
developing prototypes seems to be the only way to design the 

Software prototyping enables users and designers to cope 
with ill-defined problems and changing requirements. Past 
experience indicates that bad technical engineering is not a 
problem with software development. Rather, unsatisfactory 
design decisions and faulty information are the real 


problems. Software prototypes provide a mechanism which 
allows designers to test their decisions and t,o learn mere 
about the problem. The prototypes also allow users a 

consTrucyive environmen-c in which to express their satisfac- 
tion cr dissatisfaction and a stimulant in learning hew to 
deal wi-h their problems. 

Software prototypes, however, present special difficul- 
ties fcecaus€ -hay ar€ not the universal remedy for software 
design problems. Careful management is needed to ensure the 
software ptototype is really designed and not just put 
together. Careful thought and planning are necessary before 
coding begins. Managers, designers, and users must remember 
that a software prototype is an experiment. Judgement and 
commitment are needed to control er.diiss iteraticns. 
Managers nust have the wisdom to know when to step. Often, 
while developing successive prototypes, there is a tendency 
to delay formally documenting the system. While this 

problem is not unique to prototypes, there must be attentive 
managenient snd commitment to ensure adTCuat-; and ccuplete 

In spite of these cautions, evidence indicates that 
developing and using software prototypes is the best option 
for coping with software design problems, for ensuring the 
system is delivered, and for ensuring a satisfied user 




D€V€lcping software prototypes presents management with 
some unusual problems. Many of our current management tech- 
niques depend on getting the project done right the first 
time [Ref. 117]. As we are well aware, this seldom occurs. 
Research is needed to assess the effect of prototype devel- 
opment en management. 

1. Hew does the manager decide when to cease development 
of prototypes? When is the project ended? 

2. Hew do managers deal with increased communications 
between users and designers? If special maragement 
ccntrols are needed, how far should they go? 

3. What management style best suits managers of software 
pictetype projects? 

4. How is the project budgered and controlled? Hew is 
pr egress measured? 


Current acquisition and contract management procedures 
and regulations for software appear to be less rhan satis- 
factory, within the Federal Government generally, anc the 
Department of Defense particularly. Even as these proce- 
dures and regulations are changing, there is some evidence 
thai: the traditional model of software development may 
become required. Ihe Department of Defense has begun to 

address the concept of software prototypes in the DoD 
Software Technology Initiatives [Ref. D0D8I : p. 69-71], but 
this research appears to be concerned only with requirements 


1. Hew can or how should acquititicn and contract 
management procedures and regulations accomoda-* tha 
principles of design and software prototyp<3s? 

2. What is the best strategy for encouraging acceptance 
of the software design principles and software proto- 

3. How might the elements of software design and devel- 
oping software prototypes help with the acquisition 
and contract management for embedded computer 


Kling and Scacchi [Ref. 59, 60] reviewed a large number 
cf organizational studies while developing their views about 
the effect of computer systems upon organizations. When 
their ideas are considered within the context of software 
prototypes, further research is needed. 

1. How will chances in theories of organizational devel- 
opment affect the process of developing prototypes? 

2. Is any one organizational theory best suited for 
scftware design and software prototypes? 

3. What are the social dynamics of software design? 

4. What are the social dynamics of developing software 


a fundamental part of design is to satisfy the n^^eds for 
quality. Roolce [Ref. Rook82] has concluded that design is 
the most important factor in determining overall quality. 
Even though one of the objectives of developing software 
prototypes is to achieve user satisfaction (a major element 
cf quality) , research is needed to determine how prototypes 
can affect software quality. 


1. If w€ accept tbat prototypes will affsct a change in 
software technology, how will that change influence 
our perceptions of quality? That is, will software 
prototypes lead users to expect more than can be me-? 

2. How might the concept of Quality Circles fit the 
process of developing software prototypes? 

3. To what extent will software prototypes influence 
software quality? Since prototyping requires 
concensus, who is ultimately responsible for product 
quality and liability? Should anyone be "ultimately" 


The software prototype is the ultimate representation of 
the user's requirements. The written specification anchors 
the other end of the representations scale. 

1. What other types of representations can aid software 
design and the development of software prototypes? 

2. What methods ar? suitable for representing abstrac- 
tions when identifying a user's requirements before 
developing a software prototype? 

3. Hew do different representations affect our percep- 
tions and real world knowledge? Can different, 
initial rapresenta-cions lead to quicker design and 
development of software prototypes? 




1. Bo€hm, Barry W. , Sof twa re Engineering Econo mics , 

Prentice-Hall, Inc., EnglewooH Clitrs, New^ersey, 


Amsterdam^ '1978. 

3. Bcehm, Barry W. and others. Char act eri sti cs of 
Software Q uali ty, TRW Series of Scr^are Technology, 
VoI":~17~No rt h -loll and Publishing Co., Amstardair, 1978. 

4. Peters, Lawrence J., S oft ware Design: Methods and 
Techn igu es, Yourdon Press, Hew YorTTT T981 . 

5. Dunn, Robert and Oilman, Richard, Quality Assurance 
|cr Computer So ftware , McGraw-Hill, NewYork, 19827 

6. Alexander, Christopher, Notes on the Synthesis of 
Form, Harvard Oniversiry Press, Cambridge, MA, T9 54 . 

7. Archer, L. Bruce, "An Overviaw of -he Structure cf the 

8. Jones, J. Christopher, Des ign Methods, Seeds cf Human 

Futures, Wiley Interscience, Jcnn Wiley o SonsT Ltd. , 
IcnacnT 19 70. 

Churchman, C. West, "Wicked Problems," Maragement 
Science, vol. 14, no. 4, December 1967, p. B-TIH-'cTTn. 

10. Alexander, Christopher and others. Pattern Language, 
Oxford Press, 1S74. 

11. Page, J. K. , "A Review of the Papers Presented at the 
Conference," Conf ere nce on Systematic and Int uit ive 
Methods in Engineering, ~ TMusxriaT "DesignT 
IrclitectureT and' Ccm munications,~Tr C. Uones a n d d . 
GT THofnTly, 6^."; TUe McmiTXan Company, New York, 
1963, p. 205-2 15. 

12. Ellinger, John Henry, Design Synthesis, Vol. 1, Jchn 
Wiley 8 Sons, Ltd. London, T95'8. 


13. Rittel, Horst, "Some Principles for the Desian cf ^n 
Educational Svstem for Design," journal of 
Architectural Eaucation, v 26, nos 1-2, Winxer-'Spricg, 
T9717177'771T 1^=7-57 

14. Simcn, Herbert, The Scien ces of the Artificial, MIT 
Press, Cambridce, HA, T9FT7 " 

15. Bazjanac, Vladimir, "Architectural Design Theory: 
Models of the Design Process," Basi c Questions of 
Design The ory , William B. Spiller, eaTT TTiefican 
EIsivief^ruBlishing Co. , NY, p. 3-19, 197U. 

16. Cross, Nigel, Naughton, John, and Walker, David, 
"Design Method and Scientific Method," Design Studies, 
V. 2, n. U, Oct. 1981, p. 195-201. 

17. Smithies, K. W., Princ iples of Design in Architecture, 
Van Ncstrand R€inIiol3"roT7~Naw YorTcT l^'SlT 

18. Popper^ Karl Raimund, Obj ecti ve Knowledga, An 
Evclut ion a ry Ap proac h, OxroF3 University Press, 
Ionaon7^'^72. " ~ 

19- Pclya, G., How To Solve It, A Mew Aspect of 
Mathematical M e^'Ho d,'"2nd e^lT^ion, Princeton University 
■pfessT^^rmce^cn, TTew Jersey, 1957. 

20. Dcdd, W. P., "Prototype Programs," Com pute r, v 13, n 
2, February 1980, p. 81. 

21. 0. 5. Decartirent of 
for the Software Tec. 
3csepTr"C. "BaTz, ^IYj.^r= ^j. 
Defense for Research and Engineering 
Physical Sciences), May 1981. 

22. Madnick, Sturat E. and Donovan, John J. Operating 
Systems, McGraw-Hill, New York, 1974. " " 

23. Peters, Lawrence, 
Design", Softw are 
November 1'g7B7~pT~67 

"Relating Software Requirments and 
E nginee ring Notes vol. 3 no. 5, 


24. Podclsky, Joseph L., "Horace Builds a Cvcl€", 
Datamation, vcl. 23, no. 11, November 1977, p. 

25- Voight, Susan, "Program Design by a Multidisciplinary 
Team", Proce eding s of the First International 
Confe ren ce on 5ortware'"En gia eerinq , ITE'E Compu^r 
SccieTy7~'T9757 f7-53=^^ 


26- - Conn, Alex Paul, "Maintenance: A Key Element in 

Ccmputer Requirements Definition", Pro ceedings of the 
Ccmcuter and So ftware Applications Ccn "fe re nee, "IS^BUT 

pT-'Sni^iros;: -^.e . 

27. McCracken, D. E., and Jackson, Michael A., "Life-Cycle 

Concept Considered Harmful", Softwa re En gine er ing 
Notes, vol. 7, no. 2, April 1982, p. 29^2. 

28. Neumann, Peter G. , "Software Evolution and the 

.etter from the Editor, 
vol. 6, no. 1, January 


Dimensions of Change". Letter from the Editor, 
Software Engine eri ng Notes, vol. 6, no. 1, January 
1"5'8T7 p. T. 

Land, Frank, "Adapting to Changing User Requirements", 
Infcrmation and Ma nagement , vol, 5, 198 3, p. 59-7 5. 

30. Rauch-Hinden , Wendy, "Some Answers to the Software 
Problems of the 1980s", Data Communications, vol- 10, 
no. 5, May 198 1, p. 57-71)7 

31. Lockett, JoAnn, "Using Performance Metrics in System 
Design", Software Engineering Notes, vol. 3, not 5, 
November TT7B7"fT T5B-T5T: — 

32. Zave^ Pamela, "An Operational Approach to Requirements 
Specifications for Embedded Systems", IEEE 
Trans act ions on Software Engineering, vol. SE-8, no. 
37~"Say~T9H"27 pT TSTFI-BT: — ^ 

33. Canavan, Edward M. , "Systems, Relity and the Systems 
Practioner", Journal of Systems Management, January 
1981, p. 26-28": —^ 

34. Gilb, Tom J "High- Lev el Systems Architecture: Design 
by Objectives", Computer , vol. 13, no. 5, May 1980. 

35. Wassernan, Anthony Ira, "A Top-Down View of software 
Engineering", Proceedings of th e First International 
Conference on so rtw are'^ngmeering, I'ETJ'S CompuTer 
Socie^y7"T9757 pr"T^T~ 

36. Brittan, J. N. G., "Design for a Changing 
Environment". The Computer Jou r nal , vol. 23, no. 1, 
February 1980,"p7 TJ-TTT 

37. Peters, Lawrence J. and Tripp, Leonard L., "Is 
Software Design 'Wicked'?", Datamati on, vol. 22, no. 
5, May 1976, p. 127+. 

38. Scharer, Laura L. , "Pinpointing Requirements," 
Datamation, vol. 27, no. 4, April 1981, p. 139-151. 


39. Horning- J. J., "Program Specification: 
Ob£€rvarioDS, " Frogr a m specification , J. 
ed.. Lecture Notes In Computer Science, 
Sprmger-Verlag, Berlin, 1982, p. 5-18. 

IS£U3c and 


vol. 134, 

40. Chafin, Roy I., "The System Analyst and Software 
Requirements Specifications", Proc eedin gs cf the 
Computer and S oftwar e Applications r onfersnc e, 19BtJ7 

41. King, Williair R. , and Rodriguez, Jamie I., 
"Participative Design of Strategic Decision Support 
Systems: An Empirical Assessment", M ana gem snt 
Science, vol. 27, no- 6, 1981, p. 717-726. 

42. Rotsy, Daniel and Farrow, Dana, 
Information System Development: 
Empirical Test", " . - • 

January 1982, 

"User Involvement in 

A Conflict Model and 

Man a gement Science, vol. 28, no- 1 

43. Greenspan, Sol J. , Mylopoulos, 
Alex, "Capturing More World 
Requirements Specification", 
International c onfere nce 
Compu'fer~'Socre'ty press, S 
p. ^25-234. 

John, and Eorgida, 
Knowledge in the 

44- Gilb, Tom, "Evolutionary Development", Software 
Engineering Notes, vol. 6, no. 2, April 1981, p. T7. 

45. Stavely, Allan M. , 
Software Design Aid 
H^^^i r vol. 3, no. 5, 

"Design Feedback and its Use in 
Systems", Software "Enainserina 
November 197"S7'~?^"72-73T 

46. Brocks, Frederick P., Jr., The Myth ical Man- M onth , 
Essays on Soft war e Engineering , Addison- Wesley Co., 
Hsa'amgr MassacFiisetf s, Ty /b.' 



Meir M. 

"Laws and Conservation 

" Second Softw 

20-22 Tugust T57B7-pT 1'5Tr=T45t' 


Large-Program Evolution," Second Softw are Life Cycle 
Manag eme nt W or k sho p, -'^-■^-^ -i^- -TTt-r-w- _ ^-n-n-^i.^-^ - 

48- Frank, James W., "Applications Design by Trial and 
Error", Infosystems, September 1979, p. 76-78. 

49. Hall, Patrick A. V., "In Defense of 
Softw are Engi neering Notes , vol. 7, no. 

Life Cycles", 
3, July 1982, 

50. Lawrence, 
Dynamics" , 
Confe ren ce ^.. 


M. J., "An Examination of Evolution 

Proce edings of the Sixth International 

on sottware Engi neeri ng , IrTES" Tompu^r 

b liver Spring, laryland, 1982, p. 


51. Urban, G. L. and Karash, R., "Evlutionary Model 
Building", Jo i:rna l of Marketing Researc h, vol. 8, 

52. Swartcut. William and Balzer, Robert, "On the 
Inevitable Intertwining of Specification and 
Implementation," C ommuni cations of -che ACM, vol. 25, 
no. 7, July 19fi2,~p. UJ8-7irT77 

53. Zmud, R. W. and Cox, J. P., "The Implementation 
Process: A Change Approach", MIS Q uar terly, vol. 3, 
June 1979, p. 35-4 3. 

54. Bcland, Richard J. Jr., "The Process and PrcducT of 
System Design", Manag eme nt Science, vol. 24, no. 9, 
May 19 78, p! 8^7^^. 

55. Alavi, Mayram and Henderson, John C, "An Evcluticnary 
Strategy for I iplemen ting a Decision Support System", 
Manag eme nt Scie nce , vol. 27, no. 11, November 1981, p. 
13T)9-T3277 ^ 

56. Blum, Bruce I., "The Life Cycle — A Debata over 
Alternative Models", Sof twa re Engineering Notes, vol. 
7, no. 4, October 1987, ?.' ' IB-'ZTr. 

57. Zveqintzov, Nicholas, "What Life, What Cycle?", AFIPS 
Confe ren ce Proceedings, National Computer Conference, 
VoIume~5T7 T-gg^T^P^DBI -56 8. 

58. Gladden, G. R., "Stop the Life-Cycle, I Want tc Get 
Off", Soff^are En gin eering Not es, vol. 7, no. 2, April 
19 82, p. 35^1^. ~ 

59. Kling, Rob and Scacchi, Walt, "Computing as Social 
Action: The Social Dynamics of Computing in Complex 
Organizations." in Ad van ces in Co mpute rs, Volume 19, 
Marshall C. Yovits7'"€aT7'~5canemic PressT NY, 1980, p- 
249-327. r r » f 

60. Kling, Rob and Scacchi, Walt, "The Web of Computing: 
Computer Technology as Social Organization," m 
Advances in Comput ers , Volume 21, Marshall C. Yovits, 
e^TT^l^dsmic'TressT^NY, 1982, p. 1-90. 

61. Eerrisford, Thomas and Wetherbe, James, "Heuristic 
Development: A Redesign of Systems Design", MIS 

^uarterli, vol. 3, no. 1, March 1979, p. 11-19 

62. Nauoann, Justus D. and Jenkins, A. Milton, 

"'or Systems 
12, p. 2 9-44. 

"Prototyping: The New Paradigm for Systems 

Development*', MIS Quarterly, September 198: 

63. Rich, Charles and Waters, Richard C. , "The Disciplined 
Use of Simplifying Assumptions," So ftw are Enginserinc 
Notes, vol. 7, nol 5, December 19877 P* r50-15'^."" 


64. Earl, Michael J., "Prototype Systems for Accountmq, 
Information and Control", accounrinq, Organizaticns 
and Society, vcl. 3, no. 2, TgTBT^pT 161-T7TJT 

65. Basilir Victor E, and Turner, Albert J., "Iterative 
Enhancement: A Practical Technique for Software 
Development", First Int ernational Conf erence on 
Softw are Engme ering T IE£JS computer Society, 1y/5, pT 
5B-F2": — 

66. Asner, Michael, King, Alan and Darke, Raymond G. , 
"Prototyping: A Low Risk Approach to Develcpino 
Ccmclex Systems, (Part 2 — Methodology) ", Business 
guarterly, vol. U6 , no. U, Winter 1981, p. Sa-IBT ~ 

67. Mccracken, Daniel D. , "A Maverick Approach to Systems 
Analysis and Design." Syst ems Analysis and Design : A 
Founaation for the llSU^s," WiTIiam ¥. Co^ferman ana 
o^TTef sT edsTT ""ETsev ler Science Co. , New 
York, 1932, p. ua6-45 1. 

68. Bally, Laurent, Brittan, John, and Wagner, Karl H., "A 
Prototype Approach to Information System Desigr. and 
Develcpment" , Inf orm ation and Management, vol. 1, 
1S77, p. 21-26. 

69. Weiser, Mark, "Scale Models and Rapid Prototyping", 
Software Engineering Notes, vol. 7, no. 5, December 
l^'ElT'pT T5T-T-E5: 

70. Barstcw, David, "Raoid Prototyping, A'atcmatic 
Programming, and Experimental Sc:iences: , Sof tware 
Engmeerinq Notes, vol- 7, no. 5, December 1^B2, p. 

71. Blum, Bruce I., "Rapid Prototyping of Information 
Management Systems". Software Engi neering Notes, vol. 
7, no. 5, December i9H7, p. J5-ld7 

72. Davis, Alan M., "Rapid Prototyping using Executable 
Requirements Specifications", Software Engineerina 
NsIjs, vol. 7, no. 5, December 19B77~pT"19-^^. 

73. Feather, Martin S., "Mapping for Rapid Prototyping", 
Software Engineering Notes, vol. 7, no. 5, December 
ig-SZT^F T7=2TI7 

74. Cohen, Donald, Swartout, William and Balzer, Robert, 
"Using Symbolic Execution to Characterize Behavior", 
Software Engineering. Notes, vol. 7, no. 5, December 
l?'827'p7 25^327 

75. Canning, Richard W. , ed., "Developing Systems by 
Prototyping", EDP Analyzer, vol. 19, no. 9, September 
IS 81. 


76. Mascn, R. E. A. and Gary, T. T. , "An Approach to 
Prototyping Interactive Information Systems", 
Communications of the ACM, vol. 26, no. 5, May 1983, 


77. McCoyd, Gerard C. and Mitchell, John R., "System 
Sketching: The Generation of Rapid Prototypes for 
Transaction Based Systems", Softwa re Engine erin g 
Notes, vol. 7, DO. 5, December 19"8T7 p.'^27-T3'2. 

78. Taylor, Tamara and Standish, Thomas A., "Initial 
Thoughts on Rapid Protoyping Techniques", Software 
Engin eer ing Notes, vol. 7, no. 5, December 19B2, p- 

79. Asner, Michael and King, Alan R., "Prototyping: A 
Low-Risk Approach to Devleoping Complex Systems", 
Business Quarte rly , vol. 46, no. 3, Autumn 1981, p. 

80- Ramanathan, J. and Shubra, C. J., "Use of Anotated 
Schemes for Developing Prototype Programs," Software 
Engineering Notes, vol. 7, no. 5, December I^E^, p. 

i-ni'inv: — 

81. Heitmeyer, C. , Landwehr, C. and Cornwell, M., "The Use 
of Quick Prototypes in the Secure Military Message 
Systems Project", Software Engineering Notes, vol. 7, 
no. 5, December 19H77''P-~"E5^7. 

82. Spiegel, Mitchell G. , "Prototyping: An Approach tc 
Information and Communication System Desian", 
Performance Evaluation Review, vol. 10, no. 1, Spring 
l^Bl, p. ^-17. 

83. Hausen, Hans-Ludwig and Muellerburg, Mcnika, 
"Architecture of Software Systems in theContext of 
Software Engineering Environments," Systems 
Architecture, Proceedings of the Sixth ACM Eur opea n 
■Regional'Ccnf erence- "TTC Science an"3TechnoIogy "Fress 
IIIi^l^ Sn3frey7~Engiand, 1981, p. 147-157. 

84. Scni, Dilip, "Design and Modeling of TRIAD, an 
Adaptable, Integrated Software Environment," Computer 
Science Guest Lecture, Naval Postgraduate School, 
Monterey, CA, March 1983. 

85. Lauber, Rudolf, "Development Support Systems," 
CcmjBUter, vol. 15, no. 5, May 1982, p. 36-46. 

86. Wasserman, Anthony I., "Automated Development 
Environments," Compu ter, vol. 14, no. 4, April 1981, 
p. 7-10. 

87. Kernighan, B. ii. and Plauger, P. J., "Software Tocls," 
First' Intern ati onal Conference on Sof twar e 
Engineering, T'EhU coi5puter'"'Socie^y, 1975, p. 8-13. ~ 


88. Kerniqhan, Brian W. and Mashey, John R., "1h€ Unix 
Proqranrming Environment," Comp uter, vol. i4, no. H, 
April 1981, p. 12-24*. 

89. Gutz, Steve, Wasserman, Anthony I., and Spier, Michael 
J., "Personal Development Systems for the Professional 
Programmer," Co mpu ter, vol. 14, no. 4, April 1981, p. 

90. Barstow, David R. and Shrobe, Howard S. , "Guest 
Editorial: Programming Environments," I EEE 
Transacti ons en Soft ware Engineering, vol. SE-7, ""no. 
57~3€T^m59f T^8Tr~pr"TITI9-T5T}7 

91. Teitelman, Warren and Masinter, Larry, "The Interlisp 
Programming Environment," Computer, vol. 14, no- 4, 
April 198 1, p. 25-33. 

92. Wegner, Perer, "The Ada Language 
Software Engine ering Notes, vol. 5, 
pT-8^"ZI7 — ^ 

and Envircnraenx, " 
no. 2, April 1980, 

93. 0. £. Department of Defense, "STONEMAN," Ha^uirements 
for Ada Progra mming Support Environ ments , TeBruary 

94. Wasserman, Anthony I., "Toward Integrated Software 
Development Environments,: Scientia, vol. 115, 1980, 
p. 66 3-6 84. 


Wasserman, Acthony I., "Auromared Tools in -hs 
Information System Development Environment," Automated 
Tools for Information Systems Design, H.-J. 5chnei'31r 
an'd"! . T. ¥asserman , €^7, 1Tor^'h= Hoi land Publishing 
Co., Amsterdam, 1982, p. 1-9. 

96. Rajaraman, M. K., "A Characterization 
Design Tools." Sof tware Eng ineering Not es, 
4, October 198 27~pT"TTr=1T:r 

of Software 
vol. 7, no. 

Department of Defense, Ada Joint Proaram Office, 

Conce pts and Reguirements, 

97. 0.5, 

Ada Met hod ol ogie s: 
TTovember T9B7. 

; vj u J. ^<= ui — ii -^ , 

98. Prentice, Dan, "An Analysis of Software 
Environments." Software E ngin eering Notes, 
5, October 19 8 1; p. T9-27. 

vol. 6, no. 

99. Korzybski^ Alfred, Science and Sanity, An Int rod uction 
to Ncn-Aristotelian ?ys"Eems and"7?eneral~?emantics, 4tn 
eHi^ion, "" orelace Ey "HusseTT """Heyers, H."D., The 
International Ncn-Aristotelian Library Publishing Co., 
Lakeville, Connecticut, 1958. 





Avron and Feigenbaum, 

Edward A. 

ndpcok of Artificial Intelligence, Vol. I 
uTmann , ~Tnc77~Xos ITItos, raliTornia, 198 2. 

ed. The 

II, William 


101. Ewers, Jack and Vesssy, Iris, "The Systems Develcpraent 
Dil€mma--A Prcgrammmg Prespective, " MIS Quarterly, 
June 198 1, p. 33-4 5. 

102- Delisle, Norman d., Menicosy, David E. , and Karth, 
Norman L. , "Tccls for Supporting Structured Analysis, 
Autom ate d Tools for Information sxstems Design, H.-J. 
3clneT3er an^ 1. T. tTasserman, eHs., "nortl-Holland 
Publishing Co., Amsterdam, 1982, p. 11-20. 

103. Falla, M- E. , "The Gamma software engineering system," 
The C omp uter Jo urn al, vol. 24, no. 3, 1981, p. 

104. White, John R., "A Decision Tool for Assisting with 
the Comprehension of Large Software Systems," 
Autom ate d Tools for I nforma rion Syst ems Design, H.-J. 
^"Eneider ant. 1. T. IJasseraan, "e^s. , ^orxTT-Holland 
Publishing Co., Amsterdam, 1982, p. 49-65. 

105. Cheatham, Thcmas E., Jr., "Programming Support 
Environments," Computer Science Guest Lecture, Naval 
Postgraduate School, Monterey, CA, December 15, 1982. 

106. Lundberg, Bengt, "IMT — An Information Modelling Tool," 
Automated Tools for Information Systems Design, H.-J. 
■JclineTSef an^ 1. T. Tfasserman, "e^s. "TIortTi-Holland 
Publishing Co., Amsterdam, 1982, p. 21-30. 

107. Cheatham, Thcmas E. , Jr., "Comparing Programming 

Support Environments," Software Engineering 

Environments, North-Holland PuBIisTTing Co., Ims^efSam, 

is-siT"?: — r-R2 5. 

108. Kuo. Jeremy and others, "An Adaptable Software 
Environment to Support Methodologies," Technical 
Report TRIAD-2, Department of Computer and Information 
Science, Ohio State University, January 1993. 

109. Kuo, H. C. , Li, C. H., and Ramanathan, J., "A 
Form-Based Approach to Human Engineering 
Methodologies," proceedings of the 6th International 
Conference on scttware Engine ering , IFEE Computer 
Science "Press, I^HTJ p. 23'5-2&3. 

110. Kuo, H. C. , and others, "System Architecture of an 
Adaptable Software Environment," Department of 
Computer and Information Science, Ohio State 
University, Technical Report, TRIAD-TR- 1-83 . 

111. Ramanathan, J. and Soni, D- , "Design and 
Implementation of an Adpatable Software Environment," 
to be published in the J ournal of Com puter Lan guage s. 



Kangasallo, Hannu and others, "System D — An Integrated 
Tccl for Systems Design,' Implementation and Data Base 


113. Heckel, Faul. "Designing Translator Software," 
Datamation, vol. 26, no. 2, February 1980, p. 13a-138. 

114. Jenkins, C. Wesley, "Application Prototyoing: A Case 
Study," P erf or manc e Evaluation Revie w, vol. 10, no. 1, 
Spring 19H17"pT~2T-27. 

115. Grcner, Gabriel P., and others, "Requirements Analysis 
in Clincial Research Information Prccessina -- a Case 
Study," Computer, vol. 12, no. 9, September 1979, p. 
1CC-i08. — 


117. Keus, Hans E., "Prototyping: A More Reasonable 
Approach to System Development -" Softw are Enqineerinq 
Notes, vol. 7, no. 5, December 19 877"pr"^7-?5. 

118. Rocke, Denis, "What is Quality and How is it 
.Maintained?," Frc cee din gs of the Roval So cie ty of 
Lcr.dor, Vol. 3 8TT7~'8"~Tune 1^27"*?. "2ir5^617 * 



1. Defense Technical Information Center 
Cameron Station 

Alexandria, VA 2231 £* 

2. library. Code 1U2 

Naval Postgraduate School 
Konterey, CA 93940 

3. Cepartirent Chairiran, Code 59 
Department of Administrative Sciences 
Naval Postgraduate School 
Monterey, CA 93940 

4. Curricular Office, Code 37 
Ccmputer Technology 

Naval Postgraduate School 
Monterey, CA 93940 

5. Professor Gordon C. Howell 
Department of Information Systems 
Georgia State University 
Atlanta, GA 303C3 

6. CAPT Bradford D. Mercer, USAF 
Code 52Zi 

Naval Postgraduate School 
Monterey, CA 93940 

7. Associate Professor Roger D. Svered 
Code 5 2Ev 

Naval Postgraduate School 
Monterey, CA 93S40 

8. Assoc. Professor Poaer H. Weissenger-Bavlon 
Code 54Wr 

Naval Postgraduate School 
Monterey, CA 93940 

9. LCDS John R. Hayes, USN 
Code 54Ht 

Naval Pcsrgraduate School 
Monterey, CA93940 

10- Mr. Michael R, Kirchner 
4343-204 Americana Drive 
Annandale, VA 22003 

11. Professor A. Milton Jenkins 
Operations and Systems Management 
Graduate School of Business 
Indiana University 
Elccmington, IN 47405 

12. Mrs. Mary Jane Kirchner 
135 S. ElfflwooQ Ave. 

Oak Park, IL 60302 


No. Copies 

13. Air Force Contract Management Division 

Ccmfuter Systems Contract Management Division 
Embedded Computer Resources Focal Point 
Kirtland AFB, NM 87117 




K(i97' ■"'"the software enSl"