Automatisering van de informatievoorziening

Download de illustraties behorende bij het college: 240 KB

Inleiding

Om in de informatiebehoefte van een bedrijf te voorzien, worden informatiesystemen gebruikt. Deze informatiesystemen komen tot stand door middel van systeemontwikkeling.

 

In dit hoofdstuk beschrijven we hoe het proces van systeemontwikkeling in het algemeen is opgebouwd, hoe we tot een ontwikkelstrategie komen en welke hulpmiddelen we kunnen gebruiken voor systeemontwikkeling.

Leerdoelen

Na het bestuderen van dit onderwerp wordt verwacht dat u weet:

• Uit welke fasen systeemontwikkeling bestaat.
• Welke disciplines een rol spelen tijdens het systeemontwikkeltraject.
• Welke strategieën in de verschillende fasen van systeemontwikkeling gebruikt kunnen worden.
• Welke soorten tools bij systeemontwikkeling worden toegepast.

Produkten van systeemontwikkeling

Bij systeemontwikkeling denkt bijna iedereen logischerwijs aan het ontwikkelen van software en dan met name aan het daadwerkelijk bouwen van deze software. Systeemontwikkeling omvat echter meer dan slechts het bouwaspect van software; een moderne methode van systeemontwikkeling heeft namelijk ook expliciet aandacht voor sociaal organisatorisch aspecten, zoals weergeven is in onderstaand figuur.

Het figuur laat zien, dat systeemontwikkeling een proces is dat een multidisciplinair karakter kent. Informatiesystemen horen te worden ontwikkeld vanuit een informatiebeleid dat geaccepteerd is door het topmanagement. Op dit informatiebeleid worden een aantal plannen gebaseerd ten behoeve van de ontwikkelingen van informatiesystemen, infrastructuren en personele organisaties. Deze ontwikkelingen zullen in projectvorm worden uitgevoerd waarbij men alert moet zijn op de eventuele onderlinge beïnvloeding. De feitelijke ontwikkeling van een informatiesysteem loopt van definitiestudie tot en met de invoering. Na het basisontwerp worden verschillende werkzaamheden naast elkaar uitgevoerd. Uiterst rechts staat de bouw van de programmatuur. Indien van toepassing wordt een gegevensconversie uitgevoerd die vroegtijdig moet worden voorbereid. Uiterst links staan de werkzaamheden die dienen te worden uitgevoerd om de organisatorische inbedding van het informatiesysteem aan te passen en de aansluiting van de programmatuur op de organisatie te bewerkstelligen. Met de middelste lijn wordt bedoeld dat de gebruiker niet kan gaan rusten terwijl ‘links’ en ‘rechts’ van hem de organisatiedeskundigen resp. de bouwers druk bezig zijn. Onder voorbereiding acceptatie valt niet alleen het opzetten van een acceptatietest, maar ook algemenere zaken als voorlichting, gebruikerstrainingen en ondernemingsraadachtige zaken. Acceptatie impliceert immers de bereidheid van de eindgebruikers om het informatiesysteem te willen gaan gebruiken. Als de acceptatie uiteindelijk heeft plaatsgevonden en de invoering van het nieuwe informatiesysteem een feit is, zal het informatiesysteem gebruikt en dus ook beheerd en onderhouden moeten worden.

In onderstaand figuur laten we globaal zien welke aanpassingen er zijn bij het bouwen van informatiesystemen door middel van standaardpakketten. Vooral administratieve informatiesystemen worden vaak gebouwd door middel van standaardpakketten. Hierbij kunt u denken aan standaardpakketten van bijvoorbeeld SAP, Baan en Oracle.

Tijdens de systeemontwikkeling ontstaan er een hele reeks produkten, deze systeemontwikkelprodukten kunnen we onderverdelen in vier groepen:

• Systeemdocumentatie: denk bijvoorbeeld aan gebruikshandleidingen, gegevensmodellen en procesmodellen.
• Projectdocumentatie: zoals correspondentie, plannen en rapporten. Deze worden slechts gebruikt tijdens het systeemontwikkeltraject, terwijl handleidingen en dossiers ook nog blijven bestaan na afloop van het systeemontwikkeltraject.
• Applicaties en testsets, de werkelijk gebouwde programmatuur en de testsets om deze programmatuur te testen.
• Overige produkten zoals opgeleide medewerkers en geconverteerde gegevens.

Onderdelen van systeemontwikkeling

De feitelijke traditionele manier van systeemontwikkeling bestaat zoals eerder genoemd uit drie hoofdfasen :

• Het beschrijven en ontwerpen van het informatiesysteem
• Het construeren van het informatiesysteem
• Het invoeren van het gebouwde informatiesysteem

We gaan nu op ieder van deze fasen nader in.

Beschrijven
 

Voordat een informatiesysteem gebouwd gaat worden is het belangrijk om de functionele eisen en de kwaliteitseisen die aan het te ontwikkelen informatiesysteem gesteld gaan worden vast te stellen en vast te leggen. Er zijn een aantal redenen te bedenken waarom het belangrijk is deze verschillende eisen van te voren vast te leggen:

• Een informatiesysteem kan pas gebouwd worden als er bekend is wat er gebouwd moet worden.
• Als eisen van te voren niet worden vastgelegd, kan het gebeuren dat de klant achteraf ontevreden is met wat hij gekregen heeft. Vooraf is dan namelijk niet afgesproken wat men kon verwachten.
• Een informatiesysteem moet ingebed worden in een organisatie. Door van te voren te beschrijven hoe het informatiesysteem zal werken, weet men tijdig welke organisatorische veranderingen plaats moeten vinden om het informatiesysteem ingevoerd te krijgen.
• Het is voor zowel de gebruiker als voor de persoon die het informatiesysteem gaat onderhouden belangrijk om kwaliteitseisen aan het informatiesysteem van te voren vast te leggen. Om een informatiesysteem te kunnen onderhouden, zullen er onder andere eisen gesteld moeten worden aan de flexibiliteit, de testbaarheid en de onderhoudbaarheid van het te bouwen informatiesysteem. Voor de gebruiker is het belangrijk dat het informatiesysteem efficiënt en effectief werkt en dat continuïteit gegarandeerd is. Als u meer wilt weten over deze productkwaliteitseisen en andere kwaliteitseisen, dan verwijzen we u graag naar hoofdstuk 11 "Kwaliteitszorg".

Er bestaan twee werkwijzen bij het produceren van informatiesysteembeschrijvingen:

• Een analytische werkwijze, waarbij gebruik gemaakt wordt van abstracties en specificaties.

• Een experimentele werkwijze, waarbij gebruik gemaakt wordt van experimenten en prototypes.

Construeren
 

Als alle eisen uit de voorgaande paragraaf zijn vastgelegd, kan het informatiesysteem daadwerkelijk gebouwd worden. Tijdens het bouwen worden als het ware de functionele eisen en de kwaliteitseisen naar een werkend informatiesysteem (inclusief handmatige procedures) omgezet. Dit kan op een aantal manieren, namelijk door middel van:

• Programmeren: het ambachtelijk ontwikkelen van software met behulp van 3e en 4e generatie programmeertalen.
• Genereren: het automatisch genereren van software uit specificaties.
• Configureren: het configureren van generieke pakketsoftware naar een specifieke situatie.
• Assembleren: het assembleren van (bij voorkeur bestaande) componenten tot één geheel.

Uiteraard worden voor het ontwikkelen van software ook combinaties van bovenstaande manieren gebruikt.

Om een informatiesysteem te bouwen (en te testen) zijn een aantal strategieën voorradig:

• One-shot: het gehele informatiesysteem wordt in een keer gebouwd en getest.

• Incrementeel: het informatiesysteem wordt in opvolgende delen gebouwd en getest. Ieder deel bevat een subset aan functionaliteiten. De eisen voor het informatiesysteem zijn voordat de eerste bouw plaatsvindt volledig bekend en veranderen nadien ook niet meer.

• Evolutionair: het informatiesysteem wordt in opvolgende versies gebouwd en getest. Tussen twee versies in kunnen de eisen aan de beschrijving en bouw van het informatiesysteem veranderen door opgedane ervaringen bij het testen van het informatiesysteem. Iedere versie kan hetzij een deel van de functionaliteiten bevatten, hetzij de gehele set aan functionaliteiten bevatten.

Invoeren
 

Tijdens de laatste fase van het ontwikkelen van het informatiesysteem dient het informatiesysteem ingevoerd en ingebed te worden in de organisatie van de klant. Met invoeren en inbedden bedoelen we het installeren en operationeel in gebruik nemen van een informatiesysteem, met inbegrip van de organisatorische veranderingen. Bij organisatie brede en complexe informatiesystemen kan er voor gekozen worden het informatiesysteem niet in z’n geheel in één keer in te voeren, maar bijvoorbeeld het informatiesysteem eerst voor één afdeling in te voeren. Deze stap kan dan bijvoorbeeld dienen als een pilot, met de bedoeling het informatiesysteem aan te passen en het installatieproces te verbeteren zonder dat dit grootschalige gevolgen heeft voor de gehele organisatie. In de volgende stappen kan de geografisch dekking dan geleidelijk aan toenemen, totdat in de laatste stap het hele doeldomein wordt afgedekt.

