Inhaltsverzeichnis. 2. Grundlagen Metriken CMMI MeDIC Sonstige Werkzeuge zur Aktivitätsverwaltung...

Transkript

1 Bachelorarbeit Realisierung eines Werkzeugs zum Management von Messspezischen Projektaktivitäten Realisation of a Tool to Manage Measurement Specic Project Activities von Christoph Greven Vorgelegt der: Fakultät für Mathematik, Informatik und Naturwissenschaften der Rheinisch- Westfälischen Technischen Hochschule Aachen im Mai 2011 Angefertigt am: Lehr- und Forschungsgebiet Informatik 3 Prof. Dr. rer. nat. Horst Lichter Gutachter: Prof. Dr. rer. nat. Horst Lichter Prof. Dr. Bernhard Rumpe Betreuer: Dipl.-Inform. Matthias Vianden

2

3 Inhaltsverzeichnis 1. Einleitung Überblick über die Arbeit Beschreibung der Aufgabenstellung Überblick über die Ausarbeitung Anmerkungen zur Ausarbeitung Danksagungen Grundlagen Metriken CMMI MeDIC Sonstige Werkzeuge zur Aktivitätsverwaltung Anforderungen und Ziele Modell Werkzeug Modell der Metrikativitäten Artefakte Aktivitäten Rollen Industrieller Einsatz Werkzeugunterstützung Papierprototyp Klickdummy Evolution Reexion und Ausblick Zusammenfassung Evaluation Ausblick A. Anhang 41 A.1. Projektierung der Bachelorarbeit A.2. Anfängliches Glossar zu Aktivitäten und Akteuren A.3. Protokoll des letzten GDIS-Meetings Literaturverzeichis 51 i

4

5 Abbildungsverzeichnis 4.1. Produktionskette aus Artefakten bzw. Informationsentitäten [Legende 4.1] Produktionskette ohne Kennzahlen [Legende 4.1] Produktionskette mit Aktivitäten [Legende 4.1] Produktionskette mit Akteuren [Legende 4.1] Domänenmodell (UML Klassendiagramm) Aktivitäten in Entitätsversionen (UML Klassendiagramm) Produktionskette für GDIS Anwendungsfälle in UML Anwendungsfall Metrikverwaltung in UML Erster Paperprototyp: Projektübersicht mit Daten-Fokus Paperprototyp: Projektübersicht mit Berichte-Fokus Paperprototyp: Projektübersicht mit Aktivitäten-Fokus Paperprototyp: Neuen Report erstellen Erster Klickdummy: Projektübersicht, Fokus Berichte Erster Klickdummy: Aktivität erstellen Erster Klickdummy: Eigene Aktivitäten Klickdummy: Berichte auf gleicher Stufe mit Cockpits Klickdummy: Angebot von Aktivitäten bei neuem Cockpit Klickdummy: Aktivitäten neu präsentiert Klickdummy: Auswahl von vorhandenen Aktivitäten Klickdummy: Automatische Erzeugung von zugehörigen Aktivitäten Klickdummy: Erzeugung eigener Sammel-Aktivitäten iii

6

7 Tabellenverzeichnis 4.1. Legende zu Abbildung 4.1, 4.2, 4.3, und v

8

9 1. Einleitung Inhalt 1.1. Überblick über die Arbeit Anmerkungen zur Ausarbeitung Metriken gewinnen in der heutigen Wirtschaft immer mehr an Bedeutung. Sie stellen eine gute Möglichkeit dar, komplizierte Softwareentwicklungsprozesse in Projekten zu messen und so qualitativ und quantitativ einzuordnen. Damit können Probleme der sonst abstrakten Hergänge erkannt und an dessen Lösungen gearbeitet werden, um eine Ablaufverbesserung zu erzielen. Trotz dieser mächtigen Werkzeuge werden oft nicht die gewünschten Erfolge erzielt. Das liegt meist an falscher oder unvollständiger Anwendung, denn die noch neuen Methoden und der Umgang mit diesen sind wenig bekannt und etabliert. Das MeDIC ist ein Softwaresystem, welches für die Generali Deutschland Informatik Services entwickelt wird, und den Umgang mit Metriken weiter erleichtern soll. Dies realisiert ein zentrales Verwaltungs-, Entwicklungs- und Dokumentationswerkzeug rund um Metriken. Dieses Tool soll die Prozessverbesserung nach CMMI erhöhen, doch reicht es nicht aus, um neusten Methoden nachzukommen. Dazu müssen neben den Objekten, wie Metriken, auch die Zusammenhänge derer, sowie die damit verbundenen Aktivitäten und Aufgaben analysiert werden. Als Erweiterung für das MeDIC soll also ein Aktivitäten-Management-System entwickelt werden, was Ziel dieser Arbeit ist Überblick über die Arbeit Dieser Überblick besteht aus der Beschreibung der Aufgabenstellung, deren Diskussion, der Formulierung der Ziele Beschreibung der Aufgabenstellung Ziel dieser Arbeit ist die Realisierung eines Werkzeugs zum Management von Messspezischen Projektaktivitäten. Die ursprüngliche Aufgabenstellung dazu lautet wie folgt: Ziel dieser Arbeit ist die Realisierung eines webbasierten Softwaretools zum Verwalten und Dokumentieren von Metrik-Aktivitäten. Dies soll im Rahmen einer 1

10 1. Einleitung Integration in das bereits bestehende MeDIC 2.0 geschehen. Das auf EJB 3.0 basierte System soll mit dem IBM Rational Application Developer entwickelt werden und unter Websphere lauähig sein. Das Hauptaugenmerk der Arbeit liegt auf den Metrik-Aktivitäten Daten liefern, Interpretieren und Berichten, kann aber optional um projektweite Aktivitäten erweitert werden. Zur Übersicht ist hierfür ein "Messplanÿu erstellen, der eine Auistung aller Metrikaktivitäten realisiert. Weiter müssen aufgabenspezische Details, wie bereits erwähnt, zu jeder Aufgabe gespeichert werden. Die verschiedenen Metrikrollen, also die Rollen bezüglich einer Metrik, sollen dabei automatisch aus den Projektrollen ermittelt und dementsprechend übernommen werden. (Siehe dazu auch das anfängliche Proposal A.1.) Allerdings wurde bei der Entwicklung festgestellt, dass eine Implementierung des Werkzeuges über den Umfang dieser Arbeit hinaus geht. Stattdessen beschränkt man sich hier auf die grundlegende Analyse und Entwicklung eines geeigneten Modells sowie einiger Prototypen, auf deren Basis eine spätere Implementierung problemlos möglich ist Überblick über die Ausarbeitung Die anschlieÿende Ausarbeitung ist wie folgt aufgebaut. Nach der Einleitung werden in Kapitel 2 die Grundlagen, auf den weiteres Vorgehen aufbaut, verständlich gemacht. Diese untergliedern sich in vier Teile: Eine kurze Übersicht über Metriken, die Familie von Referenzmodellen CMMI, das MeDIC System als eine Implementierung dafür und die Erweiterung durch das Activity Management, sowie die Diskussion alternativer PMMs. Weiter wird in 3 auf die Anforderungen und Ziele dieser Ausarbeitung, im Wesentlichen das theoretische Modell und die praktische Werkzeugumsetzung, eingegangen. Kapitel 4 zeigt die konkrete Entwicklung des Modells und die darin benutzten Artefakte, Aktivitäten und Rollen, wonach noch die Anpassungen für einen industriellen Einsatz besprochen werden. Ferner präsentiert Kapitel 5 das Werkzeug in Form von Papierprototypen und Klickdummys sowie die damit verknüpften Anwendungsfälle. Schlieÿlich gibt Kapitel 6 nochmal eine Zusammenfassung und einen Ausblick über mögliche Weiterentwicklungen Anmerkungen zur Ausarbeitung Ein wichtiges Ziel des Werkzeuges sollte die Wiederverwendbarkeit von fertig denierten Informationsstrukturen sein. So müssen Einzelheiten nicht im Detail jedes mal neu speziziert werden, sondern die Anwender können auf Best- Practise Modelle mit einem Klick zurückgreifen. Dieser Aspekt bleibt aber leider unbeachtet, da hier erst Grundlagenarbeit geleistet werden muss. Er wird aber als spätere Weiterentwicklung festgehalten. 2

