Development

Software-ontwikkeling
Outsourcing in de ruimtevaart

Outsourcing in de ruimtevaart

Waarom de ene uitbesteding succes opleverde en de andere jammerlijk faalde.

2 december 2020

NASA heeft twee bedrijven uitgekozen om voor haar ruimtevaartuigen te ontwikkelen en te bouwen om astronauten van en naar het International Space Station te vervoeren. In februari 2020 werd bekend dat Boeings Starliner – zo'n ruimteschip – nog een paar softwarefouten had. 

De ene fout voorkwam dat het ruimtevaartuig aan het International Space Station kon aankoppelen (waar het allemaal om te doen was), en de andere fout kon zorgen voor een ruimtebotsing met catastrofale afloop.

Je begrijpt niet hoe het kan, maar de softwareklok stond elf uur voor en dat zorgde ervoor dat de Starlinersoftware dacht dat het ruimtevaartuig heel ergens anders was dan waar het werkelijk was. Daardoor werd veel te veel brandstof verbruikt, waardoor het aanmeren aan de ISS overgeslagen moest worden om nog heelhuids te kunnen terugkeren.

Omdat men naar de eerste fout aan het kijken was, ontdekte men nog een tweede fout. Deze fout moest tijdens de (gelukkig onbemande) testvlucht naar het ISS gerepareerd worden om een ruimtebotsing te voorkomen. Als de crewmodule van de servicemodule werd losgemaakt, konden de verkeerde stuwraketten worden geactiveerd vlak voordat deze wegwerpmodule de aardatmosfeer zou ingaan, waardoor het ding terug naar de crewmodule was gestuurd, met een mogelijke botsing tot gevolg.

NASA gaf aan dat de softwarefouten waarschijnlijk symptomen waren van een dieperliggend probleem, namelijk de coding culture van Boeing. Recentelijk was de Starliner weer in het nieuws. Boeing had nog steeds problemen met de software.

Ze gingen er blijkbaar van uit dat als het proces goed is, het product ook goed is

SpaceX, aan de andere kant, loopt fiks voor. Ze hebben een goede testvlucht gehad. In mei was er een bemande testvlucht, en deze maand (23 oktober) is een operationele vlucht gepland om astronauten voor een langer verblijf naar het ISS te brengen.

NASA gaf aan dat zij veel aandacht aan het werk van SpaceX had besteed omdat het een ander niet-traditioneel softwareproces gebruikte, namelijk agile. Het proces van Boeing kenden ze wel en blijkbaar gingen ze ervan uit dat als het proces goed is, het product ook goed is. Dat blijkt dus niet het geval te wezen. Nu moeten we niet doordraven en denken dat agile de reden van succes is geweest. Uit mijn onderzoek aan IT-outsourcingsucces en -falen is gebleken dat de afwezigheid van formele kwaliteitsbewaking bij de klant in combinatie met de aanwezigheid van agile/scrum bij de leverancier is geassocieerd met het falen van de deal. Maar die QA was er juist wel voor SpaceX.

Wat in ieder geval doorslaggevend bleek te zijn om outsourcingsucces te behalen, is dat de klant scherpe kwaliteitsbewaking voert. En dat had de NASA voor SpaceX gedaan, niet voor Boeing.

NASA heeft een goudgerande deal gesloten door met twee partijen te werken. Ze hebben zelf veel kennis in huis, goede software en dito engineers, dus met in-house development had dit zogenaamde commercial crew program even goed zo niet beter gekund.

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (novembernummer, 2020). Wil je alle artikelen uit dit nummer lezen, klik dan hier voor de inhoudsopgave.

Reactie toevoegen
1
Reacties
Anoniem 11 januari 2021 18:09

'Agile' is trouwens een bijvoeglijk naamwoord, waardoor het vaak fout gebruikt wordt. Zoals hierboven.

'Agility' is dan weer te moeilijk voor de gemiddelde meeprater.

Waarschijnlijk weten die ook niet dat ze respektievelijk lenig en lenigheid betekenen.