Einführung

Der wichtigste Teil moderner komplexer Systeme sind Softwareprodukte - die intellektuelle Komponente. Softwareprodukte werden heute zur Lösung von Managementproblemen in fast allen Bereichen der menschlichen Tätigkeit eingesetzt: in der Wirtschaft, im Sozialwesen, im Militär und in anderen Bereichen. Sicherheit Hohe Qualität inländische Softwareprodukte mit ihren Massenentwicklung und Lieferung für verschiedene Anwendungen im Inland und auf dem Weltmarkt ist zu einem strategischen Ziel geworden.

Derzeit gibt es im Software Engineering und der Qualitätssicherung von Softwareprodukten zwei nahezu unabhängige Bereiche der Standardisierung, die bedingt als ISO (International Standards Organization)-Standardprofile und SEI (US Software Engineering Institute)-Reifemodelle bezeichnet werden können. Die ersten sind ziemlich vollständig in [ , ] und die zweiten - in [ , ] vertreten. Der Hauptinhalt des Artikels ist den Reifegradmodellen gewidmet.

Um die Wettbewerbsfähigkeit in der Welt komplexer Softwareprodukte und die Möglichkeit ihres erfolgreichen Exports zu gewährleisten, müssen diese entsprechend den Anforderungen entwickelt und zertifiziert werden Profile internationaler Standards in der Basis ISO9000:2000 oder Reifemodelle - CMMI:2003(Integration des Fähigkeitsreifemodells - Integriertes Reifegradbewertungsmodell für Softwareentwicklung). Diese beiden Richtungen liegen methodisch sehr nahe beieinander und überschneiden sich teilweise durch gegenseitige Bezüge.

Die Verbesserung technischer und wirtschaftlicher Kennzahlen und der Qualität von Softwareprodukten sowie die Vermeidung von Fehlern und Mängeln wird durch den Einsatz von gewährleistet moderne Technologien Softwareentwicklung und Systeme Computergestütztes Design. Dies sind leistungsstarke, ressourcenschonende Technologien zur Erstellung von Softwarekomplexen mit hoher Qualität, Zuverlässigkeit und Sicherheit, die darauf abzielen, die Gesamtkosten der Ressourcen für das Design, die Implementierung und die Wartung von Softwaretools (PS) zu reduzieren. Dazu ist es zunächst notwendig, Methoden und Werkzeuge zur Analyse und Gestaltung anzuwenden, die von Anfang an für eine Konkretisierung und möglichst genaue Darstellung von Zielen, Zwecken und Funktionen sorgen. Lebenszyklus(LC) des PS und Verhinderung der Ausbreitung möglicher Systemfehler auf nachfolgende Entwicklungsstufen. Solche Software-Engineering-Technologien ermöglichen es, System-, Algorithmen- und Softwarefehler in zum Betrieb übergebenen Softwareprodukten zu beseitigen oder erheblich zu reduzieren. Darüber hinaus sind sie wirksam bei der Modifikation und Wartung des PS sowie bei Änderungen in der externen Umgebung.

Um die Qualität, Zuverlässigkeit und Sicherheit beim Einsatz komplexer, kritischer Systeme zu zertifizieren, werden die darin eingesetzten Softwareprodukte geprüft Zertifizierung zertifizierte, problemorientierte Prüfstellen oder Labore. Solche Tests sollten durchgeführt werden, wenn Programme komplexe, kritische Prozesse verwalten oder Informationen verarbeiten, die so wichtig sind, dass Fehler darin oder unzureichende Qualität erheblichen Schaden anrichten können. Zertifizierungstests sollten die Übereinstimmung von Softwarekomplexen mit den Anforderungen der Dokumentation feststellen und es ihnen ermöglichen, innerhalb der Grenzen von Änderungen der Parameter der während der Tests untersuchten externen Umgebung zu arbeiten. Diese Art von Tests zeichnet sich durch höchste Prüfschärfe und -tiefe aus und sollte von Spezialisten durchgeführt werden, die unabhängig von Entwicklern und Kunden (Anwendern) sind.

Die Grundlage für die Zertifizierung sollten detaillierte und effektive Programme und Methoden zum Testen von Softwarepaketen auf die Einhaltung standardisierter Kundenanforderungen, speziell entwickelte Testprobleme und Generatoren für deren Bildung sowie eine hohe Qualifikation und Autorität der Tester sein. Anwendung bei Unternehmensentwicklern von Softwareprodukten, zertifizierte Qualitätssysteme zur Sicherstellung des Lebenszyklus von PS auf der Grundlage von Anforderungen ISO9000:2000 oder CMMI:2003, garantiert ein hohes, nachhaltiges Qualitätsmanagement von Prozessen und Produkten ihres Lebenszyklus und ermöglicht in vielen Fällen auch die Zertifizierung des endgültigen Softwareprodukts. Auftraggeber von komplexen Softwareprojekten entscheiden sich daher in der Regel für ausführende Auftragnehmer, die über Zertifikate verfügen, die ihre Anwendung von Qualitätssicherungssystemen auf der Grundlage angepasster internationaler Standardprofile oder Reifegradmodelle bescheinigen.

Lücken in der Vermittlung von Software-Engineering-Methoden lassen ein weites Feld für die Willkür von Spezialisten bei der Beurteilung der Qualität ihrer Arbeit sowie für das Auftreten zahlreicher Mängel und Fehler in Softwareprojekten. Die zunehmende Komplexität und Verantwortlichkeit moderner, durch Programme gelöster Aufgaben, sowie die möglichen Schäden durch die unzureichende Qualität ihrer Ergebnisse, haben die Relevanz von Beherrschungs-Methoden für eine vollständige, standardisierte Beschreibung der Anforderungen an Qualitätsmerkmale und Messmethoden deutlich erhöht ihre realen, erreichten Werte in verschiedenen Phasen des Software-Lebenszyklus. Der Bedarf an Spezialisten, die Konzepte, Definitionen und Methoden zur Bewertung der Eigenschaften der Qualität von Softwareprodukten kennen, hat stark zugenommen.

Die schnelle Zunahme und Verkomplizierung von Softwarekomplexen führt zur Bildung großer Programmierteams mit professioneller Arbeitsteilung, in denen es notwendig ist, die koordinierten Aktivitäten von Spezialistengruppen an einem einzigen Projekt zu regeln. Die vertraglichen Zusagen von Entwicklern, qualitativ hochwertige Software innerhalb vereinbarter Fristen zu liefern, werden oft nicht eingehalten. Dies ist häufig darauf zurückzuführen, dass Auftraggeber und Auftragnehmer das Qualitätsniveau nach unterschiedlichen Kriterien bewerten, sich in dieser Frage nicht einigen und der Ansatz zur Bewertung der Qualität von Programmen nicht formalisiert genug ist. Darüber hinaus mangelt es manchmal an der Fähigkeit, die Ressourcen richtig einzuschätzen, die erforderlich sind, um qualitativ hochwertige Programme zu erreichen. Infolgedessen bleibt die Qualität von Softwareprodukten auf dem internationalen Markt oft niedrig, unzuverlässig und nicht wettbewerbsfähig. Daher ist das wichtigste Problem in der Entwicklung und Anwendung von vielen moderne Systeme ist die Aus- und Weiterbildung von Spezialisten im Bereich Software Engineering, die Anwendung internationaler Standards, die zur hohen Qualität der Software beitragen und deren verlässliche Bewertung mit dem Hauptziel – Projektprozesse zu gestalten überschaubar, und die Ergebnisse sind vorhersagbar. Es ist notwendig, in der Lage zu sein, die Anforderungen zu formalisieren und spezifische Werte der Merkmale der Qualität des Funktionierens und der Anwendung komplexer Softwarepakete zu erreichen, unter Berücksichtigung der verfügbaren Ressourcen, um diese Qualität sicherzustellen und zu verbessern.

CMMI-Reifegradmodell - 1.1 verfeinert und verbessert bisherige Modelle CMM(siehe ), und berücksichtigt teilweise auch die grundlegenden Anforderungen bestehender internationaler Standards im Bereich Softwaremanagement. Große Aufmerksamkeit in CMMI Entwicklungsprozesse und Berücksichtigung von Iterationen bei sich ändernden Kundenanforderungen, deren Rückverfolgbarkeit auf Funktionen, Komponenten, Tests und Projektunterlagen ist gegeben. Vor kurzem sind Informationen über die Modernisierung der SEI-Version der Version 2003 erschienen. CMMI-1.1 basierend auf gesammelten Erfahrungen und Rückmeldungen von Unternehmen. Es soll 2006 eine neue, deutlich aufgewertete Version des Modells herausbringen CMMI-1.2, danach sollte Version 1.1 auslaufen. Bis Ende 2007 sollten Anwender auf die Version umsteigen CMMI-1.2, und wird zukünftig für eine formalisierte Bewertung der Qualität (Zertifizierung) von Unternehmenstechnologie im Bereich Software Engineering verpflichtend. Die Gültigkeitsdauer des Zertifikats wird auf drei Jahre begrenzt. Kunden und Entwickler großer Softwaresysteme sollten sich vor der offiziellen Veröffentlichung der Version 1.2 durch SEI auf diese Änderungen vorbereiten.

Aufbau und Inhalt des CMMI-Reifegradmodells - 1.1

Zwei Modelloptionen CMMI-1.1 entworfen, um bereitzustellen kontinuierlich Bewertung eines Komplexes von Prozessen in bestimmten Bereich Software erstellen bzw phasenweise Bewertung und Verbesserung der Reife des Unternehmens sowie für die Organisation des Lebenszyklus von Programmkomplexen im Allgemeinen. Modelle CMMI Unterstützung von Spezialisten bei der Organisation und Verbesserung ihrer Produkte sowie bei der Rationalisierung und Wartung der Prozesse zur Entwicklung und Wartung von PS. Das Konzept dieser Modelle umfasst das Management und die Bewertung des Reifegrads komplexer Systeme, das Software-Engineering sowie die Prozesse zur Erstellung integrierter Softwareprodukte und zur Verbesserung ihrer Entwicklung. Die Komponenten des kontinuierlichen und des phasenweisen Modells sind weitgehend ähnlich und können je nach Eigenschaften und Besonderheiten des jeweiligen Projekts in unterschiedlicher Zusammensetzung und Nutzungsreihenfolge ausgewählt und angewendet werden.

Modellbeschreibungsoptionen werden nach einem einzigen Schema erstellt, das allgemeine Abschnitte enthält:

• Vorwort;
• 1 Abschnitt - Einführung;
• Abschnitt 2 - Komponentenmodell;
• Abschnitt 3 - Terminologie;
• Abschnitt 4 - der Inhalt der Ebenen und die Hauptkomponenten jeder Version des Modells (Entwicklung von Zielen und Verfahren);
• Abschnitt 5 - die Struktur der Interaktion von Prozessen; Die vier Kategorien von Prozessen in Abschnitt 7 sind kommentiert, ihr allgemeiner Überblick und die Interaktionsschemata von CMMI-Prozessen:
  • Prozessmanagement;
  • Management - Projektmanagement;
  • Ingenieurwissenschaften);
  • Unterstützung;
• Abschnitt 6 – Verwendung des Modells CMMI- kurze Empfehlungen für Benutzer zur Anwendung des Modells und Schulung; auf die Kompatibilität und Übereinstimmung der Modellprozesse mit den geregelten Prozessen des bisherigen CMM-Modells in den Teilen 2 und 3 der Norm wird hingewiesen ISO 15504.
• Abschnitt 7 ist der letzte und größte in jedem Standard, er nimmt etwa 500 Seiten des gesamten Dokuments ein, was über 700 Seiten umfasst. Dieser Abschnitt enthält detaillierte Empfehlungen für die Implementierung jedes der darin aufgeführten Prozesse, die die Eigenschaften eines bestimmten Modells berücksichtigen.

Erste Wahl(kontinuierliches) Modell spiegelt das Dokument wider: Capability Maturity Model Integration (CMMI) für Systems Engineering/Software Engineering/Integrierte Produkt- und Prozessentwicklung, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD, V1.1, Kontinuierlich). Reifegradbewertungsmodell für integriertes System-Engineering/Software-Engineering/integrierte Produkte und Entwicklungsverfahren - kontinuierliche Ansicht. In diesem Modell besteht der siebte Abschnitt aus Prozessen:

• Prozessmanagement:
  • Organisation der Ausbildung;
  • Organisation der Transformation (Änderungen) von Prozessen;
  • Organisation von Innovationen und Erweiterungen;
• Projektmanagement:
  • Projektplanung;
  • Überwachung und Steuerung von Projektabläufen;
  • Risikomanagement;
  • quantitatives Projektmanagement;
• Ingenieurwissenschaften):
  • Anforderungsmanagement;
  • Anforderungsentwicklung;
  • technische Lösungen;
  • Produktintegration;
  • Überprüfung;
  • Validierung (Bescheinigung, Genehmigung);
• Unterstützung:
  • Konfigurationsmanagement;
  • Analyse und Entscheidungsfindung bei Änderungen;
  • Ursachenanalyse und Problemlösung (Fehlerbeseitigung).

Die fünf Anhänge enthalten:

ABER- die Zusammensetzung der verwendeten literarischen Quellen und Dokumente, die jedoch keine Standards nennt ISO;

BEI- Abkürzungen;

AUS- glossarbasierte Terminologie ISO nur in vier Standards verwendet ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - Anforderungsbeschreibungen und Vorschläge zur Bildung von Modellkomponenten nach Reifegraden;

E - Liste der Entwicklungsteilnehmer CMMI- Projekt.

In diesem Modell liegt der Fokus auf organisatorischen Prozessen, auf der Planung, Steuerung und Kontrolle der Prozesse zur Durchführung von Softwareprojekten, auf der Entwicklung und Verwaltung von Anforderungen an Softwareprodukte. Im Folgenden finden Sie Beispiele für Details in CMMI manche von ihnen.

Projektplanung in diesem sowie im zweiten Modell beinhaltet:

• Einschätzung der möglichen Größe (Maßstab) des Softwareprodukts;
• Einschätzung der Komplexität der Funktionen und Eigenschaften des PS-Projekts;
• Definition des Modells und der Phasen des Lebenszyklus des Softwarepakets;
• Durchführbarkeitsstudie des Projekts - Bestimmung der Kosten, der Arbeitsintensität und der Dauer des Lebenszyklus des Umspannwerks;
• Entwicklung eines abgestuften Arbeitsplans und Projektbudgets;
• Analyse, Identifizierung und Bewertung von Projektrisiken;
• Planung und Verwaltung der Dokumentation von Prozessen und Produkten im Lebenszyklus des PS-Projekts;
• Planung und Verteilung der technischen und personellen Ressourcen nach Phasen des Lebenszyklus des PS;
• Planung der Bereitstellung von Wissen und Qualifikationen eines Spezialistenteams für die Durchführung des Projekts;
• Verallgemeinerung und Analyse der Pläne für das PS-Projekt;
• Koordinierung der Arbeiten und Ressourcen für die Phasen des Lebenszyklus durch den Entwickler mit dem Kunden des PS-Projekts;
• Dokumentation des Arbeitsplans und dessen Freigabe durch den Projektentwicklerleiter.

Anforderungsentwicklungsprozesse zu einem Softwareprodukt ähneln den Prozessen in beiden Modellen und beinhalten:

• Identifizierung der tatsächlichen Bedürfnisse des Kunden und der Benutzer für die Funktionen und Eigenschaften des Softwareprodukts;
• Entwicklung und Abstimmung zwischen dem Kunden und dem Entwickler der anfänglichen, grundlegenden Anforderungen an die Funktionen des Softwareprodukts;
• Ermittlung der verfügbaren Ressourcen und Einschränkungen des Software-Suite-Projekts;
• Zerlegung der grundlegenden Anfangsanforderungen für die Funktionen des PS in eine Reihe von Anforderungen für die Komponenten und Tests des Softwarepakets;
• Formalisierung von Anforderungen für Schnittstellen zwischen Komponenten mit der Betriebs- und externen Umgebung;
• Entwicklung des Konzepts eines Softwareprodukts und Szenarien für seine Verwendung;
• Entwicklung von Anforderungen an die verallgemeinerten Merkmale der funktionalen Eignung und der bestimmungsgemäßen Verwendung der Funktionen des Softwareprodukts.

Anforderungsmanagement Beide Modelle enthalten:

• Erreichen eines eindeutigen Verständnisses der Anforderungen an das PS-Projekt durch den Kunden und Entwickler;
• Einholung von Verpflichtungen durch den Kunden von den Entwicklern, alle seine Anforderungen an das Softwareprodukt zu erfüllen;
• Management von Änderungen in den zwischen dem Kunden und dem Entwickler vereinbarten Anforderungen für das PS-Projekt;
• Gewährleistung der Korrektheit von Änderungen von den allgemeinen Anforderungen für das PS-Projekt zu den Anforderungen für Komponenten und bestimmte Prozesse;
• Erkennen und Identifizieren von Diskrepanzen zwischen Projektentwicklungsprozessen und Kundenanforderungen.

Zweite Option präsentiert das Dokument: Capability Maturity Model Integration (CMMI) für Systems Engineering/Software Engineering/Integrierte Produkt- und Prozessentwicklung, Version 1.1, Stufendarstellung (CMMI-SE/SW/IPPD, V1.1, Gestaffelt). Reifegradbewertungsmodell für integriertes System-Engineering/Software-Engineering/integrierte Produkte und Entwicklungsverfahren - schrittweise Einführung. Das Modell basiert auf der Beibehaltung des Konzepts der fünf Reifegrade CMM[ , ]. Die Zusammensetzung der Prozesse wiederholt praktisch die oben für die erste Version des Modells angegebene, jedoch in einer etwas anderen Reihenfolge und mit relativ kleinen Ergänzungen.

Erste Ebene ist durch erhebliche Unsicherheit in der Zusammensetzung und dem Inhalt von Prozessen in verschiedenen relativ einfachen Projekten gekennzeichnet und wird daher in dem Dokument nicht kommentiert. Daher bei der Klärung und Detaillierung der Inhalte von Prozessen in einer abgestuften Version CMMI empfohlen, begrenzt zu werden vier Hauptebenen:

• zweites Level- formalisiert grundlegende Verwaltung Projekte:
  • Anforderungsmanagement;
  • Projektplanung;
  • Projektüberwachung und -steuerung;
  • Verwaltung von Vereinbarungen mit Lieferanten;
  • Messung und Analyse von Prozessen und Produkten;
  • Sicherstellung der Qualität von Prozessen und Produkten;
  • Konfigurationsmanagement;
• drittes Level- enthält die Standardisierung der Hauptprozesse:
  • Anforderungsentwicklung;
  • technische Lösungen;
  • Produktintegration;
  • Überprüfung;
  • Validierung (Zertifizierung);
  • der Inhalt von Organisationsprozessen;
  • Definition organisatorischer Prozesse;
  • Organisation der Ausbildung;
  • integriertes Management von Projektprozessen und Produkten;
  • Risikomanagement;
  • Integration des Entwicklungsteams;
  • integriertes Lieferantenmanagement;
  • Analyse und Lösung von Problemen (Mängelbeseitigung);
  • Organisation des Integrationsumfelds;
• vierte Ebene- definiert quantitatives Management:
  • Organisation der Darstellung der Qualität von Prozessen;
  • quantitatives Management des gesamten Projekts und der Ressourcen;
• fünfte Ebene- Optimierung, kontinuierliche Verbesserung:
  • Organisation, Innovation, quantitatives Management von Prozessen und Bereitstellung von Ressourcen;
  • Analyse der Fehlerursachen, Verbesserung der Qualität und des Managements von Prozessen und Produkten.

Anwendungen in der zweiten Version des Modells ähneln in ihrer Zusammensetzung den obigen Anwendungen für das erste Modell. Es wird empfohlen, sich bei jedem höheren Reifegrad zu bewerben alle Prozesse vorherige niedrigere Ebenen. In beiden Versionen des Modells wird jeder oben hervorgehobene grundlegende Prozess mit detaillierten Empfehlungen für seine praktische Umsetzung kommentiert, die Beschreibungen von etwa 20–30 Seiten in einer einheitlichen Struktur enthalten:

• die Gesamtziele des zu erreichenden Prozesses;
• einleitende Bemerkungen und eine allgemeine Beschreibung der Prozessfunktionen;
• spezifische Prozessziele;
• Prozessmanagement;
• Entwicklung von Prozessanforderungen;
• Interaktion und Schnittstellen mit anderen Prozessen;
• praktische Ziele - die erforderlichen Ergebnisse der Prozessaktivitäten;
• Planen von Aktionen in einem bestimmten Prozess;
• Analyse und Validierung (Freigabe) der Ergebnisse der Prozessimplementierung;
• Überwachung und Steuerung des Prozesses.

Diese Empfehlungen hinsichtlich Umfang, Inhalt und Vollständigkeit von Beschreibungen grundlegender Prozesse ähneln einer Reihe von Standards für das PS-Lebenszyklusprofil, die in dargestellt werden. Durch die Bestellung und Bewertung der Vollständigkeit der verwendeten Prozesse gemäß den Reifegraden können Sie das Produktionspotenzial von Unternehmen - Entwicklern von Softwareprodukten - in Bezug auf die prognostizierte Qualität der Prozesse und die Ergebnisse ihrer Aktivitäten und die Bereitschaft zur Zertifizierung ermitteln Einhaltung eines bestimmten Reifegrades des Modells CMMI - 1.1.

Betonung auf Modellen CMMI wird den Managementprozessen des PS-Projekts gegeben. Diese Anforderungen und Prozesse der Modelle entsprechen praktisch den geregelten und detaillierten Empfehlungen in den Standards. ISO 9001:2000 und die Hauptkomponenten des Profils komplexer PS-Lebenszyklusstandards [ , ]. Anforderungen an Prozesse in den funktionalen Abschnitten 4-8 der Standards ISO 9001, ISO 9004, ISO 90003 im Modell können mehrere inhaltlich ausreichende Abschnitte verglichen werden CMMI(in Fig. 1 die Inhaltsüberlappungszone). Die Gemeinsamkeit von Prozessen und Anforderungen besteht in der Ähnlichkeit: Aufbau, Terminologie, Struktur, Liste empfohlener Managementprozesse, Planung, Berücksichtigung verfügbarer Ressourcen, Implementierung von Software-Engineering-Prozessen, Bewertung und Organisation von Spezialisten.

Abbildung 1. Gemeinsamkeit von Prozessen und Anforderungen von Standards und Reifegradmodellen

Aus Sicht der Unterstützung und Regulierung des gesamten Lebenszyklus großer Softwareprojekte die Mängel von Modellen CMMI zum Profil bestehender Standards ISO kann Folgendes umfassen:

Um die Reifegrade der Prozesse zur Sicherstellung des oben dargestellten Lebenszyklus der PS zu ermitteln, wurde ein umfangreicher technischer Bericht entwickelt und 1998 erstmals freigegeben. ISO 15504, bestehend aus neun Teilen und vielen Anwendungen. Es skizziert das Reifegradmodell CMM und acht Grundprinzipien Software-Engineering auf Basis des Standards ISO9000:2000. Dann in ISO Dieses Dokument wurde unter vollständiger Beibehaltung der Ziele und des Konzepts einer radikalen Überarbeitung, Reduzierung, Vereinfachung der Struktur und des Inhalts unterzogen und genehmigt als Standard in fünf Teilen.

Standard ISO 15504:1-5:2003-2006 regelt die Bewertung und Zertifizierung der Reife der Prozesse zur Erstellung, Wartung und Verbesserung von Softwaretools und -systemen, die von Unternehmen durchgeführt werden:

• den eigenen Staat zu errichten technologische Prozesse und ihre Verbesserung;
• um die Eignung eigener Prozesse zu bestimmen, um bestimmte Anforderungen oder Klassen von Kundenanforderungen zu erfüllen;
• im Hinblick auf ihre Leistungsfähigkeit bestimmte Verträge mit Kunden von PS und Systemen.

Der Standard trägt dazu bei: zur Selbsteinschätzung des Reifegrads von Unternehmen, zur Sicherstellung eines angemessenen Managements attestierter Prozesse, zur Bestimmung des Profils von Prozessbewertungen und für jeden Umfang und jede Größe von Betriebssystemen und Systemen. Die Anwendung der Norm richtet sich an sich entwickelnde Unternehmen und Fachkräfte Kultur der kontinuierlichen Verbesserung Technologiereife Gewährleistung des Lebenszyklus des PS, der die Geschäftsziele der Projekte erfüllt, und Optimierung der Nutzung verfügbarer Ressourcen. Die Reifegradbewertung von Unternehmensprozessen bietet die Möglichkeit, sie zu vergleichen und auszuwählen, die für bestimmte Projekte vorzuziehen sind:

• für Kunden, Käufer, Benutzer von Softwareprodukten und -systemen: die Fähigkeit, den aktuellen und potenziellen Reifegrad der Lebenszyklusprozesse des Lieferanten zu bestimmen;
• für Anbieter und Entwickler: die Fähigkeit, die aktuelle und potenzielle Reife ihrer eigenen Software- und Systemlebenszyklusprozesse, Bereiche und Prioritäten für die Prozessverbesserung zu bestimmen;
• für Immatrikulationsbeurteiler: ein Rahmenwerk zur Durchführung und Verbesserung von Begutachtungsprozessen.

Die Zulassung in der Norm wird behandelt in zwei Aspekte: um die Lebenszyklusprozesse der PS und Systeme eines bestimmten Unternehmens zu verbessern und festzustellen, ob die deklarierte Reife der projekt- oder unternehmensunterstützenden Prozesse den tatsächlich verwendeten Prozessen entspricht. Dies spiegelt sich in den folgenden fünf Teilen der Norm wider. ISO 15504:1-5:2003-2006.

Teil 1 - Begriff und Wortschatz. Enthält allgemeine Informationen zu den Prozessen zur Zertifizierung der Reife von Software und Systemen und Empfehlungen zur Anwendung von Teilen des Standards. Umrissen Allgemeine Anforderungen für Zertifizierung, Terminologie, Struktur wird der Geltungsbereich der übrigen Teile der Norm festgelegt.

