Software Project Management Plan

Transcriptie

1 Software Project Management Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 4

2 Versie geschiedenis: Versienummer Datum Auteur Versie 1 05/11/2014 Jens Nevens Versie 2 19/11/2014 Jens Nevens Versie 3 15/12/2015 Jens Nevens Versie 4 03/03/2015 Jens Nevens

3 Contents 1 Overzicht Samenvatting project Doel, scope en objectieven Aannames en beperkingen Deliverables Samenvatting planning Evolutie van SPMP Referenties 3 3 Definities 4 4 Organisatie project Externe interfaces Interne interfaces Rollen Management plannen Start-up plan Personeelsplan Verwerving van middelen Werkplan Activiteiten en planning Middelen Controle plan Requirements controle Planning controle Kwaliteitscontrole Rapportering Risico management plan Technische plannen Software proces Methoden, tools en technieken Ondersteunende plannen Software Configuration Management Plan Doel Communicatie Version control Documentatie Kwaliteit Bibliotheken Testplan Documentatieplan

4 7.4 Kwaliteitsplan Problemen

5 1 Overzicht 1.1 Samenvatting project Doel, scope en objectieven Het doel van dit project is het ontwerpen en implementeren van een webapplicatie die het toelaat om wetenschappelijke publicaties te beheren en te raadplegen. Deze zal nuttig zijn voor studenten en doctoraat-studenten om informatie over hun onderwerp naar keuze te kunnen raadplegen. We noemen dit systeem PEN, wat een afkorting is voor Paper Exchange Network. Het moet mogelijk zijn om publicaties up te loaden op verschillende manieren, nl. via het invullen van een formulier, via het uploaden van een BibTex bestand of via extractie van de nodige gegevens uit een PDF-bestand. Ook moet het mogelijk zijn je eigen publicaties te verwijderen. De applicatie kent aan elke publicatie een score toe. Publicaties moeten kunnen worden opgezocht, niet enkel op dit systeem, maar ook gebruikmakende van gelijkaardige systemen zoals bijvoorbeeld Google Scholar, Mendeley,... Het systeem stelt bepaalde papers voor aan een gebruiker a.d.h.v. verzamelde informatie omtrent deze gebruiker. Er kan een sociaal netwerk worden opgebouwd met de papers en gebruikers. Gebruikers kunnen tags en commentaar toevoegen aan papers alsook statistieken consulteren. Tot slot biedt deze applicatie ook ondersteuning voor een mobiele webbrowser. Voor een uitgebreid overzicht van de vereisten wordt verwezen naar het SRS. Alle broncode is beschikbaar op GitHub, de documenten zijn terug te vinden op Dropbox en de vooruitgang is de vinden op de Trello Boards. Dit project behoort tot het vak Software Engineering gegeven aan de Vrije Universiteit Brussel Aannames en beperkingen Er gelden de volgende aannames en beperkingen onderverdeeld in verschillende categorieën: Documentatie De opgeleverde documenten volgen de standaard gedefinieerd door IEEE. Alle documenten moeten in het Engels of Nederlands geschreven worden. Alle documenten moeten beschikbaar worden gesteld in PDF-formaat. Alle vergaderingen moeten gedocumenteerd worden. 1

6 Programmeertaal Enkel JavaScript, HTML5, CSS en SQL mogen gebruikt worden. Er moet gebruik gemaakt worden van een testing framework. Bijkomende frameworks of bibliotheken moeten open-source en vrij beschikbaar zijn. Het gebruik van een bepaald framework moet gemotiveerd worden. Infrastructuur Andere De applicatie moet werken met Wilma als backend en een moderne browser als frontend. De mobiele versie van de applicatie moet werken op een Android toestel. GitHub moet gebruikt worden als repository. Het systeem moet eenvoudig te installeren zijn. De grafische interface moet simpel en aantrekkelijk zijn. Alle documenten moeten online beschikbaar zijn. De code moet duidelijk gedocumenteerd zijn. Het software proces moet iteratief en incrementeel zijn. De deadlines zijn: 15/12/2014: Eerste iteratie 03/03/2015: Tweede iteratie 20/04/2015: Derde iteratie 15/05/2015: Vierde iteratie Deliverables De volgende documenten en artefacten zullen steeds onderhouden worden: Software Project Management Plan (SPMP) Software Test Plan (STP) Software Requirements Specification (SRS) Software Design Document (SDD) Meeting minutes van alle meetings Source code Unit tests Op vaste deadlines worden bovenstaande documenten opgeleverd. Een overzicht van deze deadlines is te vinden in sectie Deze documenten zijn ook te vinden in de Dropbox folder van de groep en er wordt naar verwezen op de portaalsite. 2

