Software Project Management Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 6
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 Versie 5 20/04/2015 Jens Nevens Versie 6 15/05/2015 Jens Nevens
Contents 1 Overzicht 1.1 Samenvatting project . . . . . . . 1.1.1 Doel, scope en objectieven 1.1.2 Aannames en beperkingen 1.1.3 Deliverables . . . . . . . . 1.1.4 Samenvatting planning . . 1.2 Evolutie van SPMP . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
1 1 1 1 2 3 3
2 Referenties
3
3 Definities
4
4 Organisatie project 4.1 Externe interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Interne interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 4 4 5
5 Management plannen 5.1 Start-up plan . . . . . . . . . . . 5.1.1 Personeelsplan . . . . . . 5.1.2 Verwerving van middelen 5.2 Werkplan . . . . . . . . . . . . . 5.2.1 Activiteiten en planning . 5.2.2 Middelen . . . . . . . . . 5.3 Controle plan . . . . . . . . . . . 5.3.1 Requirements controle . . 5.3.2 Planning controle . . . . . 5.3.3 Kwaliteitscontrole . . . . 5.3.4 Rapportering . . . . . . . 5.4 Risico management plan . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
6 6 6 6 7 7 14 15 15 15 15 16 17
6 Technische plannen 19 6.1 Software proces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2 Methoden, tools en technieken . . . . . . . . . . . . . . . . . . . 20 7 Ondersteunende plannen 7.1 Software Configuration Management Plan 7.1.1 Doel . . . . . . . . . . . . . . . . . 7.1.2 Communicatie . . . . . . . . . . . 7.1.3 Version control . . . . . . . . . . . 7.1.4 Documentatie . . . . . . . . . . . . 7.1.5 Kwaliteit . . . . . . . . . . . . . . 7.1.6 Bibliotheken . . . . . . . . . . . . 7.2 Testplan . . . . . . . . . . . . . . . . . . . 7.3 Documentatieplan . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
20 20 20 20 21 22 22 23 24 24
7.4 7.5
Kwaliteitsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25 25
1
Overzicht
1.1 1.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 Wilma en de vooruitgang is te vinden op de Trello Boards. Dit project behoort tot het vak Software Engineering gegeven aan de Vrije Universiteit Brussel. 1.1.2
Aannames en beperkingen
Er gelden de volgende aannames en beperkingen onderverdeeld in verschillende categorie¨en: • 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
• 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 – 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. • Andere – – – – – – –
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
1.1.3
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 1.1.4. Deze documenten zijn ook te vinden in de Dropbox folder van de groep en er wordt naar verwezen op de portaalsite. 2
1.1.4
Samenvatting planning
Datum 15/11/2014 19/11/2014 15/12/2014 19/12/2014 03/03/2015 11/03/2015 20/04/2015 22/04/2015 15/05/2015 20/05/2015
1.2
Activiteit Inleveren SPMP Inleveren eerste versie documenten Einde iteratie 1: opleveren documenten Presentatie iteratie 1 Einde iteratie 2: opleveren documenten Presentatie iteratie 2 Einde iteratie 3: opleveren documenten Presentatie iteratie 3 Einde iteratie 4: opleveren documenten Presentatie iteratie 4
en code en code en code en code
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
https://github.com/JensNevens/PEN https://trello.com/softwareengineering29 https://www.dropbox.com/sh/yq3eb41dgzgsdtd/AAC11LrmOoIv5shju8MEr8Ha?dl=0 https://www.sharelatex.com/project/5440e1ad33c0006f1414598f http://wilma.vub.ac.be/˜ se1 1415/PEN.html https://codeclimate.com/github/JensNevens/PEN https://travis-ci.org/JensNevens/PEN https://se1-1415.slack.com/messages/general/ http://jquery.com/ http://jshint.com/ http://mochajs.org/ http://usejsdoc.org/ http://gruntjs.com/ http://getbootstrap.com/ http://expressjs.com/ http://jade-lang.org:
3
3
Definities
SPMP STP SRS SDD PM RM DBM SM DM Web CM QA TM
4 4.1
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
Organisatie project 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.
[email protected]. 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. Een andere tool die gebruikt wordt voor communicatie is het Trello board. Deze beide tools werden in Slack ge¨ıntegreerd, zodanig dat alle informatie op 1 enkele plaats te vinden is.
4
4.3
Rollen
In ons team heeft ieder teamlid ´e´en of meerdere rollen. De activiteiten van elke rol zijn als volgt gedefinieerd: 1. Project Manager: – – – – – – –
Schrijven van SPMP. Co¨ ordinatie 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
7. Test Manager: – – – – –
5 5.1 5.1.1
Schrijven van STP. Beheert alle testcode. Zorgt ervoor dat de tests het hele systeem dekken. Melden van bugs Voert regressietests uit
Management plannen 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 Project Manager Requirement Manager Database Manager Design Manager Configuration Manager Quality Assurance Test Manager
Jens R
Sander
B
R B R
B
Nassim
Jo B R
Jasper B
R B R B
R 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. 5.1.2
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
5.2 5.2.1
Werkplan Activiteiten en planning
Iteratie 1 In onderstaande tabel staat de planning tot en met de eerste deadline. Dit is een periode van 8 weken. We hebben deze periode opgedeeld in 2 sprints. Dit is conform met het software process dat we gaan gebruiken in dit project. Meer info hierover in sectie 6.1 Sprint 1 loopt van 17/10/2014 tot 14/11/2014. Dit is een periode van 4 weken. Sprint 2 loopt van 14/11/2014 tot 15/12/2014. Dit is een periode van 5 weken. Sprint 1: Project start-up Week Verantwoordelijke Week 1-2 Hele team Hele team
Week 3 Week 4
Activiteiten Zelfstudie JavaScript, HTML en CSS Opzoeken welke tools gebruikt kunnen worden. Organisatie van het team en het project. Begin opstellen van SPMP. Ontwerpen en opstellen van database. Initieel ontwerp. Opstellen requirements scenarion 1 Focus op schrijven van SPMP. Ontwerpen van scenario 1. Uitwerken/updaten van documenten. Begin implementatio scenario 1.
Hele team PM DBM DM RM PM Hele team Hele team Hele team
Sprint 2: Scenario 1 Week Verantwoordelijke Week 5 Hele team PM DM Week 6-7 Hele team Week 8 Hele team
Activiteiten Focus op uitwerken scenario 1 Update SPMP. Stijl van de website bepalen. Implementeren van scenario 1. Extra ruimte om alles extra te testen, debuggen, klaarmaken voor release. Voorbereiden presentatie.
Nog te bepalden
Deadline: 15/12/2014 Deze planning is nog onderhevig aan veranderingen wegens een gebrek aan ervaring vanwege alle teamleden. Elk teamlid vindt het moeilijk om een correcte inschatting te kunnen maken over hoe lang een bepaalde taak zal duren en hoe snel we zullen vorderen. Dit is zeker een werkpunt dat ook wordt behandeld in het Risico management plan. De planning wordt weergegeven in onderstaande Gantt chart:
7
8
Iteratie 2 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.
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 papers verwijderen. Hele team Website in meerdere talen beschikbaar maken. Week 4 Hele team Papers opzoeken in de eigen database. Hele team Papers opzoeken in externe systemen.
9
In de volgende tabel staat het werkschema van ieder teamlid. Dit duidt aan hoeveel tijd er door elk teamlid aan een bepaalde taak effectief gewerkt is. Dit omvat het schrijven van code en testen alsook het uitbreiden van de documenten. Werkschema: Persoon Aantal uren Jens 3h 9h 6h 5h 1h Sander 4h30 5h 2h 13h Nassim 3h 5h 2h 1h 3h Jo 2h 4h 3h 1h Jasper 4h 3h 2h
Activiteit Code van vorige iteratie verfijnen Account pagina aanmaken Gebruiker kan gegevens aanpassen Papers opzoeken in eigen database SPMP updaten Kijken naar auteurs/co-auteurs bij uploaden Gebruiker kan gegevens aanpassen Updaten van database (keywords) Accounts linken aan auteurs/co-auteurs Registreren: kiezen uit lijst van departementen Publicatie pagina aanmaken Paper uploaden via Bibtex Verslag meeting uitschrijven SDD updaten Uitbreiden testcode Verwijderen van paper SRS updaten Papers opzoeken in externe systemen Papers opzoeken in externe systemen Website in meerdere talen beschikbaar maken STD updaten
10
Iteratie 3 In de eerste tabel onder deze paragraaf staat de planning tot en met de eerstvolgende deadline. We hebben deze iteratie opgedeeld in 2 sprints. Dit is conform met het software proces dat we gebruiken in dit project. Meer info hierover in sectie 6.1. Sprint 1 loopt van 11/03/2015 tot 29/03/2015. Dit is een periode van 3 weken. Sprint 2 loopt van 30/03/2015 tot 20/04/2015. Dit is ook een peride van 3 weken. Sprint 1: van 10/03/2015 t.e.m. 29/03/2015 Week Verantwoordelijke Activiteiten Week 1 Hele Team Afwerken van vertaling Hele Team Meerdere input fields voor o.a. auteur, keywords, etc. DBM Refactoren van de database Week 2 DM Field of research toevoegen aan account. RM Uitbreiden van search functionaliteit PM Ratingsysteem Week 3 DM Publicaties linken aan persoon wanneer deze account aanmaakt. PM Project op Wilma installeren Sprint 2: van 30/03/2015 t.e.m. 20/04/2015 Week Verantwoordelijke Activiteiten Week 1 DM Account kan field of research aanpassen RM Advanced search Week 2 PM Bezoeken van andere accounts PM Account pagina uitbreiden RM Dashboard invullen Week 3 DMB en TM Uitbreiden van testen Hele Team Uitbreiden van documenten
11
In de volgende tabel staat het werkschema van ieder teamlid. Dit duidt aan hoeveel tijd er door elk teamlid aan een bepaalde taak effectief gewerkt is. Dit omvat het schrijven van code en testen alsook het uitbreiden van de documenten. Werkschema: Persoon Aantal uren Jens 5h
Sander
Nassim Jo
Jasper
8h30 1h 4h 1h 2h 1h 1h 8h30 1h 7h 6h30 11h 20h 3h 30h 3h 8h 1h 4h 3h 22h 10h 4h 3h
Activiteit Meerdere input fields voor o.a. auteurs, keywords, etc. Rating systeem Database testen toegevoegd Publicatie-pagina uitbreiden. Account-pagina uitbreiden Bezoeken van andere accounts Update SPMP Live demo op Wilma Account linken Link Person documenteren Database refactoren Database documenteren Link Publication Uitbreiden testen Updaten SDD Field of research Updaten SDD Advanced search Update SRS Dashboard invullen Zoekresultaten weergeven Vertaling en bugs oplossen Metadata uit PDF extraheren Uitbreiden testen Updaten STD
12
Iteratie 4 In de eerste tabel onder deze paragraaf staat de planning tot en met de eerstvolgende deadline. Aangezien dit een korte en de laatste iteratie is, hebben we 1 enkele sprint in deze iteratie ingebouwd. Dit is conform met het software proces dat we gebruiken in dit project. Meer info hierover in sectie 6.1. In deze sprint willen we ons vooral toeleggen op het opleveren van een afgewerkt product. Deze sprint loopt van 20/04/2015 tot 15/05/2015. De interne deadline is 13/05/2015. Deze sprint is een periode van 4 weken. Sprint 1: van 20/04/2015 t.e.m. 15/05/2015 Week Verantwoordelijke Activiteiten Week 1 PM Hashen van gevoelige informatie Hele team Recommender Systeem Week 2 TM, PM Commentaar geven op publicaties Hele team Recommender Systeem Week 3 DBM Visualisatie sociaal netwerk Hele team Tests uitbreiden Week 4 Hele team Gebruiksvriendelijke errors Hele team Documenten updaten In de volgende tabel staat een schatting van het werkschema. Hier proberen we in te schatten hoeveel uur het uitvoeren van een geplande taak zal duren. Dit wordt niet opgedeeld per teamlid, maar maakt een schatting voor alle betrokken teamleden samen. Activiteit Hashen van gevoelige informatie Recommender Systeem Commentaar geven op publicaties Visualisatie sociaal netwerk Tests uitbreiden Gebruiksvriendelijke errors Documenten updaten
Aantal uren 10h 35h 30h 20h 20h 5h 15h
Tot slot is er het werkschema van ieder teamlid. Dit duidt aan hoeveel tijd er door elk teamlid aan een bepaalde taak effectief gewerkt is. Dit omvat het schrijven van code en testen alsook het uitbreiden van de documenten.
13
Werkschema: Persoon Aantal uren Jens 4h 9h 6h 2h 1h 1h Sander 7h 6h 6h 3h 3h Nassim 5h 5h 1h 6h Jo 6h 3h 6h 3h Jasper 9h 9h 2h 5.2.2
Activiteit Hashen van gevoelige informatie Commentaar geven op publicaties Tests uitbreiden Bugs oplossen Aparte module voor rating systeem Update SPMP Sociaal netwerk (server side) Sociaal netwerk (client side) Sociaal netwerk verschillende diepte Vertaling, layout tweaks, URL veld verwijderen Tests uitbreiden Naam toevoegen aan proceeding Layout dashboard Bugfixes Update SDD Refactor interne search en tests Refactor parsing en tests Externe search met Mendeley API Update SRS Commentaar geven op publicaties Tests uitbreiden Update STD
Middelen
Onderstaande middelen zullen gebruikt worden in dit project: – Wilma server – GitHub repository – Trello board – ShareLaTeX project – Dropbox folder – Slack – MS Powerpoint – Android smartphone
14
5.3 5.3.1
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. 5.3.2
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 ´e´en 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. 5.3.3
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. 15
5.3.4
Rapportering
In sectie 1.1.3 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 ´e´en 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.
16
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. 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.
17
– 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. 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.
18
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.
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.
19
6.2
Methoden, tools en technieken
De gebruikte tools, methoden en technieken worden besproken in het SCMP.
7
Ondersteunende plannen
7.1 7.1.1
Software Configuration Management Plan Doel
Het doel van het Software Configuration Management Plan is het defini¨eren 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. 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 (´e´en 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 ´e´en 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
20
dit board worden de vereisten bijgehouden en de vooruitgang ervan opgevolgd. 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.
21
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¨eren van zijn code. De CM is verantwoordelijk voor het genereren van de documentatie en deze op Dropbox te plaatsen. 7.1.5
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.
22
– 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. 7.1.6
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, . . . 23
7.2
Testplan
Alle informatie in verband met testen van de software kan gevonden worden in het STD. Ieder teamlid is verantwoordelijk voor het testen van de door hem geschreven software. Nadien moet de Test Manager een overzicht hebben van alle tests en garanderen dat deze het hele systeem dekken.
7.3
Documentatieplan
De documentatie voor de code zal gegenereerd worden door middel van de JSDoc tool. Hiervoor werd de volgende conventie afgesproken: commentaar blokken beginnen met /** en eindigen met */. De parameters en return waarden kunnen aangeduid worden met @parameter en @return respectievelijk. Namen van functies en variabelen worden geschreven met camelCase. De op te leveren documenten worden geschreven in LaTeX. Dit gebeurd door middel van de ShareLaTeX website. Dit is een website waarbij alle teamleden tegelijk aan ´e´en of meerdere documenten kunnen werken. Het bespaard ons ook de moeite om steeds de meest recente documenten te moeten doormailen. Voor het schrijven van de documenten gelden er bepaalde conventies. Zo moet er altijd een voorpagina zijn, gevolgd door een versie geschiedenis en een inhoudsopgave. Dit telkens op een andere pagina. De paginanummering begint pas na de inhoudsopgave. De voorpagina heeft de volgende opmaak: – Naam van het document (bijvoorbeeld Sofware Project Management Plan) – Naam van het product (PEN) – Vermelding van de groep – Academiejaar – Alle namen van de groepsleden – Versienummer – Logo De versie geschiedenis is een tabel met de volgende opmaak: Versienummer Versie X
Datum DD/MM/YYYY
Auteur Naam
De inhoudsgave wordt automatisch gegenereerd door LaTeX.
24
7.4
Kwaliteitsplan
Er is geen apart plan aangaande de kwaliteit van de software. Extra informatie kan hiervoor gevonden worden in sectie 4.3, onder de verantwoordelijkheden voor de QA en TM en in sectie 5.3.3.
7.5
Problemen
Problemen in verband met de code en de documenten kunnen gemeld worden op de GitHub issue tracker en het ShareLaTeX project, respectivelijk. Slack kan ook altijd gebruikt worden om issues te melden, advies te geven over documenten, vragen te stellen, . . .
25
