Software Engineering Project

Software Engineering Project We sluiten het informaticaprogramma af met een groot eindproject. Zie het als je “proeve van bekwaamheid” voor informatica. In dit document staat het verloop en de beoordeling van het project beschreven. Eerst kijken we naar de globale opzet en eisen. Verderop (paragraaf 6) gaat dit document in detail in op de verschillende fasen en de bijbehorende mijlpaalproducten. Op de informatica site vind je voorbeelden van de verschillende mijlpaaldocumenten.

1

1. Doel Je gebruikt de vaardigheden die je bij Informatica hebt opgedaan (programmeren, ontwerpen, graphics, omgaan met software, projectwerk, etc) om een groot informatica groepsproject tot een goed einde te brengen. Je kunt kiezen om een uitgebreide game te realiseren met Gamemaker of met Greenfoot. Je kunt een dynamische website te bouwen met php, of met behulp van een CMS zoals Joomla. Misschien heb je zelf wel een idee voor een tof eindproject (uiteraard onder goedkeuring van Wt) Je werkt hierbij projectmatig, zodat je ook vaardigheden opdoet in het ontwikkelen van software in projectvorm. Naast het reguliere project is er ook de mogelijkheid om het “NAND to Tetris” project te doen. Dit is een lesmodule van de Harvard University die in vogelvlucht alle basisiprincipes van de moderne informatica behandelt. Je bouwt zelf een “virtuele”computer die je vervolgens ook nog gaat programmeren. Deze invulling vereist een hoge mate van zelfstandigheid. Details van deze invulling van het eindproject spreken we in onderling overleg af en valt grotendeels buiten deze documentatie.

2

2. Omvang De omvang van het project bedraagt 70 studielasturen (SLU) per persoon. Dit is inclusief de ± 42 lessen die je op school hebt om er aan te werken. Dat is een aardige hoeveelheid uren. De grootste kunst is dus om goed te plannen, goede afspraken te maken binnen je groepje en je daaraan te houden. Houd ook per persoon een logboek bij. Dit is nu belangrijker dan ooit. Met een logboek kun je een eventuele onevenredige tijdsbesteding binnen de groep aantonen. Dit voorkomt conflicten tegen het einde van het project. Zonder logboeken is dit heel lastig hard te maken. Je doet dit project in groepjes 3 personen (eventueel 4). De groepsgrootte is uiteraard van invloed op de vereiste omvang van het project.

3

3. Fasering Een van de belangrijkste kenmerken van een project is dat het gefaseerd wordt uitgevoerd. De volgende fase begint pas als de huidige fase (met het bijbehorende mijlpaalproduct) is afgesloten. Je laat je mijlpaalproduct eerst door de docent goedkeuren voordat je verder gaat met de volgende fase. We verdelen dit project in 6 fasen die we hier globaal beschrijven. Zie paragraaf 6 voor een uitgebreidere beschrijving van elke fase. Op de informatica website staat een voorbeeld van elk mijlpaaldocument. 1. Analysefase Bij software engineering wordt in de analysefase beschreven wat de eisen van de opdrachtgever zijn en hoe globaal gezien het product eruit komt te zien. Bij het gamemaker project heb je (waarschijnlijk) geen opdrachtgever, dus stel je de eisen zelf op. Als je wel een klant hebt (voor website bijvoorbeeld), vraag deze klant dan zo nauwkeurig mogelijk te beschrijven wat zijn eisen zijn. In deze fase stel je een Startdocument op (dit is je mijlpaalproduct). Hierin beschrijf je globaal wat je gaat maken. Eisen van de klant (of van jezelf) worden opgesomd. Bij een spel beschrijf je de globale opzet van je spel. Wat voor type spel is het? Wat is de setting en het verhaal? Wat is het doel van het spel? Bij een site beschrijf je het doel van de site, de doelgroep, de globale functionaliteit, etc. Tevens maak je in deze fase een planning voor het project. Deze planning bevat minstens de deadlines die verderop in dit document worden genoemd. In je planning neem je ook de taakverdeling op. Je maakt zo in een vroeg stadium al behoorlijk concreet wat de invulling van je project gaat zijn en je geeft mij in een vroeg stadium al een beeld geven van de inhoud en de opzet van jullie project. Dit is belangrijk zodat ik in de volgende fase beter kan begeleiden en adviseren. Mijlpaalproducten: - Startdocument met daarin o Globale projectomschrijving en eisen o Projectplanning met taakverdeling - Logboeken Beoordeling: 4 punten

2. Functioneel ontwerp In het Functioneel Ontwerp ga je de globale beschrijving van het startdocument verder uitdiepen. Je gaat hier alle functies (vandaar de naam) beschrijven van je product. De vragen 4

die je in dit document moet beantwoorden zijn “Wat kan het?”, “ Hoe wordt het gebruikt/bediend?”, “Welke randvoorwaarden zitten eraan?”, “Voor wie is het bedoeld?” , “Hoe ziet het eruit?”, “Uit welke onderdelen bestaat het?” Dit document wordt op het einde gebruikt om te checken of alle functionaliteit ook daadwerkelijk geïmplementeerd is Mijlpaalproducten: - Functioneel ontwerpdocument - Logboeken Beoordeling: 10 punten

3. Technisch ontwerp Het technisch ontwerp is bedoeld als handleiding voor de programmeurs. Er zit wat overlap met het Functioneel ontwerp, maar het is specifiek op de implementatie gericht. Dat wil zeggen: Hoe is de code ingedeeld. Bijvoorbeeld voor de game: Welke objecten (karakters, items, vijanden, etc.) zitten er in het spel? Hoe gedragen de objecten zich en welke eigenschappen hebben ze? Hoe kun je je held besturen. Welke rooms zijn er? Welke sprites zijn er? Etc.

Mijlpaalproducten: - Technisch ontwerpdocument - Logboeken Beoordeling: 10 punten

4. Implementatie Met het Technisch (en Functioneel) ontwerp in de hand ga je je product maken. Je houdt je zo precies mogelijk aan je ontwerp. Eventuele afwijkingen zul je moeten verantwoorden. Mijlpaalproducten: - Een geïmplementeerd product - Logboeken Beoordeling: 54 punten

5

5. Acceptatietest In deze fase ga je testen of het product aan je requirements voldoet. Je stelt een testschema op waarin je alle onderdelen van je spel test aan de hand van de requirements uit fase 2 en 3. Je werkt eventuele bugs en verschillen met de requirements weg. Mijlpaalproducten: - Acceptatietest rapport - Logboeken Beoordeling: 8 punten

6. Einddocumentatie en evaluatie In deze laatste fase verzamel je de geschreven documenten uit de vorige fasen in een projectverslag. Aan dit verslag voeg je een evaluatie toe waarin je ingaat op het verloop van het project, de samenwerking, de problemen die je bent tegengekomen, de oplossingen die je daarvoor gevonden hebt etc. Ook voeg je het logboek toe aan het projectverslag. Hierin staat de tijdbesteding van de groepsleden aan de verschillende onderdelen beschreven. Mijlpaalproducten: - Net vormgegeven projectverslag bestaande uit o Startdocument o Functioneel ontwerp o Technisch ontwerp o Wijzigingsdocument o Testrapport o Project evaluatie - Logboeken Beoordeling: 4 punten

6

4. Deadlines Om de voortgang van je project te waarborgen moet je de volgende deadlines in je projectplanning opnemen (Voeg naast deze verplichte deadlines zelf tussentijdse deadlines toe. Dit help om je groepje op schema te houden): 1. 2. 3. 4. 5. 6.

Startdocument: Functioneel ontwerp: Technisch ontwerp: Implementatie: Testrapport: Einddocumentatie:

18 december 24 januari 7 februari 16 april 16 april 16 april

Op (of voor) deze deadlines lever je de mijlpaalproducten van de fase in bij mij (per mail). Te laat inleveren leidt tot puntaftrek voor de beoordeling van de betreffende mijlpaal. Bij te grote onvolkomenheden kan worden gevraagd een verbeterde versie van een document in te leveren.

7

5. Beoordeling De beoordeling is als volgt opgebouwd: -

Projectmanagement (36 punten) o Startdocument (4 punten) o Functioneel ontwerp (10 punten) o Technisch ontwerp (10 punten) o Testrapportage (8 punten) o Eindverslag/evaluatie (4 punten)

-

Eindproduct (54 punten) Gelet wordt op: o Programmeerwerk  Complexiteit  Structuur o Graphics en design o Originaliteit o Overeenstemming met ontwerp

8

6. Uitgebreide fasenbeschrijving 6.1 Analysefase -> Startdocument Globale projectbeschrijving: In het startdocument beschrijf je wat je gaat maken. Je beschrijft de globale opzet van je project. Bijvoorbeeld voor gamemaker: Wat voor type spel is het? Wat is de setting en het eventuele verhaal? Wie spelen er een (belangrijke) rol in het spel? Wat is het doel van het spel? Etc. Als je een klant hebt, verwerk je ook de eisen van de klant. Deze beschrijving is +- 1 kantje lang. Je maakt met dit document aan je docent duidelijk wat voor product je gaat maken, zonder al te specifiek op details in te gaan. Dit geeft de docent een beeld van wat je wilt maken en zo kan hij eventueel nog tips of opmerkingen erbij geven zonder dat er al veel werk verloren gaat. De specifieke details van het project beschrijf je in fase 2 en 3.

Planning en rolverdeling: Je stelt een planning op voor het verloop van het gehele project. Je neemt daarbij minstens de deadlines op zoals genoemd in paragraaf 4 (hierboven). Het is zeer verstandig om zelf extra deadlines in te lassen voor subonderdelen van je project. Met name in de implementatiefase is dit van belang. Je geeft ook aan wat de rolverdeling is binnen je groepje. Je groepje heeft verplicht een projectleider, de overige rollen kun je naar inzicht verdelen. Een groepslid kan meer dan 1 rol vervullen en je mag zelf extra rollen bedenken die voor jullie project van belang zijn. Elke rol (behalve projectleider) kan eventueel door meerdere personen vervuld worden. - Projectleider o Is aanspreekpunt naar docent o Draagt zorg voor de voortgang van het project o Zorgt voor het aanleveren van de mijlpaaldocumenten o Wijst groepsgenoten op verantwoordelijkheden en afspraken - Programmeur o Werkt aan het programmeren van het spel/de website o Draagt zorg voor het implementeren volgens de richtlijnen van het Technisch ontwerp - Grafisch ontwerper o Zorgt voor de graphics en visualisatie - Tester o Bedenkt testcases en voert deze uit o Schrijft accaptatietest rapport. - Level designer o Ontwerp de levels uit een spel - Database ontwerper o Bedenkt en implementeert de structuur van een database - … 9

6.2.1 Functioneel ontwerp: gamemaker Dit onderdeel dient als een “rule book” voor het spel. Het geeft aan welke interacties de speler met het spel kan hebben. Het zou tamelijk eenvoudig moeten zijn voor een schrijver om de specificaties van het spel in een handleiding op te nemen dat bij een spel hoort. De aard van de specificaties hangt in enige mate af van het type spel dat je wilt gaan maken. 

Regels en opbouw. Bepaal hoe het spel begint en hoe het eindigt. En afhankelijk van je type spel bijvoorbeeld hoe schepen/tanks/units bewegen, welke soorten wapens ze hebben, hoe aangebrachte schade of hitpunten worden berekend. hoe de hoofdfiguur zich voortbeweegt in het spel.



Het ontwerp van de gebruikersinterface. Hoe ziet de interface van het spel eruit (layout, kleuren, tekenstijl, etc). Beschrijf de algemene “look and feel” van het spel. Voeg gerust meerdere schetsen toe.



Het spelen van het spel en de balans. Wat kan of kunnen de speler(s) doen? Hoe vindt er interactie plaats met de wereld van het spel? Beschrijf hoe het spel is ontworpen waardoor de speler altijd een keuze kan maken die voor hem interessant is en speelbaar. Beschrijf de besturing van het spel



Muziek en geluid. Zelfs de eenvoudigste muziek en de meest rudimentaire geluidseffecten geven het spel een ongelooflijke meerwaarde en verhoogt het speelgenot. Geef aan wat voor geluidseffecten er zijn en eventuele muziek.



Achtergrondverhaal. Indien van toepassing beschrijf je het verhaal van je spel



Characters. Welke characters en vijanden zijn er in het spel. Hoe zien ze eruit?



Levels. Beschrijf hoe de level(s) eruit zien. Geef aan welke levels je van plan bent te gaan implementeren.



Overig. Afhankelijk van je spel zijn er wellicht nog meer dingen belangrijk om te specificeren in je detailontwerp

10

6.2.2 Functioneel ontwerp: php/mysql In deze fase stel je gedetailleerde eisen op voor alle onderdelen van je website. Beschrijf de volgende zaken: 

Design. Beschrijf minstens de volgende dingen: kleurgebruik, lettertype(n), lay-out (kolommen, menu’s, etc) , eventuele logo’s etc.



Database. Beschrijf globaal het ontwerp van je database. Welke informatie komt er in de database en waar dient deze voor? De specifieke tabelstructuur beschrijf je straks in het Technisch ontwerp.



Functionele eisen. Beschrijf gedetailleerd de functionaliteit van de website. Bijvoorbeeld: o De gebruiker kan zich aanmelden als klant d.m.v. een aanmeldingsformulier o Het niet invullen van de gebruikersnaam resulteert in een foutmelding o Als bij de aanmelding de gebruikersnaam al bestaat krijgt de gebruiker enkele suggesties voor een andere gebruikersnaam. o …



Site indeling. Beschrijf de verschillende pagina’s die de website bevat. Geef met een sitemap inzicht in de structuur van de pagina’s. Vertel kort iets over de inhoud van elke pagina.



Systeemeisen. Beschrijf de systeemeisen van de server (php versie etc.) en van de gebruiker (eventuele browsereisen, resolutie, flash, etc.)

6.3.1 Technisch ontwerp: game Het technisch ontwerp is een handleiding voor de programmeur tijdens de implementatie. Je beschrijft hierin in zoveel mogelijk detail hoe het spel werkt. - Je beschrijft alle objecten en hun gedragingen en interacties - Je beschrijft alle levels - Je beschrijft alle geluiden en muziek - Je beschrijft alle functionaliteit - Je beschrijft alle menu’s en besturingselementen -… Bij deze beschrijvingen gebruik je zo veel mogelijk concrete waardes: afmetingen, formules, variabelen, etc. Je beschrijft de objectenstructuur van je game en de opbouw van je code. Er staat een voorbeeld van een Technisch Ontwerp op de informaticasite. Deze is goed qua beschrijving, maar kan beter in de technische details (waardes, formules etc.) 11

6.3.2 Technisch ontwerp: php/mysql Het technisch ontwerp is een handleiding voor de programmeur tijdens de implementatie. Dit valt uiteen in globale technische eisen en specifieke technische eisen. Globale technische eisen: - Welke programmeeromgeving gebruiken we (bv. Notepad++ en UsbWebserver) - Welke technieken (php, mysql, javascript, ajax, …) - Eisen aan de webserver (dataverkeer, opslagruimte, aanwezige technieken (php versie 5, …) - Eisen aan de browser van de eindgebruiker

Specifieke technische eisen: Dit geeft een beschrijving van de programmeerstructuur van de site en de programmeerdetails van de specifieke pagina’s. Tevens beschrijf je alle interactie van je site met de database. Bijvoorbeeld: - Hoe ziet je html eruit (divs, css, etc...) - Wat is de tabelstructuur van de database (maak een strokendiagram o.i.d.). Let goed op redundantie, isolatie en inconsistentie - Welke SQL query’s zijn er nodig om gegevens uit de database te halen en ze bij te werken? - Welke formulieren zijn er voor de gebruiker? Welke velden en database-interacties zijn gekoppeld aan deze formulieren? - Welke php bibliotheken gebruik je? - … NB: Dit kan lastig zijn als je nog geen of weinig ervaring hebt met Php en MySQL. Je docent kan je hierbij eventueel helpen. Het belangrijkste is om goed na te denken over het ontwerp van je database (tabellenstructuur), de interactie met je database (de query’s die je gaat gebruiken in combinatie met de formulieren en knoppen de je aan de gebruikers aanbiedt) en de scripts die de pagina’s hun functionaliteit geven.

6.4 Implementatie In deze fase gaat het echte implementeren van je project beginnen. Aan de hand van het ontwerp uit fase 2 en met name fase 3 ga je programmeren. Je probeert je zo nauwkeurig mogelijk aan het ontwerp te houden. Grote kans dat je tijdens het programmeren tegen problemen aanloopt die je niet had voorzien in de ontwerpfase. Het kan zijn dat je hierdoor je ontwerp moet bijstellen. Je maakt indien dit het geval is een bijlage voor het ontwerp waarin je de wijzigingen beschrijft en verantwoordt. Laat de wijzigingen in je ontwerp goedkeuren door je docent en (indien van toepassing) je klant/opdrachtgever.

12

6.5 Testen Je gaat je product uitvoerig testen aan de hand van de opgestelde documenten uit fase 2 en 3. Je stelt een testdocument op met daarin testcases voor alle belangrijke functionaliteiten van het product. Je vinkt in dit document af of je product aan elk van de eisen voldoet. Eisen waaraan niet is voldaan ga je (als er nog voldoende tijd is) proberen op te lossen. Als de problemen niet meer op te lossen zijn, beschrijf je het verschil tussen de eis en de daadwerkelijke implementatie.

6.6 Documentatie In de laatste fase bundel je alle documenten en logboeken uit de voorgaande fasen in een eindverslag. Vergeet niet eventuele wijzigingen in je ontwerp uit fase 4 bij te voegen. Tot slot voeg je nog een projectevaluatie toe waarin je het verloop van het project beschrijft en eventuele problemen (en oplossingen) waar je tegenaan bent gelopen opneemt. Als alles klaar is lever je het eindverslag samen met alle softwarebestanden in.

13

7. Logboek template Gebruik het volgende format voor je persoonlijke logboek. Dit logboek wordt bij het eind van elke fase mee ingeleverd met het mijlpaalproduct. Informatica eindproject logboek Naam: Henk de Vries Fase: Globaal ontwerp Globaal ontwerp … Functioneel ontwerp … … Technisch ontwerp … … Implementatie … … Testen … Documentatie …

Activiteit: Op internet gezocht voor spelideeën Rolverdeling gemaakt …

Tijd: 2 uur

Datum: 15-12-2012

0,5 uur …

17-12-2012 …

… … … … … … … … … … … …

… … … … … … … … … … … …

… … … … … … … … … … … …

14