Xref: utzoo comp.sw.components:311 comp.software-eng:2120
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Schedule and budget are secondary
Summary: "Quality" covers more than requirements
Message-ID: <16187@vail.ICO.ISC.COM>
Date: 10 Oct 89 23:25:21 GMT
References: <16168@vail.ICO.ISC.COM> <6693@hubcap.clemson.edu>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 38

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
> >>    ...We're here to engineer products on time, under budget,
> >>    and with as much quality as we can get within those two constraints.
> > ...It's particularly
> > sad to see "quality" a poor third to the other two.
>    If the product does not meet the minimal standards of acceptability,
>    then it is not complete.  "On time", etc., refers to the product
>    being completed in accordance with the relevant quality requirements.

"Quality" software is MUCH more than software which meets "the minimal
standards of acceptability", thank you.

A piece of software may be judged to have been "completed" on time and
within budget if it meets its stated requirements within those constraints.
The requirements are going to be objective criteria--such as tasks the
software must perform, performance and size limits, etc.  They MUST be
objective criteria in the (very common) case where the requirements are
part of the negotiated contract for the software project.

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.

Sometimes software doesn't need high quality--sometimes the minimal hack
that meets the short-term requirements is enough!  The "lowest bidder"
approach is OK sometimes, but not universally.  Most software far outlives
its originally estimated/intended life.  It is more common to find our-
selves with software under-engineered than over-engineered.  My personal
peeve here is that I spend far too much of my time reworking under-engin-
eered hacks back into decent code that can survive.  So I see an extreme
focus on budget/schedule as needlessly increasing the amount of such work I
have to do.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.