Freitag, 5. Juni 2015

Im Dschungel der Nachvollziehbarkeit.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


Im letzten Artikel dieser Reihe haben wir gesehen, dass Entwicklungsartefakte verschiedene Versionsstände durchlaufen, die im historischen Kontext erhalten bleiben müssen. Entwicklungsartefakte können erweitert, umgeschrieben, neu aufgeteilt und gelöscht werden. Alle diese Entwicklungsschritte müssen nachvollziehbar bleiben. Die Gesamtheit der Artefakte kann in ganz bestimmten Versionsständen eingefroren werden. Wir setzen eine Baseline. Mit Maven, einem Built-Management-Tool, kann dieser Vorgang zu einem großen Teil automatisiert werden. Diese Vorgehensweise erlaubt uns, jederzeit jeden Entwicklungsstand wieder zum Leben zu erwecken und auszuliefern.

Eine Zuschrift auf den letzten Artikel hat dieses Vorgehen als zu aufwendig kritisiert. Moderne Versionsverwaltungssysteme geben einer Vielzahl von Artefakten beim Einchecken gleiche Versionsnummern. Aufgrund dieser Versionsstände könne man ebenfalls Releases erstellen. Auf den Gesamtkomplex der Releaseerstellung möchte ich jedoch in einem späteren Artikel eingehen. Heute geht es erst einmal um weitere Abhängigkeitsbeziehungen, die im Gesamtkomplex der Entwicklungsartefakte beachtet werden müssen. Hier spielt die Traceability bzw. die Nachvollziehbarkeit eine ganz herausragende Rolle.

"Die Nachvollziehbarkeit einer Anforderung ist die Fähigkeit, den Lebenszyklus der Anforderung vom Ursprung der Anforderung über die verschiedenen Verfeinerungs- und Spezifikationsschritte bis hin zur Berücksichtigung der Anforderung in nachgelagerten Entwicklungsartefakten verfolgen zu können." [S. 505, POHL08] Auch wenn [POHL08] sich hier voll und ganz auf Anforderungen konzentriert, so gilt das für alle Entwicklungsartefakte, zumal diese in ihrem Ursprung aus Anforderungen hervorgehen. [POHL08] sieht vielfältige Gründe für die Nachvollziehbarkeit von Anforderungen: Nachweisbarkeit und Akzeptanz, Änderungsmanagement, Reengineering und Projektverfolgbarkeit sind nur einige davon.

Während der Entwicklung entstehen unterschiedliche Arten von Artefakten. Diese stehen in bestimmten Beziehungen zueinander, die ebenfalls nachvollziehbar sein sollten. In der Phase der Systemkontextanalyse ermitteln und entwickeln wir eine Vielzahl von Kontextobjekten. Diese helfen uns, das Umfeld des Systems zu verstehen. So versetzen wir uns in die Lage, das System zu beschreiben und abzugrenzen. Kontextobjekte bilden somit die Grundlage für Anforderungsobjekte. Innerhalb des von mir beschriebenen Requirements Engineerings wird eine Vielzahl solcher Objekte aus anderen Objekten heraus entwickelt. Durch den Prozess der Erstellung einer Software werden somit ebenfalls Nachvollziehbarkeitsbeziehungen definiert, aus Kontextobjekten folgen Anforderungsobjekte, aus Anforderungsobjekten folgen Codeobjekte.

[POHL08] bezeichnet diese Form der Nachvollziehbarkeit als Pre- und Post-Traceability. "Unter Pre-Traceability werden Nachvollziehbarkeitsbeziehungen zu denjenigen Artefakten subsumiert, die der Anforderung im Projektverlauf vorgelagert sind, z.B. der Ursprung bzw. die Quelle einer Anforderung. Post-Traceability umfasst Nachvollziehbarkeitsbeziehungen von Anforderungen zu Artefakten, die im Projektverlauf den Anforderungen nachgelagert sind, z.B. Komponenten, Implementierungen und Testfälle." [S. 508, POHL08]



Bei den betrachteten Objekten handelt es sich um unterschiedliche Arten. Ein Kontextobjekt bildet eine Anforderungsquelle ab, z.B. einen Stakeholder, der ganz bestimmte Forderungen aufgestellt hat oder ein Dokument, in dem Altsoftware beschrieben wurde. Ein Anforderungsobjekt beschreibt eine ganz konkrete Anforderung an das System, und eine Javadatei stellt ein Codeobjekt dar. Im Entwicklungsprozess kann es aber durchaus auch Beziehungen zwischen gleichartigen Artefakttypen geben. Im Falle des letzten Artikels waren das Versionsbeziehungen. In einem anderen Fall können das Verfeinerungsbeziehungen sein. Ein wichtiger Vorgang bei der Entwicklung eines Systems ist die Entwicklung eines Zielmodells. Nur wer sich darüber im Klaren ist, welche Ziele mit seinem System umgesetzt werden sollen, weiß wirklich, wohin die Reise geht.

