1. Forord. InventarDatabase

Transkript

1 1. Forord Dette dokumentet beskriver gruppe 6 sin planlegging og utførelse av hovedprosjekt ved Høgskolen i Oslo, avdeling for ingeniørutdanning, vårsemesteret Hensikten med dette dokumentet er å gi leseren innblikk i hvordan gruppen har planlagt og utført prosjektet. Hovedprosjektet har resultert i et system for Kunsthøgskolens IT-avdeling. Generelle kunnskaper om datamaskiner og internett er en fordel for leser, men er ingen forutsetning. Forkortelser benyttet i dokumentet: HIO - Høgskolen i Oslo KHIO Kunsthøgskolen i Oslo (Oppdragsgiver) GUI Graphical user interface (Webbasert nettside) Andre utrykk: System/Systemet Hele produktet Disse forkortelsene vil bli brukt gjennom hele dokumentet. Leser anbefales derfor å huske disse. Rapporten er optimalisert for papir og web. Gruppen retter en stor takk til følgende personer: Veileder Torunn Gjester. Avdeling: IU, Data Tittel: Høgskolelektor For å ha gitt oss gode tilbakemeldinger og virkelig vært tilstede hver gang gruppen har trengt hjelp. Takk! :-) Kontaktperson ved KHIO Ludmila Zakrevskaia Avdeling: IT, KHIO IT-koordinator Først og fremst for sin tillit til oss, for å ha gitt oss denne oppgaven, og deretter for å ha vært en god hjelp underveis. Takk! :-) Side 1 av 20

2 1. INNHOLDSFORTEGNELSE 1. FORORD INNHOLDSFORTEGNELSE INNLEDNING LITT OM OPPDRAGSGIVER DAGENS SITUASJON AV KHIO MÅL OG RAMMEBETINGELSER Mål Rammebetingelser LØSNING PLANLEGGING OG METODE GRUPPEKONTRAKT RISIKOANALYSE OG STYRING MILEPÆLPLAN FREMDRIFTSPLAN DAGBOK UTVIKLINGSMETODE UTVIKLINGSPROSSESEN DANNELSE AV GRUPPE ARBEIDE MED Å FINNE PROSJEKT PROSJEKTSKISSE PROSJEKTSTART FORPROSJEKT KRAVSPESIFIKASJON PROSJEKTETS FASER ANALYSEFASEN Strukturdiagram Dataflytdiagram (DFD) Sekvensdiagram (Hvilket navn kan dette få?) ER-diagram DESIGNFASEN Prototypen Filhierarki Kodeoppbygning IMPLEMENTASJON FASEN TEST FASEN DOKUMENTASJONSFASEN AVSLUTINGSFASEN VERKTØY OG TEKNOLOGI VERKTØY Verktøy for kommunikasjon Verktøy for dokumentasjon og modellering av systemet Vertkøy og teknologi for implementasjon av systemet TEKNOLOGIER: HTML CSS PHP Javascript Mysql PROBLEMER/UTFORDRINGER PROBLEMER I GRUPPEN Side 2 av 20

3 8.2 FAGLIG UTFORDRINGER TIDSMESSIG PROBLEMER KRAVSPESIFIKASJON ENDRINGER I KRAVSPESIFIKASJON OPPSUMMERING/KONKLUSJON HVA HAR VI GJORT HVA HAR VI LÆRT HVA KUNNE VÆRT GJORT BEDRE PRODUKTET: BRUK OG FREMTID PRODUKTETS BRUK PRODUKTETS FREMTID KONKLUSJON Vedlegg 1..Styringsdokumenter Side 3 av 20

4 3. Innledning 3.1 Litt om oppdragsgiver Oppdragsgiver er IT-avdelingen ved Kunsthøgskolen i Oslo(KHIO), som er Norges største kunsthøgskole med et studentantall på omkring 500 studenter. Kunsthøgskolen tilbyr studier innen bl.a. visuell kunst, scenekunst og design. 3.2 Dagens situasjon av KHIO IT avdelingen ved KHIO har opp gjennom årene manuelt administrert og håndrettet oversikt på sitt inventar, herunder datamaskiner, skjermer, software, hardware, lisenser og tilkoblingsanlegg. I tillegg til dette ønskes det å lagre informasjon om ansatte, leverandører, og kontaktpersoner hos leverandørene. IT-avdelingen har benyttet Microsoft Excel til å registrere sitt inventar og deretter skrevet dem ut i papirform. En annen problemstilling er at det bare er en av administratorene som er gitt tilgang til disse dataene, og har dem liggende på sitt kontor. De andre ansatte ved IT-avdelingen er derfor avhengig av at denne administratoren er på sitt kontor når de har behov å få tilgang til dataene. KHIO uttrykker sin bekymring for den uoversiktlige og upraktiske situasjon de er i nå. Kontaktpersonen vår igjennom prosjekttiden har vært Ludmila Zakrevskaia. 3.3 Mål og rammebetingelser Mål Målet med dette prosjektet har vært å gjøre administrasjonen av IT-avdelingen enklere, og samtidig mer praktisk. Til dette ønskes det opprettet en database og en GUI for å kunne lagre og innhente informasjon om ansatte, maskiner, software, lisenser, skjermer, leverandører, kontaktpersoner, heretter kalt Systemet. Systemet skal kunne gjøre det mulig for IT avdelingen å registrere, søke, og endre/slette ønskende opplysninger fra databasen. Systemet skal bare brukes av ansatte i IT-avdelingen og systemet skal være tilgjengelig via internett. Brukerne av systemet skal logge seg inn med brukernavn og passord Rammebetingelser Rammebetingelsene ifra KHIO var at systemet skal være enkelt, brukevennlig og ha et fint utseende. Utover dette fikk gruppen frie tøyler på design og oppbygning. Gruppens rammebetingelser var bygd på rammebetingelsene fra KHIO og den tiden vi hadde til rådighet med hensyn til innleveringsdatoer. 3.4 Løsning Løsningen vi kom fram til etter å ha snakket med oppdragsgiver og internt i gruppen var å lage en database ved å bruke av MYSQL. Mens MYSQL skal benyttes for å lage databasen som skal innholde all informasjon som lagres av IT-avdelingen, skal de kunne administrere informasjon som ligger på databasen igjennom en GUI som vil bli utformet med teknologiene HTML, PHP, CSS, og Javascript. Grunnen til at gruppen har valgt å bruke teknologiene PHP, Html, CSS og Mysql er fordi det er disse teknologiene som kreves for å kunne utføre denne oppgaven best etter gruppens mening. En annen grunn er gruppens kjennskap til teknologiene fra tidligere kurs. Kombinert med Photoshop, som er et velkjent bildebehandlings program, og andre nyttige verktøy, kan vi få til et fint og moderne design på vårt system. Dette gir oss muligheten til å bli kjent med andre verktøy som ikke har direkte sammenheng med vårt studium. Side 4 av 20

