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

The Art of Software Reviews

The Art of Software Reviews

Jede Software besitzt "Potential", also "besser geht immer". Aber bevor wir anfangen, wild an unseren Systemen zu verschlimmbessern, benötigen wir zuerst einen ordentlichen Überblick über dessen Stärken und Schwächen.

Der Vortrag zeigt methodisches Vorgehen solcher Reviews, beginnend mit dessen konkreten Zielen, dem (schwierigen) Scope sowie den notwendigen Personen (aka Stakeholder).
Anschliessend schauen wir etwas genauer auf verschiedene Untersuchungsbereiche, wie Architektur, Code, Technologie, Qualitätsanforderungen bis hin zu Anwendungsdaten und
den Entwicklungs- und Rollout-prozessen. Ein Kernbegriff dabei lautet "iterative Breitensuche", wobei wir die bedarfsgerecht durch Tiefensuche ergänzen. Zu jedem Untersuchungsbereich gebe ich Beispiele und zeige methodische Werkzeuge um effektiven und praxisnahen Einsatz.

Schliesslich bekommen Sie noch Tipps, die Sie für überzeugende Darstellung und Kommunikation Ihrer Schlussfolgerungen und Empfehlungen beachten sollten.

Der Vortrag richtet sich an Software-Entwicklungsteams, Architekt*innen, Product-Owner sowie technisches Management.

Dr. Gernot Starke

December 08, 2020
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. Software Reviews
    und was die mit The Police zu tun haben...
    Dr. Gernot Starke

    View full-size slide

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

    View full-size slide

  3. Software
    Reviews
    ???

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. These: Jedes System hat
    Potenzial
    Photo by John Hult on Unsplash

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

    View full-size slide

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

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

    View full-size slide

  13. *: 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

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

    View full-size slide

  15. • internes Konzern-CRM:
    • Prozesse: Content-Akquise, Aufbereitung,
    Freigabe
    • Projektorganisation
    • SW-Technik
    • kein Betrieb
    Warum – Was – Wer - Wie
    Beispiele

    View full-size slide

  16. • (Groß-)Maschinenbau:
    • SW-Architektur + Implementierung
    • on-Device, Konfigurations-
    /Planungssystem
    • Projektorganisation
    • keine Datenquellen / -senken
    Warum – Was – Wer - Wie
    Beispiele

    View full-size slide

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

    View full-size slide

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

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

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  23. Access
    All
    Areas

    View full-size slide

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

    View full-size slide

  25. Breitensuche:

    View full-size slide

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

    View full-size slide

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

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

    View full-size slide

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

  30. • 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 Ziel: „Benchmarking“:
    Produktivität
    von Entwicklung prüfen

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  33. • „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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

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

  38. Fazit
    1. Ziele und Scope klären
    2. (mehrere!) Stakeholder involvieren
    3. Schwerpunkte aus Zielen ableiten
    4. Breiten- vor Tiefensuche
    5. Mehr als Code untersuchen!!
    6. Ergebnisse präsentieren

    View full-size slide

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

    View full-size slide