Slide 1

Slide 1 text

Schluss  mit   Verschlimmbesserung   So#ware-­‐Evolu-on,  aber  rich-g   Dr.  Gernot  Starke   DevDay-­‐DD  

Slide 2

Slide 2 text

Dr.  Gernot  Starke   innoQ  Fellow     Softwarearchitekturen Entwurf, Entwicklung, Management Evolution & Modernisierung Training   Mentoring und Coaching Analyse und Optimierung von Entwicklungsprozessen   Reviews, Audits, Retrospektiven +49 177 – 728 2570 [email protected] www.arc42.de

Slide 3

Slide 3 text

Der  Normalfall...  

Slide 4

Slide 4 text

Normalfall  (2)   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  Innova-on.   Zu  wenig  Budget.   Zu  wenig  Zeit.    

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

View-­‐Pipeline  (Apache  Cocoon)   Theorie:   •  Separa-on  of  Concern   Praxis:   •  XSLT-­‐Hölle   •  Transformer     ändern  Daten   •  Enge  Kopplung   der  Filter  (Steps)     Step-1 Step-2 Step-3 Data Source-1 read Appl- Core-Old read / write Step-4 Appl- Services read hYp://cocoon.apache.org/2.1/userdocs/concepts/index.html  

Slide 7

Slide 7 text

im  normalen  Leben...   analyze evaluate improve

Slide 8

Slide 8 text

Systema-sch  verbessern...   Trenne  „Probleme“  und  „Lösungsvorschläge“   UID Description Cost Frequency Issue UID Description Cost Improvement 1..* * resolve ➤ resolved by ➤ Name System suffers from is remedy for UID Description Cost Frequency Issue Probability EarlyWarning Risk Cause UID Description Cost Improvement 1..* * resolve ➤ resolved by ➤ modify or create ➤ is real source of ➤ * * * * Name System Name Role Interests Experience Stakeholder Software Hardware Process Name Organization Documentation knows / informs about ➤ knows / informs about ➤ source of ➤ source of ➤ suffers from ➤ is remedy for Configuration consists-of Goals Constraints impose ➤ has explicit and implicit ➤ complies with ➤ restrict ➤ ➤ aim42  domain  model  

Slide 9

Slide 9 text

warum  diese  Trennung?   •  rich-g:     – wich6ge  Probleme  lösen   •  schlechter:   – einfache  Probleme  lösen   •  ganz  schlecht:   – interessante  Problemlösungen  umsetzen   – Ak-onismus   €  

Slide 10

Slide 10 text

Die  Rela-vitäts-­‐Falle   Des  Einen  Problem  ist   des  Anderen  Freund  

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

profi-eren  vom  Problem,     haben  das  Problem  erschaffen,   greifen  Sie  und  Ihre  Vorschläge  an   sind  am  Problem  schuld,   stehen  zu  Ihnen  in  Konkurrenz,   greifen  Ihre  Kompetenz  an   leiden  nicht  am  Problem,   leiden  unter  dessen  Lösung   tragen  (Teil-­‐)Schuld  am  Problem   zweifeln  Schlussfolgerungen  an,   zweifeln  Ihre  Kompetenz  an,   haben  Angst  vor  Veränderung  

Slide 13

Slide 13 text

Die  Mikroskop-­‐Falle   Wenn  Sie  NUR  im  Code  suchen,     werden  Sie  NUR  DORT  Probleme  finden...   im  Code  suchen  ist  rich-g  und  wich-g,  aber  NUR  dort  suchen  ist  fatal!  

Slide 14

Slide 14 text

hYps://www.flickr.com/photos/jonasb/24341322  

Slide 15

Slide 15 text

hYps://www.flickr.com/photos/emiliano-­‐iko/5354414276  

Slide 16

Slide 16 text

Bauch  –  Beine  –  Po:     Wo  liegen  die  IT-­‐Problemzonen?   Legende Qualitative Analyse (ATAM) Context Analysis Issue Tracker Analysis Data Analysis Documentation Analysis Runtime Analysis Requirements Analysis Software Archeology Static Code Analysis Development Process Analysis Infrastructure Analysis User Analysis Stakeholder Analysis wichtig abhängig von

Slide 17

Slide 17 text