5 4.PLANLEGGING OG METODE I denne delen av prosjektet ble det planlagt hvordan prosjektet skulle styres med tanke på planlegging av arbeid, analyse av risikofaktorer involvert, tidsbruk, og arbeidsmetode. For å kunne oppnå dette lagde vi flere styringsdokumenter som prosjektskisse, milepælplan, fremdriftsplan, dagbok. I tillegg bestemte gruppen seg for hvilken systemutviklingsmetode som skulle benyttes. Styringsdokumentene kan ses i sin helhet i vedlegg Gruppekontrakt Det ble utformet en gruppekontrakt raskt etter dannelsen av gruppen, da alle i gruppen var enige om at vi burde ha noen klare retningslinjer og regler når vi skal igjennom et prosjekt av et så stort omfang. 4.2 Risikoanalyse og styring Det er mange usikkerhetsmomenter og risikoer i et prosjekt, som direkte eller indirekte kan påvirke prosjektet på en negativ måte. Det ble derfor utformert en risikoanalyse der gruppen satt opp risikoer som kan skade prosjektet og noen retningslinjer for å hindre eller forebygge at dette skulle skje. 4.3 Milepælplan En milepælplan er oversikten over hvilke oppgaver som skal være utført til et hvert tidspunkt. Vi utarbeidet en milepælplan ut ifra informasjonen i fremdriftsplanen der alle milepælene detaljert står listet opp. Veileder ønsket også en kopi av denne, og tilbakemeldingen ble at veileder synes planen var for lite detaljert. Derfor bestemte vi oss for å henvise til fremdriftsplanen, der milepælene for når ting skal være ferdig detaljert stod listet. 4.4 Fremdriftsplan En fremdriftsplan viser hvordan man har fordelt tiden man har til rådighet på de forskjellige oppgavene. Det kan for eksempel brukes til å planlegge hvor lenge man skal jobbe med en oppgave, hvem som skal jobbe med oppgaven, og når den skal være ferdig utført(milepæl). Gruppen hadde et møte der det ble diskutert hvordan vi skal benytte tiden vi hadde til rådighet. Alt ble skrevet ned for hånd på papir. Dette førte til at vi utarbeidet en fremdriftsplan ved hjelp av verktøyet Microsoft Project. Dette er et meget komplisert verktøy som også veileder syntes vi ikke burde bruke grunnet dens kompleksitet, men vi valgte å bruke det likevel, grunnet gode erfaringer med verktøyet fra tidligere prosjekter. Vi har i etterkant opplevd problemer med å få åpnet filtypen alle steder, og en i gruppen måtte i tillegg få tak i og installere Microsoft Project på sin hjemme pc. Det gikk midlertidig bra da man som student ved HIO kan man laste dette ned gratis fra Microsoft sine sider. Veileder har også hatt problemer med å få åpnet vår fremdriftsplan, noe som ble løst ved at vi fikk levert en papirutgave. Vi holdt på den fremdriftsplanen grunnet dens detaljerte visningsform, men vil eventuelt vurdere å bruke noe mye enklere som Excel neste gang. Side 5 av 20

6 4.5 Dagbok Prosjektdagbok er et enkelt dokument som man kan føre igjennom prosjektets gang. Den kan innholde dato, tid brukt på en oppgave, og eventuelle problemer som oppstå og hvordan disse ble løst. Gruppen bestemte seg for å lage en mal som hvert gruppemedlem skulle bruke hver gang de jobbet med prosjektet. Tidsestimering(tid brukt) ble også gjort med informasjon fra dagboken. Vi utarbeidet et Excel dokument med et regneark for hver måned og hvert regneark inneholdt et skjema der vi kunne fylle informasjon som dato, tid fra-til, emne jobbet med, sted, og eventuelle kommentarer til oppgaven som ble utført. Totaltid blei beregnet automatisk. Skjemaet så følgende ut: Dato Fra Til Totalt Emne Sted Kommentar 1. 0,0 0,0 0,0 2. 0,0 0,0 0,0 3. 0,0 0,0 0,0 4. 0,0 0,0 0,0 5. 0,0 0,0 0,0 Figur 4. 1 Dagbok I tillegg til skjemaet over hadde vi en forside der timene fra hver måned ble lagt sammen og vist sammen med informasjon om hvilket gruppemedlem dagboken tilhørte, oppdragsgiver og prosjektperiode som er vår Skjemaet så følgende ut: Gruppe 6 Inventardatabase År: Vår 2008 Gruppemedlem: Gurpreet Singh Oppdragsgiver: KHIO Totalt time: Figur 4. 2 Beregning Dagbok Side 6 av 20

7 4.6 Utviklingsmetode En utviklingsmetode er en metode for å planlegge hvordan man skal utvikle produktet. Vår gruppe valgte en metode som kalles fossefallmetoden og som navnet tilsier er det en metode som tar for seg hver fase av utviklingen. Fossefallmodellen er delt opp i 5 faser og krever at hver fase er utført før man kan begynner på neste. Disse fasene er: - Kravspesifikasjon: finne ut hvilket krav som stilles til systemet. - Design/Analyse: planlegging av system funksjonalitet, utseende, og eventuelle hindringer. - Implementasjon: begynne å kode etter analysene man har gjort i fasen før og testing. - Integrering/Testing: sette systemet ut i livet hos bruker og teste i samarbeid med bruker. Vedlikeholde: oppgradere og rette eventuelle problemer som dukker opp etter hvert. Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance Figur 4. 3 Fossefallmodellen Grunnen til at fossefallmetoden ble valgt er modellens sterke struktur og dens krav til at en fase må avsluttes før neste kan begynne. En annen grunn til valget av denne metoden var arbeidsgiver selv. Det virket som arbeidsgiver helst ville ha et noenlunde operativt system før de ville gi noen konkrete tilbakemeldinger. Den største ulempen med denne metoden merket vi da arbeidsgiver i implementasjonsfasen endret krav til systemet etter å ha sett resultatet. Dette kunne ha skapt store problemer da fossefall i stor grad ikke tillater å gjøre endringer, men i dette tilfellet var endringene såpass små at det ikke fikk store konsekvenser. I etterkant har det blitt vurdert om den nye utviklingsmetoden kalt SCRUM hadde vært bedre, der man i større grad har kontakt med kunden. Side 7 av 20

8 5. Utviklingsprosessen 5.1 Dannelse av gruppe 2 av gruppemedlemmene hadde jobbet på gruppe før og hadde ønsker om å fortsette det gode samarbeidet videre. Ved en tilfeldighet kom begge medlemmene over en e-post sendt ut av en annen student ved ingeniør avdelingen som også ønsket prosjektgruppe. Det ble da sendt ut et svar om interesse for å jobbe sammen, som resulterte i et møte der vi snakket om hverandres bakgrunn og prosjektønsker. Dette møtet førte til at gruppe 6 ble dannet, bestående av Odd- Arne Eide Bakke, Mehran Paymard og Gurpreet Singh. 5.2 Arbeidet med å finne prosjekt Gruppen var på utkikk etter et prosjekt der det var mulighet for å kunne benytte flere av teknologiene og annen kunnskap gruppen har tilegnet seg opp gjennom årene. Spesielt ville gruppen jobbe med teknologiene JAVA APPLIKASJON, PHP og DATABASE. Flere firmaer ble kontaktet av gruppen via e-post og telefon der vi fortalte hvor vi ringte ifra, at dette gjaldt et hovedprosjekt ved HIO. Vi avsluttet med hvilken fordeler det vil ha, både for oss og dem. Vi kontaktet DHL, Loginor, KHIO, System Hydrolic. 5.3 Prosjektskisse Jakten på et prosjekt resulterte i at KHIO viste sin interesse, og så en mulighet for at vi kunne hjelpe dem med å løse problemet med administrasjonen deres. Dette førte deretter til et møte med ansatte ved IT-avdeling på KHIO, som resulterte i at vi, etter diskusjon i gruppen, valgte dem oppdragsgiver. Etter dette ble det opprettet en prosjektskisse som kort og godt er en oversikt over hvem som er i gruppen, informasjon om oppdragsgiver, og en kort presentasjon av hva oppgaven går ut på. 5.4 Prosjektstart Prosjektet ble sparket i gang allerede i desember ved et møte med KHIO, men arbeidet kom først i gang to uker inn i januar. Det ble opprettet kontakt med veileder, som ble tildelt gruppen, gjennom et møte. Selv om vi hadde fått mye informasjon angående hva de krevde av systemet i møtet før nyttår, kom gruppen og veileder sammen frem til at beskrivelsen var litt vag. Møtet med KHIO etter nyttår var allerede blitt avtalt på det første møtet og der vi gikk igjennom kravene en gang til. 5.5 Forprosjekt Møtene og dialogene med Khio resulterte i at vi kunne utarbeide en forprosjektrapport. Denne rapporten har som hensikt å sette sammen oppdragsgiver nåværende situasjon, forventinger til systemet og av de løsning vi kan tilby dem. 5.6 Kravspesifikasjon Ut ifra mer dialog med KHIO, forprosjekt rapporten og gruppens tolkning av kravene, ble det utarbeidet en kravspesifikasjon; en påbygging av forprosjektet, der forprosjekt bare gir overordnet innblikk i hva oppdragiver krever og går med detaljert inn på kravspesifikasjonene, helt på bunnivå av hva systemet skal gjøre. Dette dokumentet skulle også bli godkjent av oppdragsgiver, veileder, gruppen, og kan anses som en kontrakt mellom partene. Dette dokumentet ble brukt under hele utvikling av systemet da det legger grunnlag for analyse og implementering av systemet. Side 8 av 20

9 6. Prosjektets faser Med planlegging og kravspesifikasjon på plass i den innledende fasen blir de resterende fasene av prosjektet satt i gang med analysefasen først, etterfulgt av designfasen, implementasjonsfasen, testfasen, og til slutt dokumentasjonsfasen. Mens analyse-, design-, implementasjons- og testfasen tar seg av utvikling av selve systemet, er dokumentasjonsfasen mer en avsluttende fase der det ble jobbet med rapport og ferdigstilling av annen dokumentasjon. For å se diagrammene utformet i denne fasen henvises det til vedleggene i produktdokumentasjonen. 6.1 Analysefasen I denne fasen ble det gjort analyse av GUI og databasens oppbygging, utsende og funksjoner ved hjelp av analyseverktøy, også kalt UML-modellering innad i dataverdenen. For å analysere dette ble det utformet Use- Case diagram, strukturdiagram, dataflytdiagram, hendelsesdiagram og et ER-diagram. Hensikten og forklaring på de forskjellige diagrammene kan leses under, men for detaljerte tegninger av de forskjellige diagrammene henvises det til vedleggene til produktdokumentasjonen Strukturdiagram Et strukturdiagram er et diagram som kan benyttes til å få oversikt over hvilke sider vi trenger på GUI. Den bygges ovenifra og ned, det vil si fra den første siden bruker kommer inn på, i dette tilfellet logg inn - siden, og alle sidene etter det. Strukturdiagrammet lar oss planlegge hvilke sider vi trenger, hvilke linker som skal være i hver side, og hvilke underlinker Dataflytdiagram (DFD) Et dataflytdiagram er som navnet tilsier et diagram som viser flyten av informasjon fra den forlater bruker til den når databasen og flyten av informasjon tilbake til bruker. Dette diagrammet hjelper oss med å planlegge kommunikasjon i fra bruker til GUI, GUI til database, og tilbake. For eksempel kan vi ta for oss seansen der bruker skal logge inn i systemet. Da vil bruker oppgi et brukernavn og passord til GUI som sender den informasjon videre til database tabellen (Ansatt) for å sjekke om brukernavn og passordet finnes, og om det er riktig. Denne flyten av informasjon vises i et DFD Hendelsesdiagram Dette diagrammet kan sammenlignes med DFD til en viss grad da den også viser flyten av informasjon, men tar får seg mer detaljert hvilket svar man får fra det. Opprinnelig kalt sekvensdiagram og benyttes som regel til en annen form for programmering. Etter samtale med veileder fant vi ut at slike diagrammer er ment mer for objektorientert programmering noe som ikke var tilfelle i vår oppgave. Vi ble da, sammen med veileder, enige om å endre navn på denne, da vi ville ha det med som ga oss oversikt over hvordan vi skulle utføre kodesjekking av informasjon og feilmeldinger. Vi laget et diagram for hver hovedhandling som skulle utføres i systemet; det innbærer logg inn, søking av informasjon, og lagring av informasjon. Side 9 av 20

10 6.1.4 ER - diagram ER står for Entity Relation (Entitet Sammenheng) og denne modellen viser alle tabellene som skal være med i databasen og hvilken sammenheng de har seg imellom. Modellen lages for å få en god struktur på databasen før man har laget selve databasen. Et er diagram består av: - Entitetstyper (Entities): er selve identifikasjon på tabellen. For eksempel er entiteten til Ansatt tabellen ansatt. - Sammenhengstyper (Relationships): Er sammenhengen mellom entiteten og hvilken relasjon har de til hverandre. For eksempel kan et rom ha flere datamaskiner, som vil føre til en(rom)- til - mange(datamaskiner) relasjon mellom disse tabellene. - Attributter: er en egenskap med entiteten. For eksempel er fornavn og etternavn 2 attributter til entitet Ansatt. - Primærnøkkel: er en spesiell rad I hver tabell. - Fremmednøkkel: er en primærnøkkel til en tabell lagt inn i et annet tabell. Det ble utformet 3 forskjellige eksemplarer av ER-diagram og hvert eksemplar ble diskutert sammen i gruppen. I første eksemplar ble det kort og godt lagt inn hver tabell med bare navn, i andre eksemplar ble det i tillegg lagt inn informasjon som skal være i hver tabell. I det tredje og siste eksemplaret ble sammenhengen mellom tabellene lagt inn. Side 10 av 20

11 6.2 Designfasen I denne fasen ble det lagt mer vekt på hvordan, ikke bare GUI skal se ut gjennom prototyping, men også hierarki av mappene som skal innholde de forskjellige filene, oppbygning av kode, samtidig forutse feilmeldinger som kan oppstå (noe som begrenser seg litt når man ikke er har et fullt funksjonelt system) Prototypen For å kunne få et visuelt bilde av GUI ble det utformet en prototype, som kan være alt ifra kladd på et ark til et GUI med noe funksjonalitet. Prototypens primærfunksjon er å la utviklere danne et visuelt bilde av systemet og mindre funksjonstesting uten å bruke mye tid og ressurser, som kreves hvis man skulle programmere et system. Prototypen som ble utformet besto av linker, tekstbokser, farger og plassering på ting. Det ble utformet en prototype for hver side som ble planlagt i analysefasen ved hjelp av strukturdiagram. Det er ikke gitt at GUI vil se helt lik ut som prototypen, da man kan komme på nye og bedre løsninger underveis. Også denne prototypen avviker noe ifra sluttproduktet. Hele prototypen ble til slutt på flere sider, men under kan man se prototypen av hovedsiden. Figur 6. 1 Prototypen av hovedsiden Filhierarki Det ble utarbeidet et filhierarki slik at man bedre kunne planlegge hvor de forkjellige filene skulle ligge. Det ble valgt å dele opp sånn at hver del av systemet fikk sin egen mappe. Mappene ble fordelt på de forskjellige teknologiene sånn at det ble en mappe med bare PHPfiler, en for Javasript, en for CSS, og alle bildene fikk sin egen mappe. Dette gjør det lettere for oss og en eventuell videreutvikler å finne igjen riktig fil. Et annet aspekt som ble planlangt under planlegging av hierarkiet var å gi filene et logisk filnavn, som også til en viss grad beskriver funksjon til den filen. For eksempel fikk filen som henter fram skjemaet for registrering av nytt rom for nyrom.php. For et detaljert filhierarki henvises det til produktdokumentasjon. Side 11 av 20

