Das Thema der Softwarequalität ist facettenreich. Dies wird zum Einen an der Studie deutlich, die im Rahmen des Quamoco Projekts durchgeführt wurde. Eines der wichtigsten Ergebnisse dieser Studie ist, dass viele Unternehmen eine eigene Sicht auf die Softwarequalität besitzen und vornehmlich individuelle Qualitätsmodelle einsetzen, um die Qualität ihrer Software zu beschreiben. Zum Anderen wird Software neben diesen individuellen Qualitätsmodellen in unterschiedlichen Entwicklungsprozessmodellen wie dem konventionellen Wasserfallmodell oder modernen agilen Modellen produziert. Die Prozesse sind wiederum an unternehmensspezische Rollenmodelle geknüpft. Die Komplexität des Themas Softwarequalität 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ängigkeiten zwischen ihnen wird ersichtlich, wenn sich folgende Frage stellt:
Welche Qualitätsmerkmale müssen in einem bestimmten Ergebnistyp wann für wen berücksichtigt werden und welche wirksamen Qualitätssicherungsmaßnahmen existieren diesbezüglich? - Wozu? Wo? Wann? Wer? Wie?
Diese Arbeit stellt eine Methode zum Umgang mit den Modellen vor: Multidimensionale Qualitätsziele und integrierte QS-Maßnahmen.
Inhaltsverzeichnis
1. Einleitung
2. Ziele und QS-Maßnahmen
2.1. Definitionen
2.2. Beispielserie: Benzinverbrauch minimieren
2.3. Beispielserie: Softwarequalitätsziele
3. Software Engineering Modelle
3.1. Qualitätsmodelle
3.1.1. Beispiel: ISO/IEC
3.1.2. Beispiel: ISO/IEC 9126 im Test
3.1.3. Beispiel: Capgemini sd&m Softwareblutbild
3.2. Ergebnistypmodelle
3.2.1. Beispiel: Anwendungsfallmodell
3.2.2. Beispiel: Architekturmodell
3.2.3. Beispiel: Testfallmodell
3.3. Prozessmodelle
3.3.1. Beispiel: Wasserfallmodell
3.3.2. Beispiel: SCRUM - Agiles Entwicklungsmodell
3.3.3. Beispiel: Testprozessmodell gemäß ISTQB
3.4. Rollenmodelle
3.4.1. Beispiel: Rollen entlang des Wasserfalls
3.4.2. Beispiel: SCRUM Entwicklerrollen
3.4.3. Beispiel: Testrollen gemäß ISTQB
4. Stand der Forschung
4.1. Anpassen von Qualitätsmodellen
4.1.1. Aktivitätenbasiertes Qualitätsmodell
4.1.2. Produktbasiertes Qualitätsmodell: COTS Taxonomie
4.1.3. Spezialisiertes Qualitätsmodell: QUIM
4.1.4. Zielorientiertes Qualitätsmodell: Goal Question Metric
4.2. Zwischenstand
4.3. Anwenden des GQM Ansatzes
4.3.1. Software Engineering Laboratory
4.3.2. Explizite Projektpläne
4.4. Zusammenfassung
5. Multidimensionale Qualitätsziele und integrierte QS-Maßnahmen
5.1. Anpassen der Modelle des Zielraums
5.1.1. Welche Probleme existieren im GQM Ansatz?
5.1.2. Wie werden die Probleme gelöst?
5.1.3. Wie sieht das zugrunde liegende Modellsystem aus?
5.1.4. Wie funktioniert der Anpassungsprozess?
5.1.5. Wozu? Wo? Wann? Wer? Wie?
5.2. Anwenden des Zielraums
5.2.1. Methodenbereich und Projektorganisationen
5.2.2. Kontinuierlicher Verbesserungsprozess
5.3. Zusammenfassung
6. Evaluation
6.1. QP.1 Qualitätsplan einrichten
6.1.1. Szenario 1 - Traditionelles Entwicklungsprojekt
6.1.2. Szenario 2 - Traditionelles Testprojekt
6.1.3. Szenario 3 - Agiles Entwicklungsprojekt
6.2. QP.2 Qualitätsziele formulieren
6.2.1. Vorgehensweise
6.2.2. Auswertung der Qualitätspläne
6.3. Fazit
7. Ausblick
7.1. SE 2008: Forschungsagenda
7.2. Werkzeugunterstützung
Literaturverzeichnis
A. Bäckereiprojekt: Scope Statement
B. Bäckereiprojekt: Referenzqualitätsziele
C. Auszug aus QSM Katalog
D. ocomse: Prototypische Implementierung
Abbildungsverzeichnis
2.1. Definition des Begriffs Ziel
2.2. Autofahrziel I
2.3. Autofahrziel II
2.4. Autofahrziel III
2.5. Autofahrziel IV
2.6. Autofahrziel V
2.7. Modelle als Zieldimensionen
2.8. Softwarequalitätsziel I
2.9. Softwarequalitätsziel II
2.10. Softwarequalitätsziel III
3.1. Oben: FCM, unten: GQM
3.2. Aufbau der ISO/IEC 9126
3.3. Für den Test angepasste ISO/IEC 9126 [ZVS+07, S.234]
3.4. Capgemini sd&m Software-Blutbild [Hof08, S.20]
3.5. Ergebnistypmodelle im Lebenszyklus einer Software
3.6. Struktur eines Anwendungsfalls nach [Fro09, S.25f]
3.7. Architekturmetamodell gemäß [VAC+09, S.47]
3.8. Attribute eines Testfalls nach [SBS09, S.91]
3.9. Teilprozesse mit Übergabeobjekt und Quality Gate (QG)
3.10. Wasserfallmodell [Roy87, S.329] mit QGs
3.11. SCRUM Entwicklungsprozess nach [Sch95] mit QGs
3.12. Fundamentaler Testprozess [SL04, S.18] und [SBS09, S.12] mit QGs
3.13. Rollenmodell als Organigramm
3.14. Rollen entlang des Wasserfalls
3.15. SCRUM Rollenmodell
3.16. ISTQB Testrollen gemäß [SL04, S.147f]
4.1. Metamodell für aktivitätenbasierte Qualitätsmodelle [DWP+07, S.6]
4.2. Beispiel für Schritt 4: Wartungsmatrix [WDW08, S.30]
4.3. Fundamentales Modell für COTS Taxonomien [CFQT04, S.2]
4.4. Beispiel für Kategorien und Domänen [BIC+02, S.265]
4.5. Qualitätsmetamodell der ISO/IEC 9126 [FC02, S.2]
4.6. Beispiel für Schritt 2: Qualitätsmodell für ERP Systeme [BBC+03, S.232]
4.7. Beispiel für Schritt 6: Beziehungsmatrix für Mail Server [FC02, S.6]
4.8. QUIM Metamodell [SKD01, S.3]
4.9. Beziehungen im QUIM Modell [SKD01, S.4]
4.10. QUIM Metamodell mit Quellen [SKD01, S.3]
4.11. GDQA zum Ableiten von Funktionen [BKA01, S.7]
4.12. Durch GDQA abgeleitete Funktionen [BKA01, S.7]
4.13. GQM im ER-Schema [OB92, S.895]
4.14. GQM Template [OB92, S.895]
4.15. Integration von GQM in das QIP [LSO+98, S.80]
4.16. Fähigkeit der Ansätze zum Beantworten der Fragen
4.17. Quality Improvement Paradigm [BC95, S.58]
4.18. Experience Factory [BC95, S.59]
4.19. Software Engineering Modelle und GQM [OB92, S.888]
4.20. Verbesserungsorientierte Organisationsstruktur [LR93, S.3]
5.1. Modelle als Zieldimensionen
5.2. Multidimensionaler Zielraum: Qualitätsziele
5.3. Konzeptionelles Datenmodell (nur Ziele)
5.4. Multidimensionaler Zielraum: QS-Maßnahmen
5.5. Konzeptionelles Datenmodell (konstruktive QS-Maßnahmen)
5.6. Konzeptionelles Datenmodell (analytische QS-Maßnahmen)
5.7. Konzeptionelles Datenmodell (Metrikwerte)
5.8. Prozess für Softwarequalität
5.9. Template zum Formulieren multidimensionaler Qualitätsziele
5.10. Bestimmen von QS-Maßnahmen für ein Ziel
5.11. Methodenbereich und Projektorganisationen gemäß [Noa10]
5.12. KVP und Qualitätsplannutzung
5.13. Kontinuierlicher Verbesserungsprozess
6.1. Evaluationsgegenstand (blau hervorgehoben)
6.2. Traditionelles Entwicklungsprojekt
6.3. Traditionelles Testprojekt
6.4. Agiles Entwicklungsprojekt
6.5. Excel Template für Gruppe E: einfache Ziele
6.6. Excel Template für Gruppe M: multidimensionale Ziele
6.7. Gefundenes Ziel je Gruppe
6.8. Gefundene Ziele je Gruppenteilnehmer
6.9. Verhältnis der gefundenen Referenzziele an allen Zielen
6.10. Berücksichtigte Ergebnistypen je Teilnehmer
6.11. Nicht evaluierte QP Schritte
B.1. Qualitätsziele für das Scope Statement aus Anhang A
C.1. QS-Maßnahme eines QSM Katalogs (Vorderseite)
C.2. QS-Maßnahme eines QSM Katalogs (Rückseite)
D.1. ocomse: Verwaltungsbereich für Zieldimensionen und QSM Katalog
D.2. ocomse: Qualitätsziele für das Bäckereiprojekt
D.3. ocomse: QS-Maßnahmen für das Bäckereiprojekt
D.4. ocomse: Messen von Softwarequalität
Einleitung
Das Thema der Softwarequalität ist facettenreich. Dies wird zum Einen an der Studie [WLW+10] deutlich, die im Rahmen des Quamoco Projekts [Qua10] durchgeführt wurde. Eines der wichtigsten Ergebnisse dieser Studie ist, dass viele Unternehmen eine eigene Sicht auf die Softwarequalität besitzen und vornehmlich individuelle Qualitätsmodelle einsetzen, um die Qualität ihrer Software zu beschreiben. Zum Anderen wird Softwa- re neben diesen individuellen Qualitätsmodellen in unterschiedlichen Entwicklungspro- zessmodellen wie dem konventionellen Wasserfallmodell oder modernen agilen Modellen produziert. Die Prozesse sind wiederum an unternehmensspezifische Rollenmodelle ge- knüpft. Die Komplexität des Themas Softwarequalität wird weiterhin gesteigert, indem Software nicht lediglich aus Quelltext, sondern aus einer Vielzahl unterschiedlicher Er- gebnistypen besteht.
Die Vielzahl der Modellarten und die Schwierigkeit der Beherrschung der Abhängigkeiten zwischen ihnen wird ersichtlich, wenn sich folgende Frage stellt:
Welche Qualitätsmerkmale müssen in einem bestimmten Ergebnistyp wann für wen berücksichtigt werden und welche wirksamen Qualitätssicherungsmaßnahmen existieren diesbezüglich? - Wozu? Wo? Wann? Wer? Wie?
Diese Arbeit stellt eine Methode zum Umgang mit den Modellen vor: Multidimensionale Qualitätsziele und integrierte QS-Maßnahmen.
Das Ziel dieser Arbeit ist demnach das Herbeiführen einer Methode für Softwarequalität, welche in der Lage ist, die 5 Fragen zu beantworten. Herbeiführen heißt hierbei, die Vorund Nachteile bestehender Ansätze zu berücksichtigen.
Die vorliegende Arbeit beginnt mit einer Einführung in das Thema. In Kapitel 2 : Zie- le und QS-Ma ß nahmen werden die Begriffe definiert und anhand zweier Beispielserien erörtert. Kapitel 3 : Software Engineering Modelle stellt einen beispielhaften Überblick zu Modellen der unterschiedlichen Modellarten bereit. Dies soll zum Einen die Komple- xität von Softwareentwicklungsprojekten aufzeigen. Zum Anderen werden diese Modelle benötigt, um die Methode für Softwarequalität in Kapitel 6 zu evaluieren.
In Kapitel 4 : Stand der Forschung wird sowohl auf aktuelle, als auch auf altbekann- te Publikationen zur Modellierung von Softwarequalität eingegangen. Unter dem Ge sichtspunkt der Fragen ”Wozu?Wo?Wann?Wer?Wie?“werdenhiernebendembe kannten GQM Ansatz auch aktivitätenbasierte, produktbasierte und spezialisierte Qualitätsmodelle bezüglich ihrer Eignung untersucht. Für den geeignetsten Ansatz werden schließlich Strategien zur Implementierung in einem Unternehmen vorgestellt.
Der Hauptteil der Arbeit beginnt zunächst, indem die Vor- und Nachteile des geeig- netsten Ansatzes in das Kapitel 5 : Multidimensionale Qualitätsziele und integrierte QS- Ma ß nahmen einfließen. Im Anschluss daran werden schematische Modelle für die Qua- litätsziele und QS-Maßnahmen gezeigt. Für eine Werkzeugunterstützung werden diese schematischen Modelle zu konzeptionellen Datenmodellen verfeinert. Neben der Metho- de für den Umgang mit den Zielen und QS-Maßnahmen werden auch die Schritte des kontinuierlichen Verbesserungsprozesses in einer Prozessnotation modelliert. Das Funk- tionieren der vorgestellten Methode wird in Teilen in Kapitel 6 : Evaluation mit Hilfe von Szenarien und Studierenden gezeigt. Für die Evaluation mit einer Studierendengruppe dient das Scope Statement eines fiktiven Bäckereiprojekts aus Anhang A. In Anhang B werden für das Bäckereiprojekt multidimensionale Qualitätsziele in einem Excel Templa- te gezeigt. Anhang C zeigt eine konstruktive QS-Maßnahme einer frühen Version eines QSM Katalogs.
In Kapitel 7 : Ausblick werden schließlich die nachfolgenden Schritte aufgezeigt. Darunter zählt auch das Entwickeln eines Systems auf der Grundlage zweier Prototypen. Anhang D zeigt Screenshots der Prototypen.
Da das Thema der Softwarequalität facettenreich ist, sind alle Beteiligten von Softwareentwicklungsprojekten an dem Schaffen derselben beteiligt. Aus diesem Grund richtet sich diese Arbeit nicht ausschließlich an Qualitätsmanager, sondern auch an Nutzer, Tester, Entwickler, Architekten, Projektleiter und Manager.
2 Ziele und QS-Maßnahmen
2.1. Definitionen
An dieser Stelle werden die Definitionen eingeführt, die für das Verständnis der weiteren Abschnitte nötig sind.
Für das Anliegen dieser Arbeit, multidimensionale Qualitätsziele zu formulieren, wird die Zieldefinition von Basili, Caldiera und Rombach [BCR94, S.3f] herangezogen. Abbildung 2.1 stellt den modifizierten Zielbegriff grafisch dar.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.1.: Definition des Begriffs Ziel
Ein Qualitätsziel ist eine Abbildung in einen Zielraum, der durch die Dimensionen Qualität, Ergebnistyp, Prozess und Rolle aufgespannt wird. Diese Abbildung beschreibt das Ziel selbst und verknüpft es mit QS-Maßnahmen, die für sein Erreichen relevant sind. Mehrere Qualitätsziele bilden einen Qualitätsplan.
QS-Ma ß nahmen untergliedern sich in analytische und konstruktive Maßnahmen.
Eine analytische QS-Ma ß nahme (aQSM) ist eine Tätigkeit zum Bewerten der Qualität. Sie dient zur Erkennung und Lokalisierung von Mängeln und Fehlern im weitesten Sinne [Wal01, S.31]. Bezüglich eines Qualitätsziels resultiert aus einer aQSM eine Aussage zu potentiellen Chancen oder Risiken, welche die Zielerreichung positiv bzw. negativ be- einflussen. 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ät, die durchgeführt wird, um Qualität präventiv zu sichern. Sie soll das Entstehen von Fehlern und Mängeln 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örtert. Pro Ziel wird lediglich eine analytische sowie eine konstruktive QS-Maßnahme benannt.
Ziel Abbildung 2.2 zeigt ein Qualitätsziel mit der Absicht, den Benzin verbrauch während einer Fahrt mit einem Kleinwagen im Straßen verkehr zu minimieren. Wenn an einer roten Ampel gehalten werden muss, soll das Ziel durch das Fahrzeug erreicht werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.2.: Autofahrziel I
aQSM Die Fahrzeugtechnik berechnet den aktuellen und durchschnittli chen Verbrauch. Sobald der aktuelle Verbrauch über 6 Litern und der durchschnittliche Verbrauch über 3 Litern liegt, erscheint im Bordcomputer eine Anzeige.
kQSM Als vielversprechende Prävention tritt die ECO Start-Stopp Funktion auf, da sie den Motor abschaltet, nachdem das Fahrzeug an einer roten Ampel zum Stehen gekommen ist.
2.2. Beispielserie: Benzinverbrauch minimieren
Ziel In Abbildung 2.3 wird ein neues Ziel definiert, indem die Rolle gewechselt wird. Jetzt soll die Absicht der Verbrauchsminimierung aus der Sicht des Fahrers verfolgt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.3.: Autofahrziel II
aQSM Der Fahrer prüft im Bordcomputer, ob der aktuelle Verbrauch unter 6 Litern liegt. Nach Fahrtende prüft er, ob der durchschnittliche Verbrauch unter 3 Litern lag.
kQSM Sofern möglich, sollte der Fahrer das Fahrzeug bis zur Ampel aus- rollen lassen, mit so wenig Bremsvorgängen wie möglich zum Stehen kommen und beim Umschalten auf grün langsam wieder anfahren.
Ziel In Abbildung 2.4 wird ein neues Ziel dargestellt, indem ein an- derer Prozess betrachtet wird. Die Minimierung des Verbrauchs während einer Fahrt im Straßenverkehr soll aus Sicht des Fahrers beim Durchfahren einer Kurve stattfinden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.4.: Autofahrziel III
aQSM Es gilt die analytische Maßnahme des vorangegangenen Ziels.
kQSM Sofern die Situation es zulässt, sollte die Kurve ohne Bremsmanöver durchfahren werden, so dass so wenig Reisegeschwindigkeit wie möglich verloren geht. Nach der Kurve sollte der Fahrer langsam beschleunigen, bis die Reisegeschwindigkeit wieder erreicht ist.
Ziel Das nächste, in Abbildung 2.5 aufgezeigte Ziel wird durch einen neuen Ergebnistyp erzeugt. Der Verbrauch soll durch den Fahrer in Kurvenfahrten während eines Formel 1 Rennens minimiert werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.5.: Autofahrziel IV
aQSM Als Maßnahme gilt auch hier das Beobachten des Verbrauchs im Bordcomputer - jedoch mit einem höheren Schwellwert.
kQSM Die hier zu treffende Maßnahme ist identisch mit der Maßnahme, die der Fahrer im Straßenverkehr ergreifen würde.
Ziel Da Formel 1 Rennen gewonnen werden wollen, wird in Abbildung 2.6 eine der wichtigsten Absichten für ein Rennfahrzeug der Formel 1 gezeigt. Im dargestellten Ziel soll die Rundenzeit durch den Fahrer in Kurven minimiert werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.6.: Autofahrziel V
aQSM Nach Beenden einer Runde prüft der Fahrer im Bordcomputer die durchschnittliche Rundenzeit. Wenn die Zeit der abgeschlossenen Runde unter dem Durchschnitt liegt, wurde bezüglich der Absicht eine bessere Runde gefahren.
kQSM Als Maßnahme muss der Fahrer mit der maximal möglichen Ge schwindigkeit an die Kurve heranfahren, stark auf die optimale Kur- vengeschwindigkeit abbremsen und nach der Kurve so schnell wie möglich auf die höchstmögliche Geschwindigkeit beschleunigen.
Die Beispiele deuten an, dass das Erreichen von Qualitätszielen kein Zufall ist. Für jedes Ziel existieren konstruktive Maßnahmen, die zu einer guten Qualität führen sollen. Damit bestimmt werden kann, ob diese konstruktiven Maßnahmen tatsächlich zielführend sind, muss ihre Wirksamkeit durch analytische Maßnahmen nachgewiesen werden.
Die Absichten Benzinverbrauch minimieren und Rundenzeit minimieren zeigen auf, dass Zielkonflikte entstehen können. Das heißt, dass das Erreichen des einen Ziels das Errei- chen eines anderen Ziels ausschließen oder zumindest negativ beeinflussen kann. Dieser Umstand wird anhand der konstruktiven QS-Maßnahmen für das Erreichen der Beispiel- ziele aus der Formel 1 deutlich. Wenn der Fahrer auf den Benzinverbrauch achten soll, muss er die Kurve möglichst bremsfrei mit der Kurvengeschwindigkeit erreichen und mit einer langsamen Beschleunigung wieder verlassen. Im Gegensatz dazu muss er für eine geringe Rundenzeit scharf bremsen und die Kurve stark beschleunigend wieder verlassen. Beide Maßnahmen können nicht gleichzeitig durchgeführt werden.
Desweiteren wird ersichtlich, dass der Ergebnistyp die Priorisierung des Qualitätsziels beeinflusst. Die Minimierung des Benzinverbrauchs stellt im Straßenverkehr für 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ügung, die das Erreichen eines Ziels fördern. Der Fahrer prüft, ob er durch sein Fahrverhalten für oder gegen das Erreichen wirkt. Das zeigt, dass QS-Maßnahmen durch Rollen durchgeführt werden. Ziele gelten immer für Rollen.
QS-Maßnahmen können für 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ührt. Für den Kleinwagen liegt der Schwellwert für einen minimalen Benzinver- brauch bei 3 Litern pro 100 Kilometern. In der Formel 1 ist von einem deutlich höheren Schwellwert auszugehen. Dieser Umstand führt zu der Erkenntnis, dass der erwartete Wert für die Beschreibung einer analytischen Maßnahme vorerst keine Rolle spielt.
2.3. Beispielserie: Softwarequalitätsziele
Die unterschiedlichen Modellarten der Softwarewelt bilden die Dimensionen von Qualitätszielen wie in Abbildung 2.7 dargestellt. Qualitätsmerkmale entspringen aus Qualitätsmodellen im gleichen Sinne, wie Ergebnistypen und Prozesse durch Modelle beschrieben werden. Auch die Rollen entstammen aus hierarchischen Modellen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.7.: Modelle als Zieldimensionen
Zieldimension Qualität. Wie für das Beispiel der Autofahrt gilt auch für ein Softwa- requalitätsziel, dass es eine bestimmte Absicht verfolgt. Im Bereich der Softwareent- wicklung stellen Qualitätsmodelle wie die ISO/IEC 9126 Merkmale bereit, welche die Produktqualität beschreiben. Die aus den Merkmalen resultierenden Absichten liegen beispielsweise in dem Bereitstellen der relevanten Funktionalität, dem Erreichen einer hohen Zuverlässigkeit oder dem Sicherstellen einer einfachen Wartbarkeit.
Zieldimension Ergebnistyp. Ein Softwareprodukt besteht aus einer Vielzahl von Arte- fakten und adressiert eine Produktdomäne. In der Domäne der betrieblichen Informa- tionssysteme wird zwischen SAP- und Individualsoftware unterschieden. Diese werden zunächst durch Anforderungsdokumente beschrieben und später in ein Produktivsystem überführt. Ein Testsystem prüft schließlich, ob die Anforderungen im Produktivsystem richtig umgesetzt wurden. Die Unterscheidung zwischen SAP- und Individualsoftware ist nötig, da davon auszugehen ist, dass nicht die gleichen Maßnahmen gelten müssen. Das Sicherstellen einer einfachen Änderbarkeit 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 Ent- wicklungsprozess teilt sich in die Phasen Planen, Entwerfen, Umsetzen und Testen auf. Zwischen den Phasen liegen Übergabepunkte, in denen die erarbeiteten Ergebnistypen geprüft werden.
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ätsmerkmal, 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ür die Softwarequalitätssicherung beispielhaft bottomup ermittelt. Dazu wird zuerst eine konstruktive sowie eine passende analytische QSMaßnahme zur Anzeige möglicher Probleme benannt und im Anschluss ermittelt, welches Ziel die beiden QS-Maßnahmen adressieren.
kQSM Im Falle des Ersetzens eines Altsystems werden die häufig genutzten Funktionen und ihr Zeit- und Verbrauchsverhalten in Gesprächen mit dem Kunden systematisch abgefragt und protokolliert.
aQSM Der Kunde führt ein Review über das Pflichtenheft durch. Er prüft, ob alle fachlichen Funktionen des Altsystems im Pflichtenheft auf- geführt sind. Zudem prüft er, ob die nichtfunktionalen Anforderun- gen konkret beschrieben wurden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.8.: Softwarequalitätsziel I
Ziel In Abbildung 2.8 wird das durch die konstruktive Maßnahme Analy se des Altsystems verfolgte Ziel dargestellt. Neben der funktionalen Vollständigkeit fördert diese Maßnahme die Effizienz des zu ent- wickelnden Produkts, da konkrete nichtfunktionale Anforderungen für die nachfolgenden Entwicklungsphasen zur Verfügung gestellt werden. Durch die analytische Maßnahme Review des Pflichten- hefts wird ermittelt, ob die Anforderungen vollständig und konkret übernommen wurden.
kQSM Anfertigen eines Prototypen in einem technischen Durchstich.
aQSM Der Entwickler führt ein Technologiereview durch, um den Proto typen bezüglich des Einsatzes in der Systemlandschaft des Kunden zu bewerten. Während der Ausführung des Prototypen prüft er im Entwicklertest, ob gravierende Abweichungen zu den im Pflichtenheft beschriebenen Performanceanforderungen auftreten.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.9.: Softwarequalitätsziel II
Ziel In Abbildung 2.9 wird das durch die konstruktive Maßnahme An fertigen eines Prototypen verfolgte Ziel dargestellt. Durch die analytische Maßnahme Prototyp inspizieren und testen wird bereits in frühen Phasen festgestellt, ob die eingesetzten Technologien die nichtfunktionalen Anforderungen tragen können.
kQSM Testfälle von Anwendungsfällen ableiten und die Rückverfolgung der Testfallherkunft sicherstellen.
aQSM Der Tester führt ein vergleichendes Review des Pflichtenhefts und der Testfälle durch. Er prüft, ob sich die konkreten Anforderungen in den Testfällen widerspiegeln.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.10.: Softwarequalitätsziel III
Ziel In Abbildung 2.10 wird das durch die Maßnahme Testfälle von An wendungsfällen ableiten verfolgte Ziel dargestellt.
3 Software Engineering Modelle
Modelle werden in der Informatik genutzt, um die Realität 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 Überblick der Softwareziele aus Abbildung 2.7 müssen vier Modellarten berücksichtigt werden.
Wozu? - Qualitätsmodelle! Ein Qualitätsmodell enthält Merkmalsgruppen, die über Merkmale zu Metriken verfeinert sind und die Qualität eines Softwareprodukts beschreiben. Für den Zielbegriff stellt Qualität die zu verfolgende Absicht dar, indem ein bestimmtes Merkmal erreicht werden soll.
Wo? - Ergebnistypmodelle! Ein Ergebnistyp beschreibt ein Artefakt des Entwicklungs- prozesses. 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äufig der Übergang zur nächsten Phase.
Wer? - Rollenmodelle! Rollenmodelle beschreiben Hierarchien aus Aufgaben, Kompotenzen und Verantwortlichkeiten. Bezogen auf den Zielbegriff beantworten Rollenmodelle die Frage, für 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ötigt werden, um die Wiederverwendbarkeit von Modellen im multidimensionalen Zielraum zu zeigen.
3.1. Qualitätsmodelle
Ein Qualitätsmodell stellt eine Hierarchie von abstrakten Merkmalsgruppen, konkreten Merkmalen und messbaren Attributen zur Verfügung, die durch schrittweise Verfeinerung an das zu beschreibende Umfeld angepasst werden [FC02, S.2].
In diesem Zusammenhang beschreibt der durch Jim McCall formulierte FCM (Factor/Criteria/Metrics) Ansatz [MRW77] ein Metamodell, mit dessen Hilfe Qualitätsmodelle gemäß der oben genannten Definition erarbeitet werden können. Faktoren beschreiben die abstrakten Merkmalsgruppen, welche zu Kritieren verfeinert werden. Diese Kriterien beschreiben die konkreten Merkmale. Die Kriterien werden schließlich im nächsten Verfeinerungsschritt mit Hilfe von Metriken operationalisiert.
FCM bildet die Grundlage vieler Softwarequalitätsmodelle, wie dem ISO/IEC 9126 Standard für Softwareproduktqualität oder dem Capgemini sd&m Software-Blutbild als Beispiel für ein unternehmensspezifisches Qualitätsmodell.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.1.: Oben: FCM, unten: GQM
Ein weiteres Metamodell ist Teil des durch Basili, Rombach und Caldiera veröffentlichten GQM (Goal/Question/Metric) Ansatzes [BCR94]. GQM zielt auf die top-down Implementierung der Qualitätsmodellierung in die Unternehmensabläufe ab. Im ersten GQM-Schritt werden Qualitätsziele festgelegt. Da Ziele noch sehr abstrakt sind, werden sie durch Fragen konkretisiert. Die Fragen werden analog zu den Kriterien aus FCM durch Metriken operationalisiert.
3.1.1. Beispiel: ISO/IEC 9126
In der ISO/IEC 9126 wird zwischen den 6 Merkmalsgruppen Funktionalität, Zuverlässig keit, Benutzbarkeit, Effizienz, Änderbarkeit sowie Übertragbarkeit unterschieden. Im Anhang der Norm befindet sich ein Vorschlag für die Merkmalsverfeinerung. Messbare Attribute werden nicht beschrieben. Abbildung 3.2 zeigt eine grafische Repräsentation des Aufbaus der ISO/IEC 9126.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.2.: Aufbau der ISO/IEC 9126
In Hinblick auf FCM beschreiben die Merkmalsgruppen Faktoren. Die vorgeschlagenen Merkmale jeder Merkmalsgruppe dienen als Kriterien. Die Verfeinerung gemäß FCM wird nicht bis zur Metrikebene durchgeführt, 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änenübergreifend Zielgruppen anspricht, es somit weit verbreitet und sehr langlebig ist. Die aktuelle Quamoco Studie zeigt, dass Un- ternehmen vorwiegend eigene Qualitätsmodelle einsetzen [WLW+10, S.6]. Häufig dient die ISO/IEC 9126 aber als Vorlage für diese unternehmensspezifischen Modelle.
3.1.2. Beispiel: ISO/IEC 9126 im Test
Die ISO/IEC 9126 beschreibt die Produktqualität von Softwaresystemen. Dies führt dazu, dass sie nicht direkt im Test anwendbar ist. Da die Norm allerdings häufig als Ausgangsbasis für das Formulieren angepasster Qualitätsmodelle verwendet wird, wurde sie auch in [ZVS+07] für die Definition eines Qualitätsmodells für den Test herangezogen. Diese Anpassung ist in Abbildung 3.3 dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.3.: Für den Test angepasste ISO/IEC 9126 [ZVS+07, S.234]
Die vorhandenden Merkmalsgruppen des Ursprungsmodells wurden im Kontext des Tes- tens reinterpretiert. Die Gruppe Funktionalität wurde zu Testeffektivität umbenannt. Da das Ursprungsmodell nicht die Wiederverwendbarkeit auf Gruppenebene berücksichtigt, haben die Autoren des Testqualitätsmodells hierfür eine zusätzliche Merkmalsgruppe eingeführt.
Obwohl in [ZVS+07, S.237ff] einige Metriken für die Merkmale der Merkmalsgruppen Testeffektivität, Änderbarkeit und Wiederverwendbarkeit definiert werden, beschreibt das dargestellte Qualitätsmodell ein FC-Modell, da gemäß FCM lediglich Faktoren und Kriterien vollständig definiert wurden. Wie bei der ISO/IEC 9126 wird hier kein vollständiger Satz an Standardmetriken bereitgestellt, so dass diese für eine Anwendung des Modells erst definiert werden müssen.
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ür die Qualitätssteuerung zu erreichen, werden sowohl das Produkt, als auch der Entwicklungsprozess beleuchtet. Im gewissen Sinne werden damit zwei Qualitätsmodelle zu einem Modell vereint.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.4.: Capgemini sd&m Software-Blutbild [Hof08, S.20]
Gemäß 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ässigkeit 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ässt es sich mit Qualitätsmodellen anderer Beteiligten, wie z.B. dem Kunden, verbinden.
3.2. Ergebnistypmodelle
Ein Softwareprodukt entsteht nicht von heute auf morgen. Vielmehr durchläuft es einen Lebenszyklus, in dem es aus einem Entwicklungsprozess heraus entsteht und über 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.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.5.: Ergebnistypmodelle im Lebenszyklus einer Software
Anforderungen. Am Anfang besteht das Softwareprodukt aus Anforderungen. Diese ent- halten in einem Pflichtenheft die konkreten Anwendungsfälle, welche als Modell der Funktionalität des zu entwickelnden Produkts in frühen Phasen auftreten. Die nicht- funktionalen Anforderungen werden in einem Qualitätsplan dokumentiert, der entweder als eigenständiges Dokument oder als Bestandteil des Pflichtenhefts erarbeitet wird.
Entwicklersystem. Im Entwicklersystem werden die Anforderungen des Kunden in ein lauffähiges System überführt. Dazu wird zunächst ein architekturelles Modell des Systems erstellt, das in der Lage ist, sowohl den funktionalen, als auch den nichtfunktionalen Ansprüchen des Kunden gerecht zu werden. Die Implementierung füllt den architekturellen Rahmen schließlich mit der eigentlichen Funktionalität. Als wesentlicher Teil des Produktivsystems sollte auch für die Dokumentation gelten, dass sie einer einheitlichen Struktur, also einem Modell unterliegt.
Testsystem. Der Test dient der Überprüfung, ob die Anforderungen durch das Produk- tivsystem erfüllt werden. Wegen des hohen Anteils des Testaufwands am Gesamtent- wicklungsaufwand darf das Testsystem nicht als Nebenprodukt betrachtet werden.
Produktivsystem. Das Produktivsystem läuft in der realen Umgebung mit echten Daten. Nach der initialen Entwicklung und dem ersten Start definiert die Wartungsstragie die nötigen Schritte für das Einbinden von neuen Anforderungen.
3.2.1. Beispiel: Anwendungsfallmodell
Anwendungsfälle werden in der Spezifikationsphase im Rahmen der Erarbeitung von Produktfunktionen für das Pflichtenheft erstellt [Bal96, S.104]. Sie beschreiben die durch ein Softwaresystem bereitzustellende Funktionalität. Leider hat sich bis heute noch kein einheitliches und konkretes Modell für Anwendungsfälle (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.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.6.: Struktur eines Anwendungsfalls nach [Fro09, S.25f]
Akteur. Da Anwendungsfälle selten nicht von ihrer Umgebung abhängen, 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 errei- chen. Erfolgsszenarien beschreiben den geraden Weg zum Ziel, in dem keine Spezial- und Fehlerfälle auftreten. Die Sonderfälle werden in den Alternativszenarien behandelt.
Nichtfunktionale Anforderungen. NFAs betreffen Aussagen bezüglich nichtfunktionaler Qualitätsmerkmale wie Effizienz oder Wartbarkeit aus der ISO/IEC 9126. Sie werden im Anwendungsfall dokumentiert, wenn sie ihn direkt betreffen. Allgemeine NFAs können beispielsweise im Qualitätsplan aufgeführt werden.
3.2.2. Beispiel: Architekturmodell
Für den Begriff Softwarearchitektur existieren viele unterschiedliche, teilweise widersprüchliche 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ührten, textuellen Definition.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.7.: Architekturmetamodell gemäß [VAC+09, S.47]
Im Hinblick auf die Softwarebausteine, bzw. Softwarekomponenten, gibt es unterschiedli- che Möglichkeiten der Realisierung des Metamodells zu einem Modell. Der architektoni- sche Schnitt einer Anwendung enthält 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ätsarchitektur führten sie Softwa- reblutgruppen [SD00, S.248f] ein. Die Blutgruppen sortieren die Softwarearten bezüglich ihrer Wiederverwendbarkeit in 0-, A-, T-, AT- sowie R-Software. 0-Software ist un- abhängig vom Kontext und kann immer wiederverwendet werden. A-Software beschreibt die Fachlogik, T-Software die technische Lösung. Software, die fachliche und technische Aspekte implementiert, wird als AT-Software bezeichnet. AT-Software schränkt die Wie- derverwendbarkeit stark ein. R-Software ist die milde Form von AT-Software. Sie befasst sich mit der Transformation der fachlichen Objekte in ihre externe Repräsentation.
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ür die Anwendungsfälle gilt auch für Testfälle, dass sich noch kein einheitliches Modell durchgesetzt hat [SBS09, S.84] und Testfälle in der Praxis häufig in Tabellenform dokumentiert werden. Der spezifische Teil des Modells aus dem Buch ist in Abbildung 3.8 dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.8.: Attribute eines Testfalls nach [SBS09, S.91]
Spezifischer Testfall. Ein Testfall sollte aus den Attributen der obigen Abbildung beste- hen. Der Typ zeigt an, ob der Testfall manuell oder automatisiert auszuführen ist. Die Quelle besagt, wovon der Testfall abgeleitet wurde. Der Auslöser beschreibt das Ereignis, das den Testfall auslöst. Außerdem wird die Verbindung zu den geprüften Anforderun- gen und Anwendungsfällen dokumentiert. Da jeder Test über einen bestimmten Teil des Prüflings ausgeführt wird, wird im Testfall auch das Testobjekt explizit dokumentiert.
Testszenarien. Ein Testszenario entsteht durch das Aneinanderreihen von Testfällen.
Testdaten. Eingabedaten werden dem Testfall zur Ausführung als Argumente übergeben. Ausgabedaten sind die erwarteten Ergebnisse, die nach der Ausführung 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.
3.3. Prozessmodelle
Mit Hilfe von Prozessen werden Unternehmensabläufe beschrieben. Abbildung 3.9 zeigt den Aufbau von Prozessmodellen. Ein Prozess wird in Teilprozesse mit Ein- und Ausga- ben aufgegliedert. Die Ausgabe eines Teilprozesses ist die Eingabe nachfolgender Prozes- se. Das dadurch zustande kommende interne Kundenverhältnis 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 Prozessland- schaft eines Unternehmens, sie bieten jedoch noch keine konkreten, durchzuführenden Schritte. Für die weitere Verfeinerung bietet die BPMN (Business Process Modeling No- tation) ein Werkzeug, mit dem die abstrakten Teilprozesse zu konkreten Schritten mit Entscheidungszweigen sowie Ein- und Ausgaben verfeinert werden können.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.9.: Teilprozesse mit Übergabeobjekt und Quality Gate (QG)
Am oben beschriebenen, internen Kundenverhältnis wird ersichtlich, dass die Qualität über den gesamten Prozess sichergestellt werden muss, da der Erfolg des nachfolgenden Teilprozesses von den übergebenen Ergebnistypen abhängt. Die wichtigsten Ergebnisse des vorangegangen Prozesses müssen in diesem Zusammenhang während einer Abnahme einer Qualitätskontrolle unterzogen werden. Eine Methode zur Sicherung der Qualität stellt in diesem Zusammenhang das Konzept der Quality Gates (QGs) dar.
Im Folgenden werden das konventionelle Wasserfallmodell, der ISTQB Testprozess und der agile SCRUM Prozess kurz beschrieben. Die Bescheibung beschränkt sich jeweils auf die Teilprozesse. Das heißt, dass die Ein- und Ausgaben ausgeblendet sind.
3.3.1. Beispiel: Wasserfallmodell
Das von Royce 1987 veröffentlichte Wasserfallmodell [Roy87] ist in Abbildung 3.10 dargestellt. Das Alter des Modells und dessen breite Anwendung lässt erahnen, warum es als das konventionelle Modell bekannt ist.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.10.: Wasserfallmodell [Roy87, S.329] mit QGs
Anforderungsanalyse. Die Grundlage eines Softwareprojekts sind die Anforderungen des Kunden. Falls ein Altsystem ersetzt werden soll, liefert dessen Analyse wertvolle Erkenntnisse für das neue Produkt. Da die funktionalen und nichtfunktionalen Anforderungen für alle Nachfolgephasen relevant sind, liegt auf ihnen der Fokus des QG.
Design. Während des Systementwurfs wird eine Softwarearchitektur erstellt. Die Architektur muss sowohl das fachlichen Konzept widerspiegeln, als auch das Erfüllen der konkreten nichtfunktionalen Eigenschaften ermöglichen. Anhand eines prototypischen technischen Durchstichs kann am QG die Fähigkeit der Architektur zum Erfüllen der Anforderungen geprüft 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ösen Überraschungen warten, muss die Programmierung kontinuierlich überwacht werden.
Test. Der Test ist eine analytische Maßnahme, mit der bereits entstandene fachliche Fehler gefunden und Verfehlungen der nichtfunktionalen Anforderungen aufgedeckt werden sollen. Durchzuführende konstruktive QS-Maßnahmen können hier dazu führen, dass das Produkt gut testbar ist und weniger Fehler enthält.
Betrieb. Wenn das Softwareprodukt schließlich bezüglich der Anforderungen real beansprucht wird, wird Softwarequalität plötzlich für jeden sichtbar.
Zum Ende dieses kurzen Überblicks bleibt zu erwähnen, dass die Planungs- und Projektmanagementphase in dieser frühen Version des Modells noch fehlt.
3.3.2. Beispiel: SCRUM - Agiles Entwicklungsmodell
Ken Schwaber schrieb 1995 [Sch95, S.2], dass konventionell durchgeführte Projekte häufig so behandelt werden, als wäre 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.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.11.: SCRUM Entwicklungsprozess nach [Sch95] mit QGs
SCRUM Start. In der Startphase werden die definierten Planungs- und Designprozesse eines konventionellen Prozesses ausgeführt. Die Prozesse und QGs entsprechen beispielsweise den frühen 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ärung der Verfügbarkeit des Teams die zu bearbeitende Aufgabe so geschnitten werden, dass das Team die aufeinanderfolgenden Sprints durchhält.
Daily SCRUM, Daily Work. An jedem Morgen wird ein 15-minütiges SCRUM-Meeting durchgeführt, in dem jeder vorträgt, 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önnen. Deshalb findet die tägliche 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ähiges Sprint-Ergebnis beispielsweise an die Testphase des Wasserfallmodells weitergereicht wird.
3.3.3. Beispiel: Testprozessmodell gemäß 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ätzlichen Methoden und Werkzeugen rund um den Test auch der fundamentale Testprozess [SL04, S.18ff] beschrieben. Der in Abbildung 3.12 darge- stellte Testprozess verfeinert den entsprechenden Teilprozess des Wasserfallmodells aus Abbildung 3.10. Der fundamentale Testprozess entspringt der IEEE 829.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.12.: Fundamentaler Testprozess [SL04, S.18] und [SBS09, S.12] mit QGs
Testplanung und -steuerung. Die Testplanung ist der Beginn jedes Testprojekts. Sie resultiert in einem Testkonzept, das den Ablauf des Tests beschreibt. Im Rahmen der Teststeuerung wird das Testprojekt gemäß des Testkonzepts gelenkt und überwacht. Am QG wird das Testkonzept bezüglich seiner Durchführbarkeit geprüft.
Testspezifikation. In der Spezifikationsphase werden die funktionalen und nichtfunktionalen Anforderungen aus der Analysephase des Wasserfallmodells in Testfälle überführt. Am QG kann geprüft werden, ob die spezifizierte Testfälle der Priorisierung der Anwendungsfälle entsprechen.
Testdurchführung. Während der Testdurchführung werden die in der Testspezifikation erstellten Testfälle angewendet. Am QG kann beispielsweise geprüft werden, ob und wie oft jeder Testfall ausgeführt wurde.
Testprotokollierung. Die Ergebnisse der Testdurchführung werden protokolliert und Fehler in die Fehlerdatenbank eingetragen. Für jeden Fehler ist ein Retest nötig, um zu prüfen, ob er tatsächlich behoben wurde. Neben der Anzahl der gefundenen Fehler kann die Retestquote zur Bewertung am QG herangezogen werden.
Testauswertung. In der Testauswertung werden die Testdurchläufe ausgewertet und Statistiken zu Testabdeckung, Fehlerarten und -anzahl erstellt. Der Testabschlussbericht hält Ergebnisse und Erfahrungen des Testprojekts fest.
3.4. Rollenmodelle
Ein Rollenmodell beschreibt die Hierarchie, in der ein Projekt bezüglich 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.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.13.: Rollenmodell als Organigramm
In Organisationen mit einer flachen Hierarchie treten demnach kürzere, vertikale aber dafür längere, horizontale Wege auf. Bei einer tiefen Hierachie kehrt sich dies um.
Die horizontale Kommunikation überschreitet Abteilungsgrenzen und findet entlang des Wasserfallmodells statt. Die Anforderungen des Fachbereichs müssen beispielsweise über den internen IT-Bereich unmissverständlich an den Zulieferer gereicht werden. Das Überführen der Anforderungen über eine Architektur in das produktive Softwaresystem findet beim Zulieferer dann vertikal statt.
In diesem Abschnitt wird ein Überblick zu den oberen Hierarchien entlang einer verteilten Projektorganisation aufgezeigt. Zudem wird etwas genauer auf die Entwickler- und Testrollen eingegangen.
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ür einen Überblick 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.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.14.: Rollen entlang des Wasserfalls
Kundenrollen. In großen Organisationen wird Software für einen konkreten Fachbereich entwickelt, dessen Arbeit unterstützt werden soll. Die interne IT-Abteilung tritt dabei als Schnittstelle zwischen dem Fachbereich und den externen Entwicklern auf. Ein Beispiel für 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üglich 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ängiger Seite durchgeführt wird, liegt die Auslagerung des Tests an einen weiteren Dienstleister nahe. Auch ein Testunternehmen wird die Rollen besetzen - zum Beispiel gemäß ISTQB.
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öglicht es mehreren Teams autonom zu arbeiten. Abbildung 3.15 zeigt das in [Glo10, S.196f] beschriebene Rollenmodell.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.15.: SCRUM Rollenmodell
SCRUM Master. SCRUM Master sind kein Mitglied der autonomen Zellen. Sie stellen die nötigen Rahmenbedingungen her und sorgen für den korrekten Ablauf des Prozesses. Hinsichtlich der externen Rollen treten sie als Schnittstelle auf.
Product Owner. Der Product Owner übernimmt die fachliche Steuerung einer SCRUM Zelle. Er entscheidet, in welcher Reihenfolge die Arbeitspakete des Sprints abgearbeitet werden, hält sich jedoch bei Entscheidungen um die technische Realisierung zurück.
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ändig durchzuführen.
3.4.3. Beispiel: Testrollen gemäß ISTQB
Die Aufzählung der idealen Besetzung eines Testteams aus dem Buch Basiswissen Softwaretest [SL04, S.147f] wird als Organigramm in Abbildung 3.16 dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.16.: ISTQB Testrollen gemäß [SL04, S.147f]
Testmanager. Der Testmanager plant und steuert das Testprojekt.
Testdesigner. Der Testdesigner spezifiziert Testfälle. Dies schließt neben der Formulierung der konkreten Testfälle auch deren Verwaltung ein. Der Designer kommuniziert vertikal mit den Automatisierern und horizontal mit den Testern.
Testautomatisierer. Der Automatisierer wandelt die spezifizierten Testfälle in Testskripte um. Er kommuniziert vertikal mit den Designern und horizontal mit den Testern und den Administratoren.
Testadministrator. Der Administrator führt die Testumgebung ein, die ein Tester benötigt, um seine Arbeit zu erledigen und stellt ihren reinbungslosen Betrieb sicher.
Tester. Der Tester führt die spezifizierten Testfälle durch, erstellt Fehlerberichte und die Auswertung des Testdurchlaufes.
Es fällt auf, dass in dem von Spillner und Linz vorgeschlagenen Modell noch Rollen bezüglich der Fehler- und Testdatenverwaltung fehlen.
4 Stand der Forschung
Dieses Kapitel fasst wissenschaftliche Publikationen zusammen, welche Qualitätsmodelle, ihre Anpassung und Anwendung vorstellen. Um sicherzustellen, dass die vorgestellten Modelle und Methoden praktisch anwendbar sind, gelten in Abschnitt 4.1 für die Auswahl der Publikationen einige Kriterien.
Aktualität. Es sollen aktuelle Ideen und Studien betrachtet werden, d.h. die Veröffentlich- ung sollte um das Jahr 2000 stattgefunden haben. Bis auf den GQM Ansatz ist dieses Kriterium für alle Ansätze erfüllt, wobei sich Ideen von GQM in den neuen Ansätzen wiederfinden.
Praktische Relevanz. Die Modelle und Methoden müssen im praktischen Umfeld angewendet worden sein - am Besten in großen Organisationen. Dieses Kriterium wird bis auf QUIM durch alle vorgestellten Ansätze erfüllt.
Akademische Verbreitung. Die Papers, aus welchen die vorgestellten Ansätze stammen, sollen in der wissenschaftlichen Welt verbreitet sein, d.h. dass sie häufig referenziert werden.
In Abschnitt 4.2 werden die Ansätze in einer Übersicht zusammenfassend gegenüberge stellt und bestimmt, inwiefern die Konzepte für die Beantwortung der Fragen ”Wozu?
Wo? Wann? Wer? Wie?“ geeignet sind. Schließlich werden in Abschnitt 4.3 Veröffentlichungen vorgestellt, welche die Anwendung des geeignetsten Ansatzes behandeln.
4.1. Anpassen von Qualitätsmodellen
In diesem Abschnitt werden gemäß der obigen Kriterien aktivitätenbasierte, produktba- sierte, spezialisierte und zielorientierte Qualitätsmodelle vorgestellt. Bezüglich der An passung kann bei Qualitätsmodellen grundsätzlich zwischen den Eigenschaften your-own-model“ und ”define ”fixed-model“unterschiedenwerden[KLTM[10],S.1]. ”Fixed“Qua litätsmodelle entsprechen den vorgestellten spezialisierten Qualitätsmodellen. Sie können zwar nur für einen bestimmten Zweck in einem abgesteckten Umfeld angewendet werden, müssen dafür aber nicht oder nur wenig angepasst werden. Die vorgestellten aktivitätenbasierten, produktbasierten und zielorientierten ”define-your-own“Modelle verfügen neben einem Metamodell über eine Anpassungsmethode, durch welche das Modell für den Projektkontext definiert wird.
Jeder der folgenden Abschnitte ist gleich aufgebaut. Zunächst wird das Modell kurz beschrieben und geklärt, in welchem praktischen Umfeld es bereits Anwendung gefunden hat. Für jeden Ansatz wird bewertet, inwiefern die eingangs gestellten Fragen Wo? Wann? Wer? Wie?“ beantwortet werden können. ”Wozu? Welche Probleme existieren in bestehenden Ansätzen? In diesem Abschnitt werden Aussagen der Autoren der jeweiligen Veröffentlichung aufgezählt, aus welcher Motivation heraus der neue Ansatz formuliert wurde.
Wie werden die Probleme gelöst? Hier werden die Strategien der Autoren für die Lösung der zuvor angesprochenen Probleme vorgestellt.
Wie sieht das zugrunde liegende Modell aus? Um diese Frage für den entsprechenden Ansatz zu beantworten, wird die Struktur erläutert, welche die Grundlage für die Anpassungsmethode liefert.
Wie funktioniert die Anpassungsmethode? Hier wird beschrieben, wie aus dem abstrakten Modell ein konkretes Modell für die Anwendung im Projekt wird. Im Fall der spezialisierten Modelle wird am Beispiel der QUIM Erstellung die einmalig durch- zuführende Erstellungsmethode als Spezialfall einer Anpassungsmethode beschrieben.
Häufig gestellte Fragen
Was ist das Hauptthema dieses Dokuments?
Dieses Dokument ist eine umfassende Sprachvorschau, die ein Inhaltsverzeichnis, Ziele, Schlüsselthemen, Kapitelzusammenfassungen und Schlüsselwörter enthält. Es behandelt Softwarequalität, Software Engineering Modelle und zugehörige QS-Maßnahmen.
Welche Software Engineering Modelle werden in dem Dokument behandelt?
Das Dokument behandelt verschiedene Modelle, darunter Qualitätsmodelle (ISO/IEC 9126, Capgemini sd&m Softwareblutbild), Ergebnistypmodelle (Anwendungsfallmodell, Architekturmodell, Testfallmodell), Prozessmodelle (Wasserfallmodell, SCRUM, ISTQB Testprozessmodell) und Rollenmodelle.
Was sind die Qualitätsmodelle die besprochen werden?
Qualitätsmodelle wie ISO/IEC 9126, für den Test angepasste ISO/IEC 9126 und Capgemini sd&m Software-Blutbild werden beispielhaft genannt.
Was sind Ergebnistypmodelle die besprochen werden?
Ergebnistypmodelle umfassen Anwendungsfallmodelle, Architekturmodelle und Testfallmodelle.
Was sind Prozessmodelle die besprochen werden?
Prozessmodelle die besprochen werden, umfassen das Wasserfallmodell, SCRUM (ein agiles Entwicklungsmodell) und das Testprozessmodell gemäß ISTQB.
Was sind die Rollenmodelle die besprochen werden?
Die Rollenmodelle beinhalten Rollen entlang des Wasserfalls, SCRUM Entwicklerrollen und Testrollen gemäß ISTQB.
Was sind die Dimensionen von Qualitätszielen, die in diesem Dokument erwähnt werden?
Die Dimensionen von Qualitätszielen umfassen Qualität, Ergebnistyp, Prozess und Rolle.
Was wird in Kapitel 4 über den Stand der Forschung diskutiert?
Kapitel 4 fasst wissenschaftliche Publikationen zusammen, die Qualitätsmodelle, ihre Anpassung und Anwendung vorstellen, einschließlich aktivitätenbasierte, produktbasierte, spezialisierte und zielorientierte Qualitätsmodelle.
Was sind die wichtigsten Qualitätsmerkmale, die in diesem Dokument erwähnt werden?
Die wichtigsten Qualitätsmerkmale die in diesem Dokument erwähnt werden umfassen Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit sowie Übertragbarkeit (gemäß ISO/IEC 9126).
Was sind analytische QS-Maßnahmen?
Eine analytische QS-Maßnahme (aQSM) ist eine Tätigkeit zum Bewerten der Qualität. Sie dient zur Erkennung und Lokalisierung von Mängeln und Fehlern im weitesten Sinne.
Was sind konstruktive QS-Maßnahmen?
Eine konstruktive QS-Maßnahme (kQSM) beschreibt eine Aktivität, die durchgeführt wird, um Qualität präventiv zu sichern.
- Quote paper
- Thomas Noack (Author), 2011, Multidimensionale Qualitätsziele und integrierte QS-Maßnahmen, Munich, GRIN Verlag, https://www.grin.com/document/172628
