Custom Software Development

High-quality custom software development can be achieved at significantly lower cost by adopting a software infrastructure blueprinting methodology and the right mix of outsourcing and local expertise.

Software infrastructure blueprinting provides an efficient model for outsourcing custom software development, contains risk to the early stages of a project and produces a highly intuitive visual description of the project. This description (called an infrastructure blueprint) enables detailed discussion with customers leading to thorough analysis and refinement of requirements.

What is a software infrastructure blueprint?

A software blueprint is a complete, intuitive description of a particular aspect of application. An infrastructure blueprint captures the aspect that describes how all the different components of an application interact with each other.

Why does a software blueprint reduce cost and risk?

There are several ways in which software blueprinting provides considerable cost savings over alternative custom software development approaches:

Early containment of risk

Component integration approaches integrate each component one by one and fix bugs as they arise. This continues late in the project lifecycle (a recent study by the European Space Agency found that 45% of bugs occurred post-integration).

Software infrastructure blueprinting contains the inspirational (problem solving) activity involved in integrating all of these components, to the very early stages of a project.

The software infrastructure blueprint prescribes a tangible framework that performs the high-level co-ordination of the application. The prescriptive nature of this blueprint means that it can be machine translated to executable code and this executable framework can then be rigorously tested early in the lifecycle.

The infrastructure blueprint describes a single framework in a single localized description that is easy to navigate and intuitive to understand. Components then populate this framework instead of integrating with each other. As these components contain pure sequential logic they are the software engineer's bread and butter and therefore it is easy to:

• Specify them
• Accurately predict effort
• Develop and debug them
• Test and accept them

Their sequential synchronous nature means that population boils down to a simple "drag-drop" operation.

Contrast this to the traditional custom software development approach known in the industry as "glue" logic. Glue logic is extra ad-hoc logic that is sandwiched between adjacent components in an effort to persuade their individual pieces of disjoint co-ordination logic to talk to each other. With this approach, co-ordination logic is dispersed throughout an application making it very difficult to browse, understand and fix.

Shorter feedback path to customer

The software infrastructure blueprint developed during the blueprinting phase is not a design - it is formal code. Therefore any changes made to the blueprint are reflected directly in the executable application in the same way that a change to a C++ source file would be.

However, unlike C++ code, which requires a trained software engineer to understand it, infrastructure blueprints are accessible to a wider range of stakeholders and provide an intuitive visual means of talking customers through the implications of their requirements and refining them.

This provides a much shorter feedback cycle to the customer and in particular it tends to highlight many issues that would not have otherwise been considered until later in the lifecycle. This means that the customer rapidly converges on a sound set of requirements and has a much better understanding of what is going to be delivered.

Another benefit of a formal infrastructure blueprint is that any requirements attached to it can be verified against the blueprint (because it is code). Requirements attached to designs (due to the intractability of attaching them to C++ code) cannot be verified against the design because the design is subsequently interpreted into code (i.e. it could be realized in a number of different ways).

Ability to respond to change

The application framework can be extended or modified at any stage in the lifecycle to incorporate requirement changes. Changes can be introduced easily for two reasons:

Firstly, as we said earlier, the components populate the framework rather than integrating with each other. This is crucial because it means that dropping a component or adding new components requires a simple change to the framework. There is no impact on adjacent components.

Secondly, the framework is owned by a single contractor. This is particularly important where two components have been bid to different contractors. With a component integration approach where co-ordination logic is distributed between contractors, changes to one component could well involve changes to its adjacent components and this may raise contractual issues.

Ease of outsourcing

Outsourcing custom software development can significantly reduce software cost. Software infrastructure blueprinting provides a very effective outsourcing model because it allows a local software architecting company to retain full control of the custom software development.

The local company develops the infrastructure blueprint and generates the executable framework. They are responsible for rigorously testing the framework for structural integrity and liaising with the customer to ensure the requirements of the custom software development are completely satisfied. They may also choose to develop the GUI, as it is harder to specify precisely than processing code and customer/user interaction is often desirable.

Having produced the executable framework and certified it, the remaining code (typically accounting for 50-70%) can be outsourced for overseas development. This code is very easy to specify and timescales are predictable. As each outsourced code module is completed, the prime contractor simply populates the framework with it. This continues until all of the functionality is in place at which point acceptance can commence.