Projekt Message-Logger

Transkript

1 M o d u l S o f t w a r e k o m p o n e n t e n T A. S W K. F Projekt Message-Logger P r o j e k t p l a n Horw,

2 Projekt Dokument Schule Modul Projektteam Dozenten Letzte Änderung Projekt Message-Logger Projektplan Hochschule Luzern, TA.SWK.F1001 Galliker Thomas Panorama 6123 Geiss Tel Stocker Elias Schybenacherweg Hitzkirch Tel Prof. Jud Martin 27. Mai 2010, 14:40:00 Uhr Gasser Martin Mettenwilhöhe Ballwil Tel [email protected] Änderungsprotokoll Version Datum Autor Beschreibung gat Initialversion von Vorlage erstellt ste Risikoliste / Rahmenplan gam Aufwandschätzung gat Einleitung, Projektorganisation gat Gesamtüberarbeitung, Aufwandschätzung ergänzt gat Ist-Aufwände erfassen gat Ist-Aufwände erfassen gam Ist-Aufwände nachgetragen, diverse weitere Aktualisierungen vorgenommen ste Auswertung Ist-/Soll-Aufwand gat Lessions Learned

3 Inhalt 1 Einleitung Ziel & Zweck dieses Dokuments Projektübersicht Begriffe & Abkürzungen Projektorganisation Projektstruktur Projektmitglieder Rollen & Zuständigkeiten Risikomanagement Planung Grobplanung Meilensteine Rahmenplan Aufwandschätzung und Benchmarking Projektunterstützung Konfigurationsmanagement Versionisierung Configuration Items Dokumentationsplan Projektabschluss Lessions Learned Freigabeprotokoll...14

4 Abbildungsverzeichnis Abbildung 1: Projektstruktur...6 Abbildung 2: Gantt-Diagramm des Rahmenplans...10 Tabellenverzeichnis Tabelle 1: Begriffserklärungen...5 Tabelle 2: Abkürzungserklärungen...5 Tabelle 3: Koordinaten der Projektmitglieder...6 Tabelle 4: Rollen & Zuständigkeiten...7 Tabelle 5: Risikoanalyse: Risiken und geplante Gegenmassnahmen...8 Tabelle 6: Detaillierte Aufschlüsselung der Meilensteine...9 Tabelle 7: Aufwandschätzung...12 Tabelle 8: Liste der Dokumente, welche im Rahmen des Projekts entstehen...13

5 Projektplan Einleitung Hochschule Luzern 1 Einleitung 1.1 Ziel & Zweck dieses Dokuments Dieser Projektplan ist das zentrale Dokument für das Projekt Management im Projekt Message-Logger im Modul TA.SWK.F Projektübersicht Beim Message-Logger handelt es sich um eine Software-Komponente, die sehr einfach in eine bestehende Java-Applikationen (im folgenden Client genannt) eingebunden werden kann. Ein Client kann durch einfache Methodenaufrufe textbasierende Meldungen mit seinem Message-Logger dauerhaft aufzeichnen. Die Meldungen aller Clients werden in einer zentralen, gemeinsamen Datei gespeichert. Mit einem Message-Viewer-Tool, einer eigenständigen Applikation die unabhängig vom Client arbeitet, können alle generierten Meldungen eines oder mehrerer Clients online verfolgt und angezeigt werden. 1.3 Begriffe & Abkürzungen Begriff Erklärung Tabelle 1: Begriffserklärungen Abkürzung HSLU SWK gat ste gam Erklärung Hochschule Luzern "Softwarekomponenten"; Modulbezeichnung HSLU Namenskürzel für Galliker Thomas Namenskürzel für Stocker Elias Namenskürzel für Gasser Martin Tabelle 2: Abkürzungserklärungen TA.SWK.F1001 Projekt Message-Logger Team 10 5 / 14

