软件工程-第十六章-软件项目管理与计划优质PPT.ppt

1、l宿主机（Host machine）软件开发时使用的计算机及外围设备；l目标机（Target machine）运行已开发成功软件的计算机及外围设备；l其他硬件设备专用软件开发时需要的特殊硬件资源；l宿主机连同必要的软件工具构成软件开发系统。l软件资源包括用于开发的运行平台、各种CASE工具可以帮助分析和设计软件，开发程序所有的编程语言等。l（3）可复用构件资源l为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件部件库。根据需要，对软件部件稍做加工，就可以构成一些大的软件包。这要求这些软件部件应加以编目，以利引用，并进行标准化和确认，以利于应用和集成。l16.2.3 分解

2、技术分解技术l当一个待解决的问题过于复杂时，可以把它进一步分解，直到分解后的子问题变得容易解决为止。然后，分别解决每一个子问题，并将这些子问题的解答综合起来，从而得到原问题的解答。l软件项目估算是一种解决问题的形式，在多数情况下，要解决的问题（对于软件项目来说，就是成本和工作量的估算）非常复杂，想一次性整体解决比较困难。因此，对问题进行分解，把其分解成一组较小的接近于最终解决的可控的子问题，再定义它们的特性。l分解技术可以分为问题分解和过程分解。16.3 软件开发成本估算软件开发成本估算 l软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价，不包括原材料和能源的消耗，主要是人的劳动的

3、消耗。l软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发全过程所花费的人工代价作为依据的。l16.3.1 软件开发成本估算方法 l对软件成本的估算，主要靠分解和类推的手段进行。基本估算方法分为三类：l（1）自顶向下的估算方法l这种方法的想法是从项目的整体出发，进行类推。即估算人员根据以前已完成项目所耗费的总成本（或总工作量），推算将要开发的软件的总成本（即总工作量），然后按比例将它分配到各开发任务中去，再检验它是否能满足要求。Boehm给出一个参考例子，参看表16-3。表表16-3 软件开发各阶段工作量的分配软件开发各阶段工作量的分配 l（2

4、）自底向上的估计法l这种方法的想法是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。l（3）差别估计法l这种方法综合了上述两种方法的优点，其想法是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。l16.3.2 软件开发成本估算的经验模型软件开发成本估算的经验模型l开发成本估算模型通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度。l（1）IBM模型 l利用最小二乘法拟合，得到如下估算公式：l E=5.2L0.

5、19 D=4.1L0.36=17.47E0.35l S=0.54E0.6 DOC=49L1.01l其中，L是源代码行数（以KLOC计），E是工作量（以PM计），D是项目持续时间（以月计），S是人员需要量（以人计），DOC是文档数量（以页计）。l（2）Putnam模型 l这是1978年Putnam提出的模型，是一种动态多变量模型。该模型的基础是假定在软件开发的整个生存期中工作量有特定的分布。它把项目的资源需求当做时间的函数。l根据对一些大型项目的统计分析，软件开发工作量分布可用图16-4所示的曲线表示。该曲线被称为Rayleigh-Norden曲线。图图16-4 大型项目的工作量分布情况大型项目

6、的工作量分布情况 l利用该曲线得到如下的经验公式：l L=CkK1/3td4/3l其中，td是开发持续时间（以年计），K是软件开发与维护在内的整个生存期所花费的工作量（以人年计），L是源代码行数（以LOC计），Ck是技术状态常数，它反映出“妨碍程序员进展的限制”，并因开发环境而异。l（3）COCOMO模型（Constructive Cost Model）lBarry Boehm提出的一种软件估算模型的层次体系。称为结构型成本估算模型。是一种比较精确、易于使用的综合成本估算方法。l该模型首先将分为三个层次：l基本的COCOMO模型：只是将工作量（成本）作为程序规模的函数进行计算。l中级的COCO

7、MO模型：除了工作量以外，还将对产品、硬件、人员及项目属性的主观评价作为“成本驱动因子”加入估算模型中。l高级的COCOMO模型：除了中级模型的因素外，还加入了成本驱动因子对软件开发的每一个过程的影响的评估。l对于项目属性来说，COCOMO规定了三种项目属性：l组织型（Organic）：较小、较简单的软件项目。项目组人员经验丰富，对软件的使用环境很熟悉，受硬件的约束较少，程序的规模不是很大（5万行）。l嵌入型（Embadded）：此种软件要求在紧密联系的硬件、软件和操作的限制条件下运行的软件。比如航天用控制系统属此种类型。l半独立型（Semidetached）：对此种软件的要求介于上述两种软件

8、之间，但软件规模和复杂性都属于中等以上，最大可达30万行。表表16-1基本基本COCOMO模型系数表模型系数表 软件项目Abcd组织型2.41.052.50.38半独立型3.01.122.50.35嵌入型3.61.202.50.3216.4 风险分析风险分析 l风险分析实际上是4个不同的活动：风险识别，风险估计，风险评价和风险驾驭。l16.4.1 风险识别风险识别l可用不同的方法对风险进行分类。从宏观上来看，可将风险分为项目风险、技术风险和商业风险。l项目风险包括潜在的预算、进度、个人（包括人员和组织）、资源用户和需求方面的问题，以及它们对软件项目的影响。l技术风险包括潜在的设计、实现、接口、

9、检验和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。l商业风险主要有以下几种：l（1）建立的软件虽然很优秀但不是真正所想要的（市场风险）；l（2）建立的软件不适用整个软件产品战略；l（3）销售部门不清楚如何推销这种软件；l（4）失去上级管理部门的支持；l（5）失去预算或人员的承诺（预算风险）；l（6）最终用户的水平。l16.4.2 风险估算风险估算l风险估算，又叫风险预测。使用两种方法来估计每一种风险风险发生的可能性和概率。l通常，项目计划人员与管理人员、技术人员一起，进行4种风险估算活动：l（1）建立一个尺度或标准来表示一个风险的可能性；

10、l（2）描述风险的结果；l（3）估计风险对项目和产品的影响；l（4）确定风险估计的正确性。l参看图16-5，风险影响和出现概率对联驾驭参与有不同的影响。一个具有较高影响权值但出现概率极低的风险因素应当不占用很多有效管理时间。然而，具有中等到高概率的高影响的风险和具有高概率的低影响的风险，就必须进行风险的分析。图图16-5 风险与驾驭参与风险与驾驭参与 l16.4.3 风险评价风险评价l在风险分析过程中进行风险评价的时候，应当建立一个三元组：l ri，li，xil其中，ri是风险，li是风险出现的可能性（概率），而xi是风险的影响。l图16-6用图示来表示这种情况。如果因为风险的一个组合引出造成

11、项目成本和进度超出的问题，将有一个水准（在图中用曲线表示），当超出时，将导致项目终止（图中封闭区域）。图图16-6 风险参照水准风险参照水准 l在做风险评价时，按以下步骤执行：l（1）为项目定义风险参照水准；l（2）尝试找出在每个ri，li，xi和每个参照水准之间的关系；l（3）预测参照点组以定义一个终止区域，用一条曲线或一些易变动区域来界定；l（4）努力预测复合的风险组合将如何形成一个参照水准。l16.4.4 风险驾驭和监控风险驾驭和监控l所有的风险分析活动都只有一个目的建立处理风险的策略。风险驾驭是指利用某些技术，如原型化、软件自动化、软件心理学、可靠性工程学以及某些项目管理方法等设法避开

12、或转移风险。l例如，假如人员的频繁流动是一项风险ri，基于过去的历史和管理经验，频繁流动可能性的估算值li为0.70（70%相当高），而影响xi的估计值是：项目开发时间增加15%，总成本增加12%，给出了这些数据之后，建议可使用以下风险驾驭步骤：l（1）与现在在职的人员协商，确定人员流动的原因（如，工作条件差，收入低，人才市场竞争等）；l（2）在项目开始前，把缓解这些原因（避开风险）的工作列入已拟定的驾驭计划中。l（3）当项目启动时，做好人员流动会出现的准备。采取一些办法以确保人员一旦离开时项目仍能继续（削弱风险）；l（4）建立项目组，以使大家都了解有关开发活动的信息；l（5）制定文档标准，并

13、建立一种机制以保证文档能够及时产生；l（6）对所有工作组织细致的评审（以使更多的人能够按计划进度完成自己的工作）；l（7）对每一个关键性的技术人员，要培养后备人员。l图167表示风险驾驭步骤要写进风险驾驭与监控计划RMMP（Risk Management and Monitoring Plan）。RMMP记叙了风险分析的全部工作。RMMP的主要内容在表16-12中列出。图图16-7 风险驾驭与监控风险驾驭与监控 表表16-12 风险驾驭与监控计划概要风险驾驭与监控计划概要 l一旦制定出RMMP，软件项目也开始时，风险监控就开始了。风险监控的三个主要目标是：l（1）判断一个预测的风险事实上是否发

14、生了；l（2）确保针对某个风险而制定的风险消除步骤正在合理地实施；l（3）收集可用于将来的风险分析的信息。16.5 进度安排进度安排 l软件开发项目的进度安排有两种考虑方式：l（1）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成；l（2）系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。l16.5.1 软件开发小组人数与软件生产率 l一个估计有33000LOC，需要花费12个人年的软件可以用8个人工作1.3年完成。如果把完成时间延长到1.75年，根据Putnam软件方程，可得：l K=L3/（Ck3td4）3.8人年 l这表明，如果把完成时间延长6个月，就可以把人员数从8个减少到4个。这种结果不一定可靠，但可以帮助我们在制定进度时作出定性的分析。经验表明，