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

1、百度文库-让每个人平等地捉升门我基于用例的软件成本估算模型的建模与实现扌商要随着软件系统规模和复杂程度的日益扩大，从20世纪60年代末期开始，出现了 以大量软件项LI进度延期、预算超支和质量缺陷为典型特征的软件危机。人们认识到了软 件估算工作的重要性和艰难性，软件成本估算活动势在必行。从最早的系统开发公司的线 性估算模型开始，估算研究大量展开，各种估算模型和工具纷纷出现。作为一种捕获和描述用户需求的表现形式，用例在很多情况下被作为度量软件规模和 软件总工作量的重要指标。与U前流行的软件规模度量方法源码行数和功能点数相比较， 用例具有更直观、易理解、易度量、易跟踪等特性，更能反映在软件开发生命周

2、期内项U 的开发进度。本文介绍了用例的基本知识和软件估算模型国内外的现状，并根据用例规约文档建立 了基于用例的软件成本估算模型，并用实例说明使用方式，最后得出结论并指明未来的研 究方向。关键字用例；佔算：软件成本估算；软件规模估算；COCOMO5Software 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

3、end of 60th age in 20th cent ury. The crisis in eludes the delay of process, budget overr uns 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 softwar

4、e 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 s

5、ource 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 specific

6、ation 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目录第一章绪论1引言1论文的组织1第二章用例的相关研究3用例和用例模型3用例规约组成4用例、用例图与需求4第三章国内外软件成本估算方法现状7现有的软件成本估算模型7用

7、例点估算可行性9用例点估算方法Earner 方法10基于用例估算的其他方法10第四章基于用例的软件成本估算模型12建模假设12建模思路13用例规约文档结构分析14基于用例的软件成本估算模型建模144. 4. 1计算用例规模的权重154. 4.2确定参与者的乘数比例164. 4.3确定其他需求的乘数比例164. 4. 4估算源代码千行数（KSL0C） 174. 4. 5估算软件成本18模型应用-一案例分析20模型的评价214. 6. 1模型准确度分析224. 6. 2模型优点234. 6. 3模型缺陷24模型总结25原型系统254. 8. 1系统简介254. 8. 2原型系统的未来扩充工作28第

8、五章总结与展望29总结29未来工作展望29致谢31参考文献32附录用例规约模板34Contents第一章绪论1引言1论文的组织1第二章用例的相关研究3用例和用例模型3用例规约组成4用例、用例图与需求4第三章国内外软件成本估算方法现状7现有的软件成本估算模型7用例点估算可行性9用例点估算方法Earner 方法10基于用例估算的其他方法10第四章基于用例的软件成本估算模型12建模假设12建模思路13用例规约文档结构分析14基于用例的软件成本估算模型建模144. 4. 1计算用例规模的权重154. 4.2确定参与者的乘数比例164. 4.3确定其他需求的乘数比例164. 4. 4估算源代码千行数（K

9、SL0C） 174. 4. 5估算软件成本18模型应用-一案例分析20模型的评价214. 6. 1模型准确度分析224. 6. 2模型优点234. 6. 3模型缺陷24模型总结25原型系统254. 8. 1系统简介254. 8. 2原型系统的未来扩充工作28第五章总结与展望29总结29未来工作展望29致谢31参考文献32附录用例规约模板34百度文库-让每个人平等地捉升门我第一章绪论引言软件开发从产生发展到现在，经历了软件危机的洗礼，成长为一门真正的学科。在成 长过程中，人们意识到，缺乏有效的成本估算和合理的进度安排是造成项U滞后和成本不 断积累的主要原因之一，它比其他所有因素加起来的影响还要大

10、。那么，导致这种情况的 原因是什么呢山？首先，我们对估算技术缺乏有效的研究，更加严肃的说，是我们把软件开发想象成了 运作良好的开发，而没有正视出现的真正问题；第二，由于对自己的估算缺乏信心，项LI 经理通常不会有耐心持续估算这项工作；第三，对进度缺少跟踪和监督。其他工程领域中, 经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是大胆的革新；第四，当 意识到进度的偏移时，下意识（以及传统的）反应是增加人力。这就像火上浇油，只会使 事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定导致灾难性的循环。既然软件成本的估算在软件开发中有着举足轻重的地位，那么怎么样才能有效的进行 估算和研

11、究，让它为决策提供有利的支持哪？近年来，大量的成本估算方法和丄具纷纷出 现。其中，随着用例工具的兴起和在需求工程领域内的广泛应用，它在估算领域同样得到 了认可，人们开始尝试用用例这种直观的描述需求的方式对成本进行估算，代表性的有 Karner用例点方法，IBM公司的用例估算工具，用例向功能点转化等方法。用例在国际上拥有广泛的应用前景，而且贯穿于软件开发的整个过程，可以为整个开 发提供强有力的估算支持，而最重要的用例规约文档是表达用例的有效方式。本文正是着 眼于用例规约文档，在吸收前人研究工作的基础上，提出了基于用例的软件成本估算模型, 为项U的估算提供依据。论文的组织论文的组织一共分五章。第一