Teil 2 - Durchführung (Herstellung) der Zertifizierung. Es enthält detaillierte Anforderungen zur Durchführung von Zertifizierungsprozessen als Grundlage zur Verbesserung und Bestimmung des Reifegrades von technologischen Prozessen zur Sicherung des Lebenszyklus der PS und Systeme. Das Dokument definiert Prozesse zur Durchführung von Attestierungen, Modelle für empfohlene Prozesse zur Attestierung und Verifizierung von Prozessen, damit sie objektiv, aussagekräftig und repräsentativ sind.

Teil 3 - Anleitung zur Erstellung der Bescheinigung. Bietet einen Überblick über die Technologie zur Durchführung von Reifegradbewertungsprozessen und zur Interpretation der Implementierung von Anforderungen. Es spiegelt wider: Durchführung der Zertifizierung; Messinstrumente zur Bestimmung von Reifeprozessen; Auswahl und Anwendung von Zertifizierungsinstrumenten; Bewertung der Kompetenz von Zertifizierern; Überprüfung der Konformität der Bescheinigung mit den erklärten Anforderungen. Validierungswerkzeuge können von Unternehmen bei der Planung, Verwaltung, Überwachung, Steuerung und Verbesserung von Softwareprodukten und -systemen, bei deren Erwerb, Entwicklung, Anwendung und Wartung eingesetzt werden.

Teil 4 – Benutzerführung zur Prozessverbesserung und Prozessreife in diesen beiden Aspekten. Es wird eine Reihe von Schritten empfohlen, darunter: Anwendung der Ergebnisse der Validierungsprozesse; Festlegung von Zielen für die Reifebewertung; Ermittlung von Ausgangsdaten für die Zertifizierung; Einschätzung der möglichen Reduzierung der daraus resultierenden Risiken; Schritte zur Verbesserung von Prozessen; Schritte zur Bestimmung des Reifegrads; Abgleich der Ergebnisse der Qualifikationsanalyse mit den Anforderungen.

Teil 5 - Beispielmodell für Attestierungsprozesse zur Erfüllung der in Teil 2 dargestellten Anforderungen. Ein umfangreiches Dokument (162 Seiten) liefert praktische Beispiele der vorangegangenen Teile des Standards zur Organisation, Bewertung und Verbesserung von Reifegradbewertungen von Lebenszyklusprozessen für verschiedene Anwendungsbereiche, Softwareprojekte und Unternehmen.

Bei der praktischen Umsetzung von Projekten und der Sicherung des Lebenszyklus komplexer Software ist es für Entwickler und Anbieter mitunter schwierig, die Vorteile von Modellen für die Anwendung zu erkennen und aufzuzeigen. CMMI. Abhängig von den Traditionen des Unternehmens und den Merkmalen eines großen Projekts ist es oft ratsam, das PS als Hauptvolltext zu verwenden StandardprofilISO, und für die Kundenbewertung Reifegrad Management, organisatorische und technologische Unterstützung von PS-Projekten wenden spezifische Empfehlungen an CMMI. Diese Richtlinien können effektiv verwendet werden in Zertifizierung der Prozessqualität bei Unternehmen, die den Lebenszyklus des PS bereitstellen, alternativ oder zusammen mit einer Zertifizierung nach einer Reihe von Managementstandards ISO 9000, abhängig von den Besonderheiten des Projekts und den Anforderungen des Antragstellers für die Zertifizierung eines Softwareprodukts oder einer Technologie, um deren Lebenszyklus sicherzustellen.

Organisation der Zertifizierung von Softwareprodukten

Die Zertifizierung besteht aus einer Reihe von organisatorischen Prozessen, die sich zusammensetzen Zertifizierungssystem, diese Prozesse werden durch geregelte Verfahren und Dokumente unterstützt und müssen von qualifizierten, zertifizierten Experten - Inspektoren - durchgeführt werden. Für die Zertifizierung des Unternehmensentwicklers und der Ergebnisse seiner Aktivitäten - Softwareprodukte, Modelle CMMI oder Normprofile ISO[ , ] wird eine bestimmte Disziplin empfohlen, die an die spezifischen Eigenschaften der Objekte und des Umfelds des Lebenszyklus der PS angepasst werden sollte. Die nachfolgend aufgeführten Prozesse und Dokumente sind für große Projekte konzipiert und können in einfacheren Fällen nach Vereinbarung zwischen Entwicklern, Kunden und Zertifizierern reduziert werden.

Die Zertifizierungsarbeit beginnt mit der Akkreditierung einer Stelle oder eines Prüflabors, der Erstellung und Einreichung eines Antrags und einer Reihe von Dokumenten bei der Zentralen Zertifizierungsstelle zur Entscheidung über die Durchführbarkeit der Akkreditierung. Bei positivem Testergebnis wird eine Akkreditierungsurkunde erstellt und ausgestellt.

Vorschriften über die Zertifizierungsstelle oder das Labor ist das Hauptdokument, das den Themenbereich der Akkreditierung, den Rechtsstatus, die Funktionen, die Struktur, die Rechte und Pflichten, die Methoden, die Mittel und die Organisation von Tests festlegt. Der Reisepass des Zertifizierungslabors (Zentrale) muss Angaben zur Ausstattung enthalten Informatik zum Testen erforderlichen Personal und Personal, Ausrüstung mit Testwerkzeugen, Bereitstellung von behördlichen, technischen und methodischen Dokumenten sowie anderen zum Testen erforderlichen Ressourcen.

Qualitätshandbuch enthält eine Grundsatzerklärung, eine Beschreibung der Methoden und Verfahren im Zusammenhang mit der Umsetzung der Hauptfunktionen und Aufgaben der Zertifizierungsstelle oder des Labors, die Gewährleistung der Qualität der Tests und das Vertrauen in die Ergebnisse von Bewertungen, Tests und Prüfungen. Das Qualitätshandbuch enthält normalerweise Abschnitte [ TWLSC $

• Politik im Bereich der Qualitätssicherung von Prüfungen und Prüfungen;
• Ausstattung des Zentrums mit relevanten methodischen Materialien und Software und Testwerkzeugen;
• Formalisierung von Anforderungen an Testobjekte;
• Politik im Bereich der technischen Ausstattung des Zentrums und der Personalentwicklung;
• Archivierung und Sicherheitskontrolle der Dokumentation der Zertifizierungsergebnisse.

Zur Bewertung von zertifizierungspflichtigen Produkten oder Prozessen stellt der Antragsteller einen Antrag an die Zertifizierungsstelle in der im Zertifizierungssystem übernommenen Form. Die Zertifizierungsstelle führt auf Antrag Arbeiten zur Vorbereitung und Organisation der Produktzertifizierung durch. Diese Arbeit beinhaltet:

• Auswahl eines Zertifizierungssystems unter Berücksichtigung der Besonderheiten der Produkte (Menge, Technologie, Anforderungen der behördlichen Dokumente usw.) und der Vorschläge des Entwicklers;
• Festlegung der Anzahl und Reihenfolge der Probenahmen und zu prüfenden Komponenten, sofern dies nicht in den Normen festgelegt ist;
• Auswahl und Identifizierung eines akkreditierten Prüflabors zur Durchführung der Prüfungen;
• Vorbereitung eines Vertragsentwurfs für die Ausführung von Arbeiten.

Der vorbereitende Teil der Zertifizierungsarbeit endet mit der Veröffentlichung einer Entscheidung in der im Zertifizierungssystem angenommenen Form. Der Bescheid wird zusammen mit dem Werkvertragsentwurf dem Antragsteller zugesandt. Bei der Organisation von Zertifizierungstests werden Auswahl und Studium der aktuellen Regulierungsdokumente für Produkte, die zur Zertifizierung angemeldet sind, Methoden zur Prüfung und Bewertung der Ergebnisse durchgeführt.

Der Antragsteller trifft die endgültige Entscheidung, welche Elemente des Qualitätssystems, Bereiche und Arten von organisatorischen und technischen Aktivitäten während der Zertifizierung in einem bestimmten Zeitintervall überprüft werden. Der Antragsteller muss Bedingungen schaffen und Unterlagen einreichen, um die Überprüfungsprozesse sicherzustellen. Er kann der Zertifizierungsstelle Testberichte vorlegen, die während der Entwicklung und Produktion von Produkten durchgeführt wurden, Dokumente über Tests, die von externen Testlabors durchgeführt wurden, und andere Dokumente, die die Übereinstimmung der Technologie oder Produkte mit den festgelegten Anforderungen belegen. Basierend auf der Analyse der dokumentierten Nachweise der Konformität ihrer Produkte mit den festgelegten Anforderungen, die mit dem Antrag vorgelegt werden, kann die Zertifizierungsstelle entscheiden, den Prüfumfang zu reduzieren oder ein Zertifikat auszustellen.

Die Tests werden von Testlabors durchgeführt, die akkreditiert sind, nur die Tests durchzuführen, die in ihren behördlichen Akkreditierungsdokumenten vorgesehen sind. Wenn die Durchführung von Prüfungen in der Prüfeinrichtung eines akkreditierten Labors nicht möglich ist, können Prüfungen durch das Personal dieses Labors beim Hersteller oder Verbraucher dieses Produkts unter Verwendung der eigenen Einrichtungen der Prüfstelle oder der vom Lieferanten verfügbaren Prüfeinrichtungen durchgeführt werden .

Der Prozess der Zertifizierung von Softwareprodukten und Unternehmensqualitätssystemen umfasst:

• Analyse und Auswahl einer auf diesem Gebiet kompetenten Stelle und eines zertifizierten Labors zur Durchführung von Zertifizierungsprüfungen durch den Entwickler oder Kunden (Antragsteller);
• Einreichung eines Antrags auf Prüfung durch den Antragsteller bei der Zertifizierungsstelle und Beschlussfassung über den Antrag durch die Zertifizierer, Auswahl eines Zertifizierungssystems, Abschluss eines Zertifizierungsvertrags;
• Ermittlung der Anforderungen an das Qualitätssystem des Unternehmens und/oder an die Version des zu testenden Softwareprodukts;
• Durchführung von Zertifizierungstests des Qualitätssystems des Unternehmens oder der Version des Softwareprodukts durch das Zertifizierungslabor;
• Analyse der erzielten Ergebnisse und Entscheidung des Labors und/oder der Zertifizierungsstelle über die Möglichkeit, dem Antragsteller eine Konformitätsbescheinigung auszustellen;
• Ausstellung durch die Zertifizierungsstelle an den Antragsteller - ein Zertifikat und eine Lizenz zur Verwendung des Konformitätszeichens und zur Ausstellung zertifizierter Produkte - Versionen des Softwareprodukts;
• Durchführung der Inspektionskontrolle durch die Zertifizierungsstelle des zertifizierten Qualitätssystems des Unternehmens und / oder der Produkte;
• Durchführung von Korrekturmaßnahmen durch den Antragsteller bei Verletzung der Konformität der Prozesse des Qualitätssystems und / oder der Produkte mit den festgelegten Anforderungen und bei fehlerhafter Anbringung des Konformitätszeichens.

Bei der Überprüfung der Verantwortung des Managements des Entwicklers für die Produktqualität sollte festgestellt werden, dass das Unternehmen oder Projekt eine dokumentierte Politik, Ziele und Verpflichtungen im Bereich der Qualität hat, sowie inwieweit diese Politik verstanden, umgesetzt und aufrechterhalten wird in einwandfreiem Zustand auf allen Ebenen der Organisation. Es sollte festgelegt werden, dass das Unternehmen einen Vertreter der Geschäftsleitung hat, der unabhängig von anderen Aufgaben die Befugnis und Verantwortung für die kontinuierliche Umsetzung der Anforderungen der Normen und Regeldokumente des Qualitätssystems hat. Die Verfügbarkeit von Anforderungen, Verfahren, Werkzeugen und geschultem Personal für die praktische Umsetzung der Qualitätssystemprozesse sollte ebenso überprüft werden wie die Relevanz und systematische Dokumentation aller Komponenten, Anforderungen und Bestimmungen des Qualitätssystems, das ein durchgehend integrierter Prozess ist den Lebenszyklus des PS. Überprüfungen des Qualitätssystems sollte eine Definition enthalten:

• Verfügbarkeit und Vollständigkeit der technologischen Dokumentation und Erfüllung ihrer Anforderungen in der Praxis;
• der Stand der technologischen Ausrüstung und die Verfügbarkeit eines Systems für ihre Wartung;
• das Bestehen und die Wirksamkeit des Kontroll- und Prüfsystems;
• Zustand von Mess- und Prüfgeräten;
• Verfügbarkeit eines Systems zur Identifizierung und Beseitigung festgestellter Mängel an Produkten oder Technologien.

Basierend auf den Tests werden die erhaltenen Ergebnisse bewertet und Schlussfolgerungen über die Konformität oder Nichtkonformität von Produkten oder Prozessen mit den Anforderungen regulatorischer Dokumente begründet. Prüfberichte werden der Zertifizierungsstelle sowie auf Anfrage dem Antragsteller vorgelegt. Prüfberichte werden für die in den Regeln der Produktzertifizierungssysteme und in den Unterlagen des Prüflabors festgelegten Zeiträume aufbewahrt, jedoch nicht weniger als drei Jahre.

Nach Erhalt und Prüfung der Vollständigkeit und Qualität der Dokumentation sollten die Spezialisten des Prüflabors diese durchführen Prüfung des Grades der tatsächlichen Anwendung des Qualitätssystems beim Unternehmen. Das Testen beginnt mit der Entwicklung eines Testprogramms für das Qualitätssystem, das als Arbeitsplan für nachfolgende Arbeiten dienen sollte. Das Programm ist ein internes Arbeitsdokument des Prüflabors und soll eine nach den Besonderheiten des Entwicklerunternehmens detaillierte Liste der Arbeiten enthalten, einschließlich einer Analyse der Vollständigkeit und Qualität der eingereichten Quelldokumente und des Grades ihrer praktischen Anwendung bei der Konzeption, Entwicklung und Auslieferung der Software. Die Prüfung der Anwendung der Verfahren des Qualitätssystems wird vom Prüflabor an den Arbeitsplätzen des Unternehmens durchgeführt, das den Lebenszyklus des PS bereitstellt. Die Anwesenheit von Spezialisten-Entwicklern relevanter Dokumente am Arbeitsplatz und die Vollständigkeit der Verwendung ihrer Bestimmungen und Empfehlungen werden überprüft. Überprüfungen des Projektstatus und interne Audits des Qualitätssystems, der Prozesse und/oder der Produkte sollten von Personal durchgeführt werden, das von den direkt für die Durchführung dieser Arbeiten Verantwortlichen unabhängig ist.

Methoden zur Überprüfung der Entwicklungsqualität solte gegeben sein notwendigen Ressourcen für die Durchführung des Testprogramms, Planungsmethoden und die Entwicklung privater Testverfahren. Methoden sollten enthalten: Objekte und Ziele des Testens; bewertete Qualitätsindikatoren; Bedingungen und Verfahren für die Prüfung; Methoden zur Verarbeitung, Analyse und Bewertung von Testergebnissen; technischer Support testen und melden. Die während der Tests und des Testverfahrens verwendete Hard- und Software sowie die erwarteten Ergebnisse der Prüfungen sollten angegeben werden. Es sollten Methoden entwickelt werden, um Korrekturen und Maßnahmen zur Behebung von Fehlern zu kontrollieren, wenn eine solche Anfrage beim Auditmanagementdienst eingeht. Der Testprogramm-Verwaltungsdienst sollte Verfahren zur Wahrung der Vertraulichkeit aller Testinformationen sowie der Daten der Assessoren festlegen.

Testberichte dem Antragsteller und der Zertifizierungsstelle vorgelegt werden. Der Antragsteller kann der Zertifizierungsstelle unter Berücksichtigung der Gültigkeitsdauer Prüfberichte, die während der Entwicklung und Herstellung von Produkten durchgeführt wurden, oder Unterlagen über Prüfungen vorlegen, die von im Zertifizierungssystem akkreditierten oder anerkannten inländischen oder ausländischen Prüflaboratorien durchgeführt wurden. Anhand von Zertifizierungsprüfprotokollen werden die erzielten Ergebnisse bewertet und die daraus gezogenen Schlussfolgerungen über die Konformität oder Nichtkonformität von Produkten mit den Anforderungen regulatorischer Dokumente begründet.

Fazit zu den Ergebnissen der Zertifizierungstests wird von Zertifizierern entwickelt und enthält verallgemeinerte Informationen über die Testergebnisse und die Gründe für die Ausstellung eines Zertifikats. Im Falle negativer Ergebnisse von Zertifizierungstests wird entschieden, die Ausstellung einer Konformitätsbescheinigung abzulehnen. Nach Abschluss des zertifizierten Produkts oder Qualitätssystems können die Prüfungen wiederholt werden. Die Ergebnisse der Analyse des Standes der Technik oder der Produktqualität werden durch Gesetz errichtet, das Schätzungen für alle Positionen des Testprogramms enthält und Schlussfolgerungen enthält, einschließlich einer allgemeinen Bewertung des Produktionsstands und der Produkte sowie der Notwendigkeit von Korrekturmaßnahmen. Das Gesetz wird von der Zertifizierungsstelle zusammen mit Prüfberichten, einem Antrag auf Ausstellung und Bestimmung der Gültigkeitsdauer eines Zertifikats für ein Softwareprodukt, der Häufigkeit der Inspektionskontrolle sowie zur Ausarbeitung von Korrekturmaßnahmen verwendet.

Basierend auf den Ergebnissen der Zertifizierungstests und der Prüfung der Dokumentation wird über die Ausstellung eines Zertifikats entschieden. Bei negativen Ergebnissen der Zertifizierungstests wird entschieden Weigerung, eine Bescheinigung auszustellen Beachtung. Darüber hinaus können dem antragstellenden Unternehmen Vorschläge zur Beseitigung der vermeintlichen Ursachen negativer Prüfergebnisse übermittelt werden, nach Fertigstellung der zertifizierten Produkte können die Prüfungen wiederholt werden.

Die Zertifizierungsstelle bewertet nach Analyse der Prüfberichte, Bewertung der Produktion, Zertifizierung des Qualitätssystems, Analyse der in der Entscheidung über den Antrag angegebenen Dokumentation die Konformität der Produkte mit den festgelegten Anforderungen und erstellt auf der Grundlage der Meinung von Experten ein Zertifikat und registriert es. Bei Änderungen an der Design- oder Betriebsdokumentation, die sich auf die Qualität des bei der Zertifizierung zertifizierten Systems oder Softwareprodukts auswirken können, muss der Antragsteller die Zertifizierungsstelle darüber informieren, um über die Notwendigkeit zusätzlicher Tests zu entscheiden. Nach der Registrierung tritt das Zertifikat in Kraft und wird dem antragstellenden Unternehmen zugesandt. Gleichzeitig mit der Ausstellung eines Zertifikats kann das antragstellende Unternehmen ausgestellt werden Lizenz für das Recht zur Nutzung des Prüfzeichens.

für zertifizierte Softwareprodukte während ihres Betriebs während der gesamten Gültigkeitsdauer der Konformitätsbescheinigung, Kontrollkontrolle. Die Inspektionskontrolle erfolgt in Form von periodischen und außerplanmäßige Kontrollen Einhaltung der Anforderungen an die Qualität von Technik und zertifizierten Produkten. Gegenstand der Kontrolle sind je nach Zertifizierungssystem zertifizierte Produkte, das Qualitätssystem oder die Stabilität der Produktion des Entwicklers. Bei der Bestimmung der Häufigkeit und des Umfangs der Überprüfung werden folgende Faktoren berücksichtigt: Grad des Gefahrenpotentials des Softwareprodukts, Produktionsstabilität, Release-Umfang, Verfügbarkeit und Anwendung eines Qualitätssicherungssystems während der Entwicklung, Informationen über die Ergebnisse der vom Hersteller, staatlichen Kontroll- und Überwachungsbehörden durchgeführten Prüfungen des Produkts und seiner Herstellung.

Ergebnisse der Inspektionskontrolle werden durch Gesetz errichtet, das die Ergebnisse von Stichproben und anderen Kontrollen auswertet, trifft eine allgemeine Schlussfolgerung über den Produktionsstand zertifizierter Produkte und die Möglichkeit, die Gültigkeit des ausgestellten Zertifikats aufrechtzuerhalten. Das Gesetz wird in der Zertifizierungsstelle gespeichert und seine Kopien werden an den Entwickler und an die Organisationen gesendet, die an der Inspektionskontrolle teilgenommen haben. Basierend auf den Ergebnissen der Inspektionskontrolle kann die Zertifizierungsstelle die Gültigkeit des Zertifikats aussetzen oder annullieren und die Lizenz für das Recht zur Verwendung des Konformitätszeichens entziehen, wenn die Produkte die Anforderungen der während der Zertifizierung kontrollierten behördlichen Dokumente nicht erfüllen , sowie in folgenden Fällen:

• grundlegende Änderungen des Reifegradmodells, des Normenprofils, der Produktvorschriften oder der Testmethode;
• Änderungen im Design (Zusammensetzung), Vollständigkeit der Produkte;
• Änderungen in der Organisation oder Technologie der Entwicklung und Produktion;
• Nichteinhaltung der Anforderungen der Technologie, der Kontroll- und Testmethoden, des Qualitätssystems, wenn die aufgeführten Änderungen dazu führen können, dass die Produkte die während der Zertifizierung kontrollierten Anforderungen nicht erfüllen.

Die Entscheidung über die Aussetzung der Gültigkeit des Zertifikats und der Lizenz zur Nutzung des Konformitätszeichens wird nicht getroffen, wenn der Antragsteller durch mit der ausstellenden Zertifizierungsstelle vereinbarte Korrekturmaßnahmen die festgestellten Ursachen der Nichtkonformität beseitigen und bestätigen kann , ohne erneute Prüfung in einem akkreditierten Labor, die Konformität des Produkts oder Prozesses mit normativen Dokumenten. Ist dies nicht möglich, erlischt die Gültigkeit des Zertifikats und die Lizenz zur Nutzung des Übereinstimmungszeichens. Informationen über die Aussetzung oder Aufhebung des Zertifikats werden von der Zertifizierungsstelle, die es ausgestellt hat, an den Antragsteller, Verbraucher und andere interessierte Organisationen übermittelt. Die Gültigkeit des Zertifikats und das Recht zur Kennzeichnung von Produkten mit dem Prüfzeichen kann verlängert werden, wenn das Entwicklerunternehmen folgende Bedingungen erfüllt:

• Ermittlung der Ursachen der Nichteinhaltung und deren Beseitigung;
• Vorlage eines Berichts über die durchgeführten Arbeiten zur Verbesserung und Sicherung der Produktqualität bei der Zertifizierungsstelle;
• Durchführung zusätzlicher Produkttests nach den Methoden und unter der Kontrolle der Zertifizierungsstelle und Erzielung positiver Ergebnisse.

Dokumentation von Prozessen und Ergebnissen der Zertifizierung von Softwareprodukten

Aufbau und Inhalt der Dokumentation für die Zertifizierung des Qualitätssystems Unternehmen hängen von den Merkmalen des Entwurfs, der Entwicklung und der Modifikation von Software sowie von den Anforderungen an ihre Qualität und den Merkmalen des technologischen Umfelds ab. Daher sollte der erforderliche Dokumentensatz für jedes Unternehmen oder Projekt in Bezug auf diese Merkmale ausgewählt und angepasst werden. Die bei der Zertifizierung bewerteten Indikatoren des Qualitätssystems sind die Verfügbarkeit relevanter Dokumente und die praktische Erfüllung der Anforderungen eines bestimmten Niveaus des Reifegradmodells. SMMI oder ein angepasstes Normenprofil basierend auf ISO9000:2000, sowie auf ihrer Grundlage erstellt, Berufsbeschreibungen Spezialisten des Unternehmensentwicklers. Der Antragsteller muss eine Reihe von Dokumenten vorbereiten und dem Prüflabor vorlegen, die zwischen dem Kunden und dem Entwickler vereinbart und genehmigt wurden, um ihre Zuverlässigkeit, ausreichende Zusammensetzung und Verarbeitung gemäß den behördlichen Dokumenten zu überprüfen.

Ein indikativer Satz grundlegender Dokumente für die Zertifizierung besteht aus drei Gruppen:

• Basic Vorschriften Qualitätssysteme in Übereinstimmung mit der Nomenklatur und dem Inhalt des Profils von Standards auf der Grundlage ISO9000:2000 oder Reifegradmodelle SMMI, sowie das von den Entwicklern auf ihrer Grundlage erstellte Programm, Handbuch und Anweisungen, die den Testern (Experten) des Qualitätssystems oder der Produkte des auditierten Unternehmens vorgelegt werden;
• Quelldokumente, die ein bestimmtes Unternehmen oder Projekt sowie den Lebenszyklus eines Softwaretools charakterisieren, die vom Projektmanagement zur Zertifizierung seiner Qualität erstellt wurden;
• Berichtsdokumente der Tester, die die Ergebnisse des Audits (Zertifizierung) des Qualitätssystems und / oder Softwareprodukts des Unternehmens widerspiegeln und der Zertifizierungsstelle, dem Antragsteller und der Leitung des auditierten Unternehmens vorgelegt werden.

Das zur Zertifizierung vorgelegte Softwareprodukt oder Qualitätssystem des Unternehmens muss zusammen mit der entsprechenden Dokumentation eingereicht werden. Die Liste und der ungefähre Inhalt der Gruppen dieser Dokumente konzentrieren sich auf den allgemeinen Fall der Überprüfung der Qualitätssysteme von Unternehmen, die den Lebenszyklus großer Softwareprodukte sicherstellen. Der Dokumentensatz kann nach Absprache zwischen Antragsteller, Zertifizierer und Leitung des auditierten Unternehmens entsprechend den Besonderheiten von Softwareprojekten reduziert und angepasst werden. Einige Dokumente können zu integrierten Berichten mit einer klaren Verantwortung bestimmter Spezialisten für deren Umsetzung kombiniert werden.

Grundlegende Dokumente des Unternehmensqualitätssystems und des Softwarelebenszyklus

1. Konzept, Terminologie, Anforderungen und Anleitung zur Leistungsverbesserung - Qualitätsmanagementsysteme - ISO9000:2000 oder eine Version des CMMI-Reifemodells.
2. Angepasste Versionen oder Liste von Abschnitten und Empfehlungen der Normen ISO 12207, ISO 15504, ihre Änderungen und Anwendungsrichtlinien, die während der Anpassung ausgewählt und für die Verwendung im Qualitätssystem eines bestimmten Unternehmens- oder Softwareproduktprojekts obligatorisch sind.
3. Angepasste Version oder Liste von Abschnitten und Empfehlungen der Norm ISO 900003, ausgewählt während der Anpassung und obligatorisch für die Verwendung im Qualitätssystem eines Unternehmens, das ein Softwareprodukt herstellt.
4. Grundlegende Merkmale und Qualitätsmerkmale des PS-Projekts, identifiziert, angepasst und auf der Grundlage von Standards spezifiziert ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Angepasste Version und genehmigte Ausgabe des Wartungs- und Kbasierend auf den Empfehlungen der Standards ISO 14764, ISO 10007, ISO 15846.
6. Eine Reihe von Stellenbeschreibungen, die die Verantwortung, Befugnisse und Verfahren für die Interaktion aller Führungskräfte definieren, die die Arbeit des Personals ausführen und überprüfen, das an den Verfahren des Unternehmensqualitätssystems für ein bestimmtes PS-Projekt beteiligt ist.

Quelldokumente, die die Merkmale des Lebenszyklus eines bestimmten Softwaretools widerspiegeln

1. Beschreibung der Merkmale der im Unternehmen erstellten Softwareprodukte, des Systems und der externen Umgebung ihres Lebenszyklus, die für die Anpassung und Erstellung von Arbeitsversionen der Standards und Anforderungen des PS-Projekts und des Unternehmensqualitätssystems gemäß dem erforderlich sind Empfehlungen der Normen ISO 12207, ISO 15504, ISO 90003 und ISO 9126.
2. Beschreibung der Ziele, Anforderungen und Pflichten des Unternehmensentwicklers im Bereich des Qualitätssystems, Qualitätskriterien für die Prozesse und Produkte der Entwicklung, Lieferung und Betreuung des gesamten Lebenszyklus der Software.
3. Eine Reihe von Betriebsdokumenten, die dem Kunden und den Benutzern zur Verfügung gestellt werden, um den Lebenszyklus und die Verwendung einer bestimmten Version des Softwareprodukts auf der Grundlage angepasster Standards sicherzustellen ISO 9294, ISO 15910, ISO 18019.
4. Dokumentations- und Automatisierungswerkzeuge für Design, Entwicklung, Modifikation, Kontrolle und Test, die verwendet werden, um den Lebenszyklus eines Softwareprodukts sicherzustellen.
5. Pläne und Methoden zum Testen der Anwendung und zum Bewerten der Wirksamkeit der Prozesse des Qualitätssystems des Unternehmens und des Softwareprodukts.
6. Wartungsmethoden, Identifizierung von Softwareproduktkomponenten und Dokumentation, Analyse und Freigabe von Versionen von Software und Datenkomplexen.
7. Die Methodik für das Konfigurationsmanagement, die Genehmigung, die Speicherung, den Schutz, das Kopieren von Softwareproduktversionen und begleitenden Dokumenten sowie das Sammeln und Speichern von Daten zu Qualitätsmerkmalen, die während des Lebenszyklus von Softwareproduktversionen im Unternehmensarchiv registriert sind.

Die resultierenden Testdokumente - Zertifizierung des Qualitätssystems des Unternehmens und / oder des Softwareprodukts

1. Ein Bericht über die Verfügbarkeit, Relevanz und systematische Ausführung der Dokumentation, angepasst an die Anforderungen und Bestimmungen des Unternehmensqualitätssystems, das einen integrierten Qualitätssicherungsprozess über den gesamten Lebenszyklus des Softwareprodukts bietet.
2. Die Ergebnisse der Überwachung und Prüfung des Zustands und der Anwendung des Qualitätssicherungssystems, die regelmäßig durchgeführt werden, um seine Eignung und Wirksamkeit festzustellen.
3. Bericht über die Verfügbarkeit und Aufrechterhaltung von Methoden zur Durchführung von Inspektionen und dokumentierte Berichte über die Ergebnisse der erreichten Qualität zur Erfüllung der Anforderungen der Zertifizierungsvereinbarung mit dem Kunden.
4. Die Ergebnisse der Registrierung der erreichten Qualitätsmerkmale des Softwarepakets: Identifizierung, Sammlung, Speicherung der registrierten Daten über die Merkmale und Attribute der Qualität des Softwareprodukts und seiner Komponenten.
5. Die Ergebnisse der Umsetzung des Entwicklungsplans, dokumentierte Ein- und Ausgangsdaten der Entwicklungsstufen und Protokolle zur Überprüfung der Umsetzung des Lebenszyklus des PS.
6. Die Ergebnisse der praktischen Umsetzung des Qualitätsprogramms und der Umsetzung geregelter Aktivitäten im Bereich Qualität in allen Phasen des Lebenszyklus des PS.
7. Die Ergebnisse der Zertifizierung von Umgebungssimulatoren und Testgeneratoren sowie eine Bewertung ihrer Eignung zur Durchführung von Zertifizierungstests eines Softwareprodukts.
8. Die Ergebnisse der Analyse der Umsetzung von Plänen und Prüfmethoden, Prüfberichte, Bewertungen der Übereinstimmung der Prüfergebnisse mit den Anforderungen sowie die von Vertretern des Antragstellers, Kunden und Lieferanten genehmigten Prüfergebnisse.
9. Der Akt der Ergebnisse der Überprüfung der tatsächlichen Merkmale des Lebenszyklus des Softwaresystems und des Qualitätssystems des Unternehmens, Schlussfolgerungen über ihre Übereinstimmung mit den Anforderungen für die Zertifizierung der Produktion eines Softwareprodukts.
10. Zertifikat des Qualitätssystems des Unternehmens und / oder Softwareprodukts und Sicherstellung seines Lebenszyklus, Lizenz zur Verwendung von Konformitätszeichen.

Literatur

VV Lipaev -- Softwarelebenszyklus-Standardprofile. -- Jet-Info, Newsletter, N 12, 2005

K. Milman, S. Milman -- SMMI ist ein Schritt in die Zukunft. -- offene Systeme., N. 5-6. (2005), N. 2. (2006), 2005, 2006

Bewertung und Zertifizierung der Reife der Prozesse zur Erstellung und Wartung von Softwaretools und Informationssystemen ISO IEC TR 15504-CMMI. Pro. aus dem Englischen -- M.: Buch und Geschäft, 2001

VV Lipaev -- Prozesse und Standards des Lebenszyklus komplexer Software. Verzeichnis.-- M.: SINTEG, 2006

VV Lipaev -- Methoden zur Sicherstellung der Qualität umfangreicher Software.-- M.: RFBR. SINTEG, 2003

"; antisource: "Softwareprodukte werden heute zur Lösung von Managementproblemen in fast allen Bereichen menschlicher Tätigkeit eingesetzt: in der Wirtschaft, im Sozialwesen, im Militär und in anderen Bereichen. Die Sicherstellung der hohen Qualität einheimischer Softwareprodukte während ihrer Massenentwicklung und Lieferung für verschiedene Anwendungen im Land und auf dem Weltmarkt ist zu einer strategischen Aufgabe geworden."; Bedingung: 1]$

Anmerkung: Der Ideenkreis der wohl bekanntesten Methodik zur Verbesserung von Entwicklungsprozessen wird eingehend untersucht. Software- SMM. Die Logik und Struktur des HMM wird analysiert. Der Zusammenhang zwischen dem HMM und den zuvor untersuchten Prozessmodellen wird aufgezeigt.

Ein wunderbares praktisches Tool, das im Rahmen von erstellt wurde Prozessansatz zur Tätigkeitsbeschreibung Organisation entwerfen insbesondere die Organisation, die sich entwickelt Informationssysteme , demonstriert die HMM-Methodik. CMM steht für Capability Maturity Model, was so viel wie „Managementsystem-Reifegradmodell“ bedeutet. In der Literatur wird CMM häufiger als Organisationsreifemodell bezeichnet, und ich werde dieser Tradition folgen.

Die Geschichte der Entstehung von SMM ist wie folgt. Ende der 80er. Im vergangenen Jahrhundert bestellte das US-Verteidigungsministerium das Institute of Software Engineering 1Eng. SEI - Institut für Softwaretechnik Die Carnegie Mellon University arbeitet an einem Kriteriensystem für die Auswahl von Subunternehmern in Softwareentwicklungsprojekten. Die Arbeiten wurden 1991 abgeschlossen und das Ergebnis war das CMM. Wir müssen sofort einen Vorbehalt machen, dass das Modell keine finanziellen, wirtschaftlichen, politischen, organisatorischen enthält Auswahlkriterium Subunternehmer sowie die Kriterien für die Möglichkeit der Zulassung zu geheimen Arbeiten (wahrscheinlich wurden solche Aufgaben nicht festgelegt). Wir sprechen nur von Kriterien, die die Fähigkeit eines potenziellen Subunternehmers in Bezug auf die Entwicklung von Softwaresystemen beschreiben.

CMM-Struktur

Die Ersteller des Modells nahmen die Prozesse der Organisation als Grundlage für die Bewertung der Fähigkeit einer Organisation, Qualitätsarbeit zu leisten, was (Fähigkeit) als Reife bezeichnet wurde. Dann machten sie einige nicht triviale Annahmen, die anschließend von vielen IT-Experten (und vielleicht den meisten von ihnen) akzeptiert und als fair anerkannt wurden.

Annahme 1. Es gibt qualitativ unterschiedliche Reifegrade Organisation entwerfen Entwicklung Informationssysteme(es gibt fünf solcher Ebenen im HMM-Modell).

Annahme 2. Jede Entwicklungsorganisation ist daran interessiert, einen höheren Reifegrad zu erreichen (nicht nur, um ihre Chancen im Kampf um Aufträge des Verteidigungsministeriums zu erhöhen, sondern auch, um sich selbst zu verbessern).

Annahme 3. Der Übergang ist nur zur nächsthöheren Ebene möglich. Es ist unmöglich, die Ebene zu „überspringen“ (genauer gesagt, gleichzeitig steigen die Risiken für die Organisation stark an).

Somit bilden die Ebenen eine „Leiter“, entlang derer die Organisation aufsteigt eigene Entwicklung. Jede Ebene ist durch eine bestimmte Zusammensetzung und Eigenschaften der Prozesse der Organisation gekennzeichnet. Die SMM „Level Ladder“ ist weithin akzeptiert und verbreitet worden. So sieht sie aus.

Stufe 1 „Anfänger“. Der gesamte Produktionsprozess wird dadurch charakterisiert, dass er jedes Mal für ein bestimmtes Projekt erstellt wird, manchmal sogar als chaotisch. Nur wenige Prozesse sind definiert, und der Erfolg des Projekts hängt vom Einsatz Einzelner ab.

Stufe 2 „Wiederholbar“. Die wichtigsten Projektmanagementprozesse wurden eingerichtet, mit denen Sie die Kosten verfolgen, den Arbeitsplan und die Funktionalität der erstellten Softwarelösung überwachen können. Etablierte die Prozessdisziplin, die erforderlich ist, um frühere Erfolge in ähnlichen Anwendungsentwicklungsprojekten zu replizieren.

Stufe 3 „Eindeutig“. Bei beiden ist der Produktionsprozess dokumentiert und standardisiert Führungsarbeit sowie für die Gestaltung. Dieser Prozess ist in den Standardherstellungsprozess der Organisation integriert. Alle Projekte verwenden eine genehmigte angepasste Version des Standardbetriebsprozesses der Organisation.

Stufe 4 „Verwaltet“. Es werden detaillierte quantitative Indikatoren des Produktionsprozesses und der Qualität des entstehenden Produkts erhoben. Sowohl der Herstellungsprozess als auch die Produkte werden quantitativ bewertet und kontrolliert.

Stufe 5 „Optimieren“. Kontinuierliche Prozessverbesserung wird durch quantitative erreicht Rückmeldung mit dem Prozess und der Umsetzung fortschrittlicher Ideen und Technologien darin.

Trotz des Mangels an Strenge erhebt die obige Definition intuitiv meistens keine Einwände. Darüber hinaus verstehen erfahrene Spezialisten, warum Übergänge nur auf die nächste Ebene möglich sind und warum es sich überhaupt lohnt, einen solchen Übergang anzustreben. Gleichzeitig enthält das HMM-Modell keine quantitative oder auch nur formale Begründung eines solchen Ansatzes, was jedoch seine Vorzüge nicht schmälert.

Weiter, wie sie sagen, ist eine Frage der Technologie. Die Struktur des Modells wird definiert (Abbildung 7.1), es werden Definitionen gegeben, und es beginnt eine sorgfältige Arbeit, um jeden Prozess auf jeder Ebene genau zu beschreiben. Um den praktischen Wert dessen zu beurteilen, was getan wurde, gehen wir einen Teil dieses Weges durch.

Reis. 7.1.

Auf Abb. 7.1 enthält die folgenden Konzepte.

Schlüsselprozessgruppe. Wie in (Paulk, et al., 1995) festgestellt wird, „definiert jede Gruppe von Schlüsselprozessen einen Block zusammenhängender Aktivitäten, durch die eine Reihe von Zielen erreicht wird, die für die Steigerung der Produktivität des Produktionsprozesses von Bedeutung sind Beispiel für eine Gruppe von Schlüsselprozessen " Anforderungsmanagement"(Siehe Abbildung 7.2) Ziel ist es, die Anforderungen des Softwareentwicklungsprojekts zwischen dem Kunden und dem Entwickler in Einklang zu bringen."

Es gibt keine einzelnen Prozesse im CMM. Stattdessen gibt es einzelne Werke, Key Practices genannt (su), durch Inputs und Outputs miteinander verbunden sind und als Ausgangsmaterial für Bauprozesse dienen. Das CMM gibt keine Anleitung, wie Prozesse strukturiert sein sollten, d. h. die Verknüpfung von Schlüsselpraktiken in logische Sequenzen. Sätze von Schlüsselpraktiken werden als Schlüsselprozessgruppen bezeichnet.

Reis. 7.2.

Gruppen von Schlüsselprozessen im CMM werden Reifegraden zugeordnet (Abbildung 7.2), d. h. alle Praktiken auf einer Ebene interagieren nur miteinander und nicht mit Praktiken auf anderen Ebenen. Dadurch können Sie die volle Leistungsfähigkeit aller Prozesse auf einer bestimmten Ebene garantieren und somit die Ebene mit dem abgeschlossenen Stadium der Organisationsentwicklung korrelieren.

Das Adjektiv „Schlüssel“ impliziert, dass es sie gibt Prozessgruppen(d. h. Gruppen von Praktiken), die im Hinblick auf einen bestimmten Reifegrad nicht entscheidend sind, d. h. nicht mit der Erreichung der Ziele dieses Niveaus in Verbindung stehen (siehe unten). Das HMM-Modell beschreibt nicht alles Prozessgruppen in Bezug auf die Entwicklung und Wartung von Software . Es beschreibt nur diejenigen Gruppen, die als Schlüsselfaktoren für die Produktivität des Produktionsprozesses identifiziert wurden.

Ziele. Ziele in CMM sind nicht mit Prozessen verbunden, sondern mit Gruppen von Schlüsselprozessen. Wie oben erwähnt, werden die Ziele durch die Implementierung von Schlüsselpraktiken erreicht. Zielerreichung bedeutet im CMM, dass erstens nach der Implementierung von Schlüsselpraktiken das gewünschte Ergebnis erzielt wird und zweitens es ziemlich konstant erreicht wird. Die Art und Weise, wie die Ziele der Key Process Group erreicht werden, kann sich von Projekt zu Projekt aufgrund von Unterschieden unterscheiden Fachbereich oder Umwelt.

Werden diese Ziele für alle Projekte verwirklicht, bedeutet dies, dass die Organisation den Reifegrad des Produktionsprozesses erreicht hat, der mit dieser Gruppe von Schlüsselprozessen korreliert.

Kapitel. Abschnitte (es gibt fünf davon auf jeder Ebene und sie sind immer gleich) stellen die Eigenschaften von Gruppen von Schlüsselprozessen dar, die auf der entsprechenden Ebene implementiert werden müssen. Diese Eigenschaften beschreiben, wie die Prozesse implementiert und inwieweit sie in der Organisation legalisiert, d. h. offiziell genehmigt und mit Unternehmensabläufen, Richtlinien und anderen Prozessen abgestimmt sind. Hier sind die fünf Abschnitte.

Leistungsverpflichtungen

Beschreiben Sie die Maßnahmen, die die Organisation ergreifen muss, um sicherzustellen, dass der Prozess etabliert und stabil ist. Leistungsverpflichtungen beziehen sich in der Regel auf die Einführung von Unternehmensrichtlinien und die Unterstützung durch das Top-Management.

Voraussetzungen

Beschreiben Sie die Voraussetzungen, die in einem Projekt oder einer Organisation für die kompetente Durchführung eines Herstellungsprozesses erfüllt sein müssen; beziehen sich in der Regel auf Ressourcen, Organisationsstrukturen und erforderliche Schulungen.

Operationen im Gange

Der Abschnitt "Operations in Progress" beschreibt die wesentlichen Arbeiten, die auf dieser Ebene durchgeführt werden müssen. Zu den durchgeführten Vorgängen gehören in der Regel das Erstellen von Plänen und das Implementieren bestimmter Vorgänge, das Ausführen und Verfolgen von Arbeiten sowie das Ergreifen von Korrekturmaßnahmen nach Bedarf.

Messungen und Analysen

Abschnitt "Messungen und

"Jede Gruppe von Schlüsselprozessen wird durch Schlüsselpraktiken ausgedrückt, deren Umsetzung zum Erreichen der Ziele der Gruppe beiträgt. Schlüsselpraktiken beschreiben die Infrastruktur und den Betrieb, die am meisten zur effektiven Umsetzung und Etablierung einer Gruppe von Schlüsselprozessen beitragen.

Jede Schlüsselpraxis besteht aus einem einzigen Satz, dem häufig eine ausführlichere Beschreibung folgt, die Beispiele und Erläuterungen enthalten kann. Schlüsselpraktiken, die manchmal als Schlüsselpraktiken der obersten Ebene bezeichnet werden, legen die grundlegenden Richtlinien, Verfahren und Operationen für eine Gruppe von Schlüsselprozessen fest. Ausführliche Beschreibungskomponenten werden oft als Unterpraktiken bezeichnet."

Schlüsselpraktiken beschreiben, WAS getan werden muss, aber sie sollten nicht als Dogma darüber verstanden werden, WIE Ziele erreicht werden sollten. Die Ziele der Schlüsselprozessgruppe können durch alternative Praktiken erreicht werden. Die Interpretation von Schlüsselpraktiken sollte angemessen sein und das Erreichen der Ziele der Gruppe von Schlüsselprozessen ermöglichen effektiver Weg, wenn auch vielleicht formal und anders als das empfohlene CMM.

Etwas exotisch wirkt auf den ersten Blick ein Blick auf IT-Management-Tätigkeiten, bei denen statt Prozessen deren Bestandteile betrachtet werden – Key Practices, und Prozesse nur virtuell vorhanden sind, als etwas, was aus Key Practices aufgebaut werden kann. Bisher wurde die Aufgabe zur Verbesserung des IT-Managements durch die Einführung vorgefertigter Prozesse aus dem Referenzprozessmodell gelöst. Jetzt gibt es eine Reihe von Ebenen, die unterschiedliche (d. h. nicht in Prozesse integrierte) Schlüsselpraktiken enthalten, und eine empfohlene Reihenfolge, um sich durch die Ebenen zu bewegen. Laut CMM verbessert sich das IT-Management, wenn es einen höheren Reifegrad erreicht. Was passiert mit dieser Aktion?

In den Ebenendefinitionen (siehe Abbildung 7.2) taucht so etwas wie ein „Produktionsprozess“ auf. Es ist auch in der Definition einer Gruppe von Schlüsselprozessen vorhanden, und das ist kein Zufall. Der Herstellungsprozess, oder wie er in CMM treffend genannt wird, der Standard Herstellungsverfahren Organisationen (OSS) ist einer der zentralen Begriffe des gesamten Modells.

Im November 1986 begann das American Software Engineering Institute (SEI) in Zusammenarbeit mit der Mitre Corporation mit der Entwicklung einer Softwareentwicklungsprozess-Reifeprüfung, die zur Verbesserung ihrer internen Prozesse beitragen sollte.

Die Entwicklung dieser Überprüfung wurde durch eine Anfrage der US-Bundesregierung nach einer Methode zur Bewertung von Subunternehmern für die Softwareentwicklung veranlasst. Das eigentliche Problem war die Unfähigkeit zu verwalten große Projekte. In vielen Unternehmen wurden Projekte deutlich verspätet und über dem Budget abgeschlossen. Für dieses Problem musste eine Lösung gefunden werden.

Im September 1987 wurde SEI veröffentlicht Kurze Review Softwareentwicklungsprozesse mit einer Beschreibung ihres Reifegrades sowie einen Fragebogen, um Bereiche im Unternehmen zu identifizieren, in denen Verbesserungsbedarf besteht. Die meisten Unternehmen betrachteten diesen Fragebogen jedoch als fertiges Modell, weshalb der Fragebogen nach 4 Jahren in ein reales Modell, das Capability Maturity Model for Software (CMM), umgewandelt wurde. Die erste Version des CMM (Version 1.0), die 1991 veröffentlicht wurde, wurde 1992 von den Teilnehmern des Arbeitstreffens, an dem etwa 200 Softwarespezialisten und Mitglieder der Entwicklergemeinschaft teilnahmen, überarbeitet.

1. Elementar. Der primitivste Status der Organisation. Die Organisation ist in der Lage, Software zu entwickeln. Die Organisation hat keinen explizit bewussten Prozess, und die Qualität des Produkts wird vollständig von den individuellen Fähigkeiten der Entwickler bestimmt. Einer ergreift die Initiative und das Team folgt seinen Anweisungen. Der Erfolg eines Projekts garantiert nicht den Erfolg eines anderen. Am Ende des Projekts werden Daten zu Arbeitskosten, Zeitplan und Qualität nicht erfasst.
2. wiederholbar. Teilweise wird der Prozess überwacht. Aufzeichnungen über Arbeitskosten und Pläne werden erstellt. Die Funktionalität jedes Projekts wird schriftlich beschrieben. Mitte 1999 waren nur 20 % der Organisationen Level 2 oder höher.
3. Eingerichtet. Haben Sie eine definierte, dokumentierte und etablierter Prozess personenunabhängig arbeiten. Das heißt, vereinbart professionelle Maßstäbe, und die Entwickler implementieren sie. Solche Organisationen sind in der Lage, die Kosten von Projekten, die den früher abgeschlossenen ähneln, ziemlich zuverlässig vorherzusagen.
4. Gelang es. Sie können den Zeitplan und die Kosten der Arbeit genau vorhersagen. Es gibt eine Datenbank mit gesammelten Messungen. Aber es gibt keine Änderungen mit dem Aufkommen neuer Technologien und Paradigmen.
5. Optimiert. Es gibt ein kontinuierliches Verfahren, um neue und verbesserte Methoden und Werkzeuge zu finden und zu beherrschen.

Entwicklung

Die Anwendung des Modells in der Praxis offenbarte die Mehrdeutigkeit der Ansätze zum Erreichen höherer Organisationsebenen von Softwareentwicklungsprozessen. Daher werden bis 2002 Empfehlungen zur Verbesserung des Entwicklungsprozesses entwickelt, die als CMMI (Integration von Fähigkeitsreifemodellen). Zur Zeit letzte Version CMMi - 1.3 (veröffentlicht im November 2010) .

siehe auch

Verknüpfungen

MIT Student Forum > Hauptbereich > Tests > Simulation von Steuerungssystemen

Aussicht Vollversion: Simulation von Steuerungssystemen

Ich habe alle Module gelöst, alles mit 4 bestanden und das letzte mit 2, jetzt versuche ich es in drei Tagen noch einmal zu bestehen, es gab keine einzige identische Frage. Ich habe versucht, den Abschlusstest zu korrigieren, aber überprüfen Sie, ich kann nicht für die Richtigkeit bürgen. Ich stelle alles offen, was ich habe, vielleicht besteht jemand es besser als ich. Wenn jemand einen zweiten, dritten Versuch hat, ertrage, wenn es dir nichts ausmacht, Disziplin, wirklich sehr schwierig. :eek:

Abschlusstest 100 von 100

Ist das Ergebnis jedes Mal anders?

Weitere Fragen, die hier nicht aufgeführt sind und mich erwischt haben. Ich habe nicht nach Antworten gesucht, denn ohne sie habe ich 4 bestanden. Wer verwirrt sein will, lädt die Antworten hier für den Rest hoch 🙂

Modul 1:
Was sollte nicht als Kennzeichen eines Geschäftsprozesses angesehen werden?

Mehrwert

Wähle eine Antwort:
Ein Produkt eines Prozesses, das zuvor festgelegte Ziele verkörpert

Wähle eine Antwort:

Im Finale (bestanden am 4.

Was ist das Reifegradmodell der Fähigkeit? (CMM)

Diese Fragen + die bereits im Forum):
1. Kreuze die richtige Aussage an.
Wähle eine Antwort:
Der Geschäftsprozess der Divisionen besteht aus verschiedenen Wertschöpfungsketten (UNSURE)
Ein End-to-End-Geschäftsprozess besteht aus Geschäftsprozessen verschiedene Organisationen
Funktionsübergreifende Geschäftsprozesse bestehen in der Regel aus Geschäftsprozessen von Abteilungen

2. Was ist kein Element des universellen Geschäftsprozessflussdiagramms?
Wählen Sie eine oder mehrere Antworten aus:
Ressourcen verarbeiten
Risiken
Geschäftsprozessmanagement-Aktivitäten
Umweltfaktoren
Aktivität zum Konvertieren von Eingaben in Ausgaben

3. Materielle Ressourcen als Grundelement von Prozessen sind:
Wähle eine Antwort:
Aktive Tätigkeitssubjekte, die in Systemen vereint sind, die miteinander und mit anderen Ressourcen interagieren
Von den Tätigkeitsgegenständen auf die Tätigkeitsgegenstände gerichtete Kontrollhandlungen, die die Ziele und Ergebnisse der Prozesse bestimmen
Passive Einrichtungen und Aktivitäten zur Durchführung von Prozessen (NICHT SICHER)

28.03.2014, 10:07

Modul 1:
Was sollte nicht als Kennzeichen eines Geschäftsprozesses angesehen werden? Wählen Sie eine oder mehrere Antworten aus:
Umwandlung von Eingängen in Ausgänge
Lieferung des Produkts an einen externen Verbraucher
Mehrwert
Mehr- und/oder Gebrauchswertbildung

Ergebnisse als Grundelemente von Prozessen sind:
Wähle eine Antwort:
Aktive Tätigkeitssubjekte, die in Systemen vereint sind, die miteinander und mit anderen Ressourcen interagieren
Ein Produkt eines Prozesses, das zuvor festgelegte Ziele verkörpert. Passive Einrichtungen und Aktivitäten, die zur Durchführung der Prozesse verwendet werden
Die Menge an materiellen, Energie- und Informationsobjekten, die zum Abschluss des Prozesses erforderlich sind

Was ist Feedback innerhalb eines Geschäftsprozesses?
Wähle eine Antwort:
Gezielte und bewusste Einflussnahme auf den Prozess, um das gewünschte Ergebnis sicherzustellen
Analyse und Vergleich der Ergebnisse des Prozesses mit zuvor festgelegten Zielen
Einfluss auf das System von Objekten und Umweltfaktoren, die Quellen verschiedener Arten von Abweichungen in der Funktionsweise des Systems sind
Ich habe so geantwortet! aber es kam immer noch 4 heraus

Im Finale - Diese Fragen + die bereits bestehenden:
1 Wählen Sie die Mängel der Entwurfszielstrukturen aus der Liste aus.

2 Wählen Sie Beispiele für die Verwendung von Befehlen aus der Liste aus.
Hochwertige Tassen
Ausschüsse
Arbeitsteams

3 Wählen Sie aus der Liste die Bedingungen für die Anwendung organischer Organisationsstrukturen aus.
Arbeitnehmer werden durch komplexe Bedürfnisse motiviert
Ziele sind verschwommen und verändern sich dynamisch
Macht wird hinterfragt und getestet, bedarf der Bestätigung durch Untergebene

4 Wählen Sie aus der Liste die Vorteile projektbasierter Organisationsstrukturen aus.
direkte Unterordnung der Mitarbeiter unter den Projektleiter und damit die Eindeutigkeit der Richtung der Bemühungen dieser Mitarbeiter erreicht wird

5 Unterstützende Prozesse:
Zur Verfügung stellen Wirksame Umsetzung Hauptprozesse

Abschlussnote 5
Frage 1
Wählen Sie aus der Liste der Verwendungsbeispiele für Befehle.

Hochwertige Tassen
Ausschüsse
Arbeitsteams

Frage 2
Wofür werden Intermediäre innerhalb der funktionalen Struktur eingesetzt?

Integration der Aktivitäten verschiedener Strukturbereiche

Frage 3
Nennen Sie die Arten von Beziehungen im SADT-Modell:
Kontrolle
Exit-Mechanismus
Eingabe-Feedback

Frage 4
Welcher der folgenden Geschäftsprozesse ist der kürzeste?
Geschäftsprozess der Division

Frage 5
Welche Methoden, Methodologien und Tools können verwendet werden, um Geschäftsprozessinformationsmodelle zu erstellen?

Gein-Sarson-Methodik
Chen und Barkers Modellierungssprache

Frage 6
Welche Geschäftsprozessdarstellung entspricht der untersten Ebene (der aufgeführten)?

Betrieb von Geschäftsprozessen

Frage 7
Geschäftsprozesslänge:

Es ist subjektiv

Frage 8
Materielle Ressourcen als Grundelement von Prozessen sind:

Passive Mittel und Gegenstände der Tätigkeit zur Durchführung von Prozessen

Frage 9
Wählen Sie aus der Liste die Vorteile projektbasierter Organisationsstrukturen aus.

Die direkte Unterordnung von Mitarbeitern unter den Projektleiter wird umgesetzt und damit die Eindeutigkeit der Richtung der Bemühungen dieser Mitarbeiter erreicht

Frage 10
Wählen Sie aus der Liste die Vorteile von Matrix-Organisationsstrukturen aus.

Möglichkeit zur flexiblen Anpassung organisatorische Struktur innerhalb eines weiten Spektrums: von schwacher bis starker Matrix

Frage 11
Was beinhaltet die zweite Schleife des Geschäftssystemmanagements?

Betriebssteuerungs-Subsystem
Entwicklungsmanagement-Subsystem

Frage 12
Das allgemeine Prozessmodell eines Geschäftssystems umfasst die folgenden Elemente:

Ausgang
Prozess
Eingang
Störung

Frage 13
Mit welchem ​​IDEF-Standard können Sie Aktivitäten, Abläufe und den Zustand von Objekten modellieren?

Frage 14
Welche Befugnisse hat der Projektmanager in einer starken Matrixstruktur?

Mittel bis hoch

Frage 15
Was lässt sich den Hauptelementen von Anlage- und Finanzprozessen zuordnen?

Investoren
Kreditgeber

Frage 16
Wählen Sie aus der Liste die Mängel der Design-Soll-Strukturen aus.

Reduzierte Herstellbarkeit in Funktionsbereichen

Control Systems Modeling.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

Wie ist die Dominanzordnung in SADT-Diagrammen?
Antwort: Die dominantesten Funktionen befinden sich in der oberen linken Ecke.

help 3training wer hat es pliz

Nach 1 Minute hinzugefügt
Ich bitte um 3 Schulungen von jedem, der Modellierung von Steuerungssystemen hat

vBulletin® v3.8.7, Copyright 2000-2018, vBulletin Solutions, Inc.

Übersetzung, die Sie sagen können:

Methodik für die Entwicklung von IS. CMM/CMMI-Reifegradmodell.

1991 wurde das Institut für Softwaretechnik der Universität

Carnegie Mellon (Software Engineering Institute, SEI) hat das CMM-Reifegradmodell (Capability Maturity Model) für die Entwicklung von Softwareprodukten erstellt. Im Laufe der Zeit wurde eine ganze Familie von Modellen veröffentlicht:

SW-CMM – für Softwareprodukte, SE-CMM – für Systems Engineering, Acquisition CMM – für die Beschaffung, People CMM – für das Personalmanagement, ICMM – für die Produktintegration.

Eine Vielzahl von Modellen erwies sich als ziemlich schwierig zu verstehen und umzusetzen. Seit ihrer Entstehung verschiedene Gruppen Spezialisten, der Inhalt dieser Modelle war nicht immer konsistent miteinander, sowie mit

Anforderungen internationaler Normen. Daher hat SEI im Jahr 2002 ein neues CMMI-Modell (Capability Maturity Model Integration) veröffentlicht, das zuvor veröffentlichte Modelle kombiniert und die Anforderungen berücksichtigt

internationale Standards. CMMI ist eine Reihe von Modellen (Methodologien) zur Verbesserung von Prozessen in Organisationen verschiedener Größen und Aktivitäten. Das CMMI unterscheidet folgende Gruppen von Verbesserungsbereichen: Prozessmanagement, Projektmanagement, Engineeringbereiche, Service

Bereiche. Dabei werden alle Bereiche in Form von Anforderungen spezifiziert, die nicht deren Umsetzung bestimmen, sondern Schnittstellenanforderungen. Daraus ergeben sich zwei Konsequenzen.

Konsequenz 1. CMMI erlaubt verschiedene Implementierungen und ist keine Softwareentwicklungsmethodik wie MSF, Scrum, RUP usw. Letzteres kann bei seiner Implementierung verwendet werden. Beispielsweise gibt es in VSTS für CMMI eine spezielle Prozessvorlage namens MSF für CMMI.

Folgerung 2. CMMI wird verwendet, um Unternehmen für die Reife ihrer Prozesse zu zertifizieren. Ursprünglich, Ende der 80er und Anfang der 90er Jahre, wurde CMM (damals noch nicht CMMI) genau als Zertifizierungsmittel geschaffen

Subunternehmer des Bundes. Und erst später, nachdem es sich weltweit verbreitet hatte, wurde es eingesetzt und konzentrierte sich dann auf die Verbesserung von Prozessen. Wir bemerken noch eine wichtige Eigenschaft CMMI. Es ist nicht nur für die Entwicklung von Softwaresystemen gedacht. Viele Großunternehmen Sie produzieren keine Software, sondern Zielprodukte, bei denen Software ein integraler Bestandteil ist.

Zum Beispiel Luft- und Raumfahrtindustrie. Nämlich Softwareentwicklung

tritt zusammen mit Ingenieurarbeiten anderer Art auf. Und es kommt oft vor, dass mehr als zwei verschiedene Arten von Engineering an einem Projekt beteiligt sind. Aufgabe von CMMI ist es, solchen Projekten und Unternehmen eine einheitliche Plattform zur Organisation des Entwicklungsprozesses zur Verfügung zu stellen.

Im Gegensatz zum klassischen CMM-Modell, das streng hierarchisch war und nur eine sequentielle Verbesserung von Prozessen nach Ebenen erlaubte, hat das CMMI-Modell zwei Dimensionen – sequentielle, z

wie im CMM und kontinuierlich, was die Verbesserung von Prozessen in der Organisation bis zu einem gewissen Grad auf willkürliche Weise ermöglicht. Hier konzentrieren wir uns auf sequentielles Modell. Es hat 5 Ebenen

Prozessreife (Abb. 1).

Erste Ebene(Reifegrad 1) ist das Niveau, auf dem sich per Definition jedes Unternehmen befindet. Auf dieser Ebene ist die Softwareentwicklung mehr oder weniger chaotisch.

Verwaltete Ebene(Reifegrad 2) - Richtlinien und Verfahren zur Organisation von Prozessen, die auf Unternehmensebene genehmigt wurden, erscheinen hier bereits. Der volle Umfang der Prozesse existiert jedoch nur im Rahmen von Einzelprojekten.

Ein gewisses Niveau(Reifegrad 3) - hier tritt ein Standardprozess auf Ebene des Gesamtunternehmens auf.

Was ist das Capability Maturity Model (CMM)? Was sind CMM-Stufen?

Dies ist eine große und ständig wachsende Menge von Prozess-Assets: Dokumentvorlagen,

Lebenszyklusmodelle, Softwaretools, Praktiken usw. Jeder spezifische Prozess wird durch Abschneiden von dieser Norm erhalten.

Quantitative Ebene(Reifegrad 4) impliziert die Entstehung eines Systems von Messgrößen im Unternehmen, die auf Basis eines Standardprozesses erfolgen und eine quantitative Steuerung der Entwicklung ermöglichen.

Optimierungsebene(Reifegrad 5) bedeutet kontinuierliche Verbesserung von Entwicklungsprozessen, sowohl inkrementell, inkrementell als auch revolutionär. Gleichzeitig sind diese Änderungen keine erzwungenen, sondern proaktive Probleme und Schwierigkeiten. Der Prozess wird von selbst verbessert und es wurden laufend entsprechende Mechanismen implementiert.

Viele kennen die Abkürzung CMMI, viele wissen, dass es sich hier um ein Modell handelt, d.h. eine Reihe von Empfehlungen zur Verbesserung von Prozessen, beispielsweise im Zusammenhang mit der Softwareentwicklung. Aber nur wenige wissen, dass es mehrere CMMI-Modelle gibt. Das bekannteste davon ist CMMI for Development (CMMI-DEV), das in vielerlei Hinsicht wirklich mit den Aktivitäten von Entwicklungsunternehmen verbunden ist (d. h. jenen Unternehmen und Organisationen, die ein bestimmtes Softwareprodukt oder andere komplexe Software und Hardware entwickeln und liefern Lösung).

Aber was ist mit denen, die kein Produkt, sondern Dienstleistungen liefern (z. B. Produktunterstützung mit einem unbedeutenden Anteil der Entwicklung an den gesamten Arbeitskosten oder gar keinen Arbeitskosten)? Auch für sie gibt es eine Reihe von Empfehlungen – das CMMI for Services-Modell (CMMI-SVC). Für IT-Abteilungen kann dieses Modell (genauer gesagt seine Empfehlungen) beispielsweise helfen zu verstehen, was getan werden muss, damit beispielsweise dieselben ITIL-Empfehlungen zu einem normalen Prozess werden und nicht zu einer Art „heiliger Praxis“.

Fähigkeitsreifegradmodell (CMM)

Es ist merkwürdig, dass die Empfehlungen dieses Modells ziemlich universell sind und nicht nur auf "schließen". Informationstechnologie. Die Piloteinführung der Praktiken dieses Modells erfolgte ... in einem der Krankenhäuser in den Vereinigten Staaten (schließlich ist medizinische Versorgung auch eine Dienstleistung).

Allerdings ist jedes der aufgeführten Modelle besser zu erlernen. Und wenn es für die gesamte GUS mehrere hundert Personen gibt, die im CMMI-DEV-Modell geschult sind (etwa 250-300 Personen), dann gibt es in der GUS nur 6 Personen, die im CMMI-SVC-Modell geschult sind. Wir sprechen von den Ausgebildeten, nicht von den Ausbildern. Genau das war bis Dezember 2011 das Hauptproblem: Für CMMI-DEV gab es auf der ganzen Welt nur einen vom SEI (CMMI-Modellentwickler) zertifizierten russischsprachigen Ausbilder, und für andere Modelle überhaupt keinen! Nun ist auch ein solcher Ausbilder nach dem CMMI-SVC-Modell erschienen (daher die ersten 6 ausgebildeten). Dieser Ausbilder ist der Autor dieser Publikation, der für Fragen zu den genannten Modellen und zur formalen Ausbildung gerne zur Verfügung steht. Fragen!

Dieses Material ist eine private Aufzeichnung eines Mitglieds der Club.CNews-Community.
Die Herausgeber von CNews sind nicht für deren Inhalt verantwortlich.

Wir betrachten die Evolution von Qualitätssicherungsmodellen auf der Grundlage des „Prozessreifemodells“ oder „Kapazitätsverbesserungsmodells“. CMM (Capability Maturity Model). Obwohl das Modell SMM zielt darauf ab, die Qualität von Software sicherzustellen, ihre methodischen Aspekte sind auf Modelle zur Sicherung der Qualität von Produkten (Waren, Arbeiten, Dienstleistungen) anwendbar.

Hauptsächlich im Modell SMM ist das Konzept der Organisationsreife.

unreif gilt als eine Organisation, in der der Softwareentwicklungsprozess nur von bestimmten Leistungsträgern und Managern abhängt und Entscheidungen oft „on the fly“ getroffen werden. In diesem Fall besteht eine hohe Wahrscheinlichkeit, dass das Budget überschritten oder das Projekt nicht geliefert wird, und daher sind Manager gezwungen, sich nur mit der Lösung unmittelbarer Probleme zu befassen.

Reifen Es wird davon ausgegangen, dass eine Organisation die folgenden Bedingungen erfüllt:

• – Es gibt klar definierte Verfahren zur Erstellung von Softwareprodukten und zum Projektmanagement, die verfeinert und verbessert werden Pilotprojekte durch Analyse der Komponenten "Kosten - Gewinn";
• – Schätzungen des Zeit- und Kostenaufwands für die Durchführung der Arbeiten beruhen auf gesammelten Erfahrungen und sind daher ziemlich genau;
• – das Unternehmen hat Standards für die Prozesse der Entwicklung, des Testens und der Implementierung von Software, Regeln für die Gestaltung des endgültigen Programmcodes, Komponenten, Schnittstellen usw. All dies bildet die Infrastruktur und Unternehmenskultur die den Softwareentwicklungsprozess unterstützen.

Also die Norm SMM ist ein Qualitätssicherungsmodell, das aus Kriterien zur Beurteilung des Reifegrades einer Organisation und Rezepten zur Verbesserung bestehender Prozesse besteht. Im Modell SMM Es werden fünf Reifegrade von Organisationen definiert, deren Merkmale in Abb. 1 dargestellt sind. 5.3.

Reis. 5.3. Fünf Stufen der ModellreifeSMM

Erste Ebene (Anfangslevel) ist die Grundlage für die Entwicklung des Unternehmens auf den folgenden Ebenen. Es wird angenommen, dass es im Einstiegsunternehmen der Organisation keine stabilen Bedingungen für die Erstellung hochwertiger Software gibt. Folglich hängt das Ergebnis eines jeden Projekts ausschließlich von den persönlichen Qualitäten des Managers und der Erfahrung der Programmierer ab. Das bedeutet, dass der Erfolg in einem Projekt nur wiederholt werden kann, wenn die gleichen Manager und Programmierer für das nächste Projekt eingesetzt werden. Verlassen jedoch projekterfahrene Manager oder Programmierer das Unternehmen, so sinkt mit ihrem Ausscheiden die Qualität der produzierten Software stark.

Es sollte erkannt werden, dass auf der Anfangsebene, in Stresssituationen, eine große Abhängigkeit besteht menschlicher Faktor Der Entwicklungsprozess wird auf das Schreiben von Code und dessen minimales Testen reduziert.

Zweites erreichen wiederholbare Ebene (wiederholbare Ebene) wird durch die Implementierung der Projektmanagementtechnologie im Unternehmen bestimmt. Planung und Projektmanagement im Unternehmen basieren auf gesammelten Erfahrungen, es gibt und gibt Standards für die entwickelte Software, deren Einhaltung von einer speziellen Qualitätssicherungsgruppe kontrolliert wird. Es wird davon ausgegangen, dass die zweite Stufe sowohl Möglichkeiten zur weiteren Verbesserung bieten kann (Übergang zur dritten Stufe), als auch die Möglichkeit einer regressiven Rückkehr der Qualität des Softwareentwicklungsprozesses auf die Ausgangsstufe unter kritischen Bedingungen nicht ausschließt.

Dritte, ein bestimmtes Niveau (links definiert) zeichnet sich dadurch aus, dass der Standardprozess der Softwareerstellung und -pflege von der Softwareentwicklung bis zum Projektmanagement vollständig dokumentiert ist. Die Hypothese für die Einführung dieser Ebene ist, dass das Unternehmen im Prozess der Standardisierung zu den effektivsten Praktiken und Technologien übergeht. Um die Funktionsweise von Standards für die Softwareentwicklung und das Projektmanagement in einer Organisation zu schaffen und aufrechtzuerhalten, sollte eine spezielle Gruppe eingerichtet werden. Voraussetzung für das Erreichen der dritten Stufe ist das Vorhandensein eines Programms zur kontinuierlichen beruflichen Weiterentwicklung und Schulung der Mitarbeiter im Unternehmen. Es wird davon ausgegangen, dass die Organisation ab diesem Niveau nicht mehr von den Qualitäten bestimmter Entwickler abhängig ist und in Stresssituationen nicht dazu neigt, auf ein niedrigeres Niveau abzurutschen.

Am vierten, verwaltete Ebene (verwaltete Ebene) Das Unternehmen erstellt quantitative Qualitätsindikatoren - sowohl für Softwareprodukte als auch für die Prozesse ihrer Erstellung im Allgemeinen. Somit wird ein besseres Projektmanagement erreicht, indem die Abweichungen verschiedener Projektindikatoren reduziert werden. Gleichzeitig werden sinnvolle (Signal-)Variationen der implementierten Softwareentwicklungsprozesse und zufällige (Rausch-)Variationen des Prozesses getrennt.

Fünfter (höchster), Optimierungsebene (Optimierungsebene) dadurch gekennzeichnet, dass Verbesserungsmaßnahmen nicht nur auf bestehende Prozesse angewendet werden, sondern auch die Wirksamkeit der Einführung neuer Technologien bewertet wird. Die Hauptaufgabe des Unternehmens auf dieser Ebene ist die kontinuierliche Verbesserung bestehender Prozesse. Gleichzeitig soll die Prozessverbesserung zur Vorbeugung beitragen mögliche Fehler und Defekte. Gleichzeitig sollte daran gearbeitet werden, die Kosten der Softwareentwicklung zu senken.

5 Evolutionsstufen im Management von Organisationsprozessen. Erläuterung des Capability Maturity Model. CMM

Das CM-CEI Capability Maturity Model ist ein Organisationsmodell, das die 5 Evolutionsstufen (Ebenen) beschreibt, auf denen Prozesse in einer Organisation verwaltet werden.

Das ursprünglich für die Softwareentwicklung geschaffene Capability Maturity Model besteht darin, dass eine Organisation in der Lage sein sollte, ihre Softwareanwendungen zu akzeptieren und zu unterstützen. Das Modell schlägt auch konkrete Schritte und Initiativen vor, um der Organisation zu helfen, auf die nächste Stufe zu wachsen.

Die 5 Stufen des Reifegradmodells der Fähigkeiten

Anfänglich (Prozesse sind ad hoc, chaotisch oder tatsächlich sind nur wenige von ihnen definiert) Wiederholbar (grundlegende Prozesse sind etabliert und es gibt Disziplin, sich an diese Prozesse zu halten) Definiert (alle Prozesse sind definiert, dokumentiert), vereinheitlicht und integriert) Managed ( Prozesse werden gemessen, indem detaillierte Daten zu Prozessen und deren Qualität aggregiert werden) Optimieren (kontinuierliche Prozessentwicklung durch quantitatives Feedback und Testen neuer Ideen und Technologien)

Modell der Softwareentwicklung

Das CMM beschreibt die Prinzipien und Praktiken, die dem Konzept der Softwareprozessreife zugrunde liegen. Sie sollen Softwareentwicklungs- und -vertriebsfirmen helfen, die Ausgereiftheit ihrer Softwareprozesse auf evolutionäre Weise zu verbessern. Angefangen von ad hoc chaotischen Prozessen bis hin zu ausgereiften, disziplinierten Softwareprozessen. Der Schwerpunkt liegt auf der Identifizierung von Schlüsselprozessbereichen und beispielhaften Praktiken, die disziplinierte Softwareprozesse darstellen können. Das Konzept der CMM-Reife schafft einen Kontext, in dem:

Übungen können wiederholt werden. Wenn Sie eine Operation nicht wiederholen, sollten Sie sie nicht verbessern. Es gibt Regeln, Verfahren und Praktiken, die eine Organisation zur Umsetzung und konsequenten Umsetzung zwingen. Best Practices für die Organisation der Produktionsarbeit können schnell zwischen Gruppen ausgetauscht werden. Die Praktiken sind so definiert, dass sie den Austausch zwischen Projekten ermöglichen und somit eine gewisse Standardisierung für die Organisation bieten. Abweichungen in der Ausführung dieser Verfahren werden minimiert. Für Aufgaben werden quantitative Ziele gesetzt; und Messungen werden erstellt, erstellt und gepflegt, um die Grundlage für die Bewertung zu bilden. Praktiken werden kontinuierlich verbessert, um die Leistungsfähigkeit zu verbessern (Optimierung).

