Software Engineering Groep 4

Software Engineering Groep 4 Software Project Management Plan Jan-Pieter Hubrecht (Project Manager) Kevin Hendrickx (Assistent Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be 11 december 2011 1

Tabel 1: Document geschiedenis v3.0 11/12/2011 Jan-Pieter Hubrecht Eindcontrole v2.1 29/11/2011 Jan-Pieter Hubrecht Aanvullingen v2.0 13/11/2011 Jan-Pieter Hubrecht Eindcontrole v1.2 11/11/2011 Jan-Pieter Hubrecht Aanvullingen v1.1 08/11/2011 Jan-Pieter Hubrecht Revisie v1.0 30/10/2011 Jan-Pieter Hubrecht Eindcontrole v0.4 30/10/2011 Kevin Hendrickx Controle en Aanvullingen v0.3 29/10/2011 Team Aanvullingen v0.2 29/10/2011 Jan-Pieter Hubrecht Kladversie v0.1 27/10/2011 Kevin Hendrickx Kladversie 2

Inhoudsopgave Inhoudsopgave 1 Algemeen overzicht 5 1.1 Project beschrijving................................. 5 1.1.1 Doelstellingen en bereik van het project.................. 5 1.1.2 Veronderstellingen en beperkingen..................... 5 1.1.3 Project opleveringen............................. 5 1.1.4 Planning en budget overzicht........................ 5 1.2 Evolutie van het SPMP............................... 6 2 Referenties 7 3 Afkortingen en definities 8 3.1 Afkortingen...................................... 8 3.2 Definities....................................... 8 4 Project Organisatie 9 4.1 Externe communicatie................................ 9 4.2 Interne structuur................................... 9 4.3 Rollen en verantwoordelijkheden.......................... 9 5 Managerial Process plans 12 5.1 Opstartplan...................................... 12 5.1.1 Schattingsplan................................ 12 5.1.2 Personeelsplan................................ 12 5.1.3 Plan om middelen te bekomen....................... 12 5.1.4 Personeelstrainingsplan........................... 13 5.2 Werkplan....................................... 13 5.2.1 Werkactiviteiten............................... 13 5.2.2 Vergaderingen................................ 13 5.2.3 Grafische voorstelling van de planning................... 14 5.2.4 Resource Allocation............................. 16 5.3 Controleplan..................................... 17 5.3.1 Requirements Control Plan......................... 17 5.3.2 Schedule Control Plan............................ 17 5.3.3 Reporting Plan................................ 17 5.4 Plan voor risicobeheer................................ 18 5.4.1 Gebrek aan kennis junit........................... 18 5.4.2 Gebrek aan kennis SQL........................... 18 5.4.3 Gebrek aan communicatie.......................... 18 5.4.4 Gebrek aan Version Control kennis..................... 18 5.4.5 Gebrek aan kennis LaTeX.......................... 19 5.4.6 Gebrek aan ervaring in groep........................ 19 5.4.7 Het ziek worden van een teamlid...................... 19 5.4.8 Gebrek aan kennis Java/Android SDK................... 19 5.5 Project Closeout Plan................................ 20 6 Technisch Proces Plans 21 6.1 Proces model..................................... 21 6.2 Methodes, hulpmiddelen en technieken....................... 21 6.3 Infrastructure plan.................................. 21 3

Inhoudsopgave 6.4 Product acceptance plan............................... 22 7 Plannen ondersteunende processen 23 7.1 Configuration management plan........................... 23 7.1.1 Organisatie.................................. 23 7.1.2 Verantwoordelijkheden............................ 23 7.1.3 Regels, Richtlijnen en Procedures...................... 23 7.1.4 SCM Activiteiten............................... 23 7.1.5 Configuratie controle............................. 24 7.1.6 Configuratie verificatie en verslag...................... 24 7.1.7 SCM middelen................................ 24 7.2 Verification and validation plan........................... 25 7.3 Quality Assurance Plan............................... 25 7.3.1 Organisatie.................................. 25 7.3.2 Verantwoordelijkheid............................. 25 7.3.3 Vereiste documentatie............................ 25 7.3.4 Standaarden, conventies en metrieken................... 25 7.3.5 Software inspecties.............................. 26 7.3.6 Testen..................................... 27 7.3.7 Problemen rapporteren en verbeteren................... 27 7.3.8 Code controle................................. 27 8 Aanvullende plannen 28 4

1 Algemeen overzicht 1 Algemeen overzicht 1.1 Project beschrijving 1.1.1 Doelstellingen en bereik van het project Dit project is in opdracht van Professor Van Der Straeten ter examinatie van de cursus Software Engineering aan de Vrije Universiteit Brussel. De bedoeling is om een Android applicatie te bouwen die functioneert als een interactieve toeristische gids in een bepaalde stad. De gebruiker moet in staat zijn om de nabijgelegen bezienswaardigheden op een vlotte manier te kunnen zoeken en na het lezen van de informatie, eventueel te bezoeken. Door het uitdelen van scores leert de applicatie wandelingen samen te stellen die overeenstemmen met de voorkeuren van de gebruiker. Een gedetailleerd overzicht van de vereisten is terug te vinden in het SRS. 1.1.2 Veronderstellingen en beperkingen Veronderstellingen Tot op heden zijn er nog geen veronderstellingen gemaakt. Beperkingen De volgende lijst geeft een overzicht van de beperkingen die zijn opgelegd: De applicatie moet als frontend werken op Android versie 2.2. De applicatie moet als backend werken op Wilma (VUB, infogroep server). De 2 Android smartphones worden pas het 2e semester ter beschikking gesteld. Het systeem moet eenvoudig geïnstalleerd kunnen worden. De applicatie moet intuïtief en gebruiksvriendelijk zijn. Het ontwerp van de applicatie moet modulair zijn. De programmeertaal is Java, eventueel uitgebreid met bibliotheken. Er moet gewerkt worden naar deadlines. 1.1.3 Project opleveringen Vanwege de moeilijkheidsgraad van het project zullen er voor het tweede semester extra iteraties voorzien worden die los staan van de iteraties die opgelegd zijn door de Professor Van Der Straeten. Voor de mogelijkheid tot een grondig nazicht alvorens de definitieve deadline, worden er intern extra deadlines toegewezen. We onderscheiden deze intern opgelegde soft-deadlines van de extern opgelegde hard-deadlines. Van hard-deadlines kan niet worden afgeweken omdat dit zich reflecteert in het verlies van punten voor het vak. 1.1.4 Planning en budget overzicht In de vooropgestelde planning is er gebruik gemaakt van zowel extern opgelegde hard-deadlines als intern zelf opgelegde soft-deadlines. In tabel 2 en 3 zijn respectievelijk de deadlines voor het eerste en tweede semester te vinden. Hoogstwaarschijnlijk zullen er 4 iteraties doorlopen worden voor het schrijven van de code en documenten. Voor dit project is er geen budget voorzien. Voor een gedetailleerd overzicht zie sectie 5.2. 5

1 Algemeen overzicht Tabel 2: Deadlines eerste semester Datum Activiteit Aard 28/10/2011 Kladversie SPMP Soft-deadline 31/10/2011 Inleveren SPMP Hard-deadline 12/11/2011 Kladversie SPMP, STD, SRS, SDD Soft-deadline 14/11/2011 Inleveren STD, SRS, SDD Hard-deadline 10/12/2011 Revisie SPMP, STD, SRS, SDD Soft-deadline 13/12/2011 Einde 1e iteratie: opleveren code en documenten Hard-deadline 21/12/2011 Presentatie 1e iteratie Hard-deadline Tabel 3: Deadlines tweede semester Datum Activiteit Aard 06/03/2012 Einde 2e iteratie: opleveren code en documenten Hard-deadline 14/03/2012 Presentatie 2e iteratie Hard-deadline 17/04/2012 Einde 3e iteratie: opleveren code en documenten Hard-deadline 25/04/2012 Presentatie 3e iteratie Hard-deadline 18/05/2012 Einde 4e iteratie: finale oplevering Hard-deadline 23/05/2012 Finale presentatie Hard-deadline 1.2 Evolutie van het SPMP De Project Manager verzorgt het SPMP maar deze kan eventueel worden bijgestaan door de Assistent Project Manager. Het document moet telkens up-to-date zijn bij een strikte deadline. De geschiedenis van de veranderingen is terug te vinden in tabel 1. Na elke vergadering zal het document worden herzien en indien nodig worden aangepast. Elke wijziging zal worden doorgegeven aan de Project Manager die de eindcontrole doet. Dit document hanteert de IEEE 1058-1998 standaard. 6

2 Referenties 2 Referenties Referenties [1] Groep 4. Software Design Description v1.0. http://wilma.vub.ac.be/~se4_1112/docs/sdd-v1.0.pdf. [2] Groep 4. Software Engineering Groep 4-2011. http://wilma.vub.ac.be/~se4_1112/. [3] Groep 4. Software Project Management Plan v2.0. http://wilma.vub.ac.be/~se4_1112/docs/spmp-v2.0.pdf. [4] Groep 4. Software Requirements Specification v1.0. http://wilma.vub.ac.be/~se4_1112/docs/srs-v1.0.pdf. [5] Groep 4. Software Test Document v1.0. http://wilma.vub.ac.be/~se4_1112/docs/std-v1.0.pdf. [6] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. IEEE Standard for Software Project Management Plans (SPMP), 1998. [7] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. IEEE Standard for Software Quality Assurance Plans (SQAP), 2002. [8] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. IEEE Standard for Software Configuration Management Plans (SCMP), 2005. [9] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. IEEE Standard for Software and System Test Documentation (STD), 2008. [10] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. IEEE Recommended Practice for Software Requirements Specifications (SRS), 2009. [11] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. IEEE Standard for Information Technology Systems Design Software Design Descriptions (SDD), 2009. 7

3 Afkortingen en definities 3.1 Afkortingen 3 Afkortingen en definities CI IDE SCMP SPMP SQAP SRS STD VUB Configuration Item Integrated Development Environment Software Configuration Management Plan Software Project Management Plan Software Quality Assurance Plan Software Requirements Specification Software Test Document Vrije Universiteit Brussel 3.2 Definities Configuration Item De Klant Het Product Repository Repository clone Repository pull Repository push Een deel van het project dat beheerd wordt door het configuratie systeem. De personen die de opdracht hebben gegeven tot het ontwikkelen van het product: Professor Van Der Straeten en haar assistent Jens Nicolay. De Mobile City Guide software voor op Android. Documenten die op een gestructureerde manier gedeeld en aangepast worden door verschillende mensen. De documenten van een remote repository lokaal kopiëren. De lokale documenten updaten met de nieuwe versie van de remote repository. De remote repository updaten met de nieuwe versie van de lokale repository. 8

4 Project Organisatie 4 Project Organisatie 4.1 Externe communicatie Professor Van Der Straeten en haar assistent Jens Nicolay zijn de klanten van de applicatie die ontwikkeld zal worden. De communicatie met hen zal gebeuren via de Project Manager en eventueel de Design Manager. De back-end van de applicatie zal draaien op de Wilma server die beheerd wordt door Dirk Van Deun. De communicatie met hem zal gebeuren via de Configuratie Manager en de Project Manager. Daarnaast is het mogelijk dat de Infogroep gebruikt zal worden als externe hulplijn. 4.2 Interne structuur De grafische representatie van de interne structuur en de hiërarchie hiervan, is weergegeven in het organigram in figuur 1. Zwarte volle lijnen geven de interne hiërarchie weer. De rode stippellijnen duiden de interne communicatie aan. De groene lijn-streep-lijn verbindingen duiden interactie met de externe bronnen aan, zoals daar zijn de klant, de server en de website. Bovenaan de figuur staat de klant. De reden dat er wel een groene lijn staat tussen de klant en de website en niet tussen de klant en de server-repository is omwille van het feit dat de klant rechtstreeks aan de website kan maar niet rechtstreeks naar de back-end server kan, hiervoor moet hij gebruik maken van de applicatie. De horizontale zwarte streeplijn is de scheiding tussen de klant en het project. De reden dat de server-repository en de website op deze lijn liggen is omwille van het feit dat deze zowel door de klant als het project aanspreekbaar zijn. Het onderste gedeelte van de figuur geeft de interne structuur weer. Aan het hoofd staat de Project Manager. Deze wordt bijgestaan door de Assistent Project Manager en de Secretaris. Verder zijn er nog de andere functies Configuration Manager, Design Manager, Requirements Manager, Implemenation Manager, Quality Manager, Test Manager, Database Manager en Webmaster. Een gedetailleerde beschrijving van de taken van de verschillende functies is terug te vinden in sectie 4.3. De rode stippellijnen duiden de interne communicatie aan tussen de verschillende functies aan. 4.3 Rollen en verantwoordelijkheden Project Manager Is de algemeen verantwoordelijke voor het project Zit de vergaderingen voor en bepaald de onderwerpen van deze vergaderingen Is verantwoordelijk voor communicatie en contact met de docent en de assistent Leest de rapporten na en keurt deze goed alvorens deze gepubliceerd worden Observeert de vooruitgang van het project en de taken Verdeelt de taken naargelang de tijdsdruk Is de eindverantwoordelijke voor SPMP en houdt deze up-to-date Keurt alle beslissingen goed vooraleer deze worden uitgevoerd Assistent Project Manager Verzorgt samen met de Project Manager het SPMP Neemt taken over van de Project Manager waar nodig Configuration Manager Zorgt ervoor dat iedereen het systeem van de repositories kent 9

4 Project Organisatie Figuur 1: 8 Grafische representatie van de interne structuur. Zwarte volle lijnen tonen de hiërarchie. De rode stippellijnen staan voor de interne communicatie en de groene lijn-streep-lijn verbindingen duiden interactie met de externe bronnen aan. 10

4 Project Organisatie Maakt de repositories aan Controleert of de repository goed gebruikt wordt (gebruik van branches e.d.) Zorgt dat iedereen begrijpt hoe hij met de repository en bijhorende software moet werken Is verantwoordelijk voor het SCMP gedeelte in het SPMP Is verantwoordelijk voor het opzetten en onderhouden van extra software (zoals bijvoorbeeld de Java android IDE) Database Manager Verantwoordelijk voor het maken en het onderhouden van de database op de Wilma server Verantwoordelijk voor het back-end systeem dat het mogelijk maakt om op een gemakkelijke manier de database aan te passen Design Manager Kiest de standaard Is verantwoordelijk voor de SDD Leidt de discussies aangaande design Implementation Manager Is verantwoordelijk voor de verdeling van het werkt overheen de programmeurs Overziet de vooruitgang van het programmeren en stuurt waar nodig bij Quality Manager Beslist welke conventies gehanteerd zullen worden in de code en documenten Kijkt de code en documenten na Is verantwoordelijk voor het plannen en leiden van inspecties Is verantwoordelijk voor het SQAP gedeelte in de SPMP Requirements Manager Kiest de standaard Is verantwoordelijk voor het SRS document Leidt de discussies in verband met de software vereisten Test Manager Is verantwoordelijk voor het testen van de vereisten en verificatie Is verantwoordelijk voor het STD document en houdt dit up-to-date Is verantwoordelijk voor het schrijven van een document met de test resultaten Webmaster Onderhoudt de website gericht naar de klant Secretaris Schrijft de verslagen van de vergaderingen Berekent de duur van elke vergadering 11

5 Managerial Process plans 5.1 Opstartplan 5.1.1 Schattingsplan 5 Managerial Process plans Aangezien dit een project is zonder budget is het niet nodig om dit in het schattingsplan op te nemen. Wat er wel geschat moet worden is het aantal uren dat per teamlid gespendeerd zal worden aan het project. Schatting van het aantal uren Dit project is in het kader van het vak Software Engineering van 9 studiepunten. Het aantal studiepunten van een bepaald vak kan gebruikt worden om het totaal aantal uren te berekenen dat een student aan dat vak moet werken. Volgens de VUB komt 9 studiepunten overeen met 235 a 255 uren werk. Voor dit project gaan we een richtlijn van 245 uren per persoon nemen, inclusief de hoorcolleges. Deze hoorcolleges moeten niet in rekening worden gebracht om een schatting te maken van de totale tijd die aan het project gespendeerd moet worden. We komen dan uit op 210 uur per persoon. In sectie 5.2.4 wordt een gedetailleerde beschrijving van de verdeling van deze uren opgesteld. 5.1.2 Personeelsplan Groepsleden Voor dit project zijn er 7 mensen ter beschikking. In tabel 4 worden de contact gegevens van de verschillende groepsleden op een rijtje gezet. De verschillende functies Voor elke functie wordt er een verantwoordelijke aangeduid, alsook een backup. Deze laatste valt in indien de verantwoordelijke wegvalt maar hij kan deze ook bijstaan bij grote taken. De verdeling van de functies is te zien in tabel 5. 5.1.3 Plan om middelen te bekomen De VUB zal ons 2 Android smartphones ter beschikking stellen om de applicatie te testen aan het begin van het tweede semester. De Wilma server die we gebruiken voor backend, website, repositories en communicatie wordt beheerd door Infogroep. Tabel 4: Overzicht van de teamleden en hun contact gegevens Naam Coppieters Tim De Clerck Quentin Hendrickx Kevin Hubrecht Jan-Pieter Moeremans Gil Nyckees Jeroen Van den Heuvel Lorenz E-Mail Tim.Coppieters[at]vub.ac.be Quentin.De.Clerck[at]vub.ac.be Kevin.Hendrickx[at]vub.ac.be Jan-Pieter.Hubrecht[at]vub.ac.be Gil.Moeremans[at]vub.ac.be Jeroen.Nyckees[at]vub.ac.be Lorenz.Van.Den.Heuvel[at]vub.ac.be 12

5 Managerial Process plans Tabel 5: Overzicht van de verschillende functies en hun backup Functie Verantwoordelijke Backup Project Manager Jan-Pieter Quentin Assistent Project Manager Kevin Configuration Manager Tim Quentin Database Manager Tim Kevin Design Manager Jeroen Lorenz Implementation Manager Gil Jan-Pieter Quality Manager Quentin Lorenz Requirements Manager Lorenz Gil Test Manager Kevin Jan-Pieter Webmaster Kevin Tim Secretaris Lorenz Jeroen 5.1.4 Personeelstrainingsplan Niet iedereen heeft dezelfde voorkennis voor dit project. Voor Android-Java werd in het kader van het vak Software Engineering door Dries Harnie een les gegeven. Andere training moet op zelfstandige basis gebeuren. In tabel 5 werd aangeduid met J wanneer de persoon in kwestie voor een bepaald onderdeel training nodig heeft. Tabel 6: Overzicht van wie welke training nodig heeft Jeroen Quentin Lorenz Jan-Pieter Tim Kevin Gil Java J J N N J J J GIT J J J J N J N junit J J J J J J J 5.2 Werkplan 5.2.1 Werkactiviteiten Voor iedere taak is er een verantwoordelijke aangesteld die de specifieke taak overziet. Naast deze verantwoordelijkheidsfuncties zullen de teamleden ook het nodige programmeerwerk doen. 5.2.2 Vergaderingen De vergaderingen voor het project zullen plaatsvinden op maandag tussen 13:00 en 15:00 tenzij anders afgesproken. Voor elke vergadering worden de agendapunten vastgelegd. Wat niet op de agenda staat wordt niet besproken op de vergadering. De dag voor elke vergadering zal er een reminder worden gestuurd met het uur en de locatie van de vergadering. Indien het nodig wordt geacht om een extra vergadering te houden (bijvoorbeeld bij het naderen van een belangrijke deadline) of om een vergadering te verplaatsen, zal er met de groepsleden overlegd worden wanneer deze best ingepland kan worden. Op de website zijn de verslagen van deze vergaderingen beschikbaar. Tabel 7 geeft een overzicht van de geplande vergaderingen. 13

5 Managerial Process plans Tabel 7: Overzicht van de geplande vergaderingen Dag Uur Duur 24/10/2011 11:00-12:30 1:30 28/10/2011 12:30-13:20 0:50 04/11/2011 13:00-13:25 0:25 07/11/2011 13:00-14:25 1:25 14/11/2011 13:00-13:50 0:50 17/11/2011 11:30-13:20 1:50 21/11/2011 13:00-13:35 0:35 25/11/2011 12:30-13:30 1:00 07/12/2011 13:00-14:00 1:00 5.2.3 Grafische voorstelling van de planning De deadlines die vooropgesteld zijn en terug te vinden zijn in tabel 2 en 3 van sectie 1.1.3, kunnen grafisch worden voorgesteld in een zogenaamde Gantt Kaart. Deze is te zien in figuur 2. Activiteiten De geplande activiteiten worden op de Gantt Kaart voorgesteld door rechthoekjes. Boven de activiteit staat de naam en aan de onderkant de start- en einddatum. Aan de rechterkant staan de groepsleden die meewerken aan de activiteit, de verantwoordelijke staat tussen accolades. In de volgende lijst worden de activiteiten opgesomd: 1e iteratie 2e iteratie 3e iteratie 4e iteratie Milestones De milestones worden op de Gantt Kaart voorgesteld door een ruit. Boven de milestone is de naam terug te vinden. De milestones komen vaak overeen met harde-deadlines aangezien er dan iets specifiek af moet zijn en getoond moet worden aan de klant. De volgende lijst geeft een overzicht van de milestones: Opleveren SPMP Opleveren STD Opleveren SRS Opleveren SDD Opleveren prototype 1e iteratie Presentatie 1 geven Presentatie 2 geven 14

5 Managerial Process plans Figuur 2: De planning grafisch voorgesteld in een Gantt Kaart. 15

5 Managerial Process plans Presentatie 3 geven Finale Presentatie geven 5.2.4 Resource Allocation Voor dit project zijn er per groepslid 210 werkuren voorzien. Deze uren moeten verdeeld worden over de verschillende taken zoals daar zijn het schrijven van de documenten, het ontwikkelen/testen van de code, het opstellen van de requirements en het design, enz. Algemene schatting Aangezien er 7 groepsleden zijn met elks 210 uren, is het totaal aantal uren voor dit project gelijk aan 1470. Bij het verdelen van de uren is er echter een marge van 28 manuren per persoon genomen die dient als reserve. Indien zou blijken dat de schatting niet realistisch is, kunnen deze gebruikt worden om meer tijd te creëren. De eigenlijke belasting zoals deze is ingepland is dus 182 uur per persoon voor het gehele project. In tabel 9 wordt de verdeling van deze uren over de verschillende activiteiten weergeven. De it. x duid op de xste iteratie. Schrijven van documenten In tabel 8 is eens schatting weergeven voor de verschillende documenten die geschreven moeten worden en een schatting van het aantal uren dat hier per groepslid aan gewerkt zal worden. Tabel 8: Overzicht van de schatting van het aantal uren per document Document Sectie Schrijver Geschat aantal uren SPMP Kevin 6 SPMP SPMP Jan-Pieter 8 SQAP Quentin 6 SCMP Tim 4 SRS - Lorenz 8 STD - Kevin 8 SDD - Jeroen 10 Bepalen van de requirements Het bepalen van de requirements is de job van de Requirement Manager. Hiervoor zal er 6 uur voorzien worden. Merk wel op dat deze 6 uur mee verwerkt zit in het opstellen van het SRS aangezien de requirements volledig uitgewerkt moeten worden bij het schrijven van het ervan. Opstellen van het design Het opstellen van het initieel design gebeurt door de Design Manager. Voor het uitwerken van het design is er 7 uur voorzien, die deel uitmaken van het schrijven van de SDD. Daarnaast zal het design ook overlopen en geïnspecteerd worden tijdens de vergaderingen. Dat zal 2 uur in beslag nemen voor ieder groepslid. 16

5 Managerial Process plans Implementeren van de code De geschatte tijd voor het implementeren van de code is te zien in tabel 9. Voor het implementeren van de code is er een onderscheid gemaakt tussen de eerste iteratie en de daaropvolgende iteraties. We zijn er van uitgegaan dat de eerste iteratie een soort opstart iteratie is met 26 werkuren per groepslid. De drie andere iteraties is er 50 uren per persoon voorzien. Testen van de code De geschatte tijd voor het testen van de code maakt deel uit van kwaliteit en test is tabel 9. Ook hier is een onderscheid gemaakt tussen de eerste iteratie en de andere iteraties. Concreet is er in de eerste iteratie slechts 2 uur testing voorzien, aangezien dit een opstart iteratie is (de andere 3 uren zijn voor de kwaliteit van de code). Voor de daaropvolgende iteraties is er 30 uur voor testing voorzien (en 5 voor kwaliteit) voorzien. Maken van presentaties Voor dit project moeten er 4 presentaties worden gegeven. Elke presentatie zal door 2 groepsleden gegeven worden. Bij de planning is er 2 uur per presentator gerekend, dus 4 uur per presentatie (zie tabel 9). Tabel 9: Overzicht van de schatting van het aantal uren per activiteit Activiteit Documenten It. 1 It. 2 It. 3 It.4 Totaal Configuratie 5 5 5 5 5 25 Design 10 20 15 15 15 75 Implementatie 0 140 280 280 280 980 Kwaliteit en testen 6 5 35 35 35 116 Management 25 10 10 10 10 65 Presentaties 0 4 4 4 4 16 Totaal 46 184 349 349 349 1277 Per persoon 6.6 26.3 49.8 49.8 49,8 182 5.3 Controleplan 5.3.1 Requirements Control Plan Bij elk nieuw vastgelegd requirement moet het SRS gewijzigd zorden. Deze wijzigingen worden meegedeeld aan alle teamleden omdat deze een impact kunnen hebben op het design van het product, de implementatie, de tests en de verschillende bijhorende documenten. 5.3.2 Schedule Control Plan De hard-deadlines (strikte deadlines) moeten altijd nageleefd worden. De soft-deadlines kunnen indien nodig herzien een aangepast worden, mits goedkeuring van de Project Manager. Indien een soft-deadline aangepast wordt, zullen alle groepsleden hiervan op de hoogte gebracht worden. 5.3.3 Reporting Plan Bij het schrijven van de documenten wordt er gebruik gemaakt van zowel extern opgelegde hard-deadlines als intern zelf opgelegde soft-deadlines. De hard-deadlines zijn de dagen dat 17

5 Managerial Process plans het final resultaat afgewerkt moet zijn. De soft-deadlines zorgen er voor dat er voldoende tijd is om het document na te lezen en eventuele opmerkingen/fouten aan te passen. Na elke deadline worden de belangrijke wijzigingen meegedeeld aan het team. Indien nodig worden deze verder besproken op de eerstvolgende vergadering. 5.4 Plan voor risicobeheer 5.4.1 Gebrek aan kennis junit Waarschijnlijkheid 9 Impact 7 Prioriteit 20 Oplossing De Test Manager zal junit bestuderen en de andere groepsleden een crash course junit geven zodat deze de basis onder de knie krijgen. Einddatum 28/11/2011 5.4.2 Gebrek aan kennis SQL Waarschijnlijkheid 1 Impact 3 Prioriteit 15 Oplossing Einddatum Tim heeft reeds genoeg ervaring met SQL. Als Database Manager is hij de enige die hier kennis over moet hebben. Indien nodig is Kevin in staat zijn taken over te nemen. Geen datum nodig 5.4.3 Gebrek aan communicatie Waarschijnlijkheid 7 Impact 7 Prioriteit 100 Oplossing Er zal gebruikt gemaakt worden van IRC om informeel met elkaar te kunnen praten. Gregory voorziet een tutorial voor IRC. Voor de formele communicatie is er een mailing list. GSM nummers worden uitgewisseld voor snel contact bij dringende redenen. Einddatum 28/10/2011 5.4.4 Gebrek aan Version Control kennis Waarschijnlijkheid 8 Impact 10 Prioriteit 100 18

5 Managerial Process plans Oplossing Einddatum 05/11/2011 5.4.5 Gebrek aan kennis LaTeX Waarschijnlijkheid 2 Impact 2 Prioriteit 5 Tim heeft reeds ervaring met GIT. Hij zal ons helpen de basis aan te leren. Tim heeft ook een kleine tutorial geschreven over GIT. De rest is zelfstudie. Oplossing Einddatum Iedereen heeft notie van LaTeX. Het schrijven van documenten zorgt voor geen problemen. Indien er toch kleine problemen opduiken staat het team via IRC klaar om te helpen. Doorlopend 5.4.6 Gebrek aan ervaring in groep Waarschijnlijkheid 8 Impact 3 Prioriteit 20 Oplossing Door gebrek aan ervaring zal er vaker vergaderd worden. Enkel ervaring in de praktijk kan dit verbeteren. Jan-Pieter en Lorenz hebben reeds in groep gewerkt. Dit gaf Jan-Pieter de functie als Project Manager. Einddatum Doorlopend 5.4.7 Het ziek worden van een teamlid Waarschijnlijkheid 8 Impact 9 Prioriteit 20 Oplossing Einddatum Om gebrek aan teamleden te voorkomen is er de eerste vergadering reeds voor elke functie een back-up voorzien. De Project Manager kan ook het werk (zoals ontwikkelen van code) verdelen onder de overige teamleden. Geen datum nodig 5.4.8 Gebrek aan kennis Java/Android SDK Waarschijnlijkheid 6 Impact 7 Prioriteit 200 Oplossing Nog niet beslist Einddatum 21/11/2011 19

5 Managerial Process plans 5.5 Project Closeout Plan Dit project zal onmiddellijk stop gezet worden na finale presentatie. De website en repository blijven online staan maar deze worden niet meer ge-update. Ook wordt er geen verdere ondersteuning geleverd bij eventuele problemen. 20

6 Technisch Proces Plans 6.1 Proces model Eerste iteratie 6 Technisch Proces Plans In de eerste iteratie zal er gebruik gemaakt worden van een evolutionair prototype. De bedoeling is om incrementeel kleine aanpassingen te doen, deze te testen en evalueren om er zo voor te zorgen dat er snel een werkend product is (dat nog niet compleet is). Het voordeel is dat bepaalde delen getest kunnen worden desondanks dat de volledige functionaliteit nog niet beschikbaar is. Volgende iteraties Voor de andere iteraties is nog niet bepaald welk model er gebruikt zal worden. Het is perfect mogelijk om dan te kiezen voor een ander model. 6.2 Methodes, hulpmiddelen en technieken Voor dit project zal er gebruik gemaakt worden van verschillende softwarepaketten en hulpmiddelen. Tabel 10 geeft een overzicht van de gebruikte software. 6.3 Infrastructure plan De software moet werken op de 2 beschikbare Android smartphones. De smartphones zijn de front-end en zullen beschikbaar zijn vanaf het tweede semester. De database en website zullen op de back-end draaien. Voor dit project is dit de Wilma server van de Infogroep. Iedere programmeur heeft zijn eigen laptop, de meeste onder ons werken met OSX, sommigen met Linux. Op deze laptops wordt er gebruikgemaakt van de Android SDK die ook een simulator heeft. Tabel 10: Overzicht van de gebruikte software en hulpmiddelen Doel Applicatie Versie Beschrijving Projectbeheer Redmide Bijhouden van de gepresteerde aantal uren Versiebeheer GIT Gecontroleerd samen werken IDE Eclipe Indigo Programmeeromgeving Android SDK Android SDK r15 Plugin voor de Android ontwikkeling MYSQL Database die op de back-end draait Database SQLite Database die lokaal op Android draait Ruby on Rails Database opvullen via de website UML diagrammen Concept Draw Manueel opstellen van UML diagrammen Documentatie Doxygen Automatisch genereren van documentatie uit de commentaar in de code Tests junit Test-framework voor Java Tekstverwerking L A TEX Opmaak van de documenten beheren Presentaties MS Powerpoint 2007 Slides voor de presentaties maken Planning GanttProject 2.0.10 Genereren van Gantt kaarten 21

6 Technisch Proces Plans 6.4 Product acceptance plan Na iedere deadline en iteratie wordt er contact op genomen met de klant en wordt er feedback gegeven die gebruikt wordt om het project bij te sturen waar nodig. 22

7 Plannen ondersteunende processen 7 Plannen ondersteunende processen 7.1 Configuration management plan 7.1.1 Organisatie Om de organisatie van het configuration management vlot te te laten verlopen wordt er een persoon uit de groep aangesteld tot configuration manager. 7.1.2 Verantwoordelijkheden Configuration Management Het is de verantwoordelijkheid van de Configuration Manager (CM) om het team op de hoogte te houden van de status van de repository. Het zal ook hij zijn die nieuwe branches aanmaakt of wanneer anderen branches willen aanmaken, moeten zij dit eerst aanvragen aan hem. Het is wel aangewezen dat de CM eerst de groep informeert alvorens veranderingen door te voeren. Als de CM zijn taak om de een of andere reden niet kan vervullen, is er een backup CM aangeduid die dan op dat moment kan inspringen. Teamleden Het is belangrijk dat de andere teamleden (tevens gebruikers van de repository) de regels en richtlijnen i.v.m. het gebruik van de repository opgelegd door de CM strikt volgen. Met een heel team aan eenzelfde repository werken is immers zeer gevaarlijk en dergelijke repository kan makkelijk kappot gemaakt worden. 7.1.3 Regels, Richtlijnen en Procedures Om de versies van onze CI s te controleren zullen wij gebruik maken van het systeem GIT. Elk teamlid moet GIT installeren indien hij/zij dit nog niet heeft en moet op z n minst de basisfunctionaliteiten er van onder de knie hebben. Indien dit niet lukt kan hij/zij altijd uitleg vragen aan de CM. Alle versies van de CI s worden behouden. Enkel de teamleden mogen de CI s aanpassen. Teamleden mogen enkel de repository pushen en pullen. Indien er een rollback of reset nodig is, wordt dit gedaan door de CM. Bij het maken van een commit moeten altijd duidelijke messages gebruikt worden zodat indien men ooit wil terugkeren naar een vorige versie, het zeer duidelijk is naar welke commit we terug moeten. 7.1.4 SCM Activiteiten Identificeren van Configuration Items Er zal één grote repository beschikbaar zijn die onderverdeeld is in een map voor de documenten en een voor de code. Het identificeren van nieuwe CI s is de verantwoordelijkheid van de Implementation Manager. Als leden nieuwe CI s willen toevoegen moeten zij dit eerst aanvragen aan hem/haar. Indien hij/zij niet aanwezig is kan de Project Manager hier ook toestemming tot geven. 23

7 Plannen ondersteunende processen Documenten Er zal voor elk document een branch aanwezig zijn, wanneer iemand aan een document wenst te werken dient hij eerst in te checken in deze welbepaalde branch. Per document is er een aparte folder en per documenten folder zijn er folders voor elke versie van dat document. Als er een nieuwe versie gemaakt wordt van het document dan moet er een nieuwe folder aangemaakt worden met de naam van deze folder en de laatste versie moet hierin gekopieerd worden. 7.1.5 Configuratie controle Wijzigingen Aanvragen Elk teamlid is toegestaan om zijn eigen code aan te passen zolang dit geen wijziging in het design teweeg brengt. Wanneer iemand een verandering wil doen in het design moet dit eerst besproken worden met de Design Manager. Een teamlid mag ook code aanpassen van iemand anders, maar dan moet hij/zij hiervoor eerst toestemming vragen aan diegene die de code geschreven heeft. 7.1.6 Configuratie verificatie en verslag De CM bekijkt minstens een keer om de twee weken de repositories en brengt indien nodig hierover verslag op de vergadering. 7.1.7 SCM middelen Een GIT repository op de Wilma server onder de gekregen naam van onze groep Er kan altijd gebruik gemaakt worden van een grafische interface voor GIT zoals Smart- Git, maar de basis vereiste is dat iedereen de standaard GIT gebruikt. 24

7 Plannen ondersteunende processen 7.2 Verification and validation plan De verificatie en validatie van het project gebeurd op basis van de software inspecties die besproken worden in sectie 7.3.5. 7.3 Quality Assurance Plan 7.3.1 Organisatie Een teamlid wordt aangesteld om Quality Assurance Manager te zijn. 7.3.2 Verantwoordelijkheid Het is de taak van de Quality Assurance Manager om ervoor te zorgen dat de kwaliteitseisen nageleefd worden door de andere teamleden. Dit wordt gedaan door o.a. inspecties te organiseren en de documenten en code nakijken. 7.3.3 Vereiste documentatie Voor dit project moeten er een aantal documenten geschreven worden: SPMP: Software Project Management Plan SRS: Software Requirements Specifications STD: Software Test Plan SDD: Software Design Document Het Software Quality Assurance Plan (SQAP) en Software Configuration Management Plan (SCMP) moeten dit jaar niet als individueel document afgeleverd worden, in plaats daarvan worden ze in het SPMP toegevoegd onder de secties Quality Assurance Plan en Configuration Management Plan. Ook de verslagen van de vergaderingen moeten bijgehouden worden. De documentatie in de Java broncode zal waarschijnlijk gegenereerd worden in Doxygen en is ook noodzakkelijk voor dit project. 7.3.4 Standaarden, conventies en metrieken Standaarden De standaard die gedurende dit project gehanteerd zal worden is gebaseerd op de IEEEstandaard. Dit werd gekozen omdat het een klein project is tegenover degenen waarvoor de IEEE-standaard gebruikt wordt en het dus af te raden is om de volledige standaard te volgen. Dus zullen er uit de IEEE-standaard de onderdelen gekozen worden die nuttig zijn voor dit project. Conventies De codeconventies zullen dezelfde zijn als die van de Code Conventions for Java Programming Language. Metrieken De metrieken die in dit project gehanteerd zullen worden zijn de volgende: het aantal uren gespendeerd aan het project aantal lijnen code in KLOC (Kilo Line Of Code, dus 1000 lijntjes code) 25

7 Plannen ondersteunende processen 7.3.5 Software inspecties Doel Inspecties hebben voor doel om de programmeurs aan te zetten om tijdens het ontwikkelen van de software meer op de kwaliteit van de programma te letten. Inspecties gaan geörganiseerd worden bij ieder document zodat we kunnen nazien of ze aan de kwaliteitseisen voldoen. Hoe zal een inspectie verlopen? Een inspectie zal meestal hetzelfde patroon volgen namelijk: 1. Een inspectie wordt gepland wanneer het in te dienen document af is 2. Ieder lid bereidt zich voor door het document te overlopen om te zien of hij opmerkingen heeft of fouten vindt 3. Tijdens het vergadering worden er mogelijke oplossingen/verbeteringen gezocht 4. Na de vergadering zullen de gewenste aanpassingen gedaan worden 5. De aanpassingen worden gevolgd door de groep om te zien of het aangepast wordt zoals het besproken werd Geplande inspecties Software specificatie inspectie: Alle requirements zullen overlopen worden om te zien of er geen opmerkingen zijn. Architectuur specificatie inspectie: De mogelijke architecturen gaan gedurende deze inspectie overgelopen worden. Deze gaat gebeuren wanneer de SDD beschikbaar is. Gedetailleerde design inspectie: Er zal nagekeken worden of de gekozen architectuur aan de requirements voldoet. Functionele inspectie: De bedoeling is dat gedurende deze inspectie de ingediende documenten nagekeken worden of ze aan de eisen van de SRS nog voldoen. Wordt gehouden voor het indienen van de code. Fysieke inspectie: De kwaliteiteisen van het project worden nagekeken. De code en de documentatie zullen overlopen worden om te zien dat alles in orde is. Deze inspectie heeft eveneens plaats voor het indienen van de code. In-process inspectie: Deze inspectie dient om na te gaan of het project nog consistent is. Volgt de code de design documenten nog? Zijn de design document en de testen nog consistent? Post-implementatie inspectie: Inspectie die gehouden wordt na iedere iteratie. Zo kunnen er eventueel opmerkingen over de vorige iteratie of suggesties aangebracht worden voor de volgende iteratie. Planning In tabel 11 wordt een overzicht gegeven van de data waarop de geplande testen zullen doorgaan. 26

7 Plannen ondersteunende processen Tabel 11: Overzicht van de de geplande inspecties Inspectie Datum Software specificatie inspectie 17/11/2011 Architectuur specificatie inspectie 17/11/2011 Gedetailleerde design inspectie 13/02/2012 Week 12 Week 22 Functionele inspectie Week 28 Week 32 Week 12 Week 22 Fysieke inspectie Week 28 Week 32 Week 21 In-process inspectie Week 24 Week 28 Week 12 Week 22 Post-implementatie inspectie Week 28 Week 32 7.3.6 Testen Het testen gaat gedaan worden door unit tests te schrijven. Dit gaat gebeuren aan de hand van de JUnit framework. 7.3.7 Problemen rapporteren en verbeteren Documentatie Voor problemen met de documentatie zoals typefouten mag elk lid zelf de fout verbeteren. Indien er een probleem is met een stuk van een document (vb. een onderdeel die niet in het document staat) gaat het gerapporteerd worden aan de persoon die verantwoordelijk is voor het document. Code Er werd nog niets beslist voor het rapporteren van bugs in de broncode. 7.3.8 Code controle De Quality Manager gaat nakijken of de kwaliteitseisen gevolgd worden of niet. Indien niet zal hij de persoon in kwestie er attent maken en opvolgen. 27

8 Aanvullende plannen 8 Aanvullende plannen 28