IT-Projektmanagement Teil 9: Qualitätsmanagement. Wintersemester 2012/2013 Dr. Gerhard Pews

Transkript

1 IT-Projektmanagement Teil 9: Qualitätsmanagement Wintersemester 2012/2013 Dr. Gerhard Pews

2 Ziel dieser Einheit ist, den Studierenden das Wissen zu vermitteln, wie man ein Projekt steuert. Ziele der Vorlesungseinheit Inhalte Die Hörer wissen, wie Qualitätsmanagement im Projekt umgesetzt wird. Die Hörer können einen Qualitätsmanagementplan aufsetzen. Die Hörer kennen die wichtigsten Normen und Modelle im Qualitätsmanagement 2

3 Der Fahrplan durch die Vorlesung Inhalte Einführung Das Was : Der Gegenstand von Softwareprojekten Das Wie : Die Tätigkeiten in einem Projekt und wie man sie ausführt Vorbereitung eines Projekts Projektplanung Durchführen eines Projekts Unterstützende Tätigkeiten Soft Factors Wirtschaftliche Aspekte 3

4 AGENDA Qualitätsmanagement Motivation Grundlegende Anmerkungen QM im Projekt QM und Projektmanagement QM Normen und Modelle 4

5 Der Begriff Qualität ist in Verbindung mit Software oft diffus. Motivation: Assoziationen zum Begriff Qualität solide dauerhaft stabil schlechte Qualität Qualität langweilig Möbel Autos 5

6 Qualität im Bereich Software erschließt sich erst beim zweiten Hinsehen Motivation: Softwarequalität macht Spaß! Gute Qualität in der Software Gute Qualität in der Software erzeugt zufriedene Auftraggeber Gute Qualität in der Software erzeugt zufriedene Mitarbeiter Es macht Spaß, so richtig gute Software abzuliefern! 6

7 AGENDA Qualitätsmanagement Motivation Grundlegende Anmerkungen QM im Projekt QM und Projektmanagement QM Normen und Modelle 7

8 Unter qualitativ hochwertiger Software versteht jeder etwas anderes. Annäherung an den Begriff Qualität im Bereich Software Man erhält einen einfacheren Zugang, wenn man sich vom Begriff Qualität löst und von so richtig guter Software spricht. Was ist richtig gute Software?? Was macht denn Software so richtig gut? Was ist Ihre Lieblingssoftware und was gefällt Ihnen daran? Welche Software gefällt Ihnen nicht? Warum? 8

9 Ein großer Teil der gefühlten Qualität einer Software ist subjektives Empfinden Qualitätsempfinden des Software-Nutzers Qualitätsempfinden Hängt ab von der Erwartungshaltung des Nutzers Hängt ab von sonstigen Eigenschaften und Kontext Spiel, das öfter mal abstürzt Office-Programm, das öfter mal abstürzt Aber: es gibt auch klar messbare Kriterien Die Zufriedenheit des Kunden hängt aber nicht nur von der Software ab (vgl. Projektinitialisierung Kundenbefragung) 9

10 Ein gutes Ergebnis erzielt man, indem man die richtigen Dinge tut. Prozessdenken als Schlüssel zur Qualität Ein gutes Ergebnis erzielt man, indem man die richtigen Dinge tut. Ein gutes Ergebnis erzielt man nicht durch Abnahmeprüfungen. Prüfungen stellen sicher, dass keine Fehler passiert sind. Sie sind eine letzte Sicherheitsmaßnahme. Wichtige Begriffe Analytische Qualitätssicherung Überprüfen, ob die geforderte Qualität erreicht ist. Beispiele: Tests, Prüfungen allgemein Konstruktive Qualitätssicherung Verbesserungen des Software-Erstellungsprozesses, der im Projekt gelebt wird. 10

11 Qualitätsmanagement muss jeder im Projekt leben. Zuständigkeiten für das Qualitätsmanagement Frau Schmidt ist für die Qualität zuständig. Übersetzt: Unser Projekt schreibt so richtig gute Software. Das macht die Frau Schmidt. Das klingt nicht nur unplausibel, das ist auch unplausibel. Damit richtig gute Software rauskommt, muss sich jeder im Projekt anstrengen. Qualität geht alle an! 11

12 Qualität muss man in die Software hineinkonstruieren. Fazit Qualität geht jeden an. Jeder einzelne im Projekt sorgt dafür. Ein Qualitätsbeauftragter unterstützt dabei, mehr aber auch nicht. Es gibt konstruktive und analytische Maßnahmen zur Qualitätssicherung. Mehr Qualität erzeugen kann man nur mit konstruktiven Maßnahmen. Analytische Maßnahmen stellen nur sicher, dass ein Qualitätsstandard erreicht ist. Man kann keine Qualität in Software hineinprüfen. Qualität kann man nur in Software hineinkonstruieren. 12

13 AGENDA Qualitätsmanagement Motivation Grundlegende Anmerkungen QM im Projekt QM und Projektmanagement QM Normen und Modelle 13

14 Das Fallbeispiel zeigt, dass sich formale Vorgaben erfüllen lassen, ohne die Qualität zu verbessern. Fallbeispiel Qualitätsmanager In der Softwarefirma XY wurde der Mitarbeiter Müller zum Qualitätsmanager ernannt. Die Gründe: er war derjenige, auf den man im Projektgeschäft am einfachsten verzichten konnte. Er stellt ein Monster an Formalismen zusammen und nennt es Qualitätsmanagementsystem. Man beauftragt eine kleine (von ihren Auftraggebern abhängige) Firma mit der Zertifizierung nach ISO 9000 und erreicht sie tatsächlich auch. und was ist mit der Software? Die ist immer noch so schlecht wie vorher. 14

15 Die Umsetzung von QM im Projekt hat drei wesentliche Bestandteile: Qualitätsziele, Kritikalitätsanalyse, Festlegen von Maßnahmen. Bestandteile eines Qualitätsmanagement-Plans Bestandteile Qualitätsziele Kritikalität Maßnahmen Konkretisieren die allgemeinen Projektziele Fokus auf Themen zu nicht-funktionalen Anforderungen (NFAs), vgl. ISO (später) Konkrete Messkriterien für Ziele Sinn: Maßnahmen sollen nicht mit der Gießkanne erfolgen, sondern fokussiert auf die Stellen in der Software, die wichtig sind. Analyse: welche Teile in der Software sind wichtig, welche sind weniger wichtig Konkrete Maßnahmen und Vorgaben, wie im Projekt die erforderte Qualität erzeugt werden soll. Konstruktive und analytische Maßnahmen Festhalten im Qualitätsmanagement-Plan (QM-Plan) 15

16 Projektziele, Qualitätsziele und Maßnhamen bauen aufeinander auf. Zusammenhang zwischen den Bestandteilen des QM-Plans Maßnah men via Kritikalitätsanalyse: Fokussierung auf die wichtigen Bereiche des Projekts, auf die wichtigen Module der Software Qualitätsziele Konkretisierung, Fokussierung auf NFA-Themen Allgemeine Projektziele 16

17 Qualitätssicherung ist schon zu Projektbeginn wichtig. Bedeutung einer frühzeitigen Qualitätssicherung In der Projektinitialisierung werden die wesentliche Weichenstellungen für das Projekt vorgenommen: Das Team wird zusammen gestellt Ziele werden fixiert Die Projektplanung wird festgelegt Hier ist der Qualitätssicherer der Sparringspartner des Projektleiters. Falls noch niemand für die Qualitätssicherung benannt ist, sollte der Projektleiter sich hier zumindest ein Gespräch mit einem Qualitätsberater führen. 17

18 Das Fallbeispiel illustriert konkrete qualitätssichernde Maßnahmen bei der Erstellung eines Konzepts Fallbeispiel Dokumenterstellung Fallbeispiel 18

19 Für die Qualitätssicherung stehen eine Vielzahl von Maßnahmen zur Verfügung. Qualitätssichernde Maßnahmen im Projekt (1/4) Generell: als Qualitätssicherer muss man kreativ sein! Reviews (Analytische Maßnahme) Code Reviews Dokumentenreviews Workshops, zu denen externe Experten eingeladen werden. Zwischenergebnisse werden vorgestellt und diskutiert Tests (Analytische Maßnahme) Funktionale Tests, auch als Regressionstests Lasttests etc. Durchstich (Konstruktive Maßnahme) fachlich technisch 19

20 Für die Qualitätssicherung stehen eine Vielzahl von Maßnahmen zur Verfügung. Qualitätssichernde Maßnahmen im Projekt (2/4) SEU-Aufbau (Konstruktive Maßnahme) Aufbau einer insgesamt gut nutzbaren Entwicklungsumgebung (Editoren, Build-Werkzeuge, Code- Analyzer, Test-Frameworks, Anbindung an das Konfigurationsmanagement, Modellierungswerkzeuge, Generatoren, Debugger, etc.) Ausbildungsmaßnahmen für Mitarbeiter (Konstruktiv) Schulungen Workshops Vorträge Team-Rotation Verbesserung der Kommunikation (Konstruktiv) Spezielle Meetings, Statusrunden Vorträge über Fachthemen 20

21 Für die Qualitätssicherung stehen eine Vielzahl von Maßnahmen zur Verfügung. Qualitätssichernde Maßnahmen im Projekt (3/4) Vorgaben, Richtlinien (Konstruktive Maßnahme) Coding-Richtlinien Styleguides gemeinsame Glossare Richtlinien zur Erstellung von Dokumenten Checklisten, Templates (Konstruktive Maßnahme) Als Operalisierung der Vorgaben Vorsicht! Nicht übertreiben! Keine Schrankware produzieren. Richtlinien müssen noch anwendbar bleiben. 21

22 Für die Qualitätssicherung stehen eine Vielzahl von Maßnahmen zur Verfügung. Qualitätssichernde Maßnahmen im Projekt (4/4) Zusammenarbeit unterstützen (Konstruktive Maßnahme) Projektablage (Verzeichnis oder Konfig-Mgmt) organisieren Dafür sorgen, das man Informationen wieder finden kann: Konventionen für die Ablage von Dokumenten Beschaffen eines Such-Tools Händischer Index (z. B. HTML) über die wichtigsten Dokumente 22

23 Ein Audit ist eine wirksame Maßnahme, um einen Blick von außen auf das Projekt zu erhalten und daraus Hilfestellungen zu entwickeln. Vorstellung: Audit Audit Intensive Untersuchung eines Projekts In der Regel durch externe Auditoren Sichtung von Unterlagen Führen von Interviews Kann sowohl formale Kriterien (einfach) als auch Projektinhalte und Vorgehensweise (schwierig) prüfen. Ergebnise: Bewertung des Projektstatus, z. B. in Form einer Projektampel Liste vorgeschlagener Maßnahmen 23

24 Wenn das Werkzeug Audit richtig verstanden und angewendet wird, erzeugt es eine realistische Einschätzung und ist eine echte Hilfe. Diskussion des Nutzens von Audits Hilfestellung durch ein Audit Die Vorbereitung auf ein Audit selbst ist schon hilfreich Offenheit hilft, weil man als Auditierter selbst ein offenes Feedback bekommt und man das Projekt verbessern kann. Ein Audit als bloße Kontrollveranstaltung mit anschließender Bestrafung verfehlt seinen Zweck. Die Einschätzung der Projektsituation ist schwierig gerade bei kurzen Audits (wenige Stunden). wenn die Auditierten sich selbst und die Projektsituation falsch einschätzen und diese Meinung überzeugend vertreten. Trotzdem zeigt die Praxis, dass der Auditor schon nach kurzer Zeit einen guten Eindruck von der Projektsituation bekommt. 24

25 Das Audit umfasst eine Vor- und Nachbereitung Vorgehen im Audit Schritt Vorbereitung Durchführung Nachbereitung Erfolgskontrolle Inhalt Vorab werden die wichtigsten Projektunterlagen an die Auditoren verteilt: Projekthandbuch, Projektauftrag, Projektplanung, QS-Plan Auditoren bewerten die Unterlagen und führen Interviews. Interviewed werden: Projektleiter, Qualitätsbeauftrager, ggf. Auftraggeber und Projektmitarbeiter Auditoren erstellen einen Auditbericht mit einer Bewertung und vorgeschlagenen Maßnahmen. Nach einiger Zeit (z. B. 4-6 Monaten) erfolgt ein Nachaudit oder eine Nachbesprechung, um die Wirkung der Maßnahmen zu überprüfen und den Status neu zu bewerten. 25

26 Die Fragen dienen dazu, ein umfassendes Bild über die gelebte Praxis im Projekt zu erhalten Typische Fragestellungen im Audit (1/2) Generelle Fragestellung Im Audit kann man die Dinge abprüfen, die so ganz einfach und selbst-verständlich klingen. Dies sind die bisher in der Vorlesung vorgestellten Inhalte. Projektauftrag Ist der Projektauftrag klar definiert? Wo ist der? Ist der unterschrieben? Sind die Ziele klar formuliert? Ist klar, welche Ergebnisse das Projekt liefern soll? Risiken Was sind die 5 Top-Risiken im Projekt? Hat dazu jeder im Projekt die gleiche Meinung? Projektstruktur Wie sieht die Projektstruktur aus? Ist das Projekt gut gegliedert oder ein unstrukturierter Klumpen? 26

27 Die Fragen dienen dazu, ein umfassendes Bild über die gelebte Praxis im Projekt zu erhalten Typische Fragestellungen im Audit (2/2) Projektvorgehen Ist mit dem Auftraggeber das Abnahmeverfahren geklärt? Ist das CR-Verfahren mit dem Auftraggeber abgesprochen? Ist das Verfahren allen bekannt? Organisatorisches Ist das passende Know-how im Team vorhanden? Kennt jeder im Projekt das Eskalationsverfahren? QS-Plan Welche QS-Maßnahmen sind geplant? Projekthandbuch Gibt es ein aktuelles Projekthandbuch? 27

28 AGENDA Qualitätsmanagement Motivation Grundlegende Anmerkungen QM im Projekt QM und Projektmanagement QM Normen und Modelle 28

29 Qualitätsmanagement und Projektmanagement haben Überschneidungen. Verhältnis zwischen QM und PM Qualitätsmanagement und Projektmanagement sind beides keine theoretischen Wissenschaften, sie leben von der praktischen Umsetzung. Im Idealfall agieren PL und QS Hand in Hand. Der Qualitätssicherer ist Sparringspartner des Projektleiters und bringt sich konstruktiv mit ein. Im Problemfall benötigt allerdings der Qualitätssicherer einen Möglichkeit zur Eskalation. Im Teufelsquadrat ist Qualität eine relativ schwache Ecke. Kosten, Zeit, Lieferumfang sind einfacher zu messen als die Qualität 29

30 Controlling erfolgt entlang der Berichtswege und folgt der Projekthierarchie. Berichtswege im Projekt Qualitätssicherung Schmidt Team Batches TPL Meier Lenkungskreis PL Schulz tech. Chefdesign Huber Team Dialoge TPL Müller Der Berichtsweg folgt der Projekthierarchie. Nach oben hin steigt der Abstraktionsgrad und die Berichtshäufigkeit sinkt. Mitarbeiter Ford Mitarbeiter Marvin Mitarbeiter Douglas 30

31 Wir stehen kurz vor dem Abgabetermin. Wesentliche Teile unserer Software sind weder fertig noch getestet. Ich sehe keine Chance, dass wir den Termin halten können. 31

32 Das Projekt ist leider nicht mehr ganz im Plan und wird wohl nicht so ganz Na Das termingerecht gut, kann einigen ich meinem beendet wir uns Chef niemals werden auf erklären. können. gelb. Der Status ist eher rot. 32

33 Das Projekt ist gelb. Es wird zwar schwer, den Abgabetermin zu halten, wir könnten es aber noch schaffen. 33

34 Also, so lange es noch eine Chance gibt, ist das Projekt für mich grün! 34

35 Alles grün! 35

36 Dank unserer ständigen Statusberichte haben wir alles unter Kontrolle und können frühzeitig auf Probleme reagieren. Das nenne ich modernes Management! 36

37 Wenn die Eskalation von Qualitätsproblemen entlang der Projekthierarchie erfolgt, besteht die Gefahr, dass Probleme totgeschwiegen werden. Eskalationsweg im Projekt Bereich Abteilung Abteilung Abteilung Team Teamleiter Teamleiter Teamleiter Qualitätssicherung Schmidt Team Batches TPL Meier PL Schulz tech. Chefdesign Huber Team Dialoge TPL Müller Mitglied im Lenkungskreis, Chef von Schulz) Gefahr Qualitätsprobleme werden entlang des Berichtsweges totgeschwiegen 37

38 Eine eigene Berichtshierarchie für Qualitätsthemen löst dieses Problem. Auflösung durch eigene Berichtshierarchie für Qualitätsthemen Qualitätsmanager Bereich Bereich Abteilung Abteilung Abteilung Qualitätsmanager Abteilung Team Teamleiter Teamleiter Teamleiter Qualitätssicherung Schmidt Team Batches TPL Meier PL Schulz tech. Chefdesign Huber Team Dialoge TPL Müller Eigene Berichtshierarchie Der Aufbau einer eigenen Hierarchie parallel zur Projekthierarchie sorgt dafür, dass Qualitätsprobleme bei Bedarf eskaliert werden können 38

39 AGENDA Qualitätsmanagement Motivation Grundlegende Anmerkungen QM im Projekt QM und Projektmanagement QM Normen und Modelle 39

40 Beim Aufstellen von Formalismen besteht immer die Gefahr, dass leere Formalismen die Arbeit behindern. Vorbemerkungen zu Formalismen Qualitätsmanagement ist eine eigene Vorlesung, im Folgenden geht es um die Ideen und die Einordnung zum Projektmanagement. Gefahren in einem Formalismus Es können riesige Regelwerke entstehen, die niemand mehr überblicken kann und deren Inhalte nicht gelebt werden können. Hat ein Formalismus erst einmal diese Größe erreicht, ist er tot. Auch die vorhandenen sinnvollen Inhalte sind dann nutzlos. Eine hauptberufliche QS neigt zur Überreglementierung, indem jeder Handschlag vorgeschrieben ist. Das tötet den Spaß an der Arbeit und letztendlich auch die Qualität. Einen Formalismus betreiben und überwachen kann man auch, wenn man keine Ahnung von den eigentlichen Inhalten der Arbeit hat. Dann hält man sich an Formalia fest, die eigentlich unnütz oder sogar schädlich sind. 40

41 Sinnvoll eingesetzte Formalismen können eine große Hilfe sein. Nützliche Formalismen bilden ein stützendes Gerüst Gefahren in einem Formalismus Jeder leere Formalismus ist nutzlos. Durch Formalismen lässt sich Qualität nicht erzwingen. Wenn Sie im Projekt auf solche Fossilien treffen, beseitigen Sie sie. Wenn aber im Projekt Qualität gelebt wird, sind Formalismen hilfreich Sie geben einen Rahmen. Sie stellen sicher, dass nichts übersehen wird oder in Vergessenheit gerät Sie können die Priorität der Ecke Qualität im Teufelsquadrat erhöhen. Genau so sollen im Folgenden die Normen und Modelle betrachtet werden: wie helfen sie uns, gute Software zu produzieren? 41

42 ISO 9000 ff beschreibt ein Qualitätsmanagementsystem. Kurzer Überblick über die Inhalte von ISO 9000 ff ISO 9000 ff behandelt Qualitätsmanagement allgemein nicht nur für Software. Teil bezieht sich auf Software. Idee: Die Gesamtheit der QS-Prozesse, Organisationsstrukturen etc. einer Firma bildet das Qualitätsmanagementsystem (QMS). Man kann Anforderungen an ein solches System definieren und ein QMS zertifizieren. Diese Zertifizierung muss in regelmäßigen Abständen wiederholt werden. Fragestellungen: Sind die Prozesse festgelegt und dokumentiert? Werden diese Prozesse auch umgesetzt? Führen diese Prozesse zu guten Resultaten? 42

43 Im Idealfall sorgt ein QMS für steigende Produktivität und Qualität Positiv- und Negativbeispiel für den Einsatz eines QMS Positivbeispiel Eine Firma hat ein funktionierendes, schlankes QMS Die Auditierung für die Zertifizierung nach ISO 9000 hält diesem QMS den Spiegel vor: Wo kann man das QMS noch verbessern? Wo sind Punkte, die man aus Betriebsblindheit übersehen hat? Die angestrebte Zertifizierung erzeugt im Projektalltag einen gewollten Druck, damit QS-Aspekte nicht untergehen können. Die Produktqualität steigt, Qualität ist im Bewusstsein aller verankert Die bestandene Zertifizierung ist eine Belohnung, ein Lob, über das sich alle freuen. Negativbeispiel Vgl Beispiel: erschlichene Zertifizierung 43

44 In der ISO findet sich ein nützliches Qualitätsmodell, das einen Überblick über die einzelnen Aspekte der Qualität gibt. Kurzüberblick/Motivation ISO Fragestellungen Fragestellung: woran misst man Qualität? Problemstellung im Projekt: Sicherstellen, dass kein wichtiger Aspekt übersehen ist: Bei der Definition von Qualitätszielen im QM-Plan Beim Erheben von Anforderungen Ein Auftraggeber weiß unter Umständen gar nicht, dass er eine Anforderung zu einem bestimmten Kriterium hat oder er hält sie für so selbstverständlich, dass er sie gar nicht nennt. ISO enthält ein Qualitätsmodell, in der Praxis am wichtigsten sind die Qualitätsmerkmale (quality model for external and internal quality) 44

45 Die ISO gibt ein Qualitätsmodell vor, das im Folgenden näher erläutert wird. Qualitätsmodell der ISO Quelle: ISO/IEC , Software engineering Product quality Part 1: Quality model 45

46 Functionality umfasst alle Aspekte, die die fachliche Funktionalität betreffen. Umgangssprachliche Erklärung des Aspekts Functionality Teilaspekte Functionality Suitability: Kann man mit der Anwendung das machen, was man mit ihr tun will? Ist der Funktionsumfang richtig? Accuracy: Liefert die Anwendung die richtigen Ergebnisse in der gewünschten Präzision? Interoperability: Arbeitet die Anwendung korrekt mit anderen Systemen zusammen? Security: Schützt die Anwendung die enthaltenen Daten und Funktionen gegen unautorisierten Missbrauch? 46

47 Reliability umfasst alle Aspekte, die sich mit der Zuverlässigkeit der Software befassen. Umgangssprachliche Erklärung des Aspekts Reliability Teilaspekte Reliability Maturity: Stürzt die Software wegen Fehlern nur selten ab? Fault tolerance: Bleibt die Software funktionsfähig, auch wenn falsche Eingaben gemacht werden oder interne Fehler auftreten? Recoverability: Wenn die Software abgestürzt ist, lassen sich später die Software und die Daten wiederherstellen? 47

48 Usability bezeichnet die einfache Nutzbarkeit, Efficiency bezeichnet die klassisichen Nicht-funktionalen Aspekte wie Performance/Durchsatz. Umgangssprachliche Erklärung der Aspekte Usability und Efficiency Teilaspekte Usability Understandability: Versteht man, was die Software macht und ob sie das richtige macht, wenn man mit ihr arbeitet? Learnability: Ist die Nutzung der Software leicht zu erlernen? Operability: Kann man die Software leicht bedienen? Attractiveness: Macht es Spaß, mit der Software zu arbeiten? Teilaspekte Efficiency Time behaviour: Ist die Software schnell genug, verarbeitet sie schnell genug die Daten? Resource utilisation: Geht die Software sparsam genug mit den Ressourcen, insbesondere der Hardware, um? 48

