Inhaltsverzeichnis

1.  Einleitung  1

2.  Ziele und QS-Maßnahmen  3

2.1.  Definitionen  3

2.2.  Beispielserie: Benzinverbrauch minimieren  4

2.3.  Beispielserie: Softwarequalit atsziele  8

3.  Software Engineering Modelle  11

3.1.  Qualit atsmodelle  12

3.1.1.  Beispiel: ISO/IEC 9126  13

3.1.2.  Beispiel: ISO/IEC 9126 im Test  14

3.1.3.  Beispiel: Capgemini sd m Softwareblutbild  15

3.2.  Ergebnistypmodelle  16

3.2.1.  Beispiel: Anwendungsfallmodell  17

3.2.2.  Beispiel: Architekturmodell  18

3.2.3.  Beispiel: Testfallmodell  19

3.3.  Prozessmodelle  20

3.3.1.  Beispiel: Wasserfallmodell  21

3.3.2.  Beispiel: SCRUM - Agiles Entwicklungsmodell  22

3.3.3.  Beispiel: Testprozessmodell gem aß ISTQB  23

3.4.  Rollenmodelle  24

3.4.1.  Beispiel: Rollen entlang des Wasserfalls  25

3.4.2.  Beispiel: SCRUM Entwicklerrollen  26

3.4.3.  Beispiel: Testrollen gem aß ISTQB  27

iii

Inhaltsverzeichnis

4.  Stand der Forschung  29

4.1.  Anpassen von Qualit atsmodellen  30

4.1.1.  Aktivit atenbasiertes Qualit atsmodell  31

4.1.2.  Produktbasiertes Qualit atsmodell: COTS Taxonomie  36

4.1.3.  Spezialisiertes Qualit atsmodell: QUIM  44

4.1.4.  Zielorientiertes Qualit atsmodell: Goal Question Metric  51

4.2.  Zwischenstand  57

4.3.  Anwenden des GQM Ansatzes  60

4.3.1.  Software Engineering Laboratory  60

4.3.2.  Explizite Projektpl ane  65

4.4.  Zusammenfassung  68

5.  Multidimensionale Qualit atsziele und integrierte QS-Maßnahmen  69

5.1.  Anpassen der Modelle des Zielraums  70

5.1.1.  Welche Probleme existieren im GQM Ansatz?  70

5.1.2.  Wie werden die Probleme gel ost?  71

5.1.3.  Wie sieht das zugrunde liegende Modellsystem aus?  74

5.1.4.  Wie funktioniert der Anpassungsprozess?  83

5.1.5.  Wozu? Wo? Wann? Wer? Wie?  89

5.2.  Anwenden des Zielraums  89

5.2.1.  Methodenbereich und Projektorganisationen  89

5.2.2.  Kontinuierlicher Verbesserungsprozess  91

5.3.  Zusammenfassung  95

6.  Evaluation  97

6.1.  QP.1 Qualit atsplan einrichten  98

6.1.1.  Szenario 1 - Traditionelles Entwicklungsprojekt  98

6.1.2.  Szenario 2 - Traditionelles Testprojekt  100

6.1.3.  Szenario 3 - Agiles Entwicklungsprojekt  102

6.2.  QP.2 Qualit atsziele formulieren  104

6.2.1.  Vorgehensweise  104

6.2.2.  Auswertung der Qualit atspl ane  106

6.3.  Fazit  113

7.  Ausblick  117

7.1.  SE 2008: Forschungsagenda  117

7.2.  Werkzeugunterst utzung  119

iv

Inhaltsverzeichnis

Literaturverzeichnis   121

A.  B ackereiprojekt: Scope Statement  129

B.  B ackereiprojekt: Referenzqualit atsziele  133

C.  Auszug aus QSM Katalog  135

D.  ocomse: Prototypische Implementierung  137

v

Abbildungsverzeichnis

2.1. Definition des Begriffs Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Autofahrziel I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3. Autofahrziel II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4. Autofahrziel III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5. Autofahrziel IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.6. Autofahrziel V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.7. Modelle als Zieldimensionen . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.8. Softwarequalit¨ atsziel I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.9. Softwarequalit¨ atsziel II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.10. Softwarequalit¨ atsziel III . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1. Oben: FCM, unten: GQM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Aufbau der ISO/IEC 9126 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. F¨ ur den Test angepasste ISO/IEC 9126 [ZVS ⁺ 07, S.234] . . . . . . . . . 14 3.4. Capgemini sd&m Software-Blutbild [Hof08, S.20] . . . . . . . . . . . . . 15 3.5. Ergebnistypmodelle im Lebenszyklus einer Software . . . . . . . . . . . . 16 3.6. Struktur eines Anwendungsfalls nach [Fro09, S.25f] . . . . . . . . . . . . 17 3.7. Architekturmetamodell gem¨ aß [VAC ⁺ 09, S.47] . . . . . . . . . . . . . . . 18 3.8. Attribute eines Testfalls nach [SBS09, S.91] . . . . . . . . . . . . . . . . . 19 3.9. Teilprozesse mit ¨ Ubergabeobjekt und Quality Gate (QG) . . . . . . . . . 20

3.10. Wasserfallmodell [Roy87, S.329] mit QGs . . . . . . . . . . . . . . . . . . 21 3.11. SCRUM Entwicklungsprozess nach [Sch95] mit QGs . . . . . . . . . . . . 22 3.12. Fundamentaler Testprozess [SL04, S.18] und [SBS09, S.12] mit QGs . . . 23 3.13. Rollenmodell als Organigramm . . . . . . . . . . . . . . . . . . . . . . . 24 3.14. Rollen entlang des Wasserfalls . . . . . . . . . . . . . . . . . . . . . . . . 25

vii

Abbildungsverzeichnis

3.15. SCRUM Rollenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.16. ISTQB Testrollen gem¨ aß [SL04, S.147f] . . . . . . . . . . . . . . . . . . . 27

4.1. Metamodell f¨ ur aktivit¨ atenbasierte Qualit¨ atsmodelle [DWP ⁺ 07, S.6] . . . 32

4.2. Beispiel f¨ ur Schritt 4: Wartungsmatrix [WDW08, S.30] . . . . . . . . . . 34 4.3. Fundamentales Modell f¨ ur COTS Taxonomien [CFQT04, S.2] . . . . . . . 38 4.4. Beispiel f¨ ur Kategorien und Dom¨ anen [BIC ⁺ 02, S.265] . . . . . . . . . . . 38

4.5. Qualit¨ atsmetamodell der ISO/IEC 9126 [FC02, S.2] . . . . . . . . . . . . 39 4.6. Beispiel f¨ ur Schritt 2: Qualit¨ atsmodell f¨ ur ERP Systeme [BBC ⁺ 03, S.232] 41

4.7. Beispiel f¨ ur Schritt 6: Beziehungsmatrix f¨ ur Mail Server [FC02, S.6] . . . 42 4.8. QUIM Metamodell [SKD01, S.3] . . . . . . . . . . . . . . . . . . . . . . . 45 4.9. Beziehungen im QUIM Modell [SKD01, S.4] . . . . . . . . . . . . . . . . 46 4.10. QUIM Metamodell mit Quellen [SKD01, S.3] . . . . . . . . . . . . . . . . 48 4.11. GDQA zum Ableiten von Funktionen [BKA01, S.7] . . . . . . . . . . . . 49 4.12. Durch GDQA abgeleitete Funktionen [BKA01, S.7] . . . . . . . . . . . . 49 4.13. GQM im ER-Schema [OB92, S.895] . . . . . . . . . . . . . . . . . . . . . 53 4.14. GQM Template [OB92, S.895] . . . . . . . . . . . . . . . . . . . . . . . . 54 4.15. Integration von GQM in das QIP [LSO ⁺ 98, S.80] . . . . . . . . . . . . . 55

4.16. F¨ ahigkeit der Ans¨ atze zum Beantworten der Fragen . . . . . . . . . . . . 58 4.17. Quality Improvement Paradigm [BC95, S.58] . . . . . . . . . . . . . . . . 61 4.18. Experience Factory [BC95, S.59] . . . . . . . . . . . . . . . . . . . . . . . 64 4.19. Software Engineering Modelle und GQM [OB92, S.888] . . . . . . . . . . 65 4.20. Verbesserungsorientierte Organisationsstruktur [LR93, S.3] . . . . . . . . 66

5.1. Modelle als Zieldimensionen . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2. Multidimensionaler Zielraum: Qualit¨ atsziele . . . . . . . . . . . . . . . . 74 5.3. Konzeptionelles Datenmodell (nur Ziele) . . . . . . . . . . . . . . . . . . 76 5.4. Multidimensionaler Zielraum: QS-Maßnahmen . . . . . . . . . . . . . . . 77 5.5. Konzeptionelles Datenmodell (konstruktive QS-Maßnahmen) . . . . . . . 79 5.6. Konzeptionelles Datenmodell (analytische QS-Maßnahmen) . . . . . . . . 81 5.7. Konzeptionelles Datenmodell (Metrikwerte) . . . . . . . . . . . . . . . . 82 5.8. Prozess f¨ ur Softwarequalit¨ at . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.9. Template zum Formulieren multidimensionaler Qualit¨ atsziele . . . . . . . 85 5.10. Bestimmen von QS-Maßnahmen f¨ ur ein Ziel . . . . . . . . . . . . . . . . 87 5.11. Methodenbereich und Projektorganisationen gem¨ aß [Noa10] . . . . . . . 90 5.12. KVP und Qualit¨ atsplannutzung . . . . . . . . . . . . . . . . . . . . . . . 92 5.13. Kontinuierlicher Verbesserungsprozess . . . . . . . . . . . . . . . . . . . . 93

viii

6.1. Evaluationsgegenstand (blau hervorgehoben) . . . . . . . . . . . . . . . . 97 6.2. Traditionelles Entwicklungsprojekt . . . . . . . . . . . . . . . . . . . . . 98 6.3. Traditionelles Testprojekt . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.4. Agiles Entwicklungsprojekt . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.5. Excel Template f¨ ur Gruppe E: einfache Ziele . . . . . . . . . . . . . . . . 105 6.6. Excel Template f¨ ur Gruppe M: multidimensionale Ziele . . . . . . . . . . 105 6.7. Gefundenes Ziel je Gruppe . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.8. Gefundene Ziele je Gruppenteilnehmer . . . . . . . . . . . . . . . . . . . 109 6.9. Verh¨ altnis der gefundenen Referenzziele an allen Zielen . . . . . . . . . . 110 6.10. Ber¨ ucksichtigte Ergebnistypen je Teilnehmer . . . . . . . . . . . . . . . . 111 6.11. Nicht evaluierte QP Schritte . . . . . . . . . . . . . . . . . . . . . . . . . 114

B.1. Qualit¨ atsziele f¨ ur das Scope Statement aus Anhang A . . . . . . . . . . . 133

C.1. QS-Maßnahme eines QSM Katalogs (Vorderseite) . . . . . . . . . . . . . 135 C.2. QS-Maßnahme eines QSM Katalogs (R¨ uckseite) . . . . . . . . . . . . . . 136

D.1. ocomse: Verwaltungsbereich f¨ ur Zieldimensionen und QSM Katalog . . . 138 D.2. ocomse: Qualit¨ atsziele f¨ ur das B¨ ackereiprojekt . . . . . . . . . . . . . . . 139 D.3. ocomse: QS-Maßnahmen f¨ ur das B¨ ackereiprojekt . . . . . . . . . . . . . . 140 D.4. ocomse: Messen von Softwarequalit¨ at . . . . . . . . . . . . . . . . . . . . 141

Kapitel 1

Einleitung

Das Thema der Softwarequalit¨ at ist facettenreich. Dies wird zum Einen an der Studie [WLW ⁺ 10] deutlich, die im Rahmen des Quamoco Projekts [Qua10] durchgef¨ uhrt wurde. Eines der wichtigsten Ergebnisse dieser Studie ist, dass viele Unternehmen eine eigene Sicht auf die Softwarequalit¨ at besitzen und vornehmlich individuelle Qualit¨ atsmodelle einsetzen, um die Qualit¨ at ihrer Software zu beschreiben. Zum Anderen wird Software neben diesen individuellen Qualit¨ atsmodellen in unterschiedlichen Entwicklungsprozessmodellen wie dem konventionellen Wasserfallmodell oder modernen agilen Modellen produziert. Die Prozesse sind wiederum an unternehmensspezifische Rollenmodelle gekn¨ upft. Die Komplexit¨ at des Themas Softwarequalit¨ at wird weiterhin gesteigert, indem Software nicht lediglich aus Quelltext, sondern aus einer Vielzahl unterschiedlicher Ergebnistypen besteht.

Die Vielzahl der Modellarten und die Schwierigkeit der Beherrschung der Abh¨ angigkeiten zwischen ihnen wird ersichtlich, wenn sich folgende Frage stellt: Welche Qualit¨ atsmerkmale m¨ ussen in einem bestimmten Ergebnistyp wann f¨ ur wen ber¨ ucksichtigt werden und welche wirksamen Qualit¨ atssicherungsmaßnahmen existieren diesbez¨ uglich? - Wozu? Wo? Wann? Wer? Wie?

Diese Arbeit stellt eine Methode zum Umgang mit den Modellen vor: Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen.

Das Ziel dieser Arbeit ist demnach das Herbeif¨ uhren einer Methode f¨ ur Softwarequalit¨ at, welche in der Lage ist, die 5 Fragen zu beantworten. Herbeif¨ uhren heißt hierbei, die Vor-und Nachteile bestehender Ans¨ atze zu ber¨ ucksichtigen.

1

1. Einleitung

Die vorliegende Arbeit beginnt mit einer Einf¨ uhrung in das Thema. In Kapitel 2: Ziele und QS-Maßnahmen werden die Begriffe definiert und anhand zweier Beispielserien er¨ ortert. Kapitel 3: Software Engineering Modelle stellt einen beispielhaften ¨ Uberblick

zu Modellen der unterschiedlichen Modellarten bereit. Dies soll zum Einen die Komplexit¨ at von Softwareentwicklungsprojekten aufzeigen. Zum Anderen werden diese Modelle ben¨ otigt, um die Methode f¨ ur Softwarequalit¨ at in Kapitel 6 zu evaluieren.

In Kapitel 4: Stand der Forschung wird sowohl auf aktuelle, als auch auf altbekannte Publikationen zur Modellierung von Softwarequalit¨ at eingegangen. Unter dem Gesichtspunkt der Fragen ” Wozu? Wo? Wann? Wer? Wie?“ werden hier neben dem bekannten GQM Ansatz auch aktivit¨ atenbasierte, produktbasierte und spezialisierte Qualit¨ atsmodelle bez¨ uglich ihrer Eignung untersucht. F¨ ur den geeignetsten Ansatz werden schließlich Strategien zur Implementierung in einem Unternehmen vorgestellt.

Der Hauptteil der Arbeit beginnt zun¨ achst, indem die Vor- und Nachteile des geeignetsten Ansatzes in das Kapitel 5: Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen einfließen. Im Anschluss daran werden schematische Modelle f¨ ur die Qualit¨ atsziele und QS-Maßnahmen gezeigt. F¨ ur eine Werkzeugunterst¨ utzung werden diese schematischen Modelle zu konzeptionellen Datenmodellen verfeinert. Neben der Methode f¨ ur den Umgang mit den Zielen und QS-Maßnahmen werden auch die Schritte des kontinuierlichen Verbesserungsprozesses in einer Prozessnotation modelliert. Das Funktionieren der vorgestellten Methode wird in Teilen in Kapitel 6: Evaluation mit Hilfe von Szenarien und Studierenden gezeigt. F¨ ur die Evaluation mit einer Studierendengruppe dient das Scope Statement eines fiktiven B¨ ackereiprojekts aus Anhang A. In Anhang B werden f¨ ur das B¨ ackereiprojekt multidimensionale Qualit¨ atsziele in einem Excel Template gezeigt. Anhang C zeigt eine konstruktive QS-Maßnahme einer fr¨ uhen Version eines QSM Katalogs.

In Kapitel 7: Ausblick werden schließlich die nachfolgenden Schritte aufgezeigt. Darunter z¨ ahlt auch das Entwickeln eines Systems auf der Grundlage zweier Prototypen. Anhang D zeigt Screenshots der Prototypen.

Da das Thema der Softwarequalit¨ at facettenreich ist, sind alle Beteiligten von Softwareentwicklungsprojekten an dem Schaffen derselben beteiligt. Aus diesem Grund richtet sich diese Arbeit nicht ausschließlich an Qualit¨ atsmanager, sondern auch an Nutzer, Tester, Entwickler, Architekten, Projektleiter und Manager.

2

Kapitel 2

Ziele und QS-Maßnahmen

2.1. Definitionen

An dieser Stelle werden die Definitionen eingef¨ uhrt, die f¨ ur das Verst¨ andnis der weiteren Abschnitte n¨ otig sind.

F¨ ur das Anliegen dieser Arbeit, multidimensionale Qualit¨ atsziele zu formulieren, wird die Zieldefinition von Basili, Caldiera und Rombach [BCR94, S.3f] herangezogen. Abbildung 2.1 stellt den modifizierten Zielbegriff grafisch dar.

Ein Qualit¨ atsziel ist eine Abbildung in einen Zielraum, der durch die Dimensionen Qualit¨ at, Ergebnistyp, Prozess und Rolle aufgespannt wird. Diese Abbildung beschreibt das Ziel selbst und verkn¨ upft es mit QS-Maßnahmen, die f¨ ur sein Erreichen relevant sind. Mehrere Qualit¨ atsziele bilden einen Qualit¨ atsplan.

QS-Maßnahmen untergliedern sich in analytische und konstruktive Maßnahmen.

3

2. Ziele und QS-Maßnahmen

Eine analytische QS-Maßnahme (aQSM) ist eine T¨ atigkeit zum Bewerten der Qualit¨ at. Sie dient zur Erkennung und Lokalisierung von M¨ angeln und Fehlern im weitesten Sinne [Wal01, S.31]. Bez¨ uglich eines Qualit¨ atsziels resultiert aus einer aQSM eine Aussage zu potentiellen Chancen oder Risiken, welche die Zielerreichung positiv bzw. negativ beeinflussen. In der Softwareentwicklung wird zwischen Tests, Kundenfeedback, Messung, Inspektion, Review sowie Quelltextanalyse [WLW ⁺ 09, S.467] unterschieden.

Eine konstruktive QS-Maßnahme (kQSM) beschreibt eine Aktivit¨ at, die durchgef¨ uhrt wird, um Qualit¨ at pr¨ aventiv zu sichern. Sie soll das Entstehen von Fehlern und M¨ angeln von vornherein durch geeignete Prinzipien, Methoden und Werkzeuge verhindern. Sie schließt auch alle Maßnahmen zur Fehlerbehebung ein [Wal01, S.31].

Im Folgenden werden die Begriffe Maßnahme und QS-Maßnahme synonym verwendet.

2.2. Beispielserie: Benzinverbrauch minimieren

Hier werden die zuvor definierten Begriffe anhand einer Beispielserie er¨ ortert. Pro Ziel wird lediglich eine analytische sowie eine konstruktive QS-Maßnahme benannt.

Ziel

aQSM

kQSM

4

Ziel

aQSM

kQSM

Ziel

2. Ziele und QS-Maßnahmen

Ziel

aQSM

kQSM

Ziel

aQSM

kQSM

6

Die Beispiele deuten an, dass das Erreichen von Qualit¨ atszielen kein Zufall ist. F¨ ur jedes Ziel existieren konstruktive Maßnahmen, die zu einer guten Qualit¨ at f¨ uhren sollen. Damit bestimmt werden kann, ob diese konstruktiven Maßnahmen tats¨ achlich zielf¨ uhrend sind, muss ihre Wirksamkeit durch analytische Maßnahmen nachgewiesen werden.

Die Absichten Benzinverbrauch minimieren und Rundenzeit minimieren zeigen auf, dass Zielkonflikte entstehen k¨ onnen. Das heißt, dass das Erreichen des einen Ziels das Erreichen eines anderen Ziels ausschließen oder zumindest negativ beeinflussen kann. Dieser Umstand wird anhand der konstruktiven QS-Maßnahmen f¨ ur das Erreichen der Beispielziele aus der Formel 1 deutlich. Wenn der Fahrer auf den Benzinverbrauch achten soll, muss er die Kurve m¨ oglichst bremsfrei mit der Kurvengeschwindigkeit erreichen und mit einer langsamen Beschleunigung wieder verlassen. Im Gegensatz dazu muss er f¨ ur eine geringe Rundenzeit scharf bremsen und die Kurve stark beschleunigend wieder verlassen. Beide Maßnahmen k¨ onnen nicht gleichzeitig durchgef¨ uhrt werden.

Desweiteren wird ersichtlich, dass der Ergebnistyp die Priorisierung des Qualit¨ atsziels beeinflusst. Die Minimierung des Benzinverbrauchs stellt im Straßenverkehr f¨ ur den Fahrer eines Kleinwagens ein sehr wichtiges Ziel dar. In der Formel 1 kann dieses Ziel wegen eines Konflikts mit dem kritischen Ziel Rundenzeit minimieren jedoch aus der Sicht des Fahrers eines Rennwagens nicht die Hauptrolle spielen.

Die Fahrzeugtechnik stellt in den Beispielzielen Hilfsmittel zur Verf¨ ugung, die das Erreichen eines Ziels f¨ ordern. Der Fahrer pr¨ uft, ob er durch sein Fahrverhalten f¨ ur oder gegen das Erreichen wirkt. Das zeigt, dass QS-Maßnahmen durch Rollen durchgef¨ uhrt werden. Ziele gelten immer f¨ ur Rollen.

QS-Maßnahmen k¨ onnen f¨ ur mehrere Ziele gelten. Die analytische Maßnahme Benzinverbrauch beobachten fand Anwendung in allen Zielen, in denen die Absicht Benzinverbrauch minimieren verfolgt werden sollte. Zwar gibt es unterschiedliche Vorstellungen zum minimalen Verbrauch im Staßenverkehr und der Formel 1 - die Maßnahme an sich ist aber dieselbe. Auch die konstruktive Maßnahme vorausschauend fahren, d.h. das Fahrzeug ausrollen lassen, statt zu bremsen und langsam wieder beschleunigen, fand in allen Zielen mit der Absicht Benzinverbrauch minimieren Anwendung.

Analytische Maßnahmen werden je nach Ergebnistyp mit unterschiedlichen Erwartungen durchgef¨ uhrt. F¨ ur den Kleinwagen liegt der Schwellwert f¨ ur einen minimalen Benzinverbrauch bei 3 Litern pro 100 Kilometern. In der Formel 1 ist von einem deutlich h¨ oheren Schwellwert auszugehen. Dieser Umstand f¨ uhrt zu der Erkenntnis, dass der erwartete Wert f¨ ur die Beschreibung einer analytischen Maßnahme vorerst keine Rolle spielt.

7

2. Ziele und QS-Maßnahmen

2.3. Beispielserie: Softwarequalit¨ atsziele

Die unterschiedlichen Modellarten der Softwarewelt bilden die Dimensionen von Qualit¨ atszielen wie in Abbildung 2.7 dargestellt. Qualit¨ atsmerkmale entspringen aus Qualit¨ atsmodellen im gleichen Sinne, wie Ergebnistypen und Prozesse durch Modelle beschrieben werden. Auch die Rollen entstammen aus hierarchischen Modellen.

Zieldimension Qualit¨ at. Wie f¨ ur das Beispiel der Autofahrt gilt auch f¨ ur ein Softwarequalit¨ atsziel, dass es eine bestimmte Absicht verfolgt. Im Bereich der Softwareentwicklung stellen Qualit¨ atsmodelle wie die ISO/IEC 9126 Merkmale bereit, welche die Produktqualit¨ at beschreiben. Die aus den Merkmalen resultierenden Absichten liegen beispielsweise in dem Bereitstellen der relevanten Funktionalit¨ at, dem Erreichen einer hohen Zuverl¨ assigkeit oder dem Sicherstellen einer einfachen Wartbarkeit.

Zieldimension Ergebnistyp. Ein Softwareprodukt besteht aus einer Vielzahl von Artefakten und adressiert eine Produktdom¨ ane. In der Dom¨ ane der betrieblichen Informationssysteme wird zwischen SAP- und Individualsoftware unterschieden. Diese werden zun¨ achst durch Anforderungsdokumente beschrieben und sp¨ ater in ein Produktivsystem uberf¨ uhrt. Ein Testsystem pr¨ uft schließlich, ob die Anforderungen im Produktivsystem ¨

richtig umgesetzt wurden. Die Unterscheidung zwischen SAP- und Individualsoftware ist n¨ otig, da davon auszugehen ist, dass nicht die gleichen Maßnahmen gelten m¨ ussen. Das Sicherstellen einer einfachen ¨ Anderbarkeit spielt beispielsweise in SAP-Projekten

eine andere Rolle, als in Projekten mit einer individuellen Softwarearchitektur.

Zieldimension Prozess. Ein Softwareprodukt unterliegt einem Lebenszyklus, welcher die Prozesse zum Entwickeln und Betreiben eines Softwareprodukts beschreibt. Der Entwicklungsprozess teilt sich in die Phasen Planen, Entwerfen, Umsetzen und Testen auf. Zwischen den Phasen liegen ¨ Ubergabepunkte, in denen die erarbeiteten Ergebnistypen gepr¨ uft werden.

8

Zieldimension Rolle. Im Lebenszyklus einer Software arbeiten viele Rollen mit unterschiedlichen Aufgaben an bzw. mit ihr. Jede Rolle betrachtet Ziele dabei aus ihrer eigenen Perspektive. So ist der Kunde an der Erreichung anderer Zielen interessiert, als der Entwickler oder der Tester.

In der Benzinverbrauchsbeispielserie wurden zuerst Qualit¨ atsmerkmal, Ergebnistyp, Prozess und Rolle bestimmt. Die QS-Maßnahmen wurden anschließend in Hinblick auf das Ziel festgelegt. Diese Herangehensweise wird als top-down Vorgehen bezeichnet. Im Folgenden werden die Maßnahmen f¨ ur die Softwarequalit¨ atssicherung beispielhaft bottomup ermittelt. Dazu wird zuerst eine konstruktive sowie eine passende analytische QS-Maßnahme zur Anzeige m¨ oglicher Probleme benannt und im Anschluss ermittelt, welches Ziel die beiden QS-Maßnahmen adressieren.

kQSM

aQSM

2. Ziele und QS-Maßnahmen

kQSM

aQSM

Ziel

kQSM

aQSM

Ziel

10

Kapitel 3

Software Engineering Modelle

Modelle werden in der Informatik genutzt, um die Realit¨ at zu beschreiben und Ordnung in die komplexe Welt des Software Engineering zu bringen. Bezogen auf die Definition des Zielbegriffs aus Abbildung 2.1 und den ¨ Uberblick der Softwareziele aus Abbildung 2.7 m¨ ussen vier Modellarten ber¨ ucksichtigt werden.

Wozu? - Qualit¨ atsmodelle! Ein Qualit¨ atsmodell enth¨ alt Merkmalsgruppen, die ¨ uber

Merkmale zu Metriken verfeinert sind und die Qualit¨ at eines Softwareprodukts beschreiben. F¨ ur den Zielbegriff stellt Qualit¨ at die zu verfolgende Absicht dar, indem ein bestimmtes Merkmal erreicht werden soll.

Wo? - Ergebnistypmodelle! Ein Ergebnistyp beschreibt ein Artefakt des Entwicklungsprozesses. Durch das Bereitstellen projektspezifischer Ergebnistypen wird das Zielumfeld eingegrenzt.

Wann? - Prozessmodelle! Ein Prozessmodell beschreibt den Produktlebenszyklus. Die Zielerreichung muss zu einem bestimmten Zeitpunkt in einem bestimmten Ergebnistyp sichergestellt werden. Dieser Zeitpunkt ist h¨ aufig der ¨ Ubergang zur n¨ achsten Phase.

Wer? - Rollenmodelle! Rollenmodelle beschreiben Hierarchien aus Aufgaben, Kompotenzen und Verantwortlichkeiten. Bezogen auf den Zielbegriff beantworten Rollenmodelle die Frage, f¨ ur wen ein Ziel erreicht werden soll.

Dieses Kapitel stellt 1-seitige und damit nicht tiefgehende Beschreibungen von Modellen bereit, die im Abschnitt 6.1 ben¨ otigt werden, um die Wiederverwendbarkeit von Modellen im multidimensionalen Zielraum zu zeigen.

11

3. Software Engineering Modelle

3.1. Qualit¨ atsmodelle

Ein Qualit¨ atsmodell stellt eine Hierarchie von abstrakten Merkmalsgruppen, konkreten Merkmalen und messbaren Attributen zur Verf¨ ugung, die durch schrittweise Verfeinerung an das zu beschreibende Umfeld angepasst werden [FC02, S.2].

In diesem Zusammenhang beschreibt der durch Jim McCall formulierte FCM (Fac-tor/Criteria/Metrics) Ansatz [MRW77] ein Metamodell, mit dessen Hilfe Qualit¨ atsmodelle gem¨ aß der oben genannten Definition erarbeitet werden k¨ onnen. Faktoren beschreiben die abstrakten Merkmalsgruppen, welche zu Kritieren verfeinert werden. Diese Kriterien beschreiben die konkreten Merkmale. Die Kriterien werden schließlich im n¨ achsten Verfeinerungsschritt mit Hilfe von Metriken operationalisiert.

FCM bildet die Grundlage vieler Softwarequalit¨ atsmodelle, wie dem ISO/IEC 9126 Standard f¨ ur Softwareproduktqualit¨ at oder dem Capgemini sd&m Software-Blutbild als Beispiel f¨ ur ein unternehmensspezifisches Qualit¨ atsmodell.

Ein weiteres Metamodell ist Teil des durch Basili, Rombach und Caldiera ver¨ offentlichten GQM (Goal/Question/Metric) Ansatzes [BCR94]. GQM zielt auf die top-down Implementierung der Qualit¨ atsmodellierung in die Unternehmensabl¨ aufe ab. Im ersten GQM-Schritt werden Qualit¨ atsziele festgelegt. Da Ziele noch sehr abstrakt sind, werden sie durch Fragen konkretisiert. Die Fragen werden analog zu den Kriterien aus FCM durch Metriken operationalisiert.

12

3.1.1. Beispiel: ISO/IEC 9126

In der ISO/IEC 9126 wird zwischen den 6 Merkmalsgruppen Funktionalit¨ at, Zuverl¨ assigkeit, Benutzbarkeit, Effizienz, ¨ Anderbarkeit sowie ¨ Ubertragbarkeit unterschieden. Im

Anhang der Norm befindet sich ein Vorschlag f¨ ur die Merkmalsverfeinerung. Messbare Attribute werden nicht beschrieben. Abbildung 3.2 zeigt eine grafische Repr¨ asentation des Aufbaus der ISO/IEC 9126.

In Hinblick auf FCM beschreiben die Merkmalsgruppen Faktoren. Die vorgeschlagenen Merkmale jeder Merkmalsgruppe dienen als Kriterien. Die Verfeinerung gem¨ aß FCM wird nicht bis zur Metrikebene durchgef¨ uhrt, so dass die ISO/IEC 9126 ein FC-Modell darstellt. Durch den Fokus auf Faktoren und Kriterien ist die Norm sehr abstrakt. Der Nachteil daran ist das oft kritisierte Fehlen der Definition konkreter Metriken. Das FC-Modell hat jedoch den Vorteil, dass es dom¨ anen¨ ubergreifend Zielgruppen anspricht, es somit weit verbreitet und sehr langlebig ist. Die aktuelle Quamoco Studie zeigt, dass Unternehmen vorwiegend eigene Qualit¨ atsmodelle einsetzen [WLW ⁺ 10, S.6]. H¨ aufig dient die ISO/IEC 9126 aber als Vorlage f¨ ur diese unternehmensspezifischen Modelle.

13

3. Software Engineering Modelle

3.1.2. Beispiel: ISO/IEC 9126 im Test

Die ISO/IEC 9126 beschreibt die Produktqualit¨ at von Softwaresystemen. Dies f¨ uhrt dazu, dass sie nicht direkt im Test anwendbar ist. Da die Norm allerdings h¨ aufig als Ausgangsbasis f¨ ur das Formulieren angepasster Qualit¨ atsmodelle verwendet wird, wurde sie auch in [ZVS ⁺ 07] f¨ ur die Definition eines Qualit¨ atsmodells f¨ ur den Test herangezogen. Diese Anpassung ist in Abbildung 3.3 dargestellt.

Abb. 3.3.: F¨ ur den Test angepasste ISO/IEC 9126 [ZVS ⁺ 07, S.234]

Die vorhandenden Merkmalsgruppen des Ursprungsmodells wurden im Kontext des Testens reinterpretiert. Die Gruppe Funktionalit¨ at wurde zu Testeffektivit¨ at umbenannt. Da das Ursprungsmodell nicht die Wiederverwendbarkeit auf Gruppenebene ber¨ ucksichtigt, haben die Autoren des Testqualit¨ atsmodells hierf¨ ur eine zus¨ atzliche Merkmalsgruppe eingef¨ uhrt.

Obwohl in [ZVS ⁺ 07, S.237ff] einige Metriken f¨ ur die Merkmale der Merkmalsgruppen Testeffektivit¨ at, ¨ Anderbarkeit und Wiederverwendbarkeit definiert werden, beschreibt das dargestellte Qualit¨ atsmodell ein FC-Modell, da gem¨ aß FCM lediglich Faktoren und Kriterien vollst¨ andig definiert wurden. Wie bei der ISO/IEC 9126 wird hier kein vollst¨ andiger Satz an Standardmetriken bereitgestellt, so dass diese f¨ ur eine Anwendung des Modells erst definiert werden m¨ ussen.

14

3.1.3. Beispiel: Capgemini sd&m Softwareblutbild

Das in Abbildung 3.4 dargestellte Softwareblutbild ist die erste Stufe des dreistufigen Software Controllings bei Capgemini sd&m [Hof08]. Um das Ziel eines Modells mit standardisierten Eigenschaften und Kennzahlen f¨ ur die Qualit¨ atssteuerung zu erreichen, werden sowohl das Produkt, als auch der Entwicklungsprozess beleuchtet. Im gewissen Sinne werden damit zwei Qualit¨ atsmodelle zu einem Modell vereint.

Gem¨ aß FCM und verglichen mit der ISO/IEC 9126 werden durch das Softwareblutbild Faktoren und Kriterien nicht unterschieden, sondern als Eigenschaften zusammengefasst. Die 9126 Merkmalsgruppen Zuverl¨ assigkeit und Performance werden durch das unternehmensspezifische Modell wiederverwendet. Der Zwischenschritt der Konkretisierung findet nicht statt, weswegen die Eigenschaften als eine FC-Mischung auftreten. Die Operationalisierung dieser FC-Mischung findet durch Metriken statt. Damit stellt das Software-Blutbild ein (FC)M-Modell dar. Eine Besonderheit des Blutbildmodells ist die angebotene Schnittstelle zur ISO/IEC 9126. Damit l¨ asst es sich mit Qualit¨ atsmodellen anderer Beteiligten, wie z.B. dem Kunden, verbinden.

