HIS软件过程在Vsts上应用培训.pptVIP

2.4、Bug Bug登记 Bug必须关联测试任务 或 软件质量问题。 Bug确认 Bug登记后并未正式生效，测试人员必须对Bug进行确认。确认无误后把Bug状态改为“活动的”。 Bug解决 发现需求分析设计中提供的数据结构变更存在问题，则必须找与开发主管沟通，并由开发主管根据实际情况进行调整。同时开发人员应在修改Bug时特别说明“要求中的数据结构设计”作了修改。 修改程序同“开发任务”，但在CheckIn时应关联当前Bug。 测试环境搭建 把修改Bug的目标程序放到测试环境中。 如果要求的数据结构发生变更，应重新执行数据结果脚本。 把测试环境搭建状态改为“已就绪” Bug重复打开 Bug关闭 三、支持过程 3.1、问题 3.2、风险 3.3、评审 3.4、变更请求 三、支持过程 3.1、问题 3.2、风险 3.3、评审 3.4、变更请求 3.1、问题 实施服务人员现场升级后发现软件存在问题，HIS条线原来是通过发《Bug登记单》的word文档给升级技术支持负责人。现在全部用 “软件质量问题”代替。整个升级技术支持工作在新的过程管理中全透明。 3.1、问题 软件质量问题流程 3.1、问题 软件质量问题登记： 医院 医院当前使用版本 升级那个要求发生的问题：关联相关要求 软件质量问题接受与处理： 软件质量问题解决： 软件质量问题关闭： 三、支持过程 3.1、问题 3.2、风险 3.3、评审 3.4、变更请求 三、支持过程 3.1、问题 3.2、风险 3.3、评审 3.4、变更请求 三、支持过程 3.1、问题 3.2、风险 3.3、评审 3.4、变更请求 谢谢！ * 一、过程介绍 二、核心过程 三、支持过程 软件过程在Vsts上的应用 一、过程介绍 二、核心过程 三、支持过程 软件过程在Vsts上的应用 一、过程介绍 原软件过程 一、过程介绍 现软件过程 一、过程介绍 一、过程介绍 二、核心过程 三、支持过程 软件过程在Vsts上的应用 二、核心过程 2.1、计划 2.2、要求 2.3、任务 2.4、Bug 二、核心过程 2.1、计划 2.2、要求 2.3、任务 2.4、Bug 2.1、计划 2.1.1、计划过程 2.1、计划 2.1.2、计划制定 项目（或某阶段工作）启动时立即制定相应计划。明确项目（或某阶段工作）范围、验收标准、开展步骤或阶段；估计规模；计划进度。 详细的项目计划文件可以通过附件放到计划中 计划制定相关内容约定： 计划名称：用户名称_计划类型_日期 项目经理：项目经理制定、并填写项目经理 优先级：1最高、3最低。（后同） 预计规模：单位人日。指包括实施服务、开发测试的所有工作量 计划时间：开始日期、结束日期为整个计划的计划开始和结束日期。发布期限指期望计划范围内所有需求完成并发布的最后期限，发布期限一般小于计划结束日期（培训、数据准备、升级上线还需要时间） 计划状态：新计划制定时处于“已制定”状态。需等待部门经理安排审批工作。 相关过程约定： 对具体工作作了安排（即计划）才可能开展相应工作。因此，需求调研工作成果（即用户需求）必须属于相应计划。 计划在批准前就可以调研、登记用户要求（需求）。但只有计划得到批准后，其中的要求才能进入后续环节。 2.1、计划 2.1.3、计划审批 部门经理安排对已制定的计划进行审批。 计划审批相关内容约定： 计划审批： 注意计划的完整性、合理性、可行性、必要性； 范围是否明确无误； 进度安排和规模估计等是否合理； 计划被批准： 明确批准人、批准日期、批准意见（对计划中存在的可接受的问题提出改进建议）； 把计划置为“活动的”状态。计划一旦被批准，计划范围内的工作即可开展下去。 计划不被批准： 明确批准人、批准日期、批准意见（必须说明不被批准的原因） 把计划置为“已关闭”状态、原因为“计划未批准”。 2.1、计划 2.1.4、发布与用户验收 发布： 在计划发布期限前，若所有要求都已经关闭则，测试部对当前计划范围内的所有要求所修改的程序打发布包进行发布。 把发布程序放到$/项目名称/Release/计划发布/年份/月份/计划ID/ 目录下，并关联到该计划 把用户验收测试状态由“未就绪”改为“已发布” 用户验收： 相关实施服务人员根据已发布计划中发布的升级包，在用户现场测试环境中升级并与用户进行验收测试。把用户验收测试状态由“已发布”改为“就绪” 用户验收测试通过： 把用户验收测试状态由 “就绪”改为“通过”，明确用户验收意见。 用户验收测试通过后，若计划已完成，则把计划状态改为“已关闭” 用户验收测试未通过： 把用户验收测试状态由 “就绪”改为“未通过”，明确用户验收意见。 根据用户验收结果，进行后续处理。 软件质量存在问题，在“问题”工作项中登记软件质量问题。 范围发生变更，需要