软件专项项目管理概述

《软件专项项目管理概述》由会员分享，可在线阅读，更多相关《软件专项项目管理概述（76页珍藏版）》请在装配图网上搜索。

1、第14章 软件项目管理“项目”如今普遍存在于我们的工作和生活之中，并对我们的工作和生活产生着重要的影响。美国著名学者罗伯特.J.格雷厄姆曾说过：“因为项目是适应环境变化的普遍方式，故而一个组织的成功与否将取决于其管理项目的水平。”由于社会环境变化是绝对的，而当今社会唯一不变的就是变化，因此，一个组织要想存在和发展，就必须适应环境的变化，就必须开展项目。美国的项目管理权威机构项目管理协会（Project Management Institute, PMI）PMI认为，项目是一种被承办的旨在创造某种独特产品或服务的暂时性势力。在经历了软件危机和大量的软件项目失败以后，人们发现正是一系列管理问题和技

2、术问题导致了上述问题，终其原因，其一致原因可能就是：项目管理太弱。软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设范围内，有效地利用人力、资源、技术和工具，使软件系统或软件产品按原定计划和质量要求如期完成。14.1 软件项目管理概述项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目的特定目标的管理方法体系。其基本内容为 1）项目定义， 2）项目计划， 3）项目执行 ，4）项目控制， 5）项目结束。将软件进行项目管理也需采用上述5个方面的内容进行管理，由于软件项目的特殊性，将项目管理技术用于软件项

3、目管理上，其有效的项目管理集中于四个P上：人员（people）、产品（product）、过程（process）和项目（project）。14.1.1 人员Bill Curtis曾说过：“不同的人员在完成程序设计任务的能力上存在巨大的可变性。”培养有创造力的、技术水平高的软件人员是从20世纪60年代起就开始讨论的话题。而在人员管理上达到较高成熟度的组织更有可能实现有效的软件工程实践，为此，CMU软件工程研究所专门开发了一个人员管理能力成熟度模型（PMCMM），旨在“通过帮助吸引、培养、鼓励、部署和留住改善其软件开发能力所需的人才增强软件组织承担日益复杂的应用的能力。”人员管理成熟度模型为软件人员

4、定义了以下的关键实践区域：招募、选择、业绩管理、培训、报酬、职业发展、组织和工作设计以及团队精神/企业文化培养。在人员管理上达到较高成熟度的组织更有可能实现有效的软件工程实践。14.1.1.1 项目参与者参与软件过程（及每一个软件项目）的人员可以分为以下五类：1） 高级管理者。负责定义业务问题，这些问题往往对项目产生很大影响。2） 项目（技术）管理者。必须计划、激励、组织和控制软件开发人员。3） 开发人员。负责开发一个产品或应用所需的专门技术。4） 客户。 负责说明待开发软件的需求的人以及其他风险承担者。5） 最终用户。一旦软件发布成为产品，最终用户是直接与软件进行交互的人。每一个软件项目都有

5、上述的人员参与。为了达到高效，项目组的组织必须最大限度地发挥每个人的技术和能力。这是项目组负责人（项目经理）的任务。14.1.1.2 项目组负责人（项目经理）项目管理是集中于人的活动，软件项目组负责人（项目经理）除对其技术要求以外，更多地应具备管理人员应有的技能。 项目经理的任务就是要对项目进行全面的管理，具体表现在对项目目标要有一个全局的观点，并制定计划，报告项目进展，控制反馈，组建团队，在不确定环境下对不确定问题进行决策，在必要的时候进行谈判及解决冲突。项目经理的责任表现的三个方面：1） 对组织（企业）应承担的责任保证项目目标与组织（企业）的经营目标一致对组织分配给项目的资源进行适当的管理

6、，保证在资源约束条件所得资源能够被充分有效地利用与组织（企业）高层进行及时有效的沟通，及时汇报项目的进展状况，成本、时间等资源的花费，项目实施可能的结果，以及对将来可能发生的问题的预测。2） 对项目应承担的责任对项目成功负有主要责任，对项目实施计划、监督与控制，保证项目按时、在预算内达到预期结果。保证项目的整体性，保证项目在实施过程中自始至终以实现项目预期目标为最终目的，由于项目在实施过程中存在各种各样的冲突，项目经理在解决项目的冲突过程中起着重要的作用，做到化解矛盾，平衡利害。3） 对项目小组应承担的责任 为项目组成员提供良好的工作环境及氛围，项目经理作为项目负责人及协调人，首先应该保证项目

7、组成员形成一个好的工作团队，成员之间密切配合，相互合作，拥有良好的团队精神及好的工作氛围与环境，特别地，对项目组中的关键成员及高级研究人员要进行特别的照顾，这是激励项目成员的重要手段。 项目经理有责任对项目小组成员进行绩效考评。项目经理要建立一定的考评制度，对项目组成员的绩效进行监督与考评，公正的考评制度也是激励员工的一种手段。 由于项目小组是一个临时的集体，项目经理在激励项目成员的同时还应为项目小组成员的将来考虑，使他们在项目完成之后，有一个好的归属，这样可以使他们无后顾之忧，保证他们安心为项目工作。14.1.1.3 软件项目组软件项目组织结构有多种，但软件项目组织结构是不能轻易改变。在一个

8、新的软件项目中直接涉及到的人员的组织则是项目管理者的权限。在规划软件工程小组的结构时应考虑如下七个项目因素：1） 待解决问题的困难程度。2） 产生的程序的规模，以代码行或者功能点来衡量。3） 小组成员需要共同工作的时间（小组生存期）。4） 问题能够被模块化的程度。5） 待建造系统所要求的质量和可靠性。6） 交付日期的严格程度。7） 项目所需要的社交性（通信）的程度。从历史角度看，最早的软件小组是控制集中式（CC）结构，原来称为主程序员小组。这种结构由Harlan Mills首先提出，并由Baker描述出来。小组的核心是由以下人员组成的：高级工程师（“主程序员”），负责计划、协调和评审小组的所有

9、技术活动；技术人员（一般2到5个人），执行分析和开发活动；后备工程师，支持高级工程师的活动，并能在项目进行过程中以最小的代价取代高级工程师的工作。项目组必须建立有效的办法以协调参与工作的人员，要建立小组成员之间及多个小组之间的正式和非正式的通信机制。正式的通信是通过“文字、会议及其他相对而言非交互的非个人的通信渠道”来实现，非正式的通信则更加个人化。 14.1.2 产品在进行项目计划之前，应该首先建立产品目的和范围，考虑可选的解决方案，标识技术和管理的约束。没有这些信息，就不可能进行合理的（准确的）成本估算、有效的风险评估、适当的项目任务划分或是可管理的项目进度安排，项目进度安排给出了意义明确

10、的项目进展的标志。软件开发者和客户必须一起定义产品的目的和范围。在很多情况下，这项活动是作为系统工程或业务过程工程的一部分开始的，持续到作为软件需求分析的第一步。目的是标识出该产品的总体目标（从客户的角度），而不考虑这些目标如何实现。范围标识出与产品相关的数据、功能和行为，更重要的是，它以量化的方式约束了这些特性。一旦了解了产品的目的和范围，就要开始考虑备选的解决方案了。虽然这一步并不讨论细节，但它使得管理者和实践者可以选择一条“最好的”途径，该选择是根据产品交付的期限、预算的限制、可用的人员、技术接口及各种其他因素所形成的约束。14.1.2.1 软件范围软件项目管理的第一个活动是软件范围的确

11、定。范围是通过回答下列问题来定义的：1） 语境。待建造的软件如何适应于大型的系统、产品或商业的语境，在该语境下要加什么约束？2） 信息目标。软件要生产什么样的客户可见的数据对象作为输出？需要什么样的数据对象作为输入？3） 功能和性能。软件要执行什么样的功能使得输入数据变换成输出？需要满足任何特殊的性能特征吗？软件项目范围在管理层和技术层都必须是无二义性的和可理解的。对软件范围的描述必须是界定的。也就是说，明确给出定量的数据（如同时使用的用户的数目、邮件列表的大小、允许的最大响应时间），说明约束和/或局限（如产品成本限制内存大小），以及描述其他的缓解因素（如希望使用的算法能够被很好的理解并写成C

12、+程序）。14.1.2.2 问题分解问题分解有时称为划分或问题详细描述，它是一个软件需求分析的核心活动。在确定软件范围的活动中并不试图完全分解问题，而是将分解应用于两个主要方面：（1）必须交付的功能；（2）用于交付功能的过程。面对复杂的问题人类常常采用分而治之的策略。简单讲，就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策略。在估算开始之前，范围中所描述的软件功能必须被评估和细化以提供更多的细节。因为成本和进度都是面向功能的，所以某种程度的分解通常是很有用的。例如，考虑我们要建造一个新的字处理产品的项目。该产品的独特功能包括：连续的语音输入和键盘输入，高级的“自动复

13、制编辑”功能，页面布局功能，自动建立索引和目录以及其他功能。项目管理者必须首先建立软件范围陈述，该陈述限定了这些特征（以及其他的通用功能，如编辑、文件管理、文档生产等等）。例如，连续语音输入功能是否需要用户进行专门的产品“训练”？复制编辑特征提供了哪些能力？页面布局能力要高级到什么程度？随着范围陈述的进展，自然产生了第一级划分。项目组研究市场部与潜在客户的交谈并找出自动复制编辑应该具有下列功能：（1）拼写检查，（2）语句文法检查，（3）大型文档的参考书目关联检查（例如，对一本参考书的引用是否能在参考书目列表中找到？），（4）大型文档中章节的参考书目关联的确认。这些特征的每一项都是软件要实现的子

14、功能。同时，如果分解可以使计划更简单，则每一项又可以进一步细化。14.1.3 过程软件过程提供了一个框架，在该框架下可以建立一个软件开发的全面计划。少量的公共过程框架活动可应用于所有软件项目，不考虑其规模和复杂性。若干不同的任务集合（每一个集合都由任务、里程碑、工作产品以及质量保证点组成）使得框架活动能被修改，以适应于不同软件项目的特征和项目组的需求。最后是庇护性活动（软件质量保证、软件配置管理和测度）它们覆盖了过程模型。庇护性活动独立于任何一个框架活动，且贯穿于整个过程。软件过程的一般性阶段定义、开发和支持适用于所有软件项目。问题在于选择一个适合项目组要开发的软件的过程模型。我们曾讨论了多种

15、软件工程范型：l 瀑布模型。l 原型实现模型。l 增量模型。l 螺旋模型。l 喷泉模型。l 基于构件的开发模型。l 形式化方法模型。项目管理者必须决定哪一个过程模型最适合于：（1）需要该产品的客户和将做此工作的人员，（2）产品本身的特征，（3）软件项目组工作的工作环境。当一个过程模型被选定时，项目组然后基于公共过程框架活动集合，定义一个初步的计划。一旦建立了初步的计划，便可以开始进行过程分解，即必须建立一个完整的计划反映框架活动中所需要的工作任务。14.1.3.1 合并产品和过程项目计划开始于产品和过程的合并。软件项目组要开发的每一个功能都必须通过为软件组织定义的框架活动集合。假设组织采用了如

16、下的框架活动集合，该框架即为公共过程框架活动：l 客户交流建立开发者和客户之间有效需求诱导所需要的任务。l 计划定义资源、进度及其他相关项目信息所需要的任务。l 风险分析评估技术的及管理的风险所需要的任务。l 构造及发布构造、测试、安装和提供用户支持（如文档及培训）所需要的任务。l 客户评估基于对在工程阶段生产的或在安装阶段实现的软件表示的评估，获取客户反馈所需要的任务。开发某产品功能的项目组成员都要将每一个框架活动应用于该功能的实现上。实质上，产生了一个类似图14-1所示的矩阵。每一个主要的产品功能（图中列出了前述的字处理软件的功能）被列在左边的一列中，框架活动则列在顶端的一行中。软件工程工

17、作任务（对于每一个框架活动）列在紧接着的行中。项目管理者（和其他组员）的工作是估算每一个矩阵单元的资源需求、与每一个单元相关的任务的开始和结束日期以及每一个单元所产生的工作产品。公共过程框架活动软件工程任务产品功能正文输入编辑及格式设计自动复制编辑页面布局能力自动建立索引及目录文件管理文档生成图14-1 合并产品和过程 14.1.3.2 过程分解软件项目组在选择最适合项目的软件工程范型以及选定的过程模型中所包含的软件工程任务时，应该有很大的灵活度。一个相对较小的项目如果与以前已开发过的项目相似，可以采用线性顺序模型。如果时间要求很紧且问题能够被很好地划分，原型实现模型可能是正确的选择。如果时间

18、太紧，不可能完成所有功能时，增量模型可能是最合适的。类似地，具有其他特性（如不确定的需求、突破性的技术、困难的客户、明显的复用潜力等）的项目将导致选择其他过程模型。一旦选定了过程模型，公共过程框架（Common Process Framework, CPF）应该适应于它。在每一种情形，本章前面所讨论的CPF客户交流、计划、风险分析、工程、构造及发布、客户评估均可以被适合于该范型。它可以适用于线性模型，还适用于迭代和增量模型、演化模型甚至是并发或构件组件模型。CPF是不变的，它充当一个软件组织所执行的所有软件工作的基础。但实际的工作任务却是可变的。当项目管理者问到下面的问题时过程分解就开始了：“

19、我们如何完成这个CPF活动？”例如，一个小型的、相对简单的项目在客户交流活动中可能需要下列工作任务：1） 列出需澄清问题的清单。2） 与客户见面讨论需澄清的问题。3） 共同给出范围陈述。4） 和所有相关人员一起评审范围陈述。5） 根据需要修改范围陈述。这些事件可能在不到48小时的时间内发生。它们代表了适于小型的、相对简单的项目的一种过程分解。现在，我们考虑一个复杂些的项目，它具有更广的范围和更重要的商业影响。这样一个项目在客户交流活动中可能需要下列工作任务：1） 评审客户要求。2） 计划和安排与客户进行正式的、促进性的会议。3） 研究如何刻画推荐的解决方案和已有的方法。4） 为正式的会议准备一

20、份“工作文档和议程。5） 召开会议。6） 共同制订能够反映软件的数据、功能和行为特征的小规约。7） 评审每一份小规约，确认其正确性、一致性和无二义性。8） 把这些小规约组装起来形成一份范围文档。9） 和所有相关人员一起评审范围文档。10） 根据需求修改文档范围。两个项目都执行了我们称之为客户通信的框架活动，但第一个项目组只执行了第二个项目组一半的软件工程工作任务。14.1.4 项目我们进行有计划和可控制的软件项目的一个主要理由是：这是惟一知道的管理复杂性的方式。为了避免项目失败，软件项目的管理者和建造产品的工程师必须避免一些常见的警告信号，了解关键的项目管理的成功因素，并采用开发计划、监控和控

21、制项目的常用性方法。为了管理成功的软件项目，我们必须了解我们会做错什么（使得能够避免错误）和如何正确地完成任务。有如下10个信号指示一个信息系统项目正处于危险状态之中：1） 软件人员不了解他们的客户的需要。2） 产品范围定义糟糕。3） 没有很好地管理变化。4） 选择的技术发生变化。5） 业务需求发生变化（或未被很好地定义）。6） 时限是不现实的。7） 用户抵制。8） 失去赞助（或从来没有真正地得到过）。9） 项目组缺乏具有合适技能的人员。10） 管理者（和开发者）躲避已学到的最好的实践经验和教训。管理者如何避免上述的问题呢？可采用以下的软件项目方法：1） 在正确的基础上开始工作。这是通过努力工

