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
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
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 2009 154M€ 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;
http://www.objectwatch.com/whitepapers/ITComplexityWhite Paper.pdf
6
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, 26-3-2009 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. http://www.computable.nl/artikel/ict_topics/crm/2909157/233 3360/gebruikers-ontevreden-over-ictsysteempolitie.html#ixzz15GhBQH3d
8
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)
http://www.it-
executive.nl/headlines/headline/politietop_hield_kritisch_rapp 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 http://www.rijksoverheid.nl/bestanden/documenten-enpublicaties/kamerstukken/2010/11/08/basisvoorzieninghandhaving-22544/basisvoorziening-handhaving-22544.pdf
10
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
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 werkende versies van product
vele methodes, bv: Rapid Application
Development (RAD)
Extreme Programming (XP) SCRUM
14
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:
http://en.wikipedia.org/wiki/Scrum_(development)
16
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: http://www.cms.hhs.gov/SystemLifecycleFramework/Downloads/S
electingDevelopmentApproach.pdf http://en.wikipedia.org/wiki/Software_development_methodology
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
Planning
maak een realistische schatting van taken en tijd
stel uitdagende doelen
bouwen website schrijven van teksten voor deliverables vervaardigen documentatie presentaties voorbereiden (+ poster, film, CD/DVD box)
verschuif het werk niet naar achteren
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)
hoofdlijn gegeven door deadlines 7,5 ECTS = 210 uur
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?
Browse Items
analyseren bestaande producten eigen analyse probleem
customer
Buy Items
opdrachtgevers documenten (toekomstige) gebruikers reseller • interviewen • observeren—als het een taak is die ze nu al uitvoeren
Get commission
use cases: scenario’s van mogelijk gebruik ICA richtlijn document: rond de 2500 woorden meer info: http://en.wikipedia.org/wiki/Requirements_analysis slides MSO: http://www.cs.uu.nl/docs/vakken/mso/1011/Plan.html
20
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. 2500 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:
http://en.wikipedia.org/wiki/Software_design_document (volg links)
22
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. 5000 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
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 http://www.useit.com/papers/heuristic/heuristic_list.html meer info: Usability 101 http://www.useit.com/alertbox/20030825.html http://en.wikipedia.org/wiki/Usability
26
Playability kwaliteit van een game ‘als spel’ verwant aan usability belangrijke aspecten
(http://en.wikipedia.org/wiki/Gameplay#Playability) 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: http://forum.nokia.com/dp?uri=http://sw.nokia.com/id/5ed5c7a3-
73f3-48ab-8e1e631286fd26bf/Mobile_Game_Playability_Heuristics_v1_0_en.pdf (informatie over mobiliteit minder belangrijk) http://www.behavioristics.com/downloads/DesurvireFinalHCI09PLAY.pd 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
