Zwischenstand und Ausblick Übersicht Projektübersicht Projektziele, Projektaufbau, Projektablauf Projektbeschreibung Darstellung des Projekts iterativ Zwischenstand und Ausblick Vorführung Fragen?

-- Projektübericht --

Projektziele Verbesserung des allgemeinen Informationsflusses im Sächsischen Serumwerk Dresden Allgemeine Informationen: mehr oder weniger nicht jobrelevante und eine größere Zielgruppe betreffenden Informationen (…) Lösungsansatz: Einführung eines zentralen Intranetportals

Zu erzielende Ergebnisse Die Lösung des Projekts soll die folgenden Ergebnisse beinhalten: Programm (einsetzbar, getestet, installationsfertig) Enduser-Dokumentation (Handbuch, Installationsplan) Projektdokumentation (SSW & BA - SE)

Mitarbeiter / Aufgabenverteilung Rolle Lutz Leonhardt Sächsisches Serumwerk Dresden Zirkusstraße 40 D-01069 Dresden Lutz.L.Leonhardt@gsk.com (+49 351) 4561 206 Stephan Henke Stephan.S.Henke@gsk.com (+49 351) 4561 224 Projekt Manager x Process Engineer Systems Engineer Software Engineer Test Manager Deployment Manager Project Manager Der Projekt-Manager teilt Betriebsmittel zu, setzt die Prioritäten fest, koordiniert die Interaktionen mit den Kunden/ Benutzern und leitet sein Projektteam durch den gesamten Prozess. Weiterhin stellt er die Vollständigkeit und Qualität der Dokumente und Artefakte sicher. Process Engineer Ist verantwortlich für die Projektumgebung und unterstützt das Team während der zu bearbeitenden Prozesse. Sein Aufgabenbereich ist in der Environment Disziplin des RUP beschrieben. System Engineer Verantwortlich für das Business Modelling und die Requirements Disziplin. Software Engineer Primär verantwortlich für Analyse & Design und die Implementations Disziplin. Test Manager Verantwortlich für die Verwaltung der Test Disziplin. Deployment Manager Verantwortlich für die Installationsaktivitäten und die Infrastruktur der Endbenutzer-Umgebung.

Konzeptioneller Projektaufbau Der Projektaufbau muss den Anforderungen an Dokumentationen nach den GlaxoSmithKline (GSK) Kriterien erfüllen. Diese sind durch internationale Vorschriften für pharmazeutische Unternehmen definiert. Der Aufbau entspricht dem Wasserfall-Prinzip und besteht grundsätzlich aus Requirements, Design-Spezifikation, Testplan, Testbericht sowie weiteren optionalen Dokumenten. Jede Phase muss einzeln genehmigt werden. Ergänzung der strikten GSK-Richtlinien durch die Möglichkeiten der Projektplanung des Rational Unified Process (RUP) aus der Vorlesung, die da wären: iteratives Vorgehen, Möglichkeit der nachträglichen Dokumentationsänderung, flexibles Handling des Prozesses, abhängig von Projektfortschritt.

Umsetzung des Prozesses Genaue Prozessbeschreibung entstand step-by-step: Phase Definition Inception 1. Iteration: Ausarbeitung der Basisinformationen, wie initiale Projektplanung, Requirements, Marktanalyse, Risikountersuchung, etc. Elaboration 2. Iteration: Umsetzung der Anforderungen in konkrete Designelemente, Zerlegung des Gesamten in Module 3. Iteration: detaillierte Ausarbeitung der einzelnen Module und Programmierung und Test dieser Construktion 4. Iteration: Zusammenfügen der Module 5. Iteration: Test der kompletten Anwendung Transition 6. Iteration: Einführung im SSW (Schulungen, Handbücher, Installationsdokumentation)