7 1.1.4 Samenvatting planning Datum Activiteit 15/11/2014 Inleveren SPMP 19/11/2014 Inleveren eerste versie documenten 15/12/2014 Einde iteratie 1: opleveren documenten en code 19/12/2014 Presentatie iteratie 1 03/03/2015 Einde iteratie 2: opleveren documenten en code 11/03/2015 Presentatie iteratie 2 20/04/2015 Einde iteratie 3: opleveren documenten en code 22/04/2015 Presentatie iteratie 3 15/05/2015 Einde iteratie 4: opleveren documenten en code 20/05/2015 Presentatie iteratie Evolutie van SPMP Alle veranderingen in het SPMP worden besproken met het hele team. Een meerderheid van het team moet akkoord gaan met deze veranderingen alvorens ze worden doorgevoerd. Alle veranderingen dienen gedocumenteerd te worden om het SPMP up-to-date te houden. Dit is de verantwoordelijkheid van de Project Manager. Bij elke iteratie zal er ook een nieuwe versie van het SPMP verschijnen, het versienummer wordt aangeduid onder de titel. 2 Referenties GitHub Trello board Dropbox folder ShareLaTeX Wilma portaalsite CodeClimate Travis CI Slack jquery JSHint Mocha JSDoc Grunt Bootstrap Express Jade se1 1415/PEN.html

8 3 Definities SPMP STP SRS SDD PM RM DBM SM DM Web CM QA TM Software Process Management Plan Software Test Plan Software Requirement Specification Software Design Document Project Manager Requirement Manager Database Manager Server Manager Design Manager Webmaster Configuration Manager Qualtiy Assurance Test Manager 4 Organisatie project 4.1 Externe interfaces Er wordt geen gebruik gemaakt van externe personen, organisaties,... in verband met het ontwerp en implementatie van het systeem. Wel is het mogelijk om te overleggen met de klant, in dit geval dr. Ragnhild Van Der Straeten en Mr. Jens Nicolay. Vragen in verband met de infrastructuur (nl. Wilma) kunnen gericht worden aan Mr. Dirk Van Deun. 4.2 Interne interfaces Het hele project wordt ontworpen en geïmplementeerd door Jens Nevens, Sander Lenaerts, Nassim Versbraegen, Jo De Neve en Jasper Bevernage. Communicatie gebeurde voordien via de mailinglijst die voorzien werd via het Wilma systeem, nl. se1-1415@wilma.vub.ac.be. Het team heeft unaniem besloten om over te schakelen op Slack. De communicatie via een mailinglijst verliep moeizaam en te traag. Het hele team wou een ervaring waarbij er sneller gecommuniceerd kan worden en waarbij alle informatie op 1 locatie te vinden is. Andere tools die gebruikt worden voor communicatie zijn Trello boards en de GitHub issue tracker. Deze beide tools werden in Slack geïntegreerd, zodanig dat alle informatie op 1 enkele plaats te vinden is. 4

9 4.3 Rollen In ons team heeft ieder teamlid één of meerdere rollen. De activiteiten van elke rol zijn als volgt gedefinieerd: 1. Project Manager: Schrijven van SPMP. Coördinatie van het team. Contactpersoon voor teamleden. Bevestigen van beslissingen. Verzekeren dat deadlines gerespecteerd worden. Up to date houden van de portaalsite Opstellen van de planning 2. Requirements Manager: Schrijven van SRS. Overleggen met klant in verband met vereisten. Rapporteert eventuele veranderingen in de vereisten. Bepaald de prioriteiten voor elke taak. Verzekeren dat het ontwikkelde product overeenstemt met de vereisten van de klant. 3. DB Manager: Ontwerpen en onderhouden van de database. Andere teamleden informeren over de layout van de database. 4. Design Manager: Schrijven van SDD. Ontwerpt de architectuur voor het systeem. Eventueel overleg met de klant in verband met het ontwerp van het systeem. 5. Configuration Manager: Beheert de GitHub repository. Beheert de tools gebruikt door het team. Zorgt ervoor dat alle afgewerkte documenten op Dropbox geplaatst worden Verschaft uitleg in verband met Git en tools indien nodig 6. Quality Assurance: Nakijken van source code. Nakijken van documenten. Verzekeren van kwaliteit documenten. Verzekeren dat het ontwikkelde product overeenstemt met de vereisten van de klant. 5

10 7. Test Manager: Schrijven van STP. Beheert alle testcode. Zorgt ervoor dat de tests het hele systeem dekken. Melden van bugs Voert regressietests uit 5 Management plannen 5.1 Start-up plan Personeelsplan Ieder teamlid krijgt een rol toegewezen. Bovendien is er voor iedere rol ook een back-up voorzien, in geval van ziekte, afwezigheid,.... R = rol, B = back-up rol. Rol Jens Sander Nassim Jo Jasper Project Manager R B Requirement Manager R B Database Manager B R Design Manager B R Configuration Manager R B Quality Assurance B R R Test Manager B R Ieder teamlid is bovendien ook lid van het implementatie-team, dus het schrijven van de code en unit tests gebeurd door alle leden van het team Verwerving van middelen Alle middelen voor dit project zijn reeds aanwezig. De database, mailing lijst en server worden aangeboden door de Vrije Universiteit Brussel onder de vorm van de Wilma-infrastructuur. Alle andere middelen (vb. GitHub, ShareLaTeX, Trello,... ) zijn gratis en beschikbaar via een web-interface of vrij te downloaden. Aangezien het eindproduct een webapplicatie is, zal deze beschikbaar zijn op eender welke computer, alsook op eender welk type smartphone met internettoegang. 6

11 5.2 Werkplan Activiteiten en planning In de eerste tabel onder deze paragraaf staat de planning tot en met de eerstvolgende deadline. Aangezien deze iteratie vrij kort is, namelijk een periode van 4 weken, hebben we besloten om in deze iteratie maar 1 sprint in te bouwen. Dit is conform met het software proces dat we gebruiken in dit project. Meer info hierover in sectie 6.1. In de volgende tabel staat het werkschema van ieder teamlid. Dit duidt aan hoeveel tijd er door elk teamlid aan een bepaalde taak is gewerkt. Sprint 1: van 02/02/2015 t.e.m. 01/03/2015 Week Verantwoordelijke Activiteiten Week 1 Hele team Verfijnen code vorige iteratie Week 1-2 Hele team Aanmaken van Account pagina (pagina waarop gebruiker zijn eigen informatie en papers kan zien). DBM Verder uitbreiden database. Hele team Aanmaken van Paper pagina (pagina waarop een paper in detail kan bekeken worden). Week 3 Hele team Gebruiker kan gegevens aanpassen en Hele team papers verwijderen. Website in meerdere talen beschikbaar maken. Week 4 Hele team Papers opzoeken in de eigen database. Hele team Papers opzoeken in externe systemen. 7

