H4 - Analysefase (Deel 2) Flashcards
Verschil tussen business events en een use-case uitleggen.
Use-cases zijn specifieke functies in een informatiesysteem, zij vertegenwoordigen het uiterlijke gedrag van het informatiesysteem.
Events zijn gebeurtenissen die objecten beïnvloeden en doen zich voor, ook al heeft het bedrijf geen informatiesysteem.
Verschil tussen een walkthrough en een inspectie uitleggen.
Inspectie:
- veel uitgebreider dan een walkthrough
- bestaat uit 5 strikt formele stappen
- wordt niet alleen uitgevoerd voor analysedocumenten, maar ook voor programmacode
Walkthrough:
- bestaat uit 2 fasen: voorbereiding en analyse van het document
- minder formeel dan een inspectie
Het verloop van een walkthrough beschrijven.
Een kleine groep mensen (team van 4 tot 6) overlopen een document en proberen fouten, onduidelijkheden en zwakke passages te ontdekken.
Tijdens de walkthrough worden geen fouten verbeterd, enkel achteraf. Verbeteren kost teveel tijd en een walkthrough moet kort gehouden worden (max. 2 u).
Een walkthrough kan op 2 manieren:
o Deelnemersgestuurde walkthrough
Alle deelnemers geven een lijst met hun opmerkingen over het document
De vertegenwoordiger van het team moet op elke opmerking ingaan en ofwel uitleggen wat onduidelijk is ofwel toelichten waarom de beoordelaar zich heeft vergist.
o Documentgestuurde walkthrough
Het document wordt doorgenomen met de deelnemers en die onderbreken met vragen die zij van te voren hebben voorbereid of die naar aanleiding van de presentatie bij hen opkomen.
Meestal grondiger en leidt tot ontdekken van meer fouten o De voornaamste rol van de leider van de walkthrough is het aansporen tot vragenstellen en het bevorderen van de discussie.
o Een walkthrough is een interactief proces!
Het verloop van een inspectie beschrijven
Bestaat uit 5 stappen:
1) Overzicht
Eerst wordt er een overzicht gegeven van het te inspecteren document door iemand die aan het opstellen ervan heeft meegewerkt.
Aan het einde wordt het document aan de deelnemers uitgedeeld
2) Voorbereiding
De deelnemers proberen zo goed mogelijk alle details te begrijpen.
Vaak wordt er gebruik gemaakt van een lijst met de soort fouten, dan weet men waar ze zich op moeten focussen.
3) Inspectie
Het document wordt overlopen en alle onderdelen komen aan de orde.
Daarna begint het zoeken naar de fouten. Het is de bedoeling om de fouten te zoeken, niet om te verbeteren.
De moderator maakt hierna binnen 1 dag een schriftelijk verslag van de resultaten.
4) Herziening
Aan de hand van het verslag van de inspectie wordt het document gecorrigeerd.
5) Follow-up
Alles dat werd aangetoond moet nu ook opgelost zijn. Ofwel door een correctie in het document, ofwel door duidelijk te maken waarom iets ten onrechte als fout werd aangemerkt.
Beschrijven wat prototyping is en waarom dit belangrijk/interessant kan zijn.
Programma dat geheel of gedeeltelijk bepaalde functionaliteiten van het uiteindelijke systeem implementeert, maar waarbij met bepaalde vereisten bewust geen rekening werd gehouden.
De bedoeling is om gebruikersvereisten of in sommige gevallen ook bepaalde ontwerpbeslissingen
te testen.
Enkele redenen waarom prototyping interessant kan zijn:
- Hiermee kunnen bepaalde zaken uit de analyse concreet uitgetest worden
- We kunnen de gebruiker een duidelijker beeld geven van hoe de software er zal uitzien en wat het precies zal kunnen en wat niet.
- Zo kan de gebruiker nog voor er veel code geschreven werd, zijn wensen en bezwaren op een heel specifieke manier duidelijk maken.
Enkele voordelen en gevaren van prototyping opsommen. Voordelen en gevaren in een concrete
situatie herkennen.
Voordelen:
- Misverstanden tussen ontwikkelaars en gebruikers worden ontdekt
- Ontbrekende functies worden ontdekt
- Er kan een werkend programma getoond worden om het nut en de haalbaarheid van het nieuwe systeem te demonstreren.
Gevaren:
o De verleiding is groot om het prototype om te vormen tot het definitieve product.
o Wanneer snel een product klaar is dat erg goed lijkt op het definitieve systeem, begrijpen gebruikers en managers vaak niet goed waarom nog zoveel ontwikkelingstijd nodig is om het definitieve systeem te ontwikkelen.
o De managementsvaardigheden die samenhangen met de planning en de kostenschatting van een prototypingproject ontbreken in heel wat organisaties
Het prototypingproces beschrijven
Een prototype ontwikkelen gebeurt in 4 fasen:
1) Doelstellingen van het prototype bepalen -> prototypeplan
Belangrijk dat de doelstellingen vanaf begin duidelijk zijn, elke prototype zal er anders uitzien en andere eisen stellen.
2) Functionaliteiten van het prototype vastleggen -> ontwerpdefinitie
Wat zit erin, wat wordt eruit gelaten?
3) Het prototype ontwikkelen -> uitvoerbaar prototype
4) Het prototype evalueren -> evaluatieverslag
Hoe zal het prototype geëvalueerd worden (hoeveel tijd wordt daarvoor uitgetrokken en wie wordt erbij betrokken)
Welke aspecten kunnen genegeerd worden?
Het verschil tussen throw-away prototyping en evolutionair prototyping uitleggen
Throw-away:
o De bedoeling van het prototype is bepaalde gebruikersvereisten preciezer in te schatten of bepaalde risico’s te bepalen. Na evaluatie wordt het prototype niet meer gebruikt.
Evolutionair:
o Hierbij zijn de specificaties in het begin heel vaag. Door het prototype worden de specificaties verder verfijnd. Het prototype wordt dan aangepast aan de nieuwe specificaties en weer geëvalueerd. Dit gaat zo verder tot de definitieve applicatie is ontwikkeld.
Het begrip maquetteering of user-interface prototyping uitleggen.
Er worden schermen en rapporten gebouwd zonder veel achterliggende code om het concept van de user-interface te toetsen en op die manier de user-interface verder te ontwikkelen.
Er wordt vaak een evolutionaire aanpak gehanteerd. D.w.z. dat men het prototype voortdurend wijzigt tot de gebruikers en de ontwikkelaars overeenstemming hebben bereikt