Das Fähigkeitsreifemodell ist nicht nur für die Softwareentwicklung nützlich, sondern auch zur Beschreibung der Evolutionsstufen von Organisationen im Allgemeinen und zur Beschreibung des Managementniveaus, das eine Organisation implementiert hat oder erreichen möchte.

Struktur des Feature-Entwicklungsmodells

Reifegrade sind ein mehrschichtiges Konzept, das die Konsistenz der Disziplin bietet, die erforderlich ist, um eine kontinuierliche Verbesserung zu erreichen. Hier ist es wichtig zu beachten, dass eine Organisation die Fähigkeit entwickelt, die Folgen einer neuen Praxis, Technologie oder eines neuen Werkzeugs zu bewerten. Es geht also nicht um die Akzeptanz dieser Innovationen, sondern darum, wie sich diese Innovationsanstrengungen auf bestehende Praktiken auswirken. Es unterstützt Projekte, Gruppen und Organisationen, indem es ihnen eine Grundlage für fundierte Entscheidungen gibt. Schlüsselprozessbereiche – Ein Schlüsselprozessbereich (KPA) definiert eine Gruppe verwandter Aktivitäten, die, wenn sie gemeinsam durchgeführt werden, eine Reihe wichtiger Ziele erreichen. Ziele – Die Ziele eines Schlüsselprozessgebiets beschreiben die Vorkehrungen, die für dieses Schlüsselprozessgebiet bestehen müssen. Vorschriften müssen effizient und sicher umgesetzt werden. Das Ausmaß, in dem Ziele erreicht werden, zeigt an, welche Art von Fähigkeit die Organisation auf diesem Exzellenzniveau aufgebaut hat. Ziele beschreiben den Geltungsbereich, die Grenzen und den Zweck jedes Schlüsselprozessbereichs. Allgemeine Merkmale – Zu den allgemeinen Merkmalen gehören Praktiken, die Schlüsselprozessbereiche implementieren und institutionalisieren. Diese 5 Arten allgemeine Eigenschaften umfassen: Leistungsverpflichtung, Leistungsfähigkeit, durchzuführende Initiativen, Messung und Analyse sowie Umsetzungskontrolle. Schlüsselpraktiken - Schlüsselpraktiken beschreiben die Infrastrukturelemente und -praktiken, die am effektivsten zur Implementierung und Institutionalisierung von Schlüsselprozessbereichen beitragen.

Kriterien für die Definition eines Prozesses

Kriterien für die Definition eines Prozesses sind eine Reihe von Prozesselementen, die in einer Software-Prozessbeschreibung enthalten sein müssen, damit Menschen sie in der Praxis verwenden können. Um die Kriterien festzulegen, müssen Sie die Frage stellen: „Welche Informationen zu Softwareprozess zur Dokumentation benötigt?