Prosessdokumentasjon

Prosessdokumentasjon

2 S i d e

PROSJEKT NR. 2010-28 HOVEDPROSJEKT I DATA Hovedprosjekt tittel: WebStorage Prosjektdeltagere: Dato: 3.1 mai 2010 Antall sider: Son Tung Cao Hui Na Nina Gu Halvor Kokkin Iounut Rebegea Andy Trinh Oppdragsgiver: YIT Sammendrag: s148196 s148144 s146097 s148199 s148216 21 Intern veileder: Geir Skjevling Kontaktperson: Øyvind Sveberg Prosjektet er utviklet for YIT og er ment som et system for å lettere administrere og få oversikt over utstyrsparken, samt sjekke inn og ut verktøy i den daglige driften. Dette dokumentet er prosessrapporten, og er en redegjørelse og dels kritisk analyse av prosessen vi har vært gjennom mot et ferdig sluttprodukt. Prosessrapporten er primært en måte for dem som skal evaluere hovedprosjektet vårt til å få et visst inntrykk av hvordan gruppen har fungert og hva vi har lært av prosessen. 3 S i d e

1 FORORD Denne dokumentasjonen inneholder en utdypning og definisjon av gruppens arbeidsmetoder og oppgaver i forbindelse med 3. årets hovedprosjekt 2010 på Høgskolen i Oslo. Vi vil prøve å redegjøre for fremgangsmåte og tenkt strategi i løpet av dette prosjektets gang, dels ved å kronologisk oppdatere dokumentet underveis, dels ved å se på prosessen i retrospekt for å få formidlet et sannferdig bilde av arbeidsretning og mengde, samt skape en kritisk analyse av ting som kunne vært gjort bedre, hva som fungerte eller ikke og så videre. 4 S i d e

2 Innholdsfortegnelse 1 Forord... 4 2 Innholdsliste... 5 3 Innledning... 7 3.1 Fakta om YIT... 7 3.2 YIT og Høyskolen i Oslo... 7 3.3 Om gruppen... 8 3.4 Rollene i gruppa... 9 3.5 Hvorfor YIT hovedprosjekt... 10 3.6 Oppgavens mål... 10 3.6.1 Minstekrav til funksjonalitet... 10 3.6.2 Andre krav til prosjektet... 11 3.6.3 Tekniske krav... 11 3.6.4 Krav fra oppdragsgiver... 12 4 Planlegging og metode... 12 4.1 Planlegging av prosjektet... 12 4.1.1 Planlegging av databasen... 13 4.1.2 Planlegging av websiden... 13 4.1.3 Planlegging av systemet... 13 5 Utviklingsfasene... 14 5.1 Prosjektstart... 14 5.2 De forskjellige fasene under utviklingen av prosjektet... 14 5.3 Innledende arbeid... 15 5.3.1 Prosjektets styringsfase... 15 5.3.2 Implementasjonsfasen... 16 5.3.3 Dokumentasjonsfasen... 16 5.3.4 Avslutningsfasen... 17 6 Kravspesifikasjon... 17 7 Oppsummering og konklusjon... 18 7.1 Kompetanseheving... 18 5 S i d e

7.2 Forbedringspotensial... 19 7.3 Hensikt med produktet... 19 7.4 Produktets bruk... 20 7.5 Konklusjon... 20 8 Kilder... 21 9 Vedlegg... 21 9.1 Styringsdokumentasjoner... 21 6 S i d e

3 Innledning 3.1 Fakta om YIT YIT Together we can do it YIT er Norges ledende leverandør av tekniske bygg- og industri-installasjoner. Hovedtyngden av leveransene ligger innenfor fagområdene inneklima, elektro, automasjon, energisparing, rør, IKT, audiovisuelle løsninger og sikkerhet. Vi er samtidig en ledende leverandør av service på tekniske bygginstallasjoner og tjenester for eiendomsdrift. Selskapet har en årlig omsetning på ca. 4 milliarder kroner og ca. 3300 ansatte fordelt på mer enn 60 steder i Norge. 3.2 YIT og Høgskolen i Oslo Høgskolen i Oslo (HiO) er landets største høgskole med over 12 000 studenter og 1100 tilsatte. Det betyr at bruk av audiovisuelle systemer ikke kan unngås. Det er YIT som levere disse utstyrene. HiO tilbyr et bredt utvalg av studier innefor estetikk, helse, teknologi, journalistikk, økonomi og etc. Det er veldig viktig med gode AV løsninger. Dette er avgjørende for kvaliteten på undervisningen. For studenten blir det mer interessant, og for foreleseren er det et støtteverktøy. I 2009 ble en ny rammeavtale inngått mellom høgskolen og YIT. Avtalen går ut på at YIT er valgt som leverandør og samarbeidspartner for å dekke skolens totale behov for AVløsninger. 7 S i d e

3.3 Om gruppen Gruppemedlemmene i Gruppe28 er følgende personer: Son Tung Cao, s148196 Hui Na Nina Gu, s148144 Halvor Kokkin, s146097 Ionut Rebegea, s148199 Andy Trinh, s148216 Et av gruppemedlemmene har ved siden av å være student på HiO et engasjement hos YIT Statoil som IT-tekniker. I den forbindelse kom han i kontakt med ledelsen og hørte om det var noen oppdrag de kunne gi til oss som kunne forbedre eller forenkle hverdagen til de ansatte "på gulvet" i IT-avdelingen og som ville effektivisere den daglige driften. Resultatet ble at vi fikk et ganske klart definert prosjekt; Sluttproduktet skal være en database med Webgrensesnitt hvor utstyr for utlån til den daglige drift skal kunne registreres med tidsramme og tilhørende informasjon om låne/arbeidstaker. Utfordringene ligger i implementering av tilgangskontroll, brukervennlighet, og administrasjonen som må være idiotsikker. Hensikten er altså å minimere administrasjonskostnadene for bedriften knyttet til utlån av utstyr, men også på et mer folkelig plan å fjerne byråkratiet fra arbeidernes hverdag i mest mulig grad. Øyvind Sveberg på YIT er veldig behjelpelig og informativ på alle henvendelser vi har i forbindelse med prosessen, og i tillegg kan Son Tung Cao aktivt analysere hvilke ting vi må fokusere på og hva som er viktig for arbeiderne i de daglige gjøremål, samt at han er i dialog med evt fremtidige sluttbrukere av systemet når han er på jobb. Vi vil også rette stor takk til medarbeidere av Son Tung som har vært meget behjelpelige med spørsmål 8 S i d e

vi har hatt underveis. Formatet på denne rapporten er foreløpig tilpasset papir, men vi vurderer og adaptere innholdet for Webvisning også. 3.4 Rollene i gruppa Gruppemedlemmer Rollene Beskrivelse Hui Na Nina Gu Halvor Kokkin Andy Trinh Ionut Rebegea Son Tung Cao Prosjektleder/koordinator Forfatter Korrekturleser Hoved forfatter av rapportene. Korrekturleser Sekretær Holder styr på oppmøte, forfatter og dagbok sjef. Programmerer, og styrer alt det tekniske. Kontakt person Forfatter og dokumentansvarlig Nestleder/koordinator Nina hjelper til med databasen og er med på å forme dokumentasjonene. Hun leser i gjennom hva vi har skrevet og setter sammen dokumentene. Halvor har hovedansvaret for utforming av rapportene. Hjelper også til med det tekniske. Andy skriver dagbok og rapporten sammen med Halvor, Nina og Tung. Han har også ansvar for hvem som dukker opp på møtene. Ionut utfører det meste av det tekniske. Alt teknisk stoff går gjennom han. Tung hjelper til med det tekniske og rapportene. Er også kontakt person mellom gruppen og bedriften. Disse definerte rollene beskriver hva våre ansvarsområder er, men er ikke håndfaste. Alle jobber sammen på hele prosjektet og hjelper til på alle områder. 9 S i d e

3.5 Hvorfor YIT som hovedprosjekt YIT trengte en minimalisering av deres store utstyregistrerings program. De har allerede et nå men den er veldig omfattende. YIT avd Vækerø vil gjerne ha en intern database der de kan registrere stasjonære pc er, bærbare pc er og skjermer. De tre hovedutstyrene som går mest av i deres avdeling. Det blir lettere for logistikksjefen å få én oversikt når det kommer til vareopptelling for hvert kvartal. Dette sparer YIT både tid og krefter på. Meningen med WebStorage er at logistikksjefen skal få en lettere jobb både når det gjelder registrering av utstyr og når det kommer til vareopptelling. 3.6 Oppgavens mål Vårt mål er å gjøre hverdagen bedre for logistikk sjefen i YIT. En intern database i hver avdeling skal gjøre jobben deres lettere når vareopptellingen kommer. Utsyr som stasjonærer, laptoper og skjermer skal registreres i databasen. Ved slutten av hvert kvartal vet logistikksjefen nøyaktig hvor mange stasjonære pc er, bærbare pc er og skjermer det er igjen på lageret. Det skal være lett å registrere utstyr og kvittere ut utstyr. Databasen skal hele veien holde telling på utstyrene som har størst verdi og som er mest brukt i avdelingen. 3.6.1 Minstekrav til funksjonalitet Systemet skal kunne gjøre følgende oppgaver / inneha følgende funksjonalitet: Sluttbrukere skal kunne registrere informasjon om grunnlag for uttak av utstyr, ønsket låneperiode, hvem som foretar bookingen, tag-nr på utstyr osv. Grensesnittet skal være lettfattelig og veiledende. Sluttbrukere skal være forhindret fra å kunne gjøre feilregistreringer, uautoriserte slettinger eller innsyn i annen informasjon. Kun administrator skal kunne slette/endre informasjon; dette for å forhindre misbruk og manipulasjon av system og utstyr. Forskjellige typer søk i utstyr og/eller etter hva som er tilgjengelig i en gitt tidsperiode. Søkeresultatet skal også kunne sorteres etter diverse 10 S i d e

kriterier som "ledig/opptatt", person som booker utstyrer per nå, kronologisk etter dato, etter tag-nr osv. Altså kolonnebasert sortering av output fra et gitt søk. Brukere og foretatte bookinger skal ikke kunne slettes av administrator før etter at sluttbrukerkonto har vært deaktivert i en gitt periode. Av avskjedigelser er det viktig å holde på logg av historikk for å avdekke evt misbruk i ettertid. Øvrige krav til registreringssystemet: Systemet skal i minst mulig grad avhenge av en brukermanual. Dvs, sluttbruker skal intuitivt og enkelt forstå hvordan systemet brukes uten mye ekstra innføring/opplæring. Kunne oppdateres og videreutvikles. Systemet skal kunne videreutvikles av en annen programmerer uten for mye arbeide. Systemet skal kunne skrive ut kvitteringer for lånt utstyr på en enkel måte. 3.6.2 Andre krav til prosjektet Lett leselig brukermanual Må kunne videreutvikles Lett å navigere seg rundt Lett å logge seg inn hvor enn man er 3.6.3 Tekniske krav Front-end og back-end Webgrensesnitt CSS PHP MySQL 11 S i d e

Må være forberedt for implementering av scanner-utstyr ved senere anledning 3.6.4 Krav fra oppdragsgiver Det ble stilt en del krav fra oppdragsgiveren vår, YIT. Men med tanke på seks måneders arbeid kunne vi ikke rekke å oppfylle alle disse kravene. Hovedsaklig prøvde vi å utføre krav som ble stilt av logstikksjefen. Men ellers stod vi ganske fritt for brukergrensesnittet og designen. Kontakten mellom oss og oppdragsgiver har vært god hele veien. Hos YIT er de veldig opptatte, så det har blitt en del mailer og telefoner. Tung som har en deltidsstilling der har også stått for en del av møtene. Dermed trengte ikke hele gruppen å møte opp hver gang. Oppdragsgiveren har hele veien sett på de forskjellige prototypene og kommet med innslag på hva vi kan endre på. De fleste tilfellene har vi gjort det som oppdragsgiver vil, men noe har vi latt være etter avstemmning fra gruppen. 4 Planlegging og metode 4.1 Planlegging av prosjektet Etter at gruppa ble sammensatt begynte fokuset på selve prosjektet. Det var mange områder å dekke og mye idemyldring. Derfor var det viktig for oss å dele opp oppgavene så tidlig som mulig for å få bedre oversikt. Vi utviklet en arbeidsplan med detaljert beskrivelse av arbeidet som skulle utføres og arrangerte ukentlige møter. Gruppa jobbet systematisk med arbeidsoppgavene og diskuterte mye om de på møtene. Vi var også fleksible når det gjaldt ferier, eksamener og innleveringer i andre fag slik at de av oss som trengte fri fikk det. Første steget i prosjektet var å få på plass kravspesifikasjonene sammen med oppdragsgiver. Her fikk vi frie tøyler, så det meste var egentlig opp til oss. Men 12 S i d e

funksjonaliteten på prosjektet var mer eller mindre hardbanket. Siden et av gruppemedlemmene jobber hos oppdragsgiveren så gjorde det planleggingen lettere for oss som gruppe. Vi fikk mye inside informasjon som sparte oss for mye tid. Med kravspesifikasjonen klar så hadde vi det vi trengte for å komme oss videre i prosjektet siden den var en slags veiledning for oss om hvordan systemet ville se ut. Vi jobbet mye rundt den. 4.1.1 Planlegging av databasen Oppsett av databasemodellen skjedde først ved diskusjoner og håndtegnede skisser. Etter hvert som gruppa ble enig og all informasjon var på plass så begynte vi å sette opp ER modeller, koble sammen relasjoner mellom tabeller, definere primærnøkler og fremmednøkler etc. Da dette var klart kunne vi begynne med å kode selve databasen. 4.1.2 Planlegging av websiden Planleggingen av websiden startet med idemyldring og håndtegnede skisser. Det var mye å ta hensyn til, ikke kun innholdsmessig, men også utseendemessig og brukervennligheten. Samtidig hadde vi universell utforming i bakhodet. Vi ønsket en enkel webdesign med rene farger og store skriftstørrelse med en tydelig logo. 4.1.3 Planlegging av systemet Etter at vi begynte med å utforme kravspesifikasjonen kunne vi nesten se for oss hvordan systemet ville bli. Vi diskuterte mye om hva slags funksjoner systemet skulle ha og hva den kunne utføre. Vi delte ideer og forslag og skisserte de på papir. 13 S i d e

5 Utviklingsfasene 5.1 Prosjektstart Gruppen vår ble til ved mye tilfeldigheter samt at studiesituasjonen vår er noe sammenfallende. Dvs. vi er ikke så integrerte i det sosiale som foregår på HiO og var derfor i beit etter medlemmer for å få en fullverdig gruppe. 3 av oss har imidlertid jobbet sammen på et tidligere prosjekt. En av oss deler arbeidsplass med ett av de nye medlemmene og det andre nye medlemmet er en bekjentskap til et annet medlem i den originale gruppa. Vi ble relativt fort innstilt på å jobbe med prosjektet hos YIT fordi vi så at det var gjennomførbart og ikke risikobetont i forhold til at kompetansemangel kunne trenere prosessen hadde vi vært for ambisiøse. Det viser seg at selv de tilsynelatende enkle systemer har mange fallgruver og detaljer man ikke har tenkt på og som krever prøving og feiling. I tillegg er det verdifull erfaring at Tung jobber i bedriften og har en forståelse av hvordan arbeiderne på gulvet tenker og hva de fokuserer på i den daglige bruk av utstyr av systemer. Prosjektet har egentlig gått smertefritt hele veien, og vi var samstemte og motiverte for valget vi landet på. Utfordringen ligger hele tiden i at gruppen som helhet har en forståelse av systemet de skal beskrive og legge rammeverk for. Dette blir mye til underveis og man er derfor avhengig av å ha hyppige møter som vi også har prioritert. 5.2 De forskjellige fasene under utviklingen av prosjektet Vi følgte dokumentasjonsstandarden og delte prosjektet i to deler. Vi gjorde oss nesten erdig med styringsdokumentasjonen. Det som er hele tiden under utvikling i styringsdokumentasjonen er kravspesifikasjonen vår. Etter at deler av styringsdokumentasjonen er på plass startet vi på sluttdokumentasjonen. Vi har jobbet 14 S i d e

litt om hverandre i hver fase. Noen faser måtte vi vente med, mens andre faser kunne vi nesten gjøre oss ferdig med. 5.3 Innledende arbeid Etter at gruppa ble dannet og oppdragsgiver var på plass startet det innledende arbeidet. Det første som gruppa skulle levere var statusrapporten der hvor vi skrev litt om hva vi ville jobbe med og hvem vi ville jobbe sammen med. Etter jul samlet gruppa seg for å bli ordentlig kjent og begynne på planleggingsfasen. Da ble prosjektskissen til. På samme tidspunkt fikk vi opp prosjekthjemmesiden. 5.3.1 Prosjektets styringsfase Denne fasen startet vi ganske tidlig. Allerede midten av oktober skrev vi statusrapporten. Under denne fasen måtte alt planlegges nøye. For hvor mye tid vi skal bruke i hver fase under hele prosjektperioden. Statusrapport Rapporten skrev vi midten av oktober. Da var vi bare to i gruppen. Gruppen var ikke komplett da, men allerede da hadde vi fått oppdragsgiver. Prosjektskisse Prosjektskisse ble laget slutten av november. Gruppen er på plass og vi vet også hva vi skal lage i denne fasen. Arbeidsplan Planen ble laget rett etter nyttår. Arbeidsplanen måtte planlegges nøye før vi startet prosjektet. Men dette var bare en skisse, etter hvert måtte vi utdype arbeidsplanen. Prosjektdagbok 15 S i d e

Dagboken ble laget under vårt første møte. Andy i gruppen fikk ansvaret for dagboken, men alle i gruppen måtte lese gjennom det. Dokumentet ble lagt ut på google docs, og vi kunne tilføye hvis det var noe. Forprosjektrapporten Rapporten måtte leveres slutten av januar. Da hadde vi alt på plass, gruppen er på plass. Navnet haddde vi og vi visste hva slags produkt vi skal lage. Vi fikk også tildelt veileder som vi er veldig fornøyd med. Veilederen vi har er alltid tilgjengelig for spørsmål. Møtereferater Før hver møte lagde vi oss møtereferat. Hva vi måtte gå igjennom, og om alle har fått gjort backloggen. Alle måtte også fortelle hvor langt de har kommet. Vi planla også hva som måtte bli ferdig til neste møte. 5.3.2 Programmeringsfasen MySQL, opprettelse av tabeller PHPmyAdmin, definere spørringer som skal sendes til databasen Definere forskjellige tilgangsnivåer så man differensierer mellom teknikere og administrator av systemet. Grensesnitt, opprettelse av html-kode som henter definert data fra databasen. 5.3.3 Dokumentasjonsfasen I løpet av dokumentasjonsfasen ble styringsdokumentasjon og sluttdokumentasjon fullført. Forprosjektrapport, prosjektskisse, arbeidsplan, framdriftsplan, kravspesifikasjon, prosjektdagbok/møtereferat er alle essensielle deler av styringsdokumentasjonen. Vi kom litt sent i gang men mesteparten av dokumentasjonen ble ferdig i logistisk riktig rekkefølge og vi hadde god tid til å jobbe med produktrapport og selve produktet. 16 S i d e

Produktdokumentasjonen skal hovedsakelig brukes av systemadministratorer som faktisk skal bruke systemet, men den skal også delvis hjelpe sensorer og forstå produktet. Dokumentasjon av hvordan systemet fungerer og hvilke moduler det er bygget opp av er gjort på en måte som forhåpentligvis skal gjøre det lettere for personer som ikke har vært involvert i prosessen tidligere å forstå systemets virkemåte og eventuelt utvikle det videre. Som del av sluttdokumentasjonen er testinformasjon av det ferdige produktet. Brukerdokumentasjon er laget for å beskrive i enkelhet hvordan en sluttbruker skal benytte systemet. 5.3.4 Avslutningsfasen Gruppen vår hadde problemer med ujevn jobbing fordi alle jobber ved siden av studiene og til forskjellige tider. Den store utfordringen for oss lå derfor i å presentere en uniform dokumentasjon samt holde oss oppdatert i hverandres prosesser. Mot slutten satt vi mer på fysisk samme sted og dette hjalp oss med å tydeliggjøre svake områder som måtte jobbes mere med og samkjøre prosjektets sluttføring og layout i dokumentasjon. Muntlige forberedelser ble også påbegynt og planlagt. 6 Kravspesifikasjon Det meste kravspesifikasjonen ble utviklet av oss med noen få inputs fra arbeidsgiver. Siden YIT har et lignende system fra før så gjorde det jobben enklere for oss. Meningen er å forenkle det systemet de allerede har i dag og gjøre det mer brukervennlig. Som nevnt ovenfor så fikk vi for det meste frie tøyler av arbeidsgiver og utviklet en spesifikasjon etter det vi mente var best. Kravspesifikasjonen har vært en slags rød tråd gjennom prosjektet. Den har holdt oss på riktig sti og veiledet oss. Men vi har ikke låst oss fast til den. Etter hvert som bitene 17 S i d e

begynte å falle på plass oppdaget vi at spesifikasjonen måtte endres. Det var ikke snakk om store endringer, men endringer som ville forbedre systemet. 7 Oppsummering og konklusjon Etter at vi hadde blitt enige om hva prosjektet skulle være skisserte vi en fremdriftsplan samt ble enige om hva som var realistiske mål for oss. Vi gjorde også rede for hvilke kompetansefelt hver og en av oss mestret best for å kunne ha en fornuftig arbeidsflyt underveis. Samtid ønsket vi at alle skulle ha en grunnleggende forståelse av alt, så vi gikk igjennom arbeidet vi hadde gjort for hverandre med jevne mellomrom. Så laget vi en kravspesifikasjon etter hva oppdragsgiver hadde bedt om, men sørget for å bruke eget skjønn som IT studenter til å luke ut problemer som oppdragsgiver ikke hadde tenkt på samt la til noen egne krav. Sluttproduktet er en webbasert database med administrator tilgang og sluttbrukertilgang for innsjekking og utsjekking av utstyr som brukes i det daglige av YITs teknikere. Her vil man også kunne etterspore historikk av interesse. Brukerdokumentasjonen er blitt lagt ut på nettsiden vår. Den er også trykket i papirformat. 7.1 Kompetanseheving En refleksjon rundt hva gruppen har lært er en ganske vanskelig oppgave. Rent konkret i det praktiske har vi alle lært mer om html, mysql, php, css, uml-diagrammer og all annen teknologi og analyse som har vært tatt i bruk i prosessen mot et ferdig produkt. I tillegg har vi hatt en del kompetanseheving som er vanskelig å måle, dvs. alle de sosiale problemstillingene vi har støtt på i forhold til respekt for hverandres tid, demokratiske beslutninger, arbeidsfordeling, kommunikasjon og hensyn til forskjellige personligheter. 18 S i d e

Vi har også lært hvor viktig det er med fysisk tilstedeværelse uansett hvor mange sosiale nettverk og online samarbeidsverktøy man er medlem av. Dette har vært største utfordringen for oss pga vidt forskjellige arbeidsturnuser. Alt i alt er vi fornøyde med hvordan alt er gått og føler det har vært en veldig verdifull erfaring. 7.2 Forbedringspotensial Det er flere punkter vi føler kunne ha vært gjort bedre. Som nevnt i forrige avsnitt har vi hatt problemer med logistikk i forhold til oppmøte for alle medlemmene av gruppa. Ideen om at alle kunne jobbe individuelt for seg selv og så lime delene sammen til en helhet viste seg fort og ikke holde mål og vi måtte endre tilnærmingsmetode. Andre ting som burde vært gjort umiddelbart var å opprette en felles kommunikasjonskanal (epost-liste), samt online mappe for dokumentlagring med revisjoner. Det har flydd for mange versjoner av dokumenter og beskjeder fra person til person og det ble brukt for mye tid til å administrere og sette sammen dokumentasjonen samtidig som enighetene vi hadde kommet frem til ikke alltid var konsistent (fordi forskjellige beskjeder ble sendt til forskjellige gruppemedlemmer). 7.3 Hensikt med produktet Systemet var hovedsakelig utviklet for å lette Studentparlamentets arbeid med å få kontakt med og opprette en dialog med tillitspersoner ved hele HiO. Dette var et utrolig vanskelig og krevende arbeid da de måtte kontakte hver avdeling for å få navn, e-post og telefonnummer til de tillitsvalgte. For å holde databasen oppdatert ble alle avdelingene gitt tilstrekkelige rettigheter til å kunne legge inn å endre data om tillitsvalgte på sin avdeling. 19 S i d e

Studentparlamentet kan nå registrere, deaktivere og legge inn historie på tillitsvalgte, søke opp en eller flere tillitsvalgte ved hele Høgskolen, lage mailinglister, registrere hendelser som Landsmøte i systemet og på de tillitspersoner som er påmeldte, endre informasjon på valgte personer. De har også alle rettigheter til å endre ting i systemet. Studentrådsstyrenes rettigheter begrenser seg til å kunne registrere, endre og søke opp tillitsvalgte, mens studenter generelt kan søke opp sin tillitsvalgt. 7.4 Produktets bruk WebStorage YIT ble utviklet for å gjøre hverdagen til teknikerne på gulvet lettere. Når utstyret ankommer fra leverandørene Dell og HP blir det registrert med en såkalt gul-tag-id i systemet vi har laget. Man vil i systemet kunne få oversikt over beholdning til enhver tid, sjekke inn og ut utstyr, flagge utstyr for reparasjon, tilbakespore historikk på en bestemt gjenstand, administrere databasen osv. Alt skjer via nettleser. Det blir i tillegg lettere for logistikksjefen å holde oversikt over lageret og ha meningsfulle vareopptellinger. Det blir også mulig å oppdage avvik uten for mye arbeide. 7.5 Konklusjon Vi føler at tiden under prosjektet har vært veldig lærerikt og brakt oss nye kunnskaper som vi ikke hadde fra før. Vi lærte å samarbeide gjennom vanskelige tider og under press. Gjennom både gode og onde dager har gruppa lært å holde seg sammen og jobbe hardt for å oppnå et godt resultat. Erfaringene vil vi ta med oss videre i fremtiden når vi skal ut i jobb, så vel som videre i livet. 20 S i d e

8 Kilder http://www.iu.hio.no/data/hovedprosjekt/dokumenter/dokumentasjonsstandard.pdf http://www.iu.hio.no/data/hovedprosjekt/historikk.html Prosjektarbeid - en veiledning for studenter. Erling S. Andersen og Eva Schwencke 9 Vedlegg 9.1 Styringdokumentasjoner 21 S i d e