Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 2

Størrelse: px
Begynne med side:

Download "Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 2"

Transkript

1 S E CURI TYS HI E L D G R U P P E 2 5 HOVE DPROS J E KTF ORHI O2009

2 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 2

3 PROSJEKT NR TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Security Shield PROSJEKTDELTAKERE Christer Rønning Austad (s141791) Kagiso S. Molobi (s141796) Daniel Stefan Zeller (s141797) Olav Bieltvedt (s141773) DATO 29/5-09 ANTALL SIDER / BILAG 173 INTERN VEILEDER Eva Vadler Vihovde OPPDRAGSGIVER SmartPhones AS ( KONTAKTPERSON Even Weberg Mobil: SAMMENDRAG Oppgaven går ut på å lage et administrasjonssystem for Windows Mobile telefoner. Målet med denne løsningen er todelt. Den ene delen består av å kunne deaktivere forskjellige funksjoner på Windows Mobile telefoner fra en server side. Dette kan være funksjoner som (Bluetooth, ActiveSync, SD- Minnekort etc.). Til dette er det utviklet en klient som kjører på Windows Mobile samt en serverdel. Den andre delen av oppgaven består av en KioskMode applikasjon som låser ned Windows mobiltelefonen slik at kun predefinerte applikasjoner kan kjøres. Alle andre applikasjoner og funksjoner er sperret for brukeren. Til dette er det utviklet en KioskMode klient for Windows mobile, samt en server applikasjon hvor en administrator kan designe sin egen Kiosk applikasjon. 3 STIKKORD Microsoft Windows Mobile Kiosk Mode Xml provisioning Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 3

4 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 4

5 Forord Dette dokumentet består av alle dokumentene som er knyttet til hovedprosjektet vi i gruppe 25 ved Anvendt Datateknologi har hatt vårsemesteret 2009 ved Høgskolen i Oslo/Avdeling for Ingeniørutdanning. Hoveddokumentet er bygget opp av samtlige av de dokumentene vi har jobbet med underveis i prosjektet. Rekkefølgen på disse er: Styringsdokumentasjon, prosessrapport, produktrapport, testrapport og brukerveiledning. Styringsdokumentasjonen består også av følgende underdokumenter: Statusrapport, prosjektskisse, forprosjektrapport, arbeidsplan, fremdriftsplan og kravspesifikasjon. Disse dokumentene er uavhengige dokumenter, som kan leses hver for seg. Dokumentene som inngår i hoveddokumentet kan også leses på vedlagt CD i PDF format og på prosjektets webside: Her finner man også dokumentasjonen av kildekoden til programmet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 5

6 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 6

7 Innholdsfortegnelse Styringsdokumenter... 9 Prosessrapport Produktrapport Testrapport Brukerveiledning Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 7

8 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 8

9 S E CURI TYS HI E L D S TYRI NGS DUME NTE R

10 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 11

11 Forord Dette er en samling av alle styringsdokumentene som er laget i forbindelse med hovedprosjektet vårt. Disse er satt opp i den rekkefølgen de ble utarbeidet og levert inn. Dokumentene er levert inn på følgende tidspunkt: Dokumenter Frister 1. Statusrapport Prosjektskisse Forprosjekt Prosjektrapport Presentasjon Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 12

12 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 13

13 Innholdsfortegnelse 1 Statusrapport Prosjektskisse Om Touch Mobility AS Prosjektforslaget Forsprosjektrapport Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Løsninger Analyse av løsninger: Arbeidsplan Fremdriftsplan Kravspesifikasjon Presentasjon Innledning Innledning Om bedriften Bakgrunn for prosjektet Forord Systemkrav Funksjonelle krav for fjernstyring av klient Funksjoner som skal låses Aministrasjons systemet på serversiden Registrering av nye data Applikasjonen skal kunne kjøres på Windows mobile 5 og Systemet skal være brukervennlig Systemet bør ha innloggingsfunksjonalitet Server/klient kommunikasjon Funksjonelle krav for Kiosk applikasjonen Hardware knapper må lases ned Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 14

14 Alle eksterne datatilkoblinger må deaktivere Menyvalg ved oppstart SD-minnekort må deaktiveres Ikke funksjonelle krav Oppetid Ubegrenset antall brukere Tekniske krav Krav til design Brukervennlighet Fleksibilitet Universelt design Krav til kode Kode standarder Krav til dokumentasjon Utvidelser Enhanced setting Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 15

15 1 Statusrapport Levert Vi har dannet gruppe til hovedprosjektet våren 2009 ved Avdeling for Ingeniørutdanning. Gruppen vår består av Kagiso Molobi, Daniel Zeller, Christer Rønning Austad og Olav Bieltvedt. Gruppemedlemmer Klasse Studentnummer og e-post Kagiso Molobi 3DB s141796/ Daniel Stefan Zeller 3DA s141797/ Christer Rønning Austad 3DA S141791/ Olav Bieltvedt 3DB S141773/ Vi har enda ikke bestemt oss for hvilken oppgave vi skal velge som hovedprosjektoppgave. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 16

16 2 Prosjektskisse Dato og sted: Oslo, 5. Desember 2008 Foreløpig tittel: Lockout Prosjektgruppe: Kagiso Molobi, Christer Rønning Austad, Daniel Stefan Zeller og Olav Bieltvedt Oppdragsgiver: Touch Mobility AS Kontaktperson: Even Weberg Mobil: Om Touch Mobility AS Touch Mobility AS ble startet januar Touch Mobility AS fokuserer på distribusjon av administrasjon og sikkerhetsløsninger for mobiltelefoner til bedrift og konsumentmarkedet. Touch Mobility distribuerer sin egenutviklede produktserie MOZO, og er også sertifisert distributør av løsninger fra Common Time, Nokia Intellisync og Synchronica. MOZO er kjerneproduktet til Touch Mobility, som er et såkalt Device Management System. Man kan som administrator logge inn gjennom dette websystemet, og styre alle de ansattes telefoner i et firma, med mange funksjoner. MOZO utvikles og supporters av TM s medarbeidere på hovedkontoret i Nydalen i Oslo. 2.2 Prosjektforslaget Oppgaven går ut på å utvikle en applikasjon som gjør det mulig å slå av forskjellige funksjoner på PDA/Smartphones som kjører Windows Mobile som operativsystem. For store bedrifter kan det være ønskelig å kontrollere hva de ansattes PDA/Smartphone s skal brukes til. Touch Mobility får ofte forespørsler fra kunder som ønsker en løsning for å skru av Kamera, Bluetooth, Wlan, Telefon-del, etc. eventuelt mulighet for å låse telefonen slik at kun noen få applikasjoner kan kjøres f. eks Pocket Internet Explorer. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 17

17 Dette er en funksjon som Touch mobility per dags dato ikke har noen god løsning for. De ønsker derfor å inkludere en slik funksjon i den løsningen de tilbyr sine kunder. Låseapplikasjonen vil være et produkt benyttet av en systemadministrator for å låse funksjonalitet på en Microsoft Windows Mobile telefon. Løsningen vil bestå av en klient på telefon som kommuniserer med en server via internett/gprs. System Administrator kan fra serversiden sette parametre for å låse funksjoner som for eksempel kamera, bluetooth, wlan med mer. Dette vil overføres til og eksekveres av klient på telefonen. Denne applikasjonen skal utvikles på Microsofts. NET plattform med Visual Studio 2008 og SDK for Windows Mobile 5 og 6. Løsningen vil også benytte Compact Framework 2.0 og 3.5. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 18

18 3 Forprosjektrapport 3.1 Presentasjon Tittel Kioskmode applikasjon for Windows Mobile Oppgave Oppgaven går ut på å utvikle en applikasjon som gjør det mulig å slå av forskjellige funksjoner på PDA/Smartphones som kjører Windows Mobile som operativsystem Prosjektperiode Gruppemedlemmer Kagiso Molobi, Christer Austad, Olav Bieltvedt, Daniel Zeller Prosjektgruppe 25 Veileder Eva Vihovde Oppdragsgiver Touch Mobility AS Kontaktperson Even Weberg, tlf: Sammendrag Dette hovedprosjektet utføres i samarbeid med Høgskolen i Oslo og Touch Mobility AS. Oppgaven går ut på å lage en sperreapplikasjon (kioskmode) for PDA/Smartphones som benytter seg av Windows Mobile 5 og Om bedriften Touch Mobility AS ble startet januar Touch Mobility AS fokuserer på distribusjon av administrasjon og sikkerhetsløsninger for mobiltelefoner til bedrift og konsumentmarkedet. Touch Mobility distribuerer sin egenutviklede produktserie MOZO, og er også sertifisert distributør av løsninger fra Common Time, Nokia Intellisync og Synchronica. Touch Mobility er også Microsoft Certified Partner. MOZO er kjerneproduktet til Touch Mobility, som er et såkalt Device Management System. Man kan som administrator logge inn gjennom dette websystemet, og styre alle de ansattes telefoner i et firma, med mange funksjoner. MOZO utvikles og supporters av TM s medarbeidere på hovedkontoret i Nydalen i Oslo. Fellesnevneren er at alle løsningene TM distribuerer spiller sammen og bidrar til å forvandle mobile terminaler til sikre, brukervennlige og effektive lommekontor. Våre Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 19

19 løsninger gjør også bedriftenes utrulling av applikasjoner, bedriftsprofiler og oppsett til mobile terminaler effektivt og problemfritt uansett volum. Touch Mobility leverer løsninger for Windows Mobile og Symbian Terminaler. De er i dag kjøpt opp av Telenor, og skal fusjonere med et annet firma innen bransjen. 3.4 Dagens situasjon For bedrifter og systemadministratorer kan det være ønskelig å kontrollere hva de ansattes PDA/Smartphone skal brukes til. Touch Mobility får ofte forespørsel fra kunder som ønsker en løsning for å skru av Kamera, Bluetooth, Wlan, Telefon-del, etc. eventuelt mulighet for å låse telefonen slik at kun noen få applikasjoner kan kjøres f. eks Pocket Internet Explorer. Dette er en funksjon som Touch Mobility per dags dato ikke har noen god løsning for. De ønsker derfor å inkludere en slik funksjon i den løsningen de tilbyr sine kunder. 3.5 Mål og rammebetingelser Målet med oppgaven er å utvikle en klient/server kioskmode applikasjon for PDA/Smartphones basert på Windows Mobile 5 og 6. Vi legger vekt på en enkel og fleksibel løsning som skal være så brukervennlig som mulig. En forutsetning er at alle skal kunne bruke systemet uavhengig av hvor store tekniske ferdigheter de har fra før. Videre skal applikasjonen tilfredsstille brukerens behov. Kioskmode er en betegnelse benyttet om et system som begrenser eller låser tilgang til funksjonalitet på en telefon. Følgende parametre er det aktuelt å kontrollere: Knapper (hardware) Kamera Bluetooth/IR Wlan SD minnekort slot Telefon del ActiveSync Tilkobling med USB til PC Låse applikasjoner (Internet Explorer, GPS software, etc.) Predefinere/låse profil (Normal, Silent, Vibrate, etc.) Låse today screen/startskjermbildet Sette og låse kryptering Koblinger/EDGE/3G/HSDPA låsing Låse POP3/IMAP/Exchange Mail Endre tekst og applikasjon definert for Soft-keys (strektaster) Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 20

20 Rapportere fra klient tilbake til server hvilke parametre som er satt på en telefon Sette avanserte innstillinger for f. eks Bluetooth (synlighet), Wlan (kryptering), etc. Hovedfunksjoner som må implementeres: Låse hardware knapper/ funksjoner GUI på PDA/Smartphone. GUI på server siden. Akseptere predefinerte operasjoner fra designer, f. eks 3 knapper Kommunikasjon mellom server og PDA/Smartphone. Rammebetingelser Hovedfunksjonaliteten for applikasjonen er sperrefunksjonaliteten. Vi står relativt fritt til å velge funksjonalitetsmengden som skal implementeres. I startfasen av prosjektet vil vi gjøre en vurdering av hvilke arbeidsoppgaver det er viktigst å få på plass og disse vil da få høyeste prioritet. Dette gjør vi fordi det i en så tidlig fase av prosjektet vil være vanskelig å forutsi arbeidsmengden det vil ta for å implementere de forskjellige fasene i prosjektet. Ingen av gruppemedlemmene har erfaring med PDA/Smartphone programmering og det er derfor vanskelig å forutse hvor lang tid det tar å sette seg inn i programmeringsspråk, programmeringsverktøy etc. 3.6 Løsninger Applikasjonen skal kunne kjøres på alle PDA/Smartphones som bruker Windows Mobile 5 og 6 som operativsystem. Det går derav klart frem at løsningen skal benytte seg av Microsoft. NET framework SDK v2.0. Utviklingsspråket vi skal bruke vil være en blanding av C# og C++. For lagring av informasjon brukes en database. Som utviklingsprogram har vi etter nøye vurdering bestemt oss for å bruke Microsoft Visual Studio Videre bør løsningen ikke benytte seg av Open Source kode dersom løsning skal implementeres eller benyttes komersielt videre. De forskjellige funksjonene på PDA/Smartphones vil kunne sperres ved å endre verdier i registeret. Dette gjøres ved hjelp av XML og.cab filer. Å lage en overnevnte klient/server løsning innebærer enten 1 klient for PDA og 1 for Smartphone, eller enda bedre 1 felles klient. Vi er enda i en tidlig fase av prosjektet og det er derfor vanskelig å si noe om hvilken av de to løsningene vi vil velge. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 21

21 3.7 Analyse av løsninger: Hovedargumentene ovenfor bedrifter er effektivisering av de ansattes bruk av PDA/Smartphones. Ved å bruke kioskmode funksjonen vil systemadministratorer, kunne kontrollere at enheten kun brukes til ønskelige formål. Produktet i seg selv kan være en avgjørende faktor for at en bedrift tar avgjørelsen for å innføre mobile terminaler. En bruker med ikke-tekniske kunnskaper vil kunne føle trygghet fordi klientapplikasjonens GUI vil gi en brukervennlig opplevelse. Høgskolen i Oslo 2009 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 22

22 4 Arbeidsplan Aktivitet Beskrivelse Ferdig Statusrapport Oversikt over hvilke medlemmer som er på gruppe n. Videre beskriver dokumentet når vi fikk prosjekt og hva slags prosjekt vi ønsket Prosjektskisse Forprosjektrapport Arbeidsplan Fremdriftsplan Datainnsamling Kravspesifikasjon Denne beskriver bedriften vi har oppdrag for og prosjektforslaget deres. Dette er en mer detaljert beskrivelse av prosjektet, inneholder blant annet beskrivelse av mål, rammebetingelser og teknologi Beskriver de forskjellige delene i prosjektet og når de ble ferdig. Viser aller aktiviteter og milepæler i ett Gantdiagram Hentet inn informasjon om teknologi og hva prosjektet skal inneholde. Beskriver detaljert hva oppdragsgiver ønsker av systemet. Denne godkjennes av veileder og oppdragsgiver før implementering Register analyse og Utforming av XML skript. Utforsking av Windows mobile register på Windows mobile 5.0 og 6.1. Lage XML skript på bakgrunn av funn på overnevnte KioskMode koding Utvikling av KioskMode applikasjonen Utkast til GUI (server) Lage et brukergrensesnitt til server BrukerLogInn server Ferdigstille innloggings funksjon for brukere mot server Server Klient kommunikasjon Ferdigstille kommunikasjon mellom klient og server Kodefrys all programmering ferdig Testing Intern Teste all funksjonalitet på Kioskmode og Configuration manager Testing eksternt. Testet kioskmode og Configuation manager på eksterne brukere. Timelister Tid brukt fra hvert gruppemedlem fra prosjektets start til slutt. Prosjektrapport Utarbeide dokumentasjon til prosjektet Prosjektdagbok Beskriver alle gruppemedlemmene sin tidsbruk Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 23

23 Brukermanual Utarbeide en manual for sluttbruker Forberede presentasjon Lage powerpoint presentasjon, sette av tidsforbruk og generell forberedelse Presentasjon Presentere for sensor og veileder Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 24

24 5 Fremdriftsplan Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 25

25 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 26

26 6 Kravspesifikasjon 6.1 Presentasjon Tittel Security Shield Oppgave Oppgaven går ut på å utvikle en applikasjon som gjør det mulig å slå av forskjellige funksjoner på mobiltelefoner som kjører Windows Mobile som operativsystem, via en server. Det skal også utvikles KioskMode applikasjon for Windows Mobile. Prosjektperiode Gruppemedlemmer Kagiso Molobi, Christer Austad, Olav Bieltvedt, Daniel Zeller Prosjektgruppe 25 Veileder Eva Vihovde Oppdragsgiver Touch Mobility AS Kontaktperson Even Weberg, tlf: Innledning Innledning Dette hovedprosjektet skal utføres i samarbeid med Høyskolen i Oslo og Touch Mobility AS, under vårsemesteret Sperreapplikasjonen vil være et produkt benyttet av System Administrator for å låse funksjonalitet på en Microsoft Windows Mobile telefon. Løsningen vil bestå av en klient på telefon som kommuniserer med en server via internett/gprs. System Administrator kan fra server side sette parametre for å låse funksjoner som kamera, bluetooth, Wlan med mer. Dette vil overføres til og eksekveres av klient på telefonen. KioskMode skal være en applikasjon på Windows mobiltelefonen som begrenser eller låser tilgang til funksjonalitet på en mobiltelefon. Når brukeren slår på mobiltelefon skal en møtes av et predefinert skjermbilde som gir brukeren mulighet til å starte et visst antall programmer. All annen funksjonalitet skal være låst ned Om bedriften Touch Mobility AS ble startet januar De fokuserer på distribusjon av administrasjon og sikkerhetsløsninger for mobiltelefoner til bedrift og konsumentmarkedet. Touch Mobility leverer løsninger for Windows Mobile og Symbian Terminaler. De er i dag kjøpt opp av Telenor, og skal fusjonere med et annet firma innen bransjen. Per dags har de ca. 15 ansatte. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 27

27 MOZO er kjerneproduktet til Touch Mobility, som er et såkalt Device Management System. Man kan som administrator logge inn gjennom dette websystemet, og styre alle de ansattes telefoner i et firma, med mange funksjoner. Dette produktet utvikles og supporteres av Touch Mobilty sine ansatte Bakgrunn for prosjektet For bedrifter kan det være ønskelig å kontrollere hva de ansattes mobiltelefoner skal brukes til. Touch Mobility får ofte forespørsler fra kunder som ønsker en løsning for å skru av Kamera, Bluetooth, Wlan, Telefon-del, etc. eventuelt mulighet for å låse telefonen slik at kun noen få applikasjoner kan kjøres f. eks Pocket Internet Explorer. Dette kan enkelt gjøres lokalt på mobiltelefonen, men det kan være ønskelig for en administrator å kunne fjernstyre dette fra en server applikasjon. Dette er en funksjon som Touch mobility per dags dato ikke har noen god løsning for. De ønsker derfor å inkludere en slik funksjon i den løsningen de tilbyr sine kunder Forord Formålet med denne kravspesifikasjonen er å avgrense oppgavens omfang, mot oppdraget vi har fått fra Touch Mobility. Den vil være et hjelpemiddel for oss i prosjektet og sørge for at vi holder oss til de kravene som er gitt. Den skal definere hvilke oppgaver vi ser det som realistisk å kunne oppnå, samtidig som den sier noe om ekstra funksjonalitet det kan være ønskelig å implementere dersom vi oppnår hovedmålene. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 28

28 6.3 Systemkrav Under følger systemkravene for produktet som skal utvikles Funksjonelle krav for fjernstyring av klient Under følger en rekke funksjonelle krav for fjernstyring av klient Funksjoner som skal låses Funksjoner det er et absolutt krav å kunne låse: Bluetooth Wlan Autorun Autorun av filer på minnekort Klokke USB tilkobling Kamera (ikke et krav på alle PDA/Smartphone s, da dette kan være veldig vanskelig på enkelte telefoner) SD minnekortslot GPRS/3G ActiveSync Låse applikasjoner Funksjoner det er ønskelig å ta med dersom tiden tillater dette: Infrarød Soft- keys Predefinere profiler (Silent, Normal, Vibrate) Låse Today Screen/Startskjermbildet (Låse temaet slik at bruker ikke kan endre dette) Administrasjons systemet på serversiden I systemet skal man kunne velge mobiltelefon og hvilke funksjoner som skal låses Registrering av nye data Det skal være mulig å registrere nye brukere, mobiltelefoner til brukeren og tilhørende låse scripts Applikasjonen skal kunne kjøres på Windows mobile 5 og 6 Applikasjonen skal kunne kjøres på alle PDA/Smartphones som bruker Windows Mobile 5 og 6 som operativsystem. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 29

29 6.3.6 Systemet skal være brukervennlig Det er et mål at systemet skal være brukervennlig. Vi vil så langt det lar seg gjøre lage et brukervennlig system Systemet bør ha innloggingsfunksjonalitet Serversiden bør ha en innloggingsfunksjon der brukeren logger inn ved hjelp av brukernavn og passord Server/klient kommunikasjon Klient skal ved faste mellomrom sjekke sin profil hos server ved å bruke den tilgjenglige datatilkoblingen den har. Server sender endringer til klient som provisjonerings XML filer Funksjonelle krav for Kiosk applikasjonen Under følger funksjonelle krav for produktet som skal utvikles Hardware knapper må lases ned Alle hardware knapper som fungerer som snarvei til applikasjoner skal være låst ned Alle eksterne datatilkoblinger må deaktivere Alle funksjonalitet som kan koble Windows mobiltelefonen opp mot eksterne enheter må deaktiveres. Dette er funksjoner som ActiveSync, Bluetooth etc Menyvalg ved oppstart Ved oppstart av klient skal brukeren presenteres en hovedmeny som gir brukeren tilgang til å starte et gitt antall applikasjoner. Alle andre applikasjoner skal brukeren ikke få tilgang til SD-minnekort må deaktiveres SD-Minnekortslot må deaktiveres Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 30

30 Ikke funksjonelle krav Under følger en rekke ikke funksjonelle krav Oppetid Synkroniseringsserveren bør ha en oppetid på nærmere 100% Ubegrenset antall brukere Det bør ikke være noen begrensning på antall brukere av systemet Tekniske krav Utviklingsplattform: Utviklingsverktøy: Microsoft Visual studio Rammeverk: Microsoft.NET framework SDK v2.0. Driftsplattform: PDA/Smartphone: Windows mobile 5 og Krav til design Under følger krav til design av produktet som skal utvikles Brukervennlighet Ved utformingen av systemet legger vi stor vekt på brukervennlighet. Utformingen av GUI skal være slik at det er en logisk sammenheng mellom plassering av knapper, menyvalg, innstillinger etc. slik at det er enkelt å bruke de forskjellige funksjonene i systemet. Den tekniske biten av systemet skal ikke være synlig for brukeren av systemet, men skal skjules av et enkelt GUI. Systemet skal ha enkle snarveier for å kunne utføre avanserte funksjoner. En forutsetning skal være at alle skal kunne bruke systemet uansett tekniske forkunnskaper. Det kan også være ønskelig å ha en utvidet funksjonalitet for avanserte brukere. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 31

31 6.4.2 Fleksibilitet Vi tar utgangspunkt i at systemet skal ha en fleksibel grunnstruktur. Vi tar høyde for at systemet kan bli videreutviklet av Touch Mobility og prøver å legge et godt grunnlag for videreutvikling. Det er derfor viktig at designet legger grunnlag for ny funksjonalitet i fremtiden Universelt design Systemet skal være universelt utformet. Dette innebærer at systemet skal være tilpasset for alle brukere i så stor grad det lar seg gjøre. Dermed skal man ikke måtte gjøre noen spesielle endringer for bestemte brukergrupper. Dette kan være brukere med nedsatt synsevne og fargeblide. 6.5 Krav til kode For å få en ryddig og oversiktlig kode er det viktig at det følges gitte standarder for hvordan koden skal være bygget opp. Det skal være enkelt for andre som eventuelt skal jobbe videre med koden å sette seg inn i og videreutvikle denne. Det er derfor viktig med riktige variabelnavn, klassestrukturer etc. Samtidig må alle i gruppen følge samme mal for kodingen slik at det ikke lar seg skille mellom hvilke gruppemedlemmer som har programmert de forskjellige delene av systemet Kode standarder (1) Vi har bestemt oss for å følge Hungarian notation. Hungarian notation kan brukes uavhengig av programmeringsspråk og er en retningslinje eller et regelsett for hvordan variabelnavn skal se ut. Følges denne standarden vil resultatet bli en ryddig og enkel kode. (2) Microsoft har på sine nettsider laget en standard for struktur av klasse bibliotek. Denne sier noe om design av klasser og datastrukturer. Oppsummert kan vi si at det skal skrives enkel, strukturert og sikker kode, basert på de overstående retningslinjer. (1) (2) Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 32

32 6.6 Krav til dokumentasjon Vi har utviklet en dokument mal som vi skal følge i alle dokumentene i dette hovedprosjektet. Dette har vi gjort for å slippe unødvendig formateringsjobb. Samtidig vil det føre til en gjennomført stil i alle dokumentene vi lager. Gjennom hele prosjektet føres det en prosjektdagbok der all jobbing med prosjektet loggføres med alt fra møter, felles jobbing og individuell jobbing. Samtidig fører alle timelister slik at vi til slutt har en oversikt over hvor mange timer vi har brukt til sammen. Vi har også opprettet et samlingssted på Internett ( basecamp ) der alle involverte i prosjektet har tilgang. Her kan man skrive nye innlegg, diskutere neste steg, laste opp filer og føre timelister. Dette vil vise seg å være et svært nyttig hjelpemiddel for oss for å kunne holde hverandre oppdatert til enhver tid. Vi har også utarbeidet en arbeidsplan og en fremdriftsplan som hjelper oss med å overholde frister og holde fokus på de riktige arbeidsoppgavene. Det er et krav at vi følger den dokumentstandarden som er gitt av skolen. Her er det inntil videre ønskelig at vi følger Ann Mari Torvatn sine dokumentmaler. Samtidig er det store krav til sluttdokumentasjonen og det er derfor viktig at vi fortløpende dokumenterer det arbeidet som er utført slik at vi slipper alt for store arbeidsmengder mot slutten av prosjektperioden. Vi vil skille mellom styringsdokumentene og sluttdokumentasjonen. Styringsdokumentene er dokumenter som skal hjelpe oss å nå det endelige målet med oppgaven, mens sluttdokumentasjonen skal inneholde alt som til slutt skal leveres inn til sensor. Kravspesifikasjonen vil kunne endre seg underveis og denne er derfor satt både under styringsdokumenter og sluttdokumentasjon. Styringsdokumenter: Prosjektskisse Prosjektdagbok Forprosjektrapport Fremdriftsplan Overordnet kravspesifikasjon Sluttdokumentasjon: Endelig kravspesifikasjon Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Brukerveiledning Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 33

33 6.7 Utvidelser Vi ønsker å utvide vårt produkt dersom tiden tillater dette. Nedenfor er et forslag til fremtidige utvidelser Enhanced setting I tillegg til kategoriene ovenfor (Sperring + Kioskmode) så er det mange fine ting man kan gjøre i Registry - f. eks skru på analog klokke i meny, skru av SSL checkbox i konfigurasjon av server for ActiveSync, Close button i boble for datakobling ikon øverst i skjermbildet++ Dett kan legges inn under Enhanched settings for hver modell. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 34

34 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 35

35 S E CURI TYS HI E L D PROS E S S RAPPORT

36 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 36

37 Forord Dette dokumentet beskriver vårt arbeid gjennom hele prosjektperioden og hvordan prosessen har vært gjennomført. Dokumentet er i hovedsak beregnet på sensor, veileder og oppdragsgiver. Det kreves ingen tekniske forkunnskaper for å kunne sette seg inn i dette dokumentet. I rapporten blir det gjort rede for planleggingen av prosjektet, utviklingsprosessen og hvordan arbeidet har vært gjennomført i alle dets faser. Videre gir den en beskrivelse av kravspesifikasjonen og hvordan denne har blitt revidert gjentatte ganger. Det blir også redegjort for hvordan kravspesifikasjonen har vært brukt i arbeidet med dette hovedprosjektet. Det blir også nevnt hvilke utfordringer vi har hatt med de forskjellige elementene i dette hovedprosjektet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 37

38 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 38

39 Innholdsfortegnelse 1 Innledning Om bedriften Dagens situasjon Mål og rammebetingelser Planlegging og metode Fordeling av oppgaver Innspill fra prosjektveileder Innspill fra bedriftens kontaktperson Fremdriftsplanen Utviklingsprosessen Innledende fase Forprosjekt fasen Dagbok Planleggingsfasen Forprosjektrapport Faste arbeidsdager Opprettelse av arbeidsplan og fremdriftsplan Programmering Plan for arbeidet KioskMode og KioskMode designer Configuration Manager Server delen Forkjellige løsninger og læring Samarbeidet i gruppen Testing Testing av XML provisjonering script Testing av KioskMode og Configuration Manager Sluttesting Avslutningsfasen Dokumentering Kompetansetilegning Tilrettelegging fra oppdragsgiver...51 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 39

40 3.11 Kontakt i forhold til veileder Kontakt i forhold til oppdragsgiver Arbeidsforhold i prosjektperioden Faglig utbytte Kvaliteten på prosjektet Brukervennlighet Programmering Sikkerhet rundt lagring av dokumenter Fleksibilitet Utforming av kode Utfordringer i prosjektperioden Utfordringer ved KioskMode applikasjonen Deaktivering av start menyen KioskMode designeren Utfordringer ved kartleggingen av XML provisjonerings script Utfordringer ved provisjoneringsdelen (Configuration Manager) Kravspesifikasjonen Generelt Endringer i kravspesifikasjonen Kravspesifikasjon i forhold til design og implementering Oppsummering og konklusjon Oppsummering Hva kunne vært gjort annerledes? Produktets fremtid Konklusjon Kilder Vedlegg Dagboken Statusrapport Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 40

41 1 Innledning 1.1 Om bedriften Touch Mobility AS ble startet i 2005 med eiere som Telenor og Kjedehuset. Firmaet leverte IT/Telecom løsninger via de største forhandlerkjedene innen mobilmarkedet. Touch Mobility AS spesialiserte seg på såkalt Device Management løsninger med produktportføljen kalt MOZO i spissen Smartphones Telecom AS ble dannet i 2004 og levererte produkter innen Device Management og PIM rettet mot mobilmarkedet. Smartphones Telecom AS besto av 25 ansatte fordelt på administrasjon, salg, teknisk og utvikling. Smartphones Telecom AS ble i 2007 kjøpt opp av Telenor. SmartPhones AS ble dannet i januar 2009 da tidligere Touch Mobility AS ble kjøpt opp av Telenor og fusjonert med Smartphones Telecom AS. SmartPhones AS har spesialisert seg på mobilteknologi, administrasjonsløsninger og tjenester rettet mot mobilitet. SmartPhones AS er i dag ledende innenfor dette markedet i Norge. Produkter som MOZO, Telenor Mobil Kontroll, DME, Afaria, AnyMail og msuite er noen av produktene firmaet kan tilby. SmartPhones AS holder til på Brynseng i Oslo og har avdelingskontor i Sverige og Danmark. 1.2 Dagens situasjon En kan tenke seg en stor bedrift som ønsker å rulle ut en rekke applikasjoner til sine ansatte via mobiltelefonen. Til dette ønsker de seg gjerne en mobiltelefon med en skreddersydd løsning spesielt tilpasset bedriftens behov. For eksempel ønsker de seg at mobiltelefonen kun skal kunne brukes til å ringe, sende sms og surfe på internett med. All annen funksjonalitet som spill eller Office applikasjoner skal være sperret for brukeren. Bedriftens tekniske ansvarlige begynner å undersøke markedet for å finne den beste løsningen til dette. Den mest opplagte løsningen vil være å lage et eget operativsystem til mobilen som kun inneholder den ønskede funksjonaliteten. Problemet er at dette kan være meget dyrt å utvikle samtidig som det vil ta lang tid å lage et slikt system. Det beste alternativet blir da å utvikle en Kiosk applikasjon for Windows Mobile baserte mobiltelefoner. En kiosk applikasjon låser ned mobiltelefonen slik at brukeren kun får tilgang til valgte applikasjoner og tjenester. All annen funksjonalitet er sperret for brukeren. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 41

42 En annen funksjonalitet som etterspørres er muligheten til å kunne slå av og på forskjellige funksjoner på Windows Mobile telefoner via en server, dette for å kunne kontrollere de ansattes mobiltelefoner uansett hvor i verden de måtte befinne seg. Slik funksjonalitet er såkalt provisjonering av mobilen. Funksjoner det er aktuelt å kontrollere er bluetooth, wlan, minnekort leser, usb tilkobling etc. Av praktiske årsaker bør denne provisjoneringen foregå ved hjelp av OTA (Over the air) teknologi slik at man kan sitte på en server fjernstyre mobiltelefonene. Dette er funksjonalitet som Smartphones AS per dags dato ikke har noen egen løsning for. Smartphones AS ønsker derfor å utvikle en egen løsning for denne funksjonaliteten og integrere dette i den løsningen de per dags dato tilbyr sine kunder. 1.3 Mål og rammebetingelser Målet med oppgaven var å utvikle en klient/server fjernstyrings applikasjon for mobilen, samt en Kiosk applikasjon for mobilenheter basert på Windows Mobile 5 og 6. Vi la vekt på en enkel og fleksibel løsning som skulle være så brukervennlig som mulig. Applikasjonen skulle kunne tilfredsstille brukerens behov i form av å få full kontroll over brukerens Windows mobil. Følgende funksjoner var det aktuelt å kunne aktivere/deaktivere fra serverside: Kamera Bluetooth/IR Wlan Autorun fra SD minnekort-slot ActiveSync Låse today screen/startskjermbildet Koblinger/EDGE/3G/HSDPA låsing Rapportere fra klient tilbake til server hvilke parametre som er satt på en telefon Hovedfunksjoner som måtte implementeres i Kiosk applikasjonen: Låse hardware knapper Vise et predefinert velkomstbilde et menyvalg for ønskede programmer Fjerne start menyen som gir brukeren tilgang til et bredt spekter av programmer Deaktivere bluetooth Deaktivere ActiveSync Deaktivere Autorun fra minnekort Deaktivere Run funksjonen ved klokken Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 42

43 Rammebetingelser Hovedfunksjonaliteten for applikasjonen var fjernstyringen av Windows mobiltelefonen og Kiosk applikasjonen. Vi sto relativt fritt til å velge funksjonalitetsmengden som skulle implementeres. I startfasen av prosjektet ble det gjort en vurdering av hvilke arbeidsoppgaver det var viktigst å få på plass og disse fikk høyest prioritet. Dette gjorde vi fordi det i en tidlig fase av prosjektet var vanskelig å forutsi arbeidsmengden det ville ta for å implementere de forskjellige elementene i prosjektet. Ingen av gruppemedlemmene hadde erfaring med Windows mobile programmering og det var derfor vanskelig å forutse hvor lang tid det ville ta å sette seg inn i programmeringsspråk, programmeringsverktøy etc. Til utstyr ble det stilt til rådighet en PDA til hvert av gruppemedlemmene. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 43

44 2 Planlegging og metode 2.1 Fordeling av oppgaver Da vi bestemte oss for å velge hovedprosjektoppgaven fra Smartphones AS, visste vi at det kom til å bli mye programmering i Microsoft.NET plattformen. På grunn av dette valgte vi å gjøre det slik at de to på gruppa med mest programmeringserfaring fikk hovedansvaret for denne delen. Kartleggingsdelen av de forskjellige mobiltelefonene og testing fikk de resterende medlemmene på gruppa ansvar for. Kartleggingen av telefonene og arbeidet i registeret på de forskjellige modellene, var også en stor del av prosjektet. Derfor fant vi ut at vi måtte ha to gruppemedlemmer som kontinuerlig arbeidet med dette. Videre delte vi ut forskjellige ansvarsområder til gruppemedlemmene som ble som følger: Webansvarlig Kontaktansvarlig mot oppdragsgiver Utviklingsansvarlig. Research ansvarlig. Vi føler i ettertid at denne fordelingen har fungert bra for gruppa. Vi har ikke hatt noen gruppeleder under prosjektet, dette fordi vi ikke følte noe stort behov for det og alle hadde et tett samarbeid underveis. 2.2 Innspill fra prosjektveileder Veilederen vår på skolen har vært til stor hjelp for oss underveis i dette hovedprosjektet. Veilederen har hjulpet oss å sette mål som er realistisk å nå for å få et så bra prosjekt som mulig, med de forkunnskapene vi hadde fra før av. 2.3 Innspill fra bedriftens kontaktperson Vår kontaktperson hos Smartphones AS, har hjulpet oss med tilgang til nødvendig materiell som testtelefoner, simkort og arbeidslokaler. Han har også kommet med råd til utformingen av kravspesifikasjonen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 44

45 2.4 Fremdriftsplanen Fremdriftsplanen ble laget etter vi var ferdige med kravspesifikasjonen. Dette dokumentet beskrev hvilke elementer i prosjektet som skulle være ferdig til gitte tidspunkt. Dette har vært til stor hjelp for å kunne holde oversikt over tiden i dette prosjektet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 45

46 3 Utviklingsprosessen 3.1 Innledende fase I startfasen av prosjektet ble vår gruppe dannet. Vi hadde alle jobbet sammen på gruppe i tidligere prosjekter så vi hadde ingen startvansker. Vi begynte på dette tidspunktet å drøfte hvilken type oppgave vi kunne tenke oss. Da web-teknologi var noe vi alle hadde erfaring med var vi i første omgang ute etter en oppgave i denne gaten. Vi var i kontakt med noen bedrifter via e-post men siden vi kom relativt sent i gang med prosjektplanleggingen var mange av hovedprosjektoppgavene allerede opptatt. I slutten av oktober leverte vi den første statusrapporten, hvor vi dessverre ikke hadde funnet noe prosjekt enda. 3.2 Forprosjekt fasen Tidlig i desember 2008 fikk vi en e-post fra Even Weberg som jobbet i daværende TouchMobility. Prosjektforslaget som ble presentert i e-posten hørtes spennende ut. Vi hadde på dette tidspunktet fortsatt ikke funnet noen hovedprosjektoppgave. Derfor dro vi noen dager senere på besøk til TouchMobility hvor fikk en presentasjon av firmaet og hva oppgaven i hovedtrekk ville gå ut på. Vi syntes programmering på Windows Mobile plattformen i Microsoft.NET hørtes veldig spennende ut. Microsoft.NET plattformen var noe vi ikke hadde erfaring med fra før, men ettersom det er en meget etterspurt kompetanse var vi veldig lystne på nettopp et slikt hovedprosjekt. 3.3 Dagbok Vi startet med å føre en prosjektdagbok etter det første møtet med daværende Touch Mobility. Vi fant ut at dette var en bra måte å loggføre hva vi har gjort de dagene vi har vært samlet med hele gruppa og jobbet. Da det ville gjøre det enklere for oss å huske hva som til enhver tid har blitt gjort av arbeid og diskutert underveis. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 46

47 3.4 Planleggingsfasen Da vi hadde bestemt oss for prosjektforslaget, begynte vi kartleggingen av forskjellige verktøy og applikasjoner vi ville få bruk for. Vi fant ut at vi ville trenge et prosjektstyringsverktøy, valget falt på det webbaserte verktøyet Basecamp. På denne websiden laget vi en profil til alle gruppemedlemmene og veilederen vår i bedriften. Her holdt vi styr på møter, tidsforbruk, nyttige lenker og annen informasjon vi ville trenge underveis. Vi valgte også Dropbox som verktøy til å synkronisere filer og dokumenter mellom maskiner. Dropbox gjorde det mulig for flere brukere å dele på filer online. Alle prosjektets deltakere hadde tilgang til en felles mappe på sin datamaskin som ble synkronisert opp mot en server. På denne måten var vi sikre på at koden vi jobbet med ikke gikk tapt samt at alle til enhver tid hadde mulighet til å jobbe med samme kode. Vi diskuterte også på dette tidspunktet hvordan vi skulle fordele ansvar og oppgaver underveis. Vi kom frem til at vi delte gruppen i to, hvor to av gruppemedlemmene skulle jobbe mest med programmeringen mens de to andre skulle jobbe med kartleggingen av Windows Mobile operativsystemet og registeret Forprosjektrapport Det neste som stod på lista over gjøremål, var utarbeidelse av forprosjektrapporten. Denne hadde innleveringsfrist i slutten av januar. Før forprosjektrapporten kunne leveres, måtte vi definere oppgaven mer konkret og bli enige om mål og rammebetingelser. Dette samarbeidet vi tett med vår oppdragsgiver om Faste arbeidsdager Vi tok i starten utgangspunkt i å ha tre faste dager, hvor gruppen skulle møtes og arbeide sammen. Dette ble mandager, tirsdager og onsdager. I tillegg kom det individuelle arbeidet som det enkelte gruppemedlem skulle utføre Opprettelse av arbeidsplan og fremdriftsplan Det ble på dette tidspunktet opprettet en arbeidsplan og en fremdriftsplan. Denne skulle hjelpe oss med å holde en god struktur og oversikt over hva som måtte gjøres. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 47

48 3.5 Programmering Utviklingsplattformen vi skulle bruke var ny for alle gruppemedlemmene. Det ble derfor i starten av prosjektperioden satt av tid til å lære oss å bruke teknologien. Før vi kunne ta fatt på å løse oppgaven ble det derfor en del prøving for å teste hvordan ting fungerte. Til dette benyttet vi oss av diverse læringsnettsteder på internett og lærebøker Plan for arbeidet I starten av arbeidet ble det lagt stor vekt på selve funksjonaliteten til systemet. Dette gjorde vi fordi vi følte det var viktig å få på plass selve grunnstrukturen for funksjonaliteten, før vi kunne gå mer i detalj på selve programmeringen. Utformingen av brukergrensesnitt og andre deler ble dermed satt til side. Etter hvert som vi fikk på plass grunnstrukturen begynte arbeidet med grensesnittet. Kodingen har vært en kontinuerlig iterasjonsprosess da vi hele tiden har funnet ting vi kunne endre på og ting som kunne gjøres annerledes. På grunn av dette har også kravspesifikasjonen blitt revidert KioskMode og KioskMode designer I begynnelsen av prosjektet var det kun meningen at vi skulle utvikle en KioskMode applikasjon. Etter hvert som denne begynte å nærme seg et ferdig produkt ble vi oppmerksomme på en ny problemstilling. Hvordan skulle den enkelte KioskMode applikasjonen tilpasses brukeren? Skulle en programmerer hos Smartphones AS, hardkode en KioskMode applikasjon hver gang en ny versjon var nødvendig? Løsningen ble å lage KioskMode designeren som ga brukeren muligheten til å opprette sin egen KioskMode applikasjon via webgrensesnittet Configuration Manager I starten av prosjektperioden var det meningen at provisjoneringen av Windows mobiltelefonen skulle skje ved at en provisjonerings SMS skulle sendes fra server til klient. Til dette krevdes en teknologi som var så avansert at selv de mest erfarne programmererne hos Smartphones AS var usikre på hvordan dette fungerte. Vi ble derfor bedt om å lage en klient på mobil som ved gitte tidspunkt synkroniseres opp mot en webservice på serversiden, for å provisjonere enheten. På grunn av av denne endringen ble vi nødt til å endre kravspesifikasjonen. Dette førte til at vi tapte en del tid, fordi vi brukte mye tid på å sette oss inn i feil teknologi. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 48

49 3.4.4 Server delen Smartphones AS satte en server til vår disposisjon. Denne serveren kjørte Windows Server 2003 Web edition. Denne var plassert i Smartphones AS sine lokaler. Av sikkerhetsmessige årsaker kunne vi kun få tilgang til denne når vi satt på Smartphones AS sitt lokalnett. Vi satte derfor opp en server hjemme hos en av gruppemedlemmene slik at vi kunne ha tilgang til serveren hele tiden. Denne skulle fungere som en midlertidig server og all funksjonalitet skulle overføres til serveren i Smartphones AS sine lokaler i slutten av prosjektperioden. Mot slutten av prosjektet ble det dessverre ikke tid til dette, så vi ble nødt til å fortsette å bruke hjemme serveren. Selve programmeringen av database systemet fikk ikke høyeste prioritet i begynnelsen av prosjektperioden. Vi anså KioskMode applikasjonen og kommunikasjon mellom klient og server som de viktigste delene å få først på plass. Dette fordi vi anså disse delene som mest krevende. Dette medførte imidlertid at det ble et stort arbeidspress mot slutten av prosjektet for å få ferdigstilt funksjonaliteten med databasen Forkjellige løsninger og læring I begynnelsen av prosjektet ble det brukt mye tid på utforsking av Windows Mobile operativsystemet og hvilke muligheter vi hadde for manipulere dette. Arbeidet med dette prosjektet har derfor vært en kontinuerlig læringsprosess både i form av programmeringserfaring og kunnskap om Windows mobile operativsystemet Samarbeidet i gruppen Vi har i all hovedsak jobbet sammen, men vi delte inn arbeidet mellom oss. Dette medførte naturlig nok at de to som jobbet med kartleggingsdelen av Windows mobile operativsystemet og de som jobbet med programmeringen hadde et tettere samarbeid seg imellom. Vi fikk alle egne ansvarsområder å jobbe mot. Vi har utvekslet ideer og løsninger når det har vært noe uklart. Å jobbe på denne måten har medført at alle gruppemedlemmene har fått en generell god oversikt over prosjektet. Dette har også vært nyttig når noen på gruppen fikk et problem, så kunne andre i gruppen svare på det. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 49

50 3.6 Testing Testingen av systemet er delt inn i to deler. Den ene delen omhandler testing av xml provisjonerings script på forskjellig mobiltelefoner. Den andre delen er testing av selve sluttproduktet. Delene er beskrevet under Testing av XML provisjonering script Denne testingen har foregått kontinuerlig gjennom hele prosjektperioden. Hensikten med denne testingen var å finne ut hvilke register endringer som deaktiverte forskjellige funksjoner på forskjellige Windows Mobile telefoner Testing av KioskMode og Configuration Manager Når nye programbiter ble opprettet, ble disse testet opp mot eksisterende kode for å se at de fungerte sammen slik de skulle. Når disse funksjonene fungerte som de skulle ble nye programdeler påbegynt. En slik fremgangsmåte med å teste de forskjellige delene underveis har hatt den store fordelen ved at vi har sluppet den store feilsøkingsjobben mot slutten dersom det oppsto feil i koden. Noe som kan være en stor og tidkrevende prosess når programmet blir av en viss størrelse Sluttesting For å luke ut så mange feil som mulig ble det mot slutten av prosjektet opprettet en strukturert plan på hvordan testingen skulle foregå. Det ble derfor opprettet et eget testdokument med en detaljert plan for dette. Test dokumentet inneholder dokumentasjon om hva som er testet og hvordan dette er gjort med grundige forklaringer. 3.7 Avslutningsfasen Den 1. mai hadde vi en liten fremføring av vårt program for resten av gruppene som hadde samme veileder. Vi satte denne datoen som frist for å avslutte programmeringen og begynne med dokumentasjonen av produktet. Ved dette tidspunktet var det noen enkelte elementer ved programmeringen som fortsatt ikke var ferdig. Vi ble derfor enige om at tre av gruppemedlemmene begynte å dokumentere mens sistemann avsluttet programmeringen. De siste ukene av prosjektet ble hektiske for å få avsluttet alle delene. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 50

51 Når det gjelder selve kildekoden, valgte vi å utelate denne i papirutgaven av prosjektrapporten, dette fordi denne var så omfattende slik at den ville tatt opp alt for mange sider. 3.8 Dokumentering Vi ble enige om å begynne dokumenteringen så tidlig som mulig slik at vi skulle unngå alt for store arbeidsmengder mot slutten av prosjektperioden. Vi ble også stadig minnet om dette av veileder som mente vi skulle få ferdig en grunnstruktur og skjelett på diverse dokumenter så tidlig som mulig. Vi begynte derfor å dokumentere og lage notater mens vi programmerte. Å gjennomføre dokumenteringen på denne måten gjorde at vi hadde muligheten til å finpusse dokumentene, noe som har ført til en bedre sluttdokumentasjon. Dokumentering av prosjektet har pågått gjennom hele prosjektperioden. Dokumentering av de forskjellige fasene i prosjektet ble dokumentert i en dagbok. Et av gruppemedlemmene fikk ansvaret for å føre dagboken og loggføring i denne ble utført minst en gang i uken. Å kunne se tilbake på dagboken har vært nyttig spesielt med tanke på oppretting av blant annet dette dokumentet. Mange av dokumentene har blitt revidert flere ganger. Dette har vært en nødvendighet da nye detaljer til oppgaven har kommet frem. 3.9 Kompetansetilegning Da ingen av gruppemedlemmene hadde noe erfaring med programmering i C# ble det i starten av prosjektperioden satt av en del tid til å tilegne oss nødvendig kunnskap om rammeverket og teknologien vi skulle bruke. Tidlig i januar holdt kontaktperson hos Smartphones AS et introduksjonskurs der vi fikk en introduksjon til teknologien vi skulle bruke. Oppdragsgiver har gjennom hele prosjektperioden gitt oss diverse ressurser og materiale som kunne være til hjelp i vårt arbeid. Læringen av rammeverk og teknologi har stort sett foregått ved hjelp av egenlæring gjennom lærebøker og fagstoff på internett Tilrettelegging fra oppdragsgiver Oppdragsgiver hadde i form av en kravspesifikasjon visse krav til funksjonalitet som skulle implementeres i løsningen. Denne var relativt åpent definert og formulert slik at vi sto relativt fritt til å velge hvor mye og hva som skulle implementeres under gitte Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 51

52 rammer. Videre var det ingen krav til utformingen av design og utseende slik at vi selv kunne velge hvordan vi ville utforme systemet. Videre prøve vi å avpasse arbeidsmengen i forhold til hvor mye tid vi hadde til rådighet i prosjektperioden. Vår arbeidsplass i prosjektperioden har vært dels hos Smartphones AS og dels på skolen. Vi jobbet hos Smartphones AS hver fredag hvor det var satt av ledig rom til oss. Å jobbe hos oppdragsgiver har ført til god dialog med dem og vi har kunnet gå og spørre om ting vi har hatt problemer med. Programmererne hos Smartphones AS har også vært fleksible i forhold til å hjelpe oss med diverse problemer vi har hatt under programmeringen Kontakt i forhold til veileder Kontakt med veilederen vår på HIO har først og fremst forgått ved ukentlige møter, der status for prosjektet ved daværende tidspunkt ble gjort opp. Forskjellige problemstillinger og løsninger er blitt diskutert i disse møtene. Kontaktpersonen fra SmartPhones AS har også vært med på mange av disse møtene og bidratt med diverse innspill Kontakt i forhold til oppdragsgiver Kontakt med oppdragsgiver har skjedd i form av møter, e-post og telefon. Kontaktpersonen hos SmartPhones AS har vært veldig behjelpelig med å tilrettelegge arbeidet for oss og har hele tiden vært oppdatert på hva den enkelte i gruppen har jobbet med. De dagene vi har jobbet i SmartPhones AS sine lokaler har vært nyttige i form av at vi har blitt kjent med folkene som jobber der, samt at vi har kunne spørre dem diverse spørsmål Arbeidsforhold i prosjektperioden Under prosjektets gang var en av de største utfordringene vi hadde å finne steder der vi kunne sitte i fred å arbeide. På skolen var det ikke tilrettelagt for denne type arbeid og oppdragsgiver hadde begrenset med plass grunnet nye kontorlokaler. Dette ga grunnlag for mye frustrasjon da vi ofte måtte begynne dagen med å lete etter steder der det egnet seg å jobbe. Oppdragsgiver tilrettela det slik at vi fikk muligheten til å jobbe i deres lokaler hver fredag fra klokken 11:00 og utover. Det var til stor hjelp for oss å kunne arbeide hos oppdragsgiver fordi vi fikk tilgang til diverse test telefoner samt at vi kunne spørre de ansatte om ting vi lurte på i henhold til prosjektet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 52

53 3.14 Faglig utbytte Da vi startet dette prosjektet hadde vi ingen kompetanse i.net plattformen. Vi så derfor på dette prosjektet som en spennende utfordring som ga oss muligheten til å lære oss en helt ny teknologi. Dette har gitt oss mange utfordringer og det har vært spennende og meget lærerikt å jobbe med denne teknologien. Å jobbe i et så stort prosjekt som dette hovedprosjektet har gitt oss nyttig erfaring som kan komme godt med i arbeidslivet der jobbene ofte foregår i prosjektform. Vi føler at det å kunne samarbeide og fungere i gruppe har vært viktig for å kunne jobbe riktig og strukturert. Dette har gitt oss nyttig erfaring og vi føler at samarbeidet har fungert veldig bra. Siden vi benyttet en teknologi som var ny for oss har vi også blitt flinkere til å måtte lære oss ukjent teknologi på egenhånd uten hjelp av faglærer. Dette kan komme godt med senere i arbeidslivet der man hele tiden må holde seg oppdatert på ny teknologi og lære nye ting på egenhånd Kvaliteten på prosjektet Under følger en beskrivelse av prosjektets kvalitet Brukervennlighet Brukervennlighet er noe vi har prioritert ganske høyt. Vi har prøvd å lage systemet så enkelt som mulig slik at brukeren ikke blir overveldet av for mye funksjonalitet. Startsidene på både klientsiden og serversiden har få enkle valg som enkelt lar brukeren velge ønsket funksjon. Når brukeren har behov for mer avanserte valg som kan man velge dette fra en meny Programmering Vi har benyttet C# og ASP.NET med Compact Framework i utviklingen av applikasjonen. Denne teknologien er skreddersydd for utvikling på Windows Mobile og server applikasjoner. Vi støtte på noen utfordringer med bruk av C# som utviklingsspråk da det viste seg at noen elementer i programmeringen ikke var støttet i C#. Dette medførte at vi ble nødt til å benytte oss av C++ på enkelte elementer. Å benytte C++ ble en stor utfordring for oss, så programmererne hos Smartphones AS hjalp oss derfor i gang med dette. Teknologien er nærmere forklart i produktrapporten. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 53

54 Sikkerhet rundt lagring av dokumenter Sikkerheten har blitt ivaretatt på mange måter. Vi har innsett at det å ta backup av alt arbeidet er veldig viktig for å unngå tap av informasjon. Vi har derfor kontinuerlig lagret arbeidet vårt på en web-basert lagringsenhet som alle på gruppa hadde tilgang til. I tillegg til dette har den enkelte sørget for å ha egne kopier av sitt arbeid på eksterne medier Fleksibilitet Systemet vårt er beregnet på å håndtere store mengder brukere og i så måte kunne dekke et stort kundesegment. Vi tok derfor høyde for dette ved opprettelsen av systemet. Dette har ført til et fleksibelt system som kan behandle mange brukere Utforming av kode Vi har lagt vekt på å lage koden så ryddig og oversiktlig som mulig. Utformingen av koden er av en slik karakter at programmet kan videreutvikles uten å gjøre store endringer i koden. Dette er en fordel for Smartphones AS slik at de slipper å kode hele systemet fra bunnen av ved videreutvikling, men kan ta i bruk eksisterende kode Utfordringer i prosjektperioden I løpet av prosjektperioden har vi støtt på en rekke utfordringer med hensyn til funksjonalitet som skulle implementeres. Under har vi listet opp en rekke utfordringer vi har hatt Utfordringer ved KioskMode applikasjonen Enheter som kjører Windows Mobile som operativsystem er designet for å være multifunksjonelle enheter som kan kjøre et bredt spekter av forskjellige applikasjoner. Operativsystemet er designet for å kunne konfigureres av brukeren slik at brukeren har mange forskjellige muligheter til å starte programmer og enkelt kunne navigere mellom disse. Operativsystemet i seg selv er dermed så langt unna en KioskMode som overhodet mulig. Eksempler på hva en Windows Mobile enhet kan brukes til er: Spill, e-post, meldinger, telefon, applikasjoner, film, musikk, Internett, SD minnekort, bluetooth, GPS etc. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 54

55 Å lage en Kiosk applikasjon kan ses på som hacking av Windows Mobile operativsystemet. Det er ikke ulovlig å lage en slik applikasjon, men det supporteres ikke av Microsoft. Derfor var det svært vanskelig å finne informasjon om hvordan man kan låse ned de forskjellige elementene på mobiltelefonen. Microsoft ønsker av sikkerhetsmessige årsaker at ikke alle og enhver kan tukle med Windows mobile sin multifunksjonelle plattform Deaktivering av start menyen I begynnelsen av KioskMode implementeringer så det ut til at deaktiveringen av start menyen skulle gå ganske greit. Elementer som vises i start menyen kan redigeres i mappen \Windows\Start Menu. Tidlige løsninger gikk ut på å flytte alt innholdet i \Windows\Start Menu mappen over i en midlertidig mappe \Windows\Start Menu backup. Problemet med denne løsningen var at det ikke var mulig å fjerne Today ikonet og sist bukte programmer. I prinsippet fungerte denne løsningen, men vi følte at dette ikke var noen god løsning. Etter utallige forum spørsmål, noen e-poster til Microsoft og grundig utforsking av Windows mobile registeret kom vi frem til to forskjellig løsninger som fungerte tilfredsstillende. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 55

56 KioskMode designeren KioskMode designeren ble i første omgang implementert lokalt på en av gruppemedlemmenes datamaskin. Opprettelsen av KioskMode installasjonsfilen (nærmere forklart i produkt dokumentasjon) ble først utført ved hjelp av en batch fil som ble startet via web applikasjonen. Problemet oppsto da vi skulle laste opp KioskMode designeren på webserveren. Det viste seg at man av sikkerhetsmessige årsaker ikke kan starte batch filer gjennom en web applikasjon. Vi ble derfor nødt til å droppe batch scriptet og utføre opprettingen av KioskMode installasjonsfilen direkte i c# koden Utfordringer ved kartleggingen av XML provisjonerings script Testingen gikk i hovedsak ut på å finne frem til de rette katalogene i registeret i operativsystemet på mobiltelefonene. Vi måtte deretter å finne frem til de riktige verdiene som gjør at programmer og funksjoner ikke kan kjøres. Dette har vært en tidkrevende jobb, da registeret er stort og uoversiktlig. Microsoft har heller ikke gitt ut noen offisiell dokumentasjon på dette. Denne testingen ble veldig tidkrevende da vi hele tiden måtte reinstallere Windows Mobile operativsystemet på mobilen når vi hadde deaktivert en funksjon. Vi valgte i starten av testingen å teste mobiltelefoner med både Windows mobile 5 og 6 operativsystem. Etter diskusjon med arbeidsgiver ble vi enige om at vi kun skulle fokusere på Windows Mobile 6. Dette fordi WM 6 operativsystemet er mest relevant for dagens marked. XML-scriptene For å finne ut hvilke register verdier som deaktiverte forskjellige funksjoner i Windows Mobile registeret ble vi nødt til å søke etter denne informasjonen på internett. Diverse hacker forumer viste seg å innholde mye relevant informasjon for vårt arbeid. Vi fant forskjellige register verdier og startet med å teste disse. Men det var mange av disse som ikke fungerte på alle modellene og det var også variasjoner mellom hva som fungerte og ikke på Windows Mobile 5 og 6. Her er et eksempel på en registerverdi for Bluetooth: HKLM\Software\Microsoft\Bluetooth\BTHLINK\ DLL = bthlink.dll Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 56

57 XML scriptet nedenfor deaktiverer Bluetooth. Nøkkelen DLL tilegnes en tom verdi og Bluetooth deaktiveres på Windows Mobile telefonen: <wap-provisioningdoc> <characteristic type="registry"> <characteristic type="hklm\software\microsoft\bluetooth\bthlink"> <parm name="dll" value=" " datatype="string"/> </characteristic> </characteristic> </wap-provisioningdoc> CAB-filer For å få konfigurert telefonen med de endringer XML-filen inneholdt, ble xml filene pakket inn i en cab-fil (cabinet file). En cab-fil er en installasjonsfil for Windows Mobile. Disse installasjonsfilene laget vi med et program som heter makecab som fulgte med Windows Mobile 6 SDK. Når vi hadde overført denne filen fra pc til telefonen, kjørte vi cab-filen og endringene ville mange ganger tre i kraft umiddelbart etter installasjon. Hvis ikke dette var tilfelle, så foretok vi en restart av telefonen. Vi gikk så inn i registeret på telefonen og så om verdien hadde endret seg. I det endelige produktet vårt ble XML-filene overført fra serversiden, men under testingen koblet vi telefonen til en PC med Active Sync og overførte de på denne måten Utfordringer ved provisjoneringsdelen (Configuration Manager) Configuration Manager er en todelt applikasjon som stilte høye krav til planleggingen i forkant av utviklingen. Og siden ingen av gruppemedlemmene hadde noen tidligere kunnskaper innen utvikling av Webservice, mobilapplikasjoner og.net programmering førte dette til at utviklingen av applikasjonen ikke holdt fremdriftsplanen. Mye av tiden har gikk med på å lese dokumentasjon både om Visual Studio 2008 som IDE og ASP.NET programmering. Det har også vært en tidkrevende prosess å lære seg hvordan man får en god og effektiv bruk av Microsoft SQL Server 2008 Express og verktøyer som Microsoft Server 2008 Managment Studio Express. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 57

58 Tidlige løsninger gikk ut på at en klient på mobil ved jevne mellomrom synkroniserte seg opp mot et serverområde og lastet ned bestemte XML script og kjørte disse på mobilen slik at endringer ble skrevet til Windows Mobile registeret. Problemet var at vi ikke hadde noe funksjonalitet som rapporterte at filen var kjørt på mobil og derfor ikke trengte å bli lastet ned på nytt. Dette førte til mye datatrafikk og batteriet gikk fort tomt. Vi ble derfor nødt til å se oss om etter andre løsninger. Løsningen var en webservice som laget en jobb til klient. Når klienten hadde lastet filer til mobil og parset disse, rapporterte webservicen om at jobben var utført slik at filene ikke ble lastet ned flere ganger. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 58

59 4 Kravspesifikasjonen 4.1 Generelt Kravspesifikasjonen har vært til god hjelp for oss under prosjektets gang og har ført til at vi har holdt oss til de gitte rammebetingelser. Når kravspesifikasjonen ble opprettet var den rettet etter oppdragsgivers ønsker og krav. Disse kravene var ikke veldig strengt formulert, noe som ga oss ganske store spillerom på hva som skulle implementeres. Vi bestemte derfor i ganske stor grad hva som skulle implementeres og hvordan dette skulle gjøres. Vi ble i begynnelsen av prosjektet litt satt ut av hvor mye nytt som måtte læres og hvor avansert teknologien virket. Etter råd fra prosjektveileder på HIO ble vi derfor enige med oppdragsgiver om å begrense funksjonalitetsmengden i kravspesifikasjonen betraktelig. Hele KioskMode biten ble derfor prioritert bort i kravspesifikasjonen. Denne ble satt under fremtidige utvidelser, en funksjonalitet som skulle utvikles dersom tiden tillot det. 4.2 Endringer i kravspesifikasjonen Ettersom våre kunnskaper i.net plattformen økte så vi det som realistisk å utvikle KioskMode applikasjonen i tillegg til Configuration Manager. Litt ut i prosjektperioden ble vi også bedt om å endre måten Configuration Manager skulle fungere på. Vi ble derfor nødt til å lage en ny revidert utgave av kravspesifikasjonen for å imøtekomme de nye kravene som var satt. 4.3 Kravspesifikasjon i forhold til design og implementering I kravspesifikasjonen satte vi klare krav til design av systemet. Vi mener at de krav som ble satt i kravspesifikasjonen stemmer overens med, det endelige design av systemet. Siden det var satt klare krav til brukervennlighet og design, har vi ikke hatt nevneverdige problemer når dette skulle utvikles. De krav som ble satt til implementering av koden ble også fulgt opp. Dette gikk i hovedsak ut på hvordan kodestrukturen skulle være bygd opp og om regler for design av klasser og datastrukturer. Fordi alle gruppemedlemmene fulgte disse retningslinjer var det vært enkelt for oss å utveksle kode oss imellom uten å kunne se forskjell på hvem som hadde jobbet med koden. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 59

60 5 Oppsummering og konklusjon 5.1 Oppsummering Arbeidet med dette prosjektet har gitt oss et godt innblikk i hvordan det er å jobbe i slike store prosjekter og vi har lært hvor viktig det er å vektlegge de forskjellige fasene i prosjektet. Videre har vi innsett viktigheten av å overholde gitte tidsfrister. Vi føler at vi har lært veldig mye i så måte. Kompetansen vi har tilegnet oss kommer garantert godt med når vi kommer ut i arbeidslivet der jobbene ofte består av prosjekter som skal gjennomføres. 5.2 Hva kunne vært gjort annerledes? Det er alltid noe som kunne vært gjort annerledes i et stort prosjekt som dette, selv om vi mener vi har gjort ting ganske riktig hele veien. Vi har under prosjektets gang valgt forskjellige veier som vi senere har måttet gå tilbake på for å benytte en annen løsning. Dette kunne kanskje vært unngått ved bedre å planlegge hvilken fremgangsmåte skulle benyttes. Alikevel har det vært veldig nyttig med noe prøving og feiling fordi vi har lært enormt mye gjennom prosessen. I ettertid ser vi også at vi brukte mye tid på å finne ut registerverdien for XML provisjonerings scriptene til Windows Mobile 5. WM5 ble etter hvert nedprioritert noe som resulterte i at vi hadde brukt mye tid på testing av script som ikke var særlig relevante for dagens mobilmarked. 5.3 Produktets fremtid Vi har enda ikke hatt noen fremføring av produktet vårt for utviklerne hos Smartphones AS. Dette vil vi gjøres etter innlevering av sluttrapporten. Da SmartPhones under prosjektperioden fikk flere henvendelser fra kunder som forespurte en slik funksjonalitet som vårt produkt kunne tilby, er det nærliggende å anta at produktet vårt vil bli videreutviklet og kommersialisert. Vi har fått mange positive tilbakemeldinger fra SmartPhones AS på vårt produkt. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 60

61 5.4 Konklusjon Siden teknologien som ble brukt var nokså ny for oss var det i starten av prosjektet veldig mye nytt å sette seg inn i. Det har vært en veldig spennende og ikke minst lærerik prosjektperiode, som har gitt oss mange utfordringer underveis. Det er alltid vanskelig å forutse arbeidsmengden som er nødvendig for å gjennomføre et slikt prosjekt. Vi er meget godt fornøyd med at vi klarte å utvikle mye funksjonalitet som opprinnelig var satt under fremtidige utvidelser i kravspesifikasjonen. Dette var KioskMode applikasjonen og KioskMode designeren. Utfordringene i hovedprosjektet var mange i form av at mye av funksjonaliteten vi skulle utvikle ikke var støttet av Microsoft og kan ses på som hacking av operativsystemet. Vi er meget godt fornøyde med den arbeidsinnsatsen vi har gjort, og mener at vi har kommet langt i forhold til den tiden vi har hatt til disposisjon. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 61

62 6 Kilder Programming ASP.NET 3.5 Jesse Liberty, Dan Hurzwitz & Dan Maharry ISBN: Databasesystemer Bjørn Kristoffersen ISBN: Grunnleggende systemutvikling Thor E. Hasle & Gunnar Gurholt ISBN: UML Distilled Third Edition Martin Fowler ISBN: Windows Mobile Development handbook Andy Wigley, Daniel Moth, Peter Footh ISBN: Teach Yourself Visual C Sharp 2008 James Foxall NetBook Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 62

63 7 Vedlegg 7.1 Dagboken Vi har i dette hovedprosjektet loggført arbeidet i en prosjektdagbok. Dette har vi gjort for å holde kontroll på arbeidet som ble gjort, slik at det var lettere for veileder og kontaktperson å holde seg oppdatert for arbeidet vårt. Vi har i dette dokumentet kun lagt ved de loggføringene med mest relevant innhold. Dato: 6/12/08 Sted: IU/HIO Tid: 5 timer Tilstede: Kagiso, Christer, Daniel, Olav og Even Notat: - Vi fikk alle utdelt telefoner fra i-mate. En liten introduksjon til disse kommer senere. - Vi ble enige om å bruke Visual Studio 2005 som programmeringsverktøy. - Rammebetingelsene for prosjektet har blitt sendt til Christer, og han vil videresende disse til oss andre i løpet av dagen. - Vi har fått låne rapporten fra de som hadde hovedprosjekt hos Touch Mobility i 2007 som et eksempel. - Vi har ikke fått noen veileder for prosjektet enda, men dette skal skje i løpet av de neste dagene. - alle skal i nærmeste fremtid installere MS Visual Studio 2005 og nyeste SDK, og prøve ut funksjoner og prøve å finne Registry etc. - Vi har også funnet ut at Olav har ansvar for møtereferat og er også møteorganisator - arbeidsfordeling finner vi ut av ved neste møte. - Felles møter er foreløpig satt til mandager fra kl Kagiso tar ansvar for å finne toturials på Visual Studio(heretter omtalt som VS). - Christer finner ut av hvilke versjoner av SDK vi trenger. - Daniel sender mail til Ulf Uttersrud angående veiledning osv. - Christer skal lage til en profil på Mozo til alle i gruppa. - Vi skal også finne et navn til prosjektet, Daniel skal sjekke ut muligheten om å få tilgang til en Exchangeserver her på skolen. Dato: 12/1-09 Sted: IU/HIO Tid: 5 timer Tilstede: Olav, Christer, Kagiso og Daniel Notat: I dag har vi gjennomgått hvilke program vi skal ha/bruke. Vi har funnet ut at vi skal bruke MS VS Vi har også funnet fram til noen tutorials vi Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 63

64 skal bruke på MS VS Ellers har vi lastet ned MS SDK 5+6, og Mobile registry editor. Vi har også lånt noen bøker om C# og VS Ellers har vi prøvd oss litt fram på telefonene og i diverse verktøy vi skal bruke. Vi har avtalt faste dager som er mandag og tirsdag. Vi har tenkt til å sette hovedansvarsområder til hver enkelt deltager når vi har kommet ordentlig i gang med forprosjektet. Milepæler og fremdriftsplan begynner vi på i morgen den 13/1-09. Dato: 13/1-09 Sted: IU/HIO Tid: 5 timer Tilstede: Kagiso, Christer, Daniel og Olav Notat: Vi har brukt denne dagen på å prøve oss på en tutorial i VS Neste møte blir mandag den 19. januar kl hos TM. Dato: 19/1-09 Sted: IU/HIO Tid: 4 timer Tilstede: Kagiso, Daniel og Olav Notat: Christer var syk i dag, og det er greit at alle er samlet når vi skal gå i gjennom kravspesifikasjonen, så vi utsatte møte med Even inntil videre. Målet vi har i dag er å bli ferdig med fremdriftsplanen. Dato: 27/1-09 Sted: IU/HIO Tid: 5 timer Tilstede: Kagiso, Daniel og Olav Notat: I dag har vi skrevet ferdig forprosjektrapporten som skal leveres inn på fredag. Christer jobbet hjemmefra i dag, da tiden fremover skal brukes til å sette seg mer inn i VS og C#. Etter vi hadde gjort oss ferdige med forprosjektrapporten, jobbet vi med C# tutorials i VS. Dato: 6/2-09 Sted: IU/HIO Tid: 1 time Tilstede: Kagiso, Olav og Daniel Notat: Denne fredagen hadde vi en presentasjon av det vi skal ha prosjekt om. Den ble på ca. 10 minutter, og vi fikk også høre på de andre gruppenes presentasjon, som Eva er veileder for. Presentasjonen tok for seg prosjektet vårt i grove trekk, uten å gå for mye Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 64

65 inn i tekniske detaljer. Dato: 10/2-09 Sted: IU/HIO Tid: 5 timer Tilstede: Daniel, Olav, Even og Christer Notat: I dag gikk Even igjennom kravspesifikasjonen med oss, og vi fikk også en kjapp innføring i kjerneproduktet til TM, MOZO. Dato: 11/2-09 Sted: IU/HIO Tid: 1,5 timer Tilstede: Veileder, Even, Olav, Christer, Daniel og Kagiso Notat: I dag diskuterte vi videre fremgang av prosjektet, videre gjøremål, prioriteringer osv. Vi viste også frem en tegning vi hadde laget, som viste hvordan systemet vårt skal fungere, og de forskjellige modulene. Vi snakket også litt om arbeidsfordeling, og hvem som har lyst til å jobbe med hva. Dato: 12/2-09 Sted: IU/HIO Tid: 1, 5 timer Tilstede: Kagiso, Daniel, Christer, Olav, Eva og Even Notat: I dag diskuterte vi videre fremgang av prosjektet, videre gjøremål, prioriteringer. Vi snakket også litt om arbeidsfordeling, og hvem som har lyst til å jobbe med hva. Dato: 17/2-09 Sted: IU/HIO Tid: 6 timer Tilstede: Christer, Daniel, Kagiso og Even Notat: Vi har fordelt ansvarsområder i dag. Vi har delt arbeidet grovt opp i tre deler; klientdel, serverdel og testing. Klient og serverdelen har Daniel og Christer hovedansvaret for, mens Olav og Kagiso tar testingen. Dato: 20/2-09 Sted: Smartphones på Brynseng Tid: 2 timer Tilstede: Christer, Kagiso, Olav, Daniel, Even og representanter fra Smartphones Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 65

66 Notat: Vi har i dag vært i møte med Even og kollegaer av han i Smartphones på Bryn i Oslo. Vi fikk en presentasjon av firmaet Smartphones, som har kjøpt opp det som før het Touch Mobility. Vi vil derfor heretter bruke Smartphones som navn på vår oppdragsgiver. Vi har også fått tildelt en server, Microsoft Server 2003 Webedition. Men vi har på nåværende tidspunkt ikke bestemt oss for hvilken løsning vi skal bruke enda. Vi har også tilgang på en full lisens gjennom HIO, men Smartphones må få tillatelse til å bruke denne. Vi ble enige om å fortsette å prøve oss frem på telefonene og så møtes igjen til møte fredag den 27/2-09 klokka Da kan vi stille eventuelle spørsmål om ting og problemstillinger vi lurer på. Dato: 24/2-09 Sted: IU/HIO Tid: 6 timer Tilstede: Kagiso, Olav, Daniel og Christer Notat: I dag har Olav og Kagiso jobbet med tweaking og prøvd å stenge av noen funksjoner, uten at vi har lykkes helt med det. Christer og Daniel har jobbet med GUI og databaser etc. Dato: 26/2-09 Sted: IU/HIO Tid: 4 timer Tilstede: Olav og Kagiso Notat: Vi har fortsatt med tweaks, og har klart å stenge av for sending av filer med Bluetooth. Dato: 27/2-09 Sted: IU/HIO Tid: 5 timer Tilstede: Olav, Kagiso, Daniel og Christer Notat: I dag har vi gått igjennom spørsmål og status ang HTC TYTN og sett på GUI forslag som Christer har laget. Kim og Michael har kommet med forslag til hva vi bør ha hovedfokus på nå. Dato: 11/3-09 Sted: IU/HIO Tid: 7 timer Tilstede: Kagiso, Olav, Christer, Daniel, Even og veileder Notat: I dag har vi testet ut kioskmoden vi har klart å få til så langt. Vi hadde et møte med Even og Eva i løpet av dagen, hvor vi snakket om arbeidsfordeling, og at vi er nødt til å sette opp tempo, hvis vi skal bli ferdig med et brukbart resultat. Tiden går veldig fort, og det er ikke så lenge til neste innlevering. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 66

67 Vi har avtalt et møte med Even på fredagen (klokka 11) som kommer, på Smartphones. Dato: 13/3-09 Sted: Smartphones Tid: 6 timer Tilstede: Daniel, Christer og Olav Notat: I dag har vi vært hos Smartphones og jobbet. Har fått slått av noen funksjoner på HTC TyTN 2. Dato: 16/3-09 Sted: IU/HIO Tid: 7,5 timer Tilstede: Daniel, Olav, Kagiso og Christer Notat: Olav/Kagiso har jobbet videre med å låse ned funksjoner som bluetooth, wifi, kamera osv. Har fått slått av noen funksjoner, men vi har ikke klart å låse ned kamera på WM 5. Christer/Daniel har jobbet med utviklingen av klienten. Dato: 17/3-09 Sted: IU/HIO Tid: 5 timer Tilstede: Olav, Christer og Daniel Notat: Jobbet med Mysql og prøvde videre å få slått av kamera i registry på WM5 uten hell. Dato: 18/3-09 Sted: IU/HIO Tid: 1 time Tilstede: Olav, Christer, Daniel og veileder Notat: Vi har blitt enige om at innen en uke skal vi ha satt opp en fremdriftsplan angående hvilke funksjoner som skal ha hovedfokus fremover. Dato: 3/4-09 Sted: Smartphones Tid: 4 timer Tilstede: Kagiso, Olav, Christer og Daniel Notat: I dag har vi vist frem til noen av utviklerne på Smartphones hvor langt vi har kommet med prosjektet hittil. Vi har også jobbet videre med xml og testing på noen nye telefoner. Vi skal til uka få noen nye telefoner å jobbe med. Vi har også blitt enige om at vi skal ha hovedfokus på de telefonene med WM 6 på. Dato: 6/4-09 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 67

68 Sted: Tid: Tilstede: Notat: Smartphones 4 timer Olav, Christer, Kagiso og Daniel Vi har i dag jobbet med login systemet på serversiden og xml. Vi har også fått utdelt noen nye telefoner som vi har jobbet litt med i dag. Christer og Daniel har jobbet med KioskMode designeren. Dato: 10/4-09 Sted: Smartphones Tid: 4 timer Tilstede: Olav, Christer, Kagiso og Daniel Notat: Christer har jobbet med serverdelen og login funksjonen. Daniel har jobbet med KioskMode designeren og Kagiso og Olav har jobbet med de nye telefonene. Dato: 20/4-09 Sted: IU/HIO Tid: 5 timer Tilstede: Olav, Christer, Kagiso og Daniel Notat: Vi har jobbet med serverdelen/ login funksjonen og de nye telefonene. Dato: 24/4-09 Sted: IU/HIO Tid: 5 timer Tilstede: Olav, Christer, Kagiso og Daniel Notat: Arbeid for dagen har vært å se på hvordan vi skal dokumentere prosjektet. Jobbet videre med diverse XML og KioskMode designer og server. Dato: 29/4-09 Sted: IU/HIO Tid: 3 timer Tilstede: Kagiso, Olav, Christer og Daniel Notat: Vi har i dag hatt en framføring av det endelige produktet vårt, for veilederen vår på skolen og de andre gruppene. Dato: 4/5-09 Sted: IU/HIO Tid: 4 timer Tilstede: Kagiso, Olav, Christer og Daniel Notat: Vi har begynt å dokumentere produktet vårt. Daniel har også jobbet med Kioskmoden. Dato: 8/5-09 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 68

69 Sted: Tid: Tilstede: Notat: Smartphones 4 timer Kagiso, Olav, Christer og Daniel Jobbet med dokumentasjonen. Dato: 11/5-09 Sted: IU/HIO Tid: 5 timer Tilstede: Kagiso, Olav, Christer og Daniel Notat: Jobbet videre med dokumentasjonen. Dato: 13/5-09 Sted: IU/HIO Tid: 4 timer Tilstede: Kagiso, Olav, Christer, Daniel og veileder Notat: Vi har i dag hatt møte med veileder. Hun har lest noe av den dokumentasjonen vi har gjort og gitt oss tips i forhold til hva som skal være med i de forskjellige rapportene og oppbygningen av dem. Dato: 15/5-09 Sted: IU/HIO Tid: 5 timer Tilstede: Kagiso, Olav, Christer og Daniel Notat: Jobbet med dokumentasjonen. Dato: /09 Sted: IU/HIO-Smartphones Tid: Ca. 5 timer hver dag Tilstede: Kagiso, Olav, Christer og Daniel Notat: Nå er det en uke igjen til prosjektet skal leveres (29/5 klokken 12). Vi har denne uken jobbet med dokumentasjon og den siste finpussen på produktet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 69

70 7.2 Statusrapport Midt i prosjektperioden ble vi bedt om å skrive en statusrapport for hovedprosjektet av oppdragsgiver. Vi har lagt ved denne som et vedlegg til prosessrapporten, da den gir et godt bilde på hvordan prosjektets status var midt i prosjektperioden KioskMode KioskMode applikasjonen er den delen av prosjektet hvor fremgangen har vært størst med tanke på et fungerende produkt. De fleste knappene på de modellene vi har fått utlevert har blitt kartlagt. Ved enkelte telefonmodeller har vi hatt problemer med å låse noen knapper. Knappen som oftest byr på problemer er start knappen. Vi fikk hjelp av Kim på SmartPhones til å finne knappe verdiene ved hjelp av et form som kjøres på mobilen. Problemet er at når start knappen trykkes inn, mister formet fokus som resulterer i at knappverdien ikke vises. En løsning kan være å gjøre det slik at formet er always on top slik at det ikke mister fokus. Dette er noe vi skal se nærmere på dersom tiden tillater det. Ellers er det meste av jobben her videre kartlegging av andre mobiltelefoner, og hardwareknappen på disse. Koden bør også optimaliseres og GUI bør utbedres. GUI et bør fungere på alle skjermoppløsninger og i liggende og stående modus KioskMode designer Even foreslo denne funksjonen til oss et stykke ut i prosjektperioden. KioskMode designer skal være en del av serversiden, der en innlogget bruker kan designe sin egen KioskMode. Man skal ved hjelp av et skjema kunne fylle inn knappenavn + funksjon (eks. Windows\tmail.exe), samt at man kan skal kunne fylle inn hexadesimal verdien på knappene som må sperres. I denne sammenheng kunne det være en ide å videreutvikle knappeapplikasjonen som vi fikk hjelp til å lage av Kim, slik at den på en brukervennlig måte viser knappenes heks-verdi på mobilen ved hjelp av å trykke på den aktuelle knappen. Pr. dags dato fungerer kioskmode designer applikasjonen lokalt på datamaskinen (localhost). Den oppretter kioskmode applikasjonen og lager en.cab installasjonsfil til denne. Det som gjenstår er å få satt den opp på serveren og implementere funksjonaliteten slik at den samspiller med innlogget bruker etc Security Shield Klient Mobilklienten er en større utfordring når det gjelder koding og optimalisering av denne. Vi har en klient som nå laster ned xml filer fra en webserver ved gitte tidsrom og parser disse. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 70

71 Problemet nå er, at den laster ned alle filene som er lagt inn i koden. Uansett om disse filene er allerede lastet ned og allerede parset på device. Dette fører til mye datatrafikk og at batteriet går raskt tomt. Vi bør her lage en løsning som gjør at alle brukerne får en profil som blir oppdatert første gang xml filene blir lastet ned og parset. Når filene er lastet ned bør device sende status til server om at parsing ble gjennomført og var vellykket. Profilen på server blir da oppdatert. Neste gang device vil laste ned filene gir server beskjed til device at ingen av filene er endret eller at det er lagt til flere filer. En fil tilsvarer da en funksjon på device. Klienten vi har utviklet nå må spesial tilpasses for hvert device, eller gruppe som skal ha samme funksjoner deaktivert. Dette er ikke en løsning som er optimal. Det bør være mulig å legge til flere funksjoner, og å aktivere tidligere deaktiverte funksjoner. Dette skal vi prøve å få til dersom vi får tid Server Vi har nå mest gjenstående arbeid på serversiden. For alltid å ha tilgang til en server, har vi satt opp en egen server hos Christer. Denne kjører Windows Server 2008 med IIS 7 og MySQL 5.2. Vi diskuterte i en tidlig fase av prosjektet muligheten for å kode i PHP, siden dette er et språk vi har benyttet mye tidligere. Men siden vi alle ønsker å få kompetanse innenfor. NET plattformen har vi valgt bort dette. Vi har laget en DB modell i sin enkleste form. Dette ønsker vi ikke å gjøre mer omfattende en nødvendig. En utfordring her er hvordan vi på en best mulig måte kan holde orden på alle profilene. Når det gjelder GUI er vi i grunn ferdig med utformingen. Du finner en dummy i HTML her: Alle elementene vil nok ikke være tilgjengelig på den endelige utformingen. Fokuset vil ligge mest på brukerhåndtering. Utvikling av serversiden vil få størst prioritet i tiden som nå gjenstår av prosjektet XML filer og registerverdier Xml-filene vi lager skal deployes fra serversiden, disse filene inneholder registerverdier som skal disable/enable funksjoner og applikasjoner på klienten, alt etter hva verdiene er satt til. Klienten parser xml -filene og setter opp telefonene ut i fra xml -filenes innhold. Arbeidet med å finne frem i registeret har vist seg å være ganske så kronglete, siden det sjelden er noe særlig logikk i nøklene og deres verdier. Det har vist seg at det er enklere å slå av funksjonene på de nyere modellene, slik som HTC TyTn 2 og HTC P4350. Begge disse kjører på Windows Mobile 6. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 71

72 Kamera har også blitt en utfordring, da spesielt på modellene som kjører WM 5, og vi har bestemt oss for at dette er en funksjon som ikke er av høyeste prioritert på nåværende tidspunkt. Vi har fortsatt en del utfordringer når det gjelder xml -filene, og få de til å fungere på alle modellene. Vi vil fortsette å jobbe videre med dette fremover, og få kartlagt hvor i registeret de forskjellige funksjonene ligger på de ulike modellene. Nedenfor følger en liten oversikt over de funksjonene vi pr. dags dato har fått slått av på de ulike modellene vi har fått utdelt hittil. OS WM 6 WM 5 WM 6 WM 5 WM 6 WM 5 WM 6 i-mate HTC i-mate Qtek HTC HTC Ultimate i-mate HTC XML Script TyTN2 s200 Diamond TyTN 8150 Jamin P4350 Disable camera Disable bluetooth Disable 3G Disable Wi- Fi Disable GPRS Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 72

73 S E CURI TYS HI E L D PRODUKTRAPPORT

74 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 74

75 Forord Dette dokumentet tar for deg selve programmet og alle dets egenskaper. Det vil i detalj bli beskrevet hvordan systemets deler fungerer sammen. Det blir også redegjort for oppbygning og virkemåte for de forskjellige delene. Dokumentet er først og fremst beregnet på sensor men vil også være til stor hjelp til de som skal sette seg inn i programmet for å vedlikeholde eller eventuelt videreutvikle dette. Det forventes at leseren har de nødvendige tekniske kunnskaper for kunne sette inn i dette dokumentet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 75

76 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 76

77 Innholdsfortegnelse Innhold 1. Innledning Om bedriften Dagens situasjon Mål og rammebetingelser Teknologier Utviklingsmiljø Betingelser Beskrivelse av teknologi NET Framework NET Compact Framework 2.0 og Microsoft Visual Studio Visual C# ASP.NET Dropbox Signering Forutsetning for bruk av produktet Klientsiden Kioskmode og Device manager Security Shield webgrensesnitt Server Oppbygning og virkemåte generellt Introduksjon De forskjellige delene Overføring Oppgaver Brukergrensesnitt Master Pages Tiligjenglighet Configuration manager Webgrensesnitt Rettigheter for de forskjellige rollene Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 77

78 5. Brukerhåndtering i security Shield Databasestruktur Oppbygning og virkemåte for KioskMode designer Generelt Konseptuel modell Oppretting av installasjonsfil KMDesigner.aspx KMDesigner1.aspx til KMDesigner8.aspx Build.aspx Sending av SMS Utdrag fra CSoftSMSGateway klassen Sending av SMS til bruker Sekvensdiagram for overføring av KioskMode installasjonsfilen via SMS Forklaring på sentrale funksjoner i KioskMode designeren Oppbygning og virkemåte for KioskMode designer klient Generellt Fysisk oppdeling av applikasjon Grensesnitt KioskMode hovedmenyen (KioskEngine.exe) Deaktivering av start menyen Løsning 1 for å deaktivere start menyen Løsning 2 for å deaktivere start menyen KioskMode administrator funksjonalitet Applikasjonen starter automatisk ved oppstart Hardwareknapper som fungerer som snarvei til applikasjoner er låst ned Installasjonsfilen KMInstaller.cab Modell av KMInstaller.cab ROM installasjon Oppstartsfilen CFVersionCheck.exe utfører en Compact Framework versjonskontroll Grafikk og skalering Språklig uavhengiget Sentrale funksjoner i KioskMode applikasjonen Beskrivelse av sentrale klasser Sikkerhet Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 78

79 8.1 Generelt Sikkerhet i forhold til brukere av systemet Sikkerhet i forhold til testing Teknisk implementering Samsvar mellom kravspesifikasjon og produkt Fremtidige utvidelser Enhached settings Sikkerhetsutvidelser i KioskMode applikasjonen Utsendelse av nedlstningslink via SMS til alle brukerne i et firma Vedlegg Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 79

80 1. Innledning 1.1. Om bedriften Touch Mobility AS ble startet i 2005 med eiere som Telenor og Kjedehuset. Firmaet leverte IT/Telecom løsninger via de største forhandlerkjedene innen mobilmarkedet. Touch Mobility AS spesialiserte seg på såkalt Device Management løsninger med produktportføljen kalt MOZO i spissen. Smartphones Telecom AS ble dannet i 2004 og leverte produkter innen Device Management og PIM rettet mot mobilmarkedet. Smartphones Telecom AS besto av 25 ansatte fordelt på administrasjon, salg, teknisk og utvikling. Smartphones Telecom AS ble i 2007 kjøpt opp av Telenor. Smartphones AS ble dannet i januar 2009 da tidligere Touch Mobility AS ble kjøpt opp av Telenor og fusjonert med SmartPhones Telecom AS. SmartPhones AS har spesialisert seg på mobilteknologi, administrasjonsløsninger og tjenester rettet mot mobilitet. SmartPhones AS er i dag ledende innenfor dette markedet i Norge. Produkter som MOZO, Telenor Mobil Kontroll, DME, Afaria, AnyMail og msuite er noen av produktene firmaet kan tilby. SmartPhones AS holder til på Brynseng i Oslo og har avdelingskontor i Sverige og Danmark Dagens situasjon En kan tenke seg en stor bedrift som ønsker å rulle ut en rekke applikasjoner til sine ansatte via mobiltelefonen. Til dette ønsker de seg gjerne en mobiltelefon med en skreddersydd løsning spesielt tilpasset bedriftens behov. For eksempel ønsker de seg at mobiltelefonen kun skal kunne brukes til å ringe, sende sms og surfe på internett med. All annen funksjonalitet som spill eller Office applikasjoner skal være sperret for brukeren. Bedriftens tekniske ansvarlige begynner å undersøke markedet for å finne den beste løsningen til dette. Den mest opplagte løsningen vil være å lage et eget operativsystem til mobilen som kun inneholder den ønskede funksjonaliteten. Problemet er at dette kan være meget dyrt å utvikle samtidig som det vil ta lang tid å lage et slikt system. Det beste alternativet blir da å utvikle en Kiosk applikasjon for Windows Mobile baserte mobiltelefoner. En kiosk applikasjon låser ned mobiltelefonen slik at brukeren kun får tilgang til valgte applikasjoner og tjenester. All annen funksjonalitet er sperret for brukeren. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 80

81 En annen funksjonalitet som etterspørres er muligheten til å kunne slå av og på forskjellige funksjoner på Windows Mobile telefoner via en server, dette for å kunne kontrollere de ansattes mobiltelefoner uansett hvor i verden de måtte befinne seg. Slik funksjonalitet er såkalt provisjonering av mobilen. Funksjoner det er aktuelt å kontrollere er bluetooth, wlan, minnekort leser, usb tilkobling etc. Av praktiske årsaker bør denne provisjoneringen foregå ved hjelp av OTA (Over the air) teknologi slik at man kan sitte på en server fjernstyre mobiltelefonene. Dette er funksjonalitet som Smartphones AS per dags dato ikke har noen egen løsning for. Smartphones AS ønsker derfor å utvikle en egen løsning for denne funksjonaliteten og integrere dette i den løsningen de per dags dato tilbyr sine kunder Mål og rammebetingelser Målet med oppgaven var å utvikle en klient/server fjernstyrings applikasjon for mobilen, samt en Kiosk applikasjon for mobilenheter basert på Windows Mobile 5 og 6. Vi la vekt på en enkel og fleksibel løsning som skulle være så brukervennlig som mulig. Applikasjonen skulle kunne tilfredsstille brukerens behov i form av å få full kontroll over brukerens Windows mobil. Følgende funksjoner var det aktuelt å kunne aktivere/deaktivere fra serverside: Kamera Bluetooth/IR Wlan Autorun fra SD minnekort-slot ActiveSync Låse today screen/startskjermbildet Koblinger/EDGE/3G/HSDPA låsing Rapportere fra klient tilbake til server hvilke parametre som er satt på en telefon Hovedfunksjoner som måtte implementeres i Kiosk applikasjonen: Låse hardware knapper Vise et predefinert velkomstbilde et menyvalg for ønskede programmer Fjerne start menyen som gir brukeren tilgang til et bredt spekter av programmer Deaktivere bluetooth Deaktivere ActiveSync Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 81

82 Deaktivere Autorun fra minnekort Deaktivere Run funksjonen ved klokken Rammebetingelser Hovedfunksjonaliteten for applikasjonen var fjernstyringen av Windows mobiltelefonen og Kiosk applikasjonen. Vi sto relativt fritt til å velge funksjonalitetsmengden som skulle implementeres. I startfasen av prosjektet ble det gjort en vurdering av hvilke arbeidsoppgaver det var viktigst å få på plass og disse fikk høyest prioritet. Dette gjorde vi fordi det i en tidlig fase av prosjektet var vanskelig å forutsi arbeidsmengden det ville ta for å implementere de forskjellige elementene i prosjektet. Ingen av gruppemedlemmene hadde erfaring med Windows Mobile programmering og det var derfor vanskelig å forutse hvor lang tid det ville ta, å sette seg inn i programmeringsspråk, programmeringsverktøy etc. Til utstyr ble det stilt til rådighet en PDA til hvert av gruppemedlemmene. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 82

83 2. Teknologier 2.1. Utviklingsmiljø Det var et krav som både var underforstått på grunn av operativsystemet som kjører på enhetene produktet skal utvikles for, samt fra oppdragsgiver at all programmering skal skje på Microsoft sitt.net Framework versjon 3.5. For den mobile enheten ble det brukt Microsoft Compact Framework v 2.0 som er spesielt tilpasset for Windows Mobile operativsystemet. På serversiden skulle vi benytte ASP.NET som er den delen av Microsoft.NET Framework som er beregnet på webapplikasjoner. Som database valgte vi å benytte os av MS SQL relasjonsdatabase Betingelser Oppdragsgiver fastsatte i begynnelsen av prosjektet hvilken utviklingsplattform vi skulle bruke. Grunnen til dette var at de ønsket at vi skulle benytte oss av samme utviklingsplattform som SmatPhones AS selv bruker. Dette fordi det ville bli enklere for oppdragsgiver å sette seg inn i og videreutvikle produktet vårt og det var derfor naturlig å benytte deres teknologi Beskrivelse av teknologi Under beskrives de forksjellige teknologiene som er benyttet i vårt hovedprosjekt NET Framework 3.5.NET er et felles rammeverk som inneholder et bredt spekter av teknologier, standarder og utviklingsverktøy fra Microsoft. Alle programmer som kompileres, blir kompilert til et mellomformat som kalles Microsoft Intermediate language. Ved kjøring blir dette mellomformatet kompilert til det formatet prosessoren kan håndtere. På grunn av at kompileringsprosessen utføres til et felles format kan ulike utviklingsspråk som Visual Basic, Visual C#, C++ og J# benyttes under samme plattform NET Compact Framework 2.0 og 3.5.NET Compact Framework er den delen av.net rammeverket som er beregnet på mobile enheter, som kjører Windows mobile som operativsystem. Compact Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 83

84 Framework benytter seg av mange av de samme klassebibliotekene som.net Framework, selv om dette rammeverket er noe mer begrenset. Samtidig finnes det noen biblioteker som er spesielt tilpasset for.net Compact Framwork. Deler av KioskMode applikasjonen benytter seg av NET Comapct Framework versjon Microsoft Visual Studio 2008 Microsoft Visual Studio er et utviklingsverktøy som gjør det enklere å utvikle programvare som kjører på.net Framework. Dette verktøyet kan benyttes til å utvikle WEB applikasjoner, WEB services, programvare for Windows, programvare for Office systemet samt applikasjoner for mobile enheter. Følgende plattformer støttes av Visual Studio: Microsoft Windows Servere og Workstations Pocket PC Smartphones Nett lesere Visual studio inkluderer følgende utviklingsspråk: Visual Basic (.NET) Visual C# Visual C++ Visual J# ASP.NET Visual C# Vi har primært benyttet Visual C# som utviklingsspråk i dette hovedprosjektet. Vi vil heretter omtale Visual C# som C#. Dette språket er et relativt nytt språk og bygger på C, C++ og JAVA. Fordelen med å benytte C# er at man får tilgang til et bredt spekter av forskjellig klassebiblioteker siden språket er tett integrert med.net plattformen. Ingen i gruppen vår hadde noe erfaring med programmering i C#. C# er relativt likt i oppbyggingen som JAVA, et språk som vi har hatt kurs i tidligere i studiet. Overgangen fra JAVA til visual C# gikk derfor relativt greit ASP.NET ASP.NET er en Microsoft utviklingsplattform for web applikasjoner. Ved å bruke ASP.NET går det både raskt og enkelt å lage robuste web applikasjoner. Fordelen Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 84

85 med ASP.NET fremfor andre utviklingsspråk som PHP er at ASP.NET har mange ferdige komponenter og funksjoner som kan benyttes i web utviklingen. Vi har også benyttet enkelte AJAX komponenter på websiden. Vi har benyttet denne teknologien i vårt prosjekt til utviklingen av vår løsning Dropbox Vi har i dette prosjektet benyttet oss av applikasjonen dropbox for lagring av prosjektdokumenter. Dropbox gjør det mulig for flere brukere å dele på filer online. Alle prosjektets deltakere har hatt tilgang til en felles mappe på sin datamaskin som synkroniseres opp mot en server. Vi har benyttet oss av dette verktøyet for å ha en sentral kilde der all kode lagres. På denne måten var vi sikre på at koden vi jobbet med ikke gikk tapt samt alle til enhver tid hadde mulighet til å jobbe med samme kode. En annen fordel var at vi hadde tilgang til koden uansett hvilken datamaskin vi satt på forutsatt at vi hadde tilgang til Internett. Dette gjorde det også enklere å holde hverandre oppdatert med hva den enkelte jobbet med til enhver tid Signering Vi har benyttet oss av Microsoft sitt test sertifikat for utviklere sdkserts.cab. Vi har signert applikasjonen med SamplePrivDev.pfx. Dette er et test sertifikat som Microsoft har laget for applikasjoner som er under utvikling. Se bruksanvisning for info om hvor man kan få tak i sertifikatet Forutsetning for bruk av produktet Under følger forutsetninger for bruken av produktet Klientsiden KioskMode og Device manager Compact Framework 2.0 Windows Mobile 5.0 Sertifikatet sdkcerts.cab Security Shield webgrensesnitt Microsoft Windows XP og Vista Internet explorer 7.0 Mozilla Firefox Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 85

86 I prinsippet kan alle operativsystemer og nettlesere benyttes, men det er dette vi har testet og verifisert webgrensesnittet for Server Microsoft Windows Server 2003 MSSQL relasjonsdatabase.net Framework 3.5 ASP.NET Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 86

87 3. Oppbygging og virkemåte generelt 3.1. Introduksjon Beskrivelse av oppbygging og virkemåte for applikasjonen er grundig forklart i de neste avsnittene. Vi har delt forklaringen inn i to hoveddeler. En del som tar for seg oppbygging og virkemåte på serversiden, og en del som tar for seg oppbygging og virkemåte på klientsiden. Vi følte det var naturlig å skille disse fra hverandre. Hver hoveddel inneholder inngående tekniske beskrivelser og forklaringer av de teknologiene benyttet i utformingen av de ulike delene De forskjellige delene Hele prosjektet Security Shield består av fire deler. To på serversiden, KioskMode Designer og Configuration Manager, og to på klientsiden, KioskMode klient og Configuration Manager klient. KioskMode Designer og Configuration Manager kjører begge på en webserver, og klientene kjøres på en Smartphone eller PDA med Windows Mobile 5 eller høyere. Forutsetninger finner du under 2.4 Forutsetninger for bruk av produktet Hvis man deler KioskMode og Configuration Manager fra hverandre, kan man i hovedsak beskrive de to forskjellige applikasjonene slik. KioskMode er en applikasjon som lager et skall over Windows Mobile sitt UI. Her får brukeren kun tilgang til funksjoner som administrator har tillatt i KioskMode Designer. KioskMode Designer bruker da administrator for å bygge KioskMode klienten. Configuration Manager er en applikasjon for å fjernstyre aktivering og deaktivering av enkeltfunksjoner på en Windows mobiltelefon. Klienten som kjører på mobiltelefonen brukes til å koble seg opp mot en webtjeneste på server for å oppdatere profilen til brukeren. Dette utføres ved å sende provisjonerings xml filer fra server til mobiltelefon som blir provisjonert på mobiltelefon. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 87

88 3.3. Overføring All kommunikasjon skjer over trådløs datakobling. Filstørrelsen på 1-20KB er såpass liten at ingen komprimering er nødvendig. Mer utfyllende informasjon om de forskjellige delene av applikasjonene blir beskrevet senere i dokumentet Oppgaver Oppsummert har løsningen følgende oppgaver å ivareta: Generelt Tilby bruker webgrensesnitt for innlogging til Security Shield KioskMode Gi kunde tilgang til å bygge en KioskMode klient gjennom et webgrensesnitt Sende link til klient nedlasting i en SMS Overføre KioskMode klient og installere denne på mobiltelefon Avinstallere klient ved bruk av administrator passord Configuration Manager Gi kunde et webgrensesnitt for brukeradministrasjon i Configuration Manager Webtjeneste som sjekker brukerprofil i database, og sender provisjonerings XML ved ikke utførte oppgaver. Klient skal identifisere enheten ovenfor webtjenesten Motta XML og provisjonere mobiltelefon Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 88

89 3.5. Brukergrensesnitt Brukergrensesnittet i de forskjellige delene har blitt laget med tanke på å ha et så oversiktlig system som mulig. Vi har så langt har latt seg gjøre forsøkt å ha et likt utseende på hele systemet. På klientene har vi forsøkt å gjøre grensesnittet så likt Windows Mobile sitt grensesnitt som mulig. Grunnen til dette er at vi ikke ønsker å fremmedgjøre brukeren ved å tilføye mange ukjente elementer. Dette vil bare være en ulempe for systemet. Problemet med dette kan være de nyeste telefonene på markedet. Disse modellene har ofte et eget UI utenfor Windows Mobile sitt standard UI. Windows mobiltelefoner har i den siste tiden økt sin markedsandel. Mye pga. billigere enheter, og mobil produsentenes fokus på design og utforming. Vi mente derfor at løsningen vår burde være så enkel at enhver bruker skulle kunne bruke systemet. Det ble raskt tydelig at en KioskMode applikasjon var ettertraktet hos Smartphones. De trengte en måte å forenkle bruken av Windows mobiltelefoner for en gruppe eldre brukere. Grensesnittet ble derfor inspirert av dette. Antallet klikk brukeren må gjøre for å bruke systemet har blitt forsøkt gjort så lavt som mulig. I KioskMode har vi brukt store ikoner for hvert program eller funksjon som er tilgjengelig. I Configuration Manager trenger bruker kun å trykke en gang på Update Profile for å oppdatere sin profil. Dette er den oppgaven som brukeren oftest vil utføre. Websidene er laget med tanke på å separere semantikk fra utforming. Vi har brukt CSS og HTML og ASP.NET sin mulighet for Master Pages. Vi har da separert meny og generelle komponenter fra det dynamiske innholdet. HTML og CSS Semantikken av websidene er gjort med HTML, som stort sett alle websider bruker. For HTML finnes det flere standarder man kan bruke. Disse standardene vedlikeholdes av W3C ( Standarden vi bruker i Security Shield er XHTML 1.0 Transitional. Alle sidene har blitt testet og validerer med standarden. Utseende av sidene er definert i separate CSS filer. W3C vedlikeholder også standarder for hvordan CSS filer skal utformes også. Vi har brukt CSS 2.1 standarden i Security Shield og filene validerer også for CSS. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 89

90 3.6. Master Pages Fremstilling av Master Pages hentet fra asp.net ASP.NET master pages tillater oss å lage en konsistent utforming av sidene i applikasjonen. En enkelt master page kan definere standard utforming og elementer for hele applikasjonen. Det er mulig å bruke flere master pages for å gi forskjellig utforming for forskjellige områder innenfor en applikasjon. Vi har kun benyttet en master page for å gi hele applikasjonen den samme utformingen. For å fylle en master page med dynamisk innhold bruker vi content pages. Disse content pages fyller sitt innhold inn i vår master page i et definert område Tilgjenglighet Et viktig hensyn når en utvikler webgrensesnitt er å vurdere tilgjengligheten til løsningen. Dette er en todelt vurdering der den ene går på det tekniske (operativsystem/nettleser/hardware) og det andre er menneskene som skal benytte løsningen. Vi benytter oss av SiteVista ( Dette viste at følgende browsere var støttet: Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 90

91 Internet Explorer 5 (win/mac), 5.5, 6 og 7 Netscape 7 og 8 Opera 8 og 9 Firefox 1 og 2 Safari 2 Mozilla 1.x Den menneskelige delen av tilgjenglighetstesting går på noen grunnleggende funksjoner som at tekststørrelse kan økes, gode kontraster mellom tekst og bakgrunn, fornuftig strukturering av innhold, tydelig og forklarende språk, osv. Vi har ikke gått grundig inn på å gjøre denne løsningen maksimalt tilgjenglig pga at det ikke var tid til dette. Likevel er grunnleggende prinsipper fulgt slik at det enkelt kan videreutvikles før en eventuell kommersialisering av løsningen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 91

92 4. Configuration Manager Configuration Manager er en tredelt applikasjon. Den ene delen av applikasjonen er server delen. Den andre er klient applikasjonen som kjører på mobiltelefonen. Den tredje er webtjenesten mobiltelefonen bruker for å oppdatere sin profil Webgrensesnitt Webgrensesnittet til Configuration Manager følger samme utforming som resten av Security Shield websiden. Her kan kundens administrator se alle brukerne som er registrert hos sitt firma og oppdatere profilen til disse. Der er også muligheter for å legge til og fjerne brukere Tilkobling til database På rotnivå for webapplikasjonen har vi en web.config fil som overstyrer machine.config filen. Her bruker vi en connectionstring for å koble applikasjonen til en database. Vi har to connectionstrings som kobler til henholdsvis SecurityShield og CMDatabase databasene Connection Strings <connectionstrings> <add name="securityshieldconnection" connectionstring="data Source=.\SQLEXPRESS; Initial Catalog=SecurityShield; User Id=SecurityShieldUser; Password={SENSURERT}" providername="system.data.sqlclient" /> <add name="cmdatabaseconnection" connectionstring="data Source=.\SQLEXPRESS; Initial Catalog=CMDatabase; User Id=CMUser; Password={SENSURERT}" providername="system.data.sqlclient" /> </connectionstrings> Skriving og lesing fra database For lesing og skriving mot databasen bruker vi LINQ i ASP.NET rammeverket. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 92

93 LINQ Language Integrated Query LINQ er en ny standard for å lage spørringer mot en datasamling på. I vårt prosjekt bruker vi kun datakoblinger mot databaser. For å hente ut dataen i databasen har vi brukt LINQ to SQL Classes. Med LINQ lager vi klasser av de forskjellige tabellene i databasen. Vi kan da bruke innebygde metoder for å hente ut, endre og legge til data Klient Klienten blir brukt for å identifisere mobilen med en unik string. Denne blir sendt med til en webtjeneste som sender tilbake en XML fil. Denne XML filen blir så provisjonert på mobiltelefonen Hente unik string Kaller GetDeviceUniqueID fra Coredll.dll [DllImport("coredll.dll")] private extern static int GetDeviceUniqueID([In, Out] byte[] appdata, int cbapplictiondata, int dwdeviceidversion, Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 93

94 deviceidoutput, pcbdeviceidoutput); [In, Out] byte[] out uint Vi kan da lage en metode for å lage den unike stringen. private byte[] GetDeviceID(string AppString) { // Call the GetDeviceUniqueID byte[] AppData = new byte[appstring.length]; for (int count = 0; count < AppString.Length; count++) AppData[count] = (byte)appstring[count]; int appdatasize = AppData.Length; byte[] DeviceOutput = new byte[20]; uint SizeOut = 20; GetDeviceUniqueID(AppData, appdatasize, 1, DeviceOutput, out SizeOut); return DeviceOutput; } Vi kaller på metoden, og lager en string byte[] buffer = GetDeviceID("ConfigurationManager"); StringBuilder sb = new StringBuilder(); for (int x = 0; x < buffer.length; x++) { sb.append(string.format("{0:x2}", buffer[x])); } Provisjonering ProvisionDevice() private void ProvisionDevice() { try { WebService.Service ws = new WebService.Service(); string xml = ws.updatedevicebyid(id); XmlDocument xmldoc = new XmlDocument(); xmldoc.loadxml(xml); Microsoft.WindowsMobile.Configuration.ConfigurationManager.ProcessConfigura tion(xmldoc, false); MessageBox.Show("Profile updated. Please restart device to ensure that changes take effect.", "Configuration Manager"); } catch Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 94

95 { MessageBox.Show("Could not update device. Please try again", "Configuration Manager"); } } Her kobler klienten seg opp mot webtjenesten vi har referert til i Web References. Klienten sender den unike stringen, lagret i ID, for mobiltelefonen. ER det gjort endringer i profilen, vil klienten motta et XML dokument. Når vi har mottatt XML dokumentet fra webtjenesten blir det lastes inn i minnet. Vi laster XML filen inn i minnet med xmldoc.loadxml(xml). Klienten vil da bruke XML dokumentet som er lastet inn i minnet til mobilen for å provisjonere mobilen. ConfigurationManager er en klasse i Microsoft.Mobile namespace. Klassen sørger for at provisjonerings XML filer blir sendt til rett CSP Configuration Service Provider CSP Configuration Service Provider På en mobiltelefon er der mange forskjellige CSP. Den vi bruker er Registry CSP. Den kan endre registeret, eller spørre om verdier i registeret. Endringer og spørringer skjer ved å bruker XML filer. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 95

96 5. Brukerhåndtering i Security Shield Security Shield som en samlet tjeneste er avhengig av å kunne identifisere de forskjellige brukerne, og gi de forskjellige brukerne spesifikke rettigheter. For å få til dette måtte vi lagre data om hver bruker som har tilgang til systemet. Dette gjorde vi ved å lagre data i Microsoft SQL Server 2008 Express. Vi har benyttet en egen database for å holde styr på innlogging i Security Shield. Denne databasen holder styr på rettighetene til brukerne ved å definere brukerne i forskjellige roller. Det er 2 forskjellige roller for brukerne av systemet. Den ene rollen heter admin, og inneholder alle brukerne som har administrasjons rettigheter. Dette er typisk ansatte hos Smartphones. Den andre rollen heter user, og inneholder alle kunder som har tilgang til Security Shield. Rettigheter for de forskjellige rollene Administrator Brukere registrert i denne rollen har tilgang til alle mapper og undersider i Security Shield. De viktigste administratoroppgavene er tilgjenglige i mappen /Administration Kunder Kunder har tilgang til sider som ligger i mappen /Customer. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 96

97 5.1. Databasestruktur Databasen inneholder flere tabeller som ikke er tatt med i dette diagrammet. Grunnen til dette er at de ikke er i bruk i dagen system. Disse tabellene gir mulighet for ytterligere å utvide funksjonaliteten. aspnet_users Denne tabellen inneholder brukernavn for alle brukerne. aspnet_roles Denne tabellen inneholder informasjon om alle roller. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 97

98 aspnet_usersinroles Denne tabellen binder brukere opp mot de forskjellige rollene aspnet_membership Denne tabellen inneholder brukerens detaljer for autentisering. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 98

99 6. Oppbygging og virkemåte for KioskMode designer 6.1 Generelt KioskMode designeren er en web-serverapplikasjon som gir brukeren muligheten til å designe sin egen KioskMode klient via et webgrensesnitt. KioskMode designeren har to hovedfunksjoner i denne totalløsningen: Opprette en KioskMode installasjonsfil. Distribuere installasjonsfilen over på mobiltelefonen. KioskMode designeren fungerer som en type designer Wizard på maksimalt ti steg som lar brukeren velge ønskede innstillinger for KioskMode applikasjonen som skal opprettes. I denne KioskMode designeren har vi presentert brukeren de forskjellige valgene i tre hoveddeler: Webside KMDesigner.aspx KMDesigner1.aspx - KMDesigner8.aspx Build.apx Egenskap Første steg i KMDesigneren som lar brukeren velge generelle innstillinger for KioskMode applikasjonen Dette er åtte websider som henholdsvis lar brukeren velge egenskapene for maksimalt 8 knapper Denne kompilerer og oppretter Installasjonsfilen KMInstaller.cab. Denne presenteres for brukeren enten ved en nedlastningslink på websiden eller en SMS med nedlastingslink som kan sendes til mobilen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 99

100 6.2 Konseptuel modell Her presenteres en konseptuel modell for å vise hendelsesflyten i KioskMode designer delen av Websiden. Første steg er KMDesigner.aspx, andre steg er KMDesigner1.aspx til KMDesigner8.aspx som registrerer informasjon om knapper. Etter hver knapp som legges til kan man avslutte og gå til Build.aspx siden som er siste steg i KioskMode designeren. Denne oppretter installasjonsfilen og distribuerer denne til brukeren via en http nedlastningslink eller via SMS til mobil enhet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 100

101 6.3 Oppretting av installasjonsfil Hovedfunksjonen til KioskMode designeren er å opprette installasjonsfilen KMInsataller.cab og distribuere denne. Logikken rundt dette er at alle nødvendige filer for å opprette denne filen ligger lagret i mappen KMDesignerFiles på serveren. Her ligger alle Visual Studio prosjektene med deres respektive filer som må pakkes inn i KMInstaller.cab filen. Det mest sentrale Visual Studio prosjektet i denne sammenheng er KioskEngine prosjektet. For å kunne endre dette prosjektet etter brukerens behov har vi laget en standard mal av filene Login.cs og MainForm.cs henholdsvis kalt LoginReplace.cs og MainFormReplace.cs. Når brukeren legger inn ønsket informasjon om sin KioskMode applikasjon i KioskMode designerens brukergrensesnitt åpnes malene LoginReplace.cs og MainformReplace.cs og ønsket informasjon skrives til disse filene. Denne informasjonen skrives til filene ved hjelp av en StringReplace funksjon som overskriver tekst i prosjekt mal filen med input som brukeren skriver inn via web grensesnittet til KioskMode designeren. Deretter erstattes de originale prosjektfilene Login.cs og MainForm.cs med malene LoginReplace.cs og MainFormReplace.cs som nå inneholder brukerens ønskede KioskMode informasjon. Hele løsningen til KioskEngine prosjektet ligger nå klar til å kompileres ned til KioskEngine.exe filen som skal pakkes inn i KMInstaller.CAB. KioskMode designeren kjører nå en build på hele løsningen KioskEngine.sln ved hjelp av MSBuild.exe som er et Microsoft verktøy for å kompilere Visual Studio løsninger via Windows command prompt. KioskEngine.exe er nå ferdig kompilert og klar til å pakkes inn i KMInstaller.CAB filen. Deretter pakkes alle nødvendige filer inn i KMInstaller.cab filen ved hjelp av CabWiz.exe som er et Microsoft program for oppretting av.cab installasjonsfiler via Windows command prompt. KMInstaller.cab filen ligger nå ferdig laget på serveren. Det opprettes så en unik mappe for den innloggede bedriften på serveren og installasjonsfilen KMInstaller.cab kopieres over i denne mappen. Denne filen kan nå lastes ned fra denne mappen. En nedlastningslink presenteres til brukeres via webgrensesnittet samt en mulighet for å sende en SMS med nedlastningslink til et telefonnummer. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 101

102 6.4 KMDesigner.aspx Når denne siden lastes inn på en webleser startes en prosess for å klargjøre serveren for å opprette KMInstaller.cab filen. Alle endringer etter tidligere kjørte KioskMode designer prosesser må nullstilles. Dette gjøres ved å overskrive alle endrede filer med standard filene som skal brukes i KioskMode designeren. Foreksempel overskrives alle logoer som er blitt endret med standard logoer for KioskMode programmet. Kode eksempel: File.Delete(@"C:\KMDesignerFiles\KioskEngine\KioskEngine\images\logo1.jpg");... File.Delete(@"C:\KMDesignerFiles\KioskEngine\KioskEngine\images\logo8.jpg"); For å illustrere hvordan brukerens input i webgrensesnittet skrives til de respektive prosjektfilene Login.cs og MainForm.cs har vi laget et eksempel på hvordan KioskMode overskriften skrives til filen MainForm.cs: Utsnitt fra filen MainFormReplace.cs: private void Main_GotFocus(object sender, EventArgs e) { lblheader.text = "Kiosk Menu";... Som vi ser, tilegnes overskriften til KioskMode hovedmenyen via label kontroll som tilegnes teksten Kiosk Menu i Main_GotFocus funksjonen. Utsnitt fra filen KMDesigner.cs: string strmenuname = tbxheadername.text; ReplaceInFile1(@"C:\KMDesignerFiles\KioskEngine\KioskEngine\MainFormReplace.cs", "Kiosk Menu", strmenuname); StringreplaceInFile1 funksjonen åpner filen MainFormReplace.cs og overskriver Kiosk Menu teksten med input fra textboxen tbxheadername og lagrer dette som filen MainForm.cs. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 102

103 Use Case: Registrer generell info om KioskMode klient (KMDesigner.aspx) Aktør Bruker(Administrator). Prebetingelse 1. Bruker må være innlogget i Security Shield systemet. Trigger Bruker ønsker å opprette en KioskMode installasjonsfil. 1. Bruker fyller overskriften til KioskMode hovedmenyen. 2. Bruker fyller administrator koden for å åpne administrator panelet. 3. Bruker velger at Windows oppgavelinjemenyen skal benyttes. 4. Bruker velger at Security Shield splash screen skal vises ved oppstart av KioskMode klienten. 5. Bruker velger at pinkode panelet til mobilens simkort skal vises ved oppstart av Windows mobilen. 6. Bruker registrerer den første hardwareknappen som skal deaktiveres 7. Bruker registrerer den andre hardwareknappen som skal deaktiveres Postbetingelse Generell info om KioskMode klient er registrert. Variasjoner: 3a Bruker velger at Windows oppgavelinjemenyen ikke skal benyttes. 4a Bruker velger at Security Shield splash screen ikke skal vises ved oppstart av KioskMode klienten. 5a Bruker velger at pinkode panelet til mobilens simkort ikke skal vises ved oppstart av Windows mobilen. 6a Bruker ønsker ikke å deaktivere en hardware knapp og lar feltet stå tomt 7a Bruker ønsker ikke å deaktivere en hardware knapp og lar feltet stå tomt 6.5 KMDesigner1.aspx til KMDesigner8.aspx Disse åtte sidene fungerer i prinsippet på samme måte som KMDesigner.aspx siden ved at input fra brukeren skrives til MainForm.cs. I tillegg kan man laste opp ikonet til knappen som registreres. Når et ikon lastes opp overskriver dette ikonet standard ikonet som er lagret på serveren. Hvis brukeren foreksempel er på KMDesigner4.aspx siden og laster opp et ikon overskrives logo4.jpg som ligger på serveren med filen som lastes opp. Etter hver knapp som legges til kan man enten velge å fullføre ved å gå til Build.aspx eller man kan legge til en knapp til. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 103

104 Use Case: Registrer knapp (KMDesigner1.aspx KMDesigner8.aspx) Aktør Bruker(Administrator). Prebetingelse 1. Bruker må være innlogget i Security Shield systemet. 2. Steg 1 i KioskMode designeren (KMDesigner.aspx) må være fullført. Trigger Bruker ønsker å opprette en KioskMode installasjonsfil. 1. Bruker fyller inn knappens navn. 2. Bruker fyller inn filstien til applikasjonen som skal startes på Windows mobiltelefonen. 3. Bruker fyller inn parameterverdi til applikasjonen som skal startes. 4. Bruker laster opp knappens ikon. 5. Bruker trykker Finish for å gå til siste steg i KioskMode designeren (Build.aspx). Postbetingelse Informasjon om knapp er registrert. Variasjoner: 3a Applikasjonen krever ingen parameterverdi. Dermed fylles det ingen verdi her. 4a Bruker har ingen logo til knappen og laster ikke opp knappens logo. Dermed benyttes en standard logo. 5a Bruker trykker Next for å legge til en knapp til 5b Bruker trykker Cancel for å starte KioskMode designeren fra begynnelsen 6.6 Build.aspx Det eneste valget som presenteres brukeren på denne siden er knappen Build!. Denne knappen starter prosessen med å kompilere KioskEngine.sln ned til KioskEngine.exe. Kode eksempel som viser hvordan KioskEngine.sln kompileres ned til KioskEngine.exe: ProcessStartInfo psi = new ProcessStartInfo(); psi.filename = "C:\\WINDOWS\\Microsoft.NET\\Framework\\v3.5\\msbuild.exe"; psi.arguments = "C:\\KMDesignerFiles\\KioskEngine\\KioskEngine.sln /p:configuration=debug /p:platform=\"any CPU\""; psi.useshellexecute = false; psi.createnowindow = true; Process p = new Process(); p.startinfo = psi; p.start(); Deretter pakkes alle nødvendige filer inn I KMInstaller.cab ved hjelp av CabWiz.exe. CabWiz.exe leser ut informasjon om hvilke filer som skal pakkes inn i Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 104

105 KMInstaller.cab og hvilke registernøkler som skal skrives til registeret fra en informasjonsfil, KMInstaller.inf der nødvendige data er registrert. Under følger et utsnitt av KMInstaller.inf. Eksempelet under viser hvilke registernøklene som skrives til Windows Mobile registeret: [RegKeys] "HKCU","ControlPanel\Comm","AutoCnct","0x ","0" "HKLM","Security\Policies\Shell","NoAutoRun","0x ","1" "HKLM","Security\Policies\Shell","NoExternalExes","0x ","1" "HKLM","Security\Policies\Shell","NoRunDlg","0x ","1" "HKLM","Software\Microsoft\Bluetooth\BTHLINK","DLL","0x ","" "HKLM","Software\Microsoft\Color","BaseHue","0x ","160" "HKLM","Software\Microsoft\Shell\Keys\40C1","Flags","0x ","9" "HKLM","Software\Microsoft\Shell\Keys\40C2","Flags","0x ","9" "HKLM","Software\Microsoft\Shell\Keys\40C3","Flags","0x ","9" "HKLM","Software\Microsoft\Shell\Keys\40C4","Flags","0x ","9" "HKLM","Software\Microsoft\Shell\Keys\40C5","Flags","0x ","9" "HKLM","Software\Microsoft\Shell\Keys\40C6","Flags","0x ","9" "HKLM","Software\Microsoft\Shell\Keys\40C7","Flags","0x ","9" "HKLM","Software\Microsoft\Today","Enabled","0x ","1" "HKLM","init","Depend90","0x ","32","00","3C","00" "HKLM","init","Launch90","0x ","CFVersionCheck.exe" Etter at KMInstaller.cab er opprettet får brukeren opp valgene om filen skal lastes ned til datamaskinen via en http nedlastningslink eller om en nedlastningslink skal sendes til mobiltelefon via SMS. Use Case: Build (Build.aspx) Aktør Bruker(Administrator). Prebetingelse 1. Bruker må være innlogget i Security Shield systemet. 2. Steg 1 i KioskMode designeren (KMDesigner.aspx) må være fullført. 3. Steg 2 i KioskMode designeren (KMDesigner1.aspx KMDesigner8.aspx) må være fullført. Trigger Bruker ønsker å opprette en KioskMode installasjonsfil. 1. Bruker trykker Build!. 2. Bruker laster ned fil via http nedlastningslink. 3. Bruker sender nedlastningslink via SMS til spesifisert telefonnummer. Postbetingelse KMinstaller.cab er opprettet og klar til nedlastning. Variasjoner: 2a Bruker sender SMS istedenfor å laste ned via http nedlastningslink. 3a Bruker skriver ikke inn noe tlf og får melding om å spesifisere telefonnummer. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 105

106 6.7 Sending av SMS Alle SMS som sendes fra Security Shield web siden sendes via en SMS Gateway. Denne er plassert hos det Britiske firmaet Connection Software som tilbyr SMS tjenester. Dette medfører at SMS ikke bare kan sendes innenfor Norges landegrenser men også til utlandet. Logikken rundt dette er at alle nødvendige data for å kunne sende en SMS, sendes til Connection Software sin SMS Gateway i form av en SMS spørring. SMS gatewayen prosesserer informasjonen og genererer en SMS utifra dataene og sender SMS en ut til mottaker. Nødvendige data for å sende en SMS er mottakers telefonnummer med landskode, teksten som SMS en skal inneholde, hvilken SMS tjeneste som skal benyttes (Prisen per melding avhenger av dette) og brukernavn + PIN kode for vår konto hos Connection Software. I KioskMode designeren kan man skrive inn telefonnummer til mottaker manuelt via webgrensesnittet. Utdrag fra CSoftSMSGateway klassen Eksempelet under viser SMS spørringen for å sende en SMS. private static string Account = "Username=MGabriels.XXXXXX&PIN=XXXXXXXX"; private string phonenostring = "&SendTo="; private string pduid = "&SmsSubmitPduProtocolIdentifier=00"; private string usepremier = "&DeliveryServiceOption=Premier"; private string messagetextstring = "&Message="; public CSoftSMSGateway() { Gateways[0] = " Gateways[1] = "www2.csoft.co.uk/webservices/http/sendsms"; } public bool SendTextMessage(string phonenumber, string texttosend) { string decodedmsg = decodemessage(texttosend); //SMS spørring string query = Account + phonenostring + phonenumber.substring(1) + messagetextstring + decodedmsg + usepremier; return sendmessage(query); } Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 106

107 6.8 Sending av SMS til bruker Modellen under illustrerer hvordan en SMS sendes til bruker. 6.9 Sekvensdiagram for overføring av KioskMode installasjonsfilen via SMS Sekvensdiagrammet under viser hvordan mobilen mottar en SMS med nedlastningslink fra SMS Gateway og laster ned KioskMode installasjonsfilen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 107

108 6.10 Forklaring på sentrale funksjoner i KioskMode designeren Under følger en forklaring på de mest sentrale funksjonene i KMDesigner klassen: protected void Page_Load(object sender, EventArgs e) Denne funksjonen klargjør KMDesignerFiles mappen på serveren til å kunne opprette KMInstaller.cab installasjonsfilen. Alle endringer etter tidligere kjørte KioskMode designer prosesser må nullstilles. Dette gjøres ved å kopiere standard filer til KMDesignerFiles mappen. static public void ReplaceInFile1(string filepath, string searchtext, string replacetext) Denne funksjonen åpner en fil filepath og erstatter teksten searchtext i filen med replacetext. Til slutt lagres filen som er åpnet og redigert som MainForm.cs. static public void ReplaceInFile2(string filepath, string searchtext, string replacetext) Denne funksjonen åpner en fil filepath og erstatter teksten searchtext i filen med replacetext. Til slutt lagres filen som er åpnet og redigert som Login.cs. protected void btnnext_click(object sender, EventArgs e) Skriver all input fra brukeren til filene Login.cs og MainForm.cs. Åpner siden KMDesigner1.aspx. Under følger en forklaring på de mest sentrale funksjonene i KMDesigner1 KMDesigner8 klassene: private void WriteToFile() Denne funksjonen skriver all input fra brukeren til filen MainForm.cs. protected void btnnext_click(object sender, EventArgs e) Starter funksjonen WriteToFile() og åpner neste KMDesignerX.aspx. protected void btnfinish_click(object sender, EventArgs e) Starter funksjonen WriteToFile() og åpner Build.aspx. Under følger en forklaring på de mest sentrale funksjonene i Build klassen: protected void btnbuild_click(object sender, EventArgs e) Denne funksjonen kjører en build på KioskEngine.sln slik at KioskEngine.exe filen oprettes. Deretter pakkes alle nødvendige filer inn i KMInstaller.csb filen. Deretter oprettes det en unik mappe for den innloggede bedriften på serveren og KMInstaller.cab filen kopieres over i denne mappen. Deretter viser den en label på websiden som fungerer som nedlastningslink til den oprettede KMInstaller.cab filen. Til slutt gjøres et panel synlig, som gir brukeren muligheten til å sende ut SMS. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 108

109 protected void btnsendsms_click(object sender, EventArgs e) Denne funskjonen starter sending av SMS. Under følger en forklaring på de mest sentrale funksjonene i CSoftSMSGateway klassen: public bool SendTextMessage(string phonenumber, string texttosend) Tar telefonnummer og tekst som skal sendes i SMS en og returnerer en SMS spørring. private bool sendmessage(string query) Sender en forespøresel til SMS Gateway om å sende SMS. Returnerer true eller false. private string decodemessage(string msg) Gjør om alle tegn i teksten som skal sendes som i SMS en til tegn som er kompatible i en SMS. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 109

110 7. Oppbygging og virkemåte for KioskMode klient 7.1 Generelt KioskMode applikasjonen består av følgende elementer: Et skjermbilde med en hovedmeny som vises ved oppstart. Denne kan ikke lukkes eller minimeres. Start menyen er gjort utilgjengelig for brukeren Hardware knapper som gir tilgang til applikasjoner er deaktivert Bluetooth er deaktivert ActiveSync er deaktivert Autorun funksjonen fra SD-minnekort er deaktivert Kjør funksjonen på klokken er deaktivert Det er ikke mulig å kjøre.exe filer fra SD-minnekort All mulighet til å koble mobiltelefonen til andre enheter er stoppet 7.2 Fysisk oppdeling av applikasjon KioskMode applikasjonen er fysisk delt opp 3 deler: 1. Installasjonsfil (KMInstaller.cab) som skriver endringer til Windows mobile registeret og installerer alle nødvendige filer på mobilen. 2. Oppstartsfil (CFVersionCheck.exe) som sjekker om Compact Framework 3.5 er installert på mobil og starter KisokEngine.exe 3. Hovedmeny (KioskEngine.exe) som gir mulighet til å starte valgte applikasjoner. Denne deaktiverer start menyen og hardware knapper. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 110

111 7.3 Grensesnitt Under følger skjermbilder som brukeren forholder seg til når KioskMode applikasjonen kjører på klienten. Vi har satt fokus på å lage brukergrensesnittet så enkelt som mulig samtidig som det gir tilgang til nødvendig funksjonalitet. Installasjon av Kiosk programmet. Enheten restarter automatisk etter installasjon. Velkomstbilde der logoen fader inn. Vises når Kiosk programmet lastes inn ved opptart av mobiltelefonen. Hovedmenyen som presenteres gir mulighet til å starte valgte applikasjoner. Viser dato, klokkeslett og batteri status. Den blå linjen minker i takt med batteriet. Viser internet Explorer startet opp i Kioskmode. Start menyen er deaktivert. Trykker man på x knappen i høyre hjørne, returnerer man til Kiosk hovedmenyen. Login panelet kommer opp hvis man holder inne stylus pennen i over 10 sekunder på det svarte feltet i hovedmenyen. Administrator panelet gir mulighet til å aktivere eller deaktivere Bluetooth, ActiveSync og Autorun. Ved å trykke på Uninstall Kiosk knappen avinstalleres Kiosk programmet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 111

112 Bruker får melding om at endringene er utført. Avinstallasjon av KioskMode. 7.4 KioskMode hovedmenyen (KioskEngine.exe) Hovedmenyen konstrueres av klassen Main. Dette er KioskMode hovedmenyen som møter brukeren med en gang Windows Mobile telefonen starter opp. Dette skjermbildet kan ikke lukkes eller minimeres og ligger til grunn for KioskMode applikasjonens funksjonalitet. Hovedmenyen lar brukeren velge hvilken applikasjon som skal startes. Når den startede applikasjonen lukkes igjen, returnerer man tilbake til KioskMode hovedmenyen. Alle knappene i applikasjonen er sortert i en ListView kontroll. Disse knappene er laget relativt store slik at brukeren lettere skal kunne trykke på dem. Ikonene til knappene hentes ut fra.jpg bildefiler, som blir installert på Windows mobiltelefonen under installasjonen av KioskMode klienten. Hovedmenyen viser også dato, klokkeslett og batteristatus i sanntid. Disse elementene er nødvendige for bruk av klienten og er tatt med i KioskMode hovedmenyen fordi KioskMode applikasjonen sperrer for deres naturlige visning på Windows mobiltelefonen. For å hente ut denne informasjonen fra enheten har vi benyttet SystemState klassen som er en del av Compact Framework klassebiblioteket. For å oppnå at hovedmenyen ikke kan lukkes har vi satt følgende verdier i konstruksjonen av Main klassen: Setter FormBorderStyle til None Setter WindowState til Maximized (Denne funksjonene kan både aktiveres og deaktiveres i KioskMode designeren) Setter ControlBox til False Setter MinimizeBox til False Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 112

113 Kode eksempel på de overstående punkter: public Main() { InitializeComponent(); //Fjerner minimize knappen øverst i høyre hjørne this.controlbox = false; //Fjerner muligheten for å minimere skjermbildet this.formborderstyle = FormBorderStyle.None; this.maximizebox = false; this.minimizebox = false; Deaktivering av start menyen Start menyen i Windows Mobile er hovedmenyvalget i operativsystemet som lar brukeren velge hvilken applikasjon som skal startes. KioskMode applikasjonen vår har deaktivert denne på to forskjellige måter. Brukeren kan velge hvilken av fremgangmåtene som skal benyttes i KioskMode designeren Løsning 1 for å deaktivere start menyen I denne fremgangsmåten har vi deaktivert Windows oppgavelinjemenyen og laget vår egen. Dette ble gjort ved å kjøre Kiosk hovedmenyen i fullskjerm samtidig som vi fjerner oppgavelinjen. Dette gjøres i hovedmeny klassen Main. Følgende funksjoner er sentrale for å oppnå dette: Funksjonen under setter Hovedmenyen i fullskjerm modus: this.windowstate = FormWindowState.Maximized; Funksjonen under deaktiverer Windows oppgavemenylinjen: //Fjern oppgavelinje meny funksjoner [DllImport("coredll.dll")] private static extern IntPtr FindWindow(string lpclassname, string lpwindowname); [DllImport("coredll.dll")] private static extern IntPtr ShowWindow(IntPtr hwnd, int visible); Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 113

114 private void HideTaskbar() { //Finner oppgavelinjemenyen og fjerner visningen av denne ved å sette ShowWindow til 0 ShowWindow(FindWindow("HHTaskBar", null), 0); } Skjermbildene til venstre viser hvordan vår egen oppgavemenylinje ser ut på klienten. Når et annet program er åpnet kan man trykke på Click to reurn for å returnere til Kiosk hovedmenyen Løsning 2 for å deaktivere start menyen KioskMode hovedmenyen inneholder en timer som hvert femtiende millisekund sjekker om det er et nytt vindu som er i front på skjermen. Dersom det er et nytt vindu der brukes funksjonen GetForegroundWindow()for å hente ut vinduets handle og funksjonen SHFullScreen() for å fjerne start menyen. Eksempelet under illustrerer hvordan dette fungerer: //Hide start icon Pinvoke functions [DllImport("AYGShell.dll")] static extern Int32 SHFullScreen(IntPtr hwndrequester, UInt32 dwstate); public const UInt32 SHFS_HIDESTARTICON = 0x0020; [DllImport("coredll.dll", SetLastError = true)] public static extern IntPtr GetForegroundWindow(); //Hide Start Menu private void HideStartMenu() { IntPtr handle = GetForegroundWindow(); SHFullScreen(handle, SHFS_HIDESTARTICON); } Som en ekstra sikkerhet flyttes alt innholdet i \Windows\Start Menu\ mappen til Windows\Start Menu backup. Dette er gjort i tilfelle det skulle skje en programfeil eller lignende slik at Start menyen blir tilgjengelig for brukeren. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 114

115 Skjermbildene til venstre viser Windows oppgavemenylinjen der Start menyen er fjernet. Legg også merke til at muligheten for å lukke kiosk hovedmenyen er fjernet. 7.6 KioskMode administrator funksjonalitet Ved å holde inne "stylus" pennes på det svarte feltet i KioskMode hovedmenyen i over 10 sekunder får man opp en administrator login side. Tastes riktig passord får man opp et administratorpanel der man kan aktivere eller deaktivere Bluetooth, ActiveSync eller Autorun fra SD-minnekort. Dette gjøres ved å endre innstillinger i registeret ved hjelp av Registry.SetValue() funskjonen. Administratorpanelet gir også mulighet til å avinstallere KioskMode applikasjonen. 7.7 Applikasjonen starter automatisk ved oppstart Kiosk applikasjonen startes opp via registeret ved oppstart av Windows mobilen. Av sikkerhetsmessige årsaker må programmer som startes via registeret signeres med et gyldig sertifikat. Til dette har vi benyttet et Microsoft test sertifikat SamplePrivDev.pfx som følger med i Compact Framework SDK. Vi benyttet dette sertifikatet fremfor å lage vårt eget fordi Smartphones AS har et eget sertifikat som de kan benytte på deres applikasjoner. Følgende registernøkler sørger for at KioskMode starter opp ved oppstart: HKLM\Init\Launch90 = CFVersionCheck.exe og HKLM\Init\Depend90 = C 00 Disse skrives til registeret i KioskMode installasjonsfilen(kminstaller.cab). Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 115

116 7.8 Hardwareknapper som fungerer som snarvei til applikasjoner er låst ned Windows Mobile har som standard 6 snarvei hardwareknapper som kan tilegnes forskjellige funksjoner. Disse er gjerne snarveiknapper for å starte kamera, Internet, e-post etc. Disse deaktiveres via registeret på mobilen på følgende måte: HKLM\Software\Microsoft\Shell\Keys\40C1\Flags = 9 HKLM\Software\Microsoft\Shell\Keys\40C2\Flags = 9.. Dette gjentas på alle 6 knappene. Verdien 9 betyr at knappen ikke skal ha noen funksjon. Disse endringene skrives til registeret under installasjon av KioskMode programmet. Ved enkelte tilfeller er det ønskelig å låse enda flere hardwareknapper, som ikke kan deaktiveres via registeret. Vi har gitt brukeren mulighet til å velge disse knappene i KioskMode. Alle knapper på Windows Mobile baserte enheter har en heksadesimal verdi. KioskMode hovedmenyen KioskEngine.exe, deaktiverer disse knappene ved å fjerne knappenes opprinnelige funksjon og registrerer knappene til KioskMode hovedmenyen. Dette eksempelet viser funksjonen UnregisterHWKey() som deaktiverer Action og End knappene som henholdsvis har de heksadesimale verdiene 0x0D og 0x73. public MsgWindow msgw; //Funksjoner for å deaktivere hardware knapper [DllImport("coredll.dll")] protected static extern uint RegisterHotKey(IntPtr hwnd, int id, uint fsmodifiers, uint vk); [DllImport("coredll.dll")] protected static extern bool UnregisterFunc1(uint fsmodifiers, int id); public class MsgWindow : MessageWindow { protected override void WndProc(ref Message msg) { base.wndproc(ref msg); } } private void UnregisterHWKey() { msgw = new MsgWindow(); uint result; //Fjerner knappenes opprinnelige funksjon UnregisterFunc1(0, 0x0D); UnregisterFunc1(0, 0x73); //Registrerer knappen til vår KioskMode result = RegisterHotKey(msgW.Hwnd, 1, 0, 0x0D); result = RegisterHotKey(msgW.Hwnd, 1, 0, 0x73); } Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 116

117 7.9 Installasjonsfilen KMInstaller.cab Installasjonsfilen KMInstaller.cab utgjør en sentral del for å sette Windows mobilen inn i KioskMode. Det er denne filen som skriver endringene til registeret samt at den utfører flytting av \Widows\Start Menu til Windows\Start Menu backup mappen. Det finnes ingen måter å lage installasjonsinstruksjoner på i C#, så vi ble derfor nødt til å bruke c++. Ved endt installasjon restartes mobiltelefonen slik at register endringene blir registrert. Installasjonsfilen sørger også for at alle endringer som gjøres på mobiltelefonen under installasjon blir reversert når KioskMode avinstalleres. Følgende endringer skrives til registeret i installasjonsfilen: Bluetooth deaktiveres Bluetooth er en funksjon som gjør det mulig å koble sammen to enheter via en trådløs frekvens. For å hindre at brukeren kan overføre filer eller installere programmer via bluetooth må denne funksjonen deaktiveres. HKLM\Software\Microsoft\Bluetooth\BTHLINK\DLL = ActiveSync deaktiveres ActiveSync er muligheten for å koble Windows mobile klienten opp mot en datamaskin vi kabel. Denne funksjonen deaktiveres slik at ikke brukeren kan overføre filer eller installere programmer via datamaskinen. Dette gjøres ved å sette følgende nøkkel i registeret: HKCU\ControlPanel\Comm\AutoCnct = 0 Som ekstra sikkerhet har vi også deaktivert muligheten til å kunne fjernstyre enheten på noe som helst måte. Dette gjøres ved å deaktivere RAPI funksjonen på Windows mobile klienten via registeret: HKLM\Security\Policies\Policies\ = 0 Autorun fra SD-minnekortslot deaktiveres SD-minnekort har muligheten til å starte en autorun funksjon med en gang minnekortet settes inn i enheten. Dette kan brukes både til å starte applikasjoner samt å installere nye applikasjoner. For å deaktivere denne funksjonen må opprette følgende nøkkel i registeret: HKLM\Security\Policies\Shell\NoAutuRun = 1 Som en ekstra sikkerhet har vi også deaktivert muligheten til å kjøre.exe filer fra minnekort. Disse kan kjøres hvis brukeren navigerer seg frem til filen via filutforskeren. Dette gjøres ved følgende register nøkkel: HKLM\Security\Policies\Shell\NoExternalExes = 1 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 117

118 kjør funksjonen deaktiveres Ved å holde inne action knappen på klienten samtidig som man holder inne stylus pennen over klokken øverst i oppgavelinjemenyen får man frem en kjør funksjon lik den som finnes i Windows XP start menyen. Denne funksjonen gir brukeren muligheten til å skrive inn filstien til applikasjonen som skal startes. For å deaktivere denne funksjonen må man opprette følgende registernøkkel: HKLM\Security\Policies\Shell\NoRunDlg = 1 Basis fargene i Windows mobile operativsystemet endres til svart Vi har endret fargen på alle elementene i operativsystemet til svart, slik at fargene står i stil med Kiosk fargene. Dette gjøres ved å endre følgende verdi i registeret: HKLM\Software\Microsoft\Color\BaseHue = 160 C++ Funksjon for å restarte mobilen ved endt installasjon: #define IOCTL_HAL_REBOOT CTL_CODE(FILE_DEVICE_HAL, 15, METHOD_BUFFERED, FILE_ANY_ACCESS) extern "C" declspec(dllimport) BOOL KernelIoControl( DWORD dwiocontrolcode, LPVOID lpinbuf, DWORD ninbufsize, LPVOID lpoutbuf, DWORD noutbufsize, LPDWORD lpbytesreturned); BOOL ResetPocketPC() { return KernelIoControl(IOCTL_HAL_REBOOT, NULL, 0, NULL, 0, NULL); } //ResetPocketPC() startes i codeinstall_exit fuksjonen som startes ved endt innstallasjon av KioskMode. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 118

119 7.9.1 Modell av KMInstaller.cab Modellen under viser hvilke filer som installeres i de respektive mappene på klienten, samt hvilke endringer som gjøres i registeret på klienten ROM installasjon Det er nærliggende å anta at KioskMode ved enkelte tilfeller vil installeres fra ROM. ROM installasjon betyr at programmet installeres samtidig som operativsystemet installeres. I den sammenheng er det ikke ønskelig at enheten restarter etter installasjon. Derfor gjøres det en sjekk opp mot registeret etter nøkkelen: HKLM\Software\KioskMode\Reboot = 0 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 119

120 Dersom denne nøkkelen eksisterer restarter ikke enheten etter installasjon Oppstartsfilen CFVersionCheck.exe utfører en Compact Framework versjonskontroll KioskMode programmet benytter seg av Compact Framework V 3.5. I kravspesifikasjonen var det et krav at applikasjonen skulle kunne kjøres på Compact Framework versjon 2.0. Oppstartsfilen CFVersionVersionCheck.exe kjører derfor på CF versjon 2.0. Denne sjekker om CF 3.5 er installert på enheten, dersom CF 3.5 ikke er installert, installeres denne automatisk. Dersom CF 3.5 er installert startes KioskMode hovedmenyen (KioskEngine.exe) Grafikk og skalering For å unngå flimring har vi prøvd å unngå å bruke bilder for å lage grafikken. Dermed er mesteparten av elementene tegnet direkte på bakgrunnen. Dette gjøres i funksjonen: private void Main_Paint(object sender, PaintEventArgs e) KioskMode skalerer like bra til alle skjermoppløsninger og formater. Alle elementene i hovedmenyen måles ut fra hvor stor skjermen er og skalerer i henhold til dette. For å finne størrelsen på skjermen brukes ClientRectangle.GetWidt() og ClientRectangle.GetHeight() funksjonene. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 120

121 7.12 Språklig uavhengighet Kiosk applikasjonen fungerer uavhengig av hvilket språk som kjører på Windows mobilen. For å oppnå dette refereres det hele tiden til special folders, som finner eks. Program Files mappens navn på Windows mobilens aktuelle språk. I eksempelet under finner funksjonen StartKiosk() navnet på program files mappen i alle språk og starter deretter KioskEngine.exe som ligger i Program Files\KioskEngine\KioskEngine.exe : [DllImport("coredll.dll")] static extern int SHGetSpecialFolderPath(IntPtr hwndowner, StringBuilder lpszpath, int nfolder, int fcreate); const int CSIDL_PROGRAM_FILES = 0x0026; private string getpath(int foldercsidl) { StringBuilder resultpath = new StringBuilder(255); } SHGetSpecialFolderPath((IntPtr)0, resultpath, foldercsidl, 0); return resultpath.tostring() private void StartKiosk() { string progfilesfolder = getpath(csidl_program_files); Process.Start(progFilesFolder ""); } 7.13 Sentrale funksjoner i KioskMode applikasjonen private void Populatelist() Denne funksjonen lager knappene i hovedmenyen og henter ut knappenes ikon fra.jpg bildefiler. private void ItemClick() Denne funksjonen definerer hvilken applikasjon som skal startes når en knapp blir aktivert. void startmenu_tick(object sender, EventArgs e) Dette er en timer-funksjon som hvert femtiende millisekund sjekker om en ny applikasjon er aktiv. Dersom dette er tilfellet fjernes start menyen i den aktive applikasjonen. private void BatteryFunction() Denne leser ut batteriets status og styrke. Ut fra disse verdiene endres skjermbildet i hovedmenyen. void PowerBatteryStrength_Changed(object sender, ChangeEventArgs args) og void PowerBatteryState_Changed(object sender, ChangeEventArgs args) Disse to funksjonene sjekker hele tiden om det skjer noen endringer ved batteriets status og styrke. Endringer kan være at batteriet blir satt til ladning eller at batterilevetiden minker. Dersom det skjer en endring startes BatteryFunction(). Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 121

122 void Date_Changed(object sender, ChangeEventArgs args) og void Clock_Changed(object sender, ChangeEventArgs args) Disse to funksjonene sjekker hele tiden om det skjer noen endringer ved dato og klokkeslettet. Dersom det skjer en endring oppdateres hovedmenyen med de nye verdiene. codeinstall_exit Install_Exit( ) Denne c++ funskjonen kjøres etter at KioskMode installasjonen er fullført. Denne flytter innholdet i \Windows\Start Menu over til den midlertidige mappen \Windows\Start Menu backup. Den sjekker også etter registernøkkelen HKLM\Software\KioskMode\Reboot = 0. Dersom nøkkelen ikke eksisterer restartes Windows mobiltelefonen automatisk. codeuninstall_exit Uninstall_Exit(HWND hwndparent) Denne c++ funskjonen kjøres etter at KioskMode avstallasjonen er fullført. Denne flytter innholdet i \Windows\Start Menu backup tilbake til \Windows\Start Menu slik at startmenyen gjenoprettes til opprinnelig tilstand. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 122

123 Sentrale klasser i Kiosk applikasjonen Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 123

124 7.14 Beskrivelse av sentrale klasser Navn Main Login AdminForm CFVersionCheck Program CumstomBorder Egenskap Dette er hovedmeny klassen. Starter applikasjoner, viser dato/klokkelsett/batteri, deaktiverer start meny, deaktiverer hardware knapper og starter Loginpanel. Login klassen sjekker passord og åpner administrator panelet. Aktiverer/deaktiverer funksjoner i registeret. Åpner for avinstallasjon av KioskMode. Oppstarts skjermbilde (splash screen). Viser et velkomstbilde der Security Shield logoen fader inn. Sjekker om Compact Framework versjon 3.5 er installert. Starter KioskEngine.exe eller installasjon av CF versjon 3.5. Oppstarts fil i konsoll versjon. Kjører i bakgrunnen og sjekker om Compact Framework versjon 3.5 er installert. Starter KioskEngine.exe eller installasjon av CF versjon 3.5. En av flere grafikk klasser. Lager runde kanter på listview objektet i Main klassen. Er tatt med som et eksempel på flere grafikk klasser som brukes KioskMode applikasjonen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 124

125 8. Sikkerhet 8.1 Generelt Sikkerheten av systemet er viktig da dette skal brukes av mange brukere. Derfor spiller sikkerheten rundt teknologien vi har valgt å bruke i dette prosjektet en viktig rolle. Vi mener i så måte at den generelle sikkerheten er godt ivaretatt gjennom det rammeverk og den teknologien vi benytter i prosjektet. 8.2 Sikkerhet i forhold til brukere av systemet Når det gjelder sikkerheten i forhold til utviklingen av programmet er det tatt hensyn til sikkerheten ovenfor brukerne. Dette går spesielt på hvilken sensitiv informasjon som sendes gjennom et nettverk. Sikkerhet for brukere ligger også i vårt administrator system på websiden. All informasjon om brukere ligger sikkert lagret i en database som kun administratorer av systemet har tilgang til. 8.3 Sikkerhet i forhold til testing Sikkerheten av programmet er blitt grundig testet i en egen testrapport. Her har vi testet selve alle programdelene og avgjort om de enkelte delene er forsvarlige å ta i bruk. 8.4 Teknisk implementering Overføring av data mellom server og klient er ivaretatt på best mulig måte. Når det gjelder kommunikasjon mellom server og klient skjer dette via http protokollen. Dette medfører at det er mulig å kunne se http pakkene i klartekst dersom man benytter seg av pakke-sniffings verktøy. Dette er ikke noe problem i vårt system dersom det aldri sendes noe sensitiv informasjon. For å autentisere mobilen opp mot server benyttes mobilens unike hash-kode istedenfor IMEI. Det medfører ingen sikkerhetsrisiko ovenfor brukeres dersom denne skulle komme på avveie. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 125

126 9. Samsvar mellom kravspesifikasjon og produkt Da utformingen av dette hovedprosjektet begynte, var utgangspunktet kravene som var satt i kravspesifikasjonen. Vi har derfor prøvd å holde oss innenfor kravspesifikasjonens rammer. Kravspesifikasjonen var utformet på en slik måte at, enkelte deler inneholdt faste krav som måtte overholdes, mens andre deler var mer åpent formulert slik at vi selv kunne velge hvordan dette skulle implementeres. Når det gjelder krav som var satt til selve funksjonaliteten til produktet var det satt ganske klare rammer. Dette fordi det var et ønske fra oppdragsgiver at vi først og fremst konsentrerte oss om den viktigste funksjonaliteten. Det var også klart helt fra begynnelsen av hovedprosjektet at enkelte deler av funksjonaliteten ville ta lengre tid å implementere enn andre. Dette medførte at disse fikk høyeste prioritet. Når det gjelder utformingen av brukergrensesnittet var denne relativt fritt formulert, noe som medførte at vi hadde ganske fritt spillerom rundt denne delen. Kravspesifikasjonen ble revidert på bakgrunn av at endringer av produktets funksjonalitet er blitt gjort underveis i prosjektgjennomføringen. Gjennomføringen av produktet føler vi dermed samsvarer med det som er satt i den endelige kravspesifikasjonen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 126

127 10. Fremtidige utvidelser Under selve implementeringen av oppgaven har vi funnet flere mulige løsninger vi kunne tenke oss å implementere i denne oppgaven. Vi har underveis funnet flere ideer til utvidelser av produktet som er utviklet. Tiden strakk dessverre ikke til og vi ble derfor nødt til å utelate denne funksjonaliteten fra produktet. Vi hadde en fremtidig utvidelse til produktet i kravspesifikasjonen. Denne ble det heller ikke tid til å utvikle. Derfor har vi beskrevet alle fremtidige utvidelser av produktet her Enhached settings I tillegg til sperrefunksjonaliteten er det mange fine ting man kan gjøre i Registry - f.eks skru på analog klokke i meny, skru av SSL checkbox i konfigurasjon av server for ActiveSync, Close button i boble for datakobling ikon øverst i skjermbildet++ Dette kan legges inn under Enhanched settings Sikkerhetsutvidelser i KioskMode applikasjonen Vi mener selv at sikkerheten rundt KioskMode applikasjon er meget god og har under prosjektets gang ikke funnet noen mulighet for å kunne bryte ut av KioskMode applikasjonen slik at vi har fått tilgang til applikasjoner som ikke skulle være tilgjengelige. Allikevel kan man ikke være 100% sikker på at ikke brukeren på en eller annen måte kan bryte ut av KioskMode programmet. Vi har derfor to forslag til hvordan sikkerheten til KioskMode applikasjonen kan bli enda bedre: Svarteliste applikasjoner Denne løsningen går ut på å svarteliste alle programmene som ikke skal være tilgjengelige fra KioskMode applikasjonens hovedmeny. I utgangspunktet har brukeren ingen mulighet til å nå disse programmene, men det kan allikevel være lurt å ta med dette som en ekstra sikkerhet. Applikasjoner kan svartelistes via registeret. For å gjøre dette mulig må følgende registernøkkel opprettes: Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 127

128 HKLM\Security\Policies\Shell\DisallowRun = 1 Deretter må programmene svartelistes hver for seg. Som et eksempel har vi laget en nøkkel som sperrer for at prosessen clock.exe kan startes: [HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explore r\disallowrun\1=clock.exe Fjerne alle andre sertifikater enn vårt eget Denne løsningen går ut på å inndra alle andre sikkerhets-sertifikater på mobilen enn vårt eget. Dette medfører at alle applikasjoner som skal startes må være signert med vårt sertifikat Utsendelse av nedlastningslink via SMS til alle brukerne i et firma Det kan i fremtiden være ønskelig å kunne sende SMS med KioskMode nedlastningslink til alle brukerne i det innloggede firmaet Utvidelser i Configuration Manager Slik Configuration fremstår nå, er den veldig strippet for funksjoner. Den har kun ett formål. Det neste burde være å utvide muligheten for å bygge XML filer på server, samtidig som man videreutvikler klienten. Klienten bør kjøres som en service i bakgrunnen på mobilen. Der kan den automatisk sjekke med server om det har vært gjort endringer i sin profil. Ved endringer laster den automatisk ned XML filen og provisjonerer mobilen. Windows Mobile og klassen Microsoft.WindowsMobile.Configuration.ConfigurationManager, gjør det mulig å konfigurere nesten alt av innstillinger på telefonen. Det største hinderet for å få til dette nå, er muligheten for å lage sine egne XML filer på serveren. Det finnes lite informasjon om hvordan man skal sette sammen disse XML filene. Hvis man da samler så mye data som mulig om temaet. Og lager en applikasjon som kan generisk bygge XML filer, vil man ha et stort fortrinn. I 3. eller 4. kvartal i år vil Windows Mobile 7 mest sannsynlig bli lansert. Om Microsoft vil åpne mulighetene enda mer er ikke sikkert. Men den nye profilen til Microsoft konsernet har vært mye åpnere en tidligere. Å videre utvikle klienten for WM 7 er en viktig utvidelse. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 128

129 11. Vedlegg 11.1 Kildekode Se vedlagte CD 11.2 Dokumentasjon av kildekode Se vedlagte CD Databasefiler Se vedlagte CD 11.4 KioskMode/KioskMode designer veiledningsvideo Se vedlagt CD, eller se videoen på følgende webside: Fungerende XML provisjonering scripts Vi har lagt ved alle fungerende XML provisjonerings scripts. Godkjente telefoner til disse XML scriptene er dokumentert i testrapporten Deaktiverer Bluetooth (i-mate Jamin, i-mate qtek s200, HTC TyTn, HTC TyTn2, HTC P6300, HTC Touch P3050, HTC Touch Dual, HTC Touch Cruise og HTC 4350) <wap-provisioningdoc> <characteristic type="registry"> <characteristic type="hklm\software\microsoft\bluetooth\bthlink"> <parm name="dll" value="" datatype="string"/> </characteristic> </characteristic> </wap-provisioningdoc> Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 129

130 Deaktiverer kamera (HTC TyTn2, HTC Touch P3050, HTC Touch Dual, HTC 4350 og HTC Touch Cruise) <wap-provisioningdoc> <characteristic type="registry"> <characteristic type="hklm\software\htc\camera\common"> <parm name="rcdll" value="" datatype="string"/> </characteristic> </characteristic> </wap-provisioningdoc> Deaktiverer Wi-Fi (HTC TyTn2, HTC Touch P3050) <wap-provisioningdoc> <characteristic type="registry"> <characteristic type="hklm\comm\tnetw1251\linkage"> <parm name="route" value="" datatype="string"/> </characteristic> </characteristic> <characteristic type="registry"> <characteristic type="hklm\comm\tnetw12511"> <parm name="wireless" value="0" datatype="integer"/> </characteristic> </characteristic> </wap-provisioningdoc> Deaktiverer Wi-Fi (HTC Touch Cruise og HTC P6300) <wap-provisioningdoc> <characteristic type="registry"> <characteristic type="hklm\comm\tnetw1251\linkage"> <parm name="route" value="" datatype="string"/> </characteristic> </characteristic> <characteristic type="registry"> <characteristic type="hklm\comm\tnetwln1"> <parm name="wireless" value="0" datatype="integer"/> </characteristic> </characteristic> </wap-provisioningdoc> Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 130

131 Deaktiverer Activesync (HTC TyTn2, HTC Touch P3050, HTC Touch Dual, HTC 4350 og HTC Touch Cruise) <wap-provisioningdoc> <characteristic type="registry"> <characteristic type="hkcu\controlpanel\comm"> <parm name="autocnct" value="0" datatype="integer"/> </characteristic> </characteristic> </wap-provisioningdoc> Deaktiverer Autorun (HTC TyTn2, HTC Touch P3050, HTC Touch Dual, HTC 4350 og HTC Touch Cruise) <wap-provisioningdoc> <characteristic type="registry"> <characteristic type=" HKLM\Security\Policies\Shell"> <parm name=" NoAutuRun " value="1" datatype="integer"/> </characteristic> </characteristic> </wap-provisioningdoc> Deaktiverer kjøring av.exe-filer fra minnekort (HTC TyTn2, HTC Touch P3050, HTC Touch Dual, HTC 4350 og HTC Touch Cruise) <wap-provisioningdoc> <characteristic type="registry"> <characteristic type=" HKLM\Security\Policies\Shell"> <parm name=" NoExternalExes " value="1" datatype="integer"/> </characteristic> </characteristic> </wap-provisioningdoc> Deaktiverer USB-tilkobling (RAPI) (HTC TyTn2, HTC Touch P3050, HTC Touch Dual, HTC 4350 og HTC Touch Cruise) <wap-provisioningdoc> <characteristic type="registry"> <characteristic type=" HKLM\Security\Policies\Policies "> <parm name= value="0" datatype="integer"/> </characteristic> </characteristic> </wap-provisioningdoc> Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 131

132 Deaktiverer 3G (HTC TyTn2 og HTC Touch Dual) <wap-provisioningdoc> <characteristic type="registry"> <nocharacteristic type="hklm\software\oem\phonesetting\networktype" /> </characteristic> <characteristic type="registry"> <characteristic type="hklm\software\oem\phonesetting\networktype"> <parm name="itemcount" value="1" datatype="integer"/> </characteristic> <characteristic type="hklm\software\oem\phonesetting\networktype"> <parm name="itemname1" value="gsm" datatype="string"/> </characteristic> <characteristic type="hklm\software\oem\phonesetting\networktype"> <parm name="itemvalue1" value="1" datatype="integer"/> </characteristic> </characteristic> <characteristic type="registry"> <characteristic type="hklm\software\oem\umts"> <parm name="opmode" value="1" datatype="integer"/> </characteristic> </characteristic> </wap-provisioningdoc> Deaktiverer GPRS (HTC TyTn 2 og HTC Touch Dual) <wap-provisioningdoc> <characteristic type="registry"> <nocharacteristic type="hklm\software\oem\phonesetting\networktype" /> </characteristic> <characteristic type="registry"> <characteristic type="hklm\software\oem\phonesetting\networktype"> <parm name="itemcount" value="1" datatype="integer"/> </characteristic> <characteristic type="hklm\software\oem\phonesetting\networktype"> <parm name="itemname1" value="gsm" datatype="string"/> </characteristic> <characteristic type="hklm\software\oem\phonesetting\networktype"> <parm name="itemvalue1" value="1" datatype="integer"/> </characteristic> </characteristic> <characteristic type="registry"> <characteristic type="hklm\software\oem\umts"> <parm name="opmode" value="1" datatype="integer"/> </characteristic> </characteristic> </wap-provisioningdoc> Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 132

133 S E CURI TYS HI E L D TE S TRAPPORT

134 Side 132

135 Forord I dette dokumentet vil vi gjennomgå testfasen og hvilke resultater testingen resulterte i. Testingen av systemet er delt inn i to deler. Den ene delen omhandler testing av xml provisjoneringsscript på forskjellig mobiltelefoner. Den andre delen er testing av selve sluttproduktet. Delene er beskrevet under. Testrapporten er et dokument som er beregnet på utviklerne. Dette for å dokumentere hva som fungerer og er godkjent, og for å vise hvilke feil vi har funnet og utfordringer vi har hatt underveis. Side 133

136 Side 134

137 Innholdsfortegnelse 1. Test av XML provisjonerings script Hensikt og mål Testmiljø Mobiltelefon PC Test av produkt Hensikt og mål Testmiljø Klientsiden Serversiden Webgrensesnitt Testgruppe Test caser Testing av kjerneteknologi KioskMode klient KioskMode designer Configuration manager Grensesnitt WEB Konklusjon Side 135

138 1. Test av XML provisjonerings script 1.1. Hensikt og mål Målet med testingen av XML-scriptene på de forskjellige telefonene har vært å få låst ned funksjoner og applikasjoner, slik at disse ikke kan kjøres av brukeren. Kartleggingen gikk ut på å teste hvilke script som ville fungere på de ulike modellene. Videre hadde vi som mål at de funksjonene som er beskrevet i kravspesifikasjonen, skulle fungere på flest mulig modeller med WM 6 installert. Testene vi har gjort i denne rapporten har vært gjennomført en rekke ganger på forskjellige telefoner med både Windows Mobile 5 og 6 installert. Målet ble noe endret underveis, da vi valgte å holde fokus på modeller med WM Testmiljø Før vi begynte å teste XML-scriptene opp mot telefonene var det nødvendig med noen verktøy for at vi kunne gjennomføre testingen. Under testingen har vi brukt både pc og en mobiltelefon. Under er det beskrevet hvilke verktøy som vi trengte på hver av de to enhetene for å kunne teste Mobiltelefon Windows Mobile 5 eller 6 installert.net Compact Framework 2.0 og 3.5 Remote Registry Editor PC Remote Registry Editor ActiveSync.NET Framework 2.0 og 3.5 Side 136

139 Under vises en oversikt over de funksjonene som har blitt testet og godkjent på de forskjellige telefonene. Deaktiver Bluetooth Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Deaktiver Kamera Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Avvik Avvik Avvik Avvik Avvik Deaktiver Wi-Fi Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Avvik Avvik Ikke tilgjeng elig Deaktiver Autorun Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Side 137

140 Deaktiver USB-tilkobling (RAPI) Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Deaktiver kjøring av.exe filer fra minnekort Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Deaktiver Klokke Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Deaktiver 3G Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Avvik Avvik Avvik Avvik Avvik Avvik Avvik Avvik Side 138

141 Deaktiver Activesync Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Deaktiver GPRS Telefon: HTC TyTN2 i-mate Qtek s200 HTC TyTN i-mate Ultimate 8150 i-mate Jamin HTC P4350 HTC Touch Dual HTC Touch P3050 HTC Touch Cruise HTC P6300 Status Avvik Avvik Avvik Avvik Avvik Avvik Avvik Avvik Side 139

142 2. Test av sluttprodukt 2.1. Hensikt og mål Vi har gjennom hele prosjektperioden jevnlig gjennomført tester på de forskjellige elementene i produktet vårt. Dette ble gjort for å kunne kvalitetssikre vårt produkt på best mulig måte. Gjennomføring av gjentatte, små enhetstester fra start til slutt har vært en god fremgangsmåte for å fjerne feil og finne begrensinger. Testene som senere beskrives i dette dokumentet ble gjennomført på forskjellige tidspunkt i prosjektperioden og enkelte deler har blitt testet flere ganger. Feil som ble funnet i denne testen er feil som ble funnet i siste liten og ble derfor ikke rettet Testmiljø Denne avsluttende testen er blitt kjørt på Windows Mobile telefonene som vi har hatt til rådighet prosjektperioden. Vi kan derfor ikke garantere at alle testene ville hatt samme resultat på andre enheter Klientsiden En mobil enhet som kjører Windows Mobile 6.0 med Compact Framework 3.5 installert. Enheten er av typen PDA. Tilknyttet internett via enten Activesync, WLAN eller mobilt nettverk (GPRS/3G) Serversiden Maskinen kjører Windows Server 2003 med IIS 6.0 installert. Støtte for ASP.NET gjennom.net Framework 3.5. Side 140

143 Databasen er en MSSQL database som kjører på samme server Webgrensesnitt Klient programmet som skal kjøre webgrensesnittet kan i teorien kjøre et hvilket som helst operativsystem. Vi har testet webgrensesnittet manuelt i følgende nettlesere: Mozilla Firefox , Internet Explorer 8, Internet Explorer 7 og Safari 4. Det er gjennomført automatisk test av kompabilitet gjennom som er et nettsted for å teste websider i forskjellige weblesere. I følge denne testen er websiden vår kompatibel med følgende nettlesere: Internet Explorer 8, 7, 6 og 5.5 Mozilla Firefox 3.5, 3.1, 3.0 og 1.5 Opera 10, 9.64 og 8.54 Safari 4.0 og 3.2 Minefield Testgruppe Testingen er hovedsaklig utført av gruppemedlemmene. Dette fordi noen av testene har vært av en såpass teknisk karakter, at vi ikke kunne benytte eksterne personer. Testingen av grensesnitt, i slutten av dette dokumentet er utført av utført av eksterne personer. Målet med å bruke eksterne testpersoner var å kunne avduke feil eller elementer med dårlig brukervennlighet. Som programmerer er det lett å se seg blind på sitt eget produkt ettersom man har laget detaljene selv. Derfor er det nødvendig at grensesnittet testes av eksterne personer. Side 141

144 3. Test Caser Tester som er utført med forventet resultat markeres med i feltet status. Dersom det oppdages avvik markeres status feltet med Avvik og en kommentar på dette feltet følger under tabellen Testing av kjerneteknologi I kjerneteknologi testen, testes systemverdier direkte mens system kjører. Disse testene går på deler av systemet som ikke er synlig for brukeren KioskMode klient Testene omfatter de forskjellige elementene KioskMode applikasjonen består av. Installasjon av klient, nedlåsing av hardware knapper, register endringer og deaktivering av start menyen. Disse testene er utført på følgende mobiltelefoner: HTC TYTN 2 og HTC Diamond. Handling Forventet resultat Status Installering av KioskMode. Alle filer skal installeres til de respektive mapper på enheten. Automatisk restart av klient etter Klient restarter automatisk ved endt installasjon installasjon ROM installasjon Klient restarter ikke etter installasjon dersom nøkkelen HKLM\Software\KioskMode eksisterer Registerverdier endres Bluetooth, Autorun, ActiveSync og hardware knapper skal være deaktivert Start tredjeparts applikasjon Applikasjon startes. Eksempel: Process.Start( iexplore.exe, vg.no ); Batteri status endres Når batteriets levetid minker endres Side 142

145 Eksempel: PowerBatteryStrength_Changed PowerBatteryState_Changed Dato endres Date_Changed Klokke Eksempel: Clock_Changed Åpne loginpanel ved å holde inne stylus penn i 10 sekunder Innlogging Uthenting av registerverdier i administrator panelet. Eksempel: Registry.Getvalue( Register nøkkel..); Skriv til register via administrator panelet Avinstallasjon Battery: teksten i KioskMode hovedmenyen til Very High, High, Medium, Low eller Very low. Dersom den settes til ladning vises teksten Charging. Dette skal skje i sanntid. Date teksten i KioskMode hovedmenyen oppdateres når datoen endres på klien Klokken i KioskMode hovedmenyen oppdateres automatisk. Loginpanelet skal komme opp Administrator panelet åpnes dersom det tastes riktig kode. Register verdier returneres. Checkboxer oppdateres etter registerets status Bluetooth, Autorun og ActiveSync aktiveres/deaktiveres Alle rester av KioskMode klient fjernes og Klient fungerer som før installasjon av KioskMode Side 143

146 3.3. KioskMode designer Testen omfatter de forskjellige elementene KioskMode designeren består av. Oppretting av installasjonsfil, sending av SMS og nedlastning av installasjonsfil. Handling Forventet resultat Status Klargjøring av KMDesignerFiles Alle filer skal gjøres klare til mappen gjennomkjøring av KM designer. Bruker input skrives til prosjektfiler Input som skrives inn i via Eksempel: StringReplace1(...); webgrensesnitt skal skrives til prosjektfiler Opplasting av Ikon filer Filer skal lastes opp på server og overskrive standard ikon filer. FileUpload Oppkobling mot database Tilkobling til database opprettes ConnectionString Uthenting av innlogget firma Build på KioskEngine prosjektet MSBuild.exe Oppretting av installasjonsfilen KMInstaller.cab. CabWiz.exe HTTP nedlastingslink Utsendelse av SMS til spesifisert mobilnummer Utsending av SMS til alle brukere registrert på firmaet Sql spørring opp mot databasen. Innlogget firma og dets brukere returneres Det kjøres en build på KisokEngine.sln. Resultatet blir den kjørbare filen KioskEnine.exe. Installasjonsfilen opprettes ved hjelp av cabwiz.exe. Resultatet blir installasjonsfilen KMInstaller.cab HTTP nedlastningslink opprettes og vises i webgrensesnitt. En SMS melding sendes til bruker. Tlf nummer til mottaker spesifiseres via web grensesnitt. SMS sendes til alle brukerne på firmaet FEIL Det ble ikke tid til å fullføre implementering av SMS utsendelse til alle brukere i firmaet. Side 144

147 3.4. Configuration manager Testen omfatter de forskjellige elementene ved provisjonering av Windows mobiltelefon. Handling Forventet resultat Status Uthenting av mobilens unike ID En unik hash kode hentes ut av mobilen. Autentisering mot web-service Mobilens unike ID brukes til å kontakte webservice og autentisere. Webservice sjekker etter ventende Webservice kobler opp mot jobb til mobil databasen og sjekker om det er noen ventende jobber til mobilen Hent XML provisjonerings script til Mobilen laster ned XML mobil provisjonerings script Jobb utført Webservice skriver til databasen at jobb er utført XML provisjonerings script parses på XML script kjøres av mobil. Configuration Manager klient Skriv til register Endringene skrives til Windows mobile registeret 3.5. Grensesnitt WEB Denne testen er utført av to eksterne testpersoner. Brukeren blir bedt om å navigere seg frem til de forskjellige elementene i web grensesnittet. Innlogging, registrering av nye brukere og registrering av mobil provisjonering. Handling Forventet resultat Status Gå til nettsted for første gang Bruker blir presentert en velkomstskjerm hvor man må logge inn med brukernavn og passord Prøver å logge inn med feil passord Får beskjed om at enten brukernavn eller passord er feil Prøver å logge inn med riktig Brukeren logger inn og får opp Side 145

148 brukernavn og passord Glemt passord Tilsending av nytt generert passord til registrert e-post for bruker. Security Shield hovedsiden Innloggingssiden har link til skjema for å generere nytt passord Bruker får tilsendt nytt passord fra server til sin registrerte e-post adresse FEIL Tilsending av nytt passord per e-post ble ikke ferdig implementert. Side 146

149 4. Konklusjon Testingen av vårt produkt har foregått fortløpende gjennom hele prosjektperioden og har vært nødvendig for å kunne kvalitetssikre vårt sluttprodukt. Denne testingen har hovedsaklig vært gjennomført av medlemmene i hovedprosjekt gruppen. Testing av grensesnittet på web ble gjennomført av to eksterne testpersoner som fikk i oppgave å navigere seg frem gjennom web grensesnittet. Dette var nyttig for å kunne avdekke svakheter og feil i grensesnittet. Testingen av XML provisjonerings scriptene var meget tidkrevende men var nødvendig for å få et helhetlig og fungerende system. Resultatet av denne testingen vil også være til stor hjelp for oppdragsgiver i deres arbeid. Vi vil si at testingen har vært vellykket i den grad at vi har avdekket feil og svakheter i systemet og at vi har fått testet scenarioer vi ikke tok høyde for under programmeringen. Den siste fullstendige testen ble utført uten feil eller problemer og det rapporteres derfor ikke om noen problemer i dette dokumentet. Side 147

150

151 S E CURI TYS HI E L D BRUKE RVE I L E DNI NG

152 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side148

153 Forord Denne brukerveiledningen henvender seg til sensor, veileder og brukere av programmet. Dokumentet er ment som et hjelpemiddel til de som skal sette seg inn i og bruke programmet. Produktet som skal veiledes består av to deler. Den ene delen består av Kiosk klient programmet som låser ned den mobile enheten slik at kun de ønskelige funksjoner kan benyttes. Den andre delen består av et webgrensesnitt der bruker kan opprette sitt eget Kiosk program, med ønsket funksjonalitet. Det vil i dokumentet bli lagt vekt på en enkel gjennomgang av programmenes funksjonalitet og enkel veiledning for bruk av disse. Leseren av dette dokumentet trenger ingen inngående datakunnskaper, men det forutsettes at brukeren har en viss kjennskap til Microsoft sitt operativsystem. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side149

154 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side150

155 Innholdsfortegnelse 1. Veiledning for KioskMode designer KioskMode designer Forklaring av de forskjellige feltene i steg Kiosk menu name Enable Security Shield splash screen Enter SIM, PIN Disable hardware keys Programmer Button text Program path Program parameter Upload button icon Cancel, Next og Finish Build Nedlasting fra server Send nedlastingslink via SMS Installasjon av KioskMode klient Forberedelser før installasjon av klient programmer Installasjon av Compact Framework Installasjon av Certs.cab Overføring av KMInstaller.cab via ActiveSync/Mobile device center Installasjon av klient programmet Installasjon av KioskMode via nedlastningslink på SMS Installasjon av KioskMode via mobilens filutforsker Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side151

156 6. Veiledning for KioskMode klient Hovedmenyen Navigering med Windows oppgavelinjemenyen deaktivert Navigering med Windows oppgavelinjemenyen aktivert Administrator- funksjonalitet Åpne loginpanelet Loginpanelet Administratorpanelet Aktiver/deaktiver funksjoner Avinstallere KioskMode Brukerveiledning configuration manager Før du logger inn Tilganger og roller Meny Brukere XML Kunder Instruksjon i klient Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side152

157 1. Veiledning for Kioskmode Designer Vi har laget en brukerveiledning for KioskMode designer og Kioskmode klient i video format. Denne er følger med i den vedlagte CD en samt at den kan ses på følgende webside: Denne delen av brukerveiledningen for seg de ulike skjermbildene og forklaring av disse i KioskMode designer-delen av programmet. Dette er et webgrensesnitt som alle brukere av løsningen har tilgang til. Per dags dato er den tilgjengelig her: KMDesigner/KMDesigner.aspx. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side153

158 2. KioskMode designer Etter at brukeren har logget inn og trykket på KioskMode designerlinken kommer KioskMode designer hovedsiden opp. Dette er det første steget i en designer Wizard på maksimalt ti steg. Denne designeren lar brukeren velge hvilken funksjonalitet KioskMode programmet skal bestå av. Figur 1.1 Steg Forklaring av de forskjellige feltene i steg Kiosk menu name I dette feltet fylles ønsket overskrift på Kiosk programmets hovedmeny inn. Dersom man ikke ønsker noen overskrift kan dette feltet stå tomt. Figur Navn på KioskMode menyen Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side154

159 Device unlock code I dette feltet spesifiseres administrator koden som må skrives inn for å få tilgang til Kiosk administrator panelet. Det anbefales på det sterkeste at man spesifiserer en administrator kode, men dersom det måtte være ønskelig kan også dette feltet stå blankt. Koden kan bestå av tall og bokstaver, men tall anbefales. Figur Administrator kode Enable Windows taskbar Her skal man velge om man ønsker å bruke den tradisjonelle Windows Mobile oppgavelinjemenyen, eller om man ønsker å benytte seg av KioskMode sin egen oppgavelinjemeny. Windows Mobile oppgavelinjemenyen gir tilgang til noen funksjoner som lydstyrke, nettverkstilkoblinger og signalstyrke. Dersom man ønsker å sperre for disse funksjonene bør man ikke bruke KioskMode oppgavelinjemenyen. Figur Aktiver/deaktiver Windows oppgavemenylinjen Enable Security Shield splash screen Betegnelsen splash screen er definert ved et bilde som vises når programmet lastes inn. Dersom brukeren ønsker å se et velkomstbilde med Security Shield logoen ved oppstart bør man krysse av i avkrysningsboksen. Dersom man ikke krysser av vil man komme rett inn i Kiosk programmet uten noe velkomstbilde. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side155

160 Figur KioskMode velkomst skjerm Enter SIM, PIN code at startup Ved å krysse av i denne avkrysningsboksen velger man om sim-kortets PIN kode skal tastes inn ved oppstart av mobilen. Dersom man skal bruke Kiosk programmet med et simkort installert på mobilen bør man krysse av her. Figur Vis pinkode panel ved oppstart Disable hardware keys Her kan man velge om man ønsker å deaktivere noen hardwareknapper på mobilen i tillegg til de som er deaktivert som standard. For å deaktivere en knapp må man skrive inn knappen heksadesimale verdi. Disse verdiene kan finnes her: Dersom knappen ikke finnes i denne listen, finnes det programmer som kan vise disse verdiene ved tastetrykk på mobilen. Eksempel på et slikt program er HkeyLogger som kan lastes ned her: Figur Deaktiver hardware knapper Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side156

161 3. Programmer KioskMode designeren lar brukeren legge til maksimalt åtte knapper som vises i KioskMode hovedmenyen. Figur 1.3 Steg Button text I dette feltet skal man skrive inn navnet på knappen. Denne teksten vil være synlig for brukeren under knappens ikon. Figur Knappen navn 3.2. Program path Her velges programmets filsti på mobilen. For å finne programmets filsti kan man bruke mobilens filutforsker. Vi har også lagt ved liste med prosesser og deres filsti under Quick menu øverst til høyre på websiden. Eksempel på en filsti er: \Windows\iexplore.exe. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side157

162 Figur Programmets filsti 3.3. Program parameter Noen programmer krever en parameterverdi. Til programmet Internet Explorer kan foreksempel parameteret benyttes slik at dette blir startsiden. Flere parameterverdier finnes under Windows Mobile processes i "Quick menu" øverst til høyre på websiden. Figur Programmets parameterverdi 3.4. Upload button icon Her kan man laste opp knappen ikon. Bildefilen må være i formatet (.jpg). Dersom det ikke lastes opp noe bilde, vil det bli brukt et standard ikon. Figur Last opp knappens ikon 3.5. Cancel, Next og Finish Trykk next for å legge til en knapp til. Cancel for å begynne prosessen fra begynnelsen eller Finish for å fullføre KioskMode programmet. Figur Cancel, next, finish Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side158

163 4. Build Etter at brukeren har trykket på finish kommer man til Build siden, som er siste steget i KioskMode designeren. Her trykker man Build for å lage KioskMode programmet. Dette tar ca. 20 sekunder. KioskMode installasjonsfilen lagres på et unikt webområde på serveren Nedlasting fra server For å laste ned KioskMode programmet kan man trykke på linken Click this link to download your KioskMode! Send nedlastingslink via SMS Skriv inn mottakers telefonnummer og trykk Send SMS! for å sende nedlastningslink via SMS Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side159

164 5. Installasjon av KioskMode klient Installasjonsprogrammet kommer i form av en (.CAB) fil med navn KMInstaller.cab. Dette er filen som skal installeres på Windows Mobile telefonen. Under følger instruks for hvordan denne installeres på enheten Forberedelser før installasjon av klient programmer Under følger nødvendige forberedelser for bruk av KioskMode klienten Installasjon av Compact Framework 3.5 For at programmet skal fungere optimalt bør Compact Framework 3.5 være installert på enheten. Nærmere informasjon om nedlastning og installasjon finnes på Microsoft sine websider. Link til Compact Framework 3.5: bf4cc2bd&displaylang=en Installasjon av Certs.cab For at KioskMode klienten skal kunne starte opp ved oppstart av mobilen må Certs.cab være installert. Dette er et test sertifikat fra Microsoft. Link til nedlastning av Certs.cab: Overføring av KMInstaller.cab via ActiveSync/Mobile device center Windows mobiltelefonen må være koblet til PC med en USB kabel. I Windows, trykk: Start meny Min Datamaskin/Datamaskin(Vista) Velg ikonet Mobile Device. Ved å gå inn på denne, får man tilgang til alle filer og mapper som ligger lagret på den mobile enheten. Kopier filen KMInstaller.cab til en mappe på enheten eks. Mine Dokumenter. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side160

165 5.2. Installasjon av klient programmet Under vises fremgangsmåten for å installere programmet Installasjon av KioskMode via nedlastningslink på SMS Etter SMS er mottatt på klient, trykk på linken og spesifiser hvor på enheten filen skal lagres. Trykk kjør etter at filen er lastet ned og applikasjonen vil installeres på mobilen. Når installasjonen er ferdig, restartes mobilen automatisk og KioskMode applikasjonen starter ved oppstart. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side161

166 Installasjon av KioskMode via mobilens filutforsker Trykk Start Programmer Filutforsker og naviger deg frem til KMInstaller.cab filen. Trykk på filen og velg Kjør. KioskMode installeres nå på mobilen. Når installasjonen er ferdig, restartes mobilen automatisk og KioskMode applikasjonen starter ved oppstart. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side162

167 6. Veiledning for KioskMode klient 6.1. Hovedmenyen Under vises KioskMode hovedmenyen. Denne viser klokkeslett, dato og batteriets status. Her velges hvilken applikasjon som skal startes. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side163

168 6.2. Navigering med Windows oppgavelinjemenyen deaktivert Trykk på en knapp for å starte en applikasjon. Trykk på Click to return for å returnere til KioskMode hovedmenyen Navigering med Windows oppgavelinjemenyen aktivert Trykk på en knapp for å starte en applikasjon. Trykk på X-knappen for å returnere til KioskMode hovedmenyen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side164

169 6.3. Administrator- funksjonalitet KioskMode applikasjonen har et hemmelig administratorpanel Åpne loginpanelet Hold inne pennen i mer enn ti sekunder over det svarte feltet i hovedmenyen for å starte loginpanelet Loginpanelet Tast inn administrator passordet for å starte administratorpanelet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side165

170 Administratorpanelet Administratorpanelet kan benyttes til å aktivere/deaktivere bluetooth, ActiveSync og autorun fra SD-minnekort, samt at det gir tilgang til å avinstallere KioskMode applikasjonen Aktiver/deaktiver funksjoner Husk av på hvilke av funksjonene som skal aktiveres og trykk Submit changes. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side166

171 Avinstallere KioskMode For å avinstallere KioskMode, trykk Uninstall Kiosk Velg deretter Security Shield Kiosk engine i listen og trykk Fjern. KioskMode avinstalleres og Windows mobilen gjenopprettes til den tilstand den var i før installasjon av KioskMode. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side167

172 7. Brukerveiledning Configuration Manager 7.1. Før du logger inn Alle brukere av Security Shield sine websider må logge inn for å få tilgang. For å kunne logge inn må du ha fått tildelt brukernavn og passord fra Security Shield. Etter at du har fått disse opplysningene kan du logge deg inn ved å klikke på Logg inn knappen på Security Shield sine websider. Du finner Security Shield sine websider på, Figur 1 : Skjema for innlogging Som man ser på figur 1, er det 2 felt hvor bruker må fylle inn informasjon om brukernavn og passord. Det er også mulig å generere ett nytt passord hvis man har glemt det. Dette vil bli sendt til epostadressen som er registrert på brukeren. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side168

173 7.2. Tilganger og roller Avhengig av hvilken rolle brukeren har, vil man ha tilgang til forskjellige deler av websiden. De forskjellige rollene bestemmer hvilke operasjoner man kan utføre. Administrator Har tilgang til alle operasjoner på websiden. Kan logge på de forskjellige kunders konto for å utøve support. Customer Har tilgang til spesifikke funksjoner for sin egen bedrift. Disse finner man i den horisontale menyen øverst. Til høyre vil der også være linker til de mest vanlige oppgavene en kunder utfører Meny Figur 2 - Eksempel på menyvalg Den horisontale menyen gir brukeren tilgang til alle sider der brukeren har tilgang. Du finner en liste over alle mulige operasjoner i listen nedenfor. Liste over operasjoner. Bruker o Legg til bruker o Endre bruker detaljer o Velge funksjoner for sperring på brukers mobil Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side169

1 Forside security shield

1 Forside security shield 1 Forside security shield Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren 2009 Side 2 PROSJEKT NR. 2009-25 TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130

Detaljer

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

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

Detaljer

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

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

Detaljer

Hovedprosjekt 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

HOVEDPROSJEKT I DATA VÅR 2011

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

Detaljer

Studentdrevet innovasjon

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

Detaljer

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

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

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

Detaljer

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

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

Detaljer

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

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

Detaljer

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

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

Detaljer

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Sluttrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting

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

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

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser)

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

Detaljer

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

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

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

Detaljer

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

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

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

Detaljer

Kravspesifikasjon. Forord

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

Detaljer

Gruppe 43. Hoved-Prosjekt Forprosjekt

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

Detaljer

Kravspesifikasjon Innholdsfortegnelse

Kravspesifikasjon Innholdsfortegnelse Kravspesifikasjon Innholdsfortegnelse 1.Introduksjon... 2 1.1 Medlemmer:... 2 1.2 Oppdragsgiver:... 2 1.3 Kontaktsperson hos Retriever:... 2 1.4 Veileder:... 2 1.5 Bakgrunn... 3 2. Om Kravspesifikasjonen...

Detaljer

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

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

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

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

Detaljer

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015 KRAVSPESIFIKASJON Kravspesifikasjon er en beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den fungerer som en kontrakt mellom oppdragsgiver og utviklere. DAGSPLANAPPLIKASJON

Detaljer

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

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

Detaljer

Forprosjektrapport ElevApp

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

Forprosjektrapport. Gruppe Januar 2016

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

Detaljer

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

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

Detaljer

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

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

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

Detaljer

Use Case Modeller. Administrator og standardbruker

Use Case Modeller. Administrator og standardbruker Vedlegg 1 Use Case Modeller Administrator og standardbruker 2 Use case Logge inn Bruker Bruker ønsker å logge inn Bruker har valgt å logge inn Bruker er logget inn 1. Systemet ber om brukernavn 2. Systemet

Detaljer

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

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

Detaljer

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

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

Detaljer

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

InfoRed Publisering. - produktbeskrivelse.  TalkPool WebServices Postboks Åneby InfoRed Publisering - produktbeskrivelse www.talkpool.no TalkPool WebServices Postboks 90 1484 Åneby InfoRed Produktbeskrivelse 2 Sammendrag InfoRed Publisering er produktet for å administrere en hel informasjonstjeneste,

Detaljer

1. Introduksjon. Glis 13/02/2018

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

Detaljer

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

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

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

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

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

Detaljer

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

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

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 Bacheloroppgave 2017

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

Detaljer

Kravspesifikasjon MetaView

Kravspesifikasjon MetaView Kravspesifikasjon MetaView BACHELOROPPGAVE VÅREN 2014 1. Presentasjon Tittel: MetaView Oppgave: Lage en applikasjon og api som skal kommunisere med MetaVision slik at det skal bli enklere for leger og

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

Styringsdokumenter. Studentevalueringssystem

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

Detaljer

Forprosjektrapport Gruppe 30

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

Detaljer

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

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Testrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting

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

Bachelorprosjekt i informasjonsteknologi, vår 2017

Bachelorprosjekt i informasjonsteknologi, vår 2017 Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,

Detaljer

Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018

Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018 Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018 Utvikling av Spires Medlemsregister Gruppe 2, medlemmer Etternavn Fornavn og mellomnavn Studentnummer

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

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

Detaljer

Prosjektdagbok hovedprosjekt våren 09

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

Detaljer

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

Testdokumentasjon. Testingen utføres for å utelukke mest mulig feil i systemet.

Testdokumentasjon. Testingen utføres for å utelukke mest mulig feil i systemet. PROSJEKT NR. 2007-30 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET Åpen Telefon: 22 45 32 00 Telefaks: 22 45 32 05 Testdokumentasjon

Detaljer

2/3/2014 INSTITUTT FOR FÔRIT CDS INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS. Shahariar Kabir Bhuiyan

2/3/2014 INSTITUTT FOR FÔRIT CDS INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS. Shahariar Kabir Bhuiyan 2/3/2014 INSTITUTT FOR INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS FÔRIT CDS Mikkel Sannes Nylend Shahariar Kabir Bhuiyan Stian Strøm Anderssen Denne siden skal være blank. 1 Presentasjon Prosjektgruppe:

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

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

1 Forord. Kravspesifikasjon

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

Detaljer

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

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

Innholdsfortegnelse. Side 118 av 135

Innholdsfortegnelse. Side 118 av 135 Forord Dette produktet er endel av hovedprosjektoppgaven til gruppe 33 vår 2011. Produktet har som hensikt å lagre SMS meldinger i en Noark standard. Leseren av denne brukermanualen skal ikke trenge noen

Detaljer

Veiledning for aktivering av. Mobil Bredbåndstelefoni

Veiledning for aktivering av. Mobil Bredbåndstelefoni Veiledning for aktivering av Mobil Bredbåndstelefoni Veiledning for aktivering av Mobil Bredbåndstelefoni For at Telio Mobil Bredbåndstelefoni skal fungere på din mobiltelefon må en klient (@irtelio) lastes

Detaljer

P L A N I A 8 S Y S T E M K R A V PLANIA 8 SYSTEM KRAV. Plania 8 Systemkrav.docx 27.04.2015 1 av 8

P L A N I A 8 S Y S T E M K R A V PLANIA 8 SYSTEM KRAV. Plania 8 Systemkrav.docx 27.04.2015 1 av 8 PLANIA 8 SYSTEM KRAV Plania 8 Systemkrav.docx 27.04.2015 1 av 8 INNHOLD 1 INNLEDNING... 1-3 1.1 Generell beskrivelse... 1-3 1.1.1 Plania DESKTOP og Plania WEB... 1-3 2 SYSTEMKRAV... 2-4 2.1 Krav til ulike

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

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

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

Detaljer

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

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

Detaljer

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

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

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Kravspesifikasjon 1 Inledning 1.1 Presentasjon Tittel Informasjonsplattform for NorgesGruppen Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer

Detaljer

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord. Forprosjektrapport Tittel Oppgave Periode Openfoos Utvikle en plattform for digitalisering av foosballbord. 3. januar til 15. juni Gruppemedlemmer Amir Ghoreshi Marcel Eggum Neberd Salimi Valentin Rey

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

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

Detaljer

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg Forprosjektrapport Presentasjon Tittel Bakerman AS Website Oppgave Utvikle ett websted for Bakerman AS der hvor de kan promotere seg selv og kommunisere med kundene sine. Periode 4. Januar 2010 til 17.

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

Kravspesifikasjon. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31

Kravspesifikasjon. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31 Kravspesifikasjon Noark 5 grensesnitt Hovedprosjekt informasjonsteknologi Gruppe 31 Forord Denne kravspesifikasjonen inneholder retningslinjer for oss og for det vi skal utvikle. Den inneholder funksjonelle

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

Detaljer

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

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

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

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. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007.

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007. PROSJEKT NR. 2007-16 TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL DATO Panther

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

Hovedprosjekt våren 2007

Hovedprosjekt våren 2007 Hovedprosjekt våren 2007 Bachelorstudiet i informasjonsteknologi ved Høgskolen i Oslo Dokument Kravspesifikasjon Prosjekttittel: Telepower Prosjektnummer: 07-06 Oppgave: Redesign av Telepower - en GSM/GPRS/SMS

Detaljer

Installasjonsveiledning

Installasjonsveiledning Installasjonsveiledning Visma Avendo Lønn, versjon 7.60 Oktober 2011 Innhold 1. Innledning... 1 2. Installasjon / oppgradering... 2 2.1. Installasjon av nødvendige tilleggskomponenter... 3 2.2. Installasjon

Detaljer

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android 6 Kravspesifikasjon 6.1 Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes av studenter for å øve på fagpensum. Appen skal ta i bruk prinsipper fra Precision

Detaljer

Mandag : Onsdag : Torsdag : Mandag :

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

Detaljer

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

KRAVSPESIFIKASJON FORORD

KRAVSPESIFIKASJON FORORD KRAVSPESIFIKASJON FORORD Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg

Detaljer

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12 1 av 6 1.Innledning 1.1Presentasjon Dato: 01.02.2011 Bacheloroppgave: Produktkalkyle for Granitt Grafisk AS Gruppenr: 11-12 Gruppemedlemmer: Pål Georg Dahl Myran Joakim Haneberg Johansen Michael Venables

Detaljer

Forprosjektrapport For gruppe 20:

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

Detaljer

Forprosjekt - Gruppe 12. Hovedprosjekt av

Forprosjekt - Gruppe 12. Hovedprosjekt av FORSIDE A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O O G A K E R S H U S Forprosjekt - Gruppe 12 Hovedprosjekt av S AJ ID, OZAI RE (S 1711 9 7), S VEEN, S IMEN (S171208),

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.

Detaljer

Gruppe Forprosjekt. Gruppe 15

Gruppe Forprosjekt. Gruppe 15 Forprosjekt Gruppe 15 Marius Ylven Westgaard - s236797 - Anvendt Datateknologi Lise Janbu Eide - s236361 - Dataingeniør Lavanja Jeyenthiran - s236346 - Dataingeniør Kristian Pedersen - s236728 - Anvendt

Detaljer