Prosessdokumentasjon for Agresso Employee Hovedprosjekt i data våren 2007

Størrelse: px
Begynne med side:

Download "Prosessdokumentasjon for Agresso Employee Hovedprosjekt i data våren 2007"

Transkript

1 for Agresso Employee Hovedprosjekt i data våren 2007 Gruppe 20: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal

2 2 Agresso Employee

3 Sammendrag Dette prosjektarbeidet er resultatet av den avsluttende delen i ingeniørutdanningen ved Høgskolen i Oslo, avdeling for ingeniørutdanninga. Prosjektarbeidet ble utført av Anders Hartvoll Ruud, Christian Årving, Sahdia Moghal og Leif Martin Næss i løpet av vårsemesteret Prosjektoppgaven ble gitt av IT-selskapet Agresso R&D og har gått ut på å utvikle et ansettelsessystem for selskapets avdeling på Nydalen. Hensikten var å automatisere mange av oppgavene rundt en nyansettelsesprosess slik at det ble mindre arbeid rundt dette. Ansettelsessystemet vi har utviklet er en webapplikasjon som har fått navnet Agresso Employee. Systemet fungerer slik at brukeren kan registrere nødvendig personalia på en nyansatt, opprette den nyansatte på Agresso s to domener; CORP og Agresso, registrere og få bestilt diverse utstyr og software til nyansatt, diverse e-post genereringer i forbindelse med bestillinger og valg av fadder og fagansvalig, få oversikt/status over alle utførte og gjenværende oppgaver på en nyansatt og administrere oppgaver. Agresso Employee er utviklet til bruk internt i selskapets avdelinger på Nydalen. Applikasjonen er derfor kun tilgjengelig på Agresso s intranett; Programmet tilfredsstiller kravene i kravspesifikasjonen og oppfyller oppdragsgiverens forventinger. Det er også blitt lagt til funksjonalitet som ikke er beskrevet i kravspesifikasjonen, dette for å gi Agresso den beste løsningen. Applikasjonen er i hovedsakelig utviklet i Visual Studio 2005 ved hjelp av teknologi som C# og ASP.NET. Dette var krav fra Oppdragsgiver. Perioden fra utviklingen av kravspesifikasjonen til det ferdige produktet endelig står ferdig i dag, har vært veldig lærerik, både faglig og personlig. Vi har alle tilegnet oss kunnskaper på forskjellige nivå som er svært nyttige for oss å ta med oss videre i arbeidslivet. Det er blitt lagt med stort arbeid i dette prosjektet og vi er alle svært fornøyde med det vellykkede resultatet vi i dag kan presentere. Agresso Employee 3

4 Forord Dette dokumentet er en prosessdokumentasjon for bacheloroppgaven ved Høgskolen i Oslo, avdeling for ingeniørutdanning, retning ingeniørfag i data, i vårsemesterperioden Dokumentet henvender seg hovedsaklig til sensor og veileder i tilegg til de som måtte være interessert i å få et innblikk i hvordan prosjektarbeidet har forløpt og hvordan vi har kommet frem til det endelige produktet. Vi ble sikret dette prosjektet like etter å ha vist interesse i et prosjektforslag lagt ut av dem på HiO sine hjemmesider. Muligheten til å lære oss Microsoft teknologi som.net, veldig fleksibel oppgave og utfordring i ett, virket fristende. Prosjektet gikk ut på å utvikle et internt system som hjelper Agresso R&D AS med håndtering av nyansatte. Det har vært en lærerik periode hele veien og vi sitter i dag igjen med god erfaring på hva vi har å møte ute i arbeidslivet. Dessuten har vi fått oppsummert det som har vært viktigst løpet av de tre årene våre på ingeniørhøgskolen. Dette dokumentet er skrevet på papirform, men er også tilgjengelig på prosjektets hjemmeside, Tilslutt her vil vi gjerne takke følgende personer: Hverandre, for et supert samarbeid gjennom alle prosjektets faser, for oppmuntringen, spydighetene og samholdet. Vår veileder Rune Spersøy, for god oppfølging og for at han hele tiden har vært tilgjengelig for oss under hele prosessen. Og for fellesområdet. Vår interne veiledere, Demissie Aredo og Thor E. Hasle for god veiledning gjennom hele prosjektet og kunnskapen de har delt med oss innen systemutvikling og prosjektledelse. Alle som deltok under utviklingen av kravspesifikasjonen. Alle andre som har spilt en rolle for prosjektet vårt. 4 Agresso Employee

5 Innholdsfortegnelse SAMMENDRAG... 3 FORORD... 4 INNHOLDSFORTEGNELSE INNLEDNING PROSJEKTBESKRIVELSE Bedriften Dagens situasjon Mål Rammebetingelser Personvern VERSJONSTYRING KRAVSPESIFIKASJONEN OG UTVIKLING DATAINNSAMLING UTVIKLINGEN AV KRAVSPESIFIKASJONEN ENDRINGER I KRAVSPESIFIKASJONEN KRAVSPESIFIKASJONEN OG UTVIKLINGEN I DESIGN OG IMPLEMENTERING KRAVSPESIFIKASJONEN OG DET FERDIGE PRODUKTET PLANLEGGING OG METODE PROSJEKTGRUPPEN WEBSIDE OG PROSJEKTDAGBOK BÆRBAR OG FELLESOMRÅDE ARBEIDSMETODEN Prosessmodellen RUP Prosessmetoder PROSJEKTSTYRING Arbeidsplan Fremdriftsplan/Gantt-diagram Tidsestimering Risikoplanlegging Risikoanalyse Re-risikoanalyse ARBEIDSVERKTØY OG UTVIKLINGSTEKNOLOGI LÆRING AV NY TEKNOLOGI MØTER MED VEILEDER VED IU PROSJEKTORGANISERING INTERN ORGANISERING AV GRUPPA PROSJEKTANSVARSKART UTVIKLINGSPROSESSEN UML MODELLERING Workflow diagrammer Use Case diagram Agresso Employee 5

6 5.1.3 Use Case beskrivelser Klassediagram Sekvensdiagrammer Registrer nyansatt Opprett nyansatt i Active Directory Send e-post til resepsjon DESIGN AV BRUKERGRENSESNITT IMPLEMENTERING AV SYSTEMET Begynnelsesstadiet og teknologi Implementeringens gang Avslutningen TESTING UNDERVEIS FORBEDRINGER I SYSTEMET Systemet per i dag Forbedringer DOKUMENTASJON OPPDRAGSGIVERS ROLLE UNDER IMPLEMENTERINGEN TESTING INTERN TESTING Den interne testplanen Testutføring og resultat av testingen Feilrettinger EKSTERN TESTING Den eksterne testplanen Utføring Resultat AVSLUTNING SAMARBEID I GRUPPEN, ARBEIDSMILJØ OG MOTIVASJON VURDERING AV EGET ARBEID UTVIKLINGSMULIGHETER Autogenerering av velkomstbrev til nye ansatte Mulighet for å legge inn nyansatte i selskapets interne diskusjonsforum Mulighet for å legge nyansatte inn i selskapets lønns og personalsystem, Agresso Mulighet for automatisk delegering av tasks i systemet når den ansvarlige er borte Knytte oppgaver i systemet til grupper i stedet for personer Mer muligheter i valg av utstyr for den nyansatte Utvide systemet til ikke kun å brukes ved ansettelser KONKLUSJON Agresso Employee

7 1. Innledning Vi har i dette prosjektet hatt gleden av å jobbe på hovedkontoret til Agresso i Nydalen. Agresso er et internasjonalt selskap med kontorer både i USA og Europa. Agresso trengte et system som skulle hjelpe dem i ansettelsesprosessen og vi fikk oppgaven å lage et verktøy som gjør prosessen mer punktlig, holder orden på hvilke valg som må tas, hvilke oppgaver som må gjøres og hvem som skal gjøre dem. De ønsket seg et funksjonelt system for intern bruk i bedriften. Agresso la vekt på at vi måtte gjennomførte prosjektet med en grundig analyse og planlegging av design. De ønsket seg et system hvor de lett kunne legge til eller fjerne funksjoner. Dette prosjektet har gitt oss muligheten til å bli bedre kjent med en rekke nye elementer som vi ikke tidligere hadde noen erfaring med. Vi har fått jobbe med relativ ny teknologi siden Agresso ønsket seg en løsning utviklet i ASP.NET og C#. Agresso krevde at vår løsning på oppgaven skulle kunne sende data mot to forskjellige domener. Vi har fått en god forståelse for hvordan Active Directory fungerer og Agresso sitt datanett er bygd opp. Oppgaven krevde i starten at vi nøye kartla den daværende workflowen ved nyansettelse. Dette var nødvendig for å få et helhetligbilde av den prosessen og hvilke elementer det var viktig for oss å få med i produktet for at brukerne og oppdragsgiver skulle bli fornøyd. 1.1 Prosjektbeskrivelse Først en beskrivelse av oppdragsgiver, situasjonen i dag og mål og rammekrav til den nye løsningen Bedriften Utviklingen av AGRESSO programvare startet i Inenco AS som ble etablert i Selskapet Agresso AS ble etablert i Agresso AS leverer AGRESSO økonomi- og personalsystemer (AGRESSO Business World) med tilhørende konsulenttjenester og kundeservice til det norske markedet. Sammen med sine partnere betjener selskapet over 700 kunder i Norge. Utviklingen av AGRESSO Business World skjer i søsterselskapet Agresso R&D AS (Oslo). Produktporteføljen AGRESSO Business World (ABW) består av fullt integrerte økonomi- og personalsystemer. Til sammen ivaretar ABW alle sentrale deler av økonomistyring, kompetanseforvaltning, personaladministrasjon og tilhørende ledelsesinformasjon for mellomstore og store organisasjoner. Høy funksjonalitet og bruk av moderne web- og mobilteknologi bidrar til å skape fortrinn. Derfor foretrekkes AGRESSO Business World av virksomheter innen både privat og offentlig sektor verden over Dagens situasjon Per i dag gjennomføres ansettelsesprosessen manuelt hvor både it avdeling, HR avdeling og avdelingsledere pluss resepsjon må legge inn data og manuelt overrekke dette til neste ledd i Agresso Employee 7

8 prosessen. Ingen ting blir automatisk oversendt. Arbeidsoppgavene må også gjøres flere ganger, siden det er mange forskjellige systemer den nyansatte må opprettes i, blant annet CORP domene AGRESSO domene. Der må data legges inn begge steder hver for seg. Agresso ønsker å automatisere/forenkle prosessen med en mer strukturert arbeidsflyt prosess /arbeidsflyt rundt ansettelsen av en ny person. Dette innebærer at data blir generert slik at de ikke trenger å bli lagt inn flere ganger Mål Målet med prosjektet er å utvikle et internt system som hjelper Agresso R&D AS i ansettelsesprosessen som følger etter at beslutningen om ansettelse er tatt. I denne prosessen må data registreres, en del valg må tas og mange oppgaver gjennomføres. Vi skal utvikle et system som skal kunne brukes til å legge inn på ett sted, data om den nyansatte som inngår i ansettelsesprosessen slik at dette blir sendt ut til CORP og Agresso domenet. generere brukernavn til nyansatt basert på dette i Agresso s system og lage et hjemmeområde på filserver pluss å lage et nyansatt dokument, sette opp e-post, gi brukerrettigheter, posthylle og adgangskort. generere e-post med bestilling av nødvendig utstyr som mobiltelefon, fasttelefon og registrere hvilken PC pakke nyansatt skal ha. Være brukervennlig. Tekniske forkunnskaper ikke er nødvendig for å kunne bruke systemet Rammebetingelser Rammebetingelsene i dette prosjektet er at vi skal utvikle systemet i ASP.NET og C#. Systemet skal støtte Internet Explorer 7.0. Ellers er prosjektet ganske fleksibelt med henhold til omfang, vi kan enkelt legge til eller trekke fra funksjonalitet etter hvert Personvern Lover om personvern og andre relevante lover skal overholdes. Da systemet håndterer potensielt sensitive personopplysninger skal tilgang begrenses til et fåtall, navngitte personer. 8 Agresso Employee

9 1.2 Versjonstyring Versjonstyring gir en oversikt over hvor mange versjoner vi styrte med før endelig innlevering, dato de ble ferdigstilt og grov oversikt over endringene gjort fra forrige versjon. Versjon Beskrivelse av versjon Leveransedato 1.0 Første ferdigstilling av hele rapporten 14. mai Endringer og tilføyninger i punkt 8 og 10. Endring av struktur. 1.2 Finpuss av setningsoppbygging og skrivefeil. Innleveringsklar! 20. mai mai 2007 Agresso Employee 9

10 2. Kravspesifikasjonen og utvikling Under dette avsnittet finner du informasjon om hvordan vi har jobbet med innsamling av data for å kunne utvikle kravspesifikasjonen og hvordan vi har brukt kravspesifikasjonen videre i utviklingen. De funksjonelle egenskapene til prosjektet har under prosjektperioden hvert litt flytende. Kravspesifikasjonen har derfor hele tiden hatt en utvikling som har vært i tråd med endrede krav. Endringer i forhold til kravspesifikasjonen er også beskrevet her. 2.1 Datainnsamling Under utviklingen av forprosjektet fikk vi en grov oversikt over kravene til det nye ansettelsessystemet slik at vi så smått kunne komme i gang. Men for å få en mest mulig detaljert oversikt over kravene, måtte det samles inn enda mer data. Vi foretok denne datainnsamlingen ved hjelp av en rekke møter med arbeidsgiveren. Alle som vanligvis deltar i en ansettelsesprosess var til stede på disse møtene. På møtene satte dem oss inn i hvordan ansettelsesprosessen fungerer per i dag, hva dem er misfornøyd med og hvilke forbedringer de ønsker. Gjennom spørsmål og svar fikk vi både konkrete og mindre konkrete krav fra dem. De visste de ønsket å forbedre denne prosessen, særlig den delen hvor en nyansatt skal opprettes i do domener, men var usikker på hvordan en endelig løsning skulle være. Alle andre funksjoner de ønsket å ha med i programmet ga de lavere prioritet. Sammen med ITavdelingen valgte vi ut en rekke funksjoner som vi ville ha med i systemet. De stod åpne for forslag fra oss. 2.2 Utviklingen av kravspesifikasjonen Etter disse møtene, hadde vi nok informasjon til å komme i gang men utviklingen av kravspesifikasjonen. Først lagde vi et par forslag til løsninger for arbeidsgiveren, fikk tilbakemelding på forslaget og utviklet forslagene. Slik fortsatte vi til vi hadde fått et forslag arbeidsgiver var fornøyd med. Forslagene ble laget både ved hjelp av workflow og tekst. Utviklingen tok noe lenger tid en beregnet, bl.a. fordi det måtte et par møter og bekreftelser til før vi kunne fortsette med utviklingen av kravespesifikasjonen. 2.3 Endringer i kravspesifikasjonen Selv om kravspesifikasjonen vår ble utarbeidet i samarbeid med og ved hjelp av tilbakemeldinger fra oppdragsgiver, viste det seg likevel at en del endringer måtte til etter hvert. Fra de første overordnede målene vi fikk beskrevet i forprosjektet, til selve kravspesifikasjonen var laget, var det endringer nesten kun i form av utdypning og spesifisering. Den endelige kravspesifikasjonen ble godkjent av både intern veileder ved IU og oppdragsgiver. I begynnelsen av utviklingsfasen derimot fikk vi fra oppdragsgiver beskjed om å droppe et par av kravene vi hadde kommet frem til. Dette gjaldt muligheten for registrering av interne og eksterne kurs i ansettelsessystemet som skulle utvikles. Her skulle brukeren ha mulighet til å 10 Agresso Employee

11 legge til interne kurs i systemet samt melde opp en nyansatt i enten det interne eller et ønskelig ekstern kurs. Systemet skulle i den forbindelsen også håndtere nødvendige genereringer av bekreftelses e-post og tilgjengelig status over bestilte interne og eksterne kurs. Utelukkingen av funksjonene var hovedsaklig grunnet Agresso R&D s innkjøp av et annet system som skal ta seg av den type registrering. Vi kunne derfor legge mer fokus på å få registrert personalia og få opprettet brukeren i CORP og Agresso domenene. Muligheten for å melde nyansatt inn i forskjellige forums var en funksjon vi sammen med IT avdelingen oppfattet som en mindre viktig funksjon og derfor ekskludert fra vårt system. Agresso krevde et system man enkelt kunne legge til eller trekke fra funksjoner, så selv om vi har fjernet noen funksjoner fra programmet så kan disse eller andre på et senere tidspunkt enkelt legges til og implementeres. Vi valgte å ikke integrere vårt system med lønnsystemet til Agresso pga at brukergrensesnittet til Agresso sitt system ikke var klart og vi fikk ikke lov til å koble oss direkte til lønnsystemet sin database. 2.4 Kravspesifikasjonen og utviklingen i design og implementering Siden det var mye ny teknologi vi hadde tilegnet oss kunnskaper om fant vi det mest naturlig å utforske med GUI en. Kravet var et enkelt, konsistent brukergrensesnitt med tydelig funksjonalitet og nok informasjon. Enhver bruker, også de uten spesielle IT kunnskaper, skal kunne takle systemet Agresso Employee. Vi begynte med et enkelt design som vi etter hvert utviklet. Under utviklingen fikk vi også jevnlig besøk fra oppdragsgiver og han virket veldig fornøyd med utseendet. Tilbakemeldingene gjorde oss tilfreds på at vi var på rett spor. Kravspesifikasjonen beskriver all påkrevd funksjonalitet til systemet vi har utviklet. Derfor har implementeringen foregått med kravspesifikasjonen som grunnlag. Den viktigste funksjonen var muligheten for å kunne opprette bruker i både CORP og Agresso domenet. Denne fikk høyeste prioritet. Vi har implementert slik at den viktigste funksjonaliteten ble utviklet først, testet og ferdigstilt. Dette gjorde at vi hadde kontroll på at vi har prioritert det som er viktigst av funksjoner. Mindre sentrale funksjoner kom i andre rekke. Dette for å sikre oss at om vi fikk for lite tid mot slutten, var i hvertfall det viktigste gjort. Heldigvis rakk vi fint å oppfylle alle krav. Både de funksjonelle og de ikke funksjonelle. Kravspesifikasjonen har fungert som en godt veiledningsdokument under hele utviklingen. 2.5 Kravspesifikasjonen og det ferdige produktet Kravspesifikasjonen beskrev alle krav og betingelser til systemet vi skulle utvikle og fungerte som en rettesnor for oss gjennom hele utviklingen av systemet. Kravspesifikasjonen har også hjulpet oss å holde oss innenfor grenseland når det gjelder utviklingen. Implementering og design skulle begge være i samsvar med kravspesifikasjonen. Agresso Employee 11

12 I det ferdige produktet vårt er alle kravene i kravspesifikasjonen oppfylt. I tillegg har vi også enkelte steder, der vi har følt behov, tilføyd små detaljer til fordel for systemet. For eksempel har vi brukt Windows Autentifisering for at brukeren skal slippe å logge seg inn på Agresso Employee fra egen maskin. Men kravspesifikasjonen kunne vi til enhver tid kontrollere hva som var gjort og det gjenværende. 12 Agresso Employee

13 3. Planlegging og metode Å planlegge riktig ved hjelp av riktige metoder er viktig for et bra prosjektresultat. Vi brukte i vårt prosjekt god tid på planleggingsfasen og fikk gjentatte tilbakemeldinger og godkjenninger av den før vi sa oss ferdige. Planlegging og metode fasen gir en oversikt over hvordan vi gikk frem for å planlegge prosjektet vårt, hvilke styringsdokumenter vi brukte og metoder. 3.1 Prosjektgruppen Vi er 4 gruppemedlemmer som har jobbet sammen på så å si alle prosjektene i løpet av den treårige utdanningen vår. Vi kjenner hverandre godt og kommer godt overens. Det var helt selvsagt at vi kom til å jobbe sammen på dette hovedprosjektet også. Hvert enkelt gruppemedlem hadde gode kunnskaper på forskjellige områder, noe som gjorde at vi til sammen kunne dekke alle kravene som trengtes for et godt resultat. 3.2 Webside og prosjektdagbok Gruppen har helt fra begynnelsen av prosjektstadiet opprettet en webside der ferdige dokumenter har blitt publisert. Dette har gitt oss en oversikt over hva som er ferdig av dokumenter og gjort dokumentene tilgjengelige overalt med tilgang til internett. I tillegg har vi for hvert sammentreff skrevet prosjektdagbok. Her har vi ført alt vi gjort, hva vi mangler, problemer vi har hatt og løsningen. Dagboken gir en god oversikt over når de forskjellige dokumentene ble ferdige, hvor vi ligger an i forhold til fremdriftsplanen, hvor effektive vi bør være i fremtiden og hva som er gjort og skal gjøres. 3.3 Bærbar og Fellesområde Alle medlemmene i prosjektgruppa fikk disponere en bærbar programmerer PC, det vil si en bærbar med relativt gode spesifikasjoner, gjennom hele prosjektperioden. Vi fikk også tilgang til et fellesområde på serveren hos oppdragsgiveren som fungerte som et fildelingssystem for oss. Her lastet vi opp all arbeidet vårt og alle hadde hele tiden tilgang til alt av dokumenter som lå der. Dette gjorde av vi slapp å bruke Messenger eller e-post til å sende hverandre dokumenter. Fellesområdet var mye mer effektivt å bruke. Vi brukte dette området særlig mye i perioden før noe skulle publiseres på websiden. Fellesområdet ble også brukt til å legge ut dokumenter som vår interne veileder ved Agresso R&D AS, Rune Spersøy, kunne gå igjennom og gi tilbake melding på. Fellesområdet ble tatt backup av hver kveld, noe som gjorde det trygt å bruke. Skulle vi likevel være så uheldige å miste arbeidet gjort i løpet av den ene dagen kunne det ikke være mye. 3.4 Arbeidsmetoden Arbeidsmetoden beskriver metoder vi har benyttet oss av i utviklingen av prosjektet. Og ha definert en slik metode har gjort det enklere for oss å følge et mønster gjennom hele prosjektperioden. Agresso Employee 13

