The Capability Maturity Model. Das Modell der Reifegrade.

Transkript

1 The Capability Maturity Model. Das Modell der Reifegrade. Seminar Informatik. Shavrov Anton

2 Inhaltsverzeichnis. 1. Einführung in Capability Moturity Model(CMM) Geschichtliche Entwicklung Capability Maturity Model Integration (CMMI) ist ein Nachfolgermodel Andere Prozessbeurteilungsverfahren Unreife vs. reife Software-Organisationen Grundlegende Begriffe des Reife-Prozesses Grundgerüst des Capability Maturity Models Grundebene (Initial Level) Ebene der Wiederholbarkeit (Repeatable Level) Definierte Ebene (Defined Level) Lenkbare Ebene (Managed Level) Ebene der Optimierung (Optimizing Level) Interne Struktur des Capability Maturity Models Praktische Anwendung - C3 Project Chrysler Extreme Programmierung Statistik der Bewertung internationaler Unternehmen durch CMM(I) Zusammenfassung Quellen

3 1. Einführung in Capability Moturity Model(CMM). Fast alle Organisationen haben ein Problem in einer festgelegten Zeit, mit einem begrenzten Budget und der Einhaltung von bestimmten Qualitätsanforderungen eine Software zu entwickeln. Die Problematik wurde sehr ernst genommen nach der Durchführung einer Reihe von Statistiken und dem Scheitern der großen Projekte im Militärbereich inden USA. Ein nicht publizierter Review des Verteidigungsministeriums (Department of Defence) hat ergeben, dass siebzehn bedeutende Projekte im Verzug waren. Ein vier jähriges Projekt wurde nicht nach sieben Jahren abgeliefert. Der Einsatz von B1 Bombenflugzeugn wurde wegen des Softwareproblems verlegt. 1 Das Problem war auch in der Industrie bekannt. In den USA steigen die Ausgaben für Software jedes Jahr ca. um 12%. Außerdem wächst immer mehr das Verlangen nach neuen Funktionen und Anwendungen. Die Situation lässt sich durch die Aussage eines Senior Manager beschreiben : I'd rather have it wrong than have it late. We can always fix it later. Für die Auftraggeber führt dies dazu, dass sie Software nicht wie bestellt bekommen und dadurch typischerweise Zusatzkosten haben, sei es, weil die Entwicklung als solche teurer geworden ist oder weil der von der neuen Software erwartete Nutzen nicht oder zumindest erst später realisiert werden kann. Der Auftragnehmer hat im günstigsten Fall, wenn z.b. die Strafe nicht vertraglich festgelegt ist, nur den Imageschaden. Das allein kann schon für ein Unternehmen schlechte Folge haben. Für die Lösung dieses Problems hat das amerikanische Verteidigungsministerium die Gründung eines Software Engineering Institutes (SEI) veranlasst. Die Aufgabe des Institutes war die Software-Praktiken in der amerikanischen Industrie zu verbessern. Das musste auch die Möglichkeit dem Ministerium geben, seine eigenen Auftragnehmer zu bewerten, damit man sicher sein kann, dass die Software, wie versprochen, geliefert werden kann. Demgemäß ist ein Capability Maturity Model (CMM) entstanden. Die Hauptrichtlinie bei CMM ist die Bereitstellung der Methoden zur Bewertung der Fähigkeiten der respektiven Reife einer Softwareorganisation und die Bestimmung der Maßnahmen zur ihrer Verbesserung. Dabei geht man davon aus, dass die Qualität eines Softwareproduktes von der Qualität der Entwicklungsprozesse abhängt, mit denen es hergestellt wird. Das Bewertungsverfahren durch einen Fragebogen wird als Assessment bezeichnet. Dieser Fragebogen kann auf den in CMM festgelegten Fragen zur Bestimmung der Ebene der Organisation basieren. Eine Ebene wird durch die 18 Hauptkriterien, Schlüsselbereichen (Key Process Areas) definiert. Ein Hauptkriterium wird durch bestimmte Aspekte oder Key Practices bezeichnet. Sie schreiben vor, was getan werden muss, um das jeweilige Hauptkriterium zu erfüllen. 1. The Capability Maturity Model:Guidlines for Improving the Software Process Addison-Wesley publishing company ISBN:

4 Es wird jedoch nicht festgelegt, wie das umgesetzt werden soll. CMM definiert also keine Prozesse sondern lediglich deren Verwendung und Nutzen. Der Fragebogen bildet das Herzstück von CMM. Anhand der Auswertung des Assessments kann der Reifegrad bzw. Ebene der Softwarefirma bestimmt werden. Erreichen einer Ebene liefert ein Kriterium für die Beurteilung der Kompetenz einer Organisation. 1.1 Geschichtliche Entwicklung startete auf Initiative des US-Verteidigungsministeriums das Software Engineering Institute an der Carnegie Mellon University in Pittsburgh, welches dem US-Verteidigungsministerium untersteht, die Entwicklung eines Systems zur Bewertung der Reife von Softwareprozessen wurde die Software Proccess Maturity Framework freigegeben wurde das Modell als Capability Maturity Model 1.0 herausgegeben. Dabei wurde bei Assessments auf Maturity Questionnaire betont wurde es auf Grund von Rückmeldungen aus der Industrie überarbeitet und in der Version 1.1 bereitgestellt wurde CMM 2.0 kurz vor der Verabschiedung vom US- Verteidigungsministeriums zurückgezogen, stattdessen wurde das CMMI-Projekt gestartet wurde im Herbst CMMI - damals noch unter dem Namen Capability Maturity Model Integrated - als Pilotversion 1.0 herausgegeben. Anfang 2002 wurde CMMI unter dem neuen Namen Capability Maturity Model Integration (kurz CMMI) freigegeben. Ende 2003 ist die Unterstützung des SEI für die alte Version CMM ausgelaufen. Jetzt wird nur noch CMMI unterstützt wurde die CMMI-Version 1.2 für Herbst 2006 angekündigt. Die Unterstützung des SEI für CMMI Version 1.1 soll danach noch bis Ende 2007 weiterlaufen. Ende 2005 laufen die Lizenzen der Assessmentleiter für CMM aus, d. h. es gibt keine offiziellen CMM-Assessments mehr. Am 25. August 2006 ist die neue Version 1.2 des CMMI veröffentlicht worden. Mit dem neuen Release sind einige grundlegende Veränderungen einhergegangen. So wurde u. A. die neue Version auf CMMI-DEV umbenannt Capability Maturity Model Integration (CMMI) ist ein Nachfolgermodel. Seit August 2006 ersetzt CMMI die ältere Version des Software Capability Maturity Models. Es wurde ebenso am Software Engineering Institute der Carnegie Mellon University in Pittsburgh im Auftrag des amerikanischen Verteidigungsministeriums entwickelt. Im neuenmodel wird einen größeren Wert auf Modularität gesetzt. Dieses modulare Konzept bewirkt

5 die Integration weiterer Entwicklungsdisziplinen. CMMI sammelt alle aus dem CMM gewonnen Erfahrungen und Verbesserungen. Das Nachfolgemodel verfügt über die einheitlichere Struktur und kann in anderen Bereichen außer der Softwareentwicklung verwendet werden. Außerdem hat das neue Model zwei Arten der Darstellung: eine stufenförmige (Staged Representation) mit ebenfalls fünf Stufen und eine kontinuierliche (Continuous Representation). Die kontinuierliche Art stellt die Reife einer Organisation detaillierter dar. Dabei wird pro Prozessgebiet, einen so genannten Fähigkeitsgrad auf einer Skala von 0 bis 5, gegeben. Darüber hinaus gibt es neben der Unterscheidung zwischen zwei Arten der Darstellung mehrere unterschiedliche Varianten, die eine Abhängigkeit von einem Anwendungsbereich aufweisen. Neuerungen in CMMI gegenüber CMM. Neue Schlüsselbereiche (Key Process Areas). - fasst über Schlüsselbereiche verteilte Anforderungen an einer Stelle zusammen. Umbenennung. - Software Projekt Planning in Project Planning. - Software Projekt Tracking und Oversight in Projekt Monitoring and Control - Software Subcontract Management in Supplier Agreement Management - Software Quality Assurance in Process and Product Quality Assurance - Software Configuration Management in Configuration Manamement. Neue Prozessgebiete. - Anforderungsentwicklung - Technische Umsetzung - Produktintegration - Verifikation - Validation - Integriertes Projektmanagement - Risikomanagement - Entscheidungsanalyse und Entscheidungsfindung Folgende Prozessgebiete fallen weg. - Integrated Softwaremanagement - Software Produkt Engineering entfällt ganz als eigenes Prozessgebiet, Inhalte sind jetzt auf mehreren Prozessgebieten verteilt. - Intergroup Coordination - Partnerreviews ist jetzt Teil von Verifikation geworden. Keine wesentlichen Änderungen. - Organisationsweiter Prozessfokus - Organisationsweite Prozessdefinition - Training Programm ist organisationsweites Training - 5 -

6 3. Andere Prozessbeurteilungsverfahren. Es existiert eine Reihe der anderen Prozessbeurteilungsverfahren beziehungsweise Modele für das Qualitätsmanagement, die dem CMM verwandt sind. Eine kurze Übersicht über einige Modele wird im folgenden Abschnitt der Arbeit dargestellt. ISO Dieses Model ist sehr verbreitet und bekannt in Europa. Es stammt aus der Fertigungsindustrie und im Vergleich mit CMM viel allgemeiner formuliert. Die Allgemeinheit ermöglicht den Einsatz des Verfahrens fast in allen Branchen von Schraubenproduktion bis zur Softwareentwicklung. Andererseits bietet es im Bezug auf konkretes Problem weniger anwendbare Hilfsmittel als CMM auf Grund der Abstraktion an. Es gibt allerdings die Richtlinie ISO 90003:2004 und ISO 9001:2000 für die Anwendung im Bereich Software- und Systementwicklung. Ein Vorteil des dargestellten Model ist es, dass es alle wesentlichen Geschäftsprozesse abdeckt. Bootstrap. Das Verfahren wurde von vieleneuropäischen Organisationen im Auftrag der EU bereitgestellt. Das Model sollte mehr als CMM an die europäischen Anforderungen angepasst werden und mehr zur Konjunktur passen. Bootstrap verwendet eine kontinuierliche Darstellung. Dies kann mit einer Variante im CMMI verglichen werden. Momentan ist das Verfahren von ISO 15504abgelöst. ISO (SPICE). Diese ISO-Norm ist sehr unter dem Namen SPICE verbreitet. Das Akronym SPICE steht für Software Process Improvement and Capability determination. Das Verfahren definiert einen Rahmen für Reihfegrademodelle und zugehörige Bewertungsmethoden. Bei der Entwicklung von CMMI war die Zielsetzung mit SPICE kompatibel und konsistent zu bleiben. European Foundation for Quality Management (EFQM) Das Geschäftsfähigkeitsmodel der EFQM ist ein Modell für ein komplettes Qualitätsmanagement - Total Quality Management. Es ist die Grundlage für den jährlich zu vergebenen Europäischen Qualitätspreis. Das Model besteht aus zwei Teilen, eine Hälfte ist Befähiger, die Qualität ermöglichen und der andere Teil sind die Ergebnisse der Befähiger. Zu den Befähigern gehört die Nutzung definierter und kontinuierlich verbesserter Prozesse. Im Bezug auf CMMI kann man sagen, dass es diesen Bereich zum großen Teil abdeckt, währen die anderen Komponenten in CMMI fast nicht ausgearbeitet werden. Eine weitere Abbildung 1 stellt die Struktur des EFQM-Models dar. Abbildung 1-6 -

7 4. Unreife vs. reife Software-Organisationen. Um es nachvollziehen zu können, welche Verbesserungsmaßnahmen für ein Unternehmen wirklich erforderlich sind, stellt CMM in der ersten Linie einen Unterschied zwischen einer reifen und einer unreifen Organisation vor. Bei einem unreifen Unternehmen wird der Softwareprozess generell im Laufe des ganzen Projektes improvisiert. Selbst wenn der Softwareprozess spezifiziert ist, werden die festgelegten Richtlinien nicht eingehalten. Die unreifen Organisationen sind in der Regel rückschrittlich und ihre Manager sind nur auf die Überwindung der sofortigen Krisen fokussiert. Solche Unternehmen überschreiten oft auf Grund fehlender Basis für die objektive Bestimmung eigener Produktivität Ihren Fristablauf. In äußerst kritischen Fällen, kann für die Einhaltung der Termine, ein bestimmter Teil der Funktionalität bzw. Qualität geopfert werden. Die unreifen Organisationen haben also keine objektive Basis für die Bestimmung der Produktqualität und der Lösung akuter Probleme, wie auch wenig Verständnis für den Zusammenhang zwischen dem Prozess und Qualität. Die Produktqualität ist schwer vor zu bestimmen. Der Auftraggeber hat kaum Einsicht in das Produkt bis zur Abnahme. Die reifen Organisationen sind durch die gesteuerten Softwareentwicklungen und gut definierte, unternehmensweite Entwicklungsprozesse gekennzeichnet. Alle Aktivitäten werden nach einem vorgeschriebenen Plan durchgeführt. Die Planung ist hinreichend exakt und verlässlich. Die Prozessdefinitionen werden bei dem Bedarf aktualisiert und die Verbesserungen werden durch Pilot-Tests respektive Gewinn und Verlust-Analyse gewährleistet. Rollen und Verantwortung bezüglich des Prozesses sind verständlich für das ganze Projekt und die ganze Organisation. In den reifen Unternehmen überwachen Manager die Qualität des Softwareproduktes und damit verbundene Entwicklungsprozesse. Es gibt eine objektive, quantitative Basis zur Bestimmung der Produktqualität und Analyse der Probleme mit dem Produkt und Prozess. Die Erwartungen für die Kosten, Planung, Funktionalität und Qualität des Produktes werden in der Regel erfüllt. Im Allgemeinen folgen die reifen Organisationen konsistent dem disziplinierten Prozess, weil alle Teilnehmer Ihnen gestellten Aufgaben gut nachvollziehen, und die benötigte Infrastruktur vorhanden ist. 5. Grundlegende Begriffe des Reife-Prozesses. In diesem Teil der Arbeit werden die grundlegenden Begriffe vorgestellt, die eine Basis für das Verstehen der Reife eines Softwareprozesses bilden und zur Beschreibung der Reife einer Softwareorganisation dienen. CMM ist auf die Fähigkeit einer Organisation fokussiert, die hoch qualitative Softwareprodukte liefert. Die erste Frage, die beantwortet werden sollte, was ist ein Prozess? Ein Prozess ist eine Sequenz der Schritte zum Erreichen eines bestimmten Ziels. Ein Prozess nimmt die Leute, Werkzeuge und Methoden auf. Dies wird in der nächsten Abbildung 2 veranschaulicht. Ein Softwareprozess kann definiert werden als eine Menge von Aktivitäten und damit zusammenhängenden Ergebnissen, die zur Herstellung eines Softwareprodukts führen. 1 Bei den reifen Organisationen wird ein Software Prozess besser definiert und implementiert. 1. Software Engineering ISBN Auflage

8 Abbildung 2 1 Der Schwerpunkt eines Softwareprozesses legt CMM auf die Befähigung der Leute ihre Arbeit zu leisten. Ein effektiver Softwareprozess bindet die Leute, Werkzeuge und Methoden in eine integrierte Einheit zusammen. Software Process Capability beschreibt eine Reihe der erwarteten Ergebnisse, die bei der Ausführung des Software-Prozesses erreicht werden können. Software Process Capability einer Organisation sorgt dafür, dass es auch für das nächste Projekt die Ergebnisse sowie die Qualität vorhersagbar sein werden. Softwareprozess Performanz stellt die aktuellen Ergebnisse eines Softwareprozesses dar. Dabei wird auf erreichte Resultate fokussiert, währen Software Process Capability sich für die Erwartungen interessiert. Softwareprozess Reife ist ein Maß für die Bezeichnung eines bestimmten Prozesses, der explizit definiert, gesteuert, gemessen, kontrolliert und effizient ist. Die Reife bedeutet ein Potential für das Wachstum der Fähigkeiten und zeigt den Reichtum eines Prozesses einer Organisation an. Außerdem wird es die Konsistenz eines Prozesses für die Projekte innerhalb des Unternehmens aufgedeckt. Infrastruktur ist das grundlegende Gerippe einer Organisation oder Systems. Darin werden die Struktur, Methoden, Standard, Training, Einrichtungen und Werkzeuge eingeschlossen, um die Performanz des Unternehmens zu unterstützen. Institutionalisierung ist die Bildung einer Infrastruktur und Kultur, um die Methoden, Praktiken und Prozeduren zu unterstützen. Das Ergebnis von Institutionalisierung ist die organisationsweite Aufstellung eines effektiven, konsistenten Softwareprozesses. 1. The Software Engineering Institute. CMMI Product Team CMMI for Development, Version

9 6. Grundgerüst des Capability Maturity Models. Die Grundlage eines kontinuierlichen Verbesserungsprozesses ist ehe eine Anzahl von kleinen evolutionären Schritten als eine revolutionäre Innovation. Die Schritte werden in CMM durch fünf Reifenebenen oder -stufen repräsentiert. Diese fünf Stufen definieren eine Scala für die Messung des Reifengrades des Softwareprozesses der Organisation und die Erhöhung der Qualität des Prozesses selbst. Die Reifeebenen stellen eine gut definierte Evolutionsgrundlage für das Erreichen der Reife eines Softwareprozesses dar. Jede Ebene schließt eine Anzahl der Ziele ein, bei deren Erreichen man eine wichtige Komponente des Softwareprozesses stabilisiert. Die fünf Reifeebenen sind in der Abbildung 3 dargestellt. 6.1 Grundebene (Initial Level). Abbildung 3 Auf dieser Ebene gibt es keinen definierten Softwareprozess und keine stabile Umgebung für die Entwicklung. Bei dem Eintreffen von Krisen werden alle geplanten Vorgehensweisen weggelassen und durch Kodieren und Testen(Code&Fix) ersetzt. Im Laufe der Entwicklung werden ständige Änderungen und Modifizierungen vorgenommen. Aus diesem Grund ist die gute Produktion nur von dem gut qualifiziertem Personal und ihrem großem Einsatz abhängig. Man kann auch nicht vorhersagen, mit welcher Qualität und zu welchem Zeitpunkt das Produkt fertig gestellt wird. Das Budget wird meistens überschritten. Durch den Einsatz der guten Manager kann der Prozess zwar gekräftigt werden, hängt aber völlig von dem Personal ab. Die Fähigkeiten der Organisation der Ebene 1 sind personen- und nicht organisationsbezogen. 6.2 Ebene der Wiederholbarkeit (Repeatable Level). Die Ebene zwei kann durch Maßnahmen einer geordneten Steuerung und Verfolgung charakterisiert werden. Das bedeutet, dass der Prozess auf dieser Ebene schon definiert ist. Die Ablaufplanung ist auf der positiven Erfahrung aus den früheren und ähnlichen Projekten aufgebaut. Das erlaubt eine grobe Abschätzung der Projekte aus der Analogie. Prozessfähigkeit wird durch das disziplinierte Management deutlich verbessert. Die Manager verfolgen die Kosten der Software, Ablaufplanung und Funktionalität. Darüber hinaus wird eine einfache Kontrolle eingeführt. Dies führt zu einer gewissen Vorhersagbarkeit und Verbesserung des Prozesses, obwohl man noch bemerken muss, dass die Prozessqualität auf dieser Stufe noch nicht genügend ist

10 6.3 Definierte Ebene (Defined Level). Auf der dritten Ebene sind alle Entwicklungs- und Managementprozesse vollständig definiert, dokumentiert und unternehmensweit eingeführt. Die Integration des Softare-Engineerings und Managementprozesses in ein Ganzes, bildet ein Standard-Softwareprozess der Organisation. Die Organisation verwendet effektiv die Methoden aus dem Bereich Software Engineering während der Standardisierung der Softwareprozesse. Diese Stufe wird auch durch die Bildung einer Gruppe(Software Engineering Process Group) bezeichnet, die für die Prozessaktivitäten beziehungsweise für die Umsetzung verantwortlich ist. Die Definition der Prozesse soll es den Verantwortlichen ermöglichen Ihre Arbeit effizent zu leisten, ohne dabei die Prozesse hemmend und unflexibel werden zu lassen. Ein definierter Prozess folgt einer Reihe der vorgeschriebenen Techniken zur Durchführung und Verwaltung der Arbeit. Dabei existieren Eingans- bzw. Ausgangskriterien, die Maßnahmen zur Sicherstellung der Qualitätund die Methoden für die Steigerung der Performanz der Arbeit. Außerdem werden für die Erhöhung der Qualität der Arbeit und somit des Prozesses die Trainingprogramme für den Entwicklung- bzw. Verwaltungspersonal eingeführt. Die Prozessfähigkeiten der Ebene 3 kann man als konsistent charakterisieren. Ferner werden die Produktrichtlinie, Kosten, Planung, Funktionalität und Softwarequalität kontrolliert und verfolgt. Die Organisation der dritten Ebene hat einen Überblick und Kontrolle über die geführten Aktivitäten. Aber die Qualität des Softwareprozesses ist immer noch Schwankungen ausgesetzt. Lenkbare Ebene (Managed Level). Die vierte Ebene ist durch die Formulierung und Überwachung der quantitativen Ziele für das Softwareprodukt gekennzeichnet. Die Produktivität und Qualität werden als die wichtigen Aktivitäten des Softwareprozesses gemessen, um zahlreiche Aspekte des Prozesses zu erfassen. Die Messungen werden in einer organisationsweiten Datenbank abgelegt, um die Basis für die Analyse und Prozessverbesserungen zu ermitteln. Die Projekte erreichen die Kontrolle über Ihre Produkte und Prozesse bei kleiner Schwankung der Leistung. Die Prozessfähigkeiten der Ebene sind vorhersagbar. Die Organisationen dieser Stufe können die Prozessgüte einschätzen, aber sie verfügen über kein Wissen, wie ihre Prozesse verbessert werden können. 6.5 Ebene der Optimierung (Optimizing Level). Auf der Ebene 5 wird die ganze Organisation auf kontinuierliche Verbesserung des eigenen Prozesses ausgerichtet. Ein Unternehmen ist in der Lage die Schwächen zu erkennen und vorbeugende Maßnehmen zu treffen. Die gesammelten Messdaten werden für die Gewinnund Verlust-Rechnung gebraucht, um den Einsatz der neuen Technologien oder Änderungen an dem Produkte beurteilen zu können. Die festgestellten Verbesserungsmöglichkeiten werden organisationsweit eingeführt. Softwareteams der Ebene 5 untersuchen die Fehler, um Ihre Ursachen zu identifizieren. Auf dieser Grundlage werden die Vorgehensweise so geändert, dass man die Ursachen der Fehler möglichst ausschließt. Die Prozessfähigkeiten der Ebene 5 kann man als selbstverbessernd bezeichnen

11 7. Interne Struktur des Capability Maturity Models. Im folgenden Abschnitt der Arbeit wird ein Überblick über die ganze Struktur des CMMs gegeben. Wie schon bereits erwähnt wurde, bilden die Reifeebenen ein Grundgerüst des Models. Jede Reifestufe wird auf weitere Elemente geteilt. Ausschließlich der Ebene 1(siehe Abbildung 4), enthalten alle Stufen eine Reihe der Komponenten der abstrakten Aufstellungen bis hin zu den Aktivitäten in den Schlüsselpraktiken. Reifeebenen(Maturity Leveles) Abbildung 4 Eine Reifeebene ist eine gut definierte Grundlage für das Erreichen eines reifen Softwareprozesses. Jede Reifestufe zeigt das Niveau der Prozessfähigkeit, wobei Prozessfähigkeit eine Reihe von erwarteten Ergebnissen beschreibt, die bei dem Folgen dem Softwareprozess bereit gestellt werden können. Prozessfähigkeit einer Organisation dient zur Prognose der Erfolge für die erwartenden Softwareprodukte. Schlüsselbereiche(Key Process Areas). Bis auf die Ebene 1 sind alle Reifestufen auf einige Schlüsselbereiche zerlegt. Ein solcher Bereich zeigt einen Mittelpunkt für die Verbesserung des Softwareprozesses an, d.h. es werden Ergebnisse für das Erreichen bestimmter Ebene festgelegt. Jeder Schlüsselbereich legt eine Menge der Aktivitäten fest, deren vollständige Ausführung bei der wichtigen Verbesserung und Erreichung der Prozessziele hilft. Die Schlüsselbereiche aufeinander folgender Stufen bauen aufeinander auf. Die Art und Weise für die Erfüllung der Ziele ist nicht definiert und hängen von dem Projekt und seiner Umgebung ab. Die Ziele eines Schlüsselbereiches fassen seine Praktiken zusammen und können verwendet werden, um nach zu weisen, ob eine Organisation oder ein Projekt effizient den

