Capability Maturity Model - CMM

Präsentation zum Thema: "Capability Maturity Model - CMM"—  Präsentation transkript:

1 Capability Maturity Model - CMM
Inhalt Der CMM-Ansatz Die 5 Reifegradstufen Die Hauptkriterien Durchführung von Prozessverbesserungen Aufwand und Nutzen Vergleiche CMM vs. ISO 9000 vs. TQM Anhang Entwicklung kleiner Systeme - Der Personal Software Prozess -PSP Annäherung an Objekte von a. Erfahrung aus Technik b. Ansätze aus SE c. Ansätze aus Common Sense oder Philosophie Daraus ableiten: Basiseigenschaften von Objekten und Beschreibung durch UML

2 Die Situation heute Qualität war schon immer und wird immer mehr zur erfolgskritischen Größe von Unternehmen. Qualität entsteht nicht durch glückliche Umstände, sondern muss geplant werden. Dabei unterstützt das Qualitätsmanagementsystem. Mit der ISO 9000-Normenfamilie wurde ein Gerüst geschaffen, an dem solche Management-Systeme ausgerichtet werden können. Bestätigt wird die Erfüllung der Grundforderungen durch ein Managementsystem in dem entsprechenden Zertifikat für das jeweilige System. Unternehmen, die sich bereits seit langem an den Forderungen der ISO 9001ff orientieren und die ernsthaft die Weiterentwicklung ihres Managementsystems vorantreiben, haben inzwischen ein Niveau erreicht, das über diese Forderungen hinausgeht und durch einfache ISO 9001-Zertifikate allein nicht angemessen widergespiegelt wird. Solche Unternehmen nutzen meist Reifegradmodelle und zugehörige Assessments als ergänzende Hilfsmittel, um die Herausforderung der weiteren Verbesserung zu meistern. Als Beispiel für ein Reifegradmodell wird das Capability Maturity Modell (CMM) eingeführt.

3 Das sollten Sie heute lernen
Was beeinflusst die Qualität von Software. Wie kann man die Qualität verbessern Grundidee des CMM Elemente des CMM Reifestufen des CMM CMM und ISO 9000

4 Qualität von Software Qualität ist nicht messbar, sondern nur über die Erfüllung von Anforderungen zu definieren Die Erfüllung von Anforderungen ist oft nicht messbar. Deswegen müssen Metriken entwickelt werden und schon bei der Formulierung der Anforderungen Aussagen darüber gemacht werden, unter welchen Bedingungen die Anforderungen erfüllt sind. Beispiel Prozessmetrik Balkenplan Balkenplan gibt Anteil einer Aufgabe am Gesamtzeitbedarf eines Projektes an Projektfortschritt gleich Summe der bereits erledigten Anteile Vergleich geplanter und tatsächlicher Fortschritt erlaubt Aussagen zum Stand eines Projektes Bei groben Abweichungen Anpassung der geplanten Aufgaben und der dafür geplanten Ressourcen unter Berücksichtigung der Randbedingungen des Projektes

5 Attribute guter Software
Software sollte dem Benutzer die geforderte Funktionalität (Korrektheit) und Performance liefern, sowie wartbar, zuverlässig und benutzbar sein. Wartbarkeit Software muss gewartet werden, um den Änderungsbedarf zu erfüllen Zuverlässigkeit Software muss vertrauenswürdig sein Effizienz Software sollte keine Systemressourcen verschwenden Benutzbarkeit Software sollte für den Benutzer, für den sie entworfen wurde, einsetz- bar sein. Das erfordert eine anwendungsspezifische Oberfläche und Robustheit gegenüber Fehlverhalten. Sind diese Kriterien erfüllt, sollte die Software möglichst häufig wiederverwendet werden.

6 Verbesserung der Softwarequalität
Grundannahmen Qualitätsziele werden während der Konzeptfindung vorgegeben. Der Entwicklungsprozess bestimmt Eigenschaften und Qualität des Produktes. Die Qualität des Entwicklungsprozesses kann definiert gemessen und verbessert werden. Qualität des Produktes Nachweis durch Prüfung Anforderungen und/oder Erwartungen an das Produkt Merkmale und Eigenschaften des Produktes PROZESS Anweisungen Ausführung Prozessqualität Die Produktqualität wird wesentlich durch die Prozessqualität bestimmt

7 Was ist ein Softwareentwicklungsprozess?
Der Softwareentwicklungsprozess beschreibt eine Menge von Tätigkeiten, die die Entwicklung der Software als Ziel haben. Allgemeine Tätigkeiten in allen Softwareprozessen sind: · Spezifikation: Was das System können unter gegebenen Entwicklungsbedingungen muss · Entwicklung: Produktion des Softwaresystems · Validierung: Testen, ob die Software das macht, was der Kunde wollte · Wartung: Änderungen der Software in Antwort auf die Änderungswünsche Das Wasserfallmodell ist die bekannteste Ausprägung einer Beschreibung des Softwareentwicklungsprozesses

