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

Agenda Vorgehensmodelle Fachliche Spezifikation mit Use Cases Iterative Vorgehensweise

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:

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

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.

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?

Use Case Spezifikation Ergebnisse Use Case Diagramm Use Case Spezifikation Storyboards

Beispiel Use Case Diagramm

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

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

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

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.

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:

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 ……

Fragen? Vielen Dank! Andreas Hense a.hense@zim.mpg.de 089/3299-1552 (München) 02241/865-239 (Bonn)