全国计算机四级考试复习纲要-第五章(3)

　　⑤通信内聚:如果一个模块的所有处理元素集中在一个数据结构的区域上，该模块属于通信内聚。例如，一个模块中的所有处理元素使用同一输入数据。

　　⑥顺序内聚:如果一个模块的处理元素是相关的，而且必须顺序执行，这个模块属于顺序内聚。

　　⑦功能内聚:如果一个模块完成一个单一的功能，模块中的各部分在此目标下协同工作，而且都是为完成这一功能而不可缺少的，那么这个模块是功能内聚的。

　　5.模块分解时应遵循的准则

　　(1)满足信息隐蔽原则

　　(2)尽量使得模块的内聚度高，模块间的耦合度低。

　　(3)模块的大小适中(通常一个模块以50～100个语句行为适宜)。

　　(4)模块的调用深度不宜过大。一个模块A可以调用另一模块B，模块B还可调用模块C，称模块A直接调用模块B，模块A间接调用模块C，被间接调用的模块还可调其他模块，这样可形成一棵调用树，我们把以某个模块为根结点的调用树的深度称为该模块的调用深度。

　　(5)模块的扇入应尽量大，扇出不宜过大。一个模块的扇入是指直接调用该模块的上级模块个数。一个模块的扇出是指该模块直接调用的下级模块的个数。扇入大表示模块的复用程序高，扇出大表示模块的复杂度高。

　　(6)设计单入口和单出口的模块。

　　(7)模块的作用域应在控制域之内。模块的作用域是指受该模块内一个判定影响的所在模块的集合。模块的控制域是指该模块本身以及被该模块直接或间接调用的所有模块的集合。在设计时，作用域应是控制域的子集，作用域最好是做出判定的模块本身以及它的直属下级模块(直接调用的模块)。

　　(8)模块的功能应是可以预测的，功能可预测是指对相同的输入数据能产生相同的输出。

　　三、软件测试

　　在软件开发的一列活动中，为了保证软件的可靠性，人们研究并使用了很多方法进行分析、设计及编码实现。但是由于软件产品本身无形态，它是复杂的、知识高度密集的逻辑产品，其中不可能没有错误。物理产品在出厂前都要进行严格的检验，软件产品也不例外。软件开发总伴随着软件质量保证的活动，而软件测试是主要活动之一。软件测试代表了需求分析、设计、编码的最终复审。测试是一项很艰苦的工作，其工作量约占软件开发总工作量的40%以上，特别对一些关系到人的生命安全的软件，共测试成本可能相当于开发阶段总成本的3～5倍。

　　(一) 测试的基本概念

　　1.测试的目的

　　软件测试的目的是尽可能多地发现软件产品(主要是指程序)中的错误和缺陷。明确测试的目的是一件非常重要的事，因为在现实世界中对测试工作存在着许多模糊或者错误的看法，这些看法严重影响着测试工作的顺利进行。有人认为测试是为了证明程序是正确的，也就是说程序不再有错误，事实证明这是不现实的。因为要通过测试来发现程序中的所有错误就要穷举所有可能的输入数据，检查它们是否产生正确的结果。例如，一个需要3个16位字长的整型输入数据的程序，输入数据的所有组合情况大约有3×10 14 种，若每组数据的测试时间为1ms，那么即使一年365天，每天24小时地测试，也大约需要1万年的时间。

　　2.测试用例

　　要进行测试，除了要有测试数据(或称输入数据)外，还应同时给出该组测试数据应该得以怎样的输出结果，我们称它为预期结果。在测试时将实际的输出结果与预期结果比较，若不同则表示发现了错误，因此测试用例是由测试数据和预期结果构成的。为了发现程序中的错误，应竭力设计能暴露错误的测试用例。一个好的测试用例是极有可能发现迄今为止尚未发现的错误的测试用例。一次成功的测试是发现了至今为止尚未发现的错误的测试。

　　3.测试的原则

　　基于上述测试目的，我们可以考虑以下有关测试的原则:

　　(1)确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无预期结果，那么就不易判断测试结果是否正确。

　　(2)程序员应避免测试自己的程序，程序设计机构不应测试自己的程序。这是因为程序中的错误往往是由于程序员对问题说明的误解，由他来测试自己的程序就不易找出因这种误解而产生的错误。此外，开发程序是一项建设性的工作，而测试则是一项破坏性的工作(证明程序有错)，这对开发人员或机构来说在心理上是难以容忍的。为了证明自己的程序没有错误或错误很少，他们往往不去选择容易发现错误的测试用例，而选择容易通过的测试用例。当然，这并不意味着程序员都不能测试自己的程序，如单元测试通常就是由程序员自己测试的。

　　(3)彻底检查每个测试结果。如果不仔细检查测试结果，有些已经测试出来的错误也可能被遗漏掉。

　　(4)对非法的非预期的输入数据也要像合法的和预期的输入数据一样编写测试用例。

　　(5)检查程序是否做了应做的事是成功的一半，另一半是看程序是否做了不该做的事。

　　(6)除了真正没有用的程序外，一定不要扔掉测试用例。因为在改正错误或程序维护后还要进行重新测试。

　　(7)在规划测试时不要设想程序中不会查出错误。

　　(8)程序模块经测试后，残存的错误数目往往与已发现的错误数目成比例。实践证明，程序中的大量错误仅与少量的程序模块有关，因此当A模块找出的错误比B模块多得多时，很可能A模块残存的错误仍比B模块残存的错误多多。

　　4.白盒测试和黑盒测试

　　测试的关键是测试用例的设计，其方法可分成两类:白盒测试和黑盒测试。白盒测试是把程序看成装在一只透明的白盒子里，测试者完全了解程序结构和处理过程。它根据程序的内部逻辑来设计测试用例，检查程序中的逻辑通路是否都按预定的要求正确地工作。黑盒测试是把程序看成一只黑盒子，测试者完全不了解(或不考虑)程序的结构和处理过程。它根据规格说明书规定的功能来设计测试用例，检查程序的功能是否符合规格说明的要求。

　　(二) 测试步骤

　　软件测试的主要步骤有单元测试，集成测试和确认测试。

　　1.单元测试(unit testing)

　　单元测试也称模块测试。通常单元测试可放在编码阶段，程序员在编写好一个模块后，总会(也应该)对自己编写的模块进行测试，检查它是否实现了详细设计说明书中规定的模块功能 和算法。单元测试主要发现编码和详细设计中产生的错误，通常采用白盒测试。测试一个模块时需要编写一个驱动模块和若干个桩(stub)模块，如下图所示。驱动模块的功能是向被测试模块提供测试数据，驱动(即调用)被测模块，并从被测模块中接受测试结果。桩模块的功能是模拟被模块所调用的子模块，它接受被测模块的调用，检验调用参数，模拟被调用的子模块功能，把结果送回给被测模块。在模块结构图中，顶层模块测试时不需要驱动模块，最底层的模块测试时不需要桩模块。

　　2.集成测试(integration testing)

　　集成测试也称组装测试，它是对由各模块组装而成的程序进行测试，主要检查模块间的接口和通信。集成测试主要发现设计阶段产生的错误，通常采用黑盒测试。集成的方式可分成非渐增式集成和渐增式集成。非渐增式集成是先测试所有的模块，然后把这些模块集成在一起对整个程序进行测试。渐增式集成是将单元测试和集成测试合并在一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组合在一起对整个程序进行测试，每次增加一个模块，直至所有模块全部集成在程序中。渐增式集成又可分成自顶向下集成和自底向上集成。自顶向下集成先测试上层模块，再测试下层模块。由于测试下层模块时它的上层模块已测试过，所以可以用其上层模块作为它的驱动模块，而不必另编驱动模块。自底向上集成先测试下层模块，再测试上层模块。同样道理，在自底向上集成时可用下层模块作为上层模块的桩模块，而不必另外编写桩模块。

　　3.确认测试(walidation testing)

　　确认测试的任务是检查软件的功能、性能及其他特征是否与用户的需求一致，它是以需求规格说明书(即需求规约)作为依据的测试。确认测试通常采用黑盒测试。确认测试首先测试程序是否满足需求规格说明书所列的各项要求，然后要进行软件配置复查，特别是文档是否齐全，各方面的质量是否符合要求等。如果一个软件是为某个客户定制的，那么最后由客户来实施验收测试(acceptance testing)，以便客户确认该软件是否他所需要的。如果一个软件是作为产品被许多客户使用的话，那不可能为每个客户进行验收测试。大多数软件生产者使用一种Alpha测试和Beta测试的过程，来揭露仅由最终用户才能发现的错误。Alpha测试是在开发者的现场由客户来实施的，被测试的软件是在开发者从用户的角度进行常规设置的环境下运行的。Beat测试是在一个或多个客户的现场由该软件的最终用户实施的。与Alpha测试不同的是，Beat测试时开发者通常是不在场的。Alpha测试和Beat测试除了进一步发现程序中的错误外，还能发现使用上的问题。经过确认测试后的软件通常就可交付使用了。

　　(三) 白盒测试的测试用例设计

　　白盒测试是根据程序的内部逻辑来设计测试用例，常用的技术是逻辑覆盖，即考察用测试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有6种:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。为了提高测试的效率，应选择最少的测试用例来满足指定的覆盖标准。

　　1.语句覆盖

　　语句覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。

　　2.判定覆盖

　　判定覆盖又称为分支覆盖。它是指选择足够的测试用例，使得运行这些测试用例时，每个判定的所有可能结果至少出现一次(即判定的每个分支至少经过一次)。

　　3.条件覆盖

　　在软件设计过程中，一个判定往往由多个条件组成，判定覆盖仅考虑了判定的结果而没有考虑每个条件的可能结果。条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中的每个条件的所有可能结果至少出现一次。

　　4.判定/条件覆盖

　　判定/条件覆盖是指选择足够的测试用例。使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果至少出现一次。显然，满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖标准。在某些程序的测试中，如果选择得好，判定覆盖、条件覆盖和判定/条件覆盖可以使用相同的最少的测试用例。

　　5.条件组合覆盖

　　在条件覆盖中考虑了判定中每个条件的所有可能结果，但并未考虑条件的组合情况。条件组合覆盖是指选择足够的测试用例，使得运行这些测试用例时，每个判定中条件结果的所有可能组合至少出现一次。由于条件组合覆盖使每个判定中条件结果的所有可能组合都至少出现一次，因此判定本身的所有可能结果也一定至少出现一次，同时也使每个条件的所有可能结果至少出现一次。因此，条件组合覆盖是上述5种覆盖标准中最强的一种。然而，条件组合覆盖还不能保证程序中所有可能的路径都被覆盖。

　　6.路径覆盖

　　路径覆盖是指选择足够的测试用例，使得运行这些测试用例时，程序的每条可能执行到的路径都至少经过一次(如果程序中有环路，则要求每条环路至少经过一次)。路径覆盖实际上是考虑了程序中各种判定结果的所有可能组合，但它并未考虑判定中的条件结果的组合，因此它是一种比较强的覆盖标准，但并不能代替条件覆盖和条件组合覆盖。

　　(四) 黑盒测试的测试用例设计简介

　　黑盒测试是根据规格说明所规定的功能来设计测试用例，它不考虑程序中的内部结构和处理过程。常用的黑盒测试技术有等价类划分、边值分析、错误猜测等。

　　1.等价类划分

　　前面已经讲过，不能穷举所有可能的输入数据来进行测试，所以只能选取少量有代表性的输入数据，来揭露尽可能多的程序错误。这里首先要介绍一个有效的输入数据和无效的输入数据。有效的输入数据是指符合规格说明要求的合理的输入数据，它主要用来检验程序是否实现了规格说明中的功能。无效的输入数据是指不符合规格说明要求的不合理或非法的输入数据，它主要用来检验程序是否做了规格说明以外的事。如果把所有可能的输入数据(有效的和无效的)划分成若干个等价类，那么可以合理地做出假定:如果等价类中的一个输入数据能检测出一个错误，那么等价类中的其他输入数据也能检测出同一个错误;反之，如果一个输入数据不能检测出某个错误，那么等价类中其他输入数据也不能发现这一错误(除非这个等价类的某个子集还属于另一等价类)。等价类划分方法首先把输入数据划分成若干个有效等价类和若干个无效等价类，然后设计测试用例覆盖这些等价类。

　　2.边值分析

　　大量的实践说明，程序中在处理边界情况时出错的概率比较大，因此设计一些测试用例，使程序运行在边界情况附近，这样揭露程序中错误的可能性就更大。所谓边界条件是指相对于输入与输出等价类直接在其边界上，或稍高于其边界，或稍低于其边界的这些状态条件。使用等价类划分方法设计测试用例时，原则上讲，等价类中的任一输入数据都可作为该等价类的代表用作测试用例。而边值分析则是专门挑选那些位于边界附近的值作为测试用例。由于边值分析方法所设计的测试用例，更有可能发现程序中的错误，因此经常把边值分析方法与其他设计测试用例方法结合起来使用。

　　3.错误猜测

　　错误猜测是一种凭直觉和经验推测某些可能存在的错误，从而针对这些可能存在的错误设计测试用例的方法。这种方法没有机械的执行步骤，主要依靠直觉和经验。

　　四、软件维护

　　软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期，它是在软件交付使用后，为了改正软件中隐藏的错误，或者为了使软件适应新的环境，或者为了扩充和完善软件的功能或性能而修改软件的过程。一个软件的开发时间可能需要一两年，但它的使用时间可能要几年或几十年，而整个使用期都可能需要进行软件维护，所以软件维护的代价是很大的，而且维护的代价还在逐年上升，据1994年Software Engineering Encyclopedia记载，在整个软件生存周期所花费的代价中，20世纪80年代末用于软件维护的代价约为75%到90年代初为90%。因此，如何提高软件维护的效率、降低维护的代价成为十分重要的问题。

　　(一) 软件维护的分类

　　根据引用软件维护的原因，软件维护通常可分成改正性维护、适应性维护、完善性维护、预防性维护。

　　1.改正性维护

　　由于程序正确性证明尚未得到圆满的解决，软件测试又不可能找出程序中的所有错误，因此，在交付使用的软件中都可能隐藏着某些尚未被发现的错误，而这些错误在某种使用环境下会暴露出来。改正性维护就是在使用过程中发现了隐藏的错误后，为了诊断和改正这些隐藏错误而修改软件的活动。

　　2.适应性维护

　　由于计算机的发展非常迅速，新的机型、新的操作系统、新的软件系统不断地涌现，为了适应计算机的飞速发展，可能要更正在运行的软件的运行环境，如新的机型、数据库管理系统等。适应性维护就是为了适应变化了的环境而修改软件的活动。

　　3.完善性维护

　　用户在使用软件的过程中，随着业务的发展，常常希望扩充原有软件的功能，或者希望改进原有的功能或性能，以满足用户的新要求，完善性维护就是为了扩充或完善原有软件的功能或性能而修改软件的活动。

　　4.预防性维护

　　软件维护活动主要是上述三类维护，另有一类维护称为预防性维护，它是为了提高软件的可维护性和可靠性，为未来的进一步改进打下基础而修改软件的活动。据有关资料统计，在整个软件维护活动中，改正性维护约占20%，适应性维护约占25%，完善性维护约占50%以上，其他维护约占4%。

　　(二) 与软件维护有关的问题

　　软件维护人员通常不是该软件的开发人员，这给软件维护带来很大的困难，特别是有些软件在开发时没有遵循软件开发的准则，没有开发方法的支持，维护这样的软件就更困难。下面列举一些与软件维护有关的问题。

　　(1)要维护一个软件，首先要理解它。而理解别人的程序通常是非常困难的，尤其是对软件配置(指各种文档)不齐的软件，理解起来更为困难。

　　(2)需要维护的软件往往缺少合格的文档，或者文档资料不齐，甚至没有文档。在软件维护中，合格的文档十分重要，它有助于理解被维护的软件。合格的文档不仅要完整正确地反映开发过程各阶段的工作结果，而且应该容易理解并应程序源代码一致。而错误的文档会把对程序的理解引入歧途。

　　(3)在软件维护时，不要指望得到原来开发该软件的人员的帮助。开发人员开发完一个软件后，往往去从事另一软件的开发，甚至已调离开发单位。即使原先的开发人员还在，也可能因为相隔时间太久而遗忘了实现的细节。

　　(4)多数软件在设计时没有考虑今后的修改，给软件的修改带来困难，而且在修改软件时容易带来新的差错。对那些缺乏模块独立性和非结构化的程序来说，更是如此。

　　(5)软件维护通常不是一件吸引人的工作。从事维护工作常使维护人员感到缺乏成就感。这也严重影响维护工作。从而导致维护质量的不高。可以看出，上述的有些问题都与被维护的质量密切相关，所以在开发软件时，要认真写好各类文档，并且应注意提高软件的可维护性，这样可在很大程序上缓解软件维护的困难。

　　(三) 可维护性软件可维护性是指理解、改正、改动、改进软件的难易程度。通常影响软件可维护性的因素有可理解性、可测试性和可修改性。

　　1.可理解性

　　2.可测试性

　　可测试性是指测试和诊断软件(主要指程序)中错误的难易程度。测试主要是发现软件中的错误，而诊断错误的性质和出错的位置通常是调试的任务。提高软件可测试性的措施有:书写详细正确的文档，采用良好的程序结构，使用测试工具和调试工具，保存以前的测试过程和测试用例等等。

　　3.可修改性

　　可修改性是指修改软件(主要指程序)的难易程度。在修改程序时经常会发生这样的情况:修改程序中某个错误的同时又产生新的错误(由程序的修改引起的)，或者在程序中增加了某个功能的同时，原先的某些功能不能正常执行。这主要是因为程序中各成分之间存在着许多联系，当程序中某处修改时，这个修改可能会影响到程序的其他部分。如果修改程序时稍有考虑不周，就会出现上述顾此失彼的情况。因此，如果一处修改所涉及到的范围越少，发生上述情况的概率也越小，其可修改性也越好。在软件设计中我们介绍的那些设计准则都是影响可修改性的因素，如信息隐蔽原则、模块独立、模块间联系的低耦合高内聚等等。

　　(四) 软件维护活动流程

　　凡是需要软件维护，都应有一个软件维护的申请报告。改正性维护的申请报告应完整地描述导致错误的环境，包括输入数据、错误清单以及有关的材料。适应性维护或完善性维护的申请报告应提供一份简短的需求说明书。维护申请书由维护管理员和系统管理员审批。并指明所需修改的性质，申请修改的优先级，所需的工作量等。维护活动的第一步是确定维护的类型，若是改正性维护，则要估计错误的严重程度，对严重的错误，则马上分派人员执行维护任务;对不严重的错误，则可将其暂时保存，在以后适当时候再进行改正。若是适应性维护或完善性维护，则要根据其优先级来决定维护的先后次序，优先级高的维护则马上开始;优先级低的可暂时保存，以便统筹安排。适应性维护或完善性维护的过程相当于一个小的开发过程，它同样要经历需求分析、设计、编码、测试等阶段。不管是哪种维护，有些工作是每种维护活动都必须做的，如在修改程序代码的同时还要修改(如有必要)相应的需求说明文档、设计文档等，还要进行回归测试和软件配置复审等。

　　五、软件管理

　　软件工程项目高质量高效率的完成与其他产品的工程项目一样，不仅取决于所采用的技术、方法和工具，还决定于管理的好坏。两者相辅相成，缺一不可。就目前软件开发中的问题，更多的是管理问题。本节将集中讨论与管理方面有关的问题。

　　(一) 确定工作范围和资源

　　1.软件工作范围

　　软件计划的第一个任务就是确定软件的工作范围，即软件的用途及对软件的要求。其中主要包括软件的功能、性能、接口和可靠性等四个方面。计划人员必须使用管理人员和技术人员都能理解的无二义性的语言来描述工作范围。对于软件功能的要求，在某些情况下要进行求精细化，以便能够提供更多的细节，因为成本和进度的估算都与功能有关。软件的性能包括处理时间的约束、存储限制以及依赖于机器的某些特性。要同时考虑功能和性能，才能做出正确的估计。接口又可分为硬件、软件和人三类:

　　(1)硬件指执行该软件的硬件，如中央处理机和外部设备，以及由该软件控制的各种间接设备，如各种机器和显示设备等;

　　(2)软件指已有的而且必须与新开发软件连接的软件，如数据库、子程序包和操作系统等;

　　(3)人指通过终端或输入/输出设备使用该软件的操作人员。在这三种情况下，都要详细地了解通过接口的信息传递。计划人员还必须考虑各个接口的性质及复杂程度，以确定对开发资源、成本和进度的各种影响。

　　2.资源

　　(1)人员软件危机中提出的最严重的问题是缺少有经验的软件人员，人是软件开发的主要资源。这里所讨论的不是小项目，而是大项目，1、2个人是干不了的。在大项目的软件开发中，人员尤其重要。软件工程各个阶段对人员有不同的要求。开始时管理人员要用较多的精力，因为作为管理人员的决策，这时是很关键的，最后验收时也要投入较多的精力。高级技术人员同样如此。初级技术人员前期工作不多，在详细设计、编码和早期测试中参与最多，单元测试时为高峰。

　　(2)硬件硬件也是一种软件开发工具。硬件资源包括:

　　①宿主机宿主机是指在软件开发阶段使用的计算机和有关外部设备。对于一些专门的开发机构，为了能够接受更多的用户任务，并能方便地使用多种类型的开发支持工具，常备有专门的开发系统。目前很多微机都设置有单独的开发系统，而且进一步发展为专用的软件开发环境，这一部分将在第9章讨论。

　　②目标机运行所开发软件的计算机叫目标机，其中也包括有关的外部设备，在很多情况下，宿主机与目标机是统一的。

　　③其他硬件设备在进行专用软件的开发时，有时需要某些特殊的硬件资源，如开发过程控制软件时所需的A/D、D/A等专用设备。

　　(3)软件和硬件一样，也是一种软件开发工具。软件资源包括:

　　①支持软件包括范围广泛的各种工具。最基础的支持软件是操作系统、编译程序、数据库、图形包和网络软件等。它们是开发人员的必备工具。在软件生存期的各阶段还要有其它相应的支持软件:在需求分析阶段，有需求分析和生成程序;在设计阶段，有设计语言处理程序、流程图/框图生成程序和模拟程序;在编码和单元测试阶段，有动态调试程序、交叉汇编程序/编译程序和宏处理程序;在测试阶段，有测试驱动程序和测试结果分析程序等。恰当地使用支持软件，可以大大地提高软件开发的生产率和软件的质量。但是为了使支持软件能够在开发系统上运行，需要很大的工作量和费用，所以在考虑支持软件时，成本和效益两者之间的关系是一个必须考虑的重要问题。

　　②实用软件相当于软件库，可以结合到新的系统中去，如各种标准子程序等。实用软件现在应该说是非常丰富的，这是重用技术的基础。但重用技术的问题是如何选择重用对象、分类、建库，以及解决通用接口的机制问题，使其能适用于任一硬、软件环境。实用软件作为资源时，计划人员应认识到:如果现有软件符合要求，那么利用实用软件的费用几乎总是小于开发同等软件所需的费用;如果在与系统结合起来之前需要作某些修改，那就必须特别小心，因为修改现有软件所需费用有时会大于开发同等软件的费用。一般在计划阶段，软件资源常常被忽视，只有在开发阶段才成为头等大事。若能够及时地确定对软件资源的要求，则可以较好地对各种方案进行技术评价，并能尽早地获得所需的方案。

　　(二)成本估算

　　为了使开发项目能够在规定的时间内完成，而且不超过预算，成本估算的管理控制是关键。计算机广泛使用有35年，而高级语言应用仅30年。费用估算大约开始于50年代的第一个大型程序设计，60年代估算过于乐观，结果费用大大超支，70年代以后，费用估算才引起人们的普遍重视。由于影响软件成本的因素太多(如人、技术、环境以及政治因素等)，直到最近，软件成本估算仍是一门很不成熟的技术，国外已有的技术只能作为我们的借鉴。

　　1.成本估算方法

　　有两种基本的估算方法:自顶向下和自底向上。自顶向下的方法是对整个项目的总开发时间和总工作量做出估算，然后把它们按阶段、步骤和工作单元进行分配。自底向上的方法则正好相反，分别估算各工作单元所需的工作量和开发时间，然后相加，就得出总的工作量和总的开发时间。两种方法都要求采用某种方法做出估算。有许多现成的方法可以利用，大致可分为三类:

　　(1)专家估算法;

　　(2)类推估算法;

　　(3)算式估算法。

　　(1)专家估算法这种方法依靠一个或多个专家，对要求

　　的项目做出估计，其精确性主要取决于两点，即专家对估算项目的定性参数的了解和他们的经验。后者类似于类推估算法。

　　(2)类推估算法自顶向下的方法中，类推估算法是将估算项目的总体参数与类似项目进行直接相比得到结果。自底向上的方法中，类推是在两个具有相似条件的工作单元之间进行。

　　(3)算式估算法专家估算法和类推估算法的缺点在于，它们依靠带有一定盲目性的和主观的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响。用于估算的算式方法有两种基本类型:(1)由理论导出;(2)由经验得出。

　　2.成本估算模型

　　(1)IBM模型1977年Walston和Felix总结了IBM联合系统分部(FSD)负责的60个项目的数据。其中源代码从400到467000行，工作量从12到11758人-月，共使用29种不同语言和66种计算机。

　　(2)SLIM模型1979年前后，Putnam在软件开发生存期雷利(Rayleigh)曲线模型的基础上提出SLIM商业化的成本估算模型，SLIM基本估算算式为L=C k K 1/3 t 4/3d 其中:L和t d 分别表示可交付的源指令数和开发时间(单位以年计);K是整个生存期内人的工作量(单位以人一年计)，可从总的开发工作量ED=0.4K求得;C k 是根据经验数据确定的常数，表示了开发技术的先进性级别。如果软件开发环境较差(没有一定的开发方法，缺少文档和评审或批处理方式)，取C k =6500;正常的开发环境(有适当的开发方法，较好的文档和评审，以及交互式的执行方式)，C k =10000;而一个较好的开发环境(自动工具和技术)，则取C k =12500。交换上式，可得开发工作量算式 K=L 3 C 3k t 4d 可从美国或英国买到SLIM计算程序，它除了提供开发时间和成本估算外，还提供关于风险、可行性、估算CPU时间需求及项目计划中其它有关信息。