配置管理研究.pptVIP

什么是过程管理？ ? 通过在项目的开发阶段应用过程管理策略，对项目的进程进行控制，解决文档记录不全，丢失，版本不一致、代码版本混乱，权责不明等缺陷。 ? 同时为项目应用配置管理计划和变更管理做准备。 跟踪变更包 ? 在项目的开发过程中加入过程管理人员，指定专门的变更管理员，负责建立问题的跟踪记录，增加，需求的变动和开发过程中的各类问题（代码编写，代码测试，代码缺陷等） 跟踪变更包传播 ? 由变更管理人员负责将相应的变更包分发给变更所有人，明确项目的变更权责。 ? 包括变更的产生，实施和遗留问题，剩余工作量估算，缺陷的修改记录，以及资源的消耗情况 工件问责制度 ? 变更发起人。最初提起变更请求的人员，可有用户和项目组的开发人员担当。 ? 变更管理人员。在项目组中对所有的变更管理进行全面管理。可有项目经理及配置管理员担当。 ? 变更拥有人。 负责在项目组中对自己负责的变更进行处理。由项目组中的开发人员，包括系统架构师，数据库管理员和程序员等角色担当。 ? 变更顾问委员会（CCB）。由项目经理、项目中的资深工程师和用户共同负责。 * 规范项目中所有的变更工作，保证由于变更而引起的问题对生产的影响最小，提高项目的开发和服务质量，为项目的快速推进提供有效的服务。 在确定轻重缓急和对基础架构或项目的影响程度的基础上，为变更事项指定优先级和类别。集中资源处理优先级高的变更需求。 使项目组人员按照一套规范的流程去进行变更工作。 指导项目的建设，分析并解决建设过程中出现的问题 * 功能变更 ? 为了增加或删除某些功能 缺陷变更 ? 为了修复漏洞需要进行的变更，在项目前期可以不遵照标准的变更控制过程来进行，但在项目后期必须严格遵照变更控制标准进行 * 项目变更管理现状 ? 客户向开发人员直接提出变更请求 ? 功能重复的变更请求 ? 目的不清的变更请求 优化的变更请求流程 ? 第一步 变更申请。变更申请人向CCB提交变更申请，重点说明“变更内容”和“变更原因”。 ? 第二步 审批变更申请。CCB负责人（或项目经理）审批该申请，分析此变更对项目造成的影响。如果同意变更的话，则转向第三步，否则终止。 ? 第三步 分配指定变更任务。 CCB指定变更执行人，安排他们的任务。CCB需要和变更执行人就变更内容达成共识。 ? 第四步 执行变更。变更执行人根据CCB安排的任务，修改配置项。CCB监督变更任务的执行，如检查变更内容是否正确、是否按时完成工作等。 ? 第五步 结束变更。当所有变更后的配置项都通过了技术评审或领导审批，这些配置项的状态从“正在修改”变迁为“正式发布”，本次变更结束 * * 致命 ? 系统崩溃导致系统不能继续运行 ? 例如：死机、非法推出、死循环、数据库死锁、功能错误、数据库连接错误 严重 ? 使系统不稳定、或破坏数据、或产生错误结果而且是常规操作中经常发生或非常规操作中不可避免的主要问题 ? 例如：程序错误、接口错误、数据库表、规则、缺省值未加完整性等约束条件 一般 ? 系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果的问题 ? 例如：窗口含义知否一直、无提示信息 轻微 ? 界面拼写或用户使用不便等小问题 ? 界面不规范、辅助功能不清楚、未使用专业术语 * 致命 ? 系统崩溃导致系统不能继续运行 ? 例如：死机、非法推出、死循环、数据库死锁、功能错误、数据库连接错误 严重 ? 使系统不稳定、或破坏数据、或产生错误结果而且是常规操作中经常发生或非常规操作中不可避免的主要问题 ? 例如：程序错误、接口错误、数据库表、规则、缺省值未加完整性等约束条件 一般 ? 系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果的问题 ? 例如：窗口含义知否一直、无提示信息 轻微 ? 界面拼写或用户使用不便等小问题 ? 界面不规范、辅助功能不清楚、未使用专业术语 * 考虑经济问题，选择开源类软件搭建配置管理系统。 版本控制工具：在CVS、SubVersion和Git之间选择，最终选择SubVersion 变更管理工具选择Bugzilla、Mantis、Trac之间选择，最终选择Trac 原因： SubVersion功能更丰富，且项目组内成员已经对SVN有初步的了解； Trac与SubVersion的结合已经非常成熟，可以联合使用完成项目定义的SCM目标：文件版本管理、配置控制、过程管理以及问题跟踪，并能根据需要生成审计报告 基础设施 ? 为安全起见，选择一台单独的服务器作为版本管理和变更管理服务器； ? 经济和版权问题，选择Linux操作系统——Ubuntu10.04； ? 为版本管理部分，创建20G专用分区； ? 为变更管理部分，创建10G专用分区。 ? 在服务器上启动Apache服务，以便进行远程