软件工程估算.ppt

《软件工程估算.ppt》由会员分享，可在线阅读，更多相关《软件工程估算.ppt（55页珍藏版）》请在课桌文档上搜索。

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

2、小问题进行估算。在进行最终的估算之前，要考虑问题的复杂度和风险。工作产品是生成一个简单的表，描述要完成的任务、要实现的功能，以及完成每一项所需的成本、工作量和时间。,估算,如果有经验并遵循系统化的方法，使用可靠的历史数据进行估算，利用至少两种不同的方法创建估算数据点，制定现实的进度表并随着项目的进展不断进行调整，则可以确信已经为项目做了最好的估算。,估算,软件项目管理从一组统称为项目策划的活动开始。在项目可以开始前，项目经理和软件团队必须估算将要完成的工作、所需的资源，以及从开始到完成所需要的时间。这些活动一旦完成，软件团队就要制定项目进度计划。在项目进度计划中，要定义软件工程任务及里程碑，确

3、定每一项任务的负责人，详细指明对项目进展影响很大的任务间的相互依赖关系。,估算,很多技术工作者宁愿从事技术工作，而不愿花费时间制定计划。很多技术管理者没有接受过充分的技术管理方面的培训，对他们的计划能够改善项目成果缺乏信心。这两部分人都不想制定计划，因此就经常不制定计划。但是没有很好地制定计划是一个项目犯的最严重的错误之一有效的计划是必需的，可以在上游以较低的成本解决问题，而不是在下游以较高成本解决问题。一般的项目要将80%的时间花费在返工上改正在项目早期所犯的错误。,对估算的观察,估算是一门艺术，更是一门科学，这项重要的活动不能以随意的方式来进行。现在已经有了估算时间和工作量的实用技术。过程

4、度量和项目度量为定量估算从历史角度提供了依据和有效的输入。当建立估算和评审估算时，过去经验的辅助作用是不可估量的。由于估算是所有其他项目策划活动的基础，而且项目计划又提供了通往成功的软件工程的路线图。因此，没有估算就着手开发，将陷入盲目性。,对估算的观察,对软件工程工作的资源、成本及进度进行估算时，需要经验，需要了解有用的历史信息，还要有当只存在定性的信息时进行定量预言的勇气。估算具有与生俱来的风险，正是这种风险导致了不确定性。历史信息的有效性对估算的风险有很大影响。通过回顾过去，能够仿效做过的工作，并改进出现问题的地方。如果能取得对以往项目的全面的软件度量，做估算就会有更大的保证，合理安排进

5、度以避免重走过去的弯路，总体风险也会降低。,对估算的观察,估算的风险取决于对资源、成本及进度的定量估算中存在的不确定性。如果对项目范围不太了解，或者项目需求经常改变，不确定性和估算风险就会非常高。计划人员，尤其是客户，都应该认识到经常改变软件需求意味着在成本和进度上的不稳定性。,项目策划过程,软件项目策划的目标是提供一个能使管理人员对资源、成本及进度做出合理估算的框架。此外，估算应该尝试定义“最好的情况”和“最坏的情况”，使项目的结果能够限制在一定范围内。项目计划是在计划任务中创建的，尽管它具有与生俱来的不确定性，软件团队还是要根据它着手开发。因此，随着项目的进展，必须不断地对计划进行调整和更

6、新。,软件范围和可行性,软件范围描述了将要交付给最终用户的功能和特性、输入和输出的数据、使用软件时要呈现给用户的“内容”，以及界定系统的性能、约束条件、接口和可靠性。定义范围可以使用两种方法：1、在与所有共利益者交流之后，写出对软件范围的叙述性描述。2、由最终用户开发一组用例。,软件范围和可行性,在开始估算之前，首先要对范围陈述中描述的功能进行评估，在某些情况下，还要进行细化，以提供更多的细节。由于成本和进度的估算都是面向功能的，因此某种程度上的功能分解常常是有用的。性能方面的考虑包括处理时间和响应时间的需求。约束条件则标识了外部硬件、可用存储，或其他现有系统对软件的限制。,软件范围和可行性,

7、一旦确定了软件范围，人们自然会问：我们能够开发出满足范围要求的软件吗？这个项目可行吗？软件工程师常常匆忙越过这些问题，不料竟会一开始就注定要陷入这个项目的泥潭中。,资源,项目策划的第二个任务是对完成软件开发工作所需的资源进行估算。图17-1描述了三类主要的软件工程资源人员、可复用的软件构件及开发环境。对每一类资源，都要说明以下四个特征：资源的描述、可用性说明、何时需要资源、使用资源的持续时间。最后两个特性可以看成是时间窗口。对于一个特定的时间窗口，必须在开发初期就建立资源的可用性。,资源,图17-1 项目资源,人力资源,计划人员首先评估软件范围，并选择完成开发所需的技能，还要指定组织中的职位和

