• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
www.eenblogjeom.nl
Verschillen ASL1 vs. ASL2: onderhoud en vernieuwing
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

 ASL processen onderhoud en vernieuwing ASL1 vs. ASL2

 

ASL1 ASL2 Verschil

Impactanalyse

Ontwerp

 

De term ‘specificatie’ is gereserveerd voor alleen BIM (functioneel beheer). Specificaties vormen input voor de processen.
Het resultaat van ontwerpen is een ontwerp.

Realisatie Realisatie

 -

Testen Testen

 -

Implementatie Implementatie

Thema 'inbeheername' is toegevoegd. Aanpassingen om 'in lijn' te blijven met BiSL.

Laatst aangepast op zondag, 10 april 2011 19:08  
Verschillen ASL1 vs. ASL2: beheerprocessen
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

beheerprocessen ASL1 ALS2 verschillen (ASL)

 

 ASL1  ASL2 Verschil
 Incidentbeheer  Gebruiksondersteuning  

? Naam om nadruk te leggen op het proactieve karakter van het proces; er worden niet alleen reactief incidenten afgehandeld, maar ook proactief gecommuniceerd. In de praktijk wordt het woord incident vaak als synoniem gebruikt voor verstoringen

 Continuïteitsbeheer  Continuïteitsbeheer Nieuw: expliciet aandacht besteden aan ‘beveiliging’. Continuïteitsbeheer is niet samengevoegd omdat dit proces toch meer een tactische inslag heeft dan Beschikbaarheids­beheer en Capaciteitsbeheer.
 Beschikbaarheidsbeheer Operationele ICT-sturing

Beschikbaarheidsbeheer en capaciteitsbeheer zijn samen­ge­voegd.

Argumenten voor samenvoeging

