Delivering the goods using the Q2 system

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

Over the last few weeks we’ve been looking at a rapid development framework that I’ve called Q2 for “Quality Software Quickly.” The basic tenet of Q2 is that by fixing a schedule and varying resources and features you can develop high-quality software through a series of mini-development cycles, each lasting a fixed amount of time—three months, for example. Each of the development cycles is divided into three phases of equal length—design, development, and delivery. In this article we’ll focus on the delivery phase.

The most important thing to remember about the delivery phase is who is delivering to whom. In this case, the development team is delivering the application to the testing and deployment teams (and to marketing in the case of a commercial product).

By the time the code leaves the development phase, the testing team should have already devised testing plans that allow for production testing of the application. All unit and integration tests should also have been completed.

The focus of the delivery phase is for the testing group to finish the testing process, developers to focus on eliminating high-priority bugs, and for the deployment team to complete testing and quality assurance (QA) on the deployment process. The deployment should be tested on the reference platform documented during the definition phase.
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. The third column, "Developing the blueprint for a Q2 development project," covered the necessity of documenting software functionality. Last week’s installment, “Developing code using Q2,” looked at the process of actually developing code.
Completing the product testing
Final product testing is the most important deliverable for the delivery phase. It’s the QA team’s responsibility to make sure that not only has the system been thoroughly tested but also that all the documentation necessary to deploy and support the final product has been produced, reviewed, and approved.

During the design phase, the QA team developed a test plan defining the types of unit, system, and platform tests required before formal release of the system. Unit and system testing should have already been substantially performed during the development phase.

Final system testing and all platform tests should be performed and bugs reported to the development team during this phase. The QA team should also work with the help desk or the individuals responsible for supporting the product once it goes live in order to develop a final support plan.

The final delivery phase documents include:
  • The test plan summary, outlining all tests performed and the scalability and performance expectations of the released product. The QA group cannot finish scalability and performance testing until the product is deployed on the reference platform in a production environment, but by this time the system tests should have already identified and eliminated any potential performance bottlenecks.
  • The final support plan, (based on the project risks documents) identifies the risk mitigation strategies developed in response to the final deployment of the system and details additional risk factors that have been identified as a result of deploying the product. If the risk factors identified are substantial enough to justify the delay of the product’s release, then the QA team should raise this issue at the mid-period evaluation meeting. By this meeting, the help desk should be fully aware of the product, its features, the support requirements, and any technical workarounds.

Developing the deployment plan
The other major deliverable for the delivery phase is a completed deployment specification. By the time the product is ready for formal release, all the details of deployment should have been defined, tested, and documented.

If the development team needs to make product changes to accommodate deployment scenarios, then this work needs to take priority during the delivery phase.

The key deliverable of this phase is the production deployment specification. It details the interaction between this product and the reference platform, including security issues, space planning, backup considerations, recovery procedures, software licensing issues, performance considerations, network traffic generated by application or components, etc. It also takes into account the expected system requirements for the total anticipated number of users that were identified in the original design document.

Additional deliverables for commercial products
If your product is being developed for commercial distribution, then this is the time for your marketing team to work with the development and testing groups to create any required marketing support materials. These may include:
  • Product demonstration scripts.
  • Product installation and support on an external Web demonstration server that allows potential customers to try out the product using their web browser.
  • Sales scripts to allow either internal or external sales groups to easily inform prospects about the features and benefits of the product.
  • “Rude” Q&A about the product and its integration with existing platforms.

Keeping your Q2 teams on track
Throughout the development cycle you should be holding weekly code reviews and product demonstrations involving all team members. During each phase, the project team will focus their code analysis and demonstrations on different things. For example, prototypes during the design phase, current code during the development phase, and distribution methodology during the delivery phase may be included.

Both sessions should be designed to refocus the whole team—developers, testers, logicians, and product managers—on keeping their eyes on what they’re developing versus what they envisioned in the original design. If you’re having these meetings regularly, then no one should be surprised at the results when you have project wrap-up meetings at the end of the delivery phase. The team should be getting together to celebrate finishing the development of a great product that they planned as a team from the beginning.
Do you give your development team a standard deadline for developing applications? How do you structure their projects? Send us an e-mail, or post your comments.

Editor's Picks