cosmic方法及其准确性的研究与应用.docx
《cosmic方法及其准确性的研究与应用.docx》由会员分享，可在线阅读，更多相关《cosmic方法及其准确性的研究与应用.docx（43页珍藏版）》请在冰点文库上搜索。
cosmic方法及其准确性的研究与应用
分类号TP000.0学号GS06062175
UDC密级公开
工程硕士学位论文
COSMIC方法及其准确性的研究与应用
硕士生姓名
蒋辉
学科领域
软件工程
研究方向
软件规模度量
指导教师
尹俊文副教授
何鸿军副教授
国防科学技术大学研究生院
二〇〇八年十月
COSMICMethodandItsAccuratenessResearchandApplication
Candidate：
JiangHui
Advisor：
YinJunWen
Athesis
Submittedinpartialfulfillmentoftherequirements
fortheprofessionaldegreeofMasterofEngineering
inComputerEngineering
GraduateSchoolofNationalUniversityofDefenseTechnology
Changsha，Hunan，P.R.China
（October，2008）
插入独创性声明页
本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。
尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含其他已经发表或撰写过的研究成果；也不包含为获得国防科技大学或其它教育机构的学位或证书而使用过的材料。
与我一同学习的同学对本研究所做的任何贡献均已在论文中做了明确的说明并表示谢意。
学位论文题目：
学位论文作者签名：
日期年月日
学位论文版权使用授权书
本人完全了解国防科学技术大学有关保留、使用学位论文的规定。
本人授权国防科学技术大学可以保留并向国家有关部门或机构送交论文的复印件和电子文档，允许论文查阅和借阅；可以将学位论文的全部或部分内容编入有关数据库进行检索，可以采用复印、缩印或扫描等复制手段保存、汇编学位论文。
（保密学位论文在解密后适用本授权书）
学位论文题目：
学位论文作者签名：
日期年月日
作者指导老师签名：
日期年月日
目录
摘要i
ABSTRACTii
第一章绪论1
1.1论文研究背景1
1.2国内外软件估算研究现状2
1.2.1国内研究现状2
1.2.2国外研究现状2
1.3准确估算的重要性3
1.4论文的主要工作3
1.5论文的组织结构4
第二章软件规模度量基础理论5
2.1软件规模度量5
2.1.1代码行方法5
2.1.2DELPHI法6
2.1.3类比方法6
2.1.4价格胜算法7
2.1.5功能点分析方法7
2.2软件需求与规模度量10
2.2.1软件需求10
2.2.2规模度量对软件需求的作用11
2.3软件规模度量在软件项目估算中的重要性12
第三章COSMIC方法14
3.1COSMIC方法的由来14
3.2COSMIC方法的基本思想14
3.3COSMIC方法的两个模型15
3.3.1软件上下文模型15
3.3.2COSMIC通用软件模型16
3.4COSMIC方法的基本概念16
3.4.1软件层次的定义16
3.4.2边界的定义17
3.4.3功能用户的定义17
3.4.4功能过程的定义17
3.4.5触发事件17
3.4.6数据组的定义18
3.4.7感兴趣对象的定义18
3.4.8数据属性的定义18
3.4.9数据移动的定义18
3.5COSMIC方法的基本过程19
3.5.1COSMIC方法的三个阶段20
3.5.2识别软件层次21
3.5.3划分粒度级别22
3.5.4识别边界23
3.5.5识别功能过程（FunctionProcess）23
3.5.6识别数据组24
3.5.7识别数据属性24
3.5.8识别数据移动24
3.5.9执行度量与汇总结果25
3.6COSMIC方法的优势和问题25
第四章COSMIC方法的准确性研究27
4.1三种主流功能点方法的比较27
4.1.1联系27
4.1.2区别28
4.2COSMIC方法的优势与不足28
4.2.1需求风险29
4.2.2COSMIC方法使用不正确30
4.2.3度量人员对业务不熟悉30
4.2.4应用的复杂性30
4.2.5缺乏历史项目数据和经验知识30
4.2.6度量规模时遗漏某些功能30
4.2.7来自客户和高层领导的压力30
4.2.8功能点与代码行的不当转换30
4.2.9没有重估30
4.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.2图5.2名称12
摘要
（学位论文摘要）
主题词：
（主题词1）（主题词2）……
ABSTRACT
（Abstract）
KeyWords：
（KeyWords1）（KeyWords2）……
第一章绪论
1.1论文研究背景
软件规模度量是制定软件项目开发计划的基础和依据，度量是对软件项目进行量化分析和项目可行性分析的前提条件，是项目成本估算、进度安排、质量评估和资源规划的基础。
在软件业，需求风险与估算风险被认为是软件项目开发过程中最主要的两个风险[1]。
软件规模度量不准确、不合理，会导致不合理的进度安排、资源和质量目标，最终导致软件项目预算超支、进度延期以及质量失控等后果，使项目面临无法挽救的灾难局面，犹如死亡行军。
全世界每年大约有50万个项目执行着100万个左右的软件项目，产生了6000亿美元的软件产品。
在这些项目中，有很多不能满足客户所期望的质量，或者不能在预算内按时交付软件，有分析认为：
1/3左右的项目在成本和进度上超出了额定限度的125%以上。
（R.L.Glass.SoftwareRunaway:
LessonslearnedfromMassiveSoftwareProjectFailures.PrenticeHallPTR,1998）在软件开发实践中，由于软件成本估算不足或者不准确，直接导致许多软件项目开发失败，根据StandishGroup组织2003年公布的数据显示，有15%的软件项目在没有任何产出的情况下被终止，有66%的软件项目被认为是失败的，而且，该组织2004年第三季度的报告还指出，成功开发的软件项目只占29%，失败项目占到了18%，有89%的项目都有预算超支的情况发生。
另外，据ISBSG数据组织统计，美国2002年软件项目损失高达380亿美元，这还不包括预算超支的170亿美元[31]。
虽然这些数据有可能是被夸大了，但是有一点是可以肯定的：
由于早期对软件成本的估算不足，或者是由于需求不稳定，有大量的软件项目开发失败。
来自官方网站。
软件规模度量历来是比较复杂的，其范围大至软件项目管理活动，小则可为一个程序的设计，是一件困难度颇高的任务。
因为软件本身的复杂性、历史经验知识和项目数据的缺乏、度量工具缺乏以及一些人为错误，导致软件项目的规模度量往往和实际情况相差甚远。
而软件估算错误已经被公认为软件项目失败的四大原因之一。
因此，在软件工程领域，不论工业界还是学术界，软件规模度量已经是一个重要的研究方法。
软件成本估算是项极其复杂的工作。
因为影响软件成本的因素很多，而这些因素又很难把握，但作为开发者却必须在软件开发之初就要向客户做出一定的承诺，所以，开发者能否控制项目，保证项目能够按预期的方向、计划和要求进行至关重要[1]。
而控制项目，制定合同的关键是顾客、开发者对软件“大小”的了解，也就是软件经过估算得到的软件的规模、工作量、成本和进度。
在这之中，软件的成本、工作量及进度估算都是以软件的规模为输入的，规模估算的好坏直接影响着项目的后续工作，因此规模估算非常重要[4]。
1.2国内外软件估算研究现状
1.2.1国内研究现状
国内软件项目开发的管理目前正逐步向规范化发展，但是在开发周期的估算上绝大部分还是处于手工作坊的状态。
主要表现在以下两个方面：
一方面，项目管理人员意识上没有是认识估算的重要性，认为估算就是一个大概的估计，通常凭借主观经验“拍脑袋”得出的，很多还受限于商业行为，比如说为了签订合同而不惜压缩开发工作量；这样使得软件开发组织在项目开发后期可能会陷入成本、进度和质量的困境，甚至被客户拒绝接受产品。
另一方面，由于没有专门的工具来辅助估算，或者说没有专门对估算进行研究。
一个软件项目的规模究竟多大、开发费用究竟多少以及开发周期究竟多久，这些问题基本上是依靠估算人员的经验来判断，而这种经验带有很大的主观性和片面性。
不同经验的人估算出的结果相差很大，而更糟糕的是这种判断由于完全凭借经验使得不同意见的人之间很难沟通，因为谁都没有确切的量化标准来支持自己的判断，最终的结果往往是以“专家”的估算为准。
实际上，国内的软件项目开发需要的正是这种定量估算，这样做不仅规范而且精确，十分有助于软件行业的健康发展以及与国际接轨。
国内在软件估算领域，主要还停留在学术上的研究，还没有真正运用到软件开发公司的实际活动中。
还没有形成基于国内开发环境的估算方法和技术。
研究主要是在国外的估算方法基础上进行本地化研究和扩展研究。
1.2.2国外研究现状
国外发达国家在软件估算上比国内要成熟得多，从20世纪50年代软件业诞生到20世纪70年代，软件项目估算都是手工进行的，使用简单的经验法则或经过反复摸索自己开发出的估算算法。
从20世纪70年代早期到1987年，现代软件项目估算业的核心开始形成。
至今，国外发达国家在软件估算领域比国内要成熟的多，不仅有很多方法比如代码行估算法、功能点估算法、人力估算法，而且还形成了专业化的估算工具来辅助这项工作。
比如微软公司开发的项目管理工具软件Project、加拿大SoftwareProductivityCenterInc.公司开发的Estimate，都是比较成熟的估算辅助工具。
采用辅助工具对软件开发周期进行估算具有明显优势。
因为辅助工具是在大量不同类型项目数据研究的基础上总结开发出来的，采用的估算方法已经成熟，估算结果的准确性有保障。
由于这种估算过程是可以量化的，而非依据个人经验直接得出结果，所以在结果的评断上有据可依，有理可推。
而且长期依靠工具辅助估算可以将大量项目的数据和估算结果积累形成历史经验库，从而对新项目的估算进行对比调整，从而提高估算的准确性。
1.3论文的主要工作
软件项目开发必须经过估算来得到软件的工作量、成本和进度的大概情况，并且用这些估算结果来制定合同、项目计划、对客户作出承诺，控制项目，保证项目能够按预期的方向进行。
但是软件的成本、工作量及进度估算都是以即将构建的软件的规模为输入的，规模度量的准确与否直接影响着项目的后续工作，因此，规模度量是非常重要的。
本论文的主要工作及研究成果在于：
1.4论文的组织结构
论文的组织结构共分为六章。
第一章：
绪论。
阐述了论文研究的背景、国内外研究现状以及论文的主要工作。
第二章：
软件规模度量基础理论。
主要阐述了目前几种常见的规模度量方法，分析了软件需求与规模度量之间的紧密关系以及软件规模度量在软件项目估算中的重要地位。
第三章：
主要阐述COSMIC方法的基本原理和使用过程。
第四章：
通过长期对COSMIC方法的研究和实践，针对COSMIC方法在软件规模度量过程中存在的一些主要问题进行了分析和探讨，提出了软件规模度量风险管理模型。
第五章：
案例分析
第六章：
工作总结和未来展望。
第二章软件规模度量基础理论
2.1软件规模度量
任何种类的软件在开发前期，都需要对软件的规模大小进行度量。
软件的规模大小直接影响了软件开发项目的设置和管理，正确度量即将开发的目标软件规模，为其制定合体的开发计划，提高软件项目成功开发的概率。
我们这里所研究的软件规模度量是指软件的功能性规模进行度量，是对必须提交给用户的软件功能进行量化的过程。
软件开发项目规模度量（sizemeasurement）是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。
规模度量是软件项目失败的重要原因之一。
一个好的规模度量模型可以解决这一问题。
有效的软件规模度量是成功项目的核心要素：
基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。
规模度量的要点在于：
由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。
软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。
软件规模的度量方法主要有以下几种：
2.1.1代码行方法
代码行（LOC）度量是对软件规模大小的直接度量，是软件开发者在软件规模度量中最早使用也是最直观的方法[12]，已形成很完整的模式[13]。
在用代码行度量规模时，常会被描述为源代码行（sourcelinesofcode，简称SLOC）或者交付源指令（deliveredsourceinstruction，简称DSI），目前成本估算模型通常采用非注释的源代码行。
虽然代码行仍是目前普遍采用的一种方式，但它也存在局限性：
（1）对代码行没有公认的可接受的标准定义。
例如，最常见的计算代码时的分歧有空代码行、注释代码行、数据声明、复用的代码，以及包含多条指令的代码行等。
在Jones的研究中发现，对同一个产品进行代码行计算，不同的计算方式可以带来5倍之大的差异[14]。
（2）代码行数量依赖于所用的编程语言和个人的编程风格[15]。
因此，计算的差异也会影响用多种语言编写的程序规模，进而也很难对不同语言开发的项目的生产率进行直接比较。
（3）在项目早期，需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量，不适合用于项目早期度量。
（4）代码行强调编码的工作量，只是项目实现阶段的一部分[16]。
2.1.2DELPHI法
DELPHI方法是一种专家评估技术，在没有历史数据的情况下，这种方法是用于评定过去与将来，新技术与特定程序之间的差别，但专家“专”的程度及对项目的理解程度是工作中的难点，但是这种方法对决决定其他模型的输入时特别有用。
DELPHI法是60年代初美国兰德公司的专家们为避免集体讨论存在的屈从于权威或盲目服从多数的缺陷提出的一种定性预测的情报分析方法，在我国更习惯于将德尔菲法称为专家预测法。
为了消除成员间相互影响，参加的专家可以互不了解，它运用匿名方式反复多次征询意见和进行背靠背的交流，以充分发挥专家们的智慧、知识和经验，最后汇总得出一个能比较反映群体意志的预测结果。
该方法及其派生技术已被广泛应用于各个领域[49]。
这种方法的优势在于不需要历史数据，适合新项目；局限性是主观，专家技术带来误判。
基本步骤为：
1）主持人事先发给每位专家一份有关委托评估软件的说明书和一张测算表。
测算表中应包括：
系统软件名称、填表日期、程序源代码估计值：
乐观值（最少行数）、最可能值、最不利值（最多行数）以及简要理由；
2）召开小组会议。
会上，专家们可就不明白的问题向主持人询问，专家之间也可讨论。
如有可能，主持人应向专家介绍与委托评估软件相类似系统软件的有关情况，供专家参考；
3）专家们无记名填测算表；
4）主持人对测算表进行汇总，计算出第i位专家的测算期望值及全部专家的测算期望值和均方差；
5）召开小组会议，公布测算期望值和均方差，让专家们充分发表意见并加以讨论；
6）按讨论后认识的一致性程度和均方差大小决定要否重复上述3-5步工作程序；
7）按最后一轮无记名填表所得的侧算期望值作为委托评估软件的软件规模。
本方法的优点在于，先匿名填表，每个专家均需经过独立思考，作出测算，因而在讨论时有利于提出自己的见解，并通过多次反复，使意见逐渐趋于一致。
2.1.3类比方法
类比法（Analogy）适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。
类比法估计结果的精确度取决于历史项目数据的完整性和准确度。
因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的[50]。
其基本步骤是：
1）整理出项目功能列表和实现每个功能的代码行；
2）标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；
3）通过步骤1和2得出各个功能的估计值；
4）产生规模估计。
软件项目中用类比法，往往还要解决可重用代码的估算问题。
估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查己存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。
根据这三个百分比，可用下面的计算公式计算等价新代码行[1]：
等价代码行=[（重新设计%+重新编码%+重新测试%）/3]*已有代码行
比如：
有2000行代码，假定30%需要重新设计，50%需要重新编码，70%需要重新测试，那么其等价的代码行可以计算为：
[（30%+50%+70%）/3]*2000=1000等价代码行。
也就是说，重用这2000代码相当于编写1000代码行的工作量。
2.1.4价格胜算法
价格胜算法（Price-to-WinMethod）以争取项目合约为原则，因此以足够取得项目合约的价格为基础所做的规模估算。
实际上价格胜算法师一种制定价格的策略而非规模度量方法。
2.1.5功能点分析方法
功能点分析方法（FunctionPointAnalysis）是在需求分析阶段基于系统功能的一种规模度量方法，是对软件规模大小的间接度量。
一般是通过计算必须和用户交互的情况的数目来测算程序工作量的大小。
功能点分析法是目前国际上软件行业普遍接受的软件项目规模度量模型[10]。
功能点分析是把应用系统按组件进行分解，并对每类组件以IFPUG定义的功能点为度量单位进行计算，从而得到反映整个应用系统规模的功能点数。
功能点分析从用户对应用系统功能性需求出发，对应用系统两类功能性需求进行分析：
一类是数据功能性需求，另一类为事务功能性需求。
数据功能性需求又分为：
内部逻辑文件（ILF：
InternalLogicalFiles）和外部接口文件（EIF：
ExternalInterfaceFiles）两类；事务功能性需求则分为：
外部输入（EI：
ExternalInputs），外部输出（EO：
ExternalOutputs），外部查询（EQ：
ExternalInquiry）三类。
所以，应用系统一共可以按五类组件进行分解。
所谓内部逻辑文件（ILF）是指用户可确认的、在应用程序内部进行维护的、逻辑上相关的数据块或控制信息（通常是实体类型中的第二范式或第三范式表示的数据模式）；外部接口文件（EIF）是指：
用户可确认的、由被度量的应用程序引用，但由其他应用程序内部进行维护的、逻辑上相关的数据块或控制信息（通常是实体类型中的第二范式或第三范式表示的数据模式）[5]。
通常的MIS系统的开发者和用户，对这类组件并不陌生。
外部输入（EI）是指应用程序对来自应用程序边界以外的数据或控制信息的基本处理；外部输出（EO）是指应用程序向其边界之外提供数据或控制信息的基本处理，这种处理逻辑中可能包含数学计算或导出数据等，并且要对内部逻辑文件进行维护。
外部查询（EQ）是指应用程序向其边界之外提供数据或控制信息查询的基本处理，与EO不同的是，处理逻辑中既不包含数学计算公式也不产生导出数据，处理过程中也不维护ILF[29]。
在IEPUG的功能点计算实践手册中，按照组件的复杂程度分别对某个组件按若干个功能点进行计算。
复杂度分成三等，即低、中、高。
对数据功能性的组件来说，复杂度决定于两个因素：
一是看ILF或EIF所包含的数据元素个数（DET：
DataElementTypes），另一个则是看ILF和EIF中用户可以识别的记录元素类型的个数（RET：
RecordElementTypes）。
而对事务功能性组件，复杂度则取决于事务所引用的所有内部文件或外部文件的个数（FTR：
FileTypeReferenced），以及事务处理过程中输入或输出文件中涉及的动态数据元素个数（DET）[5]。
按照IFPUG功能点计算实践手册4.1版本中的规定：
ILF和EIF的低、中、高三个级别的确定方法如表3.l所示[]。
表3.1ILF和EIF数据组件的复杂度级别
记录元素类型（RET）
数据元素类型（DET）
1～19
20～50
≥51
1
低
低
中
2～5
低
中
高
>5
中
高
高
EI事务组件的低、中、高三个级别的确定方法如表3.2所示[5]。
表3.2EI事务组件的复杂度级别
引用的文件类型
个数（FTR）
数据元素类型（DET）
1～4
5～15
≥16
0～1
低
低
中
2
低
中
高
≥3
中
高
高
EO和EQ事务组件的低、中、高三个级别的确定方法如表3.3所示[5]。
表3.3EO和EQ事务组件的复杂度级别
引用的文件类型个数（FTR）
数据元素类型（DET）
1～5
6～19
≥20
0～1
低
低
中
2～3
低
中
高
>3
中
高
高
每个组件按不同的复杂度等级与功能点数的对应关系如表3.4所示[5]。
表3.4五类组件按复杂度等级与功能点值的对应关系
组件
组件复杂度级别
低
中
高
ILF
____×7
____×10
____×15
EIF
____×5
____×7
____×10
EI
____×3
____×4
____×6
EO
____×4
____×5
____×7
EQ
____×3
____×4
____×6
这样，如果将一个应用系统按组件分解后，确定每个组件的复杂度等级，然后，按照IFPUG功能点计算实践手册给出的计算方法，就可以用IFPUG定义的功能点作为度量单位计算出该系统的规模。
但是，对同一个组件（例如对一个输入组件）若考虑到该组件要有较好的可操作性，或具有更高的执行效率等要求，则它应当具有更大的规模。
因此，单纯地考虑组件个数以及组件本身的复杂度来计算功能点，仍然不能较客观地反映出系统的规模。
为此，IFPUG还考虑了l4个称为系统基本特征的属性（GSC：
GeneralSystem
升级会员 