软件人力成本估算(二)

p;           AI Shell         49         Forth          64
                    APL          32         Jovial          105
                Assembly (Macro)  320         Lisp           105
            ANSI/Quick/Turbo Basic  213       Modula 2        80
                Basic-Complied     64         Pascal          91
               Basic-Interpreted     91         Prolog          64
                     C           128     Report Generator     80
                    C++          29        Spreadsheet       6
                ANSI Cobol 85      91                                          
4  第二种改进方法
 以上是扩展功能点方法对功能点度量法的改进，下面再介绍一种针对中国软件企业普遍存在需求规格说明书不规范、实施功能点分析非常困难的实际情况,在此提出了一种改进方法,使用UML技术中的用例来生成规范的需求规格说明书，利用用例进行功能点分析。用例模型是对用户功能需求规范化的描述。通过全面定义用例模型，可以把用户对系统的功能需求,用比较规范的形式准确地表达出来。功能点可以认为是系统用例,系统用例模型是从业务用例模型和业务对象模型中提取出来的。业务对象模型提供对每个业务用例的实现，每个业务用例是一个业务的需求，解决一个业务问题或提供一个业务机遇。功能点的完整性实际上就是保证用户确认的业务问题得到解决，业务机遇得到获取的满足程度。需求规格说明书应该列出所有的系统用例，如果这些系统用例达到了上述要求，这个用例列表就是要“提炼”的功能点列表。
4.1 先介绍功能点的优缺点
 使用功能点分析具有以下优点:
 1)规模可在项目初期确定；
 2)可作为度量生产率改进的基准；
 3)独立于开发工具和环境，因而可用于衡量各种工具和环境下的生产率；
 4)提供各个项目间一致的规模度量方法。
 其缺点是:
 1) FPA的使用在RET和GSC的估算上是主观的，因其主观性使估算结果因人而异。
 2) FPA假设全部是部分的和，也就是说，分解系统的功能性，分别估算，然后用他们的和来反映整个系统。但事实并非如此，这也是任何分解法的弊端。一个复杂的系统采用的分析方法应比其各部分的和复杂得多，因为需要考虑各部分的集成。
 3)对复杂度重视不够。程序处理逻辑可能包含复杂的算法和计算，这可能耗费大量工作量而且隐含复杂度。该方法极其重视用户所见所得，而用户接触不到的逻辑处理的复杂度和所需工作量都被低估了，因为他们对用户来讲是不可见的。
 4) FPA只把复杂度粗略的分成三种类型(简单、一般、复杂)，这种描述过于简单，也丢失一些细节。虽然粗略分类使这种方法简单易用，但很不准确，因为忽略了同一类型的较高端和较低端之间的差别。
 5)这种方法在区分简单、一般、复杂类型的界线是极不妥当的，只要增加一个条目就能使整个系统的估算值变化很多。另一方面，它也很难扩展，因为对于无论多细的类别其最高复杂度的权重都是一样的(所有分类的最高等级都是公开的)。
 6)功能点不是实际的规模度量，它是在简化系统基础上的静态度量，它取决于分类的定义以及这些定义如何解释，这也是确定功能点计算的定义和解释。
 与代码行方法相比，功能点度量最大的优势就是可以在项目的早期进行规模度量和估算。理论上，只要有了详尽的需求规格说明书，就能够准确地估算出项目的规模。但是在实践中我们发现，在需求阶段进行功能点度量存在很大困难，主要包括以下几个方面:
 1)需求规格说明书不规范。
 在国内许多软件企业中，软件开发过程中的需求分析往往被当作一个可有可无的步骤而不受重视，甚至许多项目根本就不做需求分析，直接进入设计阶段。同时，绝大多数的开发人员都没有受过与需求的抽象、分析、文档、质检有关的教育。另外，也很难找到好的需求可以借鉴学习。尽管大多数的开发都采用了典型场景的方法，但它极少用有效的形式归档。造成有许多项目根本没有需求说明书，有的项目为了应付客户的要求，采取软件开发完毕后补写需求说明书的手段。虽然有些企业比较重视软件工程，在设计之前形成了需求说明书，但内容极不规范，这就给项目的规模度量和估算带来极大困难，也严重影响后续的成本和工作量度量，极易造成项目失控。
 2)功能分解随意性较大。
 由于没有统一的规定和约束，在进行功能点度量时如何进行功能分解，成为制约功能点度量的准确性和客观性的一个主要方面。对同一个项目，不同的度量人员往往会得出相差甚远的不同结果。主要原因就在于功能分解的完整性和不重复性很难把握，如何从需求分析说明书中准确提炼出系统的全部功能，并且保证在计算时没有重复计算，在实际操作中存在很大困难。
4.2  下面介绍一种利用UML建模技术对功能点度量模型的改进方法
 针对以上问题，提出一种改进方法，即使用UML中的用例建模技术来解决功能需求的规范化问题，这样，功能点可以认为是系统用例，需求规格说明书中建立的用例列表就是要“提炼” 的功能点列表。通过用例进行功能点分析是因为二者有内在的联系，功能点是从需求的角度度量软件规模，而用例是捕获需求的方法。功能点和用例都试图实现与软件的具体实现技术的无关性，用例可以验证提交的设计是否包含了所有的需求，用例的另一个优点是用例可以在生命周期的早期定义需求。如果用例很早就产生出来，然后进行功能点度量，对项目的估算和度量值就会精确得多。功能点分析将系统分解成更小的部件，以便用户、开发人员、项目经理能够更好地理解系统功能。用例同样采用了分解的方法，而且用例方法也是从用户实际使用系统的角度捕获需求，与系统如何实现这些功能无关。这就意味着通过用例形成的需求文档可以用于功能点分析(规模度量)。使用用例方法，可以在项目生命周期的早期准确度量规模，从而就能更好地估算和度量进度以及成本。另外，如果用例保持更新，功能点分析也保持更新，那么对项目进行的估算和度量也就可以容易地进行更新并对变更进行说明。Meli曾经提出，用例己经变成一个捕获用户需求的一般方法，因为用例是从用户的角度描述功能，他们应该很容易转换成功能点。但他没有给出具体的方法，而且对什么样的用例可以用于功能点分析也没有涉及。本文详细阐述用例如何形成需求，并且提出了只有系统用例才适合用于功能点分析的观点。
 4.2.1  UML简介：
 UML是统一建模语言的缩写，是三位最优秀的面向对象方法学的创始人Rumbaugh, Booch和Jacobson合作成果的结晶。UML在己有的三大面向对象方法学的基础上，抽象出表示它们的模型语言，并吸取了其它面向对象开发方法和近30年软件工程的成果。1997年11月被批准成为面向对象开发的行业标准语言。到目前为止，UML已获得了工业界、科技界和应用界的广泛支持，成为可视化建模语言事实上的工业标准。UML是一种通用的可视化建模语言，它支持面向对象的分析设计和从需求分析开始的软件开发的全过程。UML的概念及模型可以分成以下几类:
 (1)静态结构
 UML的静态结构描述了系统中的结构成员及其相互关系。系统的结构成员即类元，包括类、用例、构件和节点，为研究系统动态行为奠定了基础。静态视图包括类图、用例图、构件图和部署图。
 (2)动态行为
 动态行为描述了系统随时间变化的行为。动态行为又分为两种:一种是一个孤立对象的工作流程及状态的变化，对应的视图分别为活动图和状态机图；另一种是一系列相关对象之间交互作用时的通信，交互视图包括顺序图和协作图。
 (3)模型组织管理
 模型组织管理说明了模型的分层组织结构。包是模型的基本组织管理单元，用于存储、访问控制、配置管理及构造包含可重用的模型单元库。模型的组织管理用类图来实现，但又跨越了其它视图并根据系统开发和配置组织这些视图。包之间的依赖关系是对包的组成部分之间的依赖关系的归纳，系统整个架构可以在包之间施加依赖关系。因此，包的内容必须符合包的依赖关系和有关的架构要求。
 (4)扩展机制
 UML还包括多种具有扩展能力的组件，这些组件的扩展能力有限但很有用。这些组件包括约束、构造型和标记值，它们适用于所有的视图元素。
 4.2.2  用例(Use Case)
 (1)用例模型(Use case model)
 长期以来，在传统的软件开发和面向对象开发中，人们根据典型的使用情景来了解需求。但是，这些使用情景是非正式的，虽然经常使用，却难以建立正式文档。用例模型由Ivar Jacobson在开发AXE系统中首先使用，并加入由他所倡导的DOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后，面向对象领域己广泛接纳了用例这一概念，并认为它是第二代面向对象技术的标志。用例模型抽述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。首先，它描述了待开发系统的功能需求；其次，它将系统看作黑盒，从外部执行者的角度来理解系统；第三，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。在UML中，一个用例模型由若干个用例图描述，用例图主要元素是用例和执行者。
 (2)用例(use case)
 从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。以字处理软件为例，“将某些正文置为黑体”和“创建一个索引”便是两个典型的用例。在UML中，用例被定义成系统执行的一系列动作，动作执行的结果能被指定执行者察觉到。概括地说，用例有以下特点:
 ·用例捕获某些用户可见的需求，实现一个具体的用户目标。
 ·用例由执行者激活，并提供确切的值给执行者。
 ·用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。
 (3)执行者(Actor)
 执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可能有许多营销人员，但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个执行者表示。一个用户也可以扮演多种角色(执行者)。例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。在处理执行者时，应考虑其作用，而不是人或工作名称，这一点是很重要的。不带箭头的线段将执行者与用例连接到一起，表示两者之间交换信息，称之为通信联系。执行者触发用例，并与用例进行信息交换。单个执行者可与多个用例联系；反过来，一个用例可与多个执行者联系。对同一个用例而言，不同执行者有着不同的作用，他们可以从用例中取值，也可以参与到用例中。需要注意的是，尽管执行者在用例图中是用类似人的图形来表示的，但执行者未必是人。例如，执行者也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。通过实践，我们发现执行者对提供用例是非常有用的。面对一个大系统，要列出用例清单常常是十分困难。这时可先列出执行者清单，再对每个执行者列出它的用例，问题就会变得容易很多。
 (4)使用和扩展(Use and Extend)
 还有另外两种类型的连接，用以表示用例之间的使用和扩展关系。使用和扩展是两种不同形式的继承关系。当一个用例与另一个用例相似，但所做的动作多一些，就可以用到扩展关系。例如基本的用例是“进行交易”。交易中可能一切都进行得很顺利，但也可能存在扰乱顺利进行交易的因素。其中之一便是超出某些边界值的情况。例如，贸易组织会对某个特定客户规定最大贸易量，这时不能执行给定用例提供的常规动作，而要做些改动。我们可在“泊7交易”用例中做改动。但是，这将把该用例与一大堆特殊的判断和逻辑混杂在一起，使正常的流程晦涩不堪。将常规的动作放在“进行交易”用例中，而将非常规的动作放置于“超越边界的交易”用例中，这便是扩展关系的实质。当有一大块相似的动作存在于几个用例，又不想重复描述该动作时，就可以用到使用关系。例如，现实中风险分析和交易估价都需要评价贸易，为此可单独定义一个用例，即“评价贸易”，而“风险分析”和“交易估价”用例将使用它。请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中，而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。
 4.2.3  实现步骤：
 用例捕获用户需求
 （1）捕获执行者
 利用UML的技术进行功能需求分析时，第一步要做的是确定系统有哪些执行者。获取用例首先要找出系统的执行者，这可以通过用户对开发方所提的一些问题的答案来确定。以下问题可供参考:
 . 谁将要提供、使用或修改信息?
 . 谁将用到这些功能?
 . 谁对某些需求感兴趣?
 . 系统将交付哪个部门使用?
 . 谁将负责对系统的支持和维护?
 . 哪些是系统的外部资源?
 .要与系统进行交互的其它系统有哪些?
 （2）捕获用例
 执行者确定后，下一步的工作是捕获用例。同样，开发方也是通过提出问题的方法来获取用例。不同的是，这一次的问题主要由执行者来回答。主要的问题如下：
 . 执行者要求系统提供哪些功能(执行者需要做什么)?
 . 执行者需要读、产生、删除、修改或存储哪些信息?
 . 执行者要通知系统突发的、外部的事件有哪些?
 . 系统要通知执行者的事件有哪些?
 . 执行者是否要负责系统的启动和关闭?还有一些不针对具体执行者问题(即针对整个系统的问题)。
 . 系统需要何种输入/输出?输入从何处来?输出到何处?
 . 当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?
 . 已定义的用例集是否已包括系统的所有功能?需要注意的是：最后两个问题并不是指没有执行者也可以有用例，只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意的是，不同的设计者对用例的利用程度也不同。重要的是：在捕获用例时，心中一直所想的应该是系统要做什么，而不是系统应该怎么做。
 2、建立用例模型
 用例模型是使用UML进行功能需求分析的最终结果，是以用例图的方式来显示的。用例模型表示了系统与外界环境的交互及系统的主要功能。在这个阶段，为了画出用例图，可以考虑开发界面原型以定义边界。在用例图中，除了标志执行者与用例之间的联系外，还要标志用例之间的关系。
 3、利用用例建立需求规格说明书
 用例模型有两种基本风格：业务用例模型和系统用例模型。业务用例模型，通常称为基本或抽象用例模型，对行为需求的与技术无关的视图建模。而系统用例模型，也称为具体用例模型或详细用例模型，为行为需求的分析建模，详细描述用户将如何使用系统，同时它还提及系统用户接口方面的问题。在建立需求规格说明书的过程中，用例模型要经过由基本模型向系统模型的转换，它是分步骤、分层次的，大致过程如下表7:
 表7 需求细化级别
                   步骤        需求
                    1           业务需求最初很低级别的用例
                   2           界面规格说明书引入界面绑定时的级别
                   3           更多细节更多级别上的用例
                   4           完整的详细规格说明书用例的最终级别
  由表中可以看出，在建立需求规格说明书的过程中，用例的粒度级别是逐渐细化的。也就是说，首先编写业务用例作为所需的构思工作的一部分，然后在分析期间，将它们发展成系统用例。
 4、系统用例还是业务用例？
 下面对系统用例和业务用例进行对比分析。二者有以下一些区别:
系统用例嵌入了很多细节。
系统用例提及屏幕和报告。
因为业务规则反映系统必须实现的域的基本特征，所以两种版本都引用业务规则定义。
 系统用例的步骤比业务用例的步骤多。实际上，每个用例步骤应该只反映一个步骤。这样做有几个优点：用例更容易测试，因为每条语句都更加容易理解和验证；用例更加容易编写，因为当语句只做一件事时更容易简单描述。
用例步骤以主动语态、而不是以被动语态编写。
 两个版本都以类似“用例结束”或“在某些情况下用例结束”的步骤结束，以表示己经完全定义了操作过程的逻辑。
 通过以上的区别可以看出，如果以业务用例进行功能点分析，就可能丢失一些细节。因此，根据业务用例进行功能点分析无法保证功能点分析的功能完整性。另外，使用业务用例还会因为级别太低导致无法确定各种事务(EI, E0, EQ)或文件(ILF, EIF)的DET, RET或FTR数，从而无法确定功能复杂度，导致功能点分析无法进行。系统用例既提供了比业务用例更多的细节，又因为它将系统当作黑盒，不描述任何内部结构，并且只使用问题域的语言，因此需求分析所得到的系统用例列表可以看作功能点分析中的事务功能列表，此时用系统用例来进行功能点的分析是比较合适的。
5、利用用例确定系统功能点数
 得到以系统用例形式的表达的需求规格说明书以后，就可以利用用例确定系统的功能点数了以下仅介绍引进用例概念后不同的部分。
 （1）确定应用程序边界:
 用例方法和功能点分析方法的第一个步骤都是确定系统边界。边界代表系统及其执行者之间的接口，边界可能是一个用户界面，也可能是对其它系统的一次调用。这二种方法对系统边界的定义非常相似，功能点方法将边界定义为所度量软件和用户之间的界限。功能点方法中使用了“用户”这个术语，而在用例方法中则使用了“执行者”，二者实际上是等同的。
 （2）确定事务和文件:
 IFPUG功能点定义了五种主要部件(事务和文件)，以下是在采用用例方法后对这些定义的修订：
 1)事务:
 事务由一个或多个事件流进行定义。一个用例可能有一个或多个事务。一个系统用例对应一个事务。辅助场景有助于澄清事务。
 事务包括外部输入、外部输出和外部查询。外部输入(EI)：是数据从外向内跨越边界流动的一个基本处理。数据来自系统执行者，执行者能够增加、改变、删除内部逻辑文件（ILF）中的信息。数据既可以是控制信息，也可以是数据信息。如果数据是控制信息，那么就不必维护一个ILF的外部输出(EO)：是派生数据从内向外跨越边界流动的一个基本处理。数据传送给系统执行者，执行者能够更新内部逻辑文件（LF）。数据创建发送给其它执行者的报表或输出文件。这些报表和文件利用一个或多个ILF和EIF中包含的信息进行创建。外部查询(EQ)：是既具有输入部件，又具有输出部件的一个基本处理，执行者能够从一个或多个ILF和EIF中检索数据。输入处理不会更新和维护任何FTR (ILF或EIF)，输出处理则不包含派生数据。
 2)文件:
 内部逻辑文件(ILF)：用户可识别确认的一组逻辑上相关的数据，全部驻留在应用程序边界内部，通过外部输入进行维护。外部接口文件(EIF)：用户可识别确认的一组逻辑上相关的数据，只能用于外部引用，数据全部驻留在应用程序边界外部，通过另一个应用程序的外部输入进行维护。外部接口文件是另一个应用程序的内部逻辑文件。EIF和工LF的主要区别是EIF由另一个应用程序进行维护。
6、用例进行功能点估算的实例
 下面以一个简单的实例对上述步骤进行一下演示:
 员工查询系统功能描述:
 员工查询系统是一个用于从员工信息数据库中请求查询信息的应用程序，它也允许用户变更员工信息数据库中的信息。普通用户可以查询员工信息数据库并可以修改自己的信息。系统管理员可以查询、修改、添加或者删除员工记录。员工信息包括基本信息、职位信息以及部门信息，其中基本信息包括工号、姓名、电话、E-mail、身份证号码、传真，职位信息包括职位编码、职位名称，部门信息包括部门编码、部门名称、办公地点。
 捕获执行者
 本系统比较简单，执行者只有普通用户和系统管理员二种。
 捕获用例
 用例包括：查询记录、修改记录、添加记录、删除记录，其中修改、添加和删除记录时都需要进行身份验证，所以还有一个身份验证用例。
 建立用例模型
 用例模型包括用例图和用例描述，用例图由执行者(Actor)、用例(Use Case)、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。为了画出用例图，首先开发界面原型以定义边界和划分功能点要素。我们来定义程序的主窗口:主窗口用于数据录入和数据检索，包括菜单条、员工信息、职位信息、部门信息、员工清单列表框等。我们可以看出，系统至少包含3个ILF，分别对应基本信息(员工文件)、职位信息(职位文件)和部门信息（部门文件）。
 （5）确定未调整事务功能点
 本例有5个事务，分别对应用例图中的5个用例，即查询记录(EQ)，修改记录(EI)，添加记录(EI)、删除记录(EI)、安全验证(EQ)。查询记录(EQ)包含11个DET (工号、姓名、电话、E-mail、身份证号码、传真、职位编码、职位名称、部门编码、部门名称、办公地点)，3个FTR(员工文件、职位文件、部门文件)，复杂度为中。修改记录(EI)包含9个DET(工号、姓名、电话、E-mail、身份证号码、传真、职位编码、部门编码、提示信息)，4个FTR(员工文件、职位文件、部门文件、安全文件)，复杂度为高。添加记录(EI)包含9个DET(工号、姓名、电话、E-mail、身份证号码、传真、职位编码、部门编码、提示信息)，4个FTR(员工文件、职位文件、部门文件、安全文件)，复杂度为高。删除记录(EI)包含3个DET(工号、确认信息、提示信息)，2个FTR(员工文件、安全文件)，复杂度为低。安全验证(EQ)包含6个DET(员工号、安全级别、用户名、密码、验证次数、提示信息)，1个FTR(安全文件)，复杂度为低。
 未调整数据功能点为:3+4+4+3+1=15
 （6）确定未调整功能点数为:38+15=53
 （7）确定值调整因子:为简便起见，本例取VAF=1
 （8）确定调整后的功能点数为:53×1=53
 用例模型是对用户功能需求规范化的描述。通过全面定义用例模型，可以把用户对系统的功能需求，用比较规范的形式准确地表达出来。功能点可以认为是系统用例，系统用例模型是从业务用例模型和业务对象模型中提取出来的。业务对象模型提供对每个业务用例的实现，每个业务用例是一个业务的需求，解决一个业务问题或提供一个业务机遇。功能点的完整性实际上就是保证用户确认的业务问题得到解决，业务机遇得到获取的满足的程度。需求规格说明书应该列出所有的系统用例，如果这些系统用例达到了上述要求，这个用例列表就是要“提炼”的功能点列表。需要说明的是，软件需求规格说明书(SRS)是技术性的商业管理文档，和用例模型不一样，用例模型是纯技术性的技术管理文档。得到用户签字的SRS如果包含用例模型信息，可以直接进行功能点度量。否则，就要首先提炼功能点，也就是将SRS以系统用例的形式表达。
5  提出一种新的估算方法
 下面介绍一种将算法模型法、专家小组法和类比估算法结合起来，互相取长补短，由层次分析法（AHP法）得到各种估算法的权重，再由权重合成法得到估算成本。并给出了 实例。
5.1首先进行几种方法的比较
 算法模型法
 算法模型法提供一个和多个数学算法，这些算法将软件成本估算值看成作为主要成本驱动因素的若干变量的函数。用于软件成本估算的最常见的算法形式有线性模型、乘积模型、解析模型、表格模型和复合模型等。
 与其它估算方法相比，算法模型具有许多长处。它们目的明确，并且不受要求在竞争中取胜、想使大家心里都高兴或厌烦该项目之类的因素的影响。它们估算的成果是可重复的。使用起来效率很高，都支持进行一序列的估算值族或灵敏性分析。它们还能针对以前的经验客观的进行标定。
 由于在软件开发中非线性相互作用太多，所以很多地方线性成本估算模型无法胜任；对于乘积模型，如果所选的变量非常独立，该模型的乘积形式似可胜任，但实际中变量之间的联系是非常紧密的，所以会造成对成本和相互影响的双重计算问题，而且，变量的值只能取-1，0和1的限制会造成某种不稳定的模型，成本的估算值只能做大幅度变动；解析模型只包含少量的变量，因此有许多对软件成本起决定性作用的因素（比如硬件限制）无法对该模型起作用；对于表格模型，如果采用的变量过少，有些对软件成本起决定性作用的因素就无法对该模型起作用；如果采用的变量过多，就需要大量的实测数据，就需要配备更大的数据库，从而增加了开支；复合模型综合了以上各模型，主要缺点是计算庞大，需要的数据太多，难于学习和手工使用。
 算法模型的一般缺点为：它们要针对以前的项目进行标定，对于采用新的技术、采用新的计算机系统结构、处理新的应用领域等等的未来项目，无法用以前项目的代表性能达到的程度来标定。它们无法处理异常情况，尤其是异常的人事情况、异常的课题组工作情况或在项目的人事安排和所要完成的任务之间配合不正常（或不匹配）情况。并且，同任何其它模型一样，对于质量不高的规模估算输入值和不精确的成本驱动因子的等级划分，算法模型也无能为力。
 专家判定法
 专家判定法就是与一位或多位专家进行商讨，专家用自己的经验和对所提及的项目的理解，得出该项目的成本估算值。本方法的长处和短处与算法模型的长处和短处正好互补。
 专家判定的长处在于它能够处理在过去项目的经验和未来项目所包含的新技术、体统结构或应用之间的差异。专家还能处理异常的人事情况及其互相影响或其它特殊的项目情况。
 专家判定的弱点在于过分依赖于专家的经验（和算法模型恰好相反，算法模型过分依赖于数据），无法逾越估算者在见解和客观性方面的不足、估算者可能会有偏见、乐观、悲观或对该项目的一些关键方面不太熟悉。另外，欲在专家迅速做出的（及时、高效但难于标定和说明其理由的）估算值和彻底的、文档齐全的、得到专家组一致同意的（根据及分析较为充分，但非常耗时，并且，到下一次当规格说明书作了某些改动时，很难重复这一过程）估算值之间进行平衡是十分困难的。另外，在处理从专家那里得来的多个估算值时，如果采用简单的求中值或平均值的方法，可能受一、两个极端估算值的影响而产生严重的偏差；如果采用召开小组会议的方法，一些成员可能会过分地受比较善辩和自信的成员的影响，也可能受权威人士或政治因素的影响。
 类比估算方法
 类比估算方法就是用一个或多个已完成的项目相类比的办法进行推断，并将它们的实际成本与之相类似的新项目的成本估算值相联系。
 类比估算方法的主要长处在于估算值是根据某个项目的实际经验得出的可以对这一项目进行研究以推断新项目的某些不同之处及其对成本可能产生的影响。
 类比估算方法的主要弱点在于无法弄清以前的项目究竟在多大程度上实际代表了新项目的限制、技术、人事和软件所执行的功能。为了找到合适的类比对象，需要对以前的很多项目有详尽的了解，包括人力、财力、硬件设施、管理和当时的开发背景等等。这就需要做大量的调查工作。
 新方法和实现步骤
 通过上面的比较和分析，这里提出了一种新的软件成本估算方法：将算法模型、专家小组法和类比算法结合起来，互相取长补短，由层次分析法（AHP法）得到各种估算法的权重，再由权重合成法得到估算成本。下面是计算步骤。
 用COCOMO模型估算成本
 对开发费用估算国外较常引用的是指数模型
      MM=a(KDSI)b
 这里的MM是软件开发需要的人月数，KDSI是软件规模值，单位为千行源代码，a，b是取决于软件开发环境及应用特征的常数。
 软件开发周期为     TDEV=c(MM)d
 c，d为常数，不同公司的值不完全一样。
 COCOMO(constructive cost model)模型是B.W.Boehm在《Software engineering economics》Tr.IEEE.Soft.Eng.No.1，1984中，根据美国TRW公司的主要在宇航方面应用的63个软件项目总结出来的

首页 上一页 1 2 下一页 尾页 2/2/2

软件人力成本估算(二)相关范文