http://www.tu-ilmenau.de

Logo TU Ilmenau


INHALTE

Ablauf des Softwareprojektes

Allgemeiner Ablauf

Die folgende Abbildung stellt den organisatorischen Ablauf des Softwareprojekts dar. Das Projekt beginnt mit einer Einführungsveranstaltung, in der organisatorische Rahmenbedingungen, das Einschreibeverfahren, die eingesetzten Tools, der Projektablauf und vor allem die Themen vorgestellt werden. Anschließend können sich die Studenten für die verschiedenen Themen bzw. Gruppen online einschreiben.

Die Gruppen bearbeiten ihre Themen parallel. Sie beginnen mit der Planungs- und Entwurfsphase, in deren Ergebnis unter anderem das verbindliche Pflichtenhefte und der Entwurf entstehen. Darüber hinaus entscheiden die Studenten in dieser Phase nach welchem Vorgehensmodell das Softwareprojekt ablaufen soll. Abhängig davon unterscheiden sich auch die in den einzelnen Phasen abzugebenden Ergebnisse und Dokumente.

Unabhängig vom Vorgehensmodell wird das Thema in jeder Softwareprojektphase von den Gruppen bearbeitet und zum Abschluss eine Präsentation und verschiedene Reviewdokumente erstellt. Diese werden für das abschließende Review benötigt.

Im Rahmen des Reviews werden die Ergebnisse der aktuellen Phase in Form einer Präsentation (PowerPoint oder ähnliches) durch einen oder maximal zwei Studenten im Softwareprojektseminar vorgestellt. Dabei wechseln sich die Teilnehmer der Gruppen ab. In einer anschließenden Gruppenbesprechung bewertet der Betreuer alle Ergebnisse der aktuellen Phase und wertet diese mit den Studenten aus.

Das Softwareprojekt endet mit der Abschlussveranstaltung, bei der die Gruppen während des Softwareprojektseminars zum einen die Ergebnisse der letzten Phase und zum anderen die lauffähige und getestete Software in Form einer Produktpräsentation vorstellen.

Die Projektabnahme erfolgt durch den Betreuer im Rahmen des letzten Reviews. Hierbei wird das Softwareprodukt in Bezug auf die im Pflichtenheft definierten Ziele bewertet. Darüber hinaus sind folgende Punkte zusätzlich zum letzten Review-Dokument Grundlage der Projektabnahme:

  • lauffähiges Programm (Binaries) und Installation der Software auf dem Zielsystem inklusive einer Installationsanleitung 
  • die Erstellung einer vollständigen Dokumentation
  • die Übergabe des kompilierfähigen Quellcodes

Aus den individuellen Bewertungen der einzelnen Phasen, des Gesamtergebnisses und den Präsentationen wird eine Gersamtnote gebildet.

Vorgehensmodelle

Im Rahmen des Softwareprojektes kann durch die Gruppe ein Vorgehensmodell gewählt werden. Die Wahl erfolgt in Absprache mit dem Betreuer während der Planungsphase. Die erwarteten Ergebnisse pro Phase variieren leicht zwischen den Vorgehensmodellen und werden in den entsprechenden Abschnitten näher beschrieben. Um die Vergleichbarkeit der Ergebnisse zu gewährleisten ist ein Großteil der Anforderungen für alle Vorgehen gleich.

Die folgenden Vorgehensmodelle stehen zur Wahl:

 

Wasserfallmodell

Das Wasserfallmodell

Beim Wasserfallmodell wird die Softareentwicklung strikt in Phasen unterteilt, die nacheinander durchlaufen werden. Am Ende jeder Phase steht ein Meilenstein, welcher im SWP durch das Review markiert wird. Ein Rückkopplung aus einzelnen Phasen auf frühere Phasen ist im Wasserfallmodell nur eingeschränkt möglich. 

Damit das Wasserfallmodell zu einem erfolgreichen Abschluss führt, ist viel Erfahrung für die Planung und den Entwurf der Software notwendig.

Planungs- und Entwurfsphase

Während der Planungsphase wird das Pflichtenheft auf Basis eines Lastenheftes erstellt. Hierfür ist meist eine erste Systemanalyse notwendig, welche die Grundlage für den späteren Entwurf darstellt.

Während der Entwurfsphase wird das Konzept für das zu erstellende Softwareprodukt formuliert. Dies umfasst den Entwurf der Softwarearchitektur und des Datenmodells, die Definition von Komponenten und Schnittstellen, die Festlegung des Bedienkonzeptes und der Benutzerschnittstelle.

Implementierungsphase

Während der Implementierungsphase werden alle im Pflichtenheft festgelegten Anforderungen entsprechend des Entwurfs vollständig umgesetzt. Nach dieser Phase werden keine zusätzlichen Anforderungen implementiert (feature-freeze). Parallel entsteht die Entwicklerdokumentation durch Dokumentation des Quellcodes.

Validierungsphase

In der Validierungsphase wird die Software mit Hilfe eines in dieser Phase zu erstellenden Testdrehbuches getestet. Dabei auftretende Fehler werden behoben. Im Ergebnis entsteht eine Validierungsdokumentation, die Grundlage des Reviews und der letzten Präsentation ist. Darüber hinaus sollen in dieser Präsentation die Funktionen der Software in Form einer Produktpräsentation vorgestellt werden.

Unified Process

Vorgehen nach dem Unified Process

Die Erweiterung bestehender Vorgehendmodelle um die  objektorientierten Analyse, Design und Implementierung führte zu den so genannten objektorientierten Vorgehensmodellen. Es wurden aber auch spezielle Vorgehensmodelle entwickelt, deren Ziel es war, diverse Probleme bestehender Vorgehensmodelle zu beheben, die Wiederverwendung bestehender Lösungen zu erhöhen und die Bedeutung der Softwarearchitektur zu steigern.  Diese Vorgehensmodelle besitzen folgende Eigenschaften:

  • iterativ / inkrementell: Entwicklung in mehreren Entwurfszyklen
  • evolutionär: Entwicklung eines schnellen Prototypen, der pro Iteration verfeinert wird.
  • architekturzentriert: Die Softwarearchitektur hat von Anfang an eine hohe Bedeutung; Wiederverwendung bewährter Lösungen (z.B. Architektur- und Entwurfsmuster)
  • Anwendungszentriert: Anwendungsfälle bestimmen den Funktionsumfang

Die Erkenntis, das sich die Tätigkeiten der Softwareentwicklung (Anforderungsanalyse,  Entwurf, Implementierung und Test) nicht strikt trennen lassen, führte zur Unterteilung des Softwareentwicklungsprozesses, in mehrere iterative Softwareentwicklungsphasen. Innerhalb dieser Phasen werden die Tätigkeiten der Softwareentwicklung mit unterschiedlichem Aufwand parallel durchgeführt.

Jacobson, Booch and Rumbaugh, "Die drei Amigos" die "Väter der UML",  beschriebenen 1999 den Unified Software Development Process  [JBR99], deren bekanntesten Vertreter der Rational Unified Process (RUP von IBM), der Open Unified Process (Eclipse Foundation) und der  oose Engineering Process (OOSE).  

Vorgehensbeschreibung

Angeleht an den Unified Process wird folgedes Vorgehen für das Softwareprojekt vorgeschlagen.

Die einzelnen Tätigkeiten laufen parallel in den verschiedenen Phasen des Softwareprojektes mit unterschiedlich hohem Aufwand ab. Die Planungssphase ist zunächst bei allen Vorgehen ähnlich. Bei diesem Vorgehen können jedoch bereits erste Testimplementierungen zur Abschätzung des Aufwandes durchgeführt werden. Ebenso ist die Erstellung eines Modells zur Anforderungsanalyse z.B. mittels Use-Case-Diagramm möglich.

 

In der Entwurfsphase wird das Grobkonzept erstellt. Es können kritische Punkte beispielhaft implementiert werden um das Grobdesign abzusichern. Außerdem soll ein Testdrehbuch erstellt werden, indem die Testfälle der einzelnen Features definiert werden, gegen das die spätere Applikation getestet werden soll.

In der Implementierungsphase werden die einzelnen Anforderungen iterativ realisiert. Hierzu wird pro Anforderung:

  • die Anforderung analysiert
  • ein Fein-Entwurf zur Lösung der Anforderung erstellt und in das Gesamtmodell integriert
  • der Fein-Entwurf implementiert
  • die fertig gestellte Lösung getestet

Während der Validierungsphase wird die komplette Anwendung mit Hilfe des Testdrehbuchs gestestet. Es werden keine weiteren Features implementiert (feature-freeze). Die gefundenen Fehler werden in einer Fehler-Liste gesammelt. Die auf der Liste stehenden Fehler werden parallel behoben und die Lösung anschießend getestet.

Agiles Vorgehensmodell

Agiles Vorgehensmodell

Die zunehmende Verbreitung der, vor allem für kleinere Projekte, als zu komplex, zu starr und zu bürokratisch angesehenen Vorgehensmodelle, wie z.B. das V-Modell oder der Unified Process, führte zu einer Gegenbewegung, die zur Entwicklung der so genannten agilen Vorgehensmodelle führte. Diese Vorgehen haben das Ziel den bürokratischen Aufwand zu reduzieren, in dem nur wenige Regeln bzw. Verhalten definiert werden. Diese sehr flexibel gehaltenen Vorgehen sind stark Anwendungsgetrieben mit sehr schnellen Entwicklungsiterationen. Auch sind die sozialen Aspekte während des Softwareentwicklungsprozesses von großer Bedeutung. Bekannte Vertreter dieser Vorgehensmodelle sind das Extreme Programming (XP), Scrum und Kanban. Durch spezielle Anpassung ("Tailoring") vieler Vorgehensmodelle, wie z.B. dem Unified Process, können diese agiler gestaltet werden (zum Beispiel: Agile Unified Process (AUP)).

Beispiele für Richtlinien, Werte und Prinzipien

Die folgende Liste zeigt nur einige Beispiele der in den Agilen Vorgehensmodellen verwendeten Richtlinien, Werte und Prinzipien.

  • anwendungsgetriebenes, ereignisorientiertes Vorgehen
  • inkrementelles, iteratives, evolutionäres Vorgehen
  • testgetriebenes Vorgehen
  • Individuen und Interaktionen bedeutender als Prozesse und Tools
  • funktionierende Programme bedeutender als übermäßige Dokumentation
  • enge Zusammenarbeit mit dem Kunden
  • Mut und Offenheit für Änderungen bedeutender als das Befolgen eines Plans
  • KISS‐Prinzip („Keep it small and simple“)
  • Coding Rules
  • Gemeinsamer Codebesitz
  • ständige Lauffähigkeit des Codes
  • Team ist für Ergebnis verantwortlich und organisiert sich selbst
  • Kommunikation statt Dokumentation
  • Kleine Teams 5-8 Personen
  • Respekt untereinander
  • Fehlschläge hinnehmen
  • Pair-Programming
  • keine Überstunden 

Vorgehensbeschreibung

Das agile Vorgehen im Softwareprojekt hat folgende Punkte eigenschaften:

  • anwendungsgetriebenes, ereignisorientiertes Vorgehen
  • inkrementelles, iteratives, evolutionäres Vorgehen
  • testgetriebenes Vorgehen

Im Gegensatz zum Unified Process wird bei diesem Vorgehen pro Softwareprojektphase eine Softwareentwicklungs-Iteration vollständig durchlaufen. Wobei die Tätigkeiten der Softwareentwicklung innerhalb einer Iteration parallel ablaufen. 

Die Planungsphase ist zunächst bei allen Vorgehensmodellen ähnlich. Beim agilen Vorgehen können und sollen jedoch bereits erste Testimplementierungen zur Abschätzung des Aufwandes durchgeführt werden. Ebenso ist die Erstellung eines Modells zur Anforderungsanalyse z.B. mittels Use-Case-Diagramm möglich.

Bereits in der ersten Iteration wird ein schneller Prototyp erstellt. Hierzu werden die Anforderungen analystiert, die Grobarchitektur des Systems erstellt, das Grundgerüst implementiert und getestet. Die nächste Phase beginnt mit eine weiteren Anforderungsanalyse und der Entscheidung welche Aufgaben in der nächsten Iteration realisiert werden sollen. Insgesamt wird der Prototyp zwei mal um weitere Funktionen erweitert.

Im Ergebnis hat man nach jeder Iteration eine lauffähige Software, die iterativ um zusätzliche Funktionalitäten erweitert wird.

 

Welche weiteren Regeln und Verhalten der Agilen Vorgehensmodelle (z.B. Coding Rules) im Projekt verwendet werden sollen wird von den Projektgruppen selbstständig gewählt. Im ersten Review wird die Auswahl der Regeln vorgestellt werden.

Aufgaben, Dokumente, Präsentationen

Allgemeine Aufgaben

Die Aufgaben bzw. die  erwarteten Ergebnisse, die Inhalte und die Anzahl der Review-Dokumente sowie die Inhalte der Präsentationen sind abhängig von der Wahl des Vorgehens. Zur vergleichbaren Bewertung bestehen die Aufgaben und die vorgeschlagenen Inhalte der Dokumente und Präsentationen jeweils aus einem allgemeinen Teil, der unabhängig vom Vorgehen ist, und einem vorgehensspezifischen Teil. In der folgenden Tabelle werden diese für die verschiedenen Vorgehen näher beschrieben.

Allgemeines zu den Review-Dokumenten

Die erstellten Review-Dokumente können teilweise in späteren Review-Dokumenten wiederverwendet und erweitert werden. So kann zum Beispiel das Entwurfsdokument aus der Entwurfsphase in der Implementierungsphase mit Feinentwürfen erweitert und aktualisiert werden und dient zum Abschluss des Projektes als Entwicklerdokumentation. Zum Abschluss des Softwareprojektes soll ein finales Review-Dokument aus allen Ergebnissen des Projektes erstellt werden.

Allgemeines zu den Präsentationen

In der Präsentation sollten die wichtigsten Ergebnisse der einzelnen Phasen in 15 Minuten dargestellt werden. Hierfür sollte eine Powerpoint-Präsentation oder ähnliches verwendet werden. Bitte beachten Sie die allgemeinen Richtlinien für Präsentationen. Die Zielgruppe für die Präsentationen ist der Auftraggeber, der durch Ihre Kommilitonen, den Betreuer und die Professoren vertreten wird. Sie sollten die Aufgaben der Phase, Ihre Entscheidungen und Ihre gewählten Lösungen verständlich präsentieren.

Die letzte Präsentation stellt den Abschluss des Softwareprojektes dar. Hierzu soll das Ergebnis des Softwareprojektes in Form einer Produktpräsentation vorgestellt werden. Das laufende Programm ist dazu mit seinen Funktionen möglichst live zu demonstrieren.

Die Aufgabenstellungen

Wasserfallmodell

Aufgaben - Wasserfallmodell

Die Aufgaben des Wasserfallmodells umfasst in der ersten Phase einen vollständigen Feinentwurf. In den folgenden Phasen sollen notwendige Entwurfsänderungen dokumentiert und begründet werden. In der letzten Phase werden üblicherweise keine Funktionalitäten implementiert sondern nur noch mit Hilfe eines Testdrehbuchs das Programm getestet und Dokumentationen erstellt.

Im Folgenden werden alle Anforderungen vorgestellt:

Planung und Entwurf

1. Phase - Planung und Entwurf

Allgemeine Aufgaben

Unabhängig von der Wahl des Vorgehens sollen im Ergebnis der Planungs- und Entwurfssphase alle Gruppenmitglieder mit dem Thema und den eingesetzten Werkzeugen vertraut sein. Es soll die Wahl des Vorgehensmodells getroffen und begründet werden, das Pflichtenheft erstellt werden, die zu verwendeten Technologien festgelegt und die Organisationsstruktur der Gruppe definiert werden. Darüber hinaus sollen grundlegende Entwurfsentscheidungen getroffen werden.

Übersicht über die allgemeinen Planungsaufgaben:
  • Festlegung des Vorgehensmodells
    • Projektspezifische Anpassungen des Vorgehens
    • Projektplan
    • Meilensteine
  • Pflichtenheft erstellen
    • Problemstellung
    • Funktionale und Nichtfunktionale Anforderungen
    • Muss- und Wunschkriterien
    • Aufwand-Nutzen-Analyse
    • Risikoanalyse
  • Verwendete Technologien und Entwicklungswerkzeuge festlegen
    • verwendete Programmiersprache(n)
    • verwendete API's
    • verwendete Bibliotheken
    • verwendete Tools z.B.: Versionierung, Wiki, Bugtracking usw.
  • Festlegung der internen Organisation der Gruppe
    • Rollenverteilung (Tutor ist kein Teammitglied sondern Auftraggeber)
    • Kommunikationswege
    • Gruppentreffen
Übersicht über die allgemeinen Entwurfsaufgaben:
  • Treffen und begründen grundlegender Entwurfsentscheidungen
  • Grobkonzept und grundlegenden Softwarearchitektur erstellen
    • Systemkomponenten festlegen, deren Struktur und grundlegendes Verhalten sowie deren Zuständigkeiten definieren
    • Schnittstellen der Komponenten festlegen, Beziehungen zwischen den Komponenten festlegen
    • UML-Modell der geplanten Softwarearchitektur erstellen

Vorgehensspezifische Aufgaben

  • Variante des Wasserfallmodells festlegen (z.B.: mit oder ohne Rückkopplung)
  • Meilensteine festlegen
    • Kriterien und Bedingungen für den Wechsel der Phasen definieren
  • Maßnahmen zur Fehlervermeidung / Fehlerfindung in den frühen Phasen festlegen
  • Für jede Anforderung:
    • Anforderung analysieren
    • Fein-Entwurf zur Lösung der Anforderung erstellen und in das Gesamtmodell integrieren
  • Modell des Feinentwurfs erstellen

Allgemeiner Inhalt der Reviewdokumente

Zentrales Ergebnis der Planungs- und Entwurfsphase ist das Pflichtenheft und die Erstellung des Grob- bzw. je nach Vorgehen auch die Ergebnisse des Feinentwurfs. Daraus ergeben sich zwei Hauptteile: 

  • Ergebnisse der Planung: Pflichtenheft
  • Ergebnisse des Entwurfs: Entwurfsdokumentation 

Die Reviewdokumente können als eigenständige Dokumente erstellt werden oder als ein gemeinsames Dokument. Folgenden Inhalt sollten die Teile des Review-Dokuments haben:

Ergebnisse der Planung
  • Pflichtenheft, separat oder integriert
    • Die Inhalte eines Pflichtenheftes sind hier beschrieben
  • Vorgehen innerhalb des Softwareprojektes
    • Beschreibung des gewählten Vorgehensmodells inklusive projektspezifischer Anpassungen des Vorgehens
    • Entwickelter Projektplan inklusive einer Abschätzung des Aufwands
    • Vorstellung der festgelegten Meilensteine
  • Interne Organisation der Gruppe
    • Beschreibung und Aufteilung der gewählten Rollen
    • Beschreibung der Kommunikationswege
    • Beschreibung weiterer organisatorischer Festlegungen wie z.B. Anzahl und Art der Gruppentreffen
Ergebnisse des Entwurfs
  • Anforderungsanalyse
  • Entwurfsalternativen und Entwurfsentscheidungen
  • Dokumentation des geplanten Entwurfs
    • Systemzerlegung 
      • Pakete, Komponenten, Schnittstellen, evtl. Klassenstruktur
      • Darstellung mit geeigneten Diagrammen
    • Abbildung auf HW/SW-Komponenten
    • Globaler Kontrollfluss 
    • Management persistenter Daten
    • evtl. verwendete Architekturmuster
  • Verwendete Technologien und Entwicklungswerkzeuge
    • Beschreibung der verwendeten Programmiersprache(n), Bibliotheken und API's
    • Beschreibung der verwendeten Entwicklungswerkzeuge wie Versionierung, Bugtracking, Wiki usw.

 Vorgehensspezifische Reviewinhalte

  • Meilensteine mit Kriterien und Bedingungen für den Wechsel der Phasen
  • Maßnahmen zur Fehlervermeidung / Fehlerfindung
  • Fein-Entwurf incl. Modell des Feinentwurfs
  • Schnittstellendefinition zwischen den Komonenten / Modulen des Feinentwurfs

Allgemeiner Präsentationsinhalt

Im Folgenden werden einige mögliche Präsentationsinhalte für die Planungsphase vorgestellt:

  • Beschreibung der Aufgabe
    • Projekt und Systemumgebung
    • funktionale und nichtfunktionale Anforderungen, Randbedingungen
    • Analyse, Priorisierung und Klassifizierung der Anforderungen (Muss- und Kann-Anforderungen).
  • Ergebnisse der Anforderungsanalyse 
  • Vorstellung des Grobentwurfs (mittels geeigneter Diagramme)
    • Vorstellung grundlegender Entwurfsentscheidungen und eventueller Entwurfsalternativen
    • grundlegende Softwarearchitektur
      • Vorstellung grundlegender Systemkomponenten (Struktur, grundlegendes Verhalten, Zuständigkeiten)
      • Schnittstellen der Komponenten
      • Beziehungen zwischen den Komponenten
    • evtl. verwendete Architekturmuster
  • Verwendete Technologien und Entwicklungswerkzeuge
  • Auswahl, Begründung und Beschreibung des Vorgehens
  • Entwickelter Projektplan mit Aufwands- und Risikoabschätzung, sowie Meilensteinen
  • Interne Organisation der Gruppe
  • Stand des Projekts
  • Ausblick

 Vorgehensspezifische Präsentationsinhalte

  • Ausgewählte Elemente des Feinentwurfs
  • event. verwendete Entwurfsmuster
    • Vorstellung wie sie in das Modell integriert sind

Implementierung

2. Phase - Implementierung

Allgemeine Aufgaben

  • Implementierung des in den vorherigen Phasen geplanten Softwaresystems
  • Berücksichtigung aller Muss-Anforderungen
  • Entwicklerdokumentation erstellen (JavaDoc, Doxygen,... )
  • Stand des Projektes überprüfen

Vorgehensspezifische Aufgaben

  • Entwurf implementieren
  • Entwicklertests können auch im Wasserfallmodell durchgeführt werden
  • Änderungen des Entwurfs dokumentieren und begründen

Allgemeiner Inhalt der Reviewdokumente

Als Review-Dokumente sollen zwei Dokumente erstellt werden: 

  • Das Reviewdokument
  • Entwicklerdokumentation 

Das Reviewdokument des Entwurfs soll um wichtige Details des Feinentwurfs, wie z.B. die Dokumentation der Klassenstruktur erweitert werden. Auch sollen wichtige Entwurfsentscheidungen und Änderungen der Architektur dokumentiert werden. Folgenden Inhalt sollte das Reviewdokument besitzen:

  • Zweck des Systems, Entwurfsziele, Überblick (Teil des Pflichtenhefts)
  • Grundlegende Architektur / Grobentwurf (Teil des Entwurfsdokuments)
  • Dokumentation des realisierten Entwurfs
    • Darstellung und Beschreibung der realisierten Architektur mittels geeigneter Diagramme
    • evtl. verwendete Entwurfsmuster
    • Dokumentation der Problemlösung, Implementierungsentscheidungen und verwendeter Prinzipien
  • evtl. Überarbeitung des Entwurfs
    • Entscheidungen begründen
  • Schnittstellendokumentation
  • Akronyme und Abkürzungen, Glossar
  • Referenzen

Als zweites eigenständiges Dokument soll eine Entwicklerdokumentation erstellt werden. Diese kann aus den Kommentaren im Quelltext mit Hilfe entsprechender Tools (JavaDoc, Doxygen,...) generiert werden.

 Vorgehensspezifische Reviewinhalte

  • event. Änderungen des Entwurfs dokumentieruen und begründen

Allgemeiner Präsentationsinhalt

Den Schwerpunkt dieser Präsentation stellt die Implementierung dar. Das entstandene Programm soll erst in der Abschlussveranstaltung präsentiert werden. Daraus ergeben sich folgende Präsentationsinhalte:

  • Einleitung
    • Kurzbeschreibung der Aufgabe
    • Kurzbeschreibung des Grobentwurfs 
  • Vorstellung des Feinentwurfs
    • Vorstellung der Struktur und des Verhalten wichtiger Komponenten
    • wichtige Implementierungsalternativen und Entscheidungen
    • eventuelle Änderungen des Grobentwurfs
  • Beispielhafte Realisierung eines Implementierungsdetails
  • evtl. Integration verwendeter Entwurfsmuster
  • Stand des Projekts
  • Ausblick

Vorgehensspezifische Präsentationsinhalte 

  • Änderungen des Entwurfs vorstellen und begründen

Validierung

3. Phase - Validierung

Allgemeine Aufgaben

  • Anwendung strukturiert testen
  • Fehler behandeln
  • Produktpräsentation erstellen
  • Finales Reviewdokument des gesamten Softwarepojektes erstellen
  • Benutzerhandbuch erstellen
  • Installation bzw. Installationsanleitung erstellen
  • Quelltext dem Betreuer übergeben 
  • Projekterfolg bewerten
  • Vorgehen bewerten

Vorgehensspezifische Aufgaben

  • Erstellung eines Testdrehbuchs zur Überprüfung des Softwaresystems
  • Anwendung anhand des Testdrehbuchs testen

Allgemeiner Inhalt der Reviewdokumente

Als Review-Dokumente sollen 3 Dokumente erstellt werden: 

  • Finales Reviewdokument des Gesamtprojektes
  • Benutzerhandbuch
  • Installationsanleitung / bzw. Installation

Die Dokumente können bei Bedarf miteinander kombiniert werden. Ausgangsdokument kann das Reviewdokument der Implementierung sein. Folgende Inhalte sollten im finalen Review-Dokument enthalten sein:

  • Zweck des Systems, Entwurfsziele, Überblick (Teil des Pflichtenhefts)
  • Grundlegende Architektur / Grobentwurf (Teil des Entwurfsdokuments)
  • Dokumentation des realisierten Entwurfs (Teil des Implementierungsdokuments)
  • Dokumentation der wichtigsten Testfälle
  • Nachweis funktionaler und nichtfunktionaler Eigenschaften (durch Vorstellung der Testergebnisse)
  • Bugreview (Anzahl offener Anforderungen und Fehler)
  • evtl. Softwaremetriken und weiterer Statistiken
  • Kritische Bewertung des Projekterfolgs
  • Kritische Bewertung des Vorgehens
  • Akronyme und Abkürzungen, Glossar
  • Referenzen
  • weiterer Anhang

Darüber hinaus soll ein Benutzerhandbuch erstellt werden, in dem die Funktionen und die Benutzeroberfläche der Software beschrieben wird.

Schließlich soll eine Installationsanleitung für das fertig entwickelte System erstellt werden.

Vorgehensspezifische Reviewinhalte 

  • Testdrehbuch
    • wichtige Testfälle
    • Testplanung, -vorbereitung und -durchführung
  • Ergebnisse der Tests entsprechend des Testdrehbuchs

Vorgeschlagener Inhalt der Abschlusspräsentation

Ziel dieser Präsentation ist die Vorstellung des Ergebnisses des Softwareprojektes, also die Präsentation der laufenden Software. Wählen Sie eine für Ihr individuelles Softwareprojekt vorteilhafte/geeignete Demonstrationsart. Die vorgeschlagenen Inhalte sind für alle Vorgehen gleich.

  • Einleitung
    • Kurzbeschreibung der Aufgabe
    • Kurzbeschreibung der Lösung / der grundlegenden Architektur
  • Software demonstrieren (Oberfläche und Funktionen)
  • Zusammenfassung
    • Stand des Projekts
    • Ausblick für zukünftige Weiterentwicklungen
    • Kritische Bewertung des Projektes / des Vorgehens

Unified Process

Aufgaben - Unified Process

Die Aufgaben des Unified Process umfassen Aufgaben aus allen Softwareprojektphasen. Daher sollen zusätzlich zu den allgemeinen Aufgaben Ergebnisse aus allen Phasen des Softwareentwicklungsprozesses vorgestellt werden.

Im Folgenden werden alle Anforderungen vorgestellt:

Planung und Entwurf

1. Phase - Planung und Entwurf

Allgemeine Aufgaben

