[comp.software-eng] Prototyping and the Development Process

kraus@se-sd.SanDiego.NCR.COM (Dave Kraus) (09/12/90)

I currently work for NCR in San Diego. We are currently looking
into altering our Standard Development Process in order to incorporate the
use of Prototyping during the development of new products. We are especially
interested in an iterative development cycle where staged prototypes are
presented to customer groups for evaluation, and feedback from these groups
are then incorporated into the next stage of the prototype.

Any information concerning methodologies being used elsewhere in the world
would be greatly appreciated. We are interested in any rapid prototyping
environments currently in use. Environments that encourage the evolution of
prototypes into the final product are also of interest to us. We would like
to also to hear about any literature on the subject that others have found
particularly useful.

If you have any information for us, or would like to start a dialogue on
the subject, please send e-mail to me (see signature file). If I get a
good response, I would be glad to post my findings.


-- 
====  David R. Kraus ============ | "Some terribly insightful
|     (619) 693-5539              |  quote that shakes the
|                                 |  foundation of all your
|   kraus@se-sd.SanDiego.NCR.COM  |  beliefs."

larry@pdn.paradyne.com (Larry Swift) (09/12/90)

I would think that many people would be interested in groupware
dealing with this subject.  How about posting replies instead of
e-mail?

Larry Swift                     larry@pdn.paradyne.com
AT&T Paradyne, LG-132           Phone: (813) 530-8605
8545 - 126th Avenue, North
Largo, FL, 34649-2826           She's old and she's creaky, but she holds!

Will@cup.portal.com (Will E Estes) (09/13/90)

<We are interested in any rapid prototyping
<environments currently in use. Environments that encourage the evolution of
<prototypes into the final product are also of interest to us. We would like

I am very much interested in hearing about this as well.  It seems to me
that the problem with many rapid prototyping environments today is that
you have to throw away the prototype and re-code from scratch in C or
something similar.  Has any academic work been done on object-oriented 
environments that let different languages be attached to objects and
share data between them? (i.e., the idea is that you could evolve the language
being attached to the object from something that is easy to program to
something that is suitable for production use) 

Thanks,
Will Estes        (sun!portal!cup.portal.com!Will)

de@cs.glasgow.ac.uk (David England) (09/13/90)

In article <3839@se-sd.SanDiego.NCR.COM> kraus@se-sd.SanDiego.NCR.COM (Dave Kraus) writes:
>
>
>I currently work for NCR in San Diego. We are currently looking
>into altering our Standard Development Process in order to incorporate the
>use of Prototyping during the development of new products. We are especially
>interested in an iterative development cycle where staged prototypes are
>presented to customer groups for evaluation, and feedback from these groups
>are then incorporated into the next stage of the prototype.
>
This has been mentione in the recent past in this group but the paper:

Boehm B W "A spiral model of software development and enhancement", ACM
SIGSOFT SEN, vol 11 no 4, Aug 1986, PP.14-24.

is very relevant to incremental prototyping. And as you are building
interactive systems and of the books on User Interface Design would be
relevant, e.g.


Shneiderman B, "Designing the User interface: stategies for effective
Human-Computer Interaction, Addison-Wesley, 1987.

Thimbelby H, "User Interface Design", ACM Frontier Series, Addison Wesely,
1990.

The later has a useful reading list that you might like to follow up.

Dave

-- 
ARPANet: de%cs.glasgow.ac.uk@{ucl-cs.arpa,nsfnet-relay.ac.uk}
JANET:   de@uk.ac.glasgow.cs
Phone:   +44 (0)41 339-8855 ext 5569
UseNet:  mcsun!ukc!cs.glasgow.ac.uk!de

jjj@polari.UUCP (Jeff J) (09/14/90)

In article <33820@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
><We are interested in any rapid prototyping
><environments currently in use. Environments that encourage the evolution of
><prototypes into the final product are also of interest to us. We would like
>
>I am very much interested in hearing about this as well.  It seems to me
>that the problem with many rapid prototyping environments today is that
>you have to throw away the prototype and re-code from scratch in C or
>something similar.  Has any academic work been done on object-oriented 
>environments that let different languages be attached to objects and
>share data between them? (i.e., the idea is that you could evolve the language
>being attached to the object from something that is easy to program to
>something that is suitable for production use) 
>
The company I work for develops administrative and financial software for
public schools in the state of Washington and we have recently made the
decision to switch to a 4GL (Progress).  One of the advantages this will
give us is the ability to do cost efficient prototypes that we can try
out on sample groups of your users.  With 3GLs this was impractical, at
least in our setting.  The 4GL that we choose includes some prototyping
tools that should allow our user support/consulting staff to develop
some of these prototypes even though they come from a non programming
background.  Of course only time will tell how well this will work :=)

locke@nike.paradyne.com (Richard Locke) (09/18/90)

In article <33820@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
><We are interested in any rapid prototyping
><environments currently in use. Environments that encourage the evolution of
><prototypes into the final product are also of interest to us. We would like
>
>I am very much interested in hearing about this as well.  It seems to me
>that the problem with many rapid prototyping environments today is that
>you have to throw away the prototype and re-code from scratch in C or
>something similar.

Brooks, "Mythical Man-Month" is well known for suggesting that a
prototype be thrown away.  Evolution of a prototype into a product
is a BAD THING and has been intimately related to the failure of
projects I've worked on in the past.  Conventional wisdom is to throw
out the prototype.  This is not a bug, it is a feature.  It allows
the prototype to be brutally hacked together in a short period of time,
and then tossed away allowing the programmers to *really* do it right
the first time.

I dug up an old posting on this topic, which I agree with completely:

----

From pdn!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!ames
!ncar!ico!vail!rcd Wed Oct 25 12:16:01 EDT 1989
Subject: discarding prototypes
Summary: do it as a matter of principle!
Organization: Interactive Systems Corporation

In article <14081@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
> +-- bill@pd1.ccd.harris.com (Bill Davis) writes:
> | In article <> ejp@abvax.icd.ab.com (Ed Prochak) writes:
> | >Prototypes have to be treated as throw-aways,
> | >especially when they work!
> | 
> | I agree with throwing away prototypes when appropriate.
> | But, what makes a prototype something that should be
> | thrown away if it is working and providing useful
> | functions?...

It's not necessarily the characteristics of the prototype itself so much as
a "matter of principle" (a phrase which often suggests "no good reason":-)
to protect the process of prototyping.

If you want to be able to use prototyping, you have to know that when you
create a prototype, it's going to be just that.  Even if it does its job
well, it may not have the sort of internal characteristics that will let it
survive maintenance and adaptation.  Even if it has those as well, you
have to spend some time checking it over from the criteria of production
programs.

That's why I'd say throw it out as a matter of principle.  EVERY prototype
should get tossed.  (Then you can sneak in when nobody's looking and
scavenge the pieces you can use in the real thing...:-)

By protecting the process of prototyping, I intend first that NOBODY
outside the team responsible for implementing the "real" software should
ever even begin to ponder the possibility of hinting at broaching the
suggestion of considering turning the prototype into production code--
that allows the prototyping process to be corrupted from outside.  Nor
should the implementation team itself consider using the prototype, because
that may allow the idea of prototype->production to take root.  They may
also delude themselves into thinking they can use something they really
shouldn't.

However, since I never ever make ironclad rules, I'll admit that there is a
remote possibility that occasionally some significant piece of a prototype
can be used in production.  If you do it, don't blab it around, OK?  It'll
come back to haunt you.
-- 
Dick Dunn rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870

EGNILGES@pucc.Princeton.EDU (Ed Nilges) (09/19/90)

In article <1990Sep18.150322.17690@pdn.paradyne.com>, locke@nike.paradyne.com (Richard Locke) writes:

>In article <33820@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>><We are interested in any rapid prototyping
>><environments currently in use. Environments that encourage the evolution of
>><prototypes into the final product are also of interest to us. We would like
>>
>>I am very much interested in hearing about this as well.  It seems to me
>>that the problem with many rapid prototyping environments today is that
>>you have to throw away the prototype and re-code from scratch in C or
>>something similar.
>
>Brooks, "Mythical Man-Month" is well known for suggesting that a
>prototype be thrown away.  Evolution of a prototype into a product
>is a BAD THING and has been intimately related to the failure of
>projects I've worked on in the past.  Conventional wisdom is to throw
>out the prototype.  This is not a bug, it is a feature.  It allows
>the prototype to be brutally hacked together in a short period of time,
>and then tossed away allowing the programmers to *really* do it right
>the first time.

I sort of agree and yet I sort of disagree.  I agree that most proto-
types are brutal hacks and should be thrown away.  However, if we had
the right prototype language, allowing us to generate prototypical
code one half of an order of magnitude quicker than C, then the code
in the right prototype language (RPL) could be modified, possibly by
an automatic translator, to C.

In my current environment, I have developed many prototypes in REXX and
some final versions in C.  REXX is a very high level language in which
you simply don't have to worry about data representation because of two
facts:


     *  Everything is a character string

     *  There are NO length restrictions on ANY string, and NO restric-
        tions on what a character string can contain


The genius of REXX is NOT that its syntax follows that of PL/I, as
Mike Cowlishaw seems to believe: it is that the above two laws obtain
in an uncompromising fashion.  Because of the above two facts, "brutal
hacks" are usually not required in REXX, because the typical brutal
hack imposes close to unacceptable considerations on the use or the
maintenance programmer in the name of getting quickly around some
representational constraint.  Things like string length restrictions,
undocumented array bounds, and mysterious relationships amongst
resource allocating constant values come to mind.

Although I lack a REXX to C translator and so in some sense recreate
everything when moving  from REXX prototype code to C code, in another,
stronger sense the same code (same algorithms) run both in the proto-
type and the final version.

Soooo....if you have REXX, use it.  I understand it's now available
in OS/2 Extended Edition, the Amiga and unix.

giboin@andy.inria.fr (Alain Giboin) (09/20/90)

In article <6260@vanuata.cs.glasgow.ac.uk>, de@cs.glasgow.ac.uk (David
England) writes:


> ...
> is very relevant to incremental prototyping. And as you are building
> interactive systems and of the books on User Interface Design would
be
> relevant, e.g.
> 
> 
> Shneiderman B, "Designing the User interface: stategies for effective
> Human-Computer Interaction, Addison-Wesley, 1987.
> 
> Thimbelby H, "User Interface Design", ACM Frontier Series, Addison
Wesely,
> 1990.



You can add the following one :

Helander, M. (Ed), "Handbook of Human-Computer Interaction",
North-Holland,
1988 (Hardbound), 1168 pages, 1990 (Paperback), 1204 pages.

It contains 14 chapters on User Interface Design.




--
Alain Giboin, INRIA Sophia Antipolis -- France
giboin@andy.inria.fr               Phone: (33) 93.65.78.14, Fax: (33) 93
65 77 66
INRIA - Sophia Antipolis, 2004 route des Lucioles, 06565 Valbonne Cedex,
FRANCE

epfra@PacBell.COM (Ellen P. Francik) (09/20/90)

Here are some references on rapid iterative design, including
low-tech (paper & pencil) and high-tech (UIMS) prototyping.
I've found them to be practical guides in daily design, as
well as helpful in explaining the ideas to others.

Good, M., Spine, T.M., Whiteside, J., and George, P. (1986).
User-derived impact analysis as a tool for usability engineering.
In {Proceedings of CHI 86, Human Factors in Computing Systems}.
New York:  ACM, pp. 241 - 246.

Whiteside, J.A., Bennett, J.L., and Holtzblatt, K.A. (1988).
Usability engineering:  Our experience and evolution.  In
M. Helander (Ed.), {Handbook of Human-Computer Interaction.}
Amsterdam:  North-Holland, pp. 791 - 817.

	(The two above discuss how to set usability goals,
	 test for them, and iterate to meet them.)

Gould, J.D., Boies, S.J., Levy, S., Richards, J.T., and
Schoonard, J. (1987).  The 1984 Olympic Message System:
A test of behavioral principles of system design.
{Communications of the ACM} (September), pp. 758 - 769.

Gould, J.D., and Lewis, C. (1985).  Designing for usability:
Key principles and what designers think.  {Communications of
the ACM} (March), pp. 300 - 311.

	(These two are *highly* recommended.  The Olympic
	 Message System paper is a wonderful case study
 	 of rapid iteration and an integrated approach
	 to usability covering everything from on-line
	 help to training of overseas operators.)

Karat, C.-M. (1990).  Cost-benefit analysis of usability 
engineering techniques.  To appear in {Proceedings of the
Human Factors Society 34th Annual Meeting} (Orlando, FL:
October 8 - 12).

Mantei, M.M., and Teorey, T.J. (1988).  Cost/benefit analysis
for incorporating human factors in the software lifecycle.
{Communications of the ACM} (April), pp. 428 - 439.

Nielsen, J. (1989).  Usability engineering at a discount.  In
{Proceedings of the Third International Conference on Human-
Computer Interaction} (Boston, MA:  September 18 - 22), pp. 85 - 93.

	(These are good for The Big Picture.  Mantei & Teorey
	 expand on Boehm's software lifecycle to include
	 both formal prototyping and early, rough mockups.
	 Good summary of what kinds of usability activities
	 take place at different stages.  Read it side-by-
	 side with the Gould et al. Olympic Message System
	 paper.  Mantei & Teorey also show sample calculations
	 of the cost of various usability activities:  focus
	 groups, surveys, lab experiments, and so on.  Your
	 mileage may vary.  Nielsen argues that most people's
	 mileage *does* vary, and shows quick-and-dirty
	 techniques for getting useful information rapidly.
	 Finally, the Karat paper shows the impact of small
	 usability improvements on big systems:  big $$$$$.)

Ellen Francik
epfra@pacbell.com
Speaking from, but not for, Pacific Bell.

gbeary@uswat.uswest.com (Greg Beary) (09/20/90)

  

--
Greg Beary 				|  (303)889-7935
US West Advanced Technology  		|  gbeary@uswest.com	
6200 S. Quebec St.         		| 
Englewood, CO  80111			|

2011_552@uwovax.uwo.ca (Terry Gaetz (Astronomy, U. Western Ontario)) (09/20/90)

In article <11736@pucc.Princeton.EDU>, EGNILGES@pucc.Princeton.EDU (Ed Nilges) writes:
[... discussion of benefits of REXX as a prototyping language deleted ...]

> Although I lack a REXX to C translator and so in some sense recreate
> everything when moving  from REXX prototype code to C code, in another,
> stronger sense the same code (same algorithms) run both in the proto-
> type and the final version.
> 
> Soooo....if you have REXX, use it.  I understand it's now available
> in OS/2 Extended Edition, the Amiga and unix.
-- 
REXX is available for MS-DOS machines too:  "Personal REXX" from the
Mansfield Software Group.  (Mansfield also sells KEDIT, a clone of IBM's
XEDIT.  KEDIT has a subset of REXX, called KEXX, built in as
the macro processing language.)
--

(No connection with Mansfield Software Group other than as an
 Extremely Satisfied KEDIT User.)

Terry Gaetz         --   gaetz@uwovax.uwo.ca   --   gaetz@uwovax.BITNET

ekn@lulea.telesoft.se (Erik Karlsson) (09/20/90)

	Right... Where should I start...?

	What you're looking for is something that everyone wants:

	1) A good model for system development, that among many other
	   things takes care of the prototyping process in a good way.
	   (Supports planning, calculation and all other project
	   controlling and managing functions)

	2) A set of good methods for each step in the model.

	3) An integrated set of tools that supports every single step
	   taken in the model and methods above.

	Am I right?

	Gee, I wish I could offer you, and all other "netlanders", all that!
	I'd make loads of money. :-)

	Lots of work is done in the area, and there are results, that are
	on their way to becoming national and international standards. In
	Sweden there is a national standardisation organization, called 
	SIS. They have recently (september 1989) presented a development 
	model that is a very good step to what we want. It's called 
	"Referensmodell f|r systemutveckling" (Reference model for system 
	development), and it's translated to English. 

	This model has recieved quite a lot of interest around the world,
	and even if it's not perfect yet, it does give quite a lot of what 
	we want as a first step. If nothing else, it gives us a common
	terminology (there are mistakes in it, but it's there), and a sense
	of how to split an everage development process into controllable
	and iterative (prototyping...) steps.

	The model is presented in a small book, that you can order from:

	SIS - Standardiseringskommissionen i Sverige
	Box 3295
	S-103 66 Stockholm
	Sweden

	Phone (int.): +46 8 613 53 50
	Fax (int.):   +46 8 11 70 35

	Its ISBN no. is:ISBN 91-7162-283-7,
	and it's identified at SIS as "SIS TR 321"

	But... Are there any metods in it? No!
	Any tool support? Even less than "no"!

	David R. Kraus wrote:

>====  David R. Kraus ============ | "Some terribly insightful
>|     (619) 693-5539              |  quote that shakes the
>|                                 |  foundation of all your
>|   kraus@se-sd.SanDiego.NCR.COM  |  beliefs."

	Well, my ".signature" isn't that insightful:-

-- 
   / ___           / Erik Karlsson         / I'm not under the alcafluence of  /
  / /    _  * /   / TeleSoft AB, Lulea    / inkahol that some thinkle peep I  /
 / /--  / )/ /_) / ekn@lulea.telesoft.se / am. It's just the drunker I sit   /
/ (____/  / / ! / tel. +4692075422      / here the longer I get...          /

pbreslin@alias.UUCP (Paul Breslin) (09/20/90)

>>I am very much interested in hearing about this as well.  It seems to me
>>that the problem with many rapid prototyping environments today is that
>>you have to throw away the prototype and re-code from scratch in C or
>>something similar.
>
>Brooks, "Mythical Man-Month" is well known for suggesting that a
>prototype be thrown away.  Evolution of a prototype into a product
>is a BAD THING and has been intimately related to the failure of
>projects I've worked on in the past.  Conventional wisdom is to throw
>out the prototype.  This is not a bug, it is a feature.  It allows
>the prototype to be brutally hacked together in a short period of time,
>and then tossed away allowing the programmers to *really* do it right
>the first time.
>

In my mind doing this eliminates one of the biggest advantages of
prototyping. Which is that you move incrementally towards a better and
better solution through an iterative design process. Re-building from
scratch is too costly and wasteful.

If you can't build quality and reusability into your prototypes from
the start, then chances are you won't/don't know how to "do it right"
when you start over from scratch.

"Hacking brutally" and "doing it right" just don't mix well (IMHO).
If you're into the former then you don't fully understand the latter.

I think the big trap to avoid is having the *first* prototype become
the final product. Management has a tendency to say "hey, it works,
let's ship it".

ttw@cbnewsl.att.com (thomas.t.wetmore..iv) (09/21/90)

In various articles:
> ... We are interested in any rapid prototyping ...
> ... something that is suitable for production use ...
> ... decision to switch to a 4GL ... advantages ... is the ability
> to do cost efficient prototypes ... 

AT&T is licensing a meta-translator named MetaTool(tm) Specification-
Driven Tool Builder.  It translates description files into software
tools that are "specification-driven."  These specification-driven tools
(SDTools) can be such things as fourth-generation language processors,
user interface generators, database management system generators,
compilers, device driver generators, etc, in fact, any deterministic text
to text translator program.

Measurements show that MetaTool SDTB increases the productivity of an
SDTool builder by an average factor of 16 (which really means you can
rapidly "prototype" a production quality program), which then compounds
with the productivity increases stemming from using the generated
SDTool (factors usually between 4 and 40).

MetaTool SDTB was developed by the Advanced Software Products group at
AT&T Bell Laboratories.

Tom Wetmore (ttw@mvuxi.att.com)
AT&T Bell Laboratories
(508) 960-6015

pasek@npdiss1.StPaul.NCR.COM (Michael A. Pasek) (09/21/90)

In article <11222@uswat.UUCP> gbeary@uswat.uswest.com (Greg Beary) writes:
>
>  
>
>--
>Greg Beary 				|  (303)889-7935
>US West Advanced Technology  		|  gbeary@uswest.com	
>6200 S. Quebec St.         		| 
>Englewood, CO  80111			|

Hmmm....I take it that this was a "prototype" message -- the actual message
must still be under development    :-)

M. A. Pasek               Software Development              NCR Comten, Inc.
(612) 638-7668              MNI Development               2700 N. Snelling Ave.
pasek@c10sd3.StPaul.NCR.COM                               Roseville, MN  55113