Fragen zum Software-Prozessreifegrad (CMM Version 1.1)

Transkript

1 Fragen zum Software-Prozessreifegrad (CMM Version 1.1) (entsprechend Maturity Questionnaire, Carnegie Mellon University, 1994, Version 1.1) Anmerkungen: Die Übersetzung der Fragen des CMM Maturity Questionnaire wurde von Wolfgang Daschner und Ernest Wallmüller im November 1999 auf mehrfache Nachfrage von Kunden nach einer deutschen Version angefertigt. Die Übersetzung hält sich eng an das Original, das sich auf die derzeit gültige CMM Version 1.1 bezieht; die Veränderungen, die sich durch die vorliegenden Drafts des Software-CMM, Version 2.0, Draft C, und des CMMI (Capability Maturity Model Integration), Version 0.2 (Draft in review 11/1999), ergeben, sind nicht eingearbeitet. Level 2: Wiederholbarer Prozess Management der Anforderungen Zweck des Managements der Anforderungen ist es, ein gemeinsames Verständnis zwischen Kunde und Hauptauftragnehmer bezüglich der Kundenanforderungen, die durch das Software- Projekt abgedeckt werden sollen, zu erzeugen. Management der Anforderungen bedingt das Erstellen einer Übereinkunft mit dem Kunden über die Anforderungen für das Software-Projekt sowie das geordnete Ändern dieser Übereinkunft, wenn nötig. Die Übereinkunft deckt technische und nichttechnische Anforderungen (z.b. Lieferzeitpunkt) ab. Sie bildet die Ausgangsbasis für Schätzung, Planung, Durchführung und Verfolgung der Tätigkeiten des Software-Projekts über den ganzen Software-Lebenszyklus hinweg. Bei Änderungen der Systemanforderungen mit Software-Bezug werden die betreffenden Pläne, Arbeitsergebnisse und Tätigkeiten angepasst, um sie mit den geänderten Anforderungen konsistent zu halten. 1. Die Systemanforderungen mit Software-Bezug bilden die abgesicherte Ausgangsbasis (= Baseline) für die Software-Erstellung und das Software-Management. 2. Die Pläne zur Software-Erstellung, die Produkte und die Tätigkeiten werden mit den Systemanforderungen mit Software-Bezug konsistent gehalten. 1. Bilden die Systemanforderungen mit Software-Bezug die Ausgangsbasis (= Baseline) für die Software-Erstellung und das Software-Management? 2. Werden im Falle von Änderungen der Systemanforderungen mit Software-Bezug die Pläne zur Software-Erstellung, die Produkte und die Tätigkeiten angepasst? 3. Folgt das Projekt einer schriftlich niedergelegten Vorgabe zum Erstellen und Verwalten der Systemanforderungen mit Software-Bezug? 4. Sind die Personen im Projekt, die mit dem Management der Systemanforderungen betraut sind, auch in dieser Tätigkeit ausgebildet? 5. Werden Messungen durchgeführt, um den Status der Tätigkeiten des Managements der Systemanforderungen festzustellen (z.b. Gesamtzahl der Änderungen der Systemanforderungen, die vorgeschlagen, offen, genehmigt oder in die Baseline implementiert sind)? 6. Sind die Tätigkeiten des Managements der Systemanforderungen Reviews durch die Software-Qualitätssicherung unterworfen? Qualität & Informatik 1/10

2 Planung der Software-Projekte Zweck der Planung der Software-Projekte ist es, angemessene Pläne für die Durchführung der Software-Entwicklungstätigkeiten und für das Projektmanagement zu erstellen. Planung der Software-Projekte bedingt die Entwicklung von Abschätzungen für die zu leistende Arbeit, die Erstellung der notwendigen Vereinbarungen und des Plans, nach dem die Arbeit abgewickelt wird. 1. Software-Schätzungen werden dokumentiert und bei der Planung und der Verfolgung des Software-Projektes verwendet. 2. Auszuführende Tätigkeiten und eingegangene Vereinbarungen im Software-Projekt sind geplant und dokumentiert. 3. Alle beteiligten Gruppen und Einzelpersonen halten sich an ihre Vereinbarungen im Rahmen des Software-Projektes. 1. Werden Schätzungen (z.b. Größe, Kosten, Zeitplan) dokumentiert, die bei der Planung und der Verfolgung des Software-Projektes verwendet werden? 2. Enthält die dokumentierte Planung die auszuführenden Tätigkeiten und die eingegangenen Vereinbarungen? 3. Halten sich alle beteiligten Gruppen und Einzelpersonen an ihre Vereinbarungen im Rahmen des Software-Projektes? 4. Folgt das Projekt einer schriftlich niedergelegten Vorgabe zur Planung eines Software- Projektes? 5. Werden ausreichende Ressourcen zur Planung des Software-Projektes zur Verfügung gestellt (z.b. Budget, erfahrene Experten)? 6. Werden Messungen zur Bestimmung des Status der Planungstätigkeiten des Software- Projektes verwendet (z.b. Meilensteineinhaltung bei Planungstätigkeiten)? 7. Unterzieht der Projektmanager die Planungstätigkeiten des Software-Projektes periodischen und ereignisgetriebenen Reviews? Überwachung und Verfolgung des Fortschritts der Software- Projekte Zweck der Überwachung und Verfolgung des Fortschritts der Software-Projekte ist es, den tatsächlichen Projektfortschritt genügend transparent zu machen, sodass das Management in die Lage versetzt wird, entsprechende Korrekturmaßnahmen zu ergreifen, wenn der Projektfortschritt deutlich von der Planung abweicht. Korrekturmaßnahmen können beinhalten, dass die Software-Entwicklungsplanung revidiert wird, um das tatsächlich Erreichte widerzuspiegeln und die Restarbeit neu zu planen, oder dass Maßnahmen zur Verbesserung der Performance ergriffen werden. Überwachung und Verfolgung des Fortschritts bedingt, dass die erreichten Ergebnisse mit den dokumentierten Schätzgrößen, Vereinbarungen und Plänen verglichen werden und diese Pläne auf der Basis der bis dahin tatsächlich erreichten Ergebnisse eine Anpassung erfahren. 1. Die tatsächlichen Ergebnisse und Leistungen im Software-Projekt werden mit den Planwerten verglichen (Projektverfolgung). 2. Korrekturmaßnahmen werden eingeleitet und bis zum Abschluss ihrer Durchführung überwacht, wenn die tatsächlichen Ergebnisse und Leistungen signifikant von den Plänen Qualität & Informatik 2/10

