Informatica en Gametechnologie

Transcriptie

1 Introductieprojecten Informatica en Gametechnologie software-ontwikkelcyclus 19 november 2010 Frans Wiering 1 Inhoud college wat is het probleem? wat kan er misgaan? software-ontwikkelcyclus belangrijke stappen de menselijke factor 2

2 Nieuws webspace wordt nog geregeld, informatie gaat naar begeleiders assistenten werken op vrijdag maak afspraak per mail 3 Wat is het probleem? bij software-ontwikkeling gaat het vaak om grote producten te groot om in een keer te overzien onderscheiden componenten en subcomponenten top-down proces implementeren: regel voor regel code schrijven samenvoegen tot grotere eenheden bottom-up proces hoe komen de twee processen succesvol bij elkaar? veel belangen in het spel 4

3 Wat kan er misgaan? verschillende belanghebbenden (stakeholders) 5 De praktijk overal vind je minder geslaagde ICT producten zelfs aan de UU Nederlandse overheid geeft in M meer uit aan ICT dan gepland (NRC, 16 juni 2010) Belastingdienst: ETM-project 60->179 M Defensie: SPEER-project 185->268 M wereldwijde schatting kosten mislukte ICT projecten jaarlijks 4,3 biljoen totale schade (inclusief indirecte kosten) Roger Sessions, 2009; Paper.pdf 6

4 Meer blauw op straat! minister Opstelten van Veiligheid en Justitie op Veiligheidscongres, Zeist 11 november 2010: Er komt meer méér tijd voor het vakmanschap en de professionaliteit van de agent. Wij gaan die agent daarbij helpen. Samen met de politie en het Openbaar Ministerie gaan wij de bureaucratie te lijf. Een aanvalsplan!... We streven naar een vermindering van administratieve lasten met 25%. Het kan niet waar zijn dat 2 volwaardige dienders 4 uur tijd kwijt zijn als twee 13-jarigen zijn opgepakt voor winkeldiefstal. 7 ICT en politie (1) centrale ict-systeem: Basisvoorziening Handhaving (BVH) ingevoerd vanaf 2007 Computable, politievakbond ACP spreekt van administratieve wanorde en een toename van de administratieve rompslomp "In veel gevallen deed men twee tot drie maal zo lang over een administratief proces als in het verleden "Veel mensen verwachten dat het systeem vanaf het begin foutloos zou werken. Zoals bij elke grote ict-implementatie zijn er wat kinderziektes. Daar zitten we bovenop", vertelt Egas aan Computable /gebruikers-ontevreden-over-ictsysteempolitie.html#ixzz15GhBQH3d 8

5 ICT en politie (2) Nu.nl, 27 januari 2010 De computerproblemen bij de politie hebben ''catastrofale vormen'' aangenomen. ''Het niet functioneren van onze systemen raakt de slagader van mijn organisatie.'' (korpschef van de regiopolitie IJsselland, Peter-Jaap Aalbersberg, in een vertrouwelijke brief aan Vts PN) NRC, 13 november 2010 Een rapport dat waarschuwde voor de invoering van een slecht computersysteem bij de politie, bleef in de la liggen. Dat zei Henri Lenferink, korpsbeheerder van het korps Hollands Midden 9 ICT en politie (3) ort_over_falend_it-systeem_onder_de_pet/ (m.n. 1e 5 minuten) Citaat uit rapport: De kwaliteit van de systeemonderdelen, wanneer los beschouwd, is met enkele uitzonderingen redelijk tot goed. Echter, het systeem als geheel is van zeer lage kwaliteit en slecht onderhoudbaar. De belangrijkste zwakte is de algehele architectuur met verouderde technologie in het centrum en hoge diversiteit in satellietonderdelen en koppelingen. Dit komt ook tot uitdrukking in de documentatie van het systeem, die per systeemonderdeel is uitgewerkt, terwijl overzichts-documentatie over het gehele systeem ontbreekt. zie ook 10

6 Enkele aanbevelingen uit rapport beter versiebeheer broncode eerder en systematischer testen kennis delen tussen ontwikkelaars documenteren systeemarchitectuur verminder afhankelijkheid hardware en verouderde technologie meest extreme scenario: ontwikkel BVH opnieuw voorwaarde is dat er heldere functionele eisen van het BVH systeem voorhanden zijn. 11 Software-ontwikkeling is niet triviaal complexe taak technische beperkingen bestaande systemen, infrastructuur verschillende belangen stakeholders bv. zorgvuldigheid vs. snelle invoering communicatie verschillend wereldbeeld (bv. werk van de politie) mensen nemen (veel te) snel aan dat ze het over hetzelfde hebben (wat is een interface, een agent?) vandaar methoden van software-ontwikkeling 12

7 Basisidee: fasen planning doel en fasering analyse wat moet de software doen? verzamelen en opschrijven requirements systeemontwerp hoe werkt het systeem? leg dit vast in ontwerpdocument bouwen schrijven code documenteren testen opleveren onderhoud globale hoofdlijn details verschillen per methode 13 Ontwikkelcyclus oorspronkelijk idee: fasen na elkaar watervalmethode praktijk eisen veranderen tekortkomingen na invoering en onderhoud: volgend ontwikkeltraject cyclische, incrementele modellen essentie: opleveren en evalueren werkendeversies van product vele methodes, bv: Rapid Application Development (RAD) Extreme Programming (XP) SCRUM 14

8 Voorbeeld van een methode: SCRUM voor teams van ca. 7 mensen cyclische methode sprints van 30 dagen aan het begin: taken aan het einde: werkende versie 15 Voorbeeld van een methode: SCRUM dagelijkse SCRUM meeting (max. 15 min) staand, informeel ieder geeft korte update: wat gedaan wat ga je doen problemen voortgang in burndown chart laat zien hoe de product backlog wordt weggewerkt meer informatie: 16

9 Wat moet je hiermee je hoeft niet een bestaande methodiek te kiezen ter inspiratie voor eigen aanpak cyclisch werken, opleveren tussenproducten bv. elke week een werkende volgende versie bijhouden vordering project planning bewaken aanpassen wanneer nodig belang van goede communicatie meer info: electingdevelopmentapproach.pdf 17 Deliverables deliverables gerelateerd aan fasen ontwerpcyclus ieder team levert op: teamnaam, bio s van leden (GT, week 48) definitieve planning (week 48), geen deel beoordeling analysedocument (week 48) ontwerpdocument (week 49) tussenproduct (ICA, week 51) eindproduct (week 4) eindverslag (ICA, week 4) symposiumbijdragen (week 5) hierna enkele slides met praktische aanwijzingen meer over verslag, symposium, poster e.d. in college 6 deadlines: check data op website, kunnen veranderen!!! 18

10 Planning maak een realistische schatting van taken en tijd hoofdlijn gegeven door deadlines 7,5 ECTS = 210 uur stel uitdagende doelen bedenk wat essentieel is wat eventueel weggelaten kan worden waarmee je wilt scoren bouw ruimte in voor tegenvallers ( plan B ) plan ook bijkomende activiteiten (kosten tijd, deel cijfer) bouwen website schrijven van teksten voor deliverables vervaardigen documentatie presentaties voorbereiden (+ poster, film, CD/DVD box) verschuif het werk niet naar achteren ervaringsfeit: veel tijd gaat verloren aan begin projecten dus: zorg voor concrete taken in begin pas planning aan wanneer nodig 19 Analyse, algemeen doel: het specificeren van requirements ICA: een eenduidige beschrijving van de specificaties waar het product aan moet voldoen hoe kom je aan requirements? analyseren bestaande producten eigen analyse probleem customer opdrachtgevers documenten (toekomstige) gebruikers reseller interviewen observeren als het een taak is die ze nu al uitvoeren use cases: scenario s van mogelijk gebruik ICA richtlijn document: rond de 2500 woorden meer info: Browse Items Buy Items Get commission slides MSO: 20

11 Analyse game doel is specifieker dan bij ICA beschrijf welk spel gemaakt zal worden, hoe het spel werkt en wat de technologie is die zal worden gemaakt/aangepast aandachtspunten technologie oude game waarom (geen) succes? geschikte nieuwe technologieën gevolgen voor gamedesign analysedocument specificatie op vakwebsite max woorden gebruik zinvolle illustraties, maak het aantrekkelijk voor portfolio 21 Ontwerp, algemeen doel: beschrijving of verbeelding van de 'oplossing' voor het gekozen probleem en hoe dit vertaald gaat worden naar programmacode of anderzins (ICA) aspecten functioneel ontwerp (wat doet het product?) menus, interactie, navigatie diagrammen (vele typen) technisch ontwerp (hoe werkt het product?) welke algoritmen, libraries etc. database-ontwerp klassen, klasse-hiërarchieën visueel ontwerp (hoe ziet het product eruit?) vormgeving conceptueel scheiden van rest systeem: skin ICA richtlijn document: rond de 5000 woorden meer info vind je hier: (volg links) 22

12 Ontwerp game doel: beschrijf hoe het spel gemaakt gaat worden, wat hiervoor nodig is, wat de technologie voor effect zal hebben, etc. aspecten game ontwerp gameplay design art en sound user interface technisch ontwerp werking, gameloop klassen algoritmen, libraries ontwerpdocument specificatie op vakwebsite max woorden gebruik zinvolle illustraties 23 Implementatie programmeren toepassen kennis uit imperatief/game programmeren incrementele werkwijze: steeds werkende tussenproducten testen heeft component gewenste functionaliteit voorbeeld: unit tests voor elke input is output bekend test of elke unit dit correct reproduceert kleine units, max ca. 60 regels code risico s te laat testen te grote units testen documentatie technische documentatie voor ontwikkelaars altijd te weinig! vooral hoog-niveau architectuur product behoeft documentatie 24

13 Menselijke factor veel software en alle games zijn bestemd voor mensen paradox of the active user gebruikers gaan meteen aan het werk documentatie/training heeft beperkte betekenis niet uitgaan van geïdealiseerde rationele gebruiker rekening houden met menselijke eigenschappen wezenlijk perceptie motoriek geheugen cultuur context (werk, sociaal) enz. belangrijke begrippen usability playability 25 Usability the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use belangrijke aspecten leerbaarheid efficientie onthoudbaarheid fouten tevredenheid bekendste richtlijnen voor usability: 10 heuristics van Jakob Nielsen meer info: Usability

14 Playability kwaliteit van een game als spel verwant aan usability belangrijke aspecten ( tevredenheid (beloning, plezier) leerbaar (gemakkelijk te leren, stap voor stap) efficient (hoe snel wordt het leuk) immersie (deel uitmaken virtuele wereld) motivatie (aanzetten tot actie) emotie (liefst veel verschillende) socialisatie (deel uitmaken groep) meer info: fd26bf/Mobile_Game_Playability_Heuristics_v1_0_en.pdf (informatie over mobiliteit minder belangrijk) f (wetenschappelijke kijk) 27 Samenvatting belang methodische aanpak grootste problemen hebben menselijke oorzaak voornaamste fasen in software-ontwikkeling belang cyclische aanpak analyse, requirements game, functioneel en technisch ontwerp belang usability en playability 28