Projektauftrag (PA)

Dieser Abschnitt beinhaltet den Projektauftrag (PA) für das Software Engineering Anmelde-Tool (SAT) in der Medium-Ausbaustufe. Der Projektauftrag (PA) basiert auf dem Projektvorschlag (PV).

Der PA umschreibt konkrete Anforderungen sowie Artefakte des Projektmanagement, die zusammen die Grundlage für eine Vereinbarung mit dem Kunden bilden.

Ausgangssituation

Siehe Ausgangssituation vom Projektvorschlag

Projektbeschreibung

Siehe Projektbeschreibung vom Projektvorschlag

Zielgruppen

Siehe Zielgruppen vom Projektvorschlag

Zusätzlich zu den beschriebenen Zielgruppen, wurde eine UML Aktorenhierarchie erstellt, auf die sich die Iceberglist (erweiterte Featureliste) im folgenden Abschnitt bezieht.

AktorRechte im SystemAnmerkungen
StudentStudenten können ihre eigenen Anmeldedaten verwalten, sich zu Abgabegesprächen anmelden und Gruppenwünsche bekanntgeben.Verwaltung der Anmeldedaten umfasst auch die Abgabe einer Instituts- bzw. Übungspräferenz und optionales ausfüllen eines Fragebogens.
TutorKann die Anmeldedaten von Studenten einsehen und ändern sowie Bewertungen der Studenten durchführen.Nur Tutoren dürfen Studenten bewerten
AdminUneingeschränkten Zugriff auf den Datenbestand. Eingeschränkter Zugriff auf Services vom System. Administratoren müssen nach erfolgreicher Bewertung, die Studenten zu Gruppen zusammenstellen und ihnen Tutoren zuteilen.Nur Administratoren können neue LVA's, Termine und Bewertungs-/Fragebögen verwalten. Administratoren können aber nicht bewerten, nur Tutoren haben die Rechte zum bewerten.

Funktionale Anforderungen, Anwendungsfälle

Siehe Feature-Liste vom Projektvorschlag (PV) für eine Beschreibung der Features.

Anwendungsfall Übersicht

Die Features aus dem Projektvorschlag (PV) wurden zu folgenden Anwendungsfall-Paketen zusammengefasst. Aufgrund der Anforderungsvielfalt dieses Projektauftrags ist eine Priorisierung (Hoch, Mittel, Niedrig) der einzelnen Pakete zweckmäßig.

  1. Registrierung (H): Unbedingt erforderlich, kritisch
  2. Fragebogen (M): nur Grundfunktionalität notwendig (Institutspräferenz)
  3. Terminverwaltung (M): nur Grundfunktionalität notwendig (Abgabegespräch)
  4. Gruppenbildung, Student (M): nur Grundfunktionalität notwendig (erstellen/beitreten/abmelden)
  5. (Studenten-) Bewertung (H): Unbedingt erforderlich, kritisch
  6. Gruppenverwaltung, Admin (N): Erweiternde Features, können auch nach dem Projekt implementiert werden
  7. LVA Verwaltung (H): Unbedingt erforderlich, kritisch

Iceberglist

Der wesentliche Unterschied zur Feature-Liste aus dem Projektvorschlag (PV), besteht in der Verfeinerung der Features zu Anwendungsfällen (Use Cases) und die Spalten "Version" und "Zuständiger", die zusätzlich Projektplanung ins Spiel bringen.

 
Id
 
Feature, Aktor
 
Anwendungsfälle
Kunden- 
Priorität
Auf- 
wand
Ver- 
sion
Zustän- 
diger
1.1Registrierung, AnonymAccount anlegenH31mdemolky
1.2Registrierung, Student/TutorAccount-Daten ändernH11mdemolky
1.4Registrierung, AdminStudent/Tutor suchenH11mdemolky
1.6Registrierung, AdminStudent/Tutor Daten einsehenH31mdemolky
1.10Registrierung, AdminStudent/Tutor Passwort ändern (mit Benachrichtigen)H41mdemolky
3.1Terminverwaltung, Studentzu Termin anmeldenH41sbi
3.2Terminverwaltung, Studentvon Termin abmeldenH21sbi
3.3Terminverwaltung, Admin(Serien) Termin erstellenH51sbi
1.3Registrierung, Student, Tutorneues Passwort anfordernH21mdemolky
1.7Registrierung, AdminAccount löschenH21mdemolky
1.8Registrierung, AdminAccount-Daten ändernH11mdemolky
1.9Registrierung, AdminTutor account anlegenH31mdemolky
5.1Bewertung, TutorStudent suchenM41aschatt
7.1LVA-Verwaltung, Studentzu LVA anmeldenH41aschatt
7.1LVA-Verwaltung, Studentvon LVA abmeldenH21aschatt
7.2LVA-Verwaltung, AdminLVA erstellenH51aschatt
7.3LVA-Verwaltung, AdminLVA bearbeitenM41aschatt
7.4LVA-Verwaltung, AdminLVA löschenN31aschatt
7.7LVA-Verwaltung, AdminTestpunkte importierenH11aschatt
5.3.1Bewertung, AdminBewertungsbogen erstellenH51erikgf
5.3.2Bewertung, AdminBewertungsbogen ändernH41erikgf
4.1Gruppenbildung, StudentGruppe erstellenH42sbi
4.2Gruppenbildung, StudentGruppe ansehenM32sbi
4.2Gruppenbildung, StudentGruppenbeschreibung editierenN82sbi
2.2Fragebogen, AdminFragebogen erstellenM82sbi
3.4Terminverwaltung, AdminAnmeldungen einsehenH42sbi
4.2Gruppenbildung, Studentzu Gruppe anmeldenH22sbi
4.2Gruppenbildung, Studentvon Gruppe abmeldenM22sbi
5.2Bewertung, TutorBewertung eintragen (bewerten)H82aschatt
5.2.1Bewertung, TutorTestpunkte eintragenH22aschatt
5.2.2Bewertung, TutorLive-Beispiel eintragenH22aschatt
5.2.3Bewertung, TutorEinzelbeispiel eintragenH22aschatt
5.2.4Bewertung, TutorEinschätzung und Kommentar eintragenH22aschatt
5.3.3Bewertung, AdminBewertungsbogen löschenH22erikgf
5.3.4Bewertung, AdminBewertungsbogen übernehmenH32erikgf
6.1Gruppenverwaltung, TutorGruppe ansehenM43mdemolsky
6.2Gruppenverwaltung, AdminGruppengröße definierenH13mdemolsky
6.4Gruppenverwaltung, AdminStudent zu Gruppe zuweisenM23mdemolsky
2.1Fragebogen, StudentFragebogen ausfüllenH43sbi
7.2.1LVA-Verwaltung, AdminLVA Daten übernehmenH33aschatt
5.3Bewertung, AdminBewertungsbögen verwaltenH83erikgf
2.2Fragebogen, AdminFragebogen veröffentlichenM33sbi
2.2Fragebogen, AdminFragebogen schliessenM23sbi
5.4Bewertung, AdminTutor zur Bewertung (für einen Termin) freischaltenH53mdemolsky
6.3Gruppenverwaltung, AdminGruppenbildung freischaltenN24mdemolsky
6.5Gruppenverwaltung, AdminTutor zu Gruppe zuweisenM24mdemolsky
6.6Gruppenverwaltung, AdminStudent aus Gruppe entfernenH14mdemolsky
7.5LVA-Verwaltung, AdminLVA Daten exportierenM24aschatt
6.7Gruppenverwaltung, AdminGruppen zusammenlegen (optionale Konstruktionsheuristik)M94erikgf
2.2Fragebogen, AdminFragebogen auswertenM64sbi
6.5Gruppenverwaltung, AdminAssistent zu Gruppe zuweisenN24mdemolsky
6.8Gruppenverwaltung, AdminGruppenzusammenlegung Rückgängig machenN44erikgf
6.9Gruppenverwaltung, AdminGruppenkonfiguration zurücksetzenM44erikgf
7.6LVA-Verwaltung, AdminGruppenkonfiguration exportierenH24aschatt
7.6.1LVA-Verwaltung, AdminXLS exportieren (für GoogleDocs)H34aschatt
7.6.2LVA-Verwaltung, AdminSCM, Tracker, Mailingliste exportierenH84erikgf

