Oftmals stößt man in verschiedenen Softwareprojekten auf immer die selben Herausforderungen: Fehlende Entwicklungs-, Test- oder Produktionsumgebungen zu einem bestimmten Zeitpunkt, unsauber formulierte Anforderungen, nicht Einhaltung von Codingstandards im Quellcode, fehlende Tests und Dokumentationen, um nur einige zu nennen. Viele dieser Probleme sind auf fehlende Kommunikation und unterschiedlichen Wissensstand der involvierten Parteien innerhalb des Projekts zurückzuführen. Eine mögliche Lösung um diesem Problem entgegen zu wirken ist die Arbeit mit Artefakten und Artefakt-Sets.

Was sind Artefakte?

Artefakte entstehen, zu einem großem Teil auch implizit, in jedem Softwareprojekt. Als Artefakte bezeichnet man alle Arbeitsergebnisse (Work Products) innerhalb eines Projekts. Dies bezieht sich nicht alleine auf die Erstellung der Software, es beinhaltet auch Vorarbeiten und Zwischenergebnisse, die für die Durchführung des Projekts notwendig sind. Artefakte sind notwendig um Projektinformationen zu erfassen, wodurch man mit Hilfe der Planung den Status des Projekts ermitteln und vermitteln kann. Dadurch bekommt jedes Projektmitglied Zugriff auf alle relevanten Informationen. Ein Artefakt kann sein:

• Ein Dokument, z.B. das Software Architectur Document
• Ein Model, z.B. ein Use-Case Model oder Desgin Model
• Ein Model Element, z.B. eine Klasse oder ein Subsystem innerhalb eines Model

Ein Artefakt kann weitere Artefakte beinhalten. So kann zum Beispiel die Software Requirement Specification aus der Supplementary Specification und diversen Use-Case Models bestehen. Die meisten Artefakte stehen außerdem in Beziehung zu anderen Artefakten. Ich halte mich bei der Namensgebung einzelner, in diesem Beitrag genannter Artefakte, an den Rational Unified Process (RUP), allerdings lassen sich diese auch auf fast alle anderen bekannten Projektmethodiken übertragen.

Was sind Artefakt-Sets?

Viele Artefakte lassen sich in sogenannte Sets gruppieren. Diese Sets können dann verschiedenen Rollen innerhalb des Projekts zugewiesen werden. Die Rollen sind dann für die Erstellung und/ oder Kontrolle der einzelnen Artefakte innerhalb des Sets verantwortlich. Im folgenden liste ich die wohl gängigsten Sets in einem Softwareprojekt auf:

• Business Modeling: Dieses Set beinhaltet alle Artefakte, die zum Teil bereits vor dem Start des eigentlichen Projekts zusammengetragen werden. Das beinhaltet Dokumente wie Business Rules, Business Vision, aber auch Models wie das Business Use Case Model. Die Artefakte in diesem Set dienen zum Großteil als Input und Referenz für die Erstellung der Requirements. Verantwortlich für dieses Set sind in der Regel die Rollen Business Process Analyst oder Business Designer auf Kundenseite.
• Requirements: In diesem Set finden sich alle Artefakte zur Beschreibung der zukünftigen Funktionalität des geplanten Systems. Mögliche Artefakte dieses Sets sind: Requirements Management Plan, Requirement Specification, Stakeholder Requests. Verantwortliche Rollen für dieses Set sind der System Analyst und der Requirements Engineer.
• Analysis & Design: Die Artefakte in diesem Set repräsentieren alle notwendigen Informationen, zur geplanten technischen Umsetzung der Anforderungen aus dem Requirements Set. Artifakte in diesem Set sind zum Beispiel: Software Architecture Document, Analysis Model, Design Model, Data Model. Verantwortlich zeigen sich hierbei in der Regel der Software Architect und der Database Designer.
• Implementation: In diesem Set finden wir alle Artefakte, die während der Implementation der Lösung entstehen. Dies beinhaltet alle entwickelten Components, Implementierungen in Subsystemen (Implementation Subsystems) wie Interfaces, den Integration Build Plan, und Dokumentationen, wie das Implementation Model. Verantwortlich für dieses Set zeigt sich neben dem Implementor und Integrator auch der Software Architect
• Test: Neben der Implementation sollte in modernen Softwareprojekten auch ein großer Fokus auf Tests liegen. Daher existiert für Tests ein eigenes Set an Artefakten. Dieses beinhaltet unter anderem die folgenden Artefakte: Test Plan, Test Log, Test Evaluation Summary, Test Scripts, Test Cases, Test Environment Configuration Model. Verantwortlich zeigen sich hierbei die folgende Rollen: Test Manager, Test Analyst, Test Designer, Tester.
• Deployment: Dieses Set beinhaltet alle Artefakte um ein Softwareprojekt nach erfolgreicher Implementierung und Test in Produktion zu setzen. Beinhaltete Artefakte in diesem Set sind: Das eigentliche Product, der Deployment Plan, Installation Artifacts, aber auch Dokumentationen wie Release Notes und End-User Support Material. Verantwortlich für dieses Set sind in der Regel die folgenden Rollen: Deployment Manager, Implementer, Configuration Manager und Technical Writer
• Project Management: Dieses Set beinhaltet alle Artefakte im Projektplanung und Ausführung. Es beinhaltet unter anderem die folgenden Artefakte: Software Development Plan, Iteration Plan, Risk List, Work Order, Product Acceptance Plan, Measurement Plan, Quality Assurance Plan, Issue List. Verantwortlich für dieses Set sind sowohl der Project Manager als auch die Rolle des Project Reviewers
• Configuration and Change Management: In diesem Set findet man alle Artefakte aus dem Configuration & Change Management des laufenden Projekts. Dies beinhaltet unter anderem den Configuration Management Plan und Change Requests. Verantwortlich hierfür sind im besonderen die Rolle des Configuration Manager und Change Manager.
• Environment: Neben den Artefakten für die technischen Environments innerhalb des Projekts (Development Infrastructure) enthält dieses Set auch alle Artefakte, die für die notwendige Konsistenz innerhalb des Projekts sorge tragen. Dies beinhaltet: Project-Specific Templates, Business Modeling Guidelines, Programming Guidelines, Test Guide Lines, Tool Guidelines, Tools und Manual Style Guidelines. Verantwortlich für dieses Set sind die folgenden Rollen: Process Engineer, Business Process Analyst, Software Architect, System Analyst, System Administrator, Tool Specialist und Test Designer.

Nicht alle Rollen müssen zwangsweise jeweils durch eine einzelne Person besetzt werden. Daher habe ich hier auch lediglich die Rollen benannt, wie sie in RUP vorkommen. So besitzt der RUP insgesamt über 30 verschiedene Rollen, wohingegen Scrum lediglich 6 Rollen laut Lehrbuch vorsieht. Auch bedeutet die Verantwortlichkeit für bestimmte Sets nicht automatisch, dass diese Rolle auch für die Erstellung des jeweiligen Artefakts verantwortlich ist. In bestimmten Fällen ist es sogar recht nützlich manche Artefakte zumindest in Zusammenarbeit mit anderen Rollen zu erzeugen. Ein Beispiel hierfür sind die Artefakte Tools und Tool Guidelines. Die Verantwortlichkeit liegt hierbei eigentlich beim Tool Specialist, allerdings sollte dieser Rücksprache mit den jeweiligen Rollen halten, die diese Tools auch einsetzen.

Wie gehe ich mit Artefakten um?

Die beste Sammlung von Artefakten und der größte Detailgrad hilft nichts, wenn man nicht weiß, wie man mit ihnen umgehen soll. Wichtig ist, dass für jedes Mitglied eines Projekts ersichtlich ist, wo die für seine Arbeit notwendigen Artefakte zu finden sind und wo fertiggestellte Artefakte abzulegen sind. Hierbei ist es empfehlenswert auf ein Content Management Systeme (CMS) und Collaboration Tools zu setzen. Für die Implementation einzelner Components sollte man auf eine Versionsverwaltung (z.B. git) großen Wert legen. Auch für Projektplanung, FollowUp und Changemangement gibt es eine große Auswahl an Software am Markt.

Wichtig für die Planung ist, dass Artefakte in Abhängigkeitsbeziehungen zu einander stehen können. Aus diesem Grund ist, gerade im agilem Projektumfeld, bei der Planung mit Artefakten darauf zu achten das bestimmte Reihenfolgen eingehalten werden. Beispielsweise kann ohne ein abgenommenes Software Architecture Document nicht mit der Einrichtung von Environments begonnen werden. Ohne Environments kann nicht mit der Implementation begonnen werden, usw.

Ein wesentlicher Punkt ist es auch Abnahmekriterien für bestimmte Artefakte zu definieren. Für den Bereich der Implementation bieten sich hierbei Tools wie Gerrit, als kollaboratives Review Tool und SonarQube für die Codeanalyse an. Für Artefakte in Form von Dokumenten sollte man einen Review Prozess bei der Erzeugung, bei denen die als Arbeitsgrundlage für andere Artefakte dienen einen Übergabeprozess etablieren.

Was sind die wichtigsten Artefakte in einem Projekt?

Diese Frage ist nicht eindeutig zu klären. Ebenso wenig ist die Menge an Artefakten nicht ausschlaggebend für den Erfolg eines Projektes. Dennoch gibt es ein „Best Practice“ an Artefakten, die es in einem Projekt mindestens geben sollte. Einen Ausschnitt daraus gibt es hier:

• Software Requirement Specification: Das eigentliche Pflichtenheft beinhaltet alle Anforderungen an das Projekt.
• Glossary: Beschreibt die projektspezifischen Terminologien.
• Software Architecture Model: Beschreibt aus Sicht der Software Architektur alle relevanten Themen. Hierzu gehören unter anderem technologische Entscheidungen (Programmiersprachen, Frameworks, Datenbanken) und der Aufbau der Infrastuktur des Projekts (Umgebungen, Hardware, Software, Schnittstellen zu anderen Systemen).
• Software Development Plan: Ist der Top-Level Plan für das Software Projekt. Er wird benötigt um die jeweiligen Projektschritte zu planen. Hier fließen alle Informationen zusammen, auf deren Basis man den Status des Projekts festellen kann. Er beschreibt außerdem den Ansatz des Softwareprojekts.
• Risk List: Ist eine Liste mit allen bekannten und offenen Risiken für das Projekt anfallen können. Für jedes Risiko sollte zeitnah ein Action Plan mit möglichen Lösungen erstellt werden.
• Deployment Plan: Dieser Plan beschreibt alle Schritte, die notwendig sind um das entwickelte Produkt zu deployen und anschließend an die User Organisation zu übergeben.
• Test Plan: Beinhaltet alle geplanten Strategien und Aktivitäten um die in einzelnen Iterationen gelieferten Komponenten und das fertige Endprodukt auf Grundlage der Anforderungen zu testen und verifizieren.
• Components: Die einzelnen abgelieferten Komponenten, die später zusammengefasst als fertige Software abgeliefert werden.

Diese Liste soll natürlich nur als Basis dienen. Wie eingangs bereits erwähnt, entwickeln sich viele Artefakte aus einem Projekt heraus von ganz alleine. Wichtig ist, dass hierbei keine doppelte Arbeit gemacht wird und alle Projektmitglieder jederzeit über neue und geänderte Artefakte informiert werden, die für ihre Arbeit notwendig sind.