IV SDM - FASE 2 BASISONTWERP IV.1 Inleiding Zoals reeds besproken onderkent het in Nederland veel gebruikte 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 derde fase van SDM, fase 2 : basisontwerp, bestaat uit de volgende samenhangende activiteiten: 2.1 uitgangspunten plan van aanpak 2.2 toekomstige werkomgeving 2.3 basis gegevensstructuur 2.4 basisfunctiestructuur 2.5 specificeer benodigde faciliteiten 2.6 technische vormgeving 2.7 basisontwerp valideren 2.8 totaalplan opstellen 2.9 rapport basisontwerp opstellen Met de gearceerde blokken in het schema worden weer de zogenaamde mijlpaalproducten aangegeven. BO. 1
Toelichting bij SDM-fase 2: Meestal is het ondoenlijk om zelfs maar te proberen om één allesomvattend overzicht te krijgen over een te ontwikkelen informatiesysteem. Het doel van de Basisontwerp-fase is om het tijdens de vorige fase gekozen systeemconcept en de systeemoplossing, zover uit te werken, dat deelsystemen en de functies daarbinnen gedefinieerd kunnen worden. De definitie van de mogelijke deelsystemen wordt grotendeels bepaald door: - de organisatie-omgeving; - de gegevensstructuur; en: - de vereiste functies. Vooral deze aspecten worden daarom in deze fase (in respectievelijk activiteiten 2.2, 2.3 en 2.4) bekeken. Wel is het noodzakelijk om niet alleen naar functionele en conceptuele aspecten te kijken, maar in verband met de reële mogelijkheden tot implementatie, ook naar de technische aspecten (activiteiten 2.5 en 2.6). We zullen daarbij moeten kijken naar welke (technische) consequenties voortvloeien uit de functionele specificatie. Aan de gewenste functies van het informatiesysteem (het WAT van het informatiesysteem) zitten technische consequenties (het HOE) vast die zich al heel snel laten vertalen in te maken kosten (ontwikkeling van programmatuur, kosten van apparatuur etc.). Uiteindelijk moet er een compromis gevonden worden tussen wat functioneel gewenst wordt (het WAT) en wat technisch te realiseren valt (het HOE). Deze afweging is heel belangrijk. In de fase basisontwerp moet je een evenwicht vinden tussen wat je zou willen (het functionele WAT van het informatiesysteem) en wat je binnen het project met de beschikbare werkkracht (technisch) kan. Van belang is het maken van een realistische inschatting van de tijd en de mogelijkheden voor de realisatie van (onderdelen van) het informatiesysteem. Het gaat daarbij om tijd, in de praktijk meestal vertaald in geld. Merk op dat de fase basisontwerp eindigt met het opstellen van een gedetailleerd projectplan (totaalplan). In dit projectplan moet de inschatting van realisatie-mogelijkheden verwerkt worden. Dit projectplan biedt dan houvast voor de nog volgende fasen. Het basisontwerp levert de globale functionele en technische specificaties van het informatiesysteem op. De specificaties gaan een niveau dieper dan in de definitiestudie, maar blijven grotendeels beperkt tot het WAT (welke functies) van het informatiesysteem. IV.2 Opsomming van de Basisontwerp-activiteiten We geven nu eerst weer een volledige opsomming van alle (9) 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. 2.1 Leg uitgangspunten vast en stel een plan van aanpak op 2.2 Geef toekomstige werkomgeving aan 2.3 Bepaal basisgegevensstructuur 2.4 Bepaal basisfunctiestructuur 2.5 Specificeer benodigde faciliteiten 2.6 Bepaal technische vormgeving 2.7 Valideer basisontwerp 2.8 Vervaardig totaalplan en kosten/batenanalyse 2.9 Rapporteer over basisontwerp. Ook geven we hier weer een overzicht van de diverse bijlagen bij dit hoofdstuk over Basisontwerp: Voor gebruik vanaf oefenfase: BO-a) basisgegevensstructuur : uniciteitspijlen BO-b) basisfunctiestructuur : 1) specificatie functionele eisen BO-c) basisfunctiestructuur : 2) groeperen en menu's BO-d) Rapport Basisontwerp Factureringsafdeling Met betrekking tot de oefenopdracht 2 zèlf: BO-e) Goede raad voor het maken van oefenopdracht 2 (van week 4) BO-f) Oefenopdracht 2: Zakboekinformatiesysteem Fase 2 Voor gebruik in projectfase: BO-g) Rapport basisontwerp secretariaat sportvereniging (deels) BO. 2
IV.3 Activiteiten voor het basisontwerp tijdens de oefenfase BEPERKING!! In dit oefendeel van de cursus beperken wij ons tot het uitvoeren van twee kernactiviteiten uit de fase basisontwerp: - BASISGEGEVENSSTRUCTUUR BEPALEN ACTIVITEIT 2.3 - FUNCTIES BEPALEN ACTIVITEIT 2.4 (Uiteraard moet je ook activiteit 2.1 (planning) en 2.9 (rapport + evaluatie) uitvoeren.) De overige activiteiten - die bij het ontwerpen van informatiesystemen zeker niet gemist kunnen worden - komen in het project-deel van de cursus aan bod. IV.4 Beschrijving van de afzonderlijke activiteiten van de Basisontwerp-fase Activiteit 2.1 Leg uitgangspunten vast en stel een plan van aanpak op. Als uitgangspunt voor het basisontwerp dienen uiteraard de producten uit de definitiestudie. In een plan van aanpak wordt vastgelegd hoe de fase basisontwerp zal worden doorlopen: welke activiteiten zullen worden uitgevoerd, welke producten gemaakt zullen worden, welke momenten van afstemming en besluitvorming er zullen zijn, binnen welke tijd en onder welke voorwaarden een en ander zal worden gerealiseerd en wie wat wanneer zal doen. Activiteit 2.2 Geef toekomstige werkomgeving aan. In de vorige fase (definitiestudie) is de gewenste informatievoorziening bepaald, zijn systeemeisen vastgesteld en is een blauwdruk van het te bouwen totale informatiesysteem gemaakt. In activiteit 2.2 gaan we de hoofddoelstelling van de Basisontwerp-fase - het wel/niet (kunnen) opsplitsen van het totale systeem in deelsystemen - benaderen vanuit een organisatorische invalshoek. De wijze waarop de organisatie is opgebouwd en de taken daarin vervuld worden, kan van invloed zijn op het ontwerp van het systeem. Zo kan op basis van de verantwoordelijkheidsstructuur van de organisatie voor opsplitsing in deelsystemen worden gekozen. Het welke onderdelen van het systeem handmatig dan wel geautomatiseerd uitgevoerd gaan worden, wordt hier eveneens door beïnvloed. De toekomstige werkomgeving moet nu zodanig beschreven worden (niet te gedetailleerd en niet te technisch) dat duidelijk wordt, hoe de interactie zal zijn tussen de te automatiseren delen en de handmatige delen van het toekomstige informatiesysteem. Bepaald moet worden wat in grote lijnen de toekomstige organisatiestructuur zal worden. Taken, bevoegdheden en (gewenst) opleidingsniveau moeten per werknemer bekeken worden. Belangrijk is ook, dat duidelijkheid ontstaat over de veranderingen die het nieuwe systeem in de huidige werkomgeving teweeg zal brengen, en over de manier waarop deze veranderingen begeleid zullen worden. BO. 3
Activiteit 2.3 Bepaal basisgegevensstructuur De centrale vraag van deze ontwerpfase over het wel/niet (kunnen) opsplitsen van het totale systeem in subsystemen, wordt mede bepaald door de wijze waarop de (bedrijfs)gegevens worden gebruikt én opgeslagen. In deze activiteit 2.3 wordt nu de basisgegevensstructuur bepaald door het conceptuele model van de werkelijkheid waarin het informatiesysteem moet functioneren. Dit model bestaat uit de relaties die er tussen de gegevens (en de daarbij behorende personen, begrippen of objecten in de werkelijkheid) bestaan. Dit conceptuele model waarmee wij in de definitiestudie begonnen zijn, wordt in het basisontwerp verder verfijnd. In deze activiteit wordt het tweede deel van de informatieanalyse uitgevoerd: er wordt nagegaan welke van de rollen die objecten in het informatie-structuurdiagram spelen, uniek zijn en welke niet. Wij gaan voor alle rollen de aantallenregel: uniek (rol éénmaal gespeeld) / niet-uniek (rol meerdere malen gespeeld) na. Als basis voor deze activiteit dient dus het informatie-structuurdiagram dat als onderdeel van het systeemconcept in de definitiestudie opgesteld is. De diagrammen worden (met uniciteitspijlen) gedetailleerder uitgewerkt met als doel om mogelijke opsplitsingen in 'deel'-databanken (en/of gegevenstabellen) te ontdekken. Daartoe we hier al een ruwe, voorlopige structuur voor de relationele database-gegevenstabellen die we voor ons te ontwerpen informatiesysteem nodig zullen hebben. In de volgende SDM fase (3) gaan we deze ruwe database-structuur detailleren en zonodig corrigeren. Bij de huidige activiteit 2.3 moet ook een schatting worden gemaakt van de verwachte omvang van de toekomstige gegevensverzamelingen, het verwachte gebruik en de verwachte mutatiegraad van de gegevenselementen. N.B. Pas in de volgende SDM-fase, detailontwerp, krijgt dit informatiestructuurdiagram zijn uiteindelijke vorm en dan is het conceptuele gegevensmodel van de werkelijkheid waarin het informatiesysteem functioneert compleet gemaakt. Zie verder bijlage BO-a bij dit hoofdstuk. Activiteit 2.4 Bepaal basisfunctiestructuur De hoofdfuncties in het systeemconcept waren reeds bekend uit de definitiestudie. N.B. Mocht je nog niet de vergelijking van geuite informatiewensen versus theoretisch mogelijke functies van definitiestudie-bijlage DS-f hebben uitgevoerd, doe dit dan alsnog eerst! In deze activiteit wordt per hoofdfunctie aangegeven welke onderdelen, welke (deel) functies, er binnen die hoofdfuncties zullen worden onderscheiden. We gaan de 'geconcretiseerde informatiewensen' uit de Definitiestudie (b.v. toon factuur van klant ) verder uitwerken, zodat duidelijk wordt wat voor acties later precies zullen plaatsvinden bij het activeren van die functies. Daarbij wordt voor toekomstige gebruikers duidelijk vastgelegd, wat voor acties later van henzelf verwacht worden (b.v. wat moeten ze precies doen om die factuur van een klant te zien te krijgen? moeten ze een adres of een klantnaam of een klantnummer invoeren?) en welke acties het systeem moet uitvoeren. Door deze manier van werken wordt bovendien duidelijk welke gegevens nodig zijn voor die verschillende informatiewensen (ook dit hoort bij de achterliggende doelstelling 'opsplitsen in deelsystemen'). In de praktijk moet hier zeker ook aandacht besteed worden aan systeemonderhouds- en beveiligingsfuncties. Van de gevonden structuur (hoofdfuncties, functies, basisfuncties) wordt een genummerd overzicht gemaakt. Indien gewenst en in overleg met de gebruiker (als deze er is) worden de basisfuncties gehergroepeerd en/of worden er basisfuncties samengevoegd. Mede aan de hand van dit overzicht kan bepaald worden of een opsplitsing van het totale systeem in deelsystemen mogelijk is. De bepaalde functie-hiërarchie wordt gebruikt voor het vastleggen van de menu-structuur van het toekomstige informatiesysteem en/of deelsystemen. Zie verder bijlagen BO-b en BO-c bij dit hoofdstuk. Activiteit 2.5 Specificeer benodigde faciliteiten In deze activiteit wordt vastgelegd welke hard- en software nodig is voor zowel het ontwikkelen als later het kunnen gebruiken van alle geplande functionaliteit van het systeem. Dit moet bijtijds gebeuren omdat vaak nogal wat tijd gemoeid is met het verwerven van (vooral) hardware, maar vaak ook ontwikkel-software (o.a. tools ). Als er onzekerheid bestaat over leverdatum of uitvoering, moeten alternatieven worden gespecificeerd. BO. 4
Activiteit 2.6 Bepaal technische vormgeving Deze activiteit heeft tot doel, het vaststellen van de structuur van het te bouwen informatiesysteem voor wat betreft de verdeling van het informatiesysteem in afzonderlijk te realiseren deelsystemen. De belangrijkste voor dit onderdeel te beschouwen producten, zijn die van activiteit 2.2 (organisatorische structuur van de 'toekomstige werkomgeving'), 2.3 (basisgegevensstructuur) en 2.4 (basisfunctiestructuur). Zo zou bijvoorbeeld een totaal informatiesysteem voor een studentenadministratie (afhankelijk van...) kunnen worden opgesplitst in een - eerst te bouwen - deelsysteem voor naam-, adres-, woonplaats- e.d. gegevens, een vervolgens te bouwen systeem voor vakken en tentamens - waardoor studenten zich op een geautomatiseerde manier kunnen inschrijven voor het meedoen aan een tentamen - en tot slot een deelsysteem voor het registreren van tentamenresultaten etc.. Activiteit 2.7 Valideer basisontwerp Met wat er tot nu toe uitgewerkt is in deze fase gaat de ontwikkelaar terug naar de toekomstige gebruikers van het informatiesysteem en naar de opdrachtgever. Deze geven hun commentaar en moeten het basisontwerp valideren, dat wil zeggen er hun fiat aan geven. Deze validatie van het basisontwerp is erg belangrijk als er daadwerkelijk een automatiseringsproject wordt uitgevoerd. De opdrachtgever moet op grond van de producten precies kunnen of het nog nader te detailleren informatiesysteem doet wat het moet doen (een toekomstige werkomgeving biedt die gewenst wordt), in een technische structuur die gewenst wordt (hierbij spelen de kosten een belangrijke rol). Activiteit 2.8 Vervaardig totaalplan en kosten/batenanalyse Nu de nadere uitwerking van het te bouwen informatiesysteem is gevalideerd, kunnen - op grond van de producten die er nu zijn - uitvoeringsplannen gemaakt worden. Heel vaak zullen nu namelijk deelprojecten kunnen worden aangewezen, waarin een onderdeel van het informatiesysteem verder wordt gedetailleerd en gerealiseerd (fasen detailontwerp en realisatie). Om die verschillende deelprojecten ordentelijk te laten verlopen (wie doet wat, wanneer en hoe) wordt een betrekkelijk gedetailleerd projectplan opgesteld tot aan de invoering toe. De hoeveelheid werk wordt meestal opgesplitst in een aantal afzonderlijke projecten. Er wordt een tijdschema opgesteld en de hoeveelheid te investeren mensjaren wordt begroot; dit gebeurt dan zowel voor de afzonderlijke deelprojecten als voor het totaal. Activiteit 2.9 Rapporteer over basisontwerp. Als afsluiting van deze fase vindt weer rapportage plaats in de vorm van het rapport basisontwerp, dat grotendeels uit producten van deze fase kan worden samengesteld. Zorg er weer voor dat (ter latere evaluatie) op de een of andere manier over het in deze SDM-fase uitgevoerde onderzoek zodanig gerapporteerd wordt, dat opgedane lessen en ervaringen bewaard blijven. BO. 5