Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!snorkelwacker!bu.edu!orc!decwrl!pacbell.com!pacbell!att!cbnewsm!lfd
From: lfd@cbnewsm.att.com (leland.f.derbenwick)
Newsgroups: comp.software-eng
Subject: Re: Software Quality Assurance (SQA) reporting structure
Summary: keep it separate
Message-ID: <1990Jun14.012302.19339@cbnewsm.att.com>
Date: 14 Jun 90 01:23:02 GMT
References: <1990Jun12.191025.29951@olympus.uucp>
Distribution: usa
Organization: AT&T Bell Laboratories
Lines: 29

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?  [Well, you asked! -- lfd]

In an ideal world, SQA belongs in the design organization.  But
in reality, that allows the design management to weaken SQA: "You
certify this program _now_, or we'll miss schedule and it'll
reflect on your merit review."  Well, not usually that blatant,
but it can get pretty close...

The most effective situation I've experienced (context: about 10
each of hardware and software developers, 2 to 3 year project)
was with a totally separate QA organization, but one QA person
assigned full-time to the project, who attended all reviews, etc.
His office was also in the midst of ours.

So the QA _function_ was tightly coupled to the project, but the
reporting structure was not.  We got immediate feedback from him,
but if he saw something he didn't like, he could speak out without
fear of reprisals.

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd