Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!mdcbbs!system
From: jmi@devsim.mdcbbs.com ((JM Ivler) MDC - Douglas Aircraft Co. Long Beach, CA.)
Newsgroups: comp.software-eng
Subject: Re: Software quality
Message-ID: <447.25600697@devsim.mdcbbs.com>
Date: 14 Nov 89 12:35:35 GMT
References: <6847@hubcap.clemson.edu> <1989Oct25.002917.2412@ico.isc.com> <1989Nov2.074042.2857@ico.isc.com> <944@abvax.UUCP>
Followup-To: comp.software-eng
Organization: McDonnell Douglas M&E, Cypress CA
Lines: 71

In article <944@abvax.UUCP>, ejp@vixen (Ed Prochak) writes:
>>
>>> Bill Wolfe and Dick Dunn have been discussing the roles of
>>> and relationships between engineers and managers during
>>> the software development process. This whole process should be
>>> a team effort...
>>>...Both of you seem to have missed who sets the initial constraints
>>> of the product.  The initial bounds are set not by anyone within
>>> your  company, but by your customers!
>>
>>I didn't miss it...I just didn't think that the role of the customer was
>>all that relevant to the relative roles of engineering and management.  To
>>the customer, you have to appear unified.
>>
>>Also, be careful about how you express the role of the customer.  They are
>>the final arbiters, but they aren't the designers or implementors, and you
>>want to watch that.  (Was it Wirth or Hoare who said that if there's any-
>>thing worse than "design by committee", it's "design by customer"?)
> 
> I guess I have a much different view of who the customer is. Surely the
> company ultimately must sell product to remain viable, but that doesn't
> fully define customer. In the context of quality I was taught by my
> previous employer that the customer is the next person down the line (the
> production line that is). Thus, for software developers the customer is the
> software maintenance crew. With this perspective, the idea of customer is
> greatly expanded.
> 

At DAC we are very aware of "quality" and we insist that it be built into every
plane that you fly in. More important than "quality" is the concept of "first
time quality." This means that everything is delivered to specs the first time
out.

The key is the specs. The name of the team I'm in is Software Technologies -
Tools and we are responsible for developing tools that are used in aircraft
simulations as well as the support of the software that creates those
simulations. 

Currently we are awaiting the requirements from the users (internal) that would
define an integrated software development environment. The system would perform
all the varied support functions of the software lifecycle including initial
product development, configuation management, problem reporting and tracking
and maintenance. As the project lead, I have requested requirements from my end
users and have received design. I have returned them and re-requested
requirements. This is a constant problem. Everyone wants to do design! Even the
customer!

Once the requirements are delivered with clear and concise milestones, then the
design can be worked. In order to create a quality product the customer *must*
provide clear concise instructions on *what functionality they wish* not on how
the software should perform that functionality. This also provides a clear
benchmarking milestone for testing of the completed product.

One key requirement to devleoping a quality product here at DAC also includes
the concept of product maintainability and integrity. Therefore we also have
the "next generation developers" as customers. These customers define the
standards that will be used in developing the code. They are also part of the
software inspection team (here we use Fegans Inspection process) and they are
required to sign off and accept the software prior to the release of the
product.

Quality is never "built into" a product unless an effort is made to do just
that at the design level. Once the requirements are obtained, it is the
analyst/developers responsibility to look at the requirements and determine
what the next level of functionality the customer wants will be, and then plan
for that. No additional functionality is permitted to be added to the initial
product release, althogh the development staff can issue the requests for the
additional functionality after the initial release. Remember, the software is
to be delivered exactly as was requested, but one key of quality software is to
plan for the future growth of a product and develop a design that allows for
the future enhancements.