Doing gooD, thanks!

Transcription

Doing gooD, thanks!

Ingeniørhøjskolen i Århus
Projekthåndbog
E- og IKT projekter
Michael Alrøe
Afdeling for Computer Technology & Embedded Systems
Versionshistorie
Ver.
1.0
1.1
1.2
1.3
1.4
Dato
12.01.2009
20.01.2009
29.01.2009
03.02.2009
03.02.2009
Initialer
MA
MA
MA
MA
MA
Beskrivelse
Første version beregnet for IHA semesterprojekter
Revideret efter feedback fra FOH
Beskrivelse af perspektiver for UML
Indsat beskrivelse af Banana SCRUM fra SFK!
Link til Visual Paradigm, og generel beskrivelse af UML værktøjer.
Formidling af SVN repository. Nyt afsnit om Projektstying
Forord
Denne note er skrevet for at komme med nogle generelle betragtninger omkring
udarbejdelse af semesterprojekter og afgangsprojekter på Ingeniørhøjskolen i Århus. De
enkelte kommentarer og råd bør altid vurderes i forhold til det givne projekt. Ved tvivl bør
den respektive vejleder kontaktes.
Mange af punkterne er fremkommet som kommentarer til generelle spørgsmål og
misforståelser jeg har fået som vejleder af både semesterprojekter og afgangsprojekter.
Jeg modtager meget gerne kommentarer omkring forslag til forbedringer og udvidelser.
Michael Alrøe, [email protected]
Grady Booch:
“People are more important than any process. Good people with a good process will
outperform good people with no process any time.”
Martin Fowler:
“You should use iterative development only on projects that you want to succeed”
Version 1.4
side 2
Indholdsfortegnelse
1
2
3
4
5
6
7
8
Generelt............................................................................................................................. 4
Projektdokumentation....................................................................................................... 5
2.1
Kravspecifikation .................................................................................................... 5
2.2
Tidsplan ................................................................................................................... 8
2.3
Analyse .................................................................................................................... 8
2.4
Design...................................................................................................................... 8
2.4.1 Arkitekturdesign (strukturering): ........................................................................ 8
2.4.2 Detaljeret design:................................................................................................. 9
2.5
Implementering ....................................................................................................... 9
2.6
Enhedstest/unittest................................................................................................... 9
2.7
Integrationstest ...................................................................................................... 10
2.8
Accepttest .............................................................................................................. 10
2.9
Bilag ...................................................................................................................... 10
2.10 CD ......................................................................................................................... 10
Udviklingsmetoder ......................................................................................................... 11
3.1
Adræt projektledelse.............................................................................................. 11
3.2
Konkrete udviklingsmetoder ................................................................................. 12
3.2.1 Vandfladsmodellen............................................................................................ 12
3.2.2 Struktureret Program Udvikling (SPU) ............................................................. 12
3.2.3 Rational Unified Process ................................................................................... 13
3.2.4 Extreme Programming ...................................................................................... 14
3.2.5 SCRUM ............................................................................................................. 15
3.3
IHA Udviklingsmodel ........................................................................................... 16
3.3.1 S-Model for styring ........................................................................................... 16
3.3.2 V-model for test................................................................................................. 17
3.3.3 W-model for leverancer..................................................................................... 18
3.3.4 U-model for udviklingsaktiviteter ..................................................................... 19
Review ............................................................................................................................ 20
Projektstyring.................................................................................................................. 20
UML ............................................................................................................................... 20
Ordliste/forkortelser........................................................................................................ 22
Referencer....................................................................................................................... 22
Version 1.4
side 3
1 Generelt
•
Både semesterprojekter og afgangsprojekter bør følge ”Vejledning for EITprojekter”. Vejledningen kan findes på Campusnet.
https://www.campusnet.iha.dk/cnnet/filesharing/SADownload.aspx?ElementId=459&FolderId=6666
&FileId=30005
•
•
•
•
•
•
•
•
Bemærk at projektrapporten skal skrives som en rapport specielt til censor eller en
anden ekstern person, som kan forventes at have samme generelle tekniske
forståelse som dem der skriver rapporten. Det betyder at vigtige resultater som
censor skal se skal fremgå af projektrapporten. Indledningsvis kan rapporten f.eks.
også indeholde en beskrivelse af problemdomænet. Resultater behøver ikke bare at
være det færdige skærmlayout, eller det færdige printlayout, men i højere grad det
interne design af produktet. Det kunne f. eks. være overordnede diagrammer der
definerer arkitekturen (klasse- sekvens-, elektriske diagrammer) for produktet. Det
er også i denne rapport hvor det er muligt at diskutere fordele/ulemper ved valgte
løsningsmodeller. Husk at denne rapport kan være det første som censor læser
omkring den specifikke problemstilling.
Det kan være en fordel at indgå en gruppekontrakt ved projektopstart. Hvis en
gruppekontrakt først indgås når det er ved at ”gå skævt” er det ofte for sent.
Udnævn en individuel person til at være ansvarlig for specifikke dokumenter –
dermed ikke at vedkommende er ansvarlig for udførelsen af arbejdet, men blot har
ansvaret for vedligeholdelsen af dokumentet.
Det kan ofte være en fordel ved større grupper (3+) at lave en oversigt over de
enkelte gruppedeltageres specifikke arbejdsområder. Oversigten kan indsættes i
projektrapporten, og giver dermed censor og vejleder en oversigt over den enkelte
projektdeltagers specifikke arbejdsområde.
Definer layout for dokumenter/kode ved projektopstart.
Husk løbende at dokumentere de valg/overvejelser/alternativer der blive foretaget i
løbet af projektet. Disse kan indsættes i ”Projekt Rapporten”.
”Projekt Rapporten” er en censorrapport, ud fra hvilken censor skal være i stand til
at vurdere projektet. Det betyder at alle væsentlige resultater skal præsenteres i
rapporten. Det kan være centrale diagrammer der viser den interne opbygning af
projektet – hvilket ofte er mere interessant end f. eks. hvordan den endelige
brugergrænseflade ser ud.
Der skal være figurnumre og figurtekst til alle figurer.
Århus Tekniske Bibliotek har en side omkring projektskrivning. Biblioteket har
anskaffet et referencestyringsværktøj, RefWorks, som stilles til rådighed for
studerende – kontakt biblioteket for at høre nærmere.
http://www.atb.dk/Projektskrivning-5849.aspx
Version 1.4
side 4
2 Projektdokumentation
2.1 Kravspecifikation
•
I forbindelse med udarbejdelse af kravspecifikation foregår der typisk et antal
aktiviteter:
Figur 1, Eksempel på specifikationsaktiviteter
•
•
Ved specifikation af de funktionelle krav kan use case teknikken anvendes. En ”use
case” kan oversættes til en brugssituation.
En use case baseret kravspecifikation kan opbygges efter nedenstående model:
Aktør-kontekst diagram
1. Indledning
2. Generel beskrivelse
3. Funktionelle krav
4. Ekstern grænseflade
5. Krav til ydelse
6. Kvalitetsfaktorer
7. Design krav
8. Andre krav
9. Del-levering
System/
Produkt
Use Case diagram
Use
Case 1
Use
Case 2
...
Use
Case n
Figur 2, Eksempel på opdeling af kravspecifikation.
Version 1.4
side 5
•
•
•
•
•
•
•
•
•
Udarbejd accepttestspecifikation sideløbende med kravspecifikation, hvilket sikrer
testbarhed af kravspecifikationen.
Alle krav skal være testbare!
Use cases kan beskrives i flere detaljeringsgrader, man definerer typisk:
Brief
– Typisk en sætning der beskriver hovedscenariet.
– Hvornår: Ved tidlig Requirement Analysis
Casual
– Typisk flere sætninger der beskriver hovedscenariet samt væsentlige
alternativer/undtagelser.
– Hvornår: Ved tidlig Requirement Analysis
Fully Dressed
– Komplet og detaljeret beskrivelse af alle scenarier og undtagelser.
– Hvornår: Inden udarbejdelse af testspecifikation og design. Start med at
udvælge de mest betydningsfulde Use Cases.
En kravspecifikation kan godt bestå af use case beskrivelser med forskellige
detaljeringsgrader. Vigtigt er det at den/de use cases der skal anvendes i den aktuelle
iteration er ”Fully Dressed”.
Ved use case beskrivelser er det vigtigt at gøre sig helt klar hvem der gør hvad:
1. Systemet …
2. Aktør1….
3. Systemet…
Den funktionelle beskrivelse skal være set fra aktørens/kundens side, og ikke fra
udviklers!
Brug gerne punktform for use case beskrivelserne.
Brug gerne punktform for beskrivelse af undtagelser, og hvor går systemet hen efter
udførelse af en undtagelse.
Det kan være en fordel at beskrive brugergrænsefladen med nogle skitser/skabeloner
for hvordan det endelige system kommer til at se ud. Brugergrænseflade skal ikke
være en integreret del af UC beskrivelserne, men kan evt. refereres til i et andet
afsnit. Det endelige system må ikke afvige væsentligt fra denne beskrivelse!
Begrebet ”Who has the ball” definerer en interaktion mellem aktører og system,
således at man som læser ikke er i tvivl om hvem der skal udføre den givne aktion.
1. ”Der indtastes en parameter der valideres”
Er det aktør eller system der validerer den konkrete indtastning.
Bedre:
1. Systemet udskriver prompt for parameter X(se fig.xx, afsnit yy).
2. Aktør1 indtaster parameter X.
3. Systemet validerer parameter X.
Undtagelse: Ugyldig parameter X
4. Aktør1 …..
Undtagelser:
Ugyldig parameter X
1. Systemet udskiver ….
2. Aktør1 ….
Version 1.4
side 6
3. Use case fortsætter i pkt. 1.
Det er vigtigt at få beskrevet hvad der sker efter en undtagelse. Det kan være at use
casen fortsætter i et punkt i normalforløbet, men det kan også være at use casen
afsluttes.
3. Use case afsluttes.
•
Det kan for nogle scenarier være en fordel at beskrive alternativer som en del af
normalforløbet. Dette kan f.eks. gøres ved at bruge indeksering A. B. C. …. for et
givent punkt i normalforløbet.
1. Systemet udskriver menu X(se fig.xx, afsnit yy).
2.A.
1. Aktør1 vælger a.
2. Systemet ….
3. Aktør1 ….
2.B.
1. Aktør1 vælger b.
2. Systemet ….
3. Aktør1 ….
2.C.
1. Aktør1 vælger c.
2. Systemet ….
3. Systemet ....
Fra pkt. 3 i ovenstående er der fælles forløb for alle alternativer.
•
Udformningen af en use case er ikke standardiseret, men som udgangspunkt bør
hver use case som minimum indeholde følgende:
Mål:
Her gives selve målet med use casen. Beskrivelsen skal supplerer og uddybe
den information der ligger i selve navnet (typisk 1-3 linjer tekst).
Normal scenarie:
Normalforløbet beskriver solskinsscenariet, hvor alt går efter planen og målet
med use casen opfyldes. De øvrige scenarier beskrives som undtagelser til
normalforløbet
Hver ny funktionalitet beskrives som et trin på en ny linje, der nummereres
med et fortløbende nummer. Det angives i hvert trin om det er aktøren eller
om det er systemet der har initiativet. Hver trin (sætning) beskrives i nutid og
skal føre et trin frem mod slutmålet.
Undtagelser:
Her angives hvad der skal ske for de forskellige undtagelser, der er angivet
under normalforløbet.
Version 1.4
side 7
Yderligere information omkring use case teknikken kan findes i [UMLLIGHT],
[SPUUML], og endelig har Alistair Cockburn skrevet en bog [Cockburn2000] udelukkende
om at skrive use cases.
2.2 Tidsplan
Der bør for hvert projekt udarbejdes en tidsplan. Det vigtige ved tidsplanen er at den
indeholder nogle målebare aktiviteter (milestones). Det vil f. eks. være meget svært at måle
på en aktivitet som hedder ”Implementering”, idet dette formentlig vil foregå gennem en
stor del af projektet. Det vil her være meget bedre f.eks. at opdele i nogle underpunkter. Det
kunne f.eks. være ”Implemetering af use case XX”.
2.3 Analyse
Det kan for nogle projekter være nødvendigt at udføre en analyse inden der kan udføres et
design. Analysen kan bruges til at undersøge teknologier mm. der kan bruges i designet af
systemet. Analysen dokumenteres i et separat dokument, og kan indeholde konklusioner på
analysen.
2.4 Design
Formålet med design er realisering af kravene fra kravspecifikationen. Der skal derfor ikke
udtænkes ny funktionalitet i denne fase.
Design dokumentationen kan med fordel opdeles i 2 dokumenter. Et dokument der
indeholder de arkitektur mæssige design overvejelser, og et detaljeret design dokument.
2.4.1 Arkitekturdesign (strukturering):
Kan indledes med en kort beskrivelse af den overordnede arkitektur af systemet. Kan
suppleres med en systemtegning.
Hardware:
• Opdeling i blokke.
• Beskrivelse af overføringsfunktion for hver blok.
• Interface mellem blokkene, f.eks.:
o Analoge/digitale niveauer
o Impedanser,
o Protokol (f.eks. mellem PC og mikroprocessor)
Software:
• Overordnet klassediagram uden attributter og metoder. Gerne suppleret
med associationsnavne og multipliciteter.
• Sekvensdiagram
• Detaljeret klassediagram med samme informationer som overordnet
klassediagram, men suppleret med arkitektur signifikante (læs vigtige)
attributter og metoder.
• Suppleret med andre diagrammer, f.eks. tilstands- og package
diagrammer.
Version 1.4
side 8
Alle diagrammer bør have en tilhørende kort beskrivelse
Ved komplekse systemer kan ”4+1 view” [Krutchen85] anvendes til
dokumentation af designet.
Der findes mange bøger og artikler om Objekt Orienteret Design (OOD).
Firmaet Object Mentor har en række gode grundlæggende artikler
tilgængelige på deres hjemmeside[RobertCMartin].
2.4.2 Detaljeret design:
Hardware:
• Realisering af den enkelte blok
• Enhedstest af den enkelte blok
Software:
• Detaljeret beskrivelse af de enkelte attributter og metoder for hver
enkelt klasse (kan evt. udelades hvis beskrivelser findes i kode – typisk
C#). Herunder også detaljer der skal bruges til implementering f.eks.
opsætning af registre for mikroprocessorer.
• Enkelte metoder med komplekse strukturer kan beskrives med
aktivitetsdiagrammer.
2.5 Implementering
•
•
•
•
•
•
•
Brug evt. versionsstyring
Campusnettet har en indbygget versionskontrol, som kan bruges som simpel
versionsstyring. Ved mere avanceret styring kan et SVN repository formidles, idet
IHA har en SVN server. Ved henvendelse til Helpdesk kan et SVN repository
formidles.
Definer en kodestandard. Ved C++ programmering har IHA en kodestandard, som
kan findes på Campusnet.
https://www.campusnet.iha.dk/cnnet/filesharing/SADownload.aspx?ElementId=459&FolderId=3974
8&FileId=171717
Brug tabulering/indryk ved hvert scope.
Brug engelske navne for metoder og attributter.
GUI delen kan være på lokalt sprog (Dansk/Engelsk/…).
Fjern ”gammel” kode fra den endelige version der skal afleveres til bedømmelse.
Bibehold formatering af kildetekster ved indsættelse i tekstbehandlingsprogram.
Kode kan blive næsten ulæselig uden korrekt formatering når den indsættes i f.eks
Microsoft Word!
2.6 Enhedstest/unittest
Kan både være for hardware og software. For software vil unittest normalt være test af en
klasse. Ligesom alle andre tests skal enhedstests være reproducerbare. Det betyder at det
klart skal fremgå hvilke parametre der påtrykkes, og hvilke resultater der forventes. Det kan
ofte være en fordel at automatisere enhedstest.
Version 1.4
side 9
2.7 Integrationstest
Tester samspillet mellem enhederne. Kræver ofte udvikling af test stubbe og driver
moduler. Kan udføres enten bottom-up eller top-down i et hierarki.
2.8 Accepttest
Er altid et separat dokument!
En test skal altid være reproducerbar, hvilket betyder at testspecifikationen skal definere
hvilke specifikke værdier/parametre der skal bruges for at gennemføre testen. Dette betyder
at også brugerinput fra f. eks tastatur skal fastlægges i testspecifikationen.
Før et testscenarium kan gennemføres kan det nogle gange være nødvendigt at nogle
startbetingelser (preconditions) er opfyldt. Disse betingelser noteres i testspecifikationen
umiddelbart før beskrivelsen af testen. Det kan være at nogle bestemte filer med et bestemt
indhold skal være til stede før end testen kan gennemføres.
2.9 Bilag
Vigtige bilag kan udskrives og indsættes i rapporten. Alle bilag bør være på CD.
2.10 CD
Indeholder selvfølgelig al dokumentation for projektet.
Kildekode bør også indeholde projekt filer således at projekterne direkte kan åbnes og
kompileres.
Komponenter/biblioteker der anvendes, og som ikke er en del af udviklingsværktøjet skal
kopieres på CD, eventuelt sammen med en vejledning for installation af
komponenten/biblioteket.
Version 1.4
side 10
3
Udviklingsmetoder
En udviklingsmetode består af en proces, et ordforråd, og et tilhørende sæt af regler og
guidelines. Processen definerer et sæt af aktiviteter som tilsammen fører til målene for
metoden. Den del af metoden som kan standardiseres er ordforrådet, hvilket ofte er
defineret ved en notation. UML standarden er et eksempel på en fælles notation. Regler og
guidelines definerer kvaliteten af processen og tilhørende arbejdsopgaver. En af
udfordringerne ved at beskrive en metode er at det er svært, hvis ikke umuligt, at beskrive
en proces som fungerer for alle typer af projekter. Det vil derfor ofte være nødvendigt at
tilpasse processen til den aktuelle opgave, og det kan endda være nødvendigt at beskrive
hvordan UML anvendes, idet UML stiller så mange muligheder til rådighed.
3.1 Adræt projektledelse
Den adrætte projektledelse tager udgangspunkt i principperne bag begreberne ”Agile” og
”Lean”. Begge tankesæt fokuserer på skabelse af værdi.
Lean fokuserer på kontinuerlige forløb af arbejde og leverancer og bygger på, at man
leverer værdi til næste led i kæden ved at undgå spild.
Agile baseres på det ”Agile Manifest” der blev indgået af en gruppe udviklere, og
foreskriver:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Hele manifestet og tilhørende principper kan læses på: http://agilemanifesto.org/
Det danske ord adræt er synonymt med behændig, hurtig og let. Og sådan bør god
projektledelse være. Derfor bliver komplekse projekter skåret ud i små bidder, så det bliver
nemt at have med at gøre og nemt at fokusere på netop det, der skaber værdi her og nu både for kunden og virksomheden.
Derudover gælder det om at kunne handle hurtigt på baggrund af den nye viden,
projektdeltagerne får gennem projektet, og være kvik til at omstille sig, når kunden ændrer
behov, eller konkurrenten introducerer et nyt produkt.
Adræt projektledelse gør op med ideen om, at et projekt skal følge en tung drejebog, hvor
alt er tilrettelagt ned i detaljen, og hvor målet fra begyndelsen er urokkeligt.
Adræt projektledelse gør op med den traditionelle måde at gennemføre et projekt på, hvor
man aftaler, at et projekt skal levere et specificeret produkt til en fast tid og inden for et på
forhånd aftalt budget.
Der er generelt enighed om at man bør følge en iterativ udviklingsmodel, hvor hver ny
iteration tilfører værdi til projektet. Hver iteration bør være timeboxed, hvilket betyder af
Version 1.4
side 11
fast længde. Hvis iterationsperioden ikke kan overholdes skal funktionalitet fravælges frem
for at forlænge iterationsperioden.
Som introduktion til emnet henvises til [SPUUML].
3.2 Konkrete udviklingsmetoder
Der findes mange forskellige konkrete udviklingsmetoder. Nogle eksempler på nogle
konkrete udviklingsmetoder er:
• Vandfaldsmodellen
• Struktureret Program Udvikling (SPU)
• Rational Unified Process
• Extreme Programming
• SCRUM
3.2.1 Vandfladsmodellen
Vandfaldsmodellen er en model for udvikling af software (en proces til at lave software)
hvor softwareudvikling betragtes som konstant flydende nedad (som et vandfald) gennem
faserne: kravspecifikation, design, implementation, afprøvning/fejlfinding, integration og
vedligeholdelse. Ordet blev introduceret i 1970 af W. W. Royce. Det er dog ironisk at
Royce selv var fortaler for en anden model nemlig iterativ softwareudvikling. Royce
fremførte oprindeligt hvad der nu er kendt som vandfaldsmodellen som et eksempel på et
system som han sagde, "var risikabel og inviterer til fiasko".
3.2.2 Struktureret Program Udvikling (SPU)
Denne metode er beskrevet i bogen "Håndbog i Struktureret Programudvikling" [SPU88]
der består af 8 vejledninger, der bygger på erfaringerne fra et kursus i Struktureret
Programudvikling. SPU- vejledningerne kan anvendes som softwarehåndbog, og indeholder
mange evig gyldige sandheder om softwareudvikling.
Bogen er et resultat af et Teknologirådsprojekt, hvor erfarne softwareudviklere og
projektledere fra tidl. Jysk Teknologisk, Elektronik Centralen og Regnecentralen har
udviklet SPU-konceptet over en periode på 2 år.
De otte vejledninger er:
• Vejledning i struktureret programudvikling
• Vejledning i kravspecifikation
• Vejledning i design
• Vejledning i softwaretest
• Vejledning i review
• Vejledning i projektstyring
• Vejledning i programdokumentation
• Vejledning i konfigurationsstyring.
En af forfatterne, Finn Overgaard Hansen, har skrevet en tilføjelse til bogen som frit kan
downloades [SPUUML].
Version 1.4
side 12
3.2.3 Rational Unified Process
Rational Unified Process (forkortet RUP) er en objektorienteret softwareudviklingsproces
og et kommercielt produkt fra et firma der siden 2002 har været en del af IBM. IBM står for
videreudviklingen af RUP og tilhørende software. RUP bruger UML som notationsprog.
Når man kun taler om metoden og ikke det tilhørende software bruger man ofte betegnelsen
Unified Process (forkortet UP).
RUP blev oprindeligt udviklet af Ivar Jacobson, Grady Booch og James Rumbaugh mens de
arbejdede sammen i firmaet Rational Software. De tre forenede kræfterne for at beskrive en
ensartet objektorienteret softwareudviklingsmetode, efter at de hver for sig (samt flere
andre) havde arbejdet med flere metoder og teknikker inden for området. Deres fælles
arbejde resulterede også i beskrivelsessproget UML [UML].
UP er en iterativ metode, der overordnet er opdelt i fire faser:
• Forberedelse (Inception): En kort fase, der har til formål at få et overblik over
kravene til systemet.
• Etablering (Elaboration): En lidt længere fase, hvor man dels udvikler centrale
dele af systemet, dels får en dybere forståelse af systemets krav og arkitektur.
• Konstruktion (Construction): Den længste fase, hvor man udvikler de resterende
dele af systemet.
• Overdragelse (Transition): En afslutningsfase, der drejer sig om færdiggørelse og
overgang til drift.
De enkelte faser deler man op i en række iterationer. Hvor mange iterationer man skal lave i
de enkelte faser for at udvikle et konkret stykke software afhænger af hvor komplekst det er.
Figur 3, Eksempel på faser i RUP.
Metoden har følgende overordnede principper:
• Iterativ:
Udviklingen foregår i relativt korte iterationer, i hvilke der i varierende grad
(afhængig af, hvor langt man er i forløbet) indgår elementer af kravspecifikation,
analyse, design, implementering og test mm.
Version 1.4
side 13
•
•
•
•
Inkrementel:
Hver iteration giver (i princippet) en udvidelse af det færdige system.
Use case drevet:
Use cases er kernen i udviklingen og bruges under såvel analyse, design,
implementering som test. Hver iteration vil normalt handle om at foretage en
fuldstændig udvikling af en eller flere use cases.
Arkitektur-centreret:
En solid arkitektur opstilles tidligt i forløbet og er central for at opnå et godt
slutresultat.
Risikodrevet:
Risici identificeres tidligt i forløbet, og valget af, hvilke use cases man skal
koncentrere sig om i starten, foretages ud fra, hvor højt de scorer i risikovurdering
(eliminering af de største risici først)
3.2.4 Extreme Programming
Extreme Programming – egentlig eXtreme Programming med deraf følgende forkortelse
XP – er en forholdsvis ny udviklingsmetode til udvikling af software.
I midten af 1980'erne arbejdede de to systemudviklere Kent Beck og Ward Cunningham
sammen i en række projekter, og herfra stammer kernen i XP. Beck arbejdede videre med
tankerne og beskrev en række af de karakteristika, der senere skulle blive centrale i XP. Det
var dog først i midten af 1990'erne, at han for alvor beskrev metoden, og i 2000 udkom hans
bog [Beck2000], der betragtes som den vigtigste bog om XP.
Extreme Programming er en såkaldt agil metode, der er karakteriseret ved at være åben for
tilpasninger løbende i udviklingsprocessen. Brugernes ord er lov, og udviklerne skal altid
have brugernes prioritering af, hvilke del der skal udvikles næste gang, samt godkendelse
af, at det udviklede faktisk var det, de havde brug for.
Metoden har fire hovedprincipper:
• Kommunikation:
Brugere og udviklere skal konstant kommunikere om det kommende system
• Simpelhed:
Udviklerne skal til hver en tid kun skrive kode, der netop løser det aktuelle problem
– ikke prøve at forudse kommende behov
• Feedback:
Test er af afgørende betydning, idet det giver udviklerne svar på, om de har lavet det
rigtige
• Mod:
Der skal mod til at bryde med traditionelle tankemåder i systemudvikling, f.eks. at
der skal laves grundige kravspecifikationer
Extreme Programming opererer med tolv punkter ("core practices"), der beskriver den
ideelle arbejdspraksis i et XP-projekt:
1. Planlægning ("Planning game")
2. Små udgivelser med korte mellemrum
3. Systemmetafor
4. Simpelt design
5. Test
6. Hyppig refaktorering
7. Parprogrammering
Version 1.4
side 14
8. Fælles ejerskab til programkoden
9. Kontinuerlig integration
10. Overkommeligt arbejdstempo
11. Et samlet udviklingshold
12. Fælles kodestandard
Det understreges, at det ikke er tilrådeligt at vælge blandt disse tolv punkter, idet der opstår
en slags symbiose, når de anvendes samlet. Den metode der opstår ved anvendelse af denne
arbejdspraksis er nødvendigvis iterativ og inkrementel.
Læs mere på: http://www.extremeprogramming.org/
3.2.5 SCRUM
Scrum er en agil udviklingsmetode skabt i starten af 1990'erne, med meget fokus på
projektledelse.
Scrum tager udgangspunkt i, at udvikling af software kan være en kompliceret og
uforudsigelig proces, og er derfor snarere en form for kontrolleret black box frem for en
teoretisk proces. Scrum fastsætter ikke nogen retningslinjer for i hvilken rækkefølge
aktiviteterne skal implementeres. Et projekt kan derfor starte med en hvilken som helst
aktivitet, og skifte til en anden aktivitet på ethvert tidspunkt. Dette øger projektets
fleksibilitet og produktivitet.
Ordet Scrum er en term fra rugby og en forkortelse for 'scrummage' som betyder
skærmydsler.
Artefakter:
•
Produkt Backlog:
En samlingsplads for alle krav til systemet. Håndteres af systemets ejer (Product
Owner). Der er ingen begrænsning på hvor mange krav der må være. Til gengæld
benyttes prioritering. Jo højere prioritet, jo bedre specificeret skal kravene være.
•
Sprint Backlog
Den del af en Produkt Backlog som Scrum-gruppen påtager sig at implementere
under den kommende Sprint.
•
Sprint
Arbejdet inddeles i Sprints. Hvert sprint, som varer maksimalt 30 dage, indledes
med et møde (Sprint Planning) og afsluttes med en fremvisning af en ny version af
det kørende system, hvor de lovede ændringer indgår (Sprint Review).
Version 1.4
side 15
Figur 4, SCRUM model
Som introduktion til SCRUM kan det desuden anbefales at læse artiklen ”SCRUM in five
minutes” fra Softhouse, http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
Værktøjer:
•
Banana SCRUM, http://www.bananascrum.com/
Mangler tilsyneladende support for "issue/defect tracking" - og så alligevel ikke!
Man kan nemlig meget nemt indsætte fritekst-tags på alle tasks, så man kan i praksis
bare gøre sådan her:
1. Lav et tag til defects/issues - f.eks "Bug"
2. Når der observeres et problem, oprettes et task som bliver tagget med ”Bug”.
3. Det nye task indsættes i project backlog. Herfra kan det så flyttes over i en sprint
backlog når der arbejdes på problemet.
Demo:
http://www.codesprinters.com/uploads/videos/Banana_Good_2008-02-25_1539.swf
Online-demo:
http://demo.bananascrum.com/
•
ScrumWorks Basic(free edition), http://danube.com/scrumworks
Et omfattende værktøj med mange features.
3.3 IHA Udviklingsmodel
3.3.1 S-Model for styring
Iterative udviklingsmodeller anskueliggøres ofte vha. en spiral, hvilket stammer fra Barry
Boehms spiralmodel [Boehm88]. Dette gælder også for udviklingsmodellen ROPES –
Version 1.4
side 16
Rapid Object-oriented Process for Embedded Systems [Douglass99], der er en OO udgave
af en spiralmodel, der er specielt beregnet til udvikling af indlejrede systemer.
Figur 5, S-model for styring[SPUUML]
3.3.2 V-model for test
V-modellen giver en god illustration af forholdet mellem tidlig testforberedelse og de senere
testudførelse. Figur 2 viser hvorledes denne model også kan anvendes i forbindelse med
iterativ udvikling – her gentages V’et blot flere gange.
Version 1.4
side 17
Figur 6, V – model for test [SPUUML]
3.3.3 W-model for leverancer
W-modellen for leverancer er en model over de interne evalueringer samt de interne og
eksterne leverancer, der kan forekomme i en iterativ udviklingsmodel. Modellen er
beskrevet af Alistair Cockburn [Cockburn-W]. Den mindste iteration består i gennemførelse
af en V-model, der resulterer i en intern evaluering af et kørende delsystem. Efter et antal af
disse kan man have en mere formel og synlig ekstern leverance, der f.eks. kan anvendes til
pilottest og pilotforsøg med de rigtige brugere af systemet. Et antal af disse kan så
kombineres til en officiel ”release” af et produkt.
Figur 7, W-model for leverancer [SPUUML]
Version 1.4
side 18
3.3.4 U-model for udviklingsaktiviteter
U-modellen viser hvorledes de traditionelle udviklingsaktiviteter arbejder sammen med en
use case model, der specificerer de use cases systemet er opdelt i. U-modellen viser også
hvorledes man i næste iteration kan vende tilbage til en vilkårlig af de tidligere gennemførte
aktiviteter inklusiv kravspecifikationen.
Figur 8, U-model for udviklingsaktiviteter [SPUUML]
Version 1.4
side 19
4 Review
Reviewteknikken er den teknik der mest effektivt forbedrer kvaliteten af et givent produkt.
Et review gennemføres typisk på dokumenter, men kan også gennemføres på andet
materiale, f.eks. kode.
Der findes en vældig god beskrivelse af reviewteknikken i [SPU88].
5 Projektstyring
En projektstyringsmappe kan hjælpe gruppen med at samle information omkring projektet
et centralt sted. Derved kan alle projektdeltagere hele tiden følge projektet (f.eks. i
forbindelse med sygdom mm.). Projektstyringsmappen kan enten være en fysisk mappe,
eller kan oprettes elektronisk (f.eks. vha. Campusnet).
Indhold af Projektstyringsmappe:
- Projektdagbog
- Huskeliste
- Projektmødereferater
- Estimater og planer
- Statusrapporter
- Konfigurationsstyring
- Standarder
- Breve
- Tilbud / ordre / kontrakt
- Projektgrundlag
I forbindelse med projektstyring kan det anbefales at der udpeges:
• En projektleder (kan gå på skift).
Ansvar: Tidsplan følges, alle deltager aktivt, kan afgøre evt. tvistigheder.
• En referent (kan gå på skift)
Ansvar: Føre gruppens projektdagbog, løbende beskriver projektets forløb, og
udgiver status rapport (en gang om ugen!) til vejleder.
• En ansvarlig for kravspecifikation
• En ansvarlig for accepttestspecifikation/accepttest dokumentation
• En ansvarlig for designdokumentation
• En ansvarlig for integrationstestdokumentation
6 UML
Sidst i 1980’erne og første i 1990’erne blev der udviklet mange forskellige metoder inden
for Objekt Orienteret Analyse og Design. Hver guru sin metode og sin notation. De mest
anerkendte guruer/metoder inden for OOA&D i den periode var: Coad&Yourdon, Odell,
Wirfs-Brock, Shlaer/Mellor, Booch, Rumbaugh (OMT) og Jacobson.
I 1995 begynder 2 af de førende guruer, Grady Booch og James Rumbaugh, at arbejde på at
lave en fælles notation for deres metoder. De får senere selskab af Ivar Jacobson, og
sammen skaber de Unified Modelling Language – UML. Disse 3 ophavsmænd til UML
kaldes af nogle for: The Three Amigos
Version 1.4
side 20
UML beskriver en standard for diagrammer der kan anvendes indenfor udvikling og
dokumentation af systemer. UML er blevet accepteret af Object Management Group
(OMG) [UML] som en standard. OMG har revideret UML løbende.
For en introduktion til UML anbefales det at læse [UMLLIGHT].
Det er ofte en misforståelse at UML skal indeholde alle kodedetaljer. Faktisk kan UML
anvendes med forskellig detaljeringsgrader (perspektivering) alt efter hvad der ønskes
beskrevet i en given situation.
Der er typisk tale om 3 perspektiver:
• Konceptuel
Beskriver situationer i ”a real world” domæne (typisk domænemodeller).
• Design/Specifikation
Beskriver software abstraktioner og komponenter. Der medtages kun de detaljer der
er nødvendige for at kunne implementere. Det vil ofte være tilstrækkeligt med denne
perspektivering for at kunne kode.
• Implementering
Indeholder alle detaljer, og anvendes typisk i værktøjer der kan udføre
kodegenerering. Udviklere har en tendens til at bruge UML i denne perspektivering
uden at det er nødvendigt med dette detaljeringsniveau for at kunne implementere
systemet.
Der findes en række værktøjer der alle kan bruges til a udarbejde UML diagrammer med.
Eksempler på værktøjer:
• Visual Paradigm (IHA har licens)
Er et fint værktøj der tilbyder de nødvendige UML diagram typer
Kan hentes på: \\apps1.iha.dk\studapps (Kræver VPN forbindelse)
• Microsoft Visio (IHA har licens via Microsoft Office)
Et omfattende værktøj der kan være noget kompleks at anvende.
• Star UML (Open Source!)
• Ideogramic (IHA har licens), www.ideogramic.com
UML værktøj der supporterer whiteboard tegning af UML diagrammer. UML
modellerne tegnes på en whiteboard tavle med PC interface og en PC projektor.
Værktøjet kan også bruges direkte via PC. IHA versionen kan kun bruges på IHA
(testes via IP adresse!). Ideogramic kan bruges i lokale 424 og 512 på IHA (udenfor
undervisningstid). Begge lokaler er udstyret med whiteboard, whiteboard interface
(ToolTtribe), og computer projector.
• Raphsody (IHA har licens).
Et avanceret case værktøj med kodegenerering og model simulerings facilliter.
Rhapsody er dedikeret til modellering af realteids systemer. IHA har en University
license med 30 samtidige brugere.
Der er ofte den misforståelse at der ikke kan bruges klasse- og sekvensdiagrammer til
systemer der skal implementeres i C. Disse systemer kan sagtens modellers med klasse- og
sekvensdiagrammer, men kan selvfølgelig ikke implementeres med class, private og public
begreberne. Der gives i [UMLLIGHT] et glimrende eksempel på et minutur der modelleres
med klasse- og sekvensdiagrammer, og efterfølgende er vist implementeringen i
henholdsvis C og C++.
Version 1.4
side 21
7 Ordliste/forkortelser
TBD
Use case
To Be Defined
Kan oversættes til ”brugssituation”
8 Referencer
[Beck2000]
“Extreme Programming Explained: Embrace Change”, Kent Beck
Betragtes som den vigtigste bog om XP
Addison-Wesley Professional, 2000
[Boehm88]
”A Spiral Model of Software Development and Enhancement”, B.W. Boehm,
IEEE Computer, May 1988, pp. 61-72.
Artikel der beskriver spiralmodellen.
[Cockburn2000]:
”Writing Effective Use Cases”, Alistair Cockburn
En meget fin bog vedrørende beskrivelse af use cases samt niveauer for use
cases. Bogen tager dog udelukkende udgangspunkt i
systemudviklingseksempler fra adminstrative systemer.
Pearson Education, 2000.
[Cockburn-W]
“Using VW staging to clarify spiral development”, Alistair Cockburn,
http://alistair.cockburn.us/Using+VW+staging+to+clarify+spiral+development
Artikel der beskriver ideen i W-modellen.
[Douglass99]
”Real-Time UML, Second Edition Developing Efficient Objects for Embedded
Systems”, Bruce Powel Douglass
Beskriver en objektorienteret analyse- og designmetode for indlejrede
systemer, der er baseret på ROPES udviklingsmodellen (en spiralmodel).
Addison-Wesley, 1999.
[Krutchen85]
“Architectural Blueprints—The “4+1” ViewModel of Software Architecture”,
Philippe Kruchten
En fin artikel, der præsenterer en model for beskrivelse af et arkitekturdesign
ud fra et antal view, hvor hvert view har et bestemt formål og en bestemt
målgruppe.
IEEE Software, November 1995
[RobertCMartin]
Generel artikelsamling angående Objekt Orienteret Design, Robert C. Martin.
Der findes andre steder på hjemmesiden også en vældig god artikelsamling!
http://www.objectmentor.com/omSolutions/oops_what.html
[SPU88]
Version 1.4
”Håndbog i Struktureret Programudvikling”,
side 22
Stephen-Biering Sørensen, Finn Overgaard Hansen, Susanne Klim, Preben
Thalund Madsen, Teknisk Forlag, 1988.
[SPUUML]
”SPU – UML note, Systematisk Program Udvikling med UML”, Finn
Overgaard Hansen,
Opdateringsnote til "Håndbog i Struktureret ProgramUdvikling (SPU)" med
fokus på anvendelse af UML i forbindelse med objektorienteret
softwareudvikling.
Ingeniørhøjskolen i Århus, 2005
http://staff.iha.dk/foh/Foredrag/SPU-UML.pdf
[UML]
Unified Modeling Language, se www.uml.org. Nyeste version af UML kan
downloades fra ovenstående link.
[UMLLIGHT]
“UML-Light T133”, Finn Overgaard Hansen,
En note skrevet til programmeringsundervisningen og semesterprojekt på
IHA.
Ingeniørhøjskolen i Århus, 2004
Version 1.4
side 23

Doing gooD, thanks!

Transcription

Similar documents

København, 20-01-2014 Ansøgning om ingeniørpraktik

1 Hytterne 2 Hallen 3 Galleri Liisberg 4 Egeværk 5 Halsnæs

Denne studieordning er udarbejdet i henhold til

Legeakademietdk - legeakademietblog.dk

Curriculum vitae

CDIO DAG - ASE Medarbejdere

Hent magasinet som PDF

Facebook gruppen: Rustur AU-IHA

medl-2009 - Brande Historie

redskaber og planlægning af interne audits

For printvenlig version, klik her