12 Werkschema: Persoon Aantal uren Activiteit Jens 3h Code van vorige iteratie verfijnen 9h Account pagina aanmaken 6h Gebruiker kan gegevens aanpassen 5h Papers opzoeken in eigen database 1h SPMP updaten Sander 4h30 Kijken naar auteurs/co-auteurs bij uploaden 5h Gebruiker kan gegevens aanpassen 2h Updaten van database (keywords) 13h Accounts linken aan auteurs/co-auteurs Nassim 3h Registreren: kiezen uit lijst van departementen 5h Publicatie pagina aanmaken 2h Paper uploaden via Bibtex 1h Verslag meeting uitschrijven 3h SDD updaten Jo 2h Uitbreiden testcode 4h Verwijderen van paper 3h SRS updaten 1h Papers opzoeken in externe systemen Jasper 4h Papers opzoeken in externe systemen 3h Website in meerdere talen beschikbaar maken 2h STD updaten Middelen Onderstaande middelen zullen gebruikt worden in dit project: Wilma server GitHub repository Trello board ShareLaTeX project Dropbox folder Slack MS Powerpoint Android smartphone 8

13 5.3 Controle plan Requirements controle De vereisten kunnen gevonden worden in het SRS, alsook op het Trello board. Op het Trello board zijn de vereisten onderverdeeld in 3 groepen, nl. to-do, busy en done. Veranderingen in de vereisten moeten altijd uitvoering besproken worden tussen de RM en de klant. Deze bespreking is nodig om te bepalen of de wensen van de klant wel haalbaar zijn. Het is dan de taak van de RM om de genomen beslissingen te communiceren naar de rest van het team. Het is de taak van de QA en RM om erop toe te zien dat alle vereisten daadwerkelijk en op een correcte wijze geïmplementeerd worden Planning controle We maken telkens een ruwe schets van een sprint tot aan de volgende deadline. Deze eisen proberen we te vervolledigen en meer in detail uit te werken. Het uitbreiden en aanpassen van de planning is een verantwoordelijkheid van de PM, net zoals erop toezien dat ieder teamlid zijn deadline respecteert. Tijdens de wekelijkse vergaderingen krijgt elk teamlid één of meerdere to-do s toegewezen. Het is de bedoeling dat deze opdracht tegen de volgende vergadering volledig is afgewerkt. Elke vergadering wordt de vooruitgang van elk teamlid besproken. Indien de opdracht niet lukt of niet tijdig kan worden afgerond, krijgt dat teamlid extra hulp van de andere teamleden Kwaliteitscontrole Ieder teamlid is verantwoordelijk voor het controleren van de kwaliteit van zijn eigen code en voor het schrijven van testcode. Voor de kwaliteitscontrole kunnen we gebruik maken van verschillende tools, zoals CodeClimate en Travis CI. Deze tools zijn geïntegreerd met de GitHub repository, maar zijn natuurlijk niet de enige middelen om kwaliteit te verzekeren. Manuele controle is nog steeds nodig. Een teamlid kan ook altijd om peer-evaluatie vragen. In dat geval zal een ander teamlid de code nakijken en de testcode uitvoeren. De QA is verantwoordelijk voor de kwaliteit van de totale applicatie en voor de documenten. Samen met de RM kan de QA ook nagaan of de applicatie wel voldoet aan de vereisten van de klant. Indien een gebrek gevonden wordt in de code, kan dit gerapporteerd worden op de GitHub issue tracker en/of op Slack. In de laatste week voor de deadline is het belangrijk dat er nog een grondige controle gebeurt van alle code en functionaliteiten zodat deze, waar nodig, nog aangepast kan worden. 9