15

3. Software Engineering Modelle

3.2. Ergebnistypmodelle

Ein Softwareprodukt entsteht nicht von heute auf morgen. Vielmehr durchl¨ auft es einen Lebenszyklus, in dem es aus einem Entwicklungsprozess heraus entsteht und ¨ uber die

Betriebsphase reift. Wegen dieser unterschiedlichen Stationen eines Softwareprodukts ist es viel mehr, als lediglich Quelltext. Abbildung 3.5 zeigt die Kategorien und einige Ergebnistypen im Softwarelebenszyklus.

Anforderungen. Am Anfang besteht das Softwareprodukt aus Anforderungen. Diese enthalten in einem Pflichtenheft die konkreten Anwendungsf¨ alle, welche als Modell der Funktionalit¨ at des zu entwickelnden Produkts in fr¨ uhen Phasen auftreten. Die nichtfunktionalen Anforderungen werden in einem Qualit¨ atsplan dokumentiert, der entweder als eigenst¨ andiges Dokument oder als Bestandteil des Pflichtenhefts erarbeitet wird.

Entwicklersystem. Im Entwicklersystem werden die Anforderungen des Kunden in ein lauff¨ ahiges System ¨

tems erstellt, das in der Lage ist, sowohl den funktionalen, als auch den nichtfunktionalen Anspr¨ uchen des Kunden gerecht zu werden. Die Implementierung f¨ ullt den architekturellen Rahmen schließlich mit der eigentlichen Funktionalit¨ at. Als wesentlicher Teil des Produktivsystems sollte auch f¨ ur die Dokumentation gelten, dass sie einer einheitlichen Struktur, also einem Modell unterliegt.

Testsystem. Der Test dient der ¨

tivsystem erf¨ ullt werden. Wegen des hohen Anteils des Testaufwands am Gesamtent-wicklungsaufwand darf das Testsystem nicht als Nebenprodukt betrachtet werden.

Produktivsystem. Das Produktivsystem l¨ auft in der realen Umgebung mit echten Daten. Nach der initialen Entwicklung und dem ersten Start definiert die Wartungsstragie die n¨ otigen Schritte f¨ ur das Einbinden von neuen Anforderungen.

16

3.2.1. Beispiel: Anwendungsfallmodell

Anwendungsf¨ alle werden in der Spezifikationsphase im Rahmen der Erarbeitung von Produktfunktionen f¨ ur das Pflichtenheft erstellt [Bal96, S.104]. Sie beschreiben die durch ein Softwaresystem bereitzustellende Funktionalit¨ at. Leider hat sich bis heute noch kein einheitliches und konkretes Modell f¨ ur Anwendungsf¨ alle (Use Cases) durchgesetzt [Fro09, S.24] [FS05, S.3]. In der Praxis werden sie statt dessen wie in Abbildung 3.6 tabellarisch und textuell dokumentiert.

Akteur. Da Anwendungsf¨ alle selten nicht von ihrer Umgebung abh¨ angen, werden menschliche und technische Nutzer, die mit ihnen interagieren dokumentiert.

Szenarien. Szenarien sind der Hauptbestandteil eines Anwendungsfalls. Sie beschreiben die funktionalen Schritte, die notwendig sind, um das Ziel des Anwendungsfalls zu erreichen. Erfolgsszenarien beschreiben den geraden Weg zum Ziel, in dem keine Spezial- und Fehlerf¨ alle auftreten. Die Sonderf¨ alle werden in den Alternativszenarien behandelt.

Nichtfunktionale Anforderungen. NFAs betreffen Aussagen bez¨ uglich nichtfunktionaler Qualit¨ atsmerkmale wie Effizienz oder Wartbarkeit aus der ISO/IEC 9126. Sie werden im Anwendungsfall dokumentiert, wenn sie ihn direkt betreffen. Allgemeine NFAs k¨ onnen beispielsweise im Qualit¨ atsplan aufgef¨ uhrt werden.

17

3. Software Engineering Modelle

3.2.2. Beispiel: Architekturmodell

F¨ ur den Begriff Softwarearchitektur existieren viele unterschiedliche, teilweise widerspr¨ uchliche Definitionen [VAC ⁺ 09, S.8f]. Eine textuelle Definition aus dem Buch Software Architecture in Practice beschreibt Architektur als eine Menge von Systemstrukturen, welche aus Softwareelementen und den Beziehungen zwischen ihnen bestehen [BCK03, S.21]. Abbildung 3.7 stammt aus dem Buch Software-Architektur: Grundlagen - Konzepte - Praxis [VAC ⁺ 09, S.47]. Ihre linke Seite zeigt eine grafische Darstellung der oben aufgef¨ uhrten, textuellen Definition.

Im Hinblick auf die Softwarebausteine, bzw. Softwarekomponenten, gibt es unterschiedliche M¨ oglichkeiten der Realisierung des Metamodells zu einem Modell. Der architektonische Schnitt einer Anwendung enth¨ alt zum Beispiel Datenbank-, GUI-, Kommunikations-und Fachlogikkomponenten, die in Schichten oder einer Matrix angeordnet sind.

Johannes Siedersleben und Ernst Denert beschrieben eine Ebene zwischen IT-System und Komponenten. Im Rahmen der Quasar Qualit¨ atsarchitektur f¨ uhrten sie Softwareblutgruppen [SD00, S.248f] ein. Die Blutgruppen sortieren die Softwarearten bez¨ uglich ihrer Wiederverwendbarkeit in 0-, A-, T-, AT- sowie R-Software. 0-Software ist unabh¨ angig vom Kontext und kann immer wiederverwendet werden. A-Software beschreibt die Fachlogik, T-Software die technische L¨ osung. Software, die fachliche und technische Aspekte implementiert, wird als AT-Software bezeichnet. AT-Software schr¨ ankt die Wiederverwendbarkeit stark ein. R-Software ist die milde Form von AT-Software. Sie befasst sich mit der Transformation der fachlichen Objekte in ihre externe Repr¨ asentation.

18

3.2.3. Beispiel: Testfallmodell

In ihrem Buch Der Systemtest versuchen Harry Sneed, Manfred Baumgartner und Richard Seidl aus den unterschiedlichen Testfallbeschreibungen ein Modell zu formulieren [SBS09, S.91]. Denn wie f¨ ur die Anwendungsf¨ alle gilt auch f¨ ur Testf¨ alle, dass sich noch kein einheitliches Modell durchgesetzt hat [SBS09, S.84] und Testf¨ alle in der Praxis h¨ aufig in Tabellenform dokumentiert werden. Der spezifische Teil des Modells aus dem Buch ist in Abbildung 3.8 dargestellt.

Spezifischer Testfall. Ein Testfall sollte aus den Attributen der obigen Abbildung bestehen. Der Typ zeigt an, ob der Testfall manuell oder automatisiert auszuf¨ uhren ist. Die Quelle besagt, wovon der Testfall abgeleitet wurde. Der Ausl¨ oser beschreibt das Ereignis, das den Testfall ausl¨ ost. Außerdem wird die Verbindung zu den gepr¨ uften Anforderungen und Anwendungsf¨ allen dokumentiert. Da jeder Test ¨ uber einen bestimmten Teil des

Pr¨ uflings ausgef¨ uhrt wird, wird im Testfall auch das Testobjekt explizit dokumentiert.

Testszenarien. Ein Testszenario entsteht durch das Aneinanderreihen von Testf¨ allen.

Testdaten. Eingabedaten werden dem Testfall zur Ausf¨ uhrung als Argumente ¨ ubergeben.

Ausgabedaten sind die erwarteten Ergebnisse, die nach der Ausf¨ uhrung vorliegen sollten. Anhand des Vergleichs der Soll- und Ist-Ausgabedaten wird ermittelt, ob der Testfall positiv oder negativ durchlaufen wurde.

In dem Modell aus Der Systemtest fehlen die konkreten Testschritte, so dass es sich hier lediglich um Testaspekte handelt, welche noch auszuformulieren sind.

19

3. Software Engineering Modelle

3.3. Prozessmodelle

Mit Hilfe von Prozessen werden Unternehmensabl¨ aufe beschrieben. Abbildung 3.9 zeigt den Aufbau von Prozessmodellen. Ein Prozess wird in Teilprozesse mit Ein- und Ausgaben aufgegliedert. Die Ausgabe eines Teilprozesses ist die Eingabe nachfolgender Prozesse. Das dadurch zustande kommende interne Kundenverh¨ altnis zeigt auf, dass nicht nur am Ende der externe Kunde auf qualitativ hochwertige Ergebnisse wartet. Die Prozesse in dieser hohen Abstraktionsebene eignen sich zwar zur Beschreibung der Prozesslandschaft eines Unternehmens, sie bieten jedoch noch keine konkreten, durchzuf¨ uhrenden Schritte. F¨ ur die weitere Verfeinerung bietet die BPMN (Business Process Modeling Notation) ein Werkzeug, mit dem die abstrakten Teilprozesse zu konkreten Schritten mit Entscheidungszweigen sowie Ein- und Ausgaben verfeinert werden k¨ onnen.

3.3.1. Beispiel: Wasserfallmodell

Das von Royce 1987 ver¨ offentlichte Wasserfallmodell [Roy87] ist in Abbildung 3.10 dargestellt. Das Alter des Modells und dessen breite Anwendung l¨ asst erahnen, warum es als das konventionelle Modell bekannt ist.

Anforderungsanalyse. Die Grundlage eines Softwareprojekts sind die Anforderungen des Kunden. Falls ein Altsystem ersetzt werden soll, liefert dessen Analyse wertvolle Erkenntnisse f¨ ur das neue Produkt. Da die funktionalen und nichtfunktionalen Anforderungen f¨ ur alle Nachfolgephasen relevant sind, liegt auf ihnen der Fokus des QG.

Design. W¨ ahrend des Systementwurfs wird eine Softwarearchitektur erstellt. Die Architektur muss sowohl das fachlichen Konzept widerspiegeln, als auch das Erf¨ ullen der konkreten nichtfunktionalen Eigenschaften erm¨ oglichen. Anhand eines prototypischen technischen Durchstichs kann am QG die F¨ ahigkeit der Architektur zum Erf¨ ullen der Anforderungen gepr¨ uft werden.

Implementierung. In der Implementierungsphase wird das Fachkonzept umgesetzt. Eine Besonderheit dieser Phase ist, dass nicht bis zuletzt mit der Abnahme des Codes gewartet werden kann. Damit beim Erreichen des Quality Gates keine b¨ osen ¨ warten, muss die Programmierung kontinuierlich ¨

Test. Der Test ist eine analytische Maßnahme, mit der bereits entstandene fachliche Fehler gefunden und Verfehlungen der nichtfunktionalen Anforderungen aufgedeckt werden sollen. Durchzuf¨ uhrende konstruktive QS-Maßnahmen k¨ onnen hier dazu f¨ uhren, dass das Produkt gut testbar ist und weniger Fehler enth¨ alt.

Betrieb. Wenn das Softwareprodukt schließlich bez¨ uglich der Anforderungen real beansprucht wird, wird Softwarequalit¨ at pl¨ otzlich f¨ ur jeden sichtbar.

Zum Ende dieses kurzen ¨

jektmanagementphase in dieser fr¨ uhen Version des Modells noch fehlt.

21

3. Software Engineering Modelle

3.3.2. Beispiel: SCRUM - Agiles Entwicklungsmodell

Ken Schwaber schrieb 1995 [Sch95, S.2], dass konventionell durchgef¨ uhrte Projekte h¨ aufig so behandelt werden, als w¨ are ihr Prozess mit allen Ein- und Ausgaben definiert. Da sich die detaillierte Definition der komplexen Prozesse als schwierig erweist, betrachtet der agile SCRUM Ansatz die Implementierungsphase des Wasserfallmodells als eine kontrollierte Blackbox. Abbildung 3.11 zeigt den SCRUM Prozess.

SCRUM Start. In der Startphase werden die definierten Planungs- und Designprozesse eines konventionellen Prozesses ausgef¨ uhrt. Die Prozesse und QGs entsprechen beispielsweise den fr¨ uhen Phasen des Wasserfallmodells aus Abbildung 3.10.

Sprint Planning. Die gesamte Sprint-Phase ist ein empirischer Prozess, der aus undefinierten und ungesteuerten Teilprozessen besteht. Ein Sprint dauert in der Regel nur einige Wochen. Deswegen muss in der Planungsphase neben der Kl¨ arung der Verf¨ ugbarkeit des Teams die zu bearbeitende Aufgabe so geschnitten werden, dass das Team die auf-einanderfolgenden Sprints durchh¨ alt.

Daily SCRUM, Daily Work. An jedem Morgen wird ein 15-min¨ utiges SCRUM-Meeting durchgef¨ uhrt, in dem jeder vortr¨ agt, was er von wem braucht, um die heutige Arbeit zu erledigen. Das große SCRUM Ziel ist es, nach jedem Sprint ein auslieferbares Produkt bereitstellen zu k¨ onnen. Deshalb findet die t¨ agliche Arbeit in der Art statt, dass nach der Fertigstellung eines Arbeitspakets an diesem keine weiteren Aufgaben auftreten.

Sprint Review. Da jeder Sprint nur wenige Wochen dauert, treten kleine QGs lediglich am Ende eines Sprints im Rahmen eines Reviews auf.

Closure. Die letzte Phase findet wieder in einer definierten Prozessumgebung statt. Das bedeutet, dass ein releasef¨ ahiges Sprint-Ergebnis beispielsweise an die Testphase des Wasserfallmodells weitergereicht wird.

22

3.3.3. Beispiel: Testprozessmodell gem¨ aß ISTQB

Das Buch Basiswissen Softwaretest [SL04] von Andreas Spillner und Tilo Linz dient als Grundlage zur Ausbildung als ISTQB Ceritified Tester im Foundation Level. Darin wird neben grunds¨ atzlichen Methoden und Werkzeugen rund um den Test auch der fundamentale Testprozess [SL04, S.18ff] beschrieben. Der in Abbildung 3.12 dargestellte Testprozess verfeinert den entsprechenden Teilprozess des Wasserfallmodells aus Abbildung 3.10. Der fundamentale Testprozess entspringt der IEEE 829.

3. Software Engineering Modelle

3.4. Rollenmodelle

Ein Rollenmodell beschreibt die Hierarchie, in der ein Projekt bez¨ uglich der Projektbeteiligten organisiert wird. Im Rollenmodell werden außerdem die Kommunikationswege festgelegt. Dabei wird zwischen der vertikalen, interhierarchischen und der horizontalen, intrahierarchischen Kommunikation unterschieden. In Abbildung 3.13 ist der Aufbau des beschriebenen Modells anhand zweier Organigramme dargestellt.

In Organisationen mit einer flachen Hierarchie treten demnach k¨ urzere, vertikale aber daf¨ ur l¨ angere, horizontale Wege auf. Bei einer tiefen Hierachie kehrt sich dies um.

Die horizontale Kommunikation ¨

des Wasserfallmodells statt. Die Anforderungen des Fachbereichs m¨ ussen beispielsweise uber den internen IT-Bereich unmissverst¨ andlich an den Zulieferer gereicht werden. Das ¨ ¨ Uberf¨ uhren der Anforderungen ¨ findet beim Zulieferer dann vertikal statt.

In diesem Abschnitt wird ein ¨

ten Projektorganisation aufgezeigt. Zudem wird etwas genauer auf die Entwickler- und Testrollen eingegangen.

24

3.4.1. Beispiel: Rollen entlang des Wasserfalls

In der V-Modell-Referenz werden insgesamt 33 Rollen innerhalb der Softwareentwicklung aufgelistet [Koo09, S.4-42]. F¨ ur einen ¨ Uberblick ist dies zu viel. Aus diesem Grund

werden auf dieser Seite lediglich die oberen Hierarchien aufgezeigt. Abbildung 3.14 zeigt Kunden-, Entwicklungs- und Testrollen in einer verteilten Projektorganisation.

Kundenrollen. In großen Organisationen wird Software f¨ ur einen konkreten Fachbereich entwickelt, dessen Arbeit unterst¨ utzt werden soll. Die interne IT-Abteilung tritt dabei als Schnittstelle zwischen dem Fachbereich und den externen Entwicklern auf. Ein Beispiel f¨ ur eine Rolle ist der Anforderungsanalyst auf Auftraggeberseite [Koo09, S.4-9f].

Entwicklungsrollen. Die ausgelagerte Entwicklung findet in Unternehmen mit Spezialisierung in der Softwareentwicklung statt. Diese Unternehmen besetzen die Positionen bez¨ uglich des Projekts anhand ihres spezifischen Rollenmodells. Als Beispielrolle dient hier der Anforderungsanalyst auf Auftragnehmerseite [Koo09, S.4-11f].

Testrollen. Da der Test am Besten von unabh¨ angiger Seite durchgef¨ uhrt wird, liegt die Auslagerung des Tests an einen weiteren Dienstleister nahe. Auch ein Testunternehmen wird die Rollen besetzen - zum Beispiel gem¨ aß ISTQB.

25

3. Software Engineering Modelle

3.4.2. Beispiel: SCRUM Entwicklerrollen

Wegen der kurzen Sprintlaufzeit und der Forderung, dass nach einem Sprint auslieferbare Teilprodukte entstehen, muss das zu entwickelnde Produkt entsprechend geschnitten werden. Ein disjunkter Schnitt erm¨ oglicht es mehreren Teams autonom zu arbeiten. Abbildung 3.15 zeigt das in [Glo10, S.196f] beschriebene Rollenmodell.

SCRUM Master. SCRUM Master sind kein Mitglied der autonomen Zellen. Sie stellen die n¨ otigen Rahmenbedingungen her und sorgen f¨ ur den korrekten Ablauf des Prozesses. Hinsichtlich der externen Rollen treten sie als Schnittstelle auf.

Product Owner. Der Product Owner ¨

Zelle. Er entscheidet, in welcher Reihenfolge die Arbeitspakete des Sprints abgearbeitet werden, h¨ alt sich jedoch bei Entscheidungen um die technische Realisierung zur¨ uck.

Autonome SCRUM Zelle. Die SCRUM Zelle besteht aus Entwicklern, die ihre Aufgaben selbst organisieren. Im Idealfall besteht die Gruppe aus 5 Personen, die in der Lage sind, alle anfallenden Arbeiten selbst¨ andig durchzuf¨ uhren.

26

3.4.3. Beispiel: Testrollen gem¨ aß ISTQB

Die Aufz¨ ahlung der idealen Besetzung eines Testteams aus dem Buch Basiswissen Softwaretest [SL04, S.147f] wird als Organigramm in Abbildung 3.16 dargestellt.

Testmanager. Der Testmanager plant und steuert das Testprojekt.

Testdesigner. Der Testdesigner spezifiziert Testf¨ alle. Dies schließt neben der Formulierung der konkreten Testf¨ alle auch deren Verwaltung ein. Der Designer kommuniziert vertikal mit den Automatisierern und horizontal mit den Testern.

Testautomatisierer. Der Automatisierer wandelt die spezifizierten Testf¨ alle in Testskripte um. Er kommuniziert vertikal mit den Designern und horizontal mit den Testern und den Administratoren.

Testadministrator. Der Administrator f¨ uhrt die Testumgebung ein, die ein Tester ben¨ otigt, um seine Arbeit zu erledigen und stellt ihren reinbungslosen Betrieb sicher.

Tester. Der Tester f¨ uhrt die spezifizierten Testf¨ alle durch, erstellt Fehlerberichte und die Auswertung des Testdurchlaufes.

Es f¨ allt auf, dass in dem von Spillner und Linz vorgeschlagenen Modell noch Rollen bez¨ uglich der Fehler- und Testdatenverwaltung fehlen.

27

Kapitel 4

Stand der Forschung

Dieses Kapitel fasst wissenschaftliche Publikationen zusammen, welche Qualit¨ atsmodelle, ihre Anpassung und Anwendung vorstellen. Um sicherzustellen, dass die vorgestellten Modelle und Methoden praktisch anwendbar sind, gelten in Abschnitt 4.1 f¨ ur die Auswahl der Publikationen einige Kriterien.

Aktualit¨ at. Es sollen aktuelle Ideen und Studien betrachtet werden, d.h. die Ver¨ offentlichung sollte um das Jahr 2000 stattgefunden haben. Bis auf den GQM Ansatz ist dieses Kriterium f¨ ur alle Ans¨ atze erf¨ ullt, wobei sich Ideen von GQM in den neuen Ans¨ atzen wiederfinden.

Praktische Relevanz. Die Modelle und Methoden m¨ ussen im praktischen Umfeld angewendet worden sein - am Besten in großen Organisationen. Dieses Kriterium wird bis auf QUIM durch alle vorgestellten Ans¨ atze erf¨ ullt.

Akademische Verbreitung. Die Papers, aus welchen die vorgestellten Ans¨ atze stammen, sollen in der wissenschaftlichen Welt verbreitet sein, d.h. dass sie h¨ aufig referenziert werden.

In Abschnitt 4.2 werden die Ans¨ atze in einer ¨ Ubersicht zusammenfassend gegen¨ ubergestellt und bestimmt, inwiefern die Konzepte f¨ ur die Beantwortung der Fragen ” Wozu?

Wo? Wann? Wer? Wie?“ geeignet sind. Schließlich werden in Abschnitt 4.3 Ver¨ offentlichungen vorgestellt, welche die Anwendung des geeignetsten Ansatzes behandeln.

29

4. Stand der Forschung

4.1. Anpassen von Qualit¨ atsmodellen

In diesem Abschnitt werden gem¨ aß der obigen Kriterien aktivit¨ atenbasierte, produktbasierte, spezialisierte und zielorientierte Qualit¨ atsmodelle vorgestellt. Bez¨ uglich der An-

passung kann bei Qualit¨ atsmodellen grunds¨ atzlich zwischen den Eigenschaften ” your-own-model“ und ”

lit¨ atsmodelle entsprechen den vorgestellten spezialisierten Qualit¨ atsmodellen. Sie k¨ onnen zwar nur f¨ ur einen bestimmten Zweck in einem abgesteckten Umfeld angewendet werden, m¨ ussen daf¨ ur aber nicht oder nur wenig angepasst werden. Die vorgestellten

aktivit¨ atenbasierten, produktbasierten und zielorientierten ” verf¨ ugen neben einem Metamodell ¨ uber eine Anpassungsmethode, durch welche das Modell f¨ ur den Projektkontext definiert wird.

Jeder der folgenden Abschnitte ist gleich aufgebaut. Zun¨ achst wird das Modell kurz beschrieben und gekl¨ art, in welchem praktischen Umfeld es bereits Anwendung gefunden hat. F¨ ur jeden Ansatz wird bewertet, inwiefern die eingangs gestellten Fragen ” Wozu?

Wo? Wann? Wer? Wie?“ beantwortet werden k¨ onnen.

Welche Probleme existieren in bestehenden Ans¨ atzen? In diesem Abschnitt werden Aussagen der Autoren der jeweiligen Ver¨ offentlichung aufgez¨ ahlt, aus welcher Motivation heraus der neue Ansatz formuliert wurde.

Wie werden die Probleme gel¨ ost? Hier werden die Strategien der Autoren f¨ ur die L¨ osung der zuvor angesprochenen Probleme vorgestellt.

Wie sieht das zugrunde liegende Modell aus? Um diese Frage f¨ ur den entsprechenden Ansatz zu beantworten, wird die Struktur erl¨ autert, welche die Grundlage f¨ ur die Anpassungsmethode liefert.

Wie funktioniert die Anpassungsmethode? Hier wird beschrieben, wie aus dem abstrakten Modell ein konkretes Modell f¨ ur die Anwendung im Projekt wird. Im Fall der spezialisierten Modelle wird am Beispiel der QUIM Erstellung die einmalig durchzuf¨ uhrende Erstellungsmethode als Spezialfall einer Anpassungsmethode beschrieben.

Wozu? Wo? Wann? Wer? Wie? Abschließend wird eine Wertung des jeweiligen Ansatzes durchgef¨ uhrt, inwiefern er in der Lage ist, die in der Einleitung gestellte Fra-

ge zu beantworten. Die Einzelfragen ” sionen eines multidimensionalen Qualit¨ atsziels wieder. Das ” Maßnahmen. 30

4.1.1. Aktivit¨ atenbasiertes Qualit¨ atsmodell

Dieser Abschnitt behandelt eine Reihe von Publikationen der TU M¨ unchen, in denen das Konzept des aktivit¨ atenbasierten Qualit¨ atsmodells, seine Anpassung sowie sein Einsatz in der Praxis beschrieben wird. Ein aktivit¨ atenbasiertes Qualit¨ atsmodell spannt 2 Dimensionen auf: eine Aktivit¨ aten- und eine Produktqualit¨ atsdimension [WDW08, S.29]. Aktivit¨ aten beziehen sich auf Prozesse f¨ ur den Umgang mit dem Softwaresystem, Entwicklungsprozesse werden jedoch nicht ausgeschlossen. Durch ein 5-stufiges Verfahren werden die Modelldimensionen an das konkrete Umfeld angepasst [WDW08, S.31].

In [DWP ⁺ 07, S.4] leiteten die Autoren f¨ ur die MAN Nutzfahrzeuge AG ein Qualit¨ atsmodell bez¨ uglich der Wartung ab, indem sie den IEEE Std 1219 IEEE Standardprozess f¨ ur Software Wartung auf die Aktivit¨ atendimension und ein im FCM Verfahren erstelltes, individuelles Wartungsqualit¨ atsmodell auf die Produktqualit¨ atsdimension legten.

In einem anderen Projekt wurde ein zweidimensionales Qualit¨ atsmodell f¨ ur die Benutzbarkeit formuliert [WWD07, S.8f]. Daf¨ ur haben die Autoren auf die Produktqualit¨ atsdimension die Merkmalsgruppe der Benutzbarkeit aus der ISO/IEC 9126 abgebildet. Da die Merkmalsgruppe der ISO 9126 die Produktqualit¨ at nur sehr grob beschreibt, haben die Autoren in einem Verfeinerungsschritt die Qualit¨ atsdimension f¨ ur ein konkretes Umfeld angepasst, indem sie die einzelnen Benutzbarkeitsmerkmale durch die konkrete ISO 15005 Straßenfahrzeuge - Ergonomische Aspekte von Fahrerinformations-und Fahrerassistenzsystemen konkretisierten [WWD07, S.13]. Die Aktivit¨ atendimension beinhaltet die Wurzelaktivit¨ at Benutzung, welche stufenweise verfeinert wurde.

Welche Probleme existieren in bestehenden Ans¨ atzen? In den Publikationen [DWP ⁺ 07, S.1f], [WWD07, S.5f] und [WDW08, S.1f] wird auf die Probleme eingegangen. An erster Stelle betonen die Autoren, dass das Beschreiben von Qualit¨ atsanforderungen - und darunter besonders das Beschreiben der nichtfunktionalen Anforderungen - in der Anforderungsanalyse str¨ aflich vernachl¨ assigt wird. Dies liegt begr¨ undet in der Tatsache, dass es in Abwesenheit von Modell und Methode schwer f¨ allt, sich in der Vielfalt der m¨ oglichen Produkteigenschaften auf die relevanten Faktoren zu konzentrieren, um Qualit¨ atsanforderungen in einer messbaren Art zu beschreiben. Bestehende Qualit¨ atsmodelle wie die ISO 9126 stellen zudem zu grobe Kriterien bereit, die sich nicht direkt auf den Kontext ihres Einsatzgebietes abbilden lassen. Das zweite große Problem liegt in den nicht behandelten Abh¨ angigkeiten zwischen Anforderungen und ihrer Verfeinerung. Nach Aussage der Autoren ist es dadurch schwierig zu erkennen, welchen Einfluss Qualit¨ atsmerkmale auf die Akteure der Prozesse nehmen k¨ onnen.

31

4. Stand der Forschung

Wie werden die Probleme gel¨ ost? Aktivit¨ atenbasierte Qualit¨ atsmodelle l¨ osen diese Probleme, indem Produktqualit¨ atseigenschaften und in den Prozessen durchgef¨ uhrte Aktivit¨ aten durch das Bilden eines 2-dimensionalen Systems miteinander in Beziehung gebracht werden. Diese dimensionale Trennung erm¨ oglicht eine unabh¨ angige Anpassung von Produktqualit¨ at und Aktivit¨ aten. Das f¨ uhrt dazu, dass relevante Anforderungen leichter identifiziert werden k¨ onnen, indem klar wird, welche Produktmerkmale einen Einfluss auf welche Aktivit¨ at im zu unterst¨ utzenden Gesch¨ aftsprozess haben.

Wie sieht das zugrunde liegende Modell aus? Das Quality Metamodel (QMM) beschreibt die Struktur von aktivit¨ atenbasierten Qualit¨ atsmodellen explizit, indem es die m¨ oglichen Modellelemente und ihre Abh¨ angigkeiten definiert [DWP ⁺ 07, S.5f]. Das in Abbildung 4.1 dargestellte QMM besteht aus den Elementen Entit¨ at, Attribut, Fakt, Einfluss und Aktivit¨ at.

Entit¨ aten bilden eine Baumstruktur aus Ergebnistypmodellen. Die Autoren bezeichnen die Wurzel des Entit¨ atenbaums als Situation, welche sich beispielsweise wie in Abbildung 4.2 dargestellt zu einem Produkt- und Infrastrukturmodell verfeinern l¨ asst. Attribute entstammen einem Qualit¨ atsmodell und beschreiben die Merkmale von Entit¨ aten.

Abb. 4.1.: Metamodell f¨ ur aktivit¨ atenbasierte Qualit¨ atsmodelle [DWP ⁺ 07, S.6]

Im QMM beschreibt ein Fakt ein Tupel aus Entit¨ at und Attribut. Die Autoren formulieren den Zusammenhang von Fakten und Aktivit¨ aten als

32

Ein Fakt besteht aus einer Entit¨ at e, welche durch ein Attribut A charakterisiert wird. Der Fakt wirkt sich positiv bzw. negativ auf eine Aktivit¨ at a aus. Durch das Zusammenf¨ uhren der Attribute eines Qualit¨ atsmodells und der Entit¨ aten des Ergebnistypmodells wird das 2-dimensionale Qualit¨ ats-Ergebnistyp-Modell zu 1-dimensionalen Fakten. Aktivit¨ aten sind die Phasen eines Prozesses. Wie bereits erw¨ ahnt, k¨ onnen hier Prozesse wie der Standardwartungsprozess in das aktivit¨ atenbasierte Qualit¨ atsmodell eingebettet werden. Die Abbildung von Fakten zu Aktivit¨ aten ist unidirektional. Das bedeutet, dass der Einfluss von Produktqualit¨ at auf die Phasen operationaler Softewareprozesse abgebildet werden kann.

Wie funktioniert die Anpassungsmethode? Zur Anpassung des Modells an ein konkretes Produktumfeld wird ein 5-stufiges Verfahren vorgeschlagen [WDW08, S.31]. Hinter dem Vorgehen versteckt sich der in Abschnitt 3.1.1 beschriebene FCM Ansatz: Formulieren (Schritt 3), Konkretisieren (Schritt 4), Operationalisieren (Schritt 5).

1. Relevante Akteure identifizieren. In diesem ersten Schritt werden zun¨ achst die unterschiedlichen Rollen identifiziert und die Aktivit¨ aten bestimmt, welche sie mit dem System durchf¨ uhren. Dieser Schritt ist n¨ otig, da jede Rolle wegen ihrer spezifischen Aktivit¨ aten andere Anforderungen an die Qualit¨ at eines Softwaresystems stellt. Beispielsweise stellen Nutzer f¨ ur das Erf¨ ullen ihrer fachlichen Aufgaben funktionale Qualit¨ atsanforderungen an das System, welche sich von den Bereitstellungsanforderungen der Administratoren unterscheiden. F¨ ur das Erf¨ ullen der Anforderungen sind Architekten, Entwickler und Tester verantwortlich. Nachdem die Rollen und die relevanten Aktivit¨ aten identifiziert wurden, werden die Aktivit¨ aten auf die Aktivit¨ atendimension des QMM abgebildet.

2. Aktivit¨ aten priorisieren. Nachdem die Aktivit¨ aten bestimmt wurden, werden sie hinsichtlich ihrer Wichtigkeit priorisiert. Wichtigkeit bedeutet hierbei Schwierigkeit und H¨ aufigkeit der Ausf¨ uhrung. Falls w¨ ahrend der Priorisierung Aktivit¨ aten aufkommen, die zuvor nicht definiert wurden, wird die Aktivit¨ atendimension des Modells erweitert. Das Ergebnis des zweiten Schritts ist eine priorisierte Aktivit¨ atenliste, welche in den n¨ achsten Schritten zur Verfeinerung der Anforderungen verwendet wird.

3. Anforderungen qualitativ beschreiben. Im dritten Schritt werden konkrete Fragen bez¨ uglich der Aktivit¨ aten gestellt. Diese Fragen umfassen die Art, wie Aktivit¨ aten gestaltet sein m¨ ussen, damit sie reibungslos in den Gesamtprozess integriert werden k¨ onnen. Aus der Beantwortung der Fragen resultieren die qualitativen Anforderungen an das

33

4. Stand der Forschung

Softwaresystem. Beispielsweise muss in Systemen zur Verarbeitung verteilter Daten die Aktivit¨ at Datenbestand pflegen nebenl¨ aufig durchf¨ uhrbar sein, damit sie durch Sachbearbeiter an unterschiedlichen Standorten gleichzeitig durchgef¨ uhrt werden kann, ohne dass Inkonsistenzen auftreten.

4. Mit Hilfe des Entit¨ atenbaums verfeinern. Schritt 4 behandelt die Abh¨ angikeiten zwischen Anforderungen und ihrer Verfeinerung, indem sie auf Aktivit¨ aten abgebildet werden. Der Entit¨ atenbaum beschreibt sowohl den Aufbau eines System, als auch sein Umfeld. Von der Wurzel ausgehend beinhaltet er beispielsweise die Systemartefakte, die Dokumentationsartefakte und die Entwicklungsumgebung. Die qualitativen Anforderungen aus Schritt 3 werden konkretisiert, indem stufenweise f¨ ur jede Entit¨ at des Baums Attribute bestimmt werden. Diese Attribute stammen aus einem externen Qualit¨ atsmodell wie der ISO/IEC 9126. Die so definierten Fakten bilden die erste Spalte einer Tabelle. Die bereits in Schritt 2 erarbeitete Aktivit¨ atenliste bildet die erste Reihe einer Tabelle. Die Felder dieser 2-dimensionalen Tabelle werden schließlich mit + oder - bef¨ ullt, je nachdem, ob der Fakt die Aktivit¨ at positiv oder negativ beeinflusst. Falls kein Einfluss besteht, bleibt das Feld leer. Abbildung 4.2 zeigt eine Beispieltabelle.

34

5. Anforderungen quantifizieren. Im letzten Schritt werden die konkretisierten Anforderung operationalisiert. Dies geschieht entweder in der Aktivit¨ atendimension oder der Produktqualit¨ atsdimension. Der Vorteil dieser Trennung ist, dass klar zwischen Produkt-und Prozessmessung unterschieden werden kann. Die anhand der Aktivit¨ aten bestimmten Metriken sollen den Prozess messen: z.B. die durchschnittliche Bearbeitungszeit einer Erweiterung. Die Messung der Entit¨ aten findet ¨ uber den Produkteigenschaften statt: z.B. der Dokumenationsgrad der Schnittstellen.

Wozu? Wo? Wann? Wer? Wie? Neben den vielen M¨ oglichkeiten, die aktivit¨ atenbasierte Qualit¨ atsmodelle zur Beantwortung der 5 Fragen mit sich bringen, bleiben einige Punkte offen.

Wozu? - Qualit¨ atsmodelle! In dem Modell wird die Produktqualit¨ at implizit, indem sie w¨ ahrend der Faktenbildung in Schritt 4 durch Attribute hart mit den Entit¨ aten verbunden wird. Damit verschmelzen Produktqualit¨ atsmerkmale und Produktentit¨ aten zu einer Dimension. Diese Verschmelzung f¨ uhrt zu zwei Effekten. Zum Ersten k¨ onnen Qualit¨ atsmodelle nicht vollst¨ andig und austauschbar in das QMM eingebunden werden. Zum Zweiten geht die Hierarchie der einzelnen Qualit¨ atsmerkmale verloren.

Wo? - Ergebnistypmodelle! Bis auf den Umstand, dass Ergebnistyp- und Qualit¨ atsmodelle zu einer Dimension verschmelzen, k¨ onnen sie sehr gut in das QMM in Form von Entit¨ aten eingebunden werden. Die in Abschnitt 3.2 dargestellten Ergebnisse eines IT-Projekts lassen sich in Schritt 4 ohne Weiteres auf den Entit¨ atenbaum abbilden.

Wann? - Prozessmodelle! Der Einfluss von Fakten und Aktivit¨ aten ist nicht bidirektional. Das bedeutet, dass zwar modelliert werden kann, welche Qualit¨ atsanforderungen wichtig f¨ ur eine operationale Aktivit¨ at sind, nicht jedoch welche Softwareentwicklungsaktivit¨ aten auf eine Qualit¨ atsanforderung wirken. Dieser Umstand beschreibt einen entscheidenden Nachteil des QMM.

Wer? - Rollenmodelle! Die Idee, die aus den Rollen entspringenden Aktivit¨ aten in Schritt 1 als Grundlage f¨ ur das Formulieren von Anforderungen zu nutzen ist sehr gut. Da sich Rollen nicht als Modellelement im QMM wiederfinden, existieren sie lediglich implizit, d.h. versteckt hinter ihren Aktivit¨ aten. F¨ ur eine Werkzeugunterst¨ utzung gehen damit wertvolle Berichte verloren, z.B. wer am meisten durch schlechte Auspr¨ agungen von Produktmerkmalen betroffen ist.

Wie? - QS-Maßnahmen! Die unidirektionale Abbildung von Fakten auf Aktivit¨ aten ist im QMM sehr einfach gehalten. In Schritt 4 werden + und - in eine Matrix eingetragen, um den Einfluss eines Faktes auf eine Aktivit¨ at zu markieren. Konkrete Schritte in Form von QS-Maßnahmen k¨ onnen im QMM nicht hinterlegt werden.

35

4. Stand der Forschung

4.1.2. Produktbasiertes Qualit¨ atsmodell: COTS Taxonomie

In diesem Abschnitt wird eine Reihe von Publikationen behandelt, welche an der TU Katalonien (Barcelona/ Spanien) angefertigt wurden. Die Ver¨ offentlichungen beschreiben eine Taxonomie zur Klassifikation betrieblicher Informationssysteme mit dem Ziel, durch ein systematisches Vorgehen die richtige Kaufsoftware f¨ ur ein konkretes Umfeld auszuw¨ ahlen. Neben dem systematischen 7- bzw. 10-stufigen Vorgehen wird in den Papers außerdem der Einsatz in der Praxis beschrieben. In [CFQT04, S.6] erscheint ein Hinweis, dass es sich bei der Taxonomie um ein 2-dimensionales System handelt. Die erste Dimension enth¨ alt charakterisierende Attribute, welche die Anforderungen an die Qualit¨ at des auszuw¨ ahlenden Systems beschreiben. An der zweiten Dimension werden Produkteigenschaften angeordnet, also die Funktionen, die das auszuw¨ ahlende Produkt beherrschen muss. Das so entstehende 2-dimensionale System stellt demnach Qualit¨ atsmodelle und Produktmodelle gegen¨ uber.

In [FC02, S.4ff] wendeten die Autoren in einer Fallstudie ihr Taxonomiemodell f¨ ur die Auswahl eines Mailservers an, indem sie die ISO/IEC 9126 auf die Qualit¨ atsdimension legten und die Produktdimension ausgehend von einer Standard-Mailarchitektur verfeinerten.

In [BBC ⁺ 03] wurde das 2-dimensionale Taxonomiemodell zur Auswahl eines ERP Systems genutzt, indem die ISO/IEC 9126 Merkmale auf die Qualit¨ atsdimension und die geforderten Funktionen des ERP-Systems auf die Produktdimension abgebildet wurden. F¨ ur jedes Merkmal einer Merkmalsgruppe, z.B. die Angemessenheit aus der Gruppe Funktionalit¨ at, wurde bestimmt, welchen Einfluss es auf die Produktfunktionen hat.

Welche Probleme existieren in bestehenden Ans¨ atzen? Die Probleme der bestehenden Ans¨ atze stammen aus den Ver¨ offentlichungen [FC02, S.1] und [CFQT04, S.1]. Ein grundlegendes Problem ist, dass der Markt f¨ ur COTS Software (Commercial Off-The-Shelf) best¨ andig w¨ achst, Pakethersteller sich voneinander abgrenzen m¨ ussen und somit durch die Vielzahl der sich im Detail unterscheidenden Funktionen die richtige Wahl eines Produktes immer schwerer f¨ allt. Da sich Hersteller von COTS Paketen ihren Anspruch auf individuelle Funktionen zur Abgrenzung zur Konkurrenz nicht absprechen lassen werden, ist in diesem Zusammenhang das handhabbare Problem, dass keine strukturierte und verbreitete Beschreibung von Softwaredom¨ anen existiert. Das Fehlen von Standardbeschreibungen f¨ uhrt dazu, dass auch keine Standardqualit¨ atsanforderungen existieren. Damit geschieht die modellbasierte Auswahl von Softwarekomponenten auf jeden Fall immer durch eine Neuerstellung des gesamten Modells. Ein weiteres Problem bestehender Ans¨ atze ist, dass sie COTS Komponenten vergleichen, indem sie sich auf

36

das Erf¨ ullen der fachlichen Anforderungen konzentrieren. Weiche Faktoren politischer, rechtlicher, verwaltungstechnischer oder anderer nichtfunktionaler Art werden allzu oft außer Acht gelassen.

Wie werden die Probleme gel¨ ost? In [FC02, S.8] wird beschrieben, wie die vorgeschlagene Taxonomie die oben angesprochenen Probleme l¨ ost. Dies geschieht, indem eine Methode zur Verf¨ ugung gestellt wird, die Softwaredom¨ anen in eine Ordnung bringt. F¨ ur jede Dom¨ ane werden relevante Funktionen erarbeitet und darauf basierend funktionale und nichtfunktionale Qualit¨ atsanforderungen abgeleitet. Die so definierten, hierarchisch aufgebauten Qualit¨ atsmodelle k¨ onnen wiederverwendet und kontinuierlich verbessert werden, so dass aus ihnen mit der Zeit die angesprochenen, fehlenden Standards bez¨ uglich der fachlichen und qualitativen Beschreibung von Dom¨ anen entstehen. Damit wird das Vergleichen von Paketen der gleichen Produktdom¨ ane erheblich erleichtert.

Wie sieht das zugrunde liegende Modell aus? Die Formalisierung der vorgeschlagenen Taxonomie geschieht zum Einen durch ein fundamentales Taxonomiemodell [CFQT04, S.2], in welchem unterschiedliche Qualit¨ atsmodelle integriert werden k¨ onnen, um die Anforderungen an Produktdom¨ anen festzuhalten. Zum Anderen werden Qualit¨ atsmodelle und die Anforderungen durch eine formale Sprache beschrieben [BBF ⁺ 01], auf welche hier jedoch nicht eingegangen wird.

Das in Abbildung 4.3 dargestellte, fundamentale Modell definiert die m¨ oglichen Modellelemente und die Abh¨ angigkeiten zwischen ihnen. Das Ziel des Taxonomiemodells ist es, den Auswahlprozess f¨ ur betriebliche Informationssysteme zu unterst¨ utzen. In Abh¨ angigkeit ihres Funktionsumfangs k¨ onnen die Systeme einer oder mehreren Dom¨ anen angeh¨ oren. Dom¨ anen gruppieren eine Menge von Funktionen und lassen sich in Kate-gorien unterteilen - sie erscheinen als Bl¨ atter in der Taxonomie. Kategorien k¨ onnen bis zu einer beliebigen Tiefe hierarchisch untergliedert werden. Jeder Kategorie werden schließlich konkrete, charakterisierende Attribute zugeordnet. Dom¨ anen und Kategorien werden durch die Anpassungsmethode mit spezifischen Qualit¨ atsmodellen ausgestattet, deren Qualit¨ atsentit¨ aten entlang der Hierarchie vererbt werden k¨ onnen. Diese Vererbung soll eine Wiederverwandbarkeit der Modelle unterst¨ utzen. In [CFQT04, S.3] wird neben dem hier beschriebenen, fundamentalen Modell auch das auf UML basierende, konzeptionelle Taxonomiemodell vorgestellt.

37

4. Stand der Forschung

Abb. 4.3.: Fundamentales Modell f¨ ur COTS Taxonomien [CFQT04, S.2]

38

Abbildung 4.4 zeigt einen beispielhaften Ausschnitt einer Taxonomie. Dort wird ersichtlich, dass sich der Markt f¨ ur COTS Komponenten zun¨ achst in grobe Kategorien aufteilen l¨ asst, welche stufenweise verfeinert werden, bis sie schließlich den Dom¨ anen zugeordnet werden k¨ onnen. Die Dom¨ anen wiederum gruppieren die in einem Unternehmen relevanten Systeme. Damit stellen Kategorien ein Ordnungssystem zwischen dem COTS Markt und den Systemgruppen eines Unternehmens dar.

In das Taxonomiemodell k¨ onnen beliebge Qualit¨ atsmodelle integriert werden. Abbildung 4.5 zeigt das ISO/IEC 9126 Metamodell. Das Qualit¨ atsmetamodell definiert das FCM Schema nicht anhand von Fakten, Kriterien und Metriken, sondern durch Charakteristiken, Subcharakteristiken, Attribute und messbare Attribute.

Charakteristiken definieren generelle Eigenschaften eines Systems. Wie in Abschnitt 3.1.1 beschrieben, existieren in der ISO/IEC 9126 die Charakteristiken Funktionalit¨ at, Zuverl¨ assigkeit, Benutzbarkeit, Effizienz, ¨ Anderbarkeit und ¨ Ubertragbarkeit. Da diese Charakteristiken zu grob sind, um konkrete Aussagen zu ihnen treffen zu k¨ onnen, werden

39

4. Stand der Forschung

sie zu Subcharakteristiken in einer Baumstruktur verfeinert. Die Charakteristik Effizienz untergliedert sich besipielsweise in die Subcharakteristiken Zeitverhalten und Verbrauchsverhalten. Subcharakteristiken werden durch Attribute charakterisiert, welche nicht in jedem Fall messbar sein m¨ ussen. Messbare Attribute bestehen aus einer Entit¨ at und einer Metrik, mit deren Hilfe quantitative Aussagen zu der Entit¨ at getroffen werden k¨ onnen. Die ” gemessen durch“ Assoziation zeigt an, dass sich die Metriken eines messbaren Attributs in Abh¨ angigkeit der Subcharakteristik durchaus unterscheiden k¨ onnen. Die Entit¨ aten des Qualit¨ atsmetamodells bilden die Schnittstelle zu den Anforderungen und somit zu den Dom¨ anen und Kategorien der COTS Taxonomie.

Wie funktioniert die Anpassungsmethode? Zum Erarbeiten der Dom¨ anen und Anpassen des Qualit¨ atsmodells an ein konkretes Produktumfeld empfiehlt sich ein 7stufiges Vorgehen [FC02, S.2ff], welches zu einer 10-stufigen Version erweitert werden kann [BIC ⁺ 02, S.7ff]. Beide Versionen verwenden f¨ ur das Anpassen des Qualit¨ atsmodells das Metamodell der ISO/IEC 9126. Die 10-stufige Version beinhaltet den Umgang mit einer formalen Sprache. An dieser Stelle wird jedoch lediglich auf die 7-stufige Version eingegangen. Die Methode implementiert den FCM Ansatz: Formulieren (Schritt 1), Konkretisieren (Schritt 2 bis 4), Operationalisieren (Schritt 5).

0. Dom¨ ane analysieren. Bevor die Methode ausgef¨ uhrt werden kann, muss Klarheit ¨ uber

die betrachtete Dom¨ ane existieren. Dies schließt die grobe Beschreibung der Dom¨ ane, das Bestimmen der Abh¨ angigkeiten innerhalb der Dom¨ ane und die Verfeinerung zu den Hauptfunktionen ein. In Hinsicht auf das Modell behandelt der nullte Schritt bis auf die Qualit¨ atsmodelle alle Modellelemente der COTS Taxonomie. Außerdem wird vor dem Anwenden der Methode erwartet, dass der Kategorienbaum bereits vollst¨ andig aufgebaut wurde.

1. Top-Level Qualit¨ atssubcharakteristiken bestimmen. Die Top-Level Subcharakteristiken entsprechen den Qualit¨ atsmerkmalen, welche durch Qualit¨ atsmodelle wie der ISO/IEC 9126 beschrieben werden. Die ISO beschreibt 6 offizielle Charakteristiken, die ihrerseits in informative und inoffizielle Qualit¨ atsmerkmale, d.h. Subcharakteristiken, verfeinert sind. Obwohl die Subcharakteristiken der ISO nicht zwingend alle Aspekte der konkreten Dom¨ ane ber¨ ucksichtigen, empfehlen die Autoren, die ISO zumindest als Startpunkt in Erw¨ agung zu ziehen.

2. Hierarchie der Subcharakteristiken definieren. Im dritten Schritt werden Subcharakteristiken weiter hierarchisch verfeinert, bis der n¨ otige Detaillierungsgrad erreicht ist. Abbildung 4.6 zeigt eine Matrix mit einer Beispielverfeinerung f¨ ur ERP Systeme.

40

Abb. 4.6.: Beispiel f¨ ur Schritt 2: Qualit¨ atsmodell f¨ ur ERP Systeme [BBC ⁺ 03, S.232]

3. Subcharakteristiken zu Attributen verfeinern. Dieser Schritt dient der Verfeinerung des abstrakten Konzepts der Charakteristiken zu konkreten Qualit¨ atsattributen. Ein Attribut behandelt beobachtbare Eigenschaften eines Systems.

4. Abgeleitete Attribute zu Basisattributen verfeinern. Basisattribute sind die in Schritt 3 abgeleiteten, bereits direkt messbaren Attribute. F¨ ur die Attribute, welche zum Messen noch zu abstrakt sind gilt, dass sie in diesem Schritt solange verfeinert werden, bis sie zu Basisattributen und somit messbar werden. Die verfeinerten Attribute heißen abgeleitete Attribute.

5. Metriken f¨ ur Attribute ermitteln. Um die Attribute zu operationalisieren, werden sie in diesem Schritt mit Metriken ausgestattet. W¨ ahrend die Metriken f¨ ur Basisattribute immer quantitativ sind, k¨ onnen sie f¨ ur abgeleitete Attribute sowohl quantitativ, als auch qualitativ sein. Neben einfachen Metriken m¨ ussen f¨ ur bestimmte Attribute einfache Metriken zu Funktionen zusammengesetzt werden. Mit diesem Schritt ist das Anpassen des Modells abgeschlossen.

41

4. Stand der Forschung

6. Beziehungen zwischen Qualit¨ atsentit¨ aten aufdecken. In dem letzten Schritt werden die Beziehungen zwischen den Entit¨ aten des ISO/IEC 9126 Metamodells paarweise bewertet. M¨ ogliche Beziehungstypen sind gleichgerichtet (+), gegens¨ atzlich (-) und neutral. Dieser abschließende Schritt bewirkt, dass die Zusammenh¨ ange der Anforderungen an die Qualit¨ at im Modell klarer werden. In Abbildung 4.7 ist eine Beispielbeziehungsmatrix f¨ ur die Auswahl eines Mail Servers dargestellt.

Abb. 4.7.: Beispiel f¨ ur Schritt 6: Beziehungsmatrix f¨ ur Mail Server [FC02, S.6]

Wozu? Wo? Wann? Wer? Wie? Die COTS Taxonomie wurde f¨ ur einen Auswahlprozess von Kaufsoftware entworfen. Die Idee, unterschiedliche externe Qualit¨ atsmodelle auf ein Produktmodell abzubilden ist sehr gut. Das direkte Anwenden des Taxonomiemodells auf den Entwicklungsprozess f¨ uhrt jedoch zu einigen offenen Punkten.

Wozu? - Qualit¨ atsmodelle! Die COTS Taxonomie hat die Eigenschaft, dass unterschiedliche Qualit¨ atsmodelle verwendet werden k¨ onnen. In der praktischen Anwendung der

42

Taxonomie wurde wie beschrieben das ISO/IEC 9126 Metamodell verwendet, um Qualit¨ atsmerkmale abzubilden. Nach Bedarf kann in das konzeptionelle Taxonomiemodell jedoch auch jedes erdenkliche, andere Qualit¨ atsmetamodell eingebunden werden, um Qualit¨ atsmerkmale auf die Kategorien der Dom¨ anen abzubilden.

Wo? - Ergebnistypmodelle! Da Produktmodelle ¨ ahnlich verfeinert werden, wie Qualit¨ atsmodelle, kann der Kategorienbaum dazu verwendet werden, die Artefakte des Softwareentwicklungsprozesses auf ihn abzubilden. Sowohl Produktkategorien, als auch Entwicklungsartefakte werden von der Wurzel aus feiner. Beispielsweise untergliedert sich ein Architekturmodell zu Software- und Hardwarekomponenten - also vom Groben ins Feine. Lediglich die Bl¨ atter der COTS Taxonomie enthalten grobe Dom¨ anen, welche zur Einordnung der verfeinerten Kategorien dienen.

Wann? - Prozessmodelle! Softwareentwicklungsprozesse behandeln den Lebenszyklus von der Anforderungsanalyse bis zum Einf¨ uhren des Systems. In diesen Prozessen kann noch Einfluss auf die Produktqualit¨ at genommen werden, w¨ ahrend bei der Auswahl von Kaufsoftware Qualit¨ atsanforderungen lediglich gepr¨ uft werden. Die Taxonomie bietet keine M¨ oglichkeit der Integration von Prozessen, so dass keine explizite Aussage getroffen werden kann, in welchen Teilprozessen ein Qualit¨ atsmerkmal hergestellt und an welchen ¨ Ubergabepunkten sein Status abgenommen wird.

Wer? - Rollenmodelle! Aus der fehlenden Prozessorientierung folgt das Fehlen der an dem Schaffen von Qualit¨ at beteiligten Rollen.

Wie? - QS-Maßnahmen! Wie bereits angesprochen, soll mit Hilfe der COTS Taxonomie Kaufsoftware systematisch ausgew¨ ahlt werden. Das heißt insbesondere, dass die Software bereits produziert wurde und kein Einfluss mehr auf dessen Produktqualit¨ at genommen werden kann. Aus diesem Grund spielen QS-Maßnahmen keine Rolle in der Taxonomie.

43

4. Stand der Forschung

4.1.3. Spezialisiertes Qualit¨ atsmodell: QUIM

Im Folgenden wird anhand des QUIM Modells der Concordia Universit¨ at Quebec das Konzept spezialisierter Qualit¨ atsmodelle vorgestellt [SKD01] [SDKP06]. Das Ziel spezialisierter Modelle ist es, das FCM Vorgehen nur einmalig, d.h. nicht f¨ ur jedes Projekt erneut durchzuf¨ uhren. Die so entstehenden, vordefinierten Modelle werden schließlich im passenden Projektumfeld angewendet.

Im Grunde genommen spezialisiert QUIM eine Merkmalsgruppe aus der ISO/IEC 9126, so dass der Zweig der Benutzbarkeit bis zur Messbarkeit verfeinert wird. Dazu wurden f¨ ur die Merkmalsgruppe Benutzbarkeit im FCM Vorgehen 10 Faktoren formuliert, die ihrerseits zu 26 messbaren Kriterien verfeinert wurden. Zur Operationalisierung wurden die 26 Kriterien schließlich zu 127 spezifischen Metriken weiterverfeinert [SDKP06, S.159].

Welche Probleme existieren in bestehenden Ans¨ atzen? Spezialisierte Qualit¨ atsmodelle resultieren aus speziellen Problemen. Die Motivation f¨ ur das Formulieren des QUIM Modells stammt aus dem Umstand, dass bestehende Standards den Faktor Benutzbarkeit nur sehr grob beschreiben [SDKP06, S.160]. Dies wird am Beispiel der ISO/IEC 9126 ersichtlich, da die Benutzbarkeit dort nur eines von 6 Kriterien vorsieht und eine offizielle Verfeinerung nicht zur Verf¨ ugung steht. Das hat zur Folge, dass Qualit¨ atsanforderungen bez¨ uglich der Benutzbarkeit von Softwaresystemen immer wieder f¨ ur jedes Projekt formuliert, konkretisiert und operationalisiert werden m¨ ussen, obwohl in vielen Dom¨ anen gleiche Grunds¨ atze zur Bedienbarkeit grafischer Oberfl¨ achen gelten. Dies wiederum f¨ uhrt dazu, dass Systeme aus unterschiedlichen Benutzbarkeitsstudien nicht miteinander verglichen werden k¨ onnen. Zudem sind Modelle wie die ISO statischer Natur, so dass sowohl der Einfluss zwischen den Qualit¨ atsfaktoren, Kriterien und Metriken unber¨ ucksichtigt bleibt, als auch der Zeitpunkt von Messungen im Entwicklungsprozess außer Acht gelassen wird [SDKP06, S.165]. Nicht zuletzt werden in bestehenden Modellen keine Interpretationsvorlagen f¨ ur die Ergebnisse, welche aus der Metrikanwendung resultieren, bereitgestellt [SDKP06, S.166].

Wie werden die Probleme gel¨ ost? Das Ziel der Autoren ist es, ein konsolidiertes Modell f¨ ur die Benutzbarkeit einzuf¨ uhren. Dadurch wird das Problem gel¨ ost, dass die entsprechende Merkmalsgruppe in bestehenden Standards nur sehr vage formuliert ist. Zudem kann ein konsolidiertes Modell in passenden Projekten immer wieder angewendet werden, wodurch die aus den Projekten resultierenden Systeme wegen des gleichen Modells miteinander vergleichbar werden. Das konsolidierte Modell ist außerdem dynamisch, indem es die Untersuchung der Beziehungen zwischen Faktoren und Kriterien

44

in einer Beziehungsmatrix erm¨ oglicht. Eine grafische Anpassungsmethode zum Erstellen zusammengesetzter Metriken hilft schließlich, das Modell an das konkrete Projektumfeld anzupassen, die f¨ ur die Metrikanwendung ben¨ otigten Daten leichter zu verstehen und die aus der Metrikanwendung entspringenden Ergebnisse besser zu interpretieren.

Wie sieht das zugrunde liegende Modell aus? Die QUIM Modellelemente entsprechen im Allgemeinen dem FCM Modell [SKD01, S.3f], da QUIM 10 Faktoren, 26 Kriterien und 127 Metriken vorgibt, welche jeweils ¨ uber einen Namen und eine Beschreibung verf¨ ugen. Abbildung 4.8 zeigt das QUIM Metamodell.

Die Anwenderqualit¨ at aus der Spitze der QUIM Pyramide beschreibt die Qualit¨ at aus Sicht des Endnutzers. Der Nutzer interessiert sich dabei nicht f¨ ur die innere Codequalit¨ at, sondern ausschließlich f¨ ur Faktoren rund um die Systemnutzung.

QUIM stellt 10 Benutzbarkeitsfaktoren zur Verf¨ ugung, namentlich Effizienz, Effektivit¨ at, Produktivit¨ at, Zufriedenheit, Erlernbarkeit, Sicherheit, Vertrauensw¨ urdigkeit, Barrierefreiheit, Universalit¨ at sowie N¨ utzlichkeit [SDKP06, S.168f]. Die 10 Faktoren k¨ onnen un-tereinander verschiedene Beziehungstypen eingehen. So kann in einem Online-Banking Portal davon ausgegangen werden, dass die Vertrauensw¨ urdigkeit des Systems nur hergestellt werden kann, wenn sowohl eine hohe Sicherheit, als auch eine hohe Zufriedenheit geboten wird.

45

4. Stand der Forschung

Wie in anderen Modellen auch, gibt es in QUIM Subfaktoren, welche als Kriterien bezeichnet werden. Jedes Kriterium muss durch Metriken messbar sein. Beispiele f¨ ur Kriterien sind Attraktivit¨ at, Konsistenz, minimale Klickanzahl, minimaler Arbeitsspeicherverbrauch oder die Vollst¨ andigkeit bez¨ uglich einer spezifischen Aufgabe.

In QUIM ist das Ergebnis einer Metrikanwendung ein numerischer Wert, der den Status eines Kriteriums zusammenfasst. Die insgesamt 127 Metriken [SDKP06, S.170] teilen sich in zusammengesetzte Metriken - d.h. Funktionen - und einfach z¨ ahlbare Daten auf.

Die Grundlage von QUIM sind Daten, welche als Eingabe in die Metriken einfließen. M¨ ogliche Datenquellen sind Nutzeranforderungen, Erfahrungen von Benutzbarkeitsexperten, Umfragen, Benutzerhandb¨ ucher, Entwurfsartefakte oder Prototypen. Daten k¨ onnen dabei qualitativer oder quantitativer Natur sein.

Es gibt zwei unterschiedliche M¨ oglichkeiten, um durch Metrikanwendung aus den Eingabedaten Ergebnisse zu erzeugen. Zum Ersten k¨ onnen Daten z¨ ahlbar sein. Falls dies der Fall ist, k¨ onnen die Daten einfach als Metrik verstanden werden, welche einem Kriterium

46

direkt zugeordnet wird. Ein Beispiel f¨ ur z¨ ahlbare Daten ist die Anzahl der Bedienelemente auf dem Bildschirm. Zum Zweiten k¨ onnen Daten weiterverarbeitet werden. In diesem Zusammenhang treten sie als Parameter f¨ ur eine Berechnungsfunktion auf.

Abbildung 4.9 zeigt die Beziehungen zwischen den QUIM Modellelementen anhand einer Beispielbeziehungsmatrix. Das QUIM Modell spannt keinen Baum auf, da seine Elemente in einer n:m Beziehung stehen.

Die n:m Beziehung wird beispielsweise an den Metriken ersichtlich, welche zum Messen unterschiedlicher Kriterien herangezogen werden. Anhand der Beziehungen kann vorhergesehen werden, wie sich konkrete Modellelemente auf die Anwenderqualit¨ at als Ganzes auswirken und durch welche Entwicklungsphasen sie beeinflusst werden. So kann aus der Beziehungsmatrix in Abbildung 4.9 beispielsweise abgelesen werden, dass sich Effektivit¨ at und Effizienz verbessern l¨ asst, wenn eine flache Oberfl¨ achenhierarchie angestrebt wird. Diese Information f¨ uhrt zu der Erkenntnis, dass Effizienz und Effektivit¨ at in der Entwurfsphase des Entwicklungsprozesse gesichert werden k¨ onnen, indem im GUI-Entwurf die Oberfl¨ achenhierarchie unter besonderer Ber¨ ucksichtigung steht.

Wie funktioniert die Anpassungsmethode? Um das Ziel der Wiederverwendung spezialisierter Qualit¨ atsmodelle f¨ ur ein abgegrenztes Projektumfeld zu erreichen, m¨ ussen auch spezialisierte Modelle angepasst werden - zumindest einmalig, d.h. initial f¨ ur das abzugrenzende Umfeld. Leider wird f¨ ur einige Projekte innerhalb des abgegrenzten Umfelds weiterhin gelten, dass sie dem spezialisierten Modell nicht 100%ig entsprechen. Dies f¨ uhrt zu der Notwendigkeit einer zumindest teilweisen Anpassung und damit dem teilweisen Wiederholen der Anpassungmethode im konkreten Projekt. Wegen der stufenweisen Verfeinerung von Qualit¨ atsmodellen gilt, dass die Wahrscheinlichkeit von Anpassungen der unteren Ebene von Modellen h¨ oher ist, als die Wahrscheinlichkeit von Anpassungen der Faktoren. Dies wird beispielsweise ersichtlich am Einsatz unterschiedlicher Messtechnologien und der damit verbundenen Notwendigkeit des Anpassens der Verk¨ upfungen von Daten und Metriken.

Im Folgenden wird das initiale Erstellen des spezialisierten QUIM Modells als Spezialfall einer Anpassungsmethode beschrieben. QUIM resultiert zun¨ achst aus dem FCM Vorgehen [SKD01, S.4f]. Das heißt, dass Faktoren ¨ uber Kriterien zu Metriken verfeinert

werden. QUIM geht jedoch noch weiter, indem es Metriken zu den Daten aufschl¨ usselt, welche n¨ otig sind, um die Metriken anwenden zu k¨ onnen.

47

4. Stand der Forschung

Das bereits in Abbildung 4.8 gezeigte Metamodell wird in Abbildung 4.10 durch die Quellen erweitert, aus denen die Daten stammen. Hier wird ein weiterer Grund ersichtlich, warum das konsolidierte QUIM Modell nicht auf alle Projekte eines abgegrenzten Umfelds ohne Anpassung angewendet werden kann. Es ist davon auszugehen, dass Software nicht in allen Unternehmen in gleich ablaufenden Entwicklungsprozessen hergestellt wird. Dieser Umstand hat die Eigenschaft, dass in Unternehmen nicht alle Artefakte gleichermaßen existieren und sich die Datenquellen somit unterscheiden. Zwar k¨ onnen diese Unternehmen die konsolidierten Faktoren, Kriterien und Metriken wiederverwenden, eine Anpassung ist im beschriebenen Fall auf der untersten Ebene dennoch n¨ otig.

Aus der erweiterten Abbildung geht außerdem hervor, dass Qualit¨ at top-down ausgehend von der Anwenderqualit¨ at ¨ uber die Messdaten hin zu den messbaren Artefakten spezifiziert wird. Hinsichtlich des Messens mit dem Modell verl¨ auft der Weg umgekehrt, d.h. bottom-up. Die spezifischen Eigenschaften der Entwicklungsartefakte fließen als Daten in die Metriken ein, welche zur Anzeigen des Status eines Kriteriums dienen.

Sobald alle Elemente der QUIM Pyramide ermittelt wurden, werden im n¨ achsten Schritt die Beziehungen zwischen Daten, Metriken, Kriterien und Faktoren gem¨ aß Abbildung 4.9 identifiziert. Da anhand der Beziehungen die konkreten Berechnungsvorschriften nicht intuitiv abgeleitet werden k¨ onnen, wurde zu diesem Zweck die grafische Notation GD-QA entwickelt [BKA01]. Abbildung 4.11 zeigt die beispielhafte Anwendung der GDQA Notation.

48

Daten und Metriken werden in einer Matrix gegen¨ ubergestellt. F¨ ur jede Metrik werden die Daten durch einen Kreis markiert, welche als Parameter in die Berechnungsvorschrift einfließen. Falls eine Metrik zusammengesetzt, d.h. berechnet durch Subtraktion oder Division ist, wird an sie eine Raute vorangestellt. Die GDQA unterst¨ utzt außerdem

49

4. Stand der Forschung

Metrikgewichtungen, da die zu summierenden Metriken einen unterschiedlich hohen Einfluss auf die Berechnung des Status eines Kriteriums besitzen k¨ onnen. Abbildung 4.12 zeigt die durch die GDQA ermittelten Funktionen in Tabellenform.

Wozu? Wo? Wann? Wer? Wie? QUIM ist ein spezialisiertes Qualit¨ atsmodell, welches in einem bestimmten Umfeld Anwendung findet. Trotz der Spezialisierung soll an dieser Stelle kurz darauf eingegangen werden, welche Fragen QUIM beantworten kann und welche Fragen ungekl¨ art bleiben.

Wozu? - Qualit¨ atsmodelle! QUIM ist per se ein Qualit¨ atsmodell, welches die Merkmalsgruppe der Benutzbarkeit gem¨ aß FCM bis zur Messbarkeit verfeinert. Aus diesem Grund k¨ onnen sehr konkrete und ¨ uber unterschiedliche Projekte vergleichbare Aussagen zu

Merkmalen hinsichtlich der Benutzbarkeit getroffen werden. F¨ ur eine volle Unterst¨ utzung der ISO/IEC 9126 m¨ usste eine Bibliothek spezialisierter Modelle f¨ ur alle Merkmalsgruppen - d.h. neben der Benutzbarkeit auch f¨ ur die Funktionalit¨ at, Zuverl¨ assigkeit, Effizienz, ¨ Anderbarkeit und ¨ Ubertragbarkeit - zur Verf¨ ugung gestellt werden. Die einzelnen Modelle der Modellbibliothek k¨ onnten ohne Weiteres auf die Qualit¨ atsdimension des multidimensionalen Zielraums abgebildet werden.

Wo? - Ergebnistypmodelle! Die Ergebnistypen sind in QUIM nur implizit enthalten. Wie in Abbildung 4.10 dargestellt, fließen Ergebnistypmodelle lediglich in Form von Prim¨ ar- und Sekund¨ arartefakten als Grundlage f¨ ur die Datenerhebung ein. Diese Artefakte werden nicht direkt, sondern ¨ uber Daten und Metriken auf Faktoren und Kriterien abgebildet.

Wann? - Prozessmodelle! Obwohl die QUIM Autoren darauf eingehen, dass durch die Interpretation einer Beziehungsmatrix gem¨ aß Abbildung 4.9 abgeleitet werden kann, wie die Qualit¨ at durch die Prozessphasen beeinflusst werden, sind Prozesse in QUIM nicht direkt in Form von Modellelementen enthalten. Anhand der Artefakte, welche als Eingabe f¨ ur die Daten der Metriken dienen, kann zwar bestimmt werden, wann eine Messung durchgef¨ uhrt werden muss, es gilt jedoch auch hier, dass dies im Ermessen des Modellnutzers liegt.

Wer? - Rollenmodelle! Das gesamte Qualit¨ atsmodell wurde an der Rolle des Anwenders, d.h. des Nutzers ausgerichtet. Auf andere Rollen, welche am Umgang mit dem Modell und besonders am Schaffen von Qualit¨ at beteiligt sind, wird nicht eingegangen.

Wie? - QS-Maßnahmen! Wegen der Verfeinerung einer konreten Merkmalsgruppe bis hin zur Messbarkeit kann QUIM f¨ ur analytische QS-Maßnahmen verwendet werden. Konstruktive QS-Maßnahmen werden jedoch nicht explizit modelliert. Der Umgang mit dem Modell, die konkrete Durchf¨ uhrung und Dokumentation der Messung sowie ihre

50

Integration in das Unternehmensumfeld bleiben außer Acht. Wegen des modellhaften Charakters sind spezialisierte Modelle jedoch ideal, um sie auf die Qualit¨ atsdimension des multidimensionalen Zielraums zu legen.

4.1.4. Zielorientiertes Qualit¨ atsmodell: Goal Question Metric

Im Folgenden wird der von Basili, Rombach und Caldiera vorgestellte GQM Ansatz beschrieben [BCR94]. Neben der Anwendung von GQM in der Praxis [CFF ⁺ 97] [LSO ⁺ 98] [FLM ⁺ 98] [BHP ⁺ 99] [KSPR01] fließt die Idee der Zielorientierung derzeit im Rahmen des Quamoco Projekts in das Erstellen eines einheitlichen Modells f¨ ur Softwarequalit¨ at ein [KLTM10][S.5]. Die Intention zielorientierter Modelle ist es, konkrete Qualit¨ atsziele an den strategischen Unternehmenszielen auszurichten. F¨ ur diesen Zweck wurde eine Struktur - das sogenannte GQM Template - erarbeitet, welche das systematische Ableiten der Ziele vereinfacht [BCR94][S.4]. Ein immer wieder aufgegriffenes Beispiel f¨ ur ein Ziel ist:

Purpose Issue Object (process)

Viewpoint Jedes Ziel besteht demnach aus einer Absicht (Purpose), einem Problem (Issue), einem Objekt (Produkte, Prozesse, Ressourcen) und einer Perspektive (Viewpoint). Die Ziele werden schließlich durch Fragen konkretisiert und durch Metriken operationalisiert. Bez¨ uglich der Verfeinerung implementiert GQM das FCM Vorgehen. Es gilt:

Formulate

Concretize Measurealize with

Welche Probleme existieren in bestehenden Ans¨ atzen? In dem Erfahrungsbericht der Schlumberger RPS (Retail Petroleum Systems) [LSO ⁺ 98][S.79] ist die Motivation f¨ ur das Einf¨ uhren von GQM und somit ein Problem des bestehenden Vorgehens im praktischen Umfeld geschildert. Messdaten vieler Projekte sammelten sich ¨ uber

51

4. Stand der Forschung

die Jahre an. Das Fehlen unternehmensweiter Messziele f¨ uhrte jedoch dazu, dass Messungen isoliert voneinander durchgef¨ uhrt wurden und somit inkonsistent und unvollst¨ andig waren. Ein aussagekr¨ aftiger und projekt¨ ubergreifender Vergleich wurde dadurch unm¨ oglich. Aus der fehlenden M¨ oglichkeit des projekt¨ ubergreifenden Vergleichs folgte die Vernachl¨ assigung des organisationellen Lernens. Dieses und weitere Probleme sind auch in einer Ver¨ offentlichung des Software Engineering Laboratory der NASA beschrieben [BZP ⁺ 94][S.9]. Dort wird beispielsweise argumentiert, dass der Grund von Prozessverbesserungen die Verbesserung der aus den Prozessen resultierenden Produkte ist. Damit kann die ¨ Anderung von Prozessen nicht gerechtfertigt werden, wenn sich die Produkte nicht verbessern. In einem Qualit¨ atsmodell, welches diese Verbesserung unterst¨ utzen soll, m¨ ussen damit sowohl Prozesse, als auch Produkte R¨ ucksicht finden.

Wie werden die Probleme gel¨ ost? GQM beschreibt einen zielorientierten Messansatz. Um die beschriebenen Probleme zu l¨ osen, werden an ihn drei Anforderungen gestellt [BCR94][S.1f].

Fokus auf spezifische Ziele. Die Definition und Messung von Qualit¨ at muss an Zielen ausgerichtet werden. Die Zielorientierung bietet den Rahmen, an dem Messprogramme projekt¨ ubergreifend ausgerichtet werden. Durch das Verfolgen der gleichen Ziele werden Projekte miteinander vergleichbar.

Ber¨ ucksichtigung von Produkten, Prozessen und Ressourcen. Ziele m¨ ussen sowohl f¨ ur Produkte, als auch f¨ ur Prozesse und die damit verbundenen Ressourcen definiert werden k¨ onnen. Wenn davon auszugehen ist, dass Prozessverbesserungen nur gerechtfertigt sind, wenn sich dadurch auch die Produkte verbessern, m¨ ussen Produkt- und Prozessziele zun¨ achst klar voneinander abgegrenzt werden. Da Projekte die konkreten Prozessschritte befolgen und im Idealfall einheitliche Prozesse innerhalb einer Organisation gelten, werden Prozessziele f¨ ur alle Projekte definiert, welche nach dem entsprechenden Prozess vorgehen. Nach Abschluss mehrerer Projekte muss untersucht werden k¨ onnen, ob die ¨ ubergreifenden Prozessziele zu einer leichteren Erreichung der projektspezifischen Produktziele f¨ uhren. Die Ergebnisse der Untersuchung sollten schließlich in einen Lernprozess einfließen.

Ausrichtung an strategischen Zielen. Um in der Praxis einsatzf¨ ahig zu sein, muss sich ein Messansatz in eine Organisation integrieren lassen. Das bedeutet, dass Produkt- und Prozessziele an den strategischen Zielen der Unternehmensleitung auszurichten sind. Damit soll erm¨ oglicht werden, dass die Leitung f¨ ur bestimmte Bereiche Pflichtziele festlegen kann. Nach der Meinung der Autoren muss eine Methode f¨ ur zielorientiertes Messen aus diesem Grund top-down ausgelegt sein.

52

Wie sieht das zugrunde liegende Modell aus? Aus dem Namen des GQM Ansatzes folgen seine Modellelemente - Ziele, Fragen und Metriken. Abbildung 4.13 zeigt die Zusammenh¨ ange innerhalb des Modells. F¨ ur jedes Ziel stellt sich eine Menge von Fragen, welche durch Metriken quantifiziert werden.

Die Autoren beschreiben in [BCR94][S.3] den Aufbau des Modells in drei Ebenen.

Konzeptionelle Ebene (Ziele). Ein Ziel ist f¨ ur ein Messobjekt aus einer Vielzahl von Gr¨ unden in Hinblick auf unterschiedliche Modelle des Software Engineering aus einer bestimmten Perspektive f¨ ur eine abgesteckte Umgebung definiert. Messobjekte k¨ onnen Produkte, Prozesse oder Ressourcen sein.

Operationale Ebene (Fragen). Fragen charakterisieren das Messobjekt unter dem Gesichtspunkt eines konkreten Qualit¨ atsmerkmals. Sie spiegeln das Interesse aus einer bestimmten Perspektive wider. Ein Projektmanager wird beispielsweise andere Fragen stellen, als ein Architekt.

Quantitative Ebene (Metriken). Ein Satz an Daten wird mit jeder Frage verkn¨ upft, um diese quantitativ beantworten zu k¨ onnen. Daten k¨ onnen sowohl objektiv, als auch subjektiv sein. Objektive Daten betreffen ausschließlich das Messobjekt. Die Anzahl der Programmversionen ist beispielsweise aus jeder Perspektive gleich. Da Fragen aus einer Perspektive heraus gestellt werden k¨ onnen, haben objektive Daten den Vorteil, dass sie f¨ ur eine Vielzahl von Fragen wiederverwendet werden k¨ onnen. F¨ ur subjektive Daten muss neben dem Messobjekt auch die Perspektive ber¨ ucksichtigt werden. Die Verst¨ andlichkeit

53

4. Stand der Forschung

eines Textes h¨ angt zum Beispiel von dessen Leser ab, d.h. dass ein Mitarbeiter, welcher von Anfang an am Projekt beteiligt war, dessen Dokumention leichter versteht, als ein Mitarbeiter, der sich neu einarbeiten muss.

Wegen der Zielorientierung werden Ziele im GQM Ansatz besonders hervorgehoben. Abbildung 4.14 zeigt das GQM Template, welches die Definition der Ziele erheblich vereinfachen soll. Mit der Hilfe des Templates werden Ziele nicht in einem Freitext formuliert, sondern systematisch abgeleitet.

Wie funktioniert die Anpassungsmethode? Die Methode zum Anpassen des Modells ist in das Quality Improvement Paradigm (QIP) - einer Methode zum Betreiben des Modells - eingebettet [LSO ⁺ 98, S.80ff] [KLTM10, S.2f]. Abbildung 4.15 zeigt die Schritte des QIP f¨ ur das Anpassen und das Anwenden des GQM Ansatzes. Auf das QIP als Ganzes wird allerdings erst in Abschitt 4.3.1 eingangen, da an dieser Stelle der Fokus auf dem eingebetteten, FCM-artigen Anpassungsprozess liegt [LSO ⁺ 98, S.80ff].

54

Das Formulieren der Faktoren, d.h. Ziele findet in Schritt 2 statt. Die Verfeinerung zu Kriterien, d.h. Fragen und Metriken geschieht in Schritt 3.

4. Stand der Forschung

3. Messprogramm entwickeln. Die Hauptaktivit¨ at dieses Schritts liegt in der Verfeinerung der Ziele ¨ uber Fragen hin zu Metriken. Der Schritt wird jedoch in 2 Phasen aufgeteilt. Zun¨ achst wird das n¨ otige Wissen gesammelt, welches schließlich in die Verfeinerung einfließt.

3.1. Wissen einholen. Es werden strukturierte Interviews mit dem Projektteam durchgef¨ uhrt, um aus implizitem Erfahrungsschatz explizites Wissen zu generieren. Grundlage der Interviews ist dabei ein erweitertes GQM Template [LSO ⁺ 98, S.82], in welchem zus¨ atzliche Informationen zu jedem Ziel abgelegt werden k¨ onnen. Zun¨ achst wird ermittelt, welche messbaren Attribute f¨ ur ein Ziel existieren und welche Erwartungen an das Ergebnis der Messung gestellt werden. Außerdem werden Einflussfaktoren bestimmt, von welchen erwartet wird, dass sie sich auf das Erreichen eines Ziels auswirken. Damit nicht lediglich dokumentiert wird, dass Einflussfaktoren existieren, wird zus¨ atzlich dokumentiert, wie sich die Einflussfaktoren auf ein Ziel auswirken. Durch diesen Schritt wird das Bild ¨ uber die Ziele wesentlich deutlicher, indem die wichtigsten Verfeinerungsfragen bereits hier auftreten.

3.2. Messung planen. Das Ziel dieses Schritts ist es, ein Messprogramm aufzusetzen, welches im GQM-, Mess- und Analyseplan festgehalten wird. Dazu werden zun¨ achst die Ziele im top-down Vorgehen ¨ uber Fragen zu Metriken verfeinert und im GQM Plan aufgenommen. Das Ableiten der Fragen und Metriken basiert auf den Informationen der im vorhergehenden Schritt ausgef¨ ullten Templates. In einem Review des GQM Plans durch das Projektteam werden die einheitliche Projektsprache, die Vollst¨ andigkeit und das Nichtvorhandensein von Zweideutigkeiten gepr¨ uft. Im Messplan werden Metriken, Erhebungsmethoden und Werkzeuge beschrieben, die f¨ ur das Sammeln und Validieren der Daten n¨ otig sind. Der Messplan enth¨ alt f¨ ur jede Metrik neben Name, Definition, Klassifikation und Verkn¨ upfung zum GQM Plan auch den Zeitpunkt, wann und wie die Daten der Metrik im Entwicklungsprozess erhoben werden k¨ onnen. Der letzte Lieferge-genstand dieses Schritts ist der Analyseplan. In ihm ist aufgef¨ uhrt, wie die Messdaten analysiert, aggregiert und visualisiert werden. Ferner wird in ihm auch beschrieben, wie die erhobenen Daten mit den Grundannahmen aus dem Zieltemplate verglichen werden k¨ onnen.

Wozu? Wo? Wann? Wer? Wie? Durch das GQM Template k¨ onnen die Fragen bereits gut beantwortet werden, da Ziele zur Messung von Objekten dienen und Messobjekte Produkte, Prozesse oder Ressourcen sein k¨ onnen. Ein Nachteil ist jedoch, dass die 5 Fragen nur unabh¨ angig voneinder betrachtet werden k¨ onnen, da Messobjekte zu einer Zieldimension zusammengefasst sind. Damit k¨ onnen objekt¨ ubergreifende Zusammenh¨ ange, d.h. wer in welchem Prozessschritt f¨ ur die Qualit¨ at eines Produktes verantwortlich ist,

56

nicht modelliert werden. Desweiteren sind die Dimensionen bez¨ uglich der 5 Fragen nicht klar voneiner abgegrenzt.

Wozu? - Qualit¨ atsmodelle! Die Merkmale eines Qualit¨ atsmodells wie der ISO/IEC 9126 treten teilweise in der Problemdimension (Issue) auf. Im GQM Template aus Abbildung 4.14 wird dies ersichtlich an den Problemgruppen Effektivit¨ at und ¨ Anderbarkeit. Dort

tritt das Merkmal Richtigkeit auf, welches in der ISO unter der Merkmalsgruppe Funktionalit¨ at angeordnet ist. Da die Zieldimensionen des Templates einfache Listen sind, geht die Verfeinerungsstruktur der Modelle und somit die M¨ oglichkeit der Aggregation verloren.

Wo? - Ergebnistypmodelle! Die Ergebnistypen gem¨ aß Abbildung 3.5 finden sich in der Messobjektdimension wieder. Dort treten im GQM Template aus Abbildung 4.14 neben Prozessen auch Modelle, Metriken, Tests und Reviews auf. Diese Vermischung weist auf die bereits angesprochene Themen¨ uberlappung innerhalb der Zieldimensionen hin.

Wann? - Prozessmodelle! Der Prozess tritt im GQM Template lediglich als Messobjekt auf. Wegen der fehlenden expliziten Prozessdimension kann nicht definiert werden, wann im Prozess ein Qualit¨ atsmerkmal f¨ ur einen bestimmten Ergebnistyp ber¨ ucksichtigt werden muss.

Wer? - Rollenmodelle! Rollen kommen im GQM Template als eigene Dimension vor. Da ein Ziel beschreibt, aus welcher Perspektive ein Messobjekt analysiert werden soll, kann die Abh¨ angigkeit von Prozessen bzw. Produkten und den Rollen modelliert werden.

Wie? - QS-Maßnahmen! Im GQM Template treten QS-Maßnahmen in der Messobjektdimension in Form von Tests und Reviews auf. Das heißt, dass nicht modelliert wird, welche Ziele durch QS-Maßnahmen erreicht werden sollen, sondern lediglich, welche Ziele f¨ ur die Maßnahmendurchf¨ uhrung gelten.

4.2. Zwischenstand

An dieser Stelle wird die in Kapitel 1 gestellte Frage wiederholt:

Welche Qualit¨ atsmerkmale m¨ ussen in einem bestimmten Ergebnistyp wann f¨ ur wen ber¨ ucksichtigt werden und welche wirksamen Qualit¨ atssicherungsmaßnahmen existieren diesbez¨ uglich? - Wozu? Wo? Wann? Wer? Wie?

57

4. Stand der Forschung

Die vorgestellten Ans¨ atze k¨ onnen zwar die Einzelfragen teilweise beantworten - die An-wort auf die Ursprungsfrage bleibt jedoch unbeantwortet. Tabelle 4.16 bietet einen zusammenfassenden ¨

Zun¨ achst f¨ allt auf, dass in keinem der betrachteten Ans¨ atze QS-Maßnahmen explizit im Modell enthalten sind. Im Folgenden wird kurz zusammengefasst, inwiefern sich mit den einzelnen Ans¨ atzen die Fragen ” Wozu? Wo? Wann? Wer?“ beantworten lassen.

Aktivit¨ atenbasiert. Qualit¨ atsmodelle werden im aktivit¨ atenbasierten Ansatz zwar unterst¨ utzt, sie existieren jedoch nicht explizit als Dimension, sondern als Attribute von Entit¨ aten. Da Entit¨ aten in einer Baumstruktur modelliert werden k¨ onnen, k¨ onnen Ergebnistypmodelle gem¨ aß 3.2 als eine Dimension abgelegt werden. Im Metamodell ist die Beziehung zwischen dem Produktmodell und dem Prozessmodell unidirektional. Dies f¨ uhrt zwar zur impliziten Darstellbarkeit des Einflusses der Produktqualit¨ at auf die Softwarenutzungsaktivit¨ aten, der Einfluss von Entwicklungsaktivit¨ aten auf die Produktqualit¨ at kann jedoch nicht explizit modelliert werden. Obwohl im ersten Schritt der Anpassungsmethode Rollen f¨ ur die Bestimmung der Aktivit¨ aten herangezogen werden, existieren keine Rollen im Metamodell.

58

Produktbasiert - COTS Taxonomien. Da der Ansatz f¨ ur die Auswahl von Kaufsoftware formuliert wurde, existieren Entstehungsprozesse und die daran beteiligten Rollen nicht im Taxonomiemodell. Das Taxonomiemodell bietet daf¨ ur aber die M¨ oglichkeit, unterschiedliche Qualit¨ atsmodelle zu verwenden und diese mit dem Produktmodell in Beziehung zu setzen. Produktmodelle bestehen hierbei aus einem Kategorienbaum, welcher an den Bl¨ attern mit Produktdom¨ anen verbunden wird. Bis auf die Dom¨ anenbl¨ atter k¨ onnen Ergebnistypmodelle auch hier gem¨ aß Abschnitt 3.2 als eine Dimension betrachtet werden.

Spezialisiert - QUIM. Spezialisierte Qualit¨ atsmodelle werden mit Hilfe von FCM oder GQM initial definiert. Sie bieten eine feste Menge an Merkmalen, welche bis zur Messbarkeit durch Metriken verfeinert wurden. Am Beispiel von QUIM wurde ein Modell vorgestellt, welches speziell die Benutzbarkeit aus der ISO/IEC 9126 behandelt. Diese spezialisierten Modelle sind sehr gut f¨ ur die Abbildung auf eine Qualit¨ atsdimension geeignet, da sie im entsprechenden Projektkontext immer wieder verwendet werden k¨ onnen. Am Beispiel von QUIM wurde außerdem deutlich, dass sich spezialisierte Modelle sogar bis zu den Artefakten verfeinern lassen, welche die Daten f¨ ur die Anwendung der Metriken liefern. Die Ergebnistypen werden damit zumindest bez¨ uglich analytischer Maßnahmen ber¨ ucksichtigt. Um die gesamte ISO/IEC 9126 durch spezialisierte Qualit¨ atsmodelle zu operationalisieren, sind 6 spezialisierte Modelle n¨ otig. Die Beschr¨ ankung auf die Beschreibung der Produktqualit¨ at und die Vernachl¨ assigung der Beschreibung von Prozessen und Rollen gehen aus diesem Grund einher. Spezialisierte Modelle fließen daher beispielsweise in aktivit¨ aten- oder produktbasierte Modelle ein. Dort k¨ onnen konkrete Beziehungen zwischen Qualit¨ at, Aktivit¨ aten und Produkten hergestellt werden.

Zielbasiert - GQM. In GQM werden zun¨ achst Ziele definiert, welche bis zur Messbarkeit verfeinert werden. Ziele bestehen aus einer Absicht (Purpose), einem Problem (Issue), einem Objekt (Produkte, Prozesse, Ressourcen) und einer Perspektive (Viewpoint). Bis auf eine explizite Dimension f¨ ur Rollen, welche im GQM Template aus Abbildung 4.14 den Namen Perspektive tr¨ agt, sind die Elemente der anderen Software Engineering Modelle im GQM Template verstreut. Produkte, Prozesse und Ressourcen entsprechen dort einer Dimension, dem Objekt, welches gemessen werden soll. Das Qualit¨ atmodell versteckt sich in der Problemdimension. Dort kommen neben Effektivit¨ at und Richtigkeit auch Kosten und Defekte als Modellelemente vor.

Obwohl keiner der Ans¨ atze ideal f¨ ur das Beantworten der Fragen ist, geht aus Tabelle 4.16 hervor, dass der GQM Ansatz die meisten Fragen ber¨ ucksichtigt. Aus diesem Grund wird in dem folgenden Abschnitt anhand des GQM Ansatzes darauf eingegangen, wie ein Ansatz f¨ ur Softwarequalit¨ at im Unternehmen tats¨ achlich angewendet werden kann.

59

4. Stand der Forschung

4.3. Anwenden des GQM Ansatzes

Aus dem Zwischenstand geht hervor, dass der GQM Ansatz am Besten zur Beantwortung der Fragen ” Wozu?“, ” Wo?“, ” Wann?“ und ” Wer?“ geeignet ist. Aus diesem Grund wird

im Folgenden lediglich auf das Betreiben des GQM Ansatzes eingegangen.

4.3.1. Software Engineering Laboratory

Basili und Caldiera argumentieren [BC95, S.55f], dass das Anwenden von Lessons Learned aus dem produzierenden Bereich im Softwarebereich h¨ aufig zu Problemen f¨ uhrt. Dies liegt begr¨ undet in der Tatsache, dass Software nicht in hohen St¨ uckzahlen in Fertigungsprozessen produziert, sondern durch das Wissen, die Erfahrung und die Kreativit¨ at der Mitarbeiter getragen wird. Damit geht einher, dass sich in Softwareentwicklungsprozessen Abl¨ aufe nicht in der Form automatisieren lassen, wie dies beispielsweise an Fertigungsb¨ andern m¨ oglich ist. Verglichen mit einer Produktionsstraße, welche hohe St¨ uckzahlen identischer Produkte liefert, entspringt jede Software einer Individualentwicklung. In diesen Individualentwicklungen wird es sich nat¨ urlich als schwieriger erweisen, Daten im Sinne einer statistischen Prozesskontrolle zu erheben und die Prozesse anhand dieser Daten zu verbessern.

Die Autoren schreiben in [BC95, S.57] [BCM ⁺ 92, S.370], dass der GQM Ansatz sowohl ein Messkonzept, als auch ein Vehikel zur Steuerung des Quality Improvement Paradigm (QIP) ist. Durch GQM werden Zielen definiert, welche ¨ uber Fragen zu Metriken verfeinert werden. Diese liefern schließlich die quantitativen Daten f¨ ur das QIP. Damit das QIP in einem Unternehmen praktisch Anwendung finden kann, wird neben dem Steuerungsvehikel auch ein organisatorisches Werkzeug ben¨ otigt. Basili und Caldiera sehen dieses Werkzeug in Form einer Experience Factory. Nicht zuletzt ist QIP ein evolution¨ ares Konzept, welches zur kontinuierlichen Verbesserung f¨ uhrt. Die drei Konzepte QIP, GQM sowie Experience Factory bilden das Software Engineering Laboratory (SEL). Das GQM Modell und die im Rahmen seiner Anpassung durchzuf¨ uhrenden Schritte innerhalb des QIP wurden bereits in Abschnitt 4.1.4 beschrieben. Dort lag der Fokus allerdings auf den Aktivit¨ aten, welche relevant f¨ ur die Anpassung, d.h. die Verfeinerung von Zielen uber Fragen hin zu Metriken, waren. Bevor auf die Experience Factory eingangen wird, ¨

wird zun¨ achst die Beschreibung des QIP vervollst¨ andigt.

Wie funktioniert das Quality Improvement Paradigm (QIP)? Abbildung 4.17 zeigt das durch Basili und Caldiera vorgestellte, originale QIP. Dieses unterscheidet sich

60

geringf¨ ugig bei der Benennung der einzelnen Schritte von dem in 4.15 vorgestellten QIP, welcher bei Schlumberger RPS in der Praxis angewendet wird. Da die Beschreibung der einzelnen Aktivit¨ aten in der urspr¨ unglichen Quelle [BC95, S.57f] sehr kurz ausf¨ allt und die QIP Anwendung nicht aus praktischer Sicht beleuchtet wird, werden zus¨ atzlich die praxisnahen Dokumentationen des QIP der Schlumberger RPS [LOHR96, S.169] [LSO ⁺ 98, S.80ff] sowie der Digital Equipment Co. [FLM ⁺ 98, S.413f] herangezogen.

1.Orga. Charakterisieren und verstehen. Im Rahmen des ersten Schritts werden die Modelle f¨ ur das Unternehmen analysiert, um das zu startende Projekt zu charakterisieren. Hier wird festgelegt, welche Modelle f¨ ur das konkrete Projekt gelten. Dies betrifft zum Beispiel Lebenszyklus-, Prozess- oder initiale Qualit¨ atsmodelle. Außerdem werden bestehende Erfahrungen und Daten vergangener Projekte identifiziert, welche f¨ ur die folgenden Schritte relevant sind. Eventuell k¨ onnen Ziele samt Definition, Altdaten f¨ ur ein Benchmarking und Messwerkzeuge aus vergangenen Projekten wiederverwendet werden.

61

4. Stand der Forschung

2.Orga. Ziele definieren. Nach der Charakterisierung werden Ziele definiert, welche den in Schritt 1 festgelegten Modellen entsprechen. Dies bedeutet beispielsweise, dass in einer Organisation, welche ein Wasserfallmodell implementiert hat, keine Ziele bez¨ uglich eines agilen Entwicklungsmodells gelten werden. Damit Ziele einer einheitlichen Struktur unterliegen, sollte bei ihrer Definition ein GQM Template gem¨ aß Abbildung 4.14 verwendet werden. Zudem ist stets im Hinterkopf zu halten, dass das Verfolgen eines Ziels zur Verbesserung des Bestehenden f¨ uhren soll und nicht dem Selbstzweck dient. Der Ergebistyp dieses Schritts ist ein GQM Plan, d.h. ein strukturiertes Dokument mit den f¨ ur das Projekt geltenden Ziele.

3.Orga. Prozesse, Methoden und Tools ausw¨ ahlen. Da Projekte unterschiedlichen Gegebenheiten unterliegen, kann nicht davon ausgegangen werden, dass immer die gleichen Methoden und Tools zum Erreichen der Ziele f¨ uhren. Aus diesem Grund werden im Schritt 3 Prozesse, Methoden und Tools f¨ ur das konkrete Projekt angepasst. Bez¨ uglich GQM wird hier auch das Messprogramm definiert. Das bedeutet zun¨ achst, dass Ziele durch Fragen verfeinert und durch Metriken operationalisiert werden und dies in einem Messplan dokumentiert wird. Der Messplan bildet damit das operationale Gegenst¨ uck zum GQM Plan.

4.Proj. Durchf¨ uhren. Im Projekt werden die angepassten Prozesse, Methoden und Tools schließlich angewendet. Gem¨ aß Abbildung 4.15 werden hier auch die in Schritt 3 zusammengestellten Messprogramme durch das GQM Team durchgef¨ uhrt. Es werden gem¨ aß des GQM- und Messplans Daten gesammelt, Metriken berechnet und validiert.

5.Proj. Ergebnisse analysieren. W¨ ahrend das Projekt l¨ auft, werden sowohl die Anwendung der Prozesse, Methoden und Tools, als auch die Ergebnisse der Messungen, d.h. die ermittelten Daten analysiert. Durch die Analyse soll der Zielerreichungsgrad im Projekt kontinuierlich bestimmt werden, um auf Basis der ermittelten Daten Maßnahmen ableiten zu k¨ onnen. In diesem Zusammenhang stellte sich heraus, dass im Schritt 5 ein Schl¨ ussel f¨ ur den Erfolg des QIP liegt. In regelm¨ aßigen, gut vorbereiteten Feedbackrunden werden alle 6 bis 8 Wochen in Zusammenarbeit zwischen dem GQM Team und dem Projektteam Messergebnisse analysiert und gemeinsam interpretiert. Aus dieser Zusammenarbeit resultieren die Maßnahmen bis zur n¨ achsten Feedbackrunde. Dieses Vorgehen erinnert an agile Methoden.

6.Proj. Prozess mit Feedback unterst¨ utzen. Da w¨ ahrend der Laufzeit immer wieder neue Umst¨ ande auftreten k¨ onnen, m¨ ussen die in Schritt 3 angepassten Prozesse, Methoden und Tools rekalibriert werden. Dies geschieht mit Hilfe des Lernprozesses im Projekt, indem die Erfahrungen der Durchf¨ uhrung und die Ergebnisse der Analyse f¨ ur die Verbesserung der Abl¨ aufe innerhalb des Projekts eingesetzt werden.

62

7.Orga. Ergebnisse analysieren. Wenn das Projekt abgeschlossen ist, wird eine abschließende Analyse angestoßen, um implizite Projekterfahrungen f¨ ur zuk¨ unftige Projekte zur Verf¨ ugung zu stellen. Dabei fließen neben den Ergebnissen aus Schritt 5 auch die Dokumente im Endstand sowie die Projektabschlussdokumentation in die Analyse ein.

8.Orga. Erfahrungen b¨ undeln und ablegen. Besonders in großen Unternehmen mit vielen unterschiedlichen Projekten k¨ onnen Projektabschlussdokumentationen untergehen. Aus diesem Grund ist es besser, sie thematisch und projekt¨ ubergreifend zu Erfahrungspaketen zusammenzufassen und diese Pakete unternehmensweit zur Verf¨ ugung zu stellen. In diesem Schritt werden die w¨ ahrend der Projektlaufzeit gesammelten Daten in eine unternehmensweite GQM Datenbank eingepflegt und KPIs sowie Entwicklungsprozessdefinitionen aktualisiert. Es existiert zwar kein allgemeing¨ ultiger Hinweis, wie diese Erfahrungspakete zu schn¨ uren sind, damit sie in zuk¨ unftigen Projekten wiederverwendet werden k¨ onnen, es gilt jedoch, dass die Wahrscheinlichkeit der Wiederverwendung steigt, wenn Erfahrungen sehr konkret f¨ ur ein abgestecktes Umfeld beschrieben werden.

Wie ist die Experience Factory aufgebaut? Die Experience Factory ist eine Organisation, welche das Wiederverwenden von Erfahrungen und das kollektive Lernen f¨ ordert. Durch die Factory werden Kompetenzcluster in Form von Experience Packages gebildet, welche Projekten kontinuierlich und aktuell zur Verf¨ ugung gestellt werden. Abbildung 4.18 zeigt die Experience Factory.

Basili und Caldiera schreiben in [BC95, S.59], dass die Projektorganisation der Experience Factory Produkte, Pl¨ ane, Prozesse und w¨ ahrend der Entwicklung verwendete Modelle zuf¨ uhrt. Die Factory transformiert diese zu Experience Packages und stellt sie samt ¨ Uberwachungs- und Beratungsdienstleistungen f¨ ur sp¨ atere Projekte bereit. Die Aufgaben von Projekten und der Factory sind dabei streng voneinander zu trennen. Dies wird erreicht, indem die einzelnen Schritte des QIP der jeweiligen Organisation zugeordnet sind.

Im Projekt werden die GQM Anpassungsschritte (Charakterisieren, Ziele definieren, Prozesse w¨ ahlen) durchgef¨ uhrt. Die Ergebnisse, d.h. Projektcharakteristiken, GQM Pl¨ ane und Messpl¨ ane werden der Experience Factory zugef¨ uhrt, welche diese in der Erfahrungsdatenbank ablegt und Experience Packages schn¨ urt. In dem Fall, dass bereits Projekte mit einer ¨ ahnlichen Charakteristik durchgef¨ uhrt wurden, kann die Factory hier beratend t¨ atig werden, indem sie dem aktuellen Projekt f¨ ur die ersten 3 Phasen des QIP Ziele, Prozesse, Tools, Produkte, Ressourcenmodelle und Defektmodelle aus fr¨ uheren, ¨ ahnlichen Projekten vorschl¨ agt. Auch die QIP Aktivit¨ at Durchf¨ uhren ist naturgem¨ aß in der Projektorganisation verankert. Dort werden im Rahmen des Projekts die zuvor

63

4. Stand der Forschung

angepassten Prozesse durchgef¨ uhrt. Lessons Learned und Daten aus Messungen fließen in die Experience Factory.

Die Kompetenzen der Experience Factory liegen klar in der Analyse sowie der B¨ undelung und Ablage von Erfahrungspaketen. Lessons Learned und Daten werden analysiert und in die Erfahrungsdatenbank aufgenommen. Sowohl die aktuellen, als auch die fr¨ uheren Eintr¨ age der Datenbank liefern schließlich die Grundlage f¨ ur das Schn¨ uren der Experience Packages. Damit die dokumentierten Erfahrungen nicht lediglich in der Datenbank existieren, sondern in den Projekten gelebt werden, tritt die Factory wie bereits beschrieben beratend auf. Wenn das Projekt beispielsweise die zweite QIP Phase Ziele definieren durchf¨ uhrt, k¨ onnen die entsprechenden Projektmitarbeiter auf die Factory zugehen, welche schließlich Ziele aus fr¨ uheren, ¨ ahnlichen Projekten aus der Erfahrungsdatenbank bereitstellt.

Wozu? Wo? Wann? Wer? Wie? Oivo und Basili formulieren in ihrem Paper [OB92, S.888] die Anforderungen an einen zielorientierten Ansatz zwar nicht durch die 5 Fragen, sie erkennen jedoch, dass eine Vielzahl von Software Engineering Modellen (SEM) n¨ otig sind, um alle relevanten Aspekte des Software Engineering zu repr¨ asentieren. Die

64

Autoren bestehen auf einer klaren Trennung zwischen SEM und GQM Modellen, damit Wissen besser dargestellt und wiederverwendet werden kann. Es bedarf jedoch einer Kommunikation zwischen der Experience Factory und den Projektorganisationen, um zu bestimmen, wer wann was aus welchem Grund zu tun hat. In Abbildung 4.19 ist die Trennung und der Nachrichtenaustausch dargestellt.

Um zu bestimmen, aus welchem Grund ein Ziel verfolgt werden soll, werden Qualit¨ atsmodelle wie die ISO/IEC 9126 ben¨ otigt. Da Ziele messbar werden, indem Fragen zu bestimmten Teilprodukten anhand von Metriken beantwortet werden, spielen Produktmodelle f¨ ur GQM eine große Rolle. Es gilt, dass Ziele bis zu einem bestimmten Zeitpunkt erreicht werden m¨ ussen. F¨ ur die zeitliche Einordnung werden Projekt- und Prozessmodelle herangezogen. Damit bei der Definition von Zielen klar bestimmt werden kann, wer f¨ ur das Erreichen eines Ziel verantwortlich ist, m¨ ussen die Ressourcen des Unternehmens ber¨ ucksichtigt werden. QS-Maßnahmen treten in Form von Designmethoden auf. Diese Methoden spielen eine Rolle f¨ ur das Erreichen der Ziele.

