Prosessrapport. Gruppe 23

Transkript

1 Prosessrapport Gruppe 23

2

3 Prosessrapport Gruppe 23 Prosessrapport Forord Denne rapporten beskriver hvordan vi planla og gjennomførte prosjektet. Den beskriver hva vi syns vi har gjort bra og hva vi kunne gjort bedre, hvilke problemer vi har støtt på, hvilke begrensinger vi har hatt og hvordan vi har utnyttet de mulighetene vi har hatt. Om Oppdragsgiver Kort om ABB ABB utvikler kostnadseffektive, pålitelige og miljøvennlige løsninger og teknologier for kraftbransjen. ABBs automasjonsvirksomhet er verdensledende når det gjelder komplette elektro- og automasjonssystemer til industriell produksjon, særlig bil-, olje- og gass-, skips-, papir- og metallindustrien. Utvikling av ny teknologi og integrerte totalløsninger forbedrer industriens kostnads- og ressurseffektivitet, produksjonskvalitet og produktivitet. Forskningssenteret for Olje, Gass og Petrokjemi ABBs forskningsgruppe med globalt ansvar for Olje, Gass og Petrokjemi er lokalisert i Oslo. Forskningssenteret samarbeider både med forretningsenhetene for onshore og offshore samt sluttkundene. Forskningssenterets viktigste ansvarsområder er å levere forskning og teknologisk innovasjon på et høyt nivå, å utvikle teknologi som er helt i forkant og å skape verdi for ABB og ABBs kunder. Forskningsgruppen for Olje, Gass og Petrokjemi fokuserer på teknologidrevet innovasjon, primært innen automasjon. Forskningsgruppens kjernekompetanse og laboratoriefasiliteter omfatter følgende strategiske områder: Interaksjon og visualisering Kontroll, modellering og prosessimulering Engineering efficiency Instrument- og prosessovervåking Trådløs kommunikasjon Pervasive computing Forskningsgruppen samarbeider tett med nasjonale og internasjonale forskere og akademiske institusjoner. Oppgaven ABB ønsket en applikasjon som kunne gjøre tilgjengeligheten av P&ID diagrammer elektronisk. For mer informasjon om P&ID diagrammer. Dagens situasjon er et papirbasert permsystem for diagrammene. Vi fikk i oppgave å lage en applikasjon som kunne vise disse diagrammene elektronisk. De ønsket et oppsett der diagrammene kunne være en representasjon av den geografiske plasseringen av prosesser ved en oljeplattform, hvor da operatører kunne bruke sin erfaring og kunnskap om oljeplattformen til å navigere seg blant P&ID diagrammene. Brukeren av applikasjonen skulle også kunne ha mulighet til å zoome inn og ut på diagrammene for å se detaljer i bildet. Denne applikasjonen skulle fungere på en horisontal flerberørings skjerm og legge til rette for samarbeid mellom flere brukere. Applikasjonen skulle utvikles i C# og Windows Presentation Foundation i.net rammeverket. Se Produktrapport Vedlegg Teknologispesifikasjon for mer informasjon om teknologien. Prosessrapport Side 3

4 Prosessrapport Gruppe 23 Innhold 1. Planlegging Oppstartsfasen Gruppevalg Konkretisering av prosjektet Hjemmeside Forprosjektet Valg av metodikk Fordeling av arbeidstimer Klargjøring av arbeidsplass Utarbeidelse av kravspesifikasjon Dokumentering av fremdrift Forkunnskap Læringsprosess Utførelse Integrering i arbeidsmiljø Praktiske utfordringer Arbeidsplass Arbeidsdagbok Disponering av tid Tekniske utfordringer Utfordringene ved horisontal berøringsskjerm Utvikling i WPF Backup Bruk av metodikk Par-programmering Iterasjonsgjennomføring Læring Brukergrensesnitt Design Berøring Testing Test prosessen Akseptansetesting Brukertesting Videreutvikling Konklusjon Referanser Prosessrapport Side 4

5 Prosessrapport Gruppe 23 4 Referanser Vedlegg - Statusrapport Vedlegg - Prosjektskisse Vedlegg - Tidslinje Vedlegg - Timeregnskap Vedlegg - Fremdriftsplan Vedlegg - Dagbok Prosessrapport Side 5

6 Prosessrapport Gruppe Planlegging 1.1 Oppstartsfasen Gruppevalg Vi oppdaget første året sammen som IT-studenter at vi samarbeider bra og vi har siden jobbet sammen på de fleste prosjekter og innleveringer. Derav kjente vi godt hverandres måte å jobbe på og hadde innarbeidet en god kommunikasjon. Vi ønsket begge å ha liten gruppe, og siden oppgaven vi søkte på hos ABB var for en liten gruppe så søkte vi om disposisjon til å være bare oss to Konkretisering av prosjektet Prosjektperioden startet da vi søkte på prosjektet hos ABB den 22. oktober Siden Borghild da var utvekslingsstudent i New Zealand gikk Kamilla på intervju med ABB 26. oktober Oppgaven ble tildelt oss den 29. oktober 2009 og vi satte allerede da i gang med å konkretisere oppgaven, tenkte på hvilken metodikk vi skulle velge, og sende praktisk ting. Det første som skulle leveres inn var en statusrapport den 30. oktober Dette skulle være et lite dokument som inneholdt informasjon om hvor langt vi hadde kommet i letingen etter hovedprosjekt. Se Vedlegg Statusrapport. Neste milepæl var en prosjektskisse som skulle innleveres den 4. desember Denne skulle inneholde informasjon om oppdragsgiver og generelt om oppgaven. Se Vedlegg - Prosjektskisse Hjemmeside For å presentere vårt prosjekt for verden lagde vi en enkel nettside med informasjon om prosjektet og om oss. Her kunne vi dele dokumenter slik at både veileder fra Høgskolen i Oslo (HiO) og fra ABB hadde tilgang til det vi hadde av dokumenter. Dokumentene ville blant annet være kravspesifikasjonen, iterasjonsplanen, rapporter, prosjektdagboken. Hjemmesiden kan sees på hjemmeområdet til Kamilla Rust på adressen Forprosjektet Valg av metodikk Vi startet vårt forprosjekt den 5. januar. Vi var begge enige om at vi ville jobbe etter en agil metodikk. Denne type metodikk sees på som den nyeste og mest effektive måten å arbeide med et IT-prosjekt på. Vi brukte noe tid på å se på forskjellige agile metoder og endte til slutt med å velge Extreme Programming (XP). Grunnelementene til XP er tett samarbeid med oppdragsgiver korte iterasjoner testing brukerhistorier par-programmering XP er en prosessmodell der utviklingen skal foregå i tett samarbeid med oppdragsgiver. Med tett menes det at oppdragsgiver tar del under hele utviklingsprosessen gjennom testing av brukergrensesnitt og funksjonalitet. Utviklingsprosessen deles opp i iterasjoner, disse skal helst være korte og testbare. Fordelen med dette er at utviklingen blir fleksibel, hvor endringer i krav og Prosessrapport Side 6

7 Prosessrapport Gruppe 23 teknologi kan enkelt implementeres. Oppdragsgiver blir presentert for implementert funksjonalitet så tidlig som mulig, og får mulighet til å gi tilbakemelding ved hver iterasjon. Dette vil også gi oppdragsgiver en oversikt over hvor langt utviklingen har kommet. Oppdragsgiver får anledning til å gi tilbakemeldinger og kontrollere funksjonalitet gjennom akseptansetester. Hvis en akseptansetest ikke blir godkjent av oppdragsgiver må iterasjonen gjøres på nytt for å rette opp i de feil og/eller mangler oppdragsgiver måtte påpeke. I XP skal det også dokumenteres lite i forkant av utviklingen. Selv om man alltid setter opp en kravspesifikasjon skal ikke denne sees på som ferdig før utviklingen starter. På denne måten kan kravene fra oppdragsgiver omprioriteres, forandres eller fjernes gjennom hele prosjekttiden. Det skal også være mulig å legge til nye krav uten at dette skal bli et problem for utviklingsprosessen. Kravene fra oppdragsgiver skal fremstilles som brukerhistorier. Brukerhistorier er en beskrivelse av ønsket funksjonalitet fra oppdragsgiver. Disse skal beskrives på formen: Som bruker vil jeg kunne funksjonalitet fordi begrunnelse. Et eksempel kan være Som bruker vil jeg kunne skalere bildet jeg ser på fordi da kan jeg bedre kan se detaljer i bildet. Disse blir da utgangspunktet for utviklingen av systemet og er også grunnlaget for testing. Under utviklingen kan par-programmering benyttes. Par programmering går ut på at to programmerere sitter ved én skjerm og partene bytter på å skrive. Fordelen med par-programmering er at kvalitet på koden blir bedre ettersom utviklingen følges av to par øyne og man har kompetansen fra begge programmerere tilgjengelig. Det er viktig at begge programmererne er inneforstått med brukerhistorien som skal løses før de begynner. Da er det lettere å kommunisere underveis i utviklingen. En ulempe ved XP er at det er veldig få krav som blir fastsatt på forhånd. Derfor kan det være utfordrende å sette seg inn i prosjekter som følger denne metodikken. En annen ulempe er hvis oppdragsgiver ikke har anledning til, eller ønske om, å jobbe så tett med utviklingen av applikasjonen. Når oppdragsgiver da blir presentert for applikasjonen ved slutten av utviklingsprosessen, kan oppdragsgivers forventninger og krav blitt misforstått og applikasjonens funksjonalitet ikke er slik oppdragsgiver forventet. Dette kan resultere i at utviklingen må i verste tilfelle starte helt på nytt, eller fra et tidligere tidspunkt i utviklingen. Og prosjektet må bruke flere ressurser enn planlagt, ved økte kostnader og tid. Vi valgte XP av forskjellige grunner. En grunn var at det passet oss som liten gruppe bedre. Vi var ikke avhengig av å ha en prosessmodell som krevde mye dokumentasjon ettersom vi bare var to personer og kom til å jobbe tett sammen i løpet av prosjektet. En annen grunn var på bakgrunn av hvilken type oppgave vi hadde. I vårt tilfelle det var å utvikle en applikasjon hvor oppdragsgiver ville ta stor del i utviklingen. Men de fokuserte også på at de ønsket innspill fra oss om muligheter i funksjonalitet og brukergrensesnitt. Her passet fleksibiliteten til XP godt inn, og kravet om at oppdragsgiver skal være en del av testing av iterasjoner. Det var også positivt at XP hadde mulighet for par-programmering. Dette ville vi teste ut etter å ha hørt mye positivt om denne måten å kode på. Hvis vi fikk tilgang på en arbeidspult med plass til to, en skjerm og et tastatur ville da vi par-programmere Fordeling av arbeidstimer Vi bestemte oss for å følge standarden for en vanlig arbeidsuke, det vil si en arbeidsdag på 8 timer og en arbeidsuke på 5 dager. Selv om dette var en mal var vi også inneforstått med at det ville bli mer arbeid mot slutten og i perioder med vanskelige oppgaver. Prosessrapport Side 7

8 Prosessrapport Gruppe 23 Vi bestemte også at vi ville sette en periode av prosjekttiden som skulle disponeres til produksjon av kode, altså utvikling av applikasjonen. Denne skulle være fra den datoen vi leverte forprosjektsrapporten, 29. januar 2010, til tre uker før endelig prosjektrapport innlevering, 31. mai Dette var fordi vi gjerne ville ha de siste tre ukene av prosjektperioden til å skrive ferdig rapporten. Det vil si at vi ville være ferdige med å kode den 7. mai Alle disse fristene er satt opp i en tidslinje, se Vedlegg - Tidslinje Prosjektet var ikke det eneste vi har måtte sette av tid til i prosjektperioden. Vi måtte dele arbeidstiden med C++ og GUI programmering, som var et annet fag vi tok. Planen var å bruke 2 dager på HiO med C++ og GUI programmering og tre dager på ABB med hovedprosjektet. Det vil si at i utgangspunktet skulle vi bruke 2/5 av tiden på C++ og GUI programmering og 3/5 av tiden på hovedprosjektet. Slik ville det bare være frem til uke 15, den 14. april 2010, da vi skulle levere inn siste innlevering i C++ og GUI programmering. Etter dette ville all tid gå med til prosjektet. Antall timer totalt for hele semesteret ville da fordele seg som vist i tabell 1 Uke / Fag C++ og GUI programmering Hovedprosjekt Timer totalt Tabell 1 Kommentar Vinterferie Påske Timer til sammen gruppe: 1120 Fordeling av timer Selv om dette var en fin mal på en normal arbeidsuke så visste vi begge at noen uker ville ha overtall av arbeidstimer på HiO når det var innleveringer i C++ og GUI programmering, mens andre uker ville ha overtall av arbeidstimer på hovedprosjektet. Dette var noe vi ikke bekymret oss noe over siden det ville jevnes ut automatisk. Prosessrapport Side 8

9 Prosessrapport Gruppe Klargjøring av arbeidsplass Den 7. januar møtte vi på ABB sine lokaler og vi ble godt tatt imot. Vi fikk med en gang et eget kontor i Research & Development avdelingen. Da vi forklarte metodikken vi skulle arbeide etter, Extreme Programming, og at vi gjerne ville par-programmere fikk vi også to skjermer, et tastatur og en mus til disposisjon. Disse kunne vi koble til våre egne bærbare maskiner. Dermed kunne vi par-programmere under utviklingen av applikasjonen. Figur 1 viser arbeidsstasjonen på kontoret. Det eneste som ikke kunne gjøres i denne perioden var å sette opp og gjøre den horisontale berøringsskjermen klar til bruk. Rommet denne skjermen hadde stått på før skulle pusses opp og ABB ville ikke sette den opp på vårt kontor da det var mye jobb å skru opp en projektor på et sted den bare kunne stå midlertidig. Derfor ville de vente til de hadde funnet et bedre sted å ha skjermen. Dette var ikke noe problem for oss da vi hadde planlagt å sette oss inn i teknologien vi skulle bruke den første tiden av utviklingsperioden og hadde dermed ikke bruk for å teste noe direkte på berøringsskjermen. Figur 1 Arbeidsstasjonen på kontoret Utarbeidelse av kravspesifikasjon Oppgaven beskriver et system som skal vise P&ID-diagrammer på en horisontal berøringsskjerm og legge tilrette for samarbeid mellom flere brukere. ABB hadde ikke satt opp noen kravspesifikasjon og hadde heller ikke noen krav til annen funksjonalitet enn at P&ID diagrammene skulle vises på skjermen på en logisk måte i forhold til hverandre. Dette var fordi de ville at vi som utenforstående skulle komme med nye ideer til utseende og funksjonalitet. Oppdragsgiver sa tydelig i fra at denne applikasjonen skulle utvikles for at ABB kunne se hva berøringsskjermen kunne brukes til og hvor nyttig en slik applikasjon kunne være. Vi mente at hvis vi skulle komme med forslag til hvordan brukergrensesnitt og funksjonalitet skulle utformes måtte vi ha bedre innsikt i hva et P&ID diagram er, hvordan de brukes og hvordan de fungerer i forhold til hverandre. Vi fikk noen hefter fra ABB, hvor vi kunne lese generelt om olje og gass næringen og et som innehold forklaring på P&ID diagram og komponentene som brukes i et diagram. Etter dette lagde vi et forslag til hvordan applikasjonen kunne se ut og hvilken funksjonalitet den kunne ha. Dette presenterte vi for oppdragsgiver og vi var begge raskt enige om brukergrensesnittet. Når det gjaldt funksjonalitet hadde oppdragsgiver noen flere ideer som også ble lagt til som brukerhistorier. Deretter satte oppdragsgiver opp en liste over funksjonalitet i prioritert rekkefølge, da vi begge var enige om at vi sannsynligvis ikke kunne implementere all funksjonalitet på den tiden vi hadde til disposisjon. Det var viktig for oss at den ferdige applikasjonen skulle inneholde den funksjonalitet som var prioritert høyest, og i løpet av prosessen legge til rette for eventuell videreutvikling av den funksjonaliteten med lavere prioritering. Av dette lagde vi en kravspesifikasjon. For mer informasjon, se Produktrapport Vedlegg Kravspesifikasjon. Prosessrapport Side 9

10 Prosessrapport Gruppe Dokumentering av fremdrift I Extreme Programming (XP) skal hver iterasjon være kort og testbar. Derfor lagde vi en iterasjonsplan hvor iterasjonene var så korte som vi mente det var mulig å få dem. Vi satte derfor som mål å gjøre ferdig en iterasjon hver uke. Iterasjonsslutt satte vi til torsdag fordi vi mente at hvis akseptansetesten ikke ble godkjent så ville vi ha fredagen til å endre koden og gjøre en ny akseptansetest. Siden vi hadde bestemt oss for å jobbe på ABB de tre siste dagene i uken var vi veldig usikre på om det var nok med to dager, onsdag og torsdag, til å gjøre ferdig en iterasjon. Vi bestemte oss for å prøve og eventuelt flytte iterasjonsslutt til fredag dersom det ble vanskelig. Vi forhørte oss med oppdragsgiver om dette oppsettet. De godkjente det og ville sette av tid til testing på torsdager, og eventuelt fredager hvis ikke testing ble godkjent på torsdag. Vi ville i utgangspunktet gjøre en brukerhistorie per iterasjon. Dette mente vi var et realistisk valg, med unntak av et par brukerhistorier som vi mente måtte gå over to iterasjoner. Siden oppdragsgiver hadde satt opp en prioritert liste av brukerhistorier ville vi bruke denne og begynne på toppen og arbeide oss nedover. Selv om listen var prioritert ville vi ikke sette opp alle brukerhistoriene i hver sin iterasjon før vi begynte. Vi bestemte at ved hver iterasjonsslutt skulle vi diskutere med oppdragsgiver om listen fortsatt var prioritert som ønsket, eller om det skulle gjøres endringer. Etter dette møtet ville vi velge den brukerhistorien som sto øverst på listen for neste iterasjon Forkunnskap Av de teknologiene vi skulle bruke i prosjektet så hadde vi kun grunnleggende kunnskaper i.net. Kamilla kjente noe til WPF, mens Borghild aldri hadde brukt det. Ingen av oss hadde kunnskap om berøringsskjermen vi skulle bruke. Derfor hadde vi heller ikke kjennskap til hvordan berøringsskjermen fungerte eller hvordan vi skulle få den til å kommunisere med vår applikasjon. En annen viktig del av oppgaven som vi ikke hadde kunnskap om var P&ID diagrammer. Vi måtte derfor ha en innføring i hva disse viser og hvordan en operatør bruker de. Vi mente det var viktig å få en viss kjennskap til dette siden tilsiktede brukere av applikasjonen var personer som har god kunnskap om slike diagrammer Læringsprosess Vi begynte med å lære oss hva et P&ID diagram er og hva de brukes til. Vi forstod raskt at vi ikke kom til å skjønne alt som ble fremstilt på diagrammet, men det var heller ikke relevant for hva vi skulle utvikle. Det som var viktig å forstå var at ett eller flere diagrammer kunne representere en prosess og på grunnlag av dette måtte vi finne en løsning på hvordan vi kunne lage et oppsett av alle diagrammene som skulle representere den geografiske plasseringen av prosessene på en oljeplattform. Etter dette satte vi oss bedre inn i de tekniske verktøyene. Vi startet med å lage små programmer i Microsoft Expression Blend som er et brukergrensesnittverktøy for web- og desktopapplikasjoner. For mer informasjon om Blend, se Produktrapport Vedlegg - Teknologispesifikasjon. Vi synes dette var lærerikt, men fant ut at vi ikke lærte like mye av dette som med å starte med utviklingsprosessen for så å ta utfordringene som de kom. Vi ville også finne ut hvordan berøringsskjermen fungerte. Men ettersom berøringsskjermen ikke var satt opp og klar til bruk var ikke dette mulig. 2 Utførelse 2.1 Integrering i arbeidsmiljø Arbeidsgiver var fra starten imøtekommende og opptatt av å integrere oss som en del av avdelingen. Vi ble oppfordret til å være med på sosiale hendelser, deriblant kake-fredag. Hver fredag hadde en Prosessrapport Side 10

11 Prosessrapport Gruppe 23 fra avdelingen i oppgave å ta med seg kake og hele avdelingen tok en pause fra arbeid. Dette ble en god anledning til å bli kjent med de andre ansatte og vi følte oss som en del av avdelingen. Vi ble også oppfordret til å spørre om hjelp uansett hva det skulle være. Dersom det var noe vi manglet av arbeidsverktøy og oppslagsverk ville de prøve å skaffe det så godt det kunne gjøres. Vi fikk også beskjed om å spørre programmererne ved avdelingen om tekniske spørsmål hvis vi hadde noen. Det var en person på avdelingen som hadde programmert mot berøringsskjermen før og han sa at vi kunne spørre om hjelp når det skulle være behov. 2.2 Praktiske utfordringer Arbeidsplass Da vi startet på prosjektet fikk vi tildelt et kontor i Research & Development avdelingen til ABB. Men den 28. januar ble kontoret overtatt av en regional sjef i ABB. Vår nye arbeidsstasjon ble da et kontor sammen med tre andre ansatte i avdelingen. Den horisontale skjermen ble også med på flyttelasset dit. Vi hadde samtaler med vår veileder fra ABB angående hvor skjermen skulle stå og hvor projektoren skulle bli plassert for vi ønsket å komme i gang med å programmere mot den raskt. Men rommet den sto på før var under oppussing, og det var ikke plass til å sette den opp inne på vårt nye kontor. Konklusjonen ble at den horisontale skjermen og projektoren skulle bli installert på demonstrasjonsrommet når det ble ferdig oppusset. Demonstrasjonsrommet ble klart 22.mars 2010 og det var først da vi fikk anledning til å programmere mot berøringsskjermen. Siden skjermen ble plassert inne på demonstrasjonsrommet ble det mer naturlig å arbeide der, for å få testet applikasjonen direkte på skjermen. Med unntak av de dagene rommet ble brukt til møter. Da kunne vi benytte oss av arbeidsplassen vi hadde til rådighet på kontoret og programmere der, men uten tilgang på berøringsskjermen Arbeidsdagbok Ved slutten av hver dags arbeid dokumenterte vi det vi hadde gjort, utfordringer og gjennombrudd i en arbeidsdagbok. Dette gjorde vi både for å ha et dokument med informasjon rundt arbeidsoppgavene og for å kunne avgjøre om mengden arbeidsoppgaver ved hver iterasjon var passe stor, samt bli flinkere på å evaluere tid på arbeidsoppgaver i brukerhistorier Disponering av tid I begynnelsen av prosjektet var det enkelt å holde timeplanen, men ettersom arbeidsmengden i C++ og GUI programmering faget steg så måtte vi stadig ofre tid av prosjektet for å kunne produsere gode innleveringer i faget. Vi brukte en del kvelder og helger for å holde tritt med kravene som ble satt i faget. Dette bekymret oss, og vi så oss nødt til å jobbe kvelder og helger for å holde oss til arbeidsplanen vi hadde satt opp. Dette synes vi har fungert fint og vi har ikke hatt altfor store avvik i iterasjonsplanen som vi satt opp i begynnelsen av utviklingen. For å kunne disponere tiden som vi hadde satt av til prosjektet riktig i forhold til funksjonaliteten ABB ville at vi skulle utvikle, måtte vi først skaffe oss et bilde over hvor lang tid ting kom til å ta. Vi bestemte oss for å gjøre en til to iterasjoner og deretter ta en diskusjon med veilederne fra ABB om hva vi mente var realistisk å få ferdig. De syntes dette var en god måte å gjøre det på siden vi allerede fra begynnelsen av prosjektet var enige om at all funksjonalitet ikke ville bli implementert. De første ukene av utviklingsperioden var vi optimistiske til hvor langt ned på listen med funksjonalitet vi kunne komme. Det var fordi testingen av applikasjonen disse ukene foregikk på PC og all input fra bruker forgikk ved hjelp av museklikk. Dette gjorde vi fordi det ikke var mulig å teste Prosessrapport Side 11

12 Prosessrapport Gruppe 23 på berøringsskjermen da den ikke var satt opp enda. Vi møtte på store utfordringer som tok lang tid da vi skulle integrere berøringsskjermen i vår applikasjon. Dette var et tidstap vi ikke hadde regnet med og vi måtte innse at det ikke kom til å bli tid til å implementere all funksjonalitet som var beskrevet i kravspesifikasjonen. Vi mener selv at den tiden vi satte av til prosjektet har var tilstrekkelig og at vi har jobbet godt i denne tiden. Arbeidet med C++ faget tok derimot mer tid enn antatt, og det gikk på bekostning av den avsatte tiden til prosjektet. Men tidsmessig føler vi at vi har hatt det under kontroll. For mer informasjon om hvor mange timer vi har brukt på prosjektet, se Vedlegg Timeregnskap. 2.3 Tekniske utfordringer Utfordringene ved horisontal berøringsskjerm Kompabilitet Applikasjonen vår skulle utvikles for å kunne kjøres på en horisontal berøringsskjerm som hadde sin eget Software Development Kit(SDK). SDK er en pakke med programvare som skal gjøre det mulig å utvikle applikasjoner med den teknologien SDK tilhører. DiamondTouch sin SDK inneholder biblioteker som kunne kommunisere med berøringsskjermen og et program som simulerer museklikk ved berøring. SDK en er utviklet for Windows XP/Vista. SDK en støtter mange språk, også C#, men utfordringen i C# var at det måtte brukes en ActiveX kontroll for å få tilgang på bibliotekene. For mer informasjon om ActiveX, se Produktrapport Vedlegg Teknologispesifikasjon. Vi forsto at det ikke bare var å legge til disse bibliotekene i vårt prosjekt, men at ActiveX kontrollen måtte legges til på en annen måte. Etter å ha søkt mye på nettet fant vi ut at for å inkludere en ActiveX kontoll i en WPF applikasjon måtte vi legge den til igjennom et Windows Forms Control Library. Dette er et bibliotek for å lage kontrollere til bruk i Windows Forms porsjekter. Windows Forms er forgjengeren til WPF i å tilby brukergrensesnitt komponenter i.net rammeverk. For å kunne aksesere bibliotekene til den horisontale berøringsskjermen måtte vi derfor inkludere et Windows Forms Control Library i vårt prosjekt for så å inkludere ActiveX kontrollen i dette biblioteket og aksesere det derifra. Dette viste seg å være komplisert, fordi enda vi hadde fått dette til ville fortsatt ikke applikasjonen kompilere og vi fikk feilmeldinger som var vanskelig å tolke. Vi brukte mye tid på å feilsøke på internett, men fant ikke mye hjelp der. Vi kontaktet Håkon Berg (ABB) som hadde jobbet med berøringsskjermen før, i håp om at han kunne forklare feilmeldingene og hjelpe med integrering av ActiveX i WPF prosjektet. Han hadde litt erfaring med inkluderingen av ActiveX, men han hadde programmert i et eldre.net rammeverk og en eldre versjon av Visual Studio. Etter mye søking på internett og hjelp fra Håkon fant vi løsningen og kunne starte med å skrive kode som inkluderte bibliotekene til SDK en. Dette problemet var et av de største vi har hatt i utviklingsperioden. Vi var allerede fra starten usikre på hvordan vi skulle kommunisere med SDK en til den horisontale berøringsskjermen, men hadde ikke ventet oss at det skulle ta så lang tid å finne en løsning som det gjorde. Dessverre tok det tid før skjermen ble klar til bruk og i ettertid ser vi at vi kunne med fordel ha undersøkt hva integreringen av skjermen og WPF ville kreve. Dette kunne gitt oss en anledning til legge til rette en applikasjon som kunne kommunisere med skjermen når den var klar til bruk. Prosessrapport Side 12

13 Prosessrapport Gruppe 23 Berøring og kalibrering Berøringsskjermen er bygget opp av et rutenett med metalltråder som reagerer på at en strømkrets sluttes. For å slutte denne kretsen må brukeren, som står på en matte, berøre skjermen. Da vil en Faktisk berøring Hva skjermen oppfatter Faktisk berøring Hva skjermen oppfatter Faktisk berøring Hva skjermen oppfatter Figur 2 Berøring av flere brukere flere steder på skjermen spenning fra bordet gå igjennom brukeren, til matten og tilbake til skjermen igjen. Når en berøring av skjermen registreres, blir dette berøringspunktet registrert som et område uttrykt med to punkter. Det ene punktet er Figur 3 Berøring av én bruker flere steder på skjermen berøringsområdets øverste venstre punkt og det andre er berøringsområdets nedre høyre punkt. Det vil si at en berøring med en finger vil utgjøre en liten firkant, mens en berøring med to fingre vil utgjøre en firkant mellom disse se figurene 2, 3 og 4. Disse metalltrådene ligger tett, slik at det er et stort potensial for nøyaktighet, men også for høy sensitivitet. Dette ga en utfordring ved at en berøring ikke bare ville tolkes som en berøring, på grunn av denne sensitiviteten, men som flere. Dette kommer av at man vil Figur 4 Berøring av én bruker ett sted på skjermen sjeldent klare å holde, for eksempel, en finger helt i ro. Derfor vil skjermen oppfatte alle små bevegelser som selvstendige berøringer. Berøringens nøyaktighet er også avhengig av at skjermen er riktig kalibrert i forhold til projektoren, noe som måtte utføres stadig og ofte flere ganger på rad for å optimalisere berøringsnøyaktigheten. Figur 5 viser gjennombruddet vi hadde da vi fikk integrert berøringshendelser på skjermen i applikasjonen. Prosessrapport Side 13

14 Prosessrapport Gruppe 23 Figur 5 Applikasjonen er integrert med berøring fra skjermen Støy Ettersom berøringsskjermen reagerer på strøm oppstod det i blant situasjoner med elektriske forstyrrelser fra andre elektriske apparater, som våre datamaskiner og til tider fra kilder vi ikke kunne finne opphavet til. Fenomenet gikk ut på at skjermen registrerte disse strømforstyrrelsene og tolket de som berøringer, som da førte til tilfeldig oppførsel i vår applikasjon. Brukere ble derfor opplyst om at det kunne forekomme slike hendelser i applikasjonen Utvikling i WPF Dynamisk innlesning av XAML filer Både vi og oppdragsgiver ønsket en dynamisk innlesning av kart med P&ID diagrammer på. Dette skulle gjøres ved innlesning av en XAML fil som inneholdt en oppbygning av diagrammer for et kart. Da kunne en bruker velge et kart ut ifra hvilken plattform hun ville se på og applikasjon kunne lese inn tilhørende XAML fil til kartet, og applikasjonen ville ikke vært bundet til et kart. Vi prøvde en stund på denne løsningen, men fikk det aldri til. Vi fikk til dynamisk innlasting av WPF sine kontroller med XAML, men ikke med våre egendefinerte UserContol s. Etter vi hadde brukt en del tid på å finne ut hvordan dette skulle gjøres, ble vi enige med oppdragsgiver om ikke å jobbe videre med denne funksjonaliteten. Det var ikke avgjørende for oppdragsgiver at applikasjonen fungerte slik, og vi ble enige om at det var bedre å bruke tid på viktigere funksjonalitet i applikasjonen. Selv om vi ikke implementerte denne funksjonaliteten så mener vi at den hadde vært nyttig. Derfor er den satt opp som en videreutviklingsmulighet. Bildeskalering i WPF Vi hadde ved starten av utviklingen fått et enkelt P&ID diagram av typen JPG, som vi benyttet ved å kopiere og sette flere av samme diagrammet sammen i en flyt av diagrammer. Denne flyten av diagrammer skulle representere den visuelle oversikten over alle diagrammene på en oljeplattform. Når applikasjonen skalerte dette diagrammet ble komponentene i diagrammet uklare og ikke lesbare. Dette trodde vi var kun pga at det var dårlig oppløsning på bildet vi hadde brukt som diagram. Men det viste seg senere at det var ikke bare bildet, men også hvordan WPF skalerer bilder i applikasjoner. For selv om vi hadde fått diagrammer i god oppløsning og forskjellige bildeformat, hadde applikasjonen fortsatt problemer med å vise de tydelig i forskjellige skaleringsnivåer. Applikasjon hakket også ved skalering og panorering. Oppdragsgiver hadde vært borti en slik problematikk selv, og trodde årsaken stammet fra hvordan WPF skalerer bildeformater og hvordan WPF behandler piksler mot dpi. Prosessrapport Side 14

15 Prosessrapport Gruppe 23 En piksel er et av de mange små punkter som til sammen utgjør en representasjon av et bilde på skjerm. Men en piksel i WPF er ikke en faktisk piksel etter definisjonen, men en uavhengig virtuell enhet. DPI (dots per inch) er en system-innstilling, som beskriver størrelsen av en skjerm tomme i piksler. De fleste Windows systemer har en DPI på 96, som betyr at en tomme på en skjerm er 96 piksler. Hvis man øker DPI innstillingen vil det gjøre skjerm tommen større, og omvendt. WPF skalerer automatisk sine piksler med systemets DPI innstilling. Dette gjør WPF uavhengig av oppløsninger og systemer. Etter å ha justert sin virtuelle enhet, bruker WPF anti-aliasing når den skalere. Når man benytter anti-alias brukes et triks som får elementer til å virke mer glatte og avrundede, enn kantete og skarpe som man ville fått ved å skalere opp elementer. Samtidig bruker den en algoritme for å skalere ved ulike valg av kvaliteter, og ved høy kvalitet kan WPF komme til å bruke en del system ressurser. Dette vil føre til at animasjoner og applikasjoner kan henge seg opp. Figur 6 Forskjellige visninger av P&ID diagrammene i applikasjonen For å håndtere denne problematikken er det et valg som kan sette hvilket modus WPF skal skalere i, RenderOptions.BitScalingMode. Her kan det velges ulike kvaliteter på skalering, hvor Fant er den høyeste kvaliteten men også den tregeste og Linear det motsatte. Men tiltross dette valget, har vi fortsatt et estetisk problem. Vi finner ingen mellomting, som gir fine diagrammer skalert helt ut og inn. Enten har vi klare diagrammer i liten skalering og stor skalering, men en tregere applikasjon som kan til tider henge seg opp. Ellers får vi uklare diagrammer ved liten skalering og klare diagrammer ved stor skalering, men raskere applikasjon. Figur 6 viser de ulike kvalitetene ved utskalering på diagrammene, hvor venstre er Linear og høyre er Fant. Vi har valgt Fant som skaleringsmodus og unngår at applikasjonen hakker ved å justere den faktiske høyden og bredden til diagrammene Sikkerhetskopiering Siden vi valgte å par-programmere synes vi det var bortkastet å bruke tid og ressurser på å bruke versjonskontroll for å lagre endringer. Vi forhørte oss også med oppdragsgiver om dette, og de var enig i at det var mer arbeid å sette opp en slik løsning enn det vi fikk igjen for det siden vi uansett kom til å kode sammen hele tiden. Når de heller ikke stilte krav om å bruke det lot vi være å bruke det. Selv om vi ikke valgte å bruke versjonskontroll måtte vi jo selvfølgelig ha en form for sikkerhetskopiering. Vi valgte en enkel løsning med å lagre kopier av prosjektet på en USB penn i løpet av utviklingen, som vi lot ligge ved arbeidsstasjonen på ABB. Siden vi utviklet applikasjonen på Kamilla sin PC hadde vi i tillegg alltid den siste versjonen av applikasjonen der. Derfor ville vi alltid ha Prosessrapport Side 15

16 Prosessrapport Gruppe 23 en kopi av siste versjon på en alternativ lagringsenhet, dersom det skulle forekomme tap av versjon ved en av enhetene. Vi forsto at det ville vært lærerikt å benytte versjonskontroll, ettersom vi ikke hadde benyttet dette mye før. Men vi mener løsningen vi valgte har fungert godt og har spart oss mye tid og ressurser som ville gått med til å sette seg inn i bruk av versjonskontroll. 2.4 Bruk av metodikk Par-programmering Vi hadde innledningsvis begrenset kunnskap i teknologiene som skulle brukes, og det ble vanlig at den som hadde et forslag til løsning tok styringen og den andre tok ansvaret med å slå opp i oppslagsverk problemene vi støtte på i løpet av utviklingen. Utviklingsprosessen vår ble preget av mye prøv og feil. Dette ble vanskelig for andre parten å sette seg inn i og det ble vanskelig å kommentere koden til den som programmerte. Kommunikasjon av tankegangen til den som programmerte var også vanskelig å utøve, for ved begges tilfelle gikk all konsentrasjon og fokus til å utforme den potensielle løsningen. Da vi fikk anledning til å integrere berøring, fikk andre parten i tillegg ansvaret for testing på berøringsskjermen, og vi merket at etter hvert som vår forståelse av teknologien bak skjermen og vår programmeringskunnskap økte ble det lettere for andre parten å følge programmeringen til første parten. Vi mener at for at XP skulle ha vært effektiv for oss burde vi hatt bedre forkunnskaper innenfor teknologiene vi benyttet. Vi mener det gikk tapt ressurser, da spesielt tid, ved bruk av XP. Og i vårt tilfelle kunne læringsprosessen hatt en raskere progresjon dersom begge kunne programmert parallelt Iterasjonsgjennomføring Under iterasjonsplanleggingen valgte vi antall brukerhistorier som skulle være med i iterasjonen, avhengig av hvor omfattende de var og hvor mye kunnskap vi måtte tilegne oss. Vi fikk noen forslag og tips til bruk av teknologi ved enkelte brukerhistorier fra oppdragsgiver, mens andre måtte vi finne løsninger til selv. Når en brukerhistorie krevde tilegnelse av ny kunnskap for å kunne løse den beregnet vi dette med i arbeidsoppgavene til iterasjonen. Det vil si at vi estimerte tiden ut i fra hvor lang tid det ville ta for å tilegne seg den nye kunnskapen og Figur 7 hvor lang tid det ville ta for å utføre arbeidsoppgaven. Iterasjonssyklus Figur 7 viser hvordan en iterasjon ble gjennomført, hvor starten øverst er iterasjonsplanleggingen og i den fasen ble det valgt hvilke brukerhistorier som skulle implementeres i iterasjonen. Når antall brukerhistorier var blitt valgt, og oppgaver nedtegnet ble utviklingen satt i gang. Ved tekniske utfordringer benyttet vi spikes. En spike er et enkelt program som blir laget for å utforske mulige Prosessrapport Side 16

17 Prosessrapport Gruppe 23 løsninger på det tekniske problemet. Et eksempel på en spike var da vi skulle animere et av objektene i applikasjonen vår. Siden ingen av oss hadde brukt animasjon i WPF før, laget vi en spike der vi utforsket hvordan en animasjon fungerte. Vi kunne selvsagt også utforsket dette direkte i hovedapplikasjonen, men poenget bak en spike er å redusere risikoen for feil ved å kun se på et problem om gangen. Når vi hadde funnet ut hvordan vi skulle løse det tekniske problemet implementerte vi spiken i hovedapplikasjonen. Når en implementasjon av iterasjonen var blitt klar, måtte den testes, les mer om testing i avsnitt 2.6. Ved hver iterasjonsslutt snakket vi med oppdragsgiver og forhørte oss om listen med brukerhistorier var fortsatt prioritert riktig eller om det var noen ønskelige forandringer. Det ble ingen forandringer i listen før 14. april Da hadde vi et statusmøte med oppdragsgiver for å avklare hvor mye tid vi hadde igjen og hvor mange flere brukerhistorier vi fikk tid til å fullføre. Vi visste allerede fra starten av prosjektet at vi ikke ville få ferdig alle brukerhistoriene, men vi ville nå velge ut de siste slik at begge parter fikk en forståelse av hva sluttproduktet ville inneholde av funksjonalitet. Vi fant ut sammen at vi ville flytte opp fire brukerhistorier som vi synes var mer nyttig å implementere enn de som allerede sto øverst på listen. Disse brukerhistoriene var Navigering i radardisplayet Notat ark Lagring av notat ark Objekt informasjon 2.5 Læring I løpet av planleggingsperioden prøvde vi å tilegne oss kunnskap i.net og WPF ved å gi oss selv små oppgaver som vi trodde kunne være relevante for prosjektet. Dette gikk vi vekk i fra og bestemte at det var bedre å begynne på applikasjonen vi skulle utvikle og heller ta utfordringene underveis. En teknikk vi brukte ved utfordringer, som viste seg å være veldig lærerikt, var å lage en spike. Hver gang vi ikke kunne løse et problem med vår kompetanse hadde vi følgende valg søke etter svar på Internett finne svar i litteraturen vi hadde tilgjengelig spørre ansatte i ABB Det å søke svar på Internett har vært den beste informasjonskilden for oss når det gjelder informasjon angående.net og WPF. I tillegg til Internett hadde vi to bøker om WPF, som ABB stilte til disposisjon. Bøkene brukte vi hyppig og de var ofte til hjelp. Men det var også et par ganger veilederene fra ABB kunne komme med forslag til alternativer løsninger enn de vi hadde valgt. Når det gjaldt den horisontale berøringsskjermen var det vanskeligere å finne informasjon. DiamondTouch hadde et eget forum på Internett som vi fikk tilgang til, men denne siden var ikke oppdatert siden 2008 og det var liten aktivitet der. Når berøringsskjermen endelig var tilgjengelig, brukte vi mye tid på å finne ut hvordan vi skulle få berøringsskjermen og applikasjonen til å snakke med hverandre. Ved dette tilfellet var vi heldige å ha tilgjengelig en person fra ABB som hadde utviklet applikasjon for berøringsskjermen før. Selv om det var lenge siden han hadde utviklet sin applikasjon var han til god hjelp og kunne gi tips og råd om utvikling og hvordan skjermen fungerte. Prosessrapport Side 17

18 Prosessrapport Gruppe Brukergrensesnitt Design Ved utforming av utseende til applikasjonen har vi tatt hensyn til oppdragsgivers ønske om nøytralt utseende og stort fokus på brukervennlighet. Figur 8 illustrerer brukergrensesnittet i applikasjonen ved oppstart. Figur 8 Brukergrensesnitt ved oppstart Fargevalg Vi har valgt å ha bakgrunner i grå-toner. Grå mener vi er en nøytral farge og vil ikke være sjenerende for brukeren. For markeringsfirkanten i radardisplayet, som viser hvor man er i applikasjonen, har vi valgt fargen gul-grønn. Denne fargen måtte skille seg ut fra de andre valgte fargene, derfor har vi valgt en farge som ikke er like nøytral som bakgrunnsfargen. Vi har valgt svart som farge på de grafiske ikonene. Denne fargen har fin kontrast til de andre fargene som er brukt og vil gjøre de lette å oppdage. Grafiske ikoner Ved utforming av ikonene har vi valgt å bruke metaforer for å vise funksjonaliteten til ikonene. Vi har også brukt prinsippene rundt affordance (Norman, 2004). Når man snakker om et fysisk objekts affordance så snakkes det om de faktiske og oppfattede egenskapene ved et objekt som avgjør hvordan det kan brukes. I vårt tilfelle er det et virtuelt objekt sin perceived affordance. Det vil si hva et virtuelt objekt inviterer til og hvordan en bruker oppfatter at det kan brukes, men at det ikke eksisterer i virkeligheten. Vi har forskjellige knapper som utfører forskjellig funksjonalitet i applikasjonen. De ulike knappene har et ikon som avbilder en metafor som skal representere funksjonen de har. Figur 9 viser henholdsvis de grafiske ikonene applikasjonen har fire piler. De vertikale pilene representerer at man kan få radardisplay vist på skjermen ved å trykke knappen med pil ned, og skjule visningen av radar ved å trykke pil opp. De horisontale pilene representerer at man kan bla gjennom de ulike tegnelagene/diagrammene. Venstre er de eldre versjonene og høyre er de nyere. en blyant, som skal representere at man er i tegnemodus et plusstegn, som skal representere å legge på et nytt tegnelag en bunke med ark, som skal representere at man kan bla igjennom versjoner av diagrammet. Her fungerer de horisontale pilene som navigeringsmekanisme. Prosessrapport Side 18

19 Prosessrapport Gruppe 23 en søppelbøtte, som skal representere kast eller slett funksjon en pil med bue tilbake til hvor den starter, som skal representere muligheten for å angre en tegning som har blitt tegnet. Figur 9 Grafiske ikoner brukt i applikasjonen Noen av ikonene har en skjult affordance, det vil si at ikonet ikke viser en opplagt funksjon for bruker. Det vi mener med opplagt funksjon er at det ikke er åpenbart hva objektet inviterer til. Et slikt ikon er plusstegnet, der metaforen skal henvise til at bruker kan legge til et tegnelag. For andre ikoner har vi tatt i betraktning en brukers positive overføring av ferdigheter og erfaringer fra tidligere situasjoner. Ikonene våre, som avbilder piler, er en etablert konvensjon på valg av navigasjon. For eksempel bruker nettlesere piler i sine vinduer for navigasjon horisontalt eller vertikalt. Når man skal lage en applikasjon, som baseres på berøring, er det viktig å tenke på hvilke brukere som skal benytte berøringsskjermen og ta hensyn til fysiske forskjeller. Med fysisk forskjell mener vi forskjell på hånd og fingerstørrelse, men også forskjeller på motoriske bevegelser og syn. Ikonene bør ikke være for store slik at de tar opp plass, men heller ikke for små slik at de blir vanskelig å se og ikke minst vanskelige å trykke på. Vi har lagt til en animasjon, som gjør ikonene større og mindre når de trykkes på. Dette har vi gjort for å gi tilbakemelding til brukeren om at trykket er registrert av knappen Berøring Vi har utviklet berøringslogikk på bakgrunn av hva brukeren vil synes er intuitivt å gjøre ved ulik funksjonalitet. Med intuitivt mener vi etablerte konvensjoner på berøringsfunksjoner og funksjonalitet som følger modellen Handling og evalueringssyklusen (Sandes). Gjennom markedsaktører, som Microsoft og Apple, har det oppstått forskjellige konvensjoner på ulike berøringsfunksjonalitet som markedsaktørene benytter kontinuerlig i sine produktlinjer. Et eksempel på dette er Apple hvor bruker kan overføre sine tidligere erfaringer og ferdigheter fra et eldre produkt til et nyere produkt. Denne positive overføringen kan være brukerens mentale modell på hvordan de skal bruke applikasjonen. En mental modell (Sandes) er en brukers representasjon som definerer hva en logisk og overbevisende tilnærming til hvordan noe er oppbygd og fungerer. Handling og evalueringssyklusen er et hjelpemiddel til å forstå interaksjon mellom bruker og produkt. Modellen baseres på at en handling har fire elementer et mål, hva vi ønsker å oppnå en handling, hva vi utfører for å nå målet en verden, handlingsarenaen en evaluering, har vi nådd målet? Som figur 10 viser vil en bruker planlegge sine handlinger på grunnlaget av målet hun har og evaluere om brukergrensesnittet lar henne Prosessrapport Figur 10 Handling og evalueringssyklusen Side 19

20 Prosessrapport Gruppe 23 utføre handlingene som kreves. Et eksempel kan være når en bruker vil flytte noe på skjermen. Da vil hun sette fingeren sin på objektet som hun vil flytte og dra fingeren i retningen hun vil at objektet skal flytte seg. Det er også blitt en konvensjon at dobbelklikk lar en bruker åpne noe eller for å markere at et punkt skal være et senter. Derfor har vi i vår applikasjon programmert det slik at et dobbelklikk vil vise P&ID diagrammet som det ble dobbelklikket på over hele skjermen. Dette har vi fått god tilbakemelding på igjennom brukertester. Dette var også et ønske fra ABB sin side. Vi har vurdert når det er nyttig å kunne trykke på et objekt på skjermen. Et objekt kan være en pumpe eller et rør på et P&ID diagram. Når man klikker på disse kan man få opp informasjon om objektet. Men det er ikke nyttig å trykke på et objekt hvis objektet er mindre enn fingeren som trykker. Vi har løst dette ved at en bruker ikke får respons fra objekter på skjermen når det er så lite at det ikke synes eller det er mindre enn brukerens finger. Dette fører til mindre forstyrrelser for brukeren og gir en bedre brukeropplevelse. 2.6 Testing Test prosessen Testing er nødvendig for å sikre at funksjonalitet og brukergrensesnitt i en applikasjon tilfredsstiller alle brukere. Testing er også et verktøy for å avduke muligheter for økt funksjonalitet og bedre brukergrensesnitt. I en perfekt verden ville kontinuerlig testing av en iterasjon, helt det punkt hvor tilbakemeldinger fra testbrukere ikke forekommer lenger, levert det perfekte sluttprodukt. I virkeligheten er det balansen mellom antall iterasjoner innenfor gitt tidsramme og antall tester per iterasjon, som avveier kvaliteten til sluttproduktet. Figur 11 Testtidslinje Vi valgte å ta en iterasjon per uke, og dersom testene knyttet til iterasjon ikke ble godkjent ville vi foreta en ny iterasjon. Ettersom berøringsskjermen med projektor ble sent klar til bruk startet vi å utvikle applikasjonen kun for PC. Da brukte vi museklikk for det som senere skulle være berøring på skjermen. Hensikten med denne programmeringen var å utarbeide logikken til funksjonaliteten og utforme funksjoner med tanke på at det skulle komme inn data fra hendelser som skjedde ved berøring. Vi håpte museklikkhendelser kunne erstattes relativt enkelt med berøringshendelser. I perioden, der vi programmerte for museklikk, bestemte vi oss for kun å foreta foreløpig akseptansetesting (se avsnitt 2.5.1). Grunnen til at vi ikke gjennomførte brukertesting (se avsnitt 2.5.2) var at kun den grunnleggende funksjonaliteten ble programmert. Resultatene fra akseptansetestingen som ble gjort av arbeidsgiver ville da være tilfredsstillende nok til å dekke ønsket funksjonalitet i brukerhistoriene. Når berøringsskjermen ble klar, innførte vi brukertesting i tillegg til akseptansetesting. Figur 11 viser gjennomføringen av de ulike testene i løpet av utviklingen. Da ville vi teste alle brukerhistoriene nok en gang, av tilfeldige brukere samt arbeidsgiver. Dette ville gi verdifull tilbakemelding om design, brukervennlighet og funksjonalitet til å utvikle prosjektets sluttprodukt. Prosessrapport Side 20

21 Prosessrapport Gruppe Akseptansetesting Utviklingsprosessen var drevet av en iterasjonsplan, og for at vi kunne gå videre i iterasjonsplanen måtte oppdragsgiver utføre en akseptansetest av iterasjonen. Oppdragsgiver tester, på bakgrunn av brukerhistorien, ut funksjonaliteten på applikasjonen. Og har enten godkjent iterasjonen og vi har kunne gått videre til neste, eller ikke godkjent og oppdragsgiver har kommet med forslag til forbedringer. Da har vi utvidet iterasjonen og foretatt ny akseptansetest når en ny løsning har kunnet bli testet. Testen ble dokumentert ved hjelp av et skjema, hvor vi skrev ned forslagene og kommentarene til oppdragsgiver. For mer informasjon om resultatene av testingen, se Produktrapport Vedlegg - Akseptansetestrapport Brukertesting Under denne type test har en bruker fått lest brukerhistorien og skal ut ifra det benytte applikasjonen til å fullføre den funksjonalitet som er beskrevet. Dersom bruker ikke kunne utøve det, har vi utvidet iterasjonen for å rette opp i feil. Deretter har vi foretatt en ny brukertest når ny delløsning har kunnet bli testet. Dette gjorde vi helt til brukertesten ble gjennomført suksessfullt. Testen ble dokumentert ved hjelp av et skjema, hvor vi skrev ned forslagene og kommentarene til bruker. For mer informasjon om resultatene av testingen, se Produktrapport Vedlegg - Brukertestrapport 2.7 Videreutvikling Ved statusmøtet i april endret vi prioriteringer på enkelte brukerhistorier, se avsnitt 2.4.2, og som resultat ble de resterende brukerhistoriene videreutviklingsmuligheter. Gjennom testing av iterasjonene kom det også mange forslag fra testbrukerene til videreutvikling, for liste over alle videreutviklingsmulighetene, se Produktrapport Vedlegg Videreutvikling. Vi så at noen av forslagene som ble nevnt ved testing, kunne la seg gjøre innenfor tidsrammen og ville være gode tillegg i funksjonaliteten til applikasjonen. Blant disse forslagene var angre-knapp for brukere ved tegning og en animasjon i objektinformasjonen. Derfor har vi utført iterasjon K, som ikke bygget på en brukerhistorie fra listen til oppdragsgiver, men på forslagene som kom frem ved testing og enkelte bugs vi hadde funnet ved tidligere iterasjoner. 3 Konklusjon Om gruppen I ettertid mener vi at valget av antall gruppemedlemmer har vært riktig, og fordelen at vi kjente hverandre godt og hadde erfaring i samarbeid med hverandre har hatt god uttelling i effektivitet og utviklingsprogress. Vi har hatt få tvister om teknologiske løsninger, og har vært flink til å høre hverandre ut ved forskjellige meninger og kommet frem til løsninger som begge har godtatt. Vi har vært flinke til å fordele arbeidsmengde og holde kontroll underveis på hva vi har tid til og hva vi ikke tror vi vil ha tid til. Vi har fokusert på kvalitet og full operativ funksjonalitet, fremfor kvantitet og delvis operativ funksjonalitet. Om resultatet Applikasjonen er kjørbart på berøringsskjermen hos ABB, og kan benyttes til å skalere og panorere P&ID diagrammer for å se detaljer og utforske muligheter med samarbeid på flerberøringsskjerm. Tiltross begrensninger innenfor disponering av tid til prosjektet og implementering av teknologien fra berøringsskjermen, mener vi at resultatet har blitt bra. Det er et godt utgangspunkt for ABB til å utforske hvilke muligheter applikasjonen på en berøringsskjerm kan tilby: et tillegg til dokumentasjon på papir en arena for å kunne få informasjon enkelt og raskt, gjennom skalering og panorering av diagramkart Prosessrapport Side 21