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 Inhoud 1. Doel Omvang Fasering Analysefase Ontwerp Functionele Eisen Technische Uitwerking Implementatie Acceptatietest Einddocumentatie en evaluatie Deadlines Beoordeling Uitgebreide fasenbeschrijving Analysefase -> Startdocument Ontwerp: gamedesign/simulatie Ontwerp: webdesign/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 game of simulatie te realiseren met bijvoorbeeld NetLogo, PyGame of 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 in groepjes (ongeveer 3 personen), 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 basisprincipes 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 60 studielasturen (SLU) per persoon. Dit is inclusief de ± 30 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 (ongeveer) 3 personen. 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. Elke fase lever een mijlpaal product op. Het mijlpaal product van de vorige fase dient als input voor de volgende fase. We verdelen dit project in 5 fasen die we hier globaal beschrijven. Zie paragraaf 6 voor extra tips en voorbeelden bij 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. Uitgebreidere info en voorbeelden vind je in paragraaf 6 van dit document. 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: 5 punten 5

6 3.2 Ontwerp In de Ontwerpfase ga je de globale beschrijving van het startdocument verder uitdiepen. Het ontwerp bestaat uit 2 onderdelen: Functionele eisen en Technische uitwerking Mijlpaalproducten: - Ontwerpdocument - Logboeken Beoordeling: 18 punten Functionele Eisen De Functionele Eisen leggen precies vast WAT je gaat maken. Om het WAT boven tafel te krijgen, beschrijf je alle functies van je product en alle eisen die je er aan stelt. De vragen die je hiervoor moet beantwoorden zijn o.a. (afhankelijk van het gekozen project): - Wat kan het? - Wie is de doelgroep? - Welke handelingen kan de eindgebruiker verrichten en wat is hiervan het resultaat? - Wat voor input en output is er mogelijk? - Welke onderdelen bevat het? - Hoe ziet het eruit? (welke schermen, knoppen en lay-outs zijn er?) - Welke systeemeisen zitten er aan? - Deze eisen worden op het einde gebruikt (in de testfase) om te checken of alle functionaliteit ook daadwerkelijk geïmplementeerd is Technische Uitwerking De Technische Uitwerking bevat 2 onderdelen: - Oplossingen deelproblemen - Schematische opzet van de implementatie Oplossingen deelproblemen: Welke mogelijke oplossingen je hebt bedacht voor de functionele eisen. Voor de hoofdfuncties van je programma verzin je meerdere mogelijke uitwerkingen en je onderbouwt welke definitieve keuze je maakt voor je uiteindelijke product. Schematische opzet implementatie: - Maak een (schematische) opzet van de structuur van je programma en de code: o Welke Objecten en functies heb je nodig o Externe libraries o Schermlayouts / Webpagina layouts o Databaseontwerp o 6

7 - Te maken afbeeldingen, achtergronden en animaties - Te gebruiken geluidsfragmenten en fonts. Bijvoorbeeld voor de game: Welke objecten (karakters, items, vijanden, etc.) zitten er in het spel en hoe hangen deze samen (objectstructuur)? Hoe gedragen de objecten zich en welke eigenschappen hebben ze? Hoe werkt de besturing en input precies? Welke rooms/levels zijn er? Welke afmetingen, kleurenpaletten etc. zijn er voor de sprites en andere grafische elementen? 3.3 Implementatie Met het Ontwerp in de hand ga je je product maken. Je houdt je zo precies mogelijk aan je ontwerp. Eventuele afwijkingen zul je achteraf moeten verantwoorden. Mijlpaalproducten: - Een geïmplementeerd product - Logboeken Beoordeling: 55 punten 3.4 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 de Ontwerpfase. Je werkt eventuele bugs en verschillen met de requirements zo veel mogelijk nog weg. Als dat niet lukt, verantwoord je waar de verschillen vandaan komen. Mijlpaalproducten: - Acceptatietest rapport met toelichting - Logboeken Beoordeling: 8 punten 3.5 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 7

8 o Startdocument o Functioneel ontwerp o Technisch ontwerp o Wijzigingsdocument o Testrapport o Project evaluatie - Logboeken Beoordeling: 4 punten 8

9 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 in je planning. Dit helpt om je groepje op schema te houden): 1. Startdocument: 29 januari 2. Ontwerp: 20 februari 3. Implementatie: 3 april 4. Testrapport: 10 april 5. Einddocumentatie: 10 april Op (of voor) deze deadlines lever je de mijlpaalproducten van de fase in bij mij (per magistermail). 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. 9

