P roj ekt st rukt ur : B ei spi el e D ip lo m a rb e it 1 . L it e ra tu r- re ch e rch e

(1)

Softwaretechnologie, © Prof. Uwe Aßmann Technische Universität Dresden, Fakultät Informatik1

Teil V : Pr ojek tmanagement 50 Pr ojek tplanung Ja , m ac h nur ein en Pl an S ei nur ein groß es Lic ht ! U nd m ac h' d an n noc h 'n en z we it en Pl an Ge h' n tun s ie b eid e nic ht . Be rt ol t Bre ch t, D ie D re igros ch en ope r

Prof. U. Aßmann, Softwaretechnologie

P roj ekt st rukt ur : B ei spi el e D ip lo m a rb e it 1 . L it e ra tu r- re ch e rch e

1.1 vorgegebene Literatur auswerten 1.2 weitere Quellen identifizieren 1.3. weitere Literatur beschaffen 1.4 beschaffte Literatur auswerten

2 . E n tw u rf d e s e ig e n e n A n s a tz e s 3 . Im p le - m e n ti e ru n g 4 . A u s a r- b e it u n g .. . .. . .. . S W -P ro je kt X 1 . A n a ly s e 2 . E n tw u rf 3 . Im p le - m e n ti e ru n g 4 . In fr a s tr u kt u r .. . .. . .. . 2 .1 G ro b -E . 2 .2 F e in -E .

(2)

Prof. U. Aßmann, Softwaretechnologie3

H ausbau

Hausbau 1. Baugenehmigung2. Aushub3. Keller4. Erdgeschoß ... ...

2.1 Bagger2.2 Hand justierung 3.1 Bodenplatte

3.2 Keller- mauerwerk 3.3 Keller- decke 5. Dachgeschoß6. Elektro7. Estrich8. Innenputz Prof. U. Aßmann, Softwaretechnologie4

A uf w andsschät zung

►

S ch ät zu ng en f ür :

■relativen Aufwand der Teilaufgaben ■absoluten Aufwand für Subsysteme ►

Fa ust re ge ln , E rf ah ru ng sw er te

►

Te ch ni ke n de r A uf w an dssch ät zu ng :

■Befragung von Entwicklern ■Klassifikation z.B. durch "Function Point"-Methode ♦Wie viele Teilfunktionen? ♦Wie schwierig ist jede Teilfunktion? ■Metriken für Spezifikationen ■"Kalibrierung" durch eigene Erfahrungswerte ►

M eh r in V or le su ng „ S of tw ar em an ag em en t“ , S S

(3)

A bhängi gkei ten

►

W e lch e A kt ivi tä te n hä ng en vo n E rg eb ni sse n an de re r A kt ivi tä te n ab ? (A bh än gi gke itsg ra ph )

►

A uf w an dssch ät zu ng + f est e Te rm in e + A bh än gi gke ite n:

■Netzplantechniken (z.B. PERT) ■GANTT-Diagramm ►

B ei sp ie l f ür A bh än gi gke ite n, e rf aßb ar in A kt ivi tä te nd ia gr am m :

1. Analyse2. Entwurf 3. Imple- mentierung

4. Infrastruktur 2.1 Grob-Entwurf2.2 Fein-Entwurf

3.1 Impl. Subsystem 13.2 Impl. Subsystem 2 Prof. U. Aßmann, Softwaretechnologie

Zei tpl anung: G ant t- D iagr am m A rb e it sp a k e t 1 .1 A n a lys e 2 .1 G ro b e n tw u rf 2 .2 F e in e n tw u rf 3 .1 I m p l. S u b s ys . 1 4 .1 W e rkz e u g e

3 .2 f f .. .

P ro je kt w o c h e n 1 2 3 4 5 6 7 8 . .. Id en tif ika tio n kr iti sch er u nd un kr iti sch er (4 .1 , 3. 1) A rb ei tsp ake te (kr iti sch = V er lä ng er un g ve rlä ng er t G esa m tp ro je kt da ue r)

(4)

Zei tpl anung H ausbau: G ant t- D iagr am m A rb e it sp a k e t 1 .1 B a u g e n e h m ig . 2 .1 A u sh u b 2 .2 K e lle r 3 .1 E rd g e s c h o ß 1 4 .1 H a u sa n sc h lu ß

3 .2 D a c h g e sc h o ß .. .

P ro je kt w o c h e n 1 2 3 4 5 6 7 8 . ..

R essour cenpl anung P ro je kt w o c h e n 1 2 3 4 5 6 7 8 . ..

A n z a h l P e rso n e n 1 2 3

4 5 1 .1 2 .1

2 .2

3 .1 3 .2

4 .1

4 .1 4 .1

►

U m pl an un g m it de m Zi el : A np assu ng a n vo rh an de ne R esso ur ce n

►

P acke n in Fl äch en ü be r A nz. P er so ne n un d P ro je kt w och en

(5)

M ei lenst ei ne

►

E in M ei le nst ei n ist e in kl a r de fin ie rt es Zw isch e nr esu lta t, a n H an d de sse n de r P ro je kt fo rt sch rit t be ur te ilt w er de n ka nn .

►

B ei sp ie le :

–"Anforderungsspezifikation zusammen mit Auftraggeber verabschiedet" –"Erster Prototyp lauffähig" –Schlechtes Beispiel: "Code zu 50% fertig" ►

M ei le nst ei ne im G an tt -D ia gr am m : A rb e it sp a k e t 1 .1 A n a lys e 2 .1 G ro b e n tw u rf

P ro je kt w o c h e n 1 2 3 4 5 6 7 8 . ..

M1 Prof. U. Aßmann, Softwaretechnologie

P roj ekt ver fol gung

►

D as P ro je kt m an ag e m e nt m uß ei n "Fr üh w ar ns yst em " fü r eve nt ue lle P ro bl em e be tr ei be n (P ro je kt ve rf ol gu ng ).

►

In fo rm at io nsq ue lle n:

–Laufende (z.B. wöchentliche) Management-Berichte –Arbeitszeit-Kontierung –Resultate (deliverables) ►

R ückko pp lu ng zu m P ro je kt te am

–Regelmäßige Projektbesprechungen –Beispiel: Akkumulierter Ressourcenverbrauch

Z e it

A k ku m u lie rt e K o s te n B u d g e t g e p la n te s P ro je kt - e n d e S o ll Is t B e ri ch ts z e it p u n k t

(6)

M ei lenst ei n- T rendanal yse P ro je k tw o c h e n 1 2 3 4 5 6 7 8 . .. 1 2 3 4 5 6 7 8

B e ri ch ts - w o ch e n

A B C J e w e ili g e V o rh e rs a g e E rr e ich t

►

A n ha n d je de s M an ag em en tb er ich ts sa gt d as M an ag e m en t di e M ei le nst ei ne n eu vo ra us

Team zusam m enst el lung (S taf fing)

►

R eg el n fü r Te am pr od ukt ivi tä t:

■Optimale Teamgröße: ca. 5-7 Personen ■Gemischte Qualifikationen ■Team von externer Kommunikation entlastet ■Große Projekte aus vielen Teams zusammengesetzt ►

H ar la n M ill s / B ake r 19 72 : C he fp ro gr am m ie re r- S tr ukt ur

Chef- ProgrammiererStell- vertreter Spezialisten & Bibliothekar Testverantwortlicher Qualitätsverantwortlicher Dokumentationsverantwortlicher

(7)

O rgani sat ion von S itzungen

►

V or S itzu ng en so llt e m an im m er f ol ge nd es (sch rif tli ch ) fixi er en :

►

Zi el e

■Zweck des Treffens (was wollen wir erreichen?) ■Erfolgskriterien des Treffens (wie können wir kontrollieren, dass wir das Ziel erreicht haben?) ►

A ge nd a

■Welche Teilnehmer? Haben diese versteckte Zielkonflikte? ■Zeitplanung: Wie lange welcher Punkt? ►

V er an tw or tli ch er fü r ei n E rg eb ni sp ro to ko ll

Typi sche G lieder ung ei nes E rgebni spr ot okol ls:

►

N am e de r S itzu ng

►

Te iln eh m er , M od er at or , O rt , Ze it

►

Ta ge so rd nu ng

–Standard-Tagesordnungspunkte: ♦Protokollkontrolle ♦Bericht über den erreichten Stand ♦Einzelaufgaben ♦Nächster Termin ►

E rg eb ni sse

■gegliedert nach Tagesordnungspunkten (TOPs)

(8)

E inzel auf gaben (A ct ion Item s)

►

E in ze la uf ga be (a ct io n ite m , act io n po in t) be st eh t a us:

■Lfd. Nr. ■Verantwortliche Person ■Kurztitel ■Beschreibung ■Ursprung (Sitzung, auf der Aufgabe definiert wurde) ■Termin ■Status (offen, verlängert, erledigt) ►

Li st e de r E in ze la uf ga be n w ird b ei

jedem

T re ffe n d ur ch ge g a ng e n un d akt ua lisi er t:

■Welche Aufgaben sind fällig? ■Was ist das Ergebnis? ■Was ist weiter zu tun? ♦Termin verlängern ♦Neue Aufgaben definieren Softwaretechnologie, © Prof. Uwe Aßmann Technische Universität Dresden, Fakultät Informatik16

50.2 V or geh ens mode lle (Phas enmodelle)

(9)

O bl igat or isches Lesen

►

Zu se r K ap . 1- 3 od er

►

G he zzi C ha pt er 1 od er

►

P fle eg er C ha pt er 1 ; C ha p 8. 1

Vorgehensmodell (engl. process model) ●

S tr u kt u ri e rt e s M o d e ll z u m E rs te lle n v o n S o ft w a re

Phasenmodell –Vorgehensmodell, das den Herstellungsprozesses in definierte und abgegrenzte Phasen einteilt –Vorgabe einer Reihenfolge in der Bearbeitung der Phasen Prof. U. Aßmann, Softwaretechnologie

Wi e gehe ich vor , um S of tw ar e zu ent w ickel n?

►

A d ho c

►

E s lie f sch on o ft sch ie f. ..

■Denver International Airport, Krise 1993-95 ■Bahncard 50 ■Hamburger Güterbahnhof 1995 ►

G ib t es ni ch t i rg en dw el ch e H ilf en , st ru kt ur ie rt vo rzu ge he n?

(10)

V or gehen nach ei nem “ P hasenm odel l”

►Phasenmodell

( pr oce ss m od el , so ft w ar e de ve lo pm en t l ife cycl e )

■Einteilung des Herstellungsprozesses für ein (Software-) Produkt in definierte und abgegrenzte Abschnitte, abgegrenzt durch Meilensteine ♦Grobgliederung: Phasen (phases) ♦Feingliederung: Schritte (stages, steps) ■Vorgabe einer Reihenfolge in der Bearbeitung der Phasen ■Richtlinie für die Definition von Zwischenergebnissen ♦Detailliertes Phasenmodell + Zwischenergebnisdefinition = „Vorgehensmodell“ ►

G ru nd akt ivi tä te n:

■Analyse ■Entwurf ■Implementierung ■Validation (v.a. Test, Integration) ■Evolution (v.a. Wartung) Prof. U. Aßmann, Softwaretechnologie20

W asser fal l-M odel l ( pur )

Analyse Entwurf Implementierung Test, Integration Wartung

