Software Engineering Groep 4

Maat: px
Weergave met pagina beginnen:

Download "Software Engineering Groep 4"

Transcriptie

1 Software Engineering Groep 4 Software Project Management Plan Jan-Pieter Hubrecht (Project Manager) Kevin Hendrickx (Assistent Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be 12 mei

2 Tabel 1: Document geschiedenis v6.0 12/05/2012 Jan-Pieter Hubrecht Eindcontrole v5.1 11/05/2012 Jan-Pieter Hubrecht Aanpassen opmerkingen 3e iteratie v5.0 15/03/2012 Jan-Pieter Hubrecht Eindcontrole v4.1 07/04/2012 Jan-Pieter Hubrecht Aanpassen opmerkingen 2e iteratie v4.0 03/03/2012 Jan-Pieter Hubrecht Eindcontrole v3.1 28/02/2012 Jan-Pieter Hubrecht Aanpassen opmerkingen 1e iteratie v3.0 11/12/2011 Jan-Pieter Hubrecht Eindcontrole v2.1 29/11/2011 Jan-Pieter Hubrecht Aanvullingen v2.0 13/11/2011 Jan-Pieter Hubrecht Eindcontrole v1.2 11/11/2011 Jan-Pieter Hubrecht Aanvullingen v1.1 08/11/2011 Jan-Pieter Hubrecht Revisie v1.0 30/10/2011 Jan-Pieter Hubrecht Eindcontrole v0.4 30/10/2011 Kevin Hendrickx Controle en Aanvullingen v0.3 29/10/2011 Team Aanvullingen v0.2 29/10/2011 Jan-Pieter Hubrecht Kladversie v0.1 27/10/2011 Kevin Hendrickx Kladversie 2

3 Inhoudsopgave Inhoudsopgave 1 Algemeen overzicht Project beschrijving Doelstellingen en bereik van het project Veronderstellingen en beperkingen Project opleveringen Planning en budget overzicht Evolutie van het SPMP Referenties 7 3 Afkortingen en definities Afkortingen Definities Project Organisatie Externe communicatie Interne structuur Rollen en verantwoordelijkheden Managerial Process plans Opstartplan Schattingsplan Personeelsplan Plan om middelen te bekomen Personeelstrainingsplan Werkplan Werkactiviteiten Vergaderingen Grafische voorstelling van de planning Resource Allocation Controleplan Requirements Control Plan Schedule Control Plan Reporting Plan Plan voor risicobeheer Gebrek aan kennis junit Gebrek aan kennis SQL Gebrek aan communicatie Gebrek aan Version Control kennis Gebrek aan kennis L A TEX Gebrek aan ervaring in groep Het ziek worden van een teamlid Gebrek aan kennis Java/Android SDK Project Closeout Plan Technisch Proces Plans Proces model Methodes, hulpmiddelen en technieken Infrastructure plan

4 Inhoudsopgave 6.4 Product acceptance plan Plannen ondersteunende processen Configuration management plan Organisatie Verantwoordelijkheden Regels, Richtlijnen en Procedures SCM Activiteiten Configuratie controle Configuratie verificatie en verslag SCM middelen Verification and validation plan Quality Assurance Plan Organisatie Verantwoordelijkheid Vereiste documentatie Standaarden, conventies en metrieken Software inspecties Testen Problemen rapporteren en verbeteren Code controle Aanvullende plannen 29 4

5 1 Algemeen overzicht 1 Algemeen overzicht 1.1 Project beschrijving 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 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 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 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

6 1 Algemeen overzicht Tabel 2: Deadlines eerste semester Datum Activiteit Aard 28/10/2011 Kladversie SPMP Soft-deadline 31/10/2011 Inleveren SPMP Hard-deadline 12/11/2011 Kladversie SPMP, STD, SRS, SDD Soft-deadline 14/11/2011 Inleveren STD, SRS, SDD Hard-deadline 10/12/2011 Revisie SPMP, STD, SRS, SDD Soft-deadline 13/12/2011 Einde 1e iteratie: opleveren code en documenten Hard-deadline 21/12/2011 Presentatie 1e iteratie Hard-deadline Tabel 3: Deadlines tweede semester Datum Activiteit Aard 03/03/2012 Revisie SPMP, STD, SRS, SDD Soft-deadline 06/03/2012 Einde 2e iteratie: opleveren code en documenten Hard-deadline 14/03/2012 Presentatie 2e iteratie Hard-deadline 13/04/2012 Revisie SPMP, STD, SRS, SDD Soft-deadline 17/04/2012 Einde 3e iteratie: opleveren code en documenten Hard-deadline 25/04/2012 Presentatie 3e iteratie Hard-deadline 18/05/2012 Einde 4e iteratie: finale oplevering Hard-deadline 23/05/2012 Finale presentatie Hard-deadline 1.2 Evolutie van het SPMP De Project Manager verzorgt het SPMP maar deze kan eventueel worden bijgestaan door de Assistent Project Manager. 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 standaard. 6

7 2 Referenties 2 Referenties Referenties [1] Groep 4. Software Design Description v [2] Groep 4. Software Engineering Groep [3] Groep 4. Software Project Management Plan v [4] Groep 4. Software Requirements Specification v [5] Groep 4. Software Test Document v [6] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Software Project Management Plans (SPMP), [7] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Software Quality Assurance Plans (SQAP), [8] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Software Configuration Management Plans (SCMP), [9] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Software and System Test Documentation (STD), [10] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Recommended Practice for Software Requirements Specifications (SRS), [11] IEEE Computer Society, 3 Park Avenue, New York, NY , USA. IEEE Standard for Information Technology Systems Design Software Design Descriptions (SDD),

8 3 Afkortingen en definities 3.1 Afkortingen 3 Afkortingen en definities CI IDE SCMP SPMP SQAP SRS STD VUB Configuration Item Integrated Development Environment Software Configuration Management Plan Software Project Management Plan Software Quality Assurance Plan Software Requirements Specification Software Test Document Vrije Universiteit Brussel 3.2 Definities Configuration Item De Klant Het Product Repository Repository clone Repository pull Repository push Een deel van het project dat beheerd wordt door het configuratie systeem. De personen die de opdracht hebben gegeven tot het ontwikkelen van het product: Professor Van Der Straeten en haar assistent Jens Nicolay. De Mobile City Guide software voor op Android. Documenten die op een gestructureerde manier gedeeld en aangepast worden door verschillende mensen. De documenten van een remote repository lokaal kopiëren. De lokale documenten updaten met de nieuwe versie van de remote repository. De remote repository updaten met de nieuwe versie van de lokale repository. 8

9 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ërarchie hiervan, is weergegeven in het organigram in figuur 1. Zwarte volle lijnen geven de interne hiërarchie 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

10 4 Project Organisatie Figuur 1: 8 Grafische representatie van de interne structuur. Zwarte volle lijnen tonen de hiërarchie. De rode stippellijnen staan voor de interne communicatie en de groene lijn-streep-lijn verbindingen duiden interactie met de externe bronnen aan. 10

11 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

12 5 Managerial Process plans 5.1 Opstartplan Schattingsplan 5 Managerial Process plans 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 wordt een gedetailleerde beschrijving van de verdeling van deze uren opgesteld Personeelsplan Groepsleden Voor dit project zijn er 7 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 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 Moeremans Gil Nyckees Jeroen Van den Heuvel Lorenz 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 Gil.Moeremans[at]vub.ac.be Jeroen.Nyckees[at]vub.ac.be Lorenz.Van.Den.Heuvel[at]vub.ac.be 12

13 5 Managerial Process plans Tabel 5: Overzicht van de verschillende functies en hun backup Functie Verantwoordelijke Backup Project Manager Jan-Pieter Quentin Assistent Project Manager Kevin Configuration Manager Tim Quentin Database Manager Tim Kevin Design Manager Jeroen Lorenz Implementation Manager Gil Jan-Pieter Quality Manager Quentin Lorenz Requirements Manager Lorenz Gil Test Manager Kevin Jan-Pieter Webmaster Kevin Tim Secretaris Lorenz Jeroen 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 Jeroen Quentin Lorenz Jan-Pieter Tim Kevin Gil Java J J N N J J J GIT J J J J N J N junit J J J J J J J 5.2 Werkplan 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 Vergaderingen De vergaderingen voor het project zullen vanaf het tweede semester plaatsvinden op woensdag tussen 10:00 en 12: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

14 5 Managerial Process plans Tabel 7: Overzicht van de vergaderingen Vergadering Dag Uur Duur 1 24/10/ :00-12:30 1: /10/ :30-13:20 0: /11/ :00-13:25 0: /11/ :00-14:25 1: /11/ :00-13:50 0: /11/ :30-13:20 1: /11/ :00-13:35 0: /11/ :30-13:30 1: /12/ :00-14:00 1: /02/ :00-12:25 1: /02/ :00-11:40 1: /02/ :00-12:00 2: /03/ :00-11:00 1: /03/ :00-11:40 0: /04/ :00-11:55 0: /05/ :00-11:55 0: 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 14

15 5 Managerial Process plans Figuur 2: De planning grafisch voorgesteld in een Gantt Kaart. 15

16 5 Managerial Process plans Opleveren SRS Opleveren SDD Opleveren prototype 1e iteratie Presentatie 1 geven Opleveren prototype 2e iteratie Presentatie 2 geven Opleveren prototype 3e iteratie Presentatie 3 geven Opleveren finale versie 4e iteratie Finale Presentatie geven Resource Allocation Voor dit project zijn er per groepslid 210 werkuren 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. Algemene schatting Aangezien er 7 groepsleden zijn met elks 210 uren, is het totaal aantal uren voor dit project gelijk aan Bij het verdelen van de uren is er echter een marge van 28 manuren per persoon genomen die dient als reserve. Indien zou blijken dat de schatting niet realistisch is, kunnen deze gebruikt worden om meer tijd te creëren. De eigenlijke belasting zoals deze is ingepland is dus 182 uur per persoon voor het gehele project. In tabel 9 wordt de verdeling van deze uren over de verschillende activiteiten weergeven. De it. x duid op de xste iteratie. 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 Sectie Schrijver Geschat aantal uren SPMP Kevin 6 SPMP SPMP Jan-Pieter 8 SQAP Quentin 6 SCMP Tim 4 SRS - Lorenz 8 STD - Kevin 8 SDD - Jeroen 10 16

17 5 Managerial Process plans Bepalen van de requirements Het bepalen van de requirements is de job van de Requirement Manager. Hiervoor zal er 6 uur voorzien worden. Merk wel op dat deze 6 uur mee verwerkt zit in het opstellen van het SRS aangezien de requirements volledig uitgewerkt moeten worden bij het schrijven van het ervan. Opstellen van het design Het opstellen van het initieel design gebeurt door de Design Manager. Voor het uitwerken van het design is er 7 uur voorzien, die deel uitmaken van het schrijven van de SDD. Daarnaast zal het design ook overlopen en geïnspecteerd worden tijdens de vergaderingen. Dat zal 2 uur in beslag nemen voor ieder groepslid. Implementeren van de code De geschatte tijd voor het implementeren van de code is te zien in tabel 9. Voor het implementeren van de code is er een onderscheid gemaakt tussen de eerste iteratie en de daaropvolgende iteraties. We zijn er van uitgegaan dat de eerste iteratie een soort opstart iteratie is met 26 werkuren per groepslid. De drie andere iteraties is er 50 uren per persoon voorzien. Testen van de code De geschatte tijd voor het testen van de code maakt deel uit van kwaliteit en test is tabel 9. Ook hier is een onderscheid gemaakt tussen de eerste iteratie en de andere iteraties. Concreet is er in de eerste iteratie slechts 2 uur testing voorzien, aangezien dit een opstart iteratie is (de andere 3 uren zijn voor de kwaliteit van de code). Voor de daaropvolgende iteraties is er 30 uur voor testing voorzien (en 5 voor kwaliteit) voorzien. Maken van presentaties Voor dit project moeten er 4 presentaties worden gegeven. Elke presentatie zal door 2 groepsleden gegeven worden. Bij de planning is er 2 uur per presentator gerekend, dus 4 uur per presentatie (zie tabel 9). Tabel 9: Overzicht van de schatting van het aantal uren per activiteit Activiteit Documenten It. 1 It. 2 It. 3 It.4 Totaal Configuratie Design Implementatie Kwaliteit en testen Management Presentaties Totaal Per persoon ,8 182 Planning 1e iteratie In tabel 10 is een overzicht te zien van de gepresteerde uren in de 1e iteratie. Deze tabel is opgesteld na de 1e iteratie (op vraag van de klant), waardoor de eigelijke uren kunnen 17

18 5 Managerial Process plans verschillen van de geplande uren in tabel 9. Tabel 10: Gedetailleerd overzicht van de gepresteerde uren in de 1e iteratie Activiteit Duur Begin Einde SPMP v uur 24/10/ /10/2011 Opstarten project 6 uur 24/10/ /10/2011 Documenten v uur 31/10/ /11/2011 Configuratie 20 uur 24/10/ /12/2011 Design 20 uur 31/10/ /12/2011 Documenten v uur 14/11/ /12/2011 Implementatie 140 uur 14/11/ /12/2011 Kwaliteit en testen 5 uur 01/12/ /12/2011 Management 12 uur 24/10/ /12/2012 Presentatie 6 uur 13/12/ /12/2011 Planning 2e iteratie In tabel 11 is de gedetailleerde planning te zien van de 2e iteratie. Deze planning is opgesteld na de 1e iteratie maar voor de aanvang van de 2e iteratie. We hebben bij het opstellen van deze planning rekening gehouden met de problemen die we in de 1e iteratie zijn tegengekomen. Hierdoor is het mogelijk dat de uren verschillen met die van de oorspronkelijk planning in tabel 9. Tabel 11: Gedetailleerde planning van de 2e iteratie Activiteit Duur Begin Einde Configuratie 5 uur 13/02/ /03/2012 Design 35 uur 13/02/ /03/2012 Documenten v uur 13/02/ /03/2012 Implementatie 100 uur 06/02/ /03/2012 Kwaliteit en testen 25 uur 13/02/ /03/2012 Management 12 uur 13/02/ /03/2012 Presentatie 4 uur 03/03/ /03/2012 Planning 3e iteratie In tabel 12 is de gedetailleerde planning te zien van de 3e iteratie. Deze planning is opgesteld na de 2e iteratie maar voor de aanvang van de 3e iteratie. We hebben bij het opstellen van deze planning rekening gehouden met de problemen die we in de 2e iteratie zijn tegengekomen. Hierdoor is het mogelijk dat de uren verschillen met die van de oorspronkelijk planning in tabel 9. Planning 4e iteratie In tabel 13 is de gedetailleerde planning te zien van de 4e iteratie. Deze planning is opgesteld na de 3e iteratie maar voor de aanvang van de 4e iteratie. We hebben bij het opstellen van 18

19 5 Managerial Process plans Tabel 12: Gedetailleerde planning van de 3e iteratie Activiteit Duur Begin Einde Configuratie 10 uur 05/03/ /04/2012 Design 15 uur 05/03/ /04/2012 Documenten v uur 01/04/ /04/2012 Implementatie 110 uur 05/03/ /04/2012 Kwaliteit en testen 35 uur 28/03/ /04/2012 Management 8 uur 05/03/ /04/2012 Presentatie 4 uur 13/04/ /04/2012 deze planning rekening gehouden met de problemen die we in de 3e iteratie zijn tegengekomen. Hierdoor is het mogelijk dat de uren verschillen met die van de oorspronkelijk planning in tabel 9. Tabel 13: Gedetailleerde planning van de 4e iteratie Activiteit Duur Begin Einde Configuratie 10 uur 17/04/ /05/2012 Design 15 uur 17/04/ /05/2012 Documenten v5.0 2 uur 10/05/ /05/2012 Implementatie 100 uur 17/04/ /05/2012 Kwaliteit en testen 35 uur 01/05/ /05/2012 Management 8 uur 17/04/ /05/2012 Presentatie 4 uur 14/05/ /05/ Controleplan Requirements Control Plan Bij elk nieuw vastgelegd requirement moet het SRS gewijzigd worden. 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 Schedule Control Plan De hard-deadlines (strikte deadlines) moeten altijd nageleefd worden. De soft-deadlines kunnen indien nodig herzien en aangepast worden, mits goedkeuring van de Project Manager. Indien een soft-deadline aangepast wordt, zullen alle groepsleden hiervan op de hoogte gebracht worden 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 19

20 5 Managerial Process plans deadline worden de belangrijke wijzigingen meegedeeld aan het team. Indien nodig worden deze verder besproken op de eerstvolgende vergadering. 5.4 Plan voor risicobeheer 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/ Gebrek aan kennis SQL Waarschijnlijkheid 1 Impact 3 Prioriteit 15 Oplossing Einddatum 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. Geen datum nodig 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/ 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/

21 5 Managerial Process plans Gebrek aan kennis L A TEX Waarschijnlijkheid 2 Impact 2 Prioriteit 5 Oplossing Einddatum Iedereen kent de notie van L A TEX. Het schrijven van documenten zorgt voor geen problemen. Indien er toch kleine problemen opduiken staat het team via IRC klaar om te helpen. Doorlopend 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 Het ziek worden van een teamlid Waarschijnlijkheid 8 Impact 9 Prioriteit 20 Oplossing Einddatum 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. Geen datum nodig Gebrek aan kennis Java/Android SDK Waarschijnlijkheid 6 Impact 7 Prioriteit 200 Oplossing Nog niet beslist Einddatum 21/11/ 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. 21

22 6 Technisch Proces Plans 6.1 Proces model Eerste iteratie 6 Technisch Proces Plans 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 14 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 14: Overzicht van de gebruikte software en hulpmiddelen Doel Applicatie Versie Beschrijving Projectbeheer Redmide Bijhouden van de gepresteerde aantal uren Versiebeheer GIT Gecontroleerd samen werken IDE Eclipe Indigo Programmeeromgeving Android SDK Android SDK r15 Plugin voor de Android ontwikkeling MYSQL Database die op de back-end draait Database SQLite Database die lokaal op Android draait Ruby on Rails Database opvullen via de website UML diagrammen Concept Draw Manueel opstellen van UML diagrammen Documentatie Doxygen Automatisch genereren van documentatie uit de commentaar in de code Tests junit Test-framework voor Java Tekstverwerking L A TEX Opmaak van de documenten beheren Presentaties MS Powerpoint 2007 Slides voor de presentaties maken Planning GanttProject Genereren van Gantt kaarten 22

23 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. 23

24 7 Plannen ondersteunende processen 7 Plannen ondersteunende processen 7.1 Configuration management plan Organisatie Om de organisatie van het configuration management vlot te te laten verlopen wordt er een persoon uit de groep aangesteld tot configuration manager 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 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 SCM Activiteiten Identificeren van Configuration Items Er zal één 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. 24

25 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 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 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 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 Smart- Git, maar de basis vereiste is dat iedereen de standaard GIT gebruikt. 25

26 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 Quality Assurance Plan Organisatie Een teamlid wordt aangesteld om Quality Assurance Manager te zijn 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 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 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) 26