22、作（非常努力）以理解将被解决的问题，而后为每个涉及到项目中的人员设置现实的目标和期望而达到的。然后又通过建立合适的开发小组并给予小组完成工作所需的自主权、权力和技术而增强。2） 保持动力。很多项目的启动有一个很好的开始，但是，慢慢地开始瓦解。为了维持动力，项目管理者必须提供激励措施以保持人员变动为绝对最小的量，小组应该强调它完成的每个任务的质量，而高层的管理应该尽其所有可能以不干涉小组的工作方式。3） 跟踪进展。针对软件项目，当工作产品（例如，规约、源代码、测试案例集合）被产出和作为质量保证活动的一部分而被批准（通过正式的技术评审）时，跟踪其进展。此外，软件过程和项目测度可以被收集并根据软件开

23、发组织的平均数据用于评估进展。 4） 做出聪明的决策。本质上，项目管理者和软件小组的决策应该是“保持其简单”。只要可能，决定去使用商用成品构件（COTS）软件或现存的软件构件，决定在标准的方法可用时避免定制界面，然后避免明显的风险，以及决定去分配比你认为需要的时间更多的时间来完成复杂的或有风险的任务（你将需要每一分钟）。5） 进行事后的分析。建立一个一致的机制以从每个完成的项目获取可学习的经验。评估计划的和实际的进度，收集和分析软件项目度量，从项目组成员和客户处获取反馈，并记录下所有发现。14.1.5软件项目管理过程软件项目管理的对象是软件工程项目，它所涉及的范围覆盖了软件工程过程，而现代项目

24、管理的要求就是要对项目的整个过程进行计划及实施的控制，就是对软件项目开发过程的保持、管理与质量和进度的控制。图142给出了一个软件项目管理和通用方法。图142软件项目管理过程示例由此可见，为使软件项目开发获得成功，在软件项目开始之前需进行可行性研究，在项目可行后进行项目策划（计划）阶段。关键的问题要对软件项目范围，各阶段/活动中可能存在的风险，需要和资源（包括人、软/硬件及其它资源），要实现的任务、经历的里程碑，花费的工作量及成本，进度安排等进行计划及控制。这种管理在技术工作开始就需进行，并在软件的概念到实现的过程中延续进行，并在软件工程过程最后结束时才终止。1）启动软件项目2）软件度量3）软

25、件项目估算4）风险分析5）进度安排6）项目组织7）软件配置管理14.1.5.1 启动一个软件项目在软件项目启动前，必须对该项目进行可行性分析，其中需明确项目的目标和范围，并在此基础上考虑候选的解决方案，估计新系统可能的开发和运行成本及其效益，同时给出该项目在技术和管理上的要求，在此基础上，相关人员可确定。合理、精确的成本分析实际可行的任务分解可管理的进度安排从而，可在多个方案中选择一个相对完善的方法，给出诸如交付期限、预算、个人能力、技术界面及其它许多因素构成的限制。14.1.5.2 软件度量软件度量是指计算机软件范围内的测度，可用于对产品开发的软件过程和产品本身进行测度，对软件开发过程度量的

26、目的是为了对过程进行改进，对产品进行度量的目的是为了提高产品的质量，度量的作用是为了有效地采用定量的方式来进行管理，而为了有效地进行度量，对过程及产品要考虑：1) 合适的度量是什么？2) 所收集的数据如何使用？3) 用于比较个人、过程或产品的度量是否合理？而管理人员就可利用这些度量来了解软件工程过程的实际情况及它所生产的产品质量。14.1.5.3 项目估算在软件项目管理过程中的关键活动就是制定项目计划，而在做项目计划时就需要对项目所需的人力（以人月为单位）、项目持续时间（以年份或月份为单位）、成本（以元为单位）进行估算。这种估算是利用以前的项目花费作参考的，若新项目与以前的某个项目在规模和功能

27、上十分类似，则新项目需要的工作量、开发持续时间和成本大致与那个老项目相同，而由于每个项目均是新项目，对新项目背景生疏，只凭过去的经验就显得十分不够，就有必要采用用于软件开发的估算技术，其共同特点是1) 事先建立软件范围2) 以以往项目的软件度量为基础，以作出估算。3) 项目在估算时可分解为可估算的小块。在项目估算时，通常采用多种估算技术，以利不同估算技术之间的交叉检查。14.1.5.4 风险分析现代项目管理的优势在于引进了风险分析技术，由于当前许多项目不进行风险分析就进行开发，就存在了较大的项目风险，每当在进行一个软件项目开发时，其人员、经费、进度及用户需求均存在着不确定的因素，如建立的软件系

28、统，其用户需求是否确切地被理解，是否还存在有技术难题。所谓风险分析实际上就是一系列风险管理的步骤，主要包括风险识别、风险估算、风险评价、风险管理和控制。这些步骤贯彻于软件工程过程中。14.1.5.5 进度安排对不同的项目，应有不同的项目进度安排，在项目估算的基础上，对一个项目进行进度的安排。进度安排的原则为：1) 任务划分及定义将项目划分为子项目、任务、活动等可以管理的部分。2) 确定任务的相互依赖性确定活动与任务之间的相互依赖关系，特别是活动与任务的前置任务及后置任务。3) 时间分配为每个任务确定其一定数量的工作时间，并需指定开始时间和结束时间。4) 责任分配将每个任务/活动分配给某个特定小

