problem solving F. Vonk versie

Transcriptie

1 2017 problem solving F. Vonk versie

2 inhoudsopgave 1. inleiding soorten problemen decompositie timeboxen oplossingen genereren de beste oplossing kiezen voor- en nadelen in kaart brengen de beste oplossing kiezen je keuze uitleggen documentatie wijzigingen triviaal en niet-triviaal in de praktijk Dit werk is gelicenseerd onder een Creative Commons Naamsvermelding NietCommercieel GelijkDelen 3.0 Unported licentie Dit werk is gebaseerd op Android Apps met App Inventor; Coen Crombach, Robin Eggenkamp, François Vonk; 1 november De afbeelding op het voorblad is verkregen via INFOwrs. Copyright 2010 INFOwrs Serviços em informatica

3 1. inleiding Om leuke en interessante computerprogramma's te maken moet je leren om problemen op te lossen. Een leuke game of app komt niet zomaar aanwaaien, het maken ervan gaat meestal gepaard met de nodige uitdagingen en hopelijk vind je dat leuk! De eerste oplossing die je bedenkt of vindt voor een probleem is niet altijd de beste. Toch bedenken of zoeken veel mensen een oplossing en gaan die dan meteen gebruiken of maken. Als de oplossing dan niet werkt, is er kostbare tijd verloren gegaan. Het is nog veel erger als de oplossing op korte termijn werkt, maar op de lange termijn niet en dan veel tijd kost om aan te passen. In Figuur 1 zie je de stappen die je moet doorlopen om een probleem effectief op te lossen. Technieken om toe te passen in stappen 1 tot en met 3 worden in deze module behandeld. Stap 4 hangt sterk af van het probleem dat je op aan het lossen bent en de context. Deze stap wordt hier daarom niet behandeld. Bij software ontwikkeling doen we stap 5 vaak via het testen van de software aan de hand van de eisen en daarover heb je al het een en ander geleerd. Figuur 1: De cyclus voor het effectief oplossen van problemen. 1 Welkom bij de module problem solving. Deze module gaat je leren hoe je gestructureerd problemen op kunt lossen. Deze manier moet je in de projecten verder trainen bij het vak

4 In deze module kom je opgaves tegen die je moet maken om de lesstof te verwerken. De antwoorden kunnen in de les besproken worden. opgave Opgaves in blauw moet je maken. Let op, links in dit document hebben een rode kleur. Veel plezier en succes

5 2. soorten problemen Problemen heb je in alle soorten en maten. Je hebt kleine problemen, grote problemen, makkelijke problemen, moeilijke problemen, saaie problemen, leuke problemen, interessante problemen, uitdagende problemen enzovoorts. Een probleem dat interessant is voor de ene persoon, hoeft dat niet noodzakelijk te zijn voor een ander. Sterker nog voor die andere persoon zou het best wel eens een saai probleem kunnen zijn. Termen zoals saai, leuk, interessant, uitdagend enzovoorts zijn subjectief. De termen klein, groot, makkelijk en moeilijk zijn dat al een stuk minder. Daarom gaan we nu naar deze soorten problemen kijken. Mensen lossen graag kleine en makkelijke problemen op, omdat ze dan snel feedback krijgen en beloond woorden. Het meeste geld valt echter te verdienen met het oplossen van grote en moeilijke problemen. Er zijn namelijk veel minder mensen die grote en moeilijke problemen kunnen oplossen, dan mensen die kleine en makkelijke problemen kunnen oplossen. In de projecten, die je over een tijdje gaat uitvoeren bij informatica, ga je best veel makkelijke problemen tegenkomen. Denk hierbij aan problemen waarvoor je de oplossing al kent. Of problemen waarvoor je de oplossing op moet zoeken, omdat je het niet zelf kunt bedenken. Een voorbeeld daarvan is een webpagina een achtergrond geven. Als je niet weet hoe je dat moet doen, dan moet je dat gewoon opzoeken. Het oplossen van makkelijke problemen is fijn, want het geeft snel beloning en houdt je gemotiveerd. Of een makkelijk probleem nu groot of klein is heeft vaak alleen invloed op de oplostijd. We noemen makkelijke problemen ook triviale problemen

6 2 3 Als het gaat om leren, dan zijn echter de moeilijke problemen het meest interessant. Daarbij kunnen mensen vaak beter omgaan met kleine en moeilijke problemen, dan met grote en moeilijke problemen. Bij grote en moeilijke problemen raken veel mensen het overzicht kwijt. Het vaak verleidelijk om de oplossing op te zoeken voor moeilijke problemen, bijvoorbeeld op het internet. Op het moment dat je dat doet en je vindt ook een oplossing, dan is het probleem een triviaal probleem geworden. Immers, de oplossing kun je zo overnemen. Soms kun je echter geen oplossing vinden voor een moeilijk probleem, omdat het nog niet opgelost is. In dat geval spreken we van een niettriviaal probleem. Ook als je besluit de oplossing voor een moeilijk probleem niet op te zoeken, maar het probleem zelfstandig aan te pakken is het voor jou een niet-triviaal probleem. Specifiek bij software ontwikkeling onderscheiden we nog 2 categorieën problemen: nieuwe problemen en bugs. Nieuwe problemen zijn problemen waar nog geen code voor geschreven is. De code moet nog aan de software toegevoegd worden. Bugs zijn problemen die optreden, omdat we gemaakte software uitvoeren waarbij die software niet werkt zoals bedoeld mkbvisie.wordpress.com/2013/09/29/subsidiebureaucratie/ - 6 -

7 3. decompositie Zoals gezegd vinden mensen het moeilijker om grote problemen op te lossen dan kleine. Dat komt, omdat grote problemen vaak minder overzichtelijk zijn. Overzicht creëren bij grote problemen doe je door ze op te splitsen in deelproblemen. Op die manier maak je van 1 groot probleem meerdere kleine problemen. Dit noemen we decompositie. Je stopt doorgaans met de decompositie als je allemaal kleine problemen over hebt. Stel je hebt een lekke fietsband en die moet je zelf plakken, maar je woont net in je studentenflat en hebt nog geen reparatiespullen. Dit probleem zou je als volgt kunnen opsplitsen. Uitzoeken welke reparatiespullen je allemaal nodig hebt. Reparatiespullen kopen. Eventueel uitzoeken hoe je een fietsband plakt. Reparatiespullen klaarleggen binnen handbereik. Gat of gaten in de fietsband zoeken. Fietsband plakken. Testen of het plakken gelukt is en de band niet meer leegloopt. Soms is een probleem zo groot, dat sommige deelproblemen nog steeds groot zijn. Dan kun je natuurlijk weer decompositie op die deelproblemen toepassen. Blijf net zolang decompositie doen tot je alleen kleine problemen overhoudt. Die kun je dan vervolgens gaan oplossen. Feitelijk is in het fietsband plakken voorbeeld de taak "Fietsband plakken" nog verder op te splitsen. Buitenband van de velg halen. Ventiel los maken van het velg. Binnenband van de velg halen. Binnenband oppompen, gat zoeken en weer gedeeltelijk leeg laten lopen. Lijm rond en op het gat doen en even laten drogen. Plakker erop doen en stevig aangedrukt houden. Binnenband weer oppompen en kijken of de band niet meer leegloopt. Binnenband terugleggen op de velg. Ventiel vastmaken op de velg. Buitenband op de velg leggen

8 De vraag of je "Fietsband plakken" nog op moet splitsen is een goede vraag. Het hangt er met name vanaf of je al ooit een fietsband hebt geplakt. Als je vaker een fietsband plakt, dan kun je ervoor kiezen "Fietsband plakken" niet meer verder op te splitsen. In dat geval hoef je waarschijnlijk het hele probleem niet op te splitsen. Wanneer je klaar bent met het oplossen van alle deelproblemen, moet je daarna goed controleren of het oorspronkelijke (grote) probleem ook echt opgelost is. Het zou bijvoorbeeld best kunnen zijn: dat je tijdens je decompositie niet alle deelproblemen hebt geïdentificeerd, dat je 1 deelprobleem bent vergeten op te lossen, dat je een deelprobleem fout hebt opgelost in de context van het oorspronkelijke probleem of dat de oplossingen van een aantal deelproblemen niet goed samenwerken. Een ander voorbeeld van decompositie is het toevoegen van intro muziek aan je beginmenu van je GameMaker game. Dit probleem zou je als volgt op kunnen splitsen. Bepalen welke muziek past bij de doelgroep. Muziek zoeken. Bepalen hoe de speler het liefst het geluid aan en uit zet. Bepalen of de speler wil dat de muziek direct gaat spelen of niet. Gebruikersinterface aanpassen zodat het geluid aan- en uitgezet kan worden. Muziek toevoegen aan GameMaker. Eventueel code schrijven om de muziek aan te zetten als de game start. Code schrijven om de muziek aan- en uit te zetten. Eventuele alternatieven en ontwerpkeuzes documenteren. Testen of alles werkt. Tot nu toe heb je twee voorbeelden van decompositie van hoeveelheden werk gezien. Het is uiteraard ook mogelijk voor bijvoorbeeld technische problemen. Een voorbeeld geven van een groot technisch probleem is hier niet praktisch. Daarom illustreren we het idee aan de hand van een klein technisch probleem

9 Stel je wilt een programma voor een schrikkeljaargenerator maken. De generator moet aan de volgende eisen voldoen: Het programma laat de gebruiker een onder- en bovengrens invoeren. Daarna genereert het programma alle schrikkeljaren tussen de grenzen en druk ze overzichtelijk af. Hierin kun je de volgende deelproblemen: Correct afhandelen van de gebruikersinvoer. Bepalen of een jaartal een schrikkeljaar is. Genereren van jaartallen tussen de onder- en bovengrens. Overzichtelijke uitvoer genereren. Deze decompositie ziet er schematisch als volgt uit: Vervolgens is het natuurlijk ook belangrijk om op te schrijven waarom de decompositie er zo uitziet. In dit geval hebben we manage en genereer jaartallen samengenomen, omdat we het genereren van de jaartallen zien als managen van de aangeboden jaartallen. De drie bollen daaronder zijn een goed voorbeeld van het input - bewerk - output mechanisme, dat we bij veel software systemen zien. Het doel van zo'n systeem is immers dat je data (invoer) bewerkt tot informatie (uitvoer)

10 4. timeboxen Problemen oplossen kan tijdrovend zijn. Het is daarom belangrijk om van tevoren te bepalen hoe lang je met een probleem bezig mag zijn. Dit noemen we timeboxen. Om dit goed te kunnen inschatten moet je van tevoren inschatten met wat voor soort probleem je te maken hebt. Er zijn problemen die ontstaan, omdat je slordig bent geweest. Je bent bijvoorbeeld de teller van een loop vergeten op te hogen. Je hebt geen puntkomma achter een instructie gezet terwijl dat wel moet. Je bent de haakjes na een if vergeten. Je hebt een < gebruikt in plaats van <= enzovoorts. Slordigheidsfouten kun je meestal relatief snel oplossen. Bij andere fouten is het echter belangrijk om een gestructureerde aanpak te gebruiken. Je weet intussen, dat je bij informatica eerst dingen zelf moet proberen uit te zoeken. Daarom is leren timeboxen belangrijk. Je kunt het je namelijk niet veroorloven, om voor ieder probleem een hele les naar de oplossing te zoeken. Als je dat voor alle kleine en makkelijke problemen doet, dan kom je in tijdnood. Je zou bijvoorbeeld met jezelf kunnen afspreken, dat je maximaal 5 minuten mag zoeken naar een oplossing voor een klein en makkelijk probleem. Daarna ga je iemand om hulp vragen. Vervolgens mag je nog maximaal 10 minuten zoeken naar 2 alternatieven voor je hulp vraagt. Voor een groot en moeilijk probleem ga je eerst decompositie doen. Mogelijk houd je dan toch nog een klein en moeilijk probleem over. Voor een klein en moeilijk probleem mag je misschien wel een halve les uittrekken voor je om hulp gaat vragen. Vervolgens zou je nog een halve les kunnen zoeken naar 2 alternatieven. De hiervoor genoemde tijden zijn voorbeelden. Helaas zijn er geen universele tijden te noemen voor het timeboxen van het zoeken naar oplossingen en alternatieven. Die zijn persoonlijk en moet je door ondervinding voor jezelf bepalen. Ben ook niet bang om hiermee te spelen

11 5. oplossingen genereren In dit hoofdstuk gaan we kijken naar het oplossen van nieuwe problemen. Dat doen we aan de hand van een voorbeeld. In dit voorbeeld kijken we naar het spel Hoger-Lager. Stel persoon A kiest een getal tussen de 1 en 100, waarbij de grenzen meedoen. Persoon B moet het antwoord raden en krijgt van persoon A feedback of hij/zij hoger of lager moet raden. Hoe vind je dan het snelst het gekozen getal? Het antwoord is: "Dat hangt ervan af." Er zijn meerdere mogelijkheden om het gekozen getal te vinden. Je kunt random gaan raden met gebruik van feedback. Je kunt bij 1 beginnen en steeds een getal 1 verder raden. Je kunt bij 100 beginnen en steeds een getal 1 terug raden. Je kunt een slimme strategie gebruiken, die zo meteen beschreven wordt. En zo zijn er nog veel meer mogelijkheden. Wanneer het gekozen getal 1 is, dan is het handig om bij 1 te beginnen. Zelfs als het getal 3 is, dan is het nog steeds prima om bij 1 te beginnen. Wanneer het getal echter 98 is, dan niet. Je kunt dan beter bij 100 beginnen. Een beter te beantwoorden vraag is: "Hoe vind je gemiddeld het snelste getal?". Een slimme strategie daarvoor is steeds het interval in tweeën te delen, waarbij je op hele getallen afrondt. Dus bij [ ] kies je 50 of 51, afhankelijk van hoe je afrondt. Stel we nemen 50 en het gekozen getal is hoger dan 50, dan pak je vervolgens het midden van [ ], dus 75 of 76. Als het gekozen getal lager is dan 50, dan pak je het midden van [1.. 49], dus 25. In het slechtste geval heb je dan 2 log(100) = 6,64 ~ 7 pogingen nodig. Je moet je dus altijd bewust zijn van het feit, dat de eerste oplossing die je bedenkt, niet automatisch de meest handige is! Stel je bedenkt een oplossing en gaat die meteen maken. Je loopt dan de kans, dat de oplossing niet werkt en je daarmee onnodig tijd verliest. Erger nog is het als de oplossing lijkt te werken, maar later niet goed blijkt te zijn. In dat geval kunnen andere stukken code afhangen van de foute oplossing en moet je veel meer doen dan alleen de foute oplossing fixen. Kortom, bij het oplossen van problemen moet je altijd meerdere oplossingen (alternatieven) bedenken of zoeken en afwegen welke oplossing de beste is of lijkt. Technieken om alternatieven te genereren heb je al geleerd, onder andere bij Quest. Een goede en veel gebruikte techniek is brainstormen. Dat hoeft niet altijd in een grote brainstorm sessie, maar kan ook individueel en kort. Een ander alternatief is een woordspin gebruiken

12 Let op, dat je bij het genereren van alternatieven ook doet aan timeboxen! Soms kom je, na een tijdje nadenken, niet op meer dan 1 oplossing. Dat kan gebeuren. Er zijn dan technieken om op basis van die ene oplossing alternatieven te genereren. Een techniek hiervoor heet SCAMPER. Dit staat voor: Substitute: Vervang een deel van je product door iets anders. Combine: Combineer je product met een ander product. Adapt: Pas je product als geheel aan. Modify, Magnify or Minify: Voeg iets toe aan je product of verander de grootte. Put to other uses: Vind een andere gebruik voor je product. Eliminate: Verwijder iets uit je product. Rearrange: Verander de ordening van delen van je product. 4 Hier wat voorbeelden: Substitute: Vervang de ijzers van schaatsen door wielen. Combine: Combineer een hotel met een appartement en krijg een motel. Adapt: Lego blokken als afgeleide van houten blokken. Modify, Magnify or Minify: Een Big Mac als afgeleide van een hamburger. Put to other uses: Een camper als afgeleide van kleine vrachtwagen. Eliminate: Haal 1 wieltje weg uit skeelers en krijg skates. Rearrange: Gebruik de vulling van de snoep als buitenkant en omgekeerd

13 SCAMPER is van origine bedoeld om vanuit een bestaand product nieuwe producten te genereren. Delen van de techniek kun je echter ook gebruiken om tot alternatieven voor een oplossing van een softwareprobleem te komen. De geschikte delen zijn: Substitute valt goed te gebruiken. Door een deel van je oplossing te vervangen door een andere deeloplossing kan de hele oplossing beter worden. Modify is ook geschikt (al zijn magnify en minify dat niet). Door iets aan je oplossing toe te voegen kan je de oplossing mogelijk verbeteren. Eliminate is feitelijk essentieel. Door iets uit je oplossing te verwijderen kan deze sneller en overzichtelijker worden. Dit zou eigenlijk een standaard controle moeten zijn bij het genereren van oplossingen voor softwareproblemen. Rearrange is ook bijzonder belangrijk. Code wordt altijd in volgorde uitgevoerd, dus de volgorde van dingen veranderen kan zeer positief werken op de snelheid en het effect van een oplossing. Je gaat nu beginnen met leren alternatieven te genereren. Dat werkt het beste door te oefenen en dat ga je dan ook doen. Er volgen een aantal opdrachten waarvoor je per opdracht tenminste 3 mogelijke oplossingsstrategieën moet zoeken. We zijn dus op het moment nog niet direct geïnteresseerd in de oplossing, maar in manieren waarop we een oplossing vinden! opgave De munteenheid in een fictief land heet BIBRA. Er zijn zes verschillende soorten bankbiljetten: 1 BIBRA 2 BIBRA 4 BIBRA 8 BIBRA 16 BIBRA 32 BIBRA Je moet 50 BIBRA betalen voor een smartphone. Hoeveel bankbiljetten heb je minimaal nodig om een smartphone te betalen? Bedenk 2 strategieën, kies de beste en licht je keuze toe. 5 Dit is een omgeschreven opgave uit de Beverwedstrijd eerste ronde voor klassen 3 en 4 van

14 opgave De Kinderspeelzaal is een speelzaal voor kinderen tussen de 3 en 5 jaar. De speelzaal is dag geopend is van 9 uur in de morgen tot 6 uur in de middag. Er zijn zes kinderen die op een dag naar de speelzaal gaan om te spelen. Ze komen allemaal op hun eigen tijdstippen. Sommige kinderen komen meerdere keren op dezelfde dag. Het volgende schema laat zien van hoe laat tot hoe laat alle kinderen aanwezig zijn. kind A 09:00-12:00 14:00-15:00 16:00-18:00 kind B 10:00-13:30 16:00-17:00 kind C 11:30-13:00 16:30-18:00 kind D 11:00-13:00 kind E 10:00-13:00 14:30-17:00 kind F 09:00-10:30 16:00-18:00 Elke kind dat komt spelen moet met een eigen stuk speelgoed kunnen spelen. Wat is het minimum aantal stukken speelgoed dat in de speelzaal aanwezig moet zijn, zodat er altijd genoeg is voor de aanwezige kinderen? Bedenk 2 strategieën, kies de beste en licht je keuze toe. 6 Dit is een omgeschreven opgave uit de Beverwedstrijd finale voor klassen 1 en 2 van

15 opgave In het Wilde Westen heeft de Stagecoach Company een postkoetslijn tussen acht nederzettingen (1 tot en met 8) opgericht. In de dienstregeling staat naast elke nederzetting aangegeven op welke dag in de week een postkoets vertrekt. Een postkoets vertrekt in de morgen en komt dezelfde dag in de avond aan. Via welke route wordt een pakket op de snelste manier van nederzetting 1 naar nederzetting 8 vervoerd? Bedenk 2 strategieën, kies de beste en licht je keuze toe. 7 Dit is een omgeschreven opgave uit de Beverwedstrijd eerste ronde voor klassen 3 en 4 van

16 6. de beste oplossing kiezen 6.1. voor- en nadelen in kaart brengen Voor je de beste oplossing kunt kiezen, moet je eerst de voordelen en nadelen in kaart brengen. Let op, dat je een voordeel van het ene alternatief vaak kunt je omschrijven en er een nadeel van een ander alternatief van kunt maken. Laten we dit illustreren aan de hand van een voorbeeld. In het vorige hoofdstuk hebben we gekeken naar het spel Hoger-Lager. Daarbij heb je een aantal alternatieve oplossingen gezien. We gaan er nu 3 uiteenzetten te weten: 1. Random raden met gebruik van feedback. 2. Bij 1 beginnen en steeds 1 verder raden. 3. De slimme strategie die uitgelegd is in het vorige hoofdstuk. 1. random 2. begin bij 1 3. slim Je hoeft er niet bij te rekenen. Je hoeft er niet bij na te denken. Is gemiddeld het snelst. Voordelen Is gemiddeld sneller dan beginnen bij 1. Je gebruikt de feedback. Je gebruikt de feedback. Nadelen Is gemiddeld langzamer dan de slimme strategie. Je negeert de feedback. Duurt gemiddeld het langst. Je moet erbij rekenen. Je ziet nu bij random het voordeel "Je hoeft er niet bij te rekenen." Bij de slim strategie zie je het nadeel "Je moet erbij rekenen." Dit is zo n typisch voorbeeld van een vergelijkbare uitspraak die bij het ene alternatief een voordeel en bij het andere alternatief een nadeel is. Toch kan het geen kwaad om beide op te schrijven. Je moet er bij het kiezen van het beste alternatief natuurlijk wel rekening mee houden, dat het feitelijk dezelfde uitspraak is

17 Of iets een voordeel of nadeel is hangt uiteraard ook af van de context van het probleem. De context is de omgeving waarin zich een probleem afspeelt. Wat in de ene context een nadeel van een oplossing is, is in een andere context mogelijk een voordeel. In het voorgaande voorbeeld hebben we het "moeten rekenen" aangemerkt als iets negatiefs. Dit hoort bijvoorbeeld bij een context waarin de radende persoon niet van rekenen houdt of er geen zin in heeft. In een context waarin die persoon rekenen juist leuk vindt, zou het precies omgekeerd zijn. Het is belangrijk dat je voor- en nadelen overzichtelijk opschrijft. Dat maakt het maken van een keuze makkelijker omdat je een goed overzicht hebt van alle voor en nadelen. Laten we het voorgaande overzicht van voor- en nadelen eens in een ander formaat opschrijven. Bij random hoef je niet rekenen. Je bent echter gemiddeld langzamer dan wanneer je de slimme strategie gebruikt. Maar daarbij moet je natuurlijk wel rekenen en dat is lastig. Als je begint bij 1 hoef je niet eens echt na te denken en dus ook niet te rekenen. Je negeert gewoon de feedback die je van de ander krijgt en dat is eigenlijk ook weer niet handig. Daar komt nog bij, dat je gemiddeld ook nog eens trager bent dan random en dus ook dan via de slimme strategie. Hier volgen nog een aantal voorbeelden van hoe je voor- en nadelen overzichtelijk kunt beschrijven. Voorbeeld 1. Voordelen van random: Je hoeft er niet bij te rekenen. Is gemiddeld sneller dan beginnen bij 1. Je gebruikt de feedback. Nadelen van random: Is gemiddeld langzamer dan de slimme strategie

18 Voorbeeld 2. Random: + - Je hoeft er niet bij te rekenen. Is gemiddeld langzamer dan de slimme strategie. Is gemiddeld sneller dan beginnen bij 1. Je gebruikt de feedback. Voorbeeld 3. Random: + - Je hoeft er niet bij te rekenen. Is gemiddeld langzamer dan de slimme strategie. Is gemiddeld sneller dan beginnen bij 1. Je gebruikt de feedback. Misschien kun je zelf nog wel een overzichtelijkere manier vinden. Als je 2 of 3 alternatieven hebt, dan is de eerste tabel die je gezien hebt geschikt, omdat je alles bij elkaar hebt staan in 1 tabel. Als je meer dan 3 alternatieven hebt, dan kan alles in 1 tabel stoppen onoverzichtelijk worden. Je kunt dan 1 van de andere goede voorbeelden kunnen gebruiken. Je zou natuurlijk in plaats van een Word tabel te gebruiken een Excel spreadsheet kunnen gebruiken. Daar kun je dan vanuit Word naar verwijzen. Let op: Bij problemen, die je gaat oplossen door code te schrijven, is het altijd belangrijk om goed te kijken of je denkt dat je de code ook daadwerkelijk kunt schrijven! Soms moet je hier wat dingen voor uitproberen en dat mag natuurlijk de beste oplossing kiezen Als je alle voor- en nadelen in kaart hebt gebracht, dan rest je nog om de beste oplossing te kiezen. Hiervoor moet je alle voor- en nadelen tegen elkaar afwegen. Hoe doe je dat? Je kunt natuurlijk de oplossing met de meeste voordelen pakken. Maar is dat verstandig? Is misschien de oplossing met de minste nadelen het beste? Doorgaans is

19 voor- en nadelen tellen niet de beste methode. Niet alle voor- en nadelen wegen namelijk even zwaar. We zeggen vaak dat ze een ander gewicht kunnen hebben. Daar moet je uiteraard rekening mee houden bij het nemen van je beslissing. Je kunt dit op gevoel doen en uitleggen, maar je kunt het ook analytisch aanpakken. Een voorbeeld van een meer analytische aanpak is het werken met weegfactoren voor ieder voor- en nadeel. Hiermee geef je aan hoe belangrijk je het voor- of nadeel in de context vindt. Dat doe je bijvoorbeeld als volgt. 1. random 2. begin bij 1 3. slim Je hoeft er niet bij te rekenen. (1) Je hoeft er niet bij na te denken. (1) Is gemiddeld het snelst. (4) Voordelen Is gemiddeld sneller dan beginnen bij 1. (2) Je gebruikt de feedback. (2) Je gebruikt de feedback. (2) Nadelen Is gemiddeld langzamer dan de slimme strategie. (2) Je negeert de feedback. (2) Duurt gemiddeld het langst. (4) Je moet erbij rekenen. (1) Je ziet dat we voor- en nadelen die elkaars tegenovergestelde zijn even zwaar laten wegen! Als je voordelen als positief laat meetellen en nadelen als negatief, dan zou je op de volgende scores uitkomen. 1. random: +3 ( ) 2. begin bij 1: 5 (1 2 4) 3. slim: +5 ( ) Je zou nu kunnen zeggen dat je de 3 e oplossing moet kiezen

