SlideShare ist ein Scribd-Unternehmen logo
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




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




                                          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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                               Folie 6
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




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




                                    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.


                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                              Folie 8
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.




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




                       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)



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




                                        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



                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                             Folie 12
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




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




                                      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!



                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                                    Folie 16
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
                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                               Folie 17




                               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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                               Folie 18
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




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




                                     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?!




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                            Folie 22
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.

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




                           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




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




                        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




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




                           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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                              Folie 28
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




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




                               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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                         Folie 30
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




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




                                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

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




                                       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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                                Folie 34
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




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




                                            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

                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                                  Folie 36
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




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




                                    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


                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                                   Folie 40
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!

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




                                      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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                             Folie 42
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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                             Folie 44
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




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




                                     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
                                             aus der Seminarverwaltung
_____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)
                      Dr. rer. nat. Frank Dopatka
                                          + 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




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




                                          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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                               Folie 50
Zustands-Diagramm
                                     aus der Seminarverwaltung
_____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




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




                      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:



                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                             Folie 56
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!


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




                                                  Test-Entwurf
                                           aus der Seminarverwaltung
_____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!“
                      FrankDopatka@web.de                                                   Folie 58
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.




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




                         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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                              Folie 60
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




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




                                       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!



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




                                 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




                                 Meetings, Review & Retrospektive
_____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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                               Folie 66
Meetings, Review & Retrospektive
_____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.

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




                        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




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




                                   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



                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                                 Folie 70
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




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




                 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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                              Folie 74
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




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




                               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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                             Folie 76
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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                            Folie 78
Mit welchen Kunden funktionieren
                                      agile Methoden (nicht)?
_____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




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




                           Mit welchen Programmierern funktionieren
                                    agile Methoden (nicht)?
_____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




                      Dr. rer. nat. Frank Dopatka
                      FrankDopatka@web.de                            Folie 80
Mit welchen Programmierern funktionieren
                                    agile Methoden (nicht)?
_____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




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




                    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

Weitere ähnliche Inhalte

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

Big Data Discovery + Analytics = Datengetriebene Innovation!
Big Data Discovery + Analytics = Datengetriebene Innovation!Big Data Discovery + Analytics = Datengetriebene Innovation!
Big Data Discovery + Analytics = Datengetriebene Innovation!
Harald Erb
 
Hybrides Projektmanagement – Wie Sie agile und klassische Methoden verbinden
Hybrides Projektmanagement – Wie Sie agile und klassische Methoden verbindenHybrides Projektmanagement – Wie Sie agile und klassische Methoden verbinden
Hybrides Projektmanagement – Wie Sie agile und klassische Methoden verbinden
Achim Schmidt-Sibeth
 
eoda R-Akademie 2016
eoda R-Akademie 2016eoda R-Akademie 2016
eoda R-Akademie 2016
eoda GmbH
 
Softwarequalität: Garbage in - garbage out
Softwarequalität: Garbage in - garbage outSoftwarequalität: Garbage in - garbage out
Softwarequalität: Garbage in - garbage out
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo
QAware GmbH
 
tekom/tcworld 2013 – T1: 3D-PDF-Tools von Tetra4D im Vergleich mit SAP VEA
tekom/tcworld 2013 – T1: 3D-PDF-Tools von Tetra4D im Vergleich mit SAP VEAtekom/tcworld 2013 – T1: 3D-PDF-Tools von Tetra4D im Vergleich mit SAP VEA
tekom/tcworld 2013 – T1: 3D-PDF-Tools von Tetra4D im Vergleich mit SAP VEA
Georg Eck
 
Dev Day 2019: Stephan Birnbaum – Die Glaskugel hat ausgedient, wir machen Sof...
Dev Day 2019: Stephan Birnbaum – Die Glaskugel hat ausgedient, wir machen Sof...Dev Day 2019: Stephan Birnbaum – Die Glaskugel hat ausgedient, wir machen Sof...
Dev Day 2019: Stephan Birnbaum – Die Glaskugel hat ausgedient, wir machen Sof...
DevDay Dresden
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
QAware GmbH
 
Design od Experiment - Zeit und Sicherheit gewinnen
Design od Experiment - Zeit und Sicherheit gewinnenDesign od Experiment - Zeit und Sicherheit gewinnen
Design od Experiment - Zeit und Sicherheit gewinnen
Ralf Becker
 
Die unendliche User Geschichte: Orientierung in agilen Projekten
Die unendliche User Geschichte: Orientierung in agilen ProjektenDie unendliche User Geschichte: Orientierung in agilen Projekten
Die unendliche User Geschichte: Orientierung in agilen Projekten
Thomas Moedl
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
camunda services GmbH
 
Rasterpunkt GmbH: Schulungskalender Output Management Solutions
Rasterpunkt GmbH: Schulungskalender Output Management Solutions Rasterpunkt GmbH: Schulungskalender Output Management Solutions
Rasterpunkt GmbH: Schulungskalender Output Management Solutions
RasterpunktGmbH
 
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
camunda services GmbH
 
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der PraxisResponsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Roberto Rizzi
 
dictaJet im Produktinformationsmanagement
dictaJet im ProduktinformationsmanagementdictaJet im Produktinformationsmanagement
dictaJet im Produktinformationsmanagement
dictaJet
 
Erfahrungen mit agilen Festpreisen
Erfahrungen mit agilen FestpreisenErfahrungen mit agilen Festpreisen
Erfahrungen mit agilen Festpreisen
Joachim Baumann
 
Gamification im Projektmanagement
Gamification im ProjektmanagementGamification im Projektmanagement
Gamification im Projektmanagement
Gotscharek & Company GmbH
 
Camunda BPM 7.2 - Deutsch
Camunda BPM 7.2 - DeutschCamunda BPM 7.2 - Deutsch
Camunda BPM 7.2 - Deutsch
camunda services GmbH
 

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

Systementwurf mit UML
Systementwurf mit UMLSystementwurf mit UML
Systementwurf mit UML
 
Big Data Discovery + Analytics = Datengetriebene Innovation!
Big Data Discovery + Analytics = Datengetriebene Innovation!Big Data Discovery + Analytics = Datengetriebene Innovation!
Big Data Discovery + Analytics = Datengetriebene Innovation!
 
Hybrides Projektmanagement – Wie Sie agile und klassische Methoden verbinden
Hybrides Projektmanagement – Wie Sie agile und klassische Methoden verbindenHybrides Projektmanagement – Wie Sie agile und klassische Methoden verbinden
Hybrides Projektmanagement – Wie Sie agile und klassische Methoden verbinden
 
eoda R-Akademie 2016
eoda R-Akademie 2016eoda R-Akademie 2016
eoda R-Akademie 2016
 
Softwarequalität: Garbage in - garbage out
Softwarequalität: Garbage in - garbage outSoftwarequalität: Garbage in - garbage out
Softwarequalität: Garbage in - garbage out
 
Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo Cloud Migration mit KI: der Turbo
Cloud Migration mit KI: der Turbo
 
tekom/tcworld 2013 – T1: 3D-PDF-Tools von Tetra4D im Vergleich mit SAP VEA
tekom/tcworld 2013 – T1: 3D-PDF-Tools von Tetra4D im Vergleich mit SAP VEAtekom/tcworld 2013 – T1: 3D-PDF-Tools von Tetra4D im Vergleich mit SAP VEA
tekom/tcworld 2013 – T1: 3D-PDF-Tools von Tetra4D im Vergleich mit SAP VEA
 
Dev Day 2019: Stephan Birnbaum – Die Glaskugel hat ausgedient, wir machen Sof...
Dev Day 2019: Stephan Birnbaum – Die Glaskugel hat ausgedient, wir machen Sof...Dev Day 2019: Stephan Birnbaum – Die Glaskugel hat ausgedient, wir machen Sof...
Dev Day 2019: Stephan Birnbaum – Die Glaskugel hat ausgedient, wir machen Sof...
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
 
Design od Experiment - Zeit und Sicherheit gewinnen
Design od Experiment - Zeit und Sicherheit gewinnenDesign od Experiment - Zeit und Sicherheit gewinnen
Design od Experiment - Zeit und Sicherheit gewinnen
 
Die unendliche User Geschichte: Orientierung in agilen Projekten
Die unendliche User Geschichte: Orientierung in agilen ProjektenDie unendliche User Geschichte: Orientierung in agilen Projekten
Die unendliche User Geschichte: Orientierung in agilen Projekten
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
 
Rasterpunkt GmbH: Schulungskalender Output Management Solutions
Rasterpunkt GmbH: Schulungskalender Output Management Solutions Rasterpunkt GmbH: Schulungskalender Output Management Solutions
Rasterpunkt GmbH: Schulungskalender Output Management Solutions
 
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
Roadshow 2019: Praxistipps für die erfolgreiche Einführung von Camunda in Ihr...
 
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der PraxisResponsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
 
