# data[].attributes.body
Theorie en opdracht

# data[].attributes.body
Aan de slag met risicomanagement

# data[].attributes.attachment_link.readable_text
Risicobeheer of risicomanagement is een continu proces dat ten aanzien van de doelstelling risico's identificeert, beoordeelt en vervolgstappen definieert. Er zijn verschillende gebieden waarop risicomanagement toegepast kan worden; financieel risicomanagement richt zich op het beheersen van financiële risico's, projectrisicomanagement richt zich op het beheersen van risico's in het realiseren van grote projecten.

Belangrijk is in hoeverre er sprake is van een meetbaar risico of een onmeetbare onzekerheid, meer specifiek Knightiaanse onzekerheid.

Risicomanagement in zes stappen

Het proces van risicomanagement bestaat in veel modellen uit zes stappen: doelstelling vaststellen, risico's identificeren, gevolgen inschatten, risico's beoordelen, risico's beheersen en monitoring.

De doelstelling is datgene wat een organisatie wil bereiken, bijvoorbeeld het realiseren van omzetgroei, continuïteit, of het afronden van een project binnen een bepaalde begroting of termijn. Het vaststellen van de doelstelling kan geschieden door gebruik te maken van de regels van het SMART-principe. Sinds de Kredietcrisis is de aandacht voor risk appetite, de mate waarin organisaties risico's willen nemen om hun doelstellingen te bereiken, toegenomen. Om risicobeheer te integreren in de bedrijfsvoering zullen organisaties hun risk appetite in samenhang met hun doelstellingen moeten bepalen, communiceren en monitoren.

Risico's identificeren

Een risico is een onzekere gebeurtenis met mogelijke gevolgen voor de doelstelling. De gebeurtenis doet zich voor door interne en/of externe oorzaken. De interne oorzaken hebben invloed op de activiteiten, welke samen met de externe oorzaken het doel (de doelstelling) beïnvloeden. De beïnvloeding heeft vervolgens weer gevolgen, welke mogelijk nieuwe risico's vormen. Een risico kan in de termen van het risicomanagement zowel positief als negatief zijn. Een negatief risico wordt ook een gevaar, bedreiging, downside risk of statisch risico genoemd. Een positief risico wordt ook een kans of upside risk genoemd. Een dynamisch risico is een risico dat zowel positief als negatief kan zijn of worden.

Voor risico-identificatie (ook risicoanalyse of event ivent identification) kan onder meer geschieden middels de volgende modellen: SWOT, RISMAN, DESTEP/PESTEL, Vijfkrachtenmodel, PIOFACH en een combinatie van het vijfkrachtenmodel en het DESTEP-model.

Vervolgens worden risico's ingeschat op kans van optreden en op mogelijke gevolgen. Dit kan gekwantificeerd worden, maar ook kwalitatieve inschattingen van risico's kunnen nuttig zijn. De beoordeling en klassificatie van risico's gaat volgens de Kinney-methode of de verwachte waarde methode.

Verwachte waarde = kans x gevolg

Kinney-methode = kans x gevolg x blootstelling

De kans van voorkomen wordt vastgesteld als een percentage. Als een gebeurtenis eens in de 100 jaar zal voorkomen, dan mag de kans als 1% genoteerd worden.

Er wordt een risicoacceptatiegraad vastgesteld, dit is het risico dat bijvoorbeeld een bedrijf hooguit wil nemen om de doelstelling te behalen. Uit de risicoacceptatiegraad is af te leiden of het risico wordt opgezocht (risicozoekend) of ontweken (risicoavers). Twee factoren die meespelen bij het bepalen van de risico acceptatiegraad zijn de gevolgen en de waarschijnlijkheid. De beoordeling van risico's kan visueel worden weergegeven in een risicomatrix of riskmap en/of een Likelihood-diagram.

Twee elementen die centraal staan in het beheersen van risico's zijn de maatregelen en de reacties. Een risico zonder beheersmaatregelen wordt een bruto of inherent risico genoemd. Een risico waarop beheersmaatregelen worden genomen worden vervolgens kleiner ingeschat, en kunnen restrisico's (residual risk) genoemd worden. Beheersmaatregelen zijn preventief, waarbij beoogd wordt de kans van voorkomen af te nemen, of repressief, waarbij beoogd wordt de gevolgen te reduceren. Er zijn twee soorten beheersmaatregelen, te weten: hard controls (afspraken en richtlijnen) en soft controls (gericht op het functioneren van medewerkers).

Er zijn vier soorten reacties: vermijden (of voorkomen, terminate), beheersen (of verminderen, treat), overdragen (of uitbesteden, transfer) en accepteren (take). Risico's kunnen worden vermeden door drastische maatregelen, bijvoorbeeld bij brandgevaar al het houten meubilair te vervangen door staal. Het beheersen kan bijvoorbeeld door het meubilair brandwerend te maken en overdragen door een brandverzekering af te sluiten.

Monitoring gebeurt in de loop van het proces, en kunnen middels indicatoren gemonitord worden (Key Risk Indicator en Key Control Indicator) samen ook wel de Early Warning Indicators genoemd.

Binnen het vakgebied van risicobeheersing wordt onderscheid gemaakt tussen de volgende typen:

Operationele risico's. Dit zijn gevolgen die kunnen optreden bij het uitvoeren van het werk waar de organisatie voor in het leven is geroepen. Een voorbeeld is een koersfluctuatie waardoor de inkomsten van een multinational anders uitpakken na omwisseling van de valuta.

Financiële risico's. Dit is het risico dat de financiële verslaglegging van de organisatie afwijkt van de werkelijkheid. Een voorbeeld is de waarde van de inventaris die afwijkt van wat daadwerkelijk in de inventaris zit door verkeerde tellingen of door onvoorzien verlies vanwege schade of diefstal.

Karel de Bakker heeft onderzoek gedaan naar de effectiviteit van risicomanagement. Het resultaat was dat vooral de initiële risicosessie bijdroeg aan risicobewustzijn en aan het beheersen van risico's. Lijstjes bijhouden en rapporteren doen dat niet.

Externe link

# data[].attributes.attachment_link.description
Risicobeheer of risicomanagement is een continu proces dat ten aanzien van de doelstelling risico's identificeert, beoordeelt en vervolgstappen definieert. Er zijn verschillende gebieden waarop risicomanagement toegepast kan worden; financieel risicomanagement richt zich op het beheersen van financiële risico's, projectrisicomanagement richt zich op het beheersen van risico's in het realiseren van grote projecten.

# data[].attributes.attachment_link.readable_text
Een risicoanalyse is een methode waarbij nader benoemde risico's worden gekwantificeerd door het bepalen van de kans dat een dreiging zich voordoet en de gevolgen daarvan: Risico = Kans x Gevolg. De risicoanalyse is de eerste stap binnen het risicomanagementproces.

Bij een risicoanalyse worden bedreigingen benoemd en in kaart gebracht. Per bedreiging wordt de kans van het optreden ervan bepaald en wordt vervolgens berekend wat als gevolg de schade is die op zou kunnen treden als een bedreiging zich daadwerkelijk voor doet.

Op grond van een risicoanalyse kunnen de volgende maatregelen worden genomen:

preventie: het voorkomen dat iets gebeurt of het verminderen/ verkleinen van de kans dat het gebeurt;

detectie: het detecteren van de (potentiële) schade wanneer een bedreiging optreedt;

repressie: het beperken van de schade wanneer een bedreiging optreedt;

correctie: het instellen van maatregelen die worden geactiveerd zodra iets is gebeurd om het effect hiervan (deels) terug te draaien

