软件维护与软件文档编制.ppt

第七章 软件维护与软件文档编制,软件投入运行后，软件的开发工作已经结束，进入软件的维护阶段。软件维护所需的工作量相当大，许多国外的软件开发组织估计，软件维护所占的比例占有软件整个生命周期的60%以上的工作量，随着软件规模和数量的增大，软件维护工作将会束缚开发组织的手脚，使他们没有余力开发新的软件。人们对软件维护工作的认识加深后，软件技术服务已经可以独立承包给独立的技术厂商，由专门的技术服务公司进行软件维护，软件开发公司得以继续开发新的软件产品。,7.1 软件维护的内容,软件维护就是在软件已经交付使用以后，为了改正错误或满足新的需要而修改软件的过程。一般来说，要求进行维护的原因大致有以下几种：（1）改正程序中的错误和缺陷。（2）改进设计以适应新的软、硬件环境。（3）增加新的应用范围。,7.1 软件维护的内容,综合以上几种要求进行维护的原因，我们可以把软件维护有四种基本形式：（1）改正性维护：软件测试不可能找出一个大型软件系统中的所有潜在的软件错误，所以在软件使用期间仍有可能发现错误，诊断和改正这类错误的过程称为改正性维护；（2）适应性维护：由于计算机技术发展迅速，计算机硬件设备的不断更新，计算机操作系统的新版本也会不断出现，计算机外部设备也要经常改进，而软件的使用寿命往往超出当时开发该软件系统时设备环境的寿命，为适应新的变化而要对软件进行的修改，称为适应性维护；,7.1 软件维护的内容,（3）完善性维护：软件投入使用后，用户会提出增加新功能，修改已有的功能以及提出一般的改进要求和建议，为了满足和部分满足这类要求，就要进行完善性维护，这类工作较多，占了维护工作的大部分；（4）预防性维护：为了进一步改进软件的维护性和可靠性，或者为进一步改进提供更好的基础而对软件进行的修改，称之为预防性维护；这类工作相对较少。,7.2 影响软件维护工作的主要因素,软件维护与进行新软件产品的开发是一对矛盾，导致软件维护困难的根源大多来自软件计划和开发工作的缺点：如果软件的文档配置不全，会使得维护工作付出很大的代价，因而浪费了精力，挫伤了人的积极性。如果使用软件工程的方法，软件有一个完整配置，维护任务就从评价设计文档开始，确定这个软件的重要结构特性，性能特性、接口特性。确定软件修改带来的影响，并找出一些处理方法，先修改设计，进行设计复审，再修改源程序代码，并利用以前的测试用例进行回归测试，最后将修改过的软件交付使用。,7.2 影响软件维护工作的主要因素,这种维护方式使维护工作量大大减少，易于维护，而且可以提高软件维护的质量。可维护性是指进行软件修改、变更时的难易程度。决定可维护性的主要软件质量因素有三方面：可理解性、可测试性、可修改性。这些又与可扩充性、一致性、简洁性、清晰性、结构性等因素相关。,7.2 影响软件维护工作的主要因素,影响软件维护工作的主要因素有：（1）软件开发的方法：软件开发方法直接影响软件的易维护性；模块化结构、详细设计等文档、软件维护记录报告等将有助于理解软件的结构、界面的功能和内部的数据与控制逻辑流程、理解当前软件的版本状态；（2）软件开发的条件：软件开发过程所涉及到的软硬件资源特性也对软件的维护产生影响，如程序设计语言的特性、软件开发工具等对于理解软件有着明显的影响；,7.2 影响软件维护工作的主要因素,（3）软件规模的大小：软件规模越大，系统越复杂，维护所需的工作量也越大；（4）软件投入运行后的时间：老系统比新系统需要更多的维护工作量，在长期的维护过程中，也许软件的文档与实际的程序实现已变得不一致，维护工作会遇到更多的困难；（5）其它设计因素、人员交替与外部环境因素：开发时，原来软件的设计对软件维护工作的考虑，软件外部环境的变化，人员的交替和管理工作，都会对软件的维护工作产生影响；,7.3 软件维护的特点,7.3.1 软件工程与软件维护的关系,7.3.2 维护成本,退出,7.3.3 维护的问题,7.3.1 软件工程与软件维护的关系,无形的维护成本：（1）一些看起来是合理的改错或修改的要求不能及时满足，使得用户不满意；（2）维护时产生的改动，可能会带来新的潜伏的故障，从而降低了软件的整体质量；（3）当必须把软件开发人员抽调去进行维护工作时，将在开发过程中造成混乱。,7.3.2 维护成本,用于软件维护的工作量可以分为两部分：一部分用于生产性活动，另一部分用于非生产性活动。下面的表达式是由Belady和Lehman提出的维护工作量的计算模型：,MpKe(c d)M：维护中消耗的总工作量；p：生产性工作量；K：经验常数；c：复杂程度；d：维护人员对软件的熟悉程度。通过这个模型可以看出，如果使用了不好的软件开发方法，参加维护的人员都不是原来开发的人员，那么维护工作量（及成本）将按指数级增加。,（1）理解他人编写的程序一般都有一定的困难性。（2）软件配置的文档严重不足甚至没有，或者没有合格的文档。（3）当需要对软件进行维护时，由于软件人员经常流动，维护阶段持续的时间又很长，所以一般不能指望由原来的开发人员来完成或提供软件的解释。（4）绝大多数软件在设计时没有考虑到将来的修改问题。（5）软件维护可以说是一项毫无吸引力的工作。之所以形成这样一种观念，一方面是因为软件维护工作量大，看不到什么“成果”，更主要的原因是因为维护工作难度大，又经常遭受挫折。,7.3.3 维护的问题,7.4 软件维护过程,7.4.1 维护机构,7.4.2 维护申请报告,退出,7.4.3 维护的工作流程,7.4.4 维护记录,7.4.5 维护评价,7.4.1 维护机构,维护管理员负责接受维护申请，然后把维护申请交给某个系统管理员去评价。系统管理员是一名技术人员，他必须熟悉软件产品的某一部分。系统管理员对维护申请做出评价，然后交与修改负责人确定如何进行修改。,维护申请报告,维护申请报告是由软件组织外部提交的文档，它是计划维护活动的基础。软件组织内部应依此制定相应的软件修改报告，这个报告包括以下内容：（1）为满足某个维护申请要求所需的工作量；（2）所需修改变动的性质；（3）申请修改的优先级；（4）与修改有关的事后数据。软件修改报告应提交修改负责人进行审核批准，以便进行下一步工作。,维护的工作流程,无论是哪一种类型的维护，都要进行以下工作：,（1）修改软件设计；（2）设计复审；（3）对源代码的必要修改；（4）单元测试；（5）集成测试，包括回归测试；（6）验收测试；（7）软件配置复审。在每次软件维护任务完成后，需要进行必要的情况评审。这种评审是对以下问题的一个小结：（1）在当前情况下，设计、编码、测试中的哪些方面能够改进？（2）哪些维护资源是应该有而实际上却没有的？（3）工作中的主要和次要的障碍是什么？（4）要求的维护类型中有预防性维护吗？,维护记录,对于维护记录中的内容，Swanson给出了下述的项目表：（1）程序名称；（2）源程序语句条数；（3）机器代码指令条数；（4）使用的程序设计语言；（5）程序的安装日期；（6）程序安装后的运行次数；（7）与程序安装后运行次数有关的处理故障的次数；,（8）程序修改的层次和名称；,（9）由于程序修改而增加的源程序语句条数；（10）由于程序修改而删除的源程序语句条数；（11）每项修改所付出的“人时”数；（12）程序修改的日期；（13）软件维护人员的姓名；（14）维护申请报告的名称；（15）维护类型；（16）维护开始时间和维护结束时间；（17）用于维护的累计“人时”数；（18）维护工作的净收益。,维护评价,一般来说，可以从以下七个方面来评价维护工作：（1）每次程序运行时的平均出错次数；（2）用于每一类维护活动的总“人时”数；（3）每个程序、每种语言、每种维护类型所做的平均修改数；（4）维护过程中，增加或删除每条源程序语句花费的平均“人时”数；（5）用于每种语言的平均“人时”数；（6）一张维护申请报告的平均处理时间；（7）各类维护类型所占的百分比。,7.5 软件可维护性,7.5.1 软件可维护性的度量,7.5.2 提高软件可维护性的方法,退 出,可以从以下四个方面来度是软件的可维护性：1可理解性 2可测试性 3可修改性 4可移植性,7.5.1 软件可维护性的度量,提高软件可维护性的方法,1建立明确的软件质量标准2利用先进的软件技术和工具3建立明确的质量保证制度4选择可维护的程序设计语言5改进软件的文档,7.6 软件维护的副作用,（1）对子程序的删除或修改；（2）对语句标号的删除或修改；（3）对标识符的删除或修改；（4）为改进程序执行性能所做的修改：（5）改变文件的打开或关闭；（6）对逻辑运算符的修改；（7）把设计的修改翻译成程序代码的修改；（8）对判定的边界条件所做的修改。为确保编码修改没有引入新的错误，应进行严格的回归测试。一般情况下，通过回归测试，可以发现并纠正修改编码所带来的副作用。,1、修改编码的副作用,（1）重新定义局部常量或全程常量；（2）重新定义记录格式或文件格式；（3）改变一个数组或高阶数据结构的大小；（4）修改全程变量；（5）重新初始化控制标记或指针；（6）重新排列输入输出或子程序的自变量。修改数据的副作用可以通过完善的设计文档来加以限制。这种文档描述了数据结构，并且提供了一种把数据元素、记录、文件及其它结构与软件模块联系起来的交叉对照功能。,2、修改数据的副作用,维护应该着眼于整个软件配置，而不只是源程序代码的修改。如果源代码的修改没有反映在设计文档或用户文档中时，就会发生文档的副作用。每当对数据流图、软件结构、模块算法过程和其它有关的特征进行修改时，必须同时对相应的文档资料进行更新。在软件再次交付使用之前，对整个软件配置进行评审将大大减少文档的副作用。实际上，某些维护申请的提出只是由于用户文档不够清楚。这时，只需对文档进行维护即可，并不要求修改软件设计或源程序。,3、修改文档的副作用,7.7 软件版本控制,利用维护工具进行软件维护，可以降低维护费用，提高维护效率。比较典型的是版本控制系统，用于协调软件各种版本和配置的生成。版本控制的主要功能有：存贮、更新、检索模块的各个版本；控制修改权限，对模块采取保护措施，仅允许程序员对指定的模块进行修改；利用版本号、日期和时间等信息，系统自动识别装入的模块，确定正确的代码模块版本；自动记录对每个模块进行修改的程序员的名字，记录修改的内容、时间和原因等。可以实现版本的跟踪、恢复和升级。,7.8 软件工程标准中的文档标准,7.8.1 标准化机构与组织,7.8.2 文档的作用,退 出,7.8.3 文档的分类和标准,7.8.1 标准化机构与组织,随着软件工程学的发展，人们对计算机软件的认识逐步深入。软件工作的范围从单纯的使用程序设计语言编制程序，扩展到整个软件生存期。在软件产品的开发过程中，同时产生了许多技术管理工作和确认验证工作，这些工作常常是跨越软件生存期各个阶段的专门工作，需要软件行业的标准或规范加以约束。软件工程标准的类型是多方面的，包括过程标准（如方法、技术、度量等）、产品标准（如需求、设计、部件、描述、计划、报告等）、专业标准（如术语、表示法、语言等）。,7.8.1 标准化机构与组织,国际标准由国际联合机构制定和公布，供各国参考的标准。如ISO（International Standards Organization）,下设许多技术委员会，其中之一是计算机与信息处理技术委员会，简称ISO/TC97,负责与计算机有关的标准化工作。发布的标准通常冠有ISO字样。如：ISO 8631-86 Information Processing Program Constructs and Conventions for Representation信息处理程序构造及其表示法的约定，该标准已收入中国国家标准。,7.8.1 标准化机构与组织,国家标准由政府或国家级的机构制定或批准，适用于全国范围的标准。如：中国国家标准GB/T 15538-1995 软件工程标准分类法给出了软件工程的严格的分类。其中，GB国家标准，中华人民共和国国家技术监督局是中国的最高标准化机构，它所公布实施的标准简称为“国标”。已批准了多个软件工程标准。GJB中华人民共和国国家军用标准。,7.8.1 标准化机构与组织,ANSI(American National Standards Institute)美国国家标准协会；BS(British Standard)英国国家标准；DIN(Deutsches Institute for Normung)德国标准协会；JIS(Japanese Industrial Standard)日本工业标准；,7.8.1 标准化机构与组织,许多国家和国际化标准组织制定了软件工程标准。在众多的标准中，其中有一部分是针对软件文档的标准。如：FIPS135是美国国家标准局发布的软件文档管理指南（National Bureau of Standards,Guideline for Software Documentation Management,FIPS PUB 135,June 1984）;其中，FIPS(NBS)(Federal Information Processing Standards(National Bureau of Standards)美国商务部国家标准局联邦信息处理标准，它所公布的标准均冠有FIPS字样。,7.8.2 文档的作用,软件文档：（也称文件资料），指的是一些记录的数据和数据的媒体，具有固定的格式，可被人与计算机阅读，它和计算机程序一起共同构成了能完成特定功能的计算机软件。,7.8.2 文档的作用,软件的开发渗透着软件人员的复杂脑力劳动，文档作为软件产品的主要形式集中体现了软件开发人员的劳动成果，现在，没有文档的执行程序是不完整的软件。软件的生产和开发工作，总是伴随着大量的信息要记录和使用，因此文档的编制在软件开发工作中占有相当大的工作量，文档在软件生存期中的地位和作用越来越突出了，主要有以下几方面的作用：,7.8.2 文档的作用,（1）提高软件开发过程的能见度：把开发过程中发生的事件以某种可以阅读的方式记录在文档中，管理人员可把这些记载下来的材料作为检查软件开发进度和开发质量的依据，实现对软件开发工作的管理，文档是软件开发规范的体现和指南；（2）提高开发效率：软件文档的编制，使得开发人员对各个阶段的工作都进行周密的思考、全面衡量，从而减少返工。并可在开发的早期发现错误和不一致性，便于及时加以纠正；,7.8.2 文档的作用,（3）作为开发人员在一定阶段的工作成果和结束标志；（4）记录开发过程中的有关信息，便于协调以后的软件开发、使用和维护；（5）提供对软件的运行、维护和培训的有关信息，便于管理人员、开发人员、操作人员、用户之间的协作、交流和了解，使软件开发活动更有效，起着多种桥梁作用；（6）便于潜在用户了解软件的功能、性能等各项指标，为他们选购符合自己需要的软件提供依据；,7.8.3 文档的分类和标准,按照文档的产生和使用范围，软件文档大致可分为三类：开发文档：作为开发人员前一阶段工作成果的体现和后一阶段工作的依据。包括项目开发计划、可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、（也可包含源程序文档）；管理文档：由软件开发人员制定的、需提交管理人员的一些工作计划或工作报告，使管理人员能够了解软件开发项目安排、进度、资源、使用和成果等。包括项目开发计划、测试计划、开发进度月报、项目开发总结；,7.8.3 文档的分类和标准,（3）用户文档：软件开发人员为用户准备的有关该软件的使用操作和维护的资料，包括用户手册、操作手册、维护修改建议、软件需求说明书等；中国已经陆续制定了20余项有关软件工程的国家标准。这些标准可分为四类：基础标准、开发标准、文档标准、管理标准。国家批准的计算机文档标准有：GB8567-88 计算机软件产品开发文件编制指南；GB9385-88 计算机需求说明编制指南；GB9386-88 计算机软件测试编制指南；,7.9 软件文档编制的内容,国家标准局1988年1月发布了计算机软件开发规范和软件产平品开发文件编制指南，它们基于软件生命期方法，把软件产品从形成概念开始，经过开发、使用、和不断增补修订，直到最后被淘汰的整个过程提交的文档归于以下十三种：（1）可行性研究报告：说明该软件项目的实现在技术上、经济上和社会因素上的可行性，评述如何合理地达到开发目标，可供选择的各种实现方案，说明并论证所选定实施方案的理由；,7.9 软件文档编制的内容,（2）项目开发计划：为软件项目实施方案制定出具体的计划。应包括各部分工作的负责人员、开发的进度、开发的经费概算、所需的硬件和软件资源等。项目开发计划应提供给管理部门，并作为开发阶段评审的基础；（3）软件需求说明书：也称软件规格说明书，对所开发软件的功能、性能、用户界面、运行环境等作出详细的说明。它是用户与开发人员双方对软件需求取得共同理解的基础上达成的协议，也是实施开发工作的基础；,7.9 软件文档编制的内容,（4）数据要求说明书：该说明书应当给出数据逻辑描述和数据采集的各项要求，为生成和维护系统的数据文件作好准备；（5）概要设计说明书：应当说明系统的功能分配、模块划分、系统总体结构、输入输出及接口设计，运行设计，数据结构设计和出错处理设计等，为详细设计奠定基础；（6）详细设计说明书：描述每一个模块是如何实现的，包括实现算法和逻辑流程等；,7.9 软件文档编制的内容,(7)用户手册：详细描述软件的功能、性能和用户界面，使用户了解该软件和使用该软件；(8)操作手册：为操作人员提供该软件各种运行情况的细节和有关知识，特别是操作方法的细节；(9)测试计划：针对软件测试（主要是集成测试和确认测试），需要制定测试计划，计划应该包括测试的内容、进度、条件、参加人员、测试用例的选取原则、测试结果允许的偏差范围等；,7.9 软件文档编制的内容,(10)测试分析报告：测试工作完成后，应当提交测试计划执行情况的说明。对测试结果加以分析，并提出测试的结论性意见；(11)开发进度月报：该月报是软件人员按月向管理部门提交的项目进展情况报告。应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题、解决的办法，及下个月的打算等；,7.9 软件文档编制的内容,(12)项目开发总结报告：软件项目开发完成之后，应当与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力。此外，还需对开发工作作出评价，总结经验和教训；(13)维护修改建议：软件产品投入运行后，可能又有修正、更改等问题，应当对存在的问题、修改的考虑，及修改的影响估计等做详细描述，写成维护修改建议，提交审批。,以上这些文档，在项目开发的各个阶段的工作开展时，随之编制，有的在一个阶段进行，有的则需跨越多个阶段，如图7-1所示。,7.10 文档编制的质量要求,高质量的文档有助于程序员编制程序、有助于管理人员监督和管理软件的开发过程、有助于用户了解软件的工作和运行时正确的操作、有助于维护人员进行有效的修改和扩充。质量差的文档起着相反的作用，难于理解软件的特性，给用户造成不便，而且会削弱对软件的管理，难于确认和评价开发工作的进展，如果引起误操作，甚至造成有害的后果。,7.10 文档编制的质量要求,造成软件文档编写质量不高的原因有：缺乏实践经验，缺乏评价文档质量的标准，不重视文档的编写工作，未能合理安排和按时完成文档的编制，在开发工作接近完成时匆忙赶制文档，应付了事，没有给文档的编写工作以应有的重视。高质量的文档，在编写初稿后，常认真听取意见，经多次修改，反复推敲而成，文档的质量应当体现在以下一些方面：,7.10 文档编制的质量要求,（1）针对性：文档编制前，应分清读者对象，按不同类型、不同层次的读者分别对待，以适应他们的需要；面向用户的文档，不应加有过多的专业术语；（2）精确性：文档的行文应当十分准确，不能出现多义性的描述；同一项目若干文档的内容应该协调一致，没有矛盾；（3）清晰性：文档编写力求简明。如有可能，配以适当图表，增强清晰性；（4）完整性：任何一个文档都应是独立完整的，自成体系的，允许必要的部分重复，避免出现转引其它文档内容的情况；,7.10 文档编制的质量要求,（5）灵活性：各个不同的软件项目，其规模和复杂程度有许多实际差别，不能千篇一律看待。对于较小的比较简单的项目，可做适当调整或合并。例如：将用户手册与操作手册合并成用户操作手册，软件需求说明可包含对数据的要求，从而去掉数据要求说明书，将概要设计说明书与详细设计说明书合并成软件设计说明书等；（6）可追朔性：各开发阶段编制的文档与各阶段完成的工作密切相关，前后两个阶段的文档，具有一定的继承关系。同一项目各开发阶段之间提供的文档必定存在着可追朔的关系，需要时能够追踪。,7.11 文档的管理和维护,在整个软件开发过程，软件生命期内，各种文档作为半成品或最后的成品，会不断的生成、修改或补充。为了最终得到高质量的产品，必须加强对文档的管理。注意以下方面：（1）软件开发小组应设有一位文档保管人员，负责集中保管本项目已有的两套文档的两套主文本，内容一致，其中一套可按一定的手续借阅；（2）软件开发小组可根据需要自己保存一些文档，是主文本的复制品，并注意和主文本保持一致，做必要修改时，应先修改主文本；,7.11 文档的管理和维护,（3）开发人员个人只保存与他工作有关的部分文档；（4）当新文档取代旧文档时，管理人员应及时注销旧文档。及时反映更新的内容。（5）项目开发结束时，文档管理人员应收回开发人员的个人文档。当发现个人文档与主文档有差别时，应立即解决。（6）开发软件时，可能有时需要修改已完成的文档。对于较大规模的项目，修改必须特别谨慎，充分估计可能带来的影响，并应按照提议、评议、审核、批准及实施等步骤进行，加以严格控制。,7.11 文档的管理和维护,在软件开发的不同阶段可以使用不同的工具，如：计划工具（可用一般的文本编辑工具完成），系统需求分析工具（SADT,SREM,PSL/PSA 等），总体设计工具（SADT）编码工具(各种集成开发环境)，测试工具（PET），维护工具(SPD),文档跟踪工具(青鸟环境的DAT/T)等，也可建立数据库，维护系统开发过程的大量信息。,习题七,1软件维护有哪几种基本形式？2影响软件维护工作的主要因素有哪些？3 软件文档的形式有哪几类？具体的各个软件文档与开发各阶段关系如何？,习题七,1软件维护有哪几种基本形式？2影响软件维护工作的主要因素有哪些？3 软件文档的形式有哪几类？具体的各个软件文档与开发各阶段关系如何？,习题七,1软件维护有哪几种基本形式？2影响软件维护工作的主要因素有哪些？3 软件文档的形式有哪几类？具体的各个软件文档与开发各阶段关系如何？,习题七,1软件维护有哪几种基本形式？2影响软件维护工作的主要因素有哪些？3 软件文档的形式有哪几类？具体的各个软件文档与开发各阶段关系如何？,