软件维护服务工作计划

时光荏苒，一项工作总是在不知不觉间结束，我们又迎来新的任务与挑战，在开始新的任务前，我们要学会撰写计划，那么该如何拟定计划呢？以下是小编整理的关于《软件维护服务工作计划》相关资料，欢迎阅读！

第一篇：软件维护服务工作计划

软件与服务外包学院2014届毕业设计工作计划

根据学院2014届学生毕业设计的工作要求，结合外包学院的具体实际情况，拟定外包学院2014届毕业设计工作计划：

一、毕业设计考核小组

组长：杨正校

成员：周玲余、浦菲举、各专业负责人

二、毕业设计总要求

1. 毕业设计选题。要求毕业生尽量结合实习工作实际，选取与实习工作内容密切相关的内容，部分学生也可以选择与课程相关的大作业等内容。

2. 撰写的毕业毕业设计文本格式符合教务处格式要求规范。具体要求参见教务下发文件。

3. 需要在规定时间内完成毕业设计。

4. 指导教师对学生的选题和毕业设计工作负责。

三、具体时间要求

1. 毕业设计指导教师在1月30日前完成指导学生的开题工作，2月28日前上交《毕业设计(论文)选题审批表》、《毕业设计(论文)题目汇总及成绩》、《毕业设计(论文)任务书》及《毕业设计(论文)开题报告》四张表(电子及纸质稿，统一交由班主任汇总后上交

系部)。各文档的命名规范见下文6(补充说明)。

2.2月1日至4月4日，指导教师根据学院对毕业设计的格式及内容上的要求对学生的毕业设计进行指导及把关，并于4月11日前完成毕业设计初稿的审阅。

3.4月12日至4月18日，指导教师完成对第二稿的审阅并上报优秀毕业设计的人选，指导教师须将优秀毕业设计的相关材料(毕业设计终稿，选题表，开题报告任务书)在4月26日前交至系部优秀毕业设计评阅小组审核，并负责通知到有关答辩同学，于5月4日参加预答辩，毕业设计考核小组以确定重点答辩毕业设计人选。

4.5月10日，2014届毕业生答辩会，学生须携带毕业设计终稿的纸质稿2份参加答辩。学生须在5月16日前将根据答辩意见对毕业设计进行再修改，并将毕业设计终稿及其他相关材料发给指导教师，指导教师确认无误后交由班主任汇总。班主任需在5月21日前将班级的毕业设计材料(审批表，开题报告，任务书，题目及成绩表，毕业设计终稿)电子稿以班级为单位提交到系部，由系部统一对毕业设计进行胶印封装。

5.5月26日至5月29日，指导教师汇总其指导学生的毕业设计材料，并整理装订成袋，统一交有关班主任汇总后上交系部。

6.补充说明：①最终的电子稿材料除题目及成绩汇总表外，其他文件最终稿均需为PDF文件，文件的命名规范：文档的命名方式为：学号_姓名_文档名称。例：110302231120_张宸_毕业设计(毕业设计)开题报告。

②各附件起止日期：

毕业设计封面：2014年5月

选题审批表：2014年1月15日至1月20日之间日期 任务书：2014年1月15日至2014年5月9日 开题报告：2014年1月21日至1月31日之间日期

软件与服务外包学院

2014年2月27日

第二篇：软件维护服务合同

甲方：乙方：

甲、乙双方经友好协商，双方同意，乙方就向甲方提供软件产品维护服务达成如下协议，乙方将按照本服务合同及相关附件所约定的维护服务内容向甲方提供服务，甲方同意并保证完全执行本服务合同所约定的责任，以利于本合同的顺利进行。

第一条：维护服务内容

甲方定期做好系统数据备份，并对备份数据进行妥善保管。甲方在应用过程中发现软件出现异常，应及时与乙方取得联系，并记录当前故障现象，便于乙方作出诊断。甲方在乙方服务人员服务完成后，配合检查软件系统运行是否正常。

乙方向甲方提供系统的运行维护服务(客户其它应用软件不含在内)。乙方负责向甲方提供对上述系统问题或故障解决的技术支持与相应服务及提供服务期内软件升级的咨询服务。乙方指根据甲方要求对软件现有功能进行和改动。甲方如需新增软件功能费用另外协商再议。

第二条：服务期限：

月日至年方有运行维护服务要求，必须另行签定运行维护服务合同。

第三条：合同金额及付款方式：

3.1合同总金额：年服务费为(软件价值的15%)整(大写：)。除本合同另有明确约定外，甲方不再向乙方支付任何费用。

3.2付款方式：甲方应于本合同生效之日起的 ,向乙方一次性支付合同约定的运行维护费

第四条：维护服务进度及方式

在本合同有效期内，乙方向甲方提供系统管理的全面的技术支持和维护服务。具体维护内容和方式如下：

4.1技术支持咨询

乙方将提供给甲方一份详细的技术咨询联系办法，在合同维护服务期内，甲方系统管理员可以随时通过电话、传真及电子邮件等各种灵活的通讯手段向乙方进行技术咨询，乙方将第一时间给予甲方答复。

4.2 及时响应

乙方向甲方提供每周5个正常工作日，每个工作日8小时的随时响应服务。

4.3远程联机

如果甲方遇到一些基本问题，乙方的支持工程师可以通过远程登录到甲方设备上来查看问题所在，并指导甲方或直接排除故障。

4.4现场支持

4.4.1如果甲方遇到较为复杂的问题，一般通讯手段的咨询和远程联机不足以解决，乙方将根据甲方具体情况，安排工程师赶到现场解决问题。对于通过远程方式无法解决的，乙方应在72小时内安排工程师到达用户现场第一时间内对系统进行处理，使系统重新恢复运行。

4.4.2乙方对于甲方工程师提出的有关软件方面的技术问题进行培训和辅导。

4.4.3针对用户系统的运行情况，结合乙方工程师自身的经，提出系统改进建议，供用户参考。

4.4.4 以上若干种维护服务内容并不是相互割裂、互不相关的，而是相互渗透、紧密结合成为完整统一的支持维护体系。

乙方向甲方提供的所有现场维护服务所涉及的全部费用不包括在本合同总价款之内，甲方需根据实际费用另外支付。

第五条：责任限制及有限保证

5.1乙方承诺根据本合同的约定向甲方提供服务,但是对于因不可抗力或甲方因素导致的延误而给甲方造成的损失不承担任何责任。

5.2 除本合同或其附件另有约定,乙方对如下软件产品不提供任何运行维护:乙方及乙 方代理人之外的任何人未经乙方许可对许可软件进行任何方式的修改而产生的软件;甲方未按照许可合同约定的范围及限制使用的许可软件;甲方所使用的任何第三方软件产品。

5.3除本合同后其附件另有约定,乙 方提供的运行维护不包括以下情况:甲方人员非法操作、计算机设备感染病毒、第三方产品的故障、计算机设备故障、网络故障等导致许可软件无法正常运行;甲方因许可软件遗失、被盗、被误用或被擅自修改、计算机设备故障、网络故障、其他软件的故障、操作失误等情况造成数据混乱和丢失。

第六条：不可抗力

6.1若合同的任何一方由于不可抗力的原因影响合同正常执行，则合同应延期执行，延期时间应与事件的持续时间相同。

6.2受阻方尽快将发生的不可抗力事件情况以最快方式通知另一方，并在随后的十天内开具书面的证明给另一方，做为不可抗力的证明。

6.3受不可抗力影响的一方，应尽一切努力减轻和克服不可抗力的影响，并在不可抗力事件后，继续履行合同职责。

6.4在不可抗力的影响下，受阻方可暂时停止执行合同的受阻部分。当不可抗力事件持续的时间超过三个月，双方可就解除合同及其它未尽事宜进行协商处理。

第七条：保密

7.1甲乙双方应履行保密义务，未经双方许可，不可向任何第三方泄露任何技术文件及与合同有关的数据，包括合同本身。

7.2对于来自甲方或用户的有关保密信息，乙方须同样遵守保密约定。

7.3以上保密条款的期限为永久，自本合同生效之日起算。

7.4若乙方违反保密条款的约定，则承担本合同总额10%的违约责任及赔偿由此给甲方造成的损失。

第八条：争议的处理和解决

本合同及其补充协议的签订、履行及责任的划分等，均适用中华人民共和国法律。与本合同有关或履行本合同过程中发生的一切争议，双方同意提请甲方住所地人民法院通过诉讼方式解决。

