Path: utzoo!attcan!uunet!nih-csl!lhc!ncifcrf!haven!purdue!decwrl!ucbvax!TRANSARC.COM!Mark_Richter From: Mark_Richter@TRANSARC.COM Newsgroups: comp.software-eng Subject: Re: SQA (was: Re: The Software Process - Watts Humphrey.) Message-ID: Date: 27 Oct 90 10:50:49 GMT References: <1711@blackbird.afit.af.mil> Sender: daemon@ucbvax.BERKELEY.EDU Lines: 33 I'm always intrigued by the "SQA or not" debate. The last post I read made a point about "sunset clauses" on SQA, and also raised the old "quality versus schedule" issue. A couple of short comments: First, as a development manager I've never understood the old quality/schedule tradeoff argument. If you are going to be successful then these are not interchangeable things. Sure, I can race the schedule, quality be damned, and after my product fails in the marketplace, not be around for release 2. So what have I accomplished? Second, I want to also quibble with the sunset clause issue. But first let me define SQA in my own terms: SQA is an entity that specializes in good techniques for producing high quality work in my organization. This means that SQA is not a testing entity. Just as I need gifted people who understand the technology of the software product we are trying to build, I also need gifted people who understand good ways to put everything together along the way. Under these circumstances that last thing I want is a sunset clause on SQA. Finally, the post that showed SQA as part of the project team is correct. A crucial factor in the success of any development effort is accountability. It's awfully hard to have accountability with parallel chains of command over the same project. I've generally found the separate-corporate-entity approach to lead to a lot of finger pointing, and not necessarily higher quality products. -- mark richter markr@transarc.com markr%transarc.com@uunet.uu.net