From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-ArrivalTime: 2003-05-12 19:29:57 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.airnews.net!cabal12.airnews.net!usenet From: "John R. Strohm" Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc,comp.software-eng Subject: Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)) Date: Mon, 12 May 2003 21:16:53 -0500 Organization: Airnews.net! at Internet America Message-ID: References: <9fa75d42.0304230424.10612b1a@posting.google.com> <254c16a.0305011035.13133e8d@posting.google.com> <9fa75d42.0305011727.5eae0222@posting.google.com> <17cd177c.0305072114.24f04783@posting.google.com> <9fa75d42.0305090612.261d5a5c@posting.google.com> <9fa75d42.0305091549.48b9c5d9@posting.google.com> <7507f79d.0305121629.5b8b7369@posting.google.com> Xref: archiver1.google.com comp.lang.java.advocacy:63618 comp.object:63267 comp.lang.ada:37260 misc.misc:14106 comp.software-eng:19139 Date: 2003-05-12T21:16:53-05:00 List-Id: X-A-Notice: References line has been trimed due to 512 byte limitation Abuse-Reports-To: abuse at airmail.net to report improper postings NNTP-Proxy-Relay: library2.airnews.net NNTP-Posting-Time: Mon, 12 May 2003 21:28:16 -0500 (CDT) NNTP-Posting-Host: !Zm:G1k-VJhXs^b (Encoded at Airnews!) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 "Willard Thompson" wrote in message news:7507f79d.0305121629.5b8b7369@posting.google.com... > "Anders Wirzenius" wrote in message news:... > > "Dale Stanbrough" wrote in message news:dstanbro-DDA263.20492210052003@mec2.bigpond.net.au... > > > soft-eng wrote: > > > > > > > But for how long can you keep on making the same type > > > > of mistakes? > > > > > > Forever, if we examine software faults. What's your point? > > > That people -shouldn't-? I would agree with that. That people > > > can learn to be 100% accurate in everything they do? I don't > > > think i'll agree on that. > > > > > > dale > > > > Exactly. > > Isn't a good quality system a system which catches possible human mistakes? > > > > The more a process is dependent on human beings to be perfect, the more vulnerable the process is. A quality system is as much a > > support for the performing staff as it is a support for the management. > > > > The weaker the quality system is the more it demands a management to be involved in the daily working details meaning less time to > > work with long term organizational issues. > > > > Error catching as early as possible is a good co-worker to both the programmer and his superior. > > > > Anders > > 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? > 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 > 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. That is PRECISELY what the higher levels of the Capability Maturity Model are all about. Part of what you are doing at the higher levels is tracking defect causes, and adapting the ongoing software process to kill the process errors that allowed the defects to happen and escape immediate detection.