Objekte, Schnittstellen und Prozesse bilden für Sneed die drei Dimensionen objektorientierter Software. Sie lassen sich in drei Modellen erfassen (siehe Abbildung) und in drei Phasen messen. In der ersten Phase werden individuelle Klassen entworfen, programmiert und getestet oder aus existenten Bibliotheken übernommen. Die zweite Phase sieht die Integration der Klassen vor. Entwickler entwerfen neue Schnittstellen und überprüfen die darauf basierende Interaktion zwischen den Klassen. In der dritten Phase steht die Überprüfung der Anwendungsprozesse oder -fälle an. Die Software wird auf Funktionalität und auf Qualitätsmerkmale getestet.
Die Softwaredimensionen werden in Modellen erfaßt, die als relationale Tabellen zu verstehen sind, in der die Tupel die Entitäten der Modelle abbilden. Die Entities des Objektmodells entsprechen den Klassen, die aus Objektanalysen gewonnen werden. Die Entities des Kommunikationsmodells sind die Nachrichten oder Interfaces, die in der Schnittstellen-Analyse gefunden wurden. Die Entities des Prozeßmodells schließlich, spiegeln Prozesse und Transaktionen wider. Aus dieser Struktur läßt sich nun eine Metrik erzeugen.
Den Codieraufwand schätzt man mit Klassentabellen. Er richtet sich nach dem Grad der Anpassung einer wiederverwendeten Klasse oder nach dem Aufwand für die Erstellung sowie nach dem Klassenumfang. Dieser läßt sich durch die Anzahl der Attribute, der Relationen zu anderen Klassen und der Methoden bestimmen. In einer Formel addiert und mit einer Änderungsrate multipliziert, ergeben sich sogenannte Classpoints. Dabei gewichtet Sneed die Attribute mit dem Faktor eins, Relationen mit zwei und Methoden mit drei. Geerbte Attribute und Methoden werden auf dem Niveau der Basis- und Superklassen gezählt.
Analog zum beschriebenen Verfahren lassen sich Nachrichten und Prozeßpunkte errechnen. Der Aufwand für die Klassenintegration und die Integrationstests wird anhand der Nachrichtentabelle ermittelt. Dabei drückt sich der Grad der Anpassung von Schnittstellen und Nachrichten in einer Änderungsrate aus. Nachrichten enthalten zudem Parameter und sind durch Sender und Empfänger bestimmt. Ihre Komplexität teilt Sneed in hoch, mittel und niedrig ein. Ist die Wiederverwendungsrate der Klassen hoch, übersteigt der Integrationsaufwand den für die Klassenentwicklung.
Mit Hilfe der Prozeßtabelle läßt sich der Umfang der Systemtests abschätzen. Sie enthält anders als die zuvor beschriebenen Nachrichten- und Klassentabellen keine Änderungsraten, weil die Transaktionen, die die Funktionen der Klassen ausführen, unabhängig vom Codeumfang sind. Allerdings sind die Prozesse abhängig von der Art der Anwendung. Sneed unterscheidet vier Typen: Systemprozesse wie Backup und Recovery, Batch-, Online- und Echtzeitprozesse. Darüber hinaus gibt es verschiedene Varianten eines Prozesses. So wird etwa eine Banktransaktion als Ein- oder Auszahlung ausgeführt.
Die Summe aus Process-, Message- und Classpoints ergibt die Objectpoints. Allein mit ihnen allerdings erhält der Anwender noch keine gültige Metrik. Wesentlich für eine Aufwandsschätzung sind beispielsweise die Qualitätsanforderungen, die an das Produkt gestellt werden. Indiz für die Produktzuverlässig-keit ist etwa die Fehlerrate pro 1000 Codezeilen oder pro Testfall. Die Sneed-Methode gestattet dem Benutzer, bis zu zwölf verschiedene Qualitätsmaßstäbe zu definieren.
Darüber hinaus wählte Sneed zehn zu gewichtende Einflußfaktoren aus, die mit der Umgebung zu tun haben, in der die objektorientierte Software produziert wird. Ein Faktor vier etwa bei der Verfügbarkeit würde insgesamt einen Produktivitätsgewinn von 40 Prozent bedeuten. Sneed zählt auf:
1. die Verfügbarkeit von Groupware zur Unterstützung des Projektteams;
2. die Qualität der Benutzeroberfläche der Entwicklungsumgebung;
3. die Zuverlässigkeit des Netzes, in dem die Entwickler arbeiten;
4. die Reife des zu entwickelnden Prozesses;
5. die technische Unterstützung des Projektteams;
6. der Anwendungsgrad objektorientierter Methoden;
7. das objektorientierte Niveau der verwendeten Sprache;
8. die Verfügbarkeit von objektorientierten CASE-Tools;
9. die Anwesenheit eines Objekt-Repositorys sowie
10. der Grad der Testautomatisierung
Die Erfahrungen von Sneed beziehen sich auf Projekte geringer bis mittlerer Größe. In kleinen Projekten bis zu 2000 Objektpoints oder 10000 Codezeilen entspricht ein Objektpoint rund zwei Mannstunden. Der Aufwand steigt mit der Projektgröße. Bis zu vier Stunden pro Objectpoint sind in einem Projekt mittlerer Größe mit bis zu 8000 Objectpoints anzusetzten.
Eine ausführliche Darstellung findet sich im Vortragsbund "Software-Management Forum" des Fraunhofer Instituts für Arbeitswirtschaft und Organisation, Seite 101 ff.