Software Project Management Plan

Maat: px
Weergave met pagina beginnen:

Download "Software Project Management Plan"

Transcriptie

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

2 Revisies Omschrijving Datum Door Initiële versie 25/10/2014 Arno De Witte Uitgebreid met SCMP en SQAP 04/11/2014 Arno De Witte Uitgebreid voor iteratie 1 18/11/2014 Arno De Witte Finale versie voor iteratie 1 13/12/2014 Arno De Witte 1

3 Inhoud 1 Introductie Doel Beperkingen Deadlines Evolutie van dit document Referenties 5 3 Definities 6 4 Project Organisatie Organistatie naar buiten toe Rollen Management plan Opstartplan Stafplan Werkplan Werkactiviteiten Planning Communicatie middelen Controle Plan Requirements controle Planning controle Budget controle Risico beheer Technisch procesplan Procesmodel Methoden en middelen Infrastructuurplan Bijkomende procesplannen SCMP Configuration Management SCM Bibliotheken Quality assurance plan Documenten Broncode Documentatie plan

4 1 Introductie 1.1 Doel Het doel van dit project is om een publicatiebeheersysteem te bouwen. Het systeem beheert verschillende wetenschappelijke publicaties (zoals artikels, papers e.a.). Gebruikers kunnen zelf publicaties toevoegen, alsook andere publicaties opzoeken. Verder kan er een sociaal netwerk gebouwd worden tussen auteurs. Ook kunnen statistieken over verschillende auteurs, lezers, universiteiten en andere kunnen worden opgevraagd. Als naam voor het project hebben we gekozen voor Pubdig. Dit is een samentrekking van de Engelse woorden Publications en Digging. De symboliek hierachter is het verdiepen in publicaties, waar het systeem mee kan helpen. Het systeem is een webtoepassing die volledig gebouwd is in Javascript en draait dus in een browseromgeving. De toepassing zal naast ondersteuning voor de desktop ook ondersteuning bieden voor mobiele gebruikers. 1.2 Beperkingen Enkel gebruik van Javascript, HTML en CSS als programmeertalen. Er mogen wel open-source libraries gebruikt worden. De backend draait op de Wilma server. De frontend moet beschikbaar zijn in alle conventionele (mobiele) browsers. Er moet een website beschikbaar zijn over het project. Hierop kan informatie over de staat en de vooruitgang van het project worden gevonden. Alle documenten (in pdf formaat) en code moet beschikbaar zijn vanaf de site van het project. Er moet een overzicht van alle requirements en hun vordering op de website te vinden zijn. Alle documenten moeten worden opgeleverd in het Nederlands. Een iteratief ontwikkelingsproces. Het team bestaat uit vijf studenten van het vak Software Engineering [8]. 1.3 Deadlines Omschrijving Datum Inleveren SPMP Woensdag 05/11/2014 Eerste versie documenten Woensdag 19/11/2014 Einde iteratie 1: opleveren code en documenten Maandag 15/12/2014 Presentatie iteratie 1 Vrijdag 19/12/2014 Einde iteratie 2: opleveren code en documenten Dinsdag 03/03/2015 Presentatie iteratie 2 Woensdag 11/03/2015 Einde iteratie 3: opleveren code en documenten Maandag 20/04/2015 3

5 Omschrijving Datum Presentatie iteratie 3 Woensdag 22/04/2015 Einde iteratie 4: Finale oplevering. Vrijdag 15/05/2015 Presentatie iteratie 4 Woensdag 20/05/2015 Hieronder een kort overzicht van alle deliverables die bij elke iteratie moeten worden opgeleverd. Software Project Management Plan (SPMP) Software Design Document (SDD) Software Test Document (STD) Software Requirements Specification (SRS) Website over het project (zie beperkingen 1.2) Source code en dergelijke Verslagen van vergaderingen 1.4 Evolutie van dit document Dit document wordt onderhouden door de project manager, Arno De Witte. Wanneer deze niet beschikbaar is zal Romeo Van Snick deze taak op zich nemen als backup project manager. Naargelang het project evolueert, zal dit document worden uitgebreid. 4

6 2 Referenties [1] Project website. se3 1415/ [2] GitHub Repositories. https://github.com/pubdig/ [3] Wilma. [4] JSdoc. [5] Slack. https://slack.com/is/ [6] Trello. https://trello.com/tour [7] Agile Development. software development [8] Software Engineering. [9] Node.js 5

7 3 Definities SPMP Software project management plan SCMP Software configuration management plan SDD Software design document SRS Software requirements specification STD Software test document SQAP Software quality assurance plan Frontend Gedeelte van het project dat in de browser wordt uitgevoerd Backend Gedeelte van het project dat op de server wordt uitgevoerd 6

8 4 Project Organisatie 4.1 Organistatie naar buiten toe De klanten in dit project zijn de docenten van het vak Software Engineering [8]: Prof. Dr. Ragnhild Van Der Straeten en Jens Nicolay. Communicatie met de klant gebeurt via , tijdens de lessen Software Engineering of tijdens afspraken. Contact over de requirements zal gebeuren door de requirements manager. 4.2 Rollen Project manager Verantwoordelijk voor het maken van SPMP. Leidt de vergaderingen. Inleveren documenten en code. Zorgt voor een goede werking tussen de onderlinge groepsleden. Eindverantwoordelijke voor het halen van deadlines. Configuration manager Beheert het version control systeem. Beheert de website. Helpt het team met de gebruikte software en tools. Schrijft het SCMP. Maakt code- en document conventies. Design manager Verantwoordelijk voor het code design van het project. Schrijft het SDD. Quality assurance manager Staat in voor de kwaliteit van het ontwikkelingsproces. Staat in voor de kwaliteit van de documenten. Staat in voor de kwaliteit van de code. Controleert of de requirements correct in de applicatie worden geïmplementeerd worden en voldoen aan de eisen van de klant. Staat in voor de kwaliteit van het afgeleverde product. Test Manager Beheert de testen die instaan voor de stabiliteit van de code. Zorgt dat de tests automatisch en regelmatig worden uitgevoerd. Controleert het resultaat van de testen. Documenteert en rapporteert eventuele problemen zodat programmeurs deze kunnen oplossen. Verantwoordelijk voor het STD. 7

9 Requirements manager Schrijft het SRS. Voegt eventuele requirements toe of past huidige aan. Houdt het team op de hoogte van eventuele wijzigingen. Secretaris Neemt notities tijdens de vergaderingen. Uitschrijven van de verslagen van de vergaderingen. Communiceert over onduidelijkheden over de organisatie. Grafisch design manager Staat in voor het uiterlijk van de toepassing en website. Maakt wireframes van de diverse pagina s in het systeem. Programmeurs Schrijft de code. Voorziet zijn deel van de code van documentatie. Schrijft testen voor de code die hij heeft geschreven. Er is gekozen om de functie van Quality assurance manager en test manager samen te voegen. Dit omdat in de praktijk de kwaliteit van de code nauw in verband staat met de stabiliteit van de code. 8

10 5 Management plan 5.1 Opstartplan Stafplan Het team bestaat uit 5 leden: Arno De Witte, Romeo Van Snick, Vincent De Schutter, Silke Verhaeghe en Yannick Merckx. Dit zijn allemaal studenten computerwetenschappen die het vak Software Engineering [8] volgen. Voor elk van de bovenstaande rollen is er telkens één iemand de hoofdverantwoordelijke. Er is ook steeds een backup, dit wil zeggen dat wanneer de hoofdverantwoordelijke niet in staat is om de rol uit te voeren, de backup hem zal helpen in het uitvoeren van de rol. Opmerking hierbij is dat elk teamlid, naast zijn hieronder genoteerde functie, ook programmeur is. Functie Persoon Backup Project Manager Arno De Witte Romeo Van Snick Secretaris Silke Verhaeghe Arno De Witte Quality assurance manager en Test manager Yannick Merckx Vincent De Schutter Design manager Silke Verhaeghe Yannick Merckx Configuration manager Romeo Van Snick Arno De Witte Requirements manager Vincent De Schutter Silke Verhaeghe Grafisch design manager Vincent De Schutter Romeo Van Snick 5.2 Werkplan Werkactiviteiten In de onderstaande tabel kunnen de verschillende werkactiviteiten gevonden worden. Iteratie 1 Activiteit Verantwoordelijke Geschatte werktijd Effectieve werktijd Document Project beheren Project manager 70 uur 30 uur SPMP Configuratie setup Configuration manager 5 uur 10 uur SCMP Requirements beheren Requirements manager 40 uur 30 uur SRS Design Design manager 10 uur 20 uur SDD Implementatie Programmeurs 70 uur pp. 60 uur Broncode Tests beheren Test manager 50 uur 10 uur STD Als evaluatie hieruit kunnen we besluiten dat de sommige inschattingen zoals project management en testen voor de eerste iteratie niet helemaal correct waren. Maar naar gelang het project vordert, zullen er meer tests zijn en zal de taak van Test manager dus ook zwaarder worden. Voor bijvoorbeeld de configuration manager was er een onderschatting, maar nu het systeem draait zal deze ook een 9

11 minder zware taak hebben. Over het algemeen waren de inschattingen eerder te hoog. Hier is rekening mee gehouden bij het opstellen van de inschatting voor de volgende iteratie. Iteratie 2 Activiteit Verantwoordelijke Geschatte werktijd Document Project beheren Project manager 40 uur SPMP Configuratie onderhouden Configuration manager 2 uur SCMP Requirements beheren Requirements manager 10 uur SRS Design Design manager 5 uur SDD Implementatie Programmeurs 70 uur pp. Broncode Tests beheren Test manager 30 uur STD Wekelijkse vergaderingen Iedereen 10 uur Vergadering verslagen Planning Aan de hand van de bovenstaande werkactiviteiten werd er een visualisatie gemaakt van de planning voor de eerste iteratie. Deze tabel, ook wel een Gantt chart genoemd, geeft het visueel verloop weer van wanneer de verschillende activiteiten uitgevoerd zullen worden. De geschatte werktijd van een activiteit zal dus gespreid worden over de dagen waarop deze activiteit gepland staat. De Gantt chart voor iteratie 2 is te vinden als bijlage van dit document Communicatie middelen Voor de interne communicatie wordt er gebruik gemaakt van Slack [5]. Dit is een berichten systeem waarin er verschillende kanalen kunnen worden aangemaakt voor verschillende onderwerpen. Voor de interne taakverdeling wordt gebruik gemaakt van Trello [6]. De taakverdeling word elke week na de vergadering aangepast. Er wordt ook gebruik gemaakt van de mailinglist om algemenere updates over het project te geven. 5.3 Controle Plan Requirements controle Wijzigingen aan de project requirements (bepaalt door de klant) zullen steeds worden gereflecteerd in het SRS en op het requirements overzicht op de website. De requirement manager moet de wijzigingen aan de requirements steeds toelichten aan het team op de eerst volgende vergadering. De identifiers van de requirements moeten steeds dezelfde blijven. Zo blijven bestaande referenties naar de requirements steeds correct. Moesten er extra requirements bijkomen of moesten er aanpassingen aan de requirements gebeuren zal in het SRS besproken worden hoe dit het identificeren van de requirements verandert. De klant kan op elk moment de requirements aanpassen of nieuwe requirements toevoegen. De requirements manager zal dit opvangen. 10

12 5.3.2 Planning controle Op de wekelijkse vergadering vraagt de project manager steeds naar de vooruitgang van elk teamlid. Er worden elke week doelstellingen afgesproken die door elk teamlid moeten worden behaald. Deze gelden dus ook als deadlines. De project manager zoekt bij mogelijke problemen, bijvoorbeeld het niet halen van deadlines, naar oplossingen. Hij is dus verantwoordelijk voor het halen van de opgelegde deadlines Budget controle Het budget voor dit project wordt uitgedrukt in werkuren. De kost van het project is dus het aantal werkuren aan het project. Op de github [2] staat een intern document waar ieder teamlid noteert hoeveel tijd hij aan een bepaalde taak heeft gespendeerd. Zo kan er worden nagegaan hoeveel tijd er aan verschillende taken wordt gespendeerd. Bij het einde van een iteratie kan dit document dan worden aangepast om zo de effectief gewerkte tijd te vergelijken met de inschatting. Vermits er nog geen ervaring is met het inschatten kunnen deze dus verschillen van de realiteit. Zo kan er in volgende iteraties een betere afschatting worden gemaakt van de kost van dit project. 5.4 Risico beheer Hieronder een lijst met mogelijke risico s bij het ontwikkelen van het project. Voor elk risico is er een waarschijnlijkheid (schaal 1-10), impact (schaal 1-10), kost oplossing (schaal 1-10), oplossing en een verantwoordelijke. 1. Uitvallen van een teamlid. Waarschijnlijkheid 2 Impact 7 Kost Oplossing 8 Oplossing: Taken worden overgedragen aan backup. Nieuwe backup wordt gezocht voor de functie. Verantwoordelijke: Project manager. 2. Onvoldoende kennis van Javascript. Waarschijnlijkheid 5 Impact 8 Kost oplossing 6 Oplossing: De leden die geen kennis hebben van Javascript schaven deze bij voor 7 oktober. Bij problemen springen de andere groepsleden (met kennis van Javascript) bij. De quality assurance manager besteedt in de eerste iteratie extra aandacht aan de code geproduceerd door deze leden van het team. Verantwoordelijke: Project manager en quality assurance manager. 11

13 3. Documenten of code zijn niet tijdig klaar. Waarschijnlijkheid 5 Impact 9 Kost oplossing 4 Oplossing: Het opleggen van deadlines. Bij mogelijke problemen licht men de project manager in. Die dan zelf bijspringt of iemand aanduidt om dit te doen. Verantwoordelijke: Project manager. 4. Verlies van documenten. Waarschijnlijkheid 2 Impact 9 Kost oplossing 2 Oplossing: Elk lid zorgt ervoor dat de documenten op de github staan. Zo staan ze gebackupt op Github [2] en de computers van de andere teamleden. Verantwoordelijke: Project manager. 5. Falen backend Wilma. Waarschijnlijkheid 1 Impact 6 Kost oplossing 8 Oplossing: Er wordt een andere server gezocht om de code op te draaien. Verantwoordelijke: Configuration manager. 6. Kwaliteit van het project is onvoldoende. Waarschijnlijkheid 4 Impact 7 Kost oplossing 6 Oplossing: De quality assurance manager controleert wekelijks de kwaliteit van het project. Er worden ook automatische tests uitgevoerd bij het updaten van de code. Verantwoordelijke: Quality assurance manager. 7. Meningsverschillen Waarschijnlijkheid 7 Impact 5 Kost oplossing 4 Oplossing: Er wordt eerst een oplossing gezocht waar de verschillende partijen zich in kunnen vinden. Als deze niet kan gevonden worden, heeft de verantwoordelijke (bijvoorbeeld configuration manager bij de keuze over een tool) altijd het laatste woord. Bij verdere onenigheid, is de project manager verantwoordelijk voor het zoeken van een oplossing. 12

14 Verantwoordelijke: Project manager. 8. Onvoldoende domeinkennis (publicaties, conventies,...) Waarschijnlijkheid 5 Impact 8 Kost oplossing 3 Oplossing: Er wordt informatie vergaard bij assistenten en professoren over het onderwerp waarmee een probleem is. Vermits dit project in een academische context wordt gemaakt is het raadplegen van deze personen geen probleem. 13

15 6 Technisch procesplan 6.1 Procesmodel Voor dit project wordt er gewerkt met een iteratief model. Dit volgens de principes van Agile development [7]. Dit wil zeggen dat we steeds kiezen om bij elke iteratie een werkend project af te leveren. We kiezen hierbij om bepaalde requirements niet mee te leveren in een bepaalde iteratie, zo wordt er getracht om de geïmplementeerde requirements zo volledig mogelijk af te hebben. De vooruitgang van het project kan het best gemeten worden aan de hand van werkende software. Er wordt steeds wekelijks vergaderd. Tijdens deze vergadering geeft ieder teamlid een kleine update over de status van zijn stuk, zodat iedereen op de hoogte blijft van de status van het gehele project. 6.2 Methoden en middelen We gebruiken voor dit project de programmeertaal Javascript. Zowel de frontend en de backend wordt hierin geschreven. Voor de backend wordt gebruik gemaakt van Node.js [9]. Voor het frontend design wordt er gebruik gemaakt van HTML en CSS. Als database gebruiken we MySQL, deze software is beschikbaar op de Wilma server [3]. Als version control systeem gebruiken we git. We gebruiken github [2] als webhost voor onze repository. Er zal een repository worden aangemaakt voor de code en interne documenten en een repository voor de officiele documenten. Verwijzingen naar deze repositories zijn te vinden op de website [1]. 6.3 Infrastructuurplan De backend van het project zal draaien op de Wilma server. Deze wordt aangeboden door de Vrij Universiteit Brussel. De frontend moet kunnen draaien in verschillende browsers (zowel mobiel als desktop). Voor de mobiele browser kan beroep gedaan worden op android toestellen van de klant. 14

16 7 Bijkomende procesplannen 7.1 SCMP Naast het project management plan die het project en zijn evolutie in de juiste banen leidt, is het nodig ook een configuration management plan op te stellen. Dit document bevat richtlijnen voor het gebruik en de communicatie over code, tools en frameworks. Deze richtlijnen zijn er zowel voor intern gebruik, waar ze zorgen voor een vlotte samenwerking tussen de ontwikkelaars, als voor externe gebruikers van de software, die dankzij de uniforme werkwijze sneller hun weg kunnen vinden in het project. Beslissingen i.v.m. gebruik van frameworks, software en tools worden gaandeweg tijdens de evolutie van het project genomen want het is onmogelijk om alles reeds vooraf vast te leggen. Dit document zal dus nog evolueren naarmate het project vordert Configuration Management De configuration manager is verantwoordelijk voor het toezien op het correct toepassen van de conventies en eventuele problemen of frictie op te lossen. Hij houdt de teamleden op de hoogte van aanpassingen van de richtlijnen en stuurt bij waar nodig. De configuration manager is ook verantwoordelijk voor het correct configureren van de gebruikte tools en frameworks, om zo het werk van de teamleden te verlichten SCM Documenten Interne verslagen en documenten worden in markdown geschreven. Dit is een simpele markup-taal die iedereen snel onder de knie heeft en die weinig vooroordelen heeft over presentatie van de inhoud. Dit laat toe dat de documenten op een eenvoudige wijze omgezet worden naar verschillende formaten zodat die kunnen dienen voor verschillende doeleinden. Dit heeft als voordeel dat de instapkost en het gebruik risico voor markuptalen vermeden wordt. Iedereen kan snel markdown leren. De omzetting gebeurt aan de hand van de pandoc tool. Deze neemt markdown als input en genereert o.a. LaTeX of html documenten. Externe documenten worden in LaTeX geschreven. Markdown is namelijk een te eenvoudige taal om de complexiteit van zulke documenten in uit te drukken. Deze documenten hebben een langere levensduur en de risico s waarover hierboven gesproken worden, worden dus verspreid. Bovendien werken aan deze documenten vaak meerdere personen samen, ze kunnen elkaars fouten dus snel oplossen. De quality assurance manager kan bij het nagaan van deze documenten steeds fouten aangeven en oplossen. Conventies De conventies waaraan elk teamlid zich moet houden, bevinden zich ook op github. Zo heeft iedereen steeds een overzicht van de huidige 15

17 conventies en kunnen veranderingen van de conventies transparant worden doorgevoerd. Het onderwerp van deze conventies is voornamelijk code-formattering. Dit is een belangrijk onderwerp omdat het de teamleden toelaat op een gestructureerde wijze aan de code te werken. De codebase blijft netjes en iedereen vindt er zijn weg in. Bovendien helpen goede conventies sommige bugs te vangen (zeker in javascript). Github Om het overzichtelijk delen en beheren van code te vergemakkelijken zal gebruik gemaakt worden van github. Van de teamleden wordt verzocht om de code die ze schrijven regelmatig in te checken zodat iedereen steeds kan beschikken over de meest recente code. De management documenten worden eveneens in github bewaard, zodat ook deze dezelfde voordelen genieten. De code- en de management repositories worden gescheiden gehouden, zodat deze onafhankelijk van elkaar kunnen evolueren. Het is belangrijk dat op github enkel source-documenten worden bijgehouden, en dus nooit gegenereerde of gecompileerde documenten. Dit voorkomt dat er verschillende (tegenstrijdige) versies van een zelfde document aanwezig zijn in de repository. Als iemand een document in een bepaalde (gecompileerde) vorm nodig heeft, kan zij het altijd zelf compileren aan de hand van de correcte tool. Om te verzekeren dat de code die aanwezig is in de repository zeker voldoet aan de conventies die zijn vastgelegd, wordt gebruik gemaakt van het node-hooks pakket. Dit laat de contributors toe op een eenvoudige en geautomatiseerde wijze bepaalde scripts over de documenten die gecommit worden te laten lopen. Met name wordt er gebruik gemaakt van beautify.hks, een script dat de formattering van javascript bestanden normaliseert. De configuratie voor deze scripts bevindt zich ook in github, zodat deze gedeeld is tussen alle gebruikers (wat uiteraard belangrijk is). Bovendien is dit nog eens een extra specificatie van de syntax-conventies. API documentatie Omdat dit van uiterst belang is voor de correcte werking van het afgeleverd product wordt het protocol dat gebruikt zal worden tussen de frontend en de backend expliciet beschreven. Dit gebeurt aan de hand van een RAML-specificatie. RAML is een specificatie-tool die toelaat api s te specifieren en te documenteren. De api-documentatie zal steeds te vinden zijn op de website. De specificatie beschrijft welke endpoints er zijn alsook wat de verwachte parameters en return waarden zijn. Dit laat toe dat het backend team de correcte functies implementeert en dat het frontend team de correcte functies op een correcte manier gebruikt. De specificatie zal uiteraard ook evolueren met de tijd, maar dit wordt (waar mogelijk) altijd gedaan met oog op compatibiliteit met oudere versies. Zo moet reeds geschreven code niet meer aangepast worden. Website Er wordt ook een website [1] onderhouden, hierop bevindt zich de meeste informatie die met de management van het project te maken heeft. De 16