第九条：其它

9.1本合同一式四份，双方各执两份，附件和正本具有同等效力，经双方签字并盖章之日起立即生效。

9.2对本合同的任何修改和补充，应经双方协商共同签订补充协议。

签署

甲方：乙方：

代表：代表：

日期：年月日日期：年月日

第三篇：软件服务外包

2011年，我国软件与信息服务外包产业快速发展，产业规模达到3835亿元人民币，同比增长39.5%，高出2010年4.3个百分点;企业承接服务外包合同执行金额323.9亿美元，同比增长63.6%，其中承接国际离岸服务外包合同金额238.3亿美元，同比增长65%，比上年提高了22%;2011年我国软件与信息服务外包国际业务中，31.7%的外包业务来自日本，28.3%的业务来自美国;2011年，我国承接的服务外包占了全球的23.2%，比上年提高了6.3%。

提要：中国承接国际软件服务外包业务正迅速增长，已成为全球第二大离岸外包目的地国家。在业务规模总量不断突破提升的同时，软件外包业务类型和国别开始呈现出多元化的趋势，人才队伍建设更有成效，企业竞争力大幅提高，软件外包在转型中深耕大市场。

企业为了专注核心竞争力业务和降低软件项目成本，将软件项目中的全部或部分工作发包给提供外包服务的企业，由此带来了巨大的软件外包市场。从最初的呼叫中心到如今的云服务，软件外包自身也在不断转型并走向高端，从而孕育出更大的市场。

以软件服务外包业务闻名的东软集团董事长兼CEO刘积仁却认为，软件外包是以人力资源获得国际市场，多年来这种模式在中国软件行业迅速发展，主要是靠旺盛的本土需求和本土便宜的工程师资源。但随着中国人力资源价格上涨，这种模式将在中国“进入死胡同”。

因此，以东软为代表的软件服务外包企业开始谋求转型。对此，国际市场调研公司IDC大中华区总裁郭昕表示，软件服务外包需要新的形态，比如云计算、物联网等都提供了新的外包平台。软件服务外包不应该只盯住企业的IT部门或数据处理需求，要从被动迎接企业数据的处理需求，转向促进企业不断从实体生产变成信息生产。在这个过程中，软件服务外包企业，要起到咨询和顾问的作用。

政策解读：“十二五”期间转变经济发展方式、调整产业结构、发展战略性新兴产业等成为重点发展方向，将释放巨大的软件与信息服务外包需求，内需市场仍将成为我国软件外包与信息技术服务产业的主要市场。

与此同时，“整个软件与信息服务外包正在逐渐向高端发展，一个表现趋势是由操作层的外包转向职能型的外包。目前，信息技术外包的业务基础发展规模较大，业务流程外包的发展潜力较大，基于信息技术的业务流程的外包，也发展迅速。”中国软件与信息服务外包产业联盟副理事长高松涛表示。

第四篇：软件维护合同

甲方：_________

乙方(服务方)：_________

甲乙双方本着互相信任、真诚合作的原则，经双方友好协商，就乙方为甲方提供技术支持服务达成一致意见，特签订本合同。

一、合同适用说明

本合同适用于首次购买乙方软件产品及需要乙方技术服务的用户。

甲乙双方签订本合同，表明甲方接受乙方所提供的标准服务;否则，视甲方主动放弃乙方所提供的服务。

二、服务内容

乙方提供的服务内容：

产品标准培训：乙方负责承担甲方所产品的标准培训。

热线支持：指乙服务人员通过电话向用户提供技术问题解答的过程。

现场维护：指乙方派遣技术人员到用户现场处解决问题的过程。

功能改进：指根据甲方要求对软件功能进行和改动。

乙方的服务承诺：

乙方接到甲方通过电话，信函，传真，电子邮件等方式提出关于软件的服务请求后，在当日内给予响应并提供服务。

乙方提供给甲方的服务，必须按照合同规定的服务内容进行。

三、甲方责任

甲方应确保有专人对软件的使用和管理负责。

甲方应建立相关制度，以确保软件运行环境(包括计算机，打印机及相关硬件设备)的安全，为软件正常运行提供保障。

甲方定期做好系统数据备份，并对备份数据进行妥善保管。

