Der Beitrag Requirements Engineering und Management (Vorlesung 9-17) erschien zuerst auf Maximilian Krieg.

Qualitätssicherung

Wie kann man Fehler vermeiden?

• Fehler im Programmcode sollten zu einer bestimmten Zeit nicht mehr bearbeitet werden
• Dies steht in Abhängigkeit zum menschlichen Tagesrhythmus (vgl. Abbildung 1)
• Beachtet man dies nicht, steigt die Error Reinjection Rate (ERR)

Was ist die Error Reinjection Rate (ERR)?

• Es handelt sich dabei um das Verhältnis zwischen behobenen Fehlern bei einem Fix und den dabei neu entstehenden Fehlern
• Dies schließt auch die Wiedereinführung bereits behobener Fehler ein
• Die ERR steigt mit dem Alter eines Produkts (neue Mitglieder im Team, komplexer Code und Abhängigkeiten)
• Ab einem gewissen Punkt sollte man die Software von Grund auf neu überarbeiten

Wie kann man Fehler finden?

• In einem iterativem Modell nur über Prototypen und Integrations- und Interaktionstests während der Entwicklung
• Die Agile Entwicklung ermöglicht früheres Testen der Anwendung
• Ein probates Mittel sind Inspektionen und Reviews
• Walkthroughs haben eine schlechte Fehlererkennungsrate, da sie stark vom zeitlichen Aufwand abhängig sind
• In der Praxis kann man 40 Zeilen Programmcode oder 5 Seiten normalen Text pro Stunde prüfen
• Jedoch hat man maximal 2 Stunden Konzentration am Stück verfügbar
• Steht zu wenig Zeit zur Verfügung, kann man sich nicht ausreichend einlesen und den Text lesen
• Wird zu viel Zeit aufgewendet, sinkt die Konzentration (vgl. Abbildung 2)

Der Beitrag Requirements Engineering und Management (Vorlesung 8) erschien zuerst auf Maximilian Krieg.

Der Beitrag Requirements Engineering und Management (Vorlesung 5-7) erschien zuerst auf Maximilian Krieg.

Erfolgsfaktoren

Welche Probleme können bei der agilen Entwicklung auftreten?

• Zu viele Stakeholder
• Parallele Entwicklung/benötigte Unschärfe innen, aber harte Definition für Schnittstellen

Wie kann man den Problemen entgegen wirken?

• Das Projekt unterteilen bzw. nur kleinere Projekte machen
• Richtige Reihenfolge für Prozessphasen und Komponenten definieren
• Stets einen Gesamtüberblick halten
• Product Backlog generieren

Was ist das Product Backlog?

• Geordnete Liste von Anforderungen an ein Produkt
• Kann Features, Fixes und nichtfunktionale Anforderungen enthalten

Wofür braucht man ein gutes Portfolio-Management?

• Hierunter ist nicht das Portfoliomanagement aus dem Finanzbereich gemeint
• Im Kontext der Vorlesung ist damit eine Einordnung eines Projekts in Vorwissen und Zerlegbarkeit gemeint
• Wenn wenig Vorwissen vorhanden ist, lieber kleine und einfache Projekte machen

Sammlung der Anforderungen

Szenarien

• Positives Szenario: Ein Verhalten, das das System besitzen sollte
• Negatives Szenario: Ein Verhalten, das das System verhindern sollte

Stakeholder

• Weiß meist nicht und kann noch nicht korrekt ausdrücken was er will
• Mit ihm ist eine enge Zusammenarbeit und ggf. Schulung notwendig
• Nur die Stakeholder, welche auch Entscheidungskraft haben, sollten Einfluss haben und entscheiden dürfen
• Einen wichtigen Stakeholder zu vergessen kann starke Probleme zum Projektende hin erzeugen
• Nur einen Ansprechpartner zu haben (Person X weiß alles was, was du wissen musst) ist gefährlich

Der Beitrag Requirements Engineering und Management (Vorlesung 4) erschien zuerst auf Maximilian Krieg.

Der Beitrag Requirements Engineering und Management (Vorlesung 2-3) erschien zuerst auf Maximilian Krieg.

Einleitung

Grundlagen

• Requirements Engineering (RE) und Software-Entwicklung sind nicht trennbar
• RE ist eine Schlüsseltechnologie, um teure Fehler zu vermeiden
• Viele Anforderungen können erst bei Vorhandensein eines Modells behandelt und identifiziert werden
• In der ersten Iteration kann nicht alles vollständig spezifiziert werden
• Es ist wichtig eine RE-Dokument, wie einen Master-Plan, zu entwickeln
• Mit jeder Iteration kann dann präzisiert werden
• Das Vorgehensmodell muss zum Projekt passen (rein agile Software-Entwicklung geht nicht)
• Die Umgebung entspricht Domänenwissen und darf nicht vernachlässigt werden
• RE ist ein oftmals erforderlicher Prozess zur Projektvergabe (ohne nicht bekommen)

Was ist Domänenwissen?

• Spezielles Wissen rund um ein Themengebiet
• Erfordert das Einarbeiten in das Aufgabengebiet, wie Steuern oder Finanzwesen

Beispiel: Große gescheiterte Projekte

• Flughafen Berlin

Was sind Randbedingungen und Einschränkungen?

• Gesetzliche, soziale, ökonomische, technische, kulturelle Bestimmungen und Regeln
• Diese zu ignorieren wird teuer (RE-Fehler sind am teuersten)

Wie kann man das beste system-to-be identifizieren?

• Unter Zuhilfenahme verschiedener Prototypen (entwickeln) und die beste Lösungen rauspicken

Wie ist die allgemeine Methodik zur Findung von Lösungswegen?

1. Erste Idee aufstellen
2. Kreativitätsmethoden (bspw. Brainstorming) anwenden und Ideenraum vergrößern
3. Ideenraum dann einschränken (mithilfe von Randbedingungen oder anderen Anforderungen)
4. Entscheidung treffen

Wie hängt RE mit dem Software Lebenszyklus zusammen?

• Erst das Ziel definieren
• Dann definieren wie das Ziel zu erreichen ist

Warum ist RE schwierig?

• Es gibt keinen Compiler oder automatisiertes System zur Lösungsfindung
• Viel Kopfarbeit mit Kreativität notwendig
• Jedes Projekt ist anders
• Viel fehlendes Wissen bei anderen bzw. kaum jemand beherrscht es wirklich gut
• Es gibt verschiedene Stakeholder-Gruppen, die verschiedene Interessen haben können, auch innerhalb der Gruppen
• RE kann nicht nur einmal durchgeführt werden, sondern muss zyklisch wiederholt werden
• Den Punkt finden an dem man ein valides Modell hat und mit Implementierung beginnen kann
• Beispiele für Konfliktmanagement: Interessen von Gesetzgebern VS Motorherstellern sowie Sicherheit VS Kosten
• Risikomanagement: Was kann eintreten und was sind die Folgen?

Welche Szenarien gibt es?

• Positives Szenario: Das muss gehen
• Negatives Szenario: Das darf nicht eintreten

Was sind WER Dimensionen?

• Diese Dimension definiert die verantwortlichen Personen

Was sind Annahmen?

• Sie stellen die Verbindung zwischen Lösung und Anwender her
• Sie basieren auf Vermutungen
• Falsche annahmen führen zu erheblichen RE-Fehlern

Der Beitrag Requirements Engineering und Management (Vorlesung 1) erschien zuerst auf Maximilian Krieg.