软件工程-实践者的研究方法讲义_第二十章软件项目估算ppt课件

1、软件工程第20章 软件工程估算主要内容对估算的察看工程谋划过程软件范围和可行性资源软件工程估算分解技术阅历估算模型面向对象工程的估算小结估算软件的真实需求曾经确定；共利益者们都已就绪；软件工程师预备开场；工程将要启动。但是如何进展下去呢？软件工程方案包括五项主要活动估算、进度安排、风险分析、质量管理方案和变卦管理方案。本章思索估算尝试确定构造一个特定的基于软件的系统或产品所需求破费的资金、任务量、资源及时间。估算软件工程经理利用从共利益者和软件工程师那里获得的信息以及从以往工程搜集的软件度量数据。估算首先要描画产品的范围。然后，将问题分解为一组较小的问题，再以历史数据和阅历为指南，对每个小问题

2、进展估算。在进展最终的估算之前，要思索问题的复杂度和风险。任务产品是生成一个简单的表，描画要完成的义务、要实现的功能，以及完成每一项所需的本钱、任务量和时间。估算 假设有阅历并遵照系统化的方法，运用可靠的历史数据进展估算，利用至少两种不同的方法创建估算数据点，制定现实的进度表并随着工程的进展不断进展调整，那么可以确信曾经为工程做了最好的估算。估算软件工程管理从一组统称为工程谋划的活动开场。在工程可以开场前，工程经理和软件团队必需估算将要完成的任务、所需的资源，以及从开场到完成所需求的时间。这些活动一旦完成，软件团队就要制定工程进度方案。在工程进度方案中，要定义软件工程义务及里程碑，确定每一项义

3、务的担任人，详细指明对工程进展影响很大的义务间的相互依赖关系。估算很多技术任务者宁愿从事技术任务，而不愿破费时间制定方案。很多技术管理者没有接受过充分的技术管理方面的培训，对他们的方案可以改善工程成果缺乏自信心。这两部分人都不想制定方案，因此就经常不制定方案。但是没有很好地制定方案是一个工程犯的最严重的错误之一有效的方案是必需的，可以在上游以较低的本钱处理问题，而不是在下游以较高本钱处理问题。普通的工程要将80%的时间破费在返工上矫正在工程早期所犯的错误。对估算的察看估算是一门艺术，更是一门科学，这项重要的活动不能以随意的方式来进展。如今曾经有了估算时间和任务量的适用技术。过程度量和工程度量为

4、定量估算从历史角度提供了根据和有效的输入。当建立估算和评审估算时，过去阅历的辅助作用是不可估量的。由于估算是一切其他工程谋划活动的根底，而且工程方案又提供了通往胜利的软件工程的道路图。因此，没有估算就着手开发，将堕入盲目性。对估算的察看对软件工程任务的资源、本钱及进度进展估算时，需求阅历，需求了解有用的历史信息，还要有当只存在定性的信息时进展定量预言的勇气。估算具有与生俱来的风险，正是这种风险导致了不确定性。历史信息的有效性对估算的风险有很大影响。经过回想过去，可以仿效做过的任务，并改良出现问题的地方。假设能获得对以往工程的全面的软件度量，做估算就会有更大的保证，合理安排进度以防止重走过去的弯

5、路，总体风险也会降低。对估算的察看估算的风险取决于对资源、本钱及进度的定量估算中存在的不确定性。假设对工程范围不太了解，或者工程需求经常改动，不确定性和估算风险就会非常高。方案人员，尤其是客户，都应该认识到经常改动软件需求意味着在本钱和进度上的不稳定性。工程谋划过程软件工程谋划的目的是提供一个能使管理人员对资源、本钱及进度做出合理估算的框架。此外，估算应该尝试定义“最好的情况和“最坏的情况，使工程的结果可以限制在一定范围内。工程方案是在方案义务中创建的，虽然它具有与生俱来的不确定性，软件团队还是要根据它着手开发。因此，随着工程的进展，必需不断地对方案进展调整和更新。软件范围和可行性软件范围描画