Unabhängig von der Wahl des Vorgehens sollen im Ergebnis der Planungs- und Entwurfssphase alle Gruppenmitglieder mit dem Thema und den eingesetzten Werkzeugen vertraut sein. Es soll die Wahl des Vorgehensmodells getroffen und begründet werden, das Pflichtenheft erstellt werden, die zu verwendeten Technologien festgelegt und die Organisationsstruktur der Gruppe definiert werden. Darüber hinaus sollen grundlegende Entwurfsentscheidungen getroffen werden.

Übersicht über die allgemeinen Planungsaufgaben:
  • Festlegung des Vorgehensmodells
    • Projektspezifische Anpassungen des Vorgehens
    • Projektplan
    • Meilensteine
  • Pflichtenheft erstellen
    • Problemstellung
    • Funktionale und Nichtfunktionale Anforderungen
    • Muss- und Wunschkriterien
    • Aufwand-Nutzen-Analyse
    • Risikoanalyse
  • Verwendete Technologien und Entwicklungswerkzeuge festlegen
    • verwendete Programmiersprache(n)
    • verwendete API's
    • verwendete Bibliotheken
    • verwendete Tools z.B.: Versionierung, Wiki, Bugtracking usw.
  • Festlegung der internen Organisation der Gruppe
    • Rollenverteilung (Tutor ist kein Teammitglied sondern Auftraggeber)
    • Kommunikationswege
    • Gruppentreffen
Übersicht über die allgemeinen Entwurfsaufgaben:
  • Treffen und begründen grundlegender Entwurfsentscheidungen
  • Grobkonzept und grundlegenden Softwarearchitektur erstellen
    • Systemkomponenten festlegen, deren Struktur und grundlegendes Verhalten sowie deren Zuständigkeiten definieren
    • Schnittstellen der Komponenten festlegen, Beziehungen zwischen den Komponenten festlegen
    • UML-Modell der geplanten Softwarearchitektur erstellen

Vorgehensspezifische Aufgaben

  • Anpassung (Tailoring) des  Unified Process an die Projektbedürfnisse
  • Untersuchung der Machbarkeit durch Beispielrealisierungen kritischer bzw. essenzieller Funktionalitäten
  • Erstellung eines Testdrehbuchs zur Überprüfung des Softwaresystems 

Allgemeiner Inhalt der Reviewdokumente

Zentrales Ergebnis der Planungs- und Entwurfsphase ist das Pflichtenheft und die Erstellung des Grob- bzw. je nach Vorgehen auch die Ergebnisse des Feinentwurfs. Daraus ergeben sich zwei Hauptteile: 

  • Ergebnisse der Planung: Pflichtenheft
  • Ergebnisse des Entwurfs: Entwurfsdokumentation 

Die Reviewdokumente können als eigenständige Dokumente erstellt werden oder als ein gemeinsames Dokument. Folgenden Inhalt sollten die Teile des Review-Dokuments haben:

Ergebnisse der Planung
  • Pflichtenheft, separat oder integriert
    • Die Inhalte eines Pflichtenheftes sind hier beschrieben
  • Vorgehen innerhalb des Softwareprojektes
    • Beschreibung des gewählten Vorgehensmodells inklusive projektspezifischer Anpassungen des Vorgehens
    • Entwickelter Projektplan inklusive einer Abschätzung des Aufwands
    • Vorstellung der festgelegten Meilensteine
  • Interne Organisation der Gruppe
    • Beschreibung und Aufteilung der gewählten Rollen
    • Beschreibung der Kommunikationswege
    • Beschreibung weiterer organisatorischer Festlegungen wie z.B. Anzahl und Art der Gruppentreffen
Ergebnisse des Entwurfs
  • Anforderungsanalyse
  • Entwurfsalternativen und Entwurfsentscheidungen
  • Dokumentation des geplanten Entwurfs
    • Systemzerlegung 
      • Pakete, Komponenten, Schnittstellen, evtl. Klassenstruktur
      • Darstellung mit geeigneten Diagrammen
    • Abbildung auf HW/SW-Komponenten
    • Globaler Kontrollfluss 
    • Management persistenter Daten
    • evtl. verwendete Architekturmuster
  • Verwendete Technologien und Entwicklungswerkzeuge
    • Beschreibung der verwendeten Programmiersprache(n), Bibliotheken und API's
    • Beschreibung der verwendeten Entwicklungswerkzeuge wie Versionierung, Bugtracking, Wiki usw.

Vorgehensspezifische Reviewinhalte

  • Vorstellung des angepassten Vorgehens
  • Ergebnisse der Machbarkeitsanalysen und Beispielrealisierungen
  • Testdrehbuch
    • wichtige Testfälle
    • Testplanung
    • Festlegung zur Vorbereitung und Durchführung

Allgemeiner Präsentationsinhalt

Im Folgenden werden einige mögliche Präsentationsinhalte für die Planungsphase vorgestellt:

  • Beschreibung der Aufgabe
    • Projekt und Systemumgebung
    • funktionale und nichtfunktionale Anforderungen, Randbedingungen
    • Analyse, Priorisierung und Klassifizierung der Anforderungen (Muss- und Kann-Anforderungen).
  • Ergebnisse der Anforderungsanalyse 
  • Vorstellung des Grobentwurfs (mittels geeigneter Diagramme)
    • Vorstellung grundlegender Entwurfsentscheidungen und eventueller Entwurfsalternativen
    • grundlegende Softwarearchitektur
      • Vorstellung grundlegender Systemkomponenten (Struktur, grundlegendes Verhalten, Zuständigkeiten)
      • Schnittstellen der Komponenten
      • Beziehungen zwischen den Komponenten
    • evtl. verwendete Architekturmuster
  • Verwendete Technologien und Entwicklungswerkzeuge
  • Auswahl, Begründung und Beschreibung des Vorgehens
  • Entwickelter Projektplan mit Aufwands- und Risikoabschätzung, sowie Meilensteinen
  • Interne Organisation der Gruppe
  • Stand des Projekts
  • Ausblick

 Vorgehensspezifische Präsentationsinhalte

  • Vorstellung der Ergebnisse der Machbarkeitsanalysen und Beispielrealisierungen
  • Vorstellung des Testdrehbuchs

Implementierung

2. Phase - Implementierung

Allgemeine Aufgaben

  • Implementierung des in den vorherigen Phasen geplanten Softwaresystems
  • Berücksichtigung aller Muss-Anforderungen
  • Entwicklerdokumentation erstellen (JavaDoc, Doxygen,... )
  • Stand des Projektes überprüfen

Vorgehensspezifische Aufgaben

  • Für jede Anforderung:
    • Anforderung analysieren
    • ein Fein-Entwurf zur Lösung der Anforderung erstellen und in das Gesamtmodell integrieren
    • Fein-Entwurf implementieren
    • fertig gestellte Lösung testen
  • Fehler in einer Fehlerliste eintragen, priorisieren (trac, Bugzilla,...) und eventuell beheben

Allgemeiner Inhalt der Reviewdokumente

Als Review-Dokumente sollen zwei Dokumente erstellt werden: 

  • Das Reviewdokument
  • Entwicklerdokumentation 

Das Reviewdokument des Entwurfs soll um wichtige Details des Feinentwurfs, wie z.B. die Dokumentation der Klassenstruktur erweitert werden. Auch sollen wichtige Entwurfsentscheidungen und Änderungen der Architektur dokumentiert werden. Folgenden Inhalt sollte das Reviewdokument besitzen:

  • Zweck des Systems, Entwurfsziele, Überblick (Teil des Pflichtenhefts)
  • Grundlegende Architektur / Grobentwurf (Teil des Entwurfsdokuments)
  • Dokumentation des realisierten Entwurfs
    • Darstellung und Beschreibung der realisierten Architektur mittels geeigneter Diagramme
    • evtl. verwendete Entwurfsmuster
    • Dokumentation der Problemlösung, Implementierungsentscheidungen und verwendeter Prinzipien
  • evtl. Überarbeitung des Entwurfs
    • Entscheidungen begründen
  • Schnittstellendokumentation
  • Akronyme und Abkürzungen, Glossar
  • Referenzen

Als zweites eigenständiges Dokument soll eine Entwicklerdokumentation erstellt werden. Diese kann aus den Kommentaren im Quelltext mit Hilfe entsprechender Tools (JavaDoc, Doxygen,...) generiert werden.

Vorgehensspezifische Reviewinhalte

  • Überarbeiteter Grobentwurf
  • Finaler Fein-Entwurf
  • Bug-Review (Anzahl offener Anforderungen und Fehler)

Allgemeiner Präsentationsinhalt

Den Schwerpunkt dieser Präsentation stellt die Implementierung dar. Das entstandene Programm soll erst in der Abschlussveranstaltung präsentiert werden. Daraus ergeben sich folgende Präsentationsinhalte:

  • Einleitung
    • Kurzbeschreibung der Aufgabe
    • Kurzbeschreibung des Grobentwurfs 
  • Vorstellung des Feinentwurfs
    • Vorstellung der Struktur und des Verhalten wichtiger Komponenten
    • wichtige Implementierungsalternativen und Entscheidungen
    • eventuelle Änderungen des Grobentwurfs
  • Beispielhafte Realisierung eines Implementierungsdetails
  • evtl. Integration verwendeter Entwurfsmuster
  • Stand des Projekts
  • Ausblick

 Vorgehensspezifische Präsentationsinhalte 

  • Änderungen des Grobentwurfs
  • Bug-Review
    • Ausblick: welche Anforderungen bzw. Fehler werden noch behoben

Validierung

3. Phase - Validierung

Allgemeine Aufgaben

  • Anwendung strukturiert testen
  • Fehler behandeln
  • Produktpräsentation erstellen
  • Finales Reviewdokument des gesamten Softwarepojektes erstellen
  • Benutzerhandbuch erstellen
  • Installation bzw. Installationsanleitung erstellen
  • Quelltext dem Betreuer übergeben 
  • Projekterfolg bewerten
  • Vorgehen bewerten

Vorgehensspezifische Aufgaben

  • Anwendung anhand des Testdrehbuchs testen
  • Fehlerliste erstellen und Fehler iterativ priorisieren und beheben
    • eventuell Bugstatistik erstellen



Allgemeiner Inhalt der Reviewdokumente

Als Review-Dokumente sollen 3 Dokumente erstellt werden: 

  • Finales Reviewdokument des Gesamtprojektes
  • Benutzerhandbuch
  • Installationsanleitung / bzw. Installation

Die Dokumente können bei Bedarf miteinander kombiniert werden. Ausgangsdokument kann das Reviewdokument der Implementierung sein. Folgende Inhalte sollten im finalen Review-Dokument enthalten sein:

  • Zweck des Systems, Entwurfsziele, Überblick (Teil des Pflichtenhefts)
  • Grundlegende Architektur / Grobentwurf (Teil des Entwurfsdokuments)
  • Dokumentation des realisierten Entwurfs (Teil des Implementierungsdokuments)
  • Dokumentation der wichtigsten Testfälle
  • Nachweis funktionaler und nichtfunktionaler Eigenschaften (durch Vorstellung der Testergebnisse)
  • Bugreview (Anzahl offener Anforderungen und Fehler)
  • evtl. Softwaremetriken und weiterer Statistiken
  • Kritische Bewertung des Projekterfolgs
  • Kritische Bewertung des Vorgehens
  • Akronyme und Abkürzungen, Glossar
  • Referenzen
  • weiterer Anhang

Darüber hinaus soll ein Benutzerhandbuch erstellt werden, in dem die Funktionen und die Benutzeroberfläche der Software beschrieben wird.

Schließlich soll eine Installationsanleitung für das fertig entwickelte System erstellt werden.

Vorgehensspezifische Reviewinhalte

  • Ergebnisse der Tests entsprechend dem Testdrehbuch

Vorgeschlagener Inhalt der Abschlusspräsentation

Ziel dieser Präsentation ist die Vorstellung des Ergebnisses des Softwareprojektes, also die Präsentation der laufenden Software. Wählen Sie eine für Ihr individuelles Softwareprojekt vorteilhafte/geeignete Demonstrationsart. Die vorgeschlagenen Inhalte sind für alle Vorgehen gleich.

  • Einleitung
    • Kurzbeschreibung der Aufgabe
    • Kurzbeschreibung der Lösung / der grundlegenden Architektur
  • Software demonstrieren (Oberfläche und Funktionen)
  • Zusammenfassung
    • Stand des Projekts
    • Ausblick für zukünftige Weiterentwicklungen
    • Kritische Bewertung des Projektes / des Vorgehens

Agiles Vorgehensmodell

Aufgaben - Agiles Vorgehen

In jeder Iteration sollen die folgenden Aufgaben mit steigender Feinheit durchgeführt werden:

  • Analysieren der in der aktuellen Iteration zu realisierenden Anforderungen bzw. der zu behebenden Fehler
  • Entwerfen bzw. Erweitern der bestehenden Softwarearchitektur (UML-Modell) zur Realisierung der zu realisierenden Anforderungen
    • Die Architektur muss so erweiterbar sein, dass alle folgenden Anforderungen in diese Architektur integriert werden können
  • Implementieren der für diese Iteration festgelegten Anforderungen
    •  dabei Entwicklerdokumentation erstellen (JavaDoc, Doxygen,... ) 
  • Test der Software speziell der neuen Andorderungen
    •  Fehler in einer Fehlerliste eintragen, priorisieren (trac, Bugzilla,...)
  • Erstellung bzw. Erweiterung der Dokumentation
  • Festlegung welche Anforderungen bzw. Fehler in der nächsten Iteration realisiert bzw. behoben werden sollen

Auch bei dem agilen Vorgehen sollen in den einzelnen Reviews ähnliche Inhalte wie bei den anderen Vorgehen vorgestellt werden. Diese und weitere phasenspezifische Anforderungen werden im Folgenden vorgestellt:

Planung und Entwurf

1. Phase - Planung und Entwurf

Allgemeine Aufgaben

Unabhängig von der Wahl des Vorgehens sollen im Ergebnis der Planungs- und Entwurfssphase alle Gruppenmitglieder mit dem Thema und den eingesetzten Werkzeugen vertraut sein. Es soll die Wahl des Vorgehensmodells getroffen und begründet werden, das Pflichtenheft erstellt werden, die zu verwendeten Technologien festgelegt und die Organisationsstruktur der Gruppe definiert werden. Darüber hinaus sollen grundlegende Entwurfsentscheidungen getroffen werden.

Übersicht über die allgemeinen Planungsaufgaben:
  • Festlegung des Vorgehensmodells
    • Projektspezifische Anpassungen des Vorgehens
    • Projektplan
    • Meilensteine
  • Pflichtenheft erstellen
    • Problemstellung
    • Funktionale und Nichtfunktionale Anforderungen
    • Muss- und Wunschkriterien
    • Aufwand-Nutzen-Analyse
    • Risikoanalyse
  • Verwendete Technologien und Entwicklungswerkzeuge festlegen
    • verwendete Programmiersprache(n)
    • verwendete API's
    • verwendete Bibliotheken
    • verwendete Tools z.B.: Versionierung, Wiki, Bugtracking usw.
  • Festlegung der internen Organisation der Gruppe
    • Rollenverteilung (Tutor ist kein Teammitglied sondern Auftraggeber)
    • Kommunikationswege
    • Gruppentreffen
Übersicht über die allgemeinen Entwurfsaufgaben:
  • Treffen und begründen grundlegender Entwurfsentscheidungen
  • Grobkonzept und grundlegenden Softwarearchitektur erstellen
    • Systemkomponenten festlegen, deren Struktur und grundlegendes Verhalten sowie deren Zuständigkeiten definieren
    • Schnittstellen der Komponenten festlegen, Beziehungen zwischen den Komponenten festlegen
    • UML-Modell der geplanten Softwarearchitektur erstellen

Vorgehensspezifische Aufgaben

  • Festlegung der Richtlinien, Werte und Prinzipien
  • Durchführung der ersten Iteration wie oben beschrieben
    • Realisierung erster Prototyp
  • Festlegung der Aufgaben für die nächste Iteration

Allgemeiner Inhalt der Reviewdokumente

Zentrales Ergebnis der Planungs- und Entwurfsphase ist das Pflichtenheft und die Erstellung des Grob- bzw. je nach Vorgehen auch die Ergebnisse des Feinentwurfs. Daraus ergeben sich zwei Hauptteile: 

  • Ergebnisse der Planung: Pflichtenheft
  • Ergebnisse des Entwurfs: Entwurfsdokumentation 

Die Reviewdokumente können als eigenständige Dokumente erstellt werden oder als ein gemeinsames Dokument. Folgenden Inhalt sollten die Teile des Review-Dokuments haben:

Ergebnisse der Planung
  • Pflichtenheft, separat oder integriert
    • Die Inhalte eines Pflichtenheftes sind hier beschrieben
  • Vorgehen innerhalb des Softwareprojektes
    • Beschreibung des gewählten Vorgehensmodells inklusive projektspezifischer Anpassungen des Vorgehens
    • Entwickelter Projektplan inklusive einer Abschätzung des Aufwands
    • Vorstellung der festgelegten Meilensteine
  • Interne Organisation der Gruppe
    • Beschreibung und Aufteilung der gewählten Rollen
    • Beschreibung der Kommunikationswege
    • Beschreibung weiterer organisatorischer Festlegungen wie z.B. Anzahl und Art der Gruppentreffen
Ergebnisse des Entwurfs
  • Anforderungsanalyse
  • Entwurfsalternativen und Entwurfsentscheidungen
  • Dokumentation des geplanten Entwurfs
    • Systemzerlegung 
      • Pakete, Komponenten, Schnittstellen, evtl. Klassenstruktur
      • Darstellung mit geeigneten Diagrammen
    • Abbildung auf HW/SW-Komponenten
    • Globaler Kontrollfluss 
    • Management persistenter Daten
    • evtl. verwendete Architekturmuster
  • Verwendete Technologien und Entwicklungswerkzeuge
    • Beschreibung der verwendeten Programmiersprache(n), Bibliotheken und API's
    • Beschreibung der verwendeten Entwicklungswerkzeuge wie Versionierung, Bugtracking, Wiki usw.

Vorgehensspezifische Reviewinhalte

  • Vorstellung der gewählten Richtlinien, Werte und Prinzipien
  • Festlegung der in der ersten Iteration zu realisierenden Anforderungen
  • Ergebnisse der ersten Iteration wie oben beschrieben
  • Festlegung der Aufgaben für die nächste Iteration

Allgemeiner Präsentationsinhalt

Im Folgenden werden einige mögliche Präsentationsinhalte für die Planungsphase vorgestellt:

  • Beschreibung der Aufgabe
    • Projekt und Systemumgebung
    • funktionale und nichtfunktionale Anforderungen, Randbedingungen
    • Analyse, Priorisierung und Klassifizierung der Anforderungen (Muss- und Kann-Anforderungen).
  • Ergebnisse der Anforderungsanalyse 
  • Vorstellung des Grobentwurfs (mittels geeigneter Diagramme)
    • Vorstellung grundlegender Entwurfsentscheidungen und eventueller Entwurfsalternativen
    • grundlegende Softwarearchitektur
      • Vorstellung grundlegender Systemkomponenten (Struktur, grundlegendes Verhalten, Zuständigkeiten)
      • Schnittstellen der Komponenten
      • Beziehungen zwischen den Komponenten
    • evtl. verwendete Architekturmuster
  • Verwendete Technologien und Entwicklungswerkzeuge
  • Auswahl, Begründung und Beschreibung des Vorgehens
  • Entwickelter Projektplan mit Aufwands- und Risikoabschätzung, sowie Meilensteinen
  • Interne Organisation der Gruppe
  • Stand des Projekts
  • Ausblick

 Vorgehensspezifische Präsentationsinhalte

  • Vorstellung der gewählten Richtlinien, Werte und Prinzipien
  • Vorstellung der in der ersten Iteration zu realisierenden Anforderungen
  • Vorstellung der ersten Ergebnisse (Prototyp)
    • nur sehr kurz, da die Software erst zur Abschlußpräsentation vorgestellt werden soll
  • Aufgaben für die nächste Iteration

Implementierung

2. Phase - Implementierung

Allgemeine Aufgaben

  • Implementierung des in den vorherigen Phasen geplanten Softwaresystems
  • Berücksichtigung aller Muss-Anforderungen
  • Entwicklerdokumentation erstellen (JavaDoc, Doxygen,... )
  • Stand des Projektes überprüfen

Vorgehensspezifische Aufgaben

  • Durchführung der zweiten Iteration wie oben beschrieben
  • Bugreview durchführen
    • Offene Anforderungen und Fehler auflisten und priorisieren
  • Festlegung der finalen Aufgaben für die letzte Iteration

Allgemeiner Inhalt der Reviewdokumente

Als Review-Dokumente sollen zwei Dokumente erstellt werden: 

  • Das Reviewdokument
  • Entwicklerdokumentation 

Das Reviewdokument des Entwurfs soll um wichtige Details des Feinentwurfs, wie z.B. die Dokumentation der Klassenstruktur erweitert werden. Auch sollen wichtige Entwurfsentscheidungen und Änderungen der Architektur dokumentiert werden. Folgenden Inhalt sollte das Reviewdokument besitzen:

  • Zweck des Systems, Entwurfsziele, Überblick (Teil des Pflichtenhefts)
  • Grundlegende Architektur / Grobentwurf (Teil des Entwurfsdokuments)
  • Dokumentation des realisierten Entwurfs
    • Darstellung und Beschreibung der realisierten Architektur mittels geeigneter Diagramme
    • evtl. verwendete Entwurfsmuster
    • Dokumentation der Problemlösung, Implementierungsentscheidungen und verwendeter Prinzipien
  • evtl. Überarbeitung des Entwurfs
    • Entscheidungen begründen
  • Schnittstellendokumentation
  • Akronyme und Abkürzungen, Glossar
  • Referenzen

Als zweites eigenständiges Dokument soll eine Entwicklerdokumentation erstellt werden. Diese kann aus den Kommentaren im Quelltext mit Hilfe entsprechender Tools (JavaDoc, Doxygen,...) generiert werden.

Vorgehensspezifische Reviewinhalte

  • Ergebnisse der zweiten Iteration wie oben beschrieben
  • Bugreview
    • Übersicht und Priorisierung offener Anforderungen und Fehler
  • Festlegung der finalen Aufgaben für die letzte Iteration

Allgemeiner Präsentationsinhalt

Den Schwerpunkt dieser Präsentation stellt die Implementierung dar. Das entstandene Programm soll erst in der Abschlussveranstaltung präsentiert werden. Daraus ergeben sich folgende Präsentationsinhalte:

  • Einleitung
    • Kurzbeschreibung der Aufgabe
    • Kurzbeschreibung des Grobentwurfs 
  • Vorstellung des Feinentwurfs
    • Vorstellung der Struktur und des Verhalten wichtiger Komponenten
    • wichtige Implementierungsalternativen und Entscheidungen
    • eventuelle Änderungen des Grobentwurfs
  • Beispielhafte Realisierung eines Implementierungsdetails
  • evtl. Integration verwendeter Entwurfsmuster
  • Stand des Projekts
  • Ausblick

 Vorgehensspezifische Präsentationsinhalte 

  • Ergebnisse der Iteration vorstellen
    • keine Produktpräsentation!
  • Vorstellen der Ergebnisse des Bug-Reviews
  • Aufgaben für die letzte Iteration Vorstellen

Validierung

3. Phase - Validierung

Allgemeine Aufgaben

  • Anwendung strukturiert testen
  • Fehler behandeln
  • Produktpräsentation erstellen
  • Finales Reviewdokument des gesamten Softwarepojektes erstellen
  • Benutzerhandbuch erstellen
  • Installation bzw. Installationsanleitung erstellen
  • Quelltext dem Betreuer übergeben 
  • Projekterfolg bewerten
  • Vorgehen bewerten

Vorgehensspezifische Aufgaben

  • Durchführung der finalen Iteration, wie oben beschrieben

Allgemeiner Inhalt der Reviewdokumente

Als Review-Dokumente sollen 3 Dokumente erstellt werden: 

  • Finales Reviewdokument des Gesamtprojektes
  • Benutzerhandbuch
  • Installationsanleitung / bzw. Installation

Die Dokumente können bei Bedarf miteinander kombiniert werden. Ausgangsdokument kann das Reviewdokument der Implementierung sein. Folgende Inhalte sollten im finalen Review-Dokument enthalten sein:

  • Zweck des Systems, Entwurfsziele, Überblick (Teil des Pflichtenhefts)
  • Grundlegende Architektur / Grobentwurf (Teil des Entwurfsdokuments)
  • Dokumentation des realisierten Entwurfs (Teil des Implementierungsdokuments)
  • Dokumentation der wichtigsten Testfälle
  • Nachweis funktionaler und nichtfunktionaler Eigenschaften (durch Vorstellung der Testergebnisse)
  • Bugreview (Anzahl offener Anforderungen und Fehler)
  • evtl. Softwaremetriken und weiterer Statistiken
  • Kritische Bewertung des Projekterfolgs
  • Kritische Bewertung des Vorgehens
  • Akronyme und Abkürzungen, Glossar
  • Referenzen
  • weiterer Anhang

Darüber hinaus soll ein Benutzerhandbuch erstellt werden, in dem die Funktionen und die Benutzeroberfläche der Software beschrieben wird.

Schließlich soll eine Installationsanleitung für das fertig entwickelte System erstellt werden.

Vorgehensspezifische Reviewinhalte

  • Ergebnisse der letzten Iteration

Vorgeschlagener Inhalt der Abschlusspräsentation

Ziel dieser Präsentation ist die Vorstellung des Ergebnisses des Softwareprojektes, also die Präsentation der laufenden Software. Wählen Sie eine für Ihr individuelles Softwareprojekt vorteilhafte/geeignete Demonstrationsart. Die vorgeschlagenen Inhalte sind für alle Vorgehen gleich.

  • Einleitung
    • Kurzbeschreibung der Aufgabe
    • Kurzbeschreibung der Lösung / der grundlegenden Architektur
  • Software demonstrieren (Oberfläche und Funktionen)
  • Zusammenfassung
    • Stand des Projekts
    • Ausblick für zukünftige Weiterentwicklungen
    • Kritische Bewertung des Projektes / des Vorgehens

Beispiele und Vorlagen

Einige Ergebnisse früherer Softwareprojekte sind hier zusammengefasst.

Als Beispiel eines objektorientierten Entwurfs dient folgender Ausschnitt aus der Diplomarbeit von [POE05]. Im Rahmen dieser Diplomarbeit wurde eine Steuerungssoftware für ein Messgerät zur Härteprüfung mit anschließender Auswertung der Analysedaten entwickelt. Während der Arbeit wurden die klassischen Phasen der Softwareentwicklung durchlaufen. Bitte beachten Sie, dass dies nur ein Beispiel ist und die Struktur in einer Diplomarbeit etwas anders als in einem Konzept ist. Als Vorlage empfehlen wir ebenfalls die Tex-Vorlage [BAUR07] des Pflichtenhefts.

Hier ein Beispiel aus einem vorangegangen Softwareprojekt: Flugplanoptimierung

Quellen und weiterführende Literatur

[SWT96]

 

Helmut Balzert, Lehrbuch der Software-Technik: Software Entwicklung, Spektrum, Akad., Verl, 1996, ISBN 3-8274-0042-2 (in der Uni-Bibliothek vorhanden)

[SWE01]

 

Ian Sommerville, Software Engineering, Pearson Studium, 2001, ISBN 3-8273-7001-9 (in der Uni-Bibliothek vorhanden)

[POE05]

 

Alexander Pölck, Konzeption und Implementierung eines Programmes zur Gerätesteuerung mit anschließender Auswertung von Analysedaten, Diplomarbeit, TU Ilmenau, 2005

[JBR99]Ivar Jacobson, Grady Booch, Jim Rumbaugh: Unified Software Development Process, Addison Wesley Longman, Inc., 1999, ISBN ISBN 0-201-57169-2
[OMG]www.omg.org
[UML]www.uml.org
[SCRUM]Ken Schwaber, Mike Beedle: Agile Software Development with Scrum. Prentice Hall, Upper Saddle River, 2001, ISBN 978-0130676344