6 Projektplan Projektorganisation Hochschule Luzern 2 Projektorganisation Projektstruktur Auftraggeber STASS Elias Stocker Martin Gasser Interface-Delegierter Thomas Galliker Projektleiter Abbildung 1: Projektstruktur Projektmitglieder Name / Adresse Telefon Galliker Thomas [email protected] Panorama 6123 Geiss Stocker Elias [email protected] Schybenacherweg Hitzkirch Gasser Martin [email protected] Mettenwilhöhe Ballwil Tabelle 3: Koordinaten der Projektmitglieder Rollen & Zuständigkeiten Rolle Verantwortung Beschreibung / Aufgaben Projektspezifisch Projektmanagement gat Ist für das Projekt verantwortlich - Leitet die Sitzungen - Verteilt Aufgaben an Teammitglieder - Hält den Projektplan aktuell Delegierter Interface-Komitee gam Erstellt im Komitee die Schnittstellen-Definition Programmierung gam Siehe genauere Definition unten Testmanagement ste Erstellt und Ergänzt Testdokument & ist für die Tests verantwortlich - Wertet die Tests aus Architektur gam Plant die SW-Architektur und erstellt das grobe Gerüst (Struktur & Files) in NetBeans - hält den Lead bei der Programmierung (genauere Definition siehe unten) Dokumentenverwaltung ste Erstellt Layout aller Dokumente, hält diese aktuell (z.t. durch TA.SWK.F1001 Projekt Message-Logger Team 10 6 / 14

7 Projektplan Projektorganisation Hochschule Luzern Input der anderen Gruppenmitglieder) - hält Struktur auf ILIAS - behält den Überblick über die Dokumente Entwicklungsspezifisch Message-Logger Server gam Die Komponente "Message-Logger Server" (im Folgenden als "Server" bezeichnet) übernimmt die Funktion des Listeners, welcher auf Client-Anfragen reagiert. Die Anwendung wird als Java Console Application realisiert ein GUI ist nicht erforderlich um die gewünschten Anforderungen umzusetzen. Typischer Funktionsumfang der Server Komponente: Abhören der zugewiesenen TCP Ports Verarbeitung von eingehenden Nachrichten sowie Viewer Requests Speichern von Nachrichten in Text-File Ausgabe von Message Log Informationen an Viewer Implementierung einer Konfigurationsdatei zur persistenten Ablage von Einstellungen Message-Logger Komponente gat Die Message-Logger Komponente ist massgeblich dafür verantwortlich, die Kommunikation zwischen Test Applikation und Server zu realisieren. Sie implementiert sämtliche im Interface spezifizierten Methoden. Zudem stellt die Message-Logger Komponente auch eine Config Klasse bereit, welche als Träger für Konfigurationsparameter gebraucht werden kann. Message-Logger Interface gam Die Spezifikation für das Message-Logger Interface wurde gemeinsam in Gruppen erstellt. Das Interface beschreibt verbindliche Schnittstellen, welche von allen Projektteams eingehalten werden müssen. Auf das Interface wird in der Test Applikation referenziert, sodass später die Message-Logger Komponente jederzeit durch eine funktionsgleiche Software Komponente ersetzt werden kann. Message-Logger Viewer ste Die Message-Logger Viewer Komponente ist für das Auslesen und die Darstellung von Message-Logger Einträgen verantwortlich. Des Weiteren soll das Viewer GUI auch Möglichkeiten zur Sortierung und Filterung bereitstellen. Weitere Manipulationsmöglichkeiten (ändern/löschen von Einträgen) wären zusätzliche Optionen. Test Applikation gat Eine einfache Test Applikation sorgt dafür, dass die Message- Logger Komponente unter realistischen Bedingungen getestet werden kann. Sie dient auch zusammen mit der Message- Logger Viewer Komponente zur Visualisierung der Funktionalität. Tabelle 4: Rollen & Zuständigkeiten TA.SWK.F1001 Projekt Message-Logger Team 10 7 / 14

8 Projektplan Risikomanagement Hochschule Luzern 3 Risikomanagement Auflistung von möglichen Risiken welche im Verlauf des Projekts eintreten können sowie die entsprechenden Gegenmassnahmen: Initialrisiko 1 Vermeidungsaufwand 2 Gewichtung 3 Beschreibung Massnahmen Gruppenmitglied fällt aus Bei einem Ausfall frühzeitig Gruppenmitglieder informieren 2 2 Terminplanabweichungen Erst durch eine Analyse Arbeitspakete festlegen, danach durch Synthese einen 2 1 realistischen Rahmanplan erstellen. Missverständnisse im Projektauftrag Projektauftrag sauber lesen und alle Unklarheiten beseitigen 2 1 Missverständnis in der Interface Definition Klare, saubere und unmissverständliche Dokumentation der Schnittstellen, 1 2 Kommunikation mit anderen Gruppen Nicht einhalten einzelner Anforderungen Frühzeitig planen, Meilensteine festlegen, Validierung der Meilensteine, gegebenenfalls 2 2 frühzeitig Massnahmen treffen, Controlling Eingesetzte Technologie ist zu komplex Vorausschauende Wahl der Entwicklungsumgebung, Mitberücksichtigung in 1 1 Aufwandschätzung Komplexität der Komponente wird nicht Komplexität der Architektur und des Designs klein halten und überprüfen anhand eines 2 3 mehr handelbar Prototypen; modularisierte Entwicklung Angewendete Architektur ist nicht Zweck Vorausschauende Spezifikation der Architektur 2 3 entsprechend Test Cases sind ungenügend spezifiziert Vorausschauende Spezifikation der Test Cases mit Hilfe der Use Cases 2 2 Definierte Aspekte des Systemtests sind Vorausschauende Definition der Testaspekte und Durchführung anhand eines 1 1 nicht durchführbar Prototypen Resultate aus Tests sind ungenügend Genügend Zeit für die Testdurchführung einplanen; Unit-Tests bereits während der 2 2 Entwicklungsphase einplanen Dokumentation unvollständig / inkonsistent Genügend Zeit für die Dokumentation einplanen 2 1 Tabelle 5: Risikoanalyse: Risiken und geplante Gegenmassnahmen Legende 1 Risiko (R) 1 Geringes Risiko 2 Mittleres Risiko 3 Hohes Risiko 2 Vermeidungsaufwand (V) 1 Geringer Aufwand 2 Mittlerer Aufwand 3 Hoher Aufwand TA.SWK.F1001 Projekt Message-Logger Team 10 8 / 14 Risiko 1 per Risiko 1 per Gewichtung (G) Diejenige Massnahme, welche das grösste Gewicht erreicht, wird in erster Priorität umgesetzt. D.h. das Gewicht stellt eine Sortierreihenfolge zur Festlegung der Umsetzungspriorität dar. Berechnung: (G) = (R) / (V)

9 Projektplan Planung Hochschule Luzern 4 Planung 4.1 Grobplanung Projektstart (SW2) Projektabschluss SW14 Projektiterationen Meilensteine SW Inhalt Meilenstein SW1 SW2 SW3 SW4 Organisation der Gruppe und Organisation des Interface Komitee ist definiert Risikoliste Rahmenplan mit Meilensteinen grobe Aufwandschätzung Kurzbesprechung mit dem Dozenten, Protokoll durch Gruppe Erstellung Projektmanagementplan Interfaceteam Besprechung Aufteilen von Arbeiten Dokumentationsplan Liste der Konfigurations-Items Testplan: Testphilosopie und drei wesentliche Testaspekte Kurzbesprechung mit dem Dozenten, Protokoll durch Gruppe Von den drei Interface-Teams liegen erste dokumentierte Versionen des Interfaces vor. Präsentation und Besprechung im Plenum, Freigabe mit dem Dozenten Detaillierte Aufgabenteilung Fortsetzung Interface Spezifikation SW5 Planung erste Iteration liegen vor: detaillierte Aufwandschätzungen, Arbeitsteilung in Gruppe, Organisation des Controlling etc. festgelegt. Freigegebene Version des Interfaces liegt vor. Peer Review sind organisiert (personell und zeitlich) Spezifikation der drei Elemente für das Systemtesting einschliesslich der Definition des Vorgehens liegt vor. Kurzbesprechung mit dem Dozenten, Protokoll durch Gruppe SW6 SW7 SW8 SW9 Tabelle 6: Beginn Programmierung, Prototyp erstellen Unit-Testing Systemtest des Prototyps Prototyp freigeben zur Präsentation Demonstration / Präsentation Softwareanforderungen erstellt; Architektur ist festgelegt und exemplarisch dokumentiert. Prototyp ist lauffähig und kann demonstriert werden. Abgabe der Dokumentation & Projektcontrolling Mo, :00 ILIAS Briefkasten Kurzbesprechung mit dem Dozenten, Protokoll durch Gruppe Detaillierte Aufschlüsselung der Meilensteine TA.SWK.F1001 Projekt Message-Logger Team 10 9 / 14

10 Projektplan Planung Hochschule Luzern 4.3 Rahmenplan Semesterwoche Tag Iteration 1 Iteration 2 SW1 SW2 SW3 SW4 SW5 SW6 SW7 SW8 SW9 SW10 SW11 SW12 SW13 SW14 DO FR DO FR DO FR DO FR DO FR DO FR DO FR DO FR DO FR DO FR DO FR DO FR DO FR DO FR Gruppenbildung Risikoliste Rahmenplan Aufwandschätzung Testplan Interface Spezifikation Dokumentationsplan Peer Review Planen Peer Review Durchführen System Spezifikation Implementation Server Implementation Logger Implementation Viewer Implementation TestApp. Integration & Tests Installationsanleitung Präsentationsvorbereitung Präsentation Abbildung 2: Gantt-Diagramm des Rahmenplans TA.SWK.F1001 Projekt Message-Logger Team / 14

11 Projektplan Aufwandschätzung und Benchmarking Hochschule Luzern 5 Aufwandschätzung und Benchmarking Die nachfolgenden Schätzungen beziehen sich auf den Gesamtaufwand, welcher das Team zu leisten hat. Die einzelnen Stundenangaben sind als Mannstunden zu verstehen. Um einen guten IST-SOLL Vergleich zu erlangen, wird in regelmässigen Zeitabschnitten der ungefähre IST Aufwand erfasst. SOLL Aufwand IST Aufwand Auswertung Schätzung 1 Schätzung 2 Mittelwert SW1-3 SW4-6 SW7-9 SW10-14 Differenz Projektmanagement Kick Off, Bilden der Gruppe/Interface-Komitee, Definieren der Zuständigkeiten, Erstellen der Dokumentgrundstruktur Risikomanagement: Erörterung und Bewertung von Risiken Rahmenplan mit Meilensteinen und grobe Aufwandschätzung erstellen Erstellen des Projektmanagementplan Erstellen des Testplan, Definition der Testfälle Planen und durchführen des Peer Review Dokumentationsplan mit Dokumentenübersicht erstellen Systemspezifikation erstellen und nachführen Entwicklungsaufwand Definieren des Interface' Programmieraufwand Iteration Implementation Message-Logger Server Implementation Message-Logger Komponente Implementation Message-Logger Viewer Implementation Test Applikation Programmieraufwand Iteration Unit-Tests TA.SWK.F1001 Projekt Message-Logger Team /

12 Projektplan Aufwandschätzung und Benchmarking Hochschule Luzern Integrations-/Systemtests Projektabschluss Installationsanleitung erstellen Vorbereitung und Durchführung der Präsentation Tabelle 7: Aufwandschätzung TA.SWK.F1001 Projekt Message-Logger Team / 14

