Hovedprosjekt i teknologi, kunst og design ved Høgskolen i Oslo og Akershus Våren Gruppe 25

Transkript

1 1 Hovedprosjekt i teknologi, kunst og design ved Høgskolen i Oslo og Akershus Våren 2012 Gruppe 25 Tony Vu Pham Atia Iqbal Kenny Nguyen Sharjeel Javaid Abdullah Arshid 1 S i d e

2 2 Sluttdokumentasjon 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 S i d e

3 3 Forord: Denne dokumentasjonen består av fire deler: Prosessdokumentasjonen gir en innblikk av bakgrunnen og underlaget av produktet. Produktdokumentasjonen får sensor og leseren oversikt over systemets egenskaper og funksjoner. Testdokumentasjonen er viktig for den som skal drifte og vedlikeholde programmet. Brukerveiledningen beskriver hva systemet gjør og hvordan brukeren skal handle for å oppnå sine mål med systemet. Hver del rapport 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. All dokumentasjon blir levert både som CD og papir. I cd-en vil kildekoden også finnes. Klasser og metoder er inkludert. For å få tilgang til sluttdokumentasjonen elektronisk, er hjemmesiden for gruppen tilgjengelig på denne siden: For å teste web applikasjonen, kan det gjøres ved å gå inn på denne linken: Brukernavn: Sensor Passord: k2t7asa3 Vi anbefaler at leseren starter på prosessdokumentasjonen. Ved å lese den først forstår man både om bakgrunnen for prosjektet, og det forklarer også detaljene i planleggingsmetoden. Vi vil takke interne veileder Eva H. Vihovde for konstruktive tilbakemeldinger på arbeidet, samt gode råd til å oppnå målet vårt. Samtidig vil vi også takke kontaktpersonen May Liss Urang for jevnlig oppfølging og hjelp til å utarbeide riktig produkt. Vi vil også takke Høgskolen i Oslo og Akershus for tre gode og lærerike år. Gjennom disse tre årene har fått stort læringsutbytte. Stor takk til spesielt Tor Krattebøl for å komme i gang med oppgaven og bidratt til å løse utfordringer som har oppstått. Undervisningen hans, samt hjelpemidlene har hjulpet oss i stor grad. Hele prosjektperioden har vært erfaringsmessig meget god, og ikke minst spennende prosess for hele gruppen. 3 S i d e

4 4 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 S i d e

5 5 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. 5 S i d e

6 6 2. Innholdsfortegnelse Sluttdokumentasjon... 2 Forord:... 3 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 S i d e

7 Fargevalg og skrifttype Plassering av innhold Knapper Kravspesifikasjon Endringer Kravspesifikasjon i samsvar med applikasjon Resultat Avslutning Utbytte for oppdragsgiver Læringsutbytte Gruppen Hva kunne vært annerledes Fremtidig utvikling Sluttord Kilder S i d e

8 8 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 i dag 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. 8 S i d e

9 9 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. 9 S i d e

10 10 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. 10 S i d e

11 11 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 11 S i d e

12 12 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 12 S i d e

13 13 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). 13 S i d e

14 14 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. 14 S i d e

15 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. 15 S i d e

16 16 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 16 S i d e

17 17 med å løse problemer før de oppstår. Derfor valgte vi å ha en risikoplan for å hindre konsekvensene i prosjektet. 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 17 S i d e

18 18 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 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. 18 S i d e 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

19 19 bestemt grunnet lave driftskostnader, maksimal fleksibilitet og kontroll med plattformuavhengighet 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. 19 S i d e

20 20 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. 20 S i d e 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

21 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 21 S i d e

22 22 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. 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, 22 S i d e

23 23 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: 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. 23 S i d e

24 24 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. 24 S i d e

25 25 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. 25 S i d e

26 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: 26 S i d e

27 27 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 27 S i d e

28 28 ideer og forslag fra både veileder, kontaktperson og internt i gruppen. Endringer var mest relatert til funksjonaliteten. 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. 28 S i d e

29 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. 29 S i d e

30 30 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. 30 S i d e

31 31 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, og vi fikk sett på slutten hvilke endringer som skjedde. Det er viktig å analysere hva som var nyttig og eventuelle forbedringer for fremdriften. 31 S i d e 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.

32 32 Produktdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på 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 S i d e