11 1.2. Anmerkungen zur Ausarbeitung Danksagungen An dieser Stelle möchte ich mich bei allen bedanken, die mich bei der Entwicklung dieser Arbeit unterstützt haben. Ein besonderes Dankeschön an Dipl.- Inform. Matthias Vianden, dessen Zusammenarbeit sehr aufschlussreich war und mir ferner viel Spaÿ gemacht hat. Dank gilt auch Dr. Karl-Joachim Neumann von der GDIS. 3

12

13 2. Grundlagen Das Wissen ist Kind der Erfahrung. (Leonardo da Vinci) Inhalt 2.1. Metriken CMMI MeDIC Sonstige Werkzeuge zur Aktivitätsverwaltung In diesem Kapitel werden die Grundlagen, auf denen die weitere Arbeit aufbaut, geschaen. Dazu gibt es nachfolgend einen kurzen Einblick in Metriken, CMMI, MeDIC und alternative Aufgabenverwaltungs- bzw. PMM-Tools Metriken In Projekten jeglicher Art, insbesondere auch in Softwareentwicklungsprojekten, ist die Prozesssteuerung, und somit die Steuerung der Qualität, von zentraler Bedeutung. Dabei geht es im Wesentlichen um die Verbesserung des Projektmanagements, des Prozessmanagements oder der einzelnen eingesetzten Techniken. Übergreifend ist allerdings festzustellen, dass eine Verbesserung ebenjener für gewöhnlich auch eine Verbesserung des Endproduktes nach sich zieht. Um eine Qualitätsveränderung festzustellen, und darauf reagieren zu können, bedarf es einer Möglichkeit, die Qualität in einer vernünftigen Weise zu ermitteln. Zum Abschätzen bzw. Messen können an dieser Stelle oftmals Metriken (oder auch Softwaremetriken) eingesetzt werden und Abhilfe beim Erfassen der sonst ungreifbaren Gröÿen schaen. Eine Metrik ist eine Funktion, für gewöhnlich eine mathematische Rechenvorschrift, um aus einzelnen Eingangsdaten eine oder mehrere Kennzahlen zu errechnen, deren Bezug zu vorher festgelegten Schwellwerten darüber Aufschluss gibt, wie eine oder mehrere der betrachteten Eigenschaften des Projektes zu bewerten sind. Dies kann relativ zu vergleichbaren Werten wie auch absolut zu festen Skalen geschehen. Die Benutzung von Metriken bringt allerdings auch einige herausfordernde Probleme mit sich. Der gebende Impuls einer Metrik kann als Frage an das Projekt 5

14 2. Grundlagen aufgefasst werden. Diese muss aber erst mal konkret deniert werden. Sobald deniert ist, welches Informationsbedürfnis mit einer Metrik gedeckt werden soll, müssen unter Umständen verschiedenste Messdaten beanstandet werden, aus denen nach einer konkreten Vorschrift entsprechende Kennzahlen abgeleitet werden können. Dass diese Vorschriften und dahinter steckende Ideen in der Realität auf den ersten Blick durchaus kompliziert sein können, ist klar. Doch die kompliziertesten Rechnungen helfen dann nicht weiter, wenn man diese nicht auch entsprechend zu interpretieren weiÿ. Die bereits erwähnten Schwellwerte beruhen in der Regel auf Erfahrung, und stellen daher keine diskreten Informationen wie richtig oder falsch dar. Vielmehr sollen sie ein besser oder schlechter signalisieren. Die Abweichungen der Best-Practise-Werte einzelner Projekte oder, in einem weiteren Sinne, Unternehmen variieren daher enorm. Wenn eine Kennzahl erzeugt wurde und mit einem Schwellwert verglichen werden kann, so umfasst dies noch längst nicht die korrekte Interpretation dieser und der daraus resultierenden Reaktionen. Die Frage, wie eine angemessene Reaktion aussieht, kann nicht einfach beantwortet werden. Gewöhnlich haben viele Dinge Einuss auf eine Kennzahl, sodass mit einzelnen Maÿnahmen nicht nur die Erzielung einer Verbesserung schwierig ist, sondern auch noch unbedachte Randeekte auftreten können. Bei allem darf die Tatsache nicht unbedacht bleiben, dass Metriken nur versuchen die komplexe Wirklichkeit auf simple Informationen herunter zu brechen, dass dieses Prinzip oft funktioniert, oftmals aber nicht alles durch eine einfach Formel auzudrücken ist. Ein weiterer wichtiger Faktor, der oft vergessen wird, sind die Kosten die durch Verwendung von Metriken entstehen, da die Datenerhebung gigantische Auÿmaÿe annehmen kann, Analysen und Interpretationen von kompetenten Fachkräften durchgeführt werden müssen, etc. Dabei sind dadurch erzielte Verbesserungen unter Umständen nicht direkt erkennbar. Im Bereich der Softwareentwicklung kommt erschwerend hinzu, dass das Messen an sich ein wesentliches Problem darstellt. Produkte sind hier zwar auch oftmals von Beginn an klar deniert, doch Teilfortschritte bei der Entwicklung und vor allem in dem Entwicklungsprozess sind schwer denierbar. Die vielzahligen genannten Probleme sollen den Nutzen von Metriken bei korrekter Handhabung aber nicht schmälern. Dabei ist zu beachten, dass mehr eingesetzte Metriken aber nicht automatisch mehr Erfolg bringen. Zahlreiche Anwendungen, die die Kernproblematik verfehlen, bringen dann weniger Nutzen, als eine Metrik, die das Problem genau erfasst. Um einen klareren Eindruck des Begris Metrik zu erlangen, seien hier beispielhaft einige oft verwendete Metriken beschrieben: LOC - Lines Of Code: Anzahl der geschriebenen Codezeilen Anweisungs-/Zweig-/Pfad-/Bedingungs-Überdeckungstest: Verhältnis der Anzahl ausgeführter Anweisungen/Zweige/Pfade/Bedingungen zu allen Anweisungen/Zweigen/Pfaden/Bedingungen 6

