Projektplan. Sammanfattning. Redaktör: Ali Aghajani Version: I Tal-Lab kan ingen höra dig skrika

Transkript

1 Projektplan Redaktör: Version: 2.2 I Tal-Lab kan ingen höra dig skrika Sammanfattning Projektgruppen har fått till uppgift att skriva en modul till systemet Orator, en mjukvara för talsyntes. Modulen ska utifrån en given text som indata generera tal och även synkronisera talet till en ansiktsmodell. Kunden är Bertil Lyberg och Mustapha Shkiri på Instutionen för datavetenskap vid Linköpings universitet. Syftet med dokumentet är att tillhandahålla information för projektgruppen, kunden och kursledningen om hur projektet är organiserat och vilket arbetssätt som tillämpas inom och utanför projektgruppen. Projektplanen innehåller information så som ansvarområden, risker och riskhantering, hur dokument ska hanteras och vilka resurser som finns tillgängliga. I dokumentet finns även en tidsplan där viktiga datum som deadlines och milstolpar tas upp. Projektet startas under vecka och pågår 20 veckor framåt till vecka Projektplanen har tagits fram för att strukturera och planera arbetet med Orator, ett projekt som genomförs under hösten 2005 i kursen TDDC02 "Programvaru projekt i ett helhetsperspektiv" vid Linköpings tekniska högskola.

2 Projektidentitet Projektgrupp Stum Linköpings tekniska högskola (IDA) Projektmedlemmar Namn Ansvarsområde Telefon E-post Projektledare Kjell Enblom Dokumentansvarig Filip Klasson Kvalitetsansvarig Johan Millving Designansvarig Andreas Rasmussen Implementationsansvarig Gustav Veide 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 Dokumentet skapades Rättade språkliga fel i hela dokumentet och gjorde en ny logga se inspektion Rättade språkliga fel i hela dokumentet se inspektion Rättade stavfel se inspektion Tidsändringar i den detaljerade tidsplanen Bilaga A. Justering av fas-start i figur 1 sidan 5. Namnändringar i tabell 2 sidan 9. Layoutändringar i hela dokumentet. Tillägg avwavesurfer under 1.5 Ordförklaringar sidan Ändrade tider i detljerade tidsplan i hela Billaga A Ny akrivitet Insamling av data under A.4.Designfas Ny aktivitet Ö.tidsplan planerades in under A.1 Kvalitetsarbete Uppdaterade grupper under avsnitt 4.3 Uppdaterade medförfattare avsnitt 8.2 Ny risk Oförutsägbara händelser i tabell 2 Kap Samanfattning utökades med syfte och tid Lagt till nya ordförklaringar i Kap. 1 Skrev en utförlig beskrivning av aktiviteter i billaga A Två nya avsnitt &.4.3 Java och Derby Uppdaterade avsnitt med URL till projekthemsida Uppdaterade Referenser med URL till projekthemsida Avsnitt omskrivna Ny aktivitet Revidering/Uppföljning under A.7 Testfas Avsnitt utförligt uppdaterade Nytt avsnitt 3.2 Övergripande tidsplan Omarbetade avsnitt 3.5 Uppdaterade avsnitt 3.7 Skrev om Dokumenthistorik Rättade stavfel se inspektion Skrev om avsnitt 9.5 Rutiner för versionshantering Ändrade figur 5 sid 36 både figur och figurtext Uppdaterade milstolpe 5 och 6 ii

4 iii

5 1 Dokumentöversikt Kapitelbeskrivning Läsanvisning Dokumentberoende Distribution Ordförklaring Projektbeskrivning Bakgrund Syfte Uppgift Mål Projektstruktur Utvecklingsmodell Övergripande tidsplan Faser Arbetsaktivitet Milstolpar Milstolpe 1 - Definitionsfas påbörjad Milstolpe 2 Designfas första halvan påbörjad Milstolpe 3 - Designfas andra halva påbörjad Milstolpe 4 - Implementation- och testfas påbörjad Milstolpe 5 - Implementation- och testfas forts Milstolpe 6 - System till Acceptanstest Milstolpe 7 - Avslutningsfas påbörjad Uppskattning av projektstorlek Egen uppskattning Deadlines för dokument Organisationsplan Organisation av projektgruppen Projektbaserad organisation Fasbaserad organisation Ansvar i projektbaserad organisation Projektledare Kvalitetsansvarig Dokumentansvarig Kundansvarig Designansvarig Implementationsansvarig Testansvarig Systemansvarig Ansvar i fasbaserad organisation Förstudie Definitionsfas Designfas Implementationfas Testfas iv

6 4.3.6 Avslutningsfas Kvalitetsarbete Projektledning Dokument- och inspektionsansvar Redaktör Moderator Inspektör Sekreterare Rapporteringsplan Intern kommunikation Kommunikation i projektorganisation Sjukdoms- och frånvarorapportering Extern kommunikation Interna kommunikationskanaler E-post LysKom Projektmöten Fasgranskning Tidsrapportering Externa kommunikationskanaler Statusrapport Kvalitetsrapport Kundmöte Projektledarmöte Handledarmöte Funktionsmöte Seminarium E-post Resursplan Personal Projektmedlemmar Handledare Kund Kursledning Litteratur Processdokument Tidigare dokument Övrig litteratur Hårdvara Datorer Skrivare Lagringsmedia Övrig hårdvara Mjukvara FrameMaker Tidsredovisning Java v

7 6.4.4 Databas Concurrent Version System WaveSurfer Lokaler Universitetet Övriga resurser Projektskåp Projektpärm Projekthemsida Utbildningsplan Intern utbildning FrameMaker Kvalitetsarbete Programmeringsverktyg Versionshantering WaveSurfer Dokumentplan Dokumenthantering Versionshantering Distribution Granskning Inspektion Dokumentbeskrivningar Projektplan Reviderad Projektplan Kvalitetsplan Kravspecifikation Arkitekturspecifikation Designspecifikation Programmeringshandbok Testplan Testresultat Systemförvaltningsdokumentation Efterstudie Kvalitetsrapport I-III Versionshantering Versionsnummer Versionsuppdatering Dokumenthistorik Ansvar för versionshanteringen Rutiner för versionhantering Skapande av nya dokument Hur ett dokument blir officiellt Förändring av dokument Revisionshöjning av dokument Versionshöjning av dokument vi

8 10 Riskanalys Identifiering av risker Sannolikhet (P) Skada (S) Riskfaktor (F) Sammanställning av risker Åtgärder Tidsrelaterad risk Ledningsrelaterad risk Projektmedlemsrelaterad risk Kursadministrationsrelaterad risk Kundrelaterad risk Produktrelaterad risk Resursrelaterad risk Övriga risker Referenser Interna dokument Externa dokument Bilaga A Detaljerad tidsplan över faser A.1 Total tid per fas A.2 Kvalitetsarbete A.3 Förstudiefas A.4 Defintitionsfas A.5 Designfas A.6 Implementationfas A.7 Testfas A.8 Avslutningsfas A.9 Projektledning vii

9 1 Dokumentöversikt Detta kapitel ger en överblick av projektplanen genom att beskriva dokumentets struktur och dess innehåll. 1.1 Kapitelbeskrivning Projektplanen är indelad i elva kapitel. Kapitelbeskrivningen ger en kortfattad beskrivning av innehållet i varje kapitel. 1. Dokumentöversikt Innehåller en beskrivning av projektplanens struktur och innehåll. 2. Projektbeskrivning Kapitlet beskriver projektgruppens uppgift och målsättning. 3. Projektstruktur Innehåller en beskrivning av den utvecklingsmodell projektgruppen använder under projektarbetet. 4. Organisationsplan Beskriver ansvarsområden i projektgruppen samt organisationen under projektet. 5. Rapporteringsplan Beskriver projektets kommunikations- och rapporteringsvägar. 6. Resursplan Innehåller en beskrivning av de resurser projektgruppen har att tillgå under projektet. 7. Utbildningsplan Innehåller en plan över de utbildningar som sker under projektarbetet. 8. Dokumentplan Beskriver de dokument som skall produceras under projektet. 9. Versionshantering Beskriver hur versionshantering av dokument skall gå till samt vad som skall göras då ett dokument ändras. 10. Riskanalys Beskriver de risker och problem som kan uppstå under projektet. 11. Referenser Består av en lista över använda referenser. Kapitel 1: Dokumentöversikt 1

10 1.2 Läsanvisning För att snabbt få en överblick av projektet rekommenderas det att läsa kapitel 2 och då främst 2.1 samt 2.2. De två avsnitten ger en kort bakgrund till projektet och förklarar den uppgift som skall lösas. För den som är intresserad av hur projektet är organiserat bör 4.1 läsas. Därtill kan det vara av intresse att läsa om den processmodell och de milstolpar som är uppsatta av projektmedlemmarna. Information om detta återfinns i kapitel 3 och då främst i 3.1 samt Dokumentberoende Förändringar i projektplanen kan medföra ändringar i andra dokument. Följande dokument är beroende av detta dokument: Kvalitetsplan [Klasson, 2005] Kravspecifikation [Sandström, 2005]. 1.4 Distribution Dokumentet skall distribueras till: David Broman och Thomas Gustavsson, examinatorer för projektplanen Sten Sunnergren, handledare för projektgruppen projektpärmen i projektskåpet projektgruppens konto. 2 Kapitel 1: Dokumentöversikt

11 1.5 Ordförklaring CVS CYD-poolen Difoner FrameMaker IDA JVM LysKOM PUM RUT WaveSurfer Concurrent Version System, versionshanteringsprogram för källkod. Datorsal på Linköpings universitet där bl a studenter vid programmet för datateknik har tillträde. Delbit av stavelser. Ordbehandlingsprogram från Adobe. Förkortning för vid Linköpings universitet. Virtuell Javamaskin. Ett program skrivet i programspråket Java körs i en JVM. Elektroniskt konferenssystem utvecklat på Lysator vid linköpings universitet. Förkortning för kursen TDDC02 Programutvecklingsmetodik - projekt. Re-Use it, processdokument som har producerats tidigare år i kursen. Verktyg för manipulering och visualisering av ljud. Kapitel 1: Dokumentöversikt 3

12 4 Kapitel 1: Dokumentöversikt

13 2 Projektbeskrivning Kapitlet beskriver bakgrunden till projektet samt definierar projektgruppens uppgift och målsättning. 2.1 Bakgrund Vårt projekt baseras på ett uppdrag från (IDA). Uppdragsgivaren vill ha ett nytt system för talsyntes. Idag använder kunden Orator där Orator är ett verktyg för uppspelning av difoner och visualisering och animering av ett ansikte. I det existerande systemet behandlas ljudet innan det spelas upp för att få jämnare ljud utan hack. Nackdelen med Orator är att för allt inspelat tall försvinner rösternas personlighet. Oavsett vem som har spelat in talet så låter det likadant. 2.2 Syfte Syftet med projektet STUM är att utveckla en applikation för att utvärdera en ny metod för talsyntes. Kunden vill använda slutprodukten i olika forskningsprojekt. 2.3 Uppgift Vår uppgift är att utveckla en talsyntesmotor, baserad på konkatenering av "delbitar", ord och stavelser, av naturligt tal ur en stor uppmärkt taldatabas. Uppgiften går ut på att i taldatabasen hitta så stora "delbitar" som möjligt och sätta samman dessa till ord och meningar. Resultatet ska spelas upp i form av ljud och munrörelser. I en databas lagras uppmärkta ord och stavelser. Användaren matar in en uppmärkt text och systemet ska hitta så stora delbitar som möjligt och spela upp dessa som ljud och munrörelser. Kunden vill att systemet som projektgruppen har fått i uppdrag att utveckla, i framtiden skall vidareutvecklas till ett helt eget system. Det 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. Denna typ av talsyntes och där tillhörande animering förväntas kunna ge en syntes som svårligen kan skiljas från den individ som genererat taldatabasen. 2.4 Mål Projektet har följande mål: att åt kunden utveckla en önskad modul 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. Kapitel 2: Projektbeskrivning 5

14 6 Kapitel 2: Projektbeskrivning

15 3 Projektstruktur Kapitlet beskriver den utvecklingsprocess som projektgruppen använder under projektarbetet och berör även en uppskattning av projektets storlek i antal timmar. 3.1 Utvecklingsmodell Projektet är uppdelat i faser och arbetsaktiviteter, och den utvecklingsmodell som används i projektet är baserad på vattenfallsmodellen men med tillåtna överlappningar av respektive faser som löper genom hela projektet. För att lättare skilja de olika faserna åt och för att få en bättre kontroll över projektet i faserna finns ett antal milstolpar uppsatta. 3.2 Övergripande tidsplan Projektet startar i vecka 34 och beräknas vara klar i vecka 2. Figur 1 visar en övergripande bild över hur arbetet kommer delas upp under de 20 veckorna som projektet fortlöper. 3.3 Faser Projektet kommer delas in i totalt åtta olika faser; förstudiefas, definitionsfas, designfas, implementationsfas, testfas, avslutningsfas, projektledning och kvalitetsarbete. En överblick över faserna återfinns i figur 1 nedan. Faserna projektledning och kvalitetsarbete innehåller en del aktiviteter som skall finnas inom de flesta faser, därför fortlöper de genom hela projektet. Figur 1: Överblick över projektets faser. Kapitel 3: Projektstruktur 7

16 3.4 Arbetsaktivitet Projektet kommer innehålla arbetsaktiviteter som kan starta i en fas och sluta i en annan. Det framgår i appendix A, Tidsplan, vilka aktiviteter som ingår i projektet, under vilken fas de börjar och vilka projektmedlemmar som arbetar i vilka aktiviteter. 3.5 Milstolpar Gruppen har tagit fram ett antal milstolpar för att få en god kontroll över projektet. Milstolparna granskas först och främst av projektledaren och de flesta är framtagna så att gruppen startar och avslutar viktiga aktiviteter i tid. Figur 2 på sidan 11 är en graf över beroenden mellan aktiviteter. Milstoplar har i flesta fall valts vid större mängd av viktiga händelser, dvs då samma vecka som aktiviter måste påbörjas eller veckan innan de skall avslutas Milstolpe 1 - Definitionsfas påbörjad Inspektionshandbok klar Kvalitetsplan inspekterad och nått version 1.0 Övergripande testplan kommenterad och nått version 1.0 Projektplan inlämnad för inpektion Kravspecifikation och Definitionsfas påbörjad Milstolpe 1 kommer att kontrolleras av projektledaren i vecka Milstolpe 2 Designfas första halvan påbörjad Kravspecifikation inlämnad för inspektion Arkitekturspecifikation och Designfas påbörjad Börjat förbereda fasgransknig för Definitionsfas som skall ske vecka 39 Milstolpe 2 kommer att kontrolleras av projektledaren i vecka Milstolpe 3 - Designfas andra halva påbörjad Arkitekturspecifikation inlämnad för inspektion Designspecifikation påbörjad Programmeringshandbok påbörjad Insamling av data påbörjad Milstolpe 3 kommer att kontrolleras av projektledaren i vecka Milstolpe 4 - Implementation- och testfas påbörjad Designspecifikation inlämnad för inspektion Programmeringshandbok inlämnad för slutlig granskning Utbildning för implementation påbörjad Utbildning för test klar Testplanering påbörjad Börjat förbereda fasgranskning för Designfas som skall ske vecka 44 Milstolpe 4 kommer att kontrolleras av projektledaren i vecka 43 8 Kapitel 3: Projektstruktur

17 3.5.5 Milstolpe 5 - Implementation- och testfas forts. Testplanering inlämnad för inspektion Implementation av minst en delmodul klar Modultest påbörjad Milstolpe 5 kommer att kontrolleras av projektledaren i vecka Milstolpe 6 - System till Acceptanstest Implementation av samtliga delmoduler klar Integration klar Ev. extra Modultest klar Integrationstest klar Fasgransknig för Implementationsfas klar Börjat förbereda fasgransknig för testfas som skall ske i vecka 49 Milstolpe 6 kommer att kontrolleras av projektledaren i vecka Milstolpe 7 - Avslutningsfas påbörjad Systemtest klar Acceptanstest genomfört Systemet gått igenom Acceptanstest efter ev. uppföljning/revidering Slutprodukt levererad Milstolpe 7 kommer att kontrolleras av projektledaren i vecka Uppskattning av projektstorlek För beräkning av tidsåtgången för projektet har en kort repetition av befintliga uppskattningsmodeller utförts och noggranna studier av tidigare projektplaner och efterstudier. Slutsatsen, som grundas på modellernas osäkerhet, blev att projektets totala tidsåtgång uppskattats endast genom egna skattningar Egen uppskattning En uppskattning av aktiviteternas tidsåtgång ger att projektet kommer att ta närmare 1600 timmar i anspråk. Uppskattningen ligger inom den tidsram som kursledningen har satt 200 timmar per projektmedlem. 3.7 Deadlines för dokument Kursledningen har tagit fram datum för presentationer samt inlämningsdatum för dokument. Utöver dessa fasta datum har projektgruppen satt upp interna deadlines för när dokumentet skall vara klart för eventuell inspektion. Kapitel 3: Projektstruktur 9

18 Information rörande de dokument som skall inspekteras tas upp i avsnitt 8.2 på sidan 29. Dokument Intern deadline Presentation Extern deadline Kvalitetsplan Projektplan Kravspecifikation Kvalitetsrapport I Arkitekturspecifikation vecka Designspecifikation Reviderad projektplan Kvalitetsrapport II Testplanering Kvalitetsrapport III Testresultat Systemförvaltningsdokument Efterstudiedokument Tabell 1: Projektets deadlines. 10 Kapitel 3: Projektstruktur

19 Figur 2: Visar beroende mellan akitviteter som är viktiga för milstolpar, a) inlämnad för inspektion, b) minst en delmodul klar Kapitel 3: Projektstruktur 11

20 12 Kapitel 3: Projektstruktur

21 4 Organisationsplan Kapitlet beskriver organisationen inom projektgruppen samt vilka ansvarsområden respektive gruppmedlem har. 4.1 Organisation av projektgruppen Projektgruppen delas upp på två olika sätt. De två uppdelningarna är projektbaserad organisation och fasbaserad organisation, där den förstnämnda är mer övergripande. Uppdelningen görs för att arbetet skall effektiviseras under projektets samtliga arbetsflöden. De två organisationerna arbetar parallellt under hela projektet Projektbaserad organisation I den projektbaserade organisationen definieras de befattningar som ingår i det löpande arbetet. Varje befattning ger huvudansvar för ett område inom projektet. Varje projektmedlem tilldelas en befattning samt blir ställföreträdare för en annan. Detta främst för att underlätta projektarbetet vid eventuell frånvaro av projektmedlem. Befattning Huvudansvarig Ställföreträdare Projektledare (PL) A. Rasmussen Kundansvarig (KUND) Patrik Sandström G. Veide Kvalitetsansvarig (KVAL) Filip Klasson J. Millving Designansvarig (DES) Johan Millving T. Janowski Implementationsansvarig (IMP) Andreas Rasmussen K. Enblom Testansvarig (TEST) Thomas Janowski F. Klasson Dokumentansvarig (DOK) Kjell Enblom A. Aghajani Systemansvarig (SYS) Gustav Veide P. Sandström Tabell 2: Fördelning av befattning samt ställföreträdare Fasbaserad organisation Projektet består av faser och aktiviteter, definierade i kapitel 3 på sidan 5. Varje fas har en huvudansvarig (fasansvarig) vars uppgift är att planera och uppdatera fasen tillsammans med projektledaren. I varje fas delas projektgruppen in i mindre grupper vilket kommer att leda till mer effektivt arbete. Grupperna består av en huvudansvarig (gruppansvarig) och ett antal gruppmedlemmar. Gruppansvarig ansvarar för att arbetet i respektive fas utförs. 4.2 Ansvar i projektbaserad organisation Projektgruppen består av 8 personer, där varje person har ett eget ansvarsområde. Dessutom har varje ansvarsområde en vice ansvarig som tar över ansvaret för det aktuella ansvarsområdet om så skulle bli nödvändigt. Detta för underlätta om någon gruppmedlem skulle bli sjuk. Kapitel 4: Organisationsplan 13

22 14 Kapitel 4: Organisationsplan Den huvudansvarige har ansvaret att informera gruppen, framför allt vice ansvarig, om hur arbetet inom hans ansvarsområde fortskrider. Om huvudansvarig skulle bli sjuk eller av andra orsaker bli frånvarande från projektarbetet så har både huvudansvarig och vice ansvarig till uppgift att kontakta varandra så att den vice ansvariga kan rycka in och fortsätta arbetet inom ansvarsområdet. Att vara huvudansvarig inom ett område innebär inte att man ska utföra allt arbete inom området. Det innebär dock att man är ansvariga för att arbetet blir utfört och man har till uppgift att delegera arbetsuppgifter till andra gruppmedlemmar och samordna arbetet Projektledare Projektledaren ansvarar för: Att leda arbetet och fördela arbetet inom gruppen. Att ansvara för att gruppmedlemmarna är väl insatta i tidsplanen. Att en projektplan framställs och presenteras. Att bevaka risker i projektet tillsammans med kvalitetsansvarig. Att dagordning tas fram och kallelse skickas utan innan projektmötet. Att statusrapport framställs och sätts upp varje vecka. Att omplanera arbetet vid behov Kvalitetsansvarig Kvalitetsansvarig ansvarar för: Att framställa en kvalitetsplan och se till att den följs. Att utbilda gruppmedlemmarna i kvalitetsarbete Att projektet håller en genomgående hög kvalitet Att framställa mallar och blanketter för kvalitetsarbetet Att en kvalitetsplan framställs och efterlevs Dokumentansvarig Dokumentansvarig ansvarar för: Att dokumentmallar tas fram och underhålls. Att utbilda andra gruppmedlemmar i framemaker. Att vara en resurs vid framställandet av dokument Kundansvarig Kundansvarig ansvarar för: Att hålla en kontinuerlig kommunikationen mellan kund och projektgrupp Att tillsammans med kunden utarbeta krav för projektet Att kravens uppfylls. Att planera och ordna möten med kunden Designansvarig Designansvarig ansvarar för:

23 Att samordna och leda arbetet med att ta fram en design för systemet utifrån kravspecifikationen Implementationsansvarig Implementationsansvarig ansvarar för: att samordna och leda arbetet att implementera systemet utifrån designspecifikationen att en programmeringshandbok framställs att utbilda projektmedlemmarna i versionshantering Testansvarig Testansvarig ansvarar för: Att kontrollera att kundens krav är testbara. Att samordna testarbetet. Att ta fram metoder för testning av systemet. Att utarbeta en testplan och se till att den följs Systemansvarig Systemansvarig ansvarar för: Att närvara på kundmöten och se till att krav kan implementeras. Att krav, design och implementation är anpassad till systemet. Att medverka vid kravframställning, under designprocessen och under implementationsprocessen. Att innehållet i olika dokument är entydigt. Att vara stöd för respektive ansvarig under krav-, design- och implementationsprocessen. 4.3 Ansvar i fasbaserad organisation Detta avsnitt beskriver de ansvarsområden som respektive grupp har i den fasbaserade organisationen Förstudie Förstudiegrupp Gruppansvarig: PL Vice gruppansvarig: TEST Gruppmedlemmar: Alla Gruppens arbetsuppgifter är: att definiera roller samt få en överblick av projektet att stärka banden mellan projektmedlemmarna att påbörja planeringen av projektet att hålla inledande kundmöten att utbilda sig i kvalitetsarbete, versionshantering och dokumentframställning Kapitel 4: Organisationsplan 15

24 att arbeta fram dokumentmallar Definitionsfas Kravgrupp Gruppansvarig: KUND Vice gruppansvarig: SYS Gruppmedlemmar: SYS Gruppens arbetsuppgifter är: att arbeta fram en kravspecifikation att arbeta fram ett acceptansavtal att hålla regelbunden kontakt med kunden Designfas Analys och designgrupp Gruppansvarig: DES Vice gruppansvarig: IMP Gruppmedlemmar: IMP, PL, SYS, DOK, KUND, KVAL Gruppens arbetsuppgifter är: att arbeta fram en arkitekturspecifikation att arbeta fram en designspecifikation att ta fram en programmeringshandbok Implementationfas Implementationsgrupp Gruppansvarig: IMP Vice gruppansvarig: DOK Gruppmedlemmar: KUND, SYS, TEST, KVAL, DOK Gruppens arbetsuppgifter är: att implementera systemet enligt designspecifikation att utföra testgruppens enhetstest att rätta de fel som testgruppen hittar Testfas Testgrupp Gruppansvarig: TEST Vice gruppansvarig: DES Gruppmedlemmar: DES, SYS, KUND Gruppens arbetsuppgifter är: att arbeta fram ett dokument över testfall att arbeta fram ett dokument över testresultat 16 Kapitel 4: Organisationsplan

25 att arbeta fram enhetstest, modultest, integrationstest, systemtest samt acceptanstest att utföra modultest, integrationstest samt systemtest Avslutningsfas Leveransgrupp Gruppansvarig: SYS Vice gruppansvarig: PL Gruppmedlemmar: PL, DOK Gruppens arbetsuppgifter: att leverera färdig produkt med tillhörande dokumentation att arbeta fram ett systemförvaltningsdokument att utföra testgruppens acceptanstest. Efterstudiegrupp Gruppansvarig: DOK Vice gruppansvarig: TEST Gruppmedlemmar: ALLA Gruppens arbetsuppgifter är: att arbeta fram ett efterstudiedokument Kvalitetsarbete Förändringsgrupp Gruppansvarig: KVAL Vice gruppansvarig: PL Gruppmedlemmar: PL, KUND, DOK Gruppens arbetsuppgifter är: att arbeta fram en kvalitetsplan att arbeta fram kvalitetsrapporter att bevaka risker i projektet att genomföra fasgranskning vid avslutad milstolpe att arbeta fram en inspektionshandbok Projektledning Projektledningsgrupp Gruppansvarig: PL Vice gruppansvarig: KUND Gruppmedlemmar: DOK, KUND, SYS Gruppens arbetsuppgifter är: att planera projektet att arbeta fram en projektplan. Kapitel 4: Organisationsplan 17

26 4.4 Dokument- och inspektionsansvar För varje dokument som framställs definieras ett antal ansvarsområden vilket underlättar arbetet med att framställa dokument. Information rörande vem som har ansvar för respektive dokument tas upp i avsnitt 8.2 på sidan Redaktör För alla dokument utses en redaktör. Redaktören är huvudansvarig för dokumentet. Denne har således ansvar för: att dokumentet är färdigt vid rätt tidpunkt att arbetet samordnas mellan författarna att dokumentet sammanställs till en helhet att inspektion av dokumentet genomförs att dokumentet distribueras till berörda parter att rättning och underhåll genomförs att dokumentet versionshanteras att dokumentet sätts in i projektpärmen då det blir officiellt Moderator För större dokument utses en moderator. Moderatorn leder inspektionsgruppen, se projektets inspektionshandbok [Klasson, 2005]. Denne har således ansvar för: att rätt personer kommer till inspektionen att nödvändigt material finns tillgängligt vid inspektionen att inspektionsprotokollet sätts in i projektpärmen Inspektör I inspektionsgruppen ingår ett antal inspektörer, se projektets inspektionshandbok [Klasson, 2005]. De har således ansvar för: att före inspektionen läsa genom och markera eventuella felaktigheter att under inspektionen utföra det arbete som moderatorn tilldelar dem Sekreterare Sekreteraren ansvarar för att de korrigeringar som noteras bokförs på ett korrekt sätt, se projektets inspektionshandbok [Klasson, 2005]. Denne har således ansvar för: att alla kommentarer om dokumentet under inspektionen bokförs i avsett protokoll. För varje dokument som framställs definieras ett antal ansvarsområden vilket underlättar arbetet med att framställa dokument. Information rörande vem som har ansvar för respektive dokument tas upp i avsnitt 8.2 på sidan Kapitel 4: Organisationsplan

27 5 Rapporteringsplan Kapitlet beskriver projektgruppens interna och externa kommunikationsvägar. Genom att ha fasta rutiner för hur kommunikationen ska fungera kan förändring eller förlust av information förhindras under projektarbetet. 5.1 Intern kommunikation Avsnittet beskriver den kommunikation som sker internt inom projektgruppen Kommunikation i projektorganisation Med avseende på respektive projektmedlems ansvarsområde i den projektbaserade organisationen sker kommunikation enligt figur 3. Pilarnas numrering avser: 1. Kommunkation mellan projektledare och gruppansvarig. Endast gruppansvarig rapporterar och tar emot information från projektledaren. På så sätt undviks upprepningar och alla som berörs får rätt information. 2. Kommunikation mellan olika gruppansvariga. Information som ej behöver förmedlas till hela projektgruppen kan gå direkt från en gruppansvarig till en annan. Detta förhindrar förvirring och förlust av information pga. hög kvantitet av t.ex. e-post. 3. Kommunikation mellan gruppansvarig och övriga projektmedlemmar. Gruppansvarig ser till att informationen från projektledaren når gruppen och vidarebefordrar gruppens rapporter, frågor och önskemål till projektledaren. På så sätt undviks upprepningar och de gruppansvariga avlastar projektledaren Figur 3: Intern kommunikation inom projektorganisationen. Kapitel 5: Rapporteringsplan 19

28 5.1.2 Sjukdoms- och frånvarorapportering Vid längre frånvaro pga plötslig sjukdom, skall projektmedlemen i fråga kontakta sin ställföreträdare, se tabell 2 på sidan 13, sin vice gruppansvarig, se kapitel 4.3 på sidan 15 samt projektledaren. Vid kortare frånvaro skall projektledaren kontaktas via e-post och/eller SMS beroende på hur kort varsel det handlar om. Skulle projektledaren inte vara anträffbar kontaktas i andra hand godtycklig projektmedlem. 5.2 Extern kommunikation Avsnittet beskriver de kommunikationsvägar som finns mellan projektgruppen och utomstående parter. Den externa kommunikationen sker enligt figur 4. Pilarnas numrering avser: 1. Kommunikation mellan projektledare och kursledning. I första hand skall projektledaren förmedla projektgruppens önskemål och frågor till kursledningen. På så sätt undviks upprepningar och förlust av information. 2. Kommunikation mellan kundansvarig och kund. Kundansvarig är huvudlänk mellan kunden och projektgruppen, på så sätt sparas tid vid bl. a. kundmöten. 3. Kommunikation mellan projektgruppen och handledaren. Ingen specifik projektmedlem är satt för kontakt med handledare eftersom handledaren är till för att hjälpa alla i gruppen och projektmedlemmarna kan behöva personligit stöd av handledaren. Figur 4: Extern kommunikation. 20 Kapitel 5: Rapporteringsplan

29 5.3 Interna kommunikationskanaler Avsnittet beskriver de kommunikationskanaler som projektgruppen använder sig av internt E-post E-post är den främsta kommunikationskanalen inom projektgruppen. Projektmedlemmarna skall kontrollera sin e-post minst en gång per dag med undantag för tentamensperioden då projektmedlemmarna förväntas kontrollera sin e-post minst varannan dag. En gemensam e-postadress finns att tillgå då alla projektmedlemmar skall nås samtidigt LysKom LysKOM är en sekundär informationskanal där mindre akuta diskussioner kan hållas. LysKOM kan ibland vara ett snabbare alternativ till e-post när man har en specifik fråga till en eller flera personer i projektgruppen. Man får dock inte utgå från att alla projektmedlemmar kommer läsa det man skriver i KOM Projektmöten Projektmöten hålls kontinuerligt under projektets gång. Projektmöten är främst till för att hålla projektmedlemmarna uppdaterade med de övrigas arbete samt för att informera om vad som kommer att ske under den kommande veckan. Alla projektmedlemar kan kalla till möte i regel med två dagars varsel och projektledaren ansvarar för att den som kallat till möte skickar ut en agenda senast kvällen före mötet. Projektledaren ansvarar för att det under mötet förs protokoll av annan projektmedlem. Efter att protokollet har justerats skall det sättas in i projektpärmen och sparas på projektgruppens konto. Val av sekreterare sker på mötet Fasgranskning Projektledaren och kvalitetsansvarig ansvarar för att det kontinuerligt genomförs fasgranskningar. Fasgranskningen är till för att utvärdera avslutade faser eller del i fas. Vid granskningen skall bl a brister hittas som skall förbättras inför nästkommande fas Tidsrapportering Projektmedlemmarna skall efter avslutat arbete rapportera in den tid som har lagts ned på projektet. Rapporteringen görs via ett webbaserat tidsrapporteringssystem. 5.4 Externa kommunikationskanaler Avsnittet tar upp de kommunikationskanaler som projektgruppen använder sig av vid kommunikation med utomstående parter. Kapitel 5: Rapporteringsplan 21

30 5.4.1 Statusrapport Statusrapporten är en sammanställning över tids inom projektgruppen för varje vecka. Sammanställningen ska placeras på en anslagstavla på IDA före klockan två varje tisdag med undantag för tentamensperioder Kvalitetsrapport Kvalitetsrapporterna skall sammanställas av kvalitetsansvarig och lämnas till kvalitetsstyrningsgruppen bestående av Stina Edelfeldt och Linda Eklund- Hogsved. Kvalitetsrapporterna beskriver det utförda kvalitetsarbetet under den senaste perioden samt kommande aktiviteter Kundmöte Kunden eller projektgruppen kan kalla till möte om diskussioner kring projektet är nödvändiga. Kommunikationen mellan kunden och projektgruppen hålls mestadels via kundansvarig. Kundansvarig skall kontinuerligt informera kunden om hur projektarbetet fortskrider Projektledarmöte Alla projektledare har regelbundna möten av informell karaktär under projektets gång. Avsikten med dessa möten är att projektledarna skall få en möjlighet att utbyta erfarenheter samt fånga upp gemensamma problem Handledarmöte Vid projektmöten närvarar handledaren om möjligt för att informera sig om projektgruppens status men även för att delge information från kursledningen Funktionsmöte Kursledningen håller funktionsmöten för projektgruppens olika ansvarsområden. Den huvudansvariga för respektive område deltar på dessa möten Seminarium Fyra seminarietillfällen är inbokade för presentation och opponering på dokument i kursen. Vid seminariet presenteras dokumentet för andra projektgrupper samt kursledningen E-post Då möte ej blivit sammankallat sker kommunikationen mellan projektgruppen och externa parter främst via e-post. 22 Kapitel 5: Rapporteringsplan

31 6 Resursplan Detta kapitel beskriver vilka resuser projektet har att tillgå under projektets gång. 6.1 Personal Detta avsnitt beskriver de personer som är inblandade i projektet och de resurser dessa personer kan tillhandahålla Projektmedlemmar I projektet finns det 8 projektmedlemmar där varje projektmedlem bidrar med sina egna kunskaper och erfarenheter. Varje projektmedlem har under projektets gång 200 timmar var att lägga på projektet. Under tentamensperioden kommer projektet inte att fortgå som under läsperioden, dock kan arbete förekomma men inget schemalagt arbete har planerats in i tidsplanen Handledare Projektgruppens handledare är Sten Sunnergren som har varit handledare i PUM i många år. Han kommer under projektets gång bidra med sina erfarenheter om programutvecklingsprojekt för att projektet ska kunna genomföras på ett tillfredsställande sätt för både kund och projektgrupp. Sten kommer att finnas tillgänglig via e-post och telefon och kommer även att närvara på projektgruppens veckovis återkommande gruppmöte Kund Kunden i projektet är Bertil Lyberg och Mustapha Skhiri. Dessa kommer att bidra med expertinformation inom området tal och talsyntes. Bl a kommer de hjälpa projektgruppen med att spela in ljudslingor i tallabbet. De kommer även att bistå med de datorer som finns i tallabbet för användning vid framställning av projektuppgiften Kursledning Kursledningen har erfarenhet av programutvecklingsprojekt och tillhandahåller funktionsmöten för de olika ansvarsområdena. De är dessutom ansvariga för de exempeldokument och RUTar som ligger på kurshemsidan. 6.2 Litteratur Avsnittet beskriver den litteratur som används under projektarbetet Processdokument Ett antal processdokument med samlingsnamnet RUT(Re-Use-iT) har producerats tidigare år i kursen. Dokumenten beskriver viktiga processer för ett lyckat projektgenomförande. Samtliga processdokument finns tillgängliga på kurshemsidan. Kapitel 6: Resursplan 23

32 6.2.2 Tidigare dokument 24 Kapitel 6: Resursplan På kurshemsidan finns exempeldokument från gamla PUM-grupper från tidigare år, t.ex. gamla kravspecifikationer. Tidigare grupper har även skrivit efterstudiedokument som beskriver deras erfarenheter av projektarbetet. Dessa kommer användas genomgående genom hela projektet för att undvika onödiga misstag Övrig litteratur Kunden har tillhandahållit litteratur om det tidigare systemet. Utöver det kommer kursboken och böcker om modellering och programmering att användas. 6.3 Hårdvara Avsnittet beskriver den hårdvara som används under projektet Datorer Kursledningen tillhandahåller IDA:s unix-datorer genom bokad tid i deras datorsalar på IDA. Kursledningen tillhandahåller även en bärbar pc-dator som lånas under projektet. I kundens tallabb finns det pc-datorer som kan användas under implementationen. Projektmedlemmarna har utöver detta personliga datorer Skrivare Primärt används de skrivare som IDA tillhandahåller till sina studenter. Sekundärt används gruppmedlemmarnas egna skrivare eller de skrivare som finns i CYD-poolen Lagringsmedia Dokument och källkod kommer primärt att lagras på den CVS-server som sätts upp. Filer skall lagras på pum-gruppens användarkonto på IDA. På detta konto finns 200 MB lagringsutrymme Övrig hårdvara Viss hårdvara så som projektorer och liknande tillhandahålls av kursledningen vid presentationer. 6.4 Mjukvara Avsnittet beskriver den mjukvara som används under projektet FrameMaker Alla dokument skrivs i ordbehandlaren FrameMaker som finns på IDA:s alla unix-datorer Tidsredovisning För tidsredovisning används ett egetskrivet script i php/mysql som ligger på gruppens hemsida.

33 6.4.3 Java Projektet utvecklas i programspråket Java och för det krävs en javakompilator och en virtuell javamaskin, JVM. Java och JVM tillhandahålls av IDA Databas I projektet används databasen Derby som är en öppenkällkodsdatabas licensierad med Apache License. Databasen finns på Concurrent Version System Concurrent Version System (CVS) är ett versionshanteringssystem som används för versionhantering av källkod och dokument WaveSurfer WaveSurfer är ett verktyg för manipulering och visualisering av ljud som är baserat på öppen källkod. Detta kommer användas vid inspelning och modifiering av de ljud som ska ligga i databasen. WaveSurfer finns att ladda ner på Lokaler Avsnittet beskriver de lokaler som används av projektgruppen Universitetet Universitetet tillhandahåller diverse datorsalar, grupprum, konferensrum och andra lokaler som kommer användas under projektarbetet. Kunden tillhandahåller även sitt tallabb för ljudinspelning och för utveckling av programvara. 6.6 Övriga resurser Avsnittet beskriver övriga resurser som används under projektarbetet Projektskåp Gruppen har ett eget projektskåp där dokument och annan materiel som är relevant för hela gruppen kommer att förvaras. Här ligger bland annat projektpärmen Projektpärm Projektpärmen som ligger i projektskåpet innehåller all relevant information angående projektet. I pärmen återfinns bl a mötesprotokoll, inspektionsmaterial och officiella versioner av dokument Projekthemsida På projekthemsidan kommer de officiella versionerna av alla dokument finnas. Projektets hemsida finns på Kapitel 6: Resursplan 25

34 26 Kapitel 6: Resursplan

35 7 Utbildningsplan Kapitlet beskriver den utbildning som sker under projektarbetet. Projektmedlemmarna skall efter utbildningen ha den kompetens som krävs för de uppgifter de ställs inför. 7.1 Intern utbildning Under projektet kommer projektmedlemmarna att stöta på nya arbetsuppgifter och verktyg. Viss utbildning kan behövas för att underlätta arbetet i projektgruppen FrameMaker FrameMaker används vid större delen av dokumentframställningen inom projektgruppen. Dokumentansvarig får en utbildning av kursledningen i Frame- Maker och ansvarar därefter för att utbilda projektgruppen i verktyget. Vid tillfället skall även dokumentansvarig gå igenom vilka rutiner som gäller för dokumentmallarna. Utbildning äger rum under förstudiefasen Kvalitetsarbete Kvalitetsansvarig får en utbildning av kursledningen i kvalitetsarbetet. Denne ansvarar därefter för att utbilda projektgruppen. Utbildning äger rum i samband med inspektionerna Programmeringsverktyg Vid behov ansvarar implementationsansvarig för att utbilda projektmedlemmarna i de programmeringsverktyg som används och i språket C. Utbildning äger rum under implementationsfasen Versionshantering Dokumentansvarig ansvarar för att projektmedlemmarna har tillräckliga kunskaper för att använda projektets processer för versionshantering av dokument. Implementationsansvarig ansvarar för att de som behöver kunskap om versionshantering av kod får den utbildning som krävs. Utbildning äger rum under förstudiefasen WaveSurfer Implementationsansvarig ansvarar för att de som behöver kunskap om programet WaveSurfer, se avsnitt på sidan 25, får den utbildning som krävs. Utbildning äger rum under implementationsfasen. Kapitel 7: Utbildningsplan 27

