1. Prosessrapport. Experior - rich test editor for FitNesse -

Størrelse: px
Begynne med side:

Download "1. Prosessrapport. Experior - rich test editor for FitNesse -"

Transkript

1 1. Experior - rich test editor for FitNesse -

2

3 1.1. Forord Denne rapporten inneholder dokumentasjon av prosessen og gruppens arbeid, i form av informasjon om blant annet bakgrunn for prosjektet, mål, rammebetingelser, planlegging og gjennomføring. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan selvfølgelig også leses av andre som måtte finne det interessant. Den er optimalisert for papir. Det forutsettes at leseren har erfaring i bruk av PC som verktøy, og gjerne også noe kjennskap til programmering og utvikling. Teknisk informasjon er for øvrig utelatt fra denne rapporten i så stor grad som mulig, men er tatt med der vi mener det er nødvendig for sammenhengen. For teknisk informasjon om Experior henviser til produktrapporten. Enkelt ord og uttrykk er bevisst ikke oversatt fra engelsk til norsk. Dels fordi det ofte mangler fullgode norske oversettelser, men også fordi det skal være lettere for leseren å søke mer informasjon om enkelte emner dersom dette skulle være ønskelig. For best sammenheng anbefales det at rapporten leses i kronologisk rekkefølge. Informasjon om testingen som er gjennomført vil være sentral informasjon for de som eventuelt skal videreutvikle prosjektet. Derfor er dette en integrert del av produktrapporten. Hensikten med prosjektet har vært å utvikle en ny teksteditor for FitNesse, et eksisterende verktøy som brukes for å teste applikasjoner. Derav undertittelen rich test editor. Gruppen tok selv initiativ ovenfor Bekk Consulting og ytret ønske om å gjennomføre hovedprosjekt hos dem. Vi vil i den forbindelse rette en takk til Bekk for å ha gitt oss denne muligheten. 2

4 1.2. Innhold 1.1. Forord Innhold Innledning Om bedriften Bakgrunn for oppgaven Hva er FitNesse? Situasjonen ved prosjektstart Mål Rammebetingelser Valg av hovedprosjekt Smidige utviklingsmetoder og Scrum Bakgrunn Scrum som metode Scrum i praksis Forberedelser, planlegging og prosjektstyring Oppstart og forberedelser Valg av løsning og teknologi Organisering Prosjektstyring Verktøy og versjonshåndtering Utviklingsprosess og gjennomføring Veiledning og samarbeid Kravspesifikasjonen og dens rolle Scrum i vårt prosjekt Estimering Mønster (pattern) Hovedutfordringer Iterasjonsbeskrivelse Iterasjon 0 (uke 2 3) Iterasjon 1 (uke 4 5) Iterasjon 2 (uke 6 7) Iterasjon 3 (uke 8 9) Iterasjon 4 (uke 10 11) Iterasjon 5 (uke 12 14) Iterasjon 6 (uke 16 17) Iterasjon 7 (uke 18-19) Oppsummering Produktet Prosess Referanser/kilder

5 4

6 1.3. Innledning Om bedriften Bekk Consulting A/S er et norsk konsulentselskap med 210 ansatte. Bekk leverer tjenester innen rådgivning, teknologi og forvaltning til store offentlige og private virksomheter. Et utvalg av Bekks kunder er Telenor, Gjensidige, Norwegian og NAV. Bekk har avdelingskontorer i Oslo og Trondheim Bakgrunn for oppgaven Bekk Consulting har prosjektengasjement hos Bankenes Betalingssentral, BBS. På dette prosjektet benyttes et testverktøy kalt FitNesse, som har vært utgangspunktet for vår oppgave Hva er FitNesse? FitNesse er et verktøy som brukes til testing av applikasjoner. Det kan benyttes for at kunden, i samarbeid med utvikleren, selv skal kunne verifisere at applikasjonen oppfyller kravene som er spesifisert. I prosjektet hos BBS har BBS egne dedikerte testere, som bruker FitNesse til å teste et system som utvikles av blant annet Bekk Consulting. Kommunikasjonen med brukeren skjer gjennom et webgrensesnitt, hvor man kan opprette, redigere og kjøre tester mot en applikasjon. Testene skrives inn i FitNesse som ren tekst i en svært enkel teksteditor, med en wikisyntaks. Ved å følge denne syntaksen bygges testene opp i en type tabell. I disse tabellene skriver testeren input til applikasjonen og hva som forventes som output. Når testen gjennomføres blir det sammenlignet hva som faktisk ble returnert fra applikasjonen opp mot det som var forventet. Hvis det som var forventet stemmer overens med det som ble returnert er testen passert og den funksjonen som ble testet fungerer etter kravet. FitNesse er særlig utbredt ved bruk av testdrevet utvikling og smidige utviklingsmetoder. Her i Norge benyttes det blant annet av, som nevnt, Bekk og BBS, Bring (tidligere Posten), Statens Pensjonskasse, KnowIT og Kantega i tillegg til en rekke andre i Norge og resten av verden. Gjennom FitNesse synliggjøres tester for andre enn utviklere. Testene kan skrives med vanlig språk, det vil si lite til felles med programmeringsspråk som benyttes og forstås av utviklere. Dette gjør at for eksempel kunder og andre interessenter kan bla rundt i tester, lese hva de utfører, og selv kjøre 5

7 dem for å verifisere at systemet faktisk oppfyller kravene de har spesifisert. De som skriver testene er ofte dedikerte testere uten programmeringsbakgrunn. I BBS-prosjektets tilfelle har de imidlertid en enorm kompetanse om hvilke krav systemet må oppfylle. Med FitNesse kan disse kravene spesifiseres i form av tester med et språk som testerne forstår. Dersom testen passerer er kravet oppfylt. I tillegg fungerer dette som en utmerket dokumentasjon, da testen er en helt konkret spesifikasjon av hva systemet gjør. Denne dokumentasjonen er også kontinuerlig oppdatert, i motsetning til det som kan være tilfelle med annen dokumentasjon. Der kan det hevdes at et system møter et spesifikt krav, men man har ikke noe bevis. FitNesse derimot, beviser at systemet faktisk gjør, eller ikke gjør, det som er spesifisert Situasjonen ved prosjektstart For en bruker ser og oppfører FitNesse seg tilnærmet som en vanlig nettside som vises i en nettleser. Testene har hittil blitt skrevet inn som ren tekst i en enkel teksteditor i FitNesse. Den har ingen funksjonalitet ut over muligheten til å lagre og å importere tabeller fra regneark fra Excel og lignende. Teksten vises helt uten støtte til brukeren i form av for eksempel variasjon i tekstfargeog størrelse eller kontroll av om det brukeren skriver inn er korrekt. Teksteditoren er vist i figur 1. Figur 1: Test vist i FitNesses egen editor Tester kan bli store dokumenter, både i lengde og bredde. Som nevnt skrives testene i dag med en wikisyntaks. Dette, kombinert med at editoren ikke gir noen støtte til brukeren, gjør at testene lett blir uoversiktlige og redigeringen av tester blir vanskelig. 6

8 Oppdragsgiver ønsket dermed en forbedret editor for skriving av tester. Dette var utgangspunktet for oppgaven og vårt hovedprosjekt Mål Hovedmålet for oppgaven ble derfor å utvikle en forbedret teksteditor for FitNesse, med navn Experior. Hvilke forbedringer den nye editoren skulle inneholde var ikke fullstendig definert fra oppdragsgiver, men det ble lagt frem følgende ønsker til hovedfunksjonalitet: Forbedret tabellredigering ved at piper, som brukes for å definere kolonner i tabeller i testene, automatisk settes under hverandre. Denne funksjonaliteten er heretter kalt aligning. På denne måten blir tabellene, særlig større tabeller, mer oversiktlige. Autofullføring av metodenavn, basert på programkoden som testen skal kjøres mot. Syntaks highlighting. For konkretisering av disse og andre krav henviser vi til kravspesifikasjonen. I tillegg ble det satt hovedmål som vi som gruppe kunne oppnå i løpet av prosjektet: Få erfaring i å gjennomføre en systemutviklingsprosess langt større enn det vi til nå har gjennomført, både med tanke på dokumentasjon, utvikling, samarbeid og presentasjon. Lære, for oss, nye teknologier, metodikker og språk. Få erfaring i å samarbeide med en reell oppdragsgiver Rammebetingelser For å kunne være i stand til å implementere det som var ønsket var det nødvendig at vi som utviklere skaffet oss god kjennskap til FitNesse. Både om hvordan det brukes rent praktisk, men også om programkode og oppbygging. Vi stod veldig fritt i valg av teknologi og løsninger. Siden det ble bestemt at vi skulle utnytte det eksisterende webgrensesnittet til FitNesse (mer om begrunnelse for dette i punkt 1.5.2) måtte Experior lages i en teknologi som egnet seg for web. I tillegg var det også ønskelig at det ikke skulle være nødvendig med nye rammeverk eller teknologier, verken i selve FitNesse eller hos brukeren, for at løsningen skulle fungere. 7

9 FitNesse er skrevet i Java, og selve integrasjonen av Experior inn i FitNesse måtte derfor gjøres i Java. Oppdragsgiver ønsket at Experior skulle gjøres tilgjengelig med lisens for åpen kildekode. Dersom det skulle brukes elementer fra andre prosjekter med åpen kildekode måtte dette selvfølgelig gjøres på korrekt måte i forhold til lisensen på de aktuelle prosjektene. Som prosessmodell for utviklingen har vi brukt Scrum, som er en agil metode. Vi valgte Scrum fordi Scrum er i utstrakt bruk som prosessmodell for mange store utviklerfirmaer, som for eksempel oppdragsgiveren vår Bekk Consulting. I tillegg var det et ønske fra oppdragsgiver. Mer om denne modellen følger senere i rapporten. Vi stod i utgangspunktet fritt til å velge verktøy som skulle benyttes i utviklingen, men med tanke på eventuell videreutvikling av Experior etter prosjektslutt var det en fordel hvis vi benyttet verktøy som oppdragsgiver benytter og er godt kjent med. Prosjektperioden har gått over 21 uker. Viser her til arbeids- og fremdriftsplan Valg av hovedprosjekt Gruppen ønsket å ha hovedprosjekt hos en bedrift som har utvikling av datasystemer som en del av sin kjernevirksomhet. Derfor rettet vi henvendelser til bedrifter som Bekk Consulting, Capgemini og ErgoGroup i november 2008 med tanke på samarbeid om hovedprosjekt. Bekk Consulting ga raskt uttrykk for at de var positive til dette og presenterte forslaget til oppgaven rundt FitNesse. Vi hadde et ønske om et reelt prosjekt, og ikke noe som var funnet på fra bedriftens side. FitNesse brukes i dag på flere prosjekter, blant annet hos vår oppdragsgiver Bekk, og dermed var det stor sannsynlighet for at Experior ville bli tatt i bruk i praksis. Dette har vært en stor motivasjon for oss. JavaScript (herunder AJAX) og webteknologier generelt var noe gruppen hadde begrensede kunnskaper om på forhånd. Denne oppgaven ga mulighet for å få mer innsikt i dette og dermed muligheten til å lære noe nytt gjennom hovedprosjektet. Samtidig kunne dette kombineres med Java, som gruppen hadde et ønske om å få mer dyptgående kunnskap om. I tillegg ga det oss muligheten til å lære et testverktøy (FitNesse) som er i utstrakt bruk. Alt i alt ga altså dette hovedprosjektet oss mulighet for å lære ikke bare nye 8

10 teknologier, men også, for oss, hittil ukjente verktøy. Dette var grunnen til at vi valgte å jobbe videre med dette prosjektet Smidige utviklingsmetoder og Scrum Siden vi har valgt å bruke Scrum som prosessmodell i vårt hovedprosjekt, så vil vi derfor skrive litt om denne modellen og hvorfor vi mener den ofte egner seg bedre, særlig for enkelte typer prosjekter, enn mer tradisjonelle metodikker Bakgrunn Det har vært en voldsom utvikling fra dataverdenens tidlige spede begynnelse til vår komplekse og sofistikerte verden slik vi kjenner den i dag. I begynnelsen tenkte vel ingen programmerer at programmering og applikasjoner skulle bli så sofistikerte og komplekse som de som utvikles i dag. Kravene til applikasjonene som utvikles blir større og større. Enkelte ser på utvikling av software som å bygge hus, at man starter med planlegging, tegninger, grunnmur, 1. etasje og så videre. Man kan se på disse fasene som et fossefall der en fase kronologisk etterfølges av den neste. Dermed kalles dette fossefallmetoden. I denne modellen er det ikke mulig underveis å gå tilbake for å endre eller utvide kravene som har blitt spesifisert. Dette er ofte ikke hensiktsmessig for utvikling av datasystemer, og det har vært, og er i mange tilfeller, behov for å tenke nytt og endre på modellene som benyttes i utviklingsprosessen. Både med fossefallsmodellen og med mer avanserte modeller som for eksempel RUP (Rational Unified Process) brukes mye tid på modellering og dokumentasjon, særlig før selve programmeringen starter. Dette er ikke alltid hensiktsmessig for alle typer prosjekter: 1. Bedriftene som driver med utvikling får ofte ikke penger for dokumentasjonen. Det er produsert kode og et fullverdig system som kundene er villige til å betale for. 2. Det viser seg ofte at ting må forandres i implementeringsfasen. Dermed har man brukt mye tid og ressurser på å dokumentere et system man trodde ble sånn og slik, men som ikke ble det likevel. I tillegg finnes mange applikasjoner som aldri blir ferdige i tradisjonell betydning, men hvor det stadig dukker opp nye krav og ønsker til funksjonalitet. Det beste 9

11 eksemplet er vel GMAIL som har befunnet seg på betastadiet siden tjenesten ble tilgjengelig for ca fem år siden. Softwareutvikling kan vanskelig sammenlignes med for eksempel bygging av en bro eller et hus. Når et hus først er designet i et prosjekt så vil det ikke endre seg dynamisk etter hvert som byggingen forgår. Dette er som oftest heller ikke teknisk mulig. I softwareutvikling har man imidlertid rent teknisk muligheten til å foreta kontinuerlige endringer og det er derfor hensiktsmessig å bruke utviklingsmetoder som også legger til rette for det Scrum som metode Som et alternativ til mer tradisjonelle metoder som fossefall og RUP har det dukket opp agile (smidige) metoder. Agile metoder har eksistert i mange år, men ikke fått skikkelig fotfeste før i de senere år. Mange har sett på agile metoder som noe bare hobbyprogrammerere kunne bruke. Men nå har agile metoder fått sin rennesanse for fult, de fleste store firmaene har tatt i bruk agile metoder, som for eksempel Scrum. Følgende analogi kan benyttes for å illustrere prinsippet: A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved." (http://en.wikipedia.org/wiki/scrum_(development)#roles) Analogien er at pig og chicken kan henvises til programutviklerne og kundene og ellers alle som er involvert i hele prosjektet. Utvikleren vil være grisen, siden det er den som er mest involvert i prosjektet, og som dermed må ofre skinken. Kundene kan sees på som hønen, som skal kjøpe et produkt som igjen skal utvikles av en utvikler. Poenget er at Scrum involverer prosjektdeltakerne i stor grad. Ordet Scrum kommer fra et begrep i rugby, fordi det handler om å være sammen om å løse et problem. I rugby har man en kaptein (i Scrum en scrummaster) som oppsummerer progresjonen og hva man har oppnådd. Hovedtanken bak Scrum er at komplekse prosesser håndteres best ved en empirisk tilnærming. Med empirisk mener vi en tilnærming som bygger på erfaring og observasjon. Empiriske metoder krever: 10

12 Synlighet Synlighet betyr at de faktorer som styrer utfallet av prosessen må være synlige for dem som styrer selve prosessen. I tillegg til at faktorene må være synlige, må de også være sanne. Hva betyr det for eksempel at funksjonalitet er ferdig? Kodet i henhold til standarder? Testet? Kan utgis? Inspeksjon De forskjellige delene i en empirisk prosess må kontrolleres ofte nok slik at store avvik fanges opp. Dette forutsetter at den som kontrollerer og følger prosessen må ha kunnskap nok til å fange opp avvikene. Tilpasning Avvik som fører til at produktet ikke blir akseptert må føre til endringer. Endringer må gjøres så fort som mulig for å sikre at konsekvensene blir så små som mulig. Dette kan sammenlignes med Albert Einsteins definisjon av galskap: Å gjøre akkurat det samme om igjen og om igjen og forvente forskjellige resultat. Et prosjekt som drives med Scrum går gjennom flere iterasjoner. Iterasjonene er korte (for eksempel 1-4 uker) og hver iterasjon skal i prisnippet resultere i funksjonalitet som kan tas i bruk av kunden. Dette setter store krav til et tett samarbeid mellom kunde og leverandør. Den store styrken med å jobbe på denne måten er at det allerede tidlig i prosjektperioden sikres at alle aktører har innsikt i prosjektet. Innsikten beholdes gjennom hele prosjektet og sørger dermed for at produktet som skal overleveres, er i tråd med kundens krav og forventninger. Scrum kan innkapsle andre modeller og være den overordnede metoden for å styre et prosjekt. Scrum kan igjen også være innkapslet i andre modeller og være den "indre" metodikken som benyttes for å styre prosjektet Scrum i praksis I Scrum deles utviklingen av et system som nevnt opp i flere kortere iterasjoner. Iterasjonene kan variere i lengde, men vil normalt være av 1-4 ukers varighet. Oppsummert er målet for hver iterasjon å implementere den funksjonaliteten som er til enhver tid viktigst for kunden, og levere et fungerende forbedret system til kunden etter hver iterasjon. I starten av prosjektet lages et dokument kalt prosjektbacklog, som inneholder kundens ønsker og krav til produktet i en prioritert liste. Dette formuleres som 11

13 user stories, typisk på formen Som en bruker vil jeg kunne logge inn med brukernavn og passord og lignende. Prosjektbacklogen kan oppdateres kontinuerlig gjennom hele prosjektet. En sprintbacklog (sprint = iterasjon) lages ved å flytte (i samråd med kunden) punkter fra prosjektbacklog til sprintbacklog. Man velger da ut punkter som det er realistisk å kunne levere i løpet av neste iterasjon. Når sprintbacklog er definert, starter man på selve iterasjonen og utvikler funksjonaliteten. Under en iterasjon møtes utviklingsteamet i daglige, men korte, statusmøter for å rapportere fremdrift, synkronisere sine aktiviteter, og for å sette fokus på problemer og hindringer. User storiene, med deloppgaver, plasseres på en fysisk tavle med papirlapper. Hver oppgave kan befinne seg i fasene to do, in progress, verify og done. Etter hvert som utviklingen går fremover flyttes lappene med oppgaver mellom disse fasene. En iterasjon avsluttes med et møte hvor man går igjennom den leverte funksjonaliteten, presenterer løsningen slik den er, og evaluerer den avsluttede iterasjonen. Deretter starter man en ny iterasjon med et møte for å planlegge og å velge ut punkter fra prosjektbacklog og flytte dem til en ny sprintbacklog. Figur 2: Scrum i praksis I Scrum skal en av prosjektdeltakerne fungere som scrum-master. Denne skal blant annet sørge for at utviklingsteamet holder fokus og sørge for at metodikken følges. I tillegg skal scrum-masteren administrere burn down charts. Dette er et diagram i Scrum som sier noe om faktisk progresjon i forhold til estimert tidsbruk. 12

14 Fordeler ved bruk av Scrum som modell: Kontinuerlig og rask leveranse av fungerende programvare. Fungerende programvare leveres hyppig. Fungerende programvare er lett målbar. Tett samarbeid mellom kunde og leverandør øker sjansen for at kundens ønsker og forventninger oppfylles. Mange kjente store firmaer har tatt i bruk Scrum, for eksempel Bekk Consulting, Finn, Microsoft Norge og Capgemini. Dette viser at Scrum ikke bare er en tekno-flopp, men en seriøs utviklingsmetodikk som store firmaer innen IT har tatt i bruk. Informasjon om bruk av Scrum i vårt prosjekt finnes senere i rapporten Forberedelser, planlegging og prosjektstyring Vårt valg av prosessmodell har gjort at vi ikke har hatt en planleggingsfase i like stor grad som ved tradisjonell organisering, hvor kravene gjerne blir helt fastsatt før implementasjonen begynner. Enkelte grunnleggende elementer måtte imidlertid på plass før vi kunne gå i gang, og disse er det gitt en beskrivelse av her Oppstart og forberedelser Slik oppgaven var definert fra oppdragsgiveren var den nokså åpen. Det var i stor grad opp til oss å komme med forslag til hvordan oppdragsgivers ønsker kunne realiseres, i tillegg til å komme med egne forslag til funksjonalitet. Dermed måtte vi selv på forhånd sette oss inn i hvordan FitNesse kan brukes, for selv å kunne identifisere hvilken funksjonalitet som ville være hensiktsmessig. For å kunne begynne raskest mulig på selve prosjektet ved prosjektstart etter jul begynte vi å sette oss inn i bruken av FitNesse i begynnelsen av desember. På grunn av eksamen i andre fag ble tiden noe begrenset, men det gjorde at vi fikk en effektiv og god start i begynnelsen av januar. Vi stod også fritt i å velge teknologi, tilpasset web. Det var imidlertid ikke ønskelig at det skulle være nødvendig å implementere noen nye teknologier/rammeverk inn i FitNesse for å ta Experior i bruk. For å kunne foreta et valg var det nødvendig å sette seg inn i aktuelle teknologier for at vi kunne velge hvilke vi skulle jobbe videre med. 13

15 Valg av løsning og teknologi Ut i fra måten oppgaven var definert på var det i stor grad opp til oss hvordan sluttresultatet skulle se ut. Det som var klart var at oppdragsgiver ønsket en forbedret teksteditor til å skrive tester i. Oppgaveteksten skisserte et par mulige løsninger på dette: 1. Plug-in til Eclipse 2. Plug-in til FitNesses eksisterende webgrensesnitt En plugin til Eclipse ville vært lite fordelaktig for dedikerte testere som i utgangspunktet ikke har noe med selve programmeringen av systemet å gjøre. Å installere, drifte og kjøre en Eclipse-klient på alle testernes lokale maskiner kun for å skrive tester for FitNesse ville vært lite effektivt. I tillegg ville det blitt nødvendig med en del opplæring samt enda et program å forholde seg til for brukeren. Vi kom også frem til at det ville vært en stor utfordring å finne en smidig kobling mellom Eclipse og webgrensesnittet til FitNesse, som vi mener det ville vært vanskelig å få et godt resultat ut av innenfor tidsrammen til prosjektet. Dette forslaget til løsning ble derfor forkastet, og vi bestemte oss raskt for å lage den nye editoren som en plug-in til selve FitNesse. Oppgaveteksten var ikke spesifikk på om Bekk og BBS ønsket at Experior skulle være en utvidet teksteditor eller ha en WYSIWYG-tilnærming. Sistnevnte ville gitt funksjonalitet der en wiki-tabell ville blitt vist i Excel-format med fysiske tabeller fremfor å vise wikisyntaks i selve Experior. Etter samtaler oss i mellom, veileder og en fokusgruppe i BBS kom vi frem til at selv om dette ville sette terskelen lavere for førstegangsbrukere, er en ren teksteditor mer effektivt enn en løsning som legger opp til utstrakt bruk av mus. I tillegg er den eksisterende fremgangsmåten for å opprette, redigere og kjøre tester godt innarbeidet hos brukerne. Dermed var det ønskelig at den nye editoren skulle legge til rette for at selve fremgangsmåten og måten og bygge opp tester på skulle kunne skje tilnærmet som i dag. Forbedringene i den nye editoren skulle i hovedsak konsentreres rundt eksisterende måte å jobbe på ved å tilby støtte og hjelp til brukeren. FitNesse kjøres på en veldig enkel webserver skrevet i ren Java, uten noe annet rammverk. Det understrekes her ren Java, det vil si tilsvarende som 14

16 benyttes ved utvikling av tradisjonelle frittstående applikasjoner, uten tradisjonell server-teknologi i bunnen. Serveren har naturlig nok ikke støtte for PHP, ASP.NET eller lignende, og det var som nevnt heller ikke ønskelig at det skulle være nødvendig å implementere nye teknologier i FitNesse for å ta Experior i bruk. Dermed var det begrenset hva vi kunne benytte av teknologi. Derfor måtte vi begrense oss til kode som enten kjøres hos klienten, eller direkte i FitNesse sin Java-løsning. Teknologiene bestod da av Java, HTML og JavaScript. Det finnes en rekke rammeverk og hjelpemidler som forenkler utviklingen av JavaScript, og optimaliserer automatisk kode tilpasset alle nettlesere. Noen av disse er Google Web Tookit, JQuery og Prototype. Etter prøving og feiling kom vi frem til at vi måtte bruke ren egenutviklet JavaScript for å oppnå den kontrollen vi trengte over nettleserens funksjonalitet. Vi ville heller ikke være avhengige av eksterne bibliotek for å få den funksjonaliteten vi ønsket. På grunn av store forskjeller i hvordan de ulike nettleserne håndterer JavaScript og hvilken informasjon det er mulig å hente ut og gi nettleseren har vi av hensyn til prosjektets tidsbegrensning valgt å fokusere på Mozilla sin motor, Gecko, som brukes i Firefox. Dette er gjort etter avtale med oppdragsgiver. Det er også implementert noe funksjonalitet for Internet Explorer, men for fullstendig funksjonalitet må Mozilla Firefox benyttes. I en mer tradisjonell nettløsning ville vi forsikret oss om at koden fungerte i alle nettlesere for å nå ut til så mange som mulig, men siden Experior har en relativt begrenset potensiell brukergruppe er løsningen som er valgt hensiktsmessig Organisering Ett eller flere av gruppemedlemmene jobbet med hovedprosjektet hver dag, innenfor normal arbeidstid. Vi har hatt fast møtetid på HiO tirsdag, torsdag og fredag. Denne faste møtetiden mener vi har vært svært viktig for å sikre en jevn progresjon, og vi føler mer ansvar når ting er fastsatt enn om det avtales underveis. Vi har valgt ikke å føre detaljerte timelister. Vi mener det er resultatet ved prosjektlutt som teller, og ikke antallet timer som hver og en har brukt. Samtlige gruppemedlemmer har tatt to eller flere fag dette semesteret, i tillegg til hovedprosjektet. Dette har til tider påvirket hvor mye tid som har blitt brukt på hovedprosjektet. Ingen av gruppemedlemmene har imidlertid tatt de samme fagene, slik at hvis et medlem har vært litt opptatt med et annet fag 15

17 en periode har de to andre hatt mer tid. Derfor føler vi at dette ikke har gått nevneverdig ut over progresjonen underveis Prosjektstyring Helt fra oppstarten har vi vært bevisste på å dokumentere hva som til enhver tid har blitt gjort, i en prosjektdagbok. Ikke nødvendigvis så langt og omfattende, men tilstrekkelig til at vi har holdt oversikt over hva som til enhver tid har foregått og hvilke problemer som vi har møtt på. Denne har vært til stor hjelp i forbindelse med denne prosessrapporten, men også for vår veileder fra Bekk som har kunnet følge progresjonen fra dag til dag. Dagboken er, av hensyn til omfanget, ikke med i denne skriftlige dokumentasjonen, men er tilgjengelig via vår hjemmeside. I tidligere prosjekter har vi sendt dokumenter frem og tilbake på e-post. Dette er en lite effektiv løsning hvor det er risiko for at informasjon går tapt. Derfor har alle prosjektstyringsdokumenter for dette prosjektet blitt lagt ut på et begrenset område på Google Docs, hvor vi, vår interne veileder ved HiO og veileder hos Bekk har hatt tilgang. Gjennom Google Docs har alle kunnet jobbe på samme dokument og det har vært enkelt å spore hvilke endringer som har blitt gjort Verktøy og versjonshåndtering Som utviklingsmiljø har vi benyttet Eclipse. Dette mener vi har vært et hensiktsmessig valg. I og med at dette prosjektet har innebåret programmering i både Java og JavaScript var det hensiktsmessig å kunne foreta all programmering i samme utviklingsmiljø. Ikke minst i forhold til versjonshåndtering. Her har vi benyttet Google Code, som igjen benytter subversion (SVN). Det ble installert en plug-in for Eclipse som muliggjør synkronisering med SVN direkte fra Eclipse. Vi hadde på forhånd varierende kunnskaper om bruk av SVN for versjonshåndtering. Dermed har det vært noe tilvenning og enkelte problemer i starten, men etter hvert som vi har blitt mer fortrolige med verktøyet har dette fungert utmerket. I og med at Experior skulle integreres i et allerede eksisterende system ble det flere avhengigheter til eksterne JAR-bibliotek og lignende i prosjektet. Derfor benyttet vi, etter råd fra veilederen ved Bekk, Apache Maven som prosjektbygger. Maven benyttes i tillegg av Bekk i dag og det er dermed også hensiktsmessig dersom det skal drives videreutvikling av Experior senere. Maven inneholder funksjonalitet for kompilering, testing, rapportering, 16

18 samarbeid og dokumentasjon. Det egner seg svært godt for å holde styr på avhengigheter. Vi hadde ingen erfaring med Maven før prosjektstart, og derfor ble det nokså komplisert og tidkrevende og sette det opp. Her bistod veilederen vår Bekk med god hjelp. Når Maven først var i drift har dette fungert svært godt. For mer utfyllende beskrivelse av benyttede teknologier henvises det til produktrapporten Utviklingsprosess og gjennomføring Veiledning og samarbeid Samarbeidet vårt med veilederen og kontaktpersonen ved Bekk, Rune Flobakk, har vært svært godt gjennom hele perioden. Han har alltid vært tilgjengelig for oss og stilt opp med gode svar på våre spørsmål når det måtte være. Han har vært veldig flink og forutsigbar med å definere kravene og hvilke ønsker som Bekk hadde til dette hovedprosjektet. Måten veilederen ved HiO, Geir Skjevling, har lagt opp veiledningen på har passet oss og denne typen prosjekt svært bra. Han har alltid vært tilgjengelig for oss med raske tilbakemeldinger dersom det var noe vi stod fast på eller ønsket mer informasjon om. Vi har ikke hatt faste møter og tidspunkt, men har henvendt oss til han ved behov. Han har for øvrig hatt tilgang til styringsdokumentene og prosjektdagboken og har kunnet følge progresjonen på den måten. Vi er også godt fornøyd med samarbeidet innad i gruppen, og vi føler vi har utfylt hverandres kunnskaper svært bra. Det ble ikke satt opp noen samarbeidsavtale i forkant, da vi tok det som en selvfølge at vi skulle være profesjonelle nok til å håndtere eventuelle uenigheter som måtte oppstå uten en slik avtale. Dette har vist seg å stemme Kravspesifikasjonen og dens rolle Oppdragsgiver ønsket ikke å fastsette fullstendige krav ved prosjektstart, men derimot formulere disse underveis i prosessen. Dermed var det heller ikke definert en fullstendig kravspesifikasjon tidlig i prosjektet. Oppdragsgiver presenterte tidlig ønsker til hva som kunne være aktuell funksjonalitet. Dette var svært overordnet og har blitt konkretisert og lagt til 17

