From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: John McCabe Newsgroups: comp.lang.ada Subject: Re: [OT] ESA project memories (was Re: is Ada used in James Webb Space Telescope software?) Date: Wed, 5 Jan 2022 16:43:11 -0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <87tuevtblb.fsf@nightsong.com> <19527aed-3b3a-44c2-acc8-2221dbc7a3b6n@googlegroups.com> <87pmpiubmb.fsf@nightsong.com> <279d8891-c296-4935-ab17-11e1ce2a40ecn@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 5 Jan 2022 16:43:11 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="813b6243b40d43af4c61c646468744f7"; logging-data="6577"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Wg9acAtegKovrxN64G+jP74OnAu2i8IQ=" User-Agent: Pan/0.147 (Sweet Solitude; 97d1711 github.com/GNOME/pan.git) Cancel-Lock: sha1:eeNADkjTgLnxwTerS8XlX90rUGo= Xref: reader02.eternal-september.org comp.lang.ada:63346 List-Id: On Fri, 31 Dec 2021 23:18:49 +0200, Niklas Holsti wrote: > On 2021-12-31 12:26, John McCabe wrote: >> We didn't really have that problem. On TCIU most of our requirements >> came from Dornier - > MMS-UK (ASAR instrument prime) - > Alcatel - > >> MMS-UK (TCIU team). Both MMS-UK teams were in Portsmouth. > Interesting :-). I had a similar, but inverse, experience in a later > project (SW for the Flexible Combined Imager instruments on the MTG > satellites) where Thales Alenia Space (France) was both our customer for > the whole SW and our subcontractor for a part of the SW. It led to a > number of "direct" communications and decisions between the two TAS-F > teams that bypassed our team (in Finland) and of which we learned later. > But not much harm done, overall a good project. It would be inappropriate of me to say whether or not that sort of behaviour occurred on ASAR, although I seem to remember occasions where Alcatel waived their right to be piggy-in-the-middle as some of the discussion about SAR pulse timing and the effect of shifting things around a bit, to deal with the fact that we would've needed a mid-90s supercomputer (and a substantial re-design of the TCIU -> T/R Module interface) to achieve what was originally specified, would've fried the brains of the people who were actually involved :-) > Although splitting work up into several companies does easily make for > inefficiency, in can also have the benefit of documenting stuff that > otherwise might be lost in internal e-mails or face-to-face discussions. > That is, if the companies involved do their work properly, and don't act > as you describe for Alcatel. But perhaps the Alcatel technical people > did as well as they could to mitigate a poor higher-level decision, by > being basically a transparent conduit, as you describe. To be fair (to MMS!), the actual documentation that was produced at the instrument level was pretty good. To be fair to Alcatel, as I mentioned, we'd been working without them on this for a long time before ESA decided to mandate that they should "manage" the TCIU development as a subcontract, so they were forced to pick up on stuff they pretty much hadn't cared about before. Ironically none of this helped with the documentation from Alcatel; the TCIU -> T/R Module interface I mentioned, for example. We went through 3 rounds of TCIU Software Requirements reviews (i.e. SRR, then re-visited at ADR and DDR or something like that), where our assumptions on how that interface worked (based on rough sketch ideas we'd been given rather than formal specification) were described, before someone at Alcatel bothered to read it and say "nah, doesn't work like that" (presumably in French) :- )