Vorgehensweise bei der Software-Entwicklung des Publication Managers
16
M A X - P L A N C K - G E S E L L S C H A F T 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
description
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. - PowerPoint PPT Presentation
Transcript of Vorgehensweise bei der Software-Entwicklung des Publication Managers
M A X - P L A N C K - G E S E L L S C H A F T
Vorgehensweise bei der Software-Entwicklungdes Publication Managers
Vorgehensweise bei der Software-Entwicklungdes Publication Managers
Andreas Hense
1.0
Pilotentreffen 8. Juni 2006
Distribution: pilots
Filename:
Revision History:
Version Date Author Comment
M A X - P L A N C K - G E S E L L S C H A F T2 Filename, last changed: dd.mm.yyyy
AgendaAgenda
1) Vorgehensmodelle
2) Fachliche Spezifikation mit Use Cases
3) Iterative Vorgehensweise
M A X - P L A N C K - G E S E L L S C H A F T3 Filename, last changed: dd.mm.yyyy
VorgehensmodelleVorgehensmodelle
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:
M A X - P L A N C K - G E S E L L S C H A F T4 Filename, last changed: dd.mm.yyyy
Vorgehensweise im IT-Projekt nach V-Modell XTVorgehensweise im IT-Projekt nach V-Modell XT
Projektabgeschlossen
Projektbeauftragt
Abnahmeerfolgt
Anforderungenfestgelegt
Systemelementerealisiert
Änderungsplanfestgelegt
Projektgenehmigt
Projektausgeschrieben
Angebotabgegeben
Systemspezifiziert
Systementworfen
Feinentwurfabgeschlossen
Systemintegriert
Lieferungdurchgeführt
VerbesserungVorgehensmodell konzipiert
VerbesserungVorgehensmodell realisiert
Vorgehensmodellanalysiert
Projektdefiniert
Systementwicklungsprojekt einesAuftraggebers
Systementwicklungsprojekt einesAuftragnehmers
Einführung und Pflege einesorganisationsspezifischen
Vorgehensmodells
Zuordnung derEntscheidungspunkte zu
Projekttypen Entscheidungspunkte für die Projekttypen: Systementwicklungsprojekt eines Auftraggebers Systementwicklungsprojekt eines Auftragnehmers Einführung und Pflege eines
organisationsspezifischen Vorgehensmodells
Im Projekt bereits erledigt
M A X - P L A N C K - G E S E L L S C H A F T5 Filename, last changed: dd.mm.yyyy
Fachliche SpezifikationFachliche 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.
M A X - P L A N C K - G E S E L L S C H A F T6 Filename, last changed: dd.mm.yyyy
Use CasesUse 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?
M A X - P L A N C K - G E S E L L S C H A F T7 Filename, last changed: dd.mm.yyyy
ErgebnisseErgebnisse
Use Case Diagramm
Use Case Spezifikation
Storyboards
M A X - P L A N C K - G E S E L L S C H A F T8 Filename, last changed: dd.mm.yyyy
Beispiel Use Case DiagrammBeispiel Use Case Diagramm
Registered user
select items for a basket
save items to a basket
delete items from a basket
edit basket properties
merge baskets
delete baskets
copy a basket
export a basket
open a basket link
view basket content
send basket links
M A X - P L A N C K - G E S E L L S C H A F T9 Filename, last changed: dd.mm.yyyy
Restrukturierung von Use CasesRestrukturierung von Use Cases
Komplexe Use Cases werden aufgeteilt:
Teile werden ausgegliedert:
Ingest Administrator Ingest Administrator
manage ingestion tasks
abort ingestion task
cancel ingestion task
delete ingestion task
resume ingestion task
Catalog Administrator
define catalog refine workflow for catalog
<<include>>
M A X - P L A N C K - G E S E L L S C H A F T10 Filename, last changed: dd.mm.yyyy
Restrukturierung von Use Cases (Forts.)Restrukturierung von Use Cases (Forts.)
Identifikation von Gemeinsamen Teilen:
Depositor
start ingestion task in SAIR
ingest data from file<<secondary>><<include>>
Ingest Administrator
start ingestion task <<include>>
M A X - P L A N C K - G E S E L L S C H A F T11 Filename, last changed: dd.mm.yyyy
Use Case SpezifikationUse 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
M A X - P L A N C K - G E S E L L S C H A F T12 Filename, last changed: dd.mm.yyyy
StoryboardsStoryboards
Was ist ein Storyboard?
Visualisierung der logischen Abfolge von Handlungen.
Erster Eindruck Benutzerführung
Noch keine GUI-Elemente wie Radio Buttons, Check Boxes etc.
M A X - P L A N C K - G E S E L L S C H A F T13 Filename, last changed: dd.mm.yyyy
Search / Browsing result view
SB_UC_PM_WB_01
1.
2.-4.
Item n + 1
Item n + 2
…
Item m
Add to basketAdd selected
Add current page
Add all resultsSearch / Browsing result view
Item n + 1
Item n + 2
…
Item m
Add to basketAdd selected
Add current page
Add all results
2 items have been added to thetemporary basket.
M A X - P L A N C K - G E S E L L S C H A F T14 Filename, last changed: dd.mm.yyyy
Iterative VorgehensweiseIterative 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:
M A X - P L A N C K - G E S E L L S C H A F T15 Filename, last changed: dd.mm.yyyy
Just in Time UC Validierung Just in Time UC Validierung
Setup development
Validierung UC Rel 0.1
Validierung UCRel 0.5
Validierung UCRel 0.3
Design
Build
Test
Deploy
Rel. 0.1
Design
Build
Test
Deploy
Rel. 0.3
Design
Build
Rel. 0.5
……
System DesignFW
Rel 0.1
FWRel 0.3
Feedback Piloten Rel. 0.1
Feedback Piloten Rel. 0.3
SMC & ZIMSMCZIMFIZ
Legende
M A X - P L A N C K - G E S E L L S C H A F T16 Filename, last changed: dd.mm.yyyy
Vielen Dank!Vielen Dank!
Andreas Hense
089/3299-1552 (München)
02241/865-239 (Bonn)
Fragen?
