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,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: David Gillon Subject: Re: Interresting thread in comp.lang.eiffel Date: 2000/07/12 Message-ID: <396C9C7F.D9B20E5F@baesystems.com>#1/1 X-Deja-AN: 645532041 Content-Transfer-Encoding: 7bit References: <8ipvnj$inc$1@wanadoo.fr> <8j67p8$afd$1@nnrp1.deja.com> <395886DA.CCE008D2@deepthought.com.au> <3958B07B.18A5BB8C@acm.com> <395A0ECA.940560D1@acm.com> <8jd4bb$na7$1@toralf.uib.no> <8jfabb$1d8$1@nnrp1.deja.com> <8jhq0m$30u5$1@toralf.uib.no> <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> <3963CDDE.3E8FB644@earthlink.net> <3963DEBF.79C40BF1@eiffel.com> <2LS85.6100$7%3.493920@news.flash.net> <8k5aru$1odtq$1@ID-9852.news.cis.dfn.de> <8k8pk2$20cab$1@ID-9852.news.cis.dfn.de> <_dS95.9945$7%3.666180@news.flash.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Trace: 12 Jul 2000 17:25:11 GMT, rc3284.rochstr.gmav.gecm.com Organization: BAE SYSTEMS Avionics (Rochester) MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-12T00:00:00+00:00 List-Id: David K Allen wrote: > Applying business principles to the software engineering "Design By > Contract" will not really help much. > Conversely, trying to apply Dr. Meyer's software engineering principles to > the socio-political issues will not help either. > They are two different domains with different principles and techniques. Unfortunately, for the type of project we're discussing here the two uses of contract (requirements and legal) are likely inseperable, so Ken's arguments are a criticism based on real-world experience of the argument that DBC would have automatically solved the coordination issues (which is where we started). In an ideal world (where software engineers write the rules), maybe, in the real world, with lawyers, accountants and non-technical managers to be worked around the issue is much less clear. > But the point is that if DBC were a component of the software development > method used to build Ariane, then any attempts to reuse software from a > previous project would force the issue that the new project teams MUST HAVE > the specifications of any modules they intend to reuse. If that had been > part of the software develoment culture, then the subcontractor would have > required the additional information and the contractor would have gladly > complied and provided it. But the contracts between the companies were at the 'you provide a black box to meet this requirement' level, far above the level at which 'software development cultures' function. The need for information exchange for DBC would first have had to be pursued up multiple levels of the sub-contractor management tree until a level was reached at which the release of information could be sought, and then on the contractor side chased back down the tree until someone was found who could explain what was wanted. Think Dilbert 1 trying to have a technical discussion with Dilbert 2 by passing verbal messages through ten layers of pointy haired bosses each.... The assumption that this would logically result in the contractor 'gladly complying' doesn't necessarily reflect what happens in reality. And this is without even considering the security and clearance issues many such projects have to deal with. One thing I'm still waiting to hear in this discussion is how Eiffel would handle a temporal constraint of the type 'Signal A will be updated with its new value within 2.5 ms of a change to any of its source inputs'. -- David Gillon