No-Frills-Software-Engineering

nach \cite{Gruhn2008}

• "Software-Engineering ohne Schnickschnack"
• soll eine schlanke und wertorientierte Alternative zu herkömmlichen Vorgehensweisen zur Entwicklung von Informationssystemen bieten
• ein Fokus liegt auf Umgang mit Unsicherheiten (z.B. Unsicherheiten der Entwickler bzgl. Anforderungen, Unsicherheiten der Anwender bzgl. Funktion der Software etc.)
• vergleichbar mit dem Konzept von Billig-Airlines → nur die wichtigsten Elemente der Dienstleistung werden benötigt (bei trotzdem guter Qualität)

• Verstehe das ganze Problem in voller Breite
  • Entwicklern fehlt häufig das Domänenwissen → Fehler aufgrund mangelnden Domänenwissens sind teuer (da sie meist spät erkannt werden)
  • nur der Blick fürs Ganze erlaubt die sinnvolle Auswahl und korrekte Formulierung der Anforderungen
• Identifiziere das Schlüsseldokument
  • üblicherweise entstehen im Entwicklungsprozess viele verschiedenartige Dokumente, die nicht unbedingt "wertvoll" sind → hier den Überblick zu wahren ist sehr schwierig und zeitaufwendig
  • für jeden Dokumententyp sollte ein (!) Einstiegsdokument festgelegt werden, das ggfs. auf weitere Dokumente verweist
  • des Weiteren sollte es einige wenige Kerndokumente geben, die als Einstieg in die Dokumentation dienen und das absolut notwendige Wissen enthalten müssen
• Design for Change
  • Software wird allgemein als leicht änderbar empfunden, da sie (im Gegensatz zu materiellen Gütern) nicht greifbar ist
  • Zwei (schlechte) Prinzipien zum Umgang mit Änderbarkeit
    • Änderungen werden durch langwierige Anforderungsdefinitionen quasi ausgeschlossen
    • man erstellt generische Software, die "alles" kann
  • Änderbarkeit, Modularisierung, Abstraktion wird vornehmlich dort angewendet, wo sie in Zukunft voraussichtlich benötigt wird
  • die restlichen Bereiche werden "normal" entwickelt und liefern "nur" die Funktionalität laut den Anforderungen
• Wähle das richtige Abstraktionsniveau
  • zu Beginn der Entwicklung sind Detailfragen (z.B. Datentyp und Länge der Kundenadresse) nicht wichtig, es geht darum, beim Entwickler das Verständnis für die Domäne zu schaffen (z.B. Unterschied Antrag, Vertrag, Angebot einer Versicherung)
  • während der Entwicklung sind natürlich Detailfragen elementar
  • alle Dokumente (z.B. Klassendiagramme) müssen im Hinblick auf den Empfänger (z.B. den Fachbereich) erstellt werden und das entsprechende Abstraktionsniveau einhalten
• Trenne Anforderungen und Design
  • die Entwickler sollen nicht einfach die Lösungen der Fachbereiche implementieren, sondern vielmehr die Probleme verstehen und Lösungen anbieten
  • die Hinterfragung der Aspekte hinsichtlich Lösung (Design) oder Problem (Anforderung) führt zu einem tieferen Verständnisses des Problems und somit zu einer besseren Abwägung der verschiedenen möglichen Lösungen

• Teste, validiere und überprüfe das Wesentliche
  • nach Möglichkeit sollten nur die Programmteile erneut qualitätsgesichert werden, die geändert wurden
  • kritische Programmteile (die der Anwender zu Gesicht bekommt) sollten intensiver getestet werden → subjektiv höhere Qualität der Software
• Fordere schlanke Lösungen
  • zu jedem Zeitpunkt der Entwicklung sollte versucht werden, weniger Software zu erstellen
  • Pareto-Prinzip: wenn mit 20% Entwicklungsaufwand 80% des Tagesgeschäfts behandelt werden kann, müssen die verbleibenden 20% die Weiterentwicklung rechtfertigen
  • Möglichkeiten zur Automatisierung sollten ausgeschöpft werden
  • kann die Anforderung auf eine andere Art erfüllt werden?
  • was passiert, wenn wir die Anforderung weglassen? → häufig nichts
• Produktivität = Nutzen / Aufwand
  • die Produktivität ist besonders hoch, wenn mit wenig Aufwand schlanke Lösungen gefunden werden, die viele Anforderungen abdecken

• Design von außen nach innen
  • Informationssysteme müssen meistens in eine bestehende Systemlandschaft integriert werden (keine "grüne Wiese")
  • Integration-Engineering dominiert → nicht erst das neue System planen und dann über die Integration zum Altsystem nachdenken
• Prüfe Sourcing-Möglichkeiten
  • meist werden Aufgaben im Team anhand von Interessen oder aktueller Auslastung der Mitarbeiter verteilt → unglückliche Aufgabenverteilung (z.B. Implementierung unternehmenskritischer Anforderungen durch externe Partner)
  • die Frage der Aufgabenverteilung sollte strategisch entschieden werden
• Vermeide technologische Debatten
  • Technologiediskussionen verlieren sich schnell im Detail und arten in Glaubenskriege aus

• Professionelle und fokussierte Kommunikation
  • Stakeholder müssen immer auf dem Laufenden sein → die Informationen sind jedoch meist überfrachtet und nicht priorisiert, sodass das wichtige unter den Tisch fällt
  • die richtigen Informationen müssen zur richtigen Zeit in der richtigen Form vermittelt werden
  • Beispiel Anwender: sie dürfen keine überzogenen Vorstellungen an das System haben, sondern die Fähigkeiten realistisch einschätzen können
• Wähle die passenden Sprachen und Werkzeuge für die Stakeholder
  • Fließtext des Fachbereichs hilft den Entwicklern nicht (zu schwierig), UML der Entwickler hilft dem Fachbereich nicht → Lösung: vereinfachte Form der UML oder nur intuitiv verstehbare Modelltypen verwenden
• Überprüfe auf No-Frills-Prinzipien
  • viele Unternehmen kennen ihre eigenen Entwicklungsprozesse nicht oder sie werde mit der Zeit immer fetter
  • regelmäßige Retrospektiven sind erforderlich um den Prozess zu optimieren

• Entwickle eine Vision
  • Warum wird die Software erstellt? → strategische, wirtschaftliche Ziele
  • Für wen wird die Software erstellt? → Stakeholder
  • Was soll die Anwendung grob tun und was nicht? → Funktionalität
  • die Erfassung der Vision erfolgt methodengestützt (Results Chain Analysis, Benefits Realization Analysis)
  • Fokussierung auf Wesentliches und angemessene Abstraktion
  • die Vision muss allen Stakeholdern klar sein und von allen akzeptiert werden
• Sammeln von Anforderungen
  • strukturierte Erfassung von Anforderungen, deren Herkunft und Priorität
  • Dokumentation von Unsicherheiten durch Annotationsverfahren nach Brügge
  • bereits Berücksichtigung der Release-Planung → Ziel ist Priorisierung der Anforderungen und zeitliche Planung ihrer Umsetzung
• No-frills-Entwurf
  • Einsatz von UML-Profilen, die Ungenauigkeiten und Unschärfen darstellen können
• Prototyping
  • Erwartungen der Anwender managen → sie werden kontinuierlich eingebunden und mit Zwischenergebnissen konfrontiert → Unsicherheiten sowohl auf Seiten der Entwickler als auch auf Seiten der Anwender werden abgebaut
  • Wegwerf-Oberflächenprototypen zeigen die Navigation → sinnvoll bei neuen Geschäftsprozessen
  • Klickbare Struktur-Prototypen wachsen schrittweise zu einem Abbild der Anwendung heran, veranschaulichen das grundlegende Verhalten
• Testen
  • Ableitung der Testfälle aus vorgelagerten Artefakten
  • Teste das Wesentliche

• Aufbau eines breiten Domänenwissens bei den Entwicklern → konsistene Artefakte
• der Softwareentwicklungsprozess läuft schlanker und wird an den wichtigen Stellen methodisch gezielt unterstützt
• explizite Behandlung des Themas Unsicherheit gerade im Bereich der Anforderungen
• kontinuierliche Ausrichtung auf den wirtschaftlichen Nutzen der Software