Moderne Softwareentwicklung

• Risikoanalyse: Abwägung der Risiken hinsichtlich ihrer Wahrscheinlichkeiten und Auswirkungen. Ergebnis ist eine tabellarische Aufstellung der gefundenen Risiken und ihrer Bewertung
• Risikoplanung:
  • Vermeidungsstrategie: Auftreten des Risikos minimieren
  • Minimierungsstrategie: Auswirkungen des Risikos minimieren
  • Notfallpläne: Einstellen auf das schlimmste Szenario und planen wie mit diesem umzugehen ist
• Risikoüberwachung:
  • regelmäßige Überwachung (fortlaufender Prozess) der erkannten Risiken
  • haben sich die Wahrscheinlichkeiten der Risiken verändert?
  • haben sich die Auswirkungen der Risiken verändert?
  • sind neue Risiken hinzugekommen?

4 Phasen, die zyklisch durchlaufen werden:

• Festlegung der Ziele
  • Ziele und Anforderungen an das (Teil-)Produkt
  • Lösungsvarianten
  • Nebenbedingungen und Einschränkungen
• Beurteilung von Alternativen, Risikoanalyse
  • Erarbeitung und Beurteilung von Lösungsvarianten
  • Erkennen und beseitigen von Risiken
• Entwicklung und Testen
  • Entwicklung und Validierung des Produkts der nächsten Stufe
• Planung des nächsten Zyklus
  • Einverständnis über nächsten Zyklus herstellen

• Grundlagen des V-Modells: Dieser Teil führt in die zentralen Grundkonzepte des V-Modells ein und beschreibt das Zusammenspiel unterschiedlicher V-Modell-Projekte. Ferner werden Anwendungsrichtlinien eingeführt, welche die Umsetzung des V-Modells in konkreten Projekten regeln.
• Eine Tour durch das V-Modell: Zeigt in Ausschnitten, wie das V-Modell im Rahmen eines konkreten Beispielprojektes angewendet wird.
• V-Modell-Referenz Tailoring: Beschreibt die Projekttypen, Projektvarianten und Projektmerkmale, mittels derer ein für das jeweilige Projekt spezifisches Anwendungsprofil erstellt wird. Ferner stellt sie die wesentlichen Inhalte der mit dem V-Modell möglichen Projektdurchführungsstrategien und Vorgehensbausteine dar. Darüber hinaus werden die im V-Modell verfügbaren Entscheidungspunkte vorgestellt.
• V-Modell-Referenz Rollen: Vermittelt einen Überblick über alle im V-Modell vorgesehenen Rollen. Neben einer detaillierten Rollenbeschreibung wird für jede einzelne Rolle festgehalten, für welche Produkte und Aktivitäten die Rolle verantwortlich ist und wo sie mitwirkt.

• V-Modell-Referenz Produkte: Beinhaltet dem hierarchischen Produktmodell entsprechend alle Disziplinen, Produkte und Themen des V-Modells. Dabei werden explizit auch die Zusammenhänge zwischen den einzelnen Produkten durch sogenannte Produktabhängigkeiten beschrieben.
• V-Modell-Referenz Aktivitäten: Beinhaltet dem hierarchischen Aktivitätenmodell entsprechendalle Aktivitäten und Arbeitsschritte des V-Modells. Dabei wird insbesondere die Abwicklung dereinzelnen Arbeitsschritte im Rahmen einer Aktivität beschrieben
• V-Modell-Referenz Konventionsabbildungen: Als Basis organisationsweiter Entwicklungsprozesse muss das V-Modell kompatibel mit aktuellen (Quasi-)Standards, Normen und Vorschriften sein, wie zum Beispiel zur ISO 9001:2000, zur ISO/IEC 15288 und zum CMMI. Für jede dieser Konventionen enthält die V-Modell-Referenz Konventionsabbildungen eine Abbildung der Begriffe aus der entsprechenden Konvention in die Begriffswelt des V-Modells
• Anhang: Beinhaltet eine Reihe von Verzeichnissen und Nachschlagewerken, wie zum Beispiel Methodenreferenzen, Werkzeugreferenzen, Glossar, Abkürzungsverzeichnis und Literaturangaben.
• Vorlagen: Beinhaltet Vorlagen für die einzelnen Produkte in Form von RTF-Dokumenten. Diese Vorlagen können im Rahmen eines Projektes direkt eingesetzt oder gegebenenfalls zuvor angepasst und dann eingesetzt werden.

Extrem Tailoring steht für projektspezifische Anpassung des V-Modells. Das Tailoring beschränkt sich auf:

• die Auswahl eines Projekttyps und in Anschluss
• der Auswahl einer der möglichen Projekttypvarianten und
• der Belegung mit Werten der dazugehörigen Projektmerkmale

Man unterscheidet dabei zwischen

• Statischen Tailoring: Das Anwendungsprofil wird am Anfang eines Projektes definiert und bleibt während der Projektlaufzeit stabil.
• Dynamisches Tailoring: Bestimmte Projektmerkmale ändern sich während der Projektlaufzeit

z.B. können in einem Projekt, das zunächst auf reine SW-Entwicklung ausgelegt war, im Projektverlauf noch HW-Anteile identifiziert werden. Auch die Abläufe in der Projektdurchführungsstrategie können angepasst werden

Scrum– Artefakte

• Vision (Idee)
• ProductBacklog: Alle noch zu liefernden Funktionalitäten (eine vom ProductOwner nach Geschäftswert geordnete Liste von Produktanforderungen)
• ProductBacklog Item: Die zu liefernden Funktionalitäten, die in einem ProductBacklog aufgelistet sind
• Sprint Goal: Ziel des Sprints (festgelegt von Team und ProductOwner)
• Selected ProductBacklog: Für diesen Sprint ausgewählte Backlog Items (entsteht im Sprint Planning Meeting 1)
• Aufgaben: alles was getan werden muss, um das Ziel des Sprints zu erreichen
• Sprint Backlog: Täglich aktualisierte Liste von offenen Backlog Items des akt. Sprints (entsteht im Sprint Planning Meeting 2)
• Releaseplan: Übersichtsplan (informativ) der Backlog Items und Ihrer zugehörigen Sprints (zeigt, in welchem Sprint welches Backlog Item vom Team geliefert werden kann)
• ImpedimentBacklog: Liste aller Blockaden, die ausgeräumt werden müssen

• Forming: Das Team kommt zusammen und die Mitglieder des Teams kennen sich noch nicht
• Storming: Erste Ideen werden gemeinsam entwickelt und auch die eine oder andere Sackgasse beschritten. Hierbei lernt das Team sich kennen
• Norming: Die ersten Regeln innerhalb des Teams werden vereinbart. Die vom Team übernommen Verantwortung nimmt zu.
• Performing: Das Team beginnt auf einem intuitiven Level miteinander zu arbeiten. Die Fähigkeiten der Teammitglieder werden nun voll genutzt.

• Estimation Meeting
• Sprint Planung, Sprint Goal
  • Spezifisch
  • Messbar
  • Attraktiv
  • Realistisch
  • Termin
• Sprint Planning 2 – Design
• Daily Scrum
  • Was habe ich erreicht?
  • Was will ich erreichen?
  • Was steht mir dabei im Weg?
• Sprint Review

• Benutzeranforderungen: Spezifikationen in natürlicher Sprache und Diagrammen, zur Beschreibung der Funktionen des Softwaresystems und der Rahmenbedingungen in denen es betrieben werden soll
• Systemanforderungen: Funktionen und Einschränkungen detaillierter festgelegt. Hieraus lässt sich z.B. das Pflichtenheft erstellen
• Spezifikation des Softwareentwurfs: Abstrakte Beschreibung des Softwareentwurfs. Grundlage für exakten Entwurf, mit Details für Spezifikation des Softwareentwurfs.

Beispiele:

• Benutzeranforderung: Die Software muss über Mittel zur Darstellung externer, von anderen Werkzeugen erzeugten Dateien verfügen und auf sie zugreifen können
• Systemanforderungen:
  • Benutzer sollte über Möglichkeiten zur Definition externer Datentypen verfügen
  • Jeder externe Datentyp kann eine damit verknüpfte Anwendung besitzen, mit der die Datei bearbeitet wird
  • Jeder externe Dateityp kann als best. Symbol auf dem Bildschirm des Anwenders dargestellt werden

Funktionale Anforderungen sind Anforderungen, die sich direkt auf die Funktion(en) des Systems beziehen.

Beispiele:

• Der Benutzer soll die gesamte anfängliche Menge der Datenbank durchsuchen oder eine Teilmenge davon auswählen können
• Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentenspeicher lesen kann
• Jeder Bestellung soll ein eindeutiger Bezeichner zugeordnet werden und der Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren können

• Produktanforderungen: Anforderungen an das Verhalten des Produkts (z.B. Leistungsanforderungen, Zuverlässigkeitsanforderungen usw.)
• Unternehmensanforderungen: Anforderungen aus dem Unternehmen heraus an das Produkt (z.B. Vorschriften für die Entwicklung, Entwurfsmethode, Anforderungen an Doku)
• Externe Anforderungen: Alle Anforderungen außerhalb des Systems und des Entwicklungsprozesses (z.B. Kompatibilitätsanforderungen, gesetzliche Anforderungen)

Beispiele:

• Produktanforderungen: Es soll möglich sein, dass die gesamte nötige Kommunikation zwischen den Applikationen und dem Benutzer durch den ADA-Standardzeichensatz ausgedrückt wird
• Unternehmensanforderungen: Der Systementwicklungsprozess und lieferbare Dokumente sollen dem Vorgehen und den Ergebnissen entsprechen, die in XYSCo-SP-STAN-95 definiert sind
• Externe Anforderungen: Das System soll den Benutzer des Systems keine persönlichen Informationen über den Kunden preisgeben, abgesehen vom Namen und der Referenznummer

In Alltagssprache formulierte Systemanforderungen

Beispiele:

• Als Betreiber der Software möchte ich jedem Besucher Werbung einblenden, um Geld zu verdienen
• Als Datenschutzbeauftragter möchte ich, dass die gespeicherten Daten anonymisiert werden
• Als Admin möchte ich, dass die IP-Adressen vor der Speicherung anonymisiert werden, um den Anforderungen des Datenschutzbeauftragen gerecht zu werden

• Name und Identifier: Eindeutiger Name und Identifikationsnummer
• Beschreibung: Kurze Beschreibung, was im Case passiert, 2-3 Zeilen
• Beteiligte Akteure: Beteiligte Personen oder Systeme, z.B. Anwender, Kunde, System etc.
• Status: Status der Bearbeitung des Use Case, in Arbeit / bereit zum Review / im Review / abgelehnt / abgenommen
• Verwendete Use Case: Greift der Case Use auf andere Case Use zurück werden diese hier aufgeführt
• Auslöser: Fachlicher Grund dafür, das dieser Use Case ausgeführt wird
• Vorbedingungen: Bedingungen, die vor der Ausführung diese Cases erfüllt sein müssen
• Nachbedingungen / Ergebnis: Zustand, der nach einem erfolgreichen Durchlauf des Use Case erwartet wird
• Invarianten: Bedingungen, innerhalb und durch den Use Case nicht verändert werden dürfen
• Standardablauf: Typisches Szenario. Am Ende steht das Ziel des Use Case durch den Akteur. Nummerierung der Schritte. Beschreibung in strukturierter Sprache. Bei UML: Aktivitätsdiagramme oder Sequenzdiagrammen
• Alternativer Ablauf: Szenarien außerhalb des Standardablaufs. Am Ende steht Misserfolg, Zielerreichung des Akteurs oder Rückkehr zum Standardablauf
• Hinweis: Kurze Erklärungen zum besseren Verständnis. Hinweise zu Nebeneffekten, etc.
• Änderungsgeschichte: Versionierung, Name des Autors, Datum

• Gültigkeitsprüfung: Sind alle Funktionen enthalten? Haben sich aus den Anforderungen heraus neue Funktionen ergeben? Sind einzelne Anforderungen zu streichen, weil sie nicht von genügend Nutzern benötigt werden?
• Konsistenzprüfung: Sind die Anforderungen im Dokument Widerspruchsfrei?
• Vollständigkeitsprüfung: Sind alle durch den Systembenutzer erwarteten Funktionen und Einschränkungen im Anforderungsdokument enthalten?
• Realisierbarkeitsprüfung: Ist das Zielsystem mit der aktuellen Technologie innerhalb der Budget- und Zeiteinschränkungen realisierbar?
• Verifizierbarkeitsprüfung: Sind die Anforderungen aus dem (Vertrags-) Dokument konkret verifizierbar im Zielsystem?

• Anforderung-Review: Team von Gutachtern analysieren systematisch die Anforderungen
• Prototypen: Der Endbenutzer/Kunde überprüft die geforderten Anforderungen an einem funktionsfähigen Prototyp.
• Testfallerzeugung: Für die Überprüfung der Anforderungen im Zielsystem wird ein Testfall erarbeitet, um die korrekte Umsetzung zu überprüfen
• Automatische Konsistenzprüfung: Werden die Anforderungen in einer formalen Notation ausgedrückt, so können sie mittels CASE-Werkzeugen automatisch auf Konsistenz geprüft werden.

• Verifizierbarkeit: Ist die Anforderung überprüfbar?
• Verständlichkeit: Wurde die Anforderung richtig verstanden bei der Beschreibung durch den Endbenutzer / Kunden?
• Nachvollziehbarkeit: Ist der Ursprung einer Anforderung und die auf sie aufbauenden Anforderungen klar erkennbar? Wichtig für die Abschätzung von Folgen einer Änderung.
• Anpassungsfähigkeit: Kann die Anforderung ohne große Auswirkungen auf neue Systemanforderungen hin geändert werden?

• Anforderungsidentifikation: Eindeutige Identifikation der betroffenen Anwendung
• Ablauf des Änderungsmanagements: Aufgaben und Auswirkungen (Kosten / Zeitplanänderungen etc.), die sich aus der Änderung ergeben
• Richtlinien zur Nachvollziehbarkeit: Definieren Verbindungen zwischen Anforderungen untereinander und zwischen Anforderungen und dem Systementwurf
• Unterstützung durch CASE-Werkzeuge: Im Anforderungsmanagement treten große Informationsmengen auf, diese können mit verschiedenen Werkzeugen verwaltet werden. Von speziellen Systemen, bis hin zum einfachen Texteditor / Tabellenkalkulationsprogramm

Management für Anforderungsänderungen