Probleme  sammeln!!   ID   Beschreibung   Häufigkeit   Wert     (min)   Wert   (max)   Abhilfen   PD-­‐ 1   Falsche  Berechnung  Ar-kelpreis  bei  Kombina-on  aus   RabaYkarte,  Einzelkunde  und  yxz-­‐Konfigura-on   zZt  3-­‐5x   pro  Woche   110€   550€   V-­‐1  +  V-­‐2   PZ-­‐ 1   Zu  lange  Warteschlangen  (queues)  in  Entwicklungs-­‐ prozess:  wai-ng-­‐-me  für  neue  Anforderungen  >6W   30x  /   Woche   300€   15.000   €   V-­‐3   C-­‐1   Zeit  zur  Iden-fika-on  +  Behebung  von  Laufzeitehlern   zu  lang  (bis  zu  5  T  bei  kri-schen  Fehlern)   1x  /  Woche   V-­‐4  ||  V-­‐3   C-­‐2   Zeit  für  kompleYen  Test  der  Anwendung  >  10  T   4  x  /  Jahr   V-­‐4   Werkzeuge:     •  (gut)  Issue-­‐Tracker  (Voraussetzung:  stabile  URL‘s)   •  (ok)  Excel,  Karteikarten,  Flipchart   •  (schlecht)  Kopf  

Slide 18

Slide 18 text

Stakeholderanalyse   •  Stakeholder  kennen  Probleme   – nehmen  Probleme  aus  ihrer  Perspek-ve  wahr   (subjek-v)   – nennen  o#mals  Symptome,  keine  Ursachen   – äußern  Vermutungen   •  Vorsicht:     – Gewöhnungseffekt   – Angst  vor  Änderung     Anwender,  Entwickler,  Support,   Fachleute,  BackOffice,  Architekten,   Betreiber,  Au#raggeber,  Tester,  Admins,   Projekt-­‐/Linienverantwortliche,   Controller,  CEO,  COO,  CFO  ...  

Slide 19

Slide 19 text

Stakeholder-­‐Interviews  (1)   •  Breitensuche:  Unterschiedliche  Stakeholder   – Mindestens:  Anwender,  Fachexperten,  Entwickler,   Support-­‐Mitarbeiter,  Tester,  Betreiber,  Manager   •  Ungestörtes  Umfeld   – insbesondere:  ohne  Vorgesetzte   – garan-erte  Vertraulichkeit   •  Keine  unhaltbaren  Versprechungen  geben!!  

Slide 20

Slide 20 text

Stakeholder-­‐Interviews  (2)   •  Vorbereitung:  individueller  Vorab-­‐Fragebogen   – Zeigt  Hochachtung  vor  Gesprächspartner   – Siehe:  hYp://aim42.github.io/#Stakeholder-­‐Interview   •  Fragen  nach:   – Problemen  +  Lösungsmöglichkeiten  bezüglich   •  System,     •  Prozesse,     •  Organisa-on  

Slide 21

Slide 21 text

Kontextanalyse  (1)   •  Fachlicher  Kontext   – System-­‐Scope   – Externe  SchniYstellen   •  Daten-­‐Eingang   •  Daten-­‐Ausgang   •  UI   •  Events   •  Technischer  Kontext   – Kanäle   – Protokolle  

Slide 22

Slide 22 text

Kontextanalyse  (2)   Mögliche  Risiken  im  Kontext:   •  Abhängigkeiten  bzgl.  Qualitätszielen   –  Verfügbarkeit,  Robustheit,     –  Sicherheit   –  Kosten   –  Performance   •  Fehlende     SchniYstellen   Risiko  bzgl.   Performance-­‐   Anforderung  

Slide 23

Slide 23 text

Kontextanalyse  (3)   Mögliche  Risiken  im  Kontext:   •  Vola-le  Nachbarsysteme   Risiko  /  Problem  bzgl.   Stabilität  der   SchniYstelle   Unser   System   Anderes   (innova-ves)   Projekt  /  System   getImportantData(  customerID)  

Slide 24

Slide 24 text

„Improve  Analyzability“   Verbessern  Sie  die  Möglichkeiten,     Probleme  zu  finden!     •  zur  „Root-­‐Cause-­‐Analyse“   •  zum  Beweis  von  Vermutungen   •  Instrumen-erung,  z.B.   – (fachliches/technisches)  Logging   – Tracking  von  Qualitätseigenscha#en  

Slide 25

Slide 25 text

Prozessanalyse   •  Anforderungsprozesse   –   erheben,  klären,  managen   •  Entwicklungs-­‐  /Entwurfsprozesse   – Architektur,  Implemen-erung,  Dokumenta-on   •  Betrieb   – Deployment,  Rollout,  Administra-on,  Monitoring   •  Management   – Team-­‐  und  Taskmanagement,  Risikomanagement  

Slide 26

Slide 26 text

warum,  warum,  warum...   offshore-­‐   Dienstleister   Abnahme  erteilt,   Basis  „Funk-onsprüfung“   Abnahmeprozess   auf  Durchsatz  op-miert   he#iges  Risiko   bzgl.  Verfügbarkeit  

Slide 27

Slide 27 text

Sta-sche  Codeanalyse   •  Kopplung   •  Komplexität   •  Kohäsion  (inhaltlicher  Zusammenhang)   •  Konsistenz  (iden-sche  Probleme  ähnlich  gelöst)   •  Duplizierter  Code   •  Verletzung  von  Idiomen  (Style-­‐Checking)  

Slide 28

Slide 28 text

Korrelierte  Codeanalyse   Abgleich  unterschiedlicher     Beobachtungen/Messungen     Beispiele:   •  Fehler  pro  Komponente  /  Subsystem   •  Benö-gte  Zeit  pro  Bugfix  pro  Komponente   •  Benö-gter  Aufwand  pro  Feature  pro   Komponente  

Slide 29

Slide 29 text

Korrelierte  Codeanalyse  (2)  

Slide 30

Slide 30 text

Datenanalyse  (1)   •  Struktur   •  Typen   •  Zugriffe   –  Read  /  write   •  Volumen   –  auch  von  Query-­‐Results  +  Indizes   •  Inhalte   –  Korrektheit   –  Schutzbedarf   •  Durchsatz  -­‐>  Laufzeitanalyse   Struktur  /  Typen  ungeeignet   für  das  Problem     Wonach  ist  Persistenz   op-miert,  read  oder  write?   Haben  wir  besonders  viel  /   groß  von  etwas?   Haben  wir  falsche  Daten?  

Slide 31

Slide 31 text

Laufzeitanalyse   •  Debugger   •  Logfile-­‐Analyse     •  Performance-­‐Analyse,  Profiling   •  Ressourcenverbrauch  zur  Laufzeit   •  Analyse  von  Benutzerverhalten   •  Analyse  fachlicher  Abläufe  

Slide 32

Slide 32 text

Fazit:  Analyse  in  Vogelperspek-ve   Issues & Improvements system analyisis existing organization & processes existing system findings & suggestions stakeholder interviews stakeholder analysis development process development process analysis collected issues, suggested improvements collected issues, suggested improvements collected issues, suggested improvements collected issues, suggested improvements Stakeholders findings & suggestions 8 8

Slide 33

Slide 33 text

Verbesserung  im  Großen...     Grundprinzipien,     Verhaltensregeln       kleine,  lokale   Verbesserungen       langfris6ge,  strategische   Ansätze     3   2   1   Fundamentals Approaches Practices

Slide 34

Slide 34 text

Langfris-ge     Ansätze...   Determine 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

Slide 35

Slide 35 text

Daten  erhalten  oder  nicht?   Wesentliche  Entscheidung:     Welche  Daten  müssen  erhalten  bleiben?   Big Understructured Mess Very Valuable Data Big Understructured Mess Very Va Da alu ble at Valu ata alu ble at uable ta Big Understructured Mess Very Valuable Data

Slide 36

Slide 36 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 37

Slide 37 text

Big-­‐Bang   Vorgehen   1.  Spezifiziere  neues   System   2.  Entwerfe  und   implemen-ere  neues   System   3.  Nach  Fer-gstellung  &   Abnahme  werden   Benutzer  und  Clients   auf  neues  System   umgestellt   Risiken   •  Spezifika-on  aufgrund  der   Komplexität  des  alten  Systems   lücken-­‐  oder  fehlerha#   •  Know-­‐How-­‐Flucht:  Demo-vierte   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   Datenmigra-on  

Slide 38

Slide 38 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 Op-miere   Gemeinsamkeiten   3

