SESAM Modelle

Im folgenden Abschnitt werden einige Modelle vorgestellt. Wir besprechen den Modellierungsansatz, die grundlegenden Modell Annahmen, und die verwendeten Metriken.

QA-Modell

Zunächst wird das Qualitätssicherung Modell (Quality Assurance model = QA Modell) vorgestellt. Wir besprechen den Modellierungsansatz, die grundlegenden Modell Annahmen, und die verwendeten Metriken.

Ziele und Modell-Anforderungen

Die Entwicklung des QA Modells ist von einer Anforderungsanalyse aus unterschiedlichen Perspektiven vorangegangen worden. Ein Resultat dieser Aufgabe war die Ableitung der folgenden grundlegenden Ziele.

• Das Modell sollte flexibel sein, damit die Resultate der unterschiedlichen Managementansätze verglichen werden können. Kursteilnehmer sollten ihre eigenen Lösungen zu einem gegebenen Managementproblem entwickeln, anstatt nach einem vorbestimmten Kurs des Projektes vorzugehen.
• Das Modell sollte feingranular sein. Die Kommandos, die das Simulationsmodell akzeptiert, sollten jenen Tätigkeiten ähneln, die ein Projektmanager in der Wirklichkeit ausüben würde. So kann die Erfahrung, die während der Simulation gewonnen wird, auf reale Projekte übertragen werden.
• Das Modell sollte alle Phasen der Software-Entwicklung abdecken. Besonders in den späten Phasen eines Software-Projektes, können und werden bedeutende Mängel oder Fehler aufgedeckt. Kursteilnehmer sollten mit diesen ernsten Problemen konfrontiert werden. Erst nachdem sie auf diese Schwierigkeiten gestoßen sind, haben sie eine Chance, sie in den realen Projekten zu vermeiden.
• Das Modell sollte durch empirische Daten unterstützt werden. Quantitative Simulation der Software-Projekte ist auch ein Weg, "typische" industrielle Daten zu übermitteln. Dadurch kann eine erste Erfahrungsgrundlage für zukünftige Projektmanager geschaffen werden.

Vorstudien innerhalb des SESAM Projektes erwiesen es als schwierig, ein Universalmodell zu entwickeln, das für jedes Software-Projekt geeignet ist, unabhängig von seiner Größe oder Zielsetzung. Somit ist der Geltungsbereich des QA Modells auf eine spezifische Kategorie von Software-Projekte eingeschränkt worden. Diese Entscheidung half, die wichtigsten Tätigkeiten, die durch das Modell zur Verfügung gestellt werden sollten, auszuwählen. Zusätzlich kann die Quantifikation des Modells spezifisch auf die selektierte Projektkategorie zugeschnitten werden.

Das QA Modell konzentriert sich auf kleine bis mittlere Software-Projekte, die unter einem Vertrag zwischen einem Kunden und einem Lieferanten entwickelt werden (z.B. eine externe Softwarefirma). Das QA Modell umfasst alle Entwicklungsaktivitäten angefangen mit der Anforderungsspezifikation bis hin zur Produktlieferung. Software-Entwicklung kann durch Qualitätssicherungstätigkeiten unterstützt werden. Das QA Modell umfasst Reviews aller Dokumente sowie unterschiedliche Testarten. Alle diese unterschiedlichen Aufgaben können einzelnen simulierten Entwicklern zugewiesen werden.

Modell Annahmen

SESAM Modelle enthalten ein Teil der bekannten Effekte in den Software-Projekten. Um eine solide Grundlage für den Modell-Erstellungsprozess zu erschaffen, wurden diese Effekte zuerst gesammelt. Das Wissen und die Annahmen, die im QA Modell zusammengefasst sind, stammen hauptsächlich aus der Software-Engineering-Literatur und von Experten. Die Literaturrecherche konzentrierte sich besonders auf empirische Studien. Die Resultate dieser Studien halfen, die Ursache und die Effekt-Verhältnisse in einer quantitativen Weise zu beschreiben. Jedoch deckte die Forschung auch einige "Wissenslücken" auf. Wo notwendig, sind diese Lücken durch Hypothesen ausgefüllt worden. Einige wichtige Modell Annahmen werden jetzt besprochen.

1. Die Produktivität des einzelnen Entwicklers sinkt, während die Größe des Projektteams wächst; da eine wachsende Zeitmenge für Kommunikation verbraucht wird (z.B. in Sitzungen). Brooks (1974) demonstrierte diese Korrelation zuerst.
2. Fähigkeiten und Erfahrungen der Entwickler beeinflussen grundlegend ihre Produktivität sowie die Qualität der Resultate, die sie produzieren (Sackman, 1968). Dieser Effekt wird auch in den unterschiedlichen Kostenschätzungsmethoden, z.B. COCOMO (Boehm, 1981) reflektiert.
3. Vollständigkeit und Qualität der Software hängt von den Resultaten ab, die in früheren Entwicklungsphasen produziert wurden. Je mehr Fehler ein Dokument von einer früheren Phase enthält, desto mehr Fehler werden in das folgende Dokument übertragen.
4. Reviews ermöglichen, Fehler frühzeitig im Entwicklungsprozess zu finden. Vollständigkeit und Korrektheit der Referenzdokumente bestimmen erheblich die Effektivität des Reviews. Außerdem, gibt es andere relevante Faktoren wie Reviewerfahrung des Entwicklers oder der Aufwand für die Vorbereitung des Reviews( Weller, 1993; Porter, 1997).
5. Tests enthüllen Fehler im Code. Je besser ein Test vorbereitet wurde, desto mehr Fehler werden gefunden. Ein Code-and-Fix Entwicklungsansatz macht eine Testvorbereitung unmöglich( Pressman, 1997).
6. Je später ein Fehler, der früh im Entwicklungsprozess eingeführt wurde, aufgedeckt wird, desto höher sind die Kosten, um diesen Fehler zu beheben (Ludewig, 1995; Möller, 1993).

Modellierungskonzepte und Metriken

Die selektierten dynamischen Effekte müssen im Simulationsmodell dargestellt werden. Folglich müssen relevante Entitäten identifiziert und weiter durch Attribute beschrieben werden. Die Definition eines kohärenten Metriksystems erlaubt dann Änderungen des aktuellen Projektzustandes in einer überwiegend quantitativen Weise zu reflektieren.

Der grundlegende Ansatz, der für das QA-Modell genommen wird, besteht aus der Modellierung von Dokumenten und Entwicklern. Entwickler produzieren oder überprüfen oder verbessern unterschiedliche Arten von Software abhängig von der Aufgabe, die vom Projektmanager zugewiesen wird. Wenn sie Software produzieren, müssen Entwickler Kundenanforderungen erkennen, umsetzen und dokumentieren.

Dokumente

Die Software, die während des simulierten Projektes produziert wird, zeichnet sich durch ihren Inhalt, ihre Größe und ihre Qualität aus. Der Inhalt der Software wird durch Anforderungen modelliert. Diese Anforderungen werden mit der Function Point Methode (IFPUG, 1994) gemessen. Dieser Ansatz ermöglicht von einer spezifischen Projektaufgabe zu abstrahieren, während die simulierten Resultate quantitativ ausgewertet werden können. Die Metrik ist abstrakt genug, um für alle Software-Arten, die während eines Projektes produziert werden, anwendbar zu sein. So könnte ein einheitlicher Ansatz für das Modellieren von unterschiedlichen Dokumentarten gewählt werden.

Die Größe eines Dokumentes wird in Anzahl Seiten beziehungsweise Anzahl Lines of Code ausgedrückt. Die Größe wird von der Anzahl der Adjusted Function Point (AFP), die in einem Dokument enthalten sind, abgeleitet. Dabei werden die Sprachen oder die Notationen, die in dem jeweiligen Dokument benutzt werden, beachtet. Die Qualität eines Dokumentes wird primär charakterisiert, indem man Fehler den Anforderungen zuweist, die in einem Dokument enthalten sind. Wir unterscheiden Analyse-, Entwurf-, Codierungs- und Dokumentationsfehler um sich auf die Zeit des Fehlereintritts zu konzentrieren. Das Modellieren der Qualität der Dokumente wird ergänzt, indem man weitere individuelle Qualitätsattribute (wie Lesbarkeit) wo notwendig festsetzt.

Entwickler

Entwickler sind die wichtigste Ressource in den Software-Projekten. Ihr Wissen und ihre Erfahrungen beeinflussen erheblich die Projektergebnisse. Infolgedessen konzentriert sich die Beschreibung der Entwickler im QA Modell auch auf ihre Fähigkeiten. Zuerst sind die Erfahrungen der Entwickler hinsichtlich der unterschiedlichen Aufgaben (z.B. spezifizieren, codieren oder reviewen) an einer Ordinal Skala (no/low/average/high) geschätzt. Zweitens werden die Fähigkeiten betreffend verschiedene Notationen und Sprachen ausgewertet. Auf diese Art wird ein ausführliches einzelnes Profil jedes simulierten Entwicklers konstruiert.

Die unterschiedlichen Modell Elemente werden dann dynamisch kombiniert. Wenn z.B. ein Entwickler aufgefordert wird, das System zu entwerfen, sucht er oder sie nach einem Referenzdokument, z.B. die Spezifikation. Diese Informationen werden als Grundlage genommen und werden in den Systementwurf abhängig von den einzelnen Fähigkeiten übertragen. Im QA Modell wird diese Software-Produktionsaufgabe durch die folgenden drei Attribute beschrieben: die Produktivitätsrate (AFP/hour), die Fehlerrate (Anzahl von Fehler/AFP) und die Verlustquote (% [ AFP ]). Software-Prüfung und -Korrektur wird in einer ähnlichen Weise modelliert. Jedoch erlauben diese Aktivitäten Fehler zu ermitteln und entfernen, anstatt, neue Fehler einzuführen.

Schließlich wird der aktuelle Entwicklungsprozess durch Kosten, Aufwand und Dauer characterisiert.

Modell Parametrisierung

SESAM Modelle streben an, Wirklichkeit so nah wie möglich zu reflektieren. Infolgedessen müssen Modelle durch empirische Daten unterstützt werden. Leider wird die Parametrisierung der Modelle durch die folgenden Tatsachen erschwert. (1) umfangreiche Modelle umfassen eine Anzahl von unterschiedlichen Aspekten. Diese Modelle werden am besten mit einer einzigen Datenquelle quantifiziert. Jedoch umfassen nur sehr wenige publizierte empirische Untersuchungen eine Anzahl von Aspekten auf einer breiten statistischen Grundlage. (2) feingranulare Modelle benötigen feingranulares Datenmaterial. Ausführliche quantitative Informationen erfüllen z.Z. nicht die Anforderung (1). (3) um sicherzugehen, dass das Datenmaterial zum Modell "passt", sollten die Metriken, die für die Datenerfassung definiert werden, dieselben sein wie die, die im Modell verwendet werden.

Um diese Schwierigkeiten zu verringern, wurde das Datenmaterial für die Quantifizierung des QA Modells sehr früh im Modell-Entwicklungsprozess gesammelt. Dieses bot die Chance an, jene Aspekte der Software-Entwicklung auszuwählen, die durch empirische Daten unterstützt werden und die Metrik Definitionen , die für die Datenerfassung benutzt werden, zu denen, die im Modell verwendet werden, passend machen. Trotz dieses Ansatzes, gibt es immer noch eine Anzahl von Modell Aspekten, die nicht durch empirische Daten aufgefangen werden können. Beispiele sind der Einfluss, den bestimmte Programmiersprachen auf dem Prozess ausüben oder der Einfluss der neuen Entwicklungsansätzen und Techniken auf die gesamten Projektergebnissen. Folglich wird Quantifizierung des QA Modells durch geschätzte Parameter, die validiert werden müssen solange empirischere Daten vorhanden sind, ergänzt.

Ein bedeutender Part der Ursache und Effekt-Beziehungen, die im QA Modell umfasst werden, wird quantitativ durch die Daten unterstützt, die in Jones (1996) bereitgestellt werden. Diese Daten enstammen der Beobachtung eines breiten Bereichs von Software-Projekte, die sich weiter durch ihre Projektkategorie unterscheiden. Alle Produktivitätinformationen werden auf einer Function Point-Grundlage ausgedrückt und zusätzlich gegeben für einzelne Aktivitäten. Zusätzlich stellt Jones (1996) Datenmaterial hinsichtlich Fehler, Kosten und Dauer zur Verfügung. Wo notwendig, sind andere Untersuchungen in Erwägung, z.B. Weller (1993) oder Porter (1997) gezogen worden.

Quellenangabe

Boehm (1981) Boehm, B. W.: Software Engineering Economics. Prentice Hall (Englewood Cliffs), 1981

Brooks (1975) Brooks, F.P.: The Mythical Man-Month. Datamation, Dec. 1974, pp. 44 - 52

IFPUG (1994) International Function Point Users Group (IFPUG): Function Point Counting Practices Manual, Release 4.0, 1994

Jones (1996) Jones, C.: Applied Software Measurement. 2nd Ed. McGraw-Hill (New York), 1996

Ludewig (1995) Frühauf, K.; Ludewig, J.; Sandmayr, H.: Software-Prüfung. Eine Anleitung zum Test und zur Inspektion. 2. Auflage. vdf Hochschulverlag (Zürich), 1995, in german

Möller (1993) Möller, K.H.; Paulish, D.J.: Software-Metriken in der Praxis. Oldenbourg (München), 1993, in german

Porter (1997) Porter, A.A.; Siy, H.P.; Toman, C.A. et al.: An Experiment to Assess the Cost-Benefits of Code Inspections in Large Scale Software Development. IEEE Transactions on Software Engineering (23), No. 6, 1997, pp. 329 - 346

Pressman (1997) Pressman, R.S.: Software Engineering - A Practitioner s Approach. 4th Ed. McGraw-Hill (New York), 1997

Sackman (1968) Sackman, H. et al.: Exploratory Experimental Studies Comparing Online and Offline Programming Performance. Communications of the ACM (11), No. 1, 1968

Weller (1993) Weller, E.F.: Lessons from Three Years of Inspection Data. IEEE Software (10), No. 5, 1993, pp. 38 - 45