NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/software/2935

Internet Message Format | 1992-07-23 | 1.6 KB

Path: sparky!uunet!icd.ab.com!iccgcc.decnet.ab.com!kambic
From: [e-mail] (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: SEI Process Maturity Model
Message-ID: <[e-mail]>
Date: 23 Jul 92 11:38:29 EST
References: <[e-mail]>
Lines: 25

In article <[e-mail]>, [e-mail] (Ian Robertson (BCW MSc 89)) writes:
> Scott's response concentrates only on the `making of things. `Software
> design processes' do NOT yield `components being assembled'.
Unless you take the view that the design must be integrated and the parts of
the design must be assemble.  It is only a paper assembly, but an assembly
nonetheless.
>
> Scott, you missed the point I was trying to make.  When
> we DESIGN things we describe them so that someone else can MAKE them. Whether they get made by a
> man and a boy in a backyard or in a robotised assembly line depends on lots of issues, only
> some of which are related to the design.
>
> The design is a description of what is to be made. The designer has a specification, or a brief,
>  or whatever, and uses his/her knowledge, experience, training, ingenuity to come up with a
> `best' description of the artefact such that people who may not be so good at `designing'
> things can go off and make it (of course the corollary is also true; people who are good at
>  designing are usually pretty useless at making). This description can be verbal, narrative or
>  graphical; usually the latter.
Don't forget that the design has to be "made" also.  It does not instantiate
itself.
[...]

George Kambic
standard disclaimer