项目管理体系(完整版).docx

《项目管理体系(完整版).docx》由会员分享，可在线阅读，更多相关《项目管理体系(完整版).docx（56页珍藏版）》请在三一办公上搜索。

1、1 项目管理方法1.1 项目管理原则项目管理是指在执行质量保证体系的基础上，在人力资源和组织、计划、质量控制、资源协调、财务、风险控制等方面进行科学地管理，确保该项目如期、高质量地完成。我公司在多年的软件开发过程中，不断吸取国际先进的项目管理理念，并结合自身的特点，形成了一整套行之有效的管理方法，并形成了标准、规范、受控的配套文档体系。根据我公司的软件工程的管理规范要求，软件项目根据适用的生命周期模型分为开发项目和维护项目，根据项目所面对客户，分为产品研发和合同项目开发。对于本项目而言，属合同项目开发，我们进一步按照本章开始时划分的阶段将之分解为两个子项目：第一阶段以研发为主，属开发项目，第二

2、阶段以推广、升级、维护为主，属维护项目。下面我们从项目组织架构、软件生命周期模型、项目管理关键阶段、项目管理关键活动等方面细述对本项目的项目管理计划。1.2 组织架构在一个大型系统集成项目中，为了保证工程的顺利进行，需要建立相应的开发和管理机构，其典型的结构如下图所示：在项目实施的组织结构中，各小组的职责如下： 工程领导组是XXXX项目实施中双方协同工作的最高管理机构，是由参与工程的双方领导组成，对项目的重大事件进行决策并对项目全过程进行监督及协调，保障项目人、财、物力等基础资源，凡由双方人员参与的各组织机构均在其领导下工作并对其负责。 项目经理负责项目的实施，组织、协调并监督各工程组的工作情

3、况及进度，对工程领导组负责，对具体方案具有决定权，并负责计划与控制、人员配置管理和工程进度等工作。 项目评议组由业务、运行维护以及各方面的专家组成，负责对项目的可行性、成本收益、进度、质量等进行评议作业。 质量控制组由用户主要负责部门的工作人员与承建方人员组成，直接对项目经理负责，对应用程序编制及测试过程、内容、结果进行审查和评估，具有质量否决权。 系统需求组由用户方主要负责部门的技术人员和相关部门的工作人员与承建方的技术人员组成，对系统各项业务需求做作出总体描述，提交技术和业务部门共同论证，形成正式业务需求。 总体设计组由用户方信息化技术负责人与承建方的技术专家、顾问咨询人员构成，负责系统结

4、构设计、系统需求、技术管理、系统模块设计。还包括对开发小组的协调等工作。 开发小组主要由承建方的技术工程师构成，负责子系统详细设计、编码等工作。 测试小组主要由承建方的技术人员构成，负责编写测试方案、系统测试及编写测试报告。用户方的业务工作人员及技术人员协助对系统的运行进行测试。 系统集成组主要由承建方的技术工程师组成，负责系统硬件、网络、软件及开发工具技术支持、技术培训支持。 文档管理组主要由承建方的技术人员组成，完成整个项目过程中的所有文档、资料、技术报告、软件介质的管理。 后勤保障组主要由承建方的人员组成，负责合同管理、材料管理、后勤保障等。上述组织及职责划分根据项目进展情况由工程领导组

5、及项目经理负责启动并调整，在项目经理领导下各组由参与工程各方根据工程需要分配人员，各方应在项目实施阶段保持人员的稳定性，确保工程按计划实施。1.3 项目管理控制项目管理是贯穿整个咨询项目的一项任务。通过实施有效的项目管理，保证本咨询项目能够按工作范围要求、按时间、按质量完成。在我公司的项目管理过程中包含以下这些关键性活动，每一个项目经理必须执行和良好的完成这些任务。n 项目计划、执行和监控n 制定周密完整的项目计划，定义项目任务、子任务及任务的依赖关系、顺序、时间、资源安排n 控制项目按计划执行，对出现的偏差做出必要的纠正措施n 监督、确认项目当前状态n 项目协调与沟通n 针对项目时间、进度、

6、任务执行情况、资源、各方配合等方面协调项目组与用户项目组的关系；协调项目组内部关系n 每周召开项目组内部例会 针对项目计划、进度、任务完成情况、出现问题、各方配合等方面与用户方进行沟通，每周向用户方负责人提交书面项目情况通报；每两周与用户方管理层开一次项目协调会，通报项目状态，协调处理项目待解决问题；每月提交项目月度报告，汇报每月项目进展、下月计划、待解决问题等 对于项目组无法解决的问题提交到双方管理层n 风险管理n 制定风险防范计划n 监控项目情况，发现潜在风险n 评估、定义风险的范围、影响n 制定风险防范策略，执行风险防范措施n 质量管理n 制定并执行项目质量计划n 制定项目质量标准和规范

7、n 制定项目质量流程n 组织项目质量活动，如设计文档审查、测试等n 监督项目质量标准和规范的执行情况；对出现的偏差作出适当判断，制定相应的纠正措施n 制定项目测试计划，保证测试执行的质量n 文档管理，包括文档命名、规范、版本的控制，文档归档和分发n 变更管理n 制定变更管理计划（任务、流程、责任、组织）n 变更识别、确认n 变更范围及其影响评估n 应变措施制定n 应变措施执行及记录n 其他n 定义项目组织结构、所需人员，有效组织全体项目成员投入项目工作中，保证项目资源的有效使用n 有效控制项目费用n 对项目全程执行我公司规定的涉密管理标准规范其中进度控制管理、质量管理、风险管理、涉密管理由于其

8、重要性而具有特殊意义，在以下各节加以描述。1.3.1 项目进度控制1.3.1.1 项目进度管理的原则要求全体成员积极主动，在项目进展中，遇到问题主动找相关人员解决，若解决不得力而又确实属此人管的，则应及时向上一级反映，不得以任何借口推脱不按进度计划完成任务，除非确实是技术上不可解决的，即便如此，也应尽早汇报，以免影响整体进度。1.3.1.2 项目进度管理的方法在开始实施项目时，项目经理必须根据任务情况做好进度安排计划，按周做计划以书面呈交项目协调委员会，以周为单位做计划以书面形式下达各组，各组分头安排落实到个人，组长或个人在接到计划书时，认为恰当，则签字；若认为不恰当，必须及时陈述理由，否则责

9、任自负。在计划时间到时，项目经理严格按照进度计划书验收。在验收合格情况下，项目经理在原下达的计划书上签字，并结合完成任务情况给出一定的评价，将来作为奖励晋级的参照依据；若验收不合格，则责成3日内修正，若仍不能完成必须以书面形式说明理由，项目经理依情况处理。在每次验收都合格或者在责成期限内都合格的情况下，若项目不能及时完成，则责任应在项目经理身上，项目经理必须以书面形式向项目协调委员会陈述理由。1.3.1.3 项目沟通机制管理交流有助于解决问题，尤其是在研究开发、系统集成等项目组之间，具有更频繁和更公开交流过程的组织在新产品开发过程中比那些交流不太频繁和封闭的组织有更大的创新倾向。针对本项目的特

10、殊性多方参与，沟通机制更为重要。沟通畅通能融多方智慧，促进项目成功；沟通阻塞，则障碍重重、举步维艰，这方面我们是有教训的，也是有经验的。项目实施组作为沟通畅通的领头羊，制订相关计划，定期举行项目组和用户的交流会，建立和保持与主要利益相关者的关系，做到双向沟通；定期安排项目组内部各小组之间的相互交流；在日常工作中，营造相互学习共同成长的氛围。1.3.1.4 资料文档的管理为保证系统的建设和正常运行，我们将提供如下几类资料和文档。一、产品类l 硬件资料l 系统软件及开发工具资料l 其他相应产品资料二、工程类l 系统需求规格书l 逻辑设计文档l 系统结构设计文档l 数据库设计文档l 接口需求说明书l

11、 接口设计文档l 程序详细设计说明书l 系统故障处理流程文档三、计划与测试类l 项目开发与管理计划l 项目实施计划l 系统开发标准手册l 测试计划及测试标准l 测试结果报告l 验收计划及验收标准l 验收结果报告四、技术支持与维护类l 应用系统用户手册l 系统操作员手册l 系统运行手册l 网络操作手册l 网络接口手册l 系统接口标准l 故障处理和恢复手册上述各类文档资料由专人负责归档，后三类文档需经项目经理签字有效。1.3.1.5 项目实施规划本阶段主要目标是制定项目的实施计划，详细项目计划的制定，定义主要的工作包、里程碑和项目进度安排。内容如下：开始标准结束标准项目文档工作综述项目文档签署功能

12、规范签署分析阶段工作计划技术体系结构签署确定项目发起人实施计划确定项目关键成员，并制定时间表用户需求定义、访谈、反馈、汇总接收标准得到认可用户需求文档得到确认和接受编写项目设计概要设计及详细设计文档得到确认和接受项目编码提交用户可以测试的系统项目上线用户验收系统1.3.1.6 需求调研与分析1.3.1.6.1 需求调研1业务需求调研对电子税收信息管理系统的业务功能、用户情况、安全和性能需求进行全面的调研。业务需求调研包括以下方面的内容： 用户数； 用户管理模式； 系统的使用模式； 系统功能需求； 系统安全要求； 系统管理需求； 与其它系统的接口要求。2流程调研和确定为更明确整个系统的实际需求和

13、流程定义情况，依据以往的实施B/S/S结构系统的经验，应在具体的代码设计和开发前进行全面、细致、到位的流程调研和需求的确定，从而在实际的开发过程中能尽可能接近和达到用户的需求。在整个调研过程中，开发公司将设计各种适合的流程和需求调研表格，用户可根据实际的情况和需求进行填写，对于一些特殊的情况，开发公司将另行向用户详细了解。3管理维护功能的调研和确定管理维护功能的统计和查询功能要求较高，同时还需要导出和打印，需要对统计的要求和导出格式等功能进一步调研和明确。1.3.1.6.2 需求分析本阶段任务主要是确定并定义问题区、客户的需求、项目范围、项目成功标准与客户接收标准。 1定义实施范围确定并定义项

14、目实施的目标、范围和关键的成功要素。2需求分析对用户需要达到的目标进行确定并文档化。工作成果格式需求调查问卷反馈及汇总、分析接收文档用户需求文档签署接收文档功能规范MS Word + 图表功能规范签署接收文档技术体系结构MS Word + 图表技术体系结构签署接收文档项目实施计划MS Word + MS Project Plan1.3.1.7 系统设计阶段电子税收信息管理系统的详细设计阶段主要包括如下工作内容：1系统结构的总体设计：决定系统的总体结构，包括整个系统分哪些部分，各部分之间有什么联系以及已确定的需求对这些组成部分如何分配等方面。 2数据结构的设计：决定数据库系统的模式、子模式、关系

15、以及数据完整性、安全性设计。 3系统模块化设计：设计出系统的详细模块设计文档。4制定初步的系统测试方案：对系统测试的策略、方法和步骤等提出明确的要求。1.3.1.8 应用系统开发在所有流程、需求、表格、统计信息等详细需求资料确定并得到用户方确认后，我公司将开始有计划、可估算的系统开发工作。将预先根据收集的信息，制定清晰的开发进度和开发程度估算指标，同时与客户保持密切、有效的协调和沟通机制，确保在整个开发过程得到最好管理和控制。1.3.1.9 系统测试在每个应用和功能完成时我公司都将先进行内部的测试工作，在通过我们内部的测试后，再将功能和应用提交北京地税；负责本次工作的负责部门进行初步测试，在相

