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-Thread: 103376,c473e498c84938dd X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!elnk-atl-nf1!newsfeed.earthlink.net!stamper.news.atl.earthlink.net!newsread2.news.atl.earthlink.net.POSTED!d9c68f36!not-for-mail Message-ID: <4108F1A3.5000402@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Orders of Fault Management References: <2mnr9kFnpbivU1@uni-berlin.de> <410796AE.2080800@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 29 Jul 2004 12:46:35 GMT NNTP-Posting-Host: 209.165.23.19 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.news.atl.earthlink.net 1091105195 209.165.23.19 (Thu, 29 Jul 2004 05:46:35 PDT) NNTP-Posting-Date: Thu, 29 Jul 2004 05:46:35 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: g2news1.google.com comp.lang.ada:2456 Date: 2004-07-29T12:46:35+00:00 List-Id: Dmitry A. Kazakov wrote: > On Wed, 28 Jul 2004 12:06:13 GMT, Marin David Condic wrote: > > >>Also, a "bug" may not truly stop a software application from >>accomplishing its purpose. > > > Which is probably not a bug then. (:-)) Kind of a gray area. A common type of bug in the world I live in might be one where you fail to detect that an actuator is out of control because of a current difference between what you ask for and what you get. That is a bug. But sooner or later because of a position feedback, you see that the actuator is out of control and take the right accommodation. So you have a "bug", but due to redundancy in detection techniques, you can still use the software to operate the device safely. > > >>In that case, one might debate the economics >>of trying to remove "all bugs". It kind of leads to the question "How >>good is 'good enough'?" > > > Perhaps one should better talk about requirements fulfilling... See above. You fulfil the important system level requirement, but you fail a lower level requirement that might have lesser importance. Do you change your mind and say "well, that wasn't really a requirement - I can live without that feature for now." Or do you insist the software is unacceptable and delay everything until it is fixed? As is often the case, the answer is "It Depends..." There is no clear cut right and wrong here - you have to look at what the actual situation is and determine if you can live with it or not. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "All reformers, however strict their social conscience, live in houses just as big as they can pay for." --Logan Pearsall Smith ======================================================================