1

Prozessverbesserung

Sven Holzmann

Jochen Schwarz

2

2

Inhalt

CMM(I)EinführungReifegradeStatistische DatenStudie

PSPEinführungProzessebenenStudie

ISO 15504EinführungISO 12207SPICEStudie

Resümee

3

3

Historie

•1986 SEI beginnt mit der Entwicklung eines Systems zur Bewertung von Softwareprozessen

•1991 CMM 1.0•1993 überarbeitetes CMM 1.1•1997 CMM 2.0 kurz vor der Verabschiedung zurückgezogen

statt dessen CMMI – Projekt gestartet•2000 CMMI Pilotversion 1.0•2002 CMMI 1.1 freigegeben•2003 Unterstützung für CMM ausgelaufen•2005 CMMI 1.2 angekündigt

Lizenzen der Assessmentleiter für CMM laufen aus•2006 Herbst: Erscheinungstermin CMMI 1.2 •2007 CMMI 1.1 läuft aus

CMM(I)

Das Software Engineering Institute (SEI) der Carnegie Mellon University/Pittsburgh untersteht dem US-Verteidigungsministeriums (Department of Defense, DoD). Die Entwicklung des Bewertungssystems begann durch eine Initiative des DoD.In der Pilotversion 1.0 steht das I für „Integrated“. Später wurde dies durch Integration ersetzt.Da die Lizenzen der Assessmentleiter ausgelaufen sind gibt es nun keine offiziellen CMM – Assessments mehr.

4

4

CMM

Framework zur ProzessverbesserungAbstrakte FormulierungKonkrete Implementierung der Firma überlassen

StufenmodellBewertung von Organisationen durch ausgebildete AssessorenUnterscheidet in ausgereifte und unausgereifte Organisationen

CMM(I)

5

5

Unausgereifte Organisationen

Können ausgezeichnete Ergebnisse erzielenDurch „heldenhafte“ Taten von IndividuenReproduzierbarer Erfolg wenn „die gleichen Individuen das gleiche tun“

Qualitätsmessung nicht vorhandenQualität schwer vorauszusagen

Reagieren auf Gegebenheiten

Aktivitäten zur Qualitätsverbesserung fallen weg

CMM(I)

6

6

Ausgereifte Organisationen

Reproduzierbarer Erfolg

Organisationsweiter, wiederholbarer, standardisierter SoftwareprozessWird zu Angestellten und neuen Mitarbeitern kommuniziertPräskriptiv = deskriptivWird verbessertVerbesserungen werden getestet

Objektive QualitätsmessungProblemanalyse

Produkteckdaten können vorhergesagt werdenVorhersagen treffen ein

CMM(I)

Präskriptiv: Beschreibt den vorgegeben ProzessDeskriptiv: Beschreibt den tatsächlich durchgeführten Prozess

Produkteckdaten: Kosten, Zeit, Funktionalität, Qualität

7

7

Konzepte

ProzessleistungsfähigkeitZu erwartende Ergebnisse, die durch den Prozess erreicht werden können

ProzessleistungErgebnisse, die durch Prozess erreicht werdenUngleich Leistungsfähigkeit, z.B. durch Umgebung begrenzt

ProzessreifeAusmaß, zu dem Prozess definiert, geleitet, kontrolliert und effektiv istImpliziert Verbesserungspotential der LeistungsfähigkeitWird durch CMM gemessen

CMM(I)

Die Messung der Reife erfolgt in sog. Assessments. Zur Messung wird ein System aus 5 evolutionären Stufen verwendet.

8

8

Reifelevel/Reifegrad

Initial (1)

Repeatable (2)

Defined (3)

Managed (4)

Optimizing (5)

Diszipliniert

Standardisiert und konsistent

Vorhersagbar

Kontinuierlich verbessernd

CMM(I)

Repeatable: wiederholbarDefined: definiertManaged: geleitetOptimizing: verbessernd

9

9

Initial

Prozess ist ad hoc, bisweilen chaotisch

Wenige/keine Prozesse definiert

Erfolg durch persönliche AnstrengungEckdaten nicht vorhersehbar

Keine stabile EntwicklungsumgebungGute Engineering – Praktiken haben unbestimmte ErgebnisseUnbestimmte Planung und reaktionsgetrieben

Krisen: Code & FixErfahrene Teamleiter widerstehen der VersuchungErfahrung geht mit dem Teamleiter

CMM(I)

10

10

Repeatable

Projekt Management Prozesse eingeführtKosten, Zeitplan und Funktionalität werden verfolgtProbleme der Einhaltung werden erkannt

Projektplanung und -leitung basieren auf Erkenntnissen

Effektiver Prozesserfahren, dokumentiert, erzwungen, trainiert, gemessen, verbesserungsfähig

Standards für Prozesse eingeführtEinhaltung wird kontrolliert

Instabil

CMM(I)

Ein Softwareprozess des Reifegrades 2 wird als instabil beschrieben. Es wird sich zeigen, ob die Verbesserungen gegenüber des Grades 1 nur aufgesetzt sind oder ob sie tatsächlich verinnerlicht wurden. Je nachdem wird der Prozess mittelfristig auf Grad 3 aufsteigen oder auf Grad 1 zurückfallen. Der Reifegrad 2 ist der einzige der 5 Reifegrade, auf den diese Beschreibung zutrifft.

11

11

Defined

StandardprozessOrganisationsweit, standardisiert und dokumentiertBeinhaltet Prozesse für Management und EngineeringEffektive SE – Praktiken berücksichtigtEinsicht des Managements in den technischen Fortschritt der Projekte

Zugeschnittener ProzessPro Projekt

Software Engineering Process Group (SEPG)Kümmert sich um Prozessaktivitäten der Organisation

TrainingsprogrammPersonal und Management haben das Wissen und die Fähigkeit für ihre Rollen

CMM(I)

SE: Softwareengineering

12

12

Managed

Organisationsweites MessprogrammMessergebnisse von Softwareprozess und Produktqualität vorhandenProzesse und Produkte sind quantitativ verstanden und kontrolliertQuantitative Ziele für Prozesse und Produkte

DatenbankEnthält Messergebnisse zu spezialisierten Prozessen

CMM(I)

13

13

Optimizing

Beständige ProzessverbesserungKonzentration der Organisation auf Verbesserung

ProzessbewertungFeedback nach Prozess – VeränderungInnovative Ideen und Techniken in PilottestsOrganisation erkennt Stärken und Schwächen von Prozessen

ProzessanalyseEffektivitätsdaten zur Kosten/Nutzen Rechnung von neuen Technologien

Erfolgreiche Innovationen werden in der Organisation verbreitet

CMM(I)

14

14

Levelverteilung

Nur sehr wenige Organisationen auf Level 4 und 5Charakteristiken schwer feststellbarAnalogie zu anderen Industriezweigen

Sobald mehr Daten vorhanden:Anpassung der Definition von Level 4 und 5

CMM(I)

15

15

Schlüsselgebiete

Auch Schlüsselprozesse

Bestimmen, auf was sich die Organisation konzentrieren soll

Für jeden Level gibt es SchlüsselgebieteWerden alle abgedeckt, so wird der Level erreicht

Gebiete definieren ZieleWenn die Ziele erreicht sind, ist das Gebiet abgedecktZiele werden am besten durch Schlüsselpraktiken erreicht

CMM(I)

16

16

Reifelevel/Reifegrad

Initial Repeatable Defined Managed Optimizing•SW configurationmanagement•SW qualityassurance•SW subcontractmanagement•SW projecttracking and oversight•SW projectplaning•Requirementsmanagement

•Peer reviews•Intergroupcoordination•SW productengineering•Integrated SWmanagement•Trainingprogramm•Org. processdefinition•Org. processfocus

•SW qualitymanagement•Quantitativeprocessmanagement

•Process changemanagement•Technologychangemanagement•Defectprevention

CMM(I)

Repeatable: wiederholbarDefined: definiertManaged: geleitetOptimizing: verbessernd

17

17

Beispiel Schlüsselgebiet

Software KonfigurationsmanagementVorraussetzung für Level 2 (Repeatable)

ZieleSoftware Konfigurationsmanagement Aktivitäten sind geplantAusgewählte SW – Arbeitsprodukte sind identifiziert, kontrolliert und verfügbarÄnderungen an identifizierten SW – Arbeitsprodukten sind kontrolliertBetroffene Gruppen und Individuen sind informiert über den Status und Inhalt der SW - Grundlinie

CMM(I)

18

18

Statistische Daten zu CMM

Process Maturity Profile – Software CMM 2003 Year End UpdateJährliche Studie vom SEIhttp://www.unf.edu/~ncoulter/cen6070/handouts/2004marSwCMM.pdf

CMM(I)

19

19

Durchgeführte Assessments

CMM(I)

20

20

Verteilung der Reifegrade

1999 – 2004 : 1593 Organisationen

CMM(I)

21

21

Trend des Reifegrades

CMM(I)

22

22

Reifegrad bei erstem und letztem Assessment

598 Organisationen mit mindestens 2 Assessments

CMM(I)vv

23

23

Von CMM zu CMMI

CMMEigentlich: CMM – SWModell zur Verbesserung von ProzessenDaneben: CMM – SE, CMM – People, CMM – Team, etc.Stufenmodell

CMM(I)

24

24

Von CMM zu CMMI

CMMIIntegration: Vereinheitlicht die einzelnen CMM‘sVerwendung der Erfahrungen mit CMMSehr abstrakte Punkte wurden (etwas) konkretisiert

Modell 1: StufenmodellÄhnlich wie bei CMMNeue Levelbezeichnungen: Managed (2) und Quantitatively Managed (4)Neue Schlüsselgebiete, Aufteilung von Gebieten, Entfernung von SW vor Gebietsbezeichnungen

Modell 2: kontinuierliches ModellVergleich zu SPICEProzessbereiche werden von 0 bis 5 bewertet

CMM(I)

CMMI verwendet 2 verschiedene Bewertungsmodelle. Das Stufenmodell erlaubt den Vergleich mit CMM, das kontinuierliche Modell ermöglicht den Vergleich mit SPICE.

25

25

Beschreibung

Umfrage bei mehreren Firmen aus USA und KanadaAssessments durchgeführt 1992 und 1993Assessments liegen zwischen 1 und 3 Jahren zurückZusammenstellung der Teilnehmer September 1994155 Firmen aus PAIS61 Firmen kontaktiert (40%)1/3 der Firmen mit mehr als 200 Mitarbeitern1/3 der Firmen mit weniger als 70 Mitarbeitern

CMM(I)

PAIS: Process Appraisal Information SystemDatenbank des SEI, die Daten über bisher durchgeführte Assessments enthält.

26

26

Teilnehmer

Befragt wurdenProjektmanagerSenior developer mit der meisten ErfahrungSEPG Manager auf Organisationsebene (falls vorhanden)(Senior Manager = Sponsor des Assessments)

167 Personen für 61 Assessments

138 Fragebogen vollständig ausgefüllt (85%)Gehören zu 56 Assessments (92%)

CMM(I)

SEPG: Software Engineering Process GroupSenior Manager: Wurden in dieser Studie nicht befragt, da die Fragen eher technischer Natur waren.

Alle Teilnehmer sollten mit dem durchgeführten Assessment vertraut sein.

27

27

Ziele

Was passiert typischerweise nach einem CMM AssessmentBezogen auf Prozessverbesserungen

Verstehen, warum manche Verbesserungsanstrengungen besser sind als andere

Den Zusammenhang zwischen Reifegrad und Performance der Organisation erkennenInteressanteste Ziel

CMM(I)

28

28

Fragebogen

Fragen so zusammengestellt, dass Sichten bedeutungslos werdenEntwickler sehen Dinge anders als Manager

75 Fragen in 4 Kategorien

CMM(I)

Die Kategorien und ihre Aufteilung waren wie folgt:•Das Assessment: 13 Fragen•Prozessverbesserung: 39 Fragen•Die Organisation: 18 Fragen•Persönlicher Hintergrund: 5 FragenDer komplette Fragebogen findet sich im Anhang von [2].

29

29

Ergebnisse

Kaum Unterschiede zwischen verschiedenen RollenGuter Fragebogen

Prozessverbesserung zahlt sich durch bessere Organisationsperformance ausWahrscheinlichkeit zur guten Einschätzung von Performance steigt

Kein erheblicher Einfluss vonOrganisationsbereich (Regierung/Verteidigung und andere)Organisationsgröße

CMM(I)

Prozessverbesserung zahlt sich durch bessere Performance der Organisation aus: Diese Annahme wurde nach Auswertung von 2 Fragen getroffen. Der Teilnehmer wurde nach einer Einschätzung des aktuellen CMM Levels gefragt. Danach wurde die Einschätzung verschiedener Performanceindikatoren erfragt (Zeiteinhaltung, Einhaltung von Budget, Produktqualität, Mitarbeiterproduktivität, Kundenzufriedenheit, Mitarbeitermoral). Bei Firmen mit höherer Leveleinschätzung wurden die Fragen nach der Performance häufiger mit gut oder exzellent beantwortet.

In Organisationen, die nicht für Regierung oder Verteidigungsministerium arbeiten, ist CMM noch nicht so lange eingeführt.

30

30

Positive Reaktionen

Assessments sind sehr genau und nützlich um nachfolgende Anstrengungen zur Prozessverbesserung zu leitenAnstrengungen werden größtenteils durch CMM Einschätzung bestimmtNur 10% denken, dass aufgrund von CMM wichtige Verbesserungen vernachlässigt wurden

Bewertung durch CMM zeigt Stärken und Schwächen der Organisationauf

Manager können aktiv den Fortschritt der Prozessverbesserung aufzeigenKönnen deren Ziele benennenPassende Ressourcen auswählen

CMM(I)

31

31

Negative Reaktionen

¼: Es hat sich nicht viel getan

¼: Empfehlungen zu ehrgeizigIn angemessener Zeitspanne kaum zu erreichenDiese Firmen führten weniger Verbesserungen durch

40%: Krisen führten zu Vernachlässigung von Verbesserungen

Fast ¾: Verbesserung leider an Mangel von Zeit und Ressourcen

Über ¾: Verbesserungen brauchen länger als erwartet

Über 2/3: Verbesserungen kosten mehr als erwartet

CMM(I)

32

32

Bewertung

Keine KontrollgruppeNur Firmen aus CMM Datenbank befragt

Nur 7 Fragen zur Performance

Eigene Einschätzung zur Reife wird bewertetAusgereift Unausgereift vs. Optimistisch Pessimistisch

Alter der Studie

Zeigt: CMM führt zu VerbesserungsanstrengungenValidierung Verifikation

Vom SEI selbst durchgeführt

CMM(I)

Die Interpretation der Interviewer lautet, dass ausgereifte Firmen eine bessere Performance melden. Eine andere Interpretation wäre, dass Optimistische Personen bessere Performance berichten. Diese würden auch eine höhere Einschätzung der Reife liefern.

Die Studie wurde 1995 durchgeführt. Wie man den statistischen Daten entnehmen kann, hat sich die Verteilung der Reifegrade seither Grundlegend verschoben.

Die Studie verifiziert CMM. Das Assessment scheint sich tatsächlich dazu zu eignen, Prozessverbesserungen (im Sinen von CMM) anzustoßen. Ignoriert wird die Validierung, d.h. wie ist die Korrelation Reifegrad/Performance.

33

33

PSP – The Personal Software Process

Idee von Watts Humphrey (1995):

Anwendung der Prozessverbesserung auf den einzelnen ProgrammiererProzessmanagement und Kontrolle auf individueller Ebene

Eigenschaften• Definierter Prozess• Planen• Messen• Überwachen

PSP

Idee: Das Prinzip der Prozessverbesserung ist gut, da Die Software letzten Endes aber von einzelnen Personen erstellt wird, ist es wichtig, dass auch diese PersonenEinen „guten“ Prozess haben.Eigenltich für die Planung und Entwicklung von Softwaremodulen und kleineren Programmen gedacht, kann aber auch auf andere individuelle Aufgaben angepasst werden.

34

34

PSP – Prozessebenen

The Baseline Personal ProcessThe Baseline Personal Process

Personal Project ManagementPersonal Project Management

Personal Quality ManagementPersonal Quality Management

Cyclic Personal ProcessCyclic Personal Process

PSP0PSP0 PSP0.1PSP0.1

PSP1PSP1 PSP1.1PSP1.1

PSP2PSP2 PSP2.1PSP2.1

PSP3PSP3

PSP

