cosmic方法和准确性的研究与应用论文.doc

《cosmic方法和准确性的研究与应用论文.doc》由会员分享，可在线阅读，更多相关《cosmic方法和准确性的研究与应用论文.doc（47页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、.i/47工程硕士学位论文COSMICCOSMIC 方法与其准确性的研究与应用方法与其准确性的研究与应用软件规模度量与其准确性的研究与应用国防科学技术大学研究生院.COSMICCOSMIC MethodMethod andand ItsIts A AccuratccuratenessenessResearchResearch andand ApplicationApplicationCandidateCandidate：JiangJiang HuiHuiAdvisorAdvisor：YinYin JunJunW WenenA A thesisthesisSubmittedSubmitted i

2、nin partialpartial fulfillmentfulfillment ofof thethe requirementsrequirementsforfor thethe professionalprofessional degreedegree ofofMasterMaster ofof EngineeringEngineeringinin ComputerComputer EngineeringEngineeringGraduateSchoolGraduateSchool ofNationalUniversityofNationalUniversity ofof Defense

3、Defense.2/47TechnologyTechnologyChangshaChangsha，HunanHunan，P.R.ChinaP.R.China（OctoberOctober，20082008）毕业设计（论文）原创性声明和使用授权说明毕业设计（论文）原创性声明和使用授权说明原创性声明原创性声明本人重承诺：所呈交的毕业设计（论文），是我个人在指导教师的指导下进行的研究工作与取得的成果。尽我所知，除文中特别加以标注和致的地方外，不包含其他人或组织已经发表或公布过的研究成果，也不包含我为获得与其它教育机构的学位或学历而使用过的材料。对本研究提供过帮助和做出过贡献的个人或集体，均已在文中作

4、了明确的说明并表示了意。作 者签 名：日期：指导教师签名：日期：使用授权说明使用授权说明本人完全了解大学关于收集、保存、使用毕业设计（论文）的规定，即：按照学校要求提交毕业设计（论文）的印刷本和电子版本；学校有权保存毕业设计（论文）的印刷本和电子版，并提供目录检索与阅览服务；学校可以采用影印、缩印、数字化或其它复制手段保存论文；在不以赢利为目的前提下，学校可以公布论文的部分或全部容。作者签名：日期：.3/47学位论文原创性声明学位论文原创性声明本人重声明：所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。除了文中特别加以标注引用的容外，本论文不包含任何其他个人或集体已经发表或撰写的

5、成果作品。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律后果由本人承担。作者签名：日期：年月日学位论文使用授权书学位论文使用授权书本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权大学可以将本学位论文的全部或部分容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。涉密论文按学校规定处理。作者签名：日期：年月日导师签名：日期：年月日.4/47指导教师评阅书指导教师评阅书指导教师评价：指导教师评价：一、撰写（设计）过程1、学生在论

6、文（设计）过程中的治学态度、工作精神 优 良 中 与格 不与格2、学生掌握专业知识、技能的扎实程度 优 良 中 与格 不与格3、学生综合运用所学知识和专业技能分析和解决问题的能力 优 良 中 与格 不与格4、研究方法的科学性；技术线路的可行性；设计方案的合理性 优 良 中 与格 不与格5、完成毕业论文（设计）期间的出勤情况 优 良 中 与格 不与格二、论文（设计）质量1、论文（设计）的整体结构是否符合撰写规？优 良 中 与格 不与格2、是否完成指定的论文（设计）任务（包括装订与附件）？优 良 中 与格 不与格三、论文（设计）水平.5/471、论文（设计）的理论意义或对解决实际问题的指导意义 优

7、 良 中 与格 不与格2、论文的观念是否有新意？设计是否有创意？优 良 中 与格 不与格3、论文（设计说明书）所体现的整体水平 优 良 中 与格 不与格建议成绩：建议成绩：优优良良中中与格与格不与格不与格（在所选等级前的画“”）指导教师：指导教师：（签名）单位：单位：（盖章）年年月月日日.评阅教师评阅书评阅教师评阅书评阅教师评价：评阅教师评价：一、论文（设计）质量一、论文（设计）质量1、论文（设计）的整体结构是否符合撰写规？优 良 中 与格 不与格2、是否完成指定的论文（设计）任务（包括装订与附件）？优 良 中 与格 不与格二、论文（设计）水平二、论文（设计）水平1、论文（设计）的理论意义或对

8、解决实际问题的指导意义 优 良 中 与格 不与格2、论文的观念是否有新意？设计是否有创意？优 良 中 与格 不与格3、论文（设计说明书）所体现的整体水平 优 良 中 与格 不与格建议成绩：建议成绩：优优良良中中与格与格不与格不与格（在所选等级前的画“”）评阅教师：评阅教师：（签名）单位：单位：（盖章）年年月月日日.ii/47教研室（或答辩小组）与教学系意见教研室（或答辩小组）与教学系意见教研室（或答辩小组）评价：教研室（或答辩小组）评价：一、答辩过程一、答辩过程1、毕业论文（设计）的基本要点和见解的叙述情况 优 良 中 与格 不与格2、对答辩问题的反应、理解、表达情况 优 良 中 与格 不与格

9、3、学生答辩过程中的精神状态 优 良 中 与格 不与格二、论文（设计）质量二、论文（设计）质量1、论文（设计）的整体结构是否符合撰写规？优 良 中 与格 不与格2、是否完成指定的论文（设计）任务（包括装订与附件）？优 良 中 与格 不与格三、论文（设计）水平三、论文（设计）水平1、论文（设计）的理论意义或对解决实际问题的指导意义 优 良 中 与格 不与格2、论文的观念是否有新意？设计是否有创意？优 良 中 与格 不与格3、论文（设计说明书）所体现的整体水平 优 良 中 与格 不与格评定成绩：评定成绩：优优良良中中与格与格不与格不与格（在所选等级前的画“”）教研室主任（或答辩小组组长）：教研室主

10、任（或答辩小组组长）：（签名）年年月月日日教学系意见：教学系意见：系主任：系主任：（签名）年年月月日日.iii/47插入独创性声明页插入独创性声明页本人声明所呈交的论文是我个人在导师指导下进行的研究工作与取得的研究成果。尽我所知，除了文中特别加以标注和致中所罗列的容以外，论文中不包含其他已经发表或撰写过的研究成果；也不包含为获得国防科技大学或其它教育机构的学位或证书而使用过的材料。与我一同学习的同学对本研究所做的任何贡献均已在论文中做了明确的说明并表示意。学位论文题目：学位论文题目：学位论文作者签名：日期学位论文作者签名：日期年年月月日日学位论文使用授权书学位论文使用授权书本人完全了解国防科学

11、技术大学有关保留、使用学位论文的规定。本人授权国防科学技术大学可以保留并向国家有关部门或机构送交论文的复印件和电子文档，允许论文查阅和借阅；可以将学位论文的全部或部分容编入有关数据库进行检索，可以采用复印、缩印或扫描等复制手段保存、汇编学位论文。（学位论文在解密后适用本授权书）学位论文题目：学位论文题目：学位论文作者签名：日期学位论文作者签名：日期年年月月日日作者指导老师签名：日期作者指导老师签名：日期年年月月日日.iv/47.I/47目目录录摘要 iABSTRACTi第一章绪论 11.1 论文研究背景 11.2 国外软件估算研究现状 21.2.1 国研究现状 21.2.2 国外研究现状 21

12、.3 准确估算的重要性 111.4 论文的主要工作 31.5 论文的组织结构 3第二章软件规模度量基础理论 32.1 软件规模度量 32.1.1 代码行方法 42.1.2 DELPHI 法 42.1.3 类比方法 52.1.4 价格胜算法 62.1.5 功能点分析方法 62.2 软件需求与规模度量 92.2.1 软件需求 92.2.2 规模度量对软件需求的作用 102.3 软件规模度量在软件项目估算中的重要性 12第三章 COSMIC 方法 123.1 COSMIC 方法的由来 133.2 COSMIC 方法的基本思想 133.3 COSMIC 方法的两个模型 143.3.1 软件上下文模型

13、143.3.2 COSMIC 通用软件模型 143.4 COSMIC 方法的基本概念 153.4.1 软件层次的定义 153.4.2 边界的定义 163.4.3 功能用户的定义 16.II/473.4.4 功能过程的定义 163.4.5 触发事件 163.4.6 数据组的定义 173.4.7 感兴趣对象的定义 173.4.8 数据属性的定义 173.4.9 数据移动的定义 173.5 COSMIC 方法的基本过程 183.5.1 COSMIC 方法的三个阶段 193.5.2 识别软件层次 203.5.3 划分粒度级别 213.5.4 识别边界 223.5.5 识别功能过程（Function P

14、rocess）223.5.6 识别数据组 233.5.7 识别数据属性 233.5.8 识别数据移动 233.5.9 执行度量与汇总结果 243.6 COSMIC 方法的优势和问题 24第四章 COSMIC 方法的准确性研究 254.1 三种主流功能点方法的比较 254.1.1 联系 254.1.2 区别 264.2 COSMIC 方法的优势与不足 274.2.1 需求风险 274.2.2 COSMIC 方法使用不正确 284.2.3 度量人员对业务不熟悉 284.2.4 应用的复杂性 284.2.5 缺乏历史项目数据和经验知识 284.2.6 度量规模时遗漏某些功能 284.2.7 来自客户

15、和高层领导的压力 284.2.8 功能点与代码行的不当转换 284.2.9 没有重估 284.3 软件规模度量风险管理模型 28第五章第五章题目 29.III/47结束语 29致 29参考文献 29作者在学期间取得的学术成果 30附录 A附录 A 题目 30附录 B附录 B 题目 30表目录表 1.1 表 1.1 名称错误！未定义书签。错误！未定义书签。表 1.2 表 1.2 名称错误！未定义书签。错误！未定义书签。表 2.1 表 2.1 名称错误！未定义书签。错误！未定义书签。表 2.2 表 2.2 名称错误！未定义书签。错误！未定义书签。表 3.1 表 3.1 名称错误！未定义书签。错误！

16、未定义书签。表 3.2 表 3.2 名称错误！未定义书签。错误！未定义书签。表 3.3 表 3.3 名称错误！未定义书签。错误！未定义书签。表 4.1 表 4.1 名称错误！未定义书签。错误！未定义书签。表 4.2 表 4.2 名称错误！未定义书签。错误！未定义书签。图目录图 1.1图 1.1 名称错误！未定义书签。错误！未定义书签。图 1.2图 1.2 名称错误！未定义书签。错误！未定义书签。图 1.3图 1.3 名称错误！未定义书签。错误！未定义书签。图 2.1图 2.1 名称错误！未定义书签。错误！未定义书签。图 2.2图 2.2 名称错误！未定义书签。错误！未定义书签。图 4.1图 4

17、.1 名称错误！未定义书签。错误！未定义书签。图 5.1图 5.1 名称错误！未定义书签。错误！未定义书签。图 5.2图 5.2 名称错误！未定义书签。错误！未定义书签。.i/47摘要（学位论文摘要）主题词：（主题词 1）（主题词 2）ABSTRACT（Abstract）Key Words：（Key Words 1）（Key Words 2）.1/47第一章绪 论1 1.1.1 论文研究背景论文研究背景软件规模度量是制定软件项目开发计划的基础和依据，度量是对软件项目进行量化分析和项目可行性分析的前提条件，是项目成本估算、进度安排、质量评估和资源规划的基础。在软件业，需求风险与估算风险被认为是软

18、件项目开发过程中最主要的两个风险1。软件规模度量不准确、不合理，会导致不合理的进度安排、资源和质量目标，最终导致软件项目预算超支、进度延期以与质量失控等后果，使项目面临无法挽救的灾难局面，犹如死亡行军。全世界每年大约有 50 万个项目执行着 100 万个左右的软件项目，产生了 6000亿美元的软件产品。在这些项目中，有很多不能满足客户所期望的质量，或者不能在预算按时交付软件，有分析认为：1/3 左右的项目在成本和进度上超出了额定限度的 125%以上。（R.L.Glass.Software Runaway:Lessons learned from MassiveSoftware Project

19、Failures.Prentice Hall PTR,1998）在软件开发实践中，由于软件成本估算不足或者不准确，直接导致许多软件项目开发失败，根据Standish Group 组织 2003 年公布的数据显示，有 15%的软件项目在没有任何产出的情况下被终止，有 66%的软件项目被认为是失败的，而且，该组织 2004 年第三季度的报告还指出，成功开发的软件项目只占 29%，失败项目占到了 18%，有 89%的项目都有预算超支的情况发生。另外，据 ISBSG 数据组织统计，美国 2002 年软件项目损失高达 380 亿美元，这还不包括预算超支的 170 亿美元31。虽然这些数据有可能是被夸大了

20、，但是有一点是可以肯定的：由于早期对软件成本的估算不 足，或 者 是 由 于 需 求 不 稳 定，有 大 量 的 软 件 项 目 开 发 失 败。来 自standishgroup官方。软件规模度量历来是比较复杂的，其围大至软件项目管理活动，小则可为一个程序的设计，是一件困难度颇高的任务。因为软件本身的复杂性、历史经验知识和项目数据的缺乏、度量工具缺乏以与一些人为错误，导致软件项目的规模度量往往和实际情况相差甚远。而软件估算错误已经被公认为软件项目失败的四大原因之一。因此，在软件工程领域，不论工业界还是学术界，软件规模度量已经是一个重要的研究方法。软件成本估算是项极其复杂的工作。因为影响软件成本

21、的因素很多，而这些因素又很难把握，但作为开发者却必须在软件开发之初就要向客户做出一定的承诺，所以，开发者能否控制项目，保证项目能够按预期的方向、计划和要求进行至关重要1。而控制项目，制定合同的关键是顾客、开发者对软件“大小”的了.2/47解，也就是软件经过估算得到的软件的规模、工作量、成本和进度。在这之中，软件的成本、工作量与进度估算都是以软件的规模为输入的，规模估算的好坏直接影响着项目的后续工作，因此规模估算非常重要4。1.21.2 国外软件估算研究现状国外软件估算研究现状1.2.11.2.1 国研究现状国研究现状国软件项目开发的管理目前正逐步向规化发展，但是在开发周期的估算上绝大部分还是处

22、于手工作坊的状态。主要表现在以下两个方面：一方面，项目管理人员意识上没有是认识估算的重要性，认为估算就是一个大概的估计，通常凭借主观经验“拍脑袋”得出的，很多还受限于商业行为，比如说为了签订合同而不惜压缩开发工作量；这样使得软件开发组织在项目开发后期可能会陷入成本、进度和质量的困境，甚至被客户拒绝接受产品。另一方面，由于没有专门的工具来辅助估算，或者说没有专门对估算进行研究。一个软件项目的规模究竟多大、开发费用究竟多少以与开发周期究竟多久，这些问题基本上是依靠估算人员的经验来判断，而这种经验带有很大的主观性和片面性。不同经验的人估算出的结果相差很大，而更糟糕的是这种判断由于完全凭借经验使得不同

23、意见的人之间很难沟通，因为谁都没有确切的量化标准来支持自己的判断，最终的结果往往是以“专家”的估算为准。实际上，国的软件项目开发需要的正是这种定量估算，这样做不仅规而且精确，十分有助于软件行业的健康发展以与与国际接轨。国在软件估算领域，主要还停留在学术上的研究，还没有真正运用到软件开发公司的实际活动中。还没有形成基于国开发环境的估算方法和技术。研究主要是在国外的估算方法基础上进行本地化研究和扩展研究。1.2.21.2.2 国外研究现状国外研究现状国外发达国家在软件估算上比国要成熟得多，从 20 世纪 50 年代软件业诞生到 20 世纪 70 年代，软件项目估算都是手工进行的，使用简单的经验法则

24、或经过反复摸索自己开发出的估算算法。从 20 世纪 70 年代早期到 1987 年，现代软件项目估算业的核心开始形成。至今，国外发达国家在软件估算领域比国要成熟的多，不仅有很多方法比如代码行估算法、功能点估算法、人力估算法，而且还形成了专业化的估算工具来辅助这项工作。比如微软公司开发的项目管理工具软件Project、加拿大 Software Productivity Center Inc.公司开发的 Estimate，都.3/47是比较成熟的估算辅助工具。采用辅助工具对软件开发周期进行估算具有明显优势。因为辅助工具是在大量不同类型项目数据研究的基础上总结开发出来的，采用的估算方法已经成熟，估算

25、结果的准确性有保障。由于这种估算过程是可以量化的，而非依据个人经验直接得出结果，所以在结果的评断上有据可依，有理可推。而且长期依靠工具辅助估算可以将大量项目的数据和估算结果积累形成历史经验库，从而对新项目的估算进行对比调整，从而提高估算的准确性。1.31.3 论文的主要工作论文的主要工作软件项目开发必须经过估算来得到软件的工作量、成本和进度的大概情况，并且用这些估算结果来制定合同、项目计划、对客户作出承诺，控制项目，保证项目能够按预期的方向进行。但是软件的成本、工作量与进度估算都是以即将构建的软件的规模为输入的，规模度量的准确与否直接影响着项目的后续工作，因此，规模度量是非常重要的。本论文的主

26、要工作与研究成果在于：1.41.4 论文的组织结构论文的组织结构论文的组织结构共分为六章。第一章：绪论。阐述了论文研究的背景、国外研究现状以与论文的主要工作。第二章：软件规模度量基础理论。主要阐述了目前几种常见的规模度量方法，分析了软件需求与规模度量之间的紧密关系以与软件规模度量在软件项目估算中的重要地位。第三章：主要阐述 COSMIC 方法的基本原理和使用过程。第四章：通过长期对 COSMIC 方法的研究和实践，针对 COSMIC 方法在软件规模度量过程中存在的一些主要问题进行了分析和探讨，提出了软件规模度量风险管理模型。第五章：案例分析第六章：工作总结和未来展望。第二章软件规模度量基础理论

27、2.12.1 软件规模度量软件规模度量任何种类的软件在开发前期，都需要对软件的规模大小进行度量。软件的规.4/47模大小直接影响了软件开发项目的设置和管理，正确度量即将开发的目标软件规模，为其制定合体的开发计划，提高软件项目成功开发的概率。我们这里所研究的软件规模度量是指软件的功能性规模进行度量，是对必须提交给用户的软件功能进行量化的过程。软件开发项目规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。规模度量是软件项目失败的重要原因之一。一个好的规模度量模型可以解决这一问题。有效的软件规模度量是成功项目的核心要素：基于有效的软件规模度量可以

28、策划合理的项目计划，合理的项目计划有助于有效地管理项目。规模度量的要点在于：由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。软件规模度量有助于软件开发团队准确把握开发时间、费用分布以与缺陷密度等等。软件规模的度量方法主要有以下几种：2 2.1.1.1.1 代码行方法代码行方法代码行（LOC）度量是对软件规模大小的直接度量，是软件开发者在软件规模度量中最早使用也是最直观的方法12，已形成很完整的模式13。在用代码行度量规模时，常会被描述为源代码行(source lines of code，简称 SLOC)或者交付源指令(delivered sourc

29、e instruction，简称 DSI)，目前成本估算模型通常采用非注释的源代码行。虽然代码行仍是目前普遍采用的一种方式，但它也存在局限性：（1）对代码行没有公认的可接受的标准定义。例如，最常见的计算代码时的分歧有空代码行、注释代码行、数据声明、复用的代码，以与包含多条指令的代码行等。在 Jones 的研究中发现，对同一个产品进行代码行计算，不同的计算方式可以带来 5 倍之大的差异14。（2）代码行数量依赖于所用的编程语言和个人的编程风格15。因此，计算的差异也会影响用多种语言编写的程序规模，进而也很难对不同语言开发的项目的生产率进行直接比较。（3）在项目早期，需求不稳定、设计不成熟、实现不

30、确定的情况下很难准确地估算代码量，不适合用于项目早期度量。（4）代码行强调编码的工作量，只是项目实现阶段的一部分16。2.1.2DELPHI2.1.2DELPHI 法法DELPHI 方法是一种专家评估技术，在没有历史数据的情况下，这种方法是用于评定过去与将来，新技术与特定程序之间的差别，但专家“专”的程度与对项目的理解程度是工作中的难点，但是这种方法对决决定其他模型的输入时特别有.5/47用。DELPHI法是60年代初美国兰德公司的专家们为避免集体讨论存在的屈从于权威或盲目服从多数的缺陷提出的一种定性预测的情报分析方法，在我国更习惯于将德尔菲法称为专家预测法。为了消除成员间相互影响，参加的专家

31、可以互不了解，它运用匿名方式反复多次征询意见和进行背靠背的交流，以充分发挥专家们的智慧、知识和经验，最后汇总得出一个能比较反映群体意志的预测结果。该方法与其派生技术已被广泛应用于各个领域49。这种方法的优势在于不需要历史数据，适合新项目；局限性是主观，专家技术带来误判。基本步骤为：1）主持人事先发给每位专家一份有关委托评估软件的说明书和一测算表。测算表中应包括：系统软件名称、填表日期、程序源代码估计值：乐观值（最少行数)、最可能值、最不利值(最多行数)以与简要理由；2）召开小组会议。会上，专家们可就不明白的问题向主持人询问，专家之间也可讨论。如有可能，主持人应向专家介绍与委托评估软件相类似系统

32、软件的有关情况，供专家参考；3）专家们无记名填测算表；4）主持人对测算表进行汇总，计算出第 i 位专家的测算期望值与全部专家的测算期望值和均方差；5）召开小组会议，公布测算期望值和均方差，让专家们充分发表意见并加以讨论；6）按讨论后认识的一致性程度和均方差大小决定要否重复上述 3-5 步工作程序；7）按最后一轮无记名填表所得的侧算期望值作为委托评估软件的软件规模。本方法的优点在于，先匿名填表，每个专家均需经过独立思考，作出测算，因而在讨论时有利于提出自己的见解，并通过多次反复，使意见逐渐趋于一致。2.1.32.1.3 类比方法类比方法类比法（Analogy）适合评估一些与历史项目在应用领域、环

33、境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度。因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的50。其基本步骤是：1）整理出项目功能列表和实现每个功能的代码行；.6/472）标识出每个功能列表与历史项目的一样点和不同点，特别要注意历史项目做得不够的地方；3）通过步骤 1 和 2 得出各个功能的估计值；4）产生规模估计。软件项目中用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查己存在的代码，估算出新项目可重用的代码

34、中需重新设计的代码百分比、需重新编码或修改的代码百分比以与需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行1：等价代码行=(重新设计%+重新编码%+重新测试%)/3*已有代码行比如：有 2000 行代码，假定 30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为：(30%+50%+70%)/3*2000=1000 等价代码行。也就是说，重用这 2000 代码相当于编写 1000 代码行的工作量。2.1.42.1.4 价格胜算法价格胜算法价格胜算法（Price-to-Win Method）以争取项目合约为原则，因此以足够取得项目合约

35、的价格为基础所做的规模估算。实际上价格胜算法师一种制定价格的策略而非规模度量方法。2.1.52.1.5 功能点分析方法功能点分析方法功能点分析方法（Function Point Analysis）是在需求分析阶段基于系统功能的一种规模度量方法，是对软件规模大小的间接度量。一般是通过计算必须和用户交互的情况的数目来测算程序工作量的大小。功能点分析法是目前国际上软件行业普遍接受的软件项目规模度量模型10。功能点分析是把应用系统按组件进行分解，并对每类组件以 IFPUG 定义的功能点为度量单位进行计算，从而得到反映整个应用系统规模的功能点数。功能点分析从用户对应用系统功能性需求出发，对应用系统两类功

36、能性需求进行分析：一类是数据功能性需求，另一类为事务功能性需求。数据功能性需求又分为：部逻辑文件(ILF：Internal Logical Files)和外部接口文件(EIF：ExternalInterface Files)两类；事务功能性需求则分为：外部输入(EI：External Inputs)，外部输出(EO：External Outputs)，外部查询(EQ：External Inquiry)三类。所以，应用系统一共可以按五类组件进行分解。所谓部逻辑文件(ILF)是指用户可确认的、在应用程序部进行维护的、逻辑上相关的数据块或控制信息(通常是实体类.7/47型中的第二式或第三式表示的数据

37、模式)；外部接口文件(EIF)是指：用户可确认的、由被度量的应用程序引用，但由其他应用程序部进行维护的、逻辑上相关的数据块或控制信息(通常是实体类型中的第二式或第三式表示的数据模式)5。通常的 MIS 系统的开发者和用户，对这类组件并不陌生。外部输入(EI)是指应用程序对来自应用程序边界以外的数据或控制信息的基本处理；外部输出(EO)是指应用程序向其边界之外提供数据或控制信息的基本处理，这种处理逻辑中可能包含数学计算或导出数据等，并且要对部逻辑文件进行维护。外部查询(EQ)是指应用程序向其边界之外提供数据或控制信息查询的基本处理，与 EO 不同的是，处理逻辑中既不包含数学计算公式也不产生导出数

38、据，处理过程中也不维护 ILF29。在 IEPUG 的功能点计算实践手册中，按照组件的复杂程度分别对某个组件按若干个功能点进行计算。复杂度分成三等，即低、中、高。对数据功能性的组件来说，复杂度决定于两个因素：一是看 ILF 或 EIF 所包含的数据元素个数(DET：Data Element Types)，另一个则是看 ILF 和 EIF 中用户可以识别的记录元素类型的个数(RET：Record Element Types)。而对事务功能性组件，复杂度则取决于事务所引用的所有部文件或外部文件的个数(FTR：File Type Referenced)，以与事务处理过程中输入或输出文件中涉与的动态数

39、据元素个数（DET）5。按照 IFPUG 功能点计算实践手册 4.1 版本中的规定：ILF 和 EIF 的低、中、高三个级别的确定方法如表 3.l 所示。表 3.1 ILF 和 EIF 数据组件的复杂度级别EI 事务组件的低、中、高三个级别的确定方法如表 3.2 所示5。表 3.2EI 事务组件的复杂度级别引用的文件类型个数（FTR）数据元素类型（DET）145151601低低中2低中高3中高高EO 和 EQ 事务组件的低、中、高三个级别的确定方法如表 3.3 所示5。表 3.3EO 和 EQ 事务组件的复杂度级别记录元素类型（RET）数据元素类型（DET）1192050511低低中25低中高

40、5中高高.8/47引用的文件类型个数（FTR）数据元素类型（DET）156192001低低中23低中高3中高高每个组件按不同的复杂度等级与功能点数的对应关系如表 3.4 所示5。表 3.4五类组件按复杂度等级与功能点值的对应关系组件组件复杂度级别低中高ILF_7_10_15EIF_5_7_10EI_3_4_6EO_4_5_7EQ_3_4_6这样，如果将一个应用系统按组件分解后，确定每个组件的复杂度等级，然后，按照 IFPUG 功能点计算实践手册给出的计算方法，就可以用 IFPUG 定义的功能点作为度量单位计算出该系统的规模。但是，对同一个组件(例如对一个输入组件)若考虑到该组件要有较好的可操作

41、性，或具有更高的执行效率等要求，则它应当具有更大的规模。因此，单纯地考虑组件个数以与组件本身的复杂度来计算功能点，仍然不能较客观地反映出系统的规模。为此，IFPUG 还考虑了 l4 个称为系统基本特征的属性(GSC：General System Characteristics)510：1数据通讯（Data Communications）2分布式数据处理（Distributed Data Processing）3性能（Performance）4使用强度高的配置（Heavily Used Configuration）5处理速率（Transaction Rate）6在线数据输入（Online Dat

42、a Entry）7最终用户的效率（End-User Efficiency）8在线更新（Online Update）9复杂的处理（Complex Processing）10可重用性（Reusability）11安装的简易性（Installation Ease）12运行的简易性（Operational Ease）13多场地（Multiple Sites）.9/4714允许变更（Facilitate Change）将有关属性对系统的影响程度分别赋予 0-5 中的某个权值，然后按以下公式对应用系统的功能点进行调整，最终得到被度量系统的功能点数：AFP=UFPVAF其中，UFP 为未调整之前的功能点数，

43、VAF 为功能点值调整因子，VAF=(DIl+DI2+DIl4)0.01+0.65，而 DIi（i=l，214）为上述的 l4 个系统基本特征属性所取的权值(05)。2.22.2 软件需求与规模度量软件需求与规模度量我们在进行软件开发，以与开展软件估算活动的过程中，都是以需求为基础的，没有需求就没有软件，也就没有软件估算。而有了需求，我们就可以度量软件的规模大小，然后才能进行其它的估算活动。因此，我们要弄清楚两个问题：一是如何获取高质量的需求？二是如何度量需求？下面我们就这两个问题进行说明。2.2.12.2.1 软件需求软件需求软件需指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望