15 2.2. CMMI SPI - Schedule Performance Index: Maÿ dafür, in wie weit ein Projekt seinem Zeitplan genügt 2.2. CMMI Die Capability Maturity Model Integration (CMMI) ist eine Sammlung verschieder bewährter Referenzmodelle mit dem Ziel der kontinuierlichen Prozessverbesserung in einer Organisation. Neben CMMI for Development (CMMI-DEV) [1], das auf Produktentwicklung ausgelegt ist, gibt es noch zwei weitere Modelle CMMI for Acquisition (CMMI-ACQ), für den Produkteinkauf, und CMMI for Services (CMMI-SVC), für Dienstleistungen. Das Hauptaugenmerk liegt dabei auf der Denition des Was?, mit grundsätzlichen Praktiken, und nicht des Wie?, mit zu konkreten Schritten, sodass die CMMI-Modelle gleichermaÿen universell wie anpassungsfähig sind, und somit mit verschiedensten Strukturen in Einklang stehen. Darüber hinaus bietet die Sammlung auch diverse unterstützdende Maÿnahmen an, um nicht nur in dem gewöhnlichen fachspezischen Aktivitäten einer Organisation zu verharren, sondern auch übergreifend zu unterstützen. In der Marktwirtschaft gewinnt CMMI weiter an Bedeutung, indem sich Firmen nicht nur an die CMMI-Modelle halten, sondern sich darüber hinaus durch die dort spezizierten Reifegrade bei oziellen Überprüfungen auszeichen. Die Reifegrade sprechen dabei für die Etablierungsstärke der Prozessverbesserungen von Initial über Managed, Dened und Quantitatively Managed zu Optimizing. CMMI-DEV ist in verschiedene Prozessgebiete eingeteilt, darunter auch Messung und Analyse (MA) aus der Kategorie Support. Dies beinhaltet beispielsweise auch das Kontrollieren und Verbessern der Entwicklungsprozesse mit Metriken. Wie in der aktuellesten Version 1.3 von CMMI [2] speziziert (im Gegegensatz zu der älteren Version 1.2 [1]), reicht die Betrachtung allein von Metriken zur Optimierung aber nicht aus. Alle damit verbundenen Aktionen bzw. Aktivitäten müssen auch Arbeitsbestandteil werden, sodass periodische Abläufe, wie beispielsweise Datenerhebung, durchweg speziziert und dokumentiert sind. Das heiÿt, es wird festgehalten, wer interagiert, in welchem Intervall dies geschieht, wo Daten gespeichert werden, etc. um dieses Wissen später zur Prozessverbesserung einzusetzen MeDIC Die MeDIC - Metric Denition, Integration and Calculation - ist ein Softwareprogramm zum Denieren und Verwalten von Metriken für Projekte. Es wird für die Generali Deutschland Informatik Services GmbH (GDIS) entwickelt und ist so für Softwaremetriken gedacht. Das Werkzeug stellt die Metriken in den Mittelpunkt und ist selber in drei Hauptentwicklungsstufen (die auch bereits aus dem Namen hervorgehen) unterteilt, die nach bisherigem Stand noch nicht 7

16 2. Grundlagen alle umgesetzt sind: Denition Umfasst die Spezizierung, Bearbeitung, Verwaltung, u.ä. von Metriken und zugehörigen Komponenten. Darunter fällt beispielsweise auch eine Benutzerverwaltung. Integration Umfasst die Integration in die bestehende Infrastruktur bei GDIS bzw. auch die Ersetzung vorhandener durch das MeDIC. Kalkulation Letztlich soll das System nicht nur für textuelle Beschreibungen und Dokumentation genutzt werden, sondern alle Berechnungen, wie die Errechnung der Kennzahlen durch die Metriken, direkt selber ausführen. Derzeit steht das Projekt vor einer ersten Pilotierung, um im Wesentlichen die Abdeckung und die Annahme des ersten Entwicklungspunktes zu prüfen. Die MeDIC soll den Umgang mit Metriken erleichtern und dabei die vollständige und korrekte Denition dieser fördern. Für verdschiedene Projekte gibt es einen Überblick über die verwendeten Metriken, wobei zwischen speziell angepassten Projektmetriken, die nur im Kontext eines Projektes verwendet werden, und projektübergreifenden Standardmetriken, die auf bewährten Erfahrungswerten oder allgemeinen Vorlagen aufbauen, dierenziert wird. Für die Benutzer des Systems besteht die Möglichkeit, neue Metriken vorzuschlagen, diese anzupassen, später zu verwenden oder, wenn momentan kein Verwendungsbedarf besteht, auch zu deaktivieren. Die Relation eines Benutzers zu einem Projekt bzw. den darin verwendeten Metriken ist durch Rollen deniert, wobei ein User auch einer Metrik gegenüber durchaus mehrere Rollen annehmen kann. Hierrüber wird auch das Rechtemanagement gesteuert, was verschiedene Funktionen erlaubt oder verbietet. Dass die Metriken der Dreh- und Angelpunkt des Systems sind, vereinfacht dieses ungemein, stellt aber gleichzeitig auch einige Probleme dar. Metriken an sich werden schnell zu enormen Informationträgern, die nur noch schwer überschaubar sind. Darüber hinaus ist diese Sicht der Dinge sehr grob und lässt weitere, feinere Abhängigkeiten nicht zu. Beispielsweise sind die Verantwortungen der einzelnen Tätigkeiten rund um die Metriken unklar, was bei der rein textuellen Beschreibung im ersten Entwicklungsschritt noch nicht zu schlimm sein mag, wird aber bei der Weiterentwicklung und dem späterem Einsatz zu Unklarheit und Problemen führen. Um sich dieser Problematik anzunehmen, wurde das MeDIC Activity Management ins Leben gerufen. Die Erweiterung um das MeDIC Activity Management soll eine klarere Ablaufstruktur denieren und über das normale MeDIC hinaus ein mit der Materie verknüpftes Verwaltungssystem für messspezische Projektaktivitäten bereitstellen, welches gegebenenfalls auch mit weiteren unspezischeren Aktivitäten 8

17 2.4. Sonstige Werkzeuge zur Aktivitätsverwaltung umgehen kann. Die Realisierung eines solchen Werkzeuges ist Ziel dieser Arbeit Sonstige Werkzeuge zur Aktivitätsverwaltung Auf dem aktuellen Markt gibt es unzählige Projektmanagement Werkzeuge oder Aufgabenverwaltungssysteme, die alle ihre Stärken und Schwächen aufweisen. Nachfolgend sind nur einige davon genannt: Basecamp 1 Microsoft Project 2 Planzone 3 PHProject 4 planio 5 ProjectBubble 6 projectplace 7 Werkstatt42 8 Collabtive 9 Microsoft Outlook 10 Die Entscheidung, warum hier trotzdem ein eigener Ansatz gewählt wurde, ist gleichermaÿen simpel wie naheliegend: Durch das bestehende MeDIC, was sich aber noch in der Entwicklung bendet und daher anpassbar ist, besteht eine ideale Basis dafür ein Werkzeug zu entwickeln, das viel tiefer in die spezische Materie und seine Umgebung eingreifen kann, als es mit einem herkömmlichen Tool möglich wäre. Die Idee dabei ist, dass die beiden Systeme später einmal zusammenwachsen und sich gegenseitig zu einem einzigen ergänzen. Die Anpassbarkeit für GDIS ist darüber hinaus auch ein wesentlicher Entscheidungspunkt. So kann beliebig Funktionalität ergänzt aber auch überüssige unterdrückt oder