20 Bij een zuiver numerieke oefening, zoals we die net hebben gedaan, moet je wel altijd goed uitkijken. Ga altijd na of de gekozen oplossing ook gevoelsmatig klopt. Je kunt namelijk verkeerde weegfactoren gekozen hebben en daarmee de verkeerde uitkomst gekregen hebben. Mogelijk moet je nog een keer kritisch naar de weegfactoren kijken. Het is daarnaast altijd goed om de 2 beste oplossingen toch nog even naast elkaar te zetten en op gevoel af te wegen. In dit geval is het niet vreemd dat je gevoel zegt, dat oplossing 3 inderdaad de beste is je keuze uitleggen Bij het werken met weegfactoren is het heel erg belangrijk om uit te leggen waarom je juist die weegfactor toekent aan een voor- of nadeel. Stel dat we het volgende opschrijven als uitleg voor de keuzes van de weegfactoren uit het voorbeeld in de vorige paragraaf. In ons geval vinden we het wel of niet hoeven rekenen of denken minder belangrijk dan de snelheid of het gebruiken van de feedback. Snelheid vinden we het belangrijkst en heeft een schaal. Op het eerste gezicht lijkt dit geen verkeerde beschrijving. Maar als je goed leest, dan wordt er nergens uitgelegd waarom we de keuzes maken. We leggen alleen uit welke keuzes we maken en dat kunnen we feitelijk ook aflezen aan de weegfactoren zelf. Je kunt zien dat het waarom niet uitgelegd wordt door het ontbreken van het woord omdat, of vergelijkbare woorden, in de tekst. De volgende beschrijving is al beter. In ons geval vinden we het wel of niet hoeven rekenen of denken het minst belangrijk, omdat we dit een subjectief oordeel vinden. We zitten immers in de context van software en voor een computer speelt dit geen rol. De gemiddelde snelheid vinden we het belangrijkst, omdat dit een doelstelling is van het spel. Snelheid heeft een schaal, omdat we 3 oplossingen hebben die allemaal een verschillende gemiddelde snelheid hebben. Het niet uitleggen waarom je keuzes maakt is een veel gemaakte "fout". Mensen beschrijven nog een keer wat ze eerder al schematisch hebben laten zien. Nog een voorbeeldje aan de hand van een afbeelding en bijbehorende beschrijving

21 Figuur 2: De PDCA cyclus. 8 Om continue te kunnen verbeteren moeten we steeds een reeks stappen doorlopen. Daarbij moeten we eerst plannen, dan uitvoeren wat we gepland hebben. Het resultaat moeten we uiteraard controleren en aan de hand van wat er uit de controle komt, moeten we kijken wat we de volgende ronde moeten veranderen. Ook hier zie je weer dat er in de tekst precies staat wat het plaatje weergeeft en niets meer. Er wordt niet uitgelegd waarom je de reeks stappen vaker moet doorlopen of waarom de volgorde van de stappen zo is. 8 iso awareness.blogspot.nl/2014/04/pdca-cycle.html

22 7. documentatie wijzigingen Aan het einde van de 3 e Sprint van je project heb je je 1 e versie van de documentatie klaar. Deze moet je inleveren en wordt beoordeeld. Wanneer je vervolgens aan de slag gaat met de rest van je project blijft de documentatie natuurlijk niet ongewijzigd. Je kunt immers niet alles van tevoren weten. Het kan zijn dat je nog extra eisen tegenkomt en daar test cases voor moet maken. Het kan zijn dat wat je in je ontwerp bedacht hebt in de praktijk minder goed uitpakt en je naar een andere oplossing moet zoeken. Redenen genoeg om je documentatie aan te passen. In MS Word is het mogelijk om automatisch wijzigingen bij te houden. Het nadeel hiervan is dat dan elk karakter dat je verandert, dus ook spaties, nieuwe regels enzovoorts, gemarkeerd wordt. Daarom ga je geen gebruik maken van automatisch bijhouden van wijzingen in MS Word. In plaats daarvan hanteer je de volgende regels. tekst weghalen Als je een stuk tekst weg wilt halen, dan verwijder je die tekst niet uit het document, maar markeert hem via de Doorhalen functionaliteit. Doorhalen vind je in MS Word bij de Lettertype functies in de Start tab van het lint, net zoals de functionaliteit om tekst vet of cursief te maken. Het is gewenst om vervolgens aan te geven WAAROM je die tekst hebt weggehaald. Dit is dan weer een toevoeging en we leggen zo uit hoe je die markeert. Bijvoorbeeld: Lorem Ipsum is slechts een proeftekst uit het drukkerij- en zetterijwezen. Lorem Ipsum is de standaard proeftekst in deze bedrijfstak sinds de 16e eeuw, toen een onbekende drukker een zethaak met letters nam en ze door elkaar husselde om een font-catalogus te maken. Het heeft niet alleen vijf eeuwen overleefd maar is ook, vrijwel onveranderd, overgenomen in elektronische letterzetting. Dit stuk tekst is weggehaald, omdat

23 tekst toevoegen Als je een stuk tekst toevoegt, dan markeer je die tekst met de Tekstmarkeringskleur geel. Geel is de standaard markeringskleur als je een document opent. De Markeer functionaliteit vind je in MS Word bij de Lettertype functies in de Start tab van het lint, net zoals de functionaliteit om tekst vet of cursief te maken. Bijvoorbeeld: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. toegevoegde tekst verwijderen Als je tekst hebt toegevoegd en gemarkeerd, dan kan het zijn dat je erachter komt dat het toch niet goed was. Gooi ook dan de nieuwe tekst niet weg, maar pas hier ook weer de Doorhalen functionaliteit op toe en leg uit waarom je het weghaalt. Zo geef je duidelijk aan dat je leert en hoe. Bijvoorbeeld: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Dit stuk tekst is weggehaald, omdat... BELANGRIJK! Let op: Pas het verwijderen (doorhalen) toe op hele alinea's, dus niet op individuele woorden of zinnen. Kopieer desnoods de hele alinea en maak dan de wijzigingen. Maak alinea's dus ook niet te groot, maar pas toe wat je bij het vak Nederlands hebt geleerd. Een alinea's zou nooit langer dan 5 à 7 zinnen moeten zijn! Let op: Je hoeft geen wijzingen bij te houden in je Plan van Aanpak documentatie. Deze breid je steeds uit met nieuwe Sprints en de bijbehorende informatie. Die uitbreidingen hoef je niet te markeren, omdat het vanzelfsprekend is dat deze nieuw zijn. Verder heeft het geen nut om veranderingen te maken in de informatie over oude Sprints, want die Sprints zijn al klaar

24 8. triviaal en niet-triviaal in de praktijk In hoofdstuk 2 hebben we verteld wat we verstaan onder triviale en niet-triviale problemen. Een belangrijk onderdeel van informatica is, dat je leert niet-triviale problemen op te lossen. Nu kun je zeggen, ja maar de problemen die ik ga tegenkomen zijn waarschijnlijk allemaal al opgelost en dat is mogelijk waar. Maar zoals gezegd, hóéf je de oplossing van een moeilijk probleem natuurlijk niet op te zoeken! Dat is dus een mogelijkheid om iets een niet-triviaal te laten blijven. Het zelf leren oplossen van problemen is een heel belangrijke vaardigheid die je je hele leven blijft gebruiken. Deze train je dus niet door oplossingen op te zoeken en over te nemen. In de komende projecten ga je dan ook proberen zoveel mogelijk moeilijke problemen zelf op te lossen. Hoe meer niet-triviale problemen je zelf oplost, hoe beter dat is voor je cijfer. Wanneer je straks gaat werken, in bijvoorbeeld het bedrijfsleven, dan is het een ander verhaal. Daar geldt: "Tijd is geld!" Daarom ga je dan eerst zoeken of er al een oplossing bestaat en of je die over mag nemen. Dat laatste is namelijk niet altijd het geval als er bijvoorbeeld een patent op de oplossing zit. In de leidraaddocumenten die over het ontwerp gaan, vind je altijd een stuk over opgeloste problemen. Hierin wordt uitgelegd hoe je opgeloste problemen moet documenteren. Uiteraard gebruik je daarbij wat je in deze module hebt geleerd. Zelfs als je, met toestemming van je leraar, een oplossing voor een probleem mag overnemen, dan mag je niet de eerste oplossing gebruiken die je tegenkomt. Ook in dat geval moet je naar alternatieven gaan zoeken en een afweging maken welke oplossing het beste is en je afweging netjes documenteren. Ook dit sluit weer aan bij wat je je hele leven blijft doen en dat is kritisch kijken naar oplossingen en bepalen of ze geschikt zijn om je probleem op te lossen