14 3.4.1 Prosessmodellen RUP Rational Unified Process (RUP) er en metode som beskriver hvordan man kan jobbe med utvikling av prosjekter. Modellen kan brukes på mange forskjellige måter. Det er viktig å velge de elementene fra denne utviklingsmetoden som vi synes er nyttig for å komme frem til raskest mulig løsning. For å være effektiv velger man hvordan man bruker utviklingsmetoden. Verktøyet veileder deg ikke gjennom utviklingsmetoden, men gir deg heller friheten til å velge det som passer deg best. RUP er kort og godt en metode for å utvikle systemer. Nøkkelkonseptene i prosessen er utvikling, analyse og design ved hjelp av modellering i UML. RUP har flere iterasjonen når det gjelder forskjellige faser i prosjektet. Det fører til at det blir enklere for oss å forandre f. eks krav og design senere i prosjektet. I hvert prosjekt skal en løse en spesiell problemstilling, da bruker man bare deler av denne RUP- modellen. RUP- modellen definerer følgende fire prosjektfaser i prosjektoppgaven vår: Forberedelsesfasen, fasen der vi kommer med ideer (inception): Gruppen opprettet en prosjektdagbok tidlig i denne fasen slik at vi har oversikt over fremgangen, utførte og gjenværende oppgaver. Vi begynte denne fasen med forprosjektrapporten som ga oss en kort og overordnet oversikt over hva prosjektet dreide seg om, krav og eventuelle løsninger vi kan bruke. Vi fikk også laget flere utkast av arbeidsplanen og fremdriftsplanen. Vi endret flere ganger på disse dokumentene slik at de ble mer realistiske og samsvarte med prosessmodellen vår RUP. På den måten fikk vi god oversikt over hvilke punkter som hører til de forskjellige fasene, når vi bør utføre dem og frister. Vi utviklet også første utkast av kravspesifikasjonen. 14 Agresso Employee

15 Innenfor denne fasen kommer også læringsfasen som omfatter tilegning av kunnskaper i ASP.NET, C#, Active Directory osv. Selv om læringen går over i Utdypningsfasen og så over i Konstruksjonsfasen, var det i denne forberedelsesfasen den var viktigst. Dette fordi vi måtte danne oss et grunnlag for det videre arbeidet. Utdypningsfasen (elaboration): Denne fasen omfattet en del endringer i kravspesifikasjonen. Vi skrev flere utkast av den og med tilbakemeldinger av både intern og ekstern veileder, kom vi tilslutt frem til et vi kunne bruke som siste og endelige utkast. Deretter begynte vi med design av databasen (ERdiagram) og brukergrensesnitt og UML modellering(use Case modell og beskrivelser, klasse og sekvens diagram). Videre kom vi i gang med dokumentasjonen. Konstruksjonsfasen eller implementeringsfasen (construction): Under denne fasen implementerte vi systemet ved å bruke programmeringsspråkene ASP.NET, C#, HTML, CSS. Vi så også på videre utviklingsmuligheter av UML modellering, funksjonaliteten, brukervennligheten, dokumentasjonen og på testing av produktet. Avslutningsfasen, bl.a. bruker opplæring (transition): Testing og feilretting kommer under denne fasen. Her fikk vi testet produktet vi har kommet frem til og rettet opp feil. Vi skrev mer om produktet vi hadde kommet frem til, produktdokumentasjon. Brukermanual ble laget. Mulighet for utvikling ble også beskrevet i denne fasen. Om hva vi har gjort, hva vi har lært, egen vurdering av arbeidet. Fordel med RUP - modellen: Iterasjoner Det fine med denne modellen er muligheten vi har til å iterere. Dette innebærer at man kan starte med å utvikle enkle løsninger, for så å gå tilbake når det er behov for det å implementere flere detaljer, eller finpusse på løsningene. Mellom forberedelses og utdypningsfasen har vi hoppet frem og tilbake flere ganger, blant annet for å oppdatere fremdriftsplan og arbeidsplan. Agresso Employee 15

16 3.4.2 Prosessmetoder Arbeidsprosessen som ble brukt i selve utviklingsarbeidet: Forprosjektet og fremdriftsplan: Gruppen lagde et forprosjekt som innholdt presentasjon av oppgaven og bedriften, mål og rammebetingelser, løsninger. Det ble også laget en risikoanalyse, arbeidsplan og fremdriftsplan utenom forprosjektet. Kravspesifikasjonen: I denne arbeidsprosessen har vi i samarbeid med Agresso R&D kommet frem til systemkrav og funksjonskrav. Dette krevde nøye utskilling av data og evne til å kunne vurdere og velge ut viktigst data. Design: Her kom vi frem til en teknisk løsning for systemet ved hjelp av tabeller og diagrammer. Her inngår workflow diagrammer, Use Case diagram, klassediagrammer og sekvensdiagrammer. Disse skulle gi oss et visuelt bilde av hvordan systemet vil henge sammen. Implementering: Programmere i ASP.NET, HTML, C#, CSS og VB skript. Test: Testing både internt, av oss selv, og eksternt ble her foretatt for å kvalitetssikre produktet før innlevering. Utviklingsmuligheter: Her har vi sett på videreutviklingsmuligheter av produktet som er utviklet. Disse beskrivelsene henvender seg til eventuelle videre utviklere som ønsker å få oversikt. Konfigurasjonsstyring: Dokumentasjon av konfigurasjonen. Konfigurasjonsstyring er disiplin for å håndtere endringer og ulike versjoner av komponenter. All produkt av systemutviklingsprosessen kan inngå her. Som for eksempel kravspesifikasjon, designdokument, programmer (kildekode /kjørbare komponenter), test data og system manualer. Prosjektstyring: Dokumentasjon av prosjektrapporten samt. Fremdriftsplanen, tidsestimering og Risikoplanlegging. Generelt diverse dokumenter som inngår i planleggingen av prosjektet og styringen av det. Utviklingsmiljø: Hva vi bruker til å utvikle; Windows Vista, ASP.NET, C#, Active Directory, MS Office og MS project. RUP modellens fordeler: Vi i gruppen har valgt å bruke RUP - modellen blant annet fordi modellen har sine fordeler. Ved bruk av RUP - modellen: Reduseres risiko, alle vet hele tiden hvem som gjør hva, hvordan det gjøres og når det skal gjøres. 16 Agresso Employee

17 Gir prosjektlederen bedre kontroll over planer og leveranser. Med bedre kontroll vet prosjektgruppen hele tiden hvordan de ligger an i forhold til deadlines og hvor effektive dem må være fremover. Forbedrer kommunikasjonen i prosjekt- teamet. Beskrives maler og mønstre som kan følges under hele prosessen noe som gjør at startfasen i hver del prosjekt blir enklere å komme inn i. Får vi oss god oversikt over fremdriften i prosjektet Vet vi hvordan vi kan oppnå prosjektmål basert på tid og kunnskaper. Kan vi dele oppgavene i mindre og passende enheter for alle i gruppen. En av de unike egenskapene med RUP modellen er at all arbeidet mer eller mindre strekker seg over alle fasene. For eksempel starter implementerings delen allerede i innledningsfasen, men tilstedeværelsen av denne blir selvfølgelig høyere frem til fasen faktisk begynner. Tilstedeværelsen blir aldri helt borte, noe som gjør RUP tilpasningsdyktig i forhold til forandring i noen av de tidligere fasene. Agresso Employee 17

18 3.5 Prosjektstyring Under planleggingen av prosjektet har vi utviklet diverse dokumenter som skulle kontrollere styringen under prosjektet vårt. Denne delen tar for seg de styringsdokumenter vi har inkludert i prosjektet Arbeidsplan Gruppen opprettet en arbeidsplan for å forenkle oversikten over punkter som skal utføres i løpet av perioden og frister for disse. Detaljert arbeidsplan ser du under: Aktivitet Beskrivelse Deadline Oppstart Prosjektdagbok En logg som viser fremgangen i prosjektet. Fortløpende Opprettelse av webside Statusrapport Prosjektskisse Opprette hjemmeside for hovedprosjektet. Her vil de kommende dokumentene lastes opp fortløpende. Beskrivelse av gruppen, status per dato og evt. ønskede prosjekter. En overordnet oversikt over prosjektet og arbeidsgiver. Fortløpende Samarbeidsavtale En avtale mellom arbeidsgiver og skolen Forprosjektrapport Arbeidsplan Fremdriftsplan Læringsfase Visual Studio 2005, C# og ASP.NET Kravspesifikasjon En mer beskrivende rapport som omfatter dagens situasjon, mål, rammebetingelser, evt. løsninger og teknologier vi kommer til å benytte oss av. En beskrivende oversikt over alle punktene/arbeidsoppgaver som skal utføres i prosjektet. Oversikt over hvor mye tid som skal settes av til de forskjellige arbeidsoppgavene som skal utføres og milepæler/frister. Gruppen skal tilegne seg kunnskaper om nødvendig teknologi som skal benyttes under implementering/ utviklingen av systemet eller andre deler i prosjektet Agresso Employee

19 Innsamling av data Vurdering av stoff Utvikling av kravspesifikasjon Implementasjon Design(UseCase, diagrammer) Møter med arbeidsgiver for å kartlegge behov, krav og ønsker. All innsamlet data blir vurdert, begrenset og vi danner oss et ca bilde av oppbyggingen av systemet og prosjektet. Resultatet av innsamlingen av data/informasjon og den ferdige beskrivelsen av kravet til systemet. Modeller som skal gi oversikt over design og hvordan ting er relatert til hverandre. Viser hva, men ikke hvordan, programmet skal gjøre HTML/ CSS- GUI Programmere kode for brukergrensesnittet Databasen Oppsett av database C#/ ASP.NET (krav/ System) Integrasjon med andre systemer Koding Sette sammen hele systemet Testing Intern testing Ekstern testing (med arbeidsgiver) Feilretting/finpussing Dokumentasjon Prosessrapport En testplan blir laget for å evaluere systemets funksjoner Testing av systemet av arbeidsgiver og evt. andre eksterne personer Testrapport, eventuelle feil blir rettet. Finpussing og oversiktlig kommentering av kode. Rapport som blir utviklet gjennom hele prosjektprosessen Produktdokumentasjon Rapport om virkemåten til systemet Brukermanual Avslutningsfasen Et dokument som fungerer veiledende for arbeidsgiver og brukere Agresso Employee 19

20 Avslutning Forbrede presentasjon Legge sammen alle dokumentene, sammenfatning, klargjøres til innlevering Sette opp en fremførings/presentasjonsplan med evt. powerpoint og gjennomgåelse Presentasjon Presentasjon for sensor Fremdriftsplan/Gantt-diagram Gruppen utviklet også et Gantt- diagram ut ifra arbeidsplanen som skulle hjelpe oss med å holde oversikt over milepæler og frister. Her hadde vi oversikt over når en oppgave begynte, hvor mange dager den varer og når den skal avsluttes. Diagrammet viste oss også hvilke faser vi var i til enhver tid, hvilke andre faser som foregår samtidig og hvor lange periodene var, også i forhold til hverandre. Siste utkast av Gantt-diagrammet ser dere under: Tidsestimering Det finnes flere forskjellige metoder/kalkyler for å beregne tidsforbruk for et prosjekt. Vi har valgt å bruke en metode som vi definerer selv. Dette for at den metoden/modellen vi lager skal være best mulig tilpasset vårt prosjekt og hvordan vi kommer til å utnytte tiden og hva vi kommer til å prioritere. Vi tok utgangspunkt i prosessmodellen RUP. Dette fordi RUP 20 Agresso Employee

21 modellen definerer de 4 forskjellige fasene i prosjektet vårt, og ved å ta utgangspunkt i denne modellen kunne vi estimere hvor mye tid vi bør bruke på de forkskjellige fasene vi har. Estimeringskalkylen vår: TIDSESTIMERINGS KALKYLE TIDSESTIMERING Antall timer pr dag 6 * Antall dager i uken 2 * Antall prosjekt uker 23 - Uker brukt til annet (ferier, eksamen, obliger e.l.) 3 - "Siste innspurt" (antall uker) 5 = Totalt antall timer pr person 180 * Antall gruppemedlemmer 4 = Totalt antall gruppe timer 720 Antall timer - Siste innspurt 7 * Antall dager - Siste innspurt 3 * Antall uker - Siste innspurt 5 * Totalt timer - Siste innspurt 105 * Antall gruppemedlemmer 4 = Totalt antall gruppetimer med siste innspurt 420 = Totalt prosjekt timer 1240 Kommentarer til kalkylen Antall timer vi kommer til å bruke på prosjektet er regnet ved å multiplisere antall timer vi kommer til å bruke pr dag med antall dager i uken vi kommer til å bruke på prosjektet og antall uker. Vi velger å trekke fra noen uker som vi har brukt på andre ting enn prosjektet, bl.a. at noen har vært bortreist, eksamens lesing, obligatoriske oppgaver i andre fag e.l. Siste innspurt er de siste ukene før innlevering. Vi regner med at vi i den perioden kommer til å ta i et ekstra tak, møtes noen ekstra ganger og jobbe mer enn vanlig. Vi har derfor trukket fra disse timene først for så å kalkulere dem hver for seg og summere inn i totalen. Det totale antallet timer i løpet av prosjektperioden estimerer vi til ca 1240 timer fordelt på de fire fasene i RUP modell: Forberedelsesfasen, utdypningsfasen, konstruksjonsfasen og avslutningsfasen. Hvor mange timer som er fordelt på hver av fasene kan du se under i tidsforbruk estimeringen. Vi regner med at det vil bli noen endringer i tidsestimeringen underveis. Agresso Employee 21

22 Estimert tidsforbruk Det estimerte tidsforbruket gir en oversikt over hvor mye tid vi har tenkt skal gå til hver av fasene i prosjektet. Vi har tatt for oss de fire fasene i RUP modellen som inngår i prosjektet vårt. Oppgave BC ML WC Forberedelsesfasen Utdypningsfasen Konstruksjonsfasen Avsutningsfasen SUM BC = Best case ML= Most likely WC= Worst case Risikoplanlegging Risikoplanlegging er arbeidet med å klargjøre risikohåndteringer i prosjektet. Risikoer i prosjektet inkluderer både trusler og sårbarhet med sannsynlighet for at noe uforventet skjer. Sårbarhet er der hvor et angrep har størst mulighet til å lykkes Risikoanalyse Risikoanalysen skal hjelpe oss å ha kontroll på løsninger på problemer vi ikke forventer under prosjekt perioden, men som vi vet kan dukke opp. Den skal også gjøre oss bevisst på at det finnes en del risiko knyttet til et slikt prosjekt. Risiko Sann synli ghet Alvo rligh et For liten tid 0,40 0,75 Tap av fokus 0,30 0,50 Tap av kritisk data 0,10 0,85 Forberedelse Sette opp en fremdriftsplan som er realistisk og følge denne til enhver tid, heller å bruke noe mer tid i begynnelsen enn å sitte igjen med mye på slutten. Ha en jevn flyt i fremgangen. Viktig med god planlegging! Passe på at alle gruppemedlemmene får oppgaver de er tilfreds med, backe hverandre ved tyngre arbeidsoppgaver slik at motivasjon opprettholdes. Lagre filer også andre steder enn kun PC, laste opp dokumenter på evt. e-post. Lagre på fellesområde gitt av arbeidsgiver. Dette området blir tatt backup av hver kveld. Tiltak Endre fremdriftsplanen, melde fra til veileder, begrense omfanget slik at viktige punkter ikke faller bort. Motivere hverandre og hjelpe hverandre hvis en ligger litt bak med arbeidsoppgave. Oppmuntring. Gjøre noe annet i felleskap enn bare å jobbe med prosjekt for å få litt av kobling. Hente igjen fra fellesområde/e-post/ backup harddisken. Redusere omfanget på oppgaven. Eventuelt reproduksjon av dokument. 22 Agresso Employee

23 Endring av kravspesifikasjon 0,80 0,10 Få oversikt over viktige krav allerede i startfasen, god kommunikasjon med arbeidsgiver, Fortløpende møter og tilbakemeldinger fra arbeidsgiver. Gruppemøte, omorganisering av oppgaver. Prosjektet er underestimert 0,10 0,70 Forstudie, Nøye kartlegging av behov. begynne tidligst mulig, jevn arbeidsinnsats. Arbeidsoppgavene må omorganiseres, overtid. Tap av mindre kritisk data 0,10 0,30 Lagre filer også andre steder enn kun PC, laste opp dokumenter på evt. e-post. Lagre på fellesområde gitt av arbeidsgiver. Dette området blir tatt backup av hver kveld. Hente igjen fra fellesområde/ e-post / backup harddisken. Ekskludere data fra prosjektet. Eventuell å reprodusere om det lar seg gjøre raskt. Sykdom 0,15 0,10 Gruppemedlemmene er pliktige til å si fra tidligst mulig slik at resten av gruppa kan finne en evt. løsning. God kommunikasjon, Jobbe hjemmefra om mulig, utsette intern frist, delansvarlig på området tar over/ jobber videre på oppgaven, evt. å begrense eller kutte ut deler av prosjekt. Opprettholde kontakten med den syke og fortelle hva som skjer slik at alle er med på prosjektet. Konflikter 0,05 0,20 Få med alle under planlegging, møter og utvikling slik at alle gruppemedlemmenes synspunkter er med fra starten av og ingen uenigheter oppstår midtveis/senere. Konflikter kan skje selv blant gode venner. Ikke alle er enige i alt og hvem som skal gjøre hva også videre. Det viktige da er å ta det opp ved å diskutere og gjøre ting klart til man kommer til en enighet. Konflikter må løses felles i gruppemøte. Gruppe medlem slutter 0,01 0,80 God kommunikasjon som bekrefter og gruppemedlemmene trives. Plikt om å melde fra om flytting tidlig i fasen. Omorganisere arbeidsoppgaver, gruppemøte både internt og med veileder. Evt. kutte ned på prosjektets omfang. Agresso Employee 23

24 Tabellen under gir risikofordelingen for prosjektet vårt: Forklaring: De forskjellige sonene er fargemerket avhengig av hvor kritisk sonen er. Punktet har 40 % sannsynlighet for å inntreffe og en alvorlighet på 75 % om den skulle inntreffe. Det betyr at om vi skulle få for liten tid så blir situasjonen kritisk. Fargesonene gjør det enklere å få en oversikt over punkter vi bør se opp for å komme borti Re-risikoanalyse Erfaringer frem til cirka midtveis i prosjektet tillater oss å endre litt på risikoanalysen vi lagde i begynnelsen av prosjektet. Dette fordi vi merker oss at enkelte punktet har høyere eller lavere sannsynlighet enn andre. Risiko Sanns ynlig het Alvor lighet For liten tid 0,35 0,75 Forberedelse Sette opp en fremdriftsplan som er realistisk og følge denne til enhver tid, heller å bruke noe mer tid i begynnelsen enn å sitte igjen med mye på slutten. Ha en jevn flyt i fremgangen. Viktig med god planlegging! Tiltak Endre fremdriftsplanen, melde fra til veileder, begrense omfanget slik at viktige punkter ikke faller bort. Tap av fokus 0,20 0,50 Passe på at alle gruppemedlemmene får oppgaver de er tilfreds med, backe hverandre ved tyngre arbeidsoppgaver slik at motivasjon opprettholdes. Motivere hverandre og hjelpe hverandre hvis en ligger litt bak med arbeidsoppgave. Oppmuntring. Gjøre noe annet i felleskap enn bare å jobbe med 24 Agresso Employee

25 prosjekt for å få litt av kobling. Tap av kritisk data 0,10 0,85 Endring av kravspesifikasjon 0,80 0,10 Prosjektet er underestimert 0,10 0,70 Tap av mindre kritisk data 0,10 0,30 Sykdom 0,25 0,10 Konflikter 0,05 0,20 Lagre filer også andre steder enn kun PC, laste opp dokumenter på evt. mail. Lagre på fellesområde gitt av arbeidsgiver. Dette området blir tatt backup av hver kveld. Få oversikt over viktige krav allerede i startfasen, god kommunikasjon med arbeidsgiver, Fortløpende møter og tilbakemeldinger fra arbeidsgiver. Forstudie, Nøye kartlegging av behov. begynne tidligst mulig, jevn arbeidsinnsats. Lagre filer også andre steder enn kun PC, laste opp dokumenter på evt. mail. Lagre på fellesområde gitt av arbeidsgiver. Dette området blir tatt backup av hver kveld. Gruppemedlemmene er pliktige til å si fra tidligst mulig slik at resten av gruppa kan finne en evt. løsning. God kommunikasjon, Få med alle under planlegging, møter og utvikling slik at alle gruppemedlemmenes synspunkter er med fra starten av og ingen uenigheter oppstår midtveis/senere. Hente igjen fra fellesområde/mail/ backup harddisken. Redusere omfanget på oppgaven. Eventuelt reproduksjon av dokument. Gruppemøte, Arbeidsoppgave må omorganiseres, overtid Hente igjen fra fellesområde/mail/ backup harddisken. Ekskludere data fra prosjektet. Eventuell å reprodusere om det lar seg gjøre raskt. Jobbe hjemmefra om mulig, utsette intern frist, delansvarlig på området tar over/ jobber videre på oppgaven, evt. å begrense eller kutte ut deler av prosjekt. Opprettholde kontakten med den syke og fortelle hva som skjer slik at alle er med på prosjektet. Konflikter kan skje selv blant gode venner. Ikke alle er enige i alt og hvem som skal gjøre hva også videre. Det viktige da er å ta det opp ved å diskutere og gjøre ting klart til man kommer til en enighet. Konflikter må løses felles i gruppemøte. Gruppemedlem slutter 0,01 0,80 God kommunikasjon som bekrefter og gruppemedlemmene trives. Plikt om å melde fra om flytting tidlig i fasen. Omorganisere arbeidsoppgaver, gruppemøte både internt og med veileder. Evt. kutte ned på prosjektets omfang. Agresso Employee 25

26 Endringer i risikoanalysen. For liten tid: Fremdriftsplanen har hjulpet oss med å holde frister og ligge bra an i forhold til tiden vi har på oss. Vi setter ned sannsynligheten for risikoen For liten tid., men ikke mer enn 5 %. Dette fordi vi ikke bør se bort fra at vi fortsatt kan få for liten tid like før innleveringsfrist pga uventede oppgaver som dukker opp. Sykdom: Gruppen hadde flere meldinger om sykdom enn forventet erfaringsmessig og estimert. Flytting, forkjølelser, feber og skader er alle faktorer regnet under punktet Sykdom. Midtveis i prosjektet setter vi derfor opp sannsynligheten for at sykdom i gruppen. Alvorligheten er akkurat det samme siden tiltaket vårt sørger for at en annen tar seg av oppgaven, den blir gjort hjemme fra eller til enste gang. Det har ikke vært noen alvorlige tilfeller av sykdom hittil. Tap av fokus: Gruppen visste på forhånd at vi satte oss inn i et prosjekt som krevde tilegning av ny kunnskap innenfor teknologi. Vi satte derfor høy sannsynligheten for tap av fokus. Men få dager i uka å jobbe på (fast oppmøte 2 ganger i uken; mandag og onsdag) ga effektive arbeidsdager med mye utbytte og minimum sannsynlighet for tap av fokus. Stort nok mellomrommet mellom de dagene vi møttes på gav oss muligheten til å drive med andre ting også i tillegg til prosjektet. Dette var medvirkende faktorer til at vi jobbet bra og konsentrert selv om vi likevel falt ut neon dager. Vi har derfor satt ned sannsynligheten for Tap av fokus. 3.6 Arbeidsverktøy og utviklingsteknologi Når det kommer til arbeidsverktøy, stod vi egentlig ganske fritt til å velge hva vi skulle bruke avhengig av hvilket dokument som skulle lages. Selve utviklingsteknologien vi har brukt har i første rekke vært et ønske fra oppdragsgiver. Arbeidsverktøy Microsoft Office Word 2007 All dokumentasjon og rapporter vi har laget i hele prosjektperioden, er blitt skrevet i tekstbehandlingsprogrammet Word. Dette er et effektivt verktøy med masse muligheter for oppsett, redigering og sammensetting av dokumenter. Microsoft Office Project 2003 Kun brukt for å utvikle Gantt-diagrammet/fremdriftsplanen som var nødvendig for å holde styr på frister, milepæler og fremdrift. Brukervennlig, men med masse avanserte funksjoner for oppsett av en plan. Vi har gjort planen vår ganske enkel. 26 Agresso Employee

27 Microsoft Office Excel 2007 Ble brukt for å generere diagrammet vi har brukt i risikoanalysen og oppsett av tidsestimeringskalkyle. Masse innebygde funksjoner som sparer oss for manuell regning. Paint Ble brukt til enkle bilderedigeringer vi trengte i prosjektet. Notepad Til notater og kladd for å kunne gjøre senere redigering enklere. Microsoft Office Visio for Enterprise Architects Dette verktøyet ble brukt for å utvikle Use Case modeller, klassediagram og sekvensdiagram. Visual Studio 2005 Dette arbeidsverktøyet ble brukt for utviklingen av selve systemet vi skulle lage i dette prosjektet. Utviklingsteknologi HTML For å lage brukergrensesnitt CSS Cascading Style Sheets, som er stilark for HTML. CSS gir mer oversikt over layouten på websiden og lar deg kontrollere ganske mye fra kun denne siden. ASP.NET ASP.NET inneholder mange ferdige kontroller og funksjoner som er mye brukt på en webside. Vi har brukt denne teknologien til utviklingen av systemet. C# Programmeringsspråk som ble brukt sammen med ASP.NET. MySql Brukt for utvikling og kontakt med databasen. 3.7 Læring av ny teknologi En av grunnene til at vi ønsket oss dette prosjektet var at oppdragsgiver ønsket det utviklet i ASP.NET og C #. Prosjektet ga oss også muligheten til å bli bedre kjent med forskjellige type server oppsett, Active directory og ny teknologi i form av C# og asp.net. Kontaktpersonen vår, Rune Spersøy, skaffet oss nødvendig faglitteratur, programvare og test servere i form av en domenekontroller og en exchange server som vi kunne utforske og kjøre testinger på. Agresso Employee 27

28 Alle på gruppen meldte seg opp i faget Webprogrammering i.net på Høgskolen i Oslo. Dette faget tok for seg asp.net og C# og ga oss mye av kunnskapen vi trengte for fullføre prosjektet. Det tok lit tid før vi kom i gang med selve programmeringsdelen i prosjektet siden vi måtte lære oss et nytt programmeringsspråk. De obligatoriske oppgavene i faget Webprogrammering i.net var relaterte til programmeringa vi skulle gjøre i hovedprosjektet. 3.8 Møter med veileder ved IU Vi ble tildelt en veileder fra IU som vi holdt kontakt med under hele prosjektperioden. Veilederen vår het Demissie Aredo som vi også har hatt i fagene relasjonsdatabaser og Systemutvikling ved IU. Kontakten foregikk hovedsakelig via e-poster frem og tilbake med meldinger om status. En gang innimellom hadde vi også møter med vår veileder. Vi ble enige om et passende tidspunkt over telefon eller e-post. Møtene ble holdt etter behov på både IU og Agresso. På disse møtene gikk vi gjennom dokumenter vi var ferdige med og fikk tilbakemeldinger og tips av veilederen. Dokumentene ble gjerne sendt til veileder på forhånd via e-post slik at han kunne lese gjennom og sette seg inn i dem. Vi planla også fremdriften sammen med veilederen slik at han fikk en oversikt over det neste vi skulle gjøre. Møtene har fungert som gode veiledningstimer siden vi fikk ris, ros og masse tips til videre arbeid. Aredo ble dessverre sykemeldt de siste 2 ukene av hovedprosjektet. Vi fikk derfor en midlertidig veileder frem til Aredo kommer tilbake. Vår veileder ble da Thor E. Hasle som gruppen har hatt i faget Prosjektledelse på IU. Hasle har hjulpet oss med den siste veiledningen av prosjektet ved å gå gjennom alle delene og gi oss en endelig vurdering av alt. Veilederen var veldig fornøyd med alle diagrammer og oppsettet av sluttdokumentasjonen. Han beskrev konkrete ting i dokumentene som vi burde vurdere å endre. Denne endelige veiledingen var utrolig nyttig og gjorde at vi fikk et godt og solid sluttresultat. 28 Agresso Employee

29 4. Prosjektorganisering Ethvert prosjekt trenger organisering for å kunne ha kontroll på hvem som står ansvarlig innenfor hvert område. Gruppen har derfor planlagt den interne organiseringen og laget et prosjektansvarskart. 4.1 Intern organisering av gruppa Gruppen har fokusert på god kommunikasjon mellom de forskjellige fasene i prosjektet. Vi møttes to ganger i uken hos Agresso fra klokken 9 til ca klokken 16. Disse timene ble brukt til å jobbe med prosjektet, veiledning oss i mellom og også fra kontaktperson. All arbeid som ble gjort, ble lagt i fellesmappen vi har fikk utdelt av vår kontaktperson, Rune Spersøy hos Agresso R&D AS. Dette for at vi hele tiden skulle ha oversikt over dokumenter som vi jobbet med eller varer ferdige med. Og også i tilfelle en på gruppen trenger informasjon fra noe en annen har gjort. All ferdig dokumentasjon ble i tillegg lastet opp på hjemmesiden til prosjektet lik at vi ved leveringsfrister bare kunne linke til hjemmesiden. Det gjorde også dokumentene tilgjengelige for oss fra overalt hvor vi måtte finne oss. 4.2 Prosjektansvarskart For å ha en oversikt over hovedoppgavene hvert av gruppemedlemmene har, laget gruppen et prosjektansvarskart/oversikt som viser hoved- og delansvar. Oppgave Hovedansvarlig Delansvarlig Prosjektleder Martin Næss Sahdia Moghal Web og utviklingsansvarlig Anders Ruud Christian Årving Prosessdokumentasjon Sahdia Moghal Alle Teknisk design Christian Årving Anders Ruud Kvalitetssikring Martin Næss Alle Risikoanalyse Sahdia Moghal Christian Årving Back- up Alle Alle Testing Martin Næss Alle Agresso Employee 29

30 5. Utviklingsprosessen Utviklingsprosessen har vært en prosess som i seg selv har gått veldig problemfritt siden det ble brukt mye tid på planleggingsfasen. Utviklingen av diverse modeller og diagrammer har spilt en stor rolle for selve implementeringen. Dette avsnittet beskriver modellene vi har laget, hvordan vi har jobbet under utviklingsfasen og hvilke forbedringer som er gjort av systemet. 5.1 UML modellering Vi begynte utviklingsfasen med diverse UML modelleringer. Disse har hjulpet oss på vei med implementeringen. UML-modelleringen har gitt oss en detaljert oversikt over hvordan systemet skulle se ut og hvilke deler som skal implementeres Workflow diagrammer Under utviklingen av kravspesifikasjonen ble det laget workflow diagrammer for å presentere funksjoner og arbeidsflyt. Vi lagde en workflow både for dagens situasjon og en for hvordan arbeidsflyten blir når vi har implementert den nye løsningen. Dette for å se forskjellen i arbeidsflyt fra gammel til ny versjon. Gammel workflow: 30 Agresso Employee

31 Ny workflow: De røde strekene går til funksjoner som var planlagt men som vi ikke har fått implementert, Disse kan implementeres ved en senere anledning. Agresso Employee 31

32 5.1.2 Use Case diagram Use Case diagrammet viser hva systemet skal gjøre og for hvem. Under ser du Use Casen til Agresso Employee Use Case beskrivelser Use Case diagrammet over beskriver hva systemet gjør, men sier ingenting om hvordan. For å beskrive hendelsesflyten til Use Casene har vi skrevet Use Case beskrivelser til hvert Use Case ved hjelp av tekst slik at utenforstående lett kan forstå. Disse beskrivelsene forteller hvordan og når Use Caset starter og slutter, når Use Caset samarbeider med aktører, og hvilke objekter som utveksles. Hovedflyten og alternativ flyt er også beskrevet. 32 Agresso Employee

33 Use Case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Utvidet hendelsesflyt Avvikshåndtering Registrer Nyansatt Personal Personal skal registrere personalia på en nyansatt. Personal har data på nyansatt som er klare til å legges inn. De registrerte opplysningene personal har registrert blir lagt i databasen. 1. Personal legger inn personalia 2. Trykker registrer og bekrefter 3. Personalia blir lagret i systemet. 4. Databasen oppdateres med den nye ansatte. 1. Personal legger inn personalia 2. Trykker registrer a. Glemt å fylle ut felter b. Ikke fylt ut gyldig info 3. Personalia blir lagret i systemet a. Data kan ikke sendes til systemet 4. Systemet oppdateres 2a. Feilmelding med beskrivelse vises 2b. Feilmelding med beskrivelse vises 3a. Feilmelding med beskrivelse vises Relatert informasjon v Agresso Employee 33

34 Use Case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Utvidet hendelsesflyt Status for plassering av nyansatt i AgressoMap registreres Personal Personal skal registrere at nyansatt er tildelt en plass i Agresso map eller ikke. Den nyansatte er registrert i systemet. Status for at nyansatt er plasser geografisk settes til OK. 1. Personal huker av for om nyansatt er registrert i Agresso map. 1. Personal huker av for om nyansatt er registrert i Agresso map. Avvikshåndtering Relatert informasjon v Use Case Aktør Trigger Pre-betingelser Sjekk status Personal Bruker skal sjekke status på nyansatt. Nyansatt er opprettet i systemet. Post-betingelser Normal hendelsesflyt Utvidet hendelsesflyt Relatert informasjon 1. Bruker går inn for å sjekke status på nyansatt 2. Status sjekket 1. Bruker går inn for å sjekke status på nyansatt 2. Status sjekket Denne use casen viser kun status på nyansatt. Hva som har blitt gjort med nyansatt siden nyansatt ble opprettet. Det skal ikke gå an å gjøre endringer her. 34 Agresso Employee

35 Use Case Aktør Trigger Opprette nyansatt i Active Directory Personal Personal har registrert personalia på en nyansatt. Pre-betingelser Nyansatt er registrert i systemet. Post-betingelser Normal hendelsesflyt Utvidet hendelsesflyt Avvikshåndtering Nyansatt blir opprettet i Agresso og Corp. Mail konto blir opprettet i CORP-domene og koblet opp mot bruker i Agresso domenet. Brukernavn og passord blir generert og lagt i tabell. 1. Use caset Registrer personalia på Nyansatt er oppfylt. 2. Bruker blir opprettet i domenene. 1. Use caset Registrer personalia på Nyansatt er oppfylt. a. Use caset ikke oppfylt 2. Bruker blir opprettet i domenene. a. Bruker blir ikke opprettet i en eller begge domene. b. Bruker med samme navn eksisterer fra før 1a) Se avvikshåndering under use caset Registrer personalia på Nyansatt. 2a) Feilmelding med beskrivelse vises. 2b) Melding om at bruker eksisterer i AD fra før. Alternativer til brukernavn vises. Relatert informasjon Agresso Employee 35

36 Use Case Aktør Trigger Melder nyansatt inn i brukergrupper Avdelingsleder Avdelingsleder skal melde bruker inn i brukergrupper. Pre-betingelser 1. Use caset Registrer personalia på Nyansatt er oppfylt og bruker finnes i Active Directory. Post-betingelser 1. Nyansatt er meldt inn i de nødvendige brukergruppene. Normal hendelsesflyt Utvidet hendelsesflyt 1. Avdelingsleder velger fra en dropdown meny, hvilke brukergrupper nyansatt skal være medlem i. 2. Bruker blir meldt inn i gruppene. 3. Status oppdateres 1. Avdelingsleder velger fra en dropdown meny, hvilke brukergrupper nyansatt skal være medlem i. 2. Bruker blir meldt inn i gruppene. a. Bruker blir ikke meldt inn 3. Status oppdateres Avvikshåndtering 2a). Feilmelding med beskrivelse vises. Relatert informasjon 36 Agresso Employee

37 Use Case Aktør Trigger Bestille utstyr Avdelingsleder Avdelingsleder skal bestille utstyr til den nyansatte Pre-betingelser 1. Use caset Registrer personalia på Nyansatt er oppfylt og bruker finnes i Active Directory. Post-betingelser 1. Avdelingsleder skal ha bestilt nødvendig utstyr til den nyansatte (PC-pakke, skjerm, telefon o.l.) Normal hendelsesflyt 1. Ønsket utstyr blir valgt fra dropdown meny. 2. Bestillingen til blir sendt til IT-avdelingen 3. Status oppdateres Utvidet hendelsesflyt 1. Ønsket utstyr blir valgt i checkbokser. 2. Bestillingen til blir sendt til IT-avdelingen a. Feil ved sending 3. Status oppdateres Avvikshåndtering 2a) Feilmelding med beskrivelse vises Relatert informasjon Agresso Employee 37

38 Use Case Aktør Trigger Bestilling av telefon og abonnement Avdelingsleder Avdelingsleder skal bestille telefon og telefonabbonement til den nyansatte. Pre-betingelser 1. Use caset Registrer personalia på Nyansatt er oppfylt. Post-betingelser 1. Telefon og ønsket abonnement blir bestilt. Normal hendelsesflyt 1. Telefon og ønsket abonnement blir valgt 2. Mail blir sendt til Nordialog med beskrivelse av bestillingen 3. Status oppdateres Utvidet hendelsesflyt 1. Telefon og ønsket abonnement blir valgt 2. Mail blir sendt til Nordialog med beskrivelse av bestillingen a. Mail blir ikke sendt 3. Status oppdateres Avvikshåndtering 2a). Feilmelding med beskrivelse vises. Relatert informasjon 38 Agresso Employee

39 5.1.4 Klassediagram Gruppen har utviklet flere klassediagram som viser sammenhengen mellom de forskjellige klassene som brukes internt i applikasjonen. For detaljert beskrivelse av hver av klassene, se Produktdokumentasjonen. Diagram 1. De forskjellige lagene og deres avhengighet. Diagram 2. Modellaget med assosiasjoner. Agresso Employee 39

40 Diagram 3. GUI. Diagram 1. Modellaget med arv. 40 Agresso Employee

41 Diagram 5. Oversikt over BLL-klasser og deres forhold til DAL- og GUI-laget. Diagram 2. DAL og forholdet til GenericDAL og BLL. Agresso Employee 41

42 5.1.5 Sekvensdiagrammer Gruppen har utviklet tre sentrale sekvensdiagrammer som hver viser hendelsesflyten i den spesifikke Use Casen. For detaljert beskrivelse av sekvensenes forutsetninger og forløp, se punkt 13 i Produktdokumentasjonen Registrer nyansatt Opprett nyansatt i Active Directory 42 Agresso Employee

43 Send e-post til resepsjon 5.2 Design av brukergrensesnitt Design av brukergrensesnittet har vært den viktigste delen når det gjaldt utviklingen av webapplikasjonen. Et godt brukergrensesnitt handler ikke om bare om et fancy design og grafikk. Disse elementene kan faktisk virke i mot deres hensikt. Brukerne som vil benytte seg av applikasjonen vil ha ulik kompetanse innenfor data og vil tenke på ulike måter ut ifra deres erfaringer. Det viktigste elementet i brukerkonteksten var at alle tenkelige brukere av webapplikasjonen oppfattet siden som enkel å anvende og sette seg inn i, med andre ord brukervennlig, enkel og oversiktlig. Vi dannet oss et par viktige designmål for nettstedet som vi skulle jobbe opp imot. Designmålene var blant annet: Brukervennlig design/oppsett Konsistenthet Effektivitet Resultatet ble derfor et brukergrensesnitt basert på faner slik at det blir enkelt for brukeren å bla seg til riktig side. Kun nødvendig informasjon er tilgjengelig mens brukeren bruker applikasjonen. Dette sikrer brukervennlighet. Logoen og fanene er fast plassert på toppen gjennom hele navigeringen og innholdsområdet i midten. Med navigasjonsmenyen tilgjengelig uansett hvor på webapplikasjonen du befinner deg, blir det mye mer effektivt å bruke den. Agresso Employee 43

44 Figur: Prototype av brukergrensesnittet Disse tre områdene gjentar seg på alle webapplikasjonens sider slik at brukerne vil føle et samsvar mellom det han/hun ser. Dette gjør at brukergrensesnittet er konsistent, ettersom samme type meny og knapper forblir på de samme stedene på de ulike skjermbildene. Under registreringen av en nyansatt vil brukeren blir presentert for ulike knapper som enkelt og raskt skal kunne gi brukeren en mental modell av hvilke oppgaver som kan utføres herfra. Fargen er den eneste måten å få noe til å virke mer attraktivt på. Webapplikasjonen Agresso Employee sitt fargebruk er veldig diskret. Vi har valgt å bruke fargene blått og hvitt gjennom hele applikasjonen. Dette er enkle, kalde og rolige farger som virket avslappende og ikke forstyrrende. Det kalde fargen gir også et preg av en seriøs webapplikasjon. Figur: Screenshot av brukergrensesnittet Agresso Employee 44 Agresso Employee

45 5.3 Implementering av systemet Selve implementeringen av Agresso Employee var en utfordring i seg selv. Gjennom hele implementeringsfasen møtte vi enkelte ganger små og store problemer som vi enten måtte finne løsninger på eller forkaste helt. Dette avsnittet forteller om de forskjellige fasene våre i implementeringen, problemer vi har støtt på og hvordan vi har valgt å løse dem Begynnelsesstadiet og teknologi Selve implementeringen begynte like etter at UML modelleringen var ferdig. Vi hadde da god oversikt over hva som skulle gjøres, i form av kravspesifikasjon og hvordan det skulle se ut, i form av diverse modeller. Men hvordan alt skulle gjøres med tanke på den nye teknologien var det første problemet vi møtte. Systemet Agresso Employee er hovedsakelig blitt utviklet i ASP.NET. Dette var som sagt en helt ny teknologi for oss. Vi visste ikke hvordan det var bygget opp og hvordan det ble brukt..net rammeverket bruker C# kodespråket som vi heller ikke hadde grundig kjennskap til. For å tilegne oss denne kunnskapen brukte vi litteratur arbeidsgiver hadde skaffet oss og forskjellige kilder på internett. Blant annet Microsofts offisielle. NET og C# sider. Men alt dette var vanskelig å sette seg inn i slik at vi forstod sammenhengen. Gruppen meldte seg derfor på valgfaget Webutvikling i.net ved Høgskolen. Ved hjelp av faget og diverse innleveringer lærte vi oss først det grunnleggende i ASP.NET, deretter å utvikle større applikasjoner. Snart var utviklingen av Agresso Employee det minste problemet. Vi fikk alle et godt utbytte av faget og lærte å bruke teknologien på et høyere nivå. Vi begynte utviklingen av webapplikasjonen ved å implementere mindre funksjoner, og etter hvert som vi lærte oss mer, utvidet vi funksjonene til å kunne utføre mer kompliserte oppgaver. I Visual Studio 2005 var det en enkelt sak å designe selve brukergrensesnittet, men vi måtte likevel danne oss et bilde av hvordan elementer skulle være plassert på applikasjonen. Vi valgte å prøve å feile ved å designe forskjellige løsninger og la Rune Spersøy og oss på gruppen vurdere. Det måtte flere utkast til før vi bestemte oss for å beholde det valgte designet. Det var enkelt, effektivt og konsistent. Figur: Agresso Employee GUI Agresso Employee 45

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av:

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av: Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren 2007 31.01.07 Skrevet av: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 1 Sammendrag Prosjektittel:

Detaljer

Kravspesifikasjon for Agresso Employee Hovedprosjekt i data våren 2007

Kravspesifikasjon for Agresso Employee Hovedprosjekt i data våren 2007 for Agresso Employee Hovedprosjekt i data våren 2007 Gruppe 20: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 2 Agresso Employee Presentasjon Prosjektittel: Oppgave: Agresso

Detaljer

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender Hovedprosjekt Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport Presentasjon Sted og dato Oslo, Jan 9, 2011 Prosjekt tittel Periode K-skjema og ferie kalender Utvikle et registreringssystem

Detaljer

Brukerdokumentasjon for Agresso Employee

Brukerdokumentasjon for Agresso Employee for Agresso Employee Hovedprosjekt i data våren 2007 Gruppe 20: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 2 Agresso Employee Forord Dette dokumentet er brukerdokumentasjonen

Detaljer

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser)

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser) Arbeidsplan En arbeidsplan er en måte å få oversikt over de ulike fasene i prosjektet. I arbeidsplanen har vi delt arbeidet i naturlige faser og detaljert disse med estimert tidsbruk. Hovedfasene er startfasen,

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Studentdrevet innovasjon

Studentdrevet innovasjon Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold

Detaljer

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...

Detaljer

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1 ID Name Duration Start Finish 1 Planlegging 95 days Mon 02.10.06 Fri 09.02.07 2 Statusrapport 20 days Mon 02.10.06 Fri 27.10.06 3 Prosjektskisse 25 days Mon 30.10.06 Fri 01.12.06 4 Prosjektweb 31 days

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

Detaljer

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

HOVEDPROSJEKT I DATA VÅR 2011

HOVEDPROSJEKT I DATA VÅR 2011 PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet Kravspesifikasjon Presentasjon Tittel: Oppgave: Backup for PDA/Smartphones Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter

Detaljer

SLUTTRAPPORT. gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen. 25. november 2002

SLUTTRAPPORT. gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen. 25. november 2002 SLUTTRAPPORT gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen 25. november 2002 1 Innhold 1 Sammenligning ressursforbruk 3 2 Erfaringer fra prosjektgjennomføring

Detaljer

Prosessrapport. IT-infrastruktur. Prosessrapport. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008

Prosessrapport. IT-infrastruktur. Prosessrapport. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008 IT-infrastruktur Prosessrapport Mathias Hagen Balagumar Rajaratnam Høgskolen i Oslo Avdeling for Ingeniører 23. mai 2008 Høgskolen i Oslo Hovedprosjekt i data, 2008 Gruppe 8 side 0 PROSJEKT NR. 08-08 Studieprogram:

Detaljer

Repository Self Service. Hovedoppgave våren 2010

Repository Self Service. Hovedoppgave våren 2010 Forprosjektrapport for Repository Self Service Hovedoppgave våren 2010 Christer Berg (070604 07HBDRA) Ron Stangvik (070427 07HBDRA) 1 Innholdsfortegnelse 1. MÅL OG RAMMER...3 1.1. Bakgrunn...3 1.2. Prosjektmål...3

Detaljer

Testdokumentasjon for Agresso Employee

Testdokumentasjon for Agresso Employee for Agresso Employee Hovedprosjekt i data våren 2007 Gruppe 20: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 2 Agresso Employee 1. Forord Denne testdokumentasjonen er en

Detaljer

1. Introduksjon. Glis 13/02/2018

1. Introduksjon. Glis 13/02/2018 SDP GLIS Espen Buø Innholdsfortegnelse 1. Introduksjon... 2 2. Gruppebeskrivelse og ansvarsområder... 3 3. Risikoanalyse... 4 4. Hardware og softwarekrav for brukeren... 5 5. Behov for prosjektet... 6

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann

Detaljer

Gruppe 43. Hoved-Prosjekt Forprosjekt

Gruppe 43. Hoved-Prosjekt Forprosjekt Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

Detaljer

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2 Forum / Nettverkssamfunn Team 2 1 Innholdsfortegnelse 1 Introduksjon... 3 2 Team & Organisering... 3 3 Brainstorming, tanker og utførelse... 4 3.1 Bruker Registrering og metoder... 4 3.2 Generering av

Detaljer

Hovedprosjekt 2011 HO912A. Securitas IT portal. Forprosjektrapport. Adeel Yousaf Khan s Mats Klingenberg Naustdal s Stig Arild Ysterud

Hovedprosjekt 2011 HO912A. Securitas IT portal. Forprosjektrapport. Adeel Yousaf Khan s Mats Klingenberg Naustdal s Stig Arild Ysterud Hovedprosjekt 2011 HO912A Securitas IT portal Forprosjektrapport Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335 Stig Arild Ysterud s155483 1 Innhold

Detaljer

Forprosjektrapport. Gruppe 31

Forprosjektrapport. Gruppe 31 Forprosjektrapport Gruppe 31 1 Presentasjon Oppgave: Finne et kodespråk som kan være med på å forbedre kundetilfredsheten og brukervennligheten ved bruk av Telenor sine websider. Periode: 14. januar til

Detaljer

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Prosessrapport for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

Detaljer

Prosessrapport. Nettside, Webshop og Beregningsmodell. Magnus Eriksen, s Øyvind Schjelderupsen, s Peder Sundbø, s141795

Prosessrapport. Nettside, Webshop og Beregningsmodell. Magnus Eriksen, s Øyvind Schjelderupsen, s Peder Sundbø, s141795 Prosessrapport Nettside, Webshop og Beregningsmodell. Eriksen, s141765 Schjelderupsen, s141758 Sundbø, s141795 1 Innholdsfortegnelse Forord...3 Innledning...3 Gruppen...3 Bedriften...3 Tanker rundt prosjektet...4

Detaljer

PROSESSRAPPORT. Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB. Prosjektperiode: 4. januar mai 2010

PROSESSRAPPORT. Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB. Prosjektperiode: 4. januar mai 2010 PROSESSRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Forprosjektrapport For gruppe 20:

Forprosjektrapport For gruppe 20: Forprosjektrapport For gruppe 20: Kevin Johnny Galåen s135768 Ali Emre Yildirim s135573 Danh Tran s141712 Vibeke Askeland s141436 Fullført: 30.01.2009 Table of Contents Forprosjektrapport... 1 For gruppe

Detaljer

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson PROSJEKTGRUPPE 1 MGT SOFTWARE PROSJEKTPLAN LEVERANSE 1 (REVIDERT 1) Prosjektgruppen: Gjermund Gartmann Tommy Jansson Store Prosjektledelse: Store Kvalitetssikring: Tommy Jansson Dato: 03. oktober 2005

Detaljer

STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell.

STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell. statusrapport 2 I produksjon av webside for skjerdingen høyfjellshotell STATUSRAPPORT 3: Produksjon av nettside for Skjerdingen Høyfjellshotell 1 29. APRIL 2010 http://hovedprosjekter.hig.no/v2010/imt/mp/skjerdingen

Detaljer

Entobutikk 4.PROSESSRAPPORT VÅR 2011

Entobutikk 4.PROSESSRAPPORT VÅR 2011 4.PROSESSRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne prosessrapporten inneholder detaljer om alle metoder vi har benyttet og alle fasene vi gikk gjennom under gjennomføringen av hovedprosjektet ved Høgskolen

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Forprosjektrapport Gruppe 30

Forprosjektrapport Gruppe 30 Forprosjektrapport Gruppe 30 Gruppemedlemmer: Eyvind Nielsen s177748 Ullvar Brekke s236375 Kristoffer Pettersen s239404 Innhold Presentasjon... 3 Sammendrag... 3 Dagens situasjon... 3 Mål... 3 Rammebetingelser...

Detaljer

Prosjektdagbok Oktober 2009 November 2009 Desember 2009 Januar 2010 (Uke 1)

Prosjektdagbok Oktober 2009 November 2009 Desember 2009 Januar 2010 (Uke 1) Prosjektdagbok (Vi valgte og ikke legge ut dagboken på en felles fil som anbefalt da vi har jobbet mye sammen før og viste at vi kunne stole på hverandre. Eventuelle ubehagligheter tok vi heller opp på

Detaljer

Software Development Plan

Software Development Plan Software Development Plan Værsystem Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SDP 03/04/2018 Systemutvikling og dokumentasjon/ia4412

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de

Detaljer

Forprosjektrapport Bacheloroppgave 2017

Forprosjektrapport Bacheloroppgave 2017 Forprosjektrapport Bacheloroppgave 2017 Chat Modul for Webnodes Content Management System Gruppe 32 Adam Asskali, Anmer Seif, Sara Khan 20.01.2017 Veileder G. Anthony Giannoumis Innholdsfortegnelse 1.Presentasjon

Detaljer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

1 Forord. Kravspesifikasjon

1 Forord. Kravspesifikasjon [Type text] [Type text] 3/5 Hovedprosjekt ingeniørutdanningen 09 Kravspesifikasjon Tittel på hovedprosjektet Tarantell Dashboard Gruppe 28 Bjørn Ove Pedersen Stian Dalviken Antall sider 6 Intern veileder

Detaljer

Styringsdokumenter. Studentevalueringssystem

Styringsdokumenter. Studentevalueringssystem Styringsdokumenter Studentevalueringssystem Forord Dette er en samling av alle styringsdokumentene gjennom prosjekt perioden. Styringsdokumentene er satt opp i rekkefølge i forhold til perioden de ble

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i

Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i Heggset Engineering er et kreativt og uavhengig kompetansemiljø med ti ingeniører/tekniske tegnere lokalisert i moderne lokaler i Dale Industripark i Kristiansund. Bedriften tilbyr engineering og maskintekniske

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

Mandag : Onsdag : Torsdag : Mandag :

Mandag : Onsdag : Torsdag : Mandag : Prosjektdagbok Mandag 13.01.2014: - Oppmøte på Accenture. Pratet med veileder om oppgaven og avtalte at vi skulle starte med problemstilling, møteintervall og formulering av oppgaven. Tidsperspektivet

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

Prosjektdagbok hovedprosjekt våren 09

Prosjektdagbok hovedprosjekt våren 09 Prosjektdagbok hovedprosjekt våren 09 Man 25. Mai 09 Planlegging og arbeid med sluttføring Sluttføring av grensesnitt, arbeid med dokumentasjon og detaljplanlegging av sluttføring. Ons 21. Mai 09 Arbeid

Detaljer

Forprosjektrapport. Gruppe Januar 2016

Forprosjektrapport. Gruppe Januar 2016 Forprosjektrapport Gruppe 22 22. Januar 2016 Innholdsfortegnelse Innholdsfortegnelse Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger og alternativer Løsning

Detaljer

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold, Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus Forprosjekt Prosjekttittel Unikia Android applikasjon Gruppe 13 Markus Bugge-Hundere s188909 Morten Wold Aksel Wiig s236326 s232324

Detaljer

Forprosjektrapport ElevApp

Forprosjektrapport ElevApp Forprosjektrapport ElevApp Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2017 Gruppe 14 Mirko Grimm, s236630 Andreas Krutnes, s236656 Japple John Regalario, s236621 Innholdsfortegnelse

Detaljer

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Skrevet av Ole Myrbakken, Fadima Mohamoud, Orji Okoroafor, Karen Arrendondo Side 1 PRESENTASJON Prosjekt tittel: Prosjektperiode: MetaGen 7.jan

Detaljer

PROSJEKTDAGBOK GRUPPE 28

PROSJEKTDAGBOK GRUPPE 28 PROSJEKTDAGBOK GRUPPE 28 Uke 43-25.10.2009 Tid/Sted P35 Gruppen består av 5 medlemmer. Vi hadde en bli kjent opplegg i dag. Arbeider med å levere inn statusrapporten til fredag 30.10.2009. Uke 48-29.11.2009

Detaljer

Software Development Plan (1. utkast)

Software Development Plan (1. utkast) Software Development Plan (1. utkast) Høgskolen i Sørøst-Norge Fakultet for teknologiske fag Institutt for elektro, IT og kybernetikk SDP 12/01/2018 Systemutvikling og dokumentasjon/ia4412 Innholdsfortegnelse

Detaljer

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus Forprosjektrapport Bravo Booking App 1 Presentasjon 2 1.1 Gruppe 2 1.2 Oppdragsgiver 2 1.3 Kontaktpersoner 2 1.4 Oppgave 3 2 Dagens

Detaljer

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER

Detaljer

Fakultet for Teknologi

Fakultet for Teknologi Fakultet for Teknologi HØGSKOLEN I AGDER Grooseveien 36, N-4896 GRIMSTAD Tlf. 37 25 3000 Telefaks 37 25 30 01 Vedlegg 2: Prosjektplan Hovedprosjekt: EuroDOCSIS 2.0, virkemåte og spesifikasjon Utført av

Detaljer

Prosjektrapport Gruppenr FigureGame 3.0

Prosjektrapport Gruppenr FigureGame 3.0 Vedlegg 1. Prosjektavtale Avtale mellom: Reidar Kvadsheim, oppdragsgiver og Robin Juliussen, Olaf Nikolai Hansen og Inger Lill Nystad Prosjektets navn: Figure Game 3.0 Wrath of the Configuration 1. Prosjektets

Detaljer

PROGRAMUTVIKLINGSPLAN. Big Data and Machine Learning

PROGRAMUTVIKLINGSPLAN. Big Data and Machine Learning PROGRAMUTVIKLINGSPLAN Big Data and Machine Learning Innholdsfortegnelse Produkt beskrivelse... 1 Team beskrivelse... 2 Prosjektets kunnskapskrav... 2 Medlemmer og roller... 2 Program prosessmodell beskrivelse...

Detaljer

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio.

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio. Forprosjektrapport ERTMS Driver Interface simulering Prosjektets tittel: ERTMS Driver Interface simulering Gruppe medlemmer: Hallgeir Are Olsen s141454, 3IA Hasan Akin s141460, 3IA Oppdragsgiver: NSB skolen

Detaljer

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...

Detaljer

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...

Detaljer

WillWest Smøredatabase

WillWest Smøredatabase Vedlegg WillWest Smøredatabase GRUPPE 21 FORFATTERE: BREKKLUND, PÅL E. LARSEN, MARTIN WESTGAARD, CHRISTIAN S. 1 Innholdsliste Vedlegg... 1 Innholdsliste... 2 1 Forord... 3 2 Databasemodeller... 4 3 Styringsdokumenter...

Detaljer

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet.

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. DAGBOK Uke 43: Torsdag 28/10 Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. Uke 44: Mandag 1/11 Gruppen utformet den første statusrapporten til prosjektet.

Detaljer

Forprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016

Forprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016 Forprosjektrapport Hovedprosjekt i Informasjonsteknologi Høgskolen i Oslo og Akershus Våren 2016 Gruppe 24 Jon Gillingsrud og Christoffer André Belgen Fredriksen Veileder Thor E. Hasle thor.hasle@hioa.no

Detaljer

STATUSRAPPORT I: Produksjon av webside for Skjerdingen Høyfjellshotell.

STATUSRAPPORT I: Produksjon av webside for Skjerdingen Høyfjellshotell. STATUSRAPPORT I: Produksjon av webside for Skjerdingen Høyfjellshotell 1 25. FEBRUAR 2010 http://hovedprosjekter.hig.no/v2010/imt/mp/skjerdingen INNHOLD PROSJEKTDELTAKERNE 3 PROSJEKTPLAN 3 LEVERANSER OG

Detaljer

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport.

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport. Prosjektdagbok FRA 30.1008 TIL 2.309 Uke Dato Personer tilstede 44 30.1008 48 25.1108 49 02.1208 2 8.109 Tid 10:00 12:00 12:00 12:00 Beskrivelse Vi dannet gruppe og skrev Statusrapport. Kontaktet bedrifter

Detaljer

Forprosjektrapport. Hovedprosjekt våren 2009. Gruppenr. H09E03. Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen

Forprosjektrapport. Hovedprosjekt våren 2009. Gruppenr. H09E03. Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen Forprosjektrapport Hovedprosjekt våren 2009 Gruppenr. H09E03 Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen Styre- og loggsystem for en testjigg HØGSKOLEN I ØSTFOLD Avdeling for ingeniørfag Postadresse:

Detaljer

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad Forprosjektrapport Presentasjon Tittel: Oppgave: Infront SSO Utvikle en Single Sign-on løsning for Infront Periode: 8/1-2013 28/5-2013 Gruppemedlemmer: Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini

Detaljer

Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg.

Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg. Forprosjektrapport Presentasjon Tittel: Inventardatabase Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg. Prosjektperiode: 2/12-08 23/05-08. Prosjektgruppe:

Detaljer

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie 2013 Hovedprosjekt 2013 Gruppe 27 Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie Innhold 1. Presentasjon... 2 2. Sammendrag... 2 3. Dagens Situasjon... 2 4. Mål og rammebetingelser...

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

FORPROSJEKTRAPPORT FOR BACHELOROPPGAVE

FORPROSJEKTRAPPORT FOR BACHELOROPPGAVE FORPROSJEKTRAPPORT FOR BACHELOROPPGAVE Automatisert styring av feilsituasjoner (I NELFO`s prøvestasjon for elektrofagarbeidere) Gruppe B18E01 Magnus H Borgen Magne Johansen Sander Berg 23.Mars 2018 Høgskolen

Detaljer

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 2008-18 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: 22 45 32 00 Telefaks: 22 45 32 05

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

FORPROSJEKT RAPPORT PRESENTASJON FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan

Detaljer

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus,

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus, Bachelorprosjekt ved Institutt for informasjonsteknologi, våren 2017 Høgskolen i Oslo og Akershus, 19.01.2017 Gruppe 44 Håkon Andre Sylte Garnes, Tobias Hallèn, Gaurab J. Gurung Forprosjektrapport Presentasjon

Detaljer

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1 Innhold Innledning... 2 Faseplan... 2 Iterasjonsplanlegging... 3 Oppstartsfasen... 3 Artefaktene i oppstartsfasen... 4 Utdypingsfasen... 5 Konstruksjonsfasen... 5 Overføringsfasen... 6 Litteratur... 7

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Prosessdokument. Utlånssystem for datautstyr. Hovedprosjekt ved Høgskolen i Oslo. Prosjektgruppe nr 08 09

Prosessdokument. Utlånssystem for datautstyr. Hovedprosjekt ved Høgskolen i Oslo. Prosjektgruppe nr 08 09 Prosessdokument Utlånssystem for datautstyr Hovedprosjekt ved Høgskolen i Oslo Prosjektgruppe nr 08 09 Ole Anders Eidjord Nojanaj Pongsupaht Kristoffer Skappel Johannes Urke Utlånssystem for datautstyr

Detaljer

HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Avslutning

HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Avslutning HØGSKOLEN I OSLO OG AKERSHUS FôrIt CDS Stian Strøm Anderssen, Mikkel Sannes Nylend og Shahariar Kabir Bhuiyan Gruppe 10 26.05.2014 Forord Denne rapporten oppsummerer vårt arbeid med FôrIt CDS. Under skriver

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

Detaljer

Forord... 3. Planleggingsprosess... 4. Prosjektstart... 4. Arbeidsmåte/Fremgangsmåte... 4. Begreper innenfor Scrum... 5. Datainnsamling...

Forord... 3. Planleggingsprosess... 4. Prosjektstart... 4. Arbeidsmåte/Fremgangsmåte... 4. Begreper innenfor Scrum... 5. Datainnsamling... 1 Innholdsfortegnelse Forord... 3 Planleggingsprosess... 4 Prosjektstart... 4 Arbeidsmåte/Fremgangsmåte... 4 Begreper innenfor Scrum... 5 Datainnsamling... 6 Styringsdokumenter... 6 Dagbok... 7 Rissikoplanlegging...

Detaljer

Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2

Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2 PROSJEKT NR. 2007-02 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET

Detaljer

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV

Detaljer

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport Høgskolen i Oslo og Akershus Bachelorprosjekt 2017 Hacking Cristin (midlertidig tittel) Forprosjektrapport Innholdsfortegnelse: 1.0 Presentasjon s. 3 2.0 Sammendrag s. 3 3.0 Dagens situasjon s. 4 4.0 Mål

Detaljer

Dagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00)

Dagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00) Dagbok Januar Uke 2 (7.1-11.1) Vi har lest halvveis på standard dokumentasjon og jobbet med forprosjektrapport. Vi har hatt vårt første møte med den interne veilederen vår Tor Hasle. Vi fortalte om at

Detaljer

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen Forprosjektrapport Presentasjon Tittel Informasjonsplatform for NorgesGruppen Oppgave Utvikle en informasjonsplatform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer Joakim Sjögren

Detaljer

Prosjektdagbok. Gruppe 9. Gruppemedlemmer. Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741)

Prosjektdagbok. Gruppe 9. Gruppemedlemmer. Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741) Prosjektdagbok Gruppe 9 Gruppemedlemmer Eirik Fjellheim Andersen (s198590) Sigurd Witold Aspen (s198593) Jonas Mögenburg (s198741) Månedsoppsummering: Mai Arbeidet har vært tungt siden vi har måttet flytte

Detaljer

Entobutikk FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02

Entobutikk FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02 FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02 1 INNHOLDSFORTEGNELSE PRESENTASJON 03 SAMMENDRAG 04 BEDRIFT 05 Om bedriften 05 Dagens situasjon 05 MÅL OG RAMMEBETINGELSER 06 Funksjonalitet

Detaljer

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument

Detaljer

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Produktrapport Forord Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Dataansvarlig eller supporter trenger informasjon om

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer