SEI niet pessimistisch over softwarecrisis

19 augustus 1999


Het Software Engineering Institute (SEI) is als hoeder van het inmiddels bekende CMM-model zeer begaan met de kwaliteit van de softwareontwikkeling. Pessimistisch zijn de mensen van het SEI niet. Van een ’softwarecrisis’ is wel sprake, maar het zijn steeds nieuwe problemen waarop softwareontwikkeling stuit.

Verhalen over het uitblijven van verbetering in de succesratio van softwareontwikkelprojecten zijn aan de mensen van het SEI niet besteed, al kan er nog veel worden verbeterd. Clyde Chittister, als ’COO’ de tweede man van het SEI, denkt dat we de successen vaak uit het oog verliezen
„Een Boeing 777 is bijzonder software-intensief maar functioneert fantastisch. Auto’s hebben vaak meer dan dertig processoren, bijvoorbeeld voor een antiblokkeersysteem, en werken zeer goed. Veel software in allerlei toepassingen werkt op zo’n manier dat je er niet meer stil bij hoeft te staan. Denk maar aan de telefonie. Er zijn ook veel gebieden waar software fenomenaal werkt, maar waar nog steeds behoefte is aan verbetering. We moeten nog sneller een goed product kunnen afleveren.”
Chittister is ervan overtuigd dat het bouwen van software uiteindelijk net zo efficiënt kan verlopen als het bouwen van bijvoorbeeld een auto. „Maar het vergt wel wat veranderingen in technologie en vooruitgang in processen, dus in de manier waarop ingenieurs systemen ontwerpen. Technologie en processen moeten meer vervlochten zijn om betrouwbare systemen te bouwen.”
Zijn collega Bill Peterson wil het bouwen van software eerder vergelijken met het ontwerpen van de auto, niet met de bouw ervan. „Software bouwen is een ontwerpproces.”
Linda Northrop, programmadirecteur bij het SEI, stelt voorop dat de te bouwen software vooral veel complexer is geworden. „We hebben inderdaad nog steeds problemen met software, maar de meetlat ligt ook veel hoger en wordt nog steeds hoger gelegd. Hoe die software met de omgeving communiceert en wat die software allemaal moet kunnen, dat is enorm veranderd. Als we hetzelfde soort programma’s zouden bouwen als vroeger zou het nu absoluut zonder problemen gaan. Maar wie zou tien jaar geleden hebben voorspeld dat we nu grote op het web gebaseerde toepassingen zouden maken?”
De vergelijking tussen het maken van software en het maken van een auto kan nog worden doorgetrokken, meent Northrop. „Een auto ontwerpen is ook veel makkelijker geworden juist dankzij de IT. Er hoeft voor veel aspecten zelfs niet meer fysiek te worden getest. Botsproeven kunnen bijvoorbeeld deels achterwege blijven.”

Productlijnen
Maar een kwalitatief goede en gestroomlijnde softwareontwikkeling is niet alleen een kwestie van processen – en dus het gebruik van SEI’s CMM-modellen – maar ook van het minder ad hoc maken van de productie van software. Northrop leidt bij het SEI de Product Line Practice, een poging tot het formaliseren van softwareontwikkeling binnen ’product lines’, ofwel verzamelingen gereedschappen waarmee men steeds globaal dezelfde architectuur, herbruikbare componenten, schema’s, budgetten, testen, documentatie et cetera gebruikt voor het ontwikkelen van systemen. Het van de grond af programmeren van eenmalige systemen is al verleden tijd, maar de nadruk moet nog veel meer liggen op het snel kunnen ’componeren’ en genereren van toepassingen, zo gauw de eisen ook maar enigszins afwijken van wat er al is.
Northrop: „Het zit niet alleen in de processen die we gebruiken, maar ook in een slim gebruik van de producten door ze te zien als families van softwaresystemen. In de autoindustrie gebeurt dat al; daar heeft men standaarden voor het bouwen van een auto. Ook in de hardware-industrie is het al ingeburgerd en mensen beginnen nu een beetje te begrijpen dat ook software op die manier kan worden gemaakt. Zo kunnen organisaties veel sneller hun product op de markt krijgen.”

