Afbeelding voor Veilig software ontwikkelen met OTAP

Veilig software ontwikkelen met OTAP

Tijdens het ontwikkelen van software gaat er weleens iets mis. Soms door een persoonlijke fout, maar ook door een ongelukkige samenloop van omstandigheden. OTAP verkleint de kans op negatieve gevolgen. Maar hoe?

Wat is OTAP?

OTAP is een ontwikkelmethodiek voor het veilig ontwikkelen van software. De vier letters staan voor: Ontwikkeling, test, acceptatie en productie. Samen vormen ze een ‘straat’ met opeenvolgende fases. OTAP wordt daarom ook wel de ontwikkelstraat genoemd.

de ontwikkelstraat van OTAP: ontwikkelen, testen, acceptatie en productie

Het doel van OTAP is om nieuw ontwikkelde software goed te testen, voordat je deze publiceert en beschikbaar maakt voor het publiek. Je kunt het vergelijken met het uitgeven van een krant.

  1. Een redacteur schrijft een tekst (ontwikkelen).
  2. Een hoofdredacteur controleert eerst het concept van een tekst en stuurt deze bij waar nodig (testen).
  3. Wanneer dit naar wens is, wordt de tekst klaargezet in de lay-out van de krant (acceptatie).
  4. Als dit past en klopt, wordt de krant naar de drukker gestuurd (productie).

Ga je direct van schrijven naar de drukkerij (stap 1 en 4), dan loop je een groter risico op fouten in de tekst of een onsamenhangende krant. Zelfs met de beste schrijvers gaat dit mis. Door te testen, bouw je veiligheid in en verbeter je het proces. Dat geldt ook voor ontwikkeling.

Waarom OTAP?

De vraag ‘is het al af’ komt vaker voor op de werkvloer dan menig developer wenst. Een website of applicatie is namelijk nooit af. Er zijn altijd inzichten of wensen om je product beter of veiliger te maken. Daar gaan ontwikkelaars graag mee aan de slag, maar er is altijd de kans op een fout. Dat hoort er bij. Ontwikkelen is puzzelen en fouten leiden naar de oplossing. Je leert van je fouten. Wie is er niet groot mee geworden?

Een live website is echter niet de plek om fouten te maken. Stel je voor dat je in een webshop op het punt staat om af te rekenen en je krijgt te maken met een ontwikkelfout. De winkel verdwijnt, het scherm is wit en je winkelmandje leeg. Dit is dodelijk voor de betrouwbaarheid en reputatie van een website, laat staan de stress die ontstaat bij de winkeleigenaar én ontwikkelaar om dit zo snel mogelijk op te lossen. Elke seconde kost bezoekers en dus geld.

Deze situaties komen helaas nog vaak voor in de digitale wereld. Het eerstvolgende gesprek met de eigenaar of aangewezen projectmanager is er niet een om naar uit te kijken kan ik je vertellen. Dit alles vraagt om een veilige speeltuin waar fouten maken wordt toegejuicht. Een plek onzichtbaar voor de buitenwereld waar een ontwikkelaar zonder stress kan werken. Daar komt OTAP om de hoek kijken. Tijd om de ontwikkelstraat te doorlopen!

De vier fases van OTAP

Fase 1: Ontwikkelen

Ontwikkeling vindt plaats op de computer van een developer. Deze fase richt zich op het realiseren van de functionaliteit. De ontwikkelaar heeft meestal een lokale kopie van de software en bewerkt deze met een eigen set aan programma’s en tools.

Nieuwe functionaliteiten of updates worden vervolgens klaargezet voor de volgende fase: Testen. Bij uitzondering worden wijzigingen direct doorgezet naar productie (het live product). Bij een simpele wijziging ligt soms de voorkeur bij een snelle afwikkeling. Testen kost tijd en met voldoende ervaring weet men waar de risico’s wel en niet liggen. Ook bij urgente veiligheidskwesties spelen er andere belangen, waarbij snelheid wordt gekozen boven het proces. Over het algemeen volgt na ontwikkeling echter de testfase.

Fase 2: Testen

In de testfase wordt nieuwe functionaliteit getest op fouten. Vaak is dit op een testomgeving: een afgeschermde kopie van het live product en een veilige plek waar fouten geen gevolgen hebben voor de eindgebruiker. Op deze omgeving testen andere ontwikkelaars en projectmanagers de nieuwe functionaliteit. Het is daarbij verstandig om niet alleen naar het nieuwe gedeelte te kijken. Het kan namelijk ook zijn dat de vernieuwingen iets hebben kapotgemaakt de bestaande functionaliteit. Dat zijn de fouten die je makkelijk over het hoofd ziet.

Worden er fouten geconstateerd? Dan gaat de functionaliteit terug naar de ontwikkelfase. Is de test een succes? Dan wordt de functionaliteit doorgezet naar de acceptatieomgeving of direct naar de productieomgeving.

Fase 3: Acceptatie

De acceptatiefase beantwoordt de vraag of de functionaliteit het beoogde doel bereikt. De acceptatieomgeving is, net als de testomgeving, een afgeschermde plek om functionaliteit te testen. Hier controleert de klant (of product owner) of de functionaliteit aansluit bij de wensen. Het kan namelijk zo zijn dat de functionaliteit ‘foutloos’ is, maar dat deze niet het beoogde doel bereikt. Daaraan kunnen verschillende reden ten grondslag liggen:

  • De functionaliteit sluit niet aan bij de verwachtingen;
  • Er is iets over het hoofd gezien;
  • De gebruikerservaring of kwaliteit valt tegen;
  • Er blijken interpretatieverschillen te zijn tussen de ontwikkelaar en de opdrachtgever.

Dat kan een reden zijn om opnieuw naar de tekentafel te gaan, waarna de ontwikkelstraat weer opnieuw begint.

Een acceptatiefase is niet altijd relevant. Bij Linku hebben we voor de meeste projecten een lokale omgeving (ontwikkelen), een testomgeving en een productieomgeving (het live product). De acceptatiefase vindt plaats op de testomgeving. Hier testen we dus zowel op fouten als werking, indien nodig samen met de opdrachtgever.

Een acceptatieomgeving is vooral relevant bij het ontwikkelen van unieke, innovatieve of ingrijpende functionaliteit. De kans is dan groter dat wat vooraf bedacht is uiteindelijk niet het gewenste doel bereikt, of anders werkt dan verwacht.

Voor de webapplicatie van Visser Contactlenzen gebruiken we bijvoorbeeld wel een acceptatieomgeving. Deze bedrijfskritische tool vraagt om extra aandacht in het ontwikkelproces, aangezien fouten direct invloed hebben op de productiviteit van werknemers.

Een bedrijfskritische applicatie ontwikkelen

Bekijk de case van Visser Contactlenzen
de webapplicatie van visser contactlenzen, van papier naar digitaal
Next lineVan papier naar digitaal met een webapplicatie voor Visser Contactlenzen

Fase 4: Productie

Wanneer functionaliteit klaar is voor gebruik, wordt deze doorgezet naar de productieomgeving. Dit is het live product dat beschikbaar is voor de gebruikers, bijvoorbeeld een website die je bezoekt of een bedrijfsapplicatie die je gebruikt. In de productieomgeving is geen plek voor fouten of gebrekkige functionaliteit, want anders krijgen echte gebruikers daarmee te maken. Hoe beter de test- en acceptatiefase, hoe kleiner de kans op fouten in de nieuwe versie van het product.

Succes maak je samen

Alleen het implementeren van een ontwikkelstraat is geen garantie voor succes. Fouten vinden zich niet vanzelf. Je moet actief testen en problemen zitten niet altijd aan de oppervlakte. In de praktijk waren fouten in de productieomgeving vaak al aanwezig in de testomgeving. Pijnlijk. Dit is een gevolg van een gebrekkig testproces, onduidelijke verwachten, gemakzucht of soms gewoon pech. Dat vraagt om meer aandacht en duidelijke afspraken tussen de samenwerkende partijen.

Wil je het testproces verder professionaliseren in je organisatie, dan zijn er mogelijkheden om deze te automatiseren. Dit is een belangrijk onderdeel binnen CI/CD, een alternatief voor de ontwikkelstraat. Maar dat is een onderwerp voor een andere keer!

Daarom kiezen wij voor OTAP

OTAP is een essentiële veiligheidsmarge tussen ontwikkeling en gebruik. Het geeft je de kans om betere producten te ontwikkelen, met name bij producten met meerdere stakeholders. Fouten maken is onderdeel van ontwikkelen, maar daar wil je eindgebruikers niet mee opzadelen.

Met het doorlopen van de ontwikkelstraat investeer je in betrouwbaarheid. Dit geeft alle stakeholders van een project de nodige ademruimte. Dat maakt OTAP goed voor de gebruiker, de opdrachtgever én de ontwikkelaar.

Afbeelding voor Timo

Meer weten? We gaan graag in gesprek!

Nieuwsbrief sfeerbeeld