Plan Van Aanpak

PLAN

VA N

A A N PA K

Project James

Auteur:

Robin Lucassen

Plan van Aanpak

obin Lucassen

Plaats: Datum:

Delft 17 februari yyyy

17-2-yyyy Pagina 2

Plan van Aanpak

Inhoudsopgave 1Inleiding........................................................................................... .................4 2Projectomschrijving............................................................... ..............................5 2.1Projectomgeving.............................................................................. ................5 2.2Probleemomschrijving..................................................... ..................................5 2.3Doelstelling..................................................................................... ...............5 2.4Afbakening.............................................................................................. .......5 2.5Cruciale Succesfactoren................................................................ .....................5 2.6Producten....................................................................................... ...............5 3Aanpak............................................................................................................ ..7 3.1Projectmethodiek........................................................................................... ..7 3.2Programmeer Technieken................................................................................ ....9 3.3Overige Technieken .................................................................................. ........9 4Risicofactoren........................................................................... ........................12 4.1Tijdnood............................................................................... .......................12 4.2Ziekte.................................................................................... .....................12 4.3Verlies / Beschadiging................................................................... ...................12 4.4Kennis........................................................................................ .................12 4.5Begeleiding.......................................................................................... .........12 4.6Enthousiasme..................................................................... ...........................12 5Projectorganisatie.......................................................................... ....................13 5.1Rollen............................................................................. ............................13 5.2Resources.......................................................................................... ...........13 5.3Data................................................................................... ........................14 6Kwaliteitsborging............................................................... ................................16 6.1Testen........................................................................................... ..............16 6.2Daily Scrum Meeting................................................................ ........................16 6.3Sprint Review Meeting......................................................................... .............16 6.4Voortgang............................................................................................... ......16 7Planning....................................................................... ...................................17 Bijlage A:Code conventie........................................................... ............................18

Robin Lucassen

17-2-yyyy Pagina 3

Plan van Aanpak

1 Inleiding Dit plan van aanpak dient als handvat tijdens Project James, hier kan op terug gekeken worden op momenten dat dat nodig is. Het doel van het document is het omschrijven van het project en het werkt als basisdocument waarmee de voortgang gecontroleerd kan worden. Het plan van aanpak wordt in de eerste week van het project geschreven. De focus ligt in die week ook volledig op het plan van aanpak. Daarna kan het plan van aanpak in principe niet meer bijgewerkt worden. Dat wil niet zeggen dat er niet van het plan van aanpak afgeweken mag worden, dit hoeft echter niet gewijzigd te worden in het plan van aanpak. Het plan van aanpak wordt goedgekeurd door de opdrachtgever en door de begeleider vanuit school. Op het moment dat het plan van aanpak door beide is goedgekeurd kan er gestart worden met het project. Het plan van aanpak is verdeeld in een aantal hoofdstukken. Eerst wordt er in hoofdstuk 2 ingegaan op alle algemene zaken met betrekking tot het project. In hoofdstuk 3 wordt ingegaan op de aanpak van het project, hierin wordt beschreven welke methodieken en technieken er gebruikt worden tijdens het project. Dan volgt in hoofdstuk 4 een beschrijving van een aantal risico’s tijdens het project, tevens wordt er ingegaan op het voorkomen of genezen van deze risico’s. Daarna worden in hoofdstuk 5 alle rollen en resources bij het project beschreven. In hoofdstuk 6 is te lezen hoe de kwaliteit gewaarborgd wordt en als laatste volgt in hoofdstuk 7 een planning.

Robin Lucassen

17-2-yyyy Pagina 4

Plan van Aanpak

2 Projectomschrijving In dit hoofdstuk wordt het project omschreven en afgebakend.

2.1

Projectomgeving Auxilium heeft een intern systeem voor de urenregistratie van de medewerkers, dit systeem heet Mondriaan. Dit systeem is inmiddels al 4 jaar oud en heeft zichzelf nog steeds niet bewezen. Er zijn veel problemen met het systeem en er zijn nog maar 2 mensen die raad weten met de verdere ontwikkeling van het systeem. Dit omdat het gebaseerd is op een oude interne code bibliotheek die niet meer gebruikt wordt. Naast Mondriaan worden er in Microsoft Excel een hoop gegevens nog een keer bijgehouden, omdat deze gegevens in Mondriaan niet meer bij te houden zijn. Dit is vervelend want zo is er weinig overzicht over de gehele administratieve situatie binnen Auxilium.

2.2

Probleemomschrijving Mondriaan voldoet niet meer aan de wensen van Auxilium en is erg verouderd. Mondriaan is door het gebruik van een binnen Auxilium niet meer gebruikte programmeertaal en het gebruik van een oude code bibliotheek slecht onderhoudbaar. Ook worden veel zaken in Mondriaan en nog eens in Excel bijgehouden. Daarnaast kost het de medewerkers elke week veel tijd om hun uren op orde te krijgen.

2.3

Doelstelling Met James zullen de medewerkers binnen Auxilium gemakkelijker hun uren kunnen registreren en zal Auxilium meer overzicht krijgen over de administratieve situatie binnen het bedrijf. Voor het geval er later functionele systeemeisen bij komen zal het systeem onderhoudbaar moeten zijn. Het zal in de nieuwe situatie niet meer nodig zijn om zaken in Excel bij te houden en medewerkers zullen minder tijd kwijt zijn om hun uren op orde te krijgen.

2.4

Afbakening Mondriaan is een uitgebreide applicatie met verschillende onderdelen. Aangezien veel onderdelen uit Mondriaan inmiddels zijn vervangen door andere systemen, zullen in dit project alleen de onderdelen ‘urenregistratie’ en ‘medewerkers’ opgepakt worden. De verdere afbakening wordt gedaan aan de hand van het MoSCoW model, in paragraaf 4.2.3 wordt hier verder op ingegaan.

2.5

Cruciale Succesfactoren Het nieuwe systeem moet in ieder geval de mogelijkheid geven om medewerkers te laten inklokken, uitklokken en weekoverzichten bekijken en/of wijzigen. De administratieve medewerkers moet de uren van de medewerkers uit het systeem kunnen halen. Bij het registreren van uren hoort ook het registreren van vakantie en ziekte.

2.6

Producten Tijdens het project zullen er naast de applicatie verschillende bijproducten opgeleverd worden. Deze worden samen met de applicatie in deze paragraaf besproken.

Robin Lucassen

17-2-yyyy Pagina 5

Plan van Aanpak

2.6.1

Testplan Het testplan dient als aanvulling op het plan van aanpak, maar dan volledig gericht op het testen. Er wordt beschreven welke tests gedaan worden en hoe deze uitgevoerd zullen worden.

2.6.2

Implementatieplan In het implementatieplan wordt vastgelegd welke methodieken en technieken er gebruikt gaan worden voor het implementeren van de applicatie binnen Auxilium.

2.6.3

Eisenpakket In het eisenpakket worden alle functionele en niet-functionele eisen vastgelegd. Het document wordt opgesteld aan de hand van het template ‘Software Requirements’ van Microsoft, beschreven in het boek ‘Software Requirements’ van Karl Eugene Wiegers. De hoofdstukken die in dit document aan bod komen: • Introductie •

Globale omschrijving

•

Functionele Eisen

•

Interface Eisen

•

Overige Niet Functionele Eisen

Als bijlage komt hier nog het document met GUI designs bij. 2.6.4

Testrapport In het testrapport komen de resultaten van de in het testplan beschreven tests naar voren. Er wordt beschreven wat de resultaten van de tests waren en wat er nog gedaan moet worden om de problemen die uit de tests naar voren komen op te lossen.

2.6.5

Systeemdocumentatie Om het project overdraagbaar te maken is er enige systeemdocumentatie nodig. Hierin staan de verschillende onderdelen van de applicatie beschreven. Ook zal er een gebruikershandleiding voor de gebruikers opgeleverd moeten worden. Dit zal een kort en bondige handleiding bevatten zodat gebruikers er snel mee aan de slag kunnen.

2.6.6

James James is de uiteindelijk op te leveren software. James zal opgeleverd worden door middel van een volledige installatie op de applicatie server, met daarbij de geïnstalleerde dashboard pc.

Robin Lucassen

17-2-yyyy Pagina 6

Plan van Aanpak

3 Aanpak 3.1

Projectmethodiek Vanuit Auxilium is opgedragen gebruik te gaan maken van Scrum en Agile technieken. Dit wil zeggen dat het project verdeeld is in drie fasen die onderverdeeld zijn in iteraties, ook wel sprints genoemd. Bij deze aanpak hoort het volgende plaatje.

Zoals in het plaatje hierboven te zien is begint het project met het maken van een product backlog, hierin worden alle functionaliteit van de applicatie vastgelegd. Daarna ga je de eerste ontwikkelsprint in waarvoor een sprint backlog gemaakt is. In deze sprint houdt je elke dag een daily scrum meeting. Dit houdt aan totdat alle sprints doorgelopen zijn en daar komt het uiteindelijke product uit voort. Hieronder worden de verschillende scrum technieken en begrippen uitgelegd. 3.1.1

Fasen Volgens Scrum zijn er drie fasen die het project opsplitsen, dat zijn de volgende. • Voorstudie •

Ontwikkeling

•

Test & Implementatie

Tijdens de voorstudie worden de technische en functionele specificaties en het functioneel ontwerp van de applicatie vastgelegd. In deze drie documenten moet precies duidelijk zijn hoe de applicatie in elkaar gaat steken. Dit wordt gedaan met behulp van verschillende diagrammen en modellen. In de fase ontwikkeling wordt de werkelijke applicatie geschreven. Tijdens deze fase zal er ook het een en ander getest moeten worden. In de fase ‘test & implementatie’ wordt de geschreven applicatie getest, geaccepteerd en uiteindelijk geïmplementeerd.

Robin Lucassen

17-2-yyyy Pagina 7

Plan van Aanpak

3.1.2

Sprints Sprint zijn vaste periode’s die de fasen onderverdelen in stukken van twee tot vier weken, in dit project wordt een vaste tijd aangehouden van drie weken. Aan het begin van een sprint wordt er een sprint planning meeting gedaan waarin het doel van de sprint wordt vastgelegd. Elke dag van een sprint wordt er een Daily Scrum meeting gehouden. Aan het einde van een sprint wordt de sprint review meeting gehouden.

3.1.3

Product Owner De product owner is de eigenaar van de software. Meestal is dit iemand van de marketing afdeling van het bedrijf, maar in dit project is het de begeleider van de opdrachtnemer. Normaal gesproken prioriseert hij de product backlog, maar in dit project zal hij enkel dienen als degene die beslissingen kan nemen over wat er wel en wat er niet in het project valt.

3.1.4

Scrum Master De scrum master is eigenlijk de teamleider van het scrum team. Omdat er in dit project maar door één persoon gewerkt wordt zal de scrum master zelf gelijk het hele scrum team zijn. Hij bewaakt de voortgang en leidt de daily scrum meeting.

3.1.5

Product Backlog De product backlog is een lijst met alle functionaliteit die in het eindproduct geïmplementeerd dienen te zijn. De product backlog is een spreadsheet document met de volgende kolommen. • Item nr. – Het nummer dat bij de functionaliteit hoort. •

Omschrijving – Een korte omschrijving van de functionaliteit.

•

Fase – In welke fase zal deze functionaliteit opgepakt worden.

•

Sprint – In welke sprint zal de functionaliteit opgepakt worden.

•

MoSCoW – Geeft aan de hand van de MoSCoW methode aan hoe belangrijk deze functionaliteit is.

De product backlog wordt aan het begin van het project aangemaakt en wordt in de sprint planning geprioriteerd aan de hand van de MoSCoW methode. Tijdens de sprint planning worden er functionaliteit uit de product backlog genomen en in de sprint backlog geplaatst. 3.1.6

Sprint Backlog De sprint backlog ziet er bijna hetzelfde uit als de product backlog. Het enige verschil is dat de product backlog voor het gehele project geldt en de sprint backlog alleen voor een sprint en er zijn een aantal kolommen anders. De kolommen in de sprint backlog zijn als volgt. • Item nr. – Het nummer dat bij de functionaliteit hoort. •

Omschrijving – Een korte omschrijving van de functionaliteit.

•

MoSCoW – Geeft aan de hand van de MoSCoW methode aan hoe belangrijk deze functionaliteit is. Benodigde Tijd – De benodigde tijd die nog nodig is om deze functionaliteit af te ronden.

•

De sprint backlog wordt in tegenstelling tot de product backlog elke dag bijgewerkt. Over het algemeen zal dit betekenen dat de benodigde tijden bijgewerkt worden.

Robin Lucassen

17-2-yyyy Pagina 8

Plan van Aanpak

3.1.7

Daily Scrum Meeting Tijdens elke dag van een sprint wordt er een Daily Scrum gehouden. Deze Daily Scrum zal elke dag tussen 9 uur en half 10 gehouden worden. Tijdens de Daily Scrum worden er een aantal vragen gesteld. • Wat heb je gister gedaan? •

Wat ga je vandaag doen?

•

Zijn er nog zaken waar je tegenaan loopt?

Normaal gesproken voer je de daily scrum met je scrum team uit, maar aangezien in dit project het scrumteam maar één teamlid bevat zal de daily scrum samen met andere projecten die maar één enkel teamlid bevatten gedaan worden.

3.2 3.2.1

Programmeer Technieken C#.Net De applicatie zal volledig in C#.Net geschreven worden. Deze keuze is vanuit Auxilium opgelegd omdat alle applicaties door Auxilium in C#.Net geschreven worden. De C#.Net programmeertaal zal rusten op het .Net Framework 2.0. Dit is niet de nieuwste versie van het .Net Framework, maar aangezien alle applicaties bij Auxilium momenteel nog rusten op versie 2.0 verhoogd dit de overdraagbaarheid.

3.2.2

Castle Monorail Om gemakkelijker volgens het Model View Controller patroon te werken, wordt er gebruik gemaakt van het Caste Monorail Framework. Dit framework maakt gebruik van het model view controller patroon en heeft verschillende hulpmiddelen om het programmeren gemakkelijker te maken. De meeste applicaties bij Auxilium maken gebruik van dit framework en dus zal ook deze techniek de overdraagbaarheid verhogen.

3.3 3.3.1

Overige Technieken JBGE JBGE staat voor Just Barely Good Enough, dat wil zeggen dat er niet meer tijd dan nodig gestoken wordt in documentatie en diagrammen. Bij de documentatie kan dat betekenen dat er bepaalde hoofdstukken of paragrafen, die niet relevant zijn voor de ontwikkeling van de applicatie, weg gelaten kunnen worden. Op het moment dat blijkt dat deze hoofdstukken of paragrafen wel relevant zijn, worden ze op dat moment pas aangemaakt. Bij diagrammen en modellen wil dit zeggen dat bijvoorbeeld een foto van een getekend diagram voldoet en dat er geen digitale versie van gemaakt hoeft te worden. Ook hier geldt weer voor dat op het moment er een digitale versie nodig is deze gemaakt kan worden. Het gebruik van JBGE zal veel tijd schelen wat weer gebruikt kan worden voor de daadwerkelijke ontwikkeling van de applicatie.

3.3.2

UML UML is een modelmatige taal, ofwel een grafische weergave, die gebruikt wordt voor het in beeld brengen van objectgeoriënteerde applicaties. UML biedt een verzameling van verschillende diagrammen. In dit project zullen er maar een paar gebruikt worden.

Robin Lucassen

17-2-yyyy Pagina 9

Plan van Aanpak

•

Klasse diagrammen

•

Use Case diagrammen

•

Sequence diagrammen

•

Toestandsdiagrammen

Klasse diagrammen worden gebruikt om het model van de applicatie in beeld te brengen. Het model bestaat uit verschillende klassen en de samenhang daartussen. Use Case diagrammen tonen de actoren en de gebruikersfuncties van de applicatie. Deze worden gebruikt om beeld te krijgen van alle functionaliteit. Om deze functionaliteit later uit te werken wordt er gebruik gemaakt van gedetailleerde Use Cases. Dit zijn geen diagrammen maar een schema met een vaste structuur die verschillende zaken die bij een functionaliteit horen vast leggen. Een sequence diagram weergeeft de interactie tussen verschillende objecten die een bepaalde functionaliteit, of een deel daarvan, implementeren. De tijdsvolgorde staat centraal in een sequence diagram. Een toestandsdiagram geeft aan op welke wijze een object van toestand kan veranderen bij bepaalde gebeurtenissen. Deze diagrammen kunnen eventueel gebruikt worden waar nodig. 3.3.3

