软件工程第八章复习资料

第九章软件管理

一、复习要求

1.了解软件过程的概念、软件过程框架和软件过程模型

2.了解软件工程管理的过程

3.了解软件度量的种类，面向规模和面向功能的度量以及质量度量的种类

4.掌握LOC估算和FP估算的方法，分解技术和工作量估算方法

5.了解软件本钱估算的概念，掌握COCOMO本钱估算方法

6.了解软件本钱一效益估计方法

7.了解风险分析的步骤，风险的种类、风险工程和风险构成

8.了解软件进度安排方法及图形工具

9.了解软件工程划分的方式，工程组织的模式，人员配备的原则和条件

二、内容提要

1.软件过程1软件过程的概念软件工程是一种层次化的技术，如下图软件工程的过程层是将结合在一起的凝聚力量，使得计算机软件能够及时、合理地被开发出来软件过程定义了一组关键过程域KPAs,它们构成软件工程管理的基础，并规定了技术方法的采用、工程产品模型、文档、数据、报告、表格等的产生、里程碑的建立、质量的管理以及适当的变更控制软件过程是软件生存期中的一系列相关软件工程活动的集合每一个软件过程又是由一组工作任务、工程里程碑、软件工程产品和交付物以及质量保证SQA点等组成一个软件过程可以用图的形式来表示首先建立一个公共过程框架，其中定义了少量可适用于所有软件工程的框架活动，而不考虑它们的规模和复杂性再给出各个框架活动的任务集合，使得框架活动能够适合于工程的特点和工程组的需求最后是保护伞活动，如软件质量保证、软件配置管理以及测量等，它们独立于任何一个框架活动并将贯穿于整个过程2软件过程模型软件工程过程模型的选择基于工程和应用的特点、采用的方法和工具、耍求的控制和需交付的产品使用了分级几何表示，用以讨论软件工程过程的本质所有的软件开发都可以看成是一个问题循环解决过程，如下图其中包括4个截然不同的阶段状态捕获、问题定义、技术开发和方案综合状态捕获表示了事物的当前状态；问题定义标识了需要解决的特定问题；技术开发利用某些技术来解决问题；方案综合导出最终的结果如文档、程序、数据、新的事务功能、新的产品以上的问题循环解决过程可以用于软件工程的不同开发级别上它可用于考虑整个应用系统的宏观级，也可用于建造程序构件的中间级，甚至还可用于源代码行级因此，可以用分级几何表示来给出过程的理想化的视图首先定义一个分级几何表示的模式，然后相继地在更小的规模上递归地应用分级几何表示模式中嵌套模式在图

9.4中，问题循环解决过程的每一个阶段又包含一个同样的问题循环解决过程，该循环中每一个步骤中还可以再包含另一个问题循环解决过程这样一直继续下去，直到某个合理的边界为止对于软件来说，就是源代码行表

9.5估算表m b悲观值E期望值每行本钱生产率本钱（元）工作量（PM）（元/行）a可能值（行/PM）最正确值用户接口控制

180024002650234014315327607.4二维几何造型

41005200740053802022010760024.4三维几何造型

46006900860068002022013600030.9数据库管理

2950340036003350182406030013.9终端图形显示

40504900620049502220010890024.7外部设备控制

2000210024502140281405992015.2设计分析

66008500980084001830015120028.0总计33360656680表中给出了LOC的估算范围计算出的各功能的期望值放入表中的第4歹限然后对该列垂直求和，得到该CAD系统的LOC估算值33360o从历史数据求出生产率度量和每行本钱，即行/PM和元/行在表中的本钱和工作量这两列的值分别用LOC的期望值E与元/行相乘，及用LOC的期望值E与行/PM相除得到因此可得，该工程总本钱的估算值为657,000元，总工作量的估算值为145人月（PM）

②工作量估算每一工程任务的解决都需要花费若干人日、人月或人年每一个工作量单位都对应于一定的货币本钱，从而可以由此做出本钱估算类似于L0C或FP技术，工作量估算开始于从软件工程范围抽出软件功能接着给出为实现每一软件功能所必须执行的一系列软件工程任务，包括需求分析、设计、编码和测试表

9.6中的表格局部表示各个软件功能和相关的软件工程任务方案人员针对每一软件功能，估算完成各个软件工程任务所需要的工作量（如人月），并记在表

9.6表格的中心局部同时，把劳动费用率（即单位工作量本钱）加到每个软件工程任务上最后，计算每一个功能及软件工程任务的工作量和本钱如果工作量估算不依赖L0C或FP估算，那么，就可得到两组能进行比较和调和的本钱与工作量估算如果这两组估算值合理地一致，则估算值是可靠的如果估算的结果不一致，就有必要做进一步的检查与分析以上面所介绍的CAD软件为例，列出它的一个完全的工作量估算表（如表

9.7所示）表中对每一个软件功能提供了用人月（PM）表示的每一项软件工程任务的工作量估算值横向和纵向的总计给出所需要的工作量表

9.7工作量估算表任务功能用户接口控制二维几何造型三维几何造型数据库管理图形显示功能外设控制功能设计分析功能

14.55200总计费用率48004250450075400（元）本钱（元）292800112625227250708075除特别指出外，工作量都按人月（PM）估算与每个软件工程任务相关的劳动费用率记入表中费用率（元）这一行，这些数据反映了“负担〃的劳动本钱,即包括公司开销在内的劳动本钱如果工作量估算法与LOC估算法所得结果之间的一致性很差，就必须重新确定估算所使用的信息如果要追寻产生差距的原因，不外乎以下两个原因之一方案人员没有充分了解或误解了工程的范围；用于LOC估算的生产率数据不适合于本工程，过时了（即使用这些数据不能正确反映软件开发机构的情况），或者是误用了方案人员必须确定产生差距的原因再来协调估算结果

5、软件开发本钱估算软件开发本钱主要是指软件开发过程中所花费的工作量及相应的代价它不同于其它物理产品的本钱，它不包括原材料和能源的消耗，主要是人的劳动的消耗人的劳动消耗所需代价就是软件产品的开发本钱另一方面，软件产品开发本钱的计算方法不同于其它物理产品本钱的计算软件产品不存在重复制造过程，它的开发本钱是以一次性开发过程所花费的代价来计算的因此软件开发本钱的估算，应是从软件方案、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发全过程所花费的代价作为依据的

（1）软件开发本钱估算方法对于一个大型的软件工程，要进行一系列的估算处理主要靠分解和类推的手段进行根本估算方法分为三类

①自顶向下的估算方法这种方法的主要思想是从工程的整体出发，进行类推即估算人员根据以前已完成工程所消耗的总本钱（或总工作量），来推算将要开发的软件的总本钱（或总工作量），然后按比例将它分配到各开发任务单元中去这种方法的优点是估算工作量小，速度快缺点是对工程中的特殊困难估计缺乏，估算出来的本钱盲目性大，有时会遗漏被开发软件的某些局部

②自底向上的估计法这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量这是一种常见的估算方法它的优点是估算各个局部的准确性高缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量（配置管理、质量管理、工程管理）所以往往估算值偏低，必须用其它方法进行检验和校正

③差异估计法这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件工程与过去已完成的软件工程进行类比，从其开发的各个子任务中区分出类似的局部和不同的局部类似的局部按实际量进行计算，不同的局部则采用相应的方法进行估算这种的方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似〃的界限

（2）专家判定技术专家判定技术就是由多位专家进行本钱估算由于单独一位专家可能会有种种偏见，譬如有乐观的、悲观的、要求在竞争中取胜的、让大家都快乐的种种愿望及政治因素等因此，最好由多位专家进行估算，取得多个估算值Rand公司提出Deiphi技术，作为统一专家意见的方法用Deiphi技术可得到极为准确的估算值Deiphi技术的步骤是

①组织者发给每位专家一份软件系统的规格说明书（略去名称和单位）和一张记录估算值的表格，请他们进行估算

②专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即a——该软件可能的最小规模（最少源代码行数）；mi——该软件最可能的规模（最可能的源代码行数）；——该软件可能的最大规模（最多源代码行数）无记名地填写表格，并说明做此估算的理由在填表的过程中，专家互相不进行讨论但可以向组织者提问

③组织者对专家们填在表格中的答复进行整理，做以下事情a）计算各位专家（序号为i，i=l,2,…,n,共n位专家）的估算期望值日,并综合各位专家估算值的期望中值E Hi+411\+灯b）对专家的估算结果进行分类摘要

④在综合专家估算结果的基础上，组织专家再次无记名地填写表格然后比较两次估算的结果若差异很大，则要通过查询找出差异的原因

⑤上述过程可重复屡次最终可获得一个得到多数专家共识的软件规模（源代码行数）在此过程中不得进行小组讨论最后，通过与历史资料进行类比，根据过去完成软件工程的规模和本钱等信息，推算出该软件每行源代码所需要的本钱然后再乘以该软件源代码行数的估算值，就可得到该软件的本钱估算值此方法的缺点是人们无法利用其他参加者的估算值来调整自己的估算值宽带Deiphi技术克服了这个缺点在专家正式将估算值填入表格之前，由组织者召集小组会议，专家们与组织者一起对估算问题进行讨论，然后专家们再无记名填表组织者对各位专家在表中填写的估算值进行综合和分类后，再召集会议，请专家们对其估算值有很大变动之处进行讨论，请专家们重新无记名填表这样适当重复几次，得到比较准确的估计值由于增加了协商的时机，集思广益，使得估算值更趋于合理

（3）软件开发本钱估算的早期经验模型软件开发本钱估算是依据开发本钱估算模型进行估算的开发本钱估算模型通常采用经验公式来预测软件工程方案所需要的本钱、工作量和进度数据还没有一种估算模型能够适用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用

①IBM模型1977年,IBM的Walston和Felix提出了如下的估算公式:E=XL,L是源代码行数（以KLOC计），E是工作量（以PM计）D=XL=XE,D是工程持续时间（以月计）S=XE,S是人员需要量（以人计）DOC=49XL DOC是文档数量（以页计）O在此模型中，一般指一条机器指令为一行源代码一个软件的源代码行数不包括程序注释、作业命令、调试程序在内对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑IBM模型是一个静态单变量模型，但不是一个通用的公式在应用中有时要根据具体实际情况，对公式中的参数进行修改这种修改必须拥有足够的历史数据，在明确局部的环境之后才能做出

②Putnam模型这是1978年Putnam提出的模型，是一种动态多变量模型它是假定在软件开发的整个生存期中工作量有特定的分布这种模型是依据在一些大型工程（总工作量到达或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件工程中Putnam模型可以导出一个“软件方程〃，把已交付的源代码（源语句）行数与工作量和开发时间联系起来其中，加是开发持续时间（以年计），《是软件开发与维护在内的整个生存期所花费的工作量（以人年计），/是源代码行数（以LOC计），或是技术状态常数，它反映出“阻碍程序员进展的限制〃，并因开发环境而异其典型值的选取如表

9.8所示L=CkIC-tcP表

9.8技术状态常数的取值服的典型值开发环境开发环境举例2000差没有系统的开发方法，缺乏文档和复审，批处理方式8000好有适宜的系统开发方法，有充分的文档和复审，交互执行方式11000优有自动开发工具和技术

（4）COCOMO模型（Constructive COstMOdel）这是由TRW公司开发Boehm提出的结构型本钱估算模型是一种精确、易于使用的本钱估算方法在该模型中使用的根本量有以下几个DSI（源指令条数）定义为代码或卡片形式的源程序行数若一行有两个语句，则算做一条指令它包括作业控制语句和格式语句，但不包括注释语句KDSI=1000DSIo MM（度量单位为人月）表示开发工作量TDEV（度量单位为月）表示开发进度它由工作量决定

①软件开发工程的分类在COCOMO模型中，考虑开发环境,软件开发工程的总体类型可分为三种组织型（Organic）、嵌入型（Embadded）和介于上述两种软件之间的半独立型（Semidetached）o

②COCOMO模型的分类COCOMO模型按其详细程度分成三级即根本COCOMO模型、中间COCOMO模型、详细COCOMO模型根本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的（经验）函数来计算软件开发工作量中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量（此时称为名义工作量）的基础上，再用涉及产品、硬件、人员、工程等方面属性的影响因素来调整工作量的估算详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响

③根本COCOMO模型根本COCOMO模型的工作量和进度公式如表所示表

9.9根本COCOMO模型的工作量和进度公式总体类型工作量进，度组织型MM=

2.4KDSI TDEV=

2.5MM半独立型MM=

3.0KDSI TDEV=

2.5MM嵌入型MM=

3.6KDSI TDEV=

2.5MM利用上面公式，可求得软件工程，或分阶段求得各软件任务的开发工作量和开发进度

④中间COCOMO模型进一步考虑以下15种影响软件工作量的因素，通过定下乘法因子，修正COCOMO工作量公式和进度公式,可以更合理地估算软件（各阶段）的工作量和进度中间COCOMO模型的名义工作量与进度公式如表所示表

9.10中间COCOMO模型的名义工作量与进度公式总体类型工作量进，度组织型MM=

3.2KDSI TDEV=

2.5MM半独立型MM=

3.0KDSI TDEV=

2.5MM嵌入型MM=

2.8KDSI TDEV=

2.5MM对15种影响软件工作量的因素fi按等级打分，如表所列此时，工作量计算公式改成:15MM=rx fi x（KDSI）c口i=i表

9.1115种影响软件工作量的因素的等级分_______________软件可靠性产品因素数据库规模工作量因素「非常低J非常高超高产品复杂性执行时间限制计算机存储限制因素虚拟机易变性环境周转时间分析员能力应用论域实际经验人的因素程序员能力虚拟机使用经验程序语言使用经验现代程序设计技术软件工具的使用工程因素开发进度限制这里所谓的虚拟机是指为完成某一个软件任务所使用的硬、软件的结合

⑤详细COCOMO模型详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO模型相同但分层、分阶段给出工作量因素分级表（类似于上表）针对每一个影响因素，按模块层、子系统层、系统层，有三张不同的工作量因素分级表，供不同层次的估算使用每一张表中工作量因素又按开发各个不同阶段给出例如，关于软件可靠性（RELY）要求的工作量因素分级表（子系统层），如表

9.12所示使用这些表格，可以比中间COCOMO模型更方便、更准确地估算软件开发工作量表

9.12软件可靠性工作量因素分级表（子系统层）阶段RELY级别非常低低正常高非常高

6、本钱一效益分析本钱一效益分析的目的，是从经济角度评价开发一个新的软件工程是否可行本钱一效益分析首先是估算新软件系统的开发本钱，然后与可能取得的效益（有形的和无形的）进行比较权衡有形的效益可以用货币的时间价值、投资回收期、纯收入、投资回收率等指标进行度量无形的效益主要是从性质上、心理上进行衡量，很难直接进行量上的比较无形的效益在某些情形下会转化成有形的效益例如，一个高质量的设计先进的软件可以使用户更满意，从而影响到其他潜在的用户也会喜欢它，一旦需要时就会选择购置它，这样使得无形的效益转化成有形的效益系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用运行费用包括操作员人数、工作时间、消耗的物资等

（1）几种度量效益的方法

①货币的时间价值本钱估算的目的是要求对工程投资但投资在前，取得效益在后因此要考虑货币的时间价值通常用利率表示货币的时间价值设年利率为i,现已存入P元，则n年后可得钱数为F=（1+i）:这就是P元钱在n年后的价值反之，若n年后能收入F元，那么这些钱现在的价值是例如，在工程设计中用CAD系统来取代大局部人工设计工作，每年可节省万元若软件生存期为5年，则5年可节省48万元开发这个CAD系统共投资了20万元我们不能简单地把20万元与48万元相比较因为前者是现在投资的钱,而后者是5年以后节省的钱需要把5年内每年预计节省的钱折合成现在的价值才能进行比较设年利率是5%,利用上面计算货币现在价值的公式，可以算出引入CAD系统后，每年预计节省的钱的现在价值，参看表

9.13表

9.13货币的时间价值年份将来值（万）Hi n现在值（万）累计的现在值（万）12345

②投资回收期投资回收期是衡量一个开发工程价值的经济指标所谓投资回收期就是使累计的经济效益等于最初的投资所需的时间投资回收期越短，就能越快获得利润因此这项工程就越值得投资例如，引入CAD系统两年后可以节省万元，比最初的投资还少万元，但第三年可以节省万元，则/因此，投资回收期是年

③纯收入工程的纯收入是衡量工程价值的另一项经济指标所谓纯收入就是在整个生存期之内系统的累计经济效益（折合成现在值）与投资之差例如，引入CAD系统之后，5年内工程的纯收入预计是一20=（万元）这相当于比较投资一个待开发的软件工程后预期可取得的效益和把钱存在银行里（或贷款给其它企业）所取得的收益，到底孰优孰劣如果纯收入为零，则工程的预期效益与在银行存款一样但开发一个软件工程有风险，从经济观点看,这项工程可能是不值得投资的如果纯收入小于零，那么显然这项工程不值得投资只有当纯收入大于零，才能考虑投资

④投资回收率把钱存在银行里，可以用年利率来衡量利息的多少类似地，用投资回收率来衡量投资效益的大小现在的投资额P,并且已经估算出将来每年可以获得的经济效益Fk,以及软件的使用寿命n,k=l,2,...,n则投资回收率j,可用如下的方程来计算o这相当于把数额等于投资额的资金存入银行，每年年底从银行取回的钱等于系统每年预期可以获得的效益在时间等于系统寿命时，正好把在银行中的钱全部取光此时的年利率是多少呢？就等于投资回收率

（2）本钱一效益的分析系统的效益分析随系统的特性而异大多数数据处理系统的根本目标是开发具有较大信息容量、更高的质量、更及时、组织得更好的系统因此，效益集中在信息存取和它对用户环境的影响上面与工程一科学计算软件及基于微处理器的产品相关的效益在本质上可能不大相同新系统的效益与系统的工作方式有关仍以前面所说的代替人工设计过程的计算机辅助设计（CAD）系统为例分析员对现行系统（人工设计）和待开发系统（CAD）定义可度量的特性，选定产生最终详细图纸的时间t-draw作为一个可度量的特性且分析员发现，CAD系统产生的缩减比为1/4为进一步量化这种效益，应确定以下数据t-draw平均绘图时间=4小时；c每绘图一小时的本钱=

20.00元；n每年绘图的数量=8000；PCAD系统中已完成绘图的百分比=60%；利用以上数据，每年节省费用的估算值，即所得到的效益为节省E其它由CAD系统而得到的有形效益将以类似的方式进行处理而无形的效益（如较好的设计质量、较高的雇员素质）可以被赋予货币价值软件系统开发的本钱如表

9.14所列表

9.14信息系统可能的费用咨询费实际设备购置或租用设备费筹办费用设备安装费设备场所改建费（空调、平安设施等）资本与筹办相关的管理和人员的费用操作系统软件的费用通信设备安装费用（电话线、数据线等）开办费用开办人员的费用人员寻找与聘用活动所需的费用破坏其它机构所需的费用指导开办活动所需的管理费用应用软件购置费为适应局域系统修改软件的费用公司内应用系统开发所需的人员工数据收集和建立数据收集过程所需的费用与工程有资、经常性开销等关的费用准备文档所需的费用培训用户人员使用应用系统的费用开发管理费系统维护费用（硬件、软件和设备）租借费用（电费、电话费等）运行费用硬件折旧费信息系统管理、操作及方案活动中涉及人员的费用分析员可以估算每一项的本钱，然后用开发费用和运行费用来确定投资的归还、损益两平点和投资回收期图

9.9说明了前面所介绍的CAD系统实例的特性假设每年可节约总费用的估计值为96000元，总开发（或购置）费用为204000元，年度费用估计为32000元则从图

9.0可知，投资回收期大约需要年实际上，投资的归还可以用更详细的分析方法来确定，即货币的时间价值、税收的影响及其它潜在的对投资的使用再把无形的效益考虑在内，上级管理部门就可以决策，在经济上是否值得开发这个系统12345（年）|一一投资回收期一一|图

9.9本钱一效益分析

7、风险分析风险分析实际上是4个不同的活动风险识别，风险估计，风险评价和风险驾驭

（1）风险识别风险识别就是要系统地确定对工程方案（估算、进度、资源分配）的威胁，通过识别的或可预测的风险，就可能设法避开风险或驾驭风险

①风险类型用各种不同的方法对风险进行分类是可能的从宏观上来看，可将风险分为工程风险、技术风险和商业风险工程风险威胁到工程方案，一旦工程风险成为现实，可能会拖延工程进度，增加工程的本钱工程风险是指潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，以及它们对软件工程的影响工程复杂性、规模和结构的不确定性也构成工程的（估算）风险因素技术风险威胁到待开发软件的质量和预定的交付时间如果技术风险成为现实，开发工作可能会变得很困难或根本不可能技术风险是指潜在的设计、实现、接口、检验和维护方面的问题止匕外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素技术风险之所以出现是由于问题的解决比我们预想的要复杂商业风险威胁到待开发软件的生存能力5种主要的商业风险是建立的软件虽然很优秀但不是市场真正所想要的（市场风险）；建立的软件不再符合公司的整个软件产品战略（策略风险）；建立了销售部门不清楚如何推销的软件；由于重点转移或人员变动而失去上级管理部门的支持（管理风险）；没有得到预算或人员的保证（预算风险）特别要注意，有时对某些风险不能简单地归类，而且某些风险事先是无法预测的

②风险工程检查表识别风险的一种最好的方法就是利用一组提问来帮助工程方案人员了解在工程和技术方面有哪些风险因此，Boehm建议使用一个“风险工程检查表〃，列出所有可能的与每一个风险因素有关的提问从如下几个方面识别的或可预测的风险产品规模一一与待开发或要修改的软件的产品规模（估算偏差、产品用户、需求变更、复用软件、数据库）相关的风险商业影响一一与管理和市场所加之的约束（公司收益、上级重视、符合需求、用户水平、产品文档、政府约束、本钱损耗、交付期限）有关的风险客户特性一一与客户的素质（技术素养、合作态度、需求理解）以及开发者与客户定期通信（技术评审、通信渠道）能力有关的风险过程定义一一与软件过程定义与组织程度以及开发组织遵循的程度相关的风险开发环境一一与用来建造产品的工具（工程管理、过程管理、分析与设计、编译器及代码生成器、测试与调试、配置管理、工具集成、工具培训、联机帮助与文档）的可用性和质量相关的风险建造技术一一与待开发软件的复杂性及系统所包含技术的“新颖性〃相关的风险人员数量及经验一一与参与工作的软件技术人员的总体技术水平（优秀程度、专业配套、数量足够、时间窗口）及工程经验（业务培训、工作基础）相关的风险

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

④风险构成和驱动因素美国空军在一本关于如何识别和消除风险的手册中给出如何标识影响风险构成的风险驱动因素风险构成有如下几种性能风险一一产品是否能够满足需求且符合其使用目的的不确定的程度本钱风险一一工程预算是否能够维持的不确定的程度支持风险一一软件产品是否易于排错、适应及增强的不确定的程度进度风险一一工程进度是否能够维持及产品是否能够按时交付的不确定的程度如表所示，每个风险驱动因素对风险构成的影响可以划分为4类可忽略的、边缘的、危急的、灾难的表

9.15影响的评估构成类别1不能满足需求将可能导致任务失败失误而导致本钱增加和进度延迟，预计超支在$500K以上灾难的2严重退化以至达不到无法作出响应或无严重资金短缺，很无法到达初始运行技术性能要求法支持的软件可能超出预算能力1不能满足需求将可能使系统性能下降到连失误而导致运行延迟和/或本钱增加,预任务是否能成功都成了问题计超支在$100K到$500K危急的2技术性能有些降低在软件修改期间有资金来源缺乏，可能推迟到达初始较小的延迟可能超支运行能力不能满足需求将会导致次要任务的退化本钱、影响和/或可恢复的进度滑坡，预1计超支在$1K到$100K边缘的2技术性能有很小的降实际可到达的进低能够响应软件支持有充足的资金来源度1不能满足需求可能会造成使用不方便或不失误对本钱和/或进度的影响很小易操作的影响预计超支捕获超过$1K可忽略的2技术性能不会降低容易实施软件支可能低于预算较早到达初始运行持能力注

1.未检测出的软件错误或故障所产生的潜在后果

2.没有到达预期的成果所产生的潜在后果

（2）风险估计风险估计从两个方面估价每一种风险一是估计一个风险发生的可能性一是估价与风险相关的问题出现后将会产生的结果通常，工程方案人员与管理人员、技术人员一起，进行4种风险估计活动建立一个尺度来说明风险发生的可能性；描述风险的后果；估计风险对工程和产品的影响；指明风险估计的正确性以便消除误解

①建立风险表风险表的例如如表

9.16所示第1列列出风险（不管多么细微），可以利用风险工程检查表的条目来给出每一个风险在第2列加以分类，在第3列给出风险发生概率，第4列是利用表给出的对风险产生影响的评价这要求对4种风险构成（性能、支持、本钱、进度）的影响类别求平均值，得到一个整体的影响值表风险表风险类别概率影响RMMM规模估算可能非常低PS产品规模风险60%2用户数量大大超过方案PS々30%3复用程度低于方案PS々70%2风险最终用户抵抗该系统BU商业风险40%3缓解交付期限将被紧缩BU々50%2监控资金将会流失CU客户特性风险40%1驾驭用户将改变需求PS产品规模风险80%2方案技术达不到预期的效果TE建造技术风险30%1缺少对工具的培训DE开发环境风险80%3参与人员缺乏经验ST人员规模与经验风险30%2参与人员流动比较频繁ST々60%2风险出现概率可以使用从过去工程、直觉或其它信息收集来的度量数据进行统计分析估算出来例如，由45个工程中收集的度量说明，有37个工程遇到的用户要求变更次数到达2次作为预测，新工程将遇到的极端的要求变更次数的概率是37/45=,因而，这是一个极可能的风险一旦完成了风险表前四列的内容，就可以根据概率和影响进行排序高发生概率和高影响的风险移向表的前端，低概率低影响的风险向后移动，完成第一次风险优先排队工程管理人员研究已排序的表，定义一条截止线（Cutoff line）,这条截止线（在表中某一位置的一条横线）说明，位于线上局部的风险将给予进一步关注而位于线下局部的风险需要再评估以完成第二次优先排队参看图

9.10,风险影响和发生概率对驾驭参与有不同的影响一个具有较高的影响但发生概率极低的风险应当不占用很多有效管理时间然而，具有中等到高概率的高影响的风险和具有高概率的低影响的风险，就必须进行风险的分析

②风险评价在进行风险评价时，可建立一系列三元组［/，，，％］,其中，K是风险，入是风险出现的可能性（概率），而小是风险产生的影响在做风险评价时，应进一步审查在风险估计时所得到的估计的准确性，尝试对已发现的风险进行优先排队，并着手考虑控制和/或消除可能出现风险的方法在做风险评价时常采用的一个非常有效的方法就是定义风险参照水准对于大多数软件工程来说，性能、支持、本钱、进度就是典型的风险参照水准就是说，对于本钱超支、进度延期、性能降低、支持困难，或它们的某种组合，都有一个水准值，超出它就会导致工程被迫终止如果风险的某种组合所产生的问题导致一个或多个这样的参照水准被超出，工作就要中止在软件风险分析的上下文中，一个风险参照水准就有一个点，叫做参照点或崩溃点在这个点上，要公平地给出可接受的判断，看是继续执行工程工作，还是终止它们（出的问题太大）图

9.11用图示表示这种情况如果因为风险的某一组合造成问题，导致工程本钱超支和进度延迟，一系列的参照点构成一条曲线，超出它时就会引起工程终止（黑色阴影区域）在参照点上，要对做出是继续进行还是终止的判断公正地加权实际上，参照点能在图上被表示成一条平滑的曲线的情况很少在多数情况中，它是一个区域，在此区域中存在许多不确定性的范围，在这些范围内想做出基于参照值组合的管理判断往往是不可能的因此，在做风险评价时，我们按以下步骤执行定义工程的各种风险参照水准；找出在各［n,L,必］和各参照水准之间的关系；预测一组参照点以定义一个工程终止区域，用一条曲线或一些不确定性区来界定；预测各种复合的风险组合将如何影响参照水准

（3）风险驾驭和监控为了执行风险驾驭与监控活动，必须考虑与每一风险相关的三元组（风险描述、风险发生概率、风险影响），它们构成风险驾驭（风险消除）步骤的基础例如，假设人员的频繁流动是一项风险乙，基于过去的历史和管理经验，频繁流动可能性的估算值人为，而影响必的估计值是工程开发时间增加15%,总本钱增加12%为了缓解这一风险，工程管理必须建立一个策略来降低人员的流动造成的影响可采取的风险驾驭步骤如下与现有人员一起探讨人员流动的原因（如，工作条件差，收入低，人才市场竞争等）；在工程开始前，把缓解这些原因的工作列入管理方案中当工程启动时，做好人员流动会出现的准备采取一些技术以确保人员一旦离开后工程仍能继续；建立良好的工程组织和通信渠道，以使大家都了解每一个有关开发活动的信息；图问题循环解决过程中阶段嵌套阶段实际上，想要如图

9.4那样清楚地划分这些活动是很困难的，因为在阶段内部常常会出现一些交叉的任务,它们还可能会跨越阶段不过，这种简化的视图表达了一个重要的思想不管软件工程选择了什么样的过程模型,但所有阶段，包括状态捕获、问题定义、技术开发、方案综合，在某个细节级别上都同时存在由于给出了如图

9.4所示的递归的性质，上述的4阶段论不但可用于整个应用的分析，而且同样地可用于某一代码段的生成

（3）过程建造技术为使得软件过程模型适合于软件工程组的使用，需要开发一些过程技术工具，以帮助软件开发组织分析它们当前的过程，组织工作任务，控制和监控进度，管理技术质量使用过程技术工具，可以建造一个自动模型，模型包含前面提到的公共过程框架、任务集合及保护伞活动该模型一般表示成一个网络，对其加以分析，就能够确定典型的工作流程，考察可能导致减少开发时间、降低开发本钱的可选的过程结构一旦创立了一个可接受的过程，就可以使用其它过程技术工具来分配、监视、甚至控制在软件过程模型中定义的所有软件工程任务软件工程组的每一个成员都可以使用这样的工具来开发检查表，列出所有将要执行的工作任务、将要产生的工作产品和将要实施的软件质量保证活动过程技术工具还可用于协调适合某一特定工作任务的其它CASE工具的使用

2、软件工程管理过程软件工程管理包括进度管理、本钱管理、质量管理、人员管理、资源管理、标准化管理管理的对象是进度、系统规模及工作量估算、经费、组织机构和人员、风险、质量、作业和环境配置等软件工程管理所涉及的范围覆盖了整个软件生存期为使软件工程开发获得成功，一个关键问题是必须对软件开发工程的工作范围、可能遇到的风险、需要的资源（人、硬/软件）、要实现的任务、经历的里程碑、花费工作量（本钱），以及进度的安排等等做到心中有数而软件工程管理可以提供这些信息通常，这种管理在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，并且只有当软件开发工作最后结束时才终止

（1）启动一个软件工程在制定软件工程方案之前，必须先明确工程的目标和范围、考虑候选的解决方案、标明技术和管理上的要求有了这些信息，才能确定合理、精确的本钱估算，实际可行的任务分解以及可管理的进度安排工程的目标标明了软件工程的目的但不涉及如何去到达这些目的范围标明了软件要实现的根本功能，并尽量以定量的方式界定这些功能候选的解决方案虽然涉及方案细节不多，但有了方案，管理人员和技术人员就能够据此选择一种“好的〃方法，给出诸如交付期限、预算、个人能力、技术界面及其它许多因素所构成的限制

（2）制定工程方案制定方案的任务包括估算所需要的人力（通常以人月为单位）、工程持续时间（以年份或月份为单位）、本钱（以元为单位）作出进度安排，分配资源，建立工程组织及任用人员（包括人员的地位、作用、职责、规章制度等），根据规模和工作量估算分配任务进行风险分析，包括风险识别、风险估计、风险优化、风险驾驭策略、风险解决和风险监督这些步骤贯穿在软件工程过程中制定文档标准并建立相应机制，以保证文档能够及时建立；对所有工作组织细致的评审，使大多数人能够按方案进度完成自己的工作；对每一个关键性的技术人员，要培养后备人员这些风险驾驭步骤带来了额外的工程本钱例如，培养关键技术人员的后备需要花钱、花时间因此，当通过某个风险驾驭步骤而得到的收益被实现它们的本钱超出时要对风险驾驭局部进行评价，进行传统的本钱一效益分析对于一个大型的软件工程，可能识别30-40项风险如果每一项风险有3-7个风险驾驭步骤，那么风险驾驭本身也可能成为一个工程正因为如此，我们把Pareto的80/20规则用到软件风险上来经验说明，所有工程风险的80%即可能导致工程失败的80%的潜在因素能够通过20%的已识别风险来说明在早期风险分析步骤中所做的工作可以帮助方案人员确定，哪些风险属于这20%之内由于这个原因，某些被识别过、估计过及评价过的风险可以不写进风险驾驭方案中，因为它们不属于关键的20%具有最高工程优先级的风险风险驾驭步骤要写进风险缓解、监控和驾驭方案RMMM RiskMitigation Monitoringand ManagementPlan RMMM记叙了风险分析的全部工作，并且做为整个工程方案的一局部为工程管理人员所使用一旦制定出RMMM且工程已开始执行，风险缓解与监控就开始了风险缓解是一种问题回避活动，风险监控是一种工程追踪活动，它有三个主要目标判断一个预测的风险事实上是否发生了；确保针对某个风险而制定的风险消除步骤正在合理地使用；收集可用于将来的风险分析的信息多数情况下，工程中发生的问题总能追踪到许多风险风险监控的另一项工作就是要把“责任〃什么风险导致问题发生分配到工程中去风险分析需要占用许多有效的工程方案工作量识别，估计，评价，管理和监控都需要时间，但这些工作量花得值得孙子曾经说过“知己知彼，百战不殆〃

8、进度安排软件开发工程的进度安排有两种考虑方式1系统最终交付日期已经确定，软件开发部门必须在规定期限内完成；2系统最终交付日期只确定了大致的年限，最彳爰交付日期由软件开发部门确定彳麦一种安排能够对软件工程进行细致分析，最好地利用资源，合理地分配工作，而最后的交付日期可以在对软件进行仔细地分析之后再确定下来；但前一种安排在实际工作中常遇到，如不能按时完成，用户会不满意，甚至还会要求赔偿经济损失，所以必须在规定的期限内合理地分配人力和安排进度进度安排的准确程度可能比本钱估算的准确程度更重要软件产品可以靠重新定价或者靠大量的销售来弥补本钱的增加，但是进度安排的落空，会导致市场时机的丧失，使用户不满意，而且也会导致本钱的增加1软件开发小组人数与软件生产率对于一个小型软件开发工程，一个人就可以完成需求分析、设计、编码和测试工作随着软件开发工程规模的增大，就需要更多的人共同参与同一软件工程的工作，因此要求由多人组成软件开发组但是，软件产品是逻辑产品而不是物理产品，当几个人共同承当软件开发工程中的某一任务时，人与人之间必须通过交流来解决各自承当任务之间的接口问题，即所谓通信问题通信需花费时间和代价，会引起软件错误增加，降低软件生产率若两个人之间需要通信，则在这两人之间存在一条通信路径如果一个软件开发组有n个人，每两人之间都需要通信，则总的通信路径有n*n-l/2条假设一个人单独开发软件，生产率是5000行/人年若4个人组成一个小组共同开发这个软件，则需要6条通信路径若在每条通信路径上消耗的工作量是250行/人年则组中每人的生产率降低为5000-6X250/4=5000-375=4625行/人年从上述简单分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件工程，一个人单独开发，时间太长因此软件开发组是必要的有人提出，软件开发组的规模不能太大，人数不能太多，一般在28人左右为宜〜2任务确实定与并行性当参加同一软件工程工程的人数不止一人的时候，开发工作就会出现并行情形图显示了一个典型的由多人参加的软件工程工程的任务图*:工程阶段任务的里程碑图

9.12软件工程的并行性在软件开发过程的各种活动中，第一项任务是进行工程的需求分析和评审，此项工作为以后的并行工作打下了基础一旦软件的需求得到确认，并且通过了评审，概要设计系统结构设计和数据设计工作和测试方案制定工作就可以并行进行如果系统模块结构已经建立，对各个模块的详细设计、编码、单元测试等工作又可以并行进行待到每一个模块都已经调试完成，就可以对它们进行组装，并进行组装测试，最后进行确认测试，为软件交付进行确认工作在图中可以看到，软件开发进程中设置了许多里程碑里程碑为管理人员提供了指示工程进度的可靠依据当一个软件工程任务成功地通过了评审并产生了文档之后，一个里程碑就完成了软件工程工程的并行性提出了一系列的进度要求因为并行任务是同时发生的，所以进度方案必须决定任务之间的附属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间止匕外，应注意构成关键路径的任务，即若要保证整个工程能按进度要求完成，就必须保证这些任务要按进度要求完成这样就可以确定在进度安排中应保证的重点3制定开发进度方案图给出了在整个定义与开发阶段工作量分配的一种建议方案这个分配方案称为40—20—40规则它指出在整个软件开发过程中，编码的工作量仅占20%,编码前的工作量占40%,编码后的工作量占40%40-20-40规则只用来做为一个指南实际的工作量分配比例必须按照每个工程的特点来决定一般在方案阶段的工作量很少超过总工作量的2%3%,除非是具有高风险的巨额投资的工程需求分析可能占总工作量的10%25%花费在分析或原型〜〜化上面的工作量应当随工程规模和复杂性成比例地增加通常用于软件设计的工作量在20%25%之间而用在设计评审与反〜复修改的时间也必须考虑在内由于软件设计已经投入了工作量，因此其后的编码工作相对来说困难要小一些，用总工作量的15%20%就可以完成测〜试和随后的调试工作约占总工作量的30%40%所需要的测试量往往取决于软件的重要程度〜进一步地，由C0C0M0模型可知，开发进度TDEV与工作量MM的关系TDEV=aMMb如果想要缩短开发时间，或想要保证开发进度，必须考虑影响工作量的那些因素按可减小工作量的因素取值比较精确的进度安排可利用中间C0C0M0模型或详细C0C0M0模型4进度安排的方法软件工程的进度安排与任何一个多任务工作的进度安排根本差不多，因此，只要稍加修改，就可以把用于一般开发工程的进度安排的技术和工具应用于软件工程软件工程的进度方案和工作的实际进展情况，需要采用图示的方法描述，特别是表现各项任务之间进度的相互依赖关系以下介绍几种有效的图示方法在这几种图示方法中，有几个信息必须明确标明•各个任务的方案开始时间，完成时间；•各个任务完成的标志（即文档编写和△评审）；•各个任务与参与工作的人数，各个任务与工作量之间的衔接情况；•完成各个任务所需的物理资源和数据资源

①甘特图甘特图用水平线段表示任务的工作阶段；线段的起点和终点分别对应着任务的开工时间和完成时间；线段的长度表示完成任务所需的时间图

9.14给出了一个具有5个任务的甘特图如果这5条线段分别代表完成任务的方案时间，则在横坐标方向附加一条可向右移动的纵线它可随着工程的进展，指明已完成的任务（纵线扫过的）和有待完成的任务（纵线尚未扫过的）我们从甘特图上可以很清楚地看出各子任务在时间上的比照关系在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是必须交付应交付的文档与通过评审为标准因此在甘特图中，文档编制与评审是软件开发进度的里程碑甘特图的优点是标明了各任务的方案进度和当前进度，能动态地反映软件开发进展情况缺点是难以反映多个任务之间存在的复杂的逻辑关系任.OA务A-完成计划完成OAB-O文档编写△评审OAC---IOAD--------E--4--168910111213147当前进度图

9.14甘特图

②PERT技术和CPM方法PERT技术叫做方案评审技术，CPM方法叫做关键路径法，它们都是安排开发进度，制定软件开发方案的最常用的方法它们都采用网络图来描述一个工程的任务网络，也就是从一个工程的开始到结束，把应当完成的任务用图或表的形式表示出来通常用两张表来定义网络图一张表给出与一特定软件工程有关的所有任务（也称为任务分解结构），另一张表给出应当按照什么样的次序来完成这些任务（也称为限制表）PERT技术和CPM方法都为工程方案人员提供了一些定量的工具，以确定关键路径，即决定工程开发时间的任务链应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值计算边界时间，以便为具体的任务定义时间窗口边界时间的计算对于软件工程的方案调度是非常有用的BC5组装测可图

9.15开发模块A、B、C的任务网络图例如，某一开发工程在进入编码阶段之后，考虑安排三个模块A、B、C的开发工作其中，模块A是公用模块，模块B与C的测试有赖于模块A调试的完成模块C是利用现成已有的模块，但对它要在理解之后做局部修改最后直到A、B和C做组装测试为止这些工作步骤按图来安排在此图中，各边表示要完成的任务，边上均标注任务的名字，如“A编码〃表示模块A的编码工作边上的数字表示完成该任务的持续时间图中有数字编号的结点是任务的起点和终点，在图中，0号结点是整个任务网络的起点，8号结点是终点图中足够明确地说明了各项任务的方案时间，以及各项任务之间的依赖关系在组织较为复杂的工程任务时，或是需要对特定的任务进一步做更为详细的方案时，可以使用分层的任务网络图在软件工程工程中必须处理好进度与质量之间的关系在软件开发实践中常常会遇到这样的事情，当任务未能按方案完成时，只好设法加快进度赶上去但事实告诉我们，在进度压力下赶任务，其成果往往是以牺牲产品的质量为代价的还应当注意到，产品的质量与生产率有着密切的关系日本人有个说法在价格和质量上折衷是不可能的，但高质量给生产者带来了本钱的下降这一事实是可以理解的，这里的质量是指的软件工程过程的质量5工程的追踪和控制软件工程管理的一项重要工作就是在工程实施过程中进行追踪和控制可以用不同的方式进行追踪定期举行工程状态会议在会上，每一位工程成员报告他的进展和遇到的问题评价在软件工程过程中所产生的所有评审的结果确定由工程的方案进度所安排的可能选择的正式的里程碑比较在工程资源表中所列出的每一个工程任务的实际开始时间和方案开始时间非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价实际上有经验的工程管理人员已经使用了所有这些追踪技术软件工程管理人员还利用“控制〃来管理工程资源、覆盖问题、及指导工程工作人员如果事情进行得顺利即工程按进度安排要求且在预算内实施，各种评审说明进展正常且正在逐步到达里程碑，控制将是轻微的但当问题出现的时候，工程管理人员必须实行控制以尽可能快地排解它们在诊断出问题之后，在应用论域中可能需要一些追加资源；人员可能要重新部署，或者工程进度要重新调整

9、软件工程的组织1工程任务的划分软件工程的实施，如何进行工作的划分是实施方案首先应解决的问题常用的方案结构有

①按阶段进行工程的方案工作按软件生存期把全部工程开发工作划分为若干阶段活动，对每个阶段的工作做出方案再把每个阶段的工作进一步分解为若干个任务，做出任务方案还要把任务细分为若干步骤，做出步骤方案这样三层次的方案成为整个工程方案的依据显然，过细地做好分层方案，可以提高方案的精确度，减少或及早地发现问题

②任务分解结构按工程本身的实际情况进行自顶向下的结构化分解，形成树形任务结构，如图

9.16所示进一步把工作内容、所需的工作量、预计完成的期限也规定下来这样可以把划分彳爰的工作落实到人，做到责任明确，便于监督检查

③任务责任矩阵在任务分解的基础上，把工作分配给相关人员，用一个矩阵形表格表示任务的分工和责任例如，我们把图

9.16已分解的任务分配给五位软件开发人员，表

9.17说明了利用任务责任矩阵表达的分工情况从图中可以看出，工作的责任和任务的层次关系都非常明确表

9.17任务责任矩阵负责人张系统工程师王系统工程师李程序员赵程序员陈1审批收集信息审查设计实现加工信息审瓷统计设计实现计算设计实现打印报表审查设计实现2软件工程组织的建立参加软件工程的人员组织起来，发挥最大的工作效率，对成功地完成软件工程极为重要开发组织采用什么形式，要针对软件工程的特点来决定，同时也与参与人员的素质有关人的因素是不容无视的参数

①组织原则在建立工程组织时应注意到以下原则尽早落实责任软件工程要尽早指定专人负责使他有权有责减少接口一个组织的生产率是和完成任务中存在的通信路径数目成反比的因此，要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失责权均衡软件经理人员所负的责任不应比委任给他的权力还大

②组织结构的模式通常有三种组织结构的模式可供选择按课题划分的模式把软件人员按课题组成小组，小组成员自始至终参加所承当课题的各项任务，负责完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程按职能划分的模式把参加开发工程的软件人员按任务的工作阶段划分成若干专业小组待开发的软件产品在每个专业小组完成阶段加工即工序以后，沿工序流水线向下传递例如，分别建立方案组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等各种文档按工序在各组之间传递这种模式在小组之间的联系形成的接口较多，但便于软件人员熟悉小组的工作，进而变成这方面的专家各个小组的成员定期轮换有时是必要的，为的是减少每个软件人员因长期做单调的工作而产生的乏味感矩阵形模式这种模式实际上是以上两种模式的复合一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个工程又有它的经理人员负责管理每个软件人员属于某一个专门组，又参加某一工程的工作如图

9.17所示矩阵形结构的组织具有一些优点参加专门组的成员可在组内交流在各工程中取得的经验，这更有利于发挥专业人员的作用另一方面，各个工程有专人负责，有利于软件工程的完成显然，矩阵形结构是一种比较好的形式

③程序设计小组的组织形式通常认为程序设计工作是按独立方式进行的，程序人员独立地完成任务但这并不意味着互相之间没有联系人员之间联系的多少和联系的方式与生产率直接相关程序设计小组内人数少，如23人，则人员之间的联系比较〜简单但在增加人员数目时，相互之间的联系复杂起来，并且不是按线性关系增长并且，已经进行中的软件工程在任务紧张，延误了进度的情况下，不鼓励增加新的人员给予协助除非分配给新成员的工作是比较独立的任务，并不需要对原任务有更细致的了解，也没有技术细节的牵连小组内部人员的组织形式对生产率也有影响现有的组织形式有三种主程序员制小组小组的核心由一位主程序员、二至五位技术员、一位后援工程师组成主程序员负责小组全部技术活动的方案、协调与审查工作，还负责设计和实现工程中的关键局部技术员负责工程的具体分析与开发，以及文档资料的编写工作后援工程师支持主程序员的工作，为主程序员提供咨询，也做局部分析、设计和实现的工作并在必要时能代替主程序员工作主程序员制小组还可以由一些专家例如通信专家或数据库设计专家、辅助人员例如，打字员和秘书、软件资料员协助工作主程序员制的开发小组突出了主程序员的领导，参看图

9.18a这种集中领导的组织形式能否取得好的效果，很大程度上取决于主程序员的技术水平和管理才能民主制小组在民主制小组中，遇到问题，组内成员之间可以平等地交换意见，参见图b这种组织形式强调发挥小组每个成员的积极性，要求每个成员充分发挥主动精神和协作精神有人认为这种组织形式适合于研制时间长、开发难度大的工程层次式小组在层次式小组中，组内人员分为三级组长工程负责人一人负责全组工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动他直接领导二至三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员这种组织结构只允许必要的人际通信比较适用于工程本身就是层次结构的课题参看图c这种结构比较适合工程本身就是层次结构的课题可以把工程按功能划分成若干子工程，把子工程分配给基层小组，由基层小组完成基层小组的领导与工程负责人直接联系这种组织方式比较适合于大型软件工程的开发主程序员项目负责人a bc主程序员制小组民主制小组层次式小组图

9.18三种不同的小组结构上排的三种为结构形式，下排的三种为通信路径以上三种组织形式可以根据实际情况，组合起来灵活运用总之，软件开发小组的主要目的是发挥集体的力量进行软件研制3人员配备如何合理地配备人员，也是成功地完成软件工程的切实保证所谓合理地配备人员应包括按不同阶段适时任用人员，恰当掌握用人标准

①工程开发各阶段所需人员一个软件工程完成的快慢，取决于参与开发人员的多少在开发的整个过程中，多数软件工程是以恒定人力配备的如下图浪费掉的工作量按此曲线，需要的人力随开发的进展逐渐增加，在编码与单元测试阶段到达顶峰，以后又逐渐减少如果恒定地配备人力，在开发的初期，将会有局部人力资源用不上而浪费掉在开发的中期编码与单元测试，需要的人力又不够，造成进度的延误这样在开发的后期就需要增加人力以赶进度因此，恒定地配备人力，对人力资源是比较大的浪费

②配备人员的原则配备软件人员时，应注意以下三个主要原则重质量——软件工程是技术性很强的工作，任用少量有实践经验、有能力的人员去完成关键性的任务，常常要比使用较多的经验缺乏的人员更有效重培训——花力气培养所需的技术人员和管理人员是有效解决人员问题的好方法双阶梯提升——人员的提升应分别按技术职务和管理职务进行，不能混在一起

③对工程经理人员的要求软件经理人员是工作的组织者，他的管理能力的强弱是工程成败的关键除去一般的管理要求外，他应具有以下能力把用户提出的非技术性的要求加以整理提炼，以技术说明书的形式转告给分析员和测试员能说服用户放弃一些不切实际的要求，以便保证合理的要求得以满足能够把外表上似乎无关的要求集中在一起，归结为“需要什么〃，“要解决什么问题〃这是一种综合问题的能力要懂得心理学，能说服上级领导和用户，让他们理解什么是不合理的要求但又要使他们毫不勉强，乐于接受，并受到启发

④评价人员的条件软件工程中人的因素越来越受到重视在评价和任用软件人员时，必须掌握一定的标准人员素质的优劣常常影响到工程的成败能否到达以下这些条件是不应无视的牢固掌握计算机软件的根本知识和技能善于分析和综合问题，具有严密的逻辑思维能力工作踏实、细致，不靠碰运气，遵循标准和标准，具有严格的科学作风工作中表现出有耐心、有毅力、有责任心善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系具有良好的书面和口头表达能力

（4）指导与检验指导的目的是在软件工程的过程中，发动和促进工作人员积极完成所分配的任务实际上，指导也是属于人员管理的范围，是组织好软件工程不可缺少的工作检验是软件管理的最后一个方面它是对照方案检查执行情况的过程，同时也是对照软件工程标准检查实施情况的过程在发现工程的实施与方案或标准有较大的偏离时，应采取措施加以解决

①指导工作的要点在指导软件工程时需注意到以下几个方面的问题鼓励——对工作的兴趣和取得显著成绩常常能够成为推开工作的积极因素恰当而且及时地鼓励是非常重要的引导——通常，人们愿意追随那些能够体谅个人要求或实际困难的领导高明的领导人应能注意到这些,并能巧妙地把个人的要求和目标与工程工作的整体目标结合起来，至少应能做到在一定程度上的协调，而不应眼看着矛盾的存在和开展，以致影响工作的开展从风险分析中可知，大幅度的人员调整是非常有害的，它会带来许多实际问题即使是人员的临时观念也都要使工程付出不可见的代价，因而蒙受无形的损失通信——在软件工程中充满了人际通信联系必要的通信联络是不可少的但实践说明，软件生产率是通信量的函数如果人际通信数量过大，会使软件生产率迅速下降

②检验管理的要点在检验管理时应当注意到以下问题重大偏离——在软件工程实施过程中，必须注意发现工作的开展与已制定的方案之间、或与需遵循的标准（标准）之间的重大偏离遇到有这种情况应及时向管理部门报告并采取相应的措施给予适当的处置选定标准一一检验管理需要事先确定应当遵循的标准（或标准），使得软件工程的工作进展可以用某些客观、精确且有实际意义的标准加以衡量特殊情况——任何事务在一般规律之外都会存在一些特殊情况管理人员必须把注意力软件工程实施的一些特殊情况上，认真分析其中的一些特殊问题，加以解决

③检验管理的工作范围检验管理在软件工程中可能涉及到以下几个方面质量管理——包括明确度量软件质量的因素和准则，决定质量管理的方法和工具，以及实施质量管理的组织形式进度管理——检验进度方案执行的情况本钱管理——度量并控制软件工程的开销文档管理——检验文档编写是否符合要求配置管理——检验软件配置

④软件工程中人的因素软件产品是人们大量智力劳动的结晶，软件工程能否获得成功，人的因素在其中所起的作用比其它任何工程工程都突出用户是否参与及软件人员的能力等人的因素对软件生产率的影响极大在与软件本钱相关的影响因素中，人员的能力是最大影响因素如果在软件工程中能够充分发挥软件人员的积极性，使他们的才能得到尽量的施展，软件生产率（以单位时间内开发出的源程序的平均行数）最高可提高4倍多著名的软件工程专家Tom DeMarco积30年软件工程管理的经验，认为软件工程中对于人员的管理问题不能象其它事物那样简单地划分，机械地对待他特别注意到工程的规模、本钱、缺陷、加快开发的因素以及执行进度方案中的种种问题积累了500个工程开发过程的数据，从中发现大约15%的工程失败了有的是一开始就被撤消，有的中途流产，有的推迟了进度，有的成果不能投入使用而且工程规模越大，情况越糟究其原因，绝大多数失败的工程竟找不出一个可以说得出口的技术障碍；而障碍却来自人员之间的联系问题、人员的任用问题、对上级或对雇主失望、工作缺乏动力或缺乏高额工程维持费用等等这些人际关系问题的解决可归结于“软件工程社会学〃关于软件人员的办公环境，有许多因素影响着软件工作的效率DeMarco曾于1984年到1986年在62个公司的600名软件人员中进行编码和测试的竞赛活动，并对竞赛结果进行统计分析结果说明，除了对语言的熟悉程度、工作年限、工资收入等因素以外，环境因素因素着很大的作用良好的办公环境可保证软件人员高质量地完成任务这里所说的办公环境是指每个软件人员的办公室工作面积、办公环境安静程度、专用程度、电话干扰程度、工作时间内外面来访人员次数等DeMarco说，你如果是一名工程管理人员，你为软件人员安排了任务，提供了工作条件，而对工作环境所带来的影响估计缺乏，你还是应该承当责任

三、例题分析【例1】由于软件工程有如下的特点，使软件管理比其它工程的管理更为困难软件产品（A）（B）标准的过程大型软件工程往往是（C）工程（D）的作用是为有效地定量地进行管理，把握软件工程过程的实际情就是贯穿于软件工程过程中一系列风险管理步骤最后，每一个软件工程都要制定一个（F），一旦（G况和它所产生的产品质量在制定方案时，应当对人力、工程持续时间、本钱作出（E）；（H）实际上制定出来，就可以开始着手（H）A C.

①可见的

②不可见的

③“一次性〃

④“屡次〃

⑤存在

⑥不存在D H.

①进度安排

②度量

③风险分析

④估算

⑤追踪和控制答

⑥开发方案案A.

②，B.

⑥，C.F.

①，G.

⑥,H.

⑤③，D.

②，E.

④,供选择的答案:分析由于软件工程有如下的特点软件产品不可见；不存在标准的软件过程；大型软件工程往往是“一次性〃的工程，使得软件得管理比其它工程的管理更为困难；通常，软件人员和用户确定了软件工程的目标和范围之后,度量的作用就是为了有效地定量地进行管理对开发过程进行度量的目的是为了改良开发过程，而对产品进行度量的目的是为了提高产品的质量在软件工程管理过程中一个关键的活动是制定方案在做方案时，必须就需要的人力、工程持续时间、本钱作出估算；风险分析对于软件工程管理是决定性的，它实际上就是贯穿于软件工程过程中一系列风险管理步骤，其中包括风险识别、风险估计、风险评价和风险驾驭等步骤每一个软件工程都要制定一个进度安排，但不是所有的进度都要一样地安排一旦制定了开发方案，就可以开始着手追踪和控制活动【例2】在软件工程估算时，将代码行LOC和功能点FP数据在两个方面使用一是作为一个估算变量，度量软件每一个（A）的大小；一是联合使用从过去的工程中收集到的（B）和其它估算变量，进行本钱和（C）估算LOC和FP是两种不同的估算技术，但两者有许多共同的特征，只是LOC和FP技术对于分解所需要的（D）不同当用（E）作为估算变量时，功能分解是绝对必要且应到达很详细的程度，而用（F）作为估算变量时,分解程度可以不很详细（E）是直接估算，（F）是间接估算若方案人员对每个功能分别按最正确的、可能的、悲观的三种情况给出LOC或FP估计值，记作a,m,b,贝LOC或FP的期望值E的公式为（G）,m是加权的最可能的估计值，遵循（H）A C.

①模块

②软件工程

③分量

④持续时间

⑤工作量

⑥进度

⑦基线数据

⑧改良数据D.

①详细程度

②分解要求

③改良过程

④使用方法E,F.

①FP

②LOCG1E=a+m+b/32E二a+4m+b/

6.

③E=2a+3m+4b/3

①x概率

②丫概率

④泊松答案A.

③，B.

⑦，C.

⑤，D.

①,E.

②，F.

①，G.H.

③供选择的答案:分析在软件工程估算时，将代码行LOC和功能点FP数据在两个方面使用一是作为一个估算变量，度量软件每一个分量的大小；一是联合使用从过去的工程中收集到的基线数据（即对以往工程所做的估算值，保存下来作为后续工程的估算参考）和其它估算变量，进行本钱和工作量估算LOC和FP是两种不同的估算技术，但两者有许多共同的特征，工程方案人员首先给出一个有界的软件范围的叙述，再由此叙述尝试着把软件分解成一些小的可分别独立进行估算的子功能然后对每一个子功能估算其LOC或FP（即估算变量）接着，把基线生产率度量（如，LOC/PM或FP/PM）用做特定的估算变量，导出子功能的本钱或工作量将子功能的估算进行综合后就能得到整个工程的总估算LOC或FP估算技术对于分解所需要的详细程度是不同的当用LOC做为估算变量时，功能分解是绝对必要的且需要到达很详细的程度而估算功能点所需要的数据是宏观的量，当把FP当做估算变量时所需要的分解程度不很详细我们还应注意，LOC是直接估算的，而FP是通过估计输入、输出、数据文件、查询和外部接口的数目，以及14种复杂性校正值间接地确定的避开所用到的估算变量，工程方案人员可对每一个分解的功能提出一个有代表性的估算值范围利用历史数据或凭实际经验（当其它的方法失效时），工程方案人员对每个功能分别按最正确的、可能的、悲观的三种情况给出LOC或FP估计值记作a、川、bo当这些值的范围被确定之后，也就隐含地指明了估计值的不确定程度接着计算L0C或FP的期望值EoE=（a+4m+b）/

6.（加权平均）其中，可能的估计值m是加权最重的最可能的估算值且遵循B概率分布【例3】定义一个人参加劳动时间的长短为（A），其度量单位为PM（人月）或PY（人年）而定义完成一个软件工程（或软件任务）所需的（A）为（B），其度量单位是人月/工程（任务），记作PM（人月）进一步地，定义单位（A）所能完成的软件（C）的数量为软件（D），其度量单位为L0C/PM它说明一般指（E）的一个平均值例如，一个软件的开发工作量如下表所示该软件共有源代码2900行，其中，500行用于测试，2400行是执行（F）的源代码则劳动生产率是（G）（L0C/PM）阶段软件方案需求分析设计编码测试总计需要工作量（人月）

1.0供选择的答案A,B,D.

①生产率

②工作量

③本钱

④劳动量E.

①开发全过程

②某开发阶段

③软件生存期

④某开发任务F,C.

①软件

②程序

③进程

④产品G.

①520

②120

③320

④240答案A.

（4）,B.

②,C.

④，D.

①,E.

①，F.

②，G.表软件开发所需工作量例分析定义一个人参加劳动时间的长短为劳动量，其度量单位为PM（人月），PY（人年）它不同于工作量而定义完成一个软件工程（或软件任务）所需的劳动量为工作量，其度量单位是人月/工程（任务），记作PM（人月）进一步地，定义单位劳动量所能完成的软件产品的数量为软件生产率，其度量单位为LOC/PM它说明一般指开发全过程的一个平均值题例所示的软件共有源代码2900行，其中，500行用于测试，2400行是执行程序的源代码则劳动生产率是率900—500）/10=240（L0C/PM）o【例4】对于一个大型的软件工程，由于工程的复杂性，需要进行一系列的估算处理主要按（A）和（B）制定质量管理指标如何识别定义好的任务？管理人员对结束时间如何掌握，并如何识别和监控关键路径以确保结束？对进展如何度量？以及如何建立分隔任务的里程碑编制预算和本钱准备环境和基础设施等3方案的追踪和控制一旦建立了进度安排，就可以开始着手追踪和控制活动由工程管理人员负责在过程执行时监督过程的实施，提供过程进展的内部报告，并按合同规定向需方提供外部报告对于在进度安排中标明的每一个任务，如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的工程进度安排工具来确定在工程的中间里程碑上进度误期所造成的影响可对资源重新定向，对任务重新安排，或者做为最坏的结果可以修改交付日期以调整已经暴露的问题用这种方式可以较好地控制软件的开发4评审和评价方案的完成程度工程管理人员应对方案完成程度进行评审，对工程进行评价并对方案和工程进行检查，使之在变更或完成后保持完整性和一致性5编写管理文档工程管理人员根据合同确定软件开发过程是否完成如果完成，应从完整性方面检查工程完成的结果和记录，并把这些结果和记录编写成文档并存档

3、软件生产率和质量的度量1软件度量对软件进行度量，是为了说明软件产品的质量，弄清软件开发人员的生产率，给出使用了新的软件工程方法和工具所得到的在生产率和质量两方面的效益，建立工程估算的“基线〃，帮助调整对新的工具和附加培训的要求软件度量分为两类直接度量软件工程过程的直接度量包括所投入的本钱和工作量软件产品的直接度量包括产生的代码行数LOC、执行速度、存储量大小、在某种时间周期中所报告的过错数间接度量产品的间接度量则包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性只要事先建立特定的度量规程，很容易做到直接度量开发软件所需要的本钱和工作量、产生的代码行数等但是，软件的功能性、效率、可维护性等质量特性却很难用直接度量判明，只有通过间接度量才能推断我们可进一步将软件度量如图

9.5所示那样分类软件生产率度量主要关注软件工程过程的结果；软件质量度量则指明了软件适应明确和不明确的用户要求软件使用合理性到什么程度；技术度量主要关注软件的一些特性如逻辑复杂性、模块化程度而不是软件开发的全过程从图

9.5中还可以看到另一种分类方法面向规模的度量用于收集与直接度量有关的软件工程输出的信息和质量信息面向功能的度量提供直接度量的尺度面向人的度量则收集有关人们开发软件所用方式的信息和人们理解有关工具和方法的效率的信息2面向规模的度量面向规模的度量是对软件和软件开发过程的直接度量首先需要建立一个如表

9.1所示的面向规模的数据表格，记录过去几年完成的每一个软件工程和关于这些工程的相应面向规模的数据表

9.1面向规模的度量工程工作量人月元千规模KLOC文档页数错误数开发人数aaa-0124168365293ccc-04624401224865fff-03433141050646对于每一个工程，可以根据表格中列出的根本数据进行一些简单的面向规模的生产率和质量的度量例如,手段进行估算的方法分为三类从工程的整体出发，进行（B）的方法称为（C）估算法把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发总工作量的方法称为（D）估算法而把待开发的软件工程与过去已完成的软件工程做类比，区分出类似局部和不同局部分别处理的方法称为（E）估算法（F）是由多位专家进行本钱估算的方法供选择的答案A,B.

①类推

②类比

③分解

④综合C F.

①差异

②自顶向下

③自底向上

④专家判定技术

⑥比较

⑤循序渐进答案A.

③，B.

①,C.

②，D.

③，E.

①，F.

④分析对于一个大型的软件工程，由于工程的复杂性，开发本钱的估算不是一件简单的事，要进行一系列的估算处理主要靠分解和类推的手段进行根本估算方法分为三类

①自顶向下的估算方法这种方法的主要思想是从工程的整体出发，进行类推即估算人员根据以前已完成工程所消耗的总本钱（或总工作量），来推算将要开发的软件的总本钱（或总工作量），然后按比例将它分配到各开发任务单元中去，再来检验它是否能满足要求这种方法的优点是估算工作量小，速度快缺点是对工程中的特殊困难估计缺乏，估算出来的本钱盲目性大，有时会遗漏被开发软件的某些局部

②自底向上的估计法这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量这是一种常见的估算方法它的优点是估算各个局部的准确性高缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量（配置管理、质量管理、工程管理）所以往往估算值偏低，必须用其它方法进行检验和校正

③差异估计法这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件工程与过去已完成的软件工程进行类比，从其开发的各个子任务中区分出类似的局部和不同的局部类似的局部按实际量进行计算，不同的局部则采用相应的方法进行估算这种的方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似〃的界限专家判定技术是由多位专家进行本钱估算由于单独一位专家可能会有种种偏见，最好由多位专家进行估算，取得多个估算值【例5】Putnam模型是一种（A）模型需要建立一条连续的（B）,称为Rayleigh-Norden曲线可以由此导出一个（C）,把已交付的源代码（源语句）行数与工作量和开发时间联系起来请选择适宜的答案完成下面大型软件工程的开发工作量分布图供选择的答案A.

①单值

②多值

③静态多变量

④动态多变量

⑤静态单变量

②函数曲线

③资源需求曲线

④工作量分布B,C.

①软件方程

③测试与确认

②系统定义

④设计与编码D H.

①安装

⑤功能设计/规格说明答案A.

④，B.

④，C.

①，D.

②，E.

⑤，F.

④，G.

③，H.

①分析Putnam模型是1978年Putnam提出的模型，是一种动态多变量模型它假定在软件开发的整个生存期中工作量有特定的分布这种模型是依据在一些大型工程（总工作量到达或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件工程中大型软件工程的开发工作量分布可以用以下图所示的供选择的答案A,B.

①②月

③月

④月C.

①月

②36万美元

③万美元

④万美元D.

①万美元

②，C.

①，D.

④答案A.

③，B.Rayleigh-Norden曲线表示该曲线的典型形状由Lord Rayleigh最早有分析地导出，并由Norden使用收集到的软件开发中的经验数据证实了这条曲线用Rayleigh-Norden曲线可以导出一个“软件方程〃，把已交付的源代码（源语句）行数与工作量和开发时间联系起来L=Ck・KJ・td§其中，td是开发持续时间（以年计），K是软件开发与维护在内的整个生存期所花费的工作量（以人年计），L是源代码行数（以L0C计），Ck是技术状态常数，它反映出“阻碍程序员进展的限制〃，并因开发环境而异【例6】一个规模为10KDSI的商用微机远程通信的嵌入型软件，使用中间C0C0M0模型进行软件本钱估算程序的名义工作量MM=（A）；程序实际工作量MM=（B）；开发所用的时间TDEV=（C）；如果软件开发人员的工资都按每月6000美元计算，则该软件工程的开发人员的工资总额二（D）o表1中间C0C0M0模型的名义工作量与进度公式总体类型工作量进，度组织型MM=

3.2KDSI TDEV=

2.5MM半独立型MM=

3.0KDSI TDEV=

2.5MM嵌入型MM=

2.8KDSI TDEV=

2.5MM表2影响工作量的因素翼的取值影响工作量因素fi情况取值1软件可靠性只用于局部地区，恢复问题不严重（正常）2数据库规模20000字节（低）3产品复杂性用于远程通信处理（很高）4时间限制使用70%的CPU时间（高）5存储限制64K中使用45K（高）6机器使用商用微处理机（额定值）7周转时间平均2小时（额定值）8分析员能力优秀人才（高）9工作经验远程通信工作3年（低）10程序员能力优秀人才（高）11工作经验微型机工作6个月（正常）12语言使用经验12个月（正常）13使用现代程序设计技术1年以上（高）14使用软件工具根本的微型机软件（低）15工期9个月（正常）分析考虑如题中表2的15种影响软件工作量的因素，通过定下乘法因子，修正COCOMO工作量公式和进度公式,可更合理地估算软件（各阶段）的工作量和进度此时，实际工作量计算公式改成:15MM=r xfi x（KDSI）c口i=l由此得到程序名义工作量MM=*

（10）=

44.38（MM）15程序实际工作量（）MM=

