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?