1 / 16

Vorgehensweise bei der Software-Entwicklung des Publication Managers

Vorgehensweise bei der Software-Entwicklung des Publication Managers. Andreas Hense 1 . 0 Pilot en treffen 8. Juni 2006 Distribution: pilots Filename:. Revision History:. Agenda. Vorgehensmodelle Fachliche Spezifikation mit Use Cases Iterative Vorgehensweise. Vorgehensmodelle.

adelle
Download Presentation

Vorgehensweise bei der Software-Entwicklung des Publication Managers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Vorgehensweise bei der Software-Entwicklungdes Publication Managers Andreas Hense 1.0 Pilotentreffen 8. Juni 2006 Distribution: pilots Filename: Revision History:

  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. 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. 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:

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

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

More Related