Forprosjektrapport. CampLett. Automatisert innsjekkingssystem for campingplass. Roy Arve Hetle Sander Falkenstein Eivind N. Inderøy Jens Førsund

Transkript

1 Forprosjektrapport CampLett Automatisert innsjekkingssystem for campingplass av Roy Arve Hetle Sander Falkenstein Eivind N. Inderøy Jens Førsund Ingeniør elektro - automatiseringsteknikk HO2-300-Hovudprosjekt 2015 Februar 2015

2 Forord Dette forprosjektet er gjennomført som ein del av det avsluttande hovudprosjektet i sjette semester ved Høgskulen i Førde. Prosjektet er ei vidareføring av prosjektet gruppa hadde i femte semester. Der såg vi på om det var interesse i marknaden for automatisering av innsjekking på campingplass. Denne rapporten er ei vidareføring av det prosjektet. I denne rapporten har vi satt rammene for korleis hovudprosjektet skal gjennomførast. Totalt har vi 500 timar pr. student. I rapporten ser vi på korleis vi skal løyse det praktiske og kva løysing vi går for. For å styre prosjektet, har vi og jobba med å redusere risiko i prosjektet gjennom analyser og risikovurderingar. Vi vil takke Joar Sande som er vår rettleiar for samarbeid og tilbakemeldingar. Prosjektgruppa består av: Roy Arve Hetle Prosjektleiar Eivind N. Inderøy Teknisk Sander Falkenstein Nettside Jens Førsund Teknisk og risiko I dette prosjektet er Joar Sande rettleiar og sitter i styringsgruppa. Førde Roy Arve Eivind N. Sander Jens Hetle Inderøy Falkeinstein Førsund 1

3 2. Innhaldsliste Forord Innhaldsliste Samandrag Innleiing Plan for hovudprosjekt Ansvarsfordeling Milepælar og oversikt over tidsbruk Økonomi Nettside Teknisk løysing Usikkerheit Risikovurdering SWOT-Analyse Konklusjon Hovudmål Delmål Ordliste Figur og Tabelliste Referanse Vedlegg

4 3. Samandrag Formålet med rapporten er å setje ramma for hovudprosjektet våren For å lette innsjekking ved campingplassar ønska vi å utvikle ei programvare som skal kunne installerast og driftast på campingplassar. Formålet er å gjere dagen lettare for turistane som er på jakt etter ein plass å overnatte. I tillegg har vi og sett på funksjonar vi kan utvide systemet med. Vi skal ha fokus på å få tilbakemelding frå publikum, slik at vi får eit mest mulig brukarvennleg system. Det er derfor eit mål å lage ein teststasjon som kan synast fram til campingplassar og andre interesserte. I rapporten har vi laga ei grovskisse av utforminga på programvaren som syner korleis vi har tenkt at den kan sjå ut. Dette er ei løysing som vi tenkjer er lettvint og brukarvennleg for den brukargruppa vi søker. Vi har gjennom prosjektet i haust [1] og etter samtale med campingplassar danna oss den utforminga som er synt i rapporten. Sjølve algoritmen blir satt saman ved hovudprosjektstart. 3

5 4. Innleiing Som hovudprosjekt for våren 2015 har vi valt å utvikle ein programvare for automatisert innsjekking ved campingplass. Grunnlaget for dette valet kom frå at vi hausten 2014 hadde eit prosjekt om prosjektstyring i faget «Ingeniørfagleg systememne». Der kom gruppa fram med ideen om å automatisere innsjekking ved campingplass. Under prosjektet kartla vi interesse og behov i marknaden der konklusjonen vart at det ikkje fanst tilsvarande system, samt at tilbakemeldingane på behovet for eit slikt produkt var gode. Derfor meinte vi at dette var eit godt utgangspunkt for vidare arbeid. [1] I haust henta vi også inn prisar på det utstyret vi meinte det var behov for etter vurderingar saman med to campingplassar. Når vi var ferdige med prosjektet bestemte vi oss for å ta arbeidet vidare til bacheloroppgåve. [1] For å gjennomføre prosjektet var vi nøydt til å setje avgrensingar i forhold til tid og økonomi. Vi er fire personar på gruppa. Vi vil i dette forprosjektet legge grunnlaget for kva hovudprosjektet skal innehalde og korleis arbeidet skal fordelast mellom oss fire og kva avgrensingar vi skal setje. 4