33 33 1. Forord Denne dokumentasjonen er tilrettelagt for sensor, oppdragsgiveren og alle som har interesse for prosjektet. Produktdokumentasjonen gir en detaljert beskrivelse av webapplikasjonen. Av den grunn vil det forekomme enkelte tekniske uttrykk, og vi forventer at leseren har kjennskap til disse. Produktdokumentasjonen omfatter følgende områder: Endelige produktet Datastruktur og virkemåte Klassediagram Sekvensdiagram Use case 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. Hvis man ikke har anledning til å kjøre programmet, kan det være nyttig å se gjennom brukerveiledningen. Denne gir et innblikk i programmets funksjonalitet. For å lese om hva systemet gjør og hvordan brukeren samhandler med det, kan leseren gå til kapittelet Use Case på punkt 7. Der vil leseren få innblikk av brukstilfellemodell som visualiserer kravene til systemet. 33 S i d e

34 34 2. Innholdsfortegnelse Produktdokumentasjon Forord Innholdsfortegnelse Innledning Bakgrunn for prosjektet Bedriftens situasjon Mål og rammebetingelser Oppdragsgiver Endelige produktet Lagersystem Oppbygging og funksjonalitet Planleggingsverktøy Use Case modell Detaljerte Use Case beskrivelser Datastruktur og virkemåte ER-modellering Sekvensdiagram Klassediagram Drifting/Implementering av systemet Konklusjon Kilder S i d e

35 35 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. 35 S i d e

36 36 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. 36 S i d e

37 37 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: Applikasjons virkemåte Figuren ovenfor viser virkemåten til applikasjonen på følgende vis: 5. Brukeren lager webforespørsel 6. Server sender forespørselen til databasen 7. Resultatet sendes tilbake til serveren 8. 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. 37 S i d e

38 38 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 38 S i d e

39 39 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 39 S i d e

40 40 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). 40 S i d e

41 41 Figur 11. Validering Detaljert beskrivelse av programmet finner dere i produktdokumentasjonen og brukerveiledningen. 5. Oppbygging og funksjonalitet Lagdeling sikrer at koden blir mer robust, og derved forebygger feil. Koden vil også bli lettere å vedlikeholde og utvide. Model-view-controller (MVC) er et designmønster anvendt i programvareutvikling. Et MVC-program deler programmet opp i data (model) og brukergrensesnitt (view), slik at endringer i brukergrensesnittet ikke vil ha noen innvirkning på hvordan dataene håndteres. Det bruker en mellomliggende komponent for å kommunisere mellom view og model controller. Model Modell: Modellaget inneholder verdier for applikasjonen. Verdiene ville vanligvis ligget direkte i presentsjonslaget, men for å gjøre kontrollerlaget uavhengig av presentasjonslaget blir det benyttet en generell modell mellom. View presentasjonslaget: Presentasjonslaget er det laget som sluttbrukeren ser og kan manipulere. Dette laget kan hente og sette verdier i modellen samt be kontrollerlaget utføre funksjoner. Controller Kontroller: Hensikten med dette laget er å gjøre all virksomhetslogikk i tillegg til databaselogikk. I tillegg til dette vil dette laget styre hvilke view s som skal kalles. Kontrollerlaget tar seg av alle funksjoner og er selve kjernen i applikasjonen. Kontrollerlager kjenner ikke til presentasjonslaget og kan dermed lett settes sammen med andre presentasjonslag. 41 S i d e

42 42 Grunnen til at vi valgte MVC var for å få en oversiktelig og strukturert programmering, samt dele oppbygging av webapplikasjon inn i MVC (Model view control) struktur. Figur12. Overordnet MVC-arkitektur 6. Planleggingsverktøy For å få et effektivt og strukturert prosjekt, bestemte gruppen å bruke et utviklingsverktøy ved å følge en modell, for å gjøre utviklingsprosessen enklere. Etter å ha diskutert om flere utviklingsmodeller, falt valget på å sette opp UP (Unified Process). En prosess beskrives av hvem (utviklere) som gjør hva (artefakter), hvordan (aktiviteter) og når (arbeidsflyten) (1). Oversikt over prosessene i UP er slik: IDEFASE UTDYPNINGS- FASE KONSTRUKSJON OVERGANG Figur 13. Unified prosess 42 S i d e

43 43 7. Use Case modell For å vise hva systemet skal gjøre og for hvem, lagde vi en brukstilfellemodell (Use Case Model). Et brukstilfelle er, som navnet tilsier, en isolert funksjon, eller en prosess, som tilfredsstiller et krav hos brukeren, aktøren. Modellen består av et antall brukstilfeller (Use Case) og inneholder i tillegg til diagrammet også en tekstlig beskrivelse. Vi har brukt brukstilfellemodellen til å visualisere kravene til systemet, og benyttet det som vedlegg til en utviklingskontrakt med oppdragsgiver. Use case beskrivelsen er viktig for å beskrive hva et system gjør, men det beskriver ikke hvordan systemet gjør det. Den beskriver hendelsesflyten ved hjelp av tekst, slik at det er lett for en utenforstående å forstå. Figur 14. Use case modell som beskriver systemets hovedfunksjonalitet. 43 S i d e

44 Detaljerte Use Case beskrivelser Registrere ny vare Hovedaktør: Bruker Trigger: Brukeren ønsker å registrere ny vare Forbetingelser: Bruker har tilgang til systemet og er logget inn Sluttbetingelser: Bruker har lagt en ny vare i registeret Hovedscenario og trinn (suksess): 1. Bruker trykker på Legg til ny vare knappen 2. Bruker fyller alle felt med informasjon om varen 3. Bruker fyller ut antall varer som legges inn 4. Bruker trykker lagre knappen 5. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 2a Bruker fyller ikke ut alle obligatoriske felt (feiltilfelle) 2b Vare med samme navn ligger allerede i systemet (feiltilfelle) 2c Bruker fyller ut ugyldig datatype i feltene (feiltilfelle) 3a Bruker fyller inn ugyldig tall 5a Systemet krasjer/overbelastes (feiltilfelle) Tabell 1: Detaljert use case beskrivelse 44 S i d e

45 45 Hovedaktør: Bruker Trigger: Brukeren ønsker å oppdatere vare Forbetingelser: Sluttbetingelser: Hovedscenario og trinn (suksess): Oppdatere vare Bruker har tilgang til systemet og er logget inn Bruker har oppdatert en vare 1. Bruker angir varenavn eller varenummer på varen 2. Bruker trykker på Oppdater vare knappen 3. Bruker fyller nødvendig informasjon som f.eks. antall 4. Bruker trykker på lagre knappen 5. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 1a Systemet finner ikke varen(feiltilfelle) 2a Bruker bommer på knappen og trykker på X i stedet. 3a Feil datatype blir skrevet inn(feiltilfelle) 5a Systemet krasjer/overbelastes (feiltilfelle) Tabell 2: Detaljert use case beskrivelse Hovedaktør: Bruker Trigger: Brukeren ønsker å slette vare Forbetingelser: Sluttbetingelser: Hovedscenario og trinn (suksess): Slette vare Bruker har tilgang til systemet og er logget inn Bruker har slettet en vare 1. Bruker angir varenavn eller varenummer på varen 2. Bruker trykker på slett vare knappen 3. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 1a Systemet finner ikke varen(feiltilfelle) 3a Systemet krasjer/overbelastes (feiltilfelle) Tabell 3. Detaljert use case beskrivelse 45 S i d e

46 46 Hovedaktør: Bruker Trigger: Brukeren ønsker å logge inn Forbetingelser: Sluttbetingelser: Hovedscenario og trinn (suksess): Systemet er oppe Logge inn Brukeren har logget seg inn 1. Brukeren skriver inn brukernavn og passord 2. Brukeren trykker på logg inn 3. Systemet sjekker om brukernavn og passord er riktig 4. Systemet logger inn brukeren Utvidelser (unntak/feiltilfeller): 1b Brukeren fyller ikke ut feltene 3a Brukeren skriver inn feil brukernavn eller passord Tabell 4. Detaljert use case beskrivelse Use case modellen og beskrivelsen finner du også i kravspesifikasjonen. 8. Datastruktur og virkemåte Dette kapittelet beskriver databasestrukturen og virkemåten i applikasjonen. Den forteller oss hvilke klasser applikasjonen har blitt bygd opp av, og tilknytningen til disse. Sekvensdiagram, og klassediagram er en del av kapittelet ER-modellering Et E/R-diagram er en grafisk framstilling av strukturen til en database, men beskrivelsen er abstrakt i den forstand at vi ikke tar stilling til hvordan data er representerert fysisk. E/R står for Entity/ Relationship. E/R blir brukt i tidlig fase under utvikling av databaser. Diagrammene består av entiteter, attributter og forhold, som løselig svarer til henholdsvis tabeller, kolonner og fremmednøkler i en relasjonsdatabase (2). Entiteter viser hvordan de er knyttet sammen til andre entiteter, og hvilke entiteter som var viktig i applikasjonen vår. Før vi startet prosjektet var det bestemt at vi skulle ta i bruk Oracle databasen, men på grunn av flere årsaker og oppsett av databasen, ble det bestemt i samråd med Statsbygg at SQL database også var relevant. Endelige avgjørelsen ble at vi satte opp en SQL database på skolens server. Figurene under ER-modell og attributtene. SQL er et språk utformet for arbeid med databaser. Ved hjelp av SQL kan vi blant annet lage utvalgsspørringer, som henter ut data fra tabeller. Som databasebruker betyr dette at man ikke blir låst til et bestemt verktøy. 46 S i d e

47 47 Se databasestrukturen nedenfor: Figur 15. Databasestruktur 47 S i d e

48 Sekvensdiagram Det finnes to typer interaksjonsdiagrammer, sekvensdiagram og samarbeidsdiagram. Vi velger sekvensdiagram fordi den visualiserer klassesamarbeidet best. Sekvensdiagram og klassediagram sørger for at det er konsistens mellom diagrammene. Den er nyttig for den viser tydelig meldingers struktur og sekvens. Spesielt viser de konstruksjoner som er oversentralisert, hvor et objekt gjør alt arbeidet. Sekvensdiagrammet brukes også til å se atferden mellom flere objekter innen samme Use Case. Vi har valgt ut to sekvensdiagrammer over prosjektet vårt; legg til vare og varehistorikk. Disse viser hendelsene innenfor diagrammet, og ansvarsfordelingen. Figur 16. Sekvensdiagram - Legg til vare 48 S i d e

49 49 Figur 17. Sekvensdiagram Varehistorikk Klassediagram Klassediagram viser de objektene som inngår i problemdomenet. Med problemdomenet mener vi det domenet (området) som skal forbedres med et nytt informasjonssystem. Dette er det grunnleggende klassediagrammet som ligger til grunn for både datamodellering (ERdiagrammet) og for implementering. Operasjoner i tillegg til attributter skal være tatt med her. Dette utføres parallelt med utviklingen av det detaljerte sekvensdiagrammet og ofte selve programmeringen. I klassediagrammet ser vi ulike relasjoner mellom klassene. 49 S i d e

50 50 Figur 18. Klassediagram over lagersystemet 50 S i d e

51 Drifting/Implementering av systemet For å implementere systemet, er det nødvendig å ha en database i bunn, slik at alle data blir overført på den. Det er også nødvendig å ha en.net server, som databasen skal knytte seg opp mot. E-post funksjonen vil fungere hvis den blir knyttet mot Microsoft Outlook 2010, som Statsbygg bruker per i dag. Applikasjonen fungerer optimalt på alle nettlesere som Firefox, Internet Explorer, Opera, Google Chrome. I prosjektet ble nettleser firefox brukt mest. Firefox har egenskaper at den er rask, enkel, og svært utvidbar nettleser. Det er viktig at applikasjonen kjører uavhengig av nettleser. Dersom Statsbygg ønsker å bytte standardnettleseren, er det mulig å benytte applikasjonen. Valideringen er en del av applikasjonen. Valideringen av inputfelt er essensielt for å kontrollere at data som blir satt inn samsvarer med datafeltene i databasen. Vi har både med klient og server validering. Klientvalidering kjører på nettleser og bruker javascript til å sjekke om inputfeltene er av riktig type. Mens servervalidering vil for en siste gang sjekke at dataene som har blitt sendt er riktig, før det settes inn i databasen. Klientvalideringen er avhengig av at man har aktivert java på nettleseren for at den skal fungere, derimot servervalideringen vil slå til uansett. 9. Konklusjon Produktet er ferdigstilt og kan settes ut i drift. Det startet med at applikasjonen ble kjørt på skolens server. Dette var kun en midlertidig løsning fra Statsbygg sin side. Ettersom produktet ble ferdig, ble det tekniske og tidsmessige utfordringer fra oppdragsgiveren og dermed ble applikasjonen stående på skolens server. Med hensyn til kobling mot AD for innlogging i systemet, var det relevant å sette opp applikasjonen på Statsbygg sine egne servere. AD er en sentral katalogtjeneste som kjører på Statsbygg sine servere, for håndtering av brukere. Valget av teknologi gjorde at applikasjonen ble slik vi ønsket. Dette var de riktige avgjørelsene. Programvarene påførte ikke store endringer eller utfordringer, utenom valget av databasen. Kravet fra oppdragsgiveren var å bruke Oracle, men i samråd med Statsbygg ble vi enige om at SQL databasen ville gi en bedre innvirkning med hensyn til oppkobling mot Visual Studio. Arbeidet ble enklere, og vi var ganske godt kjent med SQL språket. Datastruktur i programmet ble løst med ER-modellene. Gruppen fikk bedre innblikk etter å ha diskutert og laget modellene. Entiteter og attributter i sammenheng med databasen, medførte utviklingen av applikasjonen mot databasen raskere. Attributtene ble allerede bestemt og skulle knyttes sammen i databasen. Designvalgene var ikke høyest prioritert i prosjektet vårt, men designvalgene ble likevel gjennomtenkt. Det var viktig at designen ikke skilte seg så veldig mye fra de tidligere 51 S i d e

52 52 applikasjonene i Statsbygg. Applikasjonene var omtrent på samme nivå som vi ønsket å fremlegge vår applikasjon, det gjorde applikasjonen enda bedre. Oppdragsgiveren hadde ikke mange krav til applikasjonen, vi stod fritt til å lage designen på egenhånd, så lenge den var brukervennlig. Målet var å designe layouten så enkelt som mulig. Enkel design passet perfekt til temaet lagersystem. Dokumentasjonen var et godt virkemiddel for prosjektet. Det ble klarert hva vi ønsket, og samtidig var det positivt å se hvordan arbeidet ble 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 dekket. Dokumentasjonen er levende, og jobben er ikke ferdig før dokumentasjonen er oppdatert. Endringer skjedde ofte og ble dokumentert jevnlig. Fordelene er at endringene blir distribuert på et øyeblikk, og det blir også enkelt å sikre (backup). 10. Kilder (1) Systemutvikling - Applikasjoner og databaser av Thor E.Hasle s.94 (2) Systemutvikling - Applikasjoner og databaser av Thor E.Hasle s S i d e

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

54 54 Forord Denne dokumentasjonen er tilrettelagt for sensor, oppdragsgiveren og alle som har interesse for prosjektet. Brukerveiledningen inneholder oversikt over hvordan brukeren skal bruke de forskjellige funksjonene i applikasjonen, og hvordan den kan fungere som et godt samt strukturert verktøy. Brukerne av Teknostorage skal være tilknyttet til ansatte hos Teknotorget. Det innebærer at Teknostorage skal være begrenset og kun tilgjengelig for brukere i Teknotorget. Tilgang til applikasjonen skjer via Active Directory. Denne dokumentasjonen omfatter hovedfunksjonene: Innlogging Oversikt Kategorier Siste hendelser Rapporter Administrering Oppdragsgiveren og sensoren vil også finne brukerveiledningen som PDF format i applikasjonen. Brukeren av applikasjonen trenger ingen avanserte IT-kompetanse for å lese denne veiledningen. 54 S i d e

55 55 Innhold Brukerveiledning Forord Generelt Logg inn Logg ut Hovedsiden Hovedmeny Produktsøk / legg til vare Vareoversikt Kategorier Opprett ny kategori Vis varer Endre Siste hendelser Rapporter Administrering Legg til ny leverandør Endre leverandør Leverandørliste Opprett merke Endre merke Merkeliste Endre varselmail Endre purr Vare Vare detaljer Fyll på varen Varehistorikk Del ut varen Legg til vare S i d e

56 Endre vare Slett varen Generelt Brukerveiledningen er for brukerne av lagersystemet. Formålet med brukerveiledningen er å beskrive hvordan produktet skal brukes og hvordan produktet skal vedlikeholdes. Den inneholder beskrivelse av applikasjonens funksjonalitet. Rekkefølgen av brukerveiledningen er sortert ved å fremstille hvordan applikasjonen vil bli brukt. 2. Logg inn For å få tilgang til webapplikasjonen, må brukeren logge seg på med brukernavn og passord. Brukernavn og passord er tilkoblet AD (Active Directory). Applikasjonen vil gi tilbakemelding om brukerinformasjon er gyldig eller ugyldig. Figur 1. Logg inn Logg ut Etter at brukeren logger ut, vil brukeren komme tilbake til logg inn siden av applikasjonen. 3. Hovedsiden Hovedsiden er den første brukeren kommer til etter innloggingen er utført. Denne siden viser oversikt over alle varer som er i systemet. Navigeringsfunksjonene vil være faste på alle sidene, og vil derfor kun bli beskrevet i dette kapitlet. På startsiden vil brukeren finne hovedmeny, varesøk funksjonen og oversikt over alle varer som er lagret i databasen. 56 S i d e

