Kvalitetsplan. Redaktör: Johan Marnetoft Version: 1.0 Datum: Sammanfattning

Transkript

1 Redaktör: Version: 1.0 Datum: Sammanfattning Denna kvalitetsplan är framtagen för att beskriva hur kvalitetsarbetet ska bedrivas inom projektet Audio Jury i kursen TDDB61 "Programvaruprojekt i ett helhetsperspektiv" vid Institutionen för datavetenskap, Linköpings tekniska högskola läsåret en innehåller de metoder, verktyg och arbetsprocesser som kommer att användas i projektet för att garantera att det inom projektet producerade materialet håller hög kvalitet.

2 ii

3 PROJEKTIDENTITET, Linköpings tekniska högskola Projektmedlemmar Namn Ansvarsområde Telefon E-post Per Andersson Dokumentansvarig (DOK) David Akhvlediani Implementationsansvarig (IMP) Robert Johansson Designansvarig (DES) Lars Larsson Kundansvarig (KUND) Kvalitetsansvarig (KVAL) Gustav Rosén Projektledare (PL) Mikael Svärd Testansvarig (TEST) Christoffer Årstrand Systemansvarig (SYS) E-postlista för hela gruppen Hemsida Kund Sony Ericsson Mobile Communications AB Kundkontakt Wanqing Shi, Sonia Sangari, Handledare Mustapha Skhiri, Kursansvarig Uwe Assman, PROJEKTIDENTITET iii

4 iv

5 Dokumenthistorik Datum Version Namn Förändring Dokumentet skapades Förändringar efter kommentering Rättning efter inspektion. Dokumenthistorik v

6 vi Dokumenthistorik

7 Syfte Ledning Organisation Uppgifter Ansvarsområden Dokumentation Syfte Nödvändiga dokument som ska produceras Standarder, rutiner och konventioner Syfte Dokumentationsstandard Standard för logiska strukturer Kodningsstandard Kommenteringsstandard Testningsstandard Granskningar och inspektioner Syfte Minimikrav Granskningsmetoder Konfigurationshantering Versionshantering Konfigurationshantering av kod Förändringshantering Problemrapportering och förändringskontroll Verktyg, tekniker och metoder Kodkontroll Mediahantering Kontroll av leverantörer Mjukvara Hårdvara Dokumentation av kvalitetsplanen Utbildningsplan Riskhantering Referenser Innehållsförteckning

8 viii Innehållsförteckning

9 1 Detta kapitel beskriver de kvalitetssäkrande aktiviteter som kommer att bedrivas under projektet. en är framtagen utifrån kvalitetsstandarden IEEE 730 som beskrivs i RUT 10.5 [Eklund, 2001]. 1.1 Syfte ens syfte är att definiera de arbetsprocesser, standarder och rutiner som ska användas för att det av projektgruppen producerade materialet ska hålla god kvalitet. 1.2 Ledning Detta avsnitt beskriver kvalitetsarbetets organisation och ledning Organisation Den kvalitetsansvarige har huvudansvaret för och ska leda kvalitetsarbetet. Denne ska motivera och utveckla kvalitetsmedvetandet hos projektmedlemmarna samt se till att de uppgifter rörande kvalitet som de tilldelas utförs och vid behov utbilda dem i kvalitetsarbete Uppgifter Under projektets gång ska fem kvalitetsrapporter produceras vilka ska sammanställa det kvalitetsarbete som utförts samt beskriva kommande aktiviteter. Kvalitetsaktiviteter som ska utföras beskrivs i tabell 1. Dokument Projektplan Kravspecifikation Designspecifikation Programmeringshandbok Testdokumentation I Teknisk dokumentation - Web doc Användarhandledning Testdokumentation II Kvalitetsrapport I-IV Kvalitetsrapport V Efterstudiedokument Granskningstyp Kommentering + inspektion Kommentering + inspektion Kommentering + inspektion Kommentering Kommentering + inspektion Kommentering + genomgång Kommentering + inspektion Kommentering + inspektion Kommentering Kommentering + genomgång Kommentering + inspektion Kommentering + inspektion Tabell 1: Kvalitetsaktiviteter Kapitel 1: 1

10 Dokument Granskningstyp Restlista Dokumenthandbok Kommentering Kommentering Ansvarsområden 2 Kapitel 1: Kvalitetsansvarige har det övergripande ansvaret för kvaliteten i projektet. Denne ska se till att samtliga aktiviteter utförs på ett korrekt sätt, att de sammanställs, redovisas och att en uppföljning av arbetet sker. Samtliga projektmedlemmar är ansvariga för att de kvalitetsaktiviteter som definierats utförs och att de följer de rutiner och standarder som definierats i detta dokument, dokumenthandboken [Andersson, 2003] samt programmeringshandboken [Akhvlediani & Årstrand, 2003]. Kvalitetsansvarige och projektledaren delegerar ansvaret för de olika kvalitetsaktiviteterna till projektmedlemmarna. 1.3 Dokumentation Detta avsnitt beskriver dokumentationen i projektet Syfte Tabell 1: Kvalitetsaktiviteter Syftet med de dokument som produceras i projektet är att se till att utveckling, testning och användning av produkten håller hög kvalitet Nödvändiga dokument som ska produceras Kravspecifikation Kravspecifikationen beskrivs i dokumentplanen som finns i projektplanen [Rosén, 2003]. Designspecifikation Designspecifikationen beskrivs i dokumentplanen som finns i projektplanen [Rosén, 2003]. Verifikations- och valideringsplan Verifikations- och valideringsplanen eller testdokumentation I, beskrivs i projektplanen [Rosén, 2003]. Verifikations- och valideringsrapport Verifikations- och valideringsrapporten även kallad testdokumentation II beskrivs i projektplanen [Rosén, 2003] Användarhandledning Användarhandledningen beskrivs i dokumentplanen som finns i projektplanen [Rosén, 2003]. Övriga dokument som ska produceras Följande dokument ska också produceras. Dokumenthandbok

11 Programmeringshandbok Projektplan Arkitektur specifikation Restlista Efterstudiedokument 1.4 Standarder, rutiner och konventioner Syfte Detta avsnitt ska identifiera de standarder, rutiner och konventioner som ska användas samt klargöra hur utveckling enligt dessa ska övervakas och säkerställas Dokumentationsstandard Standard för dokument återfinns i dokumenthandboken [Andersson, 2003] Standard för logiska strukturer I designspecifikationen [Johansson, 2003] beskrivs vilken standard för logiska strukturer (designmetod) som används Kodningsstandard Kodningsstandard beskrivs i programmeringshandboken [Akhvlediani & Årstrand, 2003] Kommenteringsstandard Kommenteringsstandard för koden finns beskriven i programmeringshandboken [Akhvlediani & Årstrand, 2003] Testningsstandard I testplanen som finns i projektplanen [Rosén, 2003] beskrivs vilken standard och vilka rutiner som gäller för de tester som kommer att utföras i projektet. 1.5 Granskningar och inspektioner Syfte Syftet med granskningar och inspektioner är säkerställa hög kvalitet genom att eliminera så många fel som möjligt i dokument och kod Minimikrav Som ett minimum ska följande granskningar och inspektioner utföras: Granskning av kravspecifikation Kapitel 1: 3

12 Syftet med granskningen är att kontrollera och säkerställa att kraven i kravspecifikationen är tillräckliga och godtagbara. Preliminär designgranskning Den preliminära designgranskningen görs för att kontrollera och säkerställa att den preliminära versionen av mjukvaran följer riktlinjerna i designspecifikationen. Kritisk designgranskning Den kritiska designgranskningen utförs för att kontrollera att den detaljerade mjukvarudesignen i designspecifikationen uppfyller villkoren i kravspecifikationen. Verifikation och valideringsgranskning Verifikation och valideringsgranskingen görs i samband med inspektionen av testdokumentation I. Funktionell inspektion Detta är en inspektion av mjukvarans funktionalitet, som görs innan överlämnandet av programvaran till kunden. Inspektionen görs för att kontrollera att alla krav i kravspecifikationen är uppfyllda. Fysisk inspektion Den fysiska inspektionen görs för att verifiera att mjukvaran och dess dokumentation är internt konsistent och redo att levereras till kunden. Fasintern granskning En fasintern granskning syftar till att kontrollera en del i designen för att verifiera designens konsistens. Detta inkluderar test av: 1. Kod gentemot designdokumentation. 2. Gränsnittsspecifikationer (hårdvara och mjukvara). 3. Designimplementering gentemot funktionella krav. 4. Funktionella krav gentemot testbeskrivningar. Administrativa granskningar Administrativa granskningar genomförs regelbundet under projektets gång för att säkerställa att kvalitetsplanen följs. Dessa granskningar (revisioner) ska hållas av en oberoende grupp i organisationen. Granskningen kan även utföras av en kvalificerad tredje part. De administrativa granskningarna kan resultera i att kvalitetsplanen bör genomgå vissa förändringar. Konfigurationshanteringsgranskning Konfigurationshanteringsgranskningen genomförs för att utvärdera om den konfigurationsrutin som projektet använder sig av är tillräcklig och fullständig. Efterstudiegranskning Efterstudiegranskningen genomförs i det avslutande skedet av projektet. Syftet med granskningen är att utvärdera samtliga aktiviteter i projektet och för att tillhandahålla rekommendationer för lämpligt handlande vid utförandet utav dessa aktiviteter. 4 Kapitel 1:

13 1.5.3 Granskningsmetoder I detta avsnitt beskrivs de granskningsmetoder som kommer att användas för att säkerställa kvaliteten hos de dokument som produceras inom projektgruppen. Inspektion (Inspection) Inspektionen är den mest formella av granskningsmetoderna. Den ska följa Fagans granskningsmetod, vilken beskrivs i RUT 10.2 [Andersson, 2002]. Diskussion kring lösningar är inte tillåten under inspektionen. Felstatistik förs och sammanställs av kvalitetsansvarige. Dokument som ska inspekteras ska ha genomgått minst två stycken kommenteringar. Genomgång (Review) Genomgången går tillväga på samma sätt som inspektionen med undantag av att diskussion kring lösningar är tillåten samt att ingen felstatistik förs. Innan en genomgång ska dokumentet kommenterats av minst två personer. Kommentering (Commenting) När redaktören anser att dokumentet är klart eller då ändringar är gjorda i dokumentet kontaktar han kvalitetsansvarige som utser minst två personer som ska kommentera dokumentet. Det som ska kommenteras i dokumentet är stavfel, layout, innehåll samt eventuella andra punkter som kvalitetsansvarige beslutat om tilsammans med redaktören. Fel och synpunkter markeras i dokumentet där de förekommer och en kommentar skrivs i marginalen eller på ett separat papper där man hänvisar till sidan och avsnittet där felet eller synpunkten förekommer. Fel och synpunkter ska numreras tillsammans med kommentaren i marginalen för att underlätta vid rättning och ändring. Efter kommenteringen ska de som granskat dokumentet och redaktören diskutera kommentarerna och enas om lösningar. Redaktören åtgärdar därefter felen och gör de ändringar som han tillsammans med de som kommenterat dokumentet enats om. Efter det meddelar redaktören kvalitetsansvarige att dokumentet är rättat. Om dokumentet genomgått kommentering och rättats behöver endast de delar där ändringar gjorts granskas såvida kvalitetsansvarige inte beslutar om annat. Varje dokument kan kommenteras godtyckligt antal gånger men ska ha genomgått minst två kommenteringar innan inspektion. Fasgranskning Fasgranskningar genomförs i övergången mellan två faser i projektet. En fas avslutas då dess planerade aktiviteter är slutförda, se projektplanen [Rosén, 2003]. Fasgranskningen är till för att kontrollera arbetet som gjorts i en fas. Fasgranskning beskrivs i RUT 10.9 [Norén, 2001]. Test Testning av programkoden beskrivs i testplanen som återfinns i projektplanen [Rosén, 2003]. Granskning av användarvänlighet Kapitel 1: 5

14 Granskning av användarvänlighet kommer att ske enligt Nielsens tumregler [Faulkner, 2002]. 1.6 Konfigurationshantering Versionshantering 6 Kapitel 1: Versionshantering finns beskriven i projektplanen [Rosén, 2003] Konfigurationshantering av kod Konfigurationshantering av kod finns beskriven i programmeringshandboken [Akhvlediani & Årstrand, 2003] Förändringshantering I detta avsnitt beskrivs tillvägagångssättet för förändringar av ett officiellt inspekterat dokument. Orsaker till förändringar Formfel, d v s stavfel, grammatiska fel, oklart uttryckssätt eller typografiska felaktigheter. Inkonsistens, det vill säga att dokumentet beskriver verkligheten felaktigt, eller att de förutsättningar på vilka dokumentet är grundat har ändrats. Anpassning, t ex om ändringar i krav eller design sker måste de dokument som beror på dessa anpassas så att de stämmer överens. Liten förändring En förändring är liten om den endast rör det enskilda dokumentet och ej påverkar övriga dokument. Stor förändring En förändring är stor om den påverkar andra dokument, vilka då måste genomgå förändring. Även en förändring som bara påverkar ett enskilt dokument men påverkar projektet i hög grad anses som stor. Förändringsprocess När en felaktighet i ett officiellt dokument påträffas och en förändring anses nödvändig ska följande steg följas: 1. Den projektmedlem som vill införa förändringen dokumenterar ett förslag på förändring samt motivering till förändringen på blanketten förändringsförslag som finns i projektgruppens hemkatalog och ger detta till projektledaren. 2. Projektledaren tar tillsammans med förslagställaren och kvalitetsansvarige ställning till om förändringen ska genomföras. 3. Om förändringen ska genomföras kontaktar projektledaren redaktören för varje dokument som berörs. Redaktören är ansvarig för att förändringen utförs. Förändringar utförs enligt rutinen för versionshantering som beskrivs i projektplanen [Rosén, 2003]. 4. Därefter meddelas kvalitetsansvarige om att förändringarna är utförda och denne beslutar om ominspektion av berörda dokument ska utföras eller ej.

15 5. Slutligen signerar kvalitetsansvarige förändringsförslaget och arkiverar det i projektpärmen. 1.7 Problemrapportering och förändringskontroll Problem rapporteras till gruppledaren som sedan ansvarar för att problemet analyseras, rätt personer informeras och lämplig åtgärd vidtas, se rapportplanen i projektplanen [Rosén, 2003]. 1.8 Verktyg, tekniker och metoder Utöver de rutiner som beskrivs i kvalitetsplanen hänvisas till projektplanen [Rosén, 2003], dokumenthandboken [Andersson, 2003] samt programmeringshandboken [Akhvlediani & Årstrand, 2003]. 1.9 Kodkontroll Se programmeringshandboken [Akhvlediani & Årstrand, 2003] för en beskrivning av hur koden ska kontrolleras Mediahantering Den senaste versionen av varje officiellt dokument ska sättas in i projektpärmen som finns i projektgruppens skåp, se projektplanen [Rosén, 2003]. Varje författare har ansvar för att sätta in sina egna dokument i pärmen. Äldre versioner och arbetskopior sparas i respektive katalog på PUM-kontot. Dokumentansvarige ansvarar för att säkerhetskopiering av officiella dokument sker. För information om mediahantering av kod hänvisas till programmeringshandboken [Akhvlediani & Årstrand, 2003] Kontroll av leverantörer Mjukvara All mjukvara som kommer att användas under projektet kommer antingen från väletablerade företag som Sun Microsystems, Adobe, Microsoft eller från. Det förutsätts att dessa håller hög kvalitet Hårdvara Hårdvaran som kommer att användas tillhandahålls antingen av kund, IDA, LiU eller är projektmedlemmarnas privata. Det kan förutsättas att den håller hög kvalitet Dokumentation av kvalitetsplanen en kommer att följas upp under projektet och ändras vid behov. Ändringarna ska då följa de riktlinjer för förändringshantering som beskrivs i avsnitt 1.7. Senaste versionen av kvalitetsplanen ska finnas tillgänglig i projektpärmen. Kapitel 1: 7

16 1.13 Utbildningsplan Information om utbildning återfinns i utbildningsplanen i projektplanen [Rosén, 2003] Riskhantering Riskhantering finns beskriven i projektplanen [Rosén, 2003]. 8 Kapitel 1:

17 2 Referenser [Akhvlediani & Årstrand, 2003] Akhvlediani, David och Årstrand, Christoffer, Programming handbook, vid Linköpings universitet, Linköping. [Andersson, 2003] Andersson, Per, Dokumenthandbok, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Andersson, 2002] Andersson, Richard, RUT utvecklingshandbok 10.2 Granskning enligt Fagan v3.0, vid Linköpings universitet. [Eklund, 2001] Eklund, Linda, RUT utvecklingshandbok 10.5 Kvalitetsarbete enligt IEEE 730 v4.1, vid Linköpings universitet, Linköping. [Faulkner, 2002] Faulkner, Xristine, Usability Enginering, The School of Computing, South Bank University, London. [Johansson, 2003] Johansson, Robert, Designspecifikation, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Norén, 2001] Norén, Per, RUT utvecklingshandbok 10.9 Fasgranskning v1.8, vid Linköpings universitet [Rosén, 2003] Rosén, Gustav, Projektplan, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. Kapitel 2: Referenser 9

18 10 Kapitel 2: Referenser