Developing the blueprint for a Q2 development project

In this week's Landgrave's View, Tim Landgrave discusses developing the blueprint in his method of software development that he calls Quality Software Quickly or Q2.

So far in this series, we’ve examined the need for a system to develop Quality Software Quickly (Q2) and the process of developing the vision for the system. If well thought out, the visioning portion of the definition phase should take about half of the total time allocated.

You should have a clear definition not only of what problem you’re trying to solve and how you’re going to solve it, but also—and more importantly—the expected business benefits of solving the problem.

If you’ve not clearly articulated these in your vision document or if the business benefits don’t outweigh the cost of continuing the project, then now is the time to kill the project. Companies will save thousands of dollars and will produce many more long-term products if they have the discipline to only continue development of projects whose benefits and vision have been clearly articulated.
In our first installment on Q2, "Developing Software Quickly: How to use the Q2 system," we looked at the basic rules that define a Q2 (Quality Software Quickly) development project. Last week, in “Defining quality in a Q2 development project,” we examined defining quality on such a project. In next week’s column, we’ll look at how development works in a Q2 environment.
Assuming that you choose to continue, the next deliverable of the definition phase is to create a product blueprint. This deliverable goes by many different names—functional specification, technical specification, system design document, etc. But the core function of the document is to define exactly how the developers will implement the product’s features.

This should be done with the same level of precision that an architect details the features of a new building. Anyone working on the project can refer to the technical specification to see how he or she should be implementing specific functionality.

Sections of the blueprint
As with the vision document, the blueprint document is also composed of several sections. Over time, you will develop your own terminology and define what sections are required in order for you to make development deadlines. Here are the key sections required for a detailed specification.
  1. The reference platform dependenciessection describes how this product interacts with the reference platform and details any expectations or requirements for successful installation and operation of the product.
  2. The product conceptdescribes in prose how this product will implement the solution concept based on the required use cases. This section is designed to allow readers—users and developers alike—to understand how the new product will interface with the reference platform to accomplish the tasks identified in the use cases.
  3. The implementation section details the specifics of application development in a series of lower-level specifications (data specification, component specification, and user interface specification).
  • The data specification details all of the new data sources that need to be created and how this product will use existing data sources. The data specification needs to be detailed enough to allow data center operations employees to create any necessary data repositories required by the product. It should also detail what data is permanent (what must be backed up and restored) and what data is state-based or transient.
  • The component specification details the functions and method calls for all components used by the system, including not only custom-developed components but also reference platform components with which this system interacts. This specification should be detailed enough to allow developers to write code implementing the features for new components and should have sufficient information for developers to code against other system components without having to do a significant amount of research first.
  • The user interface specification describes how the product will implement its user interface in each of the following containers and should include completed screen design and layout for each (where applicable):
    Windows 32
    HTML 3.2 Web Interface
    Internet Explorer 5.0+ (DHTML/XML) Web Interface
  1. The draft deployment specification details interaction between this product and the existing reference platform, including security issues, space planning, backup considerations, recovery procedures, software licensing issues, performance considerations, network traffic generated by application or components, etc.
  2. The test plan outlines the specific functions of the system that will be tested and the types of tests that will be performed during the development phase. It will also include a testing schedule for unit, system, and platform tests.
  3. The documentation plan details the amount and format of system and user documentation that will be generated, as well as the delivery date for documentation. Documentation for the system should be developed in parallel with the application and based on the specification.
  4. The development plan identifies the time to be spent by and expected deliverables for each team member. This will be the master project schedule that all team members will follow.

At the end of the definition phase, the team should produce an updated project risks document identifying the risk mitigation strategies developed in response to the vision document and detailing additional risk factors that have been identified as a result of developing the specification.

Moving on to the development phase
Once the definition phase documentation is completed and signed off by the manager with budgeting authority, your team is ready to move to the development phase. At this point in the process you should have sufficient documentation to virtually guarantee that the team will be able to deliver a product with some subset of the features described by the vision document and product specification. As always, the devil is in the details.
Do you have a standard process for developing applications in your business? Tell us about them in an e-mail, or post your comments.

Editor's Picks