Qualität durch Traceability - vom Geschäftsbedarf bis zur Lösung
•Als PPTX, PDF herunterladen•
0 gefällt mir•204 views
Warum ist Traceability für eine nachhaltige Softwareentwicklung unverzichtbar? Finden Sie hier Impulse, wie Sie die Nachverfolgbarkeit Ihrer Anforderungen vom Bedarf der Stakeholder bis zur implementierten Lösung sichern können. Es werden zwei Phasen unterschieden: Pre-Requirements Traceability und Post-Requirements Traceability. Für beide Phasen zeigt die Präsentation einen leichtgewichtigen Weg unter anderem mit Modellen der UML/SysML. Wir nennen das Lean Requirements Traceability.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Qualität durch Traceability - vom Geschäftsbedarf bis zur Lösung
Ähnlich wie Qualität durch Traceability - vom Geschäftsbedarf bis zur Lösung (20)
Mehr von microTOOL GmbH
Mehr von microTOOL GmbH (16)
Qualität durch Traceability - vom Geschäftsbedarf bis zur Lösung
- 1. Qualität durch Traceability – vom Geschäftsbedarf bis zur Lösung Warum Traceability für nachhaltige Entwicklung unverzichtbar ist und wie man sie realisiert
- 5. So kommen wir nicht durch Audits! ISO 9000 können wir vergessen! Wie sollen wir nachvollziehen, für wen wir was gebaut haben? Wie soll ich dann Auswirkungen von Änderungen erkennen? Dann erreichen wir nie CMMI Level 3! Dann wissen wir nicht, wo wir stehen Wie soll Wartung dann gehen? ???
- 6. Wie viel Traceability haben Sie realisiert
- 7. So kommen wir nicht durch Audits! ISO 9000 können wir vergessen! Wie soll ich dann Auswirkungen von Änderungen erkennen? Dann erreichen wir nie CMMI Level 3! Dann wissen wir nicht, wo wir stehen Wie soll Wartung dann gehen? ??? Wie sollen wir nachvollziehen, für wen wir was gebaut haben?
- 8. Was ist Traceability? Probleme – speziell im agilen Umfeld Traceability leben – mit Beispielen aus der Praxis Agenda
- 9. Was ist Traceability? Probleme – speziell im agilen Umfeld Traceability leben – mit Beispielen aus der Praxis Agenda
- 10. Compliance Revisionssicherheit Compliance Nachvollziehen der Historie von Artefakten Traceability Traceability Revisionssicherheit Nachvollziehen der Einhaltung von Prozessen & Standards im Entwicklungsprozess Nachvollziehen von Beziehungen zwischen Artefakten des Entwicklungsprozesses
- 11. Definition ISO/IEC/IEEE 24765:2010 Discernible association among two or more logical entities, such as requirements system elements verifications tasks Traceability
- 12. Requirements Traceability Business Analysis Body of Knowledge BABOK v3, Glossar Die Fähigkeit, Beziehungen zwischen Gruppen von Anforderungen vom ursprünglichen Bedarf des Stakeholders bis zur aktuell eingeführten Lösung zurückzuverfolgen Definition
- 13. Was heißt … Beziehungen zurückverfolgen … bezogen auf Anforderungen?
- 14. Stakeholder & ihr Bedarf Requirements CodeDesign Tests Evolution Pre-Requirements Traceability Post-Requirements Traceability Wurde eine Anforderung umgesetzt? Was ist alles von Änderungen einer Anforderung betroffen? Fehlen Artefakte (gibt es z.B. zu allen Anforderungen Testfälle)? Welche Anforderungen leiten sich aus welchem Bedarf ab? Wer hat den Bedarf? Wie wirken sich Bedarfsänderungen aus?
- 15. Requirements Dokument Welche Anforderungen und Anforderungsdokumente sind von Änderungen einer Anforderung betroffen? Inner Traceability
- 16. Requirement Tasks ln welchem Zustand ist die Realisierung einer Anforderung? Wie viel Aufwand steckt darin (Ist/Soll)? Wer hat eine Anforderung realisiert? Requirements to Tasks
- 17. Requirements Traceability macht... Projektplanung, Risikomanagement, Fortschrittskontrolle einfacher erfolgreiche Audits, mehr Stakeholder-Zufriedenheit mehr Lösungsqualität mehr Sicherheit bei den Kosten Entscheidungen und Lösungswege nachvollziehbar Validierung und Verifikation einfacher Wartungsaufwand besser schätzbar besseres Projektmanagement
- 18. Also: Spuren legen JA. Aber wie?
- 19. http://www.metabusinessanalyst.com/3-ways-manage-your-requirements-traceability-matrix/ Requirements Traceability Matrix is probably one of the most valuable things people almost never do
- 20. Was ist Traceability? Probleme – speziell im agilen Umfeld Traceability leben – mit Beispielen aus der Praxis Agenda
- 21. Traceability in agilen Projekten … führt zu mehr Artefakten, die nicht zum Lieferprodukt gehören, und zu up-front Aktivitäten … macht Änderungen, die doch willkommen sein sollten, schwerfälliger … erhöht den Grad an „Waste” … bremst die Produktivität des Teams aus
- 22. Requirements Traceability muss lebbar sein!
- 23. Was ist Traceability? Probleme – speziell im agilen Umfeld Traceability leben – mit Beispielen aus der Praxis Agenda
- 24. „Lean“ Requirements Traceability Vorschlag für leichtgewichtiges Vorgehen ohne explizite Traceability-Dokumentation in 3 Schritten
- 25. Schritt 1 Festlegen, welche Arten der Requirements Traceability angestrebt werden sollen „Lean“ Requirements Traceability
- 27. Für unsere Projekte JA: Requirements / Activity
- 28. Requirements to Document – Inner Traceability notwendig?
- 29. Für unsere Projekte NEIN: Inner Traceability: Artifact to Document
- 31. Schritt 2 Festlegen, welche Pre-/Post Requirements Traces erstellt werden sollen Lean Requirements Traceability
- 35. Ist das Arbeiten mit Modellen überhaupt leichtgewichtig? Wie nutzt man Modellwissen für die Inner- & Post-Requirement Traceability?
- 36. Wenn sich eine konkrete Anforderung ändert, welche anderen Anforderungen und Artefakte sind betroffen? Mit Modellwissen situativ tracen
- 38. Pre-Requirement Traceability Mit welchen Modellen? Keine Standardnotation für Needs & Goals
- 40. Schritt 3 Festlegen, bis zu welchem Detaillierungsniveau Artefakte „getraced“ werden sollen Lean Requirements Traceability
- 41. Traceability bis zum Code In unseren Projekten JA und NEIN
- 42. Modellgetriebene Entwicklung: Transformation der fachlichen Modelle einer Komponente in Quellcode Unsere Entscheidung: NEIN für alle Produkt- komponenten
- 43. Unsere Entscheidung: JA für alle Erweiterungen, die als RESTful Services realisiert werden
- 44. Lean Requirements Traceability kommt ohne zusätzliche Artefakte und Up-front Aktivitäten aus 3 vorbereitende Schritte für so viel Requirements Traceability wie nötig Situatives Tracen ist Bestandteil der täglichen Arbeit Fazit Der Schlüssel: Spuren legen durch Modelle
Hinweis der Redaktion
- Guten Tag, meine Damen und Herren. Ich möchte Ihnen ein methodisches Thema nahebringen: Traceability – genauer Requirements Traceability und ihre Bedeutung für eine nachhaltige Entwicklung.
- „Fertig und abgenommen? Naja, dann weg damit!“ Große Unruhe im Publikum – und dann die Frage: Klick
- „Wo bleibt da die Traceability?“ Die Rückfrage des Referenten kam prompt: Klick
- „Wozu wollen Sie Traceability?“
- Und dann schwirrte die Luft von Argumenten: Zu den wichtigsten gehörten sicher: So erreichen wir nie einen höheren CMMI oder SPICE Level. Die ISO-Zertifizierung können wir dann vergessen. Der Kollege blieb ganz cool und fragte nur:
- „Wie viel Traceability haben Sie denn realisiert?“
- Stille machte sich breit. Hier klafft offensichtliche zwischen dem, was theoretisch als wünschenswert und sogar notwendig erkannt wird, und dem, was in Projekten wirklich getan wird, eine große Lücke. Grund genug – denke ich –, das Thema einmal genauer zu betrachten. Das möchte ich jetzt mit Ihnen gemeinsam tun.
- Dazu müssen wir zunächst einmal den Begriff Traceability klären und uns das Nutzenversprechen genauer ansehen… Klick …ebenso wie die Probleme, die damit verbunden sind. Ich möchte speziell die Probleme im agilen Umfeld betrachten, weil agiles Vorgehen weitgehend Mainstream ist. Klick Und schließlich stelle ich ihnen einen Weg vor, wie man Traceability in Projekten – auch in agilen – leben kann – und zwar mit Beispielen aus unserer Entwicklungspraxis. Klick
- Also zunächst zur Frage: Was ist Traceability eigentlich?
- Wenn von Traceability – von Nachvollziehbarkeit oder Rückverfolgbarkeit – die Rede ist, werden oft drei Begriffe miteinander vermengt, die – zugegeben – sehr nahe beieinander liegen: Der Erste betriff das Nachvollziehen der Historie von Artefakten, die im Entwicklungsprozess entstehen – als Basis für ein revisionssicheres Arbeiten. Revisionssicherheit ist fest verankert in Prozessen wie etwa dem V-Modell XT. Revisionssicherheit ist ein Thema für das Versions- und Konfigurationsmanagement. Darum soll es hier heute nicht gehen. Der zweite Begriff ist der der Compliance: Dabei geht es um das Rückverfolgen und Nachvollziehen der Einhaltung von Prozessen und Standards. Ein großes Thema z.B. im Automotive Sektor und ein elementarer Aspekt für die Zertifizierung z.B. nach in Automotive SPICE. Auch das ist nicht mein Thema. Hier soll es um Traceability – um das Rückverfolgen und Nachvollziehen von Beziehungen zwischen Artefakten des Entwicklungsprozesses gehen. Klick
- Eine gängige Definition lautet: Traceability ist eine – discernible association – also eine erkennbare Verbindung zwischen zwei oder mehr logischen Entitäten wie Anforderungen Systemelementen Verifikationen oder Aufgaben.
- Was ist Traceability bezogen auf Anforderungen? Wenn wir uns in der Welt des Requirements Engineering und der Business Analyse umsehen, dann finden wir zum Beispiel im Business Analysis Body of Knowledge BABOK – einem internationalen Standard herausgegeben vom International Institute of Business Analysis folgende Definition: Klick Requirements Traceability ist Die Fähigkeit, Beziehungen zwischen Gruppen von Anforderungen vom ursprünglichen Bedarf des Stakeholders bis zur aktuell eingeführten Lösung zurückzuverfolgen Klick
- Was heißt „Beziehungen zurückverfolgen“ in Bezug auf Anforderungen genau?
- Nach BABOK soll sich also die Beziehung zwischen Anforderungen und ihrer Quelle – den Stakeholdern & ihre Needs – in beiden Richtungen nachvollziehen lassen. In diesem Fall spricht man auch von Pre-Requirements Traceability. Sie ist die Grundlage, und Fragen zu beantworten wie: Wem ist eine Anforderung wie wichtig? Ebenso sollen sich die Beziehungen zwischen Anforderungen, dem Entwurf, Code und den Test in beiden Richtungen nachvollziehen lassen. Hier spricht man entsprechend von Post-Requirements Traceability Sie ist für Fragen da wie: Was ist alles von Änderungen der Anforderung betroffen? Daneben gibt es noch den Aspekt der Evolution – also der Veränderung der Anforderungen während ihrer Entwicklung. Das ist wieder ein Thema des Versionsmanagements. Das möchte ich hier ausklammern. Pre- und Post-Requirements Traceability sind längst nicht alle Formen der Traceability … Pre-/Post Traceability Traceability innerhalb von Anforderungen (Welcher Use Case erfüllt welches Ziel) Wie wird die Anforderung getestet? Wo ist die Anforderung implementiert? Was ist von Änderungen betroffen? Wo kommt die Anforderung her? Wem ist sie wie wichtig?
- Anforderungen können auch untereinander in Beziehung stehen So unterschiedet BABOK ja zum Beispiel zwischen Business-, Stakeholder- und Solution-Requirements, die sich auseinander ableiten und Anforderungen können in Anforderungs- und Spezifikations-Dokumenten vorkommen. Hier spricht man von Inner Traceability. Sie hilft z.B. die Frage zu beantworten: Welche Anforderungen und Anforderungsdokumente sind von Änderungen einer Anforderung betroffen?
- Und schließlich gibt es noch eine weitere heiße Spur: Und zwar die zwischen einer Anforderung und einer oder mehreren Tasks oder Aufgaben in der Projektplanung. Aufgaben, die dazu dienen, eine Lösung für Anforderungen zu entwickeln und zu realisieren. Diese Form der Requirements to Task Traceability hilft bei Fragen wie: ln welchem Zustand ist die Realisierung? Wie viel Aufwand steckt darin? Wer hat es gemacht?
- Wenn es gelänge Requirements Traceability perfekt herzustellen, was hätten Entwicklungsorganisationen davon? Was ist das also Nutzenversprechen von Requirements Traceability? Wenn man die Konsequenzen beabsichtigter Veränderungen einer Anforderung kennt, kann man sicherer planen, Risiken besser und den Fortschritt besser kontrollieren. Plakativ gesagt, bedeutet das besseres Projektmanagement. Wenn man Entscheidungen und Lösungswegen nachvollziehbar macht, sind das gute Voraussetzungen für erfolgreiche Audits, und mehr Stakeholder-Zufriedenheit Validierung und Verifikation werden einfacher für mehr Qualität Und schließlich wird auch der Wartungsaufwand besser schätzbar für mehr Sicherheit bei der Kostenplanung. Klick Das Herstellen von Requirements Traceability lohnt sich schon.
- Also: Spuren legen! JA Aber wie? Und zu welchem Preis? Klick
- “The requirements traceability matrix is probably one of the most valuable things people almost never do.” Ich finde es sehr treffend. Denn der Aufwand ist riesig, wenn man die Matrix mit der Hand pflegen muss und nicht generieren kann. Dazu kommt die Multi-User-Problematik bei der Arbeit mit Excel. Generieren ist schwierig, wenn die Needs, Requirements und Artefakte mit verschiedensten Werkzeugen erstellt und verwaltet werden.
- Gerade in agilen Projekten haben sich deshalb Vorbehalte in Bezug auf Aufwand und Nutzen von Traceability aufgebaut. Werfen wir einen kurzen Blick darauf:
- Typische Kritik lautet: Traceability in agilen Projekten führt zu mehr Artefakten, die nicht zum eigentlichen Lieferprodukt gehören, und zu up-front Aktivitäten macht insbesondere Änderungen – die doch in agilen Projekten immer willkommen sein sollten – schwerfälliger erhöht den Grad am “Waste” – Zeitverschwendung etwa beim “Zusammensuchen” von Informationen und bremst damit schließlich die Produktivität des Teams aus.
- Um Akzeptanz auch in agilen Projekten zu finden, muss Requirements Traceability lebbar sein. Wie kann das gehen?
- Ich stelle Ihnen dazu eine Lösung vor, die wir in unseren agilen Projekten praktizieren. Wir arbeiten seit 2002 agil – haben dabei alle Höhen und Tiefen erlebt, die man sich vorstellen kann. Klick
- Wir haben ein leichtgewichtiges Vorgehen definiert, das sich in unserer Praxis bewährt hat – nennen wir es Lean Requirements Traceability. Unser Vorgehen verzichtet vollständig auf explizite Dokumentation von Traceability, d,h, auf Artefakte, die für die Traceability erstellt werden, und umfasst drei Schritte. Klick
- Der erste Schritt unseres Vorgehens besteht darin, für ein Projekt, ein Programm oder alle Projekte der Organisation festzulegen, welche Arten der Requirements Traceability überhaupt betrachtet werden sollen. So haben wir uns gefragt:
- Ist die Traceability Requirements to Activity notwendig?
- Wir haben uns entschieden JA. Uns ist die Information wichtig, in welchem Sprint eine Anforderung eingeplant ist bzw. war, wer sie bearbeitet hat und wie hoch der ursprüngliche Planaufwand war. Diese Informationen nutzen die Projektleiter, aber auch die Vertriebs und Support-Mitarbeiter in der Kommunikation mit den Kunden. Ich zeige Ihnen kurz, wie wir das in unserer Umgebung realisiert haben: Film starten Hier sehen Sie einen Projektplan als Gantt Chart – wie Sie ihn kennen. Bei einer Aktivität – sprich einem Sprint – im Projektplan halten wir alle Anforderungen mit ihrem Planaufwand fest, die in dem Sprint zu realisieren sind. Und wenn wir uns einer Anforderung ansehen, finden wir darin umgekehrt die Referenz auf den Sprint, in dem sie bearbeitet wird. Ein zweites Beispiel:
- Ist Requirement to Document – also diese spezielle Form der Inneren Traceability – notwendig?
- Es wird Sie vielleicht überraschen, aber unsere Entscheidung lautet NEIN. Wir merken uns nicht, welche Anforderung bzw. welches Artefakt der Analyse in welchem Dokument vorkommt. Film Starten Ganz einfach, weil wir Anforderungsdokumentation, die wir an Kunden herausgeben, immer frisch – aus dem aktuellen Stand der Entwicklung heraus generieren. So wie Sie es hier sehen. Das ist ein Business Case. Hier sehen Sie die hineingenerierte aktuelle Liste aller Stakeholder. Anschließend wird der herausgegebene Stand versioniert.
- Bleibt noch die Pre-/Post-Requirements Traceability. Hier ist nicht die Frage, ob wir sie brauchen. Sie ist in jedem Falle notwendig.
- Hier ist festzulegen, wieviel wir davon brauchen, und mit welchen Mitteln wir sie festhalten wollen. Genau das legen wir im zweiten Schritt unserer Vorgehensweise fest. Die Frage: Wieviel Pre-/Post-Requirements Traceability wollen wir festhalten, läuft auf einen ganz andere Frage hinaus.
- Wie viel Software Engineering soll in unseren Projekten stattfinden? Was hat Traceability mit Software Engineering zu tun? Blicken wir dazu in die Kiste der gängigen Software Engineering Verfahren: Darin finden wir die UML, die Unified Modeling Language. Sie gilt heute leider als ziemlich angestaubt. Trotzdem: Der Blick lohnt sich.
- Ganz besonders interessant ist aber ein Blick in die SysML, die Systems Modeling Language, eine Erweiterung der UML. Die SysML ist ursprünglich für das Systems Engineering gemacht und führt so ein wenig ein Nischendasein. Sie werden gleich sehen, dass die SysML hoch-interessante Instrumente enthält, die auch für das Requirements Engineering im Rahmen der Business Analyse sehr hilfreich sind. Die SysML kennt – wie BABOK – die Satisfy-Beziehung zwischen Elementen und Requirements Und die – hier heißt sie – Verify-Beziehung zwischen TestCases und Requirements. Einmal modelliert, kann man diese Beziehungen für die Post-Requirements Traceability nutzen. Und es wird noch besser:
- Die SysML kennt außerdem die: Derive, also die Ableitungsbeziehung zwischen Requirements Contains, also Enthält-Beziehung zwischen Requirement Und Refine-Beziehung zwischen Elementen und Requirements Alles drei nutzbar für die Inner Traceability von Anforderungen.
- Ist das Arbeiten mit Modellen überhaupt leichtgewichtig? JA – wenn nicht der Zwang besteht alle Anforderungen und ihre Beziehungen tatsächlich grafisch abzubilden. Wenn es z.B. möglich ist, beim Erfassen von Anforderungen, aber auch von Testfällen oder der Beschreibung von Stakeholdern als Quelle von Anforderungen Beziehung herzustellen – formularbasiert, ohne Grafik. Klick Und wie nutzt man Modellwissen für die Requirements Traceability?
- Was bringen solche Diagramme für die Requirements Traceability? Wenn ich eine konkrete Anforderung ändere und sich dabei die Frage stellt, welche anderen Anforderungen und Artefakte sind betroffen, … Klick ….dann kann ich mit diesem Modellwissen diese Frage aus der Situation heraus bei der Arbeit ganz leicht beantworten.
- Nehmen wir an, diese Lösungsanforderung ändert sich. Was ist davon alles betroffen? Alle was wir hier sehen (Ränder zeigen), aber vielleicht auch Artefakte, die nicht hier, sondern in anderen Diagrammen dargestellt sind. Klick Die über Modelle eingebrachten Informationen werden bei der Anforderung gesammelt. Film starten: Die Anforderung hat eine Quelle, einen Stakeholder. Sie hat Verfeinerung. Sie kommt in einer Ableitungshierarchie vor. Und ein Anwendungsfall beschreibt die Anforderung näher. Diese Spuren sind alle durch das Modellieren da. Ich muss diese Elemente überprüfen, ob sie von der vorgesehen Änderung betroffen sind. Halten wir fest: Modelle – speziell das Requirements Diagramm – helfen bei der Inner & Post-Requirements Traceability. Wie sieht es mit der Pre-Requirements Traceability aus?
- Hier verlassen wir die Komfortzone der modellbasierten Techniken. Es gibt es leider keine verbreitete Standardnotation zur Modellierung von Needs oder Goals. Aber es gibt zumindest zwei brauchbare Ansätze: Da ist zum einen das i* Framework. Dabei handelt es sich – nach meinem Gefühl – um eine recht aufwendige Notation. Wir arbeiten mit einer anderen, einfacheren Darstellungstechnik: Klick
- Wir verwenden zur Bedarf-/Zielmodellierung Und-/Oder-Graphen. Damit kann ich z.B. den Bedarf eines Stakeholders zerlegen/verfeinern. Klick Und auch Konflikte modellieren. Klick Aus einem Business Bedarf kann ich konkrete Ziele ableiten und diese ebenfalls z.B. in Alternativen zerlegen. Klick Aus Bedarf oder Zielen kann ich konkrete Anforderungen ableiten. Sie sehen: Eine Menge Spuren für die Pre-Reqirements Traceabilty, die mich zu den Quellen einer Anforderung führen. Muss man denn alles modellieren? Auch hier gilt: NEIN. Man muss zum einen nicht jedes Requirements grafisch darstellen … Klick
- Und zum anderen legen wir für unsere Projekte im dritten und letzten Schritt fest, bis zu welchem Detaillierungsniveau getraced werden soll. Ein letztes Beispiel dazu aus unserer Praxis: Klick
- NEIN bei unserer Standardproduktentwicklung: Wir haben entschieden, Spuren von einer Anforderung zu der Komponente, in der sie realisiert ist, auf Modellniveau zu legen. Auf Traceability bis in den Code verzichten wir. Warum? Eine System-Komponente besteht bei uns aus fachlichen Modellen, aus denen wir per Modelltransformation in großem Umfang Code generieren. Denn wir entwickeln unsere Software modellgetrieben und in hohem Umfang automatisiert. Uns reicht es deshalb aus, die Beziehung zwischen Anforderung und Komponente im Modell festzuhalten. Klick
- Lassen mich unsere Erfahrungen kurz zusammenfassen: Klick Man kommt für die Requirements Traceability ohne zusätzlich Artefakte, fast ohne zusätzlichen Aufwand und ohne Verschwendung von Zeit und Energie aus…. Klick … wenn man einmalig für ein Projekt oder ein Programm oder für die Organisation festlegt, wie viel Traceability wirklich nötig ist. Klick Ein großes Dokument wie die Traceability Matrix– ob generiert oder mit der Hand gepflegt – das alle Abhängigkeiten zeigt – ist für die tägliche Arbeit nur bedingt hilfreich. Hilfreich dagegen ist die Möglichkeit, situativ zu tracen. Es wird nicht als zusätzlicher Aufwand wahrgenommen und schon gar nicht als Zeitverschwendung, sondern ist einfach Bestandteil der täglichen Arbeit. Der Schlüssel dazu ist Modellieren. Klick
- Also mein Rat: Anforderungen gut aufbewahren – auf im agilen Kontext – und spurenlegen für die Traceability.
- Vielen Dank