Das SEI und CMM. Historie und Zertifizierungsphilosophie/- methodik

Transkript

1 Das SEI und CMM Historie und Zertifizierungsphilosophie/- methodik 1

2 Inhalt 1. SEI 3 2. CMM Geschichte des CMM Motivation 4 Die Problematik 4 Anforderungen 4 Konsequenzen Definitionen Struktur 5 Reifegrad Stufen 5 Überspringen von Stufen 6 Einsehbarkeit durch das Management Organisation innerhalb der Stufen 7 Schlüsselbereiche 7 Gemeinsame Eigenschaften 7 Schlüsseltätigkeiten 7 3. Anwendung Bewertungsprogramm des SEI 8 Programm 8 Qualifikation 8 Verantwortungsbereich von Lead Assessors Zwei Methoden der Bewertung 9 Software Process Assessment 9 Software Capability Evaluation Ablauf eines Assessments 9 4. Literaturverzeichnis 11 2

3 1. SEI Das Software Engineering Institute (SEI) ist ein Institut an der Carnegie Mellon Universität. Es ist ein staatlich gefördertes Forschungs- und Entwicklungszentrum, finanziert durch das U.S. Department of Defense (DoD). Die Hauptabsicht des SEI ist es, anderen (bzw. Kunden) zu messbaren Verbesserungen im Prozess der Software-Entwicklung zu verhelfen [1]. Die Richtigkeit von Software soll dabei nicht erst durch erschöpfende Testzyklen verifiziert, sondern von Anfang an durch richtige Entwicklung garantiert werden. Diese Anforderungen beziehen sich nicht nur auf die Verbesserung der Qualität der Software selbst, sonder auch der Vorhersagbarkeit des Produktionsablaufs. Das SEI betrachtet es als seine Mission, die Beschleunigung der Einführung und Verbreitung von modernen Softwarepraktiken und der vom SEI katalogisierten Software-Egineering (SE) Standards zu forcieren. Dies kann unter anderem durch Ausnutzung bislang schlecht genutzter Technologien und Praktiken erfolgen. Damit sich diese Praktiken dauerhaft etablieren können, ist die Nachhaltigkeit der Kompetenz im SE und Technologie-Übergang ein fester Bestandteil der Absichten des SEI. Das SEI arbeitet direkt mit dem Hauptsponsor - der amerikanischen Regierung - und Industrie zusammen, um die Technologien des SEI möglichst optimal an die Anforderungen der Benutzer anzupassen. Diese Weiterentwicklung und Validierung durch Anwendung bei Kunden ist ein wichtiger Bestandteil des Entwicklungsprozess. Besonders intensiv war die Zusammenarbeit auf diesem Gebiet mit dem U.S Verteidigungsministerium (Department of Defense) [2]. Für die stetige Weiterentwicklung werden mit Industrie und Universitäten Abkommen zu Forschung und Entwicklung geschlossen (CRADA - Cooperative Research and Development Agreements). Letztendlich ist die Zielsetzung des SEI die Etablierung von allgemein anerkannten Richtlinien, den Standards-of-Excellence, die durch das SEI entwickelt und verwaltet werden. 2. CMM Das Capability Maturity Model for Software (SW CMM) ist ein Modell zur Bewertung des Reifegrades der Software-Prozesse von Unternehmen. Es ist sowohl ein qualifizierendes wie auch konstruktives Konzept, das die Fähigkeit eines Unternehmens bewertet, aber auch gleichzeitig die Punkte aufzeigt, die zur Erhöhung des Reifegrades des SE-Prozesses notwendig sind. Das SW-CMM wurde von der Software-Gemeinschaft selbst unter der Schirmherrschaft des SEI entwickelt. Es ist lediglich eines von einer Vielzahl von Produkten und Technologien, die durch das SEI entwickelt wurden und vertrieben werden und ist eines der drei Bestandteile, die auf den CMMI Standard führen. 2.1 Geschichte des CMM Das Prinzip der Qualitätskontrolle besteht seit geraumer Zeit. So ist z.b. bereits 1930 das Werk von Shewart erschienen, das die wesentlichen Prinzipien dieses Gebietes darstellt [4]. Der Grundstein für das CMM lässt sich mit Recht in das Jahr 1979 legen, in dem Crosby mit seinem Buch Qualtiy is for free zum ersten Mal die inkrementelle Ausbildung und Verbesserung von Qualitätsmerkmalen beschreibt [5]. Er entwickelte dabei ein Modell, das genauso wie das CMM ein fünfstufiges Framework besitzt, das auf eine evolutionäre Prozessverbesserung führt. Die ersten, die dieses Modell auf den Software Prozess abbilden, sind Radice und Humphrey, 1985 bei IBM. Ein Jahr später führt Humphrey das Modell beim SEI ein und erweitert es um das Konzept der Reifegrad Stufen (maturity Levels) beginnt nun die eigentliche Entwicklung des CMM. Am U.S. Verteidigungsministerium erkennt man, nachdem über Jahre hinweg die Versprechen von Qualitätsverbesserungen durch die Anwendung neuer Software Methoden und Technologien nicht eingehalten werden konnten, dass das eigentliche Problem die Unfähigkeit den Software-Prozess zu organisieren ist. Auch die besten Innovationen und 3

