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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, LOTS_OF_MONEY,REPLYTO_WITHOUT_TO_CC 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: "Veli-Pekka Nousiainen" Subject: Re: Interesting thread in comp.lang.eiffel Date: 2000/07/18 Message-ID: #1/1 X-Deja-AN: 647775826 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> <396502D2.BD8A42E7@earthlink.net> <39654639.B3760EF2@eiffel.com> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 X-Trace: read2.inet.fi 963928667 213.28.8.37 (Tue, 18 Jul 2000 16:57:47 EET DST) Organization: Sonera corp Internet services X-MSMail-Priority: Normal Reply-To: "Veli-Pekka Nousiainen" NNTP-Posting-Date: Tue, 18 Jul 2000 16:57:47 EET DST Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-18T00:00:00+00:00 List-Id: "Ken Garlington" wrote in message news:i4k95.7512$7%3.571616@news.flash.net... > "Bertrand Meyer" wrote in message > news:39654639.B3760EF2@eiffel.com... > > I am afraid we are on different wavelengths. Why was it the task of > > the Ariane 4 software developers to learn about Ariane 5? It's the > > other way around! If I reuse something, I am responsible for finding > > out what its contract is and whether it fits *my* needs. > > In practice, it's almost impossible for the prime contractor to do an > analysis at this level of detail (source code) for all the elements in this > type of system. They simply don't have the resources or expertise. > Therefore, it's more cost effective for the prime to write system-level > specifications -- which in some cases can be implemented with or without > software -- and let the vendor do the next level of analysis, including > whether the software meets the system specification (with some oversight by > the prime). This "divide and conquer" approach is essential given the > diversity of systems in a platform of this type. > > Consider a relatively simpler system: If you replace the control computer in > your automobile (especially if it has ABS), do you insist that your mechanic > analyze its source code first? I suspect that you (and he) probably treat > the control module as a "black box," and that he only reads the system > "specification" (data sheet) for that module. What if I'm _designing_ a new control computer (Endaira v.4 -> v.5) and a new software for it. Maybe I want the contracts from the earlier HW/SW builders and some test material? Here we go again: You think I would have used that old test material right away, don't you? VPN > > Any large project has politics. > > The fights of departments within companies can be as bad > > as those of cooperating nations. In this case, I think what you > > write reinforces the understanding that this was a technical > > and managerial software problem -- a software engineering problem, > > which would have been prevented by the proper software engineering > > principles and practices, including Design by Contract. > > I don't believe politics was the primary cause of the Ariane 5 accident. > However, I notice that many people assume that use of proper software > engineering techniques will overcome political and psychological barriers. > My personal experience is that if you don't have good human and > organizational relationships on a project, any technical approach will be > severely degraded. I suspect this is why the inquiry's recommendations speak > more to this issue than to design methodology choices. Of course, it takes a > lot more work to understand people vs. methodologies, so maybe it's not > surprising that a lot of people take this view. > > I am glad to see, however, that you now acknowledge that there was a > managerial dimension to the problem. > >