Gepubliceerd in
Management
De term 'bloempjes van Catharina' verwijst naar Catharina de Grote (1729-1796), tsarina van Rusland. Het verhaal gaat dat zij op een van haar wandelingen in de tuin een mooie bloem zag. Omdat ze niet wilde dat deze bloem vertrapt wordt, roept ze een soldaat en geeft hem de opdracht om naast het bloempje te gaan staan om zo te vermijden, dat iemand erop zal trappen. Na enige tijd wordt de soldaat afgelost door een tweede. Jaren gaan voorbij. Nog steeds houdt een soldaat de wacht op dezelfde plek, maar inmiddels is er geen bloempje meer te zien. Bij navraag waarom hij daar staat weet eigenlijk niemand het. Maar ze laten hem daar staan, want er zal toch wel een reden voor zijn.
De 'bloempjes van Catharina' zijn een metafoor voor het verschijnsel dat zich in veel organisaties voorkomt van ingesleten werkmethoden die worden verklaard met de opmerking: “Ach, zo deden we het altijd al, ik weet eigenlijk niet precies waarom we dat zo doen”. Het gaat dus om gedragsgewoonten, ingesleten handelingspatronen, waar vaak op dit moment geen reden meer is.
Bron: Bloempjes van Catharina - in een organisatie
Laatst aangepast op dinsdag, 02 januari 2018 08:28
PDCA-cyclus (Deming-cirkel)
Gepubliceerd in
Management
Werken met processen is sturen op resultaten. Aan de basis van elk proces ligt een regelkring waarin permanent bewaakt wordt of het beoogde resultaat ook daadwerkelijk bereikt wordt. De meest gebruikte regelkring bij pocesbesturing is de PDCA–cirkel, waarbij "PDCA" staat voor 'Plan' (plannen), 'Do' (uitvoeren), 'Control' (meten) en 'Act' (bijsturen). Dit concept is in de jaren vijftig ontwikkeld door dr. W. Edwards Deming en wordt daarom wel de Deming-cirkel genoemd.
De kern van PDCA is dus een viertrapsraket, waarbij je eerst een plan maakt met de resultaten die je wilt bereiken (plan). Vervolgens ga je aan de slag met het uitvoeren van het plan (do). Zodra je resultaten boekt, vergelijk je deze met wat je had willen bereiken (control). Op basis van de uitkomst van de vergelijking, neem je maatregelen (lees: bijsturen) om de resultaten alsnog te bereiken (act).
De PDCA–cirkel bevat de meest essentiële stappen van besturing in het algemeen en van procesbesturing in het bijzonder.
Laatst aangepast op zondag, 31 december 2017 08:18
Integrated Service Management (ISM)
Gepubliceerd in
Informatiemanagement
Integrated Service Management (ISM) is een methode voor het organiseren van de dienstverlening van de IT-organisatie. ISM bestaat uit een procesmodel, een integratie met een set van tools, een serie templates, een organisatiebeschrijving, een standaard definitiestelsel, en een implementatie-aanpak.
Het procesmodel van ISM beschrijft in slechts zes elementaire processen de werkzaamheden op tactisch en operationeel niveau, in een volledig geïntegreerd model. Deze zes processen, die op uniforme en zuivere wijze tot op activiteitenniveau zijn uitgewerkt, sluiten aan op de bekende ITIL-processen. Het ISM-procesmodel bestaat uit de volgende zes processen:
-
Service Level Management (SLM)
-
Change Management (CHM)
-
Operations Management (OM)
-
Incident Management (IM)
-
Configuration Management (COM)
-
Quality Management (QM)
In de woorden van de makers:
"ISM is afgeleid van ITIL en ASL maar onderscheidt zich door structuur, eenvoud en toepasbaarheid, en met name omdat ISM geen referentiemodel is maar een toepassingsmodel. De ISM-methode levert, integreert en ontsluit de middelen die de IT-beheerder nodig heeft voor de inrichting en besturing van de beheerorganisatie. Met ISM kan de beheerorganisatie snel en efficiënt bepalen en vastleggen wat er moet gebeuren, wanneer en door wie, en met behulp van welke middelen. (...) Het ISM-procesmodel Een IT-beheerorganisatie kent maar een beperkt aantal processen. Deze zijn voor alle organisaties gelijk. Het ISM-procesmodel beschrijft in slechts zes processen, afgeleid van ITIL, alle werkzaamheden op tactisch en operationeel niveau. Door deze compacte, herkenbare vorm is ISM eenvoudig overal toe te passen."
Bron: http://www.ismportal.nl
Laatst aangepast op vrijdag, 17 november 2017 22:05
Kwaliteit (volgens Crosby)
Gepubliceerd in
Lean Six Sigma
Kwaliteitsgoeroe Philip - Quality is free, but it is not a gift - Crosby onderscheidt vier pijlers voor kwaliteit:
-
Voldoen aan vereisten (definitie van kwaliteit): elk product, elke dienst en elk proces dat voldoet aan de gestelde vereisten van de klant (c.q. de eigen interne eisen) is een kwaliteitsproduct, een kwaliteitsdienst of een kwaliteitsproces..
-
Preventie (kwaliteitssysteem): insteek is fouten te voorkomen, fouten kosten immers geld. Iedere fout die gemaakt wordt, om welke reden dan ook, gaat ten koste van het rendement van de organisatie. Immers, een fout maken, betekent later een fout ook weer herstellen en dat kost tijd, geld, capaciteit en motivatie..
-
Zero Defects (kwaliteitsnorm): een norm is nodig om te kunnen vergelijken, de belangrijkste prestatienorm die Crosby voorstaat is de norm van 'Nul Fouten', Crosby bedoelt hiermee niet, wat vaak wél wordt gedacht, letterlijk nul fouten maken. Fouten treden altijd op, maar Crosby stelde alleen maar, dat je fouten nooit mag accepteren. Het gaat hem er vooral om dat je vastbesloten moet zijn kwaliteit te leveren door op ieder niveau de vereisten van ons werk te begrijpen en te doen wat gedaan moet worden om aan de vereisten te voldoen. De norm is dus dat het Niet Voldoen niet aanvaardbaar is..
-
Prijs van Niet Voldoen (meetsysteem): de 'Prijs van niet voldoen' (PNV) is wat het kost als tijd, geld en energie wordt verspild - binnen Six Sigma aangeduid met ‘De verborgen fabriek'. De manier om kwaliteit te meten passende bij de norm Zero Defects is de ‘Prijs van het Niet Voldoen’ (PNV) te meten. Crosby's meetsysteem is gebaseerd op het principe van preventie om te voorkomen, dat een situatie van ‘Niet Voldoen’ niet ontstaat. Het systeem is gebaseerd op controle vooraf en op voortdurend zoeken naar manieren om te verbeteren. Crosby baseert zich daarbij op het bekende kwaliteitskostenmodel van Juran, dat stelt dat fouten herstellen vele factoren duurder is dan fouten voorkomen. Vandaar de uitspraak: ‘Doe de dingen in één keer goed, want daarna wordt het altijd duurder en nooit beter.’.
Volgens Crosby bestaat de weg naar kwaliteit uit de onderstaande 14 stappen:
-
Verkrijgen management commitment voor het idee dat fouten voorkómen goedkoper is dan fouten repareren.
-
Samenstellen kwaliteitsverbeterteam, waarin alle afdelingen vertegenwoordigd zijn.
-
Maken (of herzien) kwaliteitsmetingen voor elk gebied of activiteit.
-
Bereken de kwaliteitskosten. De kosten van (non-)kwaliteit zijn weliswaar moeilijk meetbaar, maar ze zijn een indicatie waar corrigerende maatregelen het meest kostenbesparend kunnen werken.
-
Kwaliteitsbewustwording. Maak non-kwaliteit bespreekbaar. Maak alle medewerkers bewust van de kosten van slechte kwaliteit.
-
Aanmoedigen medewerkers problemen naar voren te brengen. Neem corrigerende maatregelen om ze te verhelpen. Vergeet niet de oplossingen regelmatig naar de medewerkers terug te koppelen.
-
Omzetten kwaliteitsbewustzijn in een structurele organisatie met een concreet doel (namelijk nul fouten): het zgn. nulfoutenprogramma.
-
Train leidinggevenden in kwaliteitsverbetering en het nul-foutenconcept.
-
Organiseren van een zgn. nulfouten-dag ("Zero Defects Day") als officiële start van de nieuwe werkhouding.
-
Vaststellen doelstellingen (30, 60 en 90 dagen vooruit) door leidinggevende om nul fouten in hun afdeling te bereiken.
-
Verwijderen van oorzaak van fouten. Iedereen moet (kort) alle problemen beschrijven die hen weerhouden foutloos te werken. Specialisten zorgen voor oplossingen.
-
Tonen van waardering richting de mensen die hun doelen gehaald hebben. Denk daarbij niet aan een financiële beloning.
-
Houden van (regelmatige) kwaliteitsvergaderingen om te bepalen welke acties nodig zijn om het kwaliteisprogramma verder te verbeteren.
-
Kwaliteit laten inwortelen in de organisatie door het nulfoutenprogramma te blijven herhalen en aan te passen zodat het levenslang meegaat.
Bron: http://www.adburdias.nl/
Laatst aangepast op zondag, 04 november 2018 08:26
Veranderen volgens De Caluwé
Gepubliceerd in
Management
In de veranderkunde zijn 5 verschillende manieren van denken en doen te onderscheiden: - geeldrukdenken: denken vanuit machtsvorming en machtsverschillen - blauwdrukdenken: denken vanuit ratio en structuur - rooddrukdenken: denken vanuit onderlinge menselijke relaties en cohesie - groendrukdenken: denken vanuit leren, ontwikkelen en professionaliseren
De 5 werelden komen overal voor. Ze hebben ook een schaduwkant en botsen vaak onderling. Ideale organisaties kunnen met deze strijdigheden omgaan. De grootste bedreiging is eenzijdigheid: bepaalde kleuren te veel, andere te weinig. Elke manier van denken past goed bij een bepaalde context en verandering. Voor individuen zijn meestal 1 of 2 van de kleuren favoriet, voor 1 of 2 denkmanieren zijn ze juist allergisch. Veranderaars kunnen leren de eigen manieren te relativeren en gevoel te ontwikkelen voor kleuren waarvoor zij allergisch zijn.
Volgens De Caluwé gaat het in de prakijk niet altijd goed met zijn model:"Soms wordt het model niet goed toegepast. Dan worden bijvoorbeeld alleen de kleuren gebruikt om iets een label te geven, en wordt er verder niets mee gedaan. Dan heb je er nog niets aan. De kleuren zijn juist bedoeld om de complexiteit te leren zien, en hoe de dynamiek ertussen is."
Léon de Caluwé en Hans Vermaak (1999) hebben de grote verscheidenheid in het denken over organisatieverandering verder verfijnd en gegroepeerd. In feite integreren zij alle verschillende benaderingen in vijf manieren van denken over veranderen. Elke manier van veranderen correspondeert met één van de vijf kleuren: geel, blauw, rood, groen en wit. Het kleurendenken wordt gebruikt als een vijf kleurenpalet (vijf strategieën) waar de veranderaar een keuze uit kan maken. Volgens Caluwé en Vermaak zijn werkbare veranderstrategieën gebaseerd op de dominantie, het leidend zijn van één kleurdruk: de basiskleur. Dit houdt in dat een veranderingsstrategie gebaseerd is op de denkbeelden van één kleur.
(1) Geel ('Geeldrukstrategie'): richten van opvattingen, belangen, conflict en macht
(2) Baluw: doelgericht veranderen
(3) Rood: het beste uit mensen naar voren halen
(4) Groen: veranderen door leren
(5) Wit: individueel en autonoom veranderen
Geel denken verwijst naar de politieke metafoor en naar het denken over belangen, conflicten en macht in veranderingsprocessen. Beslissers manoeuvreren en proberen heersende opvattingen en machtsprocessen te beïnvloeden. De geeldrukstrategie is gebaseerd op socio-politieke opvattingen over organisaties, waarbij belangen, conflicten en macht een belangrijke rol spelen. Het geeldrukdenken symboliseert het streven om alle neuzen in dezelfde richting te krijgen. Doelen stellen, beleid bepalen, het programma formuleren gebeurt door het creëren van draagvlak, belangen te bundelen, win-win situaties te creëren, en door het politieke machtsspel en onderhandelen. Het gele veranderingsstraject is moeilijk te structureren en te plannen. Het kan worden gezien als een onderhandelingsarena waarin uiteenlopende belanghebbenden zijn vertegenwoordigd. Verandering vindt daarom plaats als men erin slaagt belangen bij elkaar te brengen en win-win situaties te creëren.
Blauw denken verwijst naar het rationeel ontwerpen en implementeren van een verandering, zoals een projectmanagementaanpak. Daarin wordt het veranderingsproces in stappen opgeknipt en uitgevoerd. De wijze van verandering is rationeel: eerst denken en daarna doen.
Rood denken richt zich op het veranderen van de zachte aspecten in een organisatie, zoals de managementstijl, de personeelsamenstelling en de competenties. Daarbij wordt gebruik gemaakt van HRM-instrumenten, zoals belonen, beoordelen, bevorderen, groeien en saneren. De rooddrukstrategie gebruikt het feit dat mensen gemotiveerd worden iets te doen als ze in ruil daarvoor iets terug krijgen.
Groen denken richt zich op het lerend vermogen van organisaties. Bij de groendrukstrategie wordt ervan uitgegaan dat verandering plaatsvindt als organisatieleden gemotiveerd zijn om te leren, als ze in leersituaties worden gebracht en als hen effectieve manieren aangereikt worden om een andere manier van doen aan te leren. De weg naar de beoogde uitkomst wordt gekenmerkt door het creëren van leersituaties. Het afdwingen van de verandering is contraproductief. Mensen moeten gemotiveerd in leersituaties gebracht worden om zo effectief mogelijk te kunnen veranderen.
Wit denken gaat ervan uit dat een organisatie een complex levend systeem is met zelforganiserend vermogen in een flux van verandering en beperkte voorspelbaarheid en beïnvledbaarheid. De mens is autonoom en beslist zelf of hij wil veranderen. Beslissers hebben daarop weinig tot geen invloed: the better argue their case. De witdrukstrategie is afgeleid van de chaostheorie, of de theorie van de complexiteit. Bij deze theorieën draait het om levende complexe systemen met een beperkte voorspelbaarheid. Een centraal begrip binnen deze context is zelforganisatie. Het zelforganisatieproces omvast het ontstaan van nieuwe structuren en gedragswijzen door ontwikkelings-, leer- en evolutieprocessen. Het systeem hervindt vervolgens zelf zijn optimale dynamische evenwicht. De centrale gedachte is dat een organisatie zich op eigen kracht ontwikkelt, en vindt zelf de meest effectieve manier om tot iets te komen.
De Caluwé en Vermaak onderscheiden zes factoren die leiden tot een 'juiste' keuze voor een bepaalde veranderstrategie: (1) beoogde uitkomst, (2) stand van zaken, (3) verschil tussen huidig en gewenst, (4) weerstand en blokkades, (5) stijl van de veranderaar en (6) ervaring.
Veranderen is te beschouwen als het realiseren of mogelijk maken van (beoogde) uitkomsten; het gaat erom bewust interventies te plegen om de richting van de verandering te beïnvloeden. Het is niet een kwestie van weten waar je heen ging, als je er aangekomen bent, er is een veranderidee vooraf dat richtinggevend is, dat gaandeweg concreter wordt en dat moet lijken op de werkelijke uitkomsten aan het eind van het verandertraject.
Het verschil tussen huidig en gewenst
Caluwé en Vermaak zien het verschil tussen huidig en gewenst als zijnde de vraag: verbeteren of vernieuwen? Verbeteren is hetzelfde steeds beter doen. Vernieuwen is denkkaders doorbreken en ter discussie stellen. Beter iets anders doen dus. Het belang van het onderscheid tussen vernieuwen en verbeteren ligt in het feit dat het de te kiezen veranderstrategie al een beetje typeert. Verbetering zal leiden tot een blauwe veranderstrategie bij een blauwdrukomgeving. Een betere HRM-aanpak (rode strategie) in een persoonsgerichte organisatie (rooddruk organisatie). Vernieuwen zal leiden tot een andere kleur strategie dan de huidige dominante kleur van de organisatie.
Weerstand en blokkades
Weerstand kan worden gezien als alle krachten die bijdragen aan de stabiliteit in de persoonlijkheid of in de sociale systemen. Het is een normaal en waardevol verschijnsel dat ons waarschijnlijk behoedt voor chaos. Weerstand tegen geplande verandering komt voor op drie niveaus: individueel niveau, groepsniveau en organisatieniveau. Weerstand op individueel niveau wordt gezien als psychologische barrières: angst voor het onbekende, lage waarderingstolerantie, desinteresse van de manager, gebrek aan vertrouwen in anderen, behoefte aan veiligheid, wens tot status quo. Weerstand op groepsnivea wordt gezien als groepsdynamische processen. Weerstand op organisatieniveau zijn symptomen van culturele aard of symptomen van politieke aard.
Bron: Management Team, 08-10-2010 "Léon de Caluwé in 1345 woorden", Een organisatie van vlees en steen (2009), Mark Mobach, De Contingentietheorie en Advies over Veranderstrategie (2005), Tom de Kort
Laatst aangepast op zondag, 04 november 2018 08:26
Alignment volgens Henderson & Venkatraman
Gepubliceerd in
Management
Het Strategisch Alignment Model (SAM) van Henderson & Venkatraman (1993) is het meest bekende en geaccepteerde conceptuele model dat ingaat op Business & IT-alignment (BIA). Het model onderkent op basis van een tweedeling vier domeinen die in harmonie met elkaar moeten worden ingericht. Allereerst wordt onderscheid gemaakt tussen het business-domein en het IT-domein. Beide domeinen kunnen bekeken worden vanuit een extern (strategisch) perspectief, als vanuit een intern (operationeel) perspectief. Hierdoor onstaan vier kwadranten.
Alignment kan op basis van het model vanuit vier invalshoeken worden belicht: de bedrijfsstrategie, de IT-strategie, de organisatorische inrichting (organisatie-infrastructuur en -processen) en de inrichting van de IT-organisatie (IT-infrastructuur en -processen). Het model maakt inzichtelijk dat alle vier de invalshoeken met elkaar in balans moeten zijn: er moet sprake zijn afstemming en/of aansluiting tussen het strategisch en operationele niveau en tussen het business- en IT-domein.
Binnen het SAM is BIA een vraagstuk waarbij strategische doelstellingen op een juiste wijze moeten worden doorvertaald naar IT-doelstellingen.
Het SAM is de basis voor het zgn. Strategic Alignment Model Enhanced.
Laatst aangepast op vrijdag, 29 december 2017 21:57
Essentially, all models are wrong, but some are useful.
George E.P. Box
Laatst aangepast op dinsdag, 13 september 2011 14:38
Gepubliceerd in
Management
Bij het beoordelen of feedback goed is, kun je gebruik maken van het acroniem GEIN als checklist:
-
G van gedrag: goede feedback gaat over het gedrag en niet over de persoon.
-
E van effect: goede feedback gaat altijd over het effect dat het op jou heeft.
-
I van ik: goede feedback wordt altijd vanuit de ik-persoon gegeven.
-
N van nu: goede feedback wordt altijd zo snel mogelijk gegeven, zoveel mogelijk in het nu.
Bron: De Management Toolbox - Managementvaardigheden praktisch besproken (Buitenhuis & Van Zanten)
Laatst aangepast op maandag, 08 januari 2018 14:46
Requirements volgens Nicole de Swart (1)
Gepubliceerd in
Requirements
De term 'requirements' binnen de context van systeemontwikkeling betekent letterlijk behoefte of eis. In de betekenis van 'behoefte' is een requirement een behoefte aan geautomatiseerde ondersteuning. Bij een requirement als 'eis', gaat het om eisen aan die worden gesteld aan het systeem in termen van gedrag of kwaliteit.
Een veel gebruikte definitie voor requirements (IEEE) is dat requirements staan voor: (a) een conditie of capaciteit die een gebruiker nodig heeft om een probleem op te lossen of een doel te bereiken, (b) eis ten aanzien van wat een systeem(deel) moet 'zijn' of 'doen' om te voldoen aan formele eisen (contract, standaard, ed), of (c) een gedocumenteerde representatie van (a) of (b).
De eerste twee delen van de IEEE-definitie zijn samen te vatten in 'gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte te voorzien van een belanghebbende uit de business.
De Swart definieert een requirement als: (i) een behoefte aan geautomatiseerde ondersteuning: een proces of een verbetering daarin, die een belanghebbende uit de business (deels) met behulp van het systeem wil uitvoeren, en (ii) een eis aan een systeem: gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte te voorzien van een belanghebbende uit de business.
Elke requirement is een eis en geeft een behoefte weer, maar niet elke eis en iedere behoefte zijn een requirement. Een behoefte is alleen een requirements als het gaat om een behoefte van een belanghebbende uit de business om met behulp van het systeem een proces uit te voeren of een procesverbetering te realiseren. Een eis is alleen een requirement als het gaat om een eis die betrekking heeft op het gedrag of de kwaliteit van het systeem om daarmee te voorzien in een behoefte van een belanghebbende uit de business. Een requirement is dus geen synoniem voor eis. Het zijn eisen die gesteld worden aan het gedrag of de kwaliteit van het systeem om in een behoefte van een belanghebbende uit de business te voorzien.
Volgens De Swart vormen requirements als het ware een brug tussen de belanghebbenden uit de business en de softwareontwikkelaars. De requirements geven aan wat het systeem moet kunnen om: de business optimaal te ondersteunen én de ontwikkelaars duidelijk te maken wat ze moeten realiseren.
Wat requirements niet zijn
Technische beperking Een technische beperking (meestal voortkomend uit het ICT-beleid, bijv. beperkingen in ontwikkelplatformen en communicatieprotocollen) is geen requirement maar stelt wel eisen aan de implementatie van een requirement.
Ontwerpbeslissing Een ontwerpbeslissing is een beslissing over de manier waarop een requirement geïmplementeerd wordt, rekening houdend met de technische beperkingen. Volgens De Swart zitten er vaak ontwerpbeslissingen in de specificaties van requirements verborgen omdat mensen meer in oplossingen denken dan in requirements. Het nadeel van 'impliciete ontwerpbeslissingen' is dat ongemerkt andere, misschien wel betere oplossingen worden uitgesloten.
Bedrijfsregel Een bedrijfsregels is een regel die een bepaalt aspect van de business definieert of beperkt. Het is bedoeld om de kenmerken van de business te handhaven of het gedrag van de business te beïnvloeden. Een bedrijfsregel komt onder andere voort uit het bedrijfsbeleid, uit wet- en regelgeving. Een bedrijfsregel is geen requirement maar is in de praktijk vaak de bron van één of meer requirements. Een bedrijfsregel is onafhankelijk van de werking van het systeem en van de inrichting van het proces. Sommige bedrijfsregels kunnen rechtstreeks worden overgenomen als requirement, bijvoorbeeld de afspraak dat klanten een zescijferig klantnummer krijgen ter identificatie. Andere bedrijfsregels kunnen op verschillende manieren worden geïmplementeerd.
Bron: Handboek Requirements (2010), Nicole de Swart
Laatst aangepast op maandag, 21 september 2020 09:01
Gepubliceerd in
Requirements
Requirements engineering gaat over het definiëren, documenteren en onderhouden van requirements gedurende de levenscyclus van de ontwikkeling van een informatiesysteem. Requirements engineering is een iteratief proces. Eerst moeten de business requirements worden ontwikkeld en vastgesteld ('gebaselined'), vervoglens vormen de business requirements input voor het ontwikkelen van requirements op gebruikersniveau. Hierbij kan het nodig zijn de business requirements aan te vullen en/of verder te verfijnen.
Requirements engineering wordt onderverdeeld in: (1) requirements development, en (2) requirements management.
Requirements development omvat alle activiteiten voor het identificeren en vastleggen van requirement en het vervolgens bereiken van overeenstemming over de requirements.
Volgens De Swart is het doel van requirements engineering het tot stand brengen en in stand houden van overeenstemming tussen de opdrachtgever, medewerkers en de softwareontwikkelaars over de requirements. Requirements development richt zich op het tot stand brengen van de overeenstemming.
Requirements development omvat alle activiteiten die problemen, kansen en behoeften omzetten naar een overeengekomen set aan requirements, de zgn. baseline. Anders gezegd gaat het om de activiteiten die nodig zijn om nieuwe requirements aan de baseline toe te voegen. Het begint bij het in kaart brengen van globale requirements, waarna de requirements tot op het gewenst detailniveau worden gespecificeerd. De gedetailleerde requirements in de baseline dienen bij een waterval- of iteratief ontwikkeltraject als basis voor de realisatie van het systeem.
Bij het specificeren van requirements dreigt volgens De Swart altijd verlammingsgevaar (analysis paralysis): de specificaties van requirements zijn nooit perfect, het kan altijd beter, completer en duidelijker. Het risico is dus dat je té lang doorgaat met het perfectioneren van beschreven requirements. Requirements development streeft naar requirementsspecificaties die 'goed genoeg' zijn om met een aanvaardbaar risico te starten met het realiseren van het systeem. Het risico bestaat in dit verband uit de kosten voor en het uitvoeren van herstelwerkzaamheden bij fouten in reeds goedgekeurde specificaties. De kwaliteit van de requirementsspecificaties is hoog genoeg, zodra de kosten voor het nog verder verhogen van de kwaliteit van de requirementsspecificaties niet meer opwegen tegen de verwachte herstelkosten later in het traject.
Volgens De Swart zijn 'de requirements in de baseline namelijk niet in beton gegotenen geldt: "Hoewel de requirements in de baseline zijn goedgekeurd en misschien zelfs al zijn geïmplementeerd, zijn wijzigingen daarin onvermiijdelijk. Dit komt omdat de wereld niet stil staat tijdens de ontwikkeling van het systeem." Als gevolg van wijzigingen in de omgeving en voortschrijdend inzicht, zullen namelijk gedurende de gehele cyclus van softwareontwikkeling wijzigingen plaats (moeten) vinden. Requirements management omvat alle activiteiten die nodig zijn om wijzigingen in de specificaties van de requirements in de baseline door te voeren. Doel hiervan is het gecontroleerd laten plaatsvinden van wijzigingen. De activiteiten met betrekking tot het omgaan met wijzigingen op requirements die 'gebaselined' zijn: het doen van wijzigingsverzoeken, het uitvoeren van impactanalyses en de besluitvorming over en invoering van goedgekeurde wijzigingen.
De Swart onderscheid vier processtappen, met daarbinnen specifieke activiteiten
Requirements development
(1) Positioneren van het systeem binnen het businessdomein
- Analyseren van de business
- Zoeken van belanghebbenden en gesprekspartners
(2) Definiëren van de gewenste oplossing
- Vaststellen behoeften en eisen aan geautomatiseerde ondersteuning
- Selecteren belangrijkste kwaliteitseigenschappen
- Identificeren technische beperkingen
- Afbakenen systeem
(3) Detailleren van de requirements
- Vaststellen van door het systeem uit te voeren activiteiten
- Vaststellen van benodigde kwaliteitsniveau van het systeem
Volgens De Swart zijn bij elk van de drie processtappen binnen requirements development vier subgebieden nodig:
[i] Elicitatie (expliciet maken van requirements) [ii] Analyse (onderzoeken requirements op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid) [iii] Specificatie (vastleggen van requirements, incl. meta-informatie) [iv] Validatie (zekerstellen dat gespecificeerde requirements overeenkomen met behoeften van de business)
Requirements managmeent
(4) Beheren van de requirements
Volgens De Swart rust requirements management op vijf pijlers:
[a] Wijzigingsbeheer [b] Versiebeheer [c] Traceerbaarheid [d] Metagegevens [e] Managementoverzichten (inzicht in stand van de requirements in de baseline)
Bron: Software Requirements Engineering: What, Why, Who, When and How (Linda Westfall), Handboek Requirements (2010), Nicole de Swart
Laatst aangepast op donderdag, 11 januari 2018 19:32
|