acceptatie: geen (additionele) maatregelen, men accepteert de kans en het mogelijke gevolg van een bedreiging;

overdragen: financieel d.m.v. verzekeren of operationeel d.m.v. outsourcen;

De bedoeling van een risicoanalyse is dat er na de analyse wordt vastgesteld op welke wijze de risico's beheerst kunnen worden, of teruggebracht tot een aanvaardbaar niveau. Daarbij wordt naast een risicoanalyse ook een kosten en baten analyse uitgevoerd. Op voorhand hoeft niet ieder risico te worden afgedekt: wanneer de kosten van de maatregelen om een risico te beperken hoger zijn dan de mogelijke schade, dan kan besloten worden het risico te accepteren. Het is ook van belang dat de afdekking of acceptatie van risico's in overeenstemming is met de risk appetite van de organisatie. Het permanent uitvoeren van risicoanalyses wordt risicomanagement (ook wel Risk Management of Risk Control) genoemd.

Risicoanalyses kunnen op twee manieren worden uitgevoerd:

Kwalitatieve methode: er worden schattingen van de gelopen risico's gemaakt.

Kwantitatieve methode: de risico's worden waar mogelijk gekwantificeerd in meetbare criteria, meestal uitgedrukt in de financiële gevolgen.

Afhankelijkheden en Kwetsbaarheden (A&K) analyse

Data Risico Management

EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité)

Information Risk Analysis Methodology (IRAM)

SPRINT dataclassificatie

Human reliability analysis

FMEA, Failure mode and effects analysis

HAZOP, Hazard and operability studie ofwel Storingsanalyse

SWOT, Strengths, Weaknesses, Opportunities, Threats of de sterkte-zwakteanalyse, analyse en strategiebepaling op basis van sterktes, zwaktes, kansen en bedreigingen als interne en externe factoren.

Norm EN 954-1 beschrijft een kwalitatieve methode voor het rangschikken van risico's van beveiligingscircuits. Deze norm is echter per december 2011 vervangen door de NEN EN ISO 13849-1. Deze is op zijn beurt op 21-01-2016 ingetrokken en vervangen door de NEN EN IEC 62061-1.

Norm EN 1050 beschrijft uitgangspunten voor een deugdelijke risicoanalyse. Ook deze norm is vervangen en wel door de EN 12100 :2010 (en 14121:2005 en 14121:2007)

Norm NEN-ISO/IEC 27005(en) beschrijft Information Security Risk Management

Een specifieke vorm van een risicoanalyse brengt de risico's in beeld van het gebruik, het transport of de opslag van gevaarlijke stoffen op de omgeving, ook wel aangeduid met de term externe veiligheid. Bij deze risicoanalyses spreekt men doorgaans van een QRA (Quantitative Risk Analysis of Quantitative Risk Assessment). In een QRA zet men de eigenschappen van de risicovolle activiteit (bijvoorbeeld een bedrijf) af tegen de eigenschappen van de omgeving, waarbij met name de aanwezigheid van personen in beeld wordt gebracht. Het risico in een QRA wordt uitgedrukt in de termen plaatsgebonden risico en groepsrisico..

# data[].attributes.attachment_link.description
Een risicoanalyse is een methode waarbij nader benoemde risico's worden gekwantificeerd door het bepalen van de kans dat een dreiging zich voordoet en de gevolgen daarvan: Risico = Kans x Gevolg. De risicoanalyse is de eerste stap binnen het risicomanagementproces. Bij een risicoanalyse worden bedreigingen benoemd en in kaart gebracht.

# data[].attributes.body
Theorie en opdracht

# data[].attributes.body
Aan de slag met testen en documenteren

# data[].attributes.body
Hoe pak je dat aan?

# data[].attributes.attachment_link.readable_text
Aan het begin van een testtraject stel je een testplan op. Dit is vergelijkbaar met een Plan van Aanpak die een projectleider opstelt.

Het doel van het Testplan is om de aanpak van het testen binnen het programma, project, release of change te beschrijven. En alles wat nodig is om die aanpak uit te kunnen voeren op het juiste moment en met welke mensen en middelen.

Het testplan wordt opgesteld door de verantwoordelijke voor het testtraject. Dit kan zijn de testmanager, de testcoördinator, de functioneel beheerder of ieder ander die de opdracht krijgt en aanvaard.
Onderdelen Testplan

De onderdelen die behandeld kunnen worden zijn:

Aanleiding (Waarom)

Aanpak (Hoe)

Benodigde mensen en middelen (Wie en wat)

Benodigde tijd (planning) (Wat)

Op te leveren producten (Wat)

De grootte van een testplan hangt af van de omvang en de complexiteit van het testtraject. Wanneer het traject groot is kan besloten worden tot een onderverdeling in een Mastertestplan en Detailtestplan(nen).

Binnen een organisatie wordt vaak gebruik gemaakt van een template testplan. Welke onderdelen van de template worden gebruikt is naar eigen inzicht en behoefte in te bepalen. Het is wel aan te raden, te beredeneren waarom bepaalde onderdelen zijn vervallen. Dit dient dan wel afgestemd te worden met andere belanghebbenden binnen het traject.

Wanneer het testplan klaar is, is het aan te raden om het plan te laten beoordelen en te laten goedkeuren door de opdrachtgever. Wie beoordeelt en goedkeurt hangt af van de inrichting van de opdracht. Voor de beoordeling kun je denken aan alle stakeholders genoemd in het testplan, bijvoorbeeld opdrachtgever, product owner, projectmanager/leider, functioneel beheerder, etc.

Het gebruik

Wanneer het Testplan is goedgekeurd begint de uitvoering ervan. Je gaat doen wat er in het plan staat. Op basis van het plan weet je gedurende de uitvoering van het testtraject of deze goed verloopt. Wanneer er omstandigheden veranderen waardoor een deel of delen van het Testplan niet uitvoerbaar zijn, kan het Testplan worden aangepast. De aanpassingen dienen kenbaar gemaakt te worden aan de betrokkenen en eventueel vindt er een nieuwe goedkeuring plaats.

Onderwerpen testplan

Bij het opstellen van een testplan spelen de volgende onderwerpen een rol:

Teststrategie

Randvoorwaarden en uitgangspunten

Entry en exit criteria

Testsoorten en testvormen

Testontwerptechnieken

# data[].attributes.attachment_link.title
Testplan opstellen - plan van aanpak maken voor software testen

# data[].attributes.attachment_link.description
Aan het begin van een testtraject stel je een testplan op. Dit is vergelijkbaar met een Plan van Aanpak die een projectleider opstelt. Het doel van het Testplan is om de aanpak van het testen binnen het programma, project, release of change te beschrijven.

# data[].attributes.body
Waar moet je rekening mee houden bij het opstellen van een testscript?

# data[].attributes.attachment_link.readable_text
Ondanks dat er in deze tijd, voor het opstellen van testgevallen en de testuitvoering, vaak gebruik gemaakt wordt van tools, is er nog steeds behoefte aan een template voor testscripts. Niet iedere organisatie is namelijk al met geautomatiseerd testen bezig en niet voor ieder testtraject is geautomatiseerd testen een effectieve oplossing. Denk hierbij bijvoorbeeld aan de gebruikersacceptatietest.

In dit artikel gaan we in op de informatie die in een testscript kan worden opgenomen en kan er een template in Excel formaat worden gedownload.

Een goed testscript template zorgt voor een consistente werkwijze en maakt het voor de stakeholders makkelijker om de testgevallen te begrijpen. Het zorgt ook voor minder fouten tijdens de testuitvoering en maakt reproduceerbaarheid makkelijker.

Een testscript wordt vaak gemaakt in Microsoft Excel, Microsoft Word of met speciale testmanagement tools.

Bij het opstellen van een testscript dient vooraf de keuze te worden gemaakt over hoe gedetailleerd de uit te voeren handelingen beschreven moeten worden. Deze afweging is van belang in verband met de benodigde tijd om het testscript op te stellen, te onderhouden en het gemak waarmee later de test uitgevoerd moet kunnen worden.

Gedetailleerdheid testscript

De gedetailleerdheid is afhankelijk van:

Kennis van het te testen systeem

Wanneer je van de tester mag verwachten dat hij/zij over voldoende kennis van de werking van de te testen applicatie beschikt, hoeven de uit te voeren handelingen niet in detail beschreven te worden. Dan is: "voer een nieuwe Belgische klant op met klantnummer: 123456789" voldoende. De tester weet hoe er ingelogd moet worden, dat er een aparte functie is voor het opvoeren van een buitenlandse klant en welke gegevens er ingevoerd kunnen en moeten worden.

Wie moet de testen kunnen uitvoeren

Wanneer de testen door een willekeurig iemand uitgevoerd moeten kunnen worden, bijvoorbeeld een onervaren gebruiker of een uitzendkracht, dan zullen de uit te voeren handelingen tot in detail beschreven moeten worden. Hoe moet er ingelogd worden, hoe kom je bij de functie die uitgevoerd moet worden, welke gegevens moeten ingevoerd worden in welk veld, hoe navigeer je door de applicatie of functie. De handelingen moeten dan directief beschreven worden: Ga naar home, kies boven in de balk voor inloggen, voer inlognaam xyz in, voer wachtwoord abc in en klik op de button inloggen.

Het hiervoor gestelde geldt ook voor de uit te voeren controles.

Inhoud testscript

Onafhankelijk van de gebruikte testontwerptechniek kan een testscript de volgende informatie bevatten:

# data[].attributes.attachment_link.title
Testscript opzet en template in Excel formaat - TestTalk

# data[].attributes.attachment_link.description
Ondanks dat er in deze tijd, voor het opstellen van testgevallen en de testuitvoering, vaak gebruik gemaakt wordt van tools, is er nog steeds behoefte aan een template voor testscripts. Niet iedere organisatie is namelijk al met geautomatiseerd testen bezig en niet voor ieder testtraject is geautomatiseerd testen een effectieve oplossing.

# data[].attributes.body
Achtergrond info

# data[].attributes.attachment_link.description
Een testplan wordt normaal gesproken gemaakt door de testmanager, die het plan daarna ook gaat uitvoeren. Doel van het testen is om informatie te verschaffen over het te testen object. Het doel van het testplan is om aan te geven hoe deze informatie verkregen wordt en welke delen van het testobject daarbij meer of minder aandacht krijgen.

# data[].attributes.body
Theorie en opdracht

# data[].attributes.body
Deze opdracht vervangt de opdracht in de presentatie

# data[].attributes.body
System Development Methodology

# data[].attributes.attachment_link.readable_text
System Development Methodology ( SDM), ofwel Systeem Ontwikkelings Methodologie (Methodiek) is een faseringsmethode. Het wordt voornamelijk gebruikt bij projecten voor ontwikkeling van (geautomatiseerde) informatiesystemen. Deze methode is de laatste jaren aan verandering onderhevig omdat de ontwikkeling van de automatisering niet stilstaat.

In 1970 heeft een bedrijf genaamd PANDATA in opdracht van drie grote Nederlandse bedrijven ( AKZO, Nationale Nederlanden en de toenmalige PTT) SDM ontwikkeld. In 1987 werd SDM verbeterd en is nu bekend als SDM2. SDM2 is onder andere aangepast ten aanzien van vorige versies vanwege 'het steeds groter wordende belang van de ontwikkeling van informatiesystemen voor de totale bedrijfsplanning, (...), het toegenomen bewustzijn ten aanzien van de invloed van informatiesystemen op de organisatie'.

SDM is een methodiek voor het plannen, ontwerpen, bouwen, invoeren en beheren van informatiesystemen. Deze fasering is 'top down', vanuit een groter geheel wordt het te ontwerpen informatiesysteem steeds gedetailleerder beschreven. Door middel van het toevoegen van systeemontwikkelingtechnieken kan men het ontwerp hiervan beschrijven in modellen, die vervolgens gebruikt worden om het ontwerp te realiseren. Tevens is SDM een watervalmethode. Een nieuwe fase begint pas als de oude klaar is.

SDM is een methodologie die gebaseerd is op fasering. Voor elke fase wordt nauwkeurig vastgelegd wat er is afgesproken met de betrokken partijen en wat er gedaan moet worden in de desbetreffende fase. SDM maakt gebruik van een procesgeoriënteerde aanpak, dit betekent dat deze methode zich voornamelijk bezighoudt met de planning en organisatie van het te maken systeem. Het beheersen van projecten voor systeemontwikkeling is de voornaamste taak van de ontwikkelmethode SDM. De documenten, waarin deze zaken worden vastgelegd, heten mijlpaalproducten.

Het gebruik van mijlpaalproducten is belangrijk om de volgende redenen:

De voortgang kan goed gevolgd worden. Door deadlines aan de mijlpaalproducten te koppelen, kan gecontroleerd worden of de uitvoering van het project op schema ligt.

Wanneer een mijlpaalproduct is goedgekeurd door de opdrachtgever, krijgt deze een bepaalde status. De status kan dan niet zomaar terug gedraaid worden. Dit voorkomt dat de opdrachtgever bijvoorbeeld later nog de systeemeisen kan uitbreiden.

Een mijlpaalproduct kan de opdrachtgever ertoe leiden om het project af te breken. Dit komt veelal voor bij het begin van het project.

De methode maakt gebruik van zeven verschillende fasen, die achtereenvolgend worden uitgevoerd. Aan het einde van elke fase wordt een eindrapport opgesteld. Hierin worden alle conclusies en verantwoordingen vastgelegd met betrekking tot die fase.

Aan de hand van dit eindrapport kan besloten worden of men doorgaat met het project of dat men het project stopt. Dit wordt aangeduid met de kreten "Go" en "NO-GO". Indien er een "NO-GO" plaatsvindt, kan het ook betekenen dat er verbeteringen gedaan moet worden in de fase. Er mag pas begonnen worden met de volgende fase, wanneer er een "Go" plaatsvindt ( watervalmethode).

De zeven fasen die sequentieel behandeld worden zijn:

In deze fase wordt het informatieplan geschreven, waarin o.a. het totale systeem wordt beschreven. Dit houdt in dat het geautomatiseerde deel en het handmatige deel hierin voorkomt. Dit plan verschaft duidelijkheid over welke informatiebehoefte er aanwezig is en hoe deze behoefte door het informatiesysteem wordt voorzien.

De mijlpaalproducten voor deze fase zijn:

Bij het uitvoeren van deze fase wordt er onderzoek verricht of het realiseren van het project haalbaar is. Om de haalbaarheid van een project te meten, kan men de volgende vragen als leidraad hanteren:

Is het ontwikkelen mogelijk en zinvol?

De kennis en manuren moeten in voldoende mate beschikbaar zijn en is het huidige systeem toe aan vervanging?

Is ontwikkelen technisch haalbaar?

De apparatuur moet beschikbaar zijn voor het systeem. Wanneer men eisen gaat stellen, waaraan de processor niet kan voldoen, kan met behulp van het systeem ook niet aan de eis worden voldaan.

Is ontwikkelen economisch verantwoord?