12 6.2.3 Kodeoppbygning Det ble ikke satt noe krav ifra KHIO sin side om hvordan kodeoppbygging skulle være, men det ble bestemt i designfasen at vi skulle legge inn et liten notat ved koden som beskriver hvilken funksjon den utfører. Et eksempel på det vises under. <?php $con = mysql_connect('cube.iu.hio.no', 's135368', '') or die( "Could not connect"); if (!$con) { die('could not connect: '. mysql_error()); } mysql_select_db('s135368'); /** ********************************************* Kopler til database og feilmelder dersom ikke kontakt. ********************************************* **/ 6.3 Implementasjonsfasen Etter å ha dannet seg et bedre bilde av systemet i design fasen begynte programmering av GUI i første omgang med hjelp av teknologiene HTML, CSS, PHP, og Javascript. Databasen ble også utviklet parallelt med brukergrensesnittet, men det var da begge delene av systemet var ferdig at sammenslåingen begynte. 6.4 Testfasen Hensikten med denne fasen er å levere et mest mulig feilfritt system til KHIO, selv om ukjente problemer i denne fasen kan dukke opp senere. Fra gruppens side var det veldig viktig å teste alle deler av systemet. Systemet har også blitt testet under design og implementasjonsfasen, men det er først nå vi har et fullt operativt system som vi kan teste for feil. Før testing ble det utarbeidet et produkttest- dokument ved hjelp av verktøyet Microsoft Excel, der man kunne teste funksjonalitet til systemet og notere hvilke feil som dukket opp. Dette dokumentet ble i etterkant brukt til å rette feilene som oppsto. Dette dokumentet ble brukt hver gang funksjonalitet ble testet til alle mulig senario som var i dokumentet gikk ok. I tillegg til å teste funksjonalitet ble det utarbeidet et dokument som tok for seg analyse av GUI. Hvordan man skal analysere et brukergrensesnitt var en egenskap gruppen hadde tilegnet seg under et kurs i MMI(Menneske Maskin Interaksjon) tidligere. Her analyseres det for blant annet farger benyttet, konsistens, og brukervennlighet. For å se dokumentet Analyse av brukergrensesnitt og detaljer rundt hvordan testene blei utført henvises det til testrapportens vedlegg. 6.5 Dokumentasjonsfasen Da alle fasene som ble benyttet for å utvikle systemet var unnagjort, begynte den viktigste delen for oss som studenter. Først og fremst ble all dokumentasjon vi har laget underveis samlet og gått igjennom. Etter dette ble det utarbeidet dokumenter som skulle beskrive arbeidet som ble utført, hvordan det ble planlagt og gjennomført, produktdokumentasjon for å beskrive systemet sammen med testrapport og veiledning for bruk av systemet. Side 12 av 20

13 6.6 Avslutningsfasen I denne fasen ble rapporten gått igjennom av alle gruppemedlemmer for få avdekket skrivefeil og evt. andre mangler. Det var en hektisk kamp med tiden da innleveringsdatoen nærmet seg. Rapporten ble derimot levert i 5 eksemplarer innen fristen og lagt ut på nettsiden vår i tillegg. Kildekode til systemet ble brent på en CD og levert med rapporten. Etter avsluttingsfasen begynte arbeidet med å utarbeide en Powerpoint presentasjon, og øving på presentasjon av prosjektet som skal holdes den 10.juni 2008 startet. Side 13 av 20

14 7. Verktøy og teknologiene 7.1 Verktøy Verktøy for kommunikasjon. MSN Messenger: ble brukt mye for å kommunisere da gruppen hadde en del ting som måtte tas snarest, i tillegg for å dele filer. HIO e-post: ble brukt mye til oversending av dokumentasjon og kontakt med veileder. Mobil: ble ofte benyttet for å formidle datoer og andre viktige beskjeder Verktøy for dokumentasjon og modellering av systemet Microsoft Word: ble hovedsakelig brukt til å skrive rapporter, men også til å utarbeide diagrammer som strukturdiagram og DFD. Microsoft Excel: ble benyttet til å utarbeide produkttest og dagbok. Rational Rose: som er et modellerings verktøy og ble benyttet til å lage Use case og hendelsesdiagram. DB-designer for å utvikle ER-diagram Verktøy og teknologi for implementasjon av systemet PHP-edit: programmere GUI Mysql: sette opp database Photoshop: for behandling av bilder 7.2 Teknologier: HTML HTML(HyperText Markup Language) er en teknologi som benyttes til å lage nettsider. Html benyttes for å strukturere innholdet ved å bestemme plassering, størrelse, og utseende på blant annet tekst, bilder og tekstbokser. I dette tilfellet ble det brukt til å utforme kroppen til GUI. Med dette menes at HTML vil brukes til å opprette linker, tekstbokser, og plassering av disse CSS CSS Cascading Style Sheets er et språk som benyttes til å definere utseende på HTML og XML filer. Fordelen er at et CSS dokument kan benyttes på flere HTML filer dersom filene skal ha samme utseende. CSS kan ligge i selve HTML filen eller hentes inn i HTML som en ekstern fil. I dette tilfellet vil CSS nettopp brukt til formålet å kunne definere utseende på GUI PHP PHP (Pre Hypertext Processor)er et dynamisk programmeringsspråk som benyttes til å lage dynamisk nettsider der informasjon skal hentes og sendes fra en annen tjener eller host. I dette tilfellet ble det språket benyttet til å etablere kommunikasjon, og vil stå for søking mot database, hente ut informasjon og slette informasjon. Side 14 av 20

15 7.2.4 Javascript Javascript er et skriftspråk som er best kjent for å tilføre dynamiske elementer til nettsider. Javascript vil bli brukt til som et kontrollverktøy, der dets oppgave vil være å sjekke at søkekriteriene er riktige og at alt er fylt inn riktig når informasjon skal registreres Mysql MySQL er en database basert på relasjonsmodellen. Den har en åpen kildekode og kan derfor modifiseres om ønskelig og støtter ulike OS. MySQL består av en databasetjener (mysql), en klient (sql) og et stort antall verktøy for vedlikehold og for andre formål. MySQL er godt tilpasset populære programmeringsspråk som PHP, Perl og Java. Mysql har i dette tilfellet blitt brukt til å lage databasen. Side 15 av 20

16 8. Problemer/utfordringer 8.1 Problemer i gruppen Det har til tider vært vanskelig å samle alle i gruppen til å møte og jobbe sammen grunnet noe sykdom og andre private problemer. Dette førte til at det ble noe individuelt arbeid igjennom prosjektets varighet, men noe som i seinere tid å ha vist seg å fungere veldig bra. 8.2 Faglig utfordringer To av gruppemedlemmene måtte oppfriske på kursene som de hadde hatt i andre året bestående av PHP og Database utvikling. I tillegg til dette hadde en av oss, et ellers meget dyktig gruppemedlem, problemer med norskkunnskapene og dette gjorde at han trengte hjelp til formulering og diverse skrivefeil i dokumentasjon. Dette var ikke en stor utfordring, og ble løst av og med de andre gruppemedlemmenes forståelse for problemet. 8.3 Tidsmessig problemer Planlegging av tid har vist seg å være en av de vanskeligere oppgavene i prosjektet. Gruppen har klart å holde tidsrammer for det meste, men har overskredet noe i de siste fasene av prosjektet. Side 16 av 20

17 10. Kravspesifikasjon Som tidligere nevnt er kravspesifikasjonen et dokument som ble benyttet til å belyse kravene til systemet og hva som kreves at planlegging og gjennomføring av oppgaven Endringer i kravspesifikasjon Gjennom prosjekts gang har det kommet endringer i kravspesifikasjonen som har ført til forsinkelser og andre problemer. Etter første versjon av kravspesifikasjon var klar kom det flere endringer. Disse endringene kom ifra KHIO etter å ha sett et mer eller mindre ferdig system. Følgende endringer ble implementert: Database: Tabellen datamaskin måtte oppdateres med 2 nye attributter. Disse er HD og RAM. Tabellen software skulle ikke ha noe anleggsnummer allikevel. Tabellen skjerm skulle ikke ha noe anleggsnummer allikevel. Tabellen ansatt måtte oppdateres med 2 nye attributter, mellomnavn og mobilnummer. Tabellen firma måtte oppdateres med 2 nye attributter, tlfnummer 1 og tlfnummer 2. Tabellen NySoftware ble opprettet. GUI: Funksjonen avansert søk ble implementert En funksjon for å sortere resultatet av søk ble implementert Skriv ut funksjon ble implementert. Andre endringer: KHIO forkastet iden om at andre skal ha tilgang til å søke informasjon. Bare ansatte ved IT-avdelingen skal ha tilgang. Gruppen ønsket å lage en funksjon som gjorde at bruker kunne opprette nye tabeller igjennom GUI, men ideen ble forkastet etter at vi kom fram til at det ikke var tidsmessig forsvarlig å utvikle denne funksjonen. Ved første øyekast ser det ut som det er små endringer, og at det ikke skal være noe problem å overkomme. Det som er nevneverdig er at disse endringene kom ganske seint, noe som gjorde at mye måtte endres med tanke på database og GUI da systemet var så godt som klart. Gruppen gjorde her en fabelaktig jobb med tanke på tidspress og stress foresaket av disse endringene Kravspesifikasjon i dag. Dette dokumentet har hjulpet oss veldig igjennom prosjekt- tiden, og gruppen har i etterkant også lært viktigheten av å ha en god kravspesifikasjon så tidlig som mulig i et prosjekt. Kravspesifikasjon er oppdatert med alle endringer og kan leses i sin helhet som vedlegg i produktdokumentasjon. Side 17 av 20

18 11. Oppsummering/konklusjon 11.1 Hva har vi gjort Vi har planlagt og gjennomført et prosjekt, som resulterte i et produkt for KHIOs IT-avdeling og en rapport som markerer slutten på 3-årig utdanning i data ved HIO. Prosjektet ble planlagt ved hjelp av styringsdokumenter som er nevnt i kapitel 4: planlegging og metode. Produktet som er utviklet og planlagt er utviklet og ferdigstilt ved hjelp av de egenskapene vi har tilegnet oss igjennom studiene. Produktet er en webbasert nettside med en underliggende database. Databasen er for å kunne for å kunne lagre informasjon om forskjellige inventar, og websiden er for å kunne kommunisere med databasen for å adminstrere informasjon som ligger der Hva har vi lært Etter endt prosjekt sitter gruppen igjen med en mye bredere kunnskap om samarbeid i gruppe, planlegging og gjennomføring av prosjekt ved hjelp av styringsdokumenter. I tillegg har gruppemedlemmene en større kunnskap om teknologiene som er brukt i dette prosjektet. Gruppen har også lært hvor vanskelig det kan være å planlegge et prosjekt da helt uforutsette ting kan dukke opp Hva kunne vært gjort bedre Gruppen er enig om at planleggingen kunne vært gjort bedre, selv om det bare skar seg med noen få dager. Gruppen kunne ha krevd mer av arbeidsgiver da det kom til å innhente informasjon om kravene til systemet. Side 18 av 20

19 12. Produktet: bruk og fremtid 12.1 Produktets bruk Dette systemet er utviklet for å lette administrasjonen for KHIOs IT-avdeling av sitt inventar. IT-avdeling kan nå ved hjelp av systemet lagre, søke, endre, slette og oppdatere informasjon om deres inventar, samt ansatte, leverandører, og kontaktpersoner Produktets fremtid Systemet er i skrivende stund ikke overlevert KHIO, da de ønsker at vi hjelper dem med å installere systemet og overføre informasjon fra Excel- filer til databasen. Det har gruppen sagt ja til. Grunnen til at systemet ikke er overlevert er at KHIO prøver å finne et passelig tidspunkt for dette, men systemet er testet av oppdragsgiver og de er meget fornøyde. KHIO kan ved hjelp av en person med nok kunnskap og produktdokumentasjon utvikle systemet til å kunne utføre flere oppgaver. I tillegg kan systemet modifiseres til bruk andre steder. Et eksempel på det kan være en lagerbeholdning. 13. Konklusjon Prosjektet har gitt alle gruppemedlemmene erfaringer de vil ha med seg videre, ikke bare i arbeidslivet, men også livet generelt. Gruppemedlemmene har modnet som personer, lært å samarbeide bedre med andre mennesker og samtidig vise forståelse for hverandres problemer. I tillegg til dette har gruppen fått et stort kunnskapsløft innen prosjektarbeid og systemutvikling. Nye teknologier har blitt tilegnet og interessen for prosjektarbeid har vokst. Side 19 av 20

20 13. Figurliste Figur 4. 1 Dagbok... 6 Figur 4. 2 Beregning Dagbok...6 Figur 4. 3 Fossefallmodellen... 7 Figur 6. 1 Prototypen av hovedsiden Side 20 av 20

21 Vedlegg 1 Styringsdokumenter Dette dokumentet innholder vedlegg til Prosessrapporten

22 1. Innholdsfortegnelse 1. INNHOLDSFORTEGNELSE STYRINGSDOKUMENTER GRUPPE KONTRAKT RISIKOANALYSE PROSJEKTSKISSE FORPROSJEKTRAPPORT... 8 Styringsdokumenter Side 1 av 11