Die einzlenen Prozessebenen bauen aufeinander auf und werden dementsprechend auch in einem Kurs gelehrt.Ähnlich wie bei CMM/ISO 15504 wird die Vorgehensweise zunehmend strukturierter

35

35

PSP – The Baseline Personal Process

PSP0

PSP0.1Prozessverbesserungsvorschläge

Zeit, Fehler und Größenangaben protokollierenPostmortem6

Testen, Fehler entfernen und protokollierenTest5

Kompilieren, Fehler entfernen und protokollierenCompile4

Implementieren des DesignsCode3

Entwerfen des ProgrammsDesign2

Planen und DokumentierenPlan1

DescriptionPhaseStep

PSP

36

36

PSP – Personal Project Management

PSP 1Größen- und Auwandsabschätzung

PROBE (Proxy-Based Estimating)

PSP 1.1Planung und Überwachung

Earned Value Methode

PSP

Bei PROBE wird ein „Proxy“ geschätzt (z.B. ein Objekt):•Kategorisierung der Objekte•Bestimmung der relativen Größe (very small, small, medium, large, very large)•Konvertierung in LOC anhand von Daten die in vorigen Projekten gesammeltwurden•Aufsummierung der Größen über alle Objekte•Vorhersage mittels linearer Regression

Earned Value:•Zuweisung eines Wertes (value) zu jeder Aufgabe (nach Anteil am Gesamtaufwand)•Wird eine Aufgabe erledigt, wird ihr Wert ein earned value

Darüberlässt sich der momentane Stand des Projektes überprüfen

37

37

PSP – Personal Quality Management

PSP2• Design Reviews• Code Reviews• Maße für die Prozess- und Produktqualität

PSP2.1• Design Notation• 4 Designvorlagen• Techniken zur Verifizierung des Designs

PSP

Ziel ist, alle Fehler schon vor dem ersten Kompilieren zu findenYield: Prozentualer Anteil der vor dem Kompilieren gefundenen Fehler an den gesamten Fehlern

Design/Code Review: selbstständig durchgeführt, strukturiert, datengetrieben, mit Checklisten (aus persönlicher „Fehler-Geschichte“)

Design: Abschätzen der verursachten/beseitigten Fehler

Implementierung: Vergleich der verursachten/beseitigten Fehler mit den geplanten Werten. 60%-70% Yield können erreicht werden

PSP2.1Sichten (Spzifikationen): •Abläufe•Funktionen•Zustände•Logik

38

38

PSP – Cyclic Personal Process

PSP3• High-Level Design• High-Level Design Review• Planung von Zyklen• Zyklen in der Entwicklung

PSP

PSP3:Die Produktivität eines Entwicklers ist am höchsten bei Programmen/Modulen deren Größe in einem bestimmten Bereich liegt.•Darüber leidet die Qualität (der Prozess skaliert dann nicht mehr gut)•Darunter leidet die Produktivität (wegen festen Kosten, die durch Overheadverursacht werden)

Das Gesamtprogramm wird in PSP2.1-Zyklen aufgeteilt, die integriert und getestet werden

39

39

Auswirkungen

• Bessere Aufwandsabschätzung• Leichteres Planen und Überwachen der eigenen Arbeit• Schutz vor “Überverantwortung”• Persönlicher Einsatz für Qualität• Einbindung in Prozessverbesserung

PSP

Aufwandsabschätzung: Besser durch Vergleich mit vorherigen ProjektenPlanen & Überwachen: Gegenwärtiger Stand kann jederzeit mit den gesteckten Zielen verglichenwerden“Überverantwortung”: Programmierer weiss, wie viel er leisten kann wird mehr verlangt, kann erbegründet und fundiert ablehnenEinsatz für Qualität: Qualität ist nichts AbstraktesProzessverbesserung: Programmierer hat nicht das Gefühl, dass “von oben” etwas diktiert wirdbessere Resultate

40

40

Studie

Daten von 298 Teilnehmern an 23 PSP-Schulungen

Daten nicht immer vollständig, für jede der Analysen standen jedoch mindestens 170 Fälle zur Verfügung.

Auswertung der Daten durch Varianzanalyse (ANOVA)

PSP - Studie

Die Studie wurde 1997 von Will Hayes und James W. Over durchgeführt (angestelltam Software Engineering Institute, Carnegie Mellon University), also

41

41

Bereiche der Untersuchung

Schätzung der Programmgröße

Schätzung des Arbeitsaufwandes

Fehler• Fehlerdichte• Yield

Produktivität

PSP - Studie

42

42

Datensätze bezogen auf Bereiche der Untersuchung

Quelle [10]

Nicht von allen Gruppen durchgeführt

PSP - Studie

Die für die Bereiche der Untersuchung zur Verfügung stehenden Datensätze unterscheiden sich, da nicht von allen Testpersonen 100% der Daten erstellt wurden.

Aufgabe 10 wurde von vielen Gruppen gar nicht durchgeführt

43

43

Datenbasis je Phase

Quelle [10]

PSP - Studie

Design- und Codereviews werden erst mit Aufgabe 7 (PSP2) eingeführt, vorherige Eingaben wurden von Testpersonen mit Vorerfahrung in Eigeninitiative erstellt.

44

44

Ergebnisse – Schätzung der Programmgröße

Quelle [10]

Genauere Schätzungen

PSP - Studie

Hypothese: „As engineers progress through the PSP training, their size estimates gradually grow closer to the actual size of the program at the end. More specifically, withthe introduction of a formal estimation technique for size in PSP level 1, there is a notable improvement in the accuracy of engineers’ size estimates”

Schätzung der Größe eines Programms:•Daten von 170 Testpersonen •Schätzungen werden zunehmend genauer•Über- und Unterschätzungen gleichen sich bei PSP-geschulten Testpersonen eher aus

45

45

Ergebnisse – Schätzung des Arbeitsaufwandes

Quelle [10]

Signifikante Verbesserung

PSP - Studie

Hypothese:“As engineers progress through the PSP training, their effort estimates grow closer to the actual effort expended for the entire life cycle. More specifically,with the introduction of a statistical technique (linear regression) in PSP level 1, there is a notable improvement in the accuracy of engineers’ effort estimates.”

•Siginfikate Verbesserung zwischen PSP0 und PSP1 (Einführung der Schätzung)•Nicht signifkant zwischen PSP1 und PSP2

50% der Testpersonen reduzierten den Schätzfehler um einen Faktor von 1.75 oder mehr

46

46

Ergebnisse – Fehlerdichte

Quelle [10]

Fehlerdichte nimmt (signifikant) ab

PSP - Studie

Hypothese 1: „As engineers progress through PSP training, the number of defects injected and therefore removed per thousand lines of code (KLOC) decreases.”

Daten von 181 Testpersonen

Ergebnisse:Signifikante Unterschiede zwischen den PSP-Ebenen bezüglich Fehlern in Test-Phase, Compile-PhaseReduktion der gesamten Fehler um Faktor 1.5 (Median)Reduktion der Fehler in der Compile-Phase um Faktor 3.7 (Median)Reduktion der Fehler in der Test-Phase um Faktor 2.5 (Median)

47

47

Ergebnisse – Fehlerdichte

Quelle [10]

PSP - Studie

Hypothese 2:“With the introduction of design and code reviews in PSP level 2, the defect densities of programs entering the compile and test phases decrease significantly.”

Ergebnis:Die Gesamtfehlerhäufigkeit sinkt zwischen PSP1 und PSP2 nicht signifikant, jedoch die Fehlerhäufigkeit in Compile- und Testphase

48

48

Ergebnisse – Yield

Quelle [10]

PSP2: Einführung von Reviews

PSP - Studie

Hypothese:“As engineers progress through the PSP training, their yield increases significantly. More specifically, the introduction of design review and codereview following PSP level 1 has a significant impact on the value of engineers’ yield.”

Daten von 188 Testpersonen

Ergebnisse:Mindestens die Hälfte der Testpersonen entfernte keine Fehler vor dem Kompilieren (vgl. Median (Stern in der Box))Signifikanter Anstieg des Yield in PSP2. Dies führen die Autoren auf die Einführung von Code- und Designreviews zurück.Mittleren Erhöhung des Yield um 50%

49

49

Ergebnisse – Produktivität

Quelle [10]

PSP - Studie

Hypothese:As engineers progress through the PSP training, their productivity increases. That is, the number of lines of code designed, written, and tested, per hourspent increases between the first and last assignments.

Daten (LOC) waren durch die Vorgaben von PSP vorhanden.

Ergebnisse:Die Produktivität steigt nicht signifikant. Zwischen PSP0 und PSP1 sinkt sie sogar.

Problem: Kein Vergleich mit Arbeit ohne PSP!

50

50

Bewertung der Studie

Untersuchung unter LaborbedingungenSind die Voraussetzungen für die ANOVA gegeben?Können die Ergebnisse auf die Realität übertragen werden?

Autoren sind/waren am SEI beschäftigtobjektiv?

Unstimmigkeiten innerhalb der Studie

PSP - Studie

Vorraussetzungen für ANOVA:•represäntative und zufällig ausgewählte Stichprobe

Das ist sie wohl nicht (geben die Autoren aber auch teilweise zu)•Die Untersuchungen müssen unabhängig sein

Besonderes Problem: Die Leiter der Schulungen ändern diese teilweise ab•Normalverteilung der abhängigen Variablen

Verteilung ist schief (die Autoren behaupten, das in den Griff bekommen zu haben – müsste man sich also genauer ansehen)

Laborbedingungen:•nur kleine Programme, kein Druck, etc., •Beispiel: Größenabschätzung: nur wenige Programme, die sich ähneln Verbesserung ist zu erwarten

Unstimmigkeiten innerhalb der Studie:Bsp.: Die Autoren sagen, dass für die Größenschätzung nur Daten von Testpersonen berücksichtigt wurden, die Ergebnisse zu allen Übungen abgegeben haben (ausschließlich der ersten, in der keine Schätzung durchgeführt werden musste). Das sind max. 152 (da nur 152 bei Übung 10). Ausserdemwurden bei Aufgabe 1 265 Bewertungen abgegeben?

51

51

PSP in der Praxis

72 von 78 Kursteilnehmern wollen PSP nicht weiter benutzen. Über die restlichen 6 ist nicht bekannt, ob sie es einsetzen! [12]

PSP erfordert viel Selbstdisziplin. Viele bringen diese nicht auf. [13]

Großer „overhead“und „context-switch“ [14]

PSP

Fazit:Zu umständlich.Softwareentwickler und Management sind oft nicht bereitZusammenarbeit und Toolunterstützung kann helfen

52

52

ISO/IEC 15504

Internationaler Standard für Software Prozess Assessments

Aktuelle Version (2003-2005)

Anforderungen an Prozessmodell• z.B.: ISO 12207 (Prozesse im Software-Lebenszyklus)

Anforderungen an Assessmentmethode• z.B.: SPICE (Assessment-Methode für ISO 12207)

ISO/IEC 15504

Projekt wurde 1993 von ISO und IEC gestartet1998: Technical Report2003-2005: Revision International Standard

