Utvärdering av projektet

KTH Institutionen för Numerisk Analys och Datalogi Utvärdering av projektet RedInc www.nada.kth.se/projects/prom03/redinc Uppdragsgivare: Projektmedlemmar: Harald Kjellin Daniel Oscarsson Rikard Laxhammar Tommy Pettersson Thomas Jansson Karin Råde Ulf Rustas Emil Stridfeldt Mikael Nyqvist Alexander Ahl Stockholm 2004-05-15

Innehållsförteckning 1 Inledning...3 2 Rollerna i gruppen...3 3 Samarbete i gruppen...4 4 Kontakt med uppdragsgivaren...5 5 Tidsplaneringen...5 6 Programvaror och utrustning...6 7 Riskanalysen...6 8 Ändringar i förstudien...7 9 Lärdomar och slutsatser...8 2

1 Inledning Detta dokument är en utvärdering av vårt programmeringsprojekt RedInc. Utvärderingen vänder sig till kursledaren, uppdragsgivare, opponenter och inte minst oss själva. Vi har tittat på och analyserat följande delar av projektet: Rollerna i gruppen Samarbete i gruppen Kontakt med uppdragsgivaren Tidsplaneringen Programvaror och utrustning Riskanalysen Ändringar i förstudien Lärdomar och slutsatser 2 Rollerna i gruppen Vid mötet 29/11 utsågs fördelning av de olika projektrollerna. Dessa var: projektledare, vice projektledare, informationsansvarig, databasansvarig, JSP-ansvarig, XML-ansvarig, testningsansvarig och sekreterare. Senare tillkom även en roll för versionshantering. Sekreterarrollen avsågs först som en roterande roll mellan samtliga projektmedlemmar. I praktiken fungerade detta inte och rollen försummades. Därför tilldelades rollen senare till en enskild projektmedlem. Eftersom många av de följande mötena var mellan ansvariga för de olika implementationsområdena (DB, JSP, XML) och sekreteraren var inte med på dessa och så kom småningom sekreterarrollen att försummas av gruppen ändå. Rollen som informationsansvarig innefattade att lägga upp sekreterarens mötesanteckningar, att ordna projektarea och webbplats samt att ansvara för dokumentation. Informationsansvarig har varit bortrest under en stor del av projektet och har således inte varit särskilt aktiv eller initiativtagande i sin roll. De viktigaste har i alla fall utförts, nämligen att ordna projektarea och skapa en hemsida för projektet. Rollerna databas-, XML-, och JSP-ansvarig utsågs i samband med uppdelningen av implementationsarbetet, för att dessa skulle kunna träffas, tillsammans med projektledaren, i mer informella möten och rapportera delresultat och andra spörsmål. Dessa roller har varit funktionella såtillvida att varje ansvarig har kunnat föra sin arbetsgrupps talan utan att man behövde koordinera möten mellan alla projektmedlemmar. Rollerna vice projektledare och testningsansvarig har inte fått tillfälle att materialiseras. Vice projektledare behövdes inte eftersom projektledaren aldrig har varit frånvarande under projektet. Även testningsrollen hamnade i bakgrunden eftersom implementeringen försenades så pass mycket att någon formell sluttestning ej har hunnits med. 3

Versionshanteringen blev sporadisk. Databasgruppen använde zip-filer för versionshantering, vilket fyllde sitt syfte utmärkt. XML-gruppen arbetade mest med penna och papper och producerade sedan en DTD-fil, i vilken endast små och noga genomtänkta modifieringar gjordes i efterhand. DTDkoden var av så pass ringa omfattning att effekten av ändringar var lätt att överblicka. I JSP-gruppen har arbetet haft en laborativ och inkrementell karaktär. Kodmassan har inte heller här varit så stor att formell versionshantering har ansetts värt besväret. Projektledarrollen är per definition mycket klar men samtidigt svår att avväga. Hur mycket skall projektledaren bestämma själv? Hur mycket ansvar skall projektledaren lämna till arbetsgrupperna? Hur pass mycket skall projektledaren kontrollera att deltagarna följer det som slagits fast, och hur mycket skall egentligen slås fast? Vilka initiativ förväntas projektledaren ta? I vårt projekt har projektledarens roll varit mest framträdande vad det gäller att sammankalla möten när han anser att så behövs. Dessutom försöka se till så att arbetet flyter på för alla arbetsgrupperna, genom att hålla kontinuerlig kontakt med deltagarna samt koordinera arbetsuppgifter och andra åtaganden. Vid ett tillfälle har initiativ tagits till omfördelning av deltagarna i arbetsgrupperna för att öka produktiviteten. Denna omfördelning bedöms lyckad. Ytterligare uppgifter som projektledaren genomfört är att boka tider för redovisningar och hålla kontakt med kursledare och uppdragsgivare. Eftersom en rad delar av projektet blivit lidande så finns det mycket som projektledaren kunde ha gjort bättre. Vad det gäller möten så hade tydligare agenda inför varje möte och verkställande av sekreterarrollen varit önskvärt. Arbetsgrupperna hade förmodligen kommit igång snabbare och jobbat hårdare om projektledaren hade satt upp tydliga, mätbara och tidsangivna mål för varje grupp efter varje möte. Detta var dock svårt eftersom gruppen i allmänhet inte på förhand kunde avgöra vad som skulle ta tid och exakt vilka beroenden som fanns mellan arbetsgrupperna. När man ser tillbaka på projektets genomförande i tiden så inser man att projektledaren borde ha framtvingat en intensivare uppföljning av gruppernas arbete och resultat. I en så pass stor projektgrupp som vår är det nämligen oundvikligt att olika deltagare har olika ambitionsnivå eller olika uppfattning om vad som måste göras och när. 3 Samarbete i gruppen I samband med gruppmöten har samarbetet i gruppen fungerat bra. När stormöten (möten med hela gruppen) har utlysts så har alla gruppmedlemmar (utom den bortreste) varit närvarande, och alla har vid mötena visat ambitioner att vara med och bidra till projektets utveckling. 4

Ett klassiskt problem som kan uppstå i grupparbeten är att olika parter drar åt olika håll. I vårt fall är det dock snarare så att ingen har dragit tillräckligt mycket. Inom undergrupperna (XML, JSP, databas) har diverse mindre samarbetsbrister förekommit. Dessa har berott på olika orsaker såsom skilda uppfattningar om hur och var arbetet skall genomföras (t.ex. individuellt eller tillsammans), inaktivitet (d.v.s. brist på arbetande över huvud taget) och skillnader i förkunskaper. Inom XML- och JSP-grupperna åstadkoms en förstärkning av samarbetet, och effektivisering av arbetet, genom projektledarens initiativ att omstrukturera grupperna. Inom databasgruppen var det i huvudsak en medlem som hade en klar uppfattning om vad som skulle göras och hur. Detta, kombinerat med bristande kommunikation ledde till obalans i samarbetet, genom att den medlem som hade en klar bild jobbade mest individuellt och resten av gruppen fick en begränsad förståelse av vad som gjordes. 4 Kontakt med uppdragsgivaren Kontakten med uppdragsgivaren, Harald Kjellin har varit begränsad. Tre möten genomfördes. Under första mötet presenterade Harald uppgiften för gruppen. Andra mötet syftade till att låta Harald ta del av förstudien och komma med kommentarer och synpunkter. Vid detta möte visade det sig att gruppens och Haralds uppfattning om vad som skulle göras stämde bra överens och det uppkom endast små frågor. Vid det sista mötet med Harald redovisades vad som ändrats relativt förstudien, inför förhandsvisningen. Vi hade alltså inga möten med Harald under själva utvecklingen av produkten. Den enda kontakten skedde via mail för att klargöra enklare frågor. Anledningen till denna sparsamma kontakt under utvecklingen var att uppgiftens karaktär var sådan att mycket lämnades kvar för oss att bestämma. Uppdragsgivarens specifikationer om vad som skulle göras var på en ganska generell nivå, men tillräckligt väldefinierade för att fånga problemets väsentligheter. Vi ser således inte heller i efterhand att mer frekvent kontakt med uppdragsgivaren hade tillfört något viktigt till projektets genomförande. 5 Tidsplaneringen Den tidsplanering som anges i förstudien ger mycket grov uppstyrning av projektets tidsramar. Tidsplaneringen delades in i veckoperioder och inga hårda milstolpar, förutom de av kursledaren uppsatta, angavs. I kort kan man säga att implementeringen har försenats ca två veckor enligt den givna tidsplanen. Detta beror på att implementeringen kom igång sent och har framflutit långsamt pga av problem med parallellisering av arbetet och beroenden mellan arbetsgrupperna. En annan försinkande faktor var att en hel del tid las ner på att sätta sig in i de tekniska detaljerna som behövdes för att lösa uppgiften. Här åsyftas dels inlärning av XML samt arbete med att få databaser och Tomcat-servers att fungera. På grund av försenad implementering hamnade också etappmötet med uppdragsgivaren senare än planerat, nämligen strax före förhandsvisningen, 5

i slutet av mars. Den ursprungliga planeringen angav denna tid till början av mars. Dödlinorna formulerade av kursledarens har dock hållits. 6 Programvaror och utrustning De program JSP-gruppen har använt, förutom texteditorer är dels Suns JDK 1.4 samt Apache Tomcat 4.0.6. JDK 1.4 har använts till att köra javafiler som genererar html-sidor samt skapar tabeller i databasen. Apache Tomcat används till att visa de genererade html-sidorna samt köra olika servlets som tillhandahåller funktioner för html-sidorna mot databasen. Programvarorna har fungerat bra, men Tomcat-servern tog tid och jobb för att installeras och fås att fungera. Databasgruppen använde PostgreSQL 7.3 och 7.4, beroende på när man har jobbat på KTH eller i hemma. Det har förekommit några små kompatibilitetsproblem mellan de olika arbetsmiljöerna vad det gäller syntax. Detta orsakade betydande tidsåtgång för JSP-gruppen när databasen skulle användas. XML-gruppen har bara använt sig av papper, penna och en enkel texteditor. I allmänhet har det inte varit några större problem med programvaror och utrustning. 7 Riskanalysen I förstudien genomfördes en riskanalys, där olika tänkbara risker beskrevs och värderades efter effekt och sannolikhet. Som framgått tidigare i utvärderingen så inträffade några av de händelser vi satt upp i riskanalysen; 4.1.2 Ofullständig tidsplan, 4.1.3 Tidsplan följs ej, 4.1.4 Frånvaro av gruppmedlem samt 4.4.4 För låg kunskapsnivå i gruppen. Med ofullständig tidsplan menar vi att den inte explicit tog upp de kritiska inläsningsmomenten inför implementeringen. Det hade varit bra med konkreta tidsramar för inläsning för att undvika försening av implementeringen. Med tidsplan följs ej syftar vi på dels att implementeringen försenades, dels (vilket hänger ihop) att etappmötet med uppdragsgivaren hamnade mycket sent i tiden. Frånvaro av gruppmedlem inträffade på sås sätt att en av gruppmedlemmarna var bortrest under hela projektets implementationsfas. Hur pass mycket detta påverkade är svårt att säga, men detta hade naturligtvis som effekt att vederbörande inte kunde delta i gruppmöten eller jobba tillsammans med de andra i gruppen. Som nämnt så var för låg kunskapsnivå en försenande faktor i projektet. Dessutom inträffade en händelse, eller snarare en trend, som inte var med riskanalysen, nämligen att vissa åtaganden och roller försummades eller fördröjdes onödigt mycket. Som exempel kan nämnas sekreterarrollen som nämndes ovan, samt att XML-gruppen tog alldeles för lång tid på sig att 6

prestera resultat. Vi identifierar tre orsaker till försummanden som dessa nämligen 1. låg initiativ-, motivationsnivå och engagemang hos gruppmedlemmar, 2. inte tillräckligt styrt projektledarskap och 3. inte tillräckligt tydliga och hårda tids- och resultatramar efter varje möte. Den sistnämnda orsaken beror dels på projektledarens ledarskap, dels på gruppen som helhet (förmågan att analysera vad som måste göras och komma överens) och till stor del på svårigheten att överblicka problemet. Effektiviteten i programmeringsgruppen ( JSP ) kan eventuellt ha effektiviserats om man hade haft ett jämnt antal gruppmedlemmar, istället för tre som i vårt fall. Tre personer är svårt att dela upp på ett självklart sätt och uppgiftsdelegering inom gruppen kan ha försvårats av detta faktum. 8 Ändringar i förstudien I förstudien gavs en översiktlig beskrivning av hur olika moduler i systemet kommunicerar med varandra. De moduler som angavs var Webbrowser, Webserver, JSP/Programlogik, Databas, XML och DTD/XMLspecifikation. De kopplingar som skissades upp mellan dessa moduler var mycket grundläggande för systemet och har på denna nivå inte ändrats under utvecklingen. För databaslagret skissades upp ett klassdiagram som var delvis konceptuellt, men också hade vissa kopplingar till implementation, dvs en bra kombination av överskådlighet och detalj. Strukturen hos den databas som implementerats följer fortfarande detta diagram, dock har detaljer tillkommit i beskrivningen som inte fångades i förstudiens diagram. På programlogiknivå så finns det en signifikant ändring som är värd att nämna. I förstudien specificerades att vid varje access till systemet (från slutanvändaren) så parsar man de XML-filer som beskriver funktionaliteten för den delen av systemet, för att på så sätt kunna generera uppdaterade httpdata till användaren. Vi insåg dock att detta var en onödig funktionalitet eftersom slutanvändaren aldrig påverkar XML-defintionen och därför sker ingen uppdatering mellan accesser av slutanvändare. Det är mer rationellt att lagra hela XML-definitionen i en enda XML-fil och låta systemet generera nya statiska webbsidor varje gång denna fil ändras av administratören. Denna nya lösning, vilken diskuterades med och accepterades av uppdragsgivaren, har som konsekvens att de dataflödesdiagram som presenterades i förstudien blir avsevärt förenklade. Uppfattningen om DTD- och XML-modulernas uppgift har inte ändrats från förstudien, även om programlogiken för att hantera dem har det (se ovan). 7

9 Lärdomar och slutsatser Det faktum att vårt projekt har varit måttligt lyckat har givit det en god lärdomspotential. Med detta menar vi att vi har upplevt en mängd lärorika problem men också uppnått framgångar som givit oss fortsatt engagemang. Givetvis varierar den faktiska lärdomen som var och en kan tillgodoräkna sig, beroende på vilken roll man har haft i projektet och hur stort engagemang man har lagt ner. Det är värt att belysa hur viktigt det är att gruppen är motiverad för ett projekt, för projektets framgång. Inför projektvalet försökte vi konstruera en grupp där alla hade liknande preferenser. Vi lyckades få förstahandsval och andrahandsval att stämma väl överens mellan projektmedlemmar. I själva projektfördelningen fick vi dock vårt tredjehandsval, vilket innebar att flera av projektmedlemmarna kom att delta i ett projekt som överhuvud taget inte fanns med på deras prioriteringslista! Det är svårt att peka ut enskilda orsaker till de problem och förseningar som uppstått, men vi tror att var och en har lärt sig vikten av att bestämma tydliga ramar och mål vid projektmöten. Detta är dock inte alltid så lätt, och bara för att man bestämmer något så kan man, av olika orsaker, misslyckas att efterfölja det. 8