Verschillen

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

--- waarom_bres [2024/06/14 16:36] – [Ontwikkel proces] stefan
+++ waarom_bres [2024/07/01 18:36] (huidige) – [Softwareontwikkeling] stefan
@@ Regel 32: / Regel 32: @@
-==== Ontwikkel proces ====
+==== Workflow ====
 Met BRES worden stapsgewijs en structureel informatieknelpunten opgelost. De (vastgoed)organisatie bepaald hierin zelf wat waardevol en belangrijk is.
@@ Regel 44: / Regel 44: @@
 ==== BRES abonnement ====
-Het BRES abonnement geeft toegang tot de laatste versie van BRES met een onbeperkt aantal gebruikers (licenties).
+Het BRES abonnement geeft toegang tot de laatste versie van BRES met een __onbeperkt__ aantal gebruikers (licenties).
 Generieke verbeteringen komen altijd beschikbaar voor __alle__ klanten (los te kopen modulen bestaan **niet**).
@@ Regel 62: / Regel 62: @@
 ==== 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''
   * ''tijd''
   * ''budget''
   * ''kwaliteit''
-//*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*.
-=== Waterfall methode ===
+//*Dit staat binnen projectmanagement ook wel bekend als de **duivelsvierkant**://\\
-De watervalmethode is een methode voor softwareontwikkeling waarin de ontwikkeling regelmatig vloeiend naar beneden loopt (als een waterval)
-Aspecten:\\
-  * ''scope/omvang''; Er wordt __gespecificeerd__ waar alles aan moet voldoen in een programma van eisen (PvE). **#vast**
-  * ''tijd''; Er wordt een planning opgenomen waarin staat dat het over X jaar __af__ moet zijn. **#vast**
-  * ''budget''; Er volgt een aanbesteding en de leverancier met de __laagste prijs__ wordt gekozen en moet zich daar aan houden. **#vast**
-  * ''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//
-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.
 === 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:\\
@@ Regel 99: / Regel 86: @@
 {{::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.
+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 ===
+De watervalmethode is een methode voor softwareontwikkeling waarin de ontwikkeling regelmatig vloeiend naar beneden loopt (als een waterval)
+Aspecten:\\
+  * ''scope/omvang''; Er wordt __gespecificeerd__ waar alles aan moet voldoen in een programma van eisen (PvE). **#vast**
+  * ''tijd''; Er wordt een planning opgenomen waarin staat dat het over X jaar __af__ moet zijn. **#vast**
+  * ''budget''; Er volgt een aanbesteding en de leverancier met de __laagste prijs__ wordt gekozen en moet zich daar aan houden. **#vast**
+  * ''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//
-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!
+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__ van Agile ten opzichte van Waterfall:
+  * Ruimte voor doorontwikkeling en voortschrijdend inzicht
-  * Ruimte voor doorontwikkeling en voortschrijdend inzicht.
   * Snel en tastbaar resultaat
-  * Altijd van voldoende kwaliteit maar nooit helemaal af.
+  * Altijd van voldoende kwaliteit maar nooit helemaal af
-  * Geen risico dat het project over budget gaat.
+  * Geen risico dat het project over budget gaat
-  * Minder bureaucratie.
+  * Minder bureaucratie
@@ Regel 127: / Regel 128: @@
 **Identiteit en toegangsmanagement:**
-  * Bedrijf: ''Okta Inc.''
+  * Bedrijf: ''Okta Identity Netherlands B.V.''
   * Type: sub-verwerker
   * Gecertificeerd: