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: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-ArrivalTime: 2003-05-12 23:36:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.vmunix.org!uio.no!newsfeed.kolumbus.fi!fi.sn.net!newsfeed1.fi.sn.net!nntp.inet.fi!central.inet.fi!inet.fi!read3.inet.fi.POSTED!53ab2750!not-for-mail From: "Anders Wirzenius" Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc,comp.software-eng References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0305010621.55e99deb@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> Subject: Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Tue, 13 May 2003 06:36:01 GMT NNTP-Posting-Host: 194.251.142.2 X-Complaints-To: abuse@inet.fi X-Trace: read3.inet.fi 1052807761 194.251.142.2 (Tue, 13 May 2003 09:36:01 EEST) NNTP-Posting-Date: Tue, 13 May 2003 09:36:01 EEST Organization: Sonera corp Internet services Xref: archiver1.google.com comp.lang.java.advocacy:63641 comp.object:63276 comp.lang.ada:37266 misc.misc:14117 comp.software-eng:19140 Date: 2003-05-13T06:36:01+00:00 List-Id: "Willard Thompson" 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