Loading...
hidden

Mobile-Version anzeigen

Meta-Navigation

Startseite – Hochschule Luzern

Sprachwahl und wichtige Links

  • Zum Inhalt springen
  • Kontakt
  • Login
  • De
  • En
Suche starten

Hauptnavigation

Departementsnavigation

  • Technik & Architektur
  • Wirtschaft
  • Informatik
  • Soziale Arbeit
  • Design & Kunst
  • Musik

Unternavigation

  • Studium
  • Weiterbildung
  • Forschung
  • International
  • Agenda
  • Campus
  • Über uns

Unternavigation

Breadcrumbs-Navigation

  1. Informatik Informatik
  2. Studium Studium
  3. Agile Softwareentwicklung Agile Softwareentwicklung
  4. Artefakte in der Softwareentwicklung Artefakte in der Softwareentwicklung

Artefakte in der Softwareentwicklung

Wie im vorhergehenden Kapitel «Agile Entwicklung - Automatisiertes Testen / DevOps» beschrieben, sind sämtliche gesammelten Informationen und gefällten Entscheidungen in einem Artefakt zu vermerken. Anleitungen für typische Softwareartefakte können dabei nützliche Wegleitungen sein.

hidden

Produkt Backlog

In der Vorbereitungsphase kann ein anfängliches Produkt Backlog als einfache Tabelle dargestellt werden.

Tabelle für das anfängliche Product Backlog
Abbildung 5: Tabelle für das anfängliche Product Backlog

Später kann ein Tool wie GitLab benutzt werden, um den Verlauf bei den Backlog Items zu verfolgen. Die nächste Abbildung zeigt ein GitLab Issue Board (Quelle: GitLab Docs, https://docs.gitlab.com/ee/user/project/issue_board.html, aufgerufen am 11. Aug. 2022)
 
Beispiel eines GitLab Issue Boards

Abbildung 6: Beispiel eines GitLab Issue Boards

Auf ILIAS gibt es ein Selbststudiums-Kurs zur Verwendung von GitLab. 

Projektmanagementplan

Der Projektmanagementplan enthält alle Informationen und Entscheidungen zum Entwicklungsprozess. Die folgenden Unterkapitel beschreiben den Inhalt eines Good-Practice Managementplans.
 
Vision und Ziele
Die Projektvision dient als Inspiration und gibt dem Projekt einen Fokus. Sie begründet kurz und bündig und leicht verständlich das Projekt und es ist wichtig, dass das ganze Team die Vision versteht, sie mitträgt und während des ganzen Prozesses darauf hinarbeitet.

Ein Ziel ist ein erwünschter zukünftiger Zustand, der kurz und klar definiert ist hinsichtlich Inhalt, Zeit und Ausmass. 
Gemeinsam mit der Auftraggeberin oder dem Auftraggeber sollen drei bis maximal sechs Ziele erarbeitet und formuliert werden.

Ziele sollen so «SMART» sein wie möglich. «SMART» bedeutet:

  • Spezifisch Das Ziel muss sich auf konkret benannte Organisationen, Rahmenbedingungen, etc., beziehen; der Zielbereich ist genau abgegrenzt.
  • Messbar Die Qualität und, wo nötig, Quantität der Zielerfüllung ist festlegbar; es lassen sich Indikatoren lassen davon ableiten.
  • Angemessen Ist es überhaupt das richtige Ziel? Braucht es die geplanten Massnahmen? 
  • Realistisch Die Aussicht auf Zielerfüllung ist gut unter den vorliegenden Rahmenbedingungen (Ressourcen, Zeit, Kompetenzen); externe, unkontrollierbare Faktoren stehen der Zielerfüllung nicht im Weg. 
  • Zeitlich festgelegt (Time-bound) Es besteht ein zeitlicher Rahmen. 

Ergebnisse 
Eine Liste aller Artefakte wird erstellt, welche die Auftraggeberin oder der Auftraggeber als Leistung des Teams erwartet.

In einem Softwareentwicklungsprojekt ist die Leistung hauptsächlich die Software selbst. Es kann jedoch sein, dass die Auftraggeberin oder der Auftraggeber eine schriftliche Dokumentation möchte, in der das Produkt und dessen Testverlauf beschrieben ist, oder in der Hilfestellung geboten wird bei der Benutzung der Software, etc.

Ergebnisse können sein:

  • Applikationssoftware
  • Dokumentation der Softwarearchitektur
  • Dokumentation von Teststrategie und -skript
  • Benutzerhandbuch
  • Handbücher zu Bereitstellung, Installation und des Unterhalts
  • Projektmanagementplan

Auftraggeberinnen und Auftraggeber wünschen sich oft vorgezogene Ergebnisse, damit sie gewisse Teile des neuen Produkts möglichst schnell benutzen können (siehe Kapitel «Roadmap»). 

Die folgende Tabelle ist ein Hilfsmittel, um die Arbeitsergebnisse eines Projekts festzuhalten:

Tabelle zum festlegen eines Projekts

Definition of Done
Nebst den Ergebnissen sind Qualitätsaspekte zu definieren, welche das Team bei der Implementierung eines Elements im Backlog erfüllen muss. Zu diesem Zweck wird eine «Definition of Done» verwendet. 
Für Software kann eine Definition of Done z.B. so aussehen: «Done bedeutet gemäss den Standards programmiert, überprüft, implementiert mit Unit Test-Driven Development (TDD), getestet mit 100% Testautomatisierung (oder gemäss Teststrategie), integriert und dokumentiert.»

Projektorganisation
Es wird eine Liste mit allen involvierten oder betroffenen Personen (die Anspruchsgruppe) erstellt, einschliesslich einer Beschreibung ihrer Rollen.
Das Projektteam wird gebildet und die Aufgaben, Kompetenzen und Verantwortlichkeiten eines jeden Mitglieds festgelegt. Je ein Teammitglied wird ernannt als Projektleiter, Scrum Owner und Scrum Master.

Roadmap
Die Roadmap ist die langfristige Planung des Projekts und dient dazu, die Wirtschaftlichkeit im Auge zu behalten.
Sie wird basierend auf dem anfänglichen Produkt Backlogs erstellt. Es ist ratsam, für die Projektdauer und den Projektaufwand zusätzliche etwas Zeit und Ressourcen einzuplanen: denn es ist ein bekanntes Phänomen, dass das ursprüngliche Produkt Backlog oft nur 80% aller Projektanforderungen enthält.
Die zentralen Elemente der Roadmap sind die  Meilensteine.
Ein Meilenstein ist ein Fixpunkt im Projektablauf, bei dem vordefinierte, messbare (Zwischen-) Arbeitsergebnisse vorliegen müssen und der es erlaubt, den Projektfortschritt und die Projektkosten zu verfolgen.
Es ist für jeden Meilenstein festzulegen, welche Artefakte (siehe «Ergebnisse») verfügbar sein müssen.
Ein Meilenstein ist erreicht, sobald die benötigten Artefakte verfügbar sind und deren Prüfung erfolgreich verlaufen ist.

Die Roadmap für eine Bachelorarbeit mit drei Meilensteinen könnte z.B. so aussehen:

 
Beispiel für Roadmap einer Bachelorarbeit mit drei Meilensteinen
Beispiel für Roadmap einer Bachelorarbeit mit drei Meilensteinen

Abbildung 7: Beispiel einer Roadmap für eine Bachelorarbeit

Release Plan
In der agilen Entwicklung ist der Release Plan ein kurzfristiges Planungsinstrument, das aufzeigt, was in den nächsten paar Sprints verfügbar sein wird. Es basiert auf den priorisierten Einträgen des Produkt Backlogs und zeigt, welche Backlog Items in welchem der anstehenden Sprints implementiert wird.

Der Release Plan kann eine einfache Tabelle sein oder mehrere Issue Boards in GitLab. 
Beispiel eines Release Plans als einfache Tabelle

Abbildung 8: Beispiel eines Release Plans als einfache Tabelle

Der Release Plan ist ein «lebendiger» Plan. Konkret heisst das, dass dieser nach jedem Sprint aktualisiert und um den Inhalt zukünftiger Sprints ergänzt wird.
Bei kleinen Projekten - beispielsweise Bachelorarbeiten - können Roadmap und Release Plan in einem einzelnen Plan kombiniert werden.

Risikomanagement
Risikomanagement dient dem Zweck, mögliche Probleme vorwegzunehmen bevor sie auftraten und über den Lebenszyklus des Projekts hinweg Aktionen auszuführen und Massnahmen zur Verhinderung dieser Probleme (und damit zum Schutz der Projektziele) umzusetzen.

Die Verwendung von Checklisten, Brainstorming mit den Anspruchsgruppen und die Berücksichtigung von Erfahrungen aus früheren Projekten sind mögliche Strategien zur Identifikation möglicher Risiken.
Jedes Risiko wird beschreiben, einschliesslich einer Einschätzung seiner Eintrittswahrscheinlichkeit und des zu erwartenden Schadenmasses. Für die grössten Risiken (siehe Risikomatrix) sollen Indikatoren für des Eintreten definiert werden sowie Strategien zur Verringerung der Eintrittswahrscheinlichkeit und/oder mögliche Korrekturmassnahmen zur Verringerung des möglichen Schadens. Als nächstes wird der Effekt dieser Aktionen beurteilt.

Die folgende Tabelle kann dabei helfen, all diese Informationen zu sammeln.

Tabelle für das Risikomanagement

Abbildung 9: Tabelle für das Risikomanagement

Zur Abschätzung der tatsächlichen Risikosituation und der Effekte des Risikomanagements kann eine Risk Matrix benutzt werden.

 
Zwei Beispiele einer Risikomatrix

Abbildung 10: Beispiel einer Risikomatrix

Es ist wichtig abzugleichen und sicherzustellen, dass die im Risikomanagement aufgeführten und beschriebenen Risiken sich mit jenen in der Teststrategie decken. Damit wird sichergestellt, dass das «risiokobasierte Testen» zu den Projektrisiken passt.

Überwachung (Controlling)
Projektüberwachung schliesst alle Aktivitäten ein, die der Entdeckung von Projektabweichungen zwischen dem geplanten und dem tatsächlichen Zustand dienen.
Mögliche Gründe für solche Abweichungen sind:

  • Veränderte oder neue Projektanforderungen vergrössern den Projektaufwand
  • Unzureichende Aufwandschätzung in der Sprintplanung
  • Falsch verstandene Anforderungen
  • Eintreten eines Risikos
  • Ineffizientes Teamwork

Jede der oben beschriebenen Abweichungen kann mit einem entsprechenden Tool entdeckt werden.

Veränderte oder neue Anforderungen
Die Project Burndown Chart zeigt den über die Zeit hinweg noch ausstehenden Arbeitsaufwand gemäss Produkt Backlog. Die Sprints werden auf der X-Achse als Zeitmarker gesetzt.
Die Trendlinie in der Project Burndown Chart zeigt in der Regel nach unten. Wenn allerdings neue Items zum Backlog hinzugefügt werden, wird sich die Anzahl der verbleibenden Storypoints nach oben bewegen.

 
 
Projekt-Burndown Chart

Abbildung 11: Projekt-Burndown Chart

In der Literatur wird statt «Projekt-Burndown Chart» auch oft der Begriff «Release Burnout Chart» verwendet. «Release» bedeutet in diesem Fall die erwarteten Ergebnisse für einen Meilenstein.

Unzureichende Schätzung des Aufwands bei der Sprintplanung
Um die Fähigkeit des Teams zu verbessern, seinen Aufwand in der Sprint-Planung abzuschätzen, sollten für jeden Sprint die Schätzungen mit dem effektiven Aufwand verglichen werden. Natürlich muss entsprechend jedes Teammitglied den geleisteten Aufwand pro Task oder User Story notieren, um effektive Daten zu erhalten.

Tabelle Rückblick Sprintaufwand
Abbildung 12: Rückblick Sprintaufwand

Diese Resultate werden im Team besprochen ( siehe Retrospektive)

Missverstandene Anforderungen
Am Ende jedes Sprints präsentiert das Team die Resultate im Rahmen der Sprint Review vor den Anspruchsgruppen. Es kann auch das Produkt Backlog anpassen, um neue Ziele zu erreichen.
Die Erkenntnisse aus der Sprint Review sind für jeden Sprint zu dokumentieren.

Vorhandene Risiken
Risiken werden periodisch überwacht als Teil des Projekt-Controllings. Falls nötig wird erneut eine Risikoanalyse ausgeführt, z.B. bei neuen Backlog Items oder substantiellen Projektänderungen.
Alle Änderungen in der Projekt-Risikoliste müssen für jeden Sprint dokumentiert werden.

Ineffizientes Teamwork
Der Zweck der Sprint-Retrospektive ist zu besprechen, wie vergangene Sprints gelaufen sind in Bezug auf die beteiligten Leute, Beziehungen, Prozesse und Tools.
Die Resultate jeder Sprint-Retrospektive müssen dokumentiert werden.

Projektsupport
Es ist zu beschreiben (z.B. in Form einer Installationsanleitung) wie das Entwicklungsumfeld aufzubauen ist. Welche Tools, Server, Datenbanken, Frameworks und Bibliotheken braucht es für die Entwicklung und das Testen?
Die Organisation der Projektablage (Repository) ist zu beschreiben. Wo befindet sie sich und welche Dateistruktur wird benutzt?
 
hidden

Softwarearchitektur - Dokumentation

Das Softwarearchitektur-Dokument beschreibt alle Aspekte eines Produkts. 
Eine empfehlenswerte Struktur ist beschrieben in der «arc42 initiative» von Gernot Starke, Peter Hruschka und Ralf D. Müller.
Eine Übersicht der arc42 Softwarearchitekturdokument-Kapitelstruktur zeigt die nächste Abbildung (Quelle: arc42 Template Overview, https://arc42.org/overview, aufgerufen am 11. Aug. 2022).

 
Übersicht der Kapitelstruktur nach arc42 für ein Softwarearchitektur-Dokument

Abbildung 13: Übersicht der Kapitelstruktur nach arc42 für ein Softwarearchitektur-Dokument 

Die arc24 Website https://arc42.org/ erklärt im Detail die Struktur, die benutzt werden kann, um eine Softwarearchitektur zu bauen, zu kommunizieren und zu dokumentieren.
Zusätzlich zur detaillierten Erklärung der vorgesehenen Kapitelinhalte enthält die Website Tipps und Beispiele aus der Praxis.

 
  • Agile Softwareentwicklung
  • Projektarten
  • Aufgaben in der Softwareentwicklung
  • Artefakte in der Softwareentwicklung

Footer

FH Zentralschweiz

Links zu den Social-Media-Kanälen

  •  Facebook
  •  Instagram
  •  Twitter
  •  LinkedIn
  •  YouTube
  •  Flickr

Kontakt

Logo Informatik

Hochschule Luzern

Informatik
Administration Office Sekretariat Aus- und Weiterbildung

Campus Zug-Rotkreuz
Suurstoffi 1
- 6343 Rotkreuz

+41 41 349 30 70

informatik@hslu.ch

Öffnungszeiten

von Montag bis Freitag
08:00 - 12:00 und
13:00 -17:00 Uhr

Direkteinstieg

  • Studieninteressierte Bachelor
  • Studieninteressierte Master
  • Weiterbildungsinteressierte
  • Unternehmen & Institutionen
  • Medienschaffende
  • Für Studierende
  • Für Mitarbeitende

Quicklink

  • Personensuche
  • Standorte
  • Aktuell
  • Bibliothek
  • Agenda
  • Jobs & Karriere
  • Räume mieten
  • Blog

Statische Links

  • Newsletter abonnieren
  • Datenschutzerklärung
  • Impressum
  • Institutionell akkreditiert nach HFKG 2019–2026
Logo Swissuniversities

QrCode

QrCode
Wir verwenden Cookies, um Ihnen eine optimale Nutzung der Website zu ermöglichen und um Ihnen auf unserer Website, auf anderen Websites und in sozialen Netzwerken personalisierte Werbung anzuzeigen. Indem Sie diesen Hinweis schliessen oder mit dem Besuch der Seite fortfahren, akzeptieren Sie die Verwendung von Cookies. Weitere Informationen zu diesen Cookies und wie Sie die Datenbearbeitung durch sie ablehnen können, finden Sie in unserer Datenschutzerklärung.
OK