44.38*[[fi=

44.38*

1.17=

51.5MMi=l开发所用时间TDEV=

2.5*（）=

8.9（月）如果分析员与程序员的工资都按每月6,000美元计算，则该工程的开发人员的工资总额为

51.5*6000=309000（美元）【例7】在特定情况下，是否必须进行风险分析，是对工程开发的形势进行（A）后确定的（A）可以按如下步骤进行明确工程的目标、总策略、具体策略和为完成所标识的目标而使用的方法和资源；保证该目标是（B）,工程成功的标准也是（B）；考虑采用某些条目作为工程成功的（C）；根据估计的结果来确定是否要进行风险分析一般来说，风险分析的方法要依赖于特定问题的需求和有关部门所关心的方面具体分3步进行第一步它可以估计各种风险项的值；第三步进行风险评估风险评估也有三个步骤确定（F），确定（G），把风做比险与“参照风险〃较供选择的答案A.

①风险管理

②风险估计

③风险评价

④风险测试B.

①可度量的

②不可度量的

③准确的

④不确定的C.

①标准

②标准

③过程模型@设计要求D,E.

①信息分类

⑤②信息收集

③度量尺度

④标准度量工具

⑥信息获取F,G.

①风险的范围

②风险的特性

③风险的级别

④风险的评价标准

⑤风险的排除策略答案A.

②，B.

①，C.

②，D.

②，E.

③，F.

④，G.

③分析在特定的情况下，是否必须进行风险分析，是对工程的开发形势进行风险估计后确定的因为风险分析需识别潜在的风险项，首先进行（D）过程；第二步估计每个风险的大小及其出现的可能性，选择一种（E）,要相当大的费用只有在软件的费用、软件的作用、软件的性能及软件与系统的关系等各方面对系统有比较大的影响时，即软件的风险对于整个系统的成败，或对系统的风险有关键的影响时，才有必要进行软件的风险分析和管理风险估计的步骤如下明确工程的目标、总策略、具体策略和为完成所标识的目标而使用的方法和资源；保证该目标是可度量的，工程成功的标准也是可度量的；考虑采用以下的某些条目作为工程成功的标准

①最大限度的收益，

②最小的费用，

③最小的风险损失，

④最大限度的市场，

⑤最小的周期性的波动，

⑥形成有益的形象，

⑦最正确的效劳质量，

⑧最高的增长率，

⑨员工的满意度最高，⑩公司声望最高；根据估计的结果来确定是否要进行风险分析一般来说，风险分析的方法要依赖于特定问题的需求和有关部门所关心的方面下面给出一种结构化的、一致的方法来进行风险分析具体分3步进行第一步识别潜在的风险项当确定要进行风险分析之后，就要收集信息，说明相关的风险这就需要观察风险的征兆，理解其产生的原因，并列出所有的风险项首先进行信息收集可以从过去完成的工程中收集已有的经验和收集来自群众的经验；可以模拟著名的事例；可以考虑类似的因素和进行常识性的判断；可以进行试验或测试以得到有关的结果，可以用各种方式来获得可能忽略的情况；此外，还可以针对经常发生的错误进行普查统计等一般来说，通过过去的历史来认识软件工程的风险也许时一种最好的方法例如，一些数字说明修复一个需求或设计阶段的错误的费用可能比修复一个测试阶段的错误的费用高100倍到1000倍因此，可以把需求阶段标识为一个软件开发各阶段的风险区域然后进行信息分类必须将收集到的信息以某种方式进行分类一种简单而有用的方法是把风险项分为三类有风险、可预见的风险、不可预见的风险“有风险〃是指经常发生的情况；“可预见的风险〃是指以较高概率出现的情况；“不可预见的风险〃是指不能识别的、未知的、不能观察的风险，是可能发生但事前很难预料的风险对于每一种类型，还可以按其原因分成三种子类型缺乏信息、缺乏管理及缺乏时间其它分类方法可以按直接或间接分类，按运行性或策略性分类，按技术、进度、本钱、支持分类第二步估计每个风险的大小及其出现的可能性，风险估计要度量所标识的各个风险可能造成的损失，即各种风险项的值（后果及程度），用以减少度量的不确定性可以按以下步骤进行选择某一种度量尺度，用以估计计算各种风险项的值，并具有适宜的精度由于要估计的风险信息可能有3种形式叙述性、定性或定量，所以可选的尺度可以是命名尺度、序次尺度、坐标尺度或比例尺度待估计的信息与度量尺度之间要建立对应关系，不同类型的信息有不同的度量尺度例如，叙述性信息需要有命名尺度或序次尺度，定量的信息需要坐标或比例性的尺度下表列出定量的风险等级风险等级失效概率说明极高超过当前的技术水平，肯定是技术问题很高超过当前的技术水平，极像是技术问题高最新的、尚未充分成熟的技术，好似是技术问题中等最正确技术，只会有很小的技术问题低使用的技术，没有技术问题很低在使用中的系统在使用不同的方法和技术进行风险估计时常常会出现偏差，这是由于缺少可用来进行判断的信息，从而限制了风险估计的精度由于信息分散，各人的理解和解释不同，造成“信息可用性偏差〃其次，选择的观念不同、专家的偏爱、采样规模的影响、样本相关的影响，以及修正的偏差等，都会产生估计的偏差特别要注意的是对于连续发生的事件和间断的不连续发生事件，这些偏差会造成什么样的影响必须采用一些技术来克服或消减风险估计中的不确定性风险一般可以看成属于以下三种过程之一行为型、自然型和随机型过程种类克服和消减叙述型的不确定性克服和消减度量型的不确定性行为型受定义人类行为的能力的限制受理性的人类行为的限制自然型理论上无限制，但实际上有一定范围受度量系统的精度的限制随机型理论上无限制，但实际上有一定范围无法消减不确定性第三步进行风险评估因为软件工程所面临的是风险的一个较大的集合及其相互之间的影响，因此，必须针对这一点进行风险评估，以到达以下的目的首先，考虑各种风险的综合影响后，对已识别风险发生的可能性及其后果给出最终的量值（如果情况发生变化，也许要重新分析风险发生的可能性和可能的后果）；其次，提供某种机制，对各个风险标明优先次序，以便予以适当安排；最后，通过考虑其它可替代的方案，寻找防止风险的根本方法，即为高层决策人员提供全部必要的信息，以作出合理的有依据的决策进行风险评估有三个步骤

①确定风险评估的标准其目的是可用以衡量每个风险的后果，即判定在工程的生存期中各个阶段的风险的后果是否可以接受此标准应与工程成功的标准相关2确定风险的级别其目的是把工程作为整体来评估就是说，人们必须理解各种风险之间的相互作用，以及修改某些因素会如何影响它们之间的相互作用为了说明可被评估的风险，引入“参照风险〃“参照风险〃可以是一组单个风险的集合，或对工程会造成最大损害的一个或多个风险必须仔细认清各风险间可能发生的耦合或复合情况说明在把系统视为一个整体时,风险将导致系统失败的概率3把风险与“参照风险〃做比较把已评定的风险与在早期确定的“参照风险〃相比较，结果可能是以下3种情况之一可接受（评定的风险低于“参照风险〃）；不可能接受（评定的风险大大高于“参照风险〃）；不适合接受（评定的风险大于，但几乎等于“参照风险〃）【例8】假设开发某个计算机应用系统的投资额为3000元，该计算机应用系统投入使用后，每年可以节约1000元，5年内可能节约5000元3000元是现在投资的钱，5000元是5年内节省的钱，两者不能简单地比较假定年利率为12%,利用计算货币现在价值的公式，可以算出该计算机应用系统投入使用后每年预计节省的供选择的答案

②

729.28元

③

602.4元

④

612.27元A.

①元

②

3.93年

③

4.25年

④

2.78元B.

①

2.4年

②30%

③20%415%C.

①25%C.

③答案A.

④，B.

②,金额的现在价值年节省（元）利率（1+）n现在价值（元）累计现在价值（元）

110001.1221000310004100051000则该系统的纯收入是（A）,投资回收期是（B）,投资回收率为（C）分析效益包括经济效益，也包括社会效益前者是有形的，后者是无形的系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用运行费用包括操作员人数、工作时间、消耗的物资等在计算系统的经济效益时，应按照货币的时间价值来计算，这是因为对工程的投资在前，而系统效益的产生在后，且常常有一个较长的过程通常，用利率表示货币的时间价值若设年利率为i,现已存入P元，则n年后可得到的钱数为F=（1+i）%F就是P元钱在n年后的价值反之，若n年后能收入F元，那么这些钱现在的价值是P=F/（l+i）由此，可从题意得该计算机应用系统在5年中的纯收入为

3612.27-（元）投资回收期约为:3+（3000-）/（-）x

3.93（年）投资回收率设为r,由以下方程式3000=1000/（1+r）+1000/（l+r）2+1000/（l+r）3+……+1000/（1+r）5解得r二20%o纯收入就是在整个生存期之内系统的累计经济效益（折合成现在值）与投资之差投资回收期就是使累计的经济效益等于最初的投资所需的时间投资回收率时投入资金所获得的利率【例9】软件工程管理的主要职能包括（A）,建立组织，配备人员，（B）和（C）由于软件工程的特有性质，o使得工程管理存在一定困难第

一、（D）,软件工程过程充满了大量高强度的脑力劳动；第

二、（E）,在特定机型上，利用特定的硬件配置，由特定的系统软件和支撑软件支持，形成了特定的开发环境；第

三、（F）,软件工程经历的各个阶段都深透了大量的手工劳动，远未到达自动化的程度；第

四、（G）,用户要经过专门的培训，才能掌握操作步骤，且需要配备专职维护人员进行售后效劳；第

五、（H）,为高质量地完成软件工程，充分开掘人员的智力才能和创造精神在总结和分析足够数量失误的软件工程之后可知，造成软件失误的原因大多与（I）工作有关在软件工程开始执行时，执行的过程中及工程进行的最后阶段都会遇到种种问题A C.

①编码

②制定方案

③开发

④指导

⑤测试

⑥检验D H.

①软件工作渗透了人的因素

②智力密集，可见性差

③单件生产

④使用方法繁琐，维护困难

⑤劳动密集，自动化程度低I.

①设计

②维护

③测试

④管理

⑤实践

⑥指导

⑦审核

⑧分析答案A.

②，B.

④，C.

⑥，D.

②,分析软E.

③，F.

⑤，G.

④，H.

①，I.

④件管理的主要职能包括供选择的答案:制定方案规定待完成的任务、要求、资源、人力和进度等建立组织为实施方案，保证任务的完成，需要建立分工明确的责任制机构配备人员任用各种层次的技术人员和管理人员指导鼓励和发动软件人员完成所分配的工作检验对照方案或标准，监督和检查实施的情况软件工程管理上的困难主要有

①智力密集，可见性差软件工程过程充满了大量高强度的脑力劳动软件开发的成果是不可见的逻辑实体，软件产品的质量难以用简单的尺度加以度量对于不深入掌握软件知识或缺乏软件开发实践经验的人员，是不可能领导做好软件管理工作软件开发任务完成得好也看不见，完成得不好有时也能制造假象，欺骗外行的领导

②单件生产在特定机型上，利用特定的硬件配置，由特定的系统软件或支撑软件的支持，形成了特定的开发环境再加上软件工程特定的目标，采用特定的开发方法、工具和语言，使得软件具有独一无二的特色，几乎找不到与之完全相同的软件产品这种建立在内容、形式各异的基础上的研制或生产方式，与其它领域中大规模现代化生产有着很大的差异，也自然会给管理工作造成许多实际困难

③劳动密集，自动化程度低软件工程经历的各个阶段都渗透了大量的手工劳动，这些劳动又十分细致、复杂和容易出错尽管近年来开展了软件工具和CASE的研究，但总体来说，仍远未到达自动化的程度软件产业所处的这一状态，加上软件本身的复杂性，使得软件的开发和维护难于防止多种错误，软件的正确性难于保证，软件产品质量的提高自然受到了很大的影响

④使用方法繁琐，维护困难用户使用软件需要掌握计算机的根本知识，或者接受专门的培训，否则面对多种使用手册、说明和繁琐的操作步骤，学会使用要花费很大力气另一方面，如果遇到软件运行出了问题，且没有配备专职维护人员，又得不到开发部门及时的售后效劳，软件的使用者更是徒唤奈何

⑤软件工作渗透了人的因素为高质量地完成软件工程，充分开掘人员的智力才能和创造精神，不仅要求软件人员具有一定的技术水平和工作经验，而且还要求他们具有良好的心理素质软件人员的情绪和他们的工作环境，对他们工作有很大的影响与其它行业相比，它的这一特点十分突出，必须给予足够的重视造成软件失误的原因在总结和分析足够数量失误的软件工程之后，看出其原因大多与管理工作有关在软件工程开始执行时，遇到的问题往往是可供利用的资料太少；工程负责人的责任不明确；工程的定义模糊；没有方案或方案过分粗糙；资源要求未按时做出安排而落空；没有明确规定子工程完成的标准；缺乏使用工具的知识；工程已有更动，但预算未随之改变在软件工程执行的过程中可能会发生工程审查只注意琐事而走过场；人员变动造成对工作的干扰；工程进行情况未能定期汇报；对阶段评审和评审中发现的问题如何处置未做出明确规定；资源要求并不像原来预计的那样大；未能做到严格遵循需求说明书；工程管理人员缺乏工程进行到最后阶段可能会发生未做质量评价；取得的知识和经验很少交流；未对人员工作情况做出评定；未做严格的移交；扩充性建议未写入文档资料总之，问题涉及到软件工程研制中的方案制定、进度估计、资源使用、人员配备、组织机构和管理方法等软件管理的许多侧面

四、习题【9-1】软件过程是软件（A）中的一系列相关软件工程（B）的集合每一个软件过程又是由一组（C）、工程（D）、软件工程产品和交付物以及质量保证（SQA）点等组成一个软件过程可以用右图的形式来表示首先建立一个（E）过程框架，其中定义了少量可适用于所有软件工程的框架（B）,再给出各个框架（B）的任务集合，最后是保护伞活动，如软件质量保证、软件配置管理以及测量等软件过程模型的选择基于工程和应用的特点、采用的（F）和工具、要求的控制和需交付的产品供选择的答案A F.

①工程

②公共

③活动

④生存期

⑤方法

⑥工作任务

⑦功能

⑧里程碑【9-2】软件的度量包括（A）和（B）软件产品的（A）包括产生的代码行数、执行速度等软件产品的（B）则包括若干质量特性我们还可进一步将软件度量如右图所示那样分类软件（C）度量主要关注软件工程过程的结果；（D）度量则指明了软件适应明确和不明确的用户要求到什么程度；（E）度量主要关注软件的一些特性而不是软件开发的全过程从图中还可看到另一种分类方法面向（F）的度量用于收集与直接度量有关软件工程输出的信息和质量信息面向（G）的度量提供直接度量的尺度面向（H）的度量则收集有关人们开发软件所用方供选择的答案A B.

①直接度量

②尺度度量

③二元度量

④间接度量C E.

①质量

②技术

③本钱

④生产率F H.

①过程

②对象

③人

④存取

⑤规模

⑥进程

⑦功能数据式的信息和人们理解有关工具和方法的效率的信息本身带有（A）o工程的复杂性越高，规模越大，开发工作量（B），估算的（A）就（C）工程的结构有化程度提高，进行精确估算的能力就能（D）,而风险将（E o用的历史信息（F），总的风险会减少供选择的答案A.

①风范（范型）

②风格

③风险

④度量B F.

①增加

②越多

③降低

④不变

⑥越高

⑦越大

⑤越少[9-4]在考虑各种软件开发资源时，（A如果把软件开发所需的资源画成一个金字塔形:）是最重要的资源在塔的上层是最根本的资源（A）,在底部为（B）（B）包括硬件资源和软件资源（C）、（I））o[9-3]估算资源、本钱和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气通常估算可建立（F）o供选择的答案

②人力

③工具

④上下文环境A,B.

①方法

②目标机

③自动机

④宿主机C,D.

①虚拟机

②分析设计工具

③支持工具

④编程工具E,F.

①维护工具

⑥框架工具

⑦原型化模拟工具

⑤可复用构件库和其它硬件设备属于硬件资源IPSE工具属于软件资源中的（E）为了提高软件的生产率和软件产品的质量,【9-5】任何软件工程都必须做好工程管理工作，最常使用的进度管理工具是（A），当某一开发工程的进度有可能拖延时，应该（B）对于一个典型的软件开发工程，各开发阶段需投入的工作量的百分比大致是（C）o各阶段所需不同层次的技术人员大致是（D），而管理人员在各阶段所需数量也不同，相对而言大致是（E）供选o择的答案A.

①数据流图

②程序结构图

③因果图

④PERT图B.

①增加新的开发人员

②分析拖期原因加以补救

③从别的小组抽调人员临时帮助

④推迟预定完成时间需求分析设计编码测试投入工作25252525量10203040153015405106530技术人员初级高级高级高级水平中级中级高级中级高级中高级初级中高级中级中高级中级初级管理人员多中少中数量中中中中多少多多少多少多【9-6】一个32KDSI的声音输入系统是一个输入原型，或是一个可行性表演模型所需可靠性非常低，因为它不打算投入生产性使用把此模型看做半独立型软件试问该软件的名义工作量和实际工作量【9-7】风险分析实际上是4个不同的活动，按顺序依次为（A）、（B）、风险评价和（C）在风险评价时，应当建立一个三元组［nL,必］,乙是风险描述，乙是（D）,而必是风险的影响一个对风险评价很有用的技术是定义（E）（F）、（G）、（H）是三种典型的（E）在做风险分析的上下文环境中一个（E）就存在一个单独的点，叫做参照点或（I）在这个点上要公正底给出判断实际上，参照点能A C.

①风险驾驭和监控

②风险识别

③风险估计

④风险消除在图上表示成一条平滑的曲线的情况很少，多数情况它是一个（J）供选择的答案D.

①风险的大小

②风险的概率

③风险的时间

④风险的范围E.

①风险参照水准

②风险度量

③风险监控

④风险工具F H.

①生产率

②功能

③本钱

④进度

⑤范围

⑥性能I,J.

①凹点

②崩溃点

③终点

④区域

⑤拐点@原点［9-8］对于一个小型的软件开发工程，一个人就可以完成需求分析、设计、编码和测试工作但随着软件工程规模增大，需要有多人共同参与同一软件工程的工作当几个人共同承当软件开发工程中的某一任务时，人与人之间必须通过交流来解决各自承当任务之间的（A）问题，即通信问题通信需花费时间和代价，会引起软件错误（B）,（C）软件生产率如果一个软件开发小组有n个人，每两人之间都需要通信，则共有（D）条通信路径假设一个人单独开发软件，生产率是5000行/人年，且在每条通信路径上消耗的工作量是250行/人年若4个人组成一个小组共同开发这个软件，则小组中每个人的软件生产率为（E）若小组有6名成员，则小组中每个成员的软件生产率为（F）o因此，有人提出，软件开发小组的规模不能太大，人数不能太多，一般在（G）人左右为宜供选择的答案A.

①分配

②管理

③接口

④协作B,C.

①降低

②增加

③不变

④n2/2D.

①nn+l/2

②nn-l/2

③nnT n-2/6

④5735E,F.

①4875

②4375

③4625G.

①8-15

②12

③25

④28〜〜〜【9-9】软件工程的进度管理有许多方法，但（A）不是常用的进度控制图示方法在几种进度控制图示方法中,（B）难以表达多个子任务之间的逻辑关系，使用（C）不仅能表达子任务之间的逻辑关系，而且可以找出关键子任务在（C）中，用带箭头的边表示（D）,用圆圈结点表示（E）,它标明（D）的（F）供选择的答案A C.

①甘特图

②IPO

③PERT

④时标网状图

②控制流

③事件

④处理D F.

①数据流

⑥任务

⑤起点或终点【9-10】软件工程组织的原则是（A）、（B）和（C）F）三种组织结构般有（D）、（E）、的模式（F）实际上是（D）和（E）两种模式的复合（E）这种模式在小组之间的联系形成的接口较多，但便于软件人员熟悉小组的工作,进而成为这方面的专家供选择的答案:C.

①推迟责任的落实

②尽早落实责任

③减少接口

④增加联系

⑤责权别离

⑥责权均衡F.

①矩阵形模式

②主程序员小组模式

③按课题划分的模式

④按职能划分的模式

⑤民主制小组模式【9-11】软件开发小组的目的是发挥集体的力量进行软件研制因此，小组从培养（A）的观点出发进行程序设计消除软件的（B）的性质通常，程序设计小组的组织形式有三种，如以下图所示的a属于（C）,b属（a）（b）（O主程序员制小组民主制小组层次式小组供选择的答案A,B.

①“局部〃

②“全局〃

③“集体〃

④“个人〃C E.

①层次式小组

②民主制小组

③主程序员制小组于（D）,c属于（E）o

五、习题解答[9-1]A.

（4）,B.

③，C.

⑥，D.

⑧，E.

②，F.

⑤软件过程是软件生存期中的一系列相关软件工程活动的集合每一个软件过程又是由一组工作任务、工程里程碑、软件工程产品和交付物以及质量保证（SQA）点等组成一个软件过程可以用右图的形式来表示首先建立一个公共过程框架，其中定义了少量可适用于所有软件工程的框架活动，而不考虑它们的规模和复杂性再给出各个框架活动的任务集合，使得框架活动能够适合于工程的特点和工程组的需求最后是保护伞活动，如软件质量保证、软件配置管理以及测量等，它们独立于任何一个框架活动并将贯穿于整个过程软件过程模型的选择基于工程和应用的特点、采用的方法和工具、要求的控制和需交付的产品[9-2]A.

①，B.

④，C.

④，D.

①，E.

②，F.

⑤,G.

⑦，H.

③软件的度量包括直接度量和间接度量软件产品的直接度量包括产生的代码行数、执行速度、存储量大小、在某种时间周期中所报告的过错数软件产品的间接度量则包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性只要事先建立特定的度量规程，很容易做到直接度量开发软件所产生的代码行数等但是，软件的功能性、效率、可维护性等质量特性却很难用直接度量判明，只有通过间接度量才能推断我们还可进一步将软件度量如下图那样分类软件生产率度量主要关注软件工程过程的结果；软件质量度量则指明了软件适应明确和不明确的用户要求（软件使用合理性）到什么程度；技术度量主要关注软件的一些特性（如逻辑复杂性、模块化程度）而不是软件开发的全过程从图中还可以看到另一种分类方法面向规模的度量用于收集与直接度量有关的软件工程输出的信息和质量信息面向功能的度量提供直接度量的尺度面向人的度量则收集有关人们开发软件所用方式的信息和人们理解有关工具和方法的效率的信息估算资源、本钱和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气通常估算本身带有（A）工程的复杂性越高，规模越大，开发工作量（C），估算的（A）就（D）工程的结构化程度的提高，进行精确估算的能力就能（E）,而风险将（F）o有用的历史信息（G），总的风险会减少供选择的答案A.

①风范（范型）

②风格

③风险

④度量B G.

①增加

②越大

③降低

④不变

⑤减少

⑥越高[9-3]A.

③，B.

②，C.

⑦，D.

①，E.

③，F.

②估算资源、本钱和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气估算本身带有风险增加风险的各种因素如下图结构化、定义、不确定性的程度/低风险区基于以往工作量的复杂性工作量的大小工程的复杂性对于增加软件估算的不确定性影响很大复杂性越高，估算的风险就越高但是，复杂性是相对度量，它与工程参加人员的经验有关工程的规模对于软件估算的精确性和成效影响也比较大因为随着软件规模的扩大，软件元素之间的相互依赖、相互影响程度迅速增加，因而估算的一个重要方法——问题分解会变得更加困难由此可知，工程的规模越大，开发工作量越大，估算的风险越高工程的结构化程度也影响工程估算的风险所谓结构性是指功能分解的简便性和处理信息的层次性结构化程度的提高，进行精确估算的能力就能提高，而风险将减少历史信息的有效性也影响估算的风险回忆过去，就能够仿效做过的事，且改良出现问题的地方在对过去的工程进行综合的软件度量之后，就可以借用来比较准确地进行估算，安排进度以防止重走过去的弯路，而总的风险也减少了风险靠对不确定性程度定量地进行估算来度量，止匕外，如果对软件工程的作用范围还不十分清楚，或者用户的要求经常变更，都会导致对软件工程所需资源、本钱、进度的估算频频变动，增加估算的风险[9-4]A.

②，B.

③，C.

②，D.

④，E.F.

⑤其中，C、D的答案顺序可互换软件工程方案的第二个任务是对完成该软件工程所需的资源进行估算若把软件开发所需的资源画成一个金字塔，在塔的底部必须有现成的用以支持软件开发的工具——硬件工具及软件工具，在塔的高层是最根本的资源——人在考虑各种软件开发资源时，人是最重要的资源在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要硬件是作为软件开发工程的一种工具而投入的在软件工程方案期间，考虑三种硬件资源宿主机（软件开发时使用的计算机及外围设备）；目标机（运行已开发成功软件的计算机及外围设备）；其它硬件设备（专用软件开发时需要的特殊硬件资源）宿主机连同必要的软件工具构成一个软件开发系统通常这样的开发系统能够支持多种用户的需要，且能保持大量的由软件开发小组成员共享的信息但在许多情况下，除了那些很大的系统之外,不一定非要配备专门的开发系统因此，所谓硬件资源，可以认为是对现存计算机系统的使用，而不是去购置一台新的计算机宿主机与目标机可以是同一种机型软件在开发期间使用了许多软件工具来帮助软件的开发这些软件工具叫做计算机辅助软件工程（CASE）o主要的软件工具分类为业务系统方案工具集；工程管理工具集；支持工具；分析和设计工具；编程工具；组装可以根据表

9.1对所有的工程计算出平均值生产率=KLOC/PM人月本钱=元/LOC质量=错误数/KLOC文档=文档页数/KLOC3面向功能的度量面向功能的软件度量是对软件和软件开发过程的间接度量面向功能度量的关注点在于程序的“功能性〃和“实用性〃，而不是对LOC计数一种典型的生产率度量法叫做功能点度量，该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能点FPs FunctionPointso功能点通过填写表

9.2所示的表格来计算首先确定五个信息域的特征，并在表格中相应位置给出计数信息域的值以如下方式定义用户输入数各个用户输入是面向不同应用的输入数据，对它们都要进行计数输入数据应有别于查询数据，它们应分别计数用户输出数各个用户输出是为用户提供的面向应用的输出信息，它们均应计数这里的输出是指报告,屏幕信息，错误信息等，在报告中的各数据项不应再分别计数用户查询数查询是一种联机输入，它导致软件以联机输出的方式生成某种即时的响应每一个不同的查询都要计数文件数每一个逻辑主文件都应计数这里的逻辑主文件，是指逻辑上的一组数据，它们可以是一个大的数据库的一局部，也可以是一个单独的文件外部接口数对所有被用来将信息传送到另一个系统中的机器可读写的接口即磁带或磁盘上的数据文件均应计数表

9.2功能点度量的计算加权因数简单中间复杂用户输入数346二用户输出数457用户查询数346文件数71015外部接口数5710二总计数一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值使用功能点方法的机构要自行拟定一些准则以确定一个特定项是简单的、平均的还是复杂的计算功能点，使用如下的关系式FP=总计数X〔+XSUM Fi〕

9.1其中，总计数是由表

9.2所得到的所有加权计数项的和；Fi i=1到14是复杂性校正值，它们应通过逐一答复表

9.3所提问题来确定SUM Fi是求和函数上述等式中的常数和应用于信息域计数的加权因数可经验地确定一旦计算出功能点，就可以仿照LOC的方式度量软件的生产率、质量和其它属性生产率=FP/PM人月本钱=元/FP质量=错误数/FP文档=文档页数/FP表

9.3计算功能点的校正值评定每个校正因素的尺度是0—5012没有影响偶然的适中的普通的重要的极重要的和测试工具；原型化和模拟工具；维护工具；框架工具这些框架工具能够提供一个建立集成工程支撑环境（IPSE）的框架在多数情况，框架工具实际提供了数据库管理和配置管理的能力与一些实用工具，能够把各种工具集成到IPSE中为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件构件库根据需要，对软件构件稍做加工，就可以构成一些大的软件包这要求这些软件构件应加以编目，以利引用，并进行标准化和确认，以利于应用和集成[9-5]A.B.

②，C.

③，D.

③，E.

①PERT技术叫做方案评审技术，是安排开发进度，制定软件开发方案的最常用的方法它采用网络图来描述一个工程的任务网络通常用两张表来定义网络图一张表给出与一特定软件工程有关的所有任务（也称为任务分解结构），另一张表给出应当按照什么样的次序来完成这些任务（有时称为限制表）当某一开发工程的进度有可能拖延时，应该分析拖期原因加以补救，切忌中途加人，否则反而会降低软件生产率对于一个典型的软件开发工程，各开发阶段需投入的工作量的百分比大致遵循40—20—40规则即在整个软件开发过程中，编码的工作量占20%,编码前的工作量占40%,编码后的工作量占40%对于一些规模较小的工程（1个人年或者更少），只要向专家做些咨询，也许一个人就可以完成所有的软件工程步骤而对一些规模较大的工程，在整个软件生存期中，各种人员的参与情况是不一样的如下图在软件方案和需求分析阶段，对软件系统进行定义，主要工作是由管理人员和高级技术人员在做，初级技术人员参与较少待到对软件进行具体设计、编码及测试时，管理人员逐渐减少对开发工作的参与，高级技术人员主要在设计方面把关，具体编码及调试参与较少，大量的工作将由初级技术人员去做到了软件开发的后期，需要对软件进行检验、评价和验收，管理人员和高级技术人员又将投入很多的精力rWj人员参加程度计需概细编单整确求要元体认划设码分设测测测析计计详试试试[9-6]对于这样一个规模为10KDSI的商用微机远程通信的嵌入式软件，使用中间C0C0M0模型进行软件本钱估算名义工作量为MM=

3.0*

（10）=146（人月）又查表知fi=,其它fi二，则最终计算出的实际工作量为MM=146*

0.75=110（人月）[9-7]A.

②，B.

③，C.

①，D.

②，E.

①，F.

③，G.

④，H.

⑥，I.

②，J.

④其中，F、G、H的答案顺序可互换风险分析实际上是4个不同的活动风险识别，风险估计，风险评价和风险驾驭与监控在进行风险评价时，可建立一系列三元组[nL,X-],其中，是风险，入是风险出现的可能性（概率），而必是风险产生的影响在做风险评价时，应进一步审查在风险估计时所得到的估计的准确性，尝试对已发现的风险进行优先排队，并着手考虑控制和/或消除可能出现风险的方法在做风险评价时常采用的一个非常有效的方法就是定义风险参照水准对于大多数软件工程来说，性能、支持、本钱、进度就是典型的风险参照水准就是说，对于本钱超支、进度延期、性能降低、支持困难，或它们的某种组合，都有一个水准值，超出它就会导致工程被迫终止在软件风险分析的上下文中，一个风险参照水准就有一个点，叫做参照点或崩溃点在这个点上，要公平地给出可接受的判断，看是继续执行工程工作，还是终止它们（出的问题太大）实际上，参照点能在图上被表示成一条平滑的曲线的情况很少在多数情况中，它是一个区域，在此区域中存在许多不确定性的范围[9-8]A.

③，B.

②，C.

①，D.

②，E.

③，F.

②，G.

④对于一个小型的软件开发工程，一个人就可以完成需求分析、设计、编码和测试工作但是，随着软件开发工程规模的增大，就会有更多的人共同参与同一软件工程的工作例如10个人1年可以完成的工程，若让1个人干10年是不行的因此，需要多人组成开发小组共同参加一个工程的开发但是，当几个人共同承当软件开发工程中的某一任务时，人与人之间必须通过交流来解决各自承当任务之间的接口问题，即所谓通信问题通信需花费时间和代价，会引起软件错误增加，降低软件生产率若两个人之间需要通信，则称在这两个人之间存在一条通信路径如果一个软件开发小组有n个人，每两人之间都需要通信，则总的通信路径有nn-l/2条假设一个人单独开发软件，生产率是5000行/人年若4个人组成一个小组共同开发这个软件，则需要6条通信路径图a若在每条通信路径上消耗的工作量是250行/人年则小组中每个人的软件生产率降低为5000-6X250/4=5000-375=4625行/人年如果小组有6名成员，通信路径增加到15条图b每条通信路径消耗的工作量不变，则小组中每个成员的软件生产率降低为5000-15X250/6=5000-625=4375行/人年a b四人之间所有通信路径六人之间所有通信路径从上述简单分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件工程，一个人单独开发，时间太长因此软件开发小组是必要的有人提出，软件开发小组的规模不能太大，人数不能太多，一般在28人左右为宜〜[9-9]A.

②，B.

①，C.

③，D.

⑥，E.

③，F.

⑤软件工程的进度方案和工作的实际进展情况，对于较大的工程来说，难以用语言叙述清楚特别是表现各项任务之间进度的相互依赖关系，需要采用图示的方法常用的图示方法有甘特图、时标网状图、PERT等，IPO图是用于在结构化设计中描述程序结构中输入一处理一输出的，不是进度控制的图示工具甘特图以水平线段表示任务的工作阶段；线段的起点和终点分别对应着任务的开工时间和完成时间；线段的长度表示完成任务所需的时间从甘特图上可以很清楚地看出各子任务在时间上的比照关系，并以文档编制与评审作为软件开发进度的里程碑甘特图的优点是标明了各任务的方案进度和当前进度，能动态地反映软件开发进展情况缺点是难以反映多个任务之间存在的复杂的逻辑关系时标网状图克服了甘特图的缺点，用具有时标的网状图来表示各个任务的分解情况，以及各个子任务之间在进度上的逻辑依赖关系参看以下图时标网状图中的箭头直线、折线表示各任务间的先决依赖关系；箭头上的名字表示任务代号；箭头的水平长度表示完成该任务的时间；而圆圈表示一个任务结束、另一个任务开始的事件PERT图也叫做方案评审技术，它采用网络图来描述一个工程的任务网络不仅可以表达子任务的方案安排,还可以在任务方案执行过程中估计任务完成的情况，分析某些子任务完成情况对全局的影响，找出影响全局的区域和关键子任务，以便及时采取措施，确保整个工程的完成在PERT图中，用箭头表示任务或子任务，箭头上附带的数字表示完成任务所需的时间；圆形结点表示事件，每一事件标明某些任务都已完成，下面另外一些任务将要开始[9-10]A.

②，B.

③，C.

⑥，D.

③，E.

④，F.

①其中，A、B、C答案顺序可互换在建立工程组织时应注意到以下原则尽早落实责任在软件工程工作的开始，要尽早指定专人负责使他有权进行管理，并对任务的完成负全责减少接口在开发过程中，人与人之间的联系是必不可少的，存在着通信路径一个组织的生产率是和完成任务中存在的通信路径数目是相互抵触的因此，要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失责权均衡软件经理人员所负的责任不应比委任给他的权力还大通常有三种组织结构的模式可供选择按课题划分的模式把软件开发人员按课题组成小组，小组成员自始至终参加所承当课题的各项任务他们应负责完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程按职能划分的模式把参加开发工程的软件人员按任务的工作阶段划分成若干个专业小组要开发的软件产品在每个专业小组完成阶段加工（即工序）以后，沿工序流水线向下传递例如，分别建立方案组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等各种文档资料按工序在各组之间传递这种模式在小组之间的联系形成的接口较多，但便于软件人员熟悉小组的工作，进而变成这方面的专家矩阵形模式这种模式实际上是以上两种模式的复合一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个工程又有它的经理人员负责管理每个软件人员属于某一个专门组，又参加某一工程的工作[9-11]A.

②，B.

④，C.

③，D.

②，E.

①软件开发小组的主要目的是发挥集体的力量进行软件研制因此，小组培养从“全局〃的观点出发进行程序设计，消除软件的“个人〃性质，并促进更充分的复审，小组提倡在共同工作中互相学习从而改善软件的质量小组内部人员的组织形式对生产率也有影响现有的组织形式有三种1主程序员制小组突出了主程序员的领导，强调主程序员与其他技术人员的直接联系，简化了人际通信这种集中领导的组织形式能否取得好的效果，很大程度上取决于主程序员的技术水平和管理才能美国的软件产业中大多是主程序员制的工作方式2民主制小组组内成员之间可以平等地交换意见，工作目标的制定及做出决定都由全体成员参加这种组织形式强调发挥小组每个成员的积极性，要求每个成员充分发挥主动精神和协作精神有人认为这种组织形式适合于研制时间长、开发难度大的工程日本在开展计算机事业中，组织软件开发大多采用这种形式的开发小组,取得了很好的效果

③层次式小组这种结构比较适合工程本身就是层次结构状的课题因为这样可以把工程按功能划分成若干个子工程，把子工程分配给基层小组，由基层小组完成基层小组的领导与工程负责人直接联系这种组织方式比较适合于大型软件工程的开发以上三种组织形式可以根据实际情况，组合起来灵活运用例如，较大的软件工程也许是把主程序员小组组织成层次式结构；也许基层小组的领导又是一个民主制小组的成员Fi1系统是否需要可靠的备份和恢复？2是否需要数据通信？3是否有分布式处理的功能？4性能是否是关键？5系统是否将运行在现有的高度实用化的操作环境中？6系统是否要求联机数据项？7联机数据项是否要求建立在多重窗口显示或操作上的输入事务8是否联机地更新主文件？9输入、输出、文件、查询是否复杂？10内部处理过程是否复杂？11程序代码是否要设计成可复用的？12设计中是否包含变换和安装？13系统是否要设计成多种安装形式以安装在不同的机构中？14应用系统是否要设计成便于修改和易于用户使用？功能点度量是为了商用信息系统应用而设计的Jones将其扩充，使这种度量可以被用于系统和工程软件应用，称之为特征点FPs FeaturePoints特征点度量适合于算法复杂性高的应用实时处理、过程控制、嵌入式软件o应用的算法复杂性都偏高，适于特征点度量为了计算特征点，可以象上面描述的那样，对信息域值进行计数和加权此外，需要对一个新的软件特征“算法〃进行计数可定义算法为“在一个特定计算机程序内所包含的一个有界的计算问题〃如矩阵求逆、二进位串转换为十进制数、处理一个中断等都是算法计算特征点可使用如表

9.4所示的表格对于每一个度量参数只使用一个权值，并且使用等式

9.1来计算总的特征点值表

9.4特征点度量的计算信息域参数计数权值加权计数用户输入数4用户输出数5二□□□用户查询数4文件数7外部接口数7算法3二□□□总计数必须注意，特征点与功能点表示的是同一件事由软件提供的“功能性〃或“实用性〃事实上，对于传统的工程计算或信息系统应用，两种度量会得出相同的FP值在较复杂的实时系统中，特征点计数常常比只用功能点确定的计数高出20%到35%4软件质量的度量质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后在软件交付之前得到的度量提供了一个定量的根据，以做出设计和测试质量好坏的判断这一类度量包括程序复杂性、有效的模块性和总的程序规模在软件交付之后的度量则把注意力集中于还未发现的过错数和系统的可维护性方面特别要强调的是，软件质量的售后度量可向管理者和技术人员说明软件工程过程的有效性到达什么程度虽然已经有许多软件质量的度量方法，但事后度量使用得最广泛它包括正确性、可维护性、完整性和可使用性Gilb提出了它们的定义和度量1正确性一个程序必须正确地运行，而且还要为它的用户提供某些输出正确性要求软件执行所要求的功能对于正确性，最一般的度量是每千代码行KL0C的过错数，其中将过错定义为已被证实是不符合需求的缺陷过错在程序交付用户普遍使用后由程序的用户报告，按标准的时间周期典型情况是1年进行计数2可维护性包括当程序中发现错误时，要能够很容易地修正它；当程序的环境发生变化时，要能够很容易地适应之；当用户希望变更需求时，要能够很容易地增强它还没有一种方法可以直接度量可维护性，因此必须采取间接度量有一种简单的面向时间的度量，叫做平均变更等待时间MTTC（Mean TimeTo Change）这个时间包o括开始分析变更要求、设计适宜的修改、实现变更并测试它、以及把这种变更发送给所有的用户一般地,一个可维护的程序与那些不可维护的程序相比，应有较低的MTTC（对于相同类型的变更）3完整性这个属性度量一个系统抗拒对它的平安性攻击（事故的和人为的）的能力软件的所有三个成分:程序、数据和文档都会遭到攻击为了度量完整性，需要定义两个附加的属性危险性和平安性危险性是特定类型的攻击将在一给定时间内发生的概率，它可以被估计或从经验数据中导出平安性是排除特定类型攻击的概率，它也可以被估计或从经验数据中导出一个系统的完整性可定义为完整性=£（1一危险性义（1一平安性））其中，对每一个攻击的危险性和平安性都进行累加4可使用性即用户友好性如果一个程序不具有“用户友好性〃，即使它所执行的功能很有价值，也常常会失败可使用性力图量化“用户友好性〃，并依据以下四个特征进行度量为学习系统所需要的体力上的和智力上的技能；为到达适度有效使用系统所需要的时间；当软件被某些人适度有效地使用时所度量的在生产率方面的净增值；用户角度对系统的主观评价（可以通过问题调查表得到）

4、软件工程的估算在做软件估算时往往存在某些不确定性，这将使得软件工程管理人员无法正常进行管理因为估算是所有其它工程方案活动的基石，且工程方案又为软件工程过程提供了工作方向，所以我们不能没有方案就开始着手开发，否则将会陷入盲目性

（1）估算估算资源、本钱和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气估算本身带有风险增加风险的各种因素如下图图中的轴线表示被估算工程的特征i结构化、定义、不确定性的程度基于以往工作量的复杂性工作量的大小/低风险区图

9.6估算与风险工程的复杂性对于增加软件估算的不确定性影响很大复杂性越高，估算的风险就越高但是，复杂性是相对度量，它与工程参加人员的经验有关例如，一个实时系统的开发，对于过去仅做过批处理应用工程的软件开发组来说是非常复杂的，但对于一个过去开发过许多高速过程控制软件的软件小组来说可能就是很容易的了此外，这种度量一般用在设计或编码级，而在软件方案时.（设计和代码存在之前）使用就很困难因此，可以在方案过程的早期建立其它较为主观的复杂性评估，如功能点复杂性校正因素工程的规模对于软件估算的精确性和成效影响也比较大因为随着软件规模的扩大，软件元素之间的相互依赖、相互影响程度迅速增加，因而估算的一个重要方法——问题分解会变得更加困难由此可知，工程的规模越大，开发工作量越大，估算的风险越高工程的结构化程度也影响工程估算的风险所谓结构性是指功能分解的简便性和处理信息的层次性结构化程度的提高，进行精确估算的能力就能提高，而风险将减少历史信息的有效性也影响估算的风险回忆过去，就能够仿效做过的事，且改良出现问题的地方在对过去的工程进行综合的软件度量之后，就可以借用来比较准确地进行估算，安排进度以防止重走过去的弯路，而总的风险也减少了风险靠对不确定性程度定量地进行估算来度量，止匕外，如果对软件工程的作用范围还不十分清楚，或者用户的要求经常变更，都会导致对软件工程所需资源、本钱、进度的估算频频变动，增加估算的风险方案人员应当要求在软件系统的规格说明中给出完备的功能、性能、接口的定义更重要的是，方案人员和用户都应认识到经常改变软件需求意味着在本钱和进度上的不稳定性

（2）软件的范围软件工程方案第一项活动就是确定软件的范围应当从管理角度和技术角度出发，确定明确的和可理解的工程范围，明确地给出定量的数据（如同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等），指明约束条件和限制（如存储容量）此外还要叙述某些质量因素（如给出的算法是否容易理解、是否使用高级语言等）软件范围包括功能、性能、限制、接口和可靠性在估算开始之前，应对软件的功能进行评价，并对其进行适当的细化以便提供更详细的细节由于本钱和进度的估算都与功能有关，因此常常采用某种程度的功能分解性能的考虑包括处理和响应时间的需求约束条件则标识外部硬件、可用存储或其它现有系统对软件的限制功能、性能和约束必须在一起进行评价当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级功能、性能和约束是密切联系在一起的软件与其它系统元素是相互作用的方案人员要考虑每个接口的性质和复杂性，以确定对开发资源、本钱和进度的影响接口的概念可解释为运行软件的硬件（如处理机与外设）及间接受软件控制的设备（如机器、显示器）;必须与新软件链接的现有的软件（如数据库存取例程、子程序包、操作系统）；通过终端或其它输入/输出设备使用该软件的人；该软件运行前后的一系列操作过程对于每一种情况，都必须清楚地了解通过接口的信息转换软件范围最不明确的方面就是可靠性的讨论软件可靠性的度量已经存在，但它们在工程的这个阶段难得用上因此，可以按照软件的一般性质规定一些具体的要求以保证它的可靠性

（3）软件开发中的资源软件工程方案的第二个任务是对完成该软件工程所需的资源进行估算图把软件开发所需的资源画成一个金字塔,在塔的底部有现成的用以支持软件开发的工具——硬件及软件工具，在塔的高层是最根本的资源——人通常，对每一种资源，应说明4个特性资源的描述，资源的有效性说明，资源在何时开始需要，使用资源的持续时间最后两个特性统称为时间窗口对每一个特定的时间窗口，在开始使用人需要的技能，开始时间，工作期限，有效性它之前就应说明它的有效性硬件开发系统，目标机器，新系统其它硬件部分软件支持软件，实用软件投入时间，持续时间，有效性图

9.7软件开发所需的资源

①人力资源在考虑各种软件开发资源时，人是最重要的资源在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要方案人员根据范围估算，选择为完成开发工作所需要的技能并在组织状况（如管理人员、高级软件工程师等）和专业（如通信、数据库、微机等）两方面做出安排对于一些规模较小的工程（1个人年或者更少），只要向专家做些咨询，也许一个人就可以完成所有的软件工程步骤对一些规模较大的工程，在整个软件生存期中，各种人员的参与情况是不一样的图

9.8画出了各类不同的人员随开发工作的进展在软件工程各个阶段的参与情况的典型曲线人高员参加程度计需概细编单整确求要元体认划设码分设测测测析计计详试试试图

9.8管理人员与技术人员的参与情况一个软件工程所需要的人数只能在对开发的工作量做出估算之后才能决定

②硬件资源硬件是作为软件开发工程的一种工具而投入的，可考虑三种硬件资源宿主机Host machine——软件开发时使用的计算机及外围设备；目标机Target machine——运行已开发成功软件的计算机及外围设备；其它硬件设备——专用软件开发时需要的特殊硬件资源；宿主机连同必要的软件工具构成一个软件开发系统通常这样的开发系统能够支持多种用户的需要，且能保持大量的由软件开发小组成员共享的信息但在许多情况下，除了那些很大的系统之外，不一定非要配备专门的开发系统因此，所谓硬件资源，可以认为是对现存计算机系统的使用，宿主机与目标机可以是同一种机型可以定义系统中其它的硬件元素为软件开发的资源例如，在开发自动排版软件的过程中，可能需要一台照相排版机所有硬件元素都应当由方案人员指定

③软件资源软件在开发期间使用了许多软件工具来帮助软件的开发软件工程人员使用在许多方面都类似于硬件工程人员所使用的CAD/CAE工具的软件工具集这种软件工具集叫做计算机辅助软件工程CASE主要的软件工具可做如下分类业务系统方案工具——业务系统方案工具借助特定的“元语言〃建立一个组织的战略信息需求的模型，导出特定的信息系统这些工具要解答一些简单但重要的问题，例如，业务关键数据从何处来？这些信息又向何处去？如何使用它们？当它们在业务系统中传递时又如何变换？要增加什么样的新信息？工程管理工具——工程管理人员使用这些工具可生成关于工作量、本钱及软件工程持续时间的估算定义开发策略及到达这一目标的必要的步骤方案可行的工程进程安排以及持续地跟踪工程的实施此外，管理人员还可使用工具收集建立软件开发生产率和产品质量的那些度量数据支持工具——支持工具可以分类为文档生成工具、网络系统软件、数据库、电子邮件、通报板，以及在开发软件时控制和管理所生成信息的配置管理工具分析和设计工具——分析和设计工具可帮助软件技术人员建立目标系统的分析模型和设计模型这些工具还帮助人们进行模型质量的评价它们靠对每一个模型进行执行一致性和有效性的检验，帮助软件技术人员在错误扩散到程序中之前排除之编程工具——系统软件实用程序、编辑器、编译器及调试程序都是CASE中必不可少的局部而除这些工具之外，还有一些新的编程工具面向对象的程序设计工具、第四代程序生成语言高级数据库查询系统，及一大批PC工具如表格软件组装和测试工具——测试工具为软件测试提供了各种不同类型和级别的支持有些工具，像路径覆盖分析器为测试用例设计提供了直接支持，并在测试的早期使用其它工具，像自动回归测试和测试数据生成工具,在组装和确认测试时使用，它们能帮助减少在测试过程中所需要的工作量原型化和模拟工具——原型化和模拟工具是一个很大的工具集，它包括的范围从简单的窗口画图到实时嵌入系统时序分析与规模分析的模拟产品原型化工具把注意力集中在建立窗口和为使用户能够了解一个信息系统或工程应用的输入/输出域而提出的报告使用模拟工具可建立嵌入式的实时应用，例如，为一架飞机建立航空控制系统的模型在系统建立之前，可以对用模拟工具建立起来的模型进行分析，对系统的运行时间性能进行评价维护工具——维护工具可以帮助分解一个现存的程序并帮助软件技术人员理解这个程序软件技术人员必须利用直觉、设计观念和人的智慧来完成逆向工程过程及再工程框架工具——这些工具能够提供一个建立集成工程支撑环境（IPSE）的框架在多数情况，框架工具实际提供了数据库管理和配置管理的能力与一些实用工具，能够把各种工具集成到IPSE中

④软件复用性及软件构件库为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件部件库根据需要，对软件部件稍做加工，就可以构成一些大的软件包这要求这些软件部件应加以编目，以利引用，并进行标准化和确认，以利于应用和集成在使用这些软件部件时，有两种情况必须加以注意如果有现成的满足要求的软件，应当设法搞到它因为搞到一个现成的软件所花的费用比重新开发一个同样的软件所花的费用少得多如果对一个现存的软件或软件部件，必须修改它才能使用这时必须多加小心，谨慎对待，因为修改时可能会引出新的问题而修改一个现存软件所花的费用有时会大于开发一个同样软件所花的费用

（4）分解技术当一个待解决的问题过于复杂时，可以把它进一步分解，直到分解后的子问题变得容易解决为止然后，分别解决每一个子问题，并将这些子问题的解答综合起来，从而得到原问题的解答通常，这是我们解决复杂问题的最自然的一种方法软件工程估算是一种解决问题的形式，在多数情况下，要解决的问题（对于软件工程来说，就是本钱和工作量的估算）非常复杂，想一次性整体解决比较困难因此，对问题进行分解，把其分解成一组较小的接近于最终解决的可控的子问题，再定义它们的特性

①LOC和FP估算LOC和FP是两个不同的估算技术但两者有许多共同特性工程方案人员首先给出一个有界的软件范围的叙述，再由此叙述把软件分解成一些小的可分别独立进行估算的子功能然后对每一个子功能估算其LOC或FP（即估算变量）接着，把根据以往完成工程得到的（基线）生产率度量（如，LOC/PM或FP/PM）用做特定的估算变量,导出子功能的本钱或工作量将子功能的估算进行综合后就能得到整个工程的总估算LOC或FP估算技术对于分解所需要的详细程度是不同的当用LOC做为估算变量时，功能分解是绝对必要的且需要到达很详细的程度而估算功能点所需要的数据是宏观的量，当把FP当做估算变量时所需要的分解程度不很详细应注意，LOC是直接估算的，而FP是通过估计输入、输出、数据文件、查询和外部接口的数目，以及在表

9.3中描述的14种复杂性校正值间接地确定的方案人员可对每一个分解的功能提出一个有代表性的估算值范围利用历史数据或凭实际经验，对每个功能分别按最正确的、可能的、悲观的三种情况给出LOC或FP估计值记作a、m、bo当这些值的范围被确定之后，也就隐含地指明了估计值的不确定程度接着计算L0C或FP的期望值EE=（a+4m+b）/6（加权平均）确定了估算变量的期望值，就可以用作L0C或FP的生产率数据作为L0C和FP估算技术的一个实例，考察一个为计算机辅助设计（CAD）应用而开发的软件包在这个实例中，使用L0C做为估算变量根据对软件范围的叙述，对软件功能进行分解，识别出主要的几个功能用户界面和控制功，二维几何分析，三维几何分析，数据库管理，计算机图形显示功能，外设控制以及设计分析模块通过下述的分解技术，可得到如表所示的估算表。