Qualität des SW-Entwicklungsprozesses

Der ISO 9000 Ansatz

• die SW-Entwicklung in Phasen stattfindet,
• die Vorgaben und die geforderten Ergebnisse der Phasen sowie die Verifizierungsverfahren jeder Phase festgelegt und dokumentiert sind,
• die Erfüllung der Vorgaben einer Phase überprüfbar sind,
• die Ergebnisse jeder Phase verifiziert werden,
• die Verifizierungsergebnisse aufgezeichnet werden,
• nur verifizierte Entwicklungsergebnisse an das Konfigurationsmanagement übergeben und für die weitere Verwendung freigegeben werden.

Vertrag Auftraggeber-Lieferant

Annahmekriterien; Behandlung von Änderungen der Auftraggeberforderungen, Behandlung von Problemen, die nach der Annahme entdeckt werden; vom Auftraggeber zu erbringende Tätigkeiten insbesondere bei Festlegung der Forderungen, Installation und Annahme ...

Spezifikation (des Auftragggebers)

vollständiger und eindeutiger Satz von funktionalen Forderungen; weitere Forderungen z.B. an Leistung, Ausfallsicherheit, Zuverlässigkeit, Datensicherheit, Persönlichkeitsschutz; Schnittstellen zu anderen Hardware- und Softwareprodukten.

Entwicklungsplan

sollte dem Entwicklungsfortschritt angepasst werden. Vor Beginn einer Phase sollen die Tätigkeiten dieser Phase festgelegt sein. Vor seiner Ausführung soll er überprüft und genehmigt sein. Sein Inhalt in Stichworten:

Festlegung des Projektes, seiner Ziele, seines Bezugs zu anderen Projekten;

Planung der Projektmittel einschließlich Teamstruktur, Verantwortlichkeiten, Heranziehung von Unterlieferanten und zu verwendender materieller Hilfsmittel;

gewähltes Vorgehensmodell (s.o.);

Management des Projekts, festzulegen sind insbesondere: Termine für Entwicklung, Implementierung und zugehörigen Lieferungen; Fortschrittsüberwachung, Festlegung organisatorische Verantwortungen, Mittel und Arbeitszuteilungen; organisatorische und technische Schnittstellen zwischen verschiedenen Gruppen;

zu verwendende Entwicklungsmethoden und Werkzeuge: Regeln, Praktiken und Übereinkommen für die Entwicklung; Werkzeuge und Techniken für die Entwicklung; Konfigurationsmanagement;

Projektplan: durchzuführende Aufgaben, dafür benötigte Zeit und Mittel, Abhängigkeiten zwischen den Aufgaben;

Identifikation weiterer verwendeter Pläne für z.B. Qualitätssicherung, Konfigurationsmanagement, Integration und Test;

Qualitätssicherungsplan

• gesetzte, möglichst meßbare Qualitätsziele;
• an die Phasenergebnisse anzulegende Kriterien;
• Art der auszuführenden Verifikations-, Validierungs- und Testmaßnahmen;
• Planung dieser Maßnahmen einschließlich Terminen, Mitteln und Genehmigungsverfahren;
• besondere Verantwortungen für QS-Maßnahmen wie z.B. Reviews und Tests, sowie Konfigurationsmanagement und Änderungswesen, Fehlermeldungwesen und Korrekturmaßnahmen.

Testplan

Pläne für Modul-, Integrations-, System- und Abnahmetests; Testfälle, Testdaten und erwartete Ergebnisse; Art der durchzuführenden Tests wie z.B. Funktionstest, Lasttest, Brauchbarkeitstest, Test unter Grenzbedingungen; Testumgebungen, -werkzeuge und zu verwendende Test-Software; Kriterien für die Vollständigkeit des Tests;

Wartungsplan

Umfang der Wartung, Identifikation des Ausgangszustand des Produktes, unterstützende Organisationen, Wartungstätigkeiten, Wartungsaufzeichnungen und -berichte.

Konfigurationsmanagementplan

die Organisationen, die am Konfigurationsmanagement beteiligte sind, sowie die ihnen zugewiesenen Verantwortlichkeiten; die auszuführenden  Konfigurationsmanagement-Tätigkeiten; die zu verwendenden Konfigurationsmanagement-Werkzeuge, -Technologien und -Methoden; das Stadium, in dem Elemente der Konfigurationslenkung unterworfen werden sollen.

Der CMM-Ansatz

1. Initial: chaotischer ad-hoc Prozess, nur informell vorhanden, "Künstler" und "Helden" agieren. Alles ist möglich: vom Glückstreffer eines vollkommen erfolgreichen Projektes bis hin zum totalen Scheitern. Kosten, Zeit und Qualitität sind unvorhersehbar. Nach einer Studie von 1989 befanden sich 74% der untersuchten US-Firmen auf dieser Stufe.
2. Wiederholbar (repeatable): intuitiver Prozess, von Individuen abhängig. Kosten und Qualität schwanken, ganz gute Termin-Kontrolle, informelle Vorgehensweisen dominieren. Erfolge früherer Projekte mit ähnlichen Aufgabenstellungen sind wiederholbar. 1989 sind 22% der US-Firmen auf dieser Stufe.
3. Definiert (defined): der Prozess ist qualitativ vollständig definiert und institutionalisiert, er umfasst und integriert sowohl die  technischen Aktivitäten der Ingenieure als auch von die organisatorischen Aktivitäten des Managements. Er ist damit im wesentlichen unabhängig von Individuen. Kosten und Termine werden beherrscht, Qualität ist verbessert, aber immer noch nicht vorhersehbar. 1989 sind nur 4% der US-Firmen so weit fortgeschritten.
4. Geleitet (managed): eine zentrale Steuerung des Prozesse sammelt Prozessmaße (Metriken). An kritischen Entwicklungsstellen werden solche Masse als Entscheidungshilfen für das weitere Vorgehen herangezogen. Eine statistische Kontrolle der Produkt-Qualität wird erreicht.
5. Optimierend (optimizing): die gesammelten Prozessmasse und weitere Rückkopplungsinformationen werden benutzt, um den Prozess zu verbessern, ohne ernsthafte Auswirkungen auf Kosten oder Zeitpläne zu riskieren..

1. Anforderungsmanagement (requirements management),
2. Projektplanung,
3. Projektverfolgung,
4. Unterauftragsnehmermanagement (subcontractor management),
5. Qualitätssicherung und
6. Konfigurationsmanagement.

• Konzentration auf Prozessorganisation: Eine (zentrale) Gruppe etablieren, die für die Verbesserung des Software-Prozesses verantwortlich ist.
• Prozessdefinition: Festlegung und Bereitstellung eines Standard Prozesses für die gesamte Organisation,
• Schulungsprogramm zur Vermittlung des Wissen und der Fähigkeiten, die Mitarbeiter für die Wahrnehmung ihrer Rollen im SW-Entwicklungsprozess benötigen.
• Integration von SW-Entwicklung und Management: Management- und Entwicklungsaktivitäten sind in einem zusammenhängenden Prozess integriert, beide Seiten verwenden das gleiche Modell, Standardprozesse werden auf Projekte zugeschnitten.
• SW-Produkt-Engineering: Verschiedene Software-Produkte werden miteinander konsistent gehalten, die software-technischen Aufgaben sind definiert, in den Prozess integriert und werden konsequent ausgeführt.
• Gruppenübergreifende Koordination: Z.B. über die Produktanforderungen sind sich alle beteilgten Gruppen wie etwa Produktmanagement, Vertrieb, Service, Entwicklerteams, ... einig, eingegangene Verpflichtungen werden von allen Beteiligten respektiert, Probleme werden zügig entdeckt, verfolgt und gelöst.
• Peer reviews für die vorzeitige Fehlerbehebung.

1. Capability Maturity Model^SM for Software, Version 1.1, lokale Kopie(466 KB)
2. Key Practices of the Capability Maturity Model^SM , Version 1.1, lokale Kopie(920KB)

Das V-Modell des Bundes

• das Vorgehensmodell mit den Submodellen
• SWE   Softwareerstellung
• QS   Qualitätssicherung
• KM   Konfigurationsmanagement
• PM   Projektmanagement
beschreibt die Aktivitäten (Tätigkeiten) und Produkte (Ergebnisse), die während der Entwicklung von Software durchzuführen bzw. zu erstellen sind. Das Vorgehensmodell ist neben dem militärischen Bereich auch für den gesamten Bereich der Bundesverwaltung verbindlich und wird von sehr vielen Industriefirmen als Hausstandard zur Softwareentwicklung verwendet. Mit seiner Hilfe können Projekte gemäß der Norm ISO 9001 abgewickelt werden.
• die Methodenzuordnung, die vorschreibt, mit welchen Methoden die Aktivitäten des Vorgehensmodells durchzuführen sind und welche Darstellungsmittel in den Ergebnissen zu verwenden sind
• die Funktionalen Werkzeuganforderungen, die von denjenigen Software-Werkzeugen ("tools") erfüllt werden müssen, die bei der Entwicklung von Software eingesetzt werden sollen.

Bei der Gesellschaft für Datenverarbeitung (GMD) kan man dieses sehr umfangreiche Modell online studieren.  Detaillierte und aktuelle Informationen finden sich auch unter  http://www.v-modell.iabg.de/.    Eine Kurzbescheibung (Word !!,) ist lokal (570 KB) vorhanden.