IntroductieProject: Handvatten

Transcriptie

1 Faculteit Betawetenschappen, Departement Informatica IntroductieProject: Handvatten Paul Bergervoet 22 november 2016

2 Doel en inhoud van dit college We verwachten een academische houding: Denk na over wat je nodig denkt te hebben voor je project Ga zelf op zoek naar informatie en bruikbare tools Wees kritisch: op wat je doet, gebruikt, oplevert, jezelf, je teamleden We bieden wat handvatten om je op weg te helpen: Software ontwikkeling Tools en content Juridische aspecten Teamwerk en communicatie NB de versie van deze presentatie op de vakwebsite is uitgebreider dan het college! NB2 verschillende onderwerpen komen uitgebreider aan bod in vervolgvakken.

3 Software ontwikkeling

4 Vraag: Is software ontwikkeling wel academisch? Er bestaan ruwweg twee perspectieven op onderzoek. Onderzoek ten behoeve van: 1. Product ontwikkeling 2. Vergaren van wetenschappelijke kennis In de informatica worden deze perspectieven vaak gecombineerd THEORIE

5 Vraag: Wat is er nou zo moeilijk aan software ontwikkeling? bij software-ontwikkeling gaat het vaak om grote producten Implementeren = regel voor regel code schrijven: samenvoegen tot grotere eenheden bottom-up proces Product te groot om in één keer te overzien: onderscheiden componenten en subcomponenten top-down proces Hoe komen de twee processen succesvol bij elkaar? (er zijn vaak veel belangen en belanghebbenden in het spel!)

6 Wat kan er misgaan? verschillende belanghebbenden (stakeholders)

7 In de praktijk gaat het nogal eens mis Overal vind je minder geslaagde ICT producten zelfs aan de UU Nederlandse overheid gaf in M meer uit aan ICT dan gepland (bron: NRC, 16 juni 2010) Belastingdienst: ETM-project M Defensie: SPEER-project M CDA wil onderzoek naar ICT-projecten overheid (bron: 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) bron: Roger Sessions `ITComplexityWhitePaper, 2009: aper.pdf

8 Software-ontwikkeling is niet triviaal! Complexe taak technische beperkingen bestaande systemen, infrastructuur verschillende belangen stakeholders bv. zorgvuldigheid vs. snelle invoering communicatie problemen 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 voor software-ontwikkeling

9 Basisidee software ontwikkeling: fasen Globale hoofdlijn (details verschillen per methode) Planning: doel en fasering Analyse (wat moet de software doen?) verzamelen en opschrijven requirements Systeemontwerp (hoe werkt het systeem?) vastleggen in ontwerpdocument Bouwen: Coderen, documenteren en testen Opleveren Onderhoud

10 Fase: Planning (ook in dit project) 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!

11 Fase: Analyse (1) 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 Buy Items Get commission NB je krijgt nu veel minder tijd dan je voor deze stappen eigenlijk zou moeten nemen!

12 Fase: Analyse (2) 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.

13 Fase: Analyse (3) 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 - moet in eindresultaat terugkomen, anders is product niet bruikbaar en project gefaald; Should haves - zeer gewenst, maar zonder is product wel bruikbaar; Could haves Won't haves tenslotte: documenteer - mag alleen aan bod komen als er tijd genoeg is; - zal in dit project niet aan bod komen maar kan in toekomstig vervolg project interessant zijn.

14 Fase: Ontwerp (algemeen) Doel: beschrijving of verbeelding van de 'oplossing' voor het gekozen probleem, en hoe dit vertaald gaat worden naar bijvoorbeeld programmacode. Relevante aspecten van ontwerp: 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 Een ander team zou nu jullie idee uit moeten kunnen voeren!

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

16 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 Documenteren technische documentatie voor ontwikkelaars altijd te weinig! vooral hoog-niveau architectuur product behoeft documentatie

17 In alle fases: de 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 dus niet uitgaan van ideale (rationele) gebruiker rekening houden met menselijke eigenschappen is essentieel! perceptie, motoriek, geheugen cultuur, context (werk, sociaal) enz. belangrijke begrippen (zie ook INFOUE) Usability en user-experience (o.a. playability)

18 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

19 SCRUM: een agile softwareontwikkelmethode voor teams van ca. 7 mensen cyclische methode sprints van 30 dagen aan het begin: taken selecteren en verdelen aan het einde: werkende versie NB: dit betreft met name de implementatie fase; analyse en ontwerp heeft tot product backlog geleid!

20 SCRUM: een agile softwareontwikkelmethode 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

21 Software ontwikkeling: wat moet ik hiermee? We verwachten dat je binnen het introductieproject de hier besproken fasen doorloopt daarbij de vordering van het project bijhoudt planning bewaken aanpassen wanneer nodig We verwachten niet dat je een bestaande methodiek voor software/gameontwikkeling kiest Het hier besprokenen is slechts ter inspiratie voor eigen aanpak; wel is het advies om cyclisch te werken, en tussenproducten op te leveren bv. elke week een werkende volgende versie Meer over software ontwikkeling komt aan bod in vervolgvakken zoals het Software/Game project.

22 Tools voor software ontwikkeling

23 Tools for managing large projects Doing large projects requires lots of planning, organizing, managing, Various tools exist to assist you with Managing your product and organizing your data, code, Managing your team and organizing your workflow, communication, We advise you to use version control for code management, and force you to use logbooks & meetings for team management. But you are welcome to look around and use more.

24 Some pointers to related resources At UU (cf. links on course website): Blackboard for project management (group rooms, wikis, ) UniTeams for project space, wikis, etc. Projectspace voor studenten And more (see Other (again, cf. links on course website): Google Code & Google Docs &

25 Code management revision control Various tools exist to support the actual implementation & testing. Important tools are those for revision control. Revision control (or version control) = the management of changes to documents, programs, and other information stored as computer files (from Wikipedia)

26 Code management revision control Keeps all code in a repository. Allows you to checkout code to work on it. Enables you to commit and merge code. Examples: SVN Git

27 Version control etiquette The best tool is only as good as the people using it. Some etiquette: Only commit code that compiles! You are part of a team. Don t let others debug your code. Commit only material that you created yourself E.g. source code, documentation, essential content, Commit no material that gets generated E.g. no executable, no PDF, Why? SVN/Git etc keep everything! Executable can be too big (storage & server overload) There s no need. Everyone can create it themselves.

28 Tools en content voor promotie en presentatie

29 Overview additional material In addition to creating the code & executable & docs, your final product/game also has to be Promoted, e.g. via a website a video (only GT) promotional material Presented, e.g. to the jury (rating & nominations) the public (hands on session at symposium) the award committee (if you are one of the chosen ones)

30 Promotion material general hints Save time (and create corporate identity) by using one design for all 3 (or 4) Check related how-to links and tips on course website Check (& critically evaluate) examples from last year Design for target audience and intended purpose!

31 Actual tools to create these Website: any (HTML) editor should do it; alternative: use a CMS, e.g. WordPress, Joomla (but requires database + php!) Flyer & box cover: MS Office tools (works quite well & easy to learn) Adobe tools (if you have experience with that) Free software (e.g. Gimp, ) Videos: Screen capturing software, e.g. Camtasia Studio (30 days trial) Video editing software, e.g. VirtualDub (free) Audio processing software, e.g. Audacity (free) Tools on your Macs & PCs (imovie, Microsoft Movie Maker) You find some links on the course website. Note: these are also helpful to create content for your product.

32 Juridische aspecten

33 MOST IMPORTANT WARNING! In a previous year one team from the software project got in trouble using an apparently copyrighted image on their website. To avoid any trouble: Only use legal material that you are allowed to use! When in doubt, don t use it. Put a disclaimer on all public material (e.g. your blog/website)! Think twice before making your game/product downloadable.

34 Rechten online materiaal is niet rechtsvrij belangrijk bij gebruik materiaal in professionele situatie terrein is sterk in beweging nieuwe technische ontwikkelingen pressie vanuit content- en software-industrie eindgebruikers hechten aan informatievrijheid diverse rechten van intellectueel eigendom auteursrecht naburige rechten databaserecht zie ook vak Recht en Informatica verschillende artikelen (legale online toegang via UBU)

35 Rechten op digitaal materiaal online content valt onder auteursrecht kennisneming is nauwelijks beperkt lokale kopie (bv. in cache) is toegestaan delen is onrechtmatig (dus ook torrent-protocol) downloaden van illegale sites is tegenwoordig punt discussie openbaarmaking is aan regels gebonden regel rechten goed in professionele producten je kunt natuurlijk de auteur betalen veel auteurs vinden verspreiding belangrijker dan exploitatie stellen werk onder voorwaarden gratis beschikbaar doen meestal geen afstand van rechten

36 Creative Commons (CC) biedt auteurs, kunstenaars, wetenschappers, docenten en alle andere creatieve makers de vrijheid om op een flexibele manier met hun auteursrechten om te gaan licentiemodellen voor kosteloos gebruik van digitale content juridisch goed beschermd jurisprudentie: Adam Curry vs. Weekend (2006) meer info op &

37 Creative Commons (CC) 4 licentievoorwaarden mogelijk attribution share alike (give credit) (new license under same terms) non-commercial no derivative work (redistribute without change) 6 combinaties hiervan:

38 Open Source essentie: gratis programmacode en ook gecompileerde versies business model: software gratis, services kosten geld geen afstand van auteursrecht! belangrijke grote toepassingen Linux, Mozilla (Firefox, Thunderbird), Open Office van alles op verschillende licentievormen regelen zaken als kopiëren, bewerken en toepassing GNU General Public License streng, toepassing maakt hele product Open Source GNU Lesser Public License staat ook commerciële toepassing toe en nog vele andere licentievormen schending voorwaarden is inbreuk op auteursrecht

39 Wetenschappelijke kennis literatuur publicaties vallen onder auteursrecht vaak overgedragen aan uitgevers vragen veel geld voor online toegang veel discussie over juistheid hiervan open access tijdschriften pre-prints op web citaatrecht kennis kan vrijelijk worden toegepast morele verplichting tot citeren algoritmen vallen niet onder auteursrecht (beschermt de vorm) kunnen wel onder octrooi vallen (beschermt het idee)

40 Creative Commons examples Soundcloud (music, sounds) Jamendo (music, paid licenses for commercial usage) Freesound (sounds, no music) Wikimedia commons (photos, videos) Social media sharing platforms, such as (photos) Bottom line: there s lots of stuff out there that you can legally use, but make sure to always check the license information!

41 Eerlijke Wetenschap

42 Welk recht heb je op je eigen werk? eigen bedrijf is van jou vrije tijd is van jou vervaardigd in opdracht recht bij werk- of opdrachtgever overeenkomst vereist vervaardigd voor opleiding je eigen inbreng is van jou i.h.a. ook grote inbreng opleiding meer info:

43 Mag je een retrogame nabouwen? het oorspronkelijke spel is beschermd auteursrecht wellicht octrooirecht voor onderwijs en eigen gebruik is OK distribueren is een schending van rechten! maken van een film, afbeeldingen en documenten over de game is toegestaan conclusie: neem geen risico s

44 Recommendation: Use a disclaimer Put a disclaimer on your website/blog stating that: This is an educational project There is no commercial interest behind it You are only using copyright free and legal data Ask people to contact you if you accidentally used inappropriate material There are many examples and samples online. Search for them and make one that is suitable for your site.

45 Recommendation: Disclaimer example Here s what you could write: This site and its content are part of an educational project done during a course in the computer science curriculum at Utrecht University. Its sole purpose is educational and there are no commercial interests involved. We carefully checked all material to make sure not to violate any copyrights or other legal rights. If inappropriate content is used accidentally, please inform us and we will be happy to remove it promptly. You also could consider adding a note about Fair use policy: But note that this only covers United States copyright law. Further note that you are encouraged to be creative and make your own graphics, sounds, etc.

46 Disclaimer I m not a lawyer. This was no legal advice. I take no responsibility for the correctness of the information that I just provided to you.

47 Teamwerk en communicatie

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

49 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

50 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

51 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:

52 Wat is communicatie? 'Communicatie is het scheppen van gemeenschappelijke betekenis.' (Gisela Redeker, hoogleraar communicatie) 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)

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

54 Communicatie: 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

55 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 voor gedrag: iemand is doorgeschoten in een kernkwaliteit (Kernkwaliteit: karakteristieke aangeboren eigenschap die handelen bepaalt)

56 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:

57 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) onproductief: jij-boodschap (beschrijft hoe de ander in elkaar zit) benoem concrete feiten en gedrag (staan niet ter discussie) onproductief: vage, generaliserende uitspraken toekomstgericht (vind oplossing) onproductief: focus op verleden (kun je niet veranderen)

58 Feedback en kernkwaliteiten: een voorbeeld Kernkwaliteit: karakteristieke aangeboren eigenschap die handelen bepaalt ( Kwadranten van Ofman: Voorbeeld: kernkwaliteit: oplossingsgerichtheid valkuil: overal een oplossing voor klaar uitdaging: niet alles willen oplossen allergie voor: niet oplossen van problemen Feedback: onproduktief: jij komt altijd meteen met een oplossing produktief: waarderen oplossingen, maar uitleggen waarom dat voor mij in deze situatie niet goed is

59 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 teamvorming, commitment ondersteunen consensus bereiken problemen signaleren 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? Geef jezelf en anderen de kans om te experimenteren!

60 En verder Vragen? Nu helemaal zelf aan de slag met deze handvatten! Geen inhoudelijke colleges meer Komende weken: gastcollege(s) ( arbeidsmarkt perspectief) zelf presenteren Check regelmatig de vakwebsite! Denk aan je deliverables en deadlines! Veel plezier en succes!