ÅTERSTÅENDE PROBLEM MultiPC v1.0 Rev 7 1(7) BILAGA E till Programvaruprojekt ÅTERSTÅENDE PROBLEM MultiPC v1.0 Här listas problem som kan behöva hanteras i kommande inkrement. De prioriteras alltså ner inom ramen för det första inkrementet. Dokumentet bör utökas med problem eller goda idéer som dyker upp, och prioriteras ner, vid det fortsatta arbetet. Dokumentets roll är att fungera som diskussionskatalysator inför arbetet med inkrement 2. Innehållsförteckning 1. ALLMÄNT...3 2. REFERENSER...3 3. TERMINOLOGI...3 4. RELATION TILL ANDRA DOKUMENT...3 5. FÖR MÅNGA FÖNSTER...3 6. ALL KONTROLL AV EMAIL PÅ SERVERSIDAN...3 7. INGA BILDER, INGET LJUD...3 8. OMSTART FÖR NY ELEV...3 9. STATISTIKKURVOR...4 10. SPRÅKGRANSKNING...4 11. FELMEDDELANDEN VID HÖG UPPLÖSNING...4 12. TA BORT ELEV...4 13. STATISTIK - SKA FRAMGÅ...5 14. INGA SVENSKA ALT-KOMBINATIONER...5 15. MODIFIERA PC-PROGRAM...5 16. MANUELL VERSIONSHANTERING...6 17. BEROENDE MULNAMES -> MULTIPC...6 18. BAKÅTKOMPATIBILITET...6 19. TEST AV AVINSTALLATION...6 20. FOTON OCH EMAIL...6 21. TEST AV TALGRÄNSER...6
ÅTERSTÅENDE PROBLEM MultiPC v1.0 Rev 7 2(7) 22. MÅNGA PARAMETRAR...7 23. INKLIPPTA DIAGRAM OCH PROGRAMKOD...7
ÅTERSTÅENDE PROBLEM MultiPC v1.0 Rev 7 3(7) 1. ALLMÄNT Det här dokumentet ska beskriva kvarstående problem och goda idéer för MultiPC-systemet. 2. REFERENSER [ANVDOK] Lindegren, Håkan: MultiPC v1.0: Användarkrav. [DETDOK] Lindegren, Håkan: MultiPC v1.0: Detaljkrav. [TESTPLAN] Lindegren, Håkan: MultiPC v1.0: Testplan. [DESSPEC] Lindegren, Håkan: MultiPC v1.0:designspecifikation. 3. TERMINOLOGI Avsiktligt lämnad tom. 4. RELATION TILL ANDRA DOKUMENT Problemdata förs över hit från samtliga övriga dokumenttyper. Återstående problem ska fungera som indata till upprättande av krav inför efterföljande inkrement. 5. FÖR MÅNGA FÖNSTER Det känns som att det dyker upp fönster lite kors och tvärs. Kanske ska man visa mer information i själva träningsfönstret? Å andra sidan kan det förvirra elever som är stresskänsliga. Kanske olika moder för olika elever? Nybörjare, medel, expert. 6. ALL KONTROLL AV EMAIL PÅ SERVERSIDAN Webbplats Användaren fyller i email och lösenord för att bli medlem. Data skickas till servern för kontroll. Viss kontroll skulle kunna göras på klientsidan, t.ex. av uteblivna data och format Kontroll skulle kunna göras av skript i HTML-koden. Fördelen med att lägga kontroller i klienten är att det går snabbare och servern belastas mindre. Nackdelen är att det kräver att klienten klarar av, och tillåter, att skript körs lokalt. 7. INGA BILDER, INGET LJUD Det är ett program för barn. Inget barn kommer att tycka att det är någon vidare action. Problemet behöver analyseras i samband med användning av v1.0. Red ut vad barnen tycker och vill ha. Granska hur viktigt kravet på installationsfil <= 2MB är. Eventuella bilder eller ljud bör däremot kunna stängas av med tanke på stresskänsliga elever. 8. OMSTART FÖR NY ELEV Då ny elev ska köra måste MultiPC avslutas och startas om. Man borde kunna aktivera Startfönstret från Träningsfönstret och välja en annan elev.
ÅTERSTÅENDE PROBLEM MultiPC v1.0 Rev 7 4(7) Ja, det här verkar som att det ska göras. En knapp e.d. i Träningsfönstret får helt enkelt aktivera Startfönstret. 9. STATISTIKKURVOR Statistiken visas endast i textform. Det borde väl snarare vara kurvor, staplar e.d. Osäkert om kurvor, pajdiagram eller annat blir bra. Bild, ljud och färger är alternativ som behöver undersökas. Men kom ihåg att också de som har problem med färgseende eller hörsel ska kunna använda och förstå programmet. 10. SPRÅKGRANSKNING Webbplats, Granskningen av språket blir tungrodd, både med avseende på webbplatsen och programmet. Kan vi hantera det bättre genom att utnyttja Word e.d. för all generering av text? Punkten bör redas ut så att vi undviker språkfel. Kanske bör läsa textsträngar från en infil, kontrollerad av Word? Kanske bör webbplatsen konstrueras som ASP-filer som läser vad som ska presenteras från infiler, kontrollerade av Word? Det tar lite tid att utveckla ett sådant grundsystem, hanteringsmässigt ger det stora fördelar på sikt. Vill vi översätta till flera språk ger det oss en klar fördel. 11. FELMEDDELANDEN VID HÖG UPPLÖSNING Hur testa att felmeddelanden ser bra ut? Såsom testplanen ser ut nu testas en del av de felsituationer som kan uppstå. De testas däremot endast i en bekväm upplösning. Kommer de att se bra ut även vid andra upplösningar? Problemet är generellt. Samtliga felsituationer kommer troligen aldrig att testas via testplanen. Ändå vill vi veta att samtliga felmeddelanden ser bra ut. En lösning på problemet kan vara att föra in en testmod där man kan stega igenom samtliga felmeddelanden som kan dyka upp. Det förenklar också tester av att utgångar till hjälpsystemet är riktiga. 12. TA BORT ELEV Nog borde det väl gå att ta bort elever? Ja, det bör det göra. Frågan är om det ska gå att ta bort elever via Träningsprogrammet eller om det bara ska kunna göras via ett lösenordsskyddat lärarprogram. Eller ska samtliga elever ha egna lösenord? Vilket beslutet än blir får man hanteringsmässiga problem. Hur ska glömma lösenord hanteras? Det bör gå att göra undelete på elever, hur långt tillbaka? Säg att beslutet blir två olika program och kravet på storlek <= 2 MB kvarstår. Då bör de båda programmen länkas ihop till en enda EXE-fil som startas med en parametrar som styr vilket av programmen som ska köras.
ÅTERSTÅENDE PROBLEM MultiPC v1.0 Rev 7 5(7) 13. STATISTIK - SKA FRAMGÅ I Detaljfönstret ska det framgå vilka svar som var rätt och vilka som var fel, som i figur 13.1. Behövs det någon extra markering? Det korrekta svaret står ju ändå överst. Se vidare kraven under 150. Det här fönstret ser inte speciellt bra ut. Är informationen överhuvudtaget av intresse? Ska MultiPC i en framtid kunna visa trender för hur svaren har sett ut på specifika tal? Problemet är nog inte om det ska vara en markering eller inte, ska fönstret vara kvar eller inte? Red ut i samband med användningen. Figur 13.1: Detaljstatistikfönster 14. INGA SVENSKA ALT-KOMBINATIONER Kravet avser att det inte ska förekomma några alt-å, alt-ä eller alt-ö som alternativ till att klicka med musen. Enligt testplan ska kravet testas genom manuell granskning. Ineffektivt och stor risk för fel. Kravet är svårt att testa på samma sätt som det är svårt att testa att alla felmeddelanden ser bra ut. En testmod, eller att alla strängar ligger i infiler, kan vara lösningen. Ett annat närliggande problem är att alt-kombinationer kan krocka med varandra. Det problemet bör också lösas i samband med att man reder ut hur strängar och alt-kombinationer ska testas. 15. MODIFIERA PC-PROGRAM Det blir många manuella steg för att från kodmodifiering bygga en installationsfil. Det vore bra om man kunde köra kompilering, länkning, installationsbygge och hoppackning från ett skript. Ja, problemet ska lösas. Antingen via skript eller via inköp av bättre verktyg.
ÅTERSTÅENDE PROBLEM MultiPC v1.0 Rev 7 6(7) 16. MANUELL VERSIONSHANTERING Webbplats, Man borde väl ha ett verktyg för att sköta versionshantering, typ RCS eller CVS? Ja. Problemet bör prioriteras högt inför det andra inkrementet. 17. BEROENDE MULNAMES -> MULTIPC, testprogram MULNAMES, som ska generera namnfiler för testning, kommer delvis att utnyttja kod i MultiPC. Hur ska det hanteras? Red ut problemet. Troligen behövs det en COMMON-katalog för kod som delas av flera program. Om det dessutom ska utvecklas två olika program för elever respektive lärare blir problemet påtagligt. 18. BAKÅTKOMPATIBILITET Ingen hänsyn har tagits till data i kommande versioner av MultiPC. Det är rimligt i samband med v1.0 eftersom det endast är elevernas namn som ska lagras. Inför framtida versioner bör problemet prioriteras upp. Om MultiPC v2.0 lagrar statistik per elev kan det mycket väl komma önskemål om att v2.0-statistik ska fungera i v3.0. Problemet är alltså: Ska dataformat för v 2.0 förberedas så att det kommer att fungera även i version 3.0? 19. TEST AV AVINSTALLATION Test av avinstallation specificeras i samband med testfall under 170. De borde förstärkas så att avinstallation testas efter en längre period av användning. Kanske, kanske inte. Red ut inför nästa inkrement. 20. FOTON OCH EMAIL Webbplats På webbplatsen ska det finnas en länk Om oss och en länk Email. Under Om oss ska det finnas ett eller flera foton på oss. Det borde väl gå att aktivera email via fotona, alternativt få info via fotona. När det finns ett foto på en webbplats klickar man alltid på det och blir lika besviken varje gång man inte kommer vidare. 21. TEST AV TALGRÄNSER Krav 310 ser ut så här: Oavsett tabell ska för ett tal a * b som slumpas fram gälla att: 1 <= a <= 10 OCH 1 <= b <= 10. Testfallet kräver manuella granskningar av koden. Det här är uppenbart överarbete. Alternativen är a) Stryk kravet, det ordnar sig ändå eller b) Utöka testmoden under 190. Om testmoden utökas, modifiera testfallet under 310.
ÅTERSTÅENDE PROBLEM MultiPC v1.0 Rev 7 7(7) 22. MÅNGA PARAMETRAR multipc_logic_c ligger som fasadklass ovanpå logiken i. Flera av funktionerna där tar onödigt många parametrar efter varandra. Kanske ska man ta bort logikklassen helt, alternativt lyfta fram underliggande datatyper. Speciellt gäller att funktionerna för att hämta och lagra elevnamn bör förbättras. 23. INKLIPPTA DIAGRAM OCH PROGRAMKOD I designspecifikationen har UML-diagram och kodgränssnitt klippts in i dokumentet. Det gör det besvärligt att ändra i dokumentationen. Det här går att förbättra på olika sätt. Kanske kan ett CASE-verktyg vara till hjälp? Alternativt kan vi lägga diagram och programkod som bilagor.