数字化校园项目控制措施方案.docxVIP

数字化校园项目控制措施方案 项目控制是对整个项目进行过程中的各种情况进行控制的一种手段，通过对项目进度、项目质量、项目的提交等控制和管理，以确保项目能够在不超出预算的前提下按时保质保量完成。 本节主要从管理控制、交付控制、缺陷管理、质量管理、文档管理和变更管理等方面进行描述。 管理控制 管理控制涉及项目活动的所有方面，控制活动以项目指导委员会会议、项目保证小组会议和其他的项目会议方式来进行。会议类型包括： 项目启动会议 – 提供一个项目的良好开端，以确保如参照、目标、承诺、调整、计划和组织等词汇被清楚的定义、公布、理解并达成一致。 进度会议 – 这是一个常规会议。在会议中，项目经理将汇报项目当前状况，并提供一个契机，让项目指导委员会解决那些项目经理无法解决的项目问题。会议召开的频度由双方决定。 最后阶段的评估 – 它在每个实施阶段的收尾部分进行。 开发结案会议 – 这是项目指导委员会的最后一个会议，用来确认并接受新开发的系统，并正式宣布相关的开发阶段结束。 关键点检查 – 这是一个定时进行的会议。项目经理检查相关交付物，确认项目的技术问题，并按需要采取相应的措施。 交付控制 质量和技术控制主要针对特定阶段提交的交付物，而不是针对整个阶段的产品结果。目的是为了在开发阶段尽可能早的确认并改正错误。它通常采用下面的控制机制： 质量抽查 － 每一次质量抽查，是指技术、质量保证及用户的相关人员对交付物进行检查，确定它已经完成、符合对它的描述、符合质量标准和相关的用户需求。 变更控制 – 一个变更是指与一个或多个交付物相关的并且事先未知的需求改变。它需要被记录并应采取适当措施加以控制以防变化扩大化。 软件配置管理 – 软件配置管理提供一个正式的机制用来对交付物进行标记和归档，跟踪开发状态及它们之间的关系。 缺陷管理 – 缺陷是指已被认为正式通过后的交付物发现技术上的异常问题。它需要被记录及改正以保持交付产品的完整性。 风险管理 – 这个控制机制用来识别、评估、监控项目风险，使项目风险对项目的破坏程度降到最小。 缺陷管理 缺陷管理是管理在系统验收测试中发现的、新系统运行过程中发现的错误的修改工作。发现的缺陷将被记录，而且修正过程需要被严格监控。缺陷是指新运行系统与开发前确定需求规格的差异（即接收到的需求与完成的产品之间的差别），包括文档，用户界面，功能，以及性能。 非偏离需求规格而引起的变动叫“变动请求”（CR）。CR将被按照变动管理的方法去报告和处理。详细描述见“变动管理”部分。 缺陷跟踪系统 为在系统开发过程中，能够即时提交缺陷，管理缺陷，分配、更新缺陷跟踪记录，必须建立缺陷跟踪系统。缺陷的管理包括： 缺陷发现 缺陷提交 缺陷分级 缺陷分配 解决缺陷 再测试 发布和完成 缺陷状态 每个缺陷将被分配一个状态。缺陷的处理过程可以通过观察每个缺陷的状态来完成缺陷监控。可能出现的状态有： 《项目缺陷状态表》 状态 说 明 活动的 缺陷已经输入，还没有实施解决措施 已解决 缺陷已经分配，问题正在解决，等待再测试。 已完成 缺陷已经测试过了，没有碰到更多问题 重复 属于重复性的缺陷 优先 缺陷比其它系统缺陷要优先处理 缺陷发现 大部分缺陷是在测试阶段发现的，如先前所讲，缺陷是文档中描述的需求与完成产品之间的差异。而系统改进方面的请求应按照“变动管理”方法处理。 缺陷提交 每个项目组成员都可以提交缺陷，通常，大部分缺陷都是在系统测试阶段发现的。在这种情况下，缺陷要报告给项目经理，并且登记到缺陷管理系统。所有的缺陷将进入缺陷管理系统，它们应该包含以下信息： 缺陷所在系统模块 缺陷的详细描述 如果是功能缺陷，说明是否缺陷会再产生，以及再产生的步骤。 严重度 根据发现问题的性质，缺陷的重要程度可以分为： 《缺陷重要程度表》 PRIVATE 严重度 适 用 于 S1 防碍系统能力的发挥 S2 防碍运行和重要任务的完成，但是其他功能仍然可以用 S3 影响运行和重要任务完成，而且没有解决措施 S4 影响运行和重要任务完成，已经发现解决办法 S5 使操作员使用不方便和烦恼，但是不影响运行和关键任务处理 使操作员使用不方便和烦恼，但不妨碍任务的完成 S6 其他影响 缺陷一旦被接收，分配一个唯一编码，其状态为“活动” 缺陷优先级 缺陷管理长官要每天监控缺陷提交。根据缺陷的严重度和性质对缺陷分配一个优先级： 高- 缺陷必须尽快改正 中- 应该尽快修正。 但是，可以在所有高优先级别的缺陷修正之后做。 低- 缺陷可以以后再改，不会影响系统运行。 缺陷分配 缺陷将按以下顺序分配给开发者去改正：高，中，低。在软件开发和内部测试阶段，分配和解决缺陷可能不必获得项目经理的批准。软件开发者可以分配和解决所有必要的缺陷。 然而，一旦一个版本已经选为基本版