In terms of re-engineering, what we do.
Top 8 indicators of when it’s time for modernization
The software does the job, but users complain about the interface, spend too much time doing trivial things, or cannot locate features.
The software is functional, but as the number of users grew, or the database became bigger, it started to work unacceptably slowly.
The software is mostly working, but there are bugs the previous team cannot fix.
The software is a self-made prototype. Now you need a “professional” version.
The software is partially functional. The team who started on it is unable to continue, or you have decided to replace them.
The software is built on the older version of the CMS. A user wants to benefit from the new features, but custom modules are written in such a way that they cannot be upgraded easily.
The software is working fine, but needs new features added and the previous team is not available.
The software is outdated and needs drastic improvement in a situation where you can’t simply replace it with new software.
What you need to know before you start re-engineering
There is specific risk that must be accepted by all parties: we cannot make any estimates or implement anything before we investigate the existing solution and analyze the code. Even after that, there’s still a risk of identifying bugs or unexpected solutions created by previous developers. Addressing them is our job, but this risk exists.
Because of the described risk, we offer only the Time and Material engagement model for software modernization projects:
Reengineering can be done only by highly qualified developers with solid expertise in software modernization and knowledge of various technologies. The procedure doesn’t make sense otherwise.
Important steps we take:
The first and most distinct part of the job is analysis. It is common for the customer to be unaware of the true state of the project, in the belief that only a couple of things need fixing. Therefore, we can test the system against stated requirements and offer a Business Analysis. The deliverables are:
On completion of the analysis phase, we are ready to come up with a project proposal and estimate the work that has to be done. The project proposal includes:
In most cases we will offer the Agile development approach based on SCRUM methodology. Development typically runs 30% over the time estimated due to code issues. Depending on the project, typical changes include:
Besides standard quality assurance procedures, our team works at integrating modernized applications into your IT infrastructure, and documents everything in sufficient detail and in an easily accessible form for developers and other stakeholders.