软件维护整理ppt.ppt

《软件维护整理ppt.ppt》由会员分享，可在线阅读，更多相关《软件维护整理ppt.ppt（101页珍藏版）》请在三一文库上搜索。

1、-软件维护,软件工程第八章,首都师范大学教育技术系 方海光 2006年10月,编程大师曾说过：“哪怕程序只有三行长，总有一天你也不得不对它进行维护。”,在软件开发过程中始终强调软件的可维护性。原因是，一个应用系统由于需求和环境的变化以及自身暴露的问题，在交付用户使用后，对它进行维护是不可避免的，统计和估测结果表明，信息技术中硬件费用一般占35%，软件占65%，而软件后期维护费用有时竟高达软件总费用的80%，所有前期开发费用仅占20%。 许多大型软件公司为维护已有软件耗费大量人力、财力。因此，必须建立一套评估、控制和实施软件维护的机制，这就是本章重点讨论的内容。,内容提要,软件维护的定义 软件维

2、护的类型 结构化维护VS非结构化维护 影响软件维护工作量的因素 软件维护的过程 可维护性 软件维护的管理,软件维护的定义,软件维护是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。 一般来说，要求进行维护的原因大致有以下几种： （1）改正程序中的错误和缺陷。 （2）改进设计以适应新的软、硬件环境。 （3）增加新的应用范围。,软件维护的类型,根据软件维护的不同原因，软件维护可以分成三种类型： 改正性维护 适应性维护 完善性维护 预防性维护,改正性维护,在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的使用环境

3、下就会暴露出来。 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。,适应性维护,在使用过程中， 外部环境（新的硬、软件配置） 数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质） 可能发生变化。 为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。,完善性维护,在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。 这种情况下进行的维护活动叫做完善性维护。,预防性维护,预防性维护即软件再工程，是为了提高

4、软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。 采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试，称为预防性维护。,各种维护类型和维护工作量的比例,其它 维护 4 %,适应性 维 护 18-25%,改正性 维护1721%,完善性维护50%66,维护占 70.8%,改正性维护占全部维护工作量的比率已从上世纪80年代初的20%大幅度下降, 上世纪90年代初一些公司的产品差错率已接近于零!,软件维护的特点,结构化维护和非结构化维护差别巨大 软件维护的代价高昂 维护问题多,软件维护事件流,结构化维护VS非结构化维护,软件的开发过程对软件的维护产生较大的

5、影响。 如果采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档，这样维护会相对容易，被称为结构化的维护。 反之，如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作变得十分困难，被成为非结构化的维护。,结构化维护VS非结构化维护,交付使用,分析设计,制定计划,修改计划,编码,复审通过,文件有吗,苦读代码,找到问题,编码,复审通过,维护要求,n,y,y,y,y,n,n,n,结构化维护,非结构化维护,维护要求,配置,评价设计,计划途径,修改设计,重编程序,评价代码,？,重编程序,复查,复查,交付使用,软件,代码,结构化维护,非结构化维护,非结构化维护,在非结构化维护过程

6、中，开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等，这样做是十分困难的，也容易产生误解。要弄清楚整个系统，势必要花费大量的人力和物力，对源程序修改产生的后果难以估计。在没有文档的情况下，也不可能进行回归测试，很难保证程序的正确性。,结构化维护,在结构化维护的过程中，所开发的软件具有各个阶段的文档，它对于理解和掌握软件的功能、性能、体系结构、数据结构、系统接口和设计约束等有很大的作用。维护时，开发人员从分析需求规格说明开始，明白软件功能和性能上的改变，对设计说明文档进行修改和复查，再根据设计修改进行程序变动，并用测试文档中的测试用例进行回归测试，最

7、后将修改后的软件再次交付使用。这种维护有利于减少工作量和降低成本，大大提高软件的维护效率。,软件维护的代价高昂,有形代价逐年上升： 1970年软件维护费用占总费用的35%40%； 1980年软件维护费用占总费用的40%60%； 1990年软件维护费用占总费用的70%80%。,软件维护的代价高昂,维护费用只不过是软件维护最明显的代价，其他一些还不明显的代价将来可能更为人们关注。其他无形的代价还有： 可用的资源被软件维护所占用。 未能及时满足用户的维护要求时引起用户不满。 维护时改动软件，引入了潜在故障，降低了软件质量。 抽调人员从事维护工作，对新的开发过程造成混乱。 导致生产率的大幅下降。,软件

8、维护的代价高昂,用于维护工作的劳动可以划分成： 生产性活动（如，分析评价、修改设计、编写程序代码等） 非生产性活动（例如，理解程序代码功能、解释数据结构、接口特点、性能限度等）,软件维护的代价高昂,下述表达式给出了维护工作量的一个模型： 其中，M是维护的总工作量，P是生产性工作量，K是经验常数，c是复杂程度，d是维护人员对软件的熟悉程度 上述模型表明，如果软件开发没有运用软件工程方法学，而且原来的开发人员未能够参与到维护工作之中，则维护工作量和费用将指数增加。,软件维护的问题,与软件维护有关的大多数问题都可归因于软件定义和开发方法上的不足。 软件开发时采用急功近利，还是放眼未来的态度，对软件维

9、护影响极大。 一般说来，软件开发若不严格遵循软件开发标准，软件维护就会遇到许多困难。,软件维护的问题,下面列出了和软件维护有关的部分问题： 理解别人的代码通常是非常困难的，而且难度随着软件配置成分的缺失而迅速增加； 需要维护的软件通常往往没有合格的文档，或文档资料显然不足。-认识到文档仅仅是第一步，容易理解且和程序保持一致的文档才是真正具有价值的； 当软件要求维护时，不能指望开发人员给我们仔细说明软件。由于维护持续时间很长，因此当需要解释软件时候，往往开发人员已经不在附近了； ,上述种种问题在现有没有采用软件工程思想开发出来的软件中，都或多或少存在。,影响软件维护工作量的因素,在软件维护中，影

10、响维护工作量的因素主要有以下六种： 系统的大小 系统规模越大，其功能就越复杂，软件维护的工作量也随之增大。 程序设计语言 使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。,影响软件维护工作量的因素,系统年龄 老系统比新系统需要更多的维护工作量 。因为多次的修改可能造成系统结构变得混乱，由于维护人员经常更换，程序变得越来越难于理解，加之系统开发时文档不齐全，或在长期的维护过程中文档在许多地方与程序实现变得不一致，从而使维护变得十分困难。 数据库技术的应用 使用数据库，可以简单而有效地管理和存储用户程序中的数据，还

11、可以减少生成用户报表应用软件的维护工作量。,影响软件维护工作量的因素,先进的软件开发技术 在软件开发过程中，如果采用先进的分析设计技术和程序设计技术，如面向对象技术、复用技术等，可减少大量的维护工作量。 其它一些因素 如应用的类型、数学模型、任务的难度、开关与标记、IF嵌套深度、索引或下标数等，对维护工作量也有影响。,软件维护的过程,软件维护工作在维护申请提出之前就开始了，它包括： 建立维护组织，强制报告和评估的过程； 为每个维护申请确定标准化的事件序列； 制定保存维护活动记录的制度和有关复审及评估的标准。,维护阶段的工作事件流,维护组织,维护决策机构,维护管理员,系统管理员,维护人员,配置管

12、理员,维护申请,每个维护申请通过维护管理员转告给系统管理员，系统管理员一般都是对程序(某一部分)特别熟悉的技术人员，他们对维护申请及可能引起的软件修改进行评估，并向修改控制决策机构(一个或一组管理者)报告，由它最后确定是否采取行动。,在维护活动开始之前就明确维护责任是十分必要的，可以大大地减少维护过程中可能出现的混乱。,维护团队组织,维护报告MRF,应该用标准的格式来表达维护要求。软件维护人员通常提供给用户空白的维护请求表（报告）即软件问题报告，该报告（表）由要求一项维护活动的用户填写。 如遇到什么错误，用户需要详细描述错误出现的现场信息(包括输入数据、列表文件和其他有关信息)； 对适应性维护

13、、完善性维护应该给出一个简短的需求规格说明书。最终由维护管理员和系统管理员评价用户用户提出的维护请求表。,一个维护申请被核准后，维护请求表就成为外部文档，视作规划本次维护任务的依据。,软件维护请求报告,软件修改报告(SCR),依据维护请求表，软件组织内部应该制定出一个软件修改报告，它给出下述信息： 满足维护请求表中提出的要求所需的工作量； 维护要求的性质； 维护要求的优先次序； 与修改有关的背景数据。 在拟定进一步维护计划前，把软件修改报告提交控制决策机构审查批准。,有 无,有 无,软件修改报告(SCR),软件维护的工作流,软件维护工作流,虽然每种维护请求类型着眼点不同，但总的维护方法是相同的

14、。 维护工作最后一步是复审，主要审查修改过的软件配置，以验证软件结构中的所有成分的功能，保证满足维护请求表中的要求。,情况复审,当一项软件维护任务完成之后，进行一次情况复审不无裨益。情况复审主要考虑下列问题: 依照当前状态，在设计、编码和测试的哪些方面还能用其他方法进行? 哪些维护资源可用但未用？ 这次维护活动中主要(或次要)的障碍有哪些? 在维护请求中有预防性维护吗? 情况复审的目的在于促进未来的维护工作,同时也为有效管理软件组织提供重要的反馈信息。,软件维护记录的保存,有效的保存维护记录是极端重要的。 保存维护记录的第一个问题就是那些数据值得保存？ Swanson为我们指出了下述内容：程序

15、标识、源语句数、机器指令数、使用的程序设计语言、软件安装的日期、自安装以来软件运行的次数、自安装以来软件失败的次数、程序变动的层次和标识、因程序变动而增加的源语句数、因程序变动而删除的源语句数、每个改动消耗的人时数、程序改动的日期、软件工程师的名称、维护要求的标识、维护类型、维护开始和完成的时间、用于维护的累计人时数、与完成的维护相关联的纯收益。 应该为每项维护工作都收集上述数据。可以利用这些数据构成一个维护数据库。,软件维护记录,评价维护活动,缺乏有效的数据就无法评价软件维护活动。 如果已经开始保存维护记录，则可以对维护工作做一些定量度量，至少可以从如下7方面进行评价： 每次程序运行平均失败

16、的次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所必需的程序变动数； 维护过程中增加或删除源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护要求表的平均周转时间； 不同维护类型所占的比例；,根据这些统计量可对开发技术、编程语言，以及对维护工作量的预测与资源分配等诸多方面的决策进行评价。,软件可维护性,软件可维护性即软件被理解、改正、调整和改进的难易程度。 可维护性是指导软件工程各个阶段工作的一条基本原则，也是软件工程追求的目标之一。,影响软件可维护性的因素,软件的可维护性受各种因素的影响：设计、编码和测试时漫不经心，软件配置不全，都会给维护带来困难

17、。除了与开发方法有关的因素外，还有下列与开发环境有关的因素: 是否拥有一组训练有素的软件人员; 系统结构是否可理解; 是否使用标准的程序设计语言; 是否使用标准的操作系统; 文档的结构是否标准化; 测试用例是否合适; 是否已有嵌入系统的调试工具; 是否有一台计算机可用于维护。 除此之外，软件开发时的原班人马是否能参加维护也是一个值得考虑的因素。,软件可维护性的度量,软件可维护性与软件质量和可靠性一样是难于量化的概念，然而借助维护活动中可以定量估算的属性，能间接地度量可维护性: 察觉到问题所耗的时间; 收集维护工具所用的时间; 分析问题所需时间; 形成修改说明书所需时间； 纠错(或修改)所用时间

18、; 局部测试所用时间; 整体测试所用时间; 维护复审所用时间; 完全恢复所用时间。,提高软件可维护性的方法,建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档 开发软件时考虑到维护,软件维护的副作用,软件修改是一项很危险的工作,对一个复杂的逻辑过程,那怕做一项微小的改动,都可能引入潜在的错误,虽然设计文档化和细致的回归测试有助于排除错误,但是维护仍然会产生副作用。 软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误,副作用大致可分为三类: 代码副作用 数据副作用 文档副作用,代码的副作用,修改或删

19、除子程序; 修改或删除语句标号; 修改或删除标识符; 为提高执行效率而做的修改; 修改文件的open、close操作; 修改逻辑操作符; 由设计变动引起的代码修改; 修改对边界条件的测试。,数据的副作用,局部和全局常量的再定义; 记录或文件格式的再定义; 增减数据或其他复杂数据结构的体积; 修改全局数据; 重新初始化控制标志和指针; 重新排列I/O表或子程序参数表。,文档的副作用,维护应统一考虑整个软件配置,而不仅仅是源代码。否则,由于在设计文档和用户手册中未能准确反映修改情况而引起文档副作用。 对软件的任何修改都应在相应的技术文档中反映出来,如果设计文档不能与软件当前的状况对应则比没有文档更

20、糟。 对用户来说,若使用说明中未能反映修改后的状况,那么用户在这些问题上必定出错。 一次维护完成之后,再次交付软件之前应仔细复审整个配置,有效地减少文档副作用。 某些维护申请不必修改设计和代码,只需整理用户文档便可达到维护的目的。,软件可维护性,许多软件的维护十分困难，原因在于这些软件的文档不全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出的，而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件具有可维护性。,软件可维护性的定义,软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的

21、容易程度。 可维护性、可使用性、可靠性是衡量软件质量的主要质量特性，也是用户十分关心的几个方面。 软件的可维护性是软件开发阶段各个时期的关键目标。,目前广泛使用的是用如下的七个特性来衡量程序的可维护性。 可理解性 可使用性 可测试性 可移植性 可修改性 效率 可靠性 而且对于不同类型的维护，这七种特性的侧重点也不相同。,在各类维护中的侧重点,这些质量特性通常体现在软件产品的许多方面; 为使每一个质量特性都达到预定的要求，需要在软件开发的各个阶段采取相应的措施加以保证。 这些质量要求要渗透到而各开发阶段的各个步骤当中。因此，软件的可维护性是产品投入运行以前各阶段面向上述各质量特性要求进行开发的最

22、终结果。,可维护性的度量,人们一直期望对软件的可维护性做出定量度量，但要做到这一点并不容易。 常用的度量一个可维护的程序的七种特性的方法。就是 质量检查表 质量测试 质量标准,质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。 评价者针对检查表上的每一个问题，依据自己的定性判断，回答“Yes”或者“No”。 质量测试与质量标准则用于定量分析和评价程序的质量。 由于许多质量特性是相互抵触的，要考虑几种不同的度量标准，相应地去度量不同的质量特性。,1. 可理解性,可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度。 一个可理解的程序应具备以下一些特性：模块化，

23、风格一致性，不使用令人捉摸不定或含糊不清的代码，使用有意义的数据名和过程名，结构化，完整性等。,2. 可靠性,可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。 关于可靠性，度量的标准主要有： 平均失效间隔时间MTTF 平均修复时间MTTR 有效性A = MTBD/(MTBD+MDT),度量可靠性的方法,根据程序错误统计数字，进行可靠性预测。常用方法是利用一些可靠性模型，根据程序测试时发现并排除的错误数预测平均失效间隔时间MTTF。 根据程序复杂性，预测软件可靠性。 用程序复杂性预测可靠性，前提条件是可靠性与复杂性有关。因此可用复杂性预测出错率。程序复杂性度量标准可

24、用于预测哪些模块最可能发生错误，以及可能出现的错误类型。,3. 可测试性,可测试性表明论证程序正确性的容易程度。程序越简单，证明其正确性就越容易。而且设计合用的测试用例，取决于对程序的全面理解。 一个可测试的程序应当是可理解的，可靠的，简单的。 用于可测试性度量的检查项目如下： 程序是否模块化? 结构是否良好?,程序是否可理解? 程序是否可靠? 程序是否能显示任意中间结果? 程序是否能以清楚的方式描述它的输出? 程序是否能及时地按照要求显示所有的输入? 程序是否有跟踪及显示逻辑控制流程的能力? 程序是否能从检查点再启动? 程序是否能显示带说明的错误信息?,4. 可修改性,可修改性表明程序容易修

25、改的程度。 一个可修改的程序应当是可理解的、通用的、灵活的、简单的。 通用性是指程序适用于各种功能变化而无需修改。 灵活性是指能够容易地对程序进行修改。,测试可修改性的一种定量方法是修改练习。其基本思想是通过做几个简单的修改，来评价修改的难度。 设C是程序中各个模块的平均复杂性，n是必须修改的模块数，A 是要修改的模块的平均复杂性。 则修改的难度D由下式计算： D = A / C,5. 可移植性,可移植性表明程序转移到一个新的计算环境的可能性的大小。或者它表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度。 一个可移植的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统的性

26、能。 用于可移植性度量的检查项目如下：,是否是用高级的独立于机器的语言来编写程序? 是否使用广泛使用的标准化的程序设计语言来编写程序? 是否仅使用了这种语言的标准版本和特性? 程序中是否使用了标准的普遍使用的库功能和子程序? 程序中是否极少使用或根本不使用操作系统的功能?,程序在执行之前是否初始化内存? 程序在执行之前是否测定当前的输入输出设备? 程序是否把与机器相关的语句分离了出来，集中放在了一些单独的程序模块中，并有说明文件? 程序是否结构化? 并允许在小一些的计算机上分段(覆盖)运行? 程序中是否避免了依赖于字母数字或特殊字符的内部位表示?,6. 效率,效率表明一个程序能执行预定功能而又

27、不浪费机器资源的程度。 这些机器资源包括内存容量、外存容量、通道容量和执行时间。 用于效率度量的检查项目如下： 程序是否模块化? 结构是否良好? 是否消除了无用的标号与表达式，以充分发挥编译器优化作用?,程序的编译器是否有优化功能? 是否把特殊子程序和错误处理子程序都归入了单独的模块中? 是否以快速的数学运算代替了较慢的数学运算? 是否尽可能地使用了整数运算，而不是实数运算? 是否在表达式中避免了混合数据类型的使用，消除了不必要的类型转换?,程序是否避免了非标准的函数或子程序的调用? 在几条分支结构中，是否最有可能为“真”的分支首先得到测试? 在复杂的逻辑条件中，是否最有可能为“真“的表达式首

28、先得到测试?,7. 可使用性,从用户观点出发，可使用性定义为程序方便、实用、及易于使用的程度。一个可使用的程序应是易于使用的、能允许用户出错和改变，并尽可能不使用户陷入混乱状态的程序。 用于可使用性度量的检查项目如下： 程序是否具有自描述性?,程序是否能始终如一地按照用户的要求运行? 程序是否让用户对数据处理有一个满意的和适当的控制? 程序是否容易学会使用? 程序是否使用数据管理系统来自动地处理事务性工作和管理格式化、地址分配及存储器组织。 程序是否具有容错性? 程序是否灵活?,其它间接定量度量可维护性的方法,问题识别的时间； 因管理活动拖延的时间； 收集维护工具的时间； 分析、诊断问题的时间

29、； 修改规格说明的时间； 具体的改错或修改的时间； 局部测试的时间； 集成或回归测试的时间； 维护的评审时间；,这些数据反映了维护全过程中检错纠错验证的周期，即从检测出软件存在的问题开始至修正它们并经回归测试验证这段时间。 可以粗略地认为，这个周期越短，维护越容易。,提高可维护性的方法,建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档,1 建立明确的软件质量目标和优先级,一个可维护的程序应是可理解的、可靠的、可测试的、可修改的、可移植的、效率高的、可使用的。 要实现这所有的目标，需要付出很大的代价，而且也不一定行得通

30、。 某些质量特性是相互促进的，例如可理解性和可测试性、可理解性和可修改性。,另一些质量特性是相互抵触的，如效率和可移植性、效率和可修改性等。 每一种质量特性的相对重要性应随程序的用途及计算环境的不同而不同。例如，对编译程序来说，可能强调效率；但对管理信息系统来说，则可能强调可使用性和可修改性。 应当对程序的质量特性，在提出目标的同时还必须规定它们的优先级。,2 使用提高软件质量的技术和工具,模块化 如果需要改变某个模块的功能，则只要改变这个模块，对其它模块影响很小； 如果需要增加程序的某些功能，则仅需增加完成这些功能的新的模块或模块层； 程序的测试与重复测试比较容易； 程序错误易于定位和纠正；

31、,结构化程序设计 程序被划分成分层的模块结构； 模块调用控制必须从模块的入口点进入，从其出口点退出。 模块的控制结构仅限于顺序、选择、重复三种，且没有GOTO语句。 每个程序变量只用于唯一的程序目的，而且变量的作用范围应是明确的、有限制的。,使用结构化程序设计技术，提高现有系统的可维护性 采用备用件的方法用一个新的结构良好的模块替换掉整个要修改的模块。 采用自动重建结构和重新格式化的工具(结构更新技术)把非结构化代码转换成良好结构代码 。 改进现有程序的不完善的文档 建立或补充系统说明书、设计文档、模块说明书、以及在源程序中插入必要的注释。,3 进行明确的质量保证审查,质量保证审查对于获得和维

32、持软件的质量，是一个很有用的技术。 审查可以用来检测在开发和维护阶段内发生的质量变化。 一旦检测出问题来，就可以采取措施来纠正，以控制不断增长的软件维护成本，延长软件系统的有效生命期。,保证软件质量的最佳方法是在软件开发的最初阶段把质量要求考虑进去，并在开发过程每一阶段的终点，设置检查点进行检查。 检查的目的是要证实，已开发的软件是否符合标准，是否满足规定的质量需求。在不同的检查点，检查的重点不完全相同。,1. 在检查点进行复审,软件开发期间各个检查点的检查重点,在设计阶段，检查重点是可理解性、可修改性、可测试性。 可理解性检查的重点是程序的复杂性。对每个模块可用McCabe环路来计算模块的复

33、杂性，若大于10，则需重新设计。 可以使用各种质量特性检查表，或用度量标准来检查可维护性。 审查小组可以采用人工测试一类的方式，进行审查。,2. 验收检查,验收检查是一个特殊的检查点的检查，是交付使用前的最后一次检查， 验收检查实际上是验收测试的一部分，只不过它是从维护的角度提出验收的条件和标准。 验收检查必须遵循的最小验收标准。,(1) 需求和规范标准 需求应当以可测试的术语进行书写，排列优先次序和定义； 区分必须的、任选的、将来的需求； 包括对系统运行时的计算机设备的需求；对维护、测试、操作、以及维护人员的需求；对测试工具等的需求。,(2) 设计标准 程序应设计成分层的模块结构。每个模块应