12 Schlüsselbereich implementiert hat. Die Ziele bezeichnen den Umfang und den Rahmen eines Bereiches. Relevante Aspekte (Common Features). Die Praktiken jedes Schlüsselbereichs sind zwecks besserer Bequemlichkeit in relevante Aspekte organisiert, die eine Reihe von Attributen enthalten, mit deren Hilfe man verfolgen kann, ob die Implementierung und Institutionalisierung eines Schlüsselbereiches effizient, wiederholbar und nachhaltig ist. Man unterscheidet zwischen fünf relevante Aspekte: Commitment to Perform : es werden Aktivitäten beschrieben, die umgesetzt werden sollten, um sicher zu stellen, dass der Prozess aufgestellt ist. Ability to Perform: es werden Vorbedingungen beschrieben, die notwendig sind, um den Prozess mit Kompetenz zu verbessern. Activities Performes: es werden die Rollen und Vorgänge beschrieben, um einen Schlüsselbereich zu entwickeln. Measurement and Analysis: es werden die Bedürfnisse beschrieben, um den Prozess zu messen und Aufmass zu analisieren. Verifying Implementation: es werden notwendige Schritte beschrieben, um sich zu vergewissern, dass die Aktivitäten im Einvernehmen mit dem Prozess ausgeführt werden. Schlüsselpraktiken (Key Practices). Jeder Schlüsselbereich wird durch eine Anzahl der Schlüsselpraktiken festgelegt. Eine Schlüsselpraktik beschreibt die Aktivitäten und Infrastruktur, mit deren Hilfe man in der Lage ist, wirksam einen Schlüsselbereich zu implementieren und institutionalisieren. Ein Schlüsselbereich stellt nur allgemeine Maßnahmen dar. Er schreibt aber nicht vor, wie man das umsetzen sollte und welche Werkzeuge oder Techniken man beispielsweise einsetzen muss. Jeder Schlüsselbereich schließt nur einen einzigen Satz ein, der oft von einer detaillierten Beschreibung gefolgt wird, die Beispiele und die Ausarbeitungen enthalten kann. 8. Praktische Anwendung - C3 Project Chrysler Extreme Programmierung. In diesem Abschnitt wird ein Projekt, nämlich das Chrysler C3 Projekt im Bezug auf Capability Maturity Model dargestellt. Ein Merkmal dieses Projektes ist, dass es auf dem Exterme Programming(XP) beruht. Das kann etwas verwirrend sein, weil es Meinungen gibt, dass die Extreme Programmierung nicht über Ebene 1 des CMMs hinaus geht. Das liegt an der fehlenden Organisation, Dokumentation und nicht genügender Kontrolle über das Projekt. Des Weiteren werden verschiedene Gemeinsamkeiten der Extreme Programmierung mit CMM betrachten, die auf höhere Ebenen abgebildet werden