4 Produkte können ihre Effektivität nicht erreichen, wenn das Projekt, in dem sie zum Einsatz kommen, schlecht organisiert und chaotisch ist. Deswegen beauftragt die US-Regierung das SEI und die Mitre Coorp. mit der Entwicklung eines Systems zur Einschätzung der Fähigkeiten ihrer Software-Hersteller. Daraufhin wurde mit der Entwicklung eines Prozessreifegrad-Frameworks begonnen veröffentlicht das SEI eine kurze Beschreibung des Frameworks und einen Reifegrad- Fragebogen, der für die Unternehmen ein simples Werkzeug zur Aufdeckung von Schwachstellen in ihren SE-Prozessen sein sollte. Dieser Fragebogen wurde allerdings oft als das eigentliche Framework missverstanden, und nicht als Hilfestellung zur Erforschung der Anforderungen an ein solches Model erkannt. In diesem Jahr wurden auch die zentralen Methoden des Software Assessment und der Software Capability Evaluation eingeführt. Nach vierjähriger Entwicklungszeit hat das SEI 1991 durch Vorabversionen und den Fragebogen ein vollständiges Model spezifiziert, CMM Version 1.0. Durch vollständige Ausarbeitung des Frameworks wurde ein Model geschaffen, das einen effektiveren Weg zur Erstellung von Prozess-Optimierung bietet als der Reifegrad-Fragebogen CMM Version 1.1, die 1993 erscheint. Durch die Zusammenarbeit mit Industrie und Regierung wurde das Modell weiter verbessert und es entstand das SW-CMM in der Version 2.0 Draft C. Die Bezeichnung dieser Version lässt schon darauf schließen, dass es sich hierbei um kein endgültiges Produkt handelt. Die eigentliche Einführung der Version 2.0 war für Mitte 1997 geplant, ist jedoch bis heute noch nicht erfolgt [3]. Dies ist darauf zurückzuführen, dass von Seiten der Kunden und der Regierung auf die Integration der einzelnen CMM Konzepte zu einem Gemeinsamen, dem CMMI, mehr Wert gelegt wurde, als auf die Modellpflege des SW-CMM. 2.2 Motivation Problematik Auch die beste Innovationen und Produkte können ihre Effektivität nicht erreichen, wenn das Projekt, in dem sie zum Einsatz kommen, schlecht organisiert und chaotisch ist. Dass dennoch auch in unorganisierten bzw. undisziplinierten Unternehmen teilweise hervorragende Software-Produkte erzeugt werden, ist allein auf die herausragenden Fähigkeiten Einzelner zurückzuführen. Um ein Softwareprojekt in dem Sinne zu wiederholen, dass das Ergebnis ähnlich erfolgreich ist wie das vorherige, ist man zwangsläufig auf dieselben Individuen angewiesen. Nicht vorhandene oder unausgereifte Software-Prozess Spezifikationen führen dazu, dass Termin- und Kostenrahmen der Planung nicht auf realistischen Annahmen beruhen und regelmäßig gesprengt werden. Der dadurch zustande kommende Termindruck zwingt die Firma, Abstriche in den Qualitätsansprüchen zu machen und die Testphase zu vernachlässigen. Anforderungen Dies ist aber keine Basis für die Langzeitplanung von Projekten in Unternehmen. Aus deren Sicht ist es vielmehr wünschenswert, den Softwareprozess vollkommen unabhängig von speziellen Entwicklern organisieren zu können. Vorhersagen über den Ausgang von Projekten die nicht auf den speziellen Fähigkeiten Einzelner beruhen sind wesentlich solider und stabiler. In einem Unternehmen, das über eine ausgereifte Software-Organisation verfügt, besteht in allen Bereichen die Fähigkeit, Softwareentwicklungs- und Wartungsprozesse zu kontrollieren. Es existiert ein stetiger Wissenstransfer zwischen existierenden Entwicklern und Neuangestellten und die einzelnen Tätigkeiten werden gemäß dem geplanten Prozess ausgeführt. Die Unterteilung des gesamten Projekts in einzelne Teilprojekte bzw. Prozesse ist konsistent mit der tatsächlichen Art ihrer Implementierung. Diese definierten Prozesse können nach Bedarf geändert und in kontrollierten Pilot-Test und Kosten-Nutzen-Analysen verbessert werden. Aus dieser Organisation resultiert eine objektive Basis zur Bewertung der Produktqualität und auch von Problemen während des Prozesses. Die Schätzungen für Kosten und Zeitrahmen beruhen auf erfahrungsgemäßen Werten und werden gewöhnlich eingehalten. 4

5 Konsequenzen Aus diesen Unterschieden ergibt sich die Notwendigkeit eines Frameworks für den Softwareprozess Reifegrad. Dieser beschreibt die Entwicklung eines Unternehmens vom chaotischen zum organisierten und ausgereiften Softwareprozess. Ohne einen solchen Rahmen können sich Verbesserungsansätze als ineffektiv erweisen, da die nötigen Grundlagen sonst nicht gegeben sind. Auch wenn Probleme und Schwachstellen in der Produktivität eines Unternehmens bekannt sind, stellt es sich meist als eine schwere Aufgabe heraus, zu bestimmen, welche Verbesserungen zuerst realisiert werden sollen. Um nachhaltige Verbesserungen durchzuführen, ist es nötig einen inkrementellen Plan zu erstellen, um den Reifegrad des Software-Prozesses in Etappen zu erhöhen. Das Software Process Maturity Framework ordnet diese einzelnen Schritte, sodass die Verbesserung jeder Stufe die Grundlage für die nachfolgende Stufe bildet. Auf diese Weise wird durch das Framework eine Roadmap zur stetigen Prozess-Verbesserung beschrieben. 2.3 Definitionen In diesem Abschnitt sollen in kurzer Ausführung für das Thema relevante Ausdrücke erklärt werden, die in diesem Zusammenhang allgemein gebräuchlich sind. Ein Softwareprozess (software process) kann als Menge von Aktivitäten, Methoden, Praktiken und Umsetzungen definiert werden, die man einsetzt um Software und die damit verbundenen Produkte zu entwickeln und zu warten. Die Fähigkeit des Software-Prozesses (Software process capability) beschreibt das Gebiet der zu erwartenden Ergebnisse, die man durch diesen SW-Prozess erhält. Die SW-PC eines Unternehmens ist ein Maß für die Vorhersagbarkeit der Resultate eines SW-Projekts, das dieses Unternehmen durchführt Die SW-Prozess Leistung (Software process performance) gibt die aktuellen Ergebnisse an, die durch Einhaltung bzw. Durchführung eines SW-Prozess erzielt werden. Der SW-Prozess Reifegrad (Software process maturity) ist das Ausmaß, in dem ein SW-Prozess explizit definiert, organisiert, messbar, kontrollierbar und effektiv ist. Reife bedeutet hier auch ein Potenzial für Wachstum der Fähigkeiten. Die Institutionalisierung (Institutionalization) bedeutet den Aufbau einer Infrastruktur im Unternehmen sowie die Bildung einer Unternehmenskultur, die die eingeführten Methoden und Praktiken unterstützt, sodass diese auch fortbestehen, nachdem die, die sie einführten das Unternehmen verlassen haben. 2.4 Struktur des CMM Das CMM liefert ein Framework, das die nötigen Schritte für die Entwicklung eines Unternehmens vom unorganisierten zum vollständig organisierten Softwareprozess in fünf Reifegrad-Stufen einteilt. Diese Stufen bilden sukzessiv das Fundament zur Prozessverbesserung. Eine Reifegrad Stufe (maturity level) beinhaltet eine Menge von Zielsetzungen, die, wenn sie erfüllt werden, eine wichtige Komponente im Software-Prozess stabilisieren. Jede Stufe führt eine andere Komponente in den Software-Prozess ein, was die Fähigkeiten des Unternehmens schrittweise erhöht. Reifegrad Stufen Die fünf Reifegrad Stufen lassen sich wie folgt charakterisieren: 1. Initial: Der Software-Prozess ist ohne besondere Organisation und teilweise chaotisch. Nur wenige Prozesse verlaufen definiert und der Erfolg von Projekten hängt gänzlich von individuellen Leistungen ab. Definitionsgemäß hat jedes Unternehmen diesen anfänglichen Reifegrad. 2. Repeatable: Es ist grundlegendes Projekt-Management vorhanden, um Kosten, Zeitplan und Funktionalität zu überwachen. Das Personal verfügt über die Schulung bzw. Fähigkeiten, um frühere Erfolge bei Projekten mit ähnlichen Anwendungsbereichen wiederholen zu können 5

6 3. Defined: Für sowohl Management als auch technische Abteilung ist der Software-Prozess dokumentiert und in einen unternehmensweiten Standardprozess integriert. In allen Projekten kommt eine jeweils spezialisierte Variante dieses Standardprozess zur Erstellung und Wartung von Software zum Einsatz. Außerdem wird ein Trainingsprogramm für alle Abteilung eingerichtet um die Umsetzung der Anforderungen dieser Stufe zu garantieren 4. Managed: Es existieren detaillierte Grundlagen zur Bemessung des Software-Prozesses und der Qualität der Produkte. Software-Prozesse und Produkte werden anhand dieser Kriterien bewertet und somit kontrolliert. 5. Optimizing: Durch Überwachung und Analyse des Software-Prozess und durch Pilot- Tests von innovativen Ideen und Technologie wird eine stetige Verbesserung des Prozesses erreicht. Abb. 1: Die fünf Reifegrad Stufen des CMM Während in Stufe 1 technische Fähigkeiten für den Erfolg eines Projekts maßgebend sind, richtet sich die Aufmerksamkeit bei den folgenden Stufen immer mehr auf Management und Organisation. Speziell in Stufe 2 liegt das Hauptaugenmerk auf der Verbesserung der Management Vorgänge. Organisationsprozesse und Technologie Übergang werden erst in Stufe 3 thematisiert. Der zentrale Begriff der Integration auf dieser Stufe bedeutet, dass die Ergebnisse eines Prozesse direkt in den nächsten Prozess eingehen. Es stellt sich dadurch ein glatter Informationsfluss im Unternehmen ein. In Level 4 wird die Abweichung von der eigentlichen Projektplanung selbst definiert und somit planbar. Abweichungen, die auf außergewöhnliche Umstände zurückzuführen sind können von normalen Abweichungen unterschieden werden Überspringen von Stufen Das Überspringen von Stufen wird vom SEI als nicht sinnvoll angesehen. Auch wenn ein Unternehmen mit einer bestimmten Reifegrad Stufe bereits in der Lage ist, Technologie und Prozesse umzusetzen, die erst in einer höheren Stufe definiert werden, so heiße dies mithin nicht, das man bereits die nötige Qualifikation dazu erworben habe. Einsehbarkeit durch das Management Die Stufen des Frameworks beschreiben des Weiteren, die Fähigkeit des Managements, Einsicht in den Softwareprozess zu nehmen. Dabei bezieht sich diese Fähigkeit auf den Prozess, nicht etwa auf Spezial-Wissen des Managements. Während bei Level 1 der gesamte Software Prozess für das Management so durchsichtig wie schwarze Magie ist, werden schon bei Stufe zwei Prüfungspunkte in das Projekt eingeführt, die dem Management eine grobe Kontrolle über den Projektverlauf gestatten. In Level 3 werden nun auch die Prozesse 6

7 zwischen diesen Prüfungspunkte verständlich und ersichtlich, da sie nach den im Unternehmen etablierten Standard-Prozessen gegliedert sind. Level 4 ermöglicht es dem Management, den Fortschritt des Projekts mittels der eingeführten quantitativen Maßstäbe zu bewerten. In Level 5 wird die Transparenz für das Management so gesteigert, dass Voraussagen über etwaige Änderungen und Optimierungen verlässlich gemacht werden können. 2.5 Organisation innerhalb der Stufen Neben der bereits geschilderten abstrakten Beschreibung der einzelnen Stufen, definiert das Framework für jede einzelne (nicht Level 1) dieser Stufen eine hierarchische Struktur, die in der untersten Ebene auf konkrete Aufgaben und Zielsetzungen führt. Schlüsselbereiche Jede Stufe besteht aus verschiedenen so genannten key process areas (KPA) oder Schlüsselbereichen. Sie zeigen in jeder Stufe die Gebiete an, auf die sich ein Unternehmen konzentrieren sollte um seinen Softwareprozess zu verbessern. Wenn die Ziele einer KPA projektübergreifend erreicht worden sind, so hat das Unternehmen die Prozess-Fähigkeit institutionalisiert, die durch diese KPA charakterisiert wird. Gemeinsame Eigenschaften Jede dieser KPA ist weiterhin in fünf Sektionen unterteilt, die Gemeinsamen Eigenschaften (common features). Die fünf gemeinsamen Eigenschaften sind Verbindlichkeiten für die Umsetzung (commitment to perform): Schritte, die notwendig sind, um die Etablierung und Nachhaltigkeit des einzuführenden Prozesses zu sichern Voraussetzungen für die Umsetzung (ability to perform): Fähigkeiten, die im Projekt oder Unternehmen vorhanden sein müssen, um die jeweilige KPA zu erfüllen. Dies beinhaltet organisatorische Strukturen, Training und Ressourcen Aktivitäten (activities performed): Schritte, die notwendig sind, um eine KPA zu implementieren. Dies beinhaltet deren Planung, Ausführung, Beobachtung und etwaige Korrekturen Messung und Analyse (measurement and analysis): Notwendigkeiten für das Messen des Prozesses und die Analyse der dadurch erhaltenen Daten Verifikation der Implementierung (verifying implementation): Überprüfung der Konformität der ausgeführten Aktivitäten mit dem etablierten Prozess. Dies beinhaltet Reviews und Prüfung seitens des Management Schlüsseltätigkeiten Die gemeinsamen Eigenschaften legen nun die Schritte fest, die auszuführen sind, um die Ziele der KPA zu erfüllen und somit letztendlich die nächste Stufe zu erreichen. Die Schlüsseltätigkeiten beschreiben die Infrastruktur und Aktivitäten, die am meisten zur effektiven Implementierung und Institutionalisierung der KPA beitragen. Sie besagen, was zu tun ist, um ein bestimmtes Ziel zu erreichen. Sie schreiben nicht vor, wie im Einzelnen dabei zu verfahren ist. CMM schreibt Unternehmen nicht vor, wie sie sich zur Erreichung der Stufen zu verhalten haben. Das Modell charakterisiert vielmehr die Fähigkeiten eines Unternehmens, das eine bestimmte Stufe erreicht hat. 7

8 3. Anwendung Im Zusammenhang mit CMM sind zwei vom SEI entwickelte Methoden für die Bewertung des Reifegrades des Software-Prozesses wichtig: Software Process Assessment und Software Capability Evaluation. Um die allgemeine Philosophie des SEI zu beschreiben, die dahinter steht, soll hier zuerst ein Überblick über das Bewertungsprogramm gegeben werden 3.1 Bewertungsprogramm des SEI Programm Diese Bezeichnung bezieht sich auf die Gesamtheit der Bewertungsmodelle, die durch das SEI verwaltet und organisiert werden. Das Programm beinhaltet neben der SW-CMM Bewertungsmethode noch viele weitere Taxierungsmodelle für Produkte und Technologien des SEI [6]. Das Ziel des SEI ist dabei, das Vertrauen der Kunden in die Qualität der Prozess-Bewertungs- Technologien zu etablieren und zu fördern. Um das zu erreichen, gibt es ein spezielles Ausbildungsprogramm, dessen Abschluss dazu berechtigt, autorisierte Bewertungen im Sinne dieses Programms durchzuführen. Das Programm sucht unter Bewerbern die am meisten qualifizierten aus und bildet sie zu so genannten Lead Appraisers aus. Speziell für SW-CMM sind dies die Lead Assessors. Sie sind autorisiert, die entsprechenden Bewertungen auszuführen. Im Falle von SW-CMM sind das Assessments und Evaluations. Die Lead Appraisers müssen für jede Bewertung einen Bericht über die Ergebnisse beim SEI abliefern. Diese werden vertraulich behandelt und nur zu statistischen Zwecken verwendet. Diese Daten fließen z.b. in den Maturity Report des SEI ein, der zweimal im Jahr veröffentlicht wird und einen Überblick über den Stand des SW-Prozesses in der Industrie gibt. Die Assessement-Methode, die für das SW-CMM benutzt wird, ist CMM-Based Appraisal for Internal Process Improvement - CBA IPI. Methoden wie diese genügen den Anforderungen, die durch das CMM Appraisal Framework (CAF) beschrieben werden. Der Zweck des CAB IPI ist es, die interne Prozessverbesserung von Unternehmen zu fördern. Lead Assessors sind grundsätzlich autorisiert Assessments durchzuführen. Die normale Gangart bei größeren Unternehmen ist es, einen Mitarbeiter zum Lead Assessor ausbilden zu lassen. Dieser kann jedoch auch bei anderen Unternehmen Assessments durchführen, indem er der Lead Assessor des Assessment-Teams bei dem entsprechenden Unternehmen wird. Qualifikation Um ein autorisierter CBA IPI Lead Assessor zu werden müssen die folgenden Bedingungen erfüllt werden [7]: 1. Nachweisbare Teilnahme als Assessment-Team Mitglied bei mindestens zwei Assessments in den zwei vorhergegangenen Jahren 2. Mindestens 10 Jahre Erfahrung im Bereich des Software Engineering, SW-Entwicklung oder SW-Support auf einem angemessenen Gebiet (software design, software quality assurance, requirements analysis, configuration management) 3. Mindestens zwei Jahre Erfahrung mit SW-Projekt Management 4. Graduierung oder vergleichbare Erfahrung in einem angemessenen technischem Gebiet 5. Erfolgreiche Teilnahme am SEI Kursus Introduction to the CMM Wenn diese Vorbedingungen erfüllt sind, kann sich der Bewerber beim SEI für ein CBA Lead Assessor Training anmelden. Nach Abschluss dieses Training ist der Bewerber Candidate Lead Assessor. Als dieser muss er innerhalb der nächsten 12 Monate unter der Aufsicht eines Lead Assessor ein Assessment durchführen. Fällt dieses zur allgemeinen Zufriedenheit aus, so wird der zum vollständig autorisierten Lead Assessor promoviert. 8

9 Verantwortungsbereich von Lead Assessors In Übereinstimmung mit dem SEI werden folgende Verantwortungen des Lead Assessors anerkannt: 1. Es ist sicherzustellen, dass alle Assessment-Team Mitglieder die Ziele des Trainings erfüllen 2. Durchführung des CBA IPI Team Training für Assessment Teams 3. Regelmäßige Führung oder Teilnahme an mindestens zwei Assessments während 24 Monaten 4. Für jedes Assessment muss ein detaillierter Bericht an das SEI übermittelt werden 5. Beschaffung und Benutzung von Materialien für Assessments 6. Benutzung eines neuen Assessment-Kits oder Kauf eines Multi-Assessment-Kits mit Mengenrabatt 7. Erfolgreiche Durchführung von allen notwendigen Upgrades 8. Akzeptierung und Benutzung von neuen Materialen sobald diese Verfügbar sind 9. Mitarbeit in zufälligen Anhörungen des SEI und Durchführung bzw. Teilnahme an allen empfohlenen Fördermaßnahmen, die sich daraus ergeben. Die Autorisierung hat eine Gültigkeit von zwei Jahren. Nach dieser Zeit muss die Autorisation erneuert werden, was kostenpflichtig ist und nicht automatisch geschieht. Für die Erneuerung müssen die Lead Assessors in den vorhergegangenen zwei Jahren die oben beschriebenen Verantwortungen erfüllt haben. 3.2 Zwei Methoden der Bewertung Software Process Assessments Software Process Assessments (SPA) bestimmen den derzeitigen Stand des Softwareprozesses eines Unternehmens. Sie haben das Ziel, die wichtigsten Stellen für Verbesserungen innerhalb des Softwareprozesses aufzudecken. Dieser Vorgang wird von einem Team durchgeführt, das sich am CMM orientiert und mit Hilfe der Schlüsseltätigkeiten, beispielsweise in Zusammenarbeit mit einer SEPG (Software Engineering Process Group), einen Plan zur Verbesserung des Softwareprozesses erstellt. Software Capability Evaluation Software Capability Evaluations (SCE) werden benutzt, um Vertragspartner zu identifizieren, die über die Qualifikation verfügen, eine bestimmte Software zu erstellen. Des Weiteren kann dadurch der Stand des Software-Prozesses bei existierenden Projekten festgestellt werden. Das Ziel ist dabei, Risiken aufzudecken, die mit konkreten Software-Projekten verbunden sind. Dazu gehört die Einhaltung des Zeit- und Kostenrahmens. SCE kommen speziell dann zum Einsatz, wenn ein Unternehmen den Kauf einer Software Lösung plant und unter verschiedenen Anbietern auswählen muss. Die SCE kann dann eingesetzt werden, um eine Vertragspartner auszuwählen und eventuell den Erstellungsprozess zu überwachen und gegebenenfalls zu verbessern. SPA und SCE unterscheiden sich nicht nur in ihrer Motivation, sondern auch durch den Eigentümer des Resultates: Beim Assessment ist der Auftraggeber das Unternehmen selbst, das untersucht werden soll. Bei der Evaluation ist der Auftraggeber ein anderes, als das zu untersuchende Unternehmen. 3.3 Ablauf eines Assessments Obwohl die beiden Verfahren sich in ihrer Zielsetzung und ihrem Anwendungsgebiet unterscheiden, ist die Vorgehensweise in beiden Fällen weitestgehend gleich [2]. 1. Auswahl des Teams: die Mitglieder des Teams müssen mit dem CMM und der Vorgehensweise des Assessment oder Evalutaion vertraut sein. Sie sollten Experten mit Kenntnissen im Gebiet des SE und des Managements sein 9

10 1. Reifegrad Fragebogen (maturity questionnaire): Mitarbeiter bzw. Beauftragte des Unternehmens, das untersucht wird, füllen den Fragebogen aus. 2. Analyse des Fragebogens: die Antworten auf den Fragebogen werden analysiert um festzustellen, auf welchen Gebieten innerhalb des Unternehmens weitere Untersuchungen notwendig sind. Diese Gebiete entsprechen den KPA des CMM. 3. Vor-Ort Inspektion: das Team führt Interviews durch und benutzt (wenn vorhanden) die Dokumentation des Unternehmens, um dessen Software-Prozess besser zu verstehen. Die Interviews und die Auswertung der Dokumentation orientieren sich dabei an den Schlüsselbereichen und den dazugehörigen Schlüsseltätigkeiten. Das Team bewertet nun die Implementierung der KPA des Unternehmens und entscheidet, ob diese den im CMM definierten Zielen genügen. Ist dies nicht der Fall, so muss das Team eine fundierte Begründung für das Urteil liefern. Die Bewertung muss mitunter ohne vollständige Informationen ausgeführt werden, wenn die Geheimhaltung des Unternehmens dies verlangt. 4. Befund (findings): das Team stellt nach Abschluss der Vor-Ort Phase eine Liste mit Erkenntnissen und Befunde zusammen, die die Stärken und Schwächen des Unternehmens hervorheben. Im Falle eines Assessments sind dies die Empfehlungen für die Stellen, an denen eine Verbesserung Erfolgen sollte. Im Falle einer Evaluation werden sie Bestandteil der Risikoanalyse. 5. KPA Profil: Letztendlich stellt das Team die Fähigkeiten und Schwächen in einer Übersicht zusammen, die die erfüllten und nicht erfüllten Schlüsselbereiche innerhalb des Unternehmens aufzeigt. Eine KPA kann dabei als erfüllt gelten und dennoch Schwächen beinhalten, solange diese keinen zu großen Einfluss auf das Gesamtziel haben. Die Ergebnisse solcher Bewertungen können sich selbst dann voneinander unterscheiden, wenn sie hintereinander bei demselben Unternehmen durchgeführt werden. Dies ist auf die jeweilige Reichweite des Verfahrens und die verschiedenen Interpretationsmöglichkeiten des Begriffs "Unternehmen" bei größeren Organisationen zurückzuführen. Dieser kann entweder im Sinne des geographischen Zusammenhangs, gemeinsamen Senior-Managements oder Unternehmensformen wie dem profit and loss center verstanden werden. 4. Zusammenfassung Das SEI hat mit dem CMM ein Framework geschaffen, das sich bis heute weit etabliert hat. Anhand dieses Frameworks ist es Unternehmen möglich, Stärken und Schwächen im Prozessablauf auf einer objektiven Basis zu analysieren. Dies ist der erste Schritt zur Eliminierung von Defiziten und das CMM gibt gleichermaßen eine strukturierte Vorgehensweise vor, anhand derer eine sukzessive Prozessverbesserung planbar und durchführbar wird. Das Framework selbst ist in fünf Stufen unterteilt, welche wiederum hierarchisch strukturiert sind. Als weitere strukturelle Grundelemente sind Schlüsselbereiche, Gemeinsame Eigenschaften sowie Schlüsseltätigkeiten zu nennen. Es existieren zwei verschiedene Methoden, in denen das CMM als Bewertungsmodell zur Anwendung kommt. So können zum einen die Prozessabläufe von beauftragten Unternehmen kontrolliert werden (Software Capability Evaluation), zum anderen kann das Unternehmen selbst als Auftraggeber in Erscheinung treten und die eigenen Prozessfähigkeiten analysieren lassen (Software Process Assessment). Die Autorität der Zertifizierung liegt dabei vollständig beim SEI und wird durch spezielle streng kontrollierte Lizenzierungen an Dritte verliehen. 10

11 5. Literaturverzeichnis [1] About the SEI - [2] Paulk, Curtis, Chrissis and Weber: "Capability Maturity Model for Software, Version 1.1", Software Engineering Institute, CMU/SEI-93-TR-24, DTIC Number ADA263403, February [3] Major decisions for SW-CMM v [4] Shewart - "Principles of statistical Quality Control", 1930 [5] Crosby - "Qualtiy is for free", 1979 [6] SEI Appraiser Program - [7] CBA IPI Lead Assessor Authorization Process