MoSCoW Methode De MoSCoW methode is een manier waarop eisen binnen een project of sprint op te delen zijn in vier categorieën van belangrijk tot niet belangrijk. Deze categorieën zijn de volgende. • Must have •

Should have

•

Could have

•

Wanna have

Must have’s moeten ten alle tijden terugkomen in het eindresultaat, zonder deze zal het project of de sprint falen. Should have’s zouden ook binnen het project of de sprint uitgevoerd moeten worden, maar een vergelijkbare oplossing kan ook voldoen. Could have’s komen alleen aan bod als er genoeg tijd is om ermee aan de slag te gaan. Een Wanna have is een eis die je graag uit zou voeren, maar die niks anders mag beïnvloeden. 3.3.4

Paper Prototyping Paper prototyping wordt gebruikt om feedback van de eindgebruikers te krijgen terwijl je applicatie nog op de tekentafel ligt. Bij paper prototyping werk je de schermen uit je applicatie uit op papier en ga je daarmee testen met de eindgebruiker. Zo kun je voordat je begint met programmeren al een hoop feedback van de eindgebruikers krijgen. Dit scheelt weer tijd die je anders had moeten gebruiken om zaken achteraf aan te passen in de applicatie.

3.3.5

Weblog Een weblog, ook wel een blog genoemd, is een website waarop regelmatig nieuwe berichten verschijnen. Op deze berichten kan gereageerd worden door lezers. Tijdens het project zal er vrijwel dagelijks geblogd worden, zo kunnen collega’s en geïnteresseerden zien wat er in het project gebeurd en kunnen ze daar feedback op geven. Het bloggen zal aan het eind van de dag

Robin Lucassen

17-2-yyyy Pagina 10

Plan van Aanpak

gebeuren om zo een overzicht van de dag te kunnen laten zien. Bij het bloggen zal er rekening gehouden moeten worden met zaken die Auxilium niet publiek wil maken. De blog zal bijgehouden worden op: http://james.auxilium.nl.

Robin Lucassen

17-2-yyyy Pagina 11

Plan van Aanpak

4 Risicofactoren Ieder project neemt risico’s met zich mee, daarom wordt er in dit hoofdstuk aandacht besteedt aan deze risico’s en zo mogelijk wordt er ook een passende oplossing gegeven.

4.1

Tijdnood Als blijkt dat er veel complexe zaken in de applicatie gaan zitten dan kan het zijn dat het projectteam in tijdnood komt. Daar is al rekening mee gehouden tijdens het opzetten van het project. Zo zijn alle onderdelen onderverdeeld van belangrijk naar niet belangrijk met de MoSCoW methode. Als er tijdnood optreedt dan zouden uiteindelijk alleen de must have’s geïmplementeerd worden. Bij het indelen van de functionaliteit met behulp van de MoSCoW methode mag het dus niet zo zijn dat de must have’s het gehele project innemen.

4.2

Ziekte Het kan altijd gebeuren dat een teamlid, in dit project de enige, ziek word. Als dit voor een langere periode gebeurd kan dit een belemmering zijn voor het project. Hiervoor geldt dezelfde oplossing als voor de tijdnood, omdat ziekte uiteindelijk resulteert in tijdnood.

4.3

Verlies / Beschadiging Verlies van data zou een cruciaal probleem zijn voor de voortgang van het project. Om te zorgen dat de data altijd veilig blijft wordt er gebruik gemaakt van verschillende tools die verder worden beschreven in de paragraaf data in het hoofdstuk projectorganisatie.

4.4

Kennis Mocht blijken dat er te weinig kennis van zaken is tijdens het project dan kan dit problemen op leveren. Om dit te voorkomen wordt er tijdens de voorstudie al gekeken of de kennis van zaken al in huis is. Zo niet, dan zal er een expert op dit gebied ingeschakeld worden die de opdrachtnemer verder op weg helpt.

4.5

Begeleiding Er is vanuit Auxilium veel ervaring met het begeleiden van stagiaires en afstudeerders, maar het kan voorkomen dat de begeleiding erbij in glipt of dat de afstudeerder te weinig begeleiding vraagt. Hierdoor zou de afstudeerder achter kunnen gaan lopen of de verkeerde richting op kunnen gaan. Om dit te voorkomen is er aan het begin van het project al elke week een gesprek met de stagebegeleider gepland om de voortgang te laten zien en te bespreken.

