Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!abvax!iccgcc!kambic
From: kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.)
Newsgroups: comp.software-eng
Subject: Re: Art vs. Engineering
Message-ID: <4565.282e85bd@iccgcc.decnet.ab.com>
Date: 13 May 91 17:25:33 GMT
References: <1991May6.165902.2116@ssd.kodak.com> <35177@athertn.Atherton.COM> <1991May9.155632.29277@mcs.kent.edu>
Distribution: usa
Lines: 28

In article <1991May9.155632.29277@mcs.kent.edu>, rothstei@mcs.kent.edu (Michael Rothstein) writes:
> In article <35177@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes:
>>In article <1991May6.165902.2116@ssd.kodak.com>, nichols@ssd.kodak.com
>>(Tim Nichols (37894)) writes:
[...]
> A SOFTWARE ARCHITECT would be in charge of developing the (functional)
> requirements and user interface of the proposed system: he would be in
> communication with a software designer (aka software engineer) who would
> correct the requirements and interface design, and would later issue the
> specifications (aka non-functional requirements) to complete the problem
> definition stage. This stage would be subject to a review session and
> a final (contract) signing.
> The remainder of the software lifecycle could continue on as before,
> with a design (done by the some software designer/engineer, not necesarily
> the same one), walkthroughs, review, etc. etc.
Many of these concepts fail for two reasons.  In reality, a person implementing
a phase of the SW development lifecycle must have a working knowledge of other
phases in order to be effective.  In fact one of the only ways to really learn
how to engineer SW is to spend time in each phase.  Humbling.  Secondly, there
is a neglect of the reality of feedback and changes during the life cycle.  No 
product development is done without change being incurred.  Software is no 
different.  Feedback, interaction, and communication are skills which are as
fundamental to good SW engineering as SW design methods.

Don't be an expert.  Be a generalist.

GXKambic
standard disclaimer