The development process is followed by thorough testing. But tests are also an integral part of our daily work, and are performed for each new part of the system. There are two types of tests: manual and automatic.
We also perform unit tests, prepared by the developers creating the software. We try to use the Test Driven Development approach, which is obviously a big challenge and requires a lot of discipline. This approach means that every short development cycle is concluded by a test which shows what has to be improved or what new software features should be implemented. We avoid the Test Last Development approach, i.e. writing tests after writing the code.
Integration tests come next to verify the integrity of the whole system.
After our internal tests we subject the application to „field” tests. Because some of our off-the-shelf solutions are used by several hundred banks, prior to releasing every update we make sure it is free of critical errors. It may happen, however, that some minor problems still occur and the software is a little rough around the edges. Users occasionally report errors and problems that can only be replicated in very specific conditions, and are impossible to reproduce in a staging environment.
It doesn’t cause dissatisfaction if issues are few and immediately solved. Of course the first version of the software must work well and perform all its functions, but given the complexity of software and diversity of environments users work in, such imperfections are virtually inevitable. It is thus so important to deal with such reported errors quickly. This approach can be implemented sensibly whenever potential errors in the system can be fixed immediately and do not affect the otherwise good performance of the system, and results of the company.
Of course, the application is accompanied by documentation, which may be very extensive sometimes. In the case of complex systems, it can reach several hundred pages. Each functionality is described step by step, which consequently makes users more independent in their work. For less complex applications, documentation is respectively shorter. Documentation is always prepared in English by default, but we also deliver it in other languages upon client request.
Another important step is training. Its form and duration also depends on the application type. Whenever a new functionality is delivered to thousands of users, we organize group training. Such workshops are attended by representatives of several companies, which allows us to transfer the knowledge to a greater number of users. When an application is being prepared for one company, however, we usually conduct the training at client's premises.
Software development rarely ends after delivering documentation and organization of training. Conversely, it is an ongoing process. That is why support and application development are so closely tied together.
Our support service gathers information about problems commonly reported by users of the system. Apart from reporting errors, users want to know how to perform certain operations, or where to find a data input field. If these queries repeat, we improve the functionality to make the application simpler and more user friendly. After such a modification the cycle starts again. The code is then tested, changes are documented and, if necessary, user training is organized.
Without the support and development, applications become outdated and unattractive to users. Much like in the case of cars, regular inspections ensure years of trouble-free operation. Without these checks driving a car becomes less comfortable and safe, the machine loses value, and its tailpipe produces ludicrous amounts of smoke. But servicing is always more economical than buying a new one every two to three years.
That is why the service also involves technological development of applications. Even when not adding new features, we consistently make sure that our software is up to date with the rapidly changing IT environment. These changes primarily regard compatibility to new operating systems, browsers, but also applicable laws and regulations.
XBRL would be a good example here. We have created several applications based on this standard. We had had a two-year head-start before the new XBRL standard was officially introduced. This allowed us to start working on adjusting our solutions well ahead.
The line between application creation and further development has become very blurred, especially in agile methodologies. When one version of the application receives the status „ready” and is sent to users, another version is already being developed, with extended functionality. Feedback and feature requests are usually provided by managers and users. While managers are constantly looking for opportunities to improve the efficiency and quality of work, users discover new ways to improve their experience with the application. The application development process is practically never ending, and inevitable.
They usually become obsolete. It happens whenever software stops growing technology-wise, it is not updated and developed. Then, at some point, it reaches a point when it's not salvageable anymore and the client must consider developing a new one. This, of course, involves significant cost. We do all we can to save our clients from such situations.