W. Royce (1970)Produkt- definition Entwurfs- Spezifikation Code geprüfter Code Änderungswünsche ►Das Wasserfallmodell ist nicht realistisch. Für ein Produkt müssen, schon um des Geschäftsmodells willen, Verbesserungen (Lebenszyklen) eingeplant werden ►Ein Lebenszyklus dauert i.D. 2 Jahre ►Dennoch muss ein Softwareingenieur den “Wasserfall” beherrschen, denn viele andere Vorgehensmodelle setzen darauf auf

(11)

1 0 % 2 0 % 5 0 % 2 0 %

U ngef ähr e V er tei lung des A rbei tsauf w andes

Analyse Entwurf Implementierung Test, Integration Wartung Prof. U. Aßmann, Softwaretechnologie

Q ual ität ssi cher ung im V -M odel l

Analyse Grobentwurf Feinentwurf Implementierung

Abnahmetest Systemtest Integrationstest Modultest

Testfälle Testfälle Testfälle Boehm 1979 („V-Modell“)

(12)

V -M odel l des B M I ( ver ei nf acht )

Analyse Grobentwurf Feinentwurf Implementierung

Test & Inte- gration Prüfaktivitäten

Subsystem-Test

Abnahme-Test Bröhl/Dröschel 1993 Prof. U. Aßmann, Softwaretechnologie24

Inkr em ent el le (evol ut ionär e) E nt w ickl ung

Analyse Entwurf Modifikation

Evolution

(13)

E vol ut ionär e E nt w ickl ung

►

Typ isch f ür kl ei ne re P ro je kt e od er e xp er im en te lle S yst em e

►

B ei O bj ekt or ie nt ie ru ng a uch f ür g rö ße re P ro je kt e an w en db ar ?

Analyse EntwurfValidation

Aufgabe

Prototypen, Vorversionen

Implementierung Prof. U. Aßmann, Softwaretechnologie

eX tr em e P rogr am m ing (X P )

►

A kt ue lle , ko nt ro ve rs di sku tie rt e E nt w ickl un gsm et ho di k (K en t B eck)

■Konsequente evolutionäre Entwicklung ■Der Programmcode ist das Analyseergebnis, das Entwurfsdokument und die Dokumentation. Code wird permanent (Tagesrhythmus) lauffähig gehalten ■Diszipliniertes und automatisiertes Testen als Qualitätssicherung ■Diverse weitere innovative Techniken (z.B. Paar-Programmierung) ■liefert schnell Ergebnisse, aber u.U. auf Kosten der Langlebigkeit ■kann prinzipiell mit traditionelleren Analyse- und Entwurfstechniken kombiniert werden ►

N ach te ile

■wird manchmal als Gegenbewegung zu sauberem Softwareentwurf mißverstanden ■ist nur geeignet für relativ überschaubare, isolierte Anwendungen ►

"A gi le " S of tw ar ee nt w ickl un g

(www.agilemanifesto.org)

:

■weitere Ansätze, z.B. Crystal, Scrum

(14)

S pi ral m odel l

Risikoanalyse Prototypen P1P2P3P4 Planung der nächsten Phase

Zielbestimmung, Beurteilung von Alternativen

Anfor- derun- gen V&V V&V V&V = Verifikation & Validation

Entwicklung nächstes Teilprodukt

Grob- entwurf Fein- entwurf

Code

Inte- gration

Test Ab- nahme B. Boehm (1988) Prof. U. Aßmann, Softwaretechnologie28

O bj ekt or ient ier tes S pi ral m odel l

Implementierung Analyse

Entwurf Test Produkte (Releases) einschl. Prototypen

L a n g fr ist ig e V o rp la n u n g d e r Z y k le n -D u rc h lä u fe

(15)

S pi ral m odel l vs. evol ut ionär e E nt w ickl ung

►

G ru nd id ee id en tisch :

■Zyklisches Durchlaufen von Entwicklungsaktivitätem ■Aufeinanderfolgende Prototypen ►

E vo lu tio nä re u nd a gi le E nt w ickl un g:

■Reaktion auf Änderungen ist wichtiger als Verfolgung eines Plans ■Planung nur für sehr kurze Zeiträume (Tage, Wochen) im voraus ■Viele, häufige Durchläufe (z.B. Tagesrhythmus) ►

S pi ra lm od el l:

■Einsetzbar in verschiedener "Strenge" ■Vorausplanung von Durchläufen ♦Anzahl Durchläufe manchmal schon bei Projektbeginn festgelegt ■Wenige Durchläufe (z.B. Quartalsrhythmus) ■Kompromiß zwischen Planbarkeit und Agilität Prof. U. Aßmann, Softwaretechnologie

P ar al lel ität im E nt w ickl ungspr ozeß

Zeit

Ergebnisse

Anforderungs- spezifikation Produkt- definition Entwurfs- spezifikation Subsystem 1 Subsystem 2 Subsystem 3 Code Subsystem 1 Subsystem 2 Subsystem 3

"Makro-Phasen" Analyse/Entwurf/ Implementierung "Mikro-Phasen" Analyse/Entwurf/ Implementierung

(16)

Zw ei di m ensi onal es M odel l

►

R at io na l U ni fie d P ro ce ss 19 9 9 (Ja co bso n e t a l., K ru ch te n ) m it M ikr o- un d M akr op ha se n

Tätigkeit

Zeit Analyse Entwurf Implementierung Test Konfigurations- management Projekt- management

Entstehung (inception) Ausarbeitung (elaboration) Erstellung (construction) Übergang (transition)

A uf w andsver tei lung und S chw er punkt e R at io na l U ni fie d P ro ce ss 19 99 ( Ja co bso n et a l., K ru ch te n)

Tätigkeit

Zeit Analyse Entwurf Implementierung Test Konfigurations- management Projekt- management

Entstehung (inception) Ausarbeitung (elaboration) Erstellung (construction) Übergang (transition)

(17)

R at ional U ni fied P rocess (R U P )

►

vo n IB M R at io na l:

Tei lpr oj ekt e und Ü ber lappungsgr ade

I1E1C1T1 I2E2C2T2Teilprojekt 1 Teilprojekt 2

Release 2 I1E1C1T1 I2E2C2T2Teilprojekt 1 Teilprojekt 2

Release 1 Release 2

I1E1C1T1 I2E2C2T2Teilprojekt 1 Teilprojekt 2

Release 1 „aggressiv“„konservativ“ „Standard“

Release 2 Release 1 IInception EElaboration CConstruction TTransition

(18)

V or gehen im S of tw ar epr akt ikum 3. S em est er

►

E ch te K un de n

►

V or ge he nsm od el l: V -M od el l m it A kze pt an zt est s

►

E in fa ch e In kr em en ta lit ät : K un de h at e in en V er be sse ru ng sw un sch fr e i, de r er st zu e in em sp ät en Ze itp un kt b eka nn tg eg eb en w ird

►

In te rn ka nn e in in kr em en te lle V or ge he nsm od el l g ew äh lt w er de n

W as haben w ir gel er nt ?

►

V o rg e he n na ch e in em st ru kt ur ie rt en P h a se n m o de ll ist g ew ö hn lic h be sse r al s ad -h oc V or ge he n

►

R ea list isch e V or ge he nsm od el le si nd it er at iv un d in kr em en te ll

►

D er I ng en ie ur m isst , en tw irf t, va lid ie rt u nd ve rb esse rt

(19)

R ef er enz

►

D ie d eu tsch en Fo lie n d e r S o ftw a re te ch no lo gi e- V or le su ng st am m e n zu g ro sse n Te ile n a us de n Ja hr en 2 0 00 -2 0 03 u nd w ur de n vo n P ro f. D r. H ei nr ic h H u ssm an n , j e tzt L M U M ü nch e n, e rst el lt. U se d b y pe rm issi on .