Restrukturierung: TR war auf Software Prozesse beschränkt, in der neuen Version (ähnlich wie bei CMMI) ist dies erweitert worden, indem verschiedene Prozessmodelle verwendet werden können

53

53

ISO/IEC 15504

Aufzeigen von Stärken und Schwächen

Überprüfung

Referenz

Im Unternehmen etablierte Prozesse

ISO 12207

SPICE

AssessmentmethodeAssessmentmethode

ProzessmodellProzessmodell

DefinierteProzesseDefinierteProzesse

AngewandteProzesse

AngewandteProzesse

ISO/IEC 15504

Ausgehend von einem Prozessmodell wie z.B. ISO 12207 (oder auch 15288 für System-Entwicklung) werden in einem Unternehmen Prozess definiert und angewandt (ohne die tatsächliche Umsetzung ist die Definition von Prozessen sinnlos).

Das Prozessmodell wird von einer Assessmentmethode wie z.B. SPICE verwendet, um Stärken und Schwächen der im Unternehmen etablierten Prozesse aufzuzeigen. SPICE beruft sich hierbei auf ISO 12207 als Prozessmodell.Umgekehrt kann auch die Assessmentmethode selbst überprüft werden.

54

54

ISO 12207 – Prozesskategorien

BeschaffungEntwicklungLieferungBetrieb

ManagementProzessverbesserungInfrastrukturWiederverwendung

KonfigurationsmanagementQualitätssicherungPrdouktqualität

PrimärprozessePrimärprozesse Organisatorische ProzesseOrganisatorische Prozesse

Unterstützende ProzesseUnterstützende Prozesse

ISO 12207

PrimärprozesseBeschaffung Aktivitäten des Beschaffens von Software und DienstleistungenEntwicklung Aktivitäten des SoftwareentwicklersLieferung Aktivitäten des Lieferns von Software und DienstleistungenBetrieb Aktivitäten wie Systemeinführung, -test, Benutzerunterstützung und Wartung

Organisatorische ProzesseManagement Qualitäts-, Risiko-, Projektmanagement…Infrastruktur Aktivitäten zur Bereitstellung der notwendigen Infrastruktur aber auch und SchulungsmaßnahmenOptimierung Messen, Überprüfen und Verbessern der LebenszyklusprozesseWiederverwendung vorhandene Komponenten managen

Unterstützende ProzesseKonfigurationsmanagement Dokumentation, Problembehebung

55

55

Einsatz von Vorgehensmodellen

ISO 12207

V-Modell

Unternehmenseigene Vorgehensmodelle zur

Softwareentwicklung34% (4100 Unternehmen)

9% (1150 Unternehmen)

8% (900 Unternehmen)

Quelle: [16]

ISO 12207

Basis der Umfrage waren 12.165 Unternehmen, die 2000 im Rahmen einer vom Bundesministerium für Bildung und Forschung in Auftrag gegebenen Studie zur Analyse und Evaluation der Softwareentwicklung in Deutschland von der GfK Marktforschung GmbH, IESE und ISI befragt wurden.

Interessant ist, dass nur ca. 50% überhaupt angeben, ein Vorgehensmodell anzuwenden.

Neben den dominanten unternehmenseigenen Modellen sind V-Modell und ISO 12207 gleich vertreten.

56

56

SPICE

ProzessProzess

ProzessVerbesserung

ProzessVerbesserung

FähigkeitsgradBestimmung

FähigkeitsgradBestimmung

ProzessAssessment

ProzessAssessment

Änderungen Prozessfähigkeit

Antrieb

SPICE

Die Idee hinter Spice ist, dass das Prozess-Assessment immens wichtig als Antrieb für SPI ist .Anfangspunkt ist ein (im Unternehmen vorhandener) Prozess. Dieser Prozess wird durch ein SPICE-Assessment bewertet. Das Ergebnis ist eine Bestimmung des Fähigkeitsgrades und Verbesserungen des Prozesses sowohl direkt durch die Ergebnisse, als auch durch den Antrieb, einen bestimmten Reifegrad zu erreichen.

57

57

Prozessfähigkeit / Process Capability

umfasst• Prozessplanung• Prozessdurchführung• Prozesslenkung & Prozessmessung• Prozessverbesserung

Bessere Prozessfähigkeit bessere Vorhersagbarkeit der Ergebnisse des Prozesses

Bewertung mittels Prozess-Assessments

SPICE

58

58

3. Definiert

0. Unvollständig

Fähigkeitsgrade/Stufen und zugeordnete Attribute

5. Optimierend Prozessoptimierung Prozessinnovation

4. Vorhersagbar Prozessmessung Prozesskontrolle

Prozessdefinition Prozessverteilung

2. Gesteuert Prozessmanagement Produktmanagement

1. Durchgeführt Prozessdurchführung

SPICE

Den Stufen sind bestimmte Aktivitäten zugeordnet, die dazu führen, dass die Ergebnisse systematisch erarbeitet werden und am Ende des Prozesses in der definierten Qualität vorliegen.

Unvollständig Chaotischer ProzessDurchgeführt Artefakte sind vorhanden, Prozesse werden intuitiv durchgeführtGesteuert Prozesse und Artefakte gemanaged, Verantwortlichkeiten sind definiertDefiniert Vordefinierte Prozesse werden eingesetzt und angepasstVorhersagbar Messen der Prozesse macht die Resultate und die Leistung derselben kontrollierbarOptimierendQuantitative Messungen werden für die Optimierung und Verbesserung der Prozesse eingesetzt

59

59

Stufe 0 – Unvollständig

chaotischer Prozess

keine definierten Abläufe

keine klar erkennbaren Produkte

0. Unvollständig

5. Optimierend

