Slide 1

Slide 1 text

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

Slide 13

Slide 13 text

Iterativ verbessern! analyze evaluate improve collect

Slide 14

Slide 14 text

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

Slide 24

Slide 24 text

Iteration 1 Breitensuche in Iterationen Stakeholder Code Kontext Qualität Daten Prozesse Iteration 2

Slide 25

Slide 25 text

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?

Slide 31

Slide 31 text

Übersicht: Systemanalyse • Qualitative Analyse (Risiken) • Quantitative Analyse („Vermessung“) • Code • Laufzeit • Datenanalyse • Kontextanalyse

Slide 32

Slide 32 text

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?

Slide 35

Slide 35 text

Sammeln Sie „Issues“ bezüglich relevanter Qualitätsmerkmale. • Time-to-Market • Performance • Sicherheit • Robustheit/ Stabilität • Flexibilität (zur Laufzeit) • Änderbarkeit • Komplexität • Betreibbarkeit • ...

Slide 36

Slide 36 text

Quantitative Bewertung („Vermessung“) • Codemetriken • Laufzeitmetriken • Zeit- und Ressourcenverbrauch • Organisatorische Metriken • Fehler / Baustein • Änderungsaufwand / Baustein • Dauer von x / Baustein (x=Test, Dev...)

Slide 37

Slide 37 text

Statische Codeanalyse • Größe • Kopplung • Komplexität • Duplizierter Code • Verletzung von Idiomen (Style-Checking) • Kohäsion (inhaltlicher Zusammenhang) • Konsistenz (identische Probleme ähnlich gelöst)

Slide 38

Slide 38 text

Beispiel (1) Anmerkung: je höher desto schlechter Fix me? Komplexität: 2 Kopplung: 10 Komplexität: 10 Kopplung: 30 Komplexität: 9 Kopplung: 35 Komplexität: 7 Kopplung: 20

Slide 39

Slide 39 text

Beispiel (2) Komplexität: 2 Kopplung: 10 DTFB: 0.5 Bugs: 200 Komplexität: 10 Kopplung: 30 DTFB: 2 Bugs: 20 Komplexität: 9 Kopplung: 35 DTFB: 3 Bugs: 2 Komplexität: 7 Kopplung: 20 DTFB: 8 Bugs: 15 Fix me DTFB: Days-to-Fix-Bug

Slide 40

Slide 40 text

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 • ....

Slide 44

Slide 44 text

Beispiel: Saubere Schichtung... GUI Application Domain Infrastructure

Slide 45

Slide 45 text

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....

Slide 49

Slide 49 text

git log --since="90 days ago" --pretty=format:"" --name-only | \ grep "[^\s]" | \ sort | uniq -c | \ sort -nr | head -10 Code („gist“): https://goo.gl/kzTgFa

Slide 50

Slide 50 text

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

Slide 62

Slide 62 text

Build-Prozess (2c)... „Problemkosten“: Gesamt 37.5h / Tag Annahme: Personalkosten 50-100€/h Summe: [3750€/T , 1875€/T] 15Bugs * 30min => 7,5h Overhead täglich 30Pers * 4 * 15min => 30h Overhead täglich

Slide 63

Slide 63 text

Build-Prozess (3)... Lösungsoptionen: • Seltener bauen (-> Fehlerkosten steigen) • Schnellere Hardware • Hot-Deployment/zero turnaround (JRebel) • Lizenzkosten 475$/dev -> ~14000€ • Deploymentmodell ändern • .... https://zeroturnaround.com/software/jrebel/features/

Slide 64

Slide 64 text

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

Slide 69

Slide 69 text

«category» Improve Processes «category» Improve Technical Infrastructure «category» Improve Analysability & Evaluability «category» Improve Architecture & Code Structure

Slide 70

Slide 70 text

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