Domänenmodell

Siehe Domänenmodell vom Projektvorschlag

Arbeitsstruktur & Grober Projektplan

Das Projektteam besteht aus 4 Entwicklern, die Expertenrollen (und damit verbundene Horizontale Verantwortlichkeiten) wurden bereits im Projektvorschlag definiert. Es wurde entschieden eine Kombination aus dem Rational Unified Process (RUP) und SCRUM zu anzuwenden: Zu Projektbeginn hat RUP mehr Einfluss (Anforderungen, Expertenwissen/Rollen), während in der Construction Phase von RUP hauptsächlich SCRUM eingesetzt werden soll.

Rollenverteilung

Siehe Projektbezeichnung und Entwicklerteam vom Projektvorschlag.

Aufgrund dieser Expertenrollen muss die Projekt- (SCM, Tracker) und Produktinfrastruktur (Maven) aufgebaut werden. Auch das verfassen von Artefakten bzw. Dokumentation unterliegt bestimmten Experten (siehe Grober Projektplan), jedoch reviewen und beitragen muss jeder.

Horizontale Verantwortlichkeiten

Technische Architekten: aschatt & mdemolsky

Technische Architekten verwalten die Programm Infrastruktur des Projekts, z.B. Ordnerstruktur und Abhängige JAR Bibliotheken der Software (Dependencies). Zum Expertenwissen der Technischen Architekten zählen eindeutig sehr gute Kenntnisse der verwendeten Programmiersprachen, Toolkits und Frameworks, sowie Architekturelles Design und Software Patterns. Spezifische Horizontale Verantwortlichkeiten für dieses Projekt sind:

  • Projekt Objekt Model (Maven pom.xml)
    • Dependency Management, vor allem Versionen
    • Plugins, z.B. JTidy
    • verwendete externe Maven Repositories
  • Expertenwissen zu allen verwendeten Technologien der Technischen Entwicklung, z.B. Eclipse, Maven.
  • Erstellung von Kodierungs-Richtlinien (Checkstyle).
  • Erstellung von Richtlinien zur Sourcecode-Dokumentation (Javadoc).
  • Verwaltung aller Enhancement-Tickets im Tracker
  • Design der Programmarchitektur und -komponenten
Team Koordinator: sbi

Team Koordinatoren müssen gute Projektmanagement Kenntnisse haben und sind für die Aktualität der Artefakte des laufenden Projektmanagement (z.B. Projektplan) verantwortlich.

  • Organisation und Planung (laufende Dokumentation)
  • Controlling & Tracking
    • Stundenlisten, Organisatorische-Tickets vom Tracker
    • Statuserhebung für den Statusbericht (Reviews), siehe Lieferkomponenten
  • Kontrolle der Aufgabenverteilung (Arbeit/Developer), siehe Grober Projektplan und Iceberglist
  • Primärer Ansprechpartner für die Auftraggeber
  • Organisation interner und externer Meetings
Dokumentationsbeauftragte: erikgf & aschatt
  • Verfügbarkeit der Dokumentation, z.B. über Mercurial und Maven site.
  • Java API Dokumentation integrieren mit dem Maven Javadoc Plugin
    • Jede Java-Package muss dokumentiert werden. Eine package-info.java Datei muss für jedes Java-Package erstellt werden.
  • Sicherstellen, dass alle Klassen, Variablen und Methoden in English dokumentiert werden
  • Erstellung von Dokumentationsrichtlinien (Format- und Formatierungsrichtlinien, Spezifikation der Code Conventions, Erstellung von Vorlagen, ...)
  • Überprüfung der Einhaltung von Dokumentationsrichtlinien
  • Überprüfung der Vollständigkeit von Dokumenten
  • Organisation und Archivierung der Dokumente im SCM
