Software verbessern,
aber richtig
Dr. Gernot Starke
Slide 2
Slide 2 text
Disclaimer (aka: bad news):
The following talk is free
of Microservices
and Lambdas
Slide 3
Slide 3 text
Dr. Gernot Starke
innoQ Fellow
Software architectures
Design, Development
Evolution, Transformation,
Dokumentation
Reviews, Audits
Analyse und Optimierung
von Entwicklungsprozessen
+49 177 – 728 2570
[email protected]
http://arc42.de
http://aim42.org
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
Velocity & Bugs in normalem System
17
0 Q1-11 Q2-11 Q3-11 Q4-11 Q1-12 Q2-12 Q3-12 Q4-12 Q1-13 Q2-13 Q3-13 Q4-13 Q1-14 Q2-14 Q3-14 Q4-14
20
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
new features
or fixes delivered
production bugs
Slide 6
Slide 6 text
Reale Welt: Geldschulden
Schulden nur auf Antrag.
Rückzahlung a priori geklärt.
Obergrenze für Verschuldung.
Klare Regeln für Risikobewertung.
Schulden explizit in Bilanz.
Software: technische Schulden
Schulden zufällig aufgenommen.
Rückzahlung völlig offen.
Beliebige Schuldenhöhe.
Kaum Kriterien für Risikobewertung.
Schulden implizit und oft unbekannt.
Hilfe, Schulden!
Slide 7
Slide 7 text
Meine Versprechen („Agenda“)
1. Methodisches Verbessern
2. Schlimme Probleme finden
3. Management überzeugen
4. Mittel- und langfristige
Verbesserungen
5. Mit Tagesgeschäft vereinbaren
Slide 8
Slide 8 text
Der Normalfall ...
Management:
Zu teuer.
Zu viele Fehler.
Zu hohe Aufwände.
Zu lange Time-to-Market.
Slide 9
Slide 9 text
Der Normalfall ...
Management:
Zu teuer.
Zu viele Fehler.
Zu hohe Aufwände.
Zu lange Time-to-Market.
Techniker:
Zu hohe technische Schuld.
Zu wenig Verbesserung.
Technologie zu schlecht.
Zu wenig Innovation.
Zu wenig Budget.
Zu wenig Zeit.
Slide 10
Slide 10 text
Meine Versprechen („Agenda“)
1. Methodisches Verbessern
2. Schlimme Probleme finden
3. Management überzeugen
4. Mittel- und langfristige Verbesserungen
5. Mit Tagesgeschäft vereinbaren
analyze evaluate
improve
collect
Slide 11
Slide 11 text
Issue
(Problem, Risk)
Improvement
Cost
Cause
cost of
improvement
improvements
resolve cause
(root) causes
of issues
cost of
issue
solve issue with
improvement(s)
improvement
solves issue(s)
Slide 12
Slide 12 text
Issue
Cost
Improvement
Cost
>
Nur verbessern, wenn
Problem schlimmer ist als Lösung teuer
Improvement
Backlog
Issue List
(problems, risks)
analyze
evaluate
improve
collect…
Slide 15
Slide 15 text
Meine Versprechen („Agenda“)
1. Methodisches Verbessern
2. Schlimme Probleme finden
3. Management überzeugen
4. Mittel- und langfristige Verbesserungen
5. Mit Tagesgeschäft vereinbaren
Iteration 1
Breitensuche in Iterationen
Slide 16
Slide 16 text
analyze
Slide 17
Slide 17 text
Probleme in
kompliziertem System
suchen (0)
• Geschmack,
• Preis,
• Aussehen,
• Lage (des Restaurants)
https://flic.kr/p/6xuSMU
Slide 18
Slide 18 text
Probleme in
kompliziertem System
suchen (1)
• Geschmack,
• Temperatur,
• Aussehen,
• Konsistenz,
• Beliebtheit
Slide 19
Slide 19 text
Probleme in
kompliziertem System
suchen (2)
Anteile an Kohlenhydrat, Protein,
Fett, Vitamin
Nachweis von Drogen,
Schad- oder Giftstoffen,
oder Radioaktivität
https://flic.kr/p/bDGDMY
Slide 20
Slide 20 text
Probleme in
kompliziertem System
suchen (3)
Transport- und Lagerung
https://flic.kr/p/pnVsxu
Slide 21
Slide 21 text
Probleme in
kompliziertem System
suchen (4)
Einkauf, Herstellung,
Verpackung, Vertrieb
https://flic.kr/p/dZfxi5
Slide 22
Slide 22 text
Probleme in
komplizierten Systemen
• Probleme einzelner Bestandteile
• Probleme bei Abhängigkeiten
• Probleme mit übergreifenden Regeln
• Probleme mit Beteiligten
• Probleme mit Prozessen
• ....
Slide 23
Slide 23 text
Legende
System
Qualities
Context &
external
Interfaces
Existing
Issues
Data
Documentation
Runtime
Behavior
Requirements
Code
History
Code
Structure
Development
Process
Infrastructure
User
Stakeholder
hängt zusammen
Security
Die Mikroskop-Falle
Wenn Sie NUR im Code suchen,
werden Sie NUR DORT Probleme finden...
im Code suchen ist richtig und wichtig, aber NUR dort suchen ist fatal!
Slide 26
Slide 26 text
Die Relativitäts-Falle
Des Einen Problem ist
des Anderen Freund
Siehe: Planning:Expect-Denial
Slide 27
Slide 27 text
Stakeholder
... wichtige Personen oder Organisationen, die:
• Interesse am System haben,
• von System oder Architektur betroffen sind:
– damit arbeiten
– daran arbeiten
– davon profitieren
– darunter leiden
– es
• betreiben
• verwalten
• regulieren
• bezahlen
?
Slide 28
Slide 28 text
Stakeholder kennen
viele Probleme
?
Slide 29
Slide 29 text
Stakeholder-Map
Backlog
System
(Code)
System
(Laufzeit)
User
System operator
IT
Budget
System
Budget
Support
Issues
High-Level
Manager
Business
Manager
Entwickler/
Architekten
Test/QS
Product
Owner
Visualisieren Sie
IHRE
Stakeholder &
Artefakte
Slide 30
Slide 30 text
Für IHR System:
• Erstellen Sie eine (informelle) Stakeholder-
Map
• Wer arbeitet
• woran
• mit wem,
• informiert/steuert wen
• Benennen Sie für 3-5 relevante
Stakeholder:
Person
/Rolle
hat welche
Aufgabe(n)
hat welche Ziele oder
Intentionen?
kann „wie“ bei Analyse
mitwirken?
Qualitative Analyse
•Welche Qualitätsziele sind „gefährdet“?
•Soll-Ist Vergleich:
• Soll: konkrete Q-Ziele
• Ist: Lösungsansätze
• Code, Konzepte, Entscheidungen...
Genauer: Vergleich von
Anforderungen mit Lösung
oder Lösungsansätzen
Slide 33
Slide 33 text
Qualitätsanforderungen präzisieren...
Slide 34
Slide 34 text
Qualitätsziele
Q-Ziel Bedeutung / Szenarien
Flexibilität • Neues csv-
Importformat in <4h
konfigurierbar
Last /
Performance
• 250.000 eingelieferte
Fotos innerhalb von
24h prozessiert
Sicherheit • Mandant kann niemals
Zugriff auf Daten
anderer Mandanten
erhalten
Architektur-/Lösungsansatz
• Konfigurationssprache für
CSV-Parser (Import), auf
Basis ANTLR
• Syntaxgesteuerter Editor für
die Sprache
• Bilder als Dateien
speichern, Links in DB
• Lasttests im DailyBuild
• Generator für (Massen-
)Testdaten
• Mandantenspezifische
Daten grundsätzlich in
(eigener) VM
• Datenlieferungen
grundsätzlich in
mandantenspezifische
Verzeichnisse (ftp-Server)
• Unix-Kennungen spezifisch
für Mandanten
Lösungsansätze
Risiken?
Korrelierte Codeanalyse
Abgleich unterschiedlicher
Beobachtungen/Messungen
Beispiele:
• Fehler pro Komponente / Subsystem
• Benötigte Zeit pro Bugfix pro Komponente
• Benötigter Aufwand pro Feature pro Komponente
Slide 41
Slide 41 text
Korrelierte Codeanalyse (2)
Slide 42
Slide 42 text
• Analyse von Benutzerverhalten
• Analyse fachlicher Abläufe
•
Wo und womit verbringen Benutzer Zeit?
• Welche Abläufe dauern ungebührlich lange?
• Korrelieren fachliche Schwierigkeit + reale Dauer?
Laufzeitanalyse
• Profiling
Analyse von zur Laufzeit erzeugten
• Daten
• Nachrichten, Events
Im Hinblick auf: Anzahl, Größe, Art
Slide 43
Slide 43 text
1. Geben Sie Beispiele für Metriken, die als
Indikatoren fungieren können.
• Mit passablem Aufwand messbar
• Indikator für was?
2. Erstellen Sie ein „Metrik-Dashboard“:
Welche Metriken würden Sie erheben?
• Codemetriken
• Laufzeitmetriken
• Test-Metriken
• Business-Metriken
• Aufwandsmetriken
• Prozess-Metriken
• ....
Beispiel:
Saubere Schichtung, aber...
„Clean“
Code
XML
Configuration
DB
Legend:
COTS
Code
Table-1
Table-2
Table-3
Table-4
Database Relational
Data
Slide 46
Slide 46 text
Datenanalyse
1. Struktur
2. Typen
3. Zugriffe
• Read / write
4. Volumen
• auch von Query-Results + Indizes
5. Korrektheit
6. Schutzbedarf
7. Verteilung/Dezentralisierung
8. Duplikation/Redundanz
9. Durchsatz -> Laufzeitanalyse
Struktur / Typen ungeeignet für
das Problem
Wonach ist Persistenz optimiert,
read oder write?
Haben wir besonders viel?Ist
etwas besonders groß?
Haben wir falsche Daten?
Haben wir sensible Daten?
Halten wir Daten mehrfach?
Slide 47
Slide 47 text
Strukturanalyse (Architekturanalyse)
Schlechte
Modularisierung?
(Zu) hohe
Kopplung?
Ungünstige
Schnittstellen?
Schlechte
Kohäsion?
Inhomogen?
Sales
Frontend
Cash
Management
Client
Personalization
Client
Data /
Contract
User
Management
Inventory
& Order
Vouchers
Rebate and
Reduction
Cards
Sales &
Contracts
Archive
External
Partners
Sales Offices
& Outlets
Price
Management
Data
Warehouse
Marketing &
Sales
Campaigns
Campaigns
Pricing
Engine
Sales
Backend
Optical
Archive
Post-Sales
Optimization
Security
Extensions
Legend:
Java
PHP
Pyth
on
C/C+
+
Hask
ell
Cob
ol
PL/
SQL
Schlechter
Code?
Slide 48
Slide 48 text
Sammeln Sie „Issues“ bezüglich:
•Architektur + Modularisierung
• Kohäsion
• Homogenität
•Schlechtem Code
•Schlechter Technologie
•Schnittstellen
•Daten oder
•Laufzeit....
und jetzt haben Sie...
• Liste von Problemen
(issue list)
• Liste von Ideen für Verbesserungen
(improvement backlog)
Issue List
(problems, risks)
Improvement
Backlog
Slide 51
Slide 51 text
evaluate
Slide 52
Slide 52 text
These:
Wir schätzen meist nur
„Aufwände“
Slide 53
Slide 53 text
Tipp: Schätzen Sie...
Kosten der
Problem
Lösungs-
aufwände
Geschäfts-
wert
Slide 54
Slide 54 text
Schätzen in Intervallen
• schätzen Sie Intervalle,
statt einzelner (exakter) Werte
Slide 55
Slide 55 text
Schätzen: Die Grundbegriffe...
Begriff Bedeutung
Subject Schätzgegenstand – was schätzen wir?
Unit Schätzgröße, Einheit: Geld, Zeit, Aufwand,
Anzahl (wovon)
Parameter von welchen Größen/Faktoren
ist das Ergebnis abhängig?
Assumptions Annahmen, meist über einzelne
Parameter
Observation Beobachtung oder Messung einzelner
Parameter
Probability Mit welcher Wahrscheinlichkeit / Zuversicht gelten
welche dieser Zahlen
Estimate
Assumption
Unit
(Measure)
Parameter
Observation
Probability
based
upon
how certain?
can
observe
or measure
Interval
time,
money, etc
Subject
what do we
estimate?
tackle
uncertainty by
based
upon
Slide 56
Slide 56 text
Zählen, Rechnen, Expertenmeinungen
1. Zählen Sie, wann immer möglich
2. Berechnen Sie,
wenn Sie nicht zählen können
3. Expertenmeinungen nur als letztes Mittel
Slide 57
Slide 57 text
Schätzen: Die Grundbegriffe...
Estimate
Assumption
Unit
(Measure)
(Cost) Factor
(Parameter)
Observation
Probability
based
upon
how certain?
can
observe
or measure
Interval
time,
money, etc
Subject
what do we
estimate?
tackle
uncertainty by
based
upon
determines
size influence
„size“
Slide 58
Slide 58 text
Wie teuer ist es...
dass der Build-Prozess jedes Mal
>15 Minuten dauert?
• Von commit bis vollständiges
Deployment auf App-/Webserver
Slide 59
Slide 59 text
Build-Prozess (1)...
Einflussgrößen („Parameter“) klären:
• Wie viele Entwickler sind betroffen?
• Können Betroffene in der Zwischenzeit
alternative Aufgaben lösen? Doku schreiben?
• Wie häufig wird Build durchgeführt?
Slide 60
Slide 60 text
Build-Prozess (2a)...
In real-life:
• >30 Entwickler
• Zur Zeit 3-5 x täglich
30Pers * 4 * 15min
=> 30h Overhead täglich
Slide 61
Slide 61 text
Build-Prozess (2b)...
Weitere Konsequenz:
• Entwickler bauen seltener,
• dadurch werden Fehler
später gefunden,
• Bugfix-Aufwände steigen
• Von 3h/Bug auf 3.5h/Bug
• Bei 15 Bugs/Tag
15Bugs * 30min
=> 7,5h Overhead täglich
Beispiel (3)
• Kontext: übertrieben heterogenes System
• C, C++, Cobol, Java, Php, Scala, Python, Haskell
• Windows, Linux, Mainframe
• Ziele:
• Beschleunigung „time-to-market“
• Verbesserung der Verfügbarkeit
Slide 65
Slide 65 text
Beispiel (3): Annahmen
• Heterogenität betrifft alle Phasen der Entwicklung
(Anforderungen bis Betrieb)
• Mittlerer Aufwand pro Phase ist bekannt
http://courses.cs.vt.edu/~csonline/SE/Lessons/LifeCycle/
Slide 66
Slide 66 text
Beispiel (3): Ergebnis
Slide 67
Slide 67 text
Meine Versprechen („Agenda“)
1. Methodisches Verbessern
2. Schlimme Probleme finden
3. Management überzeugen
4. Mittel- und langfristige Verbesserungen
5. Mit Tagesgeschäft vereinbaren
Issue
(Problem, Risk)
Improvement
Cost cost of
improvement
cost of
issue
solve issue with
improvement(s)
Slide 68
Slide 68 text
Für (1-2) Ihrer Issues:
•Finden Sie (Kosten-)Faktoren
• Was beeinflusst deren „Schlimmheit“
(Kosten)
•Treffen Sie Annahmen...
•Schätzen Sie die Kosten dieser Issues
Introduce
Interfaces
Untangle Code
Remove Nested
Control Structures
Deprecate
Obsolete Parts
Improve
Responsibility
Improve
Code Layout
Move Behavior
Close To Data
Split Up
Oversized Parts
Handle
If-Else Chains
Interface
Segregation
Anticorruption
Layer
Hide
Unmaintainable
Code
Extract Reusable
Component
Integrate Reusable
Component
Remove
Unused Parts
Eliminate
Navigation Code
Toggle Feature
Isolate Parts
(Modularize)
Break
Dependencies
Event Interception
Asset
Capture
Gateway
Handle Too
Many
«category»
Restructure
Code
«category»
Improve
Processes
«category»
Improve
Technical
Infrastructure
«category»
Improve
Analysability
& Evaluability
Improve
Engineering
Improve
Delivery
Improve
Operations
Improve
Flow
Improve
Governance
Schedule Work
Enable Team
Improve
Hardware
Improve
Supporting
Software
Automate
Release
Improve Test
Infrastructure
Improve Logging
Improve Test
Automation
Measure
«category»
Improve
Architecture &
Code Structure
Improve
Modularity
Improve
Concepts &
Consistency
Extract Domain
Model
«category»
Restructure
Code
Introduce better
Technology
Improve Use of
Technology
«category»
Prepare
Change
Improve
Hierarchy
Slide 71
Slide 71 text
«category»
Long-Term
Improvement
Approach
Strangulate
Bad Parts
Big Bang
(Cold Turkey)
Frontend
Switch
Keep Data,
Toss Code
Managed
Evolution
Change
Via Split
Data
Migration
Branch by
Abstraction
Chicken Little
Butterfly
Bridge To
New Town
Change By
Extraction
Change
On Copy
Value-based
Improvement
Slide 72
Slide 72 text
Big-Bang
Vorgehen
1. Spezifiziere neues
System
2. Entwerfe und
implementiere neues
System
3. Nach Fertigstellung &
Abnahme werden
Benutzer und Clients auf
neues System umgestellt
Risiken
• Spezifikation aufgrund der
Komplexität des alten Systems lücken-
oder fehlerhaft
• Know-How-Flucht: Demotivierte
Mitarbeiter des alten Systems
• Das neue System vermeidet zwar
bekannte Fehler, enthält jedoch neue!
• Business erhält lange Zeit (Jahre!)
keine signifikanten neuen Features
• Schwierige, aufwändige
Datenmigration
• Bereits die Anforderungsanalyse oft
sehr schwierig
Slide 73
Slide 73 text
Big Bang (aka Cold Turkey)
Client
Code
Flawed
System
User 1
New
System
Client
Code
User
Entwickle ein neues
System parallel zu
Betrieb und Pflege
des alten.
Slide 74
Slide 74 text
Branch by Abstraction
Vorgehen
1. Kapsele die Interaktion mit den
schlechten Teilen über eine
Abstraktion (Interface)
2. Lasse sämtlichen Client-Code nur
noch dieses Interface verwenden
3. Erstelle einen besseren Supplier
(Provider, Server) für dieses Interface
4. Entferne den alten Supplier
Risiken
• Entsteht auf Basis des
schlechten Suppliers...
Ggfs. ist die Abstraktion
schlecht!
Voraussetzungen
• Klare Schnittstelle für
bestehende Dienste
definierbar
Slide 75
Slide 75 text
Branch-By-Abstraction (1)
Client
Code
Flawed
Supplier
Client
Code
Client
Code
Flawed
Supplier
Client
Code
Abstraction
Layer
Client
Code
Flawed
Supplier
Client
Code
Abstraction
Layer
Kapsele die Interaktion mit
den schlechten Teilen
Lasse sämtlichen
Client-Code diese
Kapselung nutzen
Erstelle einen
besseren Supplier
Client
Code
Flawed
Supplier
Client
Code
Abstraction
Layer
Abstraction
Layer
New
Supplier
1
2
3
Slide 76
Slide 76 text
Branch-By-Abstraction (2)
Vervollständige den Supplier,
ggfs. entferne
den alten.
Client
Code
Flawed
Supplier
Client
Code
Abstraction
Layer
Abstraction
Layer
New
Supplier
Client
Code
Flawed
Supplier
Client
Code
Abstraction
Layer
New
Supplier
4
Slide 77
Slide 77 text
Change By Split
Vorgehen
1. Identifiziere mehrere
Benutzergruppen (BG)
2. Klone gesamtes System für jede
BG
3. Reduziere für jede BG, extrahiere
Gemeinsamkeiten
(technische Basis)
4. Optimiere für jede BG
Risiken
• Gemeinsamkeiten schwer
zu isolieren
• Mehrere Teams benötigt
(1 pro Klon + Basis)
Voraussetzungen
• stark unterschiedliche
Benutzergruppen
Slide 78
Slide 78 text
Change By Split
Client
Type 1
Flawed
System
Client
Type 2
Kopiere für alle
Client-Typen
1
Client
Type 1
Flawed
System
Client
Type 2
Flawed
System
Client
Type 1
Reduced to
Type 1
Client
Type 2
Reduced to
Type 2
Commons
Reduziere und extrahiere
Gemeinsamkeiten
2
Client
Type 1
Reduced to
Type 1
Client
Type 2
Reduced to
Type 2
New
Commons
Optimiere
Gemeinsamkeiten
3
Slide 79
Slide 79 text
Change By Split (2)
Client
Type 1
Reduced to
Type 1
Client
Type 2
Reduced to
Type 2
New
Commons
Optimiere spezifische
Teilsysteme („Splits“)
4
New Type 1
System
Client
Type 1
Client
Type 2
New
Commons
New Type 2
System
Slide 80
Slide 80 text
Meine Versprechen („Agenda“)
1. Methodisches Verbessern
2. Schlimme Probleme finden
3. Management überzeugen
4. Mittel- und langfristige Verbesserungen
5. Mit Tagesgeschäft vereinbaren
«category»
Improve
Processes
«category»
Improve
Technical
Infrastructure
«category»
Improve
Analysability
& Evaluability
«category»
Improve
Architecture &
Code Structure
Slide 81
Slide 81 text
aim42.github.io
aim42.org
Slide 82
Slide 82 text
Dr. Gernot Starke
[email protected]
http://innoq.com
https://www.flickr.com/photos/foto_db/16000636092
Slide 83
Slide 83 text
Agenda
https://www.flickr.com/photos/valbanese/8663968105/
by https://www.flickr.com/photos/valbanese/
Schulden eintreiben
https://www.flickr.com/photos/reindertot/3352164734/ by https://www.flickr.com/photos/reindertot/
Basel
https://www.flickr.com/photos/tambako/3007256159/
by https://www.flickr.com/photos/tambako/
Problems
https://www.flickr.com/photos/portland_mike/6852704246/
by https://www.flickr.com/photos/portland_mike/
Broken Fence
https://www.flickr.com/photos/socsci/21844740756/ by https://www.flickr.com/photos/socsci/
Circle
https://www.flickr.com/photos/infomastern/14519782386/ by
https://www.flickr.com/photos/infomastern/
Spectrum of Topics (Spices)
https://www.flickr.com/photos/crobj/5519129659
by https://www.flickr.com/photos/crobj/
Measuring
https://www.flickr.com/photos/david_mackay/5541294472/
by https://www.flickr.com/photos/david_mackay/
https://www.flickr.com/photos/mad_house_photography/4311409835/
by https://www.flickr.com/photos/david_mackay/
Evaluate / Estimation
https://www.flickr.com/photos/evelynsaenz/4987334392/
by https://www.flickr.com/photos/evelynsaenz/
https://www.flickr.com/photos/jakerust/16811604186/
by https://www.flickr.com/photos/jakerust/
Long Term Improvement
https://www.flickr.com/photos/legion293/4921980590/
by https://www.flickr.com/photos/legion293/
Image Credits