基于用例的软件成本估算模型的建模与实现-毕业论文

基于用例的软件成本估算模型的建模与实现摘要 随着软件系统规模和复杂程度的日益扩大，从20世纪60年代末期开始，出现了以大量软件项目进度延期、预算超支和质量缺陷为典型特征的软件危机。人们认识到了软件估算工作的重要性和艰难性，软件成本估算活动势在必行。从最早的系统开发公司的线性估算模型开始，估算研究大量展开，各种估算模型和工具纷纷出现。作为一种捕获和描述用户需求的表现形式，用例在很多情况下被作为度量软件规模和软件总工作量的重要指标。与目前流行的软件规模度量方法源码行数和功能点数相比较，用例具有更直观、易理解、易度量、易跟踪等特性，更能反映在软件开发生命周期内项目的开发进度。本文介绍了用例的基本知识和软件估算模型国内外的现状，并根据用例规约文档建立了基于用例的软件成本估算模型，并用实例说明使用方式，最后得出结论并指明未来的研究方向。关键字 用例；估算；软件成本估算；软件规模估算；COCOMO- I -Software Cost Estimation Model Based on Use Cases and Its RealizationAbstract With the growth of size and complexity of software systems, software crisis has taken place at the end of 60th age in 20th century. The crisis includes the delay of process, budget overruns and quality defects and so on. People realize that the software estimation is an important and difficult and task has been focused on. After SDC Estimation Model was proposed, more and more research software cost estimation. There are many models and tools to support software estimation now.As a means to capture and describe customers needs, use case is an important and widely used method in many cases to represent and measure software size and ongoing work. Compared with the popular method such as source code model and function points estimation, use case is easier to understand, use, measure and be traced.This dissertation introduces the knowledge of use case and related software estimation model. The software cost estimation based on use case is established according to the use case specification document and is verified through a project. Final part makes the conclusion and proposes the future work about the model.Key words Use Case; Estimation; Software Cost Estimation; Software Size Estimation; COCOMO- 36 -目录第一章 绪论11.1引言11.2 论文的组织1第二章 用例的相关研究32.1 用例和用例模型32.2 用例规约组成42.3 用例、用例图与需求5第三章 国内外软件成本估算方法现状73.1 现有的软件成本估算模型73.2 用例点估算可行性93.3 用例点估算方法Karner方法103.4 基于用例估算的其他方法10第四章 基于用例的软件成本估算模型124.1 建模假设124.2 建模思路134.3 用例规约文档结构分析144.4 基于用例的软件成本估算模型建模144.4.1计算用例规模的权重154.4.3 确定其他需求的乘数比例164.4.4 估算源代码千行数（KSLOC）174.4.5估算软件成本184.5 模型应用-案例分析204.6 模型的评价214.6.1 模型准确度分析224.6.2 模型优点234.6.3 模型缺陷244.7 模型总结254.8 原型系统254.8.1 系统简介254.8.2 原型系统的未来扩充工作28第五章 总结与展望295.1总结295.2 未来工作展望29致谢31参考文献32附录用例规约模板34ContentsChapter 1 Exordium11.1 Introduction11.2 Dissertation structure1Chapter 2 Research about Use Case32.1 Use case and use case modeling32.2 Use case specification42.3 Use case, use case diagram and requirement5Chapter 3 The status about software cost estimation73.1 Existing software estimation model73.2 Feasibility about use case estimation93.3 Use case pointKarner method103.4 Other methods about use case estimation10Chapter 4 Software cost estimation model based on use cases124.1 Assumptions124.2 Clues134.3 Structural analysis of use case specification144.4 Software cost estimation model based on use cases144.4.1 Use case sizes weight154.4.2 Actor Multiplier164.4.3 Other Multiplier174.4.4 Estimating KSLOC174.4.5 Estimating software cost184.5 Model application-Case study204.6 Model evaluation214.6.1 Accuracy analysis224.6.2 Benefits234.6.3 Disadvantages244.7 Model summary254.8 Prototype System254.8.1 System introduction254.8.2 The future work28Chapter 5 Summary and future work295.1 Summary295.2 Future work29Acknowledgements31References32AppendixUse case specification34基于用例的软件成本估算模型的建模与实现第一章 绪论1.1引言软件开发从产生发展到现在，经历了软件危机的洗礼，成长为一门真正的学科。在成长过程中，人们意识到，缺乏有效的成本估算和合理的进度安排是造成项目滞后和成本不断积累的主要原因之一，它比其他所有因素加起来的影响还要大。那么，导致这种情况的原因是什么呢1？首先，我们对估算技术缺乏有效的研究，更加严肃的说，是我们把软件开发想象成了运作良好的开发，而没有正视出现的真正问题；第二，由于对自己的估算缺乏信心，项目经理通常不会有耐心持续估算这项工作；第三，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是大胆的革新；第四，当意识到进度的偏移时，下意识（以及传统的）反应是增加人力。这就像火上浇油，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定导致灾难性的循环。既然软件成本的估算在软件开发中有着举足轻重的地位，那么怎么样才能有效的进行估算和研究，让它为决策提供有利的支持哪？近年来，大量的成本估算方法和工具纷纷出现。其中，随着用例工具的兴起和在需求工程领域内的广泛应用，它在估算领域同样得到了认可，人们开始尝试用用例这种直观的描述需求的方式对成本进行估算，代表性的有Karner用例点方法，IBM公司的用例估算工具，用例向功能点转化等方法。用例在国际上拥有广泛的应用前景，而且贯穿于软件开发的整个过程，可以为整个开发提供强有力的估算支持，而最重要的用例规约文档是表达用例的有效方式。本文正是着眼于用例规约文档，在吸收前人研究工作的基础上，提出了基于用例的软件成本估算模型，为项目的估算提供依据。1.2 论文的组织论文的组织一共分五章。第一章：绪论。阐述了论文的研究背景和研究方向。第二章：用例的相关研究。本章介绍了用例的相关概念和研究：用例的产生、用例的发展历史、机构组成，以及与需求的关系，系统阐述了用例作为估算工具的优势。第三章：国内外软件成本估算方法现状。本章介绍了当前国内外软件成本估算的相关研究，描述了软件成本估算的发展和传统的六种软件成本估算方法，并对用例估算的可行性进行了评估。着重讲述了基于用例点的软件工作量度量的研究，并指出各种度量方法的优缺点。第四章：基于用例的软件成本估算模型。本章是整个论文的核心部分，主要建立基于用例的成本估算模型及其模型的使用步骤过程。从模型的假设前提和注意事项，以及建模的整体思路出发，重点剖析了用例规约文档，找出影响用例规模的关键因素。之后详细阐述了模型的建立和使用。并介绍了当前最为流行的构造性成本估算模型，并将工作量参数带入公式，计算出软件开发的成本。整个估算过程通过一个人力资源开发项目案例说明。最后总结并评价了模型的准确度，优缺点等，将模型的思想嵌入到一个小型的原型系统开发之中，说明模型对软件成本开发决策的支持作用。第五章：总结与展望。总结了本文所建立的软件成本估算模型，并对未来的研究方向进行了分析。第二章 用例的相关研究本章介绍了用例的相关概念和研究，从用例的产生到用例与需求的关系，系统阐述了用例作为估算工具的优势。2.1节描述了用例的产生、概念和用例建模的一般过程；2.2节描述了用例重要组成用例规约文档的结构；2.3节描述了用例图，用例与需求的关系，强调了用例在需求分析中的重要作用，为用例估算模型的建立打下基础。2.1 用例和用例模型用例的概念是由著名计算机科学家Ivar.Jacobson教授在1987年的OOPSLA大会提出的。之后的20多年，用例被广泛的应用在面向对象软件开发过程中，得到了长足的发展和进步。用例是描述了系统、子系统和类所能提供的功能集合，表现为一个或多个外部交互者（角色）与系统进行交互的消息序列3。用例代表系统中各个项目相关人员之间就系统的行为达成的契约。每个用例只描述一个符合用户意图的任务，必须产生一个对用户有意义的结果。提出请求的项目相关人员被称为主执行者（Primary Actor），主执行者通过发起与系统的一次交互来实现某个目标。系统对任一执行者所做出的响应，要保证所有项目相关人员的利益不受侵犯。根据执行者做出请求和涉及的条件，系统将执行不同的行为序列，每一行为序列称之为一个场景。一个用例是多个不同场景的集合，既包括成功场景，也包括失败场景。用例建模是使用用例的方法来描述系统功能需求的过程。用例模型的主要内容包括用例图、用例规约。用例建模的过程是：1确定系统边界。首先要区分系统执行的任务和非系统执行的任务；2确定角色，即参与者。角色可能是人、人的集体或者是与系统发生交互的外部系统, 也可能是触发系统发生某个事件的时间等。它们通过系统完成特定的目的。通常角色的分类通过使用目的和使用权限来进行分类；3列举用例。用例是系统执行的动作序列,是系统对角色提供的服务，角色可以通过用例来达到特定目的。在列举用例时一定要以角色目的为出,并按照业务归属进行命名,通常用动词或动词短语命名, 以描述用户可见的最终结果。在较为复杂的用例环境中进行用例分析会比较困难,应当采用“自顶向下”的分解方法列举出, 每个局部应用范围内的用例就会比较容易的分析出所有的用例。但由于用例是抽象的,不能分解过多,一般用户用例个数为视图2050个；4用例图。角色、用例以及它们之间的关系与系统边界共同构成的图称为用例图。在用例图,使用标识系统名称的方框表示系统的边界,角色位于系统边界之外,用例位于系统边界之内,角色与用例间的连线表示参与者与用例间的通信关联。用例图中用例与角色之间存在着关联关系(Association) , 用例之间也存在着包含关系(Include)、扩展关系(Extend)、泛化关系(Generation)等。此外还可以利用UML提供的扩展机制自定义；5用例规约。用例图只是在总体上大致描述了系统所能提供的各种服务, 使我们对于系统有总体的认识, 对于每个用例的更为详细的描述信息,则包含于用例规约中,用例模型就是由用例图和用例规约所组成。2.2 用例规约组成虽然可以用流程图、顺序图、Petri网或者程序设计语言来表示用例，但是从根本上说，用例是文本形式的。通常情况下，它们是作为人与人之间，尤其是没有受过专门培训人员之间互相交流的一种手段。因此，简单的文本通常是编写用例的首选形式3。简单说来，用例是由多个句子组成的，所有的句子都采用同一种语法形式一个简单的执行步骤，通过执行这些步骤，执行者或者获得一定结果或者向另一个执行者传递信息。用例的组成包括：1执行者（Actor）：任何具有行为的人或者物；2项目相关人员（Stakeholder）：对被讨论系统的行为有特定兴趣的人或者物；3主执行者（Primary actor）：启动与被讨论系统的一次交互活动。从而达到某一目标的人或者物；4用例（Use case）：规定被讨论系统行为的契约；5范围（Scope）：界定被讨论的系统；6前置条件和保证（Precondition and guarantee）：在用例执行之前和之后必须满足的条件；7主成功场景（Main success scenario）：一切顺利的情况；8扩展（Extension）：场景执行过程中出现的异常情况；2.3 用例、用例图与需求用例图（Use Case Diagram）是UML中最简单也是最复杂的一种视图，表示了执行者、用例、以及它们之间的关系。主要用于描述系统功能的静态视图以及各个功能之间的静态关系。其采用了简单的图形符号来代表系统的用例集合，展示了系统需要实现的全部功能。图2.1是用例图的一个示例：图2.1 用例图示例用例规约和用例图是相互补充的。用例规约由文本组成，描述了一个执行者与系统进行交互达到目标的故事。但是阅读大量的文本信息可能给客户带来困扰，同时大量的文本用例不能将系统的功能性需求一目了然的展现出来。而用例图作为文本用例的补充，弥补了文本用例的这些不足。客户可以通过查看用例图即可知道系统所能满足的目标。特别在需求分析阶段，由于信息获取的不足，分析人员也可以先将用例图构建出来，确定系统功能的总体框架，然后再随着信息量的增多，来充实文本用例中的场景。项目的需求，一般来说包括3：1功能需求：专注于系统是“什么”，确定与“功能”和“数据”有关的需求；2非功能需求：专注于系统“有多好”的方面，并确定像“性能”、“可维护性”、“可扩展性”、“可操作性”、“可靠性”和“可移植性”等属性以及确定系统要运行在什么“限制”之下；3系统操作的限制因素；4同其他系统/操作者的接口。 在当前的软件项目开发中，用例被广泛地应用于捕获和描述需求。用例采用“以用户为中心”的角度，而不是基于程序员的角度分析问题，这样能更好地帮助用户理解他们想从目标系统中得到什么以及他们如何与目标系统交互。在捕获用例的过程中，用户可以通过角色系统的对话来告诉项目开发人员他们的真实需要。但是用例描述需求时，必须记住以下两点3：1用例确实是需求。不必将用例转变成行为需求的其他形式，用例可以准确地对系统必须要做什么进行详细的描述；2用例不是所有的需求。用例并不详细地描述外部接口、数据格式、业务规则和复杂公式，它只是所有需求中的一部分即功能需求。虽然这一部分是非常重要的，但毕竟只是一部分。也就是说，用例是需求的核心，甚至是项目开发过程中的核心元素，但它只是需求文档的一部分，而不是所有的需求，用例表述的仅是行为需求，并且是所有的行为需求。业务规则、词汇表、性能目标、过程需求和许多其他方面的东西都不属于行为需求之列，但依然可以在用例规约文档中有所体现。下面的图2.2轮轴和轮辐需求模型形象地体现了用例和需求的关系3：图2.2 轮轴轮辐需求模型第三章 国内外软件成本估算方法现状本章介绍了关于软件成本估算的相关研究，尤其是基于用例的软件工作量度量的研究。首先在3.1节描述了软件成本估算的发展和传统的六种软件成本估算方法；3.2节阐述了用例估算的可行性，为用例模型的建立做好铺垫；3.3节着重描述了Karner的用例点方法；3.4节描述了另外两种基于用例的工作量的估算方法，并指出他们模型的优缺点。3.1 现有的软件成本估算模型随着软件系统规模的不断扩大和复杂程度的日益加大，从20世纪60年代末期开始，出现了以大量软件项目进度延期、预算超支和质量缺陷为典型特征的软件危机，至今仍频繁发生。根据 Standish 组织4在1995年公布的CHAOS报告显示,在来自350个组织的8 000个项目中，只有16.2%是“成功的(succeeded)”，即能在预算和限期内完成；31.1%是“失败的(failed)”，即未能完成或者取消；其余52.7%被称为“被质疑的(challenged)”，虽然完成但平均预算超支89%（如图3.1所示）5。2004年，该组织的统计项目数累计达到50000多个，结果显示，成功项目的比例提升到29%，而被质疑的项目比例仍有53%5。虽然有些研究认为，CHAOS报告中关于预算超支89%的数据被夸大了，实际情况应该平均在 30%-40%。但有一点却能够取得共识：人们经常对软件成本估算不足。它与需求不稳定并列，是造成软件项目失控最普遍的两个原因。图3.1 Standish咨询公司对软件项目完成情况的统计数据之后，无论在企业还是实验室，越来越多的人认识到，软件成本估算是减少软件项目预算超支问题的首要措施之一，不但有助于做出合理的投资、外包、竞标等商业决定，而且有助于确定一些预算或进度方面的参考，为项目经理决策提供依据。美国南加州大学的Barry Boehm教授所指出的，“理解并控制软件成本带给我们的不仅仅是更多的软件，而会是更好的软件” 6。因此，有效的估算成为了软件开发项目管理中最具挑战性也是最重要的活动。只有使用科学的方法对软件项目的规模、工作量、进度与成本做出合理可靠的估算，才能实施良好的项目计划与控制。然而由于各种原因，目前，项目估算在软件开发中还是一个薄弱的环节。最早的软件成本估算研究可以追溯到20世纪60年代的SDC(System Development Corporation)线性模型2，已历经了40年的发展。随着研究的不断深入和发展，逐步形成了多种方法。具有代表性的有算法模型、专家判断、类推、帕金森、价格策略、自顶向下、自底向上等方法7。算法模型提供了一个或多个算法，这些算法产生的软件成本估算为一系列变量的函数，这些变量被认为是主要的成本驱动因子；专家判断会涉及到咨询一个或多个专家，也许需要专家组意见一致机制的辅助技术，如Delphi技术；类推涉及到通过类比进行推理，把一个或多个已完成项目的实际成本，与一个相似的新项目的成本估算联系起来；帕金森方法是利用“帕金森原理”工作会自动地膨胀占满所有可用的时间，是将成本估算等同于可用资源；价格策略得到的成本估算，等于人们所相信的要圆满完成工作所必需的价格；自顶向下，一个项目的全部成本估算源于软件产品的全部属性，先估算总成本，然后再分散到各种组件中；自底向上，软件任务的每个组件都独立的进行成本估算，然后将所有结果总计起来就得到对全部任务的估算。它们的优劣比较见表3.17：表3.1 几种软件成本估算模型比较列表方法优点缺点算法模型l 客观、可重复、可分析的公式l 有效率、敏感性分析好l 能用经验来客观校准l 主观输入l 不能评估异常情况l 校准的是过去的项目，不是将来的专家估算l 能对有代表性的项目进行迭代l 特殊情况下的项目进行评估l 并不比参加者好l 有偏见，不完善的回忆类推l 基于有代表性的经验上l 经验的代表帕金森l 与一些经验相关联l 加强的是不良时间价格策略l 常得到合约l 通常产生大的超进度自顶向下l 能聚焦于系统级别上l 有效率l 不够详细的基础l 缺乏稳定性自底向上l 更为详细的基础l 更稳定l 培养个人承诺l 也许忽略了系统级成本l 需要更多的工作量3.2 用例点估算可行性用例模型越来越多地用于捕获和描述软件系统的功能需求，可以有不同的途径和方法使用用例估算工作量7。一些研究者试用了用例点方法，并分析了他们的发现。结果表明，用例点方法有潜力成为估算的可靠素材，它与功能点方法类似；而且，软件开发项目的规模对估算结果影响很大，特别是当和专家估算法结合使用时。另外，用例建模技术的应用日益广泛它不仅用于描述软件和系统需求，还是设计、开发、测试、部署、配置管理和维护的基础因此，基于用例模型的估算方法是很有意义的。而软件规模或者工作量的估算，常常是软件成本估算的基础，甚至两者可以等同。捕捉软件项目的功能需求时，常使用用例模型。用例建模是一项业界广泛使用的技术，用于描述和捕捉软件系统的功能需求。用例点（Use Case Point）是一项估算软件开发工作量的新方法。既然用例和场景技术已成为需求采集和分析的标准部分，并且它们捕捉了用户需求的精确描述，那么，基于用例和场景进行更加困难的开发规模和资源的估算工作，是很有意义的。基于用例估算的另一个优点是，通过使用现代需求管理工具，可维护其双向可跟踪能力。可以在用例和多种软件工程工件之间，维护这种双向可跟踪能力，包括设计、编码、测试、配置管理、架构和部署等相关的工件。Bente Anda(Anda 2001)比较了用例点方法和专家估算法，后者是由有经验的软件开发者进行的。结果发现，用例点方法给出的估算和有经验的软件开发者给出的估算很接近。该估算方法的相对误差值和相对误差平均值都在可接受范围内。研究结果表明，用例点方法可以成功地用来估算软件开发工作量。3.3 用例点估算方法Karner方法Karner博士在1993年首先提出了的用例点方法9。下面简单介绍Karner用例点估算方法步骤。首先，将用例模型中的角色按照简单、一般和复杂三个等级来分类，并统计每类角色的数量，分别乘以各自的权重系数（Weighting Factor），然后相加，得出总的未调整角色权重（Unadjusted Actor Weight，UAW）。然后，依据用例中的事务数量（包括备选流中的交易），将用例按照简单、一般和复杂三个等级来分类，并按如下步骤计算未调整用例权重（Unadjusted Use Case Weights，UUCW）：统计每类用例的数量，分别乘以各自的权重系数，然后把这些乘积相加。最后，将UAW和UUCW相加，得到未调整用例点（Unadjusted Use Case Points，UUPC）。接下来，基于技术系数和环境系数调整用例点的值。每个系数是介于0到5之间的一个值，具体由它们对整个项目的假定影响来确定。该步骤相关的3个公式如下： 技术复杂性系数： TCF=0.6+(0.01*Tfactor)（公式3.1）环境系数： EF=1.4+(-0.03*Efactor)（公式3.2）已调整用例点： UCP=UUCP*TCF*EF（公式3.3）最终，UCP要乘以一个代表生产力的历史数据的系数，比如，每个用例点20人时（Person Hour），得到项目估算结果完成项目所需的人时总数。3.4 基于用例估算的其他方法基于用例的规模估算研究除了Karner方法外，由于代码行和功能点被业界广泛使用，所以也有一些研究人员研究用例向功能点，代码行的转换。下面介绍两种代表方法：1用例向功能点转换的方法由Thomas Fetke等人在1997年提出的一种按功能点方法，将面向对象的元素按照一定规则进行转换从而得到所要构建的对象的功能点10。Thomas制定了一系列的基于IFPUG所提供的功能点计算方法将用例直接转换到功能点模型的规则和过程。用例虽然与功能点概念相似，但不完全等价，所以转换规则比较复杂，在实际中很难运用。例如，用例中的参与者是处在系统之外的与系统进行交互的人或物，这个概念比功能点方法中的用户及外部应用程序的概念要广，因此必须分类处理用例角色。同时必须将用例细化到类的层次，这又与用例的粒度划分有关2用例结合代码行估算IBM公司的John Smith在1999年提出了一种基于用例估算的框架11。他将系统分解为SubSystem，SubSystemGroup，System，SystemOfSystem四个级别，每个级别都有10个外部用例以及8个内部的相应级别的部件，每一个用例又有8个类，一个类有12个方法，这样根据每个方法对应的基于C+的代码行数就可以估算处于任何一个层次的代码行数，利用这个框架可以获得在用例的任何层次的规模和工作量估算，避开了用例估算中用例细化的问题。但这种方法将用例与某种特定的编程语言绑定，造成了一定的局限性。第四章 基于用例的软件成本估算模型本章是论文的核心主体部分，主要介绍了本文建立的用例成本估算模型。4.1节和4.2节描述了模型建立和使用的前提和注意事项，以及建模的整体思路；4.3节剖析了用例规约文档，找出影响用例规模的关键因素；4.4节详细阐述了本文模型的建立和使用步骤，计算出工作量参数，并介绍了目前世界上使用频率很高的Barry Boehm博士的构造性成本估算模型（Constructive Cost Model，COCOMO），将得到的工作量参数带入公式，计算出软件开发的成本；4.5节通过一个实际案例说明了本文模型的应用；4.6节对模型的准确度进行了评价，说明了模型的优缺点和未来的研究工作；4.7节总结了基于用例的软件成本估算模型；4.8节实现了一个用例估算模型的原型系统，更具体的说明模型的使用。4.1 建模假设每一个模型的建立都需要一定的条件限制，没有一个模型是符合所有的要求的。本文的模型是建立在对用例规约文档分析基础上的，为了更好的应用模型为决策服务，保证模型的简单性和稳定性，需要说明以下问题。1使用本文基于用例的成本估算模型，建议开发时采用基于RUP的软件开发过程。即使不采用RUP的开发方法，那也要在需求分析阶段使用用例进行业务建模和需求分析，这是本文估算的基本前提；2本文用例模型是严格建立在用例规约文档基础上的，比较遗憾的是，目前国际上对用例规约文档还没有一个统一的标准。但是每一个用例规约文档都有很多共同的关键点，这为基于用例的成本估算提供了可能和便利。为了方便原型系统的开发与展示，本文使用了一个比较通用的用例规约文档，详细请见附录用例规约文档；3软件开发是一个不断细化的过程，软件系统的概念也逐步细化为需求说明，需求说明又进一步细化为概要设计，概要设计再细化为详细设计，详细设计最终细化为代码。在每个阶段都可能做出影响最终产品的成本和开发进度的决策，所以产品充满了不确定性。这种不确定性直接导致了成本估算的不确定性。因此，软件成本估算是一个逐渐改进的过程，它将贯穿于整个产品开发的生命周期，需要使用在开发阶段监控中所采集的数据通过在每一步实际数据与估算数据进行比较来改进下一步的估算精确度。本文所使用的用例估算模型，是基于用例规约文档，为需求分析阶段的估算提供一定的依据，随着项目开发阶段的深入，用例模型的完善，应该结合具体的数据对模型进行不断的修正和改进，以便为系统的开发提供不断的依据；4没有任何一个估算方法可以在所有方面都做的比其他方法出色7。本文的模型也不例外，例如，面对一个完善规范的用例文档时，使用它估算可以更好指导决策，但当项目缺乏有力的用例模型支持时候，它的功能也会大打折扣。4.2 建模思路本文采用的用例估算模型与前人的用例估算模型不同，Karner等人专注于用例点本身或者用例向功能点的转化进行估算，而本文专注于用例规约文档带给人们的信息。用例规约文档是对每个用例的完整描述，包含了大量的有用信息。用例图给人一种直观的感受，让客户，开发人员可以了解整个场景，而用例规约文档则更加详细具体，它可以显示出用例图本身没有的信息，包括用例的执行，事务流等信息。前人的研究中，用例的粒度划分也是一个比较重要的问题。用例的粒度直接影响用例点。到底是一个大的用例合适还是分解成多个小用例合适呢？这个问题并没有一个标准的规则，需要根据不同阶段的需求来进行不同的划分，但这样就给用例点的估算带来了不便，也为向功能点的转换规则和过程带来了不便。业界用例粒度的划分依据标准是一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的。但用例文档规约受用例粒度划分的影响比较小，因为用例规约主要由事件流进行刻画，大粒度用例事件流数量一定比小粒度用例的多，这样为软件规模估算和成本估算都带来了便利。已有的基于用例成本估算模型，往往需要考虑很多成本驱动因子对模型结果的影响，如Karner模型考虑环境因素，技术因素等。本文的基于用例的成本估算模型是以Barry Boehm博士的COCOMO II模型为基础的，在COCOMO模型中已经考虑了足够的成本驱动因子。另外，用户在使用COCOMO模型过程中，输入的KSLOC的偏差往往比较大，缺乏模型支持，导致最终的估算结果不理想。因此，本文的思路是基于用例建模得出源代码千行数（KSLOC），然后代入COCOMO II模型进行计算，从而改善用户主观猜测，KSLOC的潜在误差状况。本文模型的关键就在于将用例模型与项目规模建立相关数学关系，算出源代码千行数（KSLOC），软件的成本自然可以估算。COCOMO模型已经考虑了完整的成本驱动因子，并且考虑了软件开发过程中的估算，所以，只要专注于基于用例的软件规模估算，即可达到估算成本的目的。4.3 用例规约文档结构分析本文采用的用例规约文档请见附录用例规约文档，现在对用例规约文档进行结构分析，虽然用例不会受环境，技术等因素的影响，但它却受用例规约内部的要素的影响。因此，区分用例中影响软件规模的关键因素和其他因素是非常必要的。跳过第一部分简介和第二部分用例模型图，从第三部分具体用例开始分析。主要分析每一个用例对应的用例规约。用例的名称和简要说明是对这个用例的简要介绍，对软件的规模没有影响，是非关键因素。参与者是用例的重要组成部分，它是与系统直接进行交互的有具体行为的事务，可能是人、公司、组织等。人可能是不同的角色，比如用户、经理等。参与者不同的角色和数量会影响最后软件规模的大小，因此参与者是影响规模的因素之一。事件流是一个用例的主体部分，对用例的规模有直接的影响，反映了用例的复杂程度和执行步骤，因此是影响软件规模最为关键的因素。前置条件、触发条件和后置条件是用例执行之前和之后的满足条件，前置和触发条件是很多由其他因素引起的，对软件规模没有很大影响。后置条件是执行用例后的结果，对软件规模的影响也很小。本文模型将三者均定为非关键因素。这里的其他需求包括了非功能需求、数据、业务规则和界面约束四个方面。其中，非功能需求通常分为可用性需求、可靠性需求、性能需求以及可替换性需求。它们通常是指需要符合任意法律法规要求的需求。它们也可以是由于所使用的操作系统、环境平台、兼容性或所采用的任何应用标准等问题产生的设计约束。许多非功能性需求适用于一个单独的用例，并且可以在该用例的特征内获得这些需求。在这种情况下，这些需求可以在用例的事件流内获取。所以，一般非功能需求都包含在补充用例规约中，也体现在事件流中，所以本文不予以考虑；数据是对用例数据流中操作的限制条件，业务规则是对业务执行过程的限制，也是影响事件流的一个规约，界面约束规定了界面的要求，因此这三者也是影响软件规模的因素。综上所述，本文关注的影响因素有参与者、事件流、其他需求中的数据、业务规则和界面约束。4.4 基于用例的软件成本估算模型建模基于用例估算软件规模，事件流是用例的主体，对规模影响最大，是模型的主体；参与者，其他需求是影响软件规模的乘数因子（MG）。文中的权重和乘数因子比例，均根据经验项目数据和已有用例点估算方法中数据调整而来8。4.4.1计算用例规模的权重事件流是用例的主体部分，是用例规模的有效衡量部分。事件流又分为主事件流和扩展事件流，两者对软件工作量的影响权重是不同的。主事件流对软件规模影响要大于扩展事件流。本文根据用例规约文档中主事件流数量和扩展事件流的数量衡量用例的复杂程度。事件流的复杂程度分类规则如表4.1，4.2：表4.1 主事件流的权重因子表用例类型判断规则权重因子简单主事件流的数目小于等于310中等主事件流的数目在4到7之间15复杂主事件流的数目多于720因此，根据表4.1得出以下公式：用例主事件流的权重（UPEW）相应主事件流的用例数*权重因子（公式4.1）表4.2 扩展事件流的权重因子表用例类型判断规则权重因子简单扩展事件流的数目小于等于55复杂扩展事件流的数目大于57因此，根据表4.2得出以下公式：用例扩展事件流权重（UEEW）相应扩展事件流用例数*权重因子（公式4.2）根据公式4.1和公式4.2，可以得出用例事件流的权重公式：用例事件流的权重（UEW）主事件流权重（UPEW）+扩展事件流权重（UEEW）（公式4.3）4.4.2 确定参与者的乘数比例参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。参与者是由所开发的系统边界决定的，不同的边界，反映了不同的参与者。一般情况下，不会将一些系统的组成结构抽象为参与者。如一个ATM机系统，边界一般为银行系统，而不仅仅是ATM机。这样，后台服务器系统是属于系统的一部分而不是参与者。考虑到不同角色的参与者会有不同的操作流程，对软件规模有一定的影响。主要分为标准和复杂两个类别，并对每一个类别分配一个权重因子，如表4.3：表4.3 参与者乘数因子表参与者类型判断规则乘数因子标准项目中小于四种角色1复杂多于四种角色的参与者1.024.4.3 确定其他需求的乘数比例其他需求中影响软件规模的因素有数据、业务规则和界面约束。其中，业务规则和界面约束相对于数据对软件规模有更大的影响。本文将业务规则又分为两大类。一种是全局规则，这种规则一般与所有用例都相关而不是与特定用例相关。例如Actor要操作用例必须获得相应的授权，用例的操作与授权级别相关，或者用户在系统中的所有操作都要被记录下来等等；另一种是特定规则。所谓特定规则是指事件本身具备的规则，并且不因为外部的交互而变化的规则。例如，每张定单至少要有一件商品，同一类商品数量不能大于5件等。同时也包括大家所熟悉的数据校验规则，例如身份证号必须是15或18位，邮编必须是6位等。这类规则是事件流的内在规则。全局规则一般都在整体之外，而特定规则一般都包含在每一个用例之内，包含在每一个用例规约之中。根据项目所包含的特定规则的用例数目，分为标准，中等和复杂三类。业务规则的具体分类见表4.4：表4.4 业务规则的乘数因子表用例类型判断规则乘数因子全局规则全局文档中，不在用例规约中1.05特定规则标准项目中所有的用例没有业务规则1.0中等项目中一半以下的用例没有业务规则1.1复杂项目中多于一半的用例有业务规则1.2界面的好坏和复杂程度对软件规模也会产生一定的影响。因此，按照界面约束的数目来确定相应用例类型的乘数因子也是必要的。具体见表4.5所示：表4.5 界面约束的乘数因子表用例类型判断规则乘数因子简单界面约束条件小于等于31.03复杂界面约束条件大于等于41.054.4.4 估算源代码千行数（KSLOC）计算了事件流关键因素的权重值和各个乘数因子后，进一步计算用例规模值，具体公式如下：项目规模值（PS）用例事件流权重（UEW）*参与者乘数因子*业务规则乘数因子*界面约束乘数因子（公式4.4）用字母表示，数学公式为： （公式4.5）其中，MG是乘数因子，包括参与者，业务规则和界面约束。根据有关的项目数据，将用例权重值与项目规模，即源代码千行数比较建模。用例的权重与用例的规模是呈简单的线性关系，需要用一个比例系数来调整，这个比例系数符号为R，建模如公式4.6：（公式4.6）公式4.6中R的值需要根据项目数据调整，这里取1/12。这样就计算出了COCOMOII模型所需的关键参数源代码千行数（KSLOC）。4.4.5估算软件成本4.4.5.1 COCOMO模型介绍COCOMO模型是由Barry Boehm博士在20世纪70年代后期提出的突破性的软件成本估算模型7，这个模型在他的经典著作中进行了详细描述。模型具有独到的视点，精辟的分析方法和开发的模型细节，得到了广大用户的认可，成为了20年来应用最为广的软件成本估算模型。随着时代的进步，为了适应现代软件开发过程，方法，工具和技术的发展，Barry Boehm博士和他实验室的同事一起，继续不断的对模型进行更新、改进和扩展，并于20世纪90年代后期提出了COCOMO II8。COCOMO II不仅是对1981年提出的COCOMO经典模型的继承和改进，而且对成本驱动因子进行了调整和更新，加入了许多现代软件开发过程和各种构造方法。1981年的模型被称为COCOMO 81，而COCOMO II模型是根据数据库中161个项目的实际参数和工作量的值对COCOMO 81进行修正得到的。COCOMO 81模型是COCOMO II模型的基础，本文采用COCOMO II入手进行成本估算建模。COCOMO模型的基本原理是将软件开发所需的工作量表示为软件规模和一系列成本因子的函数，COCOMO 81包括了三个详细度和精确度递增的子模型：基本模型、中等模型和详细模型。COCOMO II模型是对COCOMO 81模型的改进和参数的进一步修正。EM为工作量的乘数，SF值代表指数比例因子，A，B，C，D是系数，取值根据项目数据库来校准。如表4.6所示，是COCOMO II的模型公式，表4.7是COCOMO II模型中的各种成本驱动因子。表4.6 COCOMO II模型的成本估算公式工作量值：（公式3.7）其中，进度公式：（公式3.8）其中，COCOMO II2000校准时的系数值：A2.94 B=0.91C=3.67 D0.28表4.7 COCOMO II2000模型中的成本驱动因子产品因子项目因子人员因子平台因子RELY 要求的软件可靠性TOOL软件工具的使用ACAP 分析员能力TIME 执行时间约束DATA 数据库规模SITE 多点开发PCAP 程序员能力STOR 主存储器约束CPLX 产品复杂性SCED 要求的开发进度PCON 人员连续性PVOL 平台易变性RUSE 可复用开发AEXP 应用经验DOCU 匹配生命周期需求的文档编制PLEX 平台经验LTEX 语言和工具经验表4.7中的每个成本驱动因子对应一个乘数EM值，将每个项目的EM值相乘带入COCOMO的公式中即可得出软件成本值和开发进度。4.4.5.2 基于用例的软件成本估算模型COCOMO系数和各个