Produktmetriken. Inhaltsverzeichnis. H.-G.Hopf. 6. Mai Einleitung 3

Transkript

1 Produktmetriken H.-G.Hopf 6. Mai 2005 Inhaltsverzeichnis 1 Einleitung 3 2 Lesbarkeitsmaße Flesh-Kincaid-Indizes Verständlichkeitsgrad Lesbarkeitsgrad Fog-Index Beispiele Einsatz COCOMO Berechnungsmodell Entwicklungskomplexitätsparameter Einflußfaktoren Beispielberechnung Function Point Verfahren Prinzipielles Vorgehen Festlegen der Systemgrenze Zählen von Funktionspunkten Kategorisierung Ermittlung des Komplexitätsgrades ν einer Funktion Bestimmung der Funktionspunkte einer Funktion Bestimmung der Funktionspunkte für die gesamte Anwendung Projektspezifische Anpassung Korrekturfaktoren Korrigierte Funktionspunkte Beispiel: Berechnung Function Point Zählregelwerk Beispiel: Zählregeln Aufwandsabschätzung

2 INHALTSVERZEICHNIS INHALTSVERZEICHNIS 5 Entwurfsstrukturmetriken von Blaschek Definition Beispiele Beispiel Beispiel Beispiel Zusammenfassung der Ergebnisse Einsatz Modul-Bindungsmetrik 47 7 LOC-Maß 49 8 Halstead-Metriken Das Metrik-Konzept Ausgangsgrößen Kenngrößen Beispiele Beispiel Beispiel Vergleich Bemerkungen McCabe-Metrik Definition Beispiele Teilgraphen Bemerkungen Grenzwert Test-Metriken Testende Prognosen Beispielberechnung software reliability model Wartungsmetriken Entwicklungseffektivität E Änderungsmetrik von Stahlknecht Portabilitätsmetriken Portabilitätsmetrik von Gilb Portabilitätsmetrik von Hommel Aufwandsmetriken Zusammenfassung Literatur 86 Version 1.03 / 6. Mai c H.-G. Hopf

3 1 EINLEITUNG 1 Einleitung In diesem Kapitel sollen Produktmetriken vorgestellt werden. Im Softwareentwicklungsprozess werden in jeder Prozessphase Entwicklungsergebnisse, Endprodukte wie z.b. der Programmcode, oder Zwischenprodukte wie beispielsweise Entwicklungsdokumente (Anforderungsdefinition, Systemarchitektur,...) erzeugt. Diese Produkte können mit Metriken bezüglich ihrer Qualität ausgemessen werden. Die hierfür eingesetzten Metriken werden als Produktmetriken bezeichnet. Die Produktmetriken sind teilweise sehr spezifisch auf Produkte einer Softwareentwicklungsphase hin ausgerichtet oder auf einen spezifischen Produkttyp hin zugeschnitten, andererseits in manchen Fällen für verschiedene Produkttypen in unterschiedlichen Softwareentwicklungsphasen einsetzbar. So sind die von Halstead entwickelten Software Science Maße dafür vorgesehen in der Implementierungsphase entstandenen Quellcode zu bewerten, Lesbarkeitsmetriken jedoch können für alle Entwicklungsdokumente eingesetzt werden, unabhängig davon, in welcher Phase sie entstehen. Produktmetriken können weiter unterschiedlich klassifiziert werden (direkte/indirekte Metriken,...). Um den Blick auf diesen unterschiedlichen Möglichkeiten der Klassifizierung von Produktmetriken nicht zu verstellen, werden die Produktmetriken in diesem Kapitel zunächst nur nacheinander vorgestellt. Version 1.03 / 6. Mai c H.-G. Hopf

4 2 LESBARKEITSMASSE 2 Lesbarkeitsmaße und Verständlichkeitsmaße Lesbarkeitsmaße und Verständlichkeitsmaße bewerten die Schwierigkeit eines Textes. Als schwierigkeitssteigernd und das Verständnis erschwerend werden in einem Text angesehen: Wörter mit besonders lange Silben Wörter mit besonders viele Silben Sätze mit vielen Wörtern Texte mit vielen komplizierten Wörtern Lesbarkeitsmaße und Verständlichkeitsmaße versuchen diese Elemente zu erfassen und in einen Zahlenwert abzubilden. Es gibt verschiedene Konzepte für diese Umsetzung (siehe auch [Dum92] oder [Kit90a]). Einige sollen im Folgenden vorgestellt werden. 2.1 Flesh-Kincaid-Indizes Es gibt zwei Flash-Kincaid-Indizes: Den Flesh-Kincaid-Verständlichkeitsgrad und den Flesh-Kincaid-Lesbarkeitsgrad. Beide Metriken gehen von der mittlere Satzlänge und von der mittleren Anzahl von Wortsilben aus: mittlere Satzlänge = Wortzahl Satzzahl mittleren Anzahl von Wortsilben = Silbenzahl Wortzahl Flesh-Kincaid-Verständlichkeitsgrad Der Verständlichkeitsgrad berechnet sich nach [Dum92] gemäß folgender Formel: L = 0.39 Wortzahl Silbenzahl Satzzahl Wortzahl Verständlichkeitsmetrik L Schwierigkeitsgrad 1-8 normal 9-12 schwierig sehr schwierig Der Flesh-Kincaid-Verständlichkeitsgrad bewertet einen Text nach einem bestimmten Schulniveau. Ein Ergebnis von 8,0 bedeutet zum Beispiel, dass das Dokument für einen Schüler der achten Klasse verständlich ist. Je nach erreichtem Wert für L wird ein Text dann als normal, schwierig oder sehr schwierig eingestuft. Standarddokumente sollten einen Wert von etwa 7,0 bis 8,0 erreichen. Version 1.03 / 6. Mai c H.-G. Hopf

5 2.2 Fog-Index 2 LESBARKEITSMASSE Flesh-Kincaid-Lesbarkeitsgrad Der Flesh-Kincaid-Lesbarkeitsgrad bewertet einen Text nach einem Punktesystem mit maximal 100 Punkten. Je höher die Punktzahl, desto verständlicher ist das Dokument. In Standarddokumenten sollte man eine Punktzahl von etwa 60 bis 70 anstreben. Die Formel für den Flesch-Lesbarkeitsgrad lautet in der in WORD 2000 vorgeschlagenen Form: Lesbarkeitsmetrik X = Wortzahl Silbenzahl 84.6 Satzzahl Wortzahl L = Y (X) X Negative Werte werden für den Lesbarkeitsgrad nicht zugelassen. Mathematisch wird dies durch die sog. Heaviside-Funktion Y erreicht. Y ist wie folgt definiert: { 0 für x < 0 Y (x) = 1 für x Fog-Index Eine weitere Variante eines Lesbarkeitsmaßes kombiniert die Basismeßgrößen mittlere Satzlänge und Anteil der komplizierten Wörter im Text: Lesbarkeitsmetrik mittleren Satzlänge = Wortzahl Satzzahl Anteil komplizierter Wörter = Anzahl komplizierter Wörter Wortzahl Der Fog-Index wird nach Kitchenham (siehe [Kit90a]) definiert als: F = c ( Wortzahl Satzzahl Anzahl komplizierter Worte ) Wortzahl Komplizierte Worte sind Worte mit drei oder mehr Silben. Im Deutschen sind viele Wörter zweisilbig. Der Faktor c ist abhängig von der Landessprache. c Sprache 0.4 Englisch 0.25 Deutsch Es finden sich von der obigen Darstellung deutlich abweichende weitere Formelzusammenhänge in der Literatur (z.b.??). Version 1.03 / 6. Mai c H.-G. Hopf

6 2.3 Beispiele 2 LESBARKEITSMASSE 2.3 Beispiele Zwei Beispieltexte sollen einander gegenübergestellt werden. Ein Text stammt aus einem Benutzerhandbuch das zweite Beispiel entstammt einem Comic. 1. Beispieltext zum Thema Desktop-Publishing-Konvertierungsprogramme Auszug Benutzerhandbuch Viele Entwickler argumentieren, dass das Web so unterschiedlich vom Druck sei, dass sie Ihre Desktop - Publishing-Dokumente wegwerfen und von vorne anfangen sollten. Dies ist aber nicht immer praktisch möglich, vor allem wenn Sie umfangreiche Dokumente haben, die Sie aufs Web bringen möchten. Verknüpfungen zu erschaffen erfordert eine andere Vorgehensweise als lineare Veröffentlichungen, aber es ist durchaus möglich, solche Unterschiede im Konversionsprozess auszugleichen. Seitenkästen, verknüpfte Textfelder und Grafiken stellen hier die größte Herausforderung. Auswertung: Anzahl Sätze 4 Anzahl einsilbiger Wörter 28 Anzahl zweisilbiger Wörter 21 Anzahl dreisilbiger Wörter 10 Anzahl viersilbiger Wörter 10 Anzahl fünfsilbiger Wörter 3 Anzahl sechssilbiger Wörter 1 Anzahl siebensilbiger Wörter 0 Anzahl achtsilbiger Wörter 0 Anzahl neunsilbiger Wörter 0 Anzahl komplizierter Wörter 24 Anzahl Wörter insgesamt 73 Anzahl Silben 161 Tabelle 1: Messwerte für den ersten Beispieltext (Benutzerhandbuch) Index Wert Flesh-Kincaid-Verständlichkeitsgrad Flesh-Kincaid-Lesbarkeitsgrad 1.73 Fog-Index Tabelle 2: Auswertung für den ersten Beispieltext (Benutzerhandbuch) Der Verständlichkeitswert ist mit oberhalb der als sehr schwierig zu verstehenden Texte angesiedelt. Der Lesbarkeitsgrad ist mit 1.73 nahe dem Maximalwert für schwierige Texte angesiedelt. Der Fog-Index Version 1.03 / 6. Mai c H.-G. Hopf

7 2.4 Einsatz 2 LESBARKEITSMASSE drückt die Lesbarkeit in einer anderen Skala aus als der Flesh-Kincaid- Lesbarkeitsgrad. Der Wert errechnet sich zu Beispieltext Comic Comic-Text UhOh! Ich denke, wir sollten eine SQLDatenbank haben. Auswertung: Anzahl Sätze 2 Anzahl einsilbiger Wörter 5 Anzahl zweisilbiger Wörter 4 Anzahl dreisilbiger Wörter 1 Anzahl viersilbiger Wörter 0 Anzahl fünfsilbiger Wörter 0 Anzahl sechssilbiger Wörter 0 Anzahl komplizierter Wörter 1 Anzahl Wörter insgesamt 8 Anzahl Silben 16 Tabelle 3: Messwerte für den zweiten Beispieltext (Comic) Index Wert Flesh-Kincaid-Verständlichkeitsgrad 5.24 Flesh-Kincaid-Lesbarkeitsgrad Fog-Index 3.75 Tabelle 4: Auswertung für den zweiten Beispieltext (Comic) Der Verständlichkeitswert ist mit 5.24 im Bereich eines normal verständlichen Textes. Der Lesbarkeitsgrad ist mit im Mittelfeld der Skala zwischen 100 (sehr leicht) bis 0 (sehr schwierig). Der Fog-Index drückt die Lesbarkeit in einer anderen Skala aus als der Flesh-Kincaid- Lesbarkeitsgrad. Der Wert errechnet sich zu Beide Auswertungen können verglichen werden. Die Indexwerte fallen erkennbar unterschiedlich aus. Man kann feststellen, dass der Comic-Text sowohl verständlicher als auch lesbarer ist als der Text aus dem Benutzerhandbuch. Diese Charakterisierung der Texte im Vergeich durch die Indexwerte entspricht unserem Empfinden. Das Meßmodell ist damit offensichtlich vernünftig. Die Ergebnisse im Vergleich: Vergleich 2.4 Einsatz von Lesbarkeitsmaßen Wozu benötigt man Lesbarkeits- bzw. Verständlichkeitsmaße? Wie oben festgestellt wird unser natürliches Empfinden durch die entsprechenden Index- Version 1.03 / 6. Mai c H.-G. Hopf

8 2.4 Einsatz 2 LESBARKEITSMASSE Index Benutzerhandbuch Comic Flesh-Kincaid-Verständlichkeitsgrad Flesh-Kincaid-Lesbarkeitsgrad Fog-Index Tabelle 5: Vergleich der Auswertungen der Beispieltexte werte richtig wiedergegeben. Dementsprechend könnte man auf eine quantitative Erfassung verzichten. Es gibt Gelegenheiten, wo das natürliche Empfinden über Lesbarkeit und Verständlichkeit eines Textes bei verschiedenen Personen unterschiedlich ausfällt. Beispielsweise in einer Inspektionssitzung kann es durchaus vorkommen, dass Autor und Inspektoren bei einem Prüfobjekt, z.b. bei einer Anforderungsspezifikation oder bei einer Benutzerdokumentation unterschiedliche Vorstellungen von der Lesbarkeit bzw. Verständlichkeit eines Textes haben. Wie soll entschieden werden? Hier ist es hilfreich, durch objektive Indexwerte den aktuell vorliegenden Grad an Lesbarkeit und Verständlichkeit zu quantifizieren. Liegen diese ermittelten Indexwerte außerhalb eines (vorher festgelegten) Toleranzbereichs, ist der Hinweis auf eine Überarbeitung angebracht und unstrittig. Der Toleranzbereich kann aufgrund von Erfahrungen durch die Leser der Dokumente festgelegt werden. Auch können für verschiedene Kategorien von Dokumenten unterschiedliche Toleranzbereiche sinnvoll sein. Es ist heute vergleichsweise einfach, Lesbarkeits- und Verständlichkeitsindikatoren zu ermitteln. So wird beispielsweise der oben eingeführte Flesh- Kincaid-Lesbarkeitsgrad und Flesh-Kincaid-Verständlichkeitsgrad in Textprogrammen wie z.b. Word 2000 zur Verfügung gestellt. Die Abbildung 1 zeigt ein Beispiel. Objektivierung der Beurteilung Werkzeuge Version 1.03 / 6. Mai c H.-G. Hopf

9 2.4 Einsatz 2 LESBARKEITSMASSE Abbildung 1: Lesbarkeitsstatistik aus Word 2000 für das erste Beispiel (Benutzerhandbuch) Version 1.03 / 6. Mai c H.-G. Hopf

10 3 COCOMO 3 COCOMO Das Verfahren COCOMO (COnstructive COst MOdel) wurde von Barry Boehm 1981 entwickelt. Das Modell bewertet die Softwarekosten in Form einer Entwicklungszeitabschätzung. 3.1 Berechnungsmodell Ausgangsparameter sind: Produktgröße gemessen in Codezeilen in 1000 LOC-Einheiten (kilo delivered source instructions): KDSI Entwicklungskomplexitäts-Parameter: α, β, γ, δ Einflußfaktoren der Softwareentwicklung: a i mit 1 a i 15 Berechnete Maßgrößen sind: Entwicklungsaufwand in Mann-Monaten: PM (personal month ) P M = α KDSI β 15 a i Entwicklungsaufwand in Monaten: TDEV (time of development) i=1 T DEV = γ PM δ Entwicklungsaufwand in Personen: N (number of programmers) N = P M T DEV Entwicklungskomplexitätsparameter Die Entwicklungskomplexität wird durch die Parameter α, β, δ und γ berücksichtigt. Es gibt vordefinierte Parameterwerte. Sie sind in der folgenden Tabelle 6 (nach [Dum92]) bzw. 7 (nach Kitchenham [Kit90b]) dargestellt. Entwicklungskomplexität (mode) α β γ δ einfach (organic) mittel (semi detached) schwierig (embeded) basic intermediate and detailed Tabelle 6: Entwicklungskomplexitätsparameter nach Dumke Die Entwicklungsparameter werden jeweils für drei Kategorien der Softwareentwicklung angegeben. Version 1.03 / 6. Mai c H.-G. Hopf

11 3.1 Berechnungsmodell 3 COCOMO Entwicklungskomplexität (mode) α β γ δ einfach (organic) mittel (semi detached) schwierig (complex model) basic intermediate and detailed Tabelle 7: Entwicklungskomplexitätsparameter nach Kitchenham einfach (organic / simple model): Diese Kategorie bedeutet Softwareentwicklung mit vergleichsweise kleinen Teams in familiärer Atmosphäre. schwierig (embeded / complex model): Diese Kategorie bedeutet Softwareentwicklung mit harten Randbedingungen. Die Randbedingungen können organisatorischer Natur sein (Zeitvorgaben), technischer Natur sein (Vorgabe von Methoden/Techniken) oder durch die Aufgabenstellung bedingt sein (Vorgabe von Realisierungsnotwendigkeiten). mittel (semi detached / average model): Diese Kategorie bedeutet Softwareentwicklung unter Bedingungen, die zwischen den beiden Kategorien organic / simple model und embeded / complex model angesiedelt ist. Die Tabellen 6 und 7 zeigen zwei unterschiedliche Sätze von Entwicklungskomplexitätsparametern. Wie man sieht, kommen hier durchaus verschiedene Ausprägungen in den Parametersätzen zur Anwendung. Beide angegebenen Versionen sind Vorschlagswerte. Hier hat eine Firma / Abteilung Spielraum, auf der Basis eigener Erfahrung zu eigenen Paramersätzen in den vorgeschlagenen oder auch feiner abgestimmten Kategorien zu kommen Einflußfaktoren Einflußfaktoren, die auf die Softwareentwicklung Auswirkung haben, sind in der Tabelle 8 dargestellt. Man spricht auch von Kostentreibern (cost driver), da die Werte für diese Entwicklungseinflussfaktoren letztlich Einfluss auf die Entwicklungskosten nehmen. Diese Einflußfaktoren a i sind nach verschiedenen Kategorien aufgelistet. Die Kategorien betreffen: Produktattribute, Rechnereigenschaften, Erfahrung des Personals, Projekteigenschaften Der Einfluss wird in sechs Stufen von sehr niederig, über niedrig, mittel, hoch, sehr hoch und extrem hoch ausgedrückt. Für jeden der 15 Version 1.03 / 6. Mai c H.-G. Hopf

12 3.2 Beispielberechnung 3 COCOMO Einflussparameter ist je nach Ausprägung des Einflusses ein Zahlenwert angegeben. Ein mittlerer Einfluss wird durch den Wert 1.00 beschrieben. Da die Einflussfaktoren multiplikativ in die Berechnungsformel für den Entwicklungsaufwand eingehen, bedeutet dies keine Änderung des Ausgangswertes α KDSI β. Eine Abweichung vom mittleren Einfluss hat zur Folge, dass der Multiplikator a i leicht erniedrigt oder erhöht wird. Die a i - Werte bewegen sich zwischen 0.70 und Die nachfolgende Tabelle 8 ist [Kit90b] entnommen. Einflussfaktoren / Kostenfaktoren Para- Bedeutung Einfluss meter sehr sehr extrem a i niedrig niedrig mittel hoch hoch hoch Produktattribute a 1 RELY geforderte Zuverlässigkeit a 2 DATA Größe der Datenbasis a 3 CPLX Komplexität des Produktes Rechnereigenschaften a 4 TIME benötigte Rechenzeit a 5 STOR benötigter Speicherplatz a 6 VIRT Systemänderungen a 7 TURN Zugang Erfahrung des Personals a 8 ACAP Fähigkeit zur Analyse a 9 AEXP Anwendungserfahrung a 10 PCAP Programmierfähigkeit a 11 VEXP Erfahrung mit dem System a 12 LEXP Erfahrung mit der Programmiersprache Projekteigenschaften a 13 MODP moderne Programmierpraktiken a 14 TOOL Anwendung von SW-Tools a 15 SCED erforderliche Entwicklungszeit Tabelle 8: Werte für Einflussfaktoren (cost driver) nach Kitchenham Die Abkürzungen für die einzelnen Einflussfaktoren leiten sich aus der englischen Bezeichnung ab. (siehe Tabelle 9). Auch bei den Einflussfaktoren könnten andere Aspekte mit neuen Gewichtsfaktoren zur Anwendung kommen. Eine Firma / Abteilung hat hier wieder Spielraum, auf der Basis eigener Erfahrung zu eigenen Vorstellungen hinsichtlich der Berücksichtigung von Einflussfaktoren zu kommen. 3.2 Beispielberechnung Ein einfaches Kassensystem hat etwa Quellcodezeilen (=90 KDSI). Es wird eine mittlere Entwicklungskomplexität angenommen und ein mittlerer Einfluss der Eintwicklungsfaktoren festgestellt. Beispiel Version 1.03 / 6. Mai c H.-G. Hopf

13 3.2 Beispielberechnung 3 COCOMO Cost driver / Einflussfaktoren Para- englische Bezeichnung deutsche Bezeichnung Product Attributes / Produktattribute a 1 RELY Required Software Reliability geforderte Zuverlässigkeit a 2 DATA Data Base Size Größe der Datenbasis a 3 CPLX Product Complexity Komplexität des Produktes Computer Attributes / Rechnereigenschaften a 4 TIME Execution Time Constraint benötigte Rechenzeit a 5 STOR Main Storage Constraint benötigter Speicherplatz a 6 VIRT Virtual Machine Volatility Systemänderungen a 7 TURN Computer Turnaround Time Zugang Personnel Attributes / Erfahrung des Personals a 8 ACAP Analyst Capability Fähigkeit zur Analyse a 9 AEXP Applications Experience Anwendungserfahrung a 10 PCAP Programming Capability Programmierfähigkeit a 11 VEXP virtual Machine Experience Erfahrung mit dem System a 12 LEXP Programming Language Experience Erfahrung mit der Programmiersprache Project Attributes / Projekteigenschaften a 13 MODP Use of Modern Programming moderne Programmierpraktiken Practices a 14 TOOL Use of Software Tools Anwendung von SW-Tools a 15 SCED Required Development Schedule erforderliche Entwicklungszeit Tabelle 9: Einflussfaktoren (cost driver) nach Kitchenham Entwicklungsaufwand in Mann-Monaten: PM (personal month) P M = α KDSI β 15 a i i=1 = Personenmonate = Personenmonate Entwicklungsaufwand in Monaten: TDEV (time of development) T DEV = γ PM δ = = 21.4 Monate Entwicklungsaufwand in Personen: N (number of programmers) N = P M T DEV = = 21.6 Personen 21.4 Version 1.03 / 6. Mai c H.-G. Hopf

14 4 FUNCTION POINT VERFAHREN 4 Function Point Verfahren Die Albrechts-Metrik oder auch Function Point Methode wurde ab 1979 bei IBM von Allan Albrecht entwickelt wurde seine Methode von IBM erweitert. Eine internationale Organisation (IFPUG: International Function Point User Group) übernahm die Weiterentwicklung und Dokumentation der Methode. Vorgestellt wird die Function Point Methode in der Version 4.2 der IFPUG (siehe [IFP04], [BF00] und [Rud04]). 4.1 Prinzipielles Vorgehen Die Größe eines zu entwickelnden Produkts wird in diesem Modell durch die Produktfunktionalität erfasst. Die Function Point Methode versucht die Produktfunktionalität (amount of functionality) in fünf Funktionsgrundkategorien aus der Sicht von außen auf das System quantitativ zu erfassen, d.h. die Größe des Produktes in Funktionalität anzugeben. Das Zählen von Funktionspunkten für ein Produkt oder Programm verläuft nach folgendem Schema: Vorgehen 1. Festlegen der Systemgrenzen Es muss zunächst festgelegt werden, was zum zu erstellenden Produkt gehört. Dies geschieht durch Definition der sog. Systemgrenze (system boundary). 2. Ermittlung der sog. unadjusted function points (UFP oder FP) Mit den unadjusted function points wird die Produktgröße und -komplexität erfasst. Die Zähleinheit ist der function point. Jede Produktfunktion wird analysiert. Sie wird einer der fünf Funktionskategorien zugeordnet. Weiter wird sie in ihrem Komplexitätsgrad beurteilt. Dazu stehen drei Komplexitätsgrade zur Verfügung. Gemäß Funktionskategorie und Schwierigkeitsgrad ist eine Funktionspunkte-Basiswert definiert. Dieser wird der Produktfunktion zugeordnet. Die Summe der Funktionspunktewert aller Produktfunktionen ergibt den Funktionspunktewert der Anwendung bzw. des Produkts. 3. Ermittlung der sog. adjusted function points (CFP) Dieser über die gesamte Anwendung ermittelte Funktionspunkte-Zählwert kann zusätzlich bezüglich projektspezifischer Randbedingungen (Programmiersprache, Vorgehensweise, Technologie,...) gewichtet werden. Diese Randbedingungen werden durch Korrekturfaktoren berücksichtigt. Insofern bleibt als weiterer Schritt die Bestimmung von anwendungsbezogenen Korrekturfaktoren. Version 1.03 / 6. Mai c H.-G. Hopf

15 4.2 Festlegen der Systemgrenze 4 FUNCTION POINT VERFAHREN 4.2 Festlegen der Systemgrenze Die Systemgrenzen legen fest, was zum System gehört und im Folgenden beim Zählen berücksichtigt werden muss und was außerhalb des Systems liegt. Die Systemgrenze muss aus Benutzersicht festgelegt werden. Erst wenn die Systemgrenze definiert ist, ist es möglich Datenströme zwischen System und Systemumgebung zu definieren und Datenbestände als interne und externe Datenbestände zu identifizieren. Abbildung 2: Studentenverwaltung 4.3 Zählen von Funktionspunkten (unadjusted function points) Das Zählen von Funktionspunkten (unadjusted function points) erfolgt in den Schritten: 1. Kategorisierung von Funktionen 2. Bestimmung des Komplexitätsgrades einer Funktion 3. Bestimmung des Funktionspunktwertes für eine Funktion der entsprechenden Kategorie mit vorgegebenem Komplexitätsgrad 4. Bestimmung des Funktionspunktewertes der gesamten Anwendung durch Analyse aller relevanten Funktionen Kategorisierung von Funktionen Funktionskategorien: Das Zählen von Funktionspunkten (unadjusted function points) erfolgt in fünf Funktionskategorien. Die betrachteten Funktionskategorien sind verbunden mit: 1. externen Eingaben (external input EI) Version 1.03 / 6. Mai c H.-G. Hopf

16 4.3 Zählen von Funktionspunkten 4 FUNCTION POINT VERFAHREN 2. externen Ausgaben (external output EO) 3. internen Dateizugriffen (internal logical file ILF) 4. externen Dateizugriffen (external interface file EIF) 5. externen Anfragen (external inquiry EQ) Eine Funktionskategorie wird im Folgenden mit k bezeichnet: k {EI, EO, ILF, EIF, EQ} Die Abbildung 2 zeigt Beispiele für Funktionen aus den verschiedenen Kategorien. Die fünf Funktionskategorien lassen sich in Datenfunktionen (Funktionen, die Datenbestände verfügbar machen) und Transaktionen (Funktionen mit Verarbeitungslogik) aufteilen (siehe Abbildung 3). Abbildung 3: Gruppierung der Funktionskategorien Datenfunktionen (data functions) Funktionskategorien internen Dateizugriffen (internal logical file ILF) Datenbestände werden bewertet in den Eine interne logische Datei (internal logical file) ist eine identifizierbare logisch zusammengehörige Gruppe von Daten oder Kontrollinformationen, die innerhalb der Systemgrenzen gepflegt wird. Die primäre Absicht eines ILF s ist es Daten zu speichern, die durch einen oder mehrere Elementarprozesse gepflegt werden. externen Dateizugriffen (external interface file EIF) Eine externe Schnittstellen-Datei (external interface file) ist eine identifizierbare logisch zusammengehörige Gruppe von Daten oder Kontrollinformationen, die vom System referenziert werden, aber von einer anderen (externen) Anwendung gepflegt werden. Die primäre Absicht eines EIF s ist es Daten zu speichern, die durch einen oder mehrere Elementarprozesse des Systems referenziert werden. Ein EIF des Systems ist ein ILF einer anderen Anwendung. Der Begriff identifizierbar (user identifiable) verweist auf definierte und gleichermaßen von Softwareentwicklern und Benutzern interpretierte Anforderungen bezogen auf den Prozess oder die Daten. Datenfunktionen ILF EIF Version 1.03 / 6. Mai c H.-G. Hopf

17 4.3 Zählen von Funktionspunkten 4 FUNCTION POINT VERFAHREN Transaktionen (transactional functions) in den Funktionskategorien: Transaktionen werden bewertet Transaktionen externen Eingaben (external input EI) Eine externe Eingabe (external input) ist ein Elementarprozess, der Daten oder Kontrollinformation verarbeitet, die von außerhalb des Systems in das System eingegeben werden. Bei einem EI ist die primäre Absicht des Elementarprozesses, eine oder mehrere ILF s zu pflegen oder das Systemverhalten zu ändern. externen Ausgaben (external output EO) Eine externe Ausgabe (external output) ist ein Elementarprozess, der Daten oder Kontrollinformation an den Benutzer (über die Systemgrenze hinweg) ausgibt. Bei einem EO ist die primäre Absicht des Elementarprozesses, dem Anwender Informationen zu präsentieren. Die Verarbeitungslogik des Elementarprozesses muss Berechnungen bzw. die Ableitung oder Transformation von Daten durchführen und kann Abfragen von Daten oder Kontrollinformation höchstens zusätzlich enthalten. externen Anfragen (external inquiry EQ) Eine externe Anfrage (external inquiry) ist ein Elementarprozess, der Daten oder Kontrollinformation an den Benutzer (über die Systemgrenze hinweg) ausgibt. Bei einem EQ ist die primäre Absicht des Elementarprozesses, dem Anwender Informationen zu präsentieren. Die Verarbeitungslogik des Elementarprozesses beinhaltet dazu Abfragen von Daten oder Kontrollinformation. Die Verarbeitungslogik des Elementarprozesses enthält keine Berechnungen, Ableitungen oder Transformationen von Daten. Es wird kein ILF gepflegt. Das Systemverhalten wird nicht beeinflusst. Ein Elementarprozess (elementary process) ist die kleinste Verarbeitungseinheit (unit of activity), die für Benutzer von Bedeutung ist. Ein Elementarprozess ist eigenständig und in sich abgeschlossen (self contained), d.h. er enthält alle Verarbeitungsschritte die für einen erfolgreichen Abschluss einer Aufgabe notwendig sind. Dementsprechend wird durch den Elementarprozess der in der Anwendung bearbeitete Geschäftsvorfall (business) in einem konsistenten Zustand hinterlassen. Im Deutschen kann man den Elementarprozess auch als Transaktion bezeichnen. Der Begriff pflegen (maintained) bedeutet in diesem Zusammenhang, die Fähigkeit, Daten durch einen Elementarprozess bzw. durch eine Transaktion zu bearbeiten und zu modifizieren. Der Begriff Kontrollinformation (control information) bezeichnet Daten, die einen Elementarprozess in seiner Ausführung beeinflussen (wann wird was wie mit den zu bearbeitenden Daten getan). Die Ablauflogik oder Verarbeitungslogik (processing logic) realisiert einen Elementarprozess. Die Verarbeitungslogik kann folgende Aktionen beinhal- EI EO EQ Elementarprozess Datenpflege Kontrollinformation Verarbeitungslogik Version 1.03 / 6. Mai c H.-G. Hopf

18 4.3 Zählen von Funktionspunkten 4 FUNCTION POINT VERFAHREN ten: 1. Validierungen (validation), z.b.eingangsprüfung, Akzeptanztest, Berechnungen (calculations), z.b. Auswertung mathematischer Formeln, Umrechnungen (conversion) 4. Auswahl oder Selektion von Daten (data is filtered or selected) 5. Überprüfen von Bedingungen (analysing conditions) 6. Aktualisieren von ILF s 7. Referenzieren von ILF s oder EIF s 8. Abfragen von Informationen (Daten oder Kontrolldaten) 9. Ableitungen und Transformationen (derived data) 10. Verändern des Systemverhaltens (alter system behavior 11. Aufbereiten und Präsentieren von Informationen außerhalb der Systemgrenzen (prepare and present information) 12. Aufnahme von Eingabedaten von außerhalb der Systemgrenzen (accept data or control information) 13. Umsortieren von Daten (resorting or rearranging set of data) Elementarprozesse der Kategorien EI, EO und EQ lassen sich bezüglich der Verarbeitungslogik wie in Abbildung 10 dargestellt gegeneinander abgrenzen Ermittlung des Komplexitätsgrades ν einer Funktion Komplexitätsgrad: Zunächst wird die Komplexität einer Funktion bewertet. Eine Programmfunktion kann in einer von drei Schwierigkeitsstufen (einfach, mittel, komplex) auftreten. Der Komplexitätsgrad einer Funktion wird im folgenden mit ν bezeichnet: ν {einfach, mittel, komplex} Komplexitätsbewertung: Die Bewertung hinsichtlich der Komplexität ist abhängig davon, welcher Kategorie eine Funktion angehört. Der Komplexitätsgrad einer Funktion dieser Kategorie wird bestimmt durch die Anzahl der Informationseinheiten, die über die Funktion angesprochen werden. Version 1.03 / 6. Mai c H.-G. Hopf

19 4.3 Zählen von Funktionspunkten 4 FUNCTION POINT VERFAHREN zwingend erforderlich mindestens eine Aktion erforderlich Kategorie des Elementarprozesses EI EO EQ Aktionen der Verarbeitungslogik 1 Validierungen 2 Berechnungen 3 Umrechnungen 4 Auswahl oder Selektion von Daten 5 Überprüfen von Bedingungen 6 Aktualisieren von ILF s 7 Referenzieren von ILF s oder EIF s 8 Abfragen von Informationen 9 Ableitungen und Transformationen 10 Verändern des Systemverhaltens 11 Aufbereiten und Präsentieren von Informationen außerhalb der Systemgrenzen 12 Aufnahme von Eingabedaten von außerhalb der Systemgrenzen 13 Umsortieren von Daten Tabelle 10: Abgrenzung der Elementarprozesse EI, EO und EQ möglich verboten zwingend erforderlich mindestens eine Aktion erforderlich möglich verboten zwingend erforderlich mindestens eine Aktion erforderlich möglich verboten Version 1.03 / 6. Mai c H.-G. Hopf

20 4.3 Zählen von Funktionspunkten 4 FUNCTION POINT VERFAHREN Bestimmung des Komplexitätsgrades einer Funktionen der Kategorie interne / externe Dateizugriffe (ILF, EIF): Zwei Typen von Informationseinheiten werden unterschieden: Datenelementtypen (data element type DET) und Recordelementtypen (record element type RET). Bestimmung des Komplexitätsgrades einer Funktionen der Kategorie externe Eingaben / Ausgaben, Abfragen (EI, EO, EQ): Zwei Typen von Informationseinheiten werden unterschieden: Datenelementtypen (data element type DET) und Dateireferenzen (file types referenced FTR) Die Bestimmung der Komplexität wird über das Zählen von Informationseinheiten (DET, RET, FTR) realisiert. Die unterschiedlichen Typen von Informationseinheiten sollen kurz erläutert werden: Datenelementtypen (data element type DET): Ein DET ist ein für den Benutzer erkennbares, eindeutig bestimmbares, nicht wiederholtes Feld in einem ILF oder EIF Beispiel: Eine Adressangabe mit den Feldern Straße, Hausnummer, Postleitzahl, Stadt und Bundesland kann mit 6 DETs gezählt werden. Recordelementtypen (record element type RET) : Ein RET is eine vom Benutzer erkennbare Untergruppe von Datenelementen in einem ILF oder EIF. Es gibt zwei Ausprägungen von Recordelementtypen: DET RET Optionale Untergruppen: Der Benutzer hat die Wahl, ob er eine oder keine der Untergruppen im Elementarprozess benutzt. Obligatorische Untergruppen: Der Benutzer muss mindestens eine der Untergruppen im Elementarprozess benutzen. Beispiel: Information über Personen in den zwei Kategorien Angestellter und Kunde kann als 2 RETs gezählt werden. Dateireferenz (file type referenced FTR) : Die FTR-Zahl bezeichnet die Anzahl der externen und internen Datenbestände, die für die Abarbeitung einer Transaktion benötigt werden. Beispiel: Wenn eine Transaktion Daten aus zwei externen Datenquellen benötigt, als zwei externe Datenzugriffe nötig sind, wird der Wert von FTR auf 2 festgelegt. FTR Die mit einer Funktion verbundenen Informationselemente DET, RET bzw. FTR werden ermittelt. Man spricht vom Zählen der Informationselemente. Der Zählvorgang selbst ist durch ein Regelwerk festgelegt. Das Regelwerk enthält Hinweise zur Identifikation von Funktionsklassen EI, EO, EQ, ILF und Version 1.03 / 6. Mai c H.-G. Hopf

21 4.3 Zählen von Funktionspunkten 4 FUNCTION POINT VERFAHREN EI FTR ILF, EIF RET DET > 50 1 einfach einfach mittel 2-5 einfach mittel hoch > 5 mittel hoch hoch DET > einfach einfach mittel 2 einfach mittel hoch > 2 mittel hoch hoch EO, EQ FTR DET > einfach einfach mittel 2-3 einfach mittel hoch > 3 mittel hoch hoch Tabelle 11: Ermittlung des Komplexitätsgrades einer Funktion EIF. Weiter finden sich Anweisungen im Regelwerk, wie DET s, RET s und FTR s gezählt werden. Das Regelwerk ist im Abschnitt 4.6 in Tabellenform ausgeführt. Auf der Basis der DET, RET und FTR - Zählwerte kann die Bestimmung des Komplexitätsgrads einer Funktion gemäß der Tabelle 11 erfolgen. Zählregeln Bestimmung der Funktionspunkte einer Funktion Der einer Funktion zugeordnete Funktionspunkte-Wert γ(k, ν) ist abhängig von Funktionspunktewert der Funktionskategorie (function category - k) und dem Komplexitätsgrad (complexity - ν) Je nach Zugehörigkeit einer Funktion zu einer Funktionskategorie und gemaß ermitteltem Komplexitätsgrad ergibt sich ein Funktionspunkte-Wert (function points) gemäß der Tabelle 12. Funktionspunkte-Basiswert γ(k, ν) Komplexitätsgrad ν Funktionskategorie k ILF EIF EI EO EQ einfach mittel hoch Tabelle 12: Funktionspunkte-Basiswert für Funktionen verschiedener Kategorien und unterschiedlicher Komplexitätsgrade Bestimmung der Funktionspunkte für die gesamte Anwendung Die Gesamtgröße der Anwendung in Funktionspunkten (unadjusted function points) ergibt sich, wenn alle Funktionen in oben angegebener Weise bewer- Version 1.03 / 6. Mai c H.-G. Hopf

22 4.4 Projektspezifische Anpassung 4 FUNCTION POINT VERFAHREN tet berücksichtigt werden. UFP = k=ei, EO, EQ, ILF, EIF ν=einfach, mittel, komplex k: Funktionskategorie ν: Komplexitätsgrad n(k, ν) γ(k, ν) n(k, ν): Anzahl der Funktionen der Kategorie k mit dem Komplexitätsgrad ν γ(k, ν): Funktionspunkte-Basiswert einer Funktionen der Kategorie k mit dem Komplexitätsgrad ν. Bemerkung: Anstelle von UFP (unadjusted function points) findet sich in der Literatur auch manchmal die Bezeichnung UFC (unadjusted function counts) oder nur FP (function points). 4.4 Projektspezifische Anpassung Bestimmung von anwendungsbezogenen Korrekturfaktoren 1. Korrekturfaktoren: Die qualitativen Anforderungen durch die Verschiedenheit der Anwendungen wird durch 14 Korrekturfaktoren parametrisiert. Die Korrekturfaktoren beziehen sich auf die in Tabelle 13 zusammengestellte Anwendungs-Aspekte: projektspezifische Anpassungen C 1 C 2 C 3 C 4 C 5 C 6 C 7 C 8 C 9 C 10 C 11 C 12 C 13 C 14 Anwendungs-Aspekte Datenkommunikation mit externen Programmen (data communications) Verteilte Verarbeitung (distributed functions) Leistungsfähigkeit, Leistungsanforderungen durch den Kunden (performance objectives) Begrenzte Kapazität, hohe Anforderung durch die Benutzer der Applikation (heavily used configuration) Hohe Anforderung an die Durchsatzrate der Daten (transaction rate) interaktive Benutzung / Dateneingabe (on line data entry) Benutzerfreundlichkeit (end user efficiency) Interaktive Datenänderung (on line update) komplexe interne Verarbeitung (complex processing) Wiederverwendbarkeit (reusability) Anforderung an die Benutzerfreundlichkeit der Programminstallation (installation ease) Betriebshilfen (operational ease) Mehrfachinstallationen (multiple sites) Änderungsfreundlichkeit (facilitate change) Tabelle 13: Anwendungsaspekte Version 1.03 / 6. Mai c H.-G. Hopf

23 4.4 Projektspezifische Anpassung 4 FUNCTION POINT VERFAHREN 2. Gewichtung: Die einzelnen Anwendungs-Aspekte gehen projektspezifisch gewichtet ein. Für die Ausprägung eines Korrekturfaktors (degree of influence - DI) steht der Wertebereich 0-5 zur Verfügung; Wert Korrekturfaktor DI Einfluß des Anwendungs-Aspekts 0 keiner oder vernachlässigbar (not present) 1 unbedeutend (insignificant) 2 gering (moderate) 3 durchschnittlich (average) 4 signifikant (significant) 5 stark (strong) Tabelle 14: Korrekturfaktoren 3. Bestimmung des technischen Komplexitätsfaktors Aus der Summe der Korrekturfaktorwerte wird ein technischer Komplexitätsfaktor (technical complexity factor - TCF) oder auch VAF (value adjustment factor) gemäß der Formel ermittelt: TCF = VAF = i=1 DI(C i ) Sind alle Korrekturfaktoren ohne Einfluß ( C i = 0 für 1 i 14) ergibt sich für TCF der Wert 0.65 TCF min = 0.65 Wird für alle Korrekturfaktoren maximaler Einfluß ( C i = 5 für 1 i 14) festgestellt, ergibt sich für TCF der Wert 1.35 TCF max = = 1.35 Über den technischen Korrekturfaktor kann demnach der ursprüngliche Funktionspunktewert als um +/- 35% korrigiert werden Berechnung der korrigierten Funktionspunkte (adjusted function points) Die anwendungsbezogen korrigierte Anzahl der Function Points (adjusted function points) ermittelt sich zu: CFP(ν) = UFP(ν) TCF Version 1.03 / 6. Mai c H.-G. Hopf

24 4.5 Beispiel: Berechnung 4 FUNCTION POINT VERFAHREN Kunde 1 Anzeige 2 Bestätigung Bestellung Angebotener Rechnung von Artikeln 3 Artikel Bestellung online 7 8 Erfassen von Artikeldaten Pflegen von Artikeldaten 9 Bestelldaten Kundendaten Artikeldaten Anzeige von Artikeldaten Kundenbezogene Umsatzstatistik 10 Artikelbezogene Umsatzstatistik Erfassen von Kundendaten 13 Pflegen von Kundendaten Anzeigen von Kundendaten Hersteller - Datenbank 15 Sachbearbeiter Abbildung 4: Artikelverwaltung für online-bestellungen 4.5 Beispiel: Anwendung der Berechnungsformeln Kunden können Artikel über eine online-anwendung Artikel bestellen. Ein Programm ONLINE BESTELLUNG zur Verwaltung des Artikelangebots der Firma Ohm-Marketing und der eingehenden Bestellungen ist spezifiziert wie in Abbildung 4 angegeben. Es wird vorausgesetzt, dass alle Funktionen mittleren Komplexitätsgrad besitzen. Mit dieser Angabe entfällt das mühsame Auswerten von DET s, RET s und FTR s. Für anwendungsbezogene Korrekturfaktoren wird angenomment: 6 Einflussfaktoren sind vernachlässigbar, 6 weitere Einflussfaktoren haben durchschnittliches Gewicht und 2 Einflussfaktoren haben starken Einfluss. 1. Bestimmung von Funktionskategorie und Komplexitätsgrad Eine Zusammenstellung der Programmdaten und -funktionen findet sich in Tabelle 15. Die Klassifikation der einzelnen Funktionen, die Feststellung des Komplexitätsgrades und die ermittelten unadjusted function points UFP s ist in der Tabelle angegeben. 2. Anzahl der Function Points (unadjusted function points) UFP: Version 1.03 / 6. Mai c H.-G. Hopf

25 4.5 Beispiel: Berechnung 4 FUNCTION POINT VERFAHREN Funktion / Daten Kate- Schwierig- UFPgorie keitsgrad Wert (6) Kundendaten: Informationen über Kunden, Adressen, ILF mittel 10 Bankverbindung,... (14) Erfassen von Kundendaten EI mittel 4 (13) Pflegen von Kundendaten EI mittel 4 (12) Anzeigen von Kundendaten EQ mittel 4 (4) Artikeldaten: Artikelnummer, Beschreibung, Preis,... ILF mittel 10 (15) Informationen über Hersteller von Artikeln aus externer EIF mittel 7 Herstellerdatenbank (7) Erfassen von Artikeldaten EI mittel 4 (8) Pflegen von Artikeldaten EI mittel 4 (9) Anzeige von Artikeldaten (Übersicht) EQ mittel 4 (1) Anzeige der online angebotenen Artikel EQ mittel 4 (5) Bestelldaten: Informationen über Bestellung von Artikeln ILF mittel 10 durch Kunden (3) Bestellen von ausgewählten Artikeln EI mittel 4 (2) Bestellbestätigung und Rechnung für Kunden (berechneter EO mittel 5 Warenwert inklusive Mehrwertsteuer) (11) Ausgabe einer berechneten artikelbezogenen Umsatzstatistik EO mittel 5 für spezifizierten Zeitraum (10) Ausgabe einer berechneten kundenbezogenen Umsatzstatistik für spezifizierten Zeitraum EO mittel 5 84 Tabelle 15: Daten- und Funktionsliste Version 1.03 / 6. Mai c H.-G. Hopf

26 4.5 Beispiel: Berechnung 4 FUNCTION POINT VERFAHREN Der Tabelle 15 kann man entnehmen: Anzahl EI Funktionen: 5, Anzahl EO Funktionen: 3, Anzahl EQ Funktionen: 3, Anzahl ILF Funktionen: 3, Anzahl EIF Funktionen: 1. Mit den in Tabelle 12 hinterlegten Basisfunktionspunktewerten für mittleren Komplexitätsgrad kann der Funktionspunktebeitrag für jede Kategorie ermittelt werden. Die UFP-Werte der einzelnen Funktionen summiert sich zum Wert 84. UFP = n(k, ν) γ(k, ν) k=ei, EO, EQ, ILF, EIF ν=einfach, mittel, komplex = = Technischer Komplexitätsfaktor (technical complexity factor) TCF bzw. Anpassungsfaktor (value adjustment factor)vaf: Für anwendungsbezogene Korrekturfaktoren gilt: 2 Einflussfaktoren haben starken Einfluss, 6 weitere Einflussfaktoren haben durchschnittliches Gewicht und die restlichen Einflussfaktoren sind vernachlässigbar. Mit dieser Angabe berechnet sich der TCF zu: 14 TCF = = DI(C i ) i=1 = ( ) = Anzahl der korrigierten Function Points (corrected function points) CFP: Aus dem Funktionpoint-Wert 84 und dem Anpassungsfaktor 0.93 berechnet sich der Wert für die korrigierten Funktionpoints: CFP = UFP TCF = = Version 1.03 / 6. Mai c H.-G. Hopf

27 4.6 Function Point Zählregelwerk 4 FUNCTION POINT VERFAHREN 4.6 Function Point Zählregelwerk Das im folgenden dargestellte Regelwerk zur Ermittlung von function point - Werten ist [IFP04] entnommen. Die Bewertung von Datenbeständen bzw. Transaktionen beginnt mit der Festlegung der jeweils vorliegenden Funktionskategorie. Das Regelwerk stellt Kriterien zur Verfügung, die die Identifikation der vorliegenden Funktionskategorie ermöglichen. In einem zweiten Schritt werden dann Bestimmungsregeln für die Informationselemente DET und RET einerseits bzw. DET und FTR andererseits aufgestellt. Die nachfolgenden Tabellen enthalten die Kriterien in einer kompakten Form. Version 1.03 / 6. Mai c H.-G. Hopf

28 4.6 Function Point Zählregelwerk 4 FUNCTION POINT VERFAHREN Bewertung der Datenbestände ILF EIF ILF/EIF- Identifikationsregeln Die Gruppe von Informationen (Daten bzw. Kontrolldaten) ist identifizierbar, d.h. die Gruppe von Daten oder Steuerungsinformationen ist eine logisch zusammengehörige Gruppe von Informationen, die zur Erfüllung bestimmter Benutzeranforderungen benötigt wird Ein Datenbestand muss allen folgenden Regeln genügen Die Gruppe von Informationen wird durch einen Elementarprozess innerhalb der Grenzen der Anwendung gepflegt. Die Gruppe von Informationen wird in der Anwendung referenziert, kommt aber von außerhalb der Systemgrenze. Die Gruppe von Informationen wird nicht in der Anwendung gepflegt. Die Gruppe von Informationen wird in wenigstens einer anderen Anwendung als ILF gezählt. DET Definition Ein Datenelementtyp (DET) ist ein aus Benutzersicht betrachtet eindeutig bestimmtes, nicht wiederholtes Feld. DET Zählregeln Gezählt wird ein DET für jedes aus Benutzersicht betrachtet eindeutig bestimmtes, nicht wiederholtes Feld in dem ILF oder EIF, das durch einen Elementarprozess abgefragt oder gepflegt wird. Wenn zwei Anwendungen dieselben ILF s oder EIF s referenzieren oder pflegen, aber jede Anwendung verschiedene oder verschiedenartig DET s referenziert, werden nur jeweils die DET s gezählt, die von der Anwendung benutzt werden. Gezählt wird ein DET für jedes Datenfeld, das vom Benutzer gefordert wurde, um eine Beziehung mit einer anderen ILF oder EIF einzugehen (Fremdschlüssel). RET Definition Ein Record Element Typ (RET) ist eine vom Benutzer erkennbare Untergruppe von Datenelementen in einem ILF oder EIF. RET Zählregeln Auswahl einer Regel Gezählt wird ein RET für jede obligatorische oder optionale Untergruppe von Informationen in dem ILF oder EIF. Gezählt wird ein RET für das gesamte ILF oder EIF, wenn es keine Untergruppe gibt. Version 1.03 / 6. Mai c H.-G. Hopf

29 4.6 Function Point Zählregelwerk 4 FUNCTION POINT VERFAHREN Bewertung der Transaktionen EI EO EQ EI/EO/EQ- Identifikationsregeln Die Daten einer Transaktion müssen allen folgenden Regeln genügen Bei einem EI ist die primäre Absicht des Elementarprozesses, eine ILF zu pflegen oder das Systemverhalten zu ändern. Die Daten oder Kontrollinformationen kommen von außerhalb der Systemgrenze. Die Daten in mindestens einer ILF werden gepflegt, falls die Daten nicht aus Kontrollinformationen bestehen, die das Systemverhalten ändern. Bei einem EO oder EQ ist die primäre Absicht des Elementarprozesses, dem Anwender Informationen zu präsentieren. Die Transaktion schickt Daten oder Steuerungsinformation nach außerhalb der Systemgrenze. Mindestens eine der drei folgenden Bedingungen muss für die Transaktion zutreffen: Die Verarbeitungslogik unterscheidet sich von der anderer EI s, EO s oder EQ s der Anwendung. Die identifizierten Datenelemente unterscheiden sich von denen anderer EI s, EO s oder EQ s der Anwendung. Die referenzierten ILF s bzw EIF s unterscheiden sich von denen anderer EI s, EO s oder EQ s der Anwendung. Zusätzlich müssen folgende Regeln erfüllt sein: Ein EO muss mindestens eine der folgenden Regeln erfüllen: Die Verarbeitungslogik des Elementarprozesses enthält mindestens eine Berechnung (mathematische Formel). erzeugt abgeleitete Daten (Transformationen). pflegt mindestens ein ILF. ändert das Systemverhalten. Ein EQ muss alle der folgenden Regeln erfüllen: Die Verarbeitungslogik des Elementarprozesses fragt Daten oder Kontrollinformationen in einem ILF oder EIF ab. enthält keine Berechnung (mathematische Formel). erzeugt keine abgeleiten Daten (Transformationen). pflegt keine ILF. ändert das Systemverhalten nicht. Version 1.03 / 6. Mai c H.-G. Hopf

30 4.6 Function Point Zählregelwerk 4 FUNCTION POINT VERFAHREN Bewertung der Transaktionen EI EO EQ FTR Definition Eine File Type Referenz ist: ein in einem Elementarprozess gelesener oder gepflegter ILF -Datensatz. ein in einem Elementarprozess gelesener EIF -Datensatz. FTR Zählregeln Gezählt wird ein FTR für jedes ILF, das während der Verarbeitung des EI bzw. EO gepflegt wird. Gezählt wird ein FTR für jedes ILF oder EIF, die während der Verarbeitung des EI, EO oder der EQ gelesen wird. Gezählt wird nur ein FTR für jedes ILF, das während der Verarbeitung des EI bzw. EO sowohl gepflegt als auch gelesen wird. Version 1.03 / 6. Mai c H.-G. Hopf

31 4.6 Function Point Zählregelwerk 4 FUNCTION POINT VERFAHREN Bewertung der Transaktionen EI EO EQ DET Definition Ein Datenelementtyp (DET) ist ein aus Benutzersicht betrachtet eindeutig bestimmtes, nicht wiederholtes Feld. DET Zählregeln: Gezählt wird ein DET für jedes aus Benutzersicht betrachtet nicht wiederholtes Feld, das die Systemgrenze kreuzt und gebraucht wird, um den EI Elementarprozess abzuschließen. Gezählt wird ein DET für ein aus Benutzersicht betrachtet eindeutig bestimmtes, nicht wiederholtes Feld, das über die Systemgrenze in die Anwendung kommt und bestimmt, wann, was und/oder wie die Daten durch den Elementarprozess abgefragt oder zusammengestellt werden. Gezählt wird ein DET für jedes aus Benutzersicht betrachtet nicht wiedeholtes Feld, das die Systemgrenzen verlässt. Wenn ein DET das System verlässt und hereinkommt, wird es nur einmal für den Elementarprozess gezählt. Gezählt werden keine Felder, die durch das System abgefragt, abgeleitet und/oder in einem ILF gespeichert werden, wenn die Daten nicht die Systemgrenze kreuzten. Gezählt wird ein DET für eine mögliche Systemmitteilung an den Benutzer (Fehlermeldung, Mitteilung über erfolgreiche Beendigung, Hinweis auf Fortsetzung). Gezählt wird nur ein DET für die Möglichkeit, eine Aktion auszuwählen, auch wenn es mehrere Aktivierungsmöglichkeiten für diese Aktion gibt. Gezählt als DET werden keine konstanten Felder (Literale). Gezählt wird kein DET für Seitenzähler oder systemgenerierte Angaben, z.b. Systemvariable (Datum, Zeit, Seite x von xx). Version 1.03 / 6. Mai c H.-G. Hopf

32 4.7 Beispiel: Zählregeln 4 FUNCTION POINT VERFAHREN 4.7 Beispiel: Anwendung der Zählregeln Diesem Beispiel liegt eine Web-Anwendung für den Bereich Studienverwaltung zugrunde. Diese Anwendung stellt Informationen über die persönlichen Daten von Studenten in einer Tabelle Student zur Verfügung. Weiter werden für mehrere Studiengänge die in den einzelnen Fachsemestern (1. Semester, 2. Semester,... ) vorgesehenen (prüfungsrelevanten) Fächer angegeben (Tabelle Fach). Studenten sind einem Studiengang zugeordnet und legen in den entsprechenden Fächern Prüfungen ab. Das Zeitsemester (SS 2005, WS2005/06,... ) in dem der Student an der Prüfung teilnimmt und die erzielte Note werden erfasst (Tabelle legt Pruefung ab). Tabelle Attribute Student Matrikelnummer, Name, Vorname, Geburtsdatum, Geburtsort, Anrede, Familienstand, Studiengang, Bemerkung, Passwort Fach Fachbezeichnung, Studiengang, Fachsemester, Prüfungstyp legt Pruefung ab Matrikelnummer, Fachbezeichnung, Studiengang, Note, Zeitsemester Die Masken der Web-Anwendung sind alle nach dem Muster der Abbildung 5 aufgebaut. Eine Maske enthält neben dem Logo und der Angabe der über diese Maske erreichbaren Programmfunktion noch Navigationselemente und weiter die Angabe des Systemdatums und einer Zeile für Systemmitteilungen. Systemmitteilungen informieren über den erfolgreichen Abschluss einer Programmfunktion, geben im Bedarfsfall Hinweise für die weitere Programmausführung oder informieren über aufgetretene Fehler. Der grau markierte Bereich bleibt dann den spezifischen Erfordernissen der aktuellen Programmfunktion Im Folgenden sollen ausgewählte Funktionen der WebAnwendung betrachtet werden. Version 1.03 / 6. Mai c H.-G. Hopf