Our firm has built its internal organization as well as its attitude and approach to clients on Agile principles. The principal characteristics of this kind of work organization, from client's standpoint, are:

1. project requirements can be much less detailed in comparison with the classic approach.
2. possibility for correction of project specification during the project development.
3. possibility of client control of the implemented functionalities through active participation in their testing.
4. continuous testing during all phases of development reduces the final testing to almost a mere formality.
5. documentation is being written simultaneously with the development process and therefore tightly corresponds to the implemented functionalities.
6. less pressure on programming staff results in a more positive atmosphere in the team.

As with any recommendation or standard, Agile remains merely a dead letter unless there exist people dedicated to implementing it in a proper way. Our previous experience in usage of Agile principles, from the client's perspective, means safe project development process.

Useful links: Agile software development, Extreme Programming, Scrum.

Among programming techniques, the object-oriented design is probably the most popular as it presents an efficient way for realization of complex systems. It is characterized by creation of smaller entities whose internal behavior is completely defined and which are then integrated into a single complex system. Defining such objects is the process of describing, in program code, the simpler data-processing procedures.

Usage of these objects, at later time, in creating of complex interactions, shows that very frequently some of those interactions are in fact repeated in different places. As a result of such notion emerged the concept of code patterns. The best known reading that addresses the patterns is a book titled "Design patterns - Elements of Reusable Object-Oriented Software".

Targeted at even more efficient work on complex system development, design patterns are supplemented with narative descriptions of procedures, UML diagrams and code that is verbosely commented according to the strict rules. This, in a word, is documentation. Though providing adequate documentation should be something considered normal, tight deadlines and other problems more often than not lead to documentation lapses whose mending is left for the very end, when almost no one knows all the project details. We can proudly say that, during all the phases of project development, we possess all of the aforementioned documentation components.

Our applications are capable of data exchange, be it among themselves or with other applications, much like participating in a chat session.

The fact that we use web services as the standard for inter-application communication means that our applications are open towards all platforms and programming languages.

The limitation of web services, compared to the other standards, is the large size of messages being sent over the network. This deficiency becomes apparent in time-critical applications. For this purpose we have, as an extension of the web services standard, developed our proprietary system of messages that are both more compact and are created much faster thus facilitating faster communication.

Single application (single executable file), can simultaneously perform more than one task. The individual tasks within an application are performed by the small processes (threads) that exchange data among themselves and thus create a complex system. A system as a whole can either be slow in its reactions to the external events, or it can be fast, providing timely reaction. Depending on needs, the requirement for timely response to the external events can vary widely but never-the-less remains something that the system must provide with consistency.

Aiming to provide the control of work performed by individual processes (threads) within the application, we have developed:

1. reliable system for data-exchange among threads.
2. system of threads that does not overburden the application so that every thread reacts to the event it is responsible for in a timely manner.

Once written, the code needs to be tested. There are two kinds of tests: tests written by the programmers and the ones performed by the end user. Tests written by the programmers (Junit or xUnit) are the first tests to be performed and are very important for the programmers themselves. They provide the appropriate dose of confidence that the code is written correctly. These tests reveal almost all deficiencies related to lapses in the coding process, such as poorly implemented functions that do not perform their tasks correctly, errors in initializer-values, uncontrolled access to a single data-item by more than one processes (threads), etc. Tests performed by the end-user are more concerned with the business-logic procedures related to the higher-level project specification.

If the aforementioned xUnit tests are written correctly we can always be sure that the tested code will perform as required by the project specification. Any modification of the code that results in its changed functionality will not pass unnoticed as xUnit tests will reveal this.

xUnit tests should not be viewed as the final solution for application bugs. As writing tests is time-wise very demanding, it is customary that during the work on any particular project an assessment is made regarding the extent to which the code is covered with tests.

We can proudly say that all of our code is always accompanied by xUnit tests that are themselves (also) well documented.

Acquisition, storage and subsequent data analysis present tasks that are best left to a dedicated database manager systems (DBMS), such as PostgreSQL, MySQL, MS SQL Server, Oracle, DB2, etc. The proper choice of DB manager system depends primarily on the amount of data that has to be processed within a given time frame. The classification can also be made by the available accompanying tools that facilitate working with database, so we can say that the open-source DB managers (PostgreSQL, MySQL, etc.) are more demanding to the programmer than the commercial products (MS SQL Server, Oracle, DB2, etc.). However, since in the end what counts remains to be the DB manager performance, we will stay with the division based on the amount of data that needs to be processed. The key question is therefore what is the amount of data that the system must process, and this determines whether the open-source DB managers are up to the task at hand or the costlier commercial solutions must be sought of. Well, as long as the open-source DBMS can provide the adequate performance - stay with them. When the DBMS performance becomes compromised - switch to some of the commercially available products.

Our recommendation for an open-source DB manager is PostgreSQL. Easy to install and maintain, exceptionally reliable, fast, working under all popular operating systems (Windows, Linux, various Unix flavors, Mac OS), PostgreSQL is also very actively developing as a product.

As far as commercial DBMS are concerned, maybe the only ones that have some advantage over the others are Oracle and DB2 because of their better support for replicated databases as well as their handling of large number of simultaneous connections (load balancing). Since the majority of projects does not have such high requirements, we recommend MS SQL Server or Oracle.

The most widespread operating systems (further abbreviated as OS-es) today are MS Windows, Linux and Mac OS (perhaps Symbian should be added here as the most common OS for mobile devices). Everybody has his or her favorite, but in everyday life we encounter various devices for which we do not know what kind of software they use. The same software could run on any of the mentioned OS-es without the user being able to experience any major difference in its usage. Depending on the software, it is possible to notice the difference in the outlook of windows, buttons, tables, etc. What is important is that there is no difference in the usage of such software. Application designed to work on more than one operating system must behave in the same manner and look the same whatever may be the OS under which it runs.

Operating systems are created around certain sets of rules. Those rules are, for the most part, well defined and adhered to. But, there always exist some errors or inconsistencies that the OS manufacturers do not correct in a timely fashion. Application that aims to work on various OS-es must bypass such problems and thus do not jeopardize the execution of other applications.

As a firm, we possess broad experience in development of applications for MS Windows and Linux operating systems. In order that our applications work transparently under both OS-es, we have based our development environment on both ready-made programming tools as well as our own solutions. Development of applications that work reliably under the aforementioned OS-es also implies that we are proficient in configuration and administration of those OS-es.

What is the definition of a real-time application? Real-time application is the application whose response to any request that comes from the user or any other application with whom it communicates is such that it does not impair the process that is being controlled by the application. When an application requests some data from some other application and expects that the answer will come within, say, two seconds, then the answer must arrive within those two seconds. When an user request, placed by a press of a button, is to be processed in, say, three seconds, than the result must arrive within that time frame. In a word, the response-time must not exceed the required and specified amount. There are no predefined response-time requirements for applications that claim to support work in real-time. The controlled processes are the ones providing the criteria for real-time work, and those response times may span from milliseconds to days, years, etc. It is obvious that, for processes that require fast responses, the processes running within applications must be very carefully designed and realized so that they do not impair the execution of the controlled, physical processes.

We have so far realized systems for the tracking of fast processes that require response times of a few milliseconds. Acquired inter-application response times, within the medium-sized local area network, are within the order of magnitude of one second. The applications that participate in data exchange can also be of self-contained type, that work in the background without the interaction with end user (they are called system services in MS Windows or daemons in Unix terminology), as well as desktop applications through which the end user can monitor processes in real-time. We can say that we are able to provide a good system design that provides short latencies and fast responses.