Projekthåndbog E- og IKT projekter

Projekthåndbog E- og IKT projekter Ingeniørhøjskolen i Århus Michael Alrøe

Versionshistorie Ver. Dato Initialer Beskrivelse 1.0 12.01.2009 MA Første version beregnet for IHA semesterprojekter 1.1 20.01.2009 MA Revideret efter feedback fra FOH 1.2 29.01.2009 MA Beskrivelse af perspektiver for UML 1.3 03.02.2009 MA Indsat beskrivelse af Banana SCRUM fra SFK! 1.4 03.02.2009 MA 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, ma@iha.dk 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 Generelt... 4 2 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 3 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 4 Review... 20 5 Projektstyring... 20 6 UML... 20 7 Ordliste/forkortelser... 22 8 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 Use Case 1 System/ Produkt Use Case diagram 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