As custom software development is our core business, we face the challenge of ensuring that both sides feel satisfied with the end result. The key to the success of the project, which is to create a custom software, is to precisely define what the program should do and how it should look like.
Project specification
The specification should include:
- Input data and their source (e.g. file, user input, webservice, database)
- Output data - format, form, destination (e.g. screen, printer, file, folder, save in database, webservice)
- Processing scope - How the input data is to be processed into the output data
- The user interface, i.e. what the program should look like, in particular:
- Menu
- Writing and arranging individual screens (input and output fields, buttons)
- Transitions between screens
This specification is the basis for:
- preparation of a valuation, from which the amount of remuneration contained in the contract results
- determining the date of performance, which is also an important point in the contract
- building the entire concept of the solution
Prototype
Our experience shows that not everything, especially when it comes to the user interface, can be predicted and put on paper in the form of specifications. Often, it is only when the client sees a running program that he states that he did not mean that he would like to change something, although everything was made according to the specification.
Some changes are often possible to introduce, but you have to take into account higher costs and a postponement of the completion date. The more revolutionary the changes, the more difficult to implement them and the higher the costs.
That is why we use prototypes in our work. The prototype can be clicked in to verify whether the original assumptions were correct, whether the navigation is optimal and ergonomic. At the prototype stage, making changes is most appropriate.
The prototype does not process data, but it allows you to show exactly how working with the program will look like. When preparing a prototype, we can immediately prepare a graphic design. The prototype approved by the client is already the basis for programming work.
It is often the case that the production of a prototype is the subject of the first contract with the client. Then the prototype is an attachment to the relevant contract. The customer, being the owner of the prototype, has a free will - he can commission us to develop the software, but he does not have to - he can choose any other company.
What if you don't know all the details at the beginning?
A variant is possible in which we do not specify the details of the entire project at the start, but only the basic assumptions and details of what is to be done in the first step. This methodology is referred to as agile software development.
This variant is very good especially in situations where the contracting authority does not have a precise vision of what it wants to obtain, because the vision crystallizes gradually as the project progresses. The downside is that in this case neither the cost of the entire project nor the completion date can be determined.
In an agile model of cooperation with the client:
- We have a jointly chosen direction
- Together, we determine the details of the next stage of work
- At the end of a given stage, we set the details of the next one
In this way, we avoid establishing details that are difficult to determine at a given moment because we are focused on a different issue. It's also easier to make changes and new features that weren't planned at launch. You can also give up ideas that initially seemed necessary and turned out to be wrong during implementation.
Have an idea? Let's talk
