1、第9章 软件项目管理过程与成本估算,9.1 软件项目管理过程 9.2 成本估算 9.3 风险分析,9.1 软件项目管理过程,软件项目管理包括哪些？进度管理、成本管理、质量管理、人员管理、资源管理和标准化管理。管理的对象是什么？进度、系统规模及工作量估算、经费、组织机构和人员、风险、质量、作业和环境配置等。软件项目管理所涉及的范围覆盖了整个软件生存期。,为使软件项目开发获得成功，一个关键问题是必须对软件开发项目的工作范围、可能遇到的风险、需要的资源（人、硬软件）要实现的任务经历的里程碑、花费工作量（成本）以及进度的安排等做到心中有数。而软件项目管理可以提供这些信息。通常这种管理在技术工作开始之前
2、就应开始， 而在软件从概念到实现的过程中继续进行，并且只有当软件开发工作最后结束时才终止。,9.1 软件项目管理过程,1. 启动一个项目,在制定软件项目计划之前，必须先明确项目的目标和范围、考虑候选的解决方案、标明技术和管理上的要求。有了这些信息，才能确定合理、精确的成本估算，实际可行的任务分解以及可管理的进度安排。项目的目标标明了软件项目的目的但不涉及如何去达到这些目的。范围标明了软件要实现的基本功能，并尽量以定量的方式界定这些功能。候选的解决方案虽然涉及方案细节不多，但有了方案，管理人员和技术人员就能够据此选择一种“好的”方法，给出诸如交付期限、预算、个人能力、技术界面及其他许多因素所构成
3、的限制。,2. 制定项目计划,制定计划的任务包括如下方面： 估算所需要的人力（通常以月为单位）、项目持续时间（以年份或月份 为单位）和成本（以元为单位）； 作出进度安排，分配资源，建立项目组织及任用人员（包括人员的地 位、作用、职责和规章制度等），根据规模和工作量估算分配任务 ； .进行风险分析，包括风险识别、风险估计、风险优化、风险驾驭策略 风险解决和风险监督。这些步骤贯穿在软件工程过程中； 制定质量管理指标，识别定义好的任务，管理人员对结束时间的掌握 并识别和监控关键路径以确保结束，对进展如何度量，以及建立分隔任务的里程碑； 编制预算和成本； 准备环境和基础设施等 ；,3. 计划的追踪和控
4、制,一旦建立了进度安排，就可以开始着手追踪和控制活动。 由项目管理人员负责在过程执行时监督过程的实施，提供过程进展的内部报告，并按合同规定向需方提供外部报告。 对于在进度安排中标明的每一个任务，如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响 可对资源重新定向，对任务重新安排，或者（作为最坏的结果）可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制软件的开发,4. 评审,项目管理人员应对计划完成程度进行评审，对项目进行评价。并对计划和项目进行检查, 使之在变更或完成后保持完整性和一致性。,5. 编写管理文
5、档,项目管理人员根据合同确定软件开发过程是否完成。如果完成，应从完整性方面检查项目完成的结果和记录，并把这些结果和记录编写成文档并存档。,9.2 成本估算,软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。它不同于其他物理产品的成本，它不包括原材料和能源的消耗，主要是人的劳动的消耗。人的劳动消耗所需代价就是软件产品的开发成本。另一方面，软件产品开发成本的计算方法不同于其他物理产品成本的计算。 软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。 因此软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试以及整个软件开发全过
6、程所花费的代价作为依据的。,9.2.1 软件开发成本估算方法,对于一个大型的软件项目，要进行一系列的估算处理 主要靠分解和类推的手段进行。基本估算方法分为3类。 1.自顶向下的估算方法。这种方法的主要思想是从项目的整体出发，进行类推。即估算人员根据以前已完成项目所消耗的总成本（或总工作量），来推算将要开发的软件的总成本（或总工作量），然后按比例将它分配到各开发任务单元中去。这种方法的优点是估算工作量小，速度快。缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。, 自底向上的估计法。这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的
7、开发工作量，然后把它们加起来，得到软件开发的总工作量。这是一种常见的估算方法。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量（配置管理、质量管理、项目管理）。所以往往估算值偏低，必须用其他方法进行检验和校正。 差别估计法。这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。,9.2.1 软件开
8、发成本估算方法,9.2.2 专家判定技术,专家判定技术就是由多位专家进行成本估算。由于单独一位专家可能会有种种偏见，譬如有乐观的、悲观的、要求在竞争中取胜的、让大家都高兴的种种愿望及政治因素等。因此，最好由多位专家进行估算，取得多个估算值。Rand公司提出Deiphi技术，作为统一专家意见的方法。用Deiphi技术可得到极为准确的估算值。,Deiphi技术的步骤如下：, 组织者发给每位专家一份软件系统的规格说明书（略去名称和单位） 和一张记录估算值的表格，请他们进行估算。 专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即 ai 该软件可能的最小规模（最少源代码行数）； mi
9、该软件最可能的规模（最可能的源代码行数）； bi 该软件可能的最大规模（最多源代码行数）。 无记名地填写表格，并说明做此估算的理由。在填表的过程中，专家互相不进行讨论但可以向组织者提问。 组织者对专家们填在表格中的答复进行整理，做以下事情： 计算各位专家（序号为i，i1,2,n，共n位专家）的估算期望值Ei，并综合各位专家估算值的期望中值E：对专家的估算结果进行分类摘要。, 在综合专家估算结果的基础上，组织专家再次无记名地填写表格。然后比较两次估算的结果。若差异很大，则要通过查询找出差异的原因。 上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。在此过程中不得进行小组
10、讨论。 最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。 此方法的缺点是人们无法利用其他参加者的估算值来调整自己的估算值。宽带Deiphi技术克服了这个缺点。在专家正式将估算值填入表格之前，由组织者召集小组会议，专家们与组织者一起对估算问题进行讨论，然后专家们再无记名填表。组织者对各位专家在表中填写的估算值进行综合和分类后，再召集会议，请专家们对其估算值有很大变动之处进行讨论，请专家们重新无记名填表。这样适当重复几次，得到比较准确的估计值。 由于增加了协商的机会，集思广益，
11、使得估算值更趋于合理。,Deiphi技术的步骤如下：,9.2.3 成本估算的经验模型,1. COCOMO模型 由Boehm提出的机构性成本模型COCOMO（Constructive Cost Mode），是最精确、最易于使用的成本估算方法之一。该模型分为：基本COCOMO模型，是一个静态单变量模型，对整个软件系统进行估算；中级COCOMO模型，是一个静态多变量模型；详细COCOMO模型，将软件系统模型分为系统、子系统和模块三个层次，有不同的工作量因素分级表，供不同的层次估算使用。 2Putnam模型这是1978年Putnam提出的模型，是一种动态多变量模型。它是假定在软件开发的整个生存期中工作
12、量有特定的分布。这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。,9.3 风险分析,风险分析实际上是四个不同的活动：1.风险识别2.风险估计3.风险评价4.风险驾驭。,9.3.1 风险识别,风险识别就是要系统地确定对项目计划（估算、进度、资源分配）的威胁； 通过识别已知的或可预测的风险就可能设法避开风险或驾驭风险。,1 风险类型,用各种不同的方法对风险进行分类是可能的。从宏观上来看，可将风险分为项目风险、技术风险和商业风险。 项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。项
13、目风险是指潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，以及它们对软件项目的影响。项目复杂性、规模和结构的不确定性也构成项目的（估算）风险因素。 技术风险威胁到待开发软件的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。技术风险是指潜在的设计、实现、接口、检验和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧和最新技术（不成熟）也是风险因素。技术风险之所以出现是由于问题的解决比我们预想的要复杂。 商业风险威胁到待开发软件的生存能力。,5种主要的商业风险如下 ：, 建立的软件虽然很优秀但不是市场真正所想要的（市场风险）；
14、 建立的软件不再符合公司的整个软件产品战略（策略风险）； 建立了销售部门不清楚如何推销的软件； 由于重点转移或人员变动而失去上级管理部门的支持（管理风险）； 没有得到预算或人员的保证（预算风险； 特别要注意，有时对某些风险不能简单地归类，而且某些风险事先是无法预测的。,2风险项目检查表,识别风险的一种最好的方法就是利用一组提问来帮助项目计划人员了解在项目和技术方面有哪些风险。因此，Boehm建议使用一个“风险项目检查表”，列出所有可能的与每一个风险因素有关的提问,从如下几个方面识别已知的或可预测的风险：, 产品规模。与待开发或要修改的软件的产品规模（估算偏差、产品用户、需求变更、复用软件、数据
15、库）相关的风险。 商业影响。与管理和市场所加之的约束（公司收益、上级重视、符合需求、用户水平、产品文档、政府约束、成本损耗、交付期限）有关的风险。 客户特性。与客户的素质（技术素养、合作态度、需求理解）以及开发者与客户定期通信（技术评审、通信渠道）能力有关的风险 过程定义。与软件过程定义与组织程度以及开发组织遵循的程度相关的风险 开发环境。与用来建造产品的工具（项目管理、过程管理、分析与设计、编译器及代码生成器、测试与调试、配置管理、工具集成、工具培训、联机帮助与文档）的可用性和质量相关的风险。 建造技术。与待开发软件的复杂性及系统所包含技术的“新颖性”相关的风险。 人员数量及经验。与参与工作
16、的软件技术人员的总体技术水平（优秀程度、专业配套、数量足够、时间窗口）及项目经验（业务培训、工作基础）相关的风险,3全面评估项目风险,下面的问题是通过调查世界各地有经验的软件项目管理者而得到的风险数据导出的。这些问题根据它们对于项目成功的相对重要性顺序排列。 高层的软件和客户的管理者是否正式地同意支持该项目？ 终端用户是否热心地支持该项目和将要建立的系统产品？ 软件工程组和他们的客户对于需求是否有充分的理解？ 客户是否充分地参与了需求定义过程 终端用户的期望是否实际？ 项目的范围是否稳定？ 软件工程组是否拥有为完成项目所必须的各种技术人才？, 项目的需求是否稳定？ 项目组是否具有实现目标软件系
17、统的技术基础和工作经验？ 项目组中的人员数量对于执行项目的任务是否足够？11.所有客户是否都一致赞同该项目的重要性并支持将要建立的系统产品？ 只要对这些问题的回答有一个是否定的，就应当制定缓解、监控、驾驭的步骤以避免项目失败。项目处于风险的程度直接与对这些问题否定回答的数目成比例。,3全面评估项目风险,4风险构成和驱动因素,美国空军在一本关于如何识别和消除风险的手册中给出如何标识影响风险构成的风险驱动因素。风险构成有如下几种： 性能风险。产品是否能够满足需求且符合其使用目的的不确定的程度。 成本风险。项目预算是否能够维持的不确定的程度。 支持风险。软件产品是否易于排错、适应及增强的不确定的程度
18、。 进度风险。项目进度是否能够维持及产品是否能够按时交付的不确定的程度。 如表9.1所示，每个风险驱动因素对风险构成的影响可以划分为4类：可忽略的、边缘的、危急的和灾难的。,表9.1 影响的评估,注：1. 未检测出的软件错误或故障所产生的潜在后果。 2. 没有达到预期的成果所产生的潜在后果,9.3.2 风险估计,风险估计从两个方面估价每一种风险：一是估计一个风险发生的可能性；一是估价与风险相关的问题出现后将会产生的结果。通常，项目计划人员与管理人员、技术人员一起，进行四种风险估计活动：建立一个尺度来表明风险发生的可能性；描述风险的后果；估计风险对项目和产品的影响；指明风险估计的正确性以便消除误
19、解。,风险表的示例如表9.2所示。第1列列出风险（不论多么细微），可以利用风险项目检查表的条目来给出。每一个风险在第2列加以分类，在第3列给出风险发生概率，第4列是利用表9.1给出的对风险产生影响的评价。这要求对4种风险构成（性能、支持、成本、进度）的影响类别求平均值，得到一个整体的影响值。 风险出现概率可以使用从过去项目、直觉或其他信息收集来的度量数据进行统计分析估算出来。例如，由45个项目中收集的度量表明，有37个项目遇到的用户要求变更次数达到2次。作为预测，新项目将遇到的极端的要求变更次数的概率是 37450.82，因而，这是一个很大的项目。 一旦完成了风险表前4列的内容，就可以根据概率
20、和影响进行排序。高发生概率和高影响的风险移向表的前端，低概率低影响的风险向后移动，完成第一次风险优先排序。 项目管理人员研究已排序的表，定义一条截止线（Cutoff line），这条截止线（在表中某一位置的一条横线）表明，位于线上部分的风险将给予进一步关注而位于线下部分的风险需要再评估以完成第二次优先排序。,9.3.2 风险估计,表9.2 风险表,参看图9.1，风险影响和发生概率对驾驭参与有不同的影响。一个具有较高的影响但发生概率极低的风险应当不占用很多有效管理时间。然而，具有中等到高概率的高影响的风险和具有高概率的低影响的风险，就必须进行风险的分析。,图9.1 风险与管理参与,9.3.2 风
21、险估计,在进行风险评价时，可建立一系列三元组： ri, li, xi ，其中，ri是风险，li是风险出现的可能性（概率），而xi是风险产生的影响。在做风险评价时，应进一步审查在风险估计时所得到的估计的准确性，尝试对已发现的风险进行优先排队，并着手考虑控制和（或）消除可能出现风险的方法。 在做风险评价时常采用的一个非常有效的方法就是定义风险参照水准。对于大多数软件项目来说，性能、支持、成本和进度就是典型的风险参照水准。就是说，对于成本超支、进度延期、性能降低及支持困难，或它们的某种组合，都有一个水准值，超出它就会导致项目被迫终止。如果风险的某种组合所产生的问题导致一个或多个这样的参照水准被超出，
22、工作就要中止。在软件风险分析的上下文中，一个风险参照水准就有一个点，叫做参照点或崩溃点。在这个点上，要公平地给出可接受的判断，看是继续执行项目工作，还是终止它们（出的问题太大）。,9.3.3 风险评价,图9.2用图示表示这种情况。如果因为风险的某一组合造成问题，导致项目成本超支和进度延迟，一系列的参照点构成一条曲线，超出它时就会引起项目终止（黑色阴影区域）。在参照点上，要对作出是继续进行还是终止的判断公正地加权。,图9.2 风险参照水准曲线,9.3.3 风险评价,实际上，参照点能在图上被表示成一条平滑的曲线的情况很少。在多数情况中，它是一个区域，在此区域中存在许多不确定性的范围，在这些范围内想
23、做出基于参照值组合的管理判断往往是不可能的。 因此，在做风险评价时，我们按以下步骤执行。 1定义项目的各种风险参照水准。 2找出在各 ri, li, xi 和各参照水准之间的关系。 3预测一组参照点以定义一个项目终止区域，用一条曲线或一些不确定性区来界定。 4预测各种复合的风险组合将如何影响参照水准。,9.3.3 风险评价,9.3.4 风险驾驭和监控,为了执行风险驾驭与监控活动，必须考虑与每一风险相关的三元组（即风险描述、风险发生概率和风险影响），它们构成风险驾驭（风险消除）步骤的基础。例如，假如人员的频繁流动是一项风险ri，基于过去的历史和管理经验，频繁流动可能性的估算值li为0.70，而影
24、响xi的估计值是：项目开发时间增加15，总成本增加12。,为了缓解这一风险，项目管理必须建立一个策略来降低人员的流动造成的影响。可采取的风险驾驭步骤如下：,1与现有人员一起探讨人员流动的原因（例如，工作条件差，收入低，人才市场竞争等）。 2在项目开始前，把缓解这些原因的工作列入管理计划中。 3当项目启动时，做好人员流动会出现的准备。采取一些技术以确保人员一旦离开，项目仍能继续。 4建立良好的项目组织和通信渠道，以使大家都了解每一个有关开发活动的信息。 5制定文档标准并建立相应机制，以保证文档能够及时建立。 6对所有工作组织细致地评审，使大多数人能够按计划进度完成自己的工作。 7对每一个关键性的
25、技术人员，要培养后备人员。,9.3.4 风险驾驭和监控,这些风险驾驭步骤带来了额外的项目成本。例如，培养关键技术人员的后备需要花钱、花时间。因此，当通过某个风险驾驭步骤而得到的收益被实现它们的成本超出时，要对风险驾驭部分进行评价，进行传统的成本效益分析。 对于一个大型的软件项目，可能识别3040项风险。如果每一项风险有37个风险驾驭步骤，那么风险驾驭本身也可能成为一个项目。 正因为如此，我们把Pareto的80/20规则用到软件风险上来。经验表明，所有项目风险的80（即可能导致项目失败的80的潜在因素）能够通过20 的已识别风险来说明。在早期风险分析步骤中所做的工作可以帮助计划人员确定，哪些风
26、险属于这20之内。由于这个原因，某些被识别过、估计过及评价过的风险可以不写进风险驾驭计划中，因为它们不属于关键的20（具有最高项目优先级的风险）。 风险驾驭步骤要写进风险缓解、监控和驾驭计划RMMM（Risk Mitigation Monitoring and Management Plan）。RMMM记叙了风险分析的全部工作，并且做为整个项目计划的一部分为项目管理人员所使用,9.3.4 风险驾驭和监控,一旦制定出RMMM且项目已开始执行，风险缓解与监控就开始了。风险缓解是一种问题回避活动，风险监控是一种项目追踪活动，它有三个主要目标。 1判断一个预测的风险事实上是否发生了。 2确保针对某个风险而制定的风险消除步骤正在合理地使用。 3收集可用于将来的风险分析的信息。 多数情况下，项目中发生的问题总能追踪到许多风险。风险监控的另一项工作就是要把“责任”（什么风险导致问题发生）分配到项目中去。 风险分析需要占用许多有效的项目计划工作量。识别、估计、评价、管理和监控都需要时间，但这些工作量花得值得。孙子曾经说过：“知己知彼，百战不殆。”,9.3.4 风险驾驭和监控,
