agile geschäftsprozeßanalyse ooa/d am beispiel einer seminarverwaltung

Thema

Agile Geschäftsprozeßanalyse (GPA),objektorientierte Analyse & Design (OOA/D)

am Beispiel einer Seminarverwaltung Referent

Dr. Frank Dopatka, GFU Cyrus AG

Vortrag am Dienstag, 10. März 2009

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

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 [email protected] Folie 4

Die GFU Cyrus AG verwendete

von 1988 bis Ende 2008

ein in Cobol selbst geschriebenes Programm zur • Verwaltung der Kunden, • deren Ansprechpartner und zur • Dokumentation der Kommunikation von

GFU-Mitarbeitern mit den Kunden (Vorgänge).

• Auch zur Fakturierung verwendet.• Über eine Kalenderfunktion wurden die

Seminare, Anmeldungen von Teilnehmern, Hotel- & Parkplatzbelegung verwaltet.

Was existierte bislang?

_____INHALT_____

Fallbeispiel






• Angebote: in den letzten Jahren in MS Word 97 erstellt

• Zusätzlich: 8 Jahre altes Programm zur Seminar-verwaltung, das in VB6 geschrieben wurde Abgleich mit den Internet-Daten

So sah die Kundenverwaltung & Fakturierung aus...

_____INHALT_____

Fallbeispiel






So sah die Seminarverwaltung aus...

_____INHALT_____

Fallbeispiel






Was soll verbessert werden?

_____INHALT_____

Fallbeispiel






• Das Cobol-Programm berechnet ab 2009 dieKalenderwochen falsch, eine Anpassung ist„schwierig“ im Quellcode durchzuführen.

• Die Fakturierung soll automatisiert werden.

• Da keine relat. DB-Struktur verwendet wurde,waren Statistiken über Kurserfolge schwierig, z.B. Gewinn aus Schulungen der Kategorie „Java“ermitteln.

• Es sind im Cobol-Programm alte Funktionenvorhanden, die nicht mehr verwendet werden, u.a. - Verwaltung von Lizenznummern und- Verwaltung von Update-Abos ...aus Zeiten, in denen bei der GFU noch Cobol-Compiler verkauft wurden.

Was wird im Vortrag behandelt?

_____INHALT_____

Fallbeispiel






Im Folgenden wird exemplarisch gezeigt, wie man mit • einer Geschäftsprozeß-Analyse (GPA)• einer Objektorientierten Alalyse (OOA) und• einem Objektorientierten Design (OOD)

einen Lösungsansatz für die zu erstellende Software ermitteln kann.

Im Fokus steht dabei• der Zusammenhang der verschiedenen

UML-Diagramme, deren Blickwinkel sowie• die Anwendung agiler Methoden bei der

Softwareentwicklung.

GPA & Story Cards

Was macht man in der GPA & OOA?

_____INHALT_____

Fallbeispiel






• In der Analyse geht es darum, die Anforderungenzu erfassen:Fakten sammeln, darstellen, prüfen

Objektorientierte Analysemodell:- fachliche Beschreibung mit OO-Konzepten- hebt das Wesentliche hervor und lässt

Unwichtiges weg

• Bezug zur Informationstechnik ist unerwünscht!

• OOA-Modell sollte statische & dynamischeAspekte enthalten ( Datenstrukturen & Abläufe)

Was sind Story Cards?

_____INHALT_____

Fallbeispiel






• User Story („Benutzergeschichte“):- eine in Alltagssprache formulierte Software-

Anforderung- bewusst kurz gehalten: nicht mehr als zwei Sätze

• Jede User Story wird auf eine Story Cardgeschrieben. Autor: Kunde bzw. User

• Die Story Card ist die wichtigste Methode, um ein agiles Projekt zu steuern!

• Aus den Story Cards entwickeln sich in kooperativer Zusammenarbeit mit dem Kundendie Use Cases Workshops

Inhalt einer Story Card

Datum, fortlaufende Nummer Nummer der übergeordneten Story Card Aktivität: neu / Fehler beheben / Funktion erweitern Funktion umgesetzt

Priorität (Kunde/Programmierer) Risiko & Aufwandschätzung

kurze, präzise Beschreibung Notizen

aktueller Fortschritt: Datum, Status, Aufgabe, Kommentar

_____INHALT_____

Fallbeispiel






Exemplarische Story Card: „Seminarverwaltung“

_____INHALT_____

Fallbeispiel





Use Cases

Was genau sind Use Cases (Anwendungsfälle)?

• Interaktion zwischen Akteuren und dem betrachteten System: Dabei soll ein fachliches Ziel erreicht werden!

• Grafisches UML Use Case:Identifikation der Funktion & der beteiligtenAkteure im Vordergrund

• Informationsgehalt eines graphischen Use Cases ist gering! Use Case Schablone Verlauf textuell beschreiben Bezug zum Geschäftsprozeß Basis kann Story Card sein!

_____INHALT_____

Fallbeispiel







Perspektiven

Use Cases können (wie auch alle anderen UML-Diagramme) in verschiedenen Abstraktions-Ebenenerstellt werden:

_____INHALT_____

Fallbeispiel





WolkeManager-View

Drachen

Meeres-SpiegelUser-View

Muschel

FischEntwickler-View


_____INHALT_____

Fallbeispiel





Exemplarischer grafischer Use Caseder Seminarverwaltung (Manager-View)


_____INHALT_____

Fallbeispiel





Etwas detailliertere Darstellung des Use Cases„Seminare verwalten“

_____INHALT_____

Fallbeispiel





Exemplarischer textueller Use Caseder Seminarverwaltung

Buchen eines Seminars

Ziel:Anmeldebestätigung an den Kunden geschickt.

Vorbedingung:---

Nachbedingung Erfolg:Kunde ist angemeldet.

Nachbedingung Fehlschlag:Mitteilung an Kunden, dass Veranstaltung ausgebucht ist, ausfällt oder nicht existiert.

Akteure:Kunde, GFU-MA

Auslösendes Ereignis: Anmeldung des Kunden liegt vor.

Beschreibung:1. Kundendaten abrufen2. Seminar prüfen3. Anmeldebestätigung erstellen

Erweiterung:1a. Kundendaten aktualisieren1b. Wenn Kunde MA einer Firma ist, Firmendaten erfassen bzw. wenn vorhanden, dann

abrufen und aktualisieren1c. Zahlungsmoral prüfen

Alternativen:1a. Neukunden erfassen, wenn Kunde noch nicht existiert1b. Auf alternative Veranstaltungen hinweisen, wenn ausgebucht1c. Mitteilung „Falsche Veranstaltung“, falls Veranstaltung nicht existiert und auch nichts

ähnliches

Aktivitäten, Szenarien& Geschäftsabläufe

Wozu Aktivitäts-Diagramme?

• Geben die Struktur eines Prozesses als Flussdynamisch wider

• Heben den Steuerungsfluss von Objekten im Geschäftsprozeß untereinander hervor

• Werden typischerweise aufgestellt, wenn die UseCases fertig sind Ziel: grundsätzliche Abläufe darstellen

• Überschneidung der Ansicht zu einem textuellen Use Case ist groß Alternativ dazu anwenden?!

_____INHALT_____

Fallbeispiel






Was ist ein Szenario?

Eine spezifische Sequenz von Aktionen, die das Verhalten des Systems unter bestimmten Bedingungen beschreibt, z.B.:

• Login• Bestellvorgang• Rechnungsstellung• Auszahlung von Geld• Angebotserstellung• …

_____INHALT_____

Fallbeispiel






Im Allgemeinen: Einen Geschäftsprozess des Unternehmens!

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

Aktivitäts-Diagramm der Seminarverwaltung:erfolgreiche Anmeldung

_____INHALT_____

Fallbeispiel






Kunde 1 Seminarverwaltung

:Seminar[status: buchend]

[AnzTN=MaxTN-1]

Suchbegriff „Java Einsteiger“ in die GFU-Seite eingegeben

Seminar auswählen

pers. Daten eingeben

Buchung abschicken

:Seminar[status: ausgebucht]

[AnzTN=MaxTN]

Daten prüfen und ggf. abgleichen

Bestätigung der Buchung senden

Liste der Seminare zurückgeben

Aktivitäts-Diagramm der Seminarverwaltung:fehlerhafte Anmeldung

_____INHALT_____

Fallbeispiel






Objekte & Klassenin der Analyse

Warum noch Objekt-Diagramme?

• Objekt-Diagramme besitzen die gleiche Notation wie Klassen-Diagramme, stellen aber konkrete Beispiele/Instanzen dar:- derFrank: Dopatka, Frank, Schmiedeweg,... Kunde: Name, Vorname, Strasse,...

• In der Praxis als erster Schritt der Analyse leicht verständlich, da anwendungsnah

• Klassen: Abstraktionen der Objekte auf höherem Niveau!

_____INHALT_____

Fallbeispiel






Warum Klassen-Diagramme in der Analyse?

• Klassen-Diagramme existieren vereinfacht in einerAnalyse-Form: Identifikation der Klassen und deren Beziehung zueinander im Vordergrund!

• Klassen und deren Beziehungen orientieren sicham Geschäftsprozeß nicht plötzlich „falsch“

• Beziehungen: textuell beschrieben

_____INHALT_____

Fallbeispiel






Exemplarisches Objekt-Diagramm:ein Seminar

_____INHALT_____

Fallbeispiel






Exemplarisches Objekt-Diagramm:Bezug eines Seminars zu anderen Objekten

_____INHALT_____

Fallbeispiel






_____INHALT_____

Fallbeispiel






Ausschnitt aus einem Klassen-Diagramm (OOA)der Seminarverwaltung

CRC-Karten

Wie kommt man an die Objekte & Klassen?

• Durch Erfahrung!

• Indem Sie in Gesprächen und Beschreibungen achten auf:- nicht-triviale Hauptwörter (Raum, Kunde,...) Klassen

- triviale Hauptwörter, die durch einzelne Zeichenketten, Zahlen oder wahr/falschdarstellbar sind (Name, Mail-Adresse,...) Attribute

- Verben (anlegen, buchen, suchen, stornieren,...) Methoden

- Ausdrücke wie „ist ein“ bzw. „besteht aus“ Vererbung bzw. Aggregation oder Komposition

_____INHALT_____

Fallbeispiel






Was ist eine CRC-Karte?

• Prinzip einer Class-Responsibility-Collaboration-Karte: für jede Klasse eine Karteikarte erstellen & auf dieser deren Eigenschaften zu notieren

• Eine solche Karte besteht aus folgenden Bereichen: - Name der Klasse - Aufgaben der Klasse - Klassen, mit denen die beschriebene Klasse

zusammenarbeitet- Rückseite: wichtigste Attribute und Methoden

_____INHALT_____

Fallbeispiel






Vorteile der CRC-Karten

• Einfache Handhabung:Problemlos Informationen hinzufügen oder streichen

• Unabhängig von Programmiersprachen & Tools

• begrenzte Platz auf die wesentlichen Aufgaben einer Klasse

konzentrieren

_____INHALT_____

Fallbeispiel






Vorgehensweise

• Mit dem Kunden typische Anwendungsfälledefinieren Use Cases

• Anwendungsfälle nacheinander durchspielen Aktivitäten

• Auf den CRC-Karten neue Aufgaben und Partnerklassen festhalten

Mit der Zeit ergibt sich ein vollständiges Bild.

• Wichtig:- Untersuchung aller typischen Anwendungsfälle

& Szenarien- Festhalten aller Details

_____INHALT_____

Fallbeispiel






_____INHALT_____

Fallbeispiel





Beispielhafte CRC-Karte „Seminar“ Klasse „Seminar“

Seminar

Aufgaben:Erstellen und verwalten von Seminaren und deren Inhalten. Man soll Seminare suchen können und im Internet veröffentlichen. Man kann sich anmelden, solange die max. TN-Tahl nicht erreicht ist. Abmelden geht auch jederzeit. Die GFU kann notfalls ein Seminar auch stornieren, wenn keine Anmeldung vorliegt oder der geplante Dozent krank ist und kein Ersatz gefunden werden konnte.

Partnerklassen:Seminarverwaltung, Rechnung, Termin -> (Raum, Dozent, Anmeldungen -> (Teilnehmer))

Risk-Value Priorisierung& Planning Poker

Was wird wie priorisiert & welche Konsequenzen ergeben sich?

Bereits bei den Story Cards wurden die Begriffe• Priorität,• Risiko und• Aufwandschätzungfür jede Funktionalität (Use Case) erwähnt.

Jetzt wissen alle Beteiligten bereits mehr über die Funktionen & Abläufe.

So langsam können Sie folgende Fragenbeantworten...

_____INHALT_____

Fallbeispiel






Was wird wie priorisiert & welche Konsequenzen ergeben sich?

• Wie wichtig ist unserem Kunden dieseFunktionalität? 0..10 Punkte K

• Wie wichtig sehen die Programmierer die Integration der Funktionalität im Kontext der Anwendung?* 0..10 Punkte P

• Wie sehen die Programmierer die Schwierigkeitder technischen Umsetzung (Risiko) derFunktion?* 0..10 Punkte S

• Wie (zeit-)aufwendig sehen die Programmiererdie Umsetzung?* Schätzverfahren COCOMO, Lines Of Code, Function Points Preis dieser Funktion

* basierend auf ihrer Projekterfahrung

_____INHALT_____

Fallbeispiel






Womit fängt man jetzt an?

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

_____INHALT_____

Fallbeispiel






K+P: 12-20S: 6-10

K+P: 12-20S: 0-3

K+P: 0-6S: 0-3

_____INHALT_____

Fallbeispiel






Exemplarische Priorisierungaus der Seminarverwaltung

Planning Poker:Zusammen mit dem Kunden die nächsten Schritte planen!Wie detailliert?vgl. eine Scrum-Aufgabe <16 Mannstunden

Klassen im Design

Von den Klassen zum Code

In der Design-Form beinhalten Klassen-Diagramme alle notwendigen Methoden und Attribute. mit Modellierungs-Werkzeuge Java- oder

C#-Coderümpfe generieren „Nur noch“ mit Funktionalität füllen

_____INHALT_____

Fallbeispiel






Auch Beziehungen zwischen Klassen wie „ein Kunde hat n Rechnungen“

können automatisch in Java-Collections abgebildet werden; u.a. mit ObjectIf von MicroTool

Von den Klassen zum Code

_____INHALT_____

Fallbeispiel






Beispiel: Together Edition for SAP NetWeaver Developer Studio

_____INHALT_____

Fallbeispiel






_____INHALT_____

Fallbeispiel





Einige Klassen im Designaus der Seminarverwaltung

Seminar- ID: Long- Zustand: Enum {existiert, buchend, ausgebucht, durchgeführt, storniert, gelöscht}- Kurzbeschreibung: String- Inhalt: String- SeminarZiel: String- Ort: String- Dauer: Byte- minAnzTN: Byte- maxAnzTN: Byte- Preis: Decimal + Daten anzeigen (): String+ Daten aktualisieren (Date von,...): String+ anmelden (Termin T, Teilnehmer TN)+ abmelden (Termin T, Teilnehmer TN)+ stornieren (Termin T) + entfallen (Termin T) + Termin hinzufügen(Date von, Date bis)....

Seminarverwaltung

- Seminare: ArrayList- instance: Seminarverwaltung

+ getInstance(): Seminarverwaltung+ suche (String Inhalt): Seminar+ suche (Long ID): Seminar....

*

Seminar-Termin

- von: Date- bis: Date

+ DozentZuweisen (Dozent d)+ RaumZuweisen (Raum r)...

* 0: individuelles In-House Seminar

Zustands-Diagramme

Wieso noch Zustandsdiagramme?

Sicht auf alle möglichen Zustände eines Objektes bezieht sich auf genau eine Klasse

Zustandsübergänge treten i.d.R. dadurch auf, dass das betreffende Objekt „angetriggert“ wird Methodenaufruf

Prinzipiell kann jede Methode eines Objektes jederzeit aufgerufen werden:Methodenaufruf Y im Zustand X erlaubt ??? Zustandsdiagramm wenn nicht erlaubt Exception

