B3: Systematisch bouwen van informatiesystemen SDM-fase 3: Detailontwerp

Transcriptie

1 V SDM - FASE 3 DETAILONTWERP V.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 vierde fase van SDM, fase 3. detailontwerp, bestaat uit een aantal activiteiten die als volgt samenhangen: 3.1 uitganspunten plan van aanpak FUNCTIONEEL D EEL rapport toekomstige organisatie opstellen 3.3 functies detailleren 3.4 gegevensstructuur detailleren 3.5 ontwikkel mens/machine interfaces 3.6 opstellen rapport functioneel ontwerp 3.7 valideer rapport functioneel ontwerp TECHNISCH DEE L Specificeer procedures/formuli eren 3.9 Specificeer beeldscherm/lijsti ndeling 3.10 Ontwerp opslagstructuur 3.11 Specificeer programmatuur valideer technisch ontwerp 3.13 maak gedetailleerd testplan maak plan v realisatie en inv oering 3.15 rapporteer over detailontwerp Met de gearceerde blokken in het schema zijn weer de zogenaamde mijlpaalproducten aangegeven. DO.1

2 Toelichting bij SDM-fase 3 De fase Detailontwerp is de eerste fase, waarin de ontwikkeling van een in het Basisontwerp bepaald deelsysteem begint. Het doel van de huidige fase 3 is het vervaardigen van de gedetailleerde specificatie van zo'n deelsysteem, waarin zowel de functionele als de technische aspecten beschreven zijn, inclusief de organisatorische consequenties. Binnen het Detailontwerp zijn twee etappes te onderkennen; in de eerste etappe staan de functionele aspecten centraal en in de tweede etappe de technische aspecten. In beide etappes moet duidelijk worden hoe de verschillende functies vervuld zullen worden. In die eerste, functionele etappe moet vooral in overleg met de toekomstige gebruikers gedetailleerd bepaald worden hoe het systeem zich moet gedragen en hoe er mee samengewerkt moet worden. Hoe moet het samenspel tussen gebruiker en systeem zijn, zodat het werkproces van de gebruiker optimaal kan worden ondersteund en uitgevoerd? De functionele aspecten hebben betrekking op: - de te verrichten bewerkingen (en de volgorde ervan); - de te produceren uitvoer; - de te verwerken invoer; - de te bewaren gegevensverzameling; en: - de gewenste/vereiste prestatie. Belangrijk is de betrokkenheid van de gebruikers bij het detailleren van de functies en het vaststellen van de gewenste kwaliteit van de te vervaardigen producten. Daarna worden de technische aspecten (met afnemende gebruikersparticipatie en toenemende invloed van de 'technische mensen') gedetailleerd bepaald; er wordt een technische uitwerking gegeven aan het functionele ontwerp uit het functionele deel van de detailontwerp-fase. Bijvoorbeeld wordt in het technische deel de fysieke opslagstructuur van de gegevenstabellen vastgelegd (activiteit 3.10). De toekomstige gebruikers van het informatiesysteem hebben van deze interne (technische) tabelstructuur geen weet; zij hebben alleen te maken met het conceptuele gegevensmodel uit het functionele deel van het ontwerp. In dit deel van het detailontwerp wordt ook de wijze van testen gedetailleerd uitgewerkt in een acceptatietestplan. De functies van het gerealiseerde informatiesysteem zullen conform dit plan worden getest. De technische aspecten hebben o.a. betrekking op: - handmatige procedures; - beeldschermindelingen; - lijstindelingen; - programma-specificatie en: - fysieke structuur van de database. N.B. Met het hoe langer hoe meer opkomen van prototyping (met grafische user interface en screen designers) lijkt het niet alleen handig, maar vaak ook efficiënt om activiteit 3.3 (detailleren van het gedrag van de functies naar de gebruiker toe) te combineren met activiteit 3.9 (specificeer beeldscherm/lijstindeling). Het vereiste vastleggen van de door de gebruiker uit te voeren bewerkingen (en hun volgorde) kan deels hand in hand gaan met het prototypen/vastleggen van de benodigde grafische user interface. Uiteraard moet dit dan voorafgegaan worden door activiteit 3.5, waarin de criteria vastgelegd worden, waaraan de beeldscherm- (en lijst-) indelingen zullen moeten voldoen. Het detailontwerp is het laatste product waarin nog wijzigingen kunnen worden aangebracht zonder dat dit direct gepaard gaat met hoge kosten of ernstige vertragingen. Wel moet je dan heel voorzichtig zijn met wijzigingen die consequenties hebben in de relaties met andere deelprojecten. N.B. In de volgende SDM-fase (realisatie) volgt pas de omzetting naar programma's of handmatige procedures. DO.2

3 V.2 Opsomming van de Detailontwerp-activiteiten We geven hier eerst weer een volledige opsomming van alle (15) 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. 3.1 Leg uitgangspunten vast en stel plan van aanpak op 3.2 Bepaal detailstructuur toekomstige organisatie 3.3 Detailleer functiestructuur 3.4 Detailleer gegevensstructuur 3.5 Specificeer mens/machine-interfaces 3.6 Vervaardig functioneel ontwerprapport 3.7 Valideer functioneel ontwerprapport 3.8 Specificeer procedures en formulieren 3.9 Specificeer beeldscherm- en lijstindelingen 3.10 Ontwerp opslagstructuur 3.11 Specificeer programmatuur 3.12 Valideer technisch ontwerp 3.13 Vervaardig gedetailleerd testplan 3.14 Vervaardig plan voor realisatie en invoering 3.15 Rapporteer over Detailontwerp. Ook geven we hier weer een overzicht van de diverse bijlagen bij dit hoofdstuk over Detailontwerp: Voor gebruik vanaf oefenfase: DO-a) Detailleer functiestructuur via Input-Process-Output-benadering DO-b) Basisgegevensstructuur detailleren: beperkingsregels DO-c) Basisgegevensstructuur detailleren: identificatie /gegevens DO-d) Detailontwerp opslagstructuur maken (bij activiteit 3.10) DO-e) Rapport Detailontwerp Factureringsafdeling DO-f) Richtlijnen voor het ontwerpen van een gebruikersinterface Met betrekking tot de oefenopdracht 3 zèlf: DO-g) Goede raad voor het maken van oefenopdracht 3 (van week 5) DO-h) Oefenopdracht 3: Zakboekinformatiesysteem Fase 3 Voor gebruik in projectfase: DO-i) Rapport Detailontwerp Secretariaat sportvereniging DO-j) Functioneel testplan opstellen V.3 Activiteiten voor het detailontwerp tijdens de oefenfase: BEPERKING + OMGOOIEN VOLGORDE! In het oefendeel van de cursus beperken we ons tot het uitvoeren van een beperkt aantal activiteiten uit deze fase en doen dat tevens in een aangepaste volgorde: Uit Functioneel deel : - GEGEVENSSTRUCTUUR DETAILLEREN ACTIVITEIT 3.4 en vervolgens: Uit Technisch deel : - DETAILONTWERP OPSLAGSTRUCTUUR MAKEN ACTIVITEIT 3.10 en daarna weer uit Functioneel deel : - (criteria) MENS/MACHINE-INTERFACES DETAILLEREN ACTIVITEIT SPECIFICEER BEELDSCHERM- EN LIJSTINDELINGEN ACTIVITEIT FUNCTIES DETAILLEREN ACTIVITEIT 3.3 N.B. Uit efficiency-overwegingen combineren we activiteiten 3.3 en 3.9.! - Uiteraard moet de ook de plannings- (3.1) en evaluatie-activiteit (3.15) uitvoeren. DO.3

4 V.4 Beschrijving van de afzonderlijke activiteiten van de Detailontwerp-fase Activiteit 3.1 Leg uitgangspunten vast en stel plan van aanpak op Als belangrijkste uitgangspunt voor het detailontwerp dienen over het algemeen de producten uit het basisontwerp. In een plan van aanpak wordt - rekening houdend met het projectplan uit het basisontwerp - vastgelegd hoe de fase detailontwerp zal worden doorlopen: welke activiteiten worden uitgevoerd, welke producten gemaakt worden, welke momenten van afstemming en besluitvorming er zijn en binnen welke tijd en onder welke voorwaarden een en ander zal worden gerealiseerd. Voor dit plan van aanpak is speciaal van belang dat de afzonderlijke onderdelen van het ontwerp door verschillende teams van personen worden uitgewerkt; dat stelt speciale eisen aan de planning en de bewaking van de werkzaamheden. Detailontwerp: FUNCTIONEEL DEEL Activiteit 3.2 Bepaal detailstructuur toekomstige organisatie Uitgaande van de resultaten uit activiteit 2.2 (aangeven van de toekomstige werkomgeving) uit de SDM-fase basisontwerp, wordt hier de detailstructuur van de toekomstige organisatie vastgelegd. Organisatiestructuur, verantwoordelijkheden, rapportering en bestuurlijke aspecten moeten tot in detail duidelijk zijn. In deze detaillering krijgen vooral de veranderingen aandacht die tengevolge van de invoering van het informatiesysteem ten opzichte van de bestaande situatie in de organisatie zullen optreden. Daarbij wordt aangegeven hoe die veranderingen (stapsgewijs) zullen worden gerealiseerd (een plan voor omschakeling). In deze activiteit wordt dus de basis gelegd voor een soepel verlopende invoering (fase 5) van het informatiesysteem. Alle mogelijke knelpunten in de verandering van de organisatie van de bestaande situatie naar de nieuwe (geautomatiseerde) situatie moeten hier in kaart zijn gebracht en er moet in detail zijn vastgelegd hoe deze knelpunten zullen worden opgeheven. De bevindingen worden neergelegd in een rapport toekomstige organisatie dat aan de opdrachtgever wordt aangeboden. Voor een concrete uitwerking verwijzen we naar het 'rapport toekomstige organisatie' voor het secretariaat van de ons bekende sportvereniging, dat als bijlage DO-h aan dit hoofdstuk is toegevoegd. Het systeemconcept dat in de fasen definitiestudie en basisontwerp reeds een invulling heeft gekregen, wordt nu nader gedetailleerd naar functies (activiteit 3.3), gegevens (activiteit 3.4) en interfaces (activiteit 3.5). Activiteit 3.3 Detailleer functiestructuur N.B. Zoals reeds eerder gesteld, is het niet alleen handig, maar vaak ook efficiënt om deze activiteit 3.3 te combineren met activiteit 3.9 (specificeer beeldscherm/lijstindeling); nadat activiteit 3.5 is gedaan. En als je eerst activiteiten 3.4 ook 3.10 doet en een database-schema bepaalt en al implementeert, dan kun je waarschijnlijk daarna via tools/wizards allerlei gebruikersschermen gemakkelijk aanmaken. In de eerdere fasen van SDM stond steeds het wat van de functies (wat kan het informatiesysteem) centraal; in deze fase detailontwerp zullen we nu ook een duidelijke invulling gaan geven aan hoe de functies van het informatiesysteem naar de gebruiker toe vervuld zullen worden. De basisfuncties die in het basisontwerp zijn aangegeven met wat de functie moet doen, worden nader gedetailleerd naar hoe de functie dat moet doen. Wij proberen de functies tot zover te detailleren dat elke gedetailleerde actie in het algoritme van de functie voor de gebruiker duidelijk is. Enerzijds betekent dit dat aan de gebruiker de samenhang tussen de grondstofgegevens en de door de betreffende actie geproduceerde productgegevens duidelijk moet zijn. DO.4

5 Anderzijds proberen we het hoe van de functies (hoe deze in elkaar zitten) duidelijk te maken door te beschrijven hoe de gebruikersdialoog met de functie verloopt. Goede specificaties zijn: - ondubbelzinnig : ze zijn slechts op één manier uit te leggen; - volledig: ze beschrijven alle eisen waaraan voldaan moet worden: functionaliteit, prestatie, beveiliging, etc. - verifieerbaar: het moet later mogelijk zijn te bepalen of het gewenste resultaat is bereikt; - consistent: de onderdelen mogen op geen enkele wijze met elkaar in tegenspraak zijn; - onderhoudbaar: het onderhoud is eenvoudiger wanneer alles slechts éénmaal is vastgelegd. Geprobeerd wordt de detailbeschrijving van de functies te doen op een voor de toekomstige gebruiker van het informatiesysteem begrijpelijke wijze zodat die gebruiker het detailontwerp kan begrijpen en daarop kan reageren. Realiseer je goed dat het hoe op gebruikersniveau moet worden beschreven en geen technische details mag bevatten. Het conceptuele model van de werkelijkheid van de gebruiker, zoals dat vastligt in informatiestructuurdiagrammen, speelt in deze beschrijving uiteraard een belangrijke rol. De uitwerking van het hoe van de functies van het informatiesysteem betreft vooral de algoritmische uitwerking van hoe een basisfunctie van het informatiesysteem gestalte zal krijgen. Ook een algoritmische uitwerking van de keuzestructuur (de basisdialoog / menu-functies) binnen het informatiesysteem, moet hier gemaakt worden. De bedoelde algoritmische uitwerking wordt bepaald door drie dingen: - wat moet de betreffende basisfunctie van het informatiesysteem doen? dit is bekend uit het basisontwerp - welke beperkingen liggen er op de vorm van de gegevens? dit komt ook terug in activiteit 3.4 van het detailontwerp - wat voor dialoog met de gebruikers wordt er gewenst? dit komt ook terug in activiteiten 3.5 en 3.9 van het detailontwerp Gezamenlijk belichamen deze drie elementen de randvoorwaarden voor de nadere uitwerking van het hoe van een basisfunctie. Wanneer de algoritmische uitwerking van dat hoe bekend is, kan ook de gedetailleerde uitwerking (interface) van de dialoog tussen basisfunctie en gebruiker gemaakt worden (activiteiten 3.5 en 3.9). N.B. Nogmaals: uit efficiency-overwegingen zullen wij deze activiteiten combineren! De 'wortel' van het informatiesysteem, de hoofdfuncties en de functies worden algoritmisch uitgewerkt; daarbij zijn zowel de invoer- als de informatie-, dialoog- als menu-schermen van belang. Wij zullen in deze cursus voor het nader detailleren van de basisfuncties een aanpak gebruiken die gebaseerd is op een Input-Process-Output-benadering. Aan de hand van (een prototype van) een user interface bespreken we met de gebruiker hoe zo n user interface bij verschillende soorten invoer zicht moet gedragen en dus bijvoorbeeld welke uitvoer (productgegevens) de functie produceert. Bij dat gewenste gedrag geven we een algoritmische beschrijving van het hoe van de functie, waarbij onder meer duidelijk gewenste keuzes en/of herhalingen worden vastgesteld. In de functies worden door de gebruiker ingetikte gegevens altijd meteen gecontroleerd op vorm; bij vormfouten wordt daarvan melding gemaakt en wordt een herkansing geboden. Interacties met de gegevensbank kunnen slagen (waarvan aan de gebruiker melding wordt gemaakt) of falen (ook daarvan wordt aan de gebruiker melding gemaakt). In geval van falen wordt een herkansing geboden. Hoe precies de interacties met de gegevensbank: selecteer, voeg toe, verwijder en muteer, gestalte krijgen komt in de realisatiefase aan bod. Dan zullen alle bij die interactie met de gegevensbank in aanmerking komende beperkingsregels worden gecontroleerd op geldigheid. Het product van activiteit 3.3 zal 'in het echt' ook prestatie- en beveiligingseisen bevatten. Voor een verdere beschrijving van de Input-Process-Output-benadering en toepassingen ervan, verwijzen we naar respectievelijk de bijlage DO-a over deze techniek en anderzijds de voorbeeld Detailontwerp-rapporten. Activiteit 3.4 Detailleer gegevensstructuur In de SDM-fase Definitiestudie zijn in informatie-structuurdiagrammen de objecten en de relaties tussen deze objecten die in de werkelijkheid van het informatiesysteem een rol spelen, vastgelegd. In de SDM-fase DO.5

