Verschillen

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

--- waarom_bres [2024/06/14 16:34] – [Aanleiding] stefan
+++ waarom_bres [2024/07/01 18:36] (huidige) – [Softwareontwikkeling] stefan
@@ Regel 20: / Regel 20: @@
     * Wereldstekker: Vele bronsystemen en webservices worden uitgelezen. De klant zorgt voor autorisaties, BRES doet de rest.
     * Verrijken: Relevante externe en open data genormaliseerd en gekoppeld.
-    * Visueel: Datastructuur blijft behouden en kan gemakkelijk geografisch en structureel inzichtelijk worden gemaakt.
+    * Visueel: Datastructuur blijft behouden en kan gemakkelijk geografisch en structureel inzichtelijk worden gemaakt via de interface.
   * __Management en rapportage__:
     * Sturen: Prestatie indicatoren worden op verzoek geautomatiseerd berekend (computing).
@@ 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.
 Zowel tijdens de pilot fase als de operationele fase wordt volgens de Agile [[https://nl.wikipedia.org/wiki/Continuous_delivery|Continuous Delivery]] methodiek ontwikkeld. De applicatie en de klant configuraties worden daarbij nooit als "af" beschouwd maar zullen continu worden door ontwikkeld en aan nieuwe eisen en wensen aangepast volgens de Continious Delivery.
-Er wordt per klant gebruikt gemaakt van een virtueel [[https://nl.wikipedia.org/wiki/Kanban|Kanban]] (een Agile methode) waarop elke individuele gebruiker gewenste wijzigingen kan plaatsen en de voortgang van alle processen kan zien. Ongeveer 1 keer per maand worden de nieuwe items op de Kanban met een groep gebruikers gezamenlijk besproken en vindt er een prioritering plaats (de "triage"). Vooraf aan de triage worden de lopende zaken kort besproken. Deze bijeenkomsten dienen tevens om onderling begrip te vergroten en een goede samenwerking te bevorderen. Elke twee weken wordt een aantal items (afhankelijk van de toegewezen prioriteit) uitgekozen om in die "sprint" te worden geïmplementeerd. Generieke en routinematige items zoals het toevoegen/wijzigen van data sets, KPI's, interne berekening of WMS/WFS/ArcGIS REST kaart lagen zijn hierbij altijd kosteloos.
+Er wordt per klant gebruikt gemaakt van een virtueel [[https://nl.wikipedia.org/wiki/Kanban|Kanban]] (een Agile methode) waarop elke individuele gebruiker gewenste wijzigingen kan plaatsen en de voortgang van alle processen kan zien. Ongeveer 1 keer per maand worden de nieuwe items op de Kanban met een groep gebruikers gezamenlijk besproken en vindt er een prioritering plaats (de "triage"). Vooraf aan de triage worden de lopende zaken kort besproken. Deze bijeenkomsten dienen tevens om onderling begrip te vergroten en een goede samenwerking te bevorderen. Elke twee weken wordt een aantal items (afhankelijk van de toegewezen prioriteit) uitgekozen om in die "sprint" te worden geïmplementeerd. Generieke en routinematige items zoals het toevoegen/wijzigen van data sets, KPI's, interne berekening of WMS/WFS/ArcGIS REST kaart lagen zijn hierbij altijd __kosteloos__.
 //Het onderhanden werk wordt continu gevisualiseerd in een Kanban://\\
@@ 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: