软件工程第八章复习资料

1、第九章 软件管理一、复习要求1. 了解软件过程的概念、软件过程框架和软件过程模型。2. 了解软件项目管理的过程。3. 了解软件度量的种类，面向规模和面向功能的度量以及质量度量的种类。4. 掌握LOC估算和FP估算的方法，分解技术和工作量估算方法。5. 了解软件成本估算的概念，掌握COCOMO成本估算方法。6. 了解软件成本效益估计方法。7. 了解风险分析的步骤，风险的种类、风险项目和风险构成。8. 了解软件进度安排方法及图形工具。9. 了解软件项目划分的方式，项目组织的模式，人员配备的原则和条件。二、内容提要1. 软件过程图9.1 软件工程层次(1) 软件过程的概念质量关注点方法工具过程软件工

2、程是一种层次化的技术，如图9.1所示。软件工程的过程层是将结合在一起的凝聚力量，使得计算机软件能够及时、合理地被开发出来。软件过程定义了一组关键过程域(KPAs)，它们构成软件项目管理的基础，并规定了技术方法的采用、工程产品(模型、文档、数据、报告、表格等)的产生、里程碑的建立、质量的管理以及适当的变更控制。任务集合保护伞活动图9.2 软件过程SQA点里程碑、交付物工作任务框架活动公共过程框架软件过程是软件生存期中的一系列相关软件工程活动的集合。每一个软件过程又是由一组工作任务、项目里程碑、软件工程产品和交付物以及质量保证(SQA)点等组成。一个软件过程可以用图9.2的形式来表示。首先建立一个

3、公共过程框架，其中定义了少量可适用于所有软件项目的框架活动，而不考虑它们的规模和复杂性。再给出各个框架活动的任务集合，使得框架活动能够适合于项目的特点和项目组的需求。最后是保护伞活动，如软件质量保证、软件配置管理以及测量等，它们独立于任何一个框架活动并将贯穿于整个过程。(2) 软件过程模型软件工程过程模型的选择基于项目和应用的特点、采用的方法和工具、要求的控制和需交付的产品。L.B.S.Raccoon使用了分级几何表示，用以讨论软件工程过程的本质。所有的软件开发都可以看成是一个问题循环解决过程，如图9.3所示。其中包括4个截然不同的阶段：状态捕获、问题定义、技术开发和方案综合。状态捕获表示了事

4、物的当前状态；问题定义标识了需要解决的特定问题；技术开发利用某些技术来解决问题；方案综合导出最终的结果(如文档、程序、数据、新的事务功能、新的产品)。图9.3 问题解决循环的各个阶段以上的问题循环解决过程可以用于软件工程的不同开发级别上。它可用于考虑整个应用系统的宏观级，也可用于建造程序构件的中间级，甚至还可用于源代码行级。因此，可以用分级几何表示来给出过程的理想化的视图。首先定义一个分级几何表示的模式，然后相继地在更小的规模上递归地应用分级几何表示：模式中嵌套模式。在图9.4中，问题循环解决过程的每一个阶段又包含一个同样的问题循环解决过程，该循环中每一个步骤中还可以再包含另一个问题循环解决过

5、程。这样一直继续下去，直到某个合理的边界为止。对于软件来说，就是源代码行。问题定义状态捕获技术开发方案综合问题定义技术开发状态捕获状态捕获方案综合问题定义技术开发状态捕获方案综合图9.4 问题循环解决过程中阶段嵌套阶段实际上，想要如图9.4那样清楚地划分这些活动是很困难的，因为在阶段内部常常会出现一些交叉的任务，它们还可能会跨越阶段。不过，这种简化的视图表达了一个重要的思想：不管软件项目选择了什么样的过程模型，但所有阶段，包括状态捕获、问题定义、技术开发、方案综合，在某个细节级别上都同时存在。由于给出了如图9.4所示的递归的性质，上述的4阶段论不但可用于整个应用的分析，而且同样地可用于某一代码

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

7、产生的工作产品和将要实施的软件质量保证活动。过程技术工具还可用于协调适合某一特定工作任务的其它CASE工具的使用。2、软件项目管理过程软件项目管理包括进度管理、成本管理、质量管理、人员管理、资源管理、标准化管理。管理的对象是进度、系统规模及工作量估算、经费、组织机构和人员、风险、质量、作业和环境配置等。软件项目管理所涉及的范围覆盖了整个软件生存期。为使软件项目开发获得成功，一个关键问题是必须对软件开发项目的工作范围、可能遇到的风险、需要的资源(人、硬软件)、要实现的任务、经历的里程碑、花费工作量(成本)，以及进度的安排等等做到心中有数。而软件项目管理可以提供这些信息。通常，这种管理在技术工作开

8、始之前就应开始，而在软件从概念到实现的过程中继续进行，并且只有当软件开发工作最后结束时才终止。(1) 启动一个软件项目在制定软件项目计划之前，必须先明确项目的目标和范围、考虑候选的解决方案、标明技术和管理上的要求。有了这些信息，才能确定合理、精确的成本估算，实际可行的任务分解以及可管理的进度安排。项目的目标标明了软件项目的目的但不涉及如何去达到这些目的。范围标明了软件要实现的基本功能，并尽量以定量的方式界定这些功能。候选的解决方案虽然涉及方案细节不多，但有了方案，管理人员和技术人员就能够据此选择一种“好的”方法，给出诸如交付期限、预算、个人能力、技术界面及其它许多因素所构成的限制。(2) 制定

9、项目计划制定计划的任务包括： 估算所需要的人力（通常以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）。 作出进度安排，分配资源，建立项目组织及任用人员(包括人员的地位、作用、职责、规章制度等)，根据规模和工作量估算分配任务。 进行风险分析，包括风险识别、风险估计、风险优化、风险驾驭策略、风险解决和风险监督。这些步骤贯穿在软件工程过程中。 制定质量管理指标：如何识别定义好的任务？管理人员对结束时间如何掌握，并如何识别和监控关键路径以确保结束？对进展如何度量？以及如何建立分隔任务的里程碑。 编制预算和成本。 准备环境和基础设施等。(3) 计划的追踪和控制一旦建立了进度安排，就

10、可以开始着手追踪和控制活动。由项目管理人员负责在过程执行时监督过程的实施，提供过程进展的内部报告，并按合同规定向需方提供外部报告。对于在进度安排中标明的每一个任务，如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。可对资源重新定向，对任务重新安排，或者(做为最坏的结果)可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制软件的开发。(4) 评审和评价计划的完成程度项目管理人员应对计划完成程度进行评审，对项目进行评价。并对计划和项目进行检查, 使之在变更或完成后保持完整性和一致性。(5) 编写管理文档项目管理

11、人员根据合同确定软件开发过程是否完成。如果完成，应从完整性方面检查项目完成的结果和记录，并把这些结果和记录编写成文档并存档。3、软件生产率和质量的度量(1) 软件度量对软件进行度量，是为了表明软件产品的质量，弄清软件开发人员的生产率，给出使用了新的软件工程方法和工具所得到的(在生产率和质量两方面)的效益，建立项目估算的“基线，帮助调整对新的工具和附加培训的要求。软件度量分为两类： 直接度量：软件工程过程的直接度量包括所投入的成本和工作量。软件产品的直接度量包括产生的代码行数(LOC)、执行速度、存储量大小、在某种时间周期中所报告的差错数。 间接度量：产品的间接度量则包括功能性、复杂性、效率、可

12、靠性、可维护性和许多其它的质量特性。图9.5 软件度量只要事先建立特定的度量规程，很容易做到直接度量开发软件所需要的成本和工作量、产生的代码行数等。但是，软件的功能性、效率、可维护性等质量特性却很难用直接度量判明，只有通过间接度量才能推断。我们可进一步将软件度量如图9.5 所示那样分类。软件生产率度量主要关注软件工程过程的结果；软件质量度量则指明了软件适应明确和不明确的用户要求(软件使用合理性)到什么程度；技术度量主要关注软件的一些特性(如逻辑复杂性、模块化程度)而不是软件开发的全过程。从图9.5中还可以看到另一种分类方法：面向规模的度量用于收集与直接度量有关的软件工程输出的信息和质量信息。面

13、向功能的度量提供直接度量的尺度。面向人的度量则收集有关人们开发软件所用方式的信息和人们理解有关工具和方法的效率的信息。(2) 面向规模的度量面向规模的度量是对软件和软件开发过程的直接度量。首先需要建立一个如表9.1所示的面向规模的数据表格，记录过去几年完成的每一个软件项目和关于这些项目的相应面向规模的数据。表9.1 面向规模的度量项目工作量(人月)元(千)规模(KLOC)文档页数错误数开发人数aaa-012416812.1365293ccc-046244027.21224865fff-034331417.51050646 对于每一个项目，可以根据表格中列出的基本数据进行一些简单的面向规模的生产

14、率和质量的度量。例如，可以根据表9.1对所有的项目计算出平均值： 生产率 KLOCPM（人月）成本 元LOC质量 错误数KLOC文档 文档页数KLOC(3) 面向功能的度量面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量的关注点在于程序的“功能性”和“实用性”，而不是对LOC计数。一种典型的生产率度量法叫做功能点度量，该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能点FPs（Function Points）。功能点通过填写表9.2所示的表格来计算。首先确定五个信息域的特征，并在表格中相应位置给出计数。信息域的值以如下方式定义： 用户输入数：各个用户输入

15、是面向不同应用的输入数据，对它们都要进行计数。输入数据应有别于查询数据，它们应分别计数。 用户输出数：各个用户输出是为用户提供的面向应用的输出信息，它们均应计数。这里的输出是指报告，屏幕信息，错误信息等，在报告中的各数据项不应再分别计数。 用户查询数：查询是一种联机输入，它导致软件以联机输出的方式生成某种即时的响应。每一个不同的查询都要计数。 文件数：每一个逻辑主文件都应计数。这里的逻辑主文件，是指逻辑上的一组数据，它们可以是一个大的数据库的一部分，也可以是一个单独的文件 外部接口数：对所有被用来将信息传送到另一个系统中的机器可读写的接口(即磁带或磁盘上的数据文件)均应计数。计数 表9.2 功

16、能点度量的计算信息域参数加 权 因 数 简单 中间 复杂用户输入数346=用户输出数457=用户查询数346=文 件 数71015=外部接口数5710=加权计数总 计 数 一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值。使用功能点方法的机构要自行拟定一些准则以确定一个特定项是简单的、平均的还是复杂的。计算功能点，使用如下的关系式： FP 总计数0.650.01SUM（Fi） （9.1）其中，总计数是由表9.2所得到的所有加权计数项的和；Fi（i = 1到14）是复杂性校正值，它们应通过逐一回答表9.3所提问题来确定。SUM（Fi）是求和函数。上述等式中的常数和应用于信息域计数的加权

17、因数可经验地确定。一旦计算出功能点，就可以仿照LOC的方式度量软件的生产率、质量和其它属性：生产率 FPPM（人月）成本 元FP质量 错误数FP文档 文档页数FP表9.3 计算功能点的校正值评定每个校正因素的尺度是05 0 1 2 3 4 5 没有影响 偶然的 适中的 普通的 重要的 极重要的Fi1系统是否需要可靠的备份和恢复？2是否需要数据通信？3是否有分布式处理的功能？4性能是否是关键？5系统是否将运行在现有的高度实用化的操作环境中？6系统是否要求联机数据项？7联机数据项是否要求建立在多重窗口显示或操作上的输入事务？8是否联机地更新主文件？9输入、输出、文件、查询是否复杂？10内部处理过程

18、是否复杂？11程序代码是否要设计成可复用的？12设计中是否包含变换和安装？13系统是否要设计成多种安装形式以安装在不同的机构中？14应用系统是否要设计成便于修改和易于用户使用？功能点度量是为了商用信息系统应用而设计的。Jones将其扩充，使这种度量可以被用于系统和工程软件应用，称之为特征点FPs（Feature Points）。特征点度量适合于算法复杂性高的应用。实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，适于特征点度量。为了计算特征点，可以象上面描述的那样，对信息域值进行计数和加权。此外，需要对一个新的软件特征“算法”进行计数。可定义算法为“在一个特定计算机程序内所包含的一个有界的

19、计算问题。”如矩阵求逆、二进位串转换为十进制数、处理一个中断等都是算法。计算特征点可使用如表9.4所示的表格。 对于每一个度量参数只使用一个权值，并且使用等式（9.1）来计算总的特征点值。表9.4 特征点度量的计算信息域参数计数 权值加权计数用户输入数4=用户输出数5=用户查询数4=文 件 数7=外部接口数7=算 法3=总 计 数 必须注意，特征点与功能点表示的是同一件事：由软件提供的“功能性”或“实用性”。事实上，对于传统的工程计算或信息系统应用，两种度量会得出相同的FP值。在较复杂的实时系统中，特征点计数常常比只用功能点确定的计数高出20到35。(4) 软件质量的度量质量度量贯穿于软件工程