18 documenten die zich op deze website bevinden worden automatisch gecompileerd uit de documenten die zich in github bevinden. Dit gebeurt elke keer wanneer iemand ze aanpast. Zo blijven de documenten automatisch up-to-date en wordt het werk van de teamleden verlicht. De configuration manager is verantwoordelijk voor het onderhouden van de scripts die deze automatisering toelaten. npm en package.json Node.js voorziet een goede toolchain die het toelaat op een eenvoudige wijze het project te onderhouden en te bouwen: npm 1. Deze maakt gebruik van een configuratie bestand package.json. Dit bestand bevat o.a. een lijst van gebruikte packages. Dit laat toe dat elke gebruiker van de code enkel nog npm install moet uitvoeren en dat hij dan zonder meer het project kan gebruiken: npm is verantwoordelijk voor het ophalen van alle packages. Ook andere functionaliteit wordt onder npm ondergebracht. Zo kan de server gestart worden met npm start en kunnen de test uitgevoerd worden a.d.h.v. npm test. Dit alles laat toe dat het project na elke push op de github account kan worden gebouwd op de backend server of getest op de CI server (zie later). Het vereenvoudigt ook de samenwerking aangezien teamleden niet alle scripts of moeten kennen. gulp Waar npm voornamelijk instaat voor het onderhouden van bibliotheken en het runnen van scripts, staat gulp 2 in voor het bouwen van de frontend code. Gulp wordt vooral gebruikt om transformaties te doen op frontend code zoals samenvoegen en minifien (verkleinen) van javascript bestanden, afbeeldingen web-klaar maken, Reactjs-code compileren naar javascript etc. Dit alles gebeurt in een fractie van een seconde zodat gulp ook tijdens het coderen gebruikt kan worden. Er is een gulp-taak die verantwoordelijk is voor het detecteren van aanpassingen in files die dan de juiste taken oproept om de gegenereerde code up te daten. Dit heeft als voordeel dat een frontend programmeur tijdens het programmeren steeds ook de uiteindelijke frontend code zoals die bij de eindgebruiker terecht komt voor handen heeft en er dus later geen inconsistensies kunnen optreden die mogelijks te verwachten zijn mocht de code slechts in de finale stap (bij het uitrollen van de software) zo behandeld worden. gulp is zelf ook een npm bibliotheek en het is dus triviaal om het te installeren (npm install zoals hierboven). Travis CI Er wordt gebruik gemaakt van een continuous intergration server, met name Travis CI 3. Deze server voert na elke push op github de tests (npm 1 https://www.npmjs.org 2 3 https://travis-ci.org 17

19 test) uit en maakt een verslag op. Dit zorgt ervoor dat er steeds recente testdata is en dat van elke gefaalde test geweten is door welke commit hij veroorzaakt wordt. Bugtracker Github bevat standaard een bugtracker die eenvoudig in gebruik is. Deze laat zowel teamleden als anderen toe om bugs en issues aan te kaarten. In de interface van github is het bovendien eenvoudig om bepaalde code aan bugs en bugfixes te linken wat alles erg overzichtelijk maakt. Pubdig zal van deze bugtracker gebruik maken doorheen het project. Node.js Dit is de server software waarop dit systeem draait. Node.js evalueert javascript en biedt de mogelijkheid om http requests te verwerken. Dit is de meest gebruikte server software die gebruik maakt van javascript (wat een beperking van dit project is). Er zijn heel erg veel uitbreidingen en bibliotheken voor deze software wat het een logische keuze maakt. 7.2 Bibliotheken Doorheen dit project zal gebruik gemaakt worden van verschillende bibliotheken. De meeste hiervan zijn niet van fundamenteel structureel belang voor het project. Ze bieden enkel implementaties voor bepaalde functionaliteit zodat deze niet door het pubdig team heruitgevonden moeten worden (bijvoorbeeld een bibliotheek die met de SQL database praat) en zouden in principe uitwisselbaar moeten zijn. Sommige bibliotheken bieden echter meer dan enkel dit, ze bieden ook een structurele meerwaarde en bieden een architectuur aan waarmee de projecten kunnen worden opgebouwd. Er wordt gebruik gemaakt van twee zulke bibliotheken: Express voor de backend een React.js voor de frontend. Express Express is een infrastructuurlaag bovenop degene die reeds aanwezig is in node.js en die veel extra voordelen biedt. Express deelt de backend functionaliteit op in verschillende handlers die elk verantwoordelijk zijn voor het behandelen van http-requests die gebeuren naar de hun eigen route (url). Daarbovenop voorziet Express ook nog het concept van middleware: dit zijn functies die alle requests manipuleren, ongeacht naar welke route ze uiteindelijk gestuurd worden. Deze structuur promoveert twee dingen: er is een strikte scheiding van verantwoordelijkheid tussen de verschillende handlers en routes en code-duplicatie wordt expliciet tegengegaan door de gemeenschappelijke code in de middleware te stoppen. React.js De belangrijkste bibliotheek die aan de frontend gebruikt zal worden is React.js 4 Dit is een bibliotheek die het schrijven van UI-code vereenvoudigt door het concept van componenten te introduceren

20 De user interface is een van de belangrijkste verantwoordelijkheden van de frontend code en het is dus belangrijk hiervoor een goede structuur te hebben. React helpt hierbij door de verantwoordelijkheden op te splitsen in de componenthiërachie. Elke component heeft als het ware slecht een verantwoordelijkheid: zijn eigen toestand bewaren en weten hoe hij zichzelf rendert (tekent). De resulterende structuur gelijkt sterk op die van het Chain-of-command patroon dat reeds bekend is in de wereld van de computerwetenschappen. Elke component heeft een bepaalde levenscyclus en het is aan de programmeur om voor elke component voor elke stap in de cyclus een implementatie te geven. Omdat elke component aan dezelfde eisen voldoet zijn componenten erg vrij te samen te stellen (hun interface is steeds dezelfde). React biedt bovenop deze conceptuele aspecten ook faciliteiten om eenvoudig html te genereren van bepaalde data en dit op een efficiënte wijze. Dit neemt een groot deel van de zorgen van de frontend programmeurs weg zodat deze zich kunnen concentreren op belangrijkere zaken. Bovendien kunnen de componenten ook in de backend gebruikt worden om daar de html te renderen. Dit voorkomt dat er code-duplicatie ontstaat. 7.3 Quality assurance plan Op de vergaderingen wordt er besproken of iedereen zijn taken heeft kunnen voltooien. Indien er taken niet zijn uitgevoerd of voltooid, wordt de persoon in kwestie bijgestuurd door de project manager en/of wordt er besproken met het team hoe deze persoon ondersteund kan worden, om zo terug op schema te geraken Documenten Er worden 4 documenten opgeleverd per iteratie die door telkens een andere persoon worden opgesteld. Deze 4 documenten zijn het SPMP, STD, SRS, SDD, en als onderdeel van het SPMP: het SQAP en SCMP. Omdat ieder document opgesteld wordt door zijn respectievelijke verantwoordelijke, zijn er door de Quality Assurance Manager standaarden vastgelegd i.v.m structuur en opmaak. Deze richtlijnen leggen vast dat alle documenten geschreven worden in LaTeX en hun structuur, opmaak, spelling en zinsbouw voor de definitieve oplevering nog eens moet worden gecontroleerd door de Quality Assurance Manager. Hiervoor moeten er uiteraard interne deadlines worden vastgelegd, ruim voldoende voor de officiële deadline, die de Quality Assurence Manager de tijd geeft om alles te controleren of indien nodig in te grijpen. Alle documenten worden verzameld op Github. Wanneer een document klaar is volgens de verantwoordelijke wordt dit gecommuniceerd via onze communicatiekanalen en kan de Quality Assurence Manager aan zijn controle beginnen. Het is de verantwoordelijkheid van de Quality Assurance Manager om documenten te corrigeren. Na goedkeuring van de documenten worden deze als voltooid beschouwd en wordt dit wederom gecommuniceerd via onze communicatiekanalen. 19

21 7.3.2 Broncode Documentatie en commentaar Er wordt verwacht dat de programmeurs kwalitatieve code schrijven, d.w.z. mooie, leesbare code met voldoende commentaar. Bovendien moet code voldoende gedocumenteerd worden d.m.v. een complete documentatie. Samen met het commentaar bij de broncode moet deze documentatie voldoende zijn voor de Quality Assurance Manager om code te lezen en te begrijpen. Wanneer de programmeur zijn vooropgestelde opdracht heeft afgewerkt, wordt de code gecontroleerd door de Quality Assurence Manager. Wanneer er iets onduidelijk is in de code, moet de Quality Assurence Manager, met de programmeur in kwestie, in overleg treden om deze onduidelijkheden uit te klaren. Wanneer de code niet voldoet aan de vooropgestelde eisen, zal de programmeur desondanks nog moeten proberen de vooropgestelde eisen te behalen door zijn code of commentaar te verbeteren. Testing De Quality Assurance Manager staat in voor het nakijken van alle tests en zal er op toezien dat er voldoende geautomatiseerde tests aanwezig en valabel zijn. Er wordt gebruik gemaakt van het testingframework Mocha en wordt verder ondersteund door Chai en Sinon. Uiteraard wordt er ook op toegezien dat alle tests slagen en geheel voldoen aan het Software Test Document (STD). Dit wil zeggen dat ook de tests van een hoge kwaliteit moeten zijn. Ze moeten dus aan dezelfde standaarden voldoen als de code. 7.4 Documentatie plan Alle documenten zijn steeds terug te vinden op de website [1] van het project. Bij elke iteratie moeten volgende documenten worden meegeleverd, in de lijst hieronder kan ook de verantwoordelijke voor dit document gevonden worden. SPMP, project manager SRS, requirement manager SDD, design manager STD, test manager In het SPMP kan ook een hoofdstuk over de configuratie worden gevonden alsook een hoofdstuk over quality assurance. Deze vervangen het SCMP en SQAP. Deze hoofdstukken worden opgesteld door respectievelijk de configuration manager en de quality assurance manager. Voor elke vergadering wordt steeds een klein verslag opgesteld. Dit bevat telkens agendapunten en TODO s die voor aanvang van de vergadering worden aangemaakt (meestal op de vergadering ervoor). Tijdens de vergadering wordt het verslag dan aangevuld met de zaken die zijn besproken op deze vergadering. Dit document wordt opgesteld door de secretaris. De code zal gedocumenteerd worden volgens de JSdoc [4] standaard. Er is een intern document gemaakt zodat de documentatie van de code consistent is bij elk teamlid. 20

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 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 Quality Assurance Plan

Software Quality Assurance Plan FACULTEIT WETENSCHAPPEN Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie Datum Auteur Commentaar 0.1 09/11/2010 Jeroen Van den haute Eerste versie 0.2 12/11/2010

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

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

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

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

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 Faculty of Applied Science Software Project Management Plan Beerend Ceulemans May 19, 2011 Version 0.7 Team Contact Info Beerend Ceulemans Michiel De Keyser Jeroen Heymans Georgi Nikolov Reinert Roux Ruben

Nadere informatie

FUMAGGO WEB SOLUTIONS

FUMAGGO WEB SOLUTIONS FUMAGGO WEB SOLUTIONS Aanpassen design partijenwijzer.nl Offerte voor ProDemos Den Haag Fumaggo Web Solutions Lammenschansweg 93, 2313 DK Leiden KvK Rijnland 52202992 Leiden, 20 juni 2012 2 1 Introductie

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

FUMAGGO WEB SOLUTIONS

FUMAGGO WEB SOLUTIONS FUMAGGO WEB SOLUTIONS Aanpassen design stemexamen.nl Offerte voor ProDemos Den Haag Fumaggo Web Solutions Lammenschansweg 93, 2313 DK Leiden KvK Rijnland 52202992 Leiden, 19 juni 2012 2 1 Introductie ProDemos

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

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

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

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

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

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

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

Agile werken: zó doen we dat

Agile werken: zó doen we dat Agile werken: zó doen we dat Bij Freshheads werken we graag volgens de Agile aanpak. De voordelen? Verhoogde efficiëntie en flexibiliteit, snellere resultaten en grotere betrokkenheid. Maar hoe gaat het

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

Howto Subversion. 1. Subversion structuur en uitleg

Howto Subversion. 1. Subversion structuur en uitleg 1. Subversion structuur en uitleg Op de Adwise VDS server staan de repositories die gebruikt kunnen worden. Een subversion repository bevat alle projecten gerelateerd aan de betreffende repository. Adwise

Nadere informatie

Technisch ontwerp. Projectteam 6. Project "Web Essentials" 02 april 2009. Versie 2.1.0

Technisch ontwerp. Projectteam 6. Project Web Essentials 02 april 2009. Versie 2.1.0 Projectteam 6 Faculteit Natuur en Techniek Hogeschool Utrecht Projectleider: Hans Allis, hans.allis@student.hu.nl Technisch ontwerp Project "Web Essentials" 02 april 2009 Versie 2.1.0 Teamleden: Armin

Nadere informatie

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB Connect Social Business Plan van Aanpak voor mijn stage bij ConnectSB Joey Kaan September 28, 2014 Inhoudsopgave 1 Achtergronden 1 2 Probleemstelling & Doelstelling 2 2.1 Leren Professioneel Functioneren..................

Nadere informatie

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB Connect Social Business Plan van Aanpak voor mijn stage bij ConnectSB Joey Kaan September 29, 2014 Inhoudsopgave 1 Achtergronden 1 2 Probleemstelling & Doelstelling 2 2.1 Leren Professioneel Functioneren..................

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

Projectdocument Minecraft Mod Builder

