Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[softeng3456@netscape.net (soft-eng)]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:<ln0wa.54$a03.44@read3.inet.fi>...
> "Willard Thompson" <need_more_spam@yahoo.com> wrote in message news:7507f79d.0305121629.5b8b7369@posting.google.com...
> > A good quality system or process is managing defects at every stage of
> > the software development process.  Requirement defects, design
> > defects, etc.  I would have to agree that many defects that are caught
> > early and subsequently fixed early would be less costly overall and
> > can lead to higher quality software systems.  However, what happens
> > when a big defect pops up after release?  ...so much for quality.
> >
> > One big question that no one knows the exact answer to is how exactly
> > does the software process quality lead to software product quality?
> 
> The exact answer is hardly found in any production environment: software, hardware, serviceware, educationware, you name it. A
> quality system certificate is nothing more than a paper stating that the production process includes some overhead routines that can
> be said affecting the product quality, like you write:
> 
> > We most certainly know that process quality affects product quality,
> > that is obvious.  To attempt to answer such a question, I think would
> > require mountains of formal and rigorous process documentation over
> 
> Not mountains, a few pages will do. The key issue is that, to avoid the "details hell", the process documentation should be made by
> the foremen, not the workers. What is then between the overall process documentation and the details? That is called profession
> skill (=individuals, but still human beings that may any time have a bad day and code an array bounds overflow ;-).
> 
> > the life time of many projects for tracking/comparing purposes, which
> > is only half the battle.  I think the other half is maintenance, to be
> > able to trace a newly discovered bug back via the documented
> > development process to properly identify not only the exact location
> > in code but abstraction and reasoning as well.
> >
> 
> One should always remember that the maintenance is pure maintenance only if you don't reuse code or algorithms in new deliveries.
> Otherwise you always have a connection between the delivered bugs and new software on its way. The new software may not have been
> coded yet, it may still be in "abstraction and reasoning" phase.
> 
> A former employer to me had in their quality system a routine where the R&D was required to make a resume of corrective actions made
> for previous versions of the product. To make the resume was a piece of cake since all service actions in the service department
> were recorded in a database. This resume requirement was a part of the R&D actions prior to the "abstraction and reasoning" phase.
> 
> Anders


Believe it or not, many people have thought very hard
about this issue!

There are generally two major approaches people
come up with.

1)  Hire good people, and give them the tools they
need.  Many companies follow this approach, e.g. Microsoft.
(See http://www.joelonsoftware.com/articles/fog0000000072.html )

2)  Since you are very smart, use your brains to
think up a quality solution.  The staff you have,
of course, doesn't matter.  You just need to
give them a quality solution, and quality will
follow.  Just tell them what to do and make
sure they do it.  (In the above URL, see the behavior
at Juno.)  For instance, a militaristic language that
will catch all their errors and solve the problem
of human fallibility.  Or a methodology that
will make quality flow out their ears.  Typical
command-and-conquer stuff is "now everybody will
write a spec in this here format before starting
a new module.  This will make our product quality
improve amazingly."

You can usually tell the people who took approach (2),
because they are always bemoaning how things don't
work right, and why it is somebody's fault.  E.g.
complaining about their vendor, or complaing about
how everybody is so stupid to use languages like C,
C++ or Java when it is obvious that better solutions
would have easily solved all world's problems.