Projektdokumentation Inhalt Requirements Beinhaltet Projektinitialisierung Planung Beinhaltet Prozess- und Projektplanung Design und Entwicklung Festlegungen zur tatsächlichen Umsetzung der Requirements in Form von Designspezifikationen als Grundlage der Programmierung Test Dokumentiert alle Arbeitsschritte, die mit dem Testen des Programms oder Programmteilen zu tun haben Guideline Regelung zu Abläufen, Formulierungen, Darstellung, etc. Templates Diverse Vorlagen für Dokumente und Präsentationen mit fertigen Formatdefinitionen

-- Projektbeschreibung --

1. Iteration: Ziele Diese erste Phase des IntraKom-Projekts beinhaltet die Inception Phase des Rational Unified Prozess, initialisiert also unser Projekt. Ziel der Iteration ist es also, die Anforderungen der Stakeholder an das Projekt zu sammeln, untersuchen und analysieren und daraus ein erstes Konzept zu Art und Umfang der Projekts zu erstellen. Der Einsatz von UML-Diagrammen soll Abläufe, Beziehungen, Nutzerklassen und ihr Verhalten und Handeln, etc. Darstellen und klären. Eine Analyse möglicher Risiken soll späteren Problemen vorbeugen. Ein wichtiger Punkt dieser Iteration ist die Gestaltung des Gesamtprojekts, also einen bestimmten Prozess zu definieren, die nötigen Artefakte festzulegen, Rollen und Aufgaben zu verteilen und wichtige Meilensteine ansetzen. Meilenstein der Iteration ist die Präsentation der vorläufigen Projektierung am 12.12.2005.

1. Iteration: Aufgaben (1) Beschreibung Initialisierung Hauptsächlich ging es in dieser Aufgabe um die Findung eines Projekts und die Auseinandersetzung mit dem zu erwartendem Inhalt und den Problemen. Auch eine Einarbeitung in den RUP fand hier statt. Requirements Sammeln und analysieren der Requierements der Stakeholder Erste Beschreibung des Programms als Grundlage für die Marktanalyse und Erweiterung nach Festlegung auf eigene Programmierung Marktanalyse Untersuchung von bereits am Markt vorhandenen Portalen/CMS-Systemen auf Einsetzbarkeit im SSW auf Grundlage der Requirements und Beschreibungen Risikoanalyse Sammeln, Analysieren und Einschätzen möglicher Risiken für das Projekt

1. Iteration: Aufgaben (2) Beschreibung UML Auseinandersetzung mit UML und erste Darstellung von Requirements Projektplanung Ausarbeitung eines groben Projektplans Iterationsplanung Tiefergehende Planung dieser Iteration Dokumentations-umplanung Umstrukturierung der Dokumente weg von RUP in Richtung der GSK-Policies Workflow Festlegen von Guidlines und Erarbeitung von Vorlagen Präsentation Präsentation erster Ergebnisse in SE Review Review der ersten Iteration

1. Iteration: Ablaufplanung

1. Iteration: Zeitplanung

1. Iteration: Marktanalyse Das System soll folgende Grundeigenschaften haben: Login-System mit User-/Gruppenverwaltung Zugriffsbeschränkung auf einzelne Teile per User-/Gruppenrichtlinie Oberfläche als HTML-Fontend einfache Administrierung für weniger versierte User (mit CMS) lauffähig auf Windows Servern einfache Informationsbereitstellung Die Marktanalyse war Grundlage für eine eigene Praxisarbeit über den Vergleich diverser CMS-Produkte unter 1500 €. Leider konnten uns keine der getesteten Produkte in Funktionsumfang und Handhabung überzeugen, oder sie waren mit ihren Lizenzmodellen deutlich über den Preis, den die Kalkulation für eine Eigenentwicklung ergeben hat

