BUG及需求变更管理制度.docVIP

BUG及需求变更管理制度 第 PAGE 12页，共 NUMPAGES 18页 BUG及需求变更管理制度 第 PAGE 13页，共 NUMPAGES 18页 BUG及需求变更管理制度 拟　　文 梁黎明 湛舜研 审　　核 胡平伟 批　　准 胡平伟 发布日期 2009-11-4 实施日期 2009-11-4 修订历史记录 序号 日期 版本 修订说明 编制 批准 1 2009-10-26 0.1 最初版本 梁黎明 湛舜研 2 2009-10-29 0.1 修改版本 梁黎明 3 2009-11-2 1.0 整理版本 梁黎明 胡平伟 目 录 TOC \o 1-3 \h \z \u 1. 目的 4 2. 适用范围 4 3. 流程图 5 第0步：需求变更确认流程 5 第一步：BUG及新需求提交过程 7 第二步：问题处理及反馈 8 第三步：测试及发布 10 第四步：现场部署及反馈 11 第五步：特殊流程 12 4. 附录 13 附件一、问题清单 13 附件二、程序修改记录 14 附件三、数据库跟踪表（项目名称：） 15 附件四、版本说明 16 附件五、更新日志 17 附件六、用户意见确认表 18 目的 规范环保项目组对BUG及需求变更的管理，提高系统实施过程软件缺陷和需求变更实现的效率，减少问题的产生，提高客户满意度。 适用范围 暂适用于环保项目组。 流程图 第0步：需求变更确认流程 工序 动作 执行者 介质 处理过程 要求 1 获得用户提出的新需求或者修改意见 实施 口头沟通 会议记录 交流草稿 用脑记录 用笔记录 用心记录 仔细全面理解和记录用户提出的需求和意见 对于明显不合理的需求及时拒绝并解释，减少流程成本 2 记录新需求 实施 1）《问题清单》 将沟通时的记录转化为《问题清单》的文档内容 《问题清单》里的问题描述列，记录用户需求详细描述 类型标为新需求 用户需求描述要清晰具体，考验实施文字表达能力 必要时贴图或画上草图 3 知会 实施 必须邮件 辅助QQ 紧急电话 把《问题清单》通过邮件的方式发送给项目经理，并抄送给胡、詹、梁； 如果有必要再在QQ群里通知； 紧急情况请打电话！ 该版本问题清单不需要放入SVN 4 需求分析 项目经理 拍脑袋 组织快速会议 请示领导 分析需求是否合理和可行； 如果合理可行，则评估需求实现的方式与时间 如果不合理，说明原因 如果合理但不可行，提出替代解决方案 看项目经理本事~ 5 需求分析意见用户确认 实施 《用户意见确认表》 根据需求分析结论，将需求记录填入用户意见表中交给用户签名确认； 对于不合理的需求，给用户解释清楚我们的看法 对于合理但不可行的需求，给用户解释我们的解决方案 《用户意见确认表》电子文档放入SVN项目文档的需求目录(/svn/projects/实施/用户意贝确认) 第一步：BUG及新需求提交过程 工序 动作 执行者 介质 处理过程 要求 6 记录BUG或新需求 实施 1）文件：《问题清单》 2）工具：JIRA 首先在JIRA工具上记录BUG并发给项目负责人，由他来指派。 1）BUG和新需求要分开两种类别进行记录； 2）在JIRA工具上记录BUG时，多个问题要分成多个BUG来记录，切记不可多个问题放在一起，这样不利于项目经理指派工作及对问题的后序跟踪处理。 7 知会 实施 1）邮件 2）QQ 3) 电话 1）把《问题清单》通过邮件的方式发送给项目负责人，并抄送给胡、詹、梁； 2）如果有必要再在QQ群里通知一次； 《问题清单》要统一放在SVN的相关目录下（/svn/projects/实施/问题清单） 第二步：问题处理及反馈 工序 动作 执行者 介质 处理过程 要求 8 问题领取并处理 项目经理 1）文件：《问题清单》 2）工具：JIRA 1）接收实施的《问题清单》； 2）对BUG直接在JIRA工具中指派人员修改； 3）对新需求要在《问题清单》表的“项目经理”栏说明需求是否允许做变更以及不做变更需求的原因，还要说明这批问题在什么时间内完成； 4）对记有新需求的《问题清单》表，项目经理要发送回实施； 1）实施接收来自项目经理的《问题清单》时，如果有新需求，要把新的需求记录回JIRA工具中； 2）项目经理必须要在《问题清单》里答复修复完成时间； 3）项目经理要编写《程序修改记录》； 4) 《问题清单》统一存放在（/svn/projects/实施/问题清单）下面。 9 问题处理 开发 工具：JIRA 1）开发人员根据JIRA工具中指派的问题进行程序的修改