CMMI

Historie von CMMI
Das Capability Maturity Model (CMM) wurde seit 1986 am Software Engineering Institute (SEI) der Carnegie-Mellon Universität in Pittsburgh entwickelt, um dem DoD eine Beurteilung seiner Software-Lieferanten zu ermögliche und 1991 in der Fassung 1.0 veröffentlicht. Seitdem hat es immer wieder Aktualisierungen erfahren, die dann 2002 in das CMMI mündeten. Im Folgenden wird eine knappe Übersicht über das CMMI gegeben.

Das CMMI geht von der Grundannahme aus, dass eine Verbesserung der Software-Entwicklungs-Prozesse innerhalb eines Unternehmens einen wesentlichen Beitrag sowohl zur Verbesserung der Qualität der erstellten Software, als auch zur Genauigkeit der Planung von Terminen und Ressourcen leistet und damit steigt letztendlich auch die Produktivität.

Entwicklungsprozesse umfassen in diesem Zusammenhang auch Prozesse der Projektplanung, des Projektmanagements und die Integration dieser software zentrierten Prozesse in die strategischen Planungen des gesamten Unternehmens.

Je systematischer die Softwareentwicklung geplant und durchgeführt und je besser sie in die unternehmerische Gesamtplanung integriert wird, umso höher ist die Prozess-Reife eines Unternehmens zu bewerten. CMMI bewertet nicht die Qualität der Softwareentwicklung an sich, sondern beschreibt die Prozess-Reife eines Unternehmens.

Die Qualität der entwickelten Software hängt von den Entwicklungsprozessen ab, deren Qualität wiederum von der Prozess-Reife eines Unternehmens bestimmt wird. Prozess-Verbesserung wird nicht mit dem Ziel durchgeführt, die Entwickler schneller arbeiten zu lassen1). Stattdessen soll ein Umfeld geschaffen werden, in dem chaotisches Vorgehen und der Umfang für aufwändige Nacharbeiten an Code, Design oder Architektur drastisch reduziert werden.

Das CMMI fusst auf Beobachtungen in der Industrie. Es handelt sich um systematisch erfasste und gründlich untersuchte Best Practices, also um einen pragmatischen empirischen Ansatz, nicht nur um ein wissenschaftlich begründetes, auf einer Theorie aufgebautes System. Dieses gewährleistet die Eignung für den praktischen Einsatz. Es beinhaltet auch einen gewissen Interpretations- und Beurteilungs-Spielraum, um die speziellen Gegebenheiten eines Unternehmens oder Projektes zu berücksichtigen.

Aufbau von CMMI
Fähigkeitsgradermittlung -> Appraisal
Das Appraisal ist eine Überprüfung einer Organisation hinsichtlich der Umsetzung der Anforderungen nach CMMI. Hierbei wird der Fähigkeitsgrad für jeden Prozess einzeln bestimmt. In der Gesamtheit aller untersuchten Prozesse ergibt sich daraus ein Stärken-Schwächen-Profil, aus dem Verbesserungspotenziale erkennbar werden. Die Anforderungen des jeweils nächsthöheren Fähigkeitsgrades zeigen Möglichkeiten zur Verbesserung der Prozesse auf.
Obwohl sich die Prozesse in Unternehmen natürlich im Detail unterscheiden, lassen sich für bestimmte Bereiche in einem Unternehmen (z.B. die Softwareentwicklung oder für IT-Services) oder Branchen (z.B. Automobilindustrie) Prozesse identifizieren oder Prozessstrukturen erkennen, die als gemeinsame Basis genutzt werden können.

Hier setzen die bekannten Prozessmodelle wie SPICE, CMMI (Capability Maturity Model Integration), ITIL (IT Infrastructure Library) usw. an.

CMMI erfüllt alle oben beschriebenen Anforderungen, um Prozesse erfolgreich einzurichten, sie effektiv und effizient zu leben und zu steuern.

CMMI beschreibt zunächst, welche Prozesse eingerichtet und gelebt werden sollen. Dazu wird das Konzept der Prozessreferenzmodelle eingeführt.

Prozessreferenzmodelle
Die Prozesse sind in sog. Process Areas (PA) zusammengefasst und werden nachfolgend aufgeführt und erklärt.

