Intelligente Handlevogner

Transkript

1 Intelligente Handlevogner Prosjektdokument Prosjekt I Systemutvikling ved Høgskolen I Gjøvik våren Audun Klundby Asbjørn Konstad Hans Einar Øverjordet 03HBINDA Kilde:

2 1. Mål og rammer Bakgrunn Prosjektmål Rammer Omfang Oppgavebeskrivelse/avgrensning Prosjektorganisering Ansvarsforhold Øvrige roller og bemanning Planlegging, oppfølging og rapportering Valg av utviklingsmodell Risikoanalyse Kvalitetssikring Gjennomføring Hovedaktiviteter...9 Side 2 av 9 4/19/2005

3 1. Mål og rammer 1.1 Bakgrunn Bakgrunn for prosjektet er beskrevet i kravspesifikasjon pkt Prosjektmål Prosjektet har som mål å utarbeide prosjektdokumentasjon, kravspesifikasjon og designdokument for systemet i henhold til brukernes krav og forventninger.. JEMA100 ønsker å ta i bruk moderne teknologi for å effektivisere driften gjennom å kutte ned på bemanningen og minke tiden kundene bruker ved de tradisjonelle kassene. Systemet skal også effektivisere tiden kundene bruker i butikken og øke kundegjennomstrømningen med 20 %. Dette vi på sikt øke kjedens omsetning med 35 %. Overordnet mål er i løpet av 6 mnd. etter idriftsettelse av systemet å kunne nedbemanne kassene med 60 %. Prosjektet skal utvikle og implementere systemet i sin helhet med tilhørende infrastruktur og grensesnitt. 1.3 Rammer Prosjektet vil utføres og overleveres i henhold til de regler og tidsfrister gitt. Systemet utvikles innen de rammer som er gitt av tilgjengelige tekniske løsninger for en Klient/Tjener arkitektur, norsk lovgivning om tillatt kommunikasjonsteknologi, og lov om vern av personopplysninger. JEMA100 har i dag en eksisterende web-løsning WEBMA100. Her er alle medlemmer registrert i en kundedatabase med medlemsnummer og personalia. JEMA100 ønsker å integrere det nye systemet med WEBMA100, for å benytte WEBMA100 som kundemaster. Systemet ønskes idriftsatt i løpet av mnd., med en kostnadsramme på kr mill NOK. Ansvarlige for utarbeidelse av prosjektdokumentasjon er Audun Klundby, Asbjørn Konstad og Hans Einar Øverjordet 03HBINDA. Side 3 av 9 4/19/2005

4 2. Omfang 1.2 Oppgavebeskrivelse/avgrensning IHID skal kunne ivareta kundens behov og støtte opp under hele handleprosessen. Vareutvalget skal være lett tilgjengelig og systemet skal kunne gi en komplett og lettfattelig oversikt over den enkelte vares attributter som pris, næringsinnhold, plassering i butikken samt alternative varer. Det skal være funksjonalitet for å registrere en handleliste som skal kunne gi kunden et overslag på pris. Med utgangspunkt i handleliste skal systemet også ha en ruteplanlegger og kunne presentere et kart med raskeste vei gjennom butikken. Det vil også lagres historikk på den enkelte kunde med mulighet for å se tidligere handlede varer og å eventuelt kunne hente en lagret/historisk handleliste for gjenbruk. Butikkene vil deles opp i soner der hver enkelt vare er registrert. På bakgrunn av dette vil et eksternt posisjonssystem kunne beregne den enkelte kundes plassering i butikken. Det utvikles reklamefunksjonalitet som gjør det mulig å vise reklame relevant for den/de varene i den enkelte sone etter hvert som kunden beveger seg i butikken. Posisjonssystemet leveres og implementeres som en ekstern enhet og vil bli integrert med IHID. Prosjektet ønsker et system som benytter RFID (Radio Frequency Identification), og det vil bli valgt en ekstern leverandør som får ansvaret for implementeringen av en slik løsning i sin helhet. Betalingsprosessen i IHID er selvbetjent og utføres i ubetjente kasser, - altså av kunden selv. Således kan kunden velge å betale med betalingskort eller seddel/myntautomat. Det stilles også krav om at hver enkelt vare må ha en RFID. Kassefunksjonen for IHID vil dermed kunne foretaes ved at kunden registrerer/scanner hver enkelt vare. Dette kan gjøres ved at varene legges på rullende bånd og scannes via fastmontert scanner, eller med håndholdt scanner for større varer som ikke får plass på disk. Etter scanning vil kunden bli presentert med totalinnhold i handlevognen samt totalbeløp å betale. Transaksjonen fullbyrdes ved at kunden drar betalingskort i kortleser eller etter tilstrekkelig seddel/myntinnkast i automat. Kunden kan også velge å avbryte betaling når som helst, og må da returnere til butikken med handlevognen/varene. Det vil være noe risiko forbundet med betalingsprosessen, og dette er grunnen til at prosjektet har besluttet å benytte RFID fremfor strekkode. Da oppnår vi økt sikkerhet ved at systemet vil kunne fange opp eventuelle ubetalte varer når kunden forlater kassesonen. Det skal gjøres gjenbruk av eksisterende løsning for kassafunksjon og elektronisk betalingshåndtering. Dette gjøres på grunn av tekniske og kostnadsmessige årsaker. Da IHID i tillegg vil kreve minimalt av kassesystem-funksjonalitet, ble det besluttet å integrere eksisterende system med det nye. IHID utvikles for internt bruk i JEMA100's dagligvarebutikker og er således spesialtilpasset kjedens forretnings-prosesser og strategier. Systemets hovedfunksjonalitet utvikles for bruk på håndholdte/monterte mobile enheter. JEMA100 ønsker i størst mulig grad å benytte seg av datagrunnlag fra eksisterende Side 4 av 9 4/19/2005

5 systemer for vare, lager, kunder, avtaler og økonomi. Det vil derfor designes for å integreres med disse systemene for utveksling av grunndata og funksjonalitet. 3. Prosjektorganisering Det avholdes innledende møte med ledelsen der det etableres styringsgruppe og velges prosjektleder. Det velges en filial der systemet vil bli implementert først for testing og lignende. Etter at prosjektleder er på plass vil resten av prosjektdeltagere settes sammen, og det avholdes kick-off i med alle involverte parter i prosjektet. 3.1 Ansvarsforhold Det etableres en styringsgruppe bestående av følgende ressurser: 1. Produktsjef i JEMA Markedssjef i JEMA Prosjektleder 4. IT-sjef 5. Økonomidirektør 6. Daglig leder fra pilotfilial Valg av prosjektleder Ved valg av prosjektleder ble det lagt vekt på å lokalisere en ressurs som kunne fylle rollen på best mulig måte. Undersøkelser viser at valget av prosjektleder kan i stor grad ha innvirkning på om prosjektet blir suksess eller fiasko. Følgende kriterier ble lagt til grunn for valg av prosjektleder: Forretningsforståelse Teknisk innsikt Prosjektledererfaring Evnen til å ta avgjørelser Øyne for detaljer God kommunikator Det var behov for en person som i tillegg hadde kunnskap om JEMA100 sine interne rutiner og støttefunksjoner. Personen som ble valgt som prosjektleder er ansatt i JEMA100 s administrasjon. Personen er erfaren fra ledelse av andre typer prosjekter og kjenner kjedens forretningslogikk godt. Utdannet økonom, med en brennende interesse for ny teknologi. 3.2 Øvrige roller og bemanning Det etableres en brukergruppe representert av en superbruker. Dette er en person med lang erfaring innen kjeden, samt de rette egenskapene for å kunne være en bidragsyter i prosjektet. Superbrukeren skal være i stand til å oversette og kommunisere med de øvrige representantene i gruppen (ansatte/kunder). Videre velges 1 ansatt fra 3 forskjellige butikker + 10 utvalgte kunder. Totalt vil da brukergruppen være representert av 14 personer. Tidsforbruk av disse vil variere utover i prosjektet. Side 5 av 9 4/19/2005

6 De øvrige 3 ansattrepresentantene velges utfra praktisk butikk/filialerfaring og kundekontakt. De må være gode kommunikatorer samt inneha grunnleggende prosjekt-kunnskaper. De ti utvalgte kundene velges fra kundene i pilot-butikken. Målet er å få med alle typer brukere. Vi trenger en som er av den eldre garde, en ungdom, noen som handler for hele familien, impulshandlere og de som alltid kjøper det samme (egg, brød, melk). 4. Planlegging, oppfølging og rapportering 4.1 Valg av utviklingsmodell Ved valg av utviklingsmodell har prosjektet diskutert flere mulige modellkandidater. Modellene er her representert med for og motargumenter. Prosjektet og produktet som utvikles er relativt nytt mtp. teknologi benyttet som verktøy i en dagligvarebutikk. Det er imidlertid utviklet en lignende løsning av Siemens systems som et antall dagligvarekjeder i USA har tatt i bruk. I tillegg eksisterer det ulike løsninger som skal forenkle kundens hverdag ved hjelp av selvbetjente kasser m/strekkodeskannere. Dette satte prosjektet på tanken at en komponentbasert modell muligens kunne benyttes. Fordelene hadde vi valgt denne modellen er at kostnadene ved utvikling reduseres da men gjør gjenbruk av eksisterende (hyllevare). Modulene er ferdig testet og dokumenterte, noe som igjen vil redusere kostnadene ved egen test og dokumentasjon i prosjektet. Disse/dette systemet er imidlertid ikke utviklet med noen definerte/åpne grensesnitt og er i så måte lite skalerbare/tilpasningsdyktige. En eventuell tilpasning ville være tidkrevende og vanskelig. I tillegg vil ikke dette systemet dekke de krav prosjektet har til funksjonalitet. Hovedproblemet er det skannersystemet som blir brukt. Her benyttes strekkodeskannere mot for prosjektets behov for bruk av RFID. Videre viser brukerundersøkelser gjort i USA at systemet/systemene som er i bruk i dag ikke er særlig tilfredsstillende mtp. funksjonalitet. Prosjektets konklusjon er å ikke satse på en komponentbasert hovedmodell da denne eksisterende systemer/komponenter ikke kan imøtekomme prosjektets krav. Som nevn vil produktet som skal utvikles være unikt, i alle fall i Norge og det finnes ingen erfaringer å bygge på verken når det gjelder bruk eller implementering. Denne usikkerheten er verd å ta med i betraktningen, og prosjektet diskuterte mulig benyttelse av XP(Extreme Programming) eller en eventuell evolusjonær metode. Med disse metodene ville vi relativt raskt kunne komme med løsnings -og designskisser som kunne presenteres for oppdragsgivere og brukergruppe. Dette er fordelaktig da det vil kunne bidra med å visualisere løsningen og 'hjelpe til' med å fremme videre brukerkrav. Det ferdige produktet kan også selges til andre kjeder om det blir en suksess. Det er ikke sikkert det er samme utviklere som står for jobben med å tilpasse systemet til det nye miljøet, derfor er dokumentasjon et viktig punkt. Om vi velger XP som modell vil det meste av dokumentasjonen være direkte i kildekoden. Det er ikke bra nok om helt nye personer skal jobbe med systemet. I tillegg kan XP gi et bilde av systemet tidlig som kan vise seg å ikke være gjennomførbart ved integrasjon av alle komponentene. Dette gjelder f.eks skjermbilder og responstid. De programmessige utfordringene er ikke så store, og Side 6 av 9 4/19/2005

7 bruk av to personer sammen da de programmerer enkel funksjonalitet blir dyrt. Ellers er det vanskelig å planlegge et XP prosjekt med tanke på tids- og ressursbruk. Ulempene med en evolusjonær metode er at den vil kunne være misvisende i den forstand at det presenteres forslag til løsninger som muligens senere viser seg å ikke være gjennomførbare ved integrering med resten av systemet. Videre vil løsningen være vanskelig å selge da det kan være vanskelig å se en helhetlig struktur i systemet. Da prosjektet vurderer brukeren av systemet som erfaren i den forstand at prosessene den/de skal gjennom er kjent fra flere år med handling. De er dermed i stand til å komme med klare krav og ønsker om hva de vil at et slit system skal kunne gjøre. Prosjektet mener at man vil i stor grad være i stand til å utarbeide klare krav og å kunne se en helhetlig løsning på et tidlig tidspunkt. Konklusjonen ble dermed at verken XP eller en evolusjonær metode ikke vil være hensiktsmessig. RUP ble vurdert til å være en systematisk og velorganisert modell. Dette ville gitt prosjektet et strukturert og fullstendig rammeverk for utviklingsløpet. Modellen er åpen for endringer og har en inkrementell tilnærming. RUP er imidlertid relativt komplisert og meget omfattende, og det vil kreves ressurser i prosjektet med spesifikk RUP-kompetanse for å kunne utnytte denne modellen effektivt. Prosjektet vurderte omfanget av oppgaven slik at det ikke vil være behov for en så omfattende metodikk. I tillegg har ingen i prosjektorganisasjonen kompetanse eller erfaring i bruk av RUP. Som nevnt vil utviklingen bære preg av ny teknologi og det vil være behov for omkoding og gjentagende testing, samt endrende krav underveis. Grunnet at ressursene i brukergruppen består av kunder uten tilknytning til kjeden på annen måte, ville det være fordelaktig med en planleggbar modell. Dette peker mot behovet for en mer sekvensiell modell som i tillegg kan ivareta fleksibiliteten nevnt over i form av endringer i krav ol. Prosjektet så også for seg at systemet lett kunne deles i flere deler som for eksempel terminalapplikasjon, applikasjonsserver-moduler og administrasjonsklient, og at en inkrementell metode var aktuell. Behovet for en evt. evolusjonær tilnærming innen utviklingen av noen områder i systemet var også tilstede, noe som ville være mulig å kunne kombinere i utviklingen av inkrementer. Modellen vil også kunne tilrettelegge for å få på plass de viktigste elementene i løsningen for så jobbe videre ut i fra det. Modellen passer også godt med at det vil kunne foreligge relativt godt definerte krav. I tillegg er dette en løsning som er lett og selge til oppdragsgiver. Det enkelt å se fremgangen etter hvert inkrement, og vi kan vise til en god planlegging om hva som skal gjøres når. Vi vet også ganske godt når vi trenger innspill fra de ansatte i butikken. Prosjektets konklusjon i valg av utviklingsmodell var at en inkrementell tilnærming med evt. innslag av evolusjonære metoder i enkelte inkrementer er mest fordelaktig. Side 7 av 9 4/19/2005

8 5. Risikoanalyse Identifikasjon, analyse og planlegging. Beskrivelse Risiko Strategi Nøkkelpersonell forsvinner grunnet sykdom eller andre faktorer. Sørge for at alt dokumenteres tilstrekkelig. Allokering av ny ressurs. Vanskelig eller umulig å skaffe ressurser med riktig kompetanse. Brukere/Ansatte innehar ikke riktig kompetanse for prosjektet, og opplæring er umulig/vanskelig å gjennomføre. Brukere/Ansatte får ikke avsatt nok tid til deltagelse i prosjektet. Eksisterende teknologi kan ikke imøtekomme operasjonelle krav. Valgt plattform kan ikke støtte opp om funksjonelle og operasjonelle krav. Kvaliteten på komponentene i systemet er for dårlig for å kunne oppfylle brukernes krav og forventninger. Løsningen blir for teknisk krevende for dagens teknologi. Underleverandører kan ikke levere etter avtale. Omorganisering gjør at prosjektets eierskap og forankring svekkes. Organisasjonen/oppdragsgiver går konkurs eller får finansielle problemer. Endringer i krav som får konsekvenser for store deler av løsningen og fører til endring av design. Kunde/Bruker forstår ikke konsekvensene av endringer. For lave estimater gjør at budsjett for kostnader og/eller tid overskrides, og prosjektet kan ikke gjennomføres. Høy Høy Høy Skolering av eksisterende ressurser. Se på muligheter for forlenget tidsfrist. Forlenge tidsfrist. Sette av tid og ressurser til skolering. Sørge for riktig forankring i ledelsen slik at disse ressursene frigis. Vurdere oppgradering av teknologien. Revisjon av krav. Revisjon av plattformvalg eller gjennomgang av krav. Følge rutiner som sikrer kvalitet på komponenter. Utvide tidsrammer. Revider krav og forventninger til systemet. Forenkle modulene. Sørge for solide avtaler med underleverandører. God presentasjon og riktig argumentering ovenfor ny ledelse. Gjøre en undersøkelse om deres økonomi før kontrakter inngås. Jobbe bra med design av løsningen, ta hensyn til alle foreliggende krav. Gi tilbakemelding om konsekvenser av endringer. Gjøre en god planlegging av ressurser i forkant av prosjektet. Side 8 av 9 4/19/2005

9 6. Kvalitetssikring For å sikre kvaliteten av arbeidet mens vi har jobbet, har versjonsstyring og samtaler eller møter oss imellom vært svært viktig. Vi har diskutert oss imellom før vi har gått i gang med nye deler av prosjektet, og dette har ført til liten tvil om hvilke arbeidsoppgaver den enkelte har hatt. Vi har satset på mye selvstendig arbeide og strebet for å gjøre alle møter så korte som mulig med kun gjennomgang av uavklarte punkter samt ny fordeling av videre arbeid. Verktøyene vi skal bruke er beskrevet i konfigurasjonsstyringsnotatet. 7. Gjennomføring 7.1 Hovedaktiviteter Prosjektet vil bestå av flere hovedaktiviteter. Aktivitetene strekker seg fra prosjektstart til systemet er ferdig testet og implementert og er beskrevet i vedlagt prosjektplan/gantt-skjema. Side 9 av 9 4/19/2005