dictaJet im Produktinformationsmanagement
dictaJet im ProduktinformationsmanagementdictaJet im Produktinformationsmanagement
dictaJet im Produktinformationsmanagement
 
Erfahrungen mit agilen Festpreisen
Erfahrungen mit agilen FestpreisenErfahrungen mit agilen Festpreisen
Erfahrungen mit agilen Festpreisen
 
Gamification im Projektmanagement
Gamification im ProjektmanagementGamification im Projektmanagement
Gamification im Projektmanagement
 
Camunda BPM 7.2 - Deutsch
Camunda BPM 7.2 - DeutschCamunda BPM 7.2 - Deutsch
Camunda BPM 7.2 - Deutsch
 
Einführung in SCRUM
Einführung in SCRUMEinführung in SCRUM
Einführung in SCRUM
 

Mehr von GFU Cyrus AG

Social Media im Unternehmen
Social Media im UnternehmenSocial Media im Unternehmen
Social Media im Unternehmen
GFU Cyrus AG
 
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
GFU Cyrus AG
 
Clean Code Developer
Clean Code DeveloperClean Code Developer
Clean Code Developer
GFU Cyrus AG
 
Cross-Apps-Entwicklung für iPhone, Android und Co.
Cross-Apps-Entwicklung für iPhone, Android und Co.Cross-Apps-Entwicklung für iPhone, Android und Co.
Cross-Apps-Entwicklung für iPhone, Android und Co.
GFU Cyrus AG
 
Softwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration ToolsSoftwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration Tools
GFU Cyrus AG
 
Datenschutz bei Facebook & Co. - Wie schütze ich meine persönlichen Daten im ...
Datenschutz bei Facebook & Co. - Wie schütze ich meine persönlichen Daten im ...Datenschutz bei Facebook & Co. - Wie schütze ich meine persönlichen Daten im ...
Datenschutz bei Facebook & Co. - Wie schütze ich meine persönlichen Daten im ...
GFU Cyrus AG
 
SharePoint 2010 - Was ist neu, was wird besser!
SharePoint 2010 - Was ist neu, was wird besser!SharePoint 2010 - Was ist neu, was wird besser!
SharePoint 2010 - Was ist neu, was wird besser!
GFU Cyrus AG
 
Java Persistence 2.0
Java Persistence 2.0Java Persistence 2.0
Java Persistence 2.0GFU Cyrus AG
 
Pragmatische Einführung von IT-Servicemanagement - ITIL im Unternehmen - Erfa...
Pragmatische Einführung von IT-Servicemanagement - ITIL im Unternehmen - Erfa...Pragmatische Einführung von IT-Servicemanagement - ITIL im Unternehmen - Erfa...
Pragmatische Einführung von IT-Servicemanagement - ITIL im Unternehmen - Erfa...
GFU Cyrus AG
 
Liferay Portal - ein Webportal für viele Unternehmensanforderungen
Liferay Portal - ein Webportal für viele UnternehmensanforderungenLiferay Portal - ein Webportal für viele Unternehmensanforderungen
Liferay Portal - ein Webportal für viele Unternehmensanforderungen
GFU Cyrus AG
 
PostgreSQL im Produktivbetrieb
PostgreSQL im ProduktivbetriebPostgreSQL im Produktivbetrieb
PostgreSQL im Produktivbetrieb
GFU Cyrus AG
 
Java Server Faces 2.0 - Der Standard für moderne und komponentenbasierte Weba...
Java Server Faces 2.0 - Der Standard für moderne und komponentenbasierte Weba...Java Server Faces 2.0 - Der Standard für moderne und komponentenbasierte Weba...
Java Server Faces 2.0 - Der Standard für moderne und komponentenbasierte Weba...
GFU Cyrus AG
 
Wieviel Web2.0 braucht Ihr Unternehmen?
Wieviel Web2.0 braucht Ihr Unternehmen?Wieviel Web2.0 braucht Ihr Unternehmen?
Wieviel Web2.0 braucht Ihr Unternehmen?
GFU Cyrus AG
 
Neue Features der Java EE 6
Neue Features der Java EE 6Neue Features der Java EE 6
Neue Features der Java EE 6
GFU Cyrus AG
 
Das Java-Spring-Framework in der Praxis
Das Java-Spring-Framework in der PraxisDas Java-Spring-Framework in der Praxis
Das Java-Spring-Framework in der Praxis
GFU Cyrus AG
 
Wissensmanagement bei Volkswagen
Wissensmanagement bei VolkswagenWissensmanagement bei Volkswagen
Wissensmanagement bei Volkswagen
GFU Cyrus AG
 
Professionelle Anforderungsanalyse am Beispiel einer Java-Anwendung zur Betri...
Professionelle Anforderungsanalyse am Beispiel einer Java-Anwendung zur Betri...Professionelle Anforderungsanalyse am Beispiel einer Java-Anwendung zur Betri...
Professionelle Anforderungsanalyse am Beispiel einer Java-Anwendung zur Betri...
GFU Cyrus AG
 
Grenzüberschreitende Geschäftsprozesse mit Microsoft SharePoint und BizTalk
Grenzüberschreitende Geschäftsprozesse mit Microsoft SharePoint und BizTalkGrenzüberschreitende Geschäftsprozesse mit Microsoft SharePoint und BizTalk
Grenzüberschreitende Geschäftsprozesse mit Microsoft SharePoint und BizTalk
GFU Cyrus AG
 
Projekt! - Toll - Ein Anderer Macht`s! - Voraussetzungen für eine erfolgreich...
Projekt! - Toll - Ein Anderer Macht`s! - Voraussetzungen für eine erfolgreich...Projekt! - Toll - Ein Anderer Macht`s! - Voraussetzungen für eine erfolgreich...
Projekt! - Toll - Ein Anderer Macht`s! - Voraussetzungen für eine erfolgreich...
GFU Cyrus AG
 
Standardsoftware in der Versicherungsbranche - Betrachtung eines Paradigmenwe...
Standardsoftware in der Versicherungsbranche - Betrachtung eines Paradigmenwe...Standardsoftware in der Versicherungsbranche - Betrachtung eines Paradigmenwe...
Standardsoftware in der Versicherungsbranche - Betrachtung eines Paradigmenwe...
GFU Cyrus AG
 

Mehr von GFU Cyrus AG (20)

Social Media im Unternehmen
Social Media im UnternehmenSocial Media im Unternehmen
Social Media im Unternehmen
 
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...
 
Clean Code Developer
Clean Code DeveloperClean Code Developer
Clean Code Developer
 
Cross-Apps-Entwicklung für iPhone, Android und Co.
Cross-Apps-Entwicklung für iPhone, Android und Co.Cross-Apps-Entwicklung für iPhone, Android und Co.
Cross-Apps-Entwicklung für iPhone, Android und Co.
 
Softwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration ToolsSoftwarequalitätssicherung mit Continuous Integration Tools
Softwarequalitätssicherung mit Continuous Integration Tools
 
Datenschutz bei Facebook & Co. - Wie schütze ich meine persönlichen Daten im ...
Datenschutz bei Facebook & Co. - Wie schütze ich meine persönlichen Daten im ...Datenschutz bei Facebook & Co. - Wie schütze ich meine persönlichen Daten im ...
Datenschutz bei Facebook & Co. - Wie schütze ich meine persönlichen Daten im ...
 
SharePoint 2010 - Was ist neu, was wird besser!
SharePoint 2010 - Was ist neu, was wird besser!SharePoint 2010 - Was ist neu, was wird besser!
SharePoint 2010 - Was ist neu, was wird besser!
 
Java Persistence 2.0
Java Persistence 2.0Java Persistence 2.0
Java Persistence 2.0
 
Pragmatische Einführung von IT-Servicemanagement - ITIL im Unternehmen - Erfa...
Pragmatische Einführung von IT-Servicemanagement - ITIL im Unternehmen - Erfa...Pragmatische Einführung von IT-Servicemanagement - ITIL im Unternehmen - Erfa...
Pragmatische Einführung von IT-Servicemanagement - ITIL im Unternehmen - Erfa...
 
Liferay Portal - ein Webportal für viele Unternehmensanforderungen
Liferay Portal - ein Webportal für viele UnternehmensanforderungenLiferay Portal - ein Webportal für viele Unternehmensanforderungen
Liferay Portal - ein Webportal für viele Unternehmensanforderungen
 
PostgreSQL im Produktivbetrieb
PostgreSQL im ProduktivbetriebPostgreSQL im Produktivbetrieb
PostgreSQL im Produktivbetrieb
 
Java Server Faces 2.0 - Der Standard für moderne und komponentenbasierte Weba...
Java Server Faces 2.0 - Der Standard für moderne und komponentenbasierte Weba...Java Server Faces 2.0 - Der Standard für moderne und komponentenbasierte Weba...
Java Server Faces 2.0 - Der Standard für moderne und komponentenbasierte Weba...
 
Wieviel Web2.0 braucht Ihr Unternehmen?
Wieviel Web2.0 braucht Ihr Unternehmen?Wieviel Web2.0 braucht Ihr Unternehmen?
Wieviel Web2.0 braucht Ihr Unternehmen?
 
Neue Features der Java EE 6
Neue Features der Java EE 6Neue Features der Java EE 6
Neue Features der Java EE 6
 
Das Java-Spring-Framework in der Praxis
Das Java-Spring-Framework in der PraxisDas Java-Spring-Framework in der Praxis
Das Java-Spring-Framework in der Praxis
 
Wissensmanagement bei Volkswagen
Wissensmanagement bei VolkswagenWissensmanagement bei Volkswagen
Wissensmanagement bei Volkswagen
 
Professionelle Anforderungsanalyse am Beispiel einer Java-Anwendung zur Betri...
Professionelle Anforderungsanalyse am Beispiel einer Java-Anwendung zur Betri...Professionelle Anforderungsanalyse am Beispiel einer Java-Anwendung zur Betri...
Professionelle Anforderungsanalyse am Beispiel einer Java-Anwendung zur Betri...
 
Grenzüberschreitende Geschäftsprozesse mit Microsoft SharePoint und BizTalk
Grenzüberschreitende Geschäftsprozesse mit Microsoft SharePoint und BizTalkGrenzüberschreitende Geschäftsprozesse mit Microsoft SharePoint und BizTalk
Grenzüberschreitende Geschäftsprozesse mit Microsoft SharePoint und BizTalk
 
Projekt! - Toll - Ein Anderer Macht`s! - Voraussetzungen für eine erfolgreich...
Projekt! - Toll - Ein Anderer Macht`s! - Voraussetzungen für eine erfolgreich...Projekt! - Toll - Ein Anderer Macht`s! - Voraussetzungen für eine erfolgreich...
Projekt! - Toll - Ein Anderer Macht`s! - Voraussetzungen für eine erfolgreich...
 
Standardsoftware in der Versicherungsbranche - Betrachtung eines Paradigmenwe...
Standardsoftware in der Versicherungsbranche - Betrachtung eines Paradigmenwe...Standardsoftware in der Versicherungsbranche - Betrachtung eines Paradigmenwe...
Standardsoftware in der Versicherungsbranche - Betrachtung eines Paradigmenwe...
 

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

  • 1. 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!
  • 2. 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
  • 3. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 5 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 6
  • 4. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 7 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. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 8
  • 5. 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. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 9 GPA & Story Cards
  • 6. 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) Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 11 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 12
  • 7. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 13 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
  • 8. 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! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 16
  • 9. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 17 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 18
  • 10. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 19 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
  • 11. 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?! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 22
  • 12. 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. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 23 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
  • 13. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 25 Objekte & Klassen in der Analyse
  • 14. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 27 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 28
  • 15. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 29 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 30
  • 16. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 31 CRC-Karten
  • 17. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 33 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 34
  • 18. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 35 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 36
  • 19. 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
  • 20. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 39 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 40
  • 21. 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! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 41 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 42
  • 22. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 44
  • 23. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 45 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
  • 24. Einige Klassen im Design aus der Seminarverwaltung _____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) Dr. rer. nat. Frank Dopatka + entfallen (Termin T) FrankDopatka@web.de hinzufügen(Date von, Date bis) + Termin Folie 47 .... Zustands-Diagramme
  • 25. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 49 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 50
  • 26. Zustands-Diagramm aus der Seminarverwaltung _____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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 51 Sequenz-Diagramme
  • 27. 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“
  • 28. 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: Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 56
  • 29. 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! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 57 Test-Entwurf aus der Seminarverwaltung _____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!“ FrankDopatka@web.de Folie 58
  • 30. 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. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 59 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 60
  • 31. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 61 Scrum
  • 32. 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! Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 63 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
  • 33. 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 Meetings, Review & Retrospektive _____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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 66
  • 34. Meetings, Review & Retrospektive _____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. Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 67 Pair Programming
  • 35. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 69 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 70
  • 36. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 71 Continous Integration
  • 37. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 74
  • 38. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 75 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 76
  • 39. 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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 78
  • 40. Mit welchen Kunden funktionieren agile Methoden (nicht)? _____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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 79 Mit welchen Programmierern funktionieren agile Methoden (nicht)? _____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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 80
  • 41. Mit welchen Programmierern funktionieren agile Methoden (nicht)? _____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 Dr. rer. nat. Frank Dopatka FrankDopatka@web.de Folie 81 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