10 5. Beoordeling De beoordeling is als volgt opgebouwd: - Projectmanagement (35 punten) o Startdocument (5 punten) o Ontwerp (18 punten) o Testrapportage (8 punten) o Eindverslag/evaluatie (4 punten) - Eindproduct (55 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 in principe vanuit dat alle groepsleden een evenredig aandeel hebben in het eindproduct. Het is geen probleem om je 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. 10

11 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. 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). 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? Deze globale 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. Zo kan Wt 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. 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. 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 - 11

12 6.2.1 Ontwerp: gamedesign/simulatie Functionele Eisen De Functionele Eisen leggen precies vast WAT je gaat maken. Om het WAT boven tafel te krijgen, beschrijf je alle functies van je product en alle eisen die je er aan stelt. De vragen die je hiervoor moet beantwoorden zijn o.a. (afhankelijk van het gekozen project): - Wat kan het? - Wie is de doelgroep? - Welke handelingen kan de eindgebruiker verrichten en wat is hiervan het resultaat? - Wat voor input en output is er mogelijk? - Welke onderdelen bevat het? - Hoe ziet het eruit? (welke schermen, knoppen en lay-outs zijn er?) - Welke systeemeisen zitten er aan? - Voor een spel of simulatie kun je concreet denken aan o.a.: Regels en opbouw. Bepaal hoe het begint en hoe het eindigt. En afhankelijk van je type spel/simulatie 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 grafisch ontwerp. Hoe ziet de interface van het spel eruit? Welke menu s en schermen zijn er? Beschrijf de algemene look and feel van het spel? (layout, kleuren, tekenstijl, etc.)? Voeg gerust meerdere schetsen toe. Balans. Wat kan of kunnen de speler(s)/gebruikers 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 Technische Uitwerking De Technische uitwerking is een handleiding voor de programmeurs voor tijdens de implementatie. Tevens toon je er mee aan dat je verschillende oplossingen hebt bedacht om aan de Functionele Eisen te voldoen. Voor de belangrijkste functies laat je zien dat je meerdere oplossingen/uitwerkingen hebt bedacht en je onderbouwt je definitieve keuzes. Je beschrijft verder in zo veel mogelijk detail hoe het spel werkt: 12

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

14 6.2.2 Ontwerp: webdesign/appdesign Functionele Eisen De Functionele Eisen leggen precies vast WAT je gaat maken. Om het WAT boven tafel te krijgen, beschrijf je alle functies van je product en alle eisen die je er aan stelt. De vragen die je hiervoor moet beantwoorden zijn o.a. (afhankelijk van het gekozen project): - Wat kan het? - Wie is de doelgroep? - Welke handelingen kan de eindgebruiker verrichten en wat is hiervan het resultaat? - Wat voor input en output is er mogelijk? - Welke onderdelen bevat het? - Hoe ziet het eruit? (welke schermen, knoppen en lay-outs zijn er?) - Welke systeemeisen zitten er aan? - Voor webdesign of appdesign kun je concreet denken aan o.a.: Functies. 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 Design. Beschrijf minstens de volgende dingen: kleurgebruik, lettertype(n), lay-out (kolommen, schermen, menu s, etc.), eventuele logo s etc. Bediening. Welke knoppen en acties zijn er mogelijk (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. Systeemeisen. Beschrijf de systeemeisen: eventuele browsereisen, resolutie, flash, Android of ios versie, etc. Technische Uitwerking De Technische uitwerking is een handleiding voor de programmeurs voor tijdens de implementatie. Tevens toon je er mee aan dat je verschillende oplossingen hebt bedacht om aan de Functionele Eisen te voldoen. Voor de belangrijkste functies laat je zien dat je meerdere oplossingen/uitwerkingen hebt bedacht en je onderbouwt je definitieve keuzes. Bij een site moet je denken aan: - Welke programmeeromgeving gebruik je? (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 14

15 - Hoe ziet je html eruit (divs, css, etc...). Hoe ziet je mappenstructuur 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 dynamisch website ontwerp. 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 gebruiker. Bij een app kun je denken aan: - 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.) - 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. Google 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, knoppen en bedieningselementen die je aan de gebruikers aanbiedt) en de interactie met de buitenwereld en de gebruiker. 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. 15

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

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