36 28 Kapitel 7: Utbildningsplan

37 8 Dokumentplan Kapitlet beskriver de dokument som skall produceras inom projektet samt de personer som är inblandade i framtagningen av respektive dokument. 8.1 Dokumenthantering Nedan beskrivs begrepp och rutiner som finns till för att underlätta hanteringen av projektets dokument Versionshantering Information rörande versionshantering tas upp i avsnitt 9.5 på sidan Distribution Information om hur dokumentet skall distribueras återfinns i första kapitlet av varje dokument. För alla dokument gäller dock att de skall distribueras till: projektpärmen i projektskåpet versionshanteringssystemet projektgruppens konto Dokument som skall betygsättas skall lämnas till motsvarande examinator. Eftersom kunden är insatt i liknande system anser vi att samtliga externa dokument rörande systemet skall distribueras till kund Granskning Samtliga dokument skall granskas. För detaljerad information om gransking se inspektionshandbok [Klasson. 2005] Inspektion Instruktioner för hur dokumenten skall inspekteras ges i projektets kvalitetsplan [Klasson, 2005] samt inspektionshandbok [Klasson, 2005]. 8.2 Dokumentbeskrivningar Här följer en lista med samtliga dokument som skall produceras. De innehåller en kort beskrivning av dokumentet, vilka som är inblandade i framtagandet av dokumentet samt när en färdig version av dokumentet lämnas in för examination. Generellt gäller att samtliga dokument skall inspekteras innan färdig version, därför skrives inte detta ut. För mer detaljer angående granskning, roller och så vidare, se inspektionshandbok [Klasson, 2005]. Samtliga dokument kan under projektets gång behöva revideras, det är då redaktören för det specifika dokumentet som har ansvaret att dokumentet uppdateras. Speciellt gäller detta för Projektplanen då den reviderade projektplanen skall lämnas in för examination. För dokumentet Programmeringshandbok finns ingen extern deadline, på grund av att det dokumentet ej skall examineras. Vi har dock satt upp en intern deadline för att dokumentet skall följa de allmänna reglerna för dokument i det här projektet. Kapitel 8: Dokumentplan 29

38 Dokument som tillkommer senare i projektet, exempelvis som ett krav från kund, skall följa de generella regler som finns för dokumenthantering Projektplan Projektplanen beskriver hur projektet skall genomföras och organiseras. Projektplanen riktar sig till samtliga parter i projektet, projektgruppens medlemmar, kund och kursledning. Genom projektplanen skall man bli insatt i vad projektet innebär och hur det skall utföras. Redaktör: PL Medförfattare: SYS, KUND, DES Inspektion: Examination: Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Reviderad Projektplan När ny information angående projektet kommer upp skall dokumentet uppdateras. Projektplanen skall därför ses som ett dynamiskt dokument som uppdateras under projektets gång. Därför får den reviderade projektplanen en egen post i detta kapitel. Redaktör: PL Medförfattare: DOK Inspektion: Examination: Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Kvalitetsplan Kvalitetsplanen beskriver hur projektgruppen skall arbeta för att allt som produceras upprätthåller den kvalitet som anses nödvändigt för projektet. Redaktör: KVAL Medförfattare: DOK Inspektion: Examination: Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Kravspecifikation Kravspecifikationen beskriver de krav som produkten skall uppfylla och tas fram i samrådan med kund. Redaktör: KUND Medförfattare: SYS Inspektion: Examination: Kapitel 8: Dokumentplan

39 Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Arkitekturspecifikation Arkitekturspecifikationen skall ge en övergripande bild av systemet som projektgruppen skall bygga. Dokumentet ligger till grund för designspecifikationen. Redaktör: IMP Medförfattare: KVAL, DES, DOK, SYS Inspektion: Examination: Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Designspecifikation Designspecifikationen beskriver systemet i detalj. I designspecifikationen skall samtliga krav från kravspecifikationen kännas igen. Dokumentet ligger till grund för implementations -och testarbetet. Redaktör: DES Medförfattare: KUND, IMP, SYS Inspektion: Examination: Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Programmeringshandbok Programmeringshandboken beskriver kodstandard och versionshantering för koden. Redaktör: IMP Medförfattare: DOK, KVAL Examination: - Distribution: Projektpärm, Projektgruppens konto Testplan Testplanen beskriver de olika testfall som kommer användas för att testa systemet. Redaktör: TEST Medförfattare: Inspektion: Examination: Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Kapitel 8: Dokumentplan 31

40 8.2.9 Testresultat Testresultat bekriver resultaten från testfallen i testplanen. Redaktör: TEST Medförfattare: IMP Inspektion: Examination: Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Systemförvaltningsdokumentation I systemförvaltningsdokumentationen finns tillräcklig information så att en person enkelt kan sätta sig in i systemet för att exempelvis underhålla eller vidareutveckla det. Redaktör: DOK Medförfattare: PL, KUND Examination: Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare Efterstudie I efterstudiedokumentet skall hela gruppen sammanställa sina erfarenheter av projektet. Dokumentet är till för att gruppen skall reflektera och dra lärdom av sina erfarenheter samt hjälpa andra genom dessa erfarenheter. Redaktör: SYS Medförfattare: PL, KUND, KVAL, DES, IMP, TEST, SYS Inspektion: Examination: Distribution: Examinator, Projektpärm, Projektgruppens konto, Handledare Kvalitetsrapport I-III De tre kvalitetsrapporterna skall lämnas in löpande under projektet och skall beskriva projektgruppens utförda kvalitetsarbete. Redaktör: KVAL Medförfattare: PL, DOK Examination: , , Distribution: Kund, Examinator, Projektpärm, Projektgruppens konto, Handledare 32 Kapitel 8: Dokumentplan

41 9 Versionshantering Alla dokument inom projektet förändras under projektets gång. Versionshantering syftar till att göra dessa förändringar spårbara samt stödja kvalitetsarbetet. Versionshanteringen av dokument stöds inte av någon speciell hårdvara utan hanteringen realiseras istället utifrån rutinerna i detta kapitel. 9.1 Versionsnummer Alla dokument har ett versionsnummer som beskriver var i utvecklingen dokumentet befinner sig. Ett versionsnummer består av två siffror åtskilda av en punkt: Exempel: 0.1 Versionssiffra - siffran till vänster om punkten. Denna definierar vilket stadium dokumentet befinner sig i. Versionssiffran är från början alltid noll (0). Revisionssiffra - siffran till höger om punkten. Denna indikerar mindre steg under dokumentets utveckling. Revisionssiffran är från början alltid noll (0). 9.2 Versionsuppdatering Versionsuppdatering är en benämning på följande två höjningar av versionsnummer. Versionshöjning - Höjer versionssiffran ett steg. Revisionssiffran nollställs. Revisionshöjning - Höjer revisionssiffran ett steg. Versionssiffran bibehålls. 9.3 Dokumenthistorik För att stödja kvalitetsarbetet skall dokumenthistorik finnas i samtliga större dokument inom projektet. För att stödja spårbarheten skall dokumenthistoriken uppdateras vid varje versionsuppdatering. Dokumenthistoriken skall innehålla: Datum för dokumentförändring Aktuell version Vem som ansvarat för ändringen Hur dokumentet förändrats (hänvisning till inspektionsprotokoll eller förändringsförslag) 9.4 Ansvar för versionshanteringen Kvalitetsansvarig har det yttersta ansvaret för att versionshanteringen följs. Kvalitetsansvarigs uppgift är att detektera och rätta felaktigt användande av versionshanteringen. Det är dokumentansvarigs ansvar att utbilda projektmedlemmarna i hur versionshanteringen skall tillämpas. Kapitel 9: Versionshantering 33

42 Varje dokuments redaktör ansvarar för att det aktuella dokumentet versionshanteras på ett korrekt sätt. 9.5 Rutiner för versionhantering Nedan beskrivs de rutiner som skall följas under arbetet med ett dokument. De är till för att underlätta versionshanteringen och det är av absolut vikt att dessa rutiner följs av samtliga projektmedlemmar Skapande av nya dokument För varje nytt dokument skapas en katalog under ~pum1/dokument/ med dokumentets namn. Under denna katalog skapas därefter en underkatalog med namnet workingcopy/. Exempel: ~pum1/dokument/projektplan/workingcopy/ Ett nytt dokument får alltid versionsnummer 0.0. Eftersom detta dokument endast används under förarbetet med dokumentet skall det inte noteras i dokumenthistoriken. Vid uppdatering av versionsnummer skall processen i avsnitt på sidan 35 användas Hur ett dokument blir officiellt Ett dokument betraktas som inofficiellt tills det genomgått en inspektion som resulterar i ett godkännande om det krävs en inspektion för dokumentet. Om inspektion inte krävs kommer dokument betraktas som inofficiellt fram till att det genomgått en kommentering och alla fel rättats. Den granskade versionen betraktas därefter som officiell. Efter kommentering skall redaktören rätta de eventuella fel som uppstått och därefter skicka dokumentet till inspektionen elle endast färdigställa dokumentet. Inspektionenleder till något av följande beslut: 1. Dokumentet godkännes i befintligt skick. 2. Dokumentet godkännes först efter att korrigeringar enligt inspektionsprotokollet utförts. 3. Delar av dokumentet underkännes vilket innebär att de delarna måste genomgå en ny inspektion efter ändring. 4. Hela dokumentet underkänns om det visar sig att större delen av dokumentet innehåller fel. Det innebär att hela dokumentet måste ominspekteras efter ändring. Beslut enligt den första punkten ovan leder till att dokumentet omgående versionshöjs och den nya versionen blir officiell. För den andra punkten blir dokumentet officiellt först efter det att korrigeringarna utförts och sedan godkänts Förändring av dokument Följande gäller vid förändringar av dokument: I en version som inte är officiell får ändringar endast göras av redaktören. Eventuella med skribenter skall spara sitt bidrag till arbetet under ~pum1/ dokument/dokumentnamn/medskribenter/medskribentens namn/ redaktören för sedan in bidraget i dokumentet. Ändringarna måste dock alltid dokumenteras i dokumenthistoriken. 34 Kapitel 9: Versionshantering

43 För att införa ändringar i en officiell version måste den procedur som beskrivs i detta kapitel följas och endast redaktör får införa ändringar. När ändringar utförs skall ändringsmarkeringarna ovillkorligen vara aktiverade i FrameMaker, detta för att underlätta spårbarheten. Ändringsmarkeringar är svarta streck som visas i dokumentets vänstermarginal och markerar på det sättet vilka rader i dokumentet som har ändrats. Användning och hantering av ändringsmarkeringar beskrivs närmare i projektets kvalitetsplan[klasson, 2005]. När en ändring påbörjats skall datumet på dokumentframsidan uppdateras och boken genereras om. Detta för att åtskilja olika versioner av det ändrade dokumentet Revisionshöjning av dokument Revisionshöjning sker inför alla typer av granskningar och efter större förändringar av innehållet i dokumentet. Vid revisionshöjning höjs revisionssiffran ett steg. Resultatet av proceduren nedan blir en ny katalog under dokumentets huvudkatalog. Dessutom förbereds den version av dokumentet som ligger under katalogen workingcopy/ för eventuella framtida förändringar. När ett dokument skall genomgå en revisionshöjning skall följande utföras: 1. Öppna dokumentets framsida i katalogen workingcopy/. Höj revisionssiffran ett steg. Exempel: 0.1 uppdateras till Ändra datumet till dagens datum. 3. Spara framsidan och uppdatera boken så att den nya versionen och datumet uppdateras i alla dokumentets delar. 4. Öppna och uppdatera dokumentets dokumenthistorik i katalogen workingcopy/. 5. Spara dokumenthistoriken och stäng därefter dokumentets bok och alla öppnade deldokument. 6. Skapa en ny katalog med samma namn som dokumentets nya versionsnummer under dokumentets huvudkatalog. Exempel: 0.2/ om dokumentet uppdaterats från 0.1 till Kopiera samtliga filer i workingcopy/ till den nya katalogen som skapades i föregående punkt. 8. Skrivskydda alla filer i den nya katalogen. 9. Nollställ ändringsmarkeringarna i samtliga av dokumentets deldokument i katalogen workingcopy/. 10. Skapa en ny PDF-fil av det dokument som ligger i katalogen workingcopy/ och spara den under ~pum1/www-pub/dokumentnamn/versionsnummer/. Se också figur5 sid 36 som kompliment till texten ovan Versionshöjning av dokument Versionshöjning av dokument sker endast för dokument som skall examineras. När ett dokument som kräver en inspektion genomgått det och godkänts får en höjning av dess versionssiffra genomföras av. För dokument som inte kräver inspektion kan versionshöjning ske först efter kommentering och rättning. Kapitel 9: Versionshantering 35

44 Vid versionshöjning höjs versionssiffran ett steg. Precis som ovan blir resultatet av proceduren nedan en ny katalog under dokumentets huvudkatalog. När ett dokument skall genomgå en versionshöjning skall följande utföras: 1. Öppna dokumentets framsida i katalogen workingcopy/. Höj versionssiffran ett steg och nollställ revisionssiffran. Exempel 0.7 ändras till Följ steg 2-10 i avsnitt Se också figur5 sid 36 som kompliment till texten ovan. 36 Kapitel 9: Versionshantering

45 Figur 5: Detaljierad bild av ett dokuments livscykel. Kapitel 9: Versionshantering 37

46 38 Kapitel 9: Versionshantering

47 10 Riskanalys Kapitlet beskriver den riskanalys som gäller för projektet. Till en början identifieras riskerna och för att sedan motverka dessa beskrivs förebyggande och avhjälpande åtgäder som planerats Identifiering av risker I tabell 3 presenteras de oönskade händelser som kan inträffa under projektarbetet. I tabellen framgår hur sannolikt (P) det är att händelsen inträffar, hur stor skada (S) händelsen åstadkommer samt en sammanvägd riskfaktor (F) för de föregående variablerna Sannolikhet (P) Nedan återfinns definitionen på de nivåer som motsvarar sannolikheten att en oönskad händelse intäffar. 1. Händelsen inträffar sannolikt inte under projektets gång. 2. Händelsen inträffar sannolikt någon gång under projektet. 3. Händelsen inträffar sannolikt flera gånger under projektet Skada (S) Nedan återfinns definitionen på de nivåer gällande skadan som sker då en oönskad händelse inträffar. Skadan mäts i den tid det tar att åtgärda händelsens skadeverkan alternativt den försämring av kvalitet som åsamkats produkten. 1. Händelsen tar mindre än 8 timmar att korrigera alternativt erhålls något försämrad kvalitet på produkten. 2. Händelsen tar mellan 8 och 40 timmar att korrigera alternativt erhålls betydligt försämrad kvalitet på produkten. 3. Händelsen tar mer än 40 timmar att korrigera alternativt erhålls så stor skada att projektet ej längre är genomförbart Riskfaktor (F) Definitionen över riskfaktorn för den oönskade händelsen utgör produkten av sannolikheten (P) och skadan (S). Denna faktor kan ses som ett mått på hur allvarlig en händelse är och tar då alltså även hänsyn till hur ofta en eventuell risk kan inträffa Sammanställning av risker Avsnittet presenterar de risker som projektet är utsatt för. Alla risker har lagts i ett övergripande område beroende på vilken typ av risk de tillhör. Varje riskområde har dessutom delats in på ett sätt så att de risker med högst riskfaktor (F) har placerats överst i respektive område. Anledningen är att risker med hög riskfaktor (F) skall bevakas med särskild noggrannhet. Kapitel 10: Riskanalys 39

48 Riskbeskrivning P S F Tidsrelaterade risker Aktivitet överstiger tidsplan Extern deadline missas Intern deadline missas Oförutsägbara händelser Ledningsrelaterade risker Orealistisk planering av aktivitet Ineffektiva möten Projektmedlemsrelaterade risker Ineffektivt arbete Avhopp Kortare frånvaro av projektmedlem Längre frånvaro av projektmedlem Stor konflikt inom projektgruppen Liten konflikt inom projektgruppen Tilldelade uppgifter som ej utförts Projektmedlems kunskap överskattad Ej tillräckligt insatt i processmodell Kursadministrationsrelaterade risker Kortare frånvaro av handledare Stor konflikt med kursledning eller handledare Liten konflikt med kursledning eller handledare Längre frånvaro av handledare Otydlig information från kursledning Kundrelaterade risker Kund bryter kontrakt Orimliga krav från kund Krav ändras Konflikt med kund uppstår Produktrelaterade risker Felaktig utveckling p g a missförstånd Ej testbara krav Implementation med många fel Design kan ej implementeras Kapitel 10: Riskanalys

49 Sena ändringar i koden Resursrelaterade risker Diskutrymme fullt Ingen dator tillgänglig Viktiga filer försvinner Ej tillgång till skrivare Övriga risker Ofullständig riskanalys Tabell 3: Sammanställning av risker 10.2 Åtgärder Avsnittet behandlar vad som kan göras för att förebygga att problem uppstår samt hur uppkomna problem kan avhjälpas Tidsrelaterad risk Förebyggande Riskbeskrivning P S F Aktivitet överstiger tidsplan Varje vecka sammanställer projektledaren gruppens tidsredovisning. Information från sammanställningen visar vilka uppgifter projektmedlemmarna har genomfört samt uppgiftens tidsåtgång. Sammanställningen ger en bra överblick över projektgruppens tidsförbrukning och indikerar om saker tar längre tid än planerat. Extern deadline missas Användandet av interna deadlines minskar sannolikheten att en extern deadline missas. Intern deadline missas Projektledaren samlar regelbundet in information från gruppmedlemmarna om hur arbetet fortlöper för att övervaka att en intern deadline inte är på väg att missas. Oförutsägbara händelser Genom att göra en så noggrann planering som möjligt och sätta sig in i projektet så bra som möjligt minskas risken för oförutsägbara händelser. Kapitel 10: Riskanalys 41

50 Avhjälpande Aktivitet överstiger tidsplan Omfördelning av ansvarsområden samt arbetsuppgifter kommer eventuellt att ske då en aktivitet överstiger tidsplanen eller då en projektmedlem har förbrukat en stor del av sin kvot innan dennes arbetsuppgifter är slutförda. Extern deadline missas Om projektgruppen märker att en extern deadline är på väg att missas skall redaktören för dokumentet förhandla med kursledningen om ett nytt datum för deadlinen. Intern deadline missas Vid miss av intern deadline skall fler resurser tillföras till uppgiften för att förhindra att även den externa deadlinen missas. Om den externa deadlinen missas kan det bli nödvändigt att omförhandla kraven med kunden. Oförutsägbara händelser Genom att ha reservtid som utnyttjas kan oförtutsägbara händelser åtgärdas Ledningsrelaterad risk Förebyggande Orealistisk planering av aktivitet Projektmedlemmarna skall delta aktivt i att ta fram projektets tidsplan så att en eventuell orealistisk planering av aktiviteter förhindras. Ineffektiva möten Genom att ta fram en tydlig mötespolicy tidigt i projektet förebyggs dessutom ineffektiva möten. Inför varje projektmöte tar projektledaren fram en dagordning som skall följas under mötet, detta för att onödiga diskussioner skall förhindras. Avhjälpande Orealistisk planering av aktivitet Vid en eventuell orealistisk planering av aktivitet kommer omfördelning av ansvarsområden samt arbetsuppgifter att vara en nödvändig åtgärd. Ineffektiva möten Om onödiga diskussioner uppkommer under mötet måste projektledaren avbryta diskussionen och se till att mötesdeltagarna återgår till dagordningen. 42 Kapitel 10: Riskanalys

51 Projektmedlemsrelaterad risk Förebyggande Ineffektivt arbete Ineffektivt arbete skall förebyggas genom att en väl planerad tidsplan skall följas av projektmedlemmarna. Avhopp Arbetet i projektgruppen är organiserat så att de större arbetsuppgifterna har mer än en person som är insatt i problemet. Detta för att undvika en katastrof om en projektmedlem bestämmer sig för att hoppa av projektet. Kortare frånvaro av projektmedlem Inom projektgruppen har en ansvarig för varje uppgift utsetts. Den ansvarige skall regelbundet under projektarbetet informera gruppmedlemmarna om hur arbetet med uppgiften fortlöper. Varje ansvarsområde har även en ställföreträdare som vid frånvaro av den huvudansvarige tillfälligt skall ta över posten, se avsnitt på sidan 13. Vid eventuell planerad frånvaro måste projektmedlemmen i god tid meddela övriga projektmedlemmar så att arbetet kan planeras efter detta. Längre frånvaro av projektmedlem Varje ansvarsområde har även en ställföreträdare som vid frånvaro av den huvudansvarige tillfälligt skall ta över posten, se avsnitt på sidan 13. Stor konflikt inom projektgruppen Konflikter inom projektgruppen förebyggs genom teambildning och utvärderingar. Utvärderingarna ger projektmedlemmarna en möjlighet att tala om vad som har fungerat bra och dåligt samt vad som bör ändras i projektet. Liten konflikt inom projektgruppen Se stor konflikt inom projektgruppen. Tilldelade uppgifter som ej utförts Projektledaren skall regelbundet samla in information från gruppmedlemmarna om hur arbetet fortlöper och kan då i ett tidigt skede se att en tilldelad uppgift utförs av projektmedlem. Projektgruppen skall dessutom använda ett väl fungerande tidsrapporteringssystem för att underlätta uppföljning av aktiviteten i de olika faserna. Ej tillräckligt insatt i processmodell För att projektarbetet skall fungera effektivt måste samtliga medlemmar vara väl förtrogna med den valda processmodellen. Kapitel 10: Riskanalys 43

52 Avhjälpande Ineffektivt arbete Projektledaren ändrar om möjligt i tidsplanen och tillför extra resurser. Avhopp Avhopp avhjälps genom att tilldela avhopparens uppgifter till andra gruppmedlemmar som är insatta i de respektive uppgifterna. Kortare frånvaro av projektmedlem Kortare frånvaro av projektmedlem löses genom omfördelning av arbetet där först och främst ställföreträdaren ersätter tillfälligt. Längre frånvaro av projektmedlem Vid längre frånvaro av gruppmedlem kommer eventuellt en omfördelning av ansvarsområden samt arbetsuppgifter att ske. Stor konflikt inom projektgruppen Vid behov kan hjälp tas av handledare och som sista utväg av kursledning. Liten konflikt inom projektgruppen Om en konflikt uppstår inom gruppen löses den i första hand internt. Tilldelade uppgifter som ej utförts Projektledaren försöker förmå personen att utföra uppgiften och om det ej går tilldelas den till en annan gruppmedlem. Projektmedlems kunskap överskattad Omfördelning av ansvarsområden samt arbetsuppgifter kommer eventuellt att ske då en gruppmedlems kunskap visar sig vara överskattade eller då en tilldelad uppgift ej utförs. Ej tillräckligt insatt i processmodell Gruppmedlemmar som ej är insatta i processmodellen får en kort introduktionsutbildning i processmodellen. 44 Kapitel 10: Riskanalys

53 Kursadministrationsrelaterad risk Förebyggande Kortare frånvaro av handledare Projektgruppen ser till att i största möjligaste mån hålla handledarmöten vid tider där handledaren har störst möjlighet att delta. Stor konflikt med kursledning eller handledare Projektgruppen strävar efter att ha en kontinuerlig kontakt med handledaren och kursledningen för att undvika eventuella konflikter. Liten konflikt med kursledning eller handledare Projektgruppen strävar efter att ha en kontinuerlig kontakt med handledaren och kursledningen för att undvika eventuella konflikter. Längre frånvaro av handledare Om handledaren skulle vara frånvarande en längre tid finns möjlighet till kontakt med andra handledare. Otydlig information från kursledning Eftersom kursledningen består av flera personer så finns det alltid möjlighet att få information från mer än en person. Genom att hålla regelbunden kontakt med handledaren och kursledningen kan missförstånd och eventuella oklarheter undvikas. Avhjälpande Kortare frånvaro av handledare Information får sökas på annat sätt vid frånvaro av handledare eller person ur kursledning. Stor konflikt med kursledning eller handledare Om konflikt uppstår med handledare eller kursledning skall omedelbar diskussion tas för att försöka lösa problemet i ett tidigt skede. Liten konflikt med kursledning eller handledare Se stor konflikt med kursledning eller handledare. Längre frånvaro av handledare Om handledaren skulle vara frånvarande en längre tid tas kontakt med andra handledare. Otydlig information från kursledning Kontakta en annan person ur kursledningen och be denne att förtydliga och förklara informationen. Kapitel 10: Riskanalys 45

54 Kundrelaterad risk Förebyggande Orimliga krav från kund och krav ändras Projektet måste arbeta mot tydliga mål som inte ändras. Därför måste kunden och projektgruppen vara överens om vad som skall göras. För att säkerställa detta skall kunden granska, godkänna och signera den slutgiltiga kravspecifikationen. Eftersom projektet är en vidareutveckling av ett befintligt system måste hänsyn tas till den befintliga arkitekturen. För att säkerställa att de två systemen går att integrera skall kunden granska, godkänna och signera de slutgiltiga artiketur- och designdokumenten. Detta hindrar även kunden från att i efterhand ändra eller lägga till krav. Konflikt med kund uppstår Regelbunden kontakt med kunden minskar risken för konflikter. Avhjälpande Kund bryter kontrakt Vid eventuellt kontraktbrott måste kursledning kontaktas så att omfördelning av projektet kan ske. Orimliga krav från kund Projektgruppen påtalar för kunden att det inte är genomförbart och om kunden fortfarande vill ha kraven genomförda så omförhandlas alla krav. Krav ändras Om kunden i efterhand upptäcker ett fel i de gemensamt framtagna dokumenten måste detta snarast omförhandlas och lösning sökas med hänsyn till den befintliga tidsramen och tillgängliga resurser. Konflikt med kund uppstår Vid konflikt med kunden skall omedelbar diskussion tas för att så snabbt som möjligt lösa de problem som uppstått. Om det uppstår svårigheter i kommunikationen med kunden är diskussion ett bra sätt till lösning. 46 Kapitel 10: Riskanalys

55 Produktrelaterad risk Förebyggande Felaktig utveckling p g a missförstånd Stor vikt skall läggas vid formuleringen av kravspecifikationen. Samtliga krav skall vara tydliga och väl avgränsade. Ej testbara krav Funktionella krav skall så långt som möjligt vara testbara. Icke testbara funktionella krav skall identifieras och tydliga kriterier för att acceptanstesta dessa skall formuleras. Det slutgiltiga acceptanstestet skall innehålla tydliga riktlinjer för icke-funktionella krav. Implementation med många fel För att säkerställa att den färdiga produkten motsvarar kundens förväntningar skall denne ges möjlighet att aktivt granska projektets alla faser under projektets gång. Design kan ej implementeras Genom kontinuerlig återkoppling skall designfel upptäckas snabbt. Sena ändringar i koden Genom kontinuerlig återkoppling skall missförstånd upptäckas snabbt och stora förändringar i projektets slutskede undvikas. Avhjälpande Felaktig utveckling p g a missförstånd Inplanerad tid efter acceptanstest för revidering och uppföljning används för att rätta till felen. Den extra reservtiden kan också utnyttjas. Ej testbara krav Tydliga kriterier formuleras för att kunna mäta om kraven uppfylls. Implementation med många fel Reservtid kan utnyttjas för att rätta till felen. Design kan ej implementeras Visar det sig att kraven är ohållbara måste en omförhandling med kunden ske. Om problem uppstår vid design eller implementation får projektgruppen diskutera om någon del skall omarbetas. Om problemet inte kan lösas inom de befintliga ramarna måste kunden meddelas och en ny lösning förhandlas. Kapitel 10: Riskanalys 47

56 Resursrelaterad risk Förebyggande Diskutrymme fullt Genom att undvika dubletter och se till att alltid rensa bort de gamla versionerna som inte längre behövs minskar risken för att diskutrymmet blir fullt. Ingen dator tillgänglig De datorer som IDA tillhandahåller är ofta uppbokade. Detta kan dock lösas då projektmedlemmarna istället kan välja att arbeta hemifrån genom att använda en SSH-klient eller använda sig av kundens datorer. Hänsyn bör dock tas till att dessa uppkopplingar kan brytas. Projektgruppen har även tillgång till en bärbar dator. Viktiga filer försvinner För att undvika dataförluster skall projektgruppen säkerställa att ordentliga rutiner för säkerhetskopiering finns för all data. Ej tillgång till skrivare Utskriftsproblem kan främst orsaka förseningar vid inlämning av dokument som skall examineras eller lämnas till kund. För att undvika denna typ av försening skrivs alla papperskopior ut i god tid innan inlämningsdatumet av ansvarig redaktör. Kunden skall tillhandahålla mänskliga resurser under flera av projektets faser. Detta skall särskilt beaktas vid tidsplanering så att personal finns tillgänglig när vi behöver den, annars kan projektet förlora mycket tid. Avhjälpande Diskutrymme fullt Om diskutrymmet som projektgruppen förfogar över tar slut skall de aktuella filerna lagras på ett annat system än IDA. Om denna situation uppstår måste projektkontot rensas från onödiga filer. Alternativt ber projektgruppen om mer diskutrymme av kursledningen. Ingen dator tillgänglig Om inga datorer är tillgängliga får gruppmedlemmarna sitta hemma och logga in på IDAs datorsystem via ssh. Viktiga filer försvinner Om viktiga filer försvinner ska projektgruppen om möjligt be systemansvariga på IDA att läsa tillbaka filerna. Ej tillgång till skrivare Om skrivare inte är tillgängliga får gruppmedlemmarna skriva ut hemma eller om det är möjligt vänta och skriva ut senare. 48 Kapitel 10: Riskanalys

57 Övriga risker Förebyggande Ofullständig riskanalys En kontinuerlig riskanalys skall genomföras. Inför varje projektgruppsmöte går projektledaren och kvalitetsansvarig genom de risker som existerar i projektet. Om det bedöms att det finns nya oplanerade risker läggs dessa till. Avhjälpande Ofullständig riskanalys Om en oförutsedd risk inträffar kommer omfördelning av ansvarsområden samt arbetsuppgifter att ske i den mån det är nödvändigt. Kapitel 10: Riskanalys 49

58 50 Kapitel 10: Riskanalys

59 11 Referenser 11.1 Interna dokument [Klasson, 2005] Klasson, Filip (2005), Inspektionshandbok, (IDA) vid Linköpings universitet, Linköping. [Klasson, 2005] Klasson, Filip (2005), Kvalitetsplan, (IDA) vid Linköpings universitet, Linköping. Alla interna dokument finns på projektets hemsida på Externa dokument [Töpel, 2004] Töpel, Johanna (2004), RUT - Development Handbook 3.8 Risk Analysis v 4.0 1, (IDA) vid Linköpings universitet, Linköping. [Nilsson, 2004] Nisson, Fredrik (2004), [Samson, 2003] Samson, Fredrik (2003), RUT - Utvecklingshandbok 1.6 RUT Rational Unified Process v1.0, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping., Kapitel 11: Referenser 51

60 52 Kapitel 11: Referenser

61 Bilaga A Detaljerad tidsplan över faser Nedan återfinns en detaljerad tidsplan över projektets faser. Tidsplanen beskriver hur projektets tillgängliga tid har planerats över faser, aktiviteter och personer. Alla angivelser i tabellerna avser antal nedlagda timmar. A.1 Total tid per fas Tabell 4: Den totala tidsförbrukningen per fas. A.2 Kvalitetsarbete Fasansvarig: KVAL Tabell 5: Tidsförbrukning för kvalitetsarbetet. Aktiviteter: Namn: Inspektionshandbok Beskrivning: Att arbeta fram ett dokument som beskriver hur inspetioner skall genomföras. Beroenden: Funktionsmöte KVAL Pågår: vecka 35 - vecka 36 Namn: Kvalitetsplan Beskrivning: Att arbeta fram ett dokument som beskriver hur kvalitetsarbetet skall genomföras. Kapitel : 53

62 Beroenden: Funktionsmöte KVAL Pågår: vecka 35 - vecka 36 Namn: Ö.testplan Beskrivning: Att arbeta fram en övergripande testplan. Beroenden: Funktionsmöte TEST. Pågår: vecka 35 - vecka 36 Namn: Kvalitetsrapportering Beskrivning: Att framställa tre dokument som sammanfattar genomfört kvalitetsarbete. Beroenden: Kvalitetsplan Pågår: Under hela projektet. Namn: Inspektionsarbete Beskrivning: Genomföra inspektioner av valda dokument. Beroenden: Inspektionshandbok Pågår: Under hela projektet Namn: Fasgranskning Beskrivning: Att genomföra en fasgranskning efter avslutad fas. Beroenden: Funktionsmöte KVAL Pågår: Vecka 38 - vecka 2 A.3 Förstudiefas Fasansvarig: DOK Tabell 6: Tidsförbrukning för förstudiefasen. Aktiviteter: Namn: Funktionsmöten Beskrivning: Utbildning för projektmedlemmar inom respektive ansvarsområden. Beroenden: - Pågår: Enligt kursplaneringen/kallelse till ej planerade möten. 54 Kapitel :

63 Namn: Projektuppgiftstudier Beskrivning: Projektmedlemmarna skall på egen hand sätta sig in i den valda uppgiften. Beroenden: - Pågår: Vecka 34 - vecka 36 Namn: Utb. Framemaker Beskrivning: Projektmedlemmarna får utbildning av DOK i användandet av Framemaker. Beroenden: Funktionsmöte för DOK. Pågår: Vecka 34 - vecka 35 Namn: Utb. versionshantering Beskrivning: Projektmedlemmarna får utbildning av DOK/KVAL/PL angående versionhantering. Beroenden: Projektplan, Kvalitetsplan Pågår: Vecka 36 Namn: Dokumentmallar Beskrivning: DOK framställer dokumentmallar för att framställningen av dokument skall gå smidigt. Beroenden: Funktionsmöte för DOK. Pågår: Vecka 34 - vecka 35 A.4 Defintitionsfas Fasansvarig: KUND Tabell 7: Tidsförbrukning för definitionsfasen. Aktiviteter: Namn: Kravspec Beskrivning: Att arbeta fram en kravspecifikation i sammarbete med kunden. Beroenden: Funktionsmöte för KUND, Projektuppgiftstudier, Kvalitetsplan, Projektplan. Pågår: Vecka 36 - vecka 39 Namn: Seminarium Krav Kapitel : 55

64 Beskrivning: Projektgruppen närvarar vid seminariet för kravspecifikationen. Beroenden: Kravspec, Presentation krav, Opponering krav Pågår: Vecka 38 Namn: Presentation Krav Beskrivning: Projektgruppen förbereder presentation av kravspecifikationen. Beroenden: Kravspec Pågår: Vecka 37 - vecka 38 Namn: Opponering Krav Beskrivning: Projektgruppen förbereder opponering av en annan projektgrupps kravspecifikation. Beroenden: Kravspec Pågår: Vecka 37 - vecka 38 A.5 Designfas Fasansvarig: DES Tabell 8: Tidsförbrukning för designfasen. Aktiviteter: Namn: Arkitekturspec Beskrivning: Att arbeta fram en arkitekturspecifikation. Beroenden: Funktionsmöte för IMP, Kravspec Pågår: Vecka 38 - vecka 41 Namn: Designspec Beskrivning: Att arbeta fram en designspecifikation. Beroenden: Funktionsmöte för DES, Arkitekturspec Pågår: Vecka 40 - vecka 44 Namn: Presentation Ark Beskrivning: Projektgruppen förbereder presentation av akitekturspecifikationen. 56 Kapitel :

65 Beroenden: Arkitekturspec Pågår: Vecka 41 Namn: Opponering Ark Beskrivning: Projektgruppen förbereder opponering av en annan projektgrupps Akitekturspecifikation. Beroenden: Arkitekturspec Pågår: Vecka 41 Namn: Seminarium Ark Beskrivning: Projektgruppen närvarar vid seminariet för arkitekturspecifikation. Beroenden: Arkitekturspec Pågår: Vecka 41 Namn: Programmeringshandbok Beskrivning: Att arbeta fram en programmeringshandbok. Beroenden: - Pågår: Vecka 40 - vecka 44 Namn: Datainsamling Beskrivning: Att ta fram användbar data till databasen Beroenden: - Pågår: Vecka 40 - vecka 44 A.6 Implementationfas Fasansvarig: IMP Tabell 9: Tidsförbrukning för implementationfasen. Aktiviteter: Namn: Utbildning imp Beskrivning: Projektgruppen får utbildning inom implementationsarbetet genomfört av IMP. Beroenden: Arkitekturspec, Designspec Pågår: Vecka 43 - vecka 45 Kapitel : 57

66 Namn: Imp. av moduler Beskrivning: De olika modulerna implementeras i kod samt testas. Beroenden: Utbildning imp Pågår: Vecka 44 - vecka 47 Namn: Integration Beskrivning: De olika modulerna sammanfogas till ett komplett system. Beroenden: Imp. av moduler Pågår: Vecka 47 A.7 Testfas Fasansvarig: TEST Tabell 10: Tidsförbrukning för testfasen. Aktiviteter: Namn: Utbildning test Beskrivning: Projektgruppen får utbildning inom testningsarbetet genomfört av TEST. Beroenden: Ö.testplan Pågår: Vecka 43 Namn: Testplanering Beskrivning: Att arbeta fram testplanen. Beroenden: Utbildning test Pågår: Vecka 43 - vecka 45 Namn: Modultest Beskrivning: De olika modulerna skall testas. Beroenden: Testplanering, Imp. av moduler Pågår: Vecka 45 - vecka 46 (ev. till vecka 47 om fel inträffar) Namn: Integrationstest 58 Kapitel :

67 Beskrivning: Test av moduler som har ett nära eller relativt nära beroende av varandra. Beroenden: Modultest Pågår: Vecka 46 - vecka 47 Namn: Systemtest Beskrivning: Modulerna skall testas tillsammans som ett komplett system. Beroenden: Integrationstest Pågår: Vecka 47 Namn: Acceptanstest Beskrivning: Det kompletta systemet skall genomgå ett acceptanstest som genomförs tillsammans med kunden. Beroenden: Systemtest Pågår: Vecka 47 - mitten av vecka 48 Namn: Uppföljning/Revidering Beskrivning: Om acceptanstestet inte går igenom fullständingt så skall en revision av felaktiga delar genomföras. Beroenden: Acceptanstest Pågår: Vecka 47 - Vecka 48 A.8 Avslutningsfas Fasansvarig: SYS Tabell 11: Tidsförbrukning för avslutningsfasen.. Aktiviteter: Namn: Gruppmöte avslutning Beskrivning: Ett sista gruppmöte inför leverans. Beroenden: Uppföljning/Revidering Pågår: Vecka 49 Namn: Leverans förb. Beskrivning: Presentationen av produkten förbereds. Kapitel : 59

68 Beroenden: Gruppmöte avslutning Pågår: Vecka 49 Namn: Seminarium Leverans Beskrivning: Seminarium där produkten levereras/presenteras till kunden. Beroenden: Presentation förb. lev. Pågår: Vecka 49 Namn: Efterstudiedok Beskrivning: Att arbeta fram ett efterstudiedokument. Beroenden: Seminarium leverans Pågår: Vecka 49 - vecka 2 Namn: Projektledning avslutning Beskrivning: Avslutande projektledningsarbete. Beroenden: - Pågår: Vecka 48 - vecka 2 Namn: Kundkontakt Beskrivning: Avslutande möte med kund. Beroenden: - Pågår: Vecka 49 - början av vecka 51 A.9 Projektledning Fasansvarig: PL Tabell 12: Tidsförbrukning för projektledningen. Aktiviteter: Namn: Projektplan Beskrivning: Att arbeta fram projektplanen. Beroenden: Funktionsmöte för PL Pågår: Vecka 35 - vecka Kapitel :