CMMI - Kurzanleitung

Prozessverbesserung ist kontinuierliche Verbesserung. Wir können niemals Perfektion erreichen. In diesem Tutorial lernen wir CMM, ein sich ständig weiterentwickelndes und verbesserndes Modell, bei dem der Fokus immer darauf liegt, es besser zu machen. Unsere Reichweite sollte immer unsere Reichweite überschreiten.

Was ist KMG?

  • CMM steht für CFähigkeit MSicherheit Model.

  • Konzentriert sich auf Elemente wesentlicher Praktiken und Prozesse aus verschiedenen Wissensbeständen.

  • Beschreibt vernünftige, effiziente und bewährte Geschäftsmethoden (die Sie bereits ausführen sollten) - kein radikal neuer Ansatz.

  • CMM ist eine Methode zur Bewertung und Messung der Reife des Softwareentwicklungsprozesses einer Organisation.

  • CMM misst die Reife des Softwareentwicklungsprozesses auf einer Skala von 1 bis 5.

  • CMM v1.0 wurde vom Software Engineering Institute (SEI) an der Carnegie Mellon University in Pittsburgh, USA, entwickelt.

  • CMM wurde ursprünglich für die Softwareentwicklung und -wartung entwickelt, später jedoch für -

    • Systemtechnik

    • Lieferantenbeschaffung

    • Integrierte Produkt- und Prozessentwicklung

    • Menschen CMM

    • Softwarebeschaffung

CMM-Beispiele

  • People CMM - Entwickeln, motivieren und binden Sie Projekttalente.

  • Software CMM - Verbessern Sie eine softwarebezogene Entwicklungs- und Wartungsfunktion.

Was ist Reife?

Die Definitionen variieren, aber es wird allgemein angenommen, dass ausgereifte Prozesse -

  • Well-defined,

  • Repeatable,

  • Measured,

  • Analyzed,

  • Verbessert und

  • Effective.

Schlechte, aber ausgereifte Prozesse sind genauso schlecht wie gar keine Reife!

CMM hilft bei der Lösung des Reifeproblems, indem es eine Reihe von Praktiken definiert und einen allgemeinen Rahmen für deren Verbesserung bereitstellt. Der Schwerpunkt von CMM liegt auf der Identifizierung der wichtigsten Prozessbereiche und der beispielhaften Praktiken, die einen disziplinierten Softwareprozess umfassen können.

Unreife vs reife Organisation

Eine unreife Organisation hätte die folgenden Eigenschaften:

  • Prozess während des Projekts improvisiert

  • Genehmigte Prozesse werden ignoriert

  • Reaktiv, nicht proaktiv

  • Unrealistisches Budget und Zeitplan

  • Qualität für Zeitplan geopfert

  • Kein objektives Qualitätsmaß

Im Gegensatz dazu sind die Merkmale einer reifen Organisation wie folgt:

  • Kommunikation und Koordination zwischen Gruppen

  • Arbeit nach Plan durchgeführt

  • Praktiken im Einklang mit Prozessen

  • Prozesse nach Bedarf aktualisiert

  • Gut definierte Rollen / Verantwortlichkeiten

  • Management verpflichtet sich formell

Was ist CMMI?

Das CMM-Integrationsprojekt wurde gegründet, um das Problem der Verwendung mehrerer CMMs zu lösen. Die Mission des CMMI-Produktteams bestand darin, drei zu kombinierenSource Modelsin einem einzigen Verbesserungsrahmen für die Organisationen, die eine unternehmensweite Prozessverbesserung anstreben. Diese drei Quellmodelle sind -

  • Capability Maturity Model für Software (SW-CMM) - v2.0 Draft C.

  • Interim Standard der Electronic Industries Alliance (UVP / IS) - 731 Systems Engineering.

  • IPD-CMM (Integrated Product Development Capability Maturity Model) v0.98.

CMM Integration

  • Erstellt einen ersten Satz integrierter Modelle.

  • Verbessert Best Practices aus Quellmodellen basierend auf den gewonnenen Erkenntnissen.

  • Richtet einen Rahmen für die Integration zukünftiger Modelle ein.

Unterschied zwischen CMM und CMMI

CMM ist ein Referenzmodell für ausgereifte Praktiken in einer bestimmten Disziplin wie Systems Engineering CMM, Software CMM, People CMM, Software Acquisition CMM usw., die jedoch bei Bedarf nur schwer zu integrieren waren.

CMMI ist der Nachfolger des CMM und hat sich zu einem ausgereifteren Richtliniensatz entwickelt. Es wurde entwickelt, um die besten Komponenten der einzelnen CMM-Disziplinen (Software-CMM, People-CMM usw.) zu kombinieren. Es kann auf Produktherstellung, Personalmanagement, Softwareentwicklung usw. angewendet werden.

CMM beschreibt nur das Software-Engineering, während CMM Integrated sowohl das Software- als auch das System-Engineering beschreibt. CMMI umfasst auch die integrierte Prozess- und Produktentwicklung sowie die Lieferantenbeschaffung.

CMMI und Geschäftsziele

Die Ziele von CMMI liegen auf der Hand. Sie sind wie folgt -

  • Produce quality products or services- Das Konzept zur Prozessverbesserung in CMMI-Modellen ist aus dem Qualitätsparadigma von Deming, Juran und Crosby hervorgegangen: Qualitätsprodukte sind das Ergebnis von Qualitätsprozessen. CMMI konzentriert sich stark auf qualitätsbezogene Aktivitäten, einschließlich Anforderungsmanagement, Qualitätssicherung, Verifizierung und Validierung.

  • Create value for the stockholders- Ältere Unternehmen machen mit größerer Wahrscheinlichkeit bessere Kosten- und Ertragsschätzungen als Unternehmen mit geringerer Laufzeit und arbeiten dann im Einklang mit diesen Schätzungen. CMMI unterstützt Qualitätsprodukte, vorhersehbare Zeitpläne und effektive Messungen, um das Management bei der Erstellung genauer und vertretbarer Prognosen zu unterstützen. Diese Prozessreife kann vor Problemen mit der Projektleistung schützen, die den Wert der Organisation in den Augen der Investoren schwächen könnten.

  • Enhance customer satisfaction- Das Erreichen von Kosten- und Zeitplanzielen mit hochwertigen Produkten, die anhand der Kundenbedürfnisse validiert werden, ist eine gute Formel für die Kundenzufriedenheit. CMMI adressiert all diese Bestandteile durch seinen Schwerpunkt auf Planung, Überwachung und Messung sowie durch die verbesserte Vorhersagbarkeit, die mit leistungsfähigeren Prozessen einhergeht.

  • Increase market share- Der Marktanteil ergibt sich aus vielen Faktoren, einschließlich Qualitätsprodukten und -dienstleistungen, Namensidentifikation, Preisgestaltung und Image. Kunden beschäftigen sich gerne mit Lieferanten, die den Ruf haben, ihre Verpflichtungen zu erfüllen.

  • Gain an industry-wide recognition for excellence- Der beste Weg, um einen Ruf für hervorragende Leistungen zu entwickeln, besteht darin, bei Projekten konstant gute Leistungen zu erbringen und qualitativ hochwertige Produkte und Dienstleistungen innerhalb der Kosten- und Zeitplanparameter bereitzustellen. Prozesse, die den CMMI-Anforderungen entsprechen, können diesen Ruf verbessern.

Die CMM-Integration ist ein Modell, das mehrere Disziplinen / Wissensbestände integriert hat. Derzeit stehen Ihnen bei der Auswahl eines CMMI-Modells vier Wissensbestände zur Verfügung.

Systemtechnik

Das Systems Engineering umfasst die Entwicklung kompletter Systeme, die Software enthalten können oder nicht. Systemingenieure konzentrieren sich darauf, Kundenbedürfnisse, -erwartungen und -beschränkungen in Produktlösungen umzuwandeln und diese Produktlösungen über den gesamten Lebenszyklus des Produkts zu unterstützen.

Softwareentwicklung

Software Engineering umfasst die Entwicklung von Softwaresystemen. Softwareentwickler konzentrieren sich auf die Anwendung systematischer, disziplinierter und quantifizierbarer Ansätze für die Entwicklung, den Betrieb und die Wartung von Software.

Integrierte Produkt- und Prozessentwicklung

Die integrierte Produkt- und Prozessentwicklung (IPPD) ist ein systematischer Ansatz, der eine zeitnahe Zusammenarbeit relevanter Stakeholder während der gesamten Lebensdauer des Produkts ermöglicht, um die Bedürfnisse, Erwartungen und Anforderungen der Kunden besser zu erfüllen. Die Prozesse zur Unterstützung eines IPPD-Ansatzes sind in die anderen Prozesse in der Organisation integriert.

Wenn ein Projekt oder eine Organisation IPPD wählt, führt es die IPPD-Best Practices gleichzeitig mit anderen Best Practices aus, die zur Herstellung von Produkten verwendet werden (z. B. im Zusammenhang mit der Systemtechnik). Das heißt, wenn eine Organisation oder ein Projekt IPPD verwenden möchte, muss sie zusätzlich zu IPPD eine oder mehrere Disziplinen auswählen.

Lieferantenbeschaffung

Wenn die Arbeitsanstrengungen komplexer werden, können Projektmanager Lieferanten verwenden, um Funktionen auszuführen oder Änderungen an Produkten hinzuzufügen, die speziell vom Projekt benötigt werden. Wenn diese Aktivitäten kritisch sind, profitiert das Projekt von einer verbesserten Quellenanalyse und von der Überwachung der Lieferantenaktivitäten vor der Produktlieferung. Unter diesen Umständen umfasst die Lieferantenbeschaffungsdisziplin den Erwerb von Produkten von Lieferanten.

Ähnlich wie bei IPPD-Best Practices müssen Best Practices für die Lieferantenbeschaffung in Verbindung mit Best Practices ausgewählt werden, die zur Herstellung von Produkten verwendet werden.

CMMI-Disziplinauswahl

Die Auswahl einer Disziplin kann ein schwieriger Schritt sein und hängt davon ab, was eine Organisation verbessern möchte.

  • Wenn Sie Ihre systemtechnischen Prozesse verbessern, z. B. Konfigurationsmanagement, Messung und Analyse, organisatorischer Prozessfokus, Projektüberwachung und -steuerung, Prozess- und Produktqualitätssicherung, Risikomanagement, Lieferantenvereinbarungsmanagement usw., sollten Sie Systems Engineering (SE) auswählen. Disziplin. Besonderes Augenmerk wird auf die Disziplinverstärkungen für die Systemtechnik gelegt.

  • Wenn Sie Ihre integrierten Produkt- und Prozessentwicklungsprozesse wie Integriertes Teaming, Organisationsumgebung für Integration verbessern, sollten Sie IPPD auswählen. Besonderes Augenmerk wird auf die Disziplinverstärkungen für IPPD gelegt.

  • Wenn Sie Ihre Quellenauswahlprozesse wie das integrierte Lieferantenmanagement verbessern, sollten Sie Supplier Sourcing (SS) auswählen. Besonderes Augenmerk wird auf die Disziplinverstärkungen bei der Lieferantenbeschaffung gelegt.

  • Wenn Sie mehrere Disziplinen verbessern, müssen Sie an allen Bereichen arbeiten, die mit diesen Disziplinen zusammenhängen, und auf alle Disziplinverstärkungen für diese Disziplinen achten.

In den folgenden Kapiteln werden verschiedene Bereiche im Zusammenhang mit der CMMI-Implementierung erörtert.

Das CMMI ist wie folgt aufgebaut:

  • Reifegrade (abgestufte Darstellung) oder Fähigkeitsstufen (kontinuierliche Darstellung)
  • Prozessbereiche
  • Ziele: Allgemein und spezifisch
  • Gemeinsamkeiten
  • Praktiken: Generisch und spezifisch

In diesem Kapitel werden zwei CMMI-Darstellungen behandelt, und der Rest der Themen wird in den folgenden Kapiteln behandelt.

Eine Vertretung ermöglicht es einer Organisation, verschiedene Verbesserungsziele zu verfolgen. Eine Organisation kann einen der folgenden zwei Verbesserungspfade wählen.

Inszenierte Darstellung

Die abgestufte Darstellung ist der im Software-KMG verwendete Ansatz. Bei diesem Ansatz werden vordefinierte Sätze von Prozessbereichen verwendet, um einen Verbesserungspfad für eine Organisation zu definieren. Dieser Verbesserungspfad wird durch eine Modellkomponente beschrieben, die als Reifegrad bezeichnet wird. Ein Reifegrad ist ein genau definiertes Evolutionsplateau zur Erzielung verbesserter Organisationsprozesse.

Inszenierte CMMI-Darstellung

  • Bietet eine bewährte Folge von Verbesserungen, von denen jede als Grundlage für die nächste dient.

  • Ermöglicht Vergleiche zwischen und zwischen Organisationen unter Verwendung von Reifegraden.

  • Bietet eine einfache Migration vom SW-CMM zum CMMI.

  • Bietet eine einzige Bewertung, die die Bewertungsergebnisse zusammenfasst und Vergleiche zwischen Organisationen ermöglicht.

Somit bietet Staged Representation eine vordefinierte Roadmap zur organisatorischen Verbesserung auf der Grundlage einer bewährten Gruppierung und Reihenfolge von Prozessen und den damit verbundenen organisatorischen Beziehungen. Sie können nicht von der Abfolge der Schritte ablenken.

CMMI Staged Structure

Das folgende Bild zeigt die CMMI-Stufenmodellstruktur.

Kontinuierliche Vertretung

Kontinuierliche Darstellung ist der Ansatz, der im SECM und im IPD-CMM verwendet wird. Dieser Ansatz ermöglicht es einer Organisation, einen bestimmten Prozessbereich auszuwählen und darauf basierend Verbesserungen vorzunehmen. Die fortlaufende Darstellung verwendet Fähigkeitsstufen, um die Verbesserung in Bezug auf einen einzelnen Prozessbereich zu charakterisieren.

CMMI Continuous Representation

  • Ermöglicht die Auswahl der Verbesserungsreihenfolge, die den Geschäftszielen Ihres Unternehmens am besten entspricht und die Risikobereiche Ihres Unternehmens verringert.

  • Ermöglicht Vergleiche zwischen und zwischen Organisationen auf Prozessbereichsbasis.

  • Bietet eine einfache Migration von EIA 731 (und anderen Modellen mit kontinuierlicher Darstellung) zu CMMI.

Somit bietet die kontinuierliche Repräsentation Unternehmen Flexibilität bei der Auswahl der zu verbessernden Prozesse sowie des erforderlichen Verbesserungsbetrags.

CMMI Continuous Structure

Das folgende Bild zeigt die kontinuierliche CMMI-Modellstruktur.

Kontinuierliche vs inszenierte Darstellungen

Kontinuierliche Vertretung Inszenierte Darstellung

Prozessbereiche sind nach Prozessbereichskategorien organisiert.

Prozessbereiche sind nach Reifegraden organisiert.

Die Verbesserung wird anhand der Fähigkeitsstufen gemessen. Die Fähigkeitsstufen messen die Reife eines bestimmten Prozesses in einem Unternehmen. es reicht von 0 bis 5.

Die Verbesserung wird anhand des Reifegrades gemessen. Die Reifegrade messen die Reife einer Reihe von Prozessen in einem Unternehmen: Sie reichen von 1 bis 5.

Es gibt zwei Arten spezifischer Praktiken: Basis- und Fortgeschrittenenpraktiken. Alle spezifischen Praktiken erscheinen in der fortlaufenden Darstellung.

Es gibt nur eine Art spezifischer Praxis. Die Konzepte der Basis- und fortgeschrittenen Praktiken werden nicht verwendet. Alle spezifischen Praktiken werden in der abgestuften Darstellung angezeigt, es sei denn, in der fortlaufenden Darstellung wird ein verwandtes Basis-Fortgeschrittenen-Übungspaar angezeigt. In diesem Fall wird nur die erweiterte Praxis in der abgestuften Darstellung angezeigt.

Fähigkeitsstufen werden verwendet, um die allgemeinen Praktiken zu organisieren.

Gemeinsame Funktionen werden verwendet, um allgemeine Praktiken zu organisieren.

Alle allgemeinen Praktiken sind in jedem Prozessbereich enthalten.

Es sind nur die allgemeinen Praktiken der Stufen 2 und 3 enthalten.

Eine gleichwertige Bereitstellung ermöglicht die Bestimmung eines Reifegrades aus dem Leistungsprofil einer Organisation.

Es ist kein Äquivalenzmechanismus erforderlich, um die kontinuierliche Darstellung zu unterstützen, da jede Organisation mithilfe der abgestuften Darstellung auswählen kann, was verbessert und wie stark verbessert werden soll.

Welche Darstellung ist besser?

Jede Darstellung hat ihre Vorteile gegenüber der anderen. Einige Organisationen verwenden beide Darstellungen, um bestimmte Anforderungen zu verschiedenen Zeitpunkten in ihren Verbesserungsprogrammen zu erfüllen.

Die organisatorische Reife steht im Mittelpunkt der inszenierten Repräsentation, während die Prozessbereichsfähigkeit im Mittelpunkt der kontinuierlichen Repräsentation steht.

Organisationsreife und Prozessbereichsfähigkeit sind ähnliche Konzepte. Der Unterschied zwischen ihnen besteht darin, dass sich die organisatorische Reife auf eine Reihe von Prozessbereichen innerhalb einer Organisation bezieht, während sich die Prozessbereichsfähigkeit auf eine Reihe von Prozessen bezieht, die sich auf einen einzelnen Prozessbereich oder eine bestimmte Praxis beziehen.

