Software Engineering – Groep 4 Software Project Management Plan Jan-Pieter Hubrecht (Project Manager) Kevin Hendrickx (Assistent Project Manager) 3e Bachelor Computerwetenschappen
[email protected] 13 november 2011
1
Tabel 1: Document geschiedenis v2.0 v1.2 v1.1 v1.0 v0.4 v0.3 v0.2 v0.1
13/11/2011 11/11/2011 08/11/2011 30/10/2011 30/10/2011 29/10/2011 29/10/2011 27/10/2011
Jan-Pieter Hubrecht Jan-Pieter Hubrecht Jan-Pieter Hubrecht Jan-Pieter Hubrecht Kevin Hendrickx Team Jan-Pieter Hubrecht Kevin Hendrickx
2
Eindcontrole Aanvullingen Revisie Eindcontrole Controle en Aanvullingen Aanvullingen Kladversie Kladversie
Inhoudsopgave
Inhoudsopgave 1 Algemeen overzicht 1.1 Project beschrijving . . . . . . . . . . . . . . . 1.1.1 Doelstellingen en bereik van het project 1.1.2 Veronderstellingen en beperkingen . . . 1.1.3 Project opleveringen . . . . . . . . . . . 1.1.4 Planning en budget overzicht . . . . . . 1.2 Evolutie van het SPMP . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
5 5 5 5 5 5 6
2 Referenties
7
3 Afkortingen en definities 3.1 Afkortingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Definities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 8 8
4 Project Organisatie 4.1 Externe communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Interne structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Rollen en verantwoordelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . .
9 9 9 9
5 Managerial Process plans 5.1 Opstartplan . . . . . . . . . . . . . . . . . . . 5.1.1 Schattingsplan . . . . . . . . . . . . . 5.1.2 Personeelsplan . . . . . . . . . . . . . 5.1.3 Plan om middelen te bekomen . . . . 5.1.4 Personeelstrainingsplan . . . . . . . . 5.2 Werkplan . . . . . . . . . . . . . . . . . . . . 5.2.1 Werkactiviteiten . . . . . . . . . . . . 5.2.2 Vergaderingen . . . . . . . . . . . . . 5.2.3 Grafische voorstelling van de planning 5.2.4 Resource Allocation . . . . . . . . . . 5.3 Controleplan . . . . . . . . . . . . . . . . . . 5.3.1 Requirements Control Plan . . . . . . 5.3.2 Schedule Control Plan . . . . . . . . . 5.3.3 Reporting Plan . . . . . . . . . . . . . 5.4 Plan voor risicobeheer . . . . . . . . . . . . . 5.4.1 Gebrek aan kennis jUnit . . . . . . . . 5.4.2 Gebrek aan kennis SQL . . . . . . . . 5.4.3 Gebrek aan communicatie . . . . . . . 5.4.4 Gebrek aan Version Control kennis . . 5.4.5 Gebrek aan kennis LaTeX . . . . . . . 5.4.6 Gebrek aan ervaring in groep . . . . . 5.4.7 Het ziek worden van een teamlid . . . 5.4.8 Gebrek aan kennis Java/Android SDK 5.5 Project Closeout Plan . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
12 12 12 12 12 13 13 13 13 14 15 15 15 17 17 17 17 17 17 18 18 18 18 19 19
6 Technisch Proces Plans 20 6.1 Proces model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 Methodes, hulpmiddelen en technieken . . . . . . . . . . . . . . . . . . . . . . . 20 6.3 Infrastructure plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3
Inhoudsopgave 6.4
Product acceptance plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7 Plannen ondersteunende processen 7.1 Configuration management plan . . . . . . . . 7.1.1 Organisatie . . . . . . . . . . . . . . . 7.1.2 Verantwoordelijkheden . . . . . . . . . 7.1.3 Regels, Richtlijnen en Procedures . . . 7.1.4 SCM Activiteiten . . . . . . . . . . . . 7.1.5 Configuratie controle . . . . . . . . . . 7.1.6 Configuratie verificatie en verslag . . . 7.1.7 SCM middelen . . . . . . . . . . . . . 7.2 Verification and validation plan . . . . . . . . 7.3 Quality Assurance Plan . . . . . . . . . . . . 7.3.1 Organisatie . . . . . . . . . . . . . . . 7.3.2 Verantwoordelijkheid . . . . . . . . . . 7.3.3 Vereiste documentatie . . . . . . . . . 7.3.4 Standaarden, conventies en metrieken 7.3.5 Software inspecties . . . . . . . . . . . 7.3.6 Testen . . . . . . . . . . . . . . . . . . 7.3.7 Problemen rapporteren en verbeteren 7.3.8 Code controle . . . . . . . . . . . . . . 8 Aanvullende plannen
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
22 22 22 22 22 22 23 23 23 24 24 24 24 24 24 25 26 26 26 27
4
1 Algemeen overzicht
1 Algemeen overzicht 1.1 Project beschrijving 1.1.1 Doelstellingen en bereik van het project Dit project is in opdracht van Professor Van Der Straeten ter examinatie van de cursus Software Engineering aan de Vrije Universiteit Brussel. De bedoeling is om een Android applicatie te bouwen die functioneert als een interactieve toeristische gids in een bepaalde stad. De gebruiker moet in staat zijn om de nabijgelegen bezienswaardigheden op een vlotte manier te kunnen zoeken en na het lezen van de informatie, eventueel te bezoeken. Door het uitdelen van scores leert de applicatie wandelingen samen te stellen die overeenstemmen met de voorkeuren van de gebruiker. Een gedetailleerd overzicht van de vereisten is terug te vinden in het SRS. 1.1.2 Veronderstellingen en beperkingen Veronderstellingen Tot op heden zijn er nog geen veronderstellingen gemaakt. Beperkingen De volgende lijst geeft een overzicht van de beperkingen die zijn opgelegd: • De applicatie moet als frontend werken op Android versie 2.2. • De applicatie moet als backend werken op Wilma (VUB, infogroep server). • De 2 Android smartphones worden pas het 2e semester ter beschikking gesteld. • Het systeem moet eenvoudig ge¨ınstalleerd kunnen worden. • De applicatie moet intu¨ıtief en gebruiksvriendelijk zijn. • Het ontwerp van de applicatie moet modulair zijn. • De programmeertaal is Java, eventueel uitgebreid met bibliotheken. • Er moet gewerkt worden naar deadlines. 1.1.3 Project opleveringen Vanwege de moeilijkheidsgraad van het project zullen er voor het tweede semester extra iteraties voorzien worden die los staan van de iteraties die opgelegd zijn door de Professor Van Der Straeten. Voor de mogelijkheid tot een grondig nazicht alvorens de definitieve deadline, worden er intern extra deadlines toegewezen. We onderscheiden deze intern opgelegde soft-deadlines van de extern opgelegde hard-deadlines. Van hard-deadlines kan niet worden afgeweken omdat dit zich reflecteert in het verlies van punten voor het vak. 1.1.4 Planning en budget overzicht In de vooropgestelde planning is er gebruik gemaakt van zowel extern opgelegde hard-deadlines als intern zelf opgelegde soft-deadlines. In tabel 2 en 3 zijn respectievelijk de deadlines voor het eerste en tweede semester te vinden. Hoogstwaarschijnlijk zullen er 4 iteraties doorlopen worden voor het schrijven van de code en documenten. Voor dit project is er geen budget voorzien. Voor een gedetailleerd overzicht zie sectie 5.2.
5
1 Algemeen overzicht
Tabel 2: Deadlines eerste semester Datum 28/10/2011 31/10/2011 12/11/2011 14/11/2011 13/12/2011 21/12/2011
Activiteit Kladversie SPMP Inleveren SPMP Kladversie SPMP, STD, SRS, SDD Inleveren STD, SRS, SDD Einde 1e iteratie: opleveren code en documenten Presentatie 1e iteratie
Aard Soft-deadline Hard-deadline Soft-deadline Hard-deadline Hard-deadline Hard-deadline
Tabel 3: Deadlines tweede semester Datum 06/03/2012 14/03/2012 17/04/2012 25/04/2012 18/05/2012 23/05/2012
Activiteit Einde 2e iteratie: opleveren code en documenten Presentatie 2e iteratie Einde 3e iteratie: opleveren code en documenten Presentatie 3e iteratie Einde 4e iteratie: finale oplevering Finale presentatie
Aard Hard-deadline Hard-deadline Hard-deadline Hard-deadline Hard-deadline Hard-deadline
1.2 Evolutie van het SPMP De Assistent Project Manager verzorgt het SPMP. Het document moet telkens up-to-date zijn bij een strikte deadline. De geschiedenis van de veranderingen is terug te vinden in tabel 1. Na elke vergadering zal het document worden herzien en indien nodig worden aangepast. Elke wijziging zal worden doorgegeven aan de Project Manager die de eindcontrole doet. Dit document hanteert de IEEE 1058-1998 standaard.
6
2 Referenties
2 Referenties Referenties [1] Groep 4. Software Design Description v1.0. http://wilma.vub.ac.be/~se4_1112/docs/sdd-v1.0.pdf. [2] Groep 4. Software Engineering Groep 4 - 2011. http://wilma.vub.ac.be/~se4_1112/. [3] Groep 4. Software Project Management Plan v2.0. http://wilma.vub.ac.be/~se4_1112/docs/spmp-v2.0.pdf. [4] Groep 4. Software Requirements Specification v1.0. http://wilma.vub.ac.be/~se4_1112/docs/srs-v1.0.pdf. [5] Groep 4. Software Test Document v1.0. http://wilma.vub.ac.be/~se4_1112/docs/std-v1.0.pdf. [6] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. Standard for Software Project Management Plans (SPMP), 1998.
IEEE
[7] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. Standard for Software Quality Assurance Plans (SQAP), 2002.
IEEE
[8] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. Standard for Software Configuration Management Plans (SCMP), 2005.
IEEE
[9] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. Standard for Software and System Test Documentation (STD), 2008.
IEEE
[10] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. IEEE Recommended Practice for Software Requirements Specifications (SRS), 2009. [11] IEEE Computer Society, 3 Park Avenue, New York, NY 10016-5997, USA. IEEE Standard for Information Technology—Systems Design— Software Design Descriptions (SDD), 2009.
7
3 Afkortingen en definities
3 Afkortingen en definities 3.1 Afkortingen CI
Configuration Item
IDE
Integrated Development Environment
SCMP
Software Configuration Management Plan
SPMP
Software Project Management Plan
SQAP
Software Quality Assurance Plan
SRS
Software Requirements Specification
STD
Software Test Document
VUB
Vrije Universiteit Brussel
3.2 Definities Configuration Item
Een deel van het project dat beheerd wordt door het configuratie systeem.
De Klant
De personen die de opdracht hebben gegeven tot het ontwikkelen van het product: Professor Van Der Straeten en haar assistent Jens Nicolay.
Het Product
De Mobile City Guide software voor op Android.
Repository
Documenten die op een gestructureerde manier gedeeld en aangepast worden door verschillende mensen.
Repository clone
De documenten van een remote repository lokaal kopi¨eren.
Repository pull
De lokale documenten updaten met de nieuwe versie van de remote repository.
Repository push
De remote repository updaten met de nieuwe versie van de lokale repository.
8
4 Project Organisatie
4 Project Organisatie 4.1 Externe communicatie Professor Van Der Straeten en haar assistent Jens Nicolay zijn de klanten van de applicatie die ontwikkeld zal worden. De communicatie met hen zal gebeuren via de Project Manager en eventueel de Design Manager. De back-end van de applicatie zal draaien op de Wilma server die beheerd wordt door Dirk Van Deun. De communicatie met hem zal gebeuren via de Configuratie Manager en de Project Manager. Daarnaast is het mogelijk dat de Infogroep gebruikt zal worden als externe hulplijn.
4.2 Interne structuur De grafische representatie van de interne structuur en de hi¨erarchie hiervan, is weergegeven in het organigram in figuur 1. Zwarte volle lijnen geven de interne hi¨erarchie weer. De rode stippellijnen duiden de interne communicatie aan. De groene lijn-streep-lijn verbindingen duiden interactie met de externe bronnen aan, zoals daar zijn de klant, de server en de website. Bovenaan de figuur staat de klant. De reden dat er wel een groene lijn staat tussen de klant en de website en niet tussen de klant en de server-repository is omwille van het feit dat de klant rechtstreeks aan de website kan maar niet rechtstreeks naar de back-end server kan, hiervoor moet hij gebruik maken van de applicatie. De horizontale zwarte streeplijn is de scheiding tussen de klant en het project. De reden dat de server-repository en de website op deze lijn liggen is omwille van het feit dat deze zowel door de klant als het project aanspreekbaar zijn. Het onderste gedeelte van de figuur geeft de interne structuur weer. Aan het hoofd staat de Project Manager. Deze wordt bijgestaan door de Assistent Project Manager en de Secretaris. Verder zijn er nog de andere functies Configuration Manager, Design Manager, Requirements Manager, Implemenation Manager, Quality Manager, Test Manager, Database Manager en Webmaster. Een gedetailleerde beschrijving van de taken van de verschillende functies is terug te vinden in sectie 4.3. De rode stippellijnen duiden de interne communicatie aan tussen de verschillende functies aan.
4.3 Rollen en verantwoordelijkheden • Project Manager – Is de algemeen verantwoordelijke voor het project – Zit de vergaderingen voor en bepaald de onderwerpen van deze vergaderingen – Is verantwoordelijk voor communicatie en contact met de docent en de assistent – Leest de rapporten na en keurt deze goed alvorens deze gepubliceerd worden – Observeert de vooruitgang van het project en de taken – Verdeelt de taken naargelang de tijdsdruk – Is de eindverantwoordelijke voor SPMP en houdt deze up-to-date – Keurt alle beslissingen goed vooraleer deze worden uitgevoerd • Assistent Project Manager – Verzorgt samen met de Project Manager het SPMP – Neemt taken over van de Project Manager waar nodig • Configuration Manager – Zorgt ervoor dat iedereen het systeem van de repositories kent
9
4 Project Organisatie
Figuur 1: 8 Grafische representatie van de interne structuur. Zwarte volle lijnen tonen de hi¨erarchie. De rode stippellijnen staan voor de interne communicatie en de groene lijn-streep-lijn verbindingen duiden interactie met de externe bronnen aan. 10
4 Project Organisatie – Maakt de repositories aan – Controleert of de repository goed gebruikt wordt (gebruik van branches e.d.) – Zorgt dat iedereen begrijpt hoe hij met de repository en bijhorende software moet werken – Is verantwoordelijk voor het SCMP gedeelte in het SPMP – Is verantwoordelijk voor het opzetten en onderhouden van extra software (zoals bijvoorbeeld de Java android IDE) • Database Manager – Verantwoordelijk voor het maken en het onderhouden van de database op de Wilma server – Verantwoordelijk voor het back-end systeem dat het mogelijk maakt om op een gemakkelijke manier de database aan te passen • Design Manager – Kiest de standaard – Is verantwoordelijk voor de SDD – Leidt de discussies aangaande design • Implementation Manager – Is verantwoordelijk voor de verdeling van het werkt overheen de programmeurs – Overziet de vooruitgang van het programmeren en stuurt waar nodig bij • Quality Manager – Beslist welke conventies gehanteerd zullen worden in de code en documenten – Kijkt de code en documenten na – Is verantwoordelijk voor het plannen en leiden van inspecties – Is verantwoordelijk voor het SQAP gedeelte in de SPMP • Requirements Manager – Kiest de standaard – Is verantwoordelijk voor het SRS document – Leidt de discussies in verband met de software vereisten • Test Manager – Is verantwoordelijk voor het testen van de vereisten en verificatie – Is verantwoordelijk voor het STD document en houdt dit up-to-date – Is verantwoordelijk voor het schrijven van een document met de test resultaten • Webmaster – Onderhoudt de website gericht naar de klant • Secretaris – Schrijft de verslagen van de vergaderingen – Berekent de duur van elke vergadering
11
5 Managerial Process plans
5 Managerial Process plans 5.1 Opstartplan 5.1.1 Schattingsplan Aangezien dit een project is zonder budget is het niet nodig om dit in het schattingsplan op te nemen. Wat er wel geschat moet worden is het aantal uren dat per teamlid gespendeerd zal worden aan het project. Schatting van het aantal uren Dit project is in het kader van het vak Software Engineering van 9 studiepunten. Het aantal studiepunten van een bepaald vak kan gebruikt worden om het totaal aantal uren te berekenen dat een student aan dat vak moet werken. Volgens de VUB komt 9 studiepunten overeen met 235 a 255 uren werk. Voor dit project gaan we een richtlijn van 245 uren per persoon nemen, inclusief de hoorcolleges. Deze hoorcolleges moeten niet in rekening worden gebracht om een schatting te maken van de totale tijd die aan het project gespendeerd moet worden. We komen dan uit op 210 uur per persoon. In sectie 5.2.4 wordt een gedetailleerde beschrijving van de verdeling van deze uren opgesteld. 5.1.2 Personeelsplan Groepsleden Voor dit project zijn er 6 mensen ter beschikking. In tabel 4 worden de contact gegevens van de verschillende groepsleden op een rijtje gezet. De verschillende functies Voor elke functie wordt er een verantwoordelijke aangeduid, alsook een backup. Deze laatste valt in indien de verantwoordelijke wegvalt maar hij kan deze ook bijstaan bij grote taken. De verdeling van de functies is te zien in tabel 5. 5.1.3 Plan om middelen te bekomen De VUB zal ons 2 Android smartphones ter beschikking stellen om de applicatie te testen aan het begin van het tweede semester. De Wilma server die we gebruiken voor backend, website, repositories en communicatie wordt beheerd door Infogroep.
Tabel 4: Overzicht van de teamleden en hun contact gegevens Naam Coppieters Tim De Clerck Quentin Hendrickx Kevin Hubrecht Jan-Pieter Nyckees Jeroen Van den Heuvel Lorenz
E-Mail Tim.Coppieters[at]vub.ac.be Quentin.De.Clerck[at]vub.ac.be Kevin.Hendrickx[at]vub.ac.be Jan-Pieter.Hubrecht[at]vub.ac.be Jeroen.Nyckees[at]vub.ac.be Lorenz.Van.Den.Heuvel[at]vub.ac.be
12
5 Managerial Process plans
Tabel 5: Overzicht van de verschillende functies en hun backup Functie Project Manager Assistent Project Manager Configuration Manager Database Manager Design Manager Implementation Manager Quality Manager Requirements Manager Test Manager Webmaster Secretaris
Verantwoordelijke Jan-Pieter Kevin Tim Tim Jeroen Jan-Pieter Quentin Lorenz Kevin Kevin Lorenz
Backup Quentin Quentin Kevin Lorenz Tim Lorenz Jeroen Jan-Pieter Tim Jeroen
5.1.4 Personeelstrainingsplan Niet iedereen heeft dezelfde voorkennis voor dit project. Voor Android-Java werd in het kader van het vak Software Engineering door Dries Harnie een les gegeven. Andere training moet op zelfstandige basis gebeuren. In tabel 5 werd aangeduid met J wanneer de persoon in kwestie voor een bepaald onderdeel training nodig heeft. Tabel 6: Overzicht van wie welke training nodig heeft
Java GIT jUnit
Jeroen J J J
Quentin J J J
Lorenz N J J
Jan-Pieter N J J
Tim J N J
Kevin J J J
5.2 Werkplan 5.2.1 Werkactiviteiten Voor iedere taak is er een verantwoordelijke aangesteld die de specifieke taak overziet. Naast deze verantwoordelijkheidsfuncties zullen de teamleden ook het nodige programmeerwerk doen. 5.2.2 Vergaderingen De vergaderingen voor het project zullen plaatsvinden op maandag tussen 13:00 en 15:00 tenzij anders afgesproken. Voor elke vergadering worden de agendapunten vastgelegd. Wat niet op de agenda staat wordt niet besproken op de vergadering. De dag voor elke vergadering zal er een reminder worden gestuurd met het uur en de locatie van de vergadering. Indien het nodig wordt geacht om een extra vergadering te houden (bijvoorbeeld bij het naderen van een belangrijke deadline) of om een vergadering te verplaatsen, zal er met de groepsleden overlegd worden wanneer deze best ingepland kan worden. Op de website zijn de verslagen van deze vergaderingen beschikbaar. Tabel 7 geeft een overzicht van de geplande vergaderingen.
13
5 Managerial Process plans
Tabel 7: Overzicht van de geplande vergaderingen Dag 24/10/2011 28/10/2011 04/11/2011 07/11/2011 14/11/2011 21/11/2011 28/11/2011 05/12/2011 12/12/2011 19/12/2011
Uur 11:00-12:30 12:30-13:20 13:00-13:25 13:00-14:25 13:00-15:00 13:00-15:00 13:00-15:00 13:00-15:00 13:00-15:00 13:00-15:00
Duur 1:30 0:50 0:25 1:25 -
5.2.3 Grafische voorstelling van de planning De deadlines die vooropgesteld zijn en terug te vinden zijn in tabel 2 en 3 van sectie 1.1.3, kunnen grafisch worden voorgesteld in een zogenaamde Gantt Kaart. Deze is te zien in figuur 2. Activiteiten De geplande activiteiten worden op de Gantt Kaart voorgesteld door rechthoekjes. Boven de activiteit staat de naam en aan de onderkant de start- en einddatum. Aan de rechterkant staan de groepsleden die meewerken aan de activiteit, de verantwoordelijke staat tussen accolades. In de volgende lijst worden de activiteiten opgesomd: • 1e iteratie • 2e iteratie • 3e iteratie • 4e iteratie Milestones De milestones worden op de Gantt Kaart voorgesteld door een ruit. Boven de milestone is de naam terug te vinden. De milestones komen vaak overeen met harde-deadlines aangezien er dan iets specifiek af moet zijn en getoond moet worden aan de klant. De volgende lijst geeft een overzicht van de milestones: • Opleveren SPMP • Opleveren STD • Opleveren SRS • Opleveren SDD • Presentatie 1 geven • Presentatie 2 geven
14
5 Managerial Process plans • Presentatie 3 geven • Finale Presentatie geven
5.2.4 Resource Allocation Voor dit project is er per groepslid 210 uren voorzien. Deze uren moeten verdeeld worden over de verschillende taken zoals daar zijn het schrijven van de documenten, het ontwikkelen/testen van de code, het opstellen van de requirements en het design, enz. Schrijven van documenten In tabel 8 is eens schatting weergeven voor de verschillende documenten die geschreven moeten worden en een schatting van het aantal uren dat hier per groepslid aan gewerkt zal worden. Tabel 8: Overzicht van de schatting van het aantal uren per document Document SPMP SRS STD SDD
Sectie SPMP SPMP SQAP SCMP -
Schrijver Kevin Jan-Pieter Quentin Tim Lorenz Kevin Jeroen
Geschat aantal uren 6 8 6 4 8 8 10
Bepalen van de requirements Nog te bepalen Opstellen van het design Nog te bepalen Implementeren van de code Nog te bepalen Testen van de code Nog te bepalen Maken van presentaties Nog te bepalen
5.3 Controleplan 5.3.1 Requirements Control Plan Bij elk nieuw vastgelegd requirement moet het SRS gewijzigd zorden. Deze wijzigingen worden meegedeeld aan alle teamleden omdat deze een impact kunnen hebben op het design van het product, de implementatie, de tests en de verschillende bijhorende documenten.
15
7
!
!
5 Managerial Process plans
Figuur 2: De planning grafisch voorgesteld in een Gantt Kaart.
16
5 Managerial Process plans 5.3.2 Schedule Control Plan De hard-deadlines (strikte deadlines) moeten altijd nageleefd worden. De soft-deadlines kunnen indien nodig herzien een aangepast worden, mits goedkeuring van de Project Manager. Indien een soft-deadline aangepast wordt, zullen alle groepsleden hiervan op de hoogte gebracht worden. 5.3.3 Reporting Plan Bij het schrijven van de documenten wordt er gebruik gemaakt van zowel extern opgelegde hard-deadlines als intern zelf opgelegde soft-deadlines. De hard-deadlines zijn de dagen dat het final resultaat afgewerkt moet zijn. De soft-deadlines zorgen er voor dat er voldoende tijd is om het document na te lezen en eventuele opmerkingen/fouten aan te passen. Na elke deadline worden de belangrijke wijzigingen meegedeeld aan het team. Indien nodig worden deze verder besproken op de eerstvolgende vergadering.
5.4 Plan voor risicobeheer 5.4.1 Gebrek aan kennis jUnit Waarschijnlijkheid
9
Impact
7
Prioriteit
20
Oplossing
De Test Manager zal jUnit bestuderen en de andere groepsleden een crash course jUnit geven zodat deze de basis onder de knie krijgen.
Einddatum
28/11/2011
5.4.2 Gebrek aan kennis SQL Waarschijnlijkheid
1
Impact
3
Prioriteit
15
Oplossing
Tim heeft reeds genoeg ervaring met SQL. Als Database Manager is hij de enige die hier kennis over moet hebben. Indien nodig is Kevin in staat zijn taken over te nemen.
Einddatum
Geen datum nodig
5.4.3 Gebrek aan communicatie Waarschijnlijkheid
7
Impact
7
Prioriteit
100
Oplossing
Er zal gebruikt gemaakt worden van IRC om informeel met elkaar te kunnen praten. Gregory voorziet een tutorial voor IRC. Voor de formele communicatie is er een mailing list. GSM nummers worden uitgewisseld voor snel contact bij dringende redenen.
Einddatum
28/10/2011
17
5 Managerial Process plans 5.4.4 Gebrek aan Version Control kennis Waarschijnlijkheid
8
Impact
10
Prioriteit
100
Oplossing
Tim heeft reeds ervaring met GIT. Hij zal ons helpen de basis aan te leren. Tim heeft ook een kleine tutorial geschreven over GIT. De rest is zelfstudie.
Einddatum
05/11/2011
5.4.5 Gebrek aan kennis LaTeX Waarschijnlijkheid
2
Impact
2
Prioriteit
5
Oplossing
Iedereen heeft notie van LaTeX. Het schrijven van documenten zorgt voor geen problemen. Indien er toch kleine problemen opduiken staat het team via IRC klaar om te helpen.
Einddatum
Doorlopend
5.4.6 Gebrek aan ervaring in groep Waarschijnlijkheid
8
Impact
3
Prioriteit
20
Oplossing
Door gebrek aan ervaring zal er vaker vergaderd worden. Enkel ervaring in de praktijk kan dit verbeteren. Jan-Pieter en Lorenz hebben reeds in groep gewerkt. Dit gaf Jan-Pieter de functie als Project Manager.
Einddatum
Doorlopend
5.4.7 Het ziek worden van een teamlid Waarschijnlijkheid
8
Impact
9
Prioriteit
20
Oplossing
Om gebrek aan teamleden te voorkomen is er de eerste vergadering reeds voor elke functie een back-up voorzien. De Project Manager kan ook het werk (zoals ontwikkelen van code) verdelen onder de overige teamleden.
Einddatum
Geen datum nodig
18
5 Managerial Process plans 5.4.8 Gebrek aan kennis Java/Android SDK Waarschijnlijkheid
6
Impact
7
Prioriteit
200
Oplossing
Nog niet beslist
Einddatum
21/11/2011
5.5 Project Closeout Plan Dit project zal onmiddellijk stop gezet worden na finale presentatie. De website en repository blijven online staan maar deze worden niet meer ge-update. Ook wordt er geen verdere ondersteuning geleverd bij eventuele problemen.
19
6 Technisch Proces Plans
6 Technisch Proces Plans 6.1 Proces model Eerste iteratie In de eerste iteratie zal er gebruik gemaakt worden van een evolutionair prototype. De bedoeling is om incrementeel kleine aanpassingen te doen, deze te testen en evalueren om er zo voor te zorgen dat er snel een werkend product is (dat nog niet compleet is). Het voordeel is dat bepaalde delen getest kunnen worden desondanks dat de volledige functionaliteit nog niet beschikbaar is. Volgende iteraties Voor de andere iteraties is nog niet bepaald welk model er gebruikt zal worden. Het is perfect mogelijk om dan te kiezen voor een ander model.
6.2 Methodes, hulpmiddelen en technieken Voor dit project zal er gebruik gemaakt worden van verschillende softwarepaketten en hulpmiddelen. Tabel 9 geeft een overzicht van de gebruikte software.
6.3 Infrastructure plan De software moet werken op de 2 beschikbare Android smartphones. De smartphones zijn de front-end en zullen beschikbaar zijn vanaf het tweede semester. De database en website zullen op de back-end draaien. Voor dit project is dit de Wilma server van de Infogroep. Iedere programmeur heeft zijn eigen laptop, de meeste onder ons werken met OSX, sommigen met Linux. Op deze laptops wordt er gebruikgemaakt van de Android SDK die ook een simulator heeft.
Tabel 9: Overzicht van de gebruikte software en hulpmiddelen Doel Projectbeheer Versiebeheer IDE Android SDK
Applicatie
UML diagrammen Documentatie
GIT Eclipe Android SDK MYSQL SQLite Ruby on Rails Concept Draw Doxygen
Tests Tekstverwerking Presentaties Planning
jUnit LATEX MS Powerpoint GanttProject
Database
Versie
2007 2.0.10
20
Beschrijving Bijhouden van de gepresteerde aantal uren Gecontroleerd samen werken Programmeeromgeving Plugin voor de Android ontwikkeling Database die op de back-end draait Database die lokaal op Android draait Database opvullen via de webiste Manueel opstellen van UML diagrammen Automatisch genereren van documentatie uit de commentaar in de code Test-framework voor Java Opmaak van de documenten beheren Slides voor de presentaties maken Genereren van Gantt kaarten
6 Technisch Proces Plans
6.4 Product acceptance plan Na iedere deadline en iteratie wordt er contact op genomen met de klant en wordt er feedback gegeven die gebruikt wordt om het project bij te sturen waar nodig.
21
7 Plannen ondersteunende processen
7 Plannen ondersteunende processen 7.1 Configuration management plan 7.1.1 Organisatie Om de organisatie van het configuration management vlot te te laten verlopen wordt er een persoon uit de groep aangesteld tot configuration manager. 7.1.2 Verantwoordelijkheden Configuration Management Het is de verantwoordelijkheid van de Configuration Manager (CM) om het team op de hoogte te houden van de status van de repository. Het zal ook hij zijn die nieuwe branches aanmaakt of wanneer anderen branches willen aanmaken, moeten zij dit eerst aanvragen aan hem. Het is wel aangewezen dat de CM eerst de groep informeert alvorens veranderingen door te voeren. Als de CM zijn taak om de een of andere reden niet kan vervullen, is er een backup CM aangeduid die dan op dat moment kan inspringen. Teamleden Het is belangrijk dat de andere teamleden (tevens gebruikers van de repository) de regels en richtlijnen i.v.m. het gebruik van de repository opgelegd door de CM strikt volgen. Met een heel team aan eenzelfde repository werken is immers zeer gevaarlijk en dergelijke repository kan makkelijk kappot gemaakt worden. 7.1.3 Regels, Richtlijnen en Procedures • Om de versies van onze CI’s te controleren zullen wij gebruik maken van het systeem GIT. • Elk teamlid moet GIT installeren indien hij/zij dit nog niet heeft en moet op z’n minst de basisfunctionaliteiten er van onder de knie hebben. Indien dit niet lukt kan hij/zij altijd uitleg vragen aan de CM. • Alle versies van de CI’s worden behouden. • Enkel de teamleden mogen de CI’s aanpassen. • Teamleden mogen enkel de repository pushen en pullen. Indien er een rollback of reset nodig is, wordt dit gedaan door de CM. • Bij het maken van een commit moeten altijd duidelijke messages gebruikt worden zodat indien men ooit wil terugkeren naar een vorige versie, het zeer duidelijk is naar welke commit we terug moeten. 7.1.4 SCM Activiteiten Identificeren van Configuration Items Er zal ´e´en grote repository beschikbaar zijn die onderverdeeld is in een map voor de documenten en een voor de code. Het identificeren van nieuwe CI’s is de verantwoordelijkheid van de Implementation Manager. Als leden nieuwe CI’s willen toevoegen moeten zij dit eerst aanvragen aan hem/haar. Indien hij/zij niet aanwezig is kan de Project Manager hier ook toestemming tot geven.
22
7 Plannen ondersteunende processen Documenten Er zal voor elk document een branch aanwezig zijn, wanneer iemand aan een document wenst te werken dient hij eerst in te checken in deze welbepaalde branch. Per document is er een aparte folder en per documenten folder zijn er folders voor elke versie van dat document. Als er een nieuwe versie gemaakt wordt van het document dan moet er een nieuwe folder aangemaakt worden met de naam van deze folder en de laatste versie moet hierin gekopieerd worden. 7.1.5 Configuratie controle Wijzigingen Aanvragen Elk teamlid is toegestaan om zijn eigen code aan te passen zolang dit geen wijziging in het design teweeg brengt. Wanneer iemand een verandering wil doen in het design moet dit eerst besproken worden met de Design Manager. Een teamlid mag ook code aanpassen van iemand anders, maar dan moet hij/zij hiervoor eerst toestemming vragen aan diegene die de code geschreven heeft. 7.1.6 Configuratie verificatie en verslag De CM bekijkt minstens een keer om de twee weken de repositories en brengt indien nodig hierover verslag op de vergadering. 7.1.7 SCM middelen • Een GIT repository op de Wilma server onder de gekregen naam van onze groep • Er kan altijd gebruik gemaakt worden van een grafische interface voor GIT zoals SmartGit, maar de basis vereiste is dat iedereen de standaard GIT gebruikt.
23
7 Plannen ondersteunende processen
7.2 Verification and validation plan De verificatie en validatie van het project gebeurd op basis van de software inspecties die besproken worden in sectie 7.3.5.
7.3 Quality Assurance Plan 7.3.1 Organisatie Een teamlid wordt aangesteld om Quality Assurance Manager te zijn. 7.3.2 Verantwoordelijkheid Het is de taak van de Quality Assurance Manager om ervoor te zorgen dat de kwaliteitseisen nageleefd worden door de andere teamleden. Dit wordt gedaan door o.a. inspecties te organiseren en de documenten en code nakijken. 7.3.3 Vereiste documentatie Voor dit project moeten er een aantal documenten geschreven worden: • SPMP: Software Project Management Plan • SRS: Software Requirements Specifications • STD: Software Test Plan • SDD: Software Design Document Het Software Quality Assurance Plan (SQAP) en Software Configuration Management Plan (SCMP) moeten dit jaar niet als individueel document afgeleverd worden, in plaats daarvan worden ze in het SPMP toegevoegd onder de secties Quality Assurance Plan en Configuration Management Plan. Ook de verslagen van de vergaderingen moeten bijgehouden worden. De documentatie in de Java broncode zal waarschijnlijk gegenereerd worden in Doxygen en is ook noodzakkelijk voor dit project. 7.3.4 Standaarden, conventies en metrieken Standaarden De standaard die gedurende dit project gehanteerd zal worden is gebaseerd op de IEEEstandaard. Dit werd gekozen omdat het een klein project is tegenover degenen waarvoor de IEEE-standaard gebruikt wordt en het dus af te raden is om de volledige standaard te volgen. Dus zullen er uit de IEEE-standaard de onderdelen gekozen worden die nuttig zijn voor dit project. Conventies De codeconventies zullen dezelfde zijn als die van de Code Conventions for Java Programming Language. Metrieken De metrieken die in dit project gehanteerd zullen worden zijn de volgende: • het aantal uren gespendeerd aan het project • aantal lijnen code in KLOC (Kilo Line Of Code, dus 1000 lijntjes code)
24
7 Plannen ondersteunende processen 7.3.5 Software inspecties Doel Inspecties hebben voor doel om de programmeurs aan te zetten om tijdens het ontwikkelen van de software meer op de kwaliteit van de programma te letten. Inspecties gaan ge¨organiseerd worden bij ieder document zodat we kunnen nazien of ze aan de kwaliteitseisen voldoen. Hoe zal een inspectie verlopen? Een inspectie zal meestal hetzelfde patroon volgen namelijk: 1. Een inspectie wordt gepland wanneer het in te dienen document af is 2. Ieder lid bereidt zich voor door het document te overlopen om te zien of hij opmerkingen heeft of fouten vindt 3. Tijdens het vergadering worden er mogelijke oplossingen/verbeteringen gezocht 4. Na de vergadering zullen de gewenste aanpassingen gedaan worden 5. De aanpassingen worden gevolgd door de groep om te zien of het aangepast wordt zoals het besproken werd Geplande inspecties • Software specificatie inspectie: Alle requirements zullen overlopen worden om te zien of er geen opmerkingen zijn. • Architectuur specificatie inspectie: De mogelijke architecturen gaan gedurende deze inspectie overgelopen worden. Deze gaat gebeuren wanneer de SDD beschikbaar is. • Gedetailleerde design inspectie: Er zal nagekeken worden of de gekozen architectuur aan de requirements voldoet. • Functionele inspectie: De bedoeling is dat gedurende deze inspectie de ingediende documenten nagekeken worden of ze aan de eisen van de SRS nog voldoen. Wordt gehouden voor het indienen van de code. • Fysieke inspectie: De kwaliteiteisen van het project worden nagekeken. De code en de documentatie zullen overlopen worden om te zien dat alles in orde is. Deze inspectie heeft eveneens plaats voor het indienen van de code. • In-process inspectie: Deze inspectie dient om na te gaan of het project nog consistent is. Volgt de code de design documenten nog? Zijn de design document en de testen nog consistent? • Post-implementatie inspectie: Inspectie die gehouden wordt na iedere iteratie. Zo kunnen er eventueel opmerkingen over de vorige iteratie of suggesties aangebracht worden voor de volgende iteratie. Planning In tabel 10 wordt een overzicht gegeven van de data waarop de geplande testen zullen doorgaan.
25
7 Plannen ondersteunende processen
Tabel 10: Overzicht van de de geplande inspecties Inspectie Software specificatie inspectie Architectuur specificatie inspectie Gedetailleerde design inspectie Functionele inspectie
Fysieke inspectie In-process inspectie Post-implementatie inspectie
Datum Nog te bepalen Nog te bepalen Nog te bepalen 13/12/2011 06/03/2012 17/04/2012 18/05/2012 13/12/2011 06/03/2012 17/04/2012 18/05/2012 Nog te bepalen 13/12/2011 06/03/2012 17/04/2012 18/05/2012
7.3.6 Testen Het testen gaat gedaan worden door unit tests te schrijven. Dit gaat gebeuren aan de hand van de JUnit framework. 7.3.7 Problemen rapporteren en verbeteren Documentatie Voor problemen met de documentatie zoals typefouten mag elk lid zelf de fout verbeteren. Indien er een probleem is met een stuk van een document (vb. een onderdeel die niet in het document staat) gaat het gerapporteerd worden aan de persoon die verantwoordelijk is voor het document. Code Er werd nog niets beslist voor het rapporteren van bugs in de broncode. 7.3.8 Code controle De Quality Manager gaat nakijken of de kwaliteitseisen gevolgd worden of niet. Indien niet zal hij de persoon in kwestie er attent maken en opvolgen.
26
8 Aanvullende plannen
8 Aanvullende plannen
27
