Der Erfolg von Softwareentwicklungsprojekten hängt maßgeblich von einer guten Anforderungsanalyse ab. Je später Konzeptionsfehler erkannt werden, desto höher sind die Kosten der erforderlichen Korrekturen. Wir stellen in diesem Vortrag dar, wie durch eine strukturierte und dabei nicht zu formale Vorgehensweise frühzeitig sichergestellt werden kann, dass die später entwickelte Anwendung den Wünschen des Auftraggebers entspricht und zudem eine verlässliche Basis für die Einschätzung des Entwicklungsaufwands entsteht. Im Vortrag verdeutlichen wir die Vorgehensweise an dem Beispiel einer Konzeption eines Systems zur Betriebsdatenerfassung und Leistungsentlohnung. Mit einem Mix aus Office- und UML-Werkzeugen konnte hier in kurzer Zeit ein gemeinsames Verständnis mit der Fachabteilung des Kunden erreicht werden und die formale Basis für die nachfolgende Realisierung des Systems geschaffen werden. Auswahl von Werkzeugen aus dem Office- und Modellierungsumfeld Halbformale Beschreibung von Anwendungsfällen Erstellung eines fachlichen und technischen Glossars Komponentenmodellierung mit UML Entwicklung eines Anwendungs-Prototyps

1. g GFU Cyrus AG
Ihr Partner für IT Schulung
"Semicolon" Vortragsreihe bei der GFU
Vortrag am Dienstag, 4. November 2008
Thema
Professionelle Anforderungsanalyse
am Beispiel einer Java-Anwendung zur Betriebsdatenerfassung und
Leistungsentlohnung
Einführung
Peter Hecker, GFU Cyrus AG
Vortrag
Dirk Weil, Geschäftsführer GEDOPLAN

2. Entwicklung von Informationssystemen
29 Jahre am Markt
~35 Mitarbeiter
Beratung und Entwicklung
Konventionelle und GEDOPLAN
neue Technologien
Objektorientierte
Maßgeschneiderte Lösungen Softwareentwicklung
Standardsoftware
www.gedoplan.de SAP®
SOA Java .NET

3. Seit 1998 im Bereich Java:
50+ Beratungs- und Entwicklungsprojekte
Konzeption und Entwicklung
30+ Seminartitel
Java / Java EE
GEDOPLAN
Diverse App.-Server Objektorientierte
Glassfish Softwareentwicklung
IBM WebSphere
JBoss SAP®
Oracle WebLogic Java
SAP NetWeaver
SOA .NET

4. IT-Systeme und Prozesse
Beratung, Schulung, Entwicklung
100+ Mitarbeiter
www.involva-gruppe.de

8. Aufgabe: Entwicklung eines BDE-Systems
Walzstrasse
Endkontrolle Betriebsdaten
Säge Betriebsdaten
- Gutmenge
- Fertigungszeit
Betriebsdaten
- Gutmenge
- Störzeit
- Fertigungszeit
- Gutmenge
- Gewichte
- Störzeit
- Fertigungszeit
Instandhaltung - Chargennummern
- Gewichte
- Störzeit
Presse - … Chargennummern
- - Gewichte
- … Chargennummern
-
-…
Werkzeug-
fertigung

9. Aufgabe: Entwicklung eines BDE-Systems
Controlling
Produktions-
Betriebsdaten planung
Betriebsdaten
- Gutmenge
- Fertigungszeit
Betriebsdaten
- Gutmenge
- Störzeit
- Fertigungszeit
- Gutmenge
- Gewichte
- Störzeit
- Fertigungszeit
- Chargennummern
- Gewichte
- Störzeit
- … Chargennummern
- - Gewichte
- … Chargennummern
-
-…
Prämien-
lohn-
ermittlung Personal-
wirtschaft

10. Professionelle Softwareanforderungsanalyse

11. Ausgangssituation
Beginn eines Softwareprojektes
Wir wissen nicht (genau), was der Kunde wünscht
Der Kunde weiß es – auch nicht!
Los!

12. Ziele der Anforderungsanalyse
Was?
Wünsche klären
Zusammenhänge und Abhängigkeiten aufdecken
Sinnhaftigkeit verifizieren
Machbarkeit sicher stellen

13. Ziele der Anforderungsanalyse
Wie?
Benutzerinterface skizzieren
Komponenten identifizieren
Komplexität darstellen
Basis für Aufwandsschätzung erstellen

14. Systemkontext
Beschreibt die Umgebung des
geplanten Systems
Akteure
Fremdsysteme
Schnittstellen

15. Use Cases als zentrale Analyseelemente
Perfor- UI Anfor-
mance derungen
UI
Security Design
Use
Daten-
Cases Business-
formate regeln
I/O
Protokolle …

16. Use Cases
Beschreiben Interaktion zwischen Akteur und System
Haben einen Auslöser und ein Ziel
Benutzersicht
Unterschiedliche Granularitäten

17. Use Cases
Alistair Cockburn: Use Cases effektiv erstellen.
Werkzeug: Word (o.ä.)!
einfach
allgegenwärtig
Integration mit anderen Tools
Halbformale Struktur

18. Use Cases

19. Use Cases
Formalität
zwanglos (casual)
ausformuliert (fully dressed)
Umfeld
(Context of Use)
Bereich (Scope)
Unternehmen
System
Subsystem

20. Use Cases
Beschreibung
Ebene (Level)
Akteure (Actors)
Interessenten (Stakeholders)

21. Use Cases
Invarianzen
Vorbedingungen
(Preconditions)
Minimales/Erfolgsergebnis (Minimal/Success Guarantee)
Detailbeschreibung
Auslöser (Trigger)
Haupt-Erfolgsszenario
(Main Success Scenario)
Erweiterungen
(Extensions)

22. Use Cases
Ergänzende Informationen
Technische Variationen (Technology & Data Variations List)
Zusätzliche Informationen (Related Information)

23. Use Cases
Jeder Use Case muss einfach zu lesen sein
Ein-Satz-Anweisungen bei den einzelnen Schritten
(Aktiv, kein Passiv verwenden)
Große Komplexität auf Unter-UCs verteilen
Immer Akteur nennen
Immer das Ziel nennen
auf welchem Level sind wir?
wo sind die Benutzerziele auf „Meeresspiegel-Ebene“?

24. Use Cases
Immer – neben dem primären Akteur und seinem Ziel – die
Garantien für weitere Interessenten berücksichtigen
Vorbedingungen festhalten
(Kandidaten: Ergebnis eines höheren/vorherigen UseCase!)
Immer zuerst das Haupt-Erfolgsszenario beschreiben, danach alle
Fehler-Szenarien / Ausnahmen / Variationen
GUI maximal als weitere Information beschreiben

25. Strukturierung der Use Cases mittels Mind Maps
Bilden logischer Gruppen
Gesamtüberblick
Identifizierung kritischer UCs
Offene Fragen
Klärungsbedarf / Widersprüche
Erfassungsfortschritt
Reviewstand

26. Strukturierung der Use Cases mittels Mind Maps

27. Anforderungsdokumente
Use Cases sind Anforderungsdokumente
weitere formelle Umwandlung sollte nicht nötig sein
Use Cases definieren nicht alle Anforderungen
externe Schnittstellen
Datenformate
Business-Regeln
komplexe Formeln

28. In/Out-Liste
Festhalten, was zur Aufgabe gehört und was nicht

29. Glossar
Verbindliche Definition fachlicher und technischer Begriffe

30. Use Cases mittels UML modellieren
Erfassen und Verlinken der Use Cases
Erfassen und Zuordnen der Akteure
mögliche Alternative:
Erfassung der Use Cases in UML-
Tool statt in Word etc.
technisch komplexer,
Review/Export aufwendiger

31. Use Cases mittels UML modellieren
Ergebnis:
alle Akteure und Use Cases in einem
(oder mehreren) Use-Case-
Diagrammen erfasst

32. Analyse-Komponenten mittels UML modellieren
Auf Basis der Use Cases und weiterer Anforderungen aus dem
Pflichtenheft:
Entitäten identifizieren
Attribute und Operationen identifizieren
Komponenten bilden
Entitäten und darauf operierende Services zu Komponenten
zusammenfassen
Service-Schnittstellen definieren
Komponenten hierarchisch strukturieren

33. Analyse-Komponenten mittels UML modellieren
Pro Komponente:
Komponentenstruktur
Anwendungsfall-Abdeckung
Domänenmodell
Gesamtarchitektur als Hierarchie
der Komponenten erstellen

34. Analyse-Komponenten mittels UML modellieren
Komponentenstruktur
angebotene Services einer
Komponente darstellen
Abhängigkeiten
zwischen den Komponenten
darstellen

35. Analyse-Komponenten mittels UML modellieren
Anwendungsfall-Abdeckung festhalten
in welchen Use Cases wird die Komponente verwendet?
uc Anw endungsfälle RapportscheinMg...
UC-046 UC-047
Rapportschein Rapportscheine
abschließen freigeben
Vorgesetzter (aufgrund
1. Mann
AP)
UC-045 UC-044
Rapportschein Rapportschein
korrigieren anzeigen
UC-049
Rapportschein
plausibilisieren
Leistungslohnermittlung
UC-071 Export
Rapportscheine UC-055
Leistungslohnberechnung

36. Analyse-Komponenten mittels UML modellieren
Domänenmodell erstellen

37. Analyse-Komponenten mittels UML modellieren
Jede Klasse, jedes Attribut, jede Relation fachlich dokumentieren
und kommentieren
Per Template aus dem Modell vollständige
Komponentenbeschreibung generieren
Bestandteile des Pflichtenheftes (u.a.):
Beschreibung des Systems in Form von UseCases
Entstandenes Analyse-Modell in Form der generierten
Komponentenbeschreibung

38. GUI-Prototyp

39. Eingliederung in den Requirements-Rahmen
Funktionale Anforderungen
Glossar
UI-Anforderungen
Nichtfunktionale Anforderungen
Benutzermodell und Berechtigungskonzept
Systemarchitektur, Komponentenbeschreibung
Hard- und Software-Infrastruktur

40. Unsere Erfahrungen: Use Cases
Einfacher Start mit Überblicks-Use-Cases
(Tagesablauf eines typischen Mitarbeiters o.ä.)
Use Cases können zum Prototyping genutzt werden
Word als Use-Case-Tool
Einfaches, allseitig akzeptiertes Format
Bietet viele Freiheitsgrade
Markierungen (z.B. für offene Punkte)
Diagramme, Images (z.B. zur Verdeutlichung)
Verknüpfungen, Hyperlinks
Review, formale Abnahme nicht unproblematisch

41. Unsere Erfahrungen: Komponentenmodellierung
UML-Tools bieten unterschiedlich tiefe Unterstützung
UML-Diagramme reichen
Dokumentengenerierung sehr hilfreich
Codegenerierung problematisch
Gute Strukturierung der Software
zur Visualisierung / Dokumentation
zur Abschätzung des Realisierungsaufwandes

42. Danke für Ihre Aufmerksamkeit!
Haben Sie Fragen?