DEFINITIES EN TELRICHTLIJNEN VOOR DE TOEPASSING VAN FUNCTIEPUNTANALYSE. NESMA functional size measurement method conform ISO/IEC Versie 2.

Transcriptie

1 DEFINITIES EN TELRICHTLIJNEN VOOR DE TOEPASSING VAN FUNCTIEPUNTANALYSE NESMA functional size measurement method conform ISO/IEC Versie HANDBOEK VAN DE NEDERLANDSE SOFTWARE METRIEKEN GEBRUIKERS ASSOCIATIE

2

3 DEFINITIES EN TELRICHTLIJNEN VOOR DE TOEPASSING VAN FUNCTIEPUNTANALYSE NESMA functional size measurement method conform ISO/IEC Versie 2.2

4 HANDBOEK VAN DE NEDERLANDSE SOFTWARE METRIEKEN GEBRUIKERS ASSOCIATIE ISBN: Copyright NESMA Alle rechten voorbehouden. NEderlandse Software Metrieken Gebruikers Associatie (NESMA). Niets uit deze uitgave mag worden verveelvoudigd of openbaar gemaakt, in enige vorm of op enige wijze, zonder voorafgaande schriftelijke toestemming van de NESMA. Na toestemming dient de titelpagina van het document waarin gedeelte(n) uit deze uitgave zijn overgenomen, de volgende bepaling te bevatten: Deze uitgave bevat materiaal dat afkomstig is uit - Definities en telrichtlijnen voor de toepassing van functiepuntanalyse, NESMA functional size measurement method conform ISO/IEC versie van de NESMA. Deze openbaarmaking geschiedt met toestemming van de NESMA.

5 VOORWOORD VOORWOORD Voor u ligt versie 2.2 van de Internationale Standaard "Definities en telrichtlijnen voor de toepassing van functiepuntanalyse", uitgegeven door de Nederlandse Software Metrieken Gebruikers Associatie (NESMA). Het bewaken en beheersen van de systeemontwikkeling en het operationeel houden van geautomatiseerde systemen is een moeilijke aangelegenheid. Dit wordt moeilijker naarmate deze systemen complexer worden. De oorzaken voor deze situatie zijn nauw verbonden met het meten (in termen van bruikbare functionaliteit) van: welke functionaliteit het desbetreffende informatiesysteem aan de gebruiker moet bieden c.q. biedt; de inspanningen en hulpmiddelen die nodig zijn om die functionaliteit aan de gebruiker te leveren; de inspanningen en hulpmiddelen die nodig zijn om het informatiesysteem operationeel te houden. FunctiePuntAnalyse (FPA) is een methode met de mogelijkheid om: een technologieonafhankelijke meting te doen van de omvang van de door een geautomatiseerd informatiesysteem geboden functionaliteit; deze meting te gebruiken als basis voor productiviteitsmeting, het schatten van de benodigde middelen en projectbeheersing; die factoren in een ontwikkelomgeving te evalueren die de productiviteit beïnvloeden, dus de mogelijkheid bieden om het ontwikkelproces te verbeteren; de omvang van een informatiesysteem tijdens het ontwikkelproces te beheersen; de kwaliteit van de specificaties van een informatiesysteem te toetsen. In mei 1989 is de Nederlandse Software Metrieken Gebruikers Associatie (Netherlands Software Metrics Users Association, afgekort NESMA), toen nog onder de naam Vereniging Nederlandse Functie Punt Gebruikers (Netherlands Function Point Users Group, afgekort NEFPUG), opgericht met als belangrijkste doelstellingen: het bijeenbrengen, bijeenhouden, uitwisselen en uitbreiden van kennis en ervaring betreffende de FPA-methode en de toepassing en toepassingsmogelijkheden daarvan; het bevorderen van verantwoord gebruik van de FPA-methode; het bevorderen van de standaardisatie van de FPA-methode; het bevorderen van het uitbreiden van de toepassingsmogelijkheden van de FPAmethode. De NESMA tracht haar doel te bereiken door: het inrichten van studiecommissies/werkgroepen; het doen van onderzoek; het houden van voordrachten, voorlichtingsbijeenkomsten, symposia en dergelijke; het doen van aanbevelingen; het verzamelen en publiceren van literatuur betreffende FPA en andere software metrieken; het samenwerken met daarvoor in aanmerking komende organisaties die zich met vergelijkbare vraagstukken bezighouden; het onderhouden van contacten met en het samenwerken met de International Function Point Users Group (IFPUG) en andere zusterorganisaties. DEFINITIES en TELRICHTLIJNEN FPA i

6 VOORWOORD ISO standaard Een van de vele uitdagingen voor software ontwikkelaars is het vinden van methoden om op basis van de systeemeisen, de inspanning en tijd die nodig is voor het ontwikkelen van een softwareproduct te schatten. Allan Albrecht van IBM heeft eind 1979 een methode ontwikkeld die FunctiePuntAnalyse (FPA) is genoemd. Deze methode kwantificeert de functies van het softwareproduct in termen van de gebruikers. Naarmate de methode populairder werd, is FPA geëvolueerd en zijn er diverse varianten ontwikkeld. ISO/IEC JTC 1/SC7 heeft in 1993 besloten hiervoor een algemeen kader functional size measurement (FSM) te ontwikkelen. De werkgroep (WG12) die hiervoor werd ingesteld, bestond uit vertegenwoordigers uit 12 landen en uit vertegenwoordigers van de voornaamste gebruikersgroepen die een eigen FSM methode hadden ontwikkeld. Deze zijn de Netherlands Software Metrics Association (NESMA), de International Function Point Users Group (IFPUG), de Common Software Measurement International Consortium (COSMIC) en de UK Software Metrics Association (UKSMA). De strategie die de WG12 heeft gevolgd is om eerst een serie generieke standaards en richtlijnen met betrekking tot FSM op te stellen, de serie standaards. Vervolgens zijn op basis van deze gepubliceerde standaards de bovengenoemde organisaties uitgenodigd om hun methode als een ISO standaard te publiceren. De bovengenoemde FSM methoden voldoen nu aan de eisen van de ISO/IEC standaard, en zijn nu bekend als respectievelijk de volgende ISO/IEC standaarden: NESMA (ISO/IEC 24570), IFPUG (ISO/IEC 20923), COSMIC (ISO/IEC 19761) en UKSMA (ISO/IEC 20968). Voorwoord bij versie 2.2 (2004) Versie 2.2 is gebaseerd op (de Nederlandse) versie 2.0. De Engelse versie 2.1 van dit handboek is gepubliceerd als internationale standaard (ISO/IEC DIS 24570). De wijzigingen die zijn aangebracht in versie 2.1 om deze als ISO/IEC-standaard te kunnen publiceren, zijn nu ook aangebracht in de Nederlandse versie 2.2. Het verschil ten opzichte van versie 2.0 is dat nu in de officiële NESMA methode, conform de eisen in de ISO/IEC-standaard 14143, de begrippen bruto, netto, correctiefactor en systeemkenmerken niet meer voorkomen. Voor diegenen die hier nog wel gebruik van willen maken, zijn deze nu in appendix C opgenomen. Verder is de NESMA methode inhoudelijk niet gewijzigd. Wel is er een aantal verduidelijkingen en moderniseringen aangebracht: De titel is aangepast aan de titel van de ISO/IEC-standaard. De term Handboek is gewijzigd in Internationale Standaard. Het begrip scope van de telling is ter verduidelijking opgenomen. Een nieuwe paragraaf met de generieke regel voor data element typen (paragraaf 4.23) is toegevoegd. Een aantal nieuwe voorbeelden is in hoofdstuk 10 opgenomen. Daar waar nodig zijn de voorbeelden gemoderniseerd. Werkgroep Telrichtlijnen Dhr. M.A. Barth, QSM Metric Consult Mevr. drs J. Onvlee, Onvlee Opleidingen en Advies Dhr. ing M. K. Spaan, PinkRoccade Civility Dhr. drs A.W.F. Timp, Interpay Nederland B.V. (voorzitter) Dhr. E.A.J. van Vliet, Chameleon Solutions ii NESMA

7 VOORWOORD Aan voorgaande versies hebben meegewerkt: Dhr. ir J.V.T. Dam, ATOS Origin Dhr. ir J.W. de Heer, Digital Equipment B.V. Dhr. R.J.H. van Leeuwen RI, Digital Equipment B.V. Dhr. J.H.J. Schalk, Philips Corporate Automation Dhr. P.G. Vreekamp, PTT Telecom BV DEFINITIES en TELRICHTLIJNEN FPA iii

8 INHOUDSOPGAVE INHOUDSOPGAVE VOORWOORD... I INHOUDSOPGAVE... IV 1 INLEIDING AANLEIDING TOT DEZE STANDAARD VOOR WIE IS DEZE STANDAARD BEDOELD DOELSTELLING VAN DE STANDAARD UITGANGSPUNTEN VAN DE STANDAARD AANDACHTSGEBIED VAN DEZE STANDAARD INDELING VAN DE STANDAARD VERSIEBELEID INLEIDING OP FPA KORTE BESCHRIJVING VAN FPA GEBRUIK VAN FPA: PRODUCTOMVANG VERSUS PROJECTOMVANG TYPEN FUNCTIEPUNTENTELLINGEN FUNCTIEPUNTENTELLINGEN TIJDENS EEN PROJECT SCOPE VAN DE TELLING EN GRENS VAN HET INFORMATIESYSTEEM GEBRUIKERS GEBRUIKERSFUNCTIES COMPLEXITEIT VAN EEN GEBRUIKERSFUNCTIE HET WAARDEREN VAN GEBRUIKERSFUNCTIES DE FUNCTIONELE OMVANG HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA STAPPENPLAN VOOR HET UITVOEREN VAN EEN FPA TYPEN FUNCTIEPUNTENTELLINGEN EN HUN NAUWKEURIGHEID DE ROL VAN DE KWALITEIT VAN DE SPECIFICATIES FPA GEDURENDE EEN PROJECT HET BEPALEN VAN DE PRODUCTOMVANG HET BEPALEN VAN DE PROJECTOMVANG FPA IN SPECIFIEKE SITUATIES ILLUSTRATIE: FPA TIJDENS FASEN VAN SYSTEEMONTWIKKELING ALGEMENE RICHTLIJNEN TELLEN VANUIT LOGISCH GEZICHTSPUNT TOEPASSING VAN DE REGELS GEBOUWDE, NIET GEVRAAGDE FUNCTIONALITEIT DUBBELTELLINGEN PRODUCEREN VAN HERBRUIKBARE CODE HERGEBRUIK VAN BESTAANDE CODE SCHERMEN EN RAPPORTEN INVOER- EN UITVOERRECORDS BEVEILIGING EN AUTORISATIE BESTURINGSSYSTEMEN EN UTILITIES RAPPORTGENERATOREN EN QUERY-FACILITEITEN...32 iv NESMA

9 INHOUDSOPGAVE 4.12 GRAFIEKEN HELPFACILITEITEN FOUT- EN ANDERE SYSTEEMMELDINGEN MENUSTRUCTUREN LIJSTFUNCTIES BLADEREN EN SCROLLFUNCTIES SCHONINGSFUNCTIES VOLLEDIGHEIDSCONTROLE OP DE FUNCTIEPUNTENTELLING FPA-TABELLEN HET AFLEIDEN VAN DE LGV S UIT EEN GENORMALISEERD GEGEVENSMODEL GEMEENSCHAPPELIJK GEBRUIK VAN GEGEVENS GENERIEKE REGEL VOOR HET TELLEN VAN DATA-ELEMENT-TYPEN INTERNE LOGISCHE GEGEVENSVERZAMELINGEN DEFINITIE VAN EEN INTERNE LOGISCHE GEGEVENSVERZAMELING HET TELLEN VAN INTERNE LOGISCHE GEGEVENSVERZAMELINGEN HET BEPALEN VAN DE COMPLEXITEIT VAN INTERNE LOGISCHE GEGEVENSVERZAMELINGEN KOPPELINGSGEGEVENSVERZAMELINGEN DEFINITIE VAN EEN KOPPELINGSGEGEVENSVERZAMELING HET TELLEN VAN KOPPELINGSGEGEVENSVERZAMELINGEN HET BEPALEN VAN DE COMPLEXITEIT VAN KOPPELINGSGEGEVENSVERZAMELINGEN INVOERFUNCTIES DEFINITIE VAN EEN INVOERFUNCTIE HET TELLEN VAN INVOERFUNCTIES HET BEPALEN VAN DE COMPLEXITEIT VAN INVOERFUNCTIES UITVOERFUNCTIES DEFINITIE VAN EEN UITVOERFUNCTIE HET TELLEN VAN UITVOERFUNCTIES HET BEPALEN VAN DE COMPLEXITEIT VAN UITVOERFUNCTIES OPVRAGINGSFUNCTIES DEFINITIE VAN EEN OPVRAGINGSFUNCTIE HET TELLEN VAN OPVRAGINGSFUNCTIES HET BEPALEN VAN DE COMPLEXITEIT VAN OPVRAGINGSFUNCTIES PRAKTIJKSITUATIES MET OPLOSSINGEN STANDAARD AUTORISATIEFUNCTIES SPECIFIEKE AUTORISATIEFUNCTIES RAPPORTGENERATOR EN QUERY-FACILITEIT HELPFUNCTIES FOUTMELDINGEN MENUSTRUCTUREN FPA-TABELLEN DENORMALISATIE BEPALEN VAN LOGISCHE GEGEVENSVERZAMELINGEN GECOMBINEERDE INVOERFUNCTIES DEFINITIES en TELRICHTLIJNEN FPA v

10 INHOUDSOPGAVE TELLEN VAN EEN TRANSACTIEBESTAND RAPPORTEN OP VERSCHILLENDE MEDIA TIJDELIJKE MUTATIEBESTANDEN CONVERSIE UITVOERFUNCTIES MET SAMENVATTENDE INFORMATIE HET AANTAL DATA-ELEMENT-TYPEN OP EEN OVERZICHT GECOMBINEERDE UITVOERFUNCTIES COMBINATIE-EFFECTEN BIJ FUNCTIES RAADPLEGEN OP BASIS VAN MEERDERE ZOEKARGUMENTEN SCHERMEN MET LIJSTFUNCTIE BLADEREN EN SCROLLFUNCTIES SELECTIESCHERMEN BIJ WIJZIGEN MET BEHULP VAN ZOEKARGUMENT DIRECTE EN UITGESTELDE VERWERKING CASUS KLANTENSYSTEEM GRAFIEKEN HET TELLEN VAN DATA-ELEMENT-TYPEN APPENDIX A: SAMENVATTING GEBRUIKERSFUNCTIES A.1 INTERNE LOGISCHE GEGEVENSVERZAMELINGEN A.2 KOPPELINGSGEGEVENSVERZAMELINGEN A.3 INVOERFUNCTIES A.4 UITVOERFUNCTIES A.5 OPVRAGINGSFUNCTIES A.6 TABEL VOOR HET WAARDEREN VAN GEBRUIKERSFUNCTIES APPENDIX B: APPENDIX C: DEFINITIES IN RELATIE TOT FPA DE CORRECTIEFACTOR C.1 FPA MET CORRECTIEFACTOR C.2 SYSTEEMKENMERKEN APPENDIX D: INDEX vi NESMA

11 INLEIDING 1 INLEIDING Dit hoofdstuk geeft een inleiding op de standaard Definities en telrichtlijnen voor de toepassing van functiepuntanalyse, NESMA functional size measurement method. Er wordt antwoord gegeven op de volgende vragen: Waarom dit handboek (paragraaf 1.1)? Voor wie is dit handboek bedoeld (paragraaf 1.2)? Wat is de doelstelling (paragraaf 1.3)? Wat zijn de uitgangspunten (paragraaf 1.4)? Wat is het aandachtsgebied (paragraaf 1.5)? Hoe is het handboek opgezet (paragraaf 1.6)? Hoe zit het met toekomstige versies (paragraaf 1.7)? 1.1 Aanleiding tot deze standaard In het voorjaar van 1989 is de NESMA (toen nog NEFPUG geheten) opgericht. Tijdens de eerste ledenvergadering in juni is een enquête onder de deelnemers gehouden om te inventariseren welke onderwerpen hun belangstelling hadden. Het onderwerp standaardisatie telrichtlijnen/definities scoorde hoog. Hierop werd door het bestuur besloten een werkgroep op te richten die zich met dit onderwerp zou gaan bezighouden. De werkgroep heeft zich later tot taak gesteld een ISO standaard samen te stellen voor de theoretische toepassing en het praktisch gebruik van functiepuntanalyse (FPA) 1. In de loop der jaren was van FPA een aantal dialecten ontstaan. Deze bemoeilijkten het eenduidig vaststellen van het aantal functiepunten en maakten het vergelijken van resultaten over organisaties heen vrijwel onmogelijk, omdat niet in voldoende mate onderkend werd dat er sprake was van verschillende interpretaties van de oorspronkelijk door A.J. Albrecht ontwikkelde methode. Deze internationale standaard beoogt helderheid te verschaffen door het formuleren van standaards voor de definities en telrichtlijnen met betrekking tot FPA. 1.2 Voor wie is deze standaard bedoeld Deze standaard is voor iedereen die functiepuntentellingen maakt, zowel voor hen die volgens de NESMA richtlijnen tellen als voor diegenen die de IFPUG methode hanteren. Voor deze laatste groep vormt de NESMA standaard een waardevolle aanvulling op de IFPUG standaard, wanneer de bestaande verschillen, terug te vinden op de website van de NESMA ( in ogenschouw worden genomen. De NESMA standaard bevat vele hints, richtlijnen en voorbeelden die voor iedere FPA analist van waarde zijn. Hierbij wordt verondersteld dat bij de lezer enige kennis over FPA aanwezig is. Toch hebben we gestreefd naar een zo volledig mogelijke standaard waarin ook voor de beginnende FPA-gebruiker voldoende aanknopingspunten en uitleg te vinden zijn. 1.3 Doelstelling van de standaard Deze standaard tracht enerzijds een theoretisch kader te scheppen in de vorm van het geven van definities en standaard richtlijnen en anderzijds de telrichtlijnen zo praktisch mogelijk te illustreren aan de hand van allerlei praktijksituaties. 1 Vanaf dit punt zal voor de term functiepuntanalyse de afkorting FPA gebruikt worden. DEFINITIES en TELRICHTLIJNEN FPA 1

12 INLEIDING 1.4 Uitgangspunten van de standaard De volgende uitgangspunten liggen aan deze standaard ten grondslag: De Internationale Standaard ISO/IEC :1997 Information technology Software measurement Functional size measurement Definition of concepts. Deze definieert een kader waaraan een functional size methode moet voldoen. De NESMA FPA methode is in principe toepasbaar voor alle functionele domeinen. IBM CIS & A Guideline 313, AD/M Productivity Measurement and Estimate Validation, 1 November Dit is een interne publicatie van IBM. De hierin beschreven methode wordt meestal aangehaald als Albrecht Aandachtsgebied van deze standaard In deze standaard is de aandacht gericht op het vaststellen van de functionele omvang van een informatiesysteem. Hiertoe wordt aangegeven hoe het aantal functiepunten wordt vastgesteld. Deze standaard gaat niet in op aspecten die een rol spelen bij het opstellen van een projectbegroting op basis van deze functionele omvang, zoals productiviteitsnormen en productiviteitsattributen. Dit onderwerp is belicht door een andere werkgroep van de NESMA en is beschreven in het handboek Begroten (op basis van het functioneel ontwerp) met behulp van functiepuntanalyse van de NESMA. Onderstaand figuur geeft aan wat er in deze standaard wel en niet wordt behandeld. Bepalen/evalueren van de kosten van een project Bepalen van de omvang van een informatiesysteem Gebruikersfuncties Productiviteitsattributen Interne Logische gegevensverzameling Koppelingsgegevensverzameling Invoerfunctie Uitvoerfunctie Opvragingsfunctie Mensen Bekwaamheden Methoden Technieken Hulpmiddelen Systeemomgeving Projectmanagement Gebruikersorganisatie Startsituatie Soort project Etc. functiepuntentelling = aandachtsgebied standaard 2 NESMA

13 INLEIDING 1.6 Indeling van de standaard De in dit handboek gebruikte begrippen zijn omschreven in hoofdstuk 2 en gedefinieerd in appendix B. Hoofdstuk 2 geeft een inleiding op FPA. Hierin wordt de functionele invalshoek van FPA benadrukt. Verder wordt kort uiteengezet wat FPA is en worden de begrippen die de basis vormen voor het concept van FPA toegelicht. Zaken zoals: het onderscheid tussen product- en projectomvang, de verschillende typen functiepuntentellingen, FPA gedurende een project en het begrip gebruikers, komen daarbij aan de orde. In hoofdstuk 3 wordt een overzicht gegeven van de plaats van FPA binnen een project en de typen functiepuntentellingen die tijdens de levenscyclus van het informatiesysteem uitgevoerd kunnen worden. Met andere woorden: op welke momenten kan er geteld worden en welke informatie is daar minimaal voor nodig. Verder wordt in dit hoofdstuk ook een stappenplan voor het uitvoeren van een functiepuntanalyse gegeven en wordt aangegeven hoe projecten, informatiesystemen en pakketten geteld moeten worden. Deze vereisen ieder voor zich een andere aanpak. Hoofdstuk 4 geeft algemene telrichtlijnen voor een functiepuntentelling. Achtereenvolgens worden in hoofdstukken 5, 6, 7, 8 en 9 voor de interne logische gegevensverzameling, de koppelingsgegevensverzameling, de invoerfunctie, de uitvoerfunctie en de opvragingsfunctie de definities en de richtlijnen gegeven voor het onderkennen van de gebruikersfuncties en het bepalen van hun complexiteit. In hoofdstuk 10 worden vele praktijksituaties met uitwerking gegeven. De telrichtlijnen worden niet expliciet herhaald; wel wordt er verwezen naar de betreffende richtlijn(en) en/of paragraaf die aan de oplossing ten grondslag ligt/liggen. Appendix A is bedoeld als korte samenvatting van de standaard en bevat per gebruikersfunctie de belangrijkste kenmerken en bevat de tabellen voor het waarderen van de gebruikersfuncties. Appendix B bevat de definities van de begrippen die in deze standaard gebruikt worden. Appendix C beschrijft de toepassing van de correctiefactor bij het vaststellen van het netto aantal functiepunten. In vorige versies van deze richtlijn was er sprake van systeemkenmerken en het bruto en netto aantal functiepunten. Deze begrippen worden in deze appendix toegelicht. Appendix D bevat een index op trefwoorden om deze standaard vanuit verschillende invalshoeken toegankelijk te maken. De standaard is zodanig opgezet dat ze in principe niet van voor naar achter doorgelezen hoeft te worden. Ieder kan naar eigen inzicht datgene opzoeken wat voor hem/haar van belang is. Soms zullen dat specifieke telrichtlijnen bij een gebruikersfunctie zijn, soms juist het meer algemene begrippenkader bij een eerste kennismaking met FPA. 1.7 Versiebeleid Wanneer in de toekomst wijzigingen en aanvullingen op deze standaard nodig blijken te zijn, zal een geheel nieuwe versie worden geproduceerd. Vandaar dat het niet als een losbladig document is uitgegeven. Op de website van de NESMA ( is een FAQ sectie opgenomen met antwoorden op veel gestelde telvragen Achter in deze standaard is een commentaarbladzijde opgenomen. Hiermee kunt u eventuele fouten, onduidelijkheden of opmerkingen betreffende de standaard aan ons doorgeven. Wij stellen uw commentaar op prijs. DEFINITIES en TELRICHTLIJNEN FPA 3

14 INLEIDING OP FPA 2 INLEIDING OP FPA Dit hoofdstuk is bedoeld om in kort bestek aan te geven wat FPA is en om een aantal belangrijke begrippen uit te leggen. In paragraaf 2.1 wordt een korte beschrijving gegeven van FPA. De paragrafen 2.2 tot en met 2.4 beschrijven welke verschillende soorten functiepuntentellingen worden onderscheiden. De paragrafen 2.5 tot en met 2.9 gaan achtereenvolgens in op wat in het kader van FPA wordt verstaan onder: grenzen waarbinnen wordt geteld, gebruikers, gebruikersfuncties, complexiteit van een functie en het waarderen van gebruikersfuncties. Ten slotte wordt in paragraaf 2.10 aangegeven wat onder de functiepuntentelling verstaan wordt en de relatie hiervan met de projectbegroting. 2.1 Korte beschrijving van FPA Achtergrond en doel van FPA FPA is bij IBM door A.J. Albrecht ontwikkeld in de periode op basis van een productiviteitsonderzoek van een groot aantal projecten. De eerste versie van FPA werd geïntroduceerd in 1979, gevolgd door aanpassingen op grond van praktijkervaringen in 1983 en FPA wordt momenteel in talloze bedrijven over de gehele wereld toegepast. Ervaringen met deze techniek worden uitgewisseld in gebruikersgroepen: de IFPUG (International Function Point Users Group), de ASMA (Australian Software Metrics Association), de UFPUG (United Kingdom Function Point Users Group), de NESMA en diverse andere landelijke gebruikersgroepen. De NESMA is aangesloten bij de IFPUG. Met behulp van FPA wordt een eenheid (de functiepunt) geïntroduceerd voor de omvang van een te ontwikkelen (of te onderhouden) informatiesysteem. In het kader van FPA wordt met een informatiesysteem bedoeld: een geautomatiseerd informatiesysteem. In de functiepunt wordt de hoeveelheid informatieverwerking die een informatiesysteem aan de gebruiker biedt uitgedrukt. De eenheid staat los van de wijze waarop de informatieverwerking technisch wordt gerealiseerd. Een functiepunt is een abstract begrip en is enigszins te vergelijken met de zogenaamde huurpunten : op basis van het aantal kamers en hun oppervlakte, het aantal voorzieningen en de ligging van het huis kan het aantal huurpunten vastgesteld worden, dat een maatstaf is voor wat de huurder geboden wordt. De eerste toepassing waarvoor FPA werd gebruikt was het achteraf meten van de productiviteit van systeemontwikkeling en systeemonderhoud. Al snel werd duidelijk dat de techniek zich tevens leent voor het ondersteunen van het proces van begroten van projecten, omdat de gegevens die nodig zijn voor een FPA al vroegtijdig in een project beschikbaar kunnen zijn Denkwijze achter FPA De drie samenstellende woorden van functiepuntanalyse kunnen worden gebruikt om de denkwijze toe te lichten. Functie Zoals al opgemerkt is, wordt bij FPA uitgegaan van de functionaliteit die een informatiesysteem de gebruiker (zie paragraaf 2.6) biedt. Omdat de gebruiker alleen de buitenkant of de grens (zie paragraaf 2.5) van een informatiesysteem ziet, wordt bij FPA gekeken naar die specificaties die de informatie-uitwisseling van het informatiesysteem met zijn omgeving beschrijven. Hierbij wordt de functionaliteit afgeleid van de in- en uitgaande informatiestromen (dit kan zowel data- 4 NESMA

15 INLEIDING als besturingsinformatie zijn) en de gegevensverzamelingen die het informatiesysteem bevat of waar het informatiesysteem gebruik van maakt. De functionaliteit van het informatiesysteem wordt gemeten door het vaststellen van de zogenaamde gebruikersfuncties (zie paragraaf 2.7). Punt Van iedere gebruikersfunctie wordt de complexiteit (zie paragraaf 2.8) bepaald volgens standaard richtlijnen. Elke functie levert een aantal punten op afhankelijk van de complexiteit (zie paragraaf 2.9). De optelsom geeft het aantal functiepunten (zie paragraaf 2.10). Analyse FPA is het analyseren van een informatiesysteem of een beschrijving van een informatiesysteem ten einde het aantal functiepunten ervan vast te stellen. Het vaststellen van het aantal functiepunten wordt ook wel een functiepuntentelling genoemd. Tot zover de denkwijze en de korte beschrijving van FPA. In de volgende paragrafen worden de diverse in het kader van FPA gehanteerde begrippen verder toegelicht. 2.2 Gebruik van FPA: productomvang versus projectomvang Functiepuntentellingen kunnen gekoppeld worden aan informatiesystemen of aan projecten. Daarbij worden de volgende doelen van de functiepuntentelling onderscheiden: het bepalen van de productomvang en het bepalen van de projectomvang. Het bepalen van de productomvang: Het aantal functiepunten is een maat voor de omvang van de door een informatiesysteem aan de gebruiker te leveren of geleverde functionaliteit. Tevens is het een maat voor de omvang van een informatiesysteem dat moet worden onderhouden. Het bepalen van de projectomvang: Het aantal functiepunten is een maat voor de omvang van de functionaliteit van een door één project te realiseren nieuw (deel van een) informatiesysteem of van wijzigingen op een bestaand informatiesysteem. In het laatste geval gaat het om het toevoegen en/of wijzigen en/of verwijderen van gebruikersfuncties. De projectomvang is een essentiële parameter bij het bepalen van de voor het project benodigde inspanning en doorlooptijd. Het bepalen van de productomvang wordt verder uitgewerkt in paragraaf 3.5, het bepalen van de projectomvang in paragraaf Typen functiepuntentellingen Afhankelijk van de mate van detail van de beschikbare specificaties kan worden gekozen voor één van de drie typen functiepuntentellingen. In oplopende mate van detail van de specificaties spreken we van: de indicatieve functiepuntentelling; de globale functiepuntentelling; de gedetailleerde functiepuntentelling. Deze typen functiepuntentellingen worden nader toegelicht in paragraaf 3.2. DEFINITIES en TELRICHTLIJNEN FPA 5

16 INLEIDING OP FPA 2.4 Functiepuntentellingen tijdens een project Op verschillende momenten tijdens een project kunnen functiepuntentellingen worden uitgevoerd. Functiepuntentellingen kunnen dus gerelateerd worden aan de fasen van een project (zoals de planningsfase, de uitvoeringsfase en de evaluatiefase). Hierbij ontstaat de volgende indeling van functiepuntentellingen: de initiële telling, de tussentijdse telling en de definitieve telling. Deze soorten functiepuntentellingen worden verder uitgewerkt in paragraaf Scope van de telling en grens van het informatiesysteem De scope van de functiepuntentelling is de set van functionele requirements/specificaties waarop de functiepuntentelling is gebaseerd. De systeemgrens is de conceptuele interface tussen het informatiesysteem en de gebruikers/andere informatiesystemen. Het vaststellen van grenzen is nodig om te kunnen vaststellen: tot welk informatiesysteem bepaalde gegevens behoren; welke gegevens de grenzen overschrijden. Zoals al in paragraaf 2.2 is aangegeven wordt bij het tellen van functiepunten onderscheid gemaakt tussen een functiepuntentelling van een informatiesysteem en een functiepuntentelling van een project. In paragraaf en worden deze begrippen nader toegelicht. 2.6 Gebruikers In het kader van FPA worden drie soorten gebruikers onderkend. De personen en/of organisaties die het te meten informatiesysteem gebruiken of gaan gebruiken. Hierbij zijn inbegrepen: de eindgebruikers, de functioneel beheerders en de operators. De eigenaar en/of de functionaris(sen) die namens de eigenaar eisen en wensen bepalen die in de specificaties zijn opgenomen. Deze eisen en wensen worden vastgesteld op grond van de eisen van bijvoorbeeld de eindgebruiker(s), maar ook op grond van eisen die door de overheid of de wetgeving gesteld worden aan het informatiesysteem. Andere informatiesystemen die gegevens of functies van het te tellen informatiesysteem gebruiken. Omdat de functiepuntentelling gebeurt vanuit de visie van de gebruiker, is het nodig zo n telling steeds in samenwerking met de gebruiker te doen plaatsvinden of op zijn minst het resultaat af te stemmen. De gebruiker is de enige die kan bepalen of een bepaalde functie wordt gevraagd. 2.7 Gebruikersfuncties De functiepuntentelling is een meting van de omvang van de gebruikersfuncties van een geautomatiseerd informatiesysteem of een deel ervan. Het gaat daarbij om het wat en niet om het hoe van hetgeen wordt geleverd. Alleen die componenten die door de gebruiker worden gevraagd en voor de gebruiker herkenbaar zijn en betekenis hebben, worden beoordeeld. Deze componenten worden gebruikersfuncties (Base Functional Components conform ISO :1997) genoemd. 6 NESMA

17 INLEIDING Gebruikersfuncties worden in het kader van FPA als volgt gedefinieerd: De vijf soorten componenten waaruit een geautomatiseerd informatiesysteem, vanuit het gezichtspunt van FPA, bestaat. Deze componenten zijn bepalend voor de hoeveelheid functionaliteit die door een informatiesysteem aan de gebruiker wordt aangeboden. Gebruikersfuncties worden ingedeeld in twee hoofdgroepen: logische gegevensverzamelingen; gebruikerstransacties. Een logische gegevensverzameling is: Een logische groep gegevens vanuit het gezichtspunt van de gebruiker. Binnen FPA worden onderscheiden: interne logische gegevensverzamelingen; koppelingsgegevensverzamelingen. Een gebruikerstransactie is: Een elementaire functie en voldoet daarom aan de volgende twee voorwaarden: De functie heeft voor de gebruiker een zelfstandige betekenis en voert een geheel afgeronde verwerking van informatie uit. Het informatiesysteem is na het uitvoeren van de functie in een consistente staat. Binnen FPA worden onderscheiden: invoerfuncties; uitvoerfuncties; opvragingsfuncties. Iedere gebruikersfunctie wordt verder besproken in de hoofdstukken 5 tot en met 9. interne logische gegevensverzamelingen logische gegevensverzamelingen koppelingsgegevensverzamelingen gebruikersfuncties invoerfuncties gebruikerstransacties uitvoerfuncties opvragingsfuncties 2.8 Complexiteit van een gebruikersfunctie De complexiteit van een gebruikersfunctie wordt als volgt gedefinieerd: De hoeveelheid informatieverwerking van een gebruikersfunctie op grond waarvan een aantal functiepunten aan de gebruikersfunctie wordt toegekend. DEFINITIES en TELRICHTLIJNEN FPA 7

18 INLEIDING OP FPA De complexiteit van een gebruikersfunctie wordt bepaald via de betreffende complexiteitstabel. Voor iedere soort gebruikersfunctie is een aparte tabel gedefinieerd. De complexiteit hangt af van het aantal data-element-typen en het aantal gerefereerde logische gegevensverzamelingen (LGV s) c.q. recordtypen (RET s) dat bij een gebruikersfunctie betrokken is. Er worden drie niveaus van complexiteit onderscheiden: eenvoudig: er zijn weinig data-element-typen en gerefereerde logische gegevensverzamelingen/recordtypen betrokken bij de gebruikersfunctie. gemiddeld: de gebruikersfunctie is voor wat de complexiteit betreft noch eenvoudig, noch moeilijk. moeilijk: er zijn veel data-element-typen en gerefereerde logische gegevensverzamelingen/recordtypen betrokken bij de gebruikersfunctie. De complexiteitstabellen zijn opgenomen in appendix A 2.9 Het waarderen van gebruikersfuncties Nadat de complexiteit van een gebruikersfunctie is bepaald, zoals beschreven in de hoofdstukken 5 tot en met 9, kan het aantal functiepunten aan de functie worden toegekend. Dit moet gebeuren volgens de waardering als weergegeven in onderstaande tabel. Functiepuntentabel voor het waarderen van gebruikersfuncties ILGV KGV IF UF OF Eenvoudig Gemiddeld Moeilijk ILGV KGV IF UF OF = Interne logische gegevensverzameling = Koppelingsgegevensverzameling = Invoerfunctie = Uitvoerfunctie = Opvragingsfunctie Bij een globale functiepuntentelling (zie paragraaf 3.2.2) zijn de specificaties wel voldoende om de gebruikersfuncties te onderkennen, maar is het niet mogelijk hun complexiteit te bepalen. In dat geval wordt voor een logische gegevensverzameling als complexiteit eenvoudig aangehouden en voor een gebruikerstransactie gemiddeld De functionele omvang De functionele omvang is de som van het aantal functiepunten dat op de hierboven beschreven wijze is toegekend aan elk van de gebruikersfuncties die binnen de scope van het getelde object (informatiesysteem of project) liggen. Het aantal functiepunten kan mede dienen als basis voor het opstellen van een projectbegroting, door dit aantal functiepunten te vermenigvuldigen met een op ervaringscijfers gebaseerde productiviteitsnorm (zoals uren per functiepunt). Het opstellen van een projectbegroting valt buiten het aandachtsgebied van deze standaard. Dit is beschreven in het handboek Begroten (op basis van het functioneel ontwerp) met behulp van functiepuntanalyse van de NESMA. 8 NESMA

19 INLEIDING Een functiepuntentelling conform de NESMA-FSM methode gebaseerd op functionele specificaties van software heeft de volgende naamconventie en zal als volgt gelabeld worden: F(unction) P(oint) (ISO/IEC 24570:2003, NESMA FSM Methode). DEFINITIES en TELRICHTLIJNEN FPA 9

20 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA 3 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA In dit hoofdstuk wordt aangegeven hoe een functiepuntanalyse uitgevoerd moet worden. Hiertoe wordt eerst een stappenplan gepresenteerd dat algemeen van toepassing is (paragraaf 3.1). Vervolgens wordt voor elk van de te onderkennen typen functiepuntentellingen (zie paragraaf 3.2) aangegeven hoe in de specifieke gevallen gehandeld moet worden. In paragraaf 3.3 wordt ingegaan op de rol van de kwaliteit van de specificaties. In paragraaf 3.4 wordt het gebruik van FPA tijdens een project belicht. Vervolgens wordt aangegeven hoe de productomvang (paragraaf 3.5) en de projectomvang (paragraaf 3.6) bepaald worden in het geval sprake is van nieuwbouw en in het geval sprake is van onderhoud. De specificaties van een informatiesysteem kunnen op geheel verschillende wijze vastgelegd zijn. In paragraaf 3.7 wordt aangegeven waar men rekening mee dient te houden bij de diverse wijzen van vastlegging. Dit hoofdstuk wordt afgesloten met een illustratie hoe de verschillende typen functiepuntentellingen tijdens de levenscyclus van een informatiesysteem toegepast kunnen worden, waarbij ter illustratie uitgegaan wordt van een faseringsmethode voor de levenscyclus van een informatiesysteem (paragraaf 3.8). 3.1 Stappenplan voor het uitvoeren van een FPA Hieronder volgt een stappenplan voor het uitvoeren van een functiepuntentelling. Stap 1: Verzamel de beschikbare documentatie. Wat aanwezig dient te zijn, is voor een indicatieve telling beschreven in paragraaf 3.2.1, voor een globale telling in paragraaf en voor een gedetailleerde telling in paragraaf Stap 2: Stel vast wie de gebruikers zijn van het informatiesysteem (zie paragraaf 2.6). Stap 3: Bepaal of de productomvang dan wel de projectomvang bepaald moet worden. Handel vervolgens, indien de productomvang bepaald moet worden, conform het gestelde in paragraaf 3.5. Indien de projectomvang bepaald moet worden, handel dan conform het gestelde in paragraaf 3.6. Stap 4: Stel vast van welk(e) andere informatiesyste(e)m(en) het te tellen informatiesysteem gegevens ontvangt en/of gebruikt. Stap 5: Identificeer de gebruikersfuncties en bepaal hun complexiteit volgens de richtlijnen beschreven in hoofdstuk 5 tot en met 9. Houd hierbij de volgorde van de hoofdstukken aan. Ken het aantal functiepunten toe met behulp van de functiepuntentabel in paragraaf 2.9, resulterend in het aantal functiepunten. Registreer de opbouw van de telling en het aantal functiepunten. Leg vooral de uitgangspunten en de aannamen die gedaan zijn vast. Stap 6: Stem het resultaat af met de gebruiker(s) ten aanzien van die aspecten waar specifieke interpretatie van de beschikbare specificaties nodig is geweest. Corrigeer eventueel het resultaat naar aanleiding van deze afstemming. Stap 7: Stem het resultaat eventueel af met een FPA-deskundige ten aanzien van die aspecten waar specifieke interpretatie van de telrichtlijnen nodig is geweest. Corrigeer eventueel het resultaat naar aanleiding van deze afstemming. 3.2 Typen functiepuntentellingen en hun nauwkeurigheid Afhankelijk van de mate van detail van de beschikbare specificaties kan worden gekozen voor één van de drie typen functiepuntentellingen: indicatieve, globale en gedetailleerde functiepuntentelling. 10 NESMA

21 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Elk in deze paragraaf genoemd type functiepunttelling kan zowel voor het bepalen van de projectomvang als voor het bepalen van de productomvang worden gebruikt. De minimaal benodigde specificaties verschillen voor elk van deze typen functiepuntentellingen. In de onderstaande paragrafen wordt per type functiepuntentelling aangegeven welke specificaties nodig zijn om de telling uit te kunnen voeren. Verder wordt per type telling aangegeven vanaf welk moment in de levenscyclus van een informatiesysteem het type telling kan worden uitgevoerd De indicatieve functiepuntentelling 2 Definitie Een indicatieve functiepuntentelling geeft een indicatie van de orde van grootte van een informatiesysteem of project, uitsluitend uitgaande van een conceptueel gegevensmodel of van een genormaliseerd gegevensmodel. Voorzichtigheid bij deze indicatie is geboden: afwijkingen van 50% naar boven of naar beneden zijn zeker mogelijk! Indien uitgegaan wordt van een conceptueel gegevensmodel bedraagt de indicatie van het aantal functiepunten: Aantal entiteittypen van het type interne logische gegevensverzameling uit het conceptueel gegevensmodel * 35 + aantal entiteittypen van het type koppelingsgegevensverzameling uit het conceptueel gegevensmodel * 15 Hierbij moeten de entiteittypen die van het type FPA-tabel zijn (zie paragraaf 4.20) én onderhouden worden door het te tellen informatiesysteem samen geteld worden als één entiteittype. Hetzelfde geldt voor de entiteittypen die van het type FPA-tabel zijn en door een ander informatiesysteem worden onderhouden. Voor FPA-tabellen worden dus maximaal twee entiteittypen geteld. De factor 35 gaat er vanuit, dat voor elke interne logische gegevensverzameling drie invoerfuncties (toevoegen, wijzigen, verwijderen), twee uitvoerfuncties, één opvragingsfunctie en enige generieke functionaliteit aanwezig zullen zijn. Hierbij wordt een lage complexiteit van de interne logische gegevensverzameling verondersteld (7 functiepunten), gemiddeld van de transacties (3x4 + 2x5 + 4 = 26 functiepunten) en 2 functiepunten voor de generieke functionaliteit. De factor 15 gaat uit van een eenvoudige koppelingsgegevensverzameling (5 functiepunten), een uitvoerfunctie en een opvragingsfunctie (9 functiepunten) en enige generieke functionaliteit (1 functiepunt) per koppelingsgegevensverzamling. Als men over een gegevensmodel in de derde normaalvorm beschikt geldt als indicatie voor het aantal functiepunten: Aantal entiteittypen van het type interne logische gegevensverzameling 2 In NESMA-verband is een rapport verschenen dat uitgebreid hierop ingaat. De titel van het handboek is: De toepassing van FPA in de eerste fasen van systeemontwikkeling. DEFINITIES en TELRICHTLIJNEN FPA 11

22 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA uit het genormaliseerd gegevensmodel * 25 + aantal entiteittypen van het type koppelingsgegevensverzameling uit het genormaliseerd gegevensmodel * 10 Ook hierbij moeten de entiteittypen die van het type FPA-tabel zijn (zie paragraaf 4.20) én onderhouden worden door het te tellen informatiesysteem samen geteld worden als één entiteittype. Hetzelfde geldt voor de entiteittypen die van het type FPA-tabel zijn en door een ander informatiesysteem worden onderhouden. Voor FPA-tabellen worden dus maximaal twee entiteittypen geteld. Toepasbaarheid Een indicatieve functiepuntentelling kan bijna altijd aan het einde van de fase requirements definitie worden uitgevoerd. In een groot aantal gevallen zal de indicatie zelfs al na de fase informatieplanning kunnen worden verkregen. De benodigde specificaties Uit bovenstaande blijkt al dat men moet beschikken over: Een conceptueel of een genormaliseerd gegevensmodel van het te tellen informatiesysteem. Een indicatie waar de onderscheiden logische gegevensverzamelingen worden onderhouden: door het te tellen informatiesysteem of door een ander informatiesysteem De globale functiepuntentelling Definitie Een globale functiepuntentelling is een functiepuntentelling waarbij per type gebruikersfunctie (gebruikerstransacties en logische gegevensverzamelingen) het aantal functies bepaald wordt, en waarbij voor de complexiteit een standaardwaarde wordt gehanteerd: gemiddeld voor de gebruikerstransacties en eenvoudig voor de logische gegevensverzamelingen. Toepasbaarheid Het moment waarop een globale functiepuntentelling kan worden uitgevoerd is in sterke mate afhankelijk van het moment waarop bepaalde specificaties opgeleverd worden. Dit is weer afhankelijk van de gehanteerde methode voor systeemontwikkeling. De benodigde specificaties De volgende specificaties moeten beschikbaar zijn voor een globale telling: Een (structuur)model dat de betrokken logische gegevensverzamelingen en hun onderlinge relaties toont. Een indicatie waar de onderscheiden logische gegevensverzamelingen worden onderhouden: door het te tellen informatiesysteem of door een ander informatiesysteem. Een model dat de systeemfuncties laat zien met hun in- en uitgaande informatiestromen. De informatiestromen die lopen tussen de functies van het te tellen informatiesysteem en zijn omgeving. 12 NESMA

23 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA De gedetailleerde functiepuntentelling Definitie De gedetailleerde functiepuntentelling is de meest nauwkeurige telling waarbij alle specificaties nodig voor FPA tot in detail bekend zijn. Dit houdt in dat de gebruikerstransacties tot op het niveau van gerefereerde logische gegevensverzamelingen en van data-element-typen gespecificeerd zijn en de logische gegevensverzamelingen tot op het niveau van recordtypen en data-element-typen. Hierdoor kan dus per onderkende gebruikersfunctie de complexiteit worden vastgesteld. Toepasbaarheid Het moment waarop een gedetailleerde telling uitgevoerd kan worden is afhankelijk van de gehanteerde faseringsmethode voor de levenscyclus van een informatiesysteem. De benodigde specificaties De volgende specificaties moeten beschikbaar zijn voor een gedetailleerde telling: Een model met alle logische gegevensverzamelingen en hun onderlinge relaties. Voorbeelden zijn: een Bachman-diagram en een Entiteit Relatie Diagram. De recordtypen en de data-element-typen van de logische gegevensverzamelingen. Een indicatie waar de onderscheiden logische gegevensverzamelingen worden onderhouden: door het te tellen informatiesysteem of door een ander informatiesysteem. Een model dat de systeemfuncties laat zien met hun in- en uitgaande informatiestromen en de bij de functies betrokken logische gegevensverzamelingen, alsmede de ondersteunende functies (helpfuncties en dergelijke). Een detaillering van de (in- en uitgaande) informatiestromen van het informatiesysteem tot op het niveau van data-element-typen. 3.3 De rol van de kwaliteit van de specificaties Ongeacht het type functiepuntentelling (zoals beschreven in paragraaf 3.2) geldt dat voor het uitvoeren van een functiepuntentelling gedegen functionele specificaties van het informatiesysteem nodig zijn. Deze specificaties kunnen het eenvoudigst gemaakt worden als op een standaard manier en methodisch gewerkt wordt. De tendens is dat men bij softwareontwikkeling steeds meer overgaat tot het gebruik van alom aanvaarde methoden. Afhankelijk van de gebruikte methode kan de vorm van de geproduceerde specificaties verschillen. De functiepuntentelling echter zou voor hetzelfde informatiesysteem steeds tot hetzelfde resultaat moeten leiden. De betrouwbaarheid van een FPA is direct afhankelijk van de kwaliteit van de specificaties. Bij kwalitatief goede specificaties zal de omzetting naar functiepunten weinig moeite kosten en een betrouwbare telling opleveren. Bij slechte en onvolledige specificaties kan het onmogelijk blijken een FPA uit te voeren of het resultaat van de telling zal, door uiteenlopende interpretaties van de specificaties, per persoon aanzienlijk kunnen verschillen. 3.4 FPA gedurende een project Tijdens de gehele duur van een systeemontwikkelingsproject speelt FPA een rol. Tijdens de planningsfase van een project wordt een initiële functiepuntentelling uitgevoerd. Tijdens het project worden, zodra wijzigingsverzoeken worden ingediend op reeds vastgestelde specificaties, tussentijdse functiepuntentellingen uitgevoerd. Als een project afgerond is, wordt in de definitieve functiepuntentelling bepaald, hoe groot het opgeleverde product is en wat de DEFINITIES en TELRICHTLIJNEN FPA 13

24 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA projectomvang geweest is. Hierbij doet het er niet toe welke fasen van de levenscyclus van het informatiesysteem in het kader van het project worden uitgevoerd. Ongeacht de inhoud van het project is er steeds sprake van een initiële en een definitieve functiepuntentelling en is er soms sprake van één of meer tussentijdse functiepuntentellingen. Een initiële functiepuntentelling is: Een telling bij aanvang van een project voor de nieuwbouw van een informatiesysteem of voor het wijzigen van een informatiesysteem (toevoegen en/of wijzigen en/of verwijderen van functionaliteit), waarbij enerzijds de productomvang (zie paragraaf 3.5) en anderzijds de projectomvang (zie paragraaf 3.6) wordt vastgesteld. Een initiële functiepuntentelling moet worden uitgevoerd bij de aanvang van een project. Afhankelijk van de beschikbare specificaties is dit een indicatieve, globale of gedetailleerde functiepuntentelling. Het doel van de initiële functiepuntentelling is het opstellen van een begroting voor het project in termen van inspanning en doorlooptijd. Een tussentijdse functiepuntentelling is: Een telling tijdens een project, waarbij de omvang van een functionele wijziging (toevoegen en/of wijzigen en/of verwijderen van functionaliteit) wordt vastgesteld. Hierbij wordt de invloed van de wijziging op zowel de productomvang (zie paragraaf 3.5) als de projectomvang (zie paragraaf 3.6) vastgesteld. Een tussentijdse functiepuntentelling moet worden uitgevoerd wanneer de functionele specificaties worden gewijzigd. Afhankelijk van de beschikbare specificaties is dit een indicatieve, globale of gedetailleerde functiepuntentelling. Het doel van de tussentijdse functiepuntentelling is het bepalen van de invloed van wijzigingsverzoeken op de met de opdrachtgever overeengekomen prijs en opleverdatum. Een definitieve functiepuntentelling is: Een telling aan het einde van een project voor de nieuwbouw van een informatiesysteem of voor het wijzigen van een informatiesysteem (toevoegen en/of wijzigen en/of verwijderen van functionaliteit), waarbij enerzijds de definitieve productomvang (zie paragraaf 3.5) en anderzijds de definitieve projectomvang (zie paragraaf 3.6) wordt vastgesteld. Het moment van tellen ligt aan het einde van een project. Het project kan betrekking hebben op de nieuwbouw van een informatiesysteem of op het realiseren van functionele wijzigingen tijdens de operationele fase Het doel van de definitieve functiepuntentelling is enerzijds het vaststellen van de omvang van het informatiesysteem, uitgedrukt in functiepunten, en anderzijds het bepalen van de omvang van het project, zodat de productiviteit bepaald kan worden en bijvoorbeeld een afrekening over het project kan plaatsvinden indien er een vaste prijs per functiepunt was overeengekomen. 3.5 Het bepalen van de productomvang Zoals in paragraaf 2.2 is aangegeven, kan FPA worden gebruikt voor het bepalen van de productomvang, of voor het bepalen van de projectomvang. In deze paragraaf wordt het gebruik van FPA bij het bepalen van de productomvang belicht. Bij het tellen van informatiesystemen gaat het om het bepalen van de omvang van de aan de gebruiker te leveren of geleverde functionaliteit, ofwel de productomvang. Daarbij moet uitgegaan worden van de functionele specificaties van een informatiesysteem en niet van fysieke componenten, zoals programma s en fysieke bestanden. 14 NESMA

25 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Het bepalen van de productomvang kan bij nieuwbouw van een informatiesysteem op een andere wijze plaatsvinden dan bij onderhoud van een informatiesysteem. In beide gevallen moet eerst de systeemgrens bepaald worden. Dit, evenals de telwijze bij nieuwbouw respectievelijk onderhoud, wordt in onderstaande paragrafen verder toegelicht Het bepalen van de systeemgrens De systeemgrens is: De grens tussen het (te ontwikkelen of ontwikkelde) informatiesysteem en zijn omgeving (gebruikers/andere informatiesystemen). In het kader van dit handboek wordt onder een informatiesysteem verstaan: Een geautomatiseerd informatiesysteem; dit is een systeem voor het verzamelen, bewaren, bewerken en presenteren van gegevens door middel van een computer. De volgende richtlijnen kunnen helpen bij het bepalen van de systeemgrens: Het door de systeemgrens afgebakende informatiesysteem moet een zelfstandig geheel vormen dat in grote mate los van andere informatiesystemen kan functioneren. Stel vast wie de eigenaar/hoofdgebruiker is. Als meerdere eigenaren/hoofdgebruikers zijn, is er vaak sprake van meerdere informatiesystemen. Kijk naar het informatiesysteem door de ogen van de gebruiker. Dus alleen naar dat deel van het informatiesysteem dat de gebruiker werkelijk kan waarnemen. Gebruik daarbij de specificaties die de buitenkant van het informatiesysteem, de systeemcontext, beschrijven. Dit kan bijvoorbeeld een contextdiagram zijn. Bepaal wat zich binnen het informatiesysteem bevindt en wat zich er buiten bevindt. Alleen die zaken die door de gebruiker gevraagd en voor hem relevant zijn, zijn van belang voor de functiepuntentelling. Bij een informatiesysteem kan men denken aan een groep van programma s die als één geheel wordt onderhouden. De systeemgrens omsluit deze groep van programma s. Alle functies binnen deze grens moeten als een geheel geteld en vastgelegd worden De productomvang van nieuwe informatiesystemen Het gaat hier om het bepalen van de productomvang van informatiesystemen die gebouwd worden of zijn op verzoek van een gebruiker of gebruikersorganisatie en die een oplossing bieden voor de wensen van die gebruiker of gebruikersorganisatie. Het bepalen van de productomvang bij de nieuwbouw van een informatiesysteem geschiedt op de in paragraaf 3.1 aangegeven wijze. Indien het informatiesysteem in één project wordt gerealiseerd, verschilt het bepalen van de productomvang niet van het bepalen van de projectomvang bij nieuwbouwprojecten (zie paragraaf 3.6.2). Let echter op dat bij de productomvang van een informatiesysteem de omvang van eventuele conversieprogrammatuur niet meegeteld mag worden. Indien het informatiesysteem wordt gerealiseerd in de vorm van een aantal parallel uitgevoerde deelprojecten, dan moet voor het bepalen van de productomvang naar de totale, door alle deelprojecten geleverde functionaliteit gekeken worden. Hierbij moet men er op toezien dat functionaliteit die in meer dan één deelproject aanwezig is (zoals een gegevensverzameling) niet dubbel geteld wordt. Als sprake is van onderhoud op een bestaand informatiesysteem (het toevoegen en/of wijzigen en/of verwijderen van functionaliteit), dan moet de productomvang van het (gewijzigde) informatiesysteem bepaald worden op de in paragraaf aangegeven wijze. DEFINITIES en TELRICHTLIJNEN FPA 15

26 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA De productomvang van gewijzigde informatiesystemen Het gaat hierbij om het bepalen van de productomvang van informatiesystemen na een functionele wijziging. Zo n functionele wijziging kan in principe plaatsvinden in elke fase van de levenscyclus van het informatiesysteem, maar vindt meestal gedurende de realisatie of tijdens het gebruik en beheer plaats. Bij grote wijzigingen kan een apart project worden gedefinieerd, waarvoor naast de productomvang ook de projectomvang wordt bepaald. In alle gevallen wordt de productomvang na de wijziging op dezelfde manier vastgesteld. De te nemen stappen voor het bepalen van de nieuwe productomvang zijn: Stap 1: Bepaal het aantal functiepunten van het informatiesysteem vóór de wijziging (Prod-oud). Stap 2: Bepaal welke gebruikerstransacties en/of logische gegevensverzamelingen uit het bestaande informatiesysteem vervallen en bepaal hoeveel functiepunten zij vertegenwoordigen (Verw). Stap 3: Bepaal welke gebruikerstransacties en/of logische gegevensverzamelingen wijzigen. Bepaal het aantal functiepunten dat zij vóór (Voor-wijz) en ná (Na-wijz) de wijziging vertegenwoordigen. Stap 4: Bepaal welke gebruikerstransacties en/of logische gegevensverzamelingen toegevoegd worden aan het informatiesysteem en stel vast hoeveel functiepunten zij vertegenwoordigen (Toev). Stap 5: Bepaal de productomvang van het informatiesysteem na de wijziging (Prodnieuw) als volgt: Prod-nieuw = Prod-oud + Toev - Verw + (Na-wijz - Voor-wijz) De productomvang van opnieuw gebouwde informatiesystemen Indien een informatiesysteem vervangen wordt door een informatiesysteem met dezelfde functionaliteit, dan is de productomvang gelijk aan die van het te vervangen informatiesysteem. Indien functionele wijzigingen plaats vinden tijdens de vervanging dan kan de omvang van het product in functiepunten op twee manieren bepaald worden: Het vervangende informatiesysteem wordt beschouwd als een nieuw informatiesysteem. Er wordt dan geteld als beschreven in paragraaf De vervanging wordt beschouwd als een wijziging op het te vervangen informatiesysteem. Er wordt dan geteld als aangegeven in paragraaf Het resultaat (de productomvang) van beide telwijzen is gelijk. 3.6 Het bepalen van de projectomvang Zoals in paragraaf 2.2 is aangegeven, kan FPA worden gebruikt voor het bepalen van de productomvang, of voor het bepalen van de projectomvang. In deze paragraaf wordt het gebruik van FPA bij het bepalen van de projectomvang belicht. Het bepalen van de omvang van een project ofwel het tellen van het aantal functiepunten van een project wijkt in een aantal gevallen af van het zuiver en alleen tellen van de productomvang, zijnde de hoeveelheid geboden of te bieden functionaliteit. Dit komt doordat de benodigde inspanning niet altijd ten goede komt aan extra geboden functionaliteit. Denk aan de te leveren 16 NESMA

27 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA inspanning voor het verwijderen van functionaliteit of voor het maken van eenmalig te gebruiken functionaliteit voor het converteren van gegevens. In de onderstaande paragrafen wordt voor een aantal projectsituaties uiteengezet hoe de projectomvang bepaald kan worden. Onderstaande tabel geeft een voorbeeld van het bepalen van de project- en productomvang en de verschillen hiertussen. RELEASE 1 RELEASE 2 RELEASE 3 VOEG TOE Functie Punten WIJZIG Voor Na VERWIJDER Projectomvang in functiepunten Productomvang in functiepunten Voeg toe +200 Voeg toe +500 Wijzig na +100 Wijzig na +200 Subtotaal +300 Subtotaal +700 Verwijder +40 Verwijder +100 TOTAAL 340 TOTAAL 8000 Rel 1: 1000 Rel 2: 1180 Voeg toe +200 Voeg toe +500 Wijzig na +100 Wijzig na +200 Wijzig voor -80 Wijzig voor -220 Verwijder -40 Verwijder -100 TOTAAL 1180 TOTAAL 1560 Het bepalen van de projectomvang kan bij nieuwbouw van een informatiesysteem op een andere wijze plaatsvinden dan bij onderhoud van een informatiesysteem. In beide gevallen moeten eerst de relevante systeemgrenzen bepaald worden. Dit en de telwijze bij nieuwbouw respectievelijk onderhoud, wordt in onderstaande paragrafen verder toegelicht Het bepalen van de scope van een projecttelling De scope van een functiepuntentelling is: De set van functionele requirements/specificaties van een nieuwbouw- of een onderhoudsproject waarop de functiepuntentelling is gebaseerd. Dit kan één of meer informatiesystemen omvatten. Om deze reden kunnen meerdere systeemgrenzen (zoals beschreven in ) bepaald moeten worden. Uit bovenstaande definitie blijkt dat twee soorten projecten onderscheiden worden: nieuwbouwen onderhoudsprojecten. DEFINITIES en TELRICHTLIJNEN FPA 17

28 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Met een nieuwbouwproject wordt bedoeld: Een project waarin een volledig nieuw informatiesysteem wordt gerealiseerd. Daarbij kan dit project opgedeeld worden in een aantal deelprojecten, die elk verantwoordelijk zijn voor de realisatie van een bepaald subsysteem van het totale informatiesysteem. Ieder deelproject moet nu beschouwd worden als een afzonderlijk nieuwbouwproject. Het opnieuw bouwen van een bestaand informatiesysteem (re-engineering) wordt als nieuwbouw beschouwd. Binnen het kader van FPA wordt onder een onderhoudsproject het volgende verstaan: Een project waarin functionele wijzigingen met betrekking tot een bestaand informatiesysteem worden uitgevoerd. Hierbij kan, in een bestaand informatiesysteem, functionaliteit toegevoegd en/of gewijzigd en/of verwijderd worden. Een functionele wijziging is als volgt gedefinieerd: De activiteiten ten behoeve van een informatiesysteem waarbij de specificaties en dientengevolge meestal ook de functiepuntentelling wijzigen. Denk aan change requests. De volgende richtlijnen kunnen helpen bij het bepalen van de scope van de projecttelling: Kijk naar het te realiseren informatiesysteem door de ogen van de gebruiker. Niet de fysieke maar de logische structuren dienen te worden beschouwd. Een informatiesysteem kan ontwikkeld worden in de vorm van een aantal min of meer parallel uit te voeren deelprojecten die elk een subsysteem realiseren. De scope van zo n deelprojecttelling omvat dan een subsysteem. Als de subsystemen dusdanig zijn, dat ze zelfstandig moeten kunnen bestaan (bijvoorbeeld in verband met de gefaseerde invoering van het informatiesysteem of om functionele redenen), dan wordt de uitwisseling van gegevens tussen de subsystemen meegenomen in de functiepuntentelling van ieder deelproject. De grens van het informatiesysteem omvat alle deelprojecten, waardoor de interfaces tussen de subsystemen binnen de totale systeemgrens vallen. De projectomvang is de som van het aantal functiepunten van de deelprojecten en kan hoger zijn dan het aantal functiepunten van het totale informatiesysteem (de productomvang) omdat in deze situatie bijvoorbeeld een interne logische gegevensverzameling van het ene deelproject ook geteld wordt als interne logische gegevensverzameling of als koppelingsgegevensverzameling voor een ander deelproject dat er gebruik van maakt. Een praktische manier om na te gaan of een bepaalde functie binnen de grens van het door de gebruiker gevraagde informatiesysteem valt, is te vragen of hij werkelijk voor deze functie wil betalen. Raadpleeg in geval van twijfel, indien mogelijk, de gebruiker De projectomvang van nieuwbouwprojecten In een nieuwbouwproject wordt een volledig nieuw informatiesysteem gerealiseerd. Als een nieuwbouwproject wordt opgedeeld in een aantal deelprojecten dan moet ieder deelproject, voor het bepalen van de projectomvang, behandeld worden als een op zichzelf staand nieuwbouwproject. De te nemen stappen zijn: Stap 1: Bepaal het aantal functiepunten van ieder te realiseren (deel)systeem. Stap 2: Bepaal het aantal functiepunten van de conversieprogrammatuur. 18 NESMA

29 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Deze functiepunten dragen alleen bij aan de projectomvang. De benodigde conversieprogrammatuur levert geen extra functionaliteit op. Het is slechts een hulpmiddel voor eenmalig gebruik en maakt geen onderdeel uit van het te onderhouden informatiesysteem. Zie de praktijksituatie zoals beschreven in paragraaf Stap 3: Bepaal het aantal functiepunten van wijzigingen in andere systemen die binnen het project gerealiseerd worden (zie hiervoor de stappen 1 tot en met 5 van paragraaf 3.6.3). Deze functiepunten dragen bij aan de projectomvang. De nieuwe productomvang van de door het project geraakte informatiesystemen moet per informatiesysteem bepaald worden. Stap 4: De omvang van het project is de som van het bij de punten 1, 2 en 3 vastgestelde aantal functiepunten. NB.: De projectomvang wordt vaak gebruikt ten behoeve van het begroten. Let op dat als er sprake is van het aanpassen van verschillende informatiesystemen, er vaak per informatiesysteem begroot moet worden, bijvoorbeeld omdat sprake is van verschillende ontwikkelomgevingen en daarom van verschillende productiviteitsnormen De projectomvang van onderhoudsprojecten 3 In een onderhoudsproject worden functionele wijzigingen met betrekking tot een bestaand informatiesysteem gerealiseerd. Hierbij kan voor dit informatiesysteem functionaliteit toegevoegd en/of gewijzigd en/of verwijderd worden. De stappen voor het bepalen van de projectomvang in functiepunten zijn: Stap 1: Bepaal welke gebruikerstransacties en/of logische gegevensverzamelingen uit het bestaande informatiesysteem vervallen en bepaal hoeveel functiepunten zij vertegenwoordigen (Verw). Stap 2: Bepaal welke gebruikerstransacties en/of logische gegevensverzamelingen wijzigen. Bepaal het aantal functiepunten dat zij ná de wijziging vertegenwoordigen (Na-wijz). Stap 3: Bepaal welke gebruikerstransacties en/of logische gegevensverzamelingen toegevoegd worden aan het informatiesysteem en stel vast hoeveel functiepunten zij vertegenwoordigen (Toev). Stap 4: Bepaal de projectomvang (Proj FP) voor het onderhoudsproject als volgt: Proj FP = Verw + Na-wijz + Toev Stap 5: Indien als gevolg van de wijzigingen conversieprogrammatuur gemaakt moet worden, bepaal dan ook het aantal functiepunten hiervan en tel dit aantal op bij 3 In NESMA-verband is het rapport Onderhoud en Functiepuntanalyse, richtlijnen verschenen dat uitgebreid ingaat op het gebruik van FPA bij onderhoud. De in dit rapport beschreven methode voor het tellen van onderhoudsprojecten is een nadere verfijning van de hier beschreven methode. DEFINITIES en TELRICHTLIJNEN FPA 19

30 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA NB.: de in stap 4 bepaalde projectomvang. Dit geldt ook voor eventuele noodzakelijke aanpassingen in andere systemen. Bij een onderhoudsproject worden bestaande interne logische gegevensverzamelingen en koppelingsgegevensverzamelingen die door de toe te voegen, te wijzigen of te verwijderen functies worden gebruikt maar zelf niet worden gewijzigd, niet geteld als interne logische gegevensverzameling of als koppelingsgegevensverzameling bij het bepalen van de projectomvang De projectomvang bij de vervanging van een informatiesysteem Het is vaak noodzakelijk om informatiesystemen die al lange tijd operationeel zijn te vervangen door informatiesystemen die efficiënter zijn en meer aan de eisen van de hedendaagse informatietechnologie tegemoet komen. Dit wordt dan gedaan in zogenaamde re-engineering projecten. Omdat in dit geval een volledig informatiesysteem gerealiseerd moet worden, geschiedt de bepaling van de projectomvang op dezelfde wijze als bij nieuwbouwprojecten (zie paragraaf 3.6.2). 3.7 FPA in specifieke situaties Men kan FPA in verschillende situaties toepassen. In elke situatie moet op een specifieke wijze met FPA omgegaan worden. In deze paragraaf wordt het gebruik van FPA in de volgende situaties toegelicht: het tellen op basis van traditionele ontwerpen; het tellen van pakketten; het tellen vanaf schermen; het toepassen van FPA bij prototyping; het tellen van GUI-omgevingen Het tellen op basis van traditionele ontwerpen Een traditioneel ontwerp beschrijft in de vorm van modellen de door de gebruiker gewenste functionaliteit. In het algemeen treft men enerzijds een gegevensmodel aan en anderzijds een functiemodel. Een gegevensmodel kan bijvoorbeeld de vorm hebben van een Entiteit Relatie Diagram, waaraan een beschrijving van de entiteittypen, attribuuttypen en relaties gekoppeld is. Het functiemodel kan bijvoorbeeld de vorm hebben van een Data Flow Diagram waaraan een beschrijving van de functies en van de gegevensstromen gekoppeld is. Bij het tellen op basis van een traditioneel ontwerp zijn de genoemde modellen de basis voor het maken van de FPA, evenals de vaak aangetroffen scherm- en lijstindelingen (deze laatste zijn niet noodzakelijk, maar wel handig). Uit het gegevensmodel worden de logische gegevensverzamelingen afgeleid en uit het functiemodel wordt bepaald welke gebruikerstransacties onderkend moeten worden. De grote voordelen van het maken van een FPA vanuit een traditioneel ontwerp zijn in de eerste plaats dat hierdoor geteld wordt vanuit de gevraagde en beschreven functionaliteit, waarbij technische overwegingen nog nauwelijks een rol een spelen, en in de tweede plaats dat het ontwerp ook een volledige weergave van de gevraagde functionaliteit is Het tellen van pakketten Een pakket dat in een organisatie wordt ingevoerd, vertegenwoordigt een bepaalde hoeveelheid functionaliteit. 20 NESMA

31 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA De functiepuntentelling uitgevoerd tijdens de fase waarin de specificaties worden vastgesteld, is een afspiegeling van de hoeveelheid door de gebruiker gewenste functionaliteit. Deze telling is onafhankelijk van de te kiezen oplossing en staat los van het al of niet invoeren van een pakket. Aan het einde van de specificatiefase wordt beslist om het informatiesysteem te bouwen of om een pakket te kopen dat voldoet aan de functionele eisen. De wijze waarop geteld moet worden hangt sterk af van de beschikbare documentatie van het pakket. De aanpak wijkt verder niet af van de in paragraaf 3.1 gegeven aanpak. Hieronder wordt ingegaan op de wijze waarop de logische gegevensverzamelingen en de gebruikerstransacties van het pakket gelokaliseerd kunnen worden. Algemeen Wanneer een pakket als oplossing gekozen is, is de eerste stap na te gaan of er een geschikt pakket beschikbaar is dat kan draaien binnen de gewenste technische infrastructuur. Indien dit zo is, moet van het gekozen pakket bepaald worden: 1. Welke door de gebruiker gewenste functionaliteit kan door het pakket geleverd worden en wat is het aantal functiepunten hiervan. 2. Welke door de gebruiker gewenste functionaliteit kan niet door het pakket geleverd worden en wat is het aantal functiepunten hiervan. 3. Welke niet door de gebruiker gewenste functionaliteit biedt het pakket en wat is het aantal functiepunten hiervan. Groep 1 vertegenwoordigt dat deel van de tijdens de specificatiefase getelde functiepunten dat door het pakket geleverd kan worden. Groep 2 vormt het aantal gewenste maar niet geleverde functiepunten. In de voor de gebruiker nuttige productomvang van het pakket, die alleen een afspiegeling van de gewenste geleverde functionaliteit moet zijn, moeten deze functiepunten niet meegeteld worden. Als vervolgens wordt besloten om het pakket uit te breiden zodat het aan alle oorspronkelijke gebruikerseisen voldoet, moet deze uitbreiding behandeld worden als een functionele wijziging (zie de paragrafen en 3.6.3). Groep 3, het surplus aan functionaliteit dat een pakket biedt, kan natuurlijk een overweging zijn om voor een bepaald pakket te kiezen. Deze extra functionaliteit valt echter buiten het aandachtsgebied van het oorspronkelijke project, terwijl er wel voor betaald moet worden; het is onderdeel van de totale productomvang van het pakket, maar het is geen onderdeel van de effectieve en voor de gebruiker nuttige productomvang. Het grote voordeel van het gebruik van FPA bij het verwerven van pakketten is dat de aandacht gericht is op de relatie tussen de geleverde functionaliteit en de kostenfactoren die een rol spelen bij de beslissing om zelf een informatiesysteem te maken of om een pakket te kopen. Met behulp van FPA wordt een afweging tussen maken en kopen mogelijk op basis van functionaliteit, kosten en snelheid waarmee de functionaliteit beschikbaar is. Het tellen van pakketten heeft dus drie mogelijke doelen: Vaststellen van de prijs/prestatieverhouding van het pakket (wat kost het per functiepunt); hierbij dienen alleen de functiepunten van de door de gebruiker/opdrachtgever geëiste functionaliteit die door het pakket geleverd wordt, te worden meegenomen. Vaststellen van de verhouding tussen de door gebruiker/opdrachtgever geëiste functionaliteit die door het pakket wordt geleverd en de totale door de gebruiker/- opdrachtgever geëiste functionaliteit. DEFINITIES en TELRICHTLIJNEN FPA 21

32 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Vaststellen van de verhouding tussen de door gebruiker/opdrachtgever geëiste functionaliteit die door het pakket wordt geleverd en de totale door het pakket geboden functionaliteit. Bepalen van de logische gegevensverzamelingen van een pakket Bij de aanschaf van een pakket maakt een gebruikersinformatiemodel meestal geen onderdeel uit van de bijgeleverde documentatie. In sommige gevallen heeft men de beschikking over een gegevensmodel in de derde normaalvorm van het pakket. De logische gegevensverzamelingen kunnen hieruit afgeleid worden. Hanteer daarbij dan de richtlijnen uit de paragrafen 4.20 en 4.21 en de hoofdstukken 5 en 6. Indien er noch een gebruikersinformatiemodel noch een gegevensmodel in de derde normaalvorm aanwezig is, stel dan aan de hand van de geboden functionaliteit vast welke logische gegevensverzamelingen waarschijnlijk te onderkennen zijn. Het een en ander kan ook afgeleid worden uit de fysieke databasestructuur. Bepalen van de gebruikerstransacties van een pakket Indien de functionele specificaties of een gebruikshandleiding beschikbaar zijn, moeten hieruit de geboden gebruikerstransacties zo goed mogelijk bepaald worden. Indien de verstrekte documentatie onvoldoende is en een proef- of demonstratie-implementatie van het pakket beschikbaar is, kunnen de gebruikerstransacties vanaf het scherm bepaald worden, zie hiervoor verder paragraaf Is alleen de menustructuur beschikbaar, probeer dan daaruit de functies af te leiden. Kies bij een menuoptie zoals muteren standaard voor drie invoerfuncties (invoeren, wijzigen en verwijderen). Kies bij een menuoptie zoals tonen standaard voor één opvragingsfunctie en één uitvoerfunctie. Bepalen van de vereiste functionaliteit Bij het bepalen van de vereiste functionaliteit moet men uitgaan van de functionele eisen die de gebruiker/opdrachtgever stelt aan een pakket. Met andere woorden: alleen die delen van het pakket worden gewaardeerd die van te voren door de gebruiker gespecificeerd zijn. Bij de telling moet dus worden uitgegaan van de functionele specificaties van de gebruiker/ opdrachtgever. Indien de functionele eisen niet beschreven zijn, moeten deze in overleg met de gebruiker alsnog vastgesteld worden door na te gaan welke logische gegevensverzamelingen en welke functies van het pakket relevant zijn (zie eerder in deze paragraaf hoe de logische gegevensverzamelingen en gebruikerstransacties bepaald kunnen worden). Functionaliteit die door het pakket wordt geboden, maar niet specifiek door de gebruiker is gevraagd, moet wel bij het bepalen van de totale productomvang van het pakket worden meegenomen, maar niet bij het bepalen van de effectieve (dit is de voor de gebruiker nuttige) productomvang Het tellen vanaf schermen Het komt bij pakketten en bestaande informatiesystemen nogal eens voor dat geschikte documentatie om een functiepuntanalyse uit te voeren ontbreekt. Indien de functionele specificaties ontbreken of onvolledig zijn kan het noodzakelijk zijn om (een deel van) de gebruikersfuncties af te leiden van de fysieke componenten van het systeem. Een mogelijkheid is dan om het desbetreffende informatiesysteem op te starten en te tellen vanaf het scherm. 22 NESMA

33 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Hierbij moeten de gebruikersfuncties worden opgespoord door elke tak van de menuboom af te lopen tot aan de invoer- en uitvoerschermen. Deze invoer- en uitvoerschermen zijn een afspiegeling van de geboden functionaliteit. Ook een gebruikshandleiding kan in zo n geval een goed hulpmiddel zijn om de geboden functionaliteit vast te stellen. Let bij de gebruikersfuncties die zo gevonden worden op de volgende punten: Voorkom dubbeltellingen: dezelfde gebruikerstransactie kan op meerdere plaatsen in de menustructuur voorkomen. Let op vervolgschermen: onlosmakelijk met elkaar verbonden schermen definiëren samen meestal slechts één gebruikerstransactie. Indien een scherm vervolgschermen heeft die niet onlosmakelijk met het voorgaande scherm verbonden zijn, resulteren de vervolgschermen meestal in nieuwe gebruikerstransacties, tenzij de nieuwe gebruikerstransacties die zo gevonden worden al op een andere plaats geteld zijn. Leid uit de schermen en de menustructuur af welke rapporten het informatiesysteem aanmaakt. Tel elk afzonderlijk rapport als één uitvoerfunctie. Soms kan een rapport met eenzelfde indeling via verschillende media worden afgedrukt (bijvoorbeeld beeldscherm en printer). Wanneer daarbij de logische verwerking niet verschilt (zie paragraaf 8.1), moet slechts één uitvoerfunctie worden geteld. Een opvragingsfunctie mag alleen geteld worden indien zij expliciet zo benoemd is in de menustructuur. Het tonen van gegevens komt in de praktijk nogal eens voor als onderdeel van een invoerfunctie (namelijk bij het wijzigen en/of verwijderen van gegevens): in dit geval wordt dit niet als opvragingsfunctie geteld. Tel lijstfuncties zoals in paragraaf 4.16 is aangegeven. Probeer uit de menuopties ook te bepalen welke transactiebestanden er zijn. Tel deze respectievelijk als in- of uitvoerfuncties. Probeer ook te achterhalen hoeveel invoer- en uitvoerfuncties per transactiebestand onderkend moeten worden. Probeer uit de onderhoudsfuncties af te leiden welke logische gegevensverzamelingen de gebruiker kan onderhouden, dus welke interne logische gegevensverzamelingen er zijn. In het algemeen zal men bij het tellen vanaf schermen de complexiteit van de gebruikerstransacties en logische gegevensverzamelingen niet kunnen onderbouwen. Waardeer daarom iedere gebruikerstransactie als gemiddeld en iedere logische gegevensverzameling als eenvoudig. Tel de menustructuren zoals in paragraaf 4.15 is aangegeven. Probeer inzicht te krijgen op periodiek uitgevoerde (batch)functies. Soms is uit opmerkingen op schermen en/of menu s op te maken dat er (bijvoorbeeld s nachts) een mutatierun zal lopen of gelopen moet hebben Het tellen bij prototyping De naam prototyping wordt voor twee verschillende situaties gebruikt: Als strategie bij het vaststellen van de functionele specificaties. Als hulpmiddel om bij bekende functionele specificaties de indeling van schermen en dialogen te ontwikkelen. Onderstaand wordt op beide situaties ingegaan. Prototyping om de specificaties vast te stellen Wanneer prototyping als ontwerpstrategie wordt gebruikt voor het vaststellen van de specificaties van het informatiesysteem, moet men voorzichtig zijn met het toepassen van FPA. DEFINITIES en TELRICHTLIJNEN FPA 23

34 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Prototyping wordt veelal toegepast bij onzekerheid omtrent het informatieprobleem en omtrent de eisen die de gebruikers stellen aan een oplossing voor dat probleem. Oorzaken van deze onzekerheid zijn te vinden in een communicatiekloof tussen ontwikkelaar en gebruiker, en in een verschuiving van informatiebehoefte die optreedt wanneer de gebruiker ervaring opdoet met het informatiesysteem. Zolang er nog geen zekerheid bestaat over de uiteindelijke functionaliteit van het te ontwikkelen informatiesysteem zal een functiepuntentelling geen betrouwbaar inzicht geven in de uiteindelijke omvang van dit informatiesysteem. Eventueel kan een indicatieve functiepuntentelling worden uitgevoerd indien al wel een (rudimentair) gegevensmodel beschikbaar is. Belangrijk is echter dat ook bij prototyping de specificaties worden gedocumenteerd, zodat er aan het einde van de prototyping-cyclus een functiepuntentelling kan worden uitgevoerd. Prototyping bij het ontwerpen van de gebruikersinterface Wordt prototyping gebruikt voor het ontwerpen van de gebruikersinterface en staan de functionele specificaties van het begin af aan al vast, dan gelden de normale richtlijnen voor FPA en kunnen deze zonder risico worden toegepast Het tellen van GUI-omgevingen In een omgeving waarbinnen gebruik gemaakt wordt van een Graphical User Interface (GUI), presenteert een informatiesysteem zich heel anders naar een gebruiker dan in een traditionele omgeving. Binnen een GUI-omgeving spelen windows een belangrijke rol. Hiervan kunnen er meerdere tegelijk op het scherm aanwezig zijn. Een gebruiker kan via windows zowel informatie ontvangen als doorgeven met behulp van de muis en het toetsenbord. De windows hebben een standaard opbouw en beschikken vaak over standaardvoorzieningen zoals vergroten, verkleinen, verplaatsen, bladeren en selectie van gegevens. Verder kenmerkt zich een dergelijke omgeving door het gebruik van iconen, scroll bars, radio buttons, check boxes, push buttons, list buttons, container windows, list boxes, clip boards, en dergelijke. Binnen een GUI-omgeving wordt FPA als volgt toegepast. De algemene leidraad luidt: kijk door de verpakking (het fraaie cadeaupapiertje ) heen en distilleer de feitelijk door het informatiesysteem geboden functionaliteit in termen van interne logische gegevensverzamelingen, koppelingsgegevensverzamelingen, invoer-, uitvoer- en opvragingsfuncties. De volgorde waarin windows in een gebruikerstransactie doorlopen worden, dient in zijn geheel te worden bezien. De afzonderlijke onderdelen van een window, hoe fraai ook vormgegeven, leiden niet tot extra FPA-functies. Veel van de onderdelen komen in een traditionele omgeving overeen met een tekstveld, en worden overeenkomstig als data-element-type geteld. Functionaliteit die door de GUI-omgeving wordt geboden, of functionaliteit die binnen de betreffende GUI-omgeving standaard wordt verwacht en door voorzieningen in de GUIomgeving (bijna) automatisch wordt verkregen, kan gezien worden als een uitbreiding van het besturingssysteem en leidt niet tot het tellen van extra functies of data-element-typen. 3.8 Illustratie: FPA tijdens fasen van systeemontwikkeling Een functiepuntentelling kan alleen worden uitgevoerd wanneer er een bepaald minimum aan specificaties aanwezig is. Welke specificaties beschikbaar zijn en de vorm waarin deze worden aangeboden is afhankelijk van de fase waarin de systeemontwikkeling zich bevindt, de aard van het project, en de methoden die worden gebruikt. In deze paragraaf wordt dit toegelicht, waarbij ter illustratie van een waterval faseringsmethode voor de levenscyclus van een informatiesysteem is uitgegaan. Het wordt aan de lezer 24 NESMA

35 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA overgelaten om deze tegen de door zijn organisatie gehanteerde methoden te houden en een vertaling te maken FPA gedurende de fase definitiestudie In deze fase wordt beoordeeld of het ontwikkelen van een nieuw of verbeterd informatiesysteem in technisch, economisch, sociaal en organisatorisch opzicht haalbaar en zinvol is. Het is de eerste stap in de ontwikkeling van een bepaald informatiesysteem. Binnen de grenzen vastgesteld tijdens informatieplanning is men bezig het probleemgebied te analyseren en alle systeemeisen te specificeren: Hoe ziet het bestaande informatiesysteem eruit? Welke functionaliteit moet door het informatiesysteem geleverd worden? Hoe kunnen gebruikers met het informatiesysteem werken? Welke eisen worden aan de kwaliteit gesteld? Welke delen van bestaande, geplande of standaard hardware en software kunnen gebruikt worden? Hoe moet de overgang van de bestaande naar de gewenste situatie plaatsvinden? Dit zal resulteren in: een model van de bedrijfsactiviteiten; de basiseisen voor het te realiseren informatiesysteem; een specificatie van de omgevingseisen van het te realiseren informatiesysteem; eisen ten aanzien van de technische kenmerken; een globaal gegevensmodel. Moment van tellen en soort telling De specificaties aan het einde van deze fase moeten worden opgeleverd zijn niet altijd voldoende voor de uitvoering van een globale functiepuntentelling (zie paragraaf 3.2.2), maar meestal wel voldoende voor een indicatieve functiepuntentelling (zie paragraaf 3.2.1). Men moet zich er wel van bewust zijn dat bij een telling in de fase definitiestudie de omvang van het informatiesysteem gewoonlijk te laag geschat wordt. Dit komt door het hoge abstractieniveau van deze specificaties, waardoor relevante details verborgen kunnen blijven. Uit ervaringen van FPA-gebruikers blijkt, dat de mate waarin te laag geschat wordt binnen een organisatie constant is. Iedere organisatie dient voor zichzelf een norm te bepalen om dit te compenseren. Deze compensatie kan aangeduid worden als een onzekerheidstoeslag. Doel van het tellen Het doel van deze telling is het krijgen van een eerste indicatie van de omvang van het te ontwikkelen informatiesysteem. Deze schatting kan gebruikt worden bij: het bepalen van de benodigde resources voor het te ontwikkelen informatiesysteem; het begroten van het project voor het ontwerp van het informatiesysteem; het bepalen van een budget voor de ontwikkelafdeling; het beoordelen van offertes bij uitbesteding van de verdere fasen van systeemontwikkeling. Vereiste documentatie De documentatie moet minimaal de specificaties bevatten als vermeld in paragraaf DEFINITIES en TELRICHTLIJNEN FPA 25

36 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA FPA gedurende de fase basisontwerp Tijdens het basisontwerp verschuift de aandacht van het analyseren van bedrijfsactiviteiten naar het specificeren van het informatiesysteem dat deze activiteiten moet ondersteunen. Het specificeren van het informatiesysteem vereist een begrip van alle aspecten van de informatie die in de gegevensverzameling(en) moet worden opgeslagen en van de manier waarop de gebruiker zal communiceren met het informatiesysteem. In feite wordt een aantal aspectmodellen gemaakt die kunnen worden beschouwd als de bestektekening van het te realiseren informatiesysteem. Dit zal resulteren in: een model dat aangeeft voor welk management en voor welke besturingsbeslissingen wanneer en waarom informatie nodig is (systelogisch model); een model dat beschrijft welke gegevens voor welke uitvoer nodig zijn en wat de betekenis van die gegevens is (infologisch model); een model waarin de structuur, de vorm en de samenhang van de gegevens van het te realiseren informatiesysteem zijn vastgelegd (datalogisch model); een model dat de technische eisen voor het te realiseren informatiesysteem vastlegt (technologisch model). Welke technieken hierbij gehanteerd worden en daarmee welke documentatie wordt opgeleverd, zal variëren per methode voor systeemontwikkeling. Moment van tellen en soort telling Tijdens de fase basisontwerp komen voldoende specificaties boven tafel om een globale functiepuntentelling te maken. Het tellen kan plaatsvinden op het moment dat de vereiste specificaties voor een globale telling aanwezig zijn. Dit kan op verschillende tijdstippen tijdens het basisontwerp, afhankelijk van de gebruikte methoden. Gewoonlijk echter zal geteld worden aan het einde van het basisontwerp. Men moet zich er wel van bewust zijn dat ook bij een telling in de fase basisontwerp de omvang van het informatiesysteem gewoonlijk te laag geschat wordt. Dit komt door het nog steeds relatief hoge abstractieniveau van deze specificaties, waardoor relevante details verborgen kunnen blijven. Uit ervaringen van FPA-gebruikers blijkt, dat de mate waarin te laag geschat wordt binnen een organisatie constant is. Iedere organisatie dient voor zichzelf een norm te bepalen om dit te compenseren. Deze compensatie kan aangeduid worden als een onzekerheidstoeslag. De onzekerheidstoeslag in de fase basisontwerp is lager dan die in de fase definitiestudie. Doel van het tellen Het doel van de functiepuntentelling aan het einde van de fase basisontwerp is het verkrijgen van een betere indicatie van de omvang van het te ontwikkelen informatiesysteem. Deze schatting kan gebruikt worden bij: het bepalen van de benodigde resources voor het te ontwikkelen informatiesysteem; het begroten van het project voor het te ontwikkelen informatiesysteem; het bepalen van een budget voor de ontwikkelafdeling; het beoordelen van offertes bij uitbesteding van de verdere fasen van systeemontwikkeling; het afrekenen van de fase basisontwerp, wanneer dit door middel van een contract op basis van nacalculatie is uitbesteed (hierbij wordt dan uitgegaan van een vaste prijs per gespecificeerde functiepunt); 26 NESMA

37 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA het vaststellen van meer/minderwerk ten opzichte van een eerdere telling. Vereiste documentatie De documentatie moet minimaal de specificaties bevatten als vermeld in paragraaf FPA gedurende de fase detailontwerp Tijdens het detailontwerp worden de ontwerpspecificaties zodanig uitgewerkt dat op basis daarvan handmatige procedures of computerprogramma s kunnen worden gerealiseerd. Tevens wordt de gegevensstructuur zodanig uitgewerkt dat aan de hand daarvan gegevensbestanden kunnen worden opgezet. Moment van tellen en soort telling Tijdens het detailontwerp komen alle specificaties die nodig zijn voor een gedetailleerde functiepuntentelling beschikbaar. Deze gedetailleerde functiepuntentelling zal dan ook gelijk zijn aan de definitieve functiepuntentelling indien er geen tussentijdse wijzigingen op de functionele specificaties in de vervolgfasen optreden. De telling kan evenals bij het basisontwerp tijdens of aan het eind van de fase worden gemaakt. Doel van het tellen Op basis van de gedetailleerde functiepuntentelling aan het eind van de fase detailontwerp kan het volgende plaatsvinden: het begroten van het verdere project voor de realisatie van het informatiesysteem; het schatten van de benodigde inspanning en financiële middelen; het beoordelen van een offerte voor het uitbesteden van de realisatiefase; het afrekenen van de fase detailontwerp, wanneer dit door middel van een contract op basis van nacalculatie is uitbesteed (hierbij wordt dan uitgegaan van een vaste prijs per gespecificeerde functiepunt); het vaststellen van meer/minderwerk ten opzichte van een eerdere telling. Vereiste documentatie De documentatie moet minimaal de specificaties bevatten als vermeld in paragraaf FPA gedurende de fase realisatie De realisatiefase omvat het daadwerkelijk bouwen en testen van het informatiesysteem. Indien men het informatiesysteem niet zelf bouwt, maar besluit tot de aanschaf van standaardprogrammatuur, omvat deze fase het evalueren van de diverse standaardpakketten en het uiteindelijk selecteren van één pakket. Moment van tellen en soort telling Tijdens de realisatie wordt slechts geteld als er wijzigingen plaatsvinden op de functionele specificaties. In feite wordt er dan teruggekeerd naar de fase basisontwerp of de fase detailontwerp omdat in deze fase de functionele specificaties worden gemaakt. Bij een dergelijke wijziging wordt opnieuw een zogenaamde tussentijdse functiepuntentelling uitgevoerd. De tussentijdse functiepuntentelling is in feite een functiepuntentelling waarbij de invloed van de wijziging op de projectomvang en de productomvang wordt bepaald. DEFINITIES en TELRICHTLIJNEN FPA 27

38 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Binnen één en hetzelfde project gaat het hierbij om kleine functionele wijzigingen. Indien er grote ingrijpende wijzigingen moeten plaatsvinden wordt gewoonlijk een nieuw project gedefinieerd. Aan het einde van de realisatiefase dient het uiteindelijk ontwikkelde informatiesysteem nogmaals geteld te worden om de uiteindelijke omvang van de gerealiseerde functionaliteit (de productomvang) te bepalen. Dit is een gedetailleerde functiepuntentelling. De gedetailleerde functiepuntentelling aan het einde van de realisatiefase is ook herleidbaar uit de gedetailleerde functiepuntentelling na het detailontwerp en alle tussentijdse functiepuntentellingen tijdens de realisatie. Doel van het tellen De doelen van de tussentijdse functiepuntentelling zijn in de eerste plaats het vaststellen van wat de bijkomende kosten bovenop de afgesproken vaste prijs zijn, met andere woorden het vaststellen van het meer/minderwerk, en in de tweede plaats het bepalen van de nieuwe omvang van het informatiesysteem, zodat ook een indicatie verkregen wordt van de invloed van de wijzigingen op het onderhoud en de exploitatie van het informatiesysteem. Het doel van de gedetailleerde functiepuntentelling aan het einde van de realisatiefase is het vaststellen van het aantal functiepunten dat onderhouden moet worden. Tevens kan de stabiliteit van het ontwerp afgemeten worden aan de hand van de eventuele groei in functiepunten. Aan de hand van de projectdocumentatie, de definitieve functiepuntentelling en het aan het project bestede aantal uren, kan worden nagegaan wat de productiviteit is geweest. Vereiste documentatie Het aan het eind van deze fase op te leveren document is niet van belang voor FPA. Wel van belang zijn de documenten uit de fasen basisontwerp en detailontwerp waarin de functionele wijzigingen zijn aangebracht. Aangaande de wijzigingen dient in ieder geval gespecificeerd te zijn wat is vermeld in paragraaf voor de globale en in paragraaf voor de gedetailleerde functiepuntentelling FPA gedurende de fase invoering Tijdens de invoeringsfase vinden eventueel benodigde organisatorische veranderingen plaats. Verder worden operationele gegevens geconverteerd en vindt de installatie plaats van zowel hardware als software. Opleidingen en het schrijven van de gebruikshandleiding vallen eveneens onder de invoering van een informatiesysteem. Moment van tellen en soort telling Binnen de invoeringsfase wordt geen functiepuntentelling uitgevoerd FPA gedurende de fase gebruik en beheer Het informatiesysteem is nu in werking en dient op een adequate manier beheerd en onderhouden te worden. Moment van tellen en soort telling Kleine functionele wijzigingen vallen gewoonlijk onder gebruik en beheer. Na zo n wijziging moet een gedetailleerde functiepuntentelling uitgevoerd worden om de omvang van de te beheren en te onderhouden functionaliteit opnieuw vast te stellen. 28 NESMA

39 HANDLEIDING VOOR HET UITVOEREN VAN EEN FPA Bij grote functionele wijzigingen wordt meestal een nieuw project gestart en vinden de tellingen plaats zoals hiervoor aangegeven. Doel van het tellen Tijdens deze fase kan gebruik gemaakt worden van de gedetailleerde functiepuntentelling van het operationele informatiesysteem om een relatie te leggen tussen de omvang van de te onderhouden functionaliteit en de vereiste onderhoudsinspanning. Een andere mogelijkheid, waarvan het de moeite waard is om te onderzoeken, is om een relatie te leggen tussen de hoeveelheid functiepunten van de geïnstalleerde informatiesystemen en de kosten van het in productie hebben van deze informatiesystemen op de beschikbare hardware. Vereiste documentatie Alle tot dan toe geproduceerde documentatie is aanwezig. De gedetailleerde functiepuntentellingen van alle geïnstalleerde en te onderhouden informatiesystemen moeten daarvan deel uitmaken. DEFINITIES en TELRICHTLIJNEN FPA 29

40 ALGEMENE RICHTLIJNEN 4 ALGEMENE RICHTLIJNEN In dit hoofdstuk zijn richtlijnen beschreven die algemeen gelden wanneer een functiepuntentelling gemaakt wordt. Iedere paragraaf van dit hoofdstuk geeft een algemene richtlijn voor FPA vanuit een bepaald gezichtspunt. De titels van de paragrafen geven aan wat dit gezichtspunt is. 4.1 Tellen vanuit logisch gezichtspunt Bij de uitvoering van een functiepuntentelling wordt uitgegaan van de bedrijfsactiviteiten. Een bedrijfsactiviteit kan ondersteund worden door één of meer gebruikersfuncties. Omgekeerd kan één gebruikersfunctie ook meerdere bedrijfsactiviteiten ondersteunen. Hoe een bepaald informatiesysteem technisch gerealiseerd wordt of is, dient buiten beschouwing te blijven. Het gaat immers om het logische gezichtspunt. De gebruikte technologie mag geen invloed hebben op het vastgestelde aantal functiepunten van een informatiesysteem. 4.2 Toepassing van de regels Gebruik van het gezonde verstand kan bij het toepassen van de richtlijnen nodig zijn. Leg altijd vast welke aanvullingen en verduidelijkingen zijn toegepast (en meld dit bij de werkgroep Telrichtlijnen met behulp van de laatste bladzijde van dit handboek: Commentaren en suggesties van de lezer ). Hanteer geen subjectieve overwegingen bij het vaststellen van de complexiteit van een gebruikersfunctie. 4.3 Gebouwde, niet gevraagde functionaliteit Tijdens de realisatie van een informatiesysteem kunnen stukken code van een bestaand informatiesysteem worden gekopieerd. Hierdoor kan er in het te bouwen informatiesysteem meer functionaliteit worden opgenomen dan alleen de gewenste. Ook kan het voorkomen dat ontwikkelaars niet gevraagde verfraaiingen in het informatiesysteem inbouwen, omdat ze dat mooier vinden. Ga daarom altijd na, of de geleverde functionaliteit ook werkelijk van het informatiesysteem wordt gevraagd. Niet-gevraagde functionaliteit telt wel mee voor het bepalen van de omvang van het geleverde product, maar niet voor het bepalen van de omvang van het gevraagde product. Onder gevraagde functionaliteit wordt zowel de initieel gespecificeerde functionaliteit begrepen, als de functionaliteit die het gevolg is van latere wijzigingsverzoeken. In schemavorm: vooraf/initieel gevraagde functionaliteit geleverde functionaliteit via wijzigingsverzoeken niet-gevraagde functionaliteit 4.4 Dubbeltellingen Binnen een informatiesysteem mag dezelfde functionaliteit maar één keer worden geteld, ongeacht het feit, of hiervan één of meer gebruikers gebruik maken. Zo wordt een logische gegevensverzameling binnen een informatiesysteem maar één keer geteld (als interne logische gegevensverzameling of als koppelingsgegevensverzameling, maar niet als beide). Een functie 30 NESMA

41 ALGEMENE RICHTLIJNEN wijzigen klant die meerdere keren binnen hetzelfde informatiesysteem voorkomt, wordt slechts één keer geteld, mits de functies in alle gevallen identiek zijn. 4.5 Produceren van herbruikbare code Soms wordt programmatuur of delen ervan zodanig algemeen opgezet, dat deze herbruikbaar is in andere informatiesystemen. Hierbij gaat het om programmatuur die als functionele eenheid ook buiten het informatiesysteem gebruikt kan worden. Dit heeft voor het informatiesysteem dat de programmatuur ontwikkelt geen gevolgen voor het aantal functiepunten. 4.6 Hergebruik van bestaande code Hergebruik van bestaande code bij de bouw van een informatiesysteem is het gebruik maken van bestaande programmatuur bij het realiseren van de gespecificeerde functionaliteit. Hergebruik maakt het eenvoudiger om bepaalde functionaliteit te realiseren. Deze functionaliteit wordt normaal meegeteld in de functiepuntentelling. Een goede handelwijze in zo n situatie is om voor delen van het informatiesysteem waarvoor volledig of gedeeltelijk hergebruik mogelijk is, te werken met een aangepaste productiviteitsnorm (minder uren per functiepunt). 4.7 Schermen en rapporten Rapporten en schermen zijn representaties van het berichtenverkeer tussen een informatiesysteem en zijn gebruiker(s). Als zodanig vormen ze fysieke structuren van berichten die worden uitgewisseld tussen het informatiesysteem en zijn omgeving. Als de beschrijving ontbreekt van de logische structuur, dat wil zeggen een beschrijving van de data-element-typen die tot de diverse beeldschermen en rapporten behoren, is het nodig deze af te leiden van de (fysieke) rapporten en schermen. De nodige voorzichtigheid moet hierbij betracht worden. Een fysieke structuur kan zijn opgebouwd uit meerdere logische structuren of omgekeerd. Zie de praktijksituaties zoals beschreven in de paragrafen 10.10, en Invoer- en uitvoerrecords Invoer- en uitvoerrecords zijn representaties van de communicatie tussen een informatiesysteem en andere informatiesystemen. Als zodanig vormen ze fysieke structuren van berichten die worden uitgewisseld tussen het informatiesysteem en zijn omgeving. Als de logische structuur ontbreekt, is het nodig deze af te leiden van de (fysieke) record layout. Hierbij moet eveneens de nodige voorzichtigheid betracht worden. Een fysiek record kan zijn opgebouwd uit meerdere logische structuren of omgekeerd. Zie de praktijksituatie zoals beschreven in paragraaf Beveiliging en autorisatie Beveiligings-, autorisatie- en logonfuncties zijn vaak standaard aanwezig en staan in principe ter beschikking van alle informatiesystemen. Ze worden daarom niet geteld. Indien deze functies echter voor het te tellen informatiesysteem moeten worden gerealiseerd, dan moeten ze in de functiepuntentelling worden meegenomen. Zie de praktijksituatie zoals beschreven in paragraaf 10.1 en DEFINITIES en TELRICHTLIJNEN FPA 31

42 ALGEMENE RICHTLIJNEN 4.10 Besturingssystemen en utilities Besturingssystemen en utilities zijn standaard aanwezig op vrijwel iedere machine en staan in principe ter beschikking van alle informatiesystemen. Ze worden daarom niet geteld. Het wijzigen en afstemmen van een besturingssysteem op een specifiek informatiesysteem vindt zijn weerslag in de productiviteit. Het voegt geen extra functionaliteit toe en moet dus niet geteld worden Rapportgeneratoren en query-faciliteiten Er kunnen drie soorten rapportgeneratoren en query-faciliteiten onderkend worden: standaard door de ontwikkelomgeving geboden faciliteiten, waarbij de gebruiker zelf de selecties en uitvoerproducten definieert; speciaal als onderdeel van de realisatie van het informatiesysteem gemaakte faciliteiten, waarbij de gebruiker zelf de selecties en uitvoerproducten definieert; reguliere uitvoer- en opvragingsfuncties, waarbij de selecties en uitvoerproducten vastliggen. Rapportgeneratoren en query-faciliteiten die standaard door de ontwikkelomgeving worden geboden, worden niet meegeteld bij het bepalen van de omvang van het project of van het informatiesysteem. Rapportgeneratoren en query-faciliteiten die op verzoek van de gebruiker moeten worden gebouwd, worden geteld alsof ze een onderdeel van het informatiesysteem zijn. Tel de functies (logische gegevensverzamelingen, invoer-, uitvoer- en opvragingsfuncties) op basis van het berichtenverkeer met de gebruiker dat nodig is voor het samenstellen van de uitvoerproducten en voor het bewaren van de gedefinieerde queries. Reguliere uitvoer- en opvragingsfuncties dienen geteld te worden zoals in de hoofdstukken 8 en 9 is aangegeven. Dit geldt ook als ze met behulp van een standaard rapportgenerator of queryfaciliteit zijn gemaakt! Zie de praktijksituatie zoals beschreven in paragraaf Grafieken Grafieken kunnen, net als rapporten, beschouwd worden als uitvoerfuncties. Het gaat dus niet om de techniek die nodig is om een bepaalde grafiek te maken en aan de gebruiker te tonen, maar om de informatie die erin gebruikt respectievelijk getoond wordt. Voor het bepalen van de complexiteit moet daarom uitgegaan worden van de data-element-typen die nodig zijn om zo n grafiek te produceren. Zie de praktijksituatie zoals beschreven in paragraaf Helpfaciliteiten Indien een informatiesysteem helpfaciliteiten kent, moet per soort helpfaciliteit één opvragingsfunctie voor het gehele informatiesysteem geteld worden. Voorbeelden van soorten helpfaciliteiten zijn: helpinformatie voor het gehele informatiesysteem; helpinformatie voor schermen; helpinformatie voor velden (waarbij inbegrepen: lijstfuncties met vaste waarden; zie paragraaf 4.16). 32 NESMA

43 ALGEMENE RICHTLIJNEN Bijvoorbeeld: indien bij ieder scherm helpinformatie opgevraagd kan worden, dient dit slechts één keer als opvragingsfunctie voor het informatiesysteem als geheel geteld te worden. In totaal kunnen er voor de helpfaciliteiten van het te tellen informatiesysteem maximaal evenveel opvragingsfuncties geteld worden als er soorten helpfaciliteiten zijn. Het bestand waarin de helpteksten zijn opgeslagen wordt beschouwd als een FPA-tabel (zie paragraaf 4.20), indien de helpteksten onderhouden kunnen worden. De complexiteit van de onderkende opvragingsfuncties van de helpfaciliteit dient altijd als eenvoudig gewaardeerd te worden. Zie de praktijksituatie zoals beschreven in paragraaf Fout- en andere systeemmeldingen Meldingen worden in dit verband onderscheiden in twee soorten, te weten computersysteemmeldingen en functiemeldingen. Computersysteemmeldingen zijn door het computersysteem gegenereerde meldingen. Deze meldingen worden niet geteld. Functiemeldingen worden door een gebruikerstransactie van het informatiesysteem gegenereerd en zeggen iets over het gebruik van die gebruikerstransactie. Zijn functiemeldingen gekoppeld aan één invoer-, uitvoer- of opvragingsfunctie, dan wordt één extra data-element-type geteld bij de betreffende functie voor alle meldingen samen. Functiemeldingen die betrekking hebben op het gebruik van meerdere gebruikerstransacties of het meermalen gebruiken van dezelfde gebruikerstransactie (bijvoorbeeld een logverslag of een foutverslag) worden, met inachtneming van de richtlijnen in hoofdstuk 8, als uitvoerfuncties geteld. NB: Wanneer er een apart entiteittype bestaat voor de meldingen en deze is door de gebruiker te onderhouden, beschouw dit entiteittype dan als FPA-tabel (zie paragraaf 4.20). Zie de praktijksituatie zoals beschreven in paragraaf Menustructuren Menustructuren dienen niet als functie geteld te worden. Per onderkende gebruikerstransactie wordt wel één data-element-type geteld voor het initiëren van de gebruikerstransactie, onafhankelijk van het daarvoor benodigde daadwerkelijke aantal stappen in de menustructuur. Indien de gebruiker de menustructuur en de menuteksten zelf kan aanpassen, dan worden deze functie(s) en de bijbehorende logische gegevensverzameling(en) geteld conform de richtlijnen voor het tellen van gegevensverzamelingen en invoerfuncties. Zie de praktijksituatie zoals beschreven in de paragrafen 10.6 en Lijstfuncties Het tonen van een lijst waaruit de gebruiker al dan niet een selectie kan doen, zoals bijvoorbeeld een selectiescherm, pick-functie, pick-list, listbox of pop-up functie, wordt als een uitvoerfunctie geteld, met inachtneming van het gestelde in paragraaf 4.3. Het is geen opvragingsfunctie omdat de omvang van de lijst niet van te voren bekend is. De eventueel aanwezige selectiemogelijkheid telt niet als een aparte functie. DEFINITIES en TELRICHTLIJNEN FPA 33

44 ALGEMENE RICHTLIJNEN Let op: als de lijst gegevens toont die opgeslagen zijn in een entiteittype van het type FPA-tabel (zie paragraaf 4.20), dan wordt geen afzonderlijke functie geteld, omdat de functies voor de FPA-tabellen-ILGV en de FPA-tabellen-KGV voor de groep als geheel op standaardwijze worden bepaald, zoals daar beschreven. Als de lijst gegevens toont die niet in een logische gegevensverzameling en niet in een FPAtabel staan, dan dient de functie geteld te worden als helpfunctie op veldniveau (zie paragraaf 4.13). Zie de praktijksituatie zoals beschreven in paragraaf Bladeren en scrollfuncties Indien een informatiesysteem uitvoer produceert op basis van een niet uniek selectiecriterium of op basis van een selectie vanaf, dan wordt dit geteld als een uitvoerfunctie. Dit geldt zowel in de situatie dat de selectie wordt gepresenteerd op een overzichtsscherm (één regel per exemplaar dat aan het criterium voldoet), als in de situatie dat heen en weer kan worden gebladerd door de betreffende detailschermen (één scherm per exemplaar). Voor het kunnen bladeren of scrollen door de uitvoer worden geen extra functies of data-element-typen geteld. Zie de praktijksituaties zoals beschreven in de paragrafen en Schoningsfuncties In een informatiesysteem kunnen functies voorkomen die on-line of automatisch periodiek gestart worden en die het verwijderen (of archiveren) van verouderde gegevens tot doel hebben. Indien deze functies gemaakt zijn om te voldoen aan door de gebruiker gestelde eisen, tel dan per voorkomende schoningsfunctie één invoerfunctie, met inachtneming van de algemene richtlijnen voor het onderkennen en waarderen van invoerfuncties (zie hoofdstuk 7). Tel op het niveau van functies en tel dus niet één invoerfunctie per interne logische gegevensverzameling Volledigheidscontrole op de functiepuntentelling Verwacht voor iedere interne logische gegevensverzameling minstens één invoer-, uitvoer- en eventueel een opvragingsfunctie en voor een koppelingsgegevensverzameling minstens één uitvoer- of opvragingsfunctie. Vraag, indien deze functies ontbreken, aan de gebruiker of er niets vergeten is en of de gegevensverzameling wel relevant is voor het desbetreffende informatiesysteem FPA-tabellen Entiteittypen binnen het informatiesysteem met constanten, teksten, decoderingen en dergelijke worden aangeduid als FPA-tabellen. De FPA-tabellen die door de gebruiker onderhouden kunnen worden met behulp van het te tellen informatiesysteem, worden samen geteld als één interne logische gegevensverzameling: de FPA-tabellen-ILGV. De FPA-tabellen die niet door het te tellen informatiesysteem, maar door een ander informatiesysteem worden onderhouden, vormen samen één koppelingsgegevensverzameling: de FPA-tabellen-KGV. Als een entiteittype niet onderhoudbaar is, is het mogelijk een systeemtabel. Deze wordt in het kader van FPA niet geteld. De volgende criteria moeten gehanteerd worden om te bepalen of een entiteittype vanuit de FPA-optiek als FPA-tabel moet worden gezien en geteld. Zodra aan één van de criteria is voldaan is het entiteittype een FPA-tabel. 34 NESMA

45 ALGEMENE RICHTLIJNEN In de volgende gevallen is een entiteittype een FPA-tabel. 1. Het entiteittype kan en moet precies één exemplaar bevatten (nooit meer en nooit minder), onafhankelijk van het aantal data-element-typen. Bijvoorbeeld: een entiteittype met gegevens (zoals naam en adres) van het bedrijf. 2. Het entiteittype bevat uitsluitend gegevens die (in principe) constant zijn. Bijvoorbeeld: een entiteittype scheikundige elementen : mnemonic, atoomnummer, omschrijving (alle data-element-typen zijn constanten); de functiepuntentabel voor het waarderen van gebruikersfuncties zoals vermeld in paragraaf 2.9: ook hierin zijn alle data-element-typen constanten. 3. Het entiteittype bestaat uit een (evt. samengestelde) sleutel + één of meer verklarende omschrijvingen, mits die verklaringen gelijksoortig zijn. Bijvoorbeeld: inkopergegevens: inkoper-nr, inkoper-naam-verkort, inkoper-naam-volledig (inkoper-naam-verkort en inkoper-naam-volledig zijn gelijksoortig). productgegevens: productcode, omschrijving-nl, omschrijving-fr (de omschrijvingen in verschillende talen zijn gelijksoortig). 4. Het entiteittype bevat grenswaarden, rekenregels, minimum- of maximumwaarden, mits de sleutel enkelvoudig is. Bijvoorbeeld: telefoonnummerreeksen: reeksnummer, laagste-telefoonnummer, hoogste-telefoonnummer. De volgende entiteittypen zijn géén FPA-tabel. 1. Entiteittypen met bedragen, koersen, (BTW-)percentages, indien deze geen constanten zijn. 2. Entiteittypen met meerdere ongelijksoortige gegevens (met uitzondering van de hierboven genoemde). Bijvoorbeeld: inkopergegevens: inkoper-nr, inkopernaam, rayonnaam (rayonnaam is een ongelijksoortig data-element-type). Let er bij deze entiteittypen op dat altijd moet worden bepaald, of een entiteittype alleen, of samen met andere entiteittypen een logische gegevensverzameling vormt (zie paragraaf 4.21). NB.: Bovenstaande opsomming van entiteittypen die hetzij een FPA-tabel zijn, hetzij (onderdeel van) een logische gegevensverzameling, dekt niet alle gevallen. Beoordeel entiteittypen bij twijfelgevallen in de geest van dit handboek. Neem voor het bepalen van de complexiteit van de FPA-tabellen-ILGV en de FPA-tabellen-KGV: het aantal verschillende FPA-tabellen dat tot de groep behoort als het aantal recordtypen; het aantal verschillende soorten data-elementen van alle FPA-tabellen samen als het aantal data-element-typen. Tevens wordt voor de FPA-tabellen-ILGV standaard één invoer-, één uitvoer- en één opvragingsfunctie geteld. Voor de FPA-tabellen-KGV worden in het geheel géén invoer-, uitvoerof opvragingsfuncties geteld. Neem voor het bepalen van de complexiteit van de standaard invoer-, uitvoer- en opvragingsfunctie voor de FPA-tabellen-ILGV: DEFINITIES en TELRICHTLIJNEN FPA 35

46 ALGEMENE RICHTLIJNEN het aantal verschillende entiteittypen dat tot de FPA-tabellen-ILGV behoort als het aantal gerefereerde logische gegevensverzamelingen; het aantal data-elementen van alle entiteittypen dat tot de FPA-tabellen-ILGV behoort samen als het aantal data-element-typen. Zie de praktijksituaties zoals beschreven in de paragrafen 10.1, 10.7, 10.9, en Het afleiden van de LGV s uit een genormaliseerd gegevensmodel Inleiding In het kader van FPA verstaan we onder een logische gegevensverzameling (interne logische gegevensverzameling of koppelingsgegevensverzameling) een conceptueel entiteittype. Een conceptueel entiteittype wordt gevormd door één of meer entiteittypen uit een gegevensmodel in de derde normaalvorm die door een gebruiker samen als één logische eenheid worden beschouwd. Wanneer we in deze paragraaf het begrip entiteittype hanteren, bedoelen we daarmee een entiteittype in een gegevensmodel in de derde normaalvorm. Als men beschikt over een gegevensmodel in de derde normaalvorm, kan men aan de hand van onderstaande regels de logische gegevensverzamelingen vaststellen. Let bij het toepassen van deze richtlijnen op de volgende zaken: Er moeten soms logische gegevensverzamelingen geteld worden die in het geheel niet in het genormaliseerde gegevensmodel staan. Denk hierbij bijvoorbeeld aan historische gegevensverzamelingen met geaggregeerde gegevens (zie richtlijn 5.2.j). Er kunnen entiteittypen in het genormaliseerde gegevensmodel voorkomen die daar nooit opgenomen hadden mogen worden, zoals tijdelijke bestanden. Hoewel deze entiteittypen genoemd staan in het gegevensmodel, zijn dit geen logische gegevensverzamelingen. Kijk altijd kritisch naar het gegevensmodel en naar de aard van de relaties (met name de cardinaliteit en optionaliteit) Denormalisatie regels De werkwijze om vanuit een gegevensmodel in de derde normaalvorm te komen tot logische gegevensverzamelingen is globaal als volgt: 1. Bepaal welke entiteittypen in het gegevensmodel een FPA-tabel zijn. FPA-tabellen worden op eigen wijze gewaardeerd. Zie paragraaf 4.20 en de richtlijnen 5.2.k en 6.2.g. 2. Bepaal welke entiteittypen een sleutel-sleutel entiteit zonder andere attributen zijn. Deze representeren in het genormaliseerde gegevensmodel een n:m-relatie. Deze entiteittypen worden in het geheel niet gewaardeerd. Het verwijzende attribuut (de vreemde sleutel) wordt als data-element-type meegeteld bij beide logische gegevensverzamelingen die door deze sleutel-sleutel entiteit worden verbonden. 3. Bepaal welke entiteittypen een sleutel-sleutel entiteit met andere attributen zijn. Daarbij kunnen zich twee situaties voordoen: a. De aanvullende attributen zijn technisch van aard (niet door de gebruiker gevraagd, bijvoorbeeld een datum/tijdstempel): deze worden niet als dataelement-type meegeteld. Indien dit de enige data-element-typen zijn, moet dit entiteittype op de bij punt 2 aangewezen wijze behandeld worden. 36 NESMA

47 ALGEMENE RICHTLIJNEN b. De aanvullende attributen zijn functioneel van aard (door de gebruiker gevraagd): behandelen als punt Bekijk van de overige entiteittypen of deze afzonderlijk een logische gegevensverzameling zijn, of dat ze samen met een (of meer) gerelateerde entiteittype(n) één logische gegevensverzameling vormen. Hierbij is bepalend: de aard van relatie(s) met een ander entiteittype (cardinaliteit en optionaliteit); de bestaanszelfstandigheid van het entiteittype. Beide begrippen worden hieronder (in de paragrafen en ) nader toegelicht. Nadat de aard van de relatie(s) bepaald is, kan aan de hand van de tabel in paragraaf worden bepaald, hoe de betreffende entiteittypen moet worden beschouwd Aard van de relatie (cardinaliteit en optionaliteit) Twee entiteittypen, bijvoorbeeld Project en Medewerker, kunnen in een gegevensmodel via een relatie, bijvoorbeeld heeft, met elkaar verbonden zijn. De aard van de relatie bepaalt, hoeveel medewerkers volgens het gegevensmodel aan een project kunnen werken (0, 1 of meer), en aan hoeveel projecten een medewerker mag werken (0, 1 of meer). Stel dat binnen een bedrijf de regel is, dat op een project meerdere medewerkers zijn ingezet (maar tenminste één), terwijl een medewerker aan precies één project moet werken. We zeggen dan, dat de relatie tussen Project en Medewerker 1:N is. Als de bedrijfsregel zou zijn, dat niet alle medewerkers aan een project hoeven te werken, zou de 1-kant optioneel zijn, en noteren we de relatie tussen Project en Medewerker als (1):N. In andere situaties zou ook de N-kant optioneel kunnen zijn, notatie 1:(N) of (1):(N) Bestaanszelfstandigheid en bestaansafhankelijkheid Onder bestaanszelfstandigheid wordt verstaan: de mate waarin een entiteittype op zichzelf betekenis heeft, los van andere entiteittypen. Voor de verschillende situaties met betrekking tot optionaliteit en cardinaliteit wordt hieronder aangegeven hoe bepaald kan worden of een entiteittype al dan niet bestaanszelfstandig is. Bestaanszelfstandigheid bij een (1):(N)-relatie A Als een relatie tussen twee entiteittypen A en B tweezijdig optioneel is, betekent dit dat de entiteittypen los van elkaar kunnen bestaan. In dit geval worden de entiteittypen in het kader van FPA gezien als bestaanszelfstandig ten opzichte van elkaar. Zoals de tabel in paragraaf aangeeft vormen in het kader van FPA de entiteittypen A en B elk afzonderlijk een logische gegevensverzameling. B Bestaansafhankelijkheid bij een 1:N-relatie A DEFINITIES en TELRICHTLIJNEN FPA 37 B

48 ALGEMENE RICHTLIJNEN Als een relatie tussen twee entiteittypen A en B tweezijdig verplicht is, betekent dit dat de entiteittypen niet los van elkaar kunnen bestaan. In dit geval worden de entiteittypen in het kader van FPA gezien als bestaansafhankelijk. Zoals de tabel in paragraaf aangeeft vormen in het kader van FPA de entiteittypen A en B één logische gegevensverzameling. 38 NESMA

49 ALGEMENE RICHTLIJNEN Bestaanszelfstandigheid of bestaansafhankelijkheid bij een 1:(N)-relatie A B Als een relatie tussen twee entiteittypen A en B optioneel is, bijvoorbeeld 1:(N) zoals de relatie tussen Project en Medewerker, betekent dit, dat er een A mag bestaan, waaraan geen B s gekoppeld zijn. In deze situatie speelt voor FPA het begrip bestaanszelfstandigheid van het entiteittype B een rol: wat gebeurt er met de optionele kant van de relatie (in dit geval B) als we de niet-optionele kant van de relatie (in dit geval A) willen verwijderen, terwijl er B s aan gekoppeld zijn? Hierbij zijn twee essentieel verschillende mogelijkheden te onderscheiden: 1. Het verwijderen van de A is toegestaan en in dezelfde actie worden tevens alle gekoppelde B s verwijderd (zonodig nadat bij de vraag om bevestiging van het verwijderen van A is meegedeeld dat ook alle B s automatisch verwijderd worden). 2. Het verwijderen van A is niet toegestaan, zolang er nog B s gekoppeld zijn. In situatie (1) hebben de B s voor het bedrijf kennelijk geen zinvolle betekenis buiten een gerelateerde A. In situatie (2) kennelijk wel. Voordat men daar de A mag verwijderen, zal men of bewust alle gerelateerde B s moeten verwijderen, of deze B s moeten koppelen aan een andere A. In situatie (1) noemen we B bestaansafhankelijk ten opzichte van A, in (2) bestaanszelfstandig. Zoals de tabel in paragraaf aangeeft vormen in het kader van FPA in situatie (1) de entiteittypen A en B één logische gegevensverzameling, in situatie (2) vormen ze elk afzonderlijk een logische gegevensverzameling. In het voorbeeld van de relatie tussen Project en Medewerker is Medewerker normaal gesproken bestaanszelfstandig. Immers, als de gegevens van een project worden verwijderd, zal het niet gewenst zijn dat de medewerkergegevens verloren gaan. Bestaanszelfstandigheid of bestaansafhankelijkheid bij een (1):N-relatie A B Ook bij een relatie tussen A en B van het type (1):N kan op soortgelijke wijze met het begrip bestaanszelfstandigheid worden omgegaan. Dit soort relaties komt in de praktijk echter zelden voor. De vraag die men zich nu moet stellen is: wat gebeurt er met de optionele kant van de relatie (in dit geval A) als we de laatste aan A gekoppelde B (dus de niet-optionele kant van de relatie) willen verwijderen? Ook hierbij weer twee essentieel verschillende mogelijkheden: DEFINITIES en TELRICHTLIJNEN FPA 39

50 ALGEMENE RICHTLIJNEN 1. Het verwijderen van de laatste aan een A gekoppelde B is toegestaan en in dezelfde actie wordt tevens de gekoppelde A verwijderd (eventueel na vermelding ervan bij de vraag om bevestiging van het verwijderen van de B). 2. Het verwijderen van B is niet toegestaan, zolang de A nog aan die B is gekoppeld. In situatie (1) heeft de A voor het bedrijf kennelijk geen zinvolle betekenis buiten één of meer gerelateerde B( s). In situatie (2) kennelijk wel. Voordat men daar de laatste B mag verwijderen, zal men of bewust de gerelateerde A moeten verwijderen, of de A moeten koppelen aan één of meer andere B s. In situatie (1) noemen we A bestaansafhankelijk ten opzichte van B, in (2) bestaanszelfstandig. Zoals de tabel in paragraaf aangeeft vormen in het kader van FPA in situatie (1) de entiteittypen A en B één logische gegevensverzameling, in situatie (2) vormen ze elk afzonderlijk een logische gegevensverzameling Conversietabel: van genormaliseerde entiteittypen naar LGV s In de onderstaande tabel zijn A en B twee entiteittypen (geen FPA-tabel en geen sleutel-sleutel entiteit, zie paragraaf punt 1, 2 en 3) uit het genormaliseerde gegevensmodel die via een relatie met elkaar zijn verbonden. type relatie tussen A en B (1) : (N) 2 LGVs hoe A en B te tellen 1 : N 1 LGV, 2 RETs, som DETs nadere voorwaarde 1 : (N) 1 LGV, 2 RETs, som DETs als B bestaansafhankelijk is van A 2 LGVs als B bestaanszelfstandig is ten opzichte van A (1) : N 1 LGV, 2 RETs, som DETs als A bestaansafhankelijk is van B (1) : (1) 2 LGVs 2 LGVs als A bestaanszelfstandig is ten opzichte van B 1 : 1 1 LGV, 1 RET, som DETs 1 : (1) 1 LGV, 2 RETs, som DETs als B bestaansafhankelijk is van A 2 LGVs als B bestaanszelfstandig is ten opzichte van A legenda: LGV = Logische gegevensverzamelingen RET = Recordtypen DET = Data-element-typen NB.: Kies in geval van twijfel voor bestaanszelfstandigheid! Let op: soms kunnen ook meer dan twee entiteittypen één logische gegevensverzameling vormen. Tel in dat geval het totale aantal entiteittypen als het aantal recordtypen. Bij een tweezijdig verplichte relatie (1:1) blijft altijd gelden: één logische gegevensverzameling met één recordtype. Zie de praktijksituaties zoals beschreven in de paragrafen 10.8 en NESMA

51 4.22 Gemeenschappelijk gebruik van gegevens ALGEMENE RICHTLIJNEN In onderstaand overzicht worden richtlijnen gegeven voor het onderkennen van functies bij gemeenschappelijk gebruik van gegevens door twee informatiesystemen. Informatiesysteem A 1 Beschrijving: Informatiesysteem A heeft een interne logische gegevensverzameling Klant. De actuele gegevens hieruit staan ter beschikking van informatiesysteem B. Tellen: Klant telt voor informatiesysteem A als interne logische gegevensverzameling. 2 Beschrijving: Informatiesysteem A maakt een kopie van de logische gegevensverzameling Klant voor informatiesysteem B. Deze kopie verlaat informatiesysteem A. Tellen: Klant telt voor informatiesysteem A als interne logische gegevensverzameling. Het aanmaken van de kopie van Klant is een uitvoerfunctie. De kopie van Klant is geen aparte logische gegevensverzameling. Informatiesysteem B Informatiesysteem B maakt gebruik van de actuele gegevens uit de logische gegevensverzameling Klant van informatiesysteem A. Klant telt voor informatiesysteem B als koppelingsgegevensverzameling. Informatiesysteem B verwerkt de aangeboden kopie in één of meer eigen interne logische gegevensverzameling(en). De gegevens uit Klant worden verbruikt. Het inlezen en verwerken van de kopie van Klant is een invoerfunctie. De kopie van Klant wordt nu verbruikt en is blijkbaar geen permanente gegevensverzameling. De kopie van Klant is dus geen logische gegevensverzameling voor informatiesysteem B. DEFINITIES en TELRICHTLIJNEN FPA 41

52 ALGEMENE RICHTLIJNEN Informatiesysteem A 3 Beschrijving: Informatiesysteem A maakt om functionele redenen periodiek een extract uit de logische gegevensverzameling Klant (Klant ) voor andere informatiesystemen ter raadpleging. Klant blijft binnen de systeemgrens van informatiesysteem A. Er kunnen verschillen ontstaan tussen de actuele gegevens in Klant en de gegevens in Klant. Tellen: Klant telt voor informatiesysteem A als interne logische gegevensverzameling. Ook Klant is voor informatiesysteem A een interne logische gegevensverzameling. Het aanmaken van Klant is een invoerfunctie. Informatiesysteem B Informatiesysteem B maakt gebruik van Klant. Klant is voor informatiesysteem B een koppelingsgegevensverzameling. 4 Beschrijving: Informatiesysteem A maakt periodiek een extract uit de logische gegevensverzameling Klant (Klant ) dat vervolgens aan andere informatiesystemen wordt verstrekt. Klant verlaat informatiesysteem A. Tellen: Klant telt voor informatiesysteem A als interne logische gegevensverzameling. Het aanmaken van Klant is een uitvoerfunctie. Klant is voor informatiesysteem A geen permanente gegevensverzameling en wordt niet als logische gegevensverzameling geteld. Informatiesysteem B leest Klant in en de gegevensverzameling wordt zonder verdere bewerkingen vastgelegd in een bestand Klant. Het inlezen van Klant is een invoerfunctie. Klant is een interne logische gegevensverzameling voor informatiesysteem B. 42 NESMA

53 ALGEMENE RICHTLIJNEN Informatiesysteem A 5 Beschrijving: Informatiesysteem A maakt een extract uit de logische gegevensverzameling Klant (Klant ) dat vervolgens aan informatiesysteem B wordt verstrekt. Klant verlaat informatiesysteem A. Tellen: Klant telt voor informatiesysteem A als interne logische gegevensverzameling. Het aanmaken van Klant is een uitvoerfunctie. Klant is voor informatiesysteem A geen permanente gegevensverzameling en wordt niet als logische gegevensverzameling geteld. Informatiesysteem B Informatiesysteem B verwerkt de gegevens uit Klant om één of meer eigen interne logische gegevensverzamelingen bij te werken. De gegevens worden verbruikt. Het inlezen en verwerken van Klant is een invoerfunctie. Klant wordt nu verbruikt en bevat dus geen permanente gegevens. Klant is dus geen logische gegevensverzameling voor informatiesysteem B. N.B.: Voor alle duidelijkheid: een bestand dat, via dezelfde logische verwerking en met dezelfde indeling, meermalen wordt aangemaakt of op meerdere fysieke plaatsen wordt opgeslagen dient, met in achtneming van het hierboven vermelde, als één gebruikerstransactie of als één logische gegevensverzameling geteld te worden Generieke regel voor het tellen van data-element-typen In de paragrafen 7.3, 8.3 en 9.3 staan richtlijnen voor het tellen van data element typen (DETs) van gebruikerstransacties. Dit zijn concrete verbijzonderingen van één algemene regel voor het tellen van data-element-typen. Deze generieke regel wordt in deze paragraaf beschreven en toegelicht. Generieke regel Voor alle typen gebruikerstransacties geldt voor het bepalen van de hoeveelheid data-elementtypen één generieke regel: Tel alle functionele gegevens die de grens van het informatiesysteem passeren (ingaand of uitgaand) De paragrafen 7.3, 8.3 en 9.3 sluiten omwille van een optimale herkenbaarheid en bruikbaarheid aan bij de karakteristieken van elk type gebruikerstransactie (IF, UF, OF); deze paragrafen formuleren richtlijnen vanuit het perspectief van dat betreffende type gebruikerstransactie. Dit lijken dan soms specifieke regels te zijn, terwijl het in feite concrete verschijningsvormen zijn van deze generieke regel. Als gevolg van de bovenstaande regel worden de volgende gegevens als DET geteld: Te wijzigen velden (mits ze de grens van het informatiesysteem passeren). Getoonde velden uit de gegevensverzamelingen en FPA-tabellen. DEFINITIES en TELRICHTLIJNEN FPA 43

54 ALGEMENE RICHTLIJNEN Initiatietrigger/functioneel stuurgegeven: voor het initiëren van een transactie moet precies één DET (niet meer en niet minder) geteld worden, ongeacht het aantal plaatsen, manieren of stappen van waaruit een transactie kan worden gestart (bijvoorbeeld meerdere menu s of functietoetsen/buttons in het scherm behorend bij de transactie zelf of functietoetsen/buttons in schermen behorend bij andere transacties). Deze initiatietrigger moet van buiten het informatiesysteem komen, zodat er besturingsinformatie de grens van het informatiesysteem passeert. Achtergrondgedachte hierbij is, dat de manier waarop de transactie wordt geïnitieerd een implementatiebeslissing is. Het data-elementtype is gelijk. Berichten en foutboodschappen: ongeacht het aantal berichten en foutboodschappen bij een gebruikerstransactie moet hiervoor precies één DET geteld worden. Dit omdat het één type betreft. Ingevoerde selectie gegevens. Getoonde proces gegevens. Andere ingevoerde gegevens zoals printerkeuze, bestandsnaam, etc. Als gevolg van de bovenstaande generieke regel worden de volgende gegevens niet als DET geteld: Page-uo/pagedown toetsen Kolomkoppen/omschrijvingen Kopregels Veldlabels Paginanummer Systeemdatum Intern bijgewerkte velden Zie de praktijksituaties zoals beschreven in de paragrafen 10.5, 10.6, 10.12,10.16, 10.19, NESMA

55 INTERNE LOGISCHE GEGEVENSVERZAMELINGEN 5 INTERNE LOGISCHE GEGEVENSVERZAMELINGEN De gegevensgroepen die door een gebruiker als een logische eenheid worden beschouwd en die door het te tellen informatiesysteem moeten worden onderhouden, worden nader bekeken. Gewoonlijk zijn deze gegevensgroepen vastgelegd in een gebruikersinformatiemodel. Vervolgens wordt vastgesteld welke interne logische gegevensverzamelingen onderkend moeten worden in de zin van FPA. Het aantal interne logische gegevensverzamelingen en hun complexiteit zijn bepalend voor de bijdrage aan de functiepuntentelling. 5.1 Definitie van een interne logische gegevensverzameling Een interne logische gegevensverzameling is een logische groep permanente gegevens vanuit het gezichtspunt van de gebruiker die aan elk van de volgende criteria voldoet: wordt gebruikt door het te tellen informatiesysteem; wordt onderhouden door het te tellen informatiesysteem. Met een logische groep gegevens vanuit het gezichtspunt van de gebruiker wordt bedoeld: een groep gegevens, die door een ervaren gebruiker als een betekenisvolle en bruikbare eenheid of object wordt beschouwd. Een equivalent van zo'n logische groep gegevens is in de gegevensmodellering een objecttype. Met permanent wordt bedoeld dat de gegevensverzameling ook na gebruik door het informatiesysteem blijft bestaan om opnieuw gebruikt te kunnen worden. Er is dus sprake van het gebruiken van gegevens en niet van het verbruiken van gegevens. Gebruikt betekent dat de gegevens ook werkelijk binnen de processen van het informatiesysteem worden gebruikt. Onderhouden wil zeggen, dat het mogelijk is om gegevens toe te voegen en/of te wijzigen en/of te verwijderen. 5.2 Het tellen van interne logische gegevensverzamelingen 5.2a. 5.2b. 5.2c. Bij de vaststelling van de interne logische gegevensverzamelingen moet uitgegaan worden van het gebruikersinformatiemodel waarin de gegevensgroepen (de objecttypen) op een voor de gebruiker hanteerbaar, herkenbaar, significant en begrijpelijk niveau zijn gespecificeerd. Er kan daarom niet zomaar worden uitgegaan van een gegevensmodel in de derde normaalvorm. De entiteittypen uit een genormaliseerd gegevensmodel dienen te worden gegroepeerd naar het hier genoemde niveau. Zie de richtlijnen hiervoor in paragraaf Zie ook de praktijksituaties zoals beschreven in de paragrafen 10.7, 10.8 en Het aspect onderhoud (toevoegen en/of wijzigen en/of verwijderen) van de gegevens is van doorslaggevende betekenis. Alleen gegevensgroepen die worden gebruikt én onderhouden binnen het informatiesysteem mogen worden geteld. Zie de praktijksituatie zoals beschreven in paragraaf Wordt een gedefinieerde gegevensverzameling niet door het gemeten informatiesysteem onderhouden, dan kan dat drie mogelijke oorzaken hebben: De gegevensverzameling is afkomstig uit een ander informatiesysteem. In dat geval is er geen sprake van een interne logische gegevensverzameling, doch van een koppelingsgegevensverzameling of van een als invoerfunctie(s) te tellen transactiebestand. DEFINITIES en TELRICHTLIJNEN FPA 45

56 INTERNE LOGISCHE GEGEVENSVERZAMELINGEN 5.2d. 5.2e. 5.2f. 5.2g. 5.2h. De gegevensverzameling is een interne logische gegevensverzameling, maar er zijn ten onrechte geen onderhoudsfuncties voor gedefinieerd. Het is een technische oplossing. Deze gegevensverzameling mag niet als interne logische gegevensverzameling geteld worden. Verwacht bij iedere interne logische gegevensverzameling tenminste één invoerfunctie, één uitvoerfunctie of één opvragingsfunctie. Indien een interne logische gegevensverzameling niet toegankelijk is voor de gebruiker door middel van een invoerfunctie, ga dan na of de betreffende gegevensverzameling terecht als interne logische gegevensverzameling onderkend is. Gegevensverzamelingen die om technische redenen worden geïntroduceerd, dienen niet te worden geteld. Voorbeelden: werkbestanden, tijdelijke bestanden, tussenbestanden, sorteerbestanden, printbestanden, spoolingbestanden en dergelijke. Zie de praktijksituaties zoals beschreven in de paragrafen en Wordt door de gebruiker een herstart/herstelmechanisme gevraagd, waarvoor bijvoorbeeld een checkpoint-bestand nodig is, tel dit bestand dan niet mee. Bij het bepalen van de complexiteit van de functies dient dit bestand ook niet te worden geteld. Verschillende user-views, toegangspaden en/of indexen bij een als interne logische gegevensverzameling onderkende gegevensverzameling leiden er niet toe dat voor deze gegevensverzameling meerdere interne logische gegevensverzamelingen geteld worden. 5.2i. Historische gegevensverzamelingen worden alleen als een interne logische gegevensverzameling geteld indien de verzameling data-element-typen van de historische gegevensverzameling uniek is ten opzichte van de overige gegevensverzamelingen. 5.2j. 5.2k. 5.2l. 5.2m. Zie de praktijksituatie zoals beschreven in paragraaf Wees alert op historische gegevensverzamelingen; deze zijn veelal wel vereist maar worden niet altijd vroegtijdig door de gebruiker gespecificeerd. Entiteittypen binnen het informatiesysteem met constanten, teksten, decoderingen en dergelijke worden binnen het informatiesysteem als groep eenmaal geteld als interne logische gegevensverzameling (de FPA-tabellen-ILGV) onder de voorwaarde dat elk van deze entiteittypen binnen het informatiesysteem onderhoudbaar is. Tevens worden standaard één invoerfunctie, één uitvoer- en één opvragingsfunctie voor de groep FPAtabellen geteld. Is een entiteittype van de hierboven genoemde soort niet onderhoudbaar binnen het informatiesysteem, dan mag deze niet worden meegeteld als onderdeel van de FPA-tabellen-ILGV. Zie de richtlijnen in paragraaf Zie de ook praktijksituaties zoals beschreven in de paragrafen 10.1, 10.7, 10.9, en Wees alert op gegevensverzamelingen waarin alleen procesgegevens worden bijgehouden (zoals een standenregister). Deze gegevensverzamelingen mogen alleen als interne logische gegevensverzameling worden geteld indien ze door de gebruiker expliciet als gegevensgroep zijn gespecificeerd. Indien de gegevensverzameling is opgenomen op grond van technische overwegingen (bijvoorbeeld performance), dan mag deze niet worden geteld. Soms is uit de door de gebruiker gespecificeerde informatiebehoefte duidelijk dat een gegevensverzameling nodig is, hoewel de gegevensverzameling niet in het gebruikers- 46 NESMA

57 INTERNE LOGISCHE GEGEVENSVERZAMELINGEN 5.2n. informatiemodel voorkomt. In dat geval moet een dergelijke gegevensverzameling als interne logische gegevensverzameling geteld worden, als zij het gevolg is van een functionele eis en als zij onderhoudbaar en gebruikt is binnen het informatiesysteem. Is een gegevensverzameling nodig op grond van technische overwegingen, dan mag deze niet worden geteld. Bij een onderhoudsproject worden de interne logische gegevensverzamelingen van het bestaande informatiesysteem die ongewijzigd blijven niet meegeteld als interne logische gegevensverzamelingen of als koppelingsgegevensverzamelingen bij het bepalen van de projectomvang. 5.3 Het bepalen van de complexiteit van interne logische gegevensverzamelingen 5.3.a 5.3.b 5.3.c 5.3.d Data-element-typen Als data-element-type worden alleen die attributen geteld die binnen het te tellen informatiesysteem worden gebruikt en/of onderhouden. Dus niet per se alle attributen. Van de FPA-tabellen-ILGV worden alle data-element-typen van de bij de FPA-tabellen- ILGV betrokken FPA-tabellen samen geteld, voor zover ze binnen het te tellen informatiesysteem worden gebruikt en/of onderhouden. Indien een interne logische gegevensverzameling bij het normaliseren is omgezet in meerdere entiteittypen, komt het aantal data-element-typen van de interne logische gegevensverzameling overeen met de som van de data-element-typen (attributen) van de genormaliseerde entiteittypen. Hierbij moeten, om dubbeltellingen te voorkomen, verwijzende attributen binnen de tot één interne logische gegevensverzameling samengevoegde entiteittypen niet meegeteld worden. Recordtypen Het aantal recordtypen voor het bepalen van de complexiteit van een interne logische gegevensverzameling is: voor de FPA-tabellen-ILGV gelijk aan het aantal omsloten FPA-tabellen; voor alle overige interne logische gegevensverzamelingen gelijk aan het aantal omsloten entiteittypen (zie paragraaf 4.21). Complexiteitstabel Voor het bepalen van het niveau van de complexiteit van de interne logische gegevensverzameling wordt de volgende tabel gehanteerd: DET RET 1 E E G E = Eenvoudig 2-5 E G M G = Gemiddeld 6+ G M M M = Moeilijk DET RET = Data-element-typen = Recordtypen DEFINITIES en TELRICHTLIJNEN FPA 47

58 INTERNE LOGISCHE GEGEVENSVERZAMELINGEN De beschikbaarheid van gegevens over het aantal recordtypen en het aantal dataelement-typen is afhankelijk van de fase van systeemontwikkeling waarin het informatiesysteem verkeert. Indien deze gegevens niet bekend zijn, dient een geïdentificeerde interne logische gegevensverzameling als eenvoudig gewaardeerd te worden. 48 NESMA

59 KOPPELINGSGEGEVENSVERZAMELINGEN 6 KOPPELINGSGEGEVENSVERZAMELINGEN De gegevensgroepen die door een gebruiker als een logische eenheid worden beschouwd en die door het te tellen informatiesysteem worden gebruikt, maar door een ander informatiesysteem worden onderhouden, worden nader bekeken. Gewoonlijk zijn deze gegevensgroepen vastgelegd in een gebruikersinformatiemodel. Vervolgens wordt vastgesteld welke koppelingsgegevensverzamelingen onderkend moeten worden in de zin van FPA. Het aantal koppelingsgegevensverzamelingen en hun complexiteit zijn bepalend voor de bijdrage aan de functiepuntentelling. 6.1 Definitie van een koppelingsgegevensverzameling Een koppelingsgegevensverzameling is een logische groep permanente gegevens vanuit het gezichtspunt van de gebruiker die aan elk van de volgende criteria voldoet: wordt gebruikt door het te tellen informatiesysteem; wordt niet onderhouden door het te tellen informatiesysteem; wordt wel door een ander informatiesysteem onderhouden; is direct benaderbaar voor het te tellen informatiesysteem. Met een logische groep gegevens vanuit het gezichtspunt van de gebruiker wordt bedoeld: een groep gegevens, die door een ervaren gebruiker als een betekenisvolle en bruikbare eenheid of object wordt beschouwd. Een equivalent van zo'n logische groep gegevens is in de gegevensmodellering een objecttype. Met permanent wordt bedoeld dat de gegevensverzameling ook na gebruik door het informatiesysteem blijft bestaan om opnieuw gebruikt te kunnen worden. Er is dus sprake van het gebruiken van gegevens en niet van het verbruiken van gegevens. Gebruikt betekent dat de gegevens ook werkelijk binnen de processen van het informatiesysteem worden gebruikt. Niet door het te tellen informatiesysteem onderhouden betekent, dat het binnen het te tellen informatiesysteem niet mogelijk is om gegevens toe te voegen en/of te wijzigen en/of te verwijderen. Direct benaderbaar voor het te tellen informatiesysteem wil zeggen, dat het te tellen informatiesysteem altijd de actuele gegevens uit de logische gegevensverzameling ter beschikking heeft, hoewel een ander informatiesysteem deze logische gegevensverzameling onderhoudt. 6.2 Het tellen van koppelingsgegevensverzamelingen 6.2.a 6.2.b Bij de vaststelling van de koppelingsgegevensverzamelingen moet uitgegaan worden van het gebruikersinformatiemodel waarin de gegevensgroepen (de objecttypen) op een voor de gebruiker hanteerbaar, herkenbaar, significant en begrijpelijk niveau zijn gespecificeerd. Er kan daarom niet zomaar worden uitgegaan van een gegevensmodel in de derde normaalvorm. De entiteittypen uit een genormaliseerd gegevensmodel dienen te worden gegroepeerd naar het hier genoemde niveau. Zie de richtlijnen hiervoor in paragraaf Alleen een gegevensverzameling waarvan op elk moment de actuele informatie ter beschikking staat van het te tellen informatiesysteem, hoewel de gegevensverzameling door een ander informatiesysteem dan het te tellen informatiesysteem wordt onderhouden, wordt als een koppelingsgegevensverzameling geteld. Zie voor een nadere uitleg paragraaf DEFINITIES en TELRICHTLIJNEN FPA 49

60 KOPPELINGSGEGEVENSVERZAMELINGEN 6.2.c 6.2.d 6.2.e Indien er sprake is van uitwisseling van gegevens tussen informatiesystemen met behulp van transactiebestanden, dan mag dit niet als een koppelingsgegevensverzameling geteld worden. Deze transactiebestanden moeten als invoer- en/of uitvoerfuncties beschouwd worden. Bij koppelingsgegevensverzamelingen moet er sprake zijn van functioneel permanente gegevens die gebruikt worden in het informatiesysteem en niet van transactiebestanden waarvan de gegevens verbruikt worden door het informatiesysteem. Zie voor een nadere uitleg paragraaf Zie de praktijksituatie zoals beschreven in paragraaf Verwacht bij iedere koppelingsgegevensverzameling tenminste één uitvoerfunctie en/of één opvragingsfunctie. Een koppelingsgegevensverzameling moet een interne logische gegevensverzameling van een ander informatiesysteem zijn. 6.2.f Verschillende user-views, toegangspaden en/of indexen bij een als koppelingsgegevensverzameling onderkende gegevensverzameling leiden er niet toe dat voor deze gegevensverzameling meerdere koppelingsgegevensverzamelingen geteld worden. 6.2.g 6.2.h 6.2.i 6.2.j 6.2.k Entiteittypen met constanten, teksten, decoderingen en dergelijke die binnen het informatiesysteem worden geraadpleegd maar worden onderhouden door een ander informatiesysteem, worden als groep éénmaal als een KGV (de FPA-tabellen-KGV) geteld. Zie de richtlijnen in paragraaf Soms is uit de door gebruiker gespecificeerde informatiebehoefte duidelijk dat een gegevensverzameling nodig is, hoewel de gegevensverzameling niet in het gebruikersinformatiemodel voorkomt. Indien een dergelijke gegevensverzameling beschikbaar gesteld wordt door een ander informatiesysteem en het te tellen informatiesysteem altijd de beschikking heeft over de actuele gegevens uit die gegevensverzameling, dan moet een dergelijke gegevensverzameling als koppelingsgegevensverzameling geteld worden. Een logische gegevensverzameling mag alleen als koppelingsgegevensverzameling worden geteld voor het informatiesysteem waarvoor ze geen interne logische gegevensverzameling is. Dus voor het informatiesysteem dat de logische gegevensverzameling niet onderhoudt. Tel bij het bepalen van de productomvang een logische gegevensverzameling die door meerdere subsystemen van hetzelfde informatiesysteem gemeenschappelijk wordt gebruikt, één keer mee als hetzij een koppelingsgegevensverzameling, hetzij een interne logische gegevensverzameling. Een logische gegevensverzameling kan uitsluitend als een koppelingsgegevensverzameling worden geteld, indien de grens van het informatiesysteem wordt overschreden. Tel bij het bepalen van de projectomvang een logische gegevensverzameling die door meerdere subsystemen van hetzelfde informatiesysteem gemeenschappelijk wordt gebruikt bij elk van deze subsystemen mee als hetzij een koppelingsgegevensverzameling, hetzij een interne logische gegevensverzameling, als deze subsystemen in evenzoveel, min of meer parallel uitgevoerde deelprojecten worden gerealiseerd, en deze subsystemen dusdanig zijn, dat ze zelfstandig moeten kunnen bestaan (bijvoorbeeld in verband met de gefaseerde invoering van het informatiesysteem of om functionele redenen). Indien het informatiesysteem na de separate projecten als één geheel wordt 50 NESMA

61 KOPPELINGSGEGEVENSVERZAMELINGEN 6.2.l onderhouden en ondersteund, wordt zo'n logische gegevensverzameling bij het bepalen van de productomvang geteld zoals aangegeven in richtlijn 6.2.j. Bij een onderhoudsproject worden de koppelingsgegevensverzamelingen van het bestaande informatiesysteem die ongewijzigd blijven niet meegeteld als koppelingsgegevensverzamelingen bij het bepalen van de projectomvang. De volgende tabel geeft een overzicht voor het onderscheiden van interne logische gegevensverzamelingen en koppelingsgegevensverzamelingen. Te tellen informatiesysteem alleen gebruik gebruik + onderhoud gebruik + onderhoud alleen gebruik Ander informatiesysteem gebruik + onderhoud alleen gebruik gebruik + onderhoud alleen gebruik in het te tellen informatiesysteem KGV ILGV ILGV * Tellen als: in het andere informatiesysteem ILGV KGV ILGV * ILGV = Interne logische gegevensverzameling KGV = Koppelingsgegevensverzameling * = De situatie waarbij een logische gegevensverzameling alleen maar gebruikt wordt, kan niet voorkomen. Er moet altijd een informatiesysteem zijn dat verantwoordelijk is voor het onderhoud. 6.3 Het bepalen van de complexiteit van koppelingsgegevensverzamelingen 6.3.a 6.3.b 6.3.c 6.3.d Data-element-typen Als data-element-type worden alleen die attributen geteld die binnen het te tellen informatiesysteem worden gebruikt. Dus niet perse alle attributen. Van de FPA-tabellen-KGV worden alle data-element-typen van de bij de FPA-tabellen- KGV betrokken FPA-tabellen samen geteld en zover ze binnen het te tellen informatiesysteem worden gebruikt. Indien een koppelingsgegevensverzameling bij het normaliseren is omgezet in meerdere entiteittypen, komt het aantal data-element-typen van de koppelingsgegevensverzameling overeen met de som van data-element-typen (attributen) van de genormaliseerde entiteittypen. Hierbij moeten, om dubbeltellingen te voorkomen, verwijzende attributen binnen de tot één koppelingsgegevensverzameling samengevoegde entiteittypen niet meegeteld worden. Recordtypen Het aantal recordtypen voor het bepalen van de complexiteit van een koppelingsgegevensverzameling is: voor de FPA-tabellen-KGV gelijk aan het aantal omsloten FPA-tabellen; voor alle overige koppelingsgegevensverzamelingen gelijk aan het aantal omsloten entiteittypen (zie paragraaf 4.21). DEFINITIES en TELRICHTLIJNEN FPA 51

62 KOPPELINGSGEGEVENSVERZAMELINGEN Complexiteitstabel Voor het bepalen van het niveau van de complexiteit van de koppelingsgegevensverzameling wordt de volgende tabel gehanteerd: DET RET 1 E E G E = Eenvoudig 2-5 E G M G = Gemiddeld 6+ G M M M = Moeilijk DET RET = Data-element-typen = Recordtypen De beschikbaarheid van gegevens over het aantal recordtypen en het aantal dataelement-typen is afhankelijk van de fase van systeemontwikkeling waarin het informatiesysteem verkeert. Indien deze gegevens niet bekend zijn, dient een geïdentificeerde koppelingsgegevensverzameling als eenvoudig gewaardeerd te worden. 52 NESMA

63 INVOERFUNCTIES 7 INVOERFUNCTIES De eisen van de gebruiker met betrekking tot het onderhouden van interne logische gegevensverzamelingen en het verwerken van besturingsinformatie van het te tellen informatiesysteem worden nader bekeken en vastgesteld wordt welke invoerfuncties in het kader van FPA onderkend moeten worden. De mate waarin zij bijdragen aan de functiepuntentelling hangt af van het aantal invoerfuncties en de complexiteit ervan. 7.1 Definitie van een invoerfunctie Een invoerfunctie is een unieke door de gebruiker onderkende functie waarbij gegevens (dataen/of besturingsinformatie) van buiten het informatiesysteem naar binnen gehaald worden. De functie moet door de gebruiker als een elementaire functie worden gezien. Onder data-informatie wordt in dit verband verstaan: gegevens die een toevoeging, wijziging of verwijdering van gegevens in een of meerdere interne logische gegevensverzamelingen veroorzaken. Onder besturingsinformatie wordt verstaan: gegevens (bijvoorbeeld een signaal) die één of meerdere processen van het informatiesysteem aan- of uitzetten of die de werking van een gebruikerstransactie beïnvloeden. Een invoerfunctie moet als uniek worden beschouwd indien: de invoerfunctie bestaat uit een andere verzameling data-element-typen dan alle andere invoerfuncties, of de invoerfunctie bestaat weliswaar uit dezelfde verzameling data-element-typen, maar vereist een andere logische manier van verwerken. Met een logische manier van verwerken wordt bedoeld: Een door de gebruiker gespecificeerde manier van werken om tot het gewenste resultaat te komen. Hieronder wordt in het kader van invoerfuncties verstaan: Het onderhouden en eventueel raadplegen van logische gegevensverzamelingen. Bijvoorbeeld: als een nieuwe order wordt toegevoegd, wordt de gegevensverzameling "Product" geraadpleegd om na te gaan of het te bestellen product inderdaad besteld kan worden. Algoritmen, berekeningen en validaties. Bijvoorbeeld: als een nieuwe order wordt toegevoegd, bestaat de logische manier van verwerken onder andere uit de uit te voeren validaties om te bepalen of de ingevoerde gegevens juist zijn. Een logische manier van verwerken wordt als anders beschouwd indien: andere interne logische gegevensverzamelingen worden onderhouden of geraadpleegd; dezelfde interne logische gegevensverzamelingen worden onderhouden, maar er sprake is van verschillende algoritmen, berekeningen en/of validaties. Verschillende technologische oplossingen die gekozen zijn om dezelfde logische manier van verwerken te realiseren, leiden er niet toe dat de logische manier van verwerken als anders wordt beschouwd. Een functie is een elementaire functie als aan twee voorwaarden wordt voldaan: DEFINITIES en TELRICHTLIJNEN FPA 53

64 INVOERFUNCTIES De functie heeft voor de gebruiker een zelfstandige betekenis en voert één geheel afgeronde verwerking van informatie uit. Ter verduidelijking kan hierbij gedacht worden aan het invoeren van een nieuwe medewerker, inclusief salarisgegevens en de gezinssamenstelling. Vanuit het gezichtspunt van de gebruiker is het invoeren van de gegevens van de medewerker één afgeronde verwerking. Het invoeren van salarisinformatie en de gezinssamenstelling is onderdeel van deze verwerking en niet een op zichzelf staande verwerking. Het informatiesysteem is na het uitvoeren van de functie in een consistente staat. Ter illustratie hiervan het volgende voorbeeld. De gebruiker eist dat bij het invoeren van een medewerker meteen ook salarisgegevens vastgelegd moeten worden. Het invoeren van alleen de medewerkergegevens of alleen de salarisgegevens zou dan het systeem in een niet-consistente staat brengen. Een invoerfunctie kan zowel de data- en besturingsinformatie die rechtstreeks door de gebruiker wordt ingebracht, als de informatie die ontvangen is van andere informatiesystemen, omvatten. 7.2 Het tellen van invoerfuncties 7.2.a 7.2.b Tel iedere invoer van gegevens voor zover deze: een elementaire functie is, én gespecificeerd is door de gebruiker, én uniek is binnen het te meten informatiesysteem, én de externe grens van het informatiesysteem overschrijdt, én (meestal) leidt tot toevoeging van gegevens aan, wijziging van gegevens in of verwijdering van gegevens uit interne logische gegevensverzamelingen van het informatiesysteem. Zie de praktijksituaties zoals beschreven in de paragrafen en Indien een invoerfunctie meerdere interne logische gegevensverzamelingen onderhoudt (invoeren, wijzigen of verwijderen van gegevens), wordt dit als één invoerfunctie geteld indien de gebruiker het als een geheel ziet en de functionaliteit om de verschillende gegevensverzamelingen afzonderlijk te onderhouden niet wordt geboden. Zie de praktijksituatie zoals beschreven in paragraaf c Indien interne logische gegevensverzamelingen afzonderlijk kunnen worden onderhouden, wordt per interne logische gegevensverzameling minstens één invoerfunctie geteld. 7.2.d 7.2.e Tel zowel het invoeren van gegevens rechtstreeks door de gebruiker, als het invoeren van gegevens die van andere informatiesystemen afkomstig zijn (bijvoorbeeld in de vorm van een invoerbestand of een bericht). Een invoerfunctie kan geactiveerd worden door een gebruiker, een ander informatiesysteem of automatisch (denk hierbij aan een batchfunctie die automatisch gestart wordt). Zie de praktijksituatie zoals beschreven in paragraaf Externe gegevensverzamelingen met functioneel permanente gegevens mogen niet als invoerfunctie worden geteld. Deze worden geteld als koppelingsgegevensverzamelingen. 7.2.f Verwacht voor iedere interne logische gegevensverzameling tenminste één invoerfunctie. Veelal zullen het er meerdere zijn. Overleg bij het ontbreken van invoerfuncties met de gebruiker. 54 NESMA

65 INVOERFUNCTIES 7.2.g 7.2.h 7.2.i 7.2.j 7.2.k 7.2.l 7.2.m 7.2.n 7.2.o 7.2.p 7.2.q 7.2.r Een invoerscherm waarop meerdere functies (invoeren, wijzigen, verwijderen) uitgevoerd kunnen worden, telt als meerdere afzonderlijke invoerfuncties. Zie de praktijksituatie zoals beschreven in paragraaf Een invoerfunctie (bijvoorbeeld voor het wijzigen van gegevens) waarbij het informatiesysteem alvorens tot uitvoering van de ingevoerde opdracht over te gaan nogmaals een bevestiging ervan vraagt, wordt als één invoerfunctie geteld, omdat het dan één elementaire functie betreft. Het in twee stappen invoeren, wijzigen of verwijderen van gegevens, bijvoorbeeld om de invoer door een andere functionaris te laten autoriseren, wordt als twee functies geteld. De initiële invoer wordt als één invoerfunctie geteld en de autorisatiefunctie wordt als één invoerfunctie geteld. Het betreft dan namelijk twee elementaire functies. Eventueel kan hier een opvragingsfunctie voorkomen, indien deze expliciet als zodanig is gespecificeerd. Een invoerfunctie die een duplicaat is van een andere reeds getelde invoerfunctie, dat wil zeggen dat de verzameling data-element-typen en de logische verwerking gelijk zijn, wordt niet opnieuw geteld. Een invoerfunctie die uitsluitend om technische redenen (bijvoorbeeld vanwege de gebruikte technologie) wordt geïntroduceerd en niet door de gebruiker wordt gevraagd, wordt niet als invoerfunctie geteld. Als invoerfuncties gelden uitsluitend die functies, die door de gebruiker worden gespecificeerd. De menustructuur wordt geteld op de in paragraaf 4.15 aangegeven wijze. Zie de praktijksituaties zoals beschreven in de paragrafen 10.6 en Indien als onderdeel van een functie voor het wijzigen en/of verwijderen de te wijzigen en/of te verwijderen gegevens worden gepresenteerd, dan wordt dit geacht deel uit te maken van deze invoerfunctie en wordt dit niet apart als opvragingsfunctie geteld. Zie de praktijksituaties zoals beschreven in de paragrafen 10.10, en Hetzelfde geldt, indien gegevens automatisch zichtbaar worden gemaakt op een wijzigingsscherm (bijvoorbeeld het achtereenvolgens presenteren van aanwezige gegevens in een invoerbestand). Dit is geen opvragingsfunctie, maar onderdeel van de invoerfunctie. Zie de praktijksituatie zoals beschreven in paragraaf Wordt de opvragingsfunctie apart gespecificeerd, dan wordt "functionaliteit" geboden aan de gebruiker en wordt wel een opvragingsfunctie geteld. Indien opgevraagde gegevens vervolgens met een wijzigingsfunctie kunnen worden gewijzigd, wordt zowel een opvragings- als een invoerfunctie geteld. Zie de praktijksituatie zoals beschreven in paragraaf Indien een invoerfunctie bestaat uit meerdere invoerschermen omdat niet alle gegevens op één scherm ingevoerd kunnen worden, tel dit dan als één invoerfunctie. Kan ieder invoerscherm echter tevens apart worden gebruikt, zonder dat een vooraf opgelegde volgorde wordt doorlopen, tel dan voor ieder invoerscherm een aparte invoerfunctie, mits elk scherm op zich als elementaire functie kan worden beschouwd. Tijdvertraging tussen het invoeren van gegevens en het verwerken van de gegevens is geen reden om extra invoerfuncties te onderkennen. DEFINITIES en TELRICHTLIJNEN FPA 55

66 INVOERFUNCTIES 7.2.s 7.2.t 7.2.u 7.2.v 7.2.w 7.2.x Zie de praktijksituaties zoals beschreven in de paragrafen en Het invoeren van gegevens ter besturing van een invoer-, uitvoer- of opvragingsfunctie (bijvoorbeeld selectiegegevens) wordt niet als aparte invoerfunctie geteld, maar wordt geteld als onderdeel van de betreffende functie. Het verwerken van een transactiebestand (een bestand met niet-permanente gegevens), aangeleverd door een ander informatiesysteem, resulteert in meerdere invoerfuncties indien er naar aanleiding van de gegevens verschillende soorten logische verwerking gespecificeerd zijn. Dit kan zich onder andere voordoen indien er meerdere recordtypen voor het transactiebestand zijn gedefinieerd of verschillende verwerkingscodes binnen één recordtype. Zie de praktijksituatie zoals beschreven in paragraaf Als de invoer van informatie voor dezelfde logische verwerking via verschillende media plaats vindt, tel dan één invoerfunctie. Invoerfuncties die uiterlijk gelijk zijn, maar waarbij andere interne logische gegevensverzamelingen worden bijgewerkt, moeten als aparte invoerfuncties worden geteld, omdat er sprake is van een andere logische verwerking. Indien in een transactiebestand een zogenaamd voorloop- en/of sluitrecord voorkomt met controlegegevens (bijvoorbeeld totaal bedrag of totaal aantal records) dan wordt de verwerking van dit record niet als afzonderlijke invoerfunctie geteld. De controlegegevens worden wel als data-element-typen meegeteld (mits door de gebruiker gevraagd). Soms wordt de mogelijkheid geboden de te wijzigen en/of te verwijderen gegevens te selecteren via een niet uniek selectiecriterium. Hierbij worden, na het invoeren van de selectiegegevens, kenmerkende gegevens getoond van die exemplaren van het entiteittype die aan het selectiecriterium voldoen, waarna het gewenste exemplaar van het entiteittype geselecteerd kan worden. Dit tonen wordt gezien als extra functionaliteit die geboden wordt aan de gebruiker. Hiervoor moet een uitvoerfunctie geteld worden. Zie paragraaf Zie de praktijksituatie zoals beschreven in paragraaf Het bepalen van de complexiteit van invoerfuncties 7.3.a 7.3.b 7.3.c Data-element-typen De volgende richtlijnen voor het tellen van de data-element-typen zijn een concrete invulling van de generieke regel zoals aangegeven in paragraaf Tel alle data-element-typen (data- en/of besturingsinformatie) die de grens van het te tellen informatiesysteem passeren. Tel de weg om bij een functie te komen en om deze te starten (bijvoorbeeld de menukeuzen en functietoetsen) als geheel als één data-element-type (de initiatietrigger). Zie de praktijksituatie zoals beschreven in paragraaf Indien op een invoerscherm meerdere functies uitgevoerd kunnen worden, bijvoorbeeld invoeren, wijzigen en verwijderen, tel dan het voor iedere functie relevante aantal dataelement-typen. 56 NESMA

67 INVOERFUNCTIES 7.3.d 7.3.e 7.3.f 7.3.g 7.3.h 7.3.i 7.3.j Indien bij een invoerfunctie meerdere schermen worden doorlopen, bijvoorbeeld eerst het scherm waarop de selectiegegevens worden ingevoerd en daarna het wijzigingsscherm, dan dient de combinatie van de schermen als één geheel te worden beschouwd bij het tellen van data-element-typen, omdat de functie één elementaire functie is. Indien echter de selectiegegevens niet uniek identificerend zijn en de gebruiker eerst uit een aantal geselecteerde exemplaren van een entiteittype het gewenste moet kiezen, tel dan wel een aparte uitvoerfunctie (zie richtlijn 7.2.x). Zie ook de praktijksituatie zoals beschreven in paragraaf Indien er sprake is van data-element-typen voor fout- en andere systeemmeldingen, of van een apart scherm voor het weergeven van berichten, tel dit dan zoals in paragraaf 4.14 is aangegeven. Als er gevraagd wordt om extra gegevens te tonen als antwoord op een invoer (bijvoorbeeld een functie "bijwerken van klantgegevens" waarbij een klantnummer wordt ingevoerd en ter verificatie naam en adres worden getoond, waarna men de overige gegevens kan invoeren), dan moeten de getoonde data-element-typen worden geteld als onderdeel van de invoerfunctie. Indien in een transactiebestand een zogenaamd voorloop- en/of sluitrecord voorkomt met controlegegevens (bijvoorbeeld totaal bedrag of totaal aantal records) dan worden deze gegevens als data-element-typen meegeteld (mits door de gebruiker gevraagd). Logische gegevensverzamelingen Het aantal gerefereerde logische gegevensverzamelingen wordt vastgesteld door per invoerfunctie het aantal bij de validatie van de invoer en/of bij het uitvoeren van de invoerfunctie betrokken gerefereerde logische gegevensverzamelingen te bepalen. Dit kunnen zowel interne logische gegevensverzamelingen als koppelingsgegevensverzamelingen zijn. Zie de praktijksituatie zoals beschreven in paragraaf De FPA-tabellen-ILGV en FPA-tabellen-KGV worden niet als gerefereerde logische gegevensverzameling geteld bij het bepalen van de complexiteit van invoerfuncties. Dit geldt ook voor gegevensverzamelingen die om technische redenen zijn geïntroduceerd (zie richtlijn 5.2.f). Indien een proces is gedefinieerd, waarbij een gegevensverzameling met permanente gegevens aan de hand van een transactiebestand (invoer) wordt onderhouden, tel dit dan als één of meer (bij meerdere verwerkingscodes) invoerfuncties (het verwerken van het transactiebestand) met minimaal één interne logische gegevensverzameling (de permanente gegevensverzameling). 7.3.k Een transactiebestand (invoer of uitvoer) kan geen "gerefereerde" logische gegevensverzameling zijn. Dat wil zeggen dat een invoerfunctie die bijvoorbeeld gebruik maakt van een invoerbestand om vervolgens de gegevens te verwerken nul logische gegevensverzamelingen zal tellen, tenzij natuurlijk interne logische gegevensverzamelingen worden bijgewerkt. Hetzelfde geldt voor tijdelijke bestanden. 7.3.l Gegevensverzamelingen die om technische redenen zijn geïntroduceerd, zoals tussenbestanden, sorteerbestanden en printbestanden, worden niet geteld. Ga na of deze soort gegevensverzamelingen een alternatief is voor een interne logische gegevensverzameling of een koppelingsgegevensverzameling. Als dit zo is, dan tellen deze onderliggende logische gegevensverzamelingen mee voor de complexiteit. DEFINITIES en TELRICHTLIJNEN FPA 57

68 INVOERFUNCTIES Complexiteitstabel Voor het bepalen van het niveau van de complexiteit van de invoerfunctie wordt de volgende tabel gehanteerd: DET LGV 0-1 E E G E = Eenvoudig 2 E G M G = Gemiddeld 3+ G M M M = Moeilijk DET LGV = Data-element-typen = Logische gegevensverzamelingen De beschikbaarheid van gegevens over het aantal data-element-typen en gerefereerde logische gegevensverzamelingen is afhankelijk van de fase van systeemontwikkeling waarin het informatiesysteem verkeert. Indien deze gegevens niet bekend zijn, dient een geïdentificeerde invoerfunctie als gemiddeld gewaardeerd te worden. 58 NESMA

69 UITVOERFUNCTIES 8 UITVOERFUNCTIES De eisen van de gebruiker met betrekking tot het door het informatiesysteem produceren van uitvoer waarvan de omvang variabel is of waarvoor verdere gegevensverwerking nodig is, worden nader bekeken en vastgesteld wordt welke uitvoerfuncties in het kader van FPA onderkend moeten worden. De mate waarin zij bijdragen aan de functiepuntentelling hangt af van het aantal uitvoerfuncties en de complexiteit ervan. 8.1 Definitie van een uitvoerfunctie Een uitvoerfunctie is een unieke door de gebruiker onderkende uitvoer die de systeemgrens passeert, waarvan de omvang variabel is of waarvoor verdere gegevensverwerking nodig is. De functie moet door de gebruiker als een elementaire functie worden gezien. Een uitvoerfunctie moet als uniek worden beschouwd indien: het uitvoerproduct een andere indeling heeft dan alle andere uitvoerproducten, of het uitvoerproduct weliswaar dezelfde indeling heeft, maar een andere logische manier van verwerken vereist, of het eventuele invoergedeelte van de uitvoerfunctie bestaat uit een andere verzameling data-element-typen dan het invoergedeelte van alle andere uitvoerfuncties. Er is sprake van dezelfde indeling indien de verzameling data-element-typen gelijk is. Hierbij is het volgende toegestaan: De data-element-typen van het uitvoerproduct hebben een andere volgorde. N.B: Het op verschillende wijze groeperen van de data-element-typen, bijvoorbeeld door middel van tussenkopjes, wordt wel als een andere indeling gezien. Sommige data-element-typen komen wel voor in het uitvoerproduct, maar zonder waarde. Hiervoor kunnen de volgende redenen bestaan: 1. het data-element-type heeft geen waarde in de logische gegevensverzameling (waardoor optisch het data-element-type niet aanwezig is); 2. het data-element-type heeft wel een waarde in de logische gegevensverzameling, maar deze waarde is niet relevant voor de gebruiker. Met een logische manier van verwerken wordt bedoeld: Een door de gebruiker gespecificeerde manier van werken om tot het gewenste resultaat te komen. Hieronder wordt in het kader van uitvoerfuncties verstaan: Het raadplegen van logische gegevensverzamelingen. Bijvoorbeeld: als een lijst van medewerkers wordt gemaakt, wordt de logische gegevensverzameling "Medewerker" geraadpleegd. Het leveren van verdere gegevensverwerking, zoals algoritmen, berekeningen en validaties. Bijvoorbeeld: de logische manier van verwerken bij het rapporteren over alle medewerkers van een organisatie omvat de algoritmen voor de berekening van het totale aantal vaste medewerkers, medewerkers op uurcontracten en alle medewerkers. DEFINITIES en TELRICHTLIJNEN FPA 59

70 UITVOERFUNCTIES Een logische manier van verwerken wordt als anders beschouwd indien: andere logische gegevensverzamelingen worden geraadpleegd; dezelfde logische gegevensverzamelingen worden geraadpleegd, maar er sprake is van andere algoritmen, berekeningen en/of validaties. Het selecteren met een andere selectiewaarde (al dan niet met verschillende vormen van wild-cards) en het selecteren op dezelfde rubriek(en) maar met een andere operator, worden niet als een andere logische manier van verwerken gezien. Verschillende technologische oplossingen die gekozen zijn om dezelfde logische manier van verwerken te realiseren, leiden er niet toe dat de logische manier van verwerken als anders wordt beschouwd. Onder selectiewaarde wordt verstaan: Selectie op dezelfde data-element-type(n) maar met een andere inhoud. Verwar dit niet met selectie op andere data-element-typen. Onder een wild-card wordt verstaan: Een specifiek teken dat aangeeft dat er diverse waarden in die positie mogen voorkomen. Voorbeelden: Veel gebruikte wild-cards zijn: "?" (die één willekeurig teken representeert) en "*" (die een aaneengesloten reeks willekeurige tekens representeert). Onder een operator wordt verstaan: Gelijk aan, groter dan, kleiner dan, groter of gelijk aan, kleiner of gelijk aan, ongelijk aan, en dergelijke. Met verdere gegevensverwerking wordt hier bedoeld: het toepassen van algoritmen of berekeningen op gegevens die uit de logische gegevensverzamelingen opgehaald zijn, voordat de informatie getoond wordt. Een functie is een elementaire functie als aan twee voorwaarden wordt voldaan: De functie heeft voor de gebruiker een zelfstandige betekenis en voert één geheel afgeronde verwerking van gegevens uit. Ter verduidelijking kan hierbij gedacht worden aan een functie waarbij alle medewerkers die in een bepaald jaar in dienst getreden zijn, afgedrukt kunnen worden. Het invoeren van selectiegegevens en het tonen of afdrukken van de geselecteerde medewerkers is vanuit het gezichtspunt van de gebruiker één afgeronde verwerking. Het informatiesysteem is na het uitvoeren van de functie in een consistente staat. Ter illustratie hiervan het volgende voorbeeld. Een informatiesysteem maakt een uitvoerbestand aan met gegevens over het verbruik van alle gebruikers die in een bepaald gebied wonen ten behoeve van een factureringssysteem. Het selecteren van de gebruikers die in het gewenste gebied wonen, het daarbij zoeken van de verbruiksgegevens, het opbouwen van het uitvoerbestand en het verzenden van het bestand, zijn één geheel. Vanuit de gebruiker gezien is het informatiesysteem pas in een consistente staat als alle stappen uitgevoerd zijn. Uitvoerfuncties omvatten zowel uitvoerproducten die rechtstreeks naar de gebruiker gaan in de vorm van rapporten en berichten, als ook gegevensstromen die via een on-line koppeling of via een uitvoerbestand naar andere informatiesystemen gaan. Bij uitvoerfuncties ligt slechts het domein van het uitvoerproduct vast. De omvang van het uitvoerproduct hoeft echter geenszins constant te zijn. Dit in tegenstelling tot opvragingsfuncties waarbij de omvang van het uitvoerproduct constant is. 60 NESMA

71 UITVOERFUNCTIES 8.2 Het tellen van uitvoerfuncties 8.2.a 8.2.b 8.2.c 8.2.d 8.2.e Tel iedere uitvoer van gegevens voor zover deze: een elementaire functie is, én uniek is binnen het te meten informatiesysteem, én de externe grens van het informatiesysteem overschrijdt, én een variabele omvang heeft of met verdere gegevensverwerking tot stand is gekomen (zie de definitie in paragraaf 8.1). Zie ook de praktijksituaties zoals beschreven in paragrafen 10.13, 10.19, 10.20, en Tel zowel uitvoerproducten die rechtstreeks in de vorm van rapporten en berichten aan de gebruiker worden aangeboden, als uitvoerproducten die als uitvoerbestanden en berichten aan andere informatiesystemen worden aangeboden. Zie de praktijksituatie zoals beschreven in paragraaf Het onderscheid tussen een uitvoerfunctie en opvragingsfunctie dient gemaakt te worden op basis van de volgende criteria: 1. de uitvoer mag bij een uitvoerfunctie in omvang variabel zijn; 2. bij een uitvoerfunctie hoeft er geen sprake te zijn van invoer ten behoeve van het selecteren van gegevens; 3. de uitvoer mag bij een uitvoerfunctie gegevens bevatten die met behulp van verdere gegevensverwerking (zoals het berekenen van gegevens) tot stand zijn gekomen. Zie de praktijksituaties zoals beschreven in de paragrafen 10.19, en Het uitvoergedeelte van een opvragingsfunctie mag niet als een aparte uitvoerfunctie geteld worden. Het invoeren van gegevens ter besturing van een uitvoerfunctie (bijvoorbeeld het invoeren van selectiecriteria, de gewenste sorteervolgorde of de gewenste printer) wordt als onderdeel gezien van de uitvoerfunctie en mag niet als een invoerfunctie worden geteld. Zie de praktijksituatie zoals beschreven in paragraaf f Verwacht voor iedere interne logische gegevensverzameling tenminste één uitvoerfunctie. Overleg, bij ontbreken daarvan, met de gebruiker. 8.2.g Een uitvoerproduct kan meerdere uitvoerfuncties omvatten. Er is sprake van meerdere uitvoerfuncties binnen één uitvoerproduct, als er sprake is van: 1. meerdere verschillende indelingen binnen dat uitvoerproduct (zie de definitie van indeling in paragraaf 8.1) en deze verschillende indelingen zijn afzonderlijk opvraagbaar, óf 2. meerdere verschillende indelingen binnen dat uitvoerproduct (zie de definitie van indeling in paragraaf 8.1) en de verschillende indelingen komen via afzonderlijke logische verwerkingen tot stand en zijn omwille van gebruiksvriendelijkheid gecombineerd. Onder afzonderlijk opvraagbaar moet in dit verband verstaan worden: de gebruiker heeft de mogelijkheid om te sturen/selecteren welke delen afgedrukt worden. Er is sprake van afzonderlijke logische verwerkingen als de verschillende delen rapporteren over een ander object of als de verschillende delen op basis van andere logische gegevensverzamelingen tot stand komen. Er is in dit geval sprake van DEFINITIES en TELRICHTLIJNEN FPA 61

72 UITVOERFUNCTIES 8.2.h 8.2.i 8.2.j 8.2.k 8.2.l 8.2.m 8.2.n 8.2.o 8.2.p 8.2.q afzonderlijke logische verwerkingen die omwille van gebruiksvriendelijkheid resulteren in één gecombineerd uitvoerproduct dat met één commando opgevraagd kan worden. Zie de praktijksituaties zoals beschreven in de paragrafen en Een overzicht dat dezelfde indeling heeft doch op meerdere manieren kan zijn gesorteerd, telt als één uitvoerfunctie, tenzij per sorteervolgorde een andere of additionele logische verwerking nodig is. Uitvoer kan rechtstreeks bestemd zijn voor een gebruiker, voor een ander informatiesysteem of voor externe opslagmedia. Is de indeling en de logische verwerking gelijk, tel het dan als één uitvoerfunctie. Zie de praktijksituatie zoals beschreven in paragraaf Het kan noodzakelijk zijn om een transactiebestand voor een ander informatiesysteem als meerdere uitvoerfuncties te tellen. Bijvoorbeeld is dit het geval indien er meerdere recordtypen in het bestand voorkomen of indien de uitvoer van verschillende logische verwerkingen fysiek is samengevoegd in één uitvoerbestand. Zie de praktijksituatie zoals beschreven in paragraaf Tel uitsluitend uitvoerfuncties waar de gebruiker om heeft gevraagd. Uitvoerproducten die niet door de gebruiker zijn gevraagd, maar alleen vanwege de gebruikte technologie worden geïntroduceerd, worden niet geteld (bijvoorbeeld spoolingbestanden). Een gegevensverzameling met functioneel permanente gegevens die door het te tellen informatiesysteem wordt onderhouden en door andere informatiesystemen wordt gebruikt, wordt geteld als een interne logische gegevensverzameling en niet als een uitvoerfunctie. Door elk ander gebruikend informatiesysteem wordt deze verzameling als een koppelingsgegevensverzameling geteld, en dus niet als een invoerfunctie. Indien de gebruiker vraagt om een overzicht van mogelijke foutmeldingen, wordt dit niet als een aparte uitvoerfunctie gezien omdat de gegevensverzameling met foutmeldingen een FPA-tabel is (zie de paragrafen 4.14 en 4.20). Meldingen (zoals foutmeldingen) die iets zeggen over de uitvoering van één functie, zijn gekoppeld aan die ene invoer-, uitvoer-, of opvragingsfunctie. Ze worden niet als afzonderlijke uitvoerfunctie geteld, maar worden samen als één data-element-type geteld bij de betreffende functie (zie ook paragraaf 4.14). Zie de praktijksituatie zoals beschreven in paragraaf Een uitvoerproduct met foutmeldingen of berichten die betrekking hebben op het uitvoeren van meerdere functies of het meermalen gebruiken van dezelfde functie, wordt als één of meer uitvoerfuncties geteld. Een uitvoerproduct dat het logische gevolg is van onderhoud op de interne logische gegevensverzamelingen, bijvoorbeeld een mutatie- of verwerkingsverslag, wordt als één of meer uitvoerfuncties geteld. Zie de praktijksituatie zoals beschreven in paragraaf Tel een uitvoer op basis van meerdere selectiecriteria als volgt: Wanneer de gebruiker meer opties heeft (d.w.z. een "en/of-situatie"), tel dan de selecties die elkaar wederzijds uitsluiten. Iedere selectie of combinatie van selecties die alle andere uitsluit, wordt apart geteld. Zie de praktijksituaties zoals beschreven in de paragrafen en NESMA

73 UITVOERFUNCTIES 8.2.r 8.2.s 8.2.t 8.2.u 8.2.v 8.2.w Indien in een transactiebestand een zogenaamd voorloop- en/of sluitrecord voorkomt met controlegegevens (bijvoorbeeld totaal bedrag of totaal aantal records) dan wordt dit record niet als afzonderlijke uitvoerfunctie geteld. Het voorlooprecord is vergelijkbaar met de kopregel uit een overzicht en het sluitrecord is vergelijkbaar met samenvattende totalen in een overzicht. De data-element-typen uit het voorloop- en/of sluitrecord worden wel meegeteld (mits door de gebruiker gevraagd). Als de gebruiker de mogelijkheid heeft om meerdere functies te starten, hetzij afzonderlijk, hetzij gecombineerd, waarbij de combinatie van de functies meer is dan de som der delen, dan is er sprake van combinatie-effecten. Ga hier als volgt mee om: Voor elke apart te starten functie met verschillende verwerking wordt een aparte uitvoerfunctie geteld. Voor alle mogelijke combinaties wordt in principe slechts één extra uitvoerfunctie geteld, tenzij er voor bepaalde (groepen van) combinaties sprake is van andersoortige logische verwerkingen. In dat geval wordt per (groep van) combinatie(s) waarvoor een andersoortige logische verwerking nodig is een uitvoerfunctie extra geteld. Zie de praktijksituatie zoals beschreven in paragraaf Het tonen van een lijst waaruit de gebruiker al dan niet een selectie kan doen, zoals een selectiescherm, pick-functie, pick-list of pop-up functie, moet, indien expliciet door de gebruiker gevraagd, als een uitvoerfunctie geteld worden, mits de gegevens uit een logische gegevensverzameling afkomstig zijn en niet uit een FPA-tabel. Het is geen opvragingsfunctie omdat de omvang van de lijst niet van te voren bekend is. De eventueel aanwezige selectiemogelijkheid telt niet als een aparte functie. Zie voor een nadere uitleg paragraaf Zie de praktijksituatie zoals beschreven in paragraaf Tel voor het kunnen bladeren of scrollen door geproduceerde uitvoer geen extra functies of data-element-typen. Zie voor een nadere uitleg paragraaf Zie de praktijksituaties zoals beschreven in de paragrafen en Indien een functie resulteert in uitvoerproducten die inhoudelijk gelijk zijn maar elk in een andere taal zijn gesteld, dan wordt dit als één uitvoerfunctie geteld, omdat de uitvoerproducten, hoewel verschillend in taal, toch bestaan uit dezelfde verzameling van data-element-typen en de verwerking gelijk is voor alle uitvoerproducten. Als er meerdere uitvoerproducten zijn, kan er toch sprake zijn van slechts één uitvoerfunctie. Er is sprake van één uitvoerfunctie, als geldt: 1. de uitvoerproducten hebben dezelfde indeling (zie de definitie in paragraaf 8.1) én 2. de uitvoerproducten zijn met dezelfde logische manier van verwerken tot stand gekomen (zie de definitie in paragraaf 8.1). Zie de praktijksituaties zoals beschreven in de paragrafen en Het bepalen van de complexiteit van uitvoerfuncties Data-element-typen De volgende richtlijnen voor het tellen van de data-element-typen zijn een concrete invulling van de generieke regel zoals aangegeven in paragraaf DEFINITIES en TELRICHTLIJNEN FPA 63

74 UITVOERFUNCTIES 8.3.a 8.3.b 8.3.c 8.3.d 8.3.e 8.3.f 8.3.g 8.3.h 8.3.i 8.3.j Alle data-element-typen (niet de mogelijke waarden ervan) die in het door de uitvoerfunctie te genereren uitvoerproduct voorkomen, worden geteld. Zie de praktijksituaties zoals beschreven in de paragrafen 10.16, en Alle besturingsinformatie (bijvoorbeeld: selectiecriteria, gewenst medium, gewenste printer, sorteervolgorde of tijdstip van afdrukken) op het niveau van data-element-type die voor het produceren van de uitvoer moeten worden ingevoerd, wordt geteld als dataelement-typen voor de uitvoerfunctie. Besturingsinformatie die zelf ook op de uitvoer verschijnt, wordt hierbij dubbel geteld. Let wel: bij een opvragingsfunctie wordt hier anders mee omgegaan (zie paragraaf 9.3) Zie ook de praktijksituaties zoals beschreven in de paragrafen 10.12, 10.16, 10.19, en Alle adresgegevens op het niveau van data-element-type die aangeven voor wie, voor welk apparaat of medium de uitvoer bestemd is, worden geteld. Zie de praktijksituatie zoals beschreven in paragraaf Alle procesgegevens die deel uitmaken van het uitvoerproduct, zoals gemiddelden, uitkomsten van berekeningen, subtotalen en totalen, worden als data-element-typen geteld. Zie de praktijksituatie zoals beschreven in paragraaf Indien t.b.v. een uitvoerfunctie logische gegevensverzamelingen moeten worden geraadpleegd, worden de hierin voorkomende en geraadpleegde data-element-typen niet geteld. Alleen data-element-typen die de grens van de toepassing passeren worden meegeteld voor het bepalen van de complexiteit. Standaardgegevens als systeemdatum en paginanummer worden niet als data-elementtypen geteld. Vaste gegevens als kopregels, kolomomschrijvingen, literals en constanten worden ook niet geteld als data-element-typen. Foutregels of andere door de uitvoerfunctie gegenereerde mededelingen worden samen als één extra data-element-type geteld (zie paragraaf 4.14). Zie ook de praktijksituatie zoals beschreven in paragraaf Functietoetsen die gebruikt worden om door de uitvoer te navigeren worden niet als data-element-typen meegeteld. Zie de praktijksituaties zoals beschreven in de paragrafen en Indien in een transactiebestand een zogenaamd voorloop- en/of sluitrecord voorkomt met controlegegevens (bijvoorbeeld totaal bedrag of totaal aantal records), dan worden deze gegevens als data-element-typen meegeteld (mits door de gebruiker gevraagd). Logische gegevensverzamelingen Het aantal gerefereerde logische gegevensverzamelingen wordt vastgesteld door per uitvoerfunctie het aantal voor de validatie van de invoer en/of voor het vervaardigen van de uitvoer gerefereerde logische gegevensverzamelingen te bepalen. Dit kunnen zowel interne logische gegevensverzamelingen als koppelingsgegevensverzamelingen zijn. Tel bij een uitvoerfunctie die onlosmakelijk verbonden is met een invoerfunctie het aantal gerefereerde logische gegevensverzamelingen voor de gegevensverwerking als geheel en niet alleen het aantal gerefereerd voor de uitvoerfunctie op zich (bijvoorbeeld: de uitvoerfunctie voor het maken van een verslag van de verwerking van een aantal 64 NESMA

75 UITVOERFUNCTIES 8.3.k 8.3.l mutaties, deze uitvoerfunctie is onlosmakelijk verbonden met de invoerfunctie voor het verwerken van mutaties). De FPA-tabellen-ILGV en FPA-tabellen-KGV worden niet als gerefereerde logische gegevensverzameling geteld bij het bepalen van de complexiteit van uitvoerfuncties. Gegevensverzamelingen die om technische redenen zijn geïntroduceerd, zoals tussenbestanden, sorteerbestanden en printbestanden, worden niet geteld. Ga na of deze soort van gegevensverzamelingen een alternatief is voor een interne logische gegevensverzameling of een koppelingsgegevensverzameling. Als dit zo is, dan tellen deze onderliggende logische gegevensverzamelingen mee voor de complexiteit. Complexiteitstabel Voor het bepalen van het niveau van de complexiteit van een uitvoerfunctie wordt de volgende tabel gehanteerd: DET LGV 0-1 E E G E = Eenvoudig 2-3 E G M G = Gemiddeld 4+ G M M M = Moeilijk DET LGV = Data-element-typen = Logische gegevensverzamelingen De beschikbaarheid van gegevens over het aantal data-element-typen en gerefereerde logische gegevensverzamelingen is afhankelijk van de fase van systeemontwikkeling waarin het informatiesysteem verkeert. Indien deze gegevens niet bekend zijn, dient een geïdentificeerde uitvoerfunctie als gemiddeld gewaardeerd te worden. DEFINITIES en TELRICHTLIJNEN FPA 65

76 OPVRAGINGSFUNCTIES 9 OPVRAGINGSFUNCTIES De eisen van de gebruiker met betrekking tot het door het informatiesysteem produceren van uitvoer waarvan de omvang volledig bepaald is, worden nader bekeken en vastgesteld wordt welke opvragingsfuncties in het kader van FPA onderkend moeten worden. De mate waarin zij bijdragen aan de functiepuntentelling hangt af van het aantal opvragingsfuncties en de complexiteit ervan. 9.1 Definitie van een opvragingsfunctie Een opvragingsfunctie is een unieke door de gebruiker onderkende invoer/uitvoer-combinatie waarbij de uitvoer, waarvan de omvang volledig bepaald is, zonder verdere gegevensverwerking naar aanleiding van de invoer door het informatiesysteem wordt verstrekt. De functie moet door de gebruiker als een elementaire functie worden gezien. Een opvragingsfunctie moet als uniek worden beschouwd indien: het invoergedeelte van de opvragingsfunctie bestaat uit een andere verzameling dataelement-typen dan het invoergedeelte van alle andere opvragingsfuncties, of het door de opvragingsfunctie geproduceerde uitvoerproduct bestaat uit een andere verzameling data-element-typen dan het uitvoergedeelte van alle andere opvragingsfuncties, of de verzameling data-element-typen van zowel het invoergedeelte als van het uitvoerproduct is hetzelfde, maar de opvragingsfunctie vereist een andere logische manier van verwerken. Met een logische manier van verwerken wordt bedoeld: Een door de gebruiker gespecificeerde manier van werken om tot het gewenste resultaat te komen. Hieronder wordt in het kader van een opvragingsfunctie verstaan: Het raadplegen van logische gegevensverzamelingen. Bijvoorbeeld: bij het tonen van medewerkergegevens wordt de logische gegevensverzameling "Medewerker" geraadpleegd. Validaties. Bijvoorbeeld: bij het opvragen van medewerkerinformatie wordt gecontroleerd of de gebruiker geautoriseerd is voor het raadplegen van deze informatie. Een logische manier van verwerken wordt als anders beschouwd indien: andere logische gegevensverzamelingen worden geraadpleegd; dezelfde logische gegevensverzamelingen worden geraadpleegd, maar er sprake is van andere validaties. Verschillende technologische oplossingen die gekozen zijn om dezelfde logische manier van verwerken te realiseren, leiden er niet toe dat de logische manier van verwerken als anders wordt beschouwd. De gegevens van het invoergedeelte van een opvragingsfunctie moeten de gewenste uitvoer uniek identificeren. Daarbij moet de omvang van de uitvoer volledig bepaald zijn. Met verdere gegevensverwerking wordt hier bedoeld: het toepassen van algoritmen of berekeningen op gegevens die uit de logische gegevensverzamelingen opgehaald zijn, voordat de informatie getoond wordt. Een functie is een elementaire functie als aan twee voorwaarden wordt voldaan: 66 NESMA

77 OPVRAGINGSFUNCTIES De functie heeft voor de gebruiker een zelfstandige betekenis en voert één geheel afgeronde verwerking van informatie uit. Ter verduidelijking kan hierbij gedacht worden aan het opvragen van de gegevens van een artikel op grond van het artikelnummer. Vanuit het gezichtspunt van de gebruiker is het invoeren van het artikelnummer en het tonen van de gegevens van het bijbehorende artikel één afgeronde verwerking. Het informatiesysteem is na het uitvoeren van de functie in een consistente staat. Hier kan gedacht worden aan hetzelfde voorbeeld als bij het vorige punt. Het slechts uitvoeren van één van beide stappen zou het systeem van het gezichtspunt van de gebruiker in een niet-consistente staat achterlaten. 9.2 Het tellen van opvragingsfuncties 9.2.a 9.2.b 9.2.c 9.2.d 9.2.e 9.2.f 9.2.g Tel iedere combinatie van invoer en uitvoer van gegevens, waarbij het invoeren van gegevens een directe generatie van uitvoer tot gevolg heeft, als een opvragingsfunctie, voor zover deze: een elementaire functie is, én uniek is binnen het te meten informatiesysteem, én de grens van het informatiesysteem (systeemgrens) overschrijdt. Opvragingsfuncties kunnen betrekking hebben op zowel opvragingen die rechtstreeks van de gebruiker afkomstig zijn, als op opvragingen die van andere informatiesystemen afkomstig zijn. Het onderscheid tussen een opvragingsfunctie en een invoerfunctie kan verder worden toegelicht door het volgende. Het invoergedeelte van een opvragingsfunctie dient uitsluitend om de zoekactie te dirigeren en het wijzigen van interne logische gegevensverzamelingen mag niet plaatsvinden. Zie de praktijksituatie zoals beschreven in paragraaf Verwar een query-faciliteit niet met een opvragingsfunctie. Een opvragingsfunctie is een directe zoekactie naar specifieke gegevens, in het algemeen met gebruikmaking van een enkele sleutel. Onder een query-faciliteit moet verstaan worden: een georganiseerde structuur van externe invoer-, uitvoer- en opvragingsfuncties om daarmee vele mogelijke opvragingen met vele sleutels en bewerkingen samen te stellen. Een dergelijke georganiseerde structuur wordt in het kader van FPA beschouwd alsof het een informatiesysteem is en moet als zodanig geteld worden wanneer deze apart ontwikkeld moet worden. Er dienen dan dus invoer-, uitvoer- en opvragingsfuncties geteld te worden om deze query-faciliteit te meten. Zie ook paragraaf Zie ook de praktijksituatie zoals beschreven in paragraaf Een opvragingsfunctie wordt alleen geteld als opvragingsfunctie als hij door de gebruiker als zodanig gespecificeerd en bedoeld is. Een opvragingsfunctie moet dus niet zonder meer geteld worden als de functie bijvoorbeeld onderdeel is van het in twee fasen invoeren van gegevens. Het invoergedeelte van een opvragingsfunctie mag niet als invoerfunctie geteld worden. Zie de praktijksituatie zoals beschreven in paragraaf Het uitvoergedeelte van een opvragingsfunctie mag niet als uitvoerfunctie geteld worden. Zie de praktijksituatie zoals beschreven in paragraaf DEFINITIES en TELRICHTLIJNEN FPA 67

78 OPVRAGINGSFUNCTIES 9.2.h 9.2.i 9.2.j Bij een opvragingsfunctie moet er sprake zijn van het invoeren van gegevens ter sturing van de gegevensverwerking (bijvoorbeeld het invoeren van selectiecriteria). Uniek identificerende gegevens moeten per definitie altijd deel uitmaken van de ingevoerde gegevens. Zie de praktijksituaties zoals beschreven in de paragrafen en Het onderscheid tussen een opvragingsfunctie en een uitvoerfunctie dient gemaakt te worden op basis van de volgende criteria: de uitvoer moet bij een opvragingsfunctie in omvang volledig bepaald zijn, én bij een opvragingsfunctie moet er sprake zijn van invoer van een uniek identificerend zoekargument, én de uitvoer mag bij een opvragingsfunctie geen gegevens bevatten die met behulp van verdere gegevensverwerking tot stand zijn gekomen, én er mag bij een opvragingsfunctie geen wijziging van interne logische gegevensverzamelingen plaatsvinden. Voor een toelichting op het begrip verdere gegevensverwerking: zie paragraaf 9.1. Tel voor het kunnen bladeren of scrollen door geproduceerde uitvoer geen extra functies of data-element-typen. Zie voor een nadere uitleg paragraaf Zie de praktijksituaties zoals beschreven in de paragrafen en Het bepalen van de complexiteit van opvragingsfuncties 9.3.a 9.3.b Data-element-typen De volgende richtlijnen voor het tellen van de data-element-typen zijn een concrete invulling van de generieke regel zoals aangegeven in paragraaf De initiatietrigger wordt als DET bij het invoergedeelte geteld. De foutboodschap wordt als DET bij het uitvoergedeelte geteld. Voor het bepalen van het niveau van de complexiteit van de externe opvragingsfunctie geldt de volgende werkwijze: 1. Classificeer het invoergedeelte van de opvragingsfunctie met gebruikmaking van de richtlijnen voor het bepalen van de complexiteit van de invoerfunctie en de complexiteitstabel voor het invoergedeelte hieronder, met dien verstande dat alleen de data-element-typen en logische gegevensverzamelingen worden beschouwd die voor het invoergedeelte relevant zijn. 2. Classificeer het uitvoergedeelte van de opvragingsfunctie met gebruikmaking van de richtlijnen voor het bepalen van de complexiteit van de uitvoerfunctie en de complexiteitstabel voor het uitvoergedeelte hieronder, met dien verstande dat alleen de data-element-typen en logische gegevensverzamelingen worden beschouwd die voor het uitvoergedeelte relevant zijn. 3. De complexiteit van de opvragingsfunctie wordt vervolgens bepaald door de meest complexe van de twee classificaties 68 NESMA

79 OPVRAGINGSFUNCTIES Complexiteitstabellen Voor het bepalen van het niveau van de complexiteit van de opvragingsfunctie worden de volgende tabellen gehanteerd: Voor het invoergedeelte: DET LGV 0-1 E E G E = Eenvoudig 2 E G M G = Gemiddeld 3+ G M M M = Moeilijk DET = Data-element-typen LGV = Logische gegevensverzamelingen Voor het uitvoergedeelte: DET LGV 0-1 E E G E = Eenvoudig 2-3 E G M G = Gemiddeld 4+ G M M M = Moeilijk DET LGV = Data-element-typen = Logische gegevensverzamelingen De beschikbaarheid van gegevens over het aantal data-element-typen en gerefereerde logische gegevensverzamelingen is afhankelijk van de fase van systeemontwikkeling waarin het informatiesysteem verkeert. Indien deze gegevens niet bekend zijn, dient een geïdentificeerde opvragingsfunctie als gemiddeld gewaardeerd te worden. DEFINITIES en TELRICHTLIJNEN FPA 69

80 PRAKTIJKSITUATIES MET OPLOSSINGEN 10 PRAKTIJKSITUATIES MET OPLOSSINGEN De onderstaande praktijksituaties zijn beschreven om degene die de functiepuntentelling moet uitvoeren te ondersteunen met praktische voorbeelden. Er worden problemen beschreven zoals die zich in werkelijkheid zouden kunnen voordoen en tegelijk wordt getoond hoe de telrichtlijnen voor FPA moeten worden toegepast. De voorbeelden zijn er voornamelijk op gericht te tonen hoe de te tellen functies kunnen worden onderkend. Waar dat van toepassing is wordt ook verteld hoe de data-element-typen geteld moeten worden. De structuur van de praktijksituaties is als volgt: een beschrijving van het probleem; een bespreking van de gerezen problemen voor de functiepuntentelling; de aanbevolen oplossing; verwijzingen naar de betreffende telrichtlijnen Standaard autorisatiefuncties Probleembeschrijving De gebruiker krijgt toegang tot het computersysteem via een logon-procedure door het ingeven van een computersysteem-identificatie, een gebruikers-identificatie en een wachtwoord. Deze logon-procedure is identiek voor alle informatiesystemen die op het systeem draaien. Om toegang te krijgen tot een specifiek informatiesysteem moet de gebruiker de desbetreffende informatiesysteem-identificatie en een wachtwoord intypen. De gebruiker is nu geautoriseerd om bepaalde gebruikerstransacties van het informatiesysteem uit te voeren. De wachtwoorden worden in een databasetabel binnen het informatiesysteem opgeslagen. De systeembeheerder kan de wachtwoorden wijzigen en aangeven welke gebruikerstransacties zijn toegestaan. Wordt deze logon-procedure wel of niet meegeteld? Hoe worden de autorisatietabel en de onderhoudsfuncties hiervoor geteld? Discussie Tel voor de logon-procedure geen functie. De autorisatietabel (waarin de wachtwoorden vastliggen) is een FPA-tabel en wordt dus als recordtype meegenomen binnen de FPA-tabellen- ILGV bij het tellen van de logische gegevensverzamelingen. Het wijzigen van de autorisatietabel wordt niet als aparte functie geteld, omdat voor de FPA-tabellen-ILGV standaard één invoer-, één uitvoer- en één opvragingsfunctie worden geteld. Oplossing Beschouw de autorisatietabel als een FPA-tabel. Tel voor de logon-procedure geen functie. Verwijzingen Zie de richtlijn 5.2.k en de paragrafen 4.9 en Specifieke autorisatiefuncties Probleembeschrijving Bij een tijdregistratie- en planningssysteem wordt in de gegevensverzameling Medewerker naast persoonsgegevens ook vastgelegd of iemand projectleider, supervisor of medewerker is. Een 70 NESMA

81 PRAKTIJKSITUATIES MET OPLOSSINGEN medewerker kan geautoriseerd zijn tot het vervullen van een of meerdere van deze rollen. De combinatie van deze rollen bepaalt welke gebruikerstransacties de gebruiker mag uitvoeren. Zo kan bijvoorbeeld alleen de projectleider activiteiten toevoegen aan een project. Andere projectleden zijn hiertoe niet geautoriseerd. Moet de gegevensverzameling Medewerker meegeteld worden bij het vaststellen van de complexiteit van de gebruikerstransactie "invoeren activiteiten"? Het gaat hierbij toch om een vorm van autorisatie? Discussie Om te kunnen vaststellen of een gebruiker een bepaalde gebruikerstransactie mag uitvoeren, moet de gegevensverzameling Medewerker worden geraadpleegd. Dit is een interne logische gegevensverzameling (geen FPA-tabel) en moet daarom worden meegeteld bij de bepaling van de complexiteit van de gebruikerstransactie. Oplossing Tel de gegevensverzameling Medewerker mee als een gerefereerde interne logische gegevensverzameling bij het vaststellen van de complexiteit van de invoerfunctie "invoeren activiteiten". Verwijzingen Zie de paragrafen 4.9 en 4.20 en richtlijn 7.3.h Rapportgenerator en query-faciliteit Probleembeschrijving Een informatiesysteem is ontwikkeld in een vierde generatie omgeving. Deze vierde generatie omgeving biedt de mogelijkheid van een interactieve query-faciliteit. De gebruiker kan zelf adhoc de gewenste queries maken en met behulp van dit geautomatiseerde gereedschap eigen overzichten produceren. Moet deze query-faciliteit en rapportgenerator in functiepunten uitgedrukt worden en zo ja op welke manier? Discussie De query-faciliteit en de rapportgenerator vallen buiten de grenzen van het te ontwikkelen informatiesysteem. Ze worden niet meegeteld bij het bepalen van de projectomvang of van de productomvang. Oplossing De query-faciliteit en de rapportgenerator als zodanig worden niet meegenomen in de functiepuntentelling voor het bepalen van de productomvang van het te ontwikkelen informatiesysteem en ook niet bij het bepalen van de projectomvang. Verwijzingen Zie paragraaf 4.11 en richtlijn 9.2.d. DEFINITIES en TELRICHTLIJNEN FPA 71

82 PRAKTIJKSITUATIES MET OPLOSSINGEN 10.4 Helpfuncties Probleembeschrijving Bij een te ontwikkelen informatiesysteem wordt een aantal helpschermen geïmplementeerd. Door middel van het intoetsen van de PF10-toets kan algemene informatie verkregen worden over het informatiesysteem, bijvoorbeeld welke modulen er bestaan en de samenhang tussen de verschillende modulen. Met behulp van de PF9-toets kan specifieke informatie over de betreffende gebruikerstransactie opgevraagd worden, bijvoorbeeld welke velden verplicht ingevuld moeten worden en het waardebereik van de verschillende velden. Deze helpteksten kunnen niet door de gebruiker onderhouden worden. Hoe wordt deze helpfaciliteit geteld? Discussie Helpschermen worden volgens de richtlijnen gewaardeerd als opvragingsfuncties. Het aantal soorten helpinformatie bepaalt het aantal functies. Omdat bij het gebruik van de PF9-toets helpinformatie op schermniveau wordt verkregen, terwijl bij het gebruik van de PF10-toets helpinformatie over het informatiesysteem verstrekt wordt, is hier sprake van twee soorten helpinformatie. Er is altijd sprake van eenvoudige opvragingsfuncties. Oplossing Tel deze helpfaciliteit als twee eenvoudige opvragingsfuncties. Verwijzingen Zie paragraaf Foutmeldingen Probleembeschrijving Bij het invoeren van de klantgegevens worden er diverse controles uitgevoerd. Wanneer het klantnummer al bestaat verschijnt de foutmelding "klant bestaat reeds"; wanneer letters in plaats van cijfers worden ingevoerd verschijnt de foutmelding "het klantnummer moet uit cijfers bestaan". Moet elke verschillende foutmelding als een aparte uitvoerfunctie of opvragingsfunctie geteld worden? Discussie De verschillende foutmeldingen worden niet als aparte gebruikersfuncties beschouwd, maar als een onderdeel van de desbetreffende invoer-, uitvoer- of opvragingsfunctie. Het veld waar de foutmelding getoond wordt, moet als data-element-type bij de functie worden geteld. Tel dus niet het aantal verschillende soorten berichten! Oplossing Voor foutmeldingen worden geen extra gebruikersfuncties geteld. Verwijzingen Zie richtlijn 8.2.n en paragraaf NESMA

83 PRAKTIJKSITUATIES MET OPLOSSINGEN 10.6 Menustructuren Probleembeschrijving Een informatiesysteem heeft de volgende menustructuur. Hoe moet de het activeren van de verschillende transacties, zoals Invoeren Klantgegevens, via de afrolmenu s geteld worden? Discussie Het getrapt activeren van een transactie (eerst keuze voor Administratie, dan Klantgegevens en dan de knop Invoeren) telt niet als een gebruikersfunctie. Wel wordt de knop Invoeren (inclusief het voorafgaande pad ) als één extra data-element-type bij de functie Invoeren klant geteld. De foutboodschappen die getoond worden bij foutieve invoer tellen eveneens als één data-element-type. Hetzelfde geldt voor de andere functies (Muteren, Verwijderen, Opvragen). Oplossing In dit voorbeeld worden één opvragingsfunctie en drie invoerfuncties geteld - invoeren, wijzigen en verwijderen van klantgegevens. Invoeren klantgegevens heeft acht data-element-typen (de zes invoervelden en de knop Invoeren en de foutboodschappen). Verwijzingen Zie de richtlijnen 7.2.m en 7.3.b en paragrafen 4.15 en DEFINITIES en TELRICHTLIJNEN FPA 73

84 PRAKTIJKSITUATIES MET OPLOSSINGEN 10.7 FPA-tabellen Probleembeschrijving Als onderdeel van een gegevensmodel in de derde normaalvorm van een verkoopsysteem, dat voorziet in de ondersteuning en vastlegging van de verkoopactiviteiten, zijn de volgende entiteittypen beschreven: Artikel: Land: BTW-tarief: Inkoper: artikelnummer (bestaande uit: artikelgroepnummer, volgnummer) omschrijving land van oorsprong (code) inkopernummer prijs btw-code landcode landnaam btw-code btw-tarief datum ingang inkopernaam inkopernummer Voor elk van de entiteittypen zijn functies beschikbaar voor het invoeren, wijzigen, verwijderen, en opvragen van de gegevens. Ook kan van elk entiteittype een rapport met alle exemplaren worden afgedrukt. Moeten deze gegevensverzamelingen als interne logische gegevensverzamelingen beschouwd worden en is er sprake van een FPA-tabellen-ILGV of FPA-tabellen-KGV en wat is de complexiteit ervan? Discussie Conform het gestelde in paragraaf 4.20 is het entiteittype BTW-tarief geen FPA-tabel, maar een afzonderlijke interne logische gegevensverzameling. Omdat de entiteittypen Land en Inkoper alleen gebruikt worden voor het decoderen van de gebruikte codes en nummers (met andere woorden een secundaire functie vervullen), moeten deze als een FPA-tabel beschouwd worden. Er wordt bijvoorbeeld over de inkopers geen additionele informatie bijgehouden. Vanwege het feit dat alle entiteittypen onderhoudbaar zijn, is er sprake van een FPA-tabellen- ILGV. De complexiteit hiervan wordt als volgt bepaald. Het totaal aantal entiteittypen (twee: Land en Inkoper) bepaalt het aantal recordtypen van de FPA-tabellen-ILGV. Het totale aantal dataelement-typen (bij elkaar vier) van de verschillende entiteittypen van het type FPA-tabel vormt het aantal data-element-typen van FPA-tabellen-ILGV. Via de complexiteitstabel voor interne logische gegevensverzamelingen kan de complexiteit van de FPA-tabellen-ILGV bepaald worden (eenvoudig). Tel voor de FPA-tabellen-ILGV standaard één invoer-, één uitvoer- en één opvragingsfunctie, ongeacht het aantal entiteittypen waaruit de FPA-tabellen-ILGV bestaat. 74 NESMA

85 PRAKTIJKSITUATIES MET OPLOSSINGEN Oplossing Tel drie interne logische gegevensverzamelingen: Artikel, met één recordtype en zeven data-element-typen, zodat de complexiteit eenvoudig is. BTW-tarief, met één recordtype en drie data-element-typen, zodat de complexiteit eenvoudig is. Voor de FPA-tabellen één interne logische gegevensverzameling. Er zijn vier dataelement-typen (landcode, landnaam, inkopernummer, inkopernaam) en het aantal recordtypen is twee (de entiteittypen Land en Inkoper), zodat de complexiteit eenvoudig is. Verwijzingen Zie de paragrafen 4.20 en 4.21 en de richtlijnen 5.2.a en 5.2.k Denormalisatie In dit voorbeeld worden voor de situatie waarin tussen twee entiteittypen een 1:(N) relatie bestaat drie voorbeelden van denormalisatie gegeven. De situaties 1:N, (1):N (1):(N), 1:(1) en (1):(1) spreken voor zich (zie paragraaf voor een toelichting op deze notatiewijze) :(N) met bestaanszelfstandigheid Probleembeschrijving Discussie Het genormaliseerde gegevensmodel van een informatiesysteem van een bibliotheek geeft aan dat er tussen de entiteittypen Boek en Uitleen sprake is van 1 : (N) relatie. Een Boek hoeft niet uitgeleend te zijn, zodat er sprake is van optionaliteit. Als er sprake is van Uitleen, heeft dat altijd betrekking op één Boek (geen optionaliteit). De bedrijfsregel voor de bibliotheek is, dat we een Boek alleen kunnen verwijderen als er geen Uitleen meer aan gekoppeld is. Is er in deze situatie sprake van één of van twee logische gegevensverzamelingen? Er is sprake van een 1:(N) relatie tussen Boek en Uitleen. Volgens de tabel in paragraaf wordt dan op grond van de bestaansafhankelijkheid het aantal logische gegevensverzamelingen bepaald. Vanwege de bedrijfsregel dat een Boek alleen verwijderd mag worden als er geen Uitleen meer aan gekoppeld is, concluderen we dat Uitleen kennelijk ook los van Boek betekenis in het informatiesysteem heeft en dus bestaanszelfstandig is ten opzichte van Boek (er is sprake van situatie 2 bij de discussie in paragraaf over bestaanszelfstandigheid bij een 1:(N) relatie). Er is dus sprake van twee logische gegevensverzamelingen. Oplossing Boek Uitleen Tel twee interne logische gegevensverzamelingen. Verwijzingen Zie paragraaf 4.21 en richtlijn 5.2.a. DEFINITIES en TELRICHTLIJNEN FPA 75

86 PRAKTIJKSITUATIES MET OPLOSSINGEN :(N) met bestaansafhankelijkheid Probleembeschrijving Het genormaliseerde gegevensmodel van een informatiesysteem van een bibliotheek geeft aan dat er tussen de entiteittypen Boek en Uitleen sprake is van 1 : (N) relatie. Een Boek hoeft niet uitgeleend te zijn, zodat er sprake is van optionaliteit. Als er sprake is van Uitleen, heeft dat altijd betrekking op één Boek (geen optionaliteit). Bij deze bibliotheek is echter de volgende bedrijfsregel van kracht: indien het Boek uit de collectie gehaald wordt (het Boek wordt verwijderd), dan is de bibliotheek niet meer geïnteresseerd in de eventuele Uitleen en mag deze dus automatisch mee worden verwijderd. Hoeveel logische gegevensverzamelingen moeten in dit geval onderkend worden? Discussie Er is sprake van een 1:(N) relatie tussen Boek en Uitleen. Volgens de tabel in paragraaf wordt dan op grond van de bestaansafhankelijkheid het aantal logische gegevensverzamelingen bepaald. Vanwege de bedrijfsregel dat een Boek altijd verwijderd mag worden en dat een eventueel daaraan gekoppelde Uitleen automatisch medeverwijderd wordt, concluderen we dat Uitleen in dit geval kennelijk in het informatiesysteem geen betekenis heeft los van Boek en dus bestaansafhankelijk is ten opzichte van Boek (er is sprake van situatie 1 bij de discussie in paragraaf over bestaanszelfstandigheid bij een 1:(N) relatie). Er is dus sprake van één logische gegevensverzameling. Oplossing Hier is sprake van één logische gegevensverzameling met twee recordtypen. Verwijzingen Zie paragraaf 4.21 en richtlijn 5.2.a :(N) met bestaansafhankelijkheid Probleembeschrijving Factuurkop Factuurregel Het genormaliseerde gegevensmodel van een factureringssysteem geeft aan dat er een 1:(N) relatie is tussen Factuurkop en Factuurregel. Het informatiesysteem staat toe dat een Factuurkop wordt aangemaakt, waar pas in een later stadium regels aan toegevoegd worden, vandaar de optionaliteit. Als men echter op gegeven moment besluit de Factuurkop te verwijderen, worden de Factuurregels automatisch meeverwijderd. Hoeveel logische gegevensverzamelingen moeten in deze situatie onderscheiden worden? Discussie Er is sprake van een 1:(N) relatie tussen Factuurkop en Factuurregel. Volgens de tabel in paragraaf wordt dan op grond van de bestaansafhankelijkheid het aantal logische gegevensverzamelingen bepaald. Vanwege de bedrijfsregel dat bij het verwijderen van een Factuurkop altijd de eventueel daaraan gekoppelde Factuurregels automatisch meeverwijderd worden, concluderen we dat Factuurregel bestaansafhankelijk is ten opzicht van Factuurkop (er 76 NESMA

87 PRAKTIJKSITUATIES MET OPLOSSINGEN is sprake van situatie 1 bij de discussie in paragraaf over bestaanszelfstandigheid bij een 1:(N) relatie). Er is dus sprake van één logische gegevensverzameling Factuur, die de entiteittypen Factuurkop en Factuurregel omvat. Oplossing Hier is sprake van één logische gegevensverzameling met twee recordtypen. Verwijzingen Zie paragraaf 4.21 en richtlijn 5.2.a Bepalen van logische gegevensverzamelingen Probleembeschrijving Hieronder wordt een deel van een genormaliseerd gegevensmodel getoond. BELASTINGPLICHTIGE STANDAARDBRIEF ADRES ONTVANGEN BETALING VERZENDLIJST CONTACTPERSOON TOEGEWEZEN BETALING SOORT BELASTING BELASTING AANSLAG TE BETALEN BELASTING Ten aanzien van dit gegevensmodel zijn op grond van de eisen van de opdrachtgever de volgende specificaties geformuleerd. Alle genoemde entiteittypen worden door het informatiesysteem onderhouden. DEFINITIES en TELRICHTLIJNEN FPA 77

88 PRAKTIJKSITUATIES MET OPLOSSINGEN Het entiteittype Belastingplichtige bevat een Sofi-nummer, de naam, de geboortedatum, en nog enkele persoonlijke kenmerken van een belastingplichtige. Een belastingplichtige kan meerdere adressen hebben: naast het woonadres (dat minimaal aanwezig is) kan ook een factuuradres en/of een postadres onderkend worden. Het entiteittype Standaardbrief bestaat uit een uniek briefnummer en de bij die brief behorende vaste tekst. Het entiteittype Verzendlijst bevat slechts verwijzende sleutels en legt daardoor vast welke brief naar welke belastingplichtige wordt gestuurd. Het entiteittype Soort Belasting bevat alle soorten belasting die voor kunnen komen. De samenstelling is als volgt: code, omschrijving en belastingbedrag per maand (in dit geval gaat het om vaste aanslagen die voor elke belastingplichtige gelijk zijn). In het entiteittype Te Betalen Belasting wordt vastgelegd welke belastingen door welke belastingplichtige moeten worden betaald. Het bevat naast verwijzende sleutels gegevens over de datum waarop de belastingplicht ingaat en de datum waarop de belastingplicht ophoudt (deze datum is meestal bij aanvang van de belastingplicht niet bekend, maar wordt pas later vastgelegd). Het entiteittype Belasting Aanslag bevat naast een bedrag ook de uiterste betaaldatum en de periode waarvoor de aanslag geldt. Een aanslag betreft altijd een vaste periode (jaarlijks, halfjaarlijks, per kwartaal of maandelijks). Het entiteittype Ontvangen Betaling bevat het ontvangen bedrag, de datum waarop de betaling ontvangen is en het bedrag dat nog niet aan een Belasting Aanslag is toegewezen. Het entiteittype Toegewezen Betaling bevat naast verwijzende sleutels naar Belasting Aanslag en Ontvangen Betaling ook het deel van de Ontvangen Betaling dat voor de betaling van de gekoppelde Belasting Aanslag is toegewezen. Het entiteittype Contactpersoon bevat de naam en een aantal aanvullende gegevens van die medewerkers van de organisatie die als contactpersoon naar een belastingplichtige kunnen optreden. Een contactpersoon wordt pas toegewezen als een belastingplichtige daadwerkelijk om advies vraagt en vanaf dat moment wordt de belastingplichtige steeds door dezelfde persoon te woord gestaan. In principe wordt iemand slechts in het systeem geregistreerd als hij één of meer soorten belasting moet betalen. Zodra een belastingplichtige niet meer voor een Soort Belasting geregistreerd staat (dat wil zeggen alle einddatums van Te Betalen Belasting zijn verstreken, of anders gezegd: de belastingplicht is beëindigd) en er geen Ontvangen Betalingen meer aan de belastingplichtige gekoppeld zijn, dan kan de Belastingplichtige verwijderd worden. Bij het verwijderen van de belastingplichtige worden de Te Betalen Belastingen automatisch meeverwijderd, mits er geen Belasting Aanslagen meer aan gekoppeld zijn. Een Belasting Aanslag wordt één jaar nadat de Belasting Aanslag volledig betaald is via een batchfunctie gearchiveerd. In het archiefbestand worden het Sofi-nummer, de soort belasting, de periode, het belastingbedrag, de datum waarop de aanslag verstuurd was en de datum waarop de aanslag volledig betaald was, vastgelegd. Bij het vastleggen van de gegevens in het archief wordt meteen de Belasting Aanslag samen met de daaraan gekoppelde Toegewezen Betalingen verwijderd. Een Ontvangen Betaling kan alleen verwijderd worden als het volledige bedrag is toegewezen en als er geen Toegewezen Betalingen meer aan gekoppeld zijn. Tot slot mag een Soort Belasting pas verwijderd worden als er geen Te Betalen Belastingen aan gekoppeld zijn. Om hoeveel logische gegevensverzamelingen gaat het in dit genormaliseerde gegevensmodel? Zijn er historische bestanden in aanwezig? 78 NESMA

89 PRAKTIJKSITUATIES MET OPLOSSINGEN Discussie Bij de analyse van dit gegevensmodel gaan we uit van de denormalisatieregels zoals die in paragraaf 4.21 zijn weergegeven. De eerste vraag die gesteld moet worden, is de vraag of er sprake is van FPA-tabellen. Uit de omschrijving van de entiteittypen blijkt dat alleen het entiteittype Standaardbrief voldoet aan de criteria voor een FPA-tabel. Het enige entiteittype waarover discussie kan zijn in dit verband, is Soort Belasting. Dit entiteittype bevat echter naast code en omschrijving ook nog een bedrag, zodat er sprake is van meerdere ongelijksoortige gegevens. De volgende vraag die conform de denormalisatieregels gesteld moet worden is, welke entiteittypen uitsluitend sleutelgegevens bevatten. In dit gegevensmodel is dat alleen het entiteittype Verzendlijst. Het entiteittype Toegewezen Betaling bevat naast de verwijzende sleutels ook nog het aan een Belasting Aanslag toegewezen betaalde bedrag en voldoet dus niet aan de eisen op dit punt. Het entiteittype Te Betalen Belasting bevat ook meer gegevens dan alleen sleutelgegevens. Voor de overige acht entiteittypen moet op grond van cardinaliteit, optionaliteit en bestaanszelfstandigheid bekeken worden hoeveel interne logische gegevensverzamelingen zij vertegenwoordigen. Hiertoe wordt van elk tweetal via een relatie verbonden entiteittypen bekeken of ze in één logische gegevensverzameling moeten worden samengenomen. De relatie tussen Belastingplichtige en Contactpersoon is tweezijdig optioneel. Volgens de richtlijnen zijn het daarom onafhankelijke gegevensverzamelingen. Contactpersoon heeft verder geen relaties met overige entiteittypen, zodat dit één interne logische gegevensverzameling is met één recordtype. De relatie tussen Belastingplichtige en Adres is een tweezijdig verplichte 1:N relatie. Conform de denormalisatieregels worden deze twee entiteittypen tot dezelfde interne logische gegevensverzameling gerekend. Om te onderzoeken of er nog meer entiteittypen tot deze interne logische gegevensverzameling gerekend moeten worden, moeten de overige relaties van Belastingplichtige onderzocht worden. De relatie tussen het entiteittype Belastingplichtige en Ontvangen Betaling is een 1:(N) relatie, waarbij geldt dat zolang er nog een Ontvangen Betaling aan een Belastingplichtige gekoppeld is, een Belastingplichtige niet mag worden verwijderd. Ontvangen Betaling heeft dus kennelijk ook buiten Belastingplichtige betekenis en is dus bestaanszelfstandig ten opzichte van Belastingplichtige. Ontvangen Betaling wordt daarom niet tot dezelfde interne logische gegevensverzameling gerekend als Belastingplichtige en Adres. De volgende relatie van Belastingplichtige die bekeken moet worden is de 1:(N) relatie tussen Belastingplichtige en Te Betalen Belasting. Hier geldt dat, als de Belastingplichtige wordt verwijderd, de gekoppelde Te Betalen Belastingen automatisch meeverwijderd worden. Te Betalen Belasting is dus bestaansafhankelijk van Belastingplichtige en wordt daarom tot dezelfde interne logische gegevensverzameling gerekend als Belastingplichtige en Adres. Of er nog meer entiteittypen tot deze interne logische gegevensverzameling gerekend moeten worden, hangt hierdoor nu ook af van de relaties van Te Betalen Belasting. De relatie tussen Te Betalen Belasting en Belasting Aanslag is een 1:(N) relatie. Uit de beschrijving blijkt dat een Te Betalen Belasting slechts verwijderd mag worden als er geen Belasting Aanslag meer aan gekoppeld is. Belasting Aanslag heeft in dit systeem dus een eigen betekenis en moet als bestaanszelfstandig beschouwd worden ten opzichte van Te Betalen Belasting. DEFINITIES en TELRICHTLIJNEN FPA 79

90 PRAKTIJKSITUATIES MET OPLOSSINGEN De relatie tussen Soort Belasting en Te Betalen Belasting is ook van het type 1:(N). Een Soort Belasting mag alleen verwijderd worden als er geen Te Betalen Belasting aan gekoppeld is. Ten opzichte van Soort Belasting is Te Betalen Belasting dus bestaanszelfstandig. Omdat nu alle relaties van Belastingplichtige, Adres en Te Betalen Belasting zijn geanalyseerd kunnen we concluderen dat Belastingplichtige samen met Adres en Te Betalen Belasting één interne logische gegevensverzameling vormt met drie recordtypen. Ontvangen Betaling, zo hebben we gezien, is bestaanszelfstandig ten opzichte van Belastingplichtige. Om na te gaan of dit entiteittype op zichzelf een interne logische gegevensverzameling is, moeten we de relatie met Toegewezen Betaling onderzoeken. Dit is een 1:(N) relatie. Uit de beschrijving blijkt dat het verwijderen van een Ontvangen Betaling alleen kan als er geen Toegewezen Betaling meer aan gekoppeld is. Toegewezen Betaling is daarom bestaanszelfstandig ten opzichte van Ontvangen Betaling. Ontvangen Betaling is daarom op zichzelf een interne logische gegevensverzameling met één recordtype. Hiervoor is al aangegeven dat Belasting Aanslag bestaanszelfstandig is ten opzichte van Te Betalen Belasting. Belasting Aanslag heeft nog een 1:(N) relatie met Toegewezen Betaling. Volgens de beschrijving worden bij het archiveren en verwijderen van een Belasting Aanslag, automatisch de daaraan gekoppelde Toegewezen Betalingen mee verwijderd. Ten opzichte van Belasting Aanslag is een Toegewezen Betaling daarom bestaansafhankelijk. Belasting Aanslag en Toegewezen Betaling vormen derhalve samen één interne logische gegevensverzameling met twee recordtypen. Te Betalen Belasting is, zoals hiervoor al aangegeven, bestaanszelfstandig ten opzichte van Soort Belasting. Soort Belasting heeft verder geen relaties met andere entiteittypen en bleek ook geen FPA-tabel te zijn. Het is dus een zelfstandige interne logische gegevensverzameling met één recordtype. Uit de beschrijving blijkt dat er sprake is van een bestand met historische gegevens. Dit bestand is niet als entiteittype in het gegevensmodel opgenomen. Het is echter wel geëist door de opdrachtgever. De samenstelling van dit bestand is anders dan de samenstelling van de overige interne logische gegevensverzamelingen, zodat hiervoor een aparte interne logische gegevensverzameling geteld moet worden met één recordtype. 80 NESMA

91 PRAKTIJKSITUATIES MET OPLOSSINGEN Oplossing Tel interne logische gegevensverzamelingen zoals hieronder is aangegeven. Verwijzingen Entiteittypen: Tellen als: Aantal recordtypen: Belastingplichtige + Adres + Te Betalen Belasting 1 ILGV 3 Soort Belasting 1 ILGV 1 Ontvangen Betaling 1 ILGV 1 Belasting Aanslag + Toegewezen Betaling 1 ILGV 2 Contactpersoon 1 ILGV 1 Standaardbrief Tellen als onderdeel van de FPA-tabellen-ILGV Verzendlijst Niet tellen Belasting Aanslag Historie 1 ILGV 1 Zie de paragrafen 4.20 en 4.21 en de richtlijnen 5.2.a, 5.2.b, 5.2.i en 5.2.k. 1 DEFINITIES en TELRICHTLIJNEN FPA 81

92 PRAKTIJKSITUATIES MET OPLOSSINGEN Gecombineerde invoerfuncties Probleembeschrijving Een informatiesysteem biedt de gebruiker met behulp van onderstaand scherm de mogelijkheid om productgegevens te onderhouden. Na het invoeren van een productcode verschijnt er óf een leeg scherm óf een scherm met de bestaande productgegevens. Bij een nieuwe productcode kunnen de overige gegevens ingetypt worden. Met behulp van de knop Toevoegen / wijzigen kunnen de gegevens in het bestand gezet worden. Wanneer het een bestaande productcode betreft, dan kunnen de gegevens gewijzigd worden en met behulp van deze knop vastgelegd. Het product kan verwijderd worden met behulp van de knop Verwijderen, hierbij wordt dan wel gecontroleerd of er geen voorraad meer van dit product aanwezig is. Hoeveel en welke soorten functies zijn hier te onderscheiden? Discussie Het invoeren van de gegevens van een nieuw product is een invoerfunctie. Vergeet niet de knop Toevoegen/wijzigen als data-element-type mee te tellen. Het wijzigen van productgegevens is een tweede invoerfunctie. Dezelfde verzameling dataelement-typen is gebruikt voor een andere logische manier van verwerking, namelijk het wijzigen van productgegevens. Hierbij wordt dezelfde knop gebruikt, deze wordt dus ook voor deze invoerfunctie als data-element-type meegeteld. Het verwijderen van productgegevens is de derde invoerfunctie. Ook deze functie verschilt logisch gezien wezenlijk van de twee bovenstaande. Indien de gegevensverzameling van de voorraadgegevens door de gebruiker als een afzonderlijke gegevensverzameling wordt beschouwd, moet zij meegeteld worden bij het bepalen van de complexiteit van deze invoerfunctie. Het tonen van de productgegevens wordt niet als aparte functie geteld, omdat het doel van de gebruiker het invoeren, wijzigen of verwijderen van productgegevens is. Alleen wanneer het doel van de gebruiker met deze functie het opvragen van de productgegevens is, dan moet het tonen van de gegevens als aparte opvragingsfunctie geteld worden. 82 NESMA

93 PRAKTIJKSITUATIES MET OPLOSSINGEN Oplossing Tel drie invoerfuncties Verwijzingen Zie paragraaf 4.7 en 4.23 en de richtlijnen 7.2.g, 7.2.n, 7.2.o en 7.2.p Tellen van een transactiebestand Probleembeschrijving Bij een Winkel Management Systeem komt een bestand met winkeltransacties binnen. De transacties worden van elkaar onderscheiden door een transactiecode. De voorkomende codes zijn: 01 = verkoop contant balie 02 = retour contant balie 03 = verkoop op rekening balie 04 = retour op rekening balie 05 = verkoop contant, levering overig 06 = retour contant, levering overig 07 = verkoop op rekening, levering overig 08 = retour op rekening, levering overig 09 = goederen verzenden 10 = goederen ontvangen 11 = ophalen artikel monteur 12 = retour artikel monteur 13 = verzenden oud materiaal 14 = ontvangen oud materiaal 15 = negatief magazijnverschil 16 = positief magazijnverschil 20 = initieel ingebrachte voorraad bij de winkel. Afhankelijk van de transactiecode worden de volgende gegevensverzamelingen bijgewerkt. 1 t/m 4: journaalpost-gegevens, verkoopgegevens en voorraad-gegevens. 5 t/m 8: journaalpost-gegevens en verkoopgegevens. 9 t/m 14: journaalpost-gegevens en voorraad-gegevens. 15 en 16: magazijnverschillen, journaalpost-gegevens en voorraad-gegevens. 20: voorraad-gegevens. Hoeveel invoerfuncties moeten hier geteld worden? Discussie In deze situatie wordt voornamelijk op grond van het bijwerken van verschillende logische gegevensverzamelingen een indeling gemaakt in het aantal verschillende logische verwerkingen dat onderkend kan worden. De betekenis van de transactiecodes ondersteunt deze keuze. De volgende invoerfuncties voor het verwerken van de transacties worden onderkend: 1. Het verwerken van transacties die met "balieactiviteiten" te maken hebben (transactiecodes 1 t/m 4); 2. Het verwerken van transacties die met "overige leveringen" te maken hebben (transactiecodes 5 t/m 8); 3. Het verwerken van transacties die met voorraadmutaties in het magazijn te maken hebben (transactiecodes 9 t/m 14); DEFINITIES en TELRICHTLIJNEN FPA 83

94 PRAKTIJKSITUATIES MET OPLOSSINGEN 4. Het verwerken van transacties die met magazijnverschillen te maken hebben (transactiecodes 15 en 16); 5. Een invoerfunctie voor het verwerken van de initiële voorraad (transactiecode 20). Oplossing Tel vijf invoerfuncties. Verwijzingen Zie paragraaf 4.8 en de richtlijnen 7.2.a, 7.2.b, 7.2.d en 7.2.t Rapporten op verschillende media Probleembeschrijving Een selectiescherm biedt de mogelijkheid om twee soorten overzichten aan te vragen en de bestemming ervan aan te geven: Het tijdregistratie-overzicht laat de ingevoerde tijdregistratiegegevens zien; het statusoverzicht is een lijst met de status van de tijdregistratieformulieren. Het tijdregistratie-overzicht is precies gelijk qua indeling en qua getoonde attributen of het nu op papier of op het scherm afgedrukt wordt of naar een bestand geëxporteerd wordt. Dit geldt evenzo voor het statusoverzicht. Is het overzicht op papier een andere uitvoerfunctie dan die op het scherm of de uitvoer naar een bestand? Van hoeveel uitvoerfuncties is hier sprake? Is hier sprake van een invoerfunctie voor het opgeven van het soort overzicht en/of voor het opgeven van de bestemming? Discussie Het criterium voor het vaststellen van het aantal uitvoerfuncties is, dat iedere uitvoerfunctie uniek moet zijn. Een uitvoerfunctie is uniek indien er voor het desbetreffende informatiesysteem geen andere uitvoerfunctie bestaat met dezelfde logische verwerking en dezelfde verzameling data-element-typen. Uit de beschrijving blijkt dat Statusoverzicht andere informatie bevat dan het Overzicht Tijdregistratie, zodat het twee afzonderlijke uitvoerfuncties zijn. 84 NESMA

95 PRAKTIJKSITUATIES MET OPLOSSINGEN In dit voorbeeld geldt verder dat het Overzicht Tijdregistratie voor wat de indeling betreft bestaat uit dezelfde verzameling data-element-typen ongeacht de bestemming. Uit de beschrijving blijkt niet dat er voor de verschillende media waarheen het overzicht gestuurd kan worden sprake is van een andere logische verwerking. Het Overzicht Tijdregistratie wordt daarom als één uitvoerfunctie geteld. Hetzelfde geldt voor het Statusoverzicht. De ingevoerde gegevens voor de bestemming zijn besturingsinformatie. Ze dienen slechts om de uitvoer te besturen, zodat er geen sprake is van een invoerfunctie. Oplossing Tel twee uitvoerfuncties, één voor het overzicht tijdregistratie en één voor het statusoverzicht. Het keuzeveld voor het medium en het veld waar eventueel de bestandsnaam ingevuld kan worden moeten elk als een data-element-type meegeteld worden bij het vaststellen van de complexiteit. Tel ook voor beide overzichten een extra data-element-type om de transactie te starten (eventuele keuzen in afrolmenu s tot en met de radio button voor het betreffende overzicht). Verwijzingen Zie de richtlijnen 8.2.e, 8.2.i, 8.3.b en 8.3.c en paragraaf 4.15 en Tijdelijke mutatiebestanden Probleembeschrijving Dagelijks wordt er op papier een overzicht gegeven van alle financiële mutaties van de betreffende dag. Aan het einde van iedere week worden alle mutaties van die week op microfiche gezet. De indeling is gelijk aan die van het dagelijkse mutatieoverzicht. Na verwerking van de mutaties wordt het desbetreffende mutatiebestand verwijderd. De inhoud van het bestand wordt alleen op de hier beschreven wijze afgedrukt en uiteindelijk op microfiche gezet. Het is niet op andere wijze toegankelijk voor de gebruiker. Hoeveel uitvoerfuncties moeten worden onderkend? Is er ook sprake van een invoerfunctie voor het verwijderen van het mutatiebestand? Telt het mutatiebestand als een interne logische gegevensverzameling of een koppelingsgegevensverzameling? Discussie Het mutatiebestand is niet toegankelijk voor de gebruiker en is daarom geen logische gegevensverzameling. Omdat het een tijdelijk bestand is, wordt het verwijderen als een technische zaak beschouwd die bij het op logisch niveau beoordelen van de functies geen rol speelt. Logisch gezien is er dan ook geen verschil tussen de dagelijkse en de wekelijkse verwerking. De indeling van het dagoverzicht is gelijk aan die van de microfiche. Omdat dus zowel de indeling als de logische verwerking gelijk zijn, is er sprake van slechts één uitvoerfunctie. Oplossing Tel één uitvoerfunctie. Verwijzingen Zie de richtlijnen 5.2.f, 7.2.r en 8.2.a. DEFINITIES en TELRICHTLIJNEN FPA 85

96 PRAKTIJKSITUATIES MET OPLOSSINGEN Conversie Probleembeschrijving Bij de ingebruikname van een financieel systeem (AIM) zijn eenmalig de gegevens vanuit een reeds bestaand systeem (PAS) geconverteerd. Het systeem PAS wordt nog steeds gebruikt en wekelijks worden er nu gegevens verstuurd vanuit AIM naar PAS. Hoe moet de conversieprogrammatuur en de uitwisseling van gegevens worden geteld bij het informatiesysteem AIM? Discussie Wanneer, zoals in het bovenstaande voorbeeld, programmatuur voor een eenmalige conversie is ontwikkeld, dan wordt deze functie niet bij het bepalen van de productomvang van het informatiesysteem meegenomen. De conversieprogrammatuur moet wel meegeteld worden bij het bepalen van de projectomvang. De wekelijkse verzending van gegevens vanuit AIM is echter een normale uitvoerfunctie en dient als zodanig meegenomen te worden in de functiepuntentelling. Oplossing Tel de wekelijkse conversie als één of meer uitvoerfuncties van het informatiesysteem AIM. Tel de initiële eenmalige conversie niet mee bij het bepalen van de productomvang, maar tel die wel mee bij het bepalen van de projectomvang. Verwijzingen Zie paragraaf en de richtlijnen 6.2.c, 8.2.b en 8.2.j. 86 NESMA

97 PRAKTIJKSITUATIES MET OPLOSSINGEN Uitvoerfuncties met samenvattende informatie In dit voorbeeld worden twee situaties behandeld: één waarbij de samenvattende informatie niet als een aparte uitvoerfunctie wordt beschouwd en één waarbij dit wel het geval is Samenvattende informatie niet als aparte uitvoerfunctie geteld Probleembeschrijving Het volgende overzicht kan geproduceerd worden: Rapport 1A Overzicht Audio 20/07/2003 Lopende maand:03-07 Periode: April-Juni Land Verkoop Netto Aantal Omzet Netto Marge Lokaal Euro (x1000) Euro % (x1000) (x1000) Oostenrijk xxx.xx xx.xx xx.x xxxxx xx.x xxxxx Spanje xxx.xx xx.xx xx.x xxxxx xx.x xxxxx Portugal xxx.xx xx.xx xx.x xxxxx xx.x xxxxx Duitsland xxx.xx xx.xx xx.x xxxxx xx.x xxxxx Europa xxx.xx xx.xx xx.x xxxxx xx.x xxxxx Europa xxx.xx xx.xx xx.x xxxxx xx.x xxxxx Azië xxx.xx xx.xx xx.x xxxxx xx.x xxxxx Overige xxx.xx xx.xx xx.x xxxxx xx.x xxxxx Het overzicht bestaat uit een onbekend aantal pagina's. Aan het einde van het overzicht worden de totalen van Europa, Azië en de rest afgedrukt. Is hier sprake van één of meerdere uitvoerfuncties? Moet de geaggregeerde informatie op het overzicht als aparte functie geteld worden of gaat het hierbij om dezelfde uitvoerfunctie? Discussie Er is hier sprake van één uitvoerproduct (het overzicht), dat weliswaar bestaat uit twee delen, maar waarvan de delen dezelfde indeling hebben. Verder is de samenvattende informatie voor Europa, Azië en Overige onlosmakelijk verbonden met de rest van het overzicht, zodat er sprake is van één uitvoerproduct, waarvan de delen niet afzonderlijk opvraagbaar zijn. Er worden geen extra logische gegevensverzamelingen benaderd om de gewenste informatie te kunnen afdrukken. De informatie is rechtstreeks af te leiden uit het voorgaande, binnen dezelfde logische verwerking. De richtlijnen geven aan dat in deze situatie slechts één uitvoerfunctie onderkend moet worden. Oplossing Tel één uitvoerfunctie. DEFINITIES en TELRICHTLIJNEN FPA 87

98 PRAKTIJKSITUATIES MET OPLOSSINGEN Verwijzingen Zie paragraaf 4.7 en de richtlijnen 8.2.g en 8.3.d Samenvattende informatie wel als aparte uitvoerfunctie geteld Probleembeschrijving Een informatiesysteem produceert het volgende overzicht: DAG OVERZICHT FINANCIELE TRANSACTIES Blad:99 Datum: Verkoper Transactiesoort Bedrag x x x x 9999,99 x x x x 9999,99 x x x x 9999,99 x x x x 9999,99 TOTALEN FINANCIELE TRANSACTIES Blad:99 Datum: Transactiesoort Aantal Bedrag x x Dagtotaal ,99 Cumulatie jaar ,99 Dag gemiddelde ,99 x x Dagtotaal ,99 Cumulatie jaar ,99 Dag gemiddelde ,99 Is hier sprake van één of meerdere uitvoerfuncties? Moet de geaggregeerde informatie op het overzicht als aparte functie geteld worden of gaat het hierbij om dezelfde uitvoerfunctie? Discussie Bij het bovenstaande overzicht is er sprake van één uitvoerproduct waarin twee delen te onderscheiden zijn. Het eerste deel is een lijst met alle transacties die op een dag hebben plaatsgevonden. Het tweede deel geeft dagtotalen, maar laat ook zien hoeveel transacties van een bepaalde soort er al in het afgelopen jaar zijn geweest en hoeveel er gemiddeld per dag zijn geweest. De twee delen hebben een verschillende indeling. Volgens de richtlijnen is er dan sprake van twee uitvoerfuncties als de delen afzonderlijk opvraagbaar zijn óf als de delen via afzonderlijke logische verwerkingen tot stand komen. In dit geval zijn de delen niet afzonderlijk opvraagbaar. Omdat bij het tweede deel andere gegevens gebruikt worden, is er sprake van een andere logische verwerking dan bij het maken van het eerste deel. De richtlijnen geven aan dat in deze situatie twee uitvoerfuncties onderkend moeten worden. Oplossing Tel twee uitvoerfuncties. Verwijzingen Zie paragraaf 4.7 en richtlijn 8.2.g. 88 NESMA

99 PRAKTIJKSITUATIES MET OPLOSSINGEN Het aantal data-element-typen op een overzicht Probleembeschrijving Rapport 1A Overzicht Audio (1) 20/07/2003 Land Verkoop Omzet Netto Marge Oostenrijk (4) Lokaal Euro % (x1000) xxx.xx (5) (x1000) xxxxx (6) xx.x (7) xxxxx (8) Spanje xxx.xx xxxxx xx.x xxxxx Portugal xxx.xx xxxxx xx.x xxxxx Duitsland xxx.xx xxxxx xx.x xxxxx Europa (9) xxx.xx (10) xxxxx (11) xx.x (12) xxxxx (13) Lopende maand:03-07 (2) Periode: April-Juni (3) Europa xxx.xx xxxxx xx.x xxxxx Azië xxx.xx xxxxx xx.x xxxxx Overige xxx.xx xxxxx xx.x xxxxx Dit rapport wordt gemaakt per artikelgroep (bijvoorbeeld audio) per kwartaal en bevat de verkopen per land. Het rapport wordt via een scherm aangevraagd. Op het scherm moet het kwartaal opgegeven worden waarover de rapportage wordt gevraagd. Alleen die landen waar werkelijk iets is verkocht van de desbetreffende artikelgroep worden afgedrukt. De totalen voor Europa, Azië en overige zijn de optellingen van de respectievelijke kolommen. Het percentage wordt berekend uit Aantal en Omzet. Hoeveel data-element-typen moeten geteld worden bij het vaststellen van de complexiteit van de uitvoerfunctie? Discussie De te tellen data-element-typen worden aangegeven door de cijfers tussen haakjes. De datum in kop is standaard, evenals "Rapport 1A", en wordt dus niet geteld. Het percentage wordt eenmaal geteld in de detailregel en nogmaals in de totaalregel per geografische eenheid omdat de logische verwerking verschilt. Iedere kolomtotaal wordt geteld. De variabele velden "audio", "lopende maand" en "Kwartaal" worden eveneens geteld. Daarnaast worden de op het scherm ingevoerde gegevens als data-element-typen meegeteld voor het bepalen van de complexiteit van de uitvoerfunctie (kwartaal) en de initiatietrigger. Oplossing In het totaal zijn er vijftien data-element-typen te onderscheiden. Verwijzingen Zie de richtlijnen 8.3.a, 8.3.b, 8.3.d en 8.3.f en paragraaf DEFINITIES en TELRICHTLIJNEN FPA 89

100 PRAKTIJKSITUATIES MET OPLOSSINGEN Gecombineerde uitvoerfuncties Het commerciële systeem van een bedrijf drukt op verzoek van de gebruiker een actielijst af waarop per afdeling de te behandelen of behandelde offerte-aanvragen staan met hun status: "Aanvraag in behandeling", "Lopende offerte", "Afgesloten contract" en "Gemiste opdracht". De weergegeven informatie beslaat altijd één week, teruggerekend vanaf de datum van aanvraag van de actielijst. In de praktijk kan een overzicht vele verschijningsvormen hebben. In dit voorbeeld worden vier varianten voor de actielijst gepresenteerd. De varianten voor de actielijsten zijn gerangschikt in toenemende mate van gebruiksvriendelijkheid. Actielijst A geeft in feite dezelfde informatie als actielijst D, maar actielijst A is veel minder gebruiksvriendelijk. De actielijsten B en C kunnen beschouwd worden als overzichten die wat betreft gebruiksvriendelijkheid tussen A en D in liggen. Hoeveel uitvoerfuncties moeten bij elk van de varianten A, B, C en D geteld worden? Deze vraag moet beantwoord worden voor de volgende situaties: 1. De acties zijn niet per status opvraagbaar. 2. De acties zijn per status opvraagbaar, en resulteren per status in één overzicht. Per variant (A, B, C en D) van de actielijst wordt voor elk van de situaties (1 en 2) de discussie en de oplossing gegeven Actielijst A Actielijst A bevat alle gegevenselementen van het hieronder weergegeven overzicht. Actielijst Afd. xxx 20/07/04 Blad 1 Betreft: Klant Verkoper Datum Aanvr. Datum Offreren Datum Offerte Datum contract Datum afloop Omzet Reden Gemist Aanvr. in xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx beh.... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx Lopende xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx offerte... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx Afgesl. xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx Contract... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx Gemiste xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx deal... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxx xxxxxxxx Situatie A.1 Discussie De acties zijn niet per status opvraagbaar Er is hier sprake van één overzicht. Onderzocht moet worden of er desondanks sprake is van meerdere uitvoerfuncties. Er kan pas sprake zijn van meerdere uitvoerfuncties als er sprake is 90 NESMA

101 PRAKTIJKSITUATIES MET OPLOSSINGEN van meerdere delen met een verschillende indeling. In dit geval is dat niet aan de orde, zodat er slechts één uitvoerfunctie geteld moet worden. Oplossing Tel één uitvoerfunctie. Situatie A.2 Discussie De acties zijn per status opvraagbaar en resulteren in één overzicht per status Er is sprake van vier overzichten. De vraag is nu of er sprake is van identieke functies. Er is sprake van identieke functies als de indeling van de overzichten gelijk is én er sprake is van dezelfde verwerking, waarbij het toepassen van hetzelfde selectiecriterium maar met een andere selectiewaarde niet als een andere verwerking gezien wordt. In deze situatie is er sprake van vier gelijke indelingen. Voor elk overzicht wordt het selectiecriterium "status van de actie" gebruikt, alleen wordt in de vier gevallen een andere waarde gehanteerd. Er moet dus slechts één uitvoerfunctie geteld worden voor de vier overzichten. Oplossing Tel één uitvoerfunctie Actielijst B Actielijst afd xxx Betreft: Klant Verkoper Datum Aanvr Datum Offreren Datum Offerte Datum Contract Datum Afloop Omzet Reden Gemist Aanvr.in xxxxx xxxxxx --/--/-- --/--/-- *) *) *) xxxxxxx *) beh.... xxxxx xxxxxx --/--/-- --/--/-- *) *) *) xxxxxxx *)... xxxxx xxxxxx --/--/-- --/--/-- *) *) *) xxxxxxx *) Lopende xxxxx xxxxxx --/--/-- --/--/-- *) *) *) xxxxxxx *) offerte... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- *) *) xxxxxxx *)... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- *) *) xxxxxxx *) Afgesl. xxxxx xxxxxx --/--/-- --/--/-- --/--/-- *) *) xxxxxxx *) contract... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxxx *)... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxxx *) Gemiste xxxxx xxxxxx --/--/-- --/--/-- --/--/-- --/--/-- --/--/-- xxxxxxx *) deal... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- *) *) xxxxxxx xxxxxxx... xxxxx xxxxxx --/--/-- --/--/-- --/--/-- *) *) xxxxxxx xxxxxxx xxxxx xxxxxx --/--/-- --/--/-- --/--/-- *) *) xxxxxxx xxxxxxx Actielijst B is bijna gelijk aan actielijst A. Bij deze actielijst worden in vergelijking met actielijst A de data-element-typen die geen waarde hebben, op grond van het feit dat bij een bepaalde status van de acties geen waarde in de interne logische gegevensverzameling kan voorkomen, niet afgedrukt. Dit is in het overzicht aangeduid met *). Er is alleen een optisch verschil t.o.v. actielijst A. Discussie Optisch lijkt het of er sprake is van meerdere delen met een verschillende indeling: per actiestatus lijkt er een verschillende indeling te onderkennen. Echter alle onderscheidbare delen DEFINITIES en TELRICHTLIJNEN FPA 91

102 PRAKTIJKSITUATIES MET OPLOSSINGEN bevatten dezelfde data-element-typen (de kolomkoppen zijn steeds hetzelfde), alleen wordt bij bepaalde data-element-typen geen waarde afgedrukt omdat ze bij een bepaalde status van de actie nog geen waarde hebben. Er is dan volgens de definitie van indeling toch sprake van dezelfde indeling. Er moet dus op dezelfde wijze als bij actielijst A geteld worden. Dit geldt zowel voor situatie B.1 als voor situatie B.2. Oplossing Tel zowel in situatie B.1 als in situatie B.2 één uitvoerfunctie Actielijst C Actielijst afd xxx Datum Datum Datum Datum Datum Reden Betreft: Klant Verkoper Aanvr. Offreren Offerte contract afloop Omzet Gemist Aanvr.in xxxxx xxxxxx --/--/-- --/--/-- *) *) *) xxxxxxx *) beh.... xxxxx xxxxxx --/--/-- --/--/-- *) *) *) xxxxxxx *)... xxxxx xxxxxx --/--/-- --/--/-- *) *) *) xxxxxxx *) Lopende xxxxx xxxxxx **) **) --/--/-- *) *) xxxxxxx *) offerte... xxxxx xxxxxx **) **) --/--/-- *) *) xxxxxxx *)... xxxxx xxxxxx **) **) --/--/-- *) *) xxxxxxx *) Afgesl. xxxxx xxxxxx **) **) **) --/--/-- --/--/-- xxxxxxx *) contract... xxxxx xxxxxx **) **) **) --/--/-- --/--/-- xxxxxxx *)... xxxxx xxxxxx **) **) **) --/--/-- --/--/-- xxxxxxx *) Gemiste xxxxx xxxxxx **) **) **) *) *) xxxxxxx xxxxxxxx deal... xxxxx xxxxxx **) **) **) *) *) xxxxxxx xxxxxxxx... xxxxx xxxxxx **) **) **) *) *) xxxxxxx xxxxxxxx Actielijst C (zie hierboven) is bijna identiek aan actielijst A. Bij actielijst C worden de dataelement-typen die nog geen waarde hebben, net als bij actielijst B, niet afgedrukt. Deze zijn in het overzicht aangeduid met *). Daarnaast worden waarden die op grond van de status van de actie niet meer relevant zijn niet afgedrukt. Deze velden zijn aangeduid met **). Discussie Opnieuw is er volgens de definitie van indeling geen sprake van verschillende indelingen omdat bij elk deel alle data-element-typen voorkomen, alleen wordt bij bepaalde data-element-typen geen waarde afgedrukt omdat de waarde niet meer relevant is of omdat er nog geen waarde voorkomt in de interne logische gegevensverzamelingen. Tel dus ook in deze situatie als bij actielijst A. Oplossing Tel zowel in situatie C.1 als in situatie C.2 één uitvoerfunctie. 92 NESMA

103 PRAKTIJKSITUATIES MET OPLOSSINGEN Actielijst D Actielijst afd xxx Aanvragen in behandeling Klant Verkoper Datum Aanvr. Datum Offreren Omzet xxxxxx xxxxxx --/--/-- --/--/-- xxxxxx xxxxxx xxxxxx --/--/-- --/--/-- xxxxxx xxxxxx xxxxxx --/--/-- --/--/-- xxxxxx Lopende offertes: Klant Verkoper Datum Offerte Omzet xxxxxx xxxxxx --/--/-- xxxxxx xxxxxx xxxxxx --/--/-- xxxxxx xxxxxx xxxxxx --/--/-- xxxxxx Afgesloten contracten: Klant Verkoper Datum contract Datum afloop Omzet xxxxxx xxxxxx --/--/-- --/--/-- xxxxxx xxxxxx xxxxxx --/--/-- --/--/-- xxxxxx xxxxxx xxxxxx --/--/-- --/--/-- xxxxxx Gemiste deals: Klant Verkoper Reden gemist Omzet xxxxxx xxxxxx xxxxxxxxxxxxx xxxxxx xxxxxx xxxxxx xxxxxxxxxxxxx xxxxxx xxxxxx xxxxxx xxxxxxxxxxxxx xxxxxx Actielijst D bevat precies dezelfde informatie als actielijst C, maar ziet er wat indeling betreft anders uit. Situatie D.1 Discussie De acties zijn niet per status opvraagbaar Er is hier sprake van één overzicht. Onderzocht moet worden of er desondanks sprake is van meerdere uitvoerfuncties. Er kan pas sprake zijn van meerdere uitvoerfuncties als er sprake is van meerdere delen met een verschillende indeling. In dit geval is er inderdaad sprake van vier afzonderlijke indelingen, omdat de delen elk bestaan uit een andere verzameling van dataelement-typen (de data-element-typen die geen waarde hebben of niet relevant zijn komen in actielijst D niet meer voor). Er kan dus sprake zijn van vier uitvoerfuncties, maar dan moeten (volgens de telrichtlijnen) de delen afzonderlijk opvraagbaar zijn of via afzonderlijke logische verwerkingen tot stand komen. De delen zijn hier niet afzonderlijk opvraagbaar. Volgens de telrichtlijnen is er geen sprake van afzonderlijke logische verwerkingen omdat alle delen over "acties" rapporteren en op grond van dezelfde interne logische gegevensverzamelingen tot stand komen. Tel dus één uitvoerfunctie. Oplossing Tel één uitvoerfunctie. Situatie D.2 Discussie De acties zijn per status opvraagbaar en resulteren per status in één overzicht Er is nu sprake van vier overzichten. De vraag is of er sprake is van identieke functies. Er is sprake van identieke functies als de indeling én de verwerking gelijk zijn, waarbij het toepassen van hetzelfde selectiecriterium maar met een andere selectiewaarde niet als een andere DEFINITIES en TELRICHTLIJNEN FPA 93

104 PRAKTIJKSITUATIES MET OPLOSSINGEN verwerking gezien wordt. In deze situatie is er, om dezelfde redenen als genoemd bij situatie D.1, sprake van vier verschillende indelingen. Er moeten dus vier uitvoerfuncties geteld worden. Oplossing Tel vier uitvoerfuncties. Verwijzingen Zie de paragrafen 4.7 en 8.1 en richtlijn 8.2.g Combinatie-effecten bij functies Eén combinatiemogelijkheid Probleembeschrijving De gebruiker heeft een scherm waarmee verzekeringspremies kunnen worden berekend en afgedrukt. Daarbij zijn er de volgende opties: 1. premieberekening voor een Man 2. premieberekening voor een Vrouw. De gebruiker kan één van deze opties aankruisen, of beide tegelijk. Het overzicht voor een Man heeft een andere indeling en/of verwerking dan voor een Vrouw. Daarnaast geldt dat als beide opties zijn aangekruist, de overzichten van Man en Vrouw achtereenvolgend worden afgedrukt, afgesloten met een totaalregel, een "groepskorting" en een eindbedragregel. Hoeveel uitvoerfuncties moeten in dit geval geteld worden? Discussie De functies premieberekening voor een Man en premieberekening voor een Vrouw zijn elk unieke functies en tellen elk voor een uitvoerfunctie. Het zijn geen opvragingsfuncties, omdat er berekeningen plaatsvinden. Omdat het combinatie-overzicht meer is dan de som der delen, wordt hiervoor een extra uitvoerfunctie geteld. Oplossing Tel de volgende uitvoerfuncties: twee uitvoerfuncties voor de unieke keuzen Man en Vrouw; één uitvoerfunctie voor het combinatie-overzicht. 94 NESMA

105 PRAKTIJKSITUATIES MET OPLOSSINGEN Verwijzingen Zie de richtlijn 8.2.s Meerdere combinatiemogelijkheden Probleembeschrijving De gebruiker heeft een scherm waarmee verzekeringspremies kunnen worden berekend en afgedrukt. Daarbij zijn er de volgende opties: 1. premieberekening voor een Man 2. premieberekening voor een Vrouw 3. premieberekening voor een Kind. De gebruiker kan één, twee of drie van deze opties aankruisen. De overzichten voor een Man, een Vrouw en een Kind hebben elk een andere indeling en/of verwerking. Bij elke combinatie worden weer de samenstellende overzichten achtereenvolgend afgedrukt, afgesloten met een totaalregel, groepskorting, en een eindbedragregel. Hoeveel uitvoerfuncties moeten in dit geval geteld worden. Discussie De gebruiker kan nu de volgende (al dan niet combinatie-) functies uitvoeren: Man, Vrouw, Kind, Man+Vrouw, Man+Kind, Vrouw+Kind, Man+Vrouw+Kind. De overzichten voor Man, Vrouw en Kind zijn elk afzonderlijk unieke uitvoerfuncties. Bij alle combinaties geldt verder dat er meer informatie beschikbaar wordt gesteld dan de som van de afzonderlijke delen. De extra informatie komt echter bij elke combinatie volgens gelijksoortige logische verwerkingen tot stand (er is geen sprake van verschillende soorten combinatieeffecten). Voor de combinaties wordt daarom in totaal één extra uitvoerfunctie geteld. NB. Oplossing Als de verwerking voor bijvoorbeeld de combinatie Man+Vrouw+Kind andersoortig zou zijn geweest dan bij de overige combinaties, dan zouden twee extra uitvoerfuncties geteld zijn voor de combinatieoverzichten (zie richtlijn 8.2.s). Het aantal uitvoerfuncties is: drie uitvoerfuncties voor de unieke keuzen Man, Vrouw, Kind; één uitvoerfunctie in totaal voor de combinaties. Verwijzingen Zie de richtlijn 8.2.s. DEFINITIES en TELRICHTLIJNEN FPA 95

106 PRAKTIJKSITUATIES MET OPLOSSINGEN Raadplegen op basis van meerdere zoekargumenten In dit voorbeeld worden twee situaties behandeld waarin er sprake is van de mogelijkheid om met verschillende criteria gegevens op te vragen Combinatie van unieke en niet-unieke zoekcriteria Probleembeschrijving Wanneer in deze functie "Raadplegen klanten" het unieke klantnummer wordt opgegeven, verschijnen de gegevens van de betreffende klant op het scherm. De knoppen Volgende en Vorige zijn dan niet actief. Indien een klantnaam (of gedeelte van de klantnaam) wordt opgegeven, worden alle klanten met die naam opgehaald. Alleen de eerste klant met deze naam wordt op het scherm getoond. Wanneer ook nog de woonplaats wordt opgegeven, worden alleen de klanten die in de betreffende woonplaats gevestigd zijn, geselecteerd. Wordt alleen de woonplaats opgegeven dan worden alle klanten uit die woonplaats geselecteerd. Als er in deze gevallen meer dan een klant wordt gevonden, kan men met de knoppen vooruiten terugbladeren door de geselecteerde klanten. Hoeveel en wat voor type(n) functies moeten worden geteld? 96 NESMA

107 PRAKTIJKSITUATIES MET OPLOSSINGEN Discussie In dit geval heeft de gebruiker de mogelijkheid óf het klantnummer in te voeren, óf de klantnaam al dan niet in combinatie met de woonplaats, óf de woonplaats. Er is dus sprake van twee elkaar uitsluitende selecties (op klantnummer resp. klantnaam/woonplaats). De twee elkaar uitsluitende selecties worden elk als een afzonderlijke functie beoordeeld. Het raadplegen op klantnummer is een opvragingsfunctie. De uitvoer is in omvang volledig bepaald, namelijk alle gegevens van de betreffende klant. Het invoergedeelte bestaat uit één data-element-type namelijk het klantnummer. Het uitvoergedeelte uit zes data-element-typen (klantnummer, klantnaam, adres, postcode, woonplaats en datum bestelling). Het raadplegen op klantnaam (of deel van een klantnaam) en/of woonplaats is een uitvoerfunctie. De uitvoer is in omvang variabel, omdat op voorhand niet bekend is hoeveel klanten er geselecteerd worden. Omdat in dit geval de gebruiker meer opties heeft waarbij de selecties elkaar niet wederzijds uitsluiten (dat wil zeggen: een "en/of-situatie"), is er sprake van slechts één uitvoerfunctie. Het aantal data-element-typen voor het vaststellen van de complexiteit is acht (klantnummer, klantnaam tweemaal, adres, postcode, woonplaats tweemaal, datum bestelling). De knop Zoeken (inclusief eventuele voorafgaande keuzen in afrolmenu s) telt voor beide functies mee als data-element-type. De functietoetsen worden gebruikt om door de uitvoer te navigeren en worden daarom niet als extra functies of als data-element-typen geteld. Oplossing Tel één opvragingsfunctie voor het raadplegen op klantnummer. Voor de complexiteit moet het invoergedeelte en uitvoergedeelte afzonderlijk beoordeeld worden. Het invoergedeelte kent twee data-element-typen (Klantnummer en de activeringsknop Zoeken) en één geraakte gegevensverzameling en is daarmee Eenvoudig. Het uitvoergedeelte kent zes dataelementtypen plus de foutboodschap en één geraakte gegevensverzameling en is daarmee Eenvoudig. De opvragingsfunctie is daarmee ook Eenvoudig. Tel één uitvoerfunctie met negen (acht plus activeringsknop Zoeken) data-element-typen voor het raadplegen op klantnaam en/of woonplaats. Verwijzingen Zie de richtlijnen 8.2.a, 8.2.c, 8.2.q, 8.3.a, 8.3.b, 8.3.g en 9.2.h en paragraaf Combinatie van niet-unieke zoekcriteria Probleembeschrijving De gebruiker kan óf via de klantnaam óf via de besteldatum gegevens van een klant raadplegen. Met behulp van de knoppen Volgende en Vorige kan naar een volgende of een vorige klant die aan het selectiecriterium voldoet gesprongen worden. Van hoeveel uitvoer- en/of opvragingsfuncties is hier sprake? DEFINITIES en TELRICHTLIJNEN FPA 97

108 PRAKTIJKSITUATIES MET OPLOSSINGEN Discussie De uitvoer voor het raadplegen op naam is variabel. Op voorhand is niet bekend hoeveel klanten er geselecteerd worden. De omvang van de uitvoer voor het raadplegen op besteldatum is eveneens variabel en kan niet voorspeld worden. Er is een verschil in logische verwerking voor beide raadplegingen. Omdat de gebruiker moet kiezen tussen het raadplegen op naam of het raadplegen op besteldatum (een combinatie is niet mogelijk), moeten twee afzonderlijke uitvoerfuncties geteld worden. De knop Zoeken (inclusief eventuele voorafgaande keuzen in afrolmenu s) telt voor beide functies mee als data-element-type. De knoppen Volgende en Vorige worden gebruikt om door de uitvoer te navigeren en worden daarom niet als extra functies of als data-element-typen meegeteld. Oplossing Tel één uitvoerfunctie met acht data-element-typen (klantnummer, klantnaam (tweemaal), adres, postcode, woonplaats en datum bestelling plus de activeringsknop) voor het raadplegen op naam. 98 NESMA

109 PRAKTIJKSITUATIES MET OPLOSSINGEN Tel één uitvoerfunctie met eveneens acht data-element-typen voor het raadplegen via besteldatum. Verwijzingen Zie de richtlijnen 8.2.a, 8.2.c, 8.2.q, 8.3.a, 8.3.b en 8.3.g Schermen met lijstfunctie Probleembeschrijving Bij het invoeren van productgegevens kunnen door gebruik te maken van drop-down-list-boxen in de velden leverancier, kleurcode en materiaalcode alle geldige codes of nummers van het desbetreffende veld op het scherm getoond worden met daarbij de omschrijving. Vanuit dit overzicht kan een code of een nummer gekozen worden; deze wordt vervolgens gekopieerd naar het invoerveld. De kleuromschrijving wordt gehaald uit een FPA-tabel met als attributen: kleurcode en kleuromschrijving. Materiaalomschrijving en leveranciersnaam komen uit twee gegevensverzamelingen waarin allerlei gegevens omtrent het materiaal respectievelijk de leverancier zijn opgeslagen. Moeten dit soort ondersteunende functies geteld worden en zo ja op welke manier? Discussie Tel verschillende lijstfuncties van het informatiesysteem in principe als afzonderlijke uitvoerfuncties. Het zijn uitvoerfuncties omdat de uitvoer in omvang variabel is. Het zijn afzonderlijke functies omdat (in dit voorbeeld) de indeling van de lijstfunctie die materiaalcodes laat zien een andere is dan die van de lijstfunctie die de mogelijke leveranciers met hun codes geeft (de lijstfunctie bestaat uit andere data-element-typen respectievelijk geeft informatie uit een andere logische gegevensverzameling). Hoewel hetzelfde geldt voor de lijstfunctie met kleurcodes, wordt deze functie niet als aparte uitvoerfunctie geteld omdat deze lijstfunctie betrekking heeft op een FPA-tabel. Voor de FPAtabellen-ILGV wordt voor de toepassing als geheel eenmalig één uitvoerfunctie geteld. Het kopiëren naar het invoerveld wordt niet als aparte functie geteld. DEFINITIES en TELRICHTLIJNEN FPA 99

110 PRAKTIJKSITUATIES MET OPLOSSINGEN Oplossing Tel in dit voorbeeld de lijstfunctie voor leverancier en materiaal elk als één uitvoerfunctie, mits de functie niet al op een andere plaats geteld is. Tel daarnaast een invoerfunctie voor het vastleggen van de producten. Tel geen aparte uitvoerfunctie voor de lijstfunctie met kleurcodes. Verwijzingen Zie de richtlijnen 5.2.k, 8.2.a en 8.2.t en de paragrafen 4.16 en Bladeren en scrollfuncties Blader- en scrollfuncties komen in de praktijk in vele vormen voor. Binnen FPA wordt er naar gestreefd om vormen die weliswaar op verschillende wijze gerealiseerd zijn, maar functioneel hetzelfde bieden, op dezelfde wijze te tellen. In dit voorbeeld wordt daarom op een groot aantal verschillende situaties ingegaan en wordt aangegeven hoe deze situaties geteld moeten worden Selectie via uniek identificerende gegevens Probleembeschrijving Bij de functie "Tonen klantgegevens" wordt het unieke klantnummer ingevoerd. Vervolgens kunnen zich de onderstaande situaties voordoen: 1. De gegevens van de betreffende klant worden getoond. Er is geen mogelijkheid om met behulp van functietoetsen gegevens van een andere klant op te vragen. 2. De gegevens van de betreffende klant worden getoond, waarna met behulp van functietoetsen de gegevens van de volgende of de vorige klant opgevraagd kunnen worden. 3. Op een overzichtsscherm worden de kerngegevens getoond (één regel per klant) van alle klanten vanaf het ingevoerde nummer waarbij er gebladerd kan worden als er meer klanten zijn dan op het overzichtsscherm weergegeven kunnen worden. 4. Op een overzichtsscherm worden de kerngegevens getoond (één regel per klant) van alle klanten vanaf het ingevoerde nummer waarbij er gebladerd kan worden als er meer klanten zijn dan op het overzichtsscherm weergegeven kunnen worden. Na selectie van één van de klanten worden de gegevens van die klant getoond. 5. De gegevens van de betreffende klant worden getoond. Met behulp van een functietoets kan vervolgens een overzicht (op scherm) gevraagd worden van de kerngegevens (één regel per klant) van alle klanten vanaf de klant die op het detailscherm werd getoond, waarbij er gebladerd kan worden als er meer klanten zijn dan op het overzichtsscherm weergegeven kunnen worden. Op het overzichtsscherm kan vervolgens weer een klant geselecteerd worden, waarna de gegevens van die klant op het detailscherm getoond worden. 6. Op een overzichtsscherm worden de kerngegevens getoond (één regel per klant) van alle klanten vanaf het ingevoerde nummer, waarbij er gebladerd kan worden als er meer klanten zijn dan op het overzichtsscherm weergegeven kunnen worden. Na selectie van één van de klanten worden de gegevens van die klant getoond, waarna met behulp van functietoetsen de gegevens van de volgende of de vorige klant opgevraagd kunnen worden. 100 NESMA

111 PRAKTIJKSITUATIES MET OPLOSSINGEN Welke uitvoer- en/of opvragingsfuncties moeten in elk van de bovenstaande situaties onderkend worden? Discussie Situatie één is een zuivere vorm van een opvragingsfunctie. De klant is uniek bepaald door het klantnummer. Er is maar één klant die daaraan voldoet. Er is geen bladermogelijkheid. In situatie twee lijkt er ook sprake van een opvragingsfunctie. In werkelijkheid is de functie echter een functie waarbij door alle klanten gebladerd kan worden, waarbij er alleen een startpunt gedefinieerd is. De gehele verzameling klanten wordt aangeboden. Het aantal is variabel. Er is hier dus sprake van een uitvoerfunctie. In situatie drie is er ook sprake van een uitvoerfunctie. Ook hier is een startpunt gedefinieerd. Er worden meerdere klanten getoond en het is niet bekend hoeveel klanten er nog volgen vanaf het startpunt. Er moet dus een uitvoerfunctie onderkend worden. Hierbij doet het niet terzake of er met behulp van een functietoets nog verder gebladerd kan worden als er meer klanten zijn dan op het scherm getoond kunnen worden. Bladeren binnen dezelfde verzameling is geen aparte functie, maar is onderdeel van de uitvoerfunctie. Het enige verschil tussen situatie 3 en situatie 2 is dat in situatie 2 alle gegevens van een klant getoond worden, terwijl dat in situatie 3 alleen de kerngegevens zijn. In situatie vier worden in feite twee functies geboden. Net als in situatie drie is het overzichtsscherm een uitvoerfunctie. Het tonen van de gegevens van een specifieke klant op het detailscherm is een andere functionaliteit: er is sprake van een andere verzameling van data-element-typen (op het overzichtsscherm is alleen sprake van de kerngegevens van klanten, terwijl op het detailscherm alle gegevens van een klant getoond worden). Bovendien kan de functie optioneel worden aangeroepen. De functie zou ook los kunnen bestaan. Ook deze functie is dus een elementaire functie. Daarom wordt het tonen van de detailgegevens als een aparte functie geteld. Het is een opvragingsfunctie omdat er op het detailscherm niet kan worden gebladerd. Er is sprake van één uitvoerfunctie en één opvragingsfunctie. Situatie vijf is functioneel gezien dezelfde als situatie vier, waarbij alleen de schermen in een andere volgorde staan. De volgorde van de schermen is voor FPA niet van belang. Dezelfde functies als bij situatie vier worden hier onderkend. In situatie zes worden, net als in situatie vier, twee functies geboden. Het overzichtsscherm is opnieuw een uitvoerfunctie. Het tonen van de gegevens van een specifieke klant op het detailscherm is een andere functionaliteit: er is sprake van een andere verzameling van data-element-typen (op het overzichtsscherm is alleen sprake van de kerngegevens van klanten, terwijl op het detailscherm alle gegevens van een klant getoond worden). Bovendien kan de functie optioneel worden aangeroepen. De functie zou ook los kunnen bestaan. Ook deze functie is dus een elementaire functie. Daarom wordt het tonen van de detailgegevens als een aparte functie geteld. Er kan nu echter wel op het detailscherm gebladerd worden, de functie biedt dezelfde functionaliteit als in situatie twee. Daarom is sprake van een uitvoerfunctie. In totaal is dus sprake van twee uitvoerfuncties. Oplossing Onderken de volgende functies: Situatie 1: één opvragingsfunctie Situatie 2: één uitvoerfunctie Situatie 3: één uitvoerfunctie DEFINITIES en TELRICHTLIJNEN FPA 101

112 PRAKTIJKSITUATIES MET OPLOSSINGEN Situatie 4: Situatie 5: Situatie 6: Verwijzingen één uitvoerfunctie en één opvragingsfunctie één uitvoerfunctie en één opvragingsfunctie twee uitvoerfuncties Zie paragraaf 4.17 en de richtlijnen 8.2.a, 8.2.c, 8.2.u, 9.2.c, 9.2.f, 9.2.g, 9.2.h en 9.2.j Selectie via niet uniek identificerende gegevens, gevolgd door bladeren Probleembeschrijving Bij de functie "Tonen klantgegevens" wordt via het ingeven van een uniek vertegenwoordigernummer de eerste klant van de desbetreffende vertegenwoordiger getoond. Met behulp van functietoetsen kan de gebruiker naar een vorige of een volgende klant van dezelfde vertegenwoordiger bladeren. Is hier sprake van één of meerdere opvragingsfuncties en/of van één of meerdere uitvoerfuncties? Discussie Bij het invoeren van een uniek vertegenwoordigernummer is het niet bekend hoeveel klanten deze vertegenwoordiger heeft. De uitvoer is dus in omvang variabel en moet daarom als één uitvoerfunctie geteld worden. De bladerfunctie is onderdeel van de uitvoerfunctie en de functietoetsen gebruikt voor het bladeren worden niet als extra functie of als data-element-typen meegeteld. Oplossing Tel één uitvoerfunctie. Verwijzingen Zie paragraaf 4.17 de richtlijnen 8.2.a, 8.2.c, 8.2.u, 8.3.g en 9.2.j Selectie via uniek identificerende gegevens, gevolgd door bladeren na een andere selectie Probleembeschrijving Bij het raadplegen van klanten op een uniek klantnummer kan een vorige of een volgende klant van dezelfde vertegenwoordiger opgevraagd worden met behulp van functietoetsen. Is hier sprake van één of meerdere opvragingsfuncties en/of van één of meer uitvoerfuncties? Discussie Bij het raadplegen op klantnummer wordt de uitvoer uniek bepaald door dat klantnummer en is niet in omvang variabel. Dit is een opvragingsfunctie. Bij het opvragen van de volgende of de vorige klant van dezelfde vertegenwoordiger met behulp van functietoetsen worden het klantnummer van de getoonde klant en het vertegenwoordigernummer als zoekargumenten gebruikt. Een andere logische verwerking is dus noodzakelijk. Hoewel de specifiek getoonde klant uniek bepaald is, is er nu sprake van het bladeren door de verzameling klanten van één vertegenwoordiger. De omvang van deze verzameling is variabel. Er is daarom sprake van een uitvoerfunctie. 102 NESMA

113 PRAKTIJKSITUATIES MET OPLOSSINGEN Oplossing Tel één opvragingsfunctie en één uitvoerfunctie. Verwijzingen Zie paragraaf 4.17 en de richtlijn 8.2.a, 8.2.c, 8.2.u, 9.2.c, 9.2.f, 9.2.g, 9.2.h en 9.2.j Selectieschermen bij wijzigen met behulp van zoekargument In dit voorbeeld wordt een wijzigingsfunctie behandeld waarvan het doel in feite tweeërlei is: in de eerste plaats moeten gegevens van een klant gewijzigd kunnen worden, maar voordat dit plaatsvindt wil de gebruiker de klant op een gebruiksvriendelijke manier kunnen selecteren. Dit kan op verschillende wijzen functioneel worden gerealiseerd. In dit voorbeeld worden twee verschillende implementaties van deze functionaliteit behandeld en wordt aangegeven hoe in beide situaties geteld dient te worden Selectie via een apart selectiescherm Probleembeschrijving De gebruiker heeft via een menukeuze aangegeven, dat hij klantgegevens wil wijzigen. Vervolgens presenteert het systeem het volgende window, waarop de gebruiker een uniek klantnummer of een klantnaam (of een gedeelte van een klantnaam) moet opgeven (maar niet beide). Wanneer het unieke klantnummer wordt opgegeven verschijnt het window Wijzigen klant met de gegevens van de betreffende klant. Wanneer een klantnaam (of een gedeelte van een klantnaam) wordt opgegeven, worden alle klanten met die naam opgehaald. Indien er slechts één klant gevonden wordt, dan verschijnt direct hetzelfde window Wijzigen klant met de gegevens van de betreffende klant. DEFINITIES en TELRICHTLIJNEN FPA 103

114 PRAKTIJKSITUATIES MET OPLOSSINGEN Als er meerdere klanten gevonden worden, dan verschijnt het window Selecteren klant met de gevonden klanten. Eventueel verschijnt er een verticale scrollbar om de hele lijst met klanten te kunnen bekijken. Na het via de muis markeren van de gewenste klant en het bevestigen hiervan met de knop Selecteren verschijnen het window Wijzigen klant met de detailgegevens van de klant. Vervolgens kunnen de klantgegevens gewijzigd worden. Vormt de selectiemogelijkheid een onderdeel van de mogelijkheid tot wijzigen, of is het een aparte functie? Is het aangeven van de gewenste klant een aparte invoerfunctie? Is het tonen van de klantgegevens een aparte opvragingsfunctie? Levert de verticale scrollbar een extra functie op? Hoeveel functies moeten er in totaal geteld worden? 104 NESMA

115 PRAKTIJKSITUATIES MET OPLOSSINGEN Discussie In de situatie waarbij via een klantnummer het window Wijzigen klant met de betreffende klantgegevens getoond wordt waarna de wijziging plaats kan vinden, is sprake van het tonen van de te wijzigen gegevens als onderdeel van de invoerfunctie "Wijzigen klant". Het tonen van de gegevens wordt niet als een afzonderlijke opvragingsfunctie geteld. De situatie dat na het invoeren van een niet unieke klantnaam klantgegevens van die klanten die aan het selectiecriterium voldoen, getoond worden in het window Selecteren klant, waarna de te wijzigen klant hieruit gekozen kan worden, moet als volgt worden geteld. Het zoeken van de klant met behulp van de klantnaam leidt tot een in omvang variabel aantal geselecteerde klanten, die alle getoond worden op in het window Selecteren klant. De gewenste klant kan vervolgens geselecteerd worden. Het tonen van de geselecteerde klanten op een apart scherm wordt gezien als extra functionaliteit die geboden wordt. Omdat de indeling van dit overzicht anders is, wordt hiervoor een extra functie geteld. Omdat de uitvoer in omvang variabel is, dient hiervoor één uitvoerfunctie geteld te worden. Bij toeval kan de selectie via klantnaam leiden tot één klant, waarna het selectie-window niet getoond wordt. Dit is een optimalisatie waarbij de gebruiker direct de detailgegevens in het wijzigingswindow getoond worden en niet eerst het selectie-window waarbij er in dit geval immers slechts "gekozen" zou kunnen worden uit één klant. Deze situatie resulteert niet in een extra uitvoer- of opvragingsfunctie. Na selectie van de gewenste klant toont het wijzigings-window alle gegevens van die klant en kan men de wijziging aanbrengen. Het tonen van de gegevens van de geselecteerde klant in dit window wordt (net als bij de selectie via het klantnummer) gezien als onderdeel van de wijzigingsfunctie en is geen afzonderlijke opvragingsfunctie. Het aangeven van de geselecteerde klant via de muis en de knop Selecteren leidt niet tot een aparte invoerfunctie. De verticale scrollbar dient voor het navigeren door de uitvoer en wordt niet meegeteld. De wijzigingsfunctie is in beide gevallen dezelfde, en wordt daarom als één invoerfunctie geteld. Oplossing Tel één invoerfunctie voor de wijzigingsfunctie. Tel één uitvoerfunctie voor het tonen van de klanten die aan het selectiecriterium voldoen. Verwijzingen Zie de paragrafen 4.16 en 4.17 en de richtlijnen 7.2.a, 7.2.n, 7.2.x, 7.3.d, 8.2.a, 8.2.c, 8.2.q, 8.2.u, 8.3.a, 8.3.b en 9.2.j Selectie via het wijzigingsscherm Probleembeschrijving De gebruiker heeft via een menukeuze aangegeven, dat hij klantgegevens wil wijzigen. Vervolgens presenteert het systeem het volgende window, waarop de gebruiker een uniek klantnummer of een klantnaam (of een gedeelte van een klantnaam) moet opgeven (maar niet beide). De wijzigingsfunctie heeft nu het onderstaande afwikkeling. DEFINITIES en TELRICHTLIJNEN FPA 105

116 PRAKTIJKSITUATIES MET OPLOSSINGEN Na het invoeren van één van beide selectiecriteria, verschijnen de gegevens van de (eerste) klant die aan het criterium voldoet in het window Wijzigen klant. Indien als selectiecriterium Klantnummer gebruikt is, voldoet hooguit één klant aan het criterium. De knoppen Volgende en Vorige zijn dan niet actief. Indien als selectiecriterium Klantnaam is gebruikt, kan er een aantal klanten aan het criterium voldoen. De gebruiker krijgt nu niet zoals in het vorige voorbeeld een apart window om een klant te selecteren, maar kan nu met de knoppen Volgende en Vorige door de geselecteerde klanten bladeren totdat de gewenste klant gevonden is. Worden bij deze invoerfunctie (het wijzigen van klantgegevens) uitvoerfuncties of opvragingsfuncties geteld? Hoeveel functies moeten er in totaal worden geteld? 106 NESMA

117 PRAKTIJKSITUATIES MET OPLOSSINGEN Discussie In de situatie waarbij via een klantnummer (ingevoerd in het eerste window) de juiste klantgegevens in het window Wijzigen klant getoond worden waarna de wijziging plaats kan vinden, is sprake van het tonen van de te wijzigen gegevens als onderdeel van de invoerfunctie "Wijzigen klant". Het tonen van de gegevens wordt niet als een afzonderlijke opvragingsfunctie geteld. De situatie dat na het invoeren van een niet unieke klantnaam door de klanten die aan het selectiecriterium voldoen gebladerd kan worden tot de juiste klant gevonden is, waarna deze gewijzigd kan worden, moet als volgt worden geteld. Het zoeken van de klant met behulp van de klantnaam leidt tot een in omvang variabel aantal geselecteerde klanten, die alle getoond kunnen worden in het window Wijzigen klant met behulp van de knoppen Volgende en Vorige. De gewenste klant kan vervolgens gewijzigd worden. Het tonen van de geselecteerde klanten wordt gezien als extra functionaliteit die geboden wordt. Omdat de geboden functionaliteit in feite gelijk is aan die van het vorige voorbeeld (waarin de geselecteerde klanten op een overzichtsscherm werden gepresenteerd) en omdat het tonen van en kunnen bladeren door de geselecteerde klanten een andere logische verwerking is dan het uitsluitend presenteren en wijzigen van de gepresenteerde gegevens, wordt hiervoor een extra functie geteld. Omdat de uitvoer in omvang variabel is, dient hiervoor één uitvoerfunctie geteld te worden. Bij toeval kan de selectie via klantnaam leiden tot één klant, waarna de knoppen voor het bladeren niet actief zijn. Dit wordt beschouwd als een situatie die onderdeel is van de uitvoerfunctie die geteld wordt voor het selecteren. Deze situatie resulteert niet in een extra uitvoer- of opvragingsfunctie. De wijzigingsfunctie is in beide gevallen dezelfde, en wordt daarom als één invoerfunctie geteld. Oplossing Tel één invoerfunctie voor de wijzigingsfunctie. Tel één uitvoerfunctie voor het kunnen bladeren door de klanten die aan het selectiecriterium voldoen. Verwijzingen Zie paragraaf 4.17 en de richtlijnen 7.2.a, 7.2.n, 7.2.x, 7.3.d, 8.2.a, 8.2.c, 8.2.q, 8.2.u, 8.3.a, 8.3.b en 9.2.j Directe en uitgestelde verwerking Probleembeschrijving Een informatiesysteem biedt functionaliteit voor het bijwerken van de verzekeringsgroep bij verzekerden op basis van een regionale indeling (denk bijvoorbeeld aan een diefstalverzekering met premies per regio). De gebruiker kan via een scherm aan een postcodereeks een andere verzekeringsgroep toekennen. In dit voorbeeld worden drie functioneel verschillende situaties behandeld, waarbij in elke situatie wordt aangegeven hoe er geteld moet worden. In de eerste situatie vindt de aanpassing direct plaats nadat een postcodereeks ingegeven is. Vervolgens kan een nieuwe reeks ingegeven worden. Als de gebruiker de functie afsluit en er zijn één of meer verzekeringsgroepen aangepast, dan wordt een overzicht van de mutaties afgedrukt voor controle-doeleinden. In de tweede situatie kan de gebruiker één of meer postcodereeksen ingegeven. De verwerking van de gegevens vindt 's nachts plaats. Als 's nachts de verzekeringsgroepen zijn aangepast, DEFINITIES en TELRICHTLIJNEN FPA 107

118 PRAKTIJKSITUATIES MET OPLOSSINGEN dan wordt een overzicht van de mutaties afgedrukt voor controle-doeleinden. De eenmaal ingegeven postcodereeksen kunnen niet meer onderhouden worden. In de derde situatie kan de gebruiker ook één of meer postcodereeksen ingegeven en worden de gegevens 's nachts verwerkt, waarna een overzicht van de mutaties wordt afgedrukt voor controle- doeleinden. De ingegeven postcodereeksen kunnen nu echter na het invoeren en vóór de nachtelijke verwerking nog worden gewijzigd of verwijderd. Bepaal per situatie welke functies geteld moeten worden. Telt in situatie 2 en/of 3 het transactiebestand met postcodereeksen als een interne logische gegevensverzameling? Situatie 1: Directe verwerking Discussie Het hoofddoel van deze functie is het aanpassen van de verzekeringsgroepen. De gegevens die vastgelegd worden, zijn functioneel permanente gegevens. Om die reden is er sprake van een invoerfunctie. Onlosmakelijk aan de functie is het aanmaken van het mutatieverslag verbonden. Het mutatieverslag vervult een functionele eis: het is namelijk nodig voor controle-doeleinden. Bovendien passeert het de grens van de toepassing. Om deze redenen wordt voor het mutatieverslag een uitvoerfunctie geteld, hoewel de functie onlosmakelijk met de invoerfunctie verbonden is. Oplossing Tel de volgende functies: één invoerfunctie voor het invoeren en aanpassen van de verzekeringsgroepen; één uitvoerfunctie voor het mutatieverslag. Verwijzingen Zie de richtlijnen 7.2.r en 8.2.p Situatie 2: Uitgestelde verwerking Discussie Het hoofddoel van deze functie is het aanpassen van de verzekeringsgroepen. De gegevens die vastgelegd worden, zijn functioneel permanente gegevens. Om die reden is er sprake van minimaal één invoerfunctie. Het invoeren van de postcodereeksen en het pas 's nachts verwerken wordt vanuit FPA beschouwd als een uitgestelde verwerking. De nachtelijke verwerking wordt vanuit FPA gezien als één geheel met het invoeren van de postcodereeksen. De tijdelijk opgeslagen postcodereeksen zijn niet onderhoudbaar en niet permanent, omdat de gegevens na te zijn verwerkt in de nachtelijke verwerking niet meer blijven bestaan, met andere woorden: de gegevens zijn verbruikt. Ze vormen dus een tussenbestand dat niet als een interne logische gegevensverzameling beschouwd kan worden. Onlosmakelijk aan de nachtelijke verwerking is het aanmaken van het mutatieverslag verbonden. Het mutatieverslag vervult een functionele eis: het is namelijk nodig voor controledoeleinden. Bovendien passeert het de grens van de toepassing. Om deze redenen wordt voor het mutatieverslag een uitvoerfunctie geteld, hoewel de functie onlosmakelijk met de invoerfunctie verbonden is. Oplossing Tel de volgende functies: 108 NESMA

119 PRAKTIJKSITUATIES MET OPLOSSINGEN één invoerfunctie voor het invoeren en 's nachts aanpassen van de verzekeringsgroepen; één uitvoerfunctie voor het mutatieverslag. Verwijzingen Zie de richtlijnen 5.2.f, 7.2.r en 8.2.p Situatie 3: Uitgestelde verwerking en onderhoud Discussie Het hoofddoel van deze functie is het aanpassen van de verzekeringsgroepen. De gegevens die vastgelegd worden, zijn functioneel permanente gegevens. Om die reden is er sprake van minimaal één invoerfunctie. Het invoeren van de postcodereeksen en het pas 's nachts verwerken wordt vanuit FPA beschouwd als een uitgestelde verwerking. De nachtelijke verwerking wordt vanuit FPA gezien als één geheel met het invoeren van de postcodereeksen. De opgeslagen postcodereeksen zijn onderhoudbaar en vormen daardoor een interne logische gegevensverzameling. Bovendien worden er twee onderhoudsfuncties geteld (voor het wijzigen en verwijderen van postcodereeksen). Onlosmakelijk met de nachtelijke verwerking is het aanmaken van het mutatieverslag verbonden. Het mutatieverslag vervult een functionele eis: het is namelijk nodig voor controledoeleinden. Bovendien passeert het de grens van de toepassing. Om deze redenen wordt voor het mutatieverslag een uitvoerfunctie geteld, hoewel de functie onlosmakelijk met de invoerfunctie verbonden is. Oplossing Tel de volgende functies: één invoerfunctie voor de initiële invoer van postcodereeksen samen met de nachtelijke verwerking; één interne logische gegevensverzameling voor de gegevensverzameling postcodereeksen; twee invoerfuncties voor het wijzigen en verwijderen van de postcodereeksen; één uitvoerfunctie voor het mutatieverslag. Verwijzingen Zie de richtlijnen 5.2.f, 7.2.r en 8.2.p Casus klantensysteem Probleembeschrijving In een vroeg stadium van een systeemontwikkelingtraject bestaan voor een klein klantensysteem de onderstaande functionele specificaties. Van elke klant wordt bijgehouden: naam, adres, plaats, landcode, telefoon en contactpersoon; van Nederlandse klanten bovendien het inschrijvingsnummer bij de Kamer van Koophandel. Men wil klantgegevens kunnen opvoeren, wijzigen en verwijderen. Bij het wijzigen en verwijderen dienen ter verificatie de aanwezige klantgegevens te worden getoond. Verder wil men via het onderstaande afrolmenu de volgende overzichten kunnen aanvragen: DEFINITIES en TELRICHTLIJNEN FPA 109

120 PRAKTIJKSITUATIES MET OPLOSSINGEN Van deze overzichten is onderstaand een voorlopige schets weergegeven. De landnaam wordt opgehaald uit een bestand Landen, dat bij elke landcode de landnaam bevat. Dit bestand wordt door een ander systeem onderhouden. 1. Overzicht "Klanten alle landen" Het overzicht bevat alle klanten, op volgorde van bedrijf. Bij Nederlandse klanten wordt het land niet afgedrukt. Klanten alle landen naam bedrijf land telefoon KvK-nr contactpersoon AeroDat België du Spiré BankBetaal Westerhof ImportRossia Rusland Ivanets LuchtBelga België VandenBerghe SehFern AG Duitsland Strohmann TevreeConsult Doeven 2. Overzicht "Binnenlandse klanten" Het overzicht bevat de Nederlandse klanten, op volgorde van bedrijf. Binnenlandse klanten naam bedrijf land telefoon KvK-nr contactpersoon BankBetaal Westerhof TevreeConsult Doeven 3. Overzicht "Buitenlandse klanten" Het overzicht bevat de buitenlandse klanten. Men wil op de lijst het land voorop. 110 NESMA

121 PRAKTIJKSITUATIES MET OPLOSSINGEN Buitenlandse klanten land naam bedrijf telefoon KvK-nr contactpersoon België AeroDat du Spiré België LuchtBelga VandenBerghe Duitsland SehFern AG Strohmann Rusland ImportRossia Ivanets 4. Overzicht "Contactpersonen Nederlandse klanten" Het overzicht bevat van alle Nederlandse klanten het telefoonnummer en de contactpersoon. Contactpersonen Nederlandse klanten naam bedrijf telefoon contactpersoon BankBetaal Westerhof TevreeConsult Doeven 5. Overzicht "Contactpersonen klanten alle landen (per land)" Het overzicht bevat van alle klanten het telefoonnummer, KvK-nummer en de contactpersoon; de klanten worden hierbij gegroepeerd per land. Contactpersonen klanten alle landen (per land) naam bedrijf telefoon KvK-nr contactpersoon België AeroDat du Spiré LuchtBelga VandenBerghe Duitsland SehFern AG Strohmann Nederland BankBetaal Westerhof TevreeConsult Doeven Rusland ImportRossia Ivanets Opdracht Voer voor dit systeem een globale functiepuntentelling uit. Dat wil zeggen: inventariseer alle gebruikersfuncties (logische gegevensverzamelingen en gebruikerstransacties). DEFINITIES en TELRICHTLIJNEN FPA 111

122 PRAKTIJKSITUATIES MET OPLOSSINGEN Discussie Het entiteittype Klant kan binnen het systeem worden onderhouden en is een interne logische gegevensverzameling. Land is een FPA-tabel, die door dit systeem slechts wordt geraadpleegd. Deze wordt geteld als recordtype binnen de FPA-tabellen-KGV. Andere FPA-tabellen zijn er niet, dus in dit geval bestaat de FPA-tabellen-KGV uit slechts één recordtype. De specificaties spreken over het opvoeren, wijzigen en verwijderen van klantgegevens. Dit leidt tot het tellen van drie invoerfuncties. Dat een KvK-nummer niet bij buitenlandse klanten mag worden opgegeven, speelt geen rol. De gebruiker heeft geen aparte opvragingsfunctie gevraagd. Het binnen de wijzig- of verwijderfunctie ter verificatie tonen van de aanwezige gegevens wordt niet als een aparte opvragingsfunctie geteld. De overzichten 1, 2 en 3 tellen als geheel voor één uitvoerfunctie. Immers, in alle gevallen geldt het volgende: er wordt gerapporteerd over hetzelfde object (klant); de selectierubriek is gelijk (land); de verwerking om de uitvoerproducten te maken is gelijk (naast het selectiemechanisme is er geen aanvullende verwerking nodig); de verzameling data-element-typen van het uitvoerproduct en hun structuur zijn gelijk, namelijk: naam-bedrijf + (land) + telefoon + (KvK-nr) + contactpersoon. De haakjes duiden hier op optionaliteit; de volgorde is niet van belang. Dat in sommige gevallen een rubriek niet wordt afgedrukt, omdat het gegeven er niet is (zoals bij het KvK-nummer) of omdat dat niet gewenst is (zoals bij landnaam), speelt geen rol: de rubrieken zijn immers wel gedefinieerd voor het uitvoerproduct. Bij overzicht 3 is daarnaast de volgorde van de kolommen anders. Dit is geen reden een aparte uitvoerfunctie te tellen. Er is in deze drie gevallen sprake van een directe selectie via de rubriek Land. Hetzelfde resultaat zou ook kunnen worden gerealiseerd met een "invulscherm", waarbij de gebruiker landcode als selectiecriterium krijgt aangeboden. Zo'n invulscherm zou niet als aparte invoerfunctie tellen; de in te vullen gegevens zouden binnen FPA worden beschouwd als besturingsinformatie voor de uitvoerfunctie en zouden elk als data-element-type meetellen. Overzicht 4 selecteert weliswaar dezelfde klanten als overzicht 2, echter de verzameling dataelement-typen is anders, namelijk: naam-bedrijf + telefoon + contactpersoon. Daarom telt dit overzicht als aparte uitvoerfunctie. Overzicht 5 selecteert dezelfde klanten als overzicht 3. De verzameling data-element-typen is in beide overzichten gelijk. Echter, de structuur van het uitvoerproduct is anders (er is sprake van het anders groeperen van de data-element-typen), omdat het land telkens éénmalig wordt gepresenteerd. Daarom wordt dit uitvoerproduct als een aparte uitvoerfunctie geteld. Volgens de richtlijnen worden voor de FPA-tabellen-KGV in het geheel géén functies geteld, ook al zouden er opvraag- of uitvoerfuncties aanwezig zijn. 112 NESMA

123 PRAKTIJKSITUATIES MET OPLOSSINGEN Oplossing Bij een globale functiepuntentelling wordt een logische gegevensverzameling geteld als eenvoudig, en een gebruikerstransactie als gemiddeld. Dit leidt tot de volgende functiepuntentelling: Gebruikersfunctie Type Complexiteit Functiepunten Opmerkingen Klant ILGV eenvoudig 7 FPA-tabellen-KGV KGV eenvoudig 5 Opvoeren klant IF gemiddeld 4 Wijzigen klant IF gemiddeld 4 Verwijderen klant IF gemiddeld 4 Overzicht 1 UF gemiddeld 5 Overzicht Voor FPA gelijk aan overzicht 1. Overzicht Voor FPA gelijk aan overzicht 1. Overzicht 4 UF gemiddeld 5 Overzicht 5 UF gemiddeld 5 Menu Wordt niet geteld. TOTAAL 39 De omvang van het systeem is 39 functiepunten. Verwijzingen Zie de paragrafen 3.2.2, 4.20 en 8.1 en de richtlijnen 5.2.k, 7.2.m, 7.2.n, 8.2.w en 8.3.b Grafieken Probleembeschrijving Een commercieel managementinformatiesysteem geeft in een grafiek weer wat per maand de resultaten van uitstaande offertes zijn, zie het volgende voorbeeld. Welke gebruikerstransactie(s) worden geteld en van welk type? Welke data-element-typen worden geteld? Hoe wordt de complexiteit bepaald? DEFINITIES en TELRICHTLIJNEN FPA 113