第5章 IT软件项目计划管理.ppt

1、Page 1,第5章 IT软件项目计划管理,5.1 IT软件项目计划管理 5.2 确定IT软件项目的目标 5.3 项目范围管理 5.4 工作分解结构(WBS) 5.5 活动定义及估算 5.6 制定IT软件项目进度计划 5.7 方案选择 5.8 软件项目计划书,Page 2,5.1 IT软件项目计划管理,项目计划是一项复杂的、自始至终不断迭代的过程，贯穿整个项目，一直到项目结束时才结束。 IT软件项目计划管理，是指为IT项目的运作和IT项目活动的管理提供一个可靠的实施基础和可行的工作计划的过程。 IT软件项目计划从不同的角度有不同的种类： 根据计划的重要性：主计划和辅助计划 根据计划的目标：项目

2、开发计划、测试验证计划、配置管理计划、人员培训计划、系统维护计划等。,Page 3,1. 项目计划的目的,基础可靠：项目计划可以使软件项目的开发建立在可靠的基础之上，项目计划是开发人员能够遵循的文档，并据此跟踪、检查、监控计划的执行。 履行承诺：项目计划是软件项目开发的活动和向用户做出的承诺。 职责明确：将任务责任落实到具体的小组和个人，从组织管理上确保项目开发的成功。,Page 4,2. 软件项目计划管理的重要原因,软件项目计划体现了对客户需求的理解 为软件工程的实施提供了可行的计划 是开展软件项目活动的基础 是跟踪、监督、评审计划执行情况的依据 结论：没有完善的工作计划常常会事倍功半，或者

3、使项目在质量、时间和成本上达不到要求，甚至使软件工程失败。 明确项目目标和制定周密、简洁、精确的软件项目计划是成功地开发软件产品的关键。,Page 5,3. 软件项目计划管理的活动,IT软件项目计划管理主要是通过一系列计划活动体现的，主要包括：明确项目目标确定项目范围进行项目工作结构分解活动定义估算和编制项目计划确定项目进度安排,Page 6,5.2 确定IT软件项目的目标,软件项目的目标必须是明确的、可行的、具体的和可以度量的，并且需要在项目的所有项目干系人之间达成一致意见。 软件项目通常具有多目标的特性。如时间、成本、技术性能是项目的3个最基本的目标，即要求在一定的时间期限内和成本预算内完

4、成预定的工作。 不同的目标在项目生命周期的不同阶段，其重要性也不同。,Page 7,1. 确定项目目标的过程,(1)明确制定项目目标的主题项目目标一般由项目发起人或者项目提议人来确定。 (2)描述项目目标项目目标必须明确、具体，尽量定量描述，保证项目目标容易被沟通和理解，并使每个项目组成员结合项目目标确定个人的具体目标。,Page 8,2. 确定和描述项目目标遵循的基本原则,定量化原则：确定项目目标时，尽可能定量描述，使得每个目标的范围、时间、成本、性能、责任等都是明确的，可以度量和监控的。 个人化原则：每个具体目标应落实到项目组的每个成员，使每个成员都明确自己的工作和职责。 简单化原则：目标

5、的描述应当是简单而直接的，使得每个参与人员都能明确而无二义性。 现实性原则：确定的每个目标都是可以实现的，而不是追求理想化的结果。,Page 9,5.3 项目范围管理,确定项目的范围是IT软件项目计划管理的重要工作。 范围管理是为成功实现项目目标，明确规定了项目的范畴，即确定了项目的哪些方面是应该做的，哪些方面是不应该做的。 项目范围(Project Scope)包括： 项目的最终产品或者服务 实现该产品或者服务所需要执行的全部工作,Page 10,1.项目范围规划,项目范围规划就是确定项目的范围，并编写项目范围说明书。 主要包括： 项目范围规划的输入 项目范围规划的工具和技术 项目范围规划的

6、输出,Page 11,（1）项目范围规划的输入,产品描述 ：项目的成果。 项目章程 ：许可文件，它表明了项目的合法性、有效性。 制约因素：制约因素是限制项目组规模、行为及期限的一些客观条件，如项目的成本预算和时间要求。 前提条件：在项目范围规划时，并不是全部因素和条件都是被证实的，某些因素只能进行假定，如，通过招聘方式解决缺少的技术人才，但存在一定风险。,Page 12,（2）项目范围规划的工具和技术,产品分析：通过对产品的分析，可以加深对预期产品的理解，确定生产该产品的必要性和必然性，确定该产品的价值。 成本效益分析 ：估算不同方案的成本和预期的效益，利用投资收益率、投资回收期等财务手段进行

7、分析。 项目方案识别技术 ：利用各种评价、选择方案的技术和方法，对能够实现项目目标的方案进行识别，寻找和选择所有可以实现项目目标的方案。 专家评定：聘请各领域专家对各种方案进行评价、筛选。,Page 13,（3）项目范围规划的输出,项目范围说明书 ：为项目实施提供基础。 项目的合理性说明 项目成果描述 项目阶段目标 项目可交付产品或服务清单 范围管理计划：描述项目范围是如何管理的。 范围识别与核实 范围变更管理 范围管理计划稳定性评价与预测,Page 14,2.项目范围定义,项目范围定义是以范围规划的成果为依据，把项目的主要可交付产品和服务划分为更小的、更容易管理的单元，即形成工作分解结构（W

8、BS）。 （1） 范围定义的输入 范围说明书 制约因素 前提条件 其他计划结果 历史资料 （2） 使用工具：工作分解结构模板,Page 15,5.4 工作分解结构(WBS),工作分解结构是IT项目管理的一项重要内容。 WBS是计划过程的中心。 WBS是制定进度计划、资源需求、成本预算、风险管理计划和采购计划的重要基础。 WBS同时也是控制项目变更的重要基础。 WBS定义项目的范围，是一个项目的综合工具。,Page 16,1.工作分解的原则, 在同一个工作任务中，最好只包含相关的工作元素。 在同一个工作任务中，所有工作活动应该是平行的或者连续发生的，其间不应该插入不相关的工作活动。 在同一个工作

9、任务中，尽量使用相同的项目组成员，便于彼此沟通和交流。,Page 17,2.工作分解的主要方法, 类比分解法 自上而下分解法 自下而上汇集法 遵循一定的指导方针,Page 18,3.工作分解的主要步骤, 确定项目的主要可交付成果 确定每个可交付成果的详细程度 确定可交付成果的组成元素 核实分解的正确性,Page 19,4. WBS的主要用途,WBS帮助项目经理和项目团队确定和有效地管理项目工作。 WBS是一个清晰表示各项目工作之间的相互联系的结构设计工具。 WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。 WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情

10、况。,Page 20,5. 工作分解结构的设计,WBS的基本要素主要有：层次结构、编码和报告 （1）层次结构 1）WBS的分解层次由于进行工作分解既可按照项目的内在结构，又可按项目的实施顺序，并且由于项目本身的复杂程度、规模大小也各不相同，从而形成了工作分解结构图的不同层次。工作分解结构每细分一个层次表示对项目元素更细致的描述。,Page 21,2）结构设计,WBS结构的总体设计对于一个有效的工作系统来说是个关键。 结构应以等级状或树状来构成，使底层代表详细的信息，而且其范围很大，逐层向上。 WBS结构底层是管理项目所需的最低层次的信息，在这一层次上，能够满足用户对交流或监控的需要，结构上的第

11、二个层次将比第一层要窄，而且另一层次的用户所需的信息由本层提供，以后依次类推。,Page 22,2）结构设计,结构设计的原则是必须有效和分等级，但不必在结构内构建太多的层次，因为，如果层次太多则不易于有效管理。对于一个较大的项目来说，4到6个层次就足够了。 在设计结构的每一层中，必须考虑信息如何向下流入下一个层次。原则是从一个层次到另一个层次的转移应当以自然状态发生。 结构应该能够根据需要增加。 结构被译成代码时对于用户来说是易于理解的,Page 23,（2）编码设计,工作分解结构中的每一项工作，或者称为单元都要编上号码，用来惟一确定项目工作分解结构每一个单元，这些号码的全体叫做编码系统。 编

12、码系统同项目工作分解结构本身一样重要，在项目规划和以后的各个阶段，项目各基本单元的查找、变更、费用计算、时间安排、资源安排、质量要求等各个方面都要参照这个编码系统。,Page 24,（3）报告设计,设计报告的基本要求是以项目活动为基础产生所需的实用管理信息，而不是为职能部门产生其所需的职能管理信息或组织的职能报告。 报告的目的是要反映项目到目前为止的进展情况，通过这个报告，管理部门将能够去判断和评价项目各个方面是否偏离目标，偏离多少。,Page 25,6.项目经理创建WBS时，应该选择怎样的粒度?,按照需要进行WBS的分解。不存在一个硬性的规定来说明WBS的粒度如何确定。 取决于项目的复杂程度

13、、风险级别、团队技术水平以及要进行有效管理所需要的级别。 一般而言，WBS分解得越深，活动就变得越小(并且越短)。 但也不能分解得太深。应该根据需要将WBS分解，存在一个合理的限制来说明应该分解多深以及每一个活动应该有多小(或多大）。 一般方针是WBS中的每一个最低层的活动应该适合分配给某一个人，而这个人能够在一到十个工作日里完成这个工作。,Page 26,7. WBS的表示方式,WBS可以用树形的层次结构图或者行首缩进的表格表示。 后面两个图分别是一个网站开发项目的树形层次结构图表示的WBS及该项目的WBS的表格表示形式。,Page 27,树形层次图表示的WBS,Page 28,表 格 形

14、式 的WBS,Page 29,8. WBS的分解方式,WBS的分解可以采用多种方式进行： 按产品的物理结构分解 按产品或项目的功能结构分解 按照实施过程分解 按照项目的地域分布分解 按照项目的各个目标分解 按部门分解 按职能分解,Page 30,采用项目可交付成果来分解的WBS,Page 31,采用项目阶段来分解的WBS,Page 32,9.工作分解结构思考题,思考题:自己拟定一个软件开发项目并做出相应的工作结构分解图 例如:软件学院学生自然情况管理系统软件学院网站开发项目,Page 33,10.项目责任分配矩阵,项目责任分配矩阵（LRC）包括责任分配矩阵表和责任分配矩阵图，是通过表格和图的形

15、式来表述工作分解结构（WBS）中每项目工作任务的个人责任的一种明细表方法。 它是IT软件项目管理的一种有用工具，明确指出了每项工作条目由谁负责、由谁具体执行，并表明了每个角色在整个项目中的地位和作用以及相互之间的协同关系。,Page 34,表5.1 项 目 XX 责 任 分 配 矩 阵,注： P=主要责任 S=次要责任,Page 35,5.5 活动定义及估算,工作分解结构是组织管理工作的主要依据，是项目管理的框架。但形成了WBS并未结束，还需要对完成工作任务的活动进行确认，即活动定义和活动估算。 活动定义是确定为了完成在工作分解结构中规定的可交付产品和服务而必须进行的具体活动，并将其形成文档的

16、过程。 活动估算是根据项目的工作范围和资源条件等相关信息估计每个活动需要的工期。,Page 36,1.活动定义,完成每一个项目，无论项目的规模大小，都必须要完成一些特定的内容和工作，需要开展一系列的具体工作活动。 对活动的定义是工作分解结构的继续，对活动定义的一般方法有活动分解法和参照模板法等。 当完成活动定义后，其输出的结果是活动清单。活动清单包括了整个项目将要进行的所有活动，它是工作分解结构的必要扩充。,Page 37,（1）活动定义的依据,工作分解结构：活动定义的最基本的依据 项目范围说明：活动定义时必须考虑范围说明中列出的项目合理性说明和目标说明，使确定的活动是在项目范围之内的。 历史

17、信息：包括项目前期的各种信息及与项目有关的以前类似项目的信息和其他组织开发的类似项目的各种信息。 约束条件：活动定义时，必须考虑对项目的限制条件和限制因素。,Page 38,（2）活动定义的方法,活动定义的主要成果是项目的所有活动清单。常见的活动定义的方法主要有： 活动分解法：活动分解法是在WBS的基础上，将项目工作任务按照一定的层次结构逐步分解而成，以期分解成更小的、更容易控制的和更具体的活动，产生项目的活动清单。 参照模板法：将已经完成或者存在的活动清单或其中的一部分，直接作为一个新项目活动清单的模板，通过对模板中活动的修改来得到新项目的活动清单。,Page 39,（3）活动定义的输出,完

18、成活动定义后，一般可以得到以下结果： 活动清单：它是本阶段工作的最主要的阶段成果，并以文档形式提供。活动清单中应当包括完成项目所需要的全部活动列表。 详细依据：活动清单的确定需要一系列的各种需要的约束条件和前提条件，也以文档形式提供。 更新的工作分解结构：在利用WBS进行活动定义时，可能会了现并修改原来的WBS，因此，也需要对原来的的工作分解结构进行更新。,Page 40,2.活动排序,活动排序是分析活动之间的相互依赖关系，并形成文档的过程，为进一步编制切实可行的进度计划做准备。 活动排序一般可以用网络图进行描述，有时又称网络分析。 活动排序可以使用计算机辅助工具（如MS Project），也

19、可以采用手工推算。,Page 41,（1）活动排序的依据,活动清单：它是活动排序的主要基础。 产品描述：项目产品描述是项目生产的产品和提供的服务的描述文档，产品和服务的功能、性能等特性会对活动排序产生影响。 活动之间的逻辑关系：排序应考虑活动之间的相互依赖关系。 项目的约束条件：资源的约束对活动排序产生影响。 里程碑：安排活动顺序必须将里程碑事件作为活动的一部分，以确保里程碑的发生。,Page 42,（2）活动排序的工具和技术,进行活动排序时最常用的工具有： 1）前导图法（PDM）是一种用结点（方框或圆）代表活动，用带箭头的线段表示依赖关系的图示法。,图5.2 前导图法表示的网络图,Page

20、43,2）箭线图法（ADM）,是一种用带箭头的线段表示活动，通过结点将活动连接起来表示依赖关系的网络图法。,图5.3 用箭线图法表示的网络图,Page 44,（3）活动排序的输出,项目网络图：项目网络图就是项目活动及其相互关系的示意图，图中可以包括项目的全部活动，也可以只包括主要活动。除此之外，还应当有对活动的简单描述、活动排序方法、重要活动说明，以及被忽略的活动说明。 更新的活动清单：在活动排序过程中，需要对活动之间的逻辑关系进行分析和确认，可能会发现必须对某些活动进行重新分解和定义，需要更改项目活动清单，甚至工作分解结构。,Page 45,3.活动估算,活动估算：即活动持续时间估算，又称活

21、动历时估计或活动工期估计，在IT软件项目管理中有很重要的作用，它是根据项目范围、资源情况及其他有关信息对项目中已经确定的各个活动可能的持续时间进行估计的过程。 只有在准确地估算出项目活动的时间后，才能够对项目各方面的工作有比较全面的理解和有效的计划，才能实施有效的项目管理。,Page 46,（1）估算过程中需要考虑的主要因素,工作量：指完成一个活动需要投入的人工，一般以人(小)时、人天、人月为计量单位。在确定工作量时，一是考虑系统的规模、功能点数和对象点数；二是考虑生产效率。这三者的关系是：工作量=规模/效率。 资源：这里是指完成一项活动能够投入的人力资源。投入人力资源的数量一般要与项目的规模

22、合理匹配，而且与项目的总的时间要求、费用支出有关。 活动工期：理论上，在工作量一定的情况下，投入的人力资源越多，则活动的工期就越短，在一定范围内二者之间的关系近似线性，如100个人天的工作量，投入10个人时，则需要10个工作日完成；投入5个人，则需要20个工作日。,Page 47,（2）活动估算时的依据,活动清单 约束条件 资源情况 历史信息 已识别的风险,Page 48,（3）活动估算方法,专家评定法：由具有经验的项目管理专家对项目活动的持续时间进行估计和评价的方法。 经验类比估算法 利用历史数据法 德尔非法(Delphi Method) ：通过调查表，充分利用群体知识和经验的一种估计方法。

23、 进行估算时，应当注意： 活动工期：包括实际的工作时间和等待时间 投入资源数量与活动工期之间并不是线性关系 IT软件项目不确定因素多，工期难以准确估计,Page 49,（4）活动估算的输出,活动持续时间：本阶段工作的最主要成果，估计出完成每个活动所需要的持续时间，该时间可以存在一个允许的变动范围。 活动持续时间估算的依据：有时也需要将进行活动估算的依据作为补充材料写入活动持续时间描述文档中。 变更的活动清单：项目活动估算中，也会发现和更改活动定义和相互关系等，因此，需要对活动清单进行修正。,Page 50,5.6 制定IT软件项目进度计划,1.制定软件项目计划的必要性 制定软件开发项目的进度是

24、为了更好地完成开发任务。 当任务是短期的或非常简单时，可以按固定顺序来完成，不一定必须进行严格的进度管理。 当任务变得庞大复杂、作业量增加、进度受到限制或在同一时间内要完成多个项目时，就需要对复杂的时间进度进行管理，需要制定一份有效的进度表，即必须进行进度管理。,Page 51,2.制定软件项目进度计划的指导原则,1）将用于编制软件项目计划及跟踪软件项目的工作文档化。 2）对于软件项目的实施采用文档化的承诺。 3）相关的机构或个人认可他们对软件项目的承诺。 4）指定软件项目负责人负责落实软件项目的承诺并制定项目的软件开发计划。 5）确保软件项目存在一份文档化的、并被认可的工作任务说明。 6）软

25、件开发计划要指定人员角色分工，明确责任。 7）对软件项目所需要的、适当的资源及资金做出计划。,Page 52,2.制定软件项目进度计划的指导原则,8）对软件项目负责人、软件工程师及其他与软件项目计划编制有关的人员进行适合其职责范围的培训。 9）成立相关软件项目组及相关的方案论证小组。 10）软件项目组及相关的方案论证小组在整个项目生命 期内参加全部的项目计划编制工作。 11）按照书面流程与高级管理人员或企业外部机构软件项目的承诺进行复审。 12）明确划分为预先定义的、规模可管理的阶段的软件生命周期。 13）按照书面流程开发项目的软件开发计划。,Page 53,2.制定软件项目进度计划的指导原则

26、,14）将软件项目计划文档化。 15）确定软件项目需要建立及维护控制的软件产品。 16）按照书面流程进行对软件产品规模的估计（或软件产品规模的改变）。 17）按照书面流程对软件项目工作量及费用估计。 18）按照书面流程进行对项目所需要的关键计算机资源的估计。 19）按照书面流程确定项目的软件开发进度。 20）识别、评估与项目的费用、资源、进度及技术方面相关的软件风险，并文档化。,Page 54,2.制定软件项目进度计划的指导原则,21）准备项目的软件工程机制及支撑工具的计划。 22）记录软件计划编制数据。 23）制定并使用度量方法以确定软件计划活动的状态。 24）定期与高级管理人员对软件项目计

27、划活动进行复审。 25）以定期及事件驱动方式对软件项目管理人员及软件项目计划活动进行复审。 26）对软件质量保证人员及软件项目计划活动、工作产品进行回顾及审核，并将结果文档化。,Page 55,3.项目进度计划的制定过程,（1） 制定项目进度计划的依据 项目网络图：活动之间的关系描述示意图 活动持续时间估计：预计的每个活动可能的持续时间 资源需求：完成活动所需资源的种类及数量清单 资源安排描述：资源的合理安排 日历：标明各资源可利用的时间 约束条件：制约项目进展的因素，如时间、人员等 假设条件：一些风险的预料 提前或滞后要求：允许提前或延迟的程度 风险管理计划：管理各种风险的措施,Page 5

28、6,（2）制定进度计划的工具和技术,数学分析法：包括关键路径法(CPM)、图形评审技术(GERT)和计划评审技术(PERT)等。 持续时间压缩法：费用交换(增加费用换取工期)和并行处理(串行活动改为并行)。 模拟法：三点估计法等（统计方法）。 资源分配的启发式方法：资源有限的合理分配法(资源有限)和资源均衡利用法(工期限定)。 项目管理软件：根据项目的资源和工期，自动计算和分析最佳工期及计划安排，以图表方式输出。,Page 57,（3）制定项目进度计划的输出,项目进度计划：最重要的阶段成果，包括每项活动的计划开始时间和预期结束时间。主要表达形式有：带有日历的项目网络图、甘特图、里程碑图、时间坐

29、标网络图等。 详细依据说明：所有约束条件和假设条件的详细说明，以及应用方面的详细说明等。 进度管理计划：说明何种进度变化应给予处理。 更新的项目资源需求：若更改了活动对资源需求的原先估计，需重新编制项目资源需求文件。,Page 58,4.软件项目计划的主要活动,1. 计划初始阶段：确定项目经理 2. 指定软件开发计划（SDP, Software Development Plan ）：提交SDP草稿 3. 对SDP草稿进行审查和批准 4. 实施软件开发计划 5. 软件开发过程的质量和评价 6. 修改SDP,Page 59,主要活动,Page 60, 5.进度安排常用方法,1）网络图 网络图是适用

30、于进度控制的一种项目管理工具。 关键路径法（CPM）属于一种数学分析方法，包括理论上计算所有活动各自的最早和最晚开始日期与结束日期。,Page 61,绘制网络图,CPM方法可以使用活动-箭线网络图，也可以使用活动-节点网络图。 绘制网络图的要求： 一个项目网络只有一个开始节点和结束节点 连接有周期（时间），节点没有周期（时间） 时间从左边流向右边 节点通常按次序编号 网络不能包含回路 网络不能包含悬挂 可以使用虚活动,Page 62,示例：虚活动,有公共节点的两条路径,Page 63,示例：请找出下面各图的错误！,解决:节点4和6合并,任务E和F 两个结束节点！,任务D 悬挂！,Page 64

31、,示例：请找出下面各图的错误！,解决:由实际情况定,任务E、F和G 存在环路！,任务F悬挂！ 或 任务E方向错,解决:根据实际情况消除环路,Page 65,关键路径法（CPM）,关键路径法中涉及的基本术语 : （1）最早开始时间（ES：Early Start） （2）最迟开始时间（LS：Late Start） （3）最早完成时间（EF：Early Finish） （4）最迟完成时间（LF：Late Finish） （5）浮动时间（Float Time）自由浮动（FF：Free Float）总浮动（TF：Total Float）,Page 66,关键路径法（CPM）,关键路径的定义: 关键路径是

32、由这样一些任务构成的集合它们的工期改变会直接影响到整个项目的工期。 在网络图中，关键路径是浮动时间为0或最小、时间花费最长的路径。 关键路径上的任何活动的延迟都会导致整个项目完成时间的延迟，它是完成项目的最短时间量，关键路径上的任何任务都是关键任务。,Page 67,确定关键路径(1),（1）正推法计算每项任务最早时间 在网络图中，按照时间顺序(从开始到结束)计算各个任务的最早开始时间和最早完成时间的方法称为正推法。 方法:从左到右，从上到下进行任务编排 ES = max 所有紧前活动的最早完成时间EF EF = ES本任务持续时间,Page 68,确定关键路径(2),（2）逆推法计算每项任务

33、的最迟时间 在网络图中，按照逆时间顺序计算各个任务的最晚开始时间和最晚完成时间的方法称为逆推法。 方法:LF = min所有紧后任务的最迟开始时间LSLS = LF本任务持续时间,Page 69,确定关键路径(3),（3）计算每项任务的总浮动时间（TF）和自由浮动时间（FF） 总浮动时间(TF)是指不影响总工期的情况下本任务可以浮动的时间 自由浮动时间(FF)是指本任务最早完成后，不影响其紧后任务最早开始时间的情况下可以自由浮动的时间TF = LSES = LFEFFF = min所有紧后任务的ESEF,Page 70,1,2,3,5,4,6,开始,A=2,D=3,E=4,C=5,F=6,结束

34、,CPM实例1计算找出关键路径,B=7,图例,Page 71,CPM实例2计算找出关键路径,思考：CPM实例3计算找出关键路径,Page 73,解：CPM实例3网络图,T1,T2,T3,T5,T4,T6,T7,T8,T9,T11,T10,T12,T13,T15,T14,T16,34,20,15,15,25,7,6,4,4,30,28,25,15,6,2,1,Page 74,思考：CPM实例4,Page 75,思考：CPM实例5自己给出时间,Page 76,6. 进度安排,（1）软件延迟的基本原因,不现实的截止期限； 客户需求发生变化，而需求的变化没有能够反映在项目进度的变化中； 对工作量和完成

35、该工作所需的资源数量估计不足； 项目开始时，未考虑可预测的和不可预测的风险； 事先无法预计的技术困难和人力资源困难； 由于项目组成员之间的交流不畅而导致的延期； 项目管理者未能发现进度拖后，或发现未能及时采取措施解决这一问题。,Page 77,（2）关于“不现实的交付日期”问题的妥善处理,进度安排技术、估算和风险分析等管理，通常都需要在一个定义好的截止期限的约束之下实现。 如果最乐观的估算都表明截止期限是不现实的，那么一个胜任的项目管理者就应该“保护其队伍免受不适当的进度安排的压力，并将这种压力反映给施加压力的一方”。,Page 78,“不现实的交付日期”处理实例,假定一个软件开发小组的任务是

36、构造一个医疗诊断仪器的实时控制器，该控制器需要在9 个月之内推向市场。 在进行了仔细的估算和风险分析之后，软件项目管理者得到的结论是在现有人员条件下，需要14个月的时间才能完成这一软件。,想一想：,怎么办,Page 79,处理办法（参考）,利用历史数据估算合适的交付日期，并说服客户，为什么该交付日期是不现实的。 向客户提交几种选择方案，例如： 增加预算，引入额外的资源，以便能够在9个月时间内完成这一工作。 去掉一部分需求中所列出的软件功能和特性。 不顾现实条件的约束，希望项目能够在 9个月时间内完成。,Page 80,（3）进度安排的基本原则,软件项目进度安排是一种活动，它通过将工作量分配给特

37、定的软件工程任务，而将所估算的工作量分布于计划好的项目持续时间内。 进度是随着时间的改变而不断演化的 在项目计划的早期，建立一个宏观的进度安排表，该进度表标识所有主要的软件工程活动和这些活动影响到的产品功能。 随着项目的进展，宏观进度表中的每个条目都被细化成一个“详细进度表”，于是完成一个活动所必须实现的特定软件任务被标识出来，并进行进度安排。,Page 81,（4）软件项目进度安排基本原则,项目划分：项目必须被划分成若干个可以管理的活动或任务。为了实现项目的划分，对产品和过程都需要进行有效分解。 活动的相互依赖性：各个被划分的活动或任务之间的相互关系必须是确定的。如：有些任务必须顺序发生，有

38、些任务则可以并发进行；有些活动只有在其他活动产生的工作产品完成时才能开始，有些则可以独立进行。,Page 82,（4）软件项目进度安排基本原则,时间分配：必须为每个被调度的任务分配一定数量的工作单位。例如，若干人天或人月的工作量。此外，必须为每个任务指定开始和结束日期，这些日期是与工作完成的方式相互依赖的（全职还是兼职）。 定义责任：为每项任务都指定某个特定的小组成员负责。,Page 83,（4）软件项目进度安排基本原则,工作量确认：每个项目都有预定数量的人员参与，在进行时间分配时，项目管理者必须确保在任意时段中分配给任务的人员数量不应超过项目组中的人员数量，即要进行工作量确认。例如，一个项目

39、分配了3名员工参加，即每天可分配的工作量为3人天，若某一天，需要完成7项开发任务，每个任务需要0.50人天的工作量，这时，所需的工作量就是3.5人天，大于可用于分配的工作量。,Page 84,（4）软件项目进度安排基本原则,定义结果：为每项任务都定义一个明确的结果。对于软件项目而言，结果通常是一个工作产品（例如一个模块的设计）或工作产品的一部分。通常是将多个工作产品组合成“可交付产品”。 定义里程碑：为每项任务或任务组都指定一个项目里程碑。当一个或多个工作产品经过质量复审并且得到认可时，标志着一个里程碑的完成。,Page 85,5.7 方案选择,制定项目计划的第一阶段应该是定义相关组织和项目的

40、特定目标，目标应该具有高可维护性、低成本、高可靠性等特征。 “最好”的方案并不一定是最好的选择。 例如：某产品的开发有三个可选方案，每种方案的目标和评分如下表所示。,Page 86,1. 极线图,极线图法是由一些极线轴构成的图。 每根轴都代表项目想要获得的一个目标。 每个特定的方案都由一系列轴绘制而成。 其中包围面积最大的方案就是最好的方案。 在极线图中，对于每个指标，最希望得到的结果应该绘制在远离原点的方向上，即轴的最外边，最不希望出现的后果则绘制在原点。 极线图法只是一种辅助工具，并不是做出决策的惟一标准，一个方案可能在极线图中是最优的，但可能是一个不可行的方案(如与关键目标相违背等)。,

41、Page 87,图5.9 可选方案极线图,Page 88,2. 决策树法,决策树法又称盈利矩阵法。在盈利矩阵中，列出了各种可能的策略方案和最大收益。 如表5.5所示，列出实现项目的两种方案策略，并且预测了两种策略的最大成本和最小成本。 盈利就是最大成本与最小成本之间的差值。 表5.5 可选方案数据表,Page 89,两种可用的决策树法,最大最小策略：这是一种保守的决策方法，它的目标是使项目的损失最小。该方法假设项目成本最大时发生的概率比成本最小时发生的概率大，因此盈利应该是负数。因此，选择盈利最小的方案。在上面的例子中，最低的损失是15 000，应该选择方案B。 乐观法则：又称为最大最大策略，

42、它选择的方案应该是能够获得最大的利润的(盈利是正数)方案。最大最大策略假设项目成本最小时发生的概率比成本最大时发生的概率大。在这个例子中，最大最大策略应该选择方案A。,Page 90,两种决策树法存在的问题,如果A和B两种方案发生的概率均为0.5，则每种方案的可 能成本为：A： 可能成本=(0.5100000)+(0.540000)=70000B： 可能成本=(0.570000)+(0.555000)=62500因此，最优方案应该选择方案B。 又如：两种方案的最可能成本分配为多少？最优方案应如何选择？,Page 91,5.8 软件项目计划书,1. 引言1.1 计划的目的1.2 项目的范围和目标

43、1.2.1 范围描述1.2.2 主要功能1.2.3 性能1.2.4 管理和技术约束 2. 项目估算2.1 使用的历史数据2.2 使用的评估技术2.3 工作量、成本、时间估算,Page 92,软件项目计划书,3. 风险管理战略3.1 风险识别3.2 有关风险的讨论3.3 风险管理计划3.3.1 风险计划3.3.2 风险监视3.3.3 风险管理 4. 日程4.1 项目工作分解结构4.2 进度安排(甘特图)4.3 资源表,Page 93,软件项目计划书,5. 项目资源5.1 人员5.2 硬件和软件5.3 特别资源 6. 人员组织6.1 组织结构6.2 管理报告 7. 跟踪和控制机制7.1 质量保证和

44、控制7.2 变化管理和控制 8. 附录,Page 94,案例1：工期拖延了怎么？,某公司准备开发一个软件产品。 在项目开始的第一个月，项目团队给出一个非正式的、粗略的进度计划，估计产品开发周期为1218个月。 一个月后，产品需求已经写完并得到了批准，项目经理制定了一个12个月期限的进度表。 因为该项目与以前的一个项目类似，因此项目经理为了让技术人员去做一些“真正的”工作（如设计、开发等），在制定计划时就没让技术人员参加，而是自己编写了详细进度表并交付审核。,Page 95,案例1：工期拖延了怎么？（续）,每个人都相当乐观，都知道这是公司很重要的一个项目。然而没有一个人重视这个进度表。 公司要求

45、尽早交付客户产品的两个理由是： 为下一个财政年获得收入； 有利于确保让主要客户选择这个产品而不是竞争对手的产品。 团队中没有人对尽快交付产品产生怀疑。,Page 96,案例1：工期拖延了怎么？（续）,在项目开发阶段，许多技术人员认为计划安排得太紧： 没考虑节假日 没有考虑新员工需要熟悉和学习的时间 计划是按最高水平的人员的进度安排的 除此之外，项目组成员也提出了一些其他问题，但基本都没有得到相应的重视。 为了缓解技术人员的抱怨，计划者将进度表中的计划工期延长了两周。 虽然不能完全满足技术人员的需求，但还是必要的，在一定程度上减少了技术人员的工作压力。,Page 97,案例1：工期拖延了怎么？（

46、续）,技术主管经常说：“产品总是到非做不可时才做，所以才会有现在这样一大堆要做的事情。” 计划编制者抱怨说：“项目中出现的问题都是由于技术主管人员没有更多的商业头脑造成的，他们没有意识到为了把业务做大，需要承担比较大的风险，技术人员不懂得做生意，我们不得不促使整个组织去完成这个进度。”,Page 98,案例1：工期拖延了怎么？（续）,在项目实施过程中，这些争论一直很多，几乎没有一次能达成一致意见。 商业目标与技术目标总是不能达成一致。 为了项目进度，项目的规格说明书被匆匆赶写出来。但提交评审时，意见很多，因为很不完善，但为了赶进度，也只好接受。 在原来的进度表中有对设计进行修改的时间，但因前期

47、分析阶段拖了进度，即使是加班加点工作，进度也很缓慢。这之后的编码、测试计划和交付产品也因为不断修改规格说明书而不断进行修改和造成返工。,Page 99,案例1：工期拖延了怎么？（续）,12个月过去了，测试工作的实际进度比计划进度落后了6周。 为了赶进度，人们将单元测试与集成测试同步进行。 但麻烦接踵而来，由于开发小组与测试小组同时对代码进行测试，两个组都会发现错误，但是对测试人员发现的错误响应很迟缓，因为开发人员正忙于完成自己的工作。,Page 100,案例1：工期拖延了怎么？（续）,为了解决这个问题。项目经理命令开发人员优先解决测试组提出的问题，而测试人员也强调测试的重要性，但最终的代码还是

48、问题很多。 现在进度已经拖后10周，开发人员加班过度，经过如此长的加班时间，大家都很疲惫，也很灰心和急躁。而工作还没有结束，如果按照目前的进度方式继续的话，整个项目将比原计划拖延4个月以上的时间。,Page 101,案例1：工期拖延了怎么？（完）,问题： 在本案例中，我们能吸取到什么教训？ 编制计划时，邀请项目组成员参与有哪些好处？ 编制进度计划时需要考虑哪些重要因素？ 一个成功的项目管理其基础是什么？,Page 102,案例2：小王该怎么办？,公司背景 某系统集成公司现有员工50多人，业务部门分为销售部、软件开发部、系统网络部等。 项目签约 经过近半年的酝酿后，在今年1月份，公司的销售部直接

49、与某银行签订了一个银行前置机的软件系统开发的项目。合同规定，6月28日前系统必须投入试运行。在合同签订后，销售部将此合同移交给了软件开发部，进行项目的实施。,Page 103,案例2：小王该怎么办？（续）,项目组简介 项目经理小王做过5年的系统分析和设计工作，但这是他第一次担任项目经理。小王兼任系统分析工作，项目组有2名有1年工作经验的程序员，1名测试人员，2名负责组网和布线的系统工程师。项目组的成员均全程参加项目开发。 项目计划 在承担项目之后，小王组织大家制定了项目的WBS，并依照以往的经历制定了本项目的进度计划，简单描述如下：,Page 104,案例2：小王该怎么办？（续）,应用子系统 1月5日2月5日进行需求分析； 2月6日3月26日进行系统设计和软件设计； 3月27日5月10日编码； 5月11日5月30日系统内部测试； 综合布线：2月20日4月20日完成调研和布线 网络子系统：4月21日5月21日设备安装、联调 系统内部调试、验收 6月1日6月20日试运行； 6月28日系统验收。,Page 105,案例2：小王该怎么办？（完）,