12、章：绪论。阐述了论文的研究背景和研究方向。第二章：用例的相关研究。本章介绍了用例的相关概念和研究：用例的产生、用例的 发展历史、机构组成，以及与需求的关系，系统阐述了用例作为估算工具的优势。百度文库-让每个人平等地捉升门我第三章：国内外软件成本估算方法现状。本章介绍了当前国内外软件成本估算的相关 研究，描述了软件成本估算的发展和传统的六种软件成本估算方法，并对用例估算的可行 性进行了评估。着重讲述了基于用例点的软件工作量度量的研究，并指出各种度量方法的 优缺点。第四章：基于用例的软件成本佔算模型。本章是整个论文的核心部分，主要建立基于 用例的成本估算模型及其模型的使用步骤过程。从模型的假设前提

13、和注意事项，以及建模 的整体思路出发，重点剖析了用例规约文档，找出影响用例规模的关键因素。之后详细阐 述了模型的建立和使用。并介绍了当前最为流行的构造性成本估算模型，并将丄作量参数 带入公式，计算出软件开发的成本。整个估算过程通过一个人力资源开发项LI案例说明。 最后总结并评价了模型的准确度，优缺点等，将模型的思想嵌入到一个小型的原型系统开 发之中，说明模型对软件成本开发决策的支持作用。第五章：总结与展望。总结了本文所建立的软件成本估算模型，并对未来的研究方向 进行了分析。5第二章用例的相关研究本章介绍了用例的相关概念和研究，从用例的产生到用例与需求的关系，系统阐述了 用例作为佔算工具的优势。

14、节描述了用例的产生、概念和用例建模的一般过程；节描述了 用例重要组成一一用例规约文档的结构；节描述了用例图，用例与需求的关系，强调了用 例在需求分析中的重要作用，为用例估算模型的建立打下基础。用例和用例模型用例的概念是山著名II算机科学家教授在1987年的OOPSLA大会提出的。之后的20多 年，用例被广泛的应用在面向对象软件开发过程中，得到了长足的发展和进步。用例是描述了系统、子系统和类所能提供的功能集合，表现为一个或多个外部交互者 (角色)与系统进行交互的消息序列。用例代表系统中各个项目相关人员之间就系统的行为达成的契约。每个用例只描述一 个符合用户意图的任务，必须产生一个对用户有意义的结

15、果。提出请求的项U相关人员被 称为主执行者(Primary Actor),主执行者通过发起与系统的一次交互来实现某个LI标。 系统对任一执行者所做出的响应，要保证所有项目相关人员的利益不受侵犯。根据执行者 做出请求和涉及的条件，系统将执行不同的行为序列，每一行为序列称之为一个场景。一 个用例是多个不同场景的集合，既包括成功场景，也包括失败场景。用例建模是使用用例的方法来描述系统功能需求的过程。用例模型的主要内容包括用 例图、用例规约。用例建模的过程是：1. 确定系统边界。首先要区分系统执行的任务和非系统执行的任务；2. 确定角色，即参与者。角色可能是人、人的集体或者是与系统发生交互的外部系统,

16、 也可能是触发系统发生某个事件的时间等。它们通过系统完成特定的U的。通常角色的分 类通过使用目的和使用权限来进行分类；3. 列举用例。用例是系统执行的动作序列，是系统对角色提供的服务，角色可以通过 用例来达到特定LI的。在列举用例时一定要以角色LI的为出，并按照业务归属进行命名，通 常用动词或动词短语命名，以描述用户可见的最终结果。在较为复杂的用例环境中进行用 例分析会比较困难，应当釆用“自顶向下”的分解方法列举出，每个局部应用范圉内的用例 就会比较容易的分析出所有的用例。但山于用例是抽象的，不能分解过多，一般用户用例个 数为视图2050个；4. 用例图。角色、用例以及它们之间的关系与系统边界

17、共同构成的图称为用例图。在 用例图，使用标识系统名称的方框表示系统的边界，角色位于系统边界之外,用例位于系统 边界之内，角色与用例间的连线表示参与者与用例间的通信关联。用例图中用例与角色之间 存在着关联关系(Association),用例之间也存在着包含关系(Include)、扩展关系 (Extend)、泛化关系(Generation)等。此外还可以利用UML提供的扩展机制自定义；5. 用例规约。用例图只是在总体上大致描述了系统所能提供的各种服务，使我们对于 系统有总体的认识，对于每个用例的更为详细的描述信息，则包含于用例规约中，用例模型 就是山用例图和用例规约所组成。用例规约组成虽然可以用流

18、程图、顺序图、Petri网或者程疗:设讣语言来表示用例，但是从根本上说, 用例是文本形式的。通常情况下，它们是作为人与人之间，尤其是没有受过专门培训人员 之间互相交流的一种手段。因此，简单的文本通常是编写用例的首选形式。简单说来，用例是由多个句子组成的，所有的句子都采用同一种语法形式个简单的执行步骤，通过执行这些步骤，执行者或者获得一定结果或者向另一个执行者传递信 息。用例的组成包括：1. 执行者(Actor)：任何具有行为的人或者物；2. 项LI相关人员(Stakeholder)：对被讨论系统的行为有特定兴趣的人或者物；3. 主执彳亍者(Primary actor)：启动与被讨论系统的一次交

19、互活动。从而达到某一 LI 标的人或者物；4. 用例(Use case)：规定被讨论系统行为的契约；5. 范圉(Scope)：界定被讨论的系统；6. 前置条件和保证(Precondition and guarantee)：在用例执行之前和之后必须满 足的条件；7. 主成功场景(Main success scenario)：切顺利的情况；8. 扩展(Extension)：场景执行过程中出现的异常情况；用例、用例图与需求百度文库-让每个人平等地捉升门我用例图(Use Case Diagram)是UML中最简单也是最复杂的一种视图，表示了执行者、 用例、以及它们之间的关系。主要用于描述系统功能的静态

20、视图以及各个功能之间的静态 关系。其采用了简单的图形符号来代表系统的用例集合，展示了系统需要实现的全部功能。 图是用例图的一个示例：图用例图示例用例规约和用例图是相互补充的。用例规约由文本组成，描述了一个执行者与系统进 行交互达到LI标的故事。但是阅读大量的文本信息可能给客户带来困扰，同时大量的文本 用例不能将系统的功能性需求一H了然的展现出来。而用例图作为文本用例的补充，弥补 了文本用例的这些不足。客户可以通过查看用例图即可知道系统所能满足的U标。特别在 需求分析阶段，山于信息获取的不足，分析人员也可以先将用例图构建出来，确定系统功 能的总体框架，然后再随着信息量的增多，来充实文本用例中的场

21、景。项目的需求，一般来说包括:珥1. 功能需求：专注于系统是“什么”，确定与“功能”和“数据”有关的需求；2. 非功能需求：专注于系统“有多好”的方面，并确定像“性能”、“可维护性”、“可 扩展性”、“可操作性”、“可靠性”和“可移植性”等属性以及确定系统要运行在什么“限 制”之下；3. 系统操作的限制因素；4. 同其他系统/操作者的接口。在当前的软件项訂开发中，用例被广泛地应用于捕获和描述需求。用例采用“以用户 为中心”的角度，而不是基于程序员的角度分析问题，这样能更好地帮助用户理解他们想 从LI标系统中得到什么以及他们如何与LI标系统交互。在捕获用例的过程中，用户可以通 百度文库让每个人平

22、等地捉升口我过角色一系统的对话来告诉项LI开发人员他们的真实需要。但是用例描述需求时，必须记 住以下两点叫1. 用例确实是需求。不必将用例转变成行为需求的其他形式，用例可以准确地对系统 必须要做什么进行详细的描述；2. 用例不是所有的需求。用例并不详细地描述外部接口、数据格式、业务规则和复杂 公式，它只是所有需求中的一部分即功能需求。虽然这一部分是非常重要的，但毕竟只是 一部分。也就是说，用例是需求的核心，甚至是项口开发过程中的核心元素，但它只是需求文 档的一部分，而不是所有的需求，用例表述的仅是行为需求，并且是所有的行为需求。业 务规则、词汇表、性能U标、过程需求和许多其他方面的东西都不属于

23、行为需求之列，但 依然可以在用例规约文档中有所体现。下面的图轮轴和轮辐需求模型形象地体现了用例和 需求的关系叫图轮轴轮辐需求模型7第三章国内外软件成本估算方法现状本章介绍了关于软件成本估算的相关研究，尤其是基于用例的软件工作量度量的研究。 首先在节描述了软件成本估算的发展和传统的六种软件成本佔算方法；节阐述了用例佔算 的可行性，为用例模型的建立做好铺垫；节着重描述了 Karner的用例点方法；节描述了另 外两种基于用例的工作量的估算方法，并指出他们模型的优缺点。现有的软件成本估算模型随着软件系统规模的不断扩大和复杂程度的日益加大，从20世纪60年代末期开始， 出现了以大量软件项U进度延期、预算

24、超支和质量缺陷为典型特征的软件危机，至今仍频 繁发生。根据Standish组织在1993年公布的CHAOS报告显示,在来自330个组织的8 000 个项目中，只有是“成功的(succeeded) 即能在预算和限期内完成；是“失败的 (failed)”，即未能完成或者取消；其余%被称为“被质疑的(challenged)虽然完成但平Standish report in 1995Standish report in 2004均预算超支89% (如图所示)。2004年，该组织的统计项目数累计达到50000多个，结果 显示，成功项H的比例提升到29%,而被质疑的项LI比例仍有53%so虽然有些研究认为，

25、 CHAOS报告中关于预算超支89%的数据被夸大了，实际情况应该平均在30%-40%。但有一点 却能够取得共识：人们经常对软件成本估算不足。它与需求不稳定并列，是造成软件项U 失控最普遍的两个原因。| SucceededFailedII Challenged图Standish咨询公司对软件项LI完成情况的统讣数据之后，无论在企业还是实验室，越来越多的人认识到，软件成本佔算是减少软件项口 预算超支问题的首要措施之一，不但有助于做出合理的投资、外包、竞标等商业决定，而 且有助于确定一些预算或进度方面的参考，为项H经理决策提供依据。美国南加州大学的 Barry Boehm教授所指岀的，“理解并控制软

26、件成本带给我们的不仅仅是更多的软件，而会 是更好的软件”同。因此，有效的估算成为了软件开发项口管理中最具挑战性也是最重要的活动。只有使 用科学的方法对软件项U的规模、工作量、进度与成本做出合理可靠的估算，才能实施良 好的项IJ计划与控制。然而由于各种原因，tJ前，项LI估算在软件开发中还是一个薄弱的 环节。最早的软件成本佔算研究可以追溯到20世纪60年代的SDC(System Development Corporation)线性模型，已历经了 40年的发展。随着研究的不断深入和发展，逐步形成 了多种方法。具有代表性的有算法模型、专家判断、类推、帕金森、价格策略、自顶向下、 自底向上等方法。算法

27、模型提供了一个或多个算法，这些算法产生的软件成本估算为一系列变量的函数, 这些变量被认为是主要的成本驱动因子；专家判断会涉及到咨询一个或多个专家，也许需 要专家组意见一致机制的辅助技术，如Delphi技术；类推涉及到通过类比进行推理，把一 个或多个已完成项LI的实际成本，与一个相似的新项LI的成本估算联系起来；帕金森方法 是利用“帕金森原理”一一工作会自动地膨胀占满所有可用的时间，是将成本估算等同于 可用资源；价格策略得到的成本佔算，等于人们所相信的要圆满完成工作所必需的价格； 自顶向下，一个项U的全部成本佔算源于软件产品的全部属性，先估算总成本，然后再分 散到各种组件中；自底向上，软件任务的

28、每个组件都独立的进行成本估算，然后将所有结 果总计起来就得到对全部任务的估算。它们的优劣比较见表卩表儿种软件成本估算模型比较列表方法优点缺点算法模型客观、可重复、可分析的公 式有效率、敬感性分析好能用经验来客观校准主观输入不能评估异常情况 校准的是过去的项目，不是将 来的专家估算 能对有代表性的项目进行迭代并不比参加者好有偏见，不完善的回忆百度文库-让每个人平等地捉升门我 特殊情况下的项目进行评 估类推基于有代表性的经验上经验的代表帕金森与一些经验相关联加强的是不良时间价格策略常得到合约通常产生大的超进度自顶向下能聚焦于系统级别上有效率不够详细的基础缺乏稳定性自底向上更为详细的基础更稳定培养个

29、人承诺也许忽略了系统级成本需要更多的工作量用例点估算可行性用例模型越来越多地用于捕获和描述软件系统的功能需求，可以有不同的途径和方法 使用用例估算工作量。一些硏究者试用了用例点方法，并分析了他们的发现。结果表明， 用例点方法有潜力成为估算的可靠素材，它与功能点方法类似；而且，软件开发项U的规 模对佔算结果影响很大，特别是当和专家估算法结合使用时。另外，用例建模技术的应用 日益广泛一一它不仅用于描述软件和系统需求，还是设计、开发、测试、部署、配置管理 和维护的基础一一因此，基于用例模型的估算方法是很有意义的。而软件规模或者工作量 的估算，常常是软件成本估算的基础，甚至两者可以等同。捕捉软件项U的

30、功能需求时，常使用用例模型。用例建模是一项业界广泛使用的技术, 用于描述和捕捉软件系统的功能需求。用例点(Use Case Point)是一项佔算软件开发工 作量的新方法。既然用例和场景技术已成为需求采集和分析的标准部分，并且它们捕捉了 用户需求的精确描述，那么，基于用例和场景进行更加困难的开发规模和资源的估算工作, 是很有意义的。基于用例估算的另一个优点是，通过使用现代需求管理工具，可维护其双 向可跟踪能力。可以在用例和多种软件工程工件之间，维护这种双向可跟踪能力，包括设 计、编码、测试、配置管理、架构和部署等相关的工件。Bente Anda (Anda 2001)比较了用例点方法和专家估算