29、组或成员来负责。5) 定义的结果每个任务都应有一个目标，软件项目的目标通常是一个工作产品（如一个模块的设计）或某个工作产品的一部分，通常将多个工作产品组合成“可交付产品”。6) 定义的里程碑（milestones）每个任务或任务组都应该与一个项目里程碑相关联，当一个或多个工作产品经过质量评审并得到认可时，标志着一个里程碑的完成。14.1.5.6 追踪与控制一旦适应了项目开发计划，就可以开始进行项目追踪和项目控制，一旦项目出现进度/资源等变化，就需要对项目计划进行调整以利于更好地完成项目，最坏情况可以对项目的交付日期进行修改。14.2 软件度量和估算测度对于任何工程学科而言都是基本的手段，同样软

30、件工程领域也需利用测度。测度通过提供目标评价的机制从而使我们对目标做到更深的了解。软件度量是指计算机软件的范围广泛的测度，可用于对产品开发的软件过程和产品本身进行测度。测度应用于软件过程，其目的是在一个连续的基础上对它进行改进，即改进软件过程；测度也可以用于整个软件项目/产品中，辅助估算、质量控制、生产率评估及项目控制。最后，测度能够被软件工程师使用以帮助评估产品的质量且在项目进行中辅助进行战术决策，即软件度量的作用是为了更有效地定量地对过程/产品进行管理。软件工程的产品、过程资源都具有外部属性和内部属性，外部属性是面向管理者和用户的属性，体现了产品过程、资源与环境的关系，如成本、效益、程序员

31、的生产率及软件产品的可靠性、可用性、可维护性可移植性等。软件的内部属性是指软件产品过程资源本身的属性，如软件产品的结构、模块化程度、复杂性、程序长度等。软件外部属性在软件开发过程中很难测量和控制，但它是由软件的内部属性决定的，因此有必要研究软件的内部属性与外部属性之间的关系，并通过软件内部属性度量解决软件某些外部属性的度量问题，从而建立软件工程度量系统。测度在现实世界中可分为两类：直接测量（如螺钉的长度）和间接测量（如生产的螺钉的“质量”，由计算其次品率来测量）。软件度量也可以这样分类。软件工程过程的直接测量包括功能、质量、复杂性、有效性、可靠性、可维护性等。建造软件所需的成本和工作量、生产的

32、代码行数以及其他直接测量事相对容易收集到的，只要事先建立好测度的特定约定；然而，软件的质量和功能或其功效或可维护性是较难于评估的，只能间接测量。可以将软件度分成两类，第一类包括了面向规模的度量和面向功能的度量和面向人的度量；第二类包括生产率度量、质量度量的技术度量。它们之间的关系如图143所示图143 软件度量分类软件生产率度量主要集中在软件工程过程的输出，软件质量度量可指明软件满足明确的和隐含的用户需求的程度，技术度量主要集中在某些特征（如逻辑复杂性、模块化程度）上，而不是软件开发的全过程。面向规模的度量用于收集与直接度量有关的软件工程输出的信息和质量信息，面向功能的度量的注意力集中在程序的

33、“功能性”和“实用性”，面向人的度量则收集有关人们开发计算机软件所用方式的信息和人员理解有关工具的方法和效率的信息。14.2.1.1 面向规模的度量面向规模软件度量是通过规范化质量和/或生产率的测量而得到的，这些测量是基于所产生的软件的“规模”。 用软件项目和代码行（LOC）数表示软件项目的规模是十分自然和直观的，代码行数是可直接测量的，几乎所有的软件开发组织都保存软件项目的代码行数记录。利用代码行数不仅能度量软件和规模，还可度量软件开发的生成率、开发每行代码的平均成本、文档按代码的比例关系、每千行代码的软件错误数等，采用代码行数以LOC，常用千行代码数K LOG（1 KLOG=103 LOC

34、）来度量。软件生产率PLOC/E，其中E为软件开发工作量，常用人月（PM）度量，亦可用人日来度量，这样P就为每人月完成的代码行数。每行代码的平均成本C=S/LOC，即软件每行代码的平均成本，S用人民币（或其它货币）进行表示。需要注意的是，工作量和成本是指整个软件工程活动（包括分析、设计、编码和测试）的工作量和成本，而不仅仅指编码活动，因此，设Pe为读软件项目相关文档页数，可得到文档代码比D=Pe /KLOC；设N为代码中的错误总数，可得代码错误率EQR=N/KLOC。在一个组织中，常用一个表格来记录项目中面向规模的度量，如表141所示。表141 软件项目记录项目工作量（人月）成本（人民币，千元

35、）代码行（KLOC）文档页数（页数）错误审计项目609002002500300书店管理24150145123089酬金管理101205585021可得到表142的度量表142项目度量示例项目代码行（KLOC）生产率P每行代码成本C文档代码比D代码错误率EQR审计项目20033334.512.51.5书店管理14560411.038.480.61酬金管理5555002.1815.450.38 面向规模的度量并不被普遍接受为测量软件开发过程的最好方式，虽然其测试简单易行，但由于代码行依赖于程序设计语言的功能和表达能力；采用代码行估算方法会对设计精巧的软件项目及非过程程序设计语言产生不利的影响；同时

36、在项目初期难于估算代码行。14.2.1.2 面向功能的度量面向功能度量是由Albrecht于1979年首先提出来的，他建议一种称为功能点的测量。面向功能的软件度量使用软件所提供的功能的测量作为规范化值。因为“功能”不能直接测量，所以必须通过利用其他直接的测量来间接地导出。功能点是基于软件信息域的可计算的（直接的）测量及软件复杂性的评估而导出的。由于该方法主要考虑程序的“功能性”和“实用性”，而不是对LOC计数，因而，在软件设计初期就能够估算出软件项目的规模。功能点FP计算步骤如下：1） 计算信息域特征CT信息域特征是通过完成图144所示的表而计算出来的。其中确定了五个信息域特征，并在表中合适的

37、位置提供计算。信息域值按下列方式定义：（1）用户输入数。对每个用户输入进行计数，它们向软件提供不同的面向应用的数据。输入应该与查询区分开来，分别计数。（2）用户输出数。对每个用户输出进行计数，它们向用户提供面向应用的信息。这里，输出是指报表、屏幕、出错消息，等等。一个报表中的单个数据项不单独计数。（3） 用户查询数。一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。（4） 文件数。计数每个逻辑的主文件（即数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件）。（5） 外部接口数。计数所有机器可读的接口（如存储介质上的数据文件），利

38、用这些接口可以将信息从一个系统传送到另一个系统。测量参数计数加权结果简单平均复杂用户输入数346用户输出数457用户查询数346文件数71015外部接口数5710总计数值CT 图14-4 计算功能点度量2）一旦已经收集到上述数据，就将每个计算与一个复杂度值（加权因子）关联上。采用功能点方法的组织建立一个标准以确定某个特定的条目是简单的、平均的还是复杂的。不过，复杂度的确定多少有些主观。我们采用下面的关系式计算功能点（FP）：FP=总计数值CT*（0.65+0.01*Fi）其中“总计数值”是从图14-3得到的所有FP条目的总和。Fi（I=1到14）是基于对表143的回答而得到的“复杂度调整值”。

39、表143问题表问题Fi（1） 系统需要可靠的备份和恢复吗？（2） 需要数据通信吗？（3） 需要数据通信吗？（4） 性能很关键吗？（5） 系统是否在一个现存的、重负的操作环境中运行？（6） 系统需要联机数据登录？（7） 联机数据登录是是否需要在多屏幕或多操作之间切换以完成输入？（8） 需要联机更新文件吗？（9） 输入、输出文件或查询很复杂吗？（10） 内部处理复杂吗？（11） 代码需要被设计成可复用的吗？（12） 设计中需要包括转换及安装吗？（13） 系统的设计支持不同组织的多次安装吗？（14） 应用的设计方便用户修改和使用吗？每个问题的回答是使用从0到5衡量的，具体见表144，复杂度调整值数值

40、表。表144 复杂度调整值表值定义0没有影响1偶然的2适中的3普通的4重要的5极重要的3）在上述中的常量值和被应用到信息源计数的加权因子是根据经验确定的。一旦计算出功能点，则以类似LOC的方法来使用它们以规范化软件生产率、质量及其他属性的测量：l 每个功能点（FP）的错误数。l 每个功能点（FP）缺陷数。l 每个功能点（FP）成本。l 每个功能点（FP）文档页数。l 每人月完成的功能点（FP）数。14.2.1.3 扩展的功能点度量 功能点度量最初主要是用于商业信息系统应用中。为了适应这类应用，数据维（前面讨论的信息域值）被强调而排除功能维及行为（控制）维。因此，功能点度量不适合用于很多工程及嵌

41、入式系统（它们强调功能及控制）。为了解决这种情况，有学者提出了许多对功能点度量的扩展。一个称为特征点的功能点扩展是功能点测量的超集，能够被用于嵌入系统及工程软件应用。特征点度量适用于算法复杂性较高的应用。实时系统、过程控制软件及嵌入式软件应用都有较高的算法复杂性，因此适合特征点度量。为了计算特征点，还要进行14.2.1.2节所述的信息域值的再次计算和加权。除此之外，特征点度量增加了一个新的软件特性，即算法。算法定义为“特定计算机程序中所包含的一个界定的计算问题”。转置矩阵、解码一个位串或处理中断都是算法的例子。CT的值按表145重新计算，FP的值可接原公式计算。表145 扩展功能点为CT计算测

42、量参数值权值结果用户输入数4用户输出数5用户查询数4文件数7外部界面数7算法3总计数CT 14.2.1.4 调和不同的度量方法代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设计的质量。很多研究试图将FP和LOC测量联系起来。表146给出了在不同的程序设计语言中建造一个功能点所需的平均代码行数的一个粗略估算。查看表可知，C+的一个LOC所提供的“功能性”大约是C的一个LOC的2.4倍（平均讲）。进而，smalltalk的一个LOC至少是诸如Ada, COBOL, C传统程序设计语言的4倍。 LOC和FP测量常常用于导出生产率度量。这总是引起关于这类数据使用的争论。是否应该将某个

43、组的LOC/人月（或FP/人月）与另一个组的类似数据进行比较？管理者是否应该根据这些度量来评价个人的表现？这些问题的答案毫无疑问是一个“不”字。这个回答的理由是很多因素都会影响生产率，进行“苹果与桔子”的比较很容易产生曲解。基于功能点和LOC度量已被发现是软件开发工作量和成本的相对精确的判定，然而，为了将LOC和FP用于估算，必须建立历史的信息基线。14.2.2 软件质量度量14.2.2.1 软件质量定义及三层次度量模型软件质量是软件的生命，它直接影响软件的使用与维护。软件开发人员、维护人员、管理人员和用户都十分重视软件的质量。质量低下的软件不但影响基于计算机系统的工作效率，而且还可能给用户带

44、来灾难性的后果，如1962年美国飞向金星的空间探测器“水手一号”，因导航程序中的一个语句错误而导致探测器偏离航线。大量软件事故的惨痛教训时刻提醒人们千万不能忽视软件产品的质量。提高软件产品质量已成为软件工程的一项首要任务。由于软件开发人员、管理人员、维护人员和用户在软件开发、维护和使用过程中所处地位不同，他们对软件质量的理解和要求不同。如：管理人员十分关心软件开发采用的标准，在经费和时间允许的情况下，如何实现软件需求规格说明中定义的功能；维护人员特别重视软件的正确性、可理解性和可修改性；用户更关心软件的性能和可靠性等。因此，应该对软件质量给出一个客观的、科学的定义，并尽量予以量化。这对统一人们

45、对软件产品的质量的认识，在软件产品开发与维护过程中评价和控制软件产品质量都是十分必要的。1983年，ADSI/IEEEstd729给出的软件质量定义是：软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，包括如下几方面：（1） 软件产品质量满足用户要求的程度。（2） 软件各种属性的组合程度。（3） 用户对软件产品的综合反映程度。（4） 软件在使用过程中满足用户要求的程度。上述定义表明，软件质量依赖于软件的内部特征及组合。为了软件质量进行度量，首先必须对影响软件质量的要素进行度量，并建立实用的软件质量度量体系或模型。1968年，Rubey和Hartwick提出了软件某些属性的度量方法。19

46、76年，Boehm提出了定量评价软件质量的概念，并给出了60个软件质量度量公式和软件质量度量的层次模型；1978年，Walters和McCall提出了包括质量要素、准则和度量的三层次软件质量度量模型。随后，G.Murine又提出了软件质量度量技术，用于定量地评价软件质量。越来越多的人认识到，软件质量度量技术在定量地评价软件质量、管理软件开发和提高软件质量方面是十分重要的。例如，国际标准化组织（ISO）在1985年提出了软件质量度量（SQM）工作报告。表146 每功能点LOC值程序语言每FP之LOC值平均中等低高Access35381547Ada154104205APS868320184ASP6

47、96232127Assembler33731591694C16210933704C+665329178Clipper38392770COBOL777714400Cool:Gen/IEF383110180Culprit51Dbase IV52Easytrieve+33342541Excel47463163Focus43423256FORTRANFoxPro32352535Ideal665234203IEF/Cool:Gen383110180Informix42312457Java635377JavaScript58634275JCL9112326150JSP59Lotus Notes212215

48、25Mantis712722250Mapper1188116245Natural605222141Oracle30354217PeopleSoft33323040Perl60PL/786722263Powerbuilder323111105REXX67RPG/614924155SAS40413349Smalltalk26191055SQL40377110VBScript36342750Visual Basic474216158图145 McCall 的软件质量度量模型14.2.2.2 软件质量要素软件质量要素直接影响软件开发过程各个阶段的产品质量和最终软件产品质量。由于对软件质量理解的不断深化

49、，软件质量要素也不是一成不变的。McCall等人给出的软件质量要素共11个，分为三类。它们之间的关系如图146所示。第一类要素表现软件的运行特征，包括正确性、可靠性、有效性、完整性和可用性；第二类要素表现软件承受修改的能力，包括可维护性、灵活性和可测试性；第三类要素表现软件对新环境的适应程度，包括可移植性、可用性和可互操作性。我们已介绍了软件的可靠性、有效性、可维护性、可移植性和可重用性的概念。下面介绍软件的正确性、完整性、可用性、灵活性、可测试性和可互操作性的概念。（1） 正确性。程序满足规格说明及完成用户目标的程度。（2） 完整性。控制未被授权人员访问程序和数据的程度。（3） 可用性。学习

50、使用软件的难易程度，包括操作软件、为软件准备输入数据以及解释软件输出结果。图146 McCall的软件质量要素（4） 灵活性。改变一个操作程序所需的工作量。（5） 可测试性。测试程序使之具有预定功能所需的工作量。（6） 可互操作性。两个或多个系统交换信息并相互使用已交换信息的能力。各种软件质量要素之间的关系如表147所示。它们之间有正相关（），也有负相关（），因此在系统设计过程中应根据具体情况对各种要素的要求进行折衷，以便得到在总体上用户和系统开发人员都满意的质量标准。例如，实时控制系统的可靠性、有效性是决定系统成败的关键要素，必须全力保证，而软件的可移植性、可重用性就不是主要的了；又如，设计

51、通用的软件工具对于可维护性、可移植性、可重用性应该给予更多的注意，而有效性就不是影响系统成败的关键要素了。表147 质量要素之间的关系14.2.2.3 软件质量要素评价准则由于直接测量软件质量要素十分困难，在某些场合甚至是不可能的，于是McCall等人定义了一组比较容易度量的软件质量要素评价准则，通过这组评价准则间接测量软件质量要素。定义评价准则的基础是确定影响软件质量要素的属性。这些属性必须满足两个条件：（1） 能够比较完整、准确地描述软件质量要素；（2） 比较容易量化和测量。它们反映了软件质量的优劣。McCall定义的软件质量要素评价准则共21种，它们是：（1） 可审查性。检查软件需求、规

