Prosessdokumentasjon Presentasjon

Transkript

1 Prosessdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på en enkel måte kan registrere varer inn og ut fra lager. Periode 3. januar 2012 til 11. juni 2012 Gruppemedlemmer Abdullah Arshid Atia Iqbal Kenny Nguyen Sharjeel Javaid Tony Vu Pham Prosjektgruppe 25 Veileder Oppdragsgiver Kontaktperson Eva Hadler Vihovde Statsbygg May Liss Urang

2 1. Forord Denne dokumentasjonen er tilrettelagt for sensor, oppdragsgiveren og alle som har interesse for prosjektet. I prosessdokumentasjonen skal vi redegjøre for hvordan vi har jobbet, ulike metodikk, verktøy, nye teknologier vi har brukt, samt problemstilinger vi måtte sette oss inn i. Dokumentasjonen begrunner de valg som er blitt gjort, og leseren får innblikk i hvordan hele prosessen har fungert for gruppen, samt hvilke utfordringer gruppen har møtt. Målet med arbeidet var å utvikle en web basert applikasjon for supportavdelingen i Statsbygg, for å levere ut varer på en enkel måte fra deres lagerbeholdning. Gjennom hele periodene har vi vært i tett kontakt med kontaktpersonen hos Statsbygg, May Liss Urang. Vi har fått råd og veiledning som hjalp oss til å komme frem til et godt resultat. Denne dokumentasjonen består av hovedkapitlene: Planlegging og metode Utviklingsprosess Kravspesifikasjon Resultat Denne prosessdokumentasjonen er en god begynnelse, dersom leseren ikke kjenner til produktet. Ved å lese dette først, får leseren innblikk i bakgrunnen for prosjektet. Hver delrapport kan leses som et selvstendig dokument, av den grunn vil enkelte kapitler være felles for prosess og produktdokumentasjon. Dette gjelder kapittel 3 og 4. Dersom leseren velger å begynne på prosessdokumentasjonen, kan disse kapitlene hoppes over i produktdokumentasjonen. Selv om oppdragsgiveren er en IT-avdeling og brukeren har kompetanse for de faglige uttrykkene, vil oppdragsgiveren finne ordliste plassert under vedlegg som beskriver ITtekniske ord.

3 2. Innholdsfortegnelse Prosessdokumentasjon Forord Innholdsfortegnelse Innledning Bakgrunn for prosjektet Bedriftens situasjon Mål og rammebetingelser Oppdragsgiver Endelige produktet Lagersystem Planlegging og metode Start fasen Arbeidsforhold Planleggingsmetodikk Ansvarsfordeling Valg av teknologi Programmeringsspråk Utviklingsverktøy Kommunikasjonsverktøy Utviklingsprosessen Utviklingsfaser Dokumentasjonsfase Drøfting av avgjørelser Oppsett av server og database Faglige utfordringer Samarbeid og utviklingsprosess med arbeidsgiver Designvalg Utseende Logo Fargevalg og skrifttype Plassering av innhold Knapper Kravspesifikasjon Endringer... 24

4 Kravspesifikasjon i samsvar med applikasjon Resultat Avslutning Utbytte for oppdragsgiver Læringsutbytte Gruppen Hva kunne vært annerledes Fremtidig utvikling Sluttord Kilder... 28

5 3. Innledning Dette kapitlet er en begynnelse for å kjenne til bakgrunnen for prosjektet og hvordan situasjonen i bedriften var før prosjektet ble iverksatt. Innledningen består av fire underkapitler; bakgrunn for prosjektet, bedriftens situasjon, mål og rammebetingelser og oppdragsgiver Bakgrunn for prosjektet Gruppen startet tidlig med å kontakte flere bedrifter for hovedprosjekt, det førte til at gruppen hadde flere utvalg av prosjekter. Blant annet fikk gruppen tilbud om å utvikle for Glasspaper og Omega A/S. Ettersom ett av gruppemedlemmene er ansatt i Statsbygg som IT-medarbeider (i IT-support avdelingen, Teknotorget), fikk gruppen tilbud om å kunne utføre hovedprosjektet for dem. Etter idémyldringer og diskusjoner rundt valget av oppgaven, kom vi frem til at Statsbyggs oppgave var den som interesserte oss mest. For å få grundigere detaljer om oppgaven, hadde gruppen møte med kontaktpersonen for Statsbygg. Vi fikk positiv inntrykk og var villig til å gjøre en god innsats i prosjektet Bedriftens situasjon Teknotorget har per idag ikke et elektronisk system som holder rede på varer som kjøpes inn og leveres ut til ansatte i Statsbygg. Det har ført til at Teknotorget ikke har oversikt over antall enheter som utleveres, og som er på lager til enhver tid. Teknotorget ønsker av den grunn å holde rede på deres lagerbeholdning i form av en web-basert applikasjon. Applikasjonen skal være en effektiv og strukturert løsning for brukerne og som kun er tilgjengelig over Statsbyggs intranett. Applikasjonen skal være enkel for Teknotorget å vedlikeholde i ettertid, og være laget i tilknytning til Statsbygg sin PC plattform, det vil si Windows 7 med støtte for 32 og 64 bits. Eksempel på varer som finnes på Teknotorgets lager er datamus og tastatur, minnebrikker, eksterne harddisker etc. Disse varene deles fortløpende ut til brukere ved behov, og varer må etterbestilles når det er tomt på lager Mål og rammebetingelser Målet med oppgaven var å utvikle en webapplikasjon, hvor ansatte i Teknotorget på en enkel måte kan registrere varer inn og ut av lager, og samtidig se hvilke produkter som de har inne på lager. Dette hjelper dem med å finne ut når de må gjøre nye innkjøp. Lagersystemet skal kun brukes av ansatte på Teknotorget.

6 Kravene var målbevisste, realistiske og tidsbegrenset. Teknotorget fremmet ønsket funksjonalitet, og i samråd med dem har vi kommet frem til kravene. Dette er blitt gjort for å komme frem til en god og effektiv løsning. I korte trekk har applikasjonen følgende funksjonalitet: Nye varer blir registrert enkelt inn på lager Varer som deles ut til bruker blir enkelt registrert ut av lager Når en vare når sitt minimumsantall, varsler systemet om at det må bestilles opp mer varer av denne typen Det er enkelt å fjerne eller opprette nye varekategorier i systemet Tar ut rapporter (spørringer) på enkelte varer Det har ikke vært strengt med rammebetingelser, men noen av rammebetingelsene er blitt bestemt på forhånd av oppdragsgiveren, for eksempel bruk av plattform og tidsbegrensninger. Rammekravene som var pålagt fra Teknotorget, var at applikasjonen skulle ha en database i bunn og at applikasjonen skulle være webbasert. Disse var de overordnede rammekravene. Oppkobling mot Visual Studio med database i bunn, var en god kombinasjon til å løse denne oppgaven på best mulig måte. Utover det hadde gruppen frie tøyler til å utarbeide en selvvalgt løsning beskrevet i tilknytning med mål og rammebetingelser over. Det var fritt fram hvilket programmeringsspråk og utviklingsverktøy som skulle benyttes for å utvikle applikasjonen Oppdragsgiver Statsbygg er Norges største statlige eiendomsaktør i sivil sektor med en eiendomsportefølje på rundt 2,7 millioner kvadratmeter til en verdi av ca. 30 milliarder kroner. De driver stedplanlegging, byggfaglig rådgivning, eiendomsforvaltning og styring av byggeprosjekter. Statsbygg er en forvaltningsbedrift med 830 ansatte, med hovedkontoret i Oslo og fem regionskontor. Statsbygg er statens sentrale rådgiver i bygge- og eiendomssaker, byggherre, eiendomsforvalter og eiendomsutvikler. Statsbygg har som mål å være statens førstevalg. Statsbygg er en statlig forvaltningsbedrift. Statsbyggs oppgave er å tilby gode og funksjonelle lokaler til statlige virksomheter, og å realisere vedtatte samfunnspolitiske mål i forhold til arkitektur, statlige planinteresser, kulturminnevern og miljø. IKT avdelingen på hovedkontoret består av ca. 30 ansatte fordelt på tre grupper; IT Support (Teknotorget), IT Drift og IT System.

7 4. Endelige produktet Lagersystem Dette kapittelet har til hensikt å gi leseren et lite innblikk i produktets oppbygging og virkemåte, slik at man vet hva arbeidet har resultert i, før man leser de neste kapitlene. Applikasjonen lagersystem er beregnet for ansatte i Teknotorget hos Statsbygg. Avdelingen Teknotorget har ingen elektronisk system som holder rede på varer som kjøpes inn og leveres ut til ansatte i Statsbygg. Applikasjonen skal være effektiv løsning for brukerne. Figur 1: Applikasjonens virkemåte Figuren ovenfor viser virkemåten til applikasjonen på følgende vis: 1. Brukeren lager webforespørsel 2. Server sender forespørselen til databasen 3. Resultatet sendes tilbake til serveren 4. Server bygger siden og returnerer resultatet til den endelige klienten Applikasjonen har blitt utviklet i flere språk som CSS,.Net, XHTML, CSS, JavaScript. For utvikling av webapplikasjonen er det brukt Visual Studio 2010 med programmeringsspråk C#. Det er store muligheter for endringer, og er tilrettelagt for eventuelle utvidelser. Applikasjonen har en database i bunn, det betyr at den henter alle dataene fra en SQL database. For å se koblingen i databasene med alle attributtene, finner dere nærmere informasjon om dette i produktdokumentasjonen. Hensikten med applikasjonen er at ansatte på en enkel måte skal klare å registrere varer inn og ut av lager. Applikasjonen viser enkelt oversikten over alle varer på forsiden til applikasjonen. For å beskrive varen, viser den varenavn, merkenavn, antall, kategori og status. Disse kan sorteres i alfabetisk rekkefølge eller minst til høyest antall. Det vil si at brukeren kan for eksempel velge å sortere varenavnene etter kategori eller status (figur 2). Statusen har logiske farger, dersom varen er på lager er statusen oppført som ikke på lager med rødt skrift, og varene som er på lager har status oppført som på lager med grønt skrift.

8 Figur 2. Sorter varenavnene etter status Hovedmenyen er plassert øverst på forsiden med sort farge og hvit skrift. Hovedmenyen består av følgende funksjoner; oversikt, kategorier, siste hendelser, rapporter og administrering (figur 3). Figur 3. Hovedmeny Søking er en sentral funksjon på hovedsiden av applikasjonen. Brukeren kan søke enten ved å skrive inn teksten selv, eller velge merkenavn og kategorinavn ved nedtrekningsmeny (figur 4). Endre varedata endrer varenavnet, merkenavn, kategori, minimumsantall på en spesifisert vare. Endre varedata er et logisk symbol på forsiden. Dersom en vare blir slettet fra systemet, viser det melding om at varenavnet er blitt slettet (figur 5). Figur4. Søkefunksjon

9 Figur 5. Varenavnet er blitt slettet Funksjonen kategorier viser liste over kategoriene. Ved å gå inn på funksjonen kategorier kan brukeren velge vis varer, da blir varene vist i den valgte kategorien. Funksjonen siste hendelser viser alle hendelsene som har skjedd til enhver tid. Per hendelse er beskrevet med dato og klokkeslett, status på antall ut eller inn og beskrivelse av varen (figur 6). Figur 6. Siste hendelser Funksjonen administrering er ikke for en administrator. I denne applikasjonen har alle brukere like rettigheter. Administrering grupperer underfunksjoner (figur 7). Logg inn funksjonen er koblet mot Active Directory (AD), der alle brukerne i Statsbygg er lagt inn. Brukerne blir lagt inn i AD systemet av ansatte i Teknotorget. Applikasjonen vår starter med at brukeren må logge seg inn med initialer og passord (figur 8). Figur7. Administrering siden Figur 8. Logg inn

10 Tilgang til systemet styres igjennom AD (Active Directory). AD brukes til å styre rettigheter og tilganger til de forskjellige systemene i Statsbygg. Det blir opprettet en gruppe i AD som den enkelte må være medlem av for å få tilgang til systemet. Primært skal denne gruppen bestå av de ansatte på Teknotorget. Som medlem i gruppen vil man få tilgang til applikasjonen og kan logge inn med brukernavn og passord, som er identisk med Windows passord på pc. Ivaretakelse av sikkerhet er viktig fra Statsbygg sin side. De har gode rutiner for ivaretakelse av sikkerhet, og jobber kontinuerlig med hindring av uautoriserte adganger til systemer, applikasjoner, servere m.m. For å kunne gjennomføre prosjektoppgaven var det viktig at vi fulgte Statsbygg sine krav om bruk av AD for autorisering av tilgang til systemet og applikasjonen. Applikasjonen inneholder en e-post funksjon som sender e-post varsel for mer bestilling av varer som har gått tomt. Blir ikke varen fylt på innen 14 dager, blir det tilsendt en purr for påminnelse. Denne e-posten blir tilsendt til alle ansatte på Teknotorget (figur 9). Figur 9. Varsel for bestilling av varer Funksjonen rapport tilbyr utskrift av rapport over en vare. Filen genereres i PDF format. Brukeren er pliktig til å fylle inn varenavn i tekstfeltet selv, og velge datoen (figur 10). Figur 10. Rapport funksjon Valideringen av inputfelt er essensielt for å kontrollere at data som blir satt inn samsvarer med datafeltene i databasen. Brukeren får opp feilmeldinger slik at de kan rette opp eventuelle feil. Vi har både med klient og server validering (figur 11).

11 Figur 11. Validering Detaljert beskrivelse av programmet finner dere i produktdokumentasjonen og brukerveiledningen. 5. Planlegging og metode Start fasen Prosjektet startet ved å ha en møte med kontaktpersonen fra oppdragsgiveren, der vi fikk introduksjon og omfang av oppgaven. For å vurdere om oppgaven var godt tilegnet oss, ble det spurt om hvilke kompetanse vi hadde egnet oss gjennom studieårene. Alle i gruppen presenterte seg selv og fremmet de egenskapene som var ved oss, og ga innspill av løsningsforlaget av prosjektoppgaven. For å strukturere helheten av utviklingsprosessen, begynte gruppen å planlegge fremgangsmåten og arbeidsdriften. Diskuterte forskjellige måter å løse oppgaven på, med ulike verktøy og ulike prosesser. Planleggingsfasen var en viktig del av prosessen, det var nødvendig å planlegge grundig for å oppnå det beste resultatet gjennom utviklingsfasen og helt til resultatene av produktet. Fire av gruppemedlemmene hadde tidligere samarbeidet i flere prosjekter ved Høgskolen i Oslo Akershus og var godt kjent med hverandre. Vedkommende som var ny i gruppen, klarte fint å tilpasse seg i gruppen, og heller ingen hindringer for gruppen å tilpasse vedkommende. Det skapte ingen endringer i kommunikasjonsmåten, uavhengig av vedkommende.

12 Arbeidsforhold Arbeidsforholdene i gruppen fungerte meget bra. Samarbeid, kommunikasjon, motivasjon, effektivitet og oppmuntring var en del av hverdagen. Alle var like flinke med å ta initiativet, oppmuntre og tilpasse hverandre, samt godta kritikk. Del kunnskap Engasjer Planlegg Lær Reflekter Vurder Figur 12. Samarbeid Figuren viser samarbeidsmåten i gruppen. Planleggingsfasen var begynnelsen til å engasjere seg i prosjektet og reflektere alle vurderingene. Ingen av gruppemedlemmene var gjerrige på å dele kunnskap, det gjør at kunnskapsnivået øker mellom gruppemedlemmene og prosjektet får et bedre resultat. Alle gruppemedlemmene var pliktoppfyllende og utførte arbeidsoppgavene nøyaktig som mulig. Arbeidsfordelingen i gruppen ble utdelt med hensyn til kvalifikasjoner og hva den individuelle trivdes med Planleggingsmetodikk For å planlegge, ble det opprettet en fremdriftsplan og aktivitetsplan. Ved bruk av disse planene, var det enkelt og oversiktlig for oss å kunne følge aktivitetene. En god plan er opplagt en viktig del av planleggingsarbeidet, men planleggingen har også en viktig hensikt. Den skal gi oss en felles forståelse for den oppgaven vi skal utføre sammen. Gjennom planleggingen skal vi utvikle et felles syn på hva vi skal oppnå, og hvordan vi skal gå fram for å få det til. Prosjektarbeidet består av en rekke bevisste utvalg. (1) Framdriftsplan er overordnete plan, ofte kalt for milepælplan. Den ble utviklet for å gi oss en mal over aktiviteter og frister. Ofte ble den brukt i samtaler med veileder for hvordan man ligger an. Den planen ble formet av gruppen sammen, slik at gruppen kunne følge opp hvilke aktiviteter som skulle utvikles til enhver tid. Framdriftsplan viste oss jevnlig struktur som effektiviserte og rutinerte gruppens arbeid. Denne planen tok vi frem i prosjektmøtene for å vurdere framdriften i prosjektet.

13 I tillegg til overordnete plan, er det viktig å ha detaljplan. Slike planer blir kalt for aktivitetsplan. Aktivitetsplan viser en plan over de aktivitetene som skal gjennomføres i løpet av prosjektet. Sammen med fremdriftsplanen ble det derfor også utviklet en aktivitetsplan. Se fremdriftsplan og aktivitetsplan i styringsdokumentet. Statsbygg og skolen ble arbeidsplassen til å jobbe med prosjektet. Det måtte reserveres plass på begge arbeidsplassene, derfor tok et av gruppemedlemmene ansvaret til å reservere rom kontinuerlig. Vi startet med å møte to ganger fast i uken, men følte at det var behov for mer. Faste dager ble tre dager i uken, og ved behov møtte vi opp oftere. Det ble også selvstendig arbeid utenom. Den siste perioden av prosjektet, jobbet vi intenst med prosjektet og møtte opp alle dagene i uken utenom fredager som vi holdt reservert for andre obligatoriske fag ved siden av dette prosjektet. Hensikt med gruppemøtene var å planlegge fremdriften, og utføre arbeidet. Arbeidstimer varierte, men målet var å forholde oss til faste 8 timer. Det var viktig med 5 minutters pauser, for å komme til nye ideer og diskutere arbeidet som var blitt gjort. Verktøy for dokumentstyring ble dropbox og google docx. Det var gode verktøy til å redigere og oppfølge dokumentene til enhver tid. Begge verktøyene ble brukt jevnlig. Loggføring er en beskrivelse av hva du har gjort i løpet av en arbeidsdag. Meningen var å reflektere over våre handlinger, reaksjoner og væremåte. I loggen fulgte vi læringsprosessen. Det ble derfor loggført hver eneste dag, der vi kalte det for prosjektdagbok. Prosjekthjemmeside ble opprettet for å holde rede over innleveringer. Veilederen hadde tilgang til hjemmesiden og dokumenter ble oppdatert fortløpende. Hjemmesiden bidro til jevnlig oppfølging av arbeidet vårt Ansvarsfordeling Det er viktig å fordele de konkrete arbeidsoppgavene, følge opp at oppgavene blir utført, og ha det formelle ansvaret for at milepælen blir nådd til rett tid. Derfor valgte vi å ha ansvarskart. Ansvarskart ble brukt for å avtale hvilke oppgaver gruppemedlemmene har i tilknytning til de forskjellige milepælene. Ansvarskart ble brukt til å realisere milepælen. Kartet viser bestemte oppgaver til hvert enkelt individ. Det er viktig å ta beslutninger sammen med andre i gruppen, og rådspørre. Det er bedre å avklare forhold på et tidlig stadium, slik at det ikke skaper noen problemer og hindringer senere. Alle prosjekter har en form for risiko, og det er derfor viktig å ha en risikoplan. Det utarbeides ulike planer som respons til forskjellige risikoene. En risikoplan skal hjelpe oss med å løse problemer før de oppstår. Derfor valgte vi å ha en risikoplan for å hindre konsekvensene i prosjektet.

14 Risiko Risikovurdering Sannsynlighet Konsekvens Forebygging Respons Sykdom Gruppemedlem rammes av sykdom. Moderat Avhenger av når i prosjektet det skjer. Ta godt vare på seg selv. Friske medlemmer blir belastet for mer arbeid. Tidsklemme Ikke nok tid til å utføre arbeidsoppgavene. Moderat-Høy Påvirker målene i prosjektet. Være ansvarsfull, jobbe effektivt innen en tidsramme. Nedprioritere delmål som ikke er vitale for prosjektutførelsen. Motivasjon Gruppen faller fra kurset/studiet. Lav Høye konsekvenser for gruppen. Samarbeide, oppmuntre og hjelpe hverandre. Unngå slike situasjoner, ta kortere pauser og passe på at alle er med. Mister data Mister arbeidet sitt. Lav Høy konsekvens. Ta back-up jevnlig. Går utover hele gruppen, tidsklemme. Missnøye Uenigheter mellom gruppemedlemmer. Lav-moderat. Kan føre til store konsekvenser dersom det ikke blir ryddet i saken. Kommunisere godt, aktiv lytting, felles løsning. Inkludere alle, holde god kontakt kontinuerlig, komme til enighet raskest mulig. Figur 13. Risikoplan 6. Valg av teknologi I dette kapitlet har vi gjennomgått teknologien vi har brukt for applikasjonen, hvilket språk som ble tatt i bruk og litt introduksjon om kildekoden.

15 6.1.1 Programmeringsspråk C# er en videreutvikling av C og C++. C# gir mindre kodemengde fordi det tilbys ett stort klassebibliotek med ferdiglagde metoder. På diskusjonsbordet sto PHP, Java og.net. Det endelige valget ble Microsoft.NET. Vi valgte.net, fordi vi mener det er en komplett utviklingsplattform. C# er et objektorientert språk, det gjør det enklere å gjenskape virkeligheten i et dataprogram. Programmeringen av.net skjer hovedsakelig med programvaren Visual Studio som tilbyr fullspekket funksjonalitet, samt databasehåndtering som egner seg best til å utvikle en web basert applikasjon. Databasen var en SQL database hvor blant annet alle tabeller og deres sammenhørighet ble planlagt. CSS (Cascading Style Sheet) eller stilark er en fil som kan styre utseendet eller designet til websider. Det gjør det mer strukturert da en kan skille kode fra design. CSS er en standard fra W3C. JavaScript er et skriptspråk gjør det mulig å lage mer dynamiske websider. JavaScript lastes hovedsakelig ned sammen med webside, og utføres hos klienten. AJAX (Asynchronous Javascript And XML) er en gruppe utviklingsmetoder som brukes på klientsiden til å lage interaktive webapplikasjoner. Med JavaScript og XMLHttpRequest objektet kan utveksling av data skje asynkront mellom nettleser og server [Ajax(programmering)]. JQuery er en JavaScript-bibliotek som forenkler klientskripting av HTML. SQL databasen blir benyttet og webapplikasjon støtter SQL databasen i bunn. Under utvikling har databasen blitt satt opp på HiOA sine servere, men webapplikasjonen skal drives fra Statsbygg sine server. Dette er en relasjonsdatabase der dataene er organisert i tabeller. SQL database ble bestemt grunnet lave driftskostnader, maksimal fleksibilitet og kontroll med plattformuavhengighet.

16 6.1.2 Utviklingsverktøy Visual Studio er Microsofts utviklingsverktøy for utvikling av programmer. VS2010 støtter utvikling av desktop-applikasjoner, web applikasjoner og web services som kjøres på alle Microsoft plattformer med.net Framework. Høgskolen tilbyr Visual Studio, og dette benyttes også i Statsbygg Kommunikasjonsverktøy Dropbox er et program som lar deg synkronisere filer mellom mange pc-er. Dropbox laster opp filen du jobber med til en server på internett og laster ned nye versjonen når du kobler deg til et annet sted. En dropbox-mappe kan deles med mange andre brukere. Dersom en person gjør endring på en delt fil, vil den bli oppdatert hos alle andre. Google docs er en webbasert kontorpakke som inneholder programmer som tekstbehandling, regneark og presentasjoner. Den tillatter bruker å opprette og redigere dokumenter på Internett. Redigering av et gitt dokument kan gjøres av flere personer samtidig, og endringer vil for de andre brukerne gjengis med det samme. Dokumenter kan lagres på egen PC i forskjellige filformater, og programmet kan importere flere ulike filformater. For utforming av design har gruppen valgt å bruke C#, CSS, JavaScript og HTML for å utvikle et brukervennlig grensesnitt. For redigering av bilder og grafiske enheter, brukte gruppen Adobe Photoshop og MS Paint. Microsoft Office Visio ble brukt i planleggingsperioden for å få et konkret overblikk over webapplikasjonens oppbygning og hendelsesforløp.

17 7. Utviklingsprosessen I underkapitlene skal vi redegjøre utviklingsprosessen. Vi skal presentere utviklingsfasene og refleksjonen over det, faglige utfordringer, problemløsninger og forhold til arbeidsgiver gjennom prosessen. Dette kapittelet gir en god beskrivelse over hele utviklingsprosessen i prosjektet, samtidig blir det vist arbeidsmåten til gruppen. Utviklingsprosessen er midtpunktet i prosessdokumentasjonen, der arbeidet på applikasjonen blir indikert og de fleste utfordringene blir møtt Utviklingsfaser Prosjektbeskrivelsen ble lagd på forhånd av oppdragsgiveren og foreslått til gruppen. Gruppen bestemte sammen til å ha oppdrag hos Statsbygg. Vi hadde derfor møte med kontaktpersonen May Liss, i Statsbygg, hvor flere ulike problemstillinger ble diskutert. Prosjektbeskrivelse bestod allerede av flere krav som Statsbygg ønsket i web applikasjonen. I samråd med Statsbygg ble alle kravene opprettet. Kravene tydeliggjorde problemstillingene, og det ble enklere å planlegge brukstilfellemodellen (use case). Dette ble gjort for å få et bedre bilde av prosjektet. Prosjektstrukturen ble bedre på fra flere synsvinkler, dermed gikk vi inn for å detaljere kravspesifisering, modellering og diagrammer. Ettersom modelleringen var på plass, ble planleggingsfasen endt, og utvikling av applikasjonen startet. Vi begynte med å samle inn det nødvendige data for web applikasjon. For å komme fram til informasjonen, brukte vi prosjektoppgaven. For å komme frem til detaljer, hadde vi møter og kontakt over tlf underveis med kontaktpersonen. Samarbeid med kontaktpersonen og analysering av prosjektoppgaven, medførte lysere dataanalyser Dokumentasjonsfase Dokumentasjonen ble satt i gang allerede ved startfasen av prosjektet. Forprosjekt og kravspesifikasjon ble først dokumentert. Innsikten av applikasjonen ble tydeligere, gjennom kravene. Realistiske mål ble fastsatt. Utfylling av sluttdokumentasjonen skjedde underveis. I dokumentasjonen blir kvalitetsutviklingen og kompetanseuthevingen tatt opp. Det er styringsdokumentene som fortløpende revideres og utvides. Det er en utfordring å finne hensiktsmessig måte å organisere dette på, slik at det blir mest mulig nyttig. Dokumentasjonen beskriver arbeidsmåten gjennom hele prosjektet. Dokumentasjonen beskriver også hvordan produktet er iverksatt. Leseren skal kunne se hva vi har oppnådd ved produktet. Vi innså at dokumentasjonen var et godt virkemiddel for prosjektet. Det ble klarert hva vi ønsket, og samtidig er det positivt å se hvordan arbeidet blir utført. Ofte er det vanskelig å ha oversikt over hva gruppen gjør, og hvor langt de kommer med arbeidet, ved hjelp av dokumentasjonen ble dette dekke

18 Drøfting av avgjørelser Avgjørelsene i planleggingsfasen og utviklingsfasen ble drøftet grundig, grunnet disse avgjørelsene hadde innvirkning på applikasjonen. Oppdragsgiveren prioriterte ikke utseende, derfor valgte vi en enkel og minimal utseende. V i drøftet bakgrunnsfarger, størrelse, skrifttype, rammer osv. Funksjoner var det viktigste i prosjektet. Det var viktig å tilfredsstille behovet til brukeren, for å kunne bruke lagersystemet optimalt. Kravspesifikasjonen beskriver ønsket funksjonalitet i lagersystemet. Det blir derfor enklere å velge hvilke funksjonalitet som er dekker behovet i applikasjonen Oppsett av server og database Databasen ble opprettet for webapplikasjonen, der møtte vi første utfordringen som var at alle dataene skulle inn og ut. Plan A var å utvikle på Statsbygg sine databaser. For teste databasen, tok vi kontakt med DBA (Database administratoren) hos Statsbygg. Etter å ha kommet i kontakt med Tava, altså DBA i Statsbygg, testet vi databasen før alle dataene ble lagt inn. Det var bestemt at databasen skulle settes opp mot.net. Vi måtte også ta hensyn til verktøyet vårt, Visual Studio. Det begynte med at Oracle database ble satt opp i Statsbygg. Utfordringen var først og fremst å koble Oracle databasen mot Visual Studio. Da den endelig ble knyttet til Visual Studio, var det umulig for flere personer å jobbe på den. Kun en av oss hadde muligheten til det. Det gjorde arbeidet tungvindt, derfor anbefalte Statsbygg at vi heller jobbet på en SQL database. Om det ble ekstern server, hadde ingen betydning. Etter innhenting av informasjon, ble endelige valget SQL database. Vi fikk opprettet en server fra skolen gjennom Tor Krattebøl. Det så ut til å fungere helt fint, slik vi hadde erfart tidligere i andre prosjekter Faglige utfordringer I tillegg til database utfordringen, oppstod det flere utfordringer hos Statsbygg. Vi startet med å bruke Statsbygg sine lokaler for å jobbe med prosjektet, men på grunn av begrenset tilgang fra deres nettverk mot VPN tilgangen til skolen, måtte vi gjennom flere prosedyrer. Vi måtte vi kontakte nettverksansvarlig hos Statsbygg til å utvide brukerrettighetene. Grunnen til at dette oppstod var fordi vi brukte gjestenettverket hos Statsbygg, der det er begrenset bruk av nettverket. For å få det i orden, mistet vi noen timers tid. Selv om gruppen hadde tilgang, hadde gruppen kontinuerlige problemer med oppkobling og tilgang til teamfoundation server (oppsett i visiual studio 2010, slik at flere kan jobbe mot samme filer). For å unngå problemene, bestemte gruppen for å jobbe med prosjektet oftere på skolen istedenfor hos Statsbygg. Logg inn funksjon mot AD (Active Directory) og rapportfunksjon var utfordringene som ble vanskeligere med tiden. Det ble tidspress, og intens jobbing med programmering. Flere løsninger ble forsøkt og løsningen krevde mye søk. For å koble sammen applikasjonen mot AD, måtte kommunikasjonen foregås med IT-drift i Statsbygg, også på grunn av manglende erfaring for gruppen. På den positive siden, fikk gruppen tillært seg nye og faglige kunnskap som garantert vil hjelpe oss videre i arbeidslivet og videreutdanning.

19 Vi starter med å detaljere utfordringen innenfor logg inn funksjonen: For å koble logg inn funksjonen mot Active Directory, måtte vi ha en Windows Server. På egenhånd skaffet vi oss en Windows Server(2003) som vi installerte i en virtuell server, slik at vi kunne teste vår kode mot denne serveren. Den første utfordringen var at ingen av oss hadde erfaring med verken Windows Server eller AD. Det resulterte seg slik at vi brukte da ganske mye tid på å sette oss inn i dette. Etter at vi fikk kjørt dette i gang, møtte vi et annet problem hvor koden vår aldri fikk kontakt med LDAP(brukes til oppslag i en katalogtjeneste på en server) til AD. Vi fikk en feilmelding hvor det stod: Unable to establish a secure connection. Etter mye leting for å prøve å løse dette, var det slik at verken koden eller LDAP-adressen var feil. Vi fant fram til slutt at det var noe galt med den lokale DNS en. Vi måtte da konfigurere slik at vi kunne bruke DNS en(koble serverens IP-adresse til den fysiske maskinen) til Windows Server. Etter at dette var gjort, kunne vi da koble logg inn funksjonen til serveren, noe som også gjorde at vi fikk kontakt med Active Directory. Figur 14: Her er en kodesnutt som viser koblingen til loginfunksjon som er koblet mot AD. For å få kontakt med AD, måtte ha vi riktig LDAP-adresse(Markert på bildet). LDAP-adressen er domenet til serverens AD. Figur 15: Her er konfigurasjonen til DNS-serveren. For å få kontakt med serveren måtte vi sette inn serverens IP-adresse. Andre utfordringen som nevnt tidligere, var rapport funksjonen. En av utfordringene vi stod ovenfor var å få data som produseres av rapporten til PDF format. Visual Studio har ikke en innebygget funksjon som gjør dette mulig. Løsningen var å laste ned itextsharp-biblioteket, som er laget for.net plattformen og som gjør at vi kan håndtere PDF-funksjoner. Med dette ble det mulig å gjøre et MVC-view til PDF-dokument. Vi brukte mye av tiden på å skjønne hvordan man skulle bruke biblioteket og dens funksjoner og egenskaper. Se kodesnutt:

20 Figur 16: Kodesnutt av rapport funksjon 8. Samarbeid og utviklingsprosess med arbeidsgiver Grunnet et av gruppemedlemmene var ansatt i Statsbygg, var det ikke behov for den interne veilederen å ha møte med kontaktpersonen i Statsbygg. Vi hadde jevnlige gruppemøter med interne veilederen, der vi presenterte hvor langt vi hadde kommet med arbeidet og hvilke utfordringer vi møtte underveis. Det har samtidig vært jevnlig kontakt med kontaktpersonen i Statsbygg gjennom telefon og e-post frem til slutten av mars. Ansatte i Statsbygg ved IT-avdelingen har bidratt til all hjelp de kunne. For å få klarere forståelse av oppgaven, har vi stilt spørsmål underveis til oppdragsgiveren. Vi fikk tilbakemelding på kravspesifikasjon, som tydet på at forståelse av oppgaven i helhet ble bedre.

21 9. Designvalg Dette kapitlet beskriver valg av design og begrunner avgjørelsene. Utseendet på hovedfunksjonaliteten og plasseringen i sammenheng med designen blir detaljert beskrevet i dette kapitlet Utseende Vi har foreslått design til oppdragsgiver og fått tilbakemeldinger, samt på de små endringene som ble underveis. Oppdragsgiveren tok ikke høyde for design delen, men applikasjonen burde være brukervennlig i helheten. Vi valgte derfor å ha en enkel og minimal design. Vi skal se nærmere på designvalgene innenfor rammeverket. Vi prøvde å ha fokus på enkelte mål som; Stilrent design Layout skal konstrueres på en brukervennlig og oversiktlig måte Unngå flash, distraherer brukeren Gode fargevalg Forklarende navn på lenker Plassering Logo Til tross for at Statsbygg allerede har en standard logo for bedriften, valgte vi å bruke samme logoen til å gjenkjenne hvem vi lager applikasjonen for. Det gjør at sensoren eller leseren gjenkjenner hvilke prosjekt vi stod for. Nemlig var logoen enkel og lett å se at bedriften er statlig. Tydelig skrift viser at bedriften heter Statsbygg. Logoen passet godt med designvalgene. Logoen ser slik ut: Figur 17. Logo Fargevalg og skrifttype Avgjørelsen av fargevalgene, prøvde vi å unngå rødt og grønt. Vi valgte å ha svart skrift og hvit bakgrunn, fordi den svarte fargen reflekteres veldig godt. Det blir en veldig god kombinasjon mellom bakgrunnen og teksten. Applikasjonen skal bli brukt mye av ansatte, derfor er det viktig å fokusere på leservennligheten slik at det er bedre for øyet.

22 Hovedmenyen er markert med sort og hvit skrift. Dette er for å fremheve hovedvalgene brukeren har, slik at informasjonen skal være lett tilgjengelig. Figur 18. Hovedmeny Skrifttypene som er brukt i applikasjonen er følgende: Verdana, Arial, Sans Seriff, og Helvetica. Mest brukte skrifttypen er Arial. Valg av skrifttype ble nøye vurdert. Avgjørelsen av skrifttypene er valgt med hensyn til design. Lesbarheten og enkelheten er viktige faktorer for brukeren. Skrifttypene er tilpasset på de forskjellige områdene Plassering av innhold Innholdet er tilrettelagt brukeren. Plassering av innhold er sentrert, for at brukeren skal fort få øye på innholdet. Grunnen til at hele siden ikke er brukt, er fordi brukeren kan miste oversikten over innholdet. Ved ulike skjermstørrelser kan teksten strekke seg langt ut på sidene. Sorte fargen på sidene og lys farge sentrert, gjør at brukeren lett får øye på innholdet og ser bort fra sidene. Se figuren nedenfor. Figur 19. Plassering av innhold Forsiden er beregnet for alle brukere. Som nevnt tidligere, er det ingen administrator for denne applikasjonen. Alle brukere har tilgang til alle funksjonene, det vil si rettigheter på lik nivå. Vi har beregnet forsiden som den mest tilgjengelige. Målet er at brukeren finner informasjonen som ønskes. Gjennom brukergrensesnitt har vi tatt hensyn til 3-klikk regelen. Det gjør at brukeren ikke behøver å klikke mer enn 3 ganger på siden fra og med forsiden. Samtidig sørget vi for at brukeren finner de fleste funksjonene på forsiden.

23 9.1.5 Knapper Vi har to typer knapper. Det er lik design på knappene legg til vare, opprett, lagre endringer. Disse ser slike ut: Figur 20. Knapper Bakgrunnsfargen er mørke grå med hvit og sort skrift. Denne bakgrunnsfargen ble valgt for å fremheve at brukeren kan lagre endringene. Brukeren må fylle ut informasjonen over knappen, før knappen blir bekreftet. Selv om brukeren klikker på den knappen, vil det komme opp bekreftelsesknapp om brukeren er sikker på å gjøre endringene. Den ser slik ut: Figur 21. Bekreftelsesknapp For å fremheve at brukeren kan bekrefte valget ved å klikke på denne knappen, er knappen OK fremhevet i form av blå kanter slik du ser ovenfor. Tilbakeknapp, logg ut, slett vare, detaljer, endre varedata, neste og siste, har samme type knapper, slik som eksemplene under:

