The Practical Magic of Building Your Software

We don’t do magic. We do real things that look like magic.
What Customer wants isn’t always what Customer needs
Our approach is to understand the business case first and to offer the best possible solution. In many cases, the outcome is optimized business processes instead of appropriate software solution only.
In-depth Research
In-depth Research

To build the best possible software solution for your business we must fully understand your requirements, priorities and commercial objectives. IT projects fail where there is poor planning, unrealistic expectations and minimal stakeholder involvement. The development process starts with in-depth discussions about the scope of the projects and key requirements. Next, we build a conceptual model of the proposed software solution to test our common understanding of the key requirements.

Architecture and Agility
Architecture and Agility

Having agreed the scope of our software development project, it’s time to start the design and build phase. First, we look at the choice of software architectures and select the right one for the job. The choice of architecture is important. It will determine how easily the software can be developed in the future. We use Agile development methods, which rely on small iterations and regular software deployments. In this way, you, the client can continually assess progress. Agile software development is three times more successful at delivering projects on time and within budget than more traditional techniques such as Waterfall.

You Drive, We Deliver
You Drive, We Deliver

Agile is a very collaborative, flexible process that puts you, the client, firmly in the driving seat. The fortnightly periods of build, learn and adapt mean that you can change priorities, and gain maximum advantage from new ideas as they emerge during the process. Agile allows you to constantly track progress and make adjustments on the fly rather than having to wait months for a “finished” piece of software. We believe that great software should always be changing and evolving to better meet your business needs. After product delivery we’re there to provide support and maintenance. We’re also there to refine and upgrade your software as your business grows and develops in a continuous, virtuous circle.

Software Development Process In Detail

Foreword

Although the steps below are described sequentially, the Agile methodology foresees that SDLC process iterates over them several times and can switch between the steps when necessary.

Switching between the steps can happen in the scope of the whole project as well on the level of specific modules/features only.

Normally, the steps are performed in the sequence they are listed below but not necessarily. The sequence of the steps is defined and regulated by the technical project manager/architect/team-lead who performs the research and supervision of the project development phases, its business needs and makes decisions accordingly in order to make the software development efficient as possible by combining the efficiency with project requirements defined by the business.

1. Planning

Business prerequisites are acknowledged in this phase.

Meetings with supervisors, partners and customers are held to decide the prerequisites like:

  • Who is going to use the software application?
  • How is the software application going to be used?
  • What information is the software going to process?

These are general inquiries that get replied during the prerequisites acknowledgement stage.

A Requirement Specification document is then created to serve the purpose of guideline for the next phase of the cycle. It usually consists of the following:

  • Functional Requirement Specification
  • Business Requirement Specification
  • Client/Customer Requirement Specification
  • User Requirement Specification
  • Business Design Document
  • Business Document

2. Requirement analysis

Performed by the senior members (systems architects and analysts) of the software development team along with marketing and industry experts. This is the crucial part of the project where the software development team leaders must understand the essence of the software to be developed, the specifics of the business case and the potential positioning of the software being developed against the products of competitors, (assuming they exist in the market).

The outcome of this stage, usually, is the SRS document, which stands for Software Requirements Specification.

At this stage, the identification of the development risks, as well as the quality assurance methodology baseline, is decided upon.

The outcome of the analysis stage is to define the technical solutions which will lead to the success of the project with minimum risk.

3. Design

After the requirements analysis, the leader of the project writes down the decisions that were taken and develops the so-called Software Requirement Specification (SRS) document. The SRS is the reference guide for the software architects to deliver the best possible result for the given software.

The outcome of the work of the software architect(s) is the System Design Specification (SDS). This document sometimes is also called the Design Document Specification (DDS). The best scenario is that the SDS is reviewed by the important stakeholders of the project from different outlooks, such as: risk assessment, product robustness, design modularity, budget and time constraints. The best design model is then discussed and selected for the product.

The design of the software clearly outlines the architectural modules of the product as well as data flow and communication diagrams within the product itself, in addition, it specifies any third-party integration that is relevant to the product.

4. Implementation

At this stage, development of the software on the basis of the previous step takes place. Fundamental features are implemented first while the analysts keep returning back to the requirement and design steps for further requirement gathering and analysis to implement less important features and tweaks in the following iterations.

The complexity of this stage heavily depends on the outcome of the previous two stages. The better the SRS and SDS, the easier it is for the software engineers to develop the required software modules. It is no secret that if the first prototypes/versions of the software are required within a very short timescale, then this can adversely affect the quality of the final software. Quality also depends heavily on the analysis capabilities of each individual taking part in the coding process, as does having a properly prepared SRS and SDS.

The more experience and brain-power the analysts, architects and developers have, the less time and documentation is needed in the design phase.

5. Testing and Integration

Although this stage is called testing, in real life, the situation is that faults found in the software in the testing phase, lead back to the development phase and then back to the testing phase in circles, until the software finally reaches the necessary quality. The testing phase normally consists of two internal phases:

  • Automated unit/functional tests
  • Acceptance tests performed by a human

6. Maintenance

This is when the software is released to the alpha/beta or stable state and feedback starts to come in. Analysis of the feedback can then lead to second third or fourth iterations of the SDLC which means, the process is continued again with phases 1, 2, 3, 4 and 5, gradually eliminating any issues that have been found in the released software.

The whole software development process can also be planned over several iterations, especially, when it comes to Agile, where the main focus is to release a working product as soon as possible and implement different features later on.

Let's Talk
First name
Last name
Phone
Phone number entered is invalid.
Message*
Message must not be empty.
preloader