Slide 1

Slide 1 text

Know Your Enemies Probleme in So,ware finden – aber rich4g Dr. Gernot Starke innoQ Fellow

Slide 2

Slide 2 text

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 [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 Configuration 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

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Iden4fiziere Probleme •  Konkret / spezifisch – Nachvollziehbar •  Was ist das Problem? – {Wobei | Wo | Wann} trie es auf? •  Auswirkungen? –  (Verursachter Schaden?) analyze evaluate improve

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 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 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

„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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Korrelierte Codeanalyse (2)

Slide 28

Slide 28 text

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?

Slide 29

Slide 29 text

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

Slide 30

Slide 30 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 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Fazit (3) 42 Vorsicht: Mikroskop-Falle

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Ein Beispiel... 42

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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)

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Daten-Chaos (2) Datenmodell auf AS/400... – 5 Tabellen, jeweils 400 Spalten – Massiv (!) gekoppelt ... (400) ... (400) ... (400) ... (400) ... (400)

Slide 42

Slide 42 text

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“

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Projekt 42

Slide 47

Slide 47 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 / Lebensmieelindustrie

Slide 48

Slide 48 text

Website Whitepaper

Slide 49

Slide 49 text

Code: github

Slide 50

Slide 50 text

Issues: viele...

Slide 51

Slide 51 text

Contributors... Beiträge willkommen!

Slide 52

Slide 52 text

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