HOVEDPROSJEKT. Automating Aptopappa. Geir Skjevling PHP. Webapplikasjon

Størrelse: px
Begynne med side:

Download "HOVEDPROSJEKT. Automating Aptopappa. Geir Skjevling PHP. Webapplikasjon"

Transkript

1 PROSJEKT NR Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Automating Aptopappa DATO ANTALL SIDER / BILAG CD PROSJEKTDELTAKERE Erik Østensen (s135803) Henning Østensen (s135784) Ida Melle Johansen (s135690) OPPDRAGSGIVER Aptoma As INTERN VEILEDER Geir Skjevling KONTAKTPERSON Geir Berset SAMMENDRAG Oppgaven har gått ut på å videreutvikle Aptomas prosjektstyringverktøy, Aptopappa. Hensikten er å forbedre informasjonsflyten med kundene, og innad i bedriften. Aptopappa har blitt utvidet med blant annet følgende ny funksjonalitet: - Supportsystem support e-post direkte inn i Aptopappa. - Faktura over E-post i PDF-format - Hendelser i Aptopappa og i SVN over på IRC Applikasjonen er utviklet i PHP og bygger på Aptomas eget rammetverk AFW. Aptopappa utnytter teknologier som HTML, CSS, Javascript, Ajax og SQL. Som database er MySQL benyttet og Apache som Webserver. Vi har lagt ned mange timer i prosjektet og har føler at vi har nådd alle målene til oppdragsgiver. Resultatet er vi meget fornøyd med. 3 STIKKORD Prosjektstyringsverktøy PHP Webapplikasjon

2 Prosessrapport for Automating Aptopappa 2 av 96

3 1. Forord Med denne rapporten vil vi fortelle hva vi har gjort og hvordan vi har jobbet for å komme frem til det endelige produktet. Vi vil utdype og redegjøre for hvilke teknikker og metoder som er brukt for å komme frem til de ulike løsningene. Rapporten er beregnet for sensor, veileder og arbeidsgiver, samt andre som har interesse av å sette seg inn i vår arbeidsmetodikken. Vi forutsetter at leser av dette dokumentet er over gjennomsnittet datakyndig. Prosessdokumentasjonen er delt opp i slik: Innledning, produkt, fasene i prosjektet, samarbeid og konklusjon. Vi anbefales at dokumentene leses i denne rekkefølgen. Vi henviser til produktdokumentasjonen som gir en dypere teknisk beskrivelse av produktet og systemets oppbygning. Vi har lagt ved en ordbok hvor leseren kan slå opp eventuelle ukjente ord og uttrykk som er nevnt i denne rapporten. I teksten er disse markert i kursiv. Vedlagt ligger også styringsdokumenter og andre dokumenter som kan være nyttige for å forstå programmet og prosessen vi har vært igjennom. 3 av 96

4 2. Innholdsfortegnelse Automating Aptopappa Hovedprosjekt våren Forord innholdsfortegnelse 3. Innledning Gruppen Om bedriften Bakgrunn for oppgaven Mål Aptopappa før Aptopappa nå Rammebetingelser... 6 Programvare/teknologi... 6 Beskrivelse Utviklingsmiljø Nettlesere Planlegging Innledende arbeid Første tanker Fremdriftsplan og arbeidsplan Metode Kravspesifikasjon Utviklingsprosessen Kompetansetilegning Programvare / Teknologi Beskrivelse Programvare/teknologi Beskrivelse Design Bakgrunn for designet Utfordringer med design Ikoner Implementasjon Prototype, scriptacolous og JSON PDF-generering av faktura IRC-bot Supportsystemet Filopplasting med Ajax-liknende funksjonalitet Automatisk kodekontroll Testing Samarbeid Samarbeid med oppdragsgiver og sluttbruker Samarbeid i gruppen Veiledning fra Høgskolen i Oslo Oppsummering/Konklusjon Oppsummering Hva kunne vært gjort bedre Konklusjon Kilder av 96

5 3. Innledning Denne delen av dokumentet inneholder bakgrunnsinformasjon for prosjektet. Her presenterer vi hvem som har utført prosjektet, en beskrivelse av bedriften, og bakgrunn og mål for oppgaven Gruppen Gruppen vår består av Erik Østensen, Henning Østensen og Ida Melle Johansen. Vi har tidligere jobbet sammen som gruppe mer eller mindre på alle gruppeprosjektene på ingeniørstudiet, og mener vi har et godt og fungerende samarbeid. Det var naturlig for oss å fortsette samarbeidet, da sannsynligheten for at det dukker opp nye uenigheter og gnisninger i gruppen er liten i og med at vi har jobbet sammen flere ganger før. Vi var både åpne for, og forholdsvis enige og samstemte i forhold til hva slags type oppgave vi ønsket. Vi ønsket helst en oppgave innen programmering, og tok i den forbindelse på egenhånd kontakt med et par interessante bedrifter. Vi leste også igjennom forslagene til hovedprosjekt på skolens hjemmesider, og var enige om at Aptoma AS sitt forslag til hovedprosjekt virket interessant og lærerikt. 3.2 Om bedriften Aptoma AS utvikler web-applikasjoner. Deres hovedkunder er avisselskaper og mediebedrifter i Norge og utlandet. Aptoma AS leverer blant annet løsninger innen web-tv, visuell produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus. Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har utviklet flere dynamiske og multimediale webapplikasjoner. Blant annet et verktøy for oppsett av forsider, Dr. Front., som blir brukt på blant annet VG-netts og den franske nyhetssiden Bedriften samarbeider også andre mediebedrifter for eksempel Asker og Bærum Budstikke og Scanpix/NTB. Aptoma AS er en relativt liten bedrift med 7 utviklere og programmerere. De fleste holder til i Oslo, men de har også en ansatt som jobber og bor i Sverige. Det er viktig for bedriften å være så mobil som mulig, altså ikke være avhengig av å være på kontoret for å kunne jobbe. Det er stor fleksibilitet for de ansatte, om de vil jobbe hjemmefra, i bedriftens lokaler og til hvilket tidspunkt. Aptoma AS jobber etter en fleksibel utviklingsmetode sterkt inspirert av SCRUM. Dette gjør at de arbeider anderledes enn man er vant med fra tradisjonelle yrker, da SCRUM er rekursiv og fordrer korte faser, smartere planlegging og tettere samarbeid. Vi har også valgt å jobbe etter bedriftens metode. Dette vil bli beskrevet ytterligere senere i rapporten. 3.3 Bakgrunn for oppgaven Oppdragsgiver har i løpet av sommer og høst 2008 utviklet et eget prosjektstyringsverktøy; Aptopappa. Aptopappa er et web-basert grensesnitt for oppgavestyring. Systemet skal forenkle jobben med planlegging og styring av prosjekter. Programmet er tenkt å etterhvert ta over alle administrative oppgaver i bedriften, slik som kalender, timelister, support o.l. Aptopappa hadde per følgende funksjoner: Ha oversikt over alle prosjektene. Lage og opprettholde oppgaver for hvert prosjekt. Oppgaven ble delt inn i tre hovedgrupper, hvor øverste oppgaveliste var bestemt etter hvilken sprint man er i. Registrere timeføring for de ansatte. Ha oversikt over Aptomas produkter og tjenester. Ha oversikt over alle kundene, samt deres kontrakter med bedriften. Lage fakturaer i HTML-format, som ble skrevet ut og levert til posten. Oppdragsgiver ønsket at programmet skulle være mer selvdrevet. Ideelt sett ønsket bedriften at Aptopappa kunne styre prosjekter «helt av seg selv». Oppdragsgiver ønsker at man som utvikler ikke skal bry seg med tidsstyring, timelister osv, men bare konsentrere seg om oppgaven som 5 av 96

6 utvikler. Oppdragsgiver ønsket at vi skulle videreutvikle Aptopappa og legge til nye funksjoner slik at de vanligste oppgavene som trengs å gjøres i bedriften går av seg selv. 3.4 Mål Målet med oppgaven er å videreutvikle og legge nye funksjoner til Aptoma AS sitt prosjektstyringsverktøy Aptopappa. Systemet er til bruk innad i bedriften, og ble brukt hele tiden mens vi jobbet med det. Oppdragsgiver ønsket å legge til funksjonalitet for automatisering av fakturaer, automatisk rapportering til bedriftens egen IRC kanal, opplasting av filer i systemet og enklere måter å få tak i informasjon på Aptopappa før I og med at vår oppgave var å videreutvikle og legge til funksjonalitet i et allerede eksisterende program kan det være nyttig å beskrive programmet slik det var før vi begynte å jobbe med det: Aptopappa er et web-basert prosjektstyringsverktøy. Programmet er utviklet av Aptoma AS og er ment som et verktøy for å holde styr på ressursene til bedriften. Aptopappa er utviklet som et SCRUM-verktøy. Det vil si at det er bygd opp rundt metodikken til SCRUM. Aptopappa er altså et prosjektstyringsverktøy som følger SCRUMS repetitive planleggingsitterasjoner kalt sprint. Aptopappa bruker Ajax-teknologi for å gi applikasjonen et interaktivt brukergrensesnitt. Applikasjonen er responsiv og dynamisk, og bærer i så måte preg av en vindusapplikasjon. Aptopappa er utviklet med fokus på enkelthet og med et ønske om å holde ting enkelt. Det er unngått å ha for mange knapper og funksjoner synlig på en gang. Programmet er knyttet rundt forskjellige prosjekter. Der man i hvert prosjekt har en sprint. Dette vises visuelt med en graf. Man registrerer timer. Fordeler oppgaver. Ser framdrift. Har en produkt backlog, med oversikt over pågående oppgaver og oppgaver som må å gjøres. Programmet er rollebasert, det vil si at man bare ser det man trenger å se i forhold til hva man er, kunde, administrator eller ekstern utvikler. Man har mulighet til å holde følge med arbeidet en selv gjør ved å få en oversikt over sine «efforts». Systemet har vært i fullt bruk siden det første gang ble utviklet sommeren 2008 og har vært i fullt bruk under hele hovedprosjektperioden. Aptopappa blir brukt til å planlegge prosjekter. Det vil si: planlegge sprint, holde styr på deltagere, timetelling og oppgavefordeling innad i de forskjellige prosjektene. Systemet ble også delvis brukt til å sende ut fakturaer til kunder og holde oversikt over forskjellige kundeforhold. Oppdragsgiver var opptatt av at Aptopappa skulle være et enkelt program med minst mulig ting og knapper som tar fokus bort fra det man ønsker å gjøre. Det var viktig for bedriften at Aptopappa opprettholdt det høye nivået av brukervennlighet og at ting skal gå så enkelt som overhode mulig. Ønske fra oppdragsgiver var altså at Aptopappa skal beholde sin enkelthet, være fokusert og samtidig være så komplisert at det kan brukes til å gjøre alle mulige oppgaver i forhold til planlegging og gjennomføring av webutvikling. Aptopappas design og grensesnitt er allerede satt av oppdragsgiver, og det var derfor ikke nødvendig og endre noe på dette. Systemets grensesnitt så vel som design er enkelt, minimalistisk og ment å lage minst mulig forvirring for brukeren. Alle funksjoner er «gjemt» og dukker fram når man fører musepekeren over eller trykker på linker. Oppgaver i sprint og backlog kan flyttes logisk og enkelt med dra-og-slippmetoden Aptopappa nå Vi har ikke endret den allerede eksisterende funksjonaliteten til Aptopappa, vi har bare lagt til ny. Vi har gjort følgende: Laget et enklere system for utsending av faktura per epost som PDF. Gjort kommunikasjonen bedre. Vi har laget en IRC-bot som er aktiv på Aptoma AS egen IRC-server. IRC-boten henter informasjon fra Aptopappas RSS-feed over hendelser og sender dette videre til de forskjellige IRC-kanalene på IRC-serveren. 6 av 96

7 Vi har laget et supportsystem. Hvert prosjekt har muligheten til å få en supportfunksjon. På denne måten blir det opprettet support tickets av alle henvendelser på mail gjort til respektive prosjekter. Mail som blir sendt til de forskjellige prosjektenes support epost- adresser blir til support tickets i Aptopappa og utviklerne har da mulighet til å svare på ticketen med en gang, vente å se om det løser seg, sende ticketen over til en annen ansatt eller gjøre ticketen om til en oppgave slik at den blir en del av prosjektets oppgaver. Det er også laget ekstra funksjonalitet til supportsystemet, for eksempel så blir man påminnet om support tickets som ingen har tatt seg av, videresending av ubehandlede support tickets til sjefens mail og mulighet til å sette en autosvarbeskjed for supportepostadressen. Inkorporert og automatisert et allerede eksisterende system for unit-testing inn i Aptopappa. Dette gjør at koden blir gjennomgått for feil på gitte tidspunkt. Eventuelle feil blir rapportert til supportsystemet, mens om testen blir godkjent blir det gitt beskjed om dette på IRC-kanalene til Aptopappa. Vi har i tillegg til dette også inkorporert ny funksjonalitet i Aptopappa. For eksempel så har gjort det mulig å laste opp filer (bilder, video og lignende) i prosjektenes oppgaver og automatisert opprettelsen av HTML-dokumenter av Aptopappas dokumentasjon. 3.5 Rammebetingelser Oppdragsgiver hadde klare retningslinjer når det gjaldt teknologi. Siden Aptopappa allerede er skrevet i PHP, med elementer av Javascript og Ajax så var det ønskelig at vi fortsatte på samme måten. Aptoma AS har utviklet sitt eget rammeverk, AFW, som oppdragsgiver ønsket at vi satt oss inn i og fulgte. På grunn av at man i bedriften ofte redigerer og arbeider i de samme filene var det vikitg med et versjonskontrollsystem. Aptoma AS bruker Subversion som versjonskontrollsystem Utviklingsmiljø Oppdragsgiver hadde også klare retningslinjer når det gjaldt utviklingsmiljø. Oppdragsgiver satte som krav at vi brukte en ren teksteditor, som for eksempel Editra, TextMate, eller Notepad++ Det var også et krav at vi ikke brukte Windows som operativsystem på grunn av problemer med linjeavsluttningstegn. Vi brukte derfor Unix/Linux eller Mac sitt operativsystem, og passet på at filene vi laget var enkodet i UTF Nettlesere Da de ansatte hos Aptoma AS bruker forskjellige nettlesere har vi testet nye funksjoner i Aptopappa i følgende nettlesere; Chrome, Firefox, Safari og Opera. Men Aptopappa er optimalisert for siste versjon av Firefox. Internet Explorer har ikke vært aktuelt, da mye av den orginale funksjonaliteten i Aptopappa ikke fungerer fullstendig i Internet Explorer. 4. Planlegging Vi vil her forsøke å vise hvordan vi valgte oppgaven, bakgrunnen for at oppgaven ble løst som den har blitt, hvordan planleggingsfasen har vært, og hvilke beslutninger som ble tatt og hvorfor Innledende arbeid I midten av november 2008 tok vi kontakt med Geir Berset ved Aptoma AS, angående prosjektet «Automating Aptopappa» som ble beskrevet på hovedprosjektets nettside. Vi ble innkalt på intervju der Aptoma AS fikk informasjon om vår bakgrunn og motivasjon, og vi fikk mer informasjon om prosjektet. Vi syntes oppgaven virket veldig interessant ut, og var positive til å ha den som vårt hovedprosjekt. Aptoma AS valgte vår gruppe til sitt prosjekt og i starten av januar 2009 hadde vi et møte med Geir Berset der vi gikk gjennom oppgaven, krav, osv. Vi fikk opplæring i bedriftens måte å jobbe på og fikk kontoer i deres SVN slik at vi hadde tilgang til kildekoden til Aptopappa og AFW. Aptoma AS jobber etter SCRUM-metoden, og ønsket at vi skulle gjøre det samme. I SCRUM 7 av 96

8 jobber man tett sammen i kortere planleggings- perioder. I Aptoma AS sitt tilfellet var et ønskelig med 30 dagers iterasjoner, kalt sprint, med demonstrasjon av fungerende funksjoner i slutten av perioden. Da vi arbeider etter SCRUM-metoden var det vanskelig å sette opp en detaljert framdriftsplan, da man kun detaljplanlegger den førstkommende iterasjonen. Istedenfor ble planla vi hver sprint, og satte av tidsbruk etter de oppgavene vi så for oss å fullføre for den sprinten. Vi avtalte å jobbe med hovedprosjektet 3 dager i uken, mandag, tirsdag og onsdag fra Noe som ga iterasjoner på 180 timer over 30 dager. Da Aptoma AS sin måte å arbeide på gir mye fleksibilitet og frihet i form av hvor man sitter, ble vi enige om at vi enten kunne jobbe hjemme fra hver for oss, sammen eller på skolen, så lenge vi hadde et møte om dagen (dagens SCRUM) der vi diskuterte dagens arbeid, mål og hva vi hadde oppnådd fra forrige møte. Første fasen av prosjektet, forprosjektet, ble startet rett etter nyttår. Vi avtalte et møte med veileder, Geir Skjevling. Oppdragsgiver hadde laget en foreløpig kravspesifikasjon som ble i samarbeid med Geir Berset oppdatert og tilpasset dagens situasjon. Og med dette var vi raskt i gang med forprosjektrapport Første tanker Vi syntes det var veldig spennende, men også utfordrende å bli kastet rett inn i en arbeidssituasjon og et allerede påbegynt prosjekt. På den ene siden så er jo da hovedtanken, design og målsetting allerede bestemt av oppdragsgiver, noe som gir lite fleksibilitet og kreativitet i forhold til utvikling av programmet. Hadde vi fått i oppgave å lage et helt nytt program så hadde jo vi kunne bestemme mer hvordan ting skulle se ut, logikken i oppbygging og hvilken funksjonalitet som er viktig. Mens i dette prosjektet er det allerede bestemt fra oppdrags- giver hva som trengs og hvordan det skal se ut. Men på den andre siden er denne måten å jobbe på veldig mye mer realistisk i forhold til arbeid i en bedrift. Det er sjelden man får gjøre akkurat som man vil og lage et program utfra eget behov. Vi synes derfor det skulle bli veldig interessant å bli satt i en tilnærmet «normal» arbeidssituasjon og måtte forholde oss til oppdragsgiver som om vi skulle vært ansatt i bedriften Fremdriftsplan og arbeidsplan En generell framdriftsplan og arbeidsplan ble satt opp i starten av prosjektet. Det var vanskelig å være spesifisert og detaljert da vi planla selve arbeidet i 30 dagers iterasjoner. Den mer spesifikk fremdriftsplanen og arbeidsplanen ble satt opp inne i Aptopappa på starten av hver nye iterasjon. Vi brukte SCRUM sin «planleggings- poker» for å bestemme antatt tidsbruk og fordelte oppgaver utfra de forskjelliges kunnskaper, evner og kompetanse. Bilde under viser en generell framstilling av hvordan vi jobbet. Arbeidsperiodene til venstre i tabellen er de forskjellige iterasjonene vi gikk gjennom. Timelister med beskrivelse av hva de forskjellige har gjort ligger vedlag på slutten av dokumentett. 8 av 96

9 Fig 1. Fremdriftsplan Metode 9 av 96

10 Vi bestemte oss for å jobbe etter oppdragsgivers systemutviklingsmetode, deres egen variant av SCRUM. SCRUM i kombinasjon med XP (Extreme Programming). SCRUM defineres slik på Wikipedia.org: Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development. (...) Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach. Kilde: Fig 2 SCRUMs utviklingsprosess. Kilde XP defineres slik på Wikipedia.org: Extreme Programming (XP) is a software engineering methodology (and a form of agile software development) (...) prescribing a set of daily stakeholder practices that embody and encourage particular XP values (...). Proponents believe that exercising these practices traditional software engineering practices taken to so-called extreme levels leads to a development process that is more responsive to customer needs ( agile ) than traditional methods, while creating software of better quality. Kilde: Fig 3 XPs utviklingsprosess. Kilde: en.wikipedia.org/wiki/extreme_programming 10 av 96

11 Aptoma AS definerer sin variant av SCRUM slik: What do we do at Aptoma? We call it Scrum even though we cover the technical practices of XP as well. However, we will never admit to doing Extreme Programming due to its silly, silly name. ( Extreme wouuu). There is absolutely nothing extreme or remarkable about agile. It s just down to earth Common Sense Results Focused Tight Development) I ll rather admit to being a Scrum based or Lean software development organization any day. Lean = The XP + Scrum combination, better explained and without the silly naming. Fra Aptoma AS sin blog Select *. Aptoma AS sin variant av SCRUM består av 6 steg: 1. Create and maintain a Product Backlog. This is a list of user stories sorted by a simple but powerful cost vs. benefit analysis. 2. Hold a monthly sprint planning meeting. Select the top requirements from the product backlog during Sprint Planning, part 1. The team break these requirements into actionable items (tasks), during the second segment, and carefully adds their time estimates. A goal that the team can commit to is then constructed for the sprint. Everything put into the sprint should be potentially ready for production before the sprint ends, remember? Tools to aid you adding the correct amount of requirements to the sprint is the calculated sprint velocity (how many ideal man-hours you can put into the sprint) versus the task estimates. Sprint velocity, in turn, depends on the focus factor. More on these new terms later. 3. Do The Sprint (with Daily Scrums). The team carries out the sprint during the coming month, and Scrum Masters are mere facilitators at this stage. The team selforganizes to make the real magic happen. Through daily scrums (short, informal team get-togethers) lasting only 5 to 15 minutes regardless of team size, the team stays synchronized and focused on the sprint tasks. Every team member answer only three questions; a) What did I do since our last daily scrum? b) What am I planning to do until the next daily scrum? c) What is stopping me from working as effectively as possible, if anything? 4. Sprint review. AKA The Demo. The team explains the goal of the sprint, and shows off the requirements that has been turned in to finished functionality, potentially ready for production, in a demo. Anyone can turn up to this event, and the demo should be understandable by the customer. Feedback is gathered during and after the review. 5. Sprint retrospect. The goal is to learn something from the just finished sprint. The team discuss the following three questions : a) What went well? b) What can be improved? and c) What will we focus on improving during the next sprint? Suggestions for improvement can be turned into requirements and put into the product backlog, ensuring that the team commits to them during upcoming sprints. 6. Rinse and repeat every 30 days. And that s all there is to it. 11 av 96

12 Fra Aptoma AS sin blog. Aptoma AS sin variant av SCURM vil altså si at man: lager en enkel oversikt over oppgavene som trengs gjøres i nærmeste framtid har en månedlig Sprint-planning der man planlegger detaljert og estimerer oppgaver for de neste 30 dagene har daglige Scrums, det vil si små daglige møter på 5 til 15 minutter hvor man diskuterere hva man har gjort, hva man skal gjøre og om det er noe som forhindrer en til å jobbe ordentlig denne dagen. har en demo, det vil si en demonstrasjon av ferdig funskjonalitet. Hele bedriften bør være til stede, og alle kommer med konstuktiv tilbakemelding. har en månedlig retrospekt, der man går gjennom forrige Sprint, finner ut hva som gikk bra og dårlig sånn at man er klar for neste Sprint. Dette gjentar man altså månedlig, eventuelt med kortere eller lengre Sprinter, alt etter som hva slags arbeid man gjør. Et annet viktig prinsipp for Aptoma AS er at man alltid strekker seg etter å gjøre ting 100% ferdig i løpet av en Sprint. Det er viktigere for bedriften at man gjør det man holder på med klar for bruk i løpet av en Sprint, enn å gjøre hundre ting litt ferdig. Når man er ferdig med en Sprint skal man i teorien kunne legge fra seg et prosjekt å gå over i et annet uten at det henger ved arbeid eller er noen løse tråder. Did you ever start coding on some functionality, only to find that it depends on something that is almost finished, but not quite? Obviously you ll have to finish the 90% done item. And it takes a lot of time, you have to dig into it (losing the context of the current functionality you are working on) in order to complete it properly. Antidote : Schedule work one user-story at a time, and bring all code to 100% completion i.e make it pass all unit-tests and acceptance tests (customer tests) before proceeding to the next feature. Fra Aptoma AS sin blog Select *. Vi har i vårt hovedprosjekt prøvd så godt vi kan å jobbe etter Aptoma AS sin metode. Dette har vært både krevende og vanskelig, men mest av alt, interessant og veldig lærerikt. Det har vært vanskelig å skulle lære en ny måte å tenke på, og det har vært vanskelig å skulle følge denne nye tankegangen når alt vi har lært på skolen og dokumentasjonsstandarden og -eksemplene er bygd opp etter helt andre prinsipper. Da vi har lært at man må planlegge alt før man begynner, ha en fullstendig plan og kravspesifikasjon klar først (jevnført RUP, UP og Fossefallsmetodikker), så er Aptoma AS sin metode helt anderledes. Her skal man planlegge for korte perioder, kravspesifikasjon og framdriftsplan er dynamisk, og hovedfokus er på å ha 100% ferdig kode i løpet av korte itterasjoner. Men etter å ha lest, lært og skjønt hvordan oppdragsgiver tenker har det gjort at vi har fått et annet perspektiv når det gjelder programutviklin. Vi føler at vi ved å jobbe etter denne metoden har fått en mye mer arbeidslivsnær erfaring og er klar for å begynne i det virkelige arbeidslivet Kravspesifikasjon Kravspesifikasjonen var generelt og foreløbig satt opp av oppdragsgiver høsten Vi gikk gjennom denne i samarbeid med Geir Berset og oppdaterte den, la til nye oppgaver og diskuterte hva oppdragsgiver ønsket og hva vi syntes virket interessant i forhold til et hovedprosjekt. Men siden vi jobber etter Aptoma AS sin SCRUM metode har det vært vanskelig å bestemme og 12 av 96

13 fastsette alt før vi begynte, så kravspesifikasjonen har blitt oppdatert og omgjort gjennom hele prosessen. Kravspesifikasjon og opprinnelig oppgavetekst ligger vedlagt. 5 Utviklingsprosessen Dette kapittelet omhandler de ulike utviklingsfasene vi har vært igjennom. Det blir beskrevet utfordringer og valg vi stod overfor, hvilke løsninger vi vurderte og hvilke løsninger vi valgte. 5.1 Kompetansetilegning Denne delen tar for seg hvilke verktøy og teknologier vi har tatt i bruk, samt hvilke teknologier som var ukjente for oss og hvilke vi måtte fordype oss i. Siden Aptopappa er et allerede utviklet system ble det lagt føringer fra oppdragsgiver for hvilke språk og rammeverk som skulle brukes. Det ble også satt krav til tekniske løsninger. I bunnen av applikasjonen ligger en database av typen MySQL. Aptopappa er utviklet med objektorientert PHP og oppdragsgivers eget PHPrammeverk, AFW. Brukergrensesnittet er utviklet ved hjelp av HTML, CSS og Javascript. På grunn av bedriftens krav til fleksibilitet var det viktig med en versjonskontroll, så vi måtte også sette oss inn i Subversion (SVN) for å kunne arbeide i samme kildekode som andre uten å ødelegge hele programmet. Det var også krav fra oppdragsgiver om at vi måtte utvikle enten med Mac OS eller et Unix os, dette pga. linjeavslutningstegn og filkoding. Windows var ikke akseptert som OS, da editorer som oftest laget filer med feil koding og linjeavslutningstegn. Her følger en detaljert oversikt over de ulike verktøyene og språkene vi har tatt i bruk: Programvare / Teknologi Beskrivelse Programvare/teknologi Apache HTTP Server PHP MySQL Beskrivelse Webserver Programmeringsspråk (server-side) PHP: Hypertext Preprocessor DBMS (database management system) Memcached AFW System for caching av databasekall på webserver Aptoma Frame Work, Aptomas eget rammeverk MySQL Admin MySQL Query Browser Brukeradministrasjon for MySQL Spørringsverktøy for MySQL MySQL Work Bench Mozilla Firefox 3.x.x Firebug og FirePHP Subversjon SVN HTML Verktøy for databasemodellereing Webleser Feilsøkingsverktøy for Mozilla Firefox. Versjonskontroll HyperText Markup Language 13 av 96

14 Automating Aptopappa Hovedprosjekt våren 2009 Programvare/teknologi Beskrivelse CSS Cascading Style Sheets Javascript Klientbasert scriptingsprål Vi hadde allerede en generell kjennskap til de fleste av disse teknologiene. Gjennom skolen hadde vi blant annet blitt kurset i programmering, webprogrammering og systemutvikling. Og deler av gruppa hadde også erfaring med teknologiene utenom skolen. Men det var likevel en del nytt å sette seg inn i. Spesielt det å jobbe med en versjonskontroll som Subversion var nytt for oss. Og å jobbe så pass konkret etter en metode var også en ny måte å tenkte på. PHP hadde vi kort vært borti gjennom skolen og via annet arbeid. Aptopappa er hovedsaklig programmert i PHP. PHP er et open source høynivåspråk, utviklet av utviklere. Syntaks minner mye svært mye om Java og C++. Vi hadde alle en eller annen tidligere erfaringer med objektorientert utvikling, da blant annet i Java, og det var derfor ikke alt for stor overgang til å programmere i PHP. Aptoma AS sitt eget rammeverk, AFW, var delvis dokumentert av oppdragsgiver, og var ellers lagt opp til objektorientert programmering og var derfor relativt enkelt å sette seg inn i. Alle teknologiene vi har benyttet oss av ligger åpne for allment bruk, og er stort sett grundig dokumentert. Det har derfor ikke vært nødvendig å bruke andre oppslagsverk Design Her blir designfasen beskrevet. Den tar for seg noen av de viktigste avgjørelsene vi har har tatt, hvilke løsninger vi har valgt samt hvorfor vi valgte disse Bakgrunn for designet På grunn av at vi utviklet på et allerede utviklet system var det allerede føringer på design. Vi ønsket ikke at våre nye funksjonaliteter skulle skille seg ut, så vi valgte å følge oppdragsgivers design, oppbygging og logikk. Aptopappas viktigste oppgave er å være brukervennlig, enkel og uten elementer som virker forstyrrende. Knapper, linker og funksjoner skal være logiske, rett fram og intuitivt oppbygd. Fig 4 Eksempel på rotete side Kilde: 14 av 96

15 5.2.1 Utfordringer med design Det har vært flere utfordringer når det gjelder design. Først og fremst har det vært viktig å hele tiden ha et brukervennlig design. Vi har derfor måtte passe på å ikke ha for mange linker, knapper eller andre forstyrrende elementer synlig på siden. Vi har derfor måtte tenke igjennom hvordan man kan samle forskjellig funksjonalitet på samme sted og hvordan man smart kan gjemme ting man ikke trenger hele tiden. For eksempel ved å ha en såkalt mus-overfunksjon. Det vil si at linken, knappen eller bildet kun er synlig når man holder Fig 5. eksempel fra Aptopappa der flere funksjoner musepekeren over et bestemt område. er smalet inn under ett Ikoner Vi har lagt til to ikoner til Aptopappa. Et ikon for generering av dokumentasjon i prosjektsiden, og et for e-postmalen for prosjektestimeringen. Andre ikoner som er brukt, har allerede vært tilgjengelig i Aptopappas filstruktur Fig 6 Ikon for generering. av dokumentasjon 5.3 Implementasjon Denne delen av dokumentet beskriver det vi syntes var de største utfordringene vi møtte på, valgene vi stod ovenfor, hvilke løsninger vi vurderte, samt hvilke løsninger vi valgte Prototype, scriptacolous og JSON Prototype er et rammeverk for Javascript som tilbyr objektdreven funksjonalitet for Javascript, og utvider DOM med mange nyttige funksjoner. Videre tilbyr Prototype kraftige Ajax-verktøy for oppdatering og uthenting av informasjon dynamisk. Scriptaculous er basert på Prototype og leverer ferdigutviklede komponenter som ved hjelp av Javascript, CSS og Ajax-kall tilbyr funksjonalitet som; dra-og-slipp, autooppdaterende tekstfelt, og mye mer. Aptopappa er stor forbruker av både prototype- og scriptacolous- funksjonalitet, og vi så på dette som noe vi var nødt til å settes oss inn i. Den nye funksjonaliteten i Aptopappa både bruker, og utvider deler av disse javascript-rammeverkene. JSON er en protokoll mye brukt i Ajax-kall mellom server og klient, som tilbyr enkel metode for å overføre flere verdier på en gang. JSON som kommunikasjonsmodell er mye brukt i Aptopappa, og hjelper til ved f.eks. å gi brukeren mer meningsfulle feilmeldinger dersom disse skulle oppstå PDF-generering av faktura PDF-generering i PHP var noe som var nytt for oss. Vi kikket på et par ferdige biblioteker som for eksempel PHP sin innebygde løsning, og lette også etter noe gratis konverteringsverktøy for HTML til PDF. Etter å ha vurdert de forskjellige løsningene som fantes, bestemte vi oss for å gå for PHP-klassen FPDF, og lage fakturaene selv, framfor et konverteringsverktøy. Vi kom fram til klassen fpdf av følgende grunner: Åpen lisens, helt fritt bruk 15 av 96

16 Krever ingen ekstra tilleggsbiblioteker for PHP Genererer PDF-kode helt selv Enkelt å lage egne PDF-dokumenter. Vi kom fort i gang med å generere PDF-fakturaer, og de ble seende ut akkurat som HTMLversjonen. Eneste ulempe med denne løsningen er at dersom Aptoma skal endre utseende på PDF-fakturaen, så må dette gjøres både i HTML-versjonen og i PDF-versjonen IRC-bot IRC-protokollen var nytt for oss alle. Ønsket til Geir var å få feedback fra Aptopappa inn på bedriftens IRC-server. For å finne en løsning for denne oppgaven, tenkte vi først på å finne en ferdig idle-klient (altså et program som venter på forespørsler, og så poster det på IRC). Aptopappa ville da hatt en cronjob som koblet seg opp til denne med gjevne mellomrom. Problemet med slike klienter er at IRC-kanalene blir da hele tiden spammet med join/quit meldinger. Vi innså at dette ikke var noen god løsning. I stedet så bestemte vi oss for å lage vår egen IRC-bot. Med litt undersøking, så fant vi ut at IRC-protokollen var ganske enkel å lære. Det tok ikke lang tid før vi hadde vår første utgave av IRC-boten. For å hente data fra Aptopappa fant vi ut at det kunne lønne seg å sette opp et RSS-feed, slik at IRC-botten vår kunne koble seg opp og hente ned de siste hendelsene. Programmeringsmessig valgte vi Perl som språk. Perl er et såpass enkelt, kjapt og kraftig språk med innebygde nettfunksjoner. Vi valgte å bruke et ferdig bibliotek til Perl for å last ned data fra RSS. Det som har vært litt utfordrende med IRC-botten er å skrive Perls regulære uttrykk. IRCprotokollen er en ren tekst protokoll. Ved å bruke regulære uttrykk, ble omgjøringen av protokolltekst til data ikke noe problem Supportsystemet For supportsystemet, var det på forhånd bestemt at det skulle benyttes en felles e-postkonto over IMAP. Vår utfordring i denne oppgaven lå i å skrive en e-postklient som kunne laste ned postboksen, og legge e-post inn som oppgaver i Aptopappa. Vi så på flere løsninger for IMAPoppkobling i PHP, og kom fram til IMAP-modulen til PHP var den greieste. Det krevdes en ekstra modul som måtte installeres på server, men modulen er mye brukt og oppdateres jevnlig Filopplasting med Ajax-liknende funksjonalitet En Ajax-metode for å laste opp filer finnes ikke. Javascript er begrenset til nettleseren, og får ikke snakke med det lokale filsystemet, annet enn gjennom HTML-taggen i Input, av type file. For å få til Ajax-liknende funksjonalitet i filopplastingen, fant vi en javascript-klasse hos webtoolkit.info kalt AIM. Javascript klassen er gitt ut i en fri lisens, og vi kunne derfor bruke dette. AIM benytter en skjult iframe, hvor det ligger en annen filopplastingsboks. Det er en skjulte filopplastingsboksen som laster opp dokumentet i bakgrunnen. Den synlige boksen blir tømt etter opplasting Automatisk kodekontroll Automatisk kodekontroll benytter AFW sine egne testverktøy. Utfordringen med disse kodekontrollene var å få lastet ned de siste versjonene av softwaren som skulle testes og å tolke testresultatene. Det var vanskelig å jobbe mot AFW som er et rammeverk som stadig er i utvikling. Vi var nødt til å samarbeide med flere av de ansatte i bedriften og forholde oss til det de hadde gjort og hvordan de arbeidet og tenker Testing Aptoma AS sin versjon av SCRUM tilsier at man tester all kode man lager før man committer den tilbake til trunken. Dermed blir det kontinuerlig utført tester. Det er også viktig med testing 16 av 96

17 før demonstrasjon etter endt sprint. Vi har derfor hele tiden gått gjennom og teste systematisk. Det har aldri vært committet ufullstendig kode eller kode som ikke fungerer. For å finne ut hvor eventuelle feil ligger har Aptopappas rammeverk AFW gode rutiner for feilrapportering, ellers har vi bruk Mozilla Firefox s FireBug-utvidelse for å lokalisere feil. En utdypet testrapport ligger vedlagt i sin helhet senere i slutt- dokumentasjonen. Her er det dokumentert testing etter hver ferdige funksjonalitet. 6. Samarbeid Her beskrives samarbeidet i gruppen, samarbeidet mellom veileder og gruppen, og samarbeidet med oppdragsgiver Samarbeid med oppdragsgiver og sluttbruker Vi har at et meget positivt samarbeid med Aptoma AS. Bedriften ga oss mulighet til å sitte i deres lokaler, men der var det svært dårlig plass, så vi byttet på å jobbe hjemmefra, på skolen eller i lunsjrommet til bedriften. Vi har hatt månedlige møter i bedriftens lokaler der vi sammen med ekstern veileder Geir Berset har gått gjennom det vi har gjort i perioden før og planlagt hva som skal gjøres i neste iterasjon. Vi har også hatt månedlige demonstrasjoner der vi har visst fram det vi hadde gjort til hele bedriften. Vi har gjennom hele prosjektperioden fått god og konstruktiv tilbakemelding fra Geir Berset. Utenom møtene hadde vi også flere møter over Skype med demonstrasjon over VNC hvor vi fikk tilbakemelding, tips og råd. Aptoma AS bruker SCRUM sin metodikk som utgangspunkt for hvordan de jobber. Vi ble oppfordret til å gjøre det samme og har fått god hjelp til å gjennomføre dette. SCRUM var nytt for gruppen som arbeidsmetode, så det var en liten tankeomstilling, men det har med hjelp fra ekstern veileder vært veldig enkelt. 6.2 Samarbeid i gruppen Vi har samarbeidet i samme gruppen i nesten alle prosjektene vi har hatt ved Høyskolen i Oslo og det var derfor veldig naturlig å gjøre det igjen. Vi har en god gruppedynamikk og samarbeidet går mye av seg selv. Eneste problemet med samarbeidet har vært at vi har en litt skjev fordeling når det gjelder kompetanse. Erik og Henning har mye erfaring fra før når det gjelder PHP og SQL, mens Ida har mindre erfaring på dette feltet. Det ble derfor en skjev fordeling av arbeidet i begynnelsen, da det var lettere for Erik og Henning å programmere det som skulle gjøres enn å vente på at Ida skulle komme til samme nivå. Men etter noen runder med dette ble vi enige at vi alle skal ta like stor del av programmeringsarbeidet, selv om noen er raskere eller tregere enn de andre. Så med litt ekstra tid og innsats fra Ida og tålmodighet fra Erik og Henning ble etterhvert arbeidsfordeling og tidsbruk jevnere. Og vi har lært at ikke alle er like flinke til alt, og at det derfor kan være nyttig med litt delegering og oppdeling av arbeidet for å nå en deadline, men for å fungere som en gruppe og ha en eierfølelse til prosjektet er det likevel viktig at alle har kjennskap til alle delene av prosjektet Veiledning fra Høgskolen i Oslo Vi ble fordelt veileder Geir Skjevling av Høgskolen i Oslo januar Vi avtalte tidlig et møte med han for å diskutere hovedprosjektet. Etter dette møtet, hadde vi ikke mer kontakt med han. Vi holdt heller mer kontakt med vår eksterne veileder, som hadde også erfaringer fra tidligere hovedprosjekter ved skolen. 17 av 96

18 7. Oppsummering/Konklusjon 7.1 Oppsummering Sluttproduktet, Automating Aptopappa, har gruppen planlagt og utviklet i tett samarbeid med oppdragsgiver. Vår opplevelse er at dette prosjektet er så nær opptil en faktisk arbeidssituasjon man kan komme med et skoleprosjekt. Aptoma AS har fungert som både kunde, oppdragsgiver, veileder og arbeidsplass. Vi har blitt behandlet som en ansatt i bedriften der det har vært forventet av oss at vi jobber etter samme metode, følger deres rammeverk og deres deadlines. Selv om vi har vært såpass styrt av prosjektets rammer har vi likevel kunnet bruke oss selv, være kreative og finne på gode løsninger. Det har vært et tidskrevende og vanskelig prosjekt. Det har vært mye nytt å sette seg inn i, nye metoder, nye programmeringsspråk, og nye måter å tenkte på. Det har vært et utfordrende prosjekt, men mest av alt har det vært lærerikt og interessant. Vi har lært masse om hvordan ting faktisk fungerer i arbeidslivet, hvilke krav og utfordringer som venter oss etter ferdige studier. Det har blitt stilt høye krav til oss fra oppdragsgiver, og forventningen har vært høy, men vi føler vi har klart å innfri og levere et godt produkt, med høy funksjonalitet og god kvalitet. Vi har blitt sterkere både når det gjelder programmering, metodikk, samarbeid og prosjektarbeid. Dette prosjektet har på alle måter vært en viktig del av utdanningen og gjort oss klar til arbeidslivet. 7.2 Hva kunne vært gjort bedre Vi mener vi har fått til et godt produkt og at vi har hatt en veldig lærerik prosess, men det er alltid noe som kunne ha vært gjort bedre. Etter hver demo har vi hatt en gjennomgang av hva som har gått bra og hva som har gått dårlig, og et punkt som stadig dukket opp var at kompetansen er ganske skjevt fordelt, vi strevde derfor med å ha lik arbeidsmengde innad i gruppen. Men dette mener vi at vi har løst på en tilfredstillende måte, da vi ble mer observante på dette og jobbet aktivt med at alle skulle ta en like stor del i arbeidet, ble det etter hvert en jevnere fordeling av arbeidet. Vi føler nå at alle har et likestort eierskap i det ferdige produktet. Andre ting som kunne ha vært gjort bedre eller i alle fall anderledes er hvordan vi valgte å løse oppgaven. Vi har sett dette prosjektet som en god erfaring i forhold til å være ansatt i en bedrift. Vi har derfor hele tiden konferert med ekstern veileder og gjort ting slik han ønsket. Vi kunne nok på mange måter ha vært friere og mer kreativ, men da tror jeg samtidig at vi hadde mistet følelsen vi hadde av å være en del av bedriften. Samarbeidet med høyskolens veileder kunne nok også ha vært bedre. Men da vi synes vi fikk en veldig god kontakt og masse hjelp av den eksterne veilederen så så vi ikke noe behov for noe videre samarbeid med høyskolens veileder. 7.3 Konklusjon Dette har vært et interessant, meget lærerikt og veldig arbeidskrevende prosjekt. Vi har lært masse, både om arbeidslivet, systemutvikling, samarbeid, kommunikasjon i en gruppe, tidsplanlegging i et stort prosjekt og i forholdt til programmering. Vi mener at vi er mye bedre rustet nå til å møte arbeidslivet og å jobbe i en bedrift som driver med systemutvikling eller programmering. 18 av 96

19 Produktrapport for Automating Aptopappa 19 av 96

20 1. Forord Dette dokumentet er produktdokumentasjonen til vårt hovedprosjekt våren 2008, Automating Aptopappa. Hovedprosjekteter et samarbeid mellom Høgskolen i Oslo, og vår oppdragsgiver, Aptoma AS. Produktdokumentasjonen beskriver det ferdige produktets funksjonalitet, virkemåte og oppbygging. Produktdokumentasjonen skal sammen med prosessrapporten gi leseren et helhetlig inntrykk av arbeidet som er utført og det produktresultatet som er oppnådd. Dokumentet gir en generell beskrivelse av systemet slik at leseren skjønner hvordan det henger sammen. Rapporten beskriver også systemets oppbyggning, databasestruktur, teknologier brukt, sikkerhet og rammebettingelser. 20 av 96

21 2. Innholdsfortegnelse 3. Innledning Om bedriften Dagens situasjon Mål Konklusjon Teknologie Rammebetingelser Utviklingsmiljø Nettlesere Benyttede teknologier, språk, og rammeverk Apache 2.4.x PHP 5.3.x MySQL 5.0.x MySQL Admin MySQL Query Browser MySQL Word Bench AFW Mozilla Firefox 3.x.x Firebug og FirePHP Subversjon SVN HTML XML CSS Perl Javascript Javascript: Prototype Javascript: webtoolkit.aim Javascript: Scriptaculous Datastrukturer og oppbyning Database ER-diagram Tabeller Projects tasks customers invoices Arkitektur Design Grafikk og fargebruk Beskrivelse av systemet Generell beskrivelse Produktets oppbyggning og virkemåte Programoppbygging Hovedkomponenter Sende PDF-faktura Generering av PDF Lagring av PDF-faktura Sikkerhet Sending Supportsystem Komme i gang Konfiguarsjonsverdier Hente support e-post Funksjonalitet Filopplasting i oppgaver Endringer i eksisterende kode Begrensing Filplassering og filnavn Sikkerhet RSS til IRC Egne triggere Automatisk kodekontroll Komme i gang Kjøre kodekontrollene Resultater Dokumentasjonsgenerering av oppgaver under docs Skrive E-postmal Se E-postmal Sikkerhet i systemet Krav til miljø For bruker av Aptopappa For å kjøre Aptopappa Utvidelsesmuligheter av 96

22 3. Innledning 3.1 Om bedriften Aptoma AS utvikler webapplikasjoner. Deres hovedkunder er avisselskaper og mediebedrifter i Norge og utlandet. Aptoma AS leverer blant annet løsninger innen web-tv, visuell produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus. Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har utviklet flere dynamiske og multimediale webapplikasjoner. Blant annet et verktøy for oppsett av forsider, Dr. Front., som blir brukt på blant annet VGnetts og den franske nyhetsnettsiden «www.20minutes.fr». Bedriften samarbeider også andre mediebedrifter for eksempel Asker og Bærum Budstikke og Scanpix/NTB. Aptoma AS er en relativt liten bedrift med 7 utviklere og programmerere. De fleste holder til i Oslo, men de har også en ansatt som jobber og bor i Sverige. Det er viktig for bedriften å være så mobil som mulig, altså ikke være avhengig av å være på kontoret for å kunne jobbe. Det er stor fleksibilitet for de ansatte, om de vil jobbe hjemmefra, i bedriftens lokaler og til hvilket tidspunkt. Aptoma AS jobber etter en fleksibel utviklingsmetode sterkt inspirert av SCRUM og XP. Vi har valgt å jobbe etter bedriftens metode. Dette vil bli beskrevet ytteligere senere i rapporten. 3.2 Dagens situasjon Oppdragsgiver har i løpet av sommer og høst 2008 utviklet et eget prosjektstyringsverktøy; Aptopappa. Aptopappa er et webbasert grensesnitt for oppgavestyring. Systemet skal forenkle jobben med planlegging og styring av prosjekter. Programmet er tenkt og etterhvert ta over alle administrative oppgaver i bedriften, slik som kalender, timelister, support og så videre. Men oppdragsgiver ønsket at programmet skulle være mer selvdrevet. Ideelt sett ønsket bedriften at Aptopappa kunne styre prosjekter helt av seg selv. Oppdragsgiver ønsker at man som utvikler ikke skal bry seg med tidsstyring, timelister osv, men bare konsentrere seg om oppgaven som utvikler. Oppdragsgiver ønsket at vi skulle videreutvikle Aptopappa og legge til nye funksjoner slik at de vanligste oppgavene som trengs å gjøres i bedriften går av seg selv. 3.3 Mål Målet med oppgaven er å videreutvikle og legge nye funksjoner til Aptoma AS sitt prosjektstyringsverktøy Aptopappa. Systemet er til bruk innad i bedriften. Oppdragsgiver ønsket å legge til funksjonalitet for automatisering flere ting innen systemet. Blant annet ønsker bedriften enklere behandling av fakturaer, automatisk rapportering til bedriftens egen IRC kanal, bedre kommunikasjonen innad i bedriften og genrelt gjøre ting enklere. 3.4 Konklusjon Vi mener dette systemet vil: gjøre kommunikasjonen bedre innad i Aptoma AS. gjøre det enklere å sende ut fakturaer.. gjøre det enklere for de ansatte å ha oversikt over supportoppgaver. gi raskere responstid på supportoppgaver gjøre det enklere å legge informasjon inn og data til, og få tak i informasjon i systemet.. 4. Teknologier Her beskriver vi hvilke teknologier, programmeringsspråk og rammebetingelser vi har hatt å forholde oss til. 4.1 Rammebetingelser Oppdragsgiver hadde klare retningslinjer når det gjaldt teknologi. Siden Aptopappa allerede er skrevet i PHP, med elementer av Javascript og Ajax så var det ønskelig at vi fortsatte på samme måten. 22 av 96

23 Aptoma AS har utviklet sitt eget rammeverk, AFW, som oppdragsgiver ønsket at vi satt oss inn i og fulgte. På grunn av at man i bedriften ofte redigerer og arbeider i de samme filene var det vikitg med et versjonskontrollsystem. Aptoma AS bruker Subversion som versjonskontrollsystem. Her følger en oversikt over benyttede teknologier, språk og rammeverk: Programvare/teknologi Beskrivelse Apache HTTP Server PHP MySQL Webserver Programmeringsspråk (server-side) PHP: Hypertext Preprocessor DBMS (database management system) Memcached AFW System for caching av databasekall på webserver Aptoma Frame Work, Aptomas eget rammeverk MySQL Admin MySQL Query Browser Brukeradministrasjon for MySQL Spørringsverktøy for MySQL MySQL Work Bench Mozilla Firefox 3.x.x Verktøy for databasemodellereing Webleser Firebug og FirePHP Subversjon SVN HTML CSS Javascript Feilsøkingsverktøy for Mozilla Firefox. Versjonskontroll HyperText Markup Language Cascading Style Sheets Klientbasert scriptingsprål 4.2 Utviklingsmiljø Oppdragsgiver hadde også klare retningslinjer når det gjaldt utviklingsmiljø. Oppdragsgiver satte som krav at vi brukte en ren teksteditor, som for eksempel Editra, TextMate, eller Gedit. Det var også et krav at vi ikke brukte Windows som operativsystem på grunn av problemer med linjeavsluttningstegn. Vi brukte derfor Unix/Linux eller Mac sitt operativsystem, og passet på at filene vi laget var enkodet i UTF av 96