14 5.3.4 Rapportering In sectie staan de op te leveren documenten beschreven. Deze documenten zijn vrij beschikbaar op de Dropbox folder van het project. Bij elke deadline worden alle documenten, samen met de source code en de test-cases per mail afgeleverd in een zip-file. Dit archief krijgt als naam se1-iterm, waarbij M het nummer van de iteratie is. De mail bevat ook een kort overzicht van alle opgeleverde documenten. Na elke deadline volgt een presentatie. Twee leden van de groep zijn telkens verantwoordelijk voor het presenteren van de gemaakte vooruitgang. Er wordt een korte demo gegeven van de toegevoegde functionaliteit. Hierbij wordt de link gelegd met de vereisten. Ook worden de resultaten van de testcode gedemonstreerd. Vervolgens wordt de tijd dat elk teamlid aan een taak besteed heeft besproken alsook hoe dit geoptimaliseerd kan worden. Ten slotte wordt er vooruitgeblikt op de volgende iteratie. Zoals eerder vermeld, krijgt elk teamlid tijdens elke vergadering één of meerdere to-do s toegewezen. Deze zullen altijd aangeduid worden op de Trello boards. Het is de verantwoordelijkheid van de pennemeester (diegene die een verslag maakt van de vergadering) om de to-do s op het Trello board aan te brengen. Indien een taak vervolledigd is, dan kan de persoon aan die de taak is toegewezen deze verwijderen van de Trello boards. 5.4 Risico management plan We hebben de volgende risico s gedentificeerd: 1. Onvoldoende kennis programmeertaal/tools Waarschijnlijkheid: Hoog Gemiddeld Impact: Hoog Beschrijving: Geen enkel teamlid heeft ervaring met programmeren in JavaScript of Node. Geen enkel teamlid heeft ervaring met het ontwerpen van een webapplicatie. Alleen Jens heeft ervaring met HTML, CSS en Git. Andere teamleden hebben weinig ervaring met Git. Oplossing: Er wordt verwacht van alle teamleden dat ze zo snel mogelijk een basiskennis JavaScript, HTML en CSS vergaren. 10

15 2. Falen van de server Waarschijnlijkheid: Laag Impact: Hoog Beschrijving: Aangezien de server door een derde partij (nl. de Vrije Universiteit Brussel) beheerd wordt, heeft ons team geen impact op het al dan niet falen van de server. Desalniettemin kan dit een grote inpact hebben op het project. Oplossing: Bij falen van de Wilma-server, zo snel mogelijk Mr. Dirk Van Deun contacteren. CM kan zoeken naar een nieuwe server. 3. Falen van een tool (vb. GitHub, ShareLaTeX, Trello) Waarschijnlijkheid: Laag Impact: Hoog Beschrijving: Indien een tool faalt, zou de informatie verloren kunnen gaan. In het geval van GitHub zou de code verloren gaan, in het geval van ShareLaTeX zouden de documenten verloren gaan. Oplossing: Indien een document is afgewerkt, wordt er steeds een back-up gemaakt van het document. Dit kan op een computer van een teamlid zijn, op Dropbox of op beiden. 4. Meningsverschil Waarschijnlijkheid: Gemiddeld Impact: Gemiddeld Beschrijving: Een meningsverschil tussen teamleden kan worden opgedeeld in 2 gevallen. Ofwel gaat het meningsverschil over het project, ofwel is het een persoonlijk meningsverschil. Ook is het mogelijk dat een teamlid slecht of zelfs niet communiceert. Oplossing: Indien het meningsverschil gaat over het project, beslist de meerderheid van het team. Indien het gaat om een persoonlijk meningsverschil, wordt er naar een oplossing gezocht samen met de andere teamleden. Indien een teamlid niet communiceert, wordt dit aangehaald door de andere teamleden. Als de situatie niet veranderd, kan dr. R. Van Der Straeten gecontacteerd worden. 5. Wegvallen van een teamlid Waarschijnlijkheid: Laag Impact: Hoog Beschrijving: Hiermee wordt het permanent wegvallen van een teamlid bedoeld. Een teamlid kan ziek worden of niet meer willen meewerken aan het project. Oplossing: Teamlid met back-up rol neemt over. 11

16 6. Niet halen van de deadline Waarschijnlijkheid: Gemiddeld Impact: Hoog Beschrijving: Het implementeren van een bepaalde functionaliteit of het schrijven van een document kan langer duren dan verwacht. Oplossing: Goed bijhouden van alle vooruitgang. Gedeeltelijke vooruitgang proberen te demonstreren. Eigen deadlines vastleggen die eerder zijn dan de werkelijke deadlines. 7. Foute interpretatie van vereisten Waarschijnlijkheid: Laag Impact: Gemiddeld Beschrijving: Het team kan een bepaalde vereiste anders interpreteren dan wat er eigenlijk verwacht wordt van de klant. Oplossing: Overleggen met de klant en proberen om de vereiste correct te implementeren. 8. Plotse verandering in vereisten Waarschijnlijkheid: Laag Impact: Gemiddeld Beschrijving: Het is mogelijk dat de klant zich tijdens de ontwikkeling van het project bedenkt en een andere functionaliteit wil. Oplossing: Overleggen met de klant en proberen een compromis te sluiten over de nieuwe vereiste. 9. Slecht inschatten hoe lang een taak zal duren Waarschijnlijkheid: Gemiddeld Impact: Gemiddeld Beschrijving: Vanwege een gebrek aan ervaring kan het voor de teamleden moeilijk zijn om in te schatten hoe lang een bepaalde taak zal duren. Oplossing: Gedurende het hele project, vooral in het begin, bijhouden hoelang elke taak geduurd heeft, om op deze manier ervaring te krijgen in het inschatten. 10. Onvoldoende domeinkennis Waarschijnlijkheid: Gemiddeld Impact: Gemiddeld Beschrijving: De teamleden zijn 3e Bachelorstudenten en hebben bijgevolg nog geen ervaring in het schrijven van een academische paper. Oplossing: Informatie omtrent academische papers vergaren bij master-studenten, assistenten en professoren aan de Vrije Universiteit Brussel. 12

17 6 Technische plannen 6.1 Software proces Het software proces dat we gaan gebruiken is iteratief en incrementeel. We hebben besloten om een variatie op de SCRUM-methode toe te passen. In de SCRUM-methode zijn er sprints van korte duur, die gebruikt worden om een bepaalde functionaliteit te implementeren, en dagelijkse vergaderingen. Wij hebben besloten om ook gebruik te maken van sprints. Elke periode die hoort bij een bepaalde iteratie kan opgedeeld worden in sprints. Elke sprint krijgt een bepaald doel dat bereikt moet zijn tegen het einde van de sprint. In plaats van dagelijkse vergaderingen te houden hebben we besloten om wekelijkse vergaderingen te houden. Net zoals in de SCRUM-methode bespreken we in elke vergadering de volgende 3 punten: 1. Wat is er veranderd sinds de vorige vergadering? 2. Welke moeilijkheden ben je hierbij tegengekomen? 3. Wat ga je doen tegen de volgende vergadering? We hebben gekozen voor dit model omdat de agenda van het project ons verplicht om iteratief te werken en omdat iedereen het makkelijker en logischer vindt om incrementeel te werken. 6.2 Methoden, tools en technieken De gebruikte tools, methoden en technieken worden besproken in het SCMP. 7 Ondersteunende plannen 7.1 Software Configuration Management Plan Doel Het doel van het Software Configuration Management Plan is het definiëren van de gebruikte tools en technieken in dit project. Deze tools zullen gebruikt worden voor communicatie, version control, documentatie, kwaliteitscontrole en het ontwikkelen van de software. 13