44、。通过对应问题与其环境的理解与分析，为问题涉与的功能与系统行为建立模型，并将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。需求分析是介于系统分析和软件设计之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科

45、9。它通过合适的工具和记号系统地描述待开发系统与其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。一般来说，我们把需求工程的活动划分为以下 5 个独.10/47立的阶段9：（1）需求获取：通过与用户的交流，对现有系统的观察与对任务进行分析，从而开发、捕获和修订用户的需求

46、；（2）需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；（3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。2.2.22.2.2 规模度量对软件需求的积极作用规模度量对软件需求的积极作用在软件项目开发生命周期的早期阶段，普遍采用功能点方法进行软件规模度量。功能点方法是根据软件项目的功能性需求来度量软件的规模大小，因此，需求的质量，包括完整

47、性、正确性、可行性、必要性、无二义性和可验证性，直接影响软件规模度量的准确性，因此，运用优秀的需求工程方法来获得高质量的需求，并形成需求规格说明书，对于准确的软件规模度量来说，具有重要的基础决定意义。一切估算皆来自软件需求，虽然说高质量的需求不是准确度量规模的充分条件，但是，需求质量低，规模度量肯定不准确，进而影响工作量、成本和进度估算的准确性，也就影响了对整个项目开发的可控性。我们推荐使用下面这些优秀的方法来进行需求开发。需求获取需求分析编写规格说明需求验证编写项目视图与围确定需求开发过程用户群分类分析用户工作流程 联 合 应 用 开 发（JAD）需求重用绘制关联图创建开发原型分析可行性 确

48、定需求优先级 为需求建立模型编写数据字典采用软件需求规格说明模板指明需求来源为每项需求注上标号记录业务规创建需求跟踪能力矩阵审查需求文档依据需求编写测试用例编写用户手册确定合格的标准软件业最大的难题之一就是在初始的需求阶段结束后如何处理新的需求和变.11/47化的需求。在运用功能点方法进行软件规模度量的过程中，可以对软件的需求产生一定的积极作用；在这里，我们主要讨论两点：2.2.2.12.2.2.1 发现需求的不完整和模糊性发现需求的不完整和模糊性不管是 IFPUG 功能点，Mark功能点，还是 COSMIC 功能点，都需要考虑到数据属性，与其描述的“实体”，没有它们，就无法采用这些功能点方法

49、度量软件规模。通过度量，我们可以逆向发现需求中的不完整性和模糊性，进而采用相应的需求工程方法补充和澄清需求，为项目的后续进展提供良好的基础。（再充实修改）2.2.2.22.2.2.2 计算需求的蔓延率计算需求的蔓延率功能点度量在测量需求蔓延率时非常有用。由于功能点数来自于对软件功能性需求大小的度量，因此，功能点数的变化大致与功能性需求成正比例变化，我们可以根据功能点数来计算软件功能性需求的蔓延率。基本过程如下：（1）在需求分析阶段，计算初始功能点数；（2）项目结束后，再计算最终的功能点数；（3）运用公式可以计算出需求的平均月度增长速率。公式 其中，RSS 代表需求蔓延率，FPf代表最终功能点数

50、，FPi代表初始功能点数，T 代表从需求结束到设计编码结束的时间周期。通过对同类型软件项目进行历史数据统计分析，可以得到该类型项目的一个平均需求蔓延率，进而可以更加准确地预测系统最终的规模大小。2.32.3 准确估算的重要性准确估算的重要性一旦可以做出足够准确的估算，无论估算偏高还是偏低都不用担心会出现大的估算误差。准确的估算可以带来以下几个方面的好处：（1）更准确地显示项目状态。跟踪进度的最佳方法之一就是将计划进度与实际进度相比较。如果计划进度是实际可行的（也就是根据准确估算作出的），就能够根据计划来跟踪进度。如果计划进度只是一些幻想，项目运行常就不太会注意计划，对实际进度和计划进度的比较很