Prosessrapport. Utvikle et registreringssystem for personalet Periode: Kamiran Ahmed Selewani (s156192) Ali Ahmed Mirzaeie (s156172)

Transkript

1 Hovedprosjekt 2011 Oppgave: Utvikle et registreringssystem for personalet Periode: 03.Januar til 17.Juni Gruppenr: 4 Medlemmer: Oppdragsgiver: Kontaktperson: Veileder: Kamiran Ahmed Selewani (s156192) Ali Ahmed Mirzaeie (s156172) Azad Bamarni (s141710) Behrouz Saki (s155476) Utlendingsnemnda (UNE) Carlos Ahomada cah@une.no Steinar Johannessen Hovedprosjekt 2011 Side 1 av 42 Gruppe 4

2 Forord Dette dokumentet er prosessrapporten for prosjektet K-Skjemaer. Rapporten er skrevet i forbindelse med hovedprosjekt oppgaven, skrevet av studentene i Gruppe 4 fra linjene Data-ingeniør og IT-Informasjonsteknologi ved Høgskolen i Oslo våren 2011 i samarbeid med oppdragsgiveren Utlendingsnemnda(UNE). Rapporten beskriver analyser, arbeidsmåter, utfordringer, resultat og konklusjon av prosjekt arbeidet. Rapporten er beregnet for sensor, veileder oppdragsgiver og andre som kan finne den interessant. Vi tar anledningen for å takke vår studieveileder Steinar Johannesen og faglærer Tor Krattebøl som har bidratt med rådgivning og veiledning under prosessen. Azad Bamarni Kamiran Selewani Behrouz Saki Ali Ahmad Mirzaiei

3 Innholdsfortegnelse 1 Innledning Om gruppen Om Utlendingsnemnda UNE Bakgrunn for prosjektet Problemstilling situasjonsanalyse Gjennomføring a Fakta innsamling Nåværendesystem a Tiltredelse b Intern endring c Fratredelse d Feriekalender Mål og Rammebetingelser Mål Rammebetingelser Løsning og alternativer: Løsning: a Språk og teknologi b Rammeverk og verktøy c presentasjon av løsningsforslag Planlegging og metode Plan i faser Fremdriftsplan Arbeidsplan a Ide fase b Utvikling, testing c Dokumentasjon d Avslutning Arbeidsmetoder Risikoanalyse Om utviklingsprosessen Valg av prosessmodell... 24

4 9.2 Oppgavefordeling Utviklingsfase og aktiviteter a Utdypningsfase b Konstruksjonsfase Planlegging av iterasjoner a Første Iterasjon b Andre iterasjon c Tredje iterasjon d Fjerde iterasjon Overgangsfase Kravspesifikasjon og dens rolle Kravanalyse Endringer i kravspesifikasjon Resultat Hva ble resultatet Skisse til videreutvikling for oppdragsgiver a Presentasjonsfiler b Presentasjonssider c Opprette ferie for ansatt d Ansatte på ferie e Ansatt på jobb f Kalender Konklusjon Litteratur... 42

5 Innledning 1 Innledning 1.1 Om gruppen Gruppen bestod av studentene Kamiran Selewani, Azad Bamarni, Ali Ahmed Mirzaiei og Behrouz Saki. Medlemmene i gruppen har kjent hverandre fra før og har jobbet sammen ved flere anledninger i løpet av studietiden på høgskolen i Oslo. Forventningene til hverandre var basert på solide erfaringer, som er gjort over de to foregående årene og er derfor realistiske. Vi valgte å danne denne gruppen da vi hadde god kommunikasjon, et godt samarbeid og likt ambisjonsnivå. Vi hadde stor interesse til felles innen systemutvikling, databaser og objekt orientert programmering. Denne oppgaven var akkurat det vi hadde ønsket å jobbe med der vi kan foreta analyser, velge riktig løsning, modellere og realisere modellene i et produkt som vi selv har utviklet. Og vi synes den har mest relevans for vårt studium, og at vi kan ha utbytte av den i forhold til arbeidslivet vi snart skal ut i Om Utlendingsnemnda UNE Klageinstansen Utlendingsnemnda (UNE) er et domstolliknende forvaltningsorgan til behandling av klager over avslag på asyl/oppholdstillatelse/arbeidstillatelse gitt av førsteinstansen Utlendingsdirektoratet(UDI) etter utlendingsloven og statsborgerloven. UNE ble startet i januar Og har siden vært en voksende organisasjon. UNE er et politisk uavhengig forvaltningsorgan som ble lagt under Justis- og politidepartementet (JD). (fra ). Departementet kan ikke instruere om lovtolking, vurdering eller avgjørelse i enkeltsaker (unntatt i saker som gjelder grunnleggende nasjonale interesser eller utenrikspolitiske omsyn). Styringen må skje gjennom lov og forskrift. Utover dette kan departementet instruere om prioritering av saker og om organisatoriske og administrative forhold. Mer om organisasjonen finner man under organisasjonens offisielle nettside: Hovedprosjekt 2011 Side 4 av 42 Gruppe 4

6 2 Bakgrunn for prosjektet Prosessrapport Bakgrunn for prosjektet Alle studenter skal i forbindelse med sin utdannelse ha en hovedprosjektoppgave (kjent som bachelor oppgave) der studenter får en oppgave om å levere inn en rapport, lage et produkt, foreta et eksperiment eller noe lignende, Oppgaven vil være avhengig av utdanningslinjen med unntak av noen studielinjer der studentene tar ekstra fag istedenfor hovedoppgaven. Studenter ved linjene Data ingeniør og IT-Informasjonsteknologi ved Høgskolen i Oslo leverer inn prosjekter i form av produkter(programmer/nettsider) eller rapporter(analyser). Studentene skal finne seg et prosjekt og danne en gruppe på 2 til 5 medlemmer. Vi valgte et prosjekt foreslått av Utlendingsnemnda(UNE). UNE benytter per i dag et midlertidig registreringssystem for personale, og registreringssystemet de har per i dag dekker ikke behovet. Derfor vil organisasjonen at studentene skal lage en administrativ applikasjon som personalansvarlig skal administrere, og flere brukere fra forskjellige avdelinger kan fylle ut skjemaer og lagre data i databasen. Hovedprosjekt 2011 Side 5 av 42 Gruppe 4

7 Problemstilling - situasjonsanalyse 3 Problemstilling situasjonsanalyse I forbindelse med prosjektet K-Skjemaer har vi foretatt en situasjonsanalyse om dagens situasjon hos Utlendingsnemnda(UNE). Målet med analysen var å kartlegge problemstillingen og samle inn nødvendig informasjon og dermed kunne utarbeide en god løsning ut ifra problemstillingen. Det er mange forutsetninger som må vurderes, Forståelse av problemområdet er grunnleggende her, og det må tas hensyn til brukere, kompetanse og ikke minst lønnsomhet. I situasjonsanalysen har vi konsentrert oss om dagens systemer, brukere, kompetanse, samspill og rutiner. 3.1 Gjennomføring Vi gjennomførte situasjonsanalysen med fakta innsamling om organisasjonen Utlendingsnemnda(UNE). Vi utførte informasjonsmøter og intervjuer sammen med organisasjonens kontaktperson og andre system bruker. Andre system brukere var avdelingssjefer for HR-Human Resource, Økonomi og Service avdeling. Under disse møtene/intervjuene brukte vi skjemaer med spørsmål om kritiske og essensielle opplysninger som er av betydning for prosjektet. Skjemaet under er et eksempel på spørreskjemaer som ble brukt under informasjonsmøter. Fokusområdet Spørsmål Faktum Personalet Ansatte Hvor mange ansatte jobber hos UNE Avdelinger Hvor mange avdelinger Stillinger Stillingstyper Ansvar Hvem har rettigheter, hvor mange avdelingssjefer. IT-avdeling Hvor mange ansatte i den avdelingen, Kunnskap. Opplysninger Info om ansatte Hvor mye info blir lagret Tilgang Hvor mange som skal ha tilgang til opplysninger Rettigheter Hvem har lese og skriverettigheter PC-relatert Server Har egen server? Hvor mange maskiner Server-Software Hvilket operativ system kjøres på servere Pc-er Hvilket operativ system kjøres på personlige datamaskiner Hovedprosjekt 2011 Side 6 av 42 Gruppe 4

8 Problemstilling - situasjonsanalyse 3.1.a Fakta innsamling Vi begynner fakta innsamling med å innhente generelle opplysninger og fortsetter med å innhente opplysninger om dagens ordning. Generelle opplysninger Det jobber per i dag 363 ansatte i utlendingsnemnda under 7 hoved avdelinger, HR Human Resource, Økonomi, Drift og IT, Service, Oppholds avdeling, Asyl avdeling A og Asyl avdeling B. Opplysninger om avdelingene HR, Økonomi, Resepsjon, Service og Drift-IT (DI) avdeling er av direkte betydning for oss siden det er disse avdelingene som bruker K-Skjemaene. I HR avdelingen jobber det 11 ansatte som har ansvaret for personalet. I Drift og ITavdelingen jobber det per i dag 13 ansatte, der jobber de med forskjellige drift og IT relaterte oppgaver. Økonomi avdelingen jobber med lønn, og det er der en ansatt får et ansatt nummer, Resepsjon skriver ut adgangskort, Service jobber med telefoner, telefonlister og kataloger. UNE har et lokalt nettverk (Intranett) som brukes kun av ansatte i organisasjonen. UNE lagrer sine data på en Windows server Personlige datamaskiner kjører Windows XP operativsystem. Vi vil nevne her at vi har fått tillatelse fra oppdragsgiver om å skrive de overnevnte opplysningene. Hovedprosjekt 2011 Side 7 av 42 Gruppe 4

9 Nåværendesystem 3.2 Nåværendesystem UNE s administrasjon bruker per i dag såkalte K-skjemaer som er laget i Microsoft Access filer. Microsoft Access er et medlem av Microsoft Office programmer, Access lagrer data i sitt eget format basert på Access Jet Database Engine der samling av informasjon blir lagret på en systematisk måte på en datamaskin. K-skjemaer består av 3 hoved skjemaer tiltredelse, intern endringer og fratredelse, og de har i tillegg et eget skjema som brukes for å ha oversikt over feriekalenderen. Skjemaene ligger under mapper på et reservert område på serveren, mappene heter forholdsvis Tiltredelse, intern endringer og fratredelse. Skjemaene virker separate og har ingen direkte kobling til hverandre. Nedenfor er en mer detaljert beskrivelse av K-skjemaene. 3.2.a Tiltredelse Dette skjemaet brukes av avdelingen HR. Det opprettes en ny Access fil for hver ny ansatt, det vil si at det ligger under mappen Tiltredelse per i dag 363 filer, en fil for hver ansatt. Filen inneholder skjemaet, der hovedansvarlig for ansettelse fyller ut skjemaet med opplysninger om nye ansatte. Her blir det oppgitt hvilken stilling vedkommende skal ha, i hvilken avdeling skal vedkommende jobbe, og en del andre tekniske og praktiske opplysninger relatert til ny ansettelse. Dette lagres i sin Access fil. Deretter gis det en beskjed via e-post til andre avdelinger. Andre avdelinger er Drift-IT, Service, Økonomi, Resepsjon. Opplysninger som blir sendt vil være avhengig av hver enkelt ny ansatt og ansettelsesforholdet med hensyn på personvern. Hver avdeling må fylle ut sine poster innen en uke før tiltredelsesdato, eventuelle avvik meldes til HR. Opplysningene blir lagret da i sin Access fil. Nesteside er et bilde av Tiltredelsesskjemaet. Hovedprosjekt 2011 Side 8 av 42 Gruppe 4

10 Nåværendesystem 3.2.b Intern endring Skjemaet ligger under mappen Intern endringer og inneholder opplysninger om intern endringer innen UNE. I likhet med andre skjemaer skal ansvarlige fylle ut sine poster. Og skjemaet lagres som Access fil helt separat uavhengige av andre skjemaer og andre filer. Her blir det 363 nye filer, da blir det til sammen 3 * 363 = 1089 filer i systemet til UNE. Hovedprosjekt 2011 Side 9 av 42 Gruppe 4

11 Nåværendesystem Nedenfor er et bilde av skjemaet. Hovedprosjekt 2011 Side 10 av 42 Gruppe 4

12 Nåværendesystem 3.2.c Fratredelse Dette skjemaet ligger under mappen Fratredelse og brukes igjen av HR avdelingen der den ansvarlige fyller ut skjemaet og ber andre avdelingsansvarlige om å fylle ut hver sine poster. Skjemaet inneholder opplysninger om ansatte som avslutter sitt arbeidsforhold sammen med en del praktiske og tekniske opplysninger. Skjemaet lagres som Access fil og har ingen kobling til første skjemaet (Tiltredelsesskjemaet), Det vil si at hvis det er 100 tidligere ansatte da er det 100 fratredelsesfiler som gir en total antall filer på 363 * = 826 filer.. Nedenfor er et bilde av Fratredelsesskjemaet. Hovedprosjekt 2011 Side 11 av 42 Gruppe 4

13 Nåværendesystem 3.2.d Feriekalender Dette er et eget skjema som brukes for å ha oversikt over feriekalenderen til ansatte hos utlendingsnemnda, skjemaet består av to deler A og B, ansatte leverer en manuell lapp til HR avdelingen, ansatte skriver inn ønsket dato og varighet for ferie. Feriekalenderansvarlig fyller inn ønsket dato eventuelt setter ny dato hvis det ikke er mulig med ønsket dato. Skjemaet viser antall ansatte som er på jobb til en hver tid, og hvem som er på ferie, med oversikt på fra-til dato. Ulempen med dette er at ved hver endring må ansvarlig endre alle feltene manuelt. Dette er i likhet med andre skjemaer et separat skjema som virker uavhengig av andre skjemaer. Nedenfor er et bilde av UNEs feriekalender. Hovedprosjekt 2011 Side 12 av 42 Gruppe 4

14 4 Mål og Rammebetingelser Prosessrapport Mål og rammebetingelser 4.1 Mål Målet med prosjektet er å utvikle et nytt system for Utlendingsnemnda. Systemet som skal utvikles skal erstatte det nåværende systemet, og tilby nye funksjoner. Løsningen skal ha et hensiktsmessig brukergrensesnitt slik at det blir så enkelt som mulig å bruke det. Det skal ikke kreve forkunnskaper innen avansert databruk for sluttbrukere og skal heller ikke være veldig avansert for drifting og eventuelt videreutvikling. 4.2 Rammebetingelser Når det gjelder rammebetingelser var det tid som ble viktigst og påvirket valg av funksjonalitet. Alle funksjonaliteter var vurdert med hensyn på tidsbegrensninger og disse betingelsene var påvirket av UNE s sitt ønske om utfall av prosjektet. Gruppen hadde møter med oppdragsgiver og satt opp en liste over all funksjonalitet som de kunne tenke seg systemet kunne ha, så prioriterte vi denne listen og realiserte funksjonene etter prioriteringsrekkefølgen. Underveis la vi også nye ideer til funksjonalitet som vi kom på og forandret det grafiske brukergrensesnittet. I tillegg har vi tatt hensyn på at systemet måtte være relativt billig å drifte, vedlikeholde og utvide. vi kom frem til følgende rammebetingelser: Windows plattform Utviklingsspråk C# Utviklingsverktøy Visual Studio Måneder tidsramme. Applikasjonen skal fungere i de fleste webleserne. 5 Løsning og alternativer: Ut ifra situasjonsanalysen om dagens situasjon hos UNE foretatt tidligere av gruppemedlemmer i forbindelse med dette prosjektet, og på bakgrunn av informasjonsmøter holdt med forskjellige systembrukere har vi fått en klar forståelse av problemstillingen. Med problemstillingen mener vi her hva som skal forbedres og hva som trengs for å forbedre det. Det som trengs i den sammenheng er en applikasjon som skal være tilgjengelig for flere brukere med hensyn på lese og skrive rettigheter, og ut ifra det har vi bestemt å utvikle en nettbasert applikasjon(web-applikasjon) som kan kjøres via en nettleser. Under et av informasjonsmøtene ble det nevnt et ønske fra oppdragsgiveren om en nettbasert Hovedprosjekt 2011 Side 13 av 42 Gruppe 4

15 Løsning applikasjon slik at applikasjonen kan være tilgjengelig og kan kjøres i UNE s lokale nettverk (UNETT). For å utvikle dette prosjektet har vi flere valg med tanke på nettbasert applikasjon, den ene vil være å utvikle det med HTML, CSS, JavaScript og PHP. En annen løsning kunne være å lage en Java web-applikasjon, men denne løsning måtte vi se bort fra etter et ønske fra oppdragsgiveren om og ikke bruke Java. Løsningen vi derimot har valgt er asp.net. 5.1 Løsning: 5.1.a Språk og teknologi Løsningen vi derimot har valgt er asp.net. Grunnen at vi valgte denne løsningen er at Microsoft asp.net er en gratis teknologi som lar programmerere lage dynamiske web-applikasjoner. Med kraftig programmeringsspråk i bakgrunn som C#, og med et funksjonsrikt utviklingsverktøy som Visual Studio 2010 blir generering av komponenter enklere som vil igjen bidra til rask utvikling. Man vil kunne spare masse tid, og har mulighet til å lage store applikasjoner fortere enn f. eks med PHP. ASP.NET er et web-applikasjons rammeverk utviklet og markedsført av Microsoft. asp.net er en integrert del av Microsofts. NET Framework visjon. Som medlem av. NET rammeverket, er asp.net et svært verdifullt verktøy for programmerere og utviklere som det tillater dem å bygge dynamiske, rike nettsteder og web-applikasjoner ved hjelp av kompilerte språk som VB og C #. asp.net ble først utgitt i Januar 2002 med versjon 1.0 av.net Framework, og er etterfølgeren til Microsoft Active Server Pages (ASP), Og har nå utgitt sin siste versjon asp.net 4.0 Vi nevner dette for å begrunne hvorfor vi valgte akkurat denne løsningen og ikke for å reklamere for Microsoft produkter. herunder er det noen fordeler med asp.net teknologien har blitt utviklet for å koble opp bedrifter, ansatte og partnere i en sløyfe gjennom bruk av web tjenester. asp.net gir optimal fart på utviklingen, og er en streng sikkerhet. Teknologien har store og beriket klassebibliotek, funksjoner og kontroller. asp.net reduserer drastisk kode mengde som kreves for å bygge store applikasjoner. asp.net gjør utviklingen lettere og enklere å vedlikeholde med en hendelse-drevet, server-side programmeringsmodell. Store erfarne team av asp.net utviklere er forpliktet til å tilby folk med bærekraftige løsninger, kvalitet og service på asp.net-teknologi. Hovedprosjekt 2011 Side 14 av 42 Gruppe 4

16 Løsning Kildekoden kjøres på serveren. Sidene har masse kraft og fleksibilitet ved denne plasseringen. Kildekoden er kompilert første gang siden forespørres. Utførelsen er rask som Web Server kompilerer siden første gang det blir bedt om. Serveren lagrer den kompilerte versjonen av siden for bruk neste gang siden forespørres. Webserveren overvåker kontinuerlig sidene, komponenter og programmer som kjører på den, Hvis det observeres minnelekkasjer, uendelige løkker, annen ulovlig programvare eller aktiviteter, dreper det sømløst de aktiviteter og starter på nytt selv. Asp.net validerer informasjon (valideringskontroller) angitt av brukeren uten å skrive en eneste linje med kode Kort oppsummert kan man si at.net vil gi oss mulighet til å utvikle avanserte systemer fortest og enklest som mulig. Dette virker veldig spennende, og statistikkene viser at det er stadig større etterspørsel etter kunnskap om denne teknologien i arbeidslivet. 5.2.b Rammeverk og verktøy Som rammeverk og verktøy har vi et stort utvalg av. Herunder nevner vi hvilket rammeverk og hvilke andre programmer vi kommer til å bruke for å utvikle dette systemet. Rammeverk:.NET Teknologier: ASP.NET 4.0 Utviklingsprogram: Visual studio 2010, Visual Web Developer Express Edition Database: SQL Server Programmeringsspråk: C# Andre programmer: Adobe Photoshop, FTP Program, VPN, WinScp, Filezila, Google Gmail-Dokument, Microsoft Visio pro 2010, Office Project Pro 2010, ArgoUml. Hovedprosjekt 2011 Side 15 av 42 Gruppe 4

17 Løsning 5.3.c presentasjon av løsningsforslag Som følge av situasjonsanalysen og løsningsforslag, hadde vi en presentasjon av løsningsforslaget i form av en PowerPoint slide. Tirsdag den holdt gruppen en presentasjon av løsningsforslaget der vi presenterte løsningen, presentasjonen ble holdt i UNE s lokaler. Fra oppdragsgiveren var det fire avdelingssjefer til stedet. Oppgavene hadde blitt delt på forhånd og gruppemedlemmer var godt forberedt til presentasjonen. Vi startet presentasjonen med forklaring av arbeidsprosessen og hvordan vi har tenkt å arbeide med prosjektet, forklaring på produktet og programmerings språk. Og vi presenterte modeller og eksempel på hvordan produktet kan se ut. Gjestene viste en stor interesse, og det ble stilt flere spørsmål under presentasjonen og på slutten av den, vi er stolte av å si at alle spørsmål ble besvart og gjestene ble førnøyde. Dermed fikk vi en godkjennelse på løsningsforslaget og kunne begynne å planlegge utviklingen. Vi legger presentasjons slide som vedlegg 1. Hovedprosjekt 2011 Side 16 av 42 Gruppe 4

18 Planlegging og metode 6 Planlegging og metode I dette kapittelet vil vi presentere hvilke verktøy, hvilke teknologier og hvilken utviklingsmetodikk vi benyttet oss av. Videre vil vi utdype hvordan vi brukte verktøyene og teknologiene knyttet til prosessen. Til slutt vil vi gå nærmere inn på fil- og kodedeling, fysiske arbeidsforhold og kommunikasjon både innad i gruppen og mellom gruppen, oppdragsgiver og veileder. Dette har vi gjort fordi vi mener det hadde en stor innvirkning på prosessen og det ferdige produktet. 6.1 Plan i faser Et prosjekt opprettes for å utføre en begrenset engangsjobb, arbeidet er en engangshendelse med et klart definert omfang. Det er faste start og stopptider. Prosjektarbeidet kan med fordel inndeles i faser. Faseinndelingen benyttes i den overordnende prosjektplanleggingen. Fase inndelingen vil være avhengig av type prosjekt. Det er vanlig å dele et prosjekt i 4 faser slik vi har gjort her. Fasene er idefase, startfase, gjennomføringsfase og sluttfase. Illustrert i figuren nedenfor: En detaljert beskrivelse av aktiviteter gjennom fasene og valgt prosessmodell ligger under kapittelet Om utviklingsprosessen. Hovedprosjekt 2011 Side 17 av 42 Gruppe 4

19 Fremdriftsplan 6.2 Fremdriftsplan En fremdriftsplan overvåker aktiviteter i et prosjekt. Et viktig konsept bak prosjektplanlegging er at enkelte aktiviteter er avhengig av andre aktiviteter til å bli ferdig først. For eksempel er det ikke en god idé å begynne å bygge veggene i et kontorbygg før man har lagt grunnlaget, heller er det en god idé å la kaken mixe i formen uten å smøre formen først. Avhengige aktiviteter må fullføres i en sekvens, med hver etappe blir mer eller mindre ferdige før neste etappe kan begynne. Vi kan kalle slike avhengige aktiviteter "sekvensiell aktiviteter". Ikke-sekvensiell aktiviteter er ikke avhengige av ferdigstillelse av andre oppgaver. Disse aktivitetene kan gjøres når som helst før eller etter et bestemt stadium i prosjektet er nådd. Disse aktivitetene kalles ikke-avhengige eller "parallelle" oppgaver. For hver oppgave vises det tidligst mulig startdato, hvor lenge det anslås hvor lang tid det skal ta, og om det er parallell eller sekvensiell. Hvis oppgavene er sekvensielle, viser hvilke stadier de er avhengig av. I fremdriftsplanen har vi tatt med dager, uker og måneder frem til oppgaven er fullført, og hvor lang tid har hver oppgave tatt. Gruppen har planlagt aktivitetene på en slik måte at sekvensiell handlinger er utført og i riktig rekkefølge og sørger for at disse avhengige aktivitetene starter ikke før de aktiviteter de er avhengige av har blitt fullført. Vi har brukt MS Project 2010 for å lage Gantt-diagramm. MS Project gjør tegning av Gantt diagrammer enklere, også gjør påfølgende endringer av planer enklere og tilbyr fasiliteter for å overvåke fremgangen mot planene. Dette er et verktøy som er ofte i bruk ute i arbeidslivet og vi har derfor bestemt å bruke det. Gant diagrammet som vist i figuren under inneholder en oversikt over fasene, varighet, start og stopp tider. Dette bildet ble skalerbart for å tilpasse dette dokumentet. Hovedprosjekt 2011 Side 18 av 42 Gruppe 4

20 Arbeidsplan 6.3 Arbeidsplan Arbeidsplanen er et styringsverktøy som er retningsgivende for studentene i prosjekt perioden, planen vil danne et grunnlag for forskjellige aktiviteter med en estimert tidsramme, og har en oversikt over tidsfrister for forskjellige milepæler. Planen kan forandres i løpet av prosjektperioden etter behov. 6.3.a Ide fase Oppgave Frist Statusrapport Fredag 30. Oktober 2010 Prosjektskisse Fredag 4. Desember 2010 Forprosjekt Fredag 29. Januar b Utvikling, testing: Oppgave Frist Iterasjon 1, Tiltredelse Fredag 25. Februar 2011 Iterasjon 2, Intern endring Fredag 18. Mars 2011 Iterasjon 3, Fratredelse Fredag 1. April 2011 Iterasjon 4, Statistikk, feriekalender(skisse) Fredag 6. Mai 2011 Sluttfase Fredag 20. Mai c Dokumentasjon: Oppgave Prosjektdagbok prosessrapport Mandag 31, mai 2011 prosjektrapport Mandag 31, mai 2011 Frist Leveres ikke sammen med prosessrapport og prosjektrapport, men for å holde oversikt over forskjellige møter. 6.3.d Avslutning: Oppgave Frist Forberede presentasjon 1-13 juni 2011 Presentasjon juni 2011 Hovedprosjekt 2011 Side 19 av 42 Gruppe 4

21 Arbeidsmetoder 7 Arbeidsmetoder Fra tidligere prosjekter i datalinjen ved Høgskolen i Oslo, har vi erfaringer med hvordan et prosjektarbeid er satt opp og hvilke arbeidsmåter kan følges. Hovedprosjektet er større enn andre prosjekter vi har hatt, så gruppen trengte en mer fleksibel utføringsplan enn de vi hadde hatt før, og vi ønsket å lære nye metoder og teknikker en de vi har lært så langt i studieperioden. Derfor valgte vi å bruke induktiv metode. Induktiv metode stammer fra ordet induksjon som fra latin kan oversettes med innføring eller tilledning. Induksjon er et begrep i filosofi, logikk, fysikk og erfaringsvitenskapelig metode. Begrepet har forskjellige betydninger innenfor de enkelte fagområdene. Her vil vi i gruppen bruke induktiv metodikken for utviklingen av produktet der alle er initiativet. Hver enkel vil ta initiativet og gå fra det enkle til det generell, vi starter med analyse av brukertilfeller(use-case), opprette brukergrensesnittet og tilslutt realisere brukertilfellen(implementere). Dette skal vi vise til oppdragsgiveren og gi dem den muligheten til å velge om de vil beholde det brukergrensesnittet eller om de ønsker forandringer. Metoden vil skape selvmedgående arbeidere, og vi vil med dette dele våre erfaringer. Til slutt vil denne metoden gi oss en generell erfaring innen prosjektdeltakelse. Vi har brukt Gmail-Dokumenter for å logge føre og skrive fremgangen parallelt med prsosessen. På den måten har vi klart å følge utviklingen dag for dag med tenking, utvikling, feilslag, testing og resultater Hovedprosjekt 2011 Side 20 av 42 Gruppe 4

22 Risikoanalyse 8 Risikoanalyse Risikoanalyse foretas for å avdekke risikoen i forbindelse med et prosjekt, en aktivitet eller et produkt etc. Risikoanalyser innebærer en oversikt over hendelser som kan inntreffe, hvilken sannsynlighet de har og konsekvenser som medfølger, basert på en slik analyse setter bedriften tiltak for kritiske hendelser. Herunder presenterer vi en kort oversikt på risikoanalyse i form av en tabell. Risiko Sannsynlighet Konsekvenser fra 0 til 10 Rang Følge Tiltak hvis problemet oppstår Tap av tid Høy Alvorlig Se punkt 1 Sykdom Høy Alvorlig Se punkt 2 Gruppemed Lav 1 0,8 Alvorlig Se punkt 3 lemmer slutter Gruppemed Høy 7 1 Alvorlig Se punkt 4 lemmer gjør ikke sin arbeid Interne lav 2 0,4 Akseptabelt Se punkt 5 konflikt Dårlig faglig Moderat Alvorlig Se punkt 6 Kompetans e Kommunika Moderat 5 0,5 Akseptabelt Se punkt 7 sjonssvikt Tap av Lav 3 0,8 Akseptabelt Se punkt 8 fokus Feil Moderat 4 0,4 Tolerabel Se punkt 9 prioritering av kilde Tap av data Moderat 5 1 Katastrofal Se punkt 10 (arbeid) Kvalitetssikr Høy Katastrofal Se punkt 11 ing Dårlig Lav Akseptabelt Se punkt 12 arbeidsmiljø Strømbrudd Lav 2 0,6 Tolerabel Se punkt 13 Brann Lav 2 0,2 Alvorlig Se punkt 14 Mangel på Lav Akseptabelt Se punkt 15 utstyr Oppdragsgi Høy 10 2 Alvorlig Se punkt 16 ver trekker seg Dårlig planlegging Høy 7 1 Alvorlig Se punkt 17 Hovedprosjekt 2011 Side 21 av 42 Gruppe 4

23 Risikoanalyse 1. Tap av tid: For å ikke havne i denne situasjonen er det viktig at gruppemedlemmer samarbeider, holde oversikt over milepæler og bruker tiden så godt man kan. 2. Sykdom: Hvis et medlem blir fraværende på grunn av sykdom, må resten av gruppa gjøre mer arbeid. Ekstra jobbing. 3. Gruppemedlem slutter: Må prøve å holde motivasjonen oppe og skape et bra arbeidsmiljø. 4. Gruppemedlemmer gjør ikke sin arbeid: Det er veldig viktig at alle får vite hvilket ansvar de har i gruppa og kommunisere med hverandre i tilfeller de ikke kan gjøre arbeidet de har fått slik at andre gruppemedlemmer får vite hvor gruppa ligger i forhold til planen. 5. Interne konflikt: Alle i gruppa har forskjellige meninger og det er smak og behag og det er ikke alle som er enige med nye forslag og ideer, men vi må løse problemet basert på hva kunde vil ha og komme med et godt forslag hvor vi ikke kommer i konflikt med andre gruppe medlemmer. 6. Dårlig faglig kompetanse: Alle er ikke på likt nivå og det er viktig at vi må regne med mye lesing for å kunne sette oss inn i fagets begreper og utrykk. 7. Kommunikasjonssvikt: Vår gruppe består av fire medlemmer av forskjellige bakgrunner, det kan derfor oppstå misforståelser og konflikter. Dette kan føre til tap av tid. Samarbeid i gruppen er viktig. 8. Tap av fokus: Det er mulig at en ikke kan fokusere og mister konsentrasjon i løpet av prosjektet og da er det viktig at vi andre tar over arbeidet og trøste han på en måte slik at han kommer i gang. 9. Feil prioritering av kilde: Kilde er en viktig del av prosjektet dersom man ikke bruker kilde på riktig måtte og den riktige kilde så kan det gå galt med arbeidet og gruppen kommer til å tape en del tid på grunn av det, derfor er det viktig å bruke de nødvendige kilder som tilpasser vår prosjekt arbeidet og henvise hva slags kilde vi har og hatt brukt i løpet av prosjektet. Hovedprosjekt 2011 Side 22 av 42 Gruppe 4

24 Risikoanalyse 10. Tap av data: Må huske å ta Back up, i tilfelle mister det. Det blir store påkjenninger dersom data må skapes på nytt. 11. Kvalitetssikring: Alle planlagte og systematiske aktiviteter som er iverksatt som en del av kvalitetssystemet og påvist som nødvendig for å skaffe tilstrekkelig tiltro til at en enhet vil oppfylle kravene til kvalitet. 12. Dårlig arbeidsmiljø: Det er viktig at vi arbeider i et miljø hvor de fleste skal trives og holde seg motivert med hverandre, jobber effektivt, da blir det mindre sykefravær og holde seg i bra form, men dersom hvis vi har et dårlig arbeidsmiljø da er det stort problem og alle de punktene vi har nevnt ovenfor kommer til fungere motsatt. 13. Strømbrudd: Dersom det blir strømbrudd mens vi jobber med prosjektet er det viktig at man har tatt back up og har ladet pc(bærbar) batterier. 14. Brann: I tilfelle det skjer brann er det viktig at man bruker de riktige utganger, vite hvor brannslukningen er og kommer seg ut av brente området for å unngå røyk skade og varsler brannvesenet. 15. Mangel på utstyr: Gruppen må sikre seg om nødvendige utstyr de trenger til prosjektet arbeidet og det er viktig at gruppemedlemmer ikke glemmer laderen til bærbar pc-en dersom de skal bruke bærbar. 16. Oppgavegiveren trekker seg: Dersom er arbeidsgiveren trekker seg fra prosjekt er det veldig viktig at fra og med starten skal både gruppen og arbeidsgiveren har skrevet kontrakten i tilfelle arbeidsgiveren trekker seg så har gruppen en kontrakt hvor de skal følge prosedyrene ut i fra kontrakten. 17. Dårlig planlegging: En viktigste del av prosjektet er å planlegge på riktig måtte slik at man har en langsiktig oversikt over ting som skal gjøres og leveres til kunden, hvis man havner i en dårlig planlegging av prosjektet, da blir det vanskelig å komme i gang og prosjektet vil ikke fungere på den måten gruppen har planlagt. Hovedprosjekt 2011 Side 23 av 42 Gruppe 4

25 Utviklingsprosess 9 Om utviklingsprosessen 9.1 Valg av prosessmodell Valg av prosess modell under utvikling av et prosjekt er avhengig av type prosjekt. Det er prosjektets størrelse og omfang som setter opp grunnlaget for valget av utviklingsmodellen. I vårt prosjekt K-Skjemaer trenger vi en iterativ modell som kan gi oss fleksibiliteten til å dele systemet til mindre systemdeler(iterasjoner), få tilbakemeldinger på leverte systemdeler og eventuelt endre på det før man går videre til neste del. UP(Unified Process) er en iterativ og inkrementell prosessmodell. Modellen blir innført i utviklingsmiljøer for bedrifter i Norge og verden over. UP er en arkitektursentrert og Use- Case drevet prosess. Use-Case modellen dokumenterer kravene og danner grunnlaget for hele utviklingsarbeidet. En prosess beskrives av hvem (utviklere) som gjør hva (artefakter), hvordan (aktiviteter) og når (arbeidsflyt). Men UP inneholder mange aktiviteter som ikke er aktuelle i vårt tilfelle og ville være en tung løsning for oss dersom vi tar med alle aktivitetene. UP-Light(Tilpasset etter eget bruk) er en variant av UP der man kan tilpasse modellen til eget behov. XP(Xtreme Programming) er en systemutviklingsmodell som betegnes som lettvekstmodell for små og mellomstore produkter og utviklingsgrupper. XP-modell er programmeringssentrisk hvilket betyr at det meste dreier seg om programmeringsaktiviteten. Gruppen har besluttet i dette prosjektet å bruke innslag fra flere utviklingsmodeller. Vi mener en kombinasjon av modellene UP-Light(Tilpaset UP) og XP(Xtreme Programming) vil være en god utviklingsmodell for dette prosjektet. Både UP Light og XP er agile utviklings metoder. Med en tilpasset UP-modell der vi tar med fasene fra UP, vil vi kunne ta med aktiviteter som er av betydning for vårt prosjekt uten å utelate nødvendige aktiviteter, utføre utviklingsfasene og kombinere XP-modellen under konstruksjonsfasen der det inngår den største delen av implementeringen(kodingen) og testing. Under konstruksjonsfasen kommer vi til å jobbe med 1, 2,, n iterasjoner. Det er i iterasjonene vi kommer til å bruke XP modellen. Hovedprosjekt 2011 Side 24 av 42 Gruppe 4

26 Utviklingsprosess Figuren under viser UPs livssyklus(puls). Hovedprosjekt 2011 Side 25 av 42 Gruppe 4

27 Oppgavefordeling 9.2 Oppgavefordeling Et prosjekt består av flere hovedaktiviteter og under hver hovedaktivitet kan det ligge ingen, en eller flere nye aktiviteter. Det er veldig viktig å organisere oppgavene slik at alle deltar aktivt i de forskjellige aktivitetene slik at vi kan utnytte arbeidsressursen maksimalt. Derfor er det hensiktsmessig å bruke et ansvarskart for rolleavklaring på gitte aktiviteter. Et ansvarskart vil sikre en jevn fordeling av aktiviteter og arbeidsmengde mellom studentene, med hensyn på studie planene for studentene i prosjekt perioden. Et slikt kart vil også holde rede på aktiviteter i forhold til milepælsplanen. Vi har laget et ansvarskart markert med navn på oppgaver, hvem har ansvaret, hva slags ansvar vedkommende har og når må oppgavene være utført. Figuren under viser de forskjellige aktivitetene under ide fasen og utdypningsfasen. For videre faser (Konstruksjon og Sluttfase)har vi brukt innslag av XP utviklingsmodellen der vi har et tettere samarbeid og mer felles ansvar for oppgavene og har derfor ikke ført inn Aktivitetene fra de siste fasene inn i nedenstående tabell. Oppgaver Personer Dato Kamiran Azad Ali Behruz Fremdriftsplan b b Arbeidsplan b b Situasjonsanalyse g g g g Enkel Use-Case B Løsningsforslag g g g g PowerPoint slide B Forprosjektrapport g g g g Detaljert kravspesifikasjon b b Dataflyt-diagram B Use-Case b b ER-diagram br br Risiko anlayse B Klassediagram br br Aktivitetsdiagram b b Bokstav forklaring g - Gruppe arbeid B - Ta en beslutning alene b - Ta en beslutning i fellesskap R Må rådspørres Hovedprosjekt 2011 Side 26 av 42 Gruppe 4

28 9.3 Utviklingsfase og aktiviteter Prosessrapport Utviklingsfase Som nevnt tidligere i rapporten, har vi valgt å bruke en kombinasjon av UP-light(tilpasset UP) og XP(Xtreme Programming) som utviklingsmodell. Dette er en tilpasset versjon av UP og innslag av XP sammensatt etter prosjekt behovet. Fasene som inngår i denne modellen er idefase, utdypningsfase, konstruksjonsfase og overgangsfase. Hoved aktivitetene som finnes i de ulike fasene og arbeidsflyten har vi illustrert i følgende figur. Ide fasen kjent også som forprosjekt ved godkjenning, er en prøveversjon av et større prosjekt som er lansert til en liten gruppe av brukere eller til et bestemt geografisk område. Fasen består først og fremst av lønnsomhetsvurderinger og beslutninger om prosjektets omfang. En forprosjektrapport inneholder: Presentasjon av prosjektet, gruppen og oppgavegiveren. Et kort sammendrag av prosjektet En kort beskrivelse av oppgavegiveren/organisasjonen Hvordan er dagens situasjon hos oppgavegiveren Hovedprosjekt 2011 Side 27 av 42 Gruppe 4

29 Utviklingsfase En beskrivelse av mål og rammebetingelser Et løsnings forslag til prosjektet Analysere løsningen Gruppens konklusjon En skisse av arbeidsplan og fremdriftsplan I forprosjektrapporten levert den har vi tatt med alle nevnte punkter og har med dette klart å få med hovedpunktene i dokumentasjonsstandarden. Standarden er utarbeidet av førstelektor Ann-Mari Torvatn ved høgskolen i Oslo. Aktivitetene fra Idefasen i form av Gant-Diagram. Link til forprosjektrapport: Hovedprosjekt 2011 Side 28 av 42 Gruppe 4

30 Utdypningsfase/konstruksjonsfase 9.3a Utdypningsfase Kjent også som Startfase. Dette er en analyse fase på system nivå. Her har vi laget alle modeller som innvirker på systemet som en helhet. Under utdypningsfasen har vi foretatt en grov analyse som innebefatter følgende: Detaljert kravspesifikasjon. Detaljert Use Case-modell. ER-diagram. Aktivitetsdiagram Klassediagram. Risiko analyse. Alle krav og Use Case-diagram ligger detaljert i dokumentet kravspesifikasjon. Aktivitetene fra Utdypningsfasen i form av Gant-Diagram 9.3b Konstruksjonsfase Kjent også som gjennomføringsfasen. Fasen består vanligvis av flere iterasjoner, dette bestemmes av prosjekt størrelse og omfang, her har vi delt fasen til fire iterasjoner, hvor hver iterasjon inneholder alle de vanlige livsyklusfasene som analyse, design, implementering og testing. Det er her vi har realisert produktet og testet funksjonalitetene til produktet som en del av kvalitetssikring. Under den fasen har vi brukt innslag fra XP utviklingsmodellen ved aktivitetene implementering og testing. Hovedprosjekt 2011 Side 29 av 42 Gruppe 4

31 Planlegging av iterasjoner Modellen som nevnt tidligere i rapporten er en programmeringssentrisk hvilket betyr at det meste dreier seg om programmering og testing. Vi har foretatt analyser ved starten av hver iterasjon, kodet litt, testet det vi har kodet, integrert det vi har kodet så kodet mer og testet igjen før vi har integrert det også, og til slutt dokumenterte det vi har gjort i den iterasjonen. Her har vi jobbet stort sett to og to, ellers har vi hatt et tett team samarbeid. Aktivitetene fra Konstruksjonsfasen i form av Gant-Diagram 9.4 Planlegging av iterasjoner En iterasjon er et miniprosjekt som har en fastsatt varighet, alle iterasjoner har vanligvis lik eller nesten lik tidsramme (timeboxing). I hver iterasjon har vi plukket en del av kravene som skal realiseres, her har vi tatt en sekvensiell fordeling hvor vi har begynt med krav om registrering, så endringer osv.. Vi startet første iterasjon i samarbeid med oppdragsgiveren. Vi foretok analyse, design, implementering od testing. Ved slutten av hver iterasjon har vi hatt avtaler med oppdragsgiveren hvor vi viste resultatet og samtidig har vi hatt brukervennlighets testing med oppdragsgiveren og brukere av systemet for eventuelt ønsker om forandringer. Ved slutten av hver iterasjon har vi rettet på tilbakemeldinger fra oppdragsgiveren, det har stort sett ikke vært store endringer. Ellers har vi avsluttet iterasjonen med en planlegging av neste iterasjon. Iterasjoner blir integrert i systemet, Systemet vokser ved slutten av hver iterasjon og blir til et ferdig produkt ved slutten av siste iterasjon. Aktivitetene fra Konstruksjonsfasen i form av Gant-Diagram Hovedprosjekt 2011 Side 30 av 42 Gruppe 4

32 Planlegging av iterasjoner 9.4a Første Iterasjon Analyse og krav Førstegangs bruk av produktet. Innloggings system. Registrere ny data. E-post til brukere. Design Grafisk Brukergrensesnitt(GUI) for applikasjonen med(template)for Admin/Avdelinger. Innloggings vindu. Logg ut vindu. Registrering av nye brukere. Registrering av Enheter, Stillinger, Adgangskort, Nøkler. Implementering Arkitektur. Database. Klasser og objekter. Realisering av punkter nevnt i Analysen. Implementere punktene nevnt i Design. Vi har i løpet av denne iterasjonen opprettet tabellene i databasen, opprettet funksjonen for førstegangsbruk av systemet, sikker innloggingssystem, grafisk brukergrensesnitt for Admin og Avdelinger, registrering av systembrukere, utsendelse av e-post ve ny registrering av system brukere. Registrering og endring av Enheter, Stillinger, Adgangskort og Nøkler. Testing Enhetstesting. Integrasjonstest. Brukertest (brukeren her er brukere fra UNE). Planlegging av neste iterasjon. 9.4b Andre iterasjon Analyse og krav Gjennomgang av tilbakemeldinger. Tiltredelse. Intern endringer. Passord og innstillinger. Hovedprosjekt 2011 Side 31 av 42 Gruppe 4

33 Planlegging av iterasjoner Design K-Skjema Tiltredelse. K-Skjema Intern endringer. Hjem-innstillinger. Implementering Redigering ved eventuelt tilbakemeldinger fra forrige iterasjon. Realisering av punkter nevnt i Analysen. Implementere punktene nevnt i Design. Vi har i løpet av denne iterasjonen endret generering av passord ved ny brukerregistrering fra selv til automatisk generert passord og endret primærnøkkelen i systemet fra fødselsnummer med 11 siffer til en sammensatt nøkkel av fødselsdato med 8 siffer, fornavn og etternavn som følge av en tilbakemelding fra oppdragsgiveren. Og har i tillegg opprettet Tiltredelsesskjemaet, Intern endringsskjemaet for både Admin delen og Avdelingsdelen. Og muligheten for brukere til å endre passord ved innstillinger. Testing Enhetstesting. Integrasjonstest. Brukertest (brukeren her er brukere fra UNE). Planlegging av neste iterasjon. 9.4c Tredje iterasjon Analyse og krav Gjennomgang av tilbakemeldinger. Fratredelse. Søkemotor. Design K-Skjema Fratredelse. Implementering Redigering ved eventuelt tilbakemeldinger fra forrige iterasjon. Realisering av punkter nevnt i Analysen. Implementere punktene nevnt i Design. Hovedprosjekt 2011 Side 32 av 42 Gruppe 4

34 Planlegging av iterasjoner Her var det ingen ønsker om endringer. Vi har opprettet Fratredelse skjemaet, og søke motor med mulighet for søk etter ansatt med fornavn, etternavn og fødselsdato.. Testing Enhetstesting. Integrasjonstest. Brukertest (brukeren her er brukere fra UNE). Planlegging av neste iterasjon. 9.4d Fjerde iterasjon statistikk og skisse av ferie kalender. Analyse og krav Gjennomgang av tilbakemeldinger. Fratredelse. Søkemotor. Design Statistikk. Skisse av feriekalender. Implementering Redigering ved eventuelt tilbakemeldinger fra forrige iterasjon. Realisering av punkter nevnt i Analysen. Implementere punktene nevnt i Design. Her var det ingen ønsker om endringer fra forrige iterasjon. Vi har opprettet muligheten for å liste alle aktive ansatte og muligheten for å liste ansatte fra tidligere arkiv. Og funksjoner til å vise mer detaljer av ansatte. Vi har leget skisse av feriekalender for eventuelt videre utvikling. I tillegg til kravene har vi selv funnet på funksjonen NOTATER som vi synes vil være til stor hjelp for administrator. Dette er en mulighet for å lagre notater for så o se på i ettertid. en bra funksjon som Testing Enhetstesting. Integrasjonstest. Hovedprosjekt 2011 Side 33 av 42 Gruppe 4

35 Brukertest (brukeren her er brukere fra UNE). Ytelsestest. Prosessrapport Overgangsfase Dette var den siste iterasjonen. Da ble det ikke mer planlegging for neste iterasjon og dette var slutten for konstruksjonsfasen. 9.5 Overgangsfase Kjent også som Sluttfase. Dette er den siste fasen ved prosjektet. Det er her produktet verifiseres og leveres som et ferdig stilt produkt. Her ble vi ferdig med normal programmering, endringer i programvaren var kun for å endre feil som ble funnet etter hvert. Det er i denne fasen man foretar idriftsettelse av produktet. Hensikten med en god planlagt idriftsettelse er å skape en god og flytende overgang fra det gamle til det nye systemet, Her ville vi normalt ha integrert det ferdige produktet i UNE s systemer og foretatt opplæring av brukere. Vi hadde planlagt å sette opp en plan for overgang fra gamle til nye systemet med en parallell idriftsettelse av systemet med en periode på 2 måneder. Av sikkerhetsgrunner har vi ikke hatt muligheten til å kunne integrere produktet selv, vi har derfor laget installasjons instruksjoner for oppdragsgiveren på hvordan de kan installere og integrere produktet. Under denne fasen har vi testet programmet som helhet og lagret mye data som kan testes på for sensur. Aktivitetene fra Overgangsfasen i form av Gant-Diagram Hovedprosjekt 2011 Side 34 av 42 Gruppe 4

36 10 Kravspesifikasjon og dens rolle Prosessrapport Kravspesifikasjon og dens rolle 10.1 Kravanalyse Ved oppstarten av prosjektet har vi brukt innslag fra prosjektforslaget utgitt av Utlendingsnemnda som en overordnet kravspesifikasjon. Forslaget inneholdt en beskrivelse av ønsket produkt. Under utdypningsfasen har vi hatt en grov analyse av kravene og visualisert dem i brukertilfeller. Krav formuleringen har vært av en stor betydning for produktutviklingen, formuleringen har ikke vært en enkel oppgave å utføre siden det var forskjellige ønsker fra de forskjellige systembrukere. Fordi krav må være realistiske og det må tas hensyn på tidsrammen måtte vi ha flere møter med oppdragsgiveren for å kunne fastsette hovedkravene til produktet. En mer detaljert beskrivelse av kravene ligger i rapporten kravspesifikasjon. Link til rapporten: Endringer i kravspesifikasjon Endringer i kravene har forekommet i løpet av utviklingsperioden, ved utgangen av hver iterasjon har vi hatt møter med oppdragsgiveren som en del av aktivitetene i prosessmodellen der vi hadde en gjennomgang av produktet og sammenlignet produktet med kravene. Der har det i løpet av første iterasjon kommet endringer om endringer av hvordan ett passord blir generert, og endringer primær nøkkel bruk av fødselsdato fra 11 siffer til 8 siffer. Ellers har det ikke vært store endringer i kravene. Hovedprosjekt 2011 Side 35 av 42 Gruppe 4

37 Resultat 11 Resultat 11.1 Hva ble resultatet Alle kravene til produktet har blitt utfylt, produktet blir sett som en god løsning og produktet kommer til å erstatte dagens ordning hos UNE. Resultatet av prosjektet ble som forventet. Det ble gode tilbakemeldinger på brukervennligheten og organiseringen av data. Produktet er lett å drifte, vedlikeholde og eventuelt videreutvikle men er samtidig bygget på solide og moderne teknologier. Det er ikke helt som vi hadde ønsket å lage, men vi måtte lage det som oppdragsgiveren ønsket. Som for eksempel måten man velger primærnøkkel for å identifisere en ansatt. Vi valgte 11 siffer som er mest vanlig i en så viktig organisasjon bestående av jurister og dommere mens organisasjonen ønsket å lagre 8 siffer siden de hadde lagret 8 siffer fra før. Eller at de kan bestemme selv om de vil sette opp dato på når en ansatt kan begynne å jobbe, bestemme selv om de skal lagre hvilken stilling vedkommende skal ha, eller hvilken enhet han/hun skal jobbe i. Det gjør det lett å lagre feil dato på start eller slutt dato. Det kan være til fordel med litt mer funksjonalitet på produktet. Vi klarte å legge til en fin funksjon NOTATER som kan være til stor hjelp som en huskelapp for administrator. Vi hadde ønske om å legge til enda mer funksjonalitet, men tiden vi hadde var dessverre ikke nok, og vi vil nevne også at oppdragsgiveren var veldig treg med opplysninger. I flere anledninger når vi hadde spørsmål, har vi ventet på å få svar fra dem og det tok 1-2 eller 2-3 uker før vi fikk svar fra dem eller at vi ikke fikk svar idet heletatt. Vi kunne ha laget en feriekalender løsning for dem hvis de hadde vært flinkere til å kommunisere med oss. Men vi er stolte av å si at vi har klart å lage en fin skisse hvor de kan implementere det i systemet. Vi har som nevnt tidligere i rapporten klart å legge til funksjoner og forbedret de gamle skjemaene ved å legge til nye datafelter som ikke var lagret i det gamle systemet, for eksempel i det gamle systemet hadde ikke UNE lagret noe adresse for en ansatt, heller ikke privat telefon eller privat e-postadresse. Dette skapte problemer når de ønsket å ta kontakt med utenfor arbeidstiden Skisse til videreutvikling for oppdragsgiver Som svar på et ønske fra oppdragsgiveren på en skisse av en feriekalender har vi laget følgende skisse som kan gjøre jobben enklere for en utvikler å implementere det i systemet. Feriekalenderen fra nåværende system er en tung løsning, for hver ny ansatt må kalenderen oppdateres manuelt, og ved hver endring må dette skje manuelt igjen. Dette er mye arbeid at hele kalenderen må oppdateres ved hver endring. Hovedprosjekt 2011 Side 36 av 42 Gruppe 4

38 Resultat Denne skissen skal kobles til skjemaene som en del av systemet. Feriekalenderen skal oppdateres ved hver registrering i k-skjemaene, oppdateringen skal skje automatisk men det er mulighet til manuell editering. Følgende er en trinnvis plan på hvordan dette kan implementeres. 11.2a Presentasjonsfiler Figur1 viser filene som inngår i kalenderen. Master page øverst til høyre med markert innholdssider(contentplaceholder)og en separat innholdsside til venstre som skal være innholdssiden, og tilslutt en(feriekalander.aspx) side sammensatt av master page og innholdssiden. I menyen øverst på master page har vi lagt til en link(feriekalander) som navigerer til Ferikalender.aspx. Figur b Presentasjonssider Figur 2 viser hvordan ferieklander kan se ut. Vi har delt opp feriekalander i forskjellige deler, i punkt 1 har brukeren en liten kalander som viser oversikt over måneder i året, brukeren kan velge hvilket år og hvilken måned man vil se på. I punkt 1 har vi valgt året 2011, måned mai og både i punkt 1a og punkt 2 ser man at kalanderen blir oppdatert til mai måned. I punkt 3 kan brukeren velge mellom å vise kalanderen i form av uke, måned eller dag som blir Hovedprosjekt 2011 Side 37 av 42 Gruppe 4

39 Resultat oppdatert i punkt 2. Punkt 3 viser menyen hvor brukeren kan opprette, endre og slette ferie for ansatte. I menyen har brukeren mulighet for å se ferie aktiviteter/statistikken eller endre innstillinger. Punkt 4 viser menyen hvor brukeren har muligheten til å søke etter en ansatt om han er på ferie eller på jobb. Liste alle ansatte som er på ferie eller på jobb ved å trykke på linkene Ansatt på ferie eller Ansatt på jobb. Brukeren kan liste helligdager eller eventuelt ferie dager ved å trykke på linkene fra menyen. Vi har laget noe skisse for funksjonalitetene i feriekalanderen, men andre funksjonalitetene kan utvikleren selv bestemme hvordan brukergrensesnittene(gui) kan se ut. Figur c Opprette ferie for ansatt Figuren nedenfor viser et skjema for registrering av ferie for en ansatt. Skjemaet består av tittel, startdato og sluttdato. Dato kan velges fra kalander vist til høyre for tekstfeltet. Notat kan brukes ved å begrunne ferien, autorisert feltet brukes for å kunne se hvem som har tildelt ferien. Forespurt feltet er for vedkommende som tar ferie. Alle feltene Hovedprosjekt 2011 Side 38 av 42 Gruppe 4

40 Resultat som er markert med rød stjerne foran (*) er obligatoriske felter som må fylles ut for at ansatt kunne ta ferie. I figuren nedenfor har vi tatt et eksempel på hvordan administratoren kan fylle ut de forskjellige feltene. Lagre knappen oppretter ferien for vedkommende ansatt i ferietabellen i databasen og sender en bekreftelse til vedkommende via e-post. Avbryt knappen benyttes for å nullstille skjemaet og avbryte operasjonen. Figur d Ansatte på ferie I figur 4 har vi laget skisse for de ansatte som er på ferie og lister dem i form av en tabell. Trykk på linken Ansatt på ferie og punkt 2 viser hvor mange ansatte som er på ferie i en tabell. Tabellen består av fornavn, etternavn, startdato, sluttdato og varighet. Dersom administratoren vil sorterer ansatte med fornavn klikker administratoren på Fornavn og tabellen blir oppdatert alfabetisk. Det gjelder også etternavn, startdato, sluttdato og varighet. I tilfelle hvis det er mange som er på ferie og tabellen har mange rader vil resultatet deles i flere sider, likene forrige og neste brukes for å gå til forrige eller neste side. Hovedprosjekt 2011 Side 39 av 42 Gruppe 4

41 Resultat Figur e Ansatt på jobb Figuren nedenfor viser ansatte som er på jobb og har samme brukergrensesnitt som punktet ovenfor. Men i dette tilfelle har vi listet ansatte med fornavn og etternavn. Utvikleren selv kan velge hva som blir listet i tabellen. Figur 5 Hovedprosjekt 2011 Side 40 av 42 Gruppe 4

42 Resultat 11.2f Kalender I figur 6 ser på vi feriekalanderen med detaljer. Fra kalanderen velger vi juli 2011 som er vist på punkt 1. Punkt 2 viser kalanderen for hele juli måned med dag og dato. For å se hvem som er på ferie den 01.juli.2011, klikker man på juli 1 og i figuren 8 viser de som er på ferie den den dagen i form av tabell. Punkt 3 viser hvilken måned vi har valgt. Figur 7 Figur 8 Hovedprosjekt 2011 Side 41 av 42 Gruppe 4