Hochschule für Technik und Architektur Biel Für Projekt Polyphemus II Dateiname: Revisionsstatus: Autor:.doc Genehmigt Roger Briggen Matthias Germann
Änderungskontrolle Version Datum Name Bemerkungen 1 23.04.2002 Matthias Germann Erstellung Roger Briggen 2 06.05.2002 Matthias Germann Roger Briggen - Referenzierte Dokumente ergänzt - Konzeptdokumente angepasst - Abschnitt QS überarbeitet 3 06.05.2002 Roger Briggen Genehmigt durch Hr. Schwab Juli 2002 Seite 2 / 13
Inhaltsverzeichnis 1 EINLEITUNG...5 1.1 Zweck des Dokumentes... 5 1.2 Referenzierte Dokumente... 5 2 PROJEKTBESCHREIBUNG...6 2.1 Ausgangssituation... 6 2.2 Ziele... 8 2.3 Liefergegenstand... 8 2.4 Vorgehensstrategie... 8 3 PROJEKTSPEZIFISCHES VORGEHENSMODELL...9 3.1 Phase Initialisierung... 9 3.2 Phase Voranalyse... 9 3.3 Phase Konzept... 9 4 ENTSCHEIDUNGSPUNKTE UND AUSZULIEFERNDE ERGEBNISSE...10 4.1 Phase Initialisierung... 10 4.2 Phase Voranalyse... 10 4.3 Phase Konzept... 10 5 METHODEN UND WERKZEUGE...11 6 STANDARDS UND RICHTLINIEN...12 6.1 Dokumentation... 12 Juli 2002 Seite 3 / 13
6.2 Vorlagen... 12 7 ANHANG: ERGÄNZENDE PROJEKT-VEREINBARUNGEN...13 7.1 Projektorganisation... 13 7.2 Qualitätssicherung... 13 7.3 Konfigurationsmanagement... 13 Juli 2002 Seite 4 / 13
1 Einleitung 1.1 Zweck des Dokumentes Das dient als einheitliche Handlungsgrundlage für alle Projektbeteiligten und legt damit den allgemeingültigen technischen und organisatorischen Rahmen fest. Das ist soweit wie möglich als statisches Dokument zu führen. Es ist jedoch zu Beginn und am Schluss jeder Phase zu überprüfen und an die neuen Erkenntnisse anzupassen. Änderungen im müssen durch den Projekt-Auftraggeber genehmigt werden. 1.2 Referenzierte Dokumente HERMES, Ausgabe 95 Diplomarbeit Polyphemus 1 von Cedric Bösiger und Patrik Schilt Projektantrag Polyphemus II 1 http://www.hta-bi.bfh.ch/projects/polyphem/ Juli 2002 Seite 5 / 13
2 Projektbeschreibung Entwicklung eines Konzepts für einen mobilen Agent für das Türüberwachungssystem Polyphemus. 2.1 Ausgangssituation Polyphemus ist ein computerunterstützes System für die Kontrolle einer Tür, welches als Semester- und Diplomarbeit an der HTA Biel von Cedric Bösiger und Patrik Schilt im Jahre 2000 entstand. Dieses System ist nach dem Manager/Agent Prinzip aufgebaut: Ein Manager und ein Agent sind an ein TCP-IP Netzwerk angeschlossene Computer. Der Manager läuft auf einem Desktop PC unter Java und stellt das Benutzer-Interface zur Verfügung. Der Agent läuft schlussendlich auf einem Industrie PC unter einem embedded Betriebssystem. Grundsätzlich gibt es im Polyphemus System mehrere Agenten und mehrere Manager. Polyphemus unterstützt die folgenden peripheren Geräte: Eine steuerbare Kamera erlaubt die Erfassung von Video, ein Mikrophon und Lautsprecher erlauben einen half-duplex oder full-duplex Dialog zwischen dem Benutzer an der Managerstation und einer Person an der Türe. Half-duplex bedeutet hier, dass zu einem Zeitpunkt nur eine der Personen spricht, und die andere zuhört. Ein Distanzsensor signalisiert Aktivität, beispielsweise, wenn sich eine Person der Tür nähert. Der Agent steuert auch das Türschloss, die Hausglocke und die Türbeleuchtung. Juli 2002 Seite 6 / 13
Der Manager von Polyphemus I funktioniert nur auf einem Desktop PC. Der Anwender von Polyphemus II sollte aber auch den Arbeitsplatz verlassen und die Türe über einen mobilen Manager weiterhin überwachen können. Juli 2002 Seite 7 / 13
2.2 Ziele Das Ziel ist es, einen Prototyp für die Erweiterung von Polyphemus I um einen mobilen Manager zu entwickeln und damit die Grundlagen für unsere Diplomarbeit zu erarbeiten. Ziel-Nr. Beschreibung 1 Evaluation der zu verwendenden Technologien 2 Evaluation der zu verwendenden Endgeräte 3 Prototyp für den mobilen Manager 4 Prototyp für die Erweiterung des Agents 2.3 Liefergegenstand Ein Prototyp für die Basisfunktionen von Polyphemus II und ein Konzept für die Realisierung als Diplomarbeit. 2.4 Vorgehensstrategie Polyphemus II ist ein Projekt mit hohem Risiko. Deshalb verwenden wir das Inkrementalmodell. Dadurch können wir schnell überprüfen, ob die von uns gewählten Lösungen funktionieren und dem Projektauftraggeber Resultate zeigen. Entscheidungen für die Verwendung von Technologien werden aufgrund unserer Evaluationen der verschiedenen Lösungen in Bezug auf die Verwendbarkeit für unser Projekt getroffen. Juli 2002 Seite 8 / 13
3 Projektspezifisches Vorgehensmodell 3.1 Phase Initialisierung Hauptaktivität Ergebnis Erstellen Bemerkung / Begründung Projekt vorbereiten Projektantrag 3.2 Phase Voranalyse Hauptaktivität Ergebnis Erstellen Bemerkung / Begründung Phase initialisieren QS-Plan nein Als Anhang im KM-Plan nein Als Anhang im Ziele definieren Situationsanalyse Systemziele nein Lösungen suchen Systemanforderungen Marktanalyse nein Forschungsprojekt Wirtschaftlichkeit nein Forschungsprojekt Lösungsvorschläge Berichte über Technologieevaluationen Phase abschliessen QS-Plan nein Als Anhang im KM-Plan nein Als Anhang im Bericht Voranalyse 3.3 Phase Konzept Hauptaktivität Ergebnis Erstellen Bemerkung / Begründung Phase initialisieren QS-Plan nein Als Anhang im KM-Plan nein Als Anhang im Konzept entwickeln Systemanforderungen Systemarchitektur nein In der Detailstudie enthalten Systemintegrationsplan nein In der Systemarchitektur enthalten Fertigprodukte nein In der Systemarchitektur enthalten Sachmittelbedarf nein In der Systemarchitektur enthalten Einführungskonzept nein Forschungsprojekt Wirtschaftlichkeit nein Forschungsprojekt Fertigprodukte und Fertigproduktevaluation nein Bereits in der Voranalyse Sachmittel evaluieren Sachmittelevaluation nein Bereits in der Voranalyse Kritische Teilsysteme Detailstudie untersuchen Prototyp Phase abschliessen QS-Plan nein Als Anhang im KM-Plan nein Als Anhang im Bericht Konzept Schlussbericht Juli 2002 Seite 9 / 13
4 Entscheidungspunkte und auszuliefernde Ergebnisse 4.1 Phase Initialisierung Entscheidungspunkt Entscheid Bemerkung / Begründung Ergebnisse Prüfung treffen Projektauftrag Review Projektantrag Abschluss Phase Initialisierung nein Der Phasenabschluss wird mit dem Entscheidungspunkt "Projektauftrag" abgedeckt. keine 4.2 Phase Voranalyse Entscheidungspunkt Entscheid Bemerkung / Begründung Ergebnisse Prüfung treffen Zielvereinbarung Situationsanalyse Review Lösungsauswahl Systemanforderungen Review Lösungsvorschläge Freigabe Phase Konzept Bericht Voranalyse Review 4.3 Phase Konzept Entscheidungspunkt Entscheid Bemerkung / Begründung Ergebnisse Prüfung treffen Konzept Systemanforderungen Review Systemarchitektur Detailstudie Prototyp Freigabe Phase Realisierung Bericht Konzept Review Juli 2002 Seite 10 / 13
5 Methoden und Werkzeuge Aktivität Methode Werkzeug Planen Balkendiagramme MS-Project Rapportieren Stundenmeldung MS-Excel Dokumente Text MS-Word Projektablage organisieren Ablage aller Projektdokumente in einem CVS Dokumentation Java-Code Kommentare Javadoc CVS :pserver:<username>@cvs.htabi.bfh.ch:/var/cvsreps/projects Juli 2002 Seite 11 / 13
6 Standards und Richtlinien 6.1 Dokumentation Für die Dokumentation des Java-Codes werden Javadoc-Kommentare 2 verwendet. 6.2 Vorlagen Folgende Vorlagen aus dem CVS sind zu verwenden: Word-Dokument (vorlage.doc) HTML Seite (vorlage.htm) Java-Source Datei (vorlage.va) 2 http://va.sun.com/j2se/vadoc/writingdoccomments/index.html Juli 2002 Seite 12 / 13
7 Anhang: Ergänzende Projekt-Vereinbarungen 7.1 Projektorganisation Projektauftraggeber: Dr. Franz Meyer Projektcoach: Gerhard Schwab Projektauftragnehmer: Roger Briggen Matthias Germann Projektleiter: Matthias Germann 7.2 Qualitätssicherung Die Projektführungsdokumente werden von Dr. Franz Meyer und Gerhard Schwab kontrolliert. Die technischen Dokumente werden von Dr. Franz Meyer kontrolliert. Technische Prototypen werden vom jeweiligen Programmierer getestet. Allfällige GUI-Prototypen werden von beiden Programmierern getestet. 7.3 Konfigurationsmanagement Für das Konfigurationsmanagement wird das CVS der HTA Biel verwendet. Juli 2002 Seite 13 / 13