31、法，后者是曲有经验的软件开发 者进行的。结果发现，用例点方法给出的估算和有经验的软件开发者给出的估算很接近。 该估算方法的相对误差值和相对误差平均值都在可接受范围内。研究结果表明，用例点方 法可以成功地用来估算软件开发工作量。用例点估算方法Earner方法Earner博士在1993年首先提出了的用例点方法。下面简单介绍Earner用例点估算 方法步骤。首先，将用例模型中的角色按照简单、一般和复杂三个等级来分类，并统计每 类角色的数量，分别乘以各自的权重系数(Weighting Factor),然后相加，得出总的未调 整角色权重(Unadjusted Actor Weight, UAW)。然后，

32、依据用例中的事务数量(包括备选 流中的交易)，将用例按照简单、一般和复杂三个等级来分类，并按如下步骤计算未调整用 例权重(Unadjusted Use Case Weights, UUCW):统计每类用例的数量,分别乘以各自的 权重系数，然后把这些乘积相加。最后，将UAW和UUCW相加，得到未调整用例点(Unadjusted Use Case Points, UUPC)。接下来，基于技术系数和环境系数调整用例点的值。每个系数是介于0到5之间的一 个值，具体由它们对整个项LI的假定影响来确定。该步骤相关的3个公式如下：技术复杂性系数：TCF=+*Tfactor)(公式)环境系数：EF二+Efac

33、tor)(公式)已调整用例点：UCP=UUCP*TCF*EF(公式)最终,UCP要乘以一个代表生产力的历史数据的系数，比如，每个用例点20人时(Person Hour),得到项LI估算结果一一完成项所需的人时总数。基于用例估算的其他方法基于用例的规模估算研究除了 Earner方法外，山于代码行和功能点被业界广泛使用， 所以也有一些研究人员研究用例向功能点，代码行的转换。下面介绍两种代表方法：1. 用例向功能点转换的方法由Thomas Fetke等人在1997年提出的一种按功能点方法，将面向对象的元素按照一 定规则进行转换从而得到所要构建的对象的功能点何。Thomas制定了一系列的基于IFPUG

34、 所提供的功能点计算方法将用例直接转换到功能点模型的规则和过程。用例虽然与功能点概念相似，但不完全等价，所以转换规则比较复杂，在实际中很难 运用。例如，用例中的参与者是处在系统之外的与系统进行交互的人或物，这个概念比功 能点方法中的用户及外部应用程序的概念要广，因此必须分类处理用例角色。同时必须将 用例细化到类的层次，这乂与用例的粒度划分有关2. 用例结合代码行估算IBM公司的John Smith在1999年提出了一种基于用例估算的框架他将系统分解为 SubSystem, SubSystemGroup, System, SystemOfSystem 四个级别，每个级别都有 10 个外 部用例以

35、及8个内部的相应级别的部件，每一个用例又有8个类，一个类有12个方法，这 样根据每个方法对应的基于C+的代码行数就可以估算处于任何一个层次的代码行数，利用 这个框架可以获得在用例的任何层次的规模和工作量估算，避开了用例估算中用例细化的 问题。但这种方法将用例与某种特定的编程语言绑定，造成了一定的局限性。25第四章基于用例的软件成本估算模型本章是论文的核心主体部分，主要介绍了本文建立的用例成本估算模型。节和节描述 了模型建立和使用的前提和注意事项，以及建模的整体思路；节剖析了用例规约文档，找 岀影响用例规模的关键因素；节详细阐述了本文模型的建立和使用步骤，计算出工作量参 数，并介绍了目前世界上使

36、用频率很高的Barry Boehm博士的构造性成本估算模型 (Constructive Cost Model, COCOMO),将得到的工作量参数带入公式，计算岀软件开发 的成本；节通过一个实际案例说明了本文模型的应用；节对模型的准确度进行了评价，说 明了模型的优缺点和未来的研究工作；节总结了基于用例的软件成本佔算模型；节实现了 一个用例估算模型的原型系统，更具体的说明模型的使用。建模假设每一个模型的建立都需要一定的条件限制，没有一个模型是符合所有的要求的。本文 的模型是建立在对用例规约文档分析基础上的，为了更好的应用模型为决策服务，保证模 型的简单性和稳定性，需要说明以下问题。1. 使用本文

37、基于用例的成本估算模型，建议开发时采用基于RUP的软件开发过程。即 使不采用RUP的开发方法，那也要在需求分析阶段使用用例进行业务建模和需求分析，这 是本文估算的基本前提；2. 本文用例模型是严格建立在用例规约文档基础上的，比较遗憾的是，口前国际上对 用例规约文档还没有一个统一的标准。但是每一个用例规约文档都有很多共同的关键点， 这为基于用例的成本估算提供了可能和便利。为了方便原型系统的开发与展示，本文使用 了一个比较通用的用例规约文档，详细请见附录一一用例规约文档；3. 软件开发是一个不断细化的过程，软件系统的概念也逐步细化为需求说明，需求说 明乂进一步细化为概要设计，概要设计再细化为详细设

