Path: utzoo!attcan!uunet!lll-winken!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!mips!prls!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: some advice to a software engineer (let's get real)
Message-ID: <31112@athertn.Atherton.COM>
Date: 28 Sep 90 23:14:53 GMT
References: <3324@mindlink.UUCP>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 127

In article <3324@mindlink.UUCP>, a1157@mindlink.UUCP (Reece Markowsky) writes:

In spirit, I greatly agree with Reece 
that software quality is a desirable thing, and that steps can be
taken to ensure quality.  However, the quoted article below offers
some opportunity to comment on the relationship between software
quality and other important acceptance criteria.

> Pressman indicated three important points when it comes to quality:
>         1. Software requirements are the foundation from which quality is
> measured.  Lack of conformance to requirements is lack of quality
> 
>         As I mentioned, with your belief that quality must be sacrificed you
> will probably not have a complete and accurate set of requirements for the
> project, let alone conformance to them.

Often it is true that many people do not have a complete and accurate
set of requirements for the project, and that as a result quality
suffers.  Two *implicit* requirements that are often not stated due
to their obviousness, is that not only must the software perform according
(or close to) specifications, but it must also be completed at an
acceptable cost, and within an acceptable amount of time. Additionally,
the acceptable tolerance for error is often not well documented. 

In the real world this is a difficult because it is a nontrivial,
expensive, and error-prone task to create complete and accurate specs.
This is probably the biggest difference between developing software
as part of a pedagogical exercise, vs. developing software for commercial
use.  In the former, the problem is typically simple enough to be
well specified, and objectively testable.  E.g. students asked to
build a "sort routine" have a very clear spec, and testing for compliance
can be easy.  In most cases in the commercial environment, the specs
that come from marketing or from the customer organization are nowhere
near as unambiguous, and so treating them with equal rigor can easily
lead to "we did exactly what they asked for, but it wasn't what they
needed and so we lost our (contract/job/bonus...).  Being a "faultless
failure" may feel better than being a "failure at fault", but in the
end failing usually has bad reprocussions whether you are at fault or not.

Since getting good specs is so difficult and expensive,
one must walk a delicate tight rope between spending too much on spec
information collection and testing, and not doing enough.  Unfortunately,
software engineering practices currently provide little concrete
recommendations as to what is right and this still remains a poorly
understood art.  It is complicated by the fact than in many development
situations, investors will only spend so much on initial feasibility,
or else they will cancel the project before it really gets started.

The problem of describing the acceptable "tolerance" for failure also
causes problem.  Again, in the academic setting, tolerance is often 
quite easy, typically binary: it met the professor's tests and inspections
or it didn't.  But with much more complex software, success is typically
more than passing acceptance tests and inspections, it is also successful
use over a long period of time.  A certain amount of tradeoffs between
cost and time vs. in field failures is appropriate.  The cost of a
space shuttle failure is very expensive, and shuttle software is some
of the most expensive per line available.  Similarly, with medical software.
Errors in game software (while annoying) are less fatal, and since low cost
and early time to market are more crucial in these markets, people will 
accept a certain tolerance for failures.  Of course, fewer failures are
obviously to be preferred, but again steps to ensure this may need to be
factored in with the other cost and time requirements.

Since predictability of costs and effort is still poor in our field, 
telling whether the set of requirements are incompatable (not feasible
within time and cost limitations) is difficult and often failure-prone,
leading to initiation of more ambitious projects than should be attempted.
Later when this is recognized, specifications must be modified so that
they make a compatable subset, and this will typically include reducing
functionality, slipping schedule and budget, and/or increasing tolerance
for defects.

A final problem in this area is in the case of non-contract software. 
Here time and cost requirements are even less clearly understood since
the only correct values are relative to your competitor's own future 
time and cost figures and these are even less clearly known.
  
> 
>       2. Specified standards define a set of development criteria that guide
>the manner in which software is engineered. If the criteria are not followed,
> lack of quality will almost surely result.
> 
>       "cutting corners" because you think quality MUST be sacrificed, or we
> won't finish this project is an example of not following criteria -
(or if your
> are following it it's definitely the WRONG criteria). And as you
expect, a lack
> in quality results - but hey! You met your expectations!

I think that  "cutting corners" most commonly comes from following
criteria, namely
criteria to keep things low cost and quick to deliver.  If you are feature or
low defect oriented, then you may call these the wrong criteria, but time and
costs are important part of the specifications and failure to attend to them
is not only equally likely to bring project failure, but also calls into
question true dedication to the specifications "whatever they may be".

> 
>         3. There is a set of implicit requirements that often goes
unmentioned
> (eg the desire for good maintainability).  IF software conforms to its
explicit
> requirements but fails to meet implicit requirements, software quality is
> suspect.
> 
>         This third point needs some modification in your case.  Here, the
> "implicit requirments" are the requirements to sacrifice quality to get the
> product out.  And you certainly don't fail to meet these.  The outcome
however
> is the same.  That is, quality is not only suspect, but is just not there.

As I mentioned above, this argument under-recognizes other important implicit
requirements that go unmentioned, namely, cost and time.  Sacrificing cost and
time to ensure quality, when budgets and market windows are limited is
also self-defeating.  Better quality cars CAN be made for upwards of $500,000.,
but it may be impossible to sell them at that cost.  It might also be
impossible
to get investment capital for twenty years to develop such safety innovations.

Cost and time are by no means the only important criteria, but neither are
functionality and quality (in terms of low tolerance for defects). Different
industries, and even different products will be best suited by differing
tradeoffs.  It is a clever person who not only manages one or two well, but
who can do a good job of satisfying the customer in all three ways.


Scott McGregor