Software Engineering – Groep 3 Post Mortem Review 1 Kristof Van Moffaert (QA Manager) 3e Bachelor Computerwetenschappen
[email protected] –
[email protected] 22 februari 2009
v0.1
22/02/2009
Document geschiedenis Kristof Van Moffaert Draft
INHOUDSOPGAVE
2
Inhoudsopgave 1 Doel
3
2 Definities en acroniemen
3
3 Review 3.1 Spiraalmodel . . 3.2 SRS . . . . . . . 3.3 Design . . . . . . 3.4 Implementatie . . 3.5 Code inspectie en 3.6 Code Testing . . 4 Referenties
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commentaar . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
3 3 4 4 4 5 5 5
1
DOEL
1
3
Doel
Dit document bevat het Post Mortem document van de eerste iteratie van het project van groep 3, in het kader van het vak Software Engineering, gedoceerd door professor Dirk Vermeir. In dit document bespreken we het verloop en de opmerkingen van de eerste iteratie. Dit document beschrijft wat er tijdens die iteratie aan het project veranderd is en wat er kan verbeterd worden aan de gekozen werkwijze. De opmerkingen gegeven in dit document heeft als doel om iets te leren uit de werking van iteratie 1.
2
Definities en acroniemen • QAM: Quality Assurance Manager • SQAP: Software Quality Assurance Plan • SCMP: Software Configuration Management Plan • SPMP: Software Project Management Plan • SDD: Software Design Document • SRS: Software Requirements Specification • STD: Software Test Document • KLOC: Kilo lines of code
Wie welke functie vervult binnen dit project, is duidelijk weergegeven in het SPMP.
3
Review
In deze sectie zullen we de verschillende onderdelen en taken van de eerste iteratie bespreken en beoordelen.
3.1
Spiraalmodel
In dit project kozen we voor een snelle eerste iteratie. Het doel dat we hiermee namelijk voor ogen hadden was dat we op een relatief korte tijd een totaalbeeld kregen van het project en voeling met de verschillende tools. Het nadeel hiervan is dat men het zou kunnen klasseren als tijdsverlies, we besteden namelijk talloze uren aan het ontwerpen en implementeren van een programma dat na de eerste iteratie niet meer gebruikt wordt. Een ander nadeel is dat we enkele toegevingen op gebied van functionaliteit hebben gedaan. Dit is een opsomming van de verschillende toegevingen: • Geen echte abstractielaag. • Alle code komt in JSP en Servlets. • Rechtstreeks database aanspreken. • Geen aparte leestoegang tot bepaalde agenda´ s. • Geen meldingen naar de gebruiker toe. • Geen suggesties naar de administrator toe.
3
REVIEW
4
• De performantievereisten worden niet gegarandeerd. • In bulk toevoegen/importeren van gebruikers is niet mogelijk. Maar toch hebben deze toegevingen en onze snelle eerste iteratie, enkele interessante opmerkingen naar boven gebracht. • Het SDD van de eerste iteratie was onvolledig op gebied van recurrente afspraken. We verdiepen ons in de tweede iteratie in de RFC-2445 library. • Dagoverschrijdende afspraken waren tot nu toe zeer onperformant ge¨ımplementeerd. We moesten namelijk de begindatum en de duur van alle afspraken tot de gewenste datum nakijken op deze eigenschap. In de tweede iteratie wordt hier zeker rekening mee gehouden. • Joda time biedt ondersteuning voor verschillende tijdzones. Dit zou een mooie uitbreiding zijn voor de tweede iteratie. • Het database design was, op uitzondering van de dagoverschrijdende afspraken, zo goed als perfect. Dit zal niet al te veel veranderingen moeten ondergaan om goedgekeurd te worden voor de volgende iteratie.
3.2
SRS
Na een moeilijke start en verscheidene draft versies is het team en meer bepaald de Software Requirements Manager erin geslaagd een volwaardig document af te leveren. De eerste draft bevatte een fout conceptueel model, waardoor het haast helemaal herschreven diende te worden. Het uitschrijven van de verschillende use cases werd verdeeld door de Implementation Manager, waarna het schrijfwerk eerlijk verdeeld kon worden. Iedereen werkte vlot mee aan het voltooien van dit document. Voor de correctheid en het nakijken van de inhoud van het SRS, werd een beroep gedaan op de Quality Assurance Manager en de Design Manager. De inspectiedocumenten, betreffende de taalfouten en dergelijke, zijn te vinden in de QA sectie van de Trac Repository. Na de tweede draft van dit document, werd het SRS goedgekeurd door elk teamlid om zowel te dienen voor de eerste als voor de tweede iteratie. In de tweede iteratie was er dus geen nood aan een nieuw interview met de klant
3.3
Design
Doordat we gebruik maakten van twee iteraties, met elk een verschillende diepgang, is er nood aan een verschillend Software Design Document voor elke iteratie. De moment waarop dit PMR afgerond wordt, is het SDD van de tweede iteratie nog in opbouw. Er is wel reeds een draft versie te vinden in de Trac Repository. De verschillende drafts van het SDD werden, net als de overige documenten, nagekeken door de Quality Assurance Manager. De opmerkingen op gebied van taal en spelling zijn te vinden in de Trac Repository.
3.4
Implementatie
De vooropgestelde taken voor de eerste iteratie werden opgesteld in het Implementation Document. De Implementation Manager verdeelde de taken op gebied van tot nu toe gepresteerde uren. Voor de grafische weergave van deze kalender, werd enkel gebruik gemaakt van HTML. Dit zal in de tweede iteratie vervangen worden door CSS, samen met JavaScript. Voor meer informatie verwijzen we naar het GUI document.
4
REFERENTIES
5
Alle vooropgestelde taken, voorzien voor de eerste iteratie werden uitgevoerd. Het is nu aan ons, om deze kennis over de positieve en de negatieve kanten van ons tot nu toe gepresteerd werk om te zetten in een succesvolle tweede iteratie.
3.5
Code inspectie en Commentaar
Doordat we kozen voor een snelle eerste iteratie, is er weinig aandacht gegaan naar het inspecteren van de code. Evenals naar de aanwezigheid van commentaar en de javadoc informatie. Dit was een keuze van de groep en had als doel zoveel mogelijk tijd te kunnen stoppen in het afwerken van de eerste iteratie. Dit is een evidente keuze aangezien het werk dat tot nu toe gepresteerd werd, niet hergebruikt zal worden in de tweede iteratie. Deze toegeving heeft natuurlijk enkel nut als we dan in de volgende iteratie dubbel zo goed de codeerconventies, commentaar als de javadoc informatie nagekeken wordt. Het is de taak van de Quality Assurance Manager om hierop toe te zien en eventuele opmerkingen door te spelen naar de desbetreffende auteurs.
3.6
Code Testing
Het testen van de code in de eerste iteratie, werd uitgevoerd op een black box manier. Met andere woorden, er werden geen unit- of integrationtests uitgevoerd. Voor deze draft versie was het voldoende dat de correctheid van de code aangetoond werd door het manueel testen van de verschillende JSP-pagina’s. In de tweede iteratie zal er vanzelfsprekend wel gebruik gemaakt worden van de verschillende test-frameworks.
4
Referenties • SPMP, Software Project Management Plan - http://wilma.rave.org:3333/Trac/browser/Documents • SRS, Software Requirements - http://wilma.rave.org:3333/Trac/browser/Documents • QA documents - http://wilma.rave.org:3333/Trac/browser/Documentation/QADocuments • GUI document - http://wilma.rave.org:3333/Trac/browser/Documents
