Handwerk · 04. April 2013

SW-Qualität in PHP-Projekten | Testbasierte Entwicklung verkaufen [05]

Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.

Offenlegung von Risiken mit ATAM

Buchcover | Link zu Amazon — Link zu Amazon

Durch die Architecture Trade-Off Analysis Method (ATAM) zeigt das Software-Team bei Fokussierung auf die Geschäftsziele die mögliche Zielerreichung und Risiken bestimmter Vorgehensmodelle auf.

Diese Methode folgt der Philosophie, dass nicht bestimmte technische Methoden für den Erfolg entscheidend sind, sondern das richtige Verständnis unter den Projektbeteiligten.

ATAM erfolgt unter Beteiligung des Auftraggebers beziehungsweise der Auftraggeberin. Ist eine intensive Vorbereitung der grundsätzlichen Entscheidungen im Projekt nicht möglich, ist zumindest die Risikokalkulation, wie sie im Teil 6 beschrieben ist, vorzunehmen.

Diese Methode liefert die Grundlage für eine Kommunikation über Zielerreichung der Geschäftsziele, Umsetzungsformen, Risiken und Trade-Offs von Entscheidungen im Projekt. Diese Ergebnisse können mithilfe betriebswirtschaftlicher Kennzahlen bewertet werden. ATAM verläuft in fünf Schritten. Diese sind nachfolgend erläutert:

Schritt 1: Vorgehen und Zielsetzung von ATAM erklären

Bei der Vorbereitung ist zu klären, wer an diesem Entscheidungsprozess teilnehmen sollte. Wird das beauftragende Unternehmen die Verantwortung für das Projekt im Regelbetrieb vom Projekt- ins Produktmanagement übergeben, sollte auch das Produktmanagement (genauso wie Personen aus dem Betrieb) an der Entscheidung beteiligt werden.

Nach Definition des Entscheidungskreises werden die einzelnen ATAM-Schritte den beteiligten Personen vorgestellt.

Schritt 2: Ziele definieren

Alle Projektbeteiligten benennen die Ziele, die sie mit der zu erstellenden Software verbinden. In Projekten werden gerne am ehesten fachliche Ziele genannt. In vielen Fällen benennt der Auftraggeber beziehungsweise die Auftraggeberin aber lediglich die fachlichen Maßnahmen: Sie benennen also Art und Umfang von Funktionen. Hier gilt es nachzufragen! Die Geschäftsziele, die durch die fachliche Umsetzung angestrebt werden, sind für alle verständlich und nachvollziehbar zu erläutern.

Darüber hinaus benennt das Software-Team diejenigen technischen Ziele, die für das System erreicht werden sollen. Die Clusterbildung der Ziele erfolgt nach ATAM in den Bereichen Erreichbarkeit, Veränderbarkeit, Performanz, Sicherheit.

Mit den Zielen, die aus dem Software-Team heraus formuliert werden, werden Fragen zur guten Wartbar- und Erweiterbarkeit beantwortet. Mögliche Anforderungen, die sich im Gespräch mit dem sAuftragge- ber beziehungsweise der Auftraggeberin ergeben, könnten sein:

Für ein Unternehmen, das gerade stark expandiert, sind Veränderungen des Geschäfts und damit der Darstellung im Web zu erwarten. Ziel ist, sehr schnell entsprechende Än- derungen öffentlichkeitswirksam publizieren zu können.

Hieraus ergibt sich die Anforderung, ein globales Redesign innerhalb von fünf Personentagen realisieren zu können. Welchen Umfang diese Arbeiten haben können, wird mittels der ATAM-Folgeschritte bestimmt.
Die Vergangenheit hat für ein bestimmtes Unternehmen gezeigt, dass neue Produkte am Besten verkauft werden, wenn die entsprechenden Artikeldarstellungen direkt über die Hauptnavigation erreichbar sind.

Daraus ergibt sich die Anforderung, dass die Erweiterung der Navigationsstruktur innerhalb von zehn Werktagen möglich sein muss.

Bedenken Sie mögliche technische Schulden eines bereits bestehenden Systems und leiten Sie daraus mögliche Risiken ab. Formulieren Sie dann Ziele, die die technischen Schulden abbauen beziehungsweise in einem neuen System den Aufbau dieser technischen Schulden verhindern.

Alle vorgestellten Ziele sind so vorzustellen und zu erläutern, dass alle anderen am Entscheidungsprozess beteiligten Personen diese Zielsetzungen verstehen. Das ist ein hoher interdisziplinärer Anspruch, dessen Einlösung sich lohnt. In der nachfolgenden Betrachtung der Vor- und Nachteile bestimmter Lösungen können diese alle in ihren Auswirkun- gen nachvollziehen.

Schritt 3: Anforderungen im Utility Tree aufzeichnen

Bild 1: Beispielhafter Utility Tree für eine Website

Aus den genannten fachlichen und technischen Zielen leiten Sie die Anforderungen für das Projekt ab. Diese werden im Utility Tree (siehe Beispiel in Abbildung 1) als Use Cases aufgenommen. Die Use Cases sind möglichst konkret formuliert. Leiten Sie aus diesen Anforderungen fachliche und technische Qualitätskriterien ab. Diese werden ebenfalls im Utility Tree aufgeführt. Damit die Darstellung im Utility Tree übersichtlich bleibt, werden die Anforderungen anhand der oben benannten Clusterbezeichnungen dargestellt. Diese Clusterbildung können Sie an Ihr Projekt anpassen.

Nach Diskussion mit allen Projektbeteiligten einigen Sie sich darauf, welche fachliche Priorität die genannten Anforderungen für das Projekt haben.

Schritt 4: Architektonische Szenarien und Vorgehensmodelle entwickeln

Überlegen Sie sich unterschiedliche architektonische Szenarien und Vorgehensmodelle für das Software-Projekt. Dieses Modell aus Architektur und Vorgehen fassen Sie unter einem geeigneten Namen zusammen und führen die entsprechenden Maßnahmen auf.

So können Sie zum einen die Systemumgebungen bestimmen, zum anderen stellen Sie auch dar, welches Testvorgehen Sie wählen, und benennen konkret die angestrebte Testabdeckung. Ebenfalls Teil des Vorgehensmodells könnten auch andere Projektvorgehen, wie zum Beispiel vereinfachte Abnahmeprozeduren, sein.

Schritt 5: Risiken und Trade-Offs aufzeigen

Für jedes dieser Modelle wird ein Utility Tree um die zu erwartende Zielerreichung ergänzt. Insgesamt erhalten Sie also einen Überblick, welches Architektur- und Vorgehensmodell die gestellten fachlichen Anforderungen am besten erfüllt.

All dies wird in einem Utility Tree für jeweils ein Modell zusammengefasst: Die Use Case-Cluster werden jeweils links mit der fachlichen Priorisierung (H für hoch, M für mittel, G für gering) gekennzeichnet. Die Zielerreichung wird in der rechten Spalte mit den gleichen Parametern dargestellt. In der Abbildung 1 ist diese Bewertung bereits eingefügt.

Gleichzeitig stellen Sie dar, welche Risiken und bereits bekannte Trade-Offs sich aus dem vorgestellten Vorgehen ergeben. Diese Punkte können zur Verdeutlichung noch in die Bereiche

Auswirkungen für den Endkunden
Fachliche Zielerreichung
Technische Zielerreichung

unterteilt werden. Um eine umfassende Diskussion zu erleichtern, sollten Sie diese Informationen in jeweils einem Dokument (von genau einer Seite) zusammenfassen:

Name Vorgehensmodell
Kurzvorstellung Vorgehensmodell sowie architektonischer Entscheidungen
Resultierender und bewerteter Utility Tree
Auflistung Risiken und Trade-Offs

Diskutieren und entscheiden

Diese Dokumente dienen als Diskussionsgrundlage für die Festlegung des Architektur- Modells und des Projektvorgehens. Durch die gemeinsame Entscheidung entsteht hieraus eine stabile Basis für das Projekt.

Mit ATAM transparente Entscheidungen herbeiführen

Durch dieses Vorgehen erreichen Sie eine offene Diskussion über das zu wählende Architektur- Modell und das Vorgehen – insbesondere also auch ein testbasiertes Vorgehen – im Projekt:

Alle Projektbeteiligten formulieren ihre Zielsetzungen. Die Projektbeteiligten einigen sich auf eine gemeinsame Zielsetzung.
Die Projektbeteiligten legen ggf. konkurrierende Zielsetzungen offen und finden ge- meinsam einen Kompromiss.
Alle kennen die sich aus dem Vorgehen ergebenden Risiken und Trade-Offs.

Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.

Tags: SWQualitaetInPHPProjekten, JudithAndresen

Kommentar schreiben

Kommentare: 0