Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OOP 2021: The Art of Software Reviews

OOP 2021: The Art of Software Reviews

Methodisches Vorgehen bei Software Reviews, beginnend bei den konkreten Zielen, dem Scope sowie den notwendigen Personen.

Anschliessend schauen wir in Breitensuche auf verschiedene Bereiche, wie Code, Architektur, Betrieb, Tests und so weiter.

Dr. Gernot Starke

February 09, 2021
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. The Art of
    Software Reviews
    Dr. Gernot Starke
    Photo by gustavo centurion on Unsplash

    View full-size slide

  2. Dr. Gernot Starke
    INNOQ Fellow
    üArchitektur-Verbesserer
    üCoach, Trainer
    ü arc42, aim42
    ü iSAQB

    View full-size slide

  3. Annahme:
    Sie haben
    Software…

    View full-size slide

  4. Room for
    improvement…
    Photo by John Hult on Unsplash

    View full-size slide

  5. Software Reviews
    Warum – Was – Wer - Wie
    Agenda

    View full-size slide

  6. Warum – Was – Wer - Wie
    Warum Software Reviews?

    View full-size slide

  7. Reviews
    vermeiden...
    lösungsgetriebenen
    Aktionismus

    View full-size slide

  8. Behandlung
    ohne
    Untersuchung

    View full-size slide

  9. Cannabidiol
    100mg/Tag

    View full-size slide

  10. •Stärken+Schwächen
    als Grundlage für Verbesserung
    •Neutrale Meinung
    Extremfall: Juristisch relevante Gutachten
    •neue Ideen
    Warum – Was – Wer - Wie

    View full-size slide

  11. Ziele schärfen
    Photo by Angelina Litvin on Unsplash
    Warum – Was – Wer - Wie

    View full-size slide

  12. Photo by Angelina Litvin on Unsplash
    Time-to-Market?
    IT-Sicherheit?
    Performance?
    Zukunfts-
    sicherheit?
    Erweiterbarkeit?
    Wer-trägt
    Schuld?
    Bestätigung

    View full-size slide

  13. • steigende Zahl „Prio-1 Fehler“
    • Entwicklung wird immer langsamer
    • (Neues) Management benötigt
    „neutrale“ Einschätzung
    Warum – Was – Wer - Wie
    Beispiele

    View full-size slide

  14. Warum – Was – Wer - Wie
    Was betrachten wir?
    (scope)

    View full-size slide

  15. Photo by Michael Dziedzic on Unsplash

    View full-size slide

  16. *: XY z.B. Warenwirtschaft, online-Shop, Planungssystem, ERP-System, whatever-you-develop
    unser
    XY*
    externe
    Nachbarsysteme
    3rd Party
    Zulieferung
    („Framework“)
    Datenquel
    le
    Datenquel
    le
    Datenquel
    le
    Datenquelle
    Vor-
    verarbeitung
    nachgelagerte
    Verarbeitung
    mobile
    App
    Fremd-
    firmen
    Fremd-
    firmen
    etc.

    View full-size slide

  17. Warum – Was – Wer - Wie
    Scoping
    ernst
    nehmen!

    View full-size slide

  18. Fokus auf
    höchste
    Wertschöpfung
    Photo by Michael Dziedzic on Unsplash

    View full-size slide

  19. Fokus auf
    intensivste
    Nutzung
    Photo by Martin Adams on Unsplash

    View full-size slide

  20. https://www.youtube.com/watch?v=xL40UN5p6IY

    View full-size slide

  21. Tipp:
    Erweitere
    Suchraum
    Photo by Angelina Litvin on Unsplash
    Warum – Was – Wer - Wie

    View full-size slide

  22. Erweitere
    Suchraum
    Photo by William Bossen on Unsplash
    Beispiel: Rechnungswesen Konzern
    (Metrik basierter) Review untersucht Java-Code:
    Findet „Clean-Code“ und spricht Lob aus
    • Realität: Krass schlechte Time-To-Market
    • 70% des Codes ist XSLT,
    beim Review „übersehen“

    View full-size slide

  23. Warum – Was – Wer - Wie
    Wer reviewt?

    View full-size slide

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

    View full-size slide

  25. • Automotive (Zulieferer):
    • 1 Person extern max. 10 PT)
    (Qualitative Analyse analog ATAM),
    • 2 Personen intern
    Warum – Was – Wer - Wie
    Beispiele Zukunftssicherheit der Architektur
    „Multimedia-Framework“

    View full-size slide

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

    View full-size slide

  27. Warum – Was – Wer - Wie
    Wie geht das?

    View full-size slide

  28. * The Police, englische New-Wave-Band, gilt als eine der erfolgreichsten Rockbands.
    Don‘t Stand So Close to Me*
    #fightCoronaSong, belegte 1980 Platz-1 der britischen Single-Charts.

    View full-size slide

  29. Alles miterleben: AAA

    View full-size slide

  30. Access
    All
    Areas

    View full-size slide

  31. Access ALL Areas.
    Breitensuche
    Stakeholder Kontext Qualität Architektur Code Laufzeit Daten Tests Prozesse Infrastruktur Security ....
    Analyze

    View full-size slide

  32. Breitensuche
    Metriken
    Struktur
    Anwendungs-
    daten
    Qualität
    Security
    Prozesse
    Code
    Technologie
    etc.

    View full-size slide

  33. Breitensuche:

    View full-size slide

  34. Stakeholder kennen
    viele Probleme
    (+ Lösungen).

    View full-size slide

  35. • (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

    View full-size slide

  36. Warum – Was – Wer - Wie
    Metriken
    • Kopplung / Abhängigkeiten
    • Code-Komplexität
    • Performance
    • …
    gut

    View full-size slide

  37. Photo by Ross Findon on Unsplash
    Not all artifacts
    are equal.
    Some are
    more important.

    View full-size slide

  38. Photo by Ross Findon on Unsplash
    Häufige Änderungen

    häufig Fehler

    View full-size slide

  39. Achte auf
    Änderungsrate
    Photo by Ross Findon on Unsplash

    View full-size slide

  40. Warum – Was – Wer - Wie
    Metriken
    • Kopplung / Abhängigkeiten
    • Code-Komplexität
    • Performance
    • …
    • Fehler pro Baustein
    • Know-How pro Baustein
    • Änderungshäufigkeit
    • …
    gut besser

    View full-size slide

  41. komplexer Code, der häufig geändert wird.
    Beachte Hotspots

    View full-size slide

  42. Warum – Was – Wer - Wie
    Breitensuche
    Metriken
    Struktur
    Anwendungs-
    daten
    Qualität
    (ATAM)
    Security
    Prozesse

    View full-size slide

  43. Warum – Was – Wer - Wie
    Der Abschluss...
    Bericht:
    • Management Summary
    • (priorisierte) Probleme
    • Maßnahmenvorschläge
    gut

    View full-size slide

  44. Tipp:
    Expect
    to be wrong
    Photo by Andrej Lišakov on Unsplash
    Warum – Was – Wer - Wie

    View full-size slide

  45. Expect
    to be wrong
    Photo by William Bossen on Unsplash
    Bleiben
    Sie
    ergebnisoffen

    View full-size slide

  46. Expect
    to be wrong
    Photo by William Bossen on Unsplash
    Beispiel: Datenpflege eCommerce
    • Review findet „Verbesserungspotential“
    in entsprechender UI
    • Realität: Datenpflege per Batch-Import,
    UI wird (praktisch) nur zur Ansicht verwendet

    View full-size slide

  47. Expect
    to be wrong
    Photo by William Bossen on Unsplash
    Konkret:
    • Review-Ergebnisse in zwei Iterationen
    vorstellen
    • Erste Iteration für Feedback und
    Korrekturen

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  50. Fazit
    1. Ziele und Scope klären
    2. Stakeholder involvieren
    3. Schwerpunkte aus Zielen ableiten
    4. Breiten- vor Tiefensuche: Mehr als Code!!
    5. Ergebnisse in zwei Iterationen präsentieren

    View full-size slide

  51. Danke.
    Gernot Starke
    [email protected]
    Twitter: @gernotstarke
    www.innoq.com

    View full-size slide