Development
Developing applications can be done two different ways. The first one is the famous black box development. As a client you define the contents of this box and the developer does the rest. The next stage is to implement it and done. This is not the way we want to work. For us, a development project is more than just the definition of the scope (analysis) and the development. We like to include the IT department, the decision takers and last but certainly not least the end-user in the entire project. Involving all these people is the key to a state of the art end product. The input of all these persons allows us to have a perfect view on what is possible technically, functionally and budget wise. Most of our projects are either client/server or web based applications. For more information on the programs and tools we use to achieve the best possible development please click here.

Structuring a development
The most important part of a project is the analysis phase. It is vital to set up a correct ‘data model’ in which the processes and the business requirements of the company (for that project) are reflected. Having a correct and detailed data model will facilitate future program extensions and the inclusion of other sources to the program and the database if needed. The result of the analysis will state the scope of the development, the technical and functional requirements, the first draft of the database architecture, the grouping and details of the business processes and the listing and reporting details. All this will be possible by having interviews and meetings with the people we mentioned before.

After the analysis of the processes, technical and functional requirements, we will decide together with our client what is the best solution for long-term use. This solution will also be based on the technical options and environment of your company. So it is perfectly possible that two very similar projects for two different clients have a different solution implemented.

Once everything has been decided the development can start. Depending on the complexity of the development and the environment that has been chosen, this can be achieved at your premises or at ours (with remote connections).

For a more complex development we always work in different stages. This allows the client to have a perfect follow-up of the project and intervene if he thinks that something needs to be changed (this can happen, even if the analysis was thorough). Another reason is that the debugging process can be distributed. Tests are carried out at each stage and changes made if necessary. It’s easier and more effective to test smaller parts, than the entire complex application. Of course at the end of the development a full debugging of the entire system is performed. This debugging happens most of the time in a QA environment that is set up very closely to the production environment. So if a program runs correctly in QA, it should run correctly in production. Nevertheless a final debugging is always done in the live environment too.

Prior to going live, existing data from external sources (if any) will be converted and uploaded in the new database architecture. Backup, restore and mirroring systems will be correctly installed, configured and tested. Before using the application, users will receive training and functional documentation. After the go live, our team will be available on site to assist in case of any issues.

At the end of the development and after the go live the development of the reports will take place. These reports and listings have already been defined during the analysis stage. But our experience has shown that while using the application, new reports and lists frequently need to be created or existing reports updated. All this, and other minor modifications can be done during the weeks after the go live. Of course the go live itself can be spread over several weeks. As we said before, more complex development will be split into several stages.

Documentation
During development a lot of remarks are inserted in the coding. This allows us and/or internal people to have a better understanding of the code if any modifications are required a few weeks, months or even years later. Besides the remarks inside the code, a document will be provided to the client. This will contain a detailed description of the entire database structure as well as all the automations (scripts, DTS’s, procedures, …) and processes.