方法及其准确的研究与应用硕士学位.doc

《方法及其准确的研究与应用硕士学位.doc》由会员分享，可在线阅读，更多相关《方法及其准确的研究与应用硕士学位.doc（56页珍藏版）》请在三一文库上搜索。

1、工程硕士学位论文COSMIC方法及其准确性的研究与应用软件规模度量及其准确性的研究与应用 国防科学技术大学研究生院COSMIC Method and Its Accurateness Research and Application Candidate：Jiang HuiAdvisor：Yin JunWenA thesisSubmitted in partial fulfillment of the requirementsfor the professional degree of Master of Engineeringin Computer EngineeringGraduate Sc

2、hool of National University of Defense TechnologyChangsha，Hunan，P.R.China（October，2008）毕业设计（论文）原创性声明和使用授权说明原创性声明本人郑重承诺：所呈交的毕业设计（论文），是我个人在指导教师的指导下进行的研究工作及取得的成果。尽我所知，除文中特别加以标注和致谢的地方外，不包含其他人或组织已经发表或公布过的研究成果，也不包含我为获得 及其它教育机构的学位或学历而使用过的材料。对本研究提供过帮助和做出过贡献的个人或集体，均已在文中作了明确的说明并表示了谢意。作 者 签 名： 日 期： 指导教师签名： 日期：

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

4、本声明的法律后果由本人承担。作者签名： 日期： 年 月 日学位论文版权使用授权书本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权 大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。涉密论文按学校规定处理。作者签名：日期： 年 月 日导师签名： 日期： 年 月 日指导教师评阅书指导教师评价：一、撰写（设计）过程1、学生在论文（设计）过程中的治学态度、工作精神 优 良 中 及格 不及格2、学生掌握专业知识、技能的扎实程度 优 良 中 及

5、格 不及格3、学生综合运用所学知识和专业技能分析和解决问题的能力 优 良 中 及格 不及格4、研究方法的科学性；技术线路的可行性；设计方案的合理性 优 良 中 及格 不及格5、完成毕业论文（设计）期间的出勤情况 优 良 中 及格 不及格二、论文（设计）质量1、论文（设计）的整体结构是否符合撰写规范？ 优 良 中 及格 不及格2、是否完成指定的论文（设计）任务（包括装订及附件）？ 优 良 中 及格 不及格三、论文（设计）水平1、论文（设计）的理论意义或对解决实际问题的指导意义 优 良 中 及格 不及格2、论文的观念是否有新意？设计是否有创意？ 优 良 中 及格 不及格3、论文（设计说明书）所体现

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

7、格 不及格（在所选等级前的内画“”）评阅教师： （签名） 单位： （盖章）年 月 日教研室（或答辩小组）及教学系意见教研室（或答辩小组）评价：一、答辩过程1、毕业论文（设计）的基本要点和见解的叙述情况 优 良 中 及格 不及格2、对答辩问题的反应、理解、表达情况 优 良 中 及格 不及格3、学生答辩过程中的精神状态 优 良 中 及格 不及格二、论文（设计）质量1、论文（设计）的整体结构是否符合撰写规范？ 优 良 中 及格 不及格2、是否完成指定的论文（设计）任务（包括装订及附件）？ 优 良 中 及格 不及格三、论文（设计）水平1、论文（设计）的理论意义或对解决实际问题的指导意义 优 良 中 及

8、格 不及格2、论文的观念是否有新意？设计是否有创意？ 优 良 中 及格 不及格3、论文（设计说明书）所体现的整体水平 优 良 中 及格 不及格评定成绩： 优 良 中 及格 不及格（在所选等级前的内画“”）教研室主任（或答辩小组组长）： （签名）年 月 日教学系意见：系主任： （签名）年 月 日插入独创性声明页本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含其他已经发表或撰写过的研究成果；也不包含为获得国防科技大学或其它教育机构的学位或证书而使用过的材料。与我一同学习的同学对本研究所做的任何贡献均已在论文

9、中做了明确的说明并表示谢意。学位论文题目： 学位论文作者签名： 日期 年 月 日学位论文版权使用授权书本人完全了解国防科学技术大学有关保留、使用学位论文的规定。本人授权国防科学技术大学可以保留并向国家有关部门或机构送交论文的复印件和电子文档，允许论文查阅和借阅；可以将学位论文的全部或部分内容编入有关数据库进行检索，可以采用复印、缩印或扫描等复制手段保存、汇编学位论文。（保密学位论文在解密后适用本授权书）学位论文题目： 学位论文作者签名： 日期 年 月 日作者指导老师签名： 日期 年 月 日国防科学技术大学研究生院工程硕士学位论文目 录摘 要iABSTRACTii第一章 绪 论11.1 论文研究

10、背景11.2 国内外软件估算研究现状21.2.1 国内研究现状21.2.2 国外研究现状21.3 准确估算的重要性31.4 论文的主要工作31.5 论文的组织结构4第二章 软件规模度量基础理论52.1 软件规模度量52.1.1代码行方法52.1.2 DELPHI法62.1.3 类比方法62.1.4 价格胜算法72.1.5 功能点分析方法72.2 软件需求与规模度量102.2.1 软件需求102.2.2 规模度量对软件需求的作用112.3软件规模度量在软件项目估算中的重要性12第三章 COSMIC方法143.1 COSMIC方法的由来143.2 COSMIC方法的基本思想143.3 COSMIC

11、方法的两个模型153.3.1软件上下文模型153.3.2 COSMIC通用软件模型163.4 COSMIC方法的基本概念163.4.1 软件层次的定义163.4.2 边界的定义173.4.3 功能用户的定义173.4.4 功能过程的定义173.4.5 触发事件173.4.6 数据组的定义183.4.7 感兴趣对象的定义183.4.8 数据属性的定义183.4.9 数据移动的定义183.5 COSMIC方法的基本过程193.5.1 COSMIC方法的三个阶段203.5.2 识别软件层次213.5.3 划分粒度级别223.5.4 识别边界233.5.5 识别功能过程（Function Proces

12、s）233.5.6 识别数据组243.5.7 识别数据属性243.5.8 识别数据移动243.5.9 执行度量与汇总结果253.6 COSMIC方法的优势和问题25第四章 COSMIC方法的准确性研究274.1 三种主流功能点方法的比较274.1.1 联系274.1.2 区别284.2 COSMIC方法的优势与不足284.2.1需求风险294.2.2 COSMIC方法使用不正确304.2.3度量人员对业务不熟悉304.2.4应用的复杂性304.2.5缺乏历史项目数据和经验知识304.2.6度量规模时遗漏某些功能304.2.7来自客户和高层领导的压力304.2.8功能点与代码行的不当转换304.

13、2.9没有重估304.3 软件规模度量风险管理模型30第五章 第五章题目30结 束 语31致 谢32参考文献33作者在学期间取得的学术成果34附录A 附录A题目35附录B 附录B题目36表 目 录表1.1 表1.1名称2表1.2 表1.2名称3表2.1 表2.1名称4表2.2 表2.2名称5表3.1 表3.1名称7表3.2 表3.2名称8表3.3 表3.3名称8表4.1 表4.1名称10表4.2 表4.2名称10图 目 录图1.1 图1.1名称1图1.2 图1.2名称2图1.3 图1.3名称3图2.1 图2.1名称4图2.2 图2.2名称5图4.1 图4.1名称9图5.1 图5.1名称11图5

14、.2 图5.2名称12第 V 页摘 要（学位论文摘要）主题词：（主题词1） （主题词2） ABSTRACT（Abstract）Key Words：（Key Words 1） （Key Words 2） 第 ii 页第一章 绪 论1.1 论文研究背景软件规模度量是制定软件项目开发计划的基础和依据，度量是对软件项目进行量化分析和项目可行性分析的前提条件，是项目成本估算、进度安排、质量评估和资源规划的基础。在软件业，需求风险与估算风险被认为是软件项目开发过程中最主要的两个风险1。软件规模度量不准确、不合理，会导致不合理的进度安排、资源和质量目标，最终导致软件项目预算超支、进度延期以及质量失控等后果，

15、使项目面临无法挽救的灾难局面，犹如死亡行军。全世界每年大约有50万个项目执行着100万个左右的软件项目，产生了6000亿美元的软件产品。在这些项目中，有很多不能满足客户所期望的质量，或者不能在预算内按时交付软件，有分析认为：1/3左右的项目在成本和进度上超出了额定限度的125%以上。（R.L.Glass. Software Runaway: Lessons learned from Massive Software Project Failures. Prentice Hall PTR,1998 ）在软件开发实践中，由于软件成本估算不足或者不准确，直接导致许多软件项目开发失败，根据Standi

16、sh Group组织2003年公布的数据显示，有15%的软件项目在没有任何产出的情况下被终止，有66%的软件项目被认为是失败的，而且，该组织2004年第三季度的报告还指出，成功开发的软件项目只占29%，失败项目占到了18%，有89%的项目都有预算超支的情况发生。另外，据ISBSG数据组织统计，美国2002年软件项目损失高达380亿美元，这还不包括预算超支的170亿美元31。虽然这些数据有可能是被夸大了，但是有一点是可以肯定的：由于早期对软件成本的估算不足，或者是由于需求不稳定，有大量的软件项目开发失败。来自http:/官方网站。软件规模度量历来是比较复杂的，其范围大至软件项目管理活动，小则可为

17、一个程序的设计，是一件困难度颇高的任务。因为软件本身的复杂性、历史经验知识和项目数据的缺乏、度量工具缺乏以及一些人为错误，导致软件项目的规模度量往往和实际情况相差甚远。而软件估算错误已经被公认为软件项目失败的四大原因之一。因此，在软件工程领域，不论工业界还是学术界，软件规模度量已经是一个重要的研究方法。软件成本估算是项极其复杂的工作。因为影响软件成本的因素很多，而这些因素又很难把握，但作为开发者却必须在软件开发之初就要向客户做出一定的承诺，所以，开发者能否控制项目，保证项目能够按预期的方向、计划和要求进行至关重要1。而控制项目，制定合同的关键是顾客、开发者对软件“大小”的了解，也就是软件经过估

18、算得到的软件的规模、工作量、成本和进度。在这之中，软件的成本、工作量及进度估算都是以软件的规模为输入的，规模估算的好坏直接影响着项目的后续工作，因此规模估算非常重要4。1.2 国内外软件估算研究现状1.2.1 国内研究现状国内软件项目开发的管理目前正逐步向规范化发展，但是在开发周期的估算上绝大部分还是处于手工作坊的状态。主要表现在以下两个方面：一方面，项目管理人员意识上没有是认识估算的重要性，认为估算就是一个大概的估计，通常凭借主观经验“拍脑袋”得出的，很多还受限于商业行为，比如说为了签订合同而不惜压缩开发工作量；这样使得软件开发组织在项目开发后期可能会陷入成本、进度和质量的困境，甚至被客户拒

19、绝接受产品。另一方面，由于没有专门的工具来辅助估算，或者说没有专门对估算进行研究。一个软件项目的规模究竟多大、开发费用究竟多少以及开发周期究竟多久，这些问题基本上是依靠估算人员的经验来判断，而这种经验带有很大的主观性和片面性。不同经验的人估算出的结果相差很大，而更糟糕的是这种判断由于完全凭借经验使得不同意见的人之间很难沟通，因为谁都没有确切的量化标准来支持自己的判断，最终的结果往往是以“专家”的估算为准。实际上，国内的软件项目开发需要的正是这种定量估算，这样做不仅规范而且精确，十分有助于软件行业的健康发展以及与国际接轨。国内在软件估算领域，主要还停留在学术上的研究，还没有真正运用到软件开发公司

20、的实际活动中。还没有形成基于国内开发环境的估算方法和技术。研究主要是在国外的估算方法基础上进行本地化研究和扩展研究。1.2.2 国外研究现状国外发达国家在软件估算上比国内要成熟得多，从20世纪50年代软件业诞生到20世纪70年代，软件项目估算都是手工进行的，使用简单的经验法则或经过反复摸索自己开发出的估算算法。从20世纪70年代早期到1987年，现代软件项目估算业的核心开始形成。至今，国外发达国家在软件估算领域比国内要成熟的多，不仅有很多方法比如代码行估算法、功能点估算法、人力估算法，而且还形成了专业化的估算工具来辅助这项工作。比如微软公司开发的项目管理工具软件Project、加拿大Softw

21、are Productivity Center Inc.公司开发的Estimate，都是比较成熟的估算辅助工具。采用辅助工具对软件开发周期进行估算具有明显优势。因为辅助工具是在大量不同类型项目数据研究的基础上总结开发出来的，采用的估算方法已经成熟，估算结果的准确性有保障。由于这种估算过程是可以量化的，而非依据个人经验直接得出结果，所以在结果的评断上有据可依，有理可推。而且长期依靠工具辅助估算可以将大量项目的数据和估算结果积累形成历史经验库，从而对新项目的估算进行对比调整，从而提高估算的准确性。1.3 论文的主要工作软件项目开发必须经过估算来得到软件的工作量、成本和进度的大概情况，并且用这些估算

22、结果来制定合同、项目计划、对客户作出承诺，控制项目，保证项目能够按预期的方向进行。但是软件的成本、工作量及进度估算都是以即将构建的软件的规模为输入的，规模度量的准确与否直接影响着项目的后续工作，因此，规模度量是非常重要的。本论文的主要工作及研究成果在于：1.4 论文的组织结构论文的组织结构共分为六章。第一章：绪论。阐述了论文研究的背景、国内外研究现状以及论文的主要工作。第二章：软件规模度量基础理论。主要阐述了目前几种常见的规模度量方法，分析了软件需求与规模度量之间的紧密关系以及软件规模度量在软件项目估算中的重要地位。第三章：主要阐述COSMIC方法的基本原理和使用过程。第四章：通过长期对COS

23、MIC方法的研究和实践，针对COSMIC方法在软件规模度量过程中存在的一些主要问题进行了分析和探讨，提出了软件规模度量风险管理模型。第五章：案例分析第六章：工作总结和未来展望。第二章 软件规模度量基础理论2.1 软件规模度量任何种类的软件在开发前期，都需要对软件的规模大小进行度量。软件的规模大小直接影响了软件开发项目的设置和管理，正确度量即将开发的目标软件规模，为其制定合体的开发计划，提高软件项目成功开发的概率。我们这里所研究的软件规模度量是指软件的功能性规模进行度量，是对必须提交给用户的软件功能进行量化的过程。软件开发项目规模度量(size measurement)是估算软件项目工作量、编制

24、成本预算、策划合理项目进度的基础。规模度量是软件项目失败的重要原因之一。一个好的规模度量模型可以解决这一问题。有效的软件规模度量是成功项目的核心要素：基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。规模度量的要点在于：由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。 软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。软件规模的度量方法主要有以下几种：2.1.1代码行方法代码行（LOC）度量是对软件规模大小的直接度量，是软件开发者在软件规模度量中最早使用也是最直观的方法12，已形成很完整的模式

25、13。在用代码行度量规模时，常会被描述为源代码行(source lines of code，简称SLOC)或者交付源指令(delivered source instruction，简称DSI)，目前成本估算模型通常采用非注释的源代码行。虽然代码行仍是目前普遍采用的一种方式，但它也存在局限性： （1）对代码行没有公认的可接受的标准定义。例如，最常见的计算代码时的分歧有空代码行、注释代码行、数据声明、复用的代码，以及包含多条指令的代码行等。在Jones的研究中发现，对同一个产品进行代码行计算，不同的计算方式可以带来5倍之大的差异14。 （2）代码行数量依赖于所用的编程语言和个人的编程风格15。因此

26、，计算的差异也会影响用多种语言编写的程序规模，进而也很难对不同语言开发的项目的生产率进行直接比较。 （3）在项目早期，需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量，不适合用于项目早期度量。（4）代码行强调编码的工作量，只是项目实现阶段的一部分16。2.1.2 DELPHI法DELPHI方法是一种专家评估技术，在没有历史数据的情况下，这种方法是用于评定过去与将来，新技术与特定程序之间的差别，但专家“专”的程度及对项目的理解程度是工作中的难点，但是这种方法对决决定其他模型的输入时特别有用。DELPHI法是60年代初美国兰德公司的专家们为避免集体讨论存在的屈从于权威或盲目服从多数的

27、缺陷提出的一种定性预测的情报分析方法，在我国更习惯于将德尔菲法称为专家预测法。为了消除成员间相互影响，参加的专家可以互不了解，它运用匿名方式反复多次征询意见和进行背靠背的交流，以充分发挥专家们的智慧、知识和经验，最后汇总得出一个能比较反映群体意志的预测结果。该方法及其派生技术已被广泛应用于各个领域49。这种方法的优势在于不需要历史数据，适合新项目；局限性是主观，专家技术带来误判。基本步骤为：1）主持人事先发给每位专家一份有关委托评估软件的说明书和一张测算表。 测算表中应包括：系统软件名称、填表日期、程序源代码估计值：乐观值（最少行数)、最可能值、最不利值(最多行数)以及简要理由；2）召开小组会

28、议。会上，专家们可就不明白的问题向主持人询问，专家之间也可讨论。如有可能，主持人应向专家介绍与委托评估软件相类似系统软件的有关情况，供专家参考；3）专家们无记名填测算表；4）主持人对测算表进行汇总，计算出第i位专家的测算期望值及全部专家的测算期望值和均方差；5）召开小组会议，公布测算期望值和均方差，让专家们充分发表意见并加以讨论；6）按讨论后认识的一致性程度和均方差大小决定要否重复上述3-5步工作程序；7）按最后一轮无记名填表所得的侧算期望值作为委托评估软件的软件规模 。本方法的优点在于，先匿名填表，每个专家均需经过独立思考，作出测算，因而在讨论时有利于提出自己的见解，并通过多次反复，使意见逐

29、渐趋于一致。2.1.3 类比方法类比法（Analogy）适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度。因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的50。其基本步骤是：1）整理出项目功能列表和实现每个功能的代码行；2）标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；3）通过步骤1和2得出各个功能的估计值；4）产生规模估计。软件项目中用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办

30、法就是由程序员或系统分析员详细地考查己存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行1：等价代码行=(重新设计%+重新编码%+重新测试%)/3 *已有代码行比如：有2000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为：( 30% + 50% + 70%)/3* 2000 = 1000等价代码行。也就是说，重用这2000代码相当于编写1000代码行的工作量。2.1.4 价格胜算法价格胜算法（Price-to-Win M

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

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

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

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

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

36、据元素类型（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定义的功能点作为度量单位计算出该系统的规模。但是，对同一个组件(例如对一个输入组件)若考虑到该组件要有较好的可操作性，或具有更高的执行效率等要求，则它应当具有更大的规模。因此

37、，单纯地考虑组件个数以及组件本身的复杂度来计算功能点，仍然不能较客观地反映出系统的规模。为此，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 Data Entry）7最终用户的效率 （End-User

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

39、DIl4)0.01 + 0.65，而DIi（i=l，214）为上述的l4个系统基本特征属性所取的权值(05)。2.2 软件需求与规模度量我们在进行软件开发，以及开展软件估算活动的过程中，都是以需求为基础的，没有需求就没有软件，也就没有软件估算。而有了需求，我们就可以度量软件的规模大小，然后才能进行其它的估算活动。因此，我们要弄清楚两个问题：一是如何获取高质量的需求？二是如何度量需求？下面我们就这两个问题进行说明。2.2.1 软件需求软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析，为问题涉及的功能及系统行为建立模型，并将用户需求精确化、完

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

41、断变化的需求演进给予支持。软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。一般来说，我们把需求工程的活动划分为以下5个独立的阶段9：（1）需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；（2）需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；（3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。2.2.2 规模度量对软件需求的积极作用在软件项目开发生命周期的早期阶段，普遍采用功能点方法进行软件规模度量。功能点方法是根据软件项目的功能性需求来度量软件的规模大小，因此，需求的质量，包括完整性、正确性、可行性、必要性、无二义性和可验证性，直接影响软件规模度量的准确性，因此，运用优秀的需求工程方法来获得高质量的需求，