8、专业。对于一些比较小的项目，只要向专家做些咨询，也许一个人就可以完成所有的软件工程任务。而对于一些较大的项目，软件团队的成员可能分散在很多不同的地方，因此，要详细说明每个人所处的位置。只有在估算出开发工作量后，才能确定软件项目需要的人员数量。,可复用软件资源,基于构件的软件工程强调可复用性，即创建并复用软件构造块，这种构造块通常被称为构件。为了容易引用，必须对这些构件进行分类；为了容易应用，必须使这些构件标准化；为了容易集成，必须对这些构件进行确认。,可复用软件资源,BEN92建议在制定计划时应该考虑以下四种软件资源。成品构件：能够从第三方获得，或在以前的项目中已经进行过内部开发的已有软件。具

9、有完全经验的构件：为以前项目开发的，与当前项目要构造的软件相似的已有的规格说明、设计、代码或测试数据。具有部分经验的构件：为以前项目开发的，与当前项目要构造的软件有关的已有的规格说明、设计、代码或测试数据，但是需要做实质上的修改。新构件：软件团队为了满足当前项目的特定需要，而必须专门开发的软件构件。,可复用软件资源,具有讽刺意味的是，在策划阶段，人们往往忽视可复用软件构件，直到软件过程的开发阶段，它才变成最重要的关注对象。最好是尽早确定软件资源的需求，这样才能对各种候选方案进行技术评估，并及时获取所需的构件。,环境资源,支持软件项目的环境，通常称为软件工程环境（SEE），它集成了硬件和软件。硬

10、件提供了支持工具的平台，这些工具是采用良好的软件工程实践来获得工作产品所必需的。因为在大多数软件组织中，有很多人都需要使用SEE，因此，项目计划人员必须详细规定需要硬件和软件的时间窗口，并且验证这些资源是可用的。,软件项目估算,几乎在所有基于计算机的系统中，软件都是最昂贵的万分。对于复杂的定制的系统，如果成本估算误差很大，就会使赢利变成亏损。对于开发者来说，成本超支可能是灾难性的。,软件项目估算,为得出可靠的成本和工作量估算，有很多选择：1.把估算推迟到项目的后期进行。2.根据已经完成的类似项目进行估算。3.使用比较简单的分解技术，生成项目的成本和工作量估算。4.使用一个或多个经验模型来进行软

11、件成本和工作量的估算。每种可行的软件成本估算方法，其效果的好坏取决于估算使用的历史数据。如果没有历史数据，成本估算也就建立在一个很不稳定的基础上。,分解技术,软件项目估算是一种解决问题的形式，在多数情况下，要解决的问题非常复杂，不能作为一个整体考虑。因此，要对问题进行分解，把它分解成一组较小的问题，再定义它们的特性。,软件规模估算,软件项目估算的准确性取决于许多因素：(1)计划人员估算待开发产品规模的正确程度;(2)把规模估算转换成人员工作量、时间及成本的能力;(3)项目计划反映软件团队能力的程度;(4)产品需求的稳定性和支持软件工程工作的环境。考虑软件规模的估算问题。由于项目估算的准确程度取

12、决于待完成工作的规模估算，因此，规模估算是项目计划人员面临的第一个主要挑战。在项目计划中，规模是指软件项目的可量化的结果。如果采用直接的方法，规模可以用代码行(LOC)来测量。如果选择间接的方法，规模可以用功能点(FP)来表示。,软件规模估算,PUT92建议使用四种不同的方法来估算规模问题：模糊逻辑法。使用这种方法，计划人员必须先确定应用的类型，定性地确定其量级，然后在初始范围内再细化该量级。功能点法。计划人员对信息域的特性进行估算。标准构件法。软件是由许多不同的“标准构件”组成的，对于某个特定的应用领域而言，这些构件是通用的。项目计划人员估算每个标准构件出现的次数，然后使用历史项目数据来确定

13、每个标准构件交付时的规模。修改法。当项目要使用已有的软件作为项目的一部分，并且该软件必须做某些方面的修改时，可以使用这种方法。计划人员要估算必须完成的修改的数量和类型。,基于问题的估算,第16章中，已经描述了LOC和FP测量，从中可以计算出生产率度量。在软件项目估算中，LOC和FP数据被用于两个方面：(1)作为估算变量，用于度量软件中每个元素的规模；(2)作为基线度量，这些度量数据是从以前的项目中收集起来的，将它们与估算变量联合使用，进行成本和工作量的估算。,基于问题的估算,LOC估算和FP估算是两种不同的估算技术，但两者有很多共同的特性。项目计划人员从界定的软件范围陈述入手。根据该陈述将软件

14、分解成一些可分别独立进行估算的功能问题。然后，估算每个功能的LOC或FP。计划人员也可以选择其他元素进行规模估算，如类或对象、变更、受影响的业务过程。,基于问题的估算,然后，将基线生产率度量应用于适当的估算变量中，导出每个功能的成本或工作量。将所有功能的估算合并起来，即可产生整个项目的总体估算。对于一个组织而言，其生产率度量常常是变化的，使用单一的基线生产率度量是不可信的。一般情况下，平均的LOC/pm或FP/pm应该根据项目领域来计算。当估算一个新项目时，首先应将该项目对应到某个领域中，然后，再使用恰当的领域生产率平均值对其进行估算。,基于问题的估算,不管使用哪一种估算变量，项目计划人员都要

15、首先为每个功能或每个信息域值确定一个估算值的范围。利用历史数据或凭直觉，计划人员为每个功能或每个信息域的计数值都分别估算出一个乐观的、可能的和悲观的规模值。当确定了值的范围后，就得到了一个不确定程度的隐含指标。,基于问题的估算,接着，计算三点(估算值)或期望值。可能通过乐观值(Sopt)、可能值(Sm)和悲观值(Spess)估算的加权平均值来计算估算变量(规模)的期望值S:S=(Sopt+4Sm+Spess)/6一旦确定了估算变量的期望值，就可以应用历史的LOC或FP生产率数据。任何估算技术，不管它有多先进，都必须与其他方法进行交叉检查。,基于LOC估算的实例,考察一个为机械零件计算机辅助设计

16、应用而开发的软件包。P342-343,图17-2 LOC方法的估算表,基于FP估算的实例,基于FP估算时，问题分解关注的不是软件功能，而是信息域的值。项目计划人员分别对软件的外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件进行估算。,图17-3 估算信息域的值,基于FP估算的实例,估算出复杂度加权因子，并计算出复杂度校正因子。最后得出FP的值：FPestimated=总计0.65+0.01(Fi),基于过程的估算,最通用的项目估算技术是根据将要采用的过程进行估算。即，将过程分解为一组较小的任务，并估算完成每个任务所需的工作量。同基于问题的估算技术一样，基于过程的估算首先从项目范围中抽取

17、出软件功能。接着给出为实现每个功能所必须执行的一系列的框架活动。这些功能和相关的框架活动可用表格形式给出，如图17-4所示。,基于过程的估算,图17-4 基于过程的估算表,基于过程的估算,一旦将问题功能与过程活动结合起来，计划人员就可以针对每个软件功能，估算完成各个软件过程活动所需的工作量，这些数据写在图的中心部分。然后，将平均劳动力价格应用于每个软件过程活动的估算工作量，就可以估算出成本。但各项任务的劳动力价格可能是不同的。,基于过程的估算,最后一个步骤就是计算每一个功能及框架活动的成本和工作量。如果基于过程的估算是不依赖LOC或FP估算而实现的，现在就已经有了两组或三组成本与工作量的估算，

18、可以进行比较、调和。如果两组估算非常一致，则有理由相信估算是可靠的。反过来，如果这些分解技术得到的结果不一致，则必须做进一步的调查和分析。,基于过程估算的实例,参看图17-4所示的在于过程的估算表，表中对CAD软件的每个功能，都给出了其各个软件工程活动的工作量估算(人月)。其中，工程和构造发布活动又被细分成表中所示的主要软件工程任务。对客户沟通、策划和风险分析活动，还给出了总工作量的估算。如果需要的话，每一个框架活动或软件工程任务都可以采用不同的劳动力价格，分别进行计算。,基于用例的估算,由于以下原因，建立基于用例的估算方法还有困难：描述用例时，可以采用多种格式和风格没有标准形式。用例表现的是

19、软件的外部视图，常常在不同的抽象级别上建立。用例没有标识出它所描述的功能和特性的复杂性。用例没有描述出涉及很多功能和特性的复杂行为。与LOC或FP不同，一个角色的“用例”可能需要数月的工作量，而另一个角色的“用例”可能在一到两天内就能完成。,调和不同的估算方法,必须对多种估算方法进行调和，以得到对工作量、项目持续时间或成本的一致估算。如果不同估算之间的差别很大，一般能够追溯到以下两个原因之一：计划人员没有充分了解或误解了项目范围。在基于问题的估算技术中所使用的生产率数据不适合本应用系统，过时了，或者是误用了。计划人员必须确定产生差别的原因，再来调和估算结果。,经验估算模型,计算机软件估算模型使

20、用由经验导出的公式来预测工作量，工作量是LOC或FP的函数，将LOC或FP的结果值代入到估算模型中。用以支持大多数估算模型的经验数据都是从有限的项目样本中得出的。因此，还没有一种估算模型能够适用于所有的软件类型和开发环境。从这些模型中得到的结果必须慎重使用。应该对估算模型进行调整，以反映当前项目的情况。应该使用从已完成项目中收集的数据对该模型进行检验方法是将数据代入到模型中，然后将实际结果与预测结果进行比较。如果两者一致性很差，则在使用该模型前，必须对其进行调整和再次检验。,估算模型的结构,典型的估算模型是通过回归分析从以往软件项目收集到的数据而得到的。这种模型的总体结构表现为下面的形式：E=

21、A+B(Ev)C其中，A、B、C是经验常数，E是工作量，Ev是估算变量（LOC或FP）。除了上式所表示的关系外，大多数估算模型都有某种形式的项目调整成分，使得E能够根据其他的项目特性加以调整。,COCOMO II模型,COCOMO II模型是一种层次结构的估算模型，主要应用于以下领域：应用组装模型。在软件工程的早期阶段使用，这时，用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的。早期设计阶段模型。在需求已经稳定并且基本的软件体系结构已经建立时使用。体系结构后阶段模型。在软件的构造过程中使用。,COCOMO II模型,和所有的软件估算模型一样，COCOMO I

22、I模型也需要使用规模估算信息，在模型层次结构中有三种不同的规模估算选项：对象点、功能点和源代码行。,COCOMO II模型,COCOMO II应用组装模型使用的是对象点一种间接的软件测量，计算对象点时，使用如下的计数值：(1)(用户界面)屏幕数，(2)报表数，(3)构造应用可能需要的构件数。将每个对象实例归类到三个复杂度级别之一（即简单的、中等的或困难的）。本质上，复杂度是以下变量的函数：客户和服务器数据表的数量和来源，以及视图或版面的数量。,COCOMO II模型,一旦确定了复杂度，就可以根据图17-6对屏幕、报表和构件的数量进行加权。首先将初始的对象实例数与表中的加权因子相乘就确定了对象点

23、数，求和后就得到了总的对象点数。当采用基于构件的开发或一般的软件复用时，还要估算复用的百分比，并调整对象点数：NOP=对象点(100-复用的百分比)/100其中NOP是新的对象点。,COCOMO II模型,图17-6 不同对象类型的复杂度加权,COCOMO II模型,根据计算得到的NOP值进行工作量估算时，必须先确定“生产率”值。图17-7中分别给出了在不同水平的开发者经验和开发环境成熟度下的生产率。PROD=NOP/人月一旦确定了生产率，就可以得到项目工作量的估算值：估算工作量=NOP/PROD,COCOMO II模型,图17-7 应用于对象点的生产率,软件方程式,软件方程式是一个多变量模型

24、，它假定在软件开发项目的整个生命周期中有特定的工作量分布。该模型是根据从4000多个当代的软件项目中收集的生产率数据导出的。根据这些数据，估算模型具有以下形式：E=LOCB0.333/P3(1/t4)其中，E为工作量，t为项目持续时间，B为特殊技能因子，P为生产率参数。对于实时嵌入式软件的开发，典型值是P=2000；对于电信及系统软件P=10000;而对于商业系统应用，P=28000。当前情况下的生产率参数可以根据以往开发工作中收集到的历史数据来导出。,面向对象项目的估算,最好用明确为OO软件设计的估算方法对传统的软件成本估算方法加以补充。LOR94给出了下列方法：1.使用工作量分解、FP分析和任何其他适用于传统应用的方法进行估算。2.使用面向对象的分析模型建立用例并确定用例数。要认识到随着项目的进展，用例数可能会改变。3.由分析模型确定关键类的数量。4.对应用的界面类进行归类，确定支持类的乘数，关键类的数量乘上乘数就得到了支持类数量的估算值。5.将类的总数乘以每个类的平均工作单元数。6.将用例数乘以每个用例的平均工作单元数，对基于类的估算做交叉检查。,小结,