Ein besonderes Merkmal des PSP ist, daß er eine Menge von recht einfachen Produkt- und Prozeßmaßen benutzt, die es trotz ihrer Einfachheit recht gut gestatten, den Prozeß zu charakterisieren und zu kontrollieren. Dieser erfreuliche Effekt rührt daher, daß durch die wohldefinierte und varianzarme Arbeitsweise (es ist ja immer die gleiche Person!) viele Daten aussagekräftig werden, die man bei projektweiter oder gar projektübergreifender Benutzung bestenfalls als dubios bezeichnen könnte.
Die Produktgröße von Software wird im PSP durch Lines of Code gemessen. Das ist sinnvoll, weil sich diese Größe recht gut schätzen läßt. Siehe auch die Diskussion im Abschnitt 6.5.2.
Der PSP beschränkt sich allerdings nicht einfach auf die Erfassung der Gesamtproduktgröße, sondern unterscheidet die Zeilen nach ihrer Historie, in der Annahme, daß unterschiedliche Entstehungsgeschichte auch unterschiedlichen Aufwand bedeutet.
Neugeschriebene Zeilen werden als ,,zugefügt`` (added, A) bezeichnet, also zum Beispiel alle Zeilen eines komplett neu entwickelten Produkts. Natürlich können auch Änderungen an bestehenden Produkten vorkommen. In diesem Fall beginnt die Entwicklung mit einer gewissen Zahl von vorhandenen Zeilen B, der ,,Basis`` (base). Dann gibt es außer den zugefügten Zeilen auch ,,gelöschte`` Zeilen (deleted, D) und ,,geänderte`` Zeilen (modified, M). Außerdem können Programmteile unverändert wiederverwendet werden (im Gegesatz zur Basis, die verändert wird); diese werden als ,,wiederverwendet`` (reused, R) ebenfalls separat gezählt. Aus diesen Werten ergibt sich die Anzahl ,,total`` (total, T) von Zeilen zu T = B + A - D + R. Außerdem wird noch die Anzahl derjenigen Zeilen gezählt, die frisch zur späteren Wiederverwendung erzeugt wurden.
Zur Beschreibung des Arbeitsumfangs wird im Normalfall die Summe der zugefügten und geänderten Zeilen (A+M) herangezogen. Für genauere Analysen, insbesondere bei der Aufwandsschätzung werden aber auch B, D und R zusätzlich berücksichtigt.
Die Messung der Produktivität ist eine der wichtigsten Aufgaben bei der Steuerung eines Prozesses. Die Produktivität ist eine wichtige Leitgröße für die Planung und die Vorhersage der Planeinhaltung; ein Absinken der Produktivität zeigt Schwierigkeiten an, die entdeckt und behoben werden müssen, und ein Ansteigen ist das Signal für eine erfolgreiche Prozeßverbesserung.
Leider ist aus Geschäftssicht das einzige wirklich aussagekräftige Produktivitätsmaß die Menge erzeugten Anwendernutzens pro eingesetzter Ressourcenmenge (und zwar genaugenommen des subjektiven Anwendernutzens, weil dieser die Marktchancen bestimmt). Diese Größe zu messen, ist dummerweise so gut wie unmöglich. Deshalb behilft man sich üblicherweise mit volumenorientierten Produktivitätsmaßen, also der Menge hergestellten Programms pro Zeit. Diese Menge kann man wiederum auf eine günstige und eine ungünstige Weise bestimmen: Günstig ist, die Menge an der Zahl erfüllter Kundenanforderungen zu messen. Ungünstig ist, die Menge an der Menge erzeugten Programms zu messen, ohne direkten Bezug dazu, was dieses Programm tut. Produktivitätsmessung anhand von Kundenanforderungen sind beispielsweise mit der Funktionspunkt-Methode [AJEG83,Beh83] möglich. Ein derartiges Vorgehen hat leider den Nachteil, daß die Messung nicht automatisiert werden kann. Deshalb ist immer noch die Methode der Mengenmessung am Programmcode trotz aller ihrer Nachteile die günstigste.
Kann man dabei trotzdem von einer sinnvollen Produktivitätsmessung sprechen? Unter gewissen Voraussetzungen ja. Was Produktivität ist, ist nämlich letztlich eine Frage des Betrachtungswinkels. Subjektiver Anwendernutzen pro Ressourcenmenge ist natürlich das für die Unternehmensführung letztendlich relevante Produktivitätsmaß; im Innern eines Softwareproduktionsprozesses sind aber gewisse Randbedingungen stets schon vorgegeben. Insbesondere kann auf der Ebene, auf der ein einzelner Softwareingenieur eine Softwarekomponente entwickelt, bei einem gut strukturierten Prozeß davon ausgegangen werden, daß der Ingenieur nicht absichtlich versucht, seine Produktivität durch Herstellung großer Mengen sinnlosen Programms künstlich in die Höhe zu treiben. Tut er das aber nicht, dann ist ein Produktivitätsmaß wie Lines of Code pro Stunde (LOC/h), wie es im PSP verwendet wird, durchaus sinnvoll. Das hat zwei Gründe:
Geschwindigkeitsmessung auf Basis von LOC/h läßt sich an verschiedenen Stellen einsetzen: Für die Gesamtentwicklung, für das Kodieren, für die Codedurchsicht und für den Test. Auf gewissen Umwegen kann damit auch der Entwurfsprozeß (im Nachhinein) beurteilt werden, falls das sinnvoll erscheint.
Von der Qualität eines Produktes läßt sich als einziger Aspekt die Zuverlässigkeit bequem messen. Der PSP verwendet hierzu eine Messung der statischen Defektanzahl; siehe den Abschnitt 7 über die Cleanroom-Technik für eine Diskussion des alternativen Ansatzes, nämlich die Messung der dynamischen Versagenshäufigkeit mittels statistischem Testen. Die statische Defektanzahl kann anhand der gefundenen Fehler gemessen werden. Diese Angabe ist zwar ungenau, denn es muß stets mit weiteren, noch nicht gefundenen Fehlern gerechnet werden, aber in einem hochwertigen Prozeß sollte diese Ungenauigkeit gering sein. Zwei Größen werden im PSP zur Charakterisierung der Produktqualität benutzt: Die Dichte der Fehler über alle Entwicklungsphasen (in Defekte pro 1000 Zeilen Code, defects/KLOC) und die Dichte der Fehler, die in der Testphase gefunden wurden (testdefects/KLOC). Ersteres Maß enthält zusätzlich zum zweiten auch alle Fehler, die schon während Entwurf, Kodieren und den zugehörigen Durchsichten gefunden wurden.
Warum kann man diese Werte zur Charakterisierung der Qualität des ausgelieferten Produkts heranziehen? Grundlage dafür ist die Beobachtung, daß jeder Defektentfernungsschritt ungefähr einen festen Prozentsatz der Fehler entfernt, beispielsweise die Hälfte, wenn ich einen vorher festgelegten Aufwand in diesen Schritt investiere. Gehe ich also mit 20 Fehlern in eine Testphase mit vordefiniertem Testprogramm, hat das ausgelieferte Programm ungefähr noch 10 Fehler; waren nur 4 vorhanden, werden ungefähr 2 ausgeliefert. Ähnliche Überlegungen gelten auch für die Defektentfernung in Durchsichten, so daß auch die Gesamtanzahl von Fehlern sinnvolle Information über die vermutliche Restfehlerzahl enthält.
Wie schon bei der Produktivität so wird auch hier die Nützlichkeit der verwendeten Maße zur Prozeßsteuerung dadurch erhöht, daß wir es mit einem PSP und also mit immer vergleichbaren Situationen zu tun haben, weil immer der gleiche Softwareingenieur zugrundeliegt.
Von konstanten Defektentfernungsquoten pro Phase kann man dann nicht ausgehen, wenn die Phasen auf die gefundene Fehlerzahl reagieren und bei hohen Zahlen ausführlichere Prüfungen einsetzen. Solches Vorgehen benutzt Zuverlässigkeitsmodelle, um die vermutliche Restfehlerzahl zu berechnen und könnte alternativ im PSP eingesetzt werden. Siehe Abschnitt 7.6. Eine andere Verbesserung wäre die Unterscheidung von Fehlern in z.B. drei verschiedene Schweregrade.
Die Prozeßqualität spiegelt sich hauptsächlich in vier Größen wider: Produktivität und Produktqualität, wie oben gesehen, sowie Planungsgenauigkeit und Erfolg des Qualitätsmanagements.
Die Planungsgenauigkeit läßt sich pauschal in einem PSP dadurch beurteilen, daß man den Unterschied zwischen Planung und Wirklichkeit betrachtet. Der PSP schlägt dafür den cost/performance index (CPI) vor, der der Quotient aus geplanter und tatsächlich benötigter Zeit ist und für jede Phase separat berechnet werden kann, da jede Phase eine separate Zeitplanung hat. Der CPI sollte möglichst nah an 1 liegen; wesentlich größere oder kleinere Werte in manchen Phasen deuten auf Bereiche hin, in denen der Planungsprozeß verbessert werden sollte oder der Entwicklungsprozeß instabil ist.
Für das Qualitätsmanagement gibt es im PSP eine zentrale Meßgröße namens Ausbeute (yield). Die Ausbeute ist das Maß für den Erfolg der Bemühungen, Fehler bereits vor der ersten Programmübersetzung zu finden und gibt den Anteil der Programmfehler an, die vor der ersten Übersetzung gefunden wurden, von allen, die bis dahin bereits eingefügt worden sind.
Bei Auslieferung des Programms kann die Ausbeute nur geschätzt werden, weil die Zahl ausgelieferter Fehler unbekannt ist, aber eigentlich in die Berechnung eingehen müßte. Dennoch ist die Ausbeute auch in der vereinfachten Form, die nur bis zur Testphase reicht, eine extrem nützliche Größe für die Prozeßsteuerung und -beurteilung.
Zur Beurteilung, ob der Prozeß in sinnvoller Weise abläuft, lassen sich noch weitere Größen heranziehen. Der PSP benutzt die Begutachtungsgeschwindigkeit in KLOC/h, um abzuschätzen, ob die Codebegutachtungen möglicherweise zu ausführlich oder zu flüchtig vorgenommen wurden. Ein anderes Maß für den gleichen Zweck ist das Begutachtungs-Versagens-Verhältnis (appraisal to failure ratio, A/FR). Dieses gibt den Quotienten aus der Zeit an, die für die Begutachtung von Entwurf und Code aufgewendet wurde, und der Zeit, die zum Übersetzen und Testen aufgewendet wurde. Letztere wird dabei als Versagenszeit betrachtet, in der Annahme, daß ihr überwiegender Teil nur deshalb aufgewendet werden muß, weil das Programm noch nicht so funktioniert, wie es nach perfekten Durchsichten eigentlich sollte. Es gibt einen optimalen Bereich für den A/FR, unterhalb dessen die Durchsichten zu flüchtig sind, so daß sich die Versagenszeit unnötig und überproportional verlängert, und oberhalb dessen der Mehraufwand in den Begutachtungen sich kaum mehr auszahlt. Dieser optimale Bereich kann identifiziert und dann im Prozeß durch Änderung der Begutachtungsgeschwindigkeit gezielt angesteuert werden.
Da das Einfügen und Entfernen von Fehlern einen ganz erheblichen Einfluß auf die Produktivität hat, ist es interessant, die Fehlerprozesse soweit möglich separat zu betrachten. Im Falle der Defektentfernung benutzt der PSP dafür zwei Maße.
Für die verschiedenen Phasen, die der Entfernung von Fehlern dienen, also Entwurfsdurchsicht, Codedurchsicht, Übersetzung und Test wird jeweils die Defektentfernungsgeschwindigkeit in entfernten Defekten pro Stunde (defects removed per hour) gemessen. Abweichungen dieser Maße von ihren üblichen Werten signalisieren einen besonders guten oder schlechten Prozeß oder ungewöhnlich gute oder schlechte Produkte und sind deshalb nützliche Prozeßkontrollgrößen.
Zur Motivation und zur Kontrolle, ob der Umfang der Durchsichten angemessen ist, dient eine weitere Größe, nämlich die Defektentfernungs-Hebelwirkung (defect removal leverage, DRL(A/B)), die als Quotient aus den Defektentfernungsgeschwindigkeiten zweier Phasen A und B berechnet wird, wobei normalerweise A eine Durchsichtphase ist und B der Test. Bei guten Durchsichten ist dort üblicherweise die Entfernungsgeschwindigkeit deutlich größer als im Test, was dann durch ein DRL von beispielsweise 2 oder 3 bestätigt wird.
Die Messung von Arbeitsvolumen durch LOC und Aufwand durch Zeit ist nützlich und praktikabel. Beim Arbeitsvolumen besteht die Schwierigkeit, daß das LOC-Maß nicht direkt auf Entwürfe angewendet werden kann, so daß viele Meßwerte erst recht spät zur Verfügung stehen. Allerdings kann man sich je nach Entwurfsmethode andere Maße denken, die diese Lücke schließen können, z.B. Anzahl von Methoden, Anzahl von Zuständen, etc.
Bei allen Maßen, die mit Qualität zu tun haben, ergibt sich hingegen ein Problem: Die gleichartige Gewichtung von 1 für Fehler aller Art ist irreführend. Erstens gibt es Fehler, die erheblich leichter zu finden sind als andere, zum Beispiel Fehler, die vom Übersetzer entdeckt werden oder Fehler, die fast immer zu schwerwiegendem Programmversagen führen. Es wäre also angemessen, auch unterschiedliche Entfernungskosten für solche Fehler zu erwarten. Zweitens gibt es Fehler, deren Auswirkung auf die Qualität erheblich geringer als bei anderen ist. Zum Beispiel ist ein gelegentlicher Datenverlust schwerwiegender als ein kleiner Formatierungsfehler in der Ausgabe oder die unvollständige Behandlung eines extrem seltenen Fehlerfalls.
Eine sinnvolle und zuverlässige Einteilung von Fehlern in Schwereklassen gemäß dieser Kriterien wäre also eine wichtige Erweiterung des PSP, ist aber ein ungelöstes Problem.