Software Reviews (SECO)

Unsere Systeme besitzen immer "Potential", also Optimierungsmöglichkeiten. Mit Hilfe gezielter Reviews verschafft man sich einen Überblick über die konkreten Stärken und Schwächen, als Grundlage gezielter Verbesserungen.

Der Vortrag zeigt methodisches Vorgehen solcher Reviews, beginnend mit dessen konkreten Zielen und dem Scoping. Ihr lernt, wie (und ob?) ihr ein Review mit dem eigenen Entwicklungsteam durchführen könnt und welche Stakeholder ihr unbedingt noch involvieren solltet.

Anschließend schauen wir etwas genauer auf verschiedene Untersuchungsbereiche von Reviews, wie Architektur, Code, Technologie, Qualitätsanforderungen bis hin zu Anwendungsdaten sowie Entwicklungs- und Betriebsprozessen. Der wohl wichtigste Begriff dabei lautet "iterative Breitensuche" - die wir bedarfsgerecht durch Tiefensuche ergänzen. Zu jedem Untersuchungsbereich gebe ich Beispiele und zeige methodische Werkzeuge für deren effektive und praxisnahe Anwendung.

Transcript

1. The Art of Software Reviews Gernot Starke INNOQ Fellow
2. Dr. Gernot Starke INNOQ Fellow üArchitektur-Verbesserer üCoach, Trainer ü arc42, aim42 ü iSAQB
3. Ähnlichkeiten... mit real-existierenden Situationen sind erwünscht. Alle Situationen abstrahiert und neutralisiert, um Non-Disclosure zu respektieren.
4. Software Reviews ???
5. Mary Million. CFO der MEMM Inc. (global investment) CFO des Jahres 2018 einer Großbank
6. Mary Million. Unabhängige Meinung Probleme in Produktion, Stabilität? Time-to-Market? Zukunftssicher?
7. Software Reviews Warum – Was – Wer - Wie Agenda
8. Warum – Was – Wer - Wie Warum Software Reviews?
9. These: Jedes System hat Potenzial Photo by John Hult on Unsplash
10. Reviews vermeiden... lösungsgetriebenen Aktionismus
11. Behandlung ohne Untersuchung …
12. Cannabidiol 100mg/Tag
13. • Übersicht: Stärken+Schwächen als Grundlage für Verbesserung • Neutrale Meinung Extremfall: Juristisch relevante Gutachten • neue Ideen / Anregungen • Bestätigungvon Vermutungen Warum – Was – Wer - Wie
14. • steigende Zahl „Prio-1 Fehler“ • Entwicklung wird immer langsamer • (Neues) Management benötigt „neutrale“ Einschätzung Warum – Was – Wer - Wie Beispiele
15. Warum – Was – Wer - Wie Was betrachten wir? (scope)
16. *: XY z.B. Warenwirtschaft, online-Shop, Planungssystem, ERP-System, whatever-you-develop unser XY * externe Nachbarsysteme 3rd Party Zulieferung („Framework“) Datenqu elle Datenqu elle Datenqu elle Daten Infrastruktur Entwicklungs- prozesse mobile App Fremd- firmen Fremd- firmen etc.
17. Warum – Was – Wer - Wie Scoping ernst nehmen!
18. Warum – Was – Wer - Wie Wer reviewt?
19. + unabhängig + neutral + neue Impulse - längere Einarbeitung - Risiko „oberflächlich“ - höhere Kosten + fachliche Erfahrung + im Unternehmen vernetzt + kostengünstig - Risiko „befangen“ - Risiko „betriebsblind“ - kein Benchmarking - „Prophet im eigenen Land“ Warum – Was – Wer - Wie
20. • (Riesen-)Online-Shop: • 4 Personen extern (INNOQ), ca. 100 PT • 3 Personen intern, 30+ PT • Verpflichtung, 24 Monate keine weiteren Aufträge für dieses Unternehmen Warum – Was – Wer - Wie Beispiele Zukunftsfähigkeit von Architektur und Implementierung
21. • Telco („Billing-Kette“): • 3 externe Dienstleister, jeweils 2-3 Personen, gesamt ca. 200 PT • 2-3 Personen intern, 30+ PT • Aufteilung entlang der Prozesskette (u.a. Wirknetz, Pre-/Post-Billing) Warum – Was – Wer - Wie Beispiele Tragfähigkeit der Architektur sowie Integration von Standardprodukten
22. Warum – Was – Wer - Wie Wie geht das?
23. kostenfreier Download! So geht das!
24. Access All Areas
25. Access ALL Areas. Breitensuche Stakeholder Kontext Qualität Architektur Code Laufzeit Daten Tests Prozesse Infrastruktur Security .... Analyze
26. Breitensuche:
27. Stakeholder kennen viele Probleme (+ Lösungen).
28. • (Riesen-)Online-Shop: • Interviews zeigten: • (krasse) Diskrepanzen in Sichtweisen Management + Entwicklungsteams • Architekturprobleme, die beim Management nicht bekannt waren Warum – Was – Wer - Wie Beispiele Zukunftsfähigkeit von Architektur und Implementierung
29. Warum – Was – Wer - Wie Metriken • Kopplung / Abhängigkeiten • Code-Komplexität • Performance • … gut
30. Warum – Was – Wer - Wie Metriken • Kopplung / Abhängigkeiten • Code-Komplexität • Performance • … • Fehler pro Baustein • Know-How pro Baustein • Änderungshäufigkeit • … gut besser
31. Telekommunikation: • Management beobachtet (Java-) Metriken nach Ampel-System (CAST Application Intelligence Platform) • >70% des Systems in xslt implementiert, • nicht von CAST erfasst Warum – Was – Wer - Wie Beispiele
32. komplexer Code, der häufig geändert wird. Beachte Hotspots
33. Hotspots bei Docker
34. Kohäsion (inhaltlicher Zusammenhalt)
35. Wo sollen wir anfangen? (uns fehlt Zeit...)
36. Fokus auf höchste Wertschöpfung Photo by Michael Dziedzic on Unsplash
37. Fokus auf intensivste Nutzung Photo by Martin Adams on Unsplash
38. Photo by Martin Adams on Unsplash Konkret: • Usage Analytics • Business Monitoring Logfiles…
39. Anti-Beispiel (schlechte Kohäsion) UDS (User Data Service) Order & Fullfillment Vouchers & Rebates Sales & Contracts Archive Price Management Marketing & Sales Campaigns Atlas Customs & Logistics Pricing Engine Sales Backend Private+Corp Sales Backend eGovernment Ermittelt Preise Berechnungen, die für Preise releant sind
40. Analyse von Entwicklungsprozessen Requirements, Architektur/Entwurf, Implementierung, Test, Deployment, Release, Support...
41. • (Groß-)Maschinenbau: • Prozessproblem (Know-How „Flaschenhals“) führt zu erheblichen Risiken in Code Beispiele Ziel: Möglichkeiten zur Verbesserung der Architektur aufzeigen Warum – Was – Wer - Wie
42. Strukturanalyse Passt Komponentenstruktur zum Problem?
43. Technologie-Analyse (1) Setzen wir adäquate Technologie ein?
44. Technologie-Analyse (2) Setzen wir Technologie adäquat ein?
45. https://www.youtube.com/watch?v=xL40UN5p6IY
46. https://www.youtube.com/watch?v=xL4 0UN5p6IY
47. Analyse von Anwendungsdaten Datenstrukturen, Datenbanken, Verteilung/Replikation, Inhalte
48. • „Warenwirtschaft“: • Fachlich sauber strukturiert • In vielen Teilen (nearly) clean-code • Datenbank + -strukturen völlig desolat Warum – Was – Wer - Wie Beispiele Ziel: Verschiedene Wege zur „ganzheitlichen Verbesserung“ aufzeigen
49. Warum – Was – Wer - Wie Breitensuche Metriken Struktur Anwendungs- daten Qualität (ATAM) Security Prozesse
50. Probleme finden reicht nicht...
51. Probleme gefunden. Jetzt überzeugend kommunizieren. • Management Summary • (priorisierte) Probleme • Maßnahmenvorschläge
52. Warum – Was – Wer - Wie Der Abschluss... Bericht: • Management Summary • (priorisierte) Probleme • Maßnahmenvorschläge gut
53. Warum – Was – Wer - Wie Der Abschluss... Bericht: • Management Summary • (priorisierte) Probleme • Maßnahmenvorschläge 2 Vorträge: • Vorab „in kleiner Runde“ • Feinschliff • Abschluss „in großer Runde“ gut besser
54. • Spezial-Maschinenbau: • Management fokussiert auf mögliche Problemen • Abschlusspräsentation fokussiert auf Stärken der Teams + des Systems Warum – Was – Wer - Wie Beispiele Ziel: „Benchmarking“ Architektur und Entwicklung
55. Fazit 1. Ziele und Scope klären 2. (mehrere!) Stakeholder involvieren 3. Breiten- vor Tiefensuche 4. Mehr als Code untersuchen!! 5. Ergebnisse präsentieren
56. Fazit Risiken und Probleme lauern überall. Risiken und Probleme lauern überall. Nicht nur im Code. Breitensuche
57. Danke. Gernot Starke gernot.starke@innoq.com Twitter: @gernotstarke www.innoq.com