Software Engineering Groep 4

Transcriptie

1 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 13 november

2 Tabel 1: Document geschiedenis 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

3 Inhoudsopgave Inhoudsopgave 1 Algemeen overzicht Project beschrijving Doelstellingen en bereik van het project Veronderstellingen en beperkingen Project opleveringen Planning en budget overzicht Evolutie van het SPMP Referenties 7 3 Afkortingen en definities Afkortingen Definities Project Organisatie Externe communicatie Interne structuur Rollen en verantwoordelijkheden Managerial Process plans Opstartplan Schattingsplan Personeelsplan Plan om middelen te bekomen Personeelstrainingsplan Werkplan Werkactiviteiten Vergaderingen Grafische voorstelling van de planning Resource Allocation Controleplan Requirements Control Plan Schedule Control Plan Reporting Plan Plan voor risicobeheer Gebrek aan kennis junit Gebrek aan kennis SQL Gebrek aan communicatie Gebrek aan Version Control kennis Gebrek aan kennis LaTeX Gebrek aan ervaring in groep Het ziek worden van een teamlid Gebrek aan kennis Java/Android SDK Project Closeout Plan Technisch Proces Plans Proces model Methodes, hulpmiddelen en technieken Infrastructure plan

4 Inhoudsopgave 6.4 Product acceptance plan Plannen ondersteunende processen Configuration management plan Organisatie Verantwoordelijkheden Regels, Richtlijnen en Procedures SCM Activiteiten Configuratie controle Configuratie verificatie en verslag SCM middelen Verification and validation plan Quality Assurance Plan Organisatie Verantwoordelijkheid Vereiste documentatie Standaarden, conventies en metrieken Software inspecties Testen Problemen rapporteren en verbeteren Code controle Aanvullende plannen 27 4

5 1 Algemeen overzicht 1 Algemeen overzicht 1.1 Project beschrijving 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 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 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 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

6 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 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 Assistent Project Manager verzorgt het SPMP. 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 standaard. 6

7 2 Referenties 2 Referenties Referenties [1] Groep 4. Software Design Description v [2] Groep 4. Software Engineering Groep [3] Groep 4. Software Project Management Plan v [4] Groep 4. Software Requirements Specification v [5] Groep 4. Software Test Document v [6] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Software Project Management Plans (SPMP), [7] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Software Quality Assurance Plans (SQAP), [8] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Software Configuration Management Plans (SCMP), [9] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Software and System Test Documentation (STD), [10] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Recommended Practice for Software Requirements Specifications (SRS), [11] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Information Technology Systems Design Software Design Descriptions (SDD),

8 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

9 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

10 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

11 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

12 5 Managerial Process plans 5.1 Opstartplan 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 wordt een gedetailleerde beschrijving van de verdeling van deze uren opgesteld Personeelsplan Groepsleden Voor dit project zijn er 6 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 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 Nyckees Jeroen Van den Heuvel Lorenz 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 Jeroen.Nyckees[at]vub.ac.be Lorenz.Van.Den.Heuvel[at]vub.ac.be 12

13 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 Jan-Pieter Tim Quality Manager Quentin Lorenz Requirements Manager Lorenz Jeroen Test Manager Kevin Jan-Pieter Webmaster Kevin Tim Secretaris Lorenz Jeroen 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 Java J J N N J J GIT J J J J N J junit J J J J J J 5.2 Werkplan 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 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

14 5 Managerial Process plans Tabel 7: Overzicht van de geplande vergaderingen Dag Uur Duur 24/10/ :00-12:30 1:30 28/10/ :30-13:20 0:50 04/11/ :00-13:25 0:25 07/11/ :00-14:25 1:25 14/11/ :00-15:00-21/11/ :00-15:00-28/11/ :00-15:00-05/12/ :00-15:00-12/12/ :00-15:00-19/12/ :00-15: 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 Presentatie 1 geven Presentatie 2 geven 14

15 5 Managerial Process plans Presentatie 3 geven Finale Presentatie geven Resource Allocation Voor dit project is er per groepslid 210 uren 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. 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 Nog te bepalen Opstellen van het design Nog te bepalen Implementeren van de code Nog te bepalen Testen van de code Nog te bepalen Maken van presentaties Nog te bepalen 5.3 Controleplan 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. 15

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

17 5 Managerial Process plans 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 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 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 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/ 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 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/

18 5 Managerial Process plans Gebrek aan Version Control kennis Waarschijnlijkheid 8 Impact 10 Prioriteit 100 Oplossing 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. Einddatum 05/11/ Gebrek aan kennis LaTeX Waarschijnlijkheid 2 Impact 2 Prioriteit 5 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 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 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 18

19 5 Managerial Process plans Gebrek aan kennis Java/Android SDK Waarschijnlijkheid 6 Impact 7 Prioriteit 200 Oplossing Nog niet beslist Einddatum 21/11/ 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. 19

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 9 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 9: Overzicht van de gebruikte software en hulpmiddelen Doel Applicatie Versie Beschrijving Projectbeheer Bijhouden van de gepresteerde aantal uren Versiebeheer GIT Gecontroleerd samen werken IDE Eclipe Programmeeromgeving Android SDK Android SDK 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 webiste 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 Genereren van Gantt kaarten 20

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. 21

22 7 Plannen ondersteunende processen 7 Plannen ondersteunende processen 7.1 Configuration management plan Organisatie Om de organisatie van het configuration management vlot te te laten verlopen wordt er een persoon uit de groep aangesteld tot configuration manager 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 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 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. 22