Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!shadooby!accuvax.nwu.edu!tank!ncar!ames!zodiac!rockmore
From: rockmore@zodiac.ADS.COM (A. Joseph Rockmore)
Newsgroups: comp.software-eng
Subject: Re: Architecture
Message-ID: <7471@zodiac.UUCP>
Date: 6 Apr 89 15:14:41 GMT
References: <1014@afit-ab.arpa> <24727@mirror.UUCP>
Sender: news@zodiac.UUCP
Lines: 70
In-reply-to: garison@mirror.UUCP's message of 28 Mar 89 18:28:53 GMT


In article <24727@mirror.UUCP> garison@mirror.UUCP (Gary Piatt) writes:

   Path: zodiac!ames!oliveb!pyramid!pyrnj!mirror!garison
   From: garison@mirror.UUCP (Gary Piatt)
   Newsgroups: comp.software-eng
   Date: 28 Mar 89 18:28:53 GMT
   References: <1014@afit-ab.arpa>
   Reply-To: garison@prism.TMC.COM (Gary Piatt)
   Organization: (Dis-)
   Lines: 31

   In article <1014@afit-ab.arpa> William A. Bralick writes:
   =>It seems to me that architecture (as in buildings, not computer
     systems :-)  
   =>should provide a useful set of lessons for software engineers.
     The parallels 
   =>[...] are striking [...]  Has any formal attempt been made to draw [up]on 
   =>[...] architecture as a model for solving some of the problems in software
   =>engineering?

   The problem with this is that (for the most part) the job of the architect
   is done when construction of the building begins.  There's still some org-
   anizational things to do -- make sure the builders keep to schedule, make
   sure the proper materials are used, etc -- but the bulk of the work an
   architect does is in the design.

this is not true, in general.  as the son-in-law of a practicing
architect and the son of a general contractor, any complex building
(again there is the distinction between a relatively stable design for
a small project versus the evolving design for a large, complex one)
undergoes many design changes as it is being built.  my father-in-law
has spend many a month as architect assigned to the construction of a
building, doing the appropriate re-design and detailing design as
things come up in the construction.  why does this happen?  in my
opinion it is due to two factors:  a lack of complete design and lack
of analysis of that design.  the first means that, given all the
drawings and specifications that an architect normally does, there is
still a lot left unsaid, and thus up to the builder.  the second means
that there are parts of the design that are incompatible in some way
with the rest, but this is not obvious to the architect because he
can't formally analyze the design.  both of these analogize to
software.  (and, of course, the owner keeps changing his mind during
construction...) 

   [stuff deleted]

   These same things happen to the architect, but the design is entirely on
   paper, and can be changed (more or less) easily.

it is much easier to change the design, but much harder to change the
implementation in building than in software.

                                                       The implementation does
   not start until the design is done.

not true, as stated above.

                                        The major problems of software eng-
   ineering stem from the fact that the design is not frozen until *after*
   the product is released.

if then.

			   -Garison-




	...joe