KRAVSPESIFIKASJON v.1.2

Transkript

1 KRAVSPESIFIKASJON v.1.2 PROKAP Prosjektstyringsverktøy for kapasitetsplanlegging G r u p p e 2 6 A n d r é S t e n e r s e n B j a r t e A u n e O l s e n C h r i s t i a n S t r å t h H e n r i k H o l h j e m

2 Side 2 av 10 1 Innledning I denne innledningen tar vi i korte trekk for oss hva prosjektet går ut på, hvem oppdragsgiveren er og bakgrunn og mål for oppgaven. 1.1 Prosjektet Prokap er et hovedprosjekt for fire datastudenter ved Høgskolen i Oslo. Vi skal lage applikasjonen Prokap som er et prosjektsyringsverktøy for kapasitetsplanlegging av utviklingsprosjekter. Det skal brukes av Christian Bonne og hans team hos Accenture for å lette planleggingsfasen på store Scrumprosjekter. Prokap skal forenkle planleggingsfasen der man deler inn hvilke oppgaver en prosjektdeltaker skal jobbe med og hvor mye på hver oppgave. Vi skal løse oppgaven ved å lage en lokal applikasjon i Java. Vi kommer til å bruke diverse teknologier gruppen ikke er kjent med fra før, blant annet GUI-rammeverket SWT, applikasjonsrammeverket Rich Client Platform (RCP), databasen db4o og prosjektrammeverket Maven. 1.2 Oppdragsgiver og kunde 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. Accenture stiller med 4 veiledere til prosjektet. Christian Bonne som produkteier og en av dem som skal bruke produktet i etterkant sammen med Øyvind Hellang. Christian og Øyvind kommer med ønsker og forslag til hvordan produktet skal utformes og tilpasses for optimalt bruk. I tillegg er Jonas Lindholm teknisk hovedveileder og Ingleiv Johansen som ekstra teknisk veileder. Accenture er oppdragsgiver og vil overta prosjektet etter levering. 1.3 Bakgrunn for prosjektet Vår veileder og prosjekteier Christian Bonne og hans team jobber med store utviklingsprosjekter. Prosjektene er oppdelt i iterasjoner (arbeidssykluser) etter Scrum-metoden 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

3 Side 3 av 10 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 ut i fra oppdragsgiver ønske håndteres ikke oppgaven på en akseptabel måte. 1.4 Mål for oppgaven 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. Verktøyet skal også ha ekstra funksjoner som at man enkelt kan endre ferie/fravær og eksportere alt av data til Excel for enkelt å bruke dataene i andre sammenhenger. 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) Rammene vi fikk fra prosjekteier var bruk av Java i systemlaget, men at GUI-lag og valget mellom lokalog webapplikasjon var opp til oss. Etter en «Proof of Concept» (PoC), hvor vi satte opp to testsystemer, konkluderte vi med at den beste løsningen for prosjektet var en lokal applikasjon med GUI-rammeverket SWT. For mer informasjon om PoC henvises det til avsnitt 6, Løsninger / alternativer i forprosjektrapporten. 2 Forord en skal gi oppdragsgiver og utviklere en felles forståelse og enighet av produktet som skal utvikles, samt en definisjon av rammer og begrensninger. I starten av prosjektet fikk vi en kravspesifikasjon fra oppdragsgiver. Denne har vi gått gjennom og utvidet litt i samarbeid med oppdragsgiver. en er utformet som use cases i tråd med Scrum-metodikk. en fungerer under hele prosjektperioden som et styringsdokument. en er ikke fastlåst, men blir oppdatert en liten stund framover. Grunnen til dette er at man i Scrum jobber tett med oppdragsgiver for å sikre at oppdragsgiver får akkurat det produktet han ønsker. Da kan det dukke opp endringer og omprioriteringer raskt.

4 Side 4 av 10 3 Innholdsfortegnelse 1 Innledning Prosjektet Oppdragsgiver og kunde Bakgrunn for prosjektet Mål for oppgaven Forord Innholdsfortegnelse Funksjonalitet Funksjonelle krav... 5 Krav Prioritet Ikke-funksjonelle krav... 6 Krav Prioritet Dokumentasjon Dokumentasjon av applikasjonen Dokumentasjon av prosjekt Internasjonalisering/språkbruk Oppdragsgivers tekniske krav Teknisk Automatisert testing Design Krav til kode Mulige utvidelser Verktøy Utviklerverktøy Eksterne Java-biblioteker Signaturer Utviklerteam Prosjekteier... 10

