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: 103376,74b55538385b7366 X-Google-Attributes: gid103376,public From: swhalen@netcom.com Subject: Re: Ada safety road Was: Which is right ... Date: 1999/06/13 Message-ID: <7k04l8$ea1@dfw-ixnews8.ix.netcom.com>#1/1 X-Deja-AN: 489056082 References: <928083159.436.79@news.remarQ.com> <928174549.336.98@news.remarQ.com> <7iuqkc$ln6$1@nnrp1.deja.com> <928529202.956.79@news.remarQ.com> <928569312.951.42@news.remarQ.com> <7jb1l9$694$1@nnrp1.deja.com> <928703068.617.98@news.remarQ.com> <375F6F0B.AD735B5B@praxis-cs.co.uk> <7jo1d2$kno$1@pegasus.csx.cam.ac.uk> <929128919.557.95@news.remarQ.com> <7jsdkf$v3p$1@nnrp1.deja.com> <929221844.567.59@news.remarQ.com> <7jvakl$nqi$1@nnrp1.deja.com> Organization: ? X-NETCOM-Date: Sun Jun 13 6:28:40 AM CDT 1999 User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (SunOS/4.1.4 (sun4m)) Newsgroups: comp.lang.ada NNTP-Posting-User: swhalen Date: 1999-06-13T06:28:40-05:00 List-Id: Robert Dewar (robert_dewar@my-deja.com) wrote: : : There is a big difference between high integrity software : (yes, most certainly safety critical is a little too : restrictive) and the general notion of reliable software. : : All software should be written in a reliable manner, and using : techniques that promote reliability. : : The danger of making the jump from high integrity to... [snip] : I have more than once run into situations where people write : a chunk of a program in C because some nitwit manager has : forbidden the use of (e.g.) unchecked conversion completely. Many excellent points and much useful information in this thread. I agree with those who believe that the 359 document should be "pushed" more widely in the Ada community. I take your point that over emphasis of "high integrity" processes like those described in the 359 document can lead to unintended consequences or needless expense or even failed projects. However, in many systems there are portions of the system that MUST be more reliable and robust and trusted than the rest of the system. The techniques and processes described in the "high integrity" document may be entirely appropriate for a small portion of a larger system. By applying the "high integrity" processes and $$$ to a small portion of a larger system, you can greatly increase overall reliablity and improve the value of the system, even if the system is not in one of the categories of systems we typically think of as requiring "high integrity". Steve -- {===--------------------------------------------------------------===} Steve Whalen swhalen@netcom.com {===--------------------------------------------------------------===}