《软件工程-实践者的研究方法讲义》由会员分享，可在线阅读，更多相关《软件工程-实践者的研究方法讲义（56页珍藏版）》请在金锄头文库上搜索。
1、软件工程,第20章 软件项目估算,主要内容,对估算的观察 项目策划过程 软件范围和可行性 资源 软件项目估算 分解技术 经验估算模型 面向对象项目的估算 小结,估算,软件的真实需求已经确定；共利益者们都已就绪；软件工程师准备开始；项目将要启动。但是如何进行下去呢？软件项目计划包括五项主要活动估算、进度安排、风险分析、质量管理计划和变更管理计划。本章考虑估算尝试确定构造一个特定的基于软件的系统或产品所需要花费的资金、工作量、资源及时间。,估算,软件项目经理利用从共利益者和软件工程师那里获得的信息以及从以往项目收集的软件度量数据。 估算首先要描述产品的范围。然后，将问题分解为一组较小的问题，再以历
2、史数据和经验为指南，对每个小问题进行估算。在进行最终的估算之前，要考虑问题的复杂度和风险。 工作产品是生成一个简单的表，描述要完成的任务、要实现的功能，以及完成每一项所需的成本、工作量和时间。,估算,如果有经验并遵循系统化的方法，使用可靠的历史数据进行估算，利用至少两种不同的方法创建估算数据点，制定现实的进度表并随着项目的进展不断进行调整，则可以确信已经为项目做了最好的估算。,估算,软件项目管理从一组统称为项目策划的活动开始。在项目可以开始前，项目经理和软件团队必须估算将要完成的工作、所需的资源，以及从开始到完成所需要的时间。这些活动一旦完成，软件团队就要制定项目进度计划。在项目进度计划中，要
3、定义软件工程任务及里程碑，确定每一项任务的负责人，详细指明对项目进展影响很大的任务间的相互依赖关系。,估算,很多技术工作者宁愿从事技术工作，而不愿花费时间制定计划。很多技术管理者没有接受过充分的技术管理方面的培训，对他们的计划能够改善项目成果缺乏信心。这两部分人都不想制定计划，因此就经常不制定计划。 但是没有很好地制定计划是一个项目犯的最严重的错误之一有效的计划是必需的，可以在上游以较低的成本解决问题，而不是在下游以较高成本解决问题。一般的项目要将80%的时间花费在返工上改正在项目早期所犯的错误。,对估算的观察,估算是一门艺术，更是一门科学，这项重要的活动不能以随意的方式来进行。现在已经有了估
4、算时间和工作量的实用技术。过程度量和项目度量为定量估算从历史角度提供了依据和有效的输入。当建立估算和评审估算时，过去经验的辅助作用是不可估量的。由于估算是所有其他项目策划活动的基础，而且项目计划又提供了通往成功的软件工程的路线图。因此，没有估算就着手开发，将陷入盲目性。,对估算的观察,对软件工程工作的资源、成本及进度进行估算时，需要经验，需要了解有用的历史信息，还要有当只存在定性的信息时进行定量预言的勇气。估算具有与生俱来的风险，正是这种风险导致了不确定性。 历史信息的有效性对估算的风险有很大影响。通过回顾过去，能够仿效做过的工作，并改进出现问题的地方。如果能取得对以往项目的全面的软件度量，做
5、估算就会有更大的保证，合理安排进度以避免重走过去的弯路，总体风险也会降低。,对估算的观察,估算的风险取决于对资源、成本及进度的定量估算中存在的不确定性。如果对项目范围不太了解，或者项目需求经常改变，不确定性和估算风险就会非常高。计划人员，尤其是客户，都应该认识到经常改变软件需求意味着在成本和进度上的不稳定性。,项目策划过程,软件项目策划的目标是提供一个能使管理人员对资源、成本及进度做出合理估算的框架。此外，估算应该尝试定义“最好的情况”和“最坏的情况”，使项目的结果能够限制在一定范围内。项目计划是在计划任务中创建的，尽管它具有与生俱来的不确定性，软件团队还是要根据它着手开发。因此，随着项目的进
6、展，必须不断地对计划进行调整和更新。,软件范围和可行性,软件范围描述了将要交付给最终用户的功能和特性、输入和输出的数据、使用软件时要呈现给用户的“内容”，以及界定系统的性能、约束条件、接口和可靠性。定义范围可以使用两种方法： 1、在与所有共利益者交流之后，写出对软件范围的叙述性描述。 2、由最终用户开发一组用例。,软件范围和可行性,在开始估算之前，首先要对范围陈述中描述的功能进行评估，在某些情况下，还要进行细化，以提供更多的细节。由于成本和进度的估算都是面向功能的，因此某种程度上的功能分解常常是有用的。性能方面的考虑包括处理时间和响应时间的需求。约束条件则标识了外部硬件、可用存储，或其他现有系
7、统对软件的限制。,软件范围和可行性,一旦确定了软件范围，人们自然会问：我们能够开发出满足范围要求的软件吗？这个项目可行吗？软件工程师常常匆忙越过这些问题，不料竟会一开始就注定要陷入这个项目的泥潭中。,资源,项目策划的第二个任务是对完成软件开发工作所需的资源进行估算。图20-1描述了三类主要的软件工程资源人员、可复用的软件构件及开发环境。对每一类资源，都要说明以下四个特征：资源的描述、可用性说明、何时需要资源、使用资源的持续时间。最后两个特性可以看成是时间窗口。对于一个特定的时间窗口，必须在开发初期就建立资源的可用性。,资源,图20-1 项目资源,人力资源,计划人员首先评估软件范围，并选择完成开
8、发所需的技能，还要指定组织中的职位和专业。对于一些比较小的项目，只要向专家做些咨询，也许一个人就可以完成所有的软件工程任务。而对于一些较大的项目，软件团队的成员可能分散在很多不同的地方，因此，要详细说明每个人所处的位置。 只有在估算出开发工作量后，才能确定软件项目需要的人员数量。,可复用软件资源,基于构件的软件工程强调可复用性，即创建并复用软件构造块，这种构造块通常被称为构件。为了容易引用，必须对这些构件进行分类；为了容易应用，必须使这些构件标准化；为了容易集成，必须对这些构件进行确认。,可复用软件资源,BEN92建议在制定计划时应该考虑以下四种软件资源。 成品构件：能够从第三方获得，或在以前
9、的项目中已经进行过内部开发的已有软件。 具有完全经验的构件：为以前项目开发的，与当前项目要构造的软件相似的已有的规格说明、设计、代码或测试数据。 具有部分经验的构件：为以前项目开发的，与当前项目要构造的软件有关的已有的规格说明、设计、代码或测试数据，但是需要做实质上的修改。 新构件：软件团队为了满足当前项目的特定需要，而必须专门开发的软件构件。,可复用软件资源,具有讽刺意味的是，在策划阶段，人们往往忽视可复用软件构件，直到软件过程的开发阶段，它才变成最重要的关注对象。最好是尽早确定软件资源的需求，这样才能对各种候选方案进行技术评估，并及时获取所需的构件。,环境资源,支持软件项目的环境，通常称为
10、软件工程环境（SEE），它集成了硬件和软件。硬件提供了支持工具的平台，这些工具是采用良好的软件工程实践来获得工作产品所必需的。因为在大多数软件组织中，有很多人都需要使用SEE，因此，项目计划人员必须详细规定需要硬件和软件的时间窗口，并且验证这些资源是可用的。,软件项目估算,几乎在所有基于计算机的系统中，软件都是最昂贵的万分。对于复杂的定制的系统，如果成本估算误差很大，就会使赢利变成亏损。对于开发者来说，成本超支可能是灾难性的。,软件项目估算,为得出可靠的成本和工作量估算，有很多选择： 1.把估算推迟到项目的后期进行。 2.根据已经完成的类似项目进行估算。 3.使用比较简单的分解技术，生成项目的
11、成本和工作量估算。 4.使用一个或多个经验模型来进行软件成本和工作量的估算。 每种可行的软件成本估算方法，其效果的好坏取决于估算使用的历史数据。如果没有历史数据，成本估算也就建立在一个很不稳定的基础上。,分解技术,软件项目估算是一种解决问题的形式，在多数情况下，要解决的问题非常复杂，不能作为一个整体考虑。因此，要对问题进行分解，把它分解成一组较小的问题，再定义它们的特性。,软件规模估算,软件项目估算的准确性取决于许多因素：(1)计划人员估算待开发产品规模的正确程度;(2)把规模估算转换成人员工作量、时间及成本的能力;(3)项目计划反映软件团队能力的程度;(4)产品需求的稳定性和支持软件工程工作
12、的环境。 考虑软件规模的估算问题。由于项目估算的准确程度取决于待完成工作的规模估算，因此，规模估算是项目计划人员面临的第一个主要挑战。在项目计划中，规模是指软件项目的可量化的结果。如果采用直接的方法，规模可以用代码行(LOC)来测量。如果选择间接的方法，规模可以用功能点(FP)来表示。,软件规模估算,PUT92建议使用四种不同的方法来估算规模问题： 模糊逻辑法。使用这种方法，计划人员必须先确定应用的类型，定性地确定其量级，然后在初始范围内再细化该量级。 功能点法。计划人员对信息域的特性进行估算。 标准构件法。软件是由许多不同的“标准构件”组成的，对于某个特定的应用领域而言，这些构件是通用的。项
13、目计划人员估算每个标准构件出现的次数，然后使用历史项目数据来确定每个标准构件交付时的规模。 修改法。当项目要使用已有的软件作为项目的一部分，并且该软件必须做某些方面的修改时，可以使用这种方法。计划人员要估算必须完成的修改的数量和类型。,基于问题的估算,在前述章节中，已经描述了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生产率数据。任何估算技术，不管它有多先进，都必须与其他
16、方法进行交叉检查。,基于LOC估算的实例,考察一个为机械零件计算机辅助设计应用而开发的软件包。P354-355,图20-2 LOC方法的估算表,基于FP估算的实例,基于FP估算时，问题分解关注的不是软件功能，而是信息域的值。项目计划人员分别对软件的外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件进行估算。,图20-3 估算信息域的值,基于FP估算的实例,估算出复杂度加权因子，并计算出复杂度校正因子。最后得出FP的值： FPestimated=总计0.65+0.01(Fi),基于过程的估算,最通用的项目估算技术是根据将要采用的过程进行估算。即，将过程分解为一组较小的任务，并估算完成每个任务所需的工作量。 同基于问题的估算技术一样，基于过程的估算首先从项目范围中抽取出软件功能。接着给出为实现每个功能所必须执行的一系列的框架活动。这些功能和相关的框架活动可用表格形式给出，如图20-4所示。,基于过程的估算,图20-4 基于过程的估算表,基于过程的估算,一旦将问题功能与过程活动结合起来，计划人员就可以针对每个软件功能，估算完成各个软
