Menysystem för gestbaserad interaktion

Menysystem för gestbaserad interaktion ett projekt för CID/CVAP vid NADA, KTH i kursen Programutvecklingsprojekt, 2D1954 Hanna Hagelin, 801022-7505 Uppdragsgivare: Patric Holm, 730302-0353 Sören Lenman Johnne Adermark, 780527-0076 Olle Sundblad Jonas Skubic, 800418-0272 Lars Bretzner Tippu Mahmood, 800914-0396

Innehållsförteckning 1 PROBLEMBESKRIVNING... 2 1.1 BAKGRUND... 2 1.2 SYFTE... 3 1.3 KRAV OCH AVGRÄNSNINGAR... 3 1.3.1 Funktioner... 3 1.3.2 Datormiljö... 3 1.3.3 Användare... 3 2 FÖRSLAG TILL LÖSNING... 4 2.1 SYSTEMETS DELAR... 4 2.1.1 Filter... 4 2.1.2 Musadapter... 4 2.1.3 Pajmeny... 4 2.1.4 Kommandocentral... 5 2.2 ANVÄNDARGRÄNSSNITTET... 6 2.2.1 Pajmenyer... 6 2.2.2 Konfigureringsfilerna... 6 3. GENOMFÖRANDE... 6 3.1 ARBETSMODELL... 6 3.2 ANSVARSFÖRDELNING I GRUPPEN... 7 3.3 TIDSPLANERING AV AKTIVITETER... 8 3.4 ADMINISTRATION... 9 3.5 ARBETE MED DOKUMENTATION... 9 4 RISKANALYS... 10 4.1 INLEDNING... 10 4.2 ANALYS OCH IDENTIFIERING AV RISKER... 10 4.2.1 Avgränsning av projektet inklusive tidsaspekten... 10 4.2.2 Personliga risker med projektdeltagarna... 11 4.2.3 Projektstyrningen (styrmodellen och beslutsmodellen)... 11 4.2.4 Risker kring gruppdynamiken... 11 4.2.5 Kunskapen... 11 4.2.6 Risker med hårdvaran... 12 4.2.7 Risker med mjukvaran... 12 4.3 ÅTGÄRDER... 12 4.3.1 Avgränsning av projektet... 12 4.3.2 Personliga risker med projektdeltagarna... 13 4.3.3 Problem med projektstyrningen... 13 4.3.4 Problem kring gruppdynamiken... 13 4.3.5 Kunskapsproblem... 13 4.3.6 Hårdvaruproblem... 13 4.3.7 Mjukvaruproblem... 13 REFERENSER... 14 1

1 Problembeskrivning Detta projekt är en del av ett större projekt som bedrivs vid CID (Centrum för användarorienterad IT-Design) och CVAP (Computational Vision and Active Perception Laboratory) vid NADA, KTH. 1.1 Bakgrund I projektet som drivs av CID och CVAP studeras hur handgester kan användas för interaktion. Utifrån datorseendebaserad analys av handgester önskas ett användargränssnitt utvecklas som kan komplettera, eller ersätta, tangentbord, mus, fjärrkontroller och talstyrning för interaktion. Detta gränssnitt kan användas för att styra hemelektronik, datorspel, visualiseringssystem och robotstyrning. Även personer med funktionshinder är en viktig målgrupp. Ett gestbaserat gränssnitt kan vara av två olika typer: Perceptive User Interfaces eller Multimodal User Interfaces [1]. Vid användning av Perceptive User Interfaces är utgångspunkten människans naturliga gester kombinerade med t.ex. kroppsspråk och tal. Multimodal User Interfaces utgår istället från handposer och gester som tagits fram för en viss tillämpning, de kan med andra ord ses som kommandon i ett kommandospråk. Projektet vid NADA har tagit denna andra inriktning, bland annat på grund av att det finns få naturliga, enkla handgester som har en överenskommen betydelse, speciellt om man ser till en tillämpning inom skilda kulturer. Det finns tre aspekter att ta hänsyn till då ett kommandospråk ska utvecklas: kognitiva aspekter, artikuleringsaspekter och tekniska aspekter [1]. De kognitiva aspekterna syftar på hur lätta kommandona är att lära sig och att komma ihåg. Ett sätt att underlätta för användaren är att använda naturliga och intuitiva gester men, som sagt, är det svårt att hitta en kulturell gemensam grund för denna typ av styrning. Hänsyn måste även tas till hur lätta gesterna är att utföra och hur uttröttande de är för användaren (artikuleringsaspekter) liksom till vad som är tekniskt möjligt i dagens samhälle (tekniska aspekter). Uppdragsgivarna till detta projekt koncentrerar sig för tillfället främst på de kognitiva aspekterna [1]. Utgångspunkten är att ett kommandospråk baserat på en menystruktur har den kognitiva fördelen att kommandon kan kännas igen istället för att behöva kommas ihåg. Menyerna är dock inte av den traditionella, linjära typen utan alternativen arrangeras i en cirkel där ett val baseras på riktning snarare än på avståndet från en utgångspunkt (s.k. pie menu). Denna radiella utformning har visat sig vara snabbare än den linjära [2] och användaren kan lättare lära sig att göra valet utan att titta på menyn. Inlärningsmöjligheten kan utnyttjas genom att menyn dyker upp efter en viss fördröjning vilket möjliggör för den avancerade användaren att göra sitt val utan att menyn måste visas, något som spar tid. Denna typ av meny brukar kallas marking menu och fungerar även i en hierarkisk struktur experten kan direkt, genom att gestens form med rörelser och svängar känns igen, göra sitt val medan nybörjaren arbetar långsammare och får upp synliga menyer. En naturlig, gradvis övergång kan därmed ske mellan nybörjar- och expertanvändare. För att utnyttja den hierarkiska marking-menyns fördelar i samband med gestbaserad interaktion krävs en kommandouppsättning i form av en startpose, en bana definierad av menyorganisationen som spåras samt en valpose. Eventuellt kan menyn struktureras så att handen återgår till grundpositionen (mitten av cirkeln) efter att valet har gjorts (s.k. flow-menu). En sådan struktur minskar den area som användaren måste täcka med sina gester och risken för utmattning avtar därmed. 2

För tillfället finns hos uppdragsgivarna ett fungerande system för att styra vissa funktioner hos en TV, en CD-spelare och en lampa. Datorseendemodulen spårar och känner igen handposer och representerar dem i termer av position, orientering och skala. Denna information passerar sedan ett filter innan den når menysystemet. Menyn aktiveras av en speciell handpose och genom att hålla denna pose kan användaren manövrera sig ner i menyhierarkin och välja ett alternativ (utförs med hjälp av en annan pose). Menysystemet saknar dock flexibilitet och uppdragsgivarnas önskan är att ett nytt menysystem utvecklas som gör det möjligt för dem att utforska olika menystrukturer med varierande funktionalitet. 1.2 Syfte Syftet med vårt projektarbete är att, utifrån tillgängliga prototyper och applikationer, utveckla ett programsystem som implementerar ett menysystem för styrning av t.ex. hemelektronik samtidigt som det är flexibelt och tillåter ett experimenterande med olika alternativ. 1.3 Krav och avgränsningar 1.3.1 Funktioner Vårt projektarbete ska resultera i en applikation bestående av ett fungerande menysystem som, tillsammans med befintlig utrustning, kan användas för att styra hemelektronik m.m. genom gestbaserad interaktion. Menysystemet bör vara flexibelt och tillåta ett experimenterande med olika menyalternativ, dvs. förändringar ska t.ex. kunna göras av vilka följder av gester och rörelser som ska utlösa en händelse. Menysystemet ska grafiskt sett vara utformat som en paj-meny med de valbara alternativen organiserade i en cirkel. Menysystemet ska vidare tillåta att alternativen är hierarkiskt organiserade med undermenyer i ett varierande antal nivåer och möjligheten ska även finnas att införa en viss fördröjning innan menyn syns på skärmen. Projektarbetet är koncentrerat till utvecklingen av denna menyapplikation men möjligheter finns att även titta på t.ex. det filter som hanterar inkommande information om användarens gester. Detta är dock inget krav. Uppdragsgivarnas föredrar ett funktionellt system som är lite mindre till storleken än ett större system som inte är funktionellt fullständigt och flexibelt. 1.3.2 Datormiljö Den hårdvara som behövs för en gestbaserad interaktion tillhandahålls av våra uppdragsgivare och består av deras datorseendemodul. Någon utveckling av denna ingår inte i vår uppgift. Mjukvaran som ska utvecklas är ett menysystem i programmeringsspråket Java som jobbar mot en xml-fil där menyns uppbyggnad och funktionalitet definieras. Modifieringar av menyn, t.ex. för att undersöka olika menyvarianters för- och nackdelar, sker via denna xml-fil. 1.3.3 Användare Användarna av det menysystem som vårt projekt ska resultera i är i första hand uppdragsgivarna på CID och CVAP. Systemet kommer att användas i deras vidare forskning kring utvecklingen av ett användargränssnitt för gestbaserad styrning av bl.a. hemelektronik. Om allting går bra kan därmed vårt arbete, någon gång i framtiden, vara en bidragande del i ett större system som riktar sig till de användare som vill ha möjligheten att styra sin utrustning utan yttre hjälpmedel. 3

2 Förslag till lösning Vårt system kommer att bestå av ett Java-program som visar pajmenyer och kan styras av CID:s handgestigenkänningssystem. Vårt program kan i sin tur skicka kommandon till ett system som styr elektriska apparater, exempelvis TV-apparater eller belysning. 2.1 Systemets delar Figur 1 Beskrivning av systemet 2.1.1 Filter Systemet får indata från gestigenkänningssystemet i form av TCP/IP-paket som innehåller data om den igenkända handposen, handens position relativt kameran, handens storlek och en vinkel som anger handens rotation relativt kameran. Varje gång användaren håller upp handen mot kameran genereras ett antal sådana paket och ibland blir poseigenkänningen fel. Vi har alltså dels repetition i data, dels brus. Om användaren till exempel gör handpose 3 kanske vi får 7 paket för pose 3, följt av två felaktiga paket med pose 2 och sedan 6 paket med pose 3. Vi vill kunna filtrera paketen så att vi i detta fall bara känner igen pose 3 en gång. Filtret kommer att anse att en handpose a har gjorts om den tagit emot n stycken paket, varav p stycken anger att a har känts igen. Filtret kommer då att skapa ett objekt som anger vilken pose som utförts, samt handens position, storlek och rotation. 2.1.2 Musadapter Förutom att kunna styra pajmenyerna med handgester bör man även kunna styra dem med en mus. För att åstadkomma detta ska vi skapa en adapter som kan läsa in MouseEvents i Java och skapa objekt av samma typ som filtret skapar, men där exempelvis musklick översätts till poser. Man kan då välja om man använder musen eller gestsystemet. 2.1.3 Pajmeny Pajmenyn är den mest omfattande delen av systemet. Den kommer att implementeras i Java2D och Swing. Pajmenymodulen har hand om att rita upp pajmenyer när de ska visas och att hantera de handlingar som användaren utför. När användaren flyttar handen avgör den aktiva pajmenyn vilket fält användare befinner sig i antingen mittfältet, någon av tårtbitarna eller utanför menyn. När användaren byter fält genereras ett Event som hanteras av kommandocentralen. 4

Pajmenyn ska vara flexibel och dess struktur ska kunna anges i XML. När programmet startar läses en XML-fil in som specificerar vilka val som finns i varje meny och olika parametrar, exempelvis färg och storlek. Ett exempel på hur en sådan XML-fil skulle kunna se ut finns i figur 2. I XML-filen för menyerna anges alltså inte menyhierarkier eller vad som sker när ett visst fält besöks. Detta hanteras av en kommandocentral och anges i dess XML-fil. Förmodligen kommer vi att använda kod från Jason Hongs pajmenyimplementation 1 vid implementeringen av denna del av systemet. <menulist> <menu id='lights' outerradius='200' innerradius='50'> <entry id='brighter' text='brighter' color='#ffffff' /> <entry id='dimmer' text='dimmer' color='#aaaaaa' /> </menu> <menu id='tv' outerradius='200' innerradius='50'> <entry id='nextch' text='next Channel' color='#998822' /> <entry id='prevch' text='previous Channel' color='#558822' /> <entry id='decvol' text='decrease Volume' /> <entry id='incvol' text='increase Volume' /> </menu> </menulist> Figur 2 XML för menyns struktur 2.1.4 Kommandocentral Varje gång användaren antingen förflyttar markören till ett nytt fält eller byter handpose så genereras en händelse. För att systemet ska vara så flexibelt som möjligt kan man med hjälp av en XML-fil specificera vilka kombinationer av händelser som ska leda till att exempelvis en ny meny öppnas, eller att ett kommando sänds till ett annat system. Detta görs genom att händelserna samlas i en lista. När de senast inkomna händelserna stämmer överens med någon av de händelsekombinationer som angetts i XML-filen utförs det som XML-filen säger ska utföras. Sedan rensas händelselistan. <commandlist> <command name='tvmenu'> <openmenu>tv</openmenu> <eventlist> <event type='move'>center</event> <event type='move'>tv</event> <event type='move'>out</event> </eventlist> </command> <command name='nextchannel'> <execute>rc SEND_ONCE samsung CH+</execute> <eventlist> <event type='move'>center</event> <event type='move'>channel</event> <event type='pose'>31</event> </eventlist> </command> </commandlist> Figur 3 Konfigurationsfil för kommandon 1 http://www.cs.berkeley.edu/~jasonh/download/software/piemenu/testpiemenu.html 5

2.2 Användargränssnittet Användargränssnittet utgörs dels av pajmenyerna som används av slutanvändare, dels av XML-filerna som den som bygger upp ett gestbaserat system använder för konfigurering av menyerna. 2.2.1 Pajmenyer Hur pajmenyerna fungerar styrs till stor del av hur systemet konfigureras, detta är ett av grundkraven på systemet. Gemensamt för alla möjliga konfigurationer av pajmenyer är att de är cirkulära, med ett cirkulärt mittenfält och ett antal tårtbitsformade fält, där varje tårtbit representerar ett möjligt val. Användaren kan få saker att hända antingen genom att utföra någon av de handposer som gestigenkänningssystemet känner igen, eller genom att förflytta en tänkt markör från ett fält till ett annat (eller bort från menyn). 2.2.2 Konfigureringsfilerna Konfigureringsfilerna är i XML och skrivs för hand av den som skapar ett gestbaserat pajmenysystem med hjälp av vårt system. Det finns en fil för att ange alla fält i menyerna och en fil för att knyta olika handlingar som användaren kan utföra till saker som ska utföras. XML-inläsningen kommer att ske med hjälp av SAX ett XML-API för Java. Den implementation av SAX som vi kommer använda är troligtvis Xerces. 3. Genomförande 3.1 Arbetsmodell Arbetet skall ske enligt Kent Becks modell extreme Programming så långt det passar in på vår problembeskrivning. Vi har valt att betona nedanstående punkter eftersom de är adekvata för ett projekt i den här storleksordningen: Planering: Vid projektets början beskriver kunden (CID) vilken funktionalitet som önskas. Vi kommer överens om vad som är möjligt, vad vi åtar oss att åstadkomma och på vilken tid. Systemet delas in i mindre delar och tillsammans med kunden bestäms vilken prioritetsordning som skall tillämpas, vilka funktioner som skall implementeras först. Projekttiden delas sedan in i mindre iterationscykler. För varje sådan är kunden med och bestämmer prioritetsordningen för just den cykeln. På detta sätt bibehålls kontroll över omfattningen på systemet samtidigt som man försäkrar sig om att få en färdig produkt. Testning: Testkod skall skrivas för varje klass innan denna implementeras. Detta skall göras kontinuerligt under hela arbetets gång. Enkel design: En självklar punkt men nog så viktig. Genom att sträva efter en enkel design läggs arbetet ner på det som är väsentligt och viktigt för beställaren. Refactoring: Refactoring innebär att men ändrar existerande kod i avsikt att göra den enklare eller effektivare. Det finns verktyg för att underlätta refactoring men vi kommer inte att använda något av dessa. Arbetet kommer istället att ske manuellt genom att vi kontinuerligt kontrollerar varandras moduler. 6

Programmera i par: Genom att programmera i par kommer fler projektdeltagare att kunna fler delar av systemet. Det möjliggör även för oss att lära oss av varandra samtidigt som följderna av en sjuk deltagare, speciellt om denna gjort förhållandevis mycket jobb, blir mildare. Kollektivt ägande av kod: Ingen i gruppen har testat detta arbetssätt i något tidigare projekt och viss skepsis finns. Vi ska dock följa denna punkt i vårt projektarbete och utvärdera arbetssättet i slutet. Kontinuerlig integration: Varje modul skall integreras i systemet direkt när den är färdig. Kodstandard: För att underlätta kommunikationen och förståelsen för varandras kod skall all implementation i Java ske enligt Java Code Conventions. 3.2 Ansvarsfördelning i gruppen Vi har delat ut ansvarroller enligt följande: Patric Holm: Projektledare Tippu Mahmood: Sekreterare. Hanna Hagelin: Dokumentationsansvarig Jonas Skubic: Teknisk chef Johnne Adermark: Samordningsansvarig När det gäller instuderingsfasen har vi gjort en indelning där varje gruppmedlem fått var sitt delområde som de är huvudansvariga för. Ansvaret ligger på att området fungerar i helheten, dvs. den ansvarige medlemmen behöver inte nödvändigtvis implementera denna del senare under implementationsfasen. Indelningen är gjord enligt följande: Java2d hur ritar vi upp pajmenyer? Hur upptäcker vi när markören rör sig mellan olika fält? Vad behöver vi tänka på när det gäller uppdatering m.m.? (Hanna) XML vad ska vi använda, JAXB, SAX, någonting annat? Hur fungerar det och hur ska ett XML-dokument som definierar en pajmeny se ut? (Tippu) Trådar hur trådar man i Java? Vilka trådar behöver vi och hur kombineras lyssnandet på en socket med att GUI:t ska fungera? (Johnne) Utvecklingsverktyg ska vi använda ant och hur används det i så fall? Ska vi använda JUnit för testning och hur fungerar det? Någon form av testverktyg måste finnas eftersom vi arbetar efter XP. (Jonas) Events/listeners hur får vi menyn att generera events när man byter handpositioner eller förflyttar sig mellan olika fält? Hur tar vi hand om dessa events och hur ser vi till att vissa följder av events gör att kommandon skickas till apparaten som styrs, eller att en ny meny öppnas? (Patric) 7

Ovanstående aktiviteter uppskattas att ta 10 timmar per gruppmedlem. Deadline för dem är satt till första veckan i mars. 3.3 Tidsplanering av aktiviteter Inlämning av den preliminära specifikationen sker den 4 mars. Fram tills dess bedrivs, vid sidan av arbete med denna, studier av delmoment inför implementationsfasen. Efter den 4 mars kommer deltagarna att vara upptagna med tentamensperioden, vilket medför att arbetsprestationen tillfälligt minskar. Direkt efter tentamensperioden får vi besked om den preliminära specifikationen. Mellan den 24 och den 26 mars ska en av gruppmedlemmarna träffa kursledaren för att ge en muntlig lägesrapport. Innan dess ska minst tre möten ha genomförts med uppdragsgivarna. Vid denna tidpunkt ska vi även ha målet fullständigt klart för oss. Efter ovanstående möte är det tänkt att implementationsfasen ska börja på allvar. För att underlätta dokumentationsarbetet kommer dokumentation att ske parallellt med implementationen. Innan det första tillfället för slutredovisning ska projektet, testningen samt dokumentationen av projektet vara slutfört. Instudering (fas 1) - XML 10 timmar - Java2D 10 timmar - Javatrådar 10 timmar - Eventlisteners 10 timmar - Utvecklingsverktyg 10 timmar - projektet med omgivning 10 timmar Implementation (fas 2) - XML 50 timmar - Menysystem 100 timmar Dokumentation (fas 3) - Systembeskrivning 20 timmar - Projektbeskrivning 20 timmar - Användarhandledning 20 timmar Testning (fas 4) - Betatestning 20 timmar Totalt 290 timmar 8

Tidsåtgång Timmar 160 140 120 100 80 60 40 20 0 1 2 3 4 Faser (se ovan) 3.4 Administration Administrationen delas upp på flera olika ansvarsområden. Projektledaren ska bestämma möten dels med gruppen och dels med uppdragsgivarna, sekreteraren skall dokumentera möten samt uppdatera hemsidan, dokumentationsansvarige ser till att slutdokumentationen görs och att den innefattar alla delar, den tekniska chefen är ansvarig för att programmeringen går framåt och samordningsansvarige ser till att alla delar i arbetet koordineras. När det gäller användarvänligheten samt det grafiska gränssnittet så delas ansvar för detta av alla projektmedlemmar. Eftersom själva huvudarbetet inte har påbörjats än så är arbetsuppgifterna skiftande, exempelvis så uppdateras hemsidan för tillfället av alla gruppmedlemmar. Vi har hittills haft fyra möten där enbart vi gruppmedlemmar deltagit. Meningen med dessa är att vi skall träffas en kort stund för att följa arbetet som sker och för att planera inför den kommande veckan. Vid varje möte förväntas alla rapportera om vad som gjorts sedan sist. Förutom de interna mötena har vi hittills haft tre möten med våra uppdragsgivare, dessa har bl.a. gett oss en inblick i problemet, detaljerad information om det tillgängliga systemet och möjligheten att diskutera den preliminära specifikationen. Under nästa period (period 4) är det tänkt att gruppen skall träffas minst en gång i veckan, lämpligen på måndagar då kursen är schemalagd hela dagen. När det gäller våra möten med uppdragsgivarna kommer de att ske då vi behöver assistans. 3.5 Arbete med dokumentation Ambitionen är att dokumentationen av projektets framskridande och systembeskrivningen ska ske kontinuerligt under arbetets gång. Varje steg dokumenteras slutgiltigt efter att det är utfört. Så fort dokumentation av ett delsteg är utförd ska den hanteras av dokumentationsansvarig. Användarhandledningen kommer att skrivas när implementationen av systemet är klar men den kommer att baseras på redan existerande dokumentation. 9

4 Riskanalys 4.1 Inledning Syftet med riskanalysen är att identifiera tänkbara framtida händelser som gör det svårare att nå projektmålen samt att få fram underlag till möjliga handlingsalternativ. Detta för att så långt som möjligt kunna eliminera riskerna eller hantera situationen om den inträffar. Riskanalysen har genomförts i grupp under en brainstormsliknande process där alla deltagare kommit med förslag på olika tänkbara risker med projektet samt sannolikheten för att dessa ska inträffa. Därefter har en gemensam diskussion förts kring olika förslag på hur dessa risker ska elimineras, hanteras och bevakas. Riskanalysen bör dock ses som en iterativ process vilket innebär att den bör genomföras ett antal gånger under projektets gång. Riskanalysen görs på olika nivåer och med olika inriktningar beroende på i vilket skede i projektet som den genomförs. 4.2 Analys och identifiering av risker Vi har undersökt förutsättningarna för att kunna genomföra detta projekt, vilket gjordes genom en gemensam diskussion inom gruppen. Vi har även diskuterat vilka risker som skulle kunna tänkas uppstå under projektets gång. I samband med detta har även en analys över vilka konsekvenser respektive risk skulle kunna få för projektet gjorts. Därefter har förslag till åtgärder gemensamt diskuterats bland gruppmedlemmarna. Sannolikheterna för att riskerna, som är upptagna nedan, ska inträffa är graderade enligt en tregradig skala som ges av: hög risk, mellanrisk och låg risk (och ges i samma ordning). Följande tänkbara övergripande risker med projektet har identifierats: Avgränsning av projektet inklusive tidsaspekten Personliga risker med projektdeltagarna Projektstyrningen (styrmodell och beslutsmodell) Risker kring gruppdynamiken Kunskapen (förkunskap och kunskap som måste inhämtas) Risker med hårdvara Risker med mjukvara 4.2.1 Avgränsning av projektet inklusive tidsaspekten En tänkbar risk är hur vi har bestämt oss för att begränsa omfattningen av vad vi anser hinna med inom ramen för denna kurs. Det har varit ganska svårt att bedöma gränsen av vad beställarna har ansett vara absolut nödvändigt att ha med och vad som bör finnas med (t.ex. i mån av tid). Vi har dock med hjälp av interna möten inom gruppen samt två möten med beställarna försökt att komma underfund med detta, och tycker nu att vi har en ganska god bild av hur vi kan avgränsa projektet. Denna punkt hänger tyvärr ihop med tidsaspekten av projektet. Risken är stor att vi felbedömer arbetsbördan av vad vi åtagit oss att göra både i denna kurs och i andra kurser på KTH och därmed kan vi hamna i problem under projektets gång. Vid bedömning av omfattningen av själva programmeringen inom ramen för projektet (räknat i tid) har projektgruppen till stor del förlitat sig på beställarna samt en hel del spekulationer. Det är naturligtvis mycket svårt att räkna ut hur lång tid programmeringen tar med tanke på att vi delvis rör oss inom okända områden (d.v.s. kunskaper som vi ännu inte 10

har). Vi bedömer därför sannolikheten som stor att vi räknat fel på hur mycket tid vi måste avsätta till detta projekt. Därför betraktar vi denna punkt som ett högriskområde som kan få allvarliga konsekvenser för vårt projekt om detta problem inträffar. 4.2.2 Personliga risker med projektdeltagarna Det finns alltid en viss risk att någon eller några deltagare av någon anledning (se även punkten om gruppdynamik) försvinner ur projektet. Det kan bero på sjukdom, olycksfall eller andra former av hinder. Detta skulle innebära stora problem för detta projekt eftersom vi är väldigt få och vi gör bedömningen att samtliga projektdeltagare behövs för att hinna klart i tid (med hänsyn tagen till att alla även läser andra kurser som vi måste hinna med). Sannolikheten att någon ska försvinna ur projektet bedömer vi dock som mellanstor, men effekten för projektets genomförande skulle bli mycket stor eftersom vi redan nu är ganska få deltagare. 4.2.3 Projektstyrningen (styrmodellen och beslutsmodellen) Projektstyrningen inom denna projektgrupp fungerar mer eller mindre informellt genom att alla gruppmedlemmar får komma till tals vid eventuella beslut. Formellt finns dock en projektledare, vars roll hittills har fungerat mer eller mindre som en länk mellan beställare, kursledare och projektmedlemmarna. Gruppen har också identifierat olika ansvarsområden vilket innebär att alla gruppmedlemmar har fått ett visst ansvar. I fortsättningen av projektet kommer därför projektledarens roll vara att sammanlänka alla personers ansvarsområden och fungera som en gemensam länk mellan dessa. Detta sätt att styra projektet förutsätter dock att alla tar ett stort ansvar. Problemen som vi ser med detta inträffar om någon eller några personer inom projektet inte tar sitt ansvar och således inte gör det de förväntas göra. Vi bedömer sannolikheten för att detta ska inträffa som mellanstor men tillfogar att det är projektledarens roll att mana på de personer som försöker smita undan. Effekten av att deltagare smiter undan kan dock bli stor beroende på i vilken utsträckning de smiter undan. 4.2.4 Risker kring gruppdynamiken Risker kring gruppdynamiken innefattar t.ex. osämja, bråk, irritation inom gruppen samt att gruppen drar åt olika håll och personer smiter undan och inte gör det de tar på sig att göra. Orsakerna till problem med gruppdynamiken är således många. Inom vår grupp känner några personer varandra sedan tidigare, men som gemensam grupp är vi oprövad. Vi är således inte helt säkra på hur det kommer att gå men gruppen känner än så länge inte av några samarbetsproblem eller problem med gruppdynamiken. Vi bedömer dock sannolikheten för att det kan komma att bli problem med gruppdynamiken som mellanstor. Detta beror på att vi alla inom gruppen förmodligen kommer att känna oss ganska stressade i slutet av projektet, beroende på om vi räknat och planerat rätt med arbetsbördan och tidsåtgången. Detta kan då i sin tur påverka gruppmedlemmarna negativt. Effekten som detta kan få på arbetet bedömer vi som mellanstor med lutning åt ganska liten effekt. Detta kommer sig av att vi alla är medvetna om att vi måste få ihop projektet för att få godkänt på kursen, oavsett om vi blir lite griniga på varandra mellan varven. 4.2.5 Kunskapen Risker med kunskapen innefattar både förkunskaper och kunskaper som projektdeltagarna behöver införskaffa under projektets gång. I detta projekt finns det i huvudsak två 11

kompetensinriktningar utspridda på de fem deltagare som deltar i projektet. Kompetensinriktningarna härstammar från blivande civilingenjörer inom datateknik och industriell ekonomi med inriktning mot programvarudesign. Riskerna som vi ser med detta är att vi kanske inte har tillräckligt med kompetens för att kunna genomföra projektet med den omfattning som uppdragsgivarna ursprungligen hade tänkt sig. Detta beror i sin tur på att vi endast är fem stycken, när det är tillåtet att vara åtta personer i projektet. Det är också tveksamt hur mycket förkunskaper inom programmering som verkligen kommer att krävas av projektdeltagarna och därför ser vi denna punkt som en tänkbar risk inom projektet. Sannolikheten för att vi ska drabbas av problem p.g.a. otillräckliga kunskaper betraktar vi dock ändå som ganska osannolik (d.v.s. liten). Detta eftersom vi är ett projektteam bestående av mycket ambitiösa och lättlärda personer som är fast beslutna att genomföra ett lyckat projekt. Kunskapsproblemen kan dock bli högst påtagliga om någon av projektdeltagarna skulle försvinna ur projektet (se punkt ovan). Effekterna på arbetet, om denna risk inträffar, är helt enkelt att projektet kommer att ta längre tid. Vi räknar dock med att tidigt ta kontakt med beställarna om vi får problem inom detta område. 4.2.6 Risker med hårdvaran Risker med hårdvaran som vi använder skulle kunna röra sig om en eventuell krasch på Nadas datorer. Denna risk bedömer vi dock som mycket liten. Utöver detta kanske någon av oss testar en del av programmeringen i hemmet. Där är om möjligt risken för fel på hårdvaran större, men eftersom den största delen av programmeringen i projektet kommer att utföras i skolan så bedömer vi sannolikheten för att vi kommer att få hårvaruproblem som mycket liten. Effekterna av ett hårdvaruproblem skulle inte kunna äventyra vårt projekt i någon större bemärkelse eftersom samtliga projektdeltagare även har tillgång till datorer i hemmet, som vi i nödfall kan använda. 4.2.7 Risker med mjukvaran Risker med mjukvaran skulle t.ex. kunna vara att de olika programmeringsmiljöerna som vi eventuellt kommer att använda oss av inte är riktigt kompatibla med varandra. En del av oss är t.ex. vana att använda Eclipse medan andra gärna använder Emacs. Vi vet inte än om detta kommer att medföra några problem. Vi bedömer dock sannolikheten för denna risk som ganska liten eftersom vi inte fått några sådana indikationer under den övriga utbildning på KTH, och i händelse av komplikationer kommer vi förmodligen att använda oss av en och samma miljö. Effekterna av detta skulle inte nämnvärt påverka projektet mer än att det skulle ta lite mer tid än beräknat att hitta en ny gemensam programmeringsmiljö som fungerar. Här kan vi dock få mycket hjälp av våra beställare. 4.3 Åtgärder Nedan ges gemensamt diskuterade förslag på hur vi inom projektgruppen ska kunna minimera och kanske eliminera sannolikheten att dessa risker inträffar och/eller begränsa effekterna som de kan ge. 4.3.1 Avgränsning av projektet För att begränsa sannolikheten att vi räknar för snävt på tidsåtgången för själva programmeringen, och de övriga delarna i projektet, har vi beslutat att så snabbt som möjligt komma igång med den praktiska delen av projektet. Detta innebär att vi innan 12

tentamensveckan (period 3) på KTH enskilt kontrollerar vissa tilldelade programmeringsområden, och direkt efter tentamensveckan ska komma igång med själva programmeringen. Vi kommer också att ha regelbundna möten varje vecka för att hålla schemat justerat och uppdaterat. 4.3.2 Personliga risker med projektdeltagarna Personliga risker med projektdeltagarna är det inte mycket vi kan göra för att minimera mer än att regelbundet hålla kontakten och försöka peppa varandra att fortsätta jobba med projektet. Projektdeltagarna kommer också att regelbundet rapportera eventuella förhinder. 4.3.3 Problem med projektstyrningen För att minimera problem med projektstyrningen har gruppen bestämt att alla projektdeltagare ska ta sina ansvarsområden på allvar och tidigt säga till om något är fel. Detta kan t.ex. inbegripa att någon känner att den fått för mycket att göra i förhållande till de andra deltagarna, eller på annat sätt känner sig missnöjd. Även projektledaren har meddelat att han tänker hålla ett extra vakande öga på hur det går för gruppen, och därmed även göra vad han kan för att så tidigt som möjligt stävja olika problem som kan tänkas uppstå. 4.3.4 Problem kring gruppdynamiken För att minimera risker och problem kring gruppdynamiken kommer projektgruppen att regelbundet ordna möten och försöka hålla en regelbunden kontakt med varandra så att vi snabbt kan få reda på om problem dyker upp inom detta område. Vi kommer även att tydligt försöka klargöra vilka ansvarsområden som var och en av oss har. Projektdeltagarna har även beslutat att vi alla ska tänka på att dessa typer av problem kan uppstå och därför i ett tidigt skede ta upp relaterade frågor till diskussion. 4.3.5 Kunskapsproblem För att minimera eventuella kunskapsproblem har samtliga projektdeltagare beslutat att var och en ska ta ansvar för att lära sig de tilldelade delar av systemet som vi åtagit oss att göra. Utöver detta ska var och en även sätta sig in i koden som vi fått av våra beställare samt tillsammans försöka lösa eventuella problem som ändå kan tänkas uppstå inom detta område. Detta kommer att göras med hjälp av god samarbetsförmåga. 4.3.6 Hårdvaruproblem Eftersom vi inte bedömer att denna punkt är någon större risk har vi inte heller någon speciell riskhantering av detta område. 4.3.7 Mjukvaruproblem För att minimera problem med mjukvaran tänker vi tidigt testa om de olika programmeringsmiljöerna som vi tänker använda oss av är kompatibla med varandra. Om de inte är det har vi beslutat att gemensamt komma överens om en utvecklingsmiljö som vi ska använda oss av. Övriga åtgärder för att förhindra fel som kan uppstå genom mjukvaran är relaterade till åtgärder för kunskapsproblem (se tidigare punkt). 13

Referenser [1] Lenman, S., Bretzner, L. & Thuresson, B. Using Marking Menus to Develop Command Sets for Computer Vision Based Hand Gesture Interfaces. [2] Kurtenbach, G. & Buxton, W. (1993) The Limits Of Expert Performance Using Hierarchic Marking Menus. Interchi 93 [3] Guimbretière, F. & Winograd, T. (2000) FlowMenu 14