Prozesse auf der Organisationsebene

  • Organizational Process Focus (OPF)
    • Aufgaben: Kontinuierliche Verbesserung aller Prozesse der Organisation. Dazu gehört das Initialisieren, Erfassen, Bewerten und Verwenden von Verbesserungs-Informationen, wie z. B.
    1. Rückmeldung der Prozess-Anwender über Fehler, Unvollständigkeit, Anwendbarkeit, Vereinfachung
    2. Definition und Erfassung von Messdaten (Metriken) der Prozesse zur Prozess-Bewertung
    3. Verwendung von Ergebnissen aus Reviews und Assessments zur Prozess-Bewertung
    4. Erstellung von sog. Prozess Assets (Dokumentation der Ergebnisse aus den in den vorgenannten Punkten gesammelten Daten und den daraus erfolgten Aktionen einschliesslich der diesen Aktionen zugrunde liegenden Daten und Dokumenten)

  • Organizational Process Definition (OPD)
    • Aufgaben: Definition und Pflegen aller wichtigen Prozesse der Organisation. Die Wichtigkeit der Prozesse ist abhängig von der Organisation und bieten daher einen grossen Interpretations-Spielraum. Als Kriterium dient z.B.
    1. Prozesse mit hohem Risiko (z.B. Bid-Process, Requirement Engineering, etc.)
    2. Prozesse, die sehr häufig angewendet werden (z.B. Dokumentation, Versions-Management, Compilation, Test Management etc.)
    3. gruppen übergreifende Prozesse mit hohem Abstimmungsbedarf (z.B. Projekt Management, Ressourcen Management etc.)

  • Organizational Training (OT)
    • Aufgaben: sicherstellen und nachweisen, dass alle betroffenen Personen qualifiziert sind, ihre Aufgaben wahrzunehmen. Hierzu ist erforderlich:
    1. Der Schulungs-Bedarf der Organisation muss identifiziert werden, z.B. auf Grund der strategischen Planung der Organisation oder auf Grund erforderlicher Qualifikationen in den entsprechenden Rollen der einzelnen Prozess-Gebiete
    2. Ein taktischer Trainings-Plan wird erstellt, der alle organisations- aber nicht projekt-spezifischen Trainings-Aktivitäten enthält
    3. Die Trainings-Aktivitäten werden durchgeführt, bewertet und dokumentiert, um nachvollziehen zu können, dass und mit welchem Erfolg sie durchgeführt wurden
    4. Bewertung der Effektivität des Trainings, um sicherzustellen, dass das Ziel, Vermittlung der erforderlichen Qualifikation, erreicht wurde

      5. Unter Training fallen nicht nur Schulungen im engeren Sinne, sondern auch andere Massnahmen zur Qualifizierung, z.B.
      • Training-on-the-Job, allerdings im Sinne eines echten Trainings und nicht als Vorwand. Das heisst, Systematik, Planung, Qualität des Trainings, und Überprüfung des Trainings-Erfolges am Ende des Trainings sind nachzuweisen.
      • Coaching durch einen erfahrenen Mitarbeiter für Aufgaben, bei denen Erfahrungen vermittelt werden sollen, auch als Begleitung zur theoretischen Ausbildung
      • Studium von Dokumentation, z.B. Prozessbeschreibungen, technische Dokumentation etc., dass aber keine Schulung ersetzt

  • Integrated Project Management (IPM)
    • Aufgaben: Die Einbindung aller Aspekte des Projekt Managements aus CMMI Level 2 in die Prozess-Definition der Organisation. Dieses beinhaltet:
    1. Anpassung der organisationsweiten Prozesse auf einzelne Projekte (Tailoring). Es muss klar definiert werden, wo Tailoring zulässig ist und was mandatory ist
    2. Integration der verschiedenen für das Projekt relevanten Pläne zu einem gemeinsamen Projekt-Plan. Dieser muss nicht aus einem einzigen grossen Dokument, sondern kann aus einem globalen Plan und dazu passend abgestimmten Detail-Plänen für bestimmte Prozess-Bereiche bestehen, wenn dieses sinnvoll ist.
    3. Zusammenarbeit aller Projekt-Beteiligten, dazu gehören alle, die für den Erfolg des Projektes massgebend sind, z.B. Einkauf, Vertrieb, Qualitätswesen, IT.
      4. CMMI fordert hier eine klare und abgestimmte Aufteilung der Verantwortlichkeiten und eine definierte Kommunikations-Struktur, wobei hiermit kontinuierliche Kommunikation und nicht Bürokratismus und Abgrenzung gemeint ist.
    4. Verbesserung und Ausbau der organisationsweiten Prozesse, indem vom Projekt erstellte und von anderen nutzbare Arbeits-Ergebnisse der Organisation zur Verfügung gestellt werden. Das gleiche gilt für die aus dem Projekt gewonnenen Metrics und dokumentierten Erfahrungen -> Process Assets.

  • Risk Management (RSKM)
    • Aufgaben: folgende Verfahren etablieren:
    1. potentielle Probleme identifizieren, bevor sie eingetreten sind.
    2. deren Risiko-Potential analysieren.
    3. Risiko Einstufung vornehmen.
    4. Kosten/Nutzen Analyse erstellen Risiko-Grösse zu Korrektur-Kosten.
    5. die erforderlichen / notwendigen Korrektur-Massnahmen planen.
    6. Anwender sind nachweislich in der Anwendung geschul.t
    7. die Anwendung des Verfahrens wird protokolliert und dokumentiert.
    8. nach Abschluss des Verfahrens erfolgt ein Review, um Erfahrungen für zukünftige Entscheidungsprozess zu gewinnen (= Lessons Learned).
      9. Eine Möglichkeit zur Identifizierung, Bewertung und Einstufung stellt die Fehlermöglichkeit- und Einfluss-Analyse (FMEA -> Failure Mode and Effect Analysis) dar. Wichtig ist, das Risiken auch nach der Identifikation und Einstufung laufend überwacht werden müssen, da sie sich im Laufe der Zeit verändern (können).

  • Decision Analysis and Resolution (DAR)
    • Aufgaben: Bereitstellung von Richtlinien und Verfahren:
    1. Identifikation, Analyse, Bewertung und Auswahl von Lösungsansätzen. Dieses impliziert bereits, dass es nicht nur eine Lösung, sondern in der Regel mehrere alternative Lösungsansätze gibt.
    2. Dieses Verfahren generell auf alle Entscheidungen anwenden.
    3. Bereits per Gesetz oder von der übergeordneten Organisation vorgeschriebene Entscheidung-Prozesse integrieren (z.B. der Bid Process).
    4. Nutzer sind nachweislich in der Anwendung geschult.
    5. die Entscheidungsfindung wird protokolliert und dokumentiert.
    6. Entscheidungsfindungsprozess nach Anwendung/Einführung der gewählten Lösung einem Review unterziehen, um Erfahrungen für zukünftige Entscheidungsprozess zu gewinnen (= Lessons Learned).

    Entwicklungsprozess
    • Requirements Development (RD)
      • Aufgaben: Erweiterung des Requirement Management dahingehend, das aktiv die tatsächlichen Anforderungen ermittelt werden, das heist also Requirements- Analyse
      1. Kunden-Anforderungen
        • Was will der Kunde wirklich.
        • Identifizieren, vervollständigen, konsolidieren und dokumentieren der Erwartungen, Bedürfnisse, Einschränkungen und Schnittstellen, die in der Regel anfangs nicht oder nur unzureichend bekannt sind. Dieses entspricht im V-Modell etwa den Aktivitäten SE1 und SE3.
        • Festlegung, wie Requirements mit dem Kunden abgestimmt und validiert werden.
      2. Produkt-Anforderungen
        • Requirements Analyse zur Implementierung , das heist, herunter brechen der Anforderungen auf die einzelnen Produkt-Komponenten

  • Technical Solution (TS)
    • Aufgaben: basierend auf der Requirement Entwicklung wird die technische Umsetzung entworfen, dokumentiert und implementiert = SW Architecture, SW Design, Coding
    1. Untersuchung von Lösungs-Möglichkeiten
      Damit soll erreicht werden, das nicht nur ein Lösungs-Ansatz betrachtet wird, sondern aus der Auswahl von Lösungsmöglichkeiten, die dann auf Wirtschaftlichkeit, Realisierbarkeit, Wiederverwendbarkeit etc. hin untersucht und nach festgelegten Kriterien bestimmt werden.
    2. Die wichtigsten Entscheidungen und ihre Kriterien sollten in den Entwurfs-Dokumenten nachvollziehbar dokumentiert werden.
    3. Im Rahmen der Lösungs-Auswahl werden auch die festgelegten Requirements reviewed und, falls erforderlich, weiterentwickelt.
    4. technisches Daten-Paket für ein Produkt oder einer Produkt-Komponente:
      hierunter versteht das CMMI die Sammlung der relevanten Anforderungs-, Architektur- und Design-Dokumente mit Begründung für Architektur und Design, Schnittstellen-Anforderungen, Verifikations-Kriterien (Test-Spezifikation, Test-Umgebung, Test-Anforderungen), Randbedingungen zum Einsatz etc. Programm-Code und Produkt-Komponente selbst sind nicht Bestandteil des technischen Daten-Paketes

  • Product Integration (PI)
    • Aufgaben: unter Produkt-Integration versteht CMMI die Integration der einzelnen Komponenten zu einem Produkt.
    1. Aufgabe der Produkt-Integration ist es, auf jeder Ebene die Integration vorzubereiten, durchzuführen und zu evaluieren (testen), bevor die nächste Integrations-Stufe erreicht wird.
    2. Eine häufige Integration, auch von Teilkomponenten mit entsprechenden Test-Dokumenten und Umgebungen, ermöglicht eine frühzeitige Fehler-Erkennung (ein Grundsatz, der im Open Source Entwicklungs-Prozess unter „release often“ bekannt ist) dieses ist auch Bestandteil von iterativen Entwicklungs-Modellen.
    3. Review der Integrations- (Test-)Resultate
    4. Damit eine Produkt-Integration möglich ist, müssen die Schnittstellen nach innen und aussen spezifiziert sein und existieren.
      Daher gehört ein Review der Schnittstelle auf Vollständigkeit, sowie dessen Management zur Produkt-Integration. Bei der Integration von Teilkomponenten müssen eventuell dafür sog. Stubs geschaffen werden (Programm/Schnittstellen-Rümpfe, die es erlauben, Ein- oder Ausgabe-Parameter zu simulieren)

  • Verifikation (VER)
    • Aufgaben: Verifikation ist die Prüfung eines Ergebnisses auf Übereinstimmung mit seiner Spezifikation.

    CMMI formuliert dieses recht allgemein. Gefordert wird aber die dokumentiert Planung, Vorbereitung und Durchführung der Verifikation, sowie Review der Ergebnisse. Ins besondere werden Partner Reviews (four eyes principle) gefordert.
    Kommentar: wichtigsten Methoden zur Verifikation sind statische und dynamische Tests incl. der hierzu notwendigen freigegebenen (gültigen) Dokumente (Test-Plan, Test-Spezifikationen, Test-Protokolle) und andere wie z.B. Code Review und Review der Test-Ergebnisse
    1. Review
        Aufgaben: hiermit sind Partner-Reviews (peer review) gemeint. Partner-Review ist Review unter gleichgestellten, z.B. 2 Software-Entwickler, die gegenseitig ihre Arbeitsprodukte, z.B. Teil eines Source Codes auf Fehler-Freiheit und Konsistenz überprüfen.
        Kommentar: Peer Review hat einen hohen Nutzen, da der jeweils andere Partner über die Qualifikation verfügt, den Source zu verstehen, gleichzeitig aber durch die individuell unterschiedliche Herangehensweise den Source aus einem „anderen Blickwinkel“ betrachtet und daher auch Fehler entdecken kann, die der Ersteller auf Grund von „Betriebsblindheit“ nicht erkennt.
    2. Test
      Aufgaben: Mit Test ist hier generell die Überprüfung einer (SW)-Implementation gegen eine formale (An)-Forderung gemeint.
      Hierunter fallen statische und dynamische Tests
      1. statischer Test:
        Unter statischem Test versteht man die Überprüfung einer Komponente ohne Laufzeit-Bedingungen, z.B.:
        • Lint-Test (lexikalische und syntaktische Überprüfung auf syntaktische Fehler und Einhaltung vorgegebener und konfigurierbarer Regeln, z.B. verbotene Konstrukte, Namens- und Aufruf-Konventionen).
        • Cyclomatic & complexity (z.B. McCoy): Schachtelungstiefe, Rekursion etc.
        • NRC: not reachable code.
        • LOCC: Lines of Code, Lines of Comments.
        • Memory usage (nicht eindeutig, kann sowohl statisch, als auch dynamisch ermittelt werden).
      2. dynamischer Test:
        Unter dynamischen Test versteht man die Ausführung von Code oder Code-Teilen. Dieses kann durch Simulation erfolgen (z.B. C Source Code wird durch einen Interpreter ausgeführt und nach div. Regeln überwacht), Emulation (die Hardware wird per Software emuliert, der Code jedoch mit übersetztem Source Code augeführt) und Kombinationen hieraus, sowie Ausführung in der realen Umgebung.

        Der Code kann mit Überwachungs- und Prüf-Code instrumentiert sein oder er wird durch spezielle Umgebungen in die der Code ausgeführt wird, überwacht.

        Ziel des dynamischen Tests kann Laufzeitverhalten, Speicher-Verbrauch und -Verwaltung, Konformität mit den Anforderungen (SW-Requirements, HW-Requirements, System-Requirements), Funktions-Sicherheit und Fehlerfreiheit sein.
    3. Statical Analysis
      4. Aufgaben: statische Analysen helfen syntaktische, nicht syntaktische und lexikalische Fehler, wie z.B. Syntax-Fehler, Inkonsistenzen, Verstösse gegen Design Rules, Verstösse gegen Komplexität-Regeln etc. zu finden

  • Validation (VAL)
    • Aufgaben: hierunter versteht man die Überprüfung des Produktes gegen die Kunden-Anforderungen hinsichtlich Konformität und Funktionalität

Die HW- & SW-Projekte finden Sie auf der Webseite von heslab Heinrich E. Seifert