FORPROSJEKTRAPPORT. Prokap Prosjektstyringsverktøy for kapasitetsplanlegging. Brukernavn/passord: hio/ p35

Transkript

1 FORPROSJEKTRAPPORT PROKAP Prosjektstyringsverktøy for kapasitetsplanlegging Presentasjon Sted og dato Oslo, 29. januar 2010 Prosjektets tittel Prosjektnettside Prokap Prosjektstyringsverktøy for kapasitetsplanlegging Brukernavn/passord: hio/ p35 Gruppemedlemmer André Stenersen s (+47) Bjarte Aune Olsen s (+47) Christian Stråth s (+47) Henrik Holhjem s (+47) Veileder ved HiO Kontaktperson hos Accenture Prosjekteier/veileder hos Accenture Teknisk veileder hos Accenture Eva Vihovde (+47) Therese Børter (+47) Christian Bonne (+47) Jonas Lindholm (+47)

2 Side 2 av 12 Innholdsfortegnelse Presentasjon... 1 Innholdsfortegnelse... 2 Sammendrag... 3 Dagens situasjon... 3 Oppdragsgiver... 3 Eksisterende løsning... 3 Mål og rammebetingelser... 4 Metodikk... 4 Definition of done... 5 Arbeidsverktøy... 6 Avhengigheter... 6 Prosjektovervåkning... 6 Fremdriftsplan og milepæler... 7 Løsninger / alternativer... 7 Webapplikasjon... 7 Lokal applikasjon... 8 Analyse av virkninger... 8 Konklusjon Signaturer Begrepsforklaring... 12

3 Side 3 av 12 Sammendrag Prokap skal bli en applikasjon for å planlegge kapasitet på prosjekter. Det skal være raskt, enkelt og greit å bruke, samt tidsbesparende sammenlignet med eksisterende løsninger. Det skal kunne gi brukeren en god oversikt over alle medlemmene av et scrum-team og deres oppgaver i forskjellige iterasjoner. Det skal også kunne eksportere data som kan importeres til Excel for å lage statistikk og burndown-grafer. Applikasjonen kommer til å kjøres lokalt på maskinen. Den skal programmeres i Java med utviklingsverktøyet Eclipse. Databasen som benyttes er av typen db4o og GUI-rammeverket er SWT. Dagens situasjon Oppdragsgiver Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing. De leverer nyskapende løsninger og samarbeider med kundene, slik at kundene kan realisere sine visjoner og skape verdi for seg selv. Selskapet har omfattende bransjeekspertise, med globale ressurser og erfaring innenfor konsulentvirksomhet og driftsutsetting. I Norge har Accenture blant annet jobbet med store prosjekter som Altinn, Statens pensjonskasse, Trygdeetaten, Norsk Tipping og flere store prosjekter for Telenor. Med mer enn ansatte som bistår kunder i 120 land, hadde Accenture en omsetning på 23,39 milliarder dollar i regnskapsåret som ble avsluttet 31. august I Norge var omsetningen på 1,58 milliarder kroner i samme periode. Accentures hjemmeside: Eksisterende løsning Vår veileder og prosjekteier Christian Bonne og hans team jobber med store utviklingsprosjekter. Prosjektene er oppdelt i iterasjoner (arbeidssykluser) og i hver iterasjon må de ha nøyaktig oversikt over arbeidsbelastning på hver enkelt prosjektdeltaker for hver dag. De bruker per dags dato store Excel-ark til å holde oversikt over timer og personer, men dette er et veldig tungt og tidkrevende arbeidsverktøy. De ønsker seg derfor et lettere verktøy som håndterer oppgaven på en enkel og rask måte. Oppdragsgiver har prøvd andre store, kjente prosjekthåndteringsverktøy som for eksempel Microsoft Project. Slike verktøy er ikke tilpasset scrummetodikk, og de håndterer ikke oppgaven på en akseptabel måte.

4 Side 4 av 12 Mål og rammebetingelser Målet med prosjektet er å utvikle et nytt verktøy for å planlegge kapasitet på prosjekter. Det skal være raskt, enkelt og greit å bruke samt tidsbesparende i forhold til eksisterende løsninger. Produktet skal i første omgang brukes av prosjekteier Christian Bonne og hans team. De har fastsatt Java som utviklingsspråk, men er tydelige på at vi ellers skal bruke teknologier vi selv ønsker å jobbe med. Produktet skal: Være enkelt og raskt å installere og ta i bruk Kunne gi brukeren en god oversikt over alle medlemmene av et scrum-team og deres oppgaver i forskjellige iterasjoner Kunne eksportere data som kan importeres til Excel for å lage statistikk og burndown-grafer Produktet bør: Kunne rapportere data tallbasert og trendbasert (grafer) Ha muligheten til å skalere (flere brukere, flere prosjekter) Gruppen skal: Utvikle produktet i Java med Eclipse Jobbe etter scrum-metodikken, med Rally for administrasjon av produktkø Vi ble bedt om å gjøre en analyse, Proof of Concept (PoC), for å finne den best egnede teknologien til prosjektet. Vi har derfor i første iterasjon gjort en PoC som er definert og forklart senere i rapporten. Vi har fått tildelt arbeidsplasser ved Accentures lokaler på Fornebu, så vi har planlagt å jobbe der 1-2 dager i uken og på skolen 1-2 dager i uken. I tillegg vil det sannsynligvis bli noen møter hos Statens pensjonskasse på Majorstua, hvor prosjekteier Christian Bonne jobber på et prosjekt. Vi har planlagt å jobbe med prosjektet fast hver mandag, tirsdag og fredag, 24 timer per uke per person. Vi kommer til å bytte på å være scrum-master (se mer informasjon om scrum nedenfor), slik at alle får forsøkt å lede og organisere gruppen. Vi bytter scrum-master ved hver iterasjon. Metodikk Under utvikling av systemet benytter vi scrum etter ønske fra arbeidsgiver. Det er en voksende og veldig utbredt metodikk innen programvareutvikling. Scrum definerer et team (scrum-teamet) som selvdrevet og med store fullmakter til å nå definerte mål for programvareutviklingen. Prosjektet vårt gjennomføres i henhold til scrum i iterasjoner på to uker,

5 Side 5 av 12 også kalt en sprint. Teamet ledes av scrum-master. Scrum-master har som hovedoppgave å sørge for at det blir holdt daglige scrum-møter, samt at utviklingsgruppen har de beste mulige forhold og betingelser for å være effektive. I forkant av en sprint plukkes det ut et sett med funksjoner som skal implementeres fra en liste av gjeldende krav til prosjektets resultat. Denne kravlisten kalles produktkø. Listen av krav som skal implementeres i løpet av en gitt sprint kalles sprintkø. Typisk tar man elementer fra produktkøen og deler opp i mindre arbeidsoppgaver. Disse mindre arbeidsoppgavene havner i sprintkøen. I forkant av hver iterasjon skrives det en kontrakt mellom oppdragsgiver og scrum-team, et dokument som kort oppsummerer hvilke oppgaver som skal løses i løpet av iterasjonen. I etterkant av en iterasjon holder utviklingsgruppen en demo for prosjekteier og det avholdes et evalueringsmøte hvor resultatene fra den siste perioden sammenholdes med de krav som ble avtalt implementert i forkant. Dernest forplikter gruppen seg til å implementere et nytt sett med funksjonalitet fra produktkøen. Fordeler med scrum er at det er veldig enkelt å tilpasse seg endringer som måtte dukke opp underveis ved for eksempel endrede behov fra produkteier eller misforståelser. Kunden er mer involvert og ser underveis at applikasjonen tar form, funksjon for funksjon. Dette gjør at feil eller misforståelser raskt kan rettes opp. Når man bygger litt og litt av applikasjonen gjør man funksjonen ferdig i alle deler av applikasjonen slik at funksjonen som implementeres fungerer og kan vises fram. Dette gjør at når man kjører en halvferdig applikasjon fungerer alle funksjonene som er implementert i applikasjonen. Ulempen med scrum er at man ikke har mulighet til å fastsette krav og resultat på forhånd og dette gjør at denne forprosjektrapporten, samt arbeidsplanen, er veldig udefinert akkurat i konstruksjonsfasen. Definition of done Når vi på en iterasjon systematisk jobber oss gjennom sprintkøen med funksjoner som skal implementeres har vi et sett med krav som skal være fullført før vi ferdigstiller en oppgave og starter på neste. Disse kravene kaller vi definition of done (DoD). I dette prosjektet vil standard-dod være: Koden er utviklet Koden er kommentert Koden er testet Koden er dokumentert (JavaDoc, brukermanual, prosjektdagbok) Koden er sett over av en annen Denne standard-dod-en er en sjekkliste som vil gjelde for alle konstruksjonsoppgaver i prosjektet. For andre oppgaver defineres DoD for den spesifikke oppgaven. DoD beskrives i iterasjons-kontrakten for hvert punkt som ikke inngår i standard-dod-en. Da vet produkteier alltid hva han kan forvente seg når funksjonen er ferdigstilt.

6 Side 6 av 12 Arbeidsverktøy Alle gruppemedlemmene har fått låne hver sin bærbare PC fra Accenture med Windows Vista Enterprise og Microsoft Office 2007 installert. Applikasjonen vil bli utviklet i Eclipse ( et gratis program for Java-utvikling. Vi skriver rapporter og andre dokumenter i Microsoft Word, Excel og PowerPoint. Disse deler vi mellom gruppemedlemmene ved hjelp av Dropbox ( Dersom vi trenger å jobbe samtidig på et dokument, gjør vi det på Google Docs ( Accenture kommer til å sette opp en Subversion-server for oss (svn). Svn gjør at vi kan holde styre på alle versjoner av all kode vi skriver, slik at alle kan jobbe på applikasjonen samtidig uten å ødelegge for hverandre. For å laste opp filer til serveren bruker vi Eclipse innebygde plugin Subclipse ( og en svn-plugin for Windows, kalt TortoiseSVN ( Prosjektnettsiden ( settes opp med publiseringsløsningen WordPress ( og vil inneholde alle dokumenter vi produserer samt prosjektdagbok. Vi bruker scrum-verktøyet Rally ( for å holde oversikt over produktkøen. Avhengigheter For å kunne gjøre jobben vår, trenger vi tilgang til Testmiljø (applikasjons- og databaseserver, svn-server) Utviklingsmiljø (bærbar PC med Eclipse) Internett Prosjektovervåkning Scrum-master har ansvar for å holde oversikt over hva vi har påtatt oss å levere kunden i løpet av iterasjonen. Scrum-metodikken med stadige leveringer gjør at vi kontinuerlig vil revidere hva vi skal levere og hva oppdragsgiver ønsker. Vi kommer til å ha daglige scrum-møter hvor alle forteller hvordan de ligger an med sine oppgaver. På slutten av hver iterasjon (hver 2. uke) har vi demonstrasjon for oppdragsgiver. Hver uke har vi møte med veileder fra skolen.

7 Side 7 av 12 Fremdriftsplan og milepæler På prosjektets nettside ( legger vi ut oppdatert fremdriftsplan og arbeidsplan. I tillegg bruker vi scrum-verktøyet Rally ( for å holde oversikt over produktkøen. Løsninger / alternativer Oppdragsgiver hadde ikke klare meninger om teknologien vi skulle bruke til å lage applikasjonen, så i første iterasjon (iterasjon 0) av prosjektet satte vi opp to testsystemer for å finne den best egnede teknologien (proof of concept). Den viktigste forskjellen mellom de to testsystemene var at den ene var en webapplikasjon og den andre en lokal applikasjon. Webapplikasjon En webapplikasjon kjører på en applikasjonsserver. Brukeren bruker applikasjonen i en vanlig nettleser, som har kontakt med denne serveren (som kan stå på internett, et internt nettverk eller kjøre lokalt på PC-en). To forskjellige brukere kan i teorien ha tilgang til og redigere på de samme dataene. Webapplikasjonen vår ble satt opp med Spring Roo, som er et "rapid application" utviklingsverktøy for java-utviklere. Med Roo kan du enkelt bygge et fullstendig java-applikasjon i løpet av få minutter. Dette er veldig praktisk dersom du trenger å sette opp standardløsninger, som nettbutikk, nettforum, eller lignende, men kanskje ikke fullt så nyttig når man skal lage spesialtilpasset programvare slik som vår applikasjon. Roo bruker Maven, som er serverprogramvare for automatisert bygging av kildekode. GUI-et blir laget med rammeverket Spring MVC. Koden blir skrevet i Java, mens informasjonen som sendes til brukeren er ren HTML, som vises i nettleseren. Databasen er en MySQL-database (relasjonsdatabase) med Hibernate. Dette er en av de mest kjente åpen-kildekode-databasene som finnes og er mye brukt i dag. Hibernate er en teknologi for å gjøre om rader med informasjon fra databasen til objekter som kan håndteres av Java-koden, et såkalt objectrelational mapping (ORM) rammeverk. Applikasjonen kjøres i Tomcat. Tomcat er en beholder for Java-applikasjoner. Java-applikasjoner er ikke OS-spesifikke, de kan kjøres på hvilket som helst operativsystem, så lenge man har en beholder laget spesifikt for dette OS-et.

8 Side 8 av 12 Lokal applikasjon En lokal applikasjon installeres og kjøres lokalt på brukerens maskin. To kopier av applikasjonen har ingen kommunikasjon seg imellom, og kan inneholde totalt forskjellige data. Applikasjonen krever at man har installert en Java runtime for å kunne kjøres, noe alle Accentures PC-er har ferdig installert. GUI-et blir laget med GUI-rammeverket SWT. Dette rammeverket er utviklet av IBM og benytter seg av OS-ets egne biblioteker for GUI, slik at den ferdige applikasjonen ser ut som den er laget spesifikt for OSet brukeren har (altså vil den samme applikasjonen på en Windows-maskin se ut som en Windowsapplikasjonen, og på en Apple-maskin se ut som en Apple- applikasjonen). Databasen som brukes er en db4o-database (objekt-database). Her trengs ikke Hibernate, objektene opprettet i Java-koden lagres rett i databasen. Selve databasen er en fil lagret lokalt på disk, noe som gjør det enkelt å ta sikkerhetskopi. Analyse av virkninger I analysen av hvilken teknologi vi ville benytte oss av, satte vi opp en del målekriterier for å kunne sammenligne de tre systemene. Hvert kriterium fikk også en vekting, slik at kriterier vi og oppdragsgiver synes var viktige, veide tyngre enn kriterier vi synes var mindre viktige. Deretter ga vi hvert testsystem en karakter etter hvor godt det oppfylte hvert kriterium. Resultatet av denne analysen: Kriterier Total poengsum Enkel installasjon og oppstart for oss Enkel installasjon og oppstart for brukeren Enkelt å programmer e Enkelt å programmer Enkelt å e pent og programmer brukervennlig e mot DB GUI Enkelt med skalering: Flere brukere som vil bruke samme data Enkelt med skalering: Hva vi har Flere lyst til å brukere som jobbe med vil bruke sine og lære oss egne data Vekting Test-oppsett 1 Webapplikasjon, Spring ROO, MySQL, Spring MVC SUM Test-oppsett 2 Lokal applikasjon, db4o, SWT SUM Test-oppsett 3 Lokal applikasjon, db4o, Swing SUM

9 Side 9 av 12 Testoppsett 1 og 2 fikk begge høy score. Vi endte med å velge testoppsett 2 som det vi ville anbefale oppdragsgiver, men både testoppsett 1 og 2 var gode alternativer som begge sannsynligvis hadde vært mulige å bruke til å lage et godt sluttprodukt som hadde oppfylt kundens ønsker. Skjermdump fra testapplikasjon 2 Testoppsett 2 var en lokal applikasjon med db4o-database og SWT som GUI-rammeverk. Vi presenterte følgende argumenter til oppdragsgiver for hvorfor vi mente dette alternativet egnet seg best for den typen applikasjon de ønsket seg. Oppdragsgiver hadde spesifikt sagt at de ville at vi skulle jobbe med den teknologien vi hadde mest lyst til å lære oss: 1. Lære å lage en lokalapplikasjon Vi har mest erfaring med webapplikasjoner, og synes det høres spennende ut å forsøke å lage en lokal applikasjon. 2. Bruke og lære om nye teknologier: SWT og db4o Begge disse teknologiene virker spennende å jobbe med, og vi har lyst til å lære mer om dem. 3. Fint utseende (native) SWT er et rammeverk som benytter seg av operativsystemets GUI-rammeverk, og dermed ser applikasjonen mer profesjonell ut enn f.eks. med Swing, som har et hobby-preg over seg.

10 Side 10 av Raskt Applikasjonen kommer til å inneholde store mengder data som skal vises på én gang, og en lokal applikasjon kan oppdatere disse dataene raskere enn en webapplikasjon. 5. Enkelt å sikkerhetskopiere db4o er en database i en fil, slik at det er enkelt å ta sikkerhetskopi og operere med flere versjoner av databasen. 6. Kundens ønske Kunden sa på forhånd at de ønsket en lokal applikasjon, men at vi godt kunne gå for webapplikasjon dersom vi gjerne ville det. 7. Forståelig kode Siden vi lager applikasjonen fra bunnen av (i motsetning til med Spring Roo), har vi oversikt over hvordan koden er bygget opp. Koden blir ikke mer kompleks enn det som er nødvendig for å lage en god applikasjon. Jo mindre kompleksitet, jo lettere er det å unngå feil. 8. Enkelt for brukeren Applikasjonen blir veldig enkel å komme i gang med. Den kopieres til brukerens datamaskin, og så er det bare å sette i gang. Ingen brukernavn og passord, ingen tidkrevende installasjon, ingen server som man må sørge for er oppe og kjører. Konklusjon Etter analyse av alternative løsninger kan vi konkludere med at det lønner seg for oss å lage en lokal applikasjon med følgende teknologi db4o til database, Java til systemlaget og SWT til GUI-laget. Dette sikrer at vi får et enkelt og raskt system som går fort å installere og oppfyller alle oppdragsgivers krav. Systemet skal kun brukes av et fåtall brukere, men plattformuavhengighet og gratis teknologi er fortsatt gode fordeler. Db4o er en enkel database som lagrer objekter. Den har begrensninger, men passer perfekt til en lokalapplikasjon som dette. Både Java i systemlaget og SWT til GUI-laget er godt kjente, velutviklede og pålitelige teknologier. De er en god kombinasjon med et rikt antall eksempler tilgjengelig på internett. Med vårt ønske om å bruke ny teknologi og våre ambisjoner om å lage et best mulig produkt til kunden, passer denne løsningen veldig bra. Scrum-utviklingsmetoden er en populær og godt egnet metode som gir relevant erfaring til å senere jobbe i større prosjekter i næringslivet.

11 Side 11 av 12 Signaturer Forprosjektrapporten er forfattet av samtlige gruppemedlemmer. 29. januar 2010 André Stenersen Bjarte Aune Olsen Christian Stråth Henrik Holhjem

12 Side 12 av 12 Begrepsforklaring Db4o Objekt-orientert database som kan brukes i Java og.net. Objekter lagres direkte i databasen. Eclipse Et gratis utviklingsverktøy for å utvikle programmer i blant annet Java. GUI (graphical user interface) Brukes for å beskrive det grafiske laget i en applikasjon. Maven Serverprogramvare for automatisert bygging av kildekode. MVC (Model-view-controller) En applikasjon som oppretter en lagdelings struktur som brukes under utviklingen av en applikasjon. Dette gjør koden mer oversiktlig og hjelper til å holde oversikt under utviklingen av en applikasjon. MySQL SQL-basert databasesystem som er lisensiert under GPL. Denne databasetjeneren er veldig mye brukt, særlig i kombinasjon med en Linux internettserver. Proof of Concept En enkel applikasjon som lages for å teste ut en teknologi man ser for seg at man kan bruke i et større prosjekt. Scrum en prosjektledermetodikk som i hovedsak benyttes innenfor programvareutvikling. Scrum benyttes gjerne i kombinasjon med systemutviklingsmetoden Extreme Programming (XP), men kan i prinsippet enkelt integreres med alle iterative og inkrementelle systemutviklingsmetoder, f.eks. DSDM eller Rational Unified Process (RUP). Spring Roo er et nestegenerasjons "rapid application" utviklingsverktøy for java-utviklere. Med Roo kan du enkelt bygge et fullstendig javaprogram i løpet av minutter. SQL databasespråk som brukes til å hente ut, slette, legge til eller oppdatere data fra en server. Swing - et rammeverk før å lage GUI i Java. SWT (Standard Widget Toolkit) - et rammeverk for å lage GUI i Java.