CXO

Developing code using Q2

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


So far in our examination of the process of rapid software development (or Q2 for Quality Software Quickly), we’ve identified the necessary deliverables for the design of a new software system. In this article, we’ll look more closely at the process and deliverables for the actual development of code.
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. The second part, "Defining quality in a Q2 development project," examined defining quality on such a project. Last week’s column, “Developing the blueprint for a Q2 development project,” covered the necessity of documenting software functionality. Next week’s article will cover the “delivery” phase.
Code development and code completion
This phase can generally be subdivided into two sub-phases: code development and code completion.

The overall goal for the development phase is to get to detailed functional prototype by the midpoint of your allotted schedule (one month in our development cycle) and then understand the effort involved to deliver the complete set of functionality by the end of the schedule.

In the Q2 environment, all development must be team-based but developer-driven. More specifically, by the time you’ve completed the functional specification in the prior phase, you should now be ready to develop a fully functional code skeleton that shows off all of the features designed for this release.

In this phase, your development process should be very iterative, like peeling back the layers of an onion rather than cutting it in half. Your design document tells you what the onion looks like in the middle.

Being team-based but developer-driven means that the team should meet every two to three days to bring all of the code together that team members have been developing individually. At each new build of the complete product, team members should see more of the product’s depth.

For example, by the time the team meets together for the first time, the UI developer(s) should have an initial interface completed that’s calling simple objects created by the business logic developer(s), which are pulling canned data from the databases or stored procedures mocked up by the database developer(s). Then, the team as a whole can review the specification to decide how to continue implementing functionality that will result in a working, but more feature-rich, application by the next deadline.

Developing in this manner allows the quality assurance group to begin some interface testing and documentation work and allows the groups responsible for maintaining the reference platform to see what, if any, changes need to be delivered for this application in the production environment.

The deliverables for the development phase include the final product and supporting documentation as well as the supporting marketing documents.

By the midpoint of your development cycle, you should have all of the product features coded and working. Features that have been difficult or impossible to implement following the proposed design can now be discarded or retained if additional resources are applied to the features to allow implementation by the end of the development phase.

You should focus your efforts after the midpoint of the development phase on finishing the code required to fully implement the designed functionality and adding proper error handling, system documentation, and deployment specifications. When you’re finished coding, you have a fully developed, albeit beta version of a product.

What’s a finished product look like?
The final product consists of product source code that includes all program code, installation, scripts, and product documentation that detail dependencies on the software versions deployed in your reference platform and which are required for proper product deployment and operation. Your product should also include:
  • The product documentation based on the documentation plan developed during the product definition phase, including
    1. User documentationcontaining sufficient information to allow your platform users to start, use, and perform basic self-support for the product.
    2. System documentation that details the interaction between the platform and components of the system to allow other development groups to interface with their applications or enhance the product with future releases.
    • The product deployment plan identifying the time to be spent and expected deliverables for each team member. This will be the master project schedule that all team members will work against.
    • An updated project risks document identifying the risk mitigation strategies developed during the development phase and detailing additional risk factors that have been identified as a result of developing the product specification.
    • A deferred product features summary that details the product functionality that was removed in order to make the schedule or in response to limited availability of resources.

    Closing out the development phase
    Once you’ve delivered the final product in its code-complete form, it’s time for the testing group to finish the testing process and for developers to focus on eliminating high-priority bugs.
    What problems or roadblocks have held up your development projects? How did you deal with them? Post your comments, send us an e-mail, or start a discussion on this topic.

    Editor's Picks

    Free Newsletters, In your Inbox