Projektmanagement Software-Qualität

Transkript

1 Projektmanagement Software-Qualität und Autor: Matrikel-Nummer: Datum: Dokumentenstatus: Ausgearbeitet v.01

2 Inhaltsverzeichnis 1. Einleitung Zeitplan - Arbeitsplan Vorstellung des Themas Eingrenzung Definition Software-Qualität Definition Projektmanagement Projektmanagement Projektstrukturen Stabsprojektorganisation Reine Projektorganisation Matrix Projektorganisation Vorgehensmodelle Wasserfallmodell V-Modell Prince Eingrenzung in Bezug auf Software-Qualität Software-Qualität Reifegradmodelle CMM CMMI DIN / ISO / IEEE ISO 900x: DIN-ISO DIN-ISO/IEC IEEE Std 730 & IEEE Std Abgrenzung Reifegradmodelle vs DIN / ISO / IEEE Zusammenfassung / Ergebnisse Anhang PRINCE2 Grundprinzipien ~ 2 ~

3 8. Abkürzungsverzeichnis Quellen Literarische Quellen Internetquellen ~ 3 ~

4 Abbildungsverzeichnis Abbildung 1: Arbeitsplan (Stand )... 7 Abbildung 2: "Das magische Projektdreieck" Abbildung 3: Stabsprojektorganisation Abbildung 4: Reine Projektorganisation Abbildung 5: Matrix Projektorganisation Abbildung 6: Wasserfallmodell Abbildung 7: V-Modell Abbildung 8: PRINCE Abbildung 9: CMM - Capability Maturity Models Abbildung 10: Beispiel CMMI Abbildung 11: Grundprinzipien PRINCE ~ 4 ~

5 1. Einleitung Für das Fach Formale Methoden wurde ein Semesterprojekt angedacht, mein Thema lautet Projektmanagement und Software-Qualität, welches in der zugesandten Literatur 1 im Kapitel 9 zu finden ist. 1 Hoffmann, Dirk: Software-Qualität, Springer-Verlag, Berlin, Heidelberg, ~ 5 ~

6 2. Zeitplan - Arbeitsplan Dieses Kapitel stellt den zeitlichen Rahmen dieser Ausarbeitung in Tabellenform dar. Hierzu zählen Vorbereitung, Literaturrecherche, Meilensteine und letztendlich die schriftliche Ausarbeitung der Semesterarbeit. Der Arbeitsplan wird während dem Projekt fortgeführt, es ist immer nur der aktuelle Status in dem Dokument abgelegt ~ 6 ~

7 Arbeit spaket Name Arbeit spaket Typ Arbeit spaket Beschreibung angedacht er Zeitraum Status Dokumentenvorbereitung Vorbereitung - Dokumentenvorlage erstellen beendet Arbeitspaketplanung Vorbereitung - Arbeitspakete erarbeiten - Arbeitspakete typisieren - Arbeitspakete beschreiben - Arbeitspakete in zeitliche Abfolge bringen beendet Arbeitsplanerstellung Vorbereitung - Arbeitspakete zusammenfassen & niederschreiben beendet Grobgliederung Meilenst ein - Grobgliederung erst ellen erstellen beendet Abgabe Meilenstein - PDF erzeugen & in St udip hochladen Arbeit splan - fixes Datum beendet Literatur lesen Wissensaneignung - zur Verfügung gestelltes Buch (Software-Qualität) lesen beendet Kapit el 1-3 Meilenst ein - Pflicht kapit el 1-3 gelesen beendet Literaturrecherche Recherche - weitere Literatur suchen - Wissen sammeln / extrahieren --> Stichpunkte beendet Kapit el 9 Meilenst ein - Themenkapitel 9 gelesen beendet erweiterte Literatur lesen Wissensaneignung - weiter führende Literatur bearbeiten / lesen - Stichpunkte erweitern beendet Literaturverzeichnis erstellen schriftliche Ausarbeitung - Literatur nach wissenschaftlichen Vorgaben aufbereiten beendet Feingliederung Meilenst ein - Grobgliederung erw eit ern & Themen eingrenzen beendet Ausarbeitung schriftliche Ausarbeitung - Facharbeit mit "Leben" füllen - Ergebnisse in einzelnen Kapiteln beschreiben beendet Kapit elausarbeit ung I Meilenst ein - Kapitel 2 & 3 ausgearbeit et (nach Grobgliederung v ) beendet Dokumentenvorbereitung schriftliche Ausarbeitung - Grafiken anfertigen & in Text einarbeiten 15 & beendet Kapit elausarbeit ung II Meilenst ein - Kapitel 1 & 4 ausgearbeit et (nach Grobgliederung v ) beendet vorläufiger Dokumentenabschluss Präsentation Vorbereitung Abgabe Vorabversionen Feintuning schriftliche Ausarbeitung schriftliche Ausarbeitung Meilenstein - fixes Datum schriftliche Ausarbeitung - Dokumentenvorlage überarbeiten - Abbildungsverzeichnis, etc. erstellen - Korrektur Fußnoten, Verweise beendet - Auswahl PPT-Vorlage - Erstellen der PowerPoint Unterlagen beendet - Semest erprojekt als PDF in St udip hochladen beendet - Kapitel nachbearbeiten / korrigieren / erweitern / abschließen beendet Präsentation Vorbereitung - Vorbereiten der Präsentation Vorbereitung (Trockenübung) beendet Überprüfung Meilenst ein - Überprüfung der Dokument e - Abgabe-Dokument e anfert igen beendet Abgabe Semest erprojekt Meilenstein - fixes Datum - abgeschlossenens Semest erprojekt in St udip hochladen beendet Vort rag Meilenstein - Präsent at ion des Semesterprojekt es Semest erprojekt - fixes Datum in Hannover gestart et Abbildung 1: Arbeitsplan (Stand ) ~ 7 ~

8 3. Vorstellung des Themas In dieser Semesterarbeit wird das Thema Projektmanagement und Software- Qualität behandelt. Hierbei soll zum Einen das Projektmanagement, wie auch die Software-Qualität vorgestellt werden. Zum Anderen sollen beide Themen in Zusammenhang gebracht werden Eingrenzung Diese Semesterarbeit wird nicht in aller Tiefe das Projektmanagement und die Software-Qualität beschreiben, sondern nur Beispiele beider Themen aufgreifen und diese dann in Einklang bringen. Der Computer hat nahezu in allen Lebensbereichen Einzug gehalten und ist für fast alle Arbeiten ein ständiger Begleiter. Je mehr jemand auf den Computer angewiesen ist, um so wichtiger wird die Zuverlässigkeit der Hard- und Software. Die Software-Qualität wird sicherlich von jedem Benutzer anders bewertet, denn jeder Anwender hat andere Erwartungen und Ansprüche an die benutzte Software. Diese subjektive Betrachtung wird in dieser Arbeit komplett außer Acht gelassen, ich werde mich ausschließlich auf messbare generische Ansätze beziehen. Das Projektmanagement ist ein sehr weitläufiges Gebiet, in dieser Arbeit sollen nur drei weitverbreitete Strukturen, sowie drei Vorgehensmodelle beispielhaft dargestellt werden. Hauptaugenmerk liegt dann auf der Vernetzung von Software-Qualität und Projektmanagement ~ 8 ~

9 3.2. Definition Software-Qualität Ich möchte folgende drei Definitionen für Software-Qualität aufgreifen. Software ist die Gesamtheit der Merkmale und Merkmalswerte eines Software- Produkts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen Begriff: Ein Softwareprodukt weist wie andere Produkte bestimmte Qualitätseigenschaften auf. Die Qualität wird hauptsächlich von der Vorgehensweise bei der Herstellung beeinflusst. 2. Merkmale der Softwarequalität: In der Literatur werden unterschiedliche Aufschlüsselungen der Merkmale genannt, z.b. Verständlichkeit, Korrektheit, Zuverlässigkeit, Benutzerfreundlichkeit, Wartungsfreundlichkeit, Portabilität, Universalität, Robustheit, Effizienz eines Softwareprodukts. [ ] 4. Konsequenzen: Die Merkmale der Softwarequalität bildeten den Ausgangspunkt für die Entwicklung von Prinzipien, Methoden und Werkzeugen des Software Engineering, v.a. für Softwareentwurfsprinzipien, Softwareentwurfsmethoden, Softwarequalitätssicherung. 3 Softwarequalität ist ein mehrdimensionales Konstrukt, das im Anwendungsfall durch Verfeinerung der Merkmale auf der obersten Abstraktionsebene in Teilmerkmale und weiter in Maße operationalisiert werden muss. Qualitätsmerkmale von Software sind nach ISO/IEC 9126 Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit und Portabilität. 4 2 DIN-ISO 9126/Hoffmann, Prof. Dr. Dirk W.: Software-Qualität. Berlin: Springer-Verlag, Lackes, Prof. Dr. Richard Lackes/Siepermann, Dr. Markus.: Softwarequalität. [ ] 4 Herzwurm, Georg/Mikusz, Martin.: Qualitätsmerkmale von Software. wirtschaftsinformatik.de/lexikon/is-management/systementwicklung/management-der- Systementwicklung/Software-Qualitatsmanagement/Qualitatsmerkmale-von-Software [ ] ~ 9 ~

10 Software-Qualität ist also in erster Hinsicht subjektiv und schwer zu definieren, ein Softwareprodukt mag für Person A alle Kriterien erfüllen, Person B jedoch fehlen entscheidende Merkmale. Nicht nur die Definition von Software-Qualität, sonder auch die Messbarkeit von Software-Qualität scheint auch in der Praxis schwierig. Fest steht ob ein Softwareprodukt als gut bezeichnet wird, muss es in Hinsicht Usability erfolgreich sein und dem Anwender bei seiner Tätigkeit unterstützen Definition Projektmanagement Die Definition von Projektmanagement möchte ich mit folgenden vier Zitaten einleiten: Gesamtheit von Führungsaufgaben, -organisation, -techniken und mittel für die Abwicklung eines Projektes. 5 Ja, mach nur einen Plan Sei nur ein großes Licht! Und mach' dann noch 'nen zweiten Plan Geh 'n tun sie beide nicht. 6 Projektmanagement wird als Managementaufgabe gegliedert in Projektdefinition, Projektdurchführung und Projektabschluss. Ziel ist, dass Projekte richtig geplant und gesteuert werden, dass die Risiken begrenzt, Chancen genutzt und Projektziele qualitativ, termingerecht und im Kostenrahmen erreicht werden. 7 5 DIN 69901/Steinle, Claus/Bruch, Heike.: Controlling. Kompendium für Ausbildung und Praxis. 3. Auflage. Stuttgart: Schäffer-Poeschel Verlag, Brecht, Bertold: Die Dreigroschenoper 7 Hobel, Bernhard/Schütte, Silke.: Projektmanagement(PM). [ ] ~ 10 ~

11 Projektmanagement beinhaltet ein autarkes Verfahren, mit dem definierte Aufgaben in einem Unternehmen oder einer Organisation durchgeführt werden. [ ] Jedes Projekt hat festgelegte, terminierte Anfangs- und Endpunkte. Die Verantwortung und die Kompetenzen sind klar geregelt. 8 Uns allen wohl bekannt ist das viel zitierte und dargestellte Projektdreieck, welches die drei Kernkomponenten Ziel, Zeit und Ressource (vgl. Abbildung 2: "Das magische Projektdreieck" ) im Gleichgewicht zeigt. Ein Projekt hat immer die gleichen Eckpunkte, das Budget muss eingehalten werden, Terminvorgaben müssen eingehalten werden und die Qualität muss stimmen. Wird eines dieser Kriterien außer Acht gelassen, so kommt das magische Dreieck aus dem Gleichgewicht und das Projekt ist so gut wie zum Scheitern verurteilt. Ein gutes Projektmanagement kann alle Eckpunkte sicher koordinieren, hat zu jeder Zeit einen Überblick über das Projekt und ist in der Lage auch auf schwierige Einflüsse zu reagieren. Abbildung 2: "Das magische Projektdreieck" 8 Teske, Dipl.-Ing. Klaus.: Projektmanagement: Definition und Bedeutung. [ ] ~ 11 ~

12 4. Projektmanagement Dieses Kapitel gibt einen kurzen Einblick in den Aufbau des Projektmanagements und erläutert drei der bekanntesten Vorgehensmodelle. Dann folgt eine Eingrenzung in Bezug auf Software-Qualität und ein Beispiel für erfolgreiches Projektmanagement in Bezug auf Software-Qualität Projektstrukturen Die drei folgenden Projektstrukturen sind die wohl am Häufigsten vorkommenden, sowie auch die Bekanntesten Stabsprojektorganisation Die Stabsprojektorganisation wird meist in kurzen, wenig risikoreichen Projekten, welche häufig neben dem Tagesgeschäft angesiedelt sind, eingesetzt. Der Projektleiter hat meistens keine Weisungsbefugnis gegenüber den Projektmitarbeitern, diese sind immer noch ihrem Vorgesetzten unterstellt, vergleiche Abbildung 3: Stabsprojektorganisation. Nachteil dieser Projektorganisation ist der hohe Kommunikationsaufwand gegenüber den anderen Abteilungsleitern, diese müssen ihre Mitarbeiter für die jeweiligen Projekte freistellen ~ 12 ~

13 Abbildung 3: Stabsprojektorganisation Vorteil ist der geringe Verwaltungs- und Kostenaufwand, da die Mitarbeiter nur neben der eigentlichen Arbeit dem Projekt zugewiesen sind. Außerdem entstehen keine direkten Projektkosten Reine Projektorganisation In der reinen Projektorganisation sind die Mitarbeiter den einzelnen Projekten zugewiesen und arbeiten ausschließlich für das jeweilige Projekt. Der Projektleiter hat volle Weisungsbefugnis und muss alle Zuständigkeiten für das Projekt managen ~ 13 ~

14 Abbildung 4: Reine Projektorganisation 9 Die reine Projektorganisation ist für große und langfristige Projekte optimal, eine Projektdauer von mindestens einem halben Jahr ist anzusetzen. Als Nachteil, bei schlechter Projektplanung, können für die Mitarbeiter Leerlaufphasen entstehen, die es dann zu überbrücken gilt. Vorteil ist die Bündelung der Projektmitarbeiter und somit auch dessen Wissen, da alle Projektbeteiligten ausschließlich für das Projekt arbeiten entsteht ein starkes Teamgefühl und das Projekt wird als solches auch nach außen kommuniziert und vertreten Matrix Projektorganisation Die Matrix Projektorganisation ist eine Mischvariante aus der reinen Projektorganisation und der Stabsprojektorganisation. Die Mitarbeiter sind während der Projektphase immer noch unter disziplinarischen Weisungsbefugnis des jeweiligen Vorgesetzten, sind aber ausschließlich dem Projekt zugeteilt. Der Projektleiter hat gegenüber den Projektmitarbeitern projektbezogene Weisungsbefugnis, Abbildung 5: Matrix Projektorganisation zeigt die grafische Darstellung. 9 Claus Steinle/Heike Bruch(Hrsg): Controlling. Kompendium für Ausbildung und Praxis. 3. Auflage. Stuttgart: Schäffer Poeschel Verlag, 2003 (Grafik nach Vorgabe selbst angefertigt) ~ 14 ~

15 Abbildung 5: Matrix Projektorganisation 10 Nachteil der Matrix Projektorganisation ist wie schon bei der Stabsorganisation der Einfluss der Abteilungsleiter, die durch die bestehende Weisungsbefugnis den Projektmitarbeiter dem Projekt entziehen können. Der Projektmitarbeiter könnte in einen Wissenskonflikt geraten. Vorteil dieser Projektorganisation ist die Aufgabenverteilung für den Projektmitarbeiter, entstehen lange Ruhepausen, etwa weil auf einen anderen Meilenstein gewartet werden muss, so kann der Mitarbeiter wieder Aufgaben der Abteilung erledigen. Ein weiterer Vorteil ist die hohe Konzentration des Wissens innerhalb des Projektteams. 10 Claus Steinle/Heike Bruch(Hrsg): Controlling. Kompendium für Ausbildung und Praxis. 3. Auflage. Stuttgart: Schäffer Poeschel Verlag, 2003 (Grafik nach Vorgabe selbst angefertigt) ~ 15 ~

16 4.2. Vorgehensmodelle Um ein Projekt erfolgreich durchzuführen, gibt es verschiedene Vorgehensmodelle. Die in der Literatur vorgestellten Modelle sind jedoch nie eins zu eins in einem Projekt umsetzbar, sie müssen immer angepasst werden. Die Vorgehensmodelle verfolgen den idealen Ansatz, ein Projekt jedoch verlangt eine gewisse Flexibilität. Im folgenden sollen die drei wichtigsten Vorgehensmodelle vorgestellt werden Wasserfallmodell Die Mutter aller Vorgehensmodelle ist wohl das Wasserfallmodell, siehe Abbildung 6: Wasserfallmodell, welches 1970 von Winston W. Royce entwickelt wurde. Die Stufen des Wasserfallmodells werden ideologisch betrachtet nach einander durchlaufen, wobei am Ende einer Phase ein Rücksprung in die vorherige Phase möglich ist. Abbildung 6: Wasserfallmodell Wingens, Silke (2010), Testprozess Einbetung in generellen Ablauf [ ] ~ 16 ~

17 Für Royce spielte die Dokumentation der einzelnen Phasen eine wichtige Rolle, so findet sich dieses auch in dem Wasserfallmodell wieder. Nach jeder erfolgreichen Phase müssen bestimmte Dokumente angefertigt sein, welche als Meilensteine dienen und den erfolgreichen Abschluss einer Phase kennzeichnen. Der bereits aus der Grafik ersichtliche Nachteil der Stufen und der stufenweisen Abarbeitung der selbigen, beschreibt am besten die nicht vorhandene Flexibilität. Welche jedoch bei jedem Projekt durch innere und äußere Einflüsse schnell gegeben sein muss. Wie sicherlich hinreichend bekannt, ändern sich (gerade bei großen und längeren Projekten) die Projektziele, Projektteilziele oder Projektvariablen. Als Vorteil sehe ich hier die klare Abgrenzung der einzelnen Phasen und die zu erstellenden Dokumente. Gerade in der Projektarbeit, wo die Mitarbeiter meist unter Zeitdruck stehen um Termine einzuhalten wird die Dokumentation meist außer Acht gelassen V-Modell Das V-Modell, siehe Abbildung 7: V-Modell ist eine Erweiterung des zuvor beschriebenen Wasserfallmodells. Besonders herauszuheben ist, dass die einzelnen Phasen links immer in Testphasen rechts enden. Ein weiteres Merkmal, wie auch in der Grafik zu sehen, ist der Detaillierungsgrad und die Zeit. Je detaillierter die Entwicklungsphasen, desto schneller können Testfälle erstellt und bearbeitet werden ~ 17 ~

18 Abbildung 7: V-Modell 12 Als Vorteil sei hier der Detaillierungsgrad der einzelnen Phasen zu nennen, das V- Modell beschreibt genau das Was, Wie und Womit um ein Softwareprojekt erfolgreich durchzuführen. Der Nachteil ist der hohe bürokratische Aufwand, den ein Projektteam aufbringen muss um das V-Modell umzusetzen. Ebenso aufwändig ist die Mitarbeiterschulung in dem Modell, es eignet sich daher eher für große Projekte Prince 2 Mit dem Vorgehensmodell PRINCE2 wurden verschiedene Vorgängermodelle gebündelt, das einstige IT-Projektmodell hat sich als generischer Ansatz zur Projektkoordination, Projektplanung, Projektsteuerung und Projektmanagement branchenunabhängig etabliert. Wie in Abbildung 8: PRINCE2 ersichtlich, ist Prince in acht gleichgroße Stücke unterteilt, diese stellen die Kern-Phasen dar. Die Subprozesse werden anhand der blauen Boxen dargestellt. Die einzelnen Kern-Phasen sollen von dem jeweiligen Projektleiter kontinuierlich beachtet und abgearbeitet werden. Für das erfolgreiche 12 Voigt, Dirk (2011) Projektphasen und Meilensteine [ ] ~ 18 ~

19 bearbeiten der Kern-Phasen sollen die Subprozesse genutzt werden. Wichtig hierbei ist, dass die Subprozesse als Teil jeder Kern-Phase zu sehen ist. Abbildung 8: PRINCE2 13 Im Gegensatz zu den bereits vorgestellten Vorgehensmodellen wird bei PRINCE2 das Augenmerk auf das Projektmanagement und nicht auf die Produkterstellung gelegt. Als Basis dienen sieben Grundprinzipien, die nicht verändert werden dürfen, siehe 7.1 PRINCE2 Grundprinzipien. Ein Vorteil ist die starke Ausrichtung in Bezug auf das Projektmanagement, so wird das Ziel des Projektes die gesamte Projektphase im Auge behalten. Gegebenenfalls werden Teilprojekte angepasst, Ziel ist nicht mehr die Erstellung eines Produktes, sondern die erfolgreiche Umsetzung an Hand des Projektziels. Als weiterer Vorteil sei genannt, dass es für jedes zu erstellende Dokument bereits PRINCE2-Vorlagen gibt, die von dem jeweiligen Projekt genutzt werden können. 13 Koord, Y./Krauter, V. (2009): Überblick Vorgehensmodelle im Projektmanagement [ ] ~ 19 ~

20 Ein Nachteil ist die starke Verankerung von PRINCE2 im Unternehmen, bestehende Unternehmensprozesse müssen für die erfolgreiche Umsetzung von PRINCE2 angepasst werden. Demzufolge entstehen Investitionskosten, die sich allerdings nach erfolgreicher Einführung amortisieren Eingrenzung in Bezug auf Software-Qualität Projektmanagement in Bezug auf Software-Qualität hat seine Vor- aber auch Nachteile, wie bereits erwähnt kann es gerade bei Softwareprojekten durch äußere und innere Einflüsse zu unvorhersehbaren Reaktionen kommen, so dass ein starres Vorgehensmodell nicht mehr umzusetzen ist. Hier wäre zum Beispiel die Änderung von gesetzlichen Bestimmungen zu nennen, welche dazu führen kann, dass ein Softwareentwicklungsprojekt das bereits entwickelte Programm runderneuern muss. Wird eine Firma von einer anderen aufgekauft, so könnte sich die Unternehmenskultur ändern und somit eventuell auch das Projektziel bzw. die Projektvariablen. Ein striktes Vorgehen nach Projektvorgehensmodell ist dann nicht mehr möglich. Die Vorteile des Projektmanagements, welche aber nicht nur bei Software-Projekten ersichtlich sind, sind die definierten Meilensteine und abgeschlossenen Projektphasen. Jeder Projektmitarbeiter kann so das Projekt besser greifen und auf (Teil-)Ziel(e) hinarbeiten. In Bezug auf Software sind Dokumente sehr wichtig, denn jede Arbeitskraft könnte, ob nun auf eigenen Wunsch oder den Wunsch des Vorgesetzten, von heute auf morgen ausgetauscht werden und dann sind Dokumentationen nötig um das Programm zu bedienen und/oder zu warten. Das Projektmanagement ist zum Einen wichtig für die Software-Entwicklung, sprich die Planung der Entwicklung und der Entwicklungszyklen, zum Anderen auch für die Software-Qualität, im Bezug auf Tests, vorhandene Dokumentationen und Abgabeterminen ~ 20 ~

21 5. Software-Qualität Dieses Kapitel stellt die Reifegradmodelle CMM, CMMI, sowie Richtlinien der DIN-Norm und des IEEE vor. Die Software-Qualität ist rein subjektiv bei jedem Anwender pro Produkt unterschiedlich, um jedoch eine allgemeingültige Messung der Software-Qualität zu gewährleisten, wurden verschiedene Reifegradmodelle und Richtlinien entworfen. In den folgenden Kapiteln werden die bekanntesten Modelle CMM, CMMI und verschiedene Richtlinien kurz vorgestellt Reifegradmodelle Zur Überwachung der Software-Qualität wurden so genannte Reifegradmodelle entwickelt, welche die Prozesse bewerten und optimieren sollen. Der aktuelle Reifegrad wird in einem Modell meist durch drei Eigenschaften charakterisiert, das Stufenmodell selbst, welches die Reife des Unternehmens beschreibt. Die Anforderungen und Maßnahmen, diese sind mit dem Reifegrad verbunden und müssen von dem Unternehmen umgesetzt sein um den Reifegrad zu erreichen. Letztendlich die Prüfung des Reifegrads, welche in der Literatur als Assessments bezeichnet werden CMM Das CMM wurde entwickelt um formale Modelle zu vereinen und daraus den größtmöglichen Nutzen zu ziehen. Das Modell, vergleiche Abbildung 9: CMM - Capability Maturity Models, beschreibt fünf Stufen, die ein Unternehmen durchlaufen muss. In die erste Stufe Initial Level werden alle Unternehmen eingegliedert. In der zweiten Stufen Repeatable Level muss ein Unternehmen sich durch ein Projektmanagement und das damit verbundene geplante und dokumentierte Vorgehen unter Beweis stellen. Schlagworte für Stufe zwei sind Anforderungsmanagement, Konfigurationsmanagement, Qualitätssicherung ~ 21 ~

22 In der dritten Stufe Defined Level werden die zuvor erwähnten Projektmanagementvorgehen auf das Unternehmen ausgeweitet. Es gibt ein unternehmensweites Vorgehensmodell, welches für spezielle Projekte angepasst werden kann. In dieser Stufe befindet sich auch die Schulung der Mitarbeiter, die Qualität wird vertieft. Abbildung 9: CMM - Capability Maturity Models 14 Im Managed Level, der vierten Stufe des CMM, werden die Projekte überwacht und es erfolgt eine Kosten-, Aufwands- und Terminschätzung. Diese Maßnahmen dienen dem Management als Frühwarnsystem für eine Abweichung des Projekts. Ein Unternehmen das die letzte Stufe Optimizing Level erreicht hat, zeichnet sich durch optimierende Prozesse und ein qualitatives Anforderungsmanagement aus. Auf Veränderungen kann mit hoher Effizienz reagiert werden. 14 E-Style Software Corp. ( ) What is CMM [ ] ~ 22 ~

23 CMMI Das CMM wurde speziell für die Software-Entwicklung entwickelt, durch die Popularität aber vermehrt auch in anderen Bereichen eingesetzt. Die SEI entschloss sich daher das Modell für andere Modelle zu erweitern und vereinte im CMMI die Bereiche System engineering, Software aquisition, Integrated product development und Human Ressource. Dabei hatte die SEI die drei folgenden Ziele im Auge: - Universalität - Flexibilität - Kompatibilität Abbildung 10: Beispiel CMMI 15 Wesentlicher Unterschied zum Vorgängermodell CMM ist die Auflösung der Stufenstruktur. Das Modell wird zwar noch in Stufen/Bereiche gegliedert, maßgebend sind jedoch die Reife einzelner Schlüsselbereiche. Hierbei wird jedem Schlüsselbereich ein so genannter Capacity Level von 0 5 zugewiesen. Der jeweilige Reifegrad ist 15 Unbekannt: Unbekannt. [ ] ~ 23 ~

24 erreicht, wenn alle Schlüsselbereiche einer Stufe/eines Bereichs das Capacity Level 3 erreicht haben. Wie in Abbildung 10: Beispiel CMMI ersichtlich, kann ein Unternehmen die verschiedenen Schlüsselbereiche je nach Machbarkeit abarbeiten, eine Stufe muss nicht mehr beendet werden bevor die nächste starten kann DIN / ISO / IEEE Die DIN stellt Normen für die Wirtschaft, den Staat und die Gesellschaft bereit. Alle Normen können auf freiwilliger Basis von dem jeweiligen Unternehmen umgesetzt werden. Seitens der Bundesregierung besteht ein Vertrag, welches die DIN als die nationale Normungsorganisation (europäisch und international) anerkennt. Die ISO wurde 1947 gegründet und hat als Ziel die weltweite standardisierte Entwicklung von Normen um den Austausch von internationalen Waren- und Dienstleistungen zu Erleichtern. Außerdem soll die ISO die Zusammenarbeit im Bereich wissenschaftlicher, technologischer und wirtschaftlicher Aktivitäten begünstigen und fördern. Das IEEE hat mehr als 130 Standards in dem Bereich Softwareengineering entwickelt, der Berufsverband aus Ingenieuren hat seinen Sitz in New York. Das IEEE erstellt mit Hilfe verschiedener Arbeitsgruppen Standardisierungen für internationale Anwendungen, Hauptgebiete sind die Raumfahrt, die Telekommunikation und die Ingenieurstechniken Im Folgenden werden einige der Richtlinien von den verschiedenen Organisationen vorgestellt ISO 900x:2000 Die Norm ISO 900x:2000 umschreibt Standards für Qualitätsmanagement und Qualitätssicherung. Sie besteht aus den folgenden drei Abschnitten: - ISO 9000:2000 QMS Grundlagen und Begriffe - ISO 9001:2000 QMS Anforderungen - ISO 9004:2000 QMS Leitfaden für Leistungsverbesserung ~ 24 ~

25 In Bezug auf Software-Qualität ist der Abschnitt 9001:2000 relevant, hier werden Anforderungen für den Entwurf, die Entwicklung, die Dienstleistung und die Produktion von qualitativen Produkten genannt. Diese Norm ist nicht nur für Software-Produkte, sondern für jegliche Produkte erstellt worden. Sie liefert ein standardisiertes Vorgehen für die Mindestanforderungen eines Qualitätsmanagementsystems DIN-ISO 9126 Die DIN-ISO 9126 versteht unter Software-Qualität die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, nach Norm sind das folgende Qualitätsmerkmale: - Funktionalität: Inwieweit besitzt die Software die geforderten Funktionen? - Zuverlässigkeit: Kann die Software ein bestimmtes Leistungsniveau unter bestimmten Bedingungen über einen bestimmten Zeitraum aufrechterhalten? - Benutzbarkeit: Welchen Aufwand fordert der Einsatz der Software von den Benutzern und wie wird er von diesen beurteilen? - Effizienz: Wie liegt das Verhältnis zwischen Leistungsniveau der Software und eingesetzten Betriebsmitteln? - Änderbarkeit: Welchen Aufwand erfordert die Durchführung vorgegebener Änderungen an der Software? - Übertragbarkeit: Wie leicht lässt sich die Software in eine andere Umgebung übertragen? DIN-ISO/IEC Die DIN-ISO/IEC wurde entwickelt um Software auf bestimmte Anforderungen zu testen, dabei wird die Norm je nach Softwaretyp individuell auf die zu prüfende Software angepasst. 16 Unbekannt: [ ] ~ 25 ~

26 Geprüft wird im allgemeinen die richtige Funktion der Software, wie häufig stürzt das Programm ab, gibt es Datenverlust oder wurden Daten zerstört. Es wird auch überprüft, ob das Programm beispielsweise beim Löschen oft genug gefragt hat und Hinweise gegeben hat. Ebenso wird die Installation und das Installationspaket überprüft und bewertet IEEE Std 730 & IEEE Std 830 Die IEEE Std 730 beschreibt den Software-Qualitätssicherungsplan (SQAP), welcher zugleich bei der Erstellung des selbigen genutzt werden kann. Die IEEE Std 830: Software-Anforderungsspezifikationen (SRS) beschreibt die Spezifikation von Software, hierunter fallen das Pflichten- und das Lastenheft Abgrenzung Reifegradmodelle vs DIN / ISO / IEEE Reifegradmodelle dienen zur Optimierung und Bewertung der Unternehmensprozesse, Normen werden von den verschiedenen Gremien für einen internationalen Qualitätsaustausch definiert. Wer heute in seinem Unternehmen nach den bestehenden Normen oder Reifegradmodellen zertifiziert ist zeigt der Außenwelt, und somit potentiellen Kunden, Partnern oder Zulieferern, dass Prozessabläufe und Qualität im eigenen Unternehmen messbar sind ~ 26 ~

27 6. Zusammenfassung / Ergebnisse Wie die vorgestellten Kapitel herausgestellt haben, gibt es in der heutigen Arbeitswelt in jedem Fachgebiet verschiedene Modelle, die das Arbeiten erleichtern und strukturieren sollen. Da wären die Organisationsstrukturen, welche die Mitarbeiter eines Unternehmens weisen und lenken sollen, die Vorgehensmodelle um Projekte zur richtigen Zeit mit dem richtigen Budget und der richtigen Anzahl an Ressourcen zum Abschluss zu bringen. Und letztendlich die Reifegradmodelle um die Unternehmensqualität mit Hilfe der zuvor angesprochenen Modelle und Strukturen zu bewerten. Es wird immer wieder versucht Struktur und Ordnung in jeden Arbeitsablauf unterzubringen, die Vorteile der strukturierten Vorgehensweise wie Risikoreduzierung, Transparenz des Projektes, zeitliche Terminierung oder auch Dokumentenbereitstellung liegen klar auf der Hand. Jedoch dürfen auch die Nachteile, stetiger Termindruck, Zeitmangel, Kostenersparnis oder fehlendes Verständnis für die Vorgehensmodelle nicht vergessen werden. Nach meiner Internetrecherche musste ich feststellen, dass 42 Prozent der deutschen Firmen, das Budget für die Qualitätssicherung von Software und Software-Test erhöht haben [vgl. 11]. Unternehmen aus Schwellenländern (China 83%, Brasilien 56%) ihre Budgets für die Software-Qualitätssicherung am stärksten erhöhen. Der Nutzung der DIN / ISO / IEEE Normen wird ein geringer Verbreitungsgrad ausgestellt, so sollen weniger als 30 % die ISO Norm 9126 benutzen. Die Unternehmen nutzen oft die eigenen erstellten Qualitätsmodelle. Oft werden die Vorgehensmodelle nicht richtig angewandt, da Unternehmenskultur, Projektziel oder Projektverständnis nicht mit dem Projektteam übereinstimmen. Ich finde alle dieser Modelle sehr idealistisch und konnte in meinem bisherigen Berufsleben nicht feststellen dass ein Unternehmen nach solchen Modellen gearbeitet hat. Vielmehr musste ich immer wieder feststellen dass in der heutigen globalisierten und schnelllebenden Welt ein dauernder Termindruck herrscht und gerade zu Projektabschluss jegliche Vorgehen außer Acht gelassen werden. Hier gibt mir ein Internetartikel [vgl. 16] Recht, in welchem gesagt wird, dass 60% der Unternehmen die Maßnahmen zur Gewährleistung von Qualität bei Software nicht konsequent durchführen. Als Hauptgrund ist hier die mangelnde Unterstützung der Unternehmensleitung aufgeführt ~ 27 ~

28 7. Anhang 7.1. PRINCE2 Grundprinzipien Abbildung 11: Grundprinzipien PRINCE OGC: Erfolgreiche Projekte managen mit PRINCE2, Seite 11 ff ~ 28 ~

29 8. Abkürzungsverzeichnis C CMM Capability Maturity Model... 23, 24, 25 CMMI Capability Maturity Model Integration... 23, 25, 26, 32, 33, 35 D DIN Deutsches Institut für Normung e.v , 12, 23, 26, 27, 28, 29 I IEC International Electronical Comission International Electronicas Comission IEEE Institute of Electrical and Electronics Engineers... 23, 26, 28, 29 ISO International Organisation for Standardization... 11, 26, 27, 28, 29, 34 P PRINCE2 PRojects IN Controlled Environment... 20, 21, 22, 30, 33, 34 S SEI Software Engineering Institute SQAP Software Quality Assurance Plan SRS SOftware Requirements Specification ~ 29 ~

30 9. Quellen Es folgen die genutzten Quellen Literarische Quellen [I] Claus Steinle/Heike Bruch(Hrsg): Controlling. Kompendium für Ausbildung und Praxis. 3. Auflage. Stuttgart: Schäffer Poeschel Verlag, 2003 [II] Hoffmann, Dirk W.: Software-Qualiät. Berlin Heidelberg: Springer-Verlag, 2008 [II] Liggesmeyer, Peter: Software-Qualität: Testen, Analysieren und Verifizieren von Software. Spektrum Akademischer Verlag, 2002 [IV] Wallmüller, Ernest: Software Quality Engineering - Ein Leitfaden für bessere Software-Qualität. 3. Auflage. München: Carl Hanser Fachbuchverlag, 2011 [V] Von Kneuper, Ralf (Hrsg)/Wallmüller, Ernest: CMMI in der Praxis. Fallstudie zur Verbesserung der Entwicklungsprozesse mit CMMI. Heidelberg: Dpunkt Verlag, 2009 [VI] Will, Hermann: Mini-Handbuch Vortrag und Präsentation von Hermann Will. Weinheim: Beltz Verlag, Internetquellen [1] Arbeitskreis Software-Qualität und Fortbildung e.v.: Internetseite im Allgemeinen. [ ] [2] Bergmann, Sebastian/Priebsch, Stefan (2010): Real-World Solutions for Developing High-Quality PHP Frameworks and Applications. [ ] [3] Carnegie Mellon University (20100): Internetseite im Allgemeinen ~ 30 ~

31 [ ] [4] Creative Commons Attribution/Share Alike (2011): PRINCE2. [ ] [5] Foegen, Malte (2011): Die ganze Wahrheit über CMMI. [ ] [6] Foegen, Malte/Battenfeld, Jörn/Raak, Claudia (2007): CMMI ein Werkzeug zur Prozessverbesserung. [ ] [7] Gerber, Neil/Ray, Terry: Smarter Nuclear Power: Using a Maturity Model to Help Prepare for the Nuclear Renaissance. [ ] [8] Happe, Rachel (2009): The Community Maturity Model. [ ] [9] Herzwurm, Georg/Mikusz, Martin (2011): Qualitätsmerkmale von Software. management/systementwicklung/management-der-systementwicklung/software- Qualitatsmanagement/Qualitatsmerkmale-von-Software [ ] [10] Hobel, Bernhard/Schütte, Silke: Projektmanagement (PM). [ ] [11] IBM: Software-Testing und Software-Qualität. [ ] [12] Jacobs, Stephan (2009): Vorgehensmodelle für das IT-Projektmanagement. [ ] [13] Neumann, Alexander (2010): Für eine bessere Software ~ 31 ~

32 [ ] [14] Neumann, Alexander (2009): Gut geprüft, ist halb gewonnen. Testmanagement html [ ] [15] Neumann, Alexander (2010): Studie: Softwarefirmen entwickeln vorrangig nach eigenem Qualitätsmodell. [ ] [16] Neumann, Alexander (2011): Zu wenig sichere Prozesse und Verfahren im Softwarelebenszyklus. Softwarelebenszyklus html [ ] [17] Kirsch, Christian (2009): Ein neuer Standard für Softwarequalität html [ ] [18] Kliewe, Michael (2011): Softwarequalität in PHP Projekten. [ ] [19] Koord, Y./Krauter, V. (2009): Überblick Vorgehensmodelle im Projektmanagement. ( [ ] [20] Lackes, Prof. Dr. Richard Lackes/Siepermann, Dr. Markus: Softwarequalität. [ ] [21] PRINCE2 Deutschland e.v.: Internetseite im Allgemeinen. [ ] [22] Prof. Dr. Klein, Martin: ISO. [ ] ~ 32 ~

33 [23] Prof. Dr. Krems, Burkhardt (2011): Projekt / Projektmanagement. [ ] [24] Software-Initiative Deutschland e.v.: Internetseite im Allgemeinen. [ ] [25] TEIA Internet Akademie Lehrbuch Verlag: 5 Projektorganisationen /31279-Projektorganisation.html [ ] [26] Teske, Klaus: Projektmanagement: Definition und Bedeutung. [ ] [27] TU-München Fakultät für Informatik: Software-Qualität. [ ] [28] TÜVRheinland: Software-Qualiät. [ ] [29] Unbekannt: Softwarequalität. [ ] [30] Unbekannt: Unbekannt. 8/s1600/CMMI [ ] [31] Voigt, Dirk (2011): Projektphasen und Meilensteine. [ ] [32] Wingens, Silke (2010): Testprozess Einbetung in generellen Ablauf. [ ] ~ 33 ~