waarom_bres

Verschillen

Dit geeft de verschillen weer tussen de geselecteerde revisie en de huidige revisie van de pagina.

Link naar deze vergelijking

Beide kanten vorige revisie Vorige revisie
Volgende revisie		 Vorige revisie
waarom_bres [2024/06/14 16:40] – [Ontwikkel proces] stefanwaarom_bres [2024/07/01 18:36] (huidige) – [Softwareontwikkeling] stefan
Regel 32: Regel 32:
  
  
-==== Ontwikkelproces ====+==== Workflow ====
 Met BRES worden stapsgewijs en structureel informatieknelpunten opgelost. De (vastgoed)organisatie bepaald hierin zelf wat waardevol en belangrijk is.  Met BRES worden stapsgewijs en structureel informatieknelpunten opgelost. De (vastgoed)organisatie bepaald hierin zelf wat waardevol en belangrijk is. 
  
Regel 62: Regel 62:
 ==== Softwareontwikkeling ==== ==== Softwareontwikkeling ====
  
-Bij alle softwareontwikkeling moet __altijd__ een balans worden gezocht tussen de aspecten:+Bij alle softwareontwikkeling moet, net als in het projectmanagement __altijd__ een balans worden gezocht tussen de aspecten:
   * ''scope/omvang''   * ''scope/omvang''
   * ''tijd''   * ''tijd''
   * ''budget''    * ''budget'' 
   * ''kwaliteit''   * ''kwaliteit''
 +
 +Wordt meer vastgehouden aan één aspect, dan gaat dat **__altijd__** ten koste van de andere aspecten*. 
  
 //*Dit staat binnen projectmanagement ook wel bekend als de **duivelsvierkant**://\\ //*Dit staat binnen projectmanagement ook wel bekend als de **duivelsvierkant**://\\
  
  
-Wordt meer vastgehouden aan één aspect, dan gaat dat **__altijd__** ten koste van de andere aspecten*.  
  
  
 === Agile methode === === Agile methode ===
-Agile-methoden verminderen risico's door software te ontwikkelen in korte overzichtelijke perioden (timeboxes), die 'iteraties' genoemd.+Agile-methoden verminderen risico's door software te ontwikkelen in korte overzichtelijke perioden (timeboxes), die ook wel "iteraties" of "sprints" genoemd worden.
  
 Aspecten:\\ Aspecten:\\
Regel 85: Regel 86:
 {{::duivelsvierkant-agile.png?300|BRES}}   {{::duivelsvierkant-agile.png?300|BRES}}  
  
-Aangezien er niet getorned mag worden aan de **vaste** aspecten zullen tegenvallers ten koste gaan van de ''scope/omvang''. M.a.w. als het project tegen valt wordt er initieel minder gerealiseerd. Veel belangrijker is dat hetgene wat wel wordt gerealiseerd van voldoende kwaliteit is, op tijd is en dat het budget niet overschreden is.  +Aangezien er niet getornd mag/kan worden aan de **vaste** aspecten zullen tegenvallers ten koste gaan van de ''scope/omvang''. Er wordt dan aanvankelijk minder ''scope/omvang'' gerealiseerd. Belangrijker is dat hetgene wat wel wordt gerealiseerd van voldoende kwaliteit is, op tijd is en dat het budget niet overschreden wordt. 
  
-Als men na de initiële implementatie vindt dat er teveel nieuwe wensen blijven liggen kan ervoor gekozen worden het ''budget'' te verhogen. Immers hoe hoger het budget, hoe meer er in ''scope/omvang'' gerealiseerd kan worden!+Door de korte iteraties wordt snel duidelijk welke kant het op gaat en kan er desgewenst op tijd gestopt worden. Anderzijds als men tevreden is maar er teveel wensen blijven liggen kan worden overwogen om het vaste ''budget'' te verhogen. Immers hoe hoger het ''budget'', hoe meer er in ''scope/omvang'' gerealiseerd kan worden!
  
 === Waterfall methode === === Waterfall methode ===
Regel 99: Regel 100:
   * ''kwaliteit''; Men heeft hoge verwachtingen maar de minder concrete kwaliteit is niet goed vast te leggen. **#variabel**   * ''kwaliteit''; Men heeft hoge verwachtingen maar de minder concrete kwaliteit is niet goed vast te leggen. **#variabel**
  
-//N.B. er wordt vaak gesteld dat bij aanbestedingen ook op ''kwaliteit'' wordt beoordeeld maar dat kan niet als de software nog niet tastbaar is//+//N.B. er wordt vaak gesteld dat bij aanbestedingen ook op ''kwaliteit'' wordt beoordeeld maar dat kan __niet__ als de software nog niet tastbaar is//
  
-Aangezien er niet getorned kan worden aan de **vaste** aspecten zullen alle tegenvallers ten koste gaan van de ''kwaliteit''. Door de lange trajecten ontstaat veel voortschrijdend inzicht maar dit ligt buiten de ''scope/omvang'' waardoor weer veel meerwerk ontstaat. Waterfall trajecten blijven vrijwel nooit binnen budget en voldoen zelden aan de verwachtingen.+Aangezien er niet getorned zal worden aan de **vaste** aspecten zullen tegenvallers ten koste gaan van de ''kwaliteit''. Door de langere trajecten ontstaat veel tussentijds(voortschrijdend) inzicht maar dit ligt buiten de ''scope/omvang'' waardoor veel meerwerk ontstaat. Waterfall trajecten blijven vrijwel nooit binnen budget en voldoen zelden aan de verwachtingen. Wat de verkeerde kant op gaat wordt vaak ook nog erg lang gecontinueerd.
  
 === Voordelen Agile ten opzichte van Waterfall === === Voordelen Agile ten opzichte van Waterfall ===
Regel 127: Regel 128:
  
 **Identiteit en toegangsmanagement:** **Identiteit en toegangsmanagement:**
-  * Bedrijf: ''Okta Inc.''+  * Bedrijf: ''Okta Identity Netherlands B.V.''
   * Type: sub-verwerker   * Type: sub-verwerker
   * Gecertificeerd:    * Gecertificeerd: