Software Engineering Project

Transcriptie

1 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

2 Inhoudsopgave 1. Doel Omvang Fasering Analysefase Functioneel ontwerp Technisch ontwerp Implementatie Acceptatietest Einddocumentatie en evaluatie Deadlines Beoordeling Uitgebreide fasenbeschrijving Analysefase -> Startdocument Functioneel ontwerp: gamedesign/simulatie Functioneel ontwerp: webdesign/appdesign Technisch ontwerp: gamedesign/simulatie Technisch ontwerp: webdesign Technisch ontwerp: appdesign Implementatie Testen Documentatie Logboek template

3 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 gameof simulatie te realiseren met bijvoorbeeld Greenfoot. Je kunt een dynamische website te bouwen met php en MySQL. Of bouw een nuttige app voor Android, ios of Windows Phone. 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. 3

4 2. Omvang De omvang van het project bedraagt 70 studielasturen (SLU) per persoon. Dit is inclusief de ± 40 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 je geïnvesteerde tijd verantwoorden en 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 van 3 personen (eventueel 4). De groepsgrootte is uiteraard van invloed op de vereiste omvang van het project. 4

5 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. Het mijlpaal product van de vorige fase dient als input voor 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. 3.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 bouwen van een game 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 of simulatie 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? Waar is het mee te vergelijken? Bij een site of app beschrijf je het doel van het product, 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 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 (+- 1 a 2 kantjes) o Projectplanning met taakverdeling o Logboeken Beoordeling: 4 punten 5

6 3.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 die je in dit document moet beantwoorden zijn Wat kan het?, Welke onderdelen bevat het, Hoe ziet het eruit?, Hoe wordt het gebruikt/bediend?, Welke randvoorwaarden zitten eraan?, Voor wie is het bedoeld?. 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.3 Technisch ontwerp Het technisch ontwerp is bedoeld als handleiding voor de programmeurs en grafisch ontwerpers. Er zit wat overlap met het Functioneel ontwerp, maar het is specifiek op de implementatie gericht. Dat wil zeggen: Hoe is de code ingedeeld? Welke concrete waarden en afspraken zijner voor de grafische elementen? Bijvoorbeeld voor de game: Welke objecten (karakters, items, vijanden, etc.) zitten er in het spel en hoe hangen deze samen (objectstrcutuur)? Hoe gedragen de objecten zich en welke eigenschappen hebben ze? Hoe werkt de besturing en input precies? Welke rooms/levels zijn er? Welke afmetingen, kluerenplatten etc. zijn er voor de sprites en andere grafische elementen? Mijlpaalproducten: - Technisch ontwerpdocument - Logboeken Beoordeling: 10 punten 3.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 6

7 3.5 Acceptatietest In deze fase ga je testen of het product aan je opgestelde eisen voldoet. Je stelt een testschema op waarin je alle onderdelen van je product test aan de hand van de eisen uit fase 2 (en 3). Je werkt eventuele bugs en verschillen met de requirements zo veel mogelijk nog weg. Als dat niet lukt, verantwoordt je waar de verschillen vandaan komen. Mijlpaalproducten: - Acceptatietest rapport met toelichting - Logboeken Beoordeling: 8 punten 3.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 7

8 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. Startdocument: 10 januari 2. Functioneel ontwerp: 31 januari 3. Technisch ontwerp: 21 februari 4. Implementatie: 10 april 5. Testrapport: 15 april 6. Einddocumentatie: 15 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. 8

9 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 en algemeen nut o Overeenstemming met ontwerp Groepsbeoordeling: Ik ga er vanuit dat alle groepsleden een evenredig aandeel hebben in het eindproduct. Het is geen probleem te specialiseren, maar de inzet en bijdrage zou vergelijkbaar moeten zijn. Normaal gesproken krijgt een groepje als geheel hetzelfde cijfer. Indien nodig kan Wt hier echter van afwijken als blijkt dat het aandeel te veel verschilt. Als je zelf problemen in je groepje signaleert, geef dit op tijd aan. Essentieel is dat je eigen logboek goed is bijgehouden. Dit dient als bewijslast bij eventuele onenigheid. 9

10 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 een game: 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 (Je mag de klant zijn eisen op papier laten zetten en als bijlage bijvoegen). Deze beschrijving is +- 1 kantje lang. Je maakt met dit document aan Wt duidelijk wat voor product je gaat maken, zonder te specifiek op details in te gaan. Dit geeft Wt 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 o Werkt aan het programmeren van het spel/de website 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 - 10

11 6.2.1 Functioneel ontwerp: gamedesign/simulatie Het functioneel ontwerp beschrijft alles dat je spel/simulatie kan. Regels en opbouw. Bepaal hoe het 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. Etc, etc. Het ontwerp van de gebruikersinterface. Hoe ziet de interface van het eruit (layout, kleuren, tekenstijl, etc)? Welke opties zijn instelbaar? Welke menu;s en schermen zijn er? 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? Hoe is het verloop van het spel? Welke vijanden/items/medespelers etc zijn er en wat doen ze? 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 11

12 6.2.2 Functioneel ontwerp: webdesign/appdesign In deze fase stel je gedetailleerde eisen op voor alle onderdelen van je product. Beschrijf in ieder geval de volgende zaken: Design. Beschrijf minstens de volgende dingen: kleurgebruik, lettertype(n), lay-out (kolommen, menu s, etc), eventuele logo s etc. Bij een app beschrijf je ook de bediening (swipen, tappen, menu 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. Ook de meeste apps bevatten een database om hun gegevens in op te slaan. Functionele eisen. Beschrijf gedetailleerd de functionaliteit van de website/app. 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 of beschrijf de verschillende schermen/views van je app. Geef met een sitemap inzicht in de structuur van de pagina s. Vertel kort iets over de inhoud van elke pagina/view. Systeemeisen. Beschrijf de systeemeisen: eventuele browsereisen, resolutie, flash, android of ios versie, etc Technisch ontwerp: gamedesign/simulatie 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. Vertel ook welke tools en hulpmiddelen je gebruikt bij de implementatie. 12

13 6.3.2 Technisch ontwerp: webdesign 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, jquery, ) - Eisen aan de webserver (dataverkeer, opslagruimte, aanwezige technieken (php versie mysql versie, ) - 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...). Hoe ziet je mappenscturtuur eruit (waar laat je plaatjes en andere ingevoegde resources? - 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 Technisch ontwerp: appdesign 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. Android Studio of Eclipse) - Eisen aan de devices van de gebruikers (Android/iOS versie, schermafmeting/resolutie, hoeveelheid geheugen, tablets, telefoons of allebei? etc.) 13

14 Specifieke technische eisen: Dit geeft een beschrijving van de programmeerstructuur van de app en de programmeerdetails van de specifieke onderdelen. Tevens beschrijf je alle interactie van je app met de eventuele database. Bijvoorbeeld: - Wat is de tabelstructuur van de database (maak een strokendiagram o.i.d.). Let goed op redundantie, isolatie en inconsistentie - Welke query s zijn er nodig om gegevens uit de database te halen en ze bij te werken? - Welke in- en output kan de gebruiker leveren? - Is er externe input? (GPS, Wifi, bluetooth, etc) - Gebruik je bibliotheken/sdk s en zo ja welke (bijv. Goolge maps, Twitter, etc.) - NB: Dit kan lastig zijn als je nog geen of weinig ervaring hebt met appontwerp. 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 interactie met de buitenwereld en de gebuiker. 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. 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 met een toelichting. 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. 14

15 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: Activiteit: Tijd: Datum: Globaal ontwerp Op internet gezocht voor 2 uur spelideeën Globaal ontwerp Rolverdeling gemaakt 0,5 uur Functioneel ontwerp Technisch ontwerp Implementatie Testen Documentatie 15