Ontwikkelstrategieën en ontwikkelmethoden

Uit de vorige paragraaf is gebleken dat het ontwikkelen van een informatiesysteem bestaat uit drie fasen. In de volgende subparagrafen laten wij u zien dat voor systeemontwikkeling verschillende strategieën en methoden bestaan.

 

Ontwikkelstrategie
 

We beginnen met een definitie. Een ontwikkelstrategie is een manier waarop het ontwikkelen van een component van een informatiesysteem kan worden aangepakt: een globale filosofie over de wijze waarop ontwikkelactiviteiten en ontwikkelobjecten in de tijd worden geordend. De ontwikkelstrategie is daarom in feite een combinatie van de strategie voor beschrijven, de strategie voor construeren en de strategie voor invoeren. Een ontwikkelstrategie bestaat dan ook uit:

• Een aanpak voor ontwikkeling en beheersing.
• Voorstellen voor risicobeheersing
• Eventuele voorstellen voor veranderingsacties, als de situatie waarin het informatiesysteem ontwikkeld wordt daar om vraagt.

Het spiraalmodel van [Boehm] erkent deze strategiepunten ook. Het model laat zien, dat het wenselijk is om softwareontwikkeling te zien als een cyclisch proces. In iedere cycle komen de fases verzamelen van eisen, ontwerp, implementatie en testen naar voren. Het cyclisch proces identificeert eerst het deelprobleem waaraan het hoogste risico gekoppeld zit en zoekt daarna een oplossing voor dat probleem. Op deze manier kunnen de totale ontwikkelkosten in de hand worden gehouden. Zie onderstaand figuur.

Ontwikkelmethoden
 

Voor het ontwikkelen van informatiesystemen zijn in de loop van de tijd een aantal methoden ontstaan om informatiesystemen te ontwikkelen. Per definitie verstaan we onder een ontwikkelmethode een vaste, weldoordachte manier van handelen om een bepaald resultaat te behalen. Een gedegen ontwikkelmethode biedt dan ook:

• Verifieerbare resultaten (producten).
• Duidelijke ontwikkelstappen (uitvoer, invoer en de relatie daartussen).
• Per ontwikkelstap en per product:
• Regels en richtlijnen
• Technieken (werkwijzen en afbeeldingswijzen)
• Hulpmiddelen
• Scheiding tussen projectdocumentatie (denk aan projectplannen en voortgangsrapportages) en systeemdocumentatie (denk aan systeembeschrijvingen en gebruikershandleidingen etcetera).

Bekende ontwikkelmethoden zijn:

• Lineaire systeemontwikkelmethoden: dit zijn klassieke methoden voor systeemontwikkeling, zoals bijvoorbeeld de watervalmethode. Bij de watervalmethode wordt op een lineaire wijze een informatiesysteem ontwikkeld. Allereerst worden de eisen voor het informatiesysteem bedacht, vervolgens wordt er van deze eisen een ontwerp gemaakt. Dit ontwerp wordt vervolgens gebouwd en getest en tenslotte wordt het informatiesysteem ingevoerd.
• Iteratieve systeemontwikkelmethoden: dit zijn modernere methoden voor systeemontwikkeling. Net zoals bij lineaire systeemontwikkelmethoden worden alle fasen van het ontwikkelproces doorlopen (van het definiëren van de eisen tot aan het invoeren van het informatiesysteem). Het verschil met de vorige methode is echter dat alle fasen meerdere keren achter elkaar worden doorlopen. Er wordt als het ware gebruik gemaakt van meerdere ontwikkelcycli. Tijdens iedere cyclus wordt het informatiesysteem een stukje uitgebreid. Zo ontstaat na een aantal cycli het gewenste informatiesysteem.
• Systeemontwikkelmethoden volgens pakketbouw: het bouwen van informatiesystemen door het toepassen van standaardpakketten bij klanten. Zoals al eerder in dit hoofdstuk werd aangegeven is pakketbouw met name geschikt voor het implementeren van administratieve informatiesystemen.
• Componentsgewijze systeemontwikkelmethoden: het bouwen van informatiesystemen door gebruik te maken van kant en klare componenten. Deze laatste manier van systeemontwikkeling staat nog in de kinderschoenen, maar zal in de toekomst waarschijnlijk steeds vaker voorkomen, omdat het ontwikkelen in componenten er voor kan zorgen dat informatiesystemen veel sneller gebouwd kunnen worden en veel beter kunnen worden onderhouden, doordat er gebruik gemaakt wordt van herbruikbare componenten.

Kwaliteit van een informatiesysteem

Zoals al eerder is opgemerkt speelt naast de functionele eisen die aan een informatiesysteem worden gesteld ook de kwaliteitseisen een belangrijke rol. Hierbij doet zich de extra moeilijkheid voor dat gebruikers wel zo'n beetje hun functionele behoefte kunnen formuleren, maar dat hun kwaliteitsbehoeften veel moeilijker boven tafel te krijgen zijn. Het is voorts belangrijk om een onderscheid te maken tussen wensen en eisen. De kwaliteiteisen dienen uiteindelijk te worden omgezet in maatregelen die zorgen voor de gevraagde kwaliteitseigenschappen.

 

De cyclus van behoefte, via kwaliteitseisen, naar maatregelen en uiteindelijk vertaald in eigen schappen dient te worden meegenomen in de ontwikkelcyclus.

We zien in deze figuur dat er een terugkoppeling is tussen eigenschappen en maatregelen en tussen maatregelen en kwaliteitseisen omdat er soms wat water bij de wijn dient te worden gedaan.

Tools

Voor de verschillende onderdelen van het systeemontwikkeltraject bestaan verschillende hulpmiddelen, zo zijn er:

• Analysis & design tools, ofwel upper-CASE-tools: dit zijn tools die ondersteuning bieden bij de definitiestudie, het maken van een basisontwerp of het maken van een detailontwerp. Denk bijvoorbeeld aan: Cap Gemini's SDW, Sterling’s Cool-Gen.
• Development tools, ofwel lower-CASE-tools: dit zijn tools die ondersteuning bieden bij het programmeren, construeren van software. Denk bijvoorbeeld aan: Uniface, Powerbuilder, NatStar
• GUI Development tools: dit zijn tools die ondersteuning bieden bij het ontwikkelen van grafische gebruikersinterfaces. Visual Basic, Borland Delphi, Visual Java J++
• Repository based tools, ofwel systeemencyclopedieën: met behulp van systeemencyclopedieën heeft de ontwikkelaar alle systeemdocumentatie op één plaats. Denk bijvoorbeeld aan: Microsoft Repository
• Tools die een combinatie zijn van bovenstaande tools: denk bijvoorbeeld aan Designer 2000 van Oracle

Fabrieksmatige aanpak

Tenslotte willen we u in deze paragraaf laten zien wat we in de systeemontwikkeling verstaan onder een fabrieksmatige aanpak.

 

Componentsgewijze systeemontwikkeling is een trend die we de laatste tijd steeds vaker zien. Dit verklaart wellicht waarom de laatste tijd een fabrieksmatige manier van systeemontwikkeling de aandacht trekt. Bij het fabrieksmatig ontwikkelen van software denken we aan het snel construeren van software eventueel met behulp van kant en klare componenten, dit in tegenstelling tot het ontwikkelen van software op een ambachtelijke manier. Zoals uit onderstaand figuur blijkt, staat in een softwarefabriek kennisbeheer en kennisontsluiting centraal. Een softwarefabriek kan namelijk slechts optimaal werken, als het ontwikkelproces kan steunen op een goed architectuurraamwerk, waarbij kennisbeheer en kennisontsluiting centraal staat. In een fabriek worden namelijk waar mogelijk componenten hergebruikt, ingekocht of zelf geassembleerd met het doel zo snel mogelijk een kwalitatief hoogwaardig product af te leveren.

Evolutie in het proces van systeemontwikkeling

Zoals in het behandelde hierboven reeds vermeld zijn er drie belangrijke facetten aan het proces van systeemontwikkeling, gevisualiseerd in het volgende plaatje, die de aard van systeemontwikkeling danig beïnvloedt : de aanpak, de ondersteuning en de wijze waarop gebruiker en ontwikkelaar met elkaar omgaan.

De relatie tussen gebruiker en ontwikkelaar wordt steeds "menselijker", enerzijds doordat de ontwikkelaar steeds krachtiger hulpmiddelen ter beschikking krijgt om de werkelijke behoefte bij de gebruiker naar boven te krijgen, anderzijds ontdekken we steeds betere op de situatie afgestemde ontwikkelaanpakken waarbij de gebruiker meer tot zijn recht komt.

Dit impliceert dat er aan de systeemontwikkelaar nieuwe stijl ook ander eisen worden gesteld. Naast voldoende kennis van ontwikkelaanpakken dient hij te beschikken over een gezonde hoeveelheid "soft skills" en een goed dosis "hard skills".

Onder soft skills verstaan wij de bekwaamheid om met de gebruiker om te gaan : vragen, luisteren, formuleren, demonstreren met als doel om de werkelijke behoefte boven tafel te krijgen. Onder hard skills verstaan we de bekwaamheden om te kunnen toveren met de hedendaagse toolsets om te tonen wat de gebruiker in zijn hoofd heeft. De systeemontwikkelaar evolueert van de introverte programmeur naar een extraverte probleemoplosser.

