Secretariaat Sportvereniging: rapport Definitiestudie

B3: Systematisch bouwen van informatiesystemen

Bijlage DS-e)

Bijlagen B bij SDM-fase 1: Definitiestudie

Secretariaat Sportvereniging: rapport Definitiestudie (UITTREKSEL)

Dit rapport beperkt zich niet tot alleen de resultaten van de activiteiten 1.2, 1.3 en 1.5. Uitgangspunten Hoewel voorlopig alleen de verenigingsadministratie wordt geautomatiseerd, wordt in dit rapport ook de wedstrijdadministratie in beschouwing genomen. Dit om de eisen te bepalen die de wedstrijdadministratie stelt aan het toekomstig verenigingsadministratiesysteem.

Plan van aanpak

Gewenste informatievoorziening De met leden, secretaris en andere bestuursleden gehouden interviews leveren bij analyse de volgende informatie over de gewenste informatievoorziening: - Door leden van de vereniging gewenste informatievoorziening . Niet opnieuw aanleveren van gegevens voor verlenging van het lidmaatschap van de vereniging en eventueel ook voor aanmelding bij en verlenging van het lidmaatschap van de bond. . Mogelijkheid om op clubavonden het bondsnummer te weten te komen. . De stand van de interne competitie iedere week bijgewerkt. - Door de secretaris gewenste informatievoorziening . Naam, het adres en de geboortedatum van de spelers administreren met pasfoto, naam van het team en de klasse waarin de speler speelt (dit is de klasse van dat team). . De bondsnummers van de spelers administreren. . De teamgegevens administreren, dat wil zeggen: naam van het team, klasse, naam van de trainer(s), naam van de aanvoerder en namen van de overige spelers. . Lidmaatschapskaart met persoonsgegevens produceren (met pasfoto). . Verlengingslijst bondslidmaatschappen met spelersnaam en bondsnummer. . Inschrijflijst extern toernooi met de bondsnummers van de spelers gecontroleerd. . Stand van de interne competitie. . Aanmelding van teams voor de externe competitie. . Bijwerken teamadministratie en spelersadministratie op grond van promoveren of degraderen. . Bijwerken teamadministratie met nieuwe trainers, ander aanvoerderschap van een team, spelerswisselingen, etc. . Bijwerken spelersadministratie op grond van vertrek, adreswijzigingen, teamwijzigingen, klassewijzigingen, etc. - Door de bestuursleden gewenste informatievoorziening . Informatie over de stand van de interne competitie. . Spelersgegevens inclusief bondsnummers, teamgegevens. . Informatie over aanvoerders en trainers. . Informatie over de externe toernooien. . Adresetiketten van de spelers. Wanneer de hiervoor weergegeven wensen ten aanzien van de informatievoorziening worden gehonoreerd in het te bouwen informatiesysteem dan is het resultaat een effectieve en efficiënte informatievoorziening. De informatievoorziening is effectief omdat zowel in de huidige informatievoorziening als in de gesignaleerde lacunes in deze informatievoorziening door het informatiesysteem zal worden voorzien. De informatievoorziening is efficiënt omdat de tijdrovende werkzaamheden van de secretaris grotendeels worden geautomatiseerd. Verder moet de informatievoorziening nog aan de volgende - reeds in het rapport informatieplanning opgenomen - criteria voldoen: De duurzaamheid van het te ontwikkelen informatiesysteem is kritisch. Voor de invoering van een geautomatiseerd informatiesysteem binnen de sportvereniging moeten naar verhouding grote investeringen

DS-bijlagen B blz.1



worden gedaan die zwaar op de begroting drukken. Het is onmogelijk om op korte termijn opnieuw geld op de begroting te vinden voor uitgaven om de informatievoorziening te herzien. Het is derhalve noodzakelijk dat het informatiesysteem voor langere tijd ongewijzigd in bedrijf kan blijven. Consequentie is dat het systeem flexibel moet zijn. Wanneer bijvoorbeeld de sportbond overzichten in een ander formaat dan het huidige wenst, dan moet het zonder veel problemen mogelijk zijn het informatiesysteem aan te passen. Ook de gebruiksvriendelijkheid van het systeem is kritisch. De functie van secretaris wordt door vrijwilligers vervuld die door de ledenraad gekozen worden. De personele invulling van deze functie kan derhalve aan snelle wisselingen onderhevig zijn. Er mag niet verwacht worden dat de aftredende secretaris nog veel tijd kan investeren in de opleiding en training van de nieuwe secretaris in het gebruik van het informatiesysteem. Een nieuwe secretaris (of ook een invaller bij ziekte) moet snel met het informatiesysteem kunnen werken. Op grond van de (bij activiteit 1.5.c) uitgevoerde informatieanalyse is aan de gewenste informatievoorziening een concrete vertaling gegeven. De concrete informatie- , toevoeg-, verwijderen mutatiefuncties zijn aan leden, secretaris en andere bestuursleden voorgelegd. De concrete vertaling van de informatiebehoefte in functies die hieronder staat is in samenspraak met deze personen tot stand gekomen. Hieronder zijn slechts twee voorbeelden van zo'n concrete vertaling uitgewerkt; het rapport definitiestudie dient de uitwerking van alle functies te bevatten. . Informatie over de stand van de interne competitie - Toon resultaat van speler op standdatum - Toon resultaten van alle spelers op standdatum op alfabetische spelervolgorde - Toon resultaten van alle spelers op standdatum op standvolgorde - Toon resultaten van speler op volgorde van standdatum - Toon resultaten van alle spelers op volgorde van standdatum - Toon wedstrijden met uitslag van speler - Toon wedstrijden met uitslag van alle spelers op alfabetische spelervolgorde - Toon wedstrijden met uitslag op wedstrijddatum - Toon alle wedstrijden met uitslag op volgorde van wedstrijddatum . Informatie over aanvoerders en trainers - Toon teams met klasse met speler die aanvoerder is, op team- en klassevolgorde - Toon teams met klasse met speler(s) die trainer is (zijn), op team- en klassevolgorde - Toon speler die aanvoerder is van team - Toon speler(s) die trainer is (zijn) van team - Toon spelers die aanvoerder zijn, van teams op spelersvolgorde - Toon spelers die trainer zijn, van teams op spelersvolgorde Commentaar De concrete invulling van de informatiebehoefte kan als volgt met de betrokken personen besproken worden. Als uitgangspunt dient steeds een bestaande informatievraag van betrokkene die vertaald wordt in termen van de objecten uit de informatieanalyse. Hieronder staan een paar voorbeelden waarin, uitgaande van enkele veel voorkomende informatievragen, de vertaling in twee stappen plaatsvindt. . Informatie over aanvoerders en trainers - "Wie is de aanvoerder van het eerste herenteam?" TOON naam SPELER die aanvoerder is van TEAM "Heren 1" Toon speler die aanvoerder is van team . Spelersgegevens - "Welke spelers spelen er in het eerste herenteam?" TOON naam SPELER(s) van TEAM "Heren 1" Toon spelers van team - "Welke spelers spelen er in de derde klasse?" TOON naam SPELER(s) met KLASSE "3" Toon spelers met klasse - "In welk team speelt Bert Dijkmeester?"

