neil@comp.lancs.ac.uk (Neil Haddley) (04/25/89)
Design Methodologies - Fact or Illusion.
----------------------------------------
I would greatly appreciate references to any papers, or books, which
discuss the merits and demerits of Design Methodologies, and also
any good references to the Design Process (Support).
as a taste of what I am hoping for:
"So called design methodologies for software systems are no such thing
and are simply notations to express a pre-formulated software design ...
it is profitable to turn our attention to building design support systems
to assist with the design process itself."
"Science [and Software Development] is an essentially anarchistic enterprise:
theoretical anarchistic is more humanitarian and more likely to encourage
progress than its law-and-order alternatives."
"Software Development support tools do not always have to turn around
formal notations being used to capture the intermediate results of the
design process, which then provides input data for expert-system type
advisors."
Many thanks in advance
Neil
--
EMAIL: neil@comp.lancs.ac.uk | Post: University of Lancaster,
UUCP: ...!mcvax!ukc!dcl-cs!neil | Department of Computing,
| Bailrigg, Lancaster, UK.crm@romeo.cs.duke.edu (Charlie Martin) (04/28/89)
Okay, I'll bite. In article <747@dcl-csvax.comp.lancs.ac.uk> neil@comp.lancs.ac.uk (Neil Haddley) writes: > >Design Methodologies - Fact or Illusion. >---------------------------------------- > >I would greatly appreciate references to any papers, or books, which >discuss the merits and demerits of Design Methodologies, and also >any good references to the Design Process (Support). > In terms of the merits and demerits of one methodology over another, you're asking a very hard question. Most or all of the benefits of a methodology are cognitive in nature (the software neither knows nor cares if it was designed with a methodology -- it's only the people involved who pay any attention.) As such, experiments to measure the relative effects of different methodologies are difficult to do, expensive, and produce results characteristic of the squishy sciences, i.e., pretty equivocal. I could, if pressed, dig up a bibliography I worked on some years ago that attempted to capture all the papers that had actual quantative results or solid case studies (or for that matter, *bad* case studies) but I think I can promise you'd be disappointed by the amount there is. The advantages of having *some* methodology over no methodology whatsoever are much less equivocal, but still hard to measure. Experiments *using skilled designers* tend not to show much difference between using a formal design methodology and using their normal methods. But all this seems to mean is that the skilled designers have evolved their own notations in which to design. The need for notations of some sort for design seems unequivocal: in fact, almost all forms of design (not just software design) use some kind of notation and thereby use something like what we call a design methodology. (See, for example, _Reflective Practice_ by Donald Shoen at MIT.) These notations are useful both in teaching the skills used in design, and in doing design; people tend to use the notations and methods they first learned, whether they are doing architecture, electronics, or software design. >"So called design methodologies for software systems are no such thing > and are simply notations to express a pre-formulated software design ... > it is profitable to turn our attention to building design support systems > to assist with the design process itself." This appears to me to be mostly nonsense, but without a little closer exploration of what was meant by the quote I can't feel certain. But every study of the cognitive processes of design I'm aware of have included some kind of design notation that is used while the design is being done. This quote could be interpreted to mean that the design process occurs in some deeper level of cognition; once a fragment of design is composed in the mind, it is then translated out into some notation. If one is using a formal design methodology, then the notation may be a formal design notation. Thus one could claim that the "real" design happens independently of the expression in a notation. But design is a process of creation FOLLOWED BY expression in some notation FOLLOWED BY reflection and testing against constraints FOLLOWED BY revision and re-creation when deficiencies are discovered. This process seems to depend on having a notation. (What IS the "design process itself" independent of the notations used to express design?) The advantage of software design notations and the formal methodologies based on them (if there is one) probably has to do with others being able to read and proof the design documents; this is shared by the formal blueprints prepared by architects after they scratch out a sketch on the back of a napkin. But the process of preparing blueprints is still an essential part of the design: errors, inconsistencies, and plain stupid stuff like only having left 21 inches for the back door are revealed in the formal scale drawings. > "Science [and Software Development] is an essentially anarchistic > enterprise: theoretical anarchistic is more humanitarian and more > likely to encourage progress than its law-and-order alternatives." This sounds like a plausible aphorism -- a little long, but plausible -- and I'm damned if I can figure out what it is supposed to tell us about design or science. Does it mean that science is essentially like russian christian anarchism, i.e., if we leave everyone alone they'll all have Good Motives and do Good Things because they are all Essentially Good? More seriously, does it suggest that science is done best in an environment in which everyone makes up their own notations and shorthand without some regulation or force of commonly accepted practice? Considering the number of times that a new notation or cognitive model (like compartmental models in physiology, or some of the other model techniques in, for example, control theory [block diagrams]) has made it easier to teach and led to new results, it doesn't seem very plausible. (What are mathematics and chemical equations but design notations?) > "Software Development support tools do not always have to turn > around formal notations being used to capture the intermediate results > of the design process, which then provides input data for > expert-system type advisors." I guess I have to agree with this because it says "do not *always* have to turn around" but I can't think of any support tool which doesn't, and have a little trouble imagining one that doesn't. And I certainly don't think that "SD support tools ... always have to turn around formal notations ... which then provide input data for expert systems" which seems to be the antithesis of the sentence. I can think of many sorts of support tools which might have no expert system involved at all. To answer your direct question, you might read Brooks' Mythical Man Month, and there is lots of information on the design process overall in the design literature, which you'd probably find in the nearest library associated with an architecture or industrial design school -- or at least that's my guess; do they break things up like that in the UK? Although only a few of the papers actually are germane to your question, there is a book called _Issues in software engineering education_ (Fairley and Freeman, eds., Springer Verlag 1988(?)) which covers some questions in teaching software design. Have a look at Ray Buhr's work, or (ahem) the paper I co-authored. Our paper also mentions some other areas of the design literature. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
dave@lethe.UUCP (Dave Collier-Brown) (04/29/89)
For a good explanation of both the power and difficulty of formal
methods in specification (and design), have a look at:
Wl'adsl'aw M. Turski and Thomas S. E. Maibaum, "The Specification of
Computer Programs", Reading, Mass (Addison-Wesley), 1987, 263pps + references.
To summarize, it took me 6 months to read the book, having taken classes
from Tom in the (distant!) past. The mental and notational tools therein
are usefull, but requires considerable thought and effort. Now, tell me again
that brand X SDE or brand Y methodology is going to solve problems in
**this** area? Pfaugh!
--dave (see note below) c-b
To be fair, I once worked on an SDE that looked after the bookkeeping, not
the methods and tools. It was a **very** worthwhile approach.
--
David Collier-Brown, | {toronto area...}lethe!dave
72 Abitibi Ave., | Joyce C-B:
Willowdale, Ontario, | He's so smart he's dumb.
CANADA. 223-8968 |