20、的全过程中以及软件交付用户使用之后。在软件交付之前得到的度量提供了一个定量的根据，以做出设计和测试质量好坏的判断。这一类度量包括程序复杂性、有效的模块性和总的程序规模。在软件交付之后的度量则把注意力集中于还未发现的差错数和系统的可维护性方面。特别要强调的是，软件质量的售后度量可向管理者和技术人员表明软件工程过程的有效性达到什么程度。虽然已经有许多软件质量的度量方法，但事后度量使用得最广泛。它包括正确性、可维护性、完整性和可使用性。Gilb提出了它们的定义和度量。 正确性：一个程序必须正确地运行，而且还要为它的用户提供某些输出。正确性要求软件执行所要求的功能。对于正确性，最一般的度量是每千代码行

21、(KLOC)的差错数，其中将差错定义为已被证实是不符合需求的缺陷。差错在程序交付用户普遍使用后由程序的用户报告，按标准的时间周期(典型情况是1年)进行计数。 可维护性：包括当程序中发现错误时，要能够很容易地修正它；当程序的环境发生变化时，要能够很容易地适应之；当用户希望变更需求时，要能够很容易地增强它。还没有一种方法可以直接度量可维护性，因此必须采取间接度量。有一种简单的面向时间的度量，叫做平均变更等待时间MTTC（Mean Time To Change)。 这个时间包括开始分析变更要求、设计合适的修改、实现变更并测试它、以及把这种变更发送给所有的用户。一般地，一个可维护的程序与那些不可维护的

22、程序相比，应有较低的MTTC（对于相同类型的变更)。 完整性：这个属性度量一个系统抗拒对它的安全性攻击(事故的和人为的)的能力。软件的所有三个成分：程序、数据和文档都会遭到攻击。为了度量完整性，需要定义两个附加的属性：危险性和安全性。危险性是特定类型的攻击将在一给定时间内发生的概率，它可以被估计或从经验数据中导出。安全性是排除特定类型攻击的概率，它也可以被估计或从经验数据中导出。一个系统的完整性可定义为： 完整性 （1危险性（1安全性）其中，对每一个攻击的危险性和安全性都进行累加。 可使用性：即用户友好性。如果一个程序不具有“用户友好性”，即使它所执行的功能很有价值，也常常会失败。可使用性力图

23、量化“用户友好性”，并依据以下四个特征进行度量： 为学习系统所需要的体力上的和智力上的技能； 为达到适度有效使用系统所需要的时间； 当软件被某些人适度有效地使用时所度量的在生产率方面的净增值； 用户角度对系统的主观评价(可以通过问题调查表得到)。4、软件项目的估算在做软件估算时往往存在某些不确定性，这将使得软件项目管理人员无法正常进行管理。因为估算是所有其它项目计划活动的基石，且项目计划又为软件工程过程提供了工作方向，所以我们不能没有计划就开始着手开发，否则将会陷入盲目性。(1) 估算估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。估算本身带有风险。增加风险的

24、各种因素如图9.6所示。图中的轴线表示被估算项目的特征。图9.6 估算与风险项目的复杂性对于增加软件估算的不确定性影响很大。复杂性越高，估算的风险就越高。但是，复杂性是相对度量，它与项目参加人员的经验有关。例如，一个实时系统的开发，对于过去仅做过批处理应用项目的软件开发组来说是非常复杂的，但对于一个过去开发过许多高速过程控制软件的软件小组来说可能就是很容易的了。此外，这种度量一般用在设计或编码级，而在软件计划时(设计和代码存在之前)使用就很困难。因此，可以在计划过程的早期建立其它较为主观的复杂性评估，如功能点复杂性校正因素。项目的规模对于软件估算的精确性和功效影响也比较大。因为随着软件规模的扩

25、大，软件元素之间的相互依赖、相互影响程度迅速增加，因而估算的一个重要方法问题分解会变得更加困难。由此可知，项目的规模越大，开发工作量越大，估算的风险越高。项目的结构化程度也影响项目估算的风险。所谓结构性是指功能分解的简便性和处理信息的层次性。结构化程度的提高，进行精确估算的能力就能提高，而风险将减少。历史信息的有效性也影响估算的风险。回顾过去，就能够仿效做过的事，且改进出现问题的地方。在对过去的项目进行综合的软件度量之后，就可以借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。风险靠对不确定性程度定量地进行估算来度量，此外，如果对软件项目的作用范围还不十分清楚，或者用

