Nieuwsbank

Schrijft, screent en verspreidt persberichten voor journalistiek, search en social media. Hét startpunt om uw nieuws wereldkundig te maken. Ook voor follow-ups, pitches en korte videoproducties.

NGI werkgroep Software Engineering opgeheven

Datum nieuwsfeit: 03-05-2000
Vindplaats van dit bericht
Bron: Razende Robot Reporter
Zoek soortgelijke berichten
Nederlands Genootschap voor Informatica

Van rammelende flexowriter tot rammelende architectuur; einde wg Software Engineering

De werkgroep software engineering" heeft de overgang naar het nieuwe millennium niet afgewacht. Na bijna dertig jaar heeft de werkgroep zich opgeheven. In die dertig jaar hebben we het vak groot zien worden, zowel in mensen, als in geld, als in bitten per seconde. Met dit groter worden werd regelmatig het perspectief van waaruit we de beheersproblematiek benaderden bijgesteld. Van programma tot programmatuur. Van project tot levensduur. Van een hulpmiddel op zichzelf tot komponent van de ICT-infrastructuur.

De werkgroep begon als werkgroep portabiliteit". Hoe kun je programma"s maken die blijven werken als de computer wordt vervangen? Hogere programmeertalen zouden daar wel bij helpen, maar daarmee was niet alles gezegd. Voor je het weet bouw je aannamen over de omgeving in die bij wijzigende omstandigheden tot hoge aanpassingskosten leiden.

Programmacorrectheid kreeg de aandacht. Fouten maken is niet te vermijden, met testen kun je niet alle fouten vinden, maar hoe kun je fouten voorkomen? Aandacht voor ontwerpen en specificeren leidde to vele formele of geformaliseerde notaties en methoden, maar toepassing in de praktijk bleef lastig. We leerden van Lehman dat het uitmaakt met welk type probleem we te maken hadden. Bij het specificeren van compilers bijvoorbeeld zijn zowel probleem als oplossing helder. Bij een andere type probleem, zoals patroonherkenning of een schaakprogramma, is het probleem wel scherp te definiëren, maar de oplossing niet. Bij toepassingen in bedrijfsprocessen is vaak ook het probleem niet helder. Het moet snel, efficiënt en graag ook nog effectief, maar wat effectief en efficiënt is verandert voortdurend met de ambitie van het bedrijf en met de snel veranderende markt van ICT-komponenten.

De opdrachtgever hoort aan het stuur. Hij betaalt en verwacht dan ook waar voor zijn geld. Met een watervalproces waren in de begintijd van de automatisering de kosten van een project redelijk te beheersen, maar dat daarmee een antwoord op het eigenlijke probleem zou worden gegeven, werd met het betreden van nieuwe toepassingsgebieden steeds minder waarschijnlijk. En hoe kon je voorkomen dat het systeem een wissel zou trekken op de toekomst? Nu weten we dat het heel wat scheelt als je vier posities gebruikt voor een jaartal, maar het was al lastig genoeg om een project goed te beginnen, laat staan om verder te kijken dan het eind van een project.

Er was nogal wat om rekening mee te houden. Programma"s waren complex en de gebruiksmogelijkheden ook. Software engineers" waren net als iedereen beperkt in hun mogelijkheden. Het zelfde gold voor gebruikers, misschien wel in nog sterkere mate, want die hadden niet altijd om de automatisering gevraagd. Aan hulpmiddelen, goede raad en silver bullets" geen gebrek: gestructureerd programmeren, gestructureerd ontwerpen, functioneel decomponeren, functioneel programmeren, functiepunten, tweede normaalvorm, drie lagen architectuur, vierde-generatietalen, abstracte datatypen, objectoriëntatie, UML, socio-technisch benaderen, chaostheorie, inspecties, reviews", clean room", overdekkingsmetrieken. Om er maar een paar te noemen.

Bij veel discussies bleken de publicaties van Barry Boehm een belangrijke steun. Hij slaagde er met zijn kwantitatieve aanpak als geen ander in een praktische ordening aan te brengen in de wereld van de software engineering verschijnselen. Characteristics of software quality" was de eerste bijdrage van Boehm die veel aandacht kreeg binnen de werkgroep. Het leidde tot presentaties op een NGI-conferentie en publicaties in Informatie die jaren later nog een rol bleken te spelen in verbeteringsprogramma"s bij verschillende grote Nederlandse bedrijven. Ander werk van Boehm dat we na discussies binnen de werkgroep naar buiten brachten was de spiral approach", die werd afgezet tegen de bekende waterval benadering. Boehm"s seven basic principles of software engineering" vatten goed samen waar je bij de uitvoering van projecten op moet letten en bleken in de eigen praktijk een prima kapstok om de activiteiten van een verbeteringsprogramma aan op te hangen. We waren dan ook blij verrast toen het, dankzij goede connecties en financiële steun van de Afdeling Informatiesystemen, lukte om Boehm voor de werkgroep uit te nodigen.

Met het groeiende inzicht in het proces werd de vraag naar het creëren van de organisatorische randvoorwaarden voor het kunnen creëren en op peil houden van goede programmatuur interessant. Wat kun je leren van mensen als Mintzberg of van het 7S-model? Welke vaardigheden moet een software engineer" hebben? Wat houdt software-architectuur in en wat zou de rol van een software-architect moeten zijn? Welke eisen stel je aan de organisatie en de hulpmiddelen? In de literatuur verschenen ervaringen van bedrijven met eigen opleidingsprogramma"s. Software engineering" werd een vak op universiteiten. ISO kwam met een speciale kwaliteitsrichtlijn voor software organisaties. De IEEE verzorgde waslijsten aan software engineering"-normen. Humphrey publiceerde zijn beroemde door Crosby geïnspireerde beheersingsniveaus. SPICE deed daar nog een schepje bovenop.

De werkgroep kwam iedere twee maanden een dag bij elkaar bij een van de werkgroepleden. Literatuur signalering was een belangrijk agendapunt. Artikelen werden in principe kort besproken, maar leidden regelmatig tot enthousiaste discussies die gemakkelijk een uur konden duren. Meegebrachte boeken en tijdschriften werden tussen de bedrijven door doorgegeven en doorgenomen. Het was een praktische manier om gevoel te houden voor wat er in het software engineering"-wereldje speelde, zonder van alles de details te hoeven kennen.

Met het verschuiven van de aandacht naar de organisatorische randvoorwaarden werd het steeds moeilijker om de discussie te richten op een gemeenschappelijk ervaren problematiek. Door de jarenlange discussies was wel een waardevol niveau van elkaar verstaan bereikt, maar de afstand met de dagelijkse praktijk en de daaruit volgende belangstelling werd groter. Ook veranderde het te beheersen proces drastisch. Software werd steeds minder in eigen huis vanaf scratch" ontwikkeld en op programmeertaalniveau onderhouden. Het ging steeds meer om de beheersing van de samenwerking van ICT-komponenten met een sterk uiteenlopende herkomst. Eigenlijk ging de discussie steeds meer om eisen aan de architectuur, een discussie waar we niet uit zijn gekomen. Bovendien bestond er al een werkgroep architectuur. Tijd om ermee op te houden.

Ik bedank alle oudleden voor de bijdrage aan de werkgroep, voor de gastvrijheid, voor het enthousiaste commentaar en voor de onvergelijkbare sfeer. We zijn met zijn allen toch een stuk wijzer geworden, en de programma"s steeds beter 'portable'. Met alle problemen van dien.

Jos Fienieg

reageer via disqus

Nieuwsbank op Twitter

Gratis persberichten ontvangen?

Registreer nu

Profiteer van het gratis Nieuwsbank persberichtenfilter

advertentie