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.
Prototype
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.
Specification
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.
Implementation
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!
Documentation
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.