TJOHO - LEK OCH TRÄNING FÖR BARN PROJEKTSPECIFIKATION FEBRUARI 2003 Uppdragsgivare: Ylva Dalén, KI Starthus Projektmedlemmar: Sofia Demnert Elina Eriksson Kamilla Johansson Per-Jonny Käck Ingela Linered Åsa Moum Michael Stockman Stefan Trolle
Inledning I det här dokumentet definierar vi vårt projekt, bakgrund, problemdefinition och exakt vad som ska göras. För att göra texten lättförståelig så har vi bifogat en ordlista sist i dokumentet. Innehållsförteckning 1. Problembeskrivning... 2 1.1 Bakgrund... 2 1.2 Syfte... 2 1.3 Krav och avgränsningar... 2 2. Förslag till lösning... 4 2.1 Systemskiss... 4 2.1.1 Moduler... 5 2.2 Skiss av användargränssnittet... 7 3. Genomförande... 8 3.1 Systematisk metod... 8 3.2 Ansvarfördelning... 8 3.3 Tidsplanering... 9 3.4 Administration... 10 3.5 Dokumentation... 10 4. Risker... 11 Tidsplanering... 11 Gruppen... 12 Beställaren... 14 5. Ordlista... 15 1
1. Problembeskrivning 1.1 Bakgrund Tjoho är en del av ett större projekt på KI Starthus under ledning av Ylva Dalén. Ylva har arbetat med att uppfinna en apparat som ska motverka benskörhet hos gravt handikappade barn som inte själva kan stå eller gå. Denna apparat kallas för Hoppolek. Barn som inte kan stå självständigt, ordineras ett s.k. ståskal, ett formgjutet plastskal som fästs runt barnet och ger möjlighet till upprättstående ställning. I Hoppolek står barnet på en vibrationsplatta och genom knapptryckningar kan barnet själv åstadkomma rörelser i den egna kroppen. Tanken är att Hoppolek ska hjälpa till att stärka barnens skelett och normalisera muskeltonus (spasticitet). Tanken är också att det ska finnas olika svårighetsgrader för olika barn, samt att barnen ska ha roligt samtidigt som de gör något nyttigt! Det gäller att förena nytta med nöje! 1.2 Syfte Det finns två mål med projektet. Det ena är att vi i projektgruppen ska lära oss att arbeta i projekt med många inblandade och med en extern uppdragsgivare. Det andra målet är att vi ska utveckla en välstrukturerad programvara, för den framtida produkten Tjoho. Produkten Tjoho kommer att bestå av den programvara vi ska uveckla samt en en maskin som ej är konstruerad än. Interaktionen mellan applikation och maskin kommer att prioriteras framför antalet funktioner i applikationen. Eftersom det resultat vi främst vill uppnå med vårt projekt är att skapa möjligheter för gravt rörelsehindrade barn att träna samtidigt som de har roligt, kommer vår programvara om möjligt, och i mån av tid, innehålla moment med musik och/eller dans. 1.3 Krav och avgränsningar Vårt främsta mål är att få hela systemet att fungera rakt igenom och att visa detta med en enklare applikation. Förutsättningarna för vårt projekt är att maskinen Tjoho ska kunna styras helt via PC, samt att vår systemgräns är datorns serieport. 2
1.3.1 Funktioner för slutanvändarna (alltså barnen) Den fysiska maskinen Tjoho kommer att stödja funktionerna: -Plan rotation -Höjning och sänkning, förmodligen via två bälgar på undersidan -Lutning, via asymmetrisk fyllning av bälgarna -Vibration, med frekvensreglering -Hopp, dvs hastigare tömning av bälgarna Vår applikation kommer dock endast att stödja funktionen höjning/sänkning (hopp) genom att visa en boll som studsar på skärmen och samtidigt styra maskinens ståplatta upp och ner i takt med bollen. 1.3.2 Datormiljö Hoppolek styrs idag av någon slags styrenhet, och det kommer även maskinen Tjoho att göra. Vår programvara kommer att köras på en fristående dator och kommunicera med maskinen via datorns serieport. Det innebär att när barnen vill träna med hjälp av Tjoho, så kommer maskinen Tjoho att placeras vid en dator med programvaran Tjoho installerad. Barnen kan sedan styra applikationerna med hjälp av maskinen Tjoho, t ex genom knappar. Programvaran Tjoho kommer huvudsakligen att vara skriven i Java. 1.3.3 Användare Användarna av vår produkt är gravt rörelsehindrade barn i åldern 4-7 år, samt personer i deras omgivning. 3
2. Förslag till lösning Utgående från de funktioner som Tjoho ska ha, så har vi bestämt att dela upp programsystemet i två delar. En del är de applikationsprogram som barnen och övriga användare ska interagera med när de använder plattformen eller förbereder plattformen för användning. Den andra delen ska hantera kommunikationen med den fysiska utrustningen och göra det enkelt att skriva bra applikationsprogram som enkelt kan konfigureras för att samverka i komplexa mönster. 2.1 Systemskiss Systemskissen visar de konceptuella lager som systemet baseras på och kommer att interagera med på en PC. Dessa är: Den fysiska hårdvaran som systemet körs på. Datorsystemets operativsystem. Javas virtuella maskin. Communication & Resource Manager är en del av systemet som sköter vissa systemtjänster åt framförallt Platform Control/Monitor Software. Platform Control/Monitor Software består egentligen av någon uppsättning applikationsprogram som kan hantera insignaler från plattformen eller generera styrkommandon till plattformen. Platform Simulation är ett utvecklingsverktyg som via Communication & Resource Manager kan visa vilket tillstånd plattformen skulle befinna sig i samt generera samma signaler som plattformen. 4
2.1.1 Moduler 2.1.1.1 Communication & Resource Manager Ett serverprogram som kommunicerar direkt med plattformen och publicerar dess funktioner som tjänster som olika applikationsprogram kan öppna och sedermera få meddelanden när det händer något intressant eller skicka styrkommandon till. 2.1.1.1.1 Java Communications API Interface, jcapi En del av CRM som via Java Communications API, javacomm, omvandlar data skickade från plattformen till händelseobjekt och lägger dessa i CRMs inkö. Den omvandlar också styrkommandon från CRM till plattformsformat och skickar dessa via javacomm till plattformen. 2.1.1.1.2 PC/MS Communications Interface, crmsrv En del av CRM som tar emot kommandon från olika PC/MS via TCP/IP och skickar tillbaka svar eller notifieringar när plattformshändelser har inträffat. 2.1.1.1.3 Platform Tracking Utility, tracking En del av CRM som lagrar information om hur plattformens funktioner har använts på ett sätt som är kompatibelt med Tjoho. 2.1.1.1.4 PC/MS Client Configuration, configuration Håller reda på att insignaler från plattformen och PC/MS passar ihop med utsignalerna. Ska tillhandahålla en uppsättning signalomformare som görs automatiskt åt PC/MS, för knappsignaler bestående av: ON/OFF klick Max pulslängd, begränsning med minst sekundupplösning OCH ELLER Ska spara de inställningar som görs. Ska kunna identifiera en uppsättning anslutna PC/MS och från dessa hitta hur de var konfigurerade senast för den aktuella användaren. Bör göra något intelligent om den inte har sett någon kombination tidigare. 2.1.1.1.5 PC/MS Client Communications Interface, crmclient Används av PC/MS och PS för att kommunicera med crmsrv. Ska tillhandahålla en standardiserad dialogruta för att konfigurera CRM med ansluten PC/MS. 2.1.1.2 PC/MS: Signal bouncer 2.1.1.3 PC/MS: Particle simulation generator 2.1.1.4 Application Communication Layer Består av en del biblioteksfunktioner för att sända och ta emot fördefinierade data i applikationen. Kommunikationen sker genom Flashs inbyggda XMLSocket objekt. 5
2.1.1.5 Bouncing Ball Application En applikation i Flash som visar en studsande boll på skärmen. Applikationen styr sedan maskinens ståplatta upp och ner i takt med bollen via anrop till funktioner i applikationens kommunikationslager. 2.1.1.6 Platform Simulation 2.1.1.6.1 Platform visualization utility En del av PS som på en bildskärm kan visa plattformens olika tillstånd och ta emot motsvarande signaler från användaren. 2.1.2 Diagram Visar hur en PC/MS utifrån kan betraktas som en transformation på några insignaler till några utsignaler. Dessa kan till exempel vara knapptryckningar på plattformen som styr motorer på plattformen. 6
2.2 Skiss av användargränssnittet Ett exempel på hur man grafiskt kan göra ett standardiserat användargränssnitt i CRM CCI för grafisk konfiguration av hur PC/MS interagerar med plattformen. 7
3. Genomförande 3.1 Systematisk metod Vi tänkte genomföra projekt Tjoho enligt PPS-metoden som Börje Törnblom från TietoEnator föreläst om. Eftersom metoden i sig är ganska omfattande och skaparna själva tycker att man ska gå en utbildning i det hela, kommer vi följa de mallar som vi tycker passar vårt projekt. Vi kommer att arbeta enligt de beslutspunkter som finns i PPS-metoden där de tre första kommer att vara avklarade i och med detta dokument. Enligt PPSmetoden har vi redan passerat beslutspunkt fyra där beslut om genomförande av projektet fattas. Hädanefter följer ett antal avstämningspunkter och i slutet av projekt har vi några beslutspunkter för att avsluta och lämna ifrån oss projektet till Ylva Dalén. Eftersom PPS-metoden inte beskriver implementationsarbetet i detalj har vi bestämt oss för att också använda oss av Extreme Programming där det är möjligt. Största tyngdpunkten kommer att läggas på kontinuerlig integrering, enkel design och användning av en kodstandard. Vårt projekt bygger på, precis som i Extreme Programming, motiverade individer som kommer att ha nära samarbete och riklig kommunikation. 3.2 Ansvarfördelning Inom projekt Tjoho har vi delat in arbetet enligt följande: En projektledare och en vice projektledare som tillsammans ansvarar för schemaläggning, tidsplanering och att projektet håller deadlines. Dessa två kommer också att ansvara för projektets kontakter utåt. En redovisningsansvarig som ansvarar för planeringen av redovisningarna av projektet. Denna person har också ansvar för att tid och lokal bokas för dessa tillfällen. En informationsansvarig som ansvarar för webben. Informationsansvarig är också ansvarig för all dokumentation. En resource manager som är ansvarig för att definiera och implementera ett gränssnitt mellan maskin och applikationer. En application manager som ansvarar för implementeringen av applikationerna. En simuleringsansvarig som ansvarar för att det går att testa applikationerna i ett simuleringsprogram så att man kan se vad som händer vid olika knapptryckningar. 8
3.3 Tidsplanering V. 5-9 Planering av projektet. Studiebesök på en specialförskola. Projektet definieras och en projektspecifikation skrivs. Projektdeltagarna delas in i olika arbetsgrupper och ansvarsområden delas ut. De olika delarna av programmet fastställs, dvs vilka funktioner programmet ska ha. Beräknad tidsåtgång: 20 timmar/projektmedlem varav 10 timmar inbokade möten. Utöver projektets tid ska projektmedlemmarna närvara vid föreläsningar, sammanlagt 18 timmar. V.10-14 030304 Inlämning av projektspecifikation. 030317 Besked om projektspecifikation. 030404 Bokning av redovisningstider. Implementation av de olika delarna i projektet. Löpande arbete med dokumentationen. Beräknad tidsåtgång: 90 timmar/gruppmedlem varav 7,5 timmar inbokade möten. Detta innebär ca 16,5 timmar eget arbete i veckan. V.15 Testning av programmet. Slutförande av dokumentationen. Förberedelser inför redovisningen. Beräknad tidsåtgång 20 timmar/projektmedlem varav 1,5 timmar inbokade möten. V.16 Påsklov V.17-21 Obs, omtentaperiod v. 17-18. Förhandsredovisning 2 timmar/projektmedlem. Arbete på oppositionsrapport 5 timmar/projektmedlem. Slutredovisning 6 timmar/projektmedlem. 9
3.4 Administration Kontinuerligt under projektet kommer gruppen mötas som helhet och diskutera framgång, problem och lösningar. Den återkommande mötesstiden är på måndagar 15.00-16.30, men kan komma att ändras under projektets gång. Varannan måndag medverkar Ylva Dalén, initiativtagare till projektet. Projektledaren eller vice leder mötet och en sekreterare utses vid varje möte. Mötesanteckningarna mailas ut till projektdeltagarna och läggs upp på webben. 3.5 Dokumentation Informationsansvarige ansvarar för all dokumentation och delegerar till lämplig projektmedlem att skriva olika delar och ser till att alla delar blir färdiga i tid. Den största delen av dokumentationen skrivs löpande under arbetets gång men vissa delar är svåra att göra klart innan all implentation är klar. 10
4. Risker Här nedan presenteras riskanalysen som vi sammanställt. Tidsplanering Den första delen av riskanalysen rör till största delen planeringen av tiden för projektets utförande a.. Felplanerad tidsplan Effekt: Det som en felaktig tidsplan kan leda till är i värsta fall att projektet inte blir slutfört enligt specifikation, men det kan också leda till att arbetsbördan på projektmedlemmarna blir alldeles för stor i slutet av projektet. Sannolikhet: Hög Åtgärd: Det man kan göra för att undvika det är att så mycket som möjligt ta reda på hur lång tid de olika delarna tar och att noga gå igenom vilka delar som finns i projektet så att man inte har missat någon del. Under projektets gång är det sedan viktigt att följa upp tidsplanen och kontrollera att de olika delarna blir gjorda i tid. b.. Nyckelperson blir sjuk eller prioriterar annat som tex. annan kurs, resa. Effekt: Nödvändig kunskap försvinner från projektet under kritisk period och vi måste omfördela resurserna i projektet. Detta leder till högre arbetsbelastning för de övriga i projektet. Sannolikhet: Medel Åtgärd: Genom att ingen arbetar ensam med någon del kan man också undvika att projektet misslyckas för att någon projektmedlem försvinner ut ur gruppen. c.. Att vi har förbisett något moment i utvecklingen eller att någon teknisk detalj visar sig senare vara mycket svår Effekt: Vår tidplan måste göras om och projektet kan haverera beroende på omfattningen av momentet. Sannolikhet: Medel Åtgärd: Genom att grupperna i projektet hela tiden stämmer av arbetet och förutsättningarna för respektive del av projektet. Viktigt att bibehålla öppen kommunikation mellan grupperna. 11
d.. Att implementeringen går för långsamt i början och vi får en stor arbetsbörda på slutet Effekt: Projektet kan haverera. Sannolikhet: Låg Åtgärd: Veckomöten där vi stämmer av tidplanen för varje grupp. e.. Tidsbrist vid testning Effekt: Vi kan stå utan en fungerande produkt vid tänkt leverans Sannolikhet: Låg Åtgärd: Kontinuerlig integrering av kod enligt Extreme Programming. Vi börjar med att utveckla en funktion som vi testar att den fungerar för att sedan bygga ut produkten efter hand. f.. Skjuter upp arbetet med dokumentation för länge Effekt: Vi står utan dokumentation vid slutlig presentation som förbundit oss till i specifikationen. Vi får restuppgift i kursen att slutföra dokumentationen. Sannolikhet: Låg Åtgärd: Vi har en person som är ansvarig för dokumentationen och som kontinuerligt uppdaterar vår hemsida. g.. Att vi väljer en programvara som inte löser problemen som förväntat Effekt: Vår tidplan håller inte och vi måste planerar om. Det leder till ökad arbetsbelastning och eventuellt kan projektet haverera. Sannolikhet: Medel Åtgärd: Hela tiden hålla en öppen kommunikation mellan grupperna med eventuella krav och problem. Gruppen En annan stor riskfaktor är missförstånd mellan gruppmedlemmarna. a.. Missförstånd inom gruppen Effekt: Vi missar moment eller tekniska svårigheter som förblir olösta eller får till följd att projektet inte håller tidplanen. Vi måste då omprioritera och arbetsbelastning ökar och projektet kan haverera. Sannolikhet: Hög Åtgärd: Öppen kommunikation mellan gruppmedlemmarna på veckomöten där alla får komma till tals. Tydlig fördelning och delegering av arbetsuppgifter. Projektledaren har en noggrann uppföljning av projektledaren av arbetsgången. 12
b.. Ägnar för mycket tid åt att förstå varandra av rädsla för missförstånd Effekt: Projektet håller inte tidplanen och vi måste omprioritera. Det kan leda till högre arbetsbelastning och att projektet kan haverera. Sannolikhet: Hög Åtgärd: Öppen kommunikation mellan gruppmedlemmarna. Att projektledaren är observant på otydligheter och tar upp dessa på veckomötena. c.. För dålig kommunikation inom gruppen så att onödig konflikter uppstår genom missförstånd Effekt: Projektet håller inte tidplanen och vi måste omprioritera. Det kan leda till högre arbetsbelastning och att projektet kan haverera. Sannolikhet: Hög Åtgärd: Öppen kommunikation mellan gruppmedlemmarna. Att projektledaren är observant på otydligheter eller tecken på konflikter och tar upp dessa på veckomötena. Att alla gruppmedlemmar verkar för öppen kommunikation och att lösa eventuella konflikter. d.. Mörkläggande av konflikter inom gruppen Effekt: Projektet håller inte tidplanen och vi måste omprioritera. Det kan leda till högre arbetsbelastning och att projektet kan haverera. Sannolikhet: Låg Åtgärd: Öppen kommunikation mellan gruppmedlemmarna. Att projektledaren är observant på otydligheter eller tecken på konflikter och tar upp dessa på veckomötena. Att alla gruppmedlemmar verkar för öppen kommunikation och att lösa eventuella konflikter. e.. Att de olika delarna inom projektet inte kommunicerar tillräckligt med varandra under projektets gång och att det då blir ett stort jobb att få ihop allt på slutet. Effekt: Projektet håller inte tidplanen och vi måste omprioritera. Det kan leda till högre arbetsbelastning och att projektet kan haverera. Sannolikhet: Medel Åtgärd: Öppen kommunikation mellan gruppmedlemmarna. Att projektledaren och alla gruppmedlemmar verkar för öppen kommunikation vid veckomötena. 13
Produkten Ytterligare en riskfaktor är att vi inte tillverkar ett program som är lämpligt till den tänkta användaren, det gäller både barnen och den som hjälper dem med att komma igång med maskinen. a.. Att vi underskattar eller överskattar barnens förmåga. Att barnen inte tycker det är roligt eller att förskolepersonalen inte förstår programmet. Effekt: Att beställaren inte är nöjd med den produkt vi levererar. Sannolikhet: Låg Åtgärd: Kontinuerlig avstämning med beställaren och kontaktföräldrar. Vi kan också kontakta specialförskolan där vi tidigare var på studiebesök. Beställaren Den sista risken som finns med i riskanalysen är att det kommer nya krav från beställaren eller att de inblandade byter inställning till projektet och vi inte får den hjälp vi har förväntat oss. a.. Ändrade direktiv från beställare eller annan person som har med projektet att göra Effekt: Projektet håller inte tidplanen och vi måste omprioritera. Det kan leda till högre arbetsbelastning och att projektet kan haverera. Sannolikhet: Medel Åtgärd: Klart redogöra för beställaren för den specifikation vi har, våra resurser och vad målet med projektet är, enligt vår uppfattning. Det man kan göra för att undvika detta är att skriva en ordentlig projektspecifikation och se till att alla inblandade har klart för sig att det är den som gäller. b.. Att Anders Andersson byter inställning till projektet Effekt: Förutsättningarna för oss att genomföra projektet enligt den tidplan och den specifikation vi har minskar betydligt. Det kan leda till högre arbetsbelastning och att projektet havererar. Sannolikhet: Medel Åtgärd: Öppen kommunikation med beställaren som i sin tur pratar med Anders Andersson. c.. Missförstånd mellan gruppen och beställaren Effekt: Projektet håller inte tidplanen och vi måste omprioritera. Det kan leda till högre arbetsbelastning och att projektet kan haverera. Sannolikhet: Låg Åtgärd: Öppen och kontinuerlig dialog med beställaren. Avstämning av resultat i projektet. Det man kan göra för att undvika detta är att skriva en ordentlig projektspecifikation och se till att alla inblandade har klart för sig att det är den som gäller. 14
5. Ordlista Applikation: Ett program som innehåller funktioner avsedda att användas direkt av användaren till skillnad från tex kommunikationsprogram som utför inre arbete. Biblioteksfunktioner: En samling funktioner som tillsammans kan sköta uppgifter inom ett visst område, alltså ungefär samma sak som en modul. Används oftast för att förenkla implementering på en högre nivå genom att dölja en del tekniska bitar. På så vis bidrar alltså biblioteksfunktionerna till en högre abstraktionsnivå för den som använder dem. CRM - Communication & Resource Manager: Applikation som man vänder sig till för att kommunicera med plattformen. CRM CCI - CRM Client's Communication Interface: Klientens, dvs applikationens, gränssnitt mot CRM applikationen. Extreme Programming: Ett sätt att bedriva programmeringsprojekt. Tyngdpunkten ligger på att man kontinuerligt ska testa och dokumentera sitt program. Flash: Ett grafik- och animeringsprogram från företaget Macromedia. Java: Ett programmeringsspråk. Java Communications API Interface: Ett gränssnitt för att kommunicera med plattformen. PC/MS Client Configuration: Beskrivning av nuvarande och möjliga konfigurationer av de kommunikationskopplingar som styr och beskriver plattformens beteende. PC/MS Communications Interface: Ett gränssnitt för att kommunicera med klientprogrammen. PC/MS - Platform Controller/ Monitor Software: Applikationsprogram som interagerar med plattformen via CRM servern. Även kallad klient. 15
Platform Tracking Utility: Den del som loggar användarens utnyttjande av plattformen. Plattform: Den blivande Tjoho, eller senare versioner av samma maskin. PPS: En metod för att arbeta i projekt. Man delar upp arbetet i åtta olika beslutspunkter. PS Platform Simulation: Applikation som simulerar plattformens beteende. Serieport: En slags kontakt på datorn till vilken man kan koppla olika enheter, t ex ett modem eller maskinen Tjoho. TCP/IP: Transmission Control Protocol/Internet Protocol. Två kommunikationsprotokoll som ofta används tillsammans. Protokollen består av en uppsättning regler för kommunikation mellan olika enheter. XMLSocket objekt: Ett objekt i Macromedia Flash som gör det möjligt för program i Flash att kommunicera med andra program via något slags nätverk (över TCP/IP), på ungefär samma sätt som en webbläsare kommunicerar med en webbserver för att visa en webbsida. 16