Onlangs heeft het Europees Parlement het concept Functional Size (basis voor strategische IT-informatie zoals Productivy, Quality of PDR, ondanks lage ontwikkelingsmethoden, tools, trends, ...) opgenomen als Transversal Engineering Framework in het Europees Agentschap voor de operationele beheer van grootschalige IT-systemen op het gebied van vrijheid, veiligheid en recht (eu-LISA). IFPUG is de vader van de Functional Size (ISO / IEC 14143). In dit artikel (gepubliceerd in MetricViews) is een reeks tips en hints opgenomen om de juiste grootte van de ILF's en EIF's te krijgen
Om een project met een hoge mate van nauwkeurigheid en excellentie te meten, is aanpassing of een verbetering een must voor een CFPS of CFPP.
Het correct identificeren van de logische bestanden (ILF en EIF) is misschien wel een van de meest uitdagende taken als er geen conceptueel of logisch gegevensmodel bestaat of als het niet zo correct is als gewenst.
Omgekeerd hebben invoer- of uitvoertransactionele functies (EI, EO en EQ) per algemene regel minder discussie omdat in bijna alle gevallen de bewijzen duidelijk zichtbaar zijn; bijv. een invoerscherm, een proces dat een bestand importeert, een rapport, een proces dat een bestand genereert ... Misschien kan de belangrijkste discussie ontstaan, nogmaals, bepalen wat wordt beschouwd als een bestand (FTR; File Type Referenced) voor die invoer en uitvoer transacties, en om het concept "proces" te verfijnen. Bovendien kan er een klein debat bestaan over het concrete aantal DET's, maar die DET-debatten kunnen in de meeste gevallen worden overgeslagen omdat de grootte precies hetzelfde zal zijn als de ILF / EIF 71 of 72 DET's heeft. De uitzondering is wanneer het DET-getal een verandering in de procescomplexiteit bepaalt van laag naar gemiddeld, van gemiddeld naar hoog of vice versa.
Het is algemeen bekend, zelfs voor mensen met relatief weinig ervaring met het tellen van functiepunten, dat een logisch bestand iets anders is dan een fysiek bestand. Soms zijn technische of functionele experts meer vertrouwd met objecten die aangeraakt kunnen worden, zoals een fysiek bestand of een databasetabel; "Logische" informatie is een beetje abstracter.
Die verschillen zijn uiteraard essentieel omdat de IFPUG Function Point Counting Practices Manual (CPM) is gebaseerd op logische bestanden.
Zelfs het is niet nieuw dat functiepuntanalyse het concept van een logische gegevensentiteit gebruikt, vanuit het oogpunt van de gebruiker, die kan worden gegroepeerd in een of meer logische bestanden. Bovendien is het belangrijk om de woorden "gebruikersweergave" te benadrukken, omdat er soms een andere interpretatie kan worden gevonden door het concept "gebruikersweergave" toe te passen.
Het is niet ongebruikelijk om te zien dat er geen logisch datamodel bestaat, zowel bij kleine als niet-kleine bedrijven of projecten. Deze situatie kan worden verbeterd, maar het is in veel gevallen de situatie in het echte leven. In andere gevallen worden in plaats van deze "gebruikersweergave-entiteiten" rechtstreeks weergegeven in de databasetabellen of -bestanden.
Het niet hebben van de juiste informatie vanuit het oogpunt van de gebruiker, of deze niet weerspiegelen in de juiste projectdocumentatie, kan resulteren in niet-nauwkeurige tellingen. Het overwegen van een nieuw overbodig / extra gemiddelde complexiteit intern logisch bestand (in plaats van te bedenken dat dit niet echt een nieuw bestand is omdat het kan zijn opgenomen in een reeds bestaand bestand) wordt geteld als 10 FP's. Deze grootte van 10 FP's zal precies hetzelfde zijn als het creëren van twee nieuwe gemiddelde externe outputs (2 x 5 FP's).
Bepalen dat een applicatie vijf outputs heeft in plaats van drie, of drie in plaats van vijf, is heel eenvoudig en de verschillende betrokken partijen (een CFPS, een gebruiker, IT-technici van de klantzijde, IT-provider, enz.) tot dezelfde conclusie na het verzamelen van alle informatie en na het toepassen van de CFPS op de juiste criteria (criteria = methode, uitvoerconcept, grenskruisconcept, procesconcept, enz.), maar na het bespreken van het concept 'bestanden', om tot de hetzelfde punt is misschien niet zo eenvoudig.
Waarom? Soms zien verschillende mensen met verschillende disciplines (niet technische, technische, CFPS-experts) de situatie anders. Dit kan het gevolg zijn van het feit dat de informatie niet volledig is geschreven, of de schriftelijke informatie weerspiegelt meer concrete technische aspecten dan functionele (gebruikersogen). Sommige partijen kunnen geïnteresseerd zijn in hogere of lagere tellingen en zelfs dit laatste argument kan het aantal bestanden kunstmatig vergroten of verkleinen.
Er kan speciale aandacht worden besteed aan het toepassen van deel 3, hoofdstuk 2, van de CPM, stap 1 "Identificeer logische bestanden" om de bestanden correct te bepalen vanuit het oogpunt van de gebruiker, en stap 4 "Identificeer recordelementtypes" om te bepalen of er verschillende entiteiten zijn één logisch bestand of meer dan één.
Deze twee stappen zijn essentieel en, ondanks dat het voor de hand lijkt te liggen, is het cruciaal om te onthouden [met speciale aandacht voor het eerste en tweede punt], dat:
- Een logisch bestand is een logische groep gegevens zoals gezien door de gebruiker.
- Er kunnen meer dan één gegevensentiteit worden afgeleid in één logisch bestand.
- De opgenomen informatie kan herkenbaar of vereist zijn voor de gebruiker.
- Entiteiten die niet door een applicatie worden onderhouden, zijn uitgesloten.
- Codegegevensentiteiten zijn uitgesloten.
- Entiteiten zonder attributen die door de gebruiker worden vereist, zijn uitgesloten.
- Entiteiten die alleen om technische redenen zijn gemaakt, zijn uitgesloten.
Om alle bovenstaande punten volledig duidelijk te hebben, ervoor te zorgen dat de antwoorden gebaseerd zijn op het woord "gebruikersstandpunt" en zonder enige vorm van technische invloed (in sommige gevallen synoniem voor een pseudobesmetting) is essentieel om tot de juiste te komen. en nauwkeurige resultaten.
