Project Gedistribueerd Programmeren

Transcriptie

1 Project Gedistribueerd Programmeren Studiewijzer Opleiding Bachelor of Science in Informatica, van de Faculteit Wetenschappen, Universiteit Antwerpen. Nota s bij de cursus voor academiejaar J. Broeckhove Onderzoeksgroep Computationeel Modelleren en Programmeren

2 Inhoudsopgave 1 Overzicht Voorkennis Inhoud Doelstellingen Werkvormen Leerstrategie Studiemateriaal Contact informatie Projectopdracht Projectvoering Opdracht: Gedistribueerde Spreadsheets Design Verdere precisering Planner Kalender Project mijlpalen Mijlpalen voor blok Mijlpalen voor blok Deadlines Evaluatie Inleiding Schema Kwaliteitscriteria

3 HOOFDSTUK 1 Overzicht 1.1 Voorkennis Zoals de naam van het opleidingsonderdeel aangeeft, is een aanzienlijke voorkennis in het programmeren en een ruime programmeerervaring als vereiste voorkennis voor de hand liggend. Ook elementaire kennis van software engineering (projectvoering, testen van programma s) is belangrijk. Voorkennis op het gebied van gedistribueerde applicaties is niet vereist. In dit opzicht vertrekt het opleidingsonderdeel met een schone lei. 1.2 Inhoud Het theoretisch luik geeft een kort overzicht van het softwareontwikkelingstraject. Vervolgens worden een aantal onderwerpen onderzocht die vaak een rol spelen in de uitbouw van gedistribueerde toepassingen zoals het client-server paradigma, programmeren met sockets, XML technologie. Het zijn aspecten die gentegreerd moet worden in de softwareoplossing van het projectprobleem. Het practicum bestaat in het uitwerken in C++ en Java van een softwareoplossing voor een probleemstelling die elk jaar anders is. Het project wordt in groepen van vier tot zes studenten uitgevoerd en bestaat o.a. in het maken van een ontwerp, het coderen en testen, en tenslotte het opstellen van documentatie. Niet alleen de geproduceerde code maar ook de aanpak is van belang. Er worden vooraf specifieke termijnen afgesproken waarop project-producten zoals design-diagrammen of prototype code opgeleverd moeten worden.

4 1.3. DOELSTELLINGEN Doelstellingen Je krijgt vaardigheden mee om in een groepsproject een gedistribueerd applicatie te ontwikkelen. Het opleidingsonderdeel bestaat uit delen, namelijk Java programmeren, Gedistribueerd programmeren en Software ontwikkelingsproces, in parallel met de eigenlijke uitvoering van het project. Hieronder vind je de doelstellingen voor ieder ervan Java Programmeren Je kan zelfstandig, met begeleiding, een programmeertaal leren gebruiken. Je hebt ervaring in het gebruik van Java als programmeertaal. Je hebt ervaring in het gebruik van Eclipse als programmeeromgeving Gedistribueerd Programmeren Je hebt inzicht in de notie architectuur van een gedistribueerde applicatie. Je kan sockets en XML gebruiken bij het bouwen van een gedistribueerde toepassing Software ontwikkeling Je begrijpt de noodzaak van een gestructureerd software ontwikkelingsproces. Je hebt contact met de activiteiten in software ontwikkelingsprocessen. Je kan gecoördineerd gebruik maken van tools o.a. voor versie controle (Subversion), programmaopbouw (make, Ant), testing (CppUnit, JUnit), UML gebaseerd development (Visual Paradigm), documentatieopbouw (doxygen) Groepsroject Je kan in een groep van 4 of 5 werken aan een gestructureerd project. Je kan je werk planmatig benaderen en omgaan met project deadlines. 1.4 Werkvormen Het Project Gedistribueerd Programmeren vertegenwoordigt negen studiepunten met vijftien contacturen voor theorie en vijfenzeventig contacturen voor praktijk. Er is een beperkt aantal hoorcolleges, voornamelijk i.v.m. het softwareontwikkelingstraject. Dit bestaat uit een overzicht waarin klemtoon gelegd wordt op datgene wat relevant is voor de uitvoering van het project. Daarnaast zijn er werkessies over Java programmeren, sockets en XML. Daarbij hoort een belangrijke component begeleid zelfstandig leren. De zelfstudie is functioneel t.t.z. je leert wat je nodig hebt om het project te realiseren

5 1.5. LEERSTRATEGIE 4 Vermits het aspect groepswerk belangrijk is in dit opleidingsonderdeel, spreekt het voor zich dat ook bij de zelfstudie in groep gewerkt kan worden. Het verdient zelfs aanbeveling dit te doen. Er kan ook over de groepen heen samengewerkt worden. Het prakticum bestaat volledig uit de uitvoering, in groepen van vier of vijf studenten, van het project. Daarbij moet het vooraf uitgestippelde plan met stappen en termijnen strikt nageleefd worden. Een twee- of driemaal zal een functioneringsgesprek met ieder van de groepen gehouden worden. 1.5 Leerstrategie Je aanpak als student moet aangepast zijn aan de werkvorm die gehanteerd wordt en de evaluatie waar je aan onderworpen wordt. Tijdens de contacturen worden de elementaire aspecten van de diverse facetten van het opleidingsonderdeel besproken. Die moet je in groep verwerken en later in functie van de noden van de projectopdracht aanvullen. Het gaat steeds om functionele kennis: ze moet je helpen in het realiseren van het project. De evaluatie is ook in die zin opgevat. De uitvoering van het project zal je dwingen die kennis in vaardigheden om te zetten: van Java syntax kennen naar Java programmeren, van de onderdelen van een software proces kennen naar een ontwikkelingsproces uitvoeren, van de elementen XML kennen naar XML files ontwerpen en zo voort. Dat vereist stappen: je leest uiteenzettingen in de nota s en de daarin vermelde bronnen vervolgens bestudeer je voorbeelden, je bootst ze na of vormt ze om, kortom je experimenteert je interageert over je bevindingen met je medestudenten, wisselt tips, materiaal of ervaringen uit je past de vaardigheid toe in het raam van de projectopdracht Deze cyclus doorloop je telkens opnieuw voor deelonderwerpen en zo breidt je je mogelijkheden stelselmatig uit. 1.6 Studiemateriaal Dit opleidingsonderdeel is gericht op het ontwikkelen van vaardigheden en niet op het bijbrengen van kennis. Daar waar de student toch kennis moet vergaren zal dat in hoofdzaak via zelfstudie zijn en volledig in functie van de project opdracht. De project opdracht zelf wordt in de nota s omschreven, zowel wat betreft onderwerp, vorm van uitvoering, termijnen, deliverables,.... Voor het deel Java programmeren zijn inleidende nota s voorzien die de student op weg zetten en die ook aangeven wat bij de zelfstudie de aandachtspunten zijn.

6 1.7. CONTACT INFORMATIE 5 In die nota s wordt ook verwezen naar een aantal naslagwerken. Een daarvan is elektronisch beschikbaar, de meeste andere kunnen in de bibliotheek geraadpleegd worden. Voor het onderdeel gedistribueerd programmeren wordt in de eerste plaats verwezen naar de relevante Java API s en specificatie documenten. Dat wordt aangevuld met beknopte nota s. Voor het software ontwikkelingsproces wordt slechts een beperkte kennismaking met de materie voorzien. De nota s zijn zeer beknopt, maar worden aangevuld met teksten in bijlage. Voor het deel object-georiënteerde design zijn er wel uitgewerkte nota s beschikbaar, omdat het grondiger aangepakt wordt. Vóór of na iedere lezing of werksessie worden de bijbehorende presentatie en codevoorbeelden ter beschikking gesteld via Blackboard. 1.7 Contact informatie Dit zijn de contactgegevens voor de lesgevers en begeleiders van dit opleidingsonderdeel: Naam: Jan Broeckhove Jan.Broeckhove@ua.ac.be Lokaal: Gebouw G, G205 Naam: Gunther Stuer Gunther.Stuer@ua.ac.be Lokaal: Gebouw G, G204 In sectie 2.1 wordt aangegeven wie je best contacteert in geval van vragen of problemen.

7 HOOFDSTUK 2 Projectopdracht 2.1 Projectvoering Het is jullie taak om met een groep van 4 of 5 studenten een softwareproject uit te werken. De groepen worden door de studenten zelf samengesteld. Er zijn ten aanzien van het project vier rollen: Projectleider Is verantwoordelijk voor de algemene organisatie, en de gestelde mijlpalen. Voert de functioneringsgesprekken met ieder van de groepen. Staat, samen met de projectbegeleider, in voor de evaluatie. Projectleider is J. Broeckhove. Projectbegeleider Heeft de dagelijkse supervisie over de uitvoering van het project en fungeert als tussenpersoon ten aanzien van de projectleider. Projectbegeleider is G. Stuer. Groepsleden Voeren in onderlinge samenwerking het project uit met in acht name van de mijlpalen opgelegd door de projectleider. Contactpersoon Groepsleden wijzen één van de leden aan als tussenpersoon ten aanzien van de projectbegeleider. De contactpersoon heeft geen leidingevende functie ten aanzien van de groepsleden. Wel staat hij in voor de communicatie en neemt hij contact op met de begeleider in geval van moeilijkheden: strubbelingen in de groep, problemen met deadlines,... Het project moet strikt verlopen volgens de planning in sectie 3.1. De oplevering van project artifacts (software, UML diagrammen, documenten) en de kennisgeving van planning artifacts (Gantt charts, interne deadlines) aan de projectbegeleider verloopt via de website die door de groep opgezet wordt. Deze zal enkel door projectleider en -begeleider geraadpleegd kunnen worden.

8 2.2. OPDRACHT: GEDISTRIBUEERDE SPREADSHEETS Opdracht: Gedistribueerde Spreadsheets Het onderwerp van dit project is de ontwikkeling van een gedistribueerde spreadsheet, met apriori een onbeperkt aantal kolommen en rijen van cellen. In deze cellen kunnen ofwel numerieke waarden, ofwel tekst ofwel formules ingebracht worden. In het laatste geval wordt met de cel de waarde geassocieerd waartoe de formule evalueert. In de formules moeten de volgende wiskundige constructies gehanteerd kunnen worden: Toewijzing. vb: =A1 Elementaire bewerkingen (+,-,*,/,%). vb: =A1+(A2/D2) Complexere bewerkingen (sin,cos). vb: =sin(0.12) Bewerkingen op 1D en 2D lijsten (sum, prod, avg, min, max). vb: =sum(a1:a20) Bewerkingen op matrices (sum, diff, prod, determinant, transpose, inverse, norm). Het is de bedoeling dat je voor deze categorie van bewerkingen gebruik maakt van vrij beschikbare bibliotheken. Welke bibliotheek je hiervoor gebruikt mag je zelf kiezen. vb: =transpose(a1:d4) Combinaties van al het voorgaande Het probleem van de mogelijk cyclische verwijzingen in formules moet niet opgelost worden bij het definieren van de formule. Het is aanvaardbaar dat het gedetecteerd wordt bij evaluatie van de formule en dan dit als fout aan de gebruiker gemeld wordt. Verder moet voor het opstellen van de formules, de mogelijkheid bestaan aliassen in te voeren t.t.z. met een rij, kolom of range van cellen een naam te associëren die als verwijzing in een formule kan gehanteerd worden. Je spreadsheet bestaat uit 2 componenten. De engine, die de algorithmes en datastructuren bevat, en de GUI (Graphical User Interface) die de informatie op een ordentelijke manier aan de gebruiker presenteert, met hiertussen een XML communicatie protocol. Het moet in de GUI mogelijk zijn om tegelijkertijd meerdere, door verschillende engines gehoste, spreadsheets te openen. Omgekeerd kan een spreadsheet concurrent door verschillende gebruikers benaderd worden. Toegangcontrole is niet nodig, maar je moet er wel op letten dat een bepaalde cel maximaal door 1 gebruiker tegelijkertijd kan geëditeerd worden. Je mag zelf kiezen of je hiervoor optimistic of pessimistic locking gebruikt. Veranderingen moeten steeds naar alle geregistreerde views worden gepropageerd zodat deze allemaal synchroon blijven. De spreadsheets moeten kunnen worden opgeslagen en terug ingelezen. De opslag dient in XML te gebeuren. Optioneel kan een import/export functionaliteit met OpenOffice calc of met het excel bestandsformaat ingebouwd worden. De engine moet op 3 manieren te benaderen zijn: Via een GUI-client, door middel van een zelf ontworpen XML-protocol Via een command-line user interface client, die de engine door middel van het zelfde protocol als de GUI benadert Via een API die toelaat om de engine als een 3th party embedded library te gebruiken.

