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

  2. Photo by Angelina Litvin on Unsplash Time-to-Market? IT-Sicherheit? Performance? Zukunfts-

    sicherheit? Erweiterbarkeit? Wer-trägt Schuld? Bestätigung
  3. • steigende Zahl „Prio-1 Fehler“ • Entwicklung wird immer langsamer

    • (Neues) Management benötigt „neutrale“ Einschätzung Warum – Was – Wer - Wie Beispiele
  4. *: 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.
  5. 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“
  6. + 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
  7. • 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“
  8. • 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
  9. * 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.
  10. Access ALL Areas. Breitensuche Stakeholder Kontext Qualität Architektur Code Laufzeit

    Daten Tests Prozesse Infrastruktur Security .... Analyze
  11. • (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
  12. Warum – Was – Wer - Wie Metriken • Kopplung

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

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

    Anwendungs- daten Qualität (ATAM) Security Prozesse
  15. Warum – Was – Wer - Wie Der Abschluss... Bericht:

    • Management Summary • (priorisierte) Probleme • Maßnahmenvorschläge gut
  16. Tipp: Expect to be wrong Photo by Andrej Lišakov on

    Unsplash Warum – Was – Wer - Wie
  17. 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
  18. Expect to be wrong Photo by William Bossen on Unsplash

    Konkret: • Review-Ergebnisse in zwei Iterationen vorstellen • Erste Iteration für Feedback und Korrekturen
  19. 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
  20. • 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
  21. 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