24 4.3 Nettlesere Da de ansatte hos Aptoma AS bruker forskjellige nettlesere har vi testet nye funksjoner i Aptopappa i følgende nettlesere; Chrome, Firefox, Safari og Opera. Men Aptopappa er optimalisert for siste versjon av Firefox. Internet Explorer har ikke vært aktuelt, da mye av den orginale funksjonaliteten i Aptopappa ikke fungerer fullstendig i Internet Explorer. 4.4 Benyttede teknologier, språk, og rammeverk Apache 2.4.x Apache er en fullskala webserver som er utviklet gjennom et samarbeid mellom frivillige individuelle utviklere. Apache er derfor gratis og kildekoden ligger åpent tilgjengelig for alle. Apache er kjent for å være den sikreste og mest brukte webserveren på Internett for tiden PHP 5.3.x PHP, HyperText-Preprocessor, eller Personal HomePage som det egentlig kommer av, er et serversidig skriptspråk. Det betyr enkelt og greit at det som utføres av oppgaver gjøres på serveren, og ikke på klienten MySQL 5.0.x MySQL er et relasjonsdatabasesystem MySQL Admin Verktøy for å håndtere brukere og rettigheter MySQL Query Browser Verktøy for å gjøre spørringer og kjøre scripts mot en MySQL database MySQL Word Bench Verktøy for å lage ER diagrammer AFW AFW er Aptomas eget rammeverk. Dette rammeverket er fortsatt under utvikling Mozilla Firefox 3.x.x Firefox er den nettleseren vi har brukt mest under utviklingen av Aptopappa. Dette er fordi den har gode muligheter for feilsøking Firebug og FirePHP Firebug of FirePHP er addons til Firefox. Disse brukes til feilsøking av for eksempel Ajax kall og kodeinspeksjon Subversjon SVN Subversion er et kildekodeversjonskontrollsystem. SVN er mye brukt av Aptoma. All kildekode som Aptoma skriver, legges opp på deres svn tjener HTML HyperText Markup Language, eller HTML som det ofte blir kalt, er språket som blir brukt for å vise dokumenter på Internett XML XML er et språk for å omkapsle informasjon CSS Cascading Style Sheet, eller CSS, er et språk som brukes til å definere hvordan HTML eller XML sider vil se ut. 24 av 96

25 Perl Perl er et avansert scripting språk. Det er raskere enn PHP, og egnet seg derfor til å bruke for og skrive en IRCBot Javascript Javascript er et skriptingsspråk brukt for å utføre oppgaver på klientsiden for en nettside Javascript: Prototype Prototype er et javascript rammeverk, som tilføyer mange nye funksjoner til javascript språket. Prototype gjør ting på en mer objekt basert måte, og tilbyr Ajax funksjoner som er lette å bruke Javascript: webtoolkit.aim Webtoolkit.aim er en liten del av webtoolkit. Dette biblioteket tilbyr en måte å laste opp filer uten å måtte oppdatere hele nettsiden Javascript: Scriptaculous Scriptaculous er et javascript bibliotek som tilbyr mange nye funksjoner, for eksempel animasjoner, effekter, dra-og-slipp og inplaceeditor. 5. Datastrukturer og oppbygning Her vil vi beskrive programmets datastruktur og oppbygning. Dette vil vi demonstrere ved hjelp av blant annet ER-diagram, beskrivelse av databasens tabeller og oversikt over klasse og filstruktur Database Da Aptopappa allerede er et fungerende program med en fungerende database, var det ikke nødvendig å lage en ny database. Vi redigerte kun noen få tabeller i databasen der vi la til atributter vi trengte til de nye funksjonene. Vi endret følgende tabeller i databasen: projects tasks customers invoices Aptopappa benytter siste versjon av MySQL. Vi har for det meste brukt mysql fra konsoll på enten Linux eller Mac, samt til tider MySQL Administrator, MySQL Query Browser for å redigere, spørre og modellere databaseendringene. MySQL Work Bench er brukt for å lage ER-diagrammet. 25 av 96

26 ER-diagram Automating Aptopappa Hovedprosjekt våren 2009 Fig 6 ER-diagram 26 av 96

27 Tabeller Vi har endret følgende tabeller: Projects I denne tabellen la vi til fire attributter: Kolonne tickets autoresponsemessage code_checking code_revision tasks I denne tabellen la vi til en attributt: Kolonne ticketfrom customers I denne tabellen har vi lagt til en attributt: Kolonne Beskrivelse Verdien forteller hvilken adresse som skal stå i TIL-feltet for e-post som kommer inn i supportpostboksen for at den skal hentes inn til dette prosjektet. Tomt felt deaktiverer support for prosjektet. Feltet inneholder meldingen kunden får når det kommer inn en e-post til et prosjekt som har automatisk svar på. Tomt felt deaktiverer automatisk svar. Feltet sier om prosjektet skal inkluderes i den daglige kjøringen av kodekontroll. 0 for av, alt annet for på. Inneholder siste revisjon som det ble kjørt kodekontroll på. Beskrivelse Dersom feltet ikke er tomt, så er det en support ticket. Feltet inneholder e-postadressen til den som sendte inn support ticketen. Beskrivelse _invoice invoices I denne tabellen har vi lagt til en attributt: Kolonne Aktiverer eller deaktiverer e-post av faktura. Beskrivelse _invoice Feltet bestemmer hvorvidt akkurat denne fakturaen skal sendes eller ikke. 27 av 96

28 5.2 Arkitektur Bildet under gir en oversikt over hvordan systemet er bygget opp. Fig 7 Flyten i systemet. Fig 8 Oppbyggingen av AFW 6. Design Her vil vi prøve å gi en oversikt over hvordan vi har tenkt i forhold til design Grafikk og fargebruk Dette prosjektet har både vokst, men samtididig lidd under å være en utvikling av et allerede eksisterende produkt. Det har ikke vært vår oppgave å endre design eller komme med input på designsiden. Vi har derfor måttet holde oss til Aptopappas allerde utviklede design. Dette har vært enkel, da Aptopappa har en godt strukturert CSS som er skilt fra resten av koden. Det har derfor bare vært å putte våre nye funskjoner inne i riktig div og riktig klasse sånn at det fungerer sammen med resten av applikasjonen. 28 av 96

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

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

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

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

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

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

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

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

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

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

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

Smidige metoder i praksis Høgskolen i Oslo Kristin Meyer Kristiansen Objectnet AS

Smidige metoder i praksis Høgskolen i Oslo Kristin Meyer Kristiansen Objectnet AS Smidige metoder i praksis Høgskolen i Oslo Kristin Meyer Kristiansen Objectnet AS Agenda Min erfaring med scrum + litt input fra Javazone 2007 Universell Utforming Min erfaring med smidige metoder MT-prosjektet

Detaljer

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

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

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

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

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

Bruk av HP Quality Center med smidige utviklingsmetoder. HP Sofware Norge

Bruk av HP Quality Center med smidige utviklingsmetoder. HP Sofware Norge Bruk av HP Quality Center med smidige utviklingsmetoder Kjell Lillemoen HP Sofware Norge QC og smidige metoder Agenda Smidig terminologi Smidig metoder og verktøy Hvilke krav bør vi stille QC med Scrum

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

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

GoOpen 2008 Oslo 8. april. Jernbaneverket Fri programvare i driftskritiske systemer. Ole Morten Killi ole.morten.killi@bouvet.

GoOpen 2008 Oslo 8. april. Jernbaneverket Fri programvare i driftskritiske systemer. Ole Morten Killi ole.morten.killi@bouvet. GoOpen 2008 Oslo 8. april Jernbaneverket Fri programvare i driftskritiske systemer Ole Morten Killi ole.morten.killi@bouvet.no Bouvet ASA Bouvet ASA Ca. 400 ansatte 8 kontorer Bouvets ambisjon er å være

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

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

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

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

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

Dokument 3 - Prosessdokumentasjon

Dokument 3 - Prosessdokumentasjon Dokument 3 - Prosessdokumentasjon Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Dokument 3 - Prosessdokumentasjon Innholdsfortegnelse

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

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

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

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

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

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

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

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

Detaljer

Styringsdokumenter. Forord

Styringsdokumenter. Forord 8 Styringsdokumenter Forord Dette er en samling av samtlige styringsdokumenter gjennom hele prosjektperioden. Styringsdokumentene er satt opp i rekkefølge i forhold til leveringsfrister Dokumentene ble

Detaljer

The Future of Academic Libraries the Road Ahead. Roy Gundersen

The Future of Academic Libraries the Road Ahead. Roy Gundersen The Future of Academic Libraries the Road Ahead Roy Gundersen Background Discussions on the modernization of BIBSYS Project spring 2007: Forprosjekt modernisering Process analysis Specification Market

Detaljer

Entobutikk 4.PROSESSRAPPORT VÅR 2011

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

Detaljer

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

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

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

Detaljer

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

Web fundamentals. Web design. Frontend vs. Backend 17.01.2008. Webdesign 17. januar 2008 3. Monica Strand

Web fundamentals. Web design. Frontend vs. Backend 17.01.2008. Webdesign 17. januar 2008 3. Monica Strand Web fundamentals Webdesign 17. januar 2008 Monica Strand Webdesign 17. januar 2008 1 Web design Fagområdet Web design inneholder flere disipliner Grafisk design Informasjonsdesign Brukergrensesnittdesign

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

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

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

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

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

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

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

Detaljer

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Gruppenummer: 21 Forprosjektrapport Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Gruppemedlemmer: Guro Asbjørnsen, Ester Jansson, Marius Skalstad og

Detaljer

Kravspesifikasjon. Vedlegg A

Kravspesifikasjon. Vedlegg A Vedlegg A Kravspesifikasjon Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen

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

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

Detaljer

Tilkobling og Triggere

Tilkobling og Triggere Tilkobling og Triggere Lars Vidar Magnusson October 12, 2011 Lars Vidar Magnusson () Forelesning i DAS 11.10.2011 October 12, 2011 1 / 25 Tilkobling med PHP PHP bruker databasespesifike moduler til å koble

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

Scrum. -nøkkelbegreper og noen personlige erfaringer

Scrum. -nøkkelbegreper og noen personlige erfaringer Scrum -nøkkelbegreper og noen personlige erfaringer Agile Manifesto Manifest for smidig systemutvikling Vi oppdager stadig nye og bedre måter å utvikle systemer på, både ved å gjøre det selv og ved å hjelpe

Detaljer

Innstallasjon og oppsett av Wordpress

Innstallasjon og oppsett av Wordpress Del 1 - Installasjon og oppsett Innstallasjon og oppsett av Wordpress Wordpress har blitt en veldig populær publiseringsplattform for websider. Uten særlige tekniske ferdigheter kan man sette opp profesjonelle

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

file:///c:/users/michaelp/sites/dkdm/dw6/dreamweaver6.html

file:///c:/users/michaelp/sites/dkdm/dw6/dreamweaver6.html 1 of 9 15.04.2015 14:15 Spry og behaviours Både Spry and Behaviours er basert på programmeringsspråket Javascript. Javascript kjører i nettleseren og ikke på webserver som PHP og Perl. På en lignende måte

Detaljer

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

HOVEDPROSJEKT. Studieprogram: ingeniørfag - data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 2010-04 Studieprogram: ingeniørfag - data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET ÅPEN Telefon: 22 45 32 00 Telefaks: 22 45 32

Detaljer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

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

Innovasjonsvennlig anskaffelse

Innovasjonsvennlig anskaffelse UNIVERSITETET I BERGEN Universitetet i Bergen Innovasjonsvennlig anskaffelse Fredrikstad, 20 april 2016 Kjetil Skog 1 Universitetet i Bergen 2 Universitetet i Bergen Driftsinntekter på 4 milliarder kr

Detaljer

Vedlegg Side 83 av 155

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

Detaljer

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

Tyrannosaurus Test Adapt or Die!

Tyrannosaurus Test Adapt or Die! Tyrannosaurus Test Adapt or Die! Testdagen Odin 2014 Remi Hansen & Christian Brødsjø 26.09.2014 Promis Qualify AS 1 Om oss og tema Dinosaurer og evolusjon Context-driven testing filosofi og prinsipper

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

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

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

Compello Invoice Approval

Compello Invoice Approval Compello Invoice Approval Godkjenning Webmodul brukerdokumentasjon Nettbrett og desktop via nettleser Index 1 Innledning... 3 2 Funksjonalitet... 4 Nettbrett og desktop via nettleser... 4 2.1.1 Desktop

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

Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold. Ove Dalen

Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold. Ove Dalen Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold Ove Dalen There is a lack of discipline in many web publishing processes because managers in charge of websites often don't respect

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

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

Prosjektstyring, metodikk og løsningsutforming for SAP prosjekter. Sveinung Gehrken Fram

Prosjektstyring, metodikk og løsningsutforming for SAP prosjekter. Sveinung Gehrken Fram Prosjektstyring, metodikk og løsningsutforming for SAP prosjekter Sveinung Gehrken Fram Til diskusjon Hva kjennetegner vellykkede SAP prosjekter? Hvilken metodikk skal man velge? Noen tanker om løsningsvalg

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

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

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

PowerOffice Server Service

PowerOffice Server Service PowerOffice Server Service 20 14 Po we ro ffice AS - v4.5.1 PowerOffice SQL - PowerOffice Server Service Alle rettigheter reservert. Ingen deler av dette arbeidet kan reproduseres i noen form eller på

Detaljer

lagring med HTML5 Offline lagring Offline Informasjonsteknologi 2 Gløer Olav Langslet Sandvika VGS

lagring med HTML5 Offline lagring Offline Informasjonsteknologi 2 Gløer Olav Langslet Sandvika VGS Offline lagring med HTML5 Gløer Olav Langslet Sandvika VGS Leksjon 8 Informasjonsteknologi 2 Offline lagring I IT1 brukte vi databaser til å lagre data. Der kunne vi bygge tabeller og fylle dem med innhold

Detaljer

Entobutikk 2.PRODUKTRAPPORT VÅR 2011

Entobutikk 2.PRODUKTRAPPORT VÅR 2011 2.PRODUKTRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne produktrapporten inneholder detaljer om produktet vi har utviklet samt programmessig oppbygning, illustrasjoner, diagrammer over produktet, funksjoner

Detaljer

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM Scrum Master og Product Owner i Høst 2015 1 Om Scrum Scrum er et populært rammeverk laget med henblikk på å utvikle komplekse informasjonssystemer.

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. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

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

Final Projectreport. 091214 - Gry Skårbø

Final Projectreport. 091214 - Gry Skårbø Final Projectreport 091214 - Gry Skårbø December 2, 2009 Contents 1 Forord 5 2 Terminologi 6 2.1 Begreper................................ 6 2.2 Forkortelser.............................. 6 3 Innledning

Detaljer

BIBSYS Brukermøte 2011 Live Rasmussen og Andreas Christensen. Alt på et brett? -om pensum på ipad og lesebrett

BIBSYS Brukermøte 2011 Live Rasmussen og Andreas Christensen. Alt på et brett? -om pensum på ipad og lesebrett BIBSYS Brukermøte 2011 Live Rasmussen og Andreas Christensen Alt på et brett? -om pensum på ipad og lesebrett Prosjektet epensum på lesebrett Vi ønsker å: Studere bruk av digitalt pensum i studiesituasjonen.

Detaljer

Mandag 09. januar 2012 Torsdag 12. januar 2012 Søndag 15.januar 2012 Mandag 16. januar 2012 Onsdag 18. januar 2012 Torsdag 19.

Mandag 09. januar 2012 Torsdag 12. januar 2012 Søndag 15.januar 2012 Mandag 16. januar 2012 Onsdag 18. januar 2012 Torsdag 19. Dagbok HP_22 Mandag 09. januar 2012 I dag møtte vi veileder Larissa Sjarbaini for første gang. Hva som ble tatt opp på møtet kan leses ut ifra sakslisten i dokumentet HP22_uke02_Erik_møte.pdf. Videre skrev

Detaljer

Brukermanual - Joomla. Kopiering av materiale fra denne Bonefish manualen for bruk annet sted er ikke tillatt uten avtale 2010 Bonefish.

Brukermanual - Joomla. Kopiering av materiale fra denne Bonefish manualen for bruk annet sted er ikke tillatt uten avtale 2010 Bonefish. Brukermanual - Joomla Bonefish brukermanual - Joomla Gratulerer med ny nettside fra Bonefish. Du er nå blitt eier og administrator for din egen nettside, noe som gir deg visse forpliktelser ovenfor din

Detaljer

Social Media Insight

Social Media Insight Social Media Insight Do you know what they say about you and your company out there? Slik fikk Integrasco fra Grimstad Vodafone og Sony Ericsson som kunder. Innovasjon og internasjonalisering, Agdering

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

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

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1 INNHOLDSFORTEGNELSE VEDLEGG 1 KRAVSPESIFIKASJON... 03 VEDLEGG 2

Detaljer

1. Intro om PowerShell

1. Intro om PowerShell Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Intro til PowerShell Stein Meisingseth 15.05.2014 Lærestoffet er utviklet for faget IDRI3005 PowerShell 1. Intro om PowerShell Resymé: Denne

Detaljer

the web Introduksjon Lesson

the web Introduksjon Lesson Lesson 1 the web All Code Clubs must be registered. Registered clubs appear on the map at codeclub.org.uk - if your club is not on the map then visit jumpto.cc/18cplpy to find out what to do. Introduksjon

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

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

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

Detaljer