NMDLGC 工程实施流程规范

1、It A ft A北京雅龙汉正科技有限责任公司项目管理标准北京雅龙汉正科技有限公司2008年1月更改履历版本号修改编号更改时间更改的图表和章节更改简要描述更改人批准人注：更改人除形成初稿，以后每次修改在未批准确认前均需采用修订的方式进行修目录1. 概述 51.1. 编写目的 错误！未定义书签。1.2. 项目背景 错误！未定义书签。1.3. 建设目标 错误！未定义书签。2. 项目计划管理 62.1. WBS（工作分解结构）分解 62.2. 项目基线计划 82.2.1. 项目基线计划 82.2.2. 基线评审计划 92.3. 项目附属计划 102.3.1. 沟通计划 102.3.2. 风险管理计划

2、 112.3.3. 配置管理计划 212.3.4. 质量保证计划 312.4. 项目阶段计划 362.5. 项目实施采用的平台软件 383. 项目实施作业标准 383.1. 项目实施过程工作项 383.2. 项目实施作业标准 403.2.1. 项目启动阶段 403.2.2. 项目策划阶段 473.2.3. 项目开发阶段 503.2.4. 工程实施阶段 524. 附件 844.1. 测试验收相关附件 844.1.1. 附件 1 : 测试结果签字确认授权书格式 844.1.2. 附件 2: 最终验收意见提纲 864.1.3. 附件 3：测试准备工作确认表 884.1.4. 附件 4：提交的最终验收

3、材料签收表 891. 概述编制本计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、 开发进度、所需软、硬件条件及可能遇到的问题瓶颈等问题作出的安排记载下来，以 便根据本计划开展和检查本项目的开发与实施工作。2. 项目计划管理2.1. WBS（工作分解结构）分解项目总体目标2008年12月30日完成基础业务系统推广、新建项目试点开发、实施分类一级任务二级任务软件工程新建系统原型开发设计原型框架原型框架确认原型开发原型确认需求调查需求调研需求整理（业务差异、实用化需求）需求分析（差异需求报告）需求确认（报送监控组审批）需求管理（纳入基线）UE/UI设计设计UE/UI框架UE/UI框架

4、确认UE/UI开发UE/UI确认系统设计设计原则讨论设计原则内部确认系统总体设计应用系统概要设计（用例规划设计）数据库完善设计应用系统详细设计（用例实现设计和实体类设计 ）ActiveX控件设计内部评审客户确认系统实现编码和单元测试代码抽查软件集成集成测试编写用户手册系统测试测试方案编与测试计划编写测试用例编写测试环境准备（项目现场仿真环境）执行系统功能测试压力测试试点单位上线试运行培训数据移植准备数据移植试运行前测试试点单位开始试运行试运行试点单位初步验收试点结束项目单位推广阶段项目推广开始项目推广单位培训推广单位数据移植准备推广单位数据移植推广单位试运行前测试推广单位开始试运行推广单位试运

5、行推广结束项目管理项目启动项目策划项目监控项目结项项目周报和下周计划内部周例会网省（自治区）周例会人力外包项目支持质量保证配置管理变更管理培训22项目基线计划2.2.1项目基线计划基线产品1标设成果原型基线产品2需求基线产品3UE/UI设计基线产品4系统设计基线产品5产口口基线产品6文档产品任务名称（天）开始时间完成时间标设成果原型设计原型框架3原型框架确认2原型开发21原型确认1需求调查需求调研14需求整理1需求分析0需求确认1需求管理0UE/UI 设计设计UE/UI框架0.5UE/UI框架确认0.5UE/UI开发10UE/UI确认2系统设计设计原则讨论1设计原则内部确认1系统总体设计10应

6、用系统概要设计15数据库完善设计20应用系统详细设计45ActiveX控件设计5内部评审5客户确认5产品系统实现90系统测试20试点单位上线试运行60文档输岀文档318备注：222基线评审计划2.2.2.1.基线评审时间计划基线产品计划评审时间主要参加人员方式标设成果原型项目主管、项目经理、质量保证员、项目组成员、需求项目主管、项目经理、质量保证员UE/UI设计项目主管、项目经理、质量保证员、项目组成员系统设计项目经理、质量保证员、项目组成员产品项目经理、质量保证员、项目组成员文档项目经理、质量保证员、项目组成员2.2.2.2.基线评审报告模版项目名称（编号）会议室审查日期预期评审速率分钟/页

7、开始时间结束时间工作产品信息序号名称作者版本大小（页）检查表标准1有没有2345评审人员姓名角色缺席检查准备时间（小时）12345是是相关文档名称版本存档位置23项目附属计划231沟通计划2.3.1.1.基于问题的沟通计划问题类型沟通对象方式需求变更管理控制组、项目经理、项目主管、公司分管领导:变更委员会会议总体计划变更管理控制组、项目经理、项目主管、公司分管领导会议基线变更管理控制组、项目主管、项目经理、配置管理组变更委员会会议人员变动管理控制组、项目主管:书面2.3.1.2.日常沟通计划沟通对象内容方式时间管理控制组、项目组成员项目进展及问题周例会每周管理控制组、项目主管、公司分管 领导项

8、目进展及问题月述职每月2.3.1.2.1.周例会工作计划单体项目负责人项目总负责人XZ-报送周期工作周报每周五下午10点前每周日中午12点前1 一级/二级组成立开始，撤销 终止项目实施经理 / /总体项目负责人报送周期项目日报每天下午10点前/项目启动会开始，合同签订 终止项目周报每周五下午10点前/每周一中午12点前项目启动开始，项目终止结 束项目月报每月最后1工作日中午12.、八 点刖合同签订开始，项目终止结 束客户周报每周五下午10点前每周一中午12点前项目启动开始，项目终止结 束客户月报每月最后1工作日中午12.、八 点刖项目启动开始，项目终止结 束2.3.1.3.与内蒙客户的沟通计划

9、2.3.1.3.1. 时间表编号沟通内容时间方式1项目启动2008年3月会议2项目整体计划2008年3月文档3调研计划2008年3月文档4需求评审2008年4月会议5数据切换计划2008年6月文档6系统上线计划2008年9月文档7系统推广计划2008年11月文档8系统验收计划2009年10月会议2.3.2风险管理计划风险管理贯穿与整个项目的全过程，具体的时间计划来源与项目实施的每个时间点。风险是一种遭受损失的可能性，这种损失的程度可能导致对项目的伤害直至失 败。风险管理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命 周期中规划风险处理活动，并在需要时启动，以减缓它们对目标的不利

10、影响2.3.2.1. 定义序号定义说明1风险是一种潜在的事件或条件，一旦发生，将会给项目带来一定的负面影响或导致项目失败。2风险管理风险管理就是在一个项目中通过过程和工具来对风险进行识别，跟踪和控制的手段。提供了对可能出现的风险进行持续评估，确 定重要的风险以及实施处理风险的策略的一种规范化的环境。合理的风险管理应尽力减少风险的发生概率；如果发生，则应尽力缩小其影响程度。3风险识别是要对各个相关领域进行检查，以便发现风险并记录下来。3风险分析是对每一项已识别的风险进行研究，以精确描述风险，分析出风险产生的原因、概率并确疋其产生的影响 （成本、进度、技术）。4风险参数包括风险发生的概率、影响的严

11、重程度，以及风险值；风险值是 概率和影响严重程度的乘积，以上具体参见风险管理列表5风险类别按照风险可能导致的影响方面对风险进行的分类。如成本、进度、质里。6问题管理将已经转化成问题的风险记录到项目问题管理表2322 角色与职责序号角色职责说明1项目经理负责项目的风险管理计划、风险管理活动的实施和总结2项目组成员在项目经理的带领下，参与风险管理活动3项目机构参加评审风险值2的风险的缓解措施4项目组收集在风险管理活动中的经验教训。2.323.流程图项目计划活动 项目监控活动项目例会里程碑会议突发事件结项准备项目负责人制定风险管理计划“项目负责人执行风险管理活动项目负责人/ 项目跟踪人风险跟踪项目负

12、责人风险总结风险管理计划1）来源和类别2）定义参数3）管理策略风险管理活动识别分析（可能性、影响、风险值、优先级）制定缓解计划执行缓解措施持 续 活 动注：风险管理活动是一个持续的、定期的，在每周例会、里程碑会议、突 发事件中都要进行风险管理活动。2.3.2.4.风险识别一般性风险识别编号产品规模风险具体风险描述现状分析值风险趋势后果缓解措施应对措施识别结果A 01没有充分估算产品的规模，导致估算的结果缺乏客观依据；1A 02对于估算出的产品规模的不可信或可信度极底，导致规模估 算的结果的偏大或者偏小；1A 03没有以程序、文件或事务处理的数目来估算产品规模，导致规模估算的结果缺乏客观依据；1

13、A- 04估算产品规模与以前产品的规模的平均值存在较大偏差，导 致估算结果可信度低；0A 05产品创建或使用的数据库过大，导致估计的项目规模偏小；0A- 06产品的用户数过多， 远远超过预期数， 导致估计的规模过小；0A 07产品的需求改变太多，导致估计的规模不准确；0A- 08没有考虑可重用构件的设计开发，导致估计的规模偏大；0编号商业影响风险现状分析值识别结果B 01开发一个没有人真正需要的优秀产品或系统（市场风险）；1B 02开发的产品不再符合公司的整体商业策略（策略风险）；0B 03建造了一个销售部门不知道如何去卖的产品；0B- 04由于重点的转移或人员的变动而失去了高级管理层的支持（

14、管理风险）；0B- 05没有得到预算或人力上的保证（预算风险）。0B- 06交付期限不合理，导致不合理的开发计划；0B- 07政府对本产品开发的约束；0B- 08延迟交付所造成的成本消耗是多少；0B- 09本产品对公司的收入影响甚小；导致市场推广缺乏动力；0B- 10本项目是否有市场部门、产品规划部门的人员的参与；0B- 11项目是否受到了市场部门、产品规划部门的关注；0B- 15合作方的供货期、技术支持力度等方面存在不足B- 161编号客户相关风险现状分析值识别结果C 01没有和该客户合作的经历，导致在需求定义过程中与客户交流时不顺畅；1C 02客户不是很清楚需要什么、客户没有时间把需求写岀

15、来，导致无法得到客户明确的需求意图；0C- 03客户不同意花时间召开正式的需求收集会议，以确定项目范 围，导致项目范围不符合客户实际的想法；0C 04客户不愿意建立与开发者之间的快速通信渠道，导致在开发 过程存在的需求相关的问题无法及时得到客户的帮助；0C 05客户不愿意参加复审工作，导致在项目早期不能发现和客户的不一致；0C- 06客户不具有该产品领域的技术素养，导致提供的需求不准缺；0C- 07客户不愿意让项目组的人来做他们的工作，导致项目组无法真实的体验用户的需求，对客户需求的理解不深刻；0C- 08客户不了解软件过程，导致对项目提出不现实的期望；01编号过程风险现状分析值识别结果管理过

16、程风险D- 01高级管理层没有一份已经写好的政策陈述（该陈述中强调了 软件开发标准过程的重要性），导致项目组对软件开发标准 过程的重要性认识不够；1D- 02开发组织没有拟定一份已经成文的、用于本项目开发的软件 过程的说明，导致项目组对软件过程定义不清楚，导致软件 过程混乱；0D- 03开发人员不同意按照文档所写的开发过程进行开发工作，并0自愿使用它，导致开发过程混乱；D- 04开发过程不可以用于其它项目，导致？；0D- 05管理者和开发人员没有接受过一系列的软件工程培训，导致 项目开发过程无法得到良好理解和执行；0D- 06没有为每一个软件开发者和管理者提供及时可查询到的工 程标准，导致无法

17、及时查阅标准；0D- 07没有为作为软件过程一部分而定义的所有交付物建立文档 概要及示例，导致开发人员无法有效和便利的使用；0D- 08没有定期对需求分析报告、设计和编码进行正式的技术复 审，导致所存在的问题没有及时发现，将问题带入到下一个 阶段；0D- 09没有定期对测试过程和测试情况进行复审，导致；0D- 10是否对每一次正式技术复审的结果建立了文档，其中包括发现的错误及使用的资源；0D- 11有什么机制来保证按照软件工程标准来指导工作；0D- 12是否使用配置管理来维护系统/软件需求、设计、编码、测试用例之间的一致性；0D- 13是否使用一个机制来控制用户需求的变化及其对软件的影响；0D

18、- 14对于每一个承包出去的子合冋，是否有一份文档化的工作说 明、一份软件需求规约和一份软件开发计划；0D- 15是否有一个可遵循的规程，来跟踪及复审子合冋承包商的工作；01技术过程风险D- 50是否使用方便易用的规格说明技术来辅助客户与开发者之 间的通信；1D- 51是否使用特定的方法进行软件分析；0D- 52是否使用特定的方法进行数据和体系结构的设计；0D- 53是否90%以上的代码都是使用高级语言编写的；0D- 54是否定义及使用特定的规则进行代码编写；0D- 55是否使用特定的方法进行测试用例的设计；0D- 56是否使用配置管理软件工具控制和跟踪软件过程中的变化活动；0D- 57是否使

19、用工具来创造软件原型；0D- 58是否使用软件工具来支持测试过程；0D- 59是否使用软件工具来支持文档的生成和管理；0D- 60是否收集所有软件项目的质量度量值；0D- 61是否收集所有软件项目的生产率度量值；01编号技术风险现状分析值识别结果E 01该技术对于项目组而言是新的；1E 02客户的需求是否需要创建新的算法或输入、输出技术；0E 03待开发的软件是否需要使用新的或未经证实的硬件接口；0E 04待开发的软件是否需要与开发商提供的未经证实的软件产 品接口；0E 05待开发的软件是否需要与功能和性能均未在本领域得到证 实的数据库系统接口；0E 06产品的需求是否要求米用特定的用户界面；

20、0E 07产品的需求中是否要求开发某些程序构件，这些构件与你的 公司以前开发的构件完全不同；0E 08需求中是否要求米用新的分析、设计、测试方法；0E 09需求中是否要求使用非传统的软件开发方法；0E 10需求中是否有过分的对产品的性能约束；0E 11客户能确定所要求的功能是可行的吗？01编号开发环境风险现状分析值识别结果F 01没有可用的项目管理工具，导致项目管理工作效率低下；1F 02是否有可用的软件过程管理工具；0F 03没有可用的分析及设计工具，导致分析和设计工作效率低下；0F 04分析和设计工具不适用于待建造产品，导致分析和设计工作无法进行；0F 05是否有可用的编译器或代码生成器；

21、0F 06是否有可用的测试工具；0F 07是否有可用的软件配置管理工具；0F 08环境是否利用了数据库或数据仓库；0F 09项目组的成员是否接受过每个所使用工具的培训；0F 10疋否有专家冃匕够回答有关工具的冋题；0F 11工具的联机帮助及文档是否适当；0F 12是否有可用的操作系统；0F 13是否有可用的商用协议栈；01编号人员数目及经验相关的风险现状分析值识别结果G- 01是否有合适的人员可用；是1G- 02人员在技术上是否配套；0G- 03是否有足够的人员可用；0G- 04开发人员是否能够自始至终地参加整个项目的工作；0G- 05项目中是否有一些人员只能部分时间工作；0G- 06开发人员

22、对自己的工作是否有正确的期望；0G- 07开发人员是否接受过必要的培训；0G- 08开发人员的流动是否仍能保证工作的连续性；01项目特定风1险识别编号项目特定风险现状分析值识别结果H 01进度计划安排紧张，没有合理的缓冲时间0H 02任务分配可能存在不恰当的情况，有可能会影响进度0H- 03需求可能会发生变化，有可能会造成大量返工，从而影响 到项目的进度与质量0H- 040H- 050H- 060H- 070H- 080H- 090H- 1000233配置管理计划2.3.3.1. 配置项定义2.3.3.1.1. 配置管理工具采用运行在 Windows环境下的Microsoft Visual S

23、ourceSafe。按以下步骤搭建配置管理环境:1. 服务器端的安装2. 配置帐号3. 客户端的安装与配置4. 工具的具体操作2.3.3.1.2. 配置项标识过程域阶段活动交付物软件工程类需求需求分析软件需求规格说明书:需求确认需求评审报告需求管理需求跟踪表需求变更跟踪表原型开发原型开发系统原型:原型确认系统设计系统设计系统设计说明书数据库设计数据库设计说明书设计评审设计评审报告系统实现编码和单元测试源代码测试记录代码抽查问题跟踪表软件集成内测版本集成测试测试记录:缺陷记录测试报告系统测试测试方案编写测试方案测试计划编写测试计划测试用例编写测试用例执行系统测试测试记录缺陷记录测试报告交付版本系