19 kravspesifikasjonen til gjennom hele prosjektet. Dette har blitt gjort av oppdragsgiver og oss i fellesskap. Veilederen vår ved Bekk Consulting bruker ikke selv FitNesse til daglig, men har god kjennskap til begrensningene i FitNesses egen teksteditor. For å lage et produkt som var mest mulig i tråd med hva de som bruker FitNesse til daglig ønsker har vi gjennomført intervju og observasjon av to testere på BBS, som bruker FitNesse til daglig. Dette ble gjort tidlig i prosjektet, og det var svært nyttig å se hvordan FitNesse blir brukt i praksis. Intervjuet var svært åpent og kombinert med vår observasjon av praktisk bruk ga dette oss god innsikt i hvilke funksjonalitet det ville være hensiktsmessig å implementere. Kravspesifikasjonen har fungert som en rettesnor for overordnede krav. Ut i fra dette har det blitt formulert user stories, som dermed har fungert som en konkretisering og presisering av hva de enkelte kravene til funksjonalitet egentlig har innebåret. Det har blitt laget use case modell av de deler vi mener har vært nødvendig for konkretisering av krav. Se vedlegg D. I og med at kravspesifikasjonen har blitt utformet underveis er det godt samsvar mellom denne og det produktet som beskrives i produktdokumentasjonen Scrum i vårt prosjekt Vi bestemte oss tidlig i prosjektperioden for at vi ville benytte utviklingsmetodikken Scrum, siden vi hadde en unik mulighet til å lære Scrum i praksis gjennom vår veileder fra Bekk Consulting. Oppdragsgiver ønsket at vi skulle komme tidlig i gang med programmering, og ønsket ikke at vi brukte tid på tydelig kravdefinering og modellering med for eksempel UML. Verken i starten eller i prosjektet forøvrig. Vi mener denne tankegangen passer vår type prosjekt svært godt. Tidlig i prosjektet hadde vi liten kunnskap om prosjektet generelt og hadde ikke vært i stand til å lage gode modeller på det tidspunktet. Dermed hadde vi måttet gjøre om disse når vi hadde fått mer kunnskap. Vi mener det har vært langt mer hensiktsmessig å bruke tiden på å skaffe seg kunnskap og drive med selve utviklingen. Generelt har det vært lite fokus på tradisjonell modellering med UML eller E/R i dette prosjektet. E/R er naturlig utelatt da det ikke inngår noen database. Det har blitt laget en overordnet use case modell for konkretisering av krav der vi føler dette har vært nødvendig. I tillegg har det blitt laget et klassediagram for 18

20 den delen av prosjektet som har blitt implementert i Java. Oppdragsgiver har ikke hatt noe ønske eller krav om at UML skulle brukes i det hele tatt, men vi har tatt med de elementene vi føler vi har hatt behov for. Vi har utviklet forslag til funksjonalitet, ut fra aktuelle user stories, og kontinuerlig presentert det for oppdragsgiver, i tråd med ett av prinsippene bak Scrum. Ved å se forslaget til funksjonaliteten i praksis føler vi det har vært mye enklere å drøfte forslag til ny funksjonalitet enn om man kun ser funksjonen beskrevet på et papir. Drøftingen av ny funksjonalitet har foregått kontinuerlig, av typen ja, dette er et godt stykke på vei, men ved å gjøre sånn og slik i tillegg ville det blitt enda bedre og når jeg ser dette kom til å tenke på en annen funksjon som hadde vært svært nyttig og så videre. Etter hvert som funksjonalitet har blitt fullført har denne blitt tatt i bruk av oppdragsgiver underveis. Etter hvert som flere og flere user stories har blitt definert har det blitt definert hvilke oppgaver hver story sannsynligvis ville inneholde. Hver oppgave ble plassert på virtuelle Scrum-tavler 1 i form av virtuelle lapper. Figur 3: En versjon av en av våre virtuelle scrum-tavler 1 På 19

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

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

4. Installasjonsveiledning. Experior - rich test editor for FitNesse -

4. Installasjonsveiledning. Experior - rich test editor for FitNesse - 4. Experior - rich test editor for FitNesse - 4.1. Forord Denne rapporten inneholder installasjonsveiledning for Experior. Experior er tilpasset for installasjon i oppdragsgivers utviklingsmiljø. Det er

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

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

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

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

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495 Charlotte Sjøthun s180495 Nanna Mjørud s180477 Anette Molund s181083 Kravspesifikasjon Android app for aktivering av jakt- og fiskekort Bacheloroppgave vår 2014 Høgskolen i Oslo og Akershus Forord Hensikten

Detaljer

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for

Detaljer

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535)

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Hovedprosjekt 2011 Høgskolen i Oslo Gruppe 24 Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Stian Pettersen (s144449) en RSS-leser på tvers av touchenheter

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

Forprosjekt gruppe 13

Forprosjekt gruppe 13 Forprosjekt gruppe 13 Presentasjon Tittel: Oppgave: Periode: Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Mobilbillett i HTML5 Utvikle en mobil billettautomat innenfor kategorien dedikert web

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

KRAVSPESIFIKASJON FORORD

KRAVSPESIFIKASJON FORORD KRAVSPESIFIKASJON 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

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

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

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

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

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

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11 Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 11 Michael Pande, Petter L. Olsen, Diego A. Pasten 23.01.2015 Presentasjon Vi er en gruppe på tre dataingeniørstudenter som har tatt på oss oppgaven

Detaljer

Båtforening på nett. Produktrapport

Båtforening på nett. Produktrapport Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet

Detaljer

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport Rinnovasjon (Renovasjon og innovasjon) monabjerke.no 2014 Høgskolen i Oslo og Akershus Torbjørn Gjøn s180399 Snorre Duun Strømsborg s180371 Matias Pettersen s180395 Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no Presentasjon Tittel:

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

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

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

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

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

Detaljer

Høgskolen i Oslo og Akershus