4.3.2. Explizite Projektpl¨ ane

Lott und Rombach schreiben in [LR93, S.1], dass der erste Schritt f¨ ur ein ingenieurm¨ aßiges Vorgehen darin liegt, Prozesse, Produkte und Qualit¨ at explizit zu modellieren. Das Organisieren dieser Software Engineering Modelle in einer Experience Factory ist zum Ersten die Grundlage f¨ ur die Wiederverwendung in Projekten. Zum Zweiten gewinnt ein Unternehmen durch die Factory die intellektuelle Kontrolle ¨ uber die Evolution ihrer

Projekte. Abbildung 4.20 zeigt eine verbesserungsorientierte Organisationsstruktur.

65

4. Stand der Forschung

Abb. 4.20.: Verbesserungsorientierte Organisationsstruktur [LR93, S.3]

Damit die Modelle in die Projekte getragen werden k¨ onnen, bedarf es expliziter Projektpl¨ ane, in welchen die Modelle f¨ ur das konkrete Projekt angepasst werden. Aus den ersten 3 QIP Schritten Projekt charakterisieren, Ziele definieren und Modelle w¨ ahlen folgt die Notwendigkeit eines Messplans, in welchem die Ergebnisse dieser Schritte dokumentiert werden k¨ onnen. Nach Abschluss der Planungsphase wird das Projekt durchgef¨ uhrt. In diesem Zusammenhang dienen die expliziten Pl¨ ane zur Steuerung und ¨ Uberwachung des

Projekts. Die Zust¨ andigkeiten f¨ ur die Analyse und das B¨ undeln der Erfahrungen liegen in der Experience Factory. Die strenge Trennung des QIP in Projekt- und Experience Factory Aktivit¨ aten findet wie in 4.18 auch hier Anwendung.

W¨ ahrend der Projektdurchf¨ uhrung ist der Projektplan der Tr¨ ager f¨ ur die Wiederverwendung von Erfahrungen. In regelm¨ aßigen Abst¨ anden w¨ ahrend der Durchf¨ uhrung und nach Abschluss des Projekts werden die Erfahrungen durch die Experience Factory dokumen-

66

tiert. Dieser Zyklus f¨ uhrt zu der kontinuierlichen Verbesserung der Software Engineering Modelle.

Bestimmen des technologischen Reifegrads. Die Autoren formulieren in [LR93, S.8ff] vier Stufen, um den Reifegrad im Umgang mit den Projekt- und Messpl¨ anen zu bestimmen. Ausgehend von der Nichtexistenz expliziter Pl¨ ane f¨ uhrt die Steigerung der Reife ¨ uber offline Pl¨ ane in der mittleren Auspr¨ agung hin zu online Pl¨ anen als h¨ ochste Stufe. Offline Pl¨ ane stellen einfache Dokumententemplates dar, welche in Projekten verwendet werden. Online Pl¨ ane sind werkzeugunterst¨ utzt und bieten beispielsweise automatisierte Vorg¨ ange f¨ ur das Erstellen projekt¨ ubergreifender Statistiken oder das Erheben von Daten.

Level 1: Kein expliziter Projekt- oder Messplan. Der unterste Reifegrad ist durch die Abwesenheit von expliziten Pl¨ anen gekennzeichnet. Damit geht einher, dass Qualit¨ atsziele nicht dokumentiert werden und das Schaffen von Qualit¨ at durch implizites Handeln der Mitarbeiter bestimmt wird. Wegen der fehlenden Modelle ist eine Werkzeugunterst¨ utzung nicht m¨ oglich. Besonders in großen Unternehmen mit vielen Projekten fehlen einheitliche Daten, welche ¨ uber eine statistische Auswertung in die Prozessverbesserung einfließen m¨ ussten.

Level 2: Expliziter Projekt- und Messplan. Die n¨ achste Stufe spiegelt die aktuelle Situation in Softwareunternehmen wider. Prozesse sind modelliert, so dass sie in angepasster Form in den Projektplan ¨ ubernommen werden k¨ onnen. Durch die Anwesenheit des Projektplans sind Mitarbeiter zwar sensibilisiert, in welcher Form sie im Prozess mitwirken, die tats¨ achliche Durchf¨ uhrung der Aktivit¨ aten kann jedoch nicht automatisch ausgel¨ ost werden. Kommunikation funktioniert wegen der fehlenden Werkzeugintegration ¨ uber

Zuruf. Ziele sind in einem Messplan explizit definiert. Durch das Verwenden von Messwerkzeugen werden Abweichungen vom Plan durch Projektmitarbeiter beobachtet. Es existiert jedoch keine automatisierte, einheitliche Messung, so dass sowohl Aufbau, als auch Qualit¨ at der Daten stark schwankt. Der projekt¨ ubergreifende Vergleich ist damit erschwert.

Level 3a: Online Projektplan, offline Messplan. In dieser Stufe werden Messungen wie in Level 2 durchgef¨ uhrt, d.h. ohne einheitliche und integrierte Werkzeugunterst¨ utzung. Im Gegensatz dazu existiert eine Umgebung f¨ ur den Projektplan, in welcher das Fortschreiten eines Projekts im Prozess werkzeugm¨ aßig unterst¨ utzt wird. Dadurch kann zumindest eingesehen werden, welchen Status ein Projekt bez¨ uglich des zeitlichen Fortschritts hat. Zwar k¨ onnen Eingangs- und Ausgangskriterien in solchen Werkzeugen h¨ aufig durch die Mitarbeiter dokumentiert werden, die quantitative Bewertung durch integrierte Messungen fehlt jedoch. Die Vorteile gegen¨ uber Level 2 sind, dass einige Aktionen aufgedeckt

67

4. Stand der Forschung

werden, welche zu Konflikten f¨ uhren, Abweichungen vom Plan berichtet werden und Maßnahmen zur Steuerung des Projekts abgeleitet werden k¨ onnen.

Level 3b: Offline Projektplan, online Messplan. In dieser Stufe geschieht der Umgang mit dem Projektplan wie in Level 2, d.h. ohne einheitliche und integrierte Werkzeugunterst¨ utzung. Daf¨ ur existiert eine Messumgebung, mit welcher Routinen zur kontinuierlichen Messdatenerhebung automatisiert durchgef¨ uhrt werden k¨ onnen. In dieser Automatisierbarkeit immer wiederkehrender Aktivit¨ aten liegt der Hauptvorteil dieses Levels, da dadurch mittelfristig die Datenqualit¨ at und damit die Datenzuverl¨ assigkeit steigt.

Level 4: Online Projektplan, online Messplan. Die letzte Stufe ist charakterisiert durch ein System, in welchem quantitative Kriterien in einem expliziten Projektplan integriert sind. Die Umgebung bietet Zugriff auf die unterschiedlichen Software Engineering Tools. Damit geht ein Paradigmenwechsel einher: weg von dem individuellen Einsatz unterschiedlichster Tools in den Projekten, hin zu einer Umgebung mit einer integrierten Werkzeugkette, welche durch die Prozesse f¨ uhrt. Automatisiert gesammelte Daten werden an entsprechender Stelle im Projektplan hinterlegt, um Entscheidungen im Projekt besser mit Fakten hinterlegen zu k¨ onnen. Abweichungen vom Projektplan und den Zielen des Messplans werden kontinuierlich aktualisiert und zum Beispiel in Form eines Dashboards zur Verf¨ ugung gestellt.

4.4. Zusammenfassung

In diesem Kapitel wurden unterschiedliche Ans¨ atze vorgestellt, welche Modell und Methode bereitstellen, um das Thema Softwarequalit¨ at strukturiert und systematisch zu behandeln. Es stellte sich jedoch heraus, dass keiner der Ans¨ atze die in der Einleitung gestellte Frage vollst¨ andig beantworten kann. Es stellte sich aber auch heraus, dass der GQM Ansatz der Beantwortung bereits sehr nahe kommt. Keiner der Ans¨ atze behandelt jedoch konstruktive und analytische QS-Maßnahmen explizit. Wegen der Eignung des GQM Ansatzes wurde gezeigt, welche Strategien zur Implementierung von GQM in die Unternehmensabl¨ aufe existieren und wie der Reifegrad des GQM Einsatzes bestimmt werden kann. Auch die anderen Ans¨ atze verf¨ ugen ¨ uber Vorteile, welche im folgenden

Hauptkapitel als Anforderungen in das Formulieren der Methode f¨ ur Softwarequalit¨ at mit multidimensionalen Qualit¨ atszielen und integrierten QS-Maßnahmen einfließen.

68

Kapitel 5

Multidimensionale Qualit¨ atsziele und

integrierte QS-Maßnahmen

Dieses Kapitel stellt das Hauptkapitel dar. Es ist wie Kapitel 4 aufgebaut, in welchem der aktuelle Stand der Forschung behandelt wurde.

In Abschnitt 5.1 wird das Modellsystem der multidimensionalen Qualit¨ atsziele und der integrierten QS-Maßnahmen vorgestellt. Dieses Modellsystem wird im Folgenden als multidimensionaler Zielraum bezeichnet. Zudem wird auf die Methode eingegangen, wie Software Engineering Modelle auf die Dimensionen des Zielraums gelegt, Ziele formuliert und QS-Maßnahmen abgeleitet werden. Abschnitt 5.1 ist wie Abschnitt 4.1 aufgebaut. Es wird zuerst beschrieben, welche Probleme in bestehenden Ans¨ atzen existieren und wie diese gel¨ ost werden k¨ onnen. Im Anschluss werden schließlich Modell und Methode - d.h. Struktur und Systematik - vorgestellt. Schließlich wird gezeigt, wie die Fragen Wozu? Wo? Wann? Wer? Wie?“ durch den multidimensionalen Zielraum beantwortet

”

werden.

Abschnitt 5.2 behandelt die organisatorische Einbettung der multidimensionalen Ziele und integrierten QS-Maßnahmen. Es wird darauf eingegangen, wie unternehmensweites Lernen und Wiederverwenden von Zielen und QS-Maßnahmen gef¨ ordert wird. Außerdem ergibt sich anhand statistischer Mittel die M¨ oglichkeit, eine Vielzahl von Projektorganisationen in großen Unternehmen durch Qualit¨ atsziele zu steuern.

Im Kapitel 4 wurde bereits gezeigt, dass unter den vorgestellten Ans¨ atzen der GQM Ansatz die besten Voraussetzungen zur Beantwortung der Fragen ” Wozu? Wo? Wann?

69

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

Wer? Wie?“ mitbringt. Diese f¨ unf Einzelfragen entspringen der Hauptfrage, deren Be-antwortung das Thema dieser Diplomarbeit ist: Welche Qualit¨ atsmerkmale m¨ ussen in einem bestimmten Ergebnistyp wann f¨ ur wen ber¨ ucksichtigt werden und welche wirksamen Qualit¨ atssicherungsmaßnahmen existieren diesbez¨ uglich?

5.1. Anpassen der Modelle des Zielraums

5.1.1. Welche Probleme existieren im GQM Ansatz?

Klare Abgrenzung der Zieldimensionen. Als Erstes f¨ allt auf, dass in den Publikationen rund um den GQM Ansatz nicht von Zieldimensionen gesprochen wird. Das GQM Template aus Abbildung 4.14 zeigt, dass jedes Ziel eine Absicht (Purpose), ein Problem (Issue), ein Objekt (Produkte, Prozesse, Ressourcen) und eine Perspektive (Viewpoint) adressiert. Jede dieser vier Eigenschaften kann als eine Zieldimension betrachtet werden, wobei hieran ersichtlicht wird, dass diese Dimensionen bez¨ uglich der Fragen ” Wozu?

Wo? Wann? Wer? Wie?“ nicht klar voneinander abgegrenzt sind. Die Objektdimension beinhaltet in Abbildung 4.14 die Elemente Prozess, Produkt, Modell, Metrik, Test und Review. Gem¨ aß Kapitel 3 werden Prozesse und Ergebnistypen (Produkte) durch Software Engineering Modelle beschrieben. Metriken werden ben¨ otigt, um in analytischen QS-Maßnahmen Aussagen bez¨ uglich eines Objekts treffen zu k¨ onnen. Auch bei Tests und Reviews handelt es sich um QS-Maßnahmen.

Wiederverwenden spezialisierter Qualit¨ atsmodelle. Die Problemdimension eines GQM Ziels gem¨ aß Abbildung 4.14 beschr¨ ankt sich nicht ausschließlich auf das Repr¨ asentieren von Qualit¨ atsmodellen. Dort treten neben Qualit¨ atsmerkmalen der ISO/IEC 9126 auch Defektmodelle und Produktmetriken auf. Aus der fehlenden, klaren Dimensionsabgrenzung folgt, dass spezialisierte Qualit¨ atsmodelle wie das QUIM aus Abschnitt 4.1.3 oder individuelle Qualit¨ atsmodelle nicht ohne Weiteres auf eine Qualit¨ atsdimension gelegt werden k¨ onnen.

Zusammenhang zwischen Ergebnistyp und Prozess. Ergebnistypmodelle, Prozessmodelle und Ressourcenmodelle fassen in einem GQM Ziel eine Dimension zusammen. Dies f¨ uhrt dazu, dass ein Ziel entweder f¨ ur Ergebnistypen, Prozesse oder Ressourcen gilt. Der Zusammenhang, dass Ergebnistypen aus Prozessen resultieren, an welchem wiederum Rollen beteiligt sind, kann mit einem Qualit¨ atsziel gem¨ aß GQM Template nicht modelliert werden.

70

Zusammenhang zwischen Software Engineering Modellen und Zielen. Abbildung 4.19 zeigt, dass Software Engineering Modelle unter der vollen Verantwortung der Experience Factory liegen und diese durch einen informellen Nachrichtenaustausch von der Factory in die Projekte getragen werden soll. Sowohl das GQM Zielmodell, als auch die Anpassungsmethode sehen jedoch keine direkte Verkn¨ upfung der Software Engineering Modelle mit den Zieldimensionen vor. Daraus folgt, dass der Zusammenhang zwischen den Modellen und den Zielen in GQM nicht explizit enthalten ist, sondern immer von der Kommunaktionsf¨ ahigkeit der Experience Factory abh¨ angt.

Zusammenhang zwischen Zielen und QS-Maßnahmen. Der GQM Ansatz beschreibt ein Vorgehen zur zielorientierten Messung. Messungen werden durchgef¨ uhrt, um Aussagen zum Zustand eines Qualit¨ atsmerkmals im gemessenen Objekt treffen und somit den Erreichungsgrad eines Qualit¨ atsziels bestimmen zu k¨ onnen. Dies ist die Definition des Begriffs analytische QS-Maßnahme. Damit ein Ziel erreicht wird, m¨ ussen aber vor allem konstruktive QS-Maßnahmen durchgef¨ uhrt werden. Dieser erweiterte Zusammenhang zwischen konstruktiven QS-Maßnahmen f¨ ur die Zielerreichung und analytischen QS-Maßnahmen f¨ ur die Messung des Zielerreichungsgrades ist in GQM nicht darstellbar.

Einbeziehung des Topmanagements. Das Konzept der Experience Factory behandelt die Anwendung des GQM Ansatzes in Projektorganisationen. Unterschiedliche Organisationen innerhalb eines Unternehmens lohnen sich jedoch erst ab einer bestimmten Gr¨ oße des Unternehmens. Da mit der Gr¨ oße des Unternehmens auch die Anzahl der Hierarchien steigt, m¨ ussen ab einer bestimmten Hierarchieebene strategische Entscheidungen getroffen werden, welche die Ausrichtung des gesamten Unternehmens definieren. Diese strategischen Ziele - im Folgenden auch CIO Ziele - stehen demnach ¨ uber den GQM Zielen der Projekte. Beispielsweise kann ein CIO definieren, dass die Betriebskosten aller eingesetzten Systeme innerhalb der n¨ achsten 5 Jahre um 15% sinken muss. Die Heraus-forderung liegt darin, alle neuen Projekte und ¨ Anderungsw¨ unsche bestehender Systeme

an diesem CIO Ziel auszurichten. Im gesamten Software Engineering Laboratory, welches die Konzepte GQM, QIP und Experience Factory einschließt, wird die Abbildung von Qualit¨ atszielen auf CIO Ziele nicht behandelt.

5.1.2. Wie werden die Probleme gel¨ ost?

Klare Abgrenzung der Zieldimensionen. Abbildung 5.1 zeigt die klare Abgrenzung der Zieldimensionen. In diesem Zusammenhang wurden die GQM Dimensionen neu geordnet und eindeutig voneinander abgegrenzt. Die Rollendimension wird hierbei ¨ ubernommen,

71

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

da diese bereits klar abgegrenzt ist und die Frage ” F¨ ur wen?“ beantworten kann. Die Pro-

blemdimension des GQM Ziels wird zu der Qualit¨ atsdimension, um die Frage ” Wozu?“ zu

beantworten. Im Gegensatz zu einem GQM Ziel beschr¨ ankt sich die Qualit¨ atsdimension eines multidimensionalen Ziels auf die Abbildung von Qualit¨ atsmodellen. Weiterhin wird die GQM Objektdimension (Produkte, Prozesse, Ressourcen) geteilt. Ergebnistypen und Prozesse bilden im multidimensionalen Zielraum jeweils eine eigene Dimension, um die Fragen ” Wo?“ und ” Wann?“ zu kl¨ aren. Da im softwareproduzierenden Prozessen der Mensch die wesentliche Ressource darstellt, existiert im multidimensionalen Zielraum keine explizite Dimension f¨ ur Ressourcen. Die Rollendimension kann hierbei als Rollen-und Ressourcendimension aufgefasst werden. Die GQM Absichtsdimension wird nicht ubernommen, da diese aus dem ” Wozu?“, d.h. dem Erreichen eines Merkmals der Qua¨

lit¨ atsdimension resultiert.

Wiederverwenden spezialisierter Qualit¨ atsmodelle. Spezialisierte Qualit¨ atsmodelle k¨ onnen einfach auf die Qualit¨ atsdimension gelegt werden. Hier ist anzumerken, dass wegen der klaren dimensionalen Abgrenzung auch bestehende Erbegnistyp-, Prozess- und Rollenmodelle einfach auf die entsprechende Dimension abgebildet werden k¨ onnen.

Zusammenhang zwischen Ergebnistyp und Prozess. Da jedes multidimensionale Qualit¨ atsziel die Fragen ” Wozu? Wo? Wann? Wer?“ beantwortet und die Fragen durch

Qualit¨ ats-, Erbegnistyp-, Prozess- und Rollenmodelle repr¨ asentiert werden, wird der Zusammenhang zwischen allen Dimensionen explizit in jedem Ziel modelliert. Dies hat zur Folge, dass keine puren Ergebnistyp-, Prozess- oder Ressourcenziele wie bei einem GQM Ziel exisiteren. Gem¨ aß der Aussage Basilis [BZP ⁺ 94, S.9], dass Prozessverbesserung ihren Sinn in der Verbesserung der aus Prozessen resultierenden Ergebnistypen hat, existieren keine multidimensionalen Qualit¨ atsziele mit purem Fokus auf Ergebnistypen, Prozesse oder Ressourcen.

72

Zusammenhang zwischen Software Engineering Modellen und Zielen. Bei der Initialisierung eines Projekts werden Prozesse angepasst, um zu definieren, wie das Projekt ablaufen soll. Aus der Anpassung der Prozesse folgen die Rollen innerhalb des Projekts. Desweiteren werden die Ergebnistypen festgelegt, welche ¨ uber die Projektlaufzeit

geliefert werden m¨ ussen. Schließlich existieren in Unternehmen h¨ aufig individuelle Qualit¨ atsmodelle [WLW ⁺ 10, S.6], welche in den Projekten Anwendung finden. Nachdem alle Modelle f¨ ur ein Projekt in dessen Initialisierungsphase festgelegt wurden, werden diese auf die Dimensionen des multidimensionalen Zielraums gelegt. Durch das Ableiten von Qualit¨ atszielen aus diesem Zielraum ist der direkte Zusammenhang zwischen Modellen und Zielen hergestellt. Dies wird auch in Abbildung 5.1 deutlich.

Zusammenhang zwischen Zielen und QS-Maßnahmen. Ziele werden definiert, indem je-

de der Fragen ”

eine zusammengesetzte Frage. QS-Maßnahmen definieren das ” der Fragen ”

nem bestimmten Zweck f¨ ur die Verbesserung eines konkreten Ergebnistyps durchgef¨ uhrt werden. Dies spiegelt die Fragen ” Wozu?“ und ” Wo?“ wider. Desweiteren gilt, dass eine QS-Maßnahme zu einem bestimmten Zeitpunkt durchgef¨ uhrt werden muss, um eine Wirkung herbeizuf¨ uhren. Wie Ziele sind auch QS-Maßnahmen an eine Rolle gebunden. Multidimensionale Qualit¨ atsziele und QS-Maßnahmen bilden demnach in denselben multidimensionalen Zielraum ab. Aus diesem Grund sind QS-Maßnahmen integriert und lassen sich systematisch f¨ ur eine Auswahl an Zielen ableiten. Hierbei wird explizit zwischen konstruktiven und analytischen Maßnahmen unterschieden. Konstruktive Maßnahmen dienen dem Erreichen eines Ziels, so dass Qualit¨ at in ein Objekt hineinentwickelt wird. Analytische Maßnahmen dienen wie in GQM der Messung des Zielerreichungsgrads.

Einbeziehung des Topmanagements. Das Topmanagement ist f¨ ur die Definition strategischer CIO Ziele verantwortlich (management by objectives). Da es in großen Unternehmen zu einer Vielzahl von Projekten kommen kann, liegt die Holschuld bez¨ uglich der CIO Ziele bei den Mitarbeitern der Projektorganisationen. Dies geschieht, indem Qualit¨ atsziele im Qualit¨ atsplan eines Projekts mit den CIO Zielen in Beziehung gesetzt werden. Dies erh¨ oht die Transparenz des allt¨ aglichen Projektgesch¨ afts, da QS-Maßnahmen durchgef¨ uhrt werden, um Qualit¨ atsziele zu erreichen und Qualit¨ atsziele mit CIO Zielen verkn¨ upft sind. Die Holschuld des Topmanagements liegt wiederum darin, sich regelm¨ aßig ¨ uber den Status der CIO Ziele berichten zu lassen. Dies geschieht anhand der statistischen Auswertung der Qualit¨ atspl¨ ane abgeschlossener Projekte. Hierbei entstehen zwei KPI Gruppen - Ziel KPIs und QS-Maßnahmen KPIs.

73

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

5.1.3. Wie sieht das zugrunde liegende Modellsystem aus?

Multidimensionale Qualit¨ atsziele

Multidimensionale Qualit¨ atsziele bilden in einen Zielraum ab, welcher durch Software Engineering Modelle aufgespannt wird. Qualit¨ atsmodelle, Ergebnistypmodelle, Prozessmodelle und Rollenmodelle definieren dabei jeweils eine Dimension, wobei sich jede Dimension baumartig verfeinern l¨ asst.

Abbildung 5.2 zeigt einen Qualit¨ atsplan f¨ ur ein Projekt und die Abbildung eines Qualit¨ atsziels in den multidimensionalen Zielraum schematisch. Das dargestellte Ziel beschreibt die Wichtigkeit der funktionalen Vollst¨ andigkeit innerhalb des Pflichtenhefts f¨ ur den Fachbereich, welcher das System sp¨ ater benutzen muss. Das Ziel muss hierbei in fr¨ uhen Phasen des Softwareentwicklungsprozesses erreicht werden, da sp¨ ate ¨ Anderungen

an der Spezifikation ein hohes Risiko f¨ ur den Projekterfolg darstellen.

Jede dimensionale Abbildung eines Qualit¨ atsziels bildet auf genau ein Modellelement der entsprechenden Dimension ab. Der Vorteil gegen¨ uber der mehrfachen Abbildung in eine Dimension ist, dass anstatt weniger allgemeiner Ziele viele konkrete Ziele formuliert werden.

Wozu? Die Abbildung in die Qualit¨ atsdimension resultiert in der konkreten Qualit¨ atscharakteristik bzw. -subcharakteristik, welche f¨ ur das Ziel erreicht werden soll. Um die Wiederverwendbarkeit von Qualit¨ atsmodellen zu verbessern, empfiehlt es sich, auf die Qualit¨ atsdimension FC-Modelle zu legen. Ein FC-Modell ist beispielsweise die ISO/IEC 9126, da sie Faktoren (F) und Kriterien (C) definiert und nicht bis zur Metrikebene (M) verfeinert. Analytische QS-Maßnahmen dienen definitionsgem¨ aß zum Bestimmen der Qualit¨ at eines Pr¨ uflings. Daher werden Metriken nicht anhand der multidimensionalen Qualit¨ atsziele, sondern durch die integrierten analytischen QS-Maßnahmen definiert. Auf QS-Maßnahmen wird genauer im folgenden Abschnitt eingegangen.

Wo? Die Abbildung in die Ergebnistypdimension definiert das Artefakt, in welchem das Qualit¨ atsmerkmal erreicht werden soll. In der Initialisierungsphase eines Projekts werden die zu liefernden Ergebnisse definiert und ihre Modelle auf die Ergebnistypdimension des multidimensionalen Zielraums gelegt. In Unternehmen existieren dabei h¨ aufig Templates, welche die Struktur des jeweiligen Liefergegenstandes vorgeben. Am Beispiel des Anwendungsfallmodells eines Pflichtenhefts gem¨ aß Abschnitt 3.2.1 wird deutlich, dass das Pflichtenheft ¨ uber Anwendungsf¨ alle bis hin zu Vorbedingungen, Szenarien und Nachbedingungen verfeinert wird. Je nach Granularit¨ at des Qualit¨ atsziels kann es somit auf das Pflichtenheft, die in ihm beschriebenen Anwendungsf¨ alle oder die Szenarien eines Anwendungsfalls abgebildet werden.

Wann? Die Abbildung in die Prozessdimension bestimmt den Zeitpunkt im Prozess, in welchem der Ergebnistyp produziert wird und somit Einfluss auf dessen Qualit¨ at genommen werden kann. Da ein Softwareprodukt nicht von heute auf morgen entsteht, durchl¨ auft es einen Lebenszyklus von der Anforderungsanalyse ¨ uber Design und Im-

plementierung bis hin zum Systembetrieb und schließlich der Systemabschaltung. Die einzelnen Ergebnistypen werden dabei zu unterschiedlichen Zeiten im Prozess bearbeitet. Aus diesem Grund muss auch ein Qualit¨ atsziel f¨ ur den entsprechenden Ergebnistyp in dieser Phase erreicht werden.

F¨ ur wen? Die Abbildung in den multidimensionalen Zielraum wird vervollst¨ andigt, indem f¨ ur jedes Ziel bestimmt wird, wer den Hauptnutzen an seiner Erreichung hat. Dies geschieht anhand des Rollenmodells. Damit wird durch das Formulieren von Zielen definiert, f¨ ur wen ein Qualit¨ atsmerkmal eines Ergebnistyps wichtig ist und wann Qualit¨ at in den Ergebnistyp hineinentwickelt werden muss.

75

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

Abbildung 5.3 zeigt das konzeptionelle Datenmodell f¨ ur den multidimensionalen Zielraum - zun¨ achst ohne QS-Maßnahmen. Die Datenmodelle mit konstruktiven und analytischen QS-Maßnahmen sind in den Abbildungen 5.5 und 5.6 dargestellt. Die Datenmodelle sind die Grundlage f¨ ur die Werkzeugunterst¨ utzung. Screenshots und Beschreibung der prototypischen Implementierung befinden sich in Kapitel 7.

Der obere Teil des Datenmodells stellt den Qualit¨ atsplan dar. Hierf¨ ur werden Tabellen f¨ ur Projekte, CIO Ziele, Priorisierungslevel und Qualit¨ atsziele ben¨ otigt. Alle Ziele werden zwar in einer einzigen Tabelle gespeichert, der Qualit¨ atsplan ergibt sich jedoch aus dem Zuweisen eines Projekts f¨ ur jedes Ziel. F¨ ur jedes Ziel kann auch angegeben werden, welches CIO Ziel es adressiert. Neben der Zuweisung von Projekt und CIO Ziel ist auch die Priorisierung f¨ ur jedes Qualit¨ atsziel verpflichtend. F¨ ur den Fall, dass ein multidimensionales Qualit¨ atsziel kein CIO Ziel adressiert, existiert das CIO Ziel none.

76

Im unteren Teil des Datenmodells ist der multidimensionale Zielraum dargestellt, wobei jede der dargestellten Zieldimensionen baumartig verfeinert werden kann. Hierbei entsteht die Aggregierbarkeit ¨ uber die Hierarchien innerhalb der Software Engineering

Modelle. Da in jeder Dimension mehrere Modelle abgelegt werden k¨ onnen, wird das Wurzelelement eines Modells gesondert markiert. Die Zieltabelle definiert im Sinne des Star Schemas aus dem Data Warehousing Bereich eine Faktentabelle, in welcher die Abbildung in den multidimensionalen Zielraum f¨ ur jedes Ziel abgelegt wird.

Integrierte QS-Maßnahmen

QS-Maßnahmen sind integriert, weil sie in denselben multidimensionalen Zielraum abbilden, wie Qualit¨ atsziele. Auch f¨ ur eine QS-Maßnahme gilt, dass spezifiziert wird, wozu wo wann durch wen etwas zu tun ist. Zus¨ atzlich wird in einer QS-Maßnahme definiert, welche konkreten Schritte durchzuf¨ uhren sind - dies spiegelt das ” Wie?“ wider. Eine

QS-Maßnahme ist damit das operative Gegenst¨ uck zu einem Qualit¨ atsziel.

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

Abbildung 5.5 zeigt das konzeptionelle Datenmodell f¨ ur konstruktive QS-Maßnahmen. Im Datenmodell werden QS-Maßnahmen bewusst nicht als Quality Assurance Measures ¨ ubersetzt, da beim deutschen Leser der Eindruck entstehen k¨ onnte, dass es sich ausschließlich um analytische Maßnahmen, d.h. das Nehmen eines Maßes, handelt. Aus diesem Grund bezeichnen Quality Assurance Activities (cQAA und aQAA) im konzeptionellen Datenmodell konstruktive und analytische QS-Maßnahmen.

Der Aufbau konstruktiver QS-Maßnahmen (kQSM) ist im unteren Teil des Datenmodells dargestellt. Eine kQSM ist Teil des QSM Katalogs, in welchem Wissen und Erfahrungen aus vergangengen Projekten unternehmensweit abgelegt werden. Jede kQSM besteht aus Schritten, welche im Rahmen der QSM Durchf¨ uhrung abgearbeitet werden.

Ein Beispiel f¨ ur eine kQSM ist die Einf¨ uhrung des Dokumentationsfreitags. (1) Der Freitag startet mit einer Besprechung, in welcher zun¨ achst bestimmt wird, in welchen Teilen des Systems die Dokumentation vervollst¨ andigt werden muss. (2) Im Anschluss daran wird festgelegt, welche Entwickler an welchen Komponenten arbeiten. Hierbei sollte Wert darauf gelegt werden, dass Entwicklung und nachtr¨ agliche Dokumentation nicht durch denselben Mitarbeiter durchgef¨ uhrt werden. (3) Jeder Entwickler hat nun 3 Stunden Zeit, um den ihm zugewiesenen Quelltext zu dokumentieren. (4) Falls Unstimmigkeiten im Quelltext durch diese Art von Review entdeckt werden, werden sie lediglich in der Fehlerdatenbank gespeichert. Der Fokus des Dokumentationsfreitags liegt eindeutig in der Dokumentation.

Jede QS-Maßnahme bildet in den multidimensionalen Zielraum ab. Anders als bei Zielen k¨ onnen sie jedoch mehrfach in die einzelnen Dimensionen abbilden. Am Beispiel der Einf¨ uhrung des Dokumentationsfreitags wird dies deutlich, da die kQSM mehrere Qualit¨ atsmerkmale der Qualit¨ atsdimension beeinflusst. Da der Quelltext f¨ ur zuk¨ unftige Entwickler und externe Tester verst¨ andlicher wird, verbessert sich die Analysierbarkeit, die Modifizierbarkeit und die Testbarkeit. Die kQSM wird im Ergebnistyp Quelltext in der Prozessphase Realisierung von der Rolle Entwickler durchgef¨ uhrt. Damit ist die Abbildung in den Zielraum vollst¨ andig.

Wenn eine QS-Maßnahme des QSM Katalogs im konkreten Projekt f¨ ur das Erreichen eines Ziels durchgef¨ uhrt wird, wird dies im Qualit¨ atsplan dokumentiert. Der obere Teil des Datenmodells zeigt diesbez¨ uglich die Erweiterung des Qualit¨ atplans aus Abbildung 5.3. Im Datenmodell k¨ onnen dokumentierte kQSM mit mehreren Zielen verkn¨ upft werden, falls sie dem Erreichen mehrerer Ziele dienen. F¨ ur jede durchgef¨ uhrte kQSM werden schließlich Start- und Enddatum, gesch¨ atzte und tats¨ achliche Kosten, die Nutzenbewertung und Freitextanmerkungen dokumentiert.

78

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

Abbildung 5.6 zeigt das konzeptionelle Datenmodell f¨ ur analytische QS-Maßnahmen.

Wie kQSM bilden auch analytische QS-Maßnahmen (aQSM) mehrfach auf die einzelnen Dimensionen des Zielraums ab. Da aQSM nicht lediglich aus Durchf¨ uhrungsschritten aufgebaut sind, sondern durch sie ein Messprogramm definiert wird, ist ihr Aufbau wesentlich komplizierter. Analytische QS-Maßnahmen orientieren sich am GQM Ansatz, wobei Fragen und Metriken an die QS-Maßnahme gebunden und somit scharf vom Zielbegriff abgegrenzt werden. Hierbei ergibt sich der Vorteil, dass Ziele zun¨ achst intuitiv definiert werden k¨ onnen ohne R¨ ucksicht auf die Messung nehmen zu m¨ ussen. Die passenden aQSM zur Messung des Erreichungsgrads eines Ziels werden aus dem QSM Katalog ausgew¨ ahlt. Der untere Teil des Datenmodells zeigt wieder den QSM Katalog, welcher neben kQSM auch aQSM enth¨ alt. Jede aQSM ist aus Fragen aufgebaut, welche die Messung motivieren. Die Metriken wiederum dienen zur Beantwortung der Fragen.

Das analytische Pendant zur kQSM Einf¨ uhrung des Dokumentationsfreitags ist das Messen des Erfolgs der Freitagsdokumentation. Hierbei stellen sich die Fragen:

1. Wie entwickelt sich der Dokumentationsgrad insgesamt?

2. Wie entwickelt sich die Anzahl der Entwickler pro Dokumentationsfreitag?

3. Wie viele Dokumentationszeilen schafft ein Entwickler durchschnittlich?

