Know Your Enemies: Probleme in Software finden

ie meiste Zeit verbringen wir in der Softwareentwicklung mit
Änderung oder Verbesserung bestehender Systeme - dabei ist es
besonders wichtig, an den richtigen Stellen zu ändern (und nicht
willkürlich die bekannten Refactoring-Patterns anzuwenden)

Ich zeige auf, wie Sie systematisch die aus langfristiger und
ökonomischer Sicht schlimmsten Probleme in Ihren
Softwaresystemen und -architekturen finden können -
und wie sie dann deren Lösung angehen können.

Dabei spannen wir den Bogen von der Analyse der beteiligten Stakeholder und externen Schnittstellen über verschiedene
Ansätze der (quantitativen) Code- und (qualitativen) Architekturanalyse bis hin zu fortgeschrittenen Themen wie Datenanalyse, Prozessanalyse oder Kontextanalyse.

Anhand realer Probleme aus mittleren und großen Projekten zeige
ich auf, dass die "Feinde" manchmal an überraschenden Stellen
lauern...

Stichworte:
* Problemanalyse in Software-Projekten und -architekturen
* Stakeholderanalyse
* Interviewtechniken zur Problemanalyse
* Kontextananyse
* statische und dynamische Codeanalyse
* Datenanayse
* Analyse der (technischen) Infrastruktur
* Analyse von Entwicklungs- und Betriebsprozessen

Transcript

1. Know Your Enemies Probleme in So,ware finden – aber rich4g Dr. Gernot Starke innoQ Fellow
2. Dr. Gernot Starke innoQ Fellow   Softwarearchitekturen Entwurf, Entwicklung, Management Evolution & Modernisierung Dokumentation Training   Mentoring und Coaching Analyse und Optimierung von Entwicklungsprozessen   Reviews +49 177 – 728 2570 Gernot.Starke@innoQ.com 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. Typische Problemzonen 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
12. Iden4fiziere Probleme •  Konkret / spezifisch – Nachvollziehbar •  Was ist das Problem? – {Wobei | Wo | Wann} trie es auf? •  Auswirkungen? –  (Verursachter Schaden?) analyze evaluate improve
13. Issue List Legende: •  Frequenz: Wie o, trie das Problem auf? Pro Aufruf, pro Release, pro implemen4ertem Feature, ... •  Kosten: Was kostet uns das Problem? •  Links zu möglichen Maßnahmen (Improvements) id Name Descrip0on Frequency Cost [Max, min] Associated Improvements P1 Wrong data in op4cal archive ~10x daily •  3 secs per search request P2 View pipeline modifies data (& crippled use of Apache Cocoon) ~1000x daily •  2 pd
14. Beispiel 2 ID Beschreibung Häufigkeit Wert (min) Wert (max) Abhilfen PD-1 Falsche Berechnung Ar4kelpreis bei Kombina4on aus Rabaekarte, 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.00 0 € V-3 C-1 Zeit zur Iden4fika4on + Behebung von Laufzeisehlern zu lang (bis zu 5 T bei kri4schen Fehlern) 1x / Woche V-4 || V-3 C-2 Zeit für kompleeen Test der Anwendung > 10 T 4 x / Jahr V-4
15. Tools zum Führen der Issue-List •  Issue-Tracking-Systeme wie – JIRA, Trac, RedMine, YouTrack, ... •  Excel-Listen •  Post-It-Notes, Staeys, Karteikarten high-tech low-tech
16. 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 ...
17. 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!!
18. Stakeholder-Interviews (2) •  Vorbereitung: individueller Vorab-Fragebogen – Zeigt Hochachtung vor Gesprächspartner – Siehe: hep://aim42.github.io/#Stakeholder-Interview •  Fragen nach: – Problemen + Lösungsmöglichkeiten bezüglich •  System, •  Prozesse, •  Organisa4on
19. Kontextanalyse (1) •  Fachlicher Kontext – System-Scope – Externe Schniestellen •  Daten-Eingang •  Daten-Ausgang •  UI •  Events •  Technischer Kontext – Kanäle – Protokolle
20. Kontextanalyse (2) Mögliche Risiken im Kontext: •  Abhängigkeiten bzgl. Qualitätszielen –  Verfügbarkeit, Robustheit, –  Sicherheit –  Kosten –  Performance •  Fehlende Schniestellen Risiko bzgl. Performance- Anforderung
21. Kontextanalyse (3) Mögliche Risiken im Kontext: •  Vola4le Nachbarsysteme Risiko / Problem bzgl. Stabilität der Schniestelle Unser System Anderes (innova4ves) Projekt / System getImportantData( customerID)
22. „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
23. Prozessanalyse •  Anforderungsprozesse –  erheben, klären, managen •  Entwicklungs- /Entwurfsprozesse – Architektur, Implemen4erung, Dokumenta4on •  Betrieb – Deployment, Rollout, Administra4on, Monitoring •  Management – Team- und Taskmanagement, Risikomanagement
24. warum, warum, warum... offshore- Dienstleister Abnahme erteilt, Basis „Funk4onsprüfung“ Abnahmeprozess auf Durchsatz op4miert he,iges Risiko bzgl. Verfügbarkeit
25. Sta4sche Codeanalyse •  Kopplung •  Komplexität •  Kohäsion (inhaltlicher Zusammenhang) •  Konsistenz (iden4sche Probleme ähnlich gelöst) •  Duplizierter Code •  Verletzung von Idiomen (Style-Checking)
26. 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
27. Korrelierte Codeanalyse (2)
28. Datenanalyse (1) •  Struktur •  Typen •  Zugriffe – Read / write •  Volumen – auch von Query-Results + Indizes •  Inhalte – Korrektheit – Schutzbedarf 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?
29. Laufzeitanalyse •  Debugger •  Logfile-Analyse •  Performance-Analyse, Profiling •  Ressourcenverbrauch zur Laufzeit •  Analyse von Benutzerverhalten •  Analyse fachlicher Abläufe
30. 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
31. 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
32. Fazit (2)
    42 Führe •  Problem-Liste und •  Improvement-Backlog
33. Fazit (3)
    42 Vorsicht: Mikroskop-Falle
34. Fazit (4)
    42 Vorsicht: neue Feinde...
35. Dr. Gernot Starke gs@gernotstarke.de hep://gernotstarke.de hep://innoq.com heps://www.flickr.com/photos/foto_db/16000636092
36. Ein Beispiel...
    42
37. Nur ein Webshop ... J Private User User Groups Corporate Users Government Users i.B.O.S.S. Operations Internal Users Rebates, Vouchers, Campaigns, Combos Regulation & Standard Bodies •  Konfigurierbare Produkte •  Vielsei4ge Käuferstruktur •  Schwierige Preisbes4mmung •  Einzel- & Firmenverträge •  Rabaekarten •  Gutscheine •  Saisonpreise •  Kombi-Regelungen Umsatz in % (ca.) 25% 15% 35% 25% Archivierungspflicht Teilw. regulierte Preise
38. Historie (1) Systeme... 1992 1997 2003 2008 2013 „Atlas 1“ (Host) „Atlas 2“ (AS/400, Cobol) Backoffice- Katalog (Java + Host) eGov (Python) Web-Katalog (Java) Pricemaster (Smalltalk) ComSuite (Java & Python) B.O.S.S (Java & Co) i.B.O.S.S (Java & Co) Campaigner (Java, PHP) div. kleine Mitbewerber „WaWi“ (Host, Cobol)
39. Historie (2) Unternehmen... 1992 1997 2003 2008 2013 Atlas So,ware GmbH & Co. KG Dr. Blau & Partner Rot AG Hodor KG Ing-Büro WebDev Inc. (London + München) Rot Holding + Rot Europa Rot-Gelb Interna4onal AG Gelb Finance AG So,ware-Töchter in Ungarn, Polen, Rumänien, Pakistan Grau GmbH
40. Daten-Chaos (1) Daten- bank Optisches Archiv ORM Appl- Services Data Access Konfig- DB AS400 DB if (isAtlas( kunde )) { k1 = getFromOpticalArchive( kunde ); k2 = getFromAS400( k1, kunde); .... } else (isCampaigner( kunde) ) { k3 = getFromKonfigDB( kunde ); ....} } if (isAtlas2( kunde ) && kunde.rebate in... // Datenmigra0on wäre schön J
41. Daten-Chaos (2) Datenmodell auf AS/400... – 5 Tabellen, jeweils 400 Spalten – Massiv (!) gekoppelt ... (400) ... (400) ... (400) ... (400) ... (400)
42. Daten-Chaos (3) •  Op4sches (!) Archiv enthält ca. –  1 Mio. Kunden-Stammdaten –  10 Mio. Angebote –  50 Mio. Bewegungsdaten, Bewertungen + Verträge •  Zwischen 2001 und 2005 ca. 5-15% der Daten fehlerha, gespeichert – Insert-Logik enthielt sub4len Fehler – Poten4ell betroffen: Alle Write-Opera4onen... – Abhilfe: „Correct-Upon-Current-Use“
43. View-Pipeline (Apache Cocoon) Theorie: •  Separa4on 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 hep://cocoon.apache.org/2.1/userdocs/concepts/index.html
44. 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 Legend: Java PHP Python C/C++ Optical Archive Post-Sales Optimization Haskell Cobol Security Extensions PL/ SQL Add XML to most of these... Business Component Disorder
45. Team- und Organisa4ons-Wirrwarr •  40% Entwicklung Inhouse, •  30% Vertragspartner (siehe Orga-Historie) •  30% Near-/Offshore sowie extern •  Heterogene: – Vertrags- und Au,ragsgestaltung – Entwicklungs- und Inbetriebnahme-Prozesse – Umgebungen für Sourcen, Build, Test + Deploy
46. Projekt
    42
47. 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 / Lebensmieelindustrie
48. Website Whitepaper
49. Code: github
50. Issues: viele...
51. Contributors... Beiträge willkommen!
52. Contribu4ons welcome •  Method guide: http://aim42.github.io – Source: heps://github.com/aim42/aim42 •  https://github.com/aim42/aim42/ issues •  Twieer: @arc_improve42 •  Mailing list: aim42@lists.innoq.com