19
Jan
09

How close to formal release do you fix problem reports?

This is a familiar question that comes up at the end of software release cycles. Software development has been completed. Verification is concluding. The last few tests are being run and a problem shows up. What do you do now?

If it’s a serious functional problem, the answer is obvious: you fix it (and hope that it’s not so serious that it affects your delivery date). But what if it’s a minor failure? Still an error, to be sure, but one that is unlikely to show up in any normal use case?

There is a point at which it becomes counter-productive to continue making changes to the software. If the fix for the bug is isolated and easily identified, sure, fix it. But if there is some uncertainty about the fix, or if there is concern that the fix will impact other functional areas in the software, then it is reasonable to leave it alone. The risk of causing other problems in the software with hasty last-minute fixes becomes greater than the risk of leaving the known problem in place.

Be sure to document the problem with a problem report so that it can be fixed for the next release. And be sure to document the problem report, along with the rationale for why it’s safe to leave in the build, and put that documentation in the Software Accomplishment Summary.

Sometimes it’s just safer to leave the bug there.

Advertisement


About SCSW

Safety Critical Software is a blog focusing on the development and verification of avionic and other safety critical software. More -->

credits

Header photo by Naddsy via Flickr.

Follow

Get every new post delivered to your Inbox.