范文一:软件维护记录表
新疆弘毅信息科技有限公司
维护记录表
部门名称 日期 编号
单位名称 用
户单位地址 邮编 信联系人 联系电话 传真 息 Email
产品/项目编号 产品/项目名称 版本
问题程度 ? 重大 ? 局部功能 ?轻微 问
题
描
述
记录人: 日期:
?用户操作有误 ?用户数据错误 ?系统安装有误 ?硬件故障 ?系统软件故障 分故障 ?软件设计有误 ?软件编码有误 ?软件生产有误 ?用户手册有误 ?服务器系统故障 析?数据库故障 ?原因不明 原
因 非故障 ?数据错误 ?超出设计功能 ?超出设计性能 ?机器配置不足 ?其他
处
理
意
见 负责人: 日期:
解
决
结
果
解决人: 日期:
?软件产品/项目维护 ?硬件产品维修 ?现场的技术服务 ?其他 维护阶段 ?质量保证期 ?维护期内 ?维护期外 操作员签字
客户签字 日期
范文二:软件维护手册
动物园动物管理系统软件维护手册
一:引言
1.1:目的
由于动物园动物管理调度大,软件工作量大,日常维护必不可少,该手册向客户提供系统存在的问题及原因或解决方法。
1.2:项目背景
该项目由中国国家动物园管理层提出,由东北大学秦皇岛分校控制工程学院负责软件的开发和调试。用户群体为全国各动物园,使用于实时统计动物园动物调度,安排。
1.3:定义
二:系统说明
2.1:系统用途
系统具有各种动物数据实时采集,实时控制决策,实时控制输出,对所有动物的信息同一管理。
2.2:安全保密
为使系统安全保密采用最新保密技术,绝对具有专利唯一性。
2.3:总体说明
说明系统的总体功能,对系统、子系统和作业做出综合性的介绍,并用图表的方式给出系统主要部分的内部关系。
四:维护过程
4.1:约定
无
4.2:验证过程
说明一个程序段修改后,对其进行验证的要求和过程(包括测试程序和数据)及程序周期性验证的过程。
4.3 :出错及纠正方法
死机:重启
密码错误:重输
超声工作站中每次打开程序,出现应用程序产生错误,会被Windows关闭,你需要重新启动应用程序。纠正方法:安装了其它版本的OFFICE软件,系统只支持OFFICE2000,需要重新安装系统,安装OFFICE2000软件。
退出主任监控系统将出现“应用程序错误”或连续点击界面上的按钮,来连续采集图片时,有时不能采集到图片(显示为空),并且图片显示的高度也不一致。纠正方法:主任监控对MC4、M24支持不强。
在其它操作系统运行错误。纠正方法:只支持Windows 2000系统。
范文三:软件维护指南
软件维护指南 GB/T 14079—1993 中华人民共和国国家标准 GB/T 14079—1993 软件维护指南 Guideline on software maintenance 国家技术监督局 1993-01-07 批准 1993-08-01 实施1 主题内容与适用范围 本标准描述软件维护的内容和类型、维护过程及维护的控制和改进。 本标准适用于软件生存周期的运行和维护阶段,主要供软件管理人员和维护人员使用。2 引用标准 GB 8567 计算机软件产品开发文件编制指南 GB/T 11457 软件工程术语3 术语 本标准使用 GB/T 11457 中的术语及下列术语:3.1 自底向上法 在层次结构的软件中,一种从最低层成份开始逐级向上扩展,直到最高层成份的开发方法。3.2 自顶向下法 在层次结构的软件中,一种从最高层成份开始逐级向下扩展,直到最低层成份的开发方法。3.3 编译扩展 一种程序设计语言的特征。这种特征超越了该语言的标准特征,但仍可以为一专门的编译程序所接受并加以编译。3.4 同级评审 一种质量保证方法,由两个或多个同级程序员互相检查、评估,以确保被检查内容正确,且与软件的其他部分相一致。3.5 软件维护管理机构 为评审修改带来的影响、制订维护计划、复查修改结果、管理维护工作等而设立的机构。3.6 软件维护主管 组织、管理和协调维护工作的负责人。3.7 维护管理人员 管理一个或几个软件的维护工作的技术人员。3.8 软件维护人员 具体完成软件维护的工作人员。4 软件维护的内容与类型 软件维护是在软件产品交付使用之后,为纠正故障,改善性能和其他属性,或使产品适应改变了的环境所进行的修改活动。 软件维护一般分为完善性维护、适应性维护和改正性维护三种类型。4.1 完善性维护 完善性维护是为扩充功能和改善性能而进行修改和扩充,以满足用户变化了的需求。主要内容包括: a.为扩充或增强功能而作的修改如扩充解题范围和算法优化; b.为提高性能而作的修改如提高精度,节省存储空间等; c.为便于维护而作的修改如增加注释,改进易读性。4.2 适应性维护 适应性维护是为适应软件运行环境的变化而作的修改,变化的主要内容包括: a.影响系统的规定、法律和规则的变化; b.硬件配置的变化,如机型、终端、打印机等的变化; c.数据格式或文卷结构的变化; d.系统软件的变化,如操作系统、编译系统或实用程序的变化。4.3 改正性维护 改正性维护是为维持系统操作运行,对在开发过程产生而在测试和验收时没有发现的错误而进行的改正。所必需改正的错误包括: a.设计错误; b.逻辑错误; c.编码错误; d.文档错误; e.数据错误。5 软件维护过程 软件生存周期中的维护阶段通常起始于软件产品交付给用户、用户验收之时。软件维护活动通常可定义成软件生存周期中前几个阶段的重复。软件维护与软件开发有许多相同的活动, 但也有其独特之处: a.维护活动限定在已有系统的框架之内完成,维护人员必须在已有的设计和编码结构的约束下作出修改,一般系统越旧,软件维护越困难和越费时。 b.通常软件维护阶段的时间比软件开发的时间长得多,但一项具体的软件维护一般比该软件的开发时间短得多。 c.软件开发必须从无到有产生所有测试数据,而软件维护通常可以使用现有的测试数据进行回归测试。有时还要产生新的数据,对软件修改及修改后的影响进行必要的测试。 完成一项软件维护的过程是复杂的。下面按顺序列出完成一项软件维护过程的步骤: a.确定修改类型; b.确定修改的需要; c.提出修改请求; d.需求分析; e.认可或否决修改请求; f.安排任务进度; g.设计; h.设计评审; i.编码修改和排错; j.评审编码修改; k.测试; l.更新文档; m.标准审计; n.用户验收; o.安装后评审修改及其对系统的影响。 其中有几个步骤会经常发生循环,但并不是每次修改都要执行所有的步骤。6 软件维护的控制和改进
软件维护必须有控制地进行,使整个过程中都处于适当的管理和控制之下。除了控制预算、进度和人员,关键在于要由软件维护主管来负责控制和修改系统。 大量的编码在开发过程中并非都考虑到了维护。即使原来是良好设计及良好实现的编码和逻辑,也会因无休止的“快速排错”和修补工作受到破坏。所以一个系统不仅在开发时要考虑到维护,还要在维护时考虑到将来的维护。6.1 软件维护的控制 软件系统的可维护性常常随着时间的推移而降低,这是许多因素综合的结果。如果没有为软件维护管理制定严格的条例,或条例贯彻不力,许多系统都将蜕变到无法继续维护的地步。 软件维护的目标是保持系统功能和及时、满意地响应用户的请求。 软件维护的控制是保持一个有秩序的维护过程,在这个过程中所有的维护请求要正式提出、评审,给予一个优先级并安排进度。6.1.1 确立软件维护的策略 软件维护策略的确定是软件维护控制的一个关键步骤。软件维护策略应充分地描述软件维护组织的责任、权利、职能及操作,它应全面地考虑到软件系统和它的环境的任何类型变化。该策略应由软件维护管理机构制定和支持。 软件维护策略必须具体地阐述修改的需要和理由、修改的责任和步骤。规定控制修改软件的过程和步骤,使请求的修改从提议到完成有控制地进行。 为保证维护策略的贯彻执行,需进行评审和审计。6.1.2 评审和评价所有修改请求 a.所有的修改要求应先提出正规的书面请求; b.评审所有修改请求; c.分析和评价修改请求的类型和频度; d.考虑对修改的需要程度和它可预见的使用,所有修改都需有充足的理由; e.评价修改,以确保与原来的系统设计和用意不冲突,对每个修改都应该仔细考虑其影响; f.应特别强调确定所建议的修改是增强还是降低系统的性能; g.仅当修改的效益超过其成本时方可修改。6.1.3 为维护安排进度 a.给每个修改请求分配一个优先级; b.为每个认可的修改请求安排进度; c.遵守安排的进度。6.1.4 将代码修改限制于批准的工作范围内 软件维护主管必须监督维护人员的工作,确保只在授权的工作范围内作修改。为有效实行监督,必须将所有的维护活动记入文档,包括修改请求报告和完成修改后的源程序清单,并为系统复原做好安排。6.1.5 强制实施文档标准和编码约定 必须贯彻编码约定和文档标准,以对软件维护人员的所有工作进行经常不断的强制性评审和检查。在开始一项新的维护工作之前,应当为更新文档分配足够的时间。6.2 软件维护的改进 可维护性是对软件进行修改的难易程度。一个系统的可维护性必须放在系统的整个生存周期中加以考虑。在系统最初的设计和开发阶段就应考虑到可维护性。 由于维护阶段的处理过程同开发阶段相似,因此许多技术和开发工具也可用在维护阶段。为提高软件可维护性,应在系统的整个生存周期中综合地使用下列技术和原理。6.2.1 编码指南 编码指南和标准提供了一种提高系统可维护性的结构和框架,它使得系统以一种共同的、更易理解的方式进行开发和维护。编码应遵循下列基本原则。6.2.1.1 单一高级语言 尽可能只用一种符合标准的高级语言。6.2.1.2 编码约定 维护人员首先必须克服的困难是编码本身,开发人员和维护人员编写大量源码时很少考虑到以后的维护人员,结果使得源码的可读性很差。源码一定要加注解并用结构化格式编写。下列技术可提高程序的可读性: a.尽量采用较简单的方法; b.代码的每节开始行使用行首空格把一系列代码分成段。行首空格和字间的间隔是显示从属关系的两种方法; c.用有意义的注释来适当地为代码加说明; d.使用有意义的变量名,以表达此数据项是什么以及为何要使用它; e.避免使用相似的变量名; f.在程序的过程/函数之间用参数来传递数据; g.在变量名中使用数字时,应放在末
端。用作程序标签或标号的数字应按顺序给出; h.逻辑上相关的功能应集中安排在同一模块或模块集,尽可能使逻辑流向自顶向下; i.避免使用程序语言版本的非标准特征。6.2.1.3 结构化和模块化 应采用自顶向下的程序设计方法,使程序的静态结构与执行时的动态结构相一致。 模块化是指用一组小的层次结构的单元或例行程序构成程序,其中每个单元或例行程序集完成特定的单一功能。模块性不是仅仅将程序分段,模块的结构必须遵循下列设计原则: a.一个模块应只完成一个主要功能; b.模块间的相互作用应最少; c.一个模块应只有一个入口和一个出口。6.2.1.4 标准数据定义 一定要为系统制定一组数据定义的标准。这些数据定义可汇集于数据字典。字典项定义了系统中使用的每个数据元素名字、属性、用途和内容。这些名字要尽可能具有描述性和意义。正确一致地定义数据标准,就会大大简化阅读和理解各模块,并确保各模块间的正确通信。6.2.1.5 良好注释的代码 好的注释可增强源码的可理解性。除了提高程序可读性,注释还有两个重要用途,即提供程序的用途和历史信息、它的起源作者、生成和修改日期、子程序名和个数以及输入/输出需求和格式,其次也提供操作控制信息、指示和建议来帮助维护人员理解代码中不清楚的部分。6.2.1.6 编译程序扩展 使用编译程序的非标准特征会严重影响系统的可维护性。如果编译程序更改了,或如果系统必须移至新机器,则以前的编译程序扩展很可能与新的编译程序相冲突。因此最好限制语言的扩展和保留语言基本特征的一致。如果需要使用编译程序扩展,应编制良好文档加以说明。6.2.2 文档编写指南 一个系统的文档是良好维护的基础,文档编写工作应贯穿系统的整个生存周期。应有计划地建立和及时地更新文档,使维护人员能很快地找到所需的信息。应参照 GB 8567 编制文档。 文档合格的关键不仅是将必需的信息记录下来,以保持文档的及时更新和一致;而且必须使维护人员能迅速地获得它。对于维护人员来说,具有受控的存取和修改能力的联机文档是文档的最佳形式,如果不能提供联机文档,应保证有一机制使维护人员在任何时候能取用硬拷贝的文档。6.2.3 编码和评审技术 本条列出有助于提高软件可维护性的设计和评审技术。6.2.3.1 自顶向下/自底向上法 应将自顶向下与自底向上的方法组合起来使用。6.2.3.2 同级评审 同级评审是一种质量保证方法。参加评审人员务必明白他们不是要评价其他程序员的能力或表现,而是分析和评价编码。评审内容应包括可维护性。6.2.3.3 审查 审查是一种质量评估技术,在软件生存周期中检查各阶段工作,然后产生一个报告指出发现的错误和提出错误改正要求。6.2.3.4 走查 简单的走查方式是让两个维护人员一起讨论正在进行的工作,复杂的走查方式可以有一份日程表、报告书和一位记录秘书。不论何种方式,目标是通过公开直接的交流,提炼好的主意,修改原来的方案。6.2.4 测试标准和过程 测试是软件维护的关键部分,因此测试过程必须强调一致性,并以合理的原则为基础,测试计划要定义预期的输入,测试有效的、无效的、预期的和出乎意料的情况。测试要检查程序是否执行预期任务,测试的目的是发现错误,而不是证明错误不存在。 只要有可能,测试过程和测试数据均需由其他人完成,而不是由做系统实际维护的人来完成。6.3 软件维护人员的管理 管理是改进软件维护过程的主要因素之一。管理必须指导怎样维护软件,行使对整个过程的控制,并保证使用高效的软件维护技术和工具。 为确保实现成功的维护,在维护过程中要有效使用良好的管理技术和方法,必须建立软件维护组织机构。 软件维护机构由维护主管、维护管理机构、维护管理员和维护人员组成。 软件维护机构的主要任务是审批维护请
求,制订并实施维护策略,控制和管理维护过程,负责软件维护的审查,组织评审和验收,确保软件维护任务的完成。 软件维护人员的素质对于有效地进行维护是十分重要的,因此应为维护项目选择合格的各级人员。 下面列出挑选软件维护人员和进行维护管理的要点: a.维护与开发同等重要,同样具有难度; b.维护人员应是合格的、有责任心的人; c.维护不能当作初级人员“放任自流”式的培训; d.全体人员应轮流分配去做维护和开发工作; e.出色的维护工作应同出色的开发工作一样受到奖励; f.必须强调对维护人员进行良好的培训; g.轮换分配,不应让一个系统或一个系统的主要部分成为某个人的专有领地。7 软件维护与软件重新设计 维护是一种不断进行的过程,但有时也应考虑是否要重新设计一个软件系统。当一个软件已变得易出差错、效率降低和耗费增大,再对其继续维护的成本/效益比可能会超出重新设计一个系统时,应考虑是否要重新设计一个软件系统。下列特征可帮助管理人员决定是否应重建软件。7.1 软件经常出错与性能恶化 代码越久,则经常的更新、新的需求和功能增强就越会引起系统的故障和性能恶化。7.2 程序结构和逻辑流过分复杂 具有部分或全部下列属性的软件通常很难维护,需重新设计: a.过多使用 DO 循环; b.过多使用 IF 语句; c.使用不必要的 GOTO 语句; d.过多使用嵌入的常数和文字; e.使用不必要的全程变量; f.使用自我修改的代码; g.使用多入口或多出口的模块; h.使用相互作用过多的模块; i.使用执行同样或相似功能的模块。7.3 过时的代码 过时的代码严重影响新系统的性能发挥。7.4 在仿真方式下运行 采用仿真方法,常阻止系统发挥全部能力和所有功能。仿真系统往往介于功能上尚可实用, 但效率较低这二者之间。7.5 模块或单个子程序非常大 此时,大模块结构应重新构造,分成较小的、功能上相关的部分,这可增强系统的可维护性。7.6 过多的资源需求 需要过多资源的系统会成为用户的沉重负担,因此需考虑是增加更多的计算机设备还是重新设计和实现该系统。7.7 将易变的参数编在代码中 尽可能对程序进行更新,以使它们能从输入模块或一个数据表中读入参数。7.8 难于拥有维护人员 用低级语言编写的程序,尤其是汇编,需大量的时间和人力去维护。一般这类语言不为人们广泛了解,因此要寻找了解这类语言的维护人员日益困难。7.9 文档严重不全或失真 文档不全、过时或失真,将造成维护工作极其困难。 附加说明: 本标准由中华人民共和国机械电子工业部提出。 本标准由上海计算机软件技术开发中心负责起草。 本标准主要起草人朱三元、刘光龙、王景寅、周庆隆。
范文四:软件维护合同
软件系统维护服务合同
软件系统维护服务合同
(示范文本)
合同编号
委托人: (以下简称“甲方”)
受托人: (以下简称“乙方”)
甲方委托乙方 就 相关软件系统进行专项运行维护服务,双方经过平等协商,在真实、充分地表达各自意愿的基础上,根据《中华人民共和国合同法》的规定,达成如下协议,并由双方共同遵守。
1、合同标的和合同价格:
服务项目 收费金额 备注
应用系统及平台运行维护
合同总金额(大写):人民币 (?: )
2、服务方式:帮助中心支持、现场维护、培训、 等 种方式。
现场服务电话: 。
8小时外应用系统应急服务热线: 。
3、具体服务内容:
第 1 页 共 7 页
软件系统维护服务合同
序
服务内容 分项列表
号
相关业务系统以及辅助软件提供日常
维护。
应用系统及平台运相关运行平台的日常维护 1 行维护 其他临时性维护工作的日常维护
2
4、付款方式与条件:
甲方向乙方支付服务费及支付方式为:
4.1(服务费总额为: ;
4.2(服务费由甲方分期支付乙方。具体支付方式和时间如下:
(1) 年 月 日前,支付合同总金额的 ,,即 万元 ;
(2) 年 月 日前,支付合同总金额的 ,,即 万元;
(3) 年 月 日前,支付 。
5、质量保证:
乙方负责对软件系统进行专项运行维护服务,具体服务实施前,乙方应提交详细的项目工作计划表、项目工作进度表报甲方确认。乙方提供全天候维护服务,在接到甲方维护服务通知后,必须在 小时内派专业技术人员提供咨询、现场维护等服务。乙方要及时填写维护报告(包括维护原因、处理情况及甲方意见等)报甲方备案。服务期内乙方有责任每周不少于一次对软件系统运行作检查维护。
6、知识产权:
在软件系统维护期间,因乙方提供的维护服务导致甲方受到有关侵犯其专利权、商标权或工业设计权等知识产权的指控,由乙方负责
第 2 页 共 7 页
软件系统维护服务合同
与第三方交涉并承担一切法律责任与因此产生的所有费用。甲方因此而遭致损失的,乙方应全额赔偿。
7、违约责任:
7.1除不可抗力因素外,由于乙方自身原因未在工作计划或工作进度规定期限内完成服务,乙方应承担服务费总额 %/日违约金。
7.2由于甲方无正当理由不能按约付款,延期超过 日后,乙方有权要求甲方支付每天 %/日的滞纳金。
8、合同的解除:
因乙方未能按时完成合同要求(不可抗力除外),在甲方发出催办通知书之日起 日内,乙方仍未能完成的,甲方有权解除合同,由此产生的一切损失由乙方自行承担。
9、 其他约定
9.1本服务合同未尽事宜的处理,由双方协商,并以补充协议或会议记录经双方签字确认同意后,方能生效。双方在更换全权代表时,须在 在 个工作日内以正式书面形式通知对方。
9.2在执行服务合同过程中发生任何纠纷均需通过双方协商解决。协商不成的,按下述第 种方式解决
(1)提交 仲裁委员会仲裁;
(2)依法向人民法院提起诉讼。
9.3、在仲裁或诉讼期间双方应继续履行服务中不属于纠纷范围的义务。
10、协议生效
第 3 页 共 7 页
软件系统维护服务合同
10.1、本合同由双方代表于 年 月 日签字生效。
10.2本合同用中文制成一式四份,甲方、乙方各执两份,具有同等法律效力。
10.3本合同的所有附件及工作过程中形成的文件、会议纪要等均为本合同不可分割的部分,并与本合同具有同等法律效力。如合同附件中的条款与协议条款的相关内容相冲突时,以本协议条款为准。
10.4所有关于本合同条款的修改、补充、变更,需经双方协商并制作书面补充协议,双方签字盖章后方能生效,补充协议作为本合同不可分割的一部分,具有与本合同相同的法律效力。
附表1:项目进度计划表
:项目工作计划表 附表2
甲 方: 乙 方: 单位地址: 单位地址: 法定代表人: 法定代表人: 委托代理人: 委托代理人: 电 话: 电 话: 开户银行: 开户银行: 账 号: 账 号:
附表1:
第 4 页 共 7 页
软件系统维护服务合同
项目进度计划表
1、项目概述:
项目名称: 开始时间: 业务部门: 项目经理: 项目范围:
2、进度计划表:
标工开始结束前置执行任务名称 识号 期(天) 时间 时间 任务 人
3、里程碑计划:
序里程碑名称 时工作描述 执行号 间 人
4、业主审批:
(1)业务处室: 时间:
意见:
(2)技术部门: 时间:
意见:
第 5 页 共 7 页
软件系统维护服务合同 附表2:
项目工作计划表
1、项目描述表:
项目名称
业务部门
项目经理
项目目标
交付物
交付物完成
准则
工作描述
工作规范
所需资源估
计
重大里程碑
2、项目工作分解结构图
3、项目人力资源计划
序姓名 角色 工作描述 进退
号 入时间 出时间
4、用户配合要求
第 6 页 共 7 页
软件系统维护服务合同
5、项目风险分析
序风险类型 风险描述 规避措施
号
6、项目管理计划
6.1项目变更管理
6.2项目质量保证措施
7、项目验收办法
验收时间:
验收人员:
验收标准:
8、业主审批:
(1)业务部门: 时间:
意见:
(2)技术部门: 时间:
意见:
第 7 页 共 7 页
范文五:浅析软件维护
摘 要:软件维护是软件生命周期的最后一个阶段,并且软件维护的成本大约占总开发成本70%以上,软件维护的巨大成本使得软件工程研究人员不得不对它更加重视。本文以软件工程原理为基础,分析了软件维护的类型和影响因素,提出了一些软件维护策略和未来的努力目标。
关键词:软件维护;软件工程;维护策略
中图分类号:TP311 文献标识码:A
1 引言(Introduction)
随着时间的推移和计算机技术的飞速发展,现代社会产生了越来越多的软件,这些软件都面临着维护和更新换代,软件维护水平的优劣直接影响着软件产品的生命周期[1]。软件产品开发结束后,该产品就进入了运行维护阶段,在这个阶段中常常由于各种原因需要对已完成的软件产品根据用户和实际中工作的新需求进行修改和维护,软件维护过程的工作量非常大,据统计,软件维护成本已经远远超过了系统的软件开发成本,占系统总投资的70%以上,为了使软件的寿命更长,这方面的工作量会越来越高,维护成本也会逐步增加,因此软件维护活动的研究越来越受到人们的关注,本文根据软件工程原理和实际应用经验总结出计算机软件维护方法策略。
2 软件维护分析(Analysis of software maintenance)
软件维护活动可以从管理和技术两个方面进行,其目的就是要确保软件维护活动能够在严格的控制之下进行,从而实现软件的功能和性能及时、准确的满足用户的要求[2]。
2.1 软件维护的类型
根据软件维护的不同目的可以将软件维护分为四类:适应性维护、完善性维护、纠错性维护、预防性维护或再工程。
(1)适应性维护:软件都有自己运行的硬件环境和软件环境,在使用过程中,硬件环境、软件环境、数据环境(如数据库、数据输入/输出方式、数据存储介质)都是可能发生变化的。为使软件适应这种变化,而去修改软件的过程就叫做适应性维护。
(2)完善性维护:在软件的使用过程中,用户往往会对软件提出新的功能与性能要求,为了满足这些要求,需要修改或再开发软件。这种以扩充软件功能、增强软件性能、改进加工效率而进行的维护叫做完善性维护。完善性维护是维护工作中最多的类型,占维护工作的50%左右。
(3)纠错性维护:在开发过程中要生成100%可靠无误的软件通常是不太现实的,在软件交付使用后,必然会有一部分隐藏的错误被带到到运行阶段,这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的错误使用,应当进行的诊断和改正错误的过程就叫做改正性维护。
(4)预防性维护或再工程:即修改软件,为将来的维护活动预先做准备。
在实际的维护工作中,软件维护类型并不是相会独立单独进行的,而是各种维护类型交织在一起进行的。例如在引入新的功能模块进行适应性维护的过程中,就有可能引入不明显的程序错误,这就需要跟踪和处理这些程序错误进行纠错性维护。类似的在进行完善性维护的过程中,可能需要重新调整代码结构从而引入了预防性维护。不同类型的软件维护之间的关系,如图1所示。
2.2 软件维护的影响因素
为了控制软件的维护活动,提高软件的维护效率,需分析影响软件维护的因素。
(1)工作繁琐。软件程序的任何一处改动,都可能影响到整个软件系统,并且这种影响只有在软件运行中遇到问题的时候才能显现,若要避免这种情况的发生,就需要在改动后进行大量的检测工作,这就无疑极大的增加了维护的工作量。
(2)系统规模。软件规模大小直接影响维护工作量,系统规模越大,读懂和理解就越困难,系统规模主要由程序模块数、数据文件数、源代码行数等因素衡量。
(3)系统使用年限。使用年限长的系统因为已经进行了多次的维护,参与维护的人员也不断变化,因此系统的结构更乱,如果没有完备的系统说明和设计文档,系统维护就更加困难。
(4)时间紧迫。通常软件错误只有在运行中才能被发现,用户往往是在时间紧迫的情况下请求维护的,这就要求维护人员必须在有限的时间内发现问题和解决问题。
(5)人员变动。软件行业人员流动性比较大,当起初的开发人员和维护人员离开后,会导致维护团队对软件熟悉程度的显著降低,甚至造成软件的彻底报废。
(6)文档同步。软件开发人员不断修改需求和设计过程中,忽略了文档的实时更新,造成交付的文档与实际软件不一致,使得今后对软件进行维护时出现误解。
3 软件维护策略(Software maintenance stratery)
通常情况下,软件维护工作要比开发工作困难得多,因为首先维护人员必须用较多的时间理解别人编写的程序和文档,并且对系统的修改不能影响程序的正确性,其次整个维护工作通常必须在规定得很短时间内完成[3]。在实际的维护工作中我们将软件工程原理运用到实际的软件维护活动中,经过长期的实践总结积累了一些实用的软件维护策略,这些策略基于维护管理和维护技术,能够以较少的代价有效的完成维护工作。
3.1 为维护工作制定流程
软件维护工作必须在一定的监控下进行,任何人不得私自进行软件维护,维护工作必须按照规定的步骤开展,否则一旦失控就有可能造成整个软件系统的报废。图2给出了一个软件维护工作流程图。
确定维护目标阶段,软件维护起始于一个对软件的更改请求,该更改请求既可能是纠错性维护也可能是完善性维护,需由维护机构确定其是何种类型,划分到合适的维护类别中(纠错性维护、适应性维护、预防性维护、完善性维护)。在分析阶段,先进行维护的可行性分析,在此基础上再进行详细分析。可行性分析主要确定软件更改的影响和可行性的解决方法等内容。详细分析则主要是提出完整的更改需求说明、鉴别需要更改的要素(模块)、提出测试方案和策略、制定实施计划。在设计阶段,汇总全部用于软件更改的设计的信息,这些信息包括系统的文档、分析阶段产生的结果、源代码等。在实现阶段,制定程序更改计划以便进行软件更改。实现阶段主要包括编码与单元测试、集成测试、风险分析、测试审查准备等过程。在系统测试阶段,主要测试程序之间的接口,以确保系统满足原来的需求以及新增加的更改需求。在验收测试期间,测试人员应该完成如下工作:报告测试结果、进行功能配置审核、确定系统功能是否满足功能需求、建立软件新版本。在交付阶段将新的系统交给用户完成安装与训练。此外,除了修改程序、数据、代码等部分以外,还应同时修改涉及的所有文档,包括系统文档和用户文档。 3.2 源程序修改
为了正确有效的修改源程序,要先在分析和理解源程序的基础上,然后修改源程序和验证源程序。在阅读源程序的过程中要画出每个过程的程序流程图,在分析过程中要定义局部数据结构,这样维护人员就可以比较清晰的了解程序中对全局数据结构的访问情况。维护人员在修改源程序前,一定要做好源程序的备份,以备将来的程序恢复和结果对照。维护人员修改源程序时应当特别注意,不要共用原来程序中已经定义的临时变量,为了减少修改带来的副作用,应该定义自己的变量,并在程序中插入错误检测语句。所编写的程序应尽量模块化,在编写程序代码时,尽量对每条编写代码都有比较详细的注释。
3.3 在维护过程中做好维护记录
维护记录是维护管理人员检查维护计划完成情况、监督维护过程、保障维护记录的基本信息,所有维护人员必须按规定认真填写。维护记录包括的内容有:程序名称、源程序语句条数、所有程序的设计语言、程序修改的层次、增加的程序语句条数、与程序有关的处理故障次数等。
3.4 验证测试
修改后的软件都需要进行测试,在修改程序的工作中通常会引入新的错误,进而影响或者破坏原来的功能,因此需要特别注意测试工作不但要测试修改过的部分,还应当测试未修改的部分。对修改的部分程序的测试应当独立进行,即先把修改部分的程序和未修改的程序进行隔离,然后进行两个隔离部分的独立测试,最后进行整个程序的测试。
4 结论(Conclusion)
软件维护是一项复杂的工作,不仅仅是技术上的问题,也是软件维护管理上的问题,只有在实际的软件维护工作中按照软件维护策略进行软件维护,才可以降低维护成本,保障维护质量,延长软件的生命周期。因此,近年来国内外的软件研究人员更加重视软件维护过程的管理和软件维护技术的研究。
参考文献(References)
[1] 黄国楠.浅谈软件维护[J].科技咨询,2005,24(8):68-69.
[2] 张海潘.软件工程导论(第五版)[M].北京:清华大学出版社,2008:191.
[3] 洪甜.FOXMS系统的软件维护[D].浙江大学,2006:13-16.
作者简介:
彭汉国(1965-),男,硕士,高级工程师.研究领域:电子装备保障,仿真系统开发.