Auf Basis der bisherigen Ausarbeitungen sowie der Feinspezifikation wird in diesem Kapi-tel das zukünftige Projektportal inhaltlich, wie auch designbezogen, konzeptioniert. Das im Folgenden beschriebene Lösungskonzept dient zur vereinfachten Betrachtung der Spezifi-kation. Das zu konzeptionierende SP2010 basierte Projektportal soll strukturell auf das fünf Phasen umfassende IT-PM angepasst werden, wobei die Informationen und Funktio-nalitäten des Projektportals den Phasen entsprechend eingeordnet werden können. Im Fol-genden werden schrittweise die Ergebnisse und Anforderungen der Feinspezifikation ab-gearbeitet. Mit den phasenübergreifenden Anforderungen, d.h. der Verwaltung der Naviga-tion sowie der Benutzerverwaltung wird begonnen. Auf Grundlage der vorgestellten Web-seitengrundstruktur und dem typischen Nutzerverhalten auf Webseiten soll im Folgenden ein Designschema einschließlich der Navigation für das Projektportal abgeleitet werden.
Zu erwähnen sei an dieser Stelle, dass sich die grundsätzliche Gestaltung, bezogen auf bei-spielsweise Farben oder Schriftarten, an den Corporate Identity Vorgaben des
305 Vgl. Bates/Smith, 2010, S.2.
306 Vgl. Williams, 2010, S. 22.
307 Vgl. Bates/Smith, 2010, S.2.
104 renden Unternehmens ausrichtet. Das entwickelte Konzept zur Umsetzung soll in der nächsten Abbildung durch eine vereinfachte Darstellung verdeutlicht werden.
Abbildung 30: Metamodell des Grundaufbaus des Portals
Quelle: Eigene Darstellung.
Bezogen auf das typische Nutzerverhalten treten bei der Gestaltung der Portalstruktur die drei Bereiche der primären und sekundären Navigation wie auch des eigentlichen Inhalts-bereiches in den Vordergrund. Die fünf Phasen des IT-PMs werden die oberste Ebene der Navigationshierarchie bilden. Die sekundäre Navigation wird entsprechend der aktuellen Hauptkategorie, welche aus der primären Navigation hervorgeht, verfügbar sein. Die je-weiligen Inhaltsbereiche wiederum werden durch die entsprechende sekundäre Navigation erzeugt. Die sekundäre Navigation kann beispielsweise Verknüpfungen zu bestimmten Listen beinhalten, wobei der Inhaltsbereich in diesem Fall die eigentliche Liste darstellen würde. Das Ziel der Benutzerverwaltung ist die Schaffung einer Umgebung zur Anlage und Änderung von Portalbenutzern. In der Benutzerverwaltung können Personen mit ad-ministrativen Berechtigungen neue Benutzer anlegen und bestehende Benutzer ändern. Die Benutzerverwaltung erfolgt immer im Kontext eines Projektportals. Es wird zum einen die Möglichkeit gegeben, Benutzer für das Projektportal anzulegen und zu bearbeiten. Der Freigabestatus gilt für die SharePoint Bibliothek der internen Anforderungsliste. Zum an-deren werden über Funktionalität die Benutzer den vier unten angegebenen Benutzergrup-pen zugeordnet. Diese BenutzergrupBenutzergrup-pen und die zugehörigen Rollen bilden die Rech-testruktur auf den Portalseiten ab. Die Benutzer werden in vier Gruppen eingeteilt: interne Projektleitung, interner Projektmitarbeiter, Projektleitung Kunde und Projektmitarbeiter Kunde. Diesen Gruppen werden auf unterschiedlichen Listen und Bibliotheken unter-schiedliche Rechte eingeräumt. Diese Rechte reichen von der Möglichkeit der Bearbeitung und Anlage, über das reine Lesen bis zu einer kompletten Sperrung für einzelne Listen.
105 Die nächste zu entwickelnde Anforderung umfasst das Verwalten von Anforderungen, Kontextinformationen und Kategorien/Unterkategorien. Der Aufbau und der Funktionsum-fang der ersten Phase des neuen Projektportals umfassen die Anforderungserfassung, wie die nächste Abbildung zeigt.
Abbildung 31: Portalkonzept Navigation der Referenzanalyse
Quelle: Eigene Darstellung.
Anforderungen werden über die Anforderungsliste erfasst. Consultants legen eine Anforde-rung an. Informationen werden gefüllt, so dass die AnfordeAnforde-rung in der Liste zu sehen ist.
Nach der internen Freigabe wird die Anforderung von der Anforderungsliste (intern) in die Anforderungsliste des Kunden übertragen. Diese Menüpunkte werden auf der Sekundär Navigation platziert. Anforderungen müssen über ein Eingabeformular erfassbar sein und können in einer extra Ansicht angewendet werden, wie die nächste Abbildung zeigt.
Abbildung 32: Portalkonzept Referenzanalyse
Quelle: Eigene Darstellung.
Eine Anforderung hat zwei Arten von Status: Freigabe- und Umsetzungsstatus. Die Arten von Status ziehen sich durch alle Phasen des IT-PM. Der Freigabestatus ist intern und dient
106 zur Kommunikation zwischen Consultant und internem Projektleiter. Der Umsetzungssta-tus ermöglicht es dem Kunden zu sehen, wie der BearbeitungsstaUmsetzungssta-tus der Anforderung ist.
Hiermit wird die Kommunikation innerhalb des Unternehmens über das Webportal umge-setzt. Der Status ist leer, wenn die Anforderung erfasst wird. Insofern der Consultant die Freigabe der Anforderung durch den Projektleiter (intern) anfordert, ist der Status auf „in Bearbeitung“. Der Status wechselt auf „freigegeben“, wenn der Projektleiter (intern) die Anforderung zur Übernahme in die Anforderungsliste des Kunden freigegeben hat. Wenn der interne Projektleiter die Freigabe dieser Anforderung zur Übernahme in die Anforde-rungsliste des Kunden ablehnt, wird der Status auf „abgelehnt“ gesetzt. Der Consultant muss die Anforderung überarbeiten und erneut die Freigabe beantragen. Der Umsetzungs-status ist der Status, der zur Kommunikation zwischen dem IT-Dienstleister und dessen Kunden operiert. Dieser wird bei Bestätigungen entsprechend automatisch vom SP 2010 gesetzt. Bei der Anlage der Anforderung durch den Consultant hat die Anforderung den Status „Anforderung intern“. Dieser Status wird auf „Anforderung“ umgesetzt, wenn die Anforderung in die Kundenbibliothek (Anforderungsliste Kunde) übernommen wurde. Hat der Kunden die Anforderung zur Spezifikation freigegeben, ist der Status „In Spezifikation übernehmen“ automatisch durch eine Funktion gesetzt worden. Eine Spezifikation wird durchgeführt. Das Spezifikationsdokument hat den Status „Spezifikation intern“. Nach interner Freigabe über die gleichen Freigabestatus wird die Spezifikation in die Kunden-bibliothek mit dem Status „Spezifikation“ übernommen. Nach Genehmigung durch den Kunden ist der Status „In Entwicklung“. Die Spezifikation zu dieser Anforderung wurde freigegeben. Außerdem existieren Entwicklungsaufgaben zu dieser Anforderung. Wenn alle zu dieser Anforderung gehörigen Entwicklungsaufgaben abgeschlossen wurden, wird die Spezifikation wurde „zum Test freigegeben“ (Status). Insofern die Anforderung vom Kunden getestet und für umgesetzt erklärt wurde, ist der Status „abgeschlossen“.
Auch die anforderungsspezifischen Kontext- und Kategorieninformationen müssen verwal-tet und gepflegt werden können. Die Kontexte dienen nur der Unterstützung der Anforde-rungserfassung. Sie werden während des Projektes vom Projektleiter (intern) gepflegt. Ka-tegorien und UnterkaKa-tegorien dienen nur der Strukturierung von Anforderungen innerhalb einer SharePoint-Ansicht. Da SharePoint nur zwei Ebenen von Gruppierungen in einer Ansicht unterstützt, beschränkt sich die Umsetzung der Kategorien auf zwei Ebenen. Dazu werden zwei Listen angelegt, auf deren Inhalte in der Anforderungsbibliothek über Dropdown-Felder zugegriffen wird. Die Feinspezifikation läuft analog zur Referenzanaly-se ab, wie die nächste Abbildung zeigt.
107 Abbildung 33: Portalkonzept Navigation der Feinspezifikation
Quelle: Eigene Darstellung.
Spezifikationen enthalten zusätzliche Informationen, so wird die detaillierte Umsetzung auf technischer Ebene erfasst. Aus einer Anforderung kann nur eine Spezifikation werden, d.h. es besteht ein 1:1 Verhältnis. Wenn ein Projektteilnehmer später in das Projekt ein-steigt, kann er bspw. sehen, aus welcher Anforderung welche Spezifikation wurde. Die Umsetzung erfolgt über eine Verlinkung der beiden Dokumente. Das hat den weiteren Nutzen der Orientierung. Insofern ein Projektteilnehmer auf der Feinspezifikationsliste ist und eine Spezifikation öffnet, kann er durch den Hyperlink automatisch zur dazugehörigen Anforderung gelangen. Die nächste Abbildung zeigt das Konzept der Spezifikationslisten.
Abbildung 34: Portalkonzept der Feinspezifikation
Quelle: Eigene Darstellung.
Auch nimmt das E-Portfolio als inhaltliches Anforderungsdokument Gestalt an. Die Inhal-te werden in die Spezifikation übergeben und erweiInhal-tert. Der Ursprung und Inhalt bleibt der gleiche, nur der Name ändert sich. Über die Verlinkung wird aber sichergestellt, dass die Inhalte dauerhaft zu einer betriebswirtschaftlichen Anforderung (E-Portfolio) gehören. Die sekundäre Navigation der dritten Phase umfasst die Verwaltung von
Entwicklungsaufga-108 ben, die auf Grundlage der vorherigen Phase erzeugt wurden. Die Verwaltung umfasst ne-ben der Bearbeitung von spezifizierten Aufgane-ben auch dessen Zuordnung zu Projektbetei-ligten. Diese Zuordnung kann beispielsweise zwischen Testaufgaben und den auf Kunden-seite verantwortlichen Rollen erforderlich sein.
Abbildung 35: Portalkonzept der Entwicklungsaufgaben
Quelle: Eigene Darstellung.
Eine Entwicklungsaufgabe kann aus einer Spezifikation, einer erzeugten Testanweisung oder einem zu behebenden Softwarefehler entstehen. Die nächste Abbildung verdeutlicht die modellhafte Umsetzung der Menüleiste der Phase Softwareentwicklung.
Abbildung 36: Portalkonzept der Menüleiste der Softwareentwicklung
Quelle: Eigene Darstellung.
In dieser Phase werden Entwicklungsaufgaben und dessen zugehörige Dokumente über ein Eingabeformular bearbeitet. Die Aufgaben benötigen bezüglich der weiteren Ausarbeitung zusätzliche Formularfelder. Die folgende Abbildung zeigt die Ansicht bzw. den Aufbau des Entwicklungsaufgabenbereiches der dritten Phase.
109 Abbildung 37: Portalkonzept der Testaufgabenzuweisung
Quelle: Eigene Darstellung.
Testaufgaben können an den Kunden zugewiesen werden. Der Inhaltsbereich für den Do-kumentenbereich wird nicht weiter beschrieben, da er lediglich eine Liste von bereitgestell-ten und erzeugbereitgestell-ten Dokumenbereitgestell-ten beinhaltet. Ab der dritbereitgestell-ten Phase steht die Rückmeldung mit dem Kunden im Vordergrund, um etwa auf Fragen oder Probleme eingehen zu können.
Die nächste Abbildung verdeutlicht das Konzept zur Umsetzung der Rückmeldungen.
Abbildung 38: Portalkonzept der Rückmeldung des Kunden
Quelle: Eigene Darstellung.
Ziel ist die Schaffung eines Systems, um Kundenrückmeldungen aufzunehmen, zu katego-risieren und zu bearbeiten. Hintergrund ist der Anspruch trotz der Anwendung eines klassi-schen Vorgehensmodells eine gewisse Agilität zu gewährleisten. Rückmeldungen erlauben dem Kunden, während der Entwicklung Anforderung anzupassen und neue Anforderungen an das System zu melden. Zu jeder Rückmeldung gibt es einen Titel, Status,
Verantwortli-110 chen, eine Priorität, Art sowie Kategorie. Für die Rückmeldungen wird eine Liste erstellt.
Diese wird in den drei Phasen „Softwareentwicklung“, „Bereitstellung zum Echtstart“ und
„Herstellung stabiler Dauerbetrieb“ verfügbar sein. Ein Projektmitarbeiter des Kunden erfasst eine Rückmeldung. Diese wird von der internen Projektleitung gesichtet und an-hand des Feldes „Art“ charakterisiert. Handelt es sich um einen Fehler, so benennt die Pro-jektleitung einen zuständigen Consultant. Dieser bearbeitet die Rückmeldung und meldet die entsprechenden Status. Der zuständige Projektteilnehmer auf Kundenseite testet die Anpassung abschließend und gibt die Anpassung frei. Handelt es sich um eine neue Anfor-derung, so erzeugt der Projektleiter eine neue Spezifikation. Diese wird dann mit Hilfe des Standardprozesses für Spezifikationen bearbeitet. Alle anderen Arten (z. B. Anforderungs-anpassung) werden vom Projektleiter eingetragen und die Kommunikation an zuständige interne Mitarbeiter übergeben. Diese besprechen das Thema mit dem verantwortlichen Kundenmitarbeiter und schließen die Rückmeldung ab, sobald diese vollständig bearbeitet ist. Die vorletzte Phase beinhaltet die Anforderungen der Integrationstests, Training und Massentests. In der vierten Phase muss das Projektportal unterstützend bei der Vorberei-tung des Echtstarts sein. In dieser Phase sind alle Einzelfunktionstests bereits abgeschlos-sen, und es kann mit Integrations- und Massentests fortgefahren werden. Diese müssen über das Portal angelegt, zugeordnet und nach korrektem Testdurchlauf bestätigt werden.
Erfolgreiche Testaufgaben, Benachrichtigungen über Fortschritte bezüglich Trainings wer-den durch Rückmeldungen stets nachvollziehbar und für alle Projektbeteiligen einsehbar.
Einen Einblick in den Aufbau der jeweiligen Inhaltsbereichen gibt die nächste Abbildung.
Abbildung 39: Portalkonzept der Integrationstests
Quelle: Eigene Darstellung.
111 Die Funktionen des Integrationstestbereiches umfassen das Erstellen, Hochladen und Be-arbeiten von integrationstestspezifischen Dokumenten. Neben dem Typ und Namen des jeweiligen Dokumentes wird zusätzlich auch angegeben, wer dieses Dokument wann er-stellt bzw. geändert hat. Die sekundären Elemente, Massentest und Trainingsunterlagen sind analog zum Integrationstest aufgebaut und werden aus diesem Grund nicht abgebildet.
Der Trainingskalender dient dazu, Trainings zu planen, abzustimmen und in Erinnerung zu behalten. In der Phase der Herstellung des stabilen Dauerbetriebes geht es um die detail-lierte Optimierung der entwickelten Software. Bestehende Funktionen sollen ausreichen, um einen optimale Kommunikation zu gewährleisten. Insofern noch Störungen oder Fra-gen im Projekt auftreten, kann bspw. die Funktion Rückmeldung angewandt werden.