Vorgehensweise bei der Software-Entwicklung des Publication Managers

Präsentation zum Thema: "Vorgehensweise bei der Software-Entwicklung des Publication Managers"—  Präsentation transkript:

1 Vorgehensweise bei der Software-Entwicklung des Publication Managers
Andreas Hense 1.0 Pilotentreffen 8. Juni 2006 Distribution: pilots Filename: Revision History: Version Date Author Comment

2 Agenda Vorgehensmodelle Fachliche Spezifikation mit Use Cases
Iterative Vorgehensweise

3 Vorgehensmodelle Die Entwicklung von großen Software-Systemen ist eine komplexe Aufgabe. Im Laufe der Zeit haben sich sogenannte Vorgehensmodelle entwickelt, die versuchen, die tatsächlich in einem Software-Projekt ablaufenden Tätigkeiten strukturiert und abstrahiert darzustellen. Zu den einfacheren gehören das Wasserfallmodell und das Spiralmodell. Näher an der Wirklichkeit ist das V-Modell XT:

4 Vorgehensweise im IT-Projekt nach V-Modell XT
Entscheidungspunkte für die Projekttypen: Systementwicklungsprojekt eines Auftraggebers Systementwicklungsprojekt eines Auftragnehmers Einführung und Pflege eines organisationsspezifischen Vorgehensmodells Im Projekt bereits erledigt

5 Fachliche Spezifikation
Die fachliche Spezifikation erfolgt im Projekt eSciDoc in zwei Stufen: Usage Scenarios und Konzepte: gesamtheitliche funktionale Beschreibung der Anforderungen aus reiner Anwendersicht. Use Cases: Standardisierte Methode zur Beschreibung von detaillierten funktionalen Anforderungen an ein System. Diese sind sowohl für funktionale Experten als auch für Software-Entwickler verständlich. Es gibt zudem eine Reihe von nichtfunktionalen Anforderungen wie z. B. Verfügbarkeit, Performance, auf die hier nicht näher eingegangen werden soll.

6 Use Cases Ein Use Case ist eine Folge von Interaktionen zwischen einem Akteur und dem System, um eine spezifische Aufgabe zu lösen. Ein Akteur ist etwas oder jemand außerhalb des Systems, welches mit dem System interagiert. Wie werden Use Cases identifiziert? Fragen: Was will der Nutzer erreichen? Was benötigt er/sie/es dazu? Welches sind die Hauptaufgaben eines Nutzers in einer spezifischen Rolle?

7 Use Case Spezifikation
Ergebnisse Use Case Diagramm Use Case Spezifikation Storyboards

8 Beispiel Use Case Diagramm

9 Restrukturierung von Use Cases
Komplexe Use Cases werden aufgeteilt: Teile werden ausgegliedert:

10 Restrukturierung von Use Cases (Forts.)
Identifikation von Gemeinsamen Teilen:

11 Use Case Spezifikation
Textuelle Beschreibung der Interaktionen zwischen dem Akteur und dem System. Geschrieben in der Sprache der fachlichen Experten. Implementierungsspezifische Sprache oder technische Termini werden vermieden. Struktur: Use case ID and name Description – short overview Trigger – why is the use case started Actors – who triggers this use case (user, user role, etc.) Pre-Conditions – pre-conditions that should be fulfilled before the use case starts Flow of Events – ordered actions of the actor and the system Post-Conditions / Results – States the system or objects are in when the use case ends Alternatives – alternate course of events under certain condition Open Issues – questions

12 Storyboards Was ist ein Storyboard? Visualisierung der logischen Abfolge von Handlungen. Erster Eindruck Benutzerführung Noch keine GUI-Elemente wie Radio Buttons, Check Boxes etc.

13

14 Iterative Vorgehensweise
Bei der Entwicklung des eSciDoc-Publication-Managers wird iterativ vorgegangen. Dies bedeutet, dass nach einer ersten Lieferung eines fachlichen Prototyps weitere Lieferungen bis zur Abnahme folgen. Eine Besonderheit in diesem Projekt ist die Tatsache, dass das sogenannte Framework gleichzeitig von einem anderen Hersteller entwickelt wird und mit der Anwendung eSciDoc-Publication-Manager jeweils integriert werden muss. Zwischen zwei Lieferungen finden fachliche Tests statt:

15 Just in Time UC Validierung
Design Build Test Deploy Rel. 0.1 Legende Setup development SMC & ZIM System Design SMC ZIM FW Rel 0.1 Validierung UC Rel 0.1 FIZ Feedback Piloten Rel. 0.1 Validierung UC Rel 0.3 Design Build Test Deploy Rel. 0.3 FW Rel 0.3 Feedback Piloten Rel. 0.3 Validierung UC Rel 0.5 Design Build Rel. 0.5 ……

16 Fragen? Vielen Dank! Andreas Hense a.hense@zim.mpg.de
089/ (München) 02241/ (Bonn)