Xref: utzoo comp.sw.components:315 comp.software-eng:2132
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!rsd
From: rsd@sei.cmu.edu (Richard S D'Ippolito)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Schedule and budget are secondary
Message-ID: <4450@ae.sei.cmu.edu>
Date: 11 Oct 89 21:46:47 GMT
References: <16168@vail.ICO.ISC.COM> <6693@hubcap.clemson.edu> <16187@vail.ICO.ISC.COM>
Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 45

In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:

>It is entirely possible to construct software which meets all such require-
>ments, but which is poorly conceived or implemented.  Examples abound.  I
>know of no way to specify software requirements such as "must be able to
>survive the next five years of changes, to meet new needs, hacked in by
>bored second-string maintenance programmers..."  But that's often what
>quality software needs.

There are ways to do it.  One can generally anticipate the areas of change,
especially in large systems where there is a long history of changes.

For example, suppose you require software for a flight trainer used to
simulate operation at several airports, i.e., the characteristics of the
airports are used to drive the simulated display and the cockpit
instruments.  Can't it be required that the capability of changing the
airport(s) be designed in?  It is possible for the contractor to include in
his bid the effort (read "cost") to do this.

Suppose you are building a C3I system based on a large number of
electronically received messages which have to be translated and validated
before being stored in a database.  Should you not require the contractor at
proposal time to tell you the cost of adding or deleting new messages, some
of which are of the same types and some of which are probable new types (if
known)?

There are many other examples I could give, as these types of systems have
been around long enough for us to have a good idea of the nature of the
expected changes.  It merely requires the program office to request the cost
of the anticipated changes in the proposals.

As you can see, the contractor (read "software engineer") is going to need
some concrete idea of what he's going to build in order to be responsive,
but, hey, isn't that true of other engineers?

Watch for it -- happening soon to a contractor near you!


Rich

-- 
It is not the possible that determines what to hope for --   
it is hope that determines what is possible.
Richard J. Oman                                               rsd@sei.cmu.edu
-----------------------------------------------------------------------------