The 'best practice' I have seen used is that the defects identified during development transition into bugs accepted for release. That is:
- During development the project keeps track of all sorts of defects, including mistakes in design documents, conflicting requirements, bad implementations, failed tests, etc.
There is a wide variety of approaches that can be taken to this sort of issue tracking... including who can formally declare things to be issues. For medical device software, my preference is that the gatekeepers for these issues are the software technical lead and their quality partner. I don't object to developers having a 'ticket' (or 'todo') system, but my experience has been that relatively few of these sorts of things end up impacting the final product (in terms of performance against requirements, or compliance with regulations, or safety of the device).
- During the project, when the technical lead believes an issue to have been resolved, she consults with the quality partner to consider formal closure of the issue.
This is why I don't like the issue tracking system to be a vague 'todo' list. The technical lead may use a ticket system to track progress, but it is unnecessarily burdensome to involve the quality partner just to make sure people are doing their assigned jobs. YMMV, depending on how well structured the actual development effort is. If there is one developer flitting between different areas, perhaps a ticket system makes sense. This is more about discipline than quality, IMO.
- When the software release is scheduled to occur, the software technical lead and the quality partner review the list of open (unresolved) issues and make an assessment if the issues are to be closed (i.e. rework the solution and/or design documentation) or deferred.
There is nothing magical about this step, expect that it formalizes acceptance that there may be unmet requirements, or that there are defects of some type in the solution.
- The greater team (beyond the software development effort) meets with the software technical lead and the quality partner to formally decide on the issues (acceptable as deferred, or unacceptable). These extra players are usually always someone with direct accountability to patient safety and often include someone with business responsibility.
If issues are not to be resolved (that is, the deficiency will go uncorrected) then the defect is considered deferred and becomes part of the 'bug list' that accompanies the regulatory submission. Again, this is why I prefer that 'todo' and 'nice-to-have' items don't end up on the issue tracker... because it is quite annoying to have issues like 'so and so thinks refactoring this element is a good idea' are quite different than 'battery doesn't turn on when it is supposed to'.