第3讲项目管理范围.pptx

第3讲项目管理范围.pptx

《第3讲项目管理范围.pptx》由会员分享，可在线阅读，更多相关《第3讲项目管理范围.pptx（32页珍藏版）》请在冰点文库上搜索。

第三讲软件项目范围管理,3.1软件项目范围管理概述,3.1.1项目范围管理3.1.2软件项目范围与系统需求,3.1.1项目范围管理,项目范围对于项目的影响是决定性的。

项目只有完成所有项目干系人达成共识的项目范围中的全部工作才能结束，因此一个范围不明确或干系人对范围理解不一致的项目不可能获得成功。

范围不明确最可能的后果是项目的范围蔓延，项目永远也做不到头；而范围的理解不一致的结果往往是项目组的工作无法得到其他干系人的认可。

对于软件项目来说，这两种情况是非常普遍的。

需求不明确的系统总会产生新的需求，开发团队只知道每天都在工作，但不知道哪一天才能完成工作；需求理解的偏差则会造成严重的系统缺陷，用户不接受一个没有满足要求的软件系统，开发团队花费了大量的工作返工已经完成的系统。

表3-1PMBOK2004对范围管理的定义,项目范围管理过程,美国项目管理学院（PMBOK2004）定义的包括以下几个过程：

范围规划制定项目范围管理计划，记载如何确定、核实与控制项目范围，以及如何制定与定义工作分解结构（WBS）。

范围定义制定详细的项目范围说明书，作为将来项目决策的根据。

制作工作分解结构将项目大的可交付成果与项目工作划分为较小和更易管理的组成部分。

范围核实正式验收已经完成的项目可交付成果。

范围控制控制项目范围的变更。

上述过程不仅彼此之间，而且还与其他知识领域过程交互作用。

3.1.2软件项目范围与系统需求,项目是临时的，任何项目都用明确的起点和终点，这也就意味着，项目中的工作是有限的，在项目中存在一个清晰的界限，通过这个界限可以判断哪些工作属于这个项目，哪些工作不属于这个项目。

位于项目边界内的工作就属于项目范围内，而位于项目边界外的工作，无论多少，甚至可能同项目有着千丝万缕的联系，都不属于项目范围。

在软件项目中，软件系统的需求同项目范围有着密切的关系。

首先，交付一个可以满足用户需求的软件系统是软件项目中最重要的工作之一。

因此，这个软件系统的功能特征就决定了主要的项目范围。

当然，实施软件系统这不是全部，除了系统范围外，软件项目的范围中还经常包括更多的内容。

比如一些软件项目的交付物中会包括系统功能规格说明书、系统设计说明书、系统使用手册、使用培训等等。

就软件项目而言，项目范围中较难把握的一部分就是软件系统的范围，或者说是软件系统的功能特性。

绝大多数的软件项目的需求都存在问题，每一个需求问题都会带来不明确的项目范围。

软件本身是抽象的，也没有找到一种简单的、可以避免歧义和理解偏差的系统功能描述的方法，因此对软件系统的描述经常会有模糊和二义性，基于这样的描述定义出的系统范围也是模糊的。

这也是软件项目范围难于管理的重要原因。

3.2范围规划,软件项目范围规划的工作要点包括四个方面。

如何确定详细的项目范围。

如何根据详细项目范围得到WBS。

如何验收已经交付的项目成果。

如何控制并管理范围变更。

软件项目管理实际工作中需要明确以下几点：

范围规划是范围管理的第一步，是对整个范围管理工作的计划，是指导范围管理工作的指南。

因此，在范围规划的工作就是定义过程的工作，定义后续工作的方法、时间、资源、准则等内容。

范围规划是一个渐进的过程，不是一蹴而就的。

在项目的最初阶段，就需进行范围规划工作，得到范围管理计划。

通过范围规划过程得到的范围管理计划可能不是独立的，而是融入到项目管理计划或其他的文档中。

3.3范围定义,3.3.1范围定义概述3.3.2软件产品范围3.3.3项目范围说明书,3.3.1范围定义概述,顾名思义，范围定义就是定义项目的范围，即根据范围规划阶段定义的范围管理计划，采取一定的方法，逐步得到精确的项目范围。

项目范围说明书是范围定义工作最主要的成果，除此之外，由于项目范围变得更加清晰，范围管理计划也需要随之更新。

范围说明书是范围定义工作最主要的产品，也是描述、界定项目范围的文件。

一般地，范围说明书包括项目目标、产品范围、项目要求等内容。

在定义项目范围、编写项目范围说明书时需要注意以下几个问题：

与项目中的很多文档一样，范围定义的工作也不可能一次性彻底完成，需要不断的改进和精化。

项目范围说明书一定要做到量化且可验证，否则会遇到难以核实和控制的问题。

软件项目的产品范围即软件产品的功能特性，是一个抽象的概念。

3.3.2软件产品范围,软件项目的目标是开发或实施某软件系统或产品，软件系统本身就是软件项目最终要的交付物，软件系统（产品）范围也是软件项目范围中最重要的一部分。

在软件项目中，软件系统的范围经常表现为软件需求规格说明书（SRS），其中一般会包括下面三部分内容：

功能特征描述。

系统接口描述。

质量特征描述。

在描述软件系统功能特征时，要注意以下几个问题：

功能分层。

通过对功能特征分层次的处理，可以让功能特征变得更清晰，更易于理解和管理。

文字描述尽量简洁，对于难以说清楚地问题通过图表的方式描述。

考虑系统状态的变化。

考虑不同的使用者。

系统功能不但同系统状态相关，往往还同系统用户相关。

除了上面谈到的这四点外，在功能特征描述中还可以通过其他的方式把功能特征描述的更清晰，例如标示号、分类、优先级、场景、实例等方式。

这些方式可以根据项目的具体特点来采用。

3.3.3项目范围说明书,项目范围说明书是范围定义的工作成果，也是项目范围的基准。

在实际软件项目中，可能最终不会出现一份叫做项目范围说明书的文档，但其中的内容可能会被多个文档包括，如项目章程、项目计划、需求规格说明书等。

3.4创建工作分解结构,3.4.1工作分解结构WBS3.4.2创建WBS的过程,3.4.1工作分解结构WBS,工作分解结构是软件项目管理中最常用的工具，WBS在范围管理中创建，在时间管理、成本管理中都需要使用。

根据PMI的定义，WBS是以项目的可交付成果为中心，为了完成项目的目标和创造项目的可交付成果，由项目团队进行的一种对项目工作有层次的分解。

图3-2软件项目WBS实例,3.4.2创建WBS的过程,简单而言，创建WBS就是对项目的分解过程。

通过对大的项目逐步分解为更细小的粒度和个具体的工作就可以得到项目的WBS。

但分解过程是一种主观的过程，具有不确定性，因此对同一项目的多次分解得到的结果可能完全不同，越是复杂的项目其结果差异越大。

WBS本身没有正确和错误之分，最多只能判断WBS是否完整，是否涵盖的整个项目，有无遗漏。

但不同的WBS将对个项目带来的时间计划、成本计划等管理过程会有很大的区别，项目的最终结果也会不同，这就是不同的WBS有不同的质量。

质量良好的WBS让项目更容易成功，而质量较差的WBS会给项目引入附加的风险，带来额外的麻烦。

分解WBS的方法,对于复杂度和抽象程度都远远超出房间装修的软件项目来说，甚至可能得出更糟糕的WBS。

为了解决这种问题，就需要科学的分解WBS的方法。

常见的分解方法有：

类比法、自顶向下的分解、自底向上的归纳这三种方法。

分解策略,对相同的项目存在完全不同的分解方法，在制作项目WBS时，有不少分解策略可供选择，这里介绍两种软件项目中经常使用的分解策略。

根据交付物进行分解。

根据项目阶段划分整个项目。

图3-5根据交付物分解得到的WBS,图3-6RUP的范例WBS,3.5范围核实,范围核实指的是根据已经定义的项目范围说明书和项目交付的成果来核实项目成果是否可以让客户或利害关系者的满意。

即使由于某些原因造成项目提前中止，也需要验证项目的完成度，了解哪些内容已经完成而哪些内容尚未完成。

范围核实即交付物验收同质量控制容易混淆到一起。

交付物的验收同质量控制是不同的。

范围核实步骤,一般地，对项目范围核实的工作由项目团队和项目的关键利益相关者进行。

在进行范围核实时，一般遵循下面的步骤：

确定范围核实的时间；估计范围核实需要的投入；确定范围正式被接受的标准和要素；组织并召开范围核实会议；通常情况下，在进行范围核实前，项目组需要先进行质量控制工作，如系统测试等工作，以确保范围核实工作的顺利完成。

3.6范围控制,“唯一不变的就是变化”，在整个项目过程充满了各种各样的变化，很多变化都会造成项目范围的变化。

当项目范围变化的时候，意味着项目中需要做的工作发生了变化，这必然会造成项目进度计划、人员安排、成本等一系列问题的变化。

处理不当则会造成项目时间、成本等方面的问题，增加项目风险，甚至造成项目陷入混乱的状态。

范围控制就是为了解决该问题，消除范围变更造成的不利影响。

项目范围控制是通过变更控制系统完成的。

在理解范围控制时，需要注意以下三点：

范围控制是必须的，不存在无变化的项目。

未必避免在发生变化的时候手忙脚乱，就一定要首先建立起变更控制系统来处理未来可能发生的变更。

项目范围变化，并不仅仅意味着工作量的增加。

项目范围的变化往往还意味着项目更贴近客户的要求、更适应项目的环境，范围控制需要做的是消除变更带来的不良影响。

项目范围控制的目的不是阻止变更的发生。