Projektmanagement

Projektmanagement
Vorlesung von Thomas Patzelt
5. Vorlesung
1
Arbeit vor dem Lastenheft - Prototypen
• Keine Ahnung ob die Kunden Ihr Produkt lieben? Wir bauen Ihnen einen
Prototypen!
• Mock-Up, Beta-Version, 3D-Drucker, Zeichnungen, Bilder, Storyboard
• Tests mit Kunden, „Focus-Groups“, „Hallway-Testing“, Usability-Labs
• Je näher am Endprodukt, desto sicherer die Aussage, aber...
• „Watch customer‘s feet, not customer‘s mouth“: Es ist nicht wichtig, was die
Leute sagen (d.h. behaupten zu kaufen), sondern was sie Kaufen
2
Arbeit vor dem Lastenheft - Durchführbarkeit
• Überprüfen Sie ob Ihr Projekt wirklich durchführbar sein wird
• Hat es das richtige Timing? Ist es zu früh, oder zu spät?
• Gibt es genügend treibende Kräfte, genügend Unterstützung?
• Gibt es zu viele hemmende Kräfte, oder Widerstände?
3
Wie kommen wir zum Lastenheft?
• Wir beschreiben das, Produkt in seinen Eigenschaften und die Produktidee
• Aber welche Eigenschaften sind wichtig und was ist die Produktidee?
• Beschreiben Sie Ihre neue Erfindung, den „Radiergummi“
• Beschreiben Sie Ihre neue Erfindung, den „MP3-Player“
• Beschreiben Sie Ihre neue Erfindung, den „Brieftauben-Dienst zum Austausch
von Aktiendaten zwischen Aachen und Brüssel“
• Beschreiben Sie Ihre neuen Produkte „Würzmischung für Ameisenlarven“ und
„Hörbücher für Gehörlose“
4
Die Erfindung / Definitionsphase eines Produktes
• Von der Idee zum Produkt: Die Erfinderin hat die Idee für das Produkt, stellt
es her und verkauft es
• Beispiele: Walkman, Kaffeefilter
• Vom Produkt zum Produkt:
• Beispiele: MP3-Player & CD-Porty
• Von beidem ein bisschen:
• Fisherman‘s Friend, Kopierer, Java-Programmiersprache
5
Requirements Engineering
• Professionelles Sammeln der Anforderungen hat sich in den letzten Jahren als
eigener Arbeitsschritt entwickelt. Das Requirements Engineering wird oftmals
in einer eigenen Abteilung erbracht
• Für das gute Sammeln von Anforderungen kennt das Requirements
Engineering wiederum seine eigenen Anforderungen
• Besonders in sicherheitsrelevanten Bereichen ist die Professionalisierung der
Anforderungserstellung weit fortgeschritten
6
R-E: Qualitäts-Kriterien für gute Anforderungen
• vollständig – alle Anforderungen des Kunden müssen
explizit beschrieben sein, es darf keine impliziten
Annahmen des Kunden über das zu entwickelnde
System geben.
• eindeutig definiert / abgegrenzt – präzise Definitionen
helfen, Missverständnisse zwischen Entwickler und
Auftraggeber zu vermeiden.
• verständlich beschrieben – damit sowohl der
Auftraggeber als auch der Entwickler mit vertretbarem
Aufwand die gesamten Anforderungen lesen und
verstehen kann.
• einheitlich dokumentiert – die Anforderungen und ihre
Quellen sollten nicht in unterschiedlichen Dokumenten
stehen oder unterschiedliche Strukturen haben.
• notwendig – gesetzliche Vorschriften sind
unabdingbar.
• nachprüfbar – die Anforderungen sollten mit
Abnahmekriterien verknüpft werden, damit bei der
Abnahme geprüft werden kann, ob die Anforderungen
erfüllt wurden. Testfälle werden aus den
Abnahmekriterien abgeleitet.
• atomar – es darf nur eine Anforderung pro Abschnitt
oder Satz beschrieben sein. Das Kriterium für ein
„Atom“ sollte die Entscheidbarkeit einer Anforderung
sein.
• rück- und vorwärtsverfolgbar – damit einerseits
erkennbar ist, ob jede Anforderung vollständig erfüllt
wurde und andererseits für jede implementierte
Funktionalität erkennbar ist, aus welcher Anforderung
sie resultiert, also nicht Überflüssiges entwickelt wird.
• identifizierbar – jede Anforderung muss eindeutig
identifizierbar sein (z. B. über eine Kennung oder
Nummer).
• Konsistenz – Konsistenz beschreibt den Grad, in dem
die definierten Anforderungen untereinander
widerspruchsfrei sind.
7
Was lernen wir daraus für das Lastenheft?
• Die Beschreibung des Problem, welches mit dem Produkt gelöst werden soll, gehört
in das Lastenheft
• Ein Produkt, welches kein Problem löst, hat es schwer: a) beschrieben zu werden und
b) verkauft zu werden
• Eigentlich jedes Produkt löst irgend ein Problem irgend eines Kunden
• Die Beschreibung des Kunden, des Marktes und der Konkurrenz kann auch für das
Lastenheft wichtig sein
• „Ein Getränk, das nur Bio-Inhaltsstoffe hat, das genauso schmeckt wie <Ihre
farbige Lieblingsbrause>, nur ohne Farbe, das Eltern ihren Kindern geben sollen“
• „Ein Telefon mit großen Tasten für über 80-jährige Radfahrer“
8
Sprache im Lastenheft
• Warum das Wort Problem nicht verwenden?
• Problem klingt so negativ. Wer will schon Probleme haben?
• Manche Lösungen lösen weniger oder mehr als ein Problem, die Lösung zu beschreiben
klingt oft schöner: Würzmittel, Walkman, Sportwagen, PC-Spiel
• Daher hat es sich durchgesetzt, die Lösungen, den Nutzen, den „Mehrwert“ zu
beschreiben und nicht die Probleme
• „Fischerman‘s Friend“: „Halsweh?“ vs. „Sind sie zu stark, ...“
• TIPP: Konjunktiv nur verwenden, wenn optionale Features beschrieben werden, sonst
entstehen leicht Missverständnisse
• Beispiel mandatory: Die Hintergrundfarbe ist rot. Optional: Man könnte die Farbe ändern.
9
Lastenheft
• Anforderungsliste, Anforderungsspezifikation: Requirements Specification
• Listet alle Anforderungen („Lasten“, „Requirements“) als eigene Punkte auf
• Ist aus der Sicht des Kunden geschrieben
• Nimmt (oft) keine Rücksicht auf Realisierbarkeit oder Kosten
• Ein gutes Lastenheft nennt auch alle „impliziten“ Anforderungen
• Beispiel: Der verwendete Speicher wird wieder frei gegeben
• Ist noch kein Entwicklungsvertrag
10
Was schreiben wir als Lastenheft?
• Format egal (Word, Powerpoint, Excel)
• Beschreibung des Applikationsverhalten im Detail:
• Start
• Verhalten der verschiedenen Bildschirme
• Verhalten der Applikation „im Hintergrund“ und z.B. über das Netzwerk
• Stoppen der Applikation
• Beschreibungen des Verhaltens, NICHT der Implementierung
11
Folien aus der Übung
12
Beispiele Lastenheft
• Applikation lädt innerhalb von 2 Sekunden nach Start ein Bild (Splash-Screen)
• Applikation unterstützt mehrere Darstellungen der Messwerte in
• Monatsansicht mit 28-31 Werten in Balkendarstellung
• Tagesansicht mit 24 Werten in Liniendarstellung
• Die Werte sind in blau (Farbwert 0xffff99) anzuzeigen
• Auf eintreffende Kommunikationsvorschläge wird dem Nutzer die Wahl überlassen ob
er die Kommunikation annimmt
• Zu einschränkend (manchmal gewollt): „Es erscheint ein modaler Dialog, der dem
Nutzer die Wahl anbietet, die Kommunikation anzunehmen“
13
Was ist besser, mehr oder weniger ins Lastenheft?
• Vorteile von „mehr“:
• Der Kunde wird auf mehr Ideen gebracht - man verdient mehr
• Das Produkt hat am Ende mehr Features - mehr Kunden freuen sich
• Mehr Features kann heissen, man hat mehr Chancen auf Glückstreffer
• Nachteile von „mehr“:
• Der Kunde wird auf mehr Ideen gebracht - man hat mehr Arbeit, bei gleichem Verdienst
• Das Produkt hat am Ende mehr Features - und ist weniger fokussiert und komplizierter
• Wenn das Produkt sowieso nicht erfolgreich wird, wäre weniger Arbeit besser gewesen
14
Nach dem Lastenheft ist vor dem Lastenheft
• Das Lastenheft könnte schon bald veraltet sein, denn die Produkt-Anforderungen können
sich ändern. Daher ist es oft sinnvoll, das Lastenheft immer wieder an den neuesten Stand
des Projektes anzupassen - der Kunde ändert sozusagen seine Meinung
• Dazu sollte Ihr Lastenheft die folgenden Dokumenteigenschaften haben:
• Versionsnummer auf jeder Seite, mindestens aber auf der Titelseite
• Datum - aktuelles Datum (wichtig bei einem Ausdruck) oder noch besser Datum der
letzten Änderung
• Seiten-Nummer auf jeder der Seiten - ist bei unterschriebenen Dokumenten wichtig oft wird sogar jede Seite paraphiert
• Wenn das Lastenheft von Ihrem Auftraggeber kommt und diese Informationen nicht
enthält, so fügen Sie diese im Dateinamen an oder schreiben sie auf die erste Seite
15