6 Basisontwerp is de uniciteit (een 'aantallenregel') van de rollen die de objecten in de relaties spelen, nagegaan en in de informatie-structuurdiagrammen vastgelegd. In deze detailontwerp-activiteit wordt nu het beeld van de werkelijkheid waarin ons informatiesysteem zal functioneren, nader gedetailleerd. Daartoe gaan we na aan welke beperkingen de objecten en de rollen die deze objecten in de werkelijkheid spelen, onderworpen zijn. We zeggen dat voor de objecten en hun rollen beperkingsregels gelden. Eén soort beperkingsregel kennen we al; dat is de uniciteitsregel (aantallenregel) die bepaalde objecten in bepaalde rollen beperkingen oplegt. Beperkingsregels voor objecten en relaties tussen objecten kunnen van velerlei aard zijn. Bijvoorbeeld: - het geboortegewicht van een baby ligt altijd onder de 4500 gram - het aantal kaarsen in een bestelling is altijd een veelvoud van 12 - een speler kan lid zijn van meerdere verenigingen - een team heeft maar één speler als aanvoerder - ieder team moet een speler als aanvoerder hebben. Al deze regels betekenen beperkingen op de eigenschappen van de objecten of de relaties tussen de objecten. Daarom noemen we deze regels ook wel beperkingsregels. Beperkingsregels zijn er in meerdere soorten. Een paar voorbeelden van soorten beperkingsregels zijn: waarderegels (dat zijn regels die iets zeggen over de waarde die een object, bijvoorbeeld dat geboortegewicht van een baby, kan hebben) en aantallenregels (die hiervoor iets zeggen over spelers en over verenigingen). Dit wordt dan het derde onderdeel van onze ORM/NIAM-informatieanalyse. We doen dat in een aantal stappen: STAP 1 Totaliteitsregels voor afzonderlijke rollen STAP 2 Aantallenregels voor afzonderlijke rollen (vervolg) STAP 3 Waarderegels voor afzonderlijke rollen STAP 4 Totaliteits- en Aantallen-regels (voor combinaties van rollen) STAP 5 Afleidbaarheidsregels STAP 6 Gelijkheids-, Uitsluitings- en Deelverzamelingsregels (combinaties van rollen) STAP 7 Overgangsregels STAP 8 Overige beperkingsregels We zullen al deze beperkingsregels zoveel mogelijk grafisch in ons ORM/NIAM-informatie-structuurdiagram gaan aanbrengen. Zie voor een nadere aanpak van dit derde onderdeel van onze ORM/NIAMinformatieanalyse bijlage DO-b bij dit hoofdstuk. Omdat we in de richting van een (werkend) informatiesysteem uitgaan, wordt het nu tijd om voor zover dat nog niet gebeurd is, de overstap van de 'abstracte objecttypen' - waar we tot nu toe in onze informatieanalyse mee hebben gewerkt - naar gegevens (namen, teksten, getallen e.d.) te gaan maken. Daarvoor moeten we ervoor zorgen dat identificatie van inderdaad alle objecten plaatsvindt. We zijn hier al in de vorige fase (bij fase 2: Basisontwerp) ruw weg mee aan de slag geweest; we gaan hier in deze fase nog een aantal andere mogelijkheden erbij betrekken. Identificatie kan plaatsvinden via: - een enkel al in het beschouwde UoD gehanteerd gegeven [zoals klantnummer voor Klant, hetgeen we bij onze ORMexpressies al aangebracht hebben via Klant ( klantnummer ) ]; - een combinatie van gegevens/objecten (in ORM-taal: entiteiten en/of value-typen); of: - een speciaal geïntroduceerd gegeven (bijvoorbeeld een code). Zie voor een aanpak van deze identificatie van objecten de bijlage DO-c bij dit hoofdstuk. Tot slot moeten - in samenspraak met de gebruikers - hier ook nog van alle gegevens in detail een aantal bekende eigenschappen worden vastgelegd. Dit zullen minimaal bijvoorbeeld de veldlengte en het datatype zijn, maar vaak ook exacte beschrijvingen van wat dat gegevenssoort precies voorstelt en welke beperkingsregels en beveiligings- en privacy-voorwaarden ervoor gelden (werk voor een data-manager...). Zie voor een verdere uitwerking hiervan de voorbeeldrapporten die als bijlagen bij dit hoofdstuk aanwezig zijn. In de vorige fase (Basisontwerp) hebben we al ruw een voorlopige databasestructuur bepaald. Nu we het datamodel in meer detail hebben uitgewerkt, zijn we (in het tweede gedeelte van deze fase bij activiteit 3.10) in staat om uit dit voltooide conceptuele gegevensmodel de definitieve structuur van de tabellen met gegevens in de gegevensbank afleiden. Het bij activiteit 3.4 gevormde conceptuele model heet ook wel de functionele gegevensstructuur; de tabellen (activiteit 3.10) staan wel bekend onder de naam technische gegevensstructuur. Het conceptuele model kan/moet nog met de gebruikers worden besproken om de juistheid en compleetheid na te gaan. DO.6

7 Activiteit 3.5 Specificeer mens/machine-interfaces (criteria vastleggen) Het resultaat van activiteit was een beschrijving van de functies op gebruikersniveau met daarbij ook een inventarisatie van de dialoog met de gebruiker. In deze activiteit 3.5 gaan we een aantal criteria vastleggen waaraan de toekomstige beeldscherm- (en lijst-) indelingen zullen moeten voldoen. Het moge duidelijk zijn, dat deze criteria moeten worden vastgelegd, vóórdat je met activiteit 3.9 start. Criteria voor de toekomstige interacties van de uitgewerkte basisfuncties met de gebruiker. Daarbij kunnen we onderscheiden: - invoerschermen; - informatieschermen; - dialoogschermen; en: - menuschermen. N.B. Wij hebben in onze aanpak al tijdens de basisontwerp-fase de basisdialoog reeds vastgelegd, dat wil zeggen de communicatie tussen gebruiker en informatiesysteem (de mens-machine interactie) voor wat betreft de keuze van uit te voeren functies (de interactie van de gebruiker met hoofdfuncties en functies). Standaard gebeurt dat ontwerpen van menu-schermen echter ook pas in de huidige Detailontwerp-fase, maar in verband met het spreiden van benodigde tijd en inspanningen hebben we dat onderdeel wat naar voren geschoven. Het gebeurt vaak dat informatiesystemen niet succesvol zijn vanwege gebrekkig ontworpen mens/machineinterfaces. Die werden dan niet echt ontworpen, maar veeleer ontwikkeld naar de grillen van individuele programmeurs, die op zulke taken niet berekend zijn. Consistentie is een van de belangrijkste punten bij het ontwerp van deze interfaces. Gebrekkig maar consistent ontworpen interfaces zijn meestal minder 'gebruiksvijandig' dan beter ontworpen maar inconsistente interfaces. Belangrijke punten voor het ontwerpen van een dialoog zijn: - basisdialoog: aparte menuschermen of pull down- of popup-menu's (of zelfs: geen menu's maar ingetikte tekst-commando's?) - de wijze waarop (eventuele) 'help'-informatie kan worden opgevraagd - het afhandelen van foutsituaties (met de plaats waar de foutboodschap op het scherm moet verschijnen en of dan in de tekst wel/niet een verwijzing naar hoe nadere informatie kan worden verkregen; via een pagina in het handboek, via een help-scherm o.i.d.) - de opbouw van de schermen: - wel/niet gebruiken van geluidsignalen, kaders, windows, kleur, reversed video e.d. - de wijze waarop de lengte van een invoerveld zichtbaar moet worden gemaakt - het wel/niet gebruiken van default (standaard) waarden om de hoeveelheid invoer te verminderen Het is aan te bevelen om het ontwerp concreet te maken via het werken met een prototype. Activiteit 3.6 Vervaardig functioneel ontwerprapport Op grond van de resultaten van de voorgaande activiteiten wordt het rapport functioneel ontwerp gemaakt. Dit rapport bevat het uitgewerkte conceptuele gegevensmodel en een overzicht van de uitgewerkte basisfuncties met bijbehorende dialogen in voor de opdrachtgever/toekomstige gebruiker begrijpelijke taal. Het rapport functioneel ontwerp geeft een gedetailleerde functionele blauwdruk van het informatiesysteem. In een 'echte' ontwikkelingssituatie geeft een rapport functioneel ontwerp ook inzicht in: - de prestaties van (de onderdelen van) het informatiesysteem en daarmee te koppelen systemen - de eisen die aan te gebruiken apparatuur en programmatuur worden gesteld - de eisen ten aanzien van het te gebruiken gegevensbanksysteem - de eisen ten aanzien van eventueel te gebruiken computernetwerken - te nemen beveiligingsmaatregelen - aspecten van kwaliteitsbewaking Activiteit 3.7 Valideer functioneel ontwerprapport Het functionele ontwerp moet worden gevalideerd, dat wil zeggen door de opdrachtgever beoordeeld en goedgekeurd. Met deze activiteit wordt het ontwerp van de functionele aspecten van het informatiesysteem voltooid. Alle voor de gebruiker relevante aspecten moeten in dit stadium volledig gespecificeerd zijn. Verificatie is voorts uiterst belangrijk, omdat dit functioneel ontwerp de basis zal vormen voor de systeemacceptatietest, die bij activiteit 3.13 zal worden uitgewerkt. DO.7

8 Detailontwerp - TECHNISCH DEEL Activiteit 3.8 Specificeer procedures en formulieren Het doel van deze activiteit is het specificeren van de onderdelen die handmatig uitgevoerd zullen worden. Handmatige werkzaamheden komen voor als afzonderlijke delen van het systeem en als onderdeel van interactieve delen, waarbij er een wisselwerking is tussen handmatig en geautomatiseerd. Ze komen ook voor bij het voorbereiden van de invoer voor en het verwerken van de uitvoer van het geautomatiseerde deel. Bij deze activiteit moet aangegeven worden hoe die handmatige functies uitgevoerd zullen moeten worden; welke handelingen daarbij precies verricht moeten worden. Via werkbeschrijvingen wordt aangegeven welke werkzaamheden verricht moeten worden. Pas in SDM-fase 5 (Invoering) hoeft te worden vastgesteld welke werkzaamheden tot taken voor (uitvoering door) welke functionarissen gebundeld zullen worden. Wèl moeten de werkbeschrijvingen de basis kunnen vormen voor eventueel benodigde opleidingen en voorlichting. Voor wat te gebruiken formulieren betreft, moet o.a. worden vastgesteld of oude formulieren gehandhaafd kunnen worden of dat daarvoor nieuwe moeten worden ontworpen, of uitvoer-formulieren wel/niet gedeeltelijk moeten worden voorbedrukt, wie of welke instantie belast is met het onderhoud, de verspreiding en het in voorraad hebben van de diverse soorten formulieren, of een bepaalde uitvoer in plaats van via een grijze cijferbrij niet beter als grafische presentatie gemaakt kan worden, etc. etc.. Activiteit 3.9 Specificeer beeldscherm- en lijstindelingen Het resultaat van activiteit 3.3 was een beschrijving van de functies op gebruikersniveau met daarbij ook een inventarisatie van de dialoog met de gebruiker. Bij activiteit 3.5 zijn daar bovendien een aantal criteria aan toegevoegd, waaraan de toekomstige beeldscherm- (en lijst-) indelingen zullen moeten voldoen. N.B. Nogmaals: uit efficiency-overwegingen zullen wij activiteiten 3.3 en 3.9 combineren! In deze activiteit gaan wij die dialogen nu gedetailleerd uitwerken. De interacties van de uitgewerkte basisfuncties met de gebruiker gaan we beschrijven in de vorm van schermen. Daarbij kunnen we onderscheiden: - invoerschermen; - informatieschermen; - dialoogschermen; en: - menuschermen. N.B. We hebben al eerder opgemerkt, dat we de mens-machine interactie voor wat betreft de keuze van uit te voeren functies (de menu-schermen dus) al tijdens de basisontwerp-fase hebben uitgevoerd en dat dat standaard echter pas in de huidige Detailontwerp-fase gebeurt, maar dat we in verband met het spreiden van benodigde tijd en inspanningen dat onderdeel in deze cursus wat naar voren hebben geschoven. De inhoud van de schermen die in de dialoog met de gebruiker een rol spelen, wordt vastgelegd met in acht neming van de bij activiteit 3.5 vastgelegde criteria en algemene regels voor Gebruikersinterfaces. De tekst van de schermen moet aansluiten bij het conceptuele model. In de dialogen zal naar in het conceptuele model voorkomende objecten verwezen worden met hun in het vierde onderdeel van de informatieanalyse gevonden identificatie (namen). Dialoog- en informatieschermen, die te maken hebben met de controle op het naleven van geldende beperkingsregels die vóór de bewerkingen van gegevens in het informatiesysteem moeten worden uitgevoerd, spelen in dit alles vaak een belangrijke rol. Tijdens deze activiteit wordt in de praktijk ook de eerste versie van de gebruikershandleiding vervaardigd. DO.8

9 Als voorbeeld over de factureringsafdeling nemen we de basisfunctie klant verwijderen : Klant verwijderen Klantnummer: Klantnaam: Straatnaam: Huisnummer: Postcode: Woonplaats: Verwijder Afbreken en stel dat we bij het beschrijven van het gedrag van deze functie naar de gebruiker toe, bij de uitwerking o.a. het volgende informatiescherm aangekondigd hebben (zie bijlage DO-e): info 1.: klantidentificatie gefaald! Een mogelijke gedetailleerde uitwerking van dit informatiescherm zou nu (in overleg met de gebruiker te bepalen!) kunnen zijn:! Er komt in de database geen klant met klantnummer <klantnummer> voor. Okay Het wordt een flinke klus, maar in de praktijk zullen toch echt alle schermen op deze manier en in samenspraak met de gebruikers van het toekomstige systeem moeten worden vastgelegd. Door gebruik te maken van een screen designer tool kan dit echter redelijk efficiënt gebeuren. Zie verder in bijlage DO-e bij dit hoofdstuk de uitwerking van het voorbeeldrapport over de factureringsafdeling. Activiteit 3.10 Ontwerp opslagstructuur In deze activiteit wordt uit het conceptueel gegevensmodel (het conceptuele schema) dat in het vierde onderdeel van de informatieanalyse voltooid is, de tabelstructuur afgeleid voor de gegevens die in de gegevensbank worden opgeslagen. Het gaat daarbij dus om een technische realisatie van de opslag van gegevens in tabellen in de gegevensbank; de gebruiker zal van deze technische realisatie geen weet hebben. De gebruiker heeft een functioneel model van het informatiesysteem waarin het conceptuele gegevensmodel uit het rapport functioneel ontwerp een belangrijke rol speelt. Voor de gebruiker van het informatiesysteem zal deze tabelstructuur dus verborgen blijven. Wij vinden de tabelstructuren door het conceptuele schema in een aantal stappen om te vormen, te transformeren, naar tabellen. Deze transformatie van een conceptueel schema naar tabellen is een redelijk bekende techniek, die in principe ook automatiseerbaar is. De transformatie heeft twee doelen: - op de juiste wijze tabellen vormen - zorgen dat de beperkingsregels uit het conceptuele schema in de gevormde tabellen terug te vinden zijn. De transformatie kent drie stappen: Stap 1 Omzetten van identificatierelaties Stap 2 Omzetten van relaties die niet uniek zijn op één rol. Stap 3 Omzetten van de overige relaties in het conceptuele schema. In bijlage DO-d bij dit hoofdstuk zullen wij deze stappen gedetailleerd beschrijven. De werkwijze zal daar geïllustreerd worden aan de hand van een 'personeelsadministratie'-voorbeeld. DO.9

10 Activiteit 3.11 Specificeer programmatuur We moeten bij deze activiteit vastleggen hoe de fysieke structuur van de gehele programmatuur zal zijn. Daarvoor geven we aan in welke modules we het totale programma gaan opsplitsen en hoe de onderlinge relaties tussen deze modules zullen zijn. Modules die op meer dan één plaats gebruikt worden, zullen nauwkeuriger afgebakend moeten worden dan modules die specifiek zijn. Van iedere module moet de functie (het doel) bekend zijn en de interface met de omgeving (de invoer en de uitvoer). De interne werking (het proces) en de hierbij benodigde interne gegevens mogen nog onbekend zijn. De beschrijving van de interne structuur van de afzonderlijke modules gebeurt pas in de volgende (Realisatie-) fase. Bij het ontwerp moet er nu dus naar gestreefd worden dat de modules zodanig gedefinieerd worden, dat we ze kunnen gebruiken, ook zonder dat hun interne structuur bekend is. Denk hier dus aan het vastleggen van (naam + doel + invoer/uitvoer + onderlinge samenhang van): - deelprogramma's - eventuele vaker gebruikte procedures binnen een of meer procedure-bestanden - 'menu'- en/of 'scherm'-bestanden en hun samenhang met andere modules In een procedure-bestand kunnen we bijvoorbeeld procedures opnemen, die te maken hebben met: - Beperkingsregels : beperkingsregels zullen moeten worden afgedwongen bij uitvoering van het programma dat het informatiesysteem realiseert. Er is echter maar een beperkt aantal soorten beperkingsregels. Dit betekent dat voor het afdwingen van een bepaalde soort beperkingsregel een 'sjabloon' kan worden vastgelegd dat steeds als deze bepaalde regel moet worden afgedwongen, gebruikt kan worden. Of zo'n sjabloon de vorm aanneemt van een procedure met parameters of van een stukje programmacode waarin kleine veranderingen worden aangebracht hangt van de situatie af. De vermelding van een gewenste procedure kan bijvoorbeeld een volgende aanduiding hebben, waarbij alleen de procedure/functie kop en de parameters (indien mogelijk met hun type) aangegeven worden: FUNCTION aantalkeer && aantal keer dat een waarde in een tabel voorkomt PARAMETERS mwaarde, mkolom, mtabelnaam Om aan te geven hoe een eventueel 'menu'-bestand wordt gebruikt, kan een uitgewerkte menu-boom handig zijn. Activiteit 3.12 Valideer technisch ontwerp Valideren van de resultaten tot nu toe is erg belangrijk. Na deze validatie door de opdrachtgever/gebruiker liggen de ontwerpbeslissingen (zowel functioneel als technisch) vast in gedetailleerde specificaties en wordt het informatiesysteem conform dit ontwerp gerealiseerd. Veranderingen in het ontwerp worden wanneer daadwerkelijk met programmeren begonnen is, al snel erg kostbaar (het kost dan erg veel tijd om zulke veranderingen alsnog aan te brengen). De validatie moet zich op de volgende punten concentreren: - is het technisch ontwerp conform het functioneel ontwerprapport van activiteit 3.7? - eventuele veranderingen in de functionele aspecten na validatie van dat functioneel ontwerp - de interfaces met andere informatiesystemen en andere deelprojecten - de volledigheid en consistentie van het ontwerp, de betrouwbaarheid ervan en de naleving van standaards en normen - in de praktijk komt hier o.a. bij: - voldoet het ontwerp nog aan beveiligings- en prestatie-eisen? - is die eerste versie van het gebruikershandboek al bruikbaar? DO.10

11 Activiteit 3.13 Vervaardig gedetailleerd testplan Het functionele testplan wordt afgemaakt. Alle identificeerbare functionele delen van het systeem (hoofdfuncties, functies, basisfuncties) moeten getest worden. Voor elk van die delen moeten testgevallen op papier staan. Verder moet duidelijk zijn hoe de verantwoordelijkheden bij de acceptatietest verdeeld zijn, met name tussen opdrachtgever en ontwerper/bouwer (wie zorgt voor wat?). Dit acceptatie-testplan wordt gevalideerd door opdrachtgever en ontwerper/bouwer. N.B. In ons project wordt de acceptatietest uitgevoerd door de cursusleiding; je hoeft dus zèlf géén acceptatietestplan te maken. Aan de acceptatietest gaan echter andere testen vooraf. De basisfuncties moeten straks worden uitgetest zo gauw deze geprogrammeerd zijn, de functies die ontstaan door samenvoeging van basisfuncties moeten zo gauw deze geprogrammeerd zijn worden getest en tenslotte moeten de hoofdfuncties, die ontstaan door samenvoeging van functies en die het totale systeem vormen, worden getest in de systeemtest. Voor deze testen (van basisfunctietesten tot systeemtest) moet je wél het testplan opstellen. Dit betekent dat je de testgevallen met bijbehorende testgegevens nu, in deze activiteit, op schrift moet stellen in een functioneel systeemtestplan. Een belangrijk onderdeel in het gehele testplan zal zijn het per functie formuleren van de na te leven beperkingsregels. Onder de geïnventariseerde beperkingen komen beperkingen op de vorm van de gegevens voor. Andere beperkingsregel zeggen iets over de samenhang tussen gegevens; vooral die zijn essentieel! Zie verder bijlage DO-i bij dit hoofdstuk over het opstellen van het functioneel testplan. Activiteit 3.14 Vervaardig plan voor realisatie en invoering Nu alle details van het ontwerp bekend zijn kan de planning voor de realisatie en de invoering ook in detail gemaakt worden. De plannen zoals vervaardigd voor het Basisontwerp moeten zonodig worden bijgewerkt. Wanneer er verscheidene deelprojecten ontwikkeld worden, moet er een totaalplan voorhanden zijn, waarmee de samenhang van de deelprojecten bewaakt wordt. Het nu op te stellen plan voor realisatie en invoering moet in de praktijk voor elk (deel)project o.a. bevatten: - alle toekomstige activiteiten en de afhankelijkheden daartussen; - een globaal tijdschema; - een bijgewerkte kosten/baten-analyse. Zeker voor onze cursus geldt dat, omdat door meerdere personen aan de realisatie wordt gewerkt en de een vaak afhankelijk is van het opleveren van een resultaat door de ander, deze planning erg belangrijk is. Omdat programmeren altijd meer tijd kost dan gepland (vaak wel drie keer zolang) is het van belang dat de planning voldoende ruimte laat voor 'onvoorzien' en dat ook een goede bewaking van de werkzaamheden wordt ingepland. Ook al kun je op dit moment niet alle problemen overzien die straks in de realisatiefase zullen optreden, toch is het van veel belang nu al zo goed mogelijk te plannen; het opvangen van onvoorziene problemen is bij een doordachte planning en een goede bewaking van deze planning veel gemakkelijker dan in een open situatie. Doordachte planning hier spaart straks in de zware realisatiefase een hoop frustratie en tijd. In de B3-projectfase kan hier eventueel een voorstel tot 'kappen' komen. Activiteit 3.15 Rapporteer over Detailontwerp. Het rapport detailontwerp vat de belangrijke punten uit functioneel en technisch deel samen en bevat de planning voor de realisatiefase en de invoering. Het rapport wordt samengesteld uit de resultaten van de eerder beschreven activiteiten in het technisch deel van het detailontwerp. Het fungeert o.a. als naslagdocument voor de programmeurs in de realisatiefase. Het functionele deel van het detailontwerp bevat grote delen die met kleine aanpassingen in de gebruikershandleiding kunnen worden opgenomen. Er dient tevens gerapporteerd te worden over de in deze fase opgedane ervaringen en het daaruit geleerde, zodat toekomstige detailontwerpen effectiever en efficiënter kunnen worden uitgevoerd. DO.11