Download
1 / 61
610 likes | 761 Views
Übersicht. Projektübersicht Projektziele, Projektaufbau, Projektablauf Projektbeschreibung Darstellung des Projekts iterativ Zwischenstand und Ausblick Vorführung Fragen?. -- Projektübericht --. Projektziele.
E N D
Übersicht • Projektübersicht • Projektziele, Projektaufbau, Projektablauf • Projektbeschreibung • Darstellung des Projekts iterativ • Zwischenstand und Ausblick • Vorführung • Fragen?
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 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 ManagerVerantwortlich 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:
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: 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: Risiken für das Projekt Risiken für die Eigenentwicklung: Ranking = 30% Wahrscheinlichkeit + 70% Auswirkung
Gliederung der Requirements nach logischen Gesichtspunkten: Login Rechteverwaltung Informationsstruktur Design & Bedienbarkeit Sicherheit Funktionalität sonstiges 1. Iteration: Requirements 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: 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: 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)
Automatische Authentifizierung gegenüber der Domäne Sammlung benutzerspezifischer Daten Grundlage für alle weiteren Module 2.+3. Iteration: Modul SSO
Entwicklung HTML-Template mit HTML, CSS, JavaScript Verwendung von Platzhaltern Sequentielle Ersetzung der Platzhalter durch PHP 2.+3. Iteration: Modul GUI
Informationen für zentrale Datenhaltung: Benutzer Benutzerrechte Abteilungen Unterseiten 2.+3. Iteration: Modul DB
Generierung dynamischen Inhalts für Platzhalter, abhängig von SSO DB LDAP Sicherheit 2.+3. Iteration: Modul SM/AC
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: 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.
Verwendung unterschiedlicher Browser Verwendung unterschiedlicher Webserver Zugriff von unterschiedlichen Rechnern Zugriff von Rechnern mit ungültigem Account Verwendung unterschiedlicher User 3. Iteration: Modultest SSO
Füllen des HTML-Templates mit Testdaten Anzeige unterschiedlicher Browser Sicherheitsbedenken JavaScript Unterschiedliche Systemumgebung (graphisch) Behindertenfreundlich 3. Iteration: Modultest GUI
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: Modultest SM/AC