13 Projektplan Projektunterstützung Hochschule Luzern 6 Projektunterstützung 6.1 Konfigurationsmanagement Versionisierung Der gesamte Programmcode wird in NetBeans erstellt und mit Hilfe eines Subversion-Plugins versionisiert. Somit können Änderungen am Code vollständig nachvollzogen und im Fehlerfall auch rückgängig gemacht werden. Der Subversion Server wird von der HSLU bereitgestellt: Alle im Rahmen des Projekts erarbeiteten Dokumente werden von den entsprechenden Autoren manuell versionisiert. Dafür wurde eine Versionisierungstabelle am Anfang jedes Dokuments eingefügt. Um den Dokumentenaustausch zu vereinfachen und die Kommunikation für die Dokumentenkooperation zu minimieren, verwendet das Projektteam das Freeware Tool "Dropbox" ( Configuration Items Dokumentation Message-Logger Server Message-Logger Komponente Message-Logger Viewer Betriebssystem Java Runtime 6.2 Dokumentationsplan Die Dokumentationen und das Projektmanagement werden anhand des Prozesses HTAgil durchgeführt und festgehalten. Die Dokumente werden mit Dropbox verwaltet. Die Versionisierung wird über die entsprechende Tabelle des jeweiligen Dokuments vorgenommen. Folgende Dokumente werden im Verlauf des Projektes erstellt: Dokument Zeitraum Kommentar zur Abgabe Verantwortung SWK_Projekt_Projektplan.doc SW02 SW13 Digital vorweisen Am Ende zur schriftlichen Dokumentation hinzulegen SWK_Projekt_Testplan.doc SW3, SW9 Digital vorweisen Am Ende zur schriftlichen Dokumentation SWK_Projekt_Testprotokoll_XY.d oc SWK_Projekt_Systemspezifikatio n.doc gat ste Autor Alle Alle SW02-SW8 Digital ste Alle SW4 SW5, SW10 Digital vorweisen Am Ende zur schriftlichen Dokumentation SWK_Projekt_Review_XY doc SW4 SW5 Digital vorweisen & Partnergruppe zur Verfügung stellen SWK_Projekt_Implementationsdo SW12 Digital gat Alle kumentation.doc SW13 SWK_Projekt_Präsentation.ppt SW14 Nur Vortragen ste Alle Tabelle 8: Liste der Dokumente, welche im Rahmen des Projekts entstehen gam gam Alle Alle TA.SWK.F1001 Projekt Message-Logger Team / 14

14 Projektplan Projektabschluss Hochschule Luzern 7 Projektabschluss 7.1 Lessions Learned In der vorletzten Woche haben wir herausgefunden, dass wir das Loggen über CORBA nicht so implementiert haben, wie es von den Dozenten vorgesehen war. Die Ursache lag darin, dass wir die Aufgabenstellung falsch interpretiert haben. Anstatt eine weitere Komponente zu erstellen, die über CORBA mit dem Logger-Server kommuniziert, haben wir direkt von der Test-Applikation auf den Server geloggt. Das funktioniert zwar sehr gut war aber nicht so vorgesehen gemäss Aufgabenstellung. Wir können uns erinnern, dass während der Diskussion für Release 2 (=CORBA Implementation) über die Variante "direkt zum Server loggen" gesprochen wurde. Gemeint war damit jedoch der direkte Zugriff zum Testen des Servers und nicht der direkte Zugriff von der Applikation. Natürlich hätte uns dieser Fehler auffallen müssen. Da CORBA zu diesem Zeitpunkt jedoch für uns sehr neu war und es ein komplexes System ist, waren wir mit dem Verständnis dieses Systems schon genügend beschäftigt. Die neue CORBA-Komponente hätte das in Iteration #1 definierte ILogger Interface verwenden müssen. Da die CORBA-Implementation einige zusätzliche Attribute benötigt, müssten diese aus einer eigens dafür vorgesehenen Konfigurationsdatei herausgelesen werden. Diese Attributnamen hätten im Interface-Team definiert werden können, sodass auch die CORBA-Komponente via Test-Applikation hätte konfiguriert werden können. In einem weiteren Refactoring könnte dies natürlich wunschgemäss umgesetzt werden. 7.2 Freigabeprotokoll Die hier dokumentierte Durchführung des Projekts und das Ergebnis erfüllen die Erwartungen des Auftraggebers vollumfänglich. Das dokumentierte Ergebnis gilt mit Unterzeichnung als abgenommen. Projektübergabe am 27. Mai 2010 in Horw. Jud Martin Auftraggeber Gisler Roland Projektbetreuer Sollberger Peter Projektbetreuer Galliker Thomas Gasser Martin Stocker Elias TA.SWK.F1001 Projekt Message-Logger Team / 14