项目工作说明书SOW.docx

项目工作说明书SOW.docx

《项目工作说明书SOW.docx》由会员分享，可在线阅读，更多相关《项目工作说明书SOW.docx（46页珍藏版）》请在冰豆网上搜索。

项目工作说明书SOW

附件1

XXXX有限公司

XXXXXXXXXXXXXX项目

工作说明书

创建人

创建日期

版本号

V0.1

密级

机密

XXXXXX有限公司

1前言

1.1目的

本工作说明书是XXXX项目技术服务合同（以下为简称主合同）的不可分割的组成部分，并经XXXX有限公司（以下简称甲方）和XXXX有限公司（以下简称乙方）协商达成以下一致意见：

（1）乙方同意向甲方提供本工作说明书所述服务。

（2）主合同的定义、解释、条款、术语和条件将作为此工作说明书未提及部分的补充。

本工作说明书与合同有冲突的，以主合同条款为准。

（3）此工作说明书描述了由乙方为甲方实施XXXX项目（以下简称本项目）的过程中提供的技术服务细则，以及甲乙双方在项目实施过程中的主要职责。

1.2术语

1.3参考

2项目概述

2.1项目背景

2.2定位和目标

2.2.1系统定位

2.2.2系统目标

2.3应用架构

3项目范围

3.1组织范围

3.2需求范围

3.3非功能性需求

3.3.1性能要求

3.3.1.1对系统功能的性能要求

3.3.1.2对系统网络带宽的评估

3.3.2可用性需求

3.3.3易用性需求

3.3.4扩展性需求

3.3.5权限控制需求

3.3.6安全性需求

3.3.7可运维性需求

3.3.8知识产权

4项目交付清单

5项目管理方案

5.1项目实施工作方法

1.1.决策制度

1.2.交流制度

1.2.1.原则

Ø问题及早提出原则

参加项目的系统工程师对自己承担责任的工作，必须及时发现不能恰当完成的因素，并及时向项目经理或有关责任人书面报告，否则不能恰当完成任务的责任在于任务承担人。

Ø及时解决原则

对所承接的工作，如没有拒绝，则代表接受人已经完全了解工作环境、工作结果要求等多个要素。

如果在呈交结果时，与任务要求有出入，则不可以以任何理由解释责任，失败责任在接受人。

因此，接受人应及时与任务分派人澄清任务的全部因素。

Ø提醒原则

所有项目组成员，如发现项目进展隐患，应及时向项目经理或其他人员提醒。

提醒可以以书面或口头方式。

提醒时也要注意不要追究相关人员的后续工作。

1.2.2.例会制度

Ø周例会

每周五下午，由项目经理组织在现场的双方项目组成员参加周例会。

总结上周工作，形成项目周报。

项目周报的内容包括：

上周工作进展报告、本周工作计划、本周任务分派报告。

Ø问题的提交

参见问题争议制度一节的相关内容。

Ø审批与确认

审批或确认人在收到问题后的二个工作日内向提出人给出书面回复。

1.2.3.问题争议制度

Ø问题及早报告原则

对于一个问题，问题发起人必须在问题发生的1日之内，向项目经理提交报告。

问题没有及早报告，导致的项目影响，由延误报告人承担。

Ø报告方式

如报告人认为口头报告即可，可以采用口头报告，但是如果口头报告没有使问题得以解决，则视同报告人没有作报告。

Ø争议管理

在项目中，任何不能达成一致的观点均为争议，争议应立即向项目的上级单位呈报，并报项目管理部。

争议应由可以协调争议各方的机构加以裁决，并对裁决承担责任。

争议裁决人由项目管理部项目经理选择。

争议的最高仲裁机构为项目领导决策组。

如项目领导决策组仍不能达成一致意见，则遵循，谁决策，谁承担决策失误给对方和项目带来的损失之原则。

1.2.4.失误管理制度

失误可能是多方面的，失误的及早发现是项目成功的基本保障。

对失误的严肃性是项目管理的基本要素。

因此，每个项目成员均要给予极大重视。

•对以下各个事件，必须做出失误分析：

•设计方案有重大改动

•技术有严重的缺陷

•进度与计划差别较大

•设计有误

•其它重大事件

项目经理应每月给出失误分析报告，并有每一失误的详细分析报告并制订弥补措施，此报告应提交相关人员。

如果失误分析报告看不出项目有重大影响，而项目实际有重大问题，则为项目经理之职责。

5.2项目实施管理方法

5.2.1责任分工

5.2.2实施过程

根据本项目的特点，建议采用瀑布模型作为软件开发的生命周期模型进行项目的管理与控制。

瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品，它是从硬件工程学来的一种分阶段的、系统的和顺序的软件开发方法，包括需求分析、项目策划、概要设计、详细设计、编码和单元测试、集成测试、系统测试、系统实施几个阶段。

如图1：

图1瀑布模型

瀑布模型的每个阶段均具有以下特征：

✧从上一阶段接受本阶段工作的对象，作为输入；

✧对上述输入实施本阶段的活动；

✧给出本阶段的工作成果，作为输出传入下一阶段；

✧对本阶段工作进行评审，如果本阶段工作得到确认，那么继续下阶段工作，否则返回前一阶段，甚至更前阶段。

瀑布模型为软件开发与维护提供了一种有效的管理模式，根据这一管理模式制订开发计划、进行成本预算、组织开发人员，以阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品的质量。

优点：

近30年来之所以广为流行，是因为它在支持开发结构化软件、控制软件的开发复杂度、促进软件开发工程化方面起着显著作用。

✧强调开发的阶段性；

✧强调早期计划及需求调查；

✧强调产品测试。

缺点：

缺乏灵活性，无法通过开发活动澄清本来不够确切的软件需求。

这些问题可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉。

✧依赖于早期进行的唯一一次需求调查，不能适应需求的变化；

✧由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；

✧风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。

瀑布模型适用于需求已明确、且很少发生变化的项目及软件开发过程，不适于需求不明确或是容易变化的软件项目。

如果正在进行一个陌生领域的软件项目，建议不采用瀑布模型，但如果正在开发很熟悉领域的软件项目，就可以使用瀑布模型来加快开发速度，因为需求已明确，所以不需要代码重构等方面的开销，开发效率较高。

另外，在科学数值计算、嵌入式软件和实时控制系统方面，比较适于采用瀑布模型，能够很好地控制这类项目的复杂性。

瀑布模型尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行的，阶段间的依赖性由入口准则来确定。

在计划项目时，每个阶段完成点必需设置为主里程碑节点，在主里程碑处安排里程碑评审活动；如果阶段时间比较长，则在阶段中设置次里程碑（建议时间间隔约二～三个月），在次里程碑处进行阶段评审；

下面各章分别描述各阶段的活动，输入输出准则，以及验证的标准。

5.2.2.1需求分析

目的

需求分析阶段的主要目的是生成一个正确说明客户所有需求的文档，需求分析的主要工作是需求提炼及分析、需求归档和需求评审等。

角色与职责

Ø高级经理：

为本阶段活动提供必要的资源支持和保证；批准项目的合同或协议等；处理本阶段中项目组不能处理的问题；参加高级管理评审和里程碑评审；

Ø项目经理：

为需求分析工作提供各种必要的环境和条件；和客户一起确定项目的范围，完成和检查验收标准；对项目计划进行维护跟踪和监控；组织和参与本阶段所有评审（同行评审和管理评审）；度量项目数据；风险管理与跟踪

Ø需求分析员：

作为作者参加需求评审；收集和分析客户需求，定义《软件需求规格说明书》，建立需求库和需求跟踪距阵；

ØPPQA人员：

参加需求评审；对需求析分过程、需求评审过程的执行进行监督；对需求分析阶段产生的工作产品进行进行检查；

ØSCM人员：

参加需求评审；对本阶段的产品进行配置管理；

ØCCB：

参加需求评审；批准基线产品入库，对基线产品的变更进行评审和审批；

Ø测试人员：

参加需求评审；细化测试计划，编写系统测试用例用；

Ø客户或客户代表：

提供客户需求；对需求进行确认；

Ø领域专家：

参加需求评审；对项目需求分析提供指导；

主要输入

Ø项目建议书或工作说明书（SOW）；（可用合同代替）

Ø客户需求/需要；

入口准则

Ø参与需求分析的人员已经到位并接受过相关技能的培训；

Ø项目建议书已经过评审；

Ø客户需求/需要客户已确认

活动

Ø采集和分析客户需求；

Ø编写《软件需求规格说明书》SRS；

Ø建立需求库和需求跟踪矩阵；

Ø细化测试计划，编写系统测试用例；

Ø评审SRS、系统测试计划和系统测试用例、需求跟踪矩阵；

Ø维护和跟踪项目计划；

Ø需求分析里程碑评审；

Ø根据度量指标收集项目数据；

主要输出

基线产品

Ø项目任务书、建议书或工作说明书（SOW）；

Ø客户需求/需要；

Ø软件需求规格说明书；

Ø需求库；

Ø系统测试用例；

Ø产品验收标准；

需控制的非基线产品

Ø软件项目计划（包括开发计划、配置管理计划、质量管理计划、质量保证计划、量化管理计划、测试计划初稿）；

Ø需求跟踪矩阵；

Ø产品使用手册（初稿）；

Ø项目度量表；

其它工作产品

ØSRS/系统测试用例/需求跟踪矩阵的同行评审记录和报告；

ØPPQA检查报告；

Ø配置管理状态报告；

Ø项目会议记录；

Ø里程碑评审记录和报告；

Ø项目管理评审记录和报告；

Ø高级管理评审记录和报告；

出口准则

Ø已建立了原始需求与需求规格说明之间以及需求规格说明与已编写的系统测试用例之间的映射关系（需求跟踪矩阵）

Ø每一个软件需求都可编写出相应的测试用例

Ø已编写了25-30%的系统测试用例并通过了评审

Ø符合组织能力基线和项目最终质量目标制定的需求阶段应发现的缺陷数

Ø100%修复需求阶段发现的缺陷

Ø已制订了系统测试计划

Ø需求阶段评审的工作量大于需求阶段总工作量的1/3

Ø客户、高层经理、项目经理及项目相关人员参加需求的评审

Ø需求阶段评审的功能数占需求阶段已确定的功能数的100%

Ø需求规格说明书通过评审并得到用户的确认和签字

Ø已收集本阶段所需收集的项目数据并进行过分析

可应用方法、工具和资源

软件过程数据库、过程能力基线、过程资产库；

约束

对SRS、需求跟踪矩阵、测试用例都要进行技术评审（同行评审）。

度量

需求分析所花的工作量，本阶段发现和清除的缺陷、评审和返工工作量；

标准和规范

OSP；

5.2.2.2项目策划

目的

项目策划是项目开发的初始阶段，目的是为开发过程和过程管理做好必要的准备。

项目策划的主要工作是进行估计和制定管理项目的计划。

角色与职责

Ø高级经理：

审批项目计划；审批和确保所需人力资源和设备；与客户谈判项目委托事项；参加高级管理评审和里程碑评审；

Ø项目经理：

与项目其他相关组商谈项目计划活动，制定项目计划（主体计划）、质量管理计划、量化管理计划、和项目定义过程；依据项目计划分配人员和资源；组织和参与本阶段所有评审（同行评审和管理评审）；度量项目数据；

ØPPQA人员：

制定质量保证计划；对项目计划过程、项目定义过程过程、评审过程的执行进行监督，对项目策划过程中的工作产品进行检查；

ØSCM人员：

负责制定配置管理计划；建立配置管理环境；对本阶段的产品进行配置管理；

ØCCB：

批准基线产品入库，对基线产品的变更进行评审和审批；

Ø测试人员：

负责制定测试计划；

Ø客户或客户代表：

提供客户需求；

Ø项目组主要成员：

参与项目计划制定和评审；

Ø领域专家：

对项目可行性分析和研究提供指导；

ØSEPG：

审批项目定义过程（PDP）；提供项目所需的过程资源和考参数据；

主要输入

Ø项目任务书、建议书或工作说明书（SOW）；

Ø客户需求/需要；

Ø软件需求规格说明书；

Ø产品验收标准；

Ø组织标准过程（OSP）；

入口准则

Ø客户需求/需要已被批准；

Ø项目任务书、建议书或SOW已被批准；

Ø软件需求规格说明书通过评审

Ø项目经理和相关人员已经到位并参与项目策划的人员接受过相关技能的培训；

活动

Ø构建WBS及估计项目的规模、工作量、成本和CCR等；

Ø标识和分析风险；

Ø编制项目计划（包括开发计划、配置管理计划、质量管理计划、质量保证计划、量化管理计划、测试计划）；

Ø编定项目定义过程（PDP）；

Ø评审和批准项目计划（总体）、（PDP）；

Ø根据度量指标收集项目数据；

主要输出

基线产品

Ø项目任务书、建议书或工作说明书（SOW）；

Ø客户需求/需要；

Ø软件需求规格说明书；

Ø需求库；

Ø系统测试用例；

Ø产品验收标准；

ØPDP

需控制的非基线产品

ØWBS估计记录；

Ø风险分析表和风险评估报告；

Ø软件项目计划（包括开发计划、配置管理计划、质量管理计划、质量保证计划、量化管理计划、测试计划）；

Ø项目度量表；

其它工作产品

Ø项目计划和PDP的评审记录和报告；

ØPPQA检查报告；

Ø配置管理状态报告；

Ø项目会议记录；

Ø里程碑评审记录和报告；

Ø项目管理评审记录和报告；

Ø高级管理评审记录和报告；

出口准则

Ø受影响的组和个人参加了软件项目计划的评审，并项目约定和计划得到受影响的组和个人的认可；

ØDSP得到SEPG批准

Ø质量管理计划得到质量经理的批准

Ø项目计划得到高级经理的批准

Ø符合组织能力基线和项目最终质量目标制定的计划阶段应发现的缺陷数

Ø100%修复计划阶段发现的缺陷

Ø本阶段所有输出工作产品已置于配置管理之下

Ø已收集本阶段所需收集的项目数据并进行过分析

可用的方法、工具和资源

ØWBS指南；

Ø估计方法（经验值法、Delphi法）；

ØMicrosoft　Project；

Ø软件过程数据库、过程能力基线、过程资产库；

约束

项目相关组代表必须参与项目计划和项目定义过程的评审；

度量

项目策划所花的工作量，评审工作量和返工工作量；

标准和规范

OSP；

5.2.2.3概要设计

目的

概要设计阶段是从实现的角度开发针对客户需求的解决方案。

在这个阶段给出的是高层的方案，这个方案包含两个主要部分，即应用的功能体系结构和数据库设计。

角色与职责

Ø高级经理：

为概要设计活动提供必要的资源支持和保证；处理本阶段中项目组不能处理的问题；参加高级管理评审和里程碑评审；

Ø项目经理：

为概要设计工作提供各种必要的环境和条件；对项目计划进行维护、跟踪和监控；组织和参与本阶段所有评审（同行评审和管理评审）；度量项目数据；

Ø需求分析员：

维护需求库和需求跟踪距阵；

Ø设计人员：

对项目进行概要设计；

ØPPQA人员：

对概要设计过程、概要设计评审过程的执行进行监督；概要设计阶段产生的工作产品进行进行检查；

ØSCM人员：

对本阶段的产品进行配置管理；

ØCCB：

批准基线产品入库，对基线产品的变更进行评审和审批；

Ø测试人员：

细化测试计划，编写集成测试用例用；

Ø领域专家：

对项目概要设计提供指导；

主要输入

ØSRS；

Ø需求跟踪矩阵；

Ø系统测试计划和系统测试用例；

入口准则

ØSRS通过评审和批准；

Ø参与概要设计的人员已经到位并且接受过相关技能的培训；

活动

Ø定义标准（编码、文档、用户接口等）；

Ø进行功能设计；

Ø开发物理数据库设计；

Ø编写概要设计文档；

Ø细化测试计划，编写集成测试用例用；

Ø评审概要设计文档、集成测试计划和集成测试用例；

Ø根据度量指标收集项目数据；

主要输出

基线产品

Ø项目任务书、建议书或工作说明书（SOW）；

ØPDP；

Ø客户需求/需要；

Ø软件需求规格说明书；

Ø需求库；

Ø系统测试用例；

Ø产品验收标准；

Ø概要设计说明书；

Ø集成测试用例；

需控制的非基线产品

Ø需求跟踪矩阵；

Ø测试计划；

Ø项目度量表；

Ø产品使用手册（初稿）；

其它工作产品

Ø概要设计说明书同行评审记录和报告；

ØPPQA检查报告；

Ø配置管理状态报告；

Ø项目会议记录；

Ø里程碑评审记录和报告；

Ø项目管理评审记录和报告；

Ø高级管理评审记录和报告；

出口准则

Ø项目相关人员参加概要设计的评审

Ø概要设计说明书，集成测试用例通过了评审

Ø更新了（需求跟踪矩阵）中需求与概要设计、集成测试的对应关系

Ø符合组织能力基线和项目最终质量目标制定的概要设计阶段应发现的缺陷数

Ø100%修复概要设计阶段发现的缺陷

Ø概要设计阶段评审的工作量大于概要设计阶段总工作量的1/3

Ø概要设计阶段评审的功能数占需求阶段已确定的功能数的100%

Ø本阶段所有输出工作产品已置于配置管理之下

Ø已收集本阶段所需收集的项目数据并进行过分析

可应用方法、工具和资源

ØPDP中所选用的概要设计工具和方法；

Ø软件过程数据库、过程能力基线、过程资产库；

约束

对所有的概要设计文档、需求跟踪矩阵、测试用例都要进行技术评审（同行评审）。

度量

概要设计工作量、本阶段发现和清除的缺陷、评审和返工工作量；

标准和规范

ØOSP；

ØPDP；

5.2.2.4详细设计

目的

在详细设计阶段，概要设计阶段开发的整体应用被分成几个模块和程序。

为每个程序进行逻辑设计，然后归档作为程序规格。

同时，为每个程序生成一个单元测试计划。

详细设计阶段的活动包括通用例程和程序的确定（如数据有效性例程、框架程序的开发及用于提高生产率的实用程序和工具的开发）。

角色与职责

Ø高级经理：

为详细设计活动提供必要的资源支持和保证；处理本阶段中项目组不能处理的问题；参加高级管理评审和里程碑评审；

Ø项目经理：

为详细设计工作提供各种必要的环境和条件；对项目计划进行维护、跟踪和监控；组织和参与本阶段所有评审（同行评审和管理评审）；度量项目数据；

Ø需求分析员：

维护需求库和需求跟踪距阵；

Ø设计人员：

对项目进行详细设计；

ØPPQA人员：

对详细设计过程、详细设计评审过程的执行进行监督；对本阶段产生的工作产品进行进行检查；

ØSCM人员：

对本阶段的产品进行配置管理；

ØCCB：

批准基线产品入库，对基线产品的变更进行评审和审批；

Ø测试人员：

细化测试计划，编写单元测试用例用；

Ø领域专家：

对项目详细设计提供指导；

主要输入

ØSRS；

Ø需求跟踪矩阵；

Ø概要设计说明书；

Ø系统测试计划和系统测试用例；

Ø集成测试计划和集成测试用例；

入口准则

Ø概要设计说明书经过评审和授权；

Ø参与详细设计的人员已经到位并员接受过相关技能的培训；

活动

Ø将功能分成小的构件；

Ø设计/开发代码框架；

Ø开发例程和工具；

Ø进行程序设计；

Ø编写详细设计文档；

Ø计划单元测试；

Ø评审详细设计文档、单元测试计划和测试用例；

Ø根据度量指标收集项目数据；

主要输出

基线产品

Ø项目任务书、建议书或工作说明书（SOW）；

ØPDP；

Ø客户需求/需要；

Ø软件需求规格说明书；

Ø需求库；

Ø系统测试用例；

Ø产品验收标准；

Ø概要设计说明书；

Ø集成测试用例；

Ø详细设计说明书；

Ø单元测试用例；

需控制的非基线产品

Ø需求跟踪矩阵；

Ø测试计划；

Ø项目度量表；

Ø产品使用手册（初稿）；

其它工作产品

Ø详细设计说明书同行评审记录和报告；

ØPPQA检查报告；

Ø配置管理状态报告；

Ø项目会议记录；

Ø里程碑评审记录和报告；

Ø项目管理评审记录和报告；

Ø高级管理评审记录和报告；

出口准则

Ø项目相关人员参加详细设计的评审

Ø详细设计说明书，单元测试用例通过了评审

Ø更新了（需求跟踪矩阵）中需求与详细设计、集成测试、单元测试的对应关系

Ø符合组织能力基线和项目最终质量目标制定的详细设计阶段应发现的缺陷数

Ø100%修复详细设计阶段发现的缺陷

Ø详细设计阶段评审的工作量大于详细设计阶段总工作量的1/3

Ø详细设计阶段评审的功能数占需求阶段已确定的功能数的100%

Ø本阶段所有输出工作产品已置于配置管理之下

Ø已收集本阶段所需收集的项目数据并进行过分析

可应用方法、工具和资源

ØPDP中所选用的工具和方法；

Ø软件过程数据库、过程能力基线、过程资产库；

约束

对所有的详细设计文档、需求跟踪矩阵、测试用例都要进行技术评审

度量

详细设计工作量、本阶段发现和清除的缺陷、评审和返工工作量；

标准和规范

ØOSP；

ØPDP；

5.2.2.5编码和单元测试

目的

Ø在编码阶段，根据详细设计用编程语言和合适的编码规范产生源代码、可执行代码和数据库。

这个阶段的输出是随后测试和验证的主体。

角色与职责

Ø高级经理：

为本阶段的活动提供必要的资源支持和保证；处理本阶段中项目组不能处理的问题；参加高级管理评审和里程碑评审；

Ø项目经理：

为编码和单元测试工作提供各种必要的环境和条件；对项目计划进行维护、跟踪和监控；组织和参与本阶段所有评审（同行评审和管理评审）；度量项目数据；

Ø需求分析员：

维护需求库和需求跟踪距阵；

Ø开发人员：

编码和单元测试；修复代码中发现的缺陷；

ØPPQA人员：

对编码和单元测试过程、编码和单元测试评审过程的执行进行监督；对编码和单元测试阶段产生的工作产品进行进行检查；

ØSCM人员：

对编码和单元测试阶段的产品进行配置管理；

ØCCB：

批准基线产品入库，对基线产品的变更进行评审和审批；

Ø测试人员：

编写单元测试用例用，进行单元测试；

Ø领域专家：

对项目编码和单元测试提供指导；

主要输入

Ø详细设计说明书；

Ø单元测试计划和测试用例；

Ø概要设计说明书；

Ø集成测试计划和测试用例；

Ø软件需求规格说明书；

Ø系统测试计划和测试用例；

入口准则

Ø详细设计文档经过评审和授权；

Ø编码和单元测试的人员已经到位并员接受过相关技能的培训；

活动

Ø编写测试代码或测试用例；

Ø对程序进行编码；

Ø编译代码；

Ø单元测试；

Ø代码评审；

Ø记录和修正缺陷；

Ø根据度量指标收集项目数据；

Ø完成所有系统测试用例和集成测试的编写

Ø完善用户使用手册

Ø对所有测试用例进行评审

主要输出

基线产品

Ø项目任务书、建议书或工作说明书（SOW）；

ØPDP；

Ø客户需求/需要；

Ø软件需求规格说明书；

Ø需求库；

Ø系统测试用例；

Ø产品验收标准；

Ø概要设计说明书；

Ø集成测试用例；

Ø详细设计说明书；

Ø单元测试用例；

Ø单元测试后的源代码、编译的目标代码；

需控制的非基线产品

Ø需求跟踪矩阵；

Ø测试计划；

Ø单元测试报告；

Ø缺陷修正记录；

Ø项目度量表；

Ø产品使用手册（完善稿）；

其它工作产品

Ø代码评审记录和报告；

Ø测试用例的评审记录和报告；

ØPPQA检查报告；

Ø配置管理状态报告；

Ø项目会议记录；

Ø里程碑评审记录和报告；

Ø项目管理评审记录和报告；

Ø高级管理评审记录和报告；

出口准则

Ø所有的测试用例通过了评审

Ø成功执行所有单元测试计划中的测试用例。

Ø代码总规模的80％以上要经过单元测试，复用部分可不经过单元测试

Ø单元测试要求90%以上语句覆盖。

Ø核心代码必须经代码评审，同时代码评审的比例不低于20%

Ø更新了（需求跟踪矩阵）中需求与详细设计、单元测试的对应关系

Ø符合组织能力基线和项目最终质量目标制定的编码和单元测试阶段应发现的缺陷数

Ø100%修复编码和测试阶段发现的缺陷

Ø已收集本阶段所需收集的项目数据并进行过分析

Ø本阶段所有输出工作产品已置于配置管理之下

可应用方法、工具和资源

ØPDP中所选用的工具和方法

Ø软件过程数据库、过程能力基线、过程资产库

约束

Ø