Rapid Development

Oberseminar Softwareentwicklung

HTWK – 2005

Johannes Zillmann

Einteilung

Begriffserkärung

4 Säulen des Rapid Developments

4 Dimensionen des Rapid Developments

Kernstrategien des Rapid Developments

Alternativen, verwandte Strategien

Toolunterstützung

Quellen

Rapid Development Begriffserklärung

~ schnelles Entwickeln

weitgefasster Begriff, Vortrag orientiert sich an Steve McConnell's Buch 'Rapid Development'

beinhaltet verschiedene Techniken zur Beschleunigung der Softwareentwicklung aber auch zu Optimierungen im Bereich Fehlerraten, Ausführungszeiten, Usability, Wartbarkeit ... (allgemein: gute 'Software-Entwicklungspraktiken')

Hintergrund

ca 2/3 aller Softwareprojekte überschreiten geplantes Zeitlimit (Gibbs 94)

großer Unterschiede zwischen Entwicklungsgeschwindigkeiten verschiedener Firmen (1:10, Jones 94)

„Rapid product development is not a quick fix solution for getting one product – which is probably already late – to market faster. Instead, it is a strategic capability that must be built from the ground up.“

4 Dimensionen

best mögliche Auslieferungszeit erstreckt sich in 4 Dimensionen:

Mensch (Entwickler, Manager, End-Benutzer)

Prozess (Enwicklungsprozess)

Produkt

Technologie

Dimensionen ineinandergreifen

zu jeder Zeit sollte jede Dimension beachtet werden

Dimensionen – 1. Mensch

wie Firmen haben Menschen verschiedene Entwicklungsgeschwindigkeiten (1:10)

Ausschöpfung menschlichen Potentials ist größter Anssatzfaktor

wichtig sind:

Motivation

Team Selektion/Organisation

Training

Dimensionen – 2. Prozess

umfasst Methodiken aus Bereich Management und Technik

Qualitätssicherung

Prinzipien der Softwareentwicklung

Risiko-Management

effektive Resourcengestaltung

Lifecycle-Planung

Einbeziehung der Kunden/Endnutzer

Dimensionen – 3. Produkt

Geschwindigkeitsvorteile durch:

Reduzieren der Produktgröße

erst essentielle Features

Verwenden von 'high-level' Sprachen

iteratives Entwickeln

Einschränken der Produktcharakteristik

Prioritäten auf einzelne Bereiche setzen

nicht gleichzeitig beste Performance, Robustheit, Wiederverwendbarkeit usw erwarten

Dimensionen - 4. Technologie

Wahl von

Entwicklungssprache(n)

Entwicklungs-, Management-, Infrastrukturtools

verschiedene Sprachen/Tools haben verschiedene Stärken, Schwächen und Risiken

4 Säulen

best mögliche Auslieferungszeit steht auf 4 Säulen:

Vermeiden klassicher Fehler

Anwenden fundamentaler Entwicklungsstrategien

Risiko-Management

Anwenden Zeitplan(schedule) orientierter Praktiken

alle ineinandergreifend und gleichermaßen wichtig

Säulen - 1. klassiche Fehler

Mensch-bezogen (zu wenig Personal, laute überfüllte Büros, zu wenig Kontakt zum Benutzer)

Entwicklungsprozess-bezogen (unzureichende Planung/Design, zu optimistische Zeitplanung)

Produkt-bezogen (zuviele komplexe Features am Anfang, zuviele Prioritäten)

Technologie-bezogen (Ersetzen von Tools mitten im laufenden Projekt, Fehlen automatisierter Sourcenkontrolle)

Säulen - 2. fundamentale Entwicklungsstrategien

Projekt-Management

Anforderungsanalysen

Produktmodellierung (Klassendiagramme,..

Design

Stile (Objektdesign, Datenstruktur, ...)

Konzepte (Modularität, Kapselung, ...)

Säulen - 2. fundamentale Entwicklungsstrategien

Programmkonstruktion

'Coding Guidelines' (Variabelnamen, Layout, ...)

Unit-Tests

Code-Integration (incrementell, evolotionär)

Projekt-Infrastruktur

zentrale Systeme zum Verwaltung von Projektartefakten, Aufgaben, Bugreporte u.ä.

Säulen - 3. Risikomanagement

es gilt :

mögliche Risiken zu identifizieren

deren Folgen zu berechnen

Größe und Wahrscheinlichkeit des Verlustes zu kalkulieren

Säulen - 3. Risikomanagement

Gefahren lauern in allen 4 Dimensionen :

Mensch(Teammitglieder harmonieren nicht, ...)

Prozess(zu viel Papierkram verlangsamt Entwickluingsprozess, ...)

Produkt(kompliziertes Design führt zu unproduktiven Implementationen, ...)

Technologie(Nutzen von selbst in Entwicklung befindlicher Technologie kann Entwicklungsprocess gefährden, ...)

Säulen - 4. Zeitplan orientierte Praktiken

Kern des Unterschieds zwischen 'nur' 'effizienter Entwicklung' und 'effizienter Entwicklung' + 'Rapid Development Praktiken'

verschiedene Projekte haben verschiedene Anforderungen (höhere Geschwindigkeit bedeutet meist höheres Risiko)

verschiedene RD-Strategien für verschiedene Projekte

Zeitplan orientierte Praktiken - zielorientiert

erst bestimmen was man optimieren will

dann festlegen, was man dafür in Kauf nimmt

mögliche Optimierungsziele :

geringere Kosten

größere Entwicklungsgeschwindigkeit

größere Sichtbarkeit des Entwicklungsfortschritts

größere Berechenbarkeit

Ziel sollte sich an Wünschen des Kunden orientieren

Überblick – Geschwindigkeit, Risiko, Sichtbarkeit

Entwicklungsgeschwindigkeit hängt von den gewählten Entwicklungsstrategien ab

schedule

oriented practises

speed

oriented practises

schedule-risk

oriented practises

visibilty

oriented practises

Überblick – Zeit, Kosten, Produkt

Zeit, Kosten und Produkt(-qualität) beeinflussen sich gegenseitig

um eine Geswichtspunkt zu optimieren müssen oft Rückschritte bei beiden anderen in Kauf genommen werden

Zeit

Produkt

Kosten

Zeitplan orientierte Praktiken – otpimale Zeitplaneinschätzung

Entwicklungsdauer hängt von vielen Faktoren ab

schwer und niemals 100%-tig einschätzbar

gute Strategie: den Zeitpunkt wählen, bei dem die Wahrscheinlichkeit ihn einzuhalten bei 50% liegt

50:50

1

2

3

1 - rapid development

2 – efficient development

3 – slow development

Dauer der Fertigstellung

Wahrscheinlichkeit des Einhalten der Zeitplans

Zeitplan orientierte Praktiken – Zeitoptimierung

feststellen an welchen Stellen des Projektes am meisten Zeit verloren geht

dort reduzieren

häufige Fehler:

unrealistische Erwartungen

Einsparung in der Designphase

Zeitplan orientierte Praktiken – Ansatzpunkte

doppelte Arbeit vermeiden (40-50%, Jones 86)

Fehler so schnell wie möglich korrigieren

Feature-Overkill (25%, Jones 94)

reduzieren auf essentielle Features

Anforderungsspezifikationen (10-30%, Boehm 81)

evolutionäres Prototyping, iterative Releases

Vor-Planungsphase

schaffen geeigneter Firmenstrukturen

Zusammenfassung Rapid Development

RD Praktiken sind längerfristig angelegt und variabel auf jeweiliges Projekt abstimmbar

man kann an unterschiedlichsten Stellen ansetzen (4 Dimensionen)

benötigt stabile Grundpaket an „guten/effektiven Softwarepraktiken“ (Säule 1-3)

man kann auf die unterschiedlichsten Ziele optimieren (manchmal mit Synergien, manchmal mit Einschränkungen in anderen Bereichen)

schnellsten Methoden sind nicht immer die effektivsten

Alternative zu Rapid Development

häufig genutzte Strategie:

heure die besten verfügbaren Leute an

motiviere sie so (Geld, Autonomie,..) das sie sich voll für das Projekt aufopfern (60-100 Stundenwoche)

Gefahren :

Erfolgswahrscheinlichkeit ca bei 50%

Motivation auf lange Sicht schwierig

geringe Planbarkeit/Prozesssichtbarkeit

verbraucht Programmierer

ähnliche Herangehensweise -
Extreme Programming

etwas jüngeres Konzept (Vertreter der agilen Software-Entwicklung)

eher für kleinere Teams geeignet

Kernprinzipien

Einfachheit

Feedback

Mut

Qualität

Extreme Programming -
ähnliche Prinzipien

enger Kundenkontakt

kurze Releasezyklen

fortlaufende Integration

Test-First-Design (Unit-Tests, Acceptance-Tests)

prototypische Lösungen

Extreme Programming -
abweichende Prinzipien

einfaches Design (do the simplest thing that might possible work)

häufiges 'Refactoring'

kürzere Designphase

Programmieren in Paaren

Gemeinsame Verantwortung

40 Stundenwoche

Toolsunterstützung für einzelne Prinzipien (java)

automatisierte Sourcenkontrolle: cvs

automatisiertes Buildmanagement: ant/maven

kontinuierliche Integration: cruisecontrol

Verwalten von Aufgaben/Bugs, Visualisieren des Entwicklungsprozesses, iterative Releaseplanung: jira, bugzilla

automatisierte Testumgebung: junit

Literatur

Quellen

Rapid Development – Steve McConnel

Extreme Programming – Kent Beck

2005-05-01T18:37:38