Das folgende Diagramm zeigt beide Präsentationen. In diesem Diagramm istML zeigt den Reifegrad und an PA Zeigt den Prozessbereich an.

Ein Reifegrad ist ein genau definiertes Evolutionsplateau zur Erreichung eines ausgereiften Softwareprozesses. Jeder Reifegrad bildet eine Grundlage für eine kontinuierliche Prozessverbesserung.

CMMI-Modelle mit abgestufter Darstellung haben fünf Reifegrade, die durch die Nummern 1 bis 5 gekennzeichnet sind. Sie sind -

  • Initial
  • Managed
  • Defined
  • Quantitativ verwaltet
  • Optimizing

Reifegrad der abgestuften CMMI-Repräsentation

Das folgende Bild zeigt die Reifegrade in einer CMMI-gestuften Darstellung.

Jetzt lernen wir die Details zu jedem Reifegrad. Im nächsten Abschnitt werden alle Prozessbereiche aufgelistet, die sich auf diese Reifegrade beziehen.

Details zum Reifegrad

Die Reifegrade bestehen aus einer vordefinierten Reihe von Prozessbereichen. Der Reifegrad wird an der Erreichung des gemessenspecific und generic goalsdie für jeden vordefinierten Satz von Prozessbereichen gelten. In den folgenden Abschnitten werden die Merkmale der einzelnen Reifegrade ausführlich beschrieben.

Reifegrad 1 Initial

Bei Reifegrad 1 sind Prozesse normalerweise ad hoc und chaotisch. Die Organisation bietet normalerweise keine stabile Umgebung. Der Erfolg in diesen Organisationen hängt von der Kompetenz und den Heldentaten der Mitarbeiter in der Organisation ab und nicht von der Verwendung bewährter Prozesse.

Organisationen mit Reifegrad 1 stellen häufig Produkte und Dienstleistungen her, die funktionieren. Sie überschreiten jedoch häufig das Budget und den Zeitplan ihrer Projekte.

Organisationen mit Reifegrad 1 zeichnen sich durch die Tendenz aus, zu viel zu tun, Prozesse in Krisenzeiten abzubrechen und ihre bisherigen Erfolge nicht wiederholen zu können.

Reifegrad 2 verwaltet

Bei Reifegrad 2 hat eine Organisation alle Ziele erreicht specific und generic goalsder Prozessbereiche des Reifegrades 2. Mit anderen Worten, die Projekte der Organisation haben sichergestellt, dass Anforderungen verwaltet und Prozesse geplant, durchgeführt, gemessen und gesteuert werden.

Die Prozessdisziplin, die sich in Reifegrad 2 widerspiegelt, trägt dazu bei, dass bestehende Praktiken in stressigen Zeiten beibehalten werden. Wenn diese Praktiken vorhanden sind, werden Projekte gemäß ihren dokumentierten Plänen durchgeführt und verwaltet.

Auf Reifegrad 2 werden Anforderungen, Prozesse, Arbeitsprodukte und Dienstleistungen verwaltet. Der Status der Arbeitsprodukte und die Erbringung von Dienstleistungen sind für das Management an definierten Punkten sichtbar.

Die Verpflichtungen werden unter den relevanten Stakeholdern festgelegt und bei Bedarf überarbeitet. Arbeitsprodukte werden mit Stakeholdern besprochen und kontrolliert.

Die Arbeitsprodukte und -dienstleistungen erfüllen ihre festgelegten Anforderungen, Standards und Ziele.

Reifegrad 3 definiert

Bei Reifegrad 3 hat eine Organisation alle Ziele erreicht specific und generic goals der Prozessbereiche, die den Reifegraden 2 und 3 zugeordnet sind.

Ab Reifegrad 3 sind Prozesse gut charakterisiert und verstanden und werden in Standards, Verfahren, Werkzeugen und Methoden beschrieben.

Eine kritische Unterscheidung zwischen Reifegrad 2 und Reifegrad 3 ist der Umfang von Standards, Prozessbeschreibungen und Verfahren. Bei Reifegrad 2 können die Standards, Prozessbeschreibungen und Verfahren in jeder spezifischen Instanz des Prozesses (z. B. in einem bestimmten Projekt) sehr unterschiedlich sein.

Bei Reifegrad 3 werden die Standards, Prozessbeschreibungen und Verfahren für ein Projekt aus den Standardprozessen der Organisation auf ein bestimmtes Projekt oder eine bestimmte Organisationseinheit zugeschnitten. Die Standardprozesse der Organisation umfassen die Prozesse, die auf Reifegrad 2 und Reifegrad 3 angesprochen werden. Daher sind die Prozesse, die im gesamten Unternehmen ausgeführt werden, bis auf die Unterschiede, die in den Anpassungsrichtlinien zulässig sind, konsistent.

Ein weiterer kritischer Unterschied besteht darin, dass Prozesse auf Reifegrad 3 in der Regel detaillierter und strenger beschrieben werden als auf Reifegrad 2. Auf Reifegrad 3 werden Prozesse proaktiver verwaltet, indem die Zusammenhänge der Prozessaktivitäten und die detaillierten Maßnahmen von verstanden werden der Prozess, seine Arbeitsprodukte und seine Dienstleistungen.

Reifegrad 4 quantitativ verwaltet

Bei Reifegrad 4 hat eine Organisation alle Ziele erreicht specific goals der Prozessbereiche, die den Reifegraden 2, 3 und 4 zugeordnet sind, und der generic goals den Reifegraden 2 und 3 zugeordnet.

Auf Reifegrad 4 werden Teilprozesse ausgewählt, die wesentlich zur Gesamtprozessleistung beitragen. Diese ausgewählten Teilprozesse werden unter Verwendung statistischer und anderer quantitativer Techniken gesteuert.

Quantitative Ziele für Qualität und Prozessleistung werden festgelegt und als Kriterien für die Verwaltung der Prozesse verwendet. Quantitative Ziele basieren auf den Anforderungen des Kunden, der Endbenutzer, der Organisation und der Prozessimplementierer. Qualität und Prozessleistung werden statistisch verstanden und während der gesamten Lebensdauer der Prozesse verwaltet.

Für diese Prozesse werden detaillierte Messungen der Prozessleistung gesammelt und statistisch analysiert. Spezielle Ursachen für Prozessschwankungen werden identifiziert und gegebenenfalls die Ursachen für spezielle Ursachen korrigiert, um zukünftige Ereignisse zu verhindern.

Qualitäts- und Prozessleistungsmessungen werden in das Messrepository des Unternehmens integriert, um die faktenbasierte Entscheidungsfindung in Zukunft zu unterstützen.

Eine kritische Unterscheidung zwischen Reifegrad 3 und Reifegrad 4 ist die Vorhersagbarkeit der Prozessleistung. Ab dem Reifegrad 4 wird die Leistung von Prozessen mithilfe statistischer und anderer quantitativer Techniken gesteuert und ist quantitativ vorhersehbar. Bei Reifegrad 3 sind Prozesse nur qualitativ vorhersehbar.

Reifegrad 5 Optimierung

Bei Reifegrad 5 hat eine Organisation alle Ziele erreicht specific goalsder Prozessbereiche, die den Reifegraden 2, 3, 4 und 5 zugeordnet sind, und der generic goals den Reifegraden 2 und 3 zugeordnet.

Prozesse werden kontinuierlich verbessert, basierend auf einem quantitativen Verständnis der häufigsten Ursachen von Variationen, die Prozessen inhärent sind.

Diese Ebene konzentriert sich auf die kontinuierliche Verbesserung der Prozessleistung durch schrittweise und innovative technologische Verbesserungen.

Die quantitativen Prozessverbesserungsziele für die Organisation werden festgelegt, kontinuierlich überarbeitet, um sich ändernden Geschäftszielen Rechnung zu tragen, und als Kriterien für das Management der Prozessverbesserung verwendet.

Die Auswirkungen der eingesetzten Prozessverbesserungen werden gemessen und anhand der quantitativen Prozessverbesserungsziele bewertet. Sowohl die definierten Prozesse als auch die Standardprozesse der Organisation sind Ziele messbarer Verbesserungsaktivitäten.

Die Optimierung agiler und innovativer Prozesse hängt von der Teilnahme einer befähigten Belegschaft ab, die auf die Geschäftswerte und -ziele des Unternehmens ausgerichtet ist. Die Fähigkeit des Unternehmens, schnell auf Änderungen und Chancen zu reagieren, wird verbessert, indem Wege gefunden werden, um das Lernen zu beschleunigen und auszutauschen. Die Verbesserung der Prozesse ist von Natur aus eine Rolle, die jeder spielen muss, was zu einem Zyklus kontinuierlicher Verbesserung führt.

Eine kritische Unterscheidung zwischen Reifegrad 4 und Reifegrad 5 ist die Art der angesprochenen Prozessvariation. Bei Reifegrad 4 befassen sich die Prozesse mit der Behandlung spezieller Ursachen für Prozessschwankungen und der statistischen Vorhersagbarkeit der Ergebnisse. Obwohl Prozesse vorhersehbare Ergebnisse liefern können, reichen die Ergebnisse möglicherweise nicht aus, um die festgelegten Ziele zu erreichen. Bei Reifegrad 5 befassen sich die Prozesse mit der Behebung häufiger Ursachen für Prozessschwankungen und der Änderung des Prozesses (dh der Verschiebung der Mittel zur Prozessleistung), um die Prozessleistung zu verbessern (unter Beibehaltung der statistischen Vorhersagbarkeit), um die festgelegten quantitativen Prozessverbesserungsziele zu erreichen .

Reifegrade sollten nicht übersprungen werden

Jeder Reifegrad bietet eine notwendige Grundlage für eine effektive Implementierung von Prozessen auf der nächsten Stufe.

  • Prozesse auf höherer Ebene haben ohne die Disziplin niedrigerer Ebenen weniger Erfolgschancen.

  • Der Effekt von Innovation kann in einem lauten Prozess verdeckt werden.

Prozesse mit höherem Reifegrad können von Organisationen mit niedrigerem Reifegrad durchgeführt werden, wobei das Risiko besteht, dass sie in einer Krise nicht konsequent angewendet werden.

Reifegrade und Prozessbereiche

Hier finden Sie eine Liste aller entsprechenden Prozessbereiche, die für eine Softwareorganisation definiert sind. Diese Prozessbereiche können für verschiedene Organisationen unterschiedlich sein.

Dieser Abschnitt enthält die Namen der zugehörigen Prozessbereiche. Weitere Informationen zu diesen Prozessbereichen finden Sie im Kapitel CMMI-Prozessbereiche.

Niveau Fokus Schlüsselprozessbereich Ergebnis
5

Optimieren

Kontinuierliche Prozessverbesserung

Organisatorische Innovation und Bereitstellung

Ursachenanalyse und -lösung

Höchste Qualität / geringstes Risiko
4

Quantitativ verwaltet

Quantitativ verwaltet

Leistung des Organisationsprozesses

Quantitatives Projektmanagement

Höhere Qualität / geringeres Risiko
3

Definiert

Prozessstandardisierung

Anforderungsentwicklung

Technische Lösung

Produktintegration

Überprüfung

Validierung

Organisationsprozessfokus

Definition des Organisationsprozesses

Organisationstraining

Integrierte Projektverwaltung (mit IPPD-Extras)

Risikomanagement

Entscheidungsanalyse und Auflösung

Integriertes Teaming (nur IPPD)

Org. Integrationsumgebung (nur IPPD)

Integriertes Lieferantenmanagement (nur SS)

Mittlere Qualität / mittleres Risiko
2

Gelang es

Grundlegendes Projektmanagement

Anforderungsmanagement

Projektplanung

Projektüberwachung und -steuerung

Management von Lieferantenvereinbarungen

Messung und Analyse

Prozess- und Produktqualitätssicherung

Konfigurationsmanagement

Geringe Qualität / hohes Risiko
1

Initiale

Prozess ist informell und Adhoc   Niedrigste Qualität / höchstes Risiko

Eine Fähigkeitsstufe ist ein genau definiertes Evolutionsplateau, das die Fähigkeit der Organisation in Bezug auf einen Prozessbereich beschreibt. Eine Fähigkeitsstufe besteht aus verwandten spezifischen und allgemeinen Praktiken für einen Prozessbereich, mit denen die mit diesem Prozessbereich verbundenen Prozesse der Organisation verbessert werden können. Jede Ebene ist eine Grundlage für eine kontinuierliche Prozessverbesserung.

Somit sind Fähigkeitsstufen kumulativ, dh eine höhere Fähigkeitsstufe enthält die Attribute der niedrigeren Stufen.

In CMMI-Modellen mit kontinuierlicher Darstellung gibt es sechs Fähigkeitsstufen, die durch die Nummern 0 bis 5 gekennzeichnet sind.

  • 0 - Unvollständig
  • 1 - Durchgeführt
  • 2 - Verwaltet
  • 3 - Definiert
  • 4 - Quantitativ verwaltet
  • 5 - Optimieren

Eine kurze Beschreibung jeder Fähigkeitsstufe lautet wie folgt:

Fähigkeitsstufe 0: Unvollständig

Ein "unvollständiger Prozess" ist ein Prozess, der entweder nicht oder teilweise ausgeführt wird. Eines oder mehrere der spezifischen Ziele des Prozessbereichs werden nicht erfüllt, und es gibt keine allgemeinen Ziele für diese Ebene, da es keinen Grund gibt, einen teilweise durchgeführten Prozess zu institutionalisieren.

Dies entspricht der Reifegradstufe 1 in der inszenierten Darstellung.

Fähigkeitsstufe 1: Durchgeführt

Ein Prozess der Fähigkeitsstufe 1 ist ein Prozess, von dem erwartet wird, dass er alle spezifischen und allgemeinen Praktiken der Fähigkeitsstufe 1 ausführt. Die Leistung ist möglicherweise nicht stabil und erfüllt möglicherweise nicht bestimmte Ziele wie Qualität, Kosten und Zeitplan. Es kann jedoch nützliche Arbeit geleistet werden. Dies ist nur ein Anfang oder ein kleiner Schritt bei der Prozessverbesserung. Es bedeutet, dass Sie etwas tun, aber Sie können nicht beweisen, dass es wirklich für Sie funktioniert.

Fähigkeitsstufe 2: Verwaltet

Ein verwalteter Prozess wird für einzelne Projekte, Gruppen oder eigenständige Prozesse geplant, durchgeführt, überwacht und gesteuert, um einen bestimmten Zweck zu erreichen. Durch die Verwaltung des Prozesses werden sowohl die Modellziele für den Prozess als auch andere Ziele wie Kosten, Zeitplan und Qualität erreicht. Wie aus dem Titel dieser Ebene hervorgeht, verwalten Sie aktiv die Vorgehensweise in Ihrer Organisation. Sie haben einige Metriken, die konsistent erfasst und auf Ihren Managementansatz angewendet werden.

Note- Metriken werden auf allen Ebenen des CMMI sowohl in der gestuften als auch in der kontinuierlichen Darstellung gesammelt und verwendet. Es ist ein bitterer Irrtum zu glauben, dass ein Unternehmen bis zur Fähigkeitsstufe 4 warten kann, um die Metriken zu verwenden.

Fähigkeitsstufe 3: Definiert

Ein Prozess der Fähigkeitsstufe 3 wird als "definierter Prozess" charakterisiert. Ein definierter Prozess ist ein verwalteter Prozess (Fähigkeitsstufe 2), der aus den Standardprozessen des Unternehmens gemäß den Anpassungsrichtlinien des Unternehmens zugeschnitten wird und Arbeitsprodukte, Maßnahmen und andere Informationen zur Prozessverbesserung in die Prozessressourcen des Unternehmens einbringt.

Fähigkeitsstufe 4: Quantitativ verwaltet

Ein Prozess der Fähigkeitsstufe 4 wird als "quantitativ verwalteter Prozess" charakterisiert. Ein quantitativ verwalteter Prozess ist ein definierter Prozess (Fähigkeitsstufe 3), der mithilfe statistischer und anderer quantitativer Techniken gesteuert wird. Quantitative Ziele für Qualität und Prozessleistung werden festgelegt und als Kriterien für die Verwaltung des Prozesses verwendet. Qualität und Prozessleistung werden statistisch verstanden und während der gesamten Lebensdauer des Prozesses verwaltet.

Fähigkeitsstufe 5: Optimierung

Ein Optimierungsprozess ist ein quantitativ verwalteter Prozess, der verbessert wird, basierend auf dem Verständnis der häufigsten Ursachen für Prozessschwankungen, die dem Prozess inhärent sind. Es konzentriert sich auf die kontinuierliche Verbesserung der Prozessleistung durch schrittweise und innovative Verbesserungen. Sowohl die definierten Prozesse als auch die Standardprozesse der Organisation sind Ziele von Verbesserungsaktivitäten.

Capability Level 4 konzentriert sich auf die Erstellung von Baselines, Modellen und Messungen für die Prozessleistung. Capability Level 5 konzentriert sich darauf, die Leistungsergebnisse im gesamten Unternehmen oder im gesamten Unternehmen zu untersuchen, häufige Ursachen für Probleme bei der Ausführung der Arbeit (die verwendeten Prozesse) zu finden und die Probleme im Prozess zu beheben. Das Update würde die Aktualisierung der Prozessdokumentation und die Schulung umfassen, bei der die Fehler aufgetreten sind.

Organisation von Prozessbereichen in kontinuierlicher Repräsentation

Kategorie Prozessbereich
Projektmanagement
  • Projektplanung
  • Projektüberwachung und -steuerung
  • Management von Lieferantenvereinbarungen
  • Integriertes Projektmanagement (IPPD)
  • Integriertes Lieferantenmanagement (SS)
  • Integriertes Teaming (IPPD)
  • Risikomanagement Quantitatives Projektmanagement