38、计，详细设计最终细化为代码。在 每个阶段都可能做出影响最终产品的成本和开发进度的决策，所以产品充满了不确定性。 这种不确定性直接导致了成本佔算的不确定性。因此，软件成本估算是一个逐渐改进的过 程，它将贯穿于整个产品开发的主命周期，需要使用在开发阶段监控中所采集的数据通过 在每一步实际数据与佔算数据进行比较来改进下一步的估算精确度。本文所使用的用例估 算模型，是基于用例规约文档，为需求分析阶段的估算提供一定的依据，随着项LI开发阶 段的深入，用例模型的完善，应该结合具体的数据对模型进行不断的修正和改进，以便为 系统的开发提供不断的依据；4. 没有任何一个估算方法可以在所有方面都做的比其他方法出色

39、。本文的模型也不 例外，例如，面对一个完善规范的用例文档时，使用它估算可以更好指导决策，但当项U 缺乏有力的用例模型支持时候，它的功能也会大打折扣。建模思路本文采用的用例估算模型与前人的用例估算模型不同，Earner等人专注于用例点本身 或者用例向功能点的转化进行佔算，而本文专注于用例规约文档带给人们的信息。用例规 约文档是对每个用例的完整描述，包含了大量的有用信息。用例图给人一种直观的感受， 让客户，开发人员可以了解整个场景，而用例规约文档则更加详细具体，它可以显示出用 例图本身没有的信息，包括用例的执行，事务流等信息。前人的研究中，用例的粒度划分也是一个比较重要的问题。用例的粒度直接影响用

40、例 点。到底是一个大的用例合适还是分解成多个小用例合适呢？这个问题并没有一个标准的 规则，需要根据不同阶段的需求来进行不同的划分，但这样就给用例点的估算带来了不便, 也为向功能点的转换规则和过程带来了不便。业界用例粒度的划分依据标准是一个用例的 粒度是否合适，是以该用例是否完成了参与者的某个LI的为依据的。但用例文档规约受用 例粒度划分的影响比较小，因为用例规约主要山事件流进行刻画，大粒度用例事件流数量 一定比小粒度用例的多，这样为软件规模估算和成本估算都带来了便利。已有的基于用例成本佔算模型，往往需要考虑很多成本驱动因子对模型结果的影响， 如Earner模型考虑环境因素，技术因素等。本文的基

41、于用例的成本佔算模型是以Barry Boehm博士的COCOMO II模型为基础的，在COCOMO模型中已经考虑了足够的成本驱动因子。 另外，用户在使用COCOMO模型过程中，输入的KSLOC的偏差往往比较大，缺乏模型支持， 导致最终的估算结果不理想。因此，本文的思路是基于用例建模得出源代码千行数(KSLOC),然后代入COCOMO II 模型进行计算，从而改善用户主观猜测，KSLOC的潜在误差状况。本文模型的关键就在于将 用例模型与项LI规模建立相关数学关系，算出源代码千行数(KSLOC),软件的成本自然可 以估算。COCOMO模型已经考虑了完整的成本驱动因子，并且考虑了软件开发过程中的估算

42、, 所以，只要专注于基于用例的软件规模估算，即可达到估算成本的U的。用例规约文档结构分析本文采用的用例规约文档请见附录一一用例规约文档，现在对用例规约文档进行结 构分析，虽然用例不会受环境，技术等因素的影响，但它却受用例规约内部的要素的影响。 因此，区分用例中影响软件规模的关键因素和其他因素是非常必要的。跳过笫一部分简介和第二部分用例模型图，从第三部分具体用例开始分析。主要分析 每一个用例对应的用例规约。用例的名称和简要说明是对这个用例的简要介绍，对软件的规模没有影响，是非关键 因素。参与者是用例的重要组成部分，它是与系统直接进行交互的有具体行为的事务，可 能是人、公司、组织等。人可能是不同的

43、角色，比如用户、经理等。参与者不同的角色和 数量会影响最后软件规模的大小，因此参与者是影响规模的因素之一。事件流是一个用例 的主体部分，对用例的规模有直接的影响，反映了用例的复杂程度和执行步骤，因此是影 响软件规模最为关键的因素。前置条件、触发条件和后置条件是用例执行之前和之后的满足条件，前置和触发条件 是很多山其他因素引起的，对软件规模没有很大影响。后置条件是执行用例后的结果，对 软件规模的影响也很小。本文模型将三者均定为非关键因素。这里的其他需求包括了非功能需求、数据、业务规则和界面约束四个方面。其中，非 功能需求通常分为可用性需求、可靠性需求、性能需求以及可替换性需求。它们通常是指 需要

44、符合任意法律法规要求的需求。它们也可以是山于所使用的操作系统、环境平台、兼 容性或所采用的任何应用标准等问题产生的设计约束。许多非功能性需求适用于一个单独 的用例，并且可以在该用例的特征内获得这些需求。在这种惜况下，这些需求可以在用例 的事件流内获取。所以，一般非功能需求都包含在补充用例规约中，也体现在事件流中， 所以本文不予以考虑；数据是对用例数据流中操作的限制条件，业务规则是对业务执行过 程的限制，也是影响事件流的一个规约，界面约束规定了界面的要求，因此这三者也是影 响软件规模的因素。综上所述，本文关注的影响因素有参与者、事件流、其他需求中的数据、业务规则和 界面约束。基于用例的软件成本估

45、算模型建模基于用例佔算软件规模，事件流是用例的主体，对规模影响最大，是模型的主体；参 与者，其他需求是影响软件规模的乘数因子（HG）。文中的权重和乘数因子比例，均根据经 验项L1数据和已有用例点估算方法中数据调整而来:役4. 4.1计算用例规模的权重事件流是用例的主体部分，是用例规模的有效衡量部分。事件流乂分为主事件流和扩 展事件流，两者对软件工作量的影响权重是不同的。主事件流对软件规模影响要大于扩展 事件流。本文根据用例规约文档中主事件流数量和扩展事件流的数量衡量用例的复杂程度。 事件流的复杂程度分类规则如表,:表主事件流的权重因子表用例类型判断规则权重因子简单主事件流的数目小于等于310中

46、等主事件流的数目在4到7之间15复杂主事件流的数目多于720因此，根据表得出以下公式:（公式）用例主事件流的权重（UPEW）=刀相应主事件流的用例数*权重因子表 扩展事件流的权重因子表用例类型判断规则权重因子简单扩展事件流的数目小于等于55复杂扩展事件流的数目大于57因此，根据表得出以下公式：用例扩展事件流权重（UEEW） =相应扩展事件流用例数*权重因子（公式）根据公式和公式，可以得出用例事件流的权重公式：用例事件流的权重（CEW）=主事件流权重（UPEW） +扩展事件流权重（UEEW）（公式）4. 4. 2确定参与者的乘数比例参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,

47、他们代表的是 系统的使用者或使用环境。参与者是曲所开发的系统边界决定的，不同的边界，反映了不 同的参与者。一般情况下，不会将一些系统的组成结构抽象为参与者。如一个ATM机系统, 边界一般为银行系统，而不仅仅是ATM机。这样，后台服务器系统是属于系统的一部分而 不是参与者。考虑到不同角色的参与者会有不同的操作流程，对软件规模有一定的影响。 主要分为标准和复杂两个类别，并对每一个类别分配一个权重因子，如表：表参与者乘数因子表参与者类型判断规则乘数因子标准项目中小于四种角色1复杂多于四种角色的参与者4. 4.3确定其他需求的乘数比例其他需求中影响软件规模的因素有数据、业务规则和界面约束。其中，业务规

48、则和界 面约束相对于数据对软件规模有更大的影响。本文将业务规则乂分为两大类。一种是全局规则，这种规则一般与所有用例都相关而 不是与特定用例相关。例如Actor要操作用例必须获得相应的授权，用例的操作与授权级 别相关，或者用户在系统中的所有操作都要被记录下来等等；另一种是特定规则。所谓特 定规则是指事件本身具备的规则，并且不因为外部的交互而变化的规则。例如，每张定单 至少要有一件商品，同一类商品数量不能大于5件等。同时也包括大家所熟悉的数据校验 规则，例如身份证号必须是15或18位，邮编必须是6位等。这类规则是事件流的内在规 则。全局规则一般都在整体之外，而特定规则一般都包含在每一个用例之内，包

49、含在每一 个用例规约之中。根据项口所包含的特定规则的用例数LI,分为标准，中等和复杂三类。 业务规则的具体分类见表：表业务规则的乘数因子表用例类型判断规则乘数因子全局规则全局文档中，不在用例规约中特定规则标准项目中所有的用例没有业务规则中等项目中一半以下的用例没有业务规则复杂项目中多于一半的用例有业务规则界面的好坏和复杂程度对软件规模也会产生一定的影响。因此，按照界面约束的数H 来确定相应用例类型的乘数因子也是必要的。具体见表所示：表界面约束的乘数因子表用例类型判断规则乘数因子简单界面约束条件小于等于3复杂界面约束条件大于等于44. 4.4估算源代码千行数（KSLOC）计算了事件流关键因素的权

