The book by Brooks {The Mythical Man Month)should be mandatory reading for
every software man. It is fun too.
I have very good memories from projects where you could first build a useful
small part of the system. The client could then update his requirements and
you could get all the bugs out and when all was stable you would build the
next part of the system. The client has a useful system very early in the
project and because you work together with the client (the user) in an early
stage of the project, errors in the specification and the programs never
last long. Cost control is also facilitated. You have a satisfied customer
most of the time during development and very much so in the end. This was
for projects for up to 1.000.000 lines of code.
Wim
----- Original Message -----
From: Chris Kennedy <chris_at_mainecoon.com>
To: <classiccmp_at_classiccmp.org>
> On Sat, 15 Dec 2001, Jim Davis wrote:
>
> > IMHO: All software development should be performed as such:
> >
> > 1) Requirements - what should it do, and not do. Spin this till
> > everybody signs off.
> <snip>
> Ah, creationism (see the Jargon Dictionary if you're not familiar
> with the term).
>
> What is describe is all very textbook. That, then begs the question,
> "why is it that software isn't, in general, done in this fashion?".
>
> The answer is found in step one: the assumption that innovative
> hunks of software can be fully specified in advanced. For software
> that is truly innovative this is empirically very rarely the case,
> as what the customer _thinks_ they want is frequently not what they
> end up wanting/needing in the end. Trotting out signed-off specs
> in no way improves the situation.
>
> In practice the solution is to accept the fact that specs, no matter
> how much they are labored over, are for most efforts soft, and
> then describe mechanism to deal with uncertainty as part of the
> development process. Rapid prototype, stepwise refinement,
> the understanding that one cannot test their way to correctness and
> a willingness to throw at least one implementation completely
> away, coupled with small, agile teams that work with an active
> user community empirically produce more correct results in less
> time that alternative techniques.
>
> Not like any of this is new. Brooks described this eons ago
> in _The Mythical Man Month_...
>
> --
> Chris Kennedy
> chris_at_mainecoon.com
> http://www.mainecoon.com
> PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
>
>
> -----Original Message-----
> From: owner-classiccmp_at_classiccmp.org
> [mailto:owner-classiccmp_at_classiccmp.org]On Behalf Of Jeffrey S. Sharp
> Sent: Saturday, December 15, 2001 8:51 AM
> To: classiccmp_at_classiccmp.org
> Subject: Re: "Geeks" and licensing
>
>
> And possibly add some planning where you use historical data and basic
> statistics to figure out how big the product will likely be, how long it
> will take, and what resources need to be allocated to complete it.
>
> > For safety critical, you should /have to perform statement and
> > decision coverage in step 6 and 7 and the detailed design should have
> > a one-to-one corespondence with the detailed design document. Jim
> > Davis.
>
> The software process course I just got out of also heavily pushed peer
> review of designs and code as a way to filter out defects before testing.
> These have their benefits, but I remain unconvinced of their status as the
> great panacea of software engineering that the course touted them as.
>
> For a little bit of on-topic goodness, what is the group's opinion on the
> trend of software engineering quality starting from ancient times? Have
> we improved (practially, not academically) or worsened?
>
> --
> Jeffrey S. Sharp
> jss_at_subatomix.com
>
>
>
Received on Mon Dec 17 2001 - 17:08:53 GMT