某科技有限责任公司项目管理标准概述.docx

《某科技有限责任公司项目管理标准概述.docx》由会员分享，可在线阅读，更多相关《某科技有限责任公司项目管理标准概述.docx（92页珍藏版）》请在三一办公上搜索。

1、北京雅龙汉正科技有限责任公司项目管理标准北京雅龙汉正科技有限公司 2008年1月更改履历版本号修改编号更改时间更改的图表和章节更改简要描述更改人批准人注：更改人除形成初稿，以后每次修改在未批准确认前均需采用修订的方式进行修改。目 录1. 概述41.1. 编写目的41.2. 项目背景51.3. 建设目标62. 项目计划管理72.1. WBS(工作分解结构)分解72.2. 项目基线计划92.2.1. 项目基线计划92.2.2. 基线评审计划102.3. 项目附属计划112.3.1. 沟通计划112.3.2. 风险管理计划122.3.3. 配置管理计划192.3.4. 质量保证计划302.4. 项目

2、阶段计划342.5. 项目实施采用的平台软件363. 项目实施作业标准373.1. 项目实施过程工作项373.2. 项目实施作业标准393.2.1. 项目启动阶段393.2.2. 项目策划阶段463.2.3. 项目开发阶段493.2.4. 工程实施阶段514. 附件874.1. 测试验收相关附件874.1.1. 附件1:测试结果签字确认授权书格式874.1.2. 附件2:最终验收意见提纲894.1.3. 附件3：测试准备工作确认表914.1.4. 附件4：提交的最终验收材料签收表921. 概述编制本计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、所需软、硬件条件及可能

3、遇到的问题瓶颈等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开发与实施工作。2. 项目计划管理2.1. WBS(工作分解结构)分解项目总体目标2008年12月30日完成基础业务系统推广、新建项目试点开发、实施分类一级任务二级任务软件工程新建系统原型开发设计原型框架原型框架确认原型开发原型确认需求调查需求调研需求整理(业务差异、实用化需求)需求分析(差异需求报告)需求确认(报送监控组审批)需求管理(纳入基线)UE/UI设计设计UE/UI框架UE/UI框架确认UE/UI开发UE/UI确认系统设计设计原则讨论设计原则内部确认系统总体设计应用系统概要设计(用例规划设计)数据库完善设计应用系

4、统详细设计(用例实现设计和实体类设计)Activex控件设计内部评审客户确认系统实现编码和单元测试代码抽查软件集成集成测试编写用户手册系统测试测试方案编写测试计划编写测试用例编写测试环境准备(项目现场仿真环境)执行系统功能测试压力测试试点单位上线试运行培训数据移植准备数据移植试运行前测试试点单位开始试运行试运行试点单位初步验收试点结束项目单位推广阶段项目推广开始项目推广单位培训推广单位数据移植准备推广单位数据移植推广单位试运行前测试推广单位开始试运行推广单位试运行推广结束项目管理项目启动项目策划项目监控项目结项项目周报和下周计划内部周例会网省(自治区)周例会人力外包项目支持质量保证配置管理变更

5、管理培训2.2. 项目基线计划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应用系统概要设计15数据库完善设计20应用系统详细设计45Activex控件设计5内部评审5客户确认5产品系统实现90系统测

6、试20试点单位上线试运行60文档输出文档318备注：2.2.2. 基线评审计划2.2.2.1. 基线评审时间计划基线产品计划评审时间主要参加人员方式标设成果原型项目主管、项目经理、质量保证员、项目组成员、 需求项目主管、项目经理、质量保证员UE/UI设计项目主管、项目经理、质量保证员、项目组成员系统设计项目经理、质量保证员、项目组成员产品项目经理、质量保证员、项目组成员文档项目经理、质量保证员、项目组成员2.2.2.2. 基线评审报告模版项目名称(编号)会议室审查日期预期评审速率分钟/页开始时间结束时间工作产品信息序号名称作者版本大小（页）检查表标准1有没有2345评审人员姓名角色缺席检查准备