Historische terugblik op de systeemontwikkeling

In de kinderjaren van de informatietechnologie, de zestiger jaren, was applicatieontwikkeling een uiterst creatieve doch chaotische bezigheid. We "krasten" stukjes software zonder gehinderd te worden door voorschriften van welke aard dan ook. De kwaliteit was sterk afhankelijk van de individuele vakbekwaamheid van de programmeur. De gebruiker, voor wie we het feitelijk deden, was elke keer weer verbaasd wat er uit dit mystieke proces te voorschijn kwam. En als er enig verband te vinden was tussen wat hij vroeg en wat hij kreeg, was dat mooi meegenomen. Hij had door schade en schande geleerd dat de grote hoeveelheid "creativiteit" die bij dit magische proces benodigd was, impliceerde dat de kosten en het oplevertijdstip volledig onvoorspelbaar waren en altijd hoger respectievelijk later uitvielen dan hij in zijn stoutste nachtmerries had verwacht. Vanzelfsprekend mocht hij, simpele ziel, niet meedoen in dit magisch gebeuren. Hij moest wachten en mocht hopen.

 

In het decennium daarna, de zeventiger jaren, kwamen de methodologen aan de macht. De standaardisatie sloeg hard toe. Wij deden alles gestructureerd : we begonnen met het structureren van het programmeren, gevolgd door gestructureerd ontwerpen, afgerond door gestructureerd testen en "structured walkthrough". Het netjes en geordend werken kwam in zwang, een discipline die ons niet zelden veroordeelde tot de dwangbuis.

 

Deze ontluistering van het magisch proces had echter niet tot gevolg dat de gebruiker echt mocht meedoen. Het enige wat van hem werd gevraagd, was zijn handtekening "liefst met zijn bloed" te zetten onder de gestructureerde specificaties. Deze werden dan bevroren. Onnodig te zeggen dat de gebruiker niet warmliep voor de applicatie die hieruit te voorschijn kwam. Bovendien duurde de ontwikkeling meestal zo lang dat hij allang vergeten was waarvoor hij de applicatie ook alweer precies nodig had.

 

In de tachtiger jaren werd het roer overgenomen door de heren technologen. De automatisering werd los gelaten op de automatisering zelf. Met vierde-generatiesystemen, CASE-tools, herbruikbare modulen/objecten en repositories werd getracht een meer fabrieksmatige aanpak te volgen.

 

De gebruiker werd verleid mee te doen door de introductie van het prototypen, een soort "trial and error" om hem zijn ware behoefte te ontfutselen. Ondanks alle technologische hoogstandjes bleef die zelfde gebruiker zitten met de klassieke problemen: "ik kan eigenlijk niet precies zeggen wat ik in werkelijkheid nodig heb"; "ik weet niet hoeveel geld de benodigde applicatieontwikkeling mij echt waard is" en tenslotte "ik heb de applicatie nu meteen nodig, want ik wil nu mijn bedrijfsgebeuren aanpassen dan wel innoveren".

 

Pas in de negentiger jaren is het echt tot ons, informatici, doorgedrongen dat het ontwikkelen van een applicatie een evolutieproces is, dat verloopt langs de richting van toenemend inzicht in het wezen van de op-te-lossen situatie. Daarom werken we tegenwoordig : interactief (samen met de gebruiker), iteratief (ontwikkelen in een aantal cycli) en incrementeel (stapsgewijs uitbouwend tot een steeds grotere bruikbaarheid). Een nieuwe aanpak waarbij dogmatiek is verdreven door pragmatiek. Voor sommige zaken ga je recht op je doel af omdat je precies weet wat je wil. Bij andere zaken ben je verkennend bezig en helpen intensieve workshops om op het juiste pad te blijven. Een harmonische synthese tussen "slechts kort vooruit kunnen zien wat er met de business gebeurt" en "toch bepaalde zaken structureel te moeten regelen". Hierbij geeft een methode ondersteuning voor werkelijke creativiteit : niet bindend, maar richtinggevend.

 

Een volwassen benadering van de applicatieontwikkeling impliceert tevens een veel grotere betrokkenheid van de gebruikers, maar bovenal vergt het een radicaal andere attitude van de informatici.

 

De ideale mens volgens Socrates heeft een koel hoofd en een warm hart. De ideale systeemontwikkelaar in onze perceptie beheerst zowel de soft skills als de hard skills. Hij kan luisteren, inventariseren, formuleren en overtuigen. Daarnaast bezit hij de technische handigheid om mogelijke oplossingen "real life" te tonen. Applicatieontwikkelaars worden gewone mensen van vlees en bloed met een nuchter verstand. Er is geen plaats meer voor de introverte vakidioot van vroeger. Maar ook de dirigistische projectleider uit de voorgaande hiërarchisch getinte periodes heeft als verschijnsel zijn langste tijd gehad. We zien de noodzaak opkomen van een facilitator die als een "primus inter pares", zorgt dat een multidisciplinaire groep deskundigen naar een optimaal einddoel wordt geloodst.

 

Eindelijk doemt er een nieuw tijdperk van applicatieontwikkeling op boven de horizon; een periode waarin gebruiker en ontwikkelaar gezamenlijk als gelijkwaardige partners verantwoordelijk zijn voor een snellere en meer flexibele toepassing van informatietechnologie in de bedrijfsvoering. Teamwerk, waarbij de juiste mix van deskundigheden en persoonlijkheidsprofielen van cruciaal belang is.

 

Applicatieontwikkeling wordt een ontdekkingstocht van gebruikers en informatici die samen ontdekken hoe informatietechnologie bedrijfsprocessen en werkomstandigheden kan verbeteren. Het nut van applicatieontwikkeling ligt in een bedrijfsnoodzaak; en moet daarom gerelateerd zijn aan het veranderen van bedrijfsprocessen en het aanpassen van bedrijfsdoelen. Dit wordt tegenwoordig vastgelegd in een business case. Door toepassing van "benefit tracking", als thermometer, wordt de vinger aan de pols gehouden of het bereiken van de bedrijfsdoelen nog wel adequaat wordt nagestreefd. Het stapsgewijze implementeren is van wezenlijk belang om te borgen dat de organisatieverandering de verandering in de ICT kan bijbenen. Hierbij speelt verwachtingsmanagement een grote rol om, op voorhand, te regelen dat de ontwikkelde applicatie met applaus zal worden ontvangen. Het is een belangrijk instrument om frustraties te voorkomen.

 

Deze volwassen aanpak voor applicatieontwikkeling plaatst de (toekomstige) gebruikers weer expliciet in de hoofdrol. De gebruikers dienen immers een transformatie van hun (persoonlijk) functioneren te ondergaan. Voorts krijgt de opdrachtgever weer het roer in handen. Adequaat kennismanagement zorgt dat alle betrokkenen delen in de ervaringen die worden uitgewisseld, waarmee een fundamenteel leerproces op gang wordt gebracht.

 

Al met al heeft het vier decennia geduurd voor applicatieontwikkeling deze mate van volwassenheid heeft bereikt. We zien een nieuwe, vlotte en leuke methode van applicatieontwikkeling opkomen. Een methode die toegesneden is op deze hectische tijd waar de veranderingen in het bedrijfsleven en de maatschappij over elkaar heen struikelen. Een tijd waarin wij geen tijd meer hebben voor zogenaamde "technische" hoogstandjes, maar die vraagt om een no-nonsense methode van nuchtere zakelijkheid !

Trends

• We zien bij de gebruikers de behoefte verschuiven van het ontwikkelen "conform specificatie" naar het ontwikkelen met "fitness for use", of liever nog "fitness for purpose".
• Gebruikers willen minder in projectvorm werken en meer naar een vorm van continue verbetering door kleine aanpassingen.
• We zien de opkomst van gebruiksgericht specificeren op grond van "use cases".
• Bij opdrachtgevers zien wij de behoefte opkomen van "concurrent transformation", het gelijktijdig transformeren van het bedrijfsgebeuren en de daarbij behorende informatiesystemen.
• De opdrachtgever heeft minder behoefte aan serieel of lineair werken bij de ontwikkeling van de informatievoorziening.
• Opdrachtgevers willen liever "kopen" dan "maken". Dit resulteert naar een steeds groter marktaandeel voor pakketleveranciers in het segment systeemontwikkeling.
• We zien bij de systeemontwikkelaars een verschuiving optreden van het maken en bedenken van programmatuur naar het assembleren van ( software ) componenten.
• De hedendaagse systeemontwikkeling zal meer en meer worden opgesplitst in :
• - verrijking van de infrastructuur
• - applicatieontwikkeling ( applicatie assemblage + componentenbouw )
• Applicatieontwikkeling zal worden teruggebracht van negen maanden naar negen weken en wellicht zelfs naar negen dagen (uiteindelijk, via de principes van ‘ultra-iteratie, zelfs naar 9 uur).
• Dit gebeurt door de toepassing van een methode die bestaat uit een componentsgewijze ontwikkeling onder architectuur in ultra korte ontwikkelcycli ( interactief, incrementeel, iteratief )
• De grens tussen ontwikkeling en onderhoud gaat verdwijnen. We krijgen een continue verrijking van de functionaliteit van de informatiesystemen. Technologie, zoals push technology helpt om dit ook logistiek voor elkaar te krijgen. Reparatie zal geschieden middels diagnose op afstand en het downloaden van de gerepareerde componenten dan wel interfaces.
• We zien bij methoden, technieken en tools voor de systeemontwikkeling een tendens optreden naar een striktere scheiding in "structureren" ( notatie techniek als UML ) en "ontwikkelen".
• Systeemontwikkeling wordt websiteontwikkeling; het netwerk wordt de standaard infrastructuur waarop applicaties gaan draaien
• Applicatieontwikkeling verschuift naar applicatie integratie.
• Expliciete handleidingen gaan verdwijnen : we krijgen intuïtieve gebruiksinterfaces met aanschouwelijke help-faciliteiten.
• Handmatige procedures worden geheel vervangen door workflow en wizards.
• Projectmanagement in zijn huidige vorm gaat verdwijnen. We krijgen een faciliterend management over ultra korte ontwikkelcycli ( inclusief deployment ), steeds gebaseerd op concrete benefit cases.
• In feite impliceert een project dat je een grote ingreep moet doen in de informatievoorziening. Waarom ? Om een achterstand in te halen ?
• Door de opkomst van het Internet ( Intranet ) zien we Web-enabled Cyberteams ontstaan. Vooral minder frequent benodigde specialismen kunnen zo meer efficiënt worden aangewend.
• Kwaliteitszorg en management ten aanzien van de voortgang worden impliciet meegenomen in de ontwikkelcycli.
• We zullen een vernieuwde aandacht zien voor het echte testwerk ( 100% coverage op componenten ), geïntegreerd door de hele ontwikkelcyclus heen, en sterk iteratief uitgevoerd (i.p.v. lineair, aan het eind). Geautomatiseerde tools zijn bij zo’n aanpak van levensbelang.

Statements

• Verantwoorde systeemontwikkeling geschiedt onder architectuur, waarbij de business case leidend is.
• Belangrijk voor het succes van het proces van systeemontwikkeling is het vaststellen van de juist scope. Een hek om de wei !
• Het is belangrijk om alvorens te beginnen met applicatieontwikkeling de infrastructuur zodanig te verrijken dat de applicatie ontwikkeling wordt vereenvoudigd.
• Inzicht groeit iteratief, dit impliceert lerend ontwikkelen. De vinger wordt aan de pols gehouden middels "benefit tracking". Een vorm van incrementeel invoeren is vaak zeer raadzaam opdat de gebruikers de automatiseerders kunnen bijhouden.
• Er is grote behoefte naar methoden, waarbij mensen op de voorgrond staan en techniek naar de achtergrond wordt verwezen.
• Een methode is niet een keurslijf voor de creatieve geest; het dient een ondersteuning te zijn voor werkelijke creativiteit: dus niet bindend, maar richtinggevend.
• Er bestaat geen standaardaanpak voor alle problemen; het is niet juist om altijd vast te houden aan de standaard-deliverables.
• Systeemontwikkeling is geen activiteit die alleen door ontwikkelaars wordt bedreven; dus niet het alleenrecht van automatiseerders, noch de hobby van professionals.
• Het is niet professioneel te streven naar een perfecte oplossing; goed is goed genoeg !
• Het is beslist geen schande om concepten en componenten van een collega te hergebruiken. Het "not invented here"-syndroom past niet bij een professionele wijze van systeemontwikkeling.
• Effectieve teaming geeft een hogere produktiviteitswinst dan methoden, technieken en tools.
• Een over het functionele en technische domein gemeenschappelijke onderliggend modelleringstaal kan het totale ontwikkelproces drastisch versnellen en verbeteren.
• De toekomst is aan de slagvaardige "assembleur". Assembleren van de business functionaliteit in de "front office", assembleren van frameworks in de 'back office".

Oefeningen

• Onderzoek bij uw bedrijf welke ontwikkelstrategieën gebruikt worden.
• Hoe kan de gebruikersparticipatie in uw bedrijf geregeld worden?
• Onderzoek voor uw bedrijf welke vormen van automatisering van de automatisering gebruikt worden.

Vragen

• Noem enkele gedachten / uitgangspunten achter de opbouw van het vijfsporenmodel van de systeemontwikkeling.
• Welke disciplines zijn nodig bij de verschillende trajecten in het vijfsporenmodel?
• Waarom is het van belang dat het ontwikkelen van de handmatige procedures parallel aan het bouwen van het systeem verloopt?
• Schets een alternatief voor de gebruikshandleiding.
• Wat wordt bedoeld met de uitspraak dat bij een evolutionaire ontwikkelstrategie de grens tussen ontwikkeling en onderhoud verdwijnt?
• Wat is de essentie achter (I)CASE?

Definities
 

acceptatietest
Een acceptatietest is het formeel beoordelen en testen van één of meer eindproducten, om te bepalen:

• of deze eindproducten voldoen aan de acceptatiecriteria, zodat de opdrachtgever tot acceptatie van deze eindproducten kan overgaan, en
• of de eindproducten op een verantwoorde wijze in gebruik en exploitatie kunnen worden genomen.

We onderscheiden acceptatietests door verschillende organisaties: gebruikersorganisatie, onderhoudsorganisatie en verwerkingsorganisatie.

applicatieconversie
Applicatieconversie is het aanpassen en overbrengen van een verzameling applicaties met behoud van functionaliteit, van een bestaande omgeving naar een andere omgeving.

gegevensconversie
Gegevensconversie is de omzetting van gegevens van een oud (soms handmatig) informatiesysteem naar de vorm die wordt vereist door het nieuwe informatiesysteem. Deze omzetting behelst niet alleen een wijziging van het technische formaat, maar ook functionele werkzaamheden, zoals schonen, selecteren en aanvullen.

parallelverwerking
Parallelverwerking is een invoeringsstrategie waarbij het nieuwe informatiesysteem het primaire informatiesysteem is. De gegevens worden echter gedurende de proefperiode ook nog met het oude informatiesysteem verwerkt.

proeftuin
Een proeftuin is een nabootsing van een volledig informatiesysteem met handmatige procedures en organisatorische inbedding.

prototype
Een prototype (van een informatiesysteem) is een experimentele, meestal beperkte, versie van het informatiesysteem. Het experiment kan zeer uiteenlopende zaken betreffen. Bijvoorbeeld kan het dienen om de functionaliteit en toepasbaarheid van een gegeven functionele specificatie te demonstreren, en daarmee tot accorderen of aanpassen van die functionele specificatie te komen (IKIWISI-effect). Maar ook om het gedrag en de toepasbaarheid te onderzoeken van het ontwikkelplatform of van onderdelen van de technische infrastructuur. Of om een indruk te krijgen van de snelheid (of andere prestatiekenmerken) van het informatiesysteem. Een prototype is niet noodzakelijkerwijs een volledig informatiesysteem. Het kan zich bijvoorbeeld concentreren op het gebruikersinterface, of op een cruciaal algoritme.
In het algemeen is het doel van het experiment: vermindering van risico.

prototyping
Prototyping is het ontwikkelen van een informatiesysteem via één of meer prototypen.

schaduwdraaien
Schaduwdraaien is een invoeringsstrategie waarbij gedurende een proefperiode het oude en het nieuwe informatiesysteem beide in gebruik zijn.

systeemencyclopedie
Een systeemencyclopedie is een centrale opslagfaciliteit voor alle systeemdocumentatie.

uitgestelde verwerking
Uitgestelde verwerking is een invoeringsstrategie waarin het oude informatiesysteem gedurende de proefperiode nog het primaire informatiesysteem is. De gegevens worden echter achteraf ook in het nieuwe informatiesysteem verwerkt.

Literatuurverwijzingen

• Rijsenbrij, D.B.B. ( 1993 ), Basisconcepten in systeemontwikkeling : Informatie 35 nr. 11 pp. 664-678
• Rijsenbrij D.B.B., Vlasblom G. ( 1992 ), Resultaatgerichte systeemontwikkeling : Informatie 34 nr. 2 pp. 81-93.
• Delen G.P.A.J., Rijsenbrij D.B.B. ( 1987 ), Vierde generatie systeemontwikkeling : Informatie 29 nr. 5 pp. 422-428.
• Vlasblom G., Rijsenbrij D.B.B. ( 1994 ), Flexibilisering van de methodologie van systeemontwikkeling : Informatie 36 nr. 3 pp.158-167.

Vlasblom G, Rijsenbrij D.B.B. and Glastra M. ( 1995 ), Flexibilization of the methodology of system development : Information and Software Technolgy Volume 37 number 11 pp. 595-607.

• Fokkinga L., Glastra M.H., Huizinga H. ( 1996 ), LAD Het lineair ontwikkelen van informatiesystemen, Academic Service.
• Tolido R.J.H. ( 1998 ) : IAD Het evolutionair ontwikkelen van informatiesystemen, Academic Service.
• Krugten-Elgersma P., Hoogenboom M. ( 1998 ) : ITC Gids Iterative Transformation Cycles; een iteratieve ontwikkelaanpak, Academic Service.