Introductieprojecten Informatica en Gametechnologie

Transcriptie

1 Introductieprojecten Informatica en Gametechnologie Teamwerk en softwareontwikkeling november 2014 Silja Renooij (met dank aan Frans Wiering) 1

2 Inhoud college software ontwikkeling: - academisch of niet? - het probleem van software ontwikkelen - wat kan er misgaan? - de software-ontwikkelcyclus - de menselijke factor teamwerk: - rollen - communicatie - conflicten 2

3 Onderzoeksmethoden De gebruikte methoden hangen sterk af van het probleem dat je wilt oplossen: een op zich staand systeem of proces? logisch-analytische benadering wiskundige bewijzen voorbeelden correctheid algoritme complexiteit van een algoritme een systeem/proces in relatie tot context? voorbeelden beeldherkenning zoekmachines empirische methodiek modelleren 3

4 Twee perspectieven op onderzoek ontwikkeling product hier: software-ontwikkelcyclus criterium: werking (specifiek) vergaren wetenschappelijke kennis onderzoeken methoden, bijv. voor OCR empirische cyclus criterium: kennis (algemeen) THEORIE Eigen aan informatica: perspectieven vaak gecombineerd 4 In informatica vaak een computationeel model

5 Modellen model is een geformaliseerde abstractie van de realiteit voorbeeld: wetten van Newton staan manipulatie toe: nabootsen realiteit in informatica en ICT is model veelgebruikt begrip politiesoftware heeft een model van aangifteprocedure Amazon, Marktplaats hebben een model van een aankoop OCR-software heeft modellen van lettertekens game heeft een model van de speler(s) informatica produceert buitengewoon veel modellen impact can groot zijn (gezichtsherkenning, security) belangrijk de beperkingen van modellen te kennen computationeel model is een vereenvoudiging van de realiteit datastructuur, algoritme niet alle menselijke kennis kan worden ingebouwd begrenst toepasbaarheid 5

6 Softwareontwikkeling: wat is het probleem? bij software-ontwikkeling gaat het vaak om grote producten te groot om in één 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 6

7 Wat kan er misgaan? verschillende belanghebbenden (stakeholders) 7

8 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 CDA wil onderzoek naar ICT-projecten overheid (Nu.nl, 19 oktober 2011) Eindrapport 15 oktober 2014: "ICT rijksoverheid niet onder controle" wereldwijde schatting kosten mislukte ICT projecten jaarlijks 4,3 biljoen totale schade (inclusief indirecte kosten) Roger Sessions, 2009; Papers/ITComplexityWhitePaper.pdf 8

9 ICT en politie (1) centrale ict-systeem: Basisvoorziening Handhaving (BVH) ingevoerd vanaf 2007 Computable, politievakbond ACP: administratieve wanorde en 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 zijnerwatkinderziektes bron: 9

10 ICT en politie (2) Nu.nl, 27 januari 2010 Computerproblemen bij de politie hebben catastrofale vormen aangenomen. ''Het niet functioneren van onze systemen raakt de slagader van mijn organisatie.'' NRC, 13 november 2010 SIG rapport dat waarschuwde voor de invoering van een slecht computersysteem bij de politie, bleef in de la liggen. Een Vandaag: Rapport: 10

11 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 Politie begroot nieuwe ICT op 326 miljoen euro De Nederlandse politie krijgt vanaf 2014 een nieuw, geïntegreerd systeem dat de huidige informatiesystemen voor handhaving en opsporing vervangt. Update: Jaarverslag Nationale Politie 2013: Door technische verbeteringen is het aantal verstoringen in de Basisvoorziening Handhaving (BVH) spectaculair verminderd. 11

12 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

13 Globale hoofdlijn: Basisidee: fasen planning doel en fasering analyse wat moet de software doen? verzamelen en opschrijven requirements systeemontwerp hoe werkt het systeem? vastleggen in ontwerpdocument bouwen schrijven code documenteren Testen opleveren onderhoud (details verschillen per methode) 13

14 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 lichte vorm: agile vele methodes, bv: Rapid Application Development (RAD) Extreme Programming (XP) SCRUM Code and fix 14

15 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

16 Voorbeeld van een methode: SCRUM dagelijkse SCRUM meeting (max. 15 min) staand, informeel ieder geeft korte update:wat gedaan, wat te doen, problemen voortgang in burndown chart laat zien hoe de product backlog wordt weggewerkt werk met vertical slices als milestone, indien mogelijk 16

17 Horizontal vs vertical slice Vertical slicing maakt het eenvoudiger om incremental releases uit te brengen Vertical slice lijkt meest nuttig na enkele iteraties van een horizontale: ( 17

18 Vertical slice in games volledig speelbare slice van een spel dat in alle opzichten representatief is voor het eindproduct stap voorbij prototype: geen grove schets, je kan zien hoe je ideeën uitpakken potentiële geldschieters verwachten tegenwoordig vaak vertical slice ipv prototype als demo controverse: book_excerpt_designing_.php?page= /08/why-vertical-slice-makes-game.html 18

19 Fase: 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) website/blog schrijven presentaties, promotiemateriaal 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

20 Fase: Analyse doel: het specificeren van vereisten (requirements) hoe kom je aan requirements? analyseren bestaande producten: wat overnemen, wat verbeteren? eigen analyse probleem: wat zou je zelf willen? opdrachtgevers documenten (toekomstige) gebruikers interviewen observeren als het een taak is die ze nu al uitvoeren use cases: scenario s van mogelijk gebruik customer reseller Browse Items Buy Items Get commission NB je krijgt veel minder tijd dan je voor deze stappen eigenlijk zou moeten nemen! 20

21 Soorten requirements User requirements: wat vraagt de gebruiker van het systeem? 1. ik moet kunnen printen, zonder teveel papier te verspillen System requirements: specificatie voor ontwerper 1.1 alleen plain text of PDF documenten kunnen geprint worden 1.2 printen kan dubbelzijdig, enkelzijdig, en twee-op-een in geval van landscape Beide soorten requirements kunnen onderverdeeld worden: functional requirements: eisen aan werking (functionaliteit; zie vbn) non-functional requirements: eisen aan bijkomende eigenschappen zoals betrouwbaarheid, veiligheid etc domain requirements: standaarden in organisatie, etc. 21

22 En dan.? maak een logische indeling van je requirements (classificeren, groeperen) geef prioriteiten aan en onderhandel bij eventuele conflicten (als verschillende stakeholders) Wees ambitieus, maar prioriteer! MoSCoW Must haves -eismoet in eindresultaat terugkomen, anders is het product niet bruikbaar en is het project gefaald; Should haves - eis is zeer gewenst, maar zonder is het product wel bruikbaar; Could haves - deze eis mag alleen aan bod komen als er tijd genoeg is; Won't haves - deze eis zal in dit project niet aan bod komen maar kan in de toekomst, bij een vervolg project, interessant zijn. tenslotte: documenteer 22

23 Eigenschappen vastgelegde requirements (IEEE830, 1998) correct: is dit inderdaad wat de gebruiker nodig heeft? niet-ambigu: is niets op meerdere manieren uit te leggen? compleet consistent: kan er tegelijk aan alle eisen voldaan worden? geordend: hoe belangrijk is elke eis? verifieerbaar: kunnen we besluiten dat er aan eisen voldaan is? traceerbaar: is van elke eis duidelijk waarom die moet gelden en waar die vandaan komt? veranderbaar: als inzichten veranderen, kunnen eisen dan eenvoudig aangepast worden zonder problemen met bovenstaande? 23

24 Fase: Ontwerp (software algemeen) doel: beschrijving of verbeelding van de 'oplossing' voor het gekozen probleem, en hoe dit vertaald gaat worden naar bijvoorbeeld programmacode. 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 (hoe ziet het product eruit?) vormgeving conceptueel scheiden van rest systeem: skin Een ander zou nu jouw idee uit moeten kunnen voeren! 24

25 Fase: Ontwerp (Game specifiek) Naast genoemde aspecten van software ontwerp speelt bij het ontwerpen van games ook een rol: gameplay, zowel inhoud en regels, als mechanics omgeving/levels/missions storyline characters gameloop art en sound 25

26 Fase: Implementatie programmeren toepassen kennis uit imperatief/game programmeren modulair opbouwen! 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 26

27 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 user-experience (o.a. playability) 27

28 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 101:

29 User experience belangrijk bij games: kwaliteit 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) 29

30 Wat moet je met deze info? je hoeft niet een bestaande methodiek voor software/gameontwikkeling 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 30

31 Werken in teamverband: dit project handleidingen van Centrum voor Onderwijs en Leren op vakwebsite Stephan Ramaekers, Samenwerken in een project Jasper van den Berg, Succesvol samenwerken in een project belangrijke onderwerpen voor jullie: projectgroep en functies welke functies zijn er in jullie groep? verantwoordelijkheden welke verantwoordelijkheden horen bij welke functies? samenwerken teambuilding taakverdeling communicatie, conflicthantering Team charter? Document dat doel van team definieert, hoe het werkt (bijv. sancties bij niet nakomen afspraken), wat verwachte uitkomsten zijn. werken in organisaties belangrijk onderdeel mensenleven 31

32 Samenwerken in (grotere) teams samenwerken is complex je kiest je partners niet uit je moet er samen uitkomen belangrijk zijn: duidelijkheid over rollen en taken goede communicatie heldere afspraken nakomen afspraken professionele houding conflicten zijn soms onvermijdelijk niet conflicten uit de weg gaan houd het zakelijk kunst: goede oplossing vinden conflict kan veel duidelijkheid scheppen 32

33 Rollen in teams teams kennen formele rollen projectleider programmeur designer maar ook informele rollen guru bemiddelaar troubleshooter hangen samen met persoonlijke kwaliteiten en gedrag belangrijk voor slagen teamwerk 33

34 Teamrollen volgens Belbin teamrollen van Belbin karakteriseren verschillende typen gedrag in organisatie mensen hebben meestal meer dan één rol doe-het-zelftest: welke rollen zijn er nodig in je project? zijn die er ook? kun je die ontwikkelen? meer informatie

35 Wat is communicatie? 'Communicatie is het scheppen van gemeenschappelijke betekenis.' (Gisela Redeker, hoogleraar communicatie, Groningen) Communicatie is de uitwisseling van symbolische informatie, die plaatsvindt tussen mensen die zich bewust zijn van elkaars aanwezigheid, onmiddellijk of gemedieerd. Deze informatie wordt deels bewust, deels onbewust gegeven, ontvangen en geïnterpreteerd. (moeilijke, maar veel gebruikte, definitie van Frank Oomkes) 35

36 Communicatietheorie Klassieke model (Shannon en Weaver, 1949) Schulz von Thun: vier betekenisaspecten 36

37 Voorbeeld: 4 monden Context: man en vrouw zitten thuis aan tafel Man: Er zit iets groens in de soep Vrouw: Als je het niet lekker vindt, dan kook je voortaan zelf maar Ik weet niet wat het is Iets is groen Vertel me wat het is! 37

38 Voorbeeld: 4 oren Context: man en vrouw zitten thuis aan tafel Man: Er zit iets groens in de soep Vrouw: Als je het niet lekker vindt, dan kook je voortaan zelf maar Jij weet niet wat dat groene is en dat vind je onplezierig Iets is groen Ik moet voortaan alleen ingredienten gebruiken die jij kent 38

39 Betekenissen en middelen zakelijke betekenis is niet enige (of belangrijkste!) andere betekenissen kunnen boodschap versterken nuanceren verzwakken bij miscommunicatie spelen betekenisaspecten grote rol tip: doorvragen! rol nonverbale communicatie ondersteunt begrijpen betekenissen geheel of gedeeltelijk uitgeschakeld bij gemedieerde communicatie zeker als die asynchroon verloopt telefoon, mail, SMS 39

40 Conflicten conflicten zijn soms onvermijdelijk niet conflicten uit de weg gaan conflict kan veel duidelijkheid scheppen redenen voor conflicten miscommunicatie tegengestelde belangen verantwoordelijkheden wel/niet nemen voortschrijdend inzicht vijandigheid, machtsspelletjes allergieën voor bepaald gedrag: iemand is doorgeschoten in een kernkwaliteit Kernkwaliteit: karakteristieke aangeboren eigenschap die handelen bepaalt ( Voorbeeld: kernkwaliteit: oplossingsgerichtheid valkuil: overal een oplossing voor klaar uitdaging: niet alles willen oplossen allergie: niet oplossen van problemen 40

41 Conflicten oplossen conflicten zijn vaak onvermijdelijk hebben meestal oorzaak in werkproces kunnen veel verduidelijken zie het als gelegenheid om een stap verder te komen conflicthantering geef emoties plek, maar laat niet domineren zo nodig neutrale 3e (gespreksleider, bemiddelaar) beide partijen hebben evenzeer recht hun punt te maken gebruik inhoudelijke, feitelijke argumenten zoek naar wat de partijen wel bindt werk naar oplossing die voor alle partijen acceptabel is voorbeeld met acteurs: 41

42 Feedback effectief feedback geven kan veel problemen voorkomen voorbeelden waardering tonen voor inzet en prestatie problemen en ergernissen bespreekbaar maken basisregels effectieve feedback ik-boodschap (feedbackgever beschrijft zijn/haar toestand) heb het over concrete feiten en gedrag (niet ter discussie) toekomstgericht (vind oplossing) onproduktief: jij-boodschap: beschrijf hoe de ander in elkaar zit vage, generaliserende uitspraken focus op verleden (kun je niet veranderen) toepassen op voorbeeld: problemen oplossen (kwadranten Ofman) onproduktief: jij komt altijd meteen met een oplossing produktief: waarderen oplossingen, maar uitleggen waarom dat voor mij in deze situatie niet goed is 42

43 Effectief communiceren: een uitdaging van cruciaal belang in projectteams brein als metafoor: werkt als verbindingen in orde zijn projecten vormen uitgelezen kans om communicatieve vaardigheden te verbeteren functies van communicatie in project: informatieuitwisseling afspraken maken en nakomen problemen signaleren teamvorming, commitment ondersteunen consensus bereiken conflicten voorkomen en hanteren gebruik gepaste communicatiemiddelen! urgentie, ernst situatie, emotie juist als boodschap geladen is, is directe communicatie beter Observeer en analyseer eens de communicatie: wat en hoe, waarom, wat is het effect? 43 Geef jezelf en anderen de kans om te experimenteren!

44 En verder Volgende keer: tools, rechten en resources (Wolfgang) Week/weken erna: gastcollege(s) Check regelmatig de vakwebsite! ICA: denk aan afspraak met studentassistent (zie Rooster en deadlines ) en begeleider GT: denk aan topic, analyse document, blogpost en teampage (zie vereisten voor deadlines en details) Succes weer! 44