Software Project Management Plan

Transcriptie

1 Software Project Management Plan PEN: Paper Exchange Network Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1

2 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 Schatting 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 Configuration management plan Testplan Documentatieplan Kwaliteitsplan Problemen

3 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 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 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

4 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 15/05/2015: Derde iteratie 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

5 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 portaal jquery JSHint QUnit JSDoc CodeClimate Travis CI se1 1415/PEN.html

6 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 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. se1-1415@wilma.vub.ac.be. 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

7 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ördinatie 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

8 5 Management plannen 5.1 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 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 Server Manager R B Design Manager R B Webmaster B R Configuration Manager B R Quality Assurance B R Test Manager B R Ieder teamlid is bovendien ook lid van het implementatie-team, dus het schrijven van de code 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

9 5.2 Werkplan Activiteiten en planning In onderstaande tabel staat de planning tot en met de eerste deadline. Dit is een periode van 8 weken. Week Verantwoordelijke Activiteiten Week 1-2 Hele team Zelfstudie JavaScript, HTML en CSS Hele team Opzoeken welke tools gebruikt kunnen worden. Hele team Organisatie van het team en het project. Jens (PM) Begin opstellen van SPMP. Sander (DBM) Ontwerpen en opstellen van database. Nassim (DM) Begin ontwerpen scenario 1. Jo en Jasper Opstellen requirements. Week 3 Jens (PM) Focus op schrijven van SPMP. Hele team Verder uitwerken van scenario 1. Week 4-5 Hele team Focus op uitwerken van scenario 1. Hele team Uitwerken van andere documenten. Sander en Nassim Inrichten van de server en stijl van de website bepalen. Week 6-7 Hele team Begin uitwerken scenario 3. Hele team Verder bepalen van stijl van de website. Week 8 Hele team Extra ruimte om alles extra te testen, debuggen, klaarmaken voor release. Nog te bepalen Voorbereiden presentatie. 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 Middelen Onderstaande middelen zullen gebruikt worden in dit project: Wilma server GitHub repository Trello board ShareLaTeX project MS Powerpoint Android smartphone 7

10 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. Indien er een nieuwe vereiste opduikt, moet deze besproken worden in de eerstvolgende vergadering en toegevoegd worden aan het SRS 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 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 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. 8

11 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

12 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 Verklaring GitHub 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. Trello 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. ShareLaTeX 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. Dropbox Er is een openbare Dropbox folder aangemaakt waarop alle afgewerkte documenten op zullen verschijnen. 10

13 Tool jquery JSHint QUnit JSDoc CodeClimate Travis CI 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. 7 Ondersteunende plannen 7.1 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 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 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

14 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