Slide 39

Slide 39 text

Change  By  Split  (2)   Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Commons Op-miere  spezifische   Teilsysteme  („Splits“)   4 New Type 1 System Client Type 1 Client Type 2 New Commons New Type 2 System

Slide 40

Slide 40 text

Change  By  Split   Vorgehen   1.  Iden-fiziere  mehrere   Benutzergruppen  BG   2.  Klone  gesamtes  System  für   jede  BG   3.  Reduziere  für  jede  BG,   extrahiere  Gemeinsamkeiten   (technische  Basis)   4.  Op-miere  für  jede  BG   Risiken   •  Gemeinsamkeiten   schwer  zu  isolieren   •  Mehrere  Teams   benö-gt  (1  pro  Klon  +   Basis)   Voraussetzungen   •  stark  unterschiedliche   Benutzergruppen  

Slide 41

Slide 41 text

Strangulate  Bad  Parts  (1)   Ersetze  einige     schlechte  Teile   Ersetze  weitere   schlechte  Teile   Und  noch     mehr...   1 2 3 Client Code Flawed System User Client Code Flawed System User better Client Code Flawed System User better Better System Client Code User Flawed Parts

Slide 42

Slide 42 text

Strangulate  Bad  Parts   Vorgehen   1.  Ersetze  im  bestehenden   System  sukzessive  einzelne   Komponenten   Risiken   •  Nebenwirkungen   innerhalb  des  Systems   schwer  zu  testen   •  Hohe  Aufwände,  um   übergangsweise  mit   „Altlasten“  zu  arbeiten   Voraussetzungen   •  interne  SchniYstellen  /   Modularisierung  

Slide 43

Slide 43 text

Improve Processes Improve Iteratively Reduce Complexity Improve Code Structure Improve Crosscutting Concepts Improve Technical Infrastructure Improve Analysability & Evaluability Verify After Every Change Fast Feedback Explicit Assumptions Group Improvement Actions Prototype Improvement Übersicht:  Prak-ken   Fundamentals Approaches Practices Breites   Spektrum  an   Op-onen  

Slide 44

Slide 44 text

Improve Processes Improve Code Structure Improve Crosscutting Concepts Improve Technical Infrastructure Improve Analysability & Evaluability Improve Code Structure Introduce Interfaces Refactor Code 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 Restructure Code Isolate Parts (Modularize) Prepare Change Break Dependencies

Slide 45

Slide 45 text

Fazit  (1)   42 Führe     •  Problem-­‐Liste  und     •  Improvement-­‐Backlog  

Slide 46

Slide 46 text

Fazit  (2)   42 Vorsicht:  Mikroskop-­‐Falle  

Slide 47

Slide 47 text

Fazit  (3)   42 Vorsicht:  neue  Feinde...                              

Slide 48

Slide 48 text

Dr.  Gernot  Starke     [email protected]     hYp://gernotstarke.de   hYp://innoq.com     hYps://www.flickr.com/photos/foto_db/16000636092  

Slide 49

Slide 49 text

Projekt   42

Slide 50

Slide 50 text

Prak-sch  eingesetzt...   ‣  2014:   – Logis-k-­‐Konzern   (Audit  Online-­‐Sales   System,  >1MLOC)   – ERP-­‐Hersteller   (Audit  und  Rebuild   Kernsystem,  2  MLOC)   – Finanzdienstleister,   Modernisierung  Core,   500kLOC   •  Automo-ve:     „Mul-media-­‐Framework“   •  Rail-­‐Service  „Infrastruktur“   •  Mobilfunk     „Billing“   •  Airport-­‐Opera-ons  „Luggage   Handling“   •  Systemso#ware  für   Maschinenbau  /   LebensmiYelindustrie  

Slide 51

Slide 51 text

Website   Whitepaper  

Slide 52

Slide 52 text

Code:  github  

Slide 53

Slide 53 text

Issues:  viele...  

Slide 54

Slide 54 text

Contributors...   Beiträge     willkommen!

Slide 55

Slide 55 text

Contribu-ons  welcome   •  Method guide: http://aim42.github.io   – Source:  hYps://github.com/aim42/aim42   •  https://github.com/aim42/aim42/ issues •  TwiYer:    @arc_improve42   •  Mailing  list:    [email protected]