Efterstudie. Sammanfattning. Redaktör: Gustav Veide Version: I Tal-Lab kan ingen höra dig skrika

Transkript

1 Efterstudie Redaktör: Version: 1.0 I Tal-Lab kan ingen höra dig skrika Sammanfattning Detta dokument sammanfattar erfarenheterna från det projekt som PUMgrupp 1 utfört i kursen TDDC02, Programutvecklingsprojekt i ett helhetsperspektiv vid Linköpings tekniska högskola under höstterminen Det visar vilka positiva och negativa erfarenheter gruppen erhållit, och tar även upp hur de enskilda projektmedlemmarna upplevde sin roll i projektet. Dessutom ges tips till framtida projektgrupper.

2 Projektidentitet Projektgrupp Stum Linköpings tekniska högskola (IDA) Projektmedlemmar Namn Ansvarsområde Telefon E-post Ali Aghajani Projektledare Kjell Enblom Dokumentansvarig Filip Klasson Kvalitetsansvarig Johan Millving Designansvarig Andreas Rasmussen Implementationsansvarig Systemansvarig Patrik Sandström Kundansvarig Thomas Janowski Testansvarig E-postlista för hela gruppen Hemsida www-und.ida.liu.se/~pum1 Kund Kundkontakt Bertil Lyberg, Mustapha Skhiri, Handledare Sten Sunnergren, Examinator och kursansvarig Robert Kaminski, IDA

3 Dokumenthistorik Version Datum Utfärdade ändringar Utfärdade av Första version skapad 0.2 Alla kapitel är nu helt klara Uppdaterad efter inspektion ii

4 iii

5 1 Inledning Syfte Dokumentöversikt Läsanvisningar Distribution Dokumentberoende Förkortningar Projektbeskrivning Bakgrund Syfte Uppsatta mål Uppnådda mål Ej uppfyllda krav Projekterfarenheter, fasvis Total tidsförbrukning Förstudiefasen Tidsförbrukning Erfarenheter Definitionsfasen Tidsförbrukning Erfarenheter Designfasen Tidsförbrukning Erfarenheter Implementationsfasen Tidsförbrukning Erfarenheter Testfasen Tidsförbrukning Erfarenheter Kvalitetsarbete Tidsförbrukning Erfarenheter Projektledning Tidsförbrukning Erfarenheter Projektavslutningsfasen Tidsförbrukning Erfarenheter Projekterfarenheter, aktivitetsvis Utbildning Intern utbildning Självstudier Dokumentframställning Dokumentmallar Dokumentskrivning iv

6 4.3 Presentationer och opponeringar Positiva erfarenheter Negativa erfarenheter Implementation Delmoment Erfarenheter Organisation Erfarenheter Utbildning Erfarenheter Modulimplementation Erfarenheter Integration Erfarenheter Design Arkitekturspecifikation Designspecifikation Programmeringshandbok Sammanfattning Testarbet Testmetod Testplan Testresultat Tillräcklighet Sammanfattning Kvalitetsarbete Kommentering Inspektion Fasgranskning Internt revision Projekterfarenheter, övergripande Projektorganisation Projektgruppen Vår ambitionsnivå Kommunikation Arbetet inom projektgruppen Projektmöten Positiva erfarenheter Negativa erfarenheter Tidsrapportering Risker, förseningar Erfarenhet av kundkontakt Projekthemsida Designansvarig Arbetsuppgifter Positiva erfarenheter Negativa erfarenheter v

7 6.4 Sammanfattning Projektledare Arbetsuppgifter Positiva erfarenheter Negativa erfarenheter Sammanfattning Systemansvarig Arbetsuppgifter Positiva erfarenheter Negativa erfarenheter Sammanfattning Testansvarig Arbetsuppgifter Positiva erfarenheter Negativa erfarenheter Sammanfattning Implementationsansvarig Arbetsuppgifter Positiva erfarenheter Negativa erfarenheter Sammanfattning Kvalitetsansvarig Arbetsuppgifter Positiva erfarenheter Negativa erfarenheter Sammanfattning Kundansvarig Arbetsuppgifter Positiva erfarenheter Negativa erfarenheter Sammanfattning Dokumentansvarig Arbetsuppgifter Positiva erfarenheter Negativa erfarenheter Sammanfattning Referenser vi

8 vii

9 1 Inledning Detta kapitel ska ge en överblick av hur dokumentet är uppbyggt. 1.1 Syfte Syftet med efterstudien är att samla de erfarenheter som medlemmarna i PUM-grupp 1 har erhållit under det projekt som genomförts. Det innehåller såväl positiva som negativa erfarenheter uppdelade i tre olika kapitel: Ett om erfarenheter fasvis, ett om erfarenheter aktivitetsvis samt ett övergripande kapitel som sammanfattar erfarenheter över hela projektet. Efterstudien ger även tips till förbättringar för kommande projektgrupper. Dessutom har varje projektmedlem skrivit ett kapitel om sin egen roll. I det kapitel beskrivs projektmedlemens arbetsuppgifter och de positiva och negativa erfarenheter projektmedlemen fått av projektet Dokumentöversikt 1. Inledning Beskriver syftet med efterstudien och innehåller läsanvisningar för den som inte är intresserad av att läsa hela dokumentet. I slutet av kapitlet finns en lista med ordförklaringar som kan vara bra att läsa igenom för bättre förståelse. 2. Projektbeskrivning Beskriver det projekt som PUM-grupp 1 har genomfört. 3. Projekterfarenheter, fasvis Beskriver erfarenheter från projektet fasvis. Knyter hårt an till tidsplaneringen och den verkliga tidsåtgången för varje fas. 4. Projekterfarenheter, aktivitetsvis Beskriver projekterfarenheter aktivitetsvis. Går in på mer specifika detaljer än vad innehållet i det fasvisa kapitlet gör. 5. Projekterfarenheter, övergripande Detta kapitel beskriver gruppens efarenheter från projektet i ett mer övergripande perspektiv. 6. Projektledare Beskriver projektledarens erfarenheter av projektet. 7. Systemansvarig Beskriver systemansvariges erfarenheter av projektet. 8. Testansvarig Beskriver testansvariges erfarenheter av projektet. 9. Kvalitetsansvarig Beskriver kvalitetsansvariges erfarenheter av projektet. 10. Kundansvarig Beskriver kundansvariges erfarenheter av projektet. 11. Implementationsansvarig Beskriver implementationsansvariges erfarenheter av projektet. Kapitel 1: Inledning 1

