Bouillon, ElkeGüldali, BarisHerrmann, AndreaKeuler, ThorstenMoldt, DanielRiebisch, Matthias2017-12-062017-12-062013https://dl.gi.de/handle/20.500.12116/8723Elke Bouillon1, Baris Güldali2, Andrea Herrmann3, Thorsten Keuler4, Daniel Moldt5, Matthias Riebisch6 1 Technische Universität Ilmenau, elke.bouillon@tu-ilmenau.de 2 s-lab ­ Software Quality Lab/Universität Paderborn, bguldali@s-lab.upb.de 3 Freie Software Engineering Trainerin und Forscherin, herrmann@herrmann-ehrlich.de 4 Fraunhofer IESE, Thorsten.keuler@iese.fraunhofer.de 5 Universität Hamburg, moldt@informatik.uni-hamburg.de 6 Universität Hamburg, riebisch@informatik.uni-hamburg.de Motivation Einer der wichtigsten Erfolgsfaktoren der agilen Softwareentwicklung ist die schnelle und unkomplizierte Verteilung von Informationen. Dabei reicht das Spektrum der Informationsverteilung von einfachen Dokumenten über Wikis, Videos und Telefonaten bis hin zum 'Face-to-Face' Gespräch. In der traditionellen Softwareentwicklung lag der Fokus typischerweise auf einer dokument-basierten Erfassung und Verteilung von Informationen. Explizite Dokumentation beruht auf der Annahme, dass sich die festgehaltenen Informationen nur in bestimmtem Maße ändern. Da dieser Umstand insbesondere in der Softwareentwicklung nicht automatisch gegeben ist, hat man dies im Kontext der agilen Vorgehensweisen als ein Kernproblem von schwergewichtigen Prozessen identifiziert. Als Konsequenz dazu wird in der agilen SoftwareEntwicklung der Umfang der Dokumentation minimiert. Dies spiegelt sich im Manifest für Agile Software-Entwicklung wider (s. agilemanifesto.org): Obwohl die umfassende Dokumentation als wichtig erachtet wird, wird der Wert funktionierender Software höher eingeschätzt. Nach den zwölf inizialen Prinzipien hinter dem Agilen Manifest gilt die direkte persönliche Übermittlung als effizientestes und effektivstes Verfahren. Funktioniert diese Kompensation besonders gut solange die Entwickler möglichst nah zusammen arbeiten, so ergeben sich jedoch Herausforderungen beim Versuch, agile Entwicklung in mehreren Teams und Standorten zu realisieren. Insbesondere fehlt es in der aktuellen Praxis an Techniken, welche die Dokumentation und Traceability der Entwicklungsartefakte optimal unterstützen. Somit kann es in der Praxis vorkommen, dass Anforderungen oder Entwurfsentscheidungen dem Rest des Teams nicht mitgeteilt werden und diese Wissenslücke die weiteren Implementierungs- und Testaktivitäten negativ beeinflusst. Unsere Hypothese ist es, dass es sinnvoll ist, Traceability in einem agilen Projekt zu unterstützen. Dies ist nach unserer Meinung notwendig, sobald ein Projekt eine Größe überschritten hat, bei der noch jedes Teammitglied das gesamte System überschauen kann oder wo ein persönlicher Kontakt, z.B. aufgrund der Laufzeit eines Projektes und der räumlichen, organisatorischen oder zeitlichen Verfügbarkeit von Personen, nicht mehr gegeben ist. TraceabilityInformationen unterstützen den Projekterfolg durch eine Überprüfung der Abdeckung (beispielsweise der User Stories durch Code und Testfälle), das Konservieren von Entscheidungen, das Unterstützen von Entscheidungsfindungen sowie die Weitergabe von Wissen, z.B. bei der Einarbeitung neuer Teammitglieder. Der Arbeitskreis 'Traceability' der GI-Fachgruppe 'Architektur' arbeitet aktuell an einem Ansatz für die Integration von Traceability in die agile Entwicklung. Der zu entwickelnde Ansatz soll leichtgewichtig sein und keine / möglichst wenige neue Artefakte in die agile Entwicklung einbringen, sondern die vorhandenen Artefakte nutzen und verbinden. Der Ansatz soll unabhängig von einem konkreten agilen Vorgehen sein, auch wenn wir ihn am Beispiel von Scrum entwickeln und darstellen. Wir stellen hier den aktuellen Stand unserer Überlegungen dar und die weitere geplante Arbeit. Lösung: Konzept und Werkzeugunterstützung Wie in Abbildung 1 dargestellt, sieht der ScrumProzess folgende Artefakte zur Erfassung der Anforderungen und zur Dokumentation der Entwicklungsvorgänge vor: Produkt-Backlog (PB), Sprint-Backlog (SB), Sprint-Tasks (ST). Die Entwickler setzen die Implementierungsaufgaben um, die in STs festgehalten werden, und checken ihren Code (Daily Results ­ DR) täglich ins Code-Repository ein. Im Laufe des Sprints werden die DRs zu funktionellen Inkrementen (I) zusammengefügt. Die Inkremente aus mehreren Sprints werden nach und nach integriert und ergeben am Ende des Projektes das fertige Produkt (P). Zur Validierung gegen die Implementierungsvorgaben werden die Codeteile nach jeder Entwicklungsphase getestet, z.B. mittels Continuous Integration oder nach Projektkonvention. Die DRs werden mittels Unit-Testfälle (UT) geprüft. Das Inkrement wird am Ende eines Sprints mittels Integrationstestfällen (IT) und RegressionstestfällendeText/Journal Article10.1007/BF033235440720-8928