Unterstützung
  • Konfigurationsmanagement
  • Prozess- und Produktqualitätssicherung
  • Messung und Analyse Ursachenanalyse und -auflösung
  • Entscheidungsanalyse und Auflösung
  • Organisationsumfeld für Integration (IPPD)
Maschinenbau
  • Anforderungsmanagement
  • Anforderungsentwicklung
  • Technische Lösung
  • Produktintegration
  • Verification
  • Validation
Prozessmanagement
  • Organisationsprozessfokus
  • Definition des Organisationsprozesses
  • Organisationstraining
  • Leistung des Organisationsprozesses
  • Organisatorische Innovation und Bereitstellung

Ein Prozessbereich ist eine Gruppe verwandter Praktiken in einem Bereich, die bei gemeinsamer Implementierung eine Reihe von Zielen erfüllen, die für eine signifikante Verbesserung in diesem Bereich als wichtig erachtet werden. Alle CMMI-Prozessbereiche sind sowohl kontinuierlichen als auch abgestuften Darstellungen gemeinsam.

Die kontinuierliche Darstellung ermöglicht es der Organisation, den Schwerpunkt ihrer Bemühungen zur Prozessverbesserung zu wählen, indem sie die Prozessbereiche oder Gruppen miteinander verbundener Prozessbereiche auswählt, die der Organisation und ihren Geschäftszielen am besten zugute kommen. Obwohl die Auswahl einer Organisation aufgrund der Abhängigkeiten zwischen den Prozessbereichen begrenzt ist, hat die Organisation erhebliche Entscheidungsfreiheit.

Nachdem Sie die Prozessbereiche ausgewählt haben, müssen Sie auch auswählen, um wie viel Sie die mit diesen Prozessbereichen verbundenen Prozesse verbessern möchten (dh die entsprechende Fähigkeitsstufe auswählen). Fähigkeitsstufen sowie allgemeine Ziele und Praktiken unterstützen die Verbesserung von Prozessen in einzelnen Prozessbereichen.

Umgekehrt werden Sie feststellen, dass die inszenierte Darstellung Sie dazu ermutigt, Prozessbereiche immer im Kontext des Reifegrades zu betrachten, zu dem sie gehören. Die Prozessbereiche sind nach Reifegraden organisiert, um dieses Konzept zu verstärken. Wenn Sie einen Prozessbereich verwenden, verwenden Sie den gesamten Prozessbereich, dh alle Ziele und alle Praktiken.

Die CMMI-Prozessbereiche (PAs) können in die folgenden vier Kategorien eingeteilt werden, um ihre Interaktionen und Verknüpfungen unabhängig von ihren definierten Ebenen zu verstehen:

  • Prozessmanagement

  • Projektmanagement

  • Engineering

  • Support

Jeder Prozessbereich wird durch eine Reihe von Zielen und Praktiken definiert. Es gibt zwei Kategorien von Zielen und Praktiken -

  • Generic goals and practices - Sie sind Teil jedes Prozessbereichs.

  • Specific goals and practices - Sie sind spezifisch für einen bestimmten Prozessbereich.

Ein Prozessbereich ist erfüllt, wenn die Prozesse eines Unternehmens alle allgemeinen und spezifischen Ziele und Praktiken für diesen Prozessbereich abdecken.

Allgemeine Ziele und Praktiken

Generische Ziele und Praktiken sind Teil jedes Prozessbereichs.

NOTATIONS - GG -> Allgemeine Ziele und GP -> Allgemeine Praxis

  • GG 1 Spezifische Ziele erreichen

    • GP 1.1 Führen Sie bestimmte Übungen durch

  • GG 2 Institutionalisieren Sie einen verwalteten Prozess

    • GP 2.1 Festlegen einer Organisationsrichtlinie

    • GP 2.2 Planen Sie den Prozess

    • GP 2.3 Ressourcen bereitstellen

    • GP 2.4 Verantwortung zuweisen

    • GP 2.5 Menschen trainieren

    • GP 2.6 Konfigurationen verwalten

    • GP 2.7 Relevante Stakeholder identifizieren und einbeziehen

    • GP 2.8 Überwachen und steuern Sie den Prozess

    • GP 2.9 Die Einhaltung objektiv bewerten

    • GP 2.10 Status mit höherem Management überprüfen

  • GG 3 Einen definierten Prozess institutionalisieren

    • GP 3.1 Einen definierten Prozess einrichten

    • GP 3.2 Verbesserungsinformationen sammeln

  • GG 4 Institutionalisierung eines quantitativ verwalteten Prozesses

    • GP 4.1 Quantitative Ziele für den Prozess festlegen

    • GP 4.2 Unterprozessleistung stabilisieren

  • GG 5 Institutionalisierung eines Optimierungsprozesses

    • GP 5.1 Kontinuierliche Prozessverbesserung sicherstellen

    • GP 5.2 Richtige Ursachen für Probleme beheben

Gemeinsamkeiten

Die gemeinsamen Merkmale sind Attribute, die angeben, ob die Implementierung und Institutionalisierung eines Schlüsselprozessbereichs effektiv, wiederholbar und dauerhaft ist. Die fünf allgemeinen Merkmale sind unten aufgeführt -

  • Commitment to Perform- Leistungsverpflichtung beschreibt die Maßnahmen, die die Organisation ergreifen muss, um sicherzustellen, dass der Prozess eingerichtet ist und andauert. Die Verpflichtung zur Leistung umfasst in der Regel die Festlegung von Organisationsrichtlinien und das Sponsoring der Geschäftsleitung.

  • Ability to Perform- Leistungsfähigkeit beschreibt die Voraussetzungen, die im Projekt oder in der Organisation vorhanden sein müssen, um den Softwareprozess kompetent zu implementieren. Die Leistungsfähigkeit umfasst in der Regel Ressourcen, Organisationsstrukturen und Schulungen.

  • Activities Performed- Die durchgeführten Aktivitäten beschreiben die Rollen und Verfahren, die zur Implementierung eines wichtigen Prozessbereichs erforderlich sind. Die durchgeführten Aktivitäten umfassen in der Regel die Erstellung von Plänen und Verfahren, die Durchführung der Arbeiten, die Verfolgung und die erforderlichen Korrekturmaßnahmen.

  • Measurement and Analysis- Messung und Analyse beschreibt die Notwendigkeit, den Prozess zu messen und die Messungen zu analysieren. Die Messung und Analyse enthält in der Regel Beispiele für Messungen, die durchgeführt werden können, um den Status und die Wirksamkeit der durchgeführten Aktivitäten zu bestimmen.

  • Verifying Implementation- Überprüfung der Implementierung beschreibt die Schritte, um sicherzustellen, dass die Aktivitäten in Übereinstimmung mit dem festgelegten Prozess ausgeführt werden. Die Überprüfung umfasst in der Regel Überprüfungen und Audits durch das Management und die Qualitätssicherung der Software.

Die Vorgehensweisen in der allgemeinen Funktion Durchgeführte Aktivitäten beschreiben, was implementiert werden muss, um eine Prozessfähigkeit zu etablieren. Die anderen Praktiken bilden als Ganzes die Grundlage, auf der eine Organisation die in der gemeinsamen Funktion "Aktivitäten durchgeführt" beschriebenen Praktiken institutionalisieren kann.

Prozessbereiche im Detail

Das CMMI enthält 22 Prozessbereiche, in denen die Aspekte der Produktentwicklung angegeben sind, die von Unternehmensprozessen abgedeckt werden sollen.

Ursachenanalyse und -lösung

  • Es ist ein Unterstützungsprozessbereich auf Reifegrad 5.

Zweck

Der Zweck von Causal Analysis and Resolution (CAR) soll Ursachen für Mängel und andere Probleme identifizieren und Maßnahmen ergreifen, um deren künftiges Auftreten zu verhindern.

Spezifische Praktiken nach Ziel

  • SG 1 Fehlerursachen ermitteln

    • SP 1.1 Wählen Sie Fehlerdaten für die Analyse

    • SP 1.2 Ursachen analysieren

  • SG 2 Fehlerursachen beheben

    • SP 2.1 Umsetzung der Aktionsvorschläge

    • SP 2.2 Bewertung der Auswirkungen von Änderungen

    • SP 2.3 Daten aufzeichnen

Konfigurationsmanagement

  • Es ist ein Unterstützungsprozessbereich auf Reifegrad 2.

Zweck

Der Zweck von Configuration Management (CM) soll die Integrität von Arbeitsprodukten mithilfe von Konfigurationsidentifikation, Konfigurationssteuerung, Konfigurationsstatusabrechnung und Konfigurationsprüfungen herstellen und aufrechterhalten.

Specific Practices by Goal

  • SG 1 Baselines festlegen

    • SP 1.1 Konfigurationselemente identifizieren

    • SP 1.2 Richten Sie ein Konfigurationsmanagementsystem ein

    • SP 1.3 Baselines erstellen oder freigeben

  • SG 2 Änderungen verfolgen und steuern

    • SP 2.1 Änderungsanforderungen verfolgen

    • SP 2.2 Steuerungskonfigurationselemente

  • SG 3 Integrität herstellen

    • SP 3.1 Konfigurationsverwaltungsdatensätze einrichten

    • SP 3.2 Konfigurationsprüfungen durchführen

Entscheidungsanalyse und Auflösung

  • Es ist ein Unterstützungsprozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Decision Analysis and Resolution (DAR) analysiert mögliche Entscheidungen mithilfe eines formalen Bewertungsprozesses, bei dem identifizierte Alternativen anhand festgelegter Kriterien bewertet werden.

Spezifische Praktiken nach Ziel

  • SG 1 Alternativen bewerten

    • SP 1.1 Richtlinien für die Entscheidungsanalyse festlegen

    • SP 1.2 Bewertungskriterien festlegen

    • SP 1.3 Alternative Lösungen identifizieren

    • SP 1.4 Auswertungsmethoden auswählen

    • SP 1.5 Alternativen bewerten

    • SP 1.6 Lösungen auswählen

Integriertes Projektmanagement + IPPD

  • Es ist ein Projektmanagement-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Integrated Project Management + IPPD (IPM) besteht darin, das Projekt und die Einbeziehung der relevanten Stakeholder gemäß einem integrierten und definierten Prozess zu etablieren und zu verwalten, der auf die Standardprozesse der Organisation zugeschnitten ist.

Spezifische Praktiken nach Ziel

  • SG 1 Verwenden Sie den definierten Prozess des Projekts

    • SP 1.1 Legen Sie den definierten Prozess des Projekts fest

    • SP 1.2 Organisatorische Prozessressourcen für die Planung von Projektaktivitäten verwenden

    • SP 1.3 Richten Sie die Arbeitsumgebung des Projekts ein

    • SP 1.4 Pläne integrieren

    • SP 1.5 Verwalten Sie das Projekt mithilfe der integrierten Pläne

    • SP 1.6 Beitrag zum Organisationsprozessvermögen

  • SG 2 Koordinieren und arbeiten Sie mit relevanten Stakeholdern zusammen

    • SP 2.1 Stakeholder-Beteiligung verwalten

    • SP 2.2 Abhängigkeiten verwalten

    • SP 2.3 Beheben von Koordinierungsproblemen

IPPD-Zusatz -

  • SG 3 IPPD-Prinzipien anwenden

    • SP 3.1 Festlegen der gemeinsamen Vision des Projekts

    • SP 3.2 Aufbau der integrierten Teamstruktur

    • SP 3.3 Anforderungen an integrierte Teams zuweisen

    • SP 3.4 Integrierte Teams aufbauen

    • SP 3.5 Stellen Sie die Zusammenarbeit zwischen Schnittstellenteams sicher

Messung und Analyse

Es ist ein Unterstützungsprozessbereich auf Reifegrad 2.

Zweck

Der Zweck von Measurement and Analysis (MA) soll eine Messfunktion entwickeln und aufrechterhalten, die zur Unterstützung des Bedarfs an Managementinformationen verwendet wird.

Spezifische Praktiken nach Ziel

  • SG 1 Mess- und Analyseaktivitäten ausrichten

    • SP 1.1 Messziele festlegen

    • SP 1.2 Maßnahmen festlegen

    • SP 1.3 Festlegen der Verfahren zur Datenerfassung und -speicherung

    • SP 1.4 Analyseverfahren festlegen

  • SG 2 Messergebnisse liefern

    • SP 2.1 Messdaten erfassen

    • SP 2.2 Messdaten analysieren

    • SP 2.3 Daten und Ergebnisse speichern

    • SP 2.4 Ergebnisse kommunizieren

Organisatorische Innovation und Bereitstellung

Es ist ein Prozessmanagement-Prozessbereich auf Reifegrad 5.

Zweck

Der Zweck von Organizational Innovation and Deployment(OID) ist die Auswahl und Bereitstellung inkrementeller und innovativer Verbesserungen, die die Prozesse und Technologien des Unternehmens messbar verbessern. Die Verbesserungen unterstützen die Qualitäts- und Prozessleistungsziele des Unternehmens, die sich aus den Geschäftszielen des Unternehmens ergeben.

Spezifische Praktiken nach Ziel

  • SG 1 Wählen Sie Verbesserungen

    • SP 1.1 Verbesserungsvorschläge sammeln und analysieren

    • SP 1.2 Innovationen identifizieren und analysieren

    • SP 1.3 Pilot Verbesserungen

    • SP 1.4 Wählen Sie Verbesserungen für die Bereitstellung aus

  • SG 2 Verbesserungen bereitstellen

    • SP 2.1 Planen Sie die Bereitstellungsbereiche

    • SP 2.2 Bereitstellen der Bereitstellung

    • SP 2.3 Verbesserungseffekte messen

Definition des Organisationsprozesses + IPPD (OPD)

Es ist ein Prozessmanagement-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Organizational Process Definition + IPPD (OPD) ist die Einrichtung und Pflege eines nutzbaren Satzes von organisatorischen Prozessressourcen.

Spezifische Praktiken nach Ziel

  • SG 1 Organisationsprozess-Assets etablieren

    • SP 1.1 Standardprozesse etablieren

    • SP 1.2 Erstellen von Beschreibungen des Lebenszyklusmodells

    • SP 1.3 Festlegen von Anpassungskriterien und -richtlinien

    • SP 1.4 Richten Sie das Messrepository der Organisation ein

    • SP 1.5 Richten Sie die Process Asset Library der Organisation ein

IPPD-Zusatz -

  • SG 2 IPPD-Verwaltung aktivieren

    • SP 2.1 Empowerment-Mechanismen etablieren

    • SP 2.2 Regeln und Richtlinien für integrierte Teams festlegen

    • SP 2.3 Verantwortlichkeiten des Balance-Teams und der Heimorganisation

Organisationsprozessfokus

Es ist ein Prozessmanagement-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Organizational Process Focus (OPF) soll die Verbesserung von Organisationsprozessen planen und implementieren, basierend auf einem gründlichen Verständnis der aktuellen Stärken und Schwächen der Prozesse und Prozessressourcen der Organisation.

Spezifische Praktiken nach Ziel

  • SG 1 Bestimmen Sie Möglichkeiten zur Prozessverbesserung

    • SP 1.1 Organisatorische Prozessanforderungen festlegen

    • SP 1.2 Bewertung der Prozesse der Organisation

    • SP 1.3 Identifizieren Sie die Prozessverbesserungen der Organisation

  • SG 2 Planen und Implementieren von Aktivitäten zur Prozessverbesserung

    • SP 2.1 Erstellen von Prozessaktionsplänen

    • SP 2.2 Prozessaktionspläne implementieren

  • SG 3 Bereitstellen von Assets für organisatorische Prozesse und Einbeziehen der gewonnenen Erkenntnisse

    • SP 3.1 Bereitstellen von Organisationsprozess-Assets

    • SP 3.2 Standardprozesse bereitstellen

    • SP 3.3 Monitor-Implementierung

    • SP 3.4 Prozessbezogene Erfahrungen in die organisatorischen Prozessressourcen einbeziehen

Leistung des Organisationsprozesses

Es ist ein Prozessmanagement-Prozessbereich auf Reifegrad 4.

Zweck

Der Zweck von Organizational Process Performance (OPP) besteht darin, ein quantitatives Verständnis der Leistung der Standardprozesse der Organisation zur Unterstützung von Qualitäts- und Prozessleistungszielen zu erstellen und aufrechtzuerhalten und die Prozessleistungsdaten, Baselines und Modelle bereitzustellen, um die Projekte der Organisation quantitativ zu verwalten.

Spezifische Praktiken nach Ziel

  • SG 1 Leistungsgrundlagen und -modelle festlegen

    • SP 1.1 Prozesse auswählen

    • SP 1.2 Festlegen von Prozessleistungsmessungen

    • SP 1.3 Festlegen von Qualitäts- und Prozessleistungszielen

    • SP 1.4 Festlegen der Prozessleistungsgrundlagen

    • SP 1.5 Erstellen von Prozessleistungsmodellen

Organisationstraining

Es ist ein Prozessmanagement-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Organizational Training (OT) ist die Entwicklung der Fähigkeiten und Kenntnisse von Menschen, damit diese ihre Rollen effektiv und effizient ausführen können.

Spezifische Praktiken nach Ziel

  • SG 1 Aufbau einer organisatorischen Schulungsfähigkeit

    • SP 1.1 Festlegen des strategischen Schulungsbedarfs

    • SP 1.2 Bestimmen Sie, welche Schulungsbedürfnisse in der Verantwortung der Organisation liegen

    • SP 1.3 Erstellen Sie einen taktischen Organisationsschulungsplan

    • SP 1.4 Schulungsfähigkeit herstellen

  • SG 2 Notwendige Schulungen anbieten

    • SP 2.1 Schulung durchführen

    • SP 2.2 Schulungsunterlagen erstellen

    • SP 2.3 Bewertung der Trainingseffektivität

Produktintegration

Es ist ein Engineering-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Product Integration (PI) besteht darin, das Produkt aus den Produktkomponenten zusammenzusetzen, sicherzustellen, dass das integrierte Produkt ordnungsgemäß funktioniert, und das Produkt zu liefern.

Spezifische Praktiken nach Ziel

  • SG 1 Vorbereitung für die Produktintegration

    • SP 1.1 Integrationssequenz bestimmen

    • SP 1.2 Richten Sie die Produktintegrationsumgebung ein

    • SP 1.3 Festlegen von Verfahren und Kriterien für die Produktintegration

  • SG 2 Stellen Sie die Schnittstellenkompatibilität sicher

    • SP 2.1 Überprüfen Sie die Schnittstellenbeschreibungen auf Vollständigkeit

    • SP 2.2 Schnittstellen verwalten

  • SG 3 Produktkomponenten zusammenbauen und Produkt liefern

    • SP 3.1 Bestätigen Sie die Bereitschaft der Produktkomponenten zur Integration

    • SP 3.2 Produktkomponenten zusammenbauen

    • SP 3.3 Zusammengebaute Produktkomponenten bewerten

    • SP 3.4 Verpacken und liefern Sie das Produkt oder die Produktkomponente

Projektüberwachung und -steuerung

Es ist ein Projektmanagement-Prozessbereich auf Reifegrad 2.

Zweck

Der Zweck von Project Monitoring and Control (PMC) soll ein Verständnis des Projektfortschritts vermitteln, damit geeignete Korrekturmaßnahmen ergriffen werden können, wenn die Leistung des Projekts erheblich vom Plan abweicht.

Spezifische Praktiken nach Ziel

  • SG 1 Projekt gegen Plan überwachen

    • SP 1.1 Projektplanungsparameter überwachen

    • SP 1.2 Monitor-Verpflichtungen

    • SP 1.3 Projektrisiken überwachen

    • SP 1.4 Datenverwaltung überwachen

    • SP 1.5 Beteiligung der Stakeholder überwachen

    • SP 1.6 Fortschrittskontrollen durchführen

    • SP 1.7 Meilensteinprüfungen durchführen

  • SG 2 Korrekturmaßnahmen zum Schließen verwalten

    • SP 2.1 Probleme analysieren

    • SP 2.2 Korrekturmaßnahmen ergreifen

    • SP 2.3 Korrekturmaßnahmen verwalten

Projektplanung

Es ist ein Projektmanagement-Prozessbereich auf Reifegrad 2.

Zweck

Der Zweck von Project Planning (PP) soll Pläne erstellen und pflegen, die die Projektaktivitäten definieren.

Spezifische Praktiken nach Ziel

  • SG 1 Schätzungen erstellen

    • SP 1.1 Schätzen Sie den Umfang des Projekts

    • SP 1.2 Schätzungen der Arbeitsprodukt- und Aufgabenattribute erstellen

    • SP 1.3 Projektlebenszyklus definieren

    • SP 1.4 Ermittlung von Aufwands- und Kostenschätzungen

  • SG 2 Entwickeln Sie einen Projektplan

    • SP 2.1 Budget und Zeitplan festlegen

    • SP 2.2 Projektrisiken identifizieren

    • SP 2.3 Plan für das Datenmanagement

    • SP 2.4 Plan für Projektressourcen

    • SP 2.5 Plan für benötigte Kenntnisse und Fähigkeiten

    • SP 2.6 Einbeziehung der Stakeholder planen

    • SP 2.7 Erstellen Sie den Projektplan

  • SG 3 Verpflichtung zum Plan einholen

    • SP 3.1 Pläne überprüfen, die sich auf das Projekt auswirken

    • SP 3.2 Arbeits- und Ressourcenebenen abgleichen

    • SP 3.3 Planverpflichtung einholen

Prozess- und Produktqualitätssicherung

Es ist ein Unterstützungsprozessbereich auf Reifegrad 2.

Zweck

Der Zweck von Process and Product Quality Assurance (PPQA) soll Mitarbeitern und Management einen objektiven Einblick in Prozesse und damit verbundene Arbeitsprodukte geben.

Spezifische Praktiken nach Ziel

  • SG 1 Prozesse und Arbeitsprodukte objektiv bewerten

    • SP 1.1 Prozesse objektiv bewerten

    • SP 1.2 Arbeitsprodukte und -dienstleistungen objektiv bewerten

  • SG 2 bietet objektive Einblicke

    • SP 2.1 Kommunizieren und Sicherstellen der Lösung von Nichteinhaltungsproblemen

    • SP 2.2 Aufzeichnungen erstellen

Quantitatives Projektmanagement

Es ist ein Projektmanagement-Prozessbereich auf Reifegrad 4.

Zweck

Der Zweck der Quantitative Project Management Der Prozessbereich (QPM) besteht darin, den definierten Prozess des Projekts quantitativ zu verwalten, um die festgelegten Qualitäts- und Prozessleistungsziele des Projekts zu erreichen.

Spezifische Praktiken nach Ziel

  • SG 1 Das Projekt quantitativ verwalten

    • SP 1.1 Festlegen der Projektziele

    • SP 1.2 Erstellen Sie die definierten Prozesse

    • SP 1.3 Wählen Sie die Unterprozesse aus, die statistisch verwaltet werden sollen

    • SP 1.4 Projektleistung verwalten

  • SG 2 Unterprozessleistung statistisch verwalten

    • SP 2.1 Wählen Sie Maßnahmen und Analysetechniken aus

    • SP 2.2 Statistische Methoden anwenden, um Variationen zu verstehen

    • SP 2.3 Überwachen der Leistung der ausgewählten Unterprozesse

    • SP 2.4 Statistische Verwaltungsdaten aufzeichnen

Anforderungsentwicklung

Es ist ein Engineering-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Requirements Development (RD) dient zur Erstellung und Analyse von Kunden-, Produkt- und Produktkomponentenanforderungen.

Spezifische Praktiken nach Ziel

  • SG 1 Kundenanforderungen entwickeln

    • SP 1.1 Anforderungen ermitteln

    • SP 1.2 Kundenanforderungen entwickeln

  • SG 2 Produktanforderungen entwickeln

    • SP 2.1 Festlegen von Produkt- und Produktkomponentenanforderungen

    • SP 2.2 Zuweisen von Produktkomponentenanforderungen

    • SP 2.3 Schnittstellenanforderungen identifizieren

  • SG 3 Anforderungen analysieren und validieren

    • SP 3.1 Festlegen von Betriebskonzepten und -szenarien

    • SP 3.2 Festlegen einer Definition der erforderlichen Funktionalität

    • SP 3.3 Anforderungen analysieren

    • SP 3.4 Anforderungen analysieren, um ein Gleichgewicht zu erreichen

    • SP 3.5 Anforderungen validieren

Anforderungsmanagement

Es ist ein Engineering-Prozessbereich auf Reifegrad 2.

Zweck

Der Zweck von Requirements Management (REQM) dient dazu, die Anforderungen der Produkte und Produktkomponenten des Projekts zu verwalten und Inkonsistenzen zwischen diesen Anforderungen und den Plänen und Arbeitsprodukten des Projekts zu identifizieren.

Spezifische Praktiken nach Ziel

  • SG 1 Anforderungen verwalten

    • SP 1.1 Machen Sie sich mit den Anforderungen vertraut

    • SP 1.2 Verpflichtung zu Anforderungen einholen

    • SP 1.3 Anforderungsänderungen verwalten

    • SP 1.4 Bidirektionale Rückverfolgbarkeit von Anforderungen aufrechterhalten

    • SP 1.5 Identifizieren Sie Inkonsistenzen zwischen Projektarbeit und Anforderungen

Risikomanagement

Es ist ein Projektmanagement-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Risk Management (RSKM) soll potenzielle Probleme identifizieren, bevor sie auftreten, damit Risikomanagementaktivitäten nach Bedarf während der gesamten Lebensdauer des Produkts oder Projekts geplant und aufgerufen werden können, um nachteilige Auswirkungen auf die Zielerreichung zu verringern.

Spezifische Praktiken nach Ziel

  • SG 1 Bereiten Sie sich auf das Risikomanagement vor

    • SP 1.1 Bestimmen von Risikoquellen und -kategorien

    • SP 1.2 Risikoparameter definieren

    • SP 1.3 Festlegung einer Risikomanagementstrategie

  • SG 2 Risiken identifizieren und analysieren

    • SP 2.1 Risiken identifizieren

    • SP 2.2 Risiken bewerten, kategorisieren und priorisieren

  • SG 3 Risiken mindern

    • SP 3.1 Entwicklung von Risikominderungsplänen

    • SP 3.2 Implementieren von Risikominderungsplänen

Management von Lieferantenvereinbarungen

Es ist ein Projektmanagement-Prozessbereich auf Reifegrad 2.

Zweck

Der Zweck von Supplier Agreement Management (SAM) soll den Erwerb von Produkten von Lieferanten verwalten, für die eine formelle Vereinbarung besteht.

Spezifische Praktiken nach Ziel

  • SG 1 Lieferantenverträge abschließenM

    • SP 1.1 Erfassungsart bestimmen

    • SP 1.2 Lieferanten auswählen

    • SP 1.3 Lieferantenvereinbarungen treffen

  • SG 2 Lieferantenvereinbarungen erfüllen

    • SP 2.1 Führen Sie die Lieferantenvereinbarung aus

    • SP 2.2 Überwachen Sie ausgewählte Lieferantenprozesse

    • SP 2.3 Ausgewählte Lieferantenarbeitsprodukte bewerten

    • SP 2.4 Akzeptieren Sie das erworbene Produkt

    • SP 2.5 Übergangsprodukte

Technische Lösung

Es ist ein Engineering-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Technical Solution(TS) soll Lösungen für Anforderungen entwerfen, entwickeln und implementieren. Lösungen, Designs und Implementierungen umfassen Produkte, Produktkomponenten und produktbezogene Lebenszyklusprozesse, entweder einzeln oder in Kombination.

Spezifische Praktiken nach Ziel

  • SG 1 Wählen Sie Produktkomponentenlösungen aus

    • SP 1.1 Alternative Lösungen und Auswahlkriterien entwickeln

    • SP 1.2 Produktkomponentenlösungen auswählen

  • SG 2 Entwickeln Sie das Design

    • SP 2.1 Entwerfen Sie das Produkt oder die Produktkomponente

    • SP 2.2 Erstellen Sie ein technisches Datenpaket

    • SP 2.3 Entwurfsschnittstellen anhand von Kriterien

    • SP 2.4 Analyse durchführen, kaufen oder wiederverwenden

  • SG 3 Implementieren Sie das Produktdesign

    • SP 3.1 Implementieren Sie das Design

    • SP 3.2 Produktunterstützungsdokumentation entwickeln

Validierung

Es ist ein Engineering-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Validation (VAL) soll nachweisen, dass ein Produkt oder eine Produktkomponente ihren Verwendungszweck erfüllt, wenn es in die vorgesehene Umgebung gebracht wird.

Spezifische Praktiken nach Ziel

  • SG 1 Bereiten Sie die Validierung vor

    • SP 1.1 Wählen Sie Produkte zur Validierung aus

    • SP 1.2 Richten Sie die Validierungsumgebung ein

    • SP 1.3 Validierungsverfahren und -kriterien festlegen

  • SG 2 Produkt oder Produktkomponenten validieren

    • SP 2.1 Validierung durchführen

    • SP 2.2 Validierungsergebnisse analysieren.

Überprüfung

Es ist ein Engineering-Prozessbereich auf Reifegrad 3.

Zweck

Der Zweck von Verification (VER) soll sicherstellen, dass ausgewählte Arbeitsprodukte ihren festgelegten Anforderungen entsprechen.

Spezifische Praktiken nach Ziel

  • SG 1 Zur Überprüfung vorbereiten

    • SP 1.1 Wählen Sie Arbeitsprodukte zur Überprüfung aus

    • SP 1.2 Richten Sie die Überprüfungsumgebung ein

    • SP 1.3 Festlegen von Überprüfungsverfahren und -kriterien

  • SG 2 Peer Reviews durchführen

    • SP 2.1 Bereiten Sie sich auf Peer Reviews vor

    • SP 2.2 Peer Reviews durchführen

    • SP 2.3 Peer-Review-Daten analysieren

  • SG 3 Überprüfen Sie ausgewählte Arbeitsprodukte

    • SP 3.1 Überprüfung durchführen

    • SP 3.2 Verifizierungsergebnisse analysieren

Änderungen an Version 1.2

Hier werden nur die Änderungen berücksichtigt, die an den Prozessbereichen vorgenommen wurden. Ein umfassendes Detail finden Sie auf der SEI-Homepage .

  • Die folgenden Prozessbereiche wurden entfernt (alle auf Reifegrad 3) -

    • Organisationsumfeld für Integration (OEI)

    • Integriertes Teaming (IT)

    • Integriertes Lieferantenmanagement (ISM)

  • Die folgenden Ergänzungen wurden in vorhandenen Prozessbereichen vorgenommen:

    • IPM. SG3 und SG4 wurden eliminiert, neues SG3 wurde hinzugefügt (alle IPPD PAs)

    • OPD. SG wurde hinzugefügt und in eine IPPD-PA umgewandelt

    • OPF. Zwei SPs wurden aus SG extrahiert und zusammen mit zwei neuen SPs SG3 erstellt

    • REQD. SP3.5 wurde in Validate Requirements umbenannt

    • SAM . SP2.1 wurde eliminiert, zwei neue SPs wurden in SG2 hinzugefügt

    • TS. SP1.2 wurde eliminiert

    • VER. SP3.2 wurde in Analyse-Überprüfungsergebnisse umbenannt

Die CMMI-Bewertung ist eine Prüfung eines oder mehrerer Prozesse durch ein geschultes Team von Fachleuten anhand eines Bewertungsreferenzmodells als Grundlage für die Ermittlung der Stärken und Schwächen einer Organisation.

Beurteilungen erfordern Planung. Bestimmen Sie bei der Planung einer Beurteilung Ihrer Organisation den Umfang der Organisationseinheit, welche Disziplinen einbezogen werden sollen, ob das Beurteilungsteam aus Mitgliedern innerhalb oder außerhalb Ihrer Organisation besteht, welche Projekte einbezogen werden sollen, welche Personen befragt werden sollen und welche Art oder Bewertungsklasse notwendig.

Bei der Bewertung werden drei Kategorien von Modellkomponenten berücksichtigt, die im CMMI definiert sind:

  • Required - nur spezifische und allgemeine Ziele.

  • Expected - nur spezifische und allgemeine Praktiken.

  • Informative - umfasst Unterpraktiken und typische Arbeitsprodukte.

Die SEI hat zwei Leitdokumente für CMMI-Bewertungen veröffentlicht -

  • Appraisal Requirements for CMMI (ARC) - Es enthält die Anforderungen für drei Klassen von Bewertungsmethoden, Klasse A, Klasse B und Klasse C. Diese Anforderungen sind die Regeln für die Definition jeder Klasse von Bewertungsmethoden.

  • Standard CMMI Appraisal Method for Process Improvement (SCAMPI) - Das Method Description Document (MDD) ist derzeit die einzige genehmigte Bewertungsmethode der Klasse A.

SCAMPI ist derzeit die einzige zugelassene CMMI-Bewertungsmethode der Klasse A. Das heißt, SCAMPI erfüllt alle Anforderungen einer ARC Class A-Bewertungsmethode und wurde von der SEI genehmigt.

Es gibt drei Klassen von CMMI-Bewertungsmethoden: Klasse A, Klasse B und Klasse C.

SCAMPI Klasse A Bewertung

Eine SCAMPI-Bewertung der Klasse A wird in der Regel durchgeführt, wenn eine Organisation eine Reihe wesentlicher Prozessverbesserungen implementiert hat und ihren Prozess formell mit dem CMMI vergleichen muss. Ein SCAMPI A ist die einzige Bewertungsmethode, die CMMI-Reifegrad- oder Fähigkeitsstufenbewertungen liefert.

Sie können folgende Ergebnisse von einem SCAMPI A erwarten -

  • Eine Bewertung des Reifegrades oder der Fähigkeitsstufe.

  • Ergebnisse, die die Stärken und Schwächen des Prozesses Ihres Unternehmens im Verhältnis zum CMMI beschreiben.

  • Konsens über die wichtigsten Prozessprobleme der Organisation.

  • Eine Bewertungsdatenbank, die das Unternehmen weiterhin verwenden kann, um den Fortschritt der Prozessverbesserung zu überwachen und zukünftige Bewertungen zu unterstützen.

SCAMPI Klasse B Bewertung

Ein SCAMPI B ist erforderlich, wenn eine Organisation ihre Fortschritte auf dem Weg zu einem angestrebten CMMI-Reifegrad bewerten muss, jedoch zu geringeren Kosten als bei einem SCAMPI A. SCAMPI B-Bewertungen liefern detaillierte Ergebnisse und geben die Wahrscheinlichkeit an, dass die bewerteten Praktiken als zufriedenstellend bewertet werden implementiert in einer SCAMPI A-Bewertung.

Eine SCAMPI Class B-Bewertung, eine von drei SEI-Bewertungsmethoden, hilft einem Unternehmen, den Status seines Software- und System-Engineering-Prozesses im Verhältnis zum CMMI mit einem relativ hohen Maß an Vertrauen zu verstehen. Ein SCAMPI B wird häufig durchgeführt, wenn eine Organisation ihren Fortschritt in Richtung eines Ziel-CMMI-Reifegrades genau bewerten muss.

Sie können folgende Ergebnisse von einem SCAMPI B erwarten -

  • Detaillierte Ergebnisse, die die Stärken und Schwächen des Prozesses Ihres Unternehmens im Verhältnis zum CMMI beschreiben.

  • Praxischarakterisierungen, die die Wahrscheinlichkeit angeben, dass die untersuchten Praktiken die Ziele erfüllen und die Absicht des CMMI erfüllen würden.

  • Konsens über die wichtigsten Prozessprobleme der Organisation.

  • Eine FIDO-Datenbank, die das Unternehmen weiterhin verwenden kann, um den Fortschritt der Prozessverbesserung zu überwachen und zukünftige Bewertungen zu unterstützen.

SCAMPI Klasse C Bewertung

SCAMPI C-Beurteilungen sind kürzer und flexibler als SCAMPI A- und B-Beurteilungen und werden durchgeführt, um eine Vielzahl von besonderen Anforderungen zu erfüllen, von einer schnellen Lückenanalyse bis zur Bestimmung der Bereitschaft eines Unternehmens für einen SCAMPI A.

SCAMPI Class C-Beurteilungen, die am wenigsten formale Beurteilungsmethode des SEI, sind hochflexibel und können für eine Vielzahl von Anforderungen durchgeführt werden. SCAMPI C-Beurteilungen sind in der Regel viel kürzer als Beurteilungen der Klassen A und B und werden häufig aus folgenden Gründen durchgeführt:

  • Bieten Sie eine schnelle Lückenanalyse des Prozesses einer Organisation in Bezug auf das CMMI.

  • Bewerten Sie die Angemessenheit eines neuen Prozesses, bevor er implementiert wird.

  • Überwachen Sie die Implementierung eines Prozesses.

  • Bestimmen Sie die Bereitschaft einer Organisation für einen SCAMPI A.

  • Unterstützen Sie die Auswahl eines Lieferanten.

Sie können folgende Ergebnisse von einem SCAMPI C erwarten -

  • Ergebnisse, die die Stärken und Schwächen der bewerteten Prozesse beschreiben. Je nach Bewertungsumfang und Strategie können die Ergebnisse den relevanten CMMI-Komponenten zugeordnet werden.

  • Charakterisierungen, die die Angemessenheit der bewerteten Prozesse gegenüber dem CMMI zusammenfassen.

  • Empfohlene Maßnahmen zur Prozessverbesserung.

  • Eine FIDO-Datenbank, die das Unternehmen weiterhin verwenden kann, um den Fortschritt der Prozessverbesserung zu überwachen und zukünftige Bewertungen zu unterstützen.

Bewertungsklassenmerkmale

Jede Klasse unterscheidet sich durch den Grad der Genauigkeit, der mit der Anwendung der Methode verbunden ist. Klasse A ist am strengsten, Klasse B ist etwas weniger streng und Klasse C ist am wenigsten streng. Die folgende Tabelle gibt einen Überblick über die erwarteten Unterschiede zwischen den Methoden in jeder Klasse.

Eigenschaften Klasse a Klasse b Klasse C
Menge der gesammelten objektiven Beweise Hoch Mittel Niedrig
Bewertung generiert Ja Nein Nein
Ressourcenbedarf Hoch Mittel Niedrig
Teamgröße Groß Mittel Klein
Datenquellen (Instrumente, Interviews und Dokumente) Benötigt alle drei Datenquellen Benötigt nur zwei Datenquellen (eine muss Interviews sein) Benötigt nur eine Datenquelle
Anforderung des Bewertungsteamleiters Autorisierter Lead Appraiser Autorisierter Lead Appraiser oder geschulte und erfahrene Person Person geschult und erfahren

SCAMPI-Grundlagen

SCAMPI ist eine Abkürzung für Standard CMMI Appraisal Method for Process Improvement. Eine SCAMPI-Bewertung muss von einem von SEI autorisierten SCAMPI Lead Appraiser durchgeführt werden. SCAMPI wird von der SCAMPI Product Suite unterstützt, die die SCAMPI-Methodenbeschreibung, den Reifegrad-Fragebogen, Arbeitshilfen und Vorlagen enthält.

Derzeit ist SCAMPI die einzige Methode, die ein Rating liefern kann, die einzige von der SEI anerkannte Methode und die Methode, die für Organisationen am interessantesten ist.

SCAMPI basiert auf Erfahrungen aus früheren Methoden, einschließlich -

  • CBA IPI - CMM-basierte Bewertung zur internen Prozessverbesserung.

  • SCE - Bewertung der Softwarefähigkeit.

  • EIA/IS 732.2 - Der internationale vorläufige Standard mit dem Titel Systems Engineering Assessment Method.

  • SDCE - Bewertung der Fähigkeit zur Softwareentwicklung.

  • FAA-Bewertungsmethode.

In diesem Kapitel werden die Hauptakteure erläutert, die an einer Prozessverbesserung beteiligt sind. Ihre Organisation benötigt jedoch möglicherweise mehr oder weniger Gruppen.

Beachten Sie, dass eine Person viele dieser Rollen gleichzeitig oder seriell erfüllen kann, abhängig von der Größe Ihres Unternehmens und der Komplexität Ihrer PI-Bemühungen (Process Improvement).

Prozessverbesserung

Prozessverbesserungsbemühungen erfordern im Allgemeinen die folgenden Einzelpersonen und Gruppen:

  • PI Sponsor- Die Person aus der Organisation, die für die Überwachung der gesamten PI-Bemühungen verantwortlich ist. Diese Person hat im Allgemeinen die Befugnis, Mittel und Personal zuzuweisen. Diese Person befindet sich normalerweise auf Direktionsebene oder darüber.

  • PI Champion- Dies ist die PR-Person für die PI-Bemühungen, die als EPG-Leiter fungieren kann oder nicht. Diese Person vermarktet die Idee, den Ansatz und die Ergebnisse von PI.

  • Engineering Process Group (EPG) Lead- Diese Person leitet die Gruppe, die Prozesse überprüft. Diese Person weist den EPG-Mitgliedern Aufgaben zu, überwacht ihre Bemühungen und plant die täglichen Aufgaben des EPG.

  • EPG Members- Diese Personen dienen im EPG als Ausschussmitglieder. Sie sind dafür verantwortlich, dass die Dokumentation zur Prozessverbesserung geschrieben und befolgt wird. Sie sind auch dafür verantwortlich, Metriken zu generieren, um den Prozessverbesserungsprozess zu verfolgen. Sie führen die PATs.

  • Process Action Teams (PATs) - Diese Teams erstellen die Dokumentation zur Prozessverbesserung, Richtlinien, Prozesse, Verfahren, Chartas und Aktionspläne.

  • Transition Partner- In der Regel werden ein oder zwei Personen, die externe Berater sind, hinzugezogen, um den Fortschritt bei der Verbesserung der organisatorischen Prozesse einzurichten, zu planen, zu leiten und zu überwachen. Diese Personen bringen Erfahrung in der Prozessverbesserung von mehreren anderen Organisationen und Branchen mit.

Dieses Tutorial befasste sich mit der Struktur von CMMI, die aus den folgenden Komponenten besteht:

  • Reifegrade (abgestufte Darstellung) oder Fähigkeitsstufen (kontinuierliche Darstellung)
  • Prozessbereiche
  • Ziele: Allgemein und spezifisch
  • Gemeinsamkeiten
  • Praktiken: Generisch und spezifisch

Wir haben alle Reifegrade und Fähigkeitsstufen abgedeckt. Darüber hinaus haben wir alle wichtigen Prozessbereiche und die damit verbundenen allgemeinen Ziele, spezifischen Ziele, allgemeinen Merkmale und Praktiken erörtert.

Später haben wir Ihnen eine kurze Einführung in CMMI-Bewertungen gegeben und Ihnen die verschiedenen Bewertungsklassen gezeigt.

Was kommt als nächstes?

SEI CMMI ist ein großes Thema, das in einem kleinen Tutorial nicht erklärt werden kann. Wir empfehlen Ihnen daher dringend, andere CMMI-Ressourcen zu durchsuchen und weitere Informationen zu diesem Thema zu sammeln. Diese Ressourcen sind im Kapitel CMMI-Ressourcen aufgeführt.

Bitte senden Sie mir Ihr Feedback an [email protected]

EIN B. C. D. E. F. G H. ich J. K.
L. M. N. Ö P. Q. R. S. T. U. V.
W. X. Y. Z.

Ability to perform - Ein gemeinsames Merkmal von CMMI-Modellprozessbereichen mit einer abgestuften Darstellung, in der die allgemeinen Praktiken zusammengefasst sind, um sicherzustellen, dass das Projekt und / oder die Organisation über die erforderlichen Ressourcen verfügen.

Acceptance criteria - Die Kriterien, die ein Produkt oder eine Produktkomponente erfüllen muss, um von einem Benutzer, Kunden oder einer anderen autorisierten Stelle akzeptiert zu werden.

Acceptance testing - Formale Tests, die durchgeführt werden, damit ein Benutzer, Kunde oder eine andere autorisierte Stelle feststellen kann, ob ein Produkt oder eine Produktkomponente akzeptiert werden soll.

Achievement profile - In der fortlaufenden Darstellung eine Liste der Prozessbereiche und ihrer entsprechenden Fähigkeitsstufen, die den Fortschritt der Organisation für jeden Prozessbereich darstellen, während die Fähigkeitsstufen durchlaufen werden.

Acquisition - Der Prozess, vertraglich diskrete oder vorgeschlagene Maßnahmen der Akquisitionseinheit zu erhalten, die sich verpflichten würden, in die Beschaffung von Produkten und Dienstleistungen zu investieren.

Acquisition strategy - Der spezifische Ansatz für den Erwerb von Produkten und Dienstleistungen, der auf Überlegungen zu Bezugsquellen, Erwerbsmethoden, Anforderungsspezifikationstypen, Vertrags- oder Vertragsarten und dem damit verbundenen Erwerbsrisiko basiert.

Adequate- Angemessen, angemessen und nach Bedarf in CMMI erscheinen, damit Manager auf allen Ebenen und Praktiker die spezifischen und allgemeinen Ziele und Praktiken im Lichte der Geschäftsziele der Organisation interpretieren können. In einer allgemeinen Praxis für den Prozessbereich des Risikomanagements heißt es beispielsweise: "Bereitstellung angemessener Ressourcen für die Durchführung des Risikomanagementprozesses, die Entwicklung der Arbeitsprodukte und die Bereitstellung der Dienstleistungen des Prozesses." Angemessen könnte durch die Anzahl der Personen, Personen, die die Risiken überwachen müssen usw. zufrieden sein.

Advanced practices - In der fortlaufenden Darstellung alle spezifischen Praktiken mit einer Fähigkeitsstufe von zwei oder höher.

Agreement/contract requirements - Alle technischen und nichttechnischen Anforderungen im Zusammenhang mit einer Akquisition.

Allocated requirement - Anforderung, die die Leistung und Funktionalität einer übergeordneten Anforderung für ein untergeordnetes Architekturelement oder eine Entwurfskomponente ganz oder teilweise erhebt.

Alternative practice- Eine Praxis, die eine oder mehrere generische oder spezifische Praktiken in CMMI-Modellen ersetzt und einen gleichwertigen Effekt zur Erreichung des generischen oder spezifischen Ziels erzielt, das mit Modellpraktiken verbunden ist. Alternative Praktiken sind nicht unbedingt ein Einzelersatz für die allgemeinen oder spezifischen Praktiken.

Appraisal - Eine Beurteilung ist eine Prüfung eines oder mehrerer Prozesse durch ein geschultes Team von Fachleuten anhand eines Bewertungsreferenzmodells als Grundlage für die Ermittlung von Stärken und Schwächen.

Appraisal findings- Die Schlussfolgerungen einer Bewertung, die die wichtigsten Probleme, Probleme oder Möglichkeiten innerhalb des Bewertungsumfangs identifizieren. Es enthält mindestens Stärken und Schwächen, die auf gültigen Beobachtungen beruhen.

Appraisal participants - Mitglieder der Organisationseinheit, die an der Bereitstellung von Informationen während der Beurteilung beteiligt sind.

Appraisal rating- Wie in CMMI-Bewertungsmaterialien verwendet, der Wert, den ein Bewertungsteam entweder (1) einem CMMI-Ziel oder -Prozessbereich, (2) dem Fähigkeitsgrad eines Prozessbereichs oder (3) dem Reifegrad einer Organisationseinheit zuweist. Die Bewertung wird durch Festlegung des definierten Bewertungsprozesses für die verwendete Bewertungsmethode festgelegt.

Appraisal reference model - Wie in CMMI-Bewertungsmaterialien verwendet, korreliert das CMMI-Modell, mit dem ein Bewertungsteam implementierte Prozessaktivitäten korreliert.

Appraisal scope - Die Definition der Grenzen der Bewertung, die die organisatorischen Grenzen und die Grenzen des CMMI-Modells umfasst.

Appraisal team leader - Eine Person, die die Aktivitäten einer Bewertung leitet und die Qualifikationskriterien für Erfahrung, Wissen und Fähigkeiten erfüllt hat, die durch die Bewertungsmethode definiert wurden.

Appropriate - Siehe Definition für Angemessen.

As needed - Siehe Definition für Angemessen.

Assessment - Eine Bewertung ist eine Bewertung, die eine Organisation zum Zwecke der Prozessverbesserung für sich selbst durchführt.

Assignable cause of process variation- In CMMI wird der Begriff "besondere Ursache für Prozessschwankungen" anstelle von "zuweisbare Ursache für Prozessschwankungen" verwendet, um die Konsistenz sicherzustellen. Beide Begriffe sind identisch definiert.

Audit - Eine unabhängige Prüfung eines Arbeitsprodukts oder einer Reihe von Arbeitsprodukten, um festzustellen, ob die Anforderungen erfüllt sind.

Base measure - Eine bestimmte Eigenschaft oder Eigenschaft eines Unternehmens und die Methode zu dessen Quantifizierung.

Base practices - In der fortlaufenden Darstellung alle spezifischen Praktiken mit einer Fähigkeitsstufe von 1.

Baseline- Der Begriff Basislinie wird normalerweise verwendet, um einen solchen Referenzpunkt zu bezeichnen. Eine Basislinie ist eine genehmigte Momentaufnahme des Systems an geeigneten Punkten im Entwicklungslebenszyklus. Eine Baseline bildet eine formale Basis für die Definition nachfolgender Änderungen. Ohne diese Linie oder diesen Bezugspunkt ist der Begriff der Veränderung bedeutungslos.

Business objectives - Von der Geschäftsleitung entwickelte Strategien, die den Fortbestand eines Unternehmens sicherstellen und dessen Rentabilität, Marktanteil und andere Faktoren verbessern sollen, die den Erfolg des Unternehmens beeinflussen.

Capability evaluation- Eine Bewertung durch ein geschultes Team von Fachleuten, die als Diskriminator zur Auswahl von Lieferanten, zur Vertragsüberwachung oder für Anreize eingesetzt werden. Mithilfe von Bewertungen können Entscheidungsträger bessere Akquisitionsentscheidungen treffen, die Leistung von Subunternehmern verbessern und Einblicke in eine Einkaufsorganisation gewähren.

Capability level- Erreichen einer Prozessverbesserung innerhalb eines einzelnen Prozessbereichs. Eine Fähigkeitsstufe wird durch die geeigneten spezifischen und allgemeinen Praktiken für einen Prozessbereich definiert.

Capability level profile- In der fortlaufenden Darstellung eine Liste der Prozessbereiche und ihrer entsprechenden Leistungsstufen. Das Profil kann ein Leistungsprofil sein, wenn es den Fortschritt der Organisation für jeden Prozessbereich darstellt, während die Fähigkeitsstufen durchlaufen werden. Oder das Profil kann ein Zielprofil sein, wenn es ein Ziel für die Prozessverbesserung darstellt.

Capability maturity model- Ein Fähigkeitsreife-Modell (CMM) enthält die wesentlichen Elemente effektiver Prozesse für eine oder mehrere Disziplinen. Es beschreibt auch einen evolutionären Verbesserungspfad von ad hoc unreifen Prozessen zu disziplinierten, ausgereiften Prozessen mit verbesserter Qualität und Effektivität.

Capable process - Ein Prozess, der die festgelegten Ziele für Produktqualität, Servicequalität und Prozessleistung erfüllen kann.

Causal analysis - Die Analyse von Mängeln, um ihre Ursache zu bestimmen.

Change management - Umsichtiger Einsatz von Mitteln, um eine Änderung oder vorgeschlagene Änderung an einem Produkt oder einer Dienstleistung vorzunehmen.

CMMI appraisal tailoring- Auswahl von Optionen innerhalb der Bewertungsmethode zur Verwendung in einer bestimmten Instanz. Die Absicht der Bewertungsanpassung besteht darin, eine Organisation bei der Ausrichtung der Anwendung der Methode auf ihre Geschäftsziele zu unterstützen.

CMMI model component- Jedes der wichtigsten Architekturelemente, aus denen ein CMMI-Modell besteht. Einige der Hauptelemente eines CMMI-Modells umfassen spezifische Praktiken, generische Praktiken, spezifische Ziele, generische Ziele, Prozessbereiche, Fähigkeitsstufen und Reifegrade.

CMMI model tailoring- Verwendung einer Teilmenge eines CMMI-Modells, um es für eine bestimmte Anwendung geeignet zu machen. Die Absicht der Modellanpassung besteht darin, eine Organisation bei der Ausrichtung der Anwendung eines Modells auf ihre Geschäftsziele zu unterstützen.

