⇒ deutsch
Logo of evolor GmbH, Berlin, Germany

Software development

Our core competence is software development, to which we – following our business philosophy – apply highest quality standards. As a customer you will benefit from reduced long-term development and maintenance costs.
We want to provide you with advice on the technical consequences of decisions to be made and show possible alternatives. Therefore, we enable you to carry out a better cost-value ratio.
Usually, we apply the following phases of software development, which are adapted in degree of detail according to the project requirements. We also offer you to assume only specific parts of the project, for example, creating a concept of a software, implementing critical parts of a programm, or test and acceptance of a third party software.

Conceptual design

During the concept phase, we will gather the functional requirements of the software to be created, if they have not already been written down; the result of this phase is a functional requirements document.
The process can be executed formally for large projects (compilation, analysis, and evaluation of requirements) or in an abbreviated form if the project conditions permit.
It is important that you have an overview of the expected functionality of the software after this phase, thus enabling you to identify technical risks up front.


Project launch
If potential technical risks have been detected, an optional prototype phase should prove feasibility of the project. Also, assumptions on existing systems, legacy code, or third party code have to be proven in this phase.
The results and experiences gathered in this phase lead to a final evaluation of the technical risks of the project. This evaluation forms the basis for the decision of continuing the project, if no evident doubts to the value of the project exist. We therefore minimize the risk of investment and enable you to intervene before unnecessary costs are produced.


The specification is targetting to translate the functional requirements into specific technical implementation instructions. Usually it is not necessary to specify all technical details – it is unnecessary in many cases, maybe even impedimental. This finding of many software developers bred the spreading of agile development processes.
We discourage to waive a specification entirely for reducing costs. Rather, we advice to reduce the specification to the software architecture (besides the writing out of technical requirements); wrong decisions in early phases can be unwound only with high efforts later.
Now, with concept and specification, it is possible to estimate the volume of the software in cost and functionality.


In this phase, the technical requirements are assembled into an executable for computers. We expend extra effort on getting a faultless software, considering correctness of output and behavior as well as stability of the software.
We exert transparency and want to point out that it is not possible to produces a completely error-free program in practice; it is important to us, to find defects as soon as possible and to limit their consequences. For that reason, we implement unit tests during development.
We are also concerned to produce maintainable and extensible code, to make a long-term usage of the software and its value possible – no matter whether the software is maintained by you, by us, or by a third party.

Test and acceptance

The function of the software has to pass more controls in the test phase if it has not been part of unit tests already. Usual checks include user interface, system, and performance tests. If requested, we create test plans and yield the test results to our customer, so that he possesses evidence of quality.
We put to the test the quality of the software before we deliver it to you!


If requested, we will create a documentation of the software – an internal documentation for further development or an external documentation for administrators and users – in any granularity you want. We want to point out though, that continuously developed software should not be fully documented, since such documentation "ages" fast and becomes meaningless. We rather propose concentrating documentation efforts on the architecture and important details of the software and invest the savings in higher quality code.
© 2011-2021 evolor GmbH, Berlin, Germany