8 Prozessmodelle - Eigenschaften
Prozess- Primäres Antreibendes Benutzer- Characteristika Modell Ziel Moment beteiligung Wasserfall- minimaler Dokumente gering sequentiell, modell Management- volle Breite aufwand Spiralmodell Risiko- Risiko mittel Entscheidung pro minimierung Zyklus über weiteres Vorgehen Prototypen- Risiko- Code hoch nur Teilsysteme Modell minimierung (horizontal oder vertikal) V-Modell maximale Dokumente gering sequentiell, Qualität volle Breite, (safe-to- Validation, market) Verifikation Diesen Prozessmodellen liegt im Wesentlichen das Paradigma der strukturierten Methoden zu Grunde. Die Objektorientierung wird erst durch neuere Modelle adäquat unterstützt. Dazu gehören das V-Modell-97 und der Rational Unified Process. In diesen Modellen steht der Qualitätsgedanke im Vordergrund. Sie versuchen daher eine stärkere Einbindung des Nutzers.

9 Verbesserung der Prozessqualität: Ansätze und Ziele
Statische Ansätze zur Verbesserung der Prozessqualität QM-Systeme Assessment TQM Business Engineering Audit SPICE CMM ISO 9000(2000) Erreichung der nächsten Reifegradstufe Prinzipien Forderungen an Prozesse

10 Vergleich der Ansätze von CMM und ISO 9000
CMM-Assessments DIN ISO 9001(1994) Vielzahl industrieller Organisationen, Produkte und Abläufe Nachweis der Qualifikation zur Erzeugung qualitätsgerechter Resultate Fester Industriestandard Minimalanforderungen (ausnahmslos zu erfüllen) Starrer Normentext Anerkanntes Zertifikat Nutzen ist durch das erteilte Zertifikat begründet Gegenstand Zur Zeit für reine Software-Entwicklungs-Prozesse vorgesehen Ziel Detaillierte Ziel- und Prioritätsvorgaben zur Verbesserung des Prozesses Status Nützliches Hilfsmittel zur Problemanalyse und Prozessverbesserung Forderungen Hierarchie von Forderungen in Abhängigkeit der Stufen Basis Flexibles Capability Maturity Model Ergebnis Ist-Stand, Stärken- und Schwächen-Profil Kosten vs. Nutzen Einsparungen durch Prozessverbesserung vs. Kosten für die Assessment und die Verbesserungsaktivitäten Quelle: Balzert Software Technik 2

11 Vergleich der Inhalte von CMM und ISO 9000(1994)
CMM enthält Einführung von statistischen Methoden Definition von Standards Einführung von Techniken ISO 9001 enthält Abnahmekriterien für jede Phase des Entwurfs und der Entwicklung Lenkung der Dokumente und Daten Lenkung von Qualitätsaufzeichnungen Festlegung von Verantwortungsbereichen und kompetentes Personal Handhabung, Lagerung, Verpackung, Konservierung und Versand, Wartung Kriterien für die Beurteilung von Unterauftragnehmern, zugekauften Produkten und beigestellten Produkten des Kunden. Beide Ansätze enthalten Unabhängige Audits der Entwicklungsaktivitäten Korrigierende Aktionen Mitarbeitertraining Detaillierte Definition des Prozess- und Lebenszyklus Schwerpunkt der ISO 9001-Zertifizierung ist der Nachweis, dass ein Qualitätsmanagementsystem der Norm entspricht. Der CMM-Ansatz konzentriert sich demgegenüber auf die Qualitäts- und Produktivitätssteigerung des gesamten Software-Entwicklungsprozesses. ISO 9000 und CMM sind keine Alternativen, sondern ergänzen sich. (Quelle: Balzert, Lehrbuch der Software Technik 2)

12 CMM und ISO 9000 (2000) Die ISO 9000 (2000) ist vor allem kunden- und prozessorientiert. Die ISO 9001 beschreibt Forderungen an Qualitätsmanagementsysteme. Die ISO 9004 ist ein Leitfaden zur Leistungsverbesserung mit dem Ziel der Exzellenz. CMM gibt Anregungen, wie dies für den Bereich Softwareengineering konkret erreicht werden kann.

13 ISO 9000 Im ISO 9000-Normenwerk werden allgemeingültige, branchenneutrale Minimal-anforderungen an ein Qualitätsmanagementsystem (QM-System) aufgestellt. Ein QM-System soll vollständig, dokumentiert, bekannt, überprüfbar, evolutionär und eingehalten sein. Dies wird in der Regel nur in mehreren Schritten (Reifestufen) erreicht. Beim Aufbau eines QM-Systems sind die betriebsinternen Prozesse zu erfassen und zu dokumentieren. Qualitätsrelevante Dokumente werden gesichert. Die Zuständigkeiten und Verantwortlichkeiten in der Aufbauorganisation werden erfasst. Anschließend erfolgt eine kritische Wertung des Istzustandes bezogen auf die Anforderungen der Qualitätssicherung. Meistens ist eine Anpassung der Ablauforganisation und eindeutige Festlegung von Zuständigkeiten und Befugnissen nötig. Die Qualitätsphilosophie des Unternehmens, die Dokumente und die Aktivitäten werden in einem Qualitätssicherungs-Handbuch dokumentiert. Nach der Einführung des QM-Systems erfolgt eine Funktions- und Wirksamkeitskontrolle zunächst durch ein internes Audit, dann durch ein externes Audit.

14 Ansätze zur Verbesserung des SE Prozesses
Total Quality Management – TQM Ganzheitliche, umfassende aber nicht klar abgegrenzte Unternehmensphilosophie, die das Ziel hat, die Prinzipien „Primat der Qualität“, „Zuständigkeit aller Mitarbeiter“, „ständige Verbesserung“, „Kunden-orientierung“, „internes Kunden-Lieferanten-Verhältnis“ und „Prozess-orientierung“ umzusetzen. Software Process Improvement and Capability Determination - SPICE Zweidimensionales Referenzmodell zur Bewertung und Verbesserung von Software-Prozessen, als ISO-Norm vorgesehen. Business Engineering Unternehmen und ihre Geschäftsprozesse werden in Abhängigkeit von ihren Zielen und Aufgaben ingenieurmäßig gestaltet, wobei alle Möglichkeiten der Informations- und Kommunikationstechnik genutzt werden.

15 Qualitätsentwicklung

16 Das Capability Maturity Modell (CMM)
1987 entwickelte das Software Engineering Institute (SEI) der Carnegie Mellon University im Auftrag des amerikanischen Verteidigungsministerium einen Fragebogen, mit dessen Hilfe die Leistungsfähigkeit von Software-Lieferanten bewertet werden sollte (Assessment). Der Fragebogen wurde zu einem Referenzmodell ausgebaut. Dieses Referenzmodell erhielt den Namen Capability Maturity Model (CMM). Den aktuellen Stand der Entwicklung findet man auf den Web-Seiten des SEI unter Publikationen. Das CMM gibt Hinweise, wie die Qualität des Software-Entwicklungsprozesse verbessert werden kann. Es werden fünf unterschiedliche Qualitätsstufen von Software-Entwicklungsprozessen unterschieden. Jede Qualitätsstufe beschreibt einen bestimmten Reifegrad (maturity) eines Entwicklungsprozesses. Die Stufen bauen aufeinander auf. Eine Stufe setzt voraus, dass die Anforderungen an die Prozesse, die die anderen Stufen erfordern, erfüllt sind.

17 Das Grundkonzept des Capability Maturity Modell

18 Reifegrade und Fähigkeiten im CMM (Übersicht)
Die Prozessqualität der Software-Entwicklung bestimmt die Fähigkeiten (capabilities) eines Software-Unternehmens. Im CMM werden 5 Reifestufen (maturity) unterschieden, deren Prozessqualität wie folgt charakterisiert ist: Stufe Bezeichnung Prozessqualität 1 initial abhängig von Einzelpersonen 2 repeatable diszipliniert 3 defined standardisiert und konsistent 4 managed vorhersagbar 5 optimizing kontinuierlich verbessert

19 Test Maturity Modell In Analogie zum CMM für die Verbesserung des Software Entwicklungsprozesses exsistiert ein Modell zur Verbesserung der Prüfvorgänge. Es hat 5 Stufen: Stufe Bezeichnung Testqualität 1 unsystematisch Test von Programmierern abhängig 2 organisiert Testpläne mit Whitebox und Blackbox Tests 3 kostensenkend Testplan durch QM vorgegeben greift in alle Phasen der Entwicklung 4 systematisch Tests mittels Tools Rückwirkung auf Prozess 5 optimierend Aus Testergebnissen werden Prozessänderungen abgeleitet

20 Wie beschreibt man ein Maturity Level -1
Maturity Levels contain Indicate Process capability Key Process Areas Die 5 Reifestufen werden durch Aktivitätsbereiche und Ergebnisse beschrieben. Aktivitätsbereichen sind Aufgabenbereiche und Ziele zugeordnet. Aufgabenbereiche setzen sich aus Workflows und Aktivitäten zusammen achieve Organized by Goals Common Features adress contain Implementation or Institutionalization Key Practices describe Infrastructure or Activitites

21 Wie beschreibt man ein Maturity Level -2
Key Process Area Aktivitätsbereiche, auf denen Organisationen im Rahmen der entsprechenden Reifegradstufen besondere Anstrengungen zur Verbesserung der Softwarequalität vornehmen sollten. Die Key Process Areas aufeinander folgender Stufen bauen aufeinander auf. Aktivitätsbereiche Die dem Bereich zugeordneten Ziele müssen in mehreren Projekten erfüllt sein, damit die durch die Key Process Area definierten Fähigkeiten institutionalisiert sind. Prozesskategorien Management, Organisation, Entwicklung

22 Wie beschreibt man ein Maturity Level -3
Common Features Jede Key Process Area ist in fünf Aufgabenbereiche (Common Features) untergliedert: Unterstützung der Durchführung: Definition von Leitlinien, Unterstützung durch das Management Fähigkeit zur Durchführung: Zuweisung von Ressourcen, Errichten von Organisationsstrukturen, Training Durchzuführende Aktivitäten: Beschreibung der Schlüsselaufgaben Bewertung und Analyse: Erhebung von Daten über die Umsetzung Überprüfung der Umsetzung: Überprüfung durch die Qualitätssicherung und das Management.

23 Wie beschreibt man ein Maturity Level -4
Key Practices Wichtigste Maßnahmen und Aktivitäten zur Erreichung der Ziele einer Key Process Area. Beschrieben wird das „Was“, nicht das „Wie“. Das „Wie“ ist aufgabenabhängig und Ergebnis des Tailoring hin auf eine konkrete Projektkultur.

24 Key Process Areas der verschiedenen CMM-Levels
Optimizing (5) Process change management Technology change management Defect prevention Managed (4) Software quality management Quantitative process management Defined (3) Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Repeatable (2) Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirement management Initial (1)

25 CMM - Stufe 1 Initial - „im Anfangsstadium“ - 1
Beschreibung Auf der Stufe initial herrscht weitgehend Chaos. Es gibt keine definierte Vorgehensweise bei der Software-Erstellung und -Wartung; weder werden Kostenschätzungen durchgeführt noch gibt es einen Projektplan. Werkzeuge sind nicht vorhanden oder kommen nur sporadisch zum Einsatz. Änderungen an der Software werden nicht dokumentiert und unterliegen keinerlei Kontrolle. Das Management versteht wenig von Software und mischt sich selten ein. Organisationen dieser Art vergessen in einem Krisenfall vieles, was sie bisher über einen organisierten Entwicklungsprozess gelernt haben, und fallen in alte Gewohnheiten zurück. Ziele: Das einzige Ziel dieser Stufe ist es, ein Projekt zum Abschluss zu bringen. Alternative Definition

26 CMM - Stufe 1 Initial - „im Anfangsstadium“ - 2
Anforderungen an die Organisation Organisationen auf der Ebene 1 müssen zunächst Projekt-management, Konfigurationskontrolle und Qualitätsmanagement einführen, wenn sie ihren Prozess verbessern wollen. Außerdem sind seitens der Geschäftsführung eine aktive Beteiligung und der feste Wille zur Verbesserung wichtige Voraussetzungen. Aktivitäten Einführung von Projektmanagement, Konfigurationskontrolle und Qualitätsmanagement Überprüfung des bisher angewandten SE Prozessmodelles Alternative Definition

27 CMM - Stufe 2 Repeatable - „reproduzierbar“ - 1
Beschreibung Die Stufe repeatable zeichnet sich gegenüber der Stufe 1 vor allem dadurch aus, dass ein einmal erzielter Erfolg wiederholbar ist. Projekte können also auf Grund vorheriger Erfahrungen geplant und durchgeführt werden. Während Organisationen der Stufe 1 im Einzelfall durchaus erfolgreich sein könnte, scheitern Projekte jedoch dann, wenn die fähigen und engagierten Schlüsselpersonen nicht verfügbar sind oder das Unternehmen verlassen. Auf Ebene 2 ist bereits ein definierter Prozess implementiert, der die Abhängigkeit von Einzelpersonen deutlich vermindert. Pläne, Zeit- und Kostenschätzungen werden von Organisationen auf dieser Ebene des QMM in der Regel eingehalten. Dies hat zum Teil seine Ursache darin, dass es sich immer wieder um vergleichbare Projekte handelt.

28 CMM - Stufe 2 Repeatable - „reproduzierbar“ - 2
Änderungen oder Störungen des SE Prozesses können alle bisher erreichten Erfolge zunichte machen, so dass der Prozess außer Kontrolle gerät. Zu erwähnen sind hier insbesondere: die Einführung neuer Werkzeuge, wenn sie nicht mit großer Sorgfalt geplant werden; große Änderungen in der Organisation, z.B. der Weggang eines fähigen Projektleiters, eine Veränderung in der Geschäftsleitung, der Einsatz eines unverhältnismäßig großen Anteils externer Mitarbeiter im Projekt; der Einstieg in ein völlig neues Arbeitsgebiet, bei dem sich das Umfeld der Software-Entwicklung fundamental ändert; ein sehr schnelles Wachstum des Unternehmens. Programme mit Quellcode-Zeilen erfordern eine völlig andere Organisation der Mitarbeiter und der Wartungsfunktionen als Software-Systeme in der Größenordnung von Quellcode-Zeilen.

29 CMM - Stufe 2 Repeatable - „reproduzierbar“ - 3
Ziele Institutionalisierung des Managementprozesses, um erfolgreiche Praktiken wiederverwendbar zu machen. Einführung von Meilensteinen, an denen Projektstand und Projekt-zwischenergebnisse mit den Kundenanforderungen verglichen werden können. Anforderungen an die Organisation Zum Aufstieg von Ebene 2 auf Ebene 3 hat sich die Einrichtung einer Software-Prozess-Gruppe (Software Engineering Process Group) sehr bewährt. Dies ist eine Gruppe von engagierten, fachkundigen Mitarbeitern, die sich speziell dieser Aufgabe widmen. Weiterhin ist es notwendig, den Software-Entwicklungsprozess formell zu definieren und festzuschreiben. Alternative Definition

30 CMM - Stufe 3 Defined - „definiert“ - 1
Beschreibung Der Software-Prozess ist bei Unternehmen der Stufe 3 standardisiert und konsistent, weil sowohl die Aktivitäten des SW-Engineerings als auch die des SW-Managements stabil und reproduzierbar sind. Innerhalb einer Produktlinie sind Kosten, Zeitpläne und Funktionalität unter Kontrolle und die Ziel-Qualität wird eingehalten. Im Fall einer Krise werden bewährte Vorgehensweisen beibehalten. Ziele Quantitative Kontrolle der Prozesse Identifikation von Abweichungen Entwicklung eines quantitativen Verständnisses für Prozess- und Produktqualität

31 CMM - Stufe 3 Defined - „definiert“ - 2
Anforderungen an die Organisation Obwohl der definierte Prozess eine solide Ausgangsbasis für weitere Verbesserungen bietet, gibt es auch auf dieser Ebene weiterhin nur qualitative Aussagen. Zwar arbeitet der Prozess weitgehend einwandfrei, doch es fehlen geeignete Kennzahlen, um den Prozess einordnen und weitere Maßnahmen anhand konkreter Messwerte vorschlagen zu können. Es ist in Organisationen dieser Ebene schwierig, zwei Projekte miteinander zu vergleichen, da die konkreten Kennwerte fehlen. Aktivitäten Der Weg von Ebene 3 zur nächst höheren Ebene führt über Metriken. Dazu ist es notwendig, eine Reihe vorher definierter Messwerte im Software-Entwicklungsprozess zu definieren und zu erfassen. Alternative Definition

32 CMM - Stufe 4 Managed - „beherrscht“ - 1
Beschreibung Produktivität und Qualität werden als Teil eines Messprogramms für wichtige Prozessaktivitäten über alle Projekte hinweg erfasst. Variationen in der Leistungsfähigkeit von Prozessen werden auf besondere Umstände zurückgeführt. Entsprechende Maßnahmen können eingeleitet werden (z.B. Tayloring) Ziele Die Qualität von Software-Produkten dieser Stufe ist vorhersagbar und hoch. Die Software-Prozessfähigkeit von Unternehmen der Stufe 4 kann als quantifizierbar und prognostizierbar bezeichnet werden. Genaue Aussagen über Zeit- und Kostenziele werden möglich

33 CMM - Stufe 4 Managed - „beherrscht“ - 2
Anforderungen an die Organisation Zwischenphasen im SE-Prozess sind auch für andere Gruppen (Management, Kunde) transparent Korrekturen des SE-Prozesses auf Basis quantitativer Erkenntnisse möglich Aktivitäten Es wird eine unternehmensweite Prozessdatenbank zur Sammlung und Analyse verfügbarer Daten definierter Prozesse geführt. Alternative Definition

34 CMM - Stufe 5 Optimizing - „optimiert“ - 1
Beschreibung Auf dieser Stufe ist die gesamte Organisation auf kontinuierliche Prozessverbesserungen ausgerichtet. Daten über die Wirksamkeit von Prozessen sind zur Durchführung von Kosten-Nutzen-Analysen und zur Empfehlung von Prozessänderungen verfügbar. Innovationen, welche die besten Software Engineering Praktiken ausnutzen, werden identifiziert und unternehmensweit eingeführt. Das Management kann seine Entscheidungen nunmehr auf Zahlen, Statistiken und Schaubilder abstützen. Alternative Definition

