软件维护与项目管理.ppt

7,7.1软件维护,7.1.1 软件维护概述,软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改，修改时应充分利用源程序修改后要填写程序改登记表，并在程序变更通知书上写明新旧程序的不同之处。,1软件维护概念,2软件维护的内容,软件的可维护性,软件的维护是十分困难的，为了使软件能易于维护，必须考虑使软件具有可维护性。,1可维护性定义,定义：软件能够被理解、校正、适应及增强功能的容 易程度。,软件的可维护性、可使用性、可靠性是衡量软件质量的几个主要特性，也是用户十分关心的几个问题。,软件的可维护性是软件开发阶段的关键目标。影响软件可维护性的因素较多，设计、编码及测试中的疏忽和低劣的软件配置，缺少文档等都对软件的可维护性产生不良影响。软件可维护性可用下面七个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。对于不同类型的维护，这七种特性的侧重点也是不相同。,2可维护性质量,目前有若干对软件可维护性进行综合度量的方法，但要对可维护性做出定量度量还是困难的。还没有一种方法能够使用计算机对软件的可维护性进行综合性的定量评价。下面是度量一个可维护的软件的七种特性时常采用的方法，即质量检查表、质量测试、质量标准。质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。质量测试与质量标准则用于定量分析和评价程序的质量。由于许多质量特性是相互抵触的，要考虑几种不同的度量标准去度量不同的质量特性。,3提高可维护性的方法,从下面五个方面来阐述如何提高软件的可维护性：,（1）建立明确的软件质量目标,（2）使用先进的软件开发技术和工具,如果要程序满足可维护性七个特性的全部要求，那么要付出很大的代价，甚至是不现实的，但有些可维护性是相互促进的，因此要明确软件所追求的质量目标。,利用先进的软件开发技术能大大提高软件质量和减少软件费用。面向对象的软件开发方法就是一个非常实用而强有力的软件开发方法，用面向对象方法开发出来的软件系统，稳定性好，比较容易修改，比较容易理解，易于测试和调试，因此，可维护性好。,（3）建立明确的质量保证,质量保证是指为提高软件质量所做的各种检查工作。质量保证检查是非常有效的方法，不仅在软件开发的各阶段中得到了广泛应用，而且在软件维护中也是一个非常主要的工具。,在检查点进行检查；验收检查周期性的维护检查；对软件包的检查。,为了保证可维护性，以下四类检查是非常有用的：,（4）选择可维护的语言,程序设计语言的选择对维护影响很大。低级语言很难掌握，很难理解，因而很难维护。一般来说，高级语言比低级语言更容易理解，第四代语言更容易理解，容易编程，程序容易修改，改进了可维护性。,（5）改进程序的文档,程序文档是对程序功能、程序各组成部分之间的关系、程序设计策略、程序实现过程的历史数据等的说明和补充。程序文档对提高程序的可阅读性有重要作用。为了维护程序，人们必须阅读和理解程序文档。,软件维护的实施,1主要任务,软件维护的主要任务包括以下两点：,（1）维护组织机构 对于大型软件系统，建立一个专门的维护组织机构是必需的。即使是对较小的软件系统，也要委派一个专人负责软件维护工作，特别是收集、保存、整理维护活动的文档资料的工作是必须随时要做的。在维护活动开始之前必须明确维护活动的审批制度。每个维护要求都要通过维护管理员转交给系统管理员去评价。系统管理员对维护申请做出评价后，由主管部门（人）决定是否进行软件修改。接到审批的维护申请报告后，将维护任务下达给指定的维护人员，并监控维护活动有条不紊地开展。合理的组织机构和精干的维护人员是保障维护活动顺利实施的基础。,（2）维护报告 任何维护申请都应该按规范化的方式提出。通常要求用户填写维护申请表。表中必须完整地描述每个错误发生的环境，包括：输入数据、输出结果等有关信息。对于适应性或完善性的维护要求，还应该提出一份修改说明书，提出用户希望的修改。维护申请表交维护组织后，经有关人员认真分析，并根据分析结果制定软件修改报告，内容应包括：,维护要求的性质；维护活动的优先顺序；计算满足维护申请表中提出的软件变更所需要的工作量；预计软件变更后的状况。,2维护阶段,软件维护的六个阶段如下：,（1）实施阶段包括软件准备和过渡活动，比如维护计划的构思与创建，为解决开发过程中所发现的问题而做的准备，以及后续的产品配置管理。（2）一旦维护团队正式接手应用，就进入了问题与修改分析阶段。维护人员必须分析每个请求，对其进行确认（通过重建应用环境）并验证其有效性，调查并提出解决方案，记录请求和解决方案，最后获取所有需要的授权来应用修改。（3）该阶段为实施修改的阶段。,（4）在接受修改阶段，由请求的提交者进行检查，以确保所做的修改解决了相应的请求。（5）迁移阶段（比如平台迁移）是个特例，并不会在所有的维护任务中都出现。如果软件必须在功能没有任何改变的情况下迁移到另一个平台上，那么这个阶段将被实施，通常这项任务会被指派给一个维护工程团队。（6）最后一个维护阶段，也并不会在每个软件中都发生，就是对软件某一部分的弃用。,3维护问题,软件维护的绝大多数问题与软件定义和软件开发阶段所采用的设计方法、指导思想、技术手段、开发工具等有直接的关系，同时与维护工作的性质也有一定的关系。,主要问题是：（1）理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有源代码而没有相关的文档，问题会更加严重。（2）严格按规范化方法开发的软件系统一般不需要大的维护活动，而需要维护的软件系统却往往因为没有必需的文档或文档残缺不全，使得维护活动进展非常艰难。,（3）当需要对软件进行维护时，很难指望熟悉软件系统的原开发人员能全力以赴地亲临现场参与维护活动。（4）绝大多数软件在设计时没有考虑将来的修改。（5）软件维护不是一项吸引人的工作。最出色的、成功的维护也只不过是保证他人开发的系统能正常运行，而且维护别人开发的软件经常受挫，使得维护人员无成就感。,7.2 软件再工程,7.2.1 软件再工程概念,软件再工程是指对既存对象系统进行调查，并将其重构为新形式代码的开发过程。最大限度地重用既存系统的各种资源是再工程的最重要特点之一。从软件重用方法学来说，如何开发可重用软件和如何构造采用可重用软件的系统体系结构是两个最关键问题。不过对再工程来说前者很大一部分内容是对既存系统中非可重用构件的改造。,软件再工程模型是一个循环模型，该模型中的每个活动均可能被重复。软件再工程模型如有图所示：,(1)库存目录分析(Inventory Analysis),每个软件组织应该保存所有应用的库存目录。该目录可能仅仅是包含如下信息的一个电子表格模型：,应用的名字。最初构建的年份。已对它进行过的实质性修改的次数。完成这些修改所花费的总劳动。最好一次实质性修改的日期。最好一次实质性修改所花费的劳动。它驻留的系统。和它有接口的应用。,它访问的数据库。过去18 个月所报告的错误。用户数量。它被安装的机器数量。程序结构的复杂性、代码的复杂性和文档的复杂性。文档的质量。整体可维护性(等级值，scale value)。预期寿命(以年算)。预期在未来36 个月内的修改次数。年度维护成本。,年度运作成本。年度业务值。业务重要程度,应该对每一个现存的应用收集上面列出的信息，通过按照业务重要程度、寿命、当前可维护性、以及其他局部重要标准对这些信息排序，可以选出再工程的候选者，然后可以明智地分配资源。必须注意：上面描述的目录表应该定期整理修订，应用的状况(如，业务重要程度)可能随时间发生变化，其结果是：再工程的优先级将发生变化。,(2)文档重构（document restructuring）,文档重构主要是实现了同一概念信息的聚集，是更接近于人类进行信息查找的思维方法。,贫乏的文档是很多遗产系统的注册商标。但是，我们对此可做些什么呢？选项1：建立文档是非常耗费时间的。系统正常运作，我们将保持现状。在某些情况下，这是一个正确的方法，不可能为数百个计算机程序重新建立文档。如果一个程序是相对静止的，正在走向其有用生命的末端，并且可能不会再经历什么变化，那么，让它保持现状。,选项2：文档必须更新，但是，我们只有有限的资源。我们将使用“使用时建文档”的方法。可能不需要对某应用全部重构文档，而是对系统中当前正在进行改变的那些部分建立完整文档。随时间流逝，将得到一组有用的和相关的文档。选项3：系统是业务关键的，而且必须完全地重构文档。即使在此情形，明智的方法是设法将文档工作减少到必需的最小量。每个选项均是可行的，软件组织必须选择最适合于每种情形的方法,(3)逆向工程(reverse engineering),术语“逆向工程”源于硬件领域，一个公司分解某竞争者的硬件产品去了解竞争者的设计和制造“秘密”。如果得到了竞争者的设计和制造规约，则这些秘密可以被很容易地理解。但是，这些文档是别人专有的，对做逆向工程的公司来说是不可得到的。本质上，成功的逆向工程通过检查产品的实际样本导出一个或多个关于产品的设计和制造规约。,软件的逆向工程是相当类似的。然而，在大多数情况下，被逆向工程的程序不是来自于竞争者，而是公司自己的软件(经常是很多年以前的)。将被理解的“秘密”是未开发过相关规约所带来的模糊不明。因此，软件的逆向工程是分析程序以在比源代码更高的抽象层次上创建程序的某种表示的过程。逆向工程是一个设计恢复过程，逆向工程工具从现存的程序中抽取数据、体系结构和过程的设计信息。,(4)代码重构(code restructuring),最常见的再工程类型(实际上，在这里使用术语“再工程”是有疑问的)是代码重构。某些遗产系统具有相对完整的程序体系结构，但是，个体模块被以难于理解、测试和维护的方式编码。在这样的情形下，在可疑模块内的代码可被重构。为了完成该活动，用重构工具去分析源代码。标注出和结构化程序设计概念相背的部分，然后重构代码(此工作可以自动进行)。复审和测试生成的重构代码以保证没有引入异常和不规则。更新内部的代码文档。,(5)数据重构(data restructuring),数据体系结构差的程序将难于进行适应性修改和增强。事实上，对很多应用来说，数据体系结构比源代码本身对程序的长期生存力有更大影响。和代码重构不同，数据重构发生在相当低的抽象层次上，它是一种全范围的再工程活动。在大多数情况下，数据重构以逆向工程活动为开始，当前的数据体系结构被分解。必要时，定义数据模型，标识数据对象和属性，并从质量的角度复审现存的数据结构。,当数据结构较差时(例如，平坦文件正被实现，而关系型方法将大大地简化处理)，数据被再工程。因为数据体系结构对程序体系结构及其中的算法有很强的影响，对数据的改变将总是会导致体系结构或代码层的改变。,(6)正向工程(forward engineering),在理想的情况，可以使用自动的“再工程引擎”来重建应用，旧的程序被输入引擎，分析、重构、然后以展示软件质量最好的方面的形式重新生成。在短期内，这样的“引擎”还不可能出现。正向工程也称为革新或改造，不仅从现存软件恢复设计信息，而且使用该信息去改变或重构现存系统，以改善其整体质量。在大多数情况，被再工程的软件重新实现现存系统的功能，并且加入新功能和/或改善整体性能。,7.2.2 逆向工程,逆向工程是对产品设计过程的一种描述。逆向工程产品设计可以认为是一个从产品到设计的过程。简单地说，逆向工程产品设计就是根据已经存在的产品，反向推出产品设计数据的过程。随着计算机技术在各个领域的广泛应用，特别是软件开发技术的迅猛发展，基于某个软件，以反汇编阅读源码的方式去推断其数据结构、体系结构和程序设计信息成为软件逆向工程技术关注的主要对象。,逆向工程过程及用于实现该过程的工具的抽象层次是指可从源代码中抽取出来的设计信息的精密程度。理想地，抽象层次应该尽可能高，即，逆向工程过程应该能够导出过程的设计表示(一种低层的抽象)；程序和数据结构信息(稍高一点层次的抽象)；数据和控制流模型(一种相对高层的抽象)；以及实体-关系模型(一种高层抽象)。随着抽象层次增高，软件工程师获得更有助于理解程序的信息。,逆向工程过程的完整性是指在某抽象层次提供的细节程度。在大多数情况，随着抽象层次增高，完整性就降低。交互性是指为了建立一个有效的逆向工程过程，人和自动工具“集成”的程度。在大多数情况，随着抽象层次增高，交互必须增加，而完整性将遭受损害。如果逆向工程过程的方向是单向的，所有从源程序中抽取的信息被提供给软件工程师，他们然后可以在任何维护活动中使用这些信息。如果方向是双向的，则信息被输入到再工程工具，以试图重构或重生成旧程序。,逆向工程的核心是被称为抽取抽象的活动，工程师必须评价旧程序并从源代码(经常是无文档的)中抽取出被执行的处理、被应用的用户界面、以及被使用的程序数据结构或数据库的有意义的规约。,1处理的逆向工程,第一个真正的逆向工程活动从理解然后抽取源代码所表示的过程抽象的启图开始。为了理解过程抽象，要在不同的抽象层次分析代码：系统、程序、模块、模式和语句。在进行更细节的逆向工程前必须理解整个系统的整体功能。这为进一步的分析建立语境，并提供对系统中应用间的互操作问题的洞悉。构成应用系统的每一个程序代表了在高详细层次的功能抽象，建立表示这些功能抽象间的交互的块图；每个模块执行某种子功能并表示某种定义的过程抽象，为每个模块建立处理叙述。在某些情况，系统、程序和模块规约已经存在，在此情况下，复审这些规约以保持和现存代码的相符性。,当考虑模块中的代码时，事情变得更复杂。工程师需寻找表示类属过程模式的代码段。几乎在每个模块中，一个代码段为处理(在模块内)准备数据，一个不同的代码段完成处理工作，而另一个代码段准备处理的结果以从模块输出。在每个代码段中，我们可能遇到更小的模式(例如，数据确认和范围检查经常出现在为处理准备数据的代码段中)。对大型系统，通常用半自动方法来完成逆向工程。,2数据的逆向工程,数据的逆向工程发生在不同的抽象层次。在程序层，作为整体再工程努力的一部分内部的程序数据结构必须被逆向工程。在系统层，全局数据结构(如，文件、数据库)经常被再工程以便符合新的数据库管理范型，当前全局数据结构的逆向工程设置了引入新的系统范围数据库的场所。,针对内部程序数据的逆向工程技术着重于对象的类的定义。这是通过意图组合相关程序变量的对程序代码的检查来完成的。在很多情况下，在代码中的数据组织标识了抽象数据类型，例如，记录结构、文件、列表和其他数据结构经常提供类的最初指示。,(1)内部数据结构,Breuer 和Lano建议了逆向工程类的下列方法：标识程序中记录关于全局数据结构(如，文件或数据库)的重要信息的标记和局部数据结构。定义在标记和局部数据结构与全局数据结构间的关系。例如，在文件空时某标记可能被设置，或某局部数据结构可能作为一个缓冲区，它包含从某中心数据库获取的最后100 个记录。对每个表示一个数组或文件的变量(在程序中)，列出所有与其有逻辑联系的其他变量。这些步骤使得软件工程师能够在和全局数据结构交互的程序中标识类。,(2)数据库结构,不管其逻辑组织和物理结构，一个数据库允许数据对象的定义并支持在对象间建立关系的方法。因此，将一个数据库模式再工程到另一个模式需要对现存对象和它们的关系的理解。可运用下面步骤将现存数据模型定义为再工程一个新的数据库模型的先驱：,（1）通过复审在平坦文件数据库中的记录或在关系模式中的表建立一个初始的对象模型。可以获得被定义为模型的一部分的类。包含在记录或表中的项成为类的属性。,（2）确定候选键。检查属性，确定它们是否被用于指向另一个记录或表，那些作为指针的属性成为候选键。（3）精化实验性的类。确定是否相似的类可被组合到某单个类中。（4）定义一般化。检查具有很多相似属性的类，确定是否应该构造一个，将一般化类放在其头部的类层次。（5）发现关联。建立类间的关联。,一旦知道了定义在上面步骤中的信息，则可以应用一系列变换将旧的数据库结构映射为新的数据库结构。,3用户界面的逆向工程,随着高级的GUI 对每种类型的基于计算机的产品和系统成为必须的，用户界面的重新开发已经成为最常见的再工程活动类型之一。但是，在用户界面可以被重建之前，应该进行一个逆向工程活动。为了我们能完全地理解某现存的用户界面(UI)，必须刻划界面的结构和行为。Merlo 及其同事提出了三个基本问题，它们必须在UI 的逆向工程开始前被回答：,什么是界面必须处理的基本动作例如，击键和按鼠标？什么是系统对这些动作的行为反应的简洁描述？“替代者”意味着什么？或更精确地说，什么界面的等价概念是相关的？,行为建模符号可以提供一种表示上面提出的头两个问题的答案的工具，对创建行为模型必需的多数信息可以通过观察现存界面的外部表现而得到，但是，对创建行为模型必需的附加信息必须从代码中抽取。,在描述发生在界面中的进程时，一个关键的不寻常点是某些对象必须准备对用户输入做出反应，这些输入不能被控制，只能被拒绝。这样，人们必须抓住这个概念，至少有两种并发的活动实体：系统和用户。第二，人们必须能够表达一定的“外部”选择，这些选择不在用户的控制之下。对界面的描述使用代理和动作。一个代理是完成系统某方面功能的某种东西，动作允许代理间相互通信。,7.2.3 重构,重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。通常，重构并不修改整体的程序体系结构，它趋向于关注个体模块的设计细节以及定义在模块中的局部数据结构。如果重构扩展到模块边界之外并涉及软件体系结构，则重构变成了正向工程重构的三次法则：事不过三，三则重构。意思是说，一件事情，第一次只管去做，第二次做类似的事情会产生反感，但无论如何还是做了，第三次再做类似的事情，就应该重构。所以，应该在添加新功能时进行重构.，在修改缺陷时进行重构以及在代码复审时进行重构。,代码重构,代码重构指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。重构既不修正错误，又不增加新的功能性。反而它是用于提高代码的可读性或者改变代码内部结构与设计，并且移除死代码，使其在将来更容易被维护。重构代码可以是结构层面抑或是语意层面，不同的重构手段施行时，可能是结构的调整或是语意的转换，但前提是不影响代码在转换前后的行为。特别是，在现有的程序的结构下，给一个程序增加一个新的行为可能会非常困难，因此开发人员可能先重构这部分代码，使加入新的行为变得容易。,数据重构,为取得正确的数据模式和作出正确的预测在数据挖掘过程中必须将经过处理的数据恢复原来的分布特征称为数据重构。在开始数据重构前，必须先进行分析源代码的逆向工程活动。评估所有包含数据定义、文件描述、I/O、以及接口描述的程序设计语言语句，目的是抽取数据项和对象，获取关于数据流的信息，以及理解现存的已实现的数据结构。该活动有时被称为数据分析。,一旦数据分析已完成，则开始数据重设计。作为其最简单的形式，数据记录标准化澄清数据定义以达到在现存数据结构或文件格式中的数据项名或物理记录格式间的一致性。另一种重设计形式称为数据名合理化，保证所有数据命名约定遵从局部标准并且当数据在程序中流动时别名被删除。当重构超出标准化和合理化的范畴时，对现存数据结构进行物理修改以使得数据设计更为有效。这可能意味着从一种文件格式到另一种文件格式的转换，或在某些情况下，从一种类型的数据库到另一种类型数据库的转换。,7.3 项目管理,7.3.1 项目管理的概念,项目管理起源于美国，20世纪4050年代主要应用于国防和军工项目，后来被广泛应用于工商、金融、信息等产业以及行政管理领域。目前，项目管理已经成为综合多门学科的新兴研究领域，其理论来自于项目管理的工作实践。所谓项目管理就是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内完成项目的各项工作。项目管理是企业的核心竞争力所在。由于项目管理具有效率高、反应灵敏的优点，所以更多的企业希望采取项目式管理的方式，从而可以对用户反应更及时，管理更高效，提高企业的管理质量。,1项目管理定义,项目管理是指一定的主题，为了实现其目标，利用各种有效的手段，对执行中的项目周期的各阶段工作进行计划、组织、协调、指挥、控制，以取得良好经济效益的各项活动的综合。通过项目各方干系人的合作，把各种资源应用于项目，以实现项目的目标，使得项目干系人的需求得到不同程度的满足。要想满足或超过项目干系人的需求和期望，就必须在以下这些相互冲突的要求中寻求平衡：,范围、时间、成本和质量；有不同需求和期望的项目干系人；明确表示出来的要求和未明确表达的要求。,项目管理有时被描述为对连续性操作进行管理的组织方法。这种方法，更准确地应该被称为“由项目实施的管理”，它是将连续性操作的许多方面作为项目来对待的，以便对其可以采用项目管理的方法。项目管理是要求在项目活动中运动知识、技能、工具和技术，以便达到项目目标的活动。它是伴随着项目的进行而进行的，目的是为了确保项目能够达到期望的结果的一系列管理行为。,2软件项目管理,软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。项目管理是项目能否高效、顺利进行的一项基础性的工作。,软件项目管理和其他项目管理相比有相当的特殊性：,（1）软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。,（2）项目周期长，复杂度高，变数多。,（3）软件需要满足一群人的期望。,软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期都能在管理者的控制之下，以预定成本按期、按质的完成软件并交付用户使用,7.3.2 项目管理的对象,项目管理的五个要素有技术(Technical)、方法(Methodology)、团队建设(Team Building)、信息(Information)和沟通(Communication)。其中沟通非常重要，项目经理的主要工作是沟通。沟通包括技术的沟通、管理的沟通、质量的沟通等很多方面。,有效的项目管理集中于三个P 上：人员(people)、问题(problem)和过程(process)。其顺序不是任意的。任何管理者如果忘记了软件工程是人的智力密集的劳动，他就永远不可能在项目管理上得到成功；任何管理者如果在项目开发早期没有支持有效的用户通信，他有可能为错误的问题建造一个不错的解决方案。最后，对过程不在意的管理者可能存在把有效的技术方法和工具插入到真空中的风险,1人员 培养有创造力的、技术水平高的软件人员是从60 年代起就开始讨论的话题。事实上，“人因素”非常重要，以至于软件工程研究所专门开发了一个人员管理能力成熟度模型(PMCMM)，旨在“通过吸引、培养、鼓励和留住改善其软件开发能力所需的人才增强软件组织承担日益复杂的应用程序开发的能力，”。人员管理成熟度模型为软件人员定义了以下的关键实践区域：招募，选择，业绩管理，培训，报酬，专业发展，组织和工作计划，以及团队精神/企业文化培养。在人员管理上达到较高成熟度的组织，更有可能实现有效的软件工程开发。,2问题 在进行项目计划之前，应该首先明确该项目的目的和范围，考虑可选的解决方案，定义技术和管理的约束。没有这些信息，就不可能进行合理的(准确的)成本估算；有效的风险评估；适当的项目任务划分；或是给出了意义明确的项目进度的标志的项目管理计划。软件开发者和用户必须一起定义项目的目的和范围。在很多情况下，这项活动是作为系统工程的一部分开始的，持续到作为软件需求分析的第一步。目的说明该项目的总体目标，而不考虑这些目标如何实现。范围说明给出与问题相关的主要数据、功能和行为，更为重要的是，它以量化的方式约束了这些特性。,一旦了解了项目的目的和范围，就要开始考虑可选的解决方案了。虽然这一步并不讨论细节，但它使得管理者和开发者可以选择一条“最好的”途径，并根据产品交付的期限、预算的限制、可用的人员、技术接口及各种其他因素，给出项目的约束。,3过程 软件过程提供了一个框架，在该框架下可以建立一个软件开发的综合计划。若干框架活动适用于所有软件项目，而不在乎其规模和复杂性。若干不同的任务集合每一个集合都由任务、里程碑、交付物以及质量保证点组成使得框架活动适应于不同软件项目的特征和项目组的需求。最后是保护性活动如软件质量保证，软件配置管理，和测度它们贯穿于整个过程模型之中。保护性活动独立于任何一个框架活动，且贯穿于整个过程之中。,7.4 项目度量,7.4.1 软件度量,1软件度量的概念 软件度量是针对软件开发项目、过程及产品进行数据定义、收集以及分析的持续性定量化的过程。软件度量实际上包括度量和分析两大部分，其中度量是基于一定的目的，采用一定的办法或者标准，对目标事物进行观察，得到客观的评价结果，以量化管理定义项目过程，完成项目已建立的质量和过程性能目标；分析是采用一系列数学函数，对数据进行处理，发现问题并确定过程的发展趋势。,软件度量的目的一般在于：（1）理解，作为研究或开发的部分，通过搜集到的软件过程及项目数据可以了解过程和状态。（2）评价，评定软件工作产品或开发活动是否符合规定的准则及条件。（3）控制，根据度量获得的数据控制软件开发过程中关键活动。（4）预测，度量数据是有效估计的基础，可以在软件开发效率或者趋势方面进行推理并提示采取措施。（5）改进，根据度量信息，确定改进的机会。,软件度量活动一般是在项目级开始，逐步向上扩展为过程度量和产品度量，在处理组织级或者本组织信息需要方面，提供足够的度量能力；向下扩展为个体行为度量，目的是了解个体开发过程中行为的详细原因，并实施行动进行改进。,其中，产品度量是描述诸如大小、复杂性、设计特征、性能和质量等级的产品特征的度量；过程度量是可用于改善软件开发和维护过程的度量，用于建立组织基线，确定改进活动，例子包括开发过程中缺陷排除的有效性、维护过程的响应时间等。,项目度量是了解项目实时质量情况，获得项目特征和执行情况，例子包括开发人员的数目、软件生命周期上的人员成本、进度和生产率等；个体行为度量可以了解个体的开发优势和不足，了解个体缺陷产生的详细原因，确定如何去提高质量并实施行动进行改进，例子包括引入缺陷最多的阶段、引入缺陷的累积百分比、编码阶段常犯错误、缺陷排除有效方法等。,软件度量应遵循的方针：（1）根据信息需要和目标建立测量目标并予以维护；（2）软件度量方法只是达到目的的手段，而其本身并不是目的；（3）以应用度量结果为中心，而不是单纯为收集数据而搜集数据；（4）规定度量元，以处理度量目标，但是要注意度量数据本身肯定存在着瑕疵、不精确也不稳定；（5）说明如何获得并存储度量数据，让软件开发者参与软件度量活动；,（6）规定如何对度量数据进行分析和报告，并且安排优先顺序，同时从小处着手，以局部为重点，逐步深入；（7）提供度量结果，以便处理信息需要和目标。包括：获得指定的度量数据；分析并解释度量数据；管理并存储度量数据、度量规范和分析结果；向所有有关的利益相关者报告度量和分析活动的结果。（8）将特定情景中的过程行为相关知识存储到经验数据库中。,2度量元,度量元简单地描述为软件度量的内容，再确切地可以定义为一个软件企业要对它的产品、项目或者过程进行量化管理时，需要关注的信息对象基本属性的描述。度量元根据度量数据的获得方式划分为基本度量元（直接度量元）和派生度量元（间接度量元）两种。基本度量元的数据可直接度量获得，派生度量元的数据来自其他数据，通常由两个或多个基本度量组合而来。,软件工程权威Barry Boehm概括了软件开发活动中最主要的10个软件度量元，准确地描述了使用传统的软件过程产生的某些基本的经济学关系。简单描述如下：,（1）在交付之后找到并修复一个软件问题的成本，是在设计早期找到并修复该问题的成本的100倍，这是过程改进的理论基础。（2）软件开发进度至多能够压缩25%，主要是因为缩减进度需要增加人力资源，从而增加管理开销。（3）在开发中，每花费1美元，在维护中就得花费2美元，因此要注意度量改进维护的度量元。,（4）软件的开发成本和维护成本主要是源代码行数的函数。这是因为采用定制软件，缺乏商业构件和缺乏重用的结果。（5）人与人的不同导致了软件生产率的最大差异，雇用优秀人才是传统的至理名言。（6）在总体上，软件和硬件成本之比仍然在继续上升：在1955年是15:85；1985年是85:15。这说明对软件的需求、应用范围及其复杂性几乎没有限制地持续增长。（7）只有15%的软件开发工作是专用于编码的，因此要重视需求管理、设计、测试、计划、项目控制、变更管理和工具开发等。,（8）随着软件系统规模的增大，其成本成倍增长，呈现1:3:9的关系，称之为软件产业的非规模经济现象。（9）走查可以发现60%的逻辑缺陷和风格缺陷，但很难发现诸如资源争夺、性能瓶颈、控制冲突问题。（10）20%的贡献者做出了80%的贡献。,在日常的开发管理过程中，我们建议使用的基本度量元包括如下一些方面内容：,进度性能度量元（里程碑进展、工作包完成情况等）。成本性能度量元（实际与计划的对照，用来衡量成本的不一致情况）。工作量性能度量元（人时数、人月数实际与计划的对照，用来衡量工作量的不一致情况）。需求管理度量元（需求追踪矩阵中增加的、删除的、修改的需求数量，衡量需求易变性）。程序规模度量元（源码行数、页数，实际与计划的对照）。,测试性能度量元（需要执行的测试用例数、已经执行通过的测试用例数）。度量度量元（未解决的问题、解决完成的问题、缺陷数、严重缺陷数、缺陷密度、缺陷来源）。过程性能度量元（完成的任务、行动项数）。计算机资源利用情况度量元（内存占有量、CPU占有量）。管理计划项目过程的性能度量元（对照实际进展做估计、重计划、项目总结数据）。,派生度量元通常表示为比率、复合指标或其他累计度量，有更加量化的可靠性和有意义的解释。可能使用的派生度量元如下：,挣值（Earned Value，EV）。进度性能指标（Schedule Performance Index，SPI）。缺陷密度（Defect Density），发现的缺陷数目与规模的比值。同行评审覆盖率（Peer Review Coverage）。测试或验证覆盖率（Test or Verification Coverage）。,测试或验证覆盖率（Test or Verification Coverage）。可靠性度量（Reliability Measures），如平均故障间隔时间（Mean Time to Failure）等。质量度量（Quality Measures），如严重缺陷数/总缺陷数（Number of Defects by Severity/Total Number of Defects）等。,以上这些度量元中，对过程改进和开发最为关键的基本度量元包括项目的规模、投入的成本、工作量、项目进度，这些控制量的期望值及其阈值。而衡量软件质量的度量元，除这些外，还包括了生命周期不同阶段的缺陷数据及各种分布情况，确保缺陷被准确地记录和跟踪，并客观地依据缺陷状况对软件过程和最终发布进行决策。,3度量模型,度量模型是指关于要度量哪些度量元的需求规格说明。它是通过生命周期、直接度量元或间接度量元3个方面来描述的。（1）在生命周期各个阶段，要用到和要度量哪些度量元？它们与企业的商业目标有什么联系？（2）其中哪些是直接度量？由谁度量？是否可以采用工具来度量？（3）其中哪些是间接度量？如何由直接度量导出？,其中，需要根据度量的目的设计不同的度量元。例如，是为了了解发现产品当前的质量情况；是为了了解组织过程能力；还是只是为了奖惩相关人员的数据参考？不同的目的，需要设定不同的度量元，比如为了衡量产品质量，那么考察每个开发人员的代码量意义就不大。度量模型的构建基础是企业自身项目的实施数据。为了保证数据的真实、有效、及时，企业需要进行合理的度量定义，实施简单易用的数据搜集工作。,7.4.2 质量度量,软件产品质量度量是软件质量度量重要组成之一，其度量的对象是软件产品，测量其软件平均失效时间、缺陷密度、适用性、可靠性等产品的质量属性，用于对软件产品进行评价，并在此基础之上不断优化产品设计、产品制造和产品服务。软件产品质量度量包括软件复杂度、客户满意度的度量。软件产品质量度量，则主要集中在软件缺陷的度量，而且这和软件测试有直接的关系。,质量是反映软件与需求相符程度的指标，而缺陷被认为是软件与需求不一致的某种表现，所以通过对测试过程中所有已发现的缺陷进行评估，可以了解软件的质量状况。也就是说，软件缺陷评估是评估软件质量的重要途径之一，软件缺陷评估指标可以看作是量度软件产品质量的重要指标，而且缺陷分析也可以用来评估当前软件的可靠性或预测软件产品的可靠性变化。软件评估首先是建立基线，为软件产品的质量、软件测试评估设置起点，这个基准线上再设置测试的目标，作为对系统评估是否通过的标准。基准对期望值的管理有很大帮助，目标就是相对基准而存在，也就是定义可接受行为的基准。,虽然有很多软件质量的测量方法，但对软件进行正确性、可维护性、完整性、及可用性的测量为项目组提供了有用的技术指标。Gilb给出了这些属性的定义及测量。,（1)正确性 一个程序必须能够正确操作，否则对于用户就没有价值了。正确性是软件完成所需的功能的程度。关于正确性的最常用的测量是每千行(KLOC)的缺陷数，这里缺陷定义为验证出的与需求不符的地方。,软件缺陷评估的方法相对比较多，从简单的缺陷计数到严格的统计建模，基于缺陷分析的产品质量评估方法有以下几种：,缺陷密度软件缺陷在规模上的分布缺陷率缺陷在时间上的分布 整体缺陷清除率 阶段性缺陷清除率 缺陷趋势、预期缺陷发现率 软件产品性能评估技术 借助工具的其他方法,（2）可维护性 软件维护所占的工作量比任何其他软件工程活动都大。可维护性是指遇到错误时程序能被修改的容易程度；环境发生变化时程序能够适应的容易程度，用户希望改变需求时程序能被增强的容易程度。可维护性无法直接测量；因此，我们必须采用间接测量。一个简单的面向时间的度量是平均修改时间(mean-time-to-change，MTTC)，即分析改变的需求设计合适的修改方案实现修改测试，并将修改后的结果发布给用户所花的时间。一般情况下，可维护的程序与不可维护的程序相比，有较低的MTTC(相对于同类修改而言)。,(3)完整性 在黑客及病毒横行的现在，软件完整性已变得日益重要。这个属性测量系统在安全方面的抗攻击(包括偶然的和蓄意的)能力。攻击可能发生在软件的三个主要成分上：程序、数据及文档。为了测量完整性，必须定义两个附加的属性：威胁和安全性。威胁是某个特定类型的攻击在给定时间内发生的可能性(能够根据经验估算或推断出来)。安全性是某个特定类型的攻击将被击退的可能性(也能够根据经验估算或推断出来)。一个系统的完整性可以定义为：完整性=1威胁(1安全性)这是威胁及安全性针对每种类型的攻击求和。,(4)可用性 在对软件产品的讨论中，“用户友好性”这个词已经是普遍存在的。如果一个程序不是“用户友好的”，那么它是注定会失败的，即使它所完成的功能很有价值。可用性试图量化“用户友好性”，并根据四个特性来测量：(1)学会一个系统所需的体力的和/或智力的投入；(2)在系统的使用上达到中等效率所需的时间；(3)当系统由某个具有中等效率的人使用时，测量到的生产率的净增长（与被该系统替代的老系统相比）；(4)用户对系统的态度的一个主观评估(有时可以通过调查表获得)。,7.4.3 集成度量,在项目级和技术级，软件度量能够提供立即可见的好处。软件设计完成后，大多数开发者都急于知道以下问题的答案：哪些用户需求最有可能发生改变？本系统中哪些模块最易于出错？对于每一个模块需要设计多少测试？当测试开始时，预计会有多少错误(特定类型的)？如果度量已经被收集并被用作一项技术指南，这些问题的答案就能够确定了。,7.5 风险分析,在开发新的软件系统过程中，由于存在许多不确定因素，软件开发失败的风险是客观存在的。因此，风险分析对于软件项目管理是决定性