Indien de kosten, die gemaakt worden met het ontwikkelen en beheren van het systeem, groter zijn dan de winst die ermee wordt behaald, dan is het financieel gezien niet verstandig om te ontwikkelen.

Is het nieuwe systeem organisatorisch inpasbaar?

De mensen, die binnen de organisatie werken, moeten met het toekomstige systeem kunnen werken.

Is het ontwikkelen van het nieuwe systeem politiek haalbaar?

Het nieuwe systeem mag niet in strijd zijn met de wetgeving.

De mijlpaalproducten voor deze fase zijn:

Het ontwerp van het systeem zal in deze fase plaatsvinden. Aan de hand hiervan wordt er beschreven wat het systeem zal doen. Ook wordt precies aangegeven uit welke subsystemen het toekomstige systeem zal bestaan. Hierdoor zullen de subsystemen apart kunnen worden ontwikkeld en gebouwd. Dit zal de doorlooptijd van het project aanzienlijk doen verkorten. Alle invoer en uitvoer wordt vastgelegd, net zoals de te bewaren gegevensverzamelingen. Voor alle functies wordt vastgesteld bij welk subsysteem ze horen. De koppeling en interfaces met andere systemen worden ook beschreven. Hiervoor wordt onderzocht wat de relatie is met andere systemen, welke functies de andere systemen hebben en welke gegevensuitwisseling er is. Na het vaststellen van de subsystemen wordt er per onderdeel de systeemeisen genoteerd. Ook worden in deze fase de testcriteria en de testgegevens al verzameld alsook de eventuele organisatorische veranderingen.

De mijlpaalproducten voor deze fase zijn:

Bepaling technische systeemstructuur

Hoe gaat het systeem er technisch uitzien? Welke apparatuur, programmatuur, bestandsstructuur en wat voor DBMS wordt er gebruikt.

Deze fase borduurt verder op de vorige fase. Het ontwerp, dat is gemaakt in de vorige fase, wordt verder in detail uitgewerkt. Dit wordt gedaan door specifieker te beschrijven wat elk onderdeel van het systeem doet. Het resultaat hiervan is het functioneel ontwerp. Tevens legt men in deze fase vast hoe de beschreven onderdelen gerealiseerd worden. Dit resulteert in het technisch ontwerp.

De mijlpaalproducten voor deze fase zijn:

In deze fase wordt het systeem daadwerkelijk gebouwd (gerealiseerd). Hiervoor van belang zijn het functioneel ontwerp rapport en het technisch ontwerp rapport. Dit zijn de uitgangspunten waarop het systeem gebaseerd wordt. Ook wordt er in deze fase de benodigde hardware gekocht, worden dus de programma's geschreven, worden er cursussen gemaakt, wordt het systeem getest, wordt ervoor gezorgd dat de documentatie in orde is en geeft de opdrachtgever zijn eindoordeel middels de acceptatietest. Deze fase is af wanneer het systeem voldoet aan de eisen en uiteindelijk goed is gekeurd door de opdrachtgever; oftewel: wanneer beide tests succesvol zijn verlopen. Hierna wordt het nieuwe systeem bij het bedrijf ingevoerd.

De mijlpaalproducten voor deze fase zijn:

Tijdens deze fase wordt het opgeleverde systeem geïnstalleerd bij de opdrachtgever. De cursussen (uit de vorige fase), worden gegeven en het personeel wordt vertrouwd gemaakt met het nieuwe systeem. De gegevens worden in het nieuwe systeem ingevoerd, met een eventuele conversie. De documentatie wordt overhandigd aan de persoon die het nieuwe systeem moet gaan beheren (systeembeheerder). Ook wordt de omgeving waarin het nieuwe systeem moet draaien aangepast.

De mijlpaalproducten voor deze fase zijn:

Hoewel de organisatie het systeem volledig gaat overnemen, zijn er nog wel enkele richtlijnen wat betreft gebruik en beheer. Deze regels moeten ervoor zorgen dat het systeem blijft voldoen aan de gestelde eisen. Ook wordt aangegeven hoe defecten en storingen verholpen moeten worden. Bovendien kunnen deze regels belangrijk zijn bij het aanbrengen van verbeteringen. Al deze activiteiten hebben een doorlopend karakter; ze bestaan zolang het systeem bestaat. Deze fase wordt dan ook niet afgerond.

De mijlpaalproducten voor deze fase zijn:

De SDM methode maakt gebruik van de volgende modelleertechnieken:

Met deze modelleertechniek wordt een beperkte weergave van een systeem gemodelleerd. Uit deze modellen is af te lezen welke handelingen worden verricht binnen een systeem en met welke gegevens dat gebeurt. Hieruit is niet af te lezen wie iets doet en met welke apparatuur de handeling uitgevoerd wordt.

Als je begint met het maken van DFD's, is het eerste wat je maakt een globaal plaatje. Dat wil zeggen, je ziet niet wat er binnen in het systeem gebeurt. Dit is het contextdiagram. Een goed uitgangspunt voor dit diagram zijn de systeemeisen. In dit diagram leg je de relaties met de buitenwereld vast en wat tot je systeem behoort (en wat niet). Dit is de systeemgrens.

Bij elke van de zeven fasen wordt een activiteitenschema gemaakt. Hierin worden alle activiteiten genummerd en weergegeven. Door middel van pijlen wordt het verloop van de activiteiten zichtbaar. Wanneer er bijvoorbeeld een pijl van activiteit 1 naar activiteit 2 loopt, dan wordt activiteit 2 gestart, wanneer activiteit 1 is afgerond.

Duidelijke ordening van de verschillende fases;

Voorkomt het overslaan van belangrijke fasen.

Kans op mislukking is groot;

Kost veel tijd en dus geld;

In de definitiestudie moet het systeem al volledig worden beschreven;

Weinig gebruikersparticipatie.

Inefficiënt werken

Bron: Systeemontwikkeling deel1: statische informatiesystemen door: D.T.G.P. Vogelaars en J.J. Merk.

¹: bron: Turner, W.S., R.P. Langerhorst, G.F. Hice, H.B. Eilers, E.Remmerde, A.A. Uijttenbroek, SDM - System Development Methodology, Rijswijk, 1990

# data[].attributes.attachment_link.description
System Development Methodology ( SDM), ofwel Systeem Ontwikkelings Methodologie (Methodiek) is een faseringsmethode. Het wordt voornamelijk gebruikt bij projecten voor ontwikkeling van (geautomatiseerde) informatiesystemen. Deze methode is de laatste jaren aan verandering onderhevig omdat de ontwikkeling van de automatisering niet stilstaat.

# data[].attributes.body
Scrum

# data[].attributes.attachment_link.readable_text
Scrum is een framework om op een flexibele manier (software)producten te maken. Er wordt gewerkt in multidisciplinaire teams die in korte sprints, met een vaste lengte van 1 tot 4 weken, werkende (software) producten opleveren. Scrum is een term die afkomstig is uit de rugbysport. Bij een scrum probeert een team samen een doel te bereiken en de wedstrijd te winnen. Samenwerking is heel belangrijk en men moet snel kunnen inspelen op veranderende omstandigheden.

Scrum wordt vaak gebruikt bij producten waarvan de klant c.q. gebruiker nog niet goed weet wat hij wil en waarbij men al doende leert om de eisen en wensen beter te beschrijven en in bruikbare producten om te zetten. Vaak weet men pas wat men wil als men het eerste product, het prototype, ziet en dan worden alsnog de eisen aangepast. Scrum heeft de flexibiliteit om met laat wijzigende eisen en wensen om te gaan. Scrum valt onder de Agile-softwareontwikkeling.

Scrum werd geïntroduceerd in een onderzoek door Ikujiro Nonaka en Hirotaka Takeuchi, dat begin 1986 in de Harvard Business Review gepubliceerd is. In dit onderzoek wordt beschreven dat projecten met kleine (multidisciplinaire) teams historisch gezien het beste resultaat leveren. Naar aanleiding van dit onderzoek ontwikkelde Jeff Sutherland in 1993 het scrumproces, terwijl Ken Schwaber een eigen benadering bij zijn bedrijf toepaste. Samen werkten ze dit verder uit en in 1995 formaliseerde Ken Schwaber scrum als softwareontwikkelmethode. Scrum is ontwikkeld in de VS en wordt veelal gebruikt in deels Engelstalige projecten, vandaar de Engelse terminologie.

In korte sprints snel werkende producten opleveren, waardoor snel duidelijk wordt of men goed bezig is. Dit beperkt de risico's van langdurige projecten waarin gebruikers of klanten soms pas na een jaar het resultaat kunnen zien en uitproberen.

Snel duidelijkheid over de voortgang.

Korte lijnen, snelle communicatie, teamwerk.

Grotere betrokkenheid teamleden, concentratie op overzichtelijk deel van project

Scrum is gebaseerd op de theorie van empirische procesbesturing, ofwel het empirisme. Empirisme gaat ervan uit dat kennis ontstaat uit ervaring en het nemen van beslissingen op basis van wat bekend is. Scrum gebruikt een iteratieve, incrementele aanpak om voorspelbaarheid te optimaliseren en risico's te beheersen.
Drie pijlers vormen het fundament van elke implementatie van empirische procesbesturing:
transparantie, inspectie en aanpassing

Scrum heeft de volgende uitgangspunten:

Toewijding: de leden moeten zich er vol voor inzetten; het is geen deeltijdklus.

Focus: men moet zich focussen op wat er in de sprints gedaan moet worden.

Openheid: men moet elkaar goed op de hoogte houden van de voortgang en mogelijke problemen. (transparantie)

Respect: men moet mensen met een andere achtergrond en expertise respecteren.

Lef: men moet lef hebben om zaken te benoemen, vragen te stellen en met nieuwe oplossingen te komen.

Scrum werkt met multidisciplinaire teams, die bij voorkeur in één ruimte werken, zodat er gemakkelijk kan worden overlegd. Het team wordt begeleid door een scrummaster, die een faciliterende rol heeft. De Product Owner of Producteigenaar, is de klant of opdrachtgever, of een vertegenwoordiger daarvan. Hij of zij specificeert de gewenste resultaten, meestal in de vorm van user stories. Deze user stories worden bijgehouden in een lijst, de product backlog of werkvoorraad. De Producteigenaar sorteert de werkvoorraad op prioriteit. De belangrijkste user stories staan bovenaan.

Er wordt gewerkt in Sprints of iteraties. Die duren meestal van ca. een week tot een maand, met een tijdsduur van twee weken als meest gebruikelijke tijdsduur. Sprints zijn time boxed. Oftewel: van tevoren staat vast hoe lang een sprint maximaal duurt, en wanneer deze is afgelopen. Aan het begin van een Sprint worden de user stories voor die Sprint bepaald en vastgelegd in de Sprint Backlog.

Sprints resulteren in zo tastbaar mogelijke resultaten. Tav. softwareontwikkeling kan dat betrekking hebben op bruikbare code, inclusief integratie, tests en documentatie, en liefst toepasbaar voor de klant of eindgebruiker.

Aan het eind van een Sprint vindt een Sprint Review plaats, waarbij het resultaat wordt getoond aan de product owner. Daarnaast vindt een evaluatie binnen het team plaats.

Bij Scrum kent men de volgende drie hoofdrollen. Deze zijn:

Product Owner

De Product Owner (producteigenaar) is de opdrachtgever of klant. Hij heeft het meeste belang bij het (software)product dat gemaakt wordt. Hij zorgt ervoor dat de rekening betaald wordt. Hij beheert ook de product backlog, hij bepaalt wat er moet gebeuren en in welke volgorde. In principe wordt begonnen met het belangrijkste, waar het meeste voordeel mee te behalen is, wat boven aan de product backlog staat.

Ontwikkelteam

Het ontwikkelteam is multidisciplinair samengesteld en is verantwoordelijk voor het afleveren van het (software)product aan het einde van elke sprint. Het team bestaat meestal uit 3 tot 9 personen. Het team organiseert zichzelf. Zij doen de analyse, ontwerp, ontwikkeling, test en documentatie en zorgen dat er aan het eind van de sprint een kant en klaar product is, dat in principe in productie genomen kan worden.

Scrummaster

De scrummaster begeleidt en helpt het team door ervoor te zorgen dat het juiste scrumproces gevolgd wordt. Hij verzorgt ook eventuele trainingen. De scrummaster regelt alle vergaderingen. Ook regelt hij de voorzieningen zoals een werkruimte, hardware en software. De scrummaster zorgt ervoor dat het team niet lastig gevallen wordt door derden die met extra eisen tussendoor komen of die bijvoorbeeld tijdelijk mensen nodig hebben uit het team. De scrummaster is geen projectmanager. Hij regelt bijvoorbeeld niet de personele zaken zoals selectie, beoordeling en beloning van de mensen. Dit bevordert de openheid en samenwerking.

Elke dag is er de "Daily scrum" of "Stand-up". Deze vergadering heeft de volgende regels:

Alle leden van het ontwikkelteam hebben zich voor de vergadering voorbereid.

De vergadering start precies op tijd, ook als niet iedereen aanwezig is.

De vergadering is elke dag op precies dezelfde tijd en plaats, meestal 9.00 uur in de projectkamer.

De vergadering duurt maximaal 15 minuten, korter mag ook.

De vergadering wordt staande gehouden: "stand-up", zodat het daardoor al eenvoudig tot 15 minuten wordt beperkt. Vergelijkbaar met een overleg tussen sporters aan het begin van bijvoorbeeld een rugbywedstrijd.

Bezoekers zijn welkom maar normaal gesproken spreken alleen de leden van het ontwikkelteam.

Normaal gesproken houdt men een rondje waarbij elk teamlid drie vragen beantwoordt:

Wat heb je gedaan?

Wat ga je doen?

Zie je ook problemen en uitdagingen (impediments), heb je hulp nodig, zijn er dingen die voor andere teamleden van belang zijn?

Het beantwoorden van deze drie vragen moet kort en bondig zijn. Inhoudelijke informatie moet dan buiten de vergadering worden besproken.

De vergadering mag maximaal 15 minuten duren dus grotere problemen worden buiten de vergadering verder besproken. De vergadering is net lang genoeg om één kopje koffie, staande, op te drinken.

De user stories die op de backlog staan moeten gemaakt worden en verder uitgewerkt. Daarom is het belangrijk om goed te begrijpen van de producteigenaar en via hem van de rest van de organisatie, wat hij nu precies wil.

Zaken die in eerste instantie nog vaag zijn, zoals een "gebruikersinterface ontwikkelen", of "managementrapportages", kunnen mogelijk ook opgesplitst worden in kleinere beter behapbare onderdelen, zoals "gebruikersinterfaces voor verschillende groepen gebruikers", "financiële overzichten" en "commerciële overzichten".

Dit maakt het mogelijk om na te denken over de beste oplossing, zodat ook ingeschat kan worden hoeveel tijd het kost om dat te maken. Hierdoor wordt het ook mogelijk om acceptatiecriteria vast te leggen zodat er acceptatietests gemaakt kunnen worden. Mogelijk moet er zelfs nog aanvullend onderzoek gedaan worden in de vorm van zogenaamde "spikes". Binnen de watervalmethode zou dit de analysefase genoemd worden. Bij scrum heeft men dit overleg vrijwel wekelijks, gedurende het gehele project.

Dit proces is niet het belangrijkste scrum proces, maar is in de loop van de tijd toegevoegd om te zorgen dat de zaken op de back-log voldoende kwaliteit hebben (duidelijk genoeg zijn), om in de komende sprint opgenomen te worden.

Als er meerdere scrum teams zijn, is er ook een overleg tussen deze teams nodig. Het gaat dan om de punten waarop men met elkaar te maken heeft, interfaces etc. Dit overleg wordt normaal gesproken aansluitend op de daily scrum gehouden.

Elk team stuurt een vertegenwoordiger.

De agenda is ongeveer hetzelfde als bij de dagelijkse scrum, namelijk:

Wat hebben jullie gedaan sinds de vorige meeting?

Wat gaan jullie nu doen?

Gaat alles goed of hebben jullie problemen of vertraging?

Zijn er zaken die voor ons van belang zijn, waar we last van zouden kunnen hebben?

Als er afspraken niet nagekomen zijn wordt hierop gereageerd door het team.

Aan het begin van de sprint is er een sprint planning overleg. In principe worden de bovenste, belangrijkste user-stories van de product backlog in de sprint opgenomen. Het is cruciaal dat het ontwikkelteam de user-stories kiest die worden opgenomen, omdat de teamleden degenen zijn die zich engageren om de onderliggende taken uit te voeren. Daarom bepaalt ook het team hoeveel werk kan worden opgenomen in de betreffende sprint en is het team tevens verantwoordelijk voor de inschatting van de hoeveelheid werk per user-story. Het ontwikkelteam moet ook bevestigen dat alles duidelijk is. Taken worden dan vervolgens verder binnen het ontwikkelteam verdeeld.

In de "Sprint Review" wordt het product getoond dat af is. Eventueel wordt ook aangegeven wat niet gelukt is om af te krijgen deze sprint. De Sprint Review duurt maximaal 4 uur. Het hele sprint team is aanwezig plus eventueel andere geïnteresseerden. Na afloop een borrel, is een goede gewoonte.

Evaluatie (retrospective)

De evaluatie is bedoeld om te leren van wat goed en fout ging met als doel om als team nog beter te worden. Alle teamleden zijn dan ook aanwezig. Het overleg duurt max 3 uur per maand en wordt geleid door de scrummaster. Men maakt een rondje en iedereen zegt wat goed en fout ging. Men kan ook zeggen wat het meeste opviel of wat het moeilijkste was enz. Het is niet de bedoeling om mensen de schuld te geven van een vertraging. De bedoeling is hieruit lering te trekken voor komende sprints.

Een van de belangrijkste voorwaarden van een retrospectieve is tegelijk een van de grootste uitdagingen voor de moderator: het scheppen van een oplossingsgericht klimaat waarin deelnemers zich vrij kunnen uitspreken én gezonde onderlinge verstandhoudingen opgebouwd worden.

Hulpmiddelen (artifacts)

De product backlog is een overzicht van de dingen die nog gedaan moeten worden. Dit wordt in andere software ontwikkelmethoden wel de requirements genoemd, de eisen en wensen. Het bestaat uit alles wat van belang is om mee te nemen in de sprint zoals eigenschappen, fouten uit vorige releases, niet functionele eisen zoals navigatie, kleur, "look en feel", snelheidseisen etc. De product-owner is de eigenaar van deze lijst en bepaalt de volgorde. In principe staan de belangrijkste bovenaan, maar ook een andere volgorde is mogelijk. Hierbij spelen zaken als risico, waarde voor de organisatie, datum waarop iets nodig is, wettelijke eisen, etc. De zaken op de lijst zijn normaal gesproken in de vorm van een user story. Hierin staat WAT er gemaakt moet worden WAAROM en voor WIE. Iedereen kan er dingen aan toevoegen, maar de product-owner is en blijft verantwoordelijk. Er staan ook ruwe schattingen bij van de waarde voor de organisatie en van de ontwikkelkosten. Voor het inschatten van de ontwikkeltijd kan gebruikgemaakt worden van wat binnen scrum "planning poker" genoemd wordt.

In de sprint backlog staat wat er deze sprint wordt gedaan. De sprint backlog wordt samengesteld uit de bovenste items van de product backlog. Het ontwikkelteam bepaalt wat ze kunnen doen gebaseerd op hun snelheid in de vorige sprints.

Gebruikelijk is dat de items op de sprint backlog geschreven worden op post-its. Er zijn dan drie kolommen, "to do", "in progress", "done". Soms met een vierde kolom "testing". Zodoende is voor iedereen duidelijk hoe het ermee staat.

Het ontwikkelteam bepaalt zelf wie wat doet, of eigenlijk kiezen de leden zelf wat ze (kunnen en willen) oppakken van de todo-lijst. Dit bevordert dat het team zich ermee verbonden voelt, dat ze zich er voor willen inzetten, dat het hun product wordt.

Er kunnen na de start geen items meer toegevoegd worden aan de sprint, behalve door het ontwikkelteam zelf. Nadat de sprint klaar is wordt de Product Backlog nog eens tegen het licht gehouden en kunnen prioriteiten en dus de volgorde wijzigen.

Acceptatiecriteria (definition of done)

In de "Definition of done" staat wat er is afgesproken over hoe men een product oplevert. Eisen over documentatie (Engelstalig), testen (getest door gebruikers en de afdeling beheer, met welke apparaten en webbrowsers), locatie (op de acceptatieomgeving) etcetera.

Verbetering (increment)

De "verbetering" (increment) is een lijst van alle gerealiseerde verbeteringen en veranderingen aan het product. Deze lijst wordt in elke sprint, aan het eind van de sprint bijgewerkt. Hierop staan alleen items die voldoen aan de "definition of done". Dit overzicht moet in een vorm zijn die bruikbaar is voor de klant of product-owner. De lijst kan nodig zijn om verdere investeringen in het project te verdedigen en om aan buitenstaanders, klanten, handelaren en de overheid duidelijk te maken wat men tot nu toe bereikt heeft. Of deze lijst gebruikt en gepubliceerd wordt, ligt aan de producteigenaar. Op basis van Engelse terminologie wordt dit ook wel aangeduid als PSI of Potentially Shippable Product.

De burn down chart van de sprint hangt meestal aan de wand in de projectkamer. Op die manier is voor iedereen direct duidelijk hoeveel er nog gedaan moet worden. Doordat hij dagelijks wordt bijgewerkt is direct duidelijk hoe het ervoor staat. Er zijn ook andere typen "burn down chart" in gebruik, bijvoorbeeld de release burn down chart waarop staat hoeveel er nog gedaan moet worden voor de volgende release van het product (ervan uitgaande dat een "release" in meerdere sprints gerealiseerd wordt). Ook bestaat er een alternative release burn down chart, deze doet in principe hetzelfde, maar geeft extra de wijzigingen aan door het meer/minder werk, veroorzaakt door het voortschrijdende inzicht.

De volgende begrippen worden gebruikt in scrum en/of zijn bruikbaar om het geheel te begrijpen.

Scrumteam (Scrum Team)

Producteigenaar, scrummaster en ontwikkelteam

Producteigenaar (ProductOwner)

De verantwoordelijke voor de productbacklog, waarmee de prioriteiten van de belanghebbenden naar voren komen zodat het werk van het ontwikkelteam waarde heeft voor de organisatie.

Scrummaster

De verantwoordelijke voor het scrumproces, de persoon die ervoor zorgt dat alles goed loopt en men maximaal profiteert van de voordelen van scrum.

Ontwikkelteam

een groep van specialisten verantwoordelijk voor het ontwikkelwerk en de realisatie van een in principe kant en klaar product(uitbreiding).

Sprint burn down chart

Een grafiek waarmee de dagelijkse voortgang van de sprint wordt weergegeven.

Release burn down chart

Een grafiek waarmee wordt aangegeven wat er al van de productbacklog klaar is en wat er nog gedaan moet worden.

Productbacklog (Product backlog)

Een lijst met op een hoog niveau de eisen en wensen voor het product.

Sprintbacklog (Sprint backlog)

Een lijst met taken die tijdens de sprint moeten worden uitgevoerd, inclusief een plan voor het opleveren van het product increment.

Sprint

Een periode van 1 tot 4 weken waarin men een aantal zaken van de productbacklog oppakt. Dit is een time-box.

Spike

Een korte periode waarin in een time-box een onderzoek gedaan wordt. Bijvoorbeeld om een prototype te maken of te testen of iets mogelijk is.

Lichtkogel (Tracer Bullet)

Een lichtkogel (tracer bullet) is een spike waarmee men probeert te onderzoeken wat de mogelijkheden zijn van de gekozen projectarchitectuur, technologie en best practice. Het resultaat is een stukje programmatuur. Het is misschien de ontwikkeling van een klein onderdeel, maar het is geen wegwerp programmatuur. Het kan in het verdere proces gebruikt worden. Het is een "Proof of concept" en ook een "Prototype", bedoeld om inzicht te krijgen in de nieuwe architectuur, technologie en werkwijze. De naam komt uit het leger, daar gebruikt men lichtspoormunitie om het spoor van de kogels te volgen en eventueel de richting te corrigeren.

Taken

Aan het begin van de sprint worden de stories van de productbacklog uiteengerafeld tot taken. Aan een taak hangt een planning in uren. Een taak mag volgens de theorie maximaal 12 uur zijn, maar meestal spreekt men af dat taken maximaal een dag (8 uur) duren.

Definition of Done (DoD)

De afvinkcriteria waaraan iets moet voldoen om klaar te zijn. Deze criteria worden door het development team samen bepaald. In veel gevallen is bijvoorbeeld een eis dat alle regressietests succesvol zijn afgesloten.

Velocity

De snelheid van het team, wat het team kan doen in één sprint. De snelheid kan worden berekend op grond van de gerealiseerde snelheid in vorige sprints, gemeten in storypunten, met behulp van een burn down chart. Dit is een richtlijn voor het team en omgeving om goed in te kunnen schatten hoeveel men kan doen en wat men kan verwachten.

Impediment

(Obstakel) Alles wat in de weg staat van een efficiënt proces.

Sashimi

Een rapport waarin is aangegeven dat iets "klaar" is.

Abnormal Termination

(Abort). Indien nodig kan de product-owner (producteigenaar) een sprint voortijdig stoppen. De product-owner kan dit doen met input van het team, scrummaster of management. Het kan bijvoorbeeld zo zijn dat het management de sprint wil stoppen omdat externe omstandigheden het doel van de sprint niet meer nuttig maken. Als een sprint op deze manier gestopt wordt is het vervolg dat men in een vergadering uitlegt waarom dit nodig was, tevens is er dan weer een nieuwe "Sprint planning vergadering" om de volgende sprint te plannen.

ScrumBut

Een ScrumBut is een uitzondering op de "echte" Scrumwerkwijze, waarbij het team scrum heeft aangepast aan hun eigen behoefte.

Pair programming

Het in tweetallen werken aan een programma of probleem. Dit is een intensieve samenwerking waarmee men van elkaar leert en samen iets probeert op te lossen wat te moeilijk is voor een persoon omdat kennis of vaardigheden ontbreken. Men kan hierbij gebruikmaken van elkaars expertise.

Refactoring

Het opnieuw maken, ontwikkelen of programmeren van een bepaald onderdeel om het beter (onderhoudbaar) te maken.

Storypoint

Worden gebruikt in planning om de omvang van een klus (story) aan te geven. Door een bekende korte klus 1 of 2 punten te geven kunnen grote klussen ingeschat worden als bijvoorbeeld driemaal zo lang of tienmaal zo lang.

Timeboxing

Een methode waarbij men een afgesproken tijd (time-box) neemt om iets te doen. Zodoende kan iets ook niet uitlopen. Men kan bijvoorbeeld voor het testen afspreken dat men drie dagen neemt om te zoeken naar fouten. Of men kan afspreken om per gebruiker twee dagen training te geven. Vergaderingen kunnen een begintijdstip en een eindtijdstip hebben.

Triangulation

Een planningsmethode waarbij men vanuit verschillende gezichtspunten tot goede schattingen hoopt te komen. Voornamelijk door met elkaar te praten over waarom men denkt dat iets een bepaalde tijd gaat duren.

# data[].attributes.attachment_link.description
Scrum is een framework om op een flexibele manier (software)producten te maken. Er wordt gewerkt in multidisciplinaire teams die in korte sprints, met een vaste lengte van 1 tot 4 weken, werkende (software) producten opleveren. Scrum is een term die afkomstig is uit de rugbysport.

# data[].attributes.body
Uitlegvideo

# data[].attributes.body
Wat zijn user stories en hoe maak je ze?

# data[].attributes.body
Theorie en opdracht

# data[].attributes.body
Wikipedia

# data[].attributes.attachment_link.readable_text
Business process modeling ( BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from events' logs using process mining tools.

The business objective is often to increase process speed or reduce cycle time; to increase quality; or to reduce costs, such as labor, materials, scrap, or capital costs. In practice, a management decision to invest in business process modeling is often motivated by the need to document requirements for an information technology project.

Change management programs are typically involved to put any improved business processes into practice. With advances in software design, the vision of BPM models becoming fully executable (and capable of simulations and round-trip engineering) is coming closer to reality.

Techniques to model business process such as the flow chart, functional flow block diagram, control flow diagram, Gantt chart, PERT diagram, and IDEF have emerged since the beginning of the 20th century. The Gantt charts were among the first to arrive around 1899, the flow charts in the 1920s, Functional Flow Block Diagram and PERT in the 1950s, Data Flow Diagrams and IDEF in the 1970s. Among the modern methods are Unified Modeling Language and Business Process Model and Notation. Still, these represent just a fraction of the methodologies used over the years to document business processes. The term 'business process modeling' was coined in the 1960s in the field of systems engineering by S. Williams in his 1967 article 'Business Process Modelling Improves Administrative Control'. His idea was that techniques for obtaining a better understanding of physical control systems could be used in a similar way for business processes. It was not until the 1990s that the term became popular.

In the 1990s the term ' process' became a new productivity paradigm. Companies were encouraged to think in processes instead of functions and procedures. Process thinking looks at the chain of events in the company from purchase to supply, from order retrieval to sales, etc. The traditional modeling tools were developed to illustrate time and cost, while modern tools focus on cross-functional activities. These cross-functional activities have increased significantly in number and importance, due to the growth of complexity and dependence. New methodologies include business process redesign, business process innovation, business process management, integrated business planning, among others, all "aiming at improving processes across the traditional functions that comprise a company".

In the field of software engineering, the term 'business process modeling' opposed the common software process modeling, aiming to focus more on the state of the practice during software development. In that time (the early 1990s) all existing and new modeling techniques to illustrate business processes were consolidated as 'business process modeling languages'[citation needed ]. In the Object Oriented approach, it was considered to be an essential step in the specification of business application systems. Business process modeling became the base of new methodologies, for instance, those that supported data collection, data flow analysis, process flow diagrams, and reporting facilities. Around 1995, the first visually oriented tools for business process modeling and implementation were being presented.

A business model is a framework for creating economic, social, and/or other forms of value. The term 'business model' is thus used for a broad range of informal and formal descriptions to represent core aspects of a business, including purpose, offerings, strategies, infrastructure, organizational structures, trading practices, and operational processes and policies.

In the most basic sense, a business model is a method of doing business by which a company can sustain itself. That is, generate revenue. The business model spells-out how a company makes money by specifying where it is positioned in the value chain.

A business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. There are three main types of business processes:

1. Management processes, that govern the operation of a system. Typical management processes include corporate governance and strategic management.

2. Operational processes, that constitute the core business and create the primary value stream. Typical operational processes are purchasing, manufacturing, marketing, and sales.

3. Supporting processes, that support the core processes. Examples include accounting, recruitment, and technical support.

A business process can be decomposed into several sub-processes, which have their own attributes but also contribute to achieving the goal of the super-process. The analysis of business processes typically includes the mapping of processes and sub-processes down to activity level. A business process model is a model of one or more business processes and defines the ways in which operations are carried out to accomplish the intended objectives of an organization. Such a model remains an abstraction and depends on the intended use of the model. It can describe the workflow or the integration between business processes. It can be constructed in multiple levels.

A workflow is a depiction of a sequence of operations, declared as work of a person, of a simple or complex mechanism, of a group of persons, of an organization of staff, or of machines. The workflow may be seen as any abstraction of real work, segregated into workshare, work split or other types of ordering. For control purposes, the workflow may be a view of real work under a chosen aspect.

The artifact-centric business process model has emerged as a holistic approach for modeling business processes, as it provides a highly flexible solution to capture operational specifications of business processes. It particularly focuses on describing the data of business processes, known as "artifacts", by characterizing business-relevant data objects, their life-cycles, and related services. The artifact-centric process modelling approach fosters the automation of the business operations and supports the flexibility of the workflow enactment and evolution.

Business process modelling tools provide business users with the ability to model their business processes, implement and execute those models, and refine the models based on as-executed data. As a result, business process modelling tools can provide transparency into business processes, as well as the centralization of corporate business process models and execution metrics. Modelling tools may also enable collaborate modelling of complex processes by users working in teams, where users can share and simulate models collaboratively. Business process modelling tools should not be confused with business process automation systems - both practices have modeling the process as the same initial step and the difference is that process automation gives you an 'executable diagram' and that is drastically different from traditional graphical business process modelling tools.[citation needed ]

Modelling and simulation functionality allows for pre-execution "what-if" modelling and simulation. Post-execution optimization is available based on the analysis of actual as-performed metrics.

Some business process modelling techniques are:

BPM suite software provides programming interfaces (web services, application program interfaces (APIs)) which allow enterprise applications to be built to leverage the BPM engine. This component is often referenced as the engine of the BPM suite.

Programming languages that are being introduced for BPM include:

Some vendor-specific languages:

Other technologies related to business process modelling include model-driven architecture and service-oriented architecture.

A business reference model is a reference model, concentrating on the functional and organizational aspects of an enterprise, service organization or government agency. In general a reference model is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes. A business reference model is a means to describe the business operations of an organization, independent of the organizational structure that perform them. Other types of business reference model can also depict the relationship between the business processes, business functions, and the business area's business reference model. These reference models can be constructed in layers, and offer a foundation for the analysis of service components, technology, data, and performance.

The most familiar business reference model is the Business Reference Model of the US federal government. That model is a function-driven framework for describing the business operations of the federal government independent of the agencies that perform them. The Business Reference Model provides an organized, hierarchical construct for describing the day-to-day business operations of the federal government. While many models exist for describing organizations - organizational charts, location maps, etc. - this model presents the business using a functionally driven approach.

A business model, which may be considered an elaboration of a business process model, typically shows business data and business organizations as well as business processes. By showing business processes and their information flows, a business model allows business stakeholders to define, understand, and validate their business enterprise. The data model part of the business model shows how business information is stored, which is useful for developing software code. See the figure on the right for an example of the interaction between business process models and data models.

Usually a business model is created after conducting an interview, which is part of the business analysis process. The interview consists of a facilitator asking a series of questions to extract information about the subject business process. The interviewer is referred to as a facilitator to emphasize that it is the participants, not the facilitator, who provide the business process information. Although the facilitator should have some knowledge of the subject business process, but this is not as important as the mastery of a pragmatic and rigorous method interviewing business experts. The method is important because for most enterprises a team of facilitators is needed to collect information across the enterprise, and the findings of all the interviewers must be compiled and integrated once completed.

Business models are developed as defining either the current state of the process, in which case the final product is called the "as is" snapshot model, or a concept of what the process should become, resulting in a "to be" model. By comparing and contrasting "as is" and "to be" models the business analysts can determine if the existing business processes and information systems are sound and only need minor modifications, or if reengineering is required to correct problems or improve efficiency. Consequently, business process modeling and subsequent analysis can be used to fundamentally reshape the way an enterprise conducts its operations.

Business process reengineering (BPR) aims to improve the efficiency and effectiveness of the processes that exist within and across organizations. It examines business processes from a "clean slate" perspective to determine how best to construct them.

Business process re-engineering (BPR) began as a private sector technique to help organizations fundamentally rethink how they do their work. A key stimulus for re-engineering has been the development and deployment of sophisticated information systems and networks. Leading organizations use this technology to support innovative business processes, rather than refining current ways of doing work.

Business process management is a field of management focused on aligning organizations with the wants and needs of clients. It is a holistic management approach[citation needed ] that promotes business effectiveness and efficiency while striving for innovation, flexibility and integration with technology. As organizations strive for attainment of their objectives, business process management attempts to continuously improve processes - the process to define, measure and improve your processes - a "process optimization" process.

Aguilar-Saven, Ruth Sara. "Business process modelling: Review and framework." International Journal of production economics 90.2 (2004): 129-149.

Barjis, Joseph (2008). "The importance of business process modeling in software systems design". Science of Computer Programming. 71: 73-87. doi:10.1016/j.scico.2008.01.002.

Becker, Jörg, Michael Rosemann, and Christoph von Uthmann. "Guidelines of business process modelling." Business Process Management. Springer Berlin Heidelberg, 2000. 30-49.

Hommes, L.J. The Evaluation of Business Process Modelling Techniques. Doctoral thesis. Technische Universiteit Delft.

Håvard D. Jørgensen (2004). Interactive Process Models. Thesis Norwegian University of Science and Technology Trondheim, Norway.

Manuel Laguna, Johan Marklund (2004). Business Process Modeling, Simulation, and Design. Pearson/Prentice Hall, 2004.

Ovidiu S. Noran (2000). Business Modelling: UML vs. IDEF Paper Griffh University

Jan Recker (2005). "Process Modelling in the 21st Century". In: BP Trends, May 2005.

Ryan K. L. Ko, Stephen S. G. Lee, Eng Wah Lee (2009) Business Process Management (BPM) Standards: A Survey. In: Business Process Management Journal, Emerald Group Publishing Limited. Volume 15 Issue 5. ISSN 1463-7154.

Jan Vanthienen, S. Goedertier and R. Haesen (2007). "EM-BrA2CE v0.1: A vocabulary and execution model for declarative business process modelling". DTEW - KBI_0728.

# data[].attributes.attachment_link.description
Business process modeling ( BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both.

# data[].attributes.body
Simple introduction

# data[].attributes.attachment_link.title
What is BPMN? Simple introduction for any audience