Projectdocument Minecraft Mod Builder Projectdocument Minecraft Mod Builder Projectgroep Twintro 11 december 2015 Inhoudsopgave 1 Probleemstelling 2 2 Productbeschrijving 2 3 Requirements analyse 3 3.1 Functional requirements................................

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

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

Inhoud. Introductie tot de cursus

Inhoud. Introductie tot de cursus Inhoud Introductie tot de cursus 1 De functie van de cursus 7 2 De inhoud van de cursus 7 2.1 Voorkennis 7 2.2 Leerdoelen van de cursus 8 2.3 Opbouw van de cursus 8 3 Leermiddelen en wijze van studeren

Nadere informatie

VERENIGINGSWIJZER.NL PROJECTPLAN

VERENIGINGSWIJZER.NL PROJECTPLAN Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen Project Multimedia Peter van Ulden Studentnr. 1494759 VERENIGINGSWIJZER.NL PROJECTPLAN INHOUDSOPGAVE 1 Inleiding...3 2 Project omschrijving...4

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

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

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

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

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

10. Single Page Applications

10. Single Page Applications WHITEPAPER IN 5 MINUTEN M E I 2 0 1 4 10. Single Page Applications Introductie De wereld verandert snel en gebruikers openen je site of applicatie steeds minder met een traditionele browser. Een site of

Nadere informatie

Testomgevingen beheer

Testomgevingen beheer Testomgevingen beheer Testen brengt het verwachte resultaat en de huidige toestand bij elkaar. Het geeft aanknopingspunten om de planning te maken, het product te verbeteren en om zorgen bij belanghebbenden

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

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

Handleiding Reinder.NET.Tasks.SQL versie 2

Handleiding Reinder.NET.Tasks.SQL versie 2 Handleiding Reinder.NET.Tasks.SQL versie 2 Reinder Stolte Tramstraat 33 8771RR Nijland Inhoudsopgave 1 Algemeen... 2 2 Installeren en configureren... 3 3 Taken instellen... 4 3.1 Taskname (Taaknaam) verplicht

Nadere informatie

VERENIGINGSWIJZER.NL FINAL DOCUMENT

VERENIGINGSWIJZER.NL FINAL DOCUMENT Vrije Universiteit Amsterdam Faculteit der Exacte Wetenschappen Project Multimedia Peter van Ulden Studentnr. 1494759 VERENIGINGSWIJZER.NL FINAL DOCUMENT INHOUDSOPGAVE 1 Inleiding...3 2 Aanpak & Techniek...4

Nadere informatie

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB

Connect Social Business. Plan van Aanpak voor mijn stage bij ConnectSB Connect Social Business Plan van Aanpak voor mijn stage bij ConnectSB Joey Kaan September 21, 2014 Inhoudsopgave 1 Achtergronden 4 2 Probleemstelling & Doelstelling 5 2.1 Leren Professioneel Functioneren..................

Nadere informatie

Connect Social Business

Connect Social Business Connect Social Business Joey Kaan September 2014 Inhoudsopgave 1 Achtergronden 4 2 Probleemstelling & Doelstelling 5 2.1 Leren Professioneel Functioneren.................. 5 2.2 Facebook API leren door

Nadere informatie

Nederlandse samenvatting (Dutch summary)

Nederlandse samenvatting (Dutch summary) Nederlandse samenvatting (Dutch summary) Ditproefschriftpresenteerteen raamwerk voorhetontwikkelenvanparallellestreaming applicaties voor heterogene architecturen met meerdere rekeneenheden op een chip.

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

Beschrijving functioneel en technisch design van de website

Beschrijving functioneel en technisch design van de website Bespreking Punten: Beschrijving functioneel en technisch design van de website Nr. Punt 1 Student 2 Bedrijf 3 Algemene lay out 4 Technologieën 5 Webruimte en datatrafiek 1. Student Registratie Bij de registratie

Nadere informatie

Ministerie van Infrastructuur en Milieu Beheerst naar beheer

Ministerie van Infrastructuur en Milieu Beheerst naar beheer Document D-2 Ministerie van Infrastructuur en Milieu Beheerst naar beheer Versie 1.0 Datum 15 juli 2014 Status Definitief Colofon Versie 1.0 Contactpersoon Paul Leunissen M 06-5250 6691 Paul.Leunissen@minienm.nl

Nadere informatie

Design Data Management voor FPGA ontwikkeling

Design Data Management voor FPGA ontwikkeling Design Data Management voor FPGA ontwikkeling Al snel heb je bij electronica ontwikkeling met Design Data Management te maken, zo ook bij FGPA ontwikkeling. Er wordt immers code gegenereerd die beheerd

Nadere informatie

Grafisch ontwerp. Referenties. https://developers.google.com/webmasters/mobile-sites/ http://www.bluetrainmobile.com/mobile-showcase

Grafisch ontwerp. Referenties. https://developers.google.com/webmasters/mobile-sites/ http://www.bluetrainmobile.com/mobile-showcase Mobiel Datanose Op dit moment is mobiel datanose niet goed gedaan; je krijgt gewoon de site te zien zoals je het te zien krijgt op pc's of laptops. Maar vaak heb je het probleem dat je op je mobiel moet

Nadere informatie

Uitgebreid voorstel Masterproef Informatica

Uitgebreid voorstel Masterproef Informatica HoGent Uitgebreid voorstel Masterproef Informatica Titel van het project: Optimalisatie & ontwikkeling van een gegevenstransfertool voor Business Intelligence-gebruikers Datum : 01/11/2012 Naam student

Nadere informatie

Wijzigingen volledig onder controle en geborgd

Wijzigingen volledig onder controle en geborgd Installation Management Platform IMProve 2014 is het ultieme hulpmiddel om het beheer van uw (terminal) serverfarm continu, stap voor stap, op een hoger niveau te brengen. Gedocumenteerd, geborgd en reproduceerbaar

Nadere informatie

Zelftest Java concepten

Zelftest Java concepten Zelftest Java concepten Document: n0838test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA CONCEPTEN Om de voorkennis nodig

Nadere informatie

Inhoudsopgave. Hoofdstuk 1: Ant...4