18 2. Grundlagen abgeschat werden. 10

19 3. Anforderungen und Ziele Ein gerader Weg führt immer nur ans Ziel. (André Gide) Inhalt 3.1. Modell Werkzeug Das zentrale Thema der Ausarbeitung ist die Entwicklung und Realisierung eines Werkzeuges zur Verwaltung von Aktivitäten in Projekten rund um Messungen und Metriken, im Kontext des bestehenden MeDICs. Nachfolgend werden dazu die Anforderungen und Ziele an das theoretische Modell und das praktische Werkzeug deniert Modell Ziel ist die Erstellung eines neuen Modells des Informationsusses rund um Metriken, um so eine möglichst getreue Abbildung der Realität zu schaen, dabei gegebenenfalls die Sichtweise des MeDIC zu überdenken, Artefakte dort aufzuarbeiten und feiner zu unterteilen, um mit dem MeDIC Activity Management letztlich eine bessere und übersichtlicher strukturierte Umgebung zu schaen. Dabei gilt es im Wesentlichen Artefakte zur Informationsspeicherung oder - repräsentation zu nden, sowie gekoppelte Aktivitäten und Akteure zu identizieren und schlieÿlich diese Zusammenhänge, zum Beispiel als Domänenmodell, visualisierend festzuhalten Werkzeug Es müssen messspezische Projektaktivitäten und eventuell damit verbundene Artefakte transparent dargestellt und verwaltet werden können. Dabei sind allerdings einige Anforderungen zu erfüllen, die von verschiedenen Interessensgruppen ausgehen. Folgende Vertreter brauchen verschiedene Übersichten: Projektleiter Fortschrittsstatus 11

20 3. Anforderungen und Ziele Aufgabenverteilung/Zuständigkeiten Messdatenlieferant Datenverwaltung Metrikkunde Gebrauch/Verarbeitung der Bestandteile Jeder Benutzer eigene involvierte Aufgaben 12

21 4. Modell der Metrikativitäten All models are wrong but some are useful. (George E. P. Box) Inhalt 4.1. Artefakte Aktivitäten Rollen Industrieller Einsatz Im Folgenden wird die neu modellierte Struktur beschrieben, auf der das Me- DIC Activity Management aufbaut. Zuerst werden die neuen Artefakte bzw. Entitäten untersucht, deren Anordnung und Verwendung einen ganz neuen Informationsuss erzeugen. Weiter stehen die damit verbundenen Aktivitäten im Fokus, und die daraus resultierenden neuen Rollen und Akteure. Letztlich wird noch auf die, für den industriellen Einsatz vorgenommenen, Anpassungen eingegangen Artefakte Bei näherer Betrachtung des aktuellen MeDIC-Systems fällt auf, dass das Werkzeug, aus Sich von Aktivitäten und Aktionen, eigentlich starr ist. Das heiÿt, es ndet kein Informationstransport oder eine Veränderung der einzelnen Artefakte statt. Die einzige sichtbare Bewegung ist beim Spezizieren von neuen Metriken zu erkennen, was das Vorschlagen, weitere Anpassen, spätere Verwenden, etc. beinhaltet, wodurch die Metrik selber erweitert bzw. verändert wird. Dabei stellt das Tool eigentlich eine ständige Weiterverarbeitung von Informationen dar. Die bisherige Struktur ist also für weiteres Vorgehen gänzlich ungeeignet und auch nicht wesentlich anpassbar, sodass es eines neuen Modells, zur Abbildung und Veränderung der Informationen, bedarf. Nach Überlegungen, welche relevanten Zwischeninformationen bei diesem Verarbeitungsprozess, bei theoretischer Betrachtungsweise, existieren, ergeben sich folgende Artefakte der Informationsdarstellung: Messdaten Die Messdaten repräsentieren eine Sammlung von gemessenen Daten, also eine Datenerhebung, zu einem Zeitpunkt oder über einen Zeitraum hinweg. 13

22 4. Modell der Metrikativitäten Metrik Die Metrik beschränkt sich im Wesentlichen auf die Vorgabe einer Funktion, für gewöhnlich eine mathematische Rechenvorschrift, nach der jegliche Eingangsdaten nach einem festgelegten Schema zu Ausgangsdaten verarbeitet werden. Dies steht ganz im Gegensatz zu dem existierenden Werkzeug, bei dem die Metriken der zentrale Angelpunkt waren. Kennzahl Eine Kennzahl ist im Prinzip das Erzeugnis einer Metrik aus gegebenen Messdaten. Hier handelt es sich um einen Zahlenwert, der zu denierten Schwellwerten (siehe auch 2.1) in Bezug gesetzt werden kann. Reportbestandteil Die visuelle Darstellung von Kennzahlen und gegebenenfalls ihrer Schwellwerte ist die Aufgabe eines Reportbestandteils. Hier soll der vorherige Informationsgehalt einfach und übersichtlich dargestellt werden; es handelt sich also eigentlich um eine Aufbereitung der vorliegenden Informationen. Cockpit Ein Cockpit beinhaltet verschiedene Reportbestandteile und ermöglicht so eine schnelle, zusammenfassende Übersicht über mehrere Metrikergebnisse. Die Intention ist, sich nur auf die Anzeige dieser Sammlung zu beschränken, sodass keinerlei Wertung der Ergebnisse gezeigt werden. Bericht Ein Bericht ist dem Cockpit sehr ähnlich. Auch hier werden diverse Reportbestandteile aufgezeigt, diese allerdings auch in einer wertenden Weise beurteilt. Man kann also sagen, dass es sich um eine Kollektion von Cockpits samt Interpretation handelt. Wie bei diesen Entitäten zu sehen ist, stellen ein oder mehrere der vorangegangenen Kategorie jeweils die Ressource eines Prozesses dar, bei dem diese Informationen zu einem weiteren Informationsprodukt verarbeitet werden. Es ergibt sich also eine Art Produktionskette der Gestalt, wie es in Abbildung 4.1 gezeigt ist. Da das Artefakt Kennzahl nicht wirklich einen Mehrwert darstellt, weil die Daten ja nach der Metrik verrechnet werden und so eine Kennzahl jederzeit reproduzierbar ist, wird aus Gründen der Komplexitätsminderung darauf verzichtet, diese im Modell darzustellen. Jene Rolle nimmt dann aber repräsentativ die Entität Metrik an, wobei diese dann im Grunde genommen das Ergebnis der Rechenvorschrift darstellt. Mit ihr sind viele Informationen verknüpft, sodass eine alternative Lösung, bei der die Metrik beispielsweise aus der Kette entfernt wird, nicht in Frage kommt. Das nun daraus resultierende Modell zeigt Abbildung

