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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public From: rkaiser@dimensional.com (Richard Kaiser) Subject: Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/19 Message-ID: <5gp06c$13l$1@quasar.dimensional.com>#1/1 X-Deja-AN: 226876612 Distribution: world References: <332B5495.167EB0E7@eiffel.com> <5giu3p$beb$1@news.irisa.fr> <332ED8AB.21E7@lmtas.lmco.com> <5go8nk$ngf$1@news.irisa.fr> Organization: Dimensional Communications Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1997-03-19T00:00:00+00:00 List-Id: In article <5go8nk$ngf$1@news.irisa.fr>, jezequel@irisa.fr (Jean-Marc Jezequel) wrote: >In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington > writes: > >> 2. No one ran a full integration test with realistic flight data, >>which would have >> alerted them to the mistake made in #1. Particularly for a >>distributed mission- >> critical system, this should be considered an absolute >>requirement. > >Yes, this is true. But you have to understand that the mere design of the SRI >made it very difficult to test it in an other way that performing a launch. >This is because of the tight integration of hard-to-fool hardware with software >in a black box functional unit. What can be your test strategy for a black box >containing an inertial central? If the software had been designed with less > coupling >on this particular hardware, you could have test the software vs. a simulation > of the >hardware and its environment. Here, the launch was the test. Take your pick: For linear rates: 1. Replace the accelerometers with A/D converters 2. Replace the values read from the accelerometers with simulated data For angles: 1. either of the above for the gyros 2. place the navigation unit in a three or four axis table. >>Although I like some of Mr. Meyer's columns, I found this particular >>column not only wrong, >>but dangerous, since it continues the trend of denigrating sound test >>strategy and common >>sense system engineering in favor of a software-centric approach. > >I don't see where it denigrates sound testing. IMHO, sound testing *is* needed. >And testing is effective only if you have a sound test strategy. >Even more when you use programming by contract. In the paper, >we just recall that you cannot rely on tests only. Prove it works. Richard Kaiser