(1)  Raakvlak tussen beide processen (gebrek aan computer­ca­paciteit kan bij een (gebrekkige) opzet leiden tot be­schik­baarheidsproblemen: “als de capaciteit niet genoeg is, heb je ook problemen met de beschikbaarheid”.

(2) Besturingsproblematiek: wijze van sturen en de para­me­ters waarop wordt gestuurd en gerapporteerd, is vergelijk­baar (efficiencyverbetering door samenvoeging). Voor een afne­mer is het onderscheid tussen de parameters voor be­schik­baarheid/betrouwbaarheid en capaciteit niet zo relevant.

 Capaciteitsbeheer
 Configuratiebeheer

Configuratiebeheer

Naamgevingsconventies zijn achterhaald. Doelstelling is eenduidiger: registreren welke versies waar draaien.

Laatst aangepast op donderdag, 17 februari 2011 21:56  
Iteratief ontwikkelen met RUP (fasering, disciplines en iteraties)
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

Rup, fasering, iteraties en disciplines

Vier fasen

Een RUP-traject bestaat uit vier fasen:

  1. Inception: overeenstemming over scope, oplossing(srichting), eisen en wensen, belangrijkste risico's + tegenmaatregelen
  2. Elaboration: gedetailleerd beeld kritische requirements, stabiele architectuur in werkende code, kosten/planning + scope inzichtelijk

  3. Construction: functionaliteit gerealiseerd, product gereed voor Beta-testing, handleidingen/trainingsmateriaal gereed

  4. Transition: gerapporteerde bugs gefixed, gebruikers/beheerders getraind, voldaan aan acceptatiecriteria, evaluatie gehouden.

 

Negen disicipines

Er zijn negen disciplines die gedurende de duur van een project zullen voorkomen.

  1. Business modelling
  2. Requirement Engineering

  3. Analyse en ontwerp

  4. Implementatie

  5. Testen

  6. Deployment ('Put-into-Production')

  7. Project management

  8. Omgeving

  9. Configurate- en wijzigingenbeheer

De intensiteit waarmee een bepaalde discipline wordt uitgevoerd is vooral afhankelijk van de fase waarin het project zich bevindt. De 9 disciplines zijn verdeeld over twee hoofdgroepen: Ontwikkeling en Ondersteuning. De eerste zes discplines vallen onder Ontwikkeling. De laatste drie disciplines vallen onder Ondersteuning.

Iteraties

Een iteratie is een afgebakend, korte periode waarin een samenhangend hoeveelheid functionaliteit wordt ontworpen, gerealiseerd of geaccepteerd. Binnen RUP wordt in opeenvolgende iteraties van ontwerp (Use Case-ontwerp, Testontwerp en technisch ontwerp), realisatie (bouw en test), acceptatie (door de opdrachtgever) toegewerkt naar een steeds completer eindproduct. Een iteratie is een timebox, wat wil zeggen dat de tijdsduur vooraf vastligt. Het succes hangt volgens Dekker en Collaris af van de inrichting van het iteratieve proces.

Bron: RUP op Maat (2008), Eef Dekker en Remi-Armand Collaris

 

 

Laatst aangepast op maandag, 08 januari 2018 14:46  
FOETSIE-model
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

foetsie model

'FOETSIE' is een acroniem, waarbij elke letter staat voor een criterium waaraan een alternatief, optie of scenario aan kan worden getoetst. Kracht van het model is dat een veelheid van factoren kan worden teruggebracht tot de essentie. Het gaat om de volgende zeven toetsingscriteria:

  1. Financieel (solvabiliteitcriteria, liquiditeitdoelstellingen)

  2. Organisatorisch (kwalitatieve en kwantitatieve impact op personeelsbezetting)

  3. Economisch (rendementeisen)

  4. Tactisch (uitvoerbaarheid)

  5. Strategisch (concurrentievoordelen op langere termijn)

  6. Juridisch (voldoen aan wet- en regelgeving)

  7. Ethisch, ecologisch, esthetisch (verwachtingen van betrokkenen)

Bron: Models, Businessmodellen met body (2006), Marischka Setz & Tom W. den Hoed

Laatst aangepast op vrijdag, 29 december 2017 22:12  
Prioriteringstechnieken
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

Prioritering

Binnen de context van requirements engineering onderscheidt De Swart vijf prioriteteringstechnieken:

(1) Hoog, middel, laag

Het maken van een onderverdeling in groepen: hoog, middel en laag is een van de eenvoudigste manieren van prioriteren. Zodra belanghebbenden aan bijna alles de hoogste prioriteit toekennen, is het nodig extra regels te introduceren, bijv. dat alledrie de prioriteiten evenveel keren moeten worden toegekend.

(2) MoSCoW-methode

Prioriteringstechniek die haar wortels heeft in de agile systeemontwikkelmethodiek DSDM, maar generiek toepasbaar is. MoSCoW is hierbij een acroniem voor vier categorieën: (a) Must have (onmisbaar), (b) Should have (niet onmisbaar, maar vaak wel 'workaround' nodig), (c) Could have (duidelijk toegevoegde waarde, maar ook bruikbaar zonder), (d) Won't have this time (niet in komende 'release').

(3) Relatieve prioritering

Bij het vaststellen van de relatieve prioriteit geven belanghebbenden paarsgewijs aan welk van de twee het belangrijkst is. Hierdoor ontstaat een rangorde van prioriteiten. Voor relatieve prioritering is één beslissingsbevoegde belanghebbende of een democratisch proces nodig. Met een groep belanghebbenden consensus bereiken over een geprioriteerde lijst (requirements) is vrijwel ondoenlijk en kost onevenredig veel tijd.

(4) Tevredenheid/ontevredenheid-ratio

De tevredenheid/ontevredenheid-ratio is een maat voor de meerwaarde die belanghebbenden ergens aan hechten. Nadruk ligt dus op toegevoegde waarde. De ontevredenheidsratio geeft aan hoe ontevreden de belanghebbende is als ergens niet aan voldaan wordt (bijv. als het systeem niet aan een requirement voldoet). De tevredenheidsratio geeft aan hoe tevreden een belanghebbende is als juist wél ergens aan wordt voldaan (systeem voldoet aan requirement).  De ratio's hebben een schaal van 1 tot 5. Een hoge score op beide ratio's wijst erop dat het gaat om iets dat veel waarde heeft. Grote verschillen tussen de ratio's zijn reden voor nader onderzoek.

(5) Urgentie vs. belangrijkheid

Een binnen time management veel toegepaste prioritering is door het uitzetten van urgentie (urgent, niet-urgent) tegen de mate van belangrijkheid (belangrijk, minder belangrijk). Hierdoor ontstaat een matrix met vier kwadranten.

Bron: Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op dinsdag, 02 januari 2018 08:26  


JPAGE_CURRENT_OF_TOTAL

The entrepreneur always searches for change, responds to it, and exploits it as an opportunity.

Peter Drucker

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 112 gasten online
Artikelen

problem solving problemen oplossen william edwards deming

Banner
Banner

how explain andy tharby

How to Explain Absolutely Anything to Absolutely Anyone
The art and science of teacher explanation
Andy Tharby

Bij Bol.com

Lean boekentips

Banner