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,FREEMAIL_FROM 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: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-ArrivalTime: 2003-05-13 06:43:57 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: softeng3456@netscape.net (soft-eng) 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: 13 May 2003 06:43:56 -0700 Organization: http://groups.google.com/ Message-ID: <9fa75d42.0305130543.60381450@posting.google.com> References: <9fa75d42.0304230424.10612b1a@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> NNTP-Posting-Host: 32.97.239.19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1052833436 14030 127.0.0.1 (13 May 2003 13:43:56 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 13 May 2003 13:43:56 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63656 comp.object:63299 comp.lang.ada:37277 misc.misc:14126 comp.software-eng:19145 Date: 2003-05-13T13:43:56+00:00 List-Id: "Anders Wirzenius" wrote in message news:... > "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 Believe it or not, many people have thought very hard about this issue! There are generally two major approaches people come up with. 1) Hire good people, and give them the tools they need. Many companies follow this approach, e.g. Microsoft. (See http://www.joelonsoftware.com/articles/fog0000000072.html ) 2) Since you are very smart, use your brains to think up a quality solution. The staff you have, of course, doesn't matter. You just need to give them a quality solution, and quality will follow. Just tell them what to do and make sure they do it. (In the above URL, see the behavior at Juno.) For instance, a militaristic language that will catch all their errors and solve the problem of human fallibility. Or a methodology that will make quality flow out their ears. Typical command-and-conquer stuff is "now everybody will write a spec in this here format before starting a new module. This will make our product quality improve amazingly." You can usually tell the people who took approach (2), because they are always bemoaning how things don't work right, and why it is somebody's fault. E.g. complaining about their vendor, or complaing about how everybody is so stupid to use languages like C, C++ or Java when it is obvious that better solutions would have easily solved all world's problems.