Design / Implementation & Change Management

This is an iterative process. Design is implemented in two different parts. One for the complete system and later for every small feature that goes into it. Former is called as laying out the framework. Latter one is part of iterative process. While working on feature based design, at several instances, it starts to affect base framework and hence it also evolves with system. This iterative process requires a strong configuration management system to sustain it over long time and keep everything traceable.

It enables customer to see working prototypes at quick intervals of time and make course corrections w.r.t. understanding gaps or change in marketing needs. Timely course correction with little process overhead enables to create a unique product over time.

On need basis, architecture / design documents are created as separate artifacts Or are availale as part of work tickets. Changes raised are also tracked as tickets and hence any changes made to the design / code are recorded within individual tickets, with traceability to code.

All of the implementation is tested as per test cases derived from requirements and wherever possible for frequently used test cases, test automation is done to save time and efforts over long time. In this, lot of organization inhouse components are reused and belong to DKT IPR.

This implementation is actually broken down into various phases further to help understand responsibility and time it properly

In CLI, it is a developer restricted backend processes to ensure quality output. In SLI, systems and integration start to happen and we start interacting with interface emulators, pilot customers and validate our assumptions of new system vis-a-vis the world around.

After CLI and SLI are done confidently and critical + major issues are ironed out, system goes through RFD which includes acceptance testing and other approvals that may be pre-requisite for GA (General Available) release.