4. Wie gut dient der Dokumentationsfreitag als Reviewtechnik?

Jede Frage wird durch Metriken operationalisiert. Die Daten f¨ ur jede Metrik entstammen aus der Messung eines Ergebnistyps. Diese Messung geschieht durch Sensoren. Metriken werden wie folgt beschrieben: Metrikname[Ergebnistyp|Sensor]. Metriken k¨ onnen durch mathematische Operatoren auch zusammengesetzt werden. Die folgende Aufz¨ ahlung enth¨ alt die Metriken f¨ ur die oben genannten Fragen der aQSM:

1. ΔDokuZeilen[System|JavaNCSS] bzw. ΔDokuZeilen[Komponente|JavaNCSS]

2. DokuTeamgr¨ oße[Projektplan|Manuell]

3. ΔDokuZeilen[System|JavaNCSS] ÷ DokuTeamgr¨ oße[Projektplan|Manuell]

4. NeueTickets[Ticketing Tool|Manuell]

Die Durchf¨ uhrung von aQSM wird wie f¨ ur kQSM im Qualit¨ atsplan dokumentiert. Auch hier werden Start- und Enddatum, die gesch¨ atzten und tats¨ achlich eingetretenen Kosten, die Bewertung des Nutzens sowie Anmerkungen und Verbesserungsvorschl¨ age notiert.

80

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

Da der Fokus dieser Arbeit nicht auf den Themengebieten Kosten und Nutzen von Softwarequalit¨ at und Messen von Softwarequalit¨ at liegt, existiert die Dokumentation des Nutzens von QS-Maßnahmen im konzeptionellen Datenmodell zun¨ achst nur in der sehr einfachen Form einer Gleitkommazahl (benefit rank DOUBLE in c und a documqaa).

Da das Gebiet Messen von Softwarequalit¨ at eine bedeutende Rolle spielt, wird an dieser Stelle trotzdem kurz darauf eingegangen, wie das Messen im Modell integriert wird. Abbildung 5.7 zeigt ein Star Schema mit einer Faktentabelle, in welcher die Metrikwerte abgelegt werden. Zu jedem Metrikwert wird gespeichert, aus welcher Metrik er resultiert und welcher Sensor genutzt wurde, um die Metrik zu erheben. Zus¨ atzlich wird im Datenmodell f¨ ur jeden Wert die Verbindung zur entsprechenden dokumentierten aQSM hergestellt. Damit kann eingeordnet werden, in welchem Projekt an welchem Tag im Rahmen welcher dokumentierten aQSM die Messung stattgefunden hat. Nicht zuletzt bildet jeder Metrikwert in die Ergebnistypdimension des multidimensionalen Zielraums ab, um festzuhalten, in welchem Artefakt die Messung durchgef¨ uhrt wurde. Das Datenmodell aus Abbildung 5.7 zeigt lediglich einfache, d.h. nicht zusammengesetzte Metriken. F¨ ur zusammengesetzte Metriken wird eine Datenbanktabelle zwischen der Metrikwerttabelle und der Metriktabelle eingef¨ ugt, welche die Kompositionsstruktur der Metriken speichert. Abbildung 5.7 zeigt auch nicht die Schwellwerte, welche individuell f¨ ur jedes Projekt und jede Metrik definiert werden m¨ ussen.

82

5.1.4. Wie funktioniert der Anpassungsprozess?

Der in Abbildung 5.8 dargestellte Anpassungsprozess beschreibt den Umgang mit den Qualit¨ atszielen und QS-Maßnahmen. Alle Ergebnisse des Prozesses, d.h. sowohl zu erreichende Qualit¨ atsziele, als auch durchzuf¨ uhrende QS-Maßnahmen, werden im Qualit¨ atsplan (QP) dokumentiert. Der QS-Maßnahmen Katalog (QSM Katalog) enth¨ alt dokumentierte QS-Maßnahmen fr¨ uherer Projekte.

Nachdem das Projekt initialisiert und dessen Aufbau und Ablauf definiert wurde, werden die Dimensionen des Zielraums mit den gew¨ ahlten Modellen im QP eingerichtet (QP.1). Anhand der Dimensionen k¨ onnen Qualit¨ atsziele im QP in Workshops systematisch definiert und strukturiert abgelegt werden (QP.2). Nachdem ein Qualit¨ atsziel bestimmt wurde, wird es mit einem CIO Ziel in Beziehung gesetzt und priorisiert (QP.3). F¨ ur die

83

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

Erreichung des Ziels werden schließlich QS-Maßnahmen aus dem QSM Katalog gew¨ ahlt oder neue QS-Maßnahmen definiert, falls im Katalog noch keine passenden Maßnahmen existieren (QP.4). Dieser Zyklus wird wiederholt, bis Endekriterien f¨ ur das Definieren von Zielen erreicht sind.

Ein externer Ausl¨ oser f¨ uhrt dazu, dass der QP aktualisiert wird. Dies ist entweder das erneute Durchlaufen des Zieldefinitionskreislaufes (QP.2) oder die Dokumentation einer Maßnahmendurchf¨ uhrung (QP.5). Wenn das Projekt abgeschlossen wurde, wird auch der QP offiziell geschlossen (QP.6). Geschlossene QPs fließen in regelm¨ aßigen Abst¨ anden in den kontinuierlichen Verbesserungsprozess (KVP) aus Abbildung 5.13 ein.

Im Folgenden wird genauer auf die einzelnen Schritte des Prozesses eingegangen.

QP.1 Qualit¨ atsplan einrichten. Obwohl der QP w¨ ahrend des KVP kontinuierlich an das Umfeld in dem Unternehmen angepasst wird, kann im konkreten Projekt immer die Notwendigkeit zur individuellen Anpassung der Modelle auftreten.

Qualit¨ atsmodelle werden jedoch im multidimensionalen Zielraum nicht bis zur Messbarkeit verfeinert, da Messungen im Rahmen analytischer QS-Maßnahmen durchgef¨ uhrt werden. Metriken liegen somit nicht im Fokus des sp¨ ateren Ableitens der Ziele. Diese Trennung hat den Vorteil, dass Qualit¨ atsmodelle in FC Form - dies entspricht gem¨ aß FCM Faktoren und Kritierien, nicht jedoch Metriken - wesentlich wiederverwendbarer sind. Die bessere Wiederverwendbarkeit liegt begr¨ undet in der Tatsache, dass die Wahrscheinlichkeit von Modellanpassungen im Projekt sinkt, je abstrakter die Ebene ist, auf der Qualit¨ atsmodelle beschrieben sind.

Auch f¨ ur Prozess-, Ergebnistyp- und Rollenmodelle gilt, dass sie nicht bis in das letzte Detail auf die entsprechende Zieldimension gelegt werden m¨ ussen. Als Repr¨ asentanten f¨ ur einen Prozess k¨ onnen beispielsweise die Phasen des Wasserfallmodells oder Quality Gates verwendet werden. Die Liefergegenst¨ ande eines Projekts werden bereits in fr¨ uhen Phasen festgelegt und zum Beispiel in der Projektbeschreibung oder dem Lastenheft aufgez¨ ahlt. Diese Liefergegenst¨ ande bilden die Ergebnistypdimension.

Bei Bedarf k¨ onnen alle Modelle wegen der baumartigen Struktur der Zieldimensionen beliebig verfeinert werden. Zum Beispiel kann der Ergebnistyp Quelltext in der Ergebnistypdimension bis zur Klassenebene verfeinert werden, wenn sich Qualit¨ atsziele nicht allgemein auf den Quelltext abbilden lassen, sondern konkret f¨ ur Eigenschaften von Klassen gelten. Analog gilt dies auch f¨ ur die Merkmalsgruppe Benutzbarkeit der ISO/IEC 9126. Auch diese kann wegen der baumartigen Struktur der Zieldimensionen im multidimensionalen Zielraum verfeinert werden.

84

QP.2 Qualit¨ atsziele formulieren. Qualit¨ atsziele werden formuliert, indem sie gem¨ aß Template aus Abbildung 5.9 abgeleitet werden. Das Template ist Bestandteil des QP, sodass Ableiten und Aufschreiben von Zielen gleichzeitig stattfinden. Ein m¨ ogliches Qualit¨ atsziel aus der dargestellten Dimensionsbelegung ist das

Sicherstellen der Zuverl¨ assigkeit durch die Abwesenheit von PRIO 1 Bugs in der Fehlerdatenbank bis zum QG-GoLive f¨ ur den Fachbereich.

In diesem Schritt werden moderierte Workshops mit den entsprechenden Rollen des Entwicklungsprojekts durchgef¨ uhrt, f¨ ur welche das Erreichen der Ziele relevant istbeispielsweise jeweils f¨ ur den Fachbereich, das Entwicklerteam und das Team f¨ ur den Betrieb. Hierbei werden pro Workshop die relevanten Elemente des Qualit¨ atsmodells identifiziert und wie in einer verschachtelten for-Schleife die Elemente des Ergebnistyp-und Prozessmodells gew¨ ahlt, bis neue Ziele entstehen..

Anhand der Vollst¨ andigkeit der Abbildung in die jeweilige Dimension kann abgesch¨ atzt werden, ob das Ende der Zieldefinition erreicht wurde. Falls beispielsweise noch keine

85

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

Ziele auf das Element Effizienz der Qualit¨ atsdimension abbilden, kann nicht davon ausgegangen werden, dass die Ziele vollst¨ andig sind. Dies gilt analog f¨ ur das Fehlen von Zielen f¨ ur das Pflichtenheft, die Designphase oder den Fachbereich. Zu jedem Zeitpunkt im Projekt kann der Wiedereintritt in den QP Prozess zum Formulieren neuer bzw. ubersehener Ziele ausgel¨ ost werden. ¨

QP.3 Qualit¨ atsziele auf CIO Ziele abbilden und priorisieren. Das Topmanagement eines Unternehmens legt f¨ ur einen bestimmten Zeitraum strategische Ziele fest, welche in die Projekte getragen werden m¨ ussen, um tats¨ achlich erreicht werden zu k¨ onnen. Beispielsweise kann ein CIO definieren, dass die Betriebskosten aller eingesetzten Systeme innerhalb der n¨ achsten 5 Jahre um 15% sinken m¨ ussen. Dies kann ausschließlich erreicht werden, indem in allen Projekten entsprechende Wartbarkeitsqualit¨ atsziele verfolgt werden. Da nicht jedes strategische Ziel der gleichen Wichtigkeit unterliegt, werden diese in der Regel durch das Management priorisiert. Durch die Abbildung auf CIO Ziele existiert daher auch f¨ ur Qualit¨ atsziele eine implizite Priorisierung. Da ein niedrig priorisiertes CIO Ziel in einem konkreten Projekt durchaus einer hohen Kritikalit¨ at unterliegen kann, wird jedes Qualit¨ atsziel nach der Abbildung auf ein CIO Ziel explizit priorisiert. Die Priorisierung erm¨ oglicht eine Fokussierung auf die wirklich wichtigen Ziele.

QP.4 QS-Maßnahmen f¨ ur Qualit¨ atsziele bestimmen. Da Qualit¨ atsziele ausschließlich das Was?“, nicht jedoch das ” Wie?“ betreffen, werden f¨ ur jedes Ziel konstruktive QS-”

Maßnahmen bestimmt, welche zu dessen Erreichung f¨ uhren. Außerdem werden analytische Maßnahmen festgelegt, welche Aussagen zum Zielerreichungsgrad erm¨ oglichen. Dazu wird zun¨ achst gepr¨ uft, ob der QSM Katalog Maßnahmen enth¨ alt, deren Wirksamkeit in fr¨ uheren Projekten bereits nachgewiesen wurde. Falls keine passenden Maßnahmen gefunden werden k¨ onnen, werden sie im Qualit¨ atsplan definiert. Dies ist der Weg, wie neue QS-Maßnahmen abgeschlossener Projekte durch den kontinuierlichen Verbesserungsprozess in den QSM Katalog gelangen.

W¨ ahrend des Bl¨ atterns im QSM Katalog k¨ onnen durchaus weitere Ideen f¨ ur Qualit¨ atsziele entstehen, wenn die Notwendigkeit f¨ ur das Durchf¨ uhren einer QS-Maßnahme besteht, hierf¨ ur aber noch keine Qualit¨ atsziele definiert wurden. Auch kann die Erfahrung fr¨ uherer Projekte zeigen, dass bestimmte QS-Maßnahmen immer durchgef¨ uhrt werden sollten. Auch hier gilt, dass dokumentierte Erfahrungen mit QS-Maßnahmen durchaus vervollst¨ andigend auf die Ziele eines Projekts wirken k¨ onnen. Aus diesem Grund startet der Zieldefinitionszyklus nach diesem Schritt erneut mit QP.2.

Abbildung 5.10 zeigt das konkrete Vorgehen zum Bestimmen von QS-Maßnahmen f¨ ur ein Qualit¨ atsziel. Hier wird der Vorteil der integrierten Maßnahmen deutlich, da Qualit¨ atsziele und QS-Maßnahmen in den multidimensionalen Zielraum abbilden. Zun¨ achst

86

werden alle QS-Maßnahmen des Katalogs gefiltert, welche auf dasselbe Element der Qualit¨ atsdimension abbilden, wie das betrachtete Qualit¨ atsziel. F¨ ur jede weitere Dimension wird dieser Vorgang auf der Maßnahmenmenge der vorherigen Filterung durchgef¨ uhrt, bis alle Dimensionen gefiltert wurden. Auf dieser Grundlage wird f¨ ur jede QS-Maßnahme ein ¨ Ubereinstimmungsmaß errechnet, welches anzeigt, wie gut sie zu dem Ziel passt. Die Richtigkeit der Auswahl an QS-Maßnahmen f¨ ur ein Ziel h¨ angt damit jedoch von der Qualit¨ at der Abbildung der QSM in den multidimensionalen Zielraum ab. Die Qualit¨ at der Zielraumabbildungen wird jedoch im Rahmen des KVP st¨ andig verbessert.

Ein ¨ Ubereinstimmungsmaß von 4 bedeutet, dass die Abbildungen in den Zielraum identisch sind. Besonders f¨ ur die Rolle heißt dies, dass sie sowohl den Hauptnutzen an der Erreichung des Ziels findet, als auch die QS-Maßnahme durchf¨ uhrt. Ein Wert von 3 mit unterschiedlicher Abbildung in die Rollendimension bedeutet, dass die QS-Maßnahme f¨ ur das Ziel ideal ist und die Rolle der QS-Maßnahme der Rolle des Ziels berichtet.

87

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

Nachdem eine QS-Maßnahme f¨ ur ein Ziel bestimmt wurde, wird diese im Qualit¨ atsplan aufgenommen und f¨ ur den Projektkontext angepasst. Zun¨ achst wird bestimmt, durch welche konkrete Person die Rolle der QS-Maßnahme besetzt wird. Sobald eine Kostensch¨ atzung f¨ ur eine Maßnahme vorliegt, wird diese im Qualit¨ atsplan notiert. Konstruktive QS-Maßnahmen werden anhand der ¨ Anderung bestimmter Durchf¨ uhrungsschritte

f¨ ur das Projekt angepasst. Dies gilt gleichermaßen f¨ ur die Fragen und Metriken der analytischen Maßnahmen. Hier m¨ ussen zus¨ atzlich Schwellwerte f¨ ur die Metriken und den Projektkontext festgelegt werden.

Die Entscheidung, ob sowohl konstruktive, als auch analytische Maßnahmen oder nur eine von beiden f¨ ur ein Ziel durchgef¨ uhrt werden sollen, h¨ angt von dem Hintergrund der Maßnahmendurchf¨ uhrung ab. Wenn eine konstruktive QS-Maßnahme bereits h¨ aufig durchgef¨ uhrt und ihre Wirksamkeit mehrfach nachgewiesen wurde, kann auf eine analytische Maßnahme zur Pr¨ ufung verzichtet werden. Falls eine neue konstruktive Maßnahme erprobt werden soll, ist die Durchf¨ uhrung des analytischen Gegenst¨ ucks jedoch ratsam. F¨ ur den Fall, dass eine definierte Prozesslandschaft in ihrer Leistungsf¨ ahigkeit bez¨ uglich der Qualit¨ at gepr¨ uft werden soll, werden sogar lediglich analytische QS-Maßnahmen durchgef¨ uhrt.

QP.5 QS-Maßnahmen durchf¨ uhren und dokumentieren. Da jede QS-Maßnahme in die Prozessdimension abbildet, ist der Durchf¨ uhrungszeitpunkt definiert. Das Durchf¨ uhren einer QS-Maßnahme ist gleichzeitig der externe Ausl¨ oser f¨ ur den Wiedereintritt in den QP Prozess. Nachdem eine Maßnahme durchgef¨ uhrt wurde, wird dies im QP festgehalten. Hierbei ist zwischen konstruktiven und analytischen Maßnahmen zu unterscheiden, da sie sich sowohl im Modell, als auch in der Durchf¨ uhrung unterscheiden.

Konstruktive Maßnahmen definieren durchzuf¨ uhrende Schritte. Die Dokumentation der Maßnahme schließt den Durchf¨ uhrungszeitraum, die gesch¨ atzten und tats¨ achlich angefallenen Kosten, das Anmerken besonders positiver oder negativer Aspekte eines Schrittes und die Bewertung der Wirksamkeit ein. Wie f¨ ur konstruktive Maßnahmen werden auch f¨ ur analytische Maßnahmen der Durchf¨ uhrungszeitraum und die gesch¨ atzten sowie tats¨ achlichen Kosten im QP abgelegt. Da analytische Maßnahmen im Datenmodell den Fragen- und Metrikteil von GQM enthalten, werden im QP auch die Werte der Metriken und somit die Antworten auf die Fragen notiert.

QP.6 Qualit¨ atsplan schließen. Nach Abschluss des Projekts wird der QP offiziell geschlossen und an einer einheitlichen Stelle abgelegt, in der s¨ amtliche QPs gesammelt werden. ¨ Uber die geschlossenen Pl¨ ane werden im Rahmen des KVP sowohl statistische Analysen durchgef¨ uhrt, als auch Zieldimensionen und QSM Katalog verbessert.

88

5.1.5. Wozu? Wo? Wann? Wer? Wie?

Die Fragen ” Wozu? Wo? Wann? und Wer?“ werden durch die Dimensionen des Zielraums repr¨ asentiert. Eine Abbildung in die Qualit¨ ats-, Ergebnistyp-, Prozess- und Rollendimension definiert hierbei ein Qualit¨ atsziel. Das ” Wie?“ entspricht den QS-Maßnahmen,

welche das operative Gegenst¨ uck zu den Qualit¨ atszielen darstellen. Qualit¨ atsziele und QS-Maßnahmen bilden in denselben multidimensionalen Zielraum ab. Aus diesem Grund k¨ onnen QS-Maßnahmen aus einem Katalog systematisch f¨ ur eine Auswahl von Zielen abgeleitet werden.

Um den multidimensionalen Zielraum an unterschiedliche Projektarten anzupassen, werden entsprechende Software Engineering Modelle ausgew¨ ahlt. F¨ ur Entwicklungsprojekte existieren beispielsweise andere Qualit¨ ats-, Ergebnistyp-, Prozess- und Rollenmodelle, als f¨ ur Testprojekte. Auf die konkrete Anwendbarkeit des Zielraums in unterschiedlichen Projektarten wird im Evaluationskapitel in Abschnitt 6.1 eingegangen.

5.2. Anwenden des Zielraums

5.2.1. Methodenbereich und Projektorganisationen

Wie Basili und Caldiera bereits in [BC95] schrieben, m¨ ussen die Zust¨ andigkeiten des Methodenbereichs und der Projektorganisationen klar voneinander abgegrenzt werden. Da der multidimensionale Zielraum durch Software Engineering Modelle aufgespannt wird, m¨ ussen die Modelle verwaltet werden. Die Aufgaben der Experience Factory gem¨ aß Basili werden in großen Unternehmen durch Bereiche wahrgenommen, deren Tagesgesch¨ aft die Projektunterst¨ utzung und Methodenentwicklung ist. Der Methodenbereich kann beispielsweise eine Research Abteilung sein.

Lott und Rombach gehen in [LR93] auf den Umstand ein, dass Methoden in Projekte durch explizite Lieferobjekte, wie z.B. explizite Projektpl¨ ane getragen werden. Der Mitarbeiter, welcher die Methode letztendlich ausf¨ uhrt, ist daran interessiert, dass ihm einfach verst¨ andliche Dokumententemplates oder Bedienoberfl¨ achen f¨ ur die Erledigung seiner Aufgaben zur Verf¨ ugung stehen.

Abbildung 5.11 zeigt die einzelnen Schritte des QP Prozesses hinsichtlich der Zust¨ andigkeiten. Da dem Methodenbereich bereits die Pflege der Dokumententemplates, Prozesse

89

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

und Rollenbeschreibungen unterliegen, liegt es nahe, dass hier auch die Aufgabe des Verwaltens der Software Engineering Modelle anf¨ allt. Die Projektorganisationen wiederum f¨ uhren Prozesse aus und fertigen Ergebnistypen an. Die Zusammenarbeit zwischen dem Methodenbereich und den Projektorganisationen wird gef¨ ordert, indem sie in allen QP Prozessschritten gemeinsam mit dem QP umgehen.

Wie bei der Experience Factory treten erfahrene Mitarbeiter des Methodenbereichs beratend auf, um ein Projekt bei der Auswahl und Instanziierung der Software Engineering Modelle zu unterst¨ utzen. Hierbei werden zuerst die Zieldimensionen des QP konfiguriert, indem die Modelle f¨ ur das Projekt angepasst werden. Im Anschluss daran werden die Workshops zur Zieldefinition durch den Methodenbereichsmitarbeiter moderiert. In diesem Zusammenhang wird auch von besonders kritischen Qualit¨ atsielen und wirksamen Maßnahmen fr¨ uherer Projekte berichtet. Der Mitarbeiter des Methodenbereichs tritt damit gleichzeitig als Berater, Moderator und Multiplikator von strategischen Zielen, Best Practices und Lessons Learned auf. Nicht zuletzt kann eine Projektorganisation im Methodenbereich auch Hilfe bei der Maßnahmendurchf¨ uhrung und -dokumentation anfordern. Da geschlossene Qualit¨ atspl¨ ane in den KVP einfließen, erh¨ alt der Methodenbereich Zahlen und Fakten f¨ ur die Verbesserung der Software Engineering Modelle und des QSM Katalogs.

5.2.2. Kontinuierlicher Verbesserungsprozess

Ein großer Nutzen des Einsatzes multidimensionaler Qualit¨ atsziele und integrierter QS-Maßnahmen liegt in der kontinuierlichen Verbesserung. Hierbei k¨ onnen sowohl Effektivit¨ ats- als auch Effizienzsteigerungen realisiert werden, indem Qualit¨ atspl¨ ane abgeschlossener Projekte analysiert werden. Abbildung 5.12 zeigt den ¨ Ubergang von der

Qualit¨ atsplannutzung (QP.1 bis QP.6) zu dem kontinuierlichen Verbesserungsprozess (KVP.1 bis KVP.5). Die Verantwortlichkeiten des KVP unterliegen dem Methodenbereich, da hier die Software Engineering Modelle und der QSM Katalog verwaltet werden. Die Projektorganisationen liefern durch ihre Qualit¨ atspl¨ ane die n¨ otigen Daten f¨ ur die statistische Auswertung.

Effektivit¨ at, d.h. die richtigen Dinge tun, kann hierbei gesteigert werden, indem die Zielauswahl im Qualit¨ atsplan zuk¨ unftiger Projekte immer genauer wird und den realen Anspr¨ uchen der Beteiligten entspricht. Es sollte also darauf geachtet werden, keine irrelevanten Ziele zu definieren, um unn¨ otige Qualit¨ atssicherungskosten zu vermeiden. Im gleichen Maße muss allerdings auch darauf Wert gelegt werden, alle relevanten Ziele zu verfolgen, da sonst zus¨ atzliche Kosten wegen fehlender Qualit¨ at entstehen k¨ onnen. Da QS-Maßnahmen anhand der Qualit¨ atsziele f¨ ur ein Projekt bestimmt werden, entsteht Effizienz, d.h. die Dinge richtig tun, durch die Verbesserung der QS-Maßnahmen.

In Abbildung 5.13 ist der kontinuierliche Verbesserungsprozess dargestellt. Er beschreibt sowohl die Aktualisierung der KPIs, als auch die Verbesserung der Software Engineering Modelle (SEM) und des QS-Maßnahmen Katalogs.

91

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

KVP.1 Geschlossene Qualit¨ atspl¨ ane analysieren. Nachdem ein Projekt beendet wurde, wird sein Qualit¨ atsplan in QP.6 geschlossen. In regelm¨ aßigen Abst¨ anden, z.B. j¨ ahrlich, werden die Qualit¨ atspl¨ ane der bis dahin abgeschlossenen Projekte statistisch ausgewertet. Hierbei werden sowohl die Auswahl der Ziele, als auch die Kosten und der Nutzen der durchgef¨ uhrten QS-Maßnahmen analysiert.

KVP.2 KPIs aktualisieren. Grunds¨ atzlich ist zwischen KPIs f¨ ur Qualit¨ atsziele und KPIs f¨ ur QS-Maßnahmen zu unterscheiden. Die Kennzahlen schaffen projekt¨ ubergreifende Transparenz und bilden die Grundlage f¨ ur alle nachfolgenden Schritte des KVP.

Aus den Qualit¨ atspl¨ anen geht hervor, welche CIO Ziele auf wie viele Qualit¨ atsziele abgebildet wurden. Hier entsteht eine Rangliste der ber¨ ucksichtigten CIO Ziele in den Projekten. Die Analyse der Qualit¨ atszieldimensionen ergibt Kennzahlen zu der Verteilung der Ziele in den einzelnen Modellen. Auch hier entsteht eine Rangliste der Ziele pro Dimensionselement. Beispielsweise kann die Merkmalsgruppe Effizienz aus dem Qualit¨ atsmodell besonders h¨ aufig und die Benutzbarkeit daf¨ ur eher selten in Projekten ber¨ ucksichtigt worden sein. Dies gilt analog f¨ ur das Ergebnistyp-, Prozess- und Rollenmodell. Hier kann die Analyse zum Beispiel zeigen, dass in einer Vielzahl von Projekten sehr viele

92

Qualit¨ atsziele f¨ ur die Realisierungsphase definiert wurden und die Qualit¨ atssicherung in der vorgelagerten Spezifikationsphase vernachl¨ assigt wurde.

Da im Qualit¨ atsplan dokumentiert wurde, welche QS-Maßnahmen f¨ ur ein Qualit¨ atziel durchgef¨ uhrt wurden und QS-Maßnahmen das operative Gegenst¨ uck zu Qualit¨ atszielen bilden, entstehen QS-Maßnahmen KPIs analog zu den Ziel KPIs. Zus¨ atzlich wurden gesch¨ atzte und tats¨ achliche Kosten sowie die ben¨ otige Zeit f¨ ur die Maßnahmen dokumentiert, so dass Kennzahlen zu der H¨ ohe und Planungssicherheit von Qualit¨ atskosten gebildet werden k¨ onnen.

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

KVP.3 Software Engineering Modelle (SEM) verbessern. Da die SEM Arten die 4 Zieldimensionen definieren, m¨ ussen diese kontinuierlich verbessert und angepasst werden, um die Zielauswahl f¨ ur ein Projekt zu verbessern. Dabei wird die Effektivit¨ at gesteigert, wenn es gelingt, die Modelle in der Art zu verbessern, dass die richtigen Ziele f¨ ur ein Projekt definiert werden. Die Kennzahlen aus der Analyse der Zieldimensionen (KVP.2) liefern dabei die n¨ otigen Hinweise. Beispielsweise kann ersichtlich werden, dass wenige Ziele f¨ ur die Prozessphase Betrieb des zu entwickelnden Systems bestimmt wurden und somit die Wartbarkeit vernachl¨ assigt wurde. Eine Befragung der Projektmitarbeiter, welche die Qualit¨ atsziele definiert haben, k¨ onnte dann ergeben, dass die ISO/IEC uber keine explizite Merkmalsgruppe Wartbarkeit verf¨ ugt und daher Wartbarkeits-9126 ¨

ziele anhand des multidimensionalen Zielraums nicht explizit formuliert werden k¨ onnen. Dies wiederum f¨ uhrt zu der Verbesserung des Qualit¨ atsmodells, indem die ISO an die Bed¨ urfnisse des Unternehmens angepasst wird.

KVP.4 QS-Maßnahmen Katalog verbessern. Auch f¨ ur die QS-Maßnahmen liefern die QS-Maßnahmen KPIs (KVP.2) die n¨ otigen Informationen f¨ ur die Verbesserung. Aus der Verbesserung der QS-Maßnahmen resultiert die M¨ oglichkeit der Effektivit¨ ats- und Effizienzsteigerung.

QS-Maßnahmen sind integriert, da sie in denselben Zielraum wie Qualit¨ atsziele abbilden. Diese gemeinsame Abbildung ist die Grundlage f¨ ur die Methode zum Bestimmen von QS-Maßnahmen f¨ ur ein Ziel gem¨ aß Abbildung 5.10. Daher ist eine korrekte Abbildung in den Zielraum existentiell, um die richtigen QS-Maßnahmen zu w¨ ahlen. Die Verbesserung der Abbildungen steigert die Effektivit¨ at - die richtigen Dinge tun. Wie bei Zielen zeigen Kennzahlen Statistiken zur Durchf¨ uhrung von Maßnahmen f¨ ur konkrete Dimensionselemente an. Wenn beispielsweise selten Maßnahmen f¨ ur das Erreichen von Performancezielen in der Spezifikationsphase durchgef¨ uhrt werden, deutet dies auf das Fehlen oder die falsche Einordnung von Maßnahmen hin.

Die Effizienz konstruktiver QS-Maßnahmen wird gesteigert, indem die beschriebenen Durchf¨ uhrungsschritte angepasst und vervollst¨ andigt werden. Analytische Maßnahmen werden effizienter, indem die Fragen und Metriken verbessert werden.

Bei der Einf¨ uhrung der multidimensionalen Qualit¨ atsziele und integrierten QS-Maßnahmen werden Workshops durchgef¨ uhrt, um aktuelle Best Practices und Lessons Learned bez¨ uglich der Qualit¨ atssicherung zu sammeln und als QS-Maßnahmen zu verpacken. Diese topdown Definitionen k¨ onnen die Eigenschaft haben, dass sie zun¨ achst unvollst¨ andig oder in der Praxis nicht anwendbar sind. Da die Durchf¨ uhrung einer QS-Maßnahme im Qualit¨ atsplan eines Projekts dokumentiert wird, k¨ onnen hier w¨ ahrend der Projektlaufzeit Bemerkungen, Erfahrungen und Verbesserungsvorschl¨ age festgehalten werden.

94

Wenn in einem Projekt Ideen f¨ ur neue QS-Maßnahmen entstehen und diese auch tats¨ achlich durchgef¨ uhrt wurden, finden sie ¨ uber die Analyse der geschlossenen Qualit¨ atspl¨ ane

und die Verbesserung des QSM Katalogs ihren Weg bottom-up in den Katalog. Wie bei den Maßnahmen aus dem Workshop gilt auch hier, dass es wahrscheinlich ist, dass die neuen Maßnahmen des Katalogs nicht so reif sind, wie die Maßnahmen, welche bereits mehrere Verbesserungen erfahren haben.

KVP.5 Ergebnisse ver¨ offentlichen. Der kontinuierliche Verbesserungsprozess schließt mit der Ver¨ offentlichung der Ergebnisse ab, damit der aktuelle Stand der Qualit¨ atssicherung in das Unternehmen getragen wird. Je nach Wichtigkeit und Umfang der ¨ Anderungen

k¨ onnen zur Verteilung Newsletter, Mitarbeiterzeitschriften, Schulungen oder Pr¨ asentationen verwendet werden.

5.3. Zusammenfassung

In diesem Kapitel wurde eine schlanke Methode vorgestellt, welche das Wiederverwenden von Software Engineering Modellen und deren kontinuierliche Verbesserung erm¨ oglicht. Hierf¨ ur wurden die Dimensionen von GQM Zielen neu geordnet, um diese klar vonein-ander abzugrenzen. Die Dimensionen des multidimensionalen Zielraums repr¨ asentieren Qualit¨ ats-, Ergebnistyp-, Prozess- und Rollenmodelle, so dass ein Qualit¨ atsziel ganzheitlich bez¨ uglich dieser Modelle definiert werden kann. Jedes multidimensionale Qualit¨ atsziel beantwortet demnach die zugrundeliegende Frage: Welche Qualit¨ atsmerkmale m¨ ussen in einem bestimmten Ergebnistyp wann f¨ ur wen ber¨ ucksichtigt werden und welche wirksamen Qualit¨ atssicherungsmaßnahmen existieren diesbez¨ uglich? - Wozu? Wo? Wann? Wer? Wie?

Wegen der Struktur eines multidimensionalen Qualit¨ atsziels erh¨ oht sich die Transparenz f¨ ur alle Beteiligten. Jede der 4 Zieldimensionen liefert daf¨ ur einen Beitrag. Jeder Mitarbeiter kann ablesen, wozu ein Qualit¨ atsziel verfolgt wird, in welchem Ergebnistyp es zu erreichen ist, in welcher Prozessphase Maßnahmen zu ergreifen sind und f¨ ur wen dieser Aufwand betrieben wird. Wegen der Abbildung auf CIO Ziele und der Priorisierung wird auch deutlich, wie wichtig das Erreichen eines konkreten Qualit¨ atsziels ist.

Da die Methode f¨ ur Softwarequalit¨ at aus den 2 Teilen Qualit¨ atsplannutzung und kontinuierlicher Verbesserungsprozess besteht, wird eine klare Aufteilung der Zust¨ andigkeiten in großen Unternehmen herbeigef¨ uhrt. Die Mitarbeiter in Projektorganisationen nutzen

95

5. Multidimensionale Qualit¨ atsziele und integrierte QS-Maßnahmen

den multidimensionalen Zielraum, um die Produktqualit¨ at der resultierenden Ergebnistypen systematisch und strukturiert zu definieren. Aus einem unternehmensweiten QSM Katalog werden im Anschluß an die Zieldefinition geeignete QS-Maßnahmen abgeleitet. Der Methodenbereich eines Unternehmens ist f¨ ur das Bereitsstellen der Methode und die Pflege der Software Engineering Modelle und des QSM Katalogs zust¨ andig. Ihm unterliegt der kontinuierliche Verbesserungsprozess.

