1、第七讲 GIS工程质量控制与维护,程承旗 北京大学遥感所,一、质量控制,工程质量，是贯穿工程生存期的一个极为重要的问题，GIS工程中，工程质量主要是指系统开发过程中所使用的各种开发技术和验证方法的最终体现。,1 软件质量的定义,有多种关于软件质量的定义。例如，ANSIIEEEStd 7291983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。MJFisher定义软件质量为： “所有描述计算机软件优秀程度的特性的组合”。也就是说，为满足软件的各项精确定义的功能、性能需求，符合文档化的开发标准，需要相应地给出或设计一些质量特性及其组合，作为在软件开发与维护中的重要
2、考虑因素。如果这些质量特性及其组合都能在产品中得到满足，则这个软件产品质量就是高的。,软件质量反映了以下三方面的问题： (1)软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。 (2)在各种标准中定义了一些开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。 (3)往往会有一些隐含的需求没有明确地提出来。例如，软件应具备良好的可维护性。如果软件只满足那些精确定义了的需求而没有满足这些隐含的需求，软件质量也不能保证。 软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。因此，有必要讨论各种质量特性，以及评
3、价质量的准则。,12 软件质量特性,软件质量特性，反映了软件的本质。讨论一个软件的质量，问题最终要归结到定义软件的质量特性。而定义一个软件的质量，就等价于为该软件定义一系列质量特性。 人们通常用软件质量模型来描述影响软件质量的特性。已有多种有关软件质量的模型。它们共同的特点是把软件质量特性定义成分层模型。在这种分层的模型中，最基本的叫做基本质量特性，它可以由一些子质量特性定义和度量。二次特性在必要时又可由它的一些子质量特性定义和度量。下面是几个影响较大的软件质量模型。,(1)McCall质量模型,这是McCall等人于1979年提出的软件质量模型。其软件质量概念基于11个特性之上。 而这11个
4、特性分别面向软件产品的运行、修正、转移。它们与特性的关系如图11所示。 进一步，McCall等给出了一个三层次式模型的框架。如图12所示。McCall等认为，特性是软件质量的反映，软件属性可用做评价准则，定量化地度量软件属性可知软件质量的McCall等人的质量特性定义如下：,正确性 在预定环境下，软件满足设计规格说明及用户预期目标 的程度。它要求软件没有错误。 可靠性 软件按照设计要求，在规定时间和条件下不出故障，持续运行的程度。 效 率 为了完成预定功能，软件系统所需的计算机资源的多少。 完整性 为了某一目的而保护数据，避免它受到偶然的，或有意的破坏、改动或遗失的能力。 可使用性 对于一个软
5、件系统，用户学习、使用软件及为程序准备输入和解释输出所需工作量的大小。 可维护性 为满足用户新的要求，或当环境发生了变化，或运行中发现了新的错误时，对一个已投入运行的软件进行相应诊断和修改所需工作量的大小。 可测试性 测试软件以确保其能够执行预定功能所需工作量的大小。,灵活性 修改或改进一个已投入运行的软件所需工作量的大小。 可移植性 将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需工作量的大小。 复用性 一个软件(或软件的部件)能再次用于其他应用(该应用的功能与此软件或软件部件的所完成的功能有联系)的程度。 互连性 连接一个软件和其他系统所需工作量的大小。如果这个
6、软件要联网，或与其他系统通信，或要把其他系统纳入到自己的控制之下，必须有系统间的接口，使之可以联结。互连性很重要。它又称相互操作性。,对以上各个质量特性直接进行度量是很困难的，在有些情况下甚至是不可能的。因此，McCall定义了一些评价准则，使用它们对反映质量特性的软件属性分级，以此来估计软件质量特性的值。软件属性一般分级范围从o(最低)到10(最高)。各评价准则定义如下:,可跟踪性 在特定的开发和运行环境下，跟踪设计表示或实际程序部件到原始需求的(可追溯)能力。 完备性 软件需求充分实现的程度。 一致性 在整个软件设计与实现的过程中技术与记号的统一程度。 安全性 防止软件受到意外的或蓄意的存
7、取、使用、修改、毁坏，或防止泄密的程度。 容错性 系统出错(机器临时发生故障或数据输入不合理)时，能以某种预定方式，做出适当处理，得以继续执行和恢复系统的能力。它又称健壮性。 准确性 能达到的计算或控制精度。它又称精确性。 简单性 在不复杂、可理解的方式下，定义和实现软件功能的程度。 执行效率 为了实现某个功能，提供使用最少处理时间的程度。 存储效率 为了实现某个功能，提供使用最少存储空间的程度。 存取控制 软件对用户存取权限的控制方式达到的程度。 存取审查 软件对用户存取权限的检查程度。,操作性 操作软件的难易程度。它通常取决于与软件操作有关的操作规程，以及是否提供有用的输入输出方法。 易训
8、练性 软件辅助新的用户使用系统的能力。这取决于是否提供帮助用户熟练掌握软件系统的方法。它又称可培训性或培训性。 简明性 软件易读的程度。这个特性可以帮助人们方便地阅读自己或他人编制的程序和文档。它又称可理解性。 模块独立性 软件系统内部接口达到的高内聚、低耦合的程度。 自描述性 对软件功能进行自身说明的程度。亦称自含文档性。 结构性 软件能达到的结构良好的程度。 文档完备性 软件文档齐全、描述清楚、满足规范或标准的程度。 通用性 软件功能覆盖面宽广的程度。 可扩充性 软件的体系结构、数据设计和过程设计的可扩充的程度。 可修改性 软件容易修改，而不致于产生副作用的程度。 自检性 软件监测自身操作
9、效果和发现自身错误的能力。它又称工具性。,机器独立性 不依赖于某个特定设备及计算机而能工作的程度。它又称硬件独立性。 软件系统独立性 软件不依赖于非标准程序设计语言特征、操作系统特征，或其他环境约束，仅靠自身能实现其功能的程度。它又称软件独立性或自包含性。 通信共享性 使用标准的通信协议、接口和带宽的标准化的程度。 数据共享性 使用标准数据结构和数据类型的程度。 通信性 提供有效的IO方式的程度。,需要特别注意的是，正确性和容错性是相互补充的。正确的程序不一定是可容错的程序。反过来，可容错的程序不一定是完全正确的程序。这就要求一个可靠的软件系统应当在正常的情况下能够正确地工作；而在意外的情况下
10、，也能做出适当的处理，隔离故障，尽快地恢复。这才是一个好的程序。此外，有人在灵活性中加了一个评价准则，叫做“可重配置特性”，它是指软件系统本身各部分的配置能按用户要求实现的容易程度。在简明性中也加了一个评价准则，即“清晰性”，它是指软件的内部结构、内部接口要清晰，人机界面要清晰。 在表11中给出的各个评价准则应取什么值，是由特定产品的性质和它们之间的相互关系来确定的。,(2)ISO的软件质量评价模型,按照ISOTC97SC7WG31985130N382，软件质量度量模型由三层组成，参看图 ISO认为，应对高层和中层建立国际标准，在国际范围内推广软件质量管理(SQM)技术，而低层可由各使用单位视
11、实际情况制定。ISO的三层次模型来自McCall等人的模型。高层、中层和低层分别对应于McCall模型中的特性、度量准则和度量。其中，SQRC由8个元素组成，如图13所示。由于许多人纷纷提出意见，按1991年ISO发布的ISOIEC9126质量特性国际标准，SQRC已降为6个。在这个标准中，三层次中的第一层为称为质量特性，第二层称为质量子特性，第三层称为度量。该标准定义了6个质量特性，即功能性、可靠性、可维护性、效率、可使用性、可移植性；并推荐了21个子特性，如适合性、准确性、互用性、依从性、安全性、成熟性、容错性、可恢复性、可理解性、易学习性、操作性、时间特性、资源特性、可分析性、可变更性、
12、稳定性、可测试性、适应性、可安装性、一致性、可替换性，但不作为标准。,(3)上海软件中心(SSC)的软件质量度量模型,在SSC模型中，采用了与ISOIEC9126相同的6个质量特性，它们分别是功能性(iE确性)、可靠性、易使用性、效率、可维护性和可移植性。同时设置了22个质量子特性，是参照McCall模型定义的。包括精确性(准确性)、健壮性(容错性)、安全性、完备性、一致性、通信有效性(在执行功能时，使用最少通信资源的的程度)、设备有效性(为实现某一功能，提供使用最少设备，包括存储设备和外部设备资源的程度)、执行有效性(执行效率)、操作性、培训性(易训练性)、可追踪性、可见性(自检性)、硬件系
13、统无关性(机器独立性)、软件系统无关性(软件独立性)、可扩充性、产品文档完备性、公用性(提供使用协议、例程、数据结构的接口标准的程度。包括数据共享性和通信共享性)、清晰性(提供不复杂、可理解的方式对程序结构做出清晰明了的描述的程度)、模块性、简单性、自描述性、结构性。它们之间的关系参看表12。,13 软件质量特性之间的竞争,在软件的质量特性与质量特性之间、质量特性与质量子特性之间存在着有利的影响和不利的影响，表13给出了质量特性与质量特性之间的有利影响和不利影响。例如，由于效率的要求，应尽可能采用汇编语言。但是用汇编语言编制出的程序，可靠性、可移植性以及可维护性都很差。若用表示该质量子特性属于
14、某质量特性的组合中；用表示该质量子特性对质量特性有有利影响；用 表示不利影响。则有下面表14所示的关系。在进行软件质量设计时，必须考虑利弊，全面权衡，根据质量需求，适当合理地选择设计 质量特性，并进行评价。,2 软件质量的度量和评价,21 软件质量的度量 软件质量特性度量有两类：预测型和验收型。 预测度量是利用定量的或定性的方法，对软件质量的评价值进行估计，以得到软件质量的比较精确的估算值。它是用在软件开发过程中的。而验收度量则是在软件开发各阶段的检查点，对软件的要求质量进行确认性检查的具体评价值，它可以看成是对预测度量的一种确认，是对开发过程中的预测进行评价。,预测度量有两种。第一种叫做尺度
15、度量，这是一种定量度量。它适用于一些能够直接度量的特性，例如，出错率定义为：错误数KIOC单位时间。一般它作为相对量进行度量。第二种叫做二元度量，这是一种定性度量。它适用于一些只能间接度量的特性，例如，可使用性、灵活性等等。通常，对质量特性制定检查表，通过对照检查项目，确定一种质量特性的有无。例如，在设计和编码阶段的复杂性度量，利用尺度度量方法来做。而对模块复杂性的度量采用McCabe环路度量。基本思想是基于程序的分支、循环、顺序等控制结构来估算模块中的结构上的复杂性，其检查表如图14(a)所示，又例如图14(b)给出了评价设计文档是否完备的检查表，这是二元度量的例子。我们对检查表中每一项都应
16、给以记分，指定信息存在时记“1”，否则记“o”。表中所有各项的分数相加，即得度量结果。用尺度度量时，填“值”这一栏，用二元度量时；填“是否”这一栏。,2.2 软件质量评价,定量地评价软件的质量，目前还不能精确地做到。一般采取由若干(610)位软件专家进行打分来评价。这些软件专家应是富有实际经验的项目带头人。软件质量评价分两步走。,(1)评分 1)肯定为“1”，否定为“0”； 2)分等级A、B、C、，若数量化，最高为“l”，最低为“0”，中间可用分数或小数标志各个等级，进行打分。 评分主要是依据软件实际成果进行的。由于软件使用环境不同，使用目的不同，各人打分会有一定差别。在计算打分的平均值X与标
17、准偏差S时，要考虑各质量指标的权值。 例如，表105给出了在编码阶段完成时，由A、B、C、D、E、F等六位专家做质量评价时所打的分数及计算出来的X、S。由X可知，可靠性功能性可测试性可修改性可移植性效率可使用性。,(2)分析结果 根据评分的结果，对照评价指标，检查某个质量特性是否达到了要求的质量标准。 质量特性的得分低于规定的质量指标有两个可能的原因： 1)该质量特性与其他质量特性冲突，而那些质量特性正好很重要； 2)这个软件部分有质量问题。,对于前一个原因，检查该质量特性是否与其他质量指标高的特性相冲突。若发生冲突，则再权衡它的重要度，决定是否需要修改权值；如果没有发生冲突，或者与它发生冲突
18、的那些质量特性的质量指标都不太高，这时应再检查度量工作表及评分，若分数太低，则说明软件有缺陷，在设计时对某些质量特性注意不够，需要加以改进。,3. 软件质量保证,进入80年代以来，软件质量问题开始提到重要议事日程上。一些在硬件领域成功地实施了全面质量管理的部门开始了对软件实行相应的质量管理尝试，并取得了成功的经验。,31 质量保证的概念,什么是质量保证，它是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。这种观点也适用于软件的质量保证。,软件的质量保证就是向用户及社会提供满意的高质
19、量的产品，也就是满足11节所述的各项质量特性的产品。进一步地，软件的质量保证活动也和一般的质量保证活动一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动。即为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。它包括的主要功能如：,质量方针的制定和展开质量保证方针和质量保证标准的制定质量保证体系的建立和管理明确各阶段的质量保证工作各阶段的质量评审确保设计质量重要质量问题的提出与分析总结实现阶段的质量保证活动整理面向用户的文档、说明书等产品质量鉴定、质量保证系统鉴定质量信息的收集、分析和使用,32 软件质量保证的主要任务,为了提高软件的质量和软件的生产率，软件质量保证的
20、主要任务大致可归结为8点。 (1)用户要求定义：软件质量保证人员必须熟练掌握正确定义用户要求的技术，包括熟练使用和指导他人使用定义软件需求的支持工具。必须十分重视领导全体开发人员收集和积累有关用户业务领域的各种业务的资料和技术技能。,(2)力争不重复劳动：利用已有软件成果是提高软件质量和软件生产率的重要途径。为此，不要只考虑如何开发新软件，而首先应考虑哪些既有软件可以复用，并在开发过程中，随时考虑所生产软件的复用性。,(3)掌握开发新软件的方法：对开发新软件的方法已经过长期的探索和积累，最普遍公认的成功方法就是软件工程学方法。标准化、设计方法论、工具化等都属此列。应当在开发新软件的过程中大力使
21、用和推行软件工程学中所介绍的开发方法和工具。,(4)组织外部力量协作：一个软件自始至终由同一软件开发单位来开发也许是最理想的。但在现实中常常难以做到。因此需要改善对外部协作部门的开发管理。必须明确规定进度管理、质量管理、交接检查、维护体制等各方面的要求，建立跟踪检查的体制。,(5)排除无效劳动：最大的无效劳动是因需求规格说明有误、设计有误而造成的返工。定量记录返工工作量，收集和分析返工劳动花费的数据非常重要。另一种较大的无效劳动是重复劳动，即相似的软件在几个地方同时开发。这多是因软件开发计划不当，或者开发信息不流畅造成的。为此，要建立互相交流、信息往来通畅、具横向交流特征的信息流通网。,(6)
22、发挥每个开发者的能力：软件生产是人的智能生产活动，它依赖于人的能力和开发组织团队的能力。开发者必须有学习各专业业务知识、生产技术和管理技术的能动性。管理者或产品服务者要制定技术培训计划、技术水平标准，以及适用于将来需要的中长期技术培训计划。,(7)提高软件开发的工程能力：要想生产出高质量的软件产品必须有高水平的软件工程能力。即在软件开发环境或软件工具箱的支持下，运用先进的开发技术、工具和管理方法开发软件的能力。,(8)提高计划和管理质量：对于大型软件项目来说，提高工程项目管理能力极其重要。提高管理能力的方法是重视和强化项目开发初期计划阶段的项目计划评价，计划执行过程中及计划完成报告的评价。将评
23、价、评审工作在工程实施之前就列入整个开发工程的工程计划之中。正确地评价开发计划和实施结果，不仅可以提高软件开发项目管理的精确度，还可以积累项目管理经验资料，提高日后进行项目预算的精确度。所以对“计划”的质量管理非常重要。,33 质量保证与检验,(1)检验在质量保证中的作用 软件质量必须在设计和实现过程中加以保证。如果工程能力不够，或者由于各种失误导致产生软件差错，其结果就会产生软件失效。为了确保每个开发过程的质量，防止把软件差错传递到下一个过程，必须进行质量检验。,(2)各个开发阶段中的检验 为了切实做好质量保证，要在软件开发工程的各个阶段实施检验。检验的实施有两种形式：实际运行检验(即白盒测
24、试和黑盒测试)和鉴定。可在各开发阶段中结合起来使用。各开发阶段及阶段中的检验如表16所示。,14 软件质量保证体系,软件的质量保证活动，是涉及各个部门的部门间的活动。例如，如果在用户处发现了软件故障，产品服务部门就应听取用户的意见，再由检查部门调查该产品的检验结果，进而还要调查软件实现过程的状况，并根据情况检查设计是否有误，对不当之处加以改进，防止再次发生问题。为了顺利开展以上活动，事先明确部门间的质量保证业务，确立部门间的联合与协作的机构十分重要，这个机构就是质量保证体系。图15和1.6是软件质量保证体系的图例。在质量保证体系图上，用户、领导、各部门横向安排，而纵向则顺序列出软件质量保证活动
25、的各项工作。制定质量体系保证图应注意以下一些问题：,(1)必须明确反馈途径。 (2)必须在体系图的纵向(纵坐标方向)顺序写明开发阶段，在横向(横坐标方向)写明组织机构，明确各部门的职责。 (3)必须确定保证系统运行的方法、工具、有关文档资料，以及系统管理的规程和标准。 (4)必须明确决定是否可向下一阶段进展的评价项目和评价准则。 (5)必须不断地总结系统管理的经验教训，改进系统。 仅靠质量保证体系图很难明确具体工作，因此必须制定质量保证计划，在这个计划中确定质量目标，确定在每个阶段为达到总目标所应达到的要求，对进度做出安排，确定所需的人力、资源和成本等等。质量保证计划的主要条目如下:,在这个质
26、量保证计划中包括的软件质量保证规程和技术准则应当： (1)指示在何时、何处进行文档检查和程序检查； (2)指示应当采集哪些数据，以及如何进行分析处理，例如，在每次评审和测试中发现的错误如何修正； (3)描述希望得到的质量度量； (4)规定在项目的哪个阶段进行评审及如何评审； (5)规定在项目的哪个阶段应当产生哪些报告和计划； (6)规定产品各方面测试应达到的水平。,15 质量保证的实施,软件质量保证的实施需要从纵向和横向两个方面展开。一方面要求所有与软件生存期有关的人员都要参加，另一方面要求对产品形成的全过程进行质量管理，这要求整个软件部门齐心协力，不断完善软件的开发环境。此外还需要与用户共同
27、合作。,51 质量目标与度量,为了开发高质量的软件，从计划阶段开始，不但需要明确软件的功能，还要明确软件应达到什么样的质量标准，即制定软件的质量目标。为了达到这些目标，在开发过程的各个阶段进行检查和评价。在做质量评价时，需要有对质量进行度量的准则和方法，但更重要的是，需要有在软件生存期中如何使用这些准则和方法的质量保证步骤及提高该项作业生产率的工具。,52 质量度量方法,软件的质量评价标准分为三级：质量需求评价准则、质量设计评价准则、质量度量准则。参看11节ISO质量模型。质量需求准则的着眼点是“是否满足用户的要求”，质量设计准则的着眼点是“开发者在设计实现时是否按软件需求保证了质量”，而质量
28、度量准则是为定量度量质量而规定的一些检查项目。它们一级比一级具体，一级比一级易于定量评价。每一级质量准则可因用户、开发者、评价者和评价观点的不同而不同。,软件质量度量的方法有三种：精密度量、全面度量和简易度量。它们应针对质量目标中给出的评价准则的重要度分别采用。精密度量是使用质量度量评价准则进行详细度量，工作量较大但度量精度也高。全面度量比较简单，可以与简易度量并用对各个质量设计评价准则进行度量。度量工作量可以控制在一定范围之内。质量准则与度量方法的关系如图17所示。,图18给出软件质量度量和保证系统在质量保证活动中的五个实施步骤： (1)Target：以用户要求和开发方针为依据，对质量需求准
29、则、质量设计准则的各质量特性设定质量目标。对各准则的重要程度可以设“特别重要”、“重要”、“一般”三级。 (2)Plan：设定适合于待开发软件的评测检查项目(质量评价准则)，质量度量表参看l2节。考虑到评价工作量，检查项目数一般设定20一30个。同时还要研讨实现质量目标的方法。 (3)Do：在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。在接受质量检查之前要先做自我检查。 (4)Check：以Plan阶段设定的质量评价准则进行评价。算出得分，用质量图的形式表示出来，参看图19。比较评价结果的质量得分和质量目标，看其是否合格。 (5)Action：对评价发现的问题进行改进活动，如
30、果实现并达到了质量目标就转入下一个开发阶段。这样重复“Plan“到“Action“的过程，直到整个开发项目完成。,53 软件质量管理小组,软件质量管理小组(SQWC)，是一种软件开发组织形式。它可以是主程序员领导下的结构化小组，也可以是民主制的开发组。在软件工程过程中提倡它是基于以下几个原因：,(1)最适合提高个人能力和小组力量。美国TRW公司的BWBoehm在IEEE的电子计算机刊物上发表了有关软件生产率影响因素分析的研究成果，参看图110。他的结论是，个人和小组的能力对软件生产率的影响最大。好与不好的小组，差别是乙18倍。当然这个数字有其局限性，但无论如何，软件的生产率确实会因个人能力和小
31、组能力而产生4倍的差异。有时还会有更大的差别，高达2030倍。软件的质量管理小组的活动，是解决这个最大问题的极好方法。计算机语言掌握得怎样，对生产率的影响充其量不过12倍。无论使用多么好的软件工具，生产率的提高范围也只能在50左右。但个人能力和小组活动对软件的生产率影响极大。因此，要提高软件的生产率，最有效的方法是开展利用小组进行自身启发的软件质量管理活动。,(2)能够在工程上比硬件更好地提高质量。硬件的质量保证活动，主要在制造工程中进行，把“是否准确地按照设计图纸，没有误差地进行制造”的制造质量视为关键。软件质量保证的对象几乎全部是设计质量，所以，通过开展以设计工程的技术人员为中心的质量管理
32、活动，能够从根本上保证质量。,(3)关系到提高积极性。软件开发活动的实践表明，靠一个人很难完成的工作，若成立小组来做，则轻而易举就能解决问题。生产软件的是人，人有无工作热情和干劲，其结果是很明显的。一个好的软件管理人员，应能给小组带来活力，提高士气。,二、 软件维护,在软件开发完成交付用户使用后，就进入软件运行维护阶段。此后的工作就是要保证软件在一个相当长的时期能够正常运行，这样对软件的维护就成为必不少的了。,21 软件维护的概念,211 软件维护的定义 人们称在软件运行维护阶段对软件产品所进行的修改就是维护。要求进行维护的原因多种多样，归结起来有三种类型： (1)改正在特定的使用条件下暴露出
33、来的一些潜在程序错误或设计缺陷； (2)因在软件使用过程中数据环境发生变化(例如一个事务处理代码发生改变)或处理环境发生变化(例如安装了新的硬件或操作系统)，需要修改软件以适应这种变化。 (3)用户和数据处理人员在使用时常提出改进现有功能，增加新的功能，以及改善总体性能的要求，为满足这些要求，就需要修改软件把这些要求纳入到软件之中。,(1)改正性维护(Correctivemaintenance),在软件交付使用后，由于开发时测试的不彻底、不完全，必然会有一部分隐藏的错误被带到运行阶段来。这些隐藏下来的错误在某些特定的使用环境下就会暴露。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的
34、误使用，应当进行的诊断和改正错误的过程，就叫做改正性维护。例如，改正性维护可以是改正原来程序中未使开关(off/on)复原的错误；解决开发时未能测试各种可能情况带来的问题；解决原来程序中遗漏处理文件中最后一个记录的问题等。,(2)适应性维护(Adaptivemaintenance),随着计算机的飞速发展，外部环境(新的硬、软件配置)或数据环境(数据库、数据格式、数据输入输出方式、数据存储介质)可能发生变化，为了使软件适应这种变化，而去修改软件的过程就叫做适应性维护。例如，适应性维护可以是为现有的某个应用问题实现一个数据库；对某个指定的事务编码进行修改，增加字符个数；调整两个程序，使它们可以使用
35、相同的记录结构；修改程序，使其适用于另外一种终端。,(3)完善性维护(Perfectivemaintenance),在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动。叫做完善性维护。例如，完善性维护可能是修改一个计算工资的程序，使其增加新的扣除项目；缩短系统的应答时间，使其达到特定的要求；把现有程序的终端对话方式加以改造，使其具有方便用户使用的界面；改进图形输出；增加联机求助(HELP) 功能；为软件的运行增加监控设施。,(4)预防性维护(Preventi
36、ve maintenance),除了以上三类维护之外，还有一类维护活动，叫做预防性维护。这是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护定义为：“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编制和测试。,212 影响维护工作量的因素,在软件的维护过程中，需要花费大量的工作量，从而直接影响了软件维护的成本。因此，应当考虑有哪些因素影响软件维护的工作量，相应应该采取什么维护策略，才能有效地维护软件并控制维护的成本。在软件维护中，影响维护工作量的程序特性有以下6种。,(1)
37、系统大小 (2)程序设计语言 (3)系统年龄 (4)GIS平台和数据库技术的应用 (5)先进的软件开发技术 (6)其他：例如，应用的类型、数学模型、任务的难度、开关与标记、IF嵌套深度、索引或下，标数等，对维护工作量都有影响。,21. 3 软件维护的策略,根据影响软件维护工作量的各种因素，针对三种典型的维护，James Martin等提出了些策略，以控制维护成本。,(1)改正性维护,通常要生成100可靠的软件并不一定合算，成本太高。但通过使用新技术，可大大提高可靠性，并减少进行改正性维护的需要。这些技术包括：数据库管理系统、软件开发环境、程序自动生成系统、较高级(第四代)的语言，应用以上4种方
38、法可产生更加可靠的代码。此外， 1)利用应用软件包，可开发出比由用户完全自己开发的系统可靠性更高的软件。 2)结构化技术，用它开发的软件易于理解和测试。 3)防错性程序设计。把自检能力引入程序，通过非正常状态的检查，提供审查跟踪。 4)通过周期性维护审查。在形成维护问题之前就可确定质量缺陷。,(2)适应性维护,这一类的维护不可避免，但可以控制。 1)在配置管理时，把硬件、操作系统和其他相关环境因素的可能变化考虑在内，可以减少某些适应性维护的工作量。 2)把与硬件、操作系统，以及其他外围设备有关的程序归到特定的程序模块中。可把因环境变化而必须修改的程序局部于某些程序模块之中。 3)使用内部程序列
39、表、外部文件，以及处理的例行程序包，可为维护时修改程序提供方便。,214 维护成本,有形的软件维护成本是花费了多少钱，而其他非直接的维护成本有更大的影响。例如，无形的成本可以是： (1)一些看起来是合理的修复，但修改请求不能及时安排，使得客户不满意； (2)变更的结果把一些潜在的错误引入正在维护的软件，使得软件整体质量下降； (3)当必须把软件人员抽调到维护工作中去时，就使得软件开发工作受到干扰。,软件维护的工作有时只有极低的生产率(用LOC人月或功能点人月度量) ，这种情况在做老程序的维护时就会遇到。有报告说，生产率将降到原来的40分之一，例如，为开发每一行源代码要耗资25oo美元，而维护每
40、一行源代码则需要耗资100000美元。,维护工作量的模型：M=P+Kec-d 其中，M是维护中消耗的总工作量，P是上面描述的生产性工作量，K是一个经验常数，c 是因缺乏好的设计和文档而导致复杂性的度量，d是对软件熟悉程度的度量。 这个模型指明，如果使用了不好的软件开发方法(未按软件工程要求做)，原来参加开发的人员或小组不能参加维护，则工作量(及成本)将按指数级增加。,22软件维护活动 软件如何进行维护，应当如何组织维护活动，以便有效地完成软件维护的任务，这是此节要讨论的问题。 为了有效地进行软件维护，应事先就开始做组织工作。首先需要建立维护的机构，申明提出维护申请报告的过程及评价的过程；为每一
41、个维护申请规定标准的处理步骤；还必须建立维护活动的登记制度以及规定评价和评审的标准。,221 维护机构,除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。维护往往是在没有计划的情况下进行的。 虽然不要求建立一个正式的维护机构，但是在开发部门，确立一个非正式的维护机构则是非常必要的。例如图23就是一个维护机构的组织方案。,222 软件维护申请报告,所有软件维护申请应按规定的方式提出。软件维护组织通常提供维护申请报告(MRP，MaintenanceRequestForm)，或称软件问题报告，由申请维护的用户填写。 如果遇到一个错误，用户必须完整地说明产生错误的情况，包括
42、输入数据、错误清单以及其他有关材料。如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。维护申请报告将由维护管理员和系统监督员来研究处理。 维护申请报告是由软件组织外部提交的文档，它是计划维护工作的基础。软件组织内部应相应地做出软件修改报告(SCR，SoftwareChangeReport)，指明：,(1)所需修改变动的性质；(2)申请修改的优先级；(3)为满足某个维护申请报告，所需的工作量； ，(4)预计修改后的状况。软件修改报告应提交修改负责人，经批准后才能开始进一步安排维护工作。,223 软件维护工作流程,软件维护工作流程如图4所示。,224 维护档案记录
43、,为了估计软件维护的有效程度，确定软件产品的质量，同时确定维护的实际开销，需要在维护的过程中做好维护档案记录。其内容包括程序名称、源程序语句条数、机器代码指令条数、所用的程序设计语言、程序安装的日期、程序安装后的运行次数、与程序安装后运行次数有关的处理故障次数、程序改变的层次及名称、修改程序所增加的源程序语句条数、修改程序所减少的源程序语句条数、每次修改所付出的“人时”数、修改程序的日期、软件维护人员的姓名、维护申请报告的名称、维护类型、维护开始时间和维护结束时间、花费在维护上的累计“人时”数、维护工作的净收益等。对每项维护任务都应该收集上述数据。,2. 25 维护评价,评价维护活动比较困难，
44、因为缺乏可靠的数据。但如果维护的档案记录做得比较好，就可以得出一些维护“性能”方面的度量值。可参考的度量值如：每次程序运行时的平均出错次数；花费在每类维护上的总“人时”数；每个程序、每种语言、每种维护类型的程序平均修改次数；因为维护，增加或删除每个源程序语句所花费的平均“人时”数；用于每种语言的平均“人时”数；维护申请报告的平均处理时间；各类维护申请的百分比。,28 软件配置管理(Software Configuration Management),在软件的变更加剧了项目中软件工程师间的混乱。之所以产生混乱，是因为在进行变更前没有仔细分析，或没有进行变更控制。Babich曾经这样说过：“协调软
45、件开发使得混乱减小的技术叫做配置管理。配置管理是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生产率”。,软件配置管理，简称SCM，是一种“保护伞”活动，它应用于整个软件工程过程。因为变在任何时刻都可能发生，因此SCM活动的目标就是为了(1)标识变更；(2)控制变更；(3）确保变更正确地实现；(4)向其他有关的人报告变更。 软件维护和软件配置管理之间的区别是：维护是一组软件工程活动，它们发生于软件以交付给用户并已投入运行之后；软件配置管理是一组追踪和控制活动，它们开始于软件开发项目始之时，结束于软件被淘汰之时。,281 软件配置管理,软件工程过程的输出有三种信息：1)计算机
46、程序(源程序及目标程序)；2)描述计算机程序的文档(包括技术文档和用户文档)；3)数据结构。,在软件工程过程中产生的所有的信息项(文档、报告、程序、表格、数据)就构成了软件配置。软件配置是软件的具体形态在某一时刻的瞬时影像。这样的具体形态取两种形式：1)不可直接执行的材料：如书写的文档、程序清单、测试数据、测试结果等。2)可直接执行的材料：如目标代码、数据库信息等。它们可由计算机处理，存于某种存储介质上。,随着软件工程过程的进展，软件配置项(Software Configuration Item，SCI)数目快速增加。系统规格说明可繁衍出软件项目实施计划和软件需求规格说明(还有与硬件相关的文档
47、)。 它们又依次繁衍出建立信息层次的其他文档。如果每个SCl只是简单地产生其他SCI，造成的混乱可能微乎其微。然而在变更时会引入其他影响因素，使得情况就变得复杂起来。 SCM是一组管理整个软件生存期中变更的活动，SCM可以视为一种质量保证活动，它应用于整个软件工程过程的所有阶段。,下面将介绍主要的SCM任务。(1)基线(Baseline)基线是软件生存期中各开发阶段末尾的特定点，又称里程碑(Milestone)。由正式的技术评审而得到的SCI协议和软件配置的正式文本才能成为基线。它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检验和肯定阶段成果。例如，明确规定不允
48、许跨越里程碑修改另一阶段的文档。如图11所示，是软件开发各阶段的基线。,一旦一个SCI成为基线，就把它存放到项目数据库(亦称项目信息库或软件仓库)中。当一位软件组织成员想要对基线SCI进行修改时，就把它从项目数据库中复制到该工程师的专用工作空间(privateworkspace)中，如图12所示。图中把一个标号为B的SCI从项目数据库复制到工程师的专用工作空间中。这个活动记录在一个记事文件中。工程师可以在B(B的副本)上完成要求的变更，然后用B来更新B。有些系统中把这个基线SCI锁定，在变更完成、评审和批准之前，不许对它做任何操作。,(2)软件配置项SCI 软件配置管理的对象就是SCI一软件配
49、置项，它们是软件工程过程中产生的信息项。在极 端情况下，可把一个SCI看成是一个大规格说明中的一节或一个大测试用例组中的一个测试 用例。比较通用的情况是把一个文档、一整个测试用例组、一个有名字的程序部件(如PASCAI。过程或Ada包)看成是一个SCI。,以下的SCI是SCM的对象，并可形成基线： 系统规格说明软件项目实施计划软件需求说明、可执行的或“书面”的原型初步的用户手册设计规格说明(数据设计、体系结构设计、模块设计、接口设计、对象描述使用面向对象技术时)源代码清单测试计划和过程、测试用例和测试结果记录操作和安装手册可执行程序(可执行程序模块、连接模块)数据库描述(模式和文件结构、初始内
50、容)正式的用户手册维护文档(软件问题报告、维护请求、工程变更次序)软件工程标准项目开发总结,在实现SCM时，把SCI组织成配置对象，在项目数据库中用一个单一的名字来组织它们。一个配置对象有一个名字和一组属性，并通过某些联系“连接”到其他对象，如图13所示。 图中分别对配置对象“设计规格说明”、“数据模型”、“模块N”、“源代码”和“测试规格说明”进行了定义，每个对象与其他对象的联系用箭头表示。这些箭头指明了一种构造关系。即“数据模型”和“模块N”是“设计规格说明”的一部分。双向箭头则表明一种相互关系。如果对“源代码”对象作了一个变更，软件工程师就可以根据这种相互关系确定，其他哪些对象(和SCl)可能受到影响。,