5 Side 5 av 10 4 Funksjonalitet Dette avsnittet tar for seg de funksjonelle og ikke-funksjonelle kravene til applikasjonen Prokap. 4.1 Funksjonelle krav Funksjonelle krav blir beskrevet ut i fra behov om funksjonalitet i applikasjonen. Kravene definerer spesifikt hva en bruker skal kunne bruke applikasjonen til. Krav Prioritet En bruker skal kunne lagre data opprette en ny database åpne en eksisterende database lagre til en eksisterende database velge hvilken database som skal åpnes se og endre opplysninger om alle personer i systemet se en liste over alle personer og hvilke oppgaver de er knyttet til se opplysningene om en person enkelt endre hvilken person han ser opplysningene til legge inn nye, endre og slette personer knytte en person til en oppgave (med start- og slutt-dato og arbeidsprosent). Systemet skal automatisk beregne timeantall på andre oppgaver i samme tidsrom på nytt hindres i å knytte en person til flere drivende oppgaver i samme tidsrom kunne hoppe direkte til en dato ved å klikke på en kalender Lav se og endre opplysninger om alle oppgaver i systemet se en liste over alle oppgaver og hvilke personer som er tilknyttet hver oppgave se alle opplysningene om en oppgave enkelt endre hvilken oppgave han ser opplysningene til legge inn nye oppgaver og endre og slette eksisterende oppgaver sette oppgaver som «drivende». Drivende oppgaver får automatisk alle personens arbeidstimer som ikke er spesifisert brukt på andre oppgaver endre en persons deltagelse på en oppgave (med start- og slutt-dato og arbeidsprosent). Systemet skal automatisk beregne timeantall på andre oppgaver i samme tidsrom på nytt hindres i å sette en oppgave som «drivende» når en av personene som er tilknyttet oppgaven allerede har en annen drivende oppgave i samme tidsrom kunne hoppe direkte til en dato ved å klikke på en kalender Lav

6 Side 6 av 10 se og endre opplysninger om alle team i systemet se liste over alle team se opplysningene om et team legge inn nye team og endre og slette eksisterende team se og endre opplysninger om ferieavvikling se en oversikt over alle personene og når de er på ferie, hvor forskjellige fraværstyper har forskjellige fargekoder legge inn ferie, kursdager og annet fravær for en person. Systemet skal automatisk sette timeantall til 0 på alle personens oppgaver på feriedagen legge inn fellesferie for alle personer (17. mai, 1. juledag, etc.). Systemet skal automatisk sette timeantall til 0 på alle oppgaver på feriedagen kunne hoppe direkte til en dato ved å klikke på en kalender Lav hente ut rapporter eksportere oversikt per person og oversikt per oppgave til Excel som kommaseparerte verdier eksportere fraværsoversikt til Excel som kommaseparerte verdier 4.2 Ikke-funksjonelle krav Ikke-funksjonelle krav definerer hvordan applikasjonen skal oppføre seg og hvilke egenskaper applikasjonen har. Krav Prioritet Systemet skal starte opp på maksimalt 15 sekunder med tom database starte opp på maksimalt 30 sekunder med eksisterende database respondere på maksimalt 1 sekund ved endring av prosentsats eller dato for en oppgave eller person være en lokal applikasjon

7 Side 7 av 10 5 Dokumentasjon Dette avsnittet tar for seg hvordan prosjektet og resultatet dokumenteres. 5.1 Dokumentasjon av applikasjonen Det vil følge brukerdokumentasjon sammen med applikasjonen. Denne dokumentasjonen skal kunne åpnes fra applikasjonens meny. Dokumentasjonen er ment for brukere av applikasjonen. I brukerdokumentasjonen vil det være en bildeguide av de mest brukte funksjonene. Koden dokumenteres med JavaDoc, som vil gi en oversikt over hvilke klasser og metoder applikasjonen inneholder, og hvordan de fungerer. Denne dokumentasjonen er påberegnet utviklere for å forstå hvordan applikasjonen fungerer. 5.2 Dokumentasjon av prosjekt Prosessrapport som tar for seg prosessen i sin helhet. Produktrapport som tar for seg produktet i sin helhet. Prosjektlogg på hjemmesiden: (brukernavn/passord: hio/p35) 6 Internasjonalisering/språkbruk Språket igjennom hele applikasjonen er engelsk Datoformatet er norsk: dd-mm-åååå (for eksempel ). Grunnen til norsk datoformat er fordi sluttdokumentasjonen er på norsk. 7 Oppdragsgivers tekniske krav 7.1 Teknisk Den ferdige applikasjonen leveres som en kjørbar programfil. Det kreves at Java JRE 6 er installert for å kjøre applikasjonen. Applikasjonen skal løse oppgaven på en bedre og raskere måte enn den gamle løsningen.

8 Side 8 av Automatisert testing Automatiske JUnit-tester skal implementeres for alle metoder på forretningslogikklaget (Business Logic Layer, BLL) 8 Design Lettfattelig, oversiktlig og brukervennlig brukergrensesnitt Lyst og pent utseende Fokus på skjermutnyttelse og størst mulig plass til tabellen God kontrast 9 Krav til kode Engelsk kode, variabler, metoder, kommentering Beskrivende navn på variabler og metoder Definition of done o Koden er utviklet o Koden er testet (hvis i BLL-laget) o Koden er dokumentert med JavaDoc (hvis offentlig metode) o Koden er sett over av en annen (både format og funksjonalitet) 10 Mulige utvidelser Mulighet til flere prosjekter Flerbrukerløsning (brukerkontoer) Opptegning av burndown-graf i applikasjonen (i stedet for eksportering til Excel) Skrive ut data rett fra applikasjonen (i stedet for eksportering til Excel) Historikk Flere språk Endre farger (temaer)

9 Side 9 av Verktøy 11.1 Utviklerverktøy Eclipse (skrive Java-kode) Subversion (SVN, versjonskontroll) Subclipse (plugin til Eclipse for opplasting til SVN-server) Microsoft Visio (for å tegne modeller) Maven (byggeverktøy og generelt prosjektrammeverk) 11.2 Eksterne Java-biblioteker SWT (GUI-rammeverk) Db4o (database)

10 Side 10 av Signaturer Dato: 23. februar Utviklerteam André Stenersen Bjarte Aune Olsen Christian Stråth Henrik Holhjem 12.2 Prosjekteier Christian Bonne