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... /
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