甲方在应用过程中发现软件出现异常，应及时与乙方取得联系，并记录当前故障现象，便于乙方作出诊断。

甲方在乙方服务人员服务完成后，配合检查软件系统运行是否正常。

四、收费办法和合同期限

年服务费为(软件价值的15%)：_________(大写)。

合同有效期为一年，自_________年_________月_________日至_________年_________月_________日止，期满合同自动中止。

合同合同满后，双方协商，甲方可要求乙方继续提供软件运行维护服务，但双方必须重新签署新的服务合同。

五、争议处理

甲乙双方如对协议条款规定的理解有异议，或者对与有关的事项发生争议，双方应本着友好合作的精神进行协商。

协商不能解决的，依照《中华人民共和国合同法》，任何一方可向乙所在地的人民法院起诉。

六、其他

本合同未尽事宜，由甲乙双方协商后产生书面文件，作为本合同的补充条款，具备与本合同同等法律效力。

对本合同内容的任何修改和变更需用书面形式，并经双方签字确认后生效。

本合同为双方唯一的正式协议，其他任何方案，口头说明及与本项目有关的信函、传真、邮件等，均以本合同为准。

甲方(盖章)：_________ 乙方(盖章)：_________

代表人(签字)：_________代表人(签字)：_________

_________年____月____日 _________年____月____日

签订地点：_________ 签订地点：_________

第五篇：软件维护

第8章 软件维护

8.1 软件维护的基本概念

教学内容：软件维护类型、策略和成本，软件维护的副作用和困难。 教学重点：软件维护类型和策略。

教学难点：软件维护的副作用和困难。 教学方法：课堂讲授+讨论。

教学要求：理解软件维护类型和策略，了解软件维护的成本，理解软件维护的副作用和困难。

思 考 题：1) 由于业务变化而修改软件是哪种类型的软件维护?

2) 如何处理控制软件维护的副作用?

3) 软件维护成本和软件开发成本哪个通常更高?

8.1.1软件维护类型

软件维护活动类型总起来大概有四种：纠错性维护;适应性维护;完善性维护或增强;预防性维护或再工程。除此四类维护活动外，还有一些其它类型的维护活动，如：支援性维护(如用户的培训等)。

8.1.2 软件维护策略

针对以上几种类型的维护，我们可以采取一些维护策略，以控制维护成本。

1、改正性维护

在开发过程中要生成100%可靠无误的软件通常是不太现实的，但通过使用一些新技术，可以大大减少进行改正性维护的需要。

2、适应性维护

运行环境的变化是不可避免的，但可以控制。 进行配置管理。把硬件、操作系统和其他相关环境因素的可能变化进行配置管理。 修改局部化。把因环境变化而必须修改的程序局部于某些程序模块中。

使用例行程序包等。例如使用内部程序列表等，可为维护性修改程序提供方便。

3、完善性维护

利用前两类维护中列举的方法，可以减少此类维护。另外，使用功能强且易于使用的工具和通过用户使用系统原型模型完整地确定系统需求等可以减少完善性维护的工作量。

4、预防性维护

可通过采用提前实现或软件重用等手段或技术来减少此类维护活动的工作量。

5、支援性维护

可通过提供最新用户文档或联机用户文档，进行适当的用户培训或设立专门的维护人员等方式来减少此类维护活动。

8.1.3 软件维护成本

软件维护活动所花费的工作量占软件整个生存期工作量的70%以上。影响软件维护工作量的因素有很多，就软件系本身而言，有以下几个方面：

1、系统的大小

系统的大小可用源程序语句数、模块数、输入/输出文件数，数据库所占字节数及预定义的用户报表数等来度量。系统越大，功能就越复杂，理解并掌握起来就越困难。因此维护工作量也就越大。

2、程序设计语言

语言的功能越强，生成程序所需的指令或语句数就越少，并且程序的可读性也越好。一般地，语言越高级越容易被人们所理解和掌握。因此，程序设计语言越高级，相应维护工作量也就减少。

3、系统年龄

系统越老，修改维护经历的次数就越多，从而结构也就越来越乱。而且老系统会存在没有文档或文档较少或文档与程序代码不一致等现象。同时，有可能老系统的开发人员已经离开，维护人员又经常更换，等等。这些使得老系统比新系统需要更多的维护工作量。

