Software Quality Assurance Plan

Transcriptie

1 Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking Bram Bruyninckx Eerste iteratie 1

2 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het team Tom Strickx Brecht Van Laethem Bram Bruyninckx Roeland Matthijssens Gil Moeremans Goedele Van kerkhoven 2

3 Inhoudsopgave 1 Doel 4 2 Referenties 4 3 Management Organisatie Taken Verantwoordelijkheden Documentatie Software Requirements Specification Software Design Document Software Configuration Management Plan Standards Documentatie standards Code standards Testing Standards Metrieken Software Reviews Software Specificatie Review Software Design Review Functional Audit In-process Audits Code versus Design Test-cases versus Requirements Management Reviews Software Configuration Management Plan Review Tests 9 8 Probleemrapportering 9 9 Media controle 9 10 Records collectie, onderhoud, retention 9 11 SQAP: Veranderingen en Historiek 9 3

4 1 Doel Dit document wordt gehanteerd bij het Project Gametrac, om te garanderen dat de software die ontwikkeld wordt van een zo hoog mogelijk kwalitatief niveau is. Het bevat hiertoe richtlijnen en methodes die het ontwikkelingsteam moet toepassen en die betrekking hebben tot de ontwikkelde software, documenten en het ontwikkelingsproces. Voor een beschrijving van het project wordt er verwezen naar het Software Project Management Plan (SPMP). 2 Referenties 1. Style Guide for python, Software Project Management Plan (SPMP), dit document en volgende documenten op se1 1011/documenten, Software Configuration Management Plan (SCMP) 4. Software Requirements Specification (SRS) 5. Software Design Document (SDD) 6. Software Test Document (STD) 3 Management 3.1 Organisatie Het ontwikkelingsteam bestaat uit 6 leden waarvan er 4 leden zijn die een rechtstreeks effect hebben op de kwaliteit van de software: Project Manager: leidt het project en zorgt ervoor dat alles vlot verloopt Requirements Manager zorgt ervoor dat de vereisten opgesteld worden en schrijft deze neer in het Software Requirements Specification (SRS). Bovendien moet hij controleren dat alle vereisten aanwezig zijn in het eindproduct. Design Manager: staat in voor het design van de software, Deze vinden we terug in het Software Design Document (SDD). Quality Assurance Manager: is verantwoordelijk voor het schrijven van het Software Quality Assurance Plan (SQAP) en het Software Test Document (STD). Bovendien moet hij controleren dat de richtlijnen uit deze documenten worden toegepast. Aangezien het ontwikkelingsteam klein van omvang is, wordt er verwacht dat elk lid zijn verantwoordelijkheid omtrent Quality Assurance op zich neemt en de methodes en richtlijnen besproken in dit document volgt. Het is de taak van de Quality Manager om op te volgen dat dit gebeurt. 4

5 3.2 Taken Volgende taken zijn onderdeel van de Quality Assurance: Overzien van de volgende activiteiten: Requirements specificatie Design Implementatie Testen Reviewen van officiele documenten Reviewen van Code Controleren dat bepaalde attributen aanwezig zijn in de software Controleren of het systeem aan de vereisten voldoet Controleren of het systeem voldoende getest wordt Aanpassen van dit document Al deze taken dienen ervoor om te garanderen dat de software die onwikkeld wordt, een bepaald niveau van kwaliteit haalt. 3.3 Verantwoordelijkheden Al deze taken zijn de verantwoordelijkheid van de Quality Manager. 4 Documentatie Deze sectie bevat alle documenten die gereviewd moeten worden alsook de zaken die men moet controleren. 4.1 Software Requirements Specification Het is noodzakelijk dat het SRS alle vereisten bevat, die opgesteld werden met de klant. Deze vereisten moeten compleet zijn, m.a.w. ze zijn volledig uitgediept waarbij er geen dubbelzinnigheden zijn of ruimte voor interpretatie is. Bovendien mogen er geen inconsistenties in het document aanwezig zijn, d.w.z. dat er geen vereisten zijn die elkaar tegenspreken. Bij elkaar horende vereisten worden best gegroepeerd en er mogen geen duplicaten zijn (vereisten die tweemaal aanwezig zijn). Het document is conform met de IEEE std Software Design Document Het SDD moet zodanig opgesteld worden dat het systeem alle vereisten uit het SRD, bevat. In dit document wordt de architectuur van de software uit te doeken gedaan. Het is daarom belangrijk dat alle aspecten van het systeem aan bod komen en dat het een compleet geheel vormt. Bovendien mag het geen inconsistenties bevatten. Het document is conform met de IEEE std

6 4.3 Software Configuration Management Plan Dit document beschrijft hoe het software configuration management zal verlopen, welke activiteiten hiervoor noodzakelijk zijn, hoe deze uitgevoerd worden en wie deze zal uitvoeren. Het moet methoden definieren om gecontroleerde versies te onderhouden, te bewaren, te beveiligen en te documenteren. Het document is conform met IEEE std Standards Standards, Praktijken, Conventies en Metrieken 5.1 Documentatie standards Layout: Het is belangrijk dat alle documenten eenzelfde stijl hebben, om dit te verwezenlijken is er een template voor LateX voorzien. Alle documenten moeten geschreven worden a.d.h.v. deze template. Inhoud: Inzake inhoud is het noodzakelijk dat alle documenten conform zijn met de overeenkomstige IEEE-standaarden. Domein- Taal: Er werd afgesproken om alle documenten in het Nederlands te schrijven. specieke woorden mogen in het Engels geschreven worden. Elk document wordt ten laatste op de afgesproken interne deadline, in de repository geplaatst. Het is de taak van de documents manager om te controleren of de documenten voldoen aan de normen. 5.2 Code standards De code standards die hier beschreven worden, hebben enkel betrekking tot python, aangezien deze programmeertaal gehanteerd wordt tijdens het project. De conventies werden deels gehaald uit de Style Guide voor python [1]. Indentation: Voor indentation wordt er gebruikt van tabs en niet van spaces, 1 tab per indentation level. Lege regels: Top level functies en klasse defenities wordt gescheiden van hun body door 2 lege regels. Methodes binnen een klasse worden gescheiden door 1 lege regel. Meerdere regels mogen eventueel gebruikt worden om groepen van gerelateerde functies te onderscheiden. Imports: Imports gebeuren altijd op verschillende lijnen en bevinden zich steeds bovenaan in een bestand. Volgende volgorde wordt gehanteerd: 1. Standard Library Imports 2. Third Party Imports 3. Applicatie Specifieke Imports Statements: Een enkele statement per lijn. 6

7 Comments: Alle comments worden geschreven in het Nederlands. Alle comments moeten steeds up-to-date zijn, dit is een prioriteit Comments moeten complete zinnen zijn. Een comment voor een klasse definitie bevat de volgende informatie: Beschrijving van het soort object dat de klasse voorstelt. Beschrijving van de velden. Informatie omtrent de methodes van de klasse wordt voorzien in een aparte comment per methode. Een comment voor een functie bevat de volgende informatie/ Beschrijving van wat de functie doet. Beschrijving van de parameters. Beschrijving van errors die de functie eventueel veroorzaakt. In de body van een functie worden de verschillende statements uitgelegd, tenzij triviaal. Hieronder verstaan we dat de lezer geen verdere informatie nodig heeft om te weten wat de statement doet. Naam Conventies Packages en modules: bestaan volledig uit lowercase-letters. Class names: Voor het benoemen van klassen gebruiken we het CapWords-principe. Elke naam begint met een hoofdletter en bij namen die uit meerdere woorden bestaan, krijgt elk woord een hoofdletter. Function names: zijn volledig lowercase, woorden mogen gescheiden worden d.m.v. underscores om het leesbaarder te maken. Variabelen: Variabelen worden geschreven a.d.h.v. het mixedcase-principe. Dit is hetzelfde als CapWords-principe, het enige verschil is dat namen met een lowercase-letter beginnen. Constanten: bestaan volledig uit hoofdletters, verschillende woorden worden gescheiden van elkaar a.d.h.v. underscores. 5.3 Testing Standards De manier waarop testing zal gebeuren, kan men terug vinden in het Software Test Document (STD). 5.4 Metrieken De volgende metrieken worden gehanteerd tijdens de reviews Aantal lijnen code per software object (functies, klassen,...) Aantal error messages 7

8 6 Software Reviews 6.1 Software Specificatie Review Het is noodzakelijk dat het SRS nagelezen en overlopen wordt. Het voltallige team is aangewezig bij deze review en ze wordt geleid door de software requirements manager. Deze overloopt het document en noteert de commentaar die geleverd wordt. Op het einde van de review somt hij de acties op die hij zal ondernemen om de commentaren te verwerken en hij zorgt ervoor dat deze uitgevoerd worden. Tenslotte stuurt hij ter verificatie het bijgewerkte document naar de Quality Manager die controleert of de acties werden toegepast. 6.2 Software Design Review Hierbij wordt het SDD onder de loep genomen. Het voltallige team is aanwezig bij de review die geleid wordt door de Software Design Manager. Deze overloopt het SDD en noteert de opmerkingen die gemaakt worden door de andere teamleden. Na het reviewen overloopt hij de commentaren en legt hij uit welke acties hij zal ondernemen. Om te controleren of deze acties uitgevoerd werden, moet het bijgewerkte document opgestuurd worden naar de Quality Manager. 6.3 Functional Audit In deze vergadering gaan we controleren of het systeem voldoet aan de vereisten van de klant. De requirements Manager overloopt het SRD en toont per vereiste een demo die aantoont dat het systeem aan die vereiste voldoet. Het is ook mogelijk dat er een demo uitgevoerd wordt, die meerdere vereisten bevat. 6.4 In-process Audits Code versus Design Wanneer iemand een stuk code geschreven heeft, moet deze gecontroleerd worden opdat hij conform zou zijn met het design. Dit wordt gecontroleerd tijdens vergaderingen. Degene die het stuk code geschreven heeft, legt dit voor en toont aan dat overeenkomt met het design Test-cases versus Requirements Er moet getest worden of het systeem voldoet aan de vereisten, dit gebeurt a.d.h.v. tests. Vooraleer men deze tests kan aanvaarden als bewijs, moeten deze onderzocht worden opdat ze overeenkomstig zijn met de vereiste die ze gaat testen. De persoon die de test-case geschreven heeft, overloopt deze en toont aan dat dit het geval is. 6.5 Management Reviews Om ervoor te zorgen dat alle acties en richtlijnen die beschreven zijn in dit document uitegevoerd worden, moeten er sporadisch management reviews uitgevoerd worden. Dit zal gebeuren om de 3 weken, hierbij worden veranderingen die doorgevoerd moeten worden in het SQAP besproken. Deze reviews worden gehouden tussen de Quality Manager en de Project Manager. 8

9 6.6 Software Configuration Management Plan Review Deze review wordt geleid door de Configuration Manager. Hij overloopt het SCMP samen met de andere teamleden en noteert de opmerkingen die ze maken. Op het einde overloopt hij alle opmerkingen en de acties die hij zal ondernemen. Ter controle hiervan stuurt hij het bijgewerkte document naar de Quality Manager. 7 Tests Voor informatie omtrent testing wordt er verwezen naar het Software Test Document (STD). 8 Probleemrapportering Probleemrapportering en te ondernemen acties: Indien men een probleem tegenkomt, zoals een defect in een stuk code of een fout in een document, dan wordt de auteur ervan op de hoogte gebracht a.d.h.v. een . Deze onderneemt dan de nodige stappen om dit probleem op te lossen. Indien het om ernstige problemen gaat moet de Project Manager eveneens op de hoogte worden gebracht. 9 Media controle Alle informatie omtrent media controle kan men terugvinden in het Software Configuration Management Plan (SCMP). 10 Records collectie, onderhoud, retention Alle documenten omtrent Quality Assurance, data van metingen, reviews worden bijgehouden in de gemeenschappelijke repository. 11 SQAP: Veranderingen en Historiek Veranderingen aan het SQAP mogen enkel uitgevoerd worden door de Quality Manager. Veranderingen worden vooraan in dit document aangeduid d.m.v. de voorziene historiek. 9