Ontwikkeling & implementatie
Van specificatie tot integratie: OTOKO® ontwikkelt applicaties en koppelt ze aan uw bestaande systemen en processen.
Ontwikkeling & implementatie
Van specificatie tot integratie: OTOKO® ontwikkelt applicaties en koppelt ze aan uw bestaande systemen en processen.

Meer weten over
Ontwikkeling & implementatie
Lees meer over hoe u onze diensten zinvol in uw technologielandschap kunt integreren.
Onze klanten
Veelgestelde vragen
Wat moeten we weten over ‘Ontwikkeling & implementatie’?
Van specificatie tot integratie: OTOKO® ontwikkelt applicaties en koppelt ze aan uw bestaande systemen en processen.
Hoe ondersteunt OTOKO® ons bij ‘Maatwerksoftware’?
Of het nu gaat om een vakapplicatie, een digitaal product of een intern hulpmiddel: wij ontwikkelen software voor processen die bestaande systemen niet zinvol kunnen ondersteunen.
Welke diensten omvat ‘Maatwerksoftware’?
Eisenanalyse met de vakafdeling, dreigingsmodel en doelarchitectuur volgens het C4-model Domeinmodel, datamodel en interfacecontracten vóór de eerste regel code Ontwikkeling in korte iteraties met codereviews en acceptaties door de vakafdeling Veilige ontwikkeling volgens OWASP ASVS, gecontroleerde afhankelijkheden en ondertekende builds Overdracht met broncode, architectuurdocumentatie en beheerhandboek
Welke resultaten ontvangen we bij ‘Maatwerksoftware’?
Werkende applicatie met broncode en buildpipeline Architectuurdocumentatie met dreigingsmodel Beheerhandboek met runbooks en noodplan
Wat moeten we voorbereiden voor ‘Maatwerksoftware’?
Voorbeelden van de huidige werkprocessen en uitzonderingen Verantwoordelijken voor vakinhoudelijke beslissingen Bestaande systemen, gegevensbronnen en eisen voor het beheer
Hoe kan ‘Maatwerksoftware’ er in de praktijk uitzien?
Een onderhoudsplanning wordt tot nu toe in spreadsheets bijgehouden. Een vakapplicatie bundelt installaties, afspraken, verantwoordelijkheden en goedkeuringen. De eerste fase omvat één locatie; andere locaties volgen pas na vakinhoudelijke toetsing van het proces.
Welke technische aspecten zijn belangrijk bij ‘Maatwerksoftware’?
.NET C# Go Rust TypeScript PostgreSQL
Wat is belangrijk bij ‘Vaklogica boven functieomvang’?
We beginnen bij het werkproces waarvoor de investering zich moet terugverdienen. Wij modelleren begrippen, statussen en bedrijfsregels samen met de mensen die er later mee werken. Een goedkeuring is bijvoorbeeld niet alleen een knop: vervanging bij afwezigheid, autorisaties, termijnen en het terugdraaien van een beslissing moeten op elkaar aansluiten. Deze regels worden onderdeel van het datamodel en de tests. De eerste versie richt zich op één volledig bruikbaar proces. Verdere functies voegen we toe op basis van feedback uit de praktijk. Zo ontstaat een product met controleerbaar nut, en geen grote verzameling onafgemaakte schermen.
Wat moeten we weten over ‘Technologie passend bij de levensduur’?
Voor backend, gebruikersinterface en gegevensopslag kiezen wij technologieën op basis van uw bestaande landschap en de verwachte verdere ontwikkeling. Bestaande competenties, interfaces en eisen voor het beheer wegen daarbij zwaarder dan een kortstondige technologietrend. Het beschikbare aanbod omvat onder andere .NET, Go en TypeScript; systeemnabije componenten worden apart beoordeeld. Wij definiëren modulegrenzen en verantwoordelijkheden zodanig dat wijzigingen navolgbaar blijven. Toegangsgegevens horen niet in de broncode, bedrijfsregels niet uitsluitend in de gebruikersinterface. Reviews, geautomatiseerde controles en geversioneerde databasewijzigingen begeleiden de uitvoering vanaf het begin.
Hoe ondersteunt OTOKO® ons bij ‘Acceptatie betekent: het werkt in de dagelijkse praktijk’?
Elke iteratie toont bruikbare functies met bekende beperkingen. Vakinhoudelijke acceptatie en technische vrijgave worden apart bekeken: een correct berekende bestelling kan inhoudelijk kloppen, terwijl belastinggedrag of foutafhandeling nog niet productierijp zijn. Samen leggen we vast welke bewijzen nodig zijn voor de betreffende uitbreidingsstap. Tot de afgesproken leveringsomvang behoren broncode, reproduceerbare builds en documentatie. Voor de livegang regelen we gegevensmigratie, training, verantwoordelijkheden en de omgang met storingen. Gebruiksrechten, externe componenten en later onderhoud regelen we vóór de overdracht.
Wat is belangrijk bij ‘Bedrijfsregels, transacties en gelijktijdige wijzigingen’?
Een applicatie moet ook correct werken als meerdere mensen tegelijk dezelfde voorraad wijzigen. Twee reserveringen mogen niet ongemerkt hetzelfde laatste artikel toewijzen. Wij bepalen daarom welke wijzigingen gezamenlijk moeten slagen en welke conflicten een vakinhoudelijke terugkoppeling nodig hebben. Databaseconstraints, transacties en versiecontroles kunnen verschillende delen van deze taak oplossen; de gebruikersinterface alleen kan deze regels niet waarborgen. Langere bedrijfsprocessen passen daarentegen vaak niet in één enkele transactie. Een bestelling, een externe betaaldienst en een verzendgoedkeuring hebben elk hun eigen foutstatussen. Wij modelleren het proces met heldere statussen en toegestane overgangen. Herhaalde verzoeken krijgen een idempotency key, zodat een verbindingsonderbreking niet automatisch een dubbele actie veroorzaakt. Bij deelfouten is een vakinhoudelijk gedefinieerde correctie nodig, bijvoorbeeld het intrekken van een goedkeuring, in plaats van een generieke technische herstart.
Wat moeten we weten over ‘Tenants, rollen en controleerbare datatoegang’?
Voor SaaS-producten en interne platformen onderscheiden wij de identiteit van een gebruiker van zijn rechten op een specifiek record. Een aangemelde medewerker mag niet automatisch elke factuur of elke order lezen. Wij controleren toegang in de backend op het niveau van organisatie, rol en zaak. Ook exports, zoekindexen, achtergrondtaken en gecachete resultaten moeten deze grenzen respecteren. Gedeelde tabellen met een tenantkenmerk, gescheiden databaseschema's of eigen databases brengen verschillende eisen met zich mee voor isolatie, migratie en herstel. Wij kiezen het model op basis van de benodigde scheiding en uw beheerorganisatie. Tests met meerdere tenants controleren met name ontoelaatbare toegang. Een auditlog documenteert vakinhoudelijk relevante wijzigingen met passende context; welke gegevens daarin staan en hoe lang ze beschikbaar blijven, wordt uitdrukkelijk vastgelegd.
Hoe ondersteunt OTOKO® ons bij ‘Gegevensopslag, performance en uitbreidbaarheid op lange termijn’?
De datastructuur volgt de queries en bedrijfsregels. Wij onderzoeken typische filters, sorteringen, analyses en schrijfacties voordat aanvullende opslagtechnologieën worden ingevoerd. Onbegrensde resultatenlijsten, herhaalde losse queries en grote gegevensoverdrachten kunnen een applicatie vertragen, ook al lijkt de server nauwelijks belast. Metingen met realistische datavolumes tonen of indexen, querywijzigingen, paginering of een andere taakverdeling helpen. Caching is een bewuste beslissing over actualiteit: het moet vaststaan wanneer een opgeslagen resultaat ongeldig wordt en welke gebruikers het mogen zien. Omvangrijke berekeningen kunnen als achtergrondtaken lopen, maar hebben dan een voortgangsindicator, herstart en foutstatussen nodig. Voor uitbreidingen scheiden wij bedrijfsregels van technische adapters. Geautomatiseerde tests en geversioneerde databasewijzigingen bewaken deze grenzen, zodat een nieuw kanaal of een andere aanbieder niet elke module hoeft te wijzigen.
Wat is belangrijk bij ‘Assessment’?
Applicatielandschap, eisen, risico's Vakafdeling, IT, informatiebeveiliging, softwarearchitect van OTOKO® Beoordeelde projecten, inventarisatie, beveiligings- en beheereisen
Wat moeten we weten over ‘Concept’?
Architectuur, technologie, beheermodel Vakafdeling, architectuur, gegevensbescherming, informatiebeveiliging Doelarchitectuur, dreigingsmodel, teststrategie, beheermodel, mijlpalen

