People Capability Maturity Model

Präsentation zum Thema: "People Capability Maturity Model"—  Präsentation transkript:

1 People Capability Maturity Model
Neben dem CMM, welches primär zur Verbesserung des Entwicklungsprozesses eingesetzt wird, existiert mit dem People Capability Maturity Model (P-CMM) ein Mittel zur Verbesserung des Personalmanagements bei der Software-Entwicklung. Es hat folgende Ziele: Erhöhung der Fähigkeiten des Unternehmens durch Erhöhung der Fähigkeiten der Entwickler Die Fähigkeit, Software zu entwickeln, wird der organisationalen und nicht individuellen Ebene angesiedelt Motivierung von Mitarbeitern Halten von wichtigen Mitarbeitern im Unternehmen

2 Entwicklung kleiner Systeme - Der PSP
Sehr eng mit dem CMM hängt der PSP (Personal Software Process) zusammen. Der PSP ergänzt das organisationsweite CMM um eine individuelle Prozessverbesserung. persönliches Management bedeutet, dass alle Schritte innerhalb des PSP vom Entwickler selbst durchgeführt werden müssen. Auch die Key Process Areas lassen sich mit dem PSP abdecken. Repeatable: Projektplanung und -überwachung, Standardisierung durch Grundprozess (PSP1) Defined: Reviews, Prozessdefinition, Produktentwicklung, Qualitätsmanagement, Quantitatives Prozessmanagement durch qualitätsorientierte Entwicklung (PSP2). Optimizing: Fehlervermeidung durch zyklische Entwicklung (PSP3)

3 Strategie zur Umsetzung des PSP
Zur Umsetzung des PSP wird eine mehrstufige Strategie vorgeschlagen. Identifikation von Methoden und Techniken für große Systeme, welche auch für den persönlichen Gebrauch verwendet werden können Definition einer Untermenge der gefundenen Methoden und Techniken für die Entwicklung kleiner Systeme Strukturierung der Methoden für eine schrittweise Einführung Bereitstellung von Übungen für die Methoden

4 Durchführung des PSP Der Personal Software Process wird anhand von Skripten durchgeführt. Diese Skripte enthalten die für einzelne Aufgabenbereiche nötigen Anweisungen. Die Aufgabenbereiche werden schwerpunktmäßig Phasen (Reifegraden) zugeordnet. Folgende Phasen werden unterschieden: Prozesssteuerung (PSPO) Planung (PSP1) Software-Entwicklung (PSP2) Auswertungen (PSP3)

5 Der Grundprozess: PSPO
Die erste Phase ist folgendermaßen charakterisiert: Verwendung des aktuellen Prozesses (z.B. Wasserfall) als Basis Einführung grundsätzlicher Größenmessungen Benutzung eines einfachen Rahmenwerks zur Erstellung kleiner Programme Die Verbesserung des Prozesses wird durch die Aufzeichnung von Problemen und den Vorschlag von Änderungen eingeleitet. Dabei werden meist kleinere Änderungen vorgenommen (z.B. npassung der Struktur), um mit dem PSP kompatibel zu sein.

6 Metriken für den Grundprozess
Um eine Prozessverbesserung erzielen zu können, sind u.a. Aussagen über den aktuellen Prozess und das erstellte Programm nötig: Erfassung der Programmgröße (hauptsächlich Zeilenzahl, da weit verbreitet und signifikante Korrelation zum Entwicklungsaufwand) Erfassung der Arbeitszeit pro Phase Erfassung von Fehlern, die während der Entwicklung gemacht und behoben werden Sammeln der erfassten Zeiten und Fehlerinformation über mehrere Projekte hinweg