24、统上线上线准备上线计划及方案系统切换上线报告试运行运行维护运行维护记录验收准备项目文档交付清单项目成果集试运行报告:提交验收申请验告 报 收 验项目管理-命 任 目 项交要 纪 议 会明 说 剪别 识 险 风告划 计 周控踪 跟 量 作 工告士口 纟 总结 总 i 项告项目支持量 定 制告告验m 目 项-告告表 理 处 与 请 申 更 变 管 更 变请 申 更 变表 理 处 与 请 申 更 变LL 审 更 变表 理 处 与 请 申 更 变施 实 更 变表 理 处 与 请 申 更 变变更验证变更跟踪表度量分析度量分析报告决策分析决策分析报告2.3.3.1.3.配置项命名规范2.3.3.1.3.1

25、. 使用范围适用于项目过程中编制的文档的命名。程序源代码、目标代码、执行程序的文件编制参照相关编程语言的程序命名规范2.3.3.1.3.2. 命名规则1纳入基线前的命名规则：vSGCC 项目简称 文档名称 文档时间 信息2、纳入基线的命名规则：SGCC 项目简称 文档名称 版本号2.3.3.1.3.3. 文档时间信息格式为YYYYMMDD在文档没有纳入基线前，要求对文档采纳时间信息。2.3.3.1.3.4. 版本定义1、主版本号设置时间：本项目中发布的文档产品通过正式评审及正式对外发布时，或未发布前的初始化设置人员：配置管理员；设置规则：1）新产品发布，主版本号为1；2） 产品的主体构件进行重

26、大修改，主版本号加1 ；3）产品的主体构件之间的接口协议修改，主版本号加；4） 主版本号变更时，副版本号同时置 0。2、副版本号 设置时间：产品发布及版本更新时;设置部门：配置管理员；设置规则：1）新产品发布，副版本号为 0；2）对现有功能模块做重大修改，副版本号加 1；3）改进现有功能模块，不增加新的功能模块，产品的主体构件未做重大修 改，副版本号加 1；4）为增加产品功能，在原版本产品上增加新的功能模块，而产品的主体构 件未做重大修改，并且产品的主体构件之间的按口协议也未做修改，副版本号加 1；5）当主版本号变更时，副版本号同时置 0。3、版本编号说明VX.Y说明： V 是版本标识X 是主

27、版本号Y 是副版本号2.3.3.1.4.配置库目录结构在本项目中采用VSSS行文档管理。配置库01客户资料02前期项目资料#01参考资料03项目资源04其他01需求02开发库03基线库04产品库2.3.3.1.5.配置库结构说明02原型开发*03系统设计04系统实现05系统测试06上线/试运行07管理01需求02计划03设计04测试01软件产品* 02发布版本程序03文档一级目录名 称二级目录名 称三级目 录名称存放内容目录变更情况权限01参考资 料主要是项目组共同共享、 且是可以经常查询参考 的资料只要有需要，该目 录下的下层目录 是可以添加的，提 出需求，统一由配 置管理员操作项目组成 员

28、都有读 的权限、配置管理 员有添加、删除 和维护的 权限01客户资料存放客户的联系信息，客 户提供的前期的原始资 料02前期项目 资料售前的项目资料03项目资源项目组公共性的资源， 将公共性的内容抽出来 放在这个路径下便于查 询01项目通讯 录包括项目组、客户、监理、 厂商等通讯方式02文档模板所有项目的文档模板，下 面可以再分子目录04其他可以存放类别名称不好 疋义的公共文档02开发库工程类文档的公共开发 库下面的子目录可 以根据生命周期 模型的阶段不同 进行调整配置管理 员有目录 维护、读、 增、删的 权限项目组都 有读、添 加、删除 文件的权 限01需求需求阶段产生的成果性 文档01需求

29、调研存放需求调研阶段相关 的资料，以及在需求分析 阶段对需求进行确认的 会议记录，包括有客户参 与的会议记录、评审会议 记录02需求分析需求分析阶段的成果性 文档，可以是阶段性的成 果，不疋疋取终版本。03需PV/AxV -rrrt 求官理包括需求变更和需求跟 踪的文档02原型开发原型03系统设计存放设计阶段的成果性 文档，包括：数据库设计 说明书、系统设计说明书 等文档。：04系统实现:庶装手册，用户手册T05系统测试包括测试计划、测试用例 和测试报告06上线/试运 行上线过程中的文档07管理与项目有关的管理类文 档03基线库操作和维 护权限都 是配置管 理员，其 他的人员 只有读权 限01

30、需求需求得到用户的确认，就 纳入基线管理；如果需求 发生很大的变更需要重 新建立基线，需要以基线 为标准进行跟踪有配置管理员根 据基线计划进行 跟踪和入库管理02计划经过用户评审并通过的 项目计划需要建立基线， 可以根据基线对项目进 行跟踪基线都是可以变 更的03设计用户确认后的应用系统 设计说明书基线都是可以变 更的04测试用户确认的测试计划和 相关文档基线都是可以变 更的04产品库配置管理 员具有所 有权限，其他人只 有读权限01软件产品软件发布的可安装软件 产品，发布后如果有大的 改动，再次发布时需要变 换版本号配置管理员进行 出入库操作，其他 人要取必须提出 申请02发布版本 程序发布

31、版本的源代码配置管理员进行 出入库操作，其他 人要取必须提出 申请03文档发布时提交给用户的文 档，包括用户使用说明书配置管理员进行 出入库操作，其他 人要取必须提出 申请2.3.3.1.6.操作权限整个配置管理库由参考资料、开发库、基线库、产品库共 4 个库组成。 参考资料 ：主要存放大家都经常查看的一些资料，比如客户的资料、项目组的一 些资料，该库的权限大家都有读的权限，但客户的资料和前期项目资料只有配置管理 员和核心组人员有其他一些处理权限。开发库： 存放开发过程中需要保留的各种信息，主要目的方便项目组成员个人使 用。库中的信息可能有较为频繁的修改，无需进行严格的控制。本项目中，各配置项

32、 的责任人具有 check in 、check out 和读权限，其他人员仅有读权限。还存放管理方 面的文档和质量保证员或配置管理员操作的一些支持工作方面的文档。 主要操作者是 项目经理或项目核心组人员，其他人员都是可以查看的。如果根据需要项目组的某些 人员需要其他权限，可以先申请进行开通。基线库 ：存放已定义的基线，基线必须进行严格的控制，由配置管理员负责管理 与维护。本项目中，配置管理员具有 check in 、 check out 和读权限，其他人员均只 有读权限。产品库： 存放需要交付给用户的且经过测试、评审的产品。也需要一定的控制， 由CM员负责管理与维护。本项目中，配置管理员具有

33、check in、check out和读权限, 其他人员均只有读权限 。2.3.3.2.配置项管理活动2.3.3.2.1.版本控制 采用开发主线的方式进行版本管理 无需修改的配置项（如部分记录、报告、总结等）直接提交配置管理服务器相应模块下的工作目录内， 由配置管理服务器自动管理 版本，配置项本身不必体现版本号的记录。可能修改的配置项（大部分的成果性文档、提交客户的文档） 配置项本身必须体现版本号的记录； 对已提交配置管理服务器配置项的修改， 必须先从配置管理服务器上检出该配 置项，对检出的配置项进行修改；检出修改之前， 必须先察看是否有人正在操作 （修改）此配置项， 有人操作时， 不准检出修

34、改；检出配置项修改后再次提交配置管理服务器时，版本按照前面的版本定义的规 定管理；本地初次生成版本用时间信息控制；检出版本vx.y，检出后本地修改版本用时间信息控制；未提交配置管理服务器的配置项或文档、资料（即本地的文档及资料），按照 时间信息的方式管理版本；提交配置管理服务器的配置项（即 vss上的文档及资料），按照vx.y的方式 管理版本。2.3.3.2.2.基线管理2.3.3.221.基线定义序 号基线名称阶段基线内容基线生 成时间批准人审核人 （配置管 理员）1需求基线需求阶段软件需求规格说明书 原型需求基 线评审 通过后项目经理配置管理 员2计划基线计划阶段项目总体计划 进度计划配置

35、管理计划 质量保证计划计划评 通过审 后项目经理配置管理 员3设计基线设计阶段应用系统设计说明书数据库设计说明书设计基 线评审 通过后项目经理配置管理 员4测试基线测试阶段测试用例测试报告测试基 线评审 通过后项目经理配置管理 员5产品基线 （存放在产品库）上线阶段软件产品 程序源码 安装手册 用户手册用户验 收通过 后项目经理配置管理 员2.3.3.2.2.2.配置项审计配置项审计在配置管理中占很重要的位置，它是项目过程相关的配置项集合的审查。根据审计内容和审计对象的不同可以把基线审计分为物理审计、功能审计，形成 基线审计报告：物理审计：主要考察偏差，完整性检查、版本是否正确。参加人员：项目

36、经 理、质量保证员、配置管理员。功能审计：主要考察功能是否实现。参加人员：项目经理、质量保证员、配置管理员、测试人员进行以下的审计审计形式时间审计内容召集人参与人员物理审计每两个月进行配置检查，看配置内容是否完整质量保证员项目经理、质量保证员、配置管理员。功能审计上线前考察功能是否实现质量保证员项目经理、质量保证员、配置管理员、测试人员。2.3.3.223.配置项状态报告受控库（基线库和产品库）配置项出入库填写配置项状态报告并通过邮件发布出入库通知。2.3.3.224.基线变更参见变更管理程序2.3.3.2.3.出入库控制2.3.3.2.3.1. 入库受控库（基线库和产品库）配置项入库规程：1

37、、入库申请申请人直接或通过邮件向配置管理员提交入库申请，经入库审查之后，由配置管理员将配置项入库。2、入库审查配置管理员对配置项进行完整性、正确性的审查。3、入库登记与通知配置管理员执行入库操作，同时填写配置项状态报告，通过邮件发布入库通知。2.3.3232 出库受控库（基线库和产品库）配置项出库规程：1、出库申请申请人直接或通过邮件向配置管理员提交出库申请，经出库审查之后，由配置管理员将配置项出库。2、出库审查配置管理员对配置项进行完整性、正确性的审查。3、出库登记与通知配置管理员执行出库操作，同时填写配置项状态报告，通过邮件发布出库通 知。2333备份本项目的配置管理备份方案：1. 保持配

38、置数据库的大小不超过5G;2. 备份频率：每月进行VSS库的完全备份，并将备份文件备份至文档服务器指 定目录。3. 备份检查：不定期进行备份文件的文件恢复测试，确保备份文件的有效性。2.3.4质量保证计划2.3.4.1.项目SQA参与的项目活动项目实施阶段SQ鮎动项目工作产品过程计划阶段项目过程、工作产品检查；项目周例会项目任务书、项目策划跟 踪记录表、项目定义软件过 程、项目 WBS、项目开发 计划、项目沟通计划、风险管理计划、成本控制计划、培训计划策划过程培训过程同行评审过程跟踪与监控过程需求开发与管理阶段项目过程、工作产 品检查；项目周例会用户需求调研报告、需求 调查表、软件需求规格说明

39、书、需 求评审记录、用例同行评审记 录里程碑评审报告、会议记 录需求管理过程策划过程培训过程同行评审过程 跟踪与监控过 程SPE （测试）系统设计阶段项目过程、工作产品检查；项目周例会概要设计说明书、数据库 设计说明书、用户界面设计 说明书、详细设计说明书、设计评审记录、里程碑评 审报告、会议记录、用 例同行评审记录需求管理过程策划过程培训过程同行评审过程 跟踪与监控过 程SPE（设计、测 试）编码阶段项目过程、工作产 品检查；项目周例会技术攻关报告、软件实现 计划、代码审查报告、 单 元测试计划、单元测试用例、单元测试报告SPE（编码）需求管理过程计划过程培训过程同行评审过程跟踪与监控过程测

40、试阶段项目过程、工作产 品检查；项目周例会测试计划（系统、集成）、测 试用例（系统、集成）、测 试总结报告、BUG艮踪管理表、会议记录SPE （测试）需求管理过程策划过程培训过程同行评审过程 跟踪与监控过 程软件发布发布产品配置审计软件产品发布审批表、项 目联系记录单、用户手册、安装维护手册SCMi 程SQA程SPE （产品发布）客户培训过程、工作产品检培训计划、培训签到表、TP过程查培训考核表、培训总结报告试运行过程、工作产品检查试运行计划、试运行问题 管理表、BU跟踪管理表、试运行总结项目验收工作产品检查验收计划、测试大纲，验收测试 报告（草稿），项目工作报告（草 稿），验收报告（草稿）、客户验收 测试报告、验收报告项目总结工作产品检查项目总结报告日常记录工作产品检查项目周报、数据采集表事件驱动里程碑会议、配置项发生变更里程碑会议记录、需求变更分析报告、需求变更记录表、配置项 变更申请单、配置项出入库单、配置项变更记录表、配置项变更 通知、配置状态报告、SCM库备份 记录表2.3.4.2. SQA活动计划质量保证人员的活动计划活动活动时机输出日常审核不定期的进行不一致问题一览表事件驱动按照开发计划、项目里程碑点不一致问题一览表定期审核每周两次不一致问题一览表2.3.4.3.收集度量数据