Software Development Project Management Using Blueprinting

Software development project management is greatly simplified by adopting an infrastructure oriented approach and its accompanying software blueprinting process.

Software blueprinting and an infrastructure-oriented approach provide a rigorous project structure, enabling highly concurrent engineering, accurate estimation and substantial risk reduction while improving software quality and customer satisfaction.

Blueprint-based software development project management phases

Software development project management using a blueprinting methodology is split into three main development phases followed by formal acceptance testing and ongoing maintenance:

Phase 1 -Requirements analysis and blueprint development

The first part of any blueprint-based development is capturing the customers requirements and producing a prescriptive infrastructure blueprint. This is an iterative process and the intuitive nature of the blueprint allows the customer (usually with some assistance from the software architect) to understand the impacts of their decisions and refine the blueprint to quite a high level of detail.

The product of this iterative process is a formal, prescriptive blueprint that describes the high-level co-ordination logic of an application (it's infrastructure). This is analogous to a building architect's blueprint that describes the structure of a house.

Once the application framework has been blueprinted, all of the inspirational activity related to the concurrent behavior of the application is complete (with the possible exception of a few tweaks due to subsequent requirement changes).

This means the engineers never interpret the blueprint, they translate it - in fact, as we shall see in phase 2, a machine can do the job. This also means that the software architect's intentions as expressed in the blueprint are reflected directly in the executable code and also requirements can be meaningfully attached to the blueprint.

Containing inspirational activity to the early stages of a project reduces risk considerably because inspirational (problem solving) activities are hard to estimate, whereas procedural activities can be fairly accurately estimated based on extrapolating previous experience.

Phase 2 - Production of an executable framework

The next phase involves translation of the blueprint into an executable framework. It is important to understand that because the infrastructure blueprint produced in phase 1 is prescriptive, this is an entirely procedural process. That is, it is possible to write down a set of rules that a programmer follows to get from the blueprint to the framework.

If the infrastructure blueprint is captured electronically in such a way that all of the necessary information can be extracted from it (i.e. using a language sensitive editor), then the procedural nature of the translation activity means that the blueprint can be machine translated into an executable framework with an appropriate tool - saving a great deal of time and effort.

Phase 3 - Production of remaining code

The final development phase involves production of the additional code that is required to perform device I/O, algorithmic processing, GUI function and so on. This typically accounts for 50-70% of the total application code.

This code populates the framework rather than being integrated together in a traditional sense and this means that a large number of isolated work packages can be identified and therefore the process is highly concurrent.

Another important advantage of generating numerous isolated work packages is the ability to outsource some or all of them to low cost overseas contractors, as appropriate. Follow this link to find out more about blueprint-based software development project management of outsourcing.