B3: Systematisch bouwen van eenvoudige informatiesystemen SDM-fase 4: Realisatie

Transcriptie

1 VI SDM - FASE 4 REALISATIE VI.1 Inleiding Zoals reeds besproken onderkent de in Nederland veel gebruikte procesbeheersingsmethode SDM II (System Development Methodology, versie II) bij de bouw van informatiesystemen de volgende ontwikkelingsfasen: fase 0 informatieplanning fase 1 definitiestudie fase 2 basisontwerp fase 3 detailontwerp ==> fase 4 realisatie fase 5 invoering fase 6 gebruik en beheer De vijfde fase van SDM, fase 4, realisatie, bestaat uit een aantal activiteiten die als volgt samenhangen: 4.1 uitgangspunten plan van aanpak 4.2 creëer database en testomgeving bepaal programmastructuur vervaardig en test programmatuur maak systeem produktierijp 4.6 maak en test opleidingen 4.7 voer systeemtest uit 4.8 voltooi documentatie 4.9 voer acceptatietest uit 4.10 rapport realisatie Met de gearceerde blokken in het schema worden de zogenaamde mijlpaalproducten aangegeven. NIII School voor Informatica R.1 KU-Nijmegen

2 Toelichting bij SDM-fase 4 Het doel van de realisatiefase is het ontworpen informatiesysteem gereed te maken voor invoering. In deze fase worden de onderdelen uit het voltooide detailontwerp, voor zover het geautomatiseerde delen van het informatiesysteem betreft, omgezet in werkende programma's. Vóórdat kan worden begonnen met programmeren, moet eerst door de ontwerpers worden vastgelegd hoe de interne structuur van de verschillende programma-onderdelen moet zijn. Pas daarna kan geprogrammeerd worden. De werking van de programma-onderdelen en het totale programma wordt getest en gebruikersdocumentatie vervaardigd. Voor de handmatige delen van het informatiesysteem worden voorschriften vervaardigd. De gegevensbank wordt aangemaakt en gevuld met de benodigde (test)gegevens. Het testen is een belangrijke activiteit in deze fase. Nagegaan moet worden of de onderdelen van het informatiesysteem - zowel de geautomatiseerde als de handmatige - naar behoren functioneren. Er zijn een systeemtest en een acceptatietest. De systeemtest is gericht op het ontdekken en herstellen van fouten. De acceptatietest moet (vooral voor de opdrachtgever) duidelijk maken of het ontwikkelde product daadwerkelijk de verwachtingen waarmaakt en aan de gestelde eisen voldoet. Door het testen kunnen niet alleen fouten in de programmatuur worden ontdekt, maar ook overgebleven foutjes en/of omissies in het Detailontwerp. Ofschoon in het algemeen geldt, dat de realisatie het ontwerp niet essentieel meer mag veranderen, kan het nu toch nodig blijken, dat vanwege dergelijke foutjes/omissies in het ontwerp dat laatste alsnog aangepast moet worden. Als zich zoiets voordoet, ga dan niet sjoemelen, maar vermeld expliciet welke wijzigingen/aanpassingen er toch nog in het oorspronkelijke ontwerp moesten worden aangebracht om het uiteindelijke systeem tot in details te laten voldoen aan de systeemeisen. Gezien het prijskaartje dat aan dergelijke aanpassingen hangt, zal voor zulke last minute-veranderingen in het ontwerp daarover met de opdrachtgever moeten worden overlegd. Als die benodigde veranderingen àl te groot (maar niet essentieel) zijn, dan kan er voor worden gekozen, om het systeem voorlopig te implementeren zoals het (gebrekkig) ontworpen is en om via een apart vervolgproject de benodigde veranderingen pas achteraf aan te brengen (als een soort versnelde grote onderhoudsbeurt). VI.2 Opsomming van de Realisatiefase-activiteiten We geven hier eerst weer een volledige opsomming van alle (10) in deze SDM-fase te verrichten activiteiten en bespreken daarna weer uitvoeriger niet alleen de bedoeling van die afzonderlijke activiteiten, maar ook een manier waarop ze uitgevoerd kunnen worden. 4.1 Leg uitgangspunten vast en stel plan van aanpak op 4.2 Creëer database en testomgeving 4.3 Bepaal programmastructuur 4.4 Vervaardig en test programmatuur 4.5 Maak systeem productierijp 4.6 Vervaardig en test opleidingen 4.7 Voer systeemtest uit 4.8 Voltooi documentatie 4.9 Voer acceptatietest uit 4.10 Rapporteer over realisatie Ook geven we hier weer een overzicht van de diverse bijlagen bij dit hoofdstuk over Realisatie: R-a) Het maken van de testomgeving en het uitvoeren van het testproces R-b) Rapport Realisatie Factureringsafdeling (uittreksel) R-c) De systeemdocumentatie In de projectfase: lever (uiterlijk na de eerste week) het bij activiteit 4.3 gemaakte overzicht van de per basisfunctie af te dwingen beperkingsregels (ook) in bij de projectleiding en valideer!! NIII School voor Informatica R.2 KU-Nijmegen

