Coded Silicon Product Proposal

Issue Management

Issue management and bug tracking system with flexible workflow control.

The software development lifecycle is never free from bugs and change requests. Tracking the life of a software issue from its identification till its resolution has been the focus of many software tools. The extended requirement may be an overkill, but it is worth stating here.

• An issue is identified and recorded using a description of a test case and relevant screen shots.
• The issue is evaluated against a database of issues for uniqueness. Issues that are duplicated can be combined and this provides the benefit of more test cases and better descriptions.
• The severity of the issue is identified by asking, "How severely does the issue impact the successful operation of the software?"
• The priority of the issue is identified, typically by a project manager. "How does the issue affect the project's critical path and delivery promises?"
• Issues may be packaged into discernible workloads for short-term project planning
• The issue is assigned to an analyst (business analyst, analyst programmer or technical team leader).
• The issue may be passed around during investigation. As the source of the problem is identified, the responsible team is asked to continue investigation.
• Multiple workloads spawn from the issue in order to work towards a resolution.
• Each workload is estimated. This usually happens while each analyst decides on what actions are required.
• The interdependence of each workload is established.
• A project manager may need to re-evaluate the feasibility of the resolution while planning for resource availability.
• Each relevant analyst/programmer/DBA starts working on the resolution as planned. Concurrency control is required to reflect the interdependence of each workload.
• Each analyst updates the status of each workload as completion of each task is reached.
• A project manager or team leader confirms completion of the total resolution and confirms the packaged version numbers of the updated modules for delivery of the solution.
• Test cases are revised to ensure they apply to the resolution and illustrate a solution.
• After the relevant modules are deployed to a test environment, the test cycle starts. A patch to a module may contain resolutions to many issues. Clarity about which modular versions are required for a resolution is essential to avoid unnecessary attempts at testing an issue.
• The issue is assigned to a test team for system integration testing.
• After system integration testing, user acceptance testing starts.
• After user acceptance testing, regression testing starts.
• Testers update the issue to show the outcome of each test.
• The overall resolution success is determined.
• Failed resolutions are forwarded back to a project manager or analyst.
• Resolutions that have passed all tests are marked for production deployment.
• At any time the project manager or business manager may view the list of resolutions available for production deployment and then initiate a request for promotion.
• Resolutions that are promoted to production are flagged accordingly.
• Each promoted resolution may be tested in production if the test is non-destructive of the production data.
• During participation in an issue, a person may decide to add the issue to their own notification list. A person may view the statuses of all the issues in their notification list in the form of a report. There may be a need to notify a person via email when the status of an issue changes.

Status: Considering development