57 57 Figur 2. Hovedsiden Hovedmeny Figur 3. Hovedmeny Figuren ovenfor viser hovedmenyen. Hovedmenyen består av oversikt, kategorier, siste hendelser, rapporter og administrering. 1. Trykk på «Oversikt» for å vise forsiden, med alle varene. 2. Trykk på «Kategorier» for å vise alle kategoriene 3. Trykk på «Siste hendelser» for å se historikken av hendelser til dagsdato 4. Trykk på «Rapporter» for å importere rapport i PDF format 5. Trykk på «Administrering» for å gjøre endringer i systemet 57 S i d e

58 Produktsøk / legg til vare På produktsøk kan det søkes: Kun varenavn Kun merkenavn Kun kategori Eller kombinasjon av alle tre Se forklaring under. Figur 4. Produktsøk 1. Under «Varenavn» skrives det varenavn som ønskes å søkes 2. Under «Merkenavn» velges det merke som varen tilhører til 3. Under «Kategori» velges det kategori som varen tilhører til 4. Trykk «Søk» for det endelige søket 5. Trykk «Legg til ny vare» for å legge til en ny vare Vareoversikt Siste delen startsiden består av vareoversikt. Figuren under viser hva ulike kolonnene viser. Figur 5. Oversikt over varene 58 S i d e

59 59 1. Side navigeringsbar 2. Kolonne over alle varer 3. Kolonne over varemerke 4. Kolonne over antall varer 5. Kolonne over varekategori 6. Detaljer knapp til varen 7. Endre kolonne 8. Kolonne over lagerstatus 59 S i d e

60 60 4. Kategorier Kategori funksjonen viser oversikt over alle kategorier. Brukeren kan selv navigere seg frem til denne siden ved å trykke på punkt to fra venstre på hovedmenyen. Figur 6. Oversikt over alle kategoriene Opprett ny kategori For å opprette ny kategori, trykk på opprett ny kategori, og følgende side vil komme frem: Figur 7. Opprett ny kategori 60 S i d e

61 61 Dersom registrering av ny kategori blir vellykket, kommer følgende bekreftelse opp på kategori siden. Figur 8. Bekreftelse på lagt inn kategori Vis varer Ved å trykke på «Vis varer», vises følgende side: Figur 9. Vis varer 1. Kolonne over alle varer i kategorien 2. Kolonne over merke tilknyttet til varen 3. Kolonne over antall varer registrert tilknyttet til varen 4. Kolonne over kategori 5. Trykk for å se på «detaljer» til den tilhørende varen 6. Informasjon om alle varer registrerer innenfor kategorien 61 S i d e

62 Endre For å endre kategori, trykk på endre, og følgende side vil komme: Figur 10. Endre kategori 1. For å slette kategori, trykk på «Slett kategori», med det samme vil følgende dialogboks dukke opp for godkjenning: Figur 11. Bekreftelses melding 1.1 Trykk «OK» for å godkjenne handlingen 1.2 Trykk «Avbryt» for å avbryte handlingen Hvis sletting av kategori blir vellykket, vil følgende melding dukke opp på kategori side: 62 S i d e

63 63 Figur 12. Bekreftelse på slett av kategori 2. Skriv inn nytt eller endret navn på kategori for å endre kategori Figur 13. Godkjenning 2.1. Trykk «OK» for godkjenne handlingen 2.2. Trykk «Avbryt» for å avbryte handlingen 3. Trykk på «Lagre endring» for å lagre endringen. Dersom endringen er vellykket, vil følgende melding dukke opp kategori side. Figur 14. Endret kategori 4. Trykk på «Tilbake» for å gå tilbake uten å gjøre noe. 63 S i d e

64 64 5. Siste hendelser «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. Når brukeren peker over hendelsene, blir hendelsen fremhevet ved at hendelsen blir markert. Se figuren under: Figur 15. Siste hendelser Hver kolonne i «Siste hendelser» viser informasjon relatert til deres kolonne: 1. Kolonne «Dato» viser dato og tid når varen ble levert ut eller tatt imot 2. Kolonne «Varenavn» viser hvilken vare raden tar oversikt for 3. Kolonne «Status» viser om leveransen ble tatt imot eller levert ut 4. Kolonne «Antall» viser hvor mange varer ble levert ut eller tatt imot 6. Rapporter Funksjonen rapport tilbyr utskrift av rapport over en vare. Filen genereres i PDF format. Brukeren er pliktig til å fylle inn varenavn i tekstfeltet, og velge datoen. Datoen fra og til. Kalenderen viser alle dagene i måneden, og måneden kan velges ved å trykke på pilen både frem og tilbake i tid. 64 S i d e

65 65 Rapport funksjonen vil føre brukeren til følgende side: Figur 16. Produser rapport 1. Under «Varenavn» velges det vare 2. Under «Dato fra» velges det en fra dato 3. Under «Dato til» velges det en til dato 4. Trykk «Lag rapport» for å generere rapport for den valgte varen Ved å skrive inn varenavn, vil en dropdown boks falle ned, der det kan velges ønsket rapport. Se figur under, importere rapport trinnvis: Figur 17. Trinn 1 Under «Dato fra» kan en velge dato fra kalender. Figur 18. Trinn 2 65 S i d e

66 66 Under «Dato til» kan en velge dato fra kalender: Figur 19. Trinn 3 Trykk nå «Lag rapport» for å få rapporten i PDF format. 7. Administrering Trykk på «Administrering», og brukeren kommer til følgende side: Figur 20. Administrering 1. Trykk «Legg til ny vare» for å legge til en ny vare 2. Trykk «Liste over alle varer» for å liste ut alle varer som er registrert 3. Trykk «Legg til ny leverandør» for å legge til en ny leverandør 66 S i d e

67 67 4. Trykk «Liste over alle leverandører» for å liste ut alle leverandører 5. Trykk «Legg til nytt merke» for å legge til et nytt merke 6. Trykk «Liste over alle merker» for å liste ut alle merker 7. Trykk «Endre varselmail» for å endre malen på varselmail 8. Trykk «Endre purr » for å endre malen på purr Legg til ny leverandør Trykk på «legg til ny leverandør», og brukeren kommer til følgende side: Figur 21. Legg til ny leverandør Dersom registrering av leverandør er vellykket, kommer følgende melding opp på leverandør oversikt siden. Figur 22. Bekreftelse av leverandøren er lagt til 67 S i d e

68 Endre leverandør Trykk på «Administrering», og brukeren kommer til følgende side: Figur 23. Endre leverandør 1. For å slette leverandør, trykk på «Slett leverandør», da vil følgende side dukke opp for godkjenning. Figur 24. Dialogboks for godkjennelse 1.1 Trykk «OK» for å godkjenne handlingen 1.2 Trykk «Avbryt» for å avbryte handlingen 68 S i d e

69 69 Hvis sletting av leverandør blir vellykket, vil følgende melding komme på forsiden: Figur 25. Bekreftelsesmelding 2. Skriver inn nytt eller endret navn på kategori for å endre kategori Figur 26. Dialogboks for godkjennelse 2.1. Trykk «OK» for å godkjenne handlingen 2.2. Trykk «Avbryt» for å avbryte handlingen 3. Trykk på «Lagre endring» for å lagre endringen. Dersom endringen er vellykket, vil følgende melding dukke opp kategori side. Figur 27. Leverandøren er blitt endret 4. Trykk på «Tilbake» for å gå tilbake uten å gjøre noen endringer. 69 S i d e

70 Leverandørliste Figur 28. Leverandørliste 1. Trykk «Legg til ny leverandør» for å legge til en ny leverandør 2. Kolonnen viser alle registrerte leverandører 3. Trykk «Endre informasjon» for å endre informasjon om leverandør Opprett merke Figur 29. Legge til merkenavn Dersom registrering av merke er vellykket, kommer følgende melding opp: 70 S i d e

71 71 Figur 30. Merkenavn er blitt lagt til Endre merke Trykk på «endre merke», og brukeren kommer til følgende side: Figur 31. Endre merke 1. For å slette kategori, trykk på «Slett merke», med de samme vil følgende side dukke opp for godkjenning. 71 S i d e

72 72 Figur 32. Bekreftelse 1.1 Trykk «OK» for godkjenne handlingen 1.2 Trykk «Avbryt» for å avbryte handlingen Hvis sletting av merke blir vellykket, vil følgende melding dukke opp på merke side. Figur 33. Merkenavn lagt til 2. Skriver inn nytt eller endret navn på kategori for å endre kategori 72 S i d e

73 73 Figur 34. Bekreftelse 2.1 Trykk «OK» for godkjenne handlingen 2.2. Trykk «Avbryt» for å avbryte handlingen 3. Trykk på «Lagre endring» for å lagre endringen. Dersom endringen er vellykket, vil følgende melding dukke opp kategori side. Figur 35. Merkenavn har blitt endret 4. Trykk på «Tilbake» for å gå tilbake uten å gjøre noen endringer. 73 S i d e

74 Merkeliste Figur 36. Liste over merkenavn 1. Trykk «Legg til ny merke» for å legge til en ny leverandør 2. Kolonnen viser alle registrerte merkene 3. Trykk «Endre informasjon» for å endre informasjon om merke 74 S i d e

75 Endre varselmail Figur 37. Endre malen for varselmail 1. Endre emnefelt for varselmail 2. Skriv nytt tekst 3. Trykk «Utfør endring» for å lagre de endringene i malen Figur 38. Bekreftelse 3.1. Trykk «OK» for å godkjenne handlingen 3.2. Trykk «Avbryt» for å avbryte handlingen Dersom malen blir vellykket, lagret kommer følgende meldingen på skjermen: 75 S i d e

76 76 Figur 39. Mal er blitt lagret Endre purr Figur 40. Endre purr 1. Endre emnefelt for purr en 2. Skriv nytt tekst 3. Trykk «Utfør endring» for å lagre de utførte endringene i malen 76 S i d e

77 77 Figur 41. Bekreftelse 3.1. Trykk «OK» for å godkjenne handlingen 3.2. Trykk «Avbryt» for å avbryte handlingen Dersom malen blir vellykket, lagret kommer følgende meldingen på skjermen. Figur 42. Mal er blitt lagret 77 S i d e

78 78 8. Vare Vare detaljer Figur 43. Vare detaljer 1. Trykk «Fyll på vare» for å fylle på varer 2. Trykk «Se varehistorikk» for å se vare historikk 3. Skriv inn antall varer som skal utleveres 4. Trykk «Lever ut» for å utlevere det valgte antallet 78 S i d e

79 Fyll på varen Trykk på «fylle på varen», og brukeren kommer til følgende side: Figur 44. Fyll på vare 1. Skriv det antallet som ønskes å bli fylt på med 2. Trykk «Fyll på» for å lagre påfylling av varer Figur 45. Bekreftelse 2.1 Trykk «OK» for å godkjenne handlingen 2.2 Trykk «Avbryt» for å avbryte handlingen Dersom varen blir riktig påfylt, kommer følgende meldingen opp på skjermen. Figur 46. Bekreftelse på fylt vare 79 S i d e

80 Varehistorikk Trykk på «varehistorikk», og brukeren kommer til følgende side: Figur 47. Varehistorikk 1. Kolonne «Dato» viser over dato og tid 2. Kolonne «Status» viser om varen har blitt tatt imot eller levert ut 3. Kolonne «Antall» viser hvor mange varer har blitt håndtert Del ut varen Ved å trykke på lever ut knappen på detaljer siden til valgte varen kommer følgende side opp. Figur 48. Bekreftelsesmelding 80 S i d e 1.1 Trykk «OK» for godkjenne handlingen 1.2 Trykk «Avbryt» for å avbryte handlingen

81 81 Dersom godkjenning vellykket kommer følgende side opp. Figur 49. Utlevering av vare Legg til vare Figur 50. Legg til vare 1. Under «Varenavn» skrives det inn varenavn 2. Under «Merke» velges det hvilken merke varen har 3. Under «Kategori» velges det hvilken kategori varen har 4. Under «Leverandør» velges det hvilken leverandør varen har 5. Under «Antall» skrives det antall varer som er tatt imot 6. Under «Minimumsantall» skrives det minimumsantall varer det skal være for å sende varsel e-post 7. Trykk «Legg til vare» for lagre det skrevet og valgte informasjon Dersom varen blir riktig registrert, kommer følgende melding på hovedsiden. 81 S i d e

82 82 Figur 52. Varen er blitt lagt til Endre vare Figur 53. Endre vare 82 S i d e 1. Under «Varenavn» skrives det inn varenavn 2. Under «Merke» velges det hvilken merke varen har 3. Under «Kategori» velges det hvilken kategori varen har 4. Under «Leverandør» velges det hvilken leverandør varen har 5. Under «Antall» skrives det antall varer som er tatt imot 6. Under «Minimumsantall» skrives det minimumsantall varer det skal være for å sende varsel e-post

83 83 7. Trykk «Lagre endringer» for lagre det skrevet og valgte informasjon 8. Trykk «Slett varen» for å slette varen 9. Trykk «Tilbake» uten å lagre noe Slett varen Figur 54. Bekreftelse 9.1 Trykk «OK» for å godkjenne handlingen 9.2 Trykk «Avbryt» for å avbryte handlingen Dersom varen blir riktig slettet, kommer følgende melding opp på startsiden Figur 55. Varen er blitt slettet 83 S i d e