De OTAP-ontwikkelstraat: vier fases

De afkorting OTAP staat voor ontwikkeling, test, acceptatie en productie. Het is een methode voor het ontwikkelen van software. In een ontwikkelomgeving, de OTAP-ontwikkelstraat, doorloopt een ontwikkelteam vier fases. OTAP kan ook wel gezien worden als een werkwijze die zorgt dat er op efficiënte en beheersbare wijze nieuwe releases en patches geïmplementeerd worden.

Wij leggen hieronder de vier verschillende fases van de OTAP-Omgeving uit, deze zijn als volgt:

Fase 1: Ontwikkelen

De applicatie of een onderdeel daarvan, wordt eerst ontwikkeld in een speciale ontwikkelomgeving. Hier bevinden zich veelal één of meerdere personen in een ontwikkelteam die werken aan één gezamenlijke versie. Aan het einde van elke dag wordt deze versie gekopieerd in het ‘versiebeheerprogramma’ op de ontwikkelserver.

Fase 2: Testen

De gezamenlijke applicatieversie wordt ‘s nachts automatisch van programmacode naar een functionerende applicatie omgezet en eventueel doorgezet naar een testserver. Op de testserver kan zowel technisch als functioneel getest worden. De resultaten liggen de volgende dag klaar liggen voor het ontwikkelteam. Wanneer er een release wordt voortgezet, kan deze release volledig worden doorgetest door alle betrokken partijen. Een specialist op het gebied van OTAP-hosting kan de invloed van de hardware in de ontwikkelomgeving op tests in kaart brengen.

Fase 3: Acceptatie

Na goedkeuring kan de applicatie worden geïnstalleerd op de acceptatieomgeving. Dit wordt zorgvuldig gedocumenteerd in een draaiboek. De acceptatieomgeving is, qua hard- en software, zoveel mogelijk gelijk aan de productieomgeving. In deze fases kunnen functionaliteiten en performance bekeken worden door de betrokken partijen, zonder dat de dagelijkse productie hierin onderbroken wordt.

Fase 4: Productie

Nadat de applicatie is geaccepteerd, wordt de applicatie geïmplementeerd binnen de productieomgeving. Dezelfde procedure wordt gevolgd als tijdens het overzetten van de testomgeving naar de acceptatieomgeving. Een plan om terug te draaien is voorbereid, zodat het ontwikkelteam bij onvoorziene omstandigheden de productie-installatie ongedaan kan maken en de oude versie terug kan zetten.

In de productieomgeving is de impact van downtime groot. Om te bepalen hoe belangrijk het is deze impact te verkleinen, bieden de begrippen Recovery Time Objective (RTO) en Recovery Point Objective (RPO) uitkomst.

ACC ICT heeft in haar datacenteronafhankelijke infrastructuur veel maatregelen genomen om de beschikbaarheid van productieomgevingen op 99,999 procent te bepalen.

Paul Bijleveld
Paul Bijleveld is Managing Director en Senior Partner bij ACC ICT. Hij nam het bedrijf in 1998 over van zijn vader en houdt zich sindsdien binnen ACC ICT bezig met het uitzetten van de strategie, ontwikkeling van de organisatie en business development. Paul schrijft graag over complexe IT-vraagstukken die herkenbaar zijn voor veel organisaties.

Meer kennis opdoen?

Bekijk onze whitepapers
Ga naar whitepapers

Search