Secretariaat Sportvereniging: rapport Definitiestudie

Transcriptie

1 Bijlage DS-e) Secretariaat Sportvereniging: rapport Definitiestudie (UITTREKSEL) Dit rapport beperkt zich niet tot alleen de resultaten de activiteiten 1.2, 1.3 en 1.5. Uitgangspunten <niet volledig uitgewerkt> 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 aanpak <hier niet uitgewerkt; dat moet jezelf beslist wèl doen!> Gewenste informatievoorziening De leden, secretaris en andere bestuursleden gehouden interviews leveren bij analyse de volgende informatie over de gewenste informatievoorziening: - Door leden de vereniging gewenste informatievoorziening. Niet opnieuw aanleveren gegevens voor verlenging het lidmaatschap de vereniging en eventueel ook voor aanmelding bij en verlenging het lidmaatschap de bond.. Mogelijkheid om op clubavonden het bondsnummer te weten te komen.. De stand de interne competitie iedere week bijgewerkt. - Door de secretaris gewenste informatievoorziening. Naam, het adres en de geboortedatum de spelers administreren pasfoto, naam het team en de klasse waarin de speler speelt (dit is de klasse dat team).. De bondsnummers de spelers administreren.. De teamgegevens administreren, dat wil zeggen: naam het team, klasse, naam de trainer(s), naam de aanvoerder en namen de overige spelers.. Lidmaatschapskaart persoonsgegevens produceren ( pasfoto).. Verlengingslijst bondslidmaatschappen spelersnaam en bondsnummer.. Inschrijflijst extern toernooi de bondsnummers de spelers gecontroleerd.. Stand de interne competitie.. Aanmelding teams voor de externe competitie.. Bijwerken teamadministratie en spelersadministratie op grond promoveren of degraderen.. Bijwerken teamadministratie nieuwe trainers, ander aanvoerderschap een team, spelerswisselingen, etc.. Bijwerken spelersadministratie op grond vertrek, adreswijzigingen, teamwijzigingen, klassewijzigingen, etc. - Door de bestuursleden gewenste informatievoorziening. Informatie over de stand de interne competitie.. Spelersgegevens inclusief bondsnummers, teamgegevens.. Informatie over aanvoerders en trainers.. Informatie over de externe toernooien.. Adresetiketten de spelers. Wanneer de hiervoor weergegeven wensen ten aanzien 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 de secretaris grotendeels worden geautomatiseerd. Verder moet de informatievoorziening nog aan de volgende - reeds in het rapport informatieplanning opgenomen - criteria voldoen: De duurzaamheid het te ontwikkelen informatiesysteem is kritisch. Voor de invoering een geautomatiseerd informatiesysteem binnen de sportvereniging moeten naar verhouding grote investeringen DS-bijlagen B blz.1

2 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 het systeem is kritisch. De functie secretaris wordt door vrijwilligers vervuld die door de ledenraad gekozen worden. De personele invulling 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 de nieuwe secretaris in het gebruik het informatiesysteem. Een nieuwe secretaris (of ook een invaller bij ziekte) moet snel het informatiesysteem kunnen werken. Op grond de (bij activiteit 1.5.c) uitgevoerde informatieanalyse is aan de gewenste informatievoorziening een concrete vertaling gegeven. De concrete informatie-, toevoeg-, verwijder- en mutatiefuncties zijn aan leden, secretaris en andere bestuursleden voorgelegd. De concrete vertaling de informatiebehoefte in functies die hieronder staat is in samenspraak deze personen tot stand gekomen. Hieronder zijn slechts twee voorbeelden zo'n concrete vertaling uitgewerkt; het rapport definitiestudie dient de uitwerking alle functies te bevatten.. Informatie over de stand de interne competitie - Toon resultaat speler op standdatum - Toon resultaten alle spelers op standdatum op alfabetische spelervolgorde - Toon resultaten alle spelers op standdatum op standvolgorde - Toon resultaten speler op volgorde standdatum - Toon resultaten alle spelers op volgorde standdatum - Toon wedstrijden uitslag speler - Toon wedstrijden uitslag alle spelers op alfabetische spelervolgorde - Toon wedstrijden uitslag op wedstrijddatum - Toon alle wedstrijden uitslag op volgorde wedstrijddatum. Informatie over aanvoerders en trainers - Toon teams klasse speler die aanvoerder is, op team- en klassevolgorde - Toon teams klasse speler(s) die trainer is (zijn), op team- en klassevolgorde - Toon speler die aanvoerder is team - Toon speler(s) die trainer is (zijn) team - Toon spelers die aanvoerder zijn, teams op spelersvolgorde - Toon spelers die trainer zijn, teams op spelersvolgorde Commentaar De concrete invulling de informatiebehoefte kan als volgt de betrokken personen besproken worden. Als uitgangspunt dient steeds een bestaande informatievraag betrokkene die vertaald wordt in termen de objecten uit de informatieanalyse. Hieronder staan een paar voorbeelden waarin, uitgaande enkele veel voorkomende informatievragen, de vertaling in twee stappen plaatsvindt.. Informatie over aanvoerders en trainers - "Wie is de aanvoerder het eerste herenteam?" TOON naam SPELER die aanvoerder is TEAM "Heren 1" Toon speler die aanvoerder is team. Spelersgegevens - "Welke spelers spelen er in het eerste herenteam?" TOON naam SPELER(s) TEAM "Heren 1" Toon spelers team - "Welke spelers spelen er in de derde klasse?" TOON naam SPELER(s) KLASSE "3" Toon spelers klasse - "In welk team speelt Bert Dijkmeester?" DS-bijlagen B blz.2

3 TOON naam TEAM SPELER "Dijkmeester, Bert" Toon team speler Veranderingsbehoefte en systeemeisen Veranderingsbehoefte Bij gebruik het nieuwe informatiesysteem moet het niet langer nodig zijn gegevens meerdere malen in te voeren of te veranderen. Bij het veranderen de klasse een team moet bijvoorbeeld ook automatisch de klasse de spelers dat team worden veranderd. De lidmaatschapskaart een lid moet ' een druk op de knop' vervaardigd kunnen worden; alleen de pasfoto moet nog de hand worden opgeplakt. Spelersgegevens, teamgegevens etc. moeten snel opvraagbaar zijn. Verder moeten diverse overzichten, waaronder inschrijflijsten, aanmeldingslijsten, overzicht de interne competitie, adressen op labels ' 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:. alle leden bondsnummer. bepaalde leden (bijvoorbeeld een team). alle teams. bepaalde teams (bijvoorbeeld alle teams in de 1e klasse). alle aanvoerders teams. alle trainers teams - etiketten te maken de adressen alle spelers - etiketten te maken de adressen bepaalde spelers (bijvoorbeeld een team) - lidmaatschapskaarten te maken - inschrijflijsten voor externe toernooien te maken - inschrijflijsten voor de bond (externe competitie) te maken - de uitslagen 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

4 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. inschrijfgegevens inschr.bond overz.spel.geg. adreswijzigingen overz.team.geg. mededelingen verenigingsadministratie spelersgegevens teamgegevens opgave spelers interne comp./ externe toern. inschrijving externe competitie spelersgegevens teamgegevens gegevensbank inschr.ext.comp. inschr.ext.toer. uitnodigingen comp.lijst uitslagen wedstrijdadministratie standenlijst inschrijfgegevens comp.geg. standengegevens spelersgegevens teamgegevens inschrijfgegevens competitiegegevens standengegevens DS-bijlagen B blz.4

5 Systeemconcept : B) de interacties Verenigingsadministratie besturingsinteracties. spelers- of team-toevoeging/mutatie/verwijdering. informatievraag grondstofinteracties. gegevens 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 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

6 De informatieanalyse wordt op grond deze gegevens uitgevoerd. In verband 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 de gegevens behorende bij de hoofdfunctie verenigingsadministratie (teamgegevens en spelersgegevens): Toen in overleg de verenigingssecretaris de relaties tussen de gegevens op de teamkaart in eerste instantie [abusievelijk] als volgt verwoord werden: Team (teamnaam) heeft / Aanvoerder Aanvoerder Team (teamnaam) heeft / Trainer Foutief! heeft / Team (teamnaam) heeft / Speler Team (teamnaam) speelt in / Klasse en daar het hiernaast afgebeelde deel-conceptuele schema bij getekend werd, realiseerde de secretaris zich plotseling, dat een Aanvoerder óók een Speler (maar een aparte rol binnen het Team waar hij/zij in speelt is) en dat een Trainer een Team ook een Speler is, maar dan wel een ander Team. Daarom werd besloten in de formulering de verwoordingen expliciet op te nemen, dat aanvoerder zijn een speciale relatie tussen Team en Speler is. 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 / Speler Speler aanvoerder / Team (teamnaam) Speler trainer / Team (teamnaam) Team (teamnaam) speelt in / Klasse Speler heeft / Voornaam Speler heeft / Achternaam Team (teamnaam) heeft / heeft / speelt in / Foutief! Trainer Speler Klasse Deze herziene formuleringen leiden tot het hiernaast getoonde deel-informatiestructuurdiagram: Team (teamnaam) heeft / / aanvoerder Speler heeft / heeft / Voornaam Achternaam speelt in / / trainer Klasse Gecorrigeerd CS: aanvoerder - en trainer - zijn betekent een speciale relatie tussen Speler en Team. DS-bijlagen B blz.6

7 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 / Klasse Speler / Bondsnummer Speler woont op Adres Adres / Straat_nr Adres / Plaatsnaam Het totale, samengestelde informatiestructuur-diagram is: Voornaam / aanvoerder heeft / Team (teamnaam) heeft / Speler heeft / Achternaam Straat_nr speelt in / / trainer / Klasse / Bondsnummer woont op is geboren op Adres Datum / / Plaatsnaam 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 de andere deelnemende spelers. Op het rooster de interne competitie staat vermeld tegen welke speler er gespeeld moet worden. Op de verenigingsavond wordt steeds een rooster gehangen de wedstrijden die op die avond gespeeld zullen worden. Op die lijst is ruimte opengehouden voor de uitslagen 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 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 de uitslag en de sterkte de spelers krijgt de winnende speler er een aantal punten bij. De precieze manier waarop dit wordt berekend is hier niet belang. De resultaten worden dan samengevoegd tot een standenlijst, bijvoorbeeld: RESULTATEN d.d. 9 JUNI 2003 SPELERS STANDEN J. Opheusden 402 pt uit 11 wedstrijden G. Pelt 378 pt uit 10 wedstrijden M. Bastiaans 378 pt uit 11 wedstrijden... DS-bijlagen B blz.7

8 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 dezelfde eigenschappen. Daarom worden deze objecten gezien als datums 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 ( veel hogere mogelijke waarden; zie voorbeeldtabel), worden deze objecttypen niet samengevoegd. Als verwoordingen de in de rooster- en resultatenoverzichten weergegeven feiten zijn in overleg de secretaris vastgesteld: Wedstrijd op/ Datum Wedstrijd / Speler N.B. bij deze relatie gaf de secretaris aan, dat hier ook wel vaker een onderscheid wordt gemaakt tussen de 1 e en de 2 e speler. Daarom geven we ook: Wedstrijd / Speler als speler1 Wedstrijd / Speler als speler2 Wedstrijd / Uitslag Uitslag / Score (punten) als score1 Uitslag / Score (punten) als score2 Speler / Stand Stand op/ Datum Stand bij/ Aantal_Wedstrijden Stand bij/ Totaalscore (punten) Het volgende informatie-structuurdiagram is het resultaat onze formulieranalyse de overzichten de wedstrijdadministratie de sportvereniging: /...als speler1 Speler Wedstrijd /...als speler2 / / / Datum / op Uitslag op / Stand...als score1...als score2 bij bij / / / / Score (punten) Aantal_Wedstrijden Totaalscore (punten) De informatieanalyse voor de inschrijfgegevens (competitie/toernooien) is in dit voorbeeld niet uitgewerkt. DS-bijlagen B blz.8

9 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 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 die drukte. - het project moet niet te omgrijk worden (ook financieel niet!). De voorkeur wordt gegeven aan een aanpak waarin kleine succesjes worden geboekt, in plaats in één klap alle problemen op te lossen. Voorkeurs-systeemoplossing De voorkeur gaat uit naar oplossing 3 hierboven. Het automatiseren de functie voor de interne competitie blijkt erg moeilijk te zijn, mede omdat de spelregels en puntentelling de interne competitie regelmatig worden veranderd. Voorgesteld wordt een speciale interne wedstrijdsecretaris aan te stellen die deze taak 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 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 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 elkaar getest worden. De acceptatietest volgt op de onder verantwoordelijkheid de ontwikkelaar(s) uit te voeren systeemtest. De procedure bij de acceptatietest is de volgende: De secretaris levert realistische testgegevens (de ledenopgave en teamindeling vorig jaar, enkele toernooi-uitnodigingen en inschrijvingen 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 het systeem getest; het testen zal een protocol worden bijgehouden dat door de secretaris moet worden goedgekeurd. De secretaris ontgt een exemplaar het protocol. Let wel: De acceptatietest gebeurt onder verantwoordelijkheid de opdrachtgever; deze kan over de uitvoering afspraken maken de ontwikkelaar. De systeemtest gebeurt onder verantwoordelijkheid de ontwikkelaar. Systeemontwikkelingsplan De activiteiten de projectgroep zullen zich in de volgende fasen SDM volledig toespitsen op het ontwikkelen het verenigingsadministratiesysteem. Helaas bestaat nog geen volledige duidelijkheid over de behoefte aan overzichten die elk 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 die aanvullende wensen nog aangepast moet worden. Einde UITTREKSEL Rapport Definitiestudie secretariaat sportvereniging DS-bijlagen B blz.9

10 Bijlage DS - f) Vergelijking geuite informatiewensen versus theoretisch mogelijke informatiefuncties een te bouwen systeem Omdat het blijkbaar moeilijk is om de toekomst te voorspellen, is het vaak zinvol om bij de ontwikkeling 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 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 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 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 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 manipulatie gegevens objecten op het hoogste of het bijna hoogste niveau de moeite het verder bekijken waard zijn. We zullen deze gedachte uitwerken aan de hand ons: Voorbeeld: factureringsafdeling Uit de daarbij behorende probleembeschrijving en het opgestelde SADT-diagram dit voorbeeld weten we, dat voor de afdeling de hoofdobjecten zijn: factuur, klant en adres. Op de gegevens deze hoofdobjecten opereren de aangegeven hoofdfuncties factureren en verzenden. Deze hoofdfuncties zijn uit de informatiewensen verfijnd in deelfuncties zoals '. factuur toevoegen' of: '.muteer klant'. Wij gaan nu uit het data-model inventariseren welke functies in deze verfijning een rol kùnnen spelen. a) Mogelijke verfijningen 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 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

11 artikel bedrag datum voor op factuur klant Hoofdfunctie factureren adres in in in in straat huis postcode woonplaats N.B. Dit is een (oudere) variant versie het informatie-structuurdiagram! We werken nu dus expliciet de belangrijkste objecten ( de bovenste niveaus ) en impliciet de objecten en gegevens die daaronder liggen. De deelfuncties binnen de hoofdfunctie factureren werken dus op de objecten klant en factuur. Uit dat deel 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: - informatie over klant. klant toevoegen. klant verwijderen. klant muteren 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 klant - informatie over klant factuur informatieve functies betreffende de relatie tussen factuur, klant en adres: - informatie over factuur klant adres - informatie over adres klant factuur DS-bijlagen B blz.11

12 b) Mogelijke verfijningen 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 het gemaakte informatie-structuurdiagram ( hier weer een oude/variant versie er): artikel bedrag datum voor op factuur klant Hoofdfunctie verzenden adres in in in in straat huis postcode woonplaats N.B. Ook dit is weer een oudere, variant versie het informatie-structuurdiagram! Uit dit deel het informatie-structuurdiagram kunnen wij aflezen dat de volgende functies 'interessant' kunnen zijn: functies betreffende klant: - klant veranderen: - informatie over klant. klant toevoegen. klant verwijderen. klant muteren functies betreffende adres: - adres veranderen: - informatie over adres. adres toevoegen. adres verwijderen. adres muteren N.B. Deze functies betreffende Adres zijn in principe alle mogelijk, maar weinig zinvol, omdat we een adres steeds in combinatie de gegevens 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: DS-bijlagen B blz.12

13 informatieve functies betreffende de relatie tussen klant en adres: - informatie over adres klant - informatie over klant adres informatieve functies betreffende de relatie tussen klant, adres en factuur: - informatie over factuur klant adres - informatie over adres klant factuur c) Vergelijkende analyse Hiervóór hebben wij, uitgaande 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 de diverse functies! Wij krijgen als een voorlopig overzicht (zonder overlap) mogelijke functies: - factuur veranderen: - informatie over factuur. factuur toevoegen (al bekend). factuur verwijderen (al bekend). factuur muteren (al bekend) - klant veranderen: - informatie over klant (al bekend). klant toevoegen (al bekend). klant verwijderen. klant muteren (al bekend) N.B. - adres veranderen: (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 klant (al bekend) - informatie over klant factuur - informatieve functies betreffende de relatie tussen klant en adres: - informatie over adres klant (al bekend) - informatie over klant adres - informatieve functies betreffende de relatie tussen factuur, klant en adres: - informatie over factuur klant adres - informatie over adres klant factuur Als we ons (uiteraard in overleg 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 factuur (het lijkt zinvol om via een factuurnummer de naam + adres een klant op te laten zoeken) Via onze inventarisatie uit 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! DS-bijlagen B blz.13

14 Merk op dat onze analysewerkzaamheden dus geleid hebben tot een bijstelling de aan het informatiesysteem gestelde eisen (en dientengevolge tot bijstelling het ontwerp): de gewenste informatievoorziening omvat nu niet meer puur de automatisering de bestaande situatie. Gewenst wordt: - aan kunnen brengen binnengekomen factuurgegevens op een factuur een uniek volgnummer, een kopiefactuur kunnen archiveren, - informatie kunnen verstrekken over facturen en klanten, - de factuur kunnen voorzien verzendgegevens (zodat deze daarna in een vensterenvelop verzonden kan worden), - de verzendgegevens kunnen bijwerken op grond 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 manipulatie gegevens objecten op het hoogste of het bijna hoogste niveau de moeite 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 betrekking tot woonplaats en/of postcode erg handig zijn (denk b.v. aan het op het postkantoor gesorteerd op postcode afleveren een mailing ). DS-bijlagen B blz.14

15 Bijlage DS - g ) FunctiePunt-Analyse (FPA) Het maken een realistische schatting (begroting) hoeveel de kosten voor het ontwikkelen 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 kostenramingshoden 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 hode voor het begroten die kosten is de zogenaamde FunctiePunt-Analyse (FPA-) hode. Bij deze hode gaat men er uit, dat het ontwikkelen elk functioneel onderdeel een informatiesysteem een bepaalde tijdsinvestering kost, die (gemiddeld, ruwweg en vooral ) bepaald wordt door het soort functionaliteit (zoals invoer of uitvoer gegevens). De FPA-hode 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 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 geen waarden bij vorige ontwikkelprojecten en waarmee een productiviteitscijfer is bepaald (aantal uren per functiepunt). We geven hier eerst schetsmatig een overzicht de oorspronkelijke FPA-hode en bekijken daarna een aanpassing (de IFPA-hode). a) de FPA-hode: (schetsmatig) bestanden invoer- functies uitvoer- functies koppelingen bepaal aantal bruto functiepunten bepaal aantal netto functiepunten 14 factoren opvragings- functies 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. DS-bijlagen B blz.15

16 N.B. Zowel bij de FPA- als de hierna te bespreken IFPA-hode geldt, dat we als het ware alleen de oorspronkelijke algoritmiek moeten beoordelen (het slechts kopiëren programma-delen kost beslist niet zoveel tijd als het oorspronkelijk uitdenken zo'n onderdeel). We mogen gebruikersfuncties dus alleen (volledig) meetellen, als ze duidelijk afwijkend 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-hode (Interprogram FPA): Een in Nederland gebruikte variant op boven beschreven FPA-hode is de IFPA-hode (Interprogram FPA). Die hode is schematisch de volgende: logische gegevensverzamelingen invoer- functies uitvoer- functies koppelingen bepaal aantal functiepunten bepaal aantal bruto-uren opvragings- functies produktiviteitscijfer eventuele correctiefactor bepaal aantal netto-uren b.1) Algemene opmerkingen bij het toepassen de IFPA-hode: 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 : - 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 ). DS-bijlagen B blz.16

17 b.2) IFPA -beoordelingsmatrices: Hulpmatrix logische gegevensverzamelingen aantal velden waardering > aantal velden > 15 Hulpmatrix invoerfunctie aantal benaderde gegevensverzam. 1 2 > aantal velden > 19 Hulpmatrix uitvoerfunctie aantal benaderde gegevensverzam > aantal velden > 19 Hulpmatrix opvragingsfunctie aantal benaderde gegevensverzam > Hulpmatrix koppeling aantal velden waardering > De IFPA-waardering voor 'ondersteunende functies' is: - foutmeldingen: worden gelet de gelijkvormigheid als één uitvoerfunctie geteld, 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 een aantal project-afhankelijke factoren zoals de gebruikte programmeertaal, het wel/niet gebruiken ontwikkeltools, de hardware waar het informatiesysteem voor ontwikkeld wordt, het gebruik een kanten-klaar databasemanagementsysteem en de complexiteit het systeem (bijvoorbeeld een min of meer 'standaard' administratief systeem of een technisch-wetenschappelijk systeem gecompliceerde berekeningen...). Desgewenst kan (ervaringsgewijs) ook een raming worden gegeven hoeveel tijd/inspanning een bepaalde fase de systeemontwikkeling zal kosten (b.v. hoeveel tijd kost het maken het Basisontwerp, de Realisatiefase, etc.). Om je een beetje een idee te geven wat er in de praktijk gebeurt, geven we hier wat getallen 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 ervaringscijfers je eigen organisatie je productiviteitscijfer moeten bepalen! DS-bijlagen B blz.17

