软件工程及应用第9章

《软件工程及应用第9章》由会员分享，可在线阅读，更多相关《软件工程及应用第9章（36页珍藏版）》请在金锄头文库上搜索。

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全面评估项目风险,下面的问题是通过调查世界各地有经验的软件项目管理者而得到的风险数据导出的。这些问题根据它们对于项目成功的相对重要性顺序排列。 高层的软件和客户的管理者是否正式地同意支持该项目？ 终端用户是否热心地支持该项目和将要建立的系统产品？ 软件工程组和他们的客户对于需求是否有充分的理解？ 客户是否充分地参与了需求定义过程 终端用户的期望是否实际？ 项目的范围是否稳定？ 软件工程组是否拥有为完成项目所必须的各种技术人才？, 项目的需求是否稳定？ 项目组是否具有实现目标软件系统的技术基础和工作经验？ 项目组中的人员数量对于执行项目的任务是否足够？11.所有客户是否都一致赞同该项目的重要性并支持将要建立的系统产品？ 只要对这些问题的回答有一个是否定的，就应当制定缓解、监控、驾驭的步骤以避免项目失败。项目处于风险的程度直接与对这些问题否定回答的数目成比例。,