Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!abvax!icd.ab.com!ejp
From: ejp@icd.ab.com (Ed Prochak)
Newsgroups: comp.software-eng
Subject: Re: Software Quality Assurance (SQA) reporting structure
Message-ID: <1363@abvax.UUCP>
Date: 14 Jun 90 13:28:48 GMT
References: <1990Jun12.191025.29951@olympus.uucp>
Sender: news@abvax.UUCP
Reply-To: ejp@icd.ab.com (Ed Prochak)
Distribution: usa
Organization: Allen-Bradley Company, Industrial Computer Division
Lines: 68

In article <1990Jun12.191025.29951@olympus.uucp>, pjs269@olympus.uucp
(Paul Schmidt) writes:
> Many texts say that SQA should have a seperate reporting structure to
> senior management than design.  I THINK THIS IS WRONG!  Quality is dependent
> on the customers perception and is embedded in the design and production of
> the software and thus the SQA function should be as close to the product as
> possible.  Therefore it should be reporting to the same management as design!
> 
> Any comments?

Basically, the arguement goes that:

 with the reporting structure as

                        Mgr
                         |
                    ------------
                    |           |
                   Dev          QA
                  team         team

and if the development is being delayed because the QA team says
the product doesn't meet the requirements, then the manager
(under pressure from his boss to get the new product out ON-TIME)
MAY pressure the QA team (threats of poor reviews, reassignment to
crummy jobs, whatever).


So the idea is the structure:

                 Dev                   QA
                 Mgr                  Mgr
                  |                    |
                  |                    |
                 Dev                   QA
                team                  team

and if the QA team is saying the product doesn't meet requirements,
they are shielded from the development manager's wrath. Now this does
push resolution of the problem up another level (the boss of the two
magagers must decide) but the benefits are:
*QA team protected from pressure of development engineering's product
 delivery schedule. (but they may have their own schedule to meet.)
*Development team must recognize that development is not complete just
 because the delivery date has come. Bad product will come back from QA.
*Development Manager protected from schedule slips because the slips
 are approved by the manager's boss.
*QA Manager protected from allowing shoddy product shipments because
 the shipments are approved by the manager's boss.

Granted these are the ideal results.

I agree with your point that quality is embedded in the product from
the concept stage on up. The QA team should be involved in the
definition of the product, along with development engineering, marketing,
manufacturing engineering, and maybe some others. Having QA report to
the development manager is not necessarily the way to do this,
any more than marketing and manufacturing should report to the
development manager.

The bottom line is that everyone must be involved in getting a quality
product out the door. (read "everyone" as "I")

(Pardon the inconvenience during our remodelling of the signature file)
Edward J. Prochak        (216)646-4663         I think. 
{cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com    I think I am.
Allen-Bradley Industrial Computer Div.       Therefore, I AM!
Highland Heights,OH 44143                      I think?  --- Moody Blues