6 5. Plan for hovudprosjekt I dette hovudprosjektet skal vi utvikle ein software for automatisert innsjekking på campingplassar. Vi har estimert timar utifrå erfaring vi har frå lab-øvingar i programmering og tidlegare prosjekt. I løpet av prosjektet skal vi utvikle ein prototype som vi kan demonstrere for campingplassar. Vi hadde eit prosjekt hausten 2014 der vi prøvde å kartlegge interessa for eit slikt produkt. Mange var interesserte i å prøve ut eit slikt produkt. [1] Vi fekk ikkje finansiering til å utvikle eit fullskala system, prisen på dette ligg mellom [1] Vi trur at ved å utvikle ein software som viser korleis storparten av systemet fungerer, vil på sikt gjere det enklare å få med seg investorar. Utan oppdragsgivar står vi friare til å utvikle dette ilag med fleire aktørar og kan legge til funksjonar som vi ønskjer Ansvarsfordeling Figur 1 Viser organisasjonskart 5

7 For å sikre kvalitet på arbeidet blir det delt opp i ulike ansvarsområder. Vi vil organisere gruppa som eit reelt prosjekt i arbeidslivet. For å sikre at alle får god innsikt og god fagleg utvikling i prosjektet, skal alt som blir gjort av programmering og undersøkingar dokumenterast. Prosjektleiar Roy Arve Hetle er ansvarlig for møteinnkalling og klargjering av møter, han skal og passe på at vi held framdriftsplanen i prosjektet. Prosjektleiar har hovudansvaret for å setje saman den skriftlege rapporten og i tillegg til dette har prosjektleiar ansvar for å setje opp budsjett og føre rekneskap. Tidlegare erfaring viser at vi får dårlig flyt i rapporten og at vi har for mykje fokus på å få til prosjektet og for lite fokus på dokumentering. Alle i gruppa skal levere statusrapport kvar veke slik at prosjektleiar har oversikt, og kan få alt inn i hovudrapporten etter kvart som ein ferdigstiller dei ulike delane. Sander Falkenstein er ansvarlig for å utforme nettside. Her skal viktige dokument leggast ut i samsvar med prosjektbeskrivinga. Gruppa vil i tillegg legge ut oppdatering når viktige mål er nådd og legge ut korte rapportar etter kvart som arbeidet går framover. Sander skal i tillegg bidra til utvikling av programvaren. Gruppa har bestemt at Jens og Eivind har hovudansvar for utvikling av programvaren, men det vert lagt opp til at alle skal delta i dette arbeidet. Programmering er den delen som er lagt inn med mest timar i prosjektplanen. Dette er berre eit utgangspunkt for prosjektet, alle i gruppa skal rapportere inn til prosjektleiar. I tillegg kan det bli justeringar på arbeidsoppgåvene etter kvart som prosjektet er i gang. Styringsgruppa er samansett av alle medlemmane i prosjektgruppa i tillegg til Joar Sande som og fungera som rettleiar. Styringsgruppa skal halde møte kvar fjortande dag for å kontrollere at prosjektgruppa held framdriftsplanen. 6

8 5.2. Milepælar og oversikt over tidsbruk Vi har utarbeid Gantt-skjema og eit timefordelingskjema som vi skal styre etter. Dette er for å ha kontroll på fristar og med timeforbruk på dei ulike delane av prosjektet. Tabell 1 Viser viktige datoar i prosjektet Oppgåve Frist Forprosjekt Oppstart Hovudprosjekt Etter godkjent forprosjekt Status framføring Innleveringfrist hovudprosjekt Framføring hovudprosjekt Nettside ferdig Rapport Forprosjekt Programmering Design Testing Status framføring Feilretting slutt test Reservetid rapport nettside Presentasjon Bacehelor Figur 2 Viser Gantt-skjema for hovudprosjektet 7

9 Som ein ser frå figur 2, har vi satt oss mål om å bli ferdig med å utvikle programvaren tidleg. Dette er for å ha god tid til å teste den ut og å gjere eventuelle forbetringar og endringar. Vi har delt opp prosjektet i ulike delar med interne fristar slik at gruppa til ei kvar tid har arbeidsoppgåver som skal fokuserast på (sjå vedlegg 1.). Reservetid rapport 4 % Feilretting 5 % Status framføring 2 % Testing 2 % Design 5 % slutt test 3 % nettside 4 % Timar Programmering 34 % Presentasjon Bacehelor 3 % Rapport 33 % Forprosjekt 5 % Figur 3 Viser timefordeling i prosent. Vi har stipulert 2068 timar til prosjektet 5.3. Økonomi På den økonomiske sida har vi tidlegare forklart at vi står åleine og det gjer oss svakare økonomisk. Skulen har lova å gå inn å dekke store delar av utgiftene til utstyr som vi har behov for under prosjektet. Det vi har størst behov for er ein berøringsskjerm som skal brukast som HMI. I tillegg skal vi reise ut å vise fram prototypen til fleire campingplassar. Vi har sett opp dette budsjettet for å få dekka dei viktigaste komponentane. Vi har fått løyve til å låne minibankterminal av Akutten studentkro. Tabell 2 Budsjett for hovudprosjektet Budsjett Inntekter Utgifter HMI(skjerm) Reise Støtte frå skulen 9550 Totalt Resultat 0 8

10 6. Nettside Prosjektgruppa skal som del av forprosjektet opprette ei nettside som skal oppdaterast og vedlikehaldas parallelt med framgangen i prosjektarbeidet. På nettsida vår skal det leggast ut prosjektbeskriving, forprosjektrapport, pressemelding, plakat og sluttrapport. Vi vil også legge ut informasjon om kva gruppa jobbar med undervegs. Gruppa har utnemnt Sander som ansvarleg for heimesida. Han utformar sida, får den opp å gå på internett, vedlikeheld og oppdaterer den under prosjektperioden. Når det kjem til utforming av nettsida, har vi tatt i bruk Wordpress. Det er eit gratis publiseringsverktøy med fokus på utsjånad, nettstandardar og brukarvennlegheit. For å kunne utvikle ei nettside i Wordpress lokalt, hadde vi bruk for ein lokal webserver. Der er det fleire gratisprogram vi kan velje mellom, til dømes XAMP,WAMP og LAMP. Sidan vi gjorde oss kjend med XAMP 5. semester har vi valt å bruke dette programmet. Når vi brukar Wordpress er det ikkje nødvendig å skrive verken PHP eller html -kodar, men om ein vil lage heilt eigne menyar, eller widgetar (miniprogram som arkiv, kalender osv.) så er det fullt mulig å kode sjølv. Då vi fekk domenenamnet til heimsida vår, eksporterte vi heimesida vi lagde på en lokal Wordpress-konto til ei XML-fil. Denne fila importerte vi til den nettbaserte Wordpresskontoen, som vart oppretta når domenenamnet var tilgjengeleg for oss. Både passord og brukarnamn fekk vi på e-post av Knut Erling Øien. 9

11 7. Teknisk løysing Programvaren skal programmerast i Java ved hjelp av ein plattform som heiter Netbeans, for å lage dei visuelle skjermbilda vil vi bruke JavaFX. Dette er program vi har brukt gjennom utdanninga vår på HiSF så vi har alle ein del erfaring med det. Det skal opprettast kommunikasjon til ein bankterminal slik at det blir mulig å betale for det alternativet som kunde har valt. Programmet skal lagast slik at det blir lett å redigere og legge til nye element, slik kan vi justere det til fordel for dei ulike campingplassane. Vi skal også kunne installere det ferdige produktet på ein pc som har Windows-operativsystem for så å sette opp ein teststasjon på skulen. Ved hjelp av den teststasjonen kan vi prøve ut grensesnittet på personar som ikkje har kjennskap til programmering, og få ei tilbakemelding på brukarvennlegheit. Dette er viktig i ein testfase. Figur 4 Viser døme på teststasjon vi kan bruke for å få tilbakemelding Grensesnittet skal vere enklast mulig for brukar, og skal vere tilgjengelig på fire språk Norsk, Engelsk, Polsk og Tysk. Språkvala vi har valt er på bakgrunn av turistgruppa i Noreg, vi føler det er dei fire hovudgruppene av språk som blir brukt. Sidan brukargruppa vår strekk seg i alt frå barnefamiliar til eldre brukarar har vi satt som mål at systemet skal vere "barnevennleg", det vil sei at det skal vere enkelt i bruk og opplyst med fargar, bilde og tekst som blir lett forstått. 10

12 Vi har laga ei grovskisse av systemet som vi skal gå ut ifrå. Sjølve algoritmen på korleis programmeringa skal gå føre seg skal vi sette saman ved prosjektstart. Vi kom fram til tre forskjellige innsjekkingsmoglegheiter med muligheit for å legge til fleire. Vi har basert vala på det som campingplassar brukar, og det har hovudsaklig vore hytte, bubil og telt. Figur 5 Viser første side med fire språkval Figur 6 Viser andre side med val av type innsjekking og om det er ledig 11

13 Figur 7 Viser tredje side, her under val "telt", og korleis ein kan velje plass ved hjelp av kart. Kartet her er over Kjørnes Camping frå Google maps Figur 8 Viser fjerde side og val av lengde på opphaldet Figur 9 Viser femte bilde og den sida som kommuniserer med bankterminal 12

14 Figur 10 Viser sjette side der ein ser kvittering med muligheit for å skrive ut For å ikkje gå over timebruken vi har fått tildelt måtte vi avgrense oppgåva som vist over. Men om vi ligg bra an i forhold til tidsbruk så har vi sett opp nokre moment vi kan utvide med: Utskrift av nøkkel(til dømes kort/brikker med NFC for opning av hytter og bom) Kommunikasjon med sensorar for heving/senking av bom Kommunikasjon med eksisterande databasar for nettregistrering Mobilapplikasjon(Innsjekking med telefon og nettbrett) Virtuell modell som syner samarbeid mellom program og utstyr på campingplassen. Administratormodus for eigar med statistikk, logg etc. 13

15 8. Usikkerheit For å få oversikt over dei elementa av usikkerheit, eller risiko, med gjennomføring av prosjektet vårt, har vi valt å sette fokus på usikkerheit allereie i forprosjektet. Vi starta med ei idémyldring på farar og fallgruver, dette var mykje basert på eigen erfaring med tidlegare prosjektarbeid. Vi har også brukt ein del av punkta frå prosjektet hausten [1] 8.1 Risikovurdering Vi sette opp farane i ein tabell (sjå tabell 3) med sannsyn for at det inntreff og konsekvens om det skulle inntreffe, begge på ein skala frå 1 til 5. Produktet av dette utgjer kor mykje elementet trugar prosjektet vårt. Det vart nødvendig å sette ei grense for kva nivå vi skulle sette i gang tiltak og ikkje. Vi valde å sette grensa for produktet på 9, då dette såg ut som ein naturleg inndeling i forhold til dei elementa vi hadde i tabellen vår (sjå tabell 3). For dei elementa med produkt over 9 laga vi tiltak for forbetring, og rekna ut eit nytt produkt. I somme tilfelle kan ei løysing rette opp fleire faremoment, medan andre element treng fleire løysingar. Det er sjølvsagt ikkje alle farar og trugsmål ein veit om og kan forberede seg på. Det er derfor viktig at ein er open for å risikovurdere element som kjem til etter kvart i prosjektarbeidet. Dei elementa av fare som ikkje utgjorde sum over 9 såg vi ikkje på som reelle farar. Men spesielt dei elementa med høg faktor av konsekvens og lite sannsyn, kan være skumle om dei først inntreff. Derfor er det viktig at vi veit om dei på førehand. Tabell 3 Utdrag frå risikoanalyse Utfordring Sans 1-5 Kons 1-5 Sum Tiltak nr Ny sans Ny kons Ny sum For lite tid a Tekniske problem med innlevering b Feil mann/verktøy på oppgåva c Økonomisk ugjennomførbart prosjekt Tiltak nr. a b c Tiltak for forbetring Begynne tidlig med faste møter og klare arbeidsmål Sette av tid til å levere tidelgare en fristen Må være klare på oppgåvene og være opne for å bytte på roller, hyppige statusmøter 14

16 Tabell 3 viser eit utkast av risikoanalysa vår, fullstendig analyse kan ein sjå som vedlegg 2. Vi ser av denne risikoanalysa at orden i dokument og god loggføring løyser mange av utfordringane våre. Det er også viktig for oss at vi har profesjonelle møter og at vi i samarbeid kjem fram til klare arbeidsoppgåver og ansvarsområde. Dette hjelper oss til å holde fokus på kva som skal gjerast, og har milepælar å nå slik at vi ikkje utsett ting for mykje. For å få rapporten på eit profesjonelt nivå er vi nøydt til å bruke eksterne resursar på korrekturlesing. I dette kapittelet har vi basert ein del av metodane våre på NTNU sin Concept rapprot nr. 12 frå NTNU [2]. Mykje av arbeidet er også basert på rapport for Sjølvstyrt camping 2014 [1] 8.1 SWOT-Analyse Som ein del av produktutviklinga har vi laga ei SWOT-analyse (sjå vedlegg 3.) som tek føre seg framtidsutsiktene til produktet. Ved å sette opp stikkord i forhold til produktutviklinga i eit slikt skjema kan får vi kategorisert kva som er mogelegheiter, svakheiter, styrkar og truslar. Kunnskapen om SWOT-analyse er i stor grad basert på Concept rapport nr. 12 frå NTNU [2] Etter kvart som utviklinga er i gang gjeld det å fokusere på styrkane våre og utnytte mogelegheitene så mykje som råd er. Truslane må vi prøve å unngå så godt som vi klarar og svakheitene våre må vi prøve å snu eller nøytralisere. Fleire av svakheitene lar seg løyse allereie i risikovurderinga. 15

17 9. Konklusjon Vi har avgrensa hovudmålet vårt til å lage ein programvare for ein innsjekkingsautomat, i staden for ein automat i full skala. Slik kan vi halde utviklingskostnadane nede og samtidig få brukt erfaringa vår med programmering mest mogeleg. Vi føler at betalingsløysinga er ein essensiell del av automaten, derfor er dette det einaste fysiske grensesnittet vi vi skal ha med i tillegg til datamaskina som programvaren køyrer på. Vi har mange idear og tankar om kva som kan leggast til systemet om tida strekker til, det er derfor viktig for oss å lage eit software som frå starten av er enkelt å utvide eller endre på. Forprosjektrapporten er skriven som ein plan på prosjektet vidare, her finn ein grovskisse og plan på teknisk løysing, organisering av gruppa, risikovurdering og usikkerhetsanalyse på produktutviklinga. Det er også oppretta ei nettside for prosjektet som del av forprosjektet Hovudmål Å prosjektere og utvikle eit software for bruk i sjølvbetjent innsjekkingsautomat på campingplass 9.2. Delmål - Utvikle Software for prototypen - Gjere programvaren enkel å oppdatere, slik at nye funksjonar enkelt kan leggast til - Lage eit brukarvenleg grensesnitt - Opprette og vedlikehalde nettside - Prototypen skal ha funksjonar for bestilling direkte på campingplassen - Halde fokus på risikostyring - Utvikle systemet basert på tilbakemeldingar frå dei campingplassane vi har samarbeid med tidlegare - Lage ein teststasjon for utprøving av software 16

18 10. Ordliste Netbeans - Plattform der vi programerar JAVA for å utvikle program JavaFX - Plattform i Netbeans der ein kan nytte JAVA-kode for å lage program Grensesnitt - Korleis brukaren kan kommunisere med programmet NFC - Near Field Communication, kommunikasjon ved hjelp av radiobølger over korte avstandar HMI - Human machine interface, tilgangspunkt mellom menneskje og maskin 11. Figur og Tabelliste Tabell 1 Viser viktige datoar i prosjektet... 7 Tabell 2 Budsjett for hovudprosjektet... 8 Tabell 3 Utdrag frå risikoanalyse Figur 1 Viser organisasjonskart... 5 Figur 2 Viser Gantt-skjema for hovudprosjektet... 7 Figur 3 Viser timefordeling i prosent. Vi har stipulert 2068 timar til prosjektet... 8 Figur 4. Viser døme på teststasjon vi kan bruke for å få tilbakemelding Figur 5:Viser første side med fire språkval Figur 6:Viser andre side med val av type innsjekking og om det er ledig Figur 7: Viser tredje side, her under val "telt", og korleis ein kan velje plass ved hjelp av kart. Kartet her er over Kjørnes Camping frå Google maps Figur 8: Viser fjerde side og val av lengde på opphaldet Figur 9: Viser femte bilde og den sida som kommuniserer med bankterminal Figur 10: Viser sjette side der ein ser kvittering med muligheit for å skrive ut Referanse [1] E. I. R. A. H. S. F. Jens Førsund, «Sjølvstyrt Camping,» HISF, Førde, [2] O. T. J. T. M. V. H. I. J. Kjell Austeng, «Usikkerhetsanalyse og metoder,» Concept-programme,tInstitutt for bygg, anlegg og transport,ntnu, Trondheim,

19 13. Vedlegg Vedlegg 1 arbeidsplan for Hovudprosjekt Oppgåver start dato slutt dato varigheit dager Timar Rapport Forprosjekt Programmering Design Testing Status framføring Feilretting slutt test Reservetid rapport nettside Presentasjon Bacehelor

20 Vedlegg 2 usikkerheitsanalyse Utfordringar Sans 1-5 Kons 1-5 Sum Tiltak Ny sans Ny kons For lite tid a Tekniske problem med innlevering b Feil mann/verktøy på oppgåva c Økonomisk ugjennomførbart prosjekt Ingen ledige grupperom d Teknisk svikt, pc osv e Vekkheft av andre f Arbeid blir utsatt for lenge a Fristar blir glømt/oversett g Feil/dårleg tilbakemelding frå styringsgruppa Større utfordringar en venta (java) h Manglande element i risikovurdering i Feil fokus på oppgåva a,c Viktig informasjon blir rota vekk a,e Manglar viktige element i rapport e,k Dårleg korrektur k For lite faglig tyngde i rapport j,l For dårlig forklart tekniske ting k Manglande dokumentasjon på kva vi har gjort e,j For høgt fokus på arbeid kontra rapport j,m Vanskeleg å få konstruktive tilbakemeldingar frå faglærar n Sabotasje frå andre Problem med opphavsrett på bilde ect Folk lagrar i same dokument på same tid o Dårleg kommunikasjon i gruppe gjer til at fleire jobbar med det same c Tar på oss meir enn vi har tid til h For mykje anna skulearbeid Problem med barn p Alvorlig Sjukdom i gruppa p Alvorlig ulykke i gruppa p Frivillig arbeid blir prioritert framfor prosjekt Folk møter ikkje på prosjektmøte q,r Sein kveld på akutten For lite dokumentert dagbok/timeliste j Sjukdom i nær familie p Dødsfall i nær familie p Ny sum 19

21 Vedlegg 2 usikkerheitsanalyse fortsetter Tiltak a b c d e f g h i j k l m n o p q r Begynne tidlig med faste møter og klare arbeidsmål Tiltak for forbetring Sette av tid til å levere tidelgare en fristen Må være klare på oppgåvene og være opne for å bytte på roller, hyppige statusmøter Booke rom tidleg, og sjå på andre mulige stader å arbeide Ta bakcup av dokument ofte, huske å lagre, alt skal lagrast på dropbox Bruke grupperom og kveldar mest mogeleg Gruppeleiar har ansvar for å dagleg halde seg oppdatert på fronter Avgrense oppgåva frå starten av og ha muligheiter for utviding Risiokovurderinga er open for endring under heile prosjektet Kvar enkelt skal føre timeliste og dagbok for kvar dag noko er gjort Rapporten skal korrekturlesast av fleire uavhengige og utanforståande Sette fokus på det faglege, skrive rapport for å beskrive produktet Satt av tid til rapport, ein person har hovudansvar for rapport Gi beskjed til faglærar om kva vi vil ha tilbakemelding, bruke andre en faglærar i tillegg Vi skal sjå på andre muligheiter, Google docks. Om ikkje må opning av dokument avtalast vere fleksible på tid for møte og arbeid. Førde dagbok og timelister slik at det er enkelt for andre og ta over om det trengs Alle må føle ansvar for prosjektet, PL er ansvarlig for å kalle inn til møter! Om nokon er meir enn 20 min. sein til oppsett tid, må han spandere kaffi den dagen 20

22 Vedlegg 3 SWOT-analyse Indre forhold Ytre forhold Fleksibilitet i produktet Styrker Behov for produktet Muligheiter Positivt Mogelegheit for avgrensing Produktet skal ha muligheit for å enkelt kunne utvides Gode Gratis produktutvikling Vi er ikkje avhengige av økonomisk overskot Byggjast ved hjelp av gratis programvare (netbeans etc) SW har låge kostnader etter utvikling Vi kan byggje vidare på andre system som allereie eksisterer tilbakemeldingar frå marknaden Er vi utan konkurranse? Kan vi få til eit krav, eller ønske frå myndigheitene om slikt produkt? Kan vi få økonomisk støtte? Vi ønskjer at kunden kan tene på å kjøpe produktet, økonomisk og/eller i form av fritid. Ha tru på det vi gjer, visjonar, vil sjå resultat muligheit for å kople til online? God planlegging, Hyppige statusmøter, Kvalitetsikring Muligheit til å justere prosjektet etter kvart God skriftleg dokumentasjon lettare å selje et produkt når vi har fungerande sw. mykje teknisk kompetanse i gruppa gruppa har interesse for produktet drivkraft i karakter fleksibelt produkt Godt samarbeid, føler seg trygg på gruppa, nær kontakt på fritida one of a kind norske folk bak produktet fokus på kunde heile tida verda blir meir og meir teknologisk kan tilpassast til ulike kundar Tilgang på sterk kompetanse i lærarar muligheit for teststasjon svak kronekurs, auke av turistnæring 21

23 Vedlegg 3 SWOT-analyse fortsetter Svakheter Truslar Negativt Vi kan bli for einspora og låse oss til løysingar som kanskje ikkje er optimale Tidsramma blir for lita for å gjennomføre prosjektet Om vi ikkje klarar å lage ein fungerande prototype Underkjent forprosjekt Feil fokus under produktutvikling, lagar noko vi ikkje treng vanskelig å lage fint design vanskelig å bli fornøgd med eige resultat fare for at ting går treigt i SW vi har ingen pris på full skala system lite erfaring lite som skal til for å felle bedrifta når vi er ferdig med Bachelor kjem vi til å gi oss Markedet ønskjer eit anna produkt en det vi gjer. Lover og reglar jobbar oss imot Nokon stel ideen vår Negativitet i marknaden Ikkje behov i marknaden Eksisterer det eit tilsvarande eller konkurrerande produkt? Behov for support / oppdateringar useriøst med studentar Hisf-domene som ikkje når ut til folk ikkje interessert i å legge så mykje pengar i det sjølv blir det for avansert for eldre vi er nøydt til å kjøpe en del ting av andre leverandører 22