Beim Entwickeln eines Zielmodells verfeinern wir aus Oberzielen Unterziele. Wir versuchen, von der groben Struktur zur feineren Struktur vorzudringen. Bei dieser Top-Down-Methode gehen ebenfalls Artefakte aus anderen Artefakten hervor, nur eben, dass sie von der gleichen Art sind. Solche hierarchischen Modelle dienen auch oft unterschiedlichen Ansprüchen. In diesem Zusammenhang kann man die Managementsicht erwähnen, die sich nur auf den höheren Hierarchieebenen bewegt und der ein grober Überblick reicht.



Es macht durchaus Sinn, Überblicksobjekte anzulegen, die einen schnellen Einblick in ein Gebiet erlauben. Der gewonnene Überblick ist Grundlage für die Entscheidung, mit welchen spezielleren Themen man sich beschäftigen will oder muss. Bei der Aufbereitung von Wissen spielt die Verfeinerungsbeziehung eine sehr wichtige Rolle. Sie erlaubt z.B. eine schnelle und gute Einarbeitung. [POHL08] ermittelt ebenso Nachvollziehbarkeitsbeziehungen, die einen zeitlichen Bezug zum Entwicklungsprozess aufweisen. So kennt er den Beziehungstyp "refines", der bei ihm eine Verfeinerung darstellt.

Am Ende spielt es eine große Rolle, wie die in Beziehung gesetzten Beziehungen erzeugt, verwaltet und sichtbar gemacht werden. Je komplizierter die Vorgehensweise ist und je mehr Disziplin dazu erforderlich ist, um so eher ist die Vorgehensweise zum Scheitern verurteilt. Bei der zu verwaltenden Objektmenge sollte man sich auf die notwendigen Artefakte konzentrieren. Dabei muss jedoch beachtet werden, dass nur Objekte, die unter dieser Verwaltung stehen, später auch nachzuvollziehen sind. "In der Praxis kann aufgrund von mehr oder weniger beschränkten Ressourcen nur eine Teilmenge der möglichen Nachvollziehbarkeitsinformationen dokumentiert werden." [S. 519, POHL08]

Die Präsentation der Nachvollziehbarkeit sollte durch ein System verwaltet werden. In diesem System definieren die Artefakte verschiedene Objekttypen. Jeder dieser Objekttypen durchläuft bestimmte Status, am Besten ähnliche oder sogar gleiche. Bestimmte Statusübergänge versionieren Objekte und bestimmte Statusübergänge erzeugen Baselines. In diesem System können die Objekte miteinander verbunden werden. Alle angelegten Artefakte sind eindeutig über Version und Identifikator zu bestimmen. In einer Firma haben wir dazu JIRA benutzt. Größere Beschreibungen konnten wir in einem Wiki ablegen und diese mit den Issues im JIRA verbinden.

Statt zuerst jedoch ein Tool auszuwählen, sollte man sich genau überlegen, welches System der Nachvollziehbarkeit man benutzen möchte. [POHL08] fordert uns dazu auf, eine Definition der projektspezifischen Nachvollziehbarkeit zu entwickeln. Dazu müssen drei Punkte beschrieben werden:

" Nachvollziehbarkeit: Definition der aufzuzeichnenden Nachvollziehbarkeitsinformationen z.B. in Form eines oder mehrerer Nachvollziehbarkeitsmodelle Aufzeichnungsstrategie: Definition der Strategie zur Aufzeichnung von Nachvollziehbarkeitsinformationen durch das Entwicklungsteam (wann ist welche Information von wem aufzuzeichnen) Nutzungsstrategie: Definition der Strategien zur Verwendung von Nachvollziehbarkeitsinformationen durch das Entwicklungsteam (wann ist welche Information von wem zu verwenden) " [S. 520, POHL08]

Es war mir wichtig, diese von [POHL08] erwähnten Punkte noch einmal aufzuzeigen, weil zu oft Strategien umgesetzt werden, ohne genau zu wissen, was wie damit eigentlich erreicht werden soll. Oft glaubt man auch an die Wunderwirkung von Tools, doch diese helfen immer nur so gut, wie der Benutzer weiß, was er mit ihnen anfangen soll. Der Spruch "A fool with a tool is still a fool" ist zwar allgemein bekannt in unserer Branche, dennoch scheint die Wundergläubigkeit in Bezug auf Tools nicht nachzulassen. Also, zuerst sollte man wissen, was man will und dann kann man sich ein passendes Werkzeug suchen.

  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen