Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!news.luth.se!eru.mt.luth.se!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!dish.news.pipex.net!pipex!demon!aldur.demon.co.uk!neil From: Neil Wilson Newsgroups: comp.object,comp.lang.beta,comp.lang.c++,comp.lang.eiffel,comp.lang.python,comp.lang.sather,comp.lang.smalltalk Subject: Re: Rapid Prototyping + statically-typed OOPLs? Followup-To: comp.object,comp.lang.beta,comp.lang.c++,comp.lang.eiffel,comp.lang.python,comp.lang.sather,comp.lang.smalltalk Date: Wed, 12 Jul 1995 19:10:45 GMT Organization: Poledra's Cottage Lines: 53 Message-ID: References: <805548287snz@galacta.demon.co.uk> X-NNTP-Posting-Host: aldur.demon.co.uk X-Newsreader: TIN [version 1.2 PL2] Xref: news.daimi.aau.dk comp.object:33413 comp.lang.beta:446 comp.lang.c++:128687 comp.lang.eiffel:9189 comp.lang.python:4980 comp.lang.sather:1914 comp.lang.smalltalk:24311 Dr. Rich Artym (rartym@galacta.demon.co.uk) wrote: : Rapid Prototyping ::= An iterative approach to the analysis of : requirements through production of an operational prototype in which : elements of design are also explored. [Excludes the degenerate case : in which no significant changes to the first prototype are needed.] Why oh why do people insist on using the term Prototyping in conjunction with Information System development? Do you intend to mass-produce it afterwards? (Congratulations on mastering the 'cp' command). Are you going to write a new system afterwards that is the same but on a larger scale? (don't forget to change that bubblesort will you). Prototyping is a horrible 'Humpty-Dumpty' word. (The best description of 'prototyping', and why it is such a bad term, is in 'Object Success' by Bertrand Meyer) The key question is what do you intend to do with the 'operational prototype' after you've done R.P? If it evolves into the system proper then shouldn't you have applied correct control procedures at the beginning? After all it is now part of your system. And if you tell me you're going to throw it away, I don't believe you. If you're going to develop a system then set out to develop one. Use the same control/feedback techniques and methods at the beginning as you would use at the end. I'm afraid that you have to handle problem space and solution space symbiotically throughout development. One is never without the other. The promise of O-O is more malleable structures that can withstand massive changes. Static v dynamic is a straight choice. Do you want the computer to check integrity, in which case you have to give more information to the computer. Or do you want the human developers to check the system - they may have better context, but they're not as good at checking certain classes of error. How fast you can get back to the user with the 'this is what we think you mean' system is probably a function of the richness of the component library and the quality of the developers. : constraints. Since the requirements and design are not known fully until : the R.P. development is ended. Requirements and design are never fully known. They always continue to evolve. Hopefully the rate of change will decrease over time, but don't bank on it. Development never ends until the system is obsoleted. -- Neil Wilson (neil@aldur.demon.co.uk) ...Arrive without travelling, Ossett, Yorkshire, UK see all without looking...