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 2013/2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Prosjektdagbok Lars sender mail til tre bedrifter for å undersøke muligheten for å skrive hovedprosjektoppgave. Disse bedriftene var Accenture, Finn.no og Steria Av de tre bedriftene var det kun Steria som ikke hadde et opplegg rundt hovedprosjektoppgave. Finn.no og Accenture hadde muligheten til dette, og vi skulle sende svar tilbake om hva vi hadde planer om å ha som hovedprosjektoppgave. Hos Accenture måtte vi i tillegg gjennom en litt lengre søkeprosess. Dette hadde vi ikke planlagt på forhånd og sa at vi måtte komme tilbake til de aktuelle bedriftene når vi hadde et klarere svar Simen forhører seg med en bekjent om en mulig prosjektoppgave hos en liten lokal bedrift. Denne bedriften ønsker en løsning av sin håndtering av ulike skjema. Det ønskes at en rekke PDF dokumenter skal kunne lastes opp til en tjenste, som registrere de ulike feltene som skal fylles ut, og gjør disse om til et webskjema, for enklere utfylling. Systemet skal holde rede på en rekke PDF maler, og kunne fylle ut disse raskere enn manuell utfylling for hånd. Bedriften kunne se på dette som en hovedprosjektoppgave, hvis ønskelig av gruppen Gruppen samles for registrering av gruppe, samt utarbeiding og levering av statusrapport.

2 Gruppen samles for å begynne utarbeiding av prosjektskisse. Sender epost til oppdragsgiver for å få avklart punktet for tilgjengelig maskinvare, samt prosjektets plass i oppdragsgivers virksomhet og legger dette til i prosjektskissen. Begynner også utarbeiding av design for nettsiden samt etablering av gruppeside, samt levering av lenke til gruppeside og prosjektskissen Gruppen samles for å starte med prosjektet og utarbeide forprosjekt. Begynner smått med å lage illustrerende figurer og lager private Git repository. Sammen med dette ser vi på å bruke rammeverket CodeIgniter ( Undersøker også muligheten for Zend rammeverk da de ser ut til å ha støtte for manipulering av pdf filer Gruppen samles for å starte med forprosjektrapport og for å legge en plan for jobbingen fremover. Vi konsulterer med oppdragsgiver og veileder for å lettere sette opp overnevnte plan. Vi har også bestemt oss for å bruke den smidige utviklingsmetoden SCRUM, og meldte oss inn i den nettbaserte SCRUM tjenesten Trello.com. Før vi skilte lag fikk vi startet på forprosjektrapporten og laget en foreløpig skisse over denne. Vi har på dette punktet ikke fått svar fra veileder Får svar og mailer videre med veileder og fastsetter første møte i morgen (15.01). Har også fastsatt første møte med oppdragsgiver kommende tirsdag (21.01). Gruppen jobber under hovedpunktet Oppstartsfase hvor vi lager grove skisser til første møte med oppdragsgiver. Mer konkret logg om oppgaver og utført arbeid finnes på Trello som vi har begynt å benytte fra og med i dag under nevnte hovedpunkt Møter veilder for første gang. Innfører og informerer kort rundt prosjektet for veileder. Gruppen kommer også med et par henvendelser tilknyttet forprosjektrapport/linsesbelagte prorgramvarer veileder skal undersøke videre. Veileder ønsker også tilgang til Trello for å kunne se mer konkret fremgang/utviklingsmetode Gruppen møtes først for å sette opp agenda for møte med oppdragsgiver (se MoteAgenda2101.pdf). Møter oppdragsgiver for første gang og får her avklart mye med tanke på punktene i nevnte dokument samt hva de ønsker av den ferdige løsningen. Etter møtet begynner

3 gruppen å skrive et møtereferat av det som ble gjennomgått på møtet. Dette sammen med forprosjektrapporten ferdigstilles senest fredag (24.01). Sender mail til hovedprosjektkoordinator med tanke på rammeverk for applikasjonen og forhører også med tanke på teknisk veileder. Har nå endret fokus fra CodeIgniter/Zend over til Laravel ( som ser ut til å være PHP rammeverket som er i vinden og er mest utbredt i 2013 ( php frameworks 2014/). Sender også mail til veileder for å få avklart kontrakt mellom oppdragsgiver og skolen Gruppen møtes for å ferdigstille møterapport og forprosjektrapporten, samt legger ut dette på gruppenettsiden sammen med møteagendaen. Informerer både oppdragsgiver og veileder om dette. Bestemmer oss også for å gå for PHP rammeverket Laravel Gruppen møtes for å sette opp kravspesifikasjon for prosjektet med prioriteringsgrad. Begynner også å sette opp fremdriftsplan med tidsestimering av kravene for å anslå hva vi kan rekke i løpet av prosjektets periode. Sender mail til veileder om hjelp med tidsestimeringen. Sender også mail til UniWeb hvor oppdragsgiver har webhotell med spørsmål tilknyttet SSL kryptering. Endrer oppdateringstidspunkt av dagbok på gruppesiden til Torsdag/Fredager Gruppen møtes og renskriver kravspesifikasjonen, samt ferdigstiller Fremdriftsplan med tidsestimering av punktene i kravspesfikasjonen. Bestemmer oss også for å utvikle med en ukes sprint, hvilket det legges opp til i fremdriftsplanen. Legger inn første sprint i Fremdriftsplanen, samt i Trello. Til slutt lager gruppen en kort presentajon for morgendagens møte med veileder. Printer i denne forbindelse ut begge dokumentene til veilder Gruppen møter to andre grupper og veileder for felles veiledning og presentasjon av gruppenes prosjekter. Her fikk vi en foreløpig tidsplan for veiledning og fikk oppklaring i noen praktiske spørsmål rundt gjennomføringen av prosjektet. Som nevnt over presenterte vi vårt prosjekt og fikk mange gode innspill fra de andre gruppene samt veileder. Etter dette hadde vi en generell diskusjon i plenum samt ris og ros fra de andre gruppene. I denne sammenhengen utleverte vi også en papirversjon av vår foreløpige fremdriftsplan og forprosjektrapport til veileder.

4 Gruppen møtes for å gjøre klart til første sprint på scrum brettet. Setter opp Git repo og legger til rette for god versjonshåndtering. Fremdriftsplanen sendes til produkteier (Meso) for å ta i betraktning hvordan de stiller seg til de ulike avgjørelsene gruppen tok i sammensetningen av denne Gruppen sender mail til hovedprosjektansvarlig for å få avklart lisenser og testmiljø. Testmiljø, i form av virtuell maskin (unix), må videre taes med Amir. Lisens for Adobe Acrobat Reader Pro, som kan skaffes på enkeltlisens, kan skolen ikke stå til disposisjon med Sender mail til oppdragsgiver og planlegger nytt møte førstkommende Mandag (10.Februar) klokken 11:00. Har nå en design/prototype utkast å vise på møte sammen med at vi må få avklart serversituasjon samt ordne med avtale mellom oppdragsgiver og skole. Oppdaterer Fremdriftsplan med gjennomført sprint, samt planlegging av ny sprint. Legger også til nye kort for neste sprint på Trello Har møte med oppdragsgiver. Gruppen utarbeider i etterkant ut både møteagenda og møtereferat som legges ut på gruppesiden. Legger på møtereferatet også med figurer fra løsningen per i dag tilsvarende slik det ble fremvist på møtet. Sender mail til UniWeb for å få avklart pris på backup av VPS server samt mail til oppdragsgiver med møtereferat og spørsmål tilknyttet hva som skal lagres tilknyttet Prosjekter i løsningen Har møte med veileder hvor vi informerer om nylig møte med oppdragsgiver samt hvordan jobbingen med prosjektet går. Får bra tilbakemeldinger på fremdriftsplan/kravspesifikasjon og får råd om å opprettholde dokumentasjon mens vi jobber ettersom det vil være god dokumentasjon til sluttrapport. Får også VM fra Amir oppe å gå slik at vi nå har et fungerende testmiljø tilsvarende det som den ferdige løsningen skal kjøre på.

5 Har videre dialog med kontaktperson hos oppdragsgiver. De er i dialog med finanstilsynet angående gyldigheten på elektronisk signatur. Det virker som det ikke skal være noe problem å legge på signatur på pdfen. "Snakket med en nå som mente at det ikke skulle være noe problem siden de godkjenner telefon, fax, mail og alt mulig annet skal sende et konkret eksempel til han på mail på mandagen, så skal de prate om det på avdelingen og deretter få et konkret svar. De sa i tilsynet at dette virket veldig innovativt og bra, de hadde ikke hørt om noen som hadde dette fra før så jeg tror at dette virkelig kan være et bra program. " Lager også nye kort i Trello med To do kort til hver enkelt for småoppgaver vi må ordne som ikke faller inn under et aktivt kort. Disse er lagt i hovedkategorien Generelt. Setter også opp ny sprint til kommende uke i Trello Har møte med veilder hvor vi forteller kort om fremdriften i prosjektet. Diskuterer kort det største utfordringen i prosjektet med tanke på gyldig signering av dokumenter. Gruppen har ikke begynt med dette kravet enda, men etter undersøkelser både fra gruppen og oppdragsgiver ser dette ut til å være i orden med tanke på gyldighet. Veilder informerer om fremtidig fremføring av prosjekt både med tanke på produkt og fremgang/dokumentering, informerer om at vi ikke vil ha noe direkte å vise frem før om 3 4 uker. Får også informasjon fra oppdragsgiver at deres nærmeste samarbeidspartner vil skiftes ut og dermed vil også den mest brukte PDF malen byttes ut. Får tilsendt den nye malen som så og si er lik den gamle, og fungerer sammen med resten etter litt modifikasjoner Setter opp nødvendig programvare på testmiljø tildelt fra skolen. Setter også opp laravel rammeverket, og henter en utgave fra Github. Lager en guide for hvordan dette oppsettet kan gjenproduseres ved publisering til oppdragsgiveres systemer.

6 Har møte med oppdragsgiver hvor oppdragsgivers sjef er med på møtet i tillegg til vår kontaktperson. Får avklart mye med tanke på hvordan deres jobbhverdager er, og hvordan vi kan speile dette i resultatet. Særlig gjelder dette krav 29 i kravspesifikasjonen som omhandler opprettelse av en annenhåndsmarkedskontrakt. Får også gitt oppdraggivers lenke til testmiljøet hvor vi jevnlig henter inn nyeste versjon. Møteagende for møtet ligger per dags dato ute på gruppesiden, men møtereferat vil ikke bli laget og publisert før på Mandag (10.03) Har møte med veileder hvor vi mottar signert utgave av kontrakten som vi nå kan gi til oppdragsgiver ved neste møte. Viser status siden forrige møte, samt en rask gjennomgang av nylige møte vi hadde med oppdragsgiver. Vi får også vist prototypen på systemet til veielder for første gang, nå som testmiljøet er oppe og kjører. Vi får informasjon om at vi om fire uker, 9. april, skal ha en fremføring sammen med de to andre gruppene samt veileder for å hovedsakelig få øvd på presentering til selve fremføringen av prosjektet. Vi vil motta nærmere informasjon om dette senere. Etterspør rapportmal / eksempel vi kan forholde oss til når vi skal skrive rapporten. Veileder har ikke noe konkret infromasjon om dette, men anbefaler at vi hører med hovedprosjektkoordinator. Vi kommer i møtet så vidt frem til en grov skisse, selv om vi mangler informasjon om hva del 1 (under) skal inneholde. Gruppen sender mail til hovedprosjektkoordinator i etterkant av møtet i påvente av mer informasjon rundt dette. 1. Selve rapporten om systemet generelt fra et overordnet synspunkt som kan leses og forstås selv om man ikke har mulighet til å gå inn i, og / eller forstå selve koden. 2. Kode / teknisk appendix hvor vi tar for oss rammeverk, oppbygging, enkelte metoder og kode valg. 3. Test appendix hvor vi tar for oss enhetstesting og eventuelt andre tester som gjøres på systemet. 4. Brukerveledning appendix til systemet som beskriver hvordan det brukes i praksis (denne er også aktuell å levere til oppdragsgiver).

7 Oppdragsgiver har fått svar fra Finanstilsynet angående gyldigheten av digitale signaturer som skal brukes i systemet. Det vises til tidligere korrespondanse mellom Finanstilsynet og Meso Capital Markets AS, senest ved deres e post 5. mars Meso Capital Markets AS har forespurt Finanstilsynet om foretaket kan innhente kundenes signatur digitalt. Finanstilsynet kan ikke se at verdipapirhandelloven eller verdipapirforskriften er til hinder for bruk av digital signatur så lenge denne er etterprøvbar på lik linje med alminnelig signatur. Finanstilsynet vil likevel minne om at Meso Capital Markets AS må sørge for at det i henhold til vphl (7) kan dokumentere at det etterlever verdipapirhandellovens krav. Det vil si at tiltenkt signeringsmekanisme vil være gyldig etter dette reglementet. Sender også en mail til oppdragsgiver hvor vi kommer med våre innspill til backupløsningen av systemet. Mailen forklarer at deres tjensteleverandør Uniweb oprerer med en 14 dagers rullerende backup, men at dette ikke vil si at de kun har kontrakter 14dager tilbake i tid, men heller at de har 14 dager fra systemet feiler, til det må oppdages. Forklarer også at systemet som vi produserer kommer med egne funksjoner for å håndtere datatap, da de selv kan ta egne backuper av alle kontraktene de har laget i systemet. Og foreslår at de gjør dette ved en regelmessig basis, for å lagre på en minnepenn, eller annet medium, i en av sine arkiver, med en periodisk hyppighet på 1 2 ganger per år Vår kontaktperson hos oppdragsgiver møtte oss på skolen for å se status og slik at vi også kunne få svar på ting som vi lurte på. På møtet viste vi frem nytt design og hvordan mal utfylling fungerte. I denne prosessen fikk oppdragsgiver svar på deres spørsmål, og konkluderte med at mal utfyllingen så veldig bra ut. For vår del gjenstår fortsatt testing rundt dette, men foreløpig fikk vi god tilbakemelding på det. Oppdragsgiver ønsket å søke etter kunder under kontraktopprettelse, noe som blir løst i nærmeste fremtid. Vår kontaktperson presenterte oss også for en funksjonalitet som vi ikke tidligere hadde kunnskap om. Dette var en slags portal for kunder der de kunne se hvilke, hvor mye andeler og hvor de hadde fondene sine. De enkelte tjenestene som behandler dette krever innlogging, og denne informasjonen vil derfor være utilgjengelig fra vårt system, så vi kom frem til en mulig løsning som kanskje kunne være en erstatning for dette. Denne funksjonaliteten blir imidlertid ikke prioritert nå, og vil ikke være en del av hovedprosjektet. I sammenheng med å sende automatisk mail til de partene som skal ha forskjellige deler av en kontraktinngåelse skal oppdragsgiver i løpet av neste uke sende en mail med hvordan typisk

8 ordlyd og tekst til de forskjellige partene skal være. Derfor blir noen timer til kravet dette gjelder overført til neste sprint Sprint 8 som nå er planlagt til kommende uke er siste planlagte uke med direkte arbeid med produktet, og fører prosjektet videre inn i teststadiet. Vi ser for oss at uke 14 vil bli brukt til å korrigere feil på siden vi opplever fra et brukerståsted, slik at vi senere samme uke kan ha en ferdig prototype vi kan teste på oppdragsgiver og få tilbakemeldinger om feil/endringer som må utbedres/gjøres. Konkretisering av dette vil komme i løpet av neste uke hvor fremdriftsplanen vil oppdateres med nærmere informasjon om planlagt arbeid innenfor testperioden Som planlagt ble sprint 8, siste sprint i utviklingsfasen, fullført og prosjektet går nå inn i teststadiet etter planen. I forbindelse med dette er det opprettet en egen fremdriftsplan for testing og rapportskriving. Dette dokumentet er ment som en tidsplan og hjelp til oss, men vi skal også i denne fasen ha kontinuerlig kontakt med oppdragsgiver for å gjøre eventuelle endringer underveis. I tillegg til fremdriftsplanen har vi laget et nytt SCRUM brett for dette og laget tilhørende sprinter og kort for å fortsette med den samme utviklingsmetodikken. Lenke til dette brettet ligger i filen Fremdriftsplan testing. Neste uke vil hovedsakelig gå ut på forberede systemet til brukertest hos kunden. Fremover ser vi for oss en blanding av forbedring (basert på brukertesten), enhetstesting og rapportskriving. Fremdriftsplanen for implementering er også oppdatert med seneste sprints oppsummering Tar kontakt med oppdragsgiver og avtaler et møte fredag 4.april 2014, hvor vi presenterer prototypen vi ferdigstiller. Samt gir et utvalg av de ansatte i bedriften et oppgavesett for å teste de ulike funksjonene i systemet. Resultatene av disse vil brukes til å strømmlinjeforme systemet etter den daglige aktiviteten i bedriften Vi hadde et møte med oppdragsgiver hvor vi viste frem prototypen som skulle benyttes til kommende brukertest. Møteagendaen ligger på gruppesiden, mens møtereferat kommer i løpet av mandag.

9 Har i samråd med oppgradsgiver bestilt miljø hvor det ferdige produktet skal kjøres. Vi vil da i løpet av kommende periode sette opp dette miljøet, og til slutt implementere vårt prosjekt på dette. Har også fått tilgang til å legge til nye e post kontoer, som skal brukes i utsendingen av e poster fra systemet. Videre har vi samlet inn resultater fra helgens brukertest, som er utført av de ansatte i bedriften. Resultatene av disse ser ved første øyekast veldig konstruktive og gode ut, og vi vil i løpet av de neste dagene bearbeide disse i et eget dokument Vi opprettet et git repository for rapporten til hovedprosjektet. Vi satt opp våre respektive maskiner til å synkronisere til og fra denne mappen, og vi installerte programvare for å skrive i LatTex Gruppen er godt på veg med enhetstesting. Har fullført enhetstesting av alle modeller i webapplikasjonen, men enhetstesting av Controllere gjenstår. Har også gått gjennom og dokumentert tidligere brukertest. I tillegg har gruppen laget et skall til rapporten og skrevet deler av den, men er dette punktet mesteparten av tiden fremover vil gå til Gruppen er ferdig med enhetstesting så langt vi kommer med tanke på tid. Sender mail til koordinator for hovedprosjekt og skolens serveransvarlig. Koordinator har fått spørsmål om tilgang til kildekode for sensor, og serveransvarlig har fått spørsmål om levetid på virituell server mtp sensur av hovedprosjektet. Serveransvarlig svarte at vi kan utvide levetiden over sommeren hvis det er ønskelig. Kommer tilbake til dette nærmere leveringsfristen. Gruppen sender også mail til Netprint og Allkopi for å forhøre angående pris og hvor lenge før de må ha inn rapporten for å få trykket den opp til firsten 27. mai ettersom printing på skolen krever innlevering av rapport senest 21. mai Har møte med veilede, og har med et par spørsmål vi ønsker ønsker klarhet i rundt rapport og levering av oppgaven, og fikk svar 8.Mai.

10 Brukerveiledning i rapport: Står i dokumentasjonsstandarden at den skal inneholde termologi, stikkordregister og generell ordliste. Hva er forskjellen? Svar: Ikke viktig med ordlister, stikkordslister etc. Bruk det som virker mest naturlig. Skal de forskjellige dokumentene fungere alene? Skal noen for eksempel kun ha produktrapporten? Kan man for eksempel i prosessrapporten referere til en figur i produktrapporten? Svar: Når det gjelder sluttrapport: Tor mente at mange deler rapporten inn i 2 deler + vedlegg (produktrapport og prosessrapport). Men det er ikke noe som er absolutt. Når jeg foreslo at sluttrapporten kunne deles inn i fem hovekapitler; 1. Kravspesifikasjon, 2. Prosessrapport, 3. Produktrapport, 4. Testdokumentasjon og 5. Brukerdokumentasjon samt referanser og vedlegg til slutt, synes han det var helt OK. Må presentasjonen være i sluttrapporten? Eller kan vi bruke tiden mellom levering av rapport og fremføring til å lage presentasjon? Svar: Presentasjonen skal ikke være en del av sluttrapporten. Skal sensor ha tilgang på en kjørbar versjon av webapplikasjonen? Slik at de kan se produktet, ikke bare dokumentasjon og kode. Svar: Noen sensorer vil ha kjørbar versjon, andre ikke. Kode på vedlagt CD /DVD plate skal holde. Her gjør vi litt etter hva vi har tid til mot innlevering. Skal sensor ha tilgang på GIT repository? Må vel være lurt for å se hvordan vi har jobbet i løpet av prosjektet? Svar: Dette er ikke nødvendig, prosessrapporten dekker dette. Hva legges det i punktet Om resultatet i dokumentasjonsstandaren? Noe i tabellform? Svar: Vi skal glemme det spesfikke punktet, men skal reflektere over resultatet av prosjektet, mao. hva har vi lært, hva kunne bli gjort bedre osv. Må rapporten printes 1 sidig? Eller kan den printes 2 sidig? Svar: Rapporten bør printes 2 sidig Hvor står det om plakaten vi skal lage? Hva skal det brukes til? Hvor skal vi legge den? Hva skal den inneholde? Svar: Ingen plakat skal lages

11 Gruppen sender utkast av sluttrapport til veielder for en gjennomlesing før ny veiledningstime på onsdag (14. mai) Gruppen har møte med veilelder hvor vi får tilbakemeldinger på utkastet til sluttrapport som ble levert 9. Mai. Får en del god pekepinner på hva vi bør endre/forbedre i rapporten. Dette gikk særlig på oppsettet i rapporten, men også å ha en kortere innledning av prosjektet før kravspesifikasjonen blir beskrevet. Blir enig eom å sende veileder rapporten førstkommende Mandag (19.Mai) slik at han får tatt et siste overblikk før den leveres 20. eller 21. Mai. Videre får gruppen informasjon om at vi skal ha øving på presentasjon 4.Juni sammen med veileders resterende grupper Gruppen har sluttrapporten så godt som klar, men mangler en siste gjennomlesing som blir gjort i løpet av morgendagen. Sender sluttrapport til veileder for eventuelle siste endringer Gruppen gjør siste gjennomlesing av rapporten og sender den til printing Henter printede bacheloroppgaver i ekspedisjonen i 7.etasje og setter inn DVD med kildekode og kjørende utgave som vedlegg. Leverer et eksemplar i samme ekspedisjon, en til hovedprosjekansvarlig, Tor Krattebøl, og en til veileder Yngve Lindsjørn. Generelt om oppdatering av prosjektdagbok For hver gang gruppen samles for møter eller arbeid oppdateres dagboken med informasjon om hva som er blitt avtalt og hovedpunkter som er gjort. Konkrete oppføringer om hvem som gjør hva på hvilke tidspunkt kommer imidlertid frem fra Trello bordet på lenken nedenfor. (Kan kun aksesseres for personer som er blitt lagt til). Legger så fremt det har skjedd oppdateringer ut oppdatert prosjektdagbok på gruppens hjemmeside hver Torsdag/Fredag slik at en oppdatert versjon til en hver tid kan nås av først o

12 frem veileder.