Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
© 2010 Capgemini. All rights reserved. 1
Ramon Anger
Dresden, 04.01.2012
Lean Architecture
© 2011 Capgemini. All rights reserved. 2
Lean-Architecture-2012.pptx
Ego
• Technischer Architekt bei Capgemini • davor debis, T-Systems, TomTom, Materna • als Entwickler, Architekt, Teamleiter, Technischer Projektleiter,
Technischer Consultant, Head of Development
• Diplominformatiker (FH) • Master of Computer Science (M. Comp. Sc.)
• Java BlackBelt (knowledgeblackbelt.com)
Zum Kennenlernen
Aktueller Kunde – Bundesagentur für Arbeit (BA)
• Technischer Architekt bei ALLEGRO • davor ELENA, ALGII, Architekturhandbuch, ITIL2010 • Projektgröße zwischen 15 und 170 MA
© 2010 Capgemini. All rights reserved. 2
© 2011 Capgemini. All rights reserved. 3
Lean-Architecture-2012.pptx
Show hands
• Studiengang • Semester
• Softwarearchitektur • Lean • Lean Architecture • Wasserfallmodell • Scrum
Show hands
© 2011 Capgemini. All rights reserved. 4
Lean-Architecture-2012.pptx
Umgang mit Fragen
• sofort • am Ende
Show Hands
© 2010 Capgemini. All rights reserved. 3
© 2011 Capgemini. All rights reserved. 5
Lean-Architecture-2012.pptx
Was ist SW-Architektur ?
• viele Definitionen
• beschreibt Softwarekomponenten und deren Beziehungen untereinander, so dass ihre Realisierung Anforderungen angemessen erfüllt [BOEHM04]
Die Begriffe
© 2011 Capgemini. All rights reserved. 6
Lean-Architecture-2012.pptx
Was ist gute SW-Architektur ?
• minimiert den Aufwand, um Software zu erzeugen, anzupassen und zu warten, während die Software ein akzeptables Laufzeitverhalten aufweist [SHORE06]
• Wie kommt man zu guter Softwarearchitektur? • Es war einmal …
Die Begriffe
© 2010 Capgemini. All rights reserved. 4
© 2011 Capgemini. All rights reserved. 7
Lean-Architecture-2012.pptx
Die Ausgangssituation
• 1997 • Diplominformatiker (FH) • Systementwickler in IT-Systemhaus
Das erste Projekt
• Entwurf einer Kfz-Briefverwaltung auf Basis vollständig vorliegender fachlicher und technischer Anforderungen im Team mit vier Kollegen
• Konzept ca. 45 Seiten • Wasserfallmodell, Big Front-Up Design (BFUD)
Plangetriebene Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 8
Lean-Architecture-2012.pptx
Das Projektergebnis
Die Retrospektive
• Projekt war irgendwie erfolgreich • Entwurf war fehlerhaft • Anforderungen waren unvollständig / falsch • Anforderungen wurden während der Umsetzung verändert • Architekturanforderungen waren schwer ableitbar
• fehlende Erfahrung • unvollständige und veränderte Anforderungen • fehlende Flexibilität des Entwurfs • etwa 60% Funktionalität wurde nicht benutzt • Dokumentation/Handbuch wurde nicht gelesen
Plangetriebene Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 5
© 2011 Capgemini. All rights reserved. 9
Lean-Architecture-2012.pptx
Der Lerneffekt
• Anforderungen vollständig erfassen • wichtige / unwichtige Anforderungen identifizieren • Anforderungen mit Einfluss auf Architektur identifizieren • Entwurf flexibel gestalten, um auf sich verändernde Anforderungen
reagieren zu können • Verwendung der Dokumentation klären
Plangetriebene Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 10
Lean-Architecture-2012.pptx
Das zweite Projekt
• Entwurf einer Software zur Patientenverwaltung auf Basis vollständiger Anforderungen im Team mit vier Kollegen
• Konzept 60 Seiten • Wasserfallmodell, Big Front-up design • Erfahrungen aus dem Vorprojekt
Anwendung der Erfahrungen aus dem ersten Projekt
• Anforderungen hinterfragen Wirklich vollständig ? Wirklich notwendig ?
• Entwurf flexibel gestalten Konfigurierbarkeit / Erweiterbarkeit berücksichtigen
Plangetriebene Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 6
© 2011 Capgemini. All rights reserved. 11
Lean-Architecture-2012.pptx
Das Projektergebnis
• Projekt war irgendwie erfolgreich • Anforderungen waren unvollständig / falsch • Anforderungen wurden während der Umsetzung verändert • Entwurf nicht flexibel genug, um auf Änderungen
reagieren zu können • Architekturanforderungen waren schwer ableitbar
Die Retrospektive
• immer noch fehlende Erfahrung • Entwurf war besser, aber nicht flexibel genug Flexibilität an den
falschen Stellen • etwa 50% Funktionalität wurde nicht benutzt • Dokumentation/Handbuch wurde kaum benutzt
Plangetriebene Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 12
Lean-Architecture-2012.pptx
Der Lerneffekt
• wichtige von unwichtigen Anforderungen trennen • Anforderungen identifizieren, die Einfluss auf Architektur haben • Entwurf an den richtigen Stellen flexibel gestalten
Plangetriebene Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 7
© 2011 Capgemini. All rights reserved. 13
Lean-Architecture-2012.pptx
Das n-te Projekt
• Entwurf eines satellitengestützten Mautsystems • Konzept etwa 2000 Seiten • Wasserfallmodell, Big Front-Up Design • Erfahrungen aus n-1 Vorprojekten
Anwendung der Erfahrungen aus de vorherigen Projekten
• jede Anforderung hinterfragen • Konfigurierbarkeit / Erweiterbarkeit berücksichtigen • mit veränderten Anforderungen rechnen
Plangetriebene Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 14
Lean-Architecture-2012.pptx
Das Projektergebnis
• das Projekt war alles, aber nicht erfolgreich • viele technische Probleme • Inbetriebnahme mit 2 Jahren Verspätung • voller Funktionsumfang mit 3 Jahren Verspätung • Regressforderungen im Milliardenbereich • Schwerer Imageschaden für Auftraggeber und Auftragnehmer
Die Retrospektive
• Konzepte bereits während der Umsetzung veraltet • damit auch Architekturentwurf veraltet
• Veränderung der Umweltbedingungen • z.B. zweiter Fahrzeuggeräte-Anbieter
• misstrauensorientierte Vertragsgestaltung
Plangetriebene Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 8
© 2011 Capgemini. All rights reserved. 15
Lean-Architecture-2012.pptx
Plangetriebene Vorgehensmodelle sind
• lineare, an Phasen orientierte Verfahren • Wasserfall, V-Modell XT, Rational Unified Process (RUP)
• einfach plan- und überprüfbar • effektiv bei stabilen Anforderungen
• teuer bei Änderungen, Erweiterungen und Fehlern
Plangetriebene Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 16
Lean-Architecture-2012.pptx
Bildquelle: http://commons.wikimedia.org/wiki/File:Fulmer_Falls_Closeup_3000px.jpg
Plangetriebene Vorgehensmodelle
Analyse
Konzept
Design
Umsetzung
Test
Betrieb
© 2010 Capgemini. All rights reserved. 9
© 2011 Capgemini. All rights reserved. 17
Lean-Architecture-2012.pptx
Plangetriebene Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 18
Lean-Architecture-2012.pptx
• Anforderungen aus abgeschlossener Konzeptphase • weisen nur indirekt auf Architektur hin • können unvollständig sein • können Fehler enthalten • sind schwer eindeutig / widerspruchsfrei beschreibbar • sind unter Umständen schnell veraltet und schwer änderbar
• Entwürfe aus abgeschlossener Designphase
• basieren auf fehlerhaften, veralteten, mehrdeutigen, unvollständigen Anforderungen
• transportieren Unzulänglichkeiten aus Vorphasen weiter
• Software aus abgeschlossener Realisierungsphase • … transportieren Unzulänglichkeiten aus Vorphasen weiter
Erkenntnisse aus dem Architekturentwurf (Wasserfall)
Plangetriebene Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 10
© 2011 Capgemini. All rights reserved. 19
Lean-Architecture-2012.pptx
Werkzeuge und Sprachen
• prägen den Architekturentwurf • haben kaum Einfluss auf Qualität der Architektur
• Beispiel: UML-Tool Versionierung
Plangetriebene Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 20
Lean-Architecture-2012.pptx
Plangetriebene Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 11
© 2011 Capgemini. All rights reserved. 21
Lean-Architecture-2012.pptx
Der Lerneffekt
• es muss anders gehen
• es war einmal …
Plangetriebene Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 22
Lean-Architecture-2012.pptx
• Entwickler liefern von Sprint zu Sprint weniger Funktionalität, während Anzahl gefundener Fehler steigt
• entsprechend steigt Aufwand für Fehlerbehebung while (true) {
System.out.exclaim(“Den Fehler habe ich doch letzte Woche
schon behoben!!!“);
}
Es war einmal in einem Scrum-Projekt …
Agile Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 12
© 2011 Capgemini. All rights reserved. 23
Lean-Architecture-2012.pptx
1. Entwickler liefern immer weniger Funktionalität 2. Entwickler benötigen viel Zeit, um Fehler zu beheben 3. Fehler nicht automatisch verifizierbar -
traten durch fehlende Koordination der Versionskontrolle bei mehreren Entwicklern auf
4. keine automatischen Testfälle
Root Cause Analysis
Agile Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 24
Lean-Architecture-2012.pptx
Bildquelle: http://commons.wikimedia.org/wiki/File:Iceberg_1_1997_08_07.jpg
Agile Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 13
© 2011 Capgemini. All rights reserved. 25
Lean-Architecture-2012.pptx
• Fokus in Scrum liegt auf Geschäftswert • keine Ressourcen für Software-Architektur • schwierig, Änderungen vorzunehmen, ohne betroffene Teile des
Systems • zu refaktorisieren • neu zu schreiben
• Refaktorisieren ohne automatische Testfälle
• führt zu neuen Fehlern
• Konsequenz • unwartbare Software
Bildquelle: http://commons.wikimedia.org/wiki/File:Iceberg_1_1997_08_07.jpg
Ursache lag tiefer, als auf ersten Blick ersichtlich …
Agile Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 26
Lean-Architecture-2012.pptx
• keine Konzeptdokumente • User stories
• beschreiben Funktionalität, die für Benutzer / Käufer der SW von Wert ist [COHN10]
Als [Rolle] will ich [Funktionalität], um [Geschäftswert].
Als [Sachbearbeiter] will ich [automatisch über Wiedervorlagen informiert werden], um [keine gesetzlichen Fristen zu verpassen].
Kunde: OK. Kauf‘ ich!
Anforderungen in Scrum
Agile Vorgehensmodelle
© 2010 Capgemini. All rights reserved. 14
© 2011 Capgemini. All rights reserved. 27
Lean-Architecture-2012.pptx
• Als [Implementierer] will ich [den Komponentenschnitt der Archivierungsschnittstelle ändern], um [leichter auf Änderungen reagieren zu können].
• Kunde: Häh? Kauf‘ ich nicht!
• Aufwände im Zusammenhang mit Architektur / Design werden • versteckt • vernachlässigt
• Technische Schulden resultieren
Architektur und Design schaffen keinen Geschäftswert
Agile Vorgehensmodelle
© 2011 Capgemini. All rights reserved. 28
Lean-Architecture-2012.pptx
• Scrum • Management-Methodik für Software-Entwicklung • kann gut auf Änderungen reagieren • keine Methodik zum Architekturmanagement
• Certified Scrum Master Training
• Design Sprint 0 Dauer 1-3 Wochen
• James Coplien: “Don‟t even think this first sprint can take less than half a year.” • natürlich in Abhängigkeit vom betroffenen System
Agile Vorgehensmodelle
Architektur und Design schaffen keinen Geschäftswert
© 2010 Capgemini. All rights reserved. 15
© 2011 Capgemini. All rights reserved. 29
Lean-Architecture-2012.pptx
• Feature Driven Development (FDD) • Behaviour Driven Development (BDD) • Test Driven Development (TDD) • Scrum • Kanban • Scrumban • Crystal clear • Naked Planning • Extreme Programming (XP)
• Pair programming, Continuous integration, User stories, Refactoring, Evolutionary design, Rapid prototyping
• Agile Methoden unterstützen irgendwie Flexibilität, aber nur beschränkt auf der Ebene der Architektur
Agile Vorgehensmodelle
Einige Agile Methoden
© 2011 Capgemini. All rights reserved. 30
Lean-Architecture-2012.pptx
Was ist Lean, Lean Management, Lean Production ?
• während Ölkrise 1973 in Japanischer Automobilindustrie entstanden • Förderung der MA • Reduktion von Verschwendung • Steigerung der Effizienz
• Beispiel: JIT-Lieferung von Rohmaterial keine
Lagerhaltungskosten
Lean
© 2010 Capgemini. All rights reserved. 16
© 2011 Capgemini. All rights reserved. 31
Lean-Architecture-2012.pptx
Was ist Lean Architecture ?
• Schlanke Architektur ? • Effiziente Architektur ?
• Annäherung über Lean Prinzipien
Lean
© 2011 Capgemini. All rights reserved. 32
Lean-Architecture-2012.pptx
• Workflow visualisieren • Einsatz der richtige Werkzeuge • Gleichmäßige Aufgabenverteilung • Pull statt Push • Wertflussoptimierung • Entscheidungen mit langfristigem Fokus treffen • Probleme zuerst lösen • Menschen und Teams weiterentwickeln • Entscheider aus dem Team • Selbst kümmern • Entscheidungen im Konsens treffen • Lean weitertragen • Kontinuierliche Verbesserung • Regeln gemeinsam definieren
Lean Prinzipien
14 Lean Prinzipien
© 2010 Capgemini. All rights reserved. 17
© 2011 Capgemini. All rights reserved. 33
Lean-Architecture-2012.pptx
• Pull statt Push • Architektur nicht vollständig im Voraus beschreiben, sondern
nur den Teil, der für aktuelles Problem relevant ist • Wertflussoptimierung
• Softwarelieferung an Kunden in kurzen Lieferzyklen • Kundenfeedback fließt in Architekturentwurf ein
• Probleme zuerst lösen • Treten Probleme mit Architektur auf, tieferen Grund suchen
Lean Prinzipien
Lean Prinzipien generell auf Architektur übertragbar
© 2011 Capgemini. All rights reserved. 34
Lean-Architecture-2012.pptx
• Menschen und Teams weiterentwickeln • Freiraum, um Methoden, Frameworks und Muster auf
Verbesserungspotential für Architektur zu untersuchen • Team profitiert davon
• Entscheidungen im Konsens treffen • Architektur ist Dienstleistung für Team
• Kontinuierliche Verbesserung • Architektur ständig hinterfragen und nach Optimierung suchen
Lean Prinzipien
Lean Prinzipien generell auf Architektur übertragbar
© 2010 Capgemini. All rights reserved. 18
© 2011 Capgemini. All rights reserved. 35
Lean-Architecture-2012.pptx
Lean Prinzipien
Architektur ist immer in Vorgehensmodell eingebettet
• Wie gut unterstützen Vorgehensmodelle Lean Prinzipien ?
© 2011 Capgemini. All rights reserved. 36
Lean-Architecture-2012.pptx
Lean Prinzipien
Lean Prinzipien auf plangetriebene/agile Methoden übertragbar?
Workflow visualisieren Plangetrieben Agil
Einsatz der richtige Werkzeuge
Gleichmäßige Aufgabenverteilung
Pull statt Push
Wertflussoptimierung
Entscheidungen mit langfristigem Fokus treffen
Probleme zuerst lösen
Menschen und Teams weiterentwickeln
Entscheider aus dem Team
Selbst kümmern
Entscheidungen im Konsens treffen
Lean weitertragen
Kontinuierliche Verbesserung
Regeln gemeinsam definieren
© 2010 Capgemini. All rights reserved. 19
© 2011 Capgemini. All rights reserved. 37
Lean-Architecture-2012.pptx
Schlussfolgerungen
Schlüsse aus Gegenüberstellung - plangetrieben / agil / lean
• Plangetriebene Vorgehensmodelle für Anwendung von Lean Prinzipien ungeeignet
• bei Interaktion zwischen Projektteilnehmern sind klare Regeln vorgegeben
• Agile Methoden unterstützen Lean Prinzipien • wo keine explizite Unterstützung vorliegt, werden Prinzipien
nicht behindert
© 2011 Capgemini. All rights reserved. 38
Lean-Architecture-2012.pptx
Schlussfolgerungen
Schlüsse aus Gegenüberstellung - Architekturaspekte
• Agile Methoden können durch Lean Prinzipien Lean Architecture erreichen
• Voraussetzung: Regeln der Methode in Bezug auf die Architektur um Lean Prinzipien erweitern
• Bei Plangetriebene Methoden wegen fehlender Unterstützung der Lean Prinzipien nicht denkbar
© 2010 Capgemini. All rights reserved. 20
© 2011 Capgemini. All rights reserved. 39
Lean-Architecture-2012.pptx
Schlussfolgerungen
Schlüsse aus Gegenüberstellung – Erweiterung der Regeln
• Lösung hin zu angemessenen Architekturentwürfen unter Berücksichtigung der Lean Prinzipien liegt nur indirekt zwischen Agilität und plangetriebenen Verfahren
• Regeln plangetriebener Verfahren müssen aufgeweicht, Regeln agiler Verfahren erweitert werden
© 2011 Capgemini. All rights reserved. 40
Lean-Architecture-2012.pptx
Schlussfolgerungen
Erweiterung zur Unterstützung der Lean Prinzipien
Chaos Ordnung
Plan-getriebene Vorgehens-modelle
Agile Vorgehens-modelle
© 2010 Capgemini. All rights reserved. 21
© 2011 Capgemini. All rights reserved. 41
Lean-Architecture-2012.pptx
Schlussfolgerungen
Hilfsmittel für Unterstützung der Lean Prinzipien erforderlich
• Welche Hilfsmittel gibt es, Lean Architecture zu unterstützen? • Hilfsmittel meint nicht Werkzeuge und Sprachen!
• Werkzeuge haben wenig Einfluss
© 2011 Capgemini. All rights reserved. 42
Lean-Architecture-2012.pptx
Schlussfolgerungen
Hilfsmittel für Unterstützung der Lean Prinzipien erforderlich
• Angemessene Prozesse • Koevolutionsmodell • Identifikation häufig/seltener Änderung Coplien-Methodik • YAGNI – You Ain„t Gonna Need It • Angemessene Architekturdokumentation • Refactoring, nicht nur im Code
© 2010 Capgemini. All rights reserved. 22
Backup
© 2011 Capgemini. All rights reserved. 44
Lean-Architecture-2012.pptx
Angemessenheit der Geschäftsprozesse
45
19
16
13
7
Niemals
Selten
Manchmal
Oft
Immer
Wie häufig werden Features eines Systems durchschnittlich genutzt? [Standish Group 1994]
© 2010 Capgemini. All rights reserved. 23
© 2011 Capgemini. All rights reserved. 45
Lean-Architecture-2012.pptx
Angemessenheit der Geschäftsprozesse
45
19
16
13
7
Niemals
Selten
Manchmal
Oft
Immer
Wie häufig werden Features eines Systems durchschnittlich genutzt?
© 2011 Capgemini. All rights reserved. 46
Lean-Architecture-2012.pptx
Angemessenheit der Geschäftsprozesse
Hilfsmittel für Unterstützung der Lean Prinzipien erforderlich
• zwischen 20 und 36 Prozent der Features wirklich benötigt • restliche 64 bis 80 Prozent der Features auf keinen Fall realisieren • Komplexität des Systems reduziert sich auf etwa ein Drittel • Architektur des betroffenen Systems weniger komplex
© 2010 Capgemini. All rights reserved. 24
© 2011 Capgemini. All rights reserved. 47
Lean-Architecture-2012.pptx
Koevolutionsmodell
• Wasserfall: Problem ermitteln Lösung ermitteln
• Koevolution von Problem- und Lösungsraum • werden parallel weiterentwickelt und tauschen Informationen • nähern sich immer weiter an
• Vertreter • Rapid Prototyping XP • Divide, Conquer Integrate Scrum • inkrementelles Design XP
Koevolutionsmodell
© 2011 Capgemini. All rights reserved. 48
Lean-Architecture-2012.pptx
Koevolutionsmodell
Beschreibung des Problems
Entwicklung der Lösung
Problembeschreibung 1 Problembeschreibung 2 Problembeschreibung 3
Prototyp 1 Prototyp 2 Prototyp 3
Koevolutionsmodell des Designs nach Maher, Poon und Boulanger von 1996
[BROOKS11, S. 79]
© 2010 Capgemini. All rights reserved. 25
© 2011 Capgemini. All rights reserved. 49
Lean-Architecture-2012.pptx
Coplien-Methodik
• Zwei Sichten auf ein SW-System • Was das System kann
• funktionale Anforderungen (Use cases, User stories) • nicht-funktionale Anforderungen (Sicherheit, Performance) • Rahmenbedingungen (Zeitrahmen)
• Was das System ist, also • über welche Eigenschaften das SW-System verfügt, um
Fähigkeiten (Was das System kann) zu ermöglichen • Architektur
Ansatz zur Identifikation von Architektur nach [COPLIEN10]
© 2011 Capgemini. All rights reserved. 50
Lean-Architecture-2012.pptx
Coplien-Methodik
• Trennung der Dinge • die sich wahrscheinlich häufig ändern • die sich wahrscheinlich selten ändern
Ansatz zur SW-Partitionierung nach [COPLIEN10]
• komplexe SW-Systeme in Teilsysteme zerlegen, damit • parallele Bearbeitung (Team) möglich ist • kritische Funktionen (Features) unabhängig bearbeitbar sind
• ein Layer (z.B. DB-Schicht) ist kein Feature FDD Literatur • (SOA-)Service kann Feature sein
Ansatz zur SW-Partitionierung nach [POPPENDIECK07]
© 2010 Capgemini. All rights reserved. 26
© 2011 Capgemini. All rights reserved. 51
Lean-Architecture-2012.pptx
Coplien-Methodik
Welche Teile eines Gebäudes ändern sich eher häufig / selten ?
© 2011 Capgemini. All rights reserved. 52
Lean-Architecture-2012.pptx
Coplien-Methodik
Welche Teile eines Gebäudes ändern sich eher häufig / selten ?
• Fundament • Keller • Außenwand • Dach • Fenster • Innenwand • Tür • Bodenbelag • Wasserleitung • Stromleitung • Schreibtisch • Blumentopf
© 2010 Capgemini. All rights reserved. 27
© 2011 Capgemini. All rights reserved. 53
Lean-Architecture-2012.pptx
Coplien-Methodik
• zwischen 40 bis 90 Prozent der Kosten für ein SW-System entstehen, nachdem das SW-System produktiv gegangen ist
• weil Software verändert wird [POPPENDIECK11]
• Beispiel ALGII/A2LL • Projektstart Herbst 2003 • Produktivsetzung im Herbst 2004
• Kosten 7,5 Millionen € • Gesundheitsreform 2007
• Kosten für eine SW-Änderung > 15 Millionen € • Beschluss der BA zur Ablösung von A2LL im Frühjahr
2008
Warum Unterscheidung nach häufiger / seltener Änderung ?
© 2011 Capgemini. All rights reserved. 54
Lean-Architecture-2012.pptx
Coplien-Methodik
• aus Retrospektiven • Änderbarkeit an den richtigen Stellen einbauen
• Was ist Software ?
• Teil eines Systems, der sich ändert • sonst wäre es Hardware
Warum Unterscheidung nach häufiger / seltener Änderung ?
• Änderbarkeit an richtigen Stellen Begrenzung von Änderungsaufwänden
Was ist daran Lean ?
© 2010 Capgemini. All rights reserved. 28
© 2011 Capgemini. All rights reserved. 55
Lean-Architecture-2012.pptx
YAGNI
• “Always implement things when you actually need them, never when you just foresee that you need them.” [CUNNINGHAM10]
• 60 Prozent aller Software-Funktionalität werden kaum oder gar nicht benutzt
• baue Dinge nicht auf Vorrat
• Ist YAGNI auf SW-Architektur anwendbar? • nur indirekt • Architektur … Eigenschaften über die das SW-System verfügt,
um Fähigkeiten (Was das System kann) zu ermöglichen
• Architektur zum spätesten möglichen Zeitpunkt zu implementieren meint nicht Architektur zum spätesten möglichen Zeitpunkt zu planen
YAGNI - You ain‘t gonna need it
© 2011 Capgemini. All rights reserved. 56
Lean-Architecture-2012.pptx
YAGNI
YAGNI vs. BFUD
Aufwand für Architektur
Langfr
istige K
oste
n
Abbildung nach [COPLIEN11]
BUFD YAGNI
© 2010 Capgemini. All rights reserved. 29
© 2011 Capgemini. All rights reserved. 57
Lean-Architecture-2012.pptx
Architekturdokumentation
• Beschreibung der Struktur eines Softwaresystems mit Dokumenten und Modellen
• wichtig für • Verständnis des Systems • Nachvollziehbarkeit von Entwurfsentscheidungen
• aufwändig
Architekturdokumentation ist
© 2011 Capgemini. All rights reserved. 58
Lean-Architecture-2012.pptx
Architekturdokumentation
Code Benutzermasken
Dokumente Diagramme
Ko
sten
Code Benutzermasken --------------------> Entwicklungskosten
Gesamtkosten
Kommunikations-kosten
Entwicklungsfremde Kosten
Kosten der Softwareentwicklung [nach LUI08]
© 2010 Capgemini. All rights reserved. 30
© 2011 Capgemini. All rights reserved. 59
Lean-Architecture-2012.pptx
Architekturdokumentation
• Bedarf besteht
• Änderungen mit vertretbarem Aufwand machbar sind • lieber keine als eine falsche Dokumentation
Architekturdokumentation in dem Umfang erzeugen, für den
© 2011 Capgemini. All rights reserved. 60
Lean-Architecture-2012.pptx
Refactoring
• ist Anpassung der inneren Struktur/des inneren Verhaltens von Software, während äußeres Verhalten unverändert bleibt
• interne Anpassung der Software erfolgt zur Verbesserung ihres Designs
• Äußeres Verhalten durch automatische Tests validieren
Refactoring
© 2010 Capgemini. All rights reserved. 31
© 2011 Capgemini. All rights reserved. 61
Lean-Architecture-2012.pptx
Refactoring
• Beschränkung auf Codeebene greift zu kurz • Konsolidierung der Anwendungslandschaft einer Organisation oder
Aktualisierung eines Standards als Refactoring interpretierbar • Auf dieser Abstraktionsebene ist Testvorgehen schwer erzeugbar
• Beibehaltung des äußeren Verhaltens muss durch anderes Konstrukt überprüft werden.
Refactoring
Bei Fragen fragen
© 2010 Capgemini. All rights reserved. 32
Vielen Dank
Quellen
© 2011 Capgemini. All rights reserved. 64
Lean-Architecture-2012.pptx
BOEHM04: Barry Boehm, Richard Turner - Balancing Agility and Discipline, S. 13, Addison-Wesley, 2004
BROOKS11: Frederick P. Brooks - Erfolgreiches Design, S.79, MITP Heidelberg, 2011
COHN10: Mike Cohn - User Stories, S. 26, MITP Heidelberg, 2010
COPLIEN10: James Coplien - Lean Architecture for Agile Software Development, Wiley, 2010
CUNNINGHAM10: Cunningham & Cunningham - You arent gonna need it, http://c2.com/cgi/wiki?YouArentGonnaNeedIt
LUI08: Kim Man Lui, C. C. Chan: Software Development Rhythms: Harmonizing Agile Practices for Synergy; Wiley & Sons, 2008
POPPENDIECK07: Mary & Tom Poppendieck - Implementing Lean Software Development, Addison-Wesley, 2007
SHORE06: James Shore - Quality With a Name, http://jamesshore.com/Articles/Quality-With-a-Name.html, 2006
© 2010 Capgemini. All rights reserved. 33
Weiterführende Literatur
© 2011 Capgemini. All rights reserved. 65
Lean-Architecture-2012.pptx
David J. Anderson: Kanban – Evolutionäres Change Management …, dpunkt.verlag, 2011
Mike Cohn: Succeeding with Agile - Software Development Using Scrum, Addison-Wesley, 2009
Eliyahu M. Goldratt: Theory of Constraints, North River Press, 1990
Craig Larman, Bas Vodde: Scaling Lean and Agile Development, Addison-Wesley, 2008
Stephen R. Palmer: A Practical Guide to Feature-Driven Development, Prentice Hall, 2002
Mary & Tom Poppendieck: Leading Lean Software Development, Addison-Wesley, 2009
Wer wir sind
Juni 2010
© 2010 Capgemini. All rights reserved. 34
Lean-Architecture-2012.pptx
1/4/2012© 2010 Capgemini – All rights reserved 67
Capgemini – der weltweit größte Dienstleister für Consulting, Technology und Outsourcing mit europäischem Ursprung
Zusammenarbeit Servicebereiche Globale Sektoren
Fakten1
Zusammenarbeit ist das zentrale Element der Capgemini-Philosophie und gleichzeitig die Säule unseres Leistungsangebots. Sie trägt zur Wertschöpfung bei, begrenzt Risiken, optimiert Kapazitäten und richtet die Organisation auf Zielerreichung aus. Wir nennen dies Collaborative Business ExperienceTM.
• Consulting Services (Capgemini Consulting)
• Technology Services
• Outsourcing Services
• Local Professional Services (Sogeti)
• Energy & Utilities, Chemicals
• Financial Services
• Manufacturing, Retail & Distribution
• Public Sector
• Telecom, Media & Entertainment
• 8,371 Mrd. EUR Umsatz
• 90.516 Mitarbeiter weltweit, davon 36.236 im globalen Liefernetz-werk Near- und Offshore
• Mehr als 300 Standorte in mehr als 30 Ländern
• Börsennotiert in Paris als Cap Gemini S.A.
Nordamerika 7.950
GB & Irland 7.844
Frankreich 19.771
Südeuropa 6.714
Skandinavien 3.681
Zentraleuropa 7.724
Benelux 11.163
Asien/Pazifik 1.830
Lateinamerika 1.661
Indien 22.178
Geografische Verteilung der Capgemini-Mitarbeiter1
1 Stand: 31. Dezember 2009
Lean-Architecture-2012.pptx
1/4/2012© 2010 Capgemini – All rights reserved 68
Mit unseren Services liefern wir unseren Kunden maßgeschneiderte Lösungen – nachhaltig, zuverlässig und kostenoptimiert
% des globalen Umsatzes in 2009
Technology Services
Consulting Services
Local Professional Services
Outsourcing Services
Consulting Services (Capgemini Consulting)
Technology Services
Outsourcing Services
Local Professional Services
(Sogeti)
• Strategy and Transformation Consulting
• Technology Transformation
• Operations Transformation
• Business Technology
• Process Consulting & Package Based Solutions
• Custom Solution Development
• Application Management
• Business Information Management
• Business Process Outsourcing
• Infrastructure Outsourcing
• Government, Service Desk & Management
• Software Quality Management & Testing Services
• Infrastructure Services
© 2010 Capgemini. All rights reserved. 35
Lean-Architecture-2012.pptx
1/4/2012© 2010 Capgemini – All rights reserved 69
Branchen
• Automotive • Energy & Utilities, Chemicals • Financial Services • Manufacturing, Retail & Distribution • Public Sector • Telecom, Media & Entertainment
Technology Services steht für leistungsfähige Prozess- und Softwarelösungen, die die Wettbewerbsfähigkeit unserer Kunden erhöhen
• Umsetzungsorientierte Beratung • Management komplexer IT-Projekte • Software-Engineering
– Gestaltung anspruchsvoller IT-Architekturen – Implementierung von Standardsoftwarepaketen
(insbesondere SAP®- und Oracle-Pakete) – Rightshore®
– Forschung & Innovation • Collaborative Business ExperienceTM
Unsere Kunden sind namhafte Unternehmen aller Branchen sowie öffentliche Institutionen, deren Erfolg von anspruchsvollen Prozess- und Softwarelösungen abhängt. Ihr Nutzen besteht in erhöhter Wettbewerbsfähigkeit durch • Differenzierung bei unternehmenskritischen Lösungen • Effizienzverbesserung bestehender Lösungen
Kunden
Leistungsangebot
• Business Technology • Process Consulting & Package Based Solutions • Custom Solution Development • Application Management • Business Information Management
Standorte in Deutschland, Österreich, Schweiz
Kompetenzen
Rightshore®-Standorte für die Region Deutschland, Österreich und Schweiz
Rightshore® ist eine eingetragene Marke von Capgemini
Wien
Berlin Hannover
Hamburg
Düsseldorf
Köln/Bonn
Stuttgart München
Walldorf
Frankfurt
Offshore
Mumbai
Bangalore
Kolkata
Zürich
Warszawa
Wrocław
Nearshore
Pune
Hyderabad
www.capgemini.com
The information contained in this presentation is proprietary. ©2011 Capgemini. All rights reserved
© 2010 Capgemini. All rights reserved. 36
© 2011 Capgemini. All rights reserved. 73
Lean-Architecture-2012.pptx
Die Inhalte dieser Präsentation (u.a. Texte, Grafiken, Fotos, Logos etc.) sowie die Präsentation selbst
sind urheberrechtlich geschützt. Alle Rechte stehen, soweit nicht anders gekennzeichnet,
Capgemini zu.
Capgemini gestattet ausdrücklich die öffentliche Zugänglichmachung kleiner Teile der Präsentation
zu Zwecken der nicht kommerziellen Lehre und Forschung.
Jede darüber hinausgehende Nutzung ist nur mit ausdrücklicher, schriftlicher Einwilligung
von Capgemini zulässig.
Haftungsausschluss
Auch wenn diese Präsentation und die damit zusammenhängenden Ergebnisse nach bestem Wissen
und sorgfältig erstellt wurden, übernimmt weder Capgemini, noch der/die Autoren, eine Haftung
für deren Verwendung.
Bei Fragen wenden Sie sich bitte an:
Capgemini Deutschland GmbH
Ramon Anger
Kurfürstendamm 22
10719 Berlin
0151/4025 1902
ramon.anger [at] capgemini.com
Forschung und Lehre leben vom Gedankenaustausch, dabei helfen klare Vereinbarungen: