"Know your enemies": Probleme in Software finden

Slide 1

Slide 1 text

Know Your Enemies Probleme in So,ware ﬁnden – aber rich4g Dr. Gernot Starke

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

im normalen Leben... analyze evaluate improve

Slide 4

Slide 4 text

dieser Vortrag... analyze evaluate improve

Slide 5

Slide 5 text

Gute Problemanalyse hil, bei... •  Priorisierung von Änderungen •  Balancieren kurz-‐ / langfris4ger Maßnahmen

Slide 6

Slide 6 text

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 Conﬁguration consists-of Goals Constraints impose ➤ has explicit and implicit ➤ complies with ➤ restrict ➤ ➤ aim42 domain model

Slide 7

Slide 7 text

warum diese Trennung? •  rich4g: – wich0ge Probleme lösen •  schlechter: – einfache Probleme lösen •  ganz schlecht: – interessante Problemlösungen umsetzen – Ak4onismus €

Slide 8

Slide 8 text

Die Rela4vitäts-‐Falle Des Einen Problem ist des Anderen Freund

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

proﬁ4eren vom Problem, haben das Problem erschaﬀen, 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 11

Slide 11 text

Die Mikroskop-‐Falle Wenn Sie NUR im Code suchen, werden Sie NUR DORT Probleme ﬁnden... im Code suchen ist rich4g und wich4g, aber NUR dort suchen ist fatal!

Slide 12

Slide 12 text

hfps://www.ﬂickr.com/photos/jonasb/24341322

Slide 13

Slide 13 text

hfps://www.ﬂickr.com/photos/emiliano-‐iko/5354414276

Slide 14

Slide 14 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 15

Slide 15 text

Iden4ﬁziere Probleme •  Konkret / speziﬁsch •  Wiederholbar •  Was ist das Problem? •  {Wobei | Wo | Wann} trif es auf? •  Reproduzierbar? •  Auswirkungen? (Verursachter Schaden?) analyze evaluate improve

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Stakeholderanalyse •  Stakeholder kennen Probleme – nehmen Probleme aus ihrer Perspek4ve wahr (subjek4v) – nennen o,mals Symptome, keine Ursachen – äußern Vermutungen •  Vorsicht: – Gewöhnungseﬀekt – Angst vor Änderung Anwender, Entwickler, Support, Fachleute, BackOﬃce, Architekten, Betreiber, Au,raggeber, Tester, Admins, Projekt-‐/Linienverantwortliche, Controller, CEO, COO, CFO ...

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Kontextanalyse (3) Mögliche Risiken im Kontext: •  Vola4le Nachbarsysteme Risiko / Problem bzgl. Stabilität der Schnifstelle Unser System Anderes (innova4ves) Projekt / System getImportantData( customerID)

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Prozessanalyse •  Anforderungsprozesse –  erheben, klären, managen •  Entwicklungs-‐ /Entwurfsprozesse – Architektur, Implemen4erung, Dokumenta4on •  Betrieb – Deployment, Rollout, Administra4on, Monitoring •  Management – Team-‐ und Taskmanagement, Risikomanagement

Slide 25

Slide 25 text

warum, warum, warum... oﬀshore-‐ Dienstleister Abnahme erteilt, Basis „Funk4onsprüfung“ Abnahmeprozess auf Durchsatz op4miert he,iges Risiko bzgl. Verfügbarkeit

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Korrelierte Codeanalyse Abgleich unterschiedlicher Beobachtungen/Messungen Beispiele: •  Fehler pro Komponente / Subsystem •  Benö4gte Zeit pro Bugﬁx pro Komponente •  Benö4gter Aufwand pro Feature pro Komponente

Slide 28

Slide 28 text

Korrelierte Codeanalyse (2)

Slide 29

Slide 29 text

Datenanalyse (1) •  Struktur •  Typen •  Zugriﬀe –  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?

Slide 30

Slide 30 text

Laufzeitanalyse •  Debugger •  Logﬁle-‐Analyse •  Performance-‐Analyse, Proﬁling •  Ressourcenverbrauch zur Laufzeit •  Analyse von Benutzerverhalten •  Analyse fachlicher Abläufe

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Fazit: Analyse in Vogelperspek4ve Issues & Improvements system analyisis existing organization & processes existing system ﬁndings & 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 ﬁndings & suggestions 8 8

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Fazit (3) 42 Vorsicht: Mikroskop-‐Falle

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Dr. Gernot Starke [email protected] hfp://gernotstarke.de hfp://innoq.com hfps://www.ﬂickr.com/photos/foto_db/16000636092

Slide 37

Slide 37 text

Projekt 42

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Website Whitepaper

Slide 40

Slide 40 text

Code: github

Slide 41

Slide 41 text

Issues: viele...

Slide 42

Slide 42 text

Contributors... Beiträge willkommen!

Slide 43

Slide 43 text

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: [email protected]