Konzeptionelle Erweiterung von Projektdashboards für unerfahrene Anwender

Dokumente

Hintergrund

Erfolgreiche Softwareentwicklung ist nur möglich, wenn Abläufe und Produkte möglichst genau überwacht werden können. Da es sich bei beiden um immaterielle Objekte handelt, bei denen die Begutachtung nicht trivial lösbar ist, müssen sie aufwendig vermessen werden. Zur Bewertung werden Metriken eingesetzt, die Attribute des Messobjekts vermessen. Die Relevanz von Metriken spiegelt sich in den häufig verwendeten Referenzmodellen wieder. So ist schon für eine Einstufung in CMMI Level 2 die Definition von Metriken erforderlich.

Für eine effektive Projektleitung wird ein guter Überblick über die Abläufe eines Softwareprojekts benötigt. Um einen quantifizierten Überblick zu erlangen, werden neuerdings vermehrt Projektdashboards bzw. Projektcockpits eingesetzt. Projektdashboards entsprechen Armaturen im Auto, über die der Fahrer alles Wissenswerte über den Zustand seines Fahrzeugs erfährt. Der momentane Zustand eines Projektes wird dem Projektleiter und anderen Anwendern durch ein Projektdashboard angezeigt. Die einzelnen Anzeigen entsprechen im Projektdashboard Metrikrepräsentationen. Eine Metrikrepräsentation, auch Reportitem genannt, stellt die Messergebnisse einer Metrik visuell in einem Diagramm dar.

Bei der Steuerung von Projekten machen die Projektleiter natürlicherweise Erfahrungen, wie sich ihre Entscheidungen auf den Verlauf ihres Projektes auswirken. Üblicherweise bleibt dies aber ihr persönliches Wissen, welches nur teilweise und nur auf Anfrage geteilt wird. Mit der Verbreitung und Wiederverwendung von organisationsinternem Wissen beschäftigen sich unter dem Begriff ?Knowledge Management? viele Forscher aus den verschiedensten Fachbereichen. Dabei gibt es verschiedene Ansätze, die die Informatik betreffen. Erstens wird versucht das Wissen formalisiert zu speichern, so dass dieses öffentlich und personenunabhängig zugänglich wird. Andererseits spielen computerbasierte Kommunikationswege eine Rolle, wenn das Wissen nicht in Informationssystemen gespeichert, sondern weiterhin von einer Person zur anderen übertragen wird.

Forschungslücken

Die Fülle von Informationen, die eine gewöhnliche Dashboardlösung anzeigt, könnte vor allem unerfahrene Projektleiter eher irritieren als nutzen. Anders als dem Fahrer eines Autos sollten dem Anwender eines Projektdashboards nicht gleichzeitig alle Messungen angezeigt werden, da in einem Softwareprojekt deutlich mehr und komplexere Messungen vorgenommen werden. Im Normalfall wird ein Anwender das Dashboard mit einem bestimmten Informationsbedürfnis, das er schnellstmöglich beantworten möchte, begutachten. Dementsprechend bietet es sich an, aufgrund des aktuellen Informationsbedürfnisses eine Zusammenstellung von Reportitems anzuzeigen und diese mit passenden Hilfen zu erweitern.

Des Weiteren könnten die Rolle des Nutzers, seine Erfahrung und persönliche Interessen eine Menge von ?Standardinformationsbedürfnissen? definieren, die eine Zusammenstellung von Reportitems bedingt. Das heißt, es ist zu erforschen, ob es möglich ist aufgrund von klaren Einordnungen eines Nutzers innerhalb verschiedener Dimensionen gewisse Informationsbedürfnisse als Standard definieren kann, so dass diese direkt durch das neu erstellte Dashboard befriedigt werden können. Dies würde insbesondere unerfahrene Benutzer unterstützen, die ihre Informationsbedürfnisse teilweise noch gar nicht artikulieren können.

Für unerfahrene Anwender ist außerdem das Wissen, das z.B. erfahrene Anwender beim Auswerten von Dashboards erlangt haben, besonders wertvoll. Es ist wäre nützlich das Wissen, das erfahrene Anwender, wie z.B. erfahrene Projektleiter, beim Verwalten ihrer Projekte aus den Dashboards ableiten konnten, formal abzuspeichern um es organisationsweit zugänglich zu machen. Da sich in der Darstellung der Metriken häufig bestimmte Situationen eines Projektes manifestieren, könnte es äußerst hilfreich sein, diese markanten Punkte zu markieren. Zum Beispiel werden die Auswirkungen einer Grippewelle in der Darstellung des SPI identifizierbar sein. Relevant in diesem Zusammenhang sind Erkenntnisse, die bereits andere Mitglieder der Organisation gesammelt haben. Möglicherweise haben sie auch Ursachen für diese Besonderheiten identifizieren können, die mit entsprechenden Maßnahmen unterstützt oder bekämpft wurden. Dies würde in besonderem Maße unerfahrene Anwender unterstützen, die z.B. noch Hilfe bei der Auswertung von Reportitems benötigen und durch das Expertenwissen fundiertere Entscheidungen treffen können. Sollten diese erfolgreichen Strategien durch Erfahrungen der Mitglieder schon implizit in das Wissen der Organisation eingegangen sein, so könnte eine explizite Speicherung dieser Erfahrungen für eine bessere Leistung der aller Projektleiter und damit der Projekte insgesamt sorgen. Unerforscht ist in diesem Zusammenhang, wie man das Organisationswissen in diesem speziellen Wissensfeld effektiv erfasst, überträgt, vermittelt und visualisiert.

Aufgabe

Das Ziel dieser Masterarbeit ist die Entwicklung eines Werkzeugs zur Erstellung von Dashboards, das durch die Informationsbedürfnisse der Anwender getrieben wird. Zusätzlich sollte überprüft werden, ob eine Generierung von Dashboards aufgrund von Heuristiken basierend auf der Rolle des Anwenders und seiner Erfahrung eine hilfreiche Unterstützung, insbesondere für unerfahrene Anwender, ist. Der Prozess soll in ein Web-Tool eingebettet sein, welches während der Masterarbeit entwickelt werden soll. Es soll sich besonders auf folgende Aspekte fokussieren:

Generierung eines Projektdashboards aufgrund von initialen Informationsbedürfnissen
Selektive Anzeige von Reportitems aufgrund von Informationsbedürfnissen

Weiterhin soll überprüft werden, ob eine Verknüpfung mit organisationsweitem Wissen über das Leiten eines Projektes möglich und hilfreich ist. Es soll untersucht werden, ob um Expertenwissen erweiterte Projektdashboards unerfahrene Anwender in ihrer Arbeit hilfreich unterstützen kann. Außerdem ist zu prüfen, wie die Externalization und Internalization des Wissens [vgl. Nonaka, Takeuchi: The Knowledge-Creating Company] im Umfeld von Projektdashboards vornehmbar ist. Insbesondere sollen dabei die folgenden Fragen begutachtet werden:

Ist eine formalisierte Speicherung dieses speziellen Wissens nützlich oder ist eine persönliche Strategie angemessener?
Gibt es eine einfache Art und Weise, wie das Wissen mit den Reportitems verknüpft werden kann, so dass dieses so formal beschrieben ist, dass ähnliche Situationen automatisch erkannt werden können?
Auf welche Weise sollte das Wissen dem Wissensnutzer präsentiert werden?
Sollte das Wissen erst auf Nachfrage oder automatisch präsentiert werden?