18 7.1.2 Communicatie De volgende tools zullen gebruikt worden voor communicatie: Slack: Slack is een communicatieplatform voor teams. De communicatie kan worden opgedeeld in verschillende kanalen (één kanaal per onderwerp) en er kan ook priv worden overlegd tussen de verschillende teamleden. Slack laat het ook toe om vele andere diensten te integreren, zoals bijvoorbeeld GitHub, Trello, Dropbox, CodeClimate,... We hebben gekozen voor Slack omdat het ons toelaat om gemakkelijk en snel met elkaar te kunnen communiceren. Het zorgt er ook voor dat alle nodige informatie beschikbaar is op 1 enkele plaats, wat het zeer makkelijk maakt om meteen up-to-date te zijn met de laatste veranderingen. Elk teamlid mag berichten plaatsen op Slack. Trello: Trello is een website waarbij er verschillende boards aangemaakt kunnen worden. Een Trello board kan meerdere lijsten bevatten en elke lijst bevat meerdere items. De items kunnen van lijst veranderen, toegekend worden aan een teamlid, uitvoerig besproken worden,... We hebben gekozen om Trello te gebruiken om een overzicht te krijgen over de wekelijkse to-do s en van de vereisten. Het to-do board bevat 4 lijsten: to-do, busy, under revision en done. Zoals eerder besproken krijgt elk teamlid één of meerdere to-do s per week. Het is de verantwoordelijkheid van de pennemeester om deze op het Trello board te plaatsen en toe te kennen aan het juiste teamlid. Ieder teamlid mag een zijn taken verplaatsen tussen de verschillende lijsten. Het requirements board bevat 3 lijsten: to-do, busy en done. Op dit board worden de vereisten bijgehouden en de vooruitgang ervan opgevolgd. 14

19 7.1.3 Version control De volgende tools zullen gebruikt worden voor version control: GitHub: GitHub is een versioning systeem. Het laat een team toe om gezamelijk aan dezelfde code te werken. Het gebruiken van GitHub is een vereiste voor dit project. Om het overzicht te bewaren, hebben we de volgende conventies afgesproken: De GitHub repository heeft 2 vaste branches: master en develop. De master branch wordt gebruikt om release-klare versies van het systeem op te zetten. De develop branch wordt gebruikt voor de actieve ontwikkeling van het systeem. Telkens er een nieuwe vereiste geïmplementeerd moet worden, kan een feature branch gemaakt worden. Zo n branch stamt af van de develop branch. Indien een vereiste volledig geïmplementeerd en getest is, kan deze terug samenvloeien met de develop branch. Het is dan de taak van de TM om te testen of het systeem in het geheel nog wel werkt. Dit gebeurt door de integratietests. Ieder teamlid mag nieuwe feature branches aanmaken. Na het slagen van alle testen en bevestiging van de TM, mag ieder teamlid ook een feature branch doen samenvloeien met de develop branch. Indien de integratietesten en regressietesten slagen, mag de inhoud van de develop branch worden overgezet naar de master branch. Dit is de verantwoordelijkheid van de CM. Deze wordt bijgestaan door de PM. Dropbox: Dropbox is een file hosting service. Alle soorten documenten kunnen in de cloud opgeslagen worden en alle leden van het team hebben hier toegang toe. We hebben gekozen voor Dropbox omdat ieder teamlid hier al een account op heeft en ervaring mee heeft. We hebben een gemeenschappelijke Dropbox folder met de volgende structuur: Documenten: deze map bevat alle afgewerkte documenten die opgeleverd moeten worden. Meetings: deze map bevat alle verslagen van de vergaderingen. UML: deze map bevat UML diagrammen Dropbox wordt in eerste instantie gebruikt om een back-up te maken van alle afgewerkte documenten. Het is de verantwoordelijkheid van de auteur van een document om het afgewerkte documenten in PDF-formaat op te slaan in de juiste map. 15

20 7.1.4 Documentatie De volgende tools zullen gebruikt worden voor documentatie: ShareLaTeX: ShareLaTeX is een website waarbij er online en gezamenlijk kan gewerkt worden aan LaTeX bestanden. We hebben gekozen voor deze website omdat we van mening waren dat de documenten in LaTeX formaat het beste zouden staan en omdat we ons wilden besparen van het altijd heen en weer mailen van documenten. ShareLaTeX wordt gebruikt voor het schrijven van de documenten (nl. SPMP, SDD, SRS,... ) en verslagen over de vergaderingen. JSDoc: JSDoc is een tool die de commentaar in de code-bestanden omzet naar documentatie. We hebben gekozen voor deze tool omdat het de standaard tool is voor de JavaScript programmeertaal. Ieder teamlid is verantwoordelijk voor het commentariëren van zijn code. De CM is verantwoordelijk voor het genereren van de documentatie en deze op Dropbox te plaatsen Kwaliteit De volgende tools zullen gebruikt worden voor kwaliteitscontrole: CodeClimate: CodeClimate is een online tool die statische analyse uitvoert op software. Deze tool is geïntegreerd met GitHub. Telkens wanneer er een commit plaats vindt op GitHub, gaat deze tool de code analyseren. Deze tool doet de volgende dingen: Zoekt naar te complexe code Zoekt naar code duplicatie Zoekt naar stukken code die het meeste veranderen van plaats (de zogenaamde churn rate). Deze metrieken worden gerapporteerd en kunnen dan door ons aangepakt worden. We hebben voor deze tool gekozen omdat we op deze manier extra controle hebben. De code wordt niet alleen gecontroleerd door de leden van het team, maar ook door een externe partij. Het is de taak van de CM om de resultaten van deze analyse te rapporteren aan de programmeur in kwestie. Travis CI: Travis CI is een contiuous integration service. Het is een online tool die automatisch de code build en test. Net als CodeClimate is deze tool geïntegreerd met GitHub. Telkens wanneer er een commit plaats vindt, gaat deze tool de code builden en automatisch de testen uitvoeren. We hebben voor deze tool gekozen omdat het ons toelaat om onze testen automatisch te laten uitvoeren telkens er een nieuwe versie is van het systeem. Het is de taak van de TM om gefaalde testen te rapporteren aan de programmeur in kwestie. 16

21 GitHub Issue Tracker: De GitHub Issue Tracker is een deel van de GitHub repository. Het laat ons toe om bugs of fouten in het systeem te melden. De integratie met Slack zorgt ervoor dat deze issues ook automatisch zichtbaar zijn in Slack. Het team kan dan samen naar een oplossing zoeken voor de bug. JSHint: JSHint is een tool die, net zoals CodeClimate, statische analyse uitvoert op de JavaScript code. Ook worden er code conventions opgelegd. Deze conventions kunnen geconfigureerd worden in een jshintc bestand Bibliotheken De volgende software bibliotheken zullen gebruikt worden: jquery: jquery is een uitbreiding op JavaScript en zal ervoor zorgen dat het makkelijker is om vanuit JavaScript-code de elementen uit de HTML-pagina te selecteren, navigeren en aan te passen. Bij het laden van een HTML-pagina gaat iedereen browser een soort van boom-model opmaken van de pagina. Dit model heet de DOM en is voor iedere browser lichtjes anders. jquery zorgt voor een abstractielaag, zodat we ons niet druk hoeven te maken over dit euvel. Deze bibliotheek is enkel bestemd voor de client-side code. Mocha: Mocha is een testing framework. Het laat ons toe om zowel de client-side JavaScript als de server-side code te testen. Grunt: Grunt is een JavaScript Task Runner. Dit laat ons toe om repetitieve taken automatisch uit te voeren, zoals bijvoorbeeld het injecteren van de juiste dependencies, uitvoeren van JSHint, uitvoeren van testcode,... We hebben voor deze bibliotheek gekozen omdat dit de task runner is die we kennen. Bootstrap: Bootstrap is een CSS en JavaScript framework en laat ons toe ervoor te zorgen dat onze website er snel aantrekkelijk uitziet, zonder veel tijd te besteden aan opmaak. Het bevat allerhande elementen die oneindig aangepast kunnen worden, zoals bijvoorbeeld buttons, formulieren, layout voor afbeeldingen,... We hebben voor Bootstrap gekozen omdat deze een van de meest gebruikte CSS frameworks is. Express: Express is een node.js framework dat ons toelaat om een RESTful API te maken voor onze website. Hiermee kunnen we op een makkelijke wijze routes bepalen naar elke pagina en sessions bijhouden. Jade: Jade is een server-side templating engine. Het is een taal die qua syntax zeer sterk lijkt op HTML, maar het laat ons toe om op een simpele wijze bepaalde HTML-elementen te genereren. Dit komt omdat het gebruik kan maken van variabelen, control-flow, includen van andere files,... 17