7、时间（小时）12345是是相关文档名称版本存档位置2.3. 项目附属计划2.3.1. 沟通计划2.3.1.1. 基于问题的沟通计划问题类型沟通对象方式需求变更管理控制组、项目经理、项目主管、公司分管领导变更委员会会议总体计划变更管理控制组、项目经理、项目主管、公司分管领导会议基线变更管理控制组、项目主管、项目经理、配置管理组变更委员会会议人员变动管理控制组、项目主管书面2.3.1.2. 日常沟通计划沟通对象内容方式时间 管理控制组、项目组成员项目进展及问题周例会每周管理控制组、项目主管、公司分管领导项目进展及问题月述职每月2.3.1.2.1. 周例会工作计划单体项目负责人项目总负责人报送周期工

8、作周报每周五下午10点前每周日中午12点前一级/二级组成立开始，撤销终止项目实施经理总体项目负责人报送周期项目日报每天下午10点前项目启动会开始，合同签订终止项目周报每周五下午10点前每周一中午12点前项目启动开始，项目终止结束项目月报每月最后1工作日中午12点前合同签订开始，项目终止结束客户周报每周五下午10点前每周一中午12点前项目启动开始，项目终止结束客户月报每月最后1工作日中午12点前项目启动开始，项目终止结束2.3.1.3. 与内蒙客户的沟通计划2.3.1.3.1. 时间表编号沟通内容时间方式1项目启动2008年3月会议2项目整体计划2008年3月文档3调研计划2008年3月文档4需

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

10、理就是在一个项目中通过过程和工具来对风险进行识别,跟踪和控制的手段。提供了对可能出现的风险进行持续评估，确定重要的风险以及实施处理风险的策略的一种规范化的环境。合理的风险管理应尽力减少风险的发生概率；如果发生，则应尽力缩小其影响程度。3风险识别是要对各个相关领域进行检查，以便发现风险并记录下来。3风险分析是对每一项已识别的风险进行研究，以精确描述风险，分析出风险产生的原因、概率并确定其产生的影响（成本、进度、技术）。4风险参数包括风险发生的概率、影响的严重程度，以及风险值；风险值是概率和影响严重程度的乘积，以上具体参见风险管理列表5风险类别按照风险可能导致的影响方面对风险进行的分类。如成本、进

11、度、质量。6问题管理将已经转化成问题的风险记录到项目问题管理表 2.3.2.2. 角色与职责序号角色职 责说明1项目经理负责项目的风险管理计划、风险管理活动的实施和总结2项目组成员在项目经理的带领下，参与风险管理活动3项目机构参加评审风险值2的风险的缓解措施4项目组收集在风险管理活动中的经验教训。2.3.2.3. 流程图2.3.2.4. 风险识别一般性风险识别编号产品规模风险具体风险描述现状分析值风险趋势后果缓解措施应对措施识别结果A01没有充分估算产品的规模，导致估算的结果缺乏客观依据； 1A02对于估算出的产品规模的不可信或可信度极底，导致规模估算的结果的偏大或者偏小； 1A03没有以程序

12、、文件或事务处理的数目来估算产品规模，导致规模估算的结果缺乏客观依据； 1A04估算产品规模与以前产品的规模的平均值存在较大偏差，导致估算结果可信度低； 0A05产品创建或使用的数据库过大，导致估计的项目规模偏小； 0A06产品的用户数过多，远远超过预期数，导致估计的规模过小； 0A07产品的需求改变太多 ，导致估计的规模不准确；0A08没有考虑可重用构件的设计开发，导致估计的规模偏大 ；0编号商业影响风险现状分析值识别结果B01开发一个没有人真正需要的优秀产品或系统（市场风险）；1B02开发的产品不再符合公司的整体商业策略（策略风险）；0B03建造了一个销售部门不知道如何去卖的产品；0B04

13、由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；0B05没有得到预算或人力上的保证（预算风险）。 0B06交付期限不合理，导致不合理的开发计划； 0B07政府对本产品开发的约束；0B08延迟交付所造成的成本消耗是多少； 0B09本产品对公司的收入影响甚小；导致市场推广缺乏动力； 0B10本项目是否有市场部门、产品规划部门的人员的参与；0B11项目是否受到了市场部门、产品规划部门的关注；0B15合作方的供货期、技术支持力度等方面存在不足B161编号客户相关风险现状分析值识别结果C01没有和该客户合作的经历，导致在需求定义过程中与客户交流时不顺畅； 1C02客户不是很清楚需要什么、

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

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

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

17、否有一份文档化的工作说明、一份软件需求规约和一份软件开发计划； 0D15是否有一个可遵循的规程，来跟踪及复审子合同承包商的工作；01技术过程风险D50是否使用方便易用的规格说明技术来辅助客户与开发者之间的通信； 1D51是否使用特定的方法进行软件分析； 0D52是否使用特定的方法进行数据和体系结构的设计； 0D53是否90以上的代码都是使用高级语言编写的； 0D54是否定义及使用特定的规则进行代码编写； 0D55是否使用特定的方法进行测试用例的设计； 0D56是否使用配置管理软件工具控制和跟踪软件过程中的变化活动； 0D57是否使用工具来创造软件原型； 0D58是否使用软件工具来支持测试过程；

18、 0D59是否使用软件工具来支持文档的生成和管理； 0D60是否收集所有软件项目的质量度量值； 0D61是否收集所有软件项目的生产率度量值；01编号技术风险现状分析值识别结果E01该技术对于项目组而言是新的； 1E02客户的需求是否需要创建新的算法或输入、输出技术； 0E03待开发的软件是否需要使用新的或未经证实的硬件接口； 0E04待开发的软件是否需要与开发商提供的未经证实的软件产品接口； 0E05待开发的软件是否需要与功能和性能均未在本领域得到证实的数据库系统接口； 0E06产品的需求是否要求采用特定的用户界面； 0E07产品的需求中是否要求开发某些程序构件，这些构件与你的公司以前开发的构

19、件完全不同； 0E08需求中是否要求采用新的分析、设计、测试方法； 0E09需求中是否要求使用非传统的软件开发方法； 0E10需求中是否有过分的对产品的性能约束； 0E11客户能确定所要求的功能是可行的吗？ 01编号开发环境风险现状分析值识别结果F01没有可用的项目管理工具，导致项目管理工作效率低下； 1F02是否有可用的软件过程管理工具； 0F03没有可用的分析及设计工具，导致分析和设计工作效率低下； 0F04分析和设计工具不适用于待建造产品，导致分析和设计工作无法进行； 0F05是否有可用的编译器或代码生成器； 0F06是否有可用的测试工具； 0F07是否有可用的软件配置管理工具； 0F0

20、8环境是否利用了数据库或数据仓库； 0F09项目组的成员是否接受过每个所使用工具的培训； 0F10是否有专家能够回答有关工具的问题; 0F11工具的联机帮助及文档是否适当；0F12是否有可用的操作系统；0F13是否有可用的商用协议栈；01编号人员数目及经验相关的风险现状分析值识别结果G01是否有合适的人员可用； 是1G02人员在技术上是否配套； 0G03是否有足够的人员可用； 0G04开发人员是否能够自始至终地参加整个项目的工作； 0G05项目中是否有一些人员只能部分时间工作； 0G06开发人员对自己的工作是否有正确的期望； 0G07开发人员是否接受过必要的培训； 0G08开发人员的流动是否仍

21、能保证工作的连续性； 01项目特定风险识别编号项目特定风险现状分析值识别结果H01进度计划安排紧张，没有合理的缓冲时间0H02任务分配可能存在不恰当的情况，有可能会影响进度0H03需求可能会发生变化，有可能会造成大量返工，从而影响到项目的进度与质量0H040H050H060H070H080H090H10002.3.3. 配置管理计划2.3.3.1. 配置项定义2.3.3.1.1. 配置管理工具采用运行在Windows环境下的Microsoft Visual SourceSafe。按以下步骤搭建配置管理环境：1. 服务器端的安装2. 配置帐号3. 客户端的安装与配置4. 工具的具体操作2.3.3

22、.1.2. 配置项标识过程域阶段活动交付物软件工程类需求需求分析软件需求规格说明书 需求确认需求评审报告需求管理需求跟踪表需求变更跟踪表原型开发原型开发系统原型原型确认系统设计系统设计系统设计说明书数据库设计数据库设计说明书设计评审设计评审报告系统实现编码和单元测试源代码测试记录代码抽查问题跟踪表软件集成内测版本集成测试测试记录缺陷记录测试报告系统测试测试方案编写测试方案测试计划编写测试计划测试用例编写测试用例执行系统测试测试记录缺陷记录测试报告交付版本系统上线上线准备上线计划及方案系统切换上线报告试运行运行维护运行维护记录验收准备项目文档交付清单项目成果集试运行报告提交验收申请组织验收评审验

23、收确认验收报告项目管理项目启动下达项目确认书项目确认书项目任命项目任命书项目资料移交项目相关资料资料清单召开项目启动会议会议纪要项目策划项目过程定义项目过程裁剪说明项目估算项目估算表风险识别风险管理计划编制项目总体计划项目总体计划总体计划评审计划评审报告编制辅助计划质量保证计划配置管理计划编制阶段计划阶段计划编制周计划周计划项目监控问题跟踪问题跟踪表工作量跟踪项目周报风险跟踪风险跟踪表阶段总结阶段总结报告周总结项目周报项目结项项目成果整理项目成果项目总结项目总结报告提交成果项目成果交付清单结项确认结项确认书项目支持质量保证制定质量保证计划质量保证计划质量保证报告质量保证活动阶段报告评审问题跟踪

24、问题跟踪表问题上报问题上报单检查活动需求管理检查表需求活动检查表系统设计检查表系统测试检查表系统上线检查表验收检查表项目计划检查表项目监控检查表里程碑检查表结项检查表配置管理制定配置管理计划配置管理计划跟踪配置状态配置状态报告配置审计配置审计报告配置项变更变更申请与处理表产品发布变更管理变更申请变更申请与处理表变更审批变更申请与处理表变更实施变更申请与处理表变更验证变更跟踪表度量分析度量分析报告决策分析决策分析报告2.3.3.1.3. 配置项命名规范2.3.3.1.3.1. 使用范围适用于项目过程中编制的文档的命名。程序源代码、目标代码、执行程序的文件编制参照相关编程语言的程序命名规范。2.3

25、.3.1.3.2. 命名规则1、 纳入基线前的命名规则：2、 纳入基线的命名规则：2.3.3.1.3.3. 文档时间信息格式为YYYYMMDD。在文档没有纳入基线前，要求对文档采纳时间信息。2.3.3.1.3.4. 版本定义1、主版本号设置时间：本项目中发布的文档产品通过正式评审及正式对外发布时，或未发布前的初始化设置人员：配置管理员；设置规则：1）新产品发布，主版本号为1；2）产品的主体构件进行重大修改，主版本号加1；3）产品的主体构件之间的接口协议修改，主版本号加；4）主版本号变更时，副版本号同时置0。2、副版本号设置时间：产品发布及版本更新时；设置部门：配置管理员；设置规则：1）新产品发

26、布，副版本号为0；2）对现有功能模块做重大修改，副版本号加1；3）改进现有功能模块，不增加新的功能模块，产品的主体构件未做重大修改，副版本号加1；4）为增加产品功能，在原版本产品上增加新的功能模块，而产品的主体构件未做重大修改，并且产品的主体构件之间的按口协议也未做修改，副版本号加1；5）当主版本号变更时，副版本号同时置0。3、版本编号说明VX.Y说明：V 是版本标识 X 是主版本号 Y 是副版本号2.3.3.1.4. 配置库目录结构在本项目中采用VSS进行文档管理。2.3.3.1.5. 配置库结构说明一级目录名称二级目录名称三级目录名称存放内容目录变更情况权限01 参考资料主要是项目组共同共

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

28、限项目组都有读、添加、删除文件的权限01 需求需求阶段产生的成果性文档01 需求调研存放需求调研阶段相关的资料，以及在需求分析阶段对需求进行确认的会议记录，包括有客户参与的会议记录、评审会议记录02 需求分析需求分析阶段的成果性文档，可以是阶段性的成果，不一定是最终版本。 03 需求管理包括需求变更和需求跟踪的文档02 原型开发原型03 系统设计存放设计阶段的成果性文档，包括：数据库设计说明书、系统设计说明书等文档。04 系统实现安装手册，用户手册05 系统测试包括测试计划、测试用例和测试报告06 上线/试运行上线过程中的文档07 管理与项目有关的管理类文档03 基线库操作和维护权限都是配置管

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

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

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

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

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

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