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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) Date: 2000/08/01 Message-ID: <0hqh5.548$SB4.38113@news.flash.net>#1/1 X-Deja-AN: 653041423 References: <8ipvnj$inc$1@wanadoo.fr> <39654639.B3760EF2@eiffel.com> <3985D8F7.754A1584@ebox.tninet.se> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 965095612 216.215.76.173 (Mon, 31 Jul 2000 21:06:52 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Mon, 31 Jul 2000 21:06:52 CDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-08-01T00:00:00+00:00 List-Id: "Stefan Skoglund" wrote in message news:3985D8F7.754A1584@ebox.tninet.se... > Ken Garlington wrote: > > Actually, that's typical for safety-critical software -- for example, I > > don't think we've ever received a single defect report from the field for > > the production F-16 or F-111 digital flight controls. > > Those are military program with the belonging red-tape. The same statement can be made for the Boeing 777, as far as I know. More to the point, we use the same process whether we are required to follow a specific process by the contract or not. > Hmm wondering why the Therac-25 debacle wasn't in my real-time > programming tution. It wasn't covered in my real-time systems class, either, but it certainly was included in my Software Engineering I text. > > However, they will also tell you that their dollars invested per SLOC is > > much higher than the industry average (again, typical for safety-critical > > software). It may be that using more "computer science" (e.g., using more > > COTS) will permit lower costs while still retaining the kinds of defect > > rates expected for this type of software. > > I doubt it considering that it will only cut down on amount on coding. > You still > must do proper testing for example. Actually, many of the techniques used in high-integrity software (formal inspections, simulation, etc.) are not tied solely to the coding phase. We are using them well before we actually write any code. Note also that the testing process can be improved considerably by (a) reducing the number of errors that enter the test process and (b) optimizing the test process to require fewer tests (e.g., by automatically generating some tests from the requirements).