Interne Produktattribute
Interne Produktattribute beschreiben die Softwareprodukte auf eine Weise, die nur vom Produkt selbst abhängig ist. Der Hauptgrund für die Messung interner Produktattribute besteht darin, dass die Produkte während der Entwicklung überwacht und gesteuert werden können.
Messung interner Produktattribute
Die wichtigsten internen Produktattribute umfassen size und structure. Die Größe kann statisch gemessen werden, ohne dass sie ausgeführt werden muss. Die Größe des Produkts gibt Auskunft über den Aufwand, der für die Erstellung erforderlich ist. Ebenso spielt die Struktur des Produkts eine wichtige Rolle bei der Gestaltung der Wartung des Produkts.
Größe messen
Die Softwaregröße kann mit drei Attributen beschrieben werden:
Length - Es ist die physische Größe des Produkts.
Functionality - Es beschreibt die Funktionen, die das Produkt dem Benutzer bietet.
Complexity - Komplexität ist von unterschiedlicher Art, wie z.
Problem complexity - Misst die Komplexität des zugrunde liegenden Problems.
Algorithmic complexity - Misst die Komplexität des zur Lösung des Problems implementierten Algorithmus
Structural complexity - Misst die Struktur der Software, die zur Implementierung des Algorithmus verwendet wird.
Cognitive complexity - Misst den Aufwand, der zum Verständnis der Software erforderlich ist.
Die Messung dieser drei Attribute kann wie folgt beschrieben werden:
Länge
Es gibt drei Entwicklungsprodukte, deren Größenmessung nützlich ist, um den für die Vorhersage erforderlichen Aufwand vorherzusagen. Sie sind Spezifikation, Design und Code.
Spezifikation und Design
Diese Dokumente kombinieren normalerweise Text, Grafiken und spezielle mathematische Diagramme und Symbole. Die Spezifikationsmessung kann verwendet werden, um die Länge des Entwurfs vorherzusagen, was wiederum ein Prädiktor für die Codelänge ist.
Die Diagramme in den Dokumenten haben eine einheitliche Syntax, z. B. beschriftete Digraphen, Datenflussdiagramme oder Z-Schemata. Da Spezifikations- und Konstruktionsdokumente aus Texten und Diagrammen bestehen, kann ihre Länge anhand eines Zahlenpaars gemessen werden, das die Textlänge und die Diagrammlänge darstellt.
Für diese Messungen sind die Atomobjekte für verschiedene Arten von Diagrammen und Symbolen zu definieren.
Die atomaren Objekte für Datenflussdiagramme sind Prozesse, externe Entitäten, Datenspeicher und Datenflüsse. Die atomaren Einheiten für algebraische Spezifikationen sind Sortierungen, Funktionen, Operationen und Axiome. Die atomaren Einheiten für Z-Schemata sind die verschiedenen Linien, die in der Spezifikation erscheinen.
Code
Code kann auf verschiedene Arten erzeugt werden, wie z. B. prozedurale Sprache, Objektorientierung und visuelle Programmierung. Das am häufigsten verwendete traditionelle Maß für die Länge des Quellcode-Programms sind die Lines of Code (LOC).
Die Gesamtlänge,
LOC = NCLOC + CLOC
dh
LOC = Non-commented LOC + Commented LOC
Neben der Codezeile können auch andere Alternativen wie die von Maurice Halsted vorgeschlagene Größe und Komplexität zur Messung der Länge verwendet werden.
Halsteads Software-Wissenschaft versuchte, verschiedene Attribute eines Programms zu erfassen. Er schlug drei interne Programmattribute wie Länge, Wortschatz und Volumen vor, die unterschiedliche Ansichten der Größe widerspiegeln.
Er begann mit der Definition eines Programms Pals eine Sammlung von Token, die von Operatoren oder Operanden klassifiziert werden. Die grundlegenden Metriken für diese Token waren:
μ1 = Anzahl der eindeutigen Operatoren
μ2 = Anzahl der eindeutigen Operanden
N1 = Gesamtzahl der Operatoren
N2 = Anzahl der eindeutigen Operatoren
Die Länge P kann definiert werden als
$$ N = N_ {1} + N_ {2} $$
Der Wortschatz von P ist
$$ \ mu = \ mu _ {1} + \ mu _ {2} $$
Das Programmvolumen = Anzahl der mentalen Vergleiche, die zum Schreiben eines Längenprogramms erforderlich sind Nist
$$ V = N \ times {log_ {2}} \ mu $$
Die Programmebene eines Programms P des Volumens V ist,
$$ L = \ frac {V ^ \ ast} {V} $$
Wobei $ V ^ \ ast $ das potentielle Volumen ist, dh das Volumen der Implementierung mit minimaler Größe von P
Die Umkehrung des Niveaus ist die Schwierigkeit -
$$ D = 1 \ diagup L $$
Nach der Halstead-Theorie können wir eine Schätzung berechnen L wie
$$ {L} '= 1 \ diagup D = \ frac {2} {\ mu_ {1}} \ times \ frac {\ mu_ {2}} {N_ {2}} $$
In ähnlicher Weise beträgt die geschätzte Programmlänge $ \ mu_ {1} \ mal log_ {2} \ mu_ {1} + \ mu_ {2} \ mal log_ {2} \ mu_ {2} $
Der Aufwand zur Erzeugung von P ist gegeben durch:
$$ E = V \ diagup L = \ frac {\ mu_ {1} N_ {2} Nlog_ {2} \ mu} {2 \ mu_ {2}} $$
Wo die Maßeinheit E ist elementare mentale Diskriminierung erforderlich, um zu verstehen P
Die anderen Alternativen zur Längenmessung sind -
In Bezug auf die Anzahl der für den Programmtext erforderlichen Bytes an Computerspeicher
In Bezug auf die Anzahl der Zeichen im Programmtext
Die objektorientierte Entwicklung schlägt neue Wege zur Längenmessung vor. Pfleeger et al. fanden heraus, dass eine Anzahl von Objekten und Methoden zu genaueren Produktivitätsschätzungen führte als diejenigen, die Codezeilen verwendeten.
Funktionalität
Der Umfang der einem Produkt innewohnenden Funktionalität gibt das Maß für die Produktgröße an. Es gibt so viele verschiedene Methoden, um die Funktionalität von Softwareprodukten zu messen. Wir werden eine solche Methode - die Albrechtsche Funktionspunktmethode - im nächsten Kapitel diskutieren.