50、重值和各个乘数因子后，进一步讣算用例规模值，具体公 式如下：项目规模值（PS）=用例事件流权重（UEW） *参与者乘数因子*业务规则乘数因子*界面约束乘数因子（公式）用字母表示，数学公式为：PS = （UEV） 匸MQ（公式）i=i其中，HG是乘数因子，包括参与者，业务规则和界面约束。根据有关的项LI数据，将用例权重值与项LI规模，即源代码千行数比较建模。用例的 权重与用例的规模是呈简单的线性关系，需要用一个比例系数来调整，这个比例系数符号 为R,建模如公式：KSLOC = R*（UEW）（公式）1=1公式中R的值需要根据项U数据调整，这里取l/12o这样就计算出了 COCOMOII模型所需的

51、关键参数一一源代码千行数(KSLOC)o4. 4. 5估算软件成本4. 4. 5. 1 C0C0M0 模型介绍C0C0M0模型是山Barry Boehm博士在20世纪70年代后期提出的突破性的软件成本估 算模型这个模型在他的经典著作中进行了详细描述。模型具有独到的视点，精辟的分析 方法和开发的模型细节，得到了广大用户的认可，成为了 20年来应用最为广的软件成本估 算模型。随着时代的进步，为了适应现代软件开发过程，方法，工具和技术的发展，Barry Boehm 博士和他实验室的同事一起，继续不断的对模型进行更新、改进和扩展，并于20世纪90 年代后期提出了 C0C0M0 I严:。C0C0M0 I

52、I不仅是对1981年提出的C0C0M0经典模型的继承和改进，而且对成本驱动因 子进行了调整和更新，加入了许多现代软件开发过程和各种构造方法。1981年的模型被称 为C0C0M0 81,而C0C0M0 II模型是根据数据库中161个项口的实际参数和工作量的值对 C0C0M0 81进行修正得到的。C0C0M0 81模型是COCOMO II模型的基础，本文采用COCOMO II 入手进行成本估算建模。C0C0M0模型的基本原理是将软件开发所需的工作量表示为软件规模和一系列成本因子 的函数，C0C0M0 81包括了三个详细度和精确度递增的子模型：基本模型、中等模型和详细 模型。C0C0M0 II模型是

53、对C0C0M0 81模型的改进和参数的进一步修正。EM为工作量的乘 数，SF值代表指数比例因子，A, B, C, D是系数，取值根据项目数据库来校准。如表所示，是C0C0M0 II的模型公式，表是COCOMO II模型中的各种成本驱动因子。表COCOMO II模型的成本估算公式匸作量值：PM =A*(KSLOC)jfEM”(公式)i=i其中，e = +o.oi*sf;问进度公式：TDEV = C(PM)f (公式)其中，F = D + 02*001水巧j= D + 0.2*(E-B)COCOMO II2000校准时的系数值：A= B 二C 二 D =表COCOMO II2000模型中的成本驱动

54、因子产品因子项目因子人员因子平台因子RELY要求的软件 可靠性TOOL软件工具的 使用ACAP分析员能力TIME执行时间约 束DATA数据库规模SITE多点开发PCAP程序员能力STOR主存储器约 束CPLX产品复杂性SCED要求的开发进度PCON人员连续性PVOL平台易变性RUSE可复用开发AEXP应用经验DOCU匹配生命周 期需求的文档编 制PLEX平台经验LTEX语言和工具经验表中的每个成本驱动因子对应一个乘数EM值，将每个项U的EM值相乘带入COCOMO的 公式中即可得出软件成本值和开发进度。4.4. 5.2基于用例的软件成本估算模型COCOMO系数和各个成本驱动因子乘数给定的情况下，

55、只有KSLOC这个重要的参数值没有确定。根据公式：KSLOC = R*（UEW）（公式）1=1可以计算出KSLOC的值，然后将其带入公式PM =A*（KSLOC）jffEMj（公式）i=i计算出所需的人月数（PM）,将人月数带入公式tdev = c*（pm）f（公式）计算出项U开发所需要的进度。整个基于用例的软件成本估算模型建立完成。模型应用-案例分析以一个简单的人力资源管理工具项H为例，提取了项H用例相关信息如表所示:表人力资源管理工具用例信息功能模块用例名称参与者事件流数其他需求人力资源管理登录Admin, PM,Staff主8,扩展1无系统管理Admin主7,扩展3无查询员工信息Admin, PM,Staff主7,扩展5无项目基本信息管理PM主8,扩展6无员工时间安排PM主9,扩展2无员工工作量安排PM主9,扩展2无员工能力评估PM主8,扩展1无全局规则界面约束1,业务规则2注：表中Admin：系统管理员；PM：项H经理；Staff：员工。运用基于用例的软件成本估算模型的估算过程如下:第一步，计算用例规模的权重，见表：表用例规模权重