Agile Geschäftsprozeßanalyse OOA/D am Beispiel einer Seminarverwaltung

Vortrag am Dienstag, 10. März 2009

Thema

Agile Geschäftsprozeßanalyse (GPA),
objektorientierte Analyse & Design (OOA/D)
am Beispiel einer Seminarverwaltung
Referent
Dr. Frank Dopatka, GFU Cyrus AG

Inhalt
• Das Fallbeispiel der GFU („Ist-Zustand bis 2008“)
• GPA/OOA:
Story Cards, Use Cases, Aktivitäten, Objekte & Klassen,
CRC-Karten, Risk/Value-Priorisierung, Planning Poker
• OOD:
Klassen-, Zustands- & Sequenz-Diagramme
• OOP:
Test Driven Development, Feature Driven Development,
Scrum, Pair-Programming, Continous Integration
• Der ideale Kunde & der ideale Programmierer

Ziel ist eine Übersicht über alle Notationen/Verfahren
& deren Verzahnung zu erkennen!

Das Fallbeispiel

Was existierte bislang?
_____INHALT_____

Fallbeispiel
Die GFU Cyrus AG verwendete
GPA / OOA
- Story Cards
- Use Cases
von 1988 bis Ende 2008
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker
ein in Cobol selbst geschriebenes Programm zur
OOD • Verwaltung der Kunden,
- Klassen
- Zustände
- Sequenzen
• deren Ansprechpartner und zur
OOP • Dokumentation der Kommunikation von
- TDD & FDD
- Scrum GFU-Mitarbeitern mit den Kunden (Vorgänge).
- Pair Programming
- Cont. Integration • Auch zur Fakturierung verwendet.
Der ideale Kunde &
Programmierer • Über eine Kalenderfunktion wurden die
Seminare, Anmeldungen von Teilnehmern,
Hotel- & Parkplatzbelegung verwaltet.

Dr. rer. nat. Frank Dopatka
FrankDopatka@web.de Folie 4

Was existierte bislang?
_____INHALT_____

Fallbeispiel
• Angebote:
GPA / OOA
in den letzten Jahren in MS Word 97 erstellt
- Story Cards
- Use Cases
- Aktivitäten • Zusätzlich:
- Objekte & Klassen
- CRC-Karten 8 Jahre altes Programm zur Seminar-
- Risk/Value+Poker
verwaltung, das in VB6 geschrieben wurde
OOD
- Klassen  Abgleich mit den Internet-Daten
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


So sah die
Kundenverwaltung & Fakturierung aus...
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


So sah die
Seminarverwaltung aus...
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Was soll verbessert werden?
_____INHALT_____

Fallbeispiel
• Das Cobol-Programm berechnet ab 2009 die
GPA / OOA
Kalenderwochen falsch, eine Anpassung ist
- Story Cards
- Use Cases
„schwierig“ im Quellcode durchzuführen.
- Aktivitäten
- Objekte & Klassen • Die Fakturierung soll automatisiert werden.
- CRC-Karten
- Risk/Value+Poker • Da keine relat. DB-Struktur verwendet wurde,
OOD
- Klassen
waren Statistiken über Kurserfolge schwierig,
- Zustände
- Sequenzen
z.B. Gewinn aus Schulungen der Kategorie „Java“
OOP
ermitteln.
- TDD & FDD
- Scrum
• Es sind im Cobol-Programm alte Funktionen
- Pair Programming
- Cont. Integration
vorhanden, die nicht mehr verwendet werden, u.a.
Der ideale Kunde &
- Verwaltung von Lizenznummern und
Programmierer
- Verwaltung von Update-Abos
...aus Zeiten, in denen bei der GFU noch
Cobol-Compiler verkauft wurden.


Was wird im Vortrag behandelt?
_____INHALT_____

Fallbeispiel
Im Folgenden wird exemplarisch gezeigt, wie man mit
GPA / OOA • einer Geschäftsprozeß-Analyse (GPA)
- Story Cards
- Use Cases • einer Objektorientierten Alalyse (OOA) und
- Aktivitäten
- Objekte & Klassen • einem Objektorientierten Design (OOD)
- CRC-Karten
- Risk/Value+Poker einen Lösungsansatz für die zu erstellende Software
OOD
- Klassen
ermitteln kann.
- Zustände
- Sequenzen Im Fokus steht dabei
OOP
- TDD & FDD
• der Zusammenhang der verschiedenen
- Scrum
- Pair Programming
UML-Diagramme, deren Blickwinkel sowie
- Cont. Integration
• die Anwendung agiler Methoden bei der
Der ideale Kunde &
Programmierer
Softwareentwicklung.


GPA & Story Cards

Was macht man in der GPA & OOA?
_____INHALT_____

Fallbeispiel
• In der Analyse geht es darum, die Anforderungen
GPA / OOA
zu erfassen:
- Story Cards
- Use Cases
Fakten sammeln, darstellen, prüfen
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker
 Objektorientierte Analysemodell:
OOD
- fachliche Beschreibung mit OO-Konzepten
- Klassen
- Zustände
- hebt das Wesentliche hervor und lässt
- Sequenzen Unwichtiges weg
OOP
- TDD & FDD
- Scrum
- Pair Programming
• Bezug zur Informationstechnik ist
- Cont. Integration unerwünscht!
Der ideale Kunde &
Programmierer
• OOA-Modell sollte statische & dynamische
Aspekte enthalten ( Datenstrukturen & Abläufe)


Was sind Story Cards?
_____INHALT_____

Fallbeispiel
• User Story („Benutzergeschichte“):
GPA / OOA
- eine in Alltagssprache formulierte Software-
- Story Cards
- Use Cases
Anforderung
- Aktivitäten
- Objekte & Klassen
- bewusst kurz gehalten: nicht mehr als zwei Sätze
- CRC-Karten
- Risk/Value+Poker

OOD
• Jede User Story wird auf eine Story Card
- Klassen
- Zustände
geschrieben. Autor: Kunde bzw. User
- Sequenzen

OOP
- TDD & FDD
• Die Story Card ist die wichtigste Methode, um ein
- Scrum
- Pair Programming
agiles Projekt zu steuern!
- Cont. Integration

Der ideale Kunde &
Programmierer
• Aus den Story Cards entwickeln sich in
kooperativer Zusammenarbeit mit dem Kunden
die Use Cases  Workshops


Inhalt einer Story Card
_____INHALT_____

Fallbeispiel
 Datum, fortlaufende Nummer
GPA / OOA
 Nummer der übergeordneten Story Card
- Story Cards
- Use Cases
 Aktivität: neu / Fehler beheben / Funktion erweitern
- Aktivitäten
- Objekte & Klassen
 Funktion umgesetzt
- CRC-Karten
- Risk/Value+Poker

OOD
 Priorität (Kunde/Programmierer)
- Klassen
- Zustände
 Risiko & Aufwandschätzung
- Sequenzen

OOP
- TDD & FDD
 kurze, präzise Beschreibung
- Scrum
- Pair Programming
 Notizen
- Cont. Integration

Der ideale Kunde &
Programmierer
 aktueller Fortschritt:
Datum, Status, Aufgabe, Kommentar


Exemplarische Story Card:
„Seminarverwaltung“
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer

Use Cases

Was genau sind Use Cases (Anwendungsfälle)?
_____INHALT_____

Fallbeispiel
• Interaktion zwischen Akteuren und dem
GPA / OOA
betrachteten System:
- Story Cards
- Use Cases
Dabei soll ein fachliches Ziel erreicht werden!
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker
• Grafisches UML Use Case:
OOD
Identifikation der Funktion & der beteiligten
- Klassen
- Zustände
Akteure im Vordergrund
- Sequenzen

OOP
- TDD & FDD
• Informationsgehalt eines graphischen Use Cases
- Scrum
- Pair Programming
ist gering!
- Cont. Integration  Use Case Schablone
Der ideale Kunde &
Programmierer
 Verlauf textuell beschreiben
 Bezug zum Geschäftsprozeß
 Basis kann Story Card sein!


Perspektiven
_____INHALT_____

Fallbeispiel
Use Cases können (wie auch alle anderen UML-
GPA / OOA
Diagramme) in verschiedenen Abstraktions-Ebenen
- Story Cards
- Use Cases
erstellt werden:
- Aktivitäten Wolke
- Objekte & Klassen
- CRC-Karten
Manager-View
- Risk/Value+Poker

OOD
- Klassen
- Zustände Drachen
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
Meeres-Spiegel
- Cont. Integration User-View
Der ideale Kunde &
Programmierer

Muschel

Fisch
Entwickler-View

Exemplarischer grafischer Use Case
der Seminarverwaltung (Manager-View)
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Etwas detailliertere Darstellung des Use Cases
„Seminare verwalten“
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Exemplarischer textueller Use Case
der Seminarverwaltung
_____INHALT_____
Buchen eines Seminars
Fallbeispiel
Ziel:
GPA / OOA
- Story Cards Anmeldebestätigung an den Kunden geschickt.
- Use Cases Vorbedingung:
- Aktivitäten
---
- Objekte & Klassen
- CRC-Karten Nachbedingung Erfolg:
- Risk/Value+Poker Kunde ist angemeldet.
OOD
Nachbedingung Fehlschlag:
- Klassen Mitteilung an Kunden, dass Veranstaltung ausgebucht ist, ausfällt oder nicht existiert.
- Zustände Akteure:
- Sequenzen
Kunde, GFU-MA
OOP Auslösendes Ereignis:
- TDD & FDD Anmeldung des Kunden liegt vor.
- Scrum
- Pair Programming
Beschreibung:
- Cont. Integration 1. Kundendaten abrufen
2. Seminar prüfen
Der ideale Kunde &
Programmierer
3. Anmeldebestätigung erstellen
Erweiterung:
1a. Kundendaten aktualisieren
1b. Wenn Kunde MA einer Firma ist, Firmendaten erfassen bzw. wenn vorhanden, dann
abrufen und aktualisieren
1c. Zahlungsmoral prüfen
Alternativen:
1a. Neukunden erfassen, wenn Kunde noch nicht existiert
1b. Auf alternative Veranstaltungen hinweisen, wenn ausgebucht
1c. Mitteilung „Falsche Veranstaltung“, falls Veranstaltung nicht existiert und auch nichts
ähnliches

Aktivitäten, Szenarien
& Geschäftsabläufe

Wozu Aktivitäts-Diagramme?
_____INHALT_____

Fallbeispiel
• Geben die Struktur eines Prozesses als Fluss
GPA / OOA
dynamisch wider
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
• Heben den Steuerungsfluss von Objekten im
- CRC-Karten
- Risk/Value+Poker
Geschäftsprozeß untereinander hervor
OOD
- Klassen
- Zustände
• Werden typischerweise aufgestellt, wenn die Use
- Sequenzen Cases fertig sind
OOP
- TDD & FDD
Ziel: grundsätzliche Abläufe darstellen
- Scrum
- Pair Programming
- Cont. Integration • Überschneidung der Ansicht zu einem
Der ideale Kunde &
Programmierer
textuellen Use Case ist groß
 Alternativ dazu anwenden?!


Was ist ein Szenario?
_____INHALT_____