Inhoudsopgave. Hoofdstuk 1: Ant...4 Inhoudsopgave Hoofdstuk 1: Ant...4 1.1 Inleiding...4 1.2 Ant installeren...5 1.3 Ant gebruiken...7 1.3.1 Een project maken...7 1.3.2 Mijn eerste Ant-script...10 1.3.2.1 Projects...10 1.3.2.2 Targets...11

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

BDD/Gherkin. Een introductie

BDD/Gherkin. Een introductie BDD/Gherkin Een introductie Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. BDD... 4 3. Gherkin... 5 4. BDD-Tools... 6 5. Voordelen... 7 6. Benodigde kennis en vaardigheden...

Nadere informatie

Informatica 2 Studiehandleiding

Informatica 2 Studiehandleiding Informatica 2 Studiehandleiding Embedded Systems Engineering Groep: ES1D ir drs E.J Boks 25-02-2010 Inhoud 1 Inleiding... 2 2 Doelstelling... 3 3 Beoordeling... 4 4 Eisen aan het verslag... 6 Voorbeeld

Nadere informatie

Vincent. Hierbij het profiel van.net developer Vincent uit Delft. Vincent presenteert zichzelf graag door onderstaande drie vragen te beantwoorden:

Vincent. Hierbij het profiel van.net developer Vincent uit Delft. Vincent presenteert zichzelf graag door onderstaande drie vragen te beantwoorden: Contact the Agency Laurens Simonse 06 22801031 laurens@rockstars-it.nl Bart Nijskens 06 52302211 bart@rockstars-it.nl Vincent Hierbij het profiel van.net developer Vincent uit Delft. Vincent presenteert

Nadere informatie

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Henrik Rexed & Joerek van Gaalen Voorstellen Joerek van Gaalen Performancetest specialist sinds 2005 Sinds 2014 CTO Computest Voorstellen

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

Project plan. Erwin Hannaart Sander Tegelaar 61849 62407

Project plan. Erwin Hannaart Sander Tegelaar 61849 62407 Project plan Erwin Hannaart Sander Tegelaar 61849 62407 I4C2 I4C1 1 Inhoudsopgave Doel en doelgroep van het project... 3 Beschrijving van het project... 4 Benodigde materialen... 5 Te verwachten resultaten,

Nadere informatie

Documentatie. InstantModules Q42. Versie 1.1

Documentatie. InstantModules Q42. Versie 1.1 Documentatie InstantModules Q42 Versie 1.1 Inhoudsopgave Inhoudsopgave... 2 Voor gebruikers... 3 InstantComment... 3 InstantTagging... 5 Voor webmasters... 9 InstantComment... 9 InstantTagging... 11 Voor

Nadere informatie

INTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer

INTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer INTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer Van toepassing op : BRL SIKB 0100, versie 4.0-29 juni 2005 Versie en datum vaststelling : 1, 3 september 2009 Datum in werking treden : 7 september

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

Project 2 Maze Driver. Plan van Aanpak TI1A

Project 2 Maze Driver. Plan van Aanpak TI1A Plan van Aanpak TI1A 1 Inhoudsopgave Achtergronden... 3 Projectopdracht... 4 Projectactiviteit... 5 Projectgrenzen... 6 Tussenresultaten... 7 Kwaliteit... 8 Projectorganisatie... 9 Planning... 10 Kosten

Nadere informatie

Xampp Web Development omgeving opzetten onder Windows.

Xampp Web Development omgeving opzetten onder Windows. Xampp Web Development omgeving opzetten onder Windows. Inhoudsopgave 1. Lees dit eerst... 2 2. Inleiding... 2 3. Installatie Xampp... 3 1.1 Installatie Xampp Launcher... 7 1.2 Controle geïnstalleerde bestanden...

Nadere informatie

WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING BUSINESS AGILITY ITERATIEVE AANPAK ONTWIKKELSTRAAT

WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING BUSINESS AGILITY ITERATIEVE AANPAK ONTWIKKELSTRAAT WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING Voor het bereiken van business agility is meer nodig dan een juiste architectuur en is een iteratieve aanpak essentieel. Daarvoor is

Nadere informatie

Indoor Navigation System

Indoor Navigation System Project Indoor Navigation System Onderwerp: Indoor Navigation System Document: Handleiding Ontwikkeltools Groep: EII6RTa Auteurs: 1. Jordi Betting 109277 2. Jerome Bos 113180 3. Theo Miltenburg 112883

Nadere informatie

Stage logboek. Datum Uur Omschrijving Persoon 28/jan Voorstelling van het project met Bart, Jorn, Peter, Jochen Iedereen

Stage logboek. Datum Uur Omschrijving Persoon 28/jan Voorstelling van het project met Bart, Jorn, Peter, Jochen Iedereen Stage logboek Datum Uur Omschrijving Persoon 28/jan Voorstelling van het project met Bart, Jorn, Peter, Jochen Opzetten virtual servers en installatie van de nodige programma's Doornemen van de manuals

Nadere informatie

Pijlers van Beheer. Bram van der Vos www.axisintoict.nl ict@axisinto.nl

Pijlers van Beheer. Bram van der Vos www.axisintoict.nl ict@axisinto.nl Welkom Pijlers van Beheer Bram van der Vos www.axisintoict.nl ict@axisinto.nl Waarom doe je Beheer Business perspectief Stabiliteit Security Enablen voor gebruikers Ondersteuning Technisch Perspectief

Nadere informatie

Christian Hoppenbrouwers Tools voor offshore testen Voorjaarsevent Testnet: 30 juni 2008

Christian Hoppenbrouwers Tools voor offshore testen Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Samenvatting: Christian Hoppenbrouwers Tools voor offshore testen Voorjaarsevent Testnet: 30 juni 2008 Steeds meer bedrijven offshoren hun IT activiteiten naar landen als

Nadere informatie

Technologie en Interactie 3.2: software architectuur

Technologie en Interactie 3.2: software architectuur Technologie en Interactie 3.2: software architectuur Manual IAM-TDI-V2-Technologie en Interactie. Jaar 0809 blok 2 Oktober 2008 Fons van Kesteren 1/8 Inhoud Technologie en Interactie 3.2: software architectuur...

Nadere informatie