7 Ressourcen- und Ablaufplanung: PSP1
Im PSP1 wird zusätzlich zu den klassischen Phasen eine Planungsphase eingeführt. Alle Phasen werden zeitlich erfasst. Ziel ist die Einrichtung eines wiederverwendbaren Prozesses zur Schätzung von Ressourcenbedarf und Zeitaufwendungen. Die Hauptressource im PSP ist die Zeit. Zur Abschätzung des Zeitbedarfs werden folgende Daten herangezogen: Vergangenheitsdaten für die Produktivität (Zeilen pro Stunde) geschätzte Programmgröße Vergangenheitsdaten für die aufgewendete Zeit In der Ablaufplanung wird die Zeit pro Phase abgeschätzt, wobei hier zwischen Zeitbedarf, welcher von der Programmgröße abhängt und unabhängigem Zeitbedarf, unterschieden werden muss.

8 Metriken für den Entwicklungsprozess
Die Überwachung des Entwicklungsprozesses wird mittels eines einfachen Indikators vorgenommen: Der Anteil einer Aufgabe am Gesamtzeitbedarf des Projekts wird errechnet, der Projektfortschritt ist gleich der Summe der bereits erledigten Anteile der geplante Fortschritt wird mit dem tatsächlichen Fortschritt verglichen bei groben Abweichungen müssen die geplanten Werte angeglichen werden Zur Größenabschätzung wird die Zeilenzahl betrachtet. Möglichkeiten zur Abschätzung durch Experten in mehreren Runden. Einteilung in grobe Kategorien aufgrund von Vergangenheitsdaten Aufteilung des Programmes in Eingaben, Ausgaben, Anfragen, benutzte Dateien/Datenbanktabellen und externen Schnittstellen Abschätzung anhand von Proxies (Stellvertretern), z.B. Programm- Objekten

9 Entwurf und Implementierung von Software: PSP2
Der Entwurf erfolgt in 4 Schritten, die aber nur selten linear durchlaufen werden: Sammeln von Benutzeranforderungen Analyse der Anforderungen Erstellen eines High-Level Designs Verfeinerung des Designs Das Ergebnis des Entwurfs wird dokumentiert. Die Dokumentation soll die genaue Funktion des Programmes beschreiben. Folgende Gesichtspunkte sind zu beachten: Beschreibung von Funktionen mittels Vorbedingungen und daraus resultierenden Aktionen (Funktionale Beschreibung) Beschreibung der Interaktion des Benutzers mit dem Programm z.B. durch Use Cases (Operationale Beschreibung) Beschreibung der Programm- oder Objektzustände (Zustandsbeschreibung) Beschreibung von Funktionen mittels Pseudocode (Logische Beschreibung)

10 Metriken für Entwurf und Implementierung
Fehler sollten möglichst früh vermieden werden. In dieser Phase sind dazu Prüfungen gegenüber Anforderungen in Form von Reviews hilfreich. Anforderunges-Reviews: Prüfung des Designs gegen die Anforderungen und evtl. Einholen von weiteren Anforderungdsdaten Überprüfung von Syntax, Namensgebung, Speichermanagement, Funktionsaufrufen Überprüfung auf Komplettheit, Programmlogik, Sonderfälle Für die Reviews sind Code- und Design-Standars zu entwickeln. Gegen diese kann dann geprüft werden

11 Zyklische Prozesse: PSP3
Mit PSPO bis PSP2 lassen sich Programme bis ca Zeilen bewältigen. Für die Entwicklung größerer Programme muss das Gesamtsystem in handhabbare Einheiten zerlegt werden. Sie können dann nacheinander oder von einem Team parallel abgearbeitet werden. Der Entwicklungsprozess wird dazu aufgeteilt: Eine Planungs- und High-Level-Design-Phase sowie daran anschließend mehrere untergeordnete Phasen (zyklischer Prozess). Jeder Zyklus besteht aus einem kompletten PSP2-Prozess. Folgendes ist zu beachten: Jeder Zyklus muss komplett und korrekt abgeschlossen sein (hohe Bedeutung für Design- und Code-Reviews) Regressions-Tests sichern die Korrektheit aller Komponenten bei fortlaufenden Änderungen die im Zyklus bearbeiteten Änderungen sollten ca. 100 bis 300 Zeilen neuen und geänderten Code enthalten Der PSP3 ist eine leicht praktizierbare Vorstufe des Rational Unified Process (RUP).