16、关部门和领导的安排和协调下组织最终用户进行试用前的测试，即对调试完毕的系统进行详细的系统功能测试、系统压力、稳定性、安全性测试，输出验收测试报告。同时开始对相关的技术支持人员和业务人员进行维护和应用培训，初验合格将投入试运行。测试阶段相关文档主要包括如下内容：交付格式系统测试结果MS Word + Test Output系统测试停止接受文档UAT 结果MS Word + Test OutputUAT 停止接受文档所有的文档广泛兼容的文档 培训材料产品培训指南培训参加列表MS Word培训评估表MS Word项目停止接受文档1.3.1.10 系统安装与试运行本阶段的主要目标是完成设备的软件安装，

17、系统联调，并着手验收手册、用户手册的输出。1.3.2 项目质量控制1.3.2.1 项目质量控制过程本项目的质量管理不仅仅是项目开发完成后的最终评价，而且还要在“电子税收信息管理系统”开发过程中进行全面质量控制。也就是说，不仅包括系统实现时的质量控制，也包括系统分析、系统设计时的质量控制；不仅包括对系统实现时的软件质量控制，而且还包括对文档、开发人员和用户培训的质量控制。我公司的项目质量控制吸取了CMM的SQA思想，为项目的实施过程提供适当的可视化管理，并对开发过程和产品的进行审核。1.3.2.1.1 项目质量控制综述在本项目中，我们把影响软件质量的因素分成三组，分别反映用户在使用软件产品时的三

18、种不同倾向或观点。这三种倾向是：产品运行、产品修改和产品转移。我们可以采取以下步骤实施全面质量控制： 实行工程化开发在本项目整个的开发过程中，建立严格的工程控制方法，按照工程控制方法规范每一步开发流程，并要求每一个项目实施人员必须遵守工程实施规范。 实行阶段性冻结与改动控制在项目实施的每一个阶段末都要冻结一部份成果，作为下一阶段工作的基础，冻结的成果并不是不可以修改，而是在修改时需要经过一定的审批流程，并涉及到整个项目的开发计划调整。 实行里程碑式的审查与版本控制里程碑式的审查就是在整个项目生命周期的每一个阶段结束之前，都正式使用结束标准对该阶段的冻结结果进行严格的技术审查，如果发现问题，可以

19、在本阶段内进行及时处理和解决。 全面测试对于本项，系统测试将采用整体测试，即从系统调研、系统分析设计、系统实现、系统文档输出等各个阶段进行全面细致的质量测试和控制，确保工程质量。 实行面向用户参与的原型演化高质量的开发和高性能产品的生产需要用户的实际参与和量身定做。在本项目中，将采用用户参与的原型化方法进行需求调研和开发，即每一阶段都要进行原型设计并与用户共同讨论其与需求的偏离程度，并进行及时修正，保证工程的快速、高效率和高性能的开发。1.3.2.1.2 符合Rational Unified Process的质量管理质量管理的目的在于： 对合格的质量确定适合的指标（基本指标）。 确定用于质量评

20、估的适当的评测方法。 及早并尽可能有效地确定和妥善处理影响质量的问题。质量管理贯穿 Rational Unified Process 的所有工作流程、阶段和迭代过程。一般来说，在整个生命周期内进行质量管理即是要使流程质量和产品质量达标，并对此进行评测和评估。下面是每一工作流程在管理质量维度要强调的工作： 需求工作流程中的质量管理涉及：分析需求工件集的一致性（工件标准和其他工件之间）；清晰性（向所有的股东、涉众和其他角色明白无误地传达信息），以及精确性（适当的详细程度和精确度）。 分析设计工作流程中的质量管理涉及：评估设计工件集，包括评估设计模型从需求工件转变过来，再转换为实施工件的一致性。 实

