"Know your enemies": Probleme in Software finden

Probleme in Software müssen wir auch ausserhalb des Quellcodes suchen - und dabei auf diverse Fallstricke achtgeben.

Transcript

1. Know  Your  Enemies   Probleme  in  So,ware  finden  –     aber  rich4g   Dr.  Gernot  Starke  
2. 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 gs@gernotstarke.de www.arc42.de
3. im  normalen  Leben...   analyze evaluate improve
4. dieser  Vortrag...   analyze evaluate improve
5. Gute  Problemanalyse  hil,  bei...   •  Priorisierung  von  Änderungen   •  Balancieren  kurz-­‐  /  langfris4ger  Maßnahmen  
6. Systema4sch  verbessern  (1)...   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  
7. warum  diese  Trennung?   •  rich4g:     – wich0ge  Probleme  lösen   •  schlechter:   – einfache  Probleme  lösen   •  ganz  schlecht:   – interessante  Problemlösungen  umsetzen   – Ak4onismus   €  
8. Die  Rela4vitäts-­‐Falle   Des  Einen  Problem  ist   des  Anderen  Freund  
10. profi4eren  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  
11. Die  Mikroskop-­‐Falle   Wenn  Sie  NUR  im  Code  suchen,     werden  Sie  NUR  DORT  Probleme  finden...   im  Code  suchen  ist  rich4g  und  wich4g,  aber  NUR  dort  suchen  ist  fatal!  
12. hfps://www.flickr.com/photos/jonasb/24341322  
13. hfps://www.flickr.com/photos/emiliano-­‐iko/5354414276  
14. 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
15. Iden4fiziere  Probleme   •  Konkret  /  spezifisch   •  Wiederholbar   •  Was  ist  das  Problem?   •  {Wobei  |  Wo  |  Wann}  trif  es  auf?   •  Reproduzierbar?   •  Auswirkungen?  (Verursachter  Schaden?)   analyze evaluate improve
16. Probleme  sammeln!!   ID   Beschreibung   Häufigkeit   Wert     (min)   Wert   (max)   Abhilfen   PD-­‐ 1   Falsche  Berechnung  Ar4kelpreis  bei  Kombina4on  aus   Rabafkarte,  Einzelkunde  und  yxz-­‐Konfigura4on   zZt  3-­‐5x   pro  Woche   110€   550€   V-­‐1  +  V-­‐2   PZ-­‐ 1   Zu  lange  Warteschlangen  (queues)  in  Entwicklungs-­‐ prozess:  wai4ng-­‐4me  für  neue  Anforderungen  >6W   30x  /   Woche   300€   15.000   €   V-­‐3   C-­‐1   Zeit  zur  Iden4fika4on  +  Behebung  von  Laufzeiwehlern   zu  lang  (bis  zu  5  T  bei  kri4schen  Fehlern)   1x  /  Woche   V-­‐4  ||  V-­‐3   C-­‐2   Zeit  für  komplefen  Test  der  Anwendung  >  10  T   4  x  /  Jahr   V-­‐4   Werkzeuge:     •  (gut)  Issue-­‐Tracker  (Voraussetzung:  stabile  URL‘s)   •  (ok)  Excel,  Karteikarten,  Flipchart   •  (schlecht)  Kopf  
17. Stakeholderanalyse   •  Stakeholder  kennen  Probleme   – nehmen  Probleme  aus  ihrer  Perspek4ve  wahr   (subjek4v)   – 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  ...  
18. Stakeholder-­‐Interviews  (1)   •  Breitensuche:  Unterschiedliche  Stakeholder   – Mindestens:  Anwender,  Fachexperten,  Entwickler,   Support-­‐Mitarbeiter,  Tester,  Betreiber,  Manager   •  Ungestörtes  Umfeld   – insbesondere:  ohne  Vorgesetzte   – garan4erte  Vertraulichkeit   •  Keine  unhaltbaren  Versprechungen  geben!!  
19. Stakeholder-­‐Interviews  (2)   •  Vorbereitung:  individueller  Vorab-­‐Fragebogen   – Zeigt  Hochachtung  vor  Gesprächspartner   – Siehe:  hfp://aim42.github.io/#Stakeholder-­‐Interview   •  Fragen  nach:   – Problemen  +  Lösungsmöglichkeiten  bezüglich   •  System,     •  Prozesse,     •  Organisa4on  
20. Kontextanalyse  (1)   •  Fachlicher  Kontext   – System-­‐Scope   – Externe  Schnifstellen   •  Daten-­‐Eingang   •  Daten-­‐Ausgang   •  UI   •  Events   •  Technischer  Kontext   – Kanäle   – Protokolle  
21. Kontextanalyse  (2)   Mögliche  Risiken  im  Kontext:   •  Abhängigkeiten  bzgl.  Qualitätszielen   –  Verfügbarkeit,  Robustheit,     –  Sicherheit   –  Kosten   –  Performance   •  Fehlende     Schnifstellen   Risiko  bzgl.   Performance-­‐   Anforderung  
22. Kontextanalyse  (3)   Mögliche  Risiken  im  Kontext:   •  Vola4le  Nachbarsysteme   Risiko  /  Problem  bzgl.   Stabilität  der   Schnifstelle   Unser   System   Anderes   (innova4ves)   Projekt  /  System   getImportantData(  customerID)  
23. „Improve  Analyzability“   Verbessern  Sie  die  Möglichkeiten,     Probleme  zu  finden!     •  zur  „Root-­‐Cause-­‐Analyse“   •  zum  Beweis  von  Vermutungen   •  Instrumen4erung,  z.B.   – (fachliches/technisches)  Logging   – Tracking  von  Qualitätseigenscha,en  
24. Prozessanalyse   •  Anforderungsprozesse   –   erheben,  klären,  managen   •  Entwicklungs-­‐  /Entwurfsprozesse   – Architektur,  Implemen4erung,  Dokumenta4on   •  Betrieb   – Deployment,  Rollout,  Administra4on,  Monitoring   •  Management   – Team-­‐  und  Taskmanagement,  Risikomanagement  
25. warum,  warum,  warum...   offshore-­‐   Dienstleister   Abnahme  erteilt,   Basis  „Funk4onsprüfung“   Abnahmeprozess   auf  Durchsatz  op4miert   he,iges  Risiko   bzgl.  Verfügbarkeit  
26. Sta4sche  Codeanalyse   •  Kopplung   •  Komplexität   •  Kohäsion  (inhaltlicher  Zusammenhang)   •  Konsistenz  (iden4sche  Probleme  ähnlich  gelöst)   •  Duplizierter  Code   •  Verletzung  von  Idiomen  (Style-­‐Checking)  
27. Korrelierte  Codeanalyse   Abgleich  unterschiedlicher     Beobachtungen/Messungen     Beispiele:   •  Fehler  pro  Komponente  /  Subsystem   •  Benö4gte  Zeit  pro  Bugfix  pro  Komponente   •  Benö4gter  Aufwand  pro  Feature  pro   Komponente  
28. Korrelierte  Codeanalyse  (2)  
29. 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   op4miert,  read  oder  write?   Haben  wir  besonders  viel  /   groß  von  etwas?   Haben  wir  falsche  Daten?  
30. Laufzeitanalyse   •  Debugger   •  Logfile-­‐Analyse     •  Performance-­‐Analyse,  Profiling   •  Ressourcenverbrauch  zur  Laufzeit   •  Analyse  von  Benutzerverhalten   •  Analyse  fachlicher  Abläufe  
31. So,ware-­‐Archäologie   Historie  von  Code  untersuchen   – benö4gt  Versionsverwaltung   •  Gründe  für  Entscheidungen  suchen   – etwa:  für  „seltsamen  Code“   •  Zeitpunkte  von  Verschlechterungen  erkennen  
32. Fazit:  Analyse  in  Vogelperspek4ve   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
33. Fazit  (2)  
    42 Führe     •  Problem-­‐Liste  und     •  Improvement-­‐Backlog  
34. Fazit  (3)  
    42 Vorsicht:  Mikroskop-­‐Falle  
35. Fazit  (4)  
    42 Vorsicht:  neue  Feinde...                              
36. Dr.  Gernot  Starke     gs@gernotstarke.de     hfp://gernotstarke.de   hfp://innoq.com     hfps://www.flickr.com/photos/foto_db/16000636092  
37. Projekt  
    42
38. Prak4sch  eingesetzt...   ‣  2014:   – Logis4k-­‐Konzern   (Audit  Online-­‐Sales   System,  >1MLOC)   – ERP-­‐Hersteller   (Audit  und  Rebuild   Kernsystem,  2  MLOC)   – Finanzdienstleister,   Modernisierung  Core,   500kLOC   •  Automo4ve:     „Mul4media-­‐Framework“   •  Rail-­‐Service  „Infrastruktur“   •  Mobilfunk     „Billing“   •  Airport-­‐Opera4ons  „Luggage   Handling“   •  Systemso,ware  für   Maschinenbau  /   Lebensmifelindustrie  
39. Website   Whitepaper  
40. Code:  github  
41. Issues:  viele...  
42. Contributors...   Beiträge     willkommen!
43. Contribu4ons  welcome   •  Method guide: http://aim42.github.io   – Source:  hfps://github.com/aim42/aim42   •  https://github.com/aim42/aim42/ issues •  Twifer:    @arc_improve42   •  Mailing  list:    aim42@lists.innoq.com