Durch den kontinuierlichen Verbesserungsprozess (KVP) k¨ onnen sowohl Effektivit¨ ats-, als auch Effizienzsteigerungen realisiert werden. Die Effektivit¨ at - d.h. die richtigen Dinge tun - steigt, indem die Software Engineering Modelle des multidimensionalen Zielraums kontinuierlich angepasst werden, damit diese die Gegebenheiten in realen Projekten immer besser widerspiegeln. Da die Auswahl der richtigen QS-Maßnahmen f¨ ur ein Qualit¨ atsziel von der Richtigkeit der Abbildungen der Maßnahmen in den multidimensionalen Zielraum abh¨ angt, werden auch diese im Rahmen des KVP stetig aktualisiert. Die Effizienz - d.h. die Dinge richtig tun - verbessert sich, indem die Maßnahmen des QSM Katalogs durch praktische Erfahrungen und Kommentare erg¨ anzt werden. Damit wird erreicht, dass die in QS-Maßnahmen definierten Schritte bzw. Fragen und Metriken solange verbessert werden, bis auch diese in der Praxis anwendbar und tats¨ achlich zielf¨ uhrend sind.

Da die Qualit¨ at durch das Einf¨ uhren von Verbesserungen steigt und Verbesserung durch Lerneffekte herbeigef¨ uhrt werden, liegt ein wesentlicher Punkt im Schaffen von Softwarequalit¨ at im organisationellen Lernen. Hierf¨ ur werden im Rahmen des KVP Best Practices und Lessons Learned aus den Projektorganisationen in den Methodenbereich uberf¨ uhrt, welcher das Wissen und die Erfahrungen aufbereitet und zuk¨ unftigen Projek¨

ten zur Verf¨ ugung stellt.

96

Kapitel 6

Evaluation

In diesem Kapitel werden Teile der vorgestellten Methode f¨ ur Softwarequalit¨ at evaluiert. Abbildung 6.1 markiert den Teil des QP Prozesses, welcher Gegenstand der Evaluation in einem akademischen Umfeld war. Der Schritt QP.1 wird in Abschnitt 6.1 anhand dreier Szenarien evaluiert. In Abschnitt 6.2 werden die Ergebnisse eines Workshops vorgestellt, mit welchem der Schritt QP.2 an der BTU Cottbus erprobt wurde.

6. Evaluation

6.1. QP.1 Qualit¨ atsplan einrichten

In diesem Abschnitt wird der erste Schritt des QP Prozesses evaluiert. Daf¨ ur werden 3 Szenarien vorgestellt, in welchen der multidimensionale Zielraum f¨ ur 3 Projektarten eingerichtet wird.

6.1.1. Szenario 1 - Traditionelles Entwicklungsprojekt

Im ersten Szenario wird gezeigt, dass sich der multidimensionale Zielraum f¨ ur traditionelle Entwicklungsprojekte einrichten l¨ asst. In dieser Projektart kann beispielsweise die ISO/IEC 9126 aus Abschnitt 3.1.1 als Qualit¨ atsmodell verwendet werden. In traditionellen Entwicklungsprojekten werden die Ergebnistypen entlang des Wasserfallprozesses aus Abschnitt 3.3.1 geliefert. Das Projekt wird von einem Kunden an einen Zulieferer ausgegeben. Gem¨ aß Abschnitt 3.4.1 verf¨ ugt der Kunde ¨ uber einen Fachbereich und einen

IT-Bereich, welcher dem Fachbereich zugeordnet ist. Diese beispielhaft f¨ ur ein traditionelles Projekt gew¨ ahlten Software Engineering Modelle werden in Abbildung 6.2 auf die Dimensionen des Zielraums gelegt.

98

Aus dem multidimensionalen Zielraum f¨ ur traditionelle Entwicklungsprojekte ergibt sich zum Beispiel das Ziel Sicherstellen von ¨ Ubertragbarkeit innerhalb der Architektur in der Designphase f¨ ur den IT-Bereich des Kunden.

Eine m¨ ogliche konstruktive QS-Maßnahme ist hier das Durchspielen von Szenarien f¨ ur unterschiedliche Laufzeitumgebungen w¨ ahrend der Designphase durch den Architekten. (1) Im ersten Schritt wird die aktuelle Laufzeitumgebung spezifiziert. Beispielsweise kann der Kunde aktuell f¨ ur alle laufenden Systeme MySQL Datenbankserver verwenden. (2) Im Anschluss daran werden zuk¨ unftige ¨ Anderungen der Laufzeitumgebung fest-

gehalten. Aus Performancegr¨ unden m¨ ochte der Kunde in der nahen Zukunft auf einen professionellen Oracle Server umsteigen. (3) Nachdem die Unterschiede der aktuellen und zuk¨ unftigen Laufzeitumgebung aufgedeckt wurden, wird bewertet, wie stark die Architektur von diesen Unterschieden betroffen ist. Anhand des Beispiels der unterschiedlichen Datenbankserver stellt sich die Frage, ob die zu verwendenden Technologien eine Persistenzschicht bereitstellen, welche einfach per XML konfiguriert werden kann, ohne dass der Programmcode betroffen ist. (4) Abschließend werden die architekturellen Entscheidungen dokumentiert. Die Analyse kann zeigen, dass f¨ ur das Erreichen des ¨ Ubertragbarkeitsziels die Java Persistency API verwendet werden muss, da sie mit unterschiedlichen Datenbankservern kommunizieren kann.

Um die Wirksamkeit der konstruktiven Maßnahme zu bestimmen, bietet sich die analytische QS-Maßnahme Bewertung der architekturellen Entscheidungen w¨ ahrend der Designphase durch den IT-Bereich des Kunden an. Hier stellen sich die Fragen:

1. Wurden architekturelle Entscheidungen getroffen?

2. Wurden schwierige Entscheidungen vertagt?

3. Ist das Team entscheidungsfreudig?

4. Wurden alle architekturellen Entscheidungen in der Architektur realisiert?

Zur Beantwortung der Fragen, welche sich im Rahmen der analytischen QS-Maßnahme stellen, dienen die Metriken:

1. Anzahl architektureller Entscheidungen[Entscheidungsprotokoll|Manuell]

2. Anzahl vertagter Entscheidungen[Entscheidungsprotokoll|Manuell]

3. Metrik 1 ÷ Metrik 2