Høgskolen i Oslo og Akershus Høgskolen i Oslo og Akershus Gruppe 2 Forprosjektrapport Presentasjon Oppdragsgiver: Prosjekttittel: Definisjon: Accenture Shera Shera er en «event»-applikasjon til Android der man kan registrere arrangementer

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

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 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. 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

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD Forprosjektrapport Feilsøkingsverktøy for Homebase AS INNHOLD Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Funksjonelle krav: Ikke-funksjonelle krav: Løsninger Analyse

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

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Hovedprosjekt i ingeniørfag, data, våren 2015 Oslo 19.01.2015 Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Forprosjektrapport Presentasjon Tittel: Pizzaplutselig.no

Detaljer

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra.

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra. Visjonsdokument 1 Introduksjon Dette prosjektet er gitt av Svend Andreas Horgen, og gjennomføres som en prosjektoppgave i faget TDAT3022-A 14H Systemutviklingsprosjekt ved HiST, AiTEL. Hensikten med dette

Detaljer

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer...

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer... Innholdsfortegnelse Presentasjon..................................................... 3 Sammendrag.................................................... 4 Dagens situasjon.................................................

Detaljer

S y s t e m d o k u m e n t a s j o n

S y s t e m d o k u m e n t a s j o n S y s t e m d o k u m e n t a s j o n Monitorering av produksjonsløyper ved Nasjonalbiblioteket - Project BAKE Utarbeidet av: Einar Wågan Kristian Akerhei Studium: Informasjonssystemer Innlevert: 26.5.2015

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

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

SCRUM EB og TMG 2010

SCRUM EB og TMG 2010 SCRUM Hovedmål Mer om roller i SCRUM Es/mering av innhold i sprinter Visualisering av fremdri; ved burndown Scrum Daily SCRUM 24h Product backlog Sprint backlog 1 uke Sprint Delprodukt / delleveranse Roller

Detaljer

Brukerdokumentasjon for LabOra portal - forfattere

Brukerdokumentasjon for LabOra portal - forfattere Brukerdokumentasjon for LabOra portal - forfattere Skin: Dnnbest-Grey-Skin1024 Skin: Metro7 Custom LabOra web-portal er et web-basert publiseringsprogram for publisering av informasjon på hjemmesider.

Detaljer

Presentasjon. Kristian Hewlett- Packard 29.05.2012

Presentasjon. Kristian Hewlett- Packard 29.05.2012 2012 Presentasjon Kristian Hewlett- Packard 29.05.2012 1 Innledning Denne innledningen inneholder informasjon om gruppen, samt bakgrunn og mål for oppgaven og en introduksjon til temaet. 1.1 Gruppen Vår

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

1. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

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

Et forsøk på definisjon. Eksempel 1

Et forsøk på definisjon. Eksempel 1 Et forsøk på definisjon [Kurssidene] [ ABI - fagsider bibin ] Michael Preminger (michael.preminger@hioa.no) 19/08-15 Engelsklignende språk, med rigid syntaks, som kan brukes til å skrive instruksjoner

Detaljer

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

4.5 Kravspesifikasjon

4.5 Kravspesifikasjon 4.5 Kravspesifikasjon 4.5.1 Funksjonalitet og systembeskrivelse Webapplikasjonen har tre overordnede funksjoner; Opprett Spotify arrangement, Opprett SoundCloud arrangement og Bli med på arrangement. Brukere(kalt

Detaljer

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

FORPROSJEKTRAPPORT. (+47) 482 32 249 egil.paulsen@gmail.com. Tore Lervik (+47) 470 10 713 tore@mindre.net

FORPROSJEKTRAPPORT. (+47) 482 32 249 egil.paulsen@gmail.com. Tore Lervik (+47) 470 10 713 tore@mindre.net AIRDOG FORPROSJEKTRAPPORT PRESENTASJON Sted og dato Oslo, Feb 9, 2009 Prosjektets tittel Gruppemedlemmer Oppdragsgiver Veiledere, BEKK Kontaktperson, BEKK Veileder, HiO AirDog Egil Paulsen (+47) 482 32

Detaljer

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav. Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig

Detaljer

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Oppdatert 15. jan. 2014, Svend Andreas Horgen (studieleder Informasjonsbehandling og itfag.hist.no) Her er noen generelle retningslinjer

Detaljer

Erfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt 13.05.2009. Motivasjon av kunder og Nyttige verktøy

Erfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt 13.05.2009. Motivasjon av kunder og Nyttige verktøy Erfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt 13.05.2009 Motivasjon av kunder og Nyttige verktøy 2009-05-20 Computas AS 2008 Computas-metodikk fra da til nå Computas

Detaljer

Oppgave 1 Multiple Choice

Oppgave 1 Multiple Choice Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen

Detaljer

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Hovedprosjekt i informasjonsteknologi våren 2014 Oslo 22.01.2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Meso

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen Prosjekt nr. 2007-11 Prosessrapport Tittel: Informasjonssystem SSPI Prosjektdeltakere: Hans Petter Kristiansen, s130182 Espen Skaarer, s123590 Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

Forprosjektrapport. Høgskolen i Oslo Våren 2007-02-02. Dr.Klikk. Gruppe 25. Håkon Drange s130167 Lars Hetland s127681

Forprosjektrapport. Høgskolen i Oslo Våren 2007-02-02. Dr.Klikk. Gruppe 25. Håkon Drange s130167 Lars Hetland s127681 Forprosjektrapport Høgskolen i Oslo Våren 2007-02-02 Dr.Klikk Gruppe 25 Håkon Drange s130167 Lars Hetland s127681 Innholdsfortegnelse PRESENTASJON... 2 SAMMENDRAG... 2 OM BEDRIFTEN... 2 DAGENS SITUASJON...

Detaljer

Pedagogisk regnskapssystem

Pedagogisk regnskapssystem av Benjamin Dehli og Jørgen Tellnes Innhold 1 Innledning 2 Om forprosjektet 2.1 Forprosjektgruppen 2.2 Målsetninger med forprosjektet 3 Beskrivelse av hovedprosjektet 3.1 Arbeidstittel 3.2 Prosjektgruppe

Detaljer

Grunnleggende om websider og HTML-kode

Grunnleggende om websider og HTML-kode Grunnleggende om websider og HTML-kode Html er et språk / en standard som brukes for å gi instrukser til nettlesere om hvordan ulike elementer på en webside skal fortolkes og presenteres for en sluttbruker.

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

2. Beskrivelse av mulige prosjektoppgaver

2. Beskrivelse av mulige prosjektoppgaver Avanserte databaser (øving 9, 10, 11 & 12) Tore Mallaug 25.01.2008 Opphavsrett:Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO326D Avanserte Databaser INNLEVERINGSFRISTER (Obligatorisk

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm Hovedprosjekt i informasjonsteknologi 2016 Høyskolen i Oslo og Akershus Forprosjektrapport Digitalt læreverktøy for Cappelen Damm Gruppe 26 Sofia Aittamaa - s198580@stud.hioa.no Petter Lysne - s198579@stud.hioa.no

Detaljer

Prosjektdagbok Gruppe 18

Prosjektdagbok Gruppe 18 Prosjektdagbok Gruppe 18 Dato: 14.05.2014 25.05.2014 Oppmøte: Alle I denne perioden har vi sittet alle mann på skolen nesten hele tiden. Vi har jobbet sammen om sluttdokumentasjonen. Selv om vi all hovedsak

Detaljer

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

Detaljer

Presentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg. Prosjektnummer 2E

Presentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg. Prosjektnummer 2E Presentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg Prosjektnummer 2E 1. Innholdsfortegnelse 1. Innholdsfortegnelse 2 2. Norske Hus Boligsystem AS 3 3. Problemstillingen 3 4.

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

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

SolidPlant er perfekt for deg som jobber med design av rørsystemer og anlegg, og er kjent med SolidWorks.

SolidPlant er perfekt for deg som jobber med design av rørsystemer og anlegg, og er kjent med SolidWorks. SolidPlant, det eneste virkelig spesifikasjonsstyrte anleggsdesign programmet for SolidWorks. Ved å kombinere intuitive parametrisk styrte SolidWorks med en sofistikert database for å generere alle komponenter

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

SCRUM Smidig prosjektledelse og utvikling. 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG

SCRUM Smidig prosjektledelse og utvikling. 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG SCRUM Smidig prosjektledelse og utvikling 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG HVORDAN SPISER DU EN ELEFANT? EN BIT AV GANGEN 'HOW WILL YOU LIVE, RAMBO?'

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 MetaView

Forprosjektrapport MetaView Forprosjektrapport MetaView BACHELOROPPGAVE VÅREN 2014 Presentasjon Tittel: MetaView Oppgave: Utvikle en Windows 8 applikasjon som skal forenkle en liten del av MetaVision. Et verktøy for sykehus, leger

Detaljer

Uansett hvilken håndbok du benytter vil fremgangsmåten være den samme. I denne veiledningen benytter vi personalhåndboken som eksempel.

Uansett hvilken håndbok du benytter vil fremgangsmåten være den samme. I denne veiledningen benytter vi personalhåndboken som eksempel. Velkommen som bruker av nettbaserte håndbøker fra Hovedorganisasjonen Virke. Våre nettbaserte håndbøker kan tilpasses din virksomhet. De er redigerbare, samtidig blir de automatisk oppdatert med nye lover

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Innstillinger. Endre Personalia

Innstillinger. Endre Personalia Innstillinger Endre Personalia: Her kan du endre personlige innstillinger. Tilpass it's:learning: Her kan du tilpasse utseende og endre f. eks språk. Varsling: Du kan få varslinger tilsendt både på e-post

Detaljer

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9 Forprosjektrapport Gruppe 17 Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen Side 0 av 9 Innholdsfortegnelse: Presentasjon - Service Broker AS - Kontaktpersoner Sammendrag Dagens situasjon Mål og

Detaljer

FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING

FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING 23. JANUAR 2015 FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING Innholdsfortegnelse Presentasjon... 2 Sammendrag... 2 Dagens situasjon... 2 Mål og rammebetingelser... 2 Mål...

Detaljer

ThinkPage CMS 2.0. Hurtigveiledning. Av ThinkPage AS

ThinkPage CMS 2.0. Hurtigveiledning. Av ThinkPage AS ThinkPage CMS 2.0 Hurtigveiledning Av ThinkPage AS ThinkPage CMS 2 Forord Dette er en midlertidig brukerveiledning tar for seg de viktigste basisfunksjonene i ThinkPage CMS og gir brukeren nødvendig innføring

Detaljer

1. Intro om SharePoint 2013

1. Intro om SharePoint 2013 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Intro om SharePoint 2013 Stein Meisingseth 09.08.2013 Lærestoffet er utviklet for faget LO205D Microsoft SharePoint 1. Intro om SharePoint

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

Forprosjekt bachelor-oppgave 2012

Forprosjekt bachelor-oppgave 2012 Forprosjekt bachelor-oppgave 2012 Oppgave nr. 4.- Styring av instrumenter. Skrevet av Jan Ingar Sethre. 1 Innhold 1. Mål og rammer... 3 1.1 Bakgrunn... 3 1.2 Mål for prosjektet... 3 1.3 Rammer og forutsetninger...

Detaljer

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Obligatorisk oppgave 1 INF-3200 12. oktober 2003 Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Oppgavebeskrivelse: Designe og implementere en distribuert ray-tracing applikasjon, med basis i kontroller-

Detaljer

IDRI3001 Bacheloroppgave i Drift av datasystemer

IDRI3001 Bacheloroppgave i Drift av datasystemer IDRI3001 Bacheloroppgave i Drift av datasystemer Kjell Toft Hansen, 15.04.2015 Bachelor Informatikk Drift av datasystemer Sammendrag Her er noen studiespesifikke retningslinjer for veiledning og vurdering

Detaljer

Prosjektledelse - fra innsiden

Prosjektledelse - fra innsiden Prosjektledelse - fra innsiden Presentasjon hos UiO 31.08.2012 Ida Lau Borch, fagansvarlig i Metier AS Det ligger et fantastisk potensial i det å være best i prosjektledelse og -styring Prosjekteierstyring

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

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 2 - revidert 10.02.2010 AESTON. Side 1

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 2 - revidert 10.02.2010 AESTON. Side 1 Brukerveiledning Kom i gang publiseringsverktøy versjon 2 - revidert 10.02.2010 AESTON Side 1 Velkommen som bruker av Kameleon Introduksjon Kameleon er et publiseringsverktøy (Content Management system

Detaljer

Shellscripting I. Innhold

Shellscripting I. Innhold Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Shellscripting I Tor Halsan 19.08.2010 Lærestoffet er utviklet for faget LN199D Scripting av Servere Resymé: Leksjonen er første innføring

Detaljer