3 abweichen. 3. Änderungen in den Vereinbarungen werden von allen beteiligten Gruppen und Einzelpersonen übernommen. 1. Werden die tatsächlichen Ergebnisse und Leistungen (z.b. Größe, Kosten, Zeitplan) mit den Schätzungen der Planung verglichen? 2. Werden Korrekturmaßnahmen eingeleitet, wenn die tatsächlichen Ergebnisse und Leistungen signifikant von den Plänen abweichen? 3. Werden Änderungen in den Vereinbarungen von allen beteiligten Gruppen und Einzelpersonen übernommen? 4. Folgt das Projekt einer schriftlich niedergelegten Vorgabe zur Verfolgung und Steuerung seiner Software-Entwicklungstätigkeiten? 5. Ist die Verantwortlichkeit im Projekt für die Verfolgung der Fertigstellung von Arbeitsergebnissen und der Tätigkeiten (z.b. Größe, Kosten, Zeitplan) bestimmt? 6. Werden Messungen eingesetzt, um den Status der Verfolgungs- und Steuerungstätigkeiten des Software-Projektes festzustellen (z.b. tatsächlich verbrauchter Aufwand bei Verfolgungs- und Steuerungstätigkeiten)? 7. Werden die Verfolgungs- und Steuerungstätigkeiten des Software-Projektes periodischen Reviews durch das übergeordnete Management unterzogen (z.b. Projektperformance, Probleme, Risiken, Punkte aus Aktionslisten)? Lieferantenmanagement bei Software-Projekten Zweck des Lieferantenmanagements bei Software-Projekten ist es, qualifizierte Software- Lieferanten auszuwählen und effektiv mit ihnen umzugehen. Lieferantenmanagement bei Software-Projekten bedingt die Auswahl eines Software-Lieferanten, den Abschluss von Vereinbarungen mit dem Lieferanten und die Überwachung und Verfolgung der Performance und der Ergebnisse des Lieferanten. Diese Verfahren decken sowohl das Management eines reinen Software-Unterauftrags als auch eines Unterauftrags ab, der Software, Hardware und eventuell weitere Systemkomponenten umfasst. 1. Der Hauptauftragnehmer wählt qualifizierte Software-Lieferanten aus. 2. Der Hauptauftragnehmer und der Software-Lieferant halten sich an ihre gemeinsamen Vereinbarungen. 3. Der Hauptauftragnehmer und der Software-Lieferant führen eine regelmäßige Kommunikation durch. 4. Der Hauptauftragnehmer überprüft die tatsächlichen Ergebnisse und die Performance des Software-Lieferanten anhand der eingegangenen Vereinbarungen. 1. Wird ein schriftlich niedergelegtes Auswahlverfahren für Lieferanten benutzt, das auf deren Fähigkeit, die Arbeit durchführen zu können, beruht? 2. Bedürfen Änderungen an Unteraufträgen sowohl der Zustimmung des Hauptauftragnehmers als auch des Lieferanten? 3. Findet periodisch ein Austausch auf technischer Ebene mit dem Lieferanten statt? 4. Werden Ergebnisse und Performance des Lieferanten anhand der eingegangenen Vereinbarungen überprüft? 5. Folgt das Projekt einer schriftlich niedergelegten Vorgabe für das Management von Aufträgen an Lieferanten? 6. Sind die Verantwortlichen für das Management von Aufträgen an Lieferanten auf diesem Gebiet entsprechend ausgebildet? Qualität & Informatik 3/10

4 7. Werden Messungen zur Bestimmung des Status der Tätigkeiten beim Management von Aufträgen an Lieferanten verwendet (z.b. Status des Zeitplans bezüglich geplanter Lieferzeitpunkte und geleisteter Aufwendungen für das Management von Unteraufträgen)? 8. Werden die Tätigkeiten im Zusammenhang mit Aufträgen an Lieferanten periodischen und ereignisgetriebenen Reviews mit dem Projektmanager unterzogen? Software-Qualitätssicherung Zweck der Software-Qualitätssicherung ist es, dem Management angemessen die in dem Software-Projekt angewandten Prozesse und die erzeugten Produkte transparent zu machen. Software-Qualitätssicherung bedingt die Durchführung von Reviews und Audits der Software- Produkte und der Projekttätigkeiten, um sicherzustellen, dass diese den vorgeschriebenen Normen und Verfahren genügen; des Weiteren stellt Software-Qualitätssicherung die Ergebnisse dieser Reviews und Audits dem Software-Projektteam und dem Management in Form von Berichten zur Verfügung. 1. Die Tätigkeiten der Software-Qualitätssicherung sind geplant. 2. Die Einhaltung von vorgeschriebenen Normen, Verfahren und Spezifikationen wird bei den Software-Tätigkeiten und Produkten objektiv überprüft. 3. Die beteiligten Gruppen und Einzelpersonen werden über die Tätigkeiten und Ergebnisse der Software-Qualitätssicherung informiert. 4. Abweichungen, die innerhalb des Software-Projektes nicht gelöst werden können, werden durch das übergeordnete Management behandelt. 1. Werden die Tätigkeiten der Software-Qualitätssicherung für das Projekt geplant? 2. Liefert die Software-Qualitätssicherung eine objektive Bestätigung, dass die Tätigkeiten und Produkte sich an die vorgeschriebenen Normen, Verfahren und Spezifikationen halten? 3. Werden die Ergebnisse von Reviews und Audits der Software-Qualitätssicherung den beteiligten Gruppen und Einzelpersonen (z.b. denen, die die Arbeit ausführten, und denen, die Verantwortung für die Arbeit tragen) weitergegeben? 4. Werden Abweichungen, die innerhalb des Software-Projektes nicht gelöst wurden, durch das übergeordnete Management behandelt (z.b. Abweichungen von vorgeschriebenen Normen)? 5. Folgt das Projekt einer schriftlich niedergelegten Vorgabe zur Durchführung von Aktivitäten der Software-Qualitätssicherung? 6. Werden ausreichende Ressourcen zur Durchführung von Software-Qualitätssicherungstätigkeiten zur Verfügung gestellt (z.b. Budget, eine Person, die explizit ernannt wird, um sich mit Abweichungen zu befassen)? 7. Werden Messungen zur Bestimmung der Kosten und des zeitlichen Status der Software- Qualitätssicherungstätigkeiten durchgeführt (z.b. fertiggestellte Arbeiten, tatsächlich verbrauchter Aufwand und Mittel im Vergleich zum Plan)? 8. Werden die Software-Qualitätssicherungstätigkeiten periodischen Reviews durch das übergeordnete Management unterzogen? Software-Konfigurationsmanagement Zweck des Software-Konfigurationsmanagements ist es, die Integrität der Ergebnisse des Software-Projekts zu schaffen und über den ganzen Lebenszyklus des Software-Projekts hinweg beizubehalten. Software-Konfigurationsmanagement bedingt die Identifizierung der Software- Konfiguration (d.h. ausgewählte Software-Arbeitsergebnisse und deren Dokumentation) zu Qualität & Informatik 4/10

5 bestimmten Zeitpunkten, die systematische Kontrolle der Änderungen an der Konfiguration und die Bewahrung der Integrität und der Auffindbarkeit der Konfiguration über den ganzen Lebenszyklus hinweg. Die Arbeitsergebnisse, die der Konfigurationskontrolle unterliegen, umfassen sowohl die Software-Produkte, die an den Kunden geliefert werden, als auch Artefakte, die Zwischenergebnisse oder Mittel zur Erzeugung der gelieferten Produkte sind. 1. Die Tätigkeiten des Software-Konfigurationsmanagements sind geplant. 2. Ausgewählte Software-Arbeitsergebnisse werden identifiziert, überwacht und sind jederzeit verfügbar. 3. Änderungen an identifizierten Software-Arbeitsergebnissen werden systematisch überwacht. 4. Betroffene Gruppen und Einzelpersonen werden über den Status und Inhalt von Software- Baselines informiert. 1. Werden die Tätigkeiten des Software-Konfigurationsmanagements für das Projekt geplant? 2. Folgt das Projekt Verfahren des Konfigurationsmanagements bei der Identifizierung der Arbeitsergebnisse, bei geordneten Änderungen daran und beim Bereitstellen der Arbeitsergebnisse? 3. Folgt das Projekt einem schriftlich niedergelegten Verfahren zur Änderungskontrolle bei Konfigurationselementen? 4. Werden Berichte über Software-Baselines (z.b. Protokolle von Sitzungen des Software- Konfigurationskontrollgremiums, zusammenfassende Berichte des Änderungswesens) an die betreffenden Gruppen und Einzelpersonen verteilt? 5. Folgt das Projekt einer schriftlich niedergelegten Vorgabe zur Durchführung von Tätigkeiten des Software-Konfigurationsmanagements? 6. Sind Mitarbeiter und Manager des Konfigurationsmanagements für ihre Aufgaben im Projekt ausreichend geschult? 7. Werden Messungen zur Bestimmung des Status der Tätigkeiten des Software- Konfigurationsmanagements verwendet (z.b. verbrauchter Aufwand und Budget für Tätigkeiten des Software-Konfigurationsmanagements)? 8. Werden periodisch Audits durchgeführt, um die Übereinstimmung der Software-Baselines mit der zugehörigen Dokumentation nachzuweisen? Level 3: Definierter Prozess Organisationsweiter Prozessfokus Zweck des organisationsweiten Prozessfokus ist es, die Verantwortlichkeit für Software- Prozesstätigkeiten zu schaffen, die die organisationsweite Software-Prozessfähigkeit verbessern. Organisationsweiter Prozessfokus bedingt die Entwicklung eines Verständnisses der Software- Prozesse in den Projekten und projektübergreifend in der Organisation sowie die Koordination von Tätigkeiten, diese Prozesse zu prüfen, zu entwickeln, zu warten und zu verbessern. Die Organisation macht langfristige Zusagen und stellt Ressourcen zur Verfügung, um Entwicklung und Wartung der Software-Prozesse über eine Einheit wie die Software Engineering Process Group (SEPG) zu koordinieren. Diese Einheit ist für die Software-Prozesstätigkeiten in der Organisation verantwortlich. 1. Die Tätigkeiten der Entwicklung und Verbesserung der Software-Prozesse werden organisationsweit koordiniert. 2. Die Stärken und Schwächen der gelebten Software-Prozesse werden im Vergleich zu einem Standardprozess identifiziert. 3. Die Tätigkeiten der organisationsweiten Entwicklung und Verbesserung der Software- Qualität & Informatik 5/10

6 Prozesse werden geplant. 1. Werden die Tätigkeiten der Entwicklung und Verbesserung der Software-Prozesse in der Organisation und in den Projekten organisationsweit koordiniert (z.b. über eine SEPG)? 2. Gibt es periodische Überprüfungen der Software-Prozesse in der Organisation? 3. Folgt die Organisation einem schriftlich niedergelegten Plan zur Entwicklung und Verbesserung ihrer Software-Prozesse? 4. Fördert das übergeordnete Management die Tätigkeiten der Organisation zur Entwicklung und Verbesserung der Software-Prozesse (z.b. durch Erstellung von langfristigen Plänen, durch Zusage von Ressourcen und Geldmitteln)? 5. Haben eine oder mehrere Personen die Verantwortlichkeit für die Software- Prozesstätigkeiten in der Organisation übernommen (z.b. eine SEPG)? 6. Werden Messungen zur Bestimmung des Status der Tätigkeiten zur Entwicklung und Verbesserung der Software-Prozesse der Organisation verwendet (z.b. verbrauchter Aufwand für Überprüfung und Verbesserung der Software-Prozesse)? 7. Werden die Tätigkeiten der Entwicklung und Verbesserung der Software-Prozesse periodischen Reviews durch das übergeordnete Management unterworfen? Organisationsweite Prozessdefinition Zweck einer organisationsweiten Prozessdefinition ist die Entwicklung und Wartung einer Menge von Software-Prozessvorgaben, die für alle Projekte die Prozessausführung verbessert und eine Basis für wachsenden langfristigen Nutzen für die Organisation darstellt. Eine organisationsweite Prozessdefinition bedingt das Entwickeln und Weiterführen der organisationsweiten Software-Prozessvorgaben, zusammen mit Prozessassets wie z.b. Beschreibungen von Software-Lebenszyklen, Kriterien und Anleitungen zur projektspezifischen Anpassung von Prozessen, die organisationsweite Software-Prozessdatenhaltung und eine Sammlung von prozessbezogenen Dokumenten. 1. Software-Prozessvorgaben für die Organisation werden entwickelt und gewartet. 2. Informationen, die mit der Nutzung der Software-Prozessvorgaben der Organisation durch die Software-Projekte zusammenhängen, werden gesammelt, Reviews unterzogen und zur Verfügung gestellt. 1. Hat die Organisation Software-Prozessvorgaben entwickelt und wartet sie diese? 2. Sammelt die Organisation Informationen, die mit der Nutzung der Software- Prozessvorgaben der Organisation zusammenhängen, unterzieht sie diese Reviews und stellt sie diese zur Verfügung (z.b. Schätzungen und Istdaten über Software-Größe, -Aufwand, und -Kosten, Produktivitätsdaten, Qualitätsmessungen)? 3. Folgt die Organisation einer schriftlich niedergelegten Vorgabe zur Entwicklung und Wartung ihrer Software-Prozessvorgaben und der zugehörigen Prozessassets (wie z.b. Beschreibungen von Software-Lebenszyklen)? 4. Werden Mitarbeiter, die die Software-Prozessvorgaben der Organisation entwickeln und warten, für diese Aufgaben ausreichend geschult? 5. Werden Messungen zur Bestimmung des Status der Tätigkeiten der Prozessdefinition und wartung der Organisation verwendet (z.b. Status der zeitlichen Meilensteine und Kosten der Prozessdefinitionstätigkeiten? 6. Sind die Tätigkeiten und Arbeitsergebnisse der Entwicklung und Wartung der Software- Prozessvorgaben der Organisation Reviews und Audits durch die Software- Qualitätssicherung unterworfen? Qualität & Informatik 6/10

7 Schulungsprogramm Zweck des Schulungsprogramms ist die Entwicklung von Fähigkeiten und Wissen bei Mitarbeitern, sodass sie ihre Rollen in der Organisation wirksam und wirtschaftlich ausüben können. Schulungsmaßnahmen bedingen zuerst die Ermittlung des Schulungsbedarfs der Organisation, der Projekte und der einzelnen Mitarbeiter, dann Kurseigenentwicklung oder Fremdbeschaffung von Schulungen, um den identifizierten Schulungsbedarf zu befriedigen. Einige Fähigkeiten werden wirksam und wirtschaftlich über informelle Maßnahmen (wie z.b. durch Training-on-the-job oder informelle Mentorenhilfe) vermittelt, andere Fähigkeiten eher über formale Schulungsmaßnahmen (wie z.b. Schulungen in Schulungsräumen oder geführte Selbststudien). Die jeweils geeigneten Maßnahmen werden ermittelt und umgesetzt. 1. Schulungsmaßnahmen werden geplant. 2. Schulungen zur Entwicklung des Wissens und der Fähigkeiten, die für die Ausübung von leitenden und technischen Rollen im Software-Bereich benötigt werden, werden angeboten. 3. Mitglieder der Software-Entwicklungsgruppe oder anderer Software-Prozessgruppen erhalten die für die Ausübung ihrer Rollen notwendigen Schulungen. 1. Werden Schulungsmaßnahmen geplant? 2. Werden Schulungen zur Entwicklung des Wissens und der Fähigkeiten angeboten, die für die Ausübung von leitenden und technischen Rollen im Software-Bereich benötigt werden? 3. Erhalten Mitglieder der SEPG oder anderer Software-Prozessgruppen die für die Ausübung ihrer Rollen notwendigen Schulungen? 4. Folgt die Organisation einer schriftlich niedergelegten Vorgabe zur Befriedigung ihres Schulungsbedarfs? 5. Werden ausreichende Ressourcen zur Durchführung des Schulungsprogramms der Organisation zur Verfügung gestellt (z.b. Budget, Software-Werkzeuge, geeignete Schulungseinrichtungen)? 6. Werden Messungen zur Bestimmung der Qualität des Schulungsprogramms eingesetzt? 7. Werden die Tätigkeiten für das Schulungsprogramm periodischen Reviews durch das übergeordnete Management unterzogen? Integriertes Software-Management Zweck des Integrierten Software-Managements ist die Integration von Software-Engineeringund -Managementtätigkeiten in einem einheitlichen, definierten Software-Prozess, der aus organisationsweiten Software-Prozessvorgaben und zugehörigen Prozessassets projektspezifisch angepasst wurde. Integriertes Software-Management bedingt die Entwicklung des projektspezifischen Software-Prozesses und das Management des Software-Projektes unter Benutzung dieses zuvor definierten Software-Prozesses. Dieser Prozess wird anhand der organisationsweiten Software-Prozessvorgaben angepasst, um die spezifischen Projekteigenschaften zu adressieren. Der Software-Entwicklungsplan beruht auf dem projektspezifischen Software-Prozess und beschreibt, wie seine Tätigkeiten durchgeführt und geleitet werden. 1. Der projektspezifische Software-Prozess entsteht durch Anpassung der organisationsweiten Software-Prozessvorgaben. 2. Jedes Projekt wird gemäß seinem projektspezifischen Software-Prozess geplant und geleitet. Qualität & Informatik 7/10

8 1. Wurde der projektspezifische Software-Prozess durch Anpassung der organisationsweiten Software-Prozessvorgaben entwickelt? 2. Wird jedes Projekt gemäß seinem projektspezifischen Software-Prozess geplant und geleitet? 3. Folgt das Projekt einem schriftlich niedergelegtem Verfahren, das von ihm bei Planung und Leitung die Benutzung der organisationsweiten Software-Prozessvorgaben einfordert? 4. Werden Schulungsmaßnahmen für Personen durchgeführt, die die organisationsweiten Software-Prozessvorgaben in einem projektspezifischen Software-Prozess für ein neues Projekt anpassen sollen? 5. Werden Messungen zur Bestimmung der Wirksamkeit der Tätigkeiten des Integrierten Software-Managements benutzt (z.b. Häufigkeit, Ursachen und Größenordnung von Umplanungsaufwänden)? 6. Sind die Tätigkeiten und Arbeitsergebnisse, die zur Leitung des Software-Projekts genutzt werden, Reviews und Audits durch die Software-Qualitätssicherung unterworfen? Software-Product-Engineering Zweck von Software-Product-Engineering (SPE) ist die konsistente Durchführung eines wohldefinierten Engineeringprozesses, der alle Software-Engineeringtätigkeiten integriert, um korrekte konsistente Software-Produkte wirksam und wirtschaftlich zu erzeugen. SPE bedingt die Durchführung der Engineeringtätigkeiten zur Erzeugung und Wartung von Software unter Benutzung des projektspezifischen Software-Prozesses und geeigneter Methoden und Werkzeuge. Zu den Software-Engineeringtätigkeiten gehören die Analyse der Systemanforderungen mit Software-Bezug, die Entwicklung der Software-Architektur und des Designs, die Erzeugung des Codes und der Test der Software, um nachzuweisen, dass sie die spezifizierten Anforderungen erfüllt. 1. Die Software-Engineeringaufgaben werden definiert, integriert und konsistent ausgeführt, um die Software herzustellen. 2. Die Software-Arbeitsergebnisse werden konsistent zueinander gehalten. 1. Werden die Software-Arbeitsergebnisse gemäß dem projektspezifischen Software-Prozess erzeugt? 2. Bleibt die Konsistenz der Software-Arbeitsergebnisse sichergestellt (z.b. wird die Dokumentation gewartet, die eine Verfolgung der Systemanforderungen mit Software-Bezug über die Software-Anforderungen, das Design, den Code und die Testfälle ermöglicht)? 3. Folgt das Projekt einem schriftlich niedergelegten Verfahren zur Durchführung der Software-Engineeringtätigkeiten (z.b. einem Verfahren, das die Benutzung von geeigneten Methoden und Werkzeugen zum Erzeugen und Warten von Software-Produkten einfordert)? 4. Werden ausreichende Ressourcen zur Durchführung der Software-Engineeringtätigkeiten zur Verfügung gestellt (z.b. Budget, fähige Mitarbeiter, geeignete Werkzeuge)? 5. Werden Messungen zur Bestimmung der Funktionalität und Qualität der Software-Produkte verwendet (z.b. Anzahl, Art und Schwere von erkannten Fehlern)? 6. Sind die Tätigkeiten und Arbeitsergebnisse der Software-Entwicklung Reviews und Audits durch die Software-Qualitätssicherung unterworfen (z.b. werden geforderte Tests durchgeführt, werden Systemanforderungen mit Software-Bezug über die Software- Anforderungen, das Design, den Code und die Testfälle hinweg verfolgt)? Qualität & Informatik 8/10

9 Koordination der beteiligten Gruppen Zweck der Koordination der beteiligten Gruppen ist die Schaffung eines Mittels für die Software-Entwicklungsgruppe, aktiv mit den anderen Entwicklungsgruppen zusammenzuarbeiten, sodass das Projekt insgesamt besser in der Lage ist, die Kundenbedürfnisse wirksam und wirtschaftlich zu befriedigen. Die Koordination der beteiligten Gruppen bedingt die Zusammenarbeit der Software-Entwicklungsgruppe mit den anderen Entwicklungsgruppen im Projekt, um Anforderungen auf Systemebene, Ziele und Probleme zu adressieren. Vertreter der Entwicklungsgruppen des Projekts arbeiten bei der Erstellung der Systemanforderungen, der Ziele und Pläne mit den Kunden und/oder Endbenutzern zusammen. Diese Systemanforderungen, Ziele und Pläne stellen die Grundlage für die gesamten Entwicklungstätigkeiten dar. 1. Die Kundenanforderungen werden von allen betroffenen Gruppen eingehalten. 2. Die Übereinkünfte zwischen den Entwicklungsgruppen werden von allen betroffenen Gruppen eingehalten. 3. Die Entwicklungsgruppen identifizieren, verfolgen und lösen Probleme zwischen den Gruppen. 1. Arbeiten die Software-Entwicklungsgruppe und andere Entwicklungsgruppen im Projekt mit den Kunden zusammen an der Erstellung der Systemanforderungen? 2. Stimmen die Entwicklungsgruppen den Übereinkünften, wie sie in dem globalen Projektplan dargestellt sind, zu? 3. Identifizieren, verfolgen und lösen die Entwicklungsgruppen Probleme zwischen den Gruppen (z.b. widersprüchliche Zeitpläne, technische Risiken, Probleme auf Systemebene)? 4. Gibt es ein schriftlich niedergelegtes Verfahren, das die Einrichtung von interdisziplinären Entwicklungsteams festlegt? 5. Ermöglichen die unterstützenden Werkzeuge, die von den verschiedenen Entwicklungsgruppen benutzt werden, eine wirksame Kommunikation und Koordination (z.b. kompatible Textverarbeitungssysteme, Datenbanken und Fehler- /Problemverfolgungssysteme)? 6. Werden Messungen zur Bestimmung des Status der Tätigkeiten zur Koordination der beteiligten Gruppen verwendet (z.b. verbrauchter Aufwand der Software- Entwicklungsgruppe für Unterstützung anderer Entwicklungsgruppen)? 7. Unterzieht der Projektmanager die Tätigkeiten zur Koordination beteiligter Gruppen periodischen und ereignisgetriebenen Reviews? Peer Reviews Der Zweck von Peer Reviews ist eine frühe und wirtschaftliche Fehlerbeseitigung in den Software-Arbeitsergebnissen. Ein wichtiger Folgeeffekt ist die Entwicklung eines besseren Verständnisses der Software-Arbeitsergebnisse und von vermeidbaren Fehlern. Peer Reviews bedingen eine methodische Prüfung der Software-Arbeitsergebnisse durch Kollegen des Erstellers, um Fehler und Bereiche, in denen Änderungen nötig sind, zu identifizieren. Die Arbeitsergebnisse, die einem Peer Review unterzogen werden, werden im projektspezifischen Software-Prozess identifiziert und die Peer-Review-Tätigkeiten werden zeitlich im Rahmen der Software-Projektplanung eingeplant. 1. Die Tätigkeiten für Peer Reviews sind geplant. Qualität & Informatik 9/10

10 2. Fehler in den Software-Arbeitsergebnissen werden identifiziert und entfernt. 1. Sind Peer Reviews geplant? 2. Werden Maßnahmen im Zusammenhang mit Fehlern, die bei Peer Reviews gefunden wurden, bis zur Problemlösung verfolgt? 3. Folgt das Projekt einem schriftlich niedergelegten Verfahren zur Durchführung von Peer Reviews? 4. Werden Teilnehmer an Peer Reviews entsprechend geschult, um ihre Rolle ausüben zu können? 5. Werden Messungen zur Bestimmung des Status von Peer-Review-Tätigkeiten verwendet (z.b. Anzahl der durchgeführten Peer Reviews, verbrauchter Aufwand für Peer Reviews, tatsächliche Anzahl der Peer Reviews gegenüber der Planung)? 6. Sind die Tätigkeiten und Arbeitsergebnisse der Peer Reviews selbst wiederum Reviews und Audits durch die Software-Qualitätssicherung unterworfen (z.b. sind geplante Peer Reviews durchgeführt worden und werden Folgemaßnahmen weiterverfolgt)? Qualität & Informatik 10/10