Controlling
Unter Controlling verstehen wir die zielgemäße, regelmäßige Überprüfung des Weges, den die TU Graz und die UzK im Projekt MCM gemeinsam geplant haben und beschreiten. Es ist ein Werkzeug des Projektmanagements, das wirksam werden kann, wenn die Frage nach den Zielen und dem Weg geklärt ist. Sind die Etappen des Weges beschrieben, kann das Projektcontrolling als "Navigator" eingesetzt und bei Bedarf frühzeitig nachgesteuert oder auf Risiken hingewiesen werden.
Teil bzw. "Produkt" des Controllings ist das Berichtswesen, mittels dessen die Projektleitung, der Auftraggeber und weitere Anspruchsgruppen über das Erreichen oder Nicht-Erreichen von (Zwischen-)Zielen und über die eingeleiteten Maßnahmen zur Zielsicherung informiert werden.
Die Projektleitung gibt regelmäßig Statusberichte an die Projektmitglieder, den Fachausschuss und den Auftraggeber heraus, in welche die ergriffenen Maßnahmen und Ergebnisse des Controllings einfließen.
Controlling von Anforderungsbündeln
Im Zuge der Beauftragung von Individualsoftware wurden von Seiten der TU Graz jeweils mehrere Anforderungen, die auf dem erstellten Sollkonzept der UzK basieren, zu so genannten 'Anforderungsbündeln' zusammengefasst.
Zum Controlling dieser Anforderungsbündel ist folgendes Vorgehen vereinbart:
Für ein Anforderungsbündel (AB) mit dem Umsetzungsgrad (UG) 4 wird je ein Umsetzungsauftrag (UA) von den jeweiligen Teilprojekten erstellt. 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. Ein Bestandteil der UA sind Soll-Anwendungsfälle (SAF). Diese enthalten abstrakt beschriebene Prozesse und können durch konkrete Beispiele ergänzt werden. Auch für Anforderungsbündel mit UG2 kann die UzK ein Dokument mit „Umsetzungsempfehlungen“ erstellen, 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 die UA auf mögliche Fehlstellen sowie auf Kompatibilität mit CAMPUSonline prüfen und hinweisen. Die Teilprojektleitung der TU Graz meldet sich zudem rechtzeitig vor Abgabe eines Umsetzungsauftrages bei der Teilprojektleitung der UzK und meldet zurück, ob Beispiele oder weitere Angaben zur Konkretisierung der SAF benötigt werden. Die UzK stellt ebenfalls Beispiele bereit, wenn Anforderungen, die nicht durch Sollanwendungsfälle abgedeckt sind, aus Sicht der TU Graz beispielhaft erläutert werden sollen.
Die TU Graz ordnet die Anforderungsbündel ihrem Releaseplan zu und spielt das Release zu einem bestimmten Zeitpunkt, nach der Durchführung von Standart-Tests sowie dem Erstellen von Testprotokollen auf Basis der gelieferten Beispiele und der Release Notes, auf das Qualitätssicherungs-System (Q-System) ein. Die Release Notes werden von der TU Graz so gestaltet, dass für die UzK ersichtlich wird, welche Anforderungen hiermit abgedeckt werden.
Nach Auslieferung des Anforderungsbündels auf das Q-System hat die UzK ca. vier Wochen Zeit zum Testen und um Rückmeldung an die TU Graz zu geben. Im Anschluss erfolgt die Bereitstellung des Releases für das Einspielen auf dem P-System. Diese letztgenannten „Bereitstellungs-Zeitpunkte“ sind vertraglich fixiert. Nach Einspielen des Release auf das Produktions-System (P-System) gewährleistet die TU Graz sechs Wochen lang einen „Early Life Support“.
Die Abnahme eines es Anforderungsbündels erfolgt durch das gesamte Teilprojektteam im Rahmen eines Abnahmeworkshops. Die Abnahme-Zeitpunkte sind je Bündel ebenfalls vertraglich fixiert.