Version 1.0. Version Datum Ändrad av Utförda ändringar

Transkript

1 Sid 1 (12) SLUTRAPPORT Webbadress Projektnamn Fastställt av Mattias Wallmark, IT-enheten Dokumentansvarig Jan Bidner Dokumentidentitet Cambro-defektrace-2010 Version 1.0 Datum Status Slutlig Version Datum Ändrad av Utförda ändringar Jan Bidner Upprättat dokument Jan Bidner Fyllt på Jan Bidner Ärenden, org mm Jan Bidner Första remissförslag Jan Bidner Slutlig version

2 Sid 2 (12) Innehållsförteckning SLUTRAPPORT Innehållsförteckning... 2 Inledning... 3 Avgränsningar... 3 Målgrupp för rapporten... 3 Dokument... 3 Beskrivning av projektet... 3 Bakgrund... 3 Projektets målsättning... 4 Projektorganisationen... 4 Tidplan... 5 Projektets genomförande... 6 Resultatet... 7 Generella åtgärder... 7 Nya Verktyg... 7 Lista över åtgärdade ärenden... 8 Avförda ärenden... 8 Erfarenheter från projektet... 8 Budgetresultat Bilagor... 12

3 Sid 3 (12) Inledning Detta dokument innehåller en sammanfattning av genomförandet och resultaten av projektet. Projektet är ett underprojekt till PIKTUM-projektet ( och har syftat till att höja den upplevda kvaliteten av UmU:s gemensamma lärplattform Cambro. Projektet har löpt under 13 veckor, våren 2010 i syfte att åtgärda de upplevda kvalitetsbristerna i UmU:s gemensamma lärplattform Cambro. Avgränsningar Rapporten sammanfattar det arbete som skett inom ramen för. Ett antal befintliga ärenden har i samråd med verksamheten avgränsats från projektet då hantering av dessa är så komplex att mycket stora delar av produkten i grunden måste skrivas om och som motsvarar flera års arbete. Målgrupp för rapporten Målgruppen för rapporten är framförallt uppdragsgivaren i syfte att ta del av resultaten av projektet, men kan även vara av intresse för Cambro-förvaltningen, lärare, IT-personal och övriga anställda vid Umeå universitet. Dokument De dokument som tagits fram inom projektet, som till exempel testplaner och statusrapporter, återfinns framförallt i projektrum Cambro i sharepoint (utförarenhetens gemensamma intranät). Styrdokument och andra viktigare dokument finns även tillgängliga på projektets webbplats (se länk på försättsbladet). 1. Projektplan Piktum 2. Projekt Slutrapport (Detta dokument) 3. Test Slutrapport 4. Lista över hanterad åtgärder Beskrivning av projektet Bakgrund Införandeprojektet för Cambro avslutades Vid den tidpunkten hade Cambro varit i skarp drift sedan december året innan och under hösten fasat ut föregångaren Ping-Pong. Under hösten kom det mycket kritik om kvalitetsbrister i Cambro från lärare, och även indirekt studenter, som upplevde en direkt försämring gentemot t.ex. Ping-Pong. Framförallt handlade det om instabilitet i verktyg direkt kopplade till kursens genomförande som t.ex. ett testverktyg samt ett verktyg för inlämningsuppgifter. Detta och en stor mängd övriga ärenden och buggar av varierande karaktär, samt även avsaknaden av vissa förväntad funktionalitet gjorde att missnöjet var väldigt stort och växande vid årsskiftet. Förutom rent faktiska kvalitetsbrister så fanns det även en hel del frågetecken kring själv införandet och på vilka grunder man 1) avskaffade Ping-Pong samt 2) valde Sakai som plattform. I inledningen till projektplanen för Piktum skiver man att:

4 Sid 4 (12) osäkerheter kring och brister i lärplattformen Cambro har dock inneburit en avsevärd arbetsbelastning för lärarna och ett oacceptabelt osäkerhetsmoment för studenterna. För att säkerställa utbildningskvalitén mot studenterna och skapa en trygg kreativ undervisningsmiljö för lärarna är det viktigt att UmU:s virtuella lärmiljö utvecklas och anpassas så att den motsvarar verksamhetens behov // Situationen just nu är en plattform där användarna upplever många brister ofta i form av defekter men även funktionalitet som inte finns och som anses behövas för utbildningen Projektets målsättning Målet med detta projekt var att höja den upplevda kvaliteten av Sakai som plattform för lärande vid Umeå universitet. De mätbara målen var att: Den sammanlagda ärendelasten beräknad med en multipel om 3 skall minska med minst 60%. Av de befintliga ärenden som går in i projektet skall minst 90 % hanteras genom implementerad lösning, fungerande work-around eller att ärendet på annat sätt inte längre upplevs som ett problem. Projektorganisationen Beställare: Projektledare: Utvecklare: Testare: Verksamhetstestare: Mattias Wallmark, IT-enheten Jan Bidner, Ladokenheten Magnus Jonsson, UMDAC Johan Forsman, Ladokenheten Nils Risslén, Ladokenheten Tobias Tjäder, konsult Mikael Lidman, Ladokenheten Marie Johansson, Ladokenheten Anna Lill Hedman, HumFak Anders Fredlander, MedFak

5 Sid 5 (12) Anders Rydh, MedFak Gudrun Hedberg, SamFak Johan Bodén, SamFak Rolf Engh, TekNat Torbjörn Sandgren, HumFak Referensgrupp: Claire Englund, UPC Ulf Sperens, UPC Andreas Bokerud, Utbildningsbevakare Andreas Olssont, Tillämpad utbildningsvetenskap Britt Mari Oja, Omvårdnad Fredrik Lindborg, Idéer och Samhällsstudier Håkan Eriksson, Ekologi, miljö och geovetenskap Kerstin Söderman, Samhällsmedicin och rehabilitering Pär Segerbrant, Tillämpad utbildningsvetenskap Torbjörn Sandgren, Estetiska ämnen Tidplan Projektet startade v.8 ( ) och avslutades v.22 ( ). I skrivande stund återstår dock en del tester inför driftsättning och själva driftsättningen kommer att ske juni. Den slutrapporten överlämnas 2 juni i samband med avrapporteringsmöte.

6 Sid 6 (12) Projektets genomförande Baserat på bakgrunden som beskrivs i detta dokument beslutades och budgeterades för ett delprojekt inom ramen för PIKTUM-projektet med syftet att höja den upplevda kvaliteten av produkten Cambro (Sakai). Därför formerades en projektgrupp som alltså primärt hade till syfte att ur ett tekniskt perspektiv lösa problemen i Cambro. För att säkerställa att man gjorde rätt saker ur ett verksamhetsperspektiv så engagerades förutom utvecklare och testare även lärare som skulle agera verksamhetstestare från alla fakulteter i denna omfattning: - 2 lärare à 25 % från SamFak - 2 lärare à 25% från HumFak - 1 lärare à 50% från TekNat - 2 lärare à 25% från Medicin Projektet har bedrivits som ett SCRUM-projekt. Med det menas att projektet har utnyttjat projektmetoden SCRUM som ramverk för att dela in projekttiden i sk sprintar. Varje sprint är en isolerad krav-, utvecklings- och testiteration på ca 3 veckor. Vidare inleds varje sprint med att man har ett sprintplaneringsmöte där man fyller på backloggen för den aktuella sprinten och uppskattar tid för varje åtgärd som läggs till den. I projektet har vi använt oss av ett åtgärdshanteringssystem (JIRA med Greenhopper som plugin) som på ett smidigt sätt erbjudit stöd i projektarbetet och gett en överblick av progress och övrig status på ärenden i projektet. Sprintplaneringen ägnades en halv till en hel dag och inbegrep förutom projektgruppen (projektledare, utvecklare och testare) även produktägaren (ITenheten). Utifrån den tillgängliga mantiden planerade vi sprintens innehåll. En utvecklingstimme adderades med en halv timme test som standard. En schablon som visade sig stämma rätt så väl. Inför varje sprintplanering hade vi en, av verksamheten, prioriterad åtgärdslista att utgå ifrån. Verksamheten representerades, förutom av verksamhetstestarna, under projektperioden av en referensgrupp under ledning av UPC. Referensgruppens uppgift var att prioritera en lista av inkomna ärenden. Projektledaren har deltagit vid referensgruppens prioriteringsmöten och varit föredragande vid mötena. Ursprungligen gick vi helt efter ett dokument där man gjort en sammanställning av Cambro-relaterade ärenden från RT (UMDACs ärendehanteringssystem) och prioriterat buggar och åtgärder. Efter att projektet hanterat alla ärenden med prio mkt hög, hög och mellan så blandades ärendena upp med sådant som framkom i projektet genom verksamhetstest och metodisk funktionell test. Mer om test under Rubriken Test. Projektgruppen har under hela projekttiden suttit samlokaliserad i UMDACs korridorer i MIT-huset.

7 Sid 7 (12) Projektet har haft hyfsat dedikerade resurser i form av projektledning, utvecklare och test. Vidare har projektgruppen haft dagliga, korta avstämningsmöten som handlat om att stämma av Vad gjorde jag igår? Vad gör jag idag? Vad hindrar mig från att göra det jag ska?. Resultatet Vi har i projektet hanterat totalt drygt 200 ärenden varav åtminstone 60 ärenden kommer från den ursprungliga prioriteringslistan från Referensgruppen. Med hanterats menas både test och utveckling. I vissa fall har det handlat om att verifiera att saker som inte funkade i tidigare version fungerar i den nya. Ärenden har rapporterats in löpande och valts ut dels bland de, i projektet, inrapporterade ärendena och dels utifrån nya inrapporterade ärenden i Umdacs helpdesk. Prioriteringsmöten i referensgruppen har hållits inför och i nära anslutning till planeringsmötena för respektive sprint. Vid dessa möten har en sammanställning av relevanta ärenden diskuterats och beslutats. Tester i projektet har skett framförallt på version 2.6 av SAKAI med den skarpa installationen (SAKAI 2.5) som referens. Ärenden har genererats dels genom verksamhetstestarnas testarbete, dels genom professionellt testarbete i projektet. I vissa fall har ny funktionalitet producerat nya problem som måste hanteras. Nedan följer en redogörelse för vilka åtgärder som genomförts. Dubletter listas inta vissa liknande åtgärder på flera olika ställen redovisas tillsammans: Generella åtgärder Versionsuppgradering från version 2.5 till 2.6 av Sakai. Generella förbättringar av gränssnitt (menyer, överensstämmelse med Bättre felsideshantering Nya Verktyg Kursutvärdering (Evaluation system) En ny modul i vilken man kan skapa och publicera kursutvärderingar och enkäter Frågor och Svar (QnA) En modul där man kan samla och kategorisera vanliga frågor och svar. Studenter kan fråga och läraren kan svara och publicera. Resultat (gradebook) Ett verktyg som samlar resultat från olika kursverktyg som till exempel: Inlämningsmapp, Uppgifter och Test & Quizzies

8 Sid 8 (12) Portfolio (OSP/Open Source Portfolio) Ett verktyg för att hantera personliga portfolios. Pilot under hösten 2010 på Umeå School of Education. Dessutom har Cambros wiki-verktyg begåvats med ett efterlängtat formelskrivningsstöd i form av jsmath (LaTeX). Lista över åtgärdade ärenden Se bilaga i SP (Sharepoint) och på projektsida (länk på första sidan i detta dokument). Avförda ärenden Vi har i projektet i valt att avföra en del ärenden. Vissa direkt och andra efter utredning. Detta har gjorts på någon av dessa grunder: Ärendet har inte ansetts prioriterat av vare sig referensgrupp, beställare eller projektledning Ärendet är otydligt och har inte - trots uppföljning och kontakt med rekvirent - fått någon vettig specificering Ärendets felbeteende kan inte upprepas i testmiljön för 2.6 Ärendet berör fel i omgivande miljöer (operativsystem, angränsande system etc) Ärendet kräver omfattande kodanpassningar som bryter mot den inriktning som finns i communityt (utrymme saknas inom ramen för projektet och skapar dessutom orimligt mycket extraarbete i förvaltning) Ärendet kräver omfattande kodanpassningar som ligger i linje med communityt (dessa ärenden har, i den mån de bedömts som viktiga i referensgruppen återkopplats och specificerats mot Sakais community) Ärendet är identiskt med ett annat ärende Erfarenheter från projektet Förutom den rent tekniska åtgärdshanteringen har andra framgångsfaktorer för projektet och för Cambro som system identifierats och i viss mån hanterats: Tät kommunikation med UPC och referensgruppen för att specificera och detaljera de ställda kraven för att säkerställa att man gör rätt lösningar. o 4 referensgruppsmöten. Flera iterationer av kravdokumentation i arbetsgrupper.

9 Sid 9 (12) o Möte med UPC, USE och IML om Portfolio (Ny verktygsmodul) i Sakai. o Möten om Eval Sys och QnA (nya verktygsmoduler i SAKAI) med UPC och delar av referensgruppen. Viktigt att bygga nätverk inom Sakai-communityt, såväl nationellt som internationellt för att inte uppfinna samma hjul flera gånger. o Nätverksmöten med Stockholms universitets MONDO-grupp och UPC (hittills 2 under våren 2010 och ett tredje inplanerat via adobe connect) sedan tidigare initierat under införande o Nya samtal med Högskolan i Skövde som kör SAKAI skarpt från hösten 2010 (inbjudna till nätverket) (PL: Daniel Andrén Studentportal 2010 ) o Samtal och samverkan med Indiana University angående Assignments 2 och gruppinlämning (Steven Githens) o Samtal och samverkan kring test (och förvaltning) med Quality Assurance- avdelningen som leds från Amsterdams universitet (Alan M Berg) o Samtal med Etudes (open source-konsulter i Communityt) om Moduler och Melete 2 (Vivie Sinou, Executive director) Identifiera studentrepresentanter och ingångar till kommunikation med studenter i första person. o Denna kontakt har främst bestått i att kommunicera med studentkåren och Umeå Studentkårs utbildningsbevakare som ingått i referensgruppen. Projektet har i dialog med Umeå studentkår utryckt önskan om att få till stånd ett möte med studentrepresentanter. Även kontakt med en med informatikstudent som skriver sitt examensarbete om lärplattformar. Avgränsa systemet o Diskussioner med UPC om mallrum (d.v.s. fördefinerad uppsättning av verktyg för olika typer av kurs-siter: Campus, Blended och Distans). Underlättar för både lärare och studenter att känna igen sig från en kurs till en annan, och även för lärare att få vägledning och best practice. Vid behov kan man lägga till flera verktyg. Men basuppsättningen bör vara tydligare. o Diskussioner med UPC om Demo- och exempelsiter. Hur kan man lägga upp det? Hur ser det ut i användning? Goda exempel? Intressant framförallt för nya lärare. o Vilka verktyg används sällan? Varför? Kan man ta bort dessa? Ju fler verktyg vi erbjuder desto fler måste vi supporta och underhålla. Idag en lång lista att bocka för vi kursskapande. Risken är att man bockar

10 Sid 10 (12) för alla och att verktyg ligger och skräpar i kurser. Identifiera studentperspektiv o Vilka verktyg och funktioner efterfrågar studenter? (t.ex. PIM/Chat) o Vilka problem ser man? (t.ex. Dåligt organiserade och strukturerade siter, Lärare som inte kan med verktyget, Bristfällig och svajig inlämnings- och testverktyg) Mer tilltalande och modernare utseende o Förbättra gränssnittet och göra det mer likt Portalen och Umu.se ger otroligt mycket är relativt lite jobb. Har stor betydelse för användarupplevelsen. Bättre användardokumentation och handledning måste till o Lärare hittar inte, använder inte eller gör trots det ett dåligt jobb med att strukturera sin kurs i Cambro o Se över dokumentation och manualer (t.ex. nya funktioner och nytt utseende, förändrad/förättrad funktionalitet, nya/förändrade flöden Fel i manualen upplevs som fel i systemet) o En ingång till dokumentation: Interna hjälpen i Cambro Kunskapsdatabasen o Informera om att och var man kan hitta hjälp o Erbjuda möjligheter för användare att hjälpa varandra (t.ex. chat, användargenererad hjälpdatabas med filmer och lathundar lärare gör egen hjälpdokumentation ) Vi måste aktivt verka för färre lokala kodanpassningar av SAKAI o Genom att utnyttja communityt för att få patchar och lösningar o Genom att bidra till communityt genom att återkoppla kodpatchar och lösningar o Inte utveckla sådant som finns/kommer i communityt inom en snar framtid o Utveckla samarbetet med Stockholm och inom kort Högskolan i Skövde och bilda en Nordic League av SAKAI-communityt. o Använda resurserna i förvaltningen smartare: Jobba på längre sikt när systemet stabiliserat sig och o sätta upp en vanilla-installation av den absolut senaste versionen av SAKAI (inte gjort än) 2.7 eller rent av 2.8 och göra alla patchar först i den aktuella versionen för att kunna återkoppla till communityt och sen anpassa för UmU:s SAKAI-installation Förbättrad systemdokumentation (påbörjad och dokumentationsmall framtagen)

11 Sid 11 (12) o Verktygsmodulerna är spretiga, dåligt dokumenterade och använder sig av vitt skilda tekniker och ramverk. o Tröskeln för nya utvecklare i Cambro är alldeles för hög o Dokumentera upp de viktigaste modulerna i Cambro med syfte att bygga bort personberoende och förenkla för utveckling och förvaltning/underhåll: Samla in och katalogisera den dokumentation som finns för modulerna i Communityt Skapa egen kartläggning av struktur och dokumentation för funktioner i modulerna: Var ändrar jag texter? Språk? Var ändrar jag Stylesheets? Vilka ramverk används? Regler och undantag Tabeller och relationer Identifiera glappen till andra system o Hur kan man uträtta samma eller likvärdiga saker som i andra tidigare använda system (PING-PONG, Moodle m.fl.)? o T.ex. SMS-tjänst är efterfrågad (fanns i PING-PONG) o Frågebanker, automaträttning finns andra sätt att göra samma saker viktigt att informera om rätt handhavande o Betygsskalor saknas, kan inte göra egendefinierade o Etc etc Identifiera kvalitetskriterier för lärande i allmänhet och virtuellt lärande i synnerhet o Idag saknas tydliga kriterier och krav på lärplattform för studenter vi UmU. o Hur kan man kvalitetssäkra online-utbildning för UmU? Uppgradering till 2.8, Hybrid, 3.0 nästa uppgradering o Blicka framåt mot nya uppdateringar i tid o Nästa bästa steg? o Få upp en vanilla -miljö av latest and greatest SAKAI-version. o Utveckla mot aktuella versioner i SAKAI och patcha bakåt o Ingen egenutveckling av sånt som kommer Framtida förvaltning ordinarie verksamhet Bättre koppling mot Ladok Budgetresultat

12 Sid 12 (12) Resultaträkningen görs på antal timmar beräknat och förbrukat. Beroende på vem som utfört timmarna blir kostnaden lite olika (siffrorna är avrundade till närmaste 5- eller 10-tal). Om man räknar på ett timpris på 600 kr/timmen så blir kostnaden ca 1,43 miljoner kronor mot för ca 1,96 vid förväntat utfall. Anledningen till att vi skå kraftigt gått under budget har flera orsaker. Flera av de medverkande har inte fullt kunnat frigöras i önskad utsträckning. Framförallt på utvecklingssidan har det varit tydligt och vi har bytt ut resurser under resans gång. Verksamhetstestarna har inte kunnat leverera den utlovade omfattningen. Där är det knappt 57% av tiden som förbrukats. Aktivitet Förbrukade timmar Budgeterat kvarvarande timmar PL Test V-Test Utv Sys.adm Totalt Bilagor Projektplan Piktum :// (projektplan piktum) Projektrum i Sharepoint ://umdacladok.db.umu.se/projects/cambro/project%20documents/forms/allitems.aspx Lista över hanterade åtgärder i projektet Testslutrapport Kravdokument Group assignment Bugreport Boundary Tests SAKAI 2.6