When developing software, the process of polishing, documenting, tidying, and adding enhancements seems like it might go on forever. So it’s difficult to know when a software product is ready for release.

This is where a release checklist comes in handy. A release checklist will make it obvious if the software is ready for prime time, or if it still needs work.

Phase one
There’s light at the end of the software development tunnel, but before you can see it, you must address the following aspects of project delivery when you create a release checklist.

Reduce known defects
Decrease the amount of defects to a quantitative level that the client agrees with. You can assess the number of defects at any stage of the project. For example, say you find 100 unfixed defects, and each defect takes roughly two person-hours to fix. You’d have roughly 200 person-hours of defect correction to do. Of course, some defects may be more significant or more difficult to resolve than others. Often a measure of defect severity can be built in to this project completion assessment.

Analyze the code
If you uncover incorrect code, don’t let the project proceed to the next phase until the code is right. Beyond finding out whether the code is accurate, look at how smoothly the different developers’ coding elements have been integrated to ensure a professional finish. Also, see if the quality of the code is up to your standards. Low-quality code takes a disproportionate amount of time to debug, so don’t let it mar your project.

Make sure the user documentation is thorough
The documentation should be a reflection of the code. Be sure the people who write the code write the user documentation with clarity and completeness.

Phase two
The measures of project completeness, which are defined within the project plan, make the decision to release software relatively straightforward.

Several of the more advanced project control tools embody a statistical model of the number of defects you can expect at each phase of development (and also take account of the current rate of progress on fixing defects within the current project). An automated, ongoing comparison of detected vs. predicted defects provides some estimation of how close to release the deliverables really are.

The criteria for release should be some objective combination of the following factors:

  • The long list of yes/no project milestones is complete.
  • The specific number of lines of code are created and plotted as a function of project time (which points up the nearness of completion).
  • There’s a current list of defects as well as the statistics of defect correction on this and previous, similar projects.

Only when you meet these criteria can you start making final preparations for product delivery. Note that you only need an independent testing team to find and comment upon the severity of the defects. The decision rests with you as to whether the software is ready for the next stage: final sign-off.

Phase three
Your final sign-off checklist should include the following elements:

  • Annotate the code with the final version number, date, and time stamps.
  • Remove any testing and debugging code.
  • Back up the built code securely.
  • Prepare final program media and check contents.
  • Check that documentation is complete and up to date.
  • Verify the rightful recipients of the software.
  • Confirm legal, license, and copyright elements.

We’ve got sign-off
Before breaking out the champagne, make sure all the main project stakeholders (as defined in the specification) sign a release sign-off form. If any of the stakeholders are slow to sign the form, show them the data from your release checklist, which will prove that your team has thoroughly prepared the software for release.