Software Project Management Plan PEN: Paper Exchange Network Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1
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 Schatting . . . . . . . . . 5.1.2 Personeelsplan . . . . . . 5.1.3 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 6 7 7 7 8 8 8 8 8 9
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
6 Technische plannen 10 6.1 Software proces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Methoden, tools en technieken . . . . . . . . . . . . . . . . . . . 10 7 Ondersteunende plannen 7.1 Configuration management plan . 7.2 Testplan . . . . . . . . . . . . . . 7.3 Documentatieplan . . . . . . . . 7.4 Kwaliteitsplan . . . . . . . . . . 7.5 Problemen . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
11 11 11 11 11 12
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 raad te plegen. Dit zal nuttig zijn voor studenten en doctoraat-studenten die zich bezig houden met onderzoek 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 en deze ook 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. 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. 1.1.2
Aannames en beperkingen
Er gelden de volgende aannames en beperkingen onderverdeeld in verschillende categorien: • 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 ∗ 15/05/2015: Derde iteratie 1.1.3
Deliverables
De volgende documenten en artefacten moeten elke iteratie opgeleverd 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
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 portaal jQuery JSHint QUnit JSDoc CodeClimate Travis CI
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 http://jquery.com/ http://jshint.com/ http://qunitjs.com/ http://usejsdoc.org/ https://codeclimate.com https://travis-ci.com/
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 gemaakt door Jens Nevens, Sander Lenaerts, Nassim Versbraegen, Jo De Neve en Jasper Bevernage. Communicatie gebeurd via de mailinglijst die voorzien werd via het Wilma systeem, nl.
[email protected]. Ook kan het Trello board gebruikt worden om te communiceren, al dient dit meer om to-do’s, requirements of andere informatie te raadplegen. De issue tracker van GitHub zal gebruikt worden om bugs en andere issues in de code te rapporteren en op te lossen.
4
4.3
Rollen
In ons team heeft ieder teamlid een 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 genomen beslissingen. Verzekeren dat deadlines gerespecteerd worden. Verzekeren van kwaliteit documenten.
2. Requirements Manager: – Schrijven van SRS. – Overleggen met klant in verband met vereisten. – Prioriteiten bepalen en zorgen dat ze gerespecteerd worden. 3. DB Manager: – Ontwerpen en onderhouden van de database. 4. Server Manager: – Inrichten en onderhouden van de server. 5. Design Manager: – Schrijven van SDD. – Ontwerpt de architectuur voor het systeem. 6. Webmaster: – Houdt de portaalsite up to date. 7. Configuration Manager: – Beheert de GitHub repository. – Beheert de tools gebruikt door het team. 8. Quality Assurance: – Nakijken van source code. – Nakijken van documenten. 9. Test Manager: – Schrijven van STP. – Beheert alle testbanken. – Zorgt ervoor dat de tests het hele systeem dekken.
5
5 5.1 5.1.1
Management plannen Start-up plan Schatting
Een schatting in verband met de planning is in dit project niet van toepassing. Het project heeft een vaste deadline en deze mag niet overschreden worden. 5.1.2
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 Server Manager Design Manager Webmaster Configuration Manager Quality Assurance Test Manager
Jens R R B
Sander
Nassim
Jo B
Jasper B
R R B B
B R R
B R
B B
R R
Ieder teamlid is bovendien ook lid van het implementatie-team, dus het schrijven van de code gebeurd door alle leden van het team. 5.1.3
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
Werkplan
5.2.1
Activiteiten en planning
In onderstaande tabel staat de planning tot en met de eerste deadline. Dit is een periode van 8 weken. Week Week 1-2
Verantwoordelijke Hele team Hele team
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. Begin ontwerpen scenario 1. Opstellen requirements. Focus op schrijven van SPMP. Verder uitwerken van scenario 1. Focus op uitwerken van scenario 1. Uitwerken van andere documenten. Inrichten van de server en stijl van de website bepalen. Begin uitwerken scenario 3. Verder bepalen van stijl van de website. Extra ruimte om alles extra te testen, debuggen, klaarmaken voor release. Voorbereiden presentatie.
Hele team
Week 3 Week 4-5
Week 6-7 Week 8
Jens (PM) Sander (DBM) Nassim (DM) Jo en Jasper Jens (PM) Hele team Hele team Hele team Sander en Nassim Hele team Hele team Hele team Nog te bepalen
Deadline: 15/12/2014 Deze planning is nog zeer 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 en wordt ook behandeld in het Risico management plan. 5.2.2
Middelen
Onderstaande middelen zullen gebruikt worden in dit project: – – – – – –
Wilma server GitHub repository Trello board ShareLaTeX project MS Powerpoint Android smartphone 7
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. Indien er een nieuwe vereiste opduikt, moet deze besproken worden in de eerstvolgende vergadering en toegevoegd worden aan het SRS. 5.3.2
Planning controle
We hebben een ruwe schets van de planning tot aan de eerste deadline opgemaakt en gaan deze proberen te perfectioneren en ons hieraan te houden. Het uitbreiden en aanpassen van de planning is een verantwoordelijkheid van de PM, alsook erop toezien dat ieder teamlid zijn deadline respecteert. Tijdens elke vergadering wordt de vooruitgang van elk teamlid besproken en indien nodig wordt er bijgestuurd. Dit teamlid krijgt dan bijvoorbeeld extra hulp van een ander teamlid. 5.3.3
Kwaliteitscontrole
De QA is verantwoordelijk voor het controleren van de kwaliteit van de code. De QA kan hierbij ook gebruik maken van verschillende tools, zoals CodeClimate en Travis CI. Deze tools zijn ge¨ıtegreerd met de GitHub repository. Indien de QA een gebrek vind in de code, kan hij dit rapporteren op de GitHub issue tracker, hij kan de auteur van de code rechtstreeks contacteren of hij kan dit melden tijdens de eerstvolgende meeting. In de laatste week voor de deadline is het ook belangrijk dat er nog een grondige controle gebeurd van alle code. 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.
8
5.4
Risico management plan
We hebben de volgende risico’s gedentificeerd: 1. Onvoldoende kennis programmeertaal/tools – Waarschijnlijkheid: Hoog – Oplossing: Volgen van online cursus, lezen van tutorials/boeken, vragen aan teamlid 2. Falen van de server – Waarschijnlijkheid: Laag – Oplossing: Dirk Van Deun contacteren 3. Falen van een tool (vb. GitHub, ShareLaTeX, Trello) – Waarschijnlijkheid: Laag – Oplossing: Zoeken naar vervanging voor de tool 4. Slechte communicatie tussen teamleden – Waarschijnlijkheid: Gemiddeld – Oplossing: Zorg ervoor dat alle communicatie beschikbaar is voor alle teamleden. 5. Wegvallen van een teamlid – Waarschijnlijkheid: Laag – Oplossing: Teamlid met back-up rol neemt over. 6. Niet halen van de deadline – Waarschijnlijkheid: Gemiddeld – Oplossing: Goed bijhouden van alle vooruitgang. Gedeeltelijke vooruitgang proberen te demonstreren. 7. Foute interpretatie van vereisten – Waarschijnlijkheid: Gemiddeld – Oplossing: Overleggen met de klant en proberen om de vereiste correct te implementeren 8. Plotse verandering in vereisten – Waarschijnlijkheid: Laag – Oplossing: Overleggen met de klant en proberen om de vereiste correct te implementeren 9. Slecht inschatten hoe lang een taak zal duren – Waarschijnlijkheid: Gemiddeld – 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.
9
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. Er wordt een wekelijkse vergadering georganiseerd waarin we de gemaakte vooruitgang bespreken, alsook de problemen die we tegenkomen en de opdrachten voor de volgende week. Deze wekelijkse vergaderingen vallen in het volgende groter kader: eerst worden de vereisten bepaald voor de volgende functionaliteit, dan wordt de functionaliteit ontwerpen en vervolgens gemplementeerd en getest. We hebben gekozen voor dit model omdat de agenda van het project ons verplicht om iteratief te werken en omdat het makkelijker en logischer is om incrementeel te werken. Tijdens elke increment ligt de focus op het uitwerken van 1 bepaald scenario/functionaliteit.
6.2
Methoden, tools en technieken
De volgende methoden, tools en technieken zullen gebruikt worden: Tool GitHub
Trello
ShareLaTeX
Dropbox
Verklaring De GitHub repository wordt gebruikt als versioning systeem voor de code. Er zijn 2 vaste branches in de repository: de master branch en de develop branch. De master branch wordt gebruikt om stabiele, release-klare versies van de code op te zetten. De develop brancht wordt gebruikt voor de actieve ontwikkeling van het systeem. Telkens een nieuwe functionaliteit gempelemteerd moet worden kan een nieuwe feature branch aangemaakt worden. Indien deze functionaliteit volledig ontwikkeld en getest is, kan deze gemerged worden met de develop branch. De GitHub issue tracker zal ook gebruikt worden om fouten/bugs in de code te melden en gezamelijk proberen op te lossen. Op Trello bevinden zich meerdere boards. Het board voor de vereisten wordt onderverdeeld in to-do’s, busy en done. Er bestaat een board om de gebruikte tools en tutorials voor deze tools te raadplegen. Ten slotte is er ook een board om de afzonderlijke activiteiten van elk teamlid te loggen. Ook deze zijn onderverdeeld in to-do’s, busy en done. Deze website wordt gebruikt om gezamelijk te kunnen werken aan de verschillende documenten die opgeleverd moeten worden. Zoals de naam al zegt worden ze allen geschreven in het LaTeX formaat. Er is een openbare Dropbox folder aangemaakt waarop alle afgewerkte documenten op zullen verschijnen.
10
Tool jQuery
JSHint QUnit JSDoc CodeClimate
Travis CI
7 7.1
Verklaring Deze tool is een uitbreiding op JavaScript en zal ervoor zorgen dat het gemakkelijk is om vanuit de JavaScript-code door de HTMLpagina te navigeren, elementen op te vragen en aan te passen. Deze tool zorgt voor code-validatie en garandeert ook een gelijkaardige stijl en kwaliteit van de code Dit is een unit-testing framework Deze tool wordt gebruikt om documentatie te genereren voor de geschreven code Deze tool werkt samen met de GitHub repository en controleert de kwaliteit van de code, voert automatisch test-cases uit en meld mogelijke bugs door middel van statische analyse. Deze tool werkt samen met de GitHub repository en zorgt voor het automatisch uitvoeren van test-cases en integratie van de software.
Ondersteunende plannen Configuration management plan
Er is geen apart plan in verband met de configuratie van het project. Alle informatie over de gebruikte configuratie kan gevonden worden in sectie 6.2.
7.2
Testplan
Alle informatie in verband met testen van de software kan gevonden worden in het STP. Ieder teamlid is verantwoordelijk voor het testen van de door hem geschreven software, maar 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.
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. 11
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.
12
