Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!joeisuzu
From: joeisuzu@pawl.rpi.edu (Anthony Sute)
Newsgroups: comp.society.futures
Subject: More large-scale design talk...
Keywords: a
Message-ID: <=B}^_*|@rpi.edu>
Date: 30 Nov 90 15:54:21 GMT
Distribution: comp
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 51
Nntp-Posting-Host: pawl3.pawl.rpi.edu

A few weeks ago I brought up the subject on this network of current trends in
large-scale software system design and what should be done both to improve
the process as well as bring an enhanced sense of "professionalism" to the
industry that it desperately needs.  This message is in reply to that pos- 
ted by Mr. George and addresses some of the concerns and ideas he brought
up.  First of all, he is absolutely correct when he says that for any soft-
ware system, there MUST be sufficient time devoted to the requirement
specification and definition phase.  Essentially this is a formal name for
that part of the design phase where the analysts simply define what it is
the users want the system to do.  The users must be absolutely sure of their
expectations for the system so that there is no interpretation required on
the part of the system designers of system operation.  The analysts are
expected to aid the customer during this requirement specification phase, but
they should not impose any restrictions on the user in terms of how the     
system must work.  In other words, the analyst must work with the client in
evaluating current operating procedures which are to be automated by the    
intended system in order to arrive at an optimized way of tackling the pro-
blem through use of the system.  Mr. George also brought up a valid point
when he stated that often times the design specification is so inadequate
that the coders have to "interpret" what they believe the system is to do.
Of course, as we all know, this ultimately leads to misunderstandings and
ultimately to code modifications in order to achieve what was originally
required.  This leads to my next point which he also mentioned, and that
design often occurs during the coding phase.  I don't want to portray
programmers (like myself) as being "grunts", but it's my belief that when
we are given a formal specification to create code for, we must stick to
that specification and not make our own modifications.  Some people may argue
that this wreaks havoc with the creativity factor, but creativity is what
helps us achieve the end result within the code.  So long as the code produces
the desired output, creativity has free reign over how the code was created.

It is a sad commentary on the state of our industry when it seems to be a
widely-accepted fact that the goal of most software design companies is to
simply get the product out when it meets minimum design specs.  Testing of
the software MUST be exhaustive, to the point that the design company is
willing to stake its reputation on the code.  After all, it is providing a
service for a fee and quality-control is a very important issue.  A clear
example of what poor quality-control can do to an industry is reflected in
the American auto industry.  If we want the American software design industry
to flourish, we must improve our quality so as to not prompt customers to look
elsewhere (doesn't Japan seem like the most obvious candidate?!?!).

More remarks on testing:  Mr. George is entirely correct when he says that with
modern systems, it is nearly impossible for any one person to wholly understand
all the facets of a system, but that is why we employ design teams.  Making
everyone responsible for one specific part of the system is essential for
success.  In addition, communication within the design team is necessary simply
to gauge progress on the various parts as well as ensuring that all of the     
parts will be compatible with each other in the end when everything is put
together. 
              


Brought to you by Super Global Mega Corp .com