Inleiding

Voordat je kan beginnen met programmeren moet je als programmeur eerst gaan bedenken wat je gaat maken. Analyse- en designactiviteiten zijn nodig om de problemen van de klant(organisatie) te begrijpen, om functionele oplossingen te vinden (analyse), deze te ontwerpen en uiteindelijk te implementeren (design).

Vorig jaar hebben we dit gedaan aan de hand van het visie/scope document. Dit jaar gaan we hier verder aan bouwen. Voordat we dieper gaan duiken in een aantal aspecten van de analyse zullen we eerst herhalen waar vorig jaar het visie/scope document uit bestond. Van daaruit wordt er verder verdiept in de stof.

Het visie/scope document: Wat was dat ook alweer?

Het visie/scope document geeft de analyse weer van het project. Aan de hand van dit document kan het project opgezet worden en de applicatie vormgegeven worden.

Wat wil je bereiken met dit document?

• De context van een organisatie begrijpen (Organisatorische context)
• In kaart brengen van de betrokkenen (Actoren, Stakeholders)
• Validatie, hebben we de situatie goed begrepen?

Let op dat dit document verandert naarmate de tijd vordert in het project! Door voortschrijdend inzicht kan de insteek of de oplossing veranderen.

Wat staat er in een Visie/Scope beschrijving?

• Inleiding
  • Waar gaat dit document over?
  • Wie is de doelgroep van het document?
  • Welke informatie staat er in dit document?
• Organisatorische context (Missie, Visie, Organogram)
  • Wat is het voor soort organisatie?
  • Wat zijn de eigenschappen van het organisatie?
  • Hoe is de organisatie opgebouwd?
• Aanleiding project
  • Wat is er gebeurd of veranderd wat geleid heeft tot de noodzaak van het project?
• Stakeholders
  • Wie hebben er belang bij dat het project uitgevoerd wordt?
• Actoren
  • Wie zijn de actoren in het system, welke rollen hebben ze en wat mogen ze wel (en niet)?
• Procesbeschrijving
• Knelpunten/kansen
  • Een knelpunt is dat deel in het proces waar iets mis loopt of suboptimaal geregeld is.
  • Een kans is een mogelijkheid tot verbetering of uitbreiding van het proces die (nog) niet herkent wordt of niet tot de mogelijkheden (lijkt) te behoren.
• Aanpak
  • In de aanpak vertaal je de knelpunten en kansen naar een EPIC story. Dit is een grote user story die je later verder kan uitsplitsen naar kleinere user stories. Bij deze story geeef je ook een visie (vaak in de vorm van een wireframe) hoe je denkt dat het probleem opgelost kan worden. Dit doe je niet voor alle knelpunten en kansen, maar alleen voor de eerstvolgende knelpunt of kans waar je in de sprint aan gaat werken. Let er dus op dat de EPIC die je gaat uitwerken geen (open) afhankelijkheden meer heeft.

In dit semester gaan we dieper duiken in de volgende onderdelen:

• Bedrijfsprocessen weergeven
• De vertaling van proces in gedrag
• Het schrijven van (goede) requirements
• Use cases / User stories

Modellen in de analyse

Voor het maken van de analyse maak je vaak gebruik van modellen. Een model is een schematische weergave van de werkelijkheid die meestal een of meerdere aspecten van de werkelijkheid uitlicht en benadrukt. ICT’ers gebruiken modellen om de werking van informatiesystemen, applicaties, netwerken en apparaten te beschrijven. Er zijn veel verschillende soorten modellen maar voor ICT’ers zijn met name twee soorten belangrijk: structuur- en gedragsmodellen. Structuurmodellen zijn statisch. Ze beschrijven de samenhang tussen onderdelen en geven inzicht in de structuur van een systeem. Gedragsmodellen zijn dynamisch. Ze beschrijven gedrag en geven inzicht in hoe iets werkt.

Veel ICT-modellen worden weergegeven met een diagram. Ieder diagram heeft een eigen syntax (welke symbolen worden gebruikt) en een eigen semantiek (wat de symbolen betekenen). Om goed te modelleren is het belangrijk om de syntax en semantiek van een model goed te kennen en te kunnen toepassen.

Aan de hand van deze modellen en diagrammen kunnen ook weer requirements voortvloeien die uiteindelijk vertaald kunnen worden naar user stories.