Fallbeispiel
Eine spezifische Sequenz von Aktionen, die das
GPA / OOA
Verhalten des Systems unter bestimmten Bedingungen
- Story Cards
- Use Cases
beschreibt, z.B.:
- Aktivitäten
- Objekte & Klassen • Login
- CRC-Karten
- Risk/Value+Poker • Bestellvorgang
OOD • Rechnungsstellung
- Klassen
- Zustände • Auszahlung von Geld
- Sequenzen
• Angebotserstellung
OOP
- TDD & FDD • …
- Scrum
- Pair Programming
- Cont. Integration Im Allgemeinen:
Der ideale Kunde & Einen Geschäftsprozess des Unternehmens!
Programmierer

Bei der Entwicklung werden alle wichtigen Szenarien
in Aktivitäts-Diagrammen fest gehalten.


Aktivitäts-Diagramm der Seminarverwaltung:
erfolgreiche Anmeldung
_____INHALT_____

Fallbeispiel Kunde 1 Seminarverwaltung
GPA / OOA
- Story Cards
- Use Cases Suchbegriff „Java Einsteiger“
- Aktivitäten
- Objekte & Klassen in die GFU-Seite eingegeben
- CRC-Karten
- Risk/Value+Poker
Liste der Seminare
OOD zurückgeben
- Klassen
- Zustände
- Sequenzen Seminar auswählen
OOP
- TDD & FDD :Seminar
- Scrum
pers. Daten eingeben
[status: buchend]
- Pair Programming
- Cont. Integration [AnzTN=MaxTN-1]
Buchung abschicken
Der ideale Kunde &
Programmierer
Daten prüfen und ggf.
abgleichen
:Seminar
[status: ausgebucht]
[AnzTN=MaxTN]
Dr. rer. nat. Frank Dopatka Bestätigung der Buchung
FrankDopatka@web.de senden Folie 24

Aktivitäts-Diagramm der Seminarverwaltung:
fehlerhafte Anmeldung
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Objekte & Klassen
in der Analyse

Warum noch Objekt-Diagramme?
_____INHALT_____

Fallbeispiel
• Objekt-Diagramme besitzen die gleiche Notation
GPA / OOA
wie Klassen-Diagramme, stellen aber konkrete
- Story Cards
- Use Cases
Beispiele/Instanzen dar:
- Aktivitäten
- Objekte & Klassen
- derFrank: Dopatka, Frank, Schmiedeweg,...
- CRC-Karten
- Risk/Value+Poker
 Kunde: Name, Vorname, Strasse,...
OOD
- Klassen
- Zustände
• In der Praxis als erster Schritt der Analyse
- Sequenzen leicht verständlich, da anwendungsnah
OOP
- TDD & FDD
- Scrum
- Pair Programming
• Klassen: Abstraktionen der Objekte
- Cont. Integration  auf höherem Niveau!
Der ideale Kunde &
Programmierer


Warum Klassen-Diagramme in der Analyse?
_____INHALT_____

Fallbeispiel
• Klassen-Diagramme existieren vereinfacht in einer
GPA / OOA
Analyse-Form:
- Story Cards
- Use Cases
Identifikation der Klassen und deren
- Aktivitäten
- Objekte & Klassen
Beziehung zueinander im Vordergrund!
- CRC-Karten
- Risk/Value+Poker

OOD
• Klassen und deren Beziehungen orientieren sich
- Klassen
- Zustände
am Geschäftsprozeß  nicht plötzlich „falsch“
- Sequenzen

OOP
- TDD & FDD
• Beziehungen: textuell beschrieben
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Exemplarisches Objekt-Diagramm:
ein Seminar
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Exemplarisches Objekt-Diagramm:
Bezug eines Seminars zu anderen Objekten
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Ausschnitt aus einem Klassen-Diagramm (OOA)
der Seminarverwaltung
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


CRC-Karten

Wie kommt man an die Objekte & Klassen?
_____INHALT_____

Fallbeispiel
• Durch Erfahrung!
GPA / OOA
- Story Cards
- Use Cases
• Indem Sie in Gesprächen und Beschreibungen
- Aktivitäten
- Objekte & Klassen
achten auf:
- CRC-Karten
- Risk/Value+Poker - nicht-triviale Hauptwörter (Raum, Kunde,...)
OOD  Klassen
- Klassen
- Zustände
- Sequenzen
- triviale Hauptwörter, die durch einzelne
OOP
Zeichenketten, Zahlen oder wahr/falsch
- TDD & FDD
- Scrum
darstellbar sind (Name, Mail-Adresse,...)
- Pair Programming
- Cont. Integration
 Attribute
Der ideale Kunde & - Verben (anlegen, buchen, suchen, stornieren,...)
Programmierer
 Methoden
- Ausdrücke wie „ist ein“ bzw. „besteht aus“
 Vererbung bzw. Aggregation oder Komposition


Was ist eine CRC-Karte?
_____INHALT_____

Fallbeispiel
• Prinzip einer Class-Responsibility-Collaboration-
GPA / OOA
Karte:
- Story Cards
- Use Cases
für jede Klasse eine Karteikarte erstellen &
- Aktivitäten
- Objekte & Klassen
auf dieser deren Eigenschaften zu notieren
- CRC-Karten
- Risk/Value+Poker

OOD
• Eine solche Karte besteht aus folgenden Bereichen:
- Klassen
- Zustände - Name der Klasse
- Sequenzen
- Aufgaben der Klasse
OOP
- TDD & FDD - Klassen, mit denen die beschriebene Klasse
- Scrum
- Pair Programming zusammenarbeitet
- Cont. Integration
- Rückseite: wichtigste Attribute und Methoden
Der ideale Kunde &
Programmierer


Vorteile der CRC-Karten
_____INHALT_____

Fallbeispiel
• Einfache Handhabung:
GPA / OOA
Problemlos Informationen hinzufügen oder streichen
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
• Unabhängig von Programmiersprachen & Tools
- CRC-Karten
- Risk/Value+Poker

OOD
• begrenzte Platz
- Klassen
- Zustände
 auf die wesentlichen Aufgaben einer Klasse
- Sequenzen konzentrieren
OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Vorgehensweise
_____INHALT_____

Fallbeispiel
• Mit dem Kunden typische Anwendungsfälle
GPA / OOA
definieren  Use Cases
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
• Anwendungsfälle nacheinander durchspielen
- CRC-Karten
- Risk/Value+Poker
 Aktivitäten
OOD
- Klassen
- Zustände
• Auf den CRC-Karten neue Aufgaben und
- Sequenzen Partnerklassen festhalten
OOP
- TDD & FDD
- Scrum
- Pair Programming
 Mit der Zeit ergibt sich ein vollständiges Bild.
- Cont. Integration

Der ideale Kunde &
Programmierer
• Wichtig:
- Untersuchung aller typischen Anwendungsfälle
& Szenarien
- Festhalten aller Details


Beispielhafte CRC-Karte „Seminar“
 Klasse „Seminar“
_____INHALT_____

Fallbeispiel Seminar

GPA / OOA
- Story Cards Aufgaben:
- Use Cases Erstellen und verwalten von Seminaren und deren Inhalten. Man soll Seminare suchen
- Aktivitäten können und im Internet veröffentlichen. Man kann sich anmelden, solange die max. TN-Tahl
- Objekte & Klassen
- CRC-Karten nicht erreicht ist. Abmelden geht auch jederzeit. Die GFU kann notfalls ein Seminar auch
- Risk/Value+Poker stornieren, wenn keine Anmeldung vorliegt oder der geplante Dozent krank ist und kein
Ersatz gefunden werden konnte.
OOD
- Klassen
- Zustände
- Sequenzen Partnerklassen:
Seminarverwaltung, Rechnung, Termin -> (Raum, Dozent, Anmeldungen -> (Teilnehmer))
OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer

Risk-Value Priorisierung
& Planning Poker

Was wird wie priorisiert
& welche Konsequenzen ergeben sich?
_____INHALT_____

Fallbeispiel
Bereits bei den Story Cards wurden die Begriffe
GPA / OOA • Priorität,
- Story Cards
- Use Cases • Risiko und
- Aktivitäten
- Objekte & Klassen • Aufwandschätzung
- CRC-Karten
- Risk/Value+Poker für jede Funktionalität (Use Case) erwähnt.
OOD
- Klassen
- Zustände
- Sequenzen
Jetzt wissen alle Beteiligten bereits mehr über die
OOP
Funktionen & Abläufe.
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration
 So langsam können Sie folgende Fragen
Der ideale Kunde &
beantworten...
Programmierer


Was wird wie priorisiert
& welche Konsequenzen ergeben sich?
_____INHALT_____

Fallbeispiel
• Wie wichtig ist unserem Kunden diese
GPA / OOA
Funktionalität?  0..10 Punkte K
- Story Cards
- Use Cases • Wie wichtig sehen die Programmierer die
- Aktivitäten
- Objekte & Klassen Integration der Funktionalität im Kontext der
- CRC-Karten
- Risk/Value+Poker Anwendung?*  0..10 Punkte P
OOD
- Klassen
• Wie sehen die Programmierer die Schwierigkeit
- Zustände
- Sequenzen
der technischen Umsetzung (Risiko) der
OOP
Funktion?*  0..10 Punkte S
- TDD & FDD
- Scrum • Wie (zeit-)aufwendig sehen die Programmierer
- Pair Programming
- Cont. Integration die Umsetzung?*
Der ideale Kunde &  Schätzverfahren COCOMO, Lines Of Code,
Programmierer
Function Points  Preis dieser Funktion

* basierend auf ihrer Projekterfahrung


Womit fängt man jetzt an?
_____INHALT_____

Fallbeispiel K+P: 12 -20
GPA / OOA S: 6 -10
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen
K+P: 0 -6
OOP
- TDD & FDD S: 0 -3
- Scrum
- Pair Programming
- Cont. Integration K+P: 12 -20
Der ideale Kunde & S: 0 -3
Programmierer

Man beginnt mit dem höchsten Risiko und dem
höchsten Wert!


Exemplarische Priorisierung
aus der Seminarverwaltung
_____INHALT_____

Fallbeispiel
Planning Poker:
GPA / OOA
- Story Cards Zusammen mit dem
- Use Cases
- Aktivitäten Kunden die nächsten
- Objekte & Klassen
- CRC-Karten Schritte planen!
- Risk/Value+Poker

OOD
Wie detailliert?
- Klassen
- Zustände
vgl. eine Scrum-Aufgabe
- Sequenzen  <16 Mannstunden
OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Klassen im Design

Von den Klassen zum Code
_____INHALT_____

Fallbeispiel
In der Design-Form beinhalten Klassen-Diagramme
GPA / OOA
alle notwendigen Methoden und Attribute.
- Story Cards
- Use Cases
 mit Modellierungs-Werkzeuge Java- oder
- Aktivitäten
- Objekte & Klassen
C#-Coderümpfe generieren
- CRC-Karten
- Risk/Value+Poker
 „Nur noch“ mit Funktionalität füllen
OOD
- Klassen
- Zustände
Auch Beziehungen zwischen Klassen wie
- Sequenzen
„ein Kunde hat n Rechnungen“
OOP
- TDD & FDD
- Scrum
können automatisch in Java-Collections abgebildet
- Pair Programming
- Cont. Integration
werden; u.a. mit ObjectIf von MicroTool
Der ideale Kunde &
Programmierer


Von den Klassen zum Code
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Beispiel: Together Edition
for SAP NetWeaver Developer Studio
_____INHALT_____

Fallbeispiel

GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer

Einige Klassen im Design
_____INHALT_____
Seminarverwaltung
Fallbeispiel
Seminar-Termin
- Seminare: ArrayList
- instance: Seminarverwaltung - von: Date
GPA / OOA
- bis: Date
- Story Cards
- Use Cases
+ getInstance(): Seminarverwaltung
+ suche (String Inhalt): Seminar + DozentZuweisen (Dozent d)
- Aktivitäten + RaumZuweisen (Raum r)
- Objekte & Klassen + suche (Long ID): Seminar
- CRC-Karten .... ...
- Risk/Value+Poker
* 0: individuelles
OOD In-House Seminar
- Klassen *
- Zustände Seminar
- Sequenzen
- ID: Long
OOP - Zustand: Enum {existiert, buchend, ausgebucht,
- TDD & FDD durchgeführt, storniert, gelöscht}
- Scrum - Kurzbeschreibung: String
- Pair Programming - Inhalt: String
- Cont. Integration - SeminarZiel: String
Der ideale Kunde &
- Ort: String
Programmierer - Dauer: Byte
- minAnzTN: Byte
- maxAnzTN: Byte
- Preis: Decimal
+ Daten anzeigen (): String
+ Daten aktualisieren (Date von,...): String
+ anmelden (Termin T, Teilnehmer TN)
+ abmelden (Termin T, Teilnehmer TN)
+ stornieren (Termin T)
+ entfallen (Termin T)
FrankDopatka@web.de hinzufügen(Date von, Date bis)
+ Termin Folie 47
....

Zustands-Diagramme

Wieso noch Zustandsdiagramme?
_____INHALT_____

Fallbeispiel
Sicht auf alle möglichen Zustände eines Objektes
GPA / OOA
 bezieht sich auf genau eine Klasse
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
Zustandsübergänge treten i.d.R. dadurch auf, dass
- CRC-Karten
- Risk/Value+Poker
das betreffende Objekt „angetriggert“ wird
OOD
 Methodenaufruf
- Klassen
- Zustände
- Sequenzen Prinzipiell kann jede Methode eines Objektes jederzeit
OOP
- TDD & FDD
aufgerufen werden:
- Scrum
- Pair Programming
Methodenaufruf Y im Zustand X erlaubt ???
- Cont. Integration  Zustandsdiagramm
Der ideale Kunde &
Programmierer
 wenn nicht erlaubt  Exception


Sichere Automaten!
_____INHALT_____

Fallbeispiel
Vollständige Zustandsautomaten...
GPA / OOA
- Story Cards
- Use Cases
 Robustheit der Software:
- Aktivitäten
- Objekte & Klassen
im Alltag werden oft einzelne Methodenaufrufe in
- CRC-Karten
- Risk/Value+Poker
bestimmten Zuständen „vergessen“
OOD
- Klassen
- Zustände
 Ein Objekt ist gegen seinen Zustandsautomaten
- Sequenzen testbar
OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Zustands-Diagramm
_____INHALT_____

Fallbeispiel
Ein Objekt der Klasse „Seminar“:
GPA / OOA
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Sequenz-Diagramme

Aktivitäten vs. Sequenzen
_____INHALT_____

Fallbeispiel
Aktivitäts-Diagrammen:
GPA / OOA
Abläufe aus Sicht des Geschäftsprozesses mit deren
- Story Cards
- Use Cases
Zuständigkeiten modelliert
- Aktivitäten
- Objekte & Klassen
 Fachliches Modell
- CRC-Karten
- Risk/Value+Poker Nun wurden bereits Klassen, deren Methoden und
OOD Beziehung ermittelt...
- Klassen
- Zustände
- Sequenzen
Sequenz-Diagramm:
OOP
Darstellung des technisch modellierten Ablaufs
- TDD & FDD
- Scrum
darstellen
- Pair Programming
- Cont. Integration
 Technisches Modell
Der ideale Kunde &
Programmierer • Ablauf von Nachrichten von Objekten
untereinander durch gegenseitige Methoden-
Aufrufe

• Auslöser:
Akteur, der einen Use-Case initiiert

Sequenz-Diagramm aus der Seminarverwaltung:
„Buchung vornehmen“

Test Driven Development
&
Feature Driven Development

Was ist Testgetriebene Entwicklung?
_____INHALT_____

Fallbeispiel
• Ziel: Software-Tests vor den zu testenden
GPA / OOA
Komponenten erstellen!
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
 Erstellte Unit-Tests sind Grey-Box-Tests
- CRC-Karten
- Risk/Value+Poker
statt klassischer White-Box-Tests
OOD
- Klassen
- Zustände
• Unit-Tests und mit ihnen getestete Units werden
- Sequenzen stets parallel entwickelt.
OOP
- TDD & FDD
- Scrum
- Pair Programming
• eigentliche Programmierung in kleinen &
- Cont. Integration wiederholten Schritten
Der ideale Kunde &
Programmierer
• eine Iteration (Dauer: wenige Minuten) hat drei
Hauptteile:


Was ist Testgetriebene Entwicklung?
_____INHALT_____

Fallbeispiel
1. Schreiben Sie einen Test für das erwünschte
GPA / OOA
fehlerfreie Verhalten, das implementiert werden soll.
- Story Cards
- Use Cases
Dieser Test wird erst einmal nicht erfüllt bzw. es gibt
- Aktivitäten
- Objekte & Klassen
den Code gibt es noch gar nicht.
- CRC-Karten
- Risk/Value+Poker 2. Änderen/schreiben Sie den Code mit möglichst
OOD wenig Aufwand, bis nach dem anschließend
- Klassen
- Zustände angestoßenen Testdurchlauf alle Tests bestanden
- Sequenzen
werden.
OOP
- TDD & FDD
- Scrum
3. Räumen Sie im Code auf (Refactoring):
- Pair Programming
- Cont. Integration
- Wiederholungen entfernen
Der ideale Kunde &
- Code abstrahieren
Programmierer - Code nach Konventionen ausrichten
- ...
- testen!


Test-Entwurf
_____INHALT_____

Fallbeispiel Test:
GPA / OOA Seminar anlegen
- Story Cards
- Use Cases Vorbedingung:
- Aktivitäten
- Objekte & Klassen ---
- CRC-Karten prüfbare Nachbedingung Erfolg:
- Risk/Value+Poker Seminar wurde mit seinen Daten in der
OOD Seminarverwaltung aufgenommen und
- Klassen eine neue Seminar-ID wurde vergeben.
- Zustände
Nachbedingung erwarteter Fehlschlag:
- Sequenzen
Seminar mit diesem Titel existiert
OOP bereits.
- TDD & FDD Test:
- Scrum Seminar buchen
- Pair Programming
- Cont. Integration
Vorbedingung:
Der ideale Kunde & Seminar existriert bereits und ist
Programmierer
zum gewählten Termin nicht
ausgebucht
prüfbare Nachbedingung Erfolg:
Kunde wurde als TN in die Liste der TN
zum gewählten Termin aufgenommen
Nachbedingung erwarteter Fehlschlag:
Meldung „Nicht möglich: Kunde hat
Dr. rer. nat. Frank Dopatka noch >3 offene Rechnungen!“

Was ist Feature-getriebene Entwicklung?
_____INHALT_____

Fallbeispiel
FDD wird eingesetzt, um ein (großes) zeitkritisches
GPA / OOA
Projekt (z.B. 15 Monate, 50 Entwickler) durchzuführen.
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
Jedes Feature stellt einen Mehrwert für den Kunden
- CRC-Karten
- Risk/Value+Poker
dar.
OOD
- Klassen
- Zustände
Die Entwicklung wird anhand eines Feature-Plans
- Sequenzen organisiert.
OOP
- TDD & FDD
- Scrum
- Pair Programming
Eine wichtige Rolle spielt der Chef-Architekt, der
- Cont. Integration ständig den Überblick über die Gesamtarchitektur und
Der ideale Kunde &
Programmierer
die fachlichen Kernmodelle behält.


Prozesse der Feature-getriebenen Entwicklung
_____INHALT_____

Fallbeispiel
1. Entwicklen Sie ein Gesamtmodell:
GPA / OOA
- Konsens über Inhalt und Umfang des zu
- Story Cards
- Use Cases
entwickelnden Systems
- Aktivitäten
- Objekte & Klassen
- fachliche Kernmodell
- CRC-Karten
- Risk/Value+Poker
 grobe Use Cases
OOD
- Klassen 2. Erstellen Sie eine Feature-Liste:
- Zustände
- Sequenzen - nach dem einfachen Schema
OOP <Aktion> <Ergebnis> <Objekt>
- TDD & FDD
- Scrum - Bsp.: „Berechne Gesamtsumme der Verkäufe“
- Pair Programming
- Cont. Integration - max. zwei Wochen zur Realisierung
Der ideale Kunde &  Risk/Value & Planning Poker
Programmierer


Prozesse der Feature-getriebenen Entwicklung
_____INHALT_____

Fallbeispiel
3. Planen Sie jedes Feature
GPA / OOA
- Reihenfolge der Realisierung festlegen
- Story Cards
- Use Cases
- Fertigstellungstermine je Geschäftsaktivität
- Aktivitäten
- Objekte & Klassen
- Projektleiter, Entwicklungsleiter sowie
- CRC-Karten
- Risk/Value+Poker
Senior-Programmierer beteiligt
OOD
- Klassen 4. Entwurf jedes Features
- Zustände
- Sequenzen - Entwicklerteams zuweisen
OOP - Erstellung von Sequenz-Diagrammen
- TDD & FDD
- Scrum - erste Klassen- und Methodenrümpfe
- Pair Programming
- Cont. Integration

Der ideale Kunde & 5. Ausprogrammierung der Features
Programmierer
- Pair Programming & TDD


Scrum

Was ist Scrum?
_____INHALT_____

Fallbeispiel
• „Das Gedränge“: agiles Vorgehensmodell
GPA / OOA
Meetings, Artefakten, Rollen & Werten
- Story Cards
- Use Cases
 folgt dem Prinzip der „Schlanken Produktion“
- Aktivitäten
- Objekte & Klassen
(lean production)
- CRC-Karten
- Risk/Value+Poker

OOD
• Teammitglieder organisieren ihre Arbeit
- Klassen
- Zustände
weitgehend selbst & wählen auch die eingesetzten
- Sequenzen Entwicklungswerkzeuge und -Methoden
OOP
- TDD & FDD
- Scrum
- Pair Programming
• Entwicklung ist sehr komplex
- Cont. Integration  im Voraus weder in große abgeschlossene
Der ideale Kunde &
Programmierer
Phasen noch in einzelne Arbeitsschritte
(Granularität von Mannstunden) planbar
 Selbst-Organisation!


Grundlegende Begriffe des Scrum
_____INHALT_____

Fallbeispiel
• Zentrales Element ist der Sprint:
GPA / OOA
Umsetzung einer Iteration (ca. 30 Tage)
- Story Cards
- Use Cases
- Aktivitäten
- Objekte & Klassen
• Vor dem Sprint:
- CRC-Karten
- Risk/Value+Poker
Produkt-Anforderungen des Kunden in einem
OOD
Product Backlog sammeln
- Klassen
- Zustände
 beinhaltet alle Funktionalitäten, die der
- Sequenzen Kunde wünscht
OOP
- TDD & FDD
 Priorisierung der Funktionen
- Scrum
- Pair Programming
- Cont. Integration • Hoch priorisierte Features:
Der ideale Kunde &
Programmierer
 von den Entwicklern im Aufwand geschätzt
 ins Sprint Backlog übernehmen:
- enthält alle Aufgaben, um das Ziel des Sprints
zu erfüllen
- eine Aufgabe: < 16 Stunden
- längere Aufgaben: in Teilaufgaben zerlegen

Meetings, Review & Retrospektive
_____INHALT_____

Fallbeispiel
Täglich: Daily Scrum Meeting (max. 15min.)
GPA / OOA
 Team stellt sich gegenseitig folgende Fragen:
- Story Cards
- Use Cases • „Bist du gestern mit dem fertig geworden, was du dir
- Aktivitäten
- Objekte & Klassen vorgenommen hast?“
- CRC-Karten
- Risk/Value+Poker • „Welche Aufgaben wirst du bis zum nächsten
OOD Meeting bearbeiten?“
- Klassen
- Zustände • „Gibt es ein Problem, das dich blockiert?“
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer

_____INHALT_____

Fallbeispiel
• Nach einem Sprint:
GPA / OOA
Ergebnis einem informellen Review unterziehen:
- Story Cards
- Use Cases
Team & Kunden
- Aktivitäten
- Objekte & Klassen
 Ergebnis des Sprints (laufende Software)
- CRC-Karten
- Risk/Value+Poker
vorführen
OOD
- Klassen
- Zustände
• Kunde prüft, ob das Sprint-Ergebnis seinen
- Sequenzen Anforderungen entspricht:
OOP
- TDD & FDD
Änderungswünsche  Product Backlog
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


_____INHALT_____

Fallbeispiel
• Retrospektive:
GPA / OOA
zurückliegende Sprint-Phase betrachten;
- Story Cards
- Use Cases
zunächst wertfreien Rückblick auf die Ereignisse
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker
• Teilnehmer notieren die wichtigen Ereignisse auf
OOD
Zetteln.
- Klassen
- Zustände
- Sequenzen • Anschließend schreiben die Teilnehmer Antworten
OOP
- TDD & FDD
auf die Fragen
- Scrum
- Pair Programming
- „Was war gut?“ (Best practice)
- Cont. Integration - „Was könnte verbessert werden?“
Der ideale Kunde &
Programmierer
(Verbesserungspotential)

• Jedes Verbesserungspotential wird priorisiert und
mit Zuständigkeiten versehen.


Pair Programming

Wie funktioniert Pair Programming?
_____INHALT_____

Fallbeispiel
• jeweils zwei Programmierer an einem Rechner
GPA / OOA
- Story Cards
- Use Cases
• einer schreibt den Code, der andere:
- Aktivitäten
- Objekte & Klassen
- nachdenken über die Problemstellungen
- CRC-Karten
- Risk/Value+Poker
- Code kontrollieren  Probleme sofort
OOD
ansprechen  sofort lösen
- Klassen
- Zustände
- Sequenzen • Rollen abwechseln & Zusammensetzung der
OOP
- TDD & FDD
Paare häufig ändern
- Scrum
- Pair Programming
- Cont. Integration Ziel:
Der ideale Kunde &
Programmierer
Erhöhung der Software-Qualität


Vorteile des Pair Programming
_____INHALT_____

Fallbeispiel
• Höhere Disziplin:
GPA / OOA
Paare entwickeln eher an der richtigen Stelle &
- Story Cards
- Use Cases
machen kürzere Pausen
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker
• Besserer Code:
OOD
Man entwickelt man sich weniger leicht in
- Klassen
- Zustände
Sackgassen.
- Sequenzen

OOP
- TDD & FDD
• Höhere Moral:
- Scrum
- Pair Programming
spannender & interessanter als alleine
- Cont. Integration

Der ideale Kunde &
Programmierer
• Collective Code Ownership:
alle erlangen Wissen über die gesamte Codebasis,
die gemeinsam erstellt wurde


Vorteile des Pair Programming
_____INHALT_____

Fallbeispiel
• Mentoring:
GPA / OOA
Jeder hat Wissen, das andere nicht haben.
- Story Cards
- Use Cases
 einfache Wissensverbreitung
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker
• Team-Bildung:
OOD
Leute lernen sich gegenseitig schneller kennen
- Klassen
- Zustände
 Zusammenarbeit verbessert
- Sequenzen

OOP
- TDD & FDD
• Weniger Unterbrechungen:
- Scrum
- Pair Programming
Paare werden seltener unterbrochen.
- Cont. Integration

Der ideale Kunde &
Programmierer


Continous Integration

Motivation
_____INHALT_____

Fallbeispiel
Unit-und Modul-Tests...
GPA / OOA
mit Werkzeugen wie JUnit mitlerweile
- Story Cards
- Use Cases
automatisiert erstellbar!
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker
 Wie können „höhere“ Tests - z.B. Integrationstest,
OOD
gehandhabt werden?
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer
???

Motivation
_____INHALT_____

Fallbeispiel
Gerade wenn bei der Integration der Komponenten
GPA / OOA
Design-Fehler entdeckt werden, ist dies entsprechend
- Story Cards
- Use Cases
teuer!
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker

OOD
- Klassen
- Zustände
- Sequenzen

OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Die Idee der Continous Integration
_____INHALT_____

Fallbeispiel
• Kontinuierliche Integration:
GPA / OOA
regelmäßiges, vollständiges Neubilden &
- Story Cards
- Use Cases
Testen einer Anwendung
- Aktivitäten
- Objekte & Klassen
- CRC-Karten
- Risk/Value+Poker
 Änderungen in die Versionsverwaltung einchecken
OOD
 Gesamtsystem neu bauen & automatisch
- Klassen
- Zustände
testen
- Sequenzen

OOP
- TDD & FDD
 alle Tests erfolgreich:
- Scrum
- Pair Programming
 Änderungen an die nächste Stufe geben
- Cont. Integration  Tests scheitern:
Der ideale Kunde &
Programmierer
 Änderungen zurücknehmen (Rollback)
 zur Korrektur vorlegen


Werkzeuge zur Continous Integration
_____INHALT_____

Fallbeispiel
Voraussetzung:
GPA / OOA
- Versionsverwaltungssystem
- Story Cards
- Use Cases
- zeitnahes Check-In
- Aktivitäten
- Objekte & Klassen
- nur funktional vollständige Blöcke eingecheckt
- CRC-Karten
- Risk/Value+Poker
Das Java-basierte CruiseControl hilft bei der
OOD
- Klassen
Umsetzung der CI:
- Zustände
- Sequenzen
- Benachrichtigung per E-Mail,
OOP
- Nutzung von Apache Ant
- TDD & FDD
- Scrum
& anderen Werkzeugen
- Pair Programming
- Cont. Integration
- Web-Oberfläche: aktuellen und vorherigen
Der ideale Kunde &
Zustand der Software anzeigen
Programmierer


Der ideale
Kunde & Programmierer

Mit welchen Kunden funktionieren
agile Methoden (nicht)?
_____INHALT_____

Fallbeispiel
• experimentierfreudig
GPA / OOA • selbst erhebliche Ressourcen aufwenden
- Story Cards
- Use Cases
- Aktivitäten
• Worin besteht das Gewek?
- Objekte & Klassen
- CRC-Karten
... das durch den vereinbarten Preis erworben
- Risk/Value+Poker wird
OOD
- Klassen • Kunde verzichtet auf formale Spezifikation und
- Zustände
- Sequenzen bindendes Angebot
OOP
- TDD & FDD
• Es darf nicht die Mentalität „das machen wir mal
- Scrum
- Pair Programming
eben nebenbei“ vorherrschen
- Cont. Integration

Der ideale Kunde &
Programmierer


Mit welchen Kunden funktionieren
_____INHALT_____

Fallbeispiel
• Vertreter des Kunden darf selbst nicht gezwungen
GPA / OOA
sein, seinen Vorgesetzten eine
- Story Cards
- Use Cases
- Planung im Vorfeld
- Aktivitäten
- Objekte & Klassen
- Erfüllung bestimmter Funktionen zu festgelegten
- CRC-Karten
- Risk/Value+Poker
Terminen zu berichten
OOD
- Klassen
- Zustände
• "Kunde vor Ort"-Prinzip
- Sequenzen  Mitarbeiter des Kunden benötigen selbst einen
OOP
- TDD & FDD
erheblichen Wissensumfang
- Scrum
- Pair Programming
 Sind diese Personen entbehrlich?
- Cont. Integration

Der ideale Kunde &
Programmierer


Mit welchen Programmierern funktionieren
_____INHALT_____

Fallbeispiel
• Programmierer: sehr gute Fähigkeiten
GPA / OOA
 häufige Änderungen
- Story Cards
- Use Cases
 umfangreiche Programmiererfahrung
- Aktivitäten
- Objekte & Klassen
 geeignete Werkzeuge
- CRC-Karten
- Risk/Value+Poker

OOD
• ausgeprägtes Ego:
- Klassen
- Zustände
 große Überzeugung von „richtigen Lösungen“
- Sequenzen  Besitzdenken des geschriebenen Codes äußert:
OOP
- TDD & FDD
 Nicht jeder kann damit umgehen,
- Scrum
- Pair Programming
dass „sein“ Code von anderen verändert wird
- Cont. Integration

Der ideale Kunde &
Programmierer


Mit welchen Programmierern funktionieren
_____INHALT_____

Fallbeispiel
• XP weist eine Reihe von Merkmalen auf,
GPA / OOA - die hohe Disziplin erfordern
- Story Cards
- Use Cases  TDD & CI, permanante Refactorings,
- Aktivitäten
- Objekte & Klassen Programmieren in Paaren
- CRC-Karten
- Risk/Value+Poker - und andere, die eine gewisse Disziplin-
OOD
- Klassen
losigkeit fördern
- Zustände
- Sequenzen
 das Auslassen von Spezifikation
OOP
- TDD & FDD
- Scrum
- Pair Programming
- Cont. Integration

Der ideale Kunde &
Programmierer


Vielen Dank für
Ihre Aufmerksamkeit!

Noch Fragen?
Quellen des Vortrags:
• Wikipedia <http://de.wikipedia.org>
• Vorlesung „Einführung in die Informatik II“
<http://www.bs.informatik.uni-siegen.de/www/lehre/ss09/ei2/index_html>
• Fowler, Scott: UML konzentriert; 2. Auflage; Addison Wesley Verlag; ISBN 3-8273-1617-0
• Helmut Balzert: Lehrbuch der Software-Technik: Software-Entwicklung; 2. Auflage;
Spektrum-Verlag; ISBN 3-8274-0480-0
• Booch, Rumbaugh, Jacobson: Das UML Benutzerhandbuch; Addison-Wesley Verlag;
ISBN 3-8273-2295-2

Agile Geschäftsprozeßanalyse OOA/D am Beispiel einer Seminarverwaltung

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Agile Geschäftsprozeßanalyse OOA/D am Beispiel einer Seminarverwaltung

Ähnlich wie Agile Geschäftsprozeßanalyse OOA/D am Beispiel einer Seminarverwaltung (20)

Mehr von GFU Cyrus AG

Mehr von GFU Cyrus AG (20)

Agile Geschäftsprozeßanalyse OOA/D am Beispiel einer Seminarverwaltung