IV SDM - FASE 2 BASISONTWERP



Vergelijkbare documenten
III SDM - FASE 1 DEFINITIESTUDIE

SDM II - System Development Methodology II. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Functioneel ontwerp. Een introductie. Algemene informative voor medewerkers van SYSQA B.V. Almere

Checklist basisontwerp SDM II

System Development Methodology (SDM II)

Samenvatting Informatica Module 6 & 7

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

Bijlagen A bij hoofdstuk IV over Basisontwerp

II SDM - FASE 0 INFORMATIEPLANNING

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

Ant: B Dit is het doel van het proces.

Informatie analyse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Bijlage BO - g) Rapport basisontwerp secretariaat sportvereniging

Informatieanalyse Sjabloon rapportage

Praktijkinstructie Oriëntatie op de informatie-analyse 4 (CIN08.4/CREBO:50131)

Functiepuntanalyse. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ORGANISATORISCHE IMPLENTATIE BEST VALUE

<<Organisatie en projectnaam>> Sjabloon Functioneel Ontwerp

Technisch Ontwerp Ontwerp template

Planning & Control. Inleiding. Inhoudsopgave

Praktijkinstructie Applicatieontwikkeling 4 (ICT12.4/CREBO:53260)

voorbeeldexamen I-Tracks Project Participation Foundation (PPF) voorbeeldexamen PPF uitgave oktober 2007

voorbeeldexamen I-Tracks voorbeeldexamen ISDDF Information Systems Design and Development Foundation uitgave april 2005

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

Praktijkinstructie Geautomatiseerde informatievoorziening - beheer 3 (CIN02.3/CREBO:50170)

De ontwikkelcirkel 1/6

Bijlagen B bij hoofdstuk II over Informatieplanning:

Functionaliteitenbeheer

Computercommunicatie B: Informatiesystemen

COINS Praktijkproject. René Dorleijn & Gertjan van Manen. 23 januari 2008

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol. Datum: dd-mm-jj

EXIN Projectmanagement Foundation

Overzicht van taken en competenties. Demandmanager-rol

Project Fasering Documentatie Applicatie Ontwikkelaar

EPD Epic. (Inbare) Baten met het nieuwe EPD

Secretariaat Sportvereniging: rapport Definitiestudie

Persoonlijk Actieplan (PAP)

perspectivisch calculeren

Functionele Specificatie van GRCcontrol. Rieks Joosten

Onderzoeksassistent CONCEPT. Doel

Ontwikkelaar ICT. Context. Doel

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

[functie] De functie die verantwoordelijk is voor het beheren van applicaties. [zaak] Een methode of maatregel om een risico te managen.

Bijlagen A bij hoofdstuk III over Definitiestudie:

Tweede Kamer der Staten-Generaal

De strategische keuzes die moeten gemaakt worden zijn als volgt: Interne controle of zelfcontrole/sociale controle

a. Wat wordt verstaan onder V&V? b. Uit welke kernactiviteiten bestaat V&V? c. Noem enkele voor- en nadelen van inspecties. d. Idem voor testen.

Nederland haalt de XBRL buit nog niet binnen. Door Ron van Ardenne

Het BiSL-model. Een whitepaper van The Lifecycle Company

Duurzaam Product. Ecodesign methode van Tischner

Oplossingsvrij specificeren

Rapportage Pizzasessie Functioneel-beheer.com Specialisten Managers Adviseurs Algemeen functioneel beheer applicatiebeheer informatiemanagement

Portal Planning Process

Xedule: stimulator en simulator voor de verbetering van plannen én roosteren

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Inhoud. Deel A Inleiding

Les E-01 Projectmanagement

DATAMODELLERING BEGRIPPENBOOM

Projectmanagement De rol van een stuurgroep

Verplichtingen administratie. Brochure - Verplichtingen administratie

Het sturend niveau: onderlinge afstemming en jaarplannen Een whitepaper van The Lifecycle Company

Ontwerp. <naam applicatie>

Afbeelding: TriamFloat Effectmetingsmodel

Handleiding Amyyon Care Plannen, registreren en rapporteren zorg. Rondomzorg

Plan van Aanpak Afstuderen

Je kunt een Data Flow Diagram (DFD) gebruiken om gegevensstromen op een grafische wijze weer te geven.

Functie Punt Analyse in het voortraject

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Cursus. Schrijf een projectplan

Inhoud. Deel een Het ontwikkeltraject 13. Inleiding 11

ERP Implementatie in de praktijk

Projectplan. Kernregistratie Medewerkers en inowit

ONDERZOEK & ONTWIKKELING

Gelijkwaardigheid van niet-geaccrediteerde laboratoria (conform NEN-EN ISO/IEC 17025)

Hosting & support contract

Administrateur. Context. Doel. Rapporteert aan/ontvangt hiërarchische richtlijnen van: Directeur dienst Afdelingshoofd

Handleiding Nederlandse Besteksystematiek

Je kunt de presentatie na afloop van elke les downloaden. Ga naar : Kies voor de map Systeemontwikkeling

Paleis van de Verdraagzaamheid. Jaarplan 2012

Pagina 1 van 5. Examenprogramma Profielvak: dienstverlening & producten. De kern


In deze appendix wordt bekeken wat er moet gebeuren voordat

Cosmic Full Function Points (CFFP) Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Examenprogramma Profielvak: dienstverlening & producten

Tradinco Academy Cursus Programma

Informatiemanager. Doel. Context

Onderwerp: Risico inventarisatie project rwzi Utrecht Nummer: Dit onderwerp wordt geagendeerd ter kennisneming ter consultering ter advisering

Checklist risicofactoren IT-projecten

Overzicht DISPATCHER. Maatoplossing voor een elekctriciteitsproducent. Versie:

Antwoordmodel beoordelaars

Informatiebeveiligingsbeleid

PROGRAMMA Vak: Informatica..

Information Capability Engineering

CURRICULUM PLANNING SCENARIO S TON PEETERS, DICK KAMPMAN

1. Burgemeester en Wethouders van Leiden, ter uitvoering van het besluit van Burgemeester en Wethouders d.d. 29 april 2008 nr. 08.

Snel te implementeren. Inpasbaar in uw situatie

Bijlage 3: Master testplan

Rapportage mogelijkheden. rapportage eenvoudig en simpel gemaakt. Geen tijdregistratie zonder een adequate rapportage.

van onderwijs en onderwijsondersteuning binnen Directeur onderwijsinstituut

Workshop 3x. Project fasen. Workshop 8 september A. Snippe ICT Lyceum 1. Project documentatie. Analytisch vermogen. Programma structuur

Transcriptie:

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