Release Criteria

Software release doesn't benefit from uncertainty. Write in stone your release criteria that have been approved by marketing. This is surprisingly simple and may read something like this. Software is ready for release when:

♦ It is deemed to have sufficient functionality to be saleable.

♦ It has passed the internal test procedure satisfactorily.

♦ The incidence of Class B bugs falls within IT standards and is deemed to be trivial.

♦ There are no other showstopper issues.

Should You Make the Bug Log Public?

There is no universal rule. If you are developing a product designed for technicians, it may build confidence if you publish a regular list of bug fixing progress. Technical users tend to like it. Users can look up issues and see exactly how much work the programmers have been doing between each build. On the other hand, publicizing bug fixes creates an impression that the software is under perpetual development, which any live software program is, but it just reinforces a "not finished" image in the customers' minds. This technique works to bond the program writers and testers during the early stages of product development.

A significant drawback is that by stating that a particular bug was fixed on a particular date you might expose yourself to people who might use this information against you. The purpose of qualifying your software is to allow you to establish standards.

Sign Off

When you arrive at a marketable version and the collective decision is to launch, it is important that you sign off on the product and make no further changes. The release candidate now needs to be transformed into the release product. To finalize the release version, take the following steps:

1. Install it on a clean machine and check that all current defects are fixed.

2. Change the version number to a release number.

3. Turn off all debugging code.

4. Compile the whole program.

5. Update readme.txt files and/or equivalents.

6. Insert matching help programs and documentation.

7. Apply a date stamp to release files.

8. Build the release set.

9. Check that all files are present and correct.

10. Produce a gold disk.

11. Virus test the gold disk.

12. Store the gold disk away from your work in a fireproof safe.

13. Compare on before/after installation Registry settings.

14. Make a master copy of the course code and seal it away (electronically rather than physically).

15. Distribute for press testing.

0 0

Post a comment