Software engineering and team work (PDF)

Introductieprojecten
Informatica en
Gametechnologie
Teamwerk en softwareontwikkeling
november 2014
Silja Renooij
(met dank aan Frans Wiering)
1
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
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
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
In informatica vaak een
computationeel model
4
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
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
Wat kan er misgaan?
verschillende belanghebbenden (stakeholders)
7
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€
“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;
https://dl.dropboxusercontent.com/u/97323460/WebDocuments/White
Papers/ITComplexityWhitePaper.pdf
8
ICT en politie (1)
 centrale ict-systeem: Basisvoorziening Handhaving (BVH)
 ingevoerd vanaf 2007
 Computable, 26-3-2009
 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
zijn er wat kinderziektes”
bron:
http://www.computable.nl/artikel/ict_topics/crm/2909157/2333360/gebruikersontevreden-over-ictsysteem-politie.html#ixzz15GhBQH3d
9
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: http://www.it-executive.nl/content/redactioneel/politietop-hield-kritisch-rapport-overfalend-it-systeem-onder-de-pet
Rapport: http://www.rijksoverheid.nl/bestanden/documenten-enpublicaties/kamerstukken/2010/11/08/basisvoorziening-handhaving-22544/basisvoorzieninghandhaving-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’.
20-09-2011 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
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
Globale hoofdlijn:
 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
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
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 te doen, problemen
 voortgang in ‘burndown chart’
 laat zien hoe de ‘product backlog’ wordt weggewerkt
 werk met ‘vertical slices’ als milestone, indien mogelijk
16
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:
(http://uber.typepad.com/birthofagame/2009/04/vertical-slice-vs-horizontal-layer.html)
17
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:
http://www.gamecareerguide.com/features/375/
book_excerpt_designing_.php?page=3
http://grassrootsgamemaster.blogspot.com/
2007/08/why-vertical-slice-makes-game.html
http://grumpygamer.com/6843121
18
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
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
Browse Items
customer
reseller
20
Buy Items
Get commission
NB je krijgt veel minder
tijd dan je voor deze
stappen eigenlijk zou
moeten nemen!
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
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 - eis moet 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
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
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
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
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
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
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
28
User experience
 belangrijk bij games: kwaliteit ‘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)
29
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
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
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
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
Teamrollen volgens Belbin
 teamrollen van Belbin
 karakteriseren verschillende typen gedrag in organisatie
 mensen hebben meestal meer dan één rol
 doe-het-zelftest: http://www.youtube.com/watch?v=B5oB8PhS64Q
 welke rollen zijn er nodig in je project?
 zijn die er ook?
 kun je die ontwikkelen?
 meer informatie
www.belbin.com
 http://nl.wikipedia.org/wiki/Meredith_Belbin
 http://www.thesis.nl/Teamrollen-van-Belbin/

34
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
Communicatietheorie
 Klassieke model
(Shannon en Weaver, 1949)
 Schulz von Thun: vier betekenisaspecten
36
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
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”
Iets is groen
Jij weet niet
wat dat groene
is en dat vind
je onplezierig
Ik moet
voortaan alleen
ingredienten
gebruiken die
jij kent
38
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
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 (http://www.scienceprogress.nl/effectiviteit/kernkwadrant-ofman)
Voorbeeld:




40
kernkwaliteit: oplossingsgerichtheid
valkuil: overal een oplossing voor klaar
uitdaging: niet alles willen oplossen
allergie: niet oplossen van problemen
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: http://www.youtube.com/watch?v=JIFNF9YMeTY
41
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
http://www.youtube.com/watch?v=LdIrI2301Ag
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!
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