4. Anzahl der realisierten Entscheidungen[Architekturreview|Manuell] ÷ (Metrik 1 +

6. Evaluation

6.1.2. Szenario 2 - Traditionelles Testprojekt

Das zweite Szenario behandelt den multidimensionalen Zielraum f¨ ur traditionelle Testprojekte. Hier kann die ISO/IEC 9126 nicht ohne Weiteres auf die Qualit¨ atsdimension gelegt werden, so dass die f¨ ur den Test angepasste Version aus Abschnitt 3.1.2 verwendet wird. Die Ergebnistypen resultieren aus dem ISTQB Testprozess gem¨ aß Abschnitt 3.3.3. Auch die Rollen innerhalb des Testprozesses unterscheiden sich von den Rollen des traditionellen Entwicklungsprozesses. Hier wird das Rollenmodell aus Abschnitt 3.4.3 auf die Rollendimension des Zielraums gelegt. Abbildung 6.3 zeigt den angepassten multidimensionalen Zielraum f¨ ur traditionelle Testprojekte gem¨ aß der obigen Beschreibung.

F¨ ur traditionelle Testprojekte ergibt sich aus dem multidimensionalen Zielraum beispielsweise das Ziel Sicherstellen der Wiederverwendbarkeit von Testf¨ allen w¨ ahrend der Testdurchf¨ uhrung f¨ ur den Tester.

100

Als konstruktive QS-Maßnahme kommt das Verwenden einer Wiederverwendungsmatrix w¨ ahrend der Testspezifikation durch den Testdesigner in Frage. (1) Hier wird zun¨ achst eine Excel Tabelle angelegt, in welcher in den Spalten die Teststufen Komponenten-, Subsystem-, System- und Abnahmetest angeordnet werden. (2) Im Anschluss daran werden die Testszenarien aufgereiht. (3) Anhand der Priorisierung der Anwendungsf¨ alle wird bestimmt, welche Testszenarien in welchen Teststufen durchzuf¨ uhren sind. (4) F¨ ur die mehrfach durchzuf¨ uhrenden Testszenarien werden schließlich Testf¨ alle markiert, welche in den entsprechenden Teststufen wiederverwendet werden m¨ ussen. (5) Nicht zuletzt wird die Matrix versioniert, indem nachtr¨ agliche ¨ Anderungen in der Dokumentenhistorie dokumentiert werden.

Da die Erreichung des Ziels gef¨ ahrdet ist, wenn sich die Wiederverwendungsmatrix (WVM) h¨ aufig ¨ andert, empfiehlt sich hier die analytische QS-Maßnahme Pr¨ ufen der Stabilit¨ at der Wiederverwendungsmatrix w¨ ahrend der Testdurchf¨ uhrung durch den Testmanager. Diesbez¨ uglich stellen sich die Fragen:

1. Wie oft werden Testf¨ alle (TF) in der WVM in eine andere Stufe eingeordnet?

2. Wie viele TF wurden nachtr¨ aglich hinzugef¨ ugt?

3. Wie viele TF wurden nachtr¨ aglich aus der WVM entfernt?

4. Wie stabil ist die WVM seit Version 1.0?

Um die Fragen beantworten zu k¨ onnen, gelten die folgenden Messvorschriften:

1. Anzahl angepasster TF seit Version 1.0[WVM|Manuell]

2. Anzahl hinzugef¨ ugter TF seit Version 1.0[WVM|Manuell]

3. Anzahl entfernter TF seit Version 1.0[WVM|Manuell]

4. Anzahl der TF in Version 1.0[WVM|Manuell] ÷ (Metrik 1 + Metrik 2 + Metrik 3)

101

6. Evaluation

6.1.3. Szenario 3 - Agiles Entwicklungsprojekt

Anhand des dritten Szenarios wird gezeigt, dass auch moderne agile Projekte durch die vorgestellten multidimensionalen Qualit¨ atsziele und integrierten QS-Maßnahmen begleitet werden k¨ onnen. Hierbei wird beispielhaft davon ausgegangen, dass das Softwareblutbild von Capgemini sd&m aus Abschnitt 3.1.3 als individuelles Qualit¨ atsmodell verwendet werden soll. F¨ ur den SCRUM Prozess aus Abschnitt 3.3.2 werden neben den herk¨ ommlichen Ergebnistypen auch spezielle Dokumente f¨ ur die Steuerung von SCRUM ben¨ otigt. Auch die beteiligten Rollen unterscheiden sich von den Rollen traditioneller Entwicklungsprojekte. Das SCRUM Rollenmodell entstammt aus Abschnitt 3.4.2. Abbildung 6.4 zeigt den multidimensionalen Zielraum f¨ ur agile SCRUM Projekte.

Als m¨ ogliches Qualit¨ atsziel ergibt sich hier das Sicherstellen des Fortschritts der zu realisierenden Features innerhalb des Sprint Backlogs w¨ ahrend der t¨ aglichen Arbeit f¨ ur den Product Owner.

102

Eine angemessene konstruktive QS-Maßnahme ist hier das Priorisieren der Features im Sprint Backlog w¨ ahrend der Sprintplanung durch den Product Owner. (1) In der Sprint Planung wird ein Workshop einberufen, in welcher der Product Owner und das SCRUM Team zusammentreffen. (2) Hier wird gemeinsam die Menge der im n¨ achsten Sprint zu realisierenden Features aus dem Product Backlog bestimmt. (3) Die ausgew¨ ahlten Features werden im Anschluss daran im Sprint Backlog festgehalten. (4) Im Sprint Backlog wird gepr¨ uft, ob die umzusetzenden Features in der Art geschnitten sind, so dass sie innerhalb eines Arbeitstages durch ein Mitglied des SCRUM Teams abgearbeitet werden k¨ onnen. (5) Schließlich werden die einzelnen Features durch den Product Owner bez¨ uglich ihrer Relevanz, Businesskritikalit¨ at und Verwendungsh¨ aufigkeit priorisiert.

Anhand der analytischen QS-Maßnahme Analyse der umgesetzten Features w¨ ahrend des Sprint Reviews durch den SCRUM Master soll ¨ uberpr¨ uft werden k¨ onnen, ob die konstruktive QS-Maßnahme wirksam ist.

1. Wie viele Features existieren insgesamt im Sprint?

2. Werden alle Features priorisiert?

3. Wie viele Features sind hoch-, mittel- und niedrigpriorisiert?

4. Ist die Priorisierung ausgeglichen?

5. Wie viele Features werden im Sprint nicht geschafft?

Um die Fragen beantworten zu k¨ onnen, gelten die folgenden Metriken:

1. Anzahl der Features[Sprint Backlog|Manuell]

2. Anzahl nichtpriorisierter Features[Sprint Backlog|Manuell]

3. Anzahl priorisierter Features hoch,mittel,niedrig [Sprint Backlog|Manuell]

4. Priorisierungsverh¨ altnis = Metrik 3 hoch ÷ (Metrik 3 mittel + Metrik 3 niedrig )

5. Anzahl verschobener Features hoch,mittel,niedrig [Burn Down Chart|Manuell]

Dieses und die 2 vorangegangen Szenarien zeigten, dass der multidimensionale Zielraum f¨ ur beliebige Projektarten angepasst werden kann. Die beispielhaften Ziele und QS-Maßnahmen sollten zu dem Verst¨ andnis beitragen, wie mit dem Zielraum in den Schritten nach QP.1 Qualit¨ atsplan einrichten umgegangen wird. In Anhang C wird eine konstruktive QS-Maßnahme einer fr¨ uhen Version eines QSM Katalogs gezeigt.

103

6. Evaluation

6.2. QP.2 Qualit¨ atsziele formulieren

F¨ ur die Evaluation des Prozessschritts QP.2 werden in diesem Abschnitt die Ergebnisse eines Workshops vorgestellt, in welchem Studierende zu einem fiktiven traditionellen Entwicklungprojekt Qualit¨ atsziele formulieren sollten. Dieser Teil der Evaluation fand im Rahmen der Vorlesung Softwaretechnik II am Lehrstuhl Software-Systemtechnik der BTU Cottbus statt.

6.2.1. Vorgehensweise

Zun¨ achst wurde eine Vorlesung durchgef¨ uhrt, in welcher die 4 Modellarten sowie die entsprechenden Beispielmodelle aus Kapitel 3 vorgestellt wurden. Der Zuh¨ orerschaft wurde zwar erkl¨ art, dass im Rahmen der Projektinitiierung die Modelle festgelegt werden m¨ ussen, welche in dem Projekt anzuwenden sind, nicht jedoch, dass diese gleichzeitig einen multidimensionalen Zielraum aufspannen. Analog der Evaluation des Schritts QP.1 Qualit¨ atsplan einrichten aus Abschnitt 6.1 wurde gezeigt, dass f¨ ur traditionelle und agile Entwicklungsprojekte sowie f¨ ur traditionelle Testprojekte unterschiedliche Software Engineering Modelle gew¨ ahlt werden m¨ ussen.

Am n¨ achsten Tag fand eine ¨ begann. Die 9 ¨ Ubungsteilnehmer hatten 20 Minuten Zeit, um sich das Scope Statement aus Anhang A

durchzulesen und wichtige Passagen zu markieren. Darauf folgend hatten sie weitere 10 Minuten Zeit, um sich einen Ausdruck der ISO/IEC 9126 von Wikipedia durchzulesen. Im Anschluss daran wurden per Zufallsverfahren 2 Gruppen gebildet. In den letzten 30 Minuten sollten die Studierenden schließlich Qualit¨ atsziele formulieren. 4 Teilnehmer bildeten die Gruppe, welche die Ziele ohne Hilfe des multidimensionalen Zielraums ableiten mussten. Diese Gruppe wird im Folgenden als E Gruppe bezeichnet. Das E steht hierbei f¨ ur einfaches Template. Das Ausf¨ ullen des Templates war keine Gruppenarbeit, so dass jedes Gruppenmitglied auf sich selbst gestellt war. Abbildung 6.5 zeigt das einfache Template.

Die andere Gruppe mit 5 Mitgliedern formulierte die Ziele anhand des multidimensionalen Zielraums mit Hilfe des Templates aus Abbildung 6.6. Die Gruppe mit dem multidimensionalen Template wird im Folgenden als M Gruppe bezeichnet. Auch in der M Gruppe war das Ausf¨ ullen keine Gruppenarbeit. Die Zieldimensionen des Templates waren gem¨ aß der Angaben des Scope Statements vorkonfiguriert, so dass die einzelnen Dimensionselemente aus einem Dropdown Men¨ u ausgew¨ ahlt werden konnten.

104

6. Evaluation

Die Hauptaufgabe der Evaluation f¨ allt nach dem Einsammeln der Qualit¨ atspl¨ ane an. Dazu soll verglichen werden, wie sich die unterschiedlichen Excel Templates in den Gruppen auf das Definieren von Qualit¨ atszielen auswirkten. Um zu evaluieren, ob multidimensionale Qualit¨ atsziele gegen¨ uber einfachen Tabellen tats¨ achlich zu einer besseren Zielauswahl f¨ uhren, sollen die folgenden Evaluationsfragen beantwortet werden.

Wurden die Referenzziele erkannt? Durch diese Frage soll gekl¨ art werden, ob das systematische Ableiten von Zielen zu einer vollst¨ andigeren Menge an Qualit¨ atszielen f¨ uhrt. In diesem Zusammenhang ist zu analysieren, zu welchem Anteil die Referenzziele in den Qualit¨ atspl¨ anen der E und M Gruppenmitglieder textuell ermittelt wurden.

Ist die Zielauswahl ganzheitlich? Hier soll verglichen werden, wie viele Qualit¨ atsziele f¨ ur die Elemente der Ergebnistypdimension definiert wurden. F¨ ur diesen Zweck wurde auch im einfachen Qualit¨ atsplan eine Spalte f¨ ur Ergebnistypen bereitgestellt, welche jedoch nicht ¨ uber ein Dropdown Men¨ u verf¨ ugte. Die zu liefernden Ergebnistypen konnten jedoch leicht aus dem Scope Statement abgelesen werden.

Wurden die Ziele einheitlich dimensioniert? Eine Auswahl von Zielen, welche sowohl in der E als auch in der M Gruppe gefunden wurden, wird bez¨ uglich ihrer Dimensionierung analysiert. Hier soll gekl¨ art werden, ob ein Ziel durch die unterschiedlichen Mitglieder der E bzw. M Gruppe dem gleichen Ergebnistyp zugeordnet wurde.

6.2.2. Auswertung der Qualit¨ atspl¨ ane

Anhand der Analyse der aus dem Workshop resultierenden Qualit¨ atspl¨ ane sollen die 3 Evaluationsfragen beantwortet werden. Hierf¨ ur stehen 4 einfache und 5 multidimensionale Qualit¨ atspl¨ ane zur Verf¨ ugung, welche durch die 9 Workshopteilnehmer ausgef¨ ullt wurden. Gruppen¨ ubergreifend definierte ein Teilnehmer durchschnittlich 12,3 Ziele, wobei zwischen der E und M Gruppe kein deutlicher Unterschied festgestellt werden kann. Hinsichtlich der zeitlichen Vorgabe von 30 Minuten dauerte das Definieren eines Ziels damit in beiden Gruppen durchschnittlich 2,5 Minuten. Unabh¨ angig von der Gruppe wurden durch die Teilnehmer doppelte bzw. nicht angemessene Ziele definiert. Ein nicht angemessenes Ziel ist beispielsweise das Ziel Pflichtenheft muss erstellt werden. Da die Analyse der Ziele ¨ uber einen Vergleich mit 15 Referenzzielen stattfindet, wurden doppelte und nicht angemessene Ziele einfach nicht mitgez¨ ahlt. In der E Gruppe kam es zudem vor, dass Prozessphasen in die Ergebnistypspalte des Templates eingetragen wurden. Diese Fehler wurden mit Hilfe des Scope Statements korrigiert, in welchem die Ergebnistypen den Prozessphasen zugeordnet sind.

106

Wurden die Referenzziele erkannt? Zun¨ achst werden die im Scope Statement aus Anhang A enthaltenen Referenzziele aufgelistet. Die Ziele sind an dieser Stelle lediglich textuell beschrieben. Ein ausgef¨ ullter multidimensionaler Qualit¨ atsplan mit den 15 wichtigen Referenzzielen befindet sich in Anhang B.

1. Fehlende Erfahrung der Nutzer mit Webanwendungen ber¨ ucksichtigen

2. Vollst¨ andige Spezifikation der Funktionalit¨ at, da die SW im Wasserfallmodell entwickelt wird

3. Schutz der ¨ ubertragenen Daten, da der Bestellprozess gesch¨ aftskritisch ist

4. Schnittstellen zu dem undefinierten Lieferprozesses ber¨ ucksichtigen

5. Nutzung in Deutschland und Polen ber¨ ucksichtigen

6. Schnittstellen zu Outlook ber¨ ucksichtigen.

7. Das Datenmodell enth¨ alt mind. die Felder der abzul¨ osenden Exceltabellen

8. Neben IE 6.1 auch neue Browsergenerationen ber¨ ucksichtigen

9. Bereitstellen von Funktionen zum Pr¨ ufen von Mengen und Einheiten, um Fehleingaben zu erkennen

10. Tester in den Entwicklungsprozess einbeziehen

11. Langsame Internetverbindung (ISDN) der Filialen ber¨ ucksichtigen

12. Mitarbeiter abholen, um Kosten der Systemeinf¨ uhrung zu reduzieren

13. Bis zu 100 gleichzeitig stattfindende Bestellungen erm¨ oglichen

14. Bereits hohe Auslastung der Administratoren ber¨ ucksichtigen

15. Bessere Datenqualit¨ at f¨ ur vertrauensw¨ urdigere Zahlen

Abbildung 6.7 zeigt ein Diagramm, in welchem die 15 Referenzziele horizontal angeordnet sind. Die blauen Balken repr¨ asentieren die E Gruppe, welche ¨ uber keinen multidimensionalen Zielraum verf¨ ugte. Die roten Balken stellen die M Gruppe dar, welche Ziele anhand des multidimensionalen Raums ableitete. Die vertikale Achse zeigt den Anteil der Gruppenmitglieder, welche das entsprechende Ziel fanden. Ein Wert von 1.0 sagt aus, dass alle Mitglieder der entsprechenden Gruppe das Ziel gefunden haben.

107

6. Evaluation

Das Diagramm zeigt, dass bei 10 von 15 Zielen anteilig mehr Mitglieder der multidimensionalen Gruppe f¨ undiger wurden. Das einzige Ziel, welches durch keinen Teilnehmer gefunden wurde, ist das Ziel Z.11. Neben dem Ziel Z.11 wurden in der M Gruppe 3 weitere Ziele (Z.5, Z.7, Z.9) durch kein Gruppenmitglied gefunden. In der E Gruppe wurden neben dem Ziel Z.11 weitere 4 Ziele (Z.4, Z.8, Z.12, Z.15) nicht gefunden. An-hand des 9-k¨ opfigen Versuchsteams zeigt sich also, dass in den Gruppen ungef¨ ahr die gleiche Anzahl an Zielen nicht gefunden wurde.

Bei den Zielen, die sowohl in der E Gruppe, als auch in der M Gruppe gefunden wurden, wird allerdings deutlich, dass mehr Mitglieder der M Gruppe diese Ziele fanden. Hier wird lediglich bei dem Ziel Z.6 ersichtlich, dass die Mitglieder der E Gruppe anteilig erfolgreicher waren. Die Ziele Z.1, Z.3, Z.4, Z.10 und Z.14 wurden durch mindestens 80% der M Gruppenmitglieder aus dem Scope Statement herausgefiltert. Dies sind 5 von 15 Ziele. Dieser Gruppenkonsens ist in der E Gruppe nicht zu beobachten.

In Abbildung 6.8 ist dargestellt, wie viele der 15 Ziele jeder einzelne Gruppenteilnehmer gefunden hat. Die Mitglieder der E Gruppe mit dem einfachen Template sind durch E.1 bis E.4 repr¨ asentiert. M.1 bis M.5 stellen die Teilnehmer der multidimensionalen Grupppe dar. Die blaue Linie entspricht der durchschnittlichen Zielfindungsrate in der E Gruppe. Die rote Linie kennzeichnet den multidimensionalen Gruppendurchschnitt.

108

Auf der vertikalen Achse bedeutet ein Wert von 1.0, dass durch einen Teilnehmer alle 15 Ziele gefunden wurden.

Das beste Mitglied der E Gruppe fand 6 der 15 Ziele (E.1). Das beste M Mitglied fand 9 Ziele (M.1). Sowohl E.1, als auch M.1 definierten in ihrer Gruppe zugleich die h¨ ochste Anzahl an Zielen. Der Rest der E Gruppe fand zwischen 10% und 20% der Ziele. In der M Gruppe fanden 3 von 5 Mitglieder zwischen 40% und 60% der Ziele. Zwei M Gruppenmitglieder filterten aus dem Scope Statement 33% der Ziele. Die Differenz der blauen und roten Linie zeigt, dass die Mitglieder der M Gruppe im Durchschnitt ungef¨ ahr doppelt so viele Referenzziele fanden, wie die Mitglieder der E Gruppe.

Abbildung 6.9 zeigt ein Diagramm, in welchem das Verh¨ altnis der gefundenen Referenzziele gemessen an der Gesamtanzahl der Ziele jedes Teilnehmers dargestellt ist. Ein Wert von 1.0 auf der vertikalen Achse zeigt an, dass alle Ziele eines Teilnehmers auf Referenzziele abgebildet werden konnten. Es zeigte sich jedoch, dass die Ziele der Teilnehmer h¨ aufig nicht den Referenzzielen entsprachen. Zum Einen lag dies darin begr¨ undet, dass Ziele nicht ausreichend beschrieben wurden. Ein Beispiel hierf¨ ur ist das Ziel Windows XP SP2. Desweiteren wurden durch einige Teilnehmer auch f¨ alschlicherweise QS-Maßnahmen definiert. Wenn sich von den QS-Maßnahmen nicht auf ein Ziel schließen ließ, wurden sie keinem Referenzziel zugewiesen.

109

6. Evaluation

Die Ziele der Gruppenbesten E.4 und M.5 konnten zu 90% auf die Referenzziele abgebildet werden. Beide definierten im Verh¨ altnis zu den anderen Teilnehmern ihrer Gruppe wenige Ziele. Die blaue Linie zeigt, dass durchschnittlich 33% der Ziele der E Gruppe auf Referenzziele abgebildet werden konnten. Die rote Linie repr¨ asentiert den Durchschnitt der M Gruppe, welche einen Wert von 55% erreichte. An der Differenz der beiden Linien wird ersichtlich, dass die M Gruppe auch hier erfolgreicher war.

An dieser Stelle stellt sich die Frage, warum die E Gruppe verh¨ altnism¨ aßig schlecht abgeschnitten hat. Zun¨ achst liegt es daran, dass der Teilnehmer E.3 nicht Ziele, sondern lediglich sehr allgemeine QS-Maßnahmen definierte. Ein Beispiel hierf¨ ur ist die Maßnahme Review des Pflichtenhefts. Auch Teilnehmer E.2 definierte einige sehr allgemeine QS-Maßnahmen. Der Teilnehmer E.4 formulierte mehrere Ziele doppelt. In der M Gruppe sind Zielduplikate und das Definieren von QS-Maßnahmen anstelle von Zielen nicht so stark ausgepr¨ agt, wie in der E Gruppe. In dieser Hinsicht zeigt sich zumindest in der kleinen Evaluationsgruppe, dass das multidimensionale Template das Formulieren von Zielen unterst¨ utzt.

110

Ist die Zielauswahl ganzheitlich? Die Auswertung der ausgef¨ ullten Qualit¨ atspl¨ ane macht die Ganzheitlichkeit der Zieldefinition innerhalb der E und M Gruppe deutlich. Eine ganzheitliche Zieldefinition ist an dieser Stelle durch das Einbeziehen aller Ergebnistypen gekennzeichnet.

Abbildung 6.10 zeigt ein Diagramm, in welchem die Mitglieder der E und M Gruppe horizontal angeordnet sind. Die Balken stellen den Anteil der ber¨ ucksichtigten Ergebnistypen durch die Gruppenmitglieder dar. Mehrere Vorkommen eines Ergebnistyps wurden hierf¨ ur nur einmal gez¨ ahlt. Bei der Z¨ ahlung der Ziele kam es nicht auf die Qualit¨ at der Zielbeschreibung an, sondern lediglich auf das Vorhandensein eines Ziels f¨ ur einen Ergebnistyp. Es soll also analysiert werden, ob w¨ ahrend der Zieldefinition an alle Ergebnistypen gedacht wurde. In der E Gruppe kam es zu Zielen wie Schnittstellen anbieten, f¨ ur welche in der Ergebnistypspalte einfach alle Ergebnistypen aufgelistet wurden. Diese Ziele gingen nicht in die Bewertung ein.

Ein Wert von 1.0 auf der vertikalen Achse sagt aus, dass durch einen Teilnehmer alle Ergebnistypen ber¨ ucksichtigt wurden. Die blaue Linie zeigt den durchschnittlichen Anteil der ber¨ ucksichtigten Ergebnistypen f¨ ur die E Gruppe. Der multidimensionale Durchschnittswert ist durch die rote Linie dargestellt.

6. Evaluation

Im Diagramm aus Abbildung 6.10 wird ersichtlich, dass zwischen den Gruppen kein großer Unterschied in der ganzheitlichen Definition bez¨ uglich der Ergebnistypen existiert, obwohl auch hier die M Gruppe leicht vorn liegt. Durchschnittlich wurden durch die M Mitglieder 63% der Ergebnistypen ber¨ ucksichtigt. Die E Gruppe kam hier auf einen Wert von 50%.

Die ¨ Ahnlichkeit der durschnittlichen Ganzheitlichkeit bez¨ uglich der Ergebnistypen liegt begr¨ undet in der Tatsache, dass sowohl im einfachen, als auch im multidimensionalen Template eine Spalte zum Eintragen von Ergebnistypen existierte. Trotzdem zeigt sich bereits in der kleinen Versuchsgruppe eine Tendenz, dass sich das Bereitstellen einer expliziten Spalte mit ausw¨ ahlbaren Dimensionselementen positiv auf die Ganzheitlichkeit der Zieldefinition auswirkt.

Wurden die Ziele einheitlich dimensioniert? Anhand der Ziele, welche sowohl durch mehrere Mitglieder der E, als auch der M Gruppe ermittelt wurden, wird gepr¨ uft, welche Ergebnistypen zugeordnet wurden. In Abbildung 6.7 wird ersichtlich, dass in der kleinen Evaluationsgruppe von 9 Teilnehmern leider nur die Ziele Z.3 und Z.13 durch mindestens 2 Mitglieder der jeweiligen Gruppe gefunden wurden.

Das Ziel Z.3 Schutz der ¨ ubertragenen Daten, da der Bestellprozess gesch¨ aftskritisch ist wurde in der E Gruppe durch 2 Mitglieder ermittelt. E.1 war der Meinung, dass das Ziel im Pflichtenheft erreicht werden muss. E.3. dachte, dass es im operativen System zu erreichen ist. In der M Gruppe wurde Z.3 durch 4 Mitglieder gefunden. Auch hier ordnete jeder das Ziel einem anderen Element der Ergebnistypdimension zu. F¨ ur M.1 spielt das Ziel im Pflichtenheft eine Rolle. M.2 ist der Ansicht, dass es in der operativen Datenbank erreicht werden soll. Der Teilnehmer M.3 sieht das Ziel in dem operativen System. M.4 w¨ urde es schließlich in der Systemarchitektur ansiedeln. Es zeigt sich jedoch, dass 3 der 4 M Gruppenmitglieder den Zeitpunkt, in welchem das Ziel erreicht werden sollte, vor der Realisierungsphase sehen. Lediglich M.2 denkt, dass es erst im Betrieb erreicht werden muss. Vermutlich sah M.2 das Ziel aus der Perspektive, dass die operative Datenbank w¨ ahrend der Betriebsphase gesch¨ utzt wird, indem beispielsweise eine einfache QS-Maßnahme durchgef¨ uhrt wird: root Passwort im Datenbankserver einrichten und Ports sperren. Jedes Mitglied der M Gruppe hat das Ziel in der Qualit¨ atsdimension als Sicherheitsziel eingestuft.

Das Ziel Z.13 Bis zu 100 gleichzeitig stattfindende Bestellungen erm¨ oglichen wurde in der E Gruppe zweimal und in der M Gruppe dreimal gefunden. In der E Gruppe sieht E.1 die Erreichung des Ziels in der Systemarchitektur. Der Teilnehmer E.4 wiederum w¨ urde das Ziel dem operativen System zuordnen. Auch von den 3 Mitgliedern der M Gruppe, welche das Ziel Z.13 fanden, ordnete M.1 das Ziel der Systemarchitektur und

112

M5 dem operativen System zu. In der Qualit¨ atsdimension bildeten M.1 und M.5 das Ziel auf die Zuverl¨ assigkeit ab. M.4 sah die Erreichung des Ziels im dokumentierten Quelltext f¨ ur das Sicherstellen der Effizienz.

Die beiden betrachteten Ziele zeigen tendenziell, dass bei der individuellen Definition der Ziele durchaus unterschiedliche Abbildungen in den multidimensionalen Zielraum entstehen. Je nach abzuleitender QS-Maßnahme kann ein Ziel nicht falsch dimensioniert werden. Dies zeigte sich zum Beispiel am zugeordneten Ergebnistyp des Ziels Z.13. In Abh¨ angigkeit der Zuordnung zu Systemarchitektur oder operativer Datenbank lassen sich f¨ ur Sicherheitsziele unterschiedliche QS-Maßnahmen ableiten. Auch an der Abbildung in die Qualit¨ atsdimension des Ziels Z.13 zeigt sich, dass sich eine Einordnung als Zuverl¨ assigkeits- oder Effizienzziel begr¨ unden l¨ asst.

Anhand der 2 Beispielziele wird klar, dass die Ansichten bez¨ uglich der Qualit¨ at sehr verschieden sein k¨ onnen. Aus diesem Grund ist es nicht sinnvoll, Qualit¨ atsziele im stillen K¨ ammerlein zu definieren, sondern wie in dem Prozessschritt QP.2 Qualit¨ atsziele formulieren vorgesehen gemeinsam in Workshops zu diskutieren.

6.3. Fazit

Im ersten Abschnitt dieses Kapitels wurde gezeigt, dass sich der multidimensionale Zielraum f¨ ur unterschiedliche Projektarten anpassen l¨ asst. F¨ ur jede Projektart wurde neben dem Zielraum auch jeweils ein Beispiel f¨ ur Qualit¨ atsziele und QS-Maßnahmen vorgestellt, um zu zeigen, dass das Definieren von Zielen und Maßnahmen innerhalb des angepassten Zielraums m¨ oglich ist. Neben Produktentwicklungsprojekten k¨ onnen durchaus auch andere Entwicklungsprojekte durch multidimensionale Ziele unterst¨ utzt werden. F¨ ur ein Entwicklungsprojekt l¨ asst sich die Ergebnistypdimension auch mit Prozessen belegen, wenn diese Gegenstand der Entwicklung sind. In diesem Fall m¨ ussen die Qualit¨ atsdimension mit einem Modell mit Prozessqualit¨ atsmerkmalen und die Prozessdimension mit einem Prozessentwicklungsprozess belegt werden.

Der Schritt QP.2 Qualit¨ atsziele formulieren wurde mit 9 Studierenden durchgespielt. In der kleinen Evaluationsgruppe kann nicht festgestellt werden, dass multidimensionale Ziele zu vollst¨ andigen Qualit¨ atspl¨ anen f¨ uhren. Durch multidimensionale Ziele wurde jedoch vermieden, dass QS-Maßnahmen statt Ziele definiert wurden. Dies konnte in den Qualit¨ atspl¨ anen der E Gruppe beobachtet werden. Desweiteren waren die Ziele der M Gruppe im Review verst¨ andlicher, da bei unkonkreter textueller Beschreibung anhand

113

6. Evaluation

der Einordnung in den Zielraum gr¨ oßere Klarheit entstand. Es zeigt sich jedoch auch, dass die Ziele der gesamten Gruppe jeweils vollst¨ andiger sind, als die der einzelnen Gruppenteilnehmer. In jeder Gruppe existierte auch ein Mitglied, welches im Vergleich zu den anderen Mitgliedern deutlich mehr Ziele fand. Dass der Anteil der gefundenen Ziele auf Gruppenebene gr¨ oßer ist, ist eine Best¨ atigung der Beschreibung des Prozessschritts QP.2, in welcher definiert ist, dass Ziele in Workshops erhoben werden m¨ ussen.

In Abbildung 6.11 sind die nicht evaluierten Schritte des QP Prozesses markiert.

QP.3 Qualit¨ atsziele auf CIO Ziele abbilden und priorisieren. Im Gespr¨ ach mit einem Quality Information Officer (QIO) wurde ¨ uber die Abbildung auf CIO Ziele diskutiert.

Der QIO merkte an, dass die strategischen CIO Ziele des entsprechenden Konzerns durch das Topmanagement definiert werden und es schwer fallen wird, diese direkt auf Qualit¨ atsziele abzubilden. Dies liegt begr¨ undet in der Tatsache, dass sich die CIO Ziele in zu großer Flugh¨ ohe befinden und h¨ aufig programmatischer Natur sind. Diese enorme Flugh¨ ohe der Ziele ist auch n¨ otig, da große Unternehmen durch Ziele gef¨ uhrt werden und eine Vielzahl von Projekten zu einer Vielzahl von betriebenen Systemen f¨ uhrt. Damit auf CIO Ziele abgebildet werden kann, m¨ ussen diese jedoch in geeigneter Abstraktion f¨ ur Systeme definiert werden. Demnach sollte ein CIO neben programmatischen und prozessorientierten Zielen auch Ziele bez¨ uglich der zu betreibenden Systeme festlegen.

114

Das Priorisieren von Qualit¨ atszielen ist nach Aussage des QIO Stand der Technik. Allerdings wird es nicht fl¨ achendeckend betrieben, da im entsprechenden Unternehmen keine einheitliche Methode f¨ ur Softwarequalit¨ at existiert. Nach der Meinung des QIO liegt der Vorteil der Priorisierung in der Entscheidungshilfe beim Aufl¨ osen von Zielkonflikten.

QP.4 QS-Maßnahmen bestimmen. Das Bestimmen der richtigen Maßnahmen h¨ angt direkt von der richtigen Einordnung der QS-Maßnahmen in den multidimensionalen Zielraum ab. Die Maßnahmen eines QSM Katalogs enthalten Best Practices und Lessons Learned vergangener Projekte, welche im Rahmen des kontinuierlichen Verbesserungsprozesses in den Katalog gelangen. Ein solcher QSM Katalog liegt zum aktuellen Zeitpunkt lediglich in einer sehr fr¨ uhen Version vor. Aus diesem Grund kann eine Evaluation des Bestimmens der QS-Maßnahmen an dieser Stelle nicht durchgef¨ uhrt werden. In Anhang C wird eine konstruktive QS-Maßnahme dieses Katalogs gezeigt.

QP.5 QS-Maßnahmen durchf¨ uhren und dokumentieren. Nachdem QS-Maßnahmen bestimmt wurden, werden diese zu dem definierten Zeitpunkt durchgef¨ uhrt. Wie bei QP.4 gilt, dass sich die Beschreibungen der QS-Maßnahmen ¨ uber den kontinuierlichen Verbesserungsprozess stetig dem tats¨ achlichen Bedarf in den Projekten ann¨ ahern. Auch hier ist anzumerken, dass diese Art von Maßnahmen zum jetzigen Zeitpunkt noch nicht existieren. Besonders f¨ ur die Analyse der Maßnahmendurchf¨ uhrung und -dokumentation bedarf es eines Unternehmens, in welchem die vorgestellte Methode f¨ ur Softwarequalit¨ at implementiert werden kann.

QP.6 Qualit¨ atsplan schließen. Das Schließen und einheitliche Ablegen von Qualit¨ atspl¨ anen ist trivial und muss nicht evaluiert werden. Die Auswertung der Qualit¨ atspl¨ ane des fiktiven Projekts deutet an, auf welche Art die Qualit¨ atspl¨ ane unterschiedlicher Projekte im Rahmen des kontinuierlichen Verbesserungsprozesses analysiert werden k¨ onnen.

F¨ ur alle zu evaluierenden Schritte gilt, dass eine Erprobung in der Praxis noch aussteht. F¨ ur die praktische Evaluation muss ein Unternehmen gefunden werden, welches bereit ist, die vorgestellte Methode f¨ ur Softwarequalit¨ at zu implementieren. Dazu ist es n¨ otig, ein Pilotprojekt zu finden, in welchem QS-Maßnahmen gezielt durchgef¨ uhrt und in ihrer Wirksamkeit bewertet werden, um den QSM Katalog initial zu bef¨ ullen. Durch die Pilotierung soll erreicht werden, dass die Projektmitarbeiter w¨ ahrend der breiten Einf¨ uhrung der Methode f¨ ur Softwarequalit¨ at bereits von konkreten Best Practices und Lessons Learned im Sinne von QS-Maßnahmen profitieren k¨ onnen. Damit sollen multidimensionale Ziele und integrierte QS-Maßnahmen nicht als theoretisches Konstrukt, sondern als praktisch relevant auftreten.

115

Kapitel 7

Ausblick

Die in der vorliegenden Arbeit vorgestellte Methode f¨ ur Softwarequalit¨ at orientiert sich am verbreiteten GQM Ansatz. Trotzdem handelt es sich bei ihr lediglich um ein theoretisches Konstrukt, welches noch nicht in der Praxis erprobt wurde. Der wichtigste Ausblick ist demnach, dass ein Unternehmen gefunden wird, welches eine Implementierung der Methode erm¨ oglicht. Das Thema der Softwarequalit¨ at war in den letzten Jahren auch in der Forschung hochaktuell - dies wird an der Anzahl der Publikationen deutlich. In Abschnitt 7.1 wird gezeigt, wie die vorgestellte Methode eine Forschungsagenda betrifft, welche im Jahr 2010 ver¨ offentlicht wurde. Abschließend werden die M¨ oglichkeiten einer Werkzeugunterst¨ utzung in Abschnitt 7.2 und Anhang D aufgezeigt.

7.1. SE 2008: Forschungsagenda

Im Rahmen der SE 2008 wurde in einer Diskussion zwischen Experten eine Forschungsagenda erstellt, welche im Informatikspektrum 2010 ver¨ offentlicht wurde [WBD ⁺ 10]. Im Folgenden wird die in dieser Arbeit vorgestellte Methode f¨ ur Softwarequalit¨ at in die Schwerpunkte der Agenda eingeordnet.

Anpassung von Qualit¨ atsmodellen. Der multidimensionale Zielraum ist hinsichtlich der Software Engineering Modelle ganzheitlich. In jedem Projekt m¨ ussen demnach nicht nur Qualit¨ atsmodelle, sondern auch Ergebnistyp-, Prozess- und Rollenmodellen angepasst werden. Bereits angepasste Modelle wie z.B. individuell spezialisierte Qualit¨ atsmodelle

117

7. Ausblick

k¨ onnen ohne Weiteres auf die entsprechende Dimension des multidimensionalen Zielraums gelegt werden. Damit ist eine Wiederverwendbarkeit der Modelle gegeben. Speziell f¨ ur die Qualit¨ atsdimension des multidimensionalen Zielraums gilt, dass auf sie Qualit¨ atsmodelle gelegt werden, welche gem¨ aß FCM lediglich ¨ uber Faktoren und Kriterien (FC), nicht jedoch ¨ uber Metriken verf¨ ugen. F¨ ur die Definition von Qualit¨ atszielen spielen Metriken demnach noch keine Rolle. Dies hat den Vorteil, dass sich Qualit¨ atsmodelle f¨ ur die Definition von Zielen wesentlich h¨ aufiger wiederverwenden lassen. Messungen werden im Rahmen analytischer QS-Maßnahmen durchgef¨ uhrt.

Qualit¨ atsmessungen mit Qualit¨ atsmodellen. In der Publikationsschrift der Agenda ist eine Herausforderung von Qualit¨ atsmodellen, wie Unternehmen zu den wichtigen Metriken f¨ ur ihre Ziele kommen [WBD ⁺ 10, S.39]. Die Antwort darauf ist: durch organisationelles Lernen. Analytische QS-Maßnahmen enthalten wie in GQM Fragen, welche durch Metriken beantwortet werden. Diese m¨ ussen zun¨ achst erarbeitet und katalogisiert werden. Wegen des unternehmensweit g¨ ultigen QSM Katalogs, der regelm¨ aßigen Wiederverwendung und Anpassung in Projekten sowie des kontinuierlichen Verbesserungsprozesses bedienen die analytischen QS-Maßnahmen mit der Zeit immer besser die Bed¨ urfnisse der Messenden. Diese Behauptung ist in der Praxis jedoch noch zu evaluieren. Hinsichtlich der vorgestellten Methode w¨ are der treffendere Name des Forschungsschwerpunktes Qualit¨ atsmessungen mit analytischen QS-Maßnahmen.

Kosten und Nutzen von Qualit¨ at. Kosten und Nutzen von Softwarequalit¨ at lassen sich anhand der durchgef¨ uhrten QS-Maßnahmen bewerten. Das Datenmodell integrierter QS-Maßnahmen bietet Felder f¨ ur gesch¨ atzte und tats¨ achliche Kosten. Wenn alle QS-Maßnahmen bestimmt und gesch¨ atzt wurden, lassen sich die gesch¨ atzten Kosten f¨ ur das Durchf¨ uhren der QS-Maßnahmen f¨ ur das Projekt summieren. Nachdem das Projekt abgeschlossen wurde, werden die tats¨ achlichen Kosten notiert. Im Rahmen des kontinuierlichen Verbesserungsprozesses werden diesbez¨ uglich Statistiken angefertigt, welche f¨ ur das Planen von Qualit¨ at in zuk¨ unftigen Projekten n¨ utzliche Hinweise liefern.

Das Thema des Nutzens ist komplizierter, als das Thema der Kosten. Zun¨ achst liegt der Nutzen analytischer Maßnahmen darin, sich ein Bild ¨ uber den Qualit¨ atsstatus zu machen. Die Bewertung des Nutzens konstruktiver Maßnahmen stellt das wesentlich spannendere Thema dar, da hierf¨ ur analytische QS-Maßnahmen vor und nach konstruktiven Maßnahmen durchgef¨ uhrt werden m¨ ussen. In dieser Arbeit wurde der Nutzen konkreter Maßnahmen noch nicht bestimmt. Daher bietet das Modell integrierter QS-Maßnahmen zurzeit lediglich eine einfache Skala von ” nicht wirksam“ bis ” sehr wirksam“. Der Ge-genstand weiterer Forschung w¨ are es, ein Pilotprojekt zu finden, in welchem reale Daten ausgewertet werden k¨ onnen.

118

Einf¨ uhrung von Qualit¨ atsmodellen. Laut [WBD ⁺ 10, S.42] ist die fehlende Akzeptanz bez¨ uglich neuer Methoden in einem Unternehmen das gr¨ oßte Risiko f¨ ur den Misserfolg. Besonders bei langwierigen ¨ Anderungen der Abl¨ aufe eines Unternehmens, wie dies auch

beim Einf¨ uhren von Qualit¨ atsmodellen der Fall sein kann, sollte daher auf die Erfahrung anderer Disziplinen, wie z.B. Prozesseinf¨ uhrungen, zur¨ uckgegriffen werden [WBD ⁺ 10, S.43]. Hier wird die Notwendigkeit einer Methode f¨ ur Softwarequalit¨ at deutlich, welche Schritte f¨ ur den Umgang mit den Modellen bereitstellt. F¨ ur den Umgang mit multidimensionalen Qualit¨ atszielen und integrierten Maßnahmen wurden diese Schritte im Rahmen der vorliegenden Arbeit in einer Prozessnotation definiert. Demnach m¨ ussen nicht Qualit¨ atsmodelle, sondern Qualit¨ atsprozesse eingef¨ uhrt werden. Da sich Mitarbeiter im t¨ aglichen Projektgesch¨ aft selten mit Qualit¨ atsmodellen besch¨ aftigen werden, existiert der Bedarf nach einem Werkzeug, welches den Umgang mit den Modellen explizit an jeden einzelnen Prozessschritt bindet.

7.2. Werkzeugunterst¨ utzung

Eine Art der Bewertung des technologischen Reifegrads im Umgang mit Qualit¨ atspl¨ anen wurde in Abschnitt 4.3.2 vorgestellt. Level 1: Kein expliziter Projekt- oder Messplan zeigt dabei an, dass im bewerteten Unternehmen kein explizites Modell f¨ ur Qualit¨ atsziele und QS-Maßnahmen existiert. Im Hauptkapitel 5 wurde ein Datenmodell f¨ ur multidimensionale Ziele und integrierte QS-Maßnahmen definiert. Im Evaluationskapitel 6 wurde f¨ ur einen Workshop mit Studierenden ein Excel Template verwendet, welches das Datenmodell umsetzt. Damit befindet sich die vorgestellte Methode f¨ ur Softwarequalit¨ at bereits im Level 2: Expliziter Projekt- und Messplan.

Ein unterhaltsamer Artikel mit dem Titel ” mit den folgenden S¨ atzen: ”

t¨ aglichen Excel-Ritt autonom und unabh¨ angig ihre Zahlenherde betreuen. Immer wieder muss einer von ihnen seine Herde abgeben - weil sie zu groß geworden ist.“

Auch die vorgestellte Methode wurde aus Gr¨ unden der Einfachheit und schnellen Implementierbarkeit mit Hilfe von Excel Templates evaluiert. Die Versuchung, Excel als Werkzeug einzusetzen, ist generell groß. Da ¨ uber die Jahre jedoch mit einer Vielzahl

von Projekten und damit von Qualit¨ atspl¨ anen zu rechnen ist gilt auch hier, dass die Zahlenherde irgendwann zu groß wird und abgegeben werden muss - an ein Werkzeug, welches das Verarbeiten der Daten aus den Qualit¨ atspl¨ anen automatisiert, so dass kein einsamer Excel-Cowboy Zahlen f¨ ur das Management aufbereiten muss.

119

7. Ausblick

In Anhang D werden Screenshots von ocomse - einem experimentellen Open Source Werkzeug f¨ ur Softwarequalit¨ at - gezeigt. Das Werkzeug soll der in dieser Arbeit vorgestellten Methode zu einem Level 4: Online Projektplan, online Messplan verhelfen.

Die Methode f¨ ur Softwarequalit¨ at muss in der Praxis unter realen Bedingungen werkzeugunterst¨ utzt erprobt werden. Hierf¨ ur gilt es zun¨ achst, die verwendeten Software Engineering Modelle eines Unternehmens zu analysieren, um den multidimensionalen Zielraum aufzubauen. W¨ ahrend der Analyse der Modelle sind auch Workshops mit Experten des Unternehmens durchzuf¨ uhren, um einen initialen QSM Katalog zu erstellen. In einem Pilotprojekt muss im Anschluss daran die Methode f¨ ur Softwarequalit¨ at angewendet werden, um aus dem Zielraum Qualit¨ atsziele abzuleiten und QS-Maßnahmen zu bestimmen. In diesem Pilotprojekt sind schließlich vor und nach konstruktiven QS-Maßnahmen analytische QS-Maßnahmen durchzuf¨ uhren, um die Wirksamkeit der konkreten konstruktiven Maßnahmen zu erforschen.

Die Entwicklung des Werkzeugs zum Planen und Messen von Softwarequalit¨ at, das Bestimmen von Kosten und Nutzen von QS-Maßnahmen sowie das Implementieren der Methode f¨ ur Softwarequalit¨ at in einem realen Umfeld sollen an dieser Stelle die Ziele f¨ ur nachfolgende Arbeiten markieren.

120

Literaturverzeichnis

[Bal96]

[BBC ⁺ 03] Botella, Pere ; Burgu´ es, Xavier ; Carvallo, Juan ; Franch, Xavier ;

[BBF ⁺ 01] Botella, Pere ; Burgues, Xavier ; Franch, Xavier ; Huerta, Mario ; Salazar, Guadalupe: Modeling Non-Functional Requirements. In: Proceedings of Jornadas de Ingenieria de Requisitos Aplicada JIRA 2001, 2001

[BC95]

[BCK03] Bass, Len ; Clements, Paul ; Kazman, Rick: Software Architecture in Practice. 2. Boston, MA : Addison-Wesley, 2003. - ISBN 978-0-321-15495-8

[BCM ⁺ 92] Basili, Victor ; Caldiera, Gianluigi ; McGarry, Frank ; Pajerski, Rose

Literaturverzeichnis

[BCR94] Basili, Victor R. ; Caldiera, Gianluigi ; Rombach, H. D.: The Goal

[BHP ⁺ 99] Birk, Andreas ; Hamann, Dirk ; Pfahl, Dietmar ; J¨ arvinen, Janne ;

[BIC ⁺ 02] Botella, Pere ; Illa, Xavier B. ; Carvallo, Juan P. ; Franch, Xavier

[BKA01] Buglione, Luigi ; Kececi, Nihal ; Abran, Alain: An Integrated Graphical Assessment For Managing Software Product Quality. 2001

[BZP ⁺ 94] Basili, Victor ; Zelkowitz, Marvin ; Page, Gerald ; Mcgarry, Frank ;

[CFF ⁺ 97] Cugola, G. ; Fuggetta, A. ; Fusaro, P. ; Wangenheim, C.G. V. ; La-

[CFQT04] Carvallo, JuanP. ; Franch, Xavier ; Quer, Carme ; Torchiano, Mar-

[DWP ⁺ 07] Deissenboeck, F. ; Wagner, S. ; Pizka, M. ; Teuchert, S. ; Girard,

[FC02]

122

[FLM ⁺ 98] Fuggetta, Alfonso ; Lavazza, Luigi ; Morasca, Sandro ; Cinti, Stefano

[Fro09]

[FS05]

[Glo10]

[Gra08]

[Hof08]

[KLTM10] Kl¨ as, M. ; Lampasona, C. ; Trendowicz, A. ; M¨ unch, J.: Goal-oriented adaptation of software quality models. (2010), S. 4-11

[Koo09]

[KSPR01] Komi-Sirvi¨ o, Seija ; Parviainen, P¨ aivi ; Ronkainen, Jussi: Measure-

Literaturverzeichnis

[LOHR96] Latum, Frank v. ; Oivo, Markku ; Hoisl, Barbara ; Ruhe, G¨ unther: No

[LR93]

[LSO ⁺ 98] Latum, Frank v. ; Solingen, Rini v. ; Oivo, Markku ; Hoisl, Barbara ;

[MRW77] Mccall, Jim A. ; Richards, Paul K. ; Walters, Gene F.: Factors in

[Noa10]

[OB92]

[Qua10]

[Roy87]

[SBS09]

124

[Sch95]

[SD00]

[SDKP06] Seffah, Ahmed ; Donyaee, Mohammad ; Kline, Rex ; Padda, Harkirat:

[SKD01]

[SL04]

[VAC ⁺ 09] Vogel, Oliver ; Arnold, Ingo ; Chughtai, Arif ; Ihler, Edmund ; Keh-

[Wal01]

[WBD ⁺ 10] Wagner, Stefan ; Broy, Manfred ; Deißenb¨ ock, Florian ; Kl¨ as, Michael

[WDW08] Wagner, Stefan ; Deissenboeck, Florian ; Winter, Sebastian: Managing

Literaturverzeichnis

[WLW ⁺ 09] Wagner, Stefan ; Lochmann, Klaus ; Winter, Sebastian ; G¨ ob, Andreas

[WLW ⁺ 10] Wagner, Stefan ; Lochmann, Klaus ; Winter, Sebastian ; G¨ ob, Andreas

[WWD07] Winter, Sebastian ; Wagner, Stefan ; Deissenboeck, Florian: A com-

[ZVS ⁺ 07] Zeiss, Benjamin ; Vega, Diana ; Schieferdecker, Ina ; Neukirchen,

126

Anhang A

B¨ ackereiprojekt: Scope Statement

Zusammenfassung

Eine Großb¨ ackerei mit Sitz und Zentrallager in Cottbus m¨ ochte ihr Vertriebsnetz von aktuell 20 Filialen in S¨ udbrandenburg in den n¨ achsten 2 Jahren auf 40 Filialen erweitern. Dabei sollen auch Filialen in Nordsachsen und Westpolen aufgebaut werden. Dieses Wachstum soll durch moderne Mittel, d.h. in Form eines Internetportals f¨ ur den Bestellprozess von Zutaten und Fertigbackwaren, unterst¨ utzt werden.

Projektbegr¨ undung und Ziele

F¨ ur die Erweiterung des Vertriebsnetzes wurde ein neuer Bestellprozess definiert, welcher in allen bestehenden und zuk¨ unftigen Filialen ausgerollt werden soll. Damit der neue Bestellprozess in den Filialen gelebt wird, muss er durch IT unterst¨ utzt werden. Dies f¨ uhrt zu der Notwendigkeit eines sicheren Internetportals, welches in allen Filialen verpflichtend f¨ ur Bestellungen im Zentrallager einzusetzen ist.

Hauptnutzen

Zurzeit werden f¨ ur die Bestellungen in den Filialen Excel Tabellen ausgef¨ ullt, welche per Email ¨ uber die Woche verteilt an die Zentrale geschickt werden. Dabei fiel in der Vergangenheit auf, dass jede Filiale die Tabellen individuell nach den ¨ ortlichen Gegebenheiten angepasst hat. Wegen der fehlenden M¨ oglichkeit, Statistiken in Echtzeit abzurufen, waren die Filialbestellungen h¨ aufig ungenau. Tippfehler f¨ uhrten manchmal zur Lieferung der 10-fachen Menge, da sowohl den Bestellenden, als auch den Mitarbeitern im Lager der Fehler nicht auffiel. Auch gab es kein gleiches Verst¨ andnis zu den Einheiten, so dass

129

A. B¨ ackereiprojekt: Scope Statement

auch hier h¨ aufig Fehler bei der Lieferung auftraten, indem beispielsweise Gramm und Kilogramm vertauscht wurden. Das aktuelle Vorgehen f¨ uhrt außerdem dazu, dass die Datenqualit¨ at der einzelnen Filialen stark schwankt, das Anfertigen von Statistiken f¨ ur das Management aufw¨ andig ist und die Zahlen nicht 100%ig zuverl¨ assig sind.

In der L¨ osung dieser Probleme liegt der Hauptnutzen des zu entwickelnden IT-Systems.

Schl¨ usselanforderungen

Im Folgenden werden die Hauptfunktionen des Systems dargestellt und die wichtigen Unterfunktionen durch Schlagworte aufgezeigt. Diese Liste ist weder vollst¨ andig, noch ausreichend beschrieben. Die Vervollst¨ andigung und Verfeinerung der Schlagworte muss im Pflichtenheft stattfinden.

1. Darstellen des Lagerinhalts: Gelagerte Menge eines Artikels anzeigen; Haltbarkeitsdaten anzeigen; Standardeinheit eines Artikels anzeigen; Benachrichtigung wenn Artikelmenge im Lager einen kritischen Schwellwert unterschreitet; Mindestbestellmenge pro Artikel

2. Bestellung zusammenstellen im Einkaufswagenprinzip: Zutaten und Fertigbackwaren w¨ ahlen; Menge w¨ ahlen; Vollst¨ andigkeit der Bestellung anhand fr¨ uherer Bestellungen pr¨ ufen; falsche Einheiten und Ausreißer finden (z.B. 10 Pkg. Eier, statt 10 Eier; 10kg Mehl, statt 100kg Mehl)

3. Auftragsbest¨ atigung und vorl¨ aufige Rechnung erstellen: Bestellung best¨ atigen; Auftragsbest¨ atigung versenden und archivieren; Vorl¨ aufige Rechnung versenden

4. Lieferpakete zusammenstellen: Lieferschein erstellen; Lieferschein an Lager versenden

5. Endg¨ ultige Rechnung erstellen: Vorl¨ aufige Rechnung aktualisieren; Endg¨ ultige Rechnung versenden und archivieren

Alle zeitlichen Angaben (Deadline f¨ ur Bestellung, Liefertermin, . . . ) sollen mit den Terminfunktionen von Microsoft Outlook behandelt werden.

130

Schl¨ usselarbeitsergebnisse (Ergebnistypen)

1. Pflichtenheft (in Anforderungsanalyse)

2. Systemarchitektur (in Design)

3. Konzeptionelles Datenmodell, d.h. SQL Modell (in Design)

4. Dokumentierter Quelltext (in Implementierung)

5. Operatives System (in Betrieb)

6. Operative Datenbank mit migrierten Altdaten aus alten Excel Tabellen (in Betrieb)

Punkte außerhalb des Scope

Der Test wird an einen dritten Dienstleister ¨ ubergeben, welcher diesen extern durchf¨ uhrt.

Aus diesem Grund soll durch den Entwicklungsdienstleister ausdr¨ ucklich kein Test durchgef¨ uhrt werden. In Workshops sollen sich Entwickler und Tester jedoch abstimmen.

Das Ziel dieses Projekts ist es nicht, den Lieferprozess (siehe Schl¨ usselanforderungen Punkt 4) zu optimieren. Der Lieferprozess wird Gegenstand eines weiteren Projekts sein, sobald der neue Bestellprozess mitsamt IT-Unterst¨ utzung ausgerollt wurde. Entsprechende Schnittstellen sind jedoch bereitzustellen.

Annahmen, Bedingungen und Abh¨ angigkeiten

• Bestellungen werden im Prozess immer Montag- und Donnerstagabend versendet.

• Durch eine Notbestellung k¨ onnen Bestellungen auch an anderen Tagen durchgef¨ uhrt werden. F¨ ur die Filialen f¨ allt dann jedoch eine Bearbeitungspauschale an.

• In der Zentrale l¨ auft ein Exchange Server 2003 (E-Mail Konten und Termine).

• Die Filialen besitzen einen ISDN Anschluss, durch welchen auch das Internet bereitgestellt wird.

• Die Rechner des Unternehmens sind mit Windows XP SP 2 und MS Office 2003

A. B¨ ackereiprojekt: Scope Statement

Kritische Erfolgsfaktoren

Wie es bei Neuerungen immer ist, ist mit Widerstand in den Filialen zu rechnen, da jede Filiale zurzeit ihre eigene Excel Vorlage verwendet. Der kritische Erfolgsfaktor f¨ ur die reibungslose Einf¨ uhrung des neuen Bestellprozesses ist daher, dass bei der Spezifikation des unterst¨ utzenden IT-Systems alle Filialmitarbeiter abgeholt werden. Eine Umfrage ergab, dass 50% der Filialmitarbeiter privat ¨ uber keinen PC mit Internetanschluss verf¨ ugen.

Eine hohe Priorit¨ at liegt daher auf der intuitiven Benutzbarkeit der Weboberfl¨ ache. Das Team der Administratoren besteht aus 2 ausgebildeten Fachinformatikern, welche bereits mit der Betreuung der Server, Zentral- und Filialrechner zu 80% ausgelastet sind. Das System muss demnach einfach zu warten sein, da eine zus¨ atzliche Einstellung eines weiteren Administrators nicht geplant ist.

Projektvorgehen

Das Projekt soll im Wasserfallvorgehen (Anforderungsanalyse, Design, Implementierung, Test, Betrieb) durchgef¨ uhrt werden und die Ergebnistypen gem¨ aß Schl¨ usselarbeitsergebnisse liefern. Als Qualit¨ atsmodell gilt die ISO/IEC 9126. Das Management der Großb¨ ackerei stellt w¨ ahrend der Projektlaufzeit die beiden Administratoren zu 30% frei und erm¨ oglicht Workshops mit Sachbearbeitern (Zentrale), den Filialen, der Vorb¨ ackerei und dem Lager. Entwicklung und Test werden an unterschiedliche externe Dienstleister vergeben.

132

Anhang B

B¨ ackereiprojekt: Referenzqualit¨ atsziele

Anhang C

Auszug aus QSM Katalog

Im Rahmen der vorliegenden Arbeit wurde eine fr¨ uhe Version eines QSM Katalogs entwickelt, welcher in Form eines Tischaufstellers gedruckt werden soll. Die Abbildungen C.1 und C.2 zeigen Vorder- und R¨ uckseite einer QS-Maßnahme.

C. Auszug aus QSM Katalog

Am Rand der kurzen Seite ist die Prozessdimension angeordnet. Der Rand der langen Seite enth¨ alt die Qualit¨ atsdimension. Bei einer Bindung als Schreibtischaufsteller k¨ onnen diese Markierungen verwendet werden, um im QSM Katalog gezielt nach QS-Maßnahmen f¨ ur bestimmte Prozessphasen oder Qualit¨ atsmerkmale zu suchen. Ein Ausdruck bietet den Vorteil, dass QS-Maßnahmen auf den Schreibtischen der Mitarbeiter pr¨ asent sind. Bez¨ uglich der kontinuierlichen Verbesserung entsteht allerdings der Nachteil, dass der Schreibtischaufsteller in der Einf¨ uhrungsphase st¨ andig neu gedruckt werden m¨ usste. Ein Aufsteller ist daher lediglich f¨ ur konsolidierte QS-Maßnahmen sinnvoll. Aus diesem Grund besteht die Notwendigkeit eines Werkzeugs, welches QS-Maßnahmen in aktueller Version auf dem Bildschirm anzeigt. Der Prototyp f¨ ur ein solches Werkzeug wird in Anhang D vorgestellt.

136

Anhang D

ocomse: Prototypische Implementierung

Das Werkzeug zur Unterst¨ utzung der Methode f¨ ur Softwarequalit¨ at wurde im Rahmen dieser Arbeit prototypisch in J2EE implementiert. Mit Hilfe von Netbeans wurden aus den konzeptionellen Datenmodellen 5.3, 5.5 sowie 5.6 Entity Beans und Session Beans generiert. Die Abbildungen D.1, D.2 sowie D.3 zeigen Screenshots.

Abbildung D.4 zeigt ein Werkzeug zum Darstellen der Messungen von Softwarequalit¨ at im Quelltext. Dieses Werkzeug implementiert das konzeptionelle Datenmodell aus Abbildung 5.7 in Java, wobei die Entit¨ atsklassen h¨ andisch programmiert wurden. Als Entwicklungsumgebung diente Eclipse.

In einem Neuentwicklungsprojekt sollen diese beiden Systeme zusammengef¨ uhrt werden. Da die Prototypen lediglich der Untersuchung der technischen Machbarkeit dienten, werden diese zum Beginn des Neuentwicklungsprojekts verworfen.

137

D. ocomse: Prototypische Implementierung

Abb. D.1.: ocomse: Verwaltungsbereich f¨ ur Zieldimensionen und QSM Katalog

Abbildung D.1 zeigt einen Screenshot des Verwaltungsbereichs. Auf der linken Seite werden die Dimensionen des Zielraums in Tabs angezeigt. Bei einem Klick auf ” Dimensionen verwalten“ ¨ offnet sich ein Dialog, in welchem die Software Engineering Modelle angepasst werden k¨ onnen.

Mit Hilfe von Checkboxen k¨ onnen Elemente der Zieldimensionen markiert werden. Bei

einem Klick auf ”

zess durchgef¨ uhrt, durch welchen auch das ¨

gefilterten QS-Maßnahmen des QSM Katalogs werden auf der rechten Seite in Listen f¨ ur konstruktive und analytische Maßnahmen angezeigt.

138

Der Screenshot aus Abbildung D.2 zeigt einen Ausschnitt der 15 Referenzziele des Qualit¨ atsplans aus Anhang B. Bei einem Klick auf die gelbe Gl¨ uhbirne vor einem Ziel erscheint ein Dialog mit Vorschl¨ agen f¨ ur QS-Maßnahmen, welche mit dem Filterprozess gem¨ aß Abbildung 5.10 f¨ ur das gew¨ ahlte Ziel ermittelt werden. Qualit¨ atsziele k¨ onnen im Prototyp noch nicht priorisiert und auf CIO Ziele abgebildet werden. Dies liegt an dem Umstand, dass das konzeptionelle Datenmodell aus Abbildung 5.3 zum Zeitpunkt der Entwicklung des Prototypen noch nicht ¨ uber die entsprechenden Attribute verf¨ ugte.

139

D. ocomse: Prototypische Implementierung

Abbildung D.3 zeigt einen Screenshot mit einer beispielhaften Auswahl durchzuf¨ uhrender QS-Maßnahmen f¨ ur die Qualit¨ atsziele aus Abbildung D.2. Bei einem Klick auf die gelbe Gl¨ uhbirne vor einer QS-Maßnahme erscheint ein Dialog, in welchem Ziele vorgeschlagen werden, welche durch die QS-Maßnahme erreicht werden k¨ onnen. Bei einem Klick auf QS-Maßnahmen vorschlagen“ wird eine Menge von QS-Maßnahmen ermittelt, welche

”

alle Ziele des Qualit¨ atsplans abdeckt. In beiden F¨ allen wird wieder der in Abbildung 5.10 dargestellte Filterprozess angewendet.

F¨ ur jede QS-Maßnahme werden gem¨ aß des konzeptionellen Datenmodells die gesch¨ atzten und tats¨ achlichen Kosten festgehalten. Eine zurzeit einfache Bewertung des Nutzens erfolgt ¨ uber eine Skala von ” nicht n¨ utzlich“ bis ” sehr n¨ utzlich“.

140

Abbildung D.4 zeigt einen Screenshot eines Werkzeugs, welches bereits vor einiger Zeit in Java entwickelt wurde. Es erh¨ alt als Eingabe XML Dateien von Messwerkzeugen wie Checkstyle, Findbugs oder JavaNCSS und transformiert diese zun¨ achst in ein einheitliches XML Format. Diese vereinheitlichten Dateien werden in ein Data Warehouse geladen und in einem Star Schema mit den Dimensionen ” Artifact“, ” Metric“ und ” Time“ abgelegt. Mit Hilfe der Tabs auf der linken Seite k¨ onnen dann Diagrammtyp und -attribute gew¨ ahlt werden.

141