27 7 Plannen ondersteunende processen 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örganiseerd 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 15 wordt een overzicht gegeven van de data waarop de geplande testen zullen doorgaan. 27

28 7 Plannen ondersteunende processen Tabel 15: Overzicht van de de geplande inspecties Inspectie Datum Software specificatie inspectie 17/11/2011 Architectuur specificatie inspectie 17/11/2011 Gedetailleerde design inspectie 22/02/2012 Week 12 Week 22 Functionele inspectie Week 28 Week 32 Week 12 Week 22 Fysieke inspectie Week 28 Week 32 Week 21 In-process inspectie Week 24 Week 28 Week 12 Week 22 Post-implementatie inspectie Week 28 Week Testen Het testen gaat gedaan worden door unit tests te schrijven. Dit gaat gebeuren aan de hand van de JUnit framework 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 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. 28

29 8 Aanvullende plannen 8 Aanvullende plannen 29

Software Engineering Groep 4

Software Engineering Groep 4 Software Engineering Groep 4 Software Project Management Plan Jan-Pieter Hubrecht (Project Manager) Kevin Hendrickx (Assistent Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be

Nadere informatie

Software Engineering Groep 4

Software Engineering Groep 4 Software Engineering Groep 4 Software Project Management Plan Jan-Pieter Hubrecht (Project Manager) Kevin Hendrickx (Assistent Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen

Nadere informatie

Software Configuration Management Plan

Software Configuration Management Plan Software Configuration Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 31/10/2010 Tom Strickx Template 0.2 31/10/2010 Tom Strickx First draft 1 Door hieronder te tekenen verklaart u akkoord

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen

Nadere informatie

Software Engineering Groep 4

Software Engineering Groep 4 Software Engineering Groep 4 Software Design Description Jeroen Nyckees (Design Manager) Jan-Pieter Hubrecht (Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be 11 december 2011

Nadere informatie

Software Engineering Groep 3

Software Engineering Groep 3 Software Engineering Groep 3 Post Mortem Review 1 Kristof Van Moffaert (QA Manager) 3 e Bachelor Computerwetenschappen Kristof.Van.Moffaert@vub.ac.be se3@tinf.vub.ac.be 22 februari 2009 Document geschiedenis

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Software Project Management Plan

Software Project Management Plan 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.1 Samenvatting project.........................

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Software Configuration Management Plan

Software Configuration Management Plan Software Configuration Management Plan Michiel De Keyser Configuration Manager van Software Engineering groep 3 December 14, 2010 Versie Datum Beschrijving 0.1 3 November 2010 Eerste ruwe versie 0.2 3

Nadere informatie

Software Project Management Plan

Software Project Management Plan FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN Software Project Management Plan Software Engineering Nicolas Carraggi, Youri Coppens, Christophe Gaethofs, Pieter Meiresone, Sam Van den Vonder, Fernando

Nadere informatie

Software Engineering Groep 3

Software Engineering Groep 3 Software Engineering Groep 3 Software Project Management Plan Diane De Coster (Project Manager) 1 e Master Burgelijk Ingenieur diane.de.coster@vub.ac.be se3@tinf.vub.ac.be 22 Oktober 2008 Document geschiedenis

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

Software Project Management Plan

Software Project Management Plan Faculteit Wetenschappen en Bio-ingenieurswetenschappen Vakgroep Computerwetenschappen Software Project Management Plan Arno De Witte, Romeo Van Snick, Vincent De Schutter, Silke Verhaeghe, Yannick Merckx

Nadere informatie

Software Engineering Groep 3

Software Engineering Groep 3 Software Engineering Groep 3 Software Project Management Plan Diane De Coster (Project Manager) 1 e Master Burgelijk Ingenieur diane.de.coster@vub.ac.be se3@tinf.vub.ac.be 8 Maart 2009 Document geschiedenis

Nadere informatie

Software Project Management Plan for WiseLib

Software Project Management Plan for WiseLib Software Project Management Plan for WiseLib Wout Van Riel Mathieu Reymond Sam Vervaeck Yannick Verschueren Arno Moonens October 2014 1 Contents 1 Introductie 5 1.1 Project Overzicht...........................

Nadere informatie

Software Test Document

Software Test Document Software Test Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

Software Engineering Group 3

Software Engineering Group 3 Software Engineering Group 3 Verslag vergadering week 2 Laurens Teirlinck (Secretaris) 1 e Master Ingenieurswetenschappen lteirlin@vub.ac.be se3@tinf.vub.ac.be 24 Oktober 2008 Document geschiedenis v1.0

Nadere informatie

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Versie

Nadere informatie

Software Engineering Groep 4

Software Engineering Groep 4 Software Engineering Groep 4 Software Test Document Kevin Hendrickx (Test Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be 17 mei 2012 1 Tabel 1: Document geschiedenis v5.0 17/05/2012

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

Software Project Management Plan

Software Project Management Plan FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN Software Project Management Plan Software Engineering Nicolas Carraggi, Youri Coppens, Christophe Gaethofs, Pieter Meiresone, Sam Van den Vonder, Fernando

Nadere informatie

Software Project Management Plan

Software Project Management Plan FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN Software Project Management Plan Software Engineering Nicolas Carraggi, Youri Coppens, Christophe Gaethofs, Pieter Meiresone, Sam Van den Vonder, Fernando

Nadere informatie

Plan van Aanpak. project Tetris Packing

Plan van Aanpak. project Tetris Packing Plan van Aanpak project Tetris Packing Inleiding! 4 Projectomschrijving! 5 Producten! 5 Testplan! 5 Ontwerprapport! 5 Implementatierapport! 5 Testrapport! 5 Systeemdocumentatie! 5 Aanpak! 6 Projectmethodiek!

Nadere informatie

Software Design Document

Software Design Document Software Design Document Mathieu Reymond, Arno Moonens December 2014 Inhoudsopgave 1 Versiegeschiedenis 2 2 Definities 3 3 Introductie 4 3.1 Doel en Scope............................. 4 4 Logica 5 4.1

Nadere informatie

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat:

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat: Training Trainingscode Duur Gepubliceerd Taal Type Leermethode Kosten SF2015V8 4 dagen 02/02/2015 Nederlands & Engels Developer, basis Invidueel & klassikaal Op aanvraag Deze training richt zich op het

Nadere informatie

Software Project Management Plan WiseLib

Software Project Management Plan WiseLib Software Project Management Plan WiseLib Wout Van Riel Yannick Verschueren Arno Moonens Mathieu Reymond se2-1415 14 Mei 2015 1 Contents 1 Introductie 5 1.1 Projectbeschrijving..........................

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

Software Engineering - Groep 1

Software Engineering - Groep 1 Software Engineering - Groep 1 Verslag vergadering week 0 Diane De Coster (Project Manager)- Laurens Teirlinck (Secretaris) 1 ste Master Ingenieurswetenschappen diane.de.coster@vub.ac.be se3@tinf.vub.ac.be

Nadere informatie

icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous

icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous icafe Project Joeri Verdeyen Stefaan De Spiegeleer Ben Naim Tanfous 2006-2007 Inhoudsopgave 1 2 1.1 Programmeertaal PHP5..................... 2 1.2 MySQL database......................... 3 1.3 Adobe Flash...........................

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

Software Requirements Specifications voor Schedule-Generator

Software Requirements Specifications voor Schedule-Generator Software Requirements Specifications voor Schedule-Generator Matthias Caenepeel Adam Cooman Alexander De Cock Zjef Van de Poel 20 mei 2011 Versie 3.0 1 Aanpassingsgeschiedenis. 23/2/2011 versie 0.1: Aanmaak

Nadere informatie

Offerte voor het bouwen van een website Klant: Ideefiks, IdeeKids

Offerte voor het bouwen van een website Klant: Ideefiks, IdeeKids Offerte voor het bouwen van een website Klant: Ideefiks, IdeeKids Consultant: Dirk Derom Inhoudstafel Algemene structuur van de website...6 Front pagina...6 Pagina IDEEFIKS/IDEEKIDS...6 Functionaliteit...10

Nadere informatie

Inhoud Inhoud. Over dit boek 7. 1 Eclipse IDE (Integrated Development Environment) 9. 2 Functionele specificatie 13

Inhoud Inhoud. Over dit boek 7. 1 Eclipse IDE (Integrated Development Environment) 9. 2 Functionele specificatie 13 5 Inhoud Inhoud Over dit boek 7 1 Eclipse IDE (Integrated Development Environment) 9 2 Functionele specificatie 13 3 Implementatie grafische gebruikersinterface 31 4 De klassen en methoden 57 5 Technische

Nadere informatie

Software Design Document

Software Design Document Software Design Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

Jaarproject programmeren bij LORE

Jaarproject programmeren bij LORE Jaarproject programmeren bij LORE Elke onderzoeksgroep heeft een eigen karakter en vereisten. Zo ook met LORE. Opdat je zou weten wat we van je verwachten maar ook wat je van ons mag verwachten, hebben

Nadere informatie

Software Conguration Management Plan Versie 1.1.1

Software Conguration Management Plan Versie 1.1.1 Versie 1.1.1 03-04-2006 Samenvatting Dit is het (SCMP) voor het project.dit project is onderdeel van het vak Software Engineering (2IP40) aan de Technische Universiteit Eindhoven. Het document voldoet

Nadere informatie

Team. Tijd. Tools. Functionaliteiten In de onderstaande afbeelding wordt aangegeven welke behoeften TeamPlayer voor u kan invullen.

Team. Tijd. Tools. Functionaliteiten In de onderstaande afbeelding wordt aangegeven welke behoeften TeamPlayer voor u kan invullen. TeamPlayer? TeamPlayer is een compleet en flexibel systeem voor tijdsregistratie en planning dat de grootste knelpunten in vele administraties aanpakt, daar waar de standaardsystemen nog te beperkt zijn.

Nadere informatie

Plan van aanpak Toogle

Plan van aanpak Toogle Plan van aanpak Toogle Gemaakt door, Kevin Donkers Paul v.d. Linden Paul Eijsermans en Geert Tapperwijn 1 Inhoudsopgave 1 Inhoudsopgave...2 2 Inleiding...3 3 Projectopdracht...4 4 Projectactiviteiten...5

Nadere informatie

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT

Nadere informatie

Software Requirements Specifications voor Schedule-Generator

Software Requirements Specifications voor Schedule-Generator Software Requirements Specifications voor Schedule-Generator Matthias Caenepeel Adam Cooman Alexander De Cock Zjef Van de Poel 23 februari 2011 Versie 1.1 1 Aanpassingsgeschiedenis. 23/2/2011 versie 0.1:

Nadere informatie

Voorlopig onderzoeksplan Bachelorscriptie CleanDoc-

Voorlopig onderzoeksplan Bachelorscriptie CleanDoc- Voorlopig onderzoeksplan Bachelorscriptie 2011 -CleanDoc- Wouter Lockefeer 0545228 Probleemstelling Een goede programmeertaal moet niet alleen efficiënte programma's opleveren, maar ook handig zijn in

Nadere informatie

Tips & Tricks: Tip van de maand januari 2009

Tips & Tricks: Tip van de maand januari 2009 Tips & Tricks: Tip van de maand januari 2009 Project Management met Teamcenter 2007 Door: Ramon van Raak Beheert u complexe projecten dan weet u als geen ander dat de projectvoorbereiding de basis legt

Nadere informatie

Projectplan. Elektronica-ICT Artesis. Auteur: Coopman Tom Interne Promotor: Peeters Tom Externe Promotor: Delepierre Bruno, Adforce

Projectplan. Elektronica-ICT Artesis. Auteur: Coopman Tom Interne Promotor: Peeters Tom Externe Promotor: Delepierre Bruno, Adforce Elektronica-ICT Artesis Projectplan Auteur: Coopman Tom Interne Promotor: Peeters Tom Externe Promotor: Delepierre Bruno, Adforce Projectplan ter voorbereiding van de bachelorproef en stage Academiejaar

Nadere informatie

Werkomgeving. Android Studio. Android - werkomgeving 1/6

Werkomgeving. Android Studio. Android - werkomgeving 1/6 Android - werkomgeving 1/6 Werkomgeving Android Studio Installatie Ga naar de volgende URL: http://developer.android.com/sdk/index.html Klik op de knop "Download Android Studio for Windows" om het programma

Nadere informatie

Webapplicaties Op maat van je proces

Webapplicaties Op maat van je proces Webapplicaties Op maat van je proces Content Wat is een webapplicatie Voordelen van webapplicaties Toepassingen/Use cases Wat is een webapplicatie Wat is een webapplicatie Webapplicaties laten toe om processen

Nadere informatie

B.Sc. Informatica Module 4: Data & Informatie

B.Sc. Informatica Module 4: Data & Informatie B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke

Nadere informatie

Business Process Management

Business Process Management Business Process Management Prof. dr. Manu De Backer Universiteit Antwerpen Katholieke Universiteit Leuven Hogeschool Gent Wat is een bedrijfsproces? Een verzameling van (logisch) gerelateerde taken die

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014 Werkgroep ISO29119 TestNet thema-avond 9 oktober 2014 Is dit n gezonde maaltijd? Ja toch!! Om jezelf een oordeel te kunnen vormen heb je informatie nodig!! Vandaag brengen we kennis en informatie bij elkaar

Nadere informatie

EXIN Agile Scrum Foundation

EXIN Agile Scrum Foundation Voorbeeldexamen EXIN Agile Scrum Foundation Editie april 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

Software Requirements Specification

Software Requirements Specification Software Requirements Specification PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage

Nadere informatie

Plan van aanpak 2006. Door: Jeroen Corsius en Mitchell Diels. GameShop

Plan van aanpak 2006. Door: Jeroen Corsius en Mitchell Diels. GameShop Plan van aanpak 2006 Door: Jeroen Corsius en Mitchell Diels GameShop 1. Inhoudsopgave 1. Inhoudsopgave blz. 2. Achtergronden 3. Projectopdracht 4. Projectactiviteiten 5. Projectgrenzen en Randvoorwaarden

Nadere informatie

Plan van aanpak. Website voor Bouwkundig Adviesbureau Punte. Hugo Nijhuis John Oelen Frank Hazekamp Cindy Roelofs Ben Wilbers Tim Regelink

Plan van aanpak. Website voor Bouwkundig Adviesbureau Punte. Hugo Nijhuis John Oelen Frank Hazekamp Cindy Roelofs Ben Wilbers Tim Regelink Plan van aanpak Website voor Bouwkundig Adviesbureau Punte 2009 Hugo Nijhuis John Oelen Frank Hazekamp Cindy Roelofs Ben Wilbers Tim Regelink Contents Product Backlog... 3 Documentatie... 4 Kwaliteitsbeheer...

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

Handleiding module Berichtenconverter Wmo en Jeugdwet

Handleiding module Berichtenconverter Wmo en Jeugdwet Handleiding module Berichtenconverter Wmo en Jeugdwet Beheerteam istandaarden Datum 2 januari 2015 Versie 1.0 Status Definitief Inhoud 1 Introductie 2 2 Installatie 4 3 Het gebruik van de Berichtenconverter

Nadere informatie

Project. 3D-Fraggel. Plan van aanpak. Door: IH1T08 1/1

Project. 3D-Fraggel. Plan van aanpak. Door: IH1T08 1/1 Project 3D-Fraggel Plan van aanpak Door: 1/1 Project 3D-Fraggel Plan van aanpak Datum: 07-05-2001 Plaats: Enschede Opdrachtgever: Saxion Hogeschool Enschede Instituut ICT Afdeling Hogere Informatica Contactpersoon

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

Nadere informatie

[ SCRUM. ] Een introductie

[ SCRUM. ] Een introductie [ SCRUM. ] Een introductie [ SCRUM IN HET KORT. ] Scrum is een agile-proces, welke het mogelijk maakt om te focussen op het leveren van het beste resultaat in de kortst mogelijke tijd. Het maakt het mogelijk

Nadere informatie

Projectdocument [versie 2.0]

Projectdocument [versie 2.0] Projectdocument [versie 2.0] Static Void 2 december 2011 Universiteit van Utrecht Team 2 Dit projectdocument is gemaakt door StaticVoid (team 2) voor het vak Introductieproject Informatica (INFOB1PICA).

Nadere informatie

Inleiding. Plan Van Aanpak

Inleiding. Plan Van Aanpak Inleiding. Er zijn verschillende mensen en bedrijven betrokken bij dit project. Het bedrijf Chess heeft een grote rol bij dit project. Het geeft de opdracht direct aan de studenten en verzorgt workshops

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

Vakinhoudelijke uitwerking Keuzevak Applicatieontwikkeling van het profiel MVI vmbo beroepsgericht

Vakinhoudelijke uitwerking Keuzevak Applicatieontwikkeling van het profiel MVI vmbo beroepsgericht Vakinhoudelijke uitwerking Keuzevak Applicatieontwikkeling van het profiel MVI vmbo beroepsgericht Deze vakinhoudelijke uitwerking is ontwikkeld door het Redactieteam van de Schooleamenbank vmbo voor dit

Nadere informatie

Stappenplan Implementatie ORBA

Stappenplan Implementatie ORBA De steden die wensen deel te nemen aan het ORBAtraject geven hun engagement. - Alle ORBA Intentieverklaring voor de instap in ORBA Centrumsteden Wanneer 5 steden zich engageren wordt gestart met Centrumsteden

Nadere informatie

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

Software Design Document

Software Design Document Software Design Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

Opdrachtformulering (pagina 3 van 7)

Opdrachtformulering (pagina 3 van 7) Afstudeerovereenkomst van Tim Wils Bijlage 1 Opdrachtformulering (pagina 3 van 7) Dit project betreft een eigen framework (soort API) waarmee relatief gemakkelijk en in korte tijd eindproducten opgezet

Nadere informatie

Verslag Vergadering 15 10/04/08

Verslag Vergadering 15 10/04/08 Verslag Vergadering 15 10/04/08 Software engineering: Groep 1 Titularis: Dirk Vermeir Begeleiders: Eline Philips 14 april 2008 Document geschiedenis Versie Datum Autheur Commentaar 0.1 14/04/2008 Nicolas

Nadere informatie

Handleiding module Berichtenconverter Wmo en Jeugd bètaversie

Handleiding module Berichtenconverter Wmo en Jeugd bètaversie Handleiding module Berichtenconverter Wmo en Jeugd bètaversie Beheerteam istandaarden Datum 24 december 2014 Versie 0.8 Status Concept Inhoud 1 Introductie 2 2 Installatie 4 3 Het gebruik van de Berichtenconverter

Nadere informatie

HEEMKUNDE RIPS. Project Initiatie Document. Datum voltooid: 9-11-2011. Versie: 1.0. Document ID: 1 Bestandsnaam: Project initiatie document

HEEMKUNDE RIPS. Project Initiatie Document. Datum voltooid: 9-11-2011. Versie: 1.0. Document ID: 1 Bestandsnaam: Project initiatie document HEEMKUNDE RIPS Project Initiatie Document Projectcode: P201101 Datum voltooid: 9-11-2011 Auteur: Paul Oostenrijk Versie: 1.0 Status: Concept Bestandsnaam: Project initiatie document Documenthistorie Revisies

Nadere informatie

1. Work Breakdown Structure en WBS Dictionary

1. Work Breakdown Structure en WBS Dictionary 1. Work Breakdown Structure en WBS Dictionary CUSTOMER migratie Management Technische Transitie Meetings Status Reporting Administratie Technisch Upgegrade Systemen (3-tier) Delta Analyse & Functioneel

Nadere informatie

Summa Cutter Tools. 1 Cutter tools. Met dit programma kunnen twee dingen geïnstalleerd worden:

Summa Cutter Tools. 1 Cutter tools. Met dit programma kunnen twee dingen geïnstalleerd worden: Summa Cutter Tools 1 Cutter tools Met dit programma kunnen twee dingen geïnstalleerd worden: 1. Plug-in voor Corel (vanaf versie 11) en Adobe Illustrator (vanaf versie CS). De plug-in voor Corel installeert

Nadere informatie

Projectdocument Airport Suite. The Wright Company: Zehna van den Berg Steven Both Reinier Maas Adolfo Ochagavía Bas Ouwerkerk Thijs van der Zaan

Projectdocument Airport Suite. The Wright Company: Zehna van den Berg Steven Both Reinier Maas Adolfo Ochagavía Bas Ouwerkerk Thijs van der Zaan Projectdocument Airport Suite The Wright Company: Zehna van den Berg Steven Both Reinier Maas Adolfo Ochagavía Bas Ouwerkerk Thijs van der Zaan December 2013 Contents 1. Overzicht... 4 2. Planning... 5

Nadere informatie

Portability, Interoperability of toch maar Connectivity Portability, Interoperability of toch maar Connectivity.

Portability, Interoperability of toch maar Connectivity Portability, Interoperability of toch maar Connectivity. Portability, Interoperability of toch 1 Even Voorstellen Diploma s: 1980 Bachelor of Science Civil Engineering (Cairo, Egypte) 1986 Doctoraal in Geodesie (TU Delft, Nederland) Enige Automatiseringservaring:

Nadere informatie

Handleiding voor de checklist Overdracht project/change naar beheer. Handleiding : Frédéric van der Vaeren

Handleiding voor de checklist Overdracht project/change naar beheer. Handleiding : Frédéric van der Vaeren Auteur(s) Datum Versie Frédéric van der Vaeren 11/03/2013 2.0 Eigenaar Doelpubliek Bert van Hemelen Gebruikers checklist overdracht project/change naar beheer Handleiding : Handleiding voor de checklist

Nadere informatie

Plan van Aanpak. Christophe Deloo, Roy Straver & Machiel Visser. Versie 4 (26-06-2010)

Plan van Aanpak. Christophe Deloo, Roy Straver & Machiel Visser. Versie 4 (26-06-2010) Plan van Aanpak Christophe Deloo, Roy Straver & Machiel Visser Versie 4 (26-06-2010) Inhoudsopgave Voorwoord... 2 1 Inleiding... 3 1.1 Aanleiding... 3 1.2 Accordering en bijstelling... 3 1.3 Toelichting

Nadere informatie

Installatiehandleiding Business Assistent

Installatiehandleiding Business Assistent Installatiehandleiding Business Assistent Wijzigingsgeschiedenis Versie Datum Omschrijving Status 0.1 25-09-2014 Eerste opzet van het installatie Concept document. 1.0 04-11-2014 Geen: Commercieel maken

Nadere informatie

Beveiligingsbeleid Perflectie. Architectuur & Procedures

Beveiligingsbeleid Perflectie. Architectuur & Procedures Beveiligingsbeleid Perflectie Architectuur & Procedures 30 november 2015 Versiebeheer Naam Functie Datum Versie Dimitri Tholen Software Architect 12 december 2014 0.1 Dimitri Tholen Software Architect

Nadere informatie

Bijlage 3: Master testplan

Bijlage 3: Master testplan Bijlage 3: Master testplan KIS Testplan Inaxion Lelystad Adres: Jol -20 Postbus : 609 Postcode Plaats 8483 ED Lelystad I www.inaxion.nl Plaats Lelystad Datum 22 maart 200 Auteur Saidou Diallo Status Finaal.0

Nadere informatie

Correspondentie inzake overnemen of reproductie kunt u richten aan:

Correspondentie inzake overnemen of reproductie kunt u richten aan: Vrijwel alle namen van software- en hardwareproducten die in deze cursus worden genoemd, zijn tegelijkertijd ook handelsmerken en dienen dienovereenkomstig te worden behandeld. Alle rechten voorbehouden.

Nadere informatie

Voorblad Inhoudsopgave Inhoud

Voorblad Inhoudsopgave Inhoud Voorblad Inhoudsopgave Inhoud (INHOUD) Achtergronden We moeten een website voor een jonge catering en een party service bedrijf bouwen. Dit bedrijf is gespecialiseerd in verzorging van borrelhapjes en

Nadere informatie

Test rapportage Waarom eigenlijk?

Test rapportage Waarom eigenlijk? Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015 @JurianvdL Jurian van de Laar

Nadere informatie

Release Notes v 1.1 0.22

Release Notes v 1.1 0.22 1/17 Release Notes v 1.1 0.22 Dit document beschrijft vanuit technisch oogpunt de aanpassingen in cheqpoint 1.1 aan de betreffende versie. Al deze informatie is confidentieel en mag niet zonder de schriftelijke

Nadere informatie

ClockWise Urenregistratie

ClockWise Urenregistratie ClockWise Urenregistratie Webbased uren schrijven ClockWise is een eenvoudig te gebruiken urenregistratie en projectregistratie systeem. ClockWise biedt de gebruiker een eenvoudige interface om snel en

Nadere informatie

Geïntegreerd Practicum

Geïntegreerd Practicum Geïntegreerd Practicum Introductie tot Git Jurgen Vandendriessche 2018-2019 Ingenieurswetenschappen 1 Introductie tot Git 1.1 Wat is Git? Git is een distributed version-control systeem (DVCS). DVCS is

Nadere informatie

Adding value to test tooling

Adding value to test tooling Adding value to test tooling performance testing and test automation Hoe we performance risico's ook in een CI/CD wereld de baas blijven Wie Ben Ik? >20 jaar ervaring in IT 10 jaarperformancearchitecten

Nadere informatie