We develop mainly under JEE and Java platforms and in C/C++ languages.
Would you like to know more? Contact us at
algomica@algomica.cz
BEFORE WE START DEVELOP SOFTWARE TOGETHER
Before we start software development it is necessary to have clear idea what should resulting software do and what requirements it should fulfill to be maximally useful. Here we demonstrate what is our typical approach during initial gathering of requirements and writing of specifications of what software we are going to develop. This approach we apply mainly for customers which do not have enough technical background to be able to manage this process themselves.
Gathering of requirements
During our initial discussions with customer we try to find out customer needs and expectations about new software. At this phase we also maximally try to orientate at customer domain and terminology - we learn to speak his language
Result of our common effort is group of simple requirements on software functionality - Functional requirements. They enable us (as software producer) basic orientation in customer needs and they represent bridge between customer and software development environments.
If customer has clearer idea about how he wants to use the software we formally describe so called Use cases. Use cases are simple scenarios describing steps during certain usage of the software. They help us clarify in what way customer wants to use the software and what the software must fulfill to be useful for the customer.
Functional specification
After successful gathering of requirements and their analysis we can start to write functional specification document. It is detailed description how the software should work but without link to a specific technology or system architecture. When writing functional specification the following areas should be taken into account:
1) Data model – formal description of data and information in the system and relationship among them. For data description we always try to use form understandable to a customer.
2) Description of functions – if we simplify it it can be said that this is description of what it can be done with the data from point 1) and how should the data change based on actions executed in the software.
3) Interaction with other systems – even the most simple standalone applications enable import and exports of data. More complex information systems needs to be integrated with existing systems. Therefore it is necessary to describe interaction and data exchange with other systems and software. Because if such interaction is required its implementation usually makes significant part of effort expended on development of the software.
4) Roles and permissions – functionality which the software offers to a user may depend on which user is currently logged to a system. It must be defined who can do what in the system and under which circumstances.
5) Graphical user interface – description how user interface (UI) should look like so that it would enable to do all the action from point 2). It is good if the description contains also graphical proposals including layout of all components. UI is area where even non technical customers have relatively clear idea how the sofware should work.
6) Functionalities of user interface – what all should be the UI do so that it would enable to a user effective and pleasant work with the software. This includes different kinds of filtering, sorting, searching, scrolling and paging of bigger amounts of records, drag and drop. If there are requirements for rich functionality of UI it means higher costs of UI development. Therefore it is suitable to document customer expectations in this area before development starts.
7) Printing – most of today software offer to a user some kind of print output. For this output we must specify format, content and graphical form like for UI.
8) Application localization – lot of our customers is coming from international environment. In such case we must count that we are going to develop multilingual software. If the software is being developed as multilingual it means just little higher costs compared single language software. On the other side add another localization to a software where such possibility has not been taken into account from beginning can be costly.
9) Application performance – it is necessary to take into account not just the functionality of an application but also performance which will be needed. Sometimes happens that application works fine for certain count of user but under higher load it gets so slow that it becomes hardly usable. If you have specific requirements for number of user to be served by the application or on high anount of data processed it must be documented in the specification.
Based on functional specification we are able to prepare qualified estimation of development costs. Functional specification also serves as base of contract for development of the software. Alternatively can be part of the contract also technical specification (see next step).
Technical specification
Follows writing of technical specification. It is description of particular technical solution of functional specification. Technical specification contains designs of system architecture and its part, selection of particular technologies which best serve functional requirements. Technical specification contains our know-how and specific technical solutions.
Meanwhile in case of functional specification we usually enable that customer after paying for it uses the functional specification for development by other software development company technical specification is considered to be confidential between us and our customer.
After we sign contract about software development (for which we need at least functional specification) the software development itself can begin.