FACULTEIT WETENSCHAPPEN
Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie 0.1 0.2 1.0 2.0
Datum 09/11/2010 12/11/2010 06/03/2010 18/05/2010
Auteur Jeroen Van den haute Beerend Ceulemans Jeroen Van den haute Jeroen Van den haute
Commentaar Eerste versie Verbeterde versie Opmerkingen feedback verbeterd Reviews toegevoegd
Table 1: Document geschiedenis
14-11-2010
Contents 1 Scope
3
2 Referenties
3
3 Definities en Acroniemen
4
4 Management 4.1 Organisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Taken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Verantwoordelijkheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 4 4 5
5 Documentatie 5.1 Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Minimale Documentatie Eisen . . . . . . . . . . . . . . . . . . . . . . . . .
5 5 5
6 Standaarden, conventies, werkwijze en metriek 6.1 Doel . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Inhoud . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Standaarden en conventies . . . . . . . . 6.2.2 Documentatie . . . . . . . . . . . . . . . 6.2.3 Werkwijze . . . . . . . . . . . . . . . . . 6.2.4 Metrieken . . . . . . . . . . . . . . . . . 6.2.5 Kwaliteitsdoelen . . . . . . . . . . . . . 6.2.6 Meeting Afspraken . . . . . . . . . . . .
. . . . . . . .
5 5 6 6 6 6 6 7 7
. . . . . . . . . .
7 7 7 7 8 8 8 8 8 9 9
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
7 Reviews en Audits 7.1 Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Minimale Requirements . . . . . . . . . . . . . . . . . . . 7.2.1 Software Specificatie Review . . . . . . . . . . . . 7.2.2 Architectuur Design Review . . . . . . . . . . . . 7.2.3 Detailed Design Document . . . . . . . . . . . . . 7.2.4 Functionele Audit . . . . . . . . . . . . . . . . . . 7.2.5 Fysieke Audit . . . . . . . . . . . . . . . . . . . . 7.2.6 In-process Audits . . . . . . . . . . . . . . . . . . 7.2.7 Software Configuration Management Plan Review 7.2.8 Post Mortem Review . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . . . . . .
8 Testen
9
9 Problemen rapporteren en oplossen 9.1 Documentatiefouten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Broncode fouten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 9 9
1
10 Tools, technieken en methodologie¨ en
9
11 Media controle
10
12 Leverancier controle
10
13 Gegevens verzamelen,onderhoud en opslag
10
14 Training
10
15 Risk management
10
16 Bijlagen 16.1 Software Specificatie Review 16.2 Software Specificatie Review 16.3 Functionele Audit . . . . . . 16.4 Fysieke Audit . . . . . . . . 16.5 Post Mortem Review . . . .
11 11 11 11 11 12
. . . . .
. . . . .
. . . . .
. . . . .
2
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
1
Scope
Dit document bevat het Software Quality Assurance Plan van groep 3 voor het vak Software Engineering. In dit document gaan we verschillende methoden en technieken gaan defini¨eren die de kwaliteit van ons project kunnen controleren, en er zo voor zorgen dat de kwaliteit van het af te leveren product zo hoog mogelijk is. Het belangrijkste doel van dit plan is ervoor te zorgen dat aan het einde van het project, het af te leveren product voldoet aan alle afgesproken standaarden en technieken, en dat ieder teamlid zich hieraan heeft gehouden. Daarom is het belangrijk dat niet alleen bij het einde van het project de kwaliteit wordt gecontroleerd, maar dit tijdens het hele project gebeurt door ieder teamlid.
2
Referenties
References [1] Beschrijving van het project, http://pointcarre.vub.ac.be/courses/VUB6537/index.php [2] Software Engineering An Object-Oriented Perspective, Eric J. Braude, 2001, ISBN 0471322083, John Wiley & Sons [3] Software Engineering Group 3 2010-2011, http://wilma.vub.ac.be/~se3_1011
3
3
Definities en Acroniemen
SCMP
SDD SPMP
SQAP SRS STD
QAM KLOC
4
Software Configuration Management Plan: Document dat gaat beschrijven hoe documenten en code wordt opgeslagen, en hoe samen te voegen. Software Design Document: Document dat het design en de architectuur beschrijft. Software Project Management Plan: Document dat beschrijft wie welke rol heeft, wat de bedoeling is van het project, wat alle taken inhouden,... Software Quality Assurance Plan: Document dat het quality assurance process beschrijft. Software Requirement Specification: Document dat de vereisten bevat waaraan het systeem moet voldoen. Software Test Document: Document dat de instructies bevat in verband met het testen van alle componenten van het systeem. Quality Assurance Manager: Persoon die verantwoordelijk is voor de kwaliteit van het project Kilo lines of code
Management
4.1
Organisatie
Het team waarmee we dit project gaan uitwerken bestaat uit 7 leden. Elk teamlid is verantwoordelijk voor de kwaliteit van zijn eigen werk. De Quality Assurance Manager heeft als taak ervoor te zorgen dat iedereen zich houdt aan de gemaakte afspraken in verband met de kwaliteit. Deze gaat ook controleren of alle documenten nog eens zijn nagelezen en of alles in orde is. Indien dit niet het geval is meldt hij dit aan diegene die het gemaakt heeft.
4.2
Taken
De taken van de Quality Assurance Manager bevatten: Schrijven en onderhouden van het SQAP Schrijven en onderhouden van het STD Verantwoordelijk voor alle documenten Controleren van tutorials Controleren van alle verslagen
4
Beslissen over Coding Conventions in samenspraak met de implementationmanager Eindverantwoordelijke testen van alle code
4.3
Verantwoordelijkheid
De Quality Assurance Manager voert bovenstaande taken allemaal uit, en zorgt ervoor dat alle leden zich houden aan de gemaakte afspraken en richtlijnen in dit document. De Project Manager controleert op zijn beurt de Quality Assurance Manager dat deze zich ook houdt aan de gemaakte afspraken en richtlijnen. Wanneer een teamlid een fout constateert die nog niet is opgemerkt door de QAM meldt deze dit.
5
Documentatie
5.1
Doel
Volgende paragraaf beschrijft hoe we het project gaan documenteren.
5.2
Minimale Documentatie Eisen
Volgende documenten moeten verplicht worden afgeleverd bij dit project: SPMP: Software Project Management Plan SCMP: Software Configuration Management Plan SDD: Software Design Document SQAP: Software Quality Assurance Plan STD: Software Test Document SRS: Software Requirements Specification Java broncode documentatie gegenereerd door Javadoc
6 6.1
Standaarden, conventies, werkwijze en metriek Doel
Volgend deel gaat de standaarden, conventies, werkwijzen en metrieken beschrijven die we gaan gebruiken in het project.
5
6.2 6.2.1
Inhoud Standaarden en conventies
Gedurende het hele project gaan we voor het schrijven van documenten ons baseren op de IEEE-standaarden. Wanneer we code schrijven houden we rekening met de Java code conventies: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html Kleine wijzigingen zijn hierin steeds mogelijk, maar enkel en alleen in overleg met de QAM. Elk teamlid heeft de eigen verantwoordelijkheid zich te houden aan deze conventies. 6.2.2
Documentatie
Alle documenten zullen worden geschreven in latex. De nieuwste versie van een document wordt steeds online gezet op de site. Alle broncode bevindt zich in de svn-repository op de wilma-server. Het is van groot belang dat steeds de recentste versie van de broncode online staat. De documentatie van de broncode bevindt zich zowel in de broncode, als in een appart document. Alle niet-code documenten zullen worden geschreven volgens een template, bepaald door de QAM, om de consistentie tussen de documenten te bewaren. 6.2.3
Werkwijze
Elk teamlid houdt zich zeker aan volgende afspraken: Elk teamlid houdt zich aan de afgesproken deadline Elk teamlid controleert de kwaliteit van zijn werk tijdens de ontwikkeling, niet erna Alle documenten en code gemaakt door een teamlid, moeten beschikbaar zijn voor alle teamleden Wanneer een stuk code is afgewerkt door de eigenaar, gaat deze dit eerst zelf nog eens controleren. Hierna laat deze dit aan een collega weten, zodat deze de code binnen de week ook nog eens kan controleren. Voor de duidelijkheid en de eenvoudigheid zullen 2 personen steeds elkaars code bekijken. Welke teams er gevormd worden zal onderling worden afgesproken.
6.2.4
Metrieken
Bij elke iteratie worden volgende metrieken onderhouden: Voor elk teamlid wordt bijgehouden hoelang hij gewerkt heeft, in uren(zowel voor de code als documentatie) Voor elk teamlid wordt bijgehouden hoeveel code hij geschreven heeft, in KLOC, alsook voor het gehele team
6
6.2.5
Kwaliteitsdoelen
We bepalen hoeveel fouten er maximaal mogen zijn, zodat ons project toch van goede kwaliteit is. Onder een fout verstaan we voor de requirements het ontbreken of niet volledig representeren van een requirement. Voor het design en de code verstaan we onder een fout het leiden tot een error, waardoor sommige functionaliteit niet meer werkt. Requirements: Niet meer dan 1 fout per 20 requirements. Design: Niet meer dan 1 fout per 6 diagrammen. Code: Niet meer dan 5 fouten per KLOC, gevonden door de klant.
6.2.6
Meeting Afspraken
Als er een meeting moet plaatsvinden zal dit beslist worden door de Project Manager. Deze laat dit weten aan de Planning Manager, die een gepast tijdstip uitzoekt waar iedereen op aanwezig kan zijn. De datum van een meeting wordt minstens 3 dagen op voorhand vastgelegd. Wanneer een teamlid niet aanwezig kan zijn laat hij dit aan de Project Manager weten, mits een geldige reden. Wanneer het dringend nodig is om een meeting te organiseren, laat de Project Manager dit minstens een dag op voorhand weten. Hierbij is het eventueel wel toegestaan dat niet alle teamleden aanwezig zijn. De agenda van de meeting wordt bepaald door de Project Manager. Elk teamlid mag agendapunten toevoegen door deze naar de Project Manager door te sturen. Tijdens elke meeting wordt er een verslag opgemaakt en op de site gezet door de secretaris, maximum 3 dagen na de meeting.
7 7.1
Reviews en Audits Doel
Het belangrijkste doel van reviews en audits bestaat uit ervoor zorgen dat de kwaliteit van ons afgeleverde product maximaal is. Door het project nog eens te overlopen kunnen we er nog fouten uithalen, en zo de kwaliteit optimaliseren. We herbekijken ook al onze documenten nog eens, zodat deze zeker geen fouten bevatten en allemaal consistent zijn.
7.2 7.2.1
Minimale Requirements Software Specificatie Review
Hierbij gaan kijken of er wel voldaan is aan alle requirements opgesomd in het SRS. Deze review is de verantwoordelijkheid van de Requirement Manager, maar zal worden uitgevoerd door het hele team. Daarom moet ieder teamlid het SRS grondig lezen, en daarna alle requirements van het project overlopen, en kijken welke nog ontbreken of niet volledig zijn.
7
7.2.2
Architectuur Design Review
Bij deze review gaan we de verschillende mogelijkheden van architectuur overlopen bij het design van het project. Deze Review zal worden geleid door de Development Manager, en kan pas plaats vinden wanneer de eerste versie van het Software Design Document klaar is. De opmerkingen zullen worden overgemaakt aan de Development Manager, en deze kan dan, rekening houdend met de opmerkingen, het definitieve Software Design Document maken. 7.2.3
Detailed Design Document
We gaan kijken of de architectuur die we gekozen hebben voor het design voldoet aan alle vereisten. Het is belangrijk dat we zo vlug mogelijk fouten opsporen, omdat we deze dan makkelijker kunnen oplossen. Deze review is ook de verantwoordelijkheid van de Development Manager. 7.2.4
Functionele Audit
Deze audit wordt uitgevoerd voor het project wordt afgeleverd, en is de verantwoordelijkheid van de Project Manager. We gaan alle documenten die worden ingediend controleren of ze wel voldoen aan de eisen opgesteld in het SRS. 7.2.5
Fysieke Audit
Deze audit vindt ook plaats voor het project wordt afgeleverd, en is de verantwoordelijkheid van de Quality Assurance Manager, samen met de Project Manager. Hierbij gaan we controleren of alle code en documenten wel voldoen aan de vereisten opgesomd in het SQAP. 7.2.6
In-process Audits
Hierbij gaan we kijken of alle code en documenten nog consistent zijn. Deze audit is de verantwoordelijkheid van de Quality Assurance Manager. We leggen voornamelijk de nadruk op: Is de code nog consistent met de design documenten? Is de publieke website nog steeds consistent met de staat van het project? Zijn de design documenten nog steeds consistent met de SRS? Zijn de software testen nog steeds consistent met de SRS?
8
7.2.7
Software Configuration Management Plan Review
Alle leden horen de status van het version control bij te houden zodat de adequaatheid en de compleetheid van de software configuratie gegarandeerd blijft, zoals opgesteld in het SCMP. 7.2.8
Post Mortem Review
Na elke iteratie gaan we deze review houden. We overlopen de iteratie en bekijken waar we bij de volgende iteratie moeten op letten, of wat we beter kunnen doen. We overlopen en evalue¨eren alle vooropgestelde doelen, alsook de functionaliteit van deze iteratie. Deze review is de verantwoordelijkheid van de Quality Assurance Manager.
8
Testen Unit Testing: ieder teamlid test zijn eigen geschreven code De Quality Assurance Manager zorgt ervoor dat de integratie en systeemtests worden uitgevoerd. Zie Software Test Document voor meer details
9 9.1
Problemen rapporteren en oplossen Documentatiefouten
Wanneer er kleine fouten worden opgemerkt, mogen deze worden opgelost door de persoon die ze ontdekt. Onder kleine fouten verstaan we spelling, grammatica, layout,... Wanneer er fouten worden opgemerkt in verband met documentstructuur of het toevoegen of verwijderen van onderdelen, wordt dit gemeld aan de schrijver van het document. Deze kan dan de nodige aanpassingen doen. Per document is er een hoofdverantwoordelijke en een back-up persoon voorzien. Deze back-up persoon zal bij afwezigheid of bij het wegvallen van de hoofdverantwoordelijke, al deze zijn taken op zich nemen.
9.2
Broncode fouten
Wanneer er een bug wordt opgemerkt kan dit worden gerapporteerd via Mantis. Deze wordt beschikbaar gemaakt via de site. Diegene die de code geschreven heeft waar de bug zich bevindt, zal deze ook oplossen.
10
Tools, technieken en methodologie¨ en
Version control wordt mogelijk gemaakt door Subversion 9
11
Media controle
Het is de taak van de Configuration Manager dat de softwaremedia conform het SCMP zijn. Elk teamlid zorgt ervoor dat alle documenten en code geplaatst worden op de svnrepository op de wilma-server. Hiernaast houdt elk teamlid ook best nog een backup bij van al zijn bestanden. Het is handig dat elk een kopie heeft van de svn-repository, zodanig dat iedereen weet wie welke wijziging heeft aangebracht.
12
Leverancier controle
Voor dit project maken we alleen maar gebruik van open-source software. We kunnen er van uitgaan dat al deze programma’s werken, en daarom voeren we hierop ook minder controle uit.
13
Gegevens verzamelen,onderhoud en opslag
Alle documenten worden bewaard in de svn-repository op de wilma-server. Deze documenten bevatten de verschillende reviews en inspectiedocumenten.
14
Training
Wanneer een teamlid een programma of programmeertaal nog niet kent, gaat hij deze grondig moeten bestuderen. Hij gaat dit zelfstandig moeten doen, maar kan altijd hulp vragen bij teamleden. Voorts zullen er door de teamleden leermateriaal en nuttige tutorials voorzien worden.
15
Risk management
Elk teamlid wordt aangemoedigd zoveel mogelijk risico’s te vinden en te melden aan het hele team. Alle risico’s bevinden zich in het SPMP.
10
16 16.1
Bijlagen Software Specificatie Review
Datum: 11/05/2011 Jeroen Van den haute Ontbreken beschrijving priv´eberichten in SRS Ontbreken priv´eberichten inbox in SRS Ontbreken vrienden worden in SRS Ontbreken avator in SRS Goldmember aankopen: niet mogelijk om correct te implementeren, functionaliteit goldmember samengevoegd met Freemember
16.2
Software Specificatie Review
Datum: 18/05/2011 Jeroen Van den haute Alles over priv´eberichten is toegevoegd Vrienden worden is toegevoegd Avatar maken is toegevoegd
16.3
Functionele Audit
Datum: 18/05/2011 Jeroen Van den haute en Beerend Ceulemans Nieuwe SRS besproken en goedgekeurd Geupdate SQAP(reviews werden toegevoegd) besproken en goedgekeurd
16.4
Fysieke Audit
Datum: 18/05/2011 Jeroen Van den haute en Beerend Ceulemans Alle code werd grondig overlopen en aangepast waar nodig Documenten werden gecontroleerd in Functionele audit
11
16.5
Post Mortem Review
Na elke iteratie werd tijdens een meeting mondeling overlopen wat beter moet en waar we extra moeten op toezien.
12