4.6

Enthousiasme Aangezien elk project leuk en minder leuke aspecten bevat, moet in de gaten gehouden worden of er wel aan alle aspecten gewerkt wordt. Door enthousiasme van de opdrachtnemer kan het gebeuren dat er minder leuke, maar wel net zo belangrijke, aspecten vergeten worden. Om dit te voorkomen houdt de opdrachtnemer elke dag een Daily Scrum om na te gaan of het project nog op schema loopt. Als extra veiligheid zijn er de wekelijkse gesprekken met de begeleider.

Robin Lucassen

17-2-yyyy Pagina 12

Plan van Aanpak

5 Projectorganisatie 5.1

Rollen Ondanks dit project maar door één persoon wordt uitgevoerd, zijn er wel meerdere mensen die een rol hebben in het project. Hieronder worden de verschillende rollen beschreven.

5.1.1

Opdrachtnemer (Robin Lucassen) Er wordt in dit project door één hoofdpersoon gewerkt, dit is de opdrachtnemer. Deze persoon zal alle werkzaamheden in het project uitvoeren en uiteindelijk alle producten opleveren. Omdat de opdrachtnemer een student is zullen er naast de producten binnen het project nog een aantal producten opgeleverd moeten worden voor school. Scrum rol: ScrumMaster, Scrum team

5.1.2

Opdrachtgever (Ronald Haze) De opdrachtgever is de persoon die het project neerlegt bij de opdrachtnemer. Hij is verantwoordelijk voor beslissingen die de opdrachtnemer niet zelf kan nemen. Hij is aanwezig bij de sprint planning meeting en de sprint review meeting. Scrum rol: Product Owner

5.1.3

Begeleider (Ronald Haze) Aangezien de opdrachtnemer een student is zal deze enige begeleiding en/of sturing nodig hebben. De opdrachtnemer kan vragen stellen aan de begeleider op het moment dat zaken niet duidelijk zijn. Elke week is er een overleg tussen de opdrachtnemer en de begeleider om de voortgang te bespreken.

5.1.4

Administratie Auxilium Aangezien er in dit project een urenregistratie systeem geschreven gaat worden is het van belang de administratie van Auxilium hierbij te betrekken. De opdrachtnemer zal met vragen over de urenregistratie terecht kunnen bij de administratie. De administratie heeft overzicht over alle regelingen die binnen Auxilium gelden. Scrum rol: Stakeholders

5.1.5

Medewerkers Auxilium De medewerkers van Auxilium moeten ook betrokken worden bij het project aangezien deze uiteindelijk de eindgebruikers worden. Een aantal van de medewerkers zullen deelnemen aan het paper prototyping.

5.2

Resources De volgende resources worden gebruikt tijdens het uitvoeren van het project.

5.2.1

Werkomgeving De werkplek van de opdrachtnemer en daarmee het gehele projectteam zal zich op de werkvloer van Auxilium bevinden. De werkplek zal aan een eiland van tafels liggen waar meerdere afstudeerders met hun project bezig zijn.

Robin Lucassen

17-2-yyyy Pagina 13

Plan van Aanpak

5.2.2

Hardware Voor de opdrachtnemer is de volgende hardware beschikbaar. • Computer met dubbele monitor •

5.2.3

Server waar de applicatie op getest kan worden

Software Voor het project is de volgende software nodig/beschikbaar. • Microsoft Windows XP Professional

5.2.4

•

Microsoft Visual Studio 2005 Professional (met Resharper)

•

Microsoft SQL Server 2005

•

Microsoft Office 2003 (Word, Excel, Powerpoint, Visio)

•

Mondriaan (de oude urenregistratie software)

•

Wordpress (Blogging software)

Boeken Software Requirements Auteur: Karl Eugene Wiegers ISBN: 0-7356-1879-8 Website: http://www.microsoft.com/learning/en/us/Books/6496.aspx Graphical User Interface Design and Evaluation Auteur: David Redmond, Alana Moore ISBN: 0-13-315193-X SmarTEST, Slim testen van informatiesystemen Auteur: Egbert Bouman ISBN: 978-90-12-12597-0 Website: http://www.smartest.nl

5.2.5

Documentatie •

5.3 5.3.1

Code Conventie Auxilium (toegevoegd als bijlage)

Data Broncode Op de broncode van de applicatie is versiebeheer nodig. Zo is het altijd mogelijk om terug te gaan naar een eerdere versie van een bestand. Ook is het belangrijk om regelmatig back-ups te maken van de broncode, mocht er verlies van broncode voorkomen. Binnen Auxilium is er een centrale SVN server voor versiebeheer, deze server maakt ook regelmatig back-ups van alle broncode van alle projecten. Voor dit project zal er dus ook gebruik van SVN gemaakt gaan worden. De SVN directory zal de volgende mappen bevatten. Trunk In de trunk wordt de broncode bewaard waar momenteel aan gewerkt wordt. Na het implementeren van een eis van de applicatie zal er weggeschreven worden naar de trunk. Mocht er aan het eind

Robin Lucassen

17-2-yyyy Pagina 14

Plan van Aanpak

van een werkdag nog aan een eis gewerkt worden, dan zal ook aan het einde van de werkdag weggeschreven worden naar de trunk. Branches Op het moment dat de broncode in de trunk moet blijven staan en er bijvoorbeeld een klein sub project gedaan wordt dan wordt er een branch aangemaakt. Op dat moment kan er aan het sub project gewerkt worden in de branch. Tags Per sprint wordt er een werkende versie van de software opgeleverd, dit wil echter nog niet zeggen dat dit gelijk een release van de software is maar dat kan wel. Al deze versies worden weggeschreven in de tags map. 5.3.2

Documentatie In dit project wordt er gebruik gemaakt van een centrale opslagplaats voor documenten. Dit gaat online gebeuren in de Microsoft Office Live omgeving. In deze omgeving wordt er een werkruimte aangemaakt voor het project. Alle documenten die bij het project horen worden weggeschreven naar deze werkruimte. Het voordeel van deze werkruimtes is dat er een plugin voor Microsoft Office bestaat die automatisch documenten wegschrijft op de werkruimte tijdens het opslaan. Ook kan er door meerdere mensen tegelijk aan een document gewerkt worden en bestaat er een mogelijkheid om deze verschillende nieuwe versies samen te voegen in één document.

Robin Lucassen

17-2-yyyy Pagina 15

Plan van Aanpak

6 Kwaliteitsborging Er zullen een aantal maatregelen genomen worden om de kwaliteit van het project en de producten te controleren.

6.1

Testen Om de kwaliteit van de applicatie te controleren zal de applicatie grondig getest moeten worden. Omdat de beschrijving van de tests redelijk wat omvat staan deze niet beschreven in het plan van aanpak. In plaats daarvan zal er een los testplan geschreven worden. Dit testplan zal als bijlage bijgevoegd worden bij dit plan van aanpak.

6.2

Daily Scrum Meeting De daily scrum meeting dient onder andere als controle voor de kwaliteit. Tijdens de daily scrum meeting kunnen projectleden, in dit geval uit andere projecten, elkaar controleren op de kwaliteit van hun project en producten. Het is daarom belangrijk dat deze bijeenkomst elke dag gevoerd wordt.

6.3

Sprint Review Meeting De sprint review meeting vind plaats aan het eind van elke sprint. Tijdens deze bijeenkomst is het gehele team inclusief de product owner aanwezig. Daarnaast is het mogelijk om de klant, gebruikers of programmeurs van een ander project uit te nodigen. Deze mensen kunnen op hun eigen gebied feedback geven op het product en daarmee wordt gelijk de kwaliteit bevorderd.

6.4

Voortgang Om het project in goede banen te laten leider is elke week een gesprek tussen de opdrachtnemer en de begeleider. In de gesprek zullen de gemaakte producten en de voortgang besproken worden. De begeleider zal feedback op de producten en de voortgang geven om te zorgen dat beide in goede banen voltooid zullen worden.

Robin Lucassen

17-2-yyyy Pagina 16

Plan van Aanpak

7 Planning

Robin Lucassen

17-2-yyyy Pagina 17

Bijlage A:Code conventie De code conventie beschrijft hoe de structuur van de broncode van de applicatie eruit zal gaan zien. Tijdens het project zal deze geraadpleegd moeten worden.

Robin Lucassen

17-2-yyyy Pagina 18