21、施工作流程中的质量管理涉及：评估实施工件，并根据需求、设计和测试工件评估相应的源代码/可执行工件。 测试工作流程就是质量管理的过程，该工作流程的绝大部分工作都是为达到管理上述确定的质量目标而进行的。 环境工作流程，和测试一样，主要工作要为实现管理质量的目的而服务。在此，可获得如何对流程进行最佳配置以满足需要的指导。 部署工作流程中的质量管理涉及：评估实施和部署工件，并根据需求、设计以及将产品交付给最终客户所需的测试工件来评估相应可执行的部署工件。 项目管理工作流程包括对质量管理大部分工作的概述，涉及复审和审核开发流程的实施、遵守以及进展情况。 1.3.2.1.2.1 产品质量产品质量是正在由流

22、程生产的产品的质量。在软件开发中，产品是许多工件的聚合关系，其中包括： 已部署的可执行代码（应用程序、系统等），这可能是最显而易见的工件，因为项目通常是由于该工件才存在的。也就是说，它是为客户（最终用户、股东、涉众等）提供价值的首要产品。 已部署的不可执行工件，包括用户手册和教程资料等工件。 未部署的可执行工件，如工件的实施集，包括已创建用于支持实施的测试脚本和开发工具。 未部署的不可执行工件，如实施计划、测试计划和各种模型。 由于很多工件都建立在其他工件的基础上，所以在某种程度上，所有工件的质量都是相关的。因此，对每个工件的质量都应该评测和评估。 1可执行工件的产品质量（部署的和未部署的）：

23、可执行工件是通过其需求来描述的，并表述为用例或补充需求（如销售、性能等）。要评测并达到质量要求，必须了解这些需求并以清楚、简明和可核实（可测试）的方式陈述这些需求。对于软件来说，测试角色不会将所有需求当作测试对象（如市场渗透或销售收益）。对于那些将成为测试对象的需求来说，测试设计员必须能够指定一种方法来核实是否满足需求（正如已指定的）、没有偏离既定意图并且没有缺陷。 产品质量是通过评测以下质量维度和评测产品是否满足这些维度的要求来决定的： 可靠性：已部署的代码在执行过程中的防故障（崩溃、挂起、内存丢失等）能力。 功能：已部署的代码按既定意图执行所需的用例。 性能：在实际的操作特征（如负载、强度

24、和长时间运行）条件下，已部署的代码以及时和可以接受的方式执行和响应，并以可接受的方式继续运行。 对于每一维度，在测试的一个或多个不同阶段，应该实施和执行一种或多种测试类型。此外，还可通过评测每一工件新版本的可执行工件中所作的变更数量和类型来评估产品质量。2不可执行工件的产品质量（已部署的或未部署的）：不可执行工件的产品质量通过工件的目的、目标和结构来描述，并通过确保工件符合以下各项要求来评估： 工件内部和工件之间的一致性（语言的使用、术语或语义等）。 指南、标准和合同需求（语言的使用、术语、语义、格式或内容等）的兼容性。此外，还可以通过工件版本之间所作变更的数量和类型来评估不可执行工件的产品质

25、量。为了帮助评估 RUP 中工件的产品质量，我公司运用了RUP中针对大多数工件的信息类型： 工件指南和检查点：有关如何开发、评估和使用工件的信息。 模板：工件的“模型”或原型，为内容提供结构和指导。1.3.2.1.2.2 流程质量流程质量是指为了生成工件而对可接受的流程（包括质量评测和质量标准）实施和遵守的程度。软件开发需要一张错综复杂的步骤网，其中既有串行步骤，又有平行步骤。随着项目规模的扩大，必须包含更多步骤来管理项目的复杂性。所有流程都由产品活动和日常管理活动组成。产品活动会取得在形成最终产品方面的实际进展。而日常管理活动对最终产品有着无形的影响，许多计划、管理和评估任务都需要进行日常管

26、理活动。对流程质量进行评测和评估的目的是： 管理利润率和资源； 管理和化解风险； 管理和维护预算、进度与质量； 获取可改进流程的数据；在某种程度上，如果遵守流程并达到了较高的流程质量，这多少会在工件的质量上得以体现。也就是说，如果遵守流程并达到较高的流程质量，生成低质量工件的风险就会降低。但反之未必亦然：生成高质量的工件并不一定表示遵守了流程。因此，不仅要按照流程被遵循的程度来评测流程质量，还要按照流程中产生成果所达到的质量等级来评测流程质量。一般而言，项目组每个人都应负责实施和遵守已得到认同的流程，并确保生成工件的质量达到已认同的质量标准。不过，特定的角色（如项目经理）可能会执行特定的任务来

27、判定和影响流程质量。1.3.2.1.2.3 评测质量对质量（包括产品质量和流程质量）的评测需要收集信息并对其进行分析，这些信息通常以评测和指标来表述。评测的目的主要是为了控制项目，以便能够管理项目。评测还被用来评估项目在完成情况、质量情况、对需求的符合情况等方面与计划所设定目标之间的差距。指标用来达到两个目标，即了解情况的目标和变更（或成果）目标： 知识目标：使用动词如评估、预测、监控来表述。您要更好地了解开发流程。例如，可能要评估产品质量、获得用来预测测试工作的数据、监控测试覆盖或跟踪需求变更等。 变更（或成果）目标：通过使用动词如增加、减少、提高或实现进行表述。通常，您感兴趣的是，随着项目

28、的进展事情如何从一个迭代到另一个迭代、从一个项目到另一个项目发生变更或得到改进。使用这两个目标的指标来评测进度和产品质量。所有指标都需要标准来标识并确定是否达到可接受的质量程度或级别。可接受的质量级别是可以协商并可以变化的，需要在开发生命周期的初期被确定并认同。例如，在早期的迭代中，可以接受较多的应用程序缺陷，但不能接受构架缺陷。而在后期迭代中，只有应用程序中美观方面的缺陷才是可以接受的。验收标准可以采用多种方式进行说明，并可以包括多种评测方法。常见验收标准可能包括以下评测方法： 缺陷数和/或趋势，如已确定、已解决或仍然打开（没有解决）的缺陷数。 测试覆盖率，如（测试）计划、实施并执行的代码（

29、或用例）的百分比。通常，测试覆盖率要和上面确定的缺陷标准一起使用。 性能，如发生指定操作（用例、操作或其他事件）所需的时间。该标准通常用于性能测试、故障转移及恢复测试或其他测试，在这些测试中，时间危急程度是本质问题。 相容性。该标准表示工件或流程活动/步骤必须满足已认同的标准或准则的程度。 可接受性或满意度。该标准通常用于主观评测，如可用性或美观性。1 评测产品质量以清晰、准确和可测试的方式说明需求只是达到产品质量的一部分。还必须确定相应的评测和标准，用来确定希望达到的质量级别，并判断是否已经达到该质量级别。评测说明如何获取用来评估质量的数据，而标准则确定产品达到可接受（或不可接受）质量的级别

30、或点。对可执行工件的产品质量进行评测是通过使用一种或多种评测技术实现的，例如： 复审/走查 检查 执行 根据评测的性质和质量目标，将使用不同的指标。例如，在复审、走查和检查中，首要目标集中在功能和可靠性质量等维度。缺陷、覆盖率和相容性是在使用评测技术时采用的主要指标。但是，执行则可能集中在功能、可靠性或性能上。然而，缺陷、覆盖率或性能是所使用的主要指标。其他评测和指标将根据需求的性质有所变化。2评测流程质量 对流程质量的评测是通过收集情况和成果评测实现的。 对已接受流程的标准、指南和实施的遵守程度。 相对于计划实施，当前流程实施的状况/状态。 所产生工件的质量（使用上面说明的产品质量评测）。

31、对流程质量进行评测是通过使用一种或多种评测技术实现的，例如： 进度 - 例如已演示用例或已完成里程碑。 差异 - 计划的时间表、预算、人员配备需求等与实际情况的差异。1.3.2.1.2.4 评估质量为了管理质量，在整个产品生命周期中都要对流程和产品质量进行评测和评估。质量评估可以主要事件在发生时进行（如阶段结束），也可以在产生工件时进行（如代码走查）。以下是在生命周期中进行的不同评估。 里程碑和状态评估； 检查、复审、走查； 里程碑和状态评估；1.3.2.1.3 项目质量控制过程我公司的质量控制过程包括项目质量保证规划、产品审计、审核计划和审核。其运作机制如下图所示。其中： 项目质量保证规划

32、对项目质量保证的任务进行规划的过程。 产品审计 对项目中的工作产品进行审计的过程。 审核计划 针对项目审核和人员审核制定计划的过程。 审核过程 根据审核计划进行质量审核的过程。 项目质量保证规划过程 项目质量保证规划过程是通过参与项目计划制订过程，确定项目质量保证任务并进行合理规划，与项目相关人员就项目质量保证任务达成共识的过程。它是项目质量保证过程的依据。项目质量保证规划过程定义如下：参与角色RI：项目管理者R2：质量保证管理者进入条件E1：项目管理者通知质量保证管理者参与项目规划。输入 I1：项目任务书活动 A1：质量保证管理者参与由项目管理者负责组织的项目任务单讨论，了解项目情况； A2

33、：质量保证管理者参加由项目管理者负责组织的项目风险分析的讨论，项目实施策略的讨论，项目生存期及各阶段的目标的讨论，阶段任务拆分的讨论； A3：质量保证管理者根据上述讨论结果识别质量风险凭 A4：质量保证管理者根据识别出来的质量风险点设定质量控制点和质量控制方式（如产品审计，对等评审，审核过程，产品测试等），并确定项目过程中使用的质量过程标准，并与有关人员讨论确认； A5：质量保证管理者根据讨论结果编写质量保证计划，确定质量控制方式和具体时间，并提交项目管理者确认； A6：项目管理者组织项目相关人员对质量保证计划进行评审，如有问题进行修改，直至评审通过； A7：质量保证管理者将质量保证计划提交给

34、项目管理者；输出 O1：质量保证计划（包含在项目计划中） O2：质量保证计划的评审报告。完成标志 F1：质量控制计划并入项目计划。产品审计过程 产品审计过程是根据质量保证计划对项目过程中的工作产品进行质量审查的过程。 产品审计过程定义如下：参与角色 R1：质量保证管理者进入条件 E1：待审计产品提交输入 I1：待审计产品的产品标准 I2：待审计产品活动 A1：质量保证管理者依据产品标准从使用者的角度编写产品审计要素； A2：质量保证管理者根据产品审计要素对产品进行审计，并记录不符和项，将不符合项与项目相关人员进行确认； A3：质量保证管理者根据确认结果编写产品审计报告； A4：质量保证管理者向

35、项目管理者提交产品审计报告； A5：质量保证管理者将产品审计报告提交入库。输出 O1：产品审计报告。 F1：产品审计报告入库审核计划过程 审核计划过程是针对人员和项目的审核过程进行计划的制定过程。 审核计划过程定义如下：参与角色 R1：审核人员进入条件 E1：上-轮审核计划完成。输出 I1：项目计划活动 A1：审核人员根据体系的执行情况确定审核目标； A2：审核人员根据审核目标确定审核范围； A3：审核人员根据审核范围和资源情况确定审核组织； A4：审核人员根据审核范围确定审核的项目； A5：审核人员根据审核项目的项目计划确定审核的过程，工作产品和受审人员； A6：审核人员确定审核过程的具体时

36、间，包括审核准备，审核实施，编写审核报告等的时间； A7：审核人员根据上述信息编写审核计划； A8：审核人员组织相关人员对审核计划进行评审，并编写评审报告； A9：审核人员将审核计划和评审报告提交入库。输出 O1：审核计划，格式见附件 O2：审核计划的评审报告。完成标志 F1：审核计划和评审报告入库。审核过程 审核过程是根据审核计划，以PQS体系为标准，对项目的工作产品和活动进行的审查活动。审核的主要目的如下： 作为项目质量保证的一种手段，及时发现生产过程中不符合规范的行为，使其得以纠正；保证开发过程严格按照PQS体系规范执行并生产 出合格的产品；同时为项目管理者提供质量状态报告。 为SEPG

37、提供过程改善的依据 作为人员管理和人员考核的-种手段，为人员评定提供依据 所以，审核过程既是项目的一个质量活动，又是PQS体系的一个质量保证过程，同时也是提高全员质量意识的手段。 审核过程过程定义如下：参与角色 R1：审核人员 R2：受审人员进入条件 E1：审核计划规定的审核时间到输入 I1：审核的项目计划 I2：体系文件活动 A1：审核人员根据审核计划和 PQS体系文件的过程标准和产品标准编写审核要素检查表； A2：审核人员根据审核计划确定具体的受审人员，受审人员中可以包括陪同审核的人员； A3：审核人员应提前通知受审人员具体的审核时间，地点和需要准备的材料及设备； A4：审核人员按事先规定

38、的时间和地点与受审人员进行面对面的审核； A5：审核人员按照准备好的审核要素检查表逐条询问受审人员项目中过程的执行情况并查阅提交产品，受审人员必须如实回答审核人员的问题。审核人员及时进行记录，受审人员可以对体系规范和审核过程提出建议； A6：审核人员在审核结束后，要求受审人员对记录的不符合项和建议进行确认； A7：审核人员根据审核结果整理审核要素检查表给出审核结论并编写审核不符合项报告，对不符合项提出建议并跟踪解决； A8：审核人员将审核要素检查表和审核不符合项报告发送给受审人员，SEPG，项目管理者及相关人员，并入库。输出 O1：审核要素检查表； O2：审核不符合项报告。完成标志F1：审核要

39、素检查表和审核不符合项报告入库。1.3.3 项目测试管理1.3.3.1 项目测试管理规范从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。为了确保软件的质量，对项目开发过程应进行严格的管理。虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。 1.3.3.1.1 测试的过程及组织当设

40、计工作完成以后，就开始着手测试的准备工作，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般按下列方式组织： (1)首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。(2)为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。(3)代码会审：代码会审是由一组人通过阅读、讨

41、论和争议对程序进行静态分析的过程。会审小组由组长，23名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。(4)单元测试：单元测试集中在检查软件设计的最小单位模块上，通过测试发现实

42、现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。(5)集成测试：集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受

43、的误差可能积累到不能接受的程度；全程数据结构可能有错误等。 (6)验收测试：验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。1.3.3.1.2 测试方法的应用集成测试及其后的测试阶段，一般采用黑盒方法。其策略包括： (1)用边值分析法和（或）等价分类法提出基本的测试用例；(2)用猜测法补充新的测试

44、用例；(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上（1）、（2）两步进行。单元测试的设计策略稍有不同。因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种：a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。 b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑

45、盒法进行补充。1.3.3.1.3 测试的人员组织 为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此，测试人员的组织也应是分阶段的。(1)软件的设计和实现都是基于需求分析规格说明进行的。需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严格的审查。审查小组由下列人员组成： 组长：1人成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户(2)设计评审：软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成：组长：1人成员：包括系统分析员、软件设计人员、测试负责人员各一人。(3)程序的测试：软件测试。是整个软件开发过程中交付用户使用前的最后阶段，是软件质量保证的关键。软件测试在软件生存周期中横跨两个阶段：通常在编写出每