4. Vorhersagbar

3. Definiert

2. Gesteuert

1. Durchgeführt

SPICE

60

60

Stufe 1 – Durchgeführt

ProzessdurchführungEs sind Produkte von Aktivitäten vorhandenDie Prozesse werden intuitiv durchgeführt

0. Unvollständig

5. Optimierend

4. Vorhersagbar

3. Definiert

2. Gesteuert

1. Durchgeführt

SPICE

61

61

Stufe 2 – Gesteuert

Management der ProzesseEinschränkungen bezüglich Ressourcen und Zeit werden berücksichtigt

Management der ProdukteAnforderungen an die Ergebnisse sind spezifiziertArt der DokumentationAbhängigkeiten zwischen ErgebnissenVerwaltung von ÄnderungenVerantwortlichkeiten sind definiert

0. Unvollständig

5. Optimierend

4. Vorhersagbar

3. Definiert

2. Gesteuert

1. Durchgeführt

SPICE

Darüberhinaus wird erwartet, dass die Ziele formuliert sind und welche Einschränkungen bezüglich Ressourcen und Zeit bei der Arbeit zu berücksichtigen sind.

Prozess ist nachvollziehbar (z.B. falls Probleme auftreten)Entspricht in etwa ISO 9001 Zertifizierung

62

62

Stufe 3 – Definiert

Definition der ProzesseEinheitlicher Entwicklungsprozess

Verteilung der ProzesseVordefinierte Prozesse werden eingesetzt und angepasst

0. Unvollständig

5. Optimierend

4. Vorhersagbar

3. Definiert

2. Gesteuert

1. Durchgeführt

SPICE

63

63

Stufe 4 – Vorhersagbar

Messung der ProzesseVordefinierte MetrikenQualitätsbestimmung der Prozesse und Produkte

Kontrolle der ProzesseGenaue Formulierung und Kontrolle von Zielvorgaben

0. Unvollständig

5. Optimierend

4. Vorhersagbar

3. Definiert

2. Gesteuert

1. Durchgeführt

SPICE

Anhand vordefinierter Metriken die Qualität der Prozesse und deren Produkte laufend ermittelt und werden die gesammelten Daten regelmässig analysiert, damit Zielvorgaben genau formuliert werden können

64

64

Stufe 5 – Optimierend

ProzessoptimierungÄnderungsbedarf wird vorzeitig erkanntMaßnahmen werden präventiv eingeleitet

ProzessinnovationPilotprojekte und neue Technologien

0. Unvollständig

5. Optimierend

4. Vorhersagbar

3. Definiert

2. Gesteuert

1. Durchgeführt

SPICE

Es findet eine ständige Prozessoptimierung statt

65

65

Bestimmung der Fähigkeitsgrade

Prozesse (z.B. nach ISO 12207)

Bestimmung des Fähigkeitsgrades für jeden einzelnen Prozess

Gesamtheit aller Prozesse Stärken-Schwächen-Profil

Nächsthöherer ReifegradMöglichkeiten zur Verbesserung

ENG.1

SUP.1

…

SUP.7

CUS.1

543210Prozesse/Stufen

SPICE

Der Reifegrad wird für jeden Prozess einzeln bestimmt. (Wesentlicher Unterschied zu CMM)

Die Bewertung erfolgt anhand der oben vorgestellten 5-stufigen Skala.

Während der Bewertung muss objektiv nachgewiesen werden, dass die Anforderungen auf der entsprechenden Stufe erfüllt werden. Dieses erfolgt zumBeispiel anhand von Arbeitsprodukten, welche als Ergebnisse aus den Prozessen hervorgehen.

66

66

Studie

DatenquelleErgebnisse der Assessments von 29 OrganisationenFragebögen (z.B. Produktivität, Kostenschätzung) zu 56 Projekten

HypothesenEine höhere Prozessfähigkeit in der Software-Anforderungsanalyse führt zu:• einer Steigerung der Produktivität• kürzeren Entwicklungszeiten

IS0/IEC 15504 - Studie

Dauer der Studie: 2 JahreUnternehmen hauptsächlich aus Europa und Australien/SüdostasienFragebögen wurden von den Verantwortlichen der Assessments beantwortet

67

67

Maße

PerformanzCustomer: KundenzufriedenheitSchedule: Fähigkeit, Kostenzusagen einzuhaltenBudget: Fähigkeit, Zeitzusagen einzuhaltenRequirements: Fähigkeit, spezifizierten Anforderungen zu genügenProducitivity: Produktivität der MitarbeiterMorale: Betriebsklima / Zufriedenheit der Mitarbeiter

Größe der Organisationseinheit (OU)Unterscheidung zwischen kleinen (<=50 IT Mitarbeitern) und großen OU

IS0/IEC 15504 - Studie

Auswertung in Fragebögen zu jedem Projekt: Frage: „Wie würden sie die Performanz des Projektes sehen hinsichtliich…“Anwtortmöglichkeiten: „Exzellent“, „Gut“, „Zufríedenstellend“, „Schlecht“, „Unbekannt“

68

68

Auswertung für kleine OU

Quelle [15]

IS0/IEC 15504 - Studie

Keiner der Korrelationskoeffizienten ist größer als der a priori festgelegte Schwellenwert von 0,3. (nur für die Requirements-Variable fast)

Die Autoren schließen deshalb, dass kein signifikanter Zusammenhang zwischen höherer Prozessfähigkeit in der SRA und einer der verwendeten Maße besteht.

69

69

Auswertung für große OU

Quelle [15]

IS0/IEC 15504 - Studie

Die Korrelationseffizienten von Produktivität und Moral sind über dem Schwellenwert von 0,3.Weitere statistische Tests (Bonferroni angpasstes alpha Level!) haben ergeben, dass nur Produktivität signifikant mit der SRA Prozessfähigkeit zusammenhängt.

Bei Budget und Schedule wurde nicht erwartet, einen starken Zusammenhang zu finden, da diese von anderen Faktoren als SRA abhängen.

Die Kundenzufriedenheit (Customer) hängt (wahrscheinlich) mehr von eingehalteten Zeit- und Kostenzusagen, als der Anforderungsanalyse ab.

Interessant ist, das Requirements nicht stark abhängt. Andere Faktoren im Laufe des Lebenszyklus haben hier also (mit) entscheidenden Einfluss..

70

70

Ergebnisse

Eine höhere Prozessfähigkeit in der Anforderungsanalyse führte zu einer Steigerung der Produktivität der Projekte und somit zu einer Kostenreduktion.

ABER: Nur bei großen Unternehmen (mit mehr als 50 Mitarbeitern)!

Interpretation:• Messung des Reifegrades funktioniert bei kleinen Betrieben nicht• Die Prozessfähigkeit in der Requirement Analyse hat bei kleineren

Organisationen einen geringeren Effekt auf die projektbezogene Leistung

IS0/IEC 15504 - Studie

Die Autoren denken, dass die Produktivitätssteigerung dadurch zustande kommt, dass weniger nachgearbeitet werden muss.

71

71

Bewertung der Studie

Es wird explizit in der Studie darauf hingewiesen, dass oft nur die Studien publiziert werden, die eine These / ein Modell stützen.

Es wird in der Studie auch auf andere mit dem Überprüfen von Assessmentmodellen verbundenen Problematiken eingegangen.

Die verwendeten statistischen Methoden werden detailliert erklärt.

IS0/IEC 15504 - Studie

Die Studie macht einen statistisch fundierten Eindruck

Die Studie eignet sich auch als Ausgangspunkt, um sich kritisch mit Prozessverbesserung auseinander zu setzen.

72

72

Resümee

„Egal mit welchem Prozess Sie beginnen, Es wird nicht der Prozess sein,

Der bei Ihnen wirklich funktioniert.Sie müssen die Verantwortung für Ihren Prozess übernehmen,

Ihn dauernd beobachtenUnd ihn an die Gegebenheiten anpassen.

Letztlich muss es Ihr Prozess werden,Alle anderen Etiketten sind sekundär“

(Martin Fowler)

Resümee

73

73

CMM[1] Process Maturity Profile – Software CMM 2003 Year End Update

http://www.unf.edu/~ncoulter/cen6070/handouts/2004marSwCMM.pdf

[2] After the Appraisal: A Systematic Survey of Process Improvement, its Benefits, and Factors that Influence Success, Dennis R. Goldenson, James D. Herbsleb, August 1995

[3] Capability Maturity Model for Software, Version 1.1, Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber, 1993

[4] A Systematic Survey of CMM Experiences and Results, J.D. Herbsleb, D.R. Goldenson:; Proceedings of ICSE-18, 1996, S.323f

[5] Software Quality and the Capability Maturity Model, J.D. Herbsleb, D.R. Goldenson et. al.: Communications of the ACM, Juni 1997/Vol.40 No.6, S.30f

Quellen

74

74

CMM[6] A Systematic Survey of CMM Experiences and Results, J.D. Herbsleb,

D.R. Goldenson; Technical Report CMU/SEI-95-TR-009, 1995; http://www.sei.cmu.edu

[7] A Critical Look at Software Capability Evaluations, T.B. Bollinger, C. McGowan; IEEE Software 8, Juli 1991, S.25f

[8] http://de.wikipedia.org/wiki/Capability_Maturity_Model

[9] de.wikipedia.org/wiki/Capability_Maturity_Model_Integration

Quellen

75

75

PSP[10] The Personal Software Process (PSP): An Empirical Study of the

Impact of PSP on Individual Engineers, Will Hayes, James W. Over, December 1997

[11] http://de.wikipedia.org/wiki/Personal_Software_Process

[12] Teaching PSP: Challenges and lessons learned, J. Borstler, D. Carrington, G. Hislop, et al., IEEE Software, 19(5), September 2002

[13] Experience Report: Teaching and Using the Personal Software Process (PSP), Prechelt, Submission to ESEC 1997.

[14] Beyond the PSP: Metrics collection and analysis for the differently disciplined. Johnson, Kou, Agustin et al., Proceedings of the 2003 International Conference on Software Engineering. Portland, Oregon, 2003

Quellen

F

76

76

ISO/IEC 15504 – SPICE – ISO 12206[15] Validating the ISO/IEC 15504 Measure of Software Requirements

Analysis Capability, Khaled El Emam, Andreas Birk, Februar 1999

[16] Analyse und Evaluation der Softwareentwicklung in Deutschland, GfK Marktforschung GmbH, IESE, ISI

[17] http://de.wikipedia.org/wiki/ISO_15504

[18] http://www.isospice.typepad.com/isospice_home/

[19] Nach CMM und BOOTSTRAP: SPiCE, Die neue Norm für Prozessbewertungen, Stienen, Informatique 6,1999

[20] http://de.wikipedia.org/wiki/ISO_12207

Quellen

77

77

Prozessverbesserung[21] http://www.tantara.ab.ca/a_isorel.htm#15504

[22] Improving Software Process Improvement, Conradi R., Fugetta A., IEEE Software July/August 2002

[23] Eine geführte Tour durch die Landschaft der Software-Prozesse und Prozessverbesserung, Glinz, Informatique 6,1999

Quellen