24 Figur 22. Enkle knapper Enkle knapper (figur 22) tilpasser applikasjonen, grunnet designen skulle være enkel som mulig. Plassering av knappene er slik som du ser i bilden (figur 22). Slett kategori og tilbake knapp kommer på venstre side under samme ramme, slik at brukeren finner den lett. Logg ut knappen er øverst på høyre hjørnet på alle sidene. Navigeringsoversikten blir bedre ved at plasseringen ikke blir flyttet. 10. Kravspesifikasjon Kravspesifikasjonen var et av de viktigste dokumentene gjennom prosjektet. Dette dokumentet var en veiledning for hvordan prosjektet skulle ferdigstilles ved det endelige målet. Kravspesifikasjon var en rammeverk som ble opprettet i samråd med oppdragsgiveren, slik at alle var enige om hvordan det endelige produktet skulle se ut. Med andre ord var kravspesifikasjon en avtale mellom gruppen og oppdragsgiveren Endringer Som forklart i kapittel 10, var kravspesifikasjon en endelig ramme satte sammen i samarbeid med arbeidsgiver. Gruppen hadde versjon 1.0 klar i uke 4, hvor den endelige kravspesifikasjonen var ferdig. Etter å ha sendt den inn til både veilederen Eva og kontaktpersonen May Liss, fikk vi gode tilbakemeldinger som vi sto åpent for. Når beslutningene var gjort i kravspesifikasjonen, var det versjon 2.0 vi fulgte gjennom hele prosjektet. Selv om kravspesifikasjon ikke ble endret etter versjon 2.0, stod gruppen åpen for alle forslag og endringer, som kunne gjøre applikasjonen fra bra til bedre. Under utvikling fikk vi nye ideer og forslag fra både veileder, kontaktperson og internt i gruppen. Endringer var mest relatert til funksjonaliteten.

25 Endringer i forhold til kravspesifikasjonen, er at applikasjonen ikke er implementert på Statsbygg sin server. Applikasjonen kan implementeres i etterkant dersom de ønsker det. Grunnet tekniske utfordringer fra oppdragsgiveren, ble det endringer i sikkerhetskrav og rammekrav. Systemet ble ikke tilgjengelig innad Statsbyggsnett og heller ikke kjørt på Statsbygg sin pc plattform. Applikasjonen ble knyttet opp mot serveren på skolen, og all testingen ble gjort i reelt miljø Kravspesifikasjon i samsvar med applikasjon Applikasjonen har klart å utfylle de fleste kravene. Hovedkravene som Statsbygg ønsket har blitt oppfylt. Applikasjonen tilfredsstillet brukerkravene, og ikke minst systemkravene. I tillegg til disse kravene, har Statsbygg i etterkant kommet med ønske om å skrive ut rapporter i PDF format. Dette var en utfordring for oss, samt tidspress. Gruppen hadde heller ingen erfaring med det. Etter all strev og testing av koder, var løsningen på plass. Vi oppnådde mer enn forventet. I samsvar med applikasjonen, er kravene utført grundig. Dersom oppdragsgiveren sammenligner kravspesifikasjonen med applikasjonen, er det enkelt å se at kravene er utført i sin virkemåte. Fokuset går på brukeren, men det er også viktig at applikasjonen dekker ikke-funksjonelle krav. Områdene i tekniske, ramme og sikkerhetskrav har stort sett blitt dekket Resultat Tre brukere testet applikasjonen samtidig, for å se om den fungerte optimalt. Ved testing av applikasjonen, ble alle brukerkravene utført. Brukernavnet og passordet ble sjekket gjennom AD, og dermed godkjent for innlogging. Alle funksjonene, som sletting, registrering, søking, oppretting, redigering av vare og kategorier ble testet av brukeren. Systemkravene oppfylte gjennomgangen av funksjonaliteten. Det ble vist hvordan funksjonen virket. Liste over varer og logghendelser kom frem ved en av hovedkategoriene på forsiden. Varsling av e-post ble testet gjennom levere ut vare og oppnå minimumsantallet slik at brukerne fikk varsling per e-post. E-posten var knyttet mot Gmail. Ikke-funksjonelle krav ble også resultert. Tekniske krav var enkelt utført ved bruk av utviklingsverktøy og validering gjennom alle nettlesere. Brukeren testet også teknisk krav ved søking av vare som ikke brukte mer enn 5 sekunder på å finne varen. Rammekravene var en del av kravspesifikasjonen. Brukeren fikk en brukerveiledning med enkel oppsett og forståelig på bruk av applikasjonen. Applikasjonen ble dokumentert og ferdigstilt før juni. Den hadde også støtte for Statsbygg sin pc plattform Windows 7 med 32 og 64 bits.

26 11. Avslutning Applikasjonen vil være i drift fra og med 31.mai. Det kan bli enklere for Teknotorget å holde oversikt over lagerbeholdningen og vedlikeholde den. Applikasjonen inneholder hovedfunksjonene som er nødvendig, og i helhet enkelt å bruke. Teknotorget vil få en brukermanual som gjør det enklere for brukere å ta i bruk applikasjonen. For å vedlikeholde databasen, blir det enkelt forklart hvordan systemet fungerer. Teknotorget skal kunne klare å gjøre endringer i databasen, det skal ikke være noen begrensninger. Dette er sluttdelen av dokumentasjonen. Her skal vi gjennomgå hva oppdragsgiveren får utbytte av applikasjonen, og hva applikasjonen tilbyr brukerne. I tillegg gjennomgår vi utbytte for oss i gruppen og fremtidig utvikling av applikasjonen. Til slutt skal vi vurdere resultatene, og trekke inn konklusjonen Utbytte for oppdragsgiver Med denne applikasjonen kan Teknotorget enkelt få rede på lagerbeholdningen. Ansatte kan enkelt registrere varer inn og ut av lager, og samtidig se hvilke varer som er inne til enhver tid. Dette kan i stor grad hjelpe dem med å gjøre nye innkjøp av varene. Applikasjonen vår har gode funksjoner, blant annet vil brukeren bli varslet per e-post for bestilling av mer varer når antall varer når et gitt minimum. Det blir da enklere å holde oversikt over varen når det nærmer seg tomt på lager. Brukeren har full oversikt og kan ta ut rapport over varer som har gått inn og ut i spesifikk tidsperiode. Brukeren holder rede over årlig forbruk av varene. Spesielt for overordnete sjef, er dette en god funksjonalitet. Applikasjonen viser totalantallet av varer som er tilgjengelig på lager i forskjellige kategorier. Kategorier gjør at det blir enklere for brukeren å søke og endre på varer. Samtidig som det er mulig å søke på kategorier, kan det søkes på varenavnet. Det er en effektiv løsning. Brukertesten viser at det tar mindre tid å skrive selv i feltet, enn å gå inn på nedtrekningsmenyer. På forsiden kan brukeren få utnytte av de fleste funksjonene. Vi har fokusert på forsiden for at brukeren skal slippe å navigere seg inn på flere sider. Ved utlevering av vare, registrerer applikasjonen hvem som leverer ut varen. Det blir enkelt for overordnete sjef å holde oversikt over hvem som har levert vare til brukere. Varen blir dermed minket av antall i systemet. I motsetning er det mulig å øke antallet, det vil si fylle på nye varer som kommer inn. Antallet blir økt. Det er også lagt til rette for redigering av varesortimentet og varer kan enkelt slettes eller legges til i systemet om de går ut fra lager hos leverandør, eller leverandør tilbyr en ty type vare som ønskes benyttet. Applikasjonen viser også detaljert informasjon av varen. Kontaktinformasjon innebærer leverandørnavn, sum antall av varer i lageret, merkenavn, kategori, og varenavnet.. Applikasjonen viser informasjon om leverandøren, og det er mulighet for å endre kontaktinformasjonen om leverandøren senere.

27 Slett funksjonen tilbyr sletting av vare, leverandør, kategori. For eksempel om leverandøren ikke brukes mer, er det mulighet for å slette leverandøren. Det er ingen administrator i systemet som har flere rettigheter enn andre. Alle ansatte på Teknotorget har de samme rettighetene som overordnete sjef. Når endringene skjer, blir det registrert av hvem som har gjort det. Oppdragsgiveren ønsket ingen administrator Læringsutbytte Enhver individ i gruppen har ansvar for sin egen læring. Det innebærer ikke at du kan fraskrive ansvar. Du må ta imot mulighetene og benytte disse. De tre hovedområdene som vi har satt fokus på er å utvikle bred kompetanse, lære fagligkunnskap, og bli en god prosjektmedarbeider. I løpet av dette prosjektet, har vi fått god erfaring og fått innsikt i flere områder. Vi oppmuntret hverandre, hadde god kommunikasjon, og ga hverandre tid til å oppnå gode resultater. Alle var pliktoppfyllende og benyttet sine egenskaper i stor grad. Prosjektet har vært utrolig lærerikt og spennende. Ettersom vi har hatt god samarbeid i gruppen, har gruppemedlemmene vært ivrig til å utvide kunnskapen. Vi har tatt i bruk kompetansen fra tidligere, og oppdaget at faglige kunnskapen har vært utfordrende for oss samt interessant. Det er ingen tvil i at vi vil kunne få utbytte av dette i fremtiden. Læring og mestring av kommunikasjonsmåter og teknologi er en forutsetning for et godt resultat Gruppen Under prosjektarbeidet har vi lagt vekt på fem hovedprinsipper, som er følgende; problem, deltakelse, samarbeid, erfaring og refleksjon. Læring er utgangspunktet en problemstilling du skal utforske eller løse. For å forstå problemet er det viktig å utforske det. Problemet blir dermed grunnlaget for målet i prosjektet, og bindeleddet mellom de forskjellige fagkunnskapene. Ved at du selv deltar i beslutningsprosessene, blir du mer selvstendig, både faglig og allment. Det er derfor like viktig å ta initiativ som å delta aktivt. Gjennom samarbeid fikk vi mer ressurser og bredere kompetanse som vi brukte i prosjektet. Det utvider iderikdom, mer variert innhenting av informasjon og flere oppfatninger av hva informasjon viser. Ved å gi hverandre tilbakemeldinger, ble det større utviklingsmuligheter for hvert enkelt individ. Det er også viktig at hvert enkelt individ gjør en egeninnsats i samarbeidet. Ved samarbeid kan det lykkes fellesskap i å nå målet. Erfaring ble brukt til å hente informasjon og alt du har erfaring fra tidligere. Ved å knytte sammen den nødvendige teorien og de praktiske erfaringene som vi gjør gjennom innsamlingen av informasjon, bygget vi vår egen varige kunnskap. Erfaring krevde tillit, og tillit måtte bygges mellom prosjektmedarbeidere. Refleksjon var for å innse og analyse hvordan arbeidet ble utført. Alt som ble utført ble sett fra flere synsvinkler. Kravspesifikasjonen ble for eksempel sammenlignet med første utkast,

28 og vi fikk sett på slutten hvilke endringer som skjedde. Det er viktig å analysere hva som var nyttig og eventuelle forbedringer for fremdriften Hva kunne vært annerledes Med hensyn til tidsbegrensninger og fremdriftsplan, kunne startfasen vært mer effektiv. Grunnet flere utfordringer som oppstod ved oppsett av database og server, kunne vi ta tak i saken enn å miste den tiden vi gjorde. Noen av funksjonene i applikasjonen tok tid enn andre, men det er positivt at vi ville oppnå god resultat. Gruppen var veldig nøyaktig og likte å gjøre arbeidet presist, derfor kunne det også ta tid, men det fører til at problemer ikke oppstår senere og ting har blitt gjennomført med høy kvalitet Fremtidig utvikling Applikasjonen skal være i bruk av ansatte i Teknotorget hos Statsbygg. De vil få med seg brukermanual og dokumentasjon på hvordan applikasjonen kan håndteres i fremtiden. Håndtering av databasen vil skje av databaseavdelingen i Statsbygg. Ansatte i Teknotorget som skal bruke applikasjonen, har selv muligheten til å legge til varer etc. Det blir enkelt for dem å utføre de sentrale oppgavene, og har ikke mulighetene til å forandre selve programmeringen bak applikasjonen. 12. Sluttord Hele prosessfasen inneholdt gode og lærerike faser. Planleggingsfasen skapte planleggingsmetodikker på høyt nivå. Fremdriftsplan og aktivitetsplan var en del av planleggingsprosessen for å tenke langsiktighet. Stegene ble utført nøye, slik at utviklingsfasen skulle resultere med ønskede mål. Testingen førte til forsinkelser i forhold til fremdriftsplanen. Grunnen til at testingen ble forskyvet, var fordi utfordringene av funksjonaliteten tok tid. Ansvarsfordelingen med risikoplan, påvirket arbeidsmåten på en positiv måte. Det var viktig å fokusere på de faktorene som kunne påvirke prosjektet negativt. Alle fulgte fasene nøyaktig. I utviklingsfasen startet utviklingen av applikasjonen. Oppgaven ble fulgt grundig med alle kravspesifikasjonene, og programmeringen var i gang. Samtidig som programmeringen ble tatt tak i, ble handlingene dokumentert underveis. Dokumentasjonsfasen var en del av utviklingsfasen. Utfordringene startet i utviklingsfasen, og oppstod helt frem til sluttfasen. Ved opphold i Statsbygg, fikk vi muligheten til å stille spørsmål og få en bedre oversikt over oppgaven. For oppsett av database og server, fikk vi hjelp av It-system gruppen i Statsbygg. Vi hadde også jevnlig kontakt med oppdragsgiver, som medførte samarbeidsprosessen effektiv. 13. Kilder (1) Prosjektarbeid en veiledning for studenter av Erling S. Andersen og Eva Schwencke s.80.