23 2. Styringsdokumenter 2.1 Gruppe kontrakt Gruppekontrakt for gruppe 6 Kontraktens område Denne kontrakten gjelder for de undertegnede i hovedprosjektets varighet ved Høyskolen i Oslo, våren 2008 heretter kalt gruppe 6. Kontrakten ansees som avsluttet etter levering/fremføring av prosjektresultat og mottatt sensur, eller når individuelle studenter avslutter sitt studieforhold ved skolen eller gruppen. De undertegnede skal til enhver tid føye seg etter denne kontrakten. Arbeidstid Gruppe 6 medlemmer skal etter beste evne møte til oppsatt arbeidstid eller oppgi grunn for ikke å gjøre dette så tidlig som mulig. Denne arbeidstiden kan avtales felles, eller ved flertall eller gruppelederens begrunnede syn, flyttes såfremt dette ikke går utover alminnelig skoletid hvis ikke alle involverte anser dette som aktuelt. Alle medlemmer plikter å møte til ethvert oppsatte møte. Unntak er dersom bare det er sent ut e-post og dette mindre enn 24 timer før oppsatt møtetid. Arbeidsgjennomføring Gruppe 6 medlemmer plikter å gjøre det arbeid de har godtatt å utføre etter beste evne til den tid gruppen har satt som ønsket tid for ferdigstillelse. Gruppen kan vurdere arbeid som ikke utført etter å ha vurdert arbeidsmengde opp mot gitt tid og andre omstendigheter individer kan ha måttet møtt. Omstendigheter individer ikke selv har forårsaket og kontroll over, skal gå i favør av vedkommendes arbeidsevne det stilles spørsmål ved. Fravær Lengre tids fravær skal meldes minst ett annet gruppemedlem så snart det er råd. Å ikke informere et annet gruppemedlem ved 3 tilfeller av fravær er grunn for at gruppen kan ta det opp med den aktuelle personen for å få en forklaring på fraværet. For dårlig forklaring resulterer til at det i førsteomgang tas opp med veileder. Hvis ikke det blir noe forbedring kan utkastelse vurderes av de andre i gruppen. Uteblivelse fra et oppsatt møte uten å på forhånd melde ifra til et annet gruppemedlem medfører advarsel. Å ikke melde ifra om dette 3 ganger, medfører at gruppen kan ta kontakt med veileder. Dersom fravær blir meldt ifra på forhånd, men gruppen anser grunnlaget som ikke tilstrekkelig for fritak, kan gruppen ved tredje gangs hendelse eller flere, ta kontakt med veileder. Styringsdokumenter Side 2 av 11

24 Konsekvenser Gruppen skal, dersom det viser seg at et medlem ikke følger kontrakten, ta kontakt med veileder. Ekskludering skjer etter skolens reglement. Dersom samme person står for flere kontraktsbrudd etter at veileder er kontaktet, kan veileder umiddelbart kontaktes på nytt. Hvorvidt gruppen velger å gi en advarsel i stedet/i tillegg er opp til gruppens flertall. De undertegnede ansees som bundet av denne kontrakten i den angitte tiden. Gurpreet Singh Mehran Paymard Odd-Arne Eide Bakke Styringsdokumenter Side 3 av 11

25 2.2 Risikoanalyse Risikoanalyse og styring Risiko Sannsynlighet Følger Frafall fra studiet Lav Katastrofal Konflikter Middels Alvorlig Sykdom innad i gruppen Middels Alvorlig Ikke godt nok kvalifiserte gruppemedlemmer lav Katastrofalt Underestimering av Tid Høy Alvorlig Store endringer av krav til produktet Høy Alvorlig Tap av data Lav Alvorlig Risiko Frafall fra studiet Konflikter Sykdom innad i gruppen Underestimering av Tid Store endringer av krav til produktet Strategi Gruppen må sørge for tilstrekkelig dokumentasjon slik at et annet gruppemedlem kan ta over oppgaven. I tillegg vil god kommunikasjon forebygge dette problemet. Gruppeavtale som signeres av alle gruppemedlemmer, snakke med veileder før eventuelle konflikter blir for store. Sørge for tilstrekkelig dokumentasjon, slik at vi unngår at en person sitter på nøkkelkunnskaper, og et annet gruppemedlem kan fortsette på arbeidet. Det er også viktig at gruppemedlemmene melder ifra straks de blir syke i lengre periode. Det burde da la seg gjøre å foreta eventuelle justeringer i tidsplan. Utarbeide en god tidsplan med mulighet for slakk. Vi beregner mer tid enn vi egentlig trenger på alle fasene. Sette fristen for innlevering av arbeid 2 dager i forveien. I tillegg satser vi på hyppige møter, minimum ett møte for hver innlevering vi leverer. Ikke godt nok kvalifiserte gruppemedlemmer Tap av data Egenstudie og kompetanseøkingen av bedre kvalifiserte gruppemedlemmer. Et prosjekt mappe skal ligge på skolens server, utført arbeid skal sendes på e-post til alle gruppemedlemmene, mappen skal ligge på en felles minne pen, og i tillegg til dette får et i gruppen ansvaret for å skrive ut all dokumentasjon og lagre det i papirform. Styringsdokumenter Side 4 av 11

26 2.3 Prosjektskisse Gruppemedlemmer Mehran Paymard S Odd-Arne eide Bakke s Gurpreet Singh s Oppdragsgiver Kunst Høgskolen i Oslo Fossveien Oslo Kontaktperson Ludmila Zakrevskaia Prosjektbeskrivelse Det skal opprettes en database og en webside for styring av inventarer herunder datamaskiner (PC og Mac), software, lisenser og skjermer som er i bruk i hver eneste rom i høyskolen. Systemet skal gjøre det mulig for IT- avdelingen å registrere og finne ut ønskende opplysninger. Dessuten skal de andre avdelingene ved Høgskolen ha tilgang til en del av systemet for å søke informasjon. Systemet skal være tilgjengelig via internett. Vi skal gjøre en fullstendig analyse til å kartlegge behovet så vi vil antageligvis komme med noen endringer underveis. Til å oppnå kravene i oppgaven har vi valgt å benytte PHP og MYSQL og eventuelt Java. Vi vil lage systemet så brukervennlig som mulig og blant annet vurdere normalisering og et godt brukergrensesnitt i vår oppgave. Styringsdokumenter Side 5 av 11