26、户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频频变动，增加估算的风险。计划人员应当要求在软件系统的规格说明中给出完备的功能、性能、接口的定义。更重要的是，计划人员和用户都应认识到经常改变软件需求意味着在成本和进度上的不稳定性。(2) 软件的范围软件项目计划第一项活动就是确定软件的范围。应当从管理角度和技术角度出发，确定明确的和可理解的项目范围，明确地给出定量的数据(如同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等)，指明约束条件和限制(如存储容量)。此外还要叙述某些质量因素(如给出的算法是否容易理解、是否使用高级语言等)。软件范围包括功能、性能、限制、接口和可靠

27、性。在估算开始之前，应对软件的功能进行评价，并对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常常采用某种程度的功能分解。性能的考虑包括处理和响应时间的需求。约束条件则标识外部硬件、可用存储或其它现有系统对软件的限制。功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。功能、性能和约束是密切联系在一起的。软件与其它系统元素是相互作用的。计划人员要考虑每个接口的性质和复杂性，以确定对开发资源、成本和进度的影响。接口的概念可解释为： 运行软件的硬件(如处理机与外设)及间接受软件控制的设备(如机器、显示器)； 必须与新软

28、件链接的现有的软件(如数据库存取例程、子程序包、操作系统)； 通过终端或其它输入输出设备使用该软件的人； 该软件运行前后的一系列操作过程。对于每一种情况，都必须清楚地了解通过接口的信息转换。软件范围最不明确的方面就是可靠性的讨论。软件可靠性的度量已经存在，但它们在项目的这个阶段难得用上。因此，可以按照软件的一般性质规定一些具体的要求以保证它的可靠性。(3) 软件开发中的资源软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。图9.7把软件开发所需的资源画成一个金字塔，在塔的底部有现成的用以支持软件开发的工具硬件及软件工具，在塔的高层是最基本的资源人。通常，对每一种资源，应说明4个特性

29、：资源的描述，资源的有效性说明，资源在何时开始需要，使用资源的持续时间。最后两个特性统称为时间窗口。对每一个特定的时间窗口，在开始使用它之前就应说明它的有效性。图9.7 软件开发所需的资源 人力资源在考虑各种软件开发资源时，人是最重要的资源。在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要。计划人员根据范围估算，选择为完成开发工作所需要的技能。并在组织状况(如管理人员、高级软件工程师等)和专业(如通信、数据库、微机等)两方面做出安排。对于一些规模较小的项目(1个人年或者更少)，只要向专家做些咨询，也许一个人就可以完成所有的软件工程步骤。对一些规模较大的

30、项目，在整个软件生存期中，各种人员的参与情况是不一样的。图9.8画出了各类不同的人员随开发工作的进展在软件工程各个阶段的参与情况的典型曲线。图9.8 管理人员与技术人员的参与情况一个软件项目所需要的人数只能在对开发的工作量做出估算之后才能决定。 硬件资源硬件是作为软件开发项目的一种工具而投入的，可考虑三种硬件资源： 宿主机(Host machine)软件开发时使用的计算机及外围设备； 目标机(Target machine)运行已开发成功软件的计算机及外围设备； 其它硬件设备专用软件开发时需要的特殊硬件资源；宿主机连同必要的软件工具构成一个软件开发系统。通常这样的开发系统能够支持多种用户的需要，

31、且能保持大量的由软件开发小组成员共享的信息。但在许多情况下，除了那些很大的系统之外，不一定非要配备专门的开发系统。因此，所谓硬件资源，可以认为是对现存计算机系统的使用，宿主机与目标机可以是同一种机型。可以定义系统中其它的硬件元素为软件开发的资源。例如，在开发自动排版软件的过程中，可能需要一台照相排版机。所有硬件元素都应当由计划人员指定。 软件资源软件在开发期间使用了许多软件工具来帮助软件的开发。软件工程人员使用在许多方面都类似于硬件工程人员所使用的CADCAE工具的软件工具集。这种软件工具集叫做计算机辅助软件工程（CASE）。主要的软件工具可做如下分类。 业务系统计划工具业务系统计划工具借助特

32、定的“元语言”建立一个组织的战略信息需求的模型，导出特定的信息系统。这些工具要解答一些简单但重要的问题，例如，业务关键数据从何处来？这些信息又向何处去？如何使用它们？当它们在业务系统中传递时又如何变换？要增加什么样的新信息？ 项目管理工具项目管理人员使用这些工具可生成关于工作量、成本及软件项目持续时间的估算。定义开发策略及达到这一目标的必要的步骤。计划可行的项目进程安排。以及持续地跟踪项目的实施。此外，管理人员还可使用工具收集建立软件开发生产率和产品质量的那些度量数据。 支持工具支持工具可以分类为文档生成工具、网络系统软件、数据库、电子邮件、通报板，以及在开发软件时控制和管理所生成信息的配置管

33、理工具。 分析和设计工具分析和设计工具可帮助软件技术人员建立目标系统的分析模型和设计模型。这些工具还帮助人们进行模型质量的评价。它们靠对每一个模型进行执行一致性和有效性的检验，帮助软件技术人员在错误扩散到程序中之前排除之。 编程工具系统软件实用程序、编辑器、编译器及调试程序都是CASE中必不可少的部分。而除这些工具之外，还有一些新的编程工具。面向对象的程序设计工具、第四代程序生成语言。高级数据库查询系统，及一大批PC工具(如表格软件）。 组装和测试工具测试工具为软件测试提供了各种不同类型和级别的支持。有些工具，像路径覆盖分析器为测试用例设计提供了直接支持，并在测试的早期使用。其它工具，像自动回

34、归测试和测试数据生成工具，在组装和确认测试时使用，它们能帮助减少在测试过程中所需要的工作量。 原型化和模拟工具原型化和模拟工具是一个很大的工具集，它包括的范围从简单的窗口画图到实时嵌入系统时序分析与规模分析的模拟产品。原型化工具把注意力集中在建立窗口和为使用户能够了解一个信息系统或工程应用的输入输出域而提出的报告。使用模拟工具可建立嵌入式的实时应用，例如，为一架飞机建立航空控制系统的模型。在系统建立之前，可以对用模拟工具建立起来的模型进行分析，对系统的运行时间性能进行评价。 维护工具维护工具可以帮助分解一个现存的程序并帮助软件技术人员理解这个程序。软件技术人员必须利用直觉、设计观念和人的智慧来

35、完成逆向工程过程及再工程。 框架工具这些工具能够提供一个建立集成项目支撑环境（IPSE）的框架。在多数情况，框架工具实际提供了数据库管理和配置管理的能力与一些实用工具，能够把各种工具集成到IPSE中。 软件复用性及软件构件库为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件部件库。根据需要，对软件部件稍做加工，就可以构成一些大的软件包。这要求这些软件部件应加以编目，以利引用，并进行标准化和确认，以利于应用和集成。在使用这些软件部件时，有两种情况必须加以注意： 如果有现成的满足要求的软件，应当设法搞到它。因为搞到一个现成的软件所花的费用比重新开发一个同样的软件所花的费用少

36、得多。 如果对一个现存的软件或软件部件，必须修改它才能使用。这时必须多加小心，谨慎对待，因为修改时可能会引出新的问题。而修改一个现存软件所花的费用有时会大于开发一个同样软件所花的费用。 (4) 分解技术当一个待解决的问题过于复杂时，可以把它进一步分解，直到分解后的子问题变得容易解决为止。然后，分别解决每一个子问题，并将这些子问题的解答综合起来，从而得到原问题的解答。通常，这是我们解决复杂问题的最自然的一种方法。软件项目估算是一种解决问题的形式，在多数情况下，要解决的问题(对于软件项目来说，就是成本和工作量的估算)非常复杂，想一次性整体解决比较困难。因此，对问题进行分解，把其分解成一组较小的接近

37、于最终解决的可控的子问题，再定义它们的特性。 LOC和FP估算LOC和FP是两个不同的估算技术。但两者有许多共同特性。项目计划人员首先给出一个有界的软件范围的叙述，再由此叙述把软件分解成一些小的可分别独立进行估算的子功能。然后对每一个子功能估算其LOC或FP(即估算变量)。接着，把根据以往完成项目得到的(基线)生产率度量(如，LOCPM或FPPM)用做特定的估算变量，导出子功能的成本或工作量。将子功能的估算进行综合后就能得到整个项目的总估算。LOC或FP估算技术对于分解所需要的详细程度是不同的。当用LOC做为估算变量时，功能分解是绝对必要的且需要达到很详细的程度。而估算功能点所需要的数据是宏观

38、的量，当把FP当做估算变量时所需要的分解程度不很详细。应注意，LOC是直接估算的，而FP是通过估计输入、输出、数据文件、查询和外部接口的数目，以及在表9.3中描述的14种复杂性校正值间接地确定的。计划人员可对每一个分解的功能提出一个有代表性的估算值范围。利用历史数据或凭实际经验，对每个功能分别按最佳的、可能的、悲观的三种情况给出LOC或FP估计值。记作a、m、b。当这些值的范围被确定之后，也就隐含地指明了估计值的不确定程度。接着计算LOC或FP的期望值E。 E （a4mb）6 （加权平均）确定了估算变量的期望值，就可以用作LOC或FP的生产率数据。作为LOC和FP估算技术的一个实例，考察一个为

39、计算机辅助设计（CAD）应用而开发的软件包。在这个实例中，使用LOC做为估算变量。根据对软件范围的叙述，对软件功能进行分解，识别出主要的几个功能：用户界面和控制功，二维几何分析，三维几何分析，数据库管理，计算机图形显示功能，外设控制以及设计分析模块。通过下述的分解技术，可得到如表9.5所示的估算表。 表9.5 估算表功 能a最佳值m可能值b悲观值E期望值每行成本(元行)生产率(行PM)成本(元)工作量(PM)用户接口控制180024002650234014315 32760 7.4二维几何造型410052007400538020220107600 24.4三维几何造型4600690086006

40、80020220136000 30.9数据库管理295034003600335018240 60300 13.9终端图形显示405049006200495022200108900 24.7外部设备控制200021002450214028140 59920 15.2设计分析660085009800840018300151200 28.0总计33360656680 144.5表中给出了LOC的估算范围。计算出的各功能的期望值放入表中的第4列。然后对该列垂直求和，得到该CAD系统的LOC估算值33360。从历史数据求出生产率度量和每行成本，即行PM和元行。在表中的成本和工作量这两列的值分别用LOC的

41、期望值E与元行相乘，及用LOC 的期望值E与行PM相除得到。因此可得，该项目总成本的估算值为657,000元，总工作量的估算值为145人月(PM）。 工作量估算每一项目任务的解决都需要花费若干人日、人月或人年。每一个工作量单位都对应于一定的货币成本，从而可以由此做出成本估算。类似于LOC或FP技术，工作量估算开始于从软件项目范围抽出软件功能。接着给出为实现每一软件功能所必须执行的一系列软件工程任务，包括需求分析、设计、编码和测试。表9.6中的表格部分表示各个软件功能和相关的软件工程任务。计划人员针对每一软件功能，估算完成各个软件工程任务所需要的工作量(如人月)，并记在表9.6表格的中心部分。同

42、时，把劳动费用率(即单位工作量成本)加到每个软件工程任务上。最后，计算每一个功能及软件工程任务的工作量和成本。如果工作量估算不依赖LOC或FP估算，那么，就可得到两组能进行比较和调和的成本与工作量估算。如果这两组估算值合理地一致，则估算值是可靠的。如果估算的结果不一致，就有必要做进一步的检查与分析。表9.6 工作量矩阵以上面所介绍的CAD软件为例，列出它的一个完全的工作量估算表(如表9.7所示)。表中对每一个软件功能提供了用人月(PM)表示的每一项软件工程任务的工作量估算值。横向和纵向的总计给出所需要的工作量。表9.7 工作量估算表需求分析总 计测 试编 码设 计 任务功能用户接口控制 1.0

43、 2.0 0.5 3.5 7.0二维几何造型 2.0 10.0 4.5 9.5 26.0三维几何造型 2.5 12.0 6.0 11.0 31.5数据库管理 2.0 6.0 3.0 4.5 15.0图形显示功能 1.5 11.0 4.0 10.5 27.5总工作量估算外设控制功能 1.5 6.0 3.5 5.0 16.0总成本 估算设计分析功能 4.0 14.0 5.0 7.0 30.0总计 14.5 61.0 26.5 50.5 152.5费用率(元) 5200 4800 4250 4500成本(元) 75400 292800 112625 227250 708075除特别指出外，工作量都按

44、人月(PM)估算。与每个软件工程任务相关的劳动费用率记入表中费用率(元)这一行，这些数据反映了“负担”的劳动成本，即包括公司开销在内的劳动成本。如果工作量估算法与LOC估算法所得结果之间的一致性很差，就必须重新确定估算所使用的信息。如果要追寻产生差距的原因，不外乎以下两个原因之一： 计划人员没有充分了解或误解了项目的范围； 用于LOC估算的生产率数据不适合于本项目，过时了(即使用这些数据不能正确反映软件开发机构的情况)，或者是误用了。计划人员必须确定产生差距的原因再来协调估算结果。5、软件开发成本估算软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。它不同于其它物理产品的成本，它不

45、包括原材料和能源的消耗，主要是人的劳动的消耗。人的劳动消耗所需代价就是软件产品的开发成本。另一方面，软件产品开发成本的计算方法不同于其它物理产品成本的计算。软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发全过程所花费的代价作为依据的。(1) 软件开发成本估算方法对于一个大型的软件项目，要进行一系列的估算处理。主要靠分解和类推的手段进行。基本估算方法分为三类。 自顶向下的估算方法：这种方法的主要思想是从项目的整体出发，进行类推。即估算人员根据以前已完成项目所消耗

46、的总成本(或总工作量)，来推算将要开发的软件的总成本(或总工作量)，然后按比例将它分配到各开发任务单元中去。 这种方法的优点是估算工作量小，速度快。缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。 自底向上的估计法：这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。这是一种常见的估算方法。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量（配置管理、质量管理、项目管理）。所以往往估算值偏低，必须用其它方法进

47、行检验和校正。 差别估计法：这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种的方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。(2) 专家判定技术专家判定技术就是由多位专家进行成本估算。由于单独一位专家可能会有种种偏见，譬如有乐观的、悲观的、要求在竞争中取胜的、让大家都高兴的种种愿望及政治因素等。因此，最好由多位专家进行估算，取得多个估算值。Rand公司提出Deiphi技术，作为统一专家意见的方法。用Deip

48、hi技术可得到极为准确的估算值。Deiphi技术的步骤是： 组织者发给每位专家一份软件系统的规格说明书（略去名称和单位） 和一张记录估算值的表格，请他们进行估算。 专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即： ai 该软件可能的最小规模（最少源代码行数）；mi 该软件最可能的规模（最可能的源代码行数）；bi 该软件可能的最大规模（最多源代码行数）。无记名地填写表格，并说明做此估算的理由。在填表的过程中，专家互相不进行讨论但可以向组织者提问。 组织者对专家们填在表格中的答复进行整理，做以下事情：a) 计算各位专家（序号为i，i1,2,n，共n位专家）的估算期望值Ei：，并

49、综合各位专家估算值的期望中值E： b) 对专家的估算结果进行分类摘要。 在综合专家估算结果的基础上，组织专家再次无记名地填写表格。 然后比较两次估算的结果。若差异很大，则要通过查询找出差异的原因。 上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。在此过程中不得进行小组讨论。最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。此方法的缺点是人们无法利用其他参加者的估算值来调整自己的估算值。宽带Deiphi技术克服了这个缺点。在专家正式将估算值填入表格之

50、前，由组织者召集小组会议，专家们与组织者一起对估算问题进行讨论，然后专家们再无记名填表。组织者对各位专家在表中填写的估算值进行综合和分类后，再召集会议，请专家们对其估算值有很大变动之处进行讨论，请专家们重新无记名填表。这样适当重复几次，得到比较准确的估计值。由于增加了协商的机会，集思广益，使得估算值更趋于合理。(3) 软件开发成本估算的早期经验模型软件开发成本估算是依据开发成本估算模型进行估算的。开发成本估算模型通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。还没有一种估算模型能够适用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。 IBM模型1977年，IB

51、M的Walston和Felix提出了如下的估算公式：E 5.2L0.91， L是源代码行数(以KLOC计)，E是工作量(以PM计)D 4.1L0.36 14.47E0.35， D是项目持续时间(以月计)S 0.54E0.6， S是人员需要量(以人计)DOC 49L1.01。 DOC是文档数量(以页计)在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。IBM模型是一个静态单变量模型，但不是一个通用的公式。 在应用中有时要根据具体实际情况，对公式中的参数进

52、行修改。这种修改必须拥有足够的历史数据，在明确局部的环境之后才能做出。 Putnam模型这是1978年Putnam提出的模型，是一种动态多变量模型。它是假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目(总工作量达到或超过30个人年)中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。Putnam模型可以导出一个“软件方程”，把已交付的源代码(源语句)行数与工作量和开发时间联系起来。其中，td是开发持续时间(以年计)，K是软件开发与维护在内的整个生存期所花费的工作量(以人年计)，L是源代码行数(以LOC计)，Ck是技术状态常数，它反映出“妨碍程序员进展的限制”，并因开发环境而异。其典型值的选取如表9.8所示。 表9.8 技术状态常数Ck的取值 Ck的典型值 开发环境 开 发 环 境 举 例 2000 差 没有系统的开发方法，缺乏文档和复审，批处理方式。 8000 好 有合适的系统开发方法，有充分的文档和复