9 2.3. DESIGN 8 Het spreekt voor zich dat vooral deze 2 laatste benaderingen uitstekend geschikt zijn voor het uitvoeren van geautomatiseerde tests. Tot slot moet je spreadsheet applicatie de mogelijk hebben om acties terug ongedaan te maken (undo). 2.3 Design Daar waar mogelijk moet gebruik gemaakt worden van design patterns. Bij de ontwikkeling van een spreadsheet zal het observer pattern een belangrijke rol spelen. Immers, indien een cel die in een formule wordt gerefereerd, wordt aangepast, moet ook deze formule-cel worden geherevalueerd. Je moet gebruik maken van het Model-View-Controller design pattern bij het ontwerpen van je spreadsheet. De spreadsheet engine komt in het model - gedeelte terecht en de user interface vertegenwoordigd de onderdelen view en controller. Het aanspreken van de engine moet via wel gedefinieerde interfaces gebeuren. Zowel de opdrachten die een gebruiker in je spreadsheet kan ingeven als de functies in je formules zijn ideale kandidaten voor het Command-pattern. Performantie is een overweging die in acht genomen wordt bij het ontwerp, maar die niet het onderwerp uitmaakt van specificaties of van tests. Hoe vervelend het ook mag zijn, het schrijven van goede documentatie is absoluut noodzakelijk. Een gezonde dosis discipline en een tool zoals JavaDoc kunnen je hier al een heel eind op weg helpen. Bij het programmeren dient de Sun Java Coding Convention gevolgd te worden. Maak tevens vanaf de eerste lijn code gebruik van publiek beschikbare kwaliteitscontrole tools zoals PMD, FindBugs en JLint. De evaluatoren zullen dit ook doen! 2.4 Verdere precisering De opdracht dient natuurlijk inhoudelijk verder gedetailleerd te worden. Dat zal gebeuren in een overleg tussen de projectbegeleider (G. Stuer) en de ontwikkelaars (de projectgroepen). Dat overleg neemt de vorm aan van een aantal interviews tussen opdrachtgever en ontwikkelaars. Het is daarbij de taak van de groepen om voldoende en relevante informatie in te winnen om de doelen en geassocieerde use cases en use case scenarios van de applicatie te omlijnen.

10 HOOFDSTUK 3 Planner 3.1 Kalender De kalender voor het opleidingsonderdeel ziet er voor het eerste blok, tot aan het Paasreces, uit zoals aangegeven in de eerste tabel en voor het tweede blok zoals aangegeven in de tweede tabel. De vermelding intro slaat op een hoorcollege terwijl de vermelding werksessie slaat op een hands-on, begeleide oefensessie in het computerlabo. De tabel geeft de begeleide activiteiten, de zelfstudie activiteiten en de milestones (moment waarop een project artifact afgewerkt is) aan die gerespecteerd moeten worden. De milestones worden nader verklaard en omschreven tijdens de contacturen. Telkens geldt zondag 24h van de aangegeven week als deadline voor het opleveren van de vereiste artifacts. Dat gebeurt steeds via publicatie op de website van de groep. Er wordt steeds doelbewust incrementeel gewerkt, vooral tijdens de implementatie en testfase. De diverse functionaliteiten worden stelselmatig, de ene na de andere, opgebouwd. Er wordt in geen geval in een alles-of-niets poging getracht alle functionaliteiten tegelijkertijd te implementeren. Intermediaire versies worden waar mogelijk reeds aan functionele tests onderworpen.

11 3.1. KALENDER 10 BLOK 1 Lessen Leeractiviteit Milestones Lesweek 1 - Intro - Java programmeren - Groepen website - Java werksessie - Web programmeren - Website met Eclipse operationeel Lesweek 2 - Overzicht - Gebruik van - svn repository, Softwareproces XML API s operationeel - XML werksessie - Java prototypes Lesweek 3 - Sockets - Gebruik van - XML prototypes werksessie socket API s Lesweek 4 - Onderwerp - Gebruik - Socket - Software- UML tool prototypes ontwikkeling 1 Lesweek 5 - Software- - UML diagrammen - Projectvisie ontwikkeling 2 - Analyse & Design document - Functionering Lesweek 6 - Software - Analyse & Design - Use Case & ontwikkeling 3 - Architectuur domein analyse baseline Reces Reces Figuur 3.1: Kalender voor het eerste blok, tot het Paasreces.

12 3.1. KALENDER 11 BLOK 2 Lessen Leeractiviteit Milestones Lesweek 7 - Design - Architectuur - Architectuur & design baseline artifacts Lesweek 8 - Functionering & - Detaildesign - Gantt chart ivm feedback - Testframework implementatie - Implementatie Lesweek 9 - Implementatie - Test framework - Testing operationeel Lesweek 10 - Implementatie - Testing Lesweek 11 - Functionering & - Implementatie feedback - Testing Lesweek 12 - Implementatie - Testing Lesweek 13 - Oplevering - Finale tests voorbereiden - Finale inspectie alle artifacts Examen - Opleveringsperiode gesprek met demonstratie Examen - Individuele periode presentatie van projectbijdrage Figuur 3.2: Kalender voor het tweede blok, na het Paasreces.

13 3.2. PROJECT MIJLPALEN Project mijlpalen In het opgeven van de mijlpalen (milestones in het Engels) van het project wordt reeds terminologie gebruikt die pas later uitgelegd wordt. Dat is ook normaal vermits hier de hele duur van het project zijn rol speelt. 3.3 Mijlpalen voor blok 1 lesweek 1 De groepen zijn samengesteld uit vier of vijf leden en hebben een naam gekozen en een contactpersoon aangeduid. Deze informatie wordt via aan de project manager gecommuniceerd. De website van de groep is operationeel en bevat een voorstelling van ieder van elk groepslid. De site mag meer informatie bevatten dan via deze opdrachtomschrijving geëist wordt. In het raam van de zelfstandige studie kan men interessante bronnen aangeven, of syntheses die men gemaakt heeft,... lesweek 2 De Subversion repository die gebruikt zal worden om version management te voeren over alle project artefacts (code, documentatie, diagrammen, test drivers,... ) moet operationeel zijn. De toegang tot de repository moet in de website geïntegreerd zijn. Het gebruikte paswoord wordt via aan de project manager gecommuniceerd. De exploratory prototypes die werden opgesteld bij de studie van Java als programmeertaal en Eclipse als ontwikkelingsomgeveing worden gepubliceerd. lesweek 3 De exploratory prototypes die werden opgesteld bij de studie van XML en XML processing worden gepubliceerd. Een beschrijving van het project, maximum twee tot drie pagina s lang, opgesteld als resultaat van het onderzoek over het onderwerp, wordt gepubliceerd. lesweek 4 De exploratory prototypes die werden opgesteld bij de studie van sockets en socket API s in Java worden gepubliceerd. lesweek 5 Een update van de beschrijving van het project, maximum twee tot drie pagina s lang, opgesteld als resultaat van het onderzoek over het onderwerp, wordt gepubliceerd. lesweek 6 De documenten uit de inception fase moeten ingeleverd worden, in één groot

14 3.4. MIJLPALEN VOOR BLOK 2 13 pdf-bestand. Hierin moeten alle use cases in het casual formaat beschreven worden en het belangrijkste in het fully-dressed formaat. Ieder van de groepsleden dient voor één use case een Use Case diagram, een Activity Diagram en een System Sequence Diagram op te stellen. Het domein model dat via een UML klasse diagram dient uitgewerkt te worden, moet ook ingediend worden in pdf formaat. 3.4 Mijlpalen voor blok 2 lesweek 7 De architectuur documenten moeten, telkens in één PDF-bestand, gepubliceerd worden. Het gaat hier om een weergave van de architectuur vanuit de logische view, via een UML Package Diagram, en om een weergave vanuit de deployment view, via een UML deployment diagram en een component diagram. Ook de sources van de geímplementeerde architecturale baseline dienen gepubliceerd te worden. Publicatie van het design op hoog niveau in pdf-formaat. Hieronder verstaan we een klasse diagram met de klassen die een sleutelrol spelen bij het realiseren van de use cases, en hun onderlinge band eventueel uitgedrukt via een object interaction diagram.. lesweek 8 Publicatie van een Gantt chart met de verdeling van de implementatietaken. Welk lid van de groep doet wat en tegen wanneer? Wat zijn de onderlinge afhankelijkheden: wat moet voltooid of getest zijn voor de volgende stap kan gezet worden? lesweek 9 Er wordt een weloverwogen, geautomatiseerde teststrategie gehanteerd tijdens de implementatie activiteit. Deze test omvatten unit tests (JUnit) en integratie tests. Een volledige of althans zo volledig mogelijke functionele test set op basis van de use cases wordt doorlopen tijdens de transitiefase. Publicatie van het plan van het framework voor testen. De bedoeling is dat het testen geautomatiseerd kan gebeuren. De tests moeten via de website geactiveerd kunnen worden door de project manager. Als resultaat dient een overzichtelijk status rapport te worden gegenereerd dat vermeld welke tests succesvol waren en welke niet. Het plan beschrijft de structuur van het test framework. Het bevat een oplijsting van de functionaliteiten die worden getest (en eventueel welke niet), de volledigheid van de test en de wijze waarop hij georganiseerd is. Groepeer de testen primair per use case en secundair per functionele unit. De tests moeten reeds operationeel zijn. Let wel: er wordt niet vereist dat op ieder moment van de ontwikkeling van de software alle testen slagen. Sommige testen zijn misschien nog niet van toepassing, voor andere is de functionaliteit

15 3.5. DEADLINES 14 nog maar partieel geïmplementeerd en is men er zich van bewust dat de test zal falen. Maar het is belangrijk dat er een overzichtelijk rapport gegenereerd wordt van welke testen slagen en welke falen, of welke testen op dit moment nog niet toegepast worden. lesweek 10 Geen mijlpalen deze week. lesweek 11 Geen mijlpalen deze week. lesweek 11 Geen mijlpalen deze week. lesweek 13 Het project wordt aan het einde van deze week afgesloten. De functionele testen moeten dan volledig en succesvol doorlopen worden. De website moet volledig en volledig in orde zijn. examen Het systeem wordt formeel opgeleverd, met daarbij een demonstratie van de functionaliteit. De projectmanager zal daarbij vragen een aantal van de use cases te doorlopen op het functionerende systeem. Dit gesprek gebeurd in groep. Individuele presentatie over de eigen bijdrage aan het project, die tien minuten duurt. Je mag daarbij enkel slides, opgenomen in een pdf bestand, gebruiken. De presentatie omvat geen demonstratie van het systeem (dat is immers al gebeurd bij oplevering) maar handelt enkel over je eigen bijdrage aan het project en benadrukt de architecturale aspecten van je werk. De presentatie moet dus antwoord geven op twee vragen. De eerste vraag is Wat heb ik aan het project bijgedragen in ideeën en artefacten?. De tweede vraag is Wat zijn de belangrijke keuzen die ik heb moeten maken en hoe geeft dit aanleiding tot sterkten/zwakten in het product?. Aansluitend is er (maximaal) tien minuten tijd voor vragen. 3.5 Deadlines Een project kan meerdere soorten deadlines hanteren. project onderscheiden we twee types: In de planning van het Externe deadlines worden gekenmerkt door vastgelegd in samenspraak met de opdrachtgever geassocieerd met de oplevering van producten vastgelegd als mijlpalen in de planning harde deadlines die niet verschoven kunnen worden

16 3.5. DEADLINES 15 Interne deadlines worden gekenmerkt door vastgelegd na overleg in de projectgroep worden enkel in consensus gewijzigd missen heeft een belangrijke signaalfunctie: één, meerdere of alle groepsleden presteren onvoldoende, de interne planning is onrealistisch, de werkverdeling is onevenwichtig,... ; remediëring is belangrijk Problemen in verband met deadlines moeten zeker aan de orde gesteld worden tijdens de functioneringsgesprekken. Aanbevelingen: Ga onmiddellijk van start: investeer voldoende tijd in de beginfase. Volg de planning en de opgelegde mijlpalen strikt. Werk steeds doelbewust op incrementele wijze Signaleer problemen zo vroeg mogelijk aan de projectbegeleider. Test, test, test,... op het referentieplatform.

17 HOOFDSTUK 4 Evaluatie 4.1 Inleiding Als algemeen uitgangspunt geldt voor dit opleidingsonderdeel: De evaluatie toetst welke vaardigheden je verworven hebt en daadwerkelijk toegepast hebt. De evaluatie is relatief complex omdat zowel het functioneren van de groep als geheel als de individuele bijdragen daarin beoordeeld moeten worden. 4.2 Schema Berekend op een totaal van 100 punten zijn er twee componenten in het evaluatieschema: assessmentquotering: 80 punten Deze quotering is een combinatie van globale en individuele factoren. Eerst wordt een globale groepsbeoordeling opgesteld (zie hieronder). Vervolgens worden individuele assessmentfactoren bepaald via peer assessment (zie ook hieronder). De assessmentquotering van ieder groepslid is dan groepsbeoordeling assessmentf actor, met een maximum van 80 punten. individuele quotering: 20 punten Deze quotering is individueel. Ze gebeurd op basis van de individuele presentatie, die tien minuten duurt, en handelt over je eigen bijdrage aan het project. Ze wordt gevolgd door (maximaal) tien minuten vragen. Alle groepsleden zijn aanwezig tijdens elkaars presentatie.

18 4.2. SCHEMA 17 De assessmentquotering komt tot stand als combinatie van een globale groepsbeoordeling door de lesgevers en een peer assessment (i.e. beoordeling door je collega s in de groep) die individuele bijdrage weergeeft. groepsbeoordeling Deze beoordeling slaat op het geheel van het geleverde groepswerk, en wordt uitgedrukt in een quotering op 80 punten. De beoordeling is als volgt samengesteld: 1. Inspectie van de opgeleverde artifacts van de inception fase en van de analyse en architectuur van de applicatie. Dit onderdeel heeft een gewicht 1/4 van de groepsbeoordeling. 2. Inspectie van de opgeleverde artifacts over design van de applicatie en het test framework dat gehanteerd zal worden bij de implementatie. Dit onderdeel heeft een gewicht 1/4 van de groepsbeoordeling. 3. Inspectie van de opgeleverde artifacts van de implementatie. Dit onderdeel heeft een gewicht 1/4 van de groepsbeoordeling. 4. Permanente evaluatie van het aanwenden van good project practices : doelbewust incrementeel werken bij implementatie en testen, het respecteren van termijnen, de vorm van documenten, overzichtelijkheid van de website, en zo meer. Dit onderdeel heeft een gewicht 1/4 van de groepsbeordeling. assessmentfactor Deze factor komt tot stand via peer assessment.deze vindt plaats tussen de leden van de groep, onmiddelijk na alle presentaties van de groep. Ze verloopt volgens het model dat hieronder wordt uiteengezet. 1. Vul de namen van de andere groepsleden in op het assessment formulier. Vul je eigen naam niet in. Je beoordeelt jezelf niet. 2. Lees zorgvuldig onderstaande criteria: Brengt zinvolle ideeën aan Houdt zich aan gemaakte afspraken Levert een bijdrage tot een vlotte samenwerking Levert een aanzienlijke bijdrage tot het groepswerk 3. Je beschikt in totaal over 10 (aantalgroepsleden 1) punten. Oordeel in eer en geweten en verdeel deze punten over de andere groepsleden de voorgaande criteria in aanmerking nemend. Je moet al je punten opgebruiken. De assessmentformulieren blijven uiteraard geheim en worden onmiddellijk aan de projectbegeleider overhandigd. 4. Geef je een groepslid meer dan 10 punten, schrijf dan het belangrijkste criterium op waarop dat groepslid het best gepresteerd heeft. Geef je een groepslid minder dan 10 punten, schrijf dan het criterium op waarop dat groepslid het meest ondermaats gepresteerd heeft. 5. Voor ieder groepslid definieert de totaalscore/10 (aantalgroepsleden 1) de assessmentfactor. Deze varieert tussen 0 en (aantalgroepsleden 1) en de som over heel de groep is (aantalgroepsleden 1). Deze factor geeft

19 4.3. KWALITEITSCRITERIA 18 weer hoe de groepsleden zelf de relatieve bijdragen inschatten. Als alle groepsleden vinden ze ze een even grote bijdrage hebben geleverd, dan hebben ze alle een assessmentfactor 1. Heeft iemand een relatief grotere bijdrage geleverd dan heeft die een assessmentfactor groter dan 1 en zal degene die een relatief kleinere bijdrage heeft geleverd een assessmentfactor kleiner dan 1 hebben. Een voorbeeldje zal dit verduidelijken. Neem een groep van 5 personen die een groepsbeoordeling van 56/80 heeft gekregen. De leden vullen hun assessment in en dat geeft onderstaande tabel. lid A B C E F A B C E F totaal factor quot Horizontaal leest men de punten uitgebracht door ieder van de leden. Verticaal leest men dus de punten ontvangen door ieder van de leden. Dat sommeert tot de totaalscores op de zesde rij. Relatief (deling door 40 in dit geval) geeft dit de assessmentfactor in de zevende rij. Wanneer deze vermenigvuldigd wordt met de groepsbeoordeling (56 op 80 in dit geval) dan krijgt men de assessmentquotering voor ieder van de groepsleden. 4.3 Kwaliteitscriteria Wanneer zijn de artifacts, code en documentatie, tests, presentatie,... goed? Artifacts De documentatie dient telkens zo volledig mogelijk te zijn. Het is heel moeilijk om harde criteria op te leggen. Zo kan bijvoorbeeld een fully-dressed use case 1 tot 10 pagina s groot kan zijn, afhankelijk van de complexiteit van de use case. De kernvraag die je je telkens moet stellen is of je aan alle aspecten, alternatieven, randgevallen en mogelijke uitzonderingen gedacht hebt. De diagrammen die je inlevert worden, naast hun volledigheid, ook op hun semantische correctheid geëvalueerd. Soberheid en overzichtelijkheid zijn zowel voor de teksten als de diagrammen belangrijke eigenschappen. Code Er bestaan verschillende tools die de kwaliteit van je code automatisch beoordelen, het probleem situeren en een mogelijke oplossing beschrijven. Enkele

20 voorbeelden zijn PMD, CheckStyle, FindBugs en Metric. We raden je ten stelligste aan deze tools te gebruiken om je code kwaliteit optimaal te houden. Tests Tests moeten zo volledig mogelijk zijn. Dit is dan ook het voornaamste beoordelingscriterium. Dit wil niet zeggen dat je elk mogelijk scenario moet testen. Indien je een goede verantwoording kan geven waarom bepaalde functionaliteiten of deelaspecten ervan niet getest worden of slechts met een beperkte dekking getest worden, is dit ook in orde. Website Overzichtelijkheid in de navigatie (ongeacht de gebruikte browser) is het primaire kwaliteitsaspect. Daarnaast speelt soberheid van de presentatie mee. Presentatie De presentatie dient overzichtelijk gestructureerd te zijn, met verzorgde slides. De uiteenzetting dient een verzorgd taalgebruik te gebeuren. Inhoudelijk moet je zo snel mogelijk terzake komen en de punten aangegeven in sectie 3.4 te behandelen.