zum Inhalt springen

Dokumentationskonzept

Zur Dokumentation von Projektstruktur und -ablauf werden folgende Dokumente über die gesamte Projektlaufzeit gepflegt:

  • Projektplan (MS Project)
  • Projektstrukturplan (MS Excel)
  • Terminplan (MS Excel)

Um Transparenz und Nachvollziehbarkeit zu gewährleisten, nimmt die Dokumentation im Rahmen der Fachkonzepte einen hohen Stellenwert ein. Die Grafik "Dokumentationskonzept" (s. rechte Spalte) illustriert zunächst die Zusammenhänge der im Rahmen der Fachkonzepte zu führenden Dokumente, welche anschließend erläutert werden.

Folgende Dokumente werden teilprojektübergreifend geführt:

Glossar

Basis einer effizienten Zusammenarbeit aller Projektbeteiligten ist das gemeinsame Verständnis von Fachbegriffen. Projektrelevante Fachbegriffe sind mitsamt Abkürzungen im Glossar (Typo3-Erweiterung) definiert. Erweiterungs- oder Änderungswünsche sind von den Teilprojektleitungen per Mail an Herrn Schmitz (c.schmitzSpamProtectionverw.uni-koeln.de) zu richten.

Risikoliste

Identifizierte Risiken werden von der Teilprojektleitung in der Risikoliste dokumentiert und hinsichtlich „Eintrittswahrscheinlichkeit“ und „Stufe der Schwere“ bewertet.

Prozessdifferenzliste

Entscheidet sich die Universität zu Köln dafür, einen CAMPUSonline-Standardprozess zu übernehmen, der jedoch vom vorliegenden Sollprozess abweicht, dann wird jene Abweichung in der Prozessdifferenzliste erfasst. Die Prozessdifferenzliste wird von dem Prozessbeauftragten des Projekts MCM (Hr. Schmitz) nach Rücksprache mit den Teilprojektleitungen der Universität zu Köln und der TU Graz gepflegt. Auf Basis der Prozessdifferenzliste erfolgt anschließend die Anpassung der Sollprozesse in ARIS durch den Prozessbeauftragten des Projekts MCM.

Folgende Dokumente werden teilprojektspezifisch geführt:

Logbuch

Das Logbuch ist das zentrale Dokument im Rahmen eines Teilprojekts. Es gibt den Erkenntnisfortschritt des Teilprojekts inhaltlich strukturiert wieder und verweist auf sämtliche Listen der Projektdokumentation (Risikoliste, Prozessdifferenzliste) sowie die Anforderungsmanagement-Datenbank. Zu jedem Inhaltspunkt wird festgehalten, wann und mit wem dieser besprochen wurde. Informationen hinsichtlich der Konventionen im Logbuch finden Sie hier.

Maßnahmenliste

Maßnahmen sind Aufgaben oder Entscheidungsbedarfe, welche die Teilprojektleitung in der Maßnahmenliste dokumentiert. Jede Maßnahme ist einer verantwortlichen Person zugeordnet. Über den Status kann der/die Teilprojektleiter/in den Fortschritt verfolgen.

Umsetzungsauftrag

Wenn ein CAMPUSonline-Standardprozess an einen UzK-Sollprozess angepasst werden muss, wird dies in einem Umsetzungsauftrag (UA) dokumentiert. Dieser enthält sämtliche Informationen, die ein/e Entwickler/in der TU Graz benötigt, um die Implementierung entsprechender Funktionen ohne weitere Rückfragen durchzuführen. In der Regel wird für Anforderungsbündel (AB) mit dem Umsetzungsgrad 4 je ein UA erstellt. Auf einen UA kann verzichtet werden, wenn die Anforderungen der UzK für die TU Graz ohne weitere Erläuterungen verständlich sind. Umgekehrt kann auch für AB mit Umsetzungsgrad 2 ein UA erstellt werden, um die Weiterentwicklung von CAMPUSonline zu unterstützen. Diese Frage muss zwischen den beiden Teilprojektleiter/inne/n (UzK und TU Graz) geklärt werden. Die Verantwortung für die Vollständigkeit und die inhaltliche Korrektheit eines UA liegt bei der Universität zu Köln. Die TU Graz hat jedoch eine wesentliche Mitwirkungspflicht; insbesondere wird die TU Graz auf mögliche Fehlstellen sowie auf Kompatibilität mit CAMPUSonline prüfen und hinweisen.

Soll-Anwendungsfälle (SAF) sind Bestandteil von UA. Sie dienen dazu, den Entwickler/inne/n der TU Graz die zu unterstützenden Abläufe zu verdeutlichen.

Ein SAF besteht aus:

  • einem Kontext (Beschreibung, Auslöser, Motivation aus Sicht der UzK, Vorbedingungen)
  • einer Abfolge konkreter Aktionen

Für jede Aktion wird angegeben:

  • wer sie auslöst/durchführt (Rolle)
  • welche Eingaben erfolgen (Input)
  • welches Ergebnis erwartet wird (Output)

Die Beschreibung von Aktionen sollte sich auf die Aktion selbst beschränken. Zusätzliche Informationen über das Motiv/Ziel einer bestimmten Aktion sind nicht Bestandteil des Ablaufs.

Beispiel:

SchrittAktionRolleInputOutput
1Liste erstellenSachbearbeiter/in Abt. 12BewerbungenListe von Bewerber/inne/n mit ausländischer HZB, sortiert nach dem Marburger Modell

Einerseits sollten mit geringem Aufwand möglichst generische SAF erstellt werden, andererseits müssen SAF für die Entwickler/innen der TU Graz auch ohne Kenntnis der UzK-Prozesslandschaft interpretierbar sein.

Für welche Anforderungen SAF erstellt werden, wird ebenfalls innerhalb der Teilprojekte entschieden. Die Teilprojektleiter/innen der UzK erstellen in jedem Fall SAF für Anforderungen, die sie selbst für missverständlich/uneindeutig halten. Für alle weiteren Anforderungen werden die Teilprojektleiter/innen der TU Graz gebeten, intern zu klären, ob einzelne Anforderungen erklärungsbedürftig sind.

SAF sind nicht dazu gedacht, eine konkrete Implementierung zu beschreiben. Sie sollten daher nicht auf Elemente der Benutzeroberfläche Bezug nehmen, sondern den entsprechenden Ablauf in abstrakter Form skizzieren.

Bei Bedarf können SAF durch konkrete Beispiele ergänzt werden. Ob Beispiele für das Verständnis einzelner Anforderungen benötigt werden, wird im Rahmen der Erstellung von Umsetzungsaufträgen (UA) zwischen der TU Graz und der UzK abgestimmt. In der Regel sollte die Erläuterung durch einen SAF genügen (sofern Anforderungen nicht ohnehin selbsterklärend sind).

Die TU Graz nutzt von der UzK bereitgestellte Beispiele darüber hinaus als Basis für Testprotokolle, auf die die UzK wiederum im Rahmen der Abnahme zurückgreifen kann.