_____INHALT_____

Fallbeispiel






Sichere Automaten!

Vollständige Zustandsautomaten...

Robustheit der Software:im Alltag werden oft einzelne Methodenaufrufe in bestimmten Zuständen „vergessen“

Ein Objekt ist gegen seinen Zustandsautomatentestbar

_____INHALT_____

Fallbeispiel






Ein Objekt der Klasse „Seminar“:_____INHALT_____

Fallbeispiel






Zustands-Diagrammaus der Seminarverwaltung

Sequenz-Diagramme

Aktivitäten vs. Sequenzen

Aktivitäts-Diagrammen:Abläufe aus Sicht des Geschäftsprozesses mit deren Zuständigkeiten modelliert Fachliches Modell

Nun wurden bereits Klassen, deren Methoden und Beziehung ermittelt...Sequenz-Diagramm:

Darstellung des technisch modellierten Ablaufs darstellen Technisches Modell

• Ablauf von Nachrichten von Objekten untereinander durch gegenseitige Methoden-Aufrufe

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

_____INHALT_____

Fallbeispiel





Sequenz-Diagramm aus der Seminarverwaltung:„Buchung vornehmen“

Test Driven Development&

Feature Driven Development

Was ist Testgetriebene Entwicklung?

• Ziel: Software-Tests vor den zu testendenKomponenten erstellen!

Erstellte Unit-Tests sind Grey-Box-Testsstatt klassischer White-Box-Tests

• Unit-Tests und mit ihnen getestete Units werden stets parallel entwickelt.

• eigentliche Programmierung in kleinen & wiederholten Schritten

• eine Iteration (Dauer: wenige Minuten) hat drei Hauptteile:

_____INHALT_____

Fallbeispiel






Was ist Testgetriebene Entwicklung?

1. Schreiben Sie einen Test für das erwünschte fehlerfreie Verhalten, das implementiert werden soll. Dieser Test wird erst einmal nicht erfüllt bzw. es gibtden Code gibt es noch gar nicht.

2. Änderen/schreiben Sie den Code mit möglichst wenig Aufwand, bis nach dem anschließend angestoßenen Testdurchlauf alle Tests bestanden werden.

3. Räumen Sie im Code auf (Refactoring): - Wiederholungen entfernen- Code abstrahieren- Code nach Konventionen ausrichten- ...- testen!

_____INHALT_____

Fallbeispiel






Test-Entwurfaus der Seminarverwaltung

_____INHALT_____

Fallbeispiel






Test: Seminar anlegen

Vorbedingung:---

prüfbare Nachbedingung Erfolg:Seminar wurde mit seinen Daten in der Seminarverwaltung aufgenommen und eine neue Seminar-ID wurde vergeben.

Nachbedingung erwarteter Fehlschlag:Seminar mit diesem Titel existiert bereits.

Test: Seminar buchen

Vorbedingung:Seminar existriert bereits und istzum 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 noch >3 offene Rechnungen!“

Was ist Feature-getriebene Entwicklung?

FDD wird eingesetzt, um ein (großes) zeitkritisches Projekt (z.B. 15 Monate, 50 Entwickler) durchzuführen.

Jedes Feature stellt einen Mehrwert für den Kundendar.

Die Entwicklung wird anhand eines Feature-Plans organisiert.

Eine wichtige Rolle spielt der Chef-Architekt, der ständig den Überblick über die Gesamtarchitektur und die fachlichen Kernmodelle behält.

_____INHALT_____

Fallbeispiel






Prozesse der Feature-getriebenen Entwicklung

1. Entwicklen Sie ein Gesamtmodell:- Konsens über Inhalt und Umfang des zu

entwickelnden Systems - fachliche Kernmodell grobe Use Cases

_____INHALT_____

Fallbeispiel






2. Erstellen Sie eine Feature-Liste:- nach dem einfachen Schema

<Aktion> <Ergebnis> <Objekt>- Bsp.: „Berechne Gesamtsumme der Verkäufe“- max. zwei Wochen zur Realisierung Risk/Value & Planning Poker