34、完成唯一的功能，并达到高内聚、低耦合； 通过一些知道预期变化的实例，说明设计的可扩充性、可缩减性和可适应性。,(3) 源代码标准 尽可能使用最高级的程序设计语言，且只使用语言的标准版本； 所有的代码都必须具有良好的结构； 所有的代码都必须文档化，在注释中说明它的输入、输出、以及便于测试再测试的一些特点与风格。,(4) 文档标准 文档中应说明 程序的输入输出 使用的方法算法 错误恢复方法 所有参数的范围 缺省条件等。,3. 周期性地维护审查,检查点复查和验收检查，可用来保证新软件系统的可维护性。 对已有的软件系统，则应当进行周期性的维护检查。 软件在运行期间进行修改，会导致软件质量有变坏的危险，

35、破坏程序概念的完整性。 必须定期检查，对软件做周期性的维护审查，以跟踪软件质量的变化。,周期性维护审查实际上是开发阶段检查点复查的继续，并且采用的检查方法、检查内容都是相同的。 维护审查的结果可以同以前的维护审查的结果，以前的验收检查的结果、检查点检查的结果相比较，任何一种改变都表明在软件质量上或其它类型的问题上可能起了变化。 对于改变的原因应当进行分析。,4. 对软件包进行检查,软件包是一种标准化的，可为不同单位、不同用户使用的软件。 一般源代码和程序文档不会提供给用户。 对软件包的维护采取以下方法。 使用单位的维护人员首先要仔细分析、研究卖主提供的用户手册、操作手册、培训教程等，以及卖方提

36、供的验收测试报告等。,在此基础上，深入了解本单位的希望和要求，编制软件包的检验程序。 检查软件包程序所执行的功能是否与用户的要求和条件相一致。 为了建立这个程序，维护人员可以利用卖方提供的验收测试实例，还可以自己重新设计新的测试实例。 根据测试结果，检查和验证软件包的参数或控制结构，以完成软件包的维护。,4 选择可维护的程序设计语言,程序设计语言的选择，对程序的可维护性影响很大。,机器语言 汇编语言 高级语言 查询语言 (FORTRAN、 报表生成语言 COBOL等) 图象语言 应用生成语言,5 改进程序的文档,程序文档是对程序总目标、程序各组成部分之间的关系、程序设计策略、程序实现过程的历史

37、数据等的说明和补充。 即使是一个十分简单的程序，要想有效地、高效率地维护它，也需要编制文档来解释其目的及任务。,对于程序维护人员来说，要想按程序编制人员的意图重新改造程序，并对今后变化的可能性进行估计，缺了文档是不行的。 因此，为了维护程序，人们必须阅读和理解文档。 另外，在软件维护阶段，利用历史文档，可以大大简化维护工作。通过了解原设计思想，可以判断出错之处，指导维护人员选择适当的方法修改代码而不危及系统的完整性。,历史文档有三种： 系统开发日志 错误记载 系统维护日志,软件维护的管理,软件维护不仅仅是技术性的，还需要大量的管理工作予以配合，才能保证维护工作的质量。,软件维护的管理,软件维护

38、的管理流程如下：,维护修改建议,分析修改建议,提交管理 部门审查,进行修改,撤销,进行退化测试,提交管理部门审批,更新主文档,提交使用,修改 不足之处,N,Y,N,N,Y,Y,更新其他文档,软件维护的管理,为了确保维护中所作修改的正确性，消除因不当修改给用户带来不良影响，要求对修改工作持谨慎态度。维护人员应和用户充分讨论，在说明情况、弄清要求的基础上，提出修改意见。,软件维护的管理,由谁来承担软件维护管理工作是维护管理的另一个重要问题。 一般认为应该有开发人员来维护，应为他们对软件最熟悉，维护起来最方便 另一种做法是安排专职维护人员负责维护工作，而非开发人员。这样的好处是开发人员可以集中精力做好开发工作，有利于坚持实施开发标准，有利于保证文档的编制质量。同时专职的维护人员可以深入透彻的分析软件，从而更有力于维护的开展。 还有一种较好的做法，安排软件人员开发任务和维护任务的定期轮换。这样可以使软件人员体会到开发和维护工作的具体要求、开发和维护的关系，有利于软件人员的技术水平和软件系统的质量。,