Tegen wil en dank
Chittister merkt nog op dat een dergelijke standaardaanpak in de industrie veel moeilijker is te verwezenlijken dan in de software. „Software is niet fysiek, dus daar moet het veel makkelijker zijn. Maar met software heb je ook een veel grotere kans op fouten, dus voor de betrouwbaarheid heb je die betere processen nodig.”
In softwareontwikkeling is de telecomindustrie een voorloper. Northrop: „Ze zijn leiders in het gebruik van technologie en ook in het gebruik van softwareproductlijnen. Vanuit het technische standpunt gezien zitten ze op de voorste rij.”
Peterson komt nog met een andere reden op de proppen voor de ’softwarecrisis’. „Waarom hebben we nog steeds een crisis? Niet ieder bedrijf heeft zich meteen gerealiseerd dat het in de softwarebusiness zat.”
De Duitse witgoedfabrikant Bosch bijvoorbeeld is zo’n bedrijf dat tegen wil en dank softwareontwikkelaar is geworden. Northrop: „Bosch had een reputatie die is gebaseerd op hun mechanische expertise. Opeens werd software een belangrijk onderdeel van hun producten. Om hun reputatie te behouden moeten ze wel dezelfde standaarden nastreven voor hun software. Bij Bosch is dat aardig gelukt, maar in veel organisaties resulteert het in een heuse crisis.”
Chittister: „E-handel is ook zo’n voorbeeld. Het individu krijgt de controle over de handel in plaats van bijvoorbeeld een beurshandelaar of een reisbureau. Dat stelt hele nieuwe eisen aan de kwaliteit van de software.”
Het millenniumprobleem heeft een nieuw licht geworpen op softwareontwikkeling. In het licht van de noodzaak met softwareontwikkeling verder vooruit te kijken, is het millenniumprobleem misschien wel een zegen, meent Northrop. „Niemand weet hoe de directe impact zal zijn. Maar wat er ook gebeurt, we weten dat mensen nu hun afhankelijkheid van computers beter begrijpen. Er zal dus een veel groter begrip zijn vanuit het publiek voor het belang van software. Mijn zoon zit in de softwareontwikkeling en realiseert zich nu veel meer dan mijn eigen generatie wat de verantwoordelijkheid van programmeurs is. Die verantwoordelijkheid gaat verder dan wat ze nu coderen. Misschien kun je het millenniumprobleem ook gewoon zien als een gebrekkige softwareontwikkeling.”
Ook bedrijven zelf zijn wakker geschud door het probleem. „Bij één organisatie bleken de processen die ze opstelden voor het millenniumprobleem zo effectief te zijn, dat ze besloten ook een programma voor procesverbetering te beginnen.”

Automatisering Gids • fbl • 20-08-’99
SEI en CMM
Het Software Engineering Institute wordt gefinancierd door het Amerikaanse ministerie van Defensie en is verbonden aan de Carnegie Mellon University in Pittsburgh (VS). Het SEI is vooral bekend door het Capability Maturity Model (CMM), dat er eind jaren tachtig werd ontwikkeld. CMM, inmiddels in gebruik bij naar schatting 5000 bedrijven, is een referentiemodel voor het aangeven van de mate van ’volwassenheid’ die een organisatie in haar softwareontwikkelingsprocessen heeft bereikt (en weet te behouden). Voor goede software moet het ontwikkelproces goed in elkaar steken, zo is de gedachtegang. In het CMM kunnen bedrijven daarin vijf niveaus behalen; de meeste bedrijven bevinden zich nog op niveau 1, maar voor het merendeel van de bedrijven moet niveau 3 haalbaar zijn.
Het kijken naar processen moet volgens het SEI overigens niet alleen op organisatieniveau gebeuren, zoals bij CMM. De afgelopen jaren heeft het instituut dan ook vergelijkbare modellen ontwikkeld voor de team- en de individuele aspecten van softwareontwikkeling.
Het Personal Software Process (PSP) geeft aan hoe men op individueel niveau proces-principes in het ontwikkelwerk zou moeten gebruiken. Clyde Chittister van SEI: „Een van de bedrijven die veel werk in PSP heeft gestoken, is Baan. Ook universiteiten gaan ermee aan de slag.”
Het Team Software Process (TSP) is een richtlijn voor het op teamniveau afleveren van softwareproducten binnen de gestelde termijnen en budgetten.
Verder doet het SEI werk op onder andere de terreinen beveiliging, virusbescherming, componenten en embedded systemen. Maar, zegt Chittister, „onze kernmissie is niet het bedenken van de optimale softwareontwikkeling, maar van het in de praktijk doen brengen ervan.”

Informatie: www.sei.cmu.edu
Software zou men moeten bouwen op de manier waarop men auto’s fabriceert, zo suggereert het SEI. Nieuwe eisen – en die zijn er in software voortdurend – kunnen dan sneller in nieuwe systemen worden vertaald.
Clyde Chittister, ’chief operating officer’ van SEI.
 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!