DS-bijlagen B blz.2



TOON naam TEAM met SPELER "Dijkmeester, Bert" Toon team met speler

Veranderingsbehoefte en systeemeisen Veranderingsbehoefte Bij gebruik van het nieuwe informatiesysteem moet het niet langer nodig zijn gegevens meerdere malen in te voeren of te veranderen. Bij het veranderen van de klasse van een team moet bijvoorbeeld ook automatisch de klasse van de spelers van dat team worden veranderd. De lidmaatschapskaart van een lid moet 'met een druk op de knop' vervaardigd kunnen worden; alleen de pasfoto moet nog met de hand worden opgeplakt. Spelersgegevens, teamgegevens etc. moeten snel opvraagbaar zijn. Verder moeten diverse overzichten, waaronder inschrijflijsten, aanmeldingslijsten, overzicht van de interne competitie, adressen op labels 'met een druk op de knop' gemaakt kunnen worden.

Systeemeisen Het te bouwen informatiesysteem moet de mogelijkheid bieden om: - spelersgegevens in te brengen en te onderhouden - teamgegevens in te brengen en te onderhouden - aanvraaglijsten voor (verlenging) bondslidmaatschap te maken - overzichten te maken: . van alle leden met bondsnummer . van bepaalde leden (bijvoorbeeld van een team) . van alle teams . van bepaalde teams (bijvoorbeeld van alle teams in de 1e klasse) . van alle aanvoerders van teams . van alle trainers van teams - etiketten te maken van de adressen van alle spelers - etiketten te maken van de adressen van bepaalde spelers (bijvoorbeeld van een team) - lidmaatschapskaarten te maken - inschrijflijsten voor externe toernooien te maken - inschrijflijsten voor de bond (externe competitie) te maken - de uitslagen van de interne competitie te verwerken tot een standenoverzicht. Het systeem moet duurzaam zijn en gebruikersvriendelijk. Het moet efficiënt in het gebruik zijn.

DS-bijlagen B blz.3



Systeemconcept Systeemconcept : A) de hoofdfuncties (weergegeven in een SADT-diagram) spelers- of team-toevoeging/mutati

e/verwijdering

informatievraag` inschrijving uitslag bekend uitnodiging binnen verzending nodig

lidmaatsch.k. inschr.bond inschrijfgegevens

overz.spel.geg.

adreswijzigingen

overz.team.geg.

verenigingsadministratie mededelingen spelersgegevens teamgegevens

gegevensbank

spelersgegevens teamgegevens

inschrijving externe competitie opgave spelers interne comp./ externe toern.

inschr.ext.comp. inschr.ext.toer.

uitnodigingen

comp.lijst standenlijst

uitslagen

wedstrijdadministratie inschrijfgegevens comp.geg. standengegevens spelersgegevens teamgegevens inschrijfgegevens competitiegegevens standengegevens

DS-bijlagen B blz.4



Systeemconcept : B) de interacties Verenigingsadministratie besturingsinteracties . spelers- of team-toevoeging/mutatie/verwijdering . informatievraag grondstofinteracties . gegevens van inschrijfformulieren . adreswijzigingen . mededelingen . spelersgegevens . teamgegevens productinteracties . lidmaatschapskaart (spelersgegevens) . inschrijving bond (spelers- en teamgegevens) . overzichten (spelersgegevens) . overzichten (teamgegevens) . spelersgegevens . teamgegevens Wedstrijdadministratie besturingsinteracties . inschrijving externe competitie . inschrijving . uitslag bekend . uitnodiging binnen . verzending nodig grondstofinteracties . opgave spelers (interne competitie/externe toernooien) . uitnodigingen (extern toernooi) . uitslagen . spelersgegevens . teamgegevens . standengegevens . inschrijfgegevens . competitiegegevens productinteracties . inschrijflijst (externe competitie) . inschrijflijst (extern toernooi) . competitielijst . standenlijst . standengegevens . inschrijfgegevens . competitiegegevens

Systeemconcept : C) de gegevens De gegevens die een rol spelen binnen het informatiesysteem en die in de gegevensbank worden opgenomen zijn: besturingsgegeven (direct van hoofdfunctie verenigingsadministratie naar hoofdfunctie wedstrijdadmin.): inschrijving externe competitie de grondstofgegevens: teamgegevens, spelersgegevens, standengegevens, inschrijfgegevens (comp./toern.), competitiegegevens de productgegevens: teamgegevens, spelersgegevens, standengegevens, inschrijfgegevens (comp./toern.), competitiegegevens.

DS-bijlagen B blz.5



De informatieanalyse wordt op grond van deze gegevens uitgevoerd. In verband met het feit dat de beide hoofdfuncties (verenigingsadministratie en wedstrijdadministratie) volgens het projectenplan na elkaar ontwikkeld moeten kunnen worden, wordt de informatieanalyse voor beide hoofdfuncties gescheiden uitgevoerd. - In de hoofdfunctie verenigingsadministratie spelen als gegevens een rol: spelersgegevens, teamgegevens. - In de hoofdfunctie wedstrijdadministratie spelen een rol: spelersgegevens, teamgegevens, standengegevens, inschrijfgegevens (competitie./toernooien), competitiegegevens. Verenigingsadministratie Informatieanalyse van de gegevens behorende bij de hoofdfunctie verenigingsadministratie (teamgegevens en spelersgegevens): Toen in overleg met de verenigingssecretaris de relaties tussen de gegevens op de teamkaart in eerste instantie [abusievelijk] als volgt verwoord werden: Team (teamnaam) heeft /van Aanvoerder Team (teamnaam) heeft / van Trainer Team (teamnaam) heeft / van Speler Team (teamnaam) speelt in /van Klasse

Aanvoerder

Foutief!

heeft / van Trainer

en daar het hiernaast afgebeelde deel-conceptuele schema bij getekend werd, realiseerde de secretaris zich plotseling, dat een Aanvoerder óók een Speler (maar met een aparte rol binnen het Team waar hij/zij in speelt is) en dat een Trainer van een Team ook een Speler is, maar dan wel van een ander Team. Daarom werd besloten in de formulering van de verwoordingen expliciet op te nemen, dat ‘aanvoerder zijn’ een speciale relatie tussen Team en Speler is.

Team (teamnaam)

heeft / van Speler heeft / van Klasse speelt in / van

Foutief!

Let er wel op, dat in het algemeen geldt dat: objecten (dingen, personen of begrippen) worden niet samengevoegd wanneer deze objecten geen gemeenschappelijke eigenschappen hebben. Daarom moeten trainer, aanvoerder en speler in het informatie-structuurdiagram samen gevoegd worden tot één object, dat de naam speler heeft gekregen. Voorgaande verwoordingen werden daarom aangepast tot: Team (teamnaam) heeft / van Speler Speler aanvoerder van / met Team (teamnaam) Speler trainer van / met Team (teamnaam) Team (teamnaam) speelt in /van Klasse Speler heeft / van Voornaam Speler heeft / van Achternaam

Deze herziene formuleringen leiden tot het hiernaast getoonde deel-informatiestructuurdiagram:

Voornaam met / aanvoerder van Team (teamnaam)

heeft / van Speler

heeft / van

speelt in

Achternaam heeft / van

met / trainer van

/ van

Klasse

Gecorrigeerd CS:

‘aanvoerder’- en ‘trainer’- zijn betekent een speciale relatie tussen ‘Speler’ en ‘Team’.

DS-bijlagen B blz.6



De relaties tussen de gegevens op de spelerskaart zijn als volgt verwoord (voor zover het ‘nieuwe’, nog niet eerder genoemde relaties zijn): Speler is geboren op Datum Speler met / van Klasse Speler met / van Bondsnummer Speler woont op Adres Adres met / van Straat_nr Adres met / van Plaatsnaam

Het totale, samengestelde informatiestructuur-diagram is: Voornaam met / aanvoerder van Team (teamnaam)

heeft / van Speler

heeft / van

Achternaam heeft / van Straat_nr

speelt in

met / trainer van

/ van

Adres met

woont op

Plaatsnaam

/ van

met / van

met

Datum

/ van Klasse

met / van

Bondsnummer

is geboren op

N.B. De verenigingssecretaris stond erop het begrip (/objecttype) ‘Adres’ te gebruiken in zijn formulering. Dat is volgens hem een veelgebruikt begrip binnen de vereniging; kreten als ‘Geef me je adres even’ of ‘Mijn adres is veranderd’ vallen veelvuldig in de kantine.

Wedstrijdadministratie Navraag binnen de vereniging heeft het volgende opgeleverd: In de interne competitie speelt iedere deelnemende speler elke week een wedstrijd tegen een van de andere deelnemende spelers. Op het rooster van de interne competitie staat vermeld tegen welke speler er gespeeld moet worden. Op de verenigingsavond wordt steeds een rooster gehangen met de wedstrijden die op die avond gespeeld zullen worden. Op die lijst is ruimte opengehouden voor de uitslagen van de wedstrijden. Die uitslagen (bijvoorbeeld "10-0" of "1-2") kunnen door de spelers zelf worden ingevuld. Hieronder staat als voorbeeld zo'n (al deels ingevuld) rooster: ROOSTER 9 JUNI 2003 WEDSTRIJD

UITSLAG

J. Kraan - G. Pelt 3-5 M. Bastiaans - R. Voeten .. - .. ... Na afloop van de verenigingsavond neemt de secretaris de (ingevulde) lijst weer mee naar huis om de uitslagen te verwerken en de resultaten te berekenen. Iedere speler die die dag deel heeft genomen aan de competitie krijgt een nieuwe stand. Afhankelijk van de uitslag en de sterkte van de spelers krijgt de winnende speler er een aantal punten bij. De precieze manier waarop dit wordt berekend is hier niet van belang. De resultaten worden dan samengevoegd tot een standenlijst, bijvoorbeeld: RESULTATEN d.d. 9 JUNI 2003 SPELERS STANDEN J. Opheusden G. Pelt M. Bastiaans ...

402 pt 378 pt 378 pt

DS-bijlagen B blz.7

uit 11 wedstrijden uit 10 wedstrijden uit 11 wedstrijden



Het voorgaande maakt duidelijk welke gegevens bij de interne competitie een rol spelen. De belangrijkste objecttypen op het hoogste niveau zijn hier speler, wedstrijd, uitslag en stand. Wedstrijddatum en standdatum zijn beide datums; het gaat om twee objecten met dezelfde eigenschappen. Daarom worden deze objecten gezien als datums met dictincte relaties. Alhoewel een totaalscore ook een score is, kan een totaalscore veel groter worden dan een score. Om het beter zichtbaar te maken dat een score qua waarde (meestal tussen de 0 en de 10) een ander ‘verwachtings’gedrag heeft dan een (berekende) totaalscore (met veel hogere mogelijke waarden; zie voorbeeldtabel), worden deze objecttypen niet samengevoegd. Als verwoordingen van de in de rooster- en resultatenoverzichten weergegeven feiten zijn in overleg met de secretaris vastgesteld: Wedstrijd op/van Datum Wedstrijd met/van Speler

N.B. bij deze relatie gaf de secretaris aan, dat hier ook wel vaker een onderscheid wordt gemaakt tussen de 1e en de 2e speler. Daarom geven we ook: Wedstrijd met/van Speler als speler1 Wedstrijd met/van Speler als speler2 Wedstrijd met/van Uitslag Uitslag met/van Score (punten) als score1 Uitslag met/van Score (punten) als score2 Speler met/van Stand Stand op/van Datum Stand bij/met Aantal_Wedstrijden Stand bij/met Totaalscore (punten)

Het volgende informatie-structuurdiagram is het resultaat van onze formulieranalyse van de overzichten van de wedstrijdadministratie van de sportvereniging:

van /...met...als speler1 Speler

Wedstrijd van /...met...als speler2

met

van / met met

/ van

/ van

van / op Datum Uitslag op / van Stand

bij

bij

/ met

/ met

...met...als score1

...met...als score2

/ van

/ van

Score (punten) Aantal_Wedstrijden

Totaalscore (punten)

De informatieanalyse voor de inschrijfgegevens (competitie/toernooien) is in dit voorbeeld niet uitgewerkt.

DS-bijlagen B blz.8



Alternatieve oplossingen voor de realisatie Er zijn verschillende oplossingen mogelijk: 1 Er wordt niets geautomatiseerd, en alles blijft bij het oude. 2 Alleen de verenigingsadministratie worden geautomatiseerd. 3 Als 2, bovendien worden de functies voor de externe competitie en de externe toernooien geautomatiseerd. 4 Als 3, bovendien wordt ook de functie voor de interne competitie geautomatiseerd, waarmee ook de hoofdfunctie wedstrijdadministratie geautomatiseerd is. De functies die niet geautomatiseerd worden, moeten bij gebruik van het toekomstige informatiesysteem handmatig worden verricht.

Selectie systeemoplossing: te gebruiken criteria: - er moet snel iets gebeuren, want de secretaris houdt het niet lang meer vol met die drukte. - het project moet niet te omvangrijk worden (ook financieel niet!). De voorkeur wordt gegeven aan een aanpak waarin kleine succesjes worden geboekt, in plaats van in één klap alle problemen op te lossen.

Voorkeurs-systeemoplossing De voorkeur gaat uit naar oplossing 3 hierboven. Het automatiseren van de functie voor de interne competitie blijkt erg moeilijk te zijn, mede omdat de spelregels en puntentelling van de interne competitie regelmatig worden veranderd. Voorgesteld wordt een speciale interne wedstrijdsecretaris aan te stellen die deze taak van de secretaris overneemt. Deze kan gevonden worden onder de leden die de interne competitie precies bijhouden en die weten hoe het een en ander berekend moet worden. Later kan misschien gebruik worden gemaakt van de kennis die er in de vereniging is over het databasepakket om de functie toch nog te automatiseren. Omdat de functie voor de interne competitie redelijk los staat van de andere functies, is het niet bezwaarlijk dat er nu geen aandacht aan besteed wordt.

Raamwerk acceptatietest De bij de systeemeisen hiervoor genoemde functies zullen in de acceptatietest worden getest op juiste werking. Daartoe zullen de functies zowel apart als in samenhang met elkaar getest worden. De acceptatietest volgt op de onder verantwoordelijkheid van de ontwikkelaar(s) uit te voeren systeemtest. De procedure bij de acceptatietest is de volgende: De secretaris levert realistische testgegevens (de ledenopgave en teamindeling van vorig jaar, enkele toernooi-uitnodigingen en inschrijvingen van vorig jaar, etc.). Deze gegevens worden door de ontwikkelaars in het systeem ingebracht. Daarna worden alle functies zowel apart als in samenhang door de ontwikkelaars van het systeem getest; van het testen zal een protocol worden bijgehouden dat door de secretaris moet worden goedgekeurd. De secretaris ontvangt een exemplaar van het protocol. Let wel: De acceptatietest gebeurt onder verantwoordelijkheid van de opdrachtgever; deze kan over de uitvoering afspraken maken met de ontwikkelaar. De systeemtest gebeurt onder verantwoordelijkheid van de ontwikkelaar.

Systeemontwikkelingsplan De activiteiten van de projectgroep zullen zich in de volgende fasen van SDM volledig toespitsen op het ontwikkelen van het verenigingsadministratiesysteem. Helaas bestaat nog geen volledige duidelijkheid over de behoefte aan overzichten die elk van de hoofdfuncties moet kunnen produceren. De secretaris zal daarom op zéér korte termijn uitzoeken wat voor overzichten het systeem moet kunnen produceren. Hij zal ook de andere bestuursleden en de in de vereniging werkzame commissies (clubblad-commissie, feest-commissie enzovoort) vragen wat daar de behoeften zijn. Het is daarom mogelijk dat dit rapport definitiestudie in verband met die aanvullende wensen nog aangepast moet worden.

Einde UITTREKSEL Rapport Definitiestudie secretariaat sportvereniging

DS-bijlagen B blz.9



Bijlage DS - f) Vergelijking van geuite informatiewensen versus theoretisch mogelijke informatiefuncties van een te bouwen systeem Omdat het blijkbaar moeilijk is om de toekomst te voorspellen, is het vaak zinvol om bij de ontwikkeling van een informatiesysteem ons niet blind te staren op wat gebruikers en opdrachtgevers in eerste instantie aan informatiewensen 'uit hun mouw schudden', maar om aan de hand van een door ons voor de betreffende organisatie opgebouwd data-model, eens te kijken of welke (nog niet genoemde) aanvullende informatiefuncties gemakkelijk (tegen een 'relatief' lage prijs) bij het toekomstige informatiesysteem 'in te bouwen' zijn. Uiteraard moet daarna de opdrachtgever, mede aan de hand van een prijskaartje, een besluit nemen of zo'n extra functie(s) de moeite (lees: prijs) waard zijn. We gaan deze mogelijke aanvullingen dus opsporen via een confrontatie van gewenste functies en een (theoretisch) door ons ontwikkeld data-model (een soort theorie versus praktijk). Het gehanteerde basisprincipe bij deze confrontatie is: (deel)functies kunnen: - ofwel gegevens die bij de objecten horen, veranderen (toevoegen, verwijderen of muteren), - ofwel door middel van bij de objecten horende gegevens, informatie geven over deze objecten en hun onderlinge relaties. Uit een opgesteld informatie-structuurdiagram kunnen wij aflezen welke functies mogelijk zijn. Of zulke mogelijke functies ook zinvol zijn is uiteraard een tweede. Als gulden regel hanteren we, dat meestal alleen theoretisch mogelijke functies met manipulatie van gegevens van objecten op het hoogste of het bijna hoogste niveau de moeite van het verder bekijken waard zijn.

We zullen deze gedachte uitwerken aan de hand van ons:

Voorbeeld:

factureringsafdeling

Uit de daarbij behorende probleembeschrijving en het opgestelde SADT-diagram van dit voorbeeld weten we, dat voor de afdeling de hoofdobjecten zijn: factuur, klant en adres. Op de gegevens van deze hoofdobjecten opereren de aangegeven hoofdfuncties factureren en verzenden. Deze hoofdfuncties zijn vanuit de informatiewensen verfijnd in deelfuncties zoals '. factuur toevoegen' of: '.muteer klant'. Wij gaan nu vanuit het data-model inventariseren welke functies in deze verfijning een rol kùnnen spelen.

a) Mogelijke verfijningen van de hoofdfunctie factureren De hoofdfunctie factureren werkt op factuurgegevens. Met deze gegevens hangen de volgende objecten en hun relaties samen, die terug te vinden zijn in het bovenste deel van het informatie-structuurdiagram dat in activiteit 1.5 (Het systeemconcept: de gegevens) gemaakt is (we gebruiken hier een oudere, ‘variant versie’):

DS-bijlagen B blz.10


artikel


bedrag

van voor

datum

van met

van

van op

met

factuur

klant Hoofdfunctie factureren met van

adres

met in

straat

met in

met in

huis

postcode

met in

woonplaats

N.B. Dit is een (oudere) ‘variant versie’ van het informatie-structuurdiagram!

We werken nu dus expliciet met de belangrijkste objecten (‘van de bovenste niveaus’) en impliciet met de objecten en gegevens die daaronder liggen. De deelfuncties binnen de hoofdfunctie factureren werken dus op de objecten klant en factuur. Uit dat deel van het informatie-structuurdiagram kunnen we aflezen dat de volgende functies 'interessant' zijn: functies betreffende factuur: - factuur veranderen: - informatie over factuur . factuur toevoegen . factuur verwijderen . factuur muteren functies betreffende klant: - klant veranderen: . klant toevoegen . klant verwijderen . klant muteren

- informatie over klant

Verder zien wij uit het informatie-structuurdiagram dat de volgende informatieve functies zinvol kunnen zijn: informatieve functies betreffende de relatie tussen factuur en klant: - informatie over factuur van klant - informatie over klant met factuur informatieve functies betreffende de relatie tussen factuur, klant en adres: - informatie over factuur van klant met adres - informatie over adres van klant met factuur




b) Mogelijke verfijningen van de hoofdfunctie verzenden De hoofdfunctie 'verzenden' werkt op verzendgegevens. Met deze gegevens hangen de volgende objecten en hun relaties samen, die beschreven zijn in het onderste deel van het gemaakte informatie-structuurdiagram (met hier weer een oude/variant versie ervan):

artikel

bedrag

van voor

datum

van met

van op

Hoofdfunctie van

met

factuur

verzenden

klant

met van

adres

met in

straat

met in

huis

met in

postcode

met in

woonplaats

N.B. Ook dit is weer een oudere, ‘variant versie’ van het informatie-structuurdiagram!

Uit dit deel van het informatie-structuurdiagram kunnen wij aflezen dat de volgende functies 'interessant' kunnen zijn: functies betreffende klant: - klant veranderen: . klant toevoegen . klant verwijderen . klant muteren functies betreffende adres: - adres veranderen: . adres toevoegen . adres verwijderen . adres muteren

- informatie over klant

- informatie over adres

N.B. Deze functies betreffende ‘Adres’ zijn in principe alle mogelijk, maar weinig zinvol, omdat we een adres steeds in combinatie met de gegevens van de betreffende klant willen zien, zodat we bij een functie ‘klant veranderen’ ook het bijbehorende adres kunnen veranderen.

Verder zien wij uit het diagram dat de volgende informatieve functies zinvol zouden kunnen zijn:




informatieve functies betreffende de relatie tussen klant en adres: - informatie over adres van klant - informatie over klant met adres informatieve functies betreffende de relatie tussen klant, adres en factuur: - informatie over factuur van klant met adres - informatie over adres van klant met factuur

c) Vergelijkende analyse Hiervóór hebben wij, uitgaande van ons data-model, rücksichtslos geïnventariseerd welke functies binnen de hoofdfuncties factureren en verzenden mogelijk zouden zijn. Deze inventarisatie maakt duidelijk wat je op je klompen kon aanvoelen: er treedt overlap op en er komen functies tevoorschijn die voor de betreffende organisatie weinig zinvol zijn. Zowel die overlap als die zinloze functies moeten wij kwijt. We (en vooral onze opdrachtgever) zullen keuzes moeten maken. N.B.

Pas in de volgende SDM-fase (Basisontwerp) gaan we ons in activiteit 2.4 wijden aan de precieze indeling/groepering van de diverse functies!

Wij krijgen als een voorlopig overzicht (zonder overlap) van mogelijke functies: - factuur veranderen: . factuur toevoegen (al bekend) . factuur verwijderen (al bekend) . factuur muteren (al bekend)

- informatie over factuur

- klant veranderen: . klant toevoegen . klant verwijderen . klant muteren

- informatie over klant (al bekend)

- adres veranderen: N.B.

(al bekend) (al bekend) (niet nodig)

- informatie over adres

Al eerder stelden we dat adreswijzigingen kunnen worden doorgevoerd via de '. Muteer klant' -mogelijkheid, die we toe kunnen laten grijpen op de 'onder' klant vallende objectgegevens.

'Grensoverschrijdende' informatieve functies: - informatieve functies betreffende de relatie tussen factuur en klant: - informatie over factuur van klant (al bekend) - informatie over klant met factuur - informatieve functies betreffende de relatie tussen klant en adres: - informatie over adres van klant (al bekend) - informatie over klant met adres - informatieve functies betreffende de relatie tussen factuur, klant en adres: - informatie over factuur van klant met adres - informatie over adres van klant met factuur Als we ons (uiteraard in overleg met de opdrachtgever!) afvragen of de nog niet bekende nieuwe functies wel zinvol zijn, dan kan daar bijvoorbeeld als resultaat uit komen, dat (naast de al bekende functies) bij de verdere systeemontwikkeling ook worden meegenomen: - informatie over klant met factuur

(het lijkt zinvol om via een factuurnummer de naam + adres van een klant op te laten zoeken)

Via onze inventarisatie vanuit het data-model zijn we er dus in geslaagd om een zinvolle extra functies te ontdekken; een hiermee uitgerust informatiesysteem is waarschijnlijk beter op in de toekomst gevoelde nieuwe informatiewensen voorbereid!




Merk op dat onze analysewerkzaamheden dus geleid hebben tot een bijstelling van de aan het informatiesysteem gestelde eisen (en dientengevolge tot bijstelling van het ontwerp): de gewenste informatievoorziening omvat nu niet meer puur de automatisering van de bestaande situatie. Gewenst wordt: - aan kunnen brengen van binnengekomen factuurgegevens op een factuur met een uniek volgnummer, een kopiefactuur kunnen archiveren, - informatie kunnen verstrekken over facturen en klanten, - de factuur kunnen voorzien van verzendgegevens (zodat deze daarna in een vensterenvelop verzonden kan worden), - de verzendgegevens kunnen bijwerken op grond van binnengekomen aanvullingen en veranderingen, - informatie kunnen verstrekken over klanten en adressen.

Al eerder zeiden we als gulden regel te hanteren, dat meestal alleen theoretisch mogelijke functies met manipulatie van gegevens van objecten op het hoogste of het bijna hoogste niveau de moeite van het verder bekijken waard zijn. Het loont vaak echter ook de moeite om onze blik wat verder 'af te laten dalen' naar lagere niveaus. Zo kunnen informatiefuncties met betrekking tot woonplaats en/of postcode erg handig zijn (denk b.v. aan het op het postkantoor gesorteerd op postcode afleveren van een mailing ).




Bijlage DS - g ) FunctiePunt-Analyse (FPA) Het maken van een realistische schatting (begroting) van hoeveel de kosten voor het ontwikkelen van een informatiesysteem zullen bedragen, is vaak een groot probleem. De tijd, dat door systeemontwikkelaars ongestraft beweerd kon worden, dat het voor zo'n creatief ontwikkelingsproces onmogelijk was om zelfs maar een zeer ruwe kostenraming te maken, is toch echt voorbij. We geven direct toe, dat de bedachte kostenramingsmethoden zeker geen nauwkeurige resultaten opleveren. Meestal geldt echter dat we beter een ruwe schatting dan helemaal géén schatting kunnen hebben. Een niet alleen in Nederland, maar ook in het buitenland tegenwoordig veel gebruikte methode voor het begroten van die kosten is de zogenaamde FunctiePunt-Analyse (FPA-) methode. Bij deze methode gaat men er van uit, dat het ontwikkelen van elk functioneel onderdeel van een informatiesysteem een bepaalde tijdsinvestering kost, die (gemiddeld, ruwweg en vooral ) bepaald wordt door het soort functionaliteit (zoals invoer of uitvoer van gegevens). De FPA-methode houdt daarom op hoofdlijnen in, dat voor het te ontwikkelen informatiesysteem wordt bepaald welke functies het moet kunnen vervullen en hoeveel functiepunten er aan elke gewenste functie moet worden toegekend. Een geschikt moment om FPA toe te passen is dus tijdens de Definitiestudie als de gebruikerswensen reeds bekend zijn. Het totaal aan functiepunten voor het gehele systeem biedt een mogelijkheid voor het berekenen van de tijd die het zal gaan kosten om het systeem te ontwikkelen. Nodig is dan nog een verband tussen aantal functiepunten en aantal benodigde arbeidsuren. Dat verband wordt meestal empirisch bepaald uit gemeten waarden bij vorige ontwikkelprojecten en waarmee een productiviteitscijfer is bepaald (aantal uren per functiepunt). We geven hier eerst schetsmatig een overzicht van de oorspronkelijke FPA-methode en bekijken daarna een aanpassing (de IFPA-methode).

a) de FPA-methode: (schetsmatig) bestanden

invoerfuncties

uitvoerfuncties

bepaal aantal bruto functiepunten 14 factoren

opvragingsfuncties bepaal aantal netto functiepunten koppelingen produktiviteitscijfer

bepaal aantal uren

Knelpunten: - bij de 'definitiestudie' weet je nog niet hoeveel 'fysieke gegevensbestanden' uiteindelijk gebruikt gaan worden; - bij de '14 factoren' die bekeken moeten worden, zitten zowel factoren die 'altijd' binnen een bepaalde organisatie gelden, als factoren die specifiek voor dit te bouwen informatiesysteem gelden.




N.B. Zowel bij de FPA- als de hierna te bespreken IFPA-methode geldt, dat we als het ware alleen de oorspronkelijke algoritmiek moeten beoordelen (het slechts kopiëren van programma-delen kost beslist niet zoveel tijd als het oorspronkelijk uitdenken van zo'n onderdeel). We mogen gebruikersfuncties dus alleen (volledig) meetellen, als ze duidelijk afwijkend van andere functies zijn (als dus een functie 'toevoegen' en een functie 'edit' qua beeldscherm-opbouw e.d. gelijk zijn, dan mag je dus die tweede functie niet (of niet volledig) mee tellen!

b) de IFPA-methode (Interprogram FPA): Een in Nederland gebruikte variant op boven beschreven FPA-methode is de IFPA-methode (Interprogram FPA). Die methode is schematisch de volgende:

logische gegevensverzamelingen

invoerfuncties

uitvoerfuncties

bepaal aantal functiepunten produktiviteitscijfer

opvragingsfuncties bepaal aantal bruto-uren koppelingen

eventuele correctiefactor

bepaal aantal netto-uren

b.1) Algemene opmerkingen bij het toepassen van de IFPA-methode: Logische gegevensverzamelingen zijn die gegevensverzamelingen die als entiteit (minstens in de zogenaamde 3N- (3º-normaal-) vorm) in het logische datamodel zijn opgenomen. Het productiviteitscijfer is (vooral) afhankelijk van: ontwikkeltaal (vooral: 4GL, 3GL+procedureel, 3GL-niet-proc.) hardware (b.v. pc, mini, mainframe) DBMS (het gebruikte databasemanagementsysteem) hulpmiddelen (b.v. screen-designer) complexiteit fase (b.v. specificatiefase, realisatiefase) Bij IFPA mogen bij de correctiefactoren alléén factoren worden meegenomen, die voor het onderhavige project gelden (dus géén algemene factoren over b.v. het softwarebedrijf; zulke factoren zitten bij het productiviteitscijfer ).




b.2) IFPA -beoordelingsmatrices: Hulpmatrix logische gegevensverzamelingen

aantal velden

1-10

waardering

4

11-25

aantal benaderde gegevensverzam.

10

7 aantal velden 5-15

1-4 Hulpmatrix invoerfunctie

> 25

> 15

1

3

2 >2

3

3 4

4 6

4

6

6

aantal velden 1-5 Hulpmatrix uitvoerfunctie

aantal benaderde gegevensverzam.

> 19

6-19

5

4

4 5

5

7

7

1

4

2-3 >3

7

aantal velden Hulpmatrix opvragingsfunctie

Hulpmatrix koppeling

2-3

3

4

> 19 4 6

>3

4

6

6

1 aantal benaderde gegevensverzam.

aantal velden waardering

1-5 3

1-10 4

6-19 3

11-25 7

> 25 10

De IFPA-waardering voor 'ondersteunende functies' is: - foutmeldingen: worden gelet de gelijkvormigheid als één uitvoerfunctie geteld, met het minimum aantal functiepunten (4 p); - help-schermen: worden indien ze functioneel op dezelfde wijze tot stand komen, slechts éénmaal als uitvoerfunctie geteld (4 p); - menustructuur: wordt als één (minimale) uitvoerfunctie geteld (4 p).

b.3) Het productiviteitscijfer: Bij b.1) werd al opgemerkt, dat het productiviteitscijfer (aantal benodigde uren per functiepunt) afhankelijk is van een aantal project-afhankelijke factoren zoals de gebruikte programmeertaal, het wel/niet gebruiken van ontwikkeltools, de hardware waar het informatiesysteem voor ontwikkeld wordt, het gebruik van een kanten-klaar databasemanagementsysteem en de complexiteit van het systeem (bijvoorbeeld een min of meer 'standaard' administratief systeem of een technisch-wetenschappelijk systeem met gecompliceerde berekeningen ...). Desgewenst kan (ervaringsgewijs) ook een raming worden gegeven hoeveel tijd/inspanning een bepaalde fase van de systeemontwikkeling zal kosten (b.v. hoeveel tijd kost het maken van het Basisontwerp, de Realisatiefase, etc.). Om je een beetje een idee te geven van wat er in de praktijk gebeurt, geven we hier wat getallen met laagste en hoogste 'grenswaarden' voor dat productiviteitscijfer (uit: 'Inleiding Technieken Informatiesystemen' door F. Pottjegort, CAP Gemini Publishing, appendix C). In de werkelijkheid moet je dus aan de hand van ervaringscijfers van je eigen organisatie je productiviteitscijfer moeten bepalen!



Programmeertaal

Gebruik Hardhulpware middelen

4 GL

ja

micro


Complexiteit

Omvang systeem in functiept.

prod. cijfer van

prod. cijfer tot

normaal

< 500 fp 500 - 1500 fp 1500 - 2500 fp 2500 - 3500 fp > 3500 fp < 500 fp 500 - 1500 fp ..... < 500 fp ..... > 3500 fp < 500 fp 500 - 1500 fp ..... < 500 fp .....

1.9 2.2 2.4 2.6 3.0 2.1 2.4

3.2 3.6 4.0 4.3 5.0 3.6 4.0

2.5

4.2

3.9 2.4 2.7

6.6 4.1 4.5

2.7

4.5

groot

extreem

mini

normaal

mainframe normaal

4 GL

nee

micro

normaal

< 500 fp 500 - 1500 fp .....

2.8 3.1

4.7 5.2

3 GL proc's

ja

micro

normaal

3.9 4.3

5.2 5.8

3 GL proc's

nee

micro

normaal

5.6 6.2

7.5 8.3

3 GL n.proc's

ja

micro

normaal

4.5 5.0

5.8 6.5

3 GL n.proc's

nee

micro

normaal

< 500 fp 500 - 1500 fp ..... < 500 fp 500 - 1500 fp ..... < 500 fp 500 - 1500 fp ..... < 500 fp 500 - 1500 fp .....

6.6 7.3

8.4 9.4

nee

mainframe extreem

> 3500 fp

18.2

23.4

en extreem: 3 GL n.proc's

Uit dit overzicht komt overduidelijk de verwachte conclusie tevoorschijn, dat je bij een 4GL-systeem (SQL + ...) met gebruik van allerlei tools je in de minst complexe situatie (voor pc's) je de hoogste productiviteit (d.w.z. het laagste benodigd aantal uren per functiepunt) kunt behalen.

c) Andere 'evaluatie'-methodes FunctiePunt-Analyse (met zijn dialecten) is een internationaal veel gebruikte techniek om de ontwikkelkosten voor een te bouwen informatiesysteem te schatten. Daarnaast bestaan er 'uiteraard' allerlei andere bedachte methoden; elk met eigen sterke en zwakke kanten. We noemen slechts een paar namen: 'Information Economics (IE)', 'Kosten en Baten Automatiseringsprojecten (KBA)' en 'Informatieverwerkingscapaciteit (IVC)'. Als je later terechtkomt in een situatie waarin je zulke methoden nodig hebt, is het zeer zeker de moeite waard om een up-to-date vergelijking tussen deze (en nog andere) methoden op te sporen en een of meer van deze methodes in detail te bestuderen.




d) Voorbeeld kostenschatting volgens de FunctiePunt-Analyse: de factureringsafdeling We maken hier een eerste ruwe kostenschatting van wat het ontwikkelen (ontwerpen+implementeren) van het gewenste informatiesysteem voor de factureringsafdeling zou gaan kosten. We gaan daarbij uit van de volgende gewenste functies/functionaliteit (zie definitiestudierapport van bijlage DS-b): . Voeg toe factuur van klant invoerfunctie . Toon facturen van klant uitvoerfunctie . Verwijder factuur van klant opvragingsfunctie . Muteer factuur van klant invoerfunctie . Druk af factuur van klant \ en: adres van klant uitvoerfunctie . Voeg toe klant invoerfunctie . Toon klant opvragingsfunctie . Muteer klant invoerfunctie We gaan er (voorlopig) van uit, dat ze allemaal 'aparte' algoritmen vereisen (omdat we geen zelfde 'denkwerk' dubbel mogen tellen). Bovendien gaan we voor het bepalen van het benodigde 'aantal velden' bij de invoer/uitvoer/opvragingsfuncties uit van de momenteel in de organisatie gebruikte formulieren (zie eerder in dit hoofdstuk, bij bijlage DS-a).

FPA-beoordeling I) logische gegevensverzamelingen: we verwachten er momenteel 2 (over klanten en over facturen), met elk een vrij beperkt (1-10) aantal velden. Bijdrage aan totaal aantal functiepunten: 2 (verzamelingen) * 4 (waardering) = 8 fp II) invoerfuncties: . Voeg toe factuur van klant . Muteer factuur van klant . Voeg toe klant . Muteer klant

invoerfunctie invoerfunctie invoerfunctie invoerfunctie

III) uitvoerfuncties: . Druk af factuur van klant en: adres van klant . Toon facturen van klant Ook:

foutmeldingen menustructuur

IV) opvragingsfuncties: . Verwijder factuur van klant . Toon klant V) koppelingen (met andere systemen):

\ -

(met 5 velden; 2 verz) (met 5 velden; 2 verz) (met 6 velden; 1 verz) (met 6 velden; 1 verz)

= = = =

4 fpt 4 fpt 3 fpt 3 fpt

uitvoerfunctie (met 10 velden; 2 verz) = 5 fpt uitvoerfunctie (met 5 velden; 1 verz) = 4 fpt

tellen als 1 minimale uitvoerfunctie) tellen als 1 minimale uitvoerfunctie)

opvragingsfunctie (5 velden; 1 verz) opvragingsfunctie (5 velden; 1 verz)

= 4 fpt = 4 fpt

= 3 fpt = 3 fpt

niet aanwezig Totaal aantal functiepunten:

= 45 fpt

Indien we het systeem ontwikkelen en realiseren met 4GL + hulpmiddelen voor een pc en we (ervaringsgewijs van ons team) een productiviteitscijfer van 2,5 uur per functiepunt hanteren, komen we in totaal uit op 113 uur als benodigde (geschatte) ontwikkeltijd voor het systeem. De offerteprijs voor de systeemontwikkeling kan hierop bepaald worden. (Let op: voor de systeemontwikkeling; daarbij zitten dus niet de kosten voor hardware, besturingssysteem, invoeren of conversie van gegevens e.d.) In onderling overleg kan bekeken worden of bepaalde functies samengevoegd kunnen worden (b.v. ‘voegtoe klant’, ‘muteer klant’ en ‘toon klant’ die zeer waarschijnlijk voor een groot deel wél eenzelfde ‘denkwerk’ vereisen), waardoor het aantal functiepunten en daarmee een daarop gebaseerde offerteprijs verlaagd kan worden.


Secretariaat Sportvereniging: rapport Definitiestudie

Recommend Documents