软件功能点度量方法概述

第 1 1 章软件功能点度量方法概述 本章介绍软件项目开发与维护所面临的典型问题，指出解决这些问题的基本途径是软 件项目的定量评价分析。在比较了各种软件定量评价方法的基础上建议采用功能点方法作 为软件定量评价的基础方法。本章进一步介绍目前被ISO 标准采纳的 5 种功能点标准，依 次是MarkII功能点标准、 COSMIC功能点标准、 NESMA功能点标准、 FISMA功能点标准以 及 IFPUG功能点标准。本章还对5 种功能点标准的不同之处进行了比对分析并给出了建议。 1.11.1软件困境 软件在我们生活和工作中的重要性正与日俱增。试想，没有银行软件系统和证券软件 平台的应用，庞大复杂的银行业务便不能有效地开展，证券业务也只能局限于现场交易， 因而不能发挥其应有的金融职能；没有网络管理软件系统的应用，快捷的电话联系方式也 是不可想象的；除了目前已经广泛应用的固定电话和移动电话业务之外，更有如雨后春笋 般出现的各种数据服务，例如宽带上网、GPS 定位导航等，而这些应用无一例外地依赖于 各种软件系统。软件应用对于很多行业的发展变革甚至起决定的作用，例如基于网络的传 媒信息更多地取代了传统的纸质媒体， 人们的阅读习惯因而发生了有史以来最重要的变化。 由此可见，软件无论在我们的生活还是工作中已经变得不可或缺。软件以其快捷、高 效、经济等诸多优势几乎渗透到各个行业中，正是软件的普及应用塑造了信息时代的主要 特征。因为软件应用的互通互联，因特网时代之前的“信息孤岛”正日益消亡，伴随着世 界范围内各种经济、科技和教育等方面的信息共享， “地球村”的预言正成为现实。具有讽 刺意味的是，软件在促进信息共享、信息透明的同时，自身却存在典型的“灯下黑”现象。 与传统的建筑等行业相比较，软件系统的建设与开发充满了各种不确定性。用户业务 需求不明确、工期和费用设置的盲目性、开发团队不稳定、人员的工作经验和技术水平参 差不齐、 “作坊式”开发模式等诸多因素使得软件开发往往达不到预期的目的。 软件开发与 建设对客户来说更多地呈现为“黑盒子”特征。实际开发出的软件系统往往差强人意，用 户在使用中抱怨不断，不能真正满足客户的要求。具体表现为所提交的软件系统功能与用 户期望的需求差异过大、工期严重拖延、费用超支明显、质量问题层出不穷等现象。导致 出现以上问题的原因纷繁复杂，但究其主要原因，则是因为软件系统的建设与开发的过程 中管理不善所致。大量的实践表明有效的软件项目管理是改善和提高软件系统建设与开发 效率的主要途径。要对软件项目进行有效的管理，首先得了解软件项目的特点。与传统行 业相比较，软件项目具备以下三个重要特点。 （1）前期业务需求不清，导致项目执行过程中需求频繁变更。 对于大部分软件项目，开发团队在启动软件需求分析之前都无法获取明确的需求。例 如对于一个电子政务项目而言，前期可能只会给出该项目的定位，例如“通过将现有手工 业务转变为软件支撑的电子流工作方式，提升工作效率，并对现有的业务模式进行合理优 化” 。可是如何对这样笼统的项目要求进行细化，并将其转变为相应的软件需求规格， 软件 开发团队还面临着各种挑战。首先是获取单一部门内的业务流程，现有的业务流程可能本 身就存在不合理或者冲突的情形，需要需求分析人员与业务人员进一步讨论才能确定。如 果涉及到部门之间的业务流程，其困难程度还会进一步加大，因为不同部门的人员都倾向 于站在自己的立场来考虑问题， 所以部门之间的业务流程确定往往还需要领导的强力参与。 伴随着组织业务流程的调整，通常意味着部门和人员的重新定位，有时甚至影响相关人员 的切身利益，此时的需求分析将会面临更大的阻力。 除了来自业务部门本身的挑战外，业务人员与技术人员的沟通也存在明显的障碍，即 客户与技术开发方对业务需求的理解不一致。客户方的业务人员通常认为自己对业务需求 的表述清楚无误， 而开发方却觉得业务人员语焉不详， 并没有将业务的来龙去脉交待清楚。 不少项目在各方对于需求的理解还未达成一致的情况下就开始项目， 结果项目是边做边改， 等到项目临近结束时，需求已“面目全非” ，与双方前期确定的需求相差甚远。 试想，一栋大楼或一座大桥在还未确定功能或结构的前提下就开始动工，然后在施工 的过程中再根据用户的要求不断变更，将会出现什么样的结果？结果很可怕，所以没人做 这样的尝试。但软件项目不然，环顾我们身边的软件项目，有多少项目真正能够做到“谋 定而后动”呢？正是软件需求的脆弱性和易变性导致了软件项目的失控。 （2）项目目标失控，明显超出客户心理预期。 所有的软件项目在初期都会设置相应的管理目标，包括项目所要实现的功能、项目工 期、 项目预算以及项目的质量目标等。 可是在项目开发的过程中却发现这些目标无异于 “海 市蜃楼” ， 可望而不可及。 大部分软件项目或多或少地表现出下列特征： 要么是 “种瓜得豆” ， 要求的功能大幅缩水；要么是项目工期严重滞后，影响客户业务的正常运行；或者项目严 重超支，软件开发商虽然投入了额外的人力物力，但客户并不领情；更有甚者，虽然软件 系统勉强按时上线，但后续的质量问题却层出不穷， “摁下葫芦浮起瓢” ，永远有解决不完 的问题。既然上述问题是目前软件项目所面临的共性问题，那么单一地将其归属为软件开 发商的责任似乎有失公允。 设想这样的场景：如果对一个小学班级进行数学测验，孩子们最后的平均成绩为 30 分 （考试采用百分制） 。30 分的平均成绩说明什么呢？首先孩子们的数学知识学得不够好，怎 么才考 30 分呢？其次，数学测验题目有问题，为孩子们设置了过高的目标要求 （学生家长 往往更倾向于这种结论） 。对软件项目而言，也存在类似的现象。所以在抱怨软件开发商工 作绩效的同时，客户似乎也应该进行自我反省，客户要求的目标合理吗？ 我国现在大部分的软件项目均采用招投标的方式来选择供应商，再加上在国内的软件 行业中普遍存在“买方市场”的特点，许多软件开发商都存在“先拿到合同再说”这样的 心理，故而往往对于客户所提的各种要求都满口应承，即使认为客户设置的项目目标不合 理，也往往忍气吞声、委曲求全①。也有一些软件开发组织与客户签署合同之前，对于客 户单方面设定的目标会提出不同的建议，例如更为合理的工期、成本与质量目标等，但这 些建议对于客户往往缺乏足够的说服力。因为大多数软件开发组织并没有一个明确的、量 化的过程可以向客户表明自己所建议目标的客观性、合理性，代之以“根据我们的经验” 、 “参照我们以前的项目”等说法，因而缺乏说服力，最终只能接受客户方设置的项目目标。 但软件项目最终的结果却让客户追悔莫及，油然而生“早知如今，何必当初”的感叹。所 以如何为客户设定合理的项目目标至关重要。 （3）软件项目的成功过度依赖个人，缺乏来自组织的过程保证。 成熟与不成熟的软件开发组织相比较，其最大差异在于两者的可预期性。不成熟的软 件开发组织往往倾向于过度承诺，而实际开发过程中却经常面临捉襟见肘的困境：要么是 工期严重滞后，要么是成本超支，工期若能勉强得到保证，通常即意味着质量风险。而高 成熟度组织所做出的承诺通常可以得到真实的兑现。在不成熟的软件开发组织内，更多地 采用“游击队” 、 “个人英雄主