1. Iteration: Kostenabschätzung Während der Software-Entwicklung sind beide Entwickler im SSW beschäftigt und werden mit einem festen Gehalt entlohnt. Die Arbeitszeit liegt im gesamtem Produktionsrahmen über 5 Monate in der Theoriephase, wo beide Entwickler entlohnt werden, aber nicht im SSW arbeiten. Würden sie nicht an Intrakom arbeiten, würden sie trotzdem entlohnt: Von projektbezogenen Kosten kann also keine Rede sein. Während der Praxisphase liegt der Anteil der Projektarbeit an der SSW-Arbeitszeit bei 10%, wenn überhaupt. Die Entwicklungsdauer beträgt 8 Monate, dies bedeutet: [5 (Monate) * 0 (Kosten für SSW an Intrakom während Theorie-Phase) + 3 (Monate) * 0,1 (Anteil der Arbeitszeit in Praxis-Phase im SSW)] * 2 (Entwickler) * 650,00 € (Bruttogehalt) = 390,00 € Für das SSW fallen in der Zeit Personalkosten in Höhe von 390,00 € (zzgl. Arbeitgeberanteil an Sozialleistungen) an, die dem Projekt zu geschrieben werden müssen. Zusätzlich fallen Hardware- und Lizenzkosten an.

1. Iteration: Selbst entwickeln! An Hand der Marktanalyse und der Kostenabschätzung für eine Eigenentwicklung wurde entschieden, die Software selbst zu programmieren. Vorteile: Erfüllung aller Anforderungen geringe Kosten Nachteile: langwierige Entwicklung Risiko des Scheiterns

1. Iteration: detaillierte Beschreibung Webapplikation als Standard-Website des Firmen-Intranets Authentifizierung per Single Sign On Gruppen- / Benutzerrechte per LDAP gegen Active Directory 3 Rechtklassen (Leser, Manager, Admin) offener und abteilungsinterner Bereich News-System Möglichkeiten zum Datei-Upload einfaches CMS zur Pflege

1. Iteration: Rollenverteilung (1)

1. Iteration: Rollenverteilung (2)

1. Iteration: Risiken für das Projekt Risiken für die Eigenentwicklung: Ranking = 30% Wahrscheinlichkeit + 70% Auswirkung

1. Iteration: Requirements Gliederung der Requirements nach logischen Gesichtspunkten: Login Rechteverwaltung Informationsstruktur Design & Bedienbarkeit Sicherheit Funktionalität sonstiges Weitere Requirements betreffen Hardware, Zutritts- und Zugriffssicherheit, Installationspläne, etc. und werden durch GSK vorgegeben und sind nicht Bestandteil des Projekts sondern der SSW internen Umsetzung.

1. Iteration: Review Nach anfänglichem schnellem Projektfortschritt verloren wir uns in den unendlichen Weiten des RUP, was zu einer Neustrukturierung des Projekts und der Dokumentation führte und den Prozess (wie Anfangs beschrieben) mehr Richtung Wasserfall-Prozess von GlaxoSmithKline führte. Trotz redundanter Speicherung der Projektdateien auf unterschiedlichen Rechnern und FTP-Server gingen kurz vor Schluss die UML-Diagramme verloren.

2. Iteration: Ziele Hauptaufgabe dieser Iteration ist die Umsetzung der Requirements und der ersten Detailbeschreibungen in konkrete Definitionen. Resultat muss eine ausführliche Projektbeschreibung sein. Anschließend soll das Projekt in Module zerlegt werden, um die parallele Abarbeitung zu gewährleisten. Diese Module werden anschließend noch detaillierte definiert, insbesondere Schnittstellen. Diese Definitionen sind Grundlage („Blaupause“) führt die spätere Entwicklung)

2. Iteration: Aufgaben Aufgabe Beschreibung Iterationsplanung Planung dieser Iteration Projektplanung Durch die Kenntnisse über Design und Zerlegung in Module kann der Rest des Projektablaufs definiert werden Modularisierung Zerlegung in Module Workflow Ausarbeitung von Guidlines zur Programmierung Gesamtdesign Detaillierte Beschreibung des System als Ganzes Moduldesign Detaillierte Definition der Module und Schnittstellen Review Review zweite Iteration

2. Iteration: Ablaufplanung

2. Iteration: Zeitplanung

2. Iteration: Struktur

2. Iteration: Rollen (1) Als Rechte für einen Benutzer stehen folgende Möglichkeiten zur Verfügung. Ein Nutzer kann prinzipiell nur auf die öffentlichen Sites und die der eigenen Abteilung zugreifen. Höhere Rechte beinhalten niedrigere Rechte. ● keine Zugriff ● Leser (gilt für diese Subsite) Ist ein User mit Rechten größer als Leser ausgestattet (für die gerade offene Site) bekommt er im unteren Bereich eine Leiste (Footer) angezeigt, in der er verschiedene Editor-Funktionen auswählen kann: ● als C_Manager (gilt nur für Subsites) bekommt er die Möglichkeit, den Inhalt per CMS zu editieren ● als S_Manager (gilt nur für Subsites) bekommt er zusätzlich die Möglichkeit, die Zugriffsoptionen für diese Site zu bearbeiten, höhere Rechte (SU_Manager und Admin werden angezeigt, können aber nicht editiert werden) ● SU_Manager hat zusätzlich die Möglichkeit, innerhalb der Mainsite neue Subsites anzulegen bzw. vorhandene zu löschen sowie Rechte und Inhalt zu editieren. Er gilt für die gesamte Mainsite inklusive aller Subsites ● Administratoren haben dazu noch die Möglichkeit, weitere Administratoren zu definieren. Er kann alles und überall.

2. Iteration: Rollen (2)

2. Iteration: Rollen (3)

2. Iteration: Rollen (4)

2. Iteration: Ablauf Programm

2. Iteration: Zerlegung Um eine parallele Bearbeitung eines Produktes zu ermöglichen, ist es üblich, das Programm in logische, aber auch praktisch sinnvolle, Teilprogramme, im weitern Module genannt, zu zerlegen. Bezogen auf die Programmdefinition in Kapitel 4 ergeben sich für das Intrakom-System folgende Module: ● Single Sign On (SSO) ● Access Control und Site Management (AC/SM) ● User Interface (GUI) ● Datenbank (DB) ● Content Management (CM)

2.+3. Iteration: Modul SSO Automatische Authentifizierung gegenüber der Domäne Sammlung benutzerspezifischer Daten Grundlage für alle weiteren Module

2.+3. Iteration: Modul GUI Entwicklung HTML-Template mit HTML, CSS, JavaScript Verwendung von Platzhaltern Sequentielle Ersetzung der Platzhalter durch PHP

2.+3. Iteration: Modul DB Informationen für zentrale Datenhaltung: Benutzer Benutzerrechte Abteilungen Unterseiten

2.+3. Iteration: Modul SM/AC Generierung dynamischen Inhalts für Platzhalter, abhängig von SSO DB LDAP Sicherheit

2.+3. Iteration: Modul CMS Dieses Modul soll die Veränderung von Inhalten der Seiten von technisch unkundigen Mitarbeitern ermöglichen. Notwendig hiefür ist eine einfache, übersichtliche Bedienung, die möglichst an bekannte Produkte wie Office erinnert. Die Darstellung der Änderungen muss in Echtzeit erfolgen. Mangelnde Vorstellungen einer zeitnahen und anforderungsgetreuen Umsetzung mitteln PHP, HTML, CSS und JavaScript zwingt uns dieses Modul zu einem späteren Zeitpunkt zu entwickeln.

2. Iteration: Review Hauptaufgabe dieser zweiten Iteration war die Umsetzung der Anforderungen des Auftraggebers SSW in eine für die Programmierung verwertbare Art und Weise. Dies bedeutete vor allem die Zerlegung des Projekts in Module und die theoretische Entwicklung dieser Module, als Ablaufpläne, Definition von Schnittstellen, usw. Zeitgründe, sowie mangelnde Ideen für die Umsetzung eines Echtzeit-CMS mittels PHP, CSS und JavaScript, welches auch von Laien ohne weiteres verwendet werden kann, nötigten uns zu der Entscheidung, das CMS zu einem späteren Zeitpunkt zu entwickeln. Schließlich muss das Projekt weitergehen und das CMS ist modular einpflegbar.

3. Iteration: Ziele Aufgabe ist es, die in Iteration zwo definierten Module (mit Ausnahme des CM-Moduls) umzusetzen und zu testen. Dazu sind die im Design-Dokument definierten Vorgaben zu den Modulen und Schnittstellen einzuhalten oder im Bedarfsfall die Definitionen im Designdokument anzupassen und für alle anderen betroffenen Module zu aktualisieren.

3. Iteration: Aufgaben Aufgabe Beschreibung Iterationsplanung Planung der Iteration Moduldesign Änderungen an den Moduldefinitionen während der Programmierung Modulentwicklung Programmierung der einzelnen Module Modultest Ist ein Modul als funktionsfähig eingestuft, muss es einem Einzeltest unterzogen werden, der Funktionaliät sichern soll Arbeitsumgebung Entwerfen und Aufbauen einer Test- und Arbeitsplattform Review Review der Iteration

3. Iteration: Ablaufplanung

3. Iteration: Zeitplanung

3. Iteration: Arbeitumfeld Grundlage: Microsoft Windows 2003 Server (ADS) Firefox und IE Client PHP 5 + open_ldap Microsoft Testfeld: IIS 6 MS SQL Server 2005 OpenSource Testfeld Apache 2 + mod_auth_sspi MySQL 4

3. Iteration: Testrichtlinien Es sind Testziele zu definieren und aufbauend ein Testplan zu erstellen, der mit geeigneten Testverfahren diese Ziele prüft. Dies ist im Test-Plan zu beschreiben. Bei der Durchführung der Tests, ist zu Dokumentieren, ob ein Test tatsächlich auch den Erwartungen genügt oder ob Abweichungen / Fehler entstanden sind. Dies im im Test-Bericht zu dokumentieren. Abweichungen sind – wenn möglich – zu erklären und zu bewerten: (B)Bedeutende Fehler sind Fehler, die andere Module betreffen oder umfangreiche Änderungen im Programmcode zur Folge haben. In diesem Fall ist die jeweilige Iteration (Design, Entwicklung, Test) erneut zu durchlaufen. (U)Unbedeutende Fehler sind Abweichungen, die keinen geringen Aufwand bedeuten. Sie sind zu erläutern, Programmänderungen zu dokumentieren. Der Test-Manager ist für die Durchführung der Test verantwortlich. Mit seiner Bestätigung garantiert er die Funktionalität des vorliegenden Codes. Nun ist das Programm(-Teil) dem Projekt-Manager vorzuführen, mit seiner Abnahme bestätigt er die Umsetzung der Anforderungen. Er muss Funktionsumfang, Handhabung, Lesbarkeit, etc. Bestätigen. Dieser Schritt dient der Qualitätskontrolle.

3. Iteration: Modultest SSO Verwendung unterschiedlicher Browser Verwendung unterschiedlicher Webserver Zugriff von unterschiedlichen Rechnern Zugriff von Rechnern mit ungültigem Account Verwendung unterschiedlicher User

3. Iteration: Modultest GUI Füllen des HTML-Templates mit Testdaten Anzeige unterschiedlicher Browser Sicherheitsbedenken JavaScript Unterschiedliche Systemumgebung (graphisch) Behindertenfreundlich

3. Iteration: Modultest SM/AC Indirekter Test Modul DB Nutzung des Moduls GUI Bekommen unterschiedliche Nutzer die richtigen Mainsites angezeigt bekommt man für jede Subsite das richtige Recht (und den entsprechenden FOOTER) werden Rechteänderungen übernommen werden Strukturänderungen durch neue Abteilungen übernommen