49 Maintainability umfasst alles, was Wartung und Weiterentwicklung betrifft. Umgangssprachliche Erklärung des Aspekts Maintainability Teilaspekte Maintainability (Wartung und Weiterentwicklung) Analysability: Wie schnell finde ich die Stelle, die ich ändern will? Changeability: Wenn ich die Stelle gefunden habe, wie leicht lässt sich etwas ändern? Stability: Haben Änderungen nur begrenzte Auswirkungen? Testability: Wie leicht kann ich die Software testen? 49

50 Portability betrifft Aspekte der Abhängigkeit von einer bestimmten Ablaufumgebung. Umgangssprachliche Erklärung des Aspekts Portability Teilaspekte Portability Umziehen in eine andere Umgebung: HW, SW, Organisation Adaptability: Kann man die Software durch Änderung an dafür vorgesehenen Stellen an eine andere Umgebung anpassen? Installability: Lässt sich die Software in einer bestimmten Umgebung einfach installieren? Co-existence: Verträgt sich die Software mit anderen Systemen oder blockiert sie z. B. gemeinsam genutzte Ressourcen? Replaceability: Lässt sich die Software gegen eine andere Software austauschen, die für den gleichen Zweck gemacht ist? 50

51 Das Fallbeispiel zeigt, wie das Qualitätsmodell der ISO 9126 genutzt wurde, um Anforderungen zu strukturieren. Fallbeispiel Nutzung der ISO 9126 im Rahmen der Anforderungsanalyse Szenario: Anforderungsanalyse In einem Großprojekt werden die Anforderungen systematisch erfasst. Die Anforderungen werden nach den Kriterien der ISO 9126 gegliedert (insbesondere die nicht-funktionalen Anforderungen) Dazu mussten aber noch weitere Gliederungspunkte ergänzt werden. Sicherheit, dass keine relevanten Punkte vergessen wurden Übersichtlichkeit und bessere Kommunikation zum Auftraggeber durch ein allgemein bekanntes Raster 51

52 CMMI ist ein von der Carnegie Mellon University entwickeltes Qualitätsmanagementmodell Motivation/Überblick CMMI CMMI (Capability Maturity Model) 1991 von der Carnegie Mellon University (Software Engineering Institute) entwickeltes Qualitätsmanagementmodell Aktualisierung zu Capability Maturity Model Integration, in der zwischenzeitlich entstandene Spezialformen des CMM integriert wurden: Software-CMM, Software Engineering-CMM, Integrated Product Development-CMM Idee: Ausgangsfrage: Wie reif ist eine Organisation? Wie reif sind ihre Software-Engineering Prozesse? Definition von fünf Stufen, um die Reife einer Organisation zu bewerten. 52

53 Die CMMI-Level beschreiben den Reifegrad einer Organisation. Umgangssprachliche Beschreibung der Level 1-3 (von 5) CMMI-Level 1: Initial Wir machen es irgendwie. Wir wissen nicht so genau, wie wir es machen. 2: Managed (früher: Repeatable ) 3: Defined Es gibt einen Software-Engineering Prozess. Was wir einmal hinbekommen haben, kriegen wir auch erneut hin. Das ist aber auch abhängig von den jeweiligen Personen. Der Software-Engineering Prozess ist standardisiert. Wir können den Prozess auch umsetzen, wenn es mal schwierig wird. 53

54 Die CMMI-Level beschreiben den Reifegrad einer Organisation. Umgangssprachliche Beschreibung der Level 4+5 (von 5) CMMI-Level 4: Quantitatively Managed (früher: Managed ) 5: Optimizing Der Prozess wird organisationsweit standardisiert durchgeführt. Die Ausführung des Prozesses wird dokumentiert und mit Kennzahlen gemessen. Aus den Kennzahlen leiten wir ab, wie wir uns verbessern können. 54

55 Vielen Dank für Ihre Aufmerksamkeit!