I Tal-Lab kan ingen höra dig skrika Kvalitetsplan Redaktör: Version: 1.3 Datum: Sammanfattning Kvalitetsplanen har tagits fram för att beskriva det kvalitetsarbete som skall utföras av PUM-grupp 1 i kursen TDDC02, Programutvecklingsprojekt i ett helhetsperspektiv, vid Linköpings tekniska högskola under höstterminen 2005. Dokumentet specificerar de metoder, verktyg och arbetsprocesser som projektet skall följa för att kvalitetssäkra utvecklingen av syntesmekanism för generering av tal och rörelsemönster för animerad agent.
Projektidentitet Projektgrupp Stum Linköpings tekniska högskola (IDA) Projektmedlemmar Namn Ansvarsområde Telefon E-post Ali Aghajani Projektledare 0730460493 aliag988@student.liu.se Kjell Enblom Dokumentansvarig 076-2353375 kjeen007@student.liu.se Kvalitetsansvarig 076-2311778 filkl784@student.liu.se Johan Millving Designansvarig 0709-788619 johmi359@student.liu.se Andreas Rasmussen Implementationsansvarig 070-3718879 avatar@lysator.liu.se Gustav Veide Systemansvarig 070-5514745 gusve322@student.liu.se Patrik Sandström Kundansvarig 0735464898 patsa014@student.liu.se Thomas Janowski Testansvarig 0709-507595 tomja961@student.liu.se E-postlista för hela gruppen pum1@und.ida.liu.se Hemsida www-und.ida.liu.se/~pum1 Kund Kundkontakt Bertil Lyberg, berly@ida.liu.se Mustapha Skhiri, mussk@ida.liu.se Handledare Sten Sunnergren, sten.sunnergren@ekhosat.se Examinator och kursansvarig Robert Kaminski, IDA
Dokumenthistorik Datum Version Utfärdade ändringar Utfärdade av 2005-09-03 0.1 Dokumentet skapades. 2005-09-07 0.1 Dokumentet slutförs. 2005-09-07 0.1 Inga fel hittades under kommentering. 2005-09-08 1.0 Ändringar efter inspektion 2005-09-08. 2005-09-29 1.1 Ändringar efter kommentering från kursexaminator. 1.2 Total omarbetning av dokumentet. Dokumentet följer nu IEEE Std 730-2002. 1.3 Ändringar efter kommentering: Ändrade kod-språket från C till Java. Uppdaterade dokumentstandarden. Rättade några små stavfel/grammatiska fel. ii
iii
1 Kvalitetsplan... 1 1.1 Syfte... 1 1.2 Refererade dokument... 1 1.2.1 Interna dokument... 1 1.2.2 Externa dokument... 1 1.3 Ledning... 1 1.3.1 Organisation... 1 1.3.2 Uppgifter... 2 1.3.3 Ansvarsområden... 3 1.3.4 Resurser lagda på kvalitetsarbetet... 3 1.4 Dokumentation... 3 1.4.1 Syfte... 3 1.4.2 Minimikrav för dokumentation... 3 1.4.2.1 Kravspecifikation... 3 1.4.2.2 Designspecifikation... 4 1.4.2.3 Verifikation och valideringsplan... 4 1.4.2.4 Verifikation- och validationsresultatsrapport... 4 1.4.2.5 Användarhandledning... 4 1.4.2.6 Systemförvaltningsdokumentation... 4 1.4.3 Övrig dokumentation... 4 1.5 Standarder, rutiner och konventioner... 4 1.5.1 Syfte... 4 1.5.2 Innehåll... 4 1.5.2.1 Dokumentationsstandard... 4 1.5.2.2 Designstandard... 5 1.5.2.3 Kodningsstandard... 5 1.5.2.4 Kommenteringsstandard... 5 1.5.2.5 Testningsstandard... 5 1.5.2.6 Standard för logiska strukturer... 5 1.5.2.7 Projektrutiner... 5 1.6 Granskningar... 5 1.6.1 Syfte... 5 1.6.2 Nödvändiga granskningar... 5 1.6.2.1 Granskning av kravspecifikation... 5 1.6.2.2 Arkitekturdesigngranskning... 6 1.6.2.3 Kritisk designgranskning... 6 1.6.2.4 Verifikation och valideringsgranskning... 6 1.6.2.5 Funktionell inspektion... 6 1.6.2.6 Fysisk inspektion... 6 1.6.2.7 Fasintern granskning... 6 1.6.2.8 Administrativa granskningar... 6 1.6.2.9 Konfigurationshanteringsgranskning... 7 1.6.2.10 Efterstudiegranskning... 7 1.6.3 Övriga granskningar och inspektioner... 7 1.6.3.1 Granskningar av övriga dokument... 7 1.6.3.2 Fasgranskningar... 7 1.6.4 Granskningsmetoder... 7 iv
1.6.4.1 Kommentering... 7 1.6.4.2 Inspektion... 8 1.6.5 Översikt av dokumentgranskningar... 8 1.7 Tester... 8 1.8 Problemrapportering och förändringskontroll... 9 1.8.1 Mjukvara... 9 1.8.2 Dokument... 9 1.8.3 Övrigt... 9 1.9 Verktyg, tekniker och metoder... 9 1.10 Mediahantering... 10 1.10.1 Mediahantering av kod... 10 1.10.2 Mediahantering av dokument... 10 1.11 Kontroll av leverantör... 10 1.11.1 Hårdvara... 10 1.11.2 Mjukvara... 10 1.12 Dokumentation av kvalitetsplanen... 11 1.13 Utbildning... 11 1.14 Riskhantering... 11 1.15 Ordlista... 11 1.16 Förändringshistorik... 11 v
1 Kvalitetsplan 1.1 Syfte Kvalitetsplanens syfte är att säkerställa att en hög kvalitet hålls enligt standarden IEEE 730-2002. 1.2 Refererade dokument 1.2.1 Interna dokument [Aghajani, 2005] Aghajani, Ali (2005), Projektplan, (IDA) vid Linköpings universitet, Linköping. [Rasmussen, 2005] Rasmussen, Andreas (2005), Programmeringshandbok, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Klasson, 2005] Klasson, Filip (2005), Inspektionshandbok, (IDA) vid Linköpings universitet, Linköping. [Janowski, 2005] Thomas Janowski (2005), Testplan, (IDA) vid Linköpings universitet, Linköping. [Rasmussen, 2005] Andreas Rasmussen (2005), Arkitekturspecifikation, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Veide, 2005] Gustav Veide (2005), Efterstudie, (IDA) vid Linköpings universitet, Linköping. 1.2.2 Externa dokument [Andersson, 2003] Andersson, Tommy (2003), RUT - Developing Handbook 10.3 Quality Revision v 5.1, (IDA) vid Linköpings universitet, Linköping. [Linnér, 2002] Linnér, Maria (2002), RUT - Development Handbook 10.9 Phase Review v 1.8, (IDA) vid Linköpings universitet, Linköping. 1.3 Ledning Här beskrivs hur kvalitetsarbetet skall organiseras samt ansvarsområden för varje delmoment i projektet. 1.3.1 Organisation Kvalitetsansvarig ansvarar för kvalitetsarbetet samt delegerar kvalitetsrelaterade uppgifter till övriga gruppmedlemmar. Kvalitetsansvarig skall även se till att övriga gruppmedlemmar har möjlighet att utbilda sig i kvalitetsrelaterade uppgifter. Kapitel 1: Kvalitetsplan 1
1.3.2 Uppgifter I tabellen nedan finns de viktigaste kvalitetsaktiviteterna som skall genomföras under projektets olika faser. Fas Aktivitet Förstudiefas Grundläggande kvalitetsutbildning. Skapa mallar och rutiner. Utbildning i olika granskningsmetoder. Utbildning i Framemaker och dokumentframställning. Definitionsfas Kommentering samt inspektering av kvalitetsplan. Kommentering samt inspektion av projektplanen. Kommentering samt inspektion av kravspecifikationen. Kommentering av övergripande testplan. Fasgranskning av definitionsfas. Designfas Kvalitetsrapport I. Kommentering samt inspektion av arkitekturspecifikation. Kommentering av kvalitetsrapport I. Kommentering samt inspektion av designspecigikation. Kommentering samt inspektion av testfallsdokument. Intern revision. Fasgranskning av designfas. Implementationsfas Utbildning i Java. Utbildning i versionshanteringssystem. Kvalitetsrapport II. Kommentering samt inspektion av Reviderad projektplan. Intern revision. Tester (löpande under fasen). Fasgranskning av implementationsfas. Testfas Kommentering samt inspektion av testrapport. Intern revision. Tester (löpande under fasen). Tabell 1: Planering av kvalitetsarbete. 2 Kapitel 1: Kvalitetsplan
Fas Efterstudiefas Aktivitet Kvalitetsrapport III. Fasgranskning av testfas. Utbildning av kund. Kommentering samt inspektion av efterstudiedokument. Fasgranskning av avslutningsfas. Tabell 1: Planering av kvalitetsarbete. 1.3.3 Ansvarsområden Kvalitetsansvarigansvarig har ett övergripande ansvar för projektets kvalitetetsarbete. Kvalitetsansvarig ansvarar för att kvalitetsarbetets olika moment utförs på ett korrekt sätt genom att se till att övriga gruppmedlemmar har tillräcklig utbildning. Kvalitetsansvarig skall delegera ansvaret för de olika kvalitetsrelaterade aktiviteterna till de övriga gruppmedlemmarna. Samtliga gruppmedlemmar är ansvariga för att kvalitetsarbetet utförs på ett korrekt sätt enligt detta dokument samt övriga kvalitetsdokument som produceras. Kvalitetsansvarig ansvarar även för att kvalitetsarbetet som utförts sammanställs och rapporteras till projektgruppen. 1.3.4 Resurser lagda på kvalitetsarbetet De resurser vi ämnar lägga på kvalitetsarbete finns specificerade i den detaljerade tidsplanen, bilaga A i Projektplanen [Aghajani, 2005]. 1.4 Dokumentation 1.4.1 Syfte Detta avsnitt identifierar de dokument som ansvarar för mjukvaruutvecklingen, verifikation och validering. Syftet med dokumentationen är att möjliggöra förståelse för projektet. 1.4.2 Minimikrav för dokumentation Kravspecifikation Designspecifikation Tesplan Testresultat Dokumenten ovan beskrivs i den dokumentplan som finns i projektplanen [Aghajani, 2005]. Dokumenten ovan ansvarar för mjukvarans utveckling samt mjukvarans verifikation och validering. Dessa dokument speglar helt den senaste versionen av mjukvaran. Dokumenten är nödvändiga för att kvalitetssäkra mjukvaran. 1.4.2.1 Kravspecifikation Kravspecifikationen beskrivs i dokumentplanen, kapitel 8 i Projektplanen [Aghajani, 2005]. Kapitel 1: Kvalitetsplan 3
1.4.2.2 Designspecifikation Designspecifikationen består av två dokument; en arkitekturspecifikation och en designspecifikation. Båda dessa beskrivs i dokumentplanen, kapitel 8 i Projektplanen [Aghajani, 2005]. 1.4.2.3 Verifikation och valideringsplan Verifikation och valideringsprocesser används för att avgöra om den utvecklade mjukvaran uppfyller alla krav som ställts. Hur detta går till finns beskrivet i Testplanen [Janowski, 2005]. 1.4.2.4 Verifikation- och validationsresultatsrapport Resultaten av verifikationen och valideringsplanen redovisas i Testresultatdokumentet [Janowski, 2005] som beskrivs i dokumentplanen, kapitel 8 i Projektplanen [Aghajani, 2005]]. 1.4.2.5 Användarhandledning Ej applicerbart på detta projekt. 1.4.2.6 Systemförvaltningsdokumentation För att beskriva systemet för någon som t ex skall underhålla eller utveckla systemet kommer en systemförvaltningsdokumentation att skapas, denna beskrivs i Projektplanen [Aghajani, 2005]. 1.4.3 Övrig dokumentation Den övriga dokumentationen stödjer projektet och dess medlemmar och ger ökad insyn för externa parter. Dokumenten och deras funktion återfinns i dokumentplanen, kapitel 8 i Projektplanen [Aghajani, 2005]. 1.5 Standarder, rutiner och konventioner 1.5.1 Syfte Denna sektion skall identifiera de standarder, rutiner och konventioner som skall användas. Det skall även klargöras hur utvecklingen enligt dessa standarder, rutiner och konventioner skall övervakas och säkerställas. 1.5.2 Innehåll Här beskrivs de standarder, rutiner och konventioner som skall följas vid bl a hantering av dokument, designarbete, programmering och testning. Det är projektmedlemmarnas ansvar att följa dessa riktlinjer. 1.5.2.1 Dokumentationsstandard Dokumentspråk är svenska för alla dokument. Alla dokument framställs i FrameMaker. Rubriker numreras enligt rn1 Rubrik 1 till rn4 Rubrik 4 för respektive rubriknivåer, bilagor numreras enligt Bilaga rubrik1 till Bilaga rubrik4. Brödtext skrivs med b1 Brödtext. Angivna mallar skall användas, aktuella mallar finns under ~pum1/templates. Endast dokumentansvarig får ändra mallarna. Mallar som skall användas är följande: 4 Kapitel 1: Kvalitetsplan
dokument_framsida.fm för försättsblad och dokumenthistorik. exempeltoc.fm för innehållsförteckning. dokument_kapitel.fm för dokumentet. dokument_bilaga.fm för bilagor. Versionshantering och förändringshantering av dokument anges i kapitel 9 i projektplanen [Aghajani, 2005]. 1.5.2.2 Designstandard De designmetoder som skall användas specifieras i Designspecifikationen [Millving, 2005]. 1.5.2.3 Kodningsstandard Den kodningsstandard som skall följas vid programmeringen anges i Programmeringshandboken [Rasmussen, 2005]. 1.5.2.4 Kommenteringsstandard Standarden för kommentering av programkod anges i Programmeringshandboken [Rasmussen, 2005]. 1.5.2.5 Testningsstandard Standarder och rutiner som skall följas vid testning av mjukvaran anges i Testplanen [Janowski, 2005]. 1.5.2.6 Standard för logiska strukturer De logiska strukturer som skall användas i arkitektur- och designarbetet skall vara erkända och etablerade. Valet av de logiska strukturerna skall anges i Arkitekturspecifikationen [Rasmussen, 2005]. 1.5.2.7 Projektrutiner Projektrutiner som skall följas anges i avsnitt 5 i Projektplanen [Aghajani, 2005]. Dessa inkluderar tidsrapportering, mötesrutiner och protokollrutiner. 1.6 Granskningar 1.6.1 Syfte Syftet med det här avsnittet är att definiera projektets tekniska och administrativa granskningar, samt att beskriva hur de skall utföras. 1.6.2 Nödvändiga granskningar Detta avsnittet definierar och beskriver det minsta möjliga antal granskningar som måste genomföras för att kvalitetssäkra mjukvaran. 1.6.2.1 Granskning av kravspecifikation Granskningen görs för att kontrollera och säkerställa att kraven i kravspecifikationen är tillräckliga, godtagbara, realiserbara samt kvantifierbara. Den skall utföras genom kommentering och inspektion av Kravspecifikationen [Sandström, 2005]. Kapitel 1: Kvalitetsplan 5
1.6.2.2 Arkitekturdesigngranskning Den preliminära designgranskningen görs för att kontrollera och säkerställa att den preliminära mjukvaran uppfyller de krav som ställs i Kravspecifikationen [Sandström, 2005], håller hög kvalitet samt är realiserbar inom tidsramen. Den skall utföras genom kommentering och inspektion av Arkitekturspecifikationen [Rasmussen, 2005]. 1.6.2.3 Kritisk designgranskning Den kritiska designgranskningen görs för att kontrollera och säkerställa att den detaljerade mjukvarudesignen uppfyller villkoren i Kravspecifikationen [Sandström, 2005], håller hög kvalitet samt är realiserbar inom tidsramen. Den skall utföras genom kommentering och inspektion av Designspecifikationen [Millving, 2005]. 1.6.2.4 Verifikation och valideringsgranskning Verifikation och valideringsgranskningen görs för att kontrollera och säkerställa verifikation- och valideringsplanens fullständighet, d v s att planen verkligen verifierar och validerar mjukvaran. Verifikation- och valideringsplanen är i projektet uppdelad på två dokument enligt avsnitt 1.4.2.3 och avsnitt 1.4.2.4. Granskningen skall utföras genom kommentering och inspektion av Testplanen [Janowski, 2005]. 1.6.2.5 Funktionell inspektion Den funktionella inspektionen (del i acceptanstestet) utförs av kunden för att kontrollera och säkerställa att den färdiga mjukvaran uppfyller de krav som ställs i kravspecifikationen [Sandström, 2005] enligt RUT 10.3 Kvalitetsrevision v5.1 en [Andersson, 2003]. Den skall förberedas genom kommentering och inspektion av Testfallsdokumentet [Janowski, 2005] och Testrapporten [Janowski, 2005]. 1.6.2.6 Fysisk inspektion Den fysiska inspektionen (del i acceptanstest) skall utföras av kunden för att kontrollera och säkerställa att den färdiga mjukvaran och dess dokumentation är internt konsistent och redo för leverans. 1.6.2.7 Fasintern granskning En fasintern granskning går ut på att kontrollera en del i designen för att verifiera designens konsistens. Detta inkluderar test av Kod gentemot designdokumentation. Gränssnittsspecifikationer. Designimplementering gentemot funktionella krav. Funktionella krav gentemot testbeskrivningar. Den fasinterna granskningen utförs internt genom tester beskrivna i Testplanen [Janowski, 2005]. 1.6.2.8 Administrativa granskningar Administrativa granskningar utförs för att säkerställa att kvalitetsplanen följs genom regelbundna revisioner av kod och granskade dokument. En revision 6 Kapitel 1: Kvalitetsplan
kontrollerar både att Kvalitetsplanen och versionshanteringen av dokument och kod följs. Versionshanteringen kontrolleras med spårbarhetstester, där möjligheten att följa ett dokuments eller en kodmoduls livscykel undersöks. 1.6.2.9 Konfigurationshanteringsgranskning Konfigurationshanteringsgranskningen görs för att utvärdera om den konfigurationshantering som projektet använder sig av är tillräcklig och fullständig. 1.6.2.10 Efterstudiegranskning Efterstudiegranskningen genomförs vid projektets slut. Detta görs för att utvärdera samtliga aktiviteter och tillhandahålla rekommendationer för lämpligt utförande av dessa. Den skall utföras genom kommentering och inspektion av Efterstudiedokumentet [Veide, 2005]. 1.6.3 Övriga granskningar och inspektioner Detta avsnitt definierar och beskriver de övriga granskningarna som skall utföras i projektet. 1.6.3.1 Granskningar av övriga dokument Programmeringshandboken [Rasmussen, 2005] skall kommenteras för att hitta innehållsfel, då dessa kan ha långtgående effekter i projektets produktion. Projektplanen [Aghajani, 2005] och Kvalitetsplanen skall kommenteras och inspekteras eftersom de har stor betydelse för allt arbete i projektet, samt skall visas externt. Kvalitetsrapport I [Klasson, 2005], Kvalitetsrapport II [Klasson, 2005] och Kvalitetsrapport III [Klasson, 2005] skall kommenteras eftersom de skall visas externt. De skall dock inte inspekteras eftersom de inte anses ha långtgående konsekvenser för projektet. 1.6.3.2 Fasgranskningar En fasgranskning görs för att jämföra utfört arbete med planerat arbete i en fas och för att samla erfarenheter inför kommande projektaktiviteter. Det skall utföras en fasgranskning efter varje fas förutom förstudiefasen. Fasgranskningen skall följa RUT 10.9 Phase Review v1.8 [Linnér, 2002] och utföres på ett veckomöte. Ansvariga för granskningen är projektledaren och kvalitetsansvarig. Övriga projektmedlemmar skall förbereda sig till mötet genom att analysera sina egna erfarenheter från fasen samt ha förberett svar på frågor angående fasgranskningen som skickats ut av kvalitetsansvarig. 1.6.4 Granskningsmetoder 1.6.4.1 Kommentering En kommentering görs för att snabbt och effektivt höja kvaliteten på ett inofficiellt dokument. En kommentering är informell, men för att vara effektiv bör den följa processen beskriven nedan: 1. Redaktören anser sitt dokument vara färdigt. Det innebär att redaktören inte kan se varken bristfälligheter eller felaktigheter i dokumentet. Kapitel 1: Kvalitetsplan 7
2. Redaktören delar ut utskrivna kopior av dokumentet till en eller flera projektmedlemmar. Alternativt skriver projektmedlemmarna själva ut kopior. Redaktören och projektmedlemmarna beslutar om en tid då kommenteringsarbetet skall vara klart. Finns checklistor tillgängliga skall redaktören tillhandahålla även dessa. 3. Projektmedlemmarna noterar brister och felaktigheter på kopian, och lämnar den till redaktören inom överrenskommen tid. 4. För noteringar skall SIS-03 62 01-standarden användas. 5. Redaktören avgör om dokumentet skall genomgå förändringar. Om så är fallet ändras versionen enligt kapitel 10 i projektplanen [Aghajani, 2005]. 1.6.4.2 Inspektion En inspektion görs för att kvalitetssäkra ett dokument. Dessutom ger den erfarenheter till produktionen av andra dokument. Inspektionen beskrivs i inspektionshandboken [Klasson, 2005]. 1.6.5 Översikt av dokumentgranskningar Tabell 2 visar samtliga granskningar som skall utföras på dokument. Dokumentnamn Arkitekturspecifikation Designspecifikation Efterstudie Inspektionshandbok Kravspecifikation Kvalitetsplan Kvalitetsrapport I Kvalitetsrapport II Kvalitetsrapport III Programmeringshandbok Projektplan Projektplan, reviderad Testplan Testresultat Systemförvaltningsdokumentaion Granskningsmetod Kommentering. Kommentering. Kommentering. Kommentering. Kommentering. Tabell 2: Dokument och granskningsmetoder. 1.7 Tester Kvaliteten på kod kommer i första hand att säkerställas genom testning. Testerna finns beskrivna i Testplanen [Janowski, 2005]. 8 Kapitel 1: Kvalitetsplan
1.8 Problemrapportering och förändringskontroll 1.8.1 Mjukvara Procedurer som skall följas vid rapportering av, sökning efter och lösning av mjukvaruproblem, samt det organisatoriska ansvaret rörande testning, felsökning och rättandet av fel, beskrivs i Testplanen [Janowski, 2005]. Mjukvarans moduler, samt mjukvaran i sin helhet, identifieras genom ett versionsnummer. Hur kontroll och implementering av ändringar sker, samt hur ändringarna sparas och rapporteras beskrivs i Testplanen [Janowski, 2005]. Mjukvaruändringar kan medföra att dokument behöver ändras. Det skall då göras enligt kapitel 1.8.2. Versionshanteringen av kod beskrivs i Programmeringshandboken [Rasmussen, 2005]. De metoder och hjälpmedel som används för att bibehålla och lagra olika versioner av mjukvaran baseras på ett etablerat versionshanteringssystem. För tillfället är det ännu inte bestämt vilket specifikt versionshanteringssystem det blir. Hur det används anges i Programmeringshandboken [Rasmussen, 2005]. 1.8.2 Dokument Proceduren som skall följas vid behov av förändringar i officiella dokument hittas i förändringsplanen, kapitel 9 i Projektplanen [Aghajani, 2005]. Inofficiella dokument får förändras fritt, men skall följa anvisningarna för versionshantering av dokument, kapitel 9 i Projektplanen [Aghajani, 2005]. Ett dokument identifieras genom ett versionsnummer. Den senaste versionen av ett dokument skall alltid spegla den senaste versionen av mjukvaran. När ett dokument förändras höjs dess versionsnummer. På så sätt garanteras att senaste versionen av projektets dokument vid projektets avslut korrekt beskriver den senaste versionen av mjukvaran. Speciellt gäller för dokumentet testrapport och samtliga testprotokoll, att de skall referera till den version av mjukvaran som testades. Förändringar skall följa de rutiner för dokumentförändring och versionshantering av dokument, som återfinns i kapitel 9 i Projektplanen [Aghajani, 2005]. 1.8.3 Övrigt Problem som ej innefattas i avsnitten ovan rapporteras till projektledaren, som ansvarar för att analysera problemet och vidta eventuella åtgärder. 1.9 Verktyg, tekniker och metoder Kvalitetsplanen beskriver rutiner och metoder som används vid säkerställningen av kvaliteten i den mjukvara och de dokument som produceras. Utöver detta finns ett antal dokument som beskriver hur kvalitetssäkringen går till i specifika processer. Dessa dokument är Inspektionshandbok, mötesprotokoll, Programmeringshandbok. De verktyg projektet skall använda sig av beskrivs i avsnitt 7.3 i Projektplanen [Aghajani, 2005]. De granskningsmetoder projektet skall använda sig av beskrivs i avsnitt 1.6. Speciellt anges dokumentgranskningsmetoderna i avsnitt 1.6.5. Kapitel 1: Kvalitetsplan 9
Metoder och tekniker relaterade till programmering beskrivs i Programmeringshandboken [Rasmussen, 2005]. 1.10 Mediahantering Allt projektmaterial skall sparas på PUM-gruppens projektkonto. Säkerhetskopieringar av kontots innehåll utförs regelbundet av vid Linköpings universitet. 1.10.1 Mediahantering av kod Mediahanteringen av kod baseras på ett etablerat versionshanteringssystem. Information om hur det används återfinns i Programmeringshandboken [Rasmussen, 2005]. 1.10.2 Mediahantering av dokument Senaste arbetskopian av dokument skall sparas i katalogen ~/Dokument/[dokumentnamn]/workingcopy där [dokumentnamn] är exempelvis "Kvalitetsplan". Finns inte underkatalogen "workingcopy" skall denna skapas. Direkt efter versions- eller revisionshöjning skall katalogen ~/Dokument/[dokumentnamn]/workingcopy namnbytas till ~/Dokument/ [dokumentnamn]/[version]. [version] är exempelvis "~/Dokument/kvalitetsplan/v1.2". En ny workingcopy skapas för senaste versionen. Inga filer får raderas från katalogen ~/Dokument och dess underkataloger. Enda undantaget är vid en omstrukturering (se nedan). En katalog med namnet medskribenter skall finnas i ~/Dokument/ [dokumentnamn]/. Under katalogen medskribenter skall en katalog med medskribentens namn skapas där han/hon sparar sin version av dokumentet. Detta görs för att ingen annan än redaktören skall ändra på det riktiga dokumentet. En omstrukturering av katalogen ~/Dokument och underkataloger kan utföras efter beslut av projektledaren tillsammans med övriga projektmedlemmar. Före omstruktureringen måste det säkerställas att samtliga säkerhetskopior är uppdaterade. Efter omstruktureringen måste en kontrollering av katalogens innehåll utföras. 1.11 Kontroll av leverantör 1.11.1 Hårdvara Hårdvara tillhandahållen av, Institutionen för systemteknik och projektmedlemmar förutses hålla tillräcklig kvalitet. Annan hårdvara får ej användas utan att dess kvalitet kan garanteras. 1.11.2 Mjukvara Mjukvaruverktygen tillhandahållna av etablerade företag förutses hålla tillräcklig kvalitet. Versionen av orator som projektet vidareutvecklar förutses hålla tillräcklig kvalitet. 10 Kapitel 1: Kvalitetsplan
Används kod från ej kvalitetssäkrade källor (t ex internet) skall koden kvalitetssäkras och anpassas till anvisningarna i programmeringshandboken [Rasmussen, 2005]. 1.12 Dokumentation av kvalitetsplanen Kvalitetsplanen är utformad enligt IEEE Std 730-2002, IEEE Standard for Software Quality Assurance Plans, IEEE 730 ställer bl a krav på strukturen av dokumentet. I övrigt är den utformad enligt anvisningarna i avsnitt 1.5.2.1. Punktlistan nedan definierar rutiner för hantering och bevaring av detta dokument: Kvalitetsplanen får vid behov förändras inom gränserna för IEEE 730. Detta skall ske enligt rutinerna för förändring och versionshantering av dokument, som beskrivs i kapitel 9 i Projektplanen [Aghajani, 2005]. Kvalitetsplanen skall bevaras enligt rutinerna för mediahantering av dokument, kapitel 1.10.2 tills det att projektet avslutas. Efter projektavslutet avgör kursledningen om kvalitetsplanen skall bevaras som ett exempeldokument för andra studenter. 1.13 Utbildning Utbildningsbehovet gällande kvalitetsfrågor, verktyg och metoder anges i kapitel 7 i Projektplanen [Aghajani, 2005]. 1.14 Riskhantering De metoder och procedurer som projektet kommer att använda sig av för att identifiera, fastställa, bevaka och hantera uppkomna risker anges i kapitel 10 i Projektplanen [Aghajani, 2005]. 1.15 Ordlista RUT: Re-Use it 1.16 Förändringshistorik För information om hur man förändrar detta dokument se kapitel 1.12. För dokumenthistorik se dokumenthistoriken på sidan ii. Kapitel 1: Kvalitetsplan 11
12 Kapitel 1: Kvalitetsplan