3. Iteration: Review Inhalt dieser Iteration war die Programmierung der Module, d.h. die Umsetzung der Designspezifikationen der zweiten Iteration in funktionierenden Programmcode und das Testen der einzelnen Module. Für die Module SSO, SM/AC ist dieser Vorgang abgeschlossen. Für diese beiden Teiliterationen liegt der Prototyp vor und wurde getestet. Das Modul CM (Content Management) wird zu einem späteren Zeitpunkt entwickelt, es liegt kein Prototyp vor und auch kein Test. Das Modul GUI ist bis auf die graphischen Elemente, die durch das CM-Modul fehlen fertig und liegt getestet vor. Das Modul DB wurde im Zusammenhang mit dem SM/AC-Test getestet (für welchen wiederum das GUI-Modul verwendet wurde)

4. Iteration: Ziele, Aufgaben, Review Inhalt dieser vierten Iteration ist der Zusammenschluss der einzelnen Module zu einem gesamten Programm. Dazu müssen noch einige kleine Anpassungen und Optimierungen vorgenommen werden. Aufgabe Beschreibung Iterationsplanung Planung der Iteration Zusammenschluß Zusammenführen der einzelnen Module, soweit noch nicht geschehen. Optimierung der Abläufe, etc. Review Review der Iteration Alle aktuell vorhandenen Module sind zusammengeführt wurden. Es fehlt das CMS mit News-System

4. Iteration: Zusammenführung Zentrales Interface: index.php (kleine Datei) Zentrale Haltung der Konfigurationsdaten der Module: config.php Verwendung HTTP: GET, POST Ersetzung der Platzhalter Auswertung der GET-Variablen id

5. Iteration: Ziele Aufgabe dieser Iteration ist es einerseits, das in Iteration vier zu einer Einheit geschlossene System in seiner Gesamtheit zu testen. Die andere Aufgabe ist Überarbeitung aller Dokumente bis zum Meilenstein 12.05.2006 – dem Tag der Projektabgabe. Eine weitere Aufgabe hängt mit dem zweiten Meilenstein dieser Iteration zusammen: Am 19.05.2006 ist das Projekt mit einer Präsentation vorzustellen und zu verteidigen. Die Präsentation dazu muss natürlich noch erarbeitet werden.

5. Iteration: Planung

5. Iteration: Review Projektabgabe und Verteidigung (fast) erfolgt. Der finale Test wurde nicht durchgeführt, da vorhergehende Schritte noch nicht abgeschlossen wurden und somit der finale Test nicht vollständig wäre.

-- Zwischenstand & Ausblick --

Zwischenstand und Ausblick Das Projekt Intrakom hat die fünfte Iteration absolviert. Für das Programm bedeutet das, dass es alle bisherigen Phasen erfolgreich durchlaufen hat und entwickelt und getestet vorliegt. Eine Ausnahme bildet das Modul Content Management. Es war uns aus Zeitgründen nicht möglich, ein vollwertiges CMS zu erarbeiten, welches ohne weiteres von technisch unkundigen Mitarbeitern genutzt werden kann. Anforderungen wären u.a. Freie Gestaltung in Echtzeit, Möglichkeiten zum Einbinden anderer Quellen, Dateiupload, etc. Es ist zu einem späteren Zeitpunkt ohne Probleme möglich, dieses Modul in die Anwendung einzubauen, die Schnittstellen sind bereits vorhanden. Nachtragungen in der Dokumentation sind selbstverständlich. Mit Vollendung des letzten Moduls kann auch der noch nicht durchgeführte Kompletttest des Programms durchgeführt werden. Die nächste, sechste und letzte Iteration umfasst die Einführung im SSW. Eine Iteration in der auch Dokumente wie Handbücher oder Installationspläne entwickelt werden müssen. Deshalb sind die vorliegenden Handbücher noch in der Entwicklungsphase.

-- Vorführung --

Projektvorführung: Umgebung Domäne: GSK.COM Abteilungen: EDV, PA, FE Benutzer: (EDV) Administrator, MitEDV1,MitEDV2,AzubiEDV1 (PA) LeiterPA,MitPA1,MitPA2,AzubiPA1 (FE) LeiterFE,MitFE1,MitFE2,AzubiFE1 Rechte für EDV-Benutzer sind vergeben EDV-Administrator = Administrator „Intrakom“

??? Fragen ???