18 Program- Gebruik Hard- Complex- Omg prod. prod. meertaal hulp- ware iteit systeem in cijfer cijfer middelen functiept. tot 4 GL ja micro normaal < 500 fp fp fp fp > 3500 fp groot < 500 fp fp extreem < 500 fp > 3500 fp mini normaal < 500 fp fp mainframe normaal < 500 fp GL nee micro normaal < 500 fp fp GL ja micro normaal < 500 fp proc's fp GL nee micro normaal < 500 fp proc's fp GL ja micro normaal < 500 fp n.proc's fp GL nee micro normaal < 500 fp n.proc's fp en extreem: 3 GL nee mainframe extreem > 3500 fp n.proc's Uit dit overzicht komt overduidelijk de verwachte conclusie tevoorschijn, dat je bij een 4GL-systeem (SQL +...) gebruik 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'-hodes FunctiePunt-Analyse ( 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 hoden; elk 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 hoden nodig hebt, is het zeer zeker de moeite waard om een up-to-date vergelijking tussen deze (en nog andere) hoden op te sporen en een of meer deze hodes in detail te bestuderen. DS-bijlagen B blz.18

19 d) Voorbeeld kostenschatting volgens de FunctiePunt-Analyse: de factureringsafdeling We maken hier een eerste ruwe kostenschatting wat het ontwikkelen (ontwerpen+implementeren) het gewenste informatiesysteem voor de factureringsafdeling zou gaan kosten. We gaan daarbij uit de volgende gewenste functies/functionaliteit (zie definitiestudierapport bijlage DS-b):. Voeg toe factuur klant invoerfunctie. Toon facturen klant uitvoerfunctie. Verwijder factuur klant opvragingsfunctie. Muteer factuur klant invoerfunctie. Druk af factuur klant \ en: adres klant - uitvoerfunctie. Voeg toe klant invoerfunctie. Toon klant opvragingsfunctie. Muteer klant invoerfunctie We gaan er (voorlopig) uit, dat ze allemaal 'aparte' algoritmen vereisen (omdat we geen zelfde 'denkwerk' dubbel mogen tellen). Bovendien gaan we voor het bepalen het benodigde 'aantal velden' bij de invoer/uitvoer/opvragingsfuncties uit 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), elk een vrij beperkt (1-10) aantal velden. Bijdrage aan totaal aantal functiepunten: 2 (verzamelingen) * 4 (waardering) = 8 fp II) invoerfuncties:. Voeg toe factuur klant invoerfunctie ( 5 velden; 2 verz) = 4 fpt. Muteer factuur klant invoerfunctie ( 5 velden; 2 verz) = 4 fpt. Voeg toe klant invoerfunctie ( 6 velden; 1 verz) = 3 fpt. Muteer klant invoerfunctie ( 6 velden; 1 verz) = 3 fpt III) uitvoerfuncties:. Druk af factuur klant \ en: adres klant - uitvoerfunctie ( 10 velden; 2 verz) = 5 fpt. Toon facturen klant uitvoerfunctie ( 5 velden; 1 verz) = 4 fpt Ook: foutmeldingen tellen als 1 minimale uitvoerfunctie) = 4 fpt menustructuur tellen als 1 minimale uitvoerfunctie) = 4 fpt IV) opvragingsfuncties:. Verwijder factuur klant opvragingsfunctie (5 velden; 1 verz) = 3 fpt. Toon klant opvragingsfunctie (5 velden; 1 verz) = 3 fpt V) koppelingen ( andere systemen): niet aanwezig Totaal aantal functiepunten: = 45 fpt Indien we het systeem ontwikkelen en realiseren 4GL + hulpmiddelen voor een pc en we (ervaringsgewijs ons team) een productiviteitscijfer 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 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. DS-bijlagen B blz.19