1. No category

Hovedprosjekt i informasjonsteknologi våren 2014
Oslo 28.03.2014
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 12.00. 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
Grov tidsplan
Tidsperiode
Antall uker
Antall arbeidstimer for hele gruppen
Arbeidsoppgave
3. Februar ­ 28.Mars
8
600
Implementering med tidvis dokumentasjon om arbeidet underveis.
31.Mars ­ 25.April
4
300
Enhetstesting med dokumentasjon av testene som gjøres, samt eventuelle utbedringer basert på testresultater.
28.April ­ 16.Mai
3
225
Sette sammen og skrive ferdig dokumentasjon.
19.Mai ­ 27. Mai
1 uke og 2 dager
105
Periode satt av til finskriving/dobbelsjekking og “buffer”­periode om overnevnte perioder ikke holder tidsrammene.
2.Juni ­ 10. Juni*
1 uke og 2 dager
105
Lage klar presentasjon av prosjektet.
Totalt
1335
* Presentasjon i tidsrommet 10.Juni til 13.Juni
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
1
A
26 A
11 A
12 A
6
A
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 inn
database
15 12 18
15
Systemet skal analysere et Herunder faller testing av PDF­skjema for digital pdftk og bash­scripting for utfylling av felter.
å få dette til å fungere
20 25 25
23
Herunder faller En kunde skal kunne være strukur/modell på kunde og
privatperson eller tilhørende databasedel for bedriftskunde
håndtering av bruker
7 8 5
7
En kunde skal ha en kundestatus
2 3 2
2
Herunder faller databasedel for roller og En bruker skal ha en rolle handlinger de forskjellige 5 5 5
5
rollene skal ha tilgang på
32 A
7
A
10 A
13 A
14 A
3
A
2
A
52 A
20 A
24 A
23 A
En bruker skal kunne endre passord
Herhunder faller sikring på sider som begrenser En bruker skal ikke kunne synlighet/muligheter i utføre uautoriserte henhold til hvilken rolle handlinger/operasjoner
man har
Herunder faller stuktur/modell for bruker En bruker skal kunne legge og tilhørede databasedel til en kunde
for håndtering av kunde
Herunder faller opprettelse av unik visningsside for En kunde skal ha en profil hver kunde
Herunder faller henting av En kundeprofil skal kundeinformasjon fra inneholde detaljer om databasen tilknyttet den kunden
spesifikke kunden
Herunder faller en unik side
for hver bruker og henting av informasjon fra En bruker skal ha en profil databasen tilknyttet den som viser personalia
spesifikke brukeren
Herunder faller opprettelse av hendelser(actions) i En admin skal kunne legge databasen som tilegnes til en ny bruker
adminbruker
Herunder faller struktur/modell av En bruker skal kunne kontrakten samt opprette en kontrakt med en databasedel for håndtering kunde
av kontrakter
En kontrakt skal ha en Herunder faller database kontraktstatus
del for å endre kundestatus
Herunder faller opplasting av PDF­filer som analyseres. Databasedel En bruker skal kunne legge for maler og lagring av til en generell PDF­mal
felter
En bruker skal kunne legge Herunder faller opplasting til PDF­mal tilknyttet en av PDF­filer og database 7
9
8
8
12 15 15
14
15 12 12
13
8
9 10
9
2
2
2
2
8
8 10
9
14 15 15
15
20 24 25
23
3
4
4
20 25 25
23
5
5
2
4
4
**
**
kunde
27 A
18 A
19 A
28 A
4
A
15 A
29 A
31 A
30 A
del som knytter denne malen til en spesifikk kunde
Herunder faller databasedel for logging av hendelser, samt en generell loggedel som blir Systemet skal logge kalt hver kan det gjøres hendelser gjort på bruker og endringer i systemet for å av hvem
sikre at alt blir logget
15 8 10
Herunder faller En kontrakt skal kunne funksjonalitet for å laste inneholde en utfylt versjon opp riktige maler og av malene.
klargjøre disse for utfylling
7 5 5
Herunder faller funksjonalitet for opplasting
av statiske vedlegg som skal tilhøre kontrakten, men ikke editeres. En kontrakt skal kunne Databasedel for dette må inneholde vedlegg
også implementeres
4 5 4
Systemet skal logge Herunder faller hendelser gjort på kunde og databasedel for av hvem
kundespesifikke logger
10 7 8
Brukerprofilen skal vise Herunder listing av logg hendelseslogg for brukeren tilknyttet spesfikk bruker
5 2 4
En kundeprofil skal vise Herunder av logg tilknyttet hendelsesloggen for kunden speslisting fikk kunde
3 2 2
Systemet skal kombinere kundeinformasjon og Herunder faller automatisk generere opp en eller flere utfylling av de feltene i PDF­dokumenter, basert på malen som allerede er denne informasjonen
lagret i databasen
15 17 20
En bruker skal kunne velge Herunder faller det visuelle kontrakttype ved opprettelse brukergrensesnittet ved av kontrakt
opprettelse av kontrakten
8 6 5
Herunder faller det å sette paramentre for kontrakten Systemet skal filtrere ut som videre benyttes til å hvilke PDF­maler som skal analysere hvilke fylles ut avhengig av dokumenter som trengs i handlingen som velges
kontrakttypen og vise disse 8 6 5
11
6
**
4
8
4
2
17
6
6
**
8
A
9
A
5
A
17 A
21 A
34 A
36 A
22 A
Herunder faller aksessliste for kundeforholdet i tillegg til hvilke handlinger man har tilgang på. Dette gjelder modellering og database del både for Systemet skal forhindre aksessliste og handlinger uautorisert tilgang til man kan utføre på en kundeinformasjon
kunde.
20 25 20
Herunder faller sikker lagring av dokumentene og
en funksjon all visning går Systemet skal forhindre gjennom som alle uautorisert tilgang til sikkerhetsmekanismer blir kontrakter og vedlegg
gjennomgått før visning
10 5 5
Herunder faller funksjonalitet for å hente ut
En admin skal kunne endre rolleinformasjon og endre på brukerpersonalia og rolle handlinger roller har
5 4 4
En kundeprofil skal vise de Herunder faller visning av funksjoner innlogget bruker valg basert på har i henhold til tilgangsnivåer samt tilgangsnivåer.
hindring av "url­injection"
8 5 6
Herunder faller sikkerhetsmekanismer som sikrer at en kontrakt En kontrakt som er signert ikke kan endres når den skal ikke kunne endres.
først er signert
5 1 3
Herunder faller sikker Systemet skal lagre ferdige lagring av ferdige PDF i et arkiv
kontrakter
5 3 3
Herunder printing av alle dokumenter som faller under kontrakten, utfylte Systemet skal kunne printe maler så vel som vedlegg ut ferdige PDF
og kopi av legitimasjon
5 2 4
Herunder faller sikkerhetsmekanismer som knytter signatur mot En signatur skal ikke kunne en enkelt kontrakt og ikke gjenbrukes på fler kan misbrukes til bruk på kontrakter
andre kontrakter for 5 4 5
22
7
4
6
3
4
4
5
16 A
53 A
33 A
35 A
38 A
25 A
54 A
56 A
57 A
samme kunde
Herunder faller søking i En kundeprofil viser alle databasen etter kontrakter og maler kundespesifikke maler og tilhørende kunden
liste disse opp
Herunder faller 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
Herunder faller kartlegging om muligheter på nåværende webhotell for å få en sikker Systemet skal bruke https­overføring av filer og SSL­kryptering i all informasjon slik at dette interaksjon med bruker
ikke overføres i klartekst
Herunder listing av Systemet skal tilby kundens kontrakter og muligheten å laste ned alle mulighet til å laste ned dokumentene knyttet til en dette som en "kundeprofil" i
kunde
zip eller lignende
Systemet skal kunne sende Herunder funksjonalitet om
mail til kunden nå er å sende ut mail når en kontrakt er laget med kontrakt er signert som en kunden
slags kvittering
Herunder funksjonalitet for å bytte ut eksisterende mal
En bruker skal kunne om det er gjort endringer i oppdatere malversjon
den
Herunder funksjonalitet for å endre aksesslister En bruker med tilgang skal tilknyttet en kunde slik at kunne redigere tilgang til andre bruker får nye kunde
rettigheter
Herunder en sperre for innlogging for å forhindre En bruker skal bli blokkert "brute force attack" på etter x antall feilinnlogginger systemet
Herunder mailfunksjonalitet
som sender ut et generert En bruker skal kunne få et passord som fungerer i et midlertidig passord på mail døgn
8
5
7
15 13 10
13
15 18 15
16
20 19 15
18
10 14
8
11
25 30 25
27
15 16 10
14
5
8
5
5
5
18 17 15
17
**
40 B
41 B
55 B
39 B
Herunder manuelle oppføringer i loggen slik at systemet kan benyttes til En bruker skal kunne legge logging av samtaler/ til manuelle oppføringer i notiser som ønskes lagret kundelogg
mot kunden
15 14 20
Herunder valg som Systemet skal tilby telefon/epost /merknad kategorier for manuelle tilknyttet manuelle oppføringer
oppføringer
8 10 8
Herunder endring og etablering av nye roller og En admin skal kunne hvilke muligheter disse redigere roller
rollene skal ha
15 18 15
Åpner for at bruker kan En bruker skal kunne endre egen profil, ikke bare
redigere egen profil
admin
4 2 5
Tot funksjonelle krav
Ikke funksjonelle krav
Totalt alle krav
16
9
16
4
468
75
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”.
https://trello.com/b/kkLlQAv2/scrumbrett­implementering (Krever innlogging og tilgang)
Sprinter
#
Antall timer*
Prosent ferdig
Timer overført til neste sprint
Ukenr
Oppsummering
1
70,0
6
Gruppen har dekket alle punktene i 100%
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.
0
2
95
7
Gruppen utfører alle punktene i 94,73%
sprinten, men det gjenstår et par underpunkter på det ene kortet tilknyttet brukers profil.(#3) Overfører derfor 5 timer til neste sprint.
5 **
3
75
8
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.
86,67%
10**
4
77
9
Gruppen utfører de fleste av punktene 79,22%
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.
16**
5
71
10
Gruppen utfører alle punkter, også 85,92%
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.
10**
6
67
11
Gruppen utfører alle krav satt. Også 100%
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ø.
0
7
79
12
Gruppen utfører alle krav i sprinten, 93,67%
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 5**
kan starte neste uke.
8
60
13
Gruppen gjør ferdig de resterende 100%
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 19­27.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) * 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.
Skjermdump av sprinter
Figur 1: Scrumbrett per 28.01.2014 kun med oppstartsfasen
Figur 2:Scrumbrett per 07.02.2014 Sprint 1 ferdig, og Sprint 2 planlagt for kommende uke
Figur 3:Scrumbrett per 14.02.2014 Sprint 2 ferdig, og Sprint 3 planlagt for kommende uke
Figur 4:Scrumbrett per 21.02.2014 Sprint 3 ferdig, og Sprint 4 planlagt for kommende uke
Figur 5:Scrumbrett per 28.02.2014 Sprint 4 ferdig, og Sprint 5 planlagt for kommende uke
Figur 6:Scrumbrett per 07.03.2014 Sprint 5 ferdig, og Sprint 6 planlagt for kommende uke
Figur 7:Scrumbrett per 14.03.2014 Sprint 6 ferdig, og Sprint 7 planlagt for kommende uke
Figur 8:Scrumbrett per 21.03.2014 Sprint 7 ferdig, og Sprint 8 planlagt for kommende uke
Figur 9:Scrumbrett per 28.03.2014 Sprint 8 ferdig. Sprintbrett ferdig.