Encyclopedie
Begrippenlijst

Stappen in het ontwerpproces

Uit Triple A Encyclopedie
Ga naar: navigatie, zoeken
MethodiekStappen.png

Voor elk functioneel ontwerp is de onderwijsvisie het uitgangspunt. Vanuit de onderwijsvisie is er een afbakening op hoofdlijnen gemaakt, die heeft geleid tot de opdeling van de totale functionaliteit in een aantal kernsystemen. In elk kernsysteem is een aantal onderwijsprocessen samengebracht met veel onderlinge samenhang, zoals bijvoorbeeld de onderwijslogistiekHet continue proces dat er voor zorgt dat de leervraag van de deelnemers en het aanbod aan onderwijsproducten van de instelling zo goed mogelijk bij elkaar worden gebracht. Uiteindelijk zorgt de onderwijslogistiek ervoor dat onderwijsproducten daadwerkelijk kunnen worden afgenomen. Het onderwijslogistieke proces bestaat uit het samenstellen van een passend arrangement voor de deelnemers (het arrangeren) het plannen van de inzet van onderwijsproducten in tijd en plaats en het vastleggen van de deelnemers om specifieke onderwijsproducten op de gereserveerde tijden en plaatsen af te nemen (het roosteren) of de ondersteuning van het primaire proces.

De uitwerking van het functioneel ontwerp van een kernsysteem wordt gedaan in een drietal stappen, zoals in nevenstaand schema is weergegeven. Onder elke stap is het product weergegeven dat uit die stap voortkomt.

Samengevat komt het erop neer dat in de eerste stap (A), het benoemen van de processen, wordt vastgesteld welke onderwijsprocessen op hoofdlijnen tot het betreffende kernsysteem behoren. Deze processen komen dan terug in het onderwijsprocesmodel. Vervolgens wordt in de tweede stap (B) elk proces opgeknipt in functionele eenheden: de use cases. Elk van deze use cases wordt vervolgens nader uitgewerkt in een activiteitendiagram, waarin de activiteiten zijn gemodelleerd waaruit de use case bestaat. Tenslotte wordt er in de derde stap (C) een inventarisatie gemaakt van de benodigde functies van het beoogde ICT-systeem, die de betreffende activiteiten in de use case zouden ondersteunen.

Processen benoemen

In de onderwijsvisie zijn de onderwijsprocessen vanuit het perspectief van de deelnemerIemand die onderwijs volgt binnen een instelling. Een deelnemer is in bezit van een verbintenis met een instelling voor het afnemen van onderwijsproducten. Een ander woord voor deelnemer is lerende leerling of student. beschreven. Het onderwijsprocesmodel geeft deze processen in samenhang weer, en clustert deze in kernsystemen. De functionele ontwerpen worden vervolgens per (combinatie van) onderwijsprocessen opgepakt.

Het vertrekpunt voor het functioneel ontwerp zijn dus de onderwijsprocessen van het onderwijsprocesmodel, waarop het functioneel ontwerp betrekking heeft. De eerste stap in het functioneel ontwerpproces is deze processen goed te definiëren en af te bakenen. Dit leidt in veel gevallen tot een aanpassing of nadere definitie van de processen in het onderwijsprocesmodel.

Use cases beschrijven

Nadat de processen zijn benoemd en afgebakend, wordt gekeken naar de functionele eenheden waaruit de ondersteuning van die processen bestaat: de use cases. Een use case beschrijft het van buitenaf zichtbare gedrag van het systeem, vanuit het perspectief van de gebruiker. Een use case heeft een concrete aanleiding en een concreet resultaat, en beschrijft de processtappen van gebruikers van het systeem die moeten leiden tot dit concrete resultaat. De use cases zijn daarmee de eenheden van functionaliteit vanuit de gebruiker gezien. Het totaal aan use cases geeft antwoord op de vraag ‘wat moet het systeem ondersteunen?’

Het voordeel van dergelijke beschrijvingen is dat eerst nagedacht wordt over de werkprocesseneen werkproces is een afgebakend geheel van beroepshandelingen binnen een kerntaak. Het werkproces kent een begin en een eind heeft een resultaat en wordt als kenmerkend herkend in de beroepspraktijk. Een werkproces bestaat dus nooit uit één handeling of gedraging. Meerdere werkprocessen kunnen gelijktijdig lopen. Dat ze een begin en eind hebben wil niet per se zeggen dat ze na elkaar komen maar dat ze duidelijk te onderscheiden zijn van andere werkprocessen. en dat niet direct de stap wordt gezet naar een invulling met systeemfunctionaliteit. Dat maakt het schrijven van use cases ook zo moeilijk. De schrijver van een use case moet afstand nemen van een mogelijke systeemoplossing en zich concentreren op de processen die ondersteund moeten worden.

Use cases laten zich goed lezen door niet-technische mensen, het is immers beschreven in termen van de werkprocesseneen werkproces is een afgebakend geheel van beroepshandelingen binnen een kerntaak. Het werkproces kent een begin en een eind heeft een resultaat en wordt als kenmerkend herkend in de beroepspraktijk. Een werkproces bestaat dus nooit uit één handeling of gedraging. Meerdere werkprocessen kunnen gelijktijdig lopen. Dat ze een begin en eind hebben wil niet per se zeggen dat ze na elkaar komen maar dat ze duidelijk te onderscheiden zijn van andere werkprocessen. van de organisatie. De beschrijvingen zijn met betrekking tot formuleringen en taalgebruik zo toegankelijk mogelijk.

Voor de beschrijving van een use case wordt een standaard format gebruikt dat is afgeleid van de binnen UML gangbare manier van beschrijven. Dit format wordt hieronder weergegeven.

3 - UMLformat.png


Een use case staat niet op zichzelf. Er liggen vaak verbanden tussen de verschillende use cases, omdat het resultaat van de ene use case vaak de aanleiding is voor een andere. Ook kan in de beschrijving van een use case een situatie worden beschreven die de aanleiding is voor het starten van een andere use case. Deze verbanden noemen we werkopdrachten. Zo’n werkopdrachtEen relatie tussen twee use cases waarbij het resultaat van de ene use case het startpunt is voor een andere use case. De relatie behelst niet het overdragen van gegevens. behelst niet het overdragen van gegevens, maar meer het initiëren van een andere use case. In de use case overzichten brengen we de samenhang tussen de use cases in beeld door deze werkopdrachten tussen de use cases te tekenen.

Uitwerken naar activiteitendiagrammen

De use cases worden vervolgens nog een stap dieper uitgewerkt in een zogenaamd activiteitendiagram. In een activiteitendiagram wordt de beschrijving van de acties gemodelleerd zodat de logica van het proces preciezer is gedefinieerd, en duidelijk is onder verantwoordelijkheid van welke actorGebruiker van het systeem in een specifieke rol of een ander systeem of technische voorziening die met het systeem communiceert. De actoren maken dus geen deel uit van het systeem maar interacteren met het systeem. Actoren zijn diegenen die gegevens met het systeem uitwisselen of diensten van het systeem betrekken. een activiteit wordt uitgevoerd. Er wordt per use case één activiteitendiagram gemaakt.

Hieronder wordt een voorbeeld van zo’n activiteitendiagram gegeven. De schematechniek is gebaseerd op UML.

3 - ActiviteitenDiagramVoorbeeld.png

Functies benoemen

Uit de beschrijving van de use cases en de activiteitendiagrammen kan een inventarisatie van functies worden opgemaakt. Dit zijn de functies die het systeem moet bieden om het beschreven proces te kunnen ondersteunen. Onder functies worden hier concrete onderdelen van een ICT-systeem verstaan, zoals schermen of rekenfuncties.

Om tot deze functies te komen wordt uitgegaan van de activiteiten in de activiteitendiagrammen. Voor elke activiteit (of enkele opeenvolgende activiteiten) wordt vastgesteld welk ICT-functies nodig zijn om de betreffende activiteit uit te voeren. Zo onstaat een verzameling functies die nodig is om de use case te ondersteunen. Sommige functies zullen voor meerdere activiteiten, in verschillende use cases toepasbaar zijn.