16.524 rapid prototyping

From: Humanist Discussion Group (by way of Willard McCarty willard.mccarty@kcl.ac.uk)
Date: Mon Mar 03 2003 - 02:37:33 EST

  • Next message: Humanist Discussion Group (by way of Willard McCarty

                   Humanist Discussion Group, Vol. 16, No. 524.
           Centre for Computing in the Humanities, King's College London
                       www.kcl.ac.uk/humanities/cch/humanist/
                         Submit to: humanist@princeton.edu

       [1] From: "Dr. Donald Weinshank" <weinshan@cse.msu.edu> (42)
             Subject: FW: 16.520 rapid prototyping

       [2] From: "De Beer Jennifer <jad@sun.ac.za>" <jad@sun.ac.za> (17)
             Subject: RE: 16.520 rapid prototyping

       [3] From: Leo Robert Klein <leo@leoklein.com> (32)
             Subject: Re: 16.511 data-modelling; rapid prototyping?

       [4] From: "Nate Combs (Home)" <ncombs@roaringshrimp.com> (37)
             Subject: Re: 16.511 data-modelling; rapid prototyping?

    --[1]------------------------------------------------------------------
             Date: Mon, 03 Mar 2003 07:30:58 +0000
             From: "Dr. Donald Weinshank" <weinshan@cse.msu.edu>
             Subject: FW: 16.520 rapid prototyping

    On Rapid Protyping
    --------------
               Date: Sun, 02 Mar 2003 09:18:59 +0000
               From: Norman Hinton <hinton@springnet1.com>

    I must confess that my gut instinct is that if something is rapid and
    simple, it's probably no use.
    --------------
    With all due respect, I went to the ACM Digital Library and got 1,460
    "hits" on the topic. In my own experience, rapid prototyping is an
    enormously powerful tool for clarifying systems needs and
    specifications. There is nothing quite as revealing as showing a user a
    mockup of the system which s/he wants. In the words of the old computer
    science limerick, "It's just what I said, but it's not what I want," is
    the frequent response.

    Many of us suspect that Microsoft's backing of Visual Basic and other
    visual languages was precisely because they allow a system to be mocked
    up rapidly. Once the user signs off on the screen objects, the really
    hard work of system design can begin.

    The one problem that afflicts developers is trying to convert the
    prototype directly into a working system. In this approach, the
    temptation is to take the very crudely designed software and patch it
    together to make a system. In reality, the only safe way to proceed is
    to keep the screens, junk the underlying code and create provably
    correct software. This leads to designed-in reliability, not "tested-in"
    software in which users report problems, and the software house provides
    endless patches, updates and service packs.
    _________________________________________________
    Dr. Don Weinshank Professor Emeritus Comp. Sci. & Eng.
    1520 Sherwood Ave., East Lansing MI 48823-1885
    Ph. 517.337.1545 FAX 517.337.2539
    http://www.cse.msu.edu/~weinshan

    -----Original Message-----
    From: Humanist Discussion Group [mailto:humanist@Princeton.EDU] On
    Behalf Of Humanist Discussion Group (by way of Willard McCarty
    <willard.mccarty@kcl.ac.uk>)
    Sent: Sunday, March 02, 2003 4:46 AM
    To: humanist@Princeton.EDU
    Subject: 16.520 rapid prototyping

                     Humanist Discussion Group, Vol. 16, No. 520.
             Centre for Computing in the Humanities, King's College London
                         www.kcl.ac.uk/humanities/cch/humanist/
                           Submit to: humanist@princeton.edu

    --[2]------------------------------------------------------------------
             Date: Mon, 03 Mar 2003 07:31:44 +0000
             From: "De Beer Jennifer <jad@sun.ac.za>" <jad@sun.ac.za>
             Subject: RE: 16.520 rapid prototyping

    Dear Willard,

    In what can rather be regarded more as information modelling cf.
    data-modelling, when teaching a Multimedia course to my second-year
    undergraduates, it is the case that I emphasise that they create rapid
    prototypes of their projects not only now, but also almost more
    importantly, when they enter the multimedia industry. As indicated by E
    Homich as well as yourself, rapid prototypes are invaluable in assessing
    a client's/ end-user's/ funder's expectations/wants early on in the
    design of the (in this case) Web-based information (delivery) system.

    Regards, Jennifer

    ---
    Jennifer De Beer
    Lecturer in Informatics,
    Dept. of Information Science,
    Universiteit Stellenbosch University, ZA
    http://www.sun.ac.za/InfoScience/staff.html
    +27 (0)21 808 2071 (t)
    +27 (0)21 808 2117 (f)
    

    --[3]------------------------------------------------------------------ Date: Mon, 03 Mar 2003 07:32:35 +0000 From: Leo Robert Klein <leo@leoklein.com> Subject: Re: 16.511 data-modelling; rapid prototyping?

    on 2/27/03 3:01 AM, Humanist Discussion Group (by way of Willard McCarty <willard.mccarty@kcl.ac.uk>) at willard@lists.village.virginia.edu wrote:

    > Some years back I recall various universities in N America investing in > "rapid prototyping" laboratories, where a person with an idea could see it > take prototypical shape quickly, then use the result to argue for the > support required to build the full thing. Whatever happened to the idea of > rapid prototyping? Is it fair to say that the development of computational > tools has or is inevitably shifting the ability to prototype toward the > ordinary user?

    Willard,

    >From the design side of things, rapid prototyping -- or rather iterative design -- is used all the time. You pencil in your idea on a piece of paper and then rush down to the entrance of your particular institution, grab about twenty students and see if the idea will fly. The idea may be no more than a simple list of options that you intend to expand into some more ambitious application further down the road.

    If this original idea turns out to be borderline cockamamie, you adjust it a bit and run back down to the entrance of your particular institution for yet more off-the-cuff testing. All that's required is a pencil and a couple of pieces of paper. For the truly hardy, there's MS Word for doing the layout.

    Eventually you refine your design down to a very precise document that becomes the organizing guide (i.e. the design spec) for the entire project. This without having touched a computer at any point.

    Although technical oversight is essential, designing the system at least initially really depends on your stomach for running down to the entrance of your institution, testing the thing, and then making adjustments over and over again.

    LEO

    --------------------------------------------------------------------------- Leo Robert Klein Library Web Coordinator home ::::::::::::::::::::::::::::::::::::::::::::::::: http://leoklein.com office ::::::::::::::::::::::::::::::::::::: http://newman.baruch.cuny.edu ---------------------------------------------------------------------------

    --[4]------------------------------------------------------------------ Date: Mon, 03 Mar 2003 07:30:16 +0000 From: "Nate Combs (Home)" <ncombs@roaringshrimp.com> Subject: Re: 16.511 data-modelling; rapid prototyping?

    At 08:01 AM 2/27/2003 +0000, Humanist Discussion Group wrote:

    >We tell our students here at King's College London to think of their >projects as prototypes -- so that they can consciously engage with genuine >research but at a simpler level within the brief amount of time that they >have.

    Dr. McCarty -

    Rapid prototyping can mean many things to those in software development.

    From a languages perspective, it might mean to some being able to write an application in LISP or a RAD (Rapid Application Development) language (associated with some application framework) such as Visual Basic or Macromedia Flash (emphasizing UI development). It might mean "higher level" interpreted/scripting languages such as Ruby. These choices would be in contrast to traditionally more time-consuming ("lower-level") languages, say "C" or "C++".

    From a specification and development methodology perspective, it might mean to some adopting a development cycle that is highly iterative and results in constrantly revisiting design assumptions and implementation. This is an idea seen often, recently, with such movements as "Extreme Programming" (XP).

    I've spent most of my career in sponsored research software development in industry. And in its various guises and flavors over the years, "rapid prototyping" has been seen as a reasonable approach for quickly testing ideas and applicaitons in poorly specified or understood problem areas. By the nature of research development - the technical solutions are not often clear in the beginning, nor how it will be applied (e.g. from a users/applications perspective) can change. In these contexts, "rapid prototyping" is often seen as a reasonable approach to refining a design and testing an idea.

    The caveat to "rapid prototyping" is that one needs to understand the tehnical limitations of their approach and know when to "let go" their prototype in favor of a more disciplined implementation / data-model etc. once the problem is better understood and before transitioning to a more exacting application/ user.

    Nathan Combs Scientist, BBN Technologies Cambridge, MA (Home: ncombs@roaringshrimp.com, Work: ncombs@bbn.com)



    This archive was generated by hypermail 2b30 : Mon Mar 03 2003 - 02:45:28 EST