清华大学：软件工程概论：swguide9

第九章 软件管理 一、复习要求 1. 了解软件过程的概念、软件过程框架和软件过程模型。 2. 了解软件项目管理的过程。 3. 了解软件度量的种类，面向规模和面向功能的度量以及质量度量的种类。 4. 掌握LOC估算和FP估算的方法，分解技术和工作量估算方法。 5. 了解软件成本估算的概念，掌握COCOMO成本估算方法。 6. 了解软件成本―效益估计方法。 7. 了解风险分析的步骤，风险的种类、风险项目和风险构成。 8. 了解软件进度安排方法及图形工具。 9. 了解软件项目划分的方式，项目组织的模式，人员配备的原则和条件。 二、内容提要 1. 软件过程 (1) 软件过程的概念 软件工程是一种层次化的技术，如图9.1所示。软件工程的过程层是将结合在一起的凝聚力量，使得计算机软件能够及时、合理地被开发出来。软件过程定义了一组关键过程域(KPAs)，它们构成软件项目管理的基础，并规定了技术方法的采用、工程产品(模型、文档、数据、报告、表格等)的产生、里程碑的建立、质量的管理以及适当的变更控制。 软件过程是软件生存期中的一系列相关软件工程活动的集合。每一个软件过程又是由一组工作任务、项目里程碑、软件工程产品和交付物以及质量保证(SQA)点等组成。一个软件过程可以用图9.2的形式来表示。首先建立一个公共过程框架，其中定义了少量可适用于所有软件项目的框架活动，而不考虑它们的规模和复杂性。再给出各个框架活动的任务集合，使得框架活动能够适合于项目的特点和项目组的需求。最后是保护伞活动，如软件质量保证、软件配置管理以及测量等，它们独立于任何一个框架活动并将贯穿于整个过程。 (2) 软件过程模型 软件工程过程模型的选择基于项目和应用的特点、采用的方法和工具、要求的控制和需交付的产品。L.B.S.Raccoon使用了分级几何表示，用以讨论软件工程过程的本质。 所有的软件开发都可以看成是一个问题循环解决过程，如图9.3所示。其中包括4个截然不同的阶段：状态捕获、问题定义、技术开发和方案综合。状态捕获表示了事物的当前状态；问题定义标识了需要解决的特定问题；技术开发利用某些技术来解决问题；方案综合导出最终的结果(如文档、程序、数据、新的事务功能、新的产品)。 以上的问题循环解决过程可以用于软件工程的不同开发级别上。它可用于考虑整个应用系统的宏观级，也可用于建造程序构件的中间级，甚至还可用于源代码行级。因此，可以用分级几何表示来给出过程的理想化的视图。首先定义一个分级几何表示的模式，然后相继地在更小的规模上递归地应用分级几何表示：模式中嵌套模式。在图9.4中，问题循环解决过程的每一个阶段又包含一个同样的问题循环解决过程，该循环中每一个步骤中还可以再包含另一个问题循环解决过程。这样一直继续下去，直到某个合理的边界为止。对于软件来说，就是源代码行。 图9.4 问题循环解决过程中阶段嵌套阶段 实际上，想要如图9.4那样清楚地划分这些活动是很困难的，因为在阶段内部常常会出现一些交叉的任务，它们还可能会跨越阶段。不过，这种简化的视图表达了一个重要的思想：不管软件项目选择了什么样的过程模型，但所有阶段，包括状态捕获、问题定义、技术开发、方案综合，在某个细节级别上都同时存在。由于给出了如图9.4所示的递归的性质，上述的4阶段论不但可用于整个应用的分析，而且同样地可用于某一代码段的生成。 (3) 过程建造技术 为使得软件过程模型适合于软件项目组的使用，需要开发一些过程技术工具，以帮助软件开发组织分析它们当前的过程，组织工作任务，控制和监控进度，管理技术质量。 使用过程技术工具，可以建造一个自动模型，模型包含前面提到的公共过程框架、任务集合及保护伞活动。该模型一般表示成一个网络，对其加以分析，就能够确定典型的工作流程，考察可能导致减少开发时间、降低开发成本的可选的过程结构。 一旦创建了一个可接受的过程，就可以使用其它过程技术工具来分配、监视、甚至控制在软件过程模型中定义的所有软件工程任务。软件项目组的每一个成员都可以使用这样的工具来开发检查表，列出所有将要执行的工作任务、将要产生的工作产品和将要实施的软件质量保证活动。过程技术工具还可用于协调适合某一特定工作任务的其它CASE工具的使用。 2、软件项目管理过程 软件项目管理包括进度管理、成本管理、质量管理、人员管理、资源管理、标准化管理。管理的对象是进度、系统规模及工作量估算、经费、组织机构和人员、风险、质量、作业和环境配置等。软件项目管理所涉及的范围覆盖了整个软件生存期。 为使软件项目开发获得成功，一个关键问题是必须对软件开发项目的工作范围、可能遇到的风险、需要的资源(人、硬／软件)、要实现的任务、经历的里程碑、花费工作量(成本)，以及进度的安排等等做到心中有数。而软件项目管理可以提供这些信息。通常，这种管理在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，并且只有当软件开发工作最后结束时才终止。 (1) 启动一个软件项目 在制定软件项目计划之前，必须先明确项目的目标和范围、考虑候选的解决方案、标明技术和管理上的要求。有了这些信息，才能确定合理、精确的成本估算，实际可行的任务分解以及可管理的进度安排。 项目的目标标明了软件项目的目的但不涉及如何去达到这些目的。范围标明了软件要实现的基本功能，并尽量以定量的方式界定这些功能。候选的解决方案虽然涉及方案细节不多，但有了方案，管理人员和技术人员就能够据此选择一种“好的”方法，给出诸如交付期限、预算、个人能力、技术界面及其它许多因素所构成的限制。 (2) 制定项目计划 制定计划的任务包括： ( 估算所需要的人力（通常以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）。 ( 作出进度安排，分配资源，建立项目组织及任用人员(包括人员的地位、作用、职责、规章制度等)，根据规模和工作量估算分配任务。 ( 进行风险分析，包括风险识别、风险估计、风险优化、风险驾驭策略、风险解决和风险监督。这些步骤贯穿在软件工程过程中。 ( 制定质量管理指标：如何识别定义好的任务？管理人员对结束时间如何掌握，并如何识别和监控关键路径以确保结束？对进展如何度量？以及如何建立分隔任务的里程碑。 ( 编制预算和成本。 ( 准备环境和基础设施等。 (3) 计划的追踪和控制 一旦建立了进度安排，就可以开始着手追踪和控制活动。由项目管理人员负责在过程执行时监督过程的实施，提供过程进展的内部报告，并按合同规定向需方提供外部报告。对于在进度安排中标明的每一个任务，如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。可对资源重新定向，对任务重新安排，或者(做为最坏的结果)可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制软件的开发。 (4) 评审和评价计划的完成程度 项目管理人员应对计划完成程度进行评审，对项目进行评价。并对计划和项目进行检查, 使之在变更或完成后保持完整性和一致性。 (5) 编写管理文档 项目管理人员根据合同确定软件开发过程是否完成。如果完成，应从完整性方面检查项目完成的结果和记录，并把这些结果和记录编写成文档并存档。 3、软件生产率和质量的度量 (1) 软件度量 对软件进行度量，是为了表明软件产品的质量，弄清软件开发人员的生产率，给出使用了新的软件工程方法和工具所得到的(在生产率和质量两方面)的效益，建立项目估算的“基线"，帮助调整对新的工具和附加培训的要求。 软件度量分为两类： ( 直接度量：软件工程过程的直接度量包括所投入的成本和工作量。软件产品的直接度量包括产生的代码行数(LOC)、执行速度、存储量大小、在某种时间周期中所报告的差错数。 ( 间接度量：产品的间接度量则包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性。 只要事先建立特定的度量规程，很容易做到直接度量开发软件所需要的成本和工作量、产生的代码行数等。但是，软件的功能性、效率、可维护性等质量特性却很难用直接度量判明，只有通过间接度量才能推断。 我们可进一步将软件度量如图9.5 所示那样分类。软件生产率度量主要关注软件工程过程的结果；软件质量度量则指明了软件适应明确和不明确的用户要求(软件使用合理性)到什么程度；技术度量主要关注软件的一些特性(如逻辑复杂性、模块化程度)而不是软件开发的全过程。 从图9.5中还可以看到另一种分类方法：面向规模的度量用于收集与直接度量有关的软件工程输出的信息和质量信息。面向功能的度量提供直接度量的尺度。面向人的度量则收集有关人们开发软件所用方式的信息和人们理解有关工具和方法的效率的信息。 (2) 面向规模的度量 面向规模的度量是对软件和软件开发过程的直接度量。首先需要建立一个如表9.1所示的面向规模的数据表格，记录过去几年完成的每一个软件项目和关于这些项目的相应面向规模的数据。 表9.1 面向规模的度量 项目 工作量(人月) 元(千) 规模(KLOC) 文档页数 错误数 开发人数  aaa-01 24 168 12.1 365 29 3  ccc-04 62 440 27.2 1224 86 5  fff-03 43 314 17.5 1050 64 6  … … … … … … …   对于每一个项目，可以根据表格中列出的基本数据进行一些简单的面向规模的生产率和质量的度量。例如，可以根据表9.1对所有的项目计算出平均值： 生产率 ＝ KLOC／PM（人月） 成本 ＝ 元／LOC  质量 ＝ 错误数／KLOC 文档 ＝ 文档页数／KLOC  (3) 面向功能的度量 面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量的关注点在于程序的“功能性”和“实用性”，而不是对LOC计数。一种典型的生产率度量法叫做功能点度量，该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能点FPs（Function Points）。 功能点通过填写表9.2所示的表格来计算。首先确定五个信息域的特征，并在表格中相应位置给出计数。信息域的值以如下方式定义： ( 用户输入数：各个用户输入是面向不同应用的输入数据，对它们都要进行计数。输入数据应有别于查询数据，它们应分别计数。 ( 用户输出数：各个用户输出是为用户提供的面向应用的输出信息，它们均应计数。这里的输出是指报告，屏幕信息，错误信息等，在报告中的各数据项不应再分别计数。 ( 用户查询数：查询是一种联机输入，它导致软件以联机输出的方式生成某种即时的响应。每一个不同的查询都要计数。 ( 文件数：每一个逻辑主文件都应计数。这里的逻辑主文件，是指逻辑上的一组数据，它们可以是一个大的数据库的一部分，也可以是一个单独的文件 ( 外部接口数：对所有被用来将信息传送到另一个系统中的机器可读写的接口(即磁带或磁盘上的数据文件)均应计数。 表9.2 功能点度量的计算   加 权 因 数        简单  中间  复杂    用户输入数 □□□ ( 3 4 6 = □□□  用户输出数 □□□ ( 4 5 7 = □□□  用户查询数 □□□ ( 3 4 6 = □□□  文 件 数 □□□ ( 7 10 15 = □□□  外部接口数 □□□ ( 5 7 10 = □□□  总 计 数       □□□   一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值。使用功能点方法的机构要自行拟定一些准则以确定一个特定项是简单的、平均的还是复杂的。 计算功能点，使用如下的关系式： FP ＝ 总计数×〔0.65＋0.01×SUM（Fi）〕 （9.1） 其中，总计数是由表9.2所得到的所有加权计数项的和；Fi（i = 1到14）是复杂性校正值，它们应通过逐一回答表9.3所提问题来确定。SUM（Fi）是求和函数。上述等式中的常数和应用于信息域计数的加权因数可经验地确定。 一旦计算出功能点，就可以仿照LOC的方式度量软件的生产率、质量和其它属性： 生产率 ＝ FP／PM（人月） 成本 ＝ 元／FP  质量 ＝ 错误数／FP 文档 ＝ 文档页数／FP   表9.3 计算功能点的校正值 评定每个校正因素的尺度是0―5    0 1 2 3 4 5       没有影响 偶然的 适中的 普通的 重要的 极重要的  Fi   1 系统是否需要可靠的备份和恢复？  2 是否需要数据通信？  3 是否有分布式处理的功能？  4 性能是否是关键？  5 系统是否将运行在现有的高度实用化的操作环境中？  6 系统是否要求联机数据项？  7 联机数据项是否要求建立在多重窗口显示或操作上的输入事务？  8 是否联机地更新主文件？  9 输入、输出、文件、查询是否复杂？  10 内部处理过程是否复杂？  11 程序代码是否要设计成可复用的？  12 设计中是否包含变换和安装？  13 系统是否要设计成多种安装形式以安装在不同的机构中？  14 应用系统是否要设计成便于修改和易于用户使用？   功能点度量是为了商用信息系统应用而设计的。Jones将其扩充，使这种度量可以被用于系统和工程软件应用，称之为特征点FPs（Feature Points）。特征点度量适合于算法复杂性高的应用。实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，适于特征点度量。 为了计算特征点，可以象上面描述的那样，对信息域值进行计数和加权。此外，需要对一个新的软件特征“算法”进行计数。可定义算法为“在一个特定计算机程序内所包含的一个有界的计算问题。”如矩阵求逆、二进位串转换为十进制数、处理一个中断等都是算法。计算特征点可使用如表9.4所示的表格。 对于每一个度量参数只使用一个权值，并且使用等式（9.1）来计算总的特征点值。 表9.4 特征点度量的计算 信息域参数 计数   权值  加权计数  用户输入数 □□□ ( 4 = □□□  用户输出数 □□□ ( 5 = □□□  用户查询数 □□□ ( 4 = □□□  文 件 数 □□□ ( 7 = □□□  外部接口数 □□□ ( 7 = □□□  算 法 □□□ ( 3 = □□□  总 计 数     □□□   必须注意，特征点与功能点表示的是同一件事：由软件提供的“功能性”或“实用性”。事实上，对于传统的工程计算或信息系统应用，两种度量会得出相同的FP值。在较复杂的实时系统中，特征点计数常常比只用功能点确定的计数高出20％到35％。 (4) 软件质量的度量 质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。在软件交付之前得到的度量提供了一个定量的根据，以做出设计和测试质量好坏的判断。这一类度量包括程序复杂性、有效的模块性和总的程序规模。在软件交付之后的度量则把注意力集中于还未发现的差错数和系统的可维护性方面。特别要强调的是，软件质量的售后度量可向管理者和技术人员表明软件工程过程的有效性达到什么程度。 虽然已经有许多软件质量的度量方法，但事后度量使用得最广泛。它包括正确性、可维护性、完整性和可使用性。Gilb提出了它们的定义和度量。 ① 正确性：一个程序必须正确地运行，而且还要为它的用户提供某些输出。正确性要求软件执行所要求的功能。对于正确性，最一般的度量是每千代码行(KLOC)的差错数，其中将差错定义为已被证实是不符合需求的缺陷。差错在程序交付用户普遍使用后由程序的用户报告，按标准的时间周期(典型情况是1年)进行计数。 ② 可维护性：包括当程序中发现错误时，要能够很容易地修正它；当程序的环境发生变化时，要能够很容易地适应之；当用户希望变更需求时，要能够很容易地增强它。还没有一种方法可以直接度量可维护性，因此必须采取间接度量。有一种简单的面向时间的度量，叫做平均变更等待时间MTTC（Mean Time To Change)。 这个时间包括开始分析变更要求、设计合适的修改、实现变更并测试它、以及把这种变更发送给所有的用户。一般地，一个可维护的程序与那些不可维护的程序相比，应有较低的MTTC（对于相同类型的变更)。 ③ 完整性：这个属性度量一个系统抗拒对它的安全性攻击(事故的和人为的)的能力。软件的所有三个成分：程序、数据和文档都会遭到攻击。 为了度量完整性，需要定义两个附加的属性：危险性和安全性。危险性是特定类型的攻击将在一给定时间内发生的概率，它可以被估计或从经验数据中导出。安全性是排除特定类型攻击的概率，它也可以被估计或从经验数据中导出。一个系统的完整性可定义为： 完整性 ＝ ∑（1－危险性×（1－安全性）） 其中，对每一个攻击的危险性和安全性都进行累加。 ④ 可使用性：即用户友好性。如果一个程序不具有“用户友好性”，即使它所执行的功能很有价值，也常常会失败。可使用性力图量化“用户友好性”，并依据以下四个特征进行度量： ( 为学习系统所需要的体力上的和智力上的技能； ( 为达到适度有效使用系统所需要的时间； ( 当软件被某些人适度有效地使用时所度量的在生产率方面的净增值； ( 用户角度对系统的主观评价(可以通过问题调查表得到)。 4、软件项目的估算 在做软件估算时往往存在某些不确定性，这将使得软件项目管理人员无法正常进行管理。因为估算是所有其它项目计划活动的基石，且项目计划又为软件工程过程提供了工作方向，所以我们不能没有计划就开始着手开发，否则将会陷入盲目性。 (1) 估算 估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。估算本身带有风险。增加风险的各种因素如图9.6所示。图中的轴线表示被估算项目的特征。
图9.6 估算与风险 项目的复杂性对于增加软件估算的不确定性影响很大。复杂性越高，估算的风险就越高。但是，复杂性是相对度量，它与项目参加人员的经验有关。例如，一个实时系统的开发，对于过去仅做过批处理应用项目的软件开发组来说是非常复杂的，但对于一个过去开发过许多高速过程控制软件的软件小组来说可能就是很容易的了。此外，这种度量一般用在设计或编码级，而在软件计划时(设计和代码存在之前)使用就很困难。因此，可以在计划过程的早期建立其它较为主观的复杂性评估，如功能点复杂性校正因素。 项目的规模对于软件估算的精确性和功效影响也比较大。因为随着软件规模的扩大，软件元素之间的相互依赖、相互影响程度迅速增加，因而估算的一个重要方法──问题分解会变得更加困难。由此可知，项目的规模越大，开发工作量越大，估算的风险越高。 项目的结构化程度也影响项目估算的风险。所谓结构性是指功能分解的简便性和处理信息的层次性。结构化程度的提高，进行精确估算的能力就能提高，而风险将减少。 历史信息的有效性也影响估算的风险。回顾过去，就能够仿效做过的事，且改进出现问题的地方。在对过去的项目进行综合的软件度量之后，就可以借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。 风险靠对不确定性程度定量地进行估算来度量，此外，如果对软件项目的作用范围还不十分清楚，或者用户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频频变动，增加估算的风险。计划人员应当要求在软件系统的规格说明中给出完备的功能、性能、接口的定义。更重要的是，计划人员和用户都应认识到经常改变软件需求意味着在成本和进度上的不稳定性。 (2) 软件的范围 软件项目计划第一项活动就是确定软件的范围。应当从管理角度和技术角度出发，确定明确的和可理解的项目范围，明确地给出定量的数据(如同时使用该软件的用户数目，发送表格的长短，最大允许响应时间等)，指明约束条件和限制(如存储容量)。此外还要叙述某些质量因素(如给出的算法是否容易理解、是否使用高级语言等)。 软件范围包括功能、性能、限制、接口和可靠性。在估算开始之前，应对软件的功能进行评价，并对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常常采用某种程度的功能分解。性能的考虑包括处理和响应时间的需求。约束条件则标识外部硬件、可用存储或其它现有系统对软件的限制。 功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发工作量可能相差一个数量级。功能、性能和约束是密切联系在一起的。 软件与其它系统元素是相互作用的。计划人员要考虑每个接口的性质和复杂性，以确定对开发资源、成本和进度的影响。接口的概念可解释为： ( 运行软件的硬件(如处理机与外设)及间接受软件控制的设备(如机器、显示器)； ( 必须与新软件链接的现有的软件(如数据库存取例程、子程序包、操作系统)； ( 通过终端或其它输入／输出设备使用该软件的人； ( 该软件运行前后的一系列操作过程。 对于每一种情况，都必须清楚地了解通过接口的信息转换。 软件范围最不明确的方面就是可靠性的讨论。软件可靠性的度量已经存在，但它们在项目的这个阶段难得用上。因此，可以按照软件的一般性质规定一些具体的要求以保证它的可靠性。 (3) 软件开发中的资源 软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。图9.7把软件开发所需的资源画成一个金字塔，在塔的底部有现成的用以支持软件开发的工具──硬件及软件工具，在塔的高层是最基本的资源──人。通常，对每一种资源，应说明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、b。当这些值的范围被确定之后，也就隐含地指明了估计值的不确定程度。接着计算LOC或FP的期望值E。 E ＝ （a＋4m＋b）／6 （加权平均） 确定了估算变量的期望值，就可以用作LOC或FP的生产率数据。 作为LOC和FP估算技术的一个实例，考察一个为计算机辅助设计（CAD）应用而开发的软件包。在这个实例中，使用LOC做为估算变量。 根据对软件范围的叙述，对软件功能进行分解，识别出主要的几个功能：用户界面和控制功，二维几何分析，三维几何分析，数据库管理，计算机图形显示功能，外设控制以及设计分析模块。通过下述的分解技术，可得到如表9.5所示的估算表。 表9.5 估算表 a 最佳值 m 可能值 b 悲观值 E 期望值 每行成本 (元∕行) 生产率 (行∕PM) 成本 (元) 工作量 (PM)  用户接口控制 1800 2400 2650 2340 14 315  32760  7.4  二维几何造型 4100 5200 7400 5380 20 220 107600  24.4  三维几何造型 4600 6900 8600 6800 20 220 136000  30.9  数据库管理 2950 3400 3600 3350 18 240  60300  13.9  终端图形显示 4050 4900 6200 4950 22 200 108900  24.7  外部设备控制 2000 2100 2450 2140 28 140  59920  15.2  设计分析 6600 8500 9800 8400 18 300 151200  28.0  总计    33360   656680  144.5   表中给出了LOC的估算范围。计算出的各功能的期望值放入表中的第4列。然后对该列垂直求和，得到该CAD系统的LOC估算值33360。 从历史数据求出生产率度量和每行成本，即行／PM和元／行。在表中的成本和工作量这两列的值分别用LOC的期望值E与元／行相乘，及用LOC 的期望值E与行／PM相除得到。因此可得，该项目总成本的估算值为657,000元，总工作量的估算值为145人月(PM）。 ② 工作量估算 每一项目任务的解决都需要花费若干人日、人月或人年。每一个工作量单位都对应于一定的货币成本，从而可以由此做出成本估算。 类似于LOC或FP技术，工作量估算开始于从软件项目范围抽出软件功能。接着给出为实现每一软件功能所必须执行的一系列软件工程任务，包括需求分析、设计、编码和测试。表9.6中的表格部分表示各个软件功能和相关的软件工程任务。 计划人员针对每一软件功能，估算完成各个软件工程任务所需要的工作量(如人月)，并记在表9.6表格的中心部分。同时，把劳动费用率(即单位工作量成本)加到每个软件工程任务上。最后，计算每一个功能及软件工程任务的工作量和成本。如果工作量估算不依赖LOC或FP估算，那么，就可得到两组能进行比较和调和的成本与工作量估算。如果这两组估算值合理地一致，则估算值是可靠的。如果估算的结果不一致，就有必要做进一步的检查与分析。 以上面所介绍的CAD软件为例，列出它的一个完全的工作量估算表(如表9.7所示)。表中对每一个软件功能提供了用人月(PM)表示的每一项软件工程任务的工作量估算值。横向和纵向的总计给出所需要的工作量。 表9.7 工作量估算表 任务 功能       用户接口控制  1.0  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  除特别指出外，工作量都按人月(PM)估算。   与每个软件工程任务相关的劳动费用率记入表中费用率(元)这一行，这些数据反映了“负担”的劳动成本，即包括公司开销在内的劳动成本。 如果工作量估算法与LOC估算法所得结果之间的一致性很差，就必须重新确定估算所使用的信息。如果要追寻产生差距的原因，不外乎以下两个原因之一： ( 计划人员没有充分了解或误解了项目的范围； ( 用于LOC估算的生产率数据不适合于本项目，过时了(即使用这些数据不能正确反映软件开发机构的情况)，或者是误用了。 计划人员必须确定产生差距的原因再来协调估算结果。 5、软件开发成本估算 软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。它不同于其它物理产品的成本，它不包括原材料和能源的消耗，主要是人的劳动的消耗。人的劳动消耗所需代价就是软件产品的开发成本。另一方面，软件产品开发成本的计算方法不同于其它物理产品成本的计算。软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发全过程所花费的代价作为依据的。 (1) 软件开发成本估算方法 对于一个大型的软件项目，要进行一系列的估算处理。主要靠分解和类推的手段进行。基本估算方法分为三类。 ① 自顶向下的估算方法： 这种方法的主要思想是从项目的整体出发，进行类推。即估算人员根据以前已完成项目所消耗的总成本(或总工作量)，来推算将要开发的软件的总成本(或总工作量)，然后按比例将它分配到各开发任务单元中去。 这种方法的优点是估算工作量小，速度快。缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。 ② 自底向上的估计法：这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。这是一种常见的估算方法。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量（配置管理、质量管理、项目管理）。所以往往估算值偏低，必须用其它方法进行检验和校正。 ③ 差别估计法：这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种的方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。 (2) 专家判定技术 专家判定技术就是由多位专家进行成本估算。由于单独一位专家可能会有种种偏见，譬如有乐观的、悲观的、要求在竞争中取胜的、让大家都高兴的种种愿望及政治因素等。因此，最好由多位专家进行估算，取得多个估算值。Rand公司提出Deiphi技术，作为统一专家意见的方法。用Deiphi技术可得到极为准确的估算值。 Deiphi技术的步骤是： ① 组织者发给每位专家一份软件系统的规格说明书（略去名称和单位） 和一张记录估算值的表格，请他们进行估算。 ② 专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即： ai ── 该软件可能的最小规模（最少源代码行数）； mi ── 该软件最可能的规模（最可能的源代码行数）； bi ── 该软件可能的最大规模（最多源代码行数）。无记名地填写表格，并说明做此估算的理由。在填表的过程中，专家互相不进行讨论但可以向组织者提问。 ③ 组织者对专家们填在表格中的答复进行整理，做以下事情： a) 计算各位专家（序号为i，i＝1,2,…,n，共n位专家）的估算期望值Ei：，并综合各位专家估算值的期望中值E：

b) 对专家的估算结果进行分类摘要。 ④ 在综合专家估算结果的基础上，组织专家再次无记名地填写表格。 然后比较两次估算的结果。若差异很大，则要通过查询找出差异的原因。 ⑤ 上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。在此过程中不得进行小组讨论。 最后，通过与历史资料进行类比，根据过去完成软件项目的规模和成本等信息，推算出该软件每行源代码所需要的成本。然后再乘以该软件源代码行数的估算值，就可得到该软件的成本估算值。 此方法的缺点是人们无法利用其他参加者的估算值来调整自己的估算值。宽带Deiphi技术克服了这个缺点。在专家正式将估算值填入表格之前，由组织者召集小组会议，专家们与组织者一起对估算问题进行讨论，然后专家们再无记名填表。组织者对各位专家在表中填写的估算值进行综合和分类后，再召集会议，请专家们对其估算值有很大变动之处进行讨论，请专家们重新无记名填表。这样适当重复几次，得到比较准确的估计值。 由于增加了协商的机会，集思广益，使得估算值更趋于合理。 (3) 软件开发成本估算的早期经验模型 软件开发成本估算是依据开发成本估算模型进行估算的。开发成本估算模型通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。还没有一种估算模型能够适用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。 ① IBM模型 1977年，IBM的Walston和Felix提出了如下的估算公式： E ＝ 5.2×L0.91， L是源代码行数(以KLOC计)，E是工作量(以PM计) D ＝ 4.1×L0.36 ＝ 14.47×E0.35， D是项目持续时间(以月计) S ＝ 0.54×E0.6， S是人员需要量(以人计) DOC ＝ 49×L1.01。 DOC是文档数量(以页计) 在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。 IBM模型是一个静态单变量模型，但不是一个通用的公式。 在应用中有时要根据具体实际情况，对公式中的参数进行修改。这种修改必须拥有足够的历史数据，在明确局部的环境之后才能做出。 ② Putnam模型 这是1978年Putnam提出的模型，是一种动态多变量模型。它是假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目(总工作量达到或超过30个人年)中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。 Putnam模型可以导出一个“软件方程”，把已交付的源代码(源语句)行数与工作量和开发时间联系起来。其中，td是开发持续时间(以年计)，K是软件开发与维护在内的整个生存期所花费的工作量(以人年计)，L是源代码行数(以LOC计)，Ck是技术状态常数，它反映出“妨碍程序员进展的限制”，并因开发环境而异。其典型值的选取如表9.8所示。
表9.8 技术状态常数Ck的取值 Ck的典型值  开发环境  开 发 环 境 举 例   2000  差  没有系统的开发方法，缺乏文档和复审，批处理方式。   8000  好  有合适的系统开发方法，有充分的文档和复审，交互执行方式。   11000  优  有自动开发工具和技术。   (4) COCOMO模型（COnstructive COst MOdel） 这是由TRW公司开发。Boehm提出的结构型成本估算模型。是一种精确、易于使用的成本估算方法。在该模型中使用的基本量有以下几个：DSI（源指令条数）定义为代码或卡片形式的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。KDSI＝1000DSI。MM（度量单位为人月）表示开发工作量。TDEV（度量单位为月）表示开发进度。它由工作量决定。 ① 软件开发项目的分类 在COCOMO模型中，考虑开发环境，软件开发项目的总体类型可分为三种：组织型(Organic)、嵌入型(Embadded)和介于上述两种软件之间的半独立型(Semidetached)。 ② COCOMO模型的分类 COCOMO模型按其详细程度分成三级：即基本COCOMO模型、中间COCOMO模型、详细COCOMO模型。基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的源代码行数(LOC)为自变量的(经验)函数来计算软件开发工作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量(此时称为名义工作量)的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤(分析、设计等)的影响。 ③ 基本COCOMO模型 基本COCOMO模型的工作量和进度公式如表9.9所示。 表9.9 基本COCOMO模型的工作量和进度公式 总体类型 工 作 量 进 度  组 织 型  MM ＝2.4 (KDSI)1.05 TDEV＝2.5 (MM)0.38  半独立型  MM ＝3.0 (KDSI)1.12 TDEV＝2.5 (MM)0.35  嵌 入 型  MM ＝3.6 (KDSI)1.20 TDEV＝2.5 (MM)0.32   利用上面公式，可求得软件项目，或分阶段求得各软件任务的开发工作量和开发进度。 ④ 中间COCOMO模型 进一步考虑以下15种影响软件工作量的因素，通过定下乘法因子，修正COCOMO工作量公式和进度公式，可以更合理地估算软件(各阶段)的工作量和进度。 中间COCOMO模型的名义工作量与进度公式如表9.10所示。 表9.10 中间COCOMO模型的名义工作量与进度公式 总体类型 工 作 量 进 度  组 织 型  MM＝3.2 (KDSI)1.05 TDEV＝2.5 (MM)0.38  半独立型  MM＝3.0 (KDSI)1.12 TDEV＝2.5 (MM)0.35  嵌 入 型  MM＝2.8 (KDSI)1.20 TDEV＝2.5 (MM)0.32   对15种影响软件工作量的因素fi按等级打分，如表9.11所列。此时，工作量计算公式改成：
表9.11 15种影响软件工作量的因素fi的等级分 工作量因素fi 非常低 低 正常 高 非常高 超高   产品因素 软件可靠性 0.75 0.88 1.00 1.15 1.40    数据库规模  0.94 1.00 1.08 1.16    产品复杂性 0.70 0.85 1.00 1.15 1.30 1.65   计算机 因素 执行时间限制   1.00 1.11 1.30 1.66   存储限制   1.00 1.06 1.21 1.56   虚拟机易变性  0.87 1.00 1.15 1.30    环境周转时间  0.87 1.00 1.07 1.15    人的因素 分析员能力  1.46 1.00 0.86 0.71    应用论域实际经验 1.29 1.13 1.00 0.91 0.82    程序员能力 1.42 1.17 1.00 0.86 0.70    虚拟机使用经验 1.21 1.10 1.00 0.90     程序语言使用经验 1.41 1.07 1.00 0.95     项目因素 现代程序设计技术 1.24 1.10 1.00 0.91 0.82    软件工具的使用 1.24 1.10 1.00 0.91 0.83    开发进度限制 1.23 1.08 1.00 1.04 1.10   这里所谓的虚拟机是指为完成某一个软件任务所使用的硬、软件的结合。 ⑤ 详细COCOMO模型 详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO模型相同。但分层、分阶段给出工作量因素分级表(类似于上表）。针对每一个影响因素，按模块层、子系统层、系统层，有三张不同的工作量因素分级表，供不同层次的估算使用。每一张表中工作量因素又按开发各个不同阶段给出。 例如，关于软件可靠性(RELY)要求的工作量因素分级表(子系统层)，如表9.12所示。使用这些表格，可以比中间COCOMO模型更方便、更准确地估算软件开发工作量。 表9.12 软件可靠性工作量因素分级表（子系统层） 阶段 RELY级别       非常低 0.80 0.80 0.80 0.60 0.75  低 0.90 0.90 0.90 0.80 0.88  正常 1.00 1.00 1.00 1.00 1.00  高 1.10 1.10 1.10 1.30 1.15  非常高 1.30 1.30 1.30 1.70 1.40   6、成本－效益分析 成本－效益分析的目的，是从经济角度评价开发一个新的软件项目是否可行。 成本－效益分析首先是估算新软件系统的开发成本，然后与可能取得的效益(有形的和无形的)进行比较权衡。有形的效益可以用货币的时间价值、投资回收期、纯收入、投资回收率等指标进行度量。无形的效益主要是从性质上、心理上进行衡量，很难直接进行量上的比较。无形的效益在某些情形下会转化成有形的效益。例如，一个高质量的设计先进的软件可以使用户更满意，从而影响到其他潜在的用户也会喜欢它，一旦需要时就会选择购买它，这样使得无形的效益转化成有形的效益。 系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用。运行费用包括操作员人数、工作时间、消耗的物资等。 (1) 几种度量效益的方法 ① 货币的时间价值 成本估算的目的是要求对项目投资。但投资在前，取得效益在后。因此要考虑货币的时间价值。通常用利率表示货币的时间价值。设年利率为i，现已存入P元，则n年后可得钱数为：F = ( 1 + i ) n，这就是P元钱在n年后的价值。 反之，若n年后能收入F元，那么这些钱现在的价值是：
例如，在工程设计中用CAD系统来取代大部分人工设计工作，每年可节省9.6万元。若软件生存期为5年，则5年可节省48万元。开发这个CAD系统共投资了20万元。我们不能简单地把20万元与48万元相比较。因为前者是现在投资的钱，而后者是5年以后节省的钱。需要把5年内每年预计节省的钱折合成现在的价值才能进行比较。 设年利率是5％，利用上面计算货币现在价值的公式，可以算出引入CAD系统后，每年预计节省的钱的现在价值，参看表9.13 表9.13 货币的时间价值 年 份 将来值 (万) (1+i )n 现在值(万) 累计的现在值(万)  1 9.6 1.05 9.1429 9.1429  2 9.6 1.1025 8.7075 17.8513  3 9.6 1.1576 8.2928 26.1432  4 9.6 1.2155 7.8979 34.0411  5 9.6 1.2763 7.5219 41.5630   ② 投资回收期 投资回收期是衡量一个开发工程价值的经济指标。所谓投资回收期就是使累计的经济效益等于最初的投资所需的时间。投资回收期越短，就能越快获得利润。因此这项工程就越值得投资。例如，引入CAD系统两年后可以节省17.85万元，比最初的投资还少2.15万元，但第三年可以节省8.29万元，则 2.15∕8.29 = 0.259。因此，投资回收期是2.259年。 ③ 纯收入 工程的纯收入是衡量工程价值的另一项经济指标。所谓纯收入就是在整个生存期之内系统的累计经济效益(折合成现在值)与投资之差。例如，引入CAD系统之后，5年内工程的纯收入预计是 41.563－20＝21.563（万元）。这相当于比较投资一个待开发的软件项目后预期可取得的效益和把钱存在银行里(或贷款给其它企业)所取得的收益，到底孰优孰劣。如果纯收入为零，则工程的预期效益与在银行存款一样。但开发一个软件项目有风险，从经济观点看，这项工程可能是不值得投资的。如果纯收入小于零，那么显然这项工程不值得投资。只有当纯收入大于零，才能考虑投资。 ④ 投资回收率 把钱存在银行里，可以用年利率来衡量利息的多少。类似地，用投资回收率来衡量投资效益的大小。已知现在的投资额P，并且已经估算出将来每年可以获得的经济效益Fk，以及软件的使用寿命n，k=1,2,...,n。则投资回收率j，可用如下的方程来计算：
这相当于把数额等于投资额的资金存入银行，每年年底从银行取回的钱等于系统每年预期可以获得的效益。在时间等于系统寿命时，正好把在银行中的钱全部取光。此时的年利率是多少呢? 就等于投资回收率。 (2) 成本－效益的分析 系统的效益分析随系统的特性而异。大多数数据处理系统的基本目标是开发具有较大信息容量、更高的质量、更及时、组织得更好的系统。因此，效益集中在信息存取和它对用户环境的影响上面。与工程－科学计算软件及基于微处理器的产品相关的效益在本质上可能不大相同。 新系统的效益与系统的工作方式有关。仍以前面所说的代替人工设计过程的计算机辅助设计(CAD)系统为例。分析员对现行系统(人工设计)和待开发系统(CAD)定义可度量的特性，选定产生最终详细图纸的时间t-draw作为一个可度量的特性。且分析员发现，CAD系统产生的缩减比为1／4。为进一步量化这种效益，应确定以下数据：t-draw：平均绘图时间 ＝ 4 小时；c：每绘图－小时的成本 ＝ 20.00 元；n：每年绘图的数量 ＝ 8000；p：CAD系统中已完成绘图的百分比 ＝ 60％；利用以上已知数据，每年节省费用的估算值，即所得到的效益为： 节省的绘图费用 ＝ 缩减比 * t-draw * n * c * p ＝ 96000 元／年。 其它由CAD系统而得到的有形效益将以类似的方式进行处理。而无形的效益(如较好的设计质量、较高的雇员素质)可以被赋予货币价值。 软件系统开发的成本如表9.14所列。 表9.14 信息系统可能的费用 筹办费用  咨询费  实际设备购置或租用设备费    设备安装费  设备场所改建费(空调、安全设施等)    资本  与筹办相关的管理和人员的费用   开办费用  操作系统软件的费用  通信设备安装费用(电话线、数据线等)    开办人员的费用  人员寻找与聘用活动所需的费用    破坏其它机构所需的费用  指导开办活动所需的管理费用   与项目 有关的 费用  应用软件购置费  为适应局域系统修改软件的费用    公司内应用系统开发所需的人员工 资、经常性开销等  数据收集和建立数据收集过程所需的费用    准备文档所需的费用  培训用户人员使用应用系统的费用    开发管理费    运行费用  系统维护费用(硬件、软件和设备)  租借费用(电费、电话费等)    硬件折旧费  信息系统管理、操作及计划活动中涉及人 员的费用   分析员可以估算每一项的成本，然后用开发费用和运行费用来确定投资的偿还、损益两平点和投资回收期。图9.9说明了前面所介绍的CAD系统实例的特性。假设每年可节约总费用的估计值为96000元，总开发（或购买）费用为204000元，年度费用估计为32000元。则从图9.0可知，投资回收期大约需要3.1年。实际上，投资的偿还可以用更详细的分析方法来确定，即货币的时间价值、税收的影响及其它潜在的对投资的使用。再把无形的效益考虑在内，上级管理部门就可以决策，在经济上是否值得开发这个系统。
图9.9 成本—效益分析 7、风险分析 风险分析实际上是4个不同的活动： 风险识别，风险估计，风险评价和风险驾驭。 (1) 风险识别 风险识别就是要系统地确定对项目计划(估算、进度、资源分配)的威胁，通过识别已知的或可预测的风险，就可能设法避开风险或驾驭风险。 ① 风险类型 用各种不同的方法对风险进行分类是可能的。从宏观上来看，可将风险分为项目风险、技术风险和商业风险。 项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。项目风险是指潜在的预算、进度、个人(包括人员和组织)、资源、用户和需求方面的问题，以及它们对软件项目的影响。项目复杂性、规模和结构的不确定性也构成项目的(估算)风险因素。 技术风险威胁到待开发软件的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。技术风险是指潜在的设计、实现、接口、检验和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。技术风险之所以出现是由于问题的解决比我们预想的要复杂。 商业风险威胁到待开发软件的生存能力。5种主要的商业风险是： ( 建立的软件虽然很优秀但不是市场真正所想要的（市场风险）； ( 建立的软件不再符合公司的整个软件产品战略（策略风险）； ( 建立了销售部门不清楚如何推销的软件； ( 由于重点转移或人员变动而失去上级管理部门的支持（管理风险）； ( 没有得到预算或人员的保证（预算风险）。 特别要注意，有时对某些风险不能简单地归类，而且某些风险事先是无法预测的。 ② 风险项目检查表 识别风险的一种最好的方法就是利用一组提问来帮助项目计划人员了解在项目和技术方面有哪些风险。因此，Boehm建议使用一个“风险项目检查表”，列出所有可能的与每一个风险因素有关的提问。从如下几个方面识别已知的或可预测的风险。 ( 产品规模——与待开发或要修改的软件的产品规模(估算偏差、产品用户、需求变更、复用软件、数据库)相关的风险。 ( 商业影响——与管理和市场所加之的约束(公司收益、上级重视、符合需求、用户水平、产品文档、政府约束、成本损耗、交付期限)有关的风险。 ( 客户特性——与客户的素质(技术素养、合作态度、需求理解)以及开发者与客户定期通信(技术评审、通信渠道)能力有关的风险。 ( 过程定义——与软件过程定义与组织程度以及开发组织遵循的程度相关的风险。 ( 开发环境——与用来建造产品的工具(项目管理、过程管理、分析与设计、编译器及代码生成器、测试与调试、配置管理、工具集成、工具培训、联机帮助与文档)的可用性和质量相关的风险。 ( 建造技术——与待开发软件的复杂性及系统所包含技术的“新颖性”相关的风险。 ( 人员数量及经验——与参与工作的软件技术人员的总体技术水平(优秀程度、专业配套、数量足够、时间窗口)及项目经验(业务培训、工作基础)相关的风险。 ③ 全面评估项目风险 下面的问题是通过调查世界各地有经验的软件项目管理者而得到的风险数据导出的。这些问题根据它们对于项目成功的相对重要性顺序排列。 ( 高层的软件和客户的管理者是否正式地同意支持该项目？ ( 终端用户是否热心地支持该项目和将要建立的系统∕产品？ ( 软件工程组和他们的客户对于需求是否有充分的理解？ ( 客户是否充分地参与了需求定义过程。 ( 终端用户的期望是否实际？ ( 项目的范围是否稳定？ ( 软件工程组是否拥有为完成项目所必须的各种技术人才。 ( 项目的需求是否稳定？ ( 项目组是否具有实现目标软件系统的技术基础和工作经验？ ( 项目组中的人员数量对于执行项目的任务是否足够？ ( 所有客户是否都一致赞同该项目的重要性并支持将要建立的系统∕产品( 只要对这些问题的回答有一个是否定的，就应当制定缓解、监控、驾驭的步骤以避免项目失败。项目处于风险的程度直接与对这些问题否定回答的数目成比例。 ④ 风险构成和驱动因素 美国空军在一本关于如何识别和消除风险的手册中给出如何标识影响风险构成的风险驱动因素。风险构成有如下几种： ( 性能风险——产品是否能够满足需求且符合其使用目的的不确定的程度。 ( 成本风险——项目预算是否能够维持的不确定的程度。 ( 支持风险——软件产品是否易于排错、适应及增强的不确定的程度。 ( 进度风险——项目进度是否能够维持及产品是否能够按时交付的不确定的程度。 如表9.15所示，每个风险驱动因素对风险构成的影响可以划分为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列是利用表9.15给出的对风险产生影响的评价。这要求对4种风险构成(性能、支持、成本、进度)的影响类别求平均值，得到一个整体的影响值。 表9.16 风险表 风 险  类 别 概率 影响 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＝0.82，因而，这是一个极可能的风险。 一旦完成了风险表前四列的内容，就可以根据概率和影响进行排序。高发生概率和高影响的风险移向表的前端，低概率低影响的风险向后移动，完成第一次风险优先排队。 项目管理人员研究已排序的表，定义一条截止线(Cutoff line)，这条截止线(在表中某一位置的一条横线)表明，位于线上部分的风险将给予进一步关注而位于线下部分的风险需要再评估以完成第二次优先排队。 参看图9.10，风险影响和发生概率对驾驭参与有不同的影响。一个具有较高的影响但发生概率极低的风险应当不占用很多有效管理时间。然而，具有中等到高概率的高影响的风险和具有高概率的低影响的风险，就必须进行风险的分析。 ② 风险评价 在进行风险评价时，可建立一系列三元组：[ ri, li, xi ]，其中，ri是风险，li是风险出现的可能性(概率)，而xi是风险产生的影响。在做风险评价时，应进一步审查在风险估计时所得到的估计的准确性，尝试对已发现的风险进行优先排队，并着手考虑控制和∕或消除可能出现风险的方法。 在做风险评价时常采用的一个非常有效的方法就是定义风险参照水准。对于大多数软件项目来说，性能、支持、成本、进度就是典型的风险参照水准。就是说，对于成本超支、进度延期、性能降低、支持困难，或它们的某种组合，都有一个水准值，超出它就会导致项目被迫终止。如果风险的某种组合所产生的问题导致一个或多个这样的参照水准被超出，工作就要中止。在软件风险分析的上下文中，一个风险参照水准就有一个点，叫做参照点或崩溃点。在这个点上，要公平地给出可接受的判断，看是继续执行项目工作，还是终止它们（出的问题太大）。 图9.11用图示表示这种情况。如果因为风险的某一组合造成问题，导致项目成本超支和进度延迟，一系列的参照点构成一条曲线，超出它时就会引起项目终止(黑色阴影区域)。在参照点上，要对做出是继续进行还是终止的判断公正地加权。 实际上，参照点能在图上被表示成一条平滑的曲线的情况很少。在多数情况中，它是一个区域，在此区域中存在许多不确定性的范围，在这些范围内想做出基于参照值组合的管理判断往往是不可能的。 因此，在做风险评价时，我们按以下步骤执行： ( 定义项目的各种风险参照水准； ( 找出在各 [ ri, li, xi ] 和各参照水准之间的关系； ( 预测一组参照点以定义一个项目终止区域，用一条曲线或一些不确定性区来界定； ( 预测各种复合的风险组合将如何影响参照水准。 (3) 风险驾驭和监控 为了执行风险驾驭与监控活动，必须考虑与每一风险相关的三元组(风险描述、风险发生概率、风险影响)，它们构成风险驾驭(风险消除)步骤的基础。例如，假如人员的频繁流动是一项风险ri，基于过去的历史和管理经验，频繁流动可能性的估算值li为0.70，而影响xi的估计值是：项目开发时间增加15％，总成本增加12％。为了缓解这一风险，项目管理必须建立一个策略来降低人员的流动造成的影响。可采取的风险驾驭步骤如下： ( 与现有人员一起探讨人员流动的原因(如，工作条件差，收入低，人才市场竞争等)； ( 在项目开始前，把缓解这些原因的工作列入管理计划中。 ( 当项目启动时，做好人员流动会出现的准备。采取一些技术以确保人员一旦离开后项目仍能继续； ( 建立良好的项目组织和通信渠道，以使大家都了解每一个有关开发活动的信息； ( 制定文档标准并建立相应机制，以保证文档能够及时建立； ( 对所有工作组织细致的评审，使大多数人能够按计划进度完成自己的工作； ( 对每一个关键性的技术人员，要培养后备人员。 这些风险驾驭步骤带来了额外的项目成本。例如，培养关键技术人员的后备需要花钱、花时间。因此，当通过某个风险驾驭步骤而得到的收益被实现它们的成本超出时，要对风险驾驭部分进行评价，进行传统的成本－效益分析。 对于一个大型的软件项目，可能识别30－40项风险。如果每一项风险有3－7个风险驾驭步骤，那么风险驾驭本身也可能成为一个项目。 正因为如此，我们把Pareto的80／20规则用到软件风险上来。经验表明，所有项目风险的80％(即可能导致项目失败的80％ 的潜在因素)能够通过20％ 的已识别风险来说明。在早期风险分析步骤中所做的工作可以帮助计划人员确定，哪些风险属于这20％之内。由于这个原因，某些被识别过、估计过及评价过的风险可以不写进风险驾驭计划中，因为它们不属于关键的20％（具有最高项目优先级的风险）。 风险驾驭步骤要写进风险缓解、监控和驾驭计划RMMM（Risk Mitigation Monitoring and Management Plan）。RMMM记叙了风险分析的全部工作，并且做为整个项目计划的一部分为项目管理人员所使用。 一旦制定出RMMM且项目已开始执行，风险缓解与监控就开始了。风险缓解是一种问题回避活动，风险监控是一种项目追踪活动，它有三个主要目标： ( 判断一个预测的风险事实上是否发生了； ( 确保针对某个风险而制定的风险消除步骤正在合理地使用； ( 收集可用于将来的风险分析的信息。 多数情况下，项目中发生的问题总能追踪到许多风险。风险监控的另一项工作就是要把“责任”（什么风险导致问题发生）分配到项目中去。 风险分析需要占用许多有效的项目计划工作量。识别，估计，评价，管理和监控都需要时间，但这些工作量花得值得。孙子曾经说过：“知己知彼，百战不殆。” 8、进度安排 软件开发项目的进度安排有两种考虑方式： （1）系统最终交付日期已经确定，软件开发部门必须在规定期限内完成； （2）系统最终交付日期只确定了大致的年限，最後交付日期由软件开发部门确定。 後一种安排能够对软件项目进行细致分析，最好地利用资源，合理地分配工作， 而最后的交付日期可以在对软件进行仔细地分析之后再确定下来；但前一种安排在实际工作中常遇到，如不能按时完成，用户会不满意，甚至还会要求赔偿经济损失，所以必须在规定的期限内合理地分配人力和安排进度。 进度安排的准确程度可能比成本估算的准确程度更重要。软件产品可以靠重新定价或者靠大量的销售来弥补成本的增加，但是进度安排的落空，会导致市场机会的丧失，使用户不满意，而且也会导致成本的增加。 (1) 软件开发小组人数与软件生产率 对于一个小型软件开发项目，一个人就可以完成需求分析、设计、编码和测试工作。随着软件开发项目规模的增大，就需要更多的人共同参与同一软件项目的工作，因此要求由多人组成软件开发组。但是，软件产品是逻辑产品而不是物理产品，当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。 若两个人之间需要通信，则在这两人之间存在一条通信路径。如果一个软件开发组有n个人，每两人之间都需要通信，则总的通信路径有 n*(n-1)/2（条）。假设一个人单独开发软件，生产率是5000行／人年。若4个人组成一个小组共同开发这个软件，则需要6条通信路径。若在每条通信路径上耗费的工作量是250行／人年。则组中每人的生产率降低为： 5000－6×250／4 ＝ 5000－375 ＝ 4625 行／人年。 从上述简单分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件开发组是必要的。有人提出，软件开发组的规模不能太大，人数不能太多，一般在2～8人左右为宜。 (2) 任务的确定与并行性 当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行情形。图9.12显示了一个典型的由多人参加的软件工程项目的任务图。

*： 项目阶段任务的里程碑 图9.12 软件项目的并行性 在软件开发过程的各种活动中，第一项任务是进行项目的需求分析和评审，此项工作为以后的并行工作打下了基础。一旦软件的需求得到确认，并且通过了评审，概要设计(系统结构设计和数据设计)工作和测试计划制定工作就可以并行进行。如果系统模块结构已经建立，对各个模块的详细设计、编码、单元测试等工作又可以并行进行。待到每一个模块都已经调试完成，就可以对它们进行组装，并进行组装测试，最后进行确认测试，为软件交付进行确认工作。在图中可以看到，软件开发进程中设置了许多里程碑。里程碑为管理人员提供了指示项目进度的可靠依据。当一个软件工程任务成功地通过了评审并产生了文档之后，一个里程碑就完成了。 软件工程项目的并行性提出了一系列的进度要求。因为并行任务是同时发生的，所以进度计划必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。此外，应注意构成关键路径的任务，即若要保证整个项目能按进度要求完成，就必须保证这些任务要按进度要求完成。这样就可以确定在进度安排中应保证的重点。 (3) 制定开发进度计划 图9.13给出了在整个定义与开发阶段工作量分配的一种建议方案。这个分配方案称为40－20－40规则。它指出在整个软件开发过程中，编码的工作量仅占20％，编码前的工作量占40％，编码后的工作量占40％。 40－20－40规则只用来做为一个指南。实际的工作量分配比例必须按照每个项目的特点来决定。一般在计划阶段的工作量很少超过总工作量的2％～3％，除非是具有高风险的巨额投资的项目。需求分析可能占总工作量的10％～25％。花费在分析或原型化上面的工作量应当随项目规模和复杂性成比例地增加。通常用于软件设计的工作量在20％～25％之间。而用在设计评审与反复修改的时间也必须考虑在内。 由于软件设计已经投入了工作量，因此其后的编码工作相对来说困难要小一些，用总工作量的15％～20％就可以完成。测试和随后的调试工作约占总工作量的30％～40％。所需要的测试量往往取决于软件的重要程度。 进一步地，由COCOMO模型可知，开发进度TDEV与工作量MM的关系： TDEV ＝ a(MM)b 如果想要缩短开发时间，或想要保证开发进度，必须考虑影响工作量的那些因素。按可减小工作量的因素取值。比较精确的进度安排可利用中间COCOMO模型或详细COCOMO模型。 (4) 进度安排的方法 软件项目的进度安排与任何一个多任务工作的进度安排基本差不多，因此，只要稍加修改，就可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。 软件项目的进度计划和工作的实际进展情况，需要采用图示的方法描述，特别是表现各项任务之间进度的相互依赖关系。以下介绍几种有效的图示方法。在这几种图示方法中，有几个信息必须明确标明： · 各个任务的计划开始时间，完成时间； · 各个任务完成的标志（即○文档编写和△评审）； · 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况； · 完成各个任务所需的物理资源和数据资源。 ① 甘特图 甘特图用水平线段表示任务的工作阶段；线段的起点和终点分别对应着任务的开工时间和完成时间；线段的长度表示完成任务所需的时间。图9.14给出了一个具有5 个任务的甘特图。如果这5条线段分别代表完成任务的计划时间，则在横坐标方向附加一条可向右移动的纵线。它可随着项目的进展，指明已完成的任务(纵线扫过的)和有待完成的任务(纵线尚未扫过的)。我们从甘特图上可以很清楚地看出各子任务在时间上的对比关系。 在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。甘特图的优点是标明了各任务的计划进度和当前进度，能动态地反映软件开发进展情况。缺点是难以反映多个任务之间存在的复杂的逻辑关系。
图9.14 甘特图 ② PERT技术和CPM方法 PERT技术叫做计划评审技术，CPM方法叫做关键路径法，它们都是安排开发进度，制定软件开发计划的最常用的方法。它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。通常用两张表来定义网络图。一张表给出与一特定软件项目有关的所有任务(也称为任务分解结构)，另一张表给出应当按照什么样的次序来完成这些任务(也称为限制表)。 PERT技术和CPM方法都为项目计划人员提供了一些定量的工具，以： ( 确定关键路径，即决定项目开发时间的任务链。 ( 应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。 ( 计算边界时间，以便为具体的任务定义时间窗口。边界时间的计算对于软件项目的计划调度是非常有用的。
图9.15 开发模块A、B、C的任务网络图 例如，某一开发项目在进入编码阶段之后，考虑安排三个模块A、B、C的开发工作。其中，模块A是公用模块，模块B与C的测试有赖于模块A调试的完成。模块C是利用现成已有的模块，但对它要在理解之后做部分修改。最后直到A、B和C做组装测试为止。这些工作步骤按图9.15来安排。在此图中，各边表示要完成的任务，边上均标注任务的名字，如“A编码”表示模块A的编码工作。边上的数字表示完成该任务的持续时间。 图中有数字编号的结点是任务的起点和终点，在图中，0号结点是整个任务网络的起点，8号结点是终点。图中足够明确地表明了各项任务的计划时间，以及各项任务之间的依赖关系。 在组织较为复杂的项目任务时，或是需要对特定的任务进一步做更为详细的计划时, 可以使用分层的任务网络图。 在软件工程项目中必须处理好进度与质量之间的关系。在软件开发实践中常常会遇到这样的事情，当任务未能按计划完成时，只好设法加快进度赶上去。但事实告诉我们，在进度压力下赶任务，其成果往往是以牺牲产品的质量为代价的。还应当注意到，产品的质量与生产率有着密切的关系。日本人有个说法：在价格和质量上折衷是不可能的，但高质量给生产者带来了成本的下降这一事实是可以理解的，这里的质量是指的软件工程过程的质量。 (5) 项目的追踪和控制 软件项目管理的一项重要工作就是在项目实施过程中进行追踪和控制。可以用不同的方式进行追踪： ( 定期举行项目状态会议。在会上，每一位项目成员报告他的进展和遇到的问题。 ( 评价在软件工程过程中所产生的所有评审的结果。 ( 确定由项目的计划进度所安排的可能选择的正式的里程碑。 ( 比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。 ( 非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。 实际上有经验的项目管理人员已经使用了所有这些追踪技术。软件项目管理人员还利用“控制”来管理项目资源、覆盖问题、及指导项目工作人员。如果事情进行得顺利(即项目按进度安排要求且在预算内实施，各种评审表明进展正常且正在逐步达到里程碑)，控制将是轻微的。但当问题出现的时候，项目管理人员必须实行控制以尽可能快地排解它们。在诊断出问题之后，在应用论域中可能需要一些追加资源；人员可能要重新部署，或者项目进度要重新调整。 9、软件项目的组织 (1) 项目任务的划分 软件项目的实施，如何进行工作的划分是实施计划首先应解决的问题。常用的计划结构有： ① 按阶段进行项目的计划工作 按软件生存期把全部项目开发工作划分为若干阶段(活动)，对每个阶段的工作做出计划。再把每个阶段的工作进一步分解为若干个任务，做出任务计划。还要把任务细分为若干步骤，做出步骤计划。这样三层次的计划成为整个项目计划的依据。显然，过细地做好分层计划，可以提高计划的精确度，减少或及早地发现问题。 ② 任务分解结构 按项目本身的实际情况进行自顶向下的结构化分解，形成树形任务结构，如图9.16所示。进一步把工作内容、所需的工作量、预计完成的期限也规定下来。这样可以把划分後的工作落实到人，做到责任明确，便于监督检查。  图9.16 任务的结构化分解  ③ 任务责任矩阵 在任务分解的基础上，把工作分配给相关人员，用一个矩阵形表格表示任务的分工和责任。例如，我们把图9.16已分解的任务分配给五位软件开发人员，表9.17表明了利用任务责任矩阵表达的分工情况。从图中可以看出，工作的责任和任务的层次关系都非常明确。 表9.17 任务责任矩阵  负责人 张(( 系统工程师 王(( 系统工程师 李(( 程序员 赵(( 程序员 陈((  1    审批       1.1  收集信息  审查 设计 实现    1.2  加工信息   审查      1.2.1 统计  设计   实现    1.2.2 计算  设计   实现   1.3 打印报表  审查 设计 实现    (2) 软件项目组织的建立 参加软件项目的人员组织起来，发挥最大的工作效率，对成功地完成软件项目极为重要。开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质有关。人的因素是不容忽视的参数。 ① 组织原则 在建立项目组织时应注意到以下原则： ( 尽早落实责任：软件项目要尽早指定专人负责。使他有权有责。 ( 减少接口：一个组织的生产率是和完成任务中存在的通信路径数目成反比的。 因此，要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。 ( 责权均衡：软件经理人员所负的责任不应比委任给他的权力还大。 ② 组织结构的模式 通常有三种组织结构的模式可供选择： ( 按课题划分的模式 把软件人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务，负责完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。 ( 按职能划分的模式 把参加开发项目的软件人员按任务的工作阶段划分成若干专业小组。待开发的软件产品在每个专业小组完成阶段加工(即工序)以后，沿工序流水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档按工序在各组之间传递。这种模式在小组之间的联系形成的接口较多，但便于软件人员熟悉小组的工作，进而变成这方面的专家。 各个小组的成员定期轮换有时是必要的，为的是减少每个软件人员因长期做单调的工作而产生的乏味感。 ( 矩阵形模式 这种模式实际上是以上两种模式的复合。一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属于某一个专门组，又参加某一项目的工作。如图9.17所示。 图9.17 软件开发组织的矩阵形模式 矩阵形结构的组织具有一些优点：参加专门组的成员可在组内交流在各项目中取得的经验，这更有利于发挥专业人员的作用。另一方面，各个项目有专人负责，有利于软件项目的完成。显然，矩阵形结构是一种比较好的形式。 ③ 程序设计小组的组织形式 通常认为程序设计工作是按独立方式进行的，程序人员独立地完成任务。但这并不意味着互相之间没有联系。人员之间联系的多少和联系的方式与生产率直接相关。程序设计小组内人数少，如2～3人，则人员之间的联系比较简单。但在增加人员数目时，相互之间的联系复杂起来，并且不是按线性关系增长。并且，已经进行中的软件项目在任务紧张，延误了进度的情况下，不鼓励增加新的人员给予协助。除非分配给新成员的工作是比较独立的任务，并不需要对原任务有更细致的了解，也没有技术细节的牵连。 小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。 ( 主程序员制小组 小组的核心由一位主程序员、二至五位技术员、一位后援工程师组成。主程序员负责小组全部技术活动的计划、协调与审查工作，还负责设计和实现项目中的关键部分。技术员负责项目的具体分析与开发，以及文档资料的编写工作。后援工程师支持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的工作。并在必要时能代替主程序员工作。主程序员制小组还可以由一些专家(例如通信专家或数据库设计专家(、辅助人员(例如，打字员和秘书(、软件资料员协助工作。 主程序员制的开发小组突出了主程序员的领导，参看图9.18(a)。 这种集中领导的组织形式能否取得好的效果, 很大程度上取决于主程序员的技术水平和管理才能。 ( 民主制小组 在民主制小组中，遇到问题，组内成员之间可以平等地交换意见, 参见图9.18(b)。这种组织形式强调发挥小组每个成员的积极性，要求每个成员充分发挥主动精神和协作精神。有人认为这种组织形式适合于研制时间长、开发难度大的项目。 ( 层次式小组 在层次式小组中，组内人员分为三级：组长(项目负责人)一人负责全组工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。他直接领导二至三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。这种组织结构只允许必要的人际通信。比较适用于项目本身就是层次结构的课题。参看图9.18(c)。 这种结构比较适合项目本身就是层次结构的课题。可以把项目按功能划分成若干子项目，把子项目分配给基层小组，由基层小组完成。基层小组的领导与项目负责人直接联系。这种组织方式比较适合于大型软件项目的开发。

图9.18 三种不同的小组结构 (上排的三种为结构形式，下排的三种为通信路径) 以上三种组织形式可以根据实际情况，组合起来灵活运用。总之，软件开发小组的主要目的是发挥集体的力量进行软件研制。 (3) 人员配备 如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地配备人员应包括：按不同阶段适时任用人员，恰当掌握用人标准。 ① 项目开发各阶段所需人员 一个软件项目完成的快慢，取决于参与开发人员的多少。在开发的整个过程中，多数软件项目是以恒定人力配备的。如图9.19所示。
图9.19 软件项目的恒定人力配备 按此曲线，需要的人力随开发的进展逐渐增加，在编码与单元测试阶段达到高峰，以后又逐渐减少。如果恒定地配备人力，在开发的初期，将会有部分人力资源用不上而浪费掉。在开发的中期(编码与单元测试)，需要的人力又不够，造成进度的延误。这样在开发的后期就需要增加人力以赶进度。因此，恒定地配备人力，对人力资源是比较大的浪费。 ② 配备人员的原则 配备软件人员时, 应注意以下三个主要原则： ( 重质量──软件项目是技术性很强的工作，任用少量有实践经验、有能力的人员去完成关键性的任务，常常要比使用较多的经验不足的人员更有效。 ( 重培训──花力气培养所需的技术人员和管理人员是有效解决人员问题的好方法。 ( 双阶梯提升──人员的提升应分别按技术职务和管理职务进行, 不能混在一起。 ③ 对项目经理人员的要求 软件经理人员是工作的组织者，他的管理能力的强弱是项目成败的关键。除去一般的管理要求外，他应具有以下能力： ( 把用户提出的非技术性的要求加以整理提炼, 以技术说明书的形式转告给分析员和测试员。 ( 能说服用户放弃一些不切实际的要求, 以便保证合理的要求得以满足。 ( 能够把表面上似乎无关的要求集中在一起, 归结为“需要什么”，“要解决什么问题”。这是一种综合问题的能力。 ( 要懂得心理学，能说服上级领导和用户，让他们理解什么是不合理的要求。但又要使他们毫不勉强，乐于接受，并受到启发。 ④ 评价人员的条件 软件项目中人的因素越来越受到重视。在评价和任用软件人员时，必须掌握一定的标准。人员素质的优劣常常影响到项目的成败。能否达到以下这些条件是不应忽视的。 ( 牢固掌握计算机软件的基本知识和技能。 ( 善于分析和综合问题，具有严密的逻辑思维能力。 ( 工作踏实、细致，不靠碰运气，遵循标准和规范，具有严格的科学作风。 ( 工作中表现出有耐心、有毅力、有责任心。 ( 善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。 ( 具有良好的书面和口头表达能力。 (4) 指导与检验 指导的目的是在软件项目的过程中，动员和促进工作人员积极完成所分配的任务。实际上，指导也是属于人员管理的范围，是组织好软件项目不可缺少的工作。 检验是软件管理的最后一个方面。它是对照计划检查执行情况的过程，同时也是对照软件工程标准检查实施情况的过程。在发现项目的实施与计划或标准有较大的偏离时，应采取措施加以解决。 ① 指导工作的要点 在指导软件项目时需注意到以下几个方面的问题。 ( 鼓励──对工作的兴趣和取得显著成绩常常能够成为推动工作的积极因素。恰当而且及时地鼓励是非常重要的。 ( 引导──通常，人们愿意追随那些能够体谅个人要求或实际困难的领导。高明的领导人应能注意到这些，并能巧妙地把个人的要求和目标与项目工作的整体目标结合起来，至少应能做到在一定程度上的协调，而不应眼看着矛盾的存在和发展，以致影响工作的开展。从风险分析中可知，大幅度的人员调整是非常有害的，它会带来许多实际问题。即使是人员的临时观念也都要使项目付出不可见的代价，因而蒙受无形的损失。 ( 通信──在软件项目中充满了人际通信联系。必要的通信联络是不可少的。但实践表明，软件生产率是通信量的函数。如果人际通信数量过大，会使软件生产率迅速下降。 ② 检验管理的要点 在检验管理时应当注意到以下问题： ( 重大偏离──在软件项目实施过程中, 必须注意发现工作的开展与已制定的计划之间、或与需遵循的标准(规范)之间的重大偏离。遇到有这种情况应及时向管理部门报告并采取相应的措施给予适当的处置。 ( 选定标准──检验管理需要事先确定应当遵循的标准(或规范)，使得软件项目的工作进展可以用某些客观、精确且有实际意义的标准加以衡量。 ( 特殊情况──任何事务在一般规律之外都会存在一些特殊情况。管理人员必须把注意力软件项目实施的一些特殊情况上，认真分析其中的一些特殊问题，加以解决。 ③ 检验管理的工作范围 检验管理在软件项目中可能涉及到以下几个方面。 ( 质量管理──包括明确度量软件质量的因素和准则，决定质量管理的方法和工具，以及实施质量管理的组织形式。 ( 进度管理──检验进度计划执行的情况。 ( 成本管理──度量并控制软件项目的开销。 ( 文档管理──检验文档编写是否符合要求。 ( 配置管理──检验软件配置。 ④ 软件项目中人的因素 软件产品是人们大量智力劳动的结晶，软件项目能否获得成功，人的因素在其中所起的作用比其它任何工程项目都突出。用户是否参与及软件人员的能力等人的因素对软件生产率的影响极大。在与软件成本相关的影响因素中, 人员的能力是最大影响因素。如果在软件项目中能够充分发挥软件人员的积极性，使他们的才能得到尽量的施展，软件生产率(以单位时间内开发出的源程序的平均行数)最高可提高4倍多。 著名的软件工程专家Tom DeMarco积30年软件项目管理的经验，认为软件项目中对于人员的管理问题不能象其它事物那样简单地划分，机械地对待。他特别注意到项目的规模、成本、缺陷、加快开发的因素以及执行进度计划中的种种问题。积累了500 个项目开发过程的数据，从中发现大约15％的项目失败了。有的是一开始就被撤消，有的中途流产，有的推迟了进度，有的成果不能投入使用。而且项目规模越大，情况越糟。究其原因，绝大多数失败的项目竟找不出一个可以说得出口的技术障碍；而障碍却来自人员之间的联系问题、人员的任用问题、对上级或对雇主失望、工作缺乏动力或缺乏高额工程维持费用等等。这些人际关系问题的解决可归结于“软件项目社会学”。 关于软件人员的办公环境，有许多因素影响着软件工作的效率。DeMarco曾于1984 年到1986年在62个公司的600 名软件人员中进行编码和测试的竞赛活动，并对竞赛结果进行统计分析。结果表明，除了对语言的熟悉程度、工作年限、工资收入等因素以外，环境因素因素着很大的作用。良好的办公环境可保证软件人员高质量地完成任务。这里所说的办公环境是指每个软件人员的办公室工作面积、办公环境安静程度、专用程度、电话干扰程度、工作时间内外面来访人员次数等。 DeMarco说，你如果是一名项目管理人员，你为软件人员安排了任务，提供了工作条件，而对工作环境所带来的影响估计不足，你还是应该承担责任。 三、例题分析 【例1】由于软件工程有如下的特点，使软件管理比其它工程的管理更为困难。软件产品( A )。( B )标准的过程。大型软件项目往往是( C )项目。( D )的作用是为有效地定量地进行管理，把握软件工程过程的实际情况和它所产生的产品质量。在制定计划时，应当对人力、项目持续时间、成本作出( E )；( H )实际上就是贯穿于软件工程过程中一系列风险管理步骤。最后，每一个软件项目都要制定一个( F )，一旦( G )制定出来，就可以开始着手( H )。 供选择的答案： A ( C. ① 可见的 ② 不可见的 ③ “一次性” ④ “多次” ⑤ 存在 ⑥ 不存在 D ( H. ① 进度安排 ② 度量 ③ 风险分析 ④ 估算 ⑤ 追踪和控制 ⑥ 开发计划 答案：A. ②, B. ⑥, C. ③, D. ②, E. ④, F. ①, G. ⑥, H. ⑤。 分析：由于软件工程有如下的特点：软件产品不可见；不存在标准的软件过程；大型软件项目往往是“一次性”的项目，使得软件得管理比其它工程的管理更为困难；通常，软件人员和用户确定了软件项目的目标和范围之后，度量的作用就是为了有效地定量地进行管理。对开发过程进行度量的目的是为了改进开发过程，而对产品进行度量的目的是为了提高产品的质量。在软件项目管理过程中一个关键的活动是制定计划。在做计划时，必须就需要的人力、项目持续时间、成本作出估算；风险分析对于软件项目管理是决定性的，它实际上就是贯穿于软件工程过程中一系列风险管理步骤，其中包括风险识别、风险估计、风险评价和风险驾驭等步骤。每一个软件项目都要制定一个进度安排，但不是所有的进度都要一样地安排。一旦制定了开发计划，就可以开始着手追踪和控制活动。 【例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 ② LOC G. ① E = (a+m+b)/3 ② E = (a+4m+b)/6 ③ E = (2a+3m+4b)/3 ④ H. ① χ概率 ② γ概率 ③ β概率 ④ 泊松 答案：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、m、b。当这些值的范围被确定之后，也就隐含地指明了估计值的不确定程度。接着计算LOC或FP的期望值E。 E = (a + 4m + b) / 6. (加权平均) 其中，可能的估计值m是加权最重的最可能的估算值且遵循β概率分布。 【例3】定义一个人参加劳动时间的长短为( A )，其度量单位为PM(人月)或PY(人年)。而定义完成一个软件项目(或软件任务)所需的( A )为( B )，其度量单位是人月／项目(任务)，记作PM(人月)。进一步地，定义单位( A )所能完成的软件( C )的数量为软件( D )，其度量单位为LOC／PM。它表明一般指( E )的一个平均值。例如，一个软件的开发工作量如下表所示。该软件共有源代码2900行，其中， 500行用于测试，2400行是执行( F )的源代码。则劳动生产率是( G ) (LOC／PM)。 表 软件开发所需工作量例 阶 段 软件计划 需求分析 设 计 编 码 测 试 总 计  需要工作量(人月) 1.0 1.5 3.0 1.0 3.5 10.0  供选择的答案： A, B, D. ① 生产率 ② 工作量 ③ 成本 ④ 劳动量 E. ① 开发全过程 ② 某开发阶段 ③ 软件生存期 ④ 某开发任务 F, C. ① 软件 ② 程序 ③ 进程 ④ 产品 G. ① 520 ② 120 ③ 320 ④ 240 答案：A. ④, B. ②, C. ④, D. ①, E. ①, F. ②, G. ④。 分析：定义一个人参加劳动时间的长短为劳动量，其度量单位为PM(人月)，PY(人年)。它不同于工作量。而定义完成一个软件项目(或软件任务)所需的劳动量为工作量，其度量单位是人月／项目(任务)，记作PM(人月)。进一步地，定义单位劳动量所能完成的软件产品的数量为软件生产率，其度量单位为LOC／PM。它表明一般指开发全过程的一个平均值。题例所示的软件共有源代码2900行，其中， 500行用于测试，2400行是执行程序的源代码。则劳动生产率是(2900－500)／10 ＝ 240（LOC／PM）。【例4】对于一个大型的软件项目，由于项目的复杂性，需要进行一系列的估算处理。主要按( A )和( B )手段进行。估算的方法分为三类：从项目的整体出发，进行( 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个人年)中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。大型软件项目的开发工作量分布可以用下图所示的Rayleigh-Norden曲线表示。
该曲线的典型形状由Lord Rayleigh最早有分析地导出，并由Norden使用收集到的软件开发中的经验数据证实了这条曲线。用Rayleigh-Norden曲线可以导出一个“软件方程”，把已交付的源代码(源语句)行数与工作量和开发时间联系起来。
其中，td是开发持续时间(以年计)， K是软件开发与维护在内的整个生存期所花费的工作量(以人年计)，L是源代码行数(以LOC计)，Ck是技术状态常数，它反映出“妨碍程序员进展的限制”，并因开发环境而异。 【例6】一个规模为10KDSI的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行软件成本估算。程序的名义工作量MM = ( A )；程序实际工作量MM = ( B )；开发所用的时间TDEV = ( C )；如果软件开发人员的工资都按每月6000美元计算，则该软件项目的开发人员的工资总额 = ( D )。 表1 中间COCOMO模型的名义工作量与进度公式 总体类型 工 作 量 进 度  组 织 型  MM＝3.2 (KDSI)1.05 TDEV＝2.5 (MM)0.38  半独立型  MM＝3.0 (KDSI)1.12 TDEV＝2.5 (MM)0.35  嵌 入 型  MM＝2.8 (KDSI)1.20 TDEV＝2.5 (MM)0.32  表2 影响工作量的因素fi 的取值 影响工作量因素fi 情 况  取 值   1 软件可靠性  只用于局部地区，恢复问题不严重  1.00（正常）   2 数据库规模  20000字节  0.94（低）   3 产品复杂性  用于远程通信处理  1.30（很高）   4 时间限制  使用70%的CPU时间  1.10（高）   5 存储限制  64K中使用45K  1.06（高）   6 机器  使用商用微处理机  1.00（额定值）   7 周转时间  平均2小时  1.00（额定值）   8 分析员能力  优秀人才  0.86（高）   9 工作经验  远程通信工作3年  1.10（低）   10 程序员能力  优秀人才  0.86（高）   11 工作经验  微型机工作6个月  1.00（正常）   12 语言使用经验  12个月  1.00（正常）   13 使用现代程序设计技术  1年以上  0.91（高）   14 使用软件工具  基本的微型机软件  1.10（低）   15 工期  9个月  1.00（正常）   供选择的答案： A, B. ① 45.8 ② 51.5 ③ 44.38 ④ 54.2 C. ① 8.9月 ② 9.8月 ③ 7.8月 ④ 10.9月 D. ① 26.4万美元 ② 36万美元 ③ 20.96万美元 ④ 30.9万美元 答案：A. ③, B. ②, C. ①, D. ④。 分析：考虑如题中表2的15种影响软件工作量的因素，通过定下乘法因子，修正COCOMO工作量公式和进度公式，可更合理地估算软件(各阶段)的工作量和进度。此时，实际工作量计算公式改成：
由此得到程序名义工作量 MM = 2.8 *(10)1.20 ＝ 44.38 （MM）
开发所用时间 TDEV ＝ 2.5 *（51.5）0.32 ＝ 8.9 （月） 如果分析员与程序员的工资都按每月6,000美元计算，则该项目的开发人员的工资总额为51.5 * 6000 ＝ 309000 （美元）【例7】在特定情况下，是否必须进行风险分析，是对项目开发的形势进行( A )后确定的。( A )可以按如下步骤进行：明确项目的目标、总策略、具体策略和为完成所标识的目标而使用的方法和资源；保证该目标是( B )，项目成功的标准也是( B )；考虑采用某些条目作为项目成功的( C )；根据估计的结果来确定是否要进行风险分析。 一般来说，风险分析的方法要依赖于特定问题的需求和有关部门所关心的方面。具体分3步进行。第一步识别潜在的风险项，首先进行( D )过程；第二步估计每个风险的大小及其出现的可能性，选择一种( E )，它可以估计各种风险项的值；第三步进行风险评估。风险评估也有三个步骤：确定( F )，确定( G )，把风险与“参照风险”做比较。 供选择的答案： A. ① 风险管理 ② 风险估计 ③ 风险评价 ④ 风险测试 B. ① 可度量的 ② 不可度量的 ③ 准确的 ④ 不确定的 C. ① 规范 ② 标准 ③ 过程模型 ④ 设计要求 D, E. ① 信息分类 ② 信息收集 ③ 度量尺度 ④ 标准 ⑤ 度量工具 ⑥ 信息获取 F, G. ① 风险的范围 ② 风险的特性 ③ 风险的级别 ④ 风险的评价标准 ⑤ 风险的排除策略 答案：A. ②, B. ①, C. ②, D. ②, E. ③, F. ④, G. ③。分析：在特定的情况下，是否必须进行风险分析，是对项目的开发形势进行风险估计后确定的。因为风险分析需要相当大的费用。只有在软件的费用、软件的作用、软件的性能及软件与系统的关系等各方面对系统有比较大的影响时，即软件的风险对于整个系统的成败，或对系统的风险有关键的影响时，才有必要进行软件的风险分析和管理。风险估计的步骤如下： ( 明确项目的目标、总策略、具体策略和为完成所标识的目标而使用的方法和资源； ( 保证该目标是可度量的，项目成功的标准也是可度量的； ( 考虑采用以下的某些条目作为项目成功的标准：① 最大限度的收益，② 最小的费用，③ 最小的风险损失，④ 最大限度的市场，⑤ 最小的周期性的波动，⑥ 形成有益的形象，⑦ 最佳的服务质量，⑧ 最高的增长率，⑨ 员工的满意度最高，⑩ 公司声望最高； ( 根据估计的结果来确定是否要进行风险分析。 一般来说，风险分析的方法要依赖于特定问题的需求和有关部门所关心的方面。下面给出一种结构化的、一致的方法来进行风险分析。具体分3步进行。 第一步识别潜在的风险项。当确定要进行风险分析之后，就要收集信息，表明相关的风险。这就需要观察风险的征兆，理解其产生的原因，并列出所有的风险项。 首先进行信息收集。可以从过去完成的项目中收集已有的经验和收集来自群众的经验；可以模拟著名的事例；可以考虑类似的因素和进行常识性的判断；可以进行试验或测试以得到有关的结果，可以用各种方式来获得可能忽略的情况；此外，还可以针对经常发生的错误进行普查统计等。一般来说，通过过去的历史来认识软件项目的风险也许时一种最好的办法。例如，一些数字表明修复一个需求或设计阶段的错误的费用可能比修复一个测试阶段的错误的费用高100倍到1000倍。因此，可以把需求阶段标识为一个软件开发各阶段的风险区域。 然后进行信息分类。必须将收集到的信息以某种方式进行分类。一种简单而有用的方法是把风险项分为三类：有风险、可预见的风险、不可预见的风险。“有风险”是指经常发生的情况；“可预见的风险”是指以较高概率出现的情况；“不可预见的风险”是指不能识别的、未知的、不能观察的风险，是可能发生但事前很难预料的风险。对于每一种类型，还可以按其原因分成三种子类型：缺乏信息、缺乏管理及缺乏时间。其它分类方法可以按直接或间接分类，按运行性或策略性分类，按技术、进度、成本、支持分类。 第二步估计每个风险的大小及其出现的可能性，风险估计要度量所标识的各个风险可能造成的损失，即各种风险项的值(后果及程度)，用以减少度量的不确定性。可以按以下步骤进行： 选择某一种度量尺度，用以估计计算各种风险项的值，并具有合适的精度。由于要估计的风险信息可能有3种形式：叙述性、定性或定量，所以可选的尺度可以是命名尺度、序次尺度、坐标尺度或比例尺度。待估计的信息与度量尺度之间要建立对应关系，不同类型的信息有不同的度量尺度。例如，叙述性信息需要有命名尺度或序次尺度，定量的信息需要坐标或比例性的尺度。下表列出定量的风险等级： 风险等级 失效概率  说 明  极高 0.99 ( 0.81 超过当前的技术水平，肯定是技术问题。  很高 0.80 ( 0.61 超过当前的技术水平，极像是技术问题。  高 0.60 ( 0.50 最新的、尚未充分成熟的技术，好像是技术问题。  中等 0.49 ( 0.24 最佳技术，只会有很小的技术问题。  低 0.24 ( 0.10 使用的技术，没有技术问题。  很低 0.09 ( 0.01 在使用中的系统。  在使用不同的方法和技术进行风险估计时常常会出现偏差，这是由于缺少可用来进行判断的信息，从而限制了风险估计的精度。由于信息分散，各人的理解和解释不同，造成“信息可用性偏差”。其次，选择的观念不同、专家的偏爱、采样规模的影响、样本相关的影响，以及修正的偏差等，都会产生估计的偏差。特别要注意的是：对于连续发生的事件和间断的不连续发生事件，这些偏差会造成什么样的影响。 必须采用一些技术来克服或消减风险估计中的不确定性。风险一般可以看成属于以下三种过程之一：行为型、自然型和随机型。 过程种类  克服和消减叙述型的不确定性 克服和消减度量型的不确定性  行为型 受定义人类行为的能力的限制 受理性的人类行为的限制  自然型 理论上无限制，但实际上有一定范围 受度量系统的精度的限制  随机型 理论上无限制，但实际上有一定范围 无法消减不确定性  第三步进行风险评估。因为软件项目所面临的是风险的一个较大的集合及其相互之间的影响，因此，必须针对这一点进行风险评估，以达到以下的目的： 首先，考虑各种风险的综合影响后，对已识别风险发生的可能性及其后果给出最终的量值(如果情况发生变化，也许要重新分析风险发生的可能性和可能的后果)； 其次，提供某种机制，对各个风险标明优先次序，以便予以适当安排； 最后，通过考虑其它可替代的方案，寻找避免风险的基本方法，即为高层决策人员提供全部必要的信息，以作出合理的有依据的决策。进行风险评估有三个步骤： ① 确定风险评估的标准。其目的是可用以衡量每个风险的后果，即判定在项目的生存期中各个阶段的风险的后果是否可以接受。此标准应与项目成功的标准相关。 ② 确定风险的级别。其目的是把项目作为整体来评估。就是说，人们必须理解各种风险之间的相互作用，以及修改某些因素会如何影响它们之间的相互作用。 为了说明可被评估的风险，引入“参照风险”。“参照风险”可以是一组单个风险的集合，或对项目会造成最大损害的一个或多个风险。必须仔细认清各风险间可能发生的耦合或复合情况。说明在把系统视为一个整体时，风险将导致系统失败的概率。 ③ 把风险与“参照风险”做比较。把已评定的风险与在早期确定的“参照风险”相比较，结果可能是以下3种情况之一： ( 可接受(评定的风险低于“参照风险”)； ( 不可能接受(评定的风险大大高于“参照风险”)； ( 不适合接受(评定的风险大于，但几乎等于“参照风险”)。 【例8】假设开发某个计算机应用系统的投资额为3000元，该计算机应用系统投入使用后，每年可以节约1000元，5年内可能节约5000元。3000元是现在投资的钱，5000元是5年内节省的钱，两者不能简单地比较。 假定年利率为12%，利用计算货币现在价值的公式，可以算出该计算机应用系统投入使用后每年预计节省的金额的现在价值。 年 节省(元) 利率(1 + 0.12)n 现在价值(元)  累计现在价值(元)  1 1000 1.12 892.86  892.86  2 1000 1.25 800.00  1692.86  3 1000 1.40 714.29  2407.15  4 1000 1.57 636.94  3044.09  5 1000 1.76 568.18  3612.27   则该系统的纯收入是( A )，投资回收期是( B )，投资回收率为( C )。 供选择的答案： A. ① 512.3元 ② 729.28元 ③ 602.4元 ④ 612.27元 B. ① 2. 4年 ② 3.93年 ③ 4.25年 ④ 2.78元 C. ① 25% ② 30% ③ 20% ④ 15% 答案：A. ④, B. ②, C. ③。 分析：效益包括经济效益，也包括社会效益。前者是有形的，后者是无形的。系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用。运行费用包括操作员人数、工作时间、消耗的物资等。在计算系统的经济效益时，应按照货币的时间价值来计算，这是因为对项目的投资在前，而系统效益的产生在后，且常常有一个较长的过程。 通常，用利率表示货币的时间价值。若设年利率为i，现已存入P元，则n年后可得到的钱数为：F = ( 1 + i ) n，F就是P元钱在n年后的价值。 反之，若n年后能收入F元，那么这些钱现在的价值是：P = F∕( 1 + i ) n。 由此，可从题意得： 该计算机应用系统在5年中的纯收入为：3612.27 - 3000 = 612.27 (元)。 投资回收期约为：3 +(3000-2407.15)/(3044.09-2407.15) ≈ 3.93 (年)。 投资回收率设为r，由下列方程式： 3000 = 1000/(1+ r)+1000/(1+ r)2+1000/(1+ r)3+ …… +1000/(1+ r)5 解得r = 20%。 纯收入就是在整个生存期之内系统的累计经济效益(折合成现在值)与投资之差。投资回收期就是使累计的经济效益等于最初的投资所需的时间。投资回收率时投入资金所获得的利率。 【例9】软件项目管理的主要职能包括：( A )，建立组织，配备人员，( B )和( C )。由于软件项目的特有性质，使得项目管理存在一定困难。第一、( 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. ① 过程 ② 对象 ③ 人 ④ 存取 ⑤ 规模 ⑥ 进程 ⑦ 功能 ⑧ 数据 【9-3】估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。通常估算本身带有( A )。项目的复杂性越高，规模越大，开发工作量( B )，估算的( A )就( C )。项目的结构化程度提高，进行精确估算的能力就能( D )，而风险将( E )。有用的历史信息( F )，总的风险会减少。 供选择的答案： A. ① 风范（范型） ② 风格 ③ 风险 ④ 度量 B ( F. ① 增加 ② 越多 ③ 降低 ④ 不变 ⑤ 越少 ⑥ 越高 ⑦ 越大 【9-4】 在考虑各种软件开发资源时，( A )是最重要的资源。如果把软件开发所需的资源画成一个金字塔形：在塔的上层是最基本的资源( A )，在底部为( B )。( B )包括硬件资源和软件资源。( C )、( D )和其它硬件设备属于硬件资源。IPSE工具属于软件资源中的( E )。为了提高软件的生产率和软件产品的质量，可建立( F )。 供选择的答案： A, B. ① 方法 ② 人力 ③ 工具 ④ 上下文环境 C, D. ① 虚拟机 ② 目标机 ③ 自动机 ④ 宿主机 E, F. ① 维护工具 ② 分析设计工具 ③ 支持工具 ④ 编程工具 ⑤ 可复用构件库 ⑥ 框架工具 ⑦ 原型化模拟工具 【9-5】任何软件项目都必须做好项目管理工作，最常使用的进度管理工具是( A )，当某一开发项目的进度有可能拖延时，应该( B )。对于一个典型的软件开发项目，各开发阶段需投入的工作量的百分比大致是( C )。各阶段所需不同层次的技术人员大致是( D )，而管理人员在各阶段所需数量也不同，相对而言大致是( E )。 供选择的答案： A. ① 数据流图 ② 程序结构图 ③ 因果图 ④ PERT图 B. ① 增加新的开发人员 ② 分析拖期原因加以补救 ③ 从别的小组抽调人员临时帮忙 ④ 推迟预定完成时间   需求分析 设 计  编 码  测 试    投入 工作量 ① 25 25  25  25   C.  ② 10 20  30  40    ③ 15 30  15  40    ④ 5 10  65  30    技术人 员水平 ① 初级 高级  高级  高级   D.  ② 中级 中级  高级  中级    ③ 高级 中高级  初级  中高级    ④ 中级 中高级  中级  初级    管理人 员数量 ① 多 中  少  中   E.  ② 中 中  中  中    ③ 多 少  多  多    ④ 少 多  少  多  【9-6】一个32KDSI的声音输入系统是一个输入原型，或是一个可行性表演模型。所需可靠性非常低，因为它不打算投入生产性使用。把此模型看做半独立型软件。试问该软件的名义工作量和实际工作量。 【9-7】风险分析实际上是4个不同的活动，按顺序依次为( A )、( B )、风险评价和( C )。在风险评价时，应当建立一个三元组：[ ri, li, xi ]，ri是风险描述，li是( D )，而xi是风险的影响。一个对风险评价很有用的技术是定义( E )。( F )、( G )、( H )是三种典型的( E )。在做风险分析的上下文环境中一个( E )就存在一个单独的点，叫做参照点或( I )。在这个点上要公正底给出判断。实际上，参照点能在图上表示成一条平滑的曲线的情况很少，多数情况它是一个( J )。 供选择的答案： A ( C. ① 风险驾驭和监控 ② 风险识别 ③ 风险估计 ④ 风险消除 D. ① 风险的大小 ② 风险的概率 ③ 风险的时间 ④ 风险的范围 E. ① 风险参照水准 ② 风险度量 ③ 风险监控 ④ 风险工具 F ( H. ① 生产率 ② 功能 ③ 成本 ④ 进度 ⑤ 范围 ⑥ 性能 I, J. ① 凹点 ② 崩溃点 ③ 终点 ④ 区域 ⑤ 拐点 ⑥ 原点 【9-8】对于一个小型的软件开发项目，一个人就可以完成需求分析、设计、编码和测试工作。但随着软件项目规模增大，需要有多人共同参与同一软件项目的工作。当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的( A )问题，即通信问题。通信需花费时间和代价，会引起软件错误( B )，( C )软件生产率。如果一个软件开发小组有n个人，每两人之间都需要通信，则共有( D )条通信路径。假设一个人单独开发软件，生产率是5000行／人年，且在每条通信路径上耗费的工作量是250行／人年。若4个人组成一个小组共同开发这个软件，则小组中每个人的软件生产率为( E )。若小组有6名成员，则小组中每个成员的软件生产率为( F )。因此，有人提出，软件开发小组的规模不能太大，人数不能太多，一般在( G )人左右为宜。 供选择的答案： A. ① 分配 ② 管理 ③ 接口 ④ 协作 B, C. ① 降低 ② 增加 ③ 不变 D. ① n(n+1)/2 ② n(n-1)/2 ③ n(n-1)(n-2)/6 ④ n2/2 E, F. ① 4875 ② 4375 ③ 4625 ④ 5735 G. ① 8～15 ② 1～2 ③ 2～5 ④ 2～8 【9-9】软件项目的进度管理有许多方法，但( A )不是常用的进度控制图示方法。在几种进度控制图示方法中，( B )难以表达多个子任务之间的逻辑关系，使用( C )不仅能表达子任务之间的逻辑关系，而且可以找出关键子任务。在( C )中，用带箭头的边表示( D )，用圆圈结点表示( E )，它标明( D )的( F )。 供选择的答案： A ( C. ① 甘特图 ② IPO ③ PERT ④ 时标网状图 D ( F. ① 数据流 ② 控制流 ③ 事件 ④ 处理 ⑤ 起点或终点 ⑥ 任务 【9-10】软件项目组织的原则是( A )、( B )和( C )。一般有( D )、( E )、( F )三种组织结构的模式。( F )实际上是( D )和( E )两种模式的复合。( E )这种模式在小组之间的联系形成的接口较多，但便于软件人员熟悉小组的工作，进而成为这方面的专家。 供选择的答案： A ( C. ① 推迟责任的落实 ② 尽早落实责任 ③ 减少接口 ④ 增加联系 ⑤ 责权分离 ⑥ 责权均衡 D ( F. ① 矩阵形模式 ② 主程序员小组模式 ③ 按课题划分的模式 ④ 按职能划分的模式 ⑤ 民主制小组模式 【9-11】软件开发小组的目的是发挥集体的力量进行软件研制。因此，小组从培养( A )的观点出发进行程序设计消除软件的( B )的性质。通常，程序设计小组的组织形式有三种，如下图所示的a属于( C )，b属于( D )，c属于( E )。
供选择的答案： A, B. ① “局部” ② “全局” ③ “集体” ④ “个人” C ( E. ① 层次式小组 ② 民主制小组 ③ 主程序员制小组 五、习题解答 【9-1】A. ④, B. ③, C. ⑥, D. ⑧, E. ②, F. ⑤。 软件过程是软件生存期中的一系列相关软件工程活动的集合。每一个软件过程又是由一组工作任务、项目里程碑、软件工程产品和交付物以及质量保证(SQA)点等组成。一个软件过程可以用右图的形式来表示。首先建立一个公共过程框架，其中定义了少量可适用于所有软件项目的框架活动，而不考虑它们的规模和复杂性。再给出各个框架活动的任务集合，使得框架活动能够适合于项目的特点和项目组的需求。最后是保护伞活动，如软件质量保证、软件配置管理以及测量等，它们独立于任何一个框架活动并将贯穿于整个过程。软件过程模型的选择基于项目和应用的特点、采用的方法和工具、要求的控制和需交付的产品。 【9-2】A. ①, B. ④, C. ④, D. ①, E. ②, F. ⑤, G. ⑦, H. ③。 软件的度量包括直接度量和间接度量。软件产品的直接度量包括产生的代码行数、执行速度、存储量大小、在某种时间周期中所报告的差错数。软件产品的间接度量则包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性。只要事先建立特定的度量规程，很容易做到直接度量开发软件所产生的代码行数等。但是，软件的功能性、效率、可维护性等质量特性却很难用直接度量判明，只有通过间接度量才能推断。我们还可进一步将软件度量如图所示那样分类。软件生产率度量主要关注软件工程过程的结果；软件质量度量则指明了软件适应明确和不明确的用户要求(软件使用合理性)到什么程度；技术度量主要关注软件的一些特性(如逻辑复杂性、模块化程度)而不是软件开发的全过程。从图中还可以看到另一种分类方法：面向规模的度量用于收集与直接度量有关的软件工程输出的信息和质量信息。面向功能的度量提供直接度量的尺度。面向人的度量则收集有关人们开发软件所用方式的信息和人们理解有关工具和方法的效率的信息。 估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。通常估算本身带有( A )。项目的复杂性越高，规模越大，开发工作量( C )，估算的( A )就( D )。项目的结构化程度的提高，进行精确估算的能力就能( E )，而风险将( F )。有用的历史信息( G )，总的风险会减少。 供选择的答案： A. ①风范（范型） ② 风格 ③ 风险 ④ 度量 B ( G. ① 增加 ② 越大 ③ 降低 ④ 不变 ⑤ 减少 ⑥ 越高 【9-3】A. ③, B. ②, C. ⑦, D. ①, E. ③, F. ②。 估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。估算本身带有风险。增加风险的各种因素如图所示。
项目的复杂性对于增加软件估算的不确定性影响很大。复杂性越高，估算的风险就越高。但是，复杂性是相对度量，它与项目参加人员的经验有关。 项目的规模对于软件估算的精确性和功效影响也比较大。因为随着软件规模的扩大，软件元素之间的相互依赖、相互影响程度迅速增加，因而估算的一个重要方法──问题分解会变得更加困难。由此可知，项目的规模越大，开发工作量越大，估算的风险越高。 项目的结构化程度也影响项目估算的风险。所谓结构性是指功能分解的简便性和处理信息的层次性。结构化程度的提高，进行精确估算的能力就能提高，而风险将减少。 历史信息的有效性也影响估算的风险。回顾过去，就能够仿效做过的事，且改进出现问题的地方。在对过去的项目进行综合的软件度量之后，就可以借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。 风险靠对不确定性程度定量地进行估算来度量，此外，如果对软件项目的作用范围还不十分清楚，或者用户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频频变动，增加估算的风险。 【9-4】A. ②, B. ③, C. ②, D. ④, E. ⑥, F. ⑤。其中，C、D的答案顺序可互换。 软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。若把软件开发所需的资源画成一个金字塔，在塔的底部必须有现成的用以支持软件开发的工具──硬件工具及软件工具，在塔的高层是最基本的资源──人。在考虑各种软件开发资源时，人是最重要的资源。在安排开发活动时必须考虑人员的技术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要。 硬件是作为软件开发项目的一种工具而投入的。在软件项目计划期间，考虑三种硬件资源：宿主机(软件开发时使用的计算机及外围设备)；目标机(运行已开发成功软件的计算机及外围设备)；其它硬件设备(专用软件开发时需要的特殊硬件资源)。宿主机连同必要的软件工具构成一个软件开发系统。通常这样的开发系统能够支持多种用户的需要，且能保持大量的由软件开发小组成员共享的信息。但在许多情况下，除了那些很大的系统之外，不一定非要配备专门的开发系统。因此，所谓硬件资源，可以认为是对现存计算机系统的使用，而不是去购买一台新的计算机。宿主机与目标机可以是同一种机型。 软件在开发期间使用了许多软件工具来帮助软件的开发。这些软件工具叫做计算机辅助软件工程(CASE)。主要的软件工具分类为：业务系统计划工具集；项目管理工具集；支持工具；分析和设计工具；编程工具；组装和测试工具；原型化和模拟工具；维护工具；框架工具。这些框架工具能够提供一个建立集成项目支撑环境(IPSE)的框架。在多数情况，框架工具实际提供了数据库管理和配置管理的能力与一些实用工具，能够把各种工具集成到IPSE中。 为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件构件库。根据需要，对软件构件稍做加工，就可以构成一些大的软件包。这要求这些软件构件应加以编目，以利引用，并进行标准化和确认，以利于应用和集成。 【9-5】A. ④, B. ②, C. ③, D. ③, E. ①。 PERT技术叫做计划评审技术，是安排开发进度，制定软件开发计划的最常用的方法。它采用网络图来描述一个项目的任务网络。通常用两张表来定义网络图。一张表给出与一特定软件项目有关的所有任务(也称为任务分解结构)，另一张表给出应当按照什么样的次序来完成这些任务(有时称为限制表)。 当某一开发项目的进度有可能拖延时，应该分析拖期原因加以补救，切忌中途加人，否则反而会降低软件生产率。对于一个典型的软件开发项目，各开发阶段需投入的工作量的百分比大致遵循40－20－40规则。即在整个软件开发过程中，编码的工作量占20％，编码前的工作量占40％，编码后的工作量占40％。 对于一些规模较小的项目(1个人年或者更少)，只要向专家做些咨询，也许一个人就可以完成所有的软件工程步骤。而对一些规模较大的项目，在整个软件生存期中，各种人员的参与情况是不一样的。如图所示。在软件计划和需求分析阶段，对软件系统进行定义，主要工作是由管理人员和高级技术人员在做，初级技术人员参与较少。待到对软件进行具体设计、编码及测试时，管理人员逐渐减少对开发工作的参与，高级技术人员主要在设计方面把关，具体编码及调试参与较少，大量的工作将由初级技术人员去做。到了软件开发的后期，需要对软件进行检验、评价和验收，管理人员和高级技术人员又将投入很多的精力。
【9-6】 对于这样一个规模为10KDSI的商用微机远程通信的嵌入式软件，使用中间COCOMO模型进行软件成本估算。名义工作量为MM = 3.0*(10)1.12 = 146 (人月)。又查表知 f1 = 0.75，其它 fi = 1.00，则最终计算出的实际工作量为MM = 146 * 0.75 = 110 (人月)。 【9-7】A. ②, B. ③, C. ①, D. ②, E. ①, F. ③, G. ④, H. ⑥, I. ②, J. ④。其中，F、G、H的答案顺序可互换。 风险分析实际上是4个不同的活动： 风险识别，风险估计，风险评价和风险驾驭与监控。 在进行风险评价时，可建立一系列三元组：[ ri, li, xi ]，其中，ri是风险，li是风险出现的可能性(概率)，而xi是风险产生的影响。在做风险评价时，应进一步审查在风险估计时所得到的估计的准确性，尝试对已发现的风险进行优先排队，并着手考虑控制和∕或消除可能出现风险的方法。 在做风险评价时常采用的一个非常有效的方法就是定义风险参照水准。对于大多数软件项目来说，性能、支持、成本、进度就是典型的风险参照水准。就是说，对于成本超支、进度延期、性能降低、支持困难，或它们的某种组合，都有一个水准值，超出它就会导致项目被迫终止。在软件风险分析的上下文中，一个风险参照水准就有一个点，叫做参照点或崩溃点。在这个点上，要公平地给出可接受的判断，看是继续执行项目工作，还是终止它们（出的问题太大）。实际上，参照点能在图上被表示成一条平滑的曲线的情况很少。在多数情况中，它是一个区域，在此区域中存在许多不确定性的范围。 【9-8】A. ③, B. ②, C. ①, D. ②, E. ③, F. ②, G. ④。 对于一个小型的软件开发项目，一个人就可以完成需求分析、设计、编码和测试工作。但是，随着软件开发项目规模的增大，就会有更多的人共同参与同一软件项目的工作。例如10个人1年可以完成的项目，若让1个人干10年是不行的。因此，需要多人组成开发小组共同参加一个项目的开发。但是，当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间和代价，会引起软件错误增加，降低软件生产率。 若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开发小组有n个人，每两人之间都需要通信，则总的通信路径有n(n-1)/2条。 假设一个人单独开发软件，生产率是5000行／人年。若4个人组成一个小组共同开发这个软件，则需要6条通信路径(图(a))。若在每条通信路径上耗费的工作量是250行／人年。则小组中每个人的软件生产率降低为 5000－6×250／4 ＝ 5000－375 ＝ 4625 行／人年。 如果小组有6名成员,通信路径增加到15条(图(b))。每条通信路径消耗的工作量不变，则小组中每个成员的软件生产率降低为 5000－15×250／6 ＝ 5000－625 ＝ 4375 行／人年。
从上述简单分析可知，一个软件任务由一个人单独开发，生产率最高；而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件开发小组是必要的。有人提出，软件开发小组的规模不能太大，人数不能太多，一般在2～8人左右为宜。 【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. ①。 软件开发小组的主要目的是发挥集体的力量进行软件研制。因此，小组培养从“全局”的观点出发进行程序设计，消除软件的“个人”性质，并促进更充分的复审，小组提倡在共同工作中互相学习从而改善软件的质量。 小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。 ① 主程序员制小组：突出了主程序员的领导，强调主程序员与其他技术人员的直接联系，简化了人际通信。这种集中领导的组织形式能否取得好的效果, 很大程度上取决于主程序员的技术水平和管理才能。美国的软件产业中大多是主程序员制的工作方式。 ② 民主制小组：组内成员之间可以平等地交换意见，工作目标的制定及做出决定都由全体成员参加。这种组织形式强调发挥小组每个成员的积极性，要求每个成员充分发挥主动精神和协作精神。有人认为这种组织形式适合于研制时间长、开发难度大的项目。日本在发展计算机事业中，组织软件开发大多采用这种形式的开发小组，取得了很好的效果。 ③ 层次式小组：这种结构比较适合项目本身就是层次结构状的课题。因为这样可以把项目按功能划分成若干个子项目，把子项目分配给基层小组，由基层小组完成。基层小组的领导与项目负责人直接联系。这种组织方式比较适合于大型软件项目的开发。 以上三种组织形式可以根据实际情况，组合起来灵活运用。例如，较大的软件项目也许是把主程序员小组组织成层次式结构；也许基层小组的领导又是一个民主制小组的成员。