Prozesse der Feature-getriebenen Entwicklung

3. Planen Sie jedes Feature- Reihenfolge der Realisierung festlegen - Fertigstellungstermine je Geschäftsaktivität - Projektleiter, Entwicklungsleiter sowie

Senior-Programmierer beteiligt

_____INHALT_____

Fallbeispiel






4. Entwurf jedes Features- Entwicklerteams zuweisen- Erstellung von Sequenz-Diagrammen - erste Klassen- und Methodenrümpfe

5. Ausprogrammierung der Features - Pair Programming & TDD

Scrum

Was ist Scrum?

• „Das Gedränge“: agiles VorgehensmodellMeetings, Artefakten, Rollen & Werten folgt dem Prinzip der „Schlanken Produktion“

(lean production)

• Teammitglieder organisieren ihre Arbeit weitgehend selbst & wählen auch die eingesetzten Entwicklungswerkzeuge und -Methoden

• Entwicklung ist sehr komplex im Voraus weder in große abgeschlossene

Phasen noch in einzelne Arbeitsschritte(Granularität von Mannstunden) planbar

Selbst-Organisation!

_____INHALT_____

Fallbeispiel






Grundlegende Begriffe des Scrum

• Zentrales Element ist der Sprint: Umsetzung einer Iteration (ca. 30 Tage)

• Vor dem Sprint:Produkt-Anforderungen des Kunden in einemProduct Backlog sammeln beinhaltet alle Funktionalitäten, die der

Kunde wünscht Priorisierung der Funktionen

• Hoch priorisierte Features: 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

_____INHALT_____

Fallbeispiel





Meetings, Review & Retrospektive

Täglich: Daily Scrum Meeting (max. 15min.) Team stellt sich gegenseitig folgende Fragen:• „Bist du gestern mit dem fertig geworden, was du dir

vorgenommen hast?“• „Welche Aufgaben wirst du bis zum nächsten

Meeting bearbeiten?“• „Gibt es ein Problem, das dich blockiert?“

_____INHALT_____

Fallbeispiel






• Nach einem Sprint:Ergebnis einem informellen Review unterziehen:Team & Kunden Ergebnis des Sprints (laufende Software)

vorführen

• Kunde prüft, ob das Sprint-Ergebnis seinen Anforderungen entspricht: Änderungswünsche Product Backlog

_____INHALT_____

Fallbeispiel







• Retrospektive:zurückliegende Sprint-Phase betrachten; zunächst wertfreien Rückblick auf die Ereignisse

• Teilnehmer notieren die wichtigen Ereignisse auf Zetteln.

• Anschließend schreiben die Teilnehmer Antworten auf die Fragen - „Was war gut?“ (Best practice) - „Was könnte verbessert werden?“

(Verbesserungspotential)

• Jedes Verbesserungspotential wird priorisiert undmit Zuständigkeiten versehen.

_____INHALT_____

Fallbeispiel






Pair Programming

Wie funktioniert Pair Programming?

• jeweils zwei Programmierer an einem Rechner

• einer schreibt den Code, der andere: - nachdenken über die Problemstellungen - Code kontrollieren Probleme sofort ansprechen sofort lösen

• Rollen abwechseln & Zusammensetzung derPaare häufig ändern

Ziel: Erhöhung der Software-Qualität

_____INHALT_____

Fallbeispiel






Vorteile des Pair Programming

• Höhere Disziplin: Paare entwickeln eher an der richtigen Stelle & machen kürzere Pausen

• Besserer Code: Man entwickelt man sich weniger leicht in Sackgassen.

• Höhere Moral: spannender & interessanter als alleine

• Collective Code Ownership: alle erlangen Wissen über die gesamte Codebasis, die gemeinsam erstellt wurde

_____INHALT_____

Fallbeispiel






Vorteile des Pair Programming

• Mentoring: Jeder hat Wissen, das andere nicht haben. einfache Wissensverbreitung

• Team-Bildung: Leute lernen sich gegenseitig schneller kennen Zusammenarbeit verbessert

• Weniger Unterbrechungen: Paare werden seltener unterbrochen.

_____INHALT_____

