Hovedprosjekt i data/informasjonsteknologi

Transkript

1 Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus, våren 2013 Avdeling for ingeniørutdanning Forprosjektrapport - Gruppe 17 Sted og dato: Høgskolen i Oslo og Akershus, Tittel: Oppgave: Mare Nostrum Å innsamle datasett fra Xenetas kontakter på en effektiv måte, analysere datasettene med tanke på rederienes kvalitetsavvik og presentere resultatet i et enkelt webbasert applikasjon. Gruppemedlemmer: Altin Qeriqi (160934) Eirik Lund Flogard (169963) Haimanot Ftsumbrhan Tekie (163488) Oppdragsgiver: Kontaktperson hos Xeneta: Intern veileder på HiOA: Xeneta AS Adresse: Malerhaugveien 19-23, 0661 Oslo Tlf: E-post: support@xeneta.com Web-side: Vilhelm K. Vardøy Stilling: Utviklingsansvarlig Tlf: E-post: vilhelm@xeneta.com Thor Hasle Tittel: Førstelektor Avdeling: TKD, Institutt for informasjonsteknologi Tlf: E-post: thor.hasle@hioa.no Side 1 av 12

2 Vi har fått i oppgave å lage en løsning for Xeneta for sporing av skip. Vi har valgt denne oppgaven da vi mener at den er framstår som tiltrekkende både teknisk og praksis. Blant annet syntes vi at forretningsideen som Xeneta er bygd på var interessant. Vi likte også at oppgaven gikk ut på å lage back-end programmering og konstruksjon av algoritmer, heller enn at det var mye fokus på design. Innholdsfortegnelse Sammendrag...2 Dagens situasjon...3 Arbeidsplan...3 Arbeidsmåte...3 Organisering...4 Fordeling av oppgaver...4 Aktivitetsplan...4 Fremdriftsplan...6 Mål og systembeskrivelse...7 Systembeskrivelse...7 Funksjonelle krav...7 Omfang/begrensninger...7 Prosjektmål...8 Rammebetingelser...8 Analyse av rammebetingelser...8 Risikovurdering...9 Løsninger/alternativer...11 Analyse av virkninger og konklusjon...12 Sammendrag Prosjektet skal gjennomføres som hovedprosjekt ved HiOA ved ingeniøravdelingen i samarbeid med Xeneta AS. Kjernen av oppgaven som skal løses er å innsamle data som forteller hvor skipet er til enhver tid. Datasettene skal så analyses og presenteres i en enkel web-basert applikasjon. Dette gjør at Xenetas kunder kan få oversikt over hvor punktlig et skip er, og når skipet faktisk kommer til havnen. Dette er ment for å hjelpe Xeneta sine kunder å kunne velge rederiene som møter deres krav best. Side 2 av 12

3 Dagens situasjon Forprosjektrapport - Gruppe 17 Xeneta er et lite, relativt nytt selskap med kun 6 ansatte. Firmaet er basert på en forretningsidé og et ønske om å gjøre den lukkede shipping markedet mer åpent. Et stort problem som mange av kundene innen shipping har opplevd er at rederiene forlanger priser som ikke er konkurransedyktige. På grunn av dette fungerer markedet i dag nesten som et oligopol. Xeneta sin mål er derfor å gjøre objektiv informasjon lett tilgjengelig for sine kunder, slik at de er i stand til å ta bedre valg i sin hverdag. I dag tilbyr Xeneta tre abonnementer til sine kunder. Gratisproduktet gir selskapene priser for handelsrutene og tilgang til markedsdata (priser) for de handelsrutene de deler. Det er et Professional -abonnement som tilbyr en månedlig rapport med dypere analyser av hvordan selskapet ligger an i markedet i tillegg til gratisabonnementet. Enterprise -abonnementet tilbyr mulighet til å kjøpe seg tilgang til markedsdata i forskjellige pakker i tillegg til de tilbudene de to overnevnt abonnementer tilbyr. Som utgangspunkt for prosjektet ønsker Xeneta å utvide sine tjenester til kundene, slik at de kan vise mer informasjon om hvor punktlig shippingselskapene er i forhold til deres estimert ankomsttid. Selskapets visjon er at flere av deres kunder skal kunne spare penger på denne informasjonen. Arbeidsplan Arbeidsmåte Vi bruker scrum som utviklingsmodell for prosjektet. Det vil eventuelt bli gjort tilpasninger til utviklingsmodellen senere i prosjektet i tillegg til det som er beskrevet her. Vi mener at flere av artefaktene og metodene i scrum er uegnet og uvesentlig grunnet at prosjektet ikke involverer penger, kostnader eller investorer. Derfor har vi valgt å gjøre mange tilpasninger til scrum modellen. I forhold til arbeidsmetoder velger vi å jobbe sammen på skolen med prosjektet. Det innebærer derfor at vi erstatter det daglige scrum-møte med programmering i grupper. Dette gjør at det blir enkelt å ta raske avgjørelser underveis, slik at vi slipper å utsette endringer. Vi har valgt å gjøre tilpasning i forhold til backlog i scrum. Ettersom vi ikke jobber direkte mot en kunde, er vi heller ikke i stand til å oppdrive mange user-stories. Vi velger derfor å kalle disse krav. Kravene som er beskrevet i forprosjektet er arrangert i rekkefølge etter forretningsverdi og effort som en product-backlog. Sprint-Backlog en utformes også utfra kravene der vi spesifiserer hvilke aspekter i kravene som skal implementeres i den neste arbeidsøkten. Siden gruppen alltid sitter sammen og programmerer, kan en del av sprint-backlogen foregå muntlig. Dette avhenger av hvor mange elementer sprint-backlogen består av. Side 3 av 12

4 Siden vi har skolen som oppdragsgiver i tillegg til Xeneta vil vi ha langt mer dokumentasjon rundt vår utviklingsprosess enn det som er vanlig i scrum-modellen. Organisering Vi har også bestemt oss for at gruppelederen skal være scrum master. Dette innebærer blant annet avgjørelser og organisering av møtetider (for gruppen og eventuelt oppdragsgiver), reservasjon av arbeidsplass, samt godkjenning av endring av arbeidsfordeling og tidsrammer. Ved behov kan det også oppnevnes en eller flere personer til å ta notater ved prosjektmøter. Det er midlertidig ingen fast rolle. Kontaktpersonen for oppdragsgiver kan i dette prosjektet regnes som Product owner i utviklingsmodellen. Det er midlertidig ikke spesifisert noen ytterligere roller for sosial organisering av gruppen for dette prosjektet. Fordeling av oppgaver Vi prøver å ha en jevn fordeling av oppgaver for gruppen under prosjektet. Allikevel kommer vi til en viss grad til å fordele ansvar/oppgaver underveis etter gruppemedlemmenes styrker. Det er bestemt at Eirik skal ta seg av mye av dokumentasjonen samt rapportskriving på grunn av hans sterke bakgrunn i allmennfag. Altin kan sørge for å sette opp det meste av utviklingsmiljø, oppsett av pakker eller klasser og konfigurering av programmeringsverktøy, siden han har mest erfaring i bruk av ulike typer programmeringsverktøy. Haimanot kan ha ansvaret for mye av testingen siden hun har en naturlig kritisk sans. Aktivitetsplan Aktivitetsplanen inneholder kun aktivitetene på et overordnet nivå. Dette er fordi vi bruker scrum som utviklingsmodell. Før fasen begynner, vil gruppen spesifisere nærmere nøyaktig hva som skal gjøres og når hver enkelt del av aktiviteten skal være ferdig. Aktivitet Beskrivelse Forstudie Statusrapport Prosjektskisse Forprosjekt En overordnet beskrivelse av gruppen, bedriften vi skal ta oppdrag for og oppgaven vi har fått av oppdragsgiveren. En mest mulig presist definisjon av problemet og prosjektets omfang Rapporten inneholder blant annet beskrivelse av prosjektet og Side 4 av 12

5 spesifiserer mål, kravspesifikasjon og sier noe om hva produktet faktisk skal gjøre. Spesifikasjon Insamling av informasjon og klargjøring av prosjekt. Møter med Xeneta og sette oss inn i nye programmeringsspråk. Implementering Forberedelse av struktur/utarbeide programmoduler Opprette klasser og moduler Opprette databasestruktur Implementering av krav og nodene av systemet Gjøre ferdig implementasjon etter hovedkrav Gjøre ferdig implementasjonen etter "sidekrav" Opprette styringsdokumenter for strukturen til systemet. Lage klasser og skjelettet systemet. Opprette og definerer databasetabeller. Lage programkode for hovedprogrammene etter fastsatt modell. Implementering av systemnodene. Fullføring av en versjon av systemet. Å fullføre sidekravene til systemet. Testing Utføre unit-tester Testing av funksjoner knyttet til sidekrav Testing av programmet i sin helhet Sette opp en testing område og teste programmet fra start av. Testing av implementasjon/kode som er knyttet til de mindre prioriterte kravene. Å utføre sluttest Dokumentasjon Påbegynne sluttrapport. Skrive ferdig sluttrapporten Gå igjennom elementene i sluttrapporten som allerede er skrevet. Lage skjellettet til sluttrapporten. Fullføre den endelige versjonen av sluttrapporten. Side 5 av 12

6 Gjennomgang av kodedokumentasjon Brukermanual Gjennomgang av programstrukturen. Påse at koden er lett å sette seg inn i. Fylle inn manglende kommentarer i koden Skrive brukermanual for programmet rettet mot brukere. Presentasjon Forberede presentasjon Presentasjon Organisere og planlegge presentasjon av prosjektet. Lage eller hente nødvendige effekter til presentasjonen. Øve på retorikk Presentere produktet til sensor. Fremdriftsplan Som nevnt flere ganger ovenfor, skal vi bruke Scrum som utviklingsmodell. Det er litt vanskelig å planlegge iterasjonene så tidlig i prosjektfasen og vi har derfor under implementasjonsfasen bare valgt å ha med aktivitetene som er felles i de fleste av iterasjonene. Side 6 av 12

7 Mål og systembeskrivelse Forprosjektrapport - Gruppe 17 Systembeskrivelse Løsningen som skal utvikles skal i størst mulig grad være en utvidelse av produkter eller tjenester som allerede tilbys av Xeneta. Systemet skal hovedsakelig utvikles slik at det kan brukes av Xeneta sine kunder, Xeneta selv eller eventuelt en tredjepart som tar over systemet. Xeneta stiller ingen bestemte ønsker eller krav til universell utforming, eller til hvordan løsningen skal se ut i front end. I forhold til krav, har Xeneta spesifisert at bruksområdet rundt løsningen er ganske usikkert. De vet altså ikke om det er Xeneta selv, Xeneta sine kunder eller en eventuell tredjepart som kommer til å benytte seg av systemet. De ønsker derfor ikke at vi skal designe løsningen med hensyn på tilpasning til bestemte aktører. Derfor har vi ikke valgt å spesifisere hvem som er aktørene i de forskjellige funksjonelle kravene. Når vi identifiserer eventuelle aktører i et brukertilfelle(usecase)-beskrivelse vil vi gjøre antagelser av hvem vi mener kommer til å ende opp med å være aktør for de bestemte brukertilfeller. Dette er kun ment for å få oversikt over løsningen og er gjort med en viss antagelse av de forskjellige aktørenes roller. Foreløpig har vi satt følgende krav til løsningen: Funksjonelle krav Trekke ut hvilke rederier som yter best i forhold til hverandre. Altså finne de som er mest punktlige. Gi kunder en advarsel på at skipet er forsinket med hensyn på posisjonen fra tidligere transitt. Gi et estimat på ankomsttid for et skip og sammenlign dette med planlagt ankomsttid. Spor skipet og tegn ruten på kartet. (kravet har lav prioritet) Vise statistikk over punktligheten til bestemte trade lanes (handelsruter) for en uke, en måned og et år i form av diagrammer. (kravet har lav prioritet) Vise statistikk over den gjennomsnittlige punktligheten til et rederi for en uke, en måned og et år i form av diagrammer/grafer. Lavest prioritet Omfang/begrensninger Programstrukturen for løsningen skal være på en slik måte at den i ettertid blir lett å sette seg inn i, og blir lett å videreutvikle i ettertid. Prosjektdokumentasjon skal være strukturert, presis og konsistent og ferdigstilt innen prosjektets sluttdato. Dokumentasjonen skal følge de retningslinjer som er beskrevet i lærerboken Systemutvikling - Applikasjoner og databaser av Thor E. Hasle (Cappelen, 2008), og skal også utformes med tanke på at HiOA skal vurdere løsningen. Side 7 av 12

8 Prosjektmål Det er som overordnet mål å bli ferdig med en god løsning som er tilfredsstillende både for oppdragsgivere og for deres kunder. Målene som er beskrevet er kun midlertidige og kan endres eller ytterligere presiseres i løpet av prosjektet. Følgende mål er satt til å nås innen prosjektets slutt: Løsningen skal være et seriøst tilbud fra Xeneta ved å bidra til å redusere kostnader (knyttet til forsinket eller tidlig ankomst av et skip)for deres kunder i størst mulig grad. Løsningen skal være nyttig, og vise mer informasjon om de forskjellige rederiene enn det deres kunder vet eller har tilgang til per i dag. Løsningen bør være veldig nøyaktig, men samtidig være effektiv med hensyn på datakraft. Rammebetingelser Xeneta har også satt en del rammebetingelser for løsningen for at den skal være mest mulig kompatibel med deres nåværende systemer. Følgende rammebetingelser er satt: Programmeringsspråk (back-end): Python Task/job-køsystem: Celery Visuelt og web: Twitter Bootstrap (HTML) og Python Database-spørrespråk: MongoDB Versjonshåndteringssystem: Git Utviklingsverktøy: Eclipse. Lagring av prosjektstyringsdokumenter: Intern lagring(backup), Google Docs og Dropbox. Microsoft Project skal brukes til prosjektstyring. Analyse av rammebetingelser Rammebetingelsene som er oppgitt i avsnittet ovenfor er utarbeidet i samarbeid med Xeneta og studentene i gruppe 17. For Xeneta så gjelder de viktigste rammebetingelsene at gruppen skal bruke programmeringsspråket Python og databasehåndteringssystemet MongoDB for å sørge for kompatibilitet med deres eksisterende systemer. Ettersom ingen i gruppe 17 har jobbet med disse tidligere, vil det være viktig for prosjektet at alle i gruppen setter seg grundig inn i dette så tidlig som mulig. I motsetning til de databasehåndteringssystemene vi har brukt tidligere (Hovedsakelig MySQL) er MongoDB et dokumentorientert databasehåndteringssystem; data blir ikke lagret i tabeller. MongoDB skalerer og yter bedre enn MySQL og andre relasjonsdatabasesystemer for med MongoDB sliper man det resurskrevende arbeidet med kobling av relasjonene mellom tabellene hvor dataene ligger fordelt i. Side 8 av 12

9 Det er allikevel behov for effektiv behandling av store mengder data samtidig, noe som i dette tilfellet er en av styrkene til MongoDB. Celery skal brukes for å distribuere arbeid på flere arbeidsnoder ved bruk av multiprosessering. Celery skal implementeres i programkoden (Python). Risikovurdering Denne risikovurderingen er gjort som en kvalitativ vurdering. Vi har altså ikke tallfestet risikoen. Vi har heller ikke vurdert risiko i form av penger, men heller som risiko for betydelig negativ påvirkning av prosjektet eller produktet. Vurderingen er gjort på bakgrunn av gruppens arbeid med tidligere prosjekter som for eksempel i faget Systemutvikling. Sykdom over kort tid Sannsynlighet: Middels Virkning: Middels Risiko: Middels Beskrivelse: Sykdomsforløp som varer kortere enn 2 uker som fører til at vedkommende er ute av stand til å arbeide med prosjekt. Løsning: Omfordeling av oppgaver til resten av medlemmene i gruppen. Omstrukturering av fremtidig arbeidsfordeling for å fordele fremtidig arbeid likt. Sykdom over lang tid Sannsynlighet: lav Virkning: Middels/høy Risiko: Lav Beskrivelse: Sykdomsforløp som varer lengere enn 2 uker som fører til at vedkommende er ute av stand til å arbeide med prosjekt. Løsning: Omfordeling av oppgaver, begrense omfanget av prosjektet. Omdefinere krav Dårlig arbeidsfordeling Sannsynlighet: Middels Virkning: Lav/middels Risiko: lav/middels Beskrivelse: Dårlig fremgang og mye belastning på enkeltpersoner på grunn av at enkelte i gruppen ikke gjør det de skal. Karakteriseres av at mye av arbeidet stadig tildeles en eller 2 av personene i gruppen. Løsning: Skriftlig advarsel og eventuelt sanksjoner. Eventuelt omfordeling av oppgaver dersom de er vanskelige å gjennomføre for vedkommende. Gjennomgang av arbeidsrutiner. Side 9 av 12

10 Tidsrammer Sannsynlighet: lav Virkning: middels Risiko: lav Beskrivelse: Tidsrammene blir ikke overholdt i følge arbeidsplanen/framdriftsplan. Løsning: Avgrense kravene eller omstrukturere arbeidsoppgaver. Eventuelt omdefiner arbeidsplanen dersom dette rett og slett skyldes underestimering av tidsbruk. Tap av data Sannsynlighet: lav Virkning: Høy Risiko: middels Beskrivelse: Tap av arbeid i form av utilsiktet overskriving av data, eller at data blir slettet på grunn av tekniske feil. Løsning: Lage flere sikkerhetskopier underveis. Beregne en ekstra tidsramme på slutten av prosjektet slik at gruppen for tid til å gjøre arbeidet på nytt igjen. Manglende strukturering i prosjektet Sannsynlighet: lav Virkning: lav til høy Risiko: lav/middels Beskrivelse: Gruppen klarer ikke å skaffe oversikt over prosjektet på en forsvarlig måte. Karakteriseres ved mange ulike oppfatninger over hvordan prosjektet skal gjennomføres, og generelt stor usikkerhet. Løsning: Organisere flere møter med oppdragsgiver for veiledning, gå igjennom styringsdokumentene. Gå til faglærere på HIOA for veiledning. Avgrense oppgaver/krav dersom det kommer fram at de er urealistiske å gjennomføre. Gruppemedlemmer slutter: Sannsynlighet: lav Virkning: lav Risiko: lav Beskrivelse: Et eller flere gruppemedlemmer slutter i prosjektet Løsning: Kutte krav, eventuelt fokuser mindre på enkelte elementer i sluttrapporten som for eksempel brukermanualen. Eventuelt prøve å forhandle med skolen/oppdragsgiver om utsettelse av innlevering. Side 10 av 12

11 Løsninger/alternativer Diagrammet nedenfor viser dataflyten til systemet slik det er tenkt etter ferdigstillelse. Noen av nodene eksisterer allerede, men det finnes ingen implementasjon/kode for disse for den løsningen vi skal lage. I tilknytning til kravene har vi som oppgave å lage UDP-serveren. Den henter data om skipsposisjonene i sann tid fra marinetraffic.com. Dataene sendes deretter videre fra UDP-serveren til Message queue (MQ) som igjen utfører ønsket operasjoner på dataene og legger dataene på riktig sted i databasen. Skipsschedules sendes av rederier til mailserveren, som beskrevet på diagrammet. Disse ligger som vedlegg i mailen i csv-format og ekstraheres og skal deretter gjennomgås av en parser. De estimerte tidene for ankomst og avgang, samt annen informasjon om skip taes ut og legges inn i Xeneta sin database. Dataene fra skipstrafikken kan deretter hentes og sammenlignes for punktlighet med schedulene som er mottatt via mail. Sammenligning av data skjer i sann tid (ved en input fra bruker). Både mailserveren og UDP-serveren er ment å fungere som et sted for midlertidig lagring av data (dataene velges ut etterpå og legges inn i databasene via MQ). De andre funksjonalitetene til systemet baserer seg på disse dataene. Celery og Message queuen har som ansvar å styre systemet, og delegere oppgaver for de forskjellige nodene. MQ lagrer meldinger midlertidig og bestemmer også om data skal mottas og behandles, eller om de skal ignoreres. Celery sørger også for en slags form for høynivåparallellisering der den delegerer disse oppgavene til de forskjellige nodene som brukes i Xeneta sine systemer. Dataene om skipstrafikk skal vises på en webside der gruppen står veldig fritt til å bestemme selv når det gjelder designet. Som et alternativ til dette, kan det vises grafer, diagrammer og statistikk om skipsdataene ut ifra en input/spesifisering fra bruker, slik som beskrevet i de siste punktene i Funksjonelle krav. Det er i midlertidig ikke snakk om noen alternativer til back-end -delen av programmet. Side 11 av 12

12 Analyse av virkninger og konklusjon Produktet skal bidra til å gjøre det enklere for Xeneta sine kunder å velge rederier, basert på objektive data. Det endelige målet for Xeneta, er at deres kunder skal kunne spare penger på å velge det billigste og mest pålitelige rederiet. Nøyaktige estimat for ankomst for skip og bruk av advarsler til Xeneta sine kunder, kan også gjøre at flere av dem sparer penger på redusert lagringstid ved havn(er). Per i dag er ikke Xeneta helt sikre på nøyaktig hvor nyttig produktet kommer til å være for deres kunder. Usikkerheten vil være tilstede fram til produktet settes i drift. Eventuelt kan systemet videre distribueres til andre operatører innenfor shippingbransjen som har vist stor interesse for konseptet. Produktet skal derfor være på en slik måte at det skal være enkelt å bruke. På bakgrunn av det som er tidligere nevnt i rapporten er det viktig å tenke at produktet ikke skal betraktes som et endelig sluttprodukt, men at det er noe som kan videreutvikles eller endres ved behov etter prosjektets slutt. Side 12 av 12