4、数据库技术的应用

使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可减少生成用户报表应用软件的维护工作量。

5、软件开发新技术的运用

在软件开发时，使用能使软件结构比较稳定的分析与设计技术，以及程序设计技术，如面向对象技术、构件技术、可视化程序设计技术等，可以减少大量的工作量。

除此之外，应用的类型、任务的难度等对维护工作量都有影响。

8.1.4 软件维护的副作用

所谓软件维护的副作用，就是指由于修改程序而导致的错误或其它不需要的活动。Freedman和Weinberg定义了三类主要副作用，即：修改代码的副作用、修改数据的副作用和修改文档资料的副作用。

为了控制因修改而引起的副作用，在修改时应做到：

1、按模块把修改分组;

2、自顶向下地安排所修改模块的顺序;

3、每次修改一个模块;

4、对于每个修改了的模块，在安排修改下一个模块之前，要确定这个修改的副作用。可以使用交叉引用表、存储映象表、执行流程跟踪等。

8.1.5 软件维护的困难

下面列出的是与软件维护有关的困难：

理解别人的程序困难，且困难程度随软件配置成分的减少而迅速增加。 需要维护的软件往往存在文档资料不全，甚至有文档也不易理解并和程序代码可能不一致。当前，有些软件的文档是在代码形成后为了应付所谓的鉴定而突击出来的。

大多数软件在开发时没有考虑到将来的维护。

软件维护被人们看成是一种没有创造性的工作，往往不能引起人们的重视。部分人认为，维护别人的程序不如开发新的程序。

显然，如果在软件定义和软件开发时期，重视采用软件工程思想，那么上述问题可以至少部分地解决。当然，软件工程也不是万应灵药，软件工程也是在实践中不断地向前发展的。

8.2 软件维护过程

教学内容：软件维护的组织机构、维护申请、维护工作流程及评价。 教学重点：维护组织机构及工作流程。 教学难点：维护评价。

教学方法：课堂讲授+讨论。

教学要求：理解软件维护组织机构的作用，了解维护申请，熟悉软件维护流程，了解软件维护评价。

思 考 题：1) 软件维护记录的作用是什么? 2)软件维护组织有哪些角色?其作用是什么?

8.2.1? 维护组织

通常，软件维护工作并不需要保持一个正式的组织机构。但是，委派一个非专门的维护管理员负责维护工作是绝对必要的。维护管理员、修改批准人员和系统管理员等分别代表了维护工作的某个职责范围。维护管理员、修改批准人员可以是指定的某个人，也可以是一个包括管理人员、高级技术人员等在内的小组。在维护活动开始之前就明确维护责任是必要的，这样可以大大减少维护过程中可能出现的混乱。?

8.2.2 维护申请

所有维护申请应按规定的方式提出。维护组织通常提供维护申请表(Maintenance Request Form，简写为MRF)，由申请维护的用户填写。如果是改正性的维护，用户必须完整地说明出错的情况，如输入数据，全部输出信息以及其他有关材料。如果申请的是适应性或完善性维护，则应提出一个简短的需求说明书。

维护申请表是由软件维护组织外部提交的文档，它是计划维护活动的基础。软件维护组织内部应相应地做出软件修改报告(Software Change Report，简写为SCR)，内容包括：

(1)为满足MRF要求所需工作量; (2)维护要求的性质;

(3)维护申请的优先次序; (4)预计修改后的状况。

在进一步安排维护工作之前，应将软件修改报告提交给修改批准人员批准。

8.2.3 维护工作流程

维护请求引起的工作流程：

(1)首先，要判明维护类型。当用户和维护管理人员存在不同意见时应协商解决。 (2)对改正性维护请求，从评价错误的严重性开始。如果存在严重错误，则应在系统管理员的指导下分派人员立即进行维护工作;否则，就同其它开发任务一起，统一安排工作时间。

(3)对适应性和完善性维护请求，应先确定请求的优先次序。如果某项请求的优先次序非常高，就应立即开始维护工作;否则，就同其它开发任务一起，统一安排工作时间。

尽管维护请求的类型不同，但都需要进行同样的技术工作：修改软件需求说明、修改软件设计、设计评审、对代码作必要的修改、单元测试、集成测试(回归测试)、确认测试等等。

为了正确、有效地修改源程序，通常需要经历以下三个步骤：1)分析和理解程序;2)修改程序;3)重新验证程序。 8.2.4 维护记录与评价

如果对维护不保存记录或保存不充分，那么就无法对软件使用的完好程度进行评价，也无法对维护技术的有效性进行评价。Swanson提出了下述内容： ⑴程序标识;

⑵源程序语句数;

⑶机器代码指令数;

⑷使用的程序设计语言;

⑸程序交付日期;

⑹程序交付以来的运行次数; ⑺自交付以来程序失效的次数;

⑻程序变动的层次和标识;

⑼因程序变动而增加的语句数;

⑽因程序变动而删除的语句数; ⑾每项修改耗费的人时数;

⑿程序修改日期;

⒀软件工程师名字;

⒁维护请求表的标识; ⒂维护类型;

⒃维护开始与结束日期;

⒄累计用于维护的人时数;

⒅与完成的维护相联系的效益。

将上述18项数据作为维护数据库的基础，可以从以下7个方面度量维护工作： ⑴程序运行失败的平均数;

⑵用于每类维护活动的总人时数;

⑶平均每个程序、每种语言、每种维护类型所做的程序变动数; ⑷维护过程中增加或删除一个源程序语句平均花费的人时数; ⑸维护每种语言所花费的工作量(平均人时数); ⑹一张维护申请表的平均周转时间; ⑺不同维护类型所占百分比。?

8.3 软件可维护性

教学内容：影响软件可维护性的三个属性、软件可维护性度量、提高可维护性的方法。

教学重点：提高可维护性的方法。 教学难点：软件可维护性度量。 教学方法：课堂讲授+讨论。

教学要求：理解软件可维护性的三个软件属性，了解定量的软件可维护性度量，掌握提高软件可维护性的方法。

思 考 题：

8.3.1 影响软件可维护性的软件属性

定性地说，软件可维护性又取决于软件的三个属性，即：可理解性、可修改性与可测试性。

1、可理解性

软件可理解性表现为人们通过阅读源代码和相关文档，理解软件的结构、接口、功能和内部过程的容易程度。模块化和结构化设计、文档、程序设计语言等都对软件的可理解性有较大的影响。而且，软件越复杂，理解也就越困难。

2、可测试性

可测试性代表一个软件容易被测试的程度。它一方面与源代码有关，要求程序易理解;另一方面，要求有齐全的测试文档，包括开发时期用过的测试用例与结果。

3、可修改性

可修改性表明程序容易修改的程度。一般来说，模块设计的内聚、耦合、局部化、作用域/控制域等因素都会影响软件的可修改性。模块抽象和信息隐蔽愈好，模块的独立性愈高，则修改中出错的机会也就愈少。??

8.3.2 软件可维护性的定量度量

1979年，T.Gilb建议把维护过程中各种活动耗费的时间记下来，以此来间接度量软件的可维护性。记录的时间如下：

⑴问题识别的时间;

⑵因管理活动拖延的时间; ⑶收集维护工具的时间;

⑷分析、诊断问题的时间; ⑸修改规格说明的时间;

⑹具体的改错或修改的时间; ⑺局部测试的时间;

⑻集成或回归测试的时间; ⑼维护评审的时间;

⑽分发与恢复运行的时间。

显然，以上10项表明了一个维护过程所包含的全部活动。可以粗略地认为，这个周期越短，维护就越容易。

8.3.3 提高可维护性的方法

软件的可维护性对于延长软件的寿命具有决定性的意义。因此，不仅维护人员应重视软件的可维护性，软件开发人员也要为减少今后的维护工作量而努力。为了提高软件的可维护性，可以从以下几个方面着手： (1)建立明确的软件质量目标和优先级; (2)使用提高软件质量的技术和工具; (3)进行明确的质量保证审查; (4)选择可维护的程序设计语言; (5)改进程序文档;

(6)开发时考虑到维护。

8.4 软件再工程技术

教学内容：逆向工程、正向工程、重构、成本/效益分析、再工程风险分析。 教学重点：逆向工程、正向工程、重构。

教学难点：再工程成本/效益分析、风险分析。 教学方法：课堂讲授+讨论。

教学要求：理解逆向工程和正向工程，掌握重构，了解再工程成本/效益分析和风险分析。

思 考 题：软件重构的目标是什么?重构的对象有哪些?

8.4.1 逆向工程

术语“逆向工程”源自硬件领域，是一种通过对产品的实际样本进行检查分析，得出一个或多个关于这个产品的设计和制造规格的活动。软件的逆向工程与此类似，通过对程序的分析，导出更高抽象层次的表示，如从现存的程序中抽取数据、体系结构、过程的设计信息等，是一个设计恢复过程。 逆向工程过程所抽取的信息，一方面可以提供给软件工程师以便在任何维护活动中使用这些信息;另一方面可以用来重构原来的系统，使新系统更易维护。?? 8.4.2 重构

软件重构是对源代码和/或数据进行修改，使其易于理解或维护，以适应将来的变更。通常，重构并不修改整个软件程序的体系结构，趋向于关注模块的细节。如果重构扩展到模块边界之外并涉及软件体系结构，则重构变成了正向工程。 软件重构中代码重构的目标是生成可提供相同功能但质量更高的程序。需要代码重构的模块往往以难于理解、测试和维护的方式编码。为此，用重构工具分析源代码，标注出和结构化程序设计概念相违背的部分，然后重构此代码，复审和测试生成的重构代码，更新代码的内部文档。

8.4.3 正向工程

正向工程也称为改造，用从现存软件恢复设计中得到的信息去重构现存系统，以改善其整体质量。在大多数情况下，被再工程的软件需重新实现现存系统的功能，并加入新功能和/或改善整体性能。正向工程过程将应用软件工程的原则、概念和方法来重建现存应用。由于软件的原型(现存系统)已经存在，正向工程的生产率将远高于平均水平;同时，又由于用户已对该软件有经验，因而正向工程过程可以很容易地确定新的需求和变化的方向。这些优越性使得再工程比重新开发更有吸引力。

8.4.4 再工程成本/效益分析

再工程花费时间，并占用资源。因此，一个组织试图再工程某现存应用之前，有必要进行成本/效益分析。

Sneed提出了再工程的成本/效益分析模型，涉及以下几个参数： P1：当前对某应用的年维护成本 P2：当前某应用的年运行成本 P3：当前某应用的年收益

P4：再工程后预期年维护成本 P5：再工程后预期运行成本 P6：再工程后预期业务收益 P7：估计的再工程成本 P8：估计的再工程日程

P9：再工程风险因子(名义上P9=1.0) L：期望的系统生命期(以年为单位)

则有：①和未执行再工程的持续维护相关的成本：Cmaint=[p3-(p1+p2)]*L ②和再工程相关的成本：Creeng=[p6-(p4+p5)*(L-p8)-(p7*p9)] ③再工程的整体收益：Cbenefit=Creeng-Cmaint

8.4.5 再工程风险分析

再工程和其它软件工程活动一样可能会遇到风险，作为软件管理人员必须在工程活动之前对再工程风险进行分析，以提供对策，防范风险带来的损失。再工程风险主要有以下几个方面：

(1)过程风险：未进行再工程成本/效益分析或在规定的时间内未达到成本/效益要求;对再工程项目的人力投入缺乏管理;对再工程方案实施缺乏监督等等。 (2)应用领域风险：再工程项目缺少本地应用领域专家支持;对源程序中体现的业务知识不熟悉;等等。

(3)技术风险：恢复设计得到的信息无用或未被充分利用;逆向工程得到的成果不可分享;缺乏再工程技术支持;等等。 8.5 小结

软件维护是软件生存周期的最后一个阶段，也是成本最高的阶段。软件维护阶段越长，软件的生存周期也就越长。软件工程学的一个主要目的便是提高软件的可维护性，降低软件维护的代价。

软件维护不同于硬件维护，通常有四种类型：改正性维护、适应性维护、完善性维护和预防性维护。软件维护大多要涉及到软件设计内容的修改，从而要重视软件维护的副作用，对软件维护要有正式的组织，制定规范化的过程，实行严格的维护评价。

软件再工程是提高软件可维护性的一类重要的软件工程活动。同软件开发相比，软件再工程不是从编制规格说明开始，而是从原有的软件出发，通过一系列再工程活动，得到更易维护的新系统。