1. Mål og rammer 1.1. Bakgrunn I elektronikkavdelingen på TOPRO har produktene som behandles i arbeidsgruppene en følgeseddel der mye informasjon om prosessen føres. Denne føres videre på regneark og lagres manuellt på intranett. Dette skaper treghet i dokumenteringen og produktflyten, og det er vanskelig å få oversikt over hvor dette oppstår. TOPRO vil kvitte seg med papirdokumentering av produktene som blir produsert, og vil derfor digitalisere dette ved hjelp av QR kode. Over lang tid har de hatt store problemer med å holde orden på hvor produktene befinner seg og om det er produksjonsfeil eller ikke. Det skapes for mye papirarbeid i sammenheng med produksjonen og dette vil de nå gjøre elektronisk. Dette er informasjon som er meget viktig, men som er vanskelig å finne eller blir borte pga. for mye papirdokumentasjon. 1.2. Prosjektmål 1.2.1. Effektmål Vi håper dette prosjektet vil effektivisere måten TOPRO sporer og holder oversikt over produktene igjennom prosessene deres, samt å spare de for mesteparten av det nåværende papirarbeidet, ved å gjøre systemet elektronisk. Eventuelt gi de et godt grunnlag for et sporingssystem de kan videreutvikle. Ved å analysere data hentet med vårt system, vil det være mulig å effektivisere arbeidet og forbedre leveransetiden.vi vil også at prosjektet skal kunne benyttes til å vise fremtidige arbeidsgivere noe om kunnskapene og erfaringene vi har tilegnet oss i løpet av bachelorgraden. 1.2.2. Resultatmål Gruppens mål med prosjektet er å tilegne seg reell arbeidserfaring ved å utføre vår hittil desidert største prosjekt. Ikke minst ved at vi må forholde oss til en oppdragsgiver hvor vi må igjennom en faktisk prosess for å finne en passende løsning, men også ved at reell arbeidserfaring vil minke overgangen ut i arbeidslivet. Vi vil også tilegne oss mye ny kunnskap rent faglig i løpet av prosjektet. Gruppens medlemmer skal forsøke å jobbe med oppgavens fagområder (kap. 2.1), og opparbeide seg reell erfaring med prosjektarbeid, spesielt innen valgt systemutviklingsmetode, Extreme Programming. Sporingssystemet skal kunne lagre nok informasjon om produktet i prosessen til å kunne føre noenlunde detaljert statistikk. Det skal også kunne erstatte mye av informasjonen som i dag føres på papir. Det vil bli mulig å se hvor produktet befinner seg i prosessene til enhver tid.
1.3. Rammer Dette prosjektet skal utføres i samarbeid med og for TOPRO. De vil stille med teknisk utstyr etter avtale til oppgaven, mens vi i tilegg vil benytte freeware til koding og databaser. Noe aktuell programvare for tjener og klient vil f.eks. være Eclipse, nettleser, Apache, PHP, MySQL, QR kodeleser og lignende. TOPRO ønsker at systemet skal kunne brukes fra en tablet. Vi kommer innledningsvis til å satse på en vanlig applikasjon for QR kode skanning, og en nettleser med en webapplikasjon der brukerne legger inn informasjon om produktet de skannet. Prosjektet skal utvikles i følge Plan for gjennomføring, kap. 6, etter vår tilpasning av utviklingsmetoden Extreme Programming. Vi bruker prosjektstyringsverktøyet Zoho Projects til å planlegge fremdrift og gjøremål. Blandt tidsfristene er milepælene våre, vår egen frist for utgivelse av programvaren og frist for endelig innlevering den 15. mai, som er fastsatt av Høgskolen i Gjøvik. Ressursbehov For å kunne møte behovet for en on site customer i Extreme Programming behøver vi et rom på TOPRO der gruppens medlemmer kan drive med gruppearbeid. Gruppen stiller med egne utviklermaskiner og egen 10 Android tablet for testing internt i gruppen. Vi behøver også en vanlig stasjonær PC til testing av systemets tjener. Operativsystemet bør være ett av følgende: Windows 8 (ikke RT), Windows 7, Windows Vista eller Windows XP. Om TOPRO allerede har en ledig PC vil den antagelig være tilstrekkelig. Om TOPRO ønsker å teste vår programvare, tror vi de kommer til å behøve tablets. Vår foreløpige anbefaling er Asus Transformer Pad TF300T Wi Fi (10 tommer) montert i stativ på arbeidsstasjonene. Til personell som kan være på flere arbeidsstasjoner anbefaler vi Asus Nexus 7. I første omgang vil ti tommeren være mest aktuell. Vi anbefaler disse på bakgrunn av relativt oppdatert maskinvare, og antatt god kvalitet, kombinert med en bra pris. Om ønskelig kan vi komme med en ny anbefaling før levering av sluttrapport den 15. Mai.
2. Omfang 2.1. Fagområdet TOPRO s avdeling som dette prosjektet skal forbedre er elektronikkavdelingen. I dag består dette området av flere prosesser som kretskortene må gjennom før det blir levert til kunder som et ferdig produkt. Kretskortene blir sent til TOPRO fra andre bedrifter med ferdiglaget baner der komponentene kan loddes på. Alle kretskort som blir levert har med et følgekort som er et dokument som forteller hvilke komponenter og antall den skal inneholde, samt står det hvilke stasjoner den skal innom under produksjonsprosessen. Elektronikkavdelingen har en egen komponent avdeling der det finnes en maskin som inneholder alle komponentene og henter de spesifikke som skal brukes til den spesifikke bestillingen som har blitt gjort. Når komponentene har blir hentet blir de sendt til første stasjon, Samstilling 1, sammen med kretskortene. Her blir komponentene maskinmontert til kortene. Når dette har blitt gjort blir kassene med kort sendt videre gjennom flere stasjoner der de registeres på følgekort på hver stasjon. Etter kortene er igjennom alle stasjonene blir de pakket og sendt til kunden. TOPRO holder orden på produktene ved hjelp av følgekortet og her finner de informasjonen som må til for å fullføre jobben. Her finner de arbeidsordrenr. som er bestillingsnr til kunden, kundenr. som identifiserer hvilken bedrift det er og artikkelnr. som forteller om varetype. Informasjonen som finnes på følgekortene blir også manuelt skrevet som excel filer på lagringsområdet på intranettet til TOPRO. Produktene blir identifisert på intranett via arbeidsordrenr. TOPRO vil endre på alt dette ved å gjøre sporingssystemet elektronisk. Følgekortene skal inneholde en strekkode eller QR kode. Når en ansatt skanner denne koden skal informasjonen av et produkt dukke opp på en skjerm. Denne informasjonen skal bli hentet fra databasen og skal inneholde arbeisdordrenr, artikkelnr og kundenr. Ved hjelp av dette systemet skal det bli mindre papirarbeid, slutt på manuel lagring i databasen og mindre tap/svinn av produkter. 2.2. Avgrensning Vi i prosjektgruppen skal lage et nytt elektronisk sporingssystem etter deres ønske. Systemet kunne utnytte strekkode eller QR kode, men etter ønske fra TOPRO og diskusjon i gruppen falt valget på QR kode. Noen av grunnene inkluderer mengden informasjon som kan lagres og mulighet for å lære. Vi introduserte ideen til dem om å montere faste tablets på hver stasjon der kretskortene må gjennom. Følgekortene vil nå inneholde en QR kode som blir skannet ved hjelp av de fastmonterte tabletene, og informasjonen vil da dukke opp elektronisk på skjermen. Vi skal kode nettsiden som skal komme opp på skjermen etter å skanning av koden. Her skal brukeren få full overvåkning av produktet. Vi skal også programmere serveren på internnettet til TOPRO som leverer sporingssiden og overvåkningssiden til nettleseren på tableten.
2.3. Oppgavebeskrivelse Oppgaven går ut på å lage et elektronisk sporingssystem som leser QR kode fra en følgeseddel på arbeidsordre for et produkt som genereres i TOPRO s logistikksystem, M3. Denne koden inkluderer en unik ID som identifiserer kretskortet i systemet. Systemet skal bruke denne koden til å vise hvor et produkt befinner seg, hva som har blitt gjort, hva som må gjøres, om produktsjonsfeil forekommer, hvem som er kunden og leveringsdato. Systemet skal kunne spore en arbeidsorde fra den slippes til den er sendt, holde kontroll på alle feilkort, samt produkter underveis. TOPRO ønsker også en modul som viser alle produkter i produksjon, hvor de er og når de skal leveres med mulighet for å legge inn og se prioriteringer. Detaljer som tidsstempler for registreringer og status for feilkort skal lagres til bruk i denne overvåkningsmodulen. Tidsstemplene skal kunne brukes til å måle tidsbruk innad i prosessen, mellom prosesser og mellomlagringstid. Det skal utvikles en klient som kjører på arbeidsstasjonene, og denne skal brukes til å samle inn informasjon om arbeidet på arbeidsstasjonene. Om det viser seg at vi har tid til mer, så skal det utvikles støtte for kvalitetskontroll i sporingen. Når en stor bestilling av kretskort har vært gjennom en maskin og blitt behandlet, vil det bli utført en kvalitetskontroll av produksjonsordren. Her skal en som er kvalifisert til dette kunne logge seg inn, skanne og loggføre utfallet av kontrollen. Det ønskes også mulighet for å inkludere lenker til dokumentasjon (testinnstruks, arbeidstegning) på arbeidsstasjonene.
3. Prosjektorganisering 3.1. Ansvarsforhold og roller 3.1.1. Ansvarsforhold Det er hvert medlems eget ansvar å forholde seg til gruppens regler (nærmere forklart i pkt. 3.2.2). Men uansvarlig oppførsel i henhold til grupperegler og unnlatelse av oppmøte vil føre til inngrep av gruppeleder og evt. diskusjon med hele gruppen. Vi må også forholde oss til oppdragsgiver på en profesjonell måte og løse oppgaven etter deres behov. Samtidig som de må forholde seg til oss ved å gi oss mulighet for å utføre acceptance testing, og være tilgjengelige for spørsmål. 3.1.2. Roller I et Extreme Programming prosjekt blir hvert medlem på gruppa en altmuligmann. Alle gjør litt av hvert. Derfor har alle ansvar for å utvikle systemet på flere områder. Knut Remi Løvli: Er gruppeleder og teknisk ansvarlig (kalender, webside, loggbok, prosjektstyring, sikkerhetskopiering av dokumenter, etc...) Fabrizio Andreas Sepulveda: Er gruppens sekretær. Skal føre ukentlig logg for å holde styr over hva som har blitt gjort og hva som skal gjøres. Anders Slåtten: Ansvar for benyttelse og tilpasninger av Extreme Programming i prosjektet. Oppdragsgiver: Frode Kojen og/eller Even Myhre har ansvar for å avgjøre om systemet kommer gjennom acceptance testene, revidering av eksisterende user stories og nye user stories. Veileder: Frode Haug har ansvar for å være til stede på veiledningsmøter han og gruppen har avtalt på forhånd. Han har også ansvar for å godkjenne prosjektplanen. 3.2. Rutiner og regler i gruppen 3.2.1. Rutiner Vi har en fast rutine på å jobbe med prosjektet hver dag fra Mandag til Fredag, utenom de dager det har blitt avtalt endringer. Alle i gruppen skal også føre logg etter en utført oppgave. Disse loggene vil bli slått sammen til en ukelogg som publiseres på nettsiden vår i slutten av uken. Det skal også avholdes acceptance test hver fredag sammen med minst en fra TOPRO før ukeloggen blir publisert på nettsiden vår. Første arbeidsdag i en iterasjon skal gruppen avholde et statusmøte. Her skal alle på gruppen snakke om hvordan de ligger an når det kommer til oppgaven deres, hva som må gjøres, og
hvilke user stories som skal med i iterasjonen. Det skal også vurderes om noen user stories kan deles opp. Før dagens programmeringsarbeid starter, skal det diskuteres hvem som skal jobbe i par og på hvilke user stories. 3.2.2. Grupperegler 1. Hvordan tas beslutningen når det ikke oppnås enighet? a. Om gruppen ikke er enige om en beslutning, avgjøres saken ved å stemme over den. Blir det uavgjort avgjør gruppeleder. 2. Skal det være en prosjektleder? a. Vi har valgt Knut Remi Løvli til gruppeleder. 3. Skal prosjektlederjobben gå på rundgang? a. Gruppeleder kan byttes ved behov hvis nåværende gruppeleder ikke fungerer eller blir borte ved sykdom. Dette diskuteres og avtales i et gruppemøte. 4. Hvilke sanksjoner kan benyttes dersom et medlem ikke utfører avtalt arbeid? a. Det medlem som ikke har utført avtalt arbeid må levere en skriftlig forklaring til gruppen, på hvorfor avtalt arbeid ikke har blitt utført. Ny avtale om arbeid som skal utføres utarbeides. Muntlig advarsel overleveres. 5. Hva skal til for at et medlem kan avskjediges fra gruppen? a. Ikke utført arbeid etter avtale tre ganger uten god grunn eller utelatt å melde ifra. Samt med advarsel om mulighet for avskjedigelse. 6. Hvordan skal avskjedigelsen gjennomføres. a. Etter diskusjon i gruppen vil da tiltalte medlem få et avskedighetsbrev som også vil bli utlevert til veileder, arbeidsgiver og HiG. 7. Dersom det påløper kostnader, hvordan fordeles disse? a. Alle kostnader skal være planlagt og avtalt med arbeidsgiver. Oppstår uforutsette kostnader som arbeidsgiver bør ta ansvar for, avtales møte der kvitteringer og bilag overleveres. Resterende fordeles likt mellom gruppen. 8. Hvem skal ha retten til å signere på vegne av gruppen? a. Gruppeleder har fullmakt til å signere på vegne av gruppen b. Gruppens nestkommanderende utfører signeringer i situasjoner hvor gruppeleder ikke er tilgjengelig.
4. Planlegging, oppfølgning og rapportering 4.1. Valg av SU modell Vi har valgt Extreme Programming (XP) med tilpasninger for utviklingsprosjektet og bacheloroppgavens natur. Oppdragsgiver ønsker at vi eller de kan legge til flere krav om vi blir ferdige med de innledende kravene. Derfor er vi avhengige av en smidig systemutviklingsmodell. Modeller som RUP, fossefall og spiral er derfor uegnet. Extreme Programming er foretrukket over SCRUM på grunn av at vi jobber sammen i gruppe, og den høye møteaktiviteten i SCRUM er ikke nødvendig. Alle på gruppa har heller ikke samme erfaringsnivå på prosjektets fagområder, så vi kan utnytte XP s parprogrammeringskonsept til å forbedre medlemmenes evner og det totale produktet gruppen evner å levere. 1 XP inkluderer bruk av en systemmetafor. Siden sluttrapporten krever at (arkitektur)designet er inkludert, bruker vi arkitekturdesignet som systemmetafor. XP innebærer krav som kan endres underveis. Når kravene endres skal kravspesifikasjonen oppdateres. Gode standarder for kommentering av kode skal også følges. Mer om dokumentasjon i prosjektplanens kap. 5.1 og 5.2. 4.2. Hovedinndeling av prosjektet Prosjektet er delt inn i tre faser: Forprosjekt, utviklingsfase og oppsummering. Forprosjektet inkluderer utarbeidelse av prosjektplan og prosjektavtale. Utviklingsfasen inkluderer tre iterasjoner innen Extreme Programming, hvor hver fase inkluderer planlegging, testing/utvikling, dokumentasjon, rapporter og mer. I oppsumeringsfasen skal prosjektets resultater samles i en ferdig sluttrapport som følger Høgskolens krav til sluttrapport for systemutviklingsprosjekter. Etter innlevering av sluttrapport skal det lages en presentasjon av arbeidet som skal framføres. 4.3. Plan for statusmøter og beslutningspunkter Før utarbeiding av iterasjonsplanen avholdes et statusmøte hvor vi lager en oversikt over hva som er gjort og hva som må gjøres. Beslutningspunktene våre inkluderer disse møtene og acceptance testene som avholdes hver fredag. Hvert statusmøte i starten av en iterasjon brukes til å velge iterasjonens innhold. På statusmøte 3 (se kap. 6.3) skal det være avgjort om valgfrie user stories skal med. 1 http://www.hig.no/imt/bacheloroppgaver/informasjon (Vedlegg C)
5. ORGANISERING AV KVALITETSSIKRING 5.1. Dokumentasjon, standardbruk og kildekode Dokumentasjon Det finnes forskjellige typer dokumentering som håndteres forskjellig. Følgende dokumentasjon skal være med. Prosjektplan Kravspesifikasjon Arkitekturdesign Systemdokumentasjon Plan for gjennomføring ligger også i prosjektstyringsverktøyet. Denne planen skal oppdateres løpende under prosjektet. De øvrige dokumenter skal også revideres under prosjektets gang. Spesielt aktuellt er det å endre på Gannt skjema. Ukentlig loggføring som er skrevet av sekretæren (Fabrizio Sepulveda), skal lastes opp på nettsiden til gruppen. Skal også være lagret hos sekretæren og lastes opp på Dropbox. Dokumenter som skal være med i sluttrapporten skal være lagret hos personen i gruppen som skrev dette dokumentet, og lastet opp på Dropbox så den er tilgjengelig for alle i gruppen. Dokumentene skal også lagres på en backup minnepinne eller ekstern harddisk som er felles for gruppen. Det blir også tatt backup av Google Drive og Dropbox. Standardbruk Subversion skal brukes som felles versjonskontrollsystem. Kode skal ha vært igjennom enhetstesting før commit (helst flere ganger daglig). Kildekode Test først utvikling Dele opp kildekode i segmenter og teste dem for seg selv. Slå sammen segmentene etterhvert som de oppfyller kravene. Lagring av programkode lastes automatisk mellom maskinene til gruppemedlemmene og opp mot en server. Backup av kode blir tatt automatisk etterhvert som de blir lagret, og det vil i tilegg bli tatt en ekstra manuel backup.
5.2. Konfigurasjonsstyring For å holde på integriteten og sørge for at dokumentasjonen til de forskjellige versjonene blir opprettholdt, vil vi benytte jevnlig backup på alle dokumenter. Vi vil ha muligheter for gjennoppretning og backup av eldre versjoner. Samt benytte gode standarder for kommentering, forklaring av filinformasjon og kildekode. Siden vi bruker Extreme Programming som utviklingsmodell vil vi ha enhetstestet nytt innhold i programmet før det skrives til versjonskontrollsystemet. 5.3. Risikoanalyse(identifisere, analysere, tiltak, oppfølging) Konsekvens Sannsynlighet 1. Liten 2. Moderat 3. Stor 4. Svært stor 4. Svært sannsynlig 3. Meget 2 6 sannsynlig 2. Middels sannsynlig 1. Lite sannsynlig 4 5 1, 3 Sannsynlighet * Konsekvens = Risiko. Lav risiko: akseptabel risiko, tiltak er ikke nødvendig. Middels risiko: akseptabel risiko, men tiltak bør vurderes. Høy risiko: uakseptabel risiko, eventuelle tiltak er viktig. 1) Kan teknologien sette begrensninger for hva som kan gjøres? Sannsynlighet (1) * Konsekvens (4) = 4 = Lav risiko. Vi vil benytte oss av SQL, Java, Javascript, PHP og QR kode. Dette er godt utprøvd teknologi med mange tileggsfunksjoner og utbredt dokumentasjon. Eventuelle tiltak for å unngå dette vil være å først fordype oss i teknologien for å lære oss mer om eventuelle begrensninger, før vi starter å bruke teknologien. Eller finne tileggsfunksjoner som er laget for spesielle bruksområder, og ment for å holde disse teknologiene oppdatert i forhold til nyutgitt teknologi.
2) Hvis medlemmer setter seg fast grunnet liten erfaring med teknologien? Sannsynlighet (4) * Konsekvens (2) = 8 = Middels risiko. Alle gruppens medlemmer har noe eller ingen erfaring med bruk av de forskjellige teknologiene. For å unngå stopp pga. mangel på kunnskap eller omskriving av funksjoner og filer, vil lesing av dokumentasjon og fordypelse innen teknologien være nyttig før igangsetting. Eller at hvert medlem spesialiserer seg innen forskjellige teknologier for så å hjelpe de andre hvis dette problemet oppstår. 3) Hva hvis prosjektet ikke opprettholder sine kvalitative mål? Sannsynlighet (1) * Konsekvens (4) = 4 = Lav risiko. Vil benytte mye testing og godt samarbeid med arbeidsgiver for å sikre de kvalitative målene. TOPRO har også ansatt en bedrift til å gjennomgå og integrere systemet vi lager med intranettet på frabrikken. Dette for å unngå at innvesteringer går tapt, hvis i værste fall systemet må vrakes pga. feil kravspesifikasjoner eller at det ikke har blitt ferdigutviklet nok. 4) Hva hvis et medlem blir borte eller ikke gjør sin del av jobben? Sannsynlighet (1) * Konsekvens (2) = 2 = Lav risiko. Dette er den siste store oppgaven for å fullføre utdanningen, noe som vil gi god motivasjon for en siste innspurt. Men hvis dette skulle inntreffe vil arbeidsmengden øke betraktelig for de gjenværende gruppemedlemmene. Noe gruppereglene er til for å forebygge, samt en nedskalering av arbeidsmengden kan bli nødvendig. 5) Levert feil vare fordi kravspesifikasjonene har blitt feil. Sannsynlighet (1) * Konsekvens (3) = 3 = Lav risiko. Siden vi benytter oss av XP som utviklingsmodell vil vi stadig møte med oppdragsgiver og kunne endre kravspesifikasjonene etter behov. Vi vil også utføre enhetstesting med oppdragsgiver hvor han vil få bedre innsikt i hvordan systemet kommer til å ende opp. 6) Ikke klarer å ferdigutvikle systemet innen tidsrammen. Sannsynlighet (3) * Konsekvens (2) = 6 = Middels risiko. Vi ser at det ikke vil være mulig å oppfylle de primære kravene innen utgivelsesdatoen. Oppsummeringsfasen skifter da fokus fra å hovedsaklig dokumentere arbeid gjort, til å dokumentere hva som gikk feil og hvordan det kunne vært unngått.
6. PLAN FOR GJENNOMFØRING Vi har tilpasset prosjektets milepæler, faser og innhold etter kravene stilt av henholdsvis HiG og TOPRO. Vi kjører tre iterasjoner. Hver iterasjon inkluderer en statusrapport og ting som acceptance testing, en leveranse av foreløpig programvare og mer. Planene som utarbeides på forhånd vil være midlertidige artefakter, og vil oppdateres i prosjektstyringsverktøyet, evt. egne dokumenter for dette. I Extreme Programming er iterasjonsplanenes faktiske innhold fredet fram til planleggingsmøtet. Derfor vil ikke våre user stories være inkludert i noen iterasjon i første utkast til Gannt skjema, men snarere spredt utover utviklingsfasen. Statusmøtene vil også brukes til å utarbeide iterasjonsplanen. 6.1. User stories Iterasjon 1 Registrere kasse (og avvikskort) Nok informasjon skal lagres under registrering til å føre statistikk over tidsbruk. Statistikken skal inkludere tid brukt i mellomlagring og tid brukt i prosess og på arbeidstasjonene. Et kort (egentlig kasse), og antall skal kunne registreres (skannes) inn når det ankommer en arbeidsstasjon. Om det er avvik på et enkeltkort skal avvikstypen, artikkelen, hvor det havner kunne registreres. Leveringsdato skal være synlig. Når kortet forlater arbeidsstasjonen skal det kunne registreres ut. Vilkår Data skal kunne skrives inn via webgrensesnitt. Scanne inn: Det skal registreres et arbeidsordrenummer Det skal registreres et artikkelnummer Det skal registreres et antall i batch Det skal registreres et tidsstempel Scanne ut: Det skal registreres kasse og evt. avvik Om avvik er registrert skal en av avvikstypene manko, feil og vrak kunne registreres. Om vrak skal antall i batch kunne endres. Scanne ut skal ha en relasjon til scanne inn.
Tilstanden i prosessene skal kunne overvåkes Det skal være mulig å se hvor kortene er i systemet til en hver tid. Dette skal være presentert på en oversiktlig og naturlig måte, gjerne grafisk. Bruker skriver inn et AO nummer, og det vises en oversikt over hvor kassene (inkl. serienummer på feilkort i kasser) er. Vilkår Data skal vises i webgrensesnitt Data vist skal avhenge av AO nummer tastet inn Det skal vises en liste over arbeidsstasjoner kassen har vært på Det skal vises tidsstempel for innregistrering for hver arbeidsstasjon Det skal vises tidsstempel for utregistrering for hver arbeidsstasjon Det skal regnes ut tid fra innregistrering til utregistrering. Det skal regnes ut tid siden forrige utregistrering. Det skal regnes ut total tid siden første innregistrering Data skal være presentert i tabell Kasser med feilkort skal være inkludert i tabell Antall feilkort skal være inkludert i tabell Restrerende iterasjoner Hva som kan gjøres i systemet skal være forskjellig alt etter hva slags stasjon du er på En bruker skal kunne logge inn på en arbeidsstasjon, og aktuelle valg skal komme opp, alt etter hva brukeren skal gjøre. Martin stasjonen (reparasjon) skal kunne se prioritet på kasser med feilkort. Foreløpig estimat: 2 uker Det skal være lett å bruke enhet på arbeidsstasjon Unødvendig informasjon og valg bør ikke være til stede. Vanlige folk skal kunne bruke systemet uten mye trening. Foreløpig estimat: 1 uke Om antall kort telt i kasse er feil skal det varsles om dette Når en kasse forlater en stasjon må antall kort ha vært tastet inn. Avviker dette fra forventet antall skal bruker varsles om dette Varsel om kasse som ikke er scannet ut Om en kasse ikke har vært registrert ut, skal neste stasjon få beskjed om at den må skannes ut på forrige stasjon.
En arbeidsordre skal kunne arkiveres når den forlater pakking. Etter arkivering skal det ikke kunne registreres nye hendelser for arbeidsordren. Systemet på enheten skal se litt ut som websiden til TOPRO (Valgfritt) Design og layout kan være inspirert av websiden til TOPRO. Foreløpig estimat: 1 uke Det skal være mulig å angre lagring av data i etterkant (Valgfritt) Om feil data (f.eks. antall) blir tastet inn skal en ansvarlig kunne gå tilbake å endre på eller slette disse. Foreløpig estimat: 2 uker Det skal være mulig å legge til funksjonalitet i etterkant for å vise dokumentasjon når et kort har blitt scannet (valgfritt) Det skal være mulig å lett få tilgang til et korts relevante arbeidsinnstukser, tegninger og lignende når det skannes. Det skal være mulig å gjøre en kvalitetskontroll etter IPC60A (Valgfritt) Kunne kvittere for godkjent/ikke godkjent kvalitetskontroll, samt kunne rollebacke. Eventuelt med mulighet for kommentar på hva som er feil. Estimat 1 uke. Dokumentasjon for kort skal være tilgjengelig når følgeseddelen skannes. (Valgfritt krav) I tillegg til registrering av kort skal det være mulig å se dokumentasjonen for kortet i H2. F. eks. testinnstruks, arbeidstegning. Det skal være mulig å legge til funksjonalitet for å vise/endre rekkefølge på prosesser (Valgfritt) Det skal være mulig å legge til og ta bort arbeidsstasjoner for et kort. Et kort skal kunne være innom tilleggsprosesser. Foreløpig estimat: 2 uker.
Når det mangler deler til et produkt, skal det automatisk sendes mail/beskjed om manko (Valgfritt) Når en produksjonsordre skal videre til neste stasjon vil det automatisk sendes melding om deler mangler. Slik at mellomlagring blir minimal, og bestilling av deler går raskest mulig. Estimat: 3 uker Endre arbeidsstasjoner i systemet Det skal være mulig å legge til/endre arbeidsstasjoner i etterkant (Valgfritt)
6.2. Tids og ressursplan Gannt skjema Januar Februar Mars April Mai Juni Uke: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Forprosjekt Innl. prosjplan. 28/1 Innl. prosjavt. 28/1 Webside Iterasjon 1 Iterasjonsplanmøt 4/2 Accept. test 1 8/2 Accept. test 2 15/2 Accept. test 3 22/2 Iterasjon 2 Leveranse 1 25/2 Iterasjonsplanm. 25/2 Statusrapport 25/2 Accept. test 1 1/3 Accept. test 2 8/3 Accept. test 3 15/3 Iterasjon 3 Leveranse 2 18/3 Iterasjonsplanm. 18/3 Statusrapport 18/3 Accept. test 1 22/3 Accept. test 2 29/3 Accept. test 3 5/4 Iterasjon 4 Leveranse 3 8/4 Iterasjonsplanm. 8/4 Statusrapport 8/4 Accept. test 1 12/4 Accept. test 2 19/4 Oppd. tab anb? 19/4 Accept. test 3 26/4 Endg. leveranse 1/5 Forsk.videreutv? 1/5 Oppsummering Sluttrapport 15/05 Framføring 4 6/6
Ukeplan 8 Mandag Tirsdag Onsdag Torsdag Fredag 9 Gruppearbeid 10 Gruppearbeid Gruppearbeid Gruppearbeid 11 12 Gruppearbeid 13 14 15 Acceptance test Iterasjon Statusmøte Start syklus User stories Acceptance test Gjenta syklus Leveranse 6.2. Liste over aktiviteter (Work Breakdown Structure) Bacheloroppgave Forprosjekt Prosjektplan Prosjektavtale Webside Loggbok Statusrapporter Oppgavebeskrivelse Prosjektdokumenter Sporingssystem Kortregistrering Inn Feilkort Typer Art./ant. Ut Overvåkning Administrasjon Produksjon Statistikk Tid i mellomlagring Tid i prosess Databasedesign Sluttrapport Prosjektplan Kravspesifikasjon Arkitekturdesign Implementering Testing Diskusjon av resultater Konklusjon
6.3. Milepæler og Beslutningspunkter Milepæler og beslutningspunkter Dato Innlevering av endelig rapport 15/05 Framføring 04 06 /06