【国家标准(GB)】 软件工程 软件生存周期过程 用于项目管理的指南

ICS 35.080
中华人民共和国国家标准化指导性技术文件GB/Z20156-2006
软件工程
软件生存周期过程
用于项目管理的指南
Software cnginecringGuide for the application of softwarelife cycle to project managemcnt(ISO/IEC TR 16326:1999 Software engineering-Guide for the applicalion ofISO/IEC 12207 to project management,MOD)2006-03-14发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
GB/7.20156—2006
前言，
范围·
符合性
规范性引用文件
术语和定义
符号利缩略语
软件项目曾理导引
理过程
附录A（资料性附录）
附录H(资料性附录）
附录 C (资料性附录)
附录D(资料性附录）
D.1介绍
GB/T 8566—2001对管理过程的支持SPM活动到管理过程活动的映射
项目管理过程到GB/T8566—2001管理过程活动的唤射支持信息·
1).2项目管理知识域过程概念
D.3符合项目督理过程定义的质量参考文歇
KAONKAca-
： 14
GB/Z20156—2006
本指导性技术文件修改采用IS0/IECTR16326：1999软件工程1SO/1EC12207用于项日管理的指南》（英文版）。
本部分与 ISO/IECTR 16326的差异为：软件生存周期过程（idtISO/
在第3章规范性引用文件中列人了GB/T8566一2001信息技术[EC12207:1995)。
为便于使用,本指导性技术文件还做了下列编辑性修改：接照语可惯对一些编排格式进行了修改；一按G/T1.1作了缩辑性修改：
-将一些适用于国际标准的表述改为适用于我国标准的表述将原技术报告的附录E参考文献直接作为本指导性技术文件的参考文献，并将原附录E中的IS08402:1994和ISO9004-1:1994分别以GB/T19000—2000和GB/T19004—2000代替；引言中删去了对文件中每章具体内容的描述本指导性技术文件的附录A、附录B,附录C和附录D为资料性附录。本指导性技未文件由中华人民共和国信息产业部提出。本指导性技术文件由企国信息技术标准化技术委员会归口。本指导性技术文件起节单位：中国电子技术标准化研究所，本指导性技术文件王要起草人：陈静、冯惠、高林。I
CB/Z20156—2006
iikAoNiKAca
软件是信息技术和传统系统的组成部分，比如交通，军事医疗和财务系统。为了开发和管理软件，异致标准、规程、方法、工具和环境数盘迅速增长，这种增长造成了软件暂理和工程困难，特别是在集成产品和服务中。软件学科需要从这种增长状态迁移到一种公共框架，这种框架使得软件从业人员在创建和管理软件时\使用相间的语言”。GB/T8566一2001《信息技术软件生存周期过程》就提供了这种公共框架。
这个框架包括下述软件生存周期：从概念形成直到退役，并且由获取和供应软件产品及服务的各个过程组成。该框架也可用米控制和改进这些过程。GB/T8566一2001提供了软件生存周期过程的一个较完整的集合。一个组织根据其目的，可以选择适合的GB/T85662001子集达到目的。把GB/T8566—2001改计成可以让具体的组织，项日或应用加以剪裁。当软件是一个独立实体、嵌入系统或整个系统的组成部分时，均可使用该标准。本指导性技术文件对GB/T8566一2001的7.1条规定的管理过程提供了指南。提供的大部分指南是基于项月管理协会（PM1'S)的项目管理主体知识(PMBOKTM）指南，ISO10006质量管理—项日管理中的质过指南以及已经取得成功的软件项目管理者的经验。本指导性技术文件不打算对任何组织的角色和职丧提出建议。已经认识到所标识的过程，活动和任务具有送代的“生存期”，并且它们可能以任何次序或题率出现。这些过程、活动和任务必须和本指导性技术文件中未着重强调的其他过程、活动和任务（如，GB/T8566--2001的生存闹期的支持过程和组织过程>相结合：I
1范围
软件工程软件生存周期过程
用于项目管理的指南
GB/l.20156—2006
本指导性技术文件在管理过程方面（以下称为“软件项目管理”或SPM,因此，在本指导性技术文件中，SPM不是人员，而是过程)补充GB/TB8566一2001信息技术软件生存周期过程及。本指导性技术文件基于以下内容而制定(见图1)：-将GB/T8566——2001中的管理过程用于SPM；一利用项目管理主体知识(PMBOKTM)指南来定义和描述适用于SPM的管理知识域；—使用IS0 10006质量管理—项目管理中的质量指南。本指导性技术文件为负责管理 GB/T 8566一2001 软件生存周期基本过程：获取,供应.开发.运作和维护的执行的人员提供了指南。本指南论述-将GB/T 8566一2001的 7.1中的管理活动在每个基本过程中实施 SPM进行一般指导；一SPM 对每个基本过程的适用性；一与SPM的范围适当交双的关键域；针对下面的管理任务、为软件项目经理(PM)扩充了指南：。［11]总体标识并描述已带遍接受的PMBOKTM子集。普遍接受意味着所描述的知识和惯例适用于大多数时期的多数项日，并且对其重要性和有效性取得了广泛的一致同意；。［5]一一给出了质量体系要素、概念和惯例的指南,其实施对于项目管理惯例是重要的并具有影响。
本指导性技术文件论述的项目管理的各方面，它们或是“软件特定的”，或是已知的在GB/T 8566一2001 任一基本过程中引发软件项目问题的。例如,众所周知,软件项目经常延期和/或超出预算，或不能满足需方的需求或期望。然而对于软件这并不罕见，有许多软件特定的屏性导致了这些情况的发生。
图 1说明GB/T 8566—2001、参考文献[11]和[5]在本指导性技术文件中的关系。1.1读者
本指导性技术文件为那些在软件项目中使用和打算使用 GH/T 8566—2001的人缩写，与项目的范围、产品、方法、规模或复杂度无关。本指导性技术文件的目的主要为帮助软件项目经理（PM)确保管理过程符合GB/T8566—2001，特别是：—负资建立并持续地改进GB/T8566—2001软件生存周期过程的经理；—负资在项目级执行GB/T8566一2001软件生存周期过程的经理：-分包一-个SPM工作的组织或个人。也考虑了下列人员：
参与软件项目,但不是软件 PM;
-曾是非软件PM，但正转变为软件FM。本指导性技术文件从软件PM的观点介绍了GB/T8566—2001基本的生存周期过程，并提出了执行者用于管理任务的最佳惯例和忠告的建议（根据经验、教训等）。最后，本指导性技术文件使工程、技术和其他支持人员能够明白其工作是怎样集成在整个软件生存周期中的。1.2先决条件
使用本指导性技术文件的先决条件是：1
GB/Z 201562006
热悉GH/T8566-2001；
熟悉组织的相关方针和规程；
了解共利益者和合同带求(要求和期望)。GB / H566—2001
软件出存周过程
[SO/ IEC 10006
微量在
项目行理中的指南5]
本拍导性技术文件
好住试例、经教等
PMBOKM指南
目诊理却识咳［1]]
图1利用GTB66—20Q1、PMBOK指南和ISC10006制定本接母性技术文件2符合性
由于这是一个指导术文件，符合性不作明确规定。3规范性引用文件
HKANi KAca-
下列文件中的翁款随过本指导性技术文件的用而戒为本指导性没术文件的条款。凡是注日期的引用文件，其随后所存的修改单（不包括勘误的内容）或修订版均不适照于本指导性文件，然而，鼓励根据本指导性描文做达成协议的各方研究是否刊使用这些文件的最新版本。凡是补注日期的引用文件，其最新版本遁用体指导性技术件GB/T8566—R00信息技术软件生存厨期过性（idt1SUECT2207：199）4术语和定义
2001，套考文献[117和二5]给出的语和定。本指导性技术文件彩间\\GB/T8565符号和缩略语
本指导性技术文件采服下刻剂湿和缩略证：CCB:
6指南
配旺/变更控谢姿资会
接口控制工作组
项目经理
软件工程环境
软件项目理
工作分解结构
6.1软件项目管理导引
项目是为产生一个唯一的产品或服务[11]而做的一项临时性的工作。同样，一个项目有一组人，资源，也包括具有下列公共特性的事件：根据项目的规模和复杂度,可以是一组人，一个人或一个职能,2
.一主要自标尼要产生产品，服务和结果一一项目有已知的开始和结束，即:项目是临时的；GB/Z 20156—2006
项目不是大多数组织通常的、正在进行中的工作的一部分，即：项甘通常有唯一的需求。一些组织（例如，研究和开发)只是为了完成项目而存在。软件项日是强调以软件作为它的产品、服务或结果的项目。那么，软件与其他项日产品、服务和结果有什么不同呢？正如WattsHumphrey[17所述软件通常较为复杂
软件经常发生变更：
一许多后期发现的硬件问融通过软件变更处理：一一由于软件低廉的再生产成本，所以，软件没有通带的像硬件那样的制造发行规律：一一软件学科不仅是基于自然科学，并且对于可行性测试和设计模型缺乏现成可用的技术；一软件通常是集成为一个完整系统的单元，因而增加了它的复杂度并且暴露在后期变更中；一软件是很敏感的,因而最易道受需求变更并且摄受用户抱恕。因为软件不同于其他产品.服务和结果，所以软件项目的管理也不同。这井不是说SPM完全不同于非软件项日管理。关键是普理层必须认识到SPM的特有领域和-·般项日管理的作用既要达到项目目标，又要防止间题发生。
[11]提供了有关管理项月的重要信息。GB/T 8566--2001的 5.2(供应过程)中给出了软件项月的重要信息，并描述了许多将要执行的活动和任务。[5]提供了怎样改进项目管理质量的信息。本指导性技术文件的主要日的是要强调以上描述中的差异怎样影响软件PM,并说明这三份文挡是怎样互补的，以及帮助PM管理软件项日取得成功。由于可用于软件工程的项目管理二其和方法的种类较其他工程学科不完全，从而导致了软件学科中快速变化的技术超过了管理和过程技术。许多因素决定了SPM方法的实，例如：人员.组织和合同的要求，以及项目复杂度，对于所承扭的项目，软件PM应决定方法和技术，并且：一预测间题的不利影响，从而顾防或使其减至最小；一做出及时和竖决的决策；
一出现问题时解决问题；
一对项目的措施,过程、活动、资源、产品和结果负责。作为-项迭代的工作，当在一个范围采取一项措施，例如;措施成功或失败，可能影响其他范时，软件 PM 必须考患任何系统性的影响。6. 2管理过程
本条分析GB/T 8566--2001(7,1条)的管理过程。GH/T 8566—2001 定义了由管理其过程的任何一方执行的一般的管理过程（不是SPM），本条论述当GB/T8566一2001用于软件项目管理（SPM)时的管理过程。
应认识到已标识的过程、活动和任务可能需要采取再选代的措施以达到项目的要求/目标。例如，基于正在使用的软件生存周期模型，过程，括动和任务可能在间一时间执行；它们可能相互依存；或在软件项目生存周期中的系列有组织的工作分解结构（WBS)依赖性中互相配合：GB/T8566—2001
7.1臂理过程
管理过程包括一般的活动和任务，由管理其对应过程的任何一方执行。管理人员负责适用过程的产品理、项目管理和任务管理，例如获取、供应、开发、运作、维护或支持过程。因为项目可能不涉及所有的基本过程，所以，GB/T8566-2001（7.1条）声明“适用过程\。例如3
GB/2 20156—2006
一个项目可能只涉及产品的开发或维护，而不涉及产品运行。iiKANiKAca-
SPM应定义（并且软件PM应控制)为确保产品按合同规定交付所必的活动，即，确保软件项目包括所有为成功地完成项目和产品所需的工作，并且只是所需的工作。6.2.1启动和范围确定
CB/T 8566—2001
7.1.1 启动和范围确定
此项活动包括下述任务：
7.1.1.1通过提出对被执行过程的要求来启动暂理过程。7.1.1.2需求一经提出，管理者应通过检查执行和管理过程所帮要的资源（包括人员、材料，技术和环境）的可行性、充分性和适用以及检查势行进度的可完成性，来建盗过程的可行性。7.1.1.3若需要并经有关签友同意可以在此刻修改过程的需游以达到究成准则。启动和范围确定是淋定料河行性，以确保执行和管理项月所需人，材料，设施，软件工程环境(SEE)和技术的可行性以死公谜和适用性，及预定的完成时间能实现的，适微制经济的。启动和范围确定包括选择软件获发策整（例如，一个项目可能包括现货供应的软评、组自己奸发的软件，外包软件或它们的组台）。
与范围（例如，好频品、产品特性及怎样测量和评估特性的描有关的馈音裤。缩制进行此项麟的理由，目的和目标的文挡一将共利益器織兼转化为要完成的项日可交付产品和活动，以实现和构造+-测旧：一确保人厕在跨固内工作；
一评价活动粘课，以促进结果满足照定的需求设好的情况最渐新件项日与组织以前臂理的项月有许多相似之处。这为该组织有能力成功地完成软件项目提供有另保证。
当新项目是无洗例时（即：组织在以前从末做过）：过启动和范函的确定可能很难完成。对于无先例的项日，要给予特别关益以确保适当地确定范固并进行监督，这应通过经常的审和评价，间顾从一些关项目学到的最候惯谢和经验，以及向专家征求意见求实现。启动和范固确定的关链提要提出并编写软件项目的详尽的范固和需求。这包括标识并理解共利益者需求，以及评价和协将谨举的需求。在软件项目小存调期中对瘤和领敏双更管理应给手特别关注。应存细地评价关然范彻积需求的所有变更对费用、进度人风险和性能的影喊。软件项目的需求确定应涉及所有的共利益者。
对确定并记载质量特性仪经粒接别关注一例如，在软车被嵌到高层系统，或功能在软件和硬件之间分配、或应在软件和外部接浪件或系蔬之间分配的说不。对于获得共利益者关于项日需示的协定，应确定职资。协定是在款件项日生存周期中执行送代过程的结果。风险、共利益者需求环境、项自源和进度的变求放不断进展的设计，使得必须不断地再评估和重中协定和承诺成为必然，在需要时，适当地变更项目范围。建立完成准则十分重要。如[11］所支持的，其目的是妥确定一个项目、活动或任务是否已成功地完成。
经常被软件PM忽视的一个商业带求是版权和专利权等的处理。例如，需方何时拥有正在开发的产品，或供方在最终产品交付之前终止业务时，需方拥有什么？对于件特别建设：
一应谨慎地确定软件复制、分发，安装和测试的带求：应建立并维护系统与软件冠求之间、软件需求与设计之间以及软件求与测试之间的可追翻性
GB/Z 20156—2006
一应把接口作为软件规格说明和接口描述文档的一个完整的部分米如以规定和控制；一由于软件开发的复杂度，很难证明软件产品满足所有用户需求（要求和期望）：根据项目类型估计工作量：新开发的、嵌人到或集成于二个系统的.修改现货供应的软件产品。移植到不同操作系统上的等等，6.2.2策划
GB/T 8566-2001
7.1.2策划
此项活动包括下述任务：
7.1.2.1管理者应为过程的执行制定计划。与过程的执行有关的计划应包括相关活动和任务的说明和对即将提供的软件产品的标识。计划应包括，但并不仅限于下述内穿：按时完成任务的进度表；
工作成果的评估；
执行任务所需充分的资源；
任务的分配：
责任的指定；
与任务或过程白身有关的风险的量化：g
整个过程中采用的质量控制措施h)
与过程执行有关的费用；
i）环境和基础设施的保证。
应规定制定和批准计划的职：
计划应标识软件生存周期模型、在务、任务分配，承诺和资源。一个软件项目应有一个工进度，并且所有的附属进度都应与主进度集成在一起并与主进度一致。WBS可以有效地测量软件项日进展，并提供过程和产品的可视性，由了-WBS为法组织并定义了项月的全部范围[11],所以极力鼓励使用WBS方法。为了充许在与软件项日的规模，复黎度关键性和风险一致的适当粒度级别上评理软件项日，应编制WBS。必须熟悉所使用的技术。用干策划中的项目估计应包括：与过程执行有关的费用
基础设施；
一-所备的资源，他括与管理和控制有关的资源；一质量保证和控制；
风险管理；
—SEE保障；
每个过程和/或活动中要执行的工作。只募可能，软件PM应尽量使用现有组织的基础设施。如果现有的基础没施不足以支持项目，底适当地增加现有的基础设施。这可能要求使用分包方式来解决基础设施的不足。通过咨询可以促进对不同的情况得一致意见。
随着项自执行进展，在评定，改进、修订（如果必要）软件项管中，策划是一项选代的活动。在软件项目生存周期中，软件PM应有过程，以便于重新策划并细化估计。每个软件项目有许多依赖关系，既使是得到最初始的SPM计划，通常都备要多次策划。对于在其他计划中提供的SFM计划所需的信息，SPM 计划可以参考这些计划。
应更新计划，并且计划至少应包括：——角色和职资；
GB/Z20156—2006
一要执行的活动和任务；
在WBS中标识的所有项目可交付项：完成准则；
完成报告；bZxz.net
费用和进度报告：
…肩动的方法：通过指示、产品或基于时简说明；—报告进展的题率和方法;
问题和异常报告；
—资源需求和状况。
iiKANiKAca-
因为支持过程（例如，配置替理、文档、质量保证）通常是项目的一部分，所以支持过程管理者应制定文档化的计划：支持过程计划应与 SPM计划一致并支持 SPM计划,并且支持过程计划可以是单独的计划，也可以包括在SFM计划之中。这些文档化的计划应由软件PM批准并置于项目变更控制之下。与支持过程有关的活动报告既可以直接交给软件PM也可以通过组织管理部门交给软件PM。问题和异常报告应引起软件PM的注意，注意对项目的费用、进度，范围和质量的分析的影响。对于冲突的解决或逐步升级应有一个机制，以便一个经授权的适当的组织曾理层可以解决软件PM和支持过程臂理之间的分歧。
依据一个或多个来自任一支持过程的报告和/或结果来设置里程碑的位置以改里程碑的实现。依照已批准的计则，以正确及时的方式报告达到里程碑是承要的。单程碑通常以合同方式与支持过程的性能联系（例如达到一个特定基线），所以协调计划使软件PM尽可能早地了解在完成被分配的任务中支持过程所面临的困难是必要的。在软件PM的直接组织的控制之外，无论组织何时执行支持过程，对于认识到存在以下两组关系都是重要的：
a）在软件PM和支持过程管理之间：h）在被支持的和支持的组织管理之间。当软件PM通过清晰地定义技术和管理报告、信息流和讨论决议米考虑策划、实施、控制和报告情说时，软件PM应考虑到这组关系。在分包协议和任务下，计划的同步可能很困难，但可以用一个主计划来支持：
对于分析和理解组织过程能力和效果、历史项月性能和学到的经验，历史项目数据是主要的信息米源。这些历史数据构成一个总的数据库，组织应利用它去不断地改进组织的生存周期过程。该数据库应支持单个的软件项目执行管理过程。每个组织都应为搜集.分析，总结、存档和检索历史项目数据建立正规的系统。
对于软件特别建议：
a）有效的配置理觉略对教件项日足置要的，因此下列签略可以故用作变更控制过程的部分来管理变更：
1）宜建立变更门阅，允许引人任何花费少于规定数额的且不要求修改合同的软件变更2）宜将对变更进行批圾组合，以进行变更的简单合并，以使对开发进度的逐响降至载小并使稳定性达到最大；
3）为处理模糊不消的、不准确的、变更的或不可测试的需求和规格说明这样一些长期的间题，应在项日承接和项自执行过程中获得接口协议。b）大多数费用模型都是基于已估计的软件。对具体项日，实际问题是确定证并调整模型。为了将其做好，应考虑下列问间题；1）从以前的项胃中搜集数据；
2）让专家运行和解释模型；
3）如果不根据组织经验校准费用模型，可能有高达一个数量级的误差；决不应只侬靠一个费用模型就提出最终的费用评估；4)
软件系统是很难目的，因此所做的变更的效果很难预测和普理；5)
GB/Z20156—2006
软件需被“打包”，以使于基经济而有效的复制、分发，安装，测试和运行；6）
量然事实上硬件和软件计划由不同的组织执行，但软件计划应与硬件计划紧密地结合，并7）
且必须将其在一起曾理。特别地，里程碑应经硬件和软件开发者之间的充分协商，以降低导致项目延期的可能性：
8）软件计划需要与客户，宿主硬件和环境计划紧密地结合。当采购软件资源时确定：
1）维护和版本升级是否是免费的2）所有权，如；授权、知识产权、专利权和版权。6.2.3执行和控制
G13/T 8566—2001
7.1.3执行和控制
此项活动包括下述任务：
7.1.3.1管理者要启动计划来满足所设定的目标和准则,在过程中实行控制。7.1.3.2管理者要监视过程的执行，提供过程进展的内部报告，按合同规定向需方提供过程进展的外部报告。
7.1.3.3管理省要对在过程执行中发现的问题进行调查,分析和解决。解决方案有可能导致计划变更。管理者有责任保证对变更的效果进行确定、控制和监视。问题及解决方案要形成文档，7.1.3. 4管理者要在协商确定的时刻报告过程进展情况,声明按计划进行,并解决进展中的疏漏情况。按照组织规程和合同要求，这种报告包括内部报告和外部报告。这项活动通常在软件PM批准了资金支出(或额外的支出)时开始。软件PM应负责监督这项活动的控制部分的成果，以确保迅速地标识和分析任何与已形成文档的计划的性能的偏离，并适当地采取纠正措施以使过程恢复在控制之下。软件PM应使用这项活动的控制部分采取纠正措施来解决出现的问题，并采取预防措施以阻止在过程执行中的预期的问题。软件测望（例如：度量），变更控制过程.软件产品和过程评价以及审核是监视和控制项目执行的手段。软件测量可以用于对照要完成的服务来确认预期的软件产品功能。注，例如、为成功地执行、评价接口约束和控制软件项目，接口控制工作组（ICWG)是必要的，ICWGs应由来自每个受到接口影响的组织的代表组成。1CWG提供了一个论坛去讨论软件和系统接口，研充可选方案以及对实施接口的最佳方法达成一致意见，[CWG建议所需的项且变班应提交给配置控制委员会(CCHB),以在实施前得到抵难。
软件PM应负责满足沟通需求，包括及时地向共利益者报告进展，公拓计划和工作授权的修改、告馅离，如有必要并形成文档。集中的、最新的数据库对于方便人员间的交流是有益的。软件 PM应确保软件项目在一致同意的时间期限内完成,以满足共利益者求。软件 PM 应与共利益者一起确定一个软件项目的首要目标。对于完成一个项目，最终目标可能不能产生一个确保最少的时间和费用的方案，例如，安全关键系统要求密集的测试。与风险相关的过程（项日风险管理裁及全部项计划中的不确定性并要求一个结构化的方法。与风险相关的过程的目的是将潜在的负面事件的响减少到小，并全面地利用改进的时机，风险者是与项目的过程或工具有关，或者是与产品对项目目标的依从性有关。对于软件特别建议：
一进度延期的矫正需要存细地评估，并且不应预期其对性能，费用或风险没有负面影响：7
GB/Z 20156—2006
一一为延期的软件项增加更多的人员可能使它更要延期，这与新人员的能力有关；一为了缓解风险，演示可使得需方和客户在选择供方之前体验软件产品能力；一用原型法开发软件的部分功能，以演示功能可以正确地执行：—一设有足够的软件工程专家就不应实施关键系统工程工作；iiKANi KAca-
一在整个项目中与共利益者一起定期评审软件诺求基线，以确保服从或调整目标（费用.时间和性能)；
一一个项目的人员和小组的数血应与预和进度相适应，并且通常不应超越控制范围一由于软件结果很难看得见，对进展的评价有很多困难。管理者应详细说明并改进确定进展的方法，以便及早发现费用或进度超出限度；由于软件开发和维护活动经常依赖于个人技巧和经验，对于正在进行的工作项目，管理者应设法阻止不必要的人员变动；
一为使性能，费用和进度中的突发性降到最低，不断地与共利益者沟通是必需的。6.2.4评审和评价
GB/T8566—2001
7.1.4评审和评价
此项活动包括下述任务：
7.1.4.1實理者应保证为满足需求而对软件产品和计划进行评价。7.1.4.2管理者应对在过程执行期间完成的软件产品、活动和任务的评价结果进行评估，以便达到目标和完成计划。
GB/T8566一2001的支持过程（例如，联合评审和审核过程）对评审利评价活动作了补。为了！
一评定软件产品、活动和任务的评审结果；遵守SPM计划、基本原理、方法和技术；形成计划和承诺文档；
满足需求；
为下一个过程、活动或任务的改进做好准备。软件PM应负责确保软件产品和计是已评价过的。软件PM应参与重要的评审。SPM计划应是跟踪软件项目过程和括动的基础。可以将事件驱动和进度驱动准则联合用于管理评审活动。正在进行的工作和要完成的工作的定期评审和评价对于成功的软件项目尼一个基本要索。软件PM应确认，预期的软件产品功能与将进行的服务的比较。在软件生存周期中软件PM应选择一组软件度盈方法以保证有日的地润亲进展。首先应通过款件工作产品祝模、成架、费用、进成、已完成的单元或构建内容与SPM计划中已形成文档的估计和要完成的工作斑相比较来确定进度。软件PM应指导软件项目组的性能评审并应提供定期的进度评审以向共利益者提供情况。使用适当的工具对评中和评价活动的帮助可能是显著的。
正在进行的工作的评价最好由熟悉项目需求、所包含的技术、产品、需求以及所使用的过程和基础设施的人进行。管理评审应双益支持软作生存周期中的所有的项日活动。商层评审应大猛地依靠功能/技术层评审并加以应用以形成全面的软件项目评估。应组织并进行进度性能特别是软件包进度的管理评审，以保证实际的评估。为了支持正确的项目评估，使用软件测盘，得到的评价分析，检查结果，走查以及联合和同行评审对于有目的地软件包评估是必要的。
应要求对重要的问题，措施项及由评审和评价产生的结果形成文档。措施项和重要的问题应跟踪8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。