Testbeauftragte: mdemolsky & sbi
  • Test Infrastruktur
    • Test Bibliotheken, Testdaten (zweite DB).
    • Test Suites: Integration mit Spring Framework um Testdaten zu managen.
    • Sicherstellen, dass Testcode von Produktionscode getrennt wird.
  • Erstellung des Testplans
    • Testvorgehensweise (Codegerüst), Planung von Test-Runs
    • Auswirkungen bei Fehlern, WeitergabeVerhalten bei Fehlern (Exceptionhandling)
    • siehe Meilenstein 2 in den Lieferkomponenten
      • Überprüfung der Einhaltung von Testrichtlinien
  • Verwaltung aller Trouble-Tickets im Tracker
  • Überwachung von Integrations- und Systemtests (starke Zusammenarbeit mit dem Technischen Architekten)
  • Regelmäßige Überprüfung aller Unit-Tests
Build/Release Manager: erikgf
  • Development Environment Infrastruktur
    • Scripts zum initialisieren, testen oder verteilen (deploy)
    • Tagging im SCM für jeden Meilenstein, siehe Iceberglist und Lieferkomponenten
    • Build, Deploy Targets von Maven; "Projekt kann jederzeit ausgecheckt und kompiliert werden"
  • Expertenwissen über die Build und SCM Werkzeuge (Maven & Mercurial)

Grober Projektplan

Artefakte, die aus dem Projektauftrag entstehen und werkzeugunterstützt oder als eigenständige Artefakte weitergeführt werden, wurden bereits in der Work Breakdown Structure eingeplant. Die Verteilung basiert auf den Rollen und Horizontalen Verantwortungen.

Work Breakdown Structure (WBS)

Die WBS wurde auf Meilenstein-Ebene entworfen und es wurden die ersten Arbeitspakete aufgrund der Horizontalen Verantwortungen berücksichtigt. Die technischen Arbeitspakete der Iceberglist werden in der WBS in diesem Projekt nur auf Meilensteinebene berücksichtigt - wir wir technisch nach SCRUM vorgehen. Das heisst es werden hier nur "nicht-technische" Arbeitspakete (Dokumentation, Konfiguration, etc.) eingetragen.

 
Nr.
 
Arbeitspakete
 
Anfang
 
Ende
Personen- 
tage
Verant- wortlich
MS.0Kick-Off01.10.200902.10.20091
1.1Anforderungs-Analyse02.10.200904.11.200923
1.1.1          Feature-Liste verfeinern: Iceberglist05.10.200913.10.20098mdemolsky
1.1.2          Ausgangssituation & Projektbeschreibung (vom PV) verfeinern06.10.200910.10.20094erikgf
1.1.3          Zielgruppen verfeinern, Aktorenhierarchie erstellen10.10.200913.10.20093aschatt
1.1.4          Anwendungsfälle: User Story zu den 5 wichtigsten (Kundenpriorität)10.10.200913.10.20093sbi
1.1.5          Projektplan erstellen03.10.200913.10.200910erikgf
MS.1Projektdefinition, Projektauftrag13.10.200914.10.20091
MR-1Management Review 1 (Anforderungs-Review)15.10.200916.10.20091
1.2Anforderungs-Analyse fertigstellen05.11.200911.11.20095
1.2.1          Anwendungsfall-Beschreibung: alle UCs mit User Story05.11.200911.11.20095sbi
1.2.2          Nichtfunktionale Anforderungen in die UCs einarbeiten05.11.200907.11.20092sbi
1.2.3          Projektplan verfeinern, Arbeitspaket-Ebene07.11.200911.11.20093erikgf
2.1Entwurf und Design19.10.200904.11.200913
2.1.1          Domänenmodell abschliessen, im SCM einchecken19.10.200920.10.20091mdemolsky
2.1.1          Komponentendiagramm aktualisieren, im SCM einchecken19.10.200920.10.20091aschatt
3.0Implementierung Sprint 115.10.20091.11.200916
3.0.1          DB Schema & Testdaten15.10.20091.11.200916mdemolsky
3.0.2          Persistenz-Schicht, DAOs, Model Klassen15.10.20091.11.200916aschatt
3.0.3          Service Schicht & erstes GUI Panel15.10.20091.11.200916sbi
3.0.4          SCM, Tracker Konfiguration15.10.20091.11.200916erikgf
3.0.5          Produkt Dokumentation, maven site15.10.20091.11.200916erikgf
3.0.6          Maven Konfiguration (pom.xml)15.10.20091.11.200916aschatt
3.0.7          Tests der Persistenz-Schicht (DAOs), Test-Suites15.10.20091.11.200916mdemolsky
MS.2Erster Systemtest (Hello World)01.11.20092.11.20091
IR-1Internes Review 1 (Anforderungs Review), Pre-Release Demo04.11.20095.11.20091
2.2Entwurf und Design fertigstellen05.11.200904.12.200921
3.1Implementierung Sprint 2 bis Version 2, siehe Iceberglist06.11.200910.12.200924
MS.3GUI Prototyp mit DAO Tests, 40% der User Stories implementiert07.12.20098.12.20091
MR-2Management Review 2 (Design Review), Alpha Release Demo10.12.200911.12.20091
3.2Implementierung Sprint 3 bis Version 3, siehe Iceberglist11.12.200912.01.201022
MS.470% der User Stories implementiert, Service-Schicht Tests09.01.200910.01.20101
IR-2Internes Review (Code Inspektion), Beta Version Demo12.01.200913.01.20101
3.3Implementierung Sprint 4 bis Version 5, siehe Iceberglist13.01.201028.01.201011
MS.5100% der User Stories implementiert, Akzeptanztests25.01.201026.01.20101
MR-3Management Review 3: Projektabnahme, General Availability (GA) Version Demo28.01.201029.01.20101
Meilensteinbeschreibung
  1. Projektauftrag :)
  2. Erster Systemtest (Hello World)

    Zu diesem Zeitpunkt soll ein erster Prototyp der Applikation vorhanden sein, d.h. alle Schichten der Architektur sollen miteinander verbunden werden und ein erster Systemtest, mit der GUI und echter Datenbankverbindung, durchgeführt werden.

    Dieser Meilenstein könnte auch als sog. "pre-release" betrachtet werden, d.h. sie Software läuft, aber es gibt keine wirkliche Funktionalität ausser getestete CRUD Methoden.

  3. GUI Prototyp mit DAO Tests, 40% der User Stories implementiert

    Dieser Meilenstein stellt die erste benutzbare Version (Alpha-Version) der Software dar. 40% der User Stories bedeutet alle Use Cases der Iceberglist, die der Version 1 zugeordnet sind.

    Zusätzlich, soll die Persistenz-Schicht schon relativ weit (70%-80%) fortgeschritten sein und es müssen Integrationstests für die Data Access Objects (DAOs) vorliegen.

  4. 70% der User Stories implementiert, Service-Schicht Tests

    Die Beta Version der Software, d.h. das Softwareprodukt soll so weit fortgeschritten sein, dass es entweder online zum download/test angeboten werden kann oder z.B. bereits beim Kunden installiert werden kann. 70% der User Stories bedeutet bis zur Version 3 der Iceberglist.

    Zu diesem Zeitpunkt soll auch die Service-Schicht vollständig getestet sein, da wir sonst mit Meilenstein 5 in Verzug geraten.

  5. 100% der User Stories implementiert, Akzeptanztests

    Alle Use Cases der Iceberglist sollen abgearbeitet sein und klarerweise müssen die Akzeptanztests funktionieren um das Produkt beim Kunden vorzuzeigen.

Alle Meilensteine, enthalten auch andere, non-source-code Artefakte , siehe Lieferkomponenten für eine vollständige Beschreibung des Lieferumfangs.

Projektabgrenzungen

Bei dem Projekt muss eine sinnvolle Erweiterbarkeit gegeben sein, in diesem Teil wird aber vor allem auf die stabile Umsetzung der oben angeführten Anforderungen geachtet.

Folgende Features werden von bestehenden Werkzeugen unterstützt und sollen nicht von SAT abgelöst werden:

  • Forum für Diskussionen zum Einzelbeispiel der Eingangsphase
  • Mailinglisten, SCM & Tracker für die Studentengruppen der Gruppenphase
  • Verteilung von Dokumentation (Foliensätze, Infoblätter, Abgaben)

Folgende Funktionen oder Arbeitspakete liegen nicht im Umfang vom SAT Projekt und werden auch nicht vom Entwicklerteam verarbeitet:

  • Konvertierung von bestehenden Datenbeständen
  • Produktivstellung der SAT Software auf einem Institutsinternen Webserver.
  • Die Schnittstellen zu externen Systemen funktionieren über manuellen Import/Export von Dateien, dies muss von den Zuständigen Betreuern übernommen werden

Schichtendiagramm

Siehe Architektur und verwendete Werkzeuge. Das Schichtendiagramm soll in weiterer Folge zu einem UML Komponentendiagramm verfeinert werden (+Interfacespezifikationen).

Lieferkomponenten

Während der Projektlaufzeit und vor allem beim Abschluss des Projektes wird dem Kunden die erstellte Software sowie dazugehörige Dokumentation übergeben. In diesem Abschnitt werden die Softwarekomponenten und Dokumentation beschrieben und eine Abgrenzung des Lieferumfangs durchgeführt.

Software

Nach Projektabschluss werden dem Kunden folgende Kernkomponenten der Software in Produktionsfähigen Zustand übergeben:

  • Apache Wicket Webapplikation (WAR File)
  • Hyper SQL Datenbank mit Datenbankskripts zur Inbetriebnahme der Applikation (Initialisierung)
  • Konfigurationsdaten für Datenbanken und Server, soweit für Wartung und Weiterentwicklung notwendig
  • Konstruktionsheuristik für die Gruppenbildung
  • Schnittstelle zu den Werkzeugen der Gruppenphase (Export der Gruppenkonfiguration)

Artefakte & Projektdokumentation

  • Domänenmodell & Komponentendigramm
  • Funktionale Anforderungen
    • Anwendungsfallbeschreibung
    • Anwendungsfalldiagramme, Pakete & Aktorenhierarchie
  • Benutzerhandbuch in Form einer Onlinehilfe
  • UML Verteilungsdiagramm (Deployment Diagramm)
  • Testplan, Funktionale Testfälle, Testberichte (soweit für die Wartung und Weiterentwicklung notwendig)
  • Datenbankbeschreibung & ER Diagramm
  • Präsentationen zu den Reviews (MRs)

Meilensteine

Meilenstein 2: Erster Systemtest (Hello World)
  • Artefakte des Laufenden Projektmanagement (Besprechungsprotokolle, Stundenlisten, Risikoabschätzung, Iceberglist, Projektstrukturplan (Work Breakdown Structure auf Arbeitspaketebene))
  • IR-1 Statusbericht
  • Funktionale Anforderungen (Übersicht über alle Anwendungsfälle, Beschreibung der Anwendungsfälle, Anwendungsfalldiagramme, AkteurInnenliste, AkteurInnenhierarchie)
  • Komponentendiagramm
  • UI-Skizze und Beschreibung
  • Deployment Diagramm
  • „Hello World“ Prototyp mit GUI: erster Systemtest
  • Testartefakte (Testplan)
  • Datenbankbeschreibung (ER-Diagramm, Beschreibung der Attribute)
Meilenstein 3: GUI Prototyp mit DAO Tests, 40% der User Stories implementiert
  • Artefakte des Laufenden Projektmanagement + MR-2 Statusbericht mit Präsentation
  • Anwendungsfallbeschreibung überarbeitet und abgeschlossen
  • Testplan abgeschlossen
  • Datenbankbeschreibung abgeschlossen
  • „Alpha Version“: Prototyp mit DAO Tests und 40% der Funktionalen Anforderungen (User Stories) Implementiert
  • UI Skizzen/Design abgeschlossen
  • Deploymentdiagramm, Komponentendiagramm überarbeitet und abgeschlossen
  • Testartefakte (Funktionale Testfälle / Akzeptanztests)
Meilenstein 4: 70% der User Stories implementiert, Service-Schicht Tests
  • Artefakte des Laufenden Projektmanagement + IR-2 Statusbericht
  • „Beta Version“: 70% der User Stories implementiert mit Service-Schicht Tests
Meilenstein 5: 100% der User Stories implementiert, Akzeptanztests
  • Artefakte des Laufenden Projektmanagement + MR-3 Statusbericht mit Präsentation
  • Testberichte abgeschlossen
  • „General Availability Version“: funktionierendes Produkt

Abgrenzung des Lieferumfangs

Nicht im Lieferumfang des End-Produkts (MS.5/MR-3) enthalten, sind:

  • Projektstrukturplan (GANTT)
  • Iceberglist, Burn-Down Charts
  • Artefakte des laufenden Projektmanagement (Besprechungsprotokolle, Stundenlisten, Risikoanalyse)
  • UI Skizzen

Nichtfunktionale Anforderungen

  • Verfügbarkeit - Die Anwendung muss Haupt-Anwendungszeiten, als v.a. zu Beginn des Semesters stabil laufen und mehrere hundert Anfragen parallel bedienen können.
  • Wiederherstellung - Die Daten müssen bei einem Ausfall des Systems wieder komplett hergestellt werden können.
  • Browser-Konformität - Die Oberfläche muss zumindest auf den am häufigsten genutzten Browsern getestet und ausreichend benutzbar sein um die Features fehlerfrei zu nutzen.
  • Benutzerfreundlichkeit - Vordergründige Aufgabe ist es die vorhandenen brauchbaren Features (wie z.B. Serientermin erstellen) zu erhalten und die Dialoge der Webapplikation deutlich zu verbessern. Es sollen neben einer klar gegliederten grafischen Benutzeroberfläche eine einheitliche Struktur geschaffen werden, welche sich durch die gesamte Applikation zieht.
  • Feedback - Sowohl Benutzer- als auch Entwicklerseitig soll ein sinnvolles Fehlerfeedback genutzt werden, um die Ursachen schnell und unkompliziert lösen zu können.
  • Wartbarkeit - Die Anwendung soll so umgesetzt werden, dass eine spätere Wartung möglichst einfach ausfällt. Dazu gehören aussagekräftige Kommentare des Programmcodes und ein sauberer Programmierstil.
  • Datensicherheit - Die Daten (z.B. Noten) der einzelnen Benutzer (Akteure) dürfen nur von den dafür vorgesehenen Tutoren und Administratoren eingesehen werden können.
  • Skalierbarkeit - Eine grundsätzliche Skalierbarkeit ist sinnvoll. Es wird aber nicht damit gerechnet, dass die Anwendung in Umgebungen benutzt wird, die eine volle Skalierbarkeit benötigt.

Risikoabschätzung

Im folgenden sind Risiken gelistet, die während der Projektlaufzeit eintreten können. Zusätzlich sind mögliche Gegenmaßnahmen zu den einzelnen Risiken beschrieben. Die Gegenmaßnahmen, die bei eintreten eines Risikos gewählt werden, hängen jedoch immer von der konkreten Situation ab.

 
 
Nr.
 
 
Typ
 
Priori 
-tät
Eintritts- 
wahrschein- 
lichkeit
 
Folge- risiken
Ver- 
ant- 
wortliche
 
Name &  
Beschreibung
 
 
Gegenmaßnahmen
1immerhochmittel2, 3sbiAusfall eines Projektmitglieds: Ein Projektmitglied kann, zB bedingt duch eine Krankheit, längere Zeit nicht am Projekt mitarbeiten bzw scheidet komplett aus dem Projektteam aus.Sammeln der bereits geleisteten und noch ausständigen Arbeit; Besprechung und Aufteilung der Aufgaben innerhalb der Gruppe (zusätzlich zum Jour-Fixe, kann auch elektronisch stattfinden). Zuteilung der Rolle zu einem anderen Gruppenmitglied.
2entwicklunghochniedrigaschattRechtzeitige Fertigstellung gefährdet: Die rechtzeitige Fertigstellung des Projekts ist gefährdet. Mögliche Ursachen könnten zu hohe Anforderungen, zu geringe zeitliche Ressourcen, Ausfall von Team-Mitgliedern, etc sein.Reduktion von Features anhand ihrer Priorisierung (abhängig von aktuellem Fortschritt)
3managementhochniedrig2sbiVerlust von Projekt-internen Wissen: Verlust an Projekt-internem Wissen durch verschiedene Ursachen (zB Ausscheiden eines Projektmitglieds, Server-Ausfall, etc)Dokumentation aller relevanten Informationen im SCM und Tracker; Eigenständige Backups vom Tracker
4planung, entwicklunghochniedrig2aschattNotwendige Libraries nicht verfügbar: Während des Projektverlaufs stellt sich heraus, dass für ein bestimmtes Feature notwendige Libraries nicht (frei) verfügbar sind.Sofern der Aufwand vertretbar ist, können die Funktionalitäten selbst entwickelt, bzw andere Libraries adaptiert werden; Ist dies nicht möglich, muss das Feature so weit wie notwendig reduziert werden.
5planung, entwicklungmittelmittel2mdemolskyUnzureichende Design-Entscheidungen: Während der Implementierung stellt sich eine Design-Entscheidung als unzureichend heraus.Design-Entscheidungen werden so früh wie möglich mit allen Projektmitgliedern besprochen, die die Entscheidung bezüglich Ihrer Rolle beurteilen; Modulares Design, damit die Auswirkungen falscher Design-Entscheidungen möglichst klein gehalten werden

Informationswesen

Die Informationsstruktur für das Projekt wird folgendermaßen aussehen:

  • Wöchentliche Treffen intern (Jour-Fixe)
  • Wöchentliche Treffen mit dem Tutor (Tutortreffen)
  • Insgesamt 5 Reviews (2 IRs, 3 MRs) zu den 5 Meilensteinen mit 5 Statusberichten
  • Elektronische Kommunikation synchron mit Skype und Google Docs, asynchron via dem Tracker. Die Mailingliste ist mit niedrigerer Priorität zu verwenden.
  • Kommunikation mit den Auftraggebern und Tutor per Mailingliste

Die zur Verfügung gestellte Infrastruktur umfasst:

  • SVN Repository
  • TRAC
  • Externe Mailingliste
  • Root-Server mit SSH-Zugang
  • Application Server
  • Datenbankserver

Besonderheiten

Das SAT Projekt basiert auf der Architektur des Medium Examples von Best-Practice Software Engineering (BPSE-Medium). Wir wollen nochmals zusammenfassen welche Design Patterns und Architekturprinzipen in BPSE-Medium angewandt wurden. Als Architekturstil wurde eine 5-Schichten-Architektur gewählt, wobei ausschließlich der Presentation Layer am Client (= Browser) läuft. Durch die verteilte Architektur erfolgt die Kommunikation zwischen Client und Browser über das HTTP Protokoll.

Wie auch im Basis Beispiel (BPSE-Basic) wurden Interfaces und DAOs verwendet. Um eine klare Trennung zwischen der relationalen Welt und der objekt orientierten Welt zu schaffen, wurde ein O/R Mapper eingesetzt. Die Mapping Informationen wurden in XML Dateien definiert. Querschnittsfunktionen wie Security und Transaktionsmanagement wurden mit der Aspekt Orientierten Programmierung (AOP) realisiert, was ein Verschlanken unserer DAOs und Service Objekte mit sich brachte.