6、了将要交付给最终用户的功能和特性、输入和输出的数据、运用软件时要呈现给用户的“内容，以及界定系统的性能、约束条件、接口和可靠性。定义范围可以运用两种方法： 1、在与一切共利益者交流之后，写出对软件范围的表达性描画。 2、由最终用户开发一组用例。软件范围和可行性在开场估算之前，首先要对范围陈说中描画的功能进展评价，在某些情况下，还要进展细化，以提供更多的细节。由于本钱和进度的估算都是面向功能的，因此某种程度上的功能分解经常是有用的。性能方面的思索包括处置时间和呼应时间的需求。约束条件那么标识了外部硬件、可用存储，或其他现有系统对软件的限制。软件范围和可行性一旦确定了软件范围，人们自然会问：我们可

7、以开发出满足范围要求的软件吗？这个工程可行吗？软件工程师经常匆忙越过这些问题，不料竟会一开场就注定要堕入这个工程的泥潭中。资源工程谋划的第二个义务是对完成软件开发任务所需的资源进展估算。图20-1描画了三类主要的软件工程资源人员、可复用的软件构件及开发环境。对每一类资源，都要阐明以下四个特征：资源的描画、可用性阐明、何时需求资源、运用资源的继续时间。最后两个特性可以看成是时间窗口。对于一个特定的时间窗口，必需在开发初期就建立资源的可用性。资源图20-1 工程资源人力资源方案人员首先评价软件范围，并选择完成开发所需的技艺，还要指定组织中的职位和专业。对于一些比较小的工程，只需向专家做些咨询，也许

8、一个人就可以完成一切的软件工程义务。而对于一些较大的工程，软件团队的成员能够分散在很多不同的地方，因此，要详细阐明每个人所处的位置。只需在估算出开发任务量后，才干确定软件工程需求的人员数量。可复用软件资源基于构件的软件工程强调可复用性，即创建并复用软件构造块，这种构造块通常被称为构件。为了容易援用，必需对这些构件进展分类；为了容易运用，必需使这些构件规范化；为了容易集成，必需对这些构件进展确认。可复用软件资源BEN92建议在制定方案时应该思索以下四种软件资源。废品构件：可以从第三方获得，或在以前的工程中曾经进展过内部开发的已有软件。具有完全阅历的构件：为以前工程开发的，与当前工程要构造的软件类

9、似的已有的规格阐明、设计、代码或测试数据。具有部分阅历的构件：为以前工程开发的，与当前工程要构造的软件有关的已有的规格阐明、设计、代码或测试数据，但是需求做本质上的修正。新构件：软件团队为了满足当前工程的特定需求，而必需专门开发的软件构件。可复用软件资源具有挖苦意味的是，在谋划阶段，人们往往忽视可复用软件构件，直到软件过程的开发阶段，它才变成最重要的关注对象。最好是尽早确定软件资源的需求，这样才干对各种候选方案进展技术评价，并及时获取所需的构件。环境资源支持软件工程的环境，通常称为软件工程环境SEE，它集成了硬件和软件。硬件提供了支持工具的平台，这些工具是采用良好的软件工程实际来获得任务产品所

10、必需的。由于在大多数软件组织中，有很多人都需求运用SEE，因此，工程方案人员必需详细规定需求硬件和软件的时间窗口，并且验证这些资源是可用的。软件工程估算几乎在一切基于计算机的系统中，软件都是最昂贵的万分。对于复杂的定制的系统，假设本钱估算误差很大，就会使赢利变成亏损。对于开发者来说，本钱超支能够是灾难性的。软件工程估算为得出可靠的本钱和任务量估算，有很多项选择择：1.把估算推迟到工程的后期进展。2.根据曾经完成的类似工程进展估算。3.运用比较简单的分解技术，生成工程的本钱和任务量估算。4.运用一个或多个阅历模型来进展软件本钱和任务量的估算。每种可行的软件本钱估算方法，其效果的好坏取决于估算运用

11、的历史数据。假设没有历史数据，本钱估算也就建立在一个很不稳定的根底上。分解技术软件工程估算是一种处理问题的方式，在多数情况下，要处理的问题非常复杂，不能作为一个整体思索。因此，要对问题进展分解，把它分解成一组较小的问题，再定义它们的特性。软件规模估算软件工程估算的准确性取决于许多要素：(1)方案人员估算待开发产品规模的正确程度;(2)把规模估算转换成人员任务量、时间及本钱的才干;(3)工程方案反映软件团队才干的程度;(4)产品需求的稳定性和支持软件工程任务的环境。思索软件规模的估算问题。由于工程估算的准确程度取决于待完成任务的规模估算，因此，规模估算是工程方案人员面临的第一个主要挑战。在工程方

12、案中，规模是指软件工程的可量化的结果。假设采用直接的方法，规模可以用代码行(LOC)来丈量。假设选择间接的方法，规模可以用功能点(FP)来表示。软件规模估算PUT92建议运用四种不同的方法来估算规模问题：模糊逻辑法。运用这种方法，方案人员必需先确定运用的类型，定性地确定其量级，然后在初始范围内再细化该量级。功能点法。方案人员对信息域的特性进展估算。规范构件法。软件是由许多不同的“规范构件组成的，对于某个特定的运用领域而言，这些构件是通用的。工程方案人员估算每个规范构件出现的次数，然后运用历史工程数据来确定每个规范构件交付时的规模。修正法。当工程要运用已有的软件作为工程的一部分，并且该软件必需做

13、某些方面的修正时，可以运用这种方法。方案人员要估算必需完成的修正的数量和类型。基于问题的估算在前述章节中，曾经描画了LOC和FP丈量，从中可以计算出消费率度量。在软件工程估算中，LOC和FP数据被用于两个方面：(1)作为估算变量，用于度量软件中每个元素的规模；(2)作为基线度量，这些度量数据是从以前的工程中搜集起来的，将它们与估算变量结合运用，进展本钱和任务量的估算。基于问题的估算LOC估算和FP估算是两种不同的估算技术，但两者有很多共同的特性。工程方案人员从界定的软件范围陈说入手。根据该陈说将软件分解成一些可分别独立进展估算的功能问题。然后，估算每个功能的LOC或FP。方案人员也可以选择其他

14、元素进展规模估算，如类或对象、变卦、受影响的业务过程。基于问题的估算然后，将基线消费率度量运用于适当的估算变量中，导出每个功能的本钱或任务量。将一切功能的估算合并起来，即可产生整个工程的总体估算。对于一个组织而言，其消费率度量经常是变化的，运用单一的基线消费率度量是不可信的。普通情况下，平均的LOC/pm或FP/pm应该根据工程领域来计算。当估算一个新工程时，首先应将该工程对应到某个领域中，然后，再运用恰当的领域消费率平均值对其进展估算。基于问题的估算不论运用哪一种估算变量，工程方案人员都要首先为每个功能或每个信息域值确定一个估算值的范围。利用历史数据或凭直觉，方案人员为每个功能或每个信息域的

15、计数值都分别估算出一个乐观的、能够的和悲观的规模值。当确定了值的范围后，就得到了一个不确定程度的隐含目的。基于问题的估算接着，计算三点(估算值)或期望值。能够经过乐观值(Sopt)、能够值(Sm)和悲观值(Spess)估算的加权平均值来计算估算变量(规模)的期望值S: S=(Sopt+4Sm+Spess)/6一旦确定了估算变量的期望值，就可以运用历史的LOC或FP消费率数据。任何估算技术，不论它有多先进，都必需与其他方法进展交叉检查。基于LOC估算的实例调查一个为机械零件计算机辅助设计运用而开发的软件包。P354-355图20-2 LOC方法的估算表基于FP估算的实例基于FP估算时，问题分解关

16、注的不是软件功能，而是信息域的值。工程方案人员分别对软件的外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件进展估算。图20-3 估算信息域的值基于FP估算的实例估算出复杂度加权因子，并计算出复杂度校正因子。最后得出FP的值：FPestimated=总计0.65+0.01(Fi)基于过程的估算最通用的工程估算技术是根据将要采用的过程进展估算。即，将过程分解为一组较小的义务，并估算完成每个义务所需的任务量。同基于问题的估算技术一样，基于过程的估算首先从工程范围中抽取出软件功能。接着给出为实现每个功能所必需执行的一系列的框架活动。这些功能和相关的框架活动可用表格方式给出，如图20-4所示。基

17、于过程的估算图20-4 基于过程的估算表基于过程的估算一旦将问题功能与过程活动结合起来，方案人员就可以针对每个软件功能，估算完成各个软件过程活动所需的任务量，这些数据写在图的中心部分。然后，将平均劳动力价钱运用于每个软件过程活动的估算任务量，就可以估算出本钱。但各项义务的劳动力价钱能够是不同的。基于过程的估算最后一个步骤就是计算每一个功能及框架活动的本钱和任务量。假设基于过程的估算是不依赖LOC或FP估算而实现的，如今就曾经有了两组或三组本钱与任务量的估算，可以进展比较、调和。假设两组估算非常一致，那么有理由置信估算是可靠的。反过来，假设这些分解技术得到的结果不一致，那么必需做进一步的调查和分

18、析。基于过程估算的实例参看图20-4所示的在于过程的估算表，表中对CAD软件的每个功能，都给出了其各个软件工程活动的任务量估算(人月)。其中，工程和构造发布活动又被细分成表中所示的主要软件工程义务。对客户沟通、谋划和风险分析活动，还给出了总任务量的估算。假设需求的话，每一个框架活动或软件工程义务都可以采用不同的劳动力价钱，分别进展计算。基于用例的估算由于以下缘由，建立基于用例的估算方法还有困难：描画用例时，可以采用多种格式和风格没有规范方式。用例表现的是软件的外部视图，经常在不同的笼统级别上建立。用例没有标识出它所描画的功能和特性的复杂性。用例没有描画出涉及很多功能和特性的复杂行为。与LOC或

19、FP不同，一个角色的“用例能够需求数月的任务量，而另一个角色的“用例能够在一到两天内就能完成。调和不同的估算方法必需对多种估算方法进展调和，以得到对任务量、工程继续时间或本钱的一致估算。假设不同估算之间的差别很大，普通可以追溯到以下两个缘由之一：方案人员没有充分了解或误解了工程范围。在基于问题的估算技术中所运用的消费率数据不适宜本运用系统，过时了，或者是误用了。方案人员必需确定产生差别的缘由，再来调和估算结果。阅历估算模型计算机软件估算模型运用由阅历导出的公式来预测任务量，任务量是LOC或FP的函数，将LOC或FP的结果值代入到估算模型中。用以支持大多数估算模型的阅历数据都是从有限的工程样本中

20、得出的。因此，还没有一种估算模型可以适用于一切的软件类型和开发环境。从这些模型中得到的结果必需慎重运用。应该对估算模型进展调整，以反映当前工程的情况。应该运用从已完成工程中搜集的数据对该模型进展检验方法是将数据代入到模型中，然后将实践结果与预测结果进展比较。假设两者一致性很差，那么在运用该模型前，必需对其进展调整和再次检验。估算模型的构造典型的估算模型是经过回归分析从以往软件工程搜集到的数据而得到的。这种模型的总体构造表现为下面的方式： E=A+B(Ev)C其中，A、B、C是阅历常数，E是任务量，Ev是估算变量LOC或FP。除了上式所表示的关系外，大多数估算模型都有某种方式的工程调整成分，使得

21、E可以根据其他的工程特性加以调整。COCOMO II模型COCOMO II模型是一种层次构造的估算模型，主要运用于以下领域：运用组装模型。在软件工程的早期阶段运用，这时，用户界面的原型开发、对软件和系统交互的思索、性能的评价以及技术成熟度的评价是最重要的。早期设计阶段模型。在需求曾经稳定并且根本的软件体系构造曾经建立时运用。体系构造后阶段模型。在软件的构造过程中运用。COCOMO II模型和一切的软件估算模型一样，COCOMO II模型也需求运用规模估算信息，在模型层次构造中有三种不同的规模估算选项：对象点、功能点和源代码行。COCOMO II模型COCOMO II运用组装模型运用的是对象点一种间接的软件丈量，计算对象点时，运用如下的计数值：(1)(用户界面)屏幕数，(2)报表数，(3)构造运用能够需求的构件数。将每个对象实例归类到三个复杂度级别之一即简单的、中等的或困难的。本质上，复杂度是以下变量的函数：客户和效力器数据表的数量和来源，以及视图或版面的数量。COCOMO II模型一旦确定了复杂度，就可以根据图20-6对屏幕、报表和构件的数量进展加权。首先将初始的对象实例数与表中的加权因子相乘就确定了对象点数，求和后就得到了总的对象点数。当采用基于构件的开发或普通的软件复用时，还要估算复用的百分比，并调整对象点数： NOP=对象点(1