10 12. Dokumentansvarig Beskriver dokumentansvariges erfarenheter av projektet. 13. Designansvarig Beskriver designansvariges erfarenheter av projektet. 1.3 Läsanvisningar För att få ett överblick av projektet och de samlade erfarenheterna bör kapitel 2 och 5 läsas. Om man är mer intresserad av hur tidsförbrukningen är anknyten till tidsplaneringen bör även kapitel 3 läsas. Om man är intresserad av specifika aktiviteter bör kapitel 4 läsas.om dokumentet läses i syfte av att man själv ska genomföra ett liknande projekt och man är intresserad av en specifik roll och dess ansvarsområden så bör kapitel 6-13 läsas. 1.4 Distribution Detta dokument distribueras till dokumentets examinatorer Sten Sunnergren och Linda Eklund-Hogsved. projektpärmen i projektskåpet. projektgruppens hemsida. 1.5 Dokumentberoende Detta dokument är fristående från alla tidigare dokument i projektet. 1.6 Förkortningar Löpande genom dokumentet kommer följande förkortningar att användas för de roller projektets medlemmar innehar: Förkortning Projektroll DOK DES IMP KUN KVAL PL SYS TES Dokumentansvarig Designansvarig Implementationsansvarig Kundansvarig Kvalitetsansvarig Projektledare Systemansvarig Testansvarig Tabell 1: Förkortningar för roller i projeketet 2 Kapitel 1: Inledning

11 2 Projektbeskrivning Detta kapitel beskriver den projektuppgift gruppen har haft, bakgrunden till denna och vilken kund gruppen har haft. Kapitlet tar även upp vilka mål gruppen ställde vid projektstarten och vilka av målen som uppnåddes. 2.1 Bakgrund På avdelningen för Human-Centered Systems bedrivs bland annat forskning om talsyntes. Deras forskning avser talsyntes genom konkatenering av ljudfragment inspelade av en människa och lagrade i en databas. Kunden har sedan tidigare ett färdigt system för animering till inkommande talspecifikation, kallat Orator [Projekt Orator, 2005]. Talsyntesen som styr Orator bygger på difoner. I Orator spelas talsyntesen upp som tal samt rörelser på ett animerat ansikte. Kunden var intresserad av ett liknande talsyntes-system som bygger på konkatenering av uppmärkta ord och stavelser. Detta till skillnad från Orator som är uppbyggt av ännu mindre delbitar av ord, difoner. Kunden ville att systemet som projektgruppen fick i uppdrag att utveckla i framtiden skall vidareutvecklas till ett helt eget system. Kravet var att systemet skall kunna spela upp både tal och rörelser med en talsyntes som i slutändan svårligen kan skiljas från den individ som genererat taldatabasen 2.2 Syfte Kunden ville att projektgruppen skulle utveckla ett system som skall bli den första byggstenen i ett större system för talsyntes. Målet med det här projektet var att bygga upp en databas med tal och rörelsemönster samt skapa ett färdigt separat system som kan spela upp konkatenerat tal. Kundens huvudsakliga mål var inte att få en talsyntes av hög kvalitet utan ett system för att testa en annan typ av talsyntes än den som de använt tidigare. Kapitel 2: Projektbeskrivning 3

12 2.3 Uppsatta mål Projektet har haft följande mål: Att åt kunden utveckla ett önskat system Att framställa nödvändig dokumentation för projektet Att den färdiga produkten är väl dokumenterad och väl designad Att inom uppsatt tid för projektet uppnå ovanstående punkter Att projektmedlemmarna utvecklas och lär sig nya saker som kan vara till nytta för framtida programutvecklingsprojekt. 2.4 Uppnådda mål Projektet har genomförts och godkänts av kunden genom acceptanstest. Samtliga dokument som skulle tas fram under projektets gång har skrivits och även blivit godkända av examinatorer samt kund. Utvecklingen av systemet har följt kvalitetsplanen och har löpande följts upp med ytterligare kvalitetsarbete. Den färdiga produkten är därför väl dokumenterad och väl designad. Slutligen har alla ovanstående mål uppfyllts inom den uppsatta tidsramen för projektet. Att kvantitativt avgöra huruvida målet med projektmedlemmarnas utveckling har uppfyllts eller inte är nästan omöjligt att avgöra, men de flesta i gruppen anser att de har lärt sig något de inte kunde tidigare. 2.5 Ej uppfyllda krav Två stycken omfattande krav uppfylldes inte av projektgruppen. I grunden beror det på rena missförstånd och underskattningar. Till en början skulle vårat system användas tillsammans med ett annat system, Orator. Kunden dröjde dock med att ge oss koden till Orator, och gav oss intrycket att det skulle vara ganska enkelt att använda en modul från detta system. Sanningen var att kunden inte hade en aning om hur koden såg ut eller var uppbyggd och när vi väl fick koden bestod den av ungefär 30 filer med odokumenterad kod. Efter att vi lagt ut flera timmar på att försöka förstå koden var vi tvugna att ge upp, det krävdes ett alldeles för omfattande arbete och vi började för sent. Nästa krav handlade om datainsamlingen till databasen så att systemet överhuvudtaget skulle kunna testköras. Kundansvarig uppfattade att arbetet skulle ta en eftermiddag och föreslog tillsammans med kund att vi skulle samla in 10 minuter tal. Problemet var att kundansvarig trodde att vi endas skulle behöva spela in talet. I verkligheten behövde vi klippa ut varje ord för sig, vilket även det skulle tagit orimligt med tid. Vid leverans hade vi klippt upp ungefär 2 minuter tal. Resultatet av detta är att vårat system inte kan spela upp rörelser och inte heller skapa speciellt mycket tal utan kunden ska behöva utöka databasen för att kunna göra detta. Dessa var två viktiga krav för kunden. Vad vi lärde oss av detta är att be om precis all information direkt, låt inte kunden avgöra vad som är lätt eller svårt eller bestämma när ni behöver något. Kundansvarig skulle givetvis ha pressat kunden till att ge oss koden till Orator istället för att bara vänta. 4 Kapitel 2: Projektbeskrivning

13 3 Projekterfarenheter, fasvis 3.1 Total tidsförbrukning I tabell 2 redovisas hur mycket tid som planerats för de olika faserna samt hur mycket tid projektgruppen lagt ner på varje fas. Vi har valt att kalle en fas projektledning som går parallellt med alla andra faser genom hela projektet. Här finns bland annat organisatoriska bitar samt möten. Här finns även projektplanen eftersom tanken var att vi skulle uppdatera den under hela projektets gång. Fas Planerad tid Reviderad tid Verklig tid Tabellen visar att planeringen varit väldigt felaktigt i vissa faser. Framförallt beror detta på att projektgruppen inte hade någon riktig erfarenhet av denna typ av arbete vilket gjorde det väldigt svårt att uppskatta tidsåtgången. Vi hade även problem att få ett bra system för tidsredovisningen. Detta påverkade den reviderade tidsplanen, som annars borde gett en bättre uppskattning. Den fas som överskridit planeringen mest är projektledningsfasen. Detta var däremot väntat då möten, kontinuerlig revision av projektplanen och alla möjliga typer av organisatoriskt arbete är svåra att uppskatta. Nu i efterhand verkar det som vi kanske gjorde det något svårt för oss genom att lägga så mycket arbete i denna fas. I förstudie- och definiftionsfasen har det faktum att dokumentmallar blev klara sent och att vi var tvungna att göra en revision av kravspecifikation gjort att dessa faser överskridit den reviderade tidsplanen även då dessa faser var klara då den planeringen gjordes. Förutom planeringsmissar hade projektgruppen dragit ner på tempot i slutet av projektet. Orimliga krav från kund gjorde att motivationen i princip var slut. Förutom dålig planering har detta bidragit till att testfasen ligger under planerad tid. Sedan skall nämnas att endast tiden tillvecka 50 redovisas i dessa tabeller och att arbete på efterstudien har lagts ner efter detta. Förstudiefas ,5 Definitionsfas ,5 Designfas ,5 Implementationsfas Testfas ,5 Kvalitetsarbete ,5 Projektledning Avslutningsfas TOTALT ,5 Tabell 2: Tidsfördelning över faserna Kapitel 3: Projekterfarenheter, fasvis 5

14 Tabell 3 visar hur mycket varje roll lagt ner på de olika faserna. Fas PL KUN KVA DES IMP TEST DOK SYS Förstudiefas 4 4, ,5 7,5 21,5 5,5 Definitionsfas , Designfas , Implementationsfas ,5 50, Testfas , Kvalitetsarbete Projektledning , ,5 36 Avslutningsfas ,5 10, TOTALT Tabell 3: Tidsfördelning över rollerna 3.2 Förstudiefasen Den första fasen döpte vi till förstudiefasen eftersom fasens huvudinnehåll var studier av olika slag. Fasen startade innan den ens var genomtänkt med att några i gruppen fick gå på de inplanerade funktionsmötena. Dagen efter hade gruppen ett möte där vi fördelade ansvarsområden och valde projekt. Fasen började på allvar efter projektutdelningen med att alla fick i uppgift att börja läsa om projektet och börja sätta sig in mer i sina ansvarsområde genom att läsa exempeldokument och aktuella rutar. Förutom studier skulle vi under fasen framställa dokumentmallar men pga dokumentansvariges plötsliga sjukdom och en dålig kommunikation inom gruppen blev de mallarna kraftigt försenade. De gruppmedlemmar som hade dokument att skriva löste det genom att använda temporära mallar från tidigare år Tidsförbrukning Förstudiefasen Aktivitet Planerad tid Verklig tid Funktionsmöten 17 13,5 Projektuppgifts-studier 16 13,5 Utb. Framemaker 5 9 Utb. versionshantering 4 4 Dokumentmallar 5 16,5 TOTALT 47 56,5 Tabell 4: Tidsförbrukning aktivitetsvis 6 Kapitel 3: Projekterfarenheter, fasvis

15 Projektroll Planerad tid Verklig tid PL 4 4 KUND 4 4,5 KVAL 7 4 DES 5 3 IMP 6 6,5 TEST 7 7,5 DOK 10 21,5 SYS 4 5,5 TOTALT 47 56,5 Tabell 5: Tidsförbrukning rollvis Som vi ser i tabell 4 så stämmer den inplanerade tiden hyfsat för alla aktiviteter förutom dokumentmallar. Eftersom DOK blev sjuk bidrog det till extra arbete för honom när han kom tillbaka eftersom han blev tvungen att sitta och fixa till de halvfärdiga mallarna innan han började med de mallar som gruppen använde sig av för de senare dokument som skrevs. Värt att nämna om de övriga aktiviteterna är att de inplanerade funktionsmötena blev kortare än vad som stod i schemat Erfarenheter Detta var den tidsmässigt kortaste fas men ändå väldigt nyttig för vi lärde oss tidigt att kommunikationen är en av de viktigaste faktorerna för att man skall kunna genomföra ett projekt. Dessutom lärde vi oss vikten i att utse viceansvariga tidigt i projektet, helst i samband med val av huvudansvariga. Gruppen hade varken hunnit utse det eller skaffa sig vettiga kommunikationsrutiner vilket bidrog till en kraftig försening av dokumentmallar. Detta blev dock inte blodigare än att dokumentansvarig fick lägga ner mer än dubbelt så mycket tid som det i början var inplanerat för honom. Gruppen tog lärdom av sina misstag och lade om sina kommunikationsrutiner. Dessutom fick vi ett ypperligt tillfälle att finslipa på vår kreativitet förmåga och kvickhet att hitta alternativa lösningar på problem. Inga deadlines på dokument påverkades av förseningen av mallarna och träningen visade sig vara väldigt nyttigt senare i projektet. 3.3 Definitionsfasen Vi valde att att kalla fasen där vi mötte kunden och tog fram kraven för definitionsfasen. Parallellt med denna fas skedde även aktiviteter i projektledningsfasen som till exempel projektplanering. Definitionsfasen startade redan efter första veckan med ett inledande kundmöten. När dessa var klara och alla riktlinjer för dokument var satta påbörjades arbetet med kravspecifikationen som är det viktigaste momentet i definitionsfasen. En viktig aktivitet som skedde under denna fas var givetvis kundmötena. Denna aktivitet har vi dock valt att lägga i projektledningsfasen eftersom både den och kundmöten sträcker sig över hela projektet. Kapitel 3: Projekterfarenheter, fasvis 7

16 3.3.1 Tidsförbrukning Definitionsfasen Aktivitet Planerad tid Verklig tid Kravspecifikation 75 72,5 Seminarium kravspec Presentation kravspec Opponering kravspec TOTALT ,5 Tabell 6: Tidsförbrukning aktivitetsvis I tabell 6 - aktiviteter redovisas tider för definitionsfasens olika aktiviteter. Dessa aktiviteter var bevisligen inte så svåra att uppskatta. Presentation och opposition är de som tagit längre tid än beräknat och de kunde säkert tagit ännu mer tid om vi inte medvetet begränsat oss. Överraskande nog gick kravspecifikationen snabbare att skriva än vad vi först trodde. Tiden för kommentering och inspektion av kravspecifikationen ligger i fasen kvalitetsarbete. Projektroll Planerad tid Verklig tid PL 2 2 KUND KVAL 7 11 DES 2 2 IMP 7 7 TEST 2 4,5 DOK 2 2 SYS TOTALT ,5 Tabell 7: Tidsförbrukning rollvis Det är framförallt KUND och SYS som jobbat med kravspecifikationen och presentationen. Deras tid var svårast att uppskatta och det är därför deras tid stämmer sämst överens med den planerade tiden. Som sagt så var dessa aktiviteter ganska lätta att planera och hålla sig inom tidsramen för Erfarenheter I början av definitionsfasen var det mycket arbete som skedde parallellt. Kvalitetsplan och projektplan skulle skrivas samtidigt som vi skulle ta reda på vad vi egentligen skulle utveckla. Vissa fick en mycket hektisk start på projektet medans andra inte behövde göra speciellt mycket. Kundansvarig och systemansvarig gick på samtliga kundmöten och skrev stora delar av kravspecifikationen tillsammans. Att vara två innebär många 8 Kapitel 3: Projekterfarenheter, fasvis

17 fördelar. Om vi till exempel hade olika uppfattningar om vad som sagts på ett kundmöte var det bara att ta upp frågan på nytt för att undvika missförstånd. En annan anledning till att denna fas gick bra var att vi tidigt tog kontakt med kunden och började skissa på kraven. I början hade vi många med kunden eftersom vi var helt nya på kundens område. 3.4 Designfasen När vi arbetade fram tidsplanen i början av projektet var designfasen den fas som vi planerade att lägga mest timmar på. Detta för att få en väl genomtänkt design av systemet som sedan förhoppningsvis skulle gå att implementera mer eller mindre automatiskt genom att följa designdokumenten Tidsförbrukning Designfasen Aktivitet Planerad tid Verklig tid Arkitekturspecifikation Designspecifikation Presentation arkspec Opponering arkspec Seminarium arkspec Insamling av data 44 37,5 Programmeringshandbok 11 7 TOTALT ,5 Tabell 8: Tidsförbrukning aktivitetsvis Projektroll Planerad tid Verklig tid PL KUND 19 7 KVAL 14 2 DES ,5 IMP TEST 7 7 DOK SYS TOTALT ,5 Tabell 9: Tidsförbrukning rollvis Kapitel 3: Projekterfarenheter, fasvis 9

18 3.4.2 Erfarenheter Som tabellerna i kapitel visar så lade vi nästan 100 timmar mindre än planerat under denna fas. Det beror troligen på att dessa siffror planerades när vi fortfarande inte hade riktigt koll på vad det egentligen var för system vi skulle utveckla och att vi under arbetets gång upptäckte att det rörde sig om ett relativt enkelt projekt i lite mindre skala. Hade uppgiften varit mer komplicerad hade dessa siffror troligtvis varit mer realistiska och kanske till och med en underskattning. Värt att notera är att aktiviteten Insamling av data inte fanns i den ursprungliga tidsplanen. Detta moment uppkom under arbetets gång till följd av ett krav som kunden ställde. En erfarenhet att tänka på är alltså att redan i projektuppstarten försöka ha en så god kontakt med kunden som möjligt för att hitta eventuella projektspecifika aktiviteter som kommer ta en ansenlig mängd tid. Detta hade vi inte en tanke på under projektets första veckor. 3.5 Implementationsfasen Syftet med implementationsfasen var att realisera alla moduler i designen i programkod, enhetstesta dessa och slutligen integrera dem till det färdiga systemet. Fasen var indelad i tre moment: utbildning, implementation av moduler och integration. Under utbildningsmomentet skulle all väsentlig information om fasens organisation, arbetsplanering och nödvändiga förkunskaper spridas till projektgruppens medlemmar. Implementation och enhetstestning av moduler skulle genomföras i självständigt arbetande undergrupper där alla utom projektledaren skulle deltaga. Varje grupp ansvarade för en väl avgränsad delmängd av hela systemet. Grupperna övervakades och stöttades av implementationsansvarig. Integrationsmomentet innebar att de färdiga modulerna skulle sättas ihop till ett fungerande system samt att alla eventuella fel som uppstod då skulle rättas till. 10 Kapitel 3: Projekterfarenheter, fasvis

19 3.5.1 Tidsförbrukning Implemenationsfasen Aktivitet Planerad tid Verklig tid Utbildning Impl. av moduler Integration TOTALT Tabell 10:Tidsförbruknings aktivitetsvis Projektroll Planerad tid Verklig tid PL 0 0 KUND KVAL DES 0 15,5 IMP 47 50,5 TEST DOK SYS TOTALT Tabell 11: Tidsförbrukning rollvis Implementation tog något mer tid än beräknat. Detta berodde framför allt på två saker. Den första var att designansvarige deltog i arbetet något som inte planerats från början. Detta visade sig vara nödvändigt för att kunna göra en bra gruppindelning och fördelning av de moduler som skulle implementeras. Slutligen visade det sig att arbetet på databasen var mycket mer omfattande än beräknat vilket ledde till att systemansvarig som arbetade med det tvingades lägga ner mer arbete än planerat. Kapitel 3: Projekterfarenheter, fasvis 11

20 3.5.2 Erfarenheter De viktigaste erfarenheterna av den här fasen är av att integrera dokumentations- och testarbetet på ett bra sätt. Testarbetet påbörjades på allvar först efter att all kod var färdigskriven och den hade då i stor utsträckning redan informellt testats. Arbetet med systemförvaltningsdokumentationen påbörjades först när allt var i princip färdigt och innebar att delar av implementationen dokumenterades i efterhand. Det hade varit mycket effektivare och gett ett mycket bättre resultat om den hade påbörjats under slutet av designfasen och de tre faserna sedan utförts parallellt med tydliga riktlinjer. Om riktlinjer för dokumentationen och testskript varit tillgängliga från början av implementationen hade detta inte varit fallet. 3.6 Testfasen Testfasen inleddes en vecka senare än planerat. Detta på grund av att implementationen endast hade lösa deadlines och alla implementerare tog i princip maximal tid på sig. Tanken var att man skulle börja testa moduler utan någon speciell ordning, så fort de blev klara. Detta visade sig pga detta vara omöjligt. En lärdom som man kan dra av detta är att i framtida projekt planera in strikta deadlines för respektive modul, så man verkligen kan inleda testarbetet i god tid. Å andra sidan så var modulerna väl enhetstestade innan de gick vidare till formellt modultest och detta kortade ner det totala testarbetet en hel del Tidsförbrukning Testfasen Aktivitet Planerad tid Verklig tid Utbildning test Testplanering 20 42,5 Modultest Integrationstest Systemtest Acceptanstest Uppföljning/revidering TOTALT ,5 Tabell 12:Tidsförbrukning aktivitetsvis Totalt sett gick testarbetet snabbare än planerat. Det enda som tog längre tid var testplaneringen och framtagningen av testplanen. Att det gick snabbare beror troligen på att implementerarna enhetstestade sina moduler mer noggrant än det egentligen var tänkt. När den formella testningen väl tog vid var det väldigt få fel som upptäcktes och dessa gick snabbt att rätta till. 12 Kapitel 3: Projekterfarenheter, fasvis

21 Tabellen nedan har den verkliga tiden för respektive projektmedlem Projektroll Planerad tid Verklig tid PL 6 7 KUND KVAL 23 0 DES 24 16,5 IMP TEST DOK 19 0 SYS 14 8 TOTALT ,5 Tabell 13: Tidsförbrukning rollvis Den totala tidsåtgången per person blev kortare än planerat. De största skillnaderna mot planen är att KVAL och DOK inte alls var involverade i testarbetet, på grund av tung belastning av andra projektmoment Erfarenheter Testfasen kom som sagt igång senare än planerat. Dock var det väldigt få fel och buggar som upptäcktes. Detta tror vi beror på att mycket av testarbetet utfördes informellt, under implementationen. I framtiden bör man dock låta formell testning stå för detta. Om varje implementerare testar mycket själv riskerar man att inte upptäcka vissa typer av fel och man får även dålig överblick över hur väl testat systemet faktiskt är. En sak som vi har lärt oss är alltså att ha strikta deadlines för implementationen, kanske tom på modulbasis, så att testarbete kan inledas i god tid. En annan sak är att dra klara gränser mellan test och implementation och göra alla projektmedlemmar medvetna om var det ena slutar och det andra tar vid. På så sätt försäkrar man sig om att de formella testmetoderna verkligen utnyttjas. Kapitel 3: Projekterfarenheter, fasvis 13

22 3.7 Kvalitetsarbete Parallellt med allt övrigt projektarbete arbetade vi med kvaliteten för att få en så bra kvalitet på hela projektet och slutprodukten som möjligt. Den största delen av kvalitetsarbetet har gått åt till granskning av dokument men även till framställningen av kvalitetsplanen. Kvalitetsarbetet har även innefattat granskning av varje respektive fas efter fasens slut Tidsförbrukning Kvalitetsarbetet har tagit något längre tid än planerat, inte minst framställning av kvalitetsplanen och de tre kvalitetsrapporterna som skrevs under projektets gång. Det var svårt att i projektets inledning uppskplan och kvalitetsrapporter. Övrigt kvalitetsarbete tog planerad tid och för fasgranskningarna till och med något kortare tid än planerat. Kvalitetsarbete Aktivitet Planerad tid Verklig tid Inspektionshandbok 5 5 Övergripande tidsplan 6 18 Kvalitetsplan 22 41,5 Kvalitetsrapportering ,5 Inspektionsarbete 66 66,5 Fasgranskning TOTALT ,5 Tabell 14:Tidsförbrukning aktivitetsvis Projektroll Planerad tid Verklig tid PL KUND 12 4 KVAL ,5 DES IMP TEST DOK SYS 12 6 TOTALT ,5 Tabell 15: Tidsförbrukning rollvis 14 Kapitel 3: Projekterfarenheter, fasvis

23 Flertalet projektmedlemmar lade ner ungefär planerad tid på kvalitetsarbete men för KVAL blev det ganska mycket mer än planerat, likaså för DOK som vid några tillfällen fick hjälpa kvalitetsansvarige med kvalitetsplan respektive kvalitetsrapporter Erfarenheter Vi har lärt oss att fortlöpande kvalitetsarbete under hela projektet är mycket viktigt för att få ett effektivt projekt och en bra slutprodukt med hög kvalitet som kunden är nöjd med. Det har varit mycket bra att göra interna revisioner och på så sätt hitta brister i projeketet. Den första interna revisionen utfördes mycket tidigt och ledde bland annat till upptäckt av brister i kvalitetsarbetet som snabbt kunde åtgärdas. Projektets hemsida och en del dokument har också uppdaterats efter interna revisioner. Vi lärt oss att det är viktigt att hålla interna deadlines för dokument för att ge oss tid till kommentering och inspektion och det har ibland brustit vilket har lett till inspektioner som har tagit onödigt lång tid på grund av utebliven kommentering. En ordentlig planering där tid ges till kommentering sparar tid. Vi har även lärt oss vikten av att sätta upp interna deadlines för allt övrigt arbete så att risken för att överskrida externa dealines kan minskas. Det har lett till mindre problem med tidsbrister och lidande kvalitet. 3.8 Projektledning Projektledning var precis som kvalitetsarbetet en fas som löpte igenom hela projektet och innehöll projektplans och systemförvaltnings-skrivande, administrativa arbeten och möten. Projektplanen var ett av de första dokumenten som framställdes i projektet och har varit stommen i projekts- och tidsplaneringen i hela projektet. Tidsplaneringen var den svåraste delen i hela dokumentet att framställa, aktiviteterna var svåra att uppskatta och mycket arbete fick läggas ner på just den delen. Projektledaren gav varje fasansvarig i uppgift att uppskatta sin fas och sammanställde allt efteråt. Anledningen till att projektledningsfasen fick innehålla möten var att de var aktiviteter som förekom i alla faser. Detta skulle delvis bidra till att gruppen skulle få en bättre bild över mötena och slippa binda dem till en enskild fas. Vad gruppen hade missat var att gruppmötena skulle vara veckovisa. Kapitel 3: Projekterfarenheter, fasvis 15

24 3.8.1 Tidsförbrukning Projektledning Aktivitet Planerad tid Verklig tid Projektplan 52 51,5 Revidering av projektplan Systemförvaltningsdok ,5 Presentation projektplan 10 15,5 Opponering projektplan Seminarium projektplan Administration Gruppmöten Kundmöten 39 21,5 TOTALT Tabell 16: Tidsförbruknings aktivitetsvis Projektroll Planerad tid Verklig tid PL KUND KVAL DES IMP 22 32,5 TEST DOK 32 63,5 SYS TOTALT Tabell 17: Tidsförbrukning rollvis Detta var sammantaget den sämst planerade fasen. Aktivitetsvis tog aktiviteter förutom ungefär lika mycket tid som de hade tilldelats. Den aktivitet som inte alls höll sig inom felmarginalen var gruppmöte som var mer än 100 procent fel. Detta berodde dels på att vi hade missat att de skulle förekomma veckovis och dels för att det var vädligt svårt att uppskatta tidsåtgången på mötena Erfarenheter Ett problem var att gruppen underskattade hur långt tid ett möte egentligen tar. Vad man borde dra lärdom av är att planera och lägga upp mötena ordentligt så att man minimerar tidsåtgången och effektiviserar dem. Detta gjordes senare i projektet och mötena kortades ner till under 45 min. 16 Kapitel 3: Projekterfarenheter, fasvis

25 3.9 Projektavslutningsfasen Denna fas var tänkt att ta vid när vi var klara med implementation och kände att vi hade en färdig produkt att leverera. De två största momenten i fasen var att leverera produkten till kunden och skriva efterstudien. Denna fas pågick alltså när detta dokument skrevs och därför är inte tiderna i denna fas helt korrekta Tidsförbrukning När vi gjorde tidsplanen för avslutningsfasen missade vi förberedelserna för presentationen. Därför har den verkliga tiden för denna aktivitet blivit längre än planerat. Vid leverans var det några saker som kunden ville att vi skulle rätta till. Denna tid lade på aktiviteten Leverans-förberedelser. Därför gick även den tiden över den planerade. Avslutningsfas Aktivitet Planerad tid Verklig tid Avslutningsgruppmöte 24 0 Demonstration 16 31,5 Leverans förberedelser Efterstudiedokument 40 23,5 Projektledning 3 2 Kundkontakt 8 0 TOTALT Tabell 18: Tidsförbruknings aktivitetsvis Projektroll Planerad tid Verklig tid PL KUND KVAL 10 6 DES 10 4,5 IMP 10 10,5 TEST 10 4 DOK 18 4 SYS TOTALT Tabell 19: Tidsförbrukning rollvis Kapitel 3: Projekterfarenheter, fasvis 17

26 3.9.2 Erfarenheter Den planerade tiden för efterstudien var något i underkant. Tiden kommer dra iväg när detta dokument blir färdigt. Detta beror på att efterstudien är ett stort dokument med mycket ny text som skall produceras. Texten i detta dokument kommer från alla projektmedlemmar vilket gör att tiden drar iväg. Avslutningsfasen har för vissa projektmedlemmar varit en hektisk fas. Vår grupp har under projektets gång haft problem med vår tidsredovisning. Detta gjorde att det blev mycket jobb för att sammanställa tiderna för detta dokument. Ett tips till kommande projektgrupper är att ha bra koll på sin tidsredovisning och noga skriva upp i vilken aktivitet timmarna lades. Detta gör sammanställningen av efterstudien betydligt mycket enklare. 18 Kapitel 3: Projekterfarenheter, fasvis

27 4 Projekterfarenheter, aktivitetsvis 4.1 Utbildning Intern utbildning En internutbildning i Framemaker hölls två veckor in i projektet. Dokumentationsansvarig gick igenom de viktigaste grunderna i Framemaker och gick igenom vilka mallar som skulle användas och hur de skulle användas för det aktuella projektet. Utbildningen hölls i en datasal på IDA med tillgång till Framemaker. Att genomföra utbildningen i en datasal där alla deltagarna satt med Framemaker och provade alla moment vartefter de gicks igenom fungerade bra. Kunskaperna fastnade tillfredsställande hos deltagarna i och med att de praktiskt fick prova alla handgreppen. I efterhand kan man se att det skulle ha varit bra med en kort uppföljning och repetition. Längre fram i projektet, i samband med implementation, hölls en kort distansutbildning i CVS via e-post. Alla projektmedlemmar deltog inte vilket tyvärr var lite synd för det hade underlättat senare arbete något. Ändringar och incheckningar av nya ändringar i programkoden hade gått smidigare. En intern inspektionsutbildning hölls av kvalitetsansvarige i samband med de första inspektionerna som en del av kvalitetsarbetet. Vid samma tillfällen utbildade dokumentansvarige i användandet av korrekturstandarden SIS Utbildningarna som helhet var effektiva och sparade tid jämfört med om var och en hade genomfört självstudier i samma ämne. I framtida projekt är det bra att genomföra flera välplanerade korta utbildningar på de verktyg som skall användas av flera personer i projektgruppen. Det är även viktigt att skriftlig dokumentation finns att tillgå efter kursen så att det finns möjlighet att gå tillbaka i efterhand och repetera Självstudier Mycket av inlärningen av sådant som framförallt berörde en eller några få personer skedde genom läsning av RUT:ar som är dokument skrivna av tidigare projektgrupper. Kvaliteten på dessa varierade men var över lag bra och de var i allra högsta grad användbara i projektarbetet. Som tips inför framtida projekt så är det bra att läsa alla RUT:ar som handlar om det som rör ens roll i projektet. 4.2 Dokumentframställning Dokumentmallar På grund av sjukdom blev mallarna försenade vilket gjorde att när projektplanen och kvalitetsplanen skulle skrivas så fanns inga färdiga mallar. Dokumenten fick skrivas med tillfälliga mallar och senare lyftas över till de riktiga mallarna. Framställningen av mallarna gick bra då det fanns väl fungerande gamla mallar att utgå från. Under projektets gång uppdaterades mallarna med bland annat automatiskt datum i sidhuvudet, bortrensande av några trasiga korsreferenser etc. Kapitel 4: Projekterfarenheter, aktivitetsvis 19

28 Så här i efterhand kan man se att goda och grundläggande kunskaper i Framemaker hade underlättat och snabbat upp framställandet av mallar. Helt färdiga mallar i början av projektet är bra och underlättar dokumentskrivandet för alla. Då går det att ha en genomgång av mallarna och användandet av dem redan innan första dokumentet påbörjas. På så sätt vet alla hur verktyg och mallar fungerar. Är mallarna färdiga i tid behöver inga dokument uppdateras i efterhand för att anpassas efter den nya uppdaterade mallen Dokumentskrivning Varje dokument har haft en redaktör som har ansvaret för framställningen av det dokumentet. Redaktören hade ansvar själv för att ta hjälp av övriga gruppmedlemmar genom att delegera arbetsuppgifter då han ansåg att arbetsbelastningen annars skulle bli för stor. Vi har lärt oss att det är otroligt viktigt att tidigt delegera arbetsuppgifter eftersom detta leder till ett bättre dokument samt att arbetsförhållanden blir bättre i och med att stress och frustration minskas. I vissa fall i början tog redaktören på sig för mycket av arbetet själv vilket resulterade i ett dåligt initialt resultat. Detta gjorde att vi i fortsättningen delegerade och planerade arbetsuppgifter mer noggrant. När redaktören delegerar en arbetsuppgift är det väldigt viktigt att det inte finns några oklarheter om vad arbetsuppgiften innebär. När man skriver ett dokument som skall examineras är det viktigt att så noga som möjligt följa de riktlinjer kursledningen gett. Ibland var informationen från kursledningen lite oklar och i dessa fall har vi tagit hjälp av gamla exempeldokument vilket varit till stor hjälp. 4.3 Presentationer och opponeringar Under projektets gång genomförde vi ett antal muntliga presentationer. Dels så presenterade vi våra egna dokument och dels opponerade vi på andras. För att göra en bra presentation krävs en del förarbete. Dels måste man läsa in sig på materialet, identifiera målgruppen och vilka delar av materialet som är relevant för just dem. Dels så måste man hitta en lagom detaljerad nivå och därefter göra en bra disposition på det material man väljer att presentera. Vi arbetade alltid två och två med presentationerna och gjorde provpresentationer inom gruppen där de andra agerade publik och kom med synpunkter. Det fungerade bra och hjälpte ovana talare att slappna av mer och kunna arbeta på sin presentationsteknik Positiva erfarenheter Att kunna hålla ett bra muntligt föredrag är mycket viktigt. Vi tyckte att det var nyttigt att arbeta med detta. Alla gruppens medlemmar har genomfört minst en presentation så alla har fått öva. Dessutom fick alla prova på att arbeta med presentationsprogram såsom Microsoft PowerPoint och OpenOffice Impress. Slutligen fick vi bra och konkreta tips av vår handledare om struktur, genomförande och viktiga detaljer att tänka på Negativa erfarenheter Många i gruppen kände att det här var ett lite obehagligt moment som vi inte arbetat med särskilt mycket tidigare. Vi hade gärna sett att det givits någon form av seminarium, föreläsning eller kort genomgång av presentationsteknik hur en bra disposition ser ut. Den handledning som fanns på kurshemsidan var inte tillräckligt. 20 Kapitel 4: Projekterfarenheter, aktivitetsvis

29 En annan negativ erfarenhet vi haft under presentationerna var att det svåraste inte var att göra en bra presentation utan att tolka de otydliga scenariobeskrivningarna rätt. 4.4 Implementation Delmoment Enligt projektplanen var implementationsfasen indelad i tre stycken delmoment; utbildning, implementation och integration. I följande avsnitt beskrivs hur arbetet var organiserat och vad som gjordes i de olika delmomenten samt vad som gick bra och vad som inte gjorde det Erfarenheter I projektplanen hade det inte planerats någon tid för implementationsansvarige att lägga på handledning och projektledning under implementationsarbetet. Denna tid fick nu tas ifrån andra moment. Efter att implementationen avslutats visade det sig att även om vi implementerat alla moduler enligt både arkitektur- och designspecifikationer och uppfyllt baskraven i kravspecifikation så fanns det ett stort behov av att förbättra och förändra det färdiga systemet innan det motsvarade kundens önskemål. Därför hade det behövts ytterligare tid och ett nytt delmoment förslagsvis kallat "färdigställning" Organisation Eftersom vår arkitektur och design var väldigt modulär kunde de olika delarna i systemet utvecklas helt oberoende av varandra. Därför skapades tre stycken implementationsgrupper och systemets olika moduler fördelades mellan dessa. Tanken var att grupperna skulle arbeta var för sig och att implementationsansvarige skulle ha det övergripande ansvaret för att följa upp arbetet, ha den övergripande bilden av arbetet och bistå grupperna med hjälp där det behövdes. Detta innebär att implementationsansvarige får en nyckelroll under implementationsarbetet och att hela arbetet kraschar ifall denne blir sjuk eller på något annat sätt oförmögen att delta i arbetet Erfarenheter Gruppindelningen och fördelningen av modulerna visade sig vara väldigt lyckad. Samtliga grupper kunde slutföra sin del på utsatt tid och utan att överskrida tidsplanen i någon större utsträckning. Dessutom kunde grupperna arbeta helt oberoende av varandra vilket innebar att de kunde planera sitt eget arbete så effektivt som möjligt utan att hindras av andra Utbildning Enligt projektplanen skulle första momentet i implementationsfasen vara utbildning på det versionshanteringssystem för kodhantering som skulle användas samt en genomgång av programmeringshandboken Erfarenheter Programmeringshandboken blev inte klar i tid istället användes till en början ett snabbskrivet kompendium som skickades ut via e-post, och som imple- Kapitel 4: Projekterfarenheter, aktivitetsvis 21

30 mentationsgrupperna studerade självständigt.. Detta visade sig dock vara fullt tillräckligt för att genomföra arbetet så förseningen blev inget stort problem i praktiken Modulimplementation Modulimplementationen gjordes i tre grupper som arbetade oberoende av varandra. Detta fungerade bra. Några små ändringar fick göras i arkitekturoch designdokumenten men inget som påverkade projektet som helhet Erfarenheter På grund av att modulerna implementerades oberoende av varandra blev alla implementationsgrupper tvungna att i viss mån skriva små ramverk för att kunna provköra sina egna delar. Detta eliminerade många fel som annars skulle ha hittats först senare. En annan fördel blev då att modulernas gränssnitt verifierades mot det som stod designspecifikationen istället för mot den kod de andra gruppernas implementerat. En nackdel med den testning som genomfördes av grupperna under modulimplementationen var att den var okoordinerad och inte dokumenterad. Det hade varit bättre om testfasen påbörjats tidigare och de systematiska testerna gjorts parallellt med implementationen. Över huvudtaget var samarbete och koordination mellan test- och implementations-faserna dålig Integration Syftet med integrationen var att sammanfoga alla de moduler som implementerats till en fungerande applikation, rätta eventuella fel och producera ett körbart system Erfarenheter Till vår stora förvåning gick detta moment väldigt fort. Delmodulerna var i stort sett felfria och fungerade nästan direkt med varandra. Vi tillskriver detta faktum till tydlig och enkel arkitektur, bra design och väl genomförd modulimplementation. Det färdiga systemet motsvarade inte våra förväntningar och hade en del "vassa kanter". Även om det uppfyllde alla krav och designanvisningar vi tagit fram så fanns det arbete kvar att göra. Detta är ett resultat av att delarna utvecklats oberoende av varandra. För att en sådan metodik skall fungera måste ytterligare ett delmoment, som nämnts tidigare, införas i implementationsfasen. Att efter integrationen färdigställa systemet. 22 Kapitel 4: Projekterfarenheter, aktivitetsvis

31 4.5 Design Vi bestämde oss för att dela upp designfasen i tre större aktiviteter, som alla tre syftade till att producera ett specifikt dokument. Dessa tre kommer att presenteras närmare i detta kapitel Arkitekturspecifikation I kronologisk ordning var den första aktiviteten att framställa en arkitekturspecifikation som utgående från kravspecifikationen skulle ge en grov överblick över den tänkta systemdesignen. Implementationsansvarig hade en mycket genomtänkt bild av hur han ville att systemet skulle se ut och som redaktör för dokumentet tog han fram en objektorienterad arkitektur som resten av gruppen sedan godtog. Tack vare att det system vi skulle utveckla var relativt okomplicerat lyckades vi få fram en mycket väl detaljerad arkitektur på mycket snabbare tid än vad som var planerat i tidsplanen Designspecifikation Arbetet från arkitekturen togs sedan över av designansvarig som producerade en mer detaljerad designspecifikation. Även detta moment tog mindre timmar i anspråk än vad som först var planerat i tidsplanen. Det dokument som togs fram fick sedan under själva implementationen genomgå en del förändringar på grund av mindre genomtänkt design, men detta får anses som rutinarbete vid programvarutveckling och i det stora hela fungerade designen tillfredsställande. Det kan ibland verka svårt att avgöra var man skall dra gränsen mellan att få fram ett tillräckligt detaljerat designdokument utan att samtidigt låsa in implementeraren i ett hörn eller kanske till och med lösa uppgiften åt honom. Vår design var helt klart i den lösare ändan av skalan och det kunde ha lönat sig att styra lite mer med framförallt hur fel skulle hanteras i de olika modulerna Programmeringshandbok Under planeringen av projektet bestämdes att en programmeringshandbok skulle tas fram under designfasen för att underlätta den efterföljande implementationen. Resultatet av detta arbete blev inget formellt dokument, utan snarare några riktlinjer som implementerarna blev uppmanade att följa. Om en mer detaljerad programmeringshandbok hade tagits fram kunde vi undvikit några problem som vi stötte på där kod delvis fick redigeras av andra implementerare Sammanfattning Designfasen var en relativt stor del av projeketet, men långt ifrån alla gruppmedlemmar var inblandade i designarbetet. Detta skapade en viss förvirring när implementationen skulle ta vid, men de eventuella negativa påföljder detta hade tror gruppen vägdes upp av det positiva i att ha få personer insatta i designutvecklingen och på så sätt få ett effektivare arbete. Av någon anledning blev arbetet med arkitektur och design uppdelat mellan IMP och DES. Detta kan visserligen ses som en fördel för det avlastade arbetsmängden för båda personerna i just denna fas, men det hade varit bättre om en person hade varit ytterst ansvarig för båda dessa aktiviteter. Den personen Kapitel 4: Projekterfarenheter, aktivitetsvis 23

32 hade inte behövt stå som redaktör för båda dokumenten, men i alla fall lett arbetet för att på så vis få en bättre kontinuitet i arkitektur och designarbetet. 4.6 Testarbet Här sammanställs erfarenheter från det testarbete som utförts under projektets gång. För mer detaljerad information angående själva testplaneringen se Testplan [Janowski, 2005]. För att få en mer detaljerad redogörelse över testresultatet se Testresultat [Janowski, 2005] Testmetod De testmetoder som användes under testfasen visade sig att fungera bra. Tanken var att fokusera på svartlådetest och noggrant testa funktionaliteten hos systemet, med hjälp av både korrekt och felaktig indata. Eftersom ingen kritisk kod eller modul kunde identifieras i systemet valde man att inte göra några vitlådetest. Såhär i efterhand ser man att man ändå kunde ha valt vissa delar av koden och granskat dem. Exempelvis hade man kunnat kodgranska felhantering och andra delar av koden som är svåra att nå och testa med hjälp av externa testprogram. Vitlådetest hade troligen haft positiv inverkan på tillräckligheten av testarbetet Testplan Testarbetet utfördes enligt Testplanen [Janowski, 2005] i den mån det var möjligt. Testfallen följdes under framtagning av testskript och testprogram. Dock var det svårt att på förhand skriva fullständiga och korrekta testfall, dels för att designen blev färdig relativt sent och dels för att den ändrades radikalt under implementationen. Testplanen fick uppdateras flera gånger och testfallen fick kompletteras. Bl a hade vi missat att ta med tillräckligt med felaktig indata i testerna Testresultat Relativt få fel upptäcktes under testarbetet. Detta skulle dels kunna bero på att det utvecklade systemet var relativt litet och dels på att mycket testarbete utfördes implicit, av implementerarna själva. I tabellen nedan återfinns alla fel som upptäckts:: Testfas Antal Modultest 1 Integrationstest 2 Systemtest 7 Acceptanstest 0 Summa 10 Tabell 20: Antal fel Eftersom projektgruppen saknade erfarenhet av formellt testarbete var det svårt att avgöra var implementation slutar och testning börjar. Detta ledde till att ingen implementerare lämnade ifrån sig en modul som denne själv inte testat utförligt, vilket också återspeglas av det faktum att endast ett fel upptäcktes under modultestningen. De flesta implementerare skrev t ex egna stubbar och 24 Kapitel 4: Projekterfarenheter, aktivitetsvis