Objektorientiertes Software-Design mittels CASE-Tools
Geschwurbel von Daniel Schwamm (01.06.1994 bis 01.08.1994)
Inhalt
Professionelle SW ist entweder auf bestimmte Kunden zugeschnitten oder für
einen breiten Markt gedacht, ausserdem sind Aspekte der Wirtschaftlichkeit zu
beachten. Diese Anforderung ist bei der Entwicklung zu berücksichtigen,
z.B. in Form eines formalen Entwicklungsprozesses oder einer konsequenten
Projektüberwachung.
Das Prozessmodell eines formalen Entwicklungsprozesses legt die einzelnen
Phasen und ihre Reihenfolge fest und gibt ausserdem die Kriterien vor, bei
denen ein Phasenwechsel vorzunehmen ist. Damit wird ein Rahmen gebildet, der es
erlaubt, auf Einzelheiten zu achten. Die Entwicklung wird dadurch
abschätzbar hinsichtlich der Kosten, der Termine und der Qualität des
Endprodukts (Dokumentation und Programm). Das macht die SW-Entwicklung und das
SW-Produkt bewertbar, vergleichbar und planbar. Mögliche Prozessmodelle
sind: Das klassische Wasserfall-, das V-, das Prototyping- und das
Spiralenmodell.
Die Qualität hat beim geordneten Entwicklungsprozess zwei Aspekte:
Produktaspekt und Prozessaspekt. Die Qualität des Prozesses lässt
sich z.B. verbessern, wenn er statistischer Kontrolle/Disziplin unterliegt.
Leistungsfähigkeit und tatsächliche Leistung müssen
übereinstimmen. Reaktives Verhalten (z.B. Prozessänderung aufgrund
einer Termin-Überschreitung) ist durch vorausschauendes Handeln zu
ersetzen. Diese kann im Rahmen der analytischen und organisatorischen
Qualitätssicherung z.B. über das SEI Process Modell oder das
Capability Maturing Model erfolgen, die die folgenden fünf
Prozess-Qualitätsstufen unterscheiden:
-
Primitiv: Jeder Rationalisierungsansatz wurde umgangen. Die Entwicklung kann
erfolgreich sein, aber die Ergebnisse sind nicht vorhersagbar. Der Erfolg
hängt nur von hervorragenden Managern ab.
-
Wiederholbar: Der Prozess wird von einem Projektleiter kontrolliert, eine
Dokumentation erfolgt nicht, die Ergebnisse sind ungefähr
abschätzbar.
-
Definiert: Ein wiederholbarer Prozess mit Dokumentation. Es gibt eine Gruppe,
die den Prozess überwacht.
-
Gesteuert: Der Prozess wird laufend gemessen, um ihn optimieren zu können.
Ziel ist die Qualität des Produkts und des Prozesses zu erhöhen.
-
Optimiert: Ein gesteuerter Prozess, bei dem genau vorgegeben ist, wie der
laufende Prozess gemessen und verbessert werden kann.
CASE ist eine spezielle Vorgehensweise für die Modellierung und
Entwicklung von Informationssystemen. Der Computer dient dabei als
Dokumentationshilfe, Modellierungshilfe, Entwicklungshilfe, Programmierumgebung
(Editieren, Kompilierung, Linking), CASE-Tool-Träger (für komplexe
Systeme) und Software-Entwicklungsumgebung (Konfiguration, Team-Steuerung, Wartung).
Die letzten drei Punkte grenzt man auch über
Programing-in-the-small/large/many voneinander ab.
Die wichtigsten CASE-Tools sind (1993): Excelerator, ProMod, Maestro, Teamwork
und Application Development Workbench. Generell gilt, dass CASE nur
unterstützend wirkt, und keinesfalls bestehende SW-Engineering-Verfahren
oder gar Erfahrung ersetzen kann, zumal CASE auch nur bei geordneten Prozessen
zum Einsatz kommen kann.
Betrachten wir als Beispiel für CASE-Tools Teamwork von CADRE
Technologies, Inc. Es verfügt über eine offene Architektur, arbeitet
auf Workstations unter UNIX, AIX und OS/2, und dient der SW-Entwicklung in
Gruppenarbeit. Seine Komponenten pro Phase sind:
-
Analyse: Information Modell (IM), Structured Analyse (SA), Real Time (RT),
System Simulation (SIM) und OOA.
-
Design: Strukturierter Entwurf (SD) und ADA.
-
Implementierung: C Source Builder und ADA Source Builder.
-
Wartung: C REV und ADA Structured Graph Builder.
Ziel der Objektorientierung ist es, durch intensive Wiederverwendung
früherer Ergebnisse die Qualität des SW-Produkts und die
Produktivität der SW-Entwicklung zu steigern. Begriffe der Objektivierung
sind:
-
Objekt: Encapsulation von Methode und Struktur. Z.B. Datei.
-
State Machine Modell (STM): Dient der Objekt-Verhaltensbeschreibung.
-
Klasse: Definiert die Eigenschaften von Objekten.
-
Instanz: Objekt einer Klasse.
-
Konstruktor/Destruktor: Methode zur Erzeugung/Zerstörung von Instanzen.
-
Meta-Klasse: Beschreibung der Klassen-Objekte (Implementation/Protokoll).
-
Klassen-Variablen: Globale Datenobjekte innerhalb einer Klasse.
-
Klassen-Methoden: Globale Methoden innerhalb einer Klasse.
-
Instanz-Variablen: Privater Bereich einer Instanz.
-
Vererbung: Eigenschaftsweitergabe an hierarchisch untergeordnete Klassen.
-
Spezialisierung: Vererbungsstruktur zwischen Gemein- und Spezialklasse.
-
Mehrfachvererbung: Eine Klasse erbt die Eigenschaften mehrere Klassen.
-
Nachricht: Informationen, die zwischen Objekten ausgetauscht werden.
-
Polymorphismus: Gleichnamige Methoden werden instanzengerecht ausgeführt.
-
Überladen: Schaffung gleichnamiger Methoden in Klassen.
-
Static/Dynamic Binding: Methode wird bei Kompilierung bzw. Laufzeit gestellt.
-
Deferred Class (Verschobene Klasse): Eingerücktes Schema einer Klasse.
-
Generische Klasse: Parametrisierte Klasse.
-
Structured Analyse/Design: Funktionale Vorläufer von OOA und OOD.
Die Methode besteht aus objektorientierter Analyse und Recursive Design. Die
System-Modellierung erfolgt ähnlich wie bei der Technik relationaler
Datenbanken, um Klassen, deren Beziehungen zueinander und deren Attribute zu
definieren.
-
Grundlagen: Klären wir einige Shlaer/Mellor-Begriffe.
- Klasse: Reale Dinge/Rollen/Ereignisse/Interaktionen/Spezifikationen
- Reales Ding: Reale Dinge des Problembereichs, z.B. Motor, Person, Konto.
- Rolle: Rollen die Instanzen spielen, z.B. Kunde, Mitarbeiter.
- Ereignis: Vorgang, der zu bestimmten Zeitpunkten eintritt, z.B. Unfall.
- Interaktion: Verbindungsklasse zwischen zwei Klassen, z.B. Vertrag.
- Spezifikation: Eigenschaftsdefinitionen einer Klasse (Relation).
- Attribut: Abstraktion einer Charakteristik aller Instanzen einer Klasse.
- Beschreibendes Attribut: Eigenschaft einer Klasse.
- Benennendes Attribut: Bezeichner (Schlüssel) zur Instanz-Identifizierung.
- Referenzattribut: Dient Instanzen-Relationen.
- Wertebereich (Domäne): Menge zulässiger Attribute-Ausprägungen.
- Beziehung: Relation zwischen Instanzen über gleiche Attribute.
- Beziehungsformen: 1:1, 1:M, M:M oder konditioniert 1:1c, 1:Mc, Mc:Mc.
- Supertype und Subtype: Klassen der Spezialisierungsbeziehung.
- Assoziative Klasse: Interaktionsklasse mit zusätzlichen Attributen.
-
Vorgehensweise: Shlaer/Mellor gehen nach vier Schritten vor.
- Definition der Klassen und deren Beziehungen über ein ERM.
- Kommunikation zwischen den Klassen über Object Communication Diagrams (OCD).
- State Transition Diagrams (STD) für das Objektverhalten.
- Datenflussdiagramme (DFD) für jeden State mit Bubbles für einzelne Aktionen.
Warum wird Qualität heute so betont? Qualität ist nicht Selbstzwecke,
sondern berücksichtigt den Markt, die Kunden und die Wirtschaftlichkeit im
Bezug auf ein SW-Produkt. Von vorneherein auf Qualität zu setzen schafft
den gebotenen Absatz durch Kundenzufriedenheit und vermeidet nachträgliche
kostenintensive und zeitaufwendige Korrekturen bzw. Wartungsarbeiten am
Endprodukt. Das notwendige mass der Qualität des Endprodukts hängt
dabei im Wesentlichen von den Anforderungen und den Prioritäten der
Anwender ab. SW-Entwicklung sollte also immer ein kundenorientierter Prozess
sein.
Qualität heisst, den Anforderungen und den Prioritäten der
Endbenutzer zu entsprechen. Sie ist keine absolute Grösse, sondern
resultiert aus verschiedenen Kriterien und deren subjektiver (!) Beurteilung,
wobei das am schlechtesten beurteilte Element der Menge der Eigenschaften
i.d.R. das Gesamturteil für das Gesamtprodukt bestimmt.
Zusammengefasst gilt, dass Qualitätsaspekte betroffen sind von dem
Endprodukt selbst und den Prozessen, die zum Endprodukt führten. Es wird
unterschieden zwischen äusserer und innerer Qualität und zwischen
messbarer und unmessbarer Qualität. Es sei hier noch einmal Endprodukt-
und Entwicklungsprozess-Qualität etwas genauer betrachtet:
-
Endproduktqualität: Resultiert aus Funktionalität, Installierbarkeit,
Benutzbarkeit, Zuverlässigkeit, Richtigkeit, Robustheit, Sicherheit,
Effizienz, Wartbarkeit, Portabilität und Interoperability
(Kopplungsaufwand eines Systems an ein anderes).
-
Prozessqualität: Resultiert aus Strukturierung, Testbarkeit und Standards.
-
Programmpflegequalität: Resultiert aus Strukturierung, Wartbarkeit,
Änderbarkeit, Testbarkeit, Standards und Verständlichkeit.
-
Übertragbarkeitsqualität: Resultiert aus der Portabilität und
der Allgemeingültigkeit.
Fazit: Qualität lässt sich unter transzendenten, produktbezogenen,
anwenderbezogenen, prozessbezogenen und Kosten-Nutzen-bezogenen Aspekten
betrachten.
Drei Typen von Qualitätssicherungskonzepten lassen sich differenzieren:
- die klassische Qualitätskontrolle.
- die Prozess-begleitende Qualitätssicherung.
- die umfassende, unternehmensweite Qualitätskonzeption (TQM).
Dieses Konzept der klassischen Qualitätskontrolle verlangt eine
organisatorische Abstimmung von allen Grössen, die die Qualität eines
Endprodukts bzw. Entwicklungsprozesses bestimmen. Diese Grössen sind u.a.
Methoden und Werkzeuge, Standards, Prozessbeschreibung, Produktionsumgebung,
personelle Organisation und Qualifikation und Motivation der Mitarbeiter
(bestimmt durch die Arbeitsbedingungen). Die Qualitätssicherungsgruppe
kann dabei als eigene Abteilung hierarchisch in die Organisation eingegliedert
werden, was aber auf Kosten der Objektivität geht aufgrund personeller
Gebundenheit an die Qualitätssicherungsgruppe, oder sich in Form von
Matrix-Organisationen aus Personen mehrerer Abteilungen rekrutieren.
Bei dieser prozessbegleitenden Qualitätssicherung wird die Qualität
des entstehenden Produkts (Zwischenprodukt) bzw. Endprodukts, sowie die
Qualität des Entwicklungsprozesses laufend geprüft und bewertet. Das
Ziel ist die Qualitätsverbesserung des Endprodukts, woraus sich für
die Entwickler-Firma ein positives Image ergibt. Besonders hilfreich ist es in
diesem Falle, wenn auch der Auftraggeber während des Entwicklungsprozesses
integriert ist, um seine Wünsche Kund tun zu können.
Voraussetzung für die analytische Qualitätssicherung ist jedoch eine
funktionierende Qualitätsplanung, die bereits im Vorfeld die genauen
Anforderungen an das Produkt festlegt, aus denen sich Prüfziele bilden
lassen. Doch wie misst man die Erreichung dieser Prüfziele (z.B.
Benutzerfreundlichkeit)? Beispielsweise durch Labortests, wo Tester daraufhin
beobachtet werden, wie oft sie Tatstatur benutzen, wie oft sie im Handbuch
nachsehen müssen, usw.
Das Produkt im Rahmen der analytischen Qualitätssicherung validiert, d.h.
es wird geprüft, inwieweit es die Anforderung der Auftraggeber
erfüllt, und es wird verifiziert, d.h. es wird geprüft, ob das
Produkt fehlerfrei arbeitet und ob die besten (neuesten) Techniken darin
Verwendung finden.
Weitere analytische Qualitätssicherungsmethoden zur Prüfung der
Qualitätsprüfziele durch Menschen sind:
- Audits: Einmalige Begutachtungen hinsichtlich der Produkt- bzw. Prozessqualität.
- Reviews: Fortlaufend Managementuntersuchungen bzgl. Kosten, Personal u.ä.
- Walk through: Formloses Durchsehen der Programme
- Inspektionen: Ein formaler Prozess (svw.)
- Formale Verifikation: (Stückweise) Induktionsbeweise.
- Final Independent Installation Test: SW-Firma übernimmt Prüfung.
-
Ursachen-Ermittlung (Causal Analysis): Warum sind Fehler in welcher Phase
entstanden? Diese Methode dient weniger dem laufenden Projekt als langfristig
dem Entwicklungsprozess (wenn z.B. erkannt wird, dass mehr Planung, bessere
Ausbildung oder mehr Standards von Nöten ist). Die Fehlerverbesserung muss
der Verursacher selbst übernehmen.
Uns interessiert hier v.a. die Inspektion, die in der Praxis bereits
erfolgreich angewendet wird. Sie ist ein formaler Prozess, bei dem diverse
Voraussetzungen (z.B. Schulung) erfüllt und diverse Meilensteine zur
Prüfung definiert sein müssen. Ziel der Inspektion ist letztlich die
Qualitätsverbesserung von Teil- bzw. Zwischenprodukten und des
Endprodukts. Durch die Formalismen kann auf ein leitendes oder kontrollierendes
Management weitgehend verzichtet werden, was die Entwicklung für die
Entwickler angstfreier macht.
Dadurch, dass bei der Inspektion viel Aufwand getrieben wird, werden Fehler
(z.B. Schnittstellenfehler) frühzeitig entdeckt, wodurch sich
nachträgliche Korrekturen minimieren lassen. Bei der klassischen
Qualitätskontrolle wurde solche Fehler häufig erst bei der
Implementierung und in der Testphase bemerkt, wo ihre Entfernung zu hohen Kosten
und niedriger Produktivität führten. Damit die frühzeitige
Fehlererkennung und Fehlerentfernung funktionieren kann, müssen Inspektion
jedoch jeweils nach dem Grobentwurf, nach dem Feinentwurf, nach der Codierung,
bei der Erstellung der Testfälle und bei der Erstellung der
Benutzerdokumentation durchgeführt werden. Allerdings ist die Inspektion
kein Ersatz für die Testphase!
Bei der Inspektion sind folgende Rollen zu verteilen: Ein Moderator als Leiter,
ein Schreiber, ein Autor (oder mehrere Autoren) und drei bis fünf
Inspektoren. Um den Autoren Fragen stellen zu können, sind Walkthroughs
hilfreich.
Analytische Qualitätssicherungsmethoden zur Prüfung der Qualitätsprüfziele
durch Maschinen sind:
- Statische Prüfungen: Quantitative Untersuchungen, z.B. Speicherplatz.
- Dynamische Prüfungen: Simulationen und Tests.
Uns interessieren hier v.a. Tests (die vom Debugging, welches die
Fehlerausmerzung beinhaltet, abzugrenzen sind). Es lassen sich Modul-Tests,
Komponenten-Tests und System-Test unterscheiden. Generell gilt, dass Tests nie
vollständig durchgeführt werden können, eine kreative
Tätigkeit sind (entgegen der landläufigen Meinung), stets destruktiv
sind, von Nicht-Programmierern durchgeführt werden sollten, ein
Soll-Ergebnis (welches von einem Simulationsmodell stammen kann) bringen
sollten, und geplant werden müssen.
Der Testablauf lässt sich in die folgenden Phasen unterteilen:
-
Testplanung (basiert auf Erfahrung)
-
Testvorbereitung: z.B. Testfälle mit Soll-Ergebnissen gestalten.
-
Testdurchführung
-
Testauswertung
Testabbruchkriterien sind: Fehlerfreier Ablauf, Soll-Ergebnisse zu bestimmtem
Prozentsatz erfüllt, Testkosten zu hoch oder Fehlerfälle zu hoch.
Tests können auf drei Arten konzipiert sein:
-
Als Black Box Test: Interne Details sind dem Tester unbekannt. Es wird nur
geprüft, ob die Input-Output-Relation stimmt. Für jede Funktion,
jedes Eingabedatum und jedes mögliche Ausgabedatum muss es dann genau
einen Testfall geben (den zu finden ein kreativer Akt darstellt). Diese Testart
eignet sich zum Testen des gesamten Systems.
-
Als White Box Test: Bei diesem Test werden nur einzelnen Module auf ihre
Richtigkeit hin getestet. Die Testfälle müssen so ausgelegt sein,
dass sie alle Module mindestens einmal berühren.
-
Als Usage Test: Vor dem Test werden Benutzerprofile ermittelt, an die sich dann
die Testfälle orientieren können. Diese neueste Testart steht im
Zusammenhang mit dem Clear-Room-Engineering (s.w.v.)
Konstruktive Qualitätssicherung wird durch handwerkliche Massnahmen
realisiert. Software Engineering, Programmpflege und Wiederverwendungen (Reuse)
dominieren dieses Konzept. Betrachten wir uns diese Punkte näher:
-
Software Engineering: Ingenieurhaftes Vorgehen bei Erstellung von Software,
nach einem IEEE-Standard. Wesentliche Charakteristiken sind Trennung der
Belange (die Fragen nach dem WAS und WIE wird z.B. in verschiedenen messbaren
Phasen bearbeitet), Abstraktion, Information Hiding (Encapsulation),
strukturierte Programmierung und schrittweise Verfeinerung. Ein bestehendes
System kann über Reverse Engineering reanalysiert und redokumentiert
werden. Ein Design-Recovery sorgt dafür, dass Experten SW-Funktionen in
einer höheren Abstraktionsstufe beschreiben, was einem Reuse
förderlich sein kann.
-
Programmpflege: Der Lebenszyklus von SW umfasst drei bis vier Jahre. Bis zu 85%
des Gesamtaufwandes müssen in die Programmpflege gesteckt werden, und ein
genauso hoher Prozentsatz der Informatiker ist mit der gleichen Aufgabe
beschäftigt, d.h. nur ca. 20% "erfinden" wirklich Neues. Die
Programmpflege unterteilt sich in korrigierende bzw. anpassende
Programm-Wartung), verbessernde Programm-Modifikation und vorbeugende
Modernisierung. Der Worst Case für Programmierer ist das Ersetzen von
Programmteilen, um sie funktional wie technisch zu aktualisieren; dies kann
jedoch der SW-Hersteller nicht (!) voraussehen. Ein solcher Fall wäre z.B.
gegeben, wenn eine Firma so stark wächst, dass das Personenkennnummernfeld
zu klein wird. Eine Modernisierung fällt z.B. an, wenn Programme mit
etlichen "goto"-Sprunganweisungen gespickt sind, was dem SW-Engineering-Prinzipien
widerspricht, oder der Betreuer des Systems in Ruhestand geht.
Grundsätzlich gilt aber, dass ein System, welches nicht von vorneherein
auf Wartung ausgelegt wurde, auch unwartbar ist. Nach einem Gesetz muss diese
Wartbarkeit durch die Benutzung von CASE-Tools oder ähnlichen Methoden und
der Einhaltung aller Entwicklungsphasen plus Dokumentation erreicht werden.
Auch sollten im Source-Code nicht mit Kommentaren gespart werden.
-
Wiederverwendung: Eine wichtige Neuerung bei konstruktiven
Entwicklungsprozessen - v.a. denen objektorientierte Methoden zugrunde liegen -
stellt die Wiederverwendung von SW-Teilen dar. Warum sollte auch jedes Mal das
Rad neu erfunden werden? Kommt man darüber überein, dass beim Design
analytisch ermittelte Objekte auch durch Standardobjekte implementiert werden
können, spart man die Neuentwicklung der Objekte. Reusing verlangt
allerdings eine saubere Dokumentation, sowie meistens auch eine gewisse
Portabilität der Objekte.
Dieses aus Japan stammende Konzept hält sich an die folgenden Prinzipien:
-
Orientierung am Kunden.
-
Corporate Culture - durchgehende Qualitätsgarantie.
-
Verhütung von Problemen, statt Reaktion auf Probleme.
-
Fortlaufende Verbesserung der Produkte/Dienstleistungen.
-
Qualitätsmanagement mit Qualitätsverantwortung des Einzelnen.
-
Sinnvoller Einsatz von Ressourcen.
ISO 9000 ist eine Norm für Qualitätsmanagement und Qualitätssicherung,
die helfen soll, Fehler von vorneherein zu verhüten. Die Norm fordert:
-
Schaffung einer Aufbau- und Ablauforganisation.
-
Qualifikation von Mitarbeitern.
-
Formale Regelungen der Kompetenzen und Verantwortungen.
-
Dokumentationspflicht.
-
Berichtspflicht an jeweils nächst höhere Ebene.
-
ein Qualitätssicherungssystem (Aufbau wird in mehreren Normen beschrieben).
-
Laufende Prüfungen.
-
Kundendienst.
-
Statistische Kontrolle.
-
Interne Qualitätsaudits der Mitarbeiter
-
Korrekturmassnahmen
-
Vertragsüberprüfung
-
Konfigurationsmanagement
Die Norm befasst sich mit allen Phasen und allen Abteilungen, die etwas mit dem
Produkt zu tun hat - sie reicht vom Entwurf bis zur Wartung und vom Lager bis
zur Marktforschung. Wer die Norm ISO 9000 in allen Punkten erfüllt - dies
wird innerhalb von vier Tage von 5 Gutachtern bewertet -, erhält ein
Zertifikat für ein Jahr, dass als Qualitätsnachweis nach aussen hin
angesehen werden kann. Doch bisher sind noch nicht viele Unternehmen in den
Genuss dieses Zertifikats gekommen.
Neben ISO 9000 gibt es auch noch zwei andere "Oskars" für Qualität:
- Malcolm Baldrige National Quality Award
- European Foundation for Quality Management
Ein anderes Wort für SW-Metrik ist SW-Mass. Entitäten, die die
Qualität der SW und des SW-Prozesses ausmachen, bekommen interne und
externe (betreffen auch Produkt-/Prozess-externe Aspekte) beobachtbare
Attribute zugewiesen, die nach klaren Regeln, die die Metriken vorgeben,
bewertet und untereinander vergleichbar gemacht werden können. Praktisch
sieht das etwa folgendermassen aus:
Entitaet internes Attribut externes Attribut
---------------------------------------------------------------
Produkt:
- Spezifikation Umfang Modularität
- Entwurf Struktur Umfang
- Code Kommentierung Zuverlässigkeit
- Testdauer Abdeckung Testfallzahlen
Prozess:
- Spezifikation Zeit Stabilität
- Detaillierung Aufwand Dauer
Ressourcen:
- Personal Erfahrung Produktivität
- Teams Zusammensetzung Produktivität
- HW/SW Leistung/Robustheit Kosten
Das bringt Vorteile hinsichtlich der Planung und Zielsetzung (z.B.
Qualität, Produktivität, Kontrolle und Kundenvertrauen) von
SW-Projekten. Allerdings gibt es wenige Metriken, die die Analyse- und
Designphase mit einbeziehen, und (noch) keine Standard-SW-Metriken, die in der
gesamten Industrie Verwendung finden. Wenn überhaupt, arbeiten Firmen mit
intern-genormten SW-Metriken. Sinn machen diese nur, wenn sie differenziert,
vergleichbar, exakt, reproduzierbar unter gleichen Bedingungen, relevant und
jederzeit verfügbar sind. Das Messen selbst ist auch nicht trivial. Wie
genau soll z.B. gemessen werden? Euklidisch (Abstand zwischen zwei Punkten)
oder der Taxi-Fahrer-Strategie folgend (Abstand zwischen Start und Ziel)? An
Skalen stehen alternativ zur Verfügung:
- Nominalskalen: Benannte Ausprägungen, z.B. C, PASCAL, BASIC, ...
- Ordinalskalen: Rangordnung, z.B. von 1 bis 5, schlecht bis gut.
- Intervallskalen: Differenzen haben Bedeutung, z.B. Temperaturskalen.
- Rationalskalen: Es gibt einen Nullpunkt, z.B. Länge, Dauer, ...
Auf Basis von SW-Metriken lässt sich abschätzen, wie gut eine SW ist,
was sie ca. Kosten wird, oder ob Produkt A besser ist als Produkt B. Auch
differenzierte Fragestellungen sind möglich, so z.B. bezüglich der
Struktur, der Verständlichkeit, der Effizienz und Bedienerfreundlichkeit
der SW. Unterscheiden lassen sich SW-Metriken grob in Qualitätsmetriken
(prognostische Metriken) und Kostenmetriken (Steuerungsmetriken). Qualitätsmetriken
beschäftigen sich mit Qualitätsaussagen des Produkt, Kostenmetriken mit der
Überwachung der Prozess und Ressourcen, die für das Produkt
benötigt werden. Ein typisches Produktmass ist z.B. Zahl der Fehler im
Code. Und ein typisches Prozess-Mass ist z.B. die Zahl der in einem formalen
Test gefundenen Fehler. In den nächsten Abschnitten wird diese
Unterscheidung noch weiter ausgeführt.
SW-Metriken bergen neben Vorteilen auch Probleme in sich, v.a. im Bezug auf die
Akzeptanz ihrer Anwendung. Die Entwickler von SW sind ja durch sie gezwungen,
die Ergebnisse der Metriken zu berücksichtige, was die Innovationskraft
schmälern kann. Ganz generell bedeuten SW-Metriken Mehr-Arbeit. Sie
müssen zudem benutzt werden, obwohl sie meist nicht immer verfügbar
sind (z.B. in Form von CASE-Tools). Und sie können zuletzt auch als Mass
für eine persönliche Kontrolle der Entwickler durch die Führung
missbraucht werden.
Qualitätsmetriken orientieren sich i.d.R. an Qualitätsmodelle, die
die Soll-Vorstellungen der Endbenutzer in adaptiv-flexibler oder fixer Weise
integriert haben. Je nach Anspruch kann grob oder fein vorgegangen werden, z.B.
kann die Gesamtfehlerzahl/Programmgrösse betrachtet werden oder -
spezieller - die Restfehlerrate/Programmgrösse. Mögliche
Qualitätsmetriken seien kurz vorgestellt:
Zuverlässigkeit = Mittlere Zeitspanne bis Fehler
Zuverlässigkeit
Verfügbarkeit = -----------------------------------------------
Mittlere Fehlerbehebungsdauer + Zuverlässigkeit
Komplexität = Zahl der Kanten - Knoten + 2 * graphenfremde Teile
= Zahl der binären Entscheidungen im Programm + 1
Restfehlerrate = Fehlerzahl nach Fertigstellung des Programms
Fehler nach Gaffney = Fehler jeder Phase + Restfehlerrate in Prozent ermitteln
Kostenmetriken helfen, SW-Projekte hinsichtlich ihrer Kosten abzuschätzen.
Sie sind wichtig für die Kalkulation, für die
Wirtschaftlichkeitsüberprüfung, die Personalplanung und die
Make-or-Buy-Entscheidung. Einschränkend muss jedoch gesagt werden, dass
sei bei innovativen Produkten nur wenig aussagekräftig sind, weil hier
Erfahrungswerte noch nicht vorhanden sind. Bei "Wiederholungstaten" können
sie jedoch gute Vergleichsbasen für alternative Vorgehensweisen bieten,
wobei die Kosten per Annahme nur mit der Komplexität und der Grösse
des Produkts in korrelativem Verhältnis steht. Im Folgenden werden drei
algorithmische Kostenschätzungsverfahren vorgestellt:
-
Lines Of Code (LOC): Die Kosten werden hier mit der geschätzten
Programmgrösse geteilt durch den empirisch ermittelten
Produktivitätsfaktor gleichgesetzt. Der Produktivitätsfaktor gibt an,
in welchem Mass das spätere Produkt eingesetzt wird; er wird dominiert von
der Komplexität, von der Projektdauer und dem Zeiteinsatz, den die
Mitglieder zur Erstellung des Produkts bringen (i.d.R. nicht mehr als 65%, der
Rest ist Tagesgeschäft).
-
Constructive Cost Model (COCOMO): Diese Kostenmetrik berücksichtigt, dass
SW mit verschiedenartigen Teams erstellt werden kann. COCOMO unterscheidet dazu
die folgenden Teamarten:
- Organic Teams: Kleine Teams, bestehend aus Profis; z.B. Batch-Systeme.
- Semi-detached Teams: Integriert die Betroffenen.
- Embedded Teams: Prozess- und ressourceneingeschränkte Teams; z.B. Online-Systeme.
Je nach dem Detaillierungsgrad (Basic/Intermediate/Detailed COCOMO) können
pro Teamart die Kosten der SW-Erstellung abgeschätzt werden, wobei
folgende Tabelle mit Erfahrungswerten für die Kostenfaktoren zugrunde liegt:
Teamart A B C D
--------------------------------------------------------
Organic Team 2.4 1.05 2.5 0.38
Semi-detached Team 3.0 1.12 2.5 0.35
Embedded Team 3.6 1.20 2.5 0.32
Basic-COCOMO berechnet die Kosten der SW-Entwicklung nach der Formel
(KDSI, Kilo Delivered Source Instruction, geschätzte Programmgrösse):
Projektkosten: K = A * KDSI^B
Dauer: Z = C * K^D; [Monate]
Intermediate-COCOMO berechnet die Kosten noch etwas genauer, indem A leicht
abgewandelte Werte annimmt (je nach Teamart 3.2, 3.0, 2.8) und die Projektkosten
K mit EAF multipliziert werden, wobei EAF eine Ziffer ist, die sich aus 15
kostenrelevanten Faktoren zusammensetzt, z.B. HW-Kosten, Projekt-Kosten,
Mitarbeitererfahrung usw.
Detailed-COCOMO berücksichtigt neben dem Intermediate-COCOMO-Kostenwert
auch die Möglichkeit, bestehende Systeme auf eine neue Anwendung hin zu
modifizieren, was neue Werte für A, B, C und D verlangt. Damit ist ein
direkter Kostenvergleich zwischen Reuse und Neukonzeption möglich.
-
Function Points-Verfahren: Als Basis dient hier der Umfang des zukünftigen
Programms, wobei als Indikator die Menge der zu implementierenden Funktionen
abgeschätzt werden muss (=Grösse; dabei wird zwangsläufig
benutzerorientiert vorgegangen, was ein positiver Nebeneffekt dieser Methode
ist). Die Funktionen sind hinsichtlich ihres Schwierigkeitsgrades
(=Komplexität) zu bewerten und pro Funktionsgruppe zu gewichten. Man
erhält eine Tabelle der Form:
Schwierigkeitsgrad: einfach medium hoch
-----------------------------------------------------------------
Eingabe-Gewichtung 3 4 5
- Datenelemente wenig viel viel
- Bedienerführung viel wenig wenig
- Cursor-Handling wenig wenig wenig
Ausgabe-Gewichtung 3 3 4
- Tabellenaufbau wenig wenig viel
Daten-Gewichtung 1 4 8
- Datentypen viel viel wenig
-----------------------------------------------------------------
Gesamtzahl: xyz = x y z
Die Function-Points xyz können über firmenweite Erfahrungswerte in
Personen-Monate umgerechnet werden, z.B. ergeben 150 Function-Points 5
Personen-Monate und 3.000 Function-Points 299 Personen-Monate. Das
Function-Point-Modell liefert eine Kostenmetrik, die v.a. in kommerziellen
Bereichen eingesetzt werden kann.