Fallbeispiel






Continous Integration

Motivation

Unit-und Modul-Tests...mit Werkzeugen wie JUnit mitlerweile

automatisiert erstellbar!

Wie können „höhere“ Tests - z.B. Integrationstest, gehandhabt werden?

_____INHALT_____

Fallbeispiel





???

Motivation

Gerade wenn bei der Integration der Komponenten Design-Fehler entdeckt werden, ist dies entsprechend teuer!

_____INHALT_____

Fallbeispiel






Die Idee der Continous Integration

• Kontinuierliche Integration: regelmäßiges, vollständiges Neubilden &Testen einer Anwendung

Änderungen in die Versionsverwaltung einchecken Gesamtsystem neu bauen & automatisch

testen

alle Tests erfolgreich: Änderungen an die nächste Stufe geben

Tests scheitern: Änderungen zurücknehmen (Rollback) zur Korrektur vorlegen

_____INHALT_____

Fallbeispiel






Werkzeuge zur Continous Integration

Voraussetzung: - Versionsverwaltungssystem- zeitnahes Check-In- nur funktional vollständige Blöcke eingecheckt

_____INHALT_____

Fallbeispiel






Das Java-basierte CruiseControl hilft bei der Umsetzung der CI:- Benachrichtigung per E-Mail, - Nutzung von Apache Ant

& anderen Werkzeugen- Web-Oberfläche: aktuellen und vorherigen

Zustand der Software anzeigen


Mit welchen Kunden funktionierenagile Methoden (nicht)?

• experimentierfreudig• selbst erhebliche Ressourcen aufwenden • Worin besteht das Gewek?

... das durch den vereinbarten Preis erworbenwird

• Kunde verzichtet auf formale Spezifikation und bindendes Angebot

• Es darf nicht die Mentalität „das machen wir maleben nebenbei“ vorherrschen

_____INHALT_____

Fallbeispiel






Mit welchen Kunden funktionierenagile Methoden (nicht)?

• Vertreter des Kunden darf selbst nicht gezwungensein, seinen Vorgesetzten eine- Planung im Vorfeld - Erfüllung bestimmter Funktionen zu festgelegten

Terminen zu berichten

• "Kunde vor Ort"-Prinzip Mitarbeiter des Kunden benötigen selbst einen

erheblichen Wissensumfang Sind diese Personen entbehrlich?

_____INHALT_____

Fallbeispiel






• Programmierer: sehr gute Fähigkeiten häufige Änderungen umfangreiche Programmiererfahrung geeignete Werkzeuge

• ausgeprägtes Ego: große Überzeugung von „richtigen Lösungen“ Besitzdenken des geschriebenen Codes äußert: Nicht jeder kann damit umgehen,

dass „sein“ Code von anderen verändert wird

_____INHALT_____

Fallbeispiel






Mit welchen Programmierern funktionierenagile Methoden (nicht)?

• XP weist eine Reihe von Merkmalen auf, - die hohe Disziplin erfordern TDD & CI, permanante Refactorings,

Programmieren in Paaren - und andere, die eine gewisse Disziplin-

losigkeit fördern das Auslassen von Spezifikation

_____INHALT_____

Fallbeispiel






Mit welchen Programmierern funktionierenagile Methoden (nicht)?

Vielen Dank für Ihre Aufmerksamkeit!

Noch Fragen?

Quellen des Vortrags: • Wikipedia <http://de.wikipedia.org>• Vorlesung „Einführung in die Informatik II“

<http://www.bs.informatik.uni-siegen.de/www/lehre/ss09/ei2/index_html>• Fowler, Scott: UML konzentriert; 2. Auflage; Addison Wesley Verlag; ISBN 3-8273-1617-0• Helmut Balzert: Lehrbuch der Software-Technik: Software-Entwicklung; 2. Auflage;

Spektrum-Verlag; ISBN 3-8274-0480-0• Booch, Rumbaugh, Jacobson: Das UML Benutzerhandbuch; Addison-Wesley Verlag;

ISBN 3-8273-2295-2

agile geschäftsprozeßanalyse ooa/d am beispiel einer seminarverwaltung

Technology