27 2.5 Fremdriftsplan Styringsdokumenter Side 6 av 11

28 Styringsdokumenter Side 7 av 11

29 3. Forprosjektrapport Presentasjon Tittel: Inventardatabase Tema: Oversikt over Ansatt, Rom, Datamaskin, skjerm, Software og Stikkontakter. Veileder: Torunn Gjester Prosjektgruppe: Mehran Paymard S Odd-Arne Eide Bakke s Gurpreet Singh s Oppdragsgiver: Kunsthøgskolen i Oslo Kontaktperson: Ludmila Zakrevskaia Sammendrag Oppgaven er et hovedprosjekt ved Høgskolen i Oslo, avdeling for ingeniørutdanning ved datalinjen, og gjennomføres i samarbeid med Kunst høgskolen i Oslo, heretter kalt KHIO. Vi skal laget et webbasert system for administratorene ved IT avdelingen på KHIO. Administratoren er den i avdelingen som skal holde rede på disse hovedkategoriene: Ansatte Rom Datamaskiner Skjerm Software Stikkontakter For hver av disse kategoriene skal administratoren kunne gjøre følgende operasjoner: Registrering Søkning Endring og sletting Dagens situasjon Dagen situasjon er at IT avdelingen bruker Excel ark til å føre inn all informasjon om deres inventarer. Noe som mildt sagt er tungvint og med stor fare for feil. Det er dessuten veldig vanskelig å få ut rapporter på noe som helst. Etter hvert som skolen har vokst, ser de at regnearket bare vokser og vokser, slik at det har blitt uoversiktig og tungvint å bruke, og svært ofte får de ikke brukt det til det de skal. Tilgang til informasjon må gå igjennom administratoren, som har det liggende på sitt kontor. Dessuten er det bare han som har tilgang til informasjon. Vi vil lage programmet webbasert slik at administratoren og de andre (i følge rettigheter som kan beskrives)får tilgang i systemet hvor det er internett. Dette vil føre til at det blir mer tidseffektiv og enklere for administratoren da han blant annet får gjort sine oppgaver overalt. Styringsdokumenter Side 8 av 11

30 Mål og rammebetingelse Vårt program skal ha oversikt på de kategoriene nevnt nedenfor slik at det kan håndteres etter de ønskede kravene. F.1 KHIO klassifikasjon. ROM De ansatte og datamaskinene befinner seg i et rom. Rommene må registreres for å holde orden og oversikt på hvor ansatte og datamaskiner befinner seg. Det som skiller hvert rom fra hverandre er rom nummeret. For hvert rom skal det programmet gjøre følgende: Registrere Vise og søke Endre/slette ANSATT IT avdelingen har som sagt ca 6 ansatte til daglig. Disse har forskjellige titler som krever sine eget rettigheter mot systemet. Det som skiller hver ansatt fra hverandre er brukernavn. For hver ansatt skal programmet gjøre følgende: Registrere Vise og søke Endre/slette Datamaskiner Hver ansatt er tildelt en eller flere datamaskin. Vi skal skille hver datamaskin ved hjelp av DNS (Domain Name System). For hver datamaskin skal programmet gjøre følgende: Registrere Vise og søke Endre/slette SOFTWARE Hver datamaskin er utstyrt med forskjellige software. Software må registreres for å holde oversikt over hva som er installert på datamaskinene til de ansatte. Det som skiller hver software er produktnavnet. For hver software skal programmet gjøre følgende: Registrere Vise og søke Endre/slette Styringsdokumenter Side 9 av 11

31 SKJERM Hver skjerm er knyttet til en datamaskin. Det som skiller hver skjerm er serienummeret. For hver skjerm skal programmet gjøre følgende: Registrere Vise og søke Endre/slette STIKKONTAKT Hver rom har en eller flere stikkontakter som skiller med stikknummer. For hver software skal programmet gjøre følgende: Registrere Vise og søke Endre/slette Løsninger/alternativer Vi har tenkt å bruke Php, html og Mysql som hovedspråk, og kommer til å lagre informasjon om kategoriene i en database. Vi vil selvfølgelig bruke de andre nyttige verktøyene for vår løsning. Andre relevante språk Vi kunne også for eksempel benyttes oss av en Java løsning, men følgende kriterier går imot dette forslaget: Lokalt system: Vår oppdragsgiver var spesielt interessert i en webbasert løsning og et lokalt system passet derfor ikke. Webbasert: Vi kunne brukt Java som en webbasert løsning. Dette er for så vidt en ny teknologi og vi har dermed ikke vært mye borti dette på skolen. Hvorfor PHP og MYSQL? Grunnen til at vi har valgt Php, html og Mysql som hovedspråk er fordi vi mener det egner seg best med tanke på en webbasert løsning. Vi har tro på at php er et nyttig programmeringsspråk i videre tid framover og har valgt å gå dypere innpå dette området. Dessuten kombinert med Photoshop og andre nyttige verktøy kan vi få til et fint og moderne design på vårt system. Dette gir oss muligheten til å bli kjent med andre verktøy som ikke har direkte sammenheng med vårt studium. Konklusjon Vår hensikt er å øke effektiviteten til IT avdelingen og med den nye applikasjonen vil for administratoren derfor kunne: Gjøre det lettere å holde oversikt over Ansatte, Rom, Datamaskiner, Skjerm, software og Tilkoblingsanlegger. Kunne gjøre søk på dem. Oppdatere og behandle dataene. Øke tidseffektiviteten. Kunne benyttes overalt der det er internett tilgang. Styringsdokumenter Side 10 av 11

32 Styringsdokumenter Side 11 av 11