35 CMM - Stufe 5 Optimizing - „optimiert“ - 2
Ziele Eine gezielte Einflussnahme auf den Prozess der Software-Erstellung ist möglich. Vorgehen und Planung aufgrund von Mutmaßungen und Schätzungen sind auf dieser Ebene nicht mehr notwendig. Prozesssteuerung ist möglich. Organisatorische Anforderungen Organisation der gesamten Software-Produktion für alle Beteiligten transparent Änderungen des Entwicklungsprozesses können kontrolliert in den Standard-Entwicklungsprozess übernommen werden Neue Techniken können bewertet und bei Nützlichkeit für ein Projekt eingeführt werden

36 People Capability Maturity Model
Neben dem CMM, welches primär zur Verbesserung des Entwicklungsprozesses eingesetzt wird, existiert mit dem People Capability Maturity Model (P-CMM) ein Mittel zur Verbesserung des Personalmanagements bei der Software-Entwicklung. Es hat folgende Ziele: Erhöhung der Fähigkeiten des Unternehmens durch Erhöhung der Fähigkeiten der Entwickler Die Fähigkeit, Software zu entwickeln, wird der organisationalen und nicht individuellen Ebene angesiedelt Motivierung von Mitarbeitern Halten von wichtigen Mitarbeitern im Unternehmen

37 Entwicklung kleiner Systeme - Der PSP
Sehr eng mit dem CMM hängt der PSP (Personal Software Process) zusammen. Der PSP ergänzt das organisationsweite CMM um eine individuelle Prozessverbesserung. persönliches Management bedeutet, dass alle Schritte innerhalb des PSP vom Entwickler selbst durchgeführt werden müssen. Auch die Key Process Areas lassen sich mit dem PSP abdecken. Repeatable: Projektplanung und -überwachung, Standardisierung durch Grundprozess (PSP1) Defined: Reviews, Prozessdefinition, Produktentwicklung, Qualitätsmanagement, Quantitatives Prozessmanagement durch qualitätsorientierte Entwicklung (PSP2). Optimizing: Fehlervermeidung durch zyklische Entwicklung (PSP3)

38 Strategie zur Umsetzung des PSP
Zur Umsetzung des PSP wird eine mehrstufige Strategie vorgeschlagen. Identifikation von Methoden und Techniken für große Systeme, welche auch für den persönlichen Gebrauch verwendet werden können Definition einer Untermenge der gefundenen Methoden und Techniken für die Entwicklung kleiner Systeme Strukturierung der Methoden für eine schrittweise Einführung Bereitstellung von Übungen für die Methoden

39 Durchführung des PSP Der Personal Software Process wird anhand von Skripten durchgeführt. Diese Skripte enthalten die für einzelne Aufgabenbereiche nötigen Anweisungen. Die Aufgabenbereiche werden schwerpunktmäßig Phasen (Reifegraden) zugeordnet. Folgende Phasen werden unterschieden: Prozesssteuerung (PSPO) Planung (PSP1) Software-Entwicklung (PSP2) Auswertungen (PSP3)

40 Der Grundprozess: PSPO
Die erste Phase ist folgendermaßen charakterisiert: Verwendung des aktuellen Prozesses (z.B. Wasserfall) als Basis Einführung grundsätzlicher Größenmessungen Benutzung eines einfachen Rahmenwerks zur Erstellung kleiner Programme Die Verbesserung des Prozesses wird durch die Aufzeichnung von Problemen und den Vorschlag von Änderungen eingeleitet. Dabei werden meist kleinere Änderungen vorgenommen (z.B. Anpassung der Struktur), um mit dem PSP kompatibel zu sein.

41 Metriken für den Grundprozess
Um eine Prozessverbesserung erzielen zu können, sind u.a. Aussagen über den aktuellen Prozess und das erstellte Programm nötig: Erfassung der Programmgröße (hauptsächlich Zeilenzahl, da weit verbreitet und signifikante Korrelation zum Entwicklungsaufwand) Erfassung der Arbeitszeit pro Phase Erfassung von Fehlern, die während der Entwicklung gemacht und behoben werden Sammeln der erfassten Zeiten und Fehlerinformation über mehrere Projekte hinweg

42 Ressourcen- und Ablaufplanung: PSP1
Im PSP1 wird zusätzlich zu den klassischen Phasen eine Planungsphase eingeführt. Alle Phasen werden zeitlich erfasst. Ziel ist die Einrichtung eines wiederverwendbaren Prozesses zur Schätzung von Ressourcenbedarf und Zeitaufwendungen. Die Hauptressource im PSP ist die Zeit. Zur Abschätzung des Zeitbedarfs werden folgende Daten herangezogen: Vergangenheitsdaten für die Produktivität (Zeilen pro Stunde) geschätzte Programmgröße Vergangenheitsdaten für die aufgewendete Zeit In der Ablaufplanung wird die Zeit pro Phase abgeschätzt, wobei hier zwischen Zeitbedarf, welcher von der Programmgröße abhängt und unabhängigem Zeitbedarf, unterschieden werden muss.

43 Metriken für den Entwicklungsprozess
Die Überwachung des Entwicklungsprozesses wird mittels eines einfachen Indikators vorgenommen: Der Anteil einer Aufgabe am Gesamtzeitbedarf des Projekts wird errechnet, der Projektfortschritt ist gleich der Summe der bereits erledigten Anteile der geplante Fortschritt wird mit dem tatsächlichen Fortschritt verglichen bei groben Abweichungen müssen die geplanten Werte angeglichen werden Zur Größenabschätzung wird die Zeilenzahl betrachtet. Möglichkeiten zur Abschätzung durch Experten in mehreren Runden. Einteilung in grobe Kategorien aufgrund von Vergangenheitsdaten Aufteilung des Programmes in Eingaben, Ausgaben, Anfragen, benutzte Dateien/Datenbanktabellen und externen Schnittstellen Abschätzung anhand von Proxies (Stellvertretern), z.B. Programm- Objekten

44 Entwurf und Implementierung von Software: PSP2
Der Entwurf erfolgt in 4 Schritten, die aber nur selten linear durchlaufen werden: Sammeln von Benutzeranforderungen Analyse der Anforderungen Erstellen eines High-Level Designs Verfeinerung des Designs Das Ergebnis des Entwurfs wird dokumentiert. Die Dokumentation soll die genaue Funktion des Programmes beschreiben. Folgende Gesichtspunkte sind zu beachten: Beschreibung von Funktionen mittels Vorbedingungen und daraus resultierenden Aktionen (Funktionale Beschreibung) Beschreibung der Interaktion des Benutzers mit dem Programm z.B. durch Use Cases (Operationale Beschreibung) Beschreibung der Programm- oder Objektzustände (Zustandsbeschreibung) Beschreibung von Funktionen mittels Pseudocode (Logische Beschreibung)

45 Metriken für Entwurf und Implementierung
Fehler sollten möglichst früh vermieden werden. In dieser Phase sind dazu Prüfungen gegenüber Anforderungen in Form von Reviews hilfreich. Anforderunges-Reviews: Prüfung des Designs gegen die Anforderungen und evtl. Einholen von weiteren Anforderungdsdaten Überprüfung von Syntax, Namensgebung, Speichermanagement, Funktionsaufrufen Überprüfung auf Komplettheit, Programmlogik, Sonderfälle Für die Reviews sind Code- und Design-Standars zu entwickeln. Gegen diese kann dann geprüft werden

46 Zyklische Prozesse: PSP3
Mit PSPO bis PSP2 lassen sich Programme bis ca Zeilen bewältigen. Für die Entwicklung größerer Programme muss das Gesamtsystem in handhabbare Einheiten zerlegt werden. Sie können dann nacheinander oder von einem Team parallel abgearbeitet werden. Der Entwicklungsprozess wird dazu aufgeteilt: Eine Planungs- und High-Level-Design-Phase sowie daran anschließend mehrere untergeordnete Phasen (zyklischer Prozess). Jeder Zyklus besteht aus einem kompletten PSP2-Prozess. Folgendes ist zu beachten: Jeder Zyklus muss komplett und korrekt abgeschlossen sein (hohe Bedeutung für Design- und Code-Reviews) Regressions-Tests sichern die Korrektheit aller Komponenten bei fortlaufenden Änderungen die im Zyklus bearbeiteten Änderungen sollten ca. 100 bis 300 Zeilen neuen und geänderten Code enthalten Der PSP3 ist eine leicht praktizierbare Vorstufe des Rational Unified Process (RUP).

47 Links zu CMM Informationen zum CMM http://www.sei.cmu.edu/cmm/cmm.html
Informationen zum P-CMM Informationen zum Software Risk Management Informationen zum PSP Informationen zu SEPT (Software Engineering Process Technology) mit Liste der Standards und Normen zum Softwareengineering

48 Literatur Thaller, Georg Erwin: ISO9000 – Software-Entwicklung, Heise Verlag; Hannover, 2000 Balzert, Helmut: Lehrbuch der Software-Technik; Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag Heidelberg, Berlin. 1998 Thaller, Georg Erwin: Software- und Systementwicklung Heise Verlag, Hannover, 2002

49 Danksagung B. Hohler: Software-Qualitätsmodelle Informatik Spektrum 18, p. 324 (1995) Banford, R.C., Deibler II W.J., Comparing, contrasting ISO 9001 and the SEI capability maturity model, in: Computer, Oct. 1993, pp Aus folgenden Vorlesungen und Foliensammlungen aus dem Bereich Softwaretechnik konnten wir Anregungen zur Gestaltung dieses Lernmoduls gewinnen: P.Göhner IAS Vorgehensmodell IAS Universität Stuttgart

50 Tailoring Tailoring bedeutet ungefähr: „Maßschneidern“ (Balzert S. 109) Tailoring ... bedeutet, dass man für jedes Projekt und jede Art von Software eine bestimmte Untermenge von Verfahren und Software-Produkten auswählt. Man kann auch Reviews in ihrer Zahl begrenzen oder ausweiten oder im Einvernehmen mit dem Kunden festlegen, dass bestimmte Software-Produkte nicht an den Auftraggeber ausgeliefert werden. (Thaller-ISO9000 – S. 193) Ziel des Tailorings ist es, eine übermäßige Papierflut sowie sinnlose Dokumente zu vermeiden, auf der anderen Seite aber zu verhindern, dass wichtige Dokumente fehlen. (Balzert S. 110) zurück

51 Metrik „Eine Software-Metrik definiert, wie eine Kenngröße eines Software-Produkts oder eines Software-Prozesses gemessen wird.“ (Balzert, S.225) „Eine Messung zu Kenngrößen der Software oder deren Entwicklung, die in der statistischen Auswertung eine quantitative Aussage erlaubt.“ (Thaller, S.350) zurück

52 Initial Prozess Es gibt wenige stabile Prozesse, und falls sie auf dem Papier existieren, werden sie nicht eingesetzt. Mitarbeiter Der Erfolg basiert auf den heroischen Anstrengungen einzelner Mitarbeiter. Krisenbewältigung (Fire Fighting) ist eine immer wieder auftretende Tätigkeit. Die Beziehungen zwischen verschiedenen Gruppen sind unkoordiniert, manchmal sogar feindselig. Technologie und Werkzeuge Es ist riskant, neue Werkzeuge einzuführen, denn es könnte alles zusammenbrechen. Matriken Datenerfassung, so weit sie überhaupt durchgeführt wird, ist eher zufällig. Sie folgt keinem Plan und wird zwischen verschiedenen Projekten nicht koordiniert. zurück

53 Repeatable Prozess Projekte werden geplant. Dazu werden Kosten- Zeitschätzungen abgegeben. Probleme werden nicht geleugnet, sondern korrigiert, wenn sie auftreten. Mitarbeiter Der Erfolg des Unternehmens beruht weiterhin auf fähigen Miterbeitern. Das Management sorgt dafür, dass diese Mitarbeiter gute Arbeitsbedingungen vorfinden. Verpflichtungen der Mitarbeiter werden verstanden. Änderungen werden vom Management verfolgt. Mitarbeiter werden für ihre Aufgaben geschult. Technologie und Werkzeuge Der Prozess wird durch den Einsatz von Werkzeugen unterstützt. zusammenbrechen. Matriken Einzelne Projekte erfassen Daten und werten sie aus. zurück

54 Defiened Prozess Sowohl für die technische Softwareerstellung als auch deren Management sind Prozesse definiert und werden angewandt. Bei der Softwareentwicklung wird mit Problemen gerechnet. Die Auswirkungen von Problemen und Änderungen werden minimiert. Mitarbeiter Einzelne Gruppen arbeiten zusammen, etwa in der Form einer integrierten Projektgruppe. Schulungen werden geplant und entsprechend den Aufgaben der Mitarbeiter durchgeführt. Technologie und Werkzeuge Neue Werkzeuge werden auf der Basis ihres Werts für das Unternehmen evaluiert und gegebenenfalls eingeführt. Matriken Für alle definierten Prozesse werden Daten erfasst und ausgewertet. Die Projekte tauschen Daten aus. zurück

55 Managed Prozess Die Prozesse werden quantitativ beurteilt. Dadurch können Abweichungen minimiert werden. Mitarbeiter Die Teamarbeit wird geschätzt. Technologie und Werkzeuge Neue Werkzeuge werden auf der Basis ihres Werts für das Unternehmen evaluiert und gegebenenfalls eingeführt. Matriken Die Datenerfassung wird über die gesamte Organisation hinweg vereinheitlicht. Die Auswertung der Daten und die Matriken werden eingesetzt, um den Prozess quantitativ beurteilen zu können und Fehler und Abweichungen zu minimieren. zurück

56 Optimizing Prozess Prozessoptimierung wird kontinuierlich durchgeführt. Gemeinsame Ursachen von Problemen werden gefunden und eliminiert. Mitarbeiter Innerhalb der gesamten Organisation entsteht ein Gefühl der Zusammengehörigkeit. Alle Mitarbeiter tragen dazu bei, den Prozess zu verbessern. Technologie und Werkzeuge Neue Werkzeuge werden selbst dann untersucht, wenn zunächst kein Nutzen für das Unternehmen erkennbar ist. Dazu werden Pilotanwendungen zu verbessern. Matriken Matriken werden eingesetzt, um den Prozess zu verbessern. zurück