23 4.2. Aktivitäten Abbildung 4.1.: Produktionskette aus Artefakten bzw. Informationsentitäten [Legende 4.1] 4.2. Aktivitäten Die Aktivitäten, die mit den Artefakten zusammenhängen, gehen direkt aus dem Entitätenmodell hervor. Eine jede Aktivität ist hier der Verarbeitungsoder Produktionsvorgang zwischen zwei aufeinander folgenden Artefakten. Dabei fungiert eine Informationsentität quasi als Rohsto für einen Herstellungsprozess (der Aktivität), welcher als Produkt eine Informationsentität der nächsten Stufe hervor bringt. Abbildung 4.3 stellt alle gefundenen Aktivitäten in der Produktionskette dar. Hier ergeben sich also die folgenden Aktivitäten: Datensammeln ( Messdaten) Dies umfasst alles, was zu einer Datenerhebung gehört. Daten müssen gemessen und aufgezeichnet werden, worauf hin diese, in der Regel, noch aufbereitet werden müssen. Dazu gehört auch, die Daten auf Korrektheit zu prüfen und dementsprechend anzupassen. Ziel ist es, diese nal so bereit zu stellen, dass sie weiter verarbeitet werden können. Berechnen (Messdaten Metrik) Messdaten, entsprechend der in einer Metrik denierten Vorschrift, zu verrechnen ist Fokus der Berechnung. Auf welche Weise dies geschieht, kann stark variieren. Ziel wird aber in der Regel ein automatisierter und nicht ein manueller Ablauf sein. 15

24 4. Modell der Metrikativitäten Abbildung 4.2.: Produktionskette ohne Kennzahlen [Legende 4.1] Visualisieren (Metriken Reportbestandteil) Hierbei geht es um die visuelle Aufbereitung, meist in Diagrammen, der zuvor berechneten Werte und, bei Bedarf, auch die Darstellung zusammen mit den Schwellwerten, sodass diese intuitiv in Bezug gesetzt werden können und leicht weitere Erkenntnisse ableitbar sind. Interpretieren (Reportbestandteile Cockpit) Bei der Interpretation muss eine Wertung gemäÿ der Visualisierung, welche eigentlich nur die errechneten Zahlen vereinfacht darstellt, erstellt werden. Diese sollte leicht verständlich sein, und kann auch auf visuelle Mittel zurück greifen. Zusammenstellen (Cockpits Bericht) Die Zusammenstellung bündelt zuvor gewonnene Interpretationsergebnisse und kombiniert diese in übersichtlicher Form, um diese der entsprechenden Audienz vermitteln zu können. Ausliefern (Bericht ) Die Auslieferung beschränkt sich lediglich darauf, einen Bericht der angedachten Zielperson oder -gruppe zukommen zu lassen, und erzeugt somit kein weiteres Produkt (analog dem Datensammeln, dem keine materielle 16

25 4.2. Aktivitäten Symbol Bedeutung Informationsartefakt Komposition Aktivität Benutzung/Erzeugung Akteur Ausführung Begriiche Zusammenfassung Tabelle 4.1.: Legende zu Abbildung 4.1, 4.2, 4.3, und 4.4. Resource in dem Sinne voraus geht). Spezizieren Das Spezizieren ist ein übergeordneter Aktion. Wie wir das Spezizieren der Metriken von MeDIC kennen, bedarf es nun einer Spezikation jeder einzelnen Entität. Der Detailgrad dieser ist exibel, kann aber ähnlich der in 2.3 genannten Folge passieren. Zum Spezizieren der neuen Entitäten ist darüber hinaus ein spezischeres Fachwissen von Nöten, als es für den allgemeinen Sammelbegri Metrik der Fall war. An dieser Stelle kann ein Fehler groÿe Konsequenzen nach sich ziehen und sogar das ganze Verfahren unbrauchbar machen. Zwar gibt es jetzt eine Informationsstruktur und auch Aktivitäten, die Artefakte ineinander überführen, allerdings bedarf es auch einer Anleitung, wie eine gewisse Entität zu erstellen ist, quasi eine Produktionsanleitung. Dies ist in den Artefakten selber realisiert. So kann gewährleistet werden, dass auch ohne Aktionen eine Vorstellung des Produktionsprozesses existiert. Ein Reportbestandteil enthält beispielsweise Informationen darüber, wie oder wohingehend verschiedene Metriken zu visualisieren sind, welches Diagramm oder welcher Graph benutzt 17

26 4. Modell der Metrikativitäten Abbildung 4.3.: Produktionskette mit Aktivitäten [Legende 4.1] wird, und wie im Detail diese erzeugt werden sollen. Zur weiteren Einsicht, siehe auch ein anfänglich erstelltes Glossar zu Aktivitäten und Rollen A Rollen Da das Modell nun Informationsartefakte und Aktivitäten - die diese erzeugen bzw. benutzen - beinhaltet, ergbibt sich die Frage nach den Akteuren. Die Akteure, oder Rollen, denn ein Akteuer kann der Struktur in mehreren Rollen gegenübertreten, ergeben sich direkt aus den Aktivitäten. Zu jedem dieser Prozesse gibt es eine passende Rolle, die diesen durchführt oder dafür verantwortlich ist. Es sind also folgende Akteure zu identizieren: Datenlieferant Der Datenlieferant ist für das Messen und Sammeln der Daten verantwort- 18

27 4.4. Industrieller Einsatz lich, sowie die Überprüfung dieser auf Korrektheit und die Aufbereitung zum weiteren Gebrauch. Somit erzeugt er die Messdaten. Berechner Der Berechner errechnet die Metrik aus den benutzen Messdaten oder ist dafür verantwortlich. Letzteres ist besonders wichtig, da dieser Prozess oft maschinell ausgeführt wird. Trotzdem muss jemand für den korrekten Ablauf sorgen, worin die Aufgabe dieser Rolle liegt. Visualisierer Der Visualisirer veranschaulicht die Metrik in einer Visualisierung, dem Reportbestandteil. Oft wird hier bei der Erstellung auf Plotter o.ä. zurückgegrien. Interpretierer Der Interpretierer braucht, zusätzlich zu der im Cockpit beschriebenen Vorgehensweise, ein gewisses Fachwissen und Erfahrung, um die Reportbestandteile bestmöglich interpretieren zu können. Zusammensteller Verschiedene Cockpits geeignet zusammenzustellen, die stituationsbedingt beste Auswahl zu treen und diese so aufzubereiten, dass sie leicht verständlich sind, gehören zu den Schwierigkeiten, die der Zusammensteller bewältigen muss. Auslieferer Die Aufgabe des Auslieferers besteht einzig und allein darin, den Bericht der zugedachten Person oder Auswahl an Personen zukommen zu lassen. Spezizierer Der Spezizierer ist eine generalisierte Rolle, die eigentlich auf alle Artefakte aufgeteilt werden kann. So gibt es Messdatenspezizierer, Metrikspezizierer, Reportbestandteil-, Cockpit- und Berichtspezizierer. Diese sind eine Randerscheinung und bleiben hier im Wesentlichen unbehandelt. Die Zusammenhänge werden noch mal in Abbildung 4.4 verdeutlicht Industrieller Einsatz Wie schon in Abschnitt 4.1 gezeigt, wurde die Entität Kennzahl nicht berücksichtigt, sodass sich insgesammt das Modell nach Abbildung 4.4 ergibt. Um einen weiteren praxisnahen Einblick in diese Struktur zu geben, ist nachfolgend beispielhaft ein mögliches Domänenmodell (Abbildung 4.5) zu sehen. Hier sieht man verschiedene Klassen, hauptsächlich die Informationsentitäten, deren Beziehung untereinander sowie ihren Zusammenhang mit Aktivitäten. Wie zu erkennen ist, setzen sich die Informationsentitäten aus anderen In- 19

28 4. Modell der Metrikativitäten Abbildung 4.4.: Produktionskette mit Akteuren [Legende 4.1] formationsentitäten niedrigerer Stufe zusammen bzw. beinhalten diese. Jene Erzeugnis-Resource-Beziehung wird durch die Kompositionen deutlich. Neben einigen Standardattributen wie Id, Name und Beschreibung, besitzen all diese Artefakte jeweils Hilfen: Messdaten haben Messhilfen, Metriken haben Berechnungshilfen, usw. Diese repräsentieren die in 4.3 beschriebenen Produktionsanleitung, wie also für die konkrete Erstellung vom Akteur vorgegangen werden muss. Da das MeDIC Activity Management unabhängig ergänzbar sein soll, drücken die Anleitungen an der Stelle nur aus, wie die Artefakte aussehen sollen bzw. zusammengesetzt sind, nicht wie sie wirklich erstellt werden. Denn Akteure zwischen den Entitären existieren hier in diesem Sinne noch nicht. Weiter kann jede Entität einem konkreten Projekt zugeordnet werden. So viel zu der strukturellen Änderung des MeDIC und weiter mit der Aktivitätsverwaltung. Jeder der Informationsentitäten können Aktivitäten zugeordnet werden. Eine solche setzt sich, neben trivialen Attributen wie Id, Name, Beschreibung, aus folgenden Teilen zusammen: Kategorie, dazu später mehr; verantwortlicheprojektrollen, eine Liste der für die Ausführung der Aktivität zuständigen Personen bzw. deren Projektrollen, über welche die Benutzer dann ermittelt werden; Intervall, eine Angabe, in welchen regelmäÿigen, zeitlichen Abständen die Aktion zu wiederholen ist; Speicherort, da die erzeugten Daten ja irgendwo abgelegt werden müssen; inprojekt, eine Referenz zu einem Projekt, in dessen Rahmen die Aktivität stattndet, welche aber auch leer sein kann, sofern es sich um eine allgemeine, nicht zuzuordnende oder projektübergreifende 20

29 4.4. Industrieller Einsatz Abbildung 4.5.: Domänenmodell (UML Klassendiagramm) Aktion handelt. Bei den Überlegungen zu der Struktur von Artefakten, Aktivitäten und Rollen ergab sich eine weitere Fragestellung. Im nativen MeDIC-System gibt es, zum Weiterentwickeln und Festhalten von Veränderungen, die Versionierung von Metriken. Dieses Prinzip könnte auch für Aktivitäten übernommen werden. Da aber zu erwarten ist, dass Änderungen in Aktivitäten nur selten, dann aber dauerhaft sind, und der Informationsgehalt von Aktivitäten an sich, verglichen mit dem ursprünglichen Metriken in MeDIC, relativ gering ist, wurde diese Idee wieder verworfen. Wie Aktivitäten aber in die Versionierung der anderen Infor- 21

30 4. Modell der Metrikativitäten Abbildung 4.6.: Aktivitäten in Entitätsversionen (UML Klassendiagramm) mationsentitäten (wie Messdaten, Metrik, etc) integriert werden können, zeigt ein Domänenmodell in Abbildung 4.6. Hier ist dies beispielhaft für einen Reportbestandteil (ReportItem) geschehen. Dieser enthält eine Liste mit verschiedenen Versionen, in denen die eigentlichen Informationen abgespeichert sind. Um das MeDIC weiterhin völlig unabhängig von dem Activity Management benutzen zu können, leitet letzteres die Version als Activity Report Item Version (ActRIVersion) ab, um dort eine Liste von Aktivitäten zu ergänzen. Darunter wäre dann beispielsweise die damit verbundene Aktivität Visualisieren, die eine Spezialisierung darstellt. Versuche, das Activity Management als eigenständige Erweiterung zu konstruieren, wurden mit dem Programm Maven 1 unternommen. Dabei sollte Maven die Aufgabe übernehmen, die zwei Projekte des eigentlichen MeDIC und des Activity Managements zu verbinden. Leider ergaben sich hier erhebliche Probleme, deren Lösung den zeitlichen Rahmen dieser Arbeit überschreitet, sodass aus Zeitgründen wieder davon abgesehen werden musste. Da das MeDIC, wie bereits erwähnt, für die Generali Deutschland Informatik Services GmbH (GDIS) entwickelt wird, ist es auch auf die speziellen Bedürfnisse ausgelegt und angepasst. Mit der Idee, das MeDIC Activity Management als eigenständige Erweiterung im selben Kontext zu realisieren, geht auch einher, die neuen Strukturen auf GDIS zuzuschneiden. Das Entfernen der Kennzahl war bereits in diesem Sinne. Das wurde auch durch ein Treen mit GDIS bestätigt. Dieses ergab, dass das Modell für die praktische Anwendung viel zu detailliert ist. Eine so feingranulare Struktur würde unverhältnismäÿig viel neuen Verwaltungsaufwand bedeuten. Auÿerdem würde das System für einen ersten Gebrauch

31 4.4. Industrieller Einsatz Abbildung 4.7.: Produktionskette für GDIS zu komplex, sodass die Befürchtung besteht, dass es wegen des ungewöhnlichen Mehraufwandes nicht wie gedacht angenommen würde. Um dem entgegen zu wirken, wurde das Modell komplett überarbeitet. Die bisher entwickelte Theorie wurde nicht als falsch angesehen, sondern existiert auch neben dem neuen Modell, ist aber so nicht realistisch umsetzbar. Ziel war hier eindeutig die Reduzierung von Aktivitäten. Zunächst wurden dazu einige Aktionen zusammen gelegt, die ohnehin in dem Unternehmen nicht wirklich trennbar sind bzw. vom Ablauf her nicht getrennt werden. Dazu kommt die Tatsache, dass diese Aktionen normalerweise auch von ein und der selben Person ausgeführt werden. Abbildung 4.7 lässt einige Änderungen erkennen. Die Aktivitäten Datenliefern, Berechnen und Visualisieren wurden unter einer neuen übergeordneten Aktivität Datenverwalten zusammengefasst. Dies fasst gleichermaÿen die damit verbundenen Rollen des Datenlieferanten, Berechners und Visualisierers in der Rolle des Datenverwalters zusammen. Dies fällt in den Tätigkeitsbereich des Messdatenlieferanten, wie er in der AGSM 2 [3] der GDIS speziziert wurde, also der entsprechenden GDIS-Rolle. Neben den Aktivitäten mussten auch die sonstigen Abhängigkeiten korrigiert werden. Man einigte sich darauf, dass sowohl Cockpits als auch Berichte nebeneinander existieren und Zusammenstellungen 2 AGSM - Advanced Generali Systems Engineering Method - ist eine Methode zur Steigerung der Qualität und Produktivität von Entwicklungsprozessen bei der GDIS. Es handelt sich um eine Instanziierung des Rational Unied Process 23

32 4. Modell der Metrikativitäten aus Reportbestandteilen darstellen, wobei ein Bericht darüberhinaus eine Interpretation enthält, diese aber für das Cockpit optional und ehrer unüblich ist. Neben dem neu integrierten Zusammenstellen und Interpretieren fällt noch die Aktivität Ausliefern in die Zuständigkeit des so genannten Metrikkunden, was wieder eine GDIS-Rolle nach AGSM [3] darstellt, wobei letztere Aktivität weniger von Bedeutung ist. Zwar wären so die Herausforderungen erfüllt, auch diese Tätigkeiten unter einem neuen Begri zu vereinen, doch wurde dies vorerst nicht vereinbart. Der am Rande stehende Spezizierer konnte weiter als Metrikkoordinator (nach AGSM [3]) identiziert werden. Bis dato zielte die Vorstellung eines Domänenmodells immer darauf, die genannten Aktivitäten Datenliefern, Berechnen, Visualisieren, Interpretieren, Zusammenstellen, Ausliefern als Unterklasse von einer allgemeinen Aktivitäten- Klasse abzuleiten, welche die eigentlichen, gemeinsamen Informationen enthält. Im Sinne der Flexibilität für den Einsatz bei GDIS, wurde dies aber überdacht und abgeändert. Anstatt einzelne Sub-Klassen zu unterscheiden, bekam die Aktivitäten-Klasse ein weiteres Attribut Kategorie, die hier bereits kurz erwähnt wurde. Diese unterscheidet die Aktivitäten zwischen den genannten Arten und lässt Spielraum für weitere abstraktere Aktivitäten oder solche, die nicht strikt dem Kontext der Produktionskette folgen. So gibt es eine universelle Aktivität, die auf viele Bedürfnisse angepasst werden kann. Ein weiterer Gesichtspunkt bei der Planung war die Trennung von projektspezischen und projektunabhängigen Entitäten als auch Aktivitäten. Überlegungen ergaben allerdings, dass Entitäten nur projektspezisch sein sollten, darüber hinaus aber die Möglichkeit gegeben sein sollte, auf Standardartefakte zurückzugreifen, und diese für ein Projekt zu übernehmen, und damit wieder projektspezisch zu instanziieren. Bei Aktivitäten hingegen machen projektunabhängige Aktionen im Rahmen der Produktionskette keinen Sinn, da sie dann immer an projektspezische Informationsentitäten gebunden sind. Ferner sollten sie aber universell und projektübergreifend denierbar sein, was Zugri auf bewährte oder oft gebrauchte Standardaktivitäten nicht ausschlieÿt. Dies ist aber im Wesentlichen durch die Einführung der Kategorie in den Aktivitäten schon ermöglicht. 24

33 5. Werkzeugunterstützung Jedes Werkzeug erhält nämlich dadurch seine Vollendung, dass es nicht mehreren, sondern nur einem Zwecke dient. (Aristoteles) Inhalt 5.1. Papierprototyp Klickdummy Evolution Im folgenden Kapitel wird die Entwicklung und Evolution eines industrienahen Prototypen gezeigt, der auf den Erkenntnissen des theoretischen Modells aus Kapitel 4 aufbaut, und auf eine spätere Implementierung als Webanwendung, wie das MeDIC selber auch, zielt. Dies beinhaltet die anfängliche Gestaltung eines Papierprototypen sowie die spätere Entwicklung eines Klickdummys. Die vorgestellten Entwürfe sind an die nachfolgenden, identizierten Anwendungsfälle (Use Cases) angelehnt. Eine Umsetzung zeigt Abbildung 5.1, mit den wichtigen Anwendungsfällen. Diese sind im Wesentlichen folgende: Projektübersicht anzeigen Die Projektübersicht zeigt Informationen zu verwendeten Entitäten bzw. Aktivitäten eines Projekts an. Dabei gibt es mehrere Sichten auf das Projekt, hier Fokus genannt. Im Fokus können sein: Daten Die Übersicht zeigt die verwendeten Messdaten, aus Sicht der Daten. Das heiÿt, es ist ersichtlich, wie die Messdaten in diesem Projekt weiter verwendet werden, in welchen Metriken sie benutzt werden, in welchen Reportbestandteilen weiter diese Metriken verwendet werden, usw. So ist letztlich der Informationsuss von den anfänglichen Daten bis hin zum nalen Bericht erkennbar. Metriken Diese Ansicht entspricht im Prinzip der Datenansicht, sie beginnt aber erst bei den Metriken, und zeigt von dort weiter den Verlauf bis zu den Berichten. 25

34 5. Werkzeugunterstützung Abbildung 5.1.: Anwendungsfälle in UML Reportbestandteile Die Übersicht der Reportbestandteile unterscheidet sich von den bisherigen. Da sich diese quasi in der Mitte der Prozesskette benden, ergibt eine lineare Einordnung wie bei den übrigen vier Fokussen keinen Sinn. Die Verwendung ist in der Tat auch schon durch diese sichtbar. Da im MeDIC die Informationsbedürfnisse einen wichtigen Aspekt der Metriken darstellen, beschränkt man sich in dieser Ansicht darauf zu zeigen, welche Informationsbedürfnisse durch einen Reportbestandteil abgedeckt sind oder gegebenenfalls noch ergänzt werden müssen. Cockpits Da die Cockpits nahe dem Ende der Prozesskette eingeordnet sind, wird hier das vorherige Prinzip der Sicht von Messdaten und Metriken aufgegrien. Die Sicht ist aber umgekehrt. Sie zeigt also nicht, worin ein Cockpit verwendet wird, sondern welche Artefakte in einem jeden Cockpit benutzt werden. Dies setzt sich bis zu den Messdaten fort. Berichte Die Übersicht der Berichte erweitert die der Cockpits, und lässt die Prozesskette aus Sicht der Berichte erkennen. Entitätsverwaltung 26

35 5.1. Papierprototyp Unabhängig voneinander, können einzelne, neue Informationsentitäten erstellt und bearbeitet werden. Diese können zuerst noch ungebunden sein, aber auch direkt mit Informationsartefakten der niedrigeren Stufe assoziiert werden. Das bedeutet, dass beispielsweise bei der Erstellung einer Metrik dirket angeben wird, welche Messdaten dafür verwendet werden - sofern diese schon existieren -, was aber auch nachträglich noch gemacht werden kann. In diesem ersten Ansatz ist es so, dass zu einer Informationsentiät gehörende Aktivitäten direkt mit erstellt und speziziert werden. Das sind solche, die zur Erstellung des Artefakts unbedingt ausgeführt werden müssen. Um, zum Beispiel, einen neue Bericht erstellen zu können, muss vorher zwingend die Aktivität Zusammenstellen ausgeführt werden. eigene Aktivitäten anzeigen Hier bekommt der entsprechende Benutzer eine Übersicht über alle Aktivitäten, in die er selber involviert ist. Dies kann als eine Art Aufgabenliste verstanden werden. Dabei werden natürlich die Aufgaben von allen Projekten beachtet und nach den verschiedenen Aktivitätsbereichen Visualisieren, Interpretieren, usw. geordnet. Beispielhaft sei hier auch noch eine Entitätsverwaltung im Detail erklärt. Wie Abbildung 5.2 erkennen lässt, beinhaltet die Metrikverwaltung weitere, feingranulare Fälle. Zunächst kann ein Benutzer eine neue Metrik erstellen, was die Generierung einer Berechnen-Aktivität beinhaltet. Dabei kann sowohl die Metrik als auch die Aktivität direkt bearbeitet werden. Neben dem Benutzer gibt es noch einen weiteren Akteuer, der durch die Art der Aktivität bestimmt wird. Bei Metriken ist die verbundene Aktivität Berechnen, als Konsequenz muss unter anderem die Rolle des Berechners vergeben werden. Das Prinzip ist bei allen Informationsartefakten gleich, die Anzahl der Aktivitäten und somit Verantwortlichen kann aber variieren. Beim Erstellen sollte die Aktivität zu einem projektspezischen Artefakt natürlich an das selbe Projekt gebunden werden, was aber beim Editieren des Artefaktes nachträglich geändert werden kann. Hier müssen natürlich auch noch die verwendeten Artefakte der niedrigeren Ebene verknüpft werden Papierprototyp Da sich systemnahe Präsentationen im bisherigen Umgang mit GDIS bewährt haben, lag die Entscheidung nahe, erste Entwürfe des Werkzeuges in Form von Papierprototypen zu machen. Anfängliche Versuche mit Bleistift und Papier bleiben hier unerwähnt. Stattdessen wird vermehrt auf die Software-Prototypen eingegangen. Diese wurden mit einem gängigen Bildbearbeitungsprogramm gebaut. Gründe, sich dafür zu entscheiden, waren unter anderem die Möglichkeit einen an dem späteren Produkt sehr stark angelehnten Entwurf zu erstellen, und dabei aber schlichtweg alle gestalterischen Möglichkeiten und Freiheiten zu 27

36 5. Werkzeugunterstützung Abbildung 5.2.: Anwendungsfall Metrikverwaltung in UML Abbildung 5.3.: Erster Paperprototyp: Projektübersicht mit Daten-Fokus haben, die sonst schwer umsetzbar wären. Zwar mussten zuerst die gängigen Elemente, wie Textfelder, Buttons, etc., eines Webinterfaces zusammengebaut werden, doch standen sie danach unbegrenzt zur Auswahl. Das bedeutete anfänglich einen enormen Aufwand, der nachträglich aber durch die hohe Wiederverwendbarkeit kompensiert wurde. Auch die frühere Erfahrung im Umgang mit dem Programm kam hier zu Gute. 28

37 5.1. Papierprototyp Abbildung 5.4.: Paperprototyp: Projektübersicht mit Berichte-Fokus Einen ersten Prototypen zeigt Abbildung 5.3. Hier ist eine Projektübersicht mit Fokus auf den Daten zu sehen. Gut erkennbar ist bereits die Verschachtelung der verschiedenen Artefakte in Form eines Baumes bzw. mehreren Ebenen von Listen. Die Kopfelemente, wie wichtige Links, wurden einfach vom existierenden MeDIC übernommen. Das Design ist auch möglichst nahe am vorhandenen System angelehnt. Konkret ist hier eine Datenmessung WTF-Messung 1 zu sehen, die in der Metrik WTF pro Tag verwendet wird. Daraus ergibt sich die Kennzahl WTF-Kennzahl, von der weiter im Reportbestandteil WTF Grak Gebrauch gemacht wird. Dieser wird im Cockpit SuperWTF-Ampel benutzt, welches schlieÿlich in dem Bericht wöchentlicher WTF-Bericht auftaucht. Das Beispiel ist sehr einfach gehalten, weil hier einzelne Artefakte nicht mehrfach benutzt werden. Abbildung 5.4 zeigt, leicht abgeändert, die gleiche Übersicht mit Bericht-Fokus. Erwähnenswert ist hier auf jeden Fall der unten aufgelistete [leere] Bericht. Dieser ist bereits im Projekt erstellt worden, macht aber noch nicht von weiteren Entitäten Gebrauch. Trotzdem bzw. gerade deswegen ist es wichtig, dass derartige Entitäten auch in der Übersicht auftauchen, damit sie weiter speziziert oder verwendet werden. Betrachten wir weiter die Übersicht der Projektaktivitäten nach Abbildung 5.5. Hier werden alle Aktivitären des aktuellen Projektes, nach Kategorie geordnet, aufgeführt. Dazu gehört jeweils der Verantwortliche, ein zeitliches Ausführungsintervall, sowie der Name oder ein kurzer Infotext, der hier die involvierten Entitäten aufzeigt. Informationen wie Speicherort wurden hier absichtlich, der Übersichtlichkeit wegen, weggelassen. Zu sehen ist an diesem Beispiel auch, dass eine Person durchaus in mehreren verschiedenen Rollen involviert sein kann. In diesem Beispiel der Fachmann, der sowohl als Visualisierer als auch Inter- 29

38 5. Werkzeugunterstützung Abbildung 5.5.: Paperprototyp: Projektübersicht mit Aktivitäten-Fokus pretierer auftritt. Bereits an dieser Stelle ist unten eine Kategorie Sonstiges eingearbeitet, die weitere Aktivitäten katalogisiert, welche nicht zur Produktionsstruktur der Informationsartefakte passen. Die Anzeige der Entitäten ist klar, aber bislang wurde nicht auf den dazwischen liegenden Erzeugungsprozess eingegangen. Abbildung 5.6 zeigt dies beispielhaft an der Erstellung eines neuen Berichtes. Im oberen Teil wird der Bericht selber durch einige Textfelder näher speziziert. Hier können aus einer Auswahlliste per Mehrfachauswahl auch Cockpits selektiert werden, die in dem Bericht verwendet werden sollen. Weiter unten können direkt die neuen Aktivitäten speziziert werden, die mit dem neuen Artefakt zusammenhängen und so automatisch mit erzeugt werden sollen. Bei einem Bericht wären das Berichten und Ausliefern. Alle nötigen Informationen dazu können angegeben werden. Im Gegensatz zu der separaten Erzeugung einer Aktivität kann hier nicht das Projekt frei gewählt werden, es wird stattdessen das aktuelle verwendet, in dem sich der Benutzer gerade bendet Klickdummy Die Papierprototypen via Graksoftwareprogramm erfüllten zwar anfänglich ihren Zweck, doch waren Änderungen sehr aufwändig, besonders beim Austau- 30