13 Ebene 1 - Grundebene. Eigenschaften: - keine stabile Umgebung für die Entwicklung. - oft vorhandene Überforderung - im Krisenfall Verzicht auf die Anforderungen - Abhängigkeit des Erfolgs nur vom Personalkompetenz Extreme Programmierung ist in zwei Ebenen der Terminplanung angeordnet, die den Ablaufplan bestimmen. Diese Ebenen heißen Commitment Schedule and Iteration Plan und sind auf der Einschätzung des Entwickler und seiner Erfahrung basiert. Das Resultat des Commitment-Schedule-Prozesses ist eine umfangreiche Bestimmung des zu entwickelnden Produktes und der Frist. Der Iteration Plan ist die Ruckkopplung an Commitmen Schedule, die in kurzen Intervallen stattfindet und die Verfeinerung des Ablaufplans zum Ziel hat. Der Fortschritt von C3 lässt sich auf keinen Fall als kritisch charakterisieren. Das C3-Team verweigert explizit den großen, heroischen Einsatz und arbeitet fast ohne Überstunden. Eine Neigung zur heroischen Taten ist ein Anzeichen für die bestehenden Probleme. In diesem Fall wird die Situation analysiert und der Entwicklungsprozess korrigiert. Die Mitglieder des C3-Teams sind kompetent aber nicht außergewöhnlich. Zur Steigerung der Effizienz wird das Pair-Programming verwendet. Bei diesem Verfahren werden zwei Leute eingesetzt, eine Person, die das bessere Verständnis über den aktuellen Zustand des Ablaufs hat, schreibt den Code, die Andere überwacht den Prozess und den entwickelnde ntrend, dabei korrigiert sie die aufgetretenen Fehler. Der Teammanager bietet keine außergewöhnliche Unterstützung. Der Teammanager dient nur zum Zweck der Verfolgung des Fortschrittes und als Schnittstelle zu Management. Ebene 2 Wiederholbarkeit. Eigenschaften: - effektive Prozessimplementierung auf Grund der vorhandenen Definitionen, Dokumenten, gesammelten Erfahrungen, der Übungen, Messungen und der Möglichkeit zur Verbesserung. Extreme Programmierung offensichtlich spezifiziert eine Menge von Praktiken (Extreme Programming Rules). Diese Regeln sind gut definiert und dokumentiert. Das Team wurde zum Anfang des Projekts gut vorbereitet, hatte Vollzeit-Coaching und übte die Methoden und Vorgehensweise des Teams. Pair Programming und ein offener Prozess gewährleistet allen Entwicklern zu wissen, in welchem Stand sich das Projekt befindet. In seltenen Fällen konnten Entwickler, die die Teampraktiken nicht einhalten, gemahnt oder aus dem Projekt ausgeschlossen werden. Die Praktiken können angereichert werden und sie werden ständig verbessert

14 Weitere Eigenschaften: - Managers des Projekts verfolgen den Aufwand, die Termineinhaltung und Funktionalität - Identifizierung der Probleme bei der Entstehung. In Extreme Programmierung werden vier Komponenten verfolgt, nämlich die Ressourcen, den Rahmen, die Qualität und Zeit. Diese Komponente erlauben fest zu stellen, ob der Terminplan mit entsprechender Qualität erreicht werden kann. Die Information über diese Komponenten werden im Laufe des Projektes regelmäßig dem höheren Management bereitgestellt. Definierte Ebene. Eigenschaften: - Software Engineering-, Managementprozesse sind die Beistandteile des Softwareprozesses. - Prozesscharakteristik mithilfe der Bereitschaftskriterien, den Verifikationsmechanismus, den Outputs, den Inputs, dem Endfertigungskriterium - Leichte Einsicht in technischen Fortschritt. Extreme Programmierung Methoden umfassen die Bereitschaftskriterien Inputs (Benutzer- Geschichte), Standarten und Prozeduren (zahlreiche Extreme Programming Rules ), Verifikationsmechanismus (Unit-Test und Systemtest), Output (Software)und Endfertigungskriterium (Abnahme durch einen Benutzer) Verwendung von vier Komponenten: die Ressourcen, den Rahmen, die Qualität und Zeit ermöglichen dem Management einfache und verständliche Einsicht in die aktuelle Projektperformanz. Lenkbare Ebene. Eigenschaften: - quantitativ qualitative Ziele sowohl für das Softwareprodukt als auch für den Softwareprozess. Für die Extreme Programmierung werden die qualitativen Ziele für das Produkt durch Systemtest nachgeprüft. Außerdem ist es erforderlich, dass das Unit-Test ständig 100% erfüllt hat. Der Auslastungsfaktor wird durch das Verhältnis der vergangenen Zeit zu dem vom Entwickler abgeschätzten Schwierigkeit bestimmt. Der Faktor wird nicht als quantitatives Ziel gesetzt, sondern es erlaubt die Durchführung und Bewertung der Veränderung, die zur Verbesserung des Prozesses führen. Wenn der Terminplan eingehalten ist und die Ergebnisse des Tests positiv sind, werden keine anderen quantitativen Werte untersucht. Einige Kandidaten für die Bewertung könnten zum Beispiel eine bestimmte Anzahl von Unit-Tests bzw. Systemklassen sein. Bei der Betrachtung auf Extreme Programmierung im Zusammenhang mit CMM, besonders wenn XP innerhalb des ganzen Unternehmens eingesetzt wird, könnte man vermuten, dass

15 etwas mehr Messungen bzw. Auswertungen durchgeführt werden müssen als im Rahmen dieses einzelnen Projektes nötig war. Eine interessante Frage unter diesen Umständen ist es, wie viel ist in diese Messungen zu investieren? Eine Empfehlung seitens Extreme Programming wären nur die Werte zu analisieren, bei deren Messung niedrige Kosten entstehen und sich nur dann damit beschäftigen, wenn das wirklich notwendig ist. Ein anderer Ratschlag ist Messungen zu protokollieren, wenn das nicht teuer ist, aber sie nur bei Bedarf aus zu werten. Ansonsten werden die Ressourcen umsonst aufgewendet, die für die weitere Entwicklung eingesetzt werden könnten. Ebene der Optimierung. Eigenschaften: - Fehleranalyse - Verbesserung des Softwareprozesses zwecks der Vermeidung von Fehlern. - Verbreitung der gesammelten Erfahrung innerhalb der Organisation. In einer der Phasen der Extreme Programmierung findet ein Implementierungstest statt. Dabei werden bestimmte Fehler aufgedeckt, die anschießend korrigiert werden müssen, um die Tests zu bestehen. Die Erfahrung aus den erfolgreichen Testfällen wird ferner auf die gleichartigen Anwendungsgebiete übertragen Statistik der Bewertung internationaler Unternehmen durch CMM(I). In diesem Kapitel wird eine Übersicht über den Stand der Reifegrade beziehungsweise Adaptation von CMM(I) verschiedener Organisationen respektive Unternehmen weltweit vermittelt. Die Reifegrade werden durch von dem Software Engineering Institute bereitgestellten Bewertungsmethoden bestimmt. Die Bewertungen werden ab April 2002 innerhalb von 52 Monate, also bis Juli 2006 durchgeführt. In dieser Frist wurden 1581 Bewertungen eingereicht. Abbildung 5 veranschaulicht die Verteilung aller Organisation über die CMM(I) Stufen. Dabei fällt es auf, dass die meisten Unternehmen sich auf den Ebenen zwei und drei positionieren und dabei die Stufen Managed und Defined erreicht haben Ron Jeffries 01/01/

16 Abbildung 5 1 Die Abbildung 6 zeigt die Statistik über die Verteilung der Branchen, aus denen die bewerteten Organisationen stammen. Es wird zwischen kommerziellen Softwarehäusern, die Auftragnehmer für Militär bzw. Regierung und Militär- bzw. Regierungsbehörden unterschieden. Es lässt sich feststellen, dass die kommerzielle Organisation einen überwiegenden Anteil mit einem Wert von 67,6% aufweisen. Abbildung 6 1 Die nächste Abbildung 7 stellt eine Liste mit allen beteiligten Ländern dar. Daraus kann man entnehmen, wie viele Organisationen eines bestimmten Landes einer CMMI Bewertung unterzogen wurden. 1.Software Engineering Institut Appraisal Results September

17 Der höchste Wert hat die USA mit 598 Bewertungen. Danach kommen Indien, China und Japan mit den Werten 177,158 und 155. Und nur 28 Organisation aus Deutschland haben an der Bewertung teilgenommen. Abbildung 7 Aus den oben vorgeführten Statistiken, lässt sich die Folgerung ziehen, dass das CMMI überwiegend in kommerziellen Organisationen verwendet wird. Die daran beteiligten Organisationen sind meistens relativ ausgereift und haben bereit die Stufen Managed und Defined erreicht. In Deutschland bzw. in Europa hat sich das Verfahren nicht durchgesetzt und es wird in großer Anzahl nur lokal in den USA benutzt. 10. Zusammenfassung. Dieser letzte Teil der Arbeit schließt das Thema Capability Maturity Model ab und stellt die Schlussfolgerung dar. Das oben beschriebene Model stellt eine Reihe von Methoden, Techniken und Vorgehensweisen bereit, die es ermöglichen den Reifegrad einer Organisation bzw. der Softwareprozesse dieser Organisation zu bewerten. Der Reifegrad wird in fünf Ebenen eingeteilt. Jede Reifeebene definiert die Maßnahmen, die zur Prozessverbesserung führen, d.h. erlauben einer Organisation effizienter Ihre Ressourcen auf zu wenden. Das CMM war der erste systematische Ansatz zur Prozessverbesserung. Obwohl das Model zuerst für Softwareentwicklungsprojekte entwickelt wurde, kann vieles davon mit nur geringfügigen Anpassungen auch für andere Bereiche verwendet werden. Das CMM bietet eine systematische Möglichkeit zur Verbesserung der Prozessqualität und Identifizierung von Schwächen, deren Behebung besonders wirksam ist. Außerdem wird Evaluierung und damit

18 Vergleich mit anderen Organisationen erlaubt. Darüber hinaus sind einige Nebenwirkungen und Contraargumenten bekannt. Für die Prozessverbesserung sind zusätzliche Kosten zu kalkulieren. Aber im Gegensatz dazu ergeben die empirischen Untersuchungen, dass der Nutzen wesentlich höher ist als die Kosten. Die Optimierung der Prozesse ist nur für die Standardprobleme möglich. Es ist aus verschiedenen Blickwinkeln unbefriedigend und unvollständig. Die Anwendung ist teuer und langsam, daher nur für große Organisationen geeignet. Das Model ist sehr stark technikbezogen und es wurde wenig Rücksicht auf Personal genommen

19 11. Quellen. 1. The Capability Maturity Model:Guidlines for Improving the Software Process Addison-Wesley publishing company ISBN: Software Engineering ISBN Auflage Ron Jeffries 01/01/ Software Engineering Institut Appraisal Results September