Hey, wir haben das Pflichtenheft komplett! - Datenbank- und ...
Hey, wir haben das Pflichtenheft komplett! - Datenbank- und ...
Hey, wir haben das Pflichtenheft komplett! - Datenbank- und ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Hey</strong>, <strong>wir</strong> <strong>haben</strong> <strong>das</strong><br />
<strong>Pflichtenheft</strong><br />
<strong>komplett</strong>!<br />
Cool!<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
Endlich!<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 1
Und die letzten Teile<br />
gingen doch recht flott,<br />
besonders die Use Cases<br />
waren kinderleicht.<br />
Stimmt, die meisten<br />
von den Strichmännchen<br />
hat<br />
tatsächlich Mikes<br />
Sohn da reingemalt<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 2<br />
????
Haben <strong>wir</strong> da nicht<br />
was vergessen?<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 3
Zielbestimmung<br />
Modell des Problembereichs<br />
Geschäftsprozesse<br />
Produktfunktionen<br />
Produktcharakteristiken<br />
Wir <strong>haben</strong> alles!<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 4
Figuren © Christopher B. Wright, ubersoft.net<br />
Und die<br />
Qualität?<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 5
Wo sollen <strong>wir</strong> die denn noch<br />
hinschreiben?<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 6<br />
uh-oh
Software-Entwurf<br />
Software Entwurf<br />
Kapitel II: Das <strong>Pflichtenheft</strong><br />
Abschnitt II.5: Qualität des<br />
<strong>Pflichtenheft</strong>es<br />
Prof. Dr. Gregor Engels<br />
AG <strong>Datenbank</strong>- <strong>und</strong><br />
Informationssysteme
Über <strong>das</strong> Scheitern von IT-Projekten<br />
IT Projekte sind modern, toll, teuer <strong>und</strong> zum Scheitern<br />
verurteilt!<br />
Standish Group<br />
Research:<br />
CHAOS Report<br />
Untersuchung an<br />
>30.000 IT Projekten<br />
in den USA<br />
Quelle: The Standish Group: Extreme Chaos, 2001<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 8
Und warum ist <strong>das</strong> so?<br />
Antworten auf die Frage: Warum ist ihr Projekt gescheitert?<br />
1. Incomplete Requirements<br />
2. Lack of User Involvement<br />
3. Lack of Resources<br />
4. Unrealistic Expectations<br />
5. Lack of Executive Support<br />
7. Lack of Planning<br />
8. Didn't Need It Any Longer<br />
9. Lack of IT Management<br />
10. Technology Illiteracy<br />
Other<br />
Über <strong>das</strong> Scheitern von IT-Projekten<br />
Project Impaired Factors<br />
6. Changing Requirements & Specifications<br />
% of Responses<br />
13.1%<br />
12.4%<br />
10.6%<br />
9.9%<br />
9.3%<br />
8.7%<br />
8.1%<br />
7.5%<br />
6.2%<br />
4.3%<br />
9.9%<br />
Quelle: The Standish Group: The CHAOS Report, 1994<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 9
Und warum ist <strong>das</strong> so?<br />
Antworten auf die Frage: Warum ist ihr Projekt gescheitert?<br />
1. Incomplete Requirements<br />
2. Lack of User Involvement<br />
3. Lack of Resources<br />
4. Unrealistic Expectations<br />
5. Lack of Executive Support<br />
6. Changing Requirements & Specifications<br />
7. Lack of Planning<br />
8. Didn't Need It Any Longer<br />
9. Lack of IT Management<br />
Über <strong>das</strong> Scheitern von IT-Projekten<br />
Project Impaired Factors<br />
% of Responses<br />
13.1%<br />
12.4%<br />
10.6%<br />
Das <strong>Pflichtenheft</strong> ist <strong>das</strong> F<strong>und</strong>ament jedes IT-Projektes.<br />
10. Technology Illiteracy<br />
4.3%<br />
Man sollte sicher sein, <strong>das</strong>s dieses F<strong>und</strong>ament tragfähig ist,<br />
Other<br />
9.9%<br />
bevor man weiterbaut!<br />
9.9%<br />
9.3%<br />
8.7%<br />
8.1%<br />
7.5%<br />
6.2%<br />
Quelle: The Standish Group: The CHAOS Report, 1994<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 10
0,1-0,2<br />
0,5<br />
1<br />
2-4<br />
20<br />
Anpassungen:<br />
Jetzt oder später?<br />
Anforderungsdefinition<br />
Relative Kosten einer Fehlerkorrektur<br />
Entwurf<br />
Implementierung<br />
[nach A.M. Davis, Software Requirements: Objects, Functions, and States. Prentice Hall, 1993.]<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 11<br />
Test<br />
Wartung
Was ist denn genau die<br />
Qualität des <strong>Pflichtenheft</strong>s?<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
Dafür gibt<br />
es einen<br />
Standard!<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 12
IEEE Std. 830-1998:<br />
IEEE Recommended Practice for<br />
Software Requirements Specifications<br />
Qualität des <strong>Pflichtenheft</strong>s- IEEE 830<br />
http://kybele.escet.urjc.es/Documentos/ISI/IEEE-STD-830-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Ranked - Gewichtet (nach Wichtigkeit etc.)<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 13
Wann ist ein <strong>Pflichtenheft</strong> korrekt?<br />
Alle Diagramme/Texte sind syntaktisch korrekt<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Das <strong>Pflichtenheft</strong> stellt die Domäne/Anforderungen korrekt dar (semantisch korrekt)<br />
Specification<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 14
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Syntaktische Korrektheit<br />
Wie stellt man syntaktische Korrektheit der<br />
Diagramme sicher?<br />
Einsatz von Tools (automatisch korrekt – in bestimmten Maßen)<br />
Durchsehen des <strong>Pflichtenheft</strong>es:<br />
Objektdiagramme<br />
Alle Namen unterstrichen?<br />
Beziehungen beschriftet?<br />
Aggregationsbeziehungen sinnvoll verwendet?<br />
Keine Klassendiagrammnotationen verwendet (Vererbung, Kardinalitäten)?<br />
Klassendiagramme<br />
Klassen im Singular benannt?<br />
Assoziationen sinnvoll beschriftet, inkl. Leserichtung?<br />
Aggregationen sinnvoll eingesetzt?<br />
Kardinalitäten konsequent angegeben?<br />
Vererbungen sinnvoll eingesetzt?<br />
Keine zirkulären Vererbungen?<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 15
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Syntaktische Korrektheit<br />
Durchsehen des <strong>Pflichtenheft</strong>s (fortgesetzt)<br />
Aktivitätendiagramme<br />
Pfeilspitzen an allen Pfeilen? (sonst Richtung unklar)<br />
Start-/Endknoten eingefügt?<br />
Komplexe Aktionen verfeinert?<br />
Flow final nur in nebenläufigen Teilen?<br />
Use Case Diagramme<br />
Systemgrenze klar beschriftet?<br />
Richtung der <strong>und</strong> Pfeile korrekt?<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 16
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Semantische Korrektheit<br />
Wie kann man semantische Korrektheit feststellen?<br />
„Even if you can prove that a program satisfies a mathematical<br />
specification, there is no way to prove that the mathematical specification<br />
meets the real requirements of the system.”<br />
(Martin Fowler)<br />
Abgleich von Realität <strong>und</strong> <strong>Pflichtenheft</strong> geht nur per Review:<br />
Geschulte Reviewer können mit Fragetechniken Lücken/Probleme aufdecken<br />
Domainexperten können die modellierten Informationen überprüfen<br />
Anwender können feststellen, ob ihre Bedürfnisse berücksichtigt wurden (ev. mit<br />
einem Prototyp)<br />
Allgemein wichtig: Mit anderen drüber reden!<br />
Man sieht die eigenen Fehler/Annahmen nicht<br />
Unterschiedliche Interpretationen helfen, Mehrdeutigkeiten <strong>und</strong> Lücken zu<br />
erkennen<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 17
K<strong>und</strong>e<br />
Adresse:Adresse<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Klassendiagramm-Review<br />
Adresse<br />
Entweder Attribut oder Assoziation, nicht beides!<br />
Achtung: Diese <strong>und</strong> die folgenden Folien zeigen teilweise Beispiele<br />
für schlechtes Klassendesign!<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 18<br />
1
Person<br />
K<strong>und</strong>e<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Klassendiagramm-Review<br />
Adresse<br />
Vererbte Assoziationen oder Attribute nicht wiederholen<br />
(es sei denn, diese sind zusätzlich)<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 19<br />
1<br />
1
Position<br />
<strong>wir</strong>d bestellt in <br />
Verfallsdatum<br />
1<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Klassendiagramm-Review<br />
Medikament<br />
Name:String<br />
Gewicht:Dezimal<br />
Darreichungsform<br />
Lagerfach<br />
Spinnenklassen (viele Verbindungen <strong>und</strong> Attribute):<br />
Möglicherweise Überladung mehrerer Konzepte! (Homonyme nicht<br />
aufgelöst?). Teilen?<br />
Hier: Medikamentensorte <strong>und</strong> Medikament.<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 20<br />
1<br />
1<br />
enthält
Spiegelklassen:<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Klassendiagramm-Review<br />
Lagersegment Lagerfeld<br />
Synonyme nicht erkannt -> integrieren<br />
26<br />
1..4<br />
Karussellager<br />
Lagerfach<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 21<br />
1..4<br />
26
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Klassendiagramm-Review<br />
Auftrag<br />
Auftragsnummer:int<br />
Entsorgungsauftrag<br />
Geisterklassen (Klassen ohne Eigenschaften):<br />
Empfänger<br />
Können irrelevante Konzepte darstellen, können aber auch wichtige<br />
Strukturierungen sein. Beim Modellierer nachfragen!<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 22
Vererbung prüfen:<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Klassendiagramm-Review<br />
Lagerfeld<br />
zulässiges Gewicht: dezimal<br />
Lagerfach<br />
Die vererbte Klasse soll eine Spezialisierung der Oberklasse<br />
darstellen. Vererbung soll nicht eingesetzt werden, nur um<br />
Eigenschaften zu kopieren!<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 23
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Modell des Problembereichs<br />
Beschreibt <strong>das</strong> Modell des Problembereichs <strong>wir</strong>klich den<br />
Problembereich oder bereits Datenstrukturen zu seiner<br />
Repräsentation im System ?<br />
Gegenbeispiel: Kommissioniervorgang<br />
LoslisteKarussell1 : Array<br />
LoslisteKarussell2 : Array<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 24
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Zielbestimmung<br />
Stehen in der Zielbestimmung <strong>wir</strong>klich Ziele, die allein<br />
durch die in diesem Projekt zu entwickelnde Software zu<br />
erreichen sind ?<br />
Gegenbeispiel:<br />
Mit der Umstellung des Medikamentenlagers auf <strong>das</strong><br />
horizontale Karusselllager soll es möglich sein,<br />
Aufträge mit weniger Personal schneller zu bearbeiten.<br />
Ziel der Einführung des Karusselllagers, nicht<br />
der Entwicklung der Lagerverwaltungssoftware<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 25
Nimmt eine Produktfunktion keine<br />
Entwurfsentscheidungen vorweg ?<br />
Gegenbeispiel:<br />
Name:<br />
Beschreibung:<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Produktfunktionen<br />
Beschränkte Benutzung<br />
Der Lagerist muss sich über die<br />
Eingabe eines Passwortes<br />
identifizieren.<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 26
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Produktfunktionen<br />
Wird <strong>das</strong> Ziel jedes Use Cases von irgendeinem<br />
Nutzer tatsächlich als erwünscht angesehen ?<br />
Gegenbeispiel:<br />
Name des Use Cases:<br />
Ziel des Use Cases:<br />
Lagerfachoptimierung<br />
Eingelagerte Waren<br />
einer Charge sollen so<br />
dicht wie möglich<br />
beieinander lagern.<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 27
Review mit Domainexperten<br />
Ware<br />
Hat jeder Medikamententyp ein Verfallsdatum?<br />
Kann ein Lagerfach nur eine Ware enthalten?<br />
Ist die Darreichungsform im Medicode erkennbar?<br />
Bestellen die Stationen Waren einer bestimmten Charge?<br />
1..*<br />
Charge<br />
Verfallsdatum:Datum<br />
Chargennummer:Int<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Review mit Domainexperten<br />
Lagerfach<br />
Darreichungsform<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 28<br />
0..1<br />
1..*<br />
enthält <br />
1<br />
1<br />
Medikamententyp<br />
Name:String<br />
Medicode:Int<br />
Gewicht:Decimal<br />
1
Suchen nach (relevanten) Spezialfällen:<br />
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Review mit Domainexperten<br />
Die Zahl der Passagiere auf einem Flug bleibt konstant!<br />
„Wenn aber nun einer mit dem Fallschirm abspringt?“<br />
Die Zahl der Passagiere auf einem Flug ist konstant oder fallend!<br />
„Wenn aber nun eine Schwangere ein Baby an Bord bekommt?“<br />
Die Zahl der Passagiere auf einem Flug ist variabel zwischen Start <strong>und</strong><br />
Landung!<br />
Das Suchen nach Spezialfällen sollte sich auf relevante Situationen<br />
beschränken!<br />
z.B.: Krücken <strong>haben</strong> kein Verfallsdatum, werden aber auch im Lager<br />
verwaltet<br />
Im Glossar gut dokumentieren<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 29
Korrektheit des <strong>Pflichtenheft</strong>s<br />
Review mit Anwendern/Nutzern<br />
(nur) Anforderungen beschrieben, die auch Bedürfnissen<br />
der Nutzer entsprechen?<br />
nicht korrekte Anforderungen führen zu Funktionalität,<br />
die keiner braucht!<br />
fehlende Akzeptanz durch den Nutzer<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 30
IEEE Std. 830-1998:<br />
IEEE Recommended Practice for<br />
Software Requirements Specifications<br />
Qualität des <strong>Pflichtenheft</strong>s- IEEE 830<br />
http://kybele.escet.urjc.es/Documentos/ISI/IEEE-STD-830-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 31
Vollständigkeit des <strong>Pflichtenheft</strong>es<br />
Wie stelle ich fest, ob <strong>das</strong> <strong>Pflichtenheft</strong> vollständig ist?<br />
In den Texten: auf Ungenauigkeiten achten (verstecken häufig<br />
Lücken)<br />
„ungefähr“, „meistens“, „häufig“, „normalerweise“<br />
Was ist in den anderen Fällen?<br />
In Klassendiagrammen:<br />
Ergeben zwei relevant unterschiedliche Situationen zwei<br />
unterschiedliche Objektdiagramme?<br />
Kann ich 0..* Kardinalitäten genauer fassen?<br />
In Aktivitätendiagrammen:<br />
Sind alle möglichen Abläufe abgebildet? Insbesondere „im Prinzip<br />
könnte man <strong>das</strong> auch so…“ vs. „Wir machen <strong>das</strong> immer so…“<br />
Unabhängige Aktionen durch Nebenläufigkeit entkoppeln<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 32
Vollständigkeit des <strong>Pflichtenheft</strong>es<br />
Produktfunktionen<br />
Wie stelle ich fest, ob <strong>das</strong> <strong>Pflichtenheft</strong> vollständig ist?<br />
Produktfunktionen<br />
Review mit Anwender: Anwendung simulieren (Prototyp oder Mockup)<br />
Da müsste ich doch<br />
jetzt eine Bestätigung<br />
drucken können... Warum kann ich denn<br />
jetzt nicht auf die Liste<br />
zurück?<br />
Kann ich auch eine Übersicht<br />
nach Bestelldatum bekommen?<br />
Woher soll ich denn jetzt<br />
hier den Medicode wissen?<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 33
Name:<br />
Vorbedingung:<br />
Nachbedingung bei erfolgreicher<br />
Ausführung:<br />
...<br />
Name:<br />
Vorbedingung:<br />
...<br />
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels 26<br />
Vollständigkeit des <strong>Pflichtenheft</strong>es<br />
Produktfunktionen<br />
Zusammenhang (Konsistenz)<br />
zwischen Produktfunktionen<br />
Auftrag zur Kommissionierung einstellen<br />
keine<br />
Es existiert ein KV mit diesem Auftrag.<br />
KV durchführen<br />
KV vorhanden <strong>und</strong> zur Bearbeitung<br />
freigegeben<br />
Gibt es zu jeder<br />
Vorbedingung<br />
eine andere<br />
Funktion, die<br />
diese herstellt?<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 34
IEEE Std. 830-1998:<br />
IEEE Recommended Practice for<br />
Software Requirements Specifications<br />
Qualität des <strong>Pflichtenheft</strong>s- IEEE 830<br />
http://kybele.escet.urjc.es/Documentos/ISI/IEEE-STD-830-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 35
Eindeutigkeit des <strong>Pflichtenheft</strong>es<br />
Werden dieselben Begriffe an allen Stellen des <strong>Pflichtenheft</strong>es<br />
verwendet?<br />
Medikamententyp<br />
Name:String<br />
Medicode:Int<br />
Gewicht:Decimal<br />
vs.<br />
Gibt es nur eine Interpretation für Aussagen im PH?<br />
z.B. im Glossar oben: Kann oder muss eine Medikamentsorte einen<br />
Identcode <strong>haben</strong>?<br />
Fehlende Eindeutigkeit führt zu<br />
Glossar:<br />
Software, die nicht dem PH oder den Anforderungen entspricht<br />
Streit zwischen Auftraggeber <strong>und</strong> Auftragnehmer<br />
Medikamentensorte: Eine bestimmte<br />
Packungsgröße <strong>und</strong> Darreichungsform von<br />
einem Medikament bezeichnet man als<br />
Medikamentensorte. Diese kann über einen<br />
Identcode eindeutig bestimmt werden.<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 36
Konsistenz des <strong>Pflichtenheft</strong>es<br />
Widersprechen sich verschiedene Teile des<br />
<strong>Pflichtenheft</strong>es?<br />
Karussell<br />
26<br />
Lagerfeld<br />
Ware entnehmen<br />
Entnahme<br />
bestätigen<br />
vs.<br />
vs.<br />
Glossar:<br />
Karussell: Ein Karussell besteht aus einer<br />
variablen Anzahl von Lagerfeldern.<br />
Glossar:<br />
Entnahme: Bei der Entnahme <strong>wir</strong>d über<br />
einen Gewichtssensor die Menge der<br />
entnommenen Ware bestimmt.<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 37
Konsistenz des <strong>Pflichtenheft</strong>es<br />
Klassen- <strong>und</strong> Objektdiagramme<br />
Sind eventuelle Objektdiagramme konsistent zu den<br />
Klassendiagrammen? (siehe II.2)<br />
Allgemeines Modell:<br />
Klassendiagramm<br />
Auftrag<br />
Auftragsnummer : Dezimal<br />
Bestelldatum : Datum<br />
Einlagerungsauftrag<br />
1<br />
1..*<br />
Position<br />
Instanziierung<br />
Konkretes Modell:<br />
Objektdiagramme<br />
A131:Einlagerungsauftrag<br />
Auftragsnummer = D214V7<br />
Bestelldatum = 3.11.2004<br />
P1:Position P2:Position<br />
Softwareentwurf 2004/05 Universität Paderborn - Gregor Engels 40<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 38
Schri<br />
tt<br />
1<br />
2<br />
3<br />
4<br />
5<br />
6<br />
7<br />
8<br />
Konsistenz des <strong>Pflichtenheft</strong>es<br />
Szenarien <strong>und</strong> Aktivitätendiagramme<br />
Sind die Szenarien im Aktivitätendiagramm enthalten?<br />
Nutzer<br />
Lagerist<br />
DHC<br />
DHC<br />
DHC<br />
Lagerist<br />
Lagerist<br />
Beschreibung der Aktivität<br />
Anzeigen, <strong>das</strong>s 3 Aufträge im KV enthalten sind<br />
3 Kisten auf Packpositionen stellen<br />
DHC in Position 16 drehen<br />
Entnahmemenge 12 für Fach 1 anzeigen<br />
Tür öffnen<br />
12 Packungen aus Fach 1 entnehmen<br />
Entnahme bestätigen<br />
...<br />
[Menge in Fach<br />
ausreichend]<br />
Ware entnehmen<br />
Entnahme<br />
bestätigen<br />
Tür öffnen<br />
Tür schließen<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 39<br />
[Menge in Fach nicht<br />
ausreichend]<br />
Entnehmbare<br />
Menge in V-DHC<br />
eintragen<br />
…
IEEE Std. 830-1998:<br />
IEEE Recommended Practice for<br />
Software Requirements Specifications<br />
Qualität des <strong>Pflichtenheft</strong>s- IEEE 830<br />
http://kybele.escet.urjc.es/Documentos/ISI/IEEE-STD-830-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 40
Überprüfbarkeit des <strong>Pflichtenheft</strong>s<br />
Das <strong>Pflichtenheft</strong> ist ein Vertragsbestandteil!<br />
Alle Angaben/Aussagen sollten so konkret wie möglich <strong>und</strong> ihre<br />
Einhaltung muss überprüfbar sein (Existenz eines endlichen,<br />
machbaren Prozesses, so <strong>das</strong>s eine Person oder Maschine überprüfen<br />
kann, ob Anforderung in Implementierung erfüllt wurde)<br />
Name:<br />
Typ:<br />
Beschreibung:<br />
Optimierte Kommissionierung<br />
EFFIZIENZ<br />
Das Ansteuern des Karussellagers <strong>wir</strong>d zeitlich<br />
optimiert.<br />
Zugeordnete(r)<br />
KV durchführen<br />
Use Case(s) Ungenau <strong>und</strong> nicht überprüfbar! Besser: Das Ansteuern<br />
des Karusselllagers dauert max. 4 Sek pro<br />
Bewegungsvorgang (plus Öffnen der Türen)<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 41
IEEE Std. 830-1998:<br />
IEEE Recommended Practice for<br />
Software Requirements Specifications<br />
Qualität des <strong>Pflichtenheft</strong>s- IEEE 830<br />
http://kybele.escet.urjc.es/Documentos/ISI/IEEE-STD-830-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 42
Änderbarkeit des <strong>Pflichtenheft</strong>s<br />
„The requirements will change whether they’re<br />
allowed to or not.” Edward H. Bersoff<br />
Maßnahmen um <strong>das</strong> <strong>Pflichtenheft</strong> änderbar zu halten:<br />
Klare Struktur, Inhaltsverzeichnis etc.<br />
Querverweise<br />
Red<strong>und</strong>anzfreiheit<br />
-> Nachverfolgbarkeit<br />
nicht änderbare Anforderungen führen zu<br />
nicht mehr benutztem <strong>Pflichtenheft</strong><br />
<strong>Pflichtenheft</strong> von schlechter Qualität<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 43
Nachverfolgbarkeit des <strong>Pflichtenheft</strong>s<br />
Es gibt Beziehungen innerhalb des <strong>Pflichtenheft</strong>s (siehe Konsistenz)<br />
Es sollte Beziehungen zwischen dem PH, der Realität <strong>und</strong> dem<br />
fertigen Produkt geben (sehr wünschenswert!)<br />
Diese Beziehungen sollten nachverfolgbar sein<br />
Welches Quellmaterial liegt einer Anforderung zu Gr<strong>und</strong>e?<br />
Welche andere Elemente des PH hängen mit dieser Anforderung zusammen?<br />
Welche Teile des fertigen Systems realisieren diese Anforderung?<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 44
IEEE Std. 830-1998:<br />
IEEE Recommended Practice for<br />
Software Requirements Specifications<br />
Qualität des <strong>Pflichtenheft</strong>s- IEEE 830<br />
http://kybele.escet.urjc.es/Documentos/ISI/IEEE-STD-830-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 45
Bist du jetzt endlich<br />
zufrieden!?<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
Ja, Danke für<br />
eure Mitarbeit!<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 46
Ich bringe <strong>das</strong> Ding ins Archiv<br />
<strong>und</strong> du fängst schon mal an, zu<br />
programmieren?<br />
Let‘s go!<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
wenn ihr<br />
wüsstet….<br />
Softwareentwurf 2007/08 Universität Paderborn - Gregor Engels 47
Change language