My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
maintenanceplan  
Updated Mar 20, 2011 by wutianhu...@gmail.com

Maintenance Plan

Bug Report

• User posts a bug on Google Project Hosting of iClass Issue page, by setting the issue type to Defect: http://code.google.com/p/iclass-team6/issues/list

Project Manager: Yi Zheng • Project manager checks open issues posted by users on daily base.

• After reviewing each issue, project manager makes change on status of the issue, issue type, and severity level.

• Specifically, project manager will change the status to Invalid if the reported issue is not a bug, to WontFix if the issue will not be fixed, and to Duplicate if the issue has been reported. Otherwise, he will assign the bug to one of the sub teams, base on type of the reported issue.

Generally, sub team 1 is responsible for issues related to interaction process between instructor and student, i.e., issues raised for Course Mode; sub team 2 is responsible for issues related to non-interaction parts of the system. Adjustment will be made by project manager according to the work load and process of each sub team.

• In weekly team meeting, project manager tracks the process of each sub team on bug lists, and makes adjustment on issue assignments accordingly.

• When it comes to release time, the project manager should decide which set of bugs have to be fixed in this build. Such bugs will have higher priority than others and be fixed before deadline.

Sub Team 1: Developer: Baiqi Shao; Quality Assurance: Tianhui Wu. Sub Team 2: Developer: Bowen Ni; Quality Assurance: Rui Shang. • When an issue is assigned to a sub team, the QA will try to reproduce the bug based on the report. QA can make change on the bug report for clarity and disambiguity. In other cases, QA can add comments to the report to explain the reproduce process in detail, or help identify the potential cause of the bug. QA is responsible for contacting the bug reporter when the bug cannot be reproduced following the instructor, or more information is needed.

QA will change the status of the issue to Accepted if the bug is reproduced and to NeedInfo if more information about the issue is needed from the reporter.

• QA can contact the project manager if he/she thinks that the issue is not a bug, or the issue will not be fixed. The project manager will review the request from QAs and make the decision on the change of the issue status. If the project manager insists that the sub team should work on the issue, the bug will be returned to the QA.

• QA will also connect related issues, either issues which have been raised in previous versions, or issues occur in similar conditions, to provide more clues for developer.

• QA is responsible for directing the issue to the developer.

• Developer will change the status of the issue to Started when he starts working on the issue.

If, in the process of fixing bugs, the developer finds that a bug is caused by the improper design of the system, or any bugs of such high severity level, the developer can organize a meeting to discuss the issue within the team.

• After a bug is fixed, the developer will change the status of the issue to Fixed. QA should verify the change, and change the status of the issue to Verified and close the bug.

Change Request

• User requests a change on Google Project Hosting of iClass Issue page, by setting the issue type to Enhancement: http://code.google.com/p/iclass-team6/issues/list

• In weekly team meeting, project manager raises change requests raised by user in the previous week, if any, and discuss whether or not accepts a request. The decision should take the following factors into consideration:

o How many users request for the change

o How beneficial to the user if the change is made

o Does it conflict with the current system design and architecture

o Does it worth the time and cost

o Etc.

• If the team decides to accept a change request, the project manager will assign the task to one of the sub teams, based on the type of the change request and the current work load of the team.

• When a change request is assigned to a sub team, the team should create a technical definition of the issue and a design for the issue. The project manager will then decide the expected complete time for this change.

• The team will implement, test and validate the change in an environment if possible and then test and validate in integrate test. Documentation and tests related to this change should be added at the same time.

• After a change has been implemented, tested and validated in a sub team, the sub team will present the change to the project team. The project team will help the sub team refine the implementation. After the refinement process, the change is available to be published.

Powered by Google Project Hosting