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

The Art of Software Reviews (JUG Zürich)

The Art of Software Reviews (JUG Zürich)

Jede Software besitzt „Potenzial“, 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.

In diesem kompakten Vortrag möchte Gernot einen Rundumschlag versuchen: beginnend mit Review-Zielen und -Scope über die notwendigen Personen (aka Stakeholder) bis hin zu Review-Methodik und der überzeugenden Darstellung von Schlussfolgerungen und Empfehlungen.

Dr. Gernot Starke

October 01, 2021
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. • Ü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
  2. • steigende Zahl „Prio-1 Fehler“ • Entwicklung wird immer langsamer

    • (Neues) Management benötigt „neutrale“ Einschätzung Warum – Was – Wer - Wie Beispiele
  3. *: XY z.B. Warenwirtschaft, online-Shop, Planungssystem, ERP-System, whatever-you-develop unser XY

    * externe Nachbarsysteme 3rd Party Zulieferung („Framework“) Datenquelle Datenquelle Datenquelle Datenquelle Vor- verarbeitung nachgelagerte Verarbeitung mobile App Fremd- firmen Fremd- firmen etc.
  4. • internes Konzern-CRM: • Prozesse: Content-Akquise, Aufbereitung, Freigabe • Projektorganisation

    • SW-Technik • kein Betrieb Warum – Was – Wer - Wie Beispiele
  5. • (Groß-)Maschinenbau: • SW-Architektur + Implementierung • on-Device, Konfigurations- /Planungssystem

    • Projektorganisation • keine Datenquellen / -senken Warum – Was – Wer - Wie Beispiele
  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. • (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
  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. Access ALL Areas. Breitensuche Stakeholder Kontext Qualität Architektur Code Laufzeit

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

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

    / Abhängigkeiten • Code-Komplexität • Performance • … • Fehler pro Baustein • Know-How pro Baustein • Änderungshäufigkeit • … gut besser
  13. 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
  14. 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
  15. • (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
  16. • „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
  17. Warum – Was – Wer - Wie Breitensuche Metriken Struktur

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

    • Management Summary • (priorisierte) Probleme • Maßnahmenvorschläge gut
  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. (mehrere!) Stakeholder involvieren

    3. Schwerpunkte aus Zielen ableiten 4. Breiten- vor Tiefensuche 5. Mehr als Code untersuchen!! 6. Ergebnisse präsentieren