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: 101deb,3488d9e5d292649f X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,e6a2e4a4c0d7d8a6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-25 02:31:59 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!news.teledanmark.no!uninett.no!uio.no!newsfeed.song.fi!nntp.inet.fi!central.inet.fi!inet.fi!read3.inet.fi.POSTED!53ab2750!not-for-mail From: "Anders Wirzenius" Newsgroups: comp.lang.pl1,comp.lang.ada References: <1045856952.418085@master.nyc.kbcfp.com> Subject: Quality (Re: status of PL/I as a viable language) MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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, 25 Feb 2003 10:31:46 GMT NNTP-Posting-Host: 194.251.142.2 X-Complaints-To: abuse@inet.fi X-Trace: read3.inet.fi 1046169106 194.251.142.2 (Tue, 25 Feb 2003 12:31:46 EET) NNTP-Posting-Date: Tue, 25 Feb 2003 12:31:46 EET Organization: Sonera corp Internet services Xref: archiver1.google.com comp.lang.pl1:4451 comp.lang.ada:34552 Date: 2003-02-25T10:31:46+00:00 List-Id: "John R. Strohm" wrote in message news:CACF786833CAF67E.50C10DC07731FD2D.0DEBE34F2ECDF3F2@lp.airnews.net... > It wasn't extremely good; it was PERFECT. It did PRECISELY what it was > designed to do. It did PRECISELY what the customer WANTED it to do. And it > didn't just CLAIM to do that, and CLAIM to have no lurking faults; it was > rigorously KNOWN to have no lurking faults. > > This was part of a long project aimed at developing verification technology > to the point that it would be possible to build perfect software. One can > easily envision domains where exhaustive testing is just not possible, where > it is necessary to KNOW by other techniques that the software is absolutely, > positively, correct. In those domains, "debugging" until it LOOKS like it > works just isn't good enough. > > > When you talk about quality, I think a key issue is a discussion about building quality versus testing quality. What means "building quality into something"? The paradoxality lies in that you never can avoid the situation of "First Do It And Then Test What You Have Done". With "testing" I mean any way (test, review ...) to convince that some entity is fulfilling the requirements put on it. If you write an essay, the only way to have linguistically correct text is to write a sentence and check (test) your sentence. Then write the next sentence. And check it. The only way to guarantee that you spread butter all over your slice of bread is to spread the butter and then check that you have it all over the slice. So, how do you then _build_ quality into your product or computer program? By "testing" smartly! By taking your time to plan a "testing" schedule all over the lifetime of the project. By leaving all testing to the end you just create a big bang and hope that the bang is a positive one. By splitting the development project into smaller pieces the bangs are smaller and hence the damages of having negative bangs become significantly smaller. The thing you have to decide is then: How often do I test? How small pieces do I test? In a software project you have requirements in the beginning and a running software at the end. What you have in between is your own choice as a project manager. Your choice may be to build a protype and run a test suite on it, create next proto and test it. Or your choice may be to divide your project into phases of specification, design and coding and have a testing or review after each phase. The specification and the final piece of code (maybe together with necessary hardware) both should demonstrate the end product entirely. Hence it should be possible to test the requirements of the end product on both embodiments. If the tests show shortages or inaccuracies the embodiment is incomplete and should be corrected before the project continues. If the specification has passed your tests (or review, whatever), then you KNOW (as John R. Strohm writes) that you have a correct specification of the end product. My experience of development projects in electronics and steel industry has strengthen my above described opinion about the value of dividing the whole project into phases. I have participated in projects where we systematically worked through the project starting from a verbal specification of the product and ending at a hand held measuring device with correct functions and accuracy and look. I have also seen development projects ending in a bitter situation where the project manager defended his ideas about a successful product because that discussion was never held earlier in the project. In the latter situation the project manager DID NOT KNOW whether or not he was on the right track until at the end of the track. Anders