Ihr Partner für IT Schulungg GFU Cyrus AG
"Semicolon" Vortragsreihe bei der GFU
Vortrag am Dienstag, 4. November 2008
Thema
Professionelle Anforderungsanalyseam Beispiel einer Java-Anwendung zur Betriebsdatenerfassung und
Leistungsentlohnung
Einführung
Peter Hecker, GFU Cyrus AG
Vortrag
Dirk Weil, Geschäftsführer GEDOPLAN
Entwicklung von Informationssystemen
29 Jahre am Markt
~35 MitarbeiterBeratung und Entwicklung
Konventionelle undneue Technologien
Maßgeschneiderte Lösungen
Standardsoftware
www.gedoplan.de
SOA Java .NET
SAP®
GEDOPLANObjektorientierte
Softwareentwicklung
Seit 1998 im Bereich Java:50+ Beratungs- und Entwicklungsprojekte
Konzeption und Entwicklung
30+ Seminartitel
Java / Java EE
Diverse App.-ServerGlassfish
IBM WebSphere
JBoss
Oracle WebLogic
SAP NetWeaverSOA .NET
SAP®
GEDOPLANObjektorientierte
Softwareentwicklung
Java
IT-Systeme und Prozesse
Beratung, Schulung, Entwicklung
100+ Mitarbeiter
www.involva-gruppe.de
Aufgabe: Entwicklung eines BDE-Systems
Walzstrasse
Säge
Presse
Endkontrolle
Werkzeug-fertigung
Instandhaltung
Betriebsdaten- Gutmenge- Fertigungszeit- Störzeit- Gewichte- Chargennummern- …
Betriebsdaten- Gutmenge- Fertigungszeit- Störzeit- Gewichte- Chargennummern- …
Betriebsdaten- Gutmenge- Fertigungszeit- Störzeit- Gewichte- Chargennummern- …
Aufgabe: Entwicklung eines BDE-Systems
Betriebsdaten- Gutmenge- Fertigungszeit- Störzeit- Gewichte- Chargennummern- …
Betriebsdaten- Gutmenge- Fertigungszeit- Störzeit- Gewichte- Chargennummern- …
Betriebsdaten- Gutmenge- Fertigungszeit- Störzeit- Gewichte- Chargennummern- …
Controlling
Produktions-planung
Personal-wirtschaft
Prämien-lohn-
ermittlung
Professionelle Softwareanforderungsanalyse
Ausgangssituation
Beginn eines Softwareprojektes
Wir wissen nicht (genau), was der Kunde wünscht
Der Kunde weiß es – auch nicht!
Los!
Ziele der Anforderungsanalyse
Was?
Wünsche klären
Zusammenhänge und Abhängigkeiten aufdecken
Sinnhaftigkeit verifizieren
Machbarkeit sicher stellen
Ziele der Anforderungsanalyse
Wie?
Benutzerinterface skizzieren
Komponenten identifizieren
Komplexität darstellen
Basis für Aufwandsschätzung erstellen
Systemkontext
Beschreibt die Umgebung des geplanten Systems
Akteure
Fremdsysteme
Schnittstellen
Use Cases als zentrale Analyseelemente
Daten-formate
I/OProtokolle
Security
Business-regeln
UIDesign
…
UI Anfor-derungen
Perfor-mance
UseUse
CasesCases
Use Cases
Beschreiben Interaktion zwischen Akteur und System
Haben einen Auslöser und ein Ziel
Benutzersicht
Unterschiedliche Granularitäten
Use Cases
Alistair Cockburn: Use Cases effektiv erstellen.
Werkzeug: Word (o.ä.)!
einfach
allgegenwärtig
Integration mit anderen Tools
Halbformale Struktur
Use Cases
Use Cases
Formalitätzwanglos (casual)ausformuliert (fully dressed)
Umfeld(Context of Use)
Bereich (Scope)UnternehmenSystemSubsystem
Use Cases
Beschreibung
Ebene (Level)
Akteure (Actors)
Interessenten (Stakeholders)
Use Cases
Invarianzen
Vorbedingungen(Preconditions)
Minimales/Erfolgsergebnis (Minimal/Success Guarantee)
Detailbeschreibung
Auslöser (Trigger)
Haupt-Erfolgsszenario(Main Success Scenario)
Erweiterungen(Extensions)
Use Cases
Ergänzende Informationen
Technische Variationen (Technology & Data Variations List)
Zusätzliche Informationen (Related Information)
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“?
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
Strukturierung der Use Cases mittels Mind Maps
Bilden logischer Gruppen
Gesamtüberblick
Identifizierung kritischer UCs
Offene Fragen
Klärungsbedarf / Widersprüche
Erfassungsfortschritt
Reviewstand
Strukturierung der Use Cases mittels Mind Maps
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
In/Out-Liste
Festhalten, was zur Aufgabe gehört und was nicht
Glossar
Verbindliche Definition fachlicher und technischer Begriffe
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
Use Cases mittels UML modellieren
Ergebnis: alle Akteure und Use Cases in einem (oder mehreren) Use-Case-Diagrammen erfasst
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
Analyse-Komponenten mittels UML modellieren
Pro Komponente:
Komponentenstruktur
Anwendungsfall-Abdeckung
Domänenmodell
Gesamtarchitektur als Hierarchie der Komponenten erstellen
Analyse-Komponenten mittels UML modellieren
Komponentenstruktur
angebotene Services einer Komponente darstellen
Abhängigkeiten zwischen den Komponenten darstellen
Analyse-Komponenten mittels UML modellieren
Anwendungsfall-Abdeckung festhalten
in welchen Use Cases wird die Komponente verwendet?uc Anwendungsfälle RapportscheinMg...
UC-044 Rapportschein
anzeigen
UC-045 Rapportschein
korrigieren
UC-046 Rapportschein
abschließen
UC-047 Rapportscheine
freigeben
UC-049 Rapportschein plausibilisieren
1. MannVorgesetzter (aufgrund
AP)
Leistungslohnermittlung
UC-055 Leistungslohnberechnung
UC-071 Export Rapportscheine
Analyse-Komponenten mittels UML modellieren
Domänenmodell erstellen
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
GUI-Prototyp
Eingliederung in den Requirements-Rahmen
Funktionale Anforderungen
Glossar
UI-Anforderungen
Nichtfunktionale Anforderungen
Benutzermodell und Berechtigungskonzept
Systemarchitektur, Komponentenbeschreibung
Hard- und Software-Infrastruktur
Unsere Erfahrungen: Use Cases
Einfacher Start mit Überblicks-Use-Cases(Tagesablauf eines typischen Mitarbeiters o.ä.)Use Cases können zum Prototyping genutzt werdenWord als Use-Case-Tool
Einfaches, allseitig akzeptiertes FormatBietet viele FreiheitsgradeMarkierungen (z.B. für offene Punkte)Diagramme, Images (z.B. zur Verdeutlichung)Verknüpfungen, Hyperlinks
Review, formale Abnahme nicht unproblematisch
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
Danke für Ihre Aufmerksamkeit!
Haben Sie Fragen?
Top Related