CMMI Product Suite - Dieser Begriff wurde für ein vollständiges CMMI-Framework verwendet.

Commitment to perform - Ein gemeinsames Merkmal der Prozessbereiche des CMMI-Modells mit einer abgestuften Darstellung, in der die allgemeinen Praktiken zur Erstellung von Richtlinien und zur Sicherung des Sponsorings zusammengefasst sind.

Common cause of process variation - Die Variation eines Prozesses, die aufgrund normaler und erwarteter Wechselwirkungen zwischen den Komponenten eines Prozesses besteht.

Concept of operations - Eine allgemeine Beschreibung der Art und Weise, wie ein Unternehmen verwendet wird oder arbeitet.

Configuration audit - Ein Audit, das durchgeführt wird, um zu überprüfen, ob ein Konfigurationselement einem bestimmten Standard oder einer bestimmten Anforderung entspricht.

Configuration baseline- Die Konfigurationsinformationen, die zu einem bestimmten Zeitpunkt während der Lebensdauer eines Produkts oder einer Produktkomponente offiziell festgelegt wurden. Konfigurationsbasislinien sowie genehmigte Änderungen gegenüber diesen Basislinien bilden die aktuellen Konfigurationsinformationen.

Configuration control - Ein Element des Konfigurationsmanagements, das aus der Bewertung, Koordination, Genehmigung oder Ablehnung und Implementierung von Änderungen an Konfigurationselementen nach formeller Festlegung ihrer Konfigurationsidentifikation besteht.

Configuration control board - Eine Gruppe von Personen, die dafür verantwortlich sind, vorgeschlagene Änderungen an Konfigurationselementen zu bewerten und zu genehmigen oder abzulehnen und die Umsetzung genehmigter Änderungen sicherzustellen.

Configuration identification - Ein Element des Konfigurationsmanagements, das darin besteht, die Konfigurationselemente für ein Produkt auszuwählen, ihnen eindeutige Kennungen zuzuweisen und ihre funktionalen und physikalischen Eigenschaften in der technischen Dokumentation aufzuzeichnen.

Configuration item - Eine Aggregation von Arbeitsprodukten, die für das Konfigurationsmanagement vorgesehen ist und im Konfigurationsmanagementprozess als eine Einheit behandelt wird.

Configuration management- Eine Disziplin, die technische und administrative Anweisungen und Überwachung anwendet, um (1) die funktionalen und physischen Merkmale eines Konfigurationselements zu identifizieren und zu dokumentieren, (2) Änderungen an diesen Merkmalen zu kontrollieren, (3) den Verarbeitungs- und Implementierungsstatus von Änderungen aufzuzeichnen und zu melden und ( 4) Überprüfen Sie die Einhaltung der festgelegten Anforderungen. [IEEE Std 610.1990]

CMMI Model- Da das CMMI-Framework je nach den Anforderungen der Organisation, die es verwendet, unterschiedliche Modelle generieren kann, gibt es mehrere CMMI-Modelle. Folglich könnte der Ausdruck "CMMI-MODELL" eine von vielen Informationssammlungen sein. Der Ausdruck "CMMI-Modelle" bezieht sich auf ein, einige oder die gesamte Sammlung möglicher Modelle, die aus dem CMMI-Framework generiert werden können.

Configuration status accounting- Ein Element des Konfigurationsmanagements, das aus der Aufzeichnung und Berichterstellung von Informationen besteht, die zur effektiven Verwaltung einer Konfiguration erforderlich sind. Diese Informationen enthalten eine Liste der genehmigten Konfigurationsidentifikation, den Status der vorgeschlagenen Änderungen an der Konfiguration und den Implementierungsstatus der genehmigten Änderungen.

Continuous representation - Eine Struktur des Fähigkeitsreifegradmodells, in der Fähigkeitsstufen eine empfohlene Reihenfolge für die Annäherung an die Prozessverbesserung in jedem angegebenen Prozessbereich bereitstellen.

Corrective action - Handlungen oder Taten, die verwendet werden, um eine Situation zu beheben, einen Fehler zu beseitigen oder eine Bedingung anzupassen.

COTS - Artikel, die bei einem kommerziellen Anbieter gekauft werden können.

Customer- Ein Kunde ist die Person, das Projekt, die Organisation, die Gruppe usw., die für die Annahme des Produkts oder die Autorisierung der Zahlung verantwortlich ist. Der Kunde befindet sich außerhalb des Projekts, jedoch nicht unbedingt außerhalb der Organisation. Der Begriff Kunde dient auch als Variable, wenn es um das Sammeln oder Ermitteln von Anforderungen geht.

Data management - Grundsätze, Prozesse und Systeme für den Austausch und die Verwaltung von Daten.

Defect density - Anzahl der Fehler pro Einheit der Produktgröße (z. B. Problemberichte pro 1000 Codezeilen).

Defined process - Eine definierte Reihe von Schritten, die als Teil der Verbesserung zu befolgen sind.

Derived measures - Daten, die sich aus der mathematischen Funktion von zwei oder mehr Basismaßnahmen ergeben.

Derived requirements- Anforderungen, die nicht ausdrücklich in den Kundenanforderungen angegeben sind, aber (1) aus kontextbezogenen Anforderungen (z. B. anwendbaren Standards, Gesetzen, Richtlinien, gängigen Praktiken und Managemententscheidungen) oder (2) aus Anforderungen abgeleitet werden, die zur Spezifizierung eines Produkts erforderlich sind Komponente. Abgeleitete Anforderungen können auch bei der Analyse und Konstruktion von Komponenten des Produkts oder Systems auftreten.

Design review - Eine formale, dokumentierte, umfassende und systematische Prüfung eines Entwurfs, um die Entwurfsanforderungen und die Fähigkeit des Entwurfs zu bewerten, diese Anforderungen zu erfüllen, Probleme zu identifizieren und Lösungen vorzuschlagen.

Development- Entwicklung, wie sie im gesamten CMMI verwendet wird, umfasst sowohl Wartungsaktivitäten als auch Entwicklungsaktivitäten. Die Erfahrung hat gezeigt, dass Best Practices sowohl für Entwicklungs- als auch für Wartungsprojekte angewendet werden sollten, wenn eine Organisation nach technischer Exzellenz strebt.

Developmental plan - Ein Plan zur Steuerung, Implementierung und Kontrolle des Designs und der Entwicklung eines oder mehrerer Produkte.

Directing implementation - Ein gemeinsames Merkmal der Prozessbereiche des CMMI-Modells mit einer abgestuften Darstellung, in der die allgemeinen Praktiken für die Verwaltung der Prozessleistung, die Verwaltung der Integrität seiner Arbeitsprodukte und die Einbeziehung relevanter Stakeholder zusammengefasst sind.

Discipline amplification- Modellkomponenten, die Anleitungen zur Interpretation von Modellinformationen für bestimmte Disziplinen (z. B. Systemtechnik oder Softwareentwicklung) bieten, werden als "DISZIPLINVERSTÄRKUNGEN" bezeichnet. Bei Bedarf werden anderen Modellkomponenten Disziplinverstärkungen hinzugefügt. Diese sind leicht zu finden, da sie auf der rechten Seite der Seite angezeigt werden und einen Titel haben, der die Disziplin angibt, die sie ansprechen (z. B. "Für Software-Engineering").

Document- Ein Dokument ist eine Sammlung von Daten, unabhängig davon, auf welchem ​​Medium sie aufgezeichnet sind. Es hat im Allgemeinen Beständigkeit und kann von Menschen oder Maschinen gelesen werden. Dokumente umfassen sowohl Papierdokumente als auch elektronische Dokumente.

Enterprise - Unter Unternehmen werden sehr große Unternehmen verstanden, die aus vielen Organisationen an vielen verschiedenen Standorten mit unterschiedlichen Kunden bestehen.

Entry criteria - Seinszustände, die vorhanden sein müssen, bevor eine Anstrengung erfolgreich beginnen kann.

Equivalent staging - Äquivalentes Staging ist ein Ziel-Staging, das unter Verwendung der definierten kontinuierlichen Darstellung erstellt wird, damit die Ergebnisse der Verwendung des Ziel-Staging mit den Reifegraden der inszenierten Darstellung verglichen werden können.

Exit criteria - Seinszustände, die vorhanden sein müssen, bevor eine Anstrengung erfolgreich enden kann.

Expected CMMI components- CMMI-Komponenten, die erklären, was getan werden kann, um eine erforderliche CMMI-Komponente zu erfüllen. Modellbenutzer können die erwarteten Komponenten explizit implementieren oder äquivalente alternative Vorgehensweisen zu diesen Komponenten implementieren. Spezifische und generische Praktiken sind erwartete Modellkomponenten

Finding - Siehe Bewertungsergebnisse.

Formal evaluation process - Im Bereich Entscheidungsanalyse und Lösungsprozess finden Sie die Definition eines "formalen Bewertungsprozesses" in den einleitenden Anmerkungen.

Functional analysis- Prüfung einer definierten Funktion, um alle zur Erfüllung dieser Funktion erforderlichen Unterfunktionen zu identifizieren; Identifizierung funktionaler Beziehungen und Schnittstellen (intern und extern) und Erfassung dieser in einer funktionalen Architektur; und Ablauf der Leistungsanforderungen der oberen Ebene und Zuordnung dieser Anforderungen zu Unterfunktionen der unteren Ebene.

Functional architecture - Die hierarchische Anordnung von Funktionen, ihre internen und externen (außerhalb der Aggregation selbst) Funktionsschnittstellen und externen physischen Schnittstellen, ihre jeweiligen Funktions- und Leistungsanforderungen und ihre Entwurfsbeschränkungen.

Generic goal- GENERISCHE ZIELE werden als "generisch" bezeichnet, da dieselbe Zielaussage in mehreren Prozessbereichen angezeigt wird. In der abgestuften Darstellung hat jeder Prozessbereich nur ein generisches Ziel. Das Erreichen eines generischen Ziels in einem Prozessbereich bedeutet eine verbesserte Kontrolle bei der Planung und Implementierung der mit diesem Prozessbereich verbundenen Prozesse, wodurch angezeigt wird, ob diese Prozesse wahrscheinlich effektiv, wiederholbar und dauerhaft sind. Generische Ziele sind erforderliche Modellkomponenten und werden in Beurteilungen verwendet, um festzustellen, ob ein Prozessbereich erfüllt ist.

Generic practice- GENERIC PRACTICES bieten eine Institutionalisierung, um sicherzustellen, dass die mit dem Prozessbereich verbundenen Prozesse effektiv, wiederholbar und dauerhaft sind. Generische Praktiken werden nach generischen Zielen und gemeinsamen Merkmalen kategorisiert und sind erwartete Komponenten in CMMI-Modellen. (In den Prozessbereichen werden nur der Titel, die Aussage und die Ausarbeitungen der allgemeinen Praxis angezeigt.)

Generic practice elaboration- Nach den spezifischen Praktiken werden die allgemeinen Praxistitel und -anweisungen angezeigt, die für den Prozessbereich gelten. Nach jeder allgemeinen Übungserklärung kann eine Ausarbeitung im Klartext mit der Überschrift "Ausarbeitung" erscheinen. Die GENERIC PRACTICE ELABORATION enthält Informationen darüber, wie die generische Praxis für den Prozessbereich interpretiert werden sollte. Wenn keine Ausarbeitung vorhanden ist, ist die Anwendung der allgemeinen Praxis ohne Ausarbeitung offensichtlich.

Goal- Ein "ZIEL" ist eine erforderliche CMMI-Komponente, die entweder ein generisches Ziel oder ein bestimmtes Ziel sein kann. Wenn Sie das Wort "Ziel" in einem CMMI-Modell sehen, bezieht es sich immer auf Modellkomponenten (z. B. generisches Ziel, spezifisches Ziel).

Incomplete process- Ein Prozess, der nicht oder nur teilweise ausgeführt wird (auch als Fähigkeitsstufe 0 bezeichnet). Eines oder mehrere der spezifischen Ziele des Prozessbereichs werden nicht erfüllt.

Independent group - Lesen Sie im Prozessbereich Prozess- und Produktqualitätssicherung die Diskussion einer "Gruppe, die unabhängig ist" in den einleitenden Anmerkungen.

Informative CMMI components- CMMI-Komponenten, die Modellbenutzern helfen, die erforderlichen und erwarteten Komponenten eines Modells zu verstehen. Diese Komponenten können Beispiele, detaillierte Erklärungen oder andere hilfreiche Informationen enthalten. Unterübungen, Notizen, Referenzen, Zieltitel, Übungstitel, Quellen, typische Arbeitsprodukte, Disziplinverstärkungen und allgemeine Übungsausarbeitungen sind informative Modellkomponenten.

Institutionalization - Die tief verwurzelte Art der Geschäftstätigkeit, der eine Organisation im Rahmen ihrer Unternehmenskultur routinemäßig folgt.

Integrated Product and Process Development - Ein systematischer Ansatz für die Produktentwicklung, der eine zeitnahe Zusammenarbeit relevanter Stakeholder während des gesamten Produktlebenszyklus ermöglicht, um die Kundenbedürfnisse besser zu befriedigen.

Integrated team- Eine Gruppe von Personen mit komplementären Fähigkeiten und Fachkenntnissen, die sich dazu verpflichten, bestimmte Arbeitsprodukte in zeitnaher Zusammenarbeit zu liefern. Integrierte Teammitglieder bieten Fähigkeiten und Interessenvertretung, die für alle Phasen der Arbeitsprodukte geeignet sind, und sind gemeinsam für die Lieferung der Arbeitsprodukte wie angegeben verantwortlich. Ein integriertes Team sollte befugte Vertreter von Organisationen, Disziplinen und Funktionen umfassen, die am Erfolg der Arbeitsprodukte beteiligt sind.

Interface control- Im Konfigurationsmanagement der Prozess des (1) Identifizierens aller funktionalen und physischen Merkmale, die für die Schnittstelle von zwei oder mehr Konfigurationselementen relevant sind, die von einer oder mehreren Organisationen bereitgestellt werden, und (2) Sicherstellen, dass die vorgeschlagenen Änderungen dieser Merkmale bewertet und genehmigt werden vor der Implementierung. [IEEE 828-1983].

Lead appraiser - Wie in der CMMI Product Suite verwendet, eine Person, die von einer autorisierenden Stelle die Anerkennung erhalten hat, als Bewertungsteamleiter für eine bestimmte Bewertungsmethode aufzutreten.

Life-cycle model - Eine Aufteilung der Lebensdauer eines Produkts in Phasen, die das Projekt von der Ermittlung der Kundenbedürfnisse bis zur Stilllegung des Produkts leiten.

Manager- Ein Projektmanager ist die Person, die für die Planung, Leitung, Steuerung, Strukturierung und Motivation des Projekts verantwortlich ist. Er oder sie kann denjenigen, die Projektaufgaben oder -aktivitäten in seinem Verantwortungsbereich ausführen, sowohl technische als auch administrative Anweisungen und Kontrolle geben. Der Projektmanager ist letztendlich gegenüber dem Kunden verantwortlich.

Maturity level - Grad der Prozessverbesserung in einem vordefinierten Satz von Prozessbereichen, in denen alle Ziele innerhalb des Satzes erreicht werden.

Memorandum of agreement - Verbindliche Dokumente oder Vereinbarungen zwischen zwei oder mehr Parteien.

Natural bounds- Der inhärente Prozess, der sich in Maßstäben der Prozessleistung widerspiegelt und manchmal als "Stimme des Prozesses" bezeichnet wird. Techniken wie Kontrolldiagramme, Konfidenzintervalle und Vorhersageintervalle werden verwendet, um zu bestimmen, ob die Variation auf häufige Ursachen zurückzuführen ist (dh der Prozess ist vorhersehbar oder "stabil") oder auf eine spezielle Ursache zurückzuführen ist, die identifiziert werden kann und sollte und sollte entfernt.

Non-developmental item- Ein Liefergegenstand, der vor seiner aktuellen Verwendung in einem Akquisitions- oder Entwicklungsprozess entwickelt wurde. Ein solcher Gegenstand kann geringfügige Änderungen erfordern, um die Anforderungen seiner derzeit beabsichtigten Verwendung zu erfüllen.

Nontechnical requirements- Vertragliche Bestimmungen, Verpflichtungen, Bedingungen und Bedingungen, die sich auf den Erwerb von Produkten oder Dienstleistungen auswirken. Beispiele hierfür sind zu liefernde Produkte, Datenrechte für ausgelieferte kommerzielle nicht handelsübliche (COTS) Nichtentwicklungsartikel (NDIs), Liefertermine und Meilensteine ​​mit Ausstiegskriterien. Andere nicht technische Anforderungen umfassen Schulungsanforderungen, Standortanforderungen und Bereitstellungspläne.

Objective- Der Begriff Ziel wird in CMMI im alltäglichen Sinne verwendet. Dies ist unser Ziel oder Ziel, das erreicht werden soll.

Objective evidence - In CMMI-Bewertungsmaterialien werden qualitative oder quantitative Informationen, Aufzeichnungen oder Tatsachenerklärungen verwendet, die sich auf die Merkmale eines Gegenstands oder einer Dienstleistung oder auf das Vorhandensein und die Implementierung eines Prozesselements beziehen und auf Beobachtung, Messung oder Prüfung beruhen die überprüfbar sind.

Objectively evaluate- Überprüfung von Aktivitäten und Arbeitsprodukten anhand von Kriterien, die die Subjektivität und Voreingenommenheit des Überprüfers minimieren. Ein Beispiel für eine objektive Bewertung ist ein Audit anhand von Anforderungen, Standards oder Verfahren durch eine unabhängige Qualitätssicherungsfunktion.

Observation- Wie in CMMI-Bewertungsmaterialien verwendet, eine schriftliche Aufzeichnung, die das Verständnis der Mitglieder des Bewertungsteams für Informationen darstellt, die während der Aktivitäten zur Erfassung von Bewertungsdaten gesehen oder gehört wurden. Die schriftliche Aufzeichnung kann die Form einer Erklärung oder eine andere Form annehmen, solange der Informationsgehalt erhalten bleibt.

Operational concept - Eine allgemeine Beschreibung der Art und Weise, wie ein Unternehmen verwendet wird oder arbeitet.

Operational scenario- Eine Beschreibung einer imaginären Abfolge von Ereignissen, die die Interaktion des Produkts mit seiner Umgebung und seinen Benutzern sowie die Interaktion zwischen seinen Produktkomponenten umfasst. Betriebsszenarien werden verwendet, um die Anforderungen und das Design des Systems zu bewerten und das System zu verifizieren und zu validieren.

Optimizing process- Ein quantitativ verwalteter Prozess, der auf der Grundlage eines Verständnisses der mit dem Prozess verbundenen häufigen Ursachen für Abweichungen verbessert wird. Ein Prozess, der sich darauf konzentriert, den Bereich der Prozessleistung durch inkrementelle und innovative Verbesserungen kontinuierlich zu verbessern.

Organization - Eine Organisation ist eine Struktur, in der Personen gemeinsam ein oder mehrere Projekte als Ganzes verwalten und deren Projekte sich einen Senior Manager teilen und nach denselben Richtlinien arbeiten.

Organization's business objectives - Strategien, die von der Geschäftsleitung entwickelt wurden, um den Fortbestand eines Unternehmens sicherzustellen und seine Rentabilität, seinen Marktanteil und andere Faktoren zu verbessern, die den Erfolg des Unternehmens beeinflussen.

Organizational maturity- Inwieweit hat eine Organisation Prozesse explizit und konsistent implementiert, die dokumentiert, verwaltet, gemessen, gesteuert und kontinuierlich verbessert werden? Die organisatorische Reife kann über Beurteilungen gemessen werden.

Organizational policy - Ein Leitprinzip, das normalerweise von der Geschäftsleitung festgelegt wird und von einer Organisation übernommen wird, um Entscheidungen zu beeinflussen und zu bestimmen.

Organizational unit- Der Teil einer Organisation, der Gegenstand einer Bewertung ist (auch als organisatorischer Umfang der Bewertung bezeichnet). Eine Organisationseinheit setzt einen oder mehrere Prozesse ein, die einen kohärenten Prozesskontext haben und innerhalb eines kohärenten Satzes von Geschäftszielen arbeiten. Eine Organisationseinheit ist normalerweise Teil einer größeren Organisation, obwohl in einer kleinen Organisation die Organisationseinheit die gesamte Organisation sein kann.

Outsourcing - Der Prozess, vertraglich diskrete oder vorgeschlagene Maßnahmen der Akquisitionseinheit zu erhalten, die sich verpflichten würden, in die Beschaffung von Produkten und Dienstleistungen zu investieren.

Peer review - Eine Überprüfung durch den Peer, um Mängel in einem Ergebnis festzustellen.

Performance parameters - Die Wirksamkeitsmaße und andere Schlüsselmaßnahmen zur Steuerung und Kontrolle der fortschreitenden Entwicklung.

Performed process- Ein Prozess, der die erforderliche Arbeit zur Erstellung identifizierter Output-Arbeitsprodukte unter Verwendung identifizierter Input-Arbeitsprodukte (auch als Fähigkeitsstufe 1 bezeichnet) ausführt. Die spezifischen Ziele des Prozessbereichs werden erfüllt.

Planned process- Ein Prozess, der sowohl durch eine Beschreibung als auch durch einen Plan dokumentiert wird. Die Beschreibung und der Plan sollten koordiniert werden, und der Plan sollte Standards, Anforderungen, Ziele, Ressourcen, Aufgaben usw. enthalten.

Process - Eine Reihe von Aktivitäten, Methoden, Praktiken und Transformationen, mit denen Menschen Systeme und zugehörige Produkte entwickeln und warten.

Process action plan - Im Prozessbereich Organisationsprozessfokus finden Sie die Definition des "Prozessaktionsplans" in den einleitenden Anmerkungen.

Process action team - Ein Team, das die Verantwortung hat, Aktivitäten zur Prozessverbesserung für eine Organisation zu entwickeln und umzusetzen, wie im Aktionsplan zur Prozessverbesserung dokumentiert.

Process and technology improvements - Im Prozessbereich Organisatorische Innovation und Bereitstellung finden Sie die Diskussion zu "Prozess- und Technologieverbesserungen" in den einleitenden Anmerkungen.

Process area- Ein Prozessbereich ist eine Gruppe verwandter Praktiken in einem Bereich, die bei gemeinsamer Durchführung eine Reihe von Zielen erfüllen, die für eine signifikante Verbesserung in diesem Bereich als wichtig erachtet werden. Alle CMMI-Prozessbereiche sind sowohl kontinuierlichen als auch abgestuften Darstellungen gemeinsam. In der abgestuften Darstellung sind die Prozessbereiche nach Reifegraden organisiert.

Process asset - Alles, was die Organisation für nützlich hält, um die Ziele eines Prozessbereichs zu erreichen.

Process asset library - Eine Sammlung von Prozessbeständen, die von einer Organisation oder einem Projekt verwendet werden können.

Process attribute - Ein messbares Merkmal der Prozessfähigkeit, das auf jeden Prozess anwendbar ist.

Process capability - Der Bereich der erwarteten Ergebnisse, die durch Befolgen eines Prozesses erzielt werden können.

Process context- Die in der Bewertungseingabe dokumentierten Faktoren, die die Beurteilung und Vergleichbarkeit der Bewertungsbewertungen beeinflussen. Dazu gehört, ohne darauf beschränkt zu sein, die Größe der zu bewertenden Organisationseinheit; die Demografie der Organisationseinheit; die Anwendungsdisziplin der Produkte oder Dienstleistungen; die Größe, Kritikalität und Komplexität der Produkte oder Dienstleistungen; und die Qualitätsmerkmale der Produkte oder Dienstleistungen.

Process definition- Das Definieren und Beschreiben eines Prozesses. Das Ergebnis der Prozessdefinition ist eine Prozessbeschreibung.

Process description- Ein dokumentierter Ausdruck einer Reihe von Aktivitäten, die zur Erreichung eines bestimmten Zwecks ausgeführt werden und eine operative Definition der Hauptkomponenten eines Prozesses enthalten. In der Dokumentation werden die Anforderungen, das Design, das Verhalten oder andere Merkmale eines Prozesses vollständig, präzise und überprüfbar angegeben. Es kann auch Verfahren zur Feststellung enthalten, ob diese Bestimmungen erfüllt wurden. Prozessbeschreibungen finden Sie auf Aktivitäts-, Projekt- oder Organisationsebene.

Process element- Die grundlegende Einheit eines Prozesses. Ein Prozess kann in Form von Unterprozessen oder Prozesselementen definiert werden. Ein Unterprozess kann weiter zerlegt werden; Ein Prozesselement kann nicht. Jedes Prozesselement deckt einen eng verwandten Satz von Aktivitäten ab (z. B. Schätzelement, Peer-Review-Element). Prozesselemente können mithilfe von Vorlagen dargestellt werden, die vervollständigt, Abstraktionen verfeinert oder Beschreibungen geändert oder verwendet werden müssen. Ein Prozesselement kann eine Aktivität oder Aufgabe sein.

Process group - Eine Sammlung von Spezialisten, die die Definition, Wartung und Verbesserung der von der Organisation verwendeten Prozesse erleichtern.

Process improvement - Ein Programm von Aktivitäten zur Verbesserung der Leistung und Reife der Prozesse der Organisation sowie der Ergebnisse eines solchen Programms.

Process-improvement objectives - Eine Reihe von Zielmerkmalen, die festgelegt wurden, um die Bemühungen zur Verbesserung eines bestehenden Prozesses auf eine bestimmte messbare Weise zu steuern, entweder in Bezug auf die resultierenden Produkteigenschaften (z. B. Qualität, Leistung, Einhaltung von Standards usw.) oder in Bezug auf die Art und Weise, in der der Prozess durchgeführt wird ausgeführt wird (z. B. Eliminierung redundanter Prozessschritte, Kombinieren von Prozessschritten, Verbessern der Zykluszeit usw.)

Process-improvement plan - Im Prozessbereich Organisationsprozessfokus finden Sie die Definition des "Prozessverbesserungsplans" in den einleitenden Anmerkungen.

Process measurement - Die Definitionen, Methoden und Aktivitäten, mit denen ein Prozess und die daraus resultierenden Produkte gemessen werden, um den Prozess zu charakterisieren und zu verstehen.

Process owner- Die Person (oder das Team), die / das für die Definition und Aufrechterhaltung eines Prozesses verantwortlich ist. Auf organisatorischer Ebene ist der Prozessverantwortliche die Person (oder das Team), die / das für die Beschreibung eines Standardprozesses verantwortlich ist. Auf Projektebene ist der Prozessverantwortliche die Person (oder das Team), die / das für die Beschreibung des definierten Prozesses verantwortlich ist. Ein Prozess kann daher mehrere Eigentümer auf verschiedenen Verantwortungsebenen haben.

Process performance- Ein Maß für die tatsächlichen Ergebnisse, die durch Befolgen eines Prozesses erzielt werden. Es ist sowohl durch Prozessmaßnahmen (z. B. Aufwand, Zykluszeit und Effizienz bei der Fehlerbeseitigung) als auch durch Produktmaßnahmen (z. B. Zuverlässigkeit, Fehlerdichte und Reaktionszeit) gekennzeichnet.

Process performance baseline - Eine dokumentierte Charakterisierung der tatsächlichen Ergebnisse, die durch Befolgen eines Prozesses erzielt werden, der als Benchmark für den Vergleich der tatsächlichen Prozessleistung mit der erwarteten Prozessleistung verwendet wird.

Process performance model - Eine Beschreibung der Beziehungen zwischen den Attributen eines Prozesses und seinen Arbeitsprodukten, die aus historischen Prozessleistungsdaten entwickelt und anhand der gesammelten Prozess- und Produktmaße aus dem Projekt kalibriert werden und zur Vorhersage der Ergebnisse verwendet werden, die durch Verfolgung eines Prozesses erzielt werden sollen.

Process tailoring- Erstellen, Ändern oder Anpassen einer Prozessbeschreibung für ein bestimmtes Ziel. Beispielsweise passt ein Projekt seinen definierten Prozess aus den Standardprozessen der Organisation an, um die Ziele, Einschränkungen und die Umgebung des Projekts zu erfüllen.

Product- Ein Produkt kann als eine konkrete Ausgabe oder Dienstleistung angesehen werden, die das Ergebnis eines Prozesses ist und zur Lieferung an einen Kunden oder Endbenutzer bestimmt ist. Ein Produkt kann auch ein beliebiges Arbeitsprodukt sein, das vertraglich an den Kunden geliefert wird.

Product component- Produktkomponenten sind im Allgemeinen untergeordnete Komponenten des Produkts und werden integriert, um das Produkt zu "bauen". Produktkomponenten können Teil des an den Kunden gelieferten Produkts sein oder zur Herstellung oder Verwendung des Produkts dienen. Für Unternehmen, die Mobiltelefonbatterien herstellen, ist die Mobiltelefonbatterie beispielsweise ein Produkt. Für Unternehmen, die Mobiltelefone bauen und liefern, ist der Akku eine Produktkomponente.

Product baseline - Beim Konfigurationsmanagement das ursprünglich genehmigte technische Datenpaket (einschließlich der Quellcodeliste für Software), das ein Konfigurationselement während der Produktion, des Betriebs, der Wartung und der logistischen Unterstützung seines Lebenszyklus definiert.

Product-component requirements - Die Anforderungen an Produktkomponenten enthalten eine vollständige Spezifikation einer Produktkomponente, einschließlich Passform, Form, Funktion, Leistung und anderer Anforderungen.

Product life cycle- Ein Arbeitsprodukt ist ein Artefakt, das durch einen Lebenszyklusprozess erzeugt wird, und kann auch als Lebenszyklus-Arbeitsprodukt bezeichnet werden. Lebenszyklus-Arbeitsprodukte können Anforderungsspezifikationen, Schnittstellenspezifikationen, Architekturspezifikationen, Projektpläne, Konstruktionsdokumente, Komponententestpläne, Integrations- und Systemtestpläne sowie einen Prozess wie einen Montageprozess für Herstellungsprodukte umfassen.

Project- Ein Projekt ist ein verwalteter Satz miteinander verbundener Ressourcen, die einem Kunden oder Endbenutzer ein oder mehrere Produkte liefern. Die Ressourcen haben einen bestimmten Anfang und ein bestimmtes Ende und arbeiten nach einem Plan.

Product line - Eine Gruppe von Produkten, die einen gemeinsamen, verwalteten Satz von Funktionen gemeinsam haben, die die spezifischen Anforderungen eines ausgewählten Marktes oder einer ausgewählten Mission erfüllen.

Product-related life-cycle processes - Prozesse, die mit einem Produkt während einer oder mehrerer Phasen seines Lebens verbunden sind (dh von der Konzeption bis zur Entsorgung), wie z. B. die Herstellungs- und Unterstützungsprozesse.

Product requirements - Eine Verfeinerung der Kundenanforderungen in die Sprache der Entwickler, wobei implizite Anforderungen in explizit abgeleitete Anforderungen umgewandelt werden.

Program- (1) Ein Projekt. (2) Eine Sammlung verwandter Projekte und der Infrastruktur, die sie unterstützt, einschließlich Zielen, Methoden, Aktivitäten, Plänen und Erfolgsmaßnahmen.

Project manager- Ein Projektmanager ist die Person, die für die Planung, Leitung, Steuerung, Strukturierung und Motivation des Projekts verantwortlich ist. Er oder sie kann denjenigen, die Projektaufgaben oder -aktivitäten in seinem Verantwortungsbereich ausführen, sowohl technische als auch administrative Anweisungen und Kontrolle geben. Der Projektmanager ist letztendlich gegenüber dem Kunden verantwortlich. Der Projektmanager übernimmt unterschiedliche Rollen und Verantwortlichkeiten, wenn sich Größe, Vielfalt und Komplexität des Projekts ändern.

Project progress and performance - Was ein Projekt in Bezug auf die Umsetzung von Projektplänen erreicht, einschließlich Aufwand, Kosten, Zeitplan und technischer Leistung.

Project's defined process - Im Prozessbereich Integriertes Projektmanagement finden Sie die Definition des "Projektdefinierten Prozesses" in den einleitenden Hinweisen und in der spezifischen Praxis "Projektdefinierten Prozess festlegen".

Prototype - Ein vorläufiger Typ, eine vorläufige Form oder eine vorläufige Instanz eines Produkts oder einer Produktkomponente, die als Modell für spätere Phasen oder für die endgültige, vollständige Version des Produkts dient.

Quality - Die Fähigkeit einer Reihe von inhärenten Merkmalen eines Produkts, einer Produktkomponente oder eines Prozesses, die Anforderungen der Kunden zu erfüllen.

Quality assurance - Ein geplantes und systematisches Mittel, um dem Management sicherzustellen, dass definierte Standards, Praktiken, Verfahren und Methoden des Prozesses angewendet werden.

Quality control - Die betrieblichen Techniken und Aktivitäten, mit denen die Qualitätsanforderungen erfüllt werden.

Quantitative objective - Gewünschter Zielwert ausgedrückt als quantitative Messgröße.

Quantitatively managed process- Ein definierter Prozess, der mit statistischen und anderen quantitativen Techniken gesteuert wird. Die Attribute Produktqualität, Servicequalität und Prozessleistung sind während des gesamten Projekts messbar und kontrollierbar.

Reference mode - Ein Modell, das als Benchmark für die Messung bestimmter Attribute verwendet wird.

Relevant stakeholder - Ein relevanter Stakeholder wird verwendet, um einen Stakeholder zu bestimmen, der für die Beteiligung an bestimmten Aktivitäten identifiziert und in einem geeigneten Plan wie dem Projektplan enthalten ist.

Required CMMI components- CMMI-Komponenten, die für die Prozessverbesserung in einem bestimmten Prozessbereich unerlässlich sind. Diese Komponenten werden in Beurteilungen verwendet, um die Prozessfähigkeit zu bestimmen. Spezifische Ziele und generische Ziele sind erforderliche Modellkomponenten.

Requirement- (1) Eine Bedingung oder Fähigkeit, die ein Benutzer benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen. (2) Eine Bedingung oder Fähigkeit, die ein Produkt oder eine Produktkomponente erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere formal auferlegte Dokumente zu erfüllen. (3) Eine dokumentierte Darstellung eines Zustands oder einer Fähigkeit wie in (1) oder (2).

Requirements analysis- Ermittlung produktspezifischer Leistungs- und Funktionsmerkmale auf der Grundlage von Analysen der Kundenbedürfnisse, -erwartungen und -beschränkungen; Betriebskonzept; projizierte Nutzungsumgebungen für Personen, Produkte und Prozesse; und Maßnahmen der Wirksamkeit.

Requirements elicitation - Verwendung systematischer Techniken wie Prototypen und strukturierter Umfragen, um Kunden- und Endbenutzerbedürfnisse proaktiv zu identifizieren und zu dokumentieren.

Requirements management - Verwaltung aller Anforderungen, die vom Projekt erhalten oder generiert wurden, einschließlich technischer und nichttechnischer Anforderungen sowie der Anforderungen, die die Organisation an das Projekt stellt.

Requirements traceability - Der Nachweis eines Zusammenhangs zwischen einer Anforderung und ihrer Quellanforderung, ihrer Umsetzung und ihrer Überprüfung.

Return on investment - Das Verhältnis der Einnahmen aus der Produktion (Produkt) zu den Produktionskosten, das bestimmt, ob eine Organisation von der Durchführung einer Aktion zur Produktion von etwas profitiert.

Risk analysis - Bewertung, Klassifizierung und Priorisierung von Risiken.

Risk identification - Ein organisierter, gründlicher Ansatz zur Suche nach wahrscheinlichen oder realistischen Risiken bei der Erreichung der Ziele.

Risk management - Ein organisierter Analyseprozess, um zu identifizieren, was Schaden oder Verlust verursachen könnte (Risiken identifizieren), die identifizierten Risiken zu bewerten und zu quantifizieren sowie einen geeigneten Ansatz zu entwickeln und erforderlichenfalls umzusetzen, um Risikoursachen zu verhindern oder zu behandeln, die zu erheblichen Schäden führen könnten oder Verlust.

Risk management strategy- Ein organisierter technischer Ansatz, um zu identifizieren, was Schaden oder Verlust verursachen könnte (Risiken identifizieren), die identifizierten Risiken zu bewerten und zu quantifizieren und einen geeigneten Ansatz zu entwickeln und erforderlichenfalls umzusetzen, um Risikoursachen zu verhindern oder zu behandeln, die zu erheblichen Schäden oder Verlusten führen könnten . In der Regel wird das Risikomanagement für Projekt-, Organisations- oder Produktentwicklungs-Organisationseinheiten durchgeführt.

Root cause - Eine Grundursache ist eine Fehlerquelle, sodass der Fehler verringert oder beseitigt wird, wenn er behoben wird.

Senior manager- Der Begriff Senior Manager, wie er in CMMI verwendet wird, bezieht sich auf eine Managementrolle, die in einer Organisation so hoch ist, dass der Hauptfokus der Person eher auf der langfristigen Gesundheit und dem Erfolg der Organisation als auf dem kurzfristigen Projekt liegt vertragliche Bedenken und Druck. Ein Senior Manager kann für die Überwachung eines Programms verantwortlich sein, das viele Projekte enthält, die von Projektmanagern verwaltet werden.

Software engineering- (1) Anwendung eines systematischen, disziplinierten und quantifizierbaren Ansatzes für die Entwicklung, den Betrieb und die Wartung von Software. (2) Die Untersuchung von Ansätzen wie in (1).

Solicitation - Der Prozess der Erstellung eines Werbepakets und der Auswahl eines Lieferanten (Auftragnehmers).

Solicitation package- Ein formelles Dokument mit technischen und nichttechnischen Anforderungen, das verwendet wird, um Angebote für Ausschreibungen (Gebote) und Angebotsanfragen (Vorschläge) anzufordern oder um Leistungsnachweise und Preisangebote (Angebote) anzufordern. Andernfalls wird es als Grundlage für die Auswahl einer oder mehrerer Bezugsquellen für die Bereitstellung von Produkten oder Dienstleistungen verwendet.

Special cause of process variation - Eine Ursache für einen Defekt, der für einen vorübergehenden Umstand spezifisch ist und nicht Teil eines Prozesses ist.

Specific goal- SPEZIFISCHE ZIELE gelten für einen Prozessbereich und befassen sich mit den einzigartigen Merkmalen, die beschreiben, was implementiert werden muss, um den Prozessbereich zu erfüllen. Bestimmte Ziele sind erforderliche Modellkomponenten und werden in Beurteilungen verwendet, um festzustellen, ob ein Prozessbereich erfüllt ist.

Specific practice- Eine SPEZIFISCHE PRAXIS ist eine Aktivität, die als wichtig für die Erreichung des damit verbundenen spezifischen Ziels angesehen wird. Die spezifischen Praktiken beschreiben die Aktivitäten, die zur Erreichung der spezifischen Ziele eines Prozessbereichs führen sollen. Spezifische Praktiken sind erwartete Modellkomponenten.

Stable process - Der Zustand, in dem alle besonderen Ursachen für Prozessschwankungen beseitigt und daran gehindert wurden, sich zu wiederholen, so dass nur die gemeinsamen Ursachen für Prozessschwankungen des Prozesses übrig bleiben.

Staged representation- Eine Modellstruktur, in der das Erreichen der Ziele einer Reihe von Prozessbereichen einen Reifegrad festlegt; Jede Ebene bildet eine Grundlage für nachfolgende Ebenen.

Stakeholder - Ein Stakeholder ist eine Gruppe oder Einzelperson, die vom Ergebnis eines Projekts betroffen ist oder die Aktivitäten oder Ergebnisse des Projekts beeinflussen kann.

Standard process- Eine operative Definition des grundlegenden Prozesses, der die Einrichtung eines gemeinsamen Prozesses in einer Organisation steuert. Ein Standardprozess beschreibt die grundlegenden Prozesselemente, von denen erwartet wird, dass sie in einen definierten Prozess integriert werden. Außerdem werden die Beziehungen (z. B. Reihenfolge und Schnittstellen) zwischen diesen Prozesselementen beschrieben.

Statement of work - Eine Beschreibung der Auftragsarbeiten, die zur Fertigstellung eines Projekts erforderlich sind.

Statistical predictability - Die Leistung eines quantitativen Prozesses, der mit statistischen und anderen quantitativen Techniken gesteuert wird.

Statistical process control - Statistisch basierte Analyse eines Prozesses und Messung der Prozessleistung, um häufige und spezielle Ursachen für Schwankungen der Prozessleistung zu identifizieren und die Prozessleistung in Grenzen zu halten.

Statistical techniques - Eine Analysetechnik, die statistische Methoden verwendet (z. B. statistische Prozesskontrolle, Konfidenzintervalle, Vorhersageintervalle).

Statistically managed process - Ein Prozess, der mit einer statistisch basierten Technik verwaltet wird, bei der Prozesse analysiert, spezielle Ursachen für Prozessschwankungen identifiziert und die Leistung in genau definierten Grenzen gehalten werden.

Strength - Wie in CMMI-Bewertungsmaterialien verwendet, eine beispielhafte oder bemerkenswerte Implementierung einer CMMI-Modellpraxis.

Sub-process - Ein Prozess, der Teil eines größeren Prozesses ist.

Supplier- (1) Ein Unternehmen, das Produkte liefert oder Dienstleistungen erbringt, die erworben werden. (2) Eine Einzelperson, eine Personengesellschaft, ein Unternehmen, ein Unternehmen, eine Vereinigung oder eine andere Dienstleistung, die eine Vereinbarung (Vertrag) mit einem Erwerb für das Design, die Entwicklung, Herstellung, Wartung, Änderung oder Lieferung von Gegenständen gemäß den Bedingungen einer Vereinbarung (Vertrag) hat ).

Sustainment- Die Prozesse, mit denen sichergestellt wird, dass ein Produkt von seinen Endbenutzern oder Kunden betrieblich genutzt werden kann. Durch Nachhaltigkeit wird sichergestellt, dass die Wartung so durchgeführt wird, dass das Produkt in einem betriebsbereiten Zustand ist, unabhängig davon, ob das Produkt von Kunden oder Endbenutzern verwendet wird oder nicht.

Systems engineering- Der interdisziplinäre Ansatz, der den gesamten technischen und verwaltungstechnischen Aufwand regelt, der erforderlich ist, um eine Reihe von Kundenbedürfnissen, -erwartungen und -beschränkungen in eine Produktlösung umzuwandeln und diese Lösung während der gesamten Produktlebensdauer zu unterstützen. Dies umfasst die Definition technischer Leistungskennzahlen, die Integration technischer Fachgebiete in die Etablierung einer Produktarchitektur und die Definition unterstützender Lebenszyklusprozesse, bei denen Kosten-, Leistungs- und Zeitplanziele in Einklang gebracht werden.

Tailoring guidelines- Durch das Anpassen eines Prozesses werden Prozessbeschreibungen, die normalerweise auf Organisationsebene beschrieben werden, für die Verwendung in einem bestimmten Projekt erstellt, geändert oder angepasst. Für die meisten Organisationen kann oder wird eine organisatorische Prozessdefinition nicht für alle Projekte zu 100% befolgt. Normalerweise ist eine gewisse Anpassung erforderlich. Anpassungsrichtlinien beschreiben dann, was geändert werden kann und was nicht, und identifizieren Prozesskomponenten, die zulässige Kandidaten für Änderungen sind.

Target profile - In der fortlaufenden Darstellung eine Liste der Prozessbereiche und ihrer entsprechenden Fähigkeitsstufen, die ein Ziel für die Prozessverbesserung darstellen.

Target staging - In der fortlaufenden Darstellung eine Folge von Zielprofilen, die den Weg der Prozessverbesserung beschreibt, den die Organisation einschlagen muss.

Technical data package - Eine Sammlung von Artikeln, die Folgendes enthalten können, wenn diese Informationen für den Produkttyp und die Produktkomponente geeignet sind.

Technical requirements - Eigenschaften (Attribute) von Produkten oder Dienstleistungen, die erworben oder entwickelt werden sollen.

Test procedure - Detaillierte Anweisungen zum Einrichten, Ausführen und Auswerten der Ergebnisse für einen bestimmten Test.

Trade study - Bewertung von Alternativen anhand von Kriterien und systematischer Analyse, um die beste Alternative zur Erreichung festgelegter Ziele auszuwählen.

Training- Siehe im Prozessbereich Organisationsschulung die Definition von .training. in den einleitenden Anmerkungen.

Unit testing - Testen einzelner Hardware- oder Softwareeinheiten oder Gruppen verwandter Einheiten.

Validation- Die Validierung zeigt, dass das Produkt, wie bereitgestellt (oder wie bereitgestellt), seinen Verwendungszweck in der Betriebsumgebung erfüllt. Die Validierung stellt sicher, dass "Sie das Richtige gebaut haben".

Verification- Die Überprüfung umfasst die Überprüfung des Produkts und der Zwischenprodukte anhand aller ausgewählten Anforderungen, einschließlich der Anforderungen an Kunden, Produkte und Produktkomponenten. Die Überprüfung ist von Natur aus ein inkrementeller Prozess. Es beginnt mit der Überprüfung der Anforderungen, geht über die Überprüfung der sich entwickelnden Arbeitsprodukte hinaus und endet mit der Überprüfung des fertigen Produkts. Bei der Überprüfung wird geprüft, ob das Arbeitsprodukt die angegebenen Anforderungen ordnungsgemäß widerspiegelt. Die Überprüfung stellt sicher, dass "Sie es richtig gebaut haben".

Verifying implementation - Ein gemeinsames Merkmal von CMMI-Modellprozessbereichen mit einer abgestuften Darstellung, in der die allgemeinen Praktiken im Zusammenhang mit der Überprüfung durch das übergeordnete Management und der objektiven Bewertung der Konformität mit Prozessbeschreibungen, -verfahren und -standards zusammengefasst sind.

Version control - Einrichtung und Pflege von Basislinien und Identifizierung von Änderungen an Basislinien, die es ermöglichen, zur vorherigen Basislinie zurückzukehren.

Weakness - Wie in CMMI-Bewertungsmaterialien verwendet, die ineffektive oder fehlende Implementierung einer oder mehrerer CMMI-Modellpraktiken.

Work breakdown structure - Eine Anordnung der Arbeitselemente und ihrer Beziehung zueinander und zum Endprodukt.

Work product- Der Begriff ARBEITSPRODUKT wird in der gesamten CMMI-Produktsuite verwendet, um alle durch einen Prozess erzeugten Artefakte zu bezeichnen. Diese Artefakte können Dateien, Dokumente, Teile des Produkts, Dienstleistungen, Prozesse, Spezifikationen und Rechnungen umfassen. Beispiele für Prozesse, die als Arbeitsprodukte betrachtet werden sollen, umfassen einen Herstellungsprozess, einen Schulungsprozess und einen Entsorgungsprozess für das Produkt. Ein wesentlicher Unterschied zwischen einem ARBEITSPRODUKT und einer Produktkomponente besteht darin, dass ein Arbeitsprodukt nicht konstruiert oder Teil des Endprodukts sein muss.

Work product and task attributes- Merkmale von Produkten, Dienstleistungen und Projektaufgaben, die zur Abschätzung der Projektarbeit verwendet werden. Diese Eigenschaften umfassen Elemente wie Größe, Komplexität, Gewicht, Form, Passform oder Funktion. Sie werden normalerweise als eine Eingabe verwendet, um andere Projekt- und Ressourcenschätzungen abzuleiten (z. B. Aufwand, Kosten, Zeitplan).

Hier ist die Liste aller CMMI-Akronyme in alphabetischer Reihenfolge.

Akronym Erweiterte Form
BOGEN Bewertungsanforderungen für CMMI
CAF CMM Appraisal Framework
AUTO Ursachenanalyse und -lösung (Prozessbereich)
CAU Cockpit Avionics Upgrade
CBA IPI CMM-basierte Bewertung zur internen Prozessverbesserung
CBT Computer basiertes Training
CCB Konfigurationssteuerkarte
CM Konfigurationsmanagement (Prozessbereich)
KMG Reifegradmodell
CMMI Integration des Capability Maturity Model
CMMI-SE / SW Integration des Capability Maturity Model für Systems Engineering und Software Engineering
CMMI-SE / SW / IPPD Integration des Capability Maturity-Modells für Systems Engineering, Software Engineering und integrierte Produkt- und Prozessentwicklung
CMMI-SE / SW / IPPD / SS Integration von Capability Maturity-Modellen für Systems Engineering, Software Engineering, integrierte Produkt- und Prozessentwicklung und Lieferantenbeschaffung
COTS Werbung von der Stange
CPM Kritische Pfadmethode
DAR Entscheidungsanalyse und Auflösung (Prozessbereich)
UVP Electronic Industries Alliance
UVP / IS Interim Standard der Electronic Industries Alliance
FAA Föderale Flugverwaltung
FAA-iCMM Integriertes Capability Maturity Model der Federal Aviation Administration
GG Generisches Ziel
GP Generische Praxis
IDEAL Initiieren, Diagnostizieren, Etablieren, Handeln, Lernen
IEEE Institut für Elektro- und Elektronikingenieure
INCOSE Internationaler Rat für Systemtechnik
IPD-CMM Integriertes Reifegradmodell für Produktentwicklungsfähigkeiten
IPM Integriertes Projektmanagement (Prozessbereich)
IPPD Integrierte Produkt- und Prozessentwicklung
IPT Integriertes Produktteam
ISM Integriertes Lieferantenmanagement (Prozessbereich)
ISO Internationale Standardisierungsorganisation
ISO / IEC Internationale Organisation für Normung und Internationale Elektrotechnische Kommission
ES Integriertes Teaming (Prozessbereich)
KSLOC Tausend Quellcodezeilen
MA Messung und Analyse (Prozessbereich)
MOA Niederschrift des Vertrags
NDI Nicht entwicklungsbezogener Gegenstand
NDIA National Defense Industrial Association
OEI Organisationsumfeld für Integration (Prozessbereich)
OID Organisatorische Innovation und Bereitstellung (Prozessbereich)
OPD Organisationsprozessdefinition (Prozessbereich)
OPF Organisatorischer Prozessfokus (Prozessbereich)
OPP Organisatorische Prozessleistung (Prozessbereich)
OT Organisationstraining (Prozessbereich)
OUSD / AT & L. Büro des Unterstaatssekretärs für Verteidigung, Akquisition, Technologie und Logistik
P-CMM People Capability Maturity Model
PA Prozessbereich
PAIS Prozessbewertungsinformationssystem
BESTEHEN Primäres Avionik-Softwaresystem
PERT Programmevaluierungs- und Überprüfungstechnik
PI Produktintegration (Prozessbereich)
PMC Projektüberwachung und -steuerung (Prozessbereich)
PP Projektplanung (Prozessbereich)
PPQA Prozess- und Produktqualitätssicherung (Prozessbereich)
QFD Bereitstellung von Qualitätsfunktionen
QPM Quantitatives Projektmanagement (Prozessbereich)
RD Anforderungsentwicklung (Prozessbereich)
REQM Anforderungsmanagement (Prozessbereich)
RSKM Risikomanagement (Prozessbereich)
SA-CMM Reifegradmodell für Software-Erwerbsfähigkeit
SAM Lieferantenvereinbarungsmanagement (Prozessbereich)
SCAMPI Standard-CMMI-Bewertungsmethode zur Prozessverbesserung
SDMP Managementplan für die Softwareentwicklung
SE Systemtechnik
SE-CMM Reifegradmodell für systemtechnische Fähigkeiten
SEC Executive Council für Software
SECAM Modell zur Bewertung der Fähigkeit zur Systemtechnik
SECM Systemtechnisches Fähigkeitsmodell
SEI Institut für Softwareentwicklung
SE / SW Systems Engineering und Software Engineering
SEPG Software Engineering Process Group
SG Spezifisches Ziel
SP Spezifische Praxis
SPMN Netzwerk der Software-Programmmanager
SS Lieferantenbeschaffung
STSC Software Technology Support Center
SW Softwareentwicklung
SW-CMM Capability Maturity Model für Software
TS Technische Lösung (Prozessbereich)
VAL Validierung (Prozessbereich)
VER Überprüfung (Prozessbereich)
PSP Projektstrukturplan