Hovedprosjekt i informasjonsteknologi våren Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen

Transkript

1 Hovedprosjekt i informasjonsteknologi våren 2014 Oslo Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Fremdriftsplan Generelt om tidsberegning Som grunnlag for vår tidsberegninger har vi tatt for oss at hovedprosjektet for oss tilsvarer 20 studiepoeng som for oss er ⅔ av uken. Gitt at en arbeidsuke er 37,5 timer gir dette oss 25 arbeidstimer i uken hver til hovedprosjektet, totalt 75 arbeidstimer i uken. Fristen for levering av prosjektrapport er satt til 27. mai 2014 klokken For å gi oss selv rom for avvik og utarbeidelse av prosjektrapport setter vi som en tidsfrist for selve produktet til å være ferdig i løpet av uke 17 (med siste arbeidsdag fredag 25. april). Gruppen anser seg ferdig med planleggingsfasen i løpet av denne uken (uke 5, med siste arbeidsdag fredag 31. januar) da dette også skal presenteres for veileder denne uken. Dette gir oss fra og med første dag etter planleggingsfasen (mandag 3. februar, uke 6) frem til nevnte tidsfrist for produktet totalt 12 uker. Dette gir hele gruppen totalt 900 arbeidstimer samlet. Ettersom vi skal utføre enhetstesting av siden som er meget viktig, samt at en del dokumentasjon vil bli gjort i løpet av denne tiden anslår vi at ⅔ (66,67%) av tiden vil gå med på direkte koding og utvikling av produktet. Dermed sitter vi igjen med 600 timer til planlegging for den spesifikke tidsberegningen under. De resterende 300 timene vil gå til enhetstesting av systemet. Vi ser for oss at nevnte 25 timer per gruppemedlem fordeler seg på følgende måte i uken uten at selve tidspunktene er låst for alle uker. Dag Tidspunkt Timeantall Mandager 09:30 15:00 5,5 timer Tirsdager 08:30 15:00 6,5 timer Torsdager 08:30 15:00 6,5 timer Fredager 08:30 15:00 6,5 timer Totalt 25 timer

2 Grov tidsplan Tidsperiode Antall uker Antall arbeidstimer for hele gruppen Arbeidsoppgave 3. Februar 28.Mars Implementering med tidvis dokumentasjon om arbeidet underveis. 31.Mars 25.April Enhetstesting med dokumentasjon av testene som gjøres, samt eventuelle utbedringer basert på testresultater. 28.April 16.Mai Sette sammen og skrive ferdig dokumentasjon. 19.Mai 27. Mai 2.Juni 10. Juni* 1 uke og 2 dager 1 uke og 2 dager 105 Periode satt av til finskriving/dobbelsjekking og buffer periode om overnevnte perioder ikke holder tidsrammene. 105 Lage klar presentasjon av prosjektet. Totalt 1335 * Presentasjon i tidsrommet 10.Juni til 13.Juni

3 Om planning poker og krav Vi har tatt utgangspunkt i de funksjonelle kravene fra kravspesifikasjonen og listet disse opp i prioritert rekkefølge også innenfor hver enkelt prioriteringsgrad (A D). Vi regner med en feilmargin i tidsberegningen på 10% hvilket gir oss 540 timer å planlegge arbeid på. For å få et best mulig tidsestimat har vi benyttet os av planning poker hvor hver gruppemedlem hver for seg estimerte timer oppgaven ville ta. Videre setter vi ingen konkrete tidsestimater på de ikke funksjonelle kravene ettersom det er vanskelig å sette direkte tidsestimater på dette. Vi setter imidlertid av en arbeidsuke (75 timer) til å dekke dette strødd utover prosjektet. Ideelt er det da 465 timer som står igjen til skjemaet under. Setter videre opp en sprint (75 timer per sprint) ved endt sprint slik at vi har mulighet til å ta med punkter som ikke ble ferdig i sist sprint. Markerer sprintene med hver sin farge i tabellen nedenfor. Tidsberegning Tidsberegning (i hele timer) # PRI Krav Utdyping av krav E L S Snitt* #Sprint Herunder opprettes tilhørende databasedel for brukerhåndtering. Samt bestemme hashfunksjoner En bruker skal kunne logge og lagring av dette i 1 A inn database A 11 A Systemet skal analysere et PDF skjema for digital utfylling av felter. En kunde skal kunne være privatperson eller bedriftskunde En kunde skal ha en testing av pdftk og bash scripting for å få dette til å fungere strukur/modell på kunde og tilhørende databasedel for håndtering av bruker A kundestatus databasedel for roller og 6 A En bruker skal ha en rolle handlinger de forskjellige

4 32 A 7 A 10 A rollene skal ha tilgang på En bruker skal kunne endre passord En bruker skal ikke kunne utføre uautoriserte handlinger/operasjoner En bruker skal kunne legge til en kunde 13 A En kunde skal ha en profil 14 A 3 A 2 A 52 A 20 A 24 A 23 A En kundeprofil skal inneholde detaljer om kunden En bruker skal ha en profil som viser personalia En admin skal kunne legge til en ny bruker En bruker skal kunne opprette en kontrakt med en kunde En kontrakt skal ha en kontraktstatus En bruker skal kunne legge til en generell PDF mal En bruker skal kunne legge til PDF mal tilknyttet en Herhunder faller sikring på sider som begrenser synlighet/muligheter i henhold til hvilken rolle man har stuktur/modell for bruker og tilhørede databasedel for håndtering av kunde opprettelse av unik visningsside for hver kunde henting av kundeinformasjon fra databasen tilknyttet den spesifikke kunden en unik side for hver bruker og henting av informasjon fra databasen tilknyttet den spesifikke brukeren ** opprettelse av hendelser(actions) i databasen som tilegnes adminbruker struktur/modell av kontrakten samt databasedel for håndtering av kontrakter database del for å endre kundestatus opplasting av PDF filer som analyseres. Databasedel for maler og lagring av felter opplasting av PDF filer og database **

5 27 A 18 A 19 A 28 A 4 A 15 A 29 A 31 A 30 A kunde del som knytter denne malen til en spesifikk kunde databasedel for logging av hendelser, samt en generell loggedel som blir Systemet skal logge kalt hver kan det gjøres hendelser gjort på bruker ogendringer i systemet for å av hvem sikre at alt blir logget En kontrakt skal kunne inneholde en utfylt versjon av malene. En kontrakt skal kunne inneholde vedlegg Systemet skal logge hendelser gjort på kunde og av hvem Brukerprofilen skal vise hendelseslogg for brukeren En kundeprofil skal vise hendelsesloggen for kunden funksjonalitet for å laste opp riktige maler og klargjøre disse for utfylling ** funksjonalitet for opplasting av statiske vedlegg som skal tilhøre kontrakten, men ikke editeres. Databasedel for dette må også implementeres databasedel for kundespesifikke logger Herunder listing av logg tilknyttet spesfikk bruker Herunder av logg tilknyttet speslisting fikk kunde Systemet skal kombinere kundeinformasjon og generere opp en eller flere automatisk utfylling av de feltene i PDF dokumenter, basert på malen som allerede er denne informasjonen lagret i databasen ** En bruker skal kunne velge det visuelle kontrakttype ved opprettelsebrukergrensesnittet ved av kontrakt opprettelse av kontrakten Systemet skal filtrere ut hvilke PDF maler som skal fylles ut avhengig av handlingen som velges det å sette paramentre for kontrakten som videre benyttes til å analysere hvilke dokumenter som trengs i kontrakttypen og vise disse

6 8 A 9 A 5 A 17 A 21 A 34 A 36 A 22 A Systemet skal forhindre uautorisert tilgang til kundeinformasjon Systemet skal forhindre uautorisert tilgang til kontrakter og vedlegg En admin skal kunne endre på brukerpersonalia og rolle En kundeprofil skal vise de funksjoner innlogget bruker har i henhold til tilgangsnivåer. En kontrakt som er signert skal ikke kunne endres. Systemet skal lagre ferdige PDF i et arkiv Systemet skal kunne printe ut ferdige PDF En signatur skal ikke kunne gjenbrukes på fler kontrakter aksessliste for kundeforholdet i tillegg til hvilke handlinger man har tilgang på. Dette gjelder modellering og database del både for aksessliste og handlinger man kan utføre på en kunde sikker lagring av dokumentene og en funksjon all visning går gjennom som alle sikkerhetsmekanismer blir gjennomgått før visning funksjonalitet for å hente ut rolleinformasjon og endre handlinger roller har visning av valg basert på tilgangsnivåer samt hindring av "url injection" sikkerhetsmekanismer som sikrer at en kontrakt ikke kan endres når den først er signert sikker lagring av ferdige kontrakter Herunder printing av alle dokumenter som faller under kontrakten, utfylte maler så vel som vedlegg og kopi av legitimasjon sikkerhetsmekanismer som knytter signatur mot en enkelt kontrakt og ikke kan misbrukes til bruk på andre kontrakter for

7 16 A 53 A 33 A 35 A 38 A 25 A 54 A 56 A 57 A En kundeprofil viser alle kontrakter og maler tilhørende kunden samme kunde søking i databasen etter kundespesifikke maler og liste disse opp Systemet skal kunne søke databasespørringer som etter kunder/prosjekter etter endres i henhold til de valg gitte kriterier brukeren setter på søket Systemet skal bruke SSL kryptering i all interaksjon med bruker Systemet skal tilby muligheten å laste ned alle dokumentene knyttet til en kunde Systemet skal kunne sende mail til kunden nå er kontrakt er laget med kunden En bruker skal kunne oppdatere malversjon En bruker med tilgang skal kunne redigere tilgang til kunde En bruker skal bli blokkert etter x antall feilinnlogginger En bruker skal kunne få et midlertidig passord på mail kartlegging om muligheter på nåværende webhotell for å få en sikker https overføring av filer og informasjon slik at dette ikke overføres i klartekst Herunder listing av kundens kontrakter og mulighet til å laste ned dette som en "kundeprofil" i zip eller lignende Herunder funksjonalitet om å sende ut mail når en kontrakt er signert som en slags kvittering ** Herunder funksjonalitet for å bytte ut eksisterende mal om det er gjort endringer i den Herunder funksjonalitet for å endre aksesslister tilknyttet en kunde slik at andre bruker får nye rettigheter Herunder en sperre for innlogging for å forhindre "brute force attack" på systemet Herunder mailfunksjonalitet som sender ut et generert passord som fungerer i et døgn

8 40 B 41 B 55 B 39 B En bruker skal kunne legge til manuelle oppføringer i kundelogg Systemet skal tilby kategorier for manuelle oppføringer En admin skal kunne redigere roller En bruker skal kunne redigere egen profil Herunder manuelle oppføringer i loggen slik at systemet kan benyttes til logging av samtaler/ notiser som ønskes lagret mot kunden Herunder valg som telefon/epost /merknad tilknyttet manuelle oppføringer Herunder endring og etablering av nye roller og hvilke muligheter disse rollene skal ha Åpner for at bruker kan endre egen profil, ikke bare admin Tot funksjonelle krav 468 Ikke funksjonelle krav 75 Totalt alle krav 543 * Nærmeste hele time ** Har blitt overført videre til annen sprint. Nærmere spesifisering kommer frem i avsnittet om oppsummering av sprinter nedenfor. Om sprintene Etter endt sprint på Fredager oppsummerer vi sprinten og fyller ut skjemaet nedenfor både for nylig tilbakelagt sprint, samt planlegger neste ukes sprint. Vedplanlegging av sprint legges også sprinten med tilhørende oppgaver inn på scrumbrettet hvor oppgavene deles mellom gruppemedlemmene. Mer spesifikk fremgang fremkommer kun på Trello (Scrumbrett Implementering). Fargekodene som benyttes her går igjen på Trello slik at man enkelt kan bruke denne fremdriftsplanen mot Trello. For å dokumentere fremdrift i Scrumbrettet tar vi skjermbilder av scrumbrette i midten av hver sprint med unntak av kolonnen Ferdig. implementering (Krever innlogging og tilgang)

9 Sprinter # Antall timer* Ukenr Oppsummering Prosent ferdig Timer overført til neste sprint 1 70,0 6 Gruppen har dekket alle punktene i sprinten, samt gjort innlendende arbeid på oppgaver/krav som ikke var en del av sprinten. Velger av den grunn å ha et noe større timeantall på kommende sprint ettersom deler av kravene er påbegynte. På dette stadiet har vi en kjørende prototype med meget begrenset funksjonalitet Gruppen utfører alle punktene i sprinten, men det gjenstår et par underpunkter på det ene kortet tilknyttet brukers profil.(#3) Overfører derfor 5 timer til neste sprint Gruppen utfører alle planlagte krav med unntak av to krav, #23 som er planlagt for 4 timer samt krav #18 planlagt for 6 timer. Sistnevnte krav flyttet da kravet avhenger av andre deler som ikke er på plass. Begge flyttet til neste sprint. 100% 0 94,73% 5 ** 86,67% 10** Gruppen utfører de fleste av punktene satt av til denne sprinten. Et av kravene i denne sprinten, #29, ble i midlertid en del vanskeligere enn først anslått i tidsestimeringen. Punktet vil ha en estimert tid ytterligere legger til 10 timer på dette punktet. Disse ytterligere timene må derfor overføres til neste sprint. Det andre punktet som ikke ble fullført i denne sprinten er #18, dette punktet er dirkekte avhengig av #29, og er derfor ikke påbegynt i det hele tatt. Dette punktet må overføres i sin helhet til neste sprint. 79,22% 16**

10 Gruppen utfører alle punkter, også krav #18 selv om vi ikke har fått testet dette ettersom det ikke kan bli gjørt før krav #29 er ferdig. Punkt #29 er fortsatt ikke ferdigstilt ettersom vi har møtt på komplikasjoner med gjenbruk av kode for dette punktet. Skal ha møte med oppdragsgiver for å få avklart spørsmål tilknyttet dette kravet. Må derfor legge til ytterligere 10 timer for å dekke dette kravet i neste sprint. Planlegger neste sprint med 8 timer mindre enn en planlagt sprint for å jobbe mer med å ferdigstille en prototype til oppdragsgiver Gruppen utfører alle krav satt. Også krav #29 som har blitt overført over flere sprinter. I tillegg blir et testmiljø satt opp riktig for en prototype som oppdragsgiver kan aksessere for å se konkret fremdrift. I tillegg testet vi fremgangsmåten for å kryptere overføringer i systemet ved hjelp av SSL teknologi, slik at dette er kjent ved levering til oppdragsgivers servermiljø. 85,92% 10** 100% Gruppen utfører alle krav i sprinten, med unntak av #38 som etter et kort møte med oppdragsgiver også vil dekke mail til samarbeidspartnere i tillegg til kunden. Avventer maler fra oppdragsgiver før dette kan ferdigstilles, og overfører 5 timer til neste sprint. Til kommende sprint er alle krav B krav. Imidlertid er mange av disse kravene påbegynt i forbindelse med tidligere krav, men ettersom sprint 8 blir siste planlagte arbeidsuke med selve produktet, gjenstår mye arbeid med å ferdigstille alle funksjoner og sy sammen produktet til en helhet før testingen 93,67% 5**

11 kan starte neste uke Gruppen gjør ferdig de resterende krav satt. Er imidlertid noe mindre funksjonalitet som gjenstår som vi tar sikte på å ordne i forbindelse med testingen og bufferperioden satt av til Mai. Herunder: Laste opp utfylt utgave av vedlegg. Kontonummer på kunder. Unik XFDF fil for hver bruker. Kalender på kunder. Logge hendelser Mindre oppgaver i hver enkelts To do kort Oppsett av tjenester på oppdragsgivers miljøer. (Mail, webserver, SSL) 100% * Sum av timesnitt fra fargemarkerte krav pluss eventuelle timer overført fra foregående sprint, i tillegg til del av ikke funksjonelle krav (75/8 10) ** Timer overført til neste sprint illustreres både i dette skjemaet og på Trello med rød farge i tillegg til original sprintfarge.

12 Skjermdump av sprinter Figur 1: Scrumbrett per kun med oppstartsfasen Figur 2:Scrumbrett per Sprint 1 ferdig, og Sprint 2 planlagt for kommende uke

13 Figur 3:Scrumbrett per Sprint 2 ferdig, og Sprint 3 planlagt for kommende uke Figur 4:Scrumbrett per Sprint 3 ferdig, og Sprint 4 planlagt for kommende uke

14 Figur 5:Scrumbrett per Sprint 4 ferdig, og Sprint 5 planlagt for kommende uke Figur 6:Scrumbrett per Sprint 5 ferdig, og Sprint 6 planlagt for kommende uke

15 Figur 7:Scrumbrett per Sprint 6 ferdig, og Sprint 7 planlagt for kommende uke Figur 8:Scrumbrett per Sprint 7 ferdig, og Sprint 8 planlagt for kommende uke

16 Figur 9:Scrumbrett per Sprint 8 ferdig. Sprintbrett ferdig.