52、格说明、标准、过程、指令、代码及合同是否一致的难易程度。（2） 准确性。计算和控制的精度，是对无误差程度的一种定量估计。最好表示成相对误差的函数。值越大表示精度越高。（3） 通信通用性。使用标准接口、协议和频带的程度。（4） 完全性。软件不丢失各重要成分，完全实现系统所需功能。（5） 简明性。程序源代码的紧凑性。（6） 一致性。采用统一的概念、术语及符号，接口、规格说明等保持一致。（7） 数据通用性。在程序中使用标准的数据结构和类型。（8） 容错性。系统在各种异常条件下提供继续操作的能力。（9） 执行效率。程序运行效率。（10） 可扩充性。能够对结构设计、数据设计和过程设计进行扩充的程度。（1

53、1） 通用性。程序部件潜在应用范围的广泛性。（12） 硬件独立性。软件同支持它运行的硬件系统不相关的程度。（13） 检测性。监视程序的运行，一旦发生错误，标识错误的程度。（14） 模块化。划分成逻辑上相对独立的成分，具有良好的接口定义。（15） 可操作性。操作一个软件的难易程度。（16） 安全性。控制或保护程序和数据不受破坏的机制，以防止程序和数据受到意外的或蓄意的存取、使用、修改、毁坏或泄密。（17） 自文档化。源代码提供有意义文档的程度。（18） 简单性。理解程序的难易程度。（19） 软件系统独立性。程序与非标准的程序设计语言特征、操作系统特征以及其他环境约束无关的程度。（20） 可追踪性

54、。可在软件文档之间实现正向/逆向的追踪能力。（21） 易培训性。软件支持新用户使用该系统的能力。软件质量要素与评价准则之间的关系如表148所示。表148 质量要素与评价准则质量要素关系正确性可靠性有效性完整性可维护性可测试性可移植性可重用性可互操作性可用性灵活性评价准则可审查性准确性通信通用性完全性复杂性简明性一致性数据通用性容错性执行效率可扩充性通用性硬件独立性检测性模块化可操作性安全性自文档化简单性软件系统独立性可追踪性易培训性McCall等人提出的软件质量度量模型、软件质量要素和评价准则为软件质量管理奠定了基础。近年来，国内外许多软件工程组织和专家在软件质量要素和评价准则的选取度量方面做

55、了大量的工作，部分结果已用软件开发过程的质量控制和软件产品的质量度量。1987年，Hewlett-Packard提出一组称之为FURPS的软件质量要素。这组要素由功能性、可用性、可靠性、性能和可支撑性组成。Grad和Caswell给出了以调查报告/规格说明、设计、实现、测试、支撑为行，以上述要素为列的5行5列矩阵，通过对矩阵元素的度量导出软件开发过程和软件产品能质量要素的FURPS度量。1985年，国际标准化组织（ISO）建议，软件质量度量模型由3层组成。高层称软件质量需求评价准则（SQRC），中层称软件质量设计评价准则（SQDC），低层称软件质量度量评价准则（SQMC）。分别对应McCall

56、等人的要素、评价准则和度量。ISO认为，应对高层和中层建立国际标准，以便在国际范围内推广应用软件质量管理，而低层可由各使用单位自行制定。ISO高层由8个要素组成，中层由23个评价准则组成，它们之间的关系如表149所示。14.2.3 软件复杂性度量14.2.3.1 软件复杂性度量原则软件复杂性度量是软件度量的重要组成部分.任何一个有经验的程序员都知道，开发规模相同、复杂性不同的软件，花费的时间和成本会有很大差异。K.Magel从如下6个方面描述软件复杂性：（1） 理解程序的难度；（2） 纠错、维护程序的难度；（3） 向他人解释程序的难度；（4） 按指定方法修改程序的难度；（5） 根据设计文件编写

57、程序的工作量；（6） 执行程序时需要资源的程度。它反映了软件的可理解性、模块性、简洁性等属性。当前，还没有比较理想、全面、系统的度量软件复杂性的模型。人们一般认为，软件复杂性度量模型应遵循下列基本原则：（1） 软件复杂性与程序大小的关系不是线性的；（2） 控制结构复杂的程序较复杂；（3） 数据结构复杂的程序较复杂；（4） 转向语句使用不当的程序较复杂；（5） 循环结构比选择结构复杂，选择结构又比顺序结构复杂；（6） 语句、数据、子程序和模块在程序中的次序对复杂性有影响；（7） 全程变量、非局部变量较多时，程序较复杂；（8） 参数按地址调用比按值调用复杂；（9） 函数副作用比显式参数传递难于理解；（10） 具有不同作用的变量共用一个名字时较难理解。（11） 模块间、过程间联系密切的程序比较复杂；（12） 嵌套深度越深，程序越复杂。下面介绍几种满足上述部分原则的复杂性度量模型。表149 ISO质量要素要素关系正确性可容性有效性安全性可用性可维护性灵活性 可互操作性准则可追踪性完全性一致性准确性容错性简单性