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

Software Reviews (SECO)

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.

Dr. Gernot Starke

December 14, 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“) Datenqu elle Datenqu elle Datenqu elle Daten Infrastruktur Entwicklungs- prozesse mobile App Fremd- firmen Fremd- firmen etc.
  4. + 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
  5. • (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
  6. • 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
  7. Access ALL Areas. Breitensuche Stakeholder Kontext Qualität Architektur Code Laufzeit

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

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

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

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

    • Management Summary • (priorisierte) Probleme • Maßnahmenvorschläge gut
  17. 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
  18. • 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
  19. Fazit 1. Ziele und Scope klären 2. (mehrere!) Stakeholder involvieren

    3. Breiten- vor Tiefensuche 4. Mehr als Code untersuchen!! 5. Ergebnisse präsentieren