3 VI.3 Beschrijving van de afzonderlijke activiteiten van de realisatie-fase Activiteit 4.1 Leg uitgangspunten vast en stel plan van aanpak op Als uitgangspunt voor de realisatie dienen de producten uit het detailontwerp. In een plan van aanpak wordt - rekening houdend met het projectplan uit het basisontwerp - vastgelegd hoe de realisatiefase zal worden doorlopen: welke activiteiten zullen worden uitgevoerd, welke producten gemaakt zullen worden, welke momenten van afstemming en besluitvorming er zullen zijn en binnen welke tijd en onder welke voorwaarden een en ander zal worden gerealiseerd en door wie. Activiteit 4.2 Creëer database en testomgeving Het doel van deze activiteit is het ontwikkelen van een omgeving die gebruikt kan worden bij het vervaardigen en testen (van delen) van het informatiesysteem. Het ontwerp van de opslagstructuur heb je bij activiteit 3.9 van de Detailontwerp-fase gemaakt. Zorg ervoor dat nu niet alleen de ontworpen gegevenstabelstructuren, maar ook de ontworpen indexen correct worden geïmplementeerd. Om onderdelen van het te vervaardigen informatiesysteem te kunnen uittesten moet deze database van testgegevens worden voorzien. Vaak kan dat door selectie uit een bestaande gegevensbank. Let er in ieder geval uiterst consciëntieus op, dat de opvulling van de testdatabase voldoet aan alle beperkingsregels zoals je die in activiteit 3.4 hebt bepaald en in het conceptueel schema (NIAM-gegevensmodel) hebt geplaatst. Als je gegevens in strijd zijn met dat conceptueel schema, zou je wel eens onzin kunnen gaan zitten testen! Omdat je er welhaast zeker van kunt zijn dat er tijdens de testfase foutieve gegevens in de testdatabase terechtkomen, is het handig om van de (eerst nog) correcte database een back up te maken, zodat je bij vervuiling van de testdatabase die weer gemakkelijk kunt vullen met de correcte gegevens uit de back up. Maak liefst gebruik van hulpmiddelen om die correcte testomgeving in stand te houden (zoals een batch file-tje of een hulpprogrammaatje). In de praktijk kunnen hier allerlei tools voor het analyseren van het gedrag van het in ontwikkeling zijnde systeem worden gebruikt (b.v. voor het meten van geheugenbeslag, processor- en netwerkbelasting in multi-user en/of multi-tasking situaties). Ook eventueel benodigde apparatuur wordt hierbij in beschouwing genomen. N.B. Eventueel kun je in de B3-projectfase het vullen van de gegevensbank even uitstellen tot activiteit 4.4 om dan tegelijkertijd de toevoegfuncties te kunnen testen. Zie ook bijlage R-a. Activiteit 4.3 Bepaal programmastructuur Tijdens activiteit 3.11 van de Detailontwerpfase is vastgelegd hoe de totaalstructuur van de programmatuur zal zijn: hoe de verhouding tussen de verschillende modulen is. We richten ons nu, bij deze activiteit, op de interne structuur van de afzonderlijke modules. Het in werking stellen van een actie door een menukeuze betreft in de meeste gevallen de aanroep van zo'n afzonderlijke module (i.c. een basisfunctie) die gegevens moet toevoegen, verwijderen, wijzigen of als informatie moet opleveren. De programmaspecificaties die hiervoor in de vorige fase zijn vervaardigd moeten volledig begrepen (kunnen) worden, voordat aan het uiteindelijke coderen mag worden begonnen. Het bepalen van die interne structuur van het programma (onderdeel) is een uitstekend middel om dat te bereiken. De manier waarop deze activiteit precies wordt uitgevoerd, hangt af van het te gebruiken Database Management Systeem. In ons geval kunnen we ons hier beperken tot een - door de ontwerpers - per basisfunctie vastleggen van de binnen die basisfunctie af te dwingen beperkingsregels (en de volgorde waarin ze moeten worden gecontroleerd). De ontwerpers hebben zich immers tijdens de ontwerpfase ingeleefd in die beperkingsregels; de beste manier om de door hen daarover opgedane ervaring aan de programmeurs over te brengen, is een expliciet (schriftelijk) formuleren van die beperkingsregels en die formulering doorspreken met de programmeurs. Ook binnen een basisfunctie te gebruiken SQL-opdrachten en eventuele sjablonen met betrekking tot toe te passen herhalings- en keuzeconstructies moeten hier door de ontwerpers worden vastgelegd. NIII School voor Informatica R.3 KU-Nijmegen

4 Als voorbeeld hierbij geven we een mogelijke uitwerking uit het sportverenigingssysteem van de basisfunctie VERWIJDER (spelergegevens): Hou bij implementatie rekening met: - totale rol op in te tikken speler-identificatie - speler moet bestaan (voorkomen in systeem) - speler mag geen team-aanvoerder zijn - speler mag niet enige trainer van een team zijn - speler mag geen openstaande boetes hebben Als dit alles okay, dan: spelergegevens echt verwijderen anders: bijbehorende foutboodschappen genereren Pas als deze interne structuur van de afzonderlijke modules is bepaald, mag worden overgegaan tot de volgende activiteit (4.4) waarin de implementatie en het testen daadwerkelijk plaatsvindt. Uiteraard hoeven de programmeurs hier niet zitten te wachten totdat eerst alle basisfuncties op deze manier zijn uitgewerkt; als de interne structuur van een eerste module is vastgelegd en met hen doorgesproken kunnen de programmeurs uiteraard al met de implementatie van die eerste module beginnen en ondertussen gaan de ontwerpers met volgende modules verder. 'Bij nader inzien' kan hier eventueel tot een uitbreiding/aanpassing van het testplan worden besloten. Voor zover nodig worden bij deze activiteit de programmaspecificaties uit het detailontwerp nog aangevuld, bijvoorbeeld omdat de gewenste efficiency van het uiteindelijk te realiseren systeem een aangepaste opzet nodig maakt, of als in de specificaties van het detailontwerp constructies worden gebruikt die het te gebruiken programmeersysteem niet ondersteunt. Zie als voorbeeld-uitwerking in bijlage R-b het uittreksel uit het rapport realisatie van de factureringsafdeling. Activiteit 4.4 Vervaardig en test programmatuur Het uiteindelijke doel van deze activiteit is, dat men kan beschikken over werkende programmatuur. De programmaspecificaties moeten niet alleen uitgeprogrammeerd worden in de gekozen programmeertaal maar ook getest. De geprogrammeerde (basis)functies moeten voldoen aan de detailbeschrijvingen die in eerdere fasen gemaakt zijn. Een programmeur mag niet af wijken van de specificaties van het detailontwerp. De ontwerper is de baas en niet de programmeur. Indien nu duidelijke fouten in het ontwerp naar boven komen, dient overleg met de ontwerper(s) plaats te vinden. Al lange tijd is de ontwikkeling gaande om van steeds 'hogere' programmeertalen en verder ontwikkelde tools en programma-generatoren gebruik te maken. Men hoopt uiteindelijk zover te komen dat systemen gegenereerd kunnen worden op basis van functionele specificaties. Maar zover zijn we nog lang niet. Denk er bij het programmeren aan, dat ca. 70% van alle programmeertijd wordt besteed aan 'onderhoud' (alsnog ontdekte fouten verbeteren en aanpassen van de programmatuur aan veranderende informatiewensen). Zorg er daarom voor, dat je programmacode leesbaar is; gebruik geen onnodig ingewikkelde besturingsconstructie (dus geen driedubbele herhalingen met vijfvoudig diep geneste keuze-constructies, waar via 'Exit' en of 'Goto' in heen en weer gesprongen wordt). Voeg zo mogelijk verhelderende commentaarregels toe. Het testen van de programmatuur vereist normaliter een veelvoud van de tijd die nodig is om de programmacode te schrijven. Dat testen kan vaak beter door een andere gedaan worden dan door degene die het betreffende onderdeel vervaardigd heeft. Geconstateerde gebreken worden uiteraard verholpen. Bij een top down testaanpak worden onderdelen pas getest als de bovenliggende lagen voltooid zijn. Onderliggende delen die nog niet gereed zijn, worden vervangen door zogenaamde dummies (dat kan desnoods een miniem programmaatje zijn, dat alleen meldt dat dat onderdeel nog niet klaar is). Met een bottom up aanpak worden onderdelen pas getest als de onderliggende lagen gereed zijn. Bovenliggende onderdelen worden dan vervangen door zogenaamde drivers of testharnassen. Ook zijn combinaties van de top down en de bottom up aanpak mogelijk. Het in de detailontwerpfase opgestelde testplan kan een goede leidraad voor deze deeltesten zijn. Zie ook bijlage R-a over het maken van de testomgeving en het uitvoeren van het testproces. NIII School voor Informatica R.4 KU-Nijmegen

5 Activiteit 4.5 Maak systeem productierijp Geprogrammeerde onderdelen moeten worden samengevoegd in een groter geheel dat bedrijfsgereed is. Zo zal de programmatuur op de uiteindelijk te gebruiken computer "gezet" moeten worden en zullen de benodigde (test)gegevensbestanden aanwezig moeten zijn. Ook moeten de benodigde organisatorische maatregelen worden getroffen. Een bruikbare versie van alle documentatie en van de gebruikershandleiding moet beschikbaar zijn. Het systeem moet als het ware ' testgereed' worden gemaakt. Activiteit 4.6 Vervaardig en test opleidingen Gebruikers, productie- en onderhoudspersoneel moeten worden opgeleid om het nieuwe systeem snel en efficiënt te kunnen gebruiken. De leerdoelen moeten vooraf duidelijk worden gespecificeerd op grond van wat cursisten later op eigen kracht moeten kunnen uitvoeren. Het cursusmateriaal moet worden vervaardigd en uitgetest. Activiteit 4.7 Voer systeemtest uit De bedrijfsklare onderdelen van het informatiesysteem zijn samengevoegd en worden in hun geheel - als systeem - getest op fouten en onvolkomenheden. Geconstateerde gebreken worden verholpen. De resultaten van deze activiteit zijn een correct functionerend systeem met het bijbehorende testrapport. Zie ook bijlage R-a over het testen. Activiteit 4.8 Voltooi documentatie Het informatiesysteem is nu in zijn geheel bedrijfsklaar en ' af'. Dit betekent dat de laatste hand kan worden gelegd aan de documentatie. Er is tijdens de verschillende activiteiten al de nodige documentatie vervaardigd, maar nu moet deze worden bijgewerkt op doorgevoerde wijzigingen. Zie ook bijlage R-c over systeemdocumentatie. Activiteit 4.9 Voer acceptatietest uit De acceptatietest is het moment van de waarheid. De waarde van het systeem wordt bepaald vanuit de optiek van de eindgebruiker. De acceptatietest kan worden beschouwd als een black box -test; de gebruiker is alleen geïnteresseerd in òf het systeem de gestelde doelen bereikt en niet in hoe het dat doet. In het functionele deel van het detailontwerp is de acceptatietest gespecificeerd. Deze specificatie wordt nu uitgevoerd op het op te leveren informatiesysteem. In een evaluatieverslag worden de resultaten van de acceptatietest beschreven. Indien de resultaten acceptabel zijn, maar er toch wensen bestaan ter vervolmaking en verfijning van het systeem, is het verstandig het systeem toch ongewijzigd in te voeren. Na een periode van gebruik kunnen de geconstateerde schoonheidsfoutjes en andere kleine tekortkomingen beter worden beoordeeld en worden verholpen. De resultaten van de acceptatietest worden vastgelegd en bewaard; na wijzigingen in het systeem wordt dezelfde acceptatietest weer op het gewijzigde systeem uitgevoerd en kunnen de resultaten van voor en na de wijziging met elkaar vergeleken worden. Activiteit 4.10 Rapporteer over realisatie Het rapport over de realisatiefase wordt hier in de praktijk geschreven. Ons project houdt op met activiteit 4.9 (de acceptatietest). Het rapport wordt niet meer geschreven (wel moet uiterlijk 1 week na de start van de realisatie-fase het te maken overzicht van de per basisfunctie af te dwingen beperkingsregels worden ingeleverd!). NIII School voor Informatica R.5 KU-Nijmegen