Planung von
Softwareprojekten
Übung, Wintersemester 2014
20. Oktober 2014 – Organisatorisches
Christoph Stollwerk
Gliederung
1. Anforderungskonzept
2. Design /Konzeption
3. Kontrolle / Zeitplanung
4. Evaluation
Anforderungskonzept
Der Chaos Report
• Unvollständige Anforderungen 13.1%
• Kunden nicht ausreichend einbezogen 12.4 %
• Mittel nicht ausreichend 10.6 %
• Unrealistische Erwartungen 9.9 %
• Mangelnde Unterstützung durch Management 9.3 %
• Änderungen in den Anforderungen 8.7 %
• mangelnde Planung 8.1 %
CHAOS Report, Standish Group 1995
Der Chaos Report
Gründe des Scheiterns
nach Forbes/Gartner
Forbes, Gartner, 2004
Anforderungen
Qu
elle
: http
://4.b
p.b
log
sp
ot.c
om
/-rvlk
prI9
BD
0/U
LP
m1
IjIHB
I/AA
AA
AA
AA
CR
8/w
FrG
E1
oIO
hI/s
16
00
/fun
ny-s
cie
nce
-ne
ws-e
xp
erim
en
ts-m
em
es-c
ha
ng
e-is
-ine
vita
ble
.jpg
ANALYSE
Benutzer- und
Systemanforderungen
Anforderungen
ermitteln (Req.)
Anforderungen
formalisieren (specs.)
System modellieren
(modell.)Entwurf
Lastenheft
Pflichtenheft
Forderungen
des “Kunden“
Aufgaben in der Analyse
• Ermittlung
• Formulierung
• Analyse
• Validierung
• OrganisationCHAOS Report, Standish Group 1995
Gute Anforderungen
• Eindeutigkeit
• Vollständigkeit
• Konsistenz
• Korrekt
CHAOS Report, Standish Group 1995
• Verifizierbar
• Priorisierbar
• Variabel
• Identifizierbar
Schlechte Anforderungen
• Gegenteile von guten Anforderungen
• Abgrenzung
• Verzicht
• Schutz (vor ChangeRequests)
CHAOS Report, Standish Group 1995
Schlechte Anforderungen
• Gegenteile von guten Anforderungen
• Abgrenzung
• Verzicht
• Schutz (vor ChangeRequests)
CHAOS Report, Standish Group 1995
ISO 9126/ DIN 66272
• Funktionalität
• Angemessenheit
• Sicherheit
• Genauigkeit der Berechnung
• Interoperabilität
• Konformanz zu Standards
• Benutzbarkeit
• Verständlichkeit
• Erlernbarkeit
• Bedienbarkeit
• Effizienz
• Zeitverhalten
• Verbrauchsverhalten
• Zuverlässigkeit
• Reife
• Fehlertoleranz
• Wiederherstellbarkeit
• Änderbarkeit
• Analysierbarkeit
• Modifizierbarkeit
• Stabilität
• Prüfbarkeit
• Übertragbarkeit
• Anpassbarkeit
• Installierbarkeit
• Konformanz zu Standards
• Austauschbarkeit
"Vorhersagen sind immer
schwierig – vor allem über die
Zukunft."
Anforderungen ermitteln
• Bei Projektstart fast immer eine grobe Vision des zu entwickelnden
Systems (SuD - System under Design) und deren Funktionalität.
• Die Stakeholder entwickeln eine gemeinsame Sprache, um die
Anforderungen zu ermitteln und das Projekt koordinieren zu können.
• User Stories = Kurzgeschichten (z.B. aus Interviews)
• Use Cases (30%)
• Dokumentenanalyse
• Beobachtung
• Prototyping
Anforderungen klassifizieren
• Zusammengehörigkeit und Überlappungen
• z.B. über unterschiedliche Autoren
• Vollständigkeit prüfen
• fehlende Anforderungen erkennen
• Anforderungen aus Dokumenten ableiten
• z.B. Rollen/Sichten („Views”)
• Mögliche Kriterien
• Features/Funktionen
• Dependencies/Abhängigkeit
• Anforderungsspezifischj
• Benutzergruppenspezifisch
• Priorität
• Kosten
Use Case (Anwendungsfall)
Beschreibung:
Namen
Beschreibung (kurz!)
Aktoren / Auslösendes Ereignis
Eingangsvorraussetzung (Bedingungen)
Ablauf
Ausgang
Bemerkungen
htt
p://i.m
sd
n.m
icro
soft.c
om
/
Use-Case-Diagramme
Qu
elle
: h
ttp
s://w
ww
.fb
i.h
-da.d
e/la
bo
re/c
ase/u
ml/a
nw
end
un
gsfa
lldia
gra
mm
.htm
l
Use Case• Beschreibung:
• Namen
• Beschreibung (kurz!)
• Aktoren / Auslösendes Ereignis
• Eingangsvorraussetzung (Bedingungen)
• Ablauf
• Ausgang
• Bemerkungen
• …
htt
p://i.m
sd
n.m
icro
soft.c
om
/
System von
Anwendungs-
fällen
Qu
elle
: h
ttp://w
eite
s-in
tern
et.d
e/k
ate
go
rie
n/in
tere
ssan
t/6
8-U
ML-A
nw
end
un
gsfa
elle
-mit-E
nte
rprise-A
rch
ite
ct.h
tml
1. Sytem
2. Akteur
3. Szenario
4. Use Case
5. …
Zusammenfassung
• Motivation und Ziele
• Anforderungen
• Anforderungsanalyse
• Use Cases / User Stories (Text & Diagramm)
• Szenarien
Übersicht „Vorgehensweisen“
Qu
elle
: h
ttp://w
infw
iki.w
i-fo
m.d
e/index.p
hp/A
bg
ren
zung
_de
r_agile
n_S
oft
wa
ree
ntw
icklu
ng_von
_kla
ssis
chen_V
erf
ahre
n
Softwareentwicklung über die
letzten Jahrzehnte
Wasserfallsmodell
Qu
elle
: h
ttp
://i.im
gu
r.co
m/o
Xm
nL
.pn
g
Spiralmodell
Qu
elle
: h
ttp
://w
ww
.im
n.h
twk-le
ipzig
.de
/~w
eic
ke
r/u
plo
ad
//M
ain
/win
win
mo
de
ll.jp
g
http
://im
ag
es.r
ap
ge
niu
s.c
om
/ca
89
bf9
75
c7
83
485
53
4cb
97
54
65
96
45
a.6
40
x4
27
x1
.jp
g
SCRUM
Qu
elle
: h
ttp
://m
ed
ia-c
ach
e-e
c0
.pin
img
.co
m/7
36
x/6
b/e
d/6
5/6
be
d6
5d
b79
4cfd
4a
ee
11
65
42
fde
0e
d2
4.jp
g
http
://a
u.s
tre
ng
thsco
pe
.co
m/b
log
/?p
=1
17
7
http
://r
eb
ecca
no
eh
.co
m/w
p-c
on
ten
t/u
plo
ad
s/2
01
3/1
1/s
cru
m-M
TE
2M
jgxN
TczM
zE
5M
jIzM
TY
1N
T.jp
g
Klassisch vs. Agil (?)
Quelle
:htt
p:/
/ww
w.in
foq.c
om
/resourc
e/n
ew
s/2
008/0
1/ite
ratin
g-a
nd-in
cre
mentin
g/e
n/r
esourc
es/P
att
on_In
cre
menta
l_It
era
tive
_M
naLis
a.jp
g
Aufgaben
Aufgabe 1
• Überlegen Sie einen Use-Case für:
• Die Abwicklung eines Einkaufes an
einer Kasse.
• oder Ihr Projekt.
und bilden Sie ein Modell dazu.
und schicken Sie mir diese an:
Herzlichen Dank!