《基于WEB的软件产品质量的维护 毕业论文.doc》由会员分享，可在线阅读，更多相关《基于WEB的软件产品质量的维护 毕业论文.doc（11页珍藏版）》请在三一文库上搜索。
1、毕业论文（设计）基于WEB的软件产品质量的维护Web-based Software Product Quality Maintenance完成日期 2012 年 3 月 25 日吉林大学珠海学院本科毕业论文（设计）开题报告基于WEB的软件产品质量的维护摘要在科技高速发展的今日，计算机成为人们生活中不可缺少的一部分，而人们利用计算机最经常使用的便是计算机软件与网络。而软件产品的开发过程，简单来说就分为问题的定义、软件需求分析、软件设计、软件实施、软件测试，之后便是软件维护的工作了，所以说软件维护在整个完整的软件生存期中有着不可或缺的作用，而且一个好的软件产品，在整个软件生存期中，软件维护的周期理
2、应是最长的。但是，在软件发展刚开始的时候，大多数的软件公司并不注重软件维护，把着重点都放在软件设计与软件实施中，以为只要把软件产品生产出来就万事大吉了，他们都没有想过一个问题，软件开发出来就是提供给用户使用的，软件设计与软件实施准确来说是面向内部的，而软件维护才是真正面向用户的。而软件发展都现在，国内越来越多的企业开始注重软件的后期维护，软件维护是越来越重要。本人实习的公司做的产品是基于B/S的web应用程序，而本人在公司实习期间所做的工作也与本文选题相符合，在维护部门下做一个子系统的软件维护工作。公司维护部门的维护工作包括软件的质量保证，软件的版本控制，以及软件的配置管理。本人主要的工作是软
3、件质量的维护，简单来说就是增加新功能、修正系统错误以及解决客户对此子系统提出的问题。虽然主要的工作是软件质量的维护，但既然在维护部门下工作，当然也是需要对子系统的版本进行控制的。因为公司系统的每个大版本都有不同程度的改动，所以就需要根据客户的版本变更要求来对系统进行相应的修改、配置以及说明。至于最后一项配置管理，本人就没有太多的涉及。而本文主要研究的就是基于B/S模式的web应用程序下，关于软件质量的软件维护。关键词：软件维护过程；软件质量；软件维护成本；基于网络的（浏览器/服务器）；软件可维护性；Web-based Software Product Quality MaintenanceAb
4、stractIn the rapid development of technology, the computer has become an indispensable part of peoples lives. In the use of computers, the most often used is the computer software and networks. And software product development process, in simple terms, is divided into the problem definition, softwar
5、e requirements analysis, software design, software implementation and software testing. After that is the work of software maintenance, so that software maintenance has an indispensable role in the complete software lifetime. And as one excellent software product, in the lifetime of the entire softw
6、are, software maintenance cycle is supposed to be the longest.However, in the early stages of the development of computer technology, most software companies only care software design and software implementation instead of software maintenance. they think everything is done when the software product
7、 is finished. They have not thought about a problem,the software is provided for users to use. And precisely, the software design and software implementation are face to internal.But software maintenance is face to users directly. With the development of software industry,more and more domestic ente
8、rprises began attach importance to the software maintenance, software maintenance is increasingly important.The product of my internship company is web application which based on B/S. And my work is maintenance the subsystem in maintenance team. So this work is consistent with this subject during th
9、e internships. In the maintenance team, the maintenance work includes software quality assurance, software version control, and software configuration management. And my main work is software quality maintenance. In simple terms, software quality maintenance is to add new features, fix system bugs a
10、nd resolve customer issues. Since working in the maintenance team, I also need to do software version control. We need according to customers requirements to make the appropriate changes, configuration, and instructions because there are many different degrees of alterations in each large version. A
11、s for the configuration management, I do not have much involved. This paper is researching about the maintenance of web applications based on B/S.Key words: software maintenance process; quality of software; software maintenance costs; web-based(B/S);software maintainability;目录1 软件维护的概念与概述11.1 概述11.
12、2 软件维护的类型21.3 基于web的软件的维护介绍与特点22 软件维护的活动与策略42.1 软件维护的工作流程42.1.1 维护组织42.1.2 维护报告42.1.3 维护的流程图52.1.4 维护记录与评价62.2 软件维护的内容62.2.1 完善性维护72.2.2 纠正性维护72.2.3 适应性维护72.2.4 日常维护72.3 软件维护质量的度量82.3.1可理解性82.3.2可修改性82.3.3可靠性92.3.4可测试性92.3.5可使用性102.3.6可移植性102.3.7效率112.4 各类维护的侧重点123 国内外情况分析与对比133.1 国内软件质量维护情况简单分析133.
13、2 国外软件质量维护情况简单分析134 软件质量维护案例分析154.1 国外电子政务系统的维护实例154.2 国内软件维护的维护实例164.3 案例分析165 提高软件可维护性与维护效率的方法186 软件维护的前景237 结束语24参考文献25致谢261 软件维护的概念与概述1.1 概述在软件的生存周期中，涵盖了两个重要的阶段，分别是开发期和运营期。运营期是系统有效发展的阶段，在软件开发的时候，由于花费了许多的人力物力资源，所以，软件人员总是希望能看到，可以尽可能地延长软件的运行周期，使软件的性价比更高。事实上，软件在运行的时候，是不可能不修改软件的，开发是一项大工程，可以提高生产效率，降低成
14、本，并保证软件的品质，人们总是希望使用现有的软件，对其扩张或移植。所以，软件人员在软件开发阶段之后，会继续对软件进行修正、扩展以及移植的这种行为，就是软件维护。软件质量是软件产品中能够满足用户需求的各种特性的总和，这些特性包括：功能、性能、可靠性、可维护性、可重用性、易用性等。软件质量，对软件开发人员来说就是优良的代码或设计，对用户来说就是响应快速、功能强大、性能良好的体验，对维护人员来说就是易于升级、修改的程序，对管理者来说就是合理的开发周期以及尽量低的开发成本。软件质量维护、版本控制、配置管理等在一定程度上也属于软件维护的范围，而本文主要研究的是软件质量的维护。图1-1 软件生存周期组成图
15、1.2 软件维护的类型软件维护一般分为四种类型的维护：一是完善性维护：为了满足用户的新需求而增加的功能的维护活动，完善性维护一般占整个软件维护量的50%左右。二是纠错性维护：顾名思义，也就是对软件系统中错误、bug等进行纠正的维护活动，纠错性维护一般占整个软件维护量的20%左右。三是适应性维护：为了适应软件运行环境而进行的修改的维护活动，适应性维护可以适应于由于硬件或者支持软件环境进而带来的变化、把软件移植到新机器上等，此类维护一般占整个软件维护量的25%左右。而最后一种维护是预防性维护：为提高软件的性能、可靠性、可维护性而进行修改的维护活动，预防性维护一般占整个软件维护量的4%，所以很少会进
16、行预防性维护。图1-2 各类维护比例图1.3 基于web的软件的维护介绍与特点基于web的软件，也称为B/S模式的应用程序，是通过浏览器与服务器的数据交互来运行的，依赖于网络，依赖于浏览器，不依赖于计算机的硬件环境，这种模式统一了客户端，将系统功能实现的核心部分集中在了服务器上，所以维护的工作只需专注于网络的故障以及软件本身的缺陷，维护的难度相对于C/S模式较小，并且需要及时快速地响应用户的问题以及给出解决方案；传统的C/S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。由于不能提供给用户真实期望的开放环境
17、，C/S结构的软件需要针对不同的操作系统以及不同的环境开发不同的版本，加上软件产品的更新换代十分迅速，已经很难适应百台电脑以上局域网用户同时使用。而且维护代价高昂，效率低下。与B/S模式的应用程序的维护不同，C/S 程序由于整体性，必须对软件进行整体考察，问题处理难度大以及系统升级难，C/S模式的应用程序的维护会经常性地需要远程维护，这就增加了维护的工作量以及维护的成本。图1-3 B/S体系结构图图1-4 C/S体系结构图2 软件维护的活动与策略2.1 软件维护的工作流程2.1.1 维护组织图2-1 维护组织组成图在这个维护组织中，有一名维护管理员总负责，每一项维护请求都要通过维护管理员，再指
18、派给维护人员进行维护工作。2.1.2 维护报告维护组织内部应该制定一个软件维护报告，它应该给出以下信息：1. 满足维护要求表中要求的所需要的工作量；2. 维护请求或问题的性质；3. 维护要求的优先级；4. 修复后的相关事后数据。2.1.3 维护的流程图图2-2 维护的事件流程图以下是维护的人员流程图：图2-3 维护的人员流程图2.1.4 维护记录与评价在软件维护的过程中，软件人员往往忽略了软件维护记录。这样，在软件运行了一段时间之后，如果要对软件的多方面进行评估的时候，因为没有维护记录，评估就无法进行，也就无法评价软件维护人员的效率与贡献。因此，维护记录也是软件维护中很重要的一环，而维护记录一
19、般会记录下以下数据：(1) 程序标志与标识 (10) 因程序变动而删除的源语句数(2) 源语句数 (11) 每个改动花费的人时数(3) 机器指令条数 (12) 程序修改的日期(4) 使用的程序设计语言 (13) 软件工程师的名字(5) 程序安装的日期 (14) 维护要求表的标识(6) 自从安装以来程序运行的次数 (15) 要进行维护的类型(7) 自从安装以来程序失效的次数 (16) 维护开始和完成的时间(8) 程序变动的层次和标识 (17) 用于维护的总人时数(9) 因程序变动而增加的源语句数 (18) 与完成的维护相联系的纯效益通过维护记录中的数据，对维护活动进行评价，从而产生维护工作的定量
20、度量。包括以下内容：(1) 每次程序运行平均失效的次数(2) 用于每一类维护活动的总人时数(3) 平均每个程序、每种语言、每种维护类型所做的程序变动数(4) 维护过程中增加或删除一个源语句平均花费的人时数(5) 维护每种语言平均花费的人时数(6) 一张维护要求表的平均处理时间(7) 不同维护类型所占的百分比根据对维护工作定量度量的结果，可以利用得到的数据去分析评价维护任务。2.2 软件维护的内容由第一部分的介绍中，已知软件维护一般分为四类：完善性维护、纠正性维护、适应性维护和预防性维护，而每类维护针对的方面不同，所以会有不同的维护内容。2.2.1 完善性维护当软件进入稳定运行期后，客户或用户会
21、有一些新的需求，一旦这些需求被接受，就需要开始完善或增加系统的功能，为了满足这类要求需要进行完善性维护。例如，完善性维护可以是增加新的处理、改变业务处理的流程、改善用户界面的的终端会话模式，或提高系统的运行速度、提高系统性能，或增加注释、改进可读性等。在软件刚上线运行的一两年，也就是系统维护阶段的前一两年，纠正性维护的工作量是比较大的。随着时间的推进与缺陷发现率的降低，系统就开始趋于稳定，纠正性维护的工作量就会降低了许多，而完善性维护与适应性维护的工作量就开始增加起来。2.2.2 纠正性维护在软件测试阶段，因各种原因的作用下，一部分的错误会没被测试出来或隐藏了起来，所以在软件上线运行期间，用户
22、必然会发现程序错误或者缺陷，并且把他们遇到的问题与错误报告给维护人员，软件维护人员为了识别和纠正这些错误、改正软件性能上的缺陷，就会进行相应的诊断和改正错误。而纠正性维护需要纠正的错误也包括很多种，如设计缺陷、代码缺陷、逻辑缺陷、数据缺陷、文档缺陷等等。2.2.3 适应性维护在计算机技术发展十分迅速的今日，各种操作系统的出现与各类硬件设备的更新，都会影响系统运行环境的变化。所以为了让软件在不同的环境下都能正常地运行，就需要适应性维护。影响环境变化的有很多因素，其中包括操作系统的变化（单单微软的操作系统就已经有很多种了,如Server 2003、Server 2008、Server 2012等等
23、）、硬件配置的变化（如机型、终端、打印机等等）、数据库的变化（如Oracle、SQL Server、NoSQL类型的数据库等等）、数据格式或文件结构的变化等。2.2.4 日常维护日常维护相对来说要简单一些，一般来说只要应用文档写的足够详细的话，维护工作都能顺利完成。例如对文件系统的检查，查看是否有足够空闲的空间；对数据库系统的检查，检查数据库是否正常运行，检查数据库数据是否正常与是否有脏数据；对第三方平台系统的检查，检查第三方平台是否正常运行。2.3 软件维护质量的度量目前广泛使用的是用如下的七个特性来衡量程序的可维护性与质量。2.3.1可理解性可理解性表明人们通过阅读源代码和相关文档，了解程
24、序功能及其如何运行的容易程度。对于一个程序来说，可理解性应该是最基本的要求。如果一个程序难以被理解，那么实际上就难以找到一种有效的方法来对它进行维护。一个具有可理解性的程序应具备以下一些特点：模块化，代码风格一致性，不使用令人捉摸不定或含糊不清的代码，使用有意义的接口名和类名，结构化，完整性等。用于可理解性度量的检查如下：（1）程序是否模式化？结构是否良好？（2）每个模块是否有清晰的注释（3）在整个程序代码中缩进和间隔的距离以及风格是否一致？（4）程序中的变量和函数过程是否是易于理解且独有的名字？（5）程序是否体现了设计思想？（6）是否能通过建立公共模块或子程序来避免多余的代码？（7）是否所有
25、变量都有用处，没有多余的变量？（8）程序是否避免了很难理解的 、非标准的语言特性？2.3.2可修改性可修改性表明程序修改的困难度。用于可修改性度量的检查如下：（1） 程序是否模块化？结构是否良好？（2） 程序是否是可理解的？（3） 在表达式中 ，数组的上下界的界定 、输入/输出设备命名符中是否使用了符合代码习惯的文字常数？（4） 是否具有可用于支持程序扩展的附加存储空间？（5） 是否使用了提供常用功能的标准库函数？（6） 程序是否把可能会产生变化的特定业务逻辑功能部分都分离到了单独的模块中？（7） 程序是否提供了不因个别功能变化而产生影响的模块接口？（8） 是否实现了一个模块只执行一个系统功能
26、的规则？（9） 每一个变量在程序中的用途是否单一？（10） 能否以不同的输入/输出方式操作？2.3.3可靠性可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行其功能的可能性。虽然定义是如此，可是在现实世界中，还没有任何一种手段能够保证软件具有百分之百的可靠性或精确地度量一个软件的可靠性。只能使用以下这些问题来大概估测程序是否可靠。用于可靠性度量的检查如下：（1） 程序中对可能出现的没有定义的数学运算是否做了控制与检查？（2） 循环的范围和循环终止的参数是否确认与测试过？（3） 下标的范围是否有超标或溢出？（4） 输入的数据是否经过了测试？（5） 对于可能发生溢出的情况是否已
27、经尽量避免以及测试过？（6） 对程序中最复杂的模块以及接口， 是否使用了多种测试技术对其进行反复测试？（7） 测试是否包括除了正常测试用例之外的 ，特殊的或者非正常的测试用例？（8） 是否测试了程序的所有业务逻辑， 是否都能得到正确结果？2.3.4可测试性可测试性表明论证程序正确性的容易程度。用于可测试性的度量的检查如下：（1） 程序是否模块化？结构是否良好？（2） 程序是否能显示已定义 ，带说明性质的错误信息？（3） 程序是否能显示任意的中间结果？（4） 程序是否具有跟踪以及显示业务逻辑控制流程的能力？（5） 程序是否能清晰不含糊地表示出它的输出数据？（6） 程序是否能及时地要求显示出所有的
28、输入？2.3.5可使用性可使用性就是从用户的角度出发，程序方便、实用以及便于使用的程度。一个具有可使用性的程序，应该是易于使用的、能允许用户出错和改变而不会是系统崩溃的程序。用于可使用性度量检查如下：（1） 程序是否具有自描述性？程序是否附有实例性的使用说明？是否有形成交互模式的帮助功能？在没有专业人员的指导下 ，用户是否能迅速地熟悉程序的简单操作？（2） 程序是否能让用户对数据处理有相对合适的控制？程序是否允许用户查看后台处理？程序是否能提供合理的、需要提醒用户的错误信息？程序能否在一旦用户需要系统提供帮助或提示信息的时候 ，显示出准确的帮助信息？（3） 程序的使用是否符合用户的使用习惯？程
29、序的操作是否有超出用户预期的结果？（4） 程序是否容易学会使用？程序是否不需要专业的知识便能够使用？对输入格式 、要求和限制的解释是否是完全的以及清晰不含糊地？程序是否自带有纠错功能？（5） 程序是否具有容错性？程序是否能容忍具有典型错误的数据输入 ，如打字或拼写错误 ？程序能否验证输入数据的正确率？（6） 程序是否灵活？程序是否允许以自由形式输入？对于用户来说，程序是否提供了不同的输入选择？程序是否允许用户自定义自己的功能模块和特性模块？程序是否可以重复使用而无需对输入值做过多的说明？（7） 程序的用户界面是否友好？程序用户界面的编排是否合理？界面文本与图片的间距是否合理？界面用色是否符合用
30、户的使用习惯？2.3.6可移植性可移植性表明程序转移到一个新的计算环境的可能性的大小。或者它表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度。一个具有可移植性的程序应该是不过重地依赖于某一具体计算机或操作系统的性能。用于可移植性的检查如下：（1） 是否使用了高级语言 ，而不是第一代 、第二代语言来设计编写程序？（2） 程序中是否使用了准确的 、已定义的 、普遍使用的子模块与库功能？（3） 程序在启动之前是否初始化了内存？（4） 程序在启动之前是否检查了当前使用的I/O设备？（5） 程序是否使用了较为成熟的软件技术进行设计？（6） 程序中是否极少使用或根本不使用操作系统的功能？（7
31、） 程序中数值计算的精度是否与机器的字长或存储器的大小限制无关？2.3.7效率效率表明一个程序能执行预定功能而不浪费机器资源的程度。这些机器资源包括内存容量、存储空间容量和执行时间等等。可用于效率的检查如下：（1） 程序是否具有高度的模块性，即程序在一个功能执行时都只涉及一个局部范围？（2） 是否清除了多余无用的符号 、标号以及表达式 ，以充分发挥编译器的优化作用？（3） 是否把在单独的模块中对特殊的子程序和错误进行处理？（4） 在编译时是否尽可能多地完成了初始化工作？（5） 在一个循环内是否有循环不变的代码？（6） 是否以快速的数学运算代替了较慢的数学运算？（7） 是否尽可能地利用整数运算，
32、而非实数运算？（8） 程序是否避免了非标准的函数或子程序的调用？（9） 在几条分支结构中，是否有可能为“真”的分支首先得到测试？（10） 在复杂的逻辑条件中，是否最有可能为“真”的表达式得到测试？2.4 各类维护的侧重点而且对于不同类型的维护，这七种特性的侧重点也不相同。图2-4 各类维护的侧重点图从图2-4中可以看出，因为纠正性维护主要的工作是修复bug，所以对可理解性、可测试性、可修改性、可靠性就比较侧重；根据适应性维护的定义，这类维护与环境有关，所有对可修改性、可移植性、可使用性比较侧重；而完善性维护就对可使用性和效率比较侧重。3 国内外情况分析与对比3.1 国内软件质量维护情况简单分析
33、在互联网的迅速发展中，越来越多的国内公司希望通过互联网这个渠道来增加公司产品的销量以及建立公司形象，因此也就促使越来越多的软件公司产生，国内的软件行业也因此开始了迅速地发展。可是受需求市场的影响，加上软件开发的成本不高，而且周期短，许多新兴的软件公司为了一时地盈利，只注重在软件开发中，并且在软件开发的过程中没有对软件进行详细的涉及以及长远的规划，导致国内软件的质量参差不齐，更不用说对软件维护的忽视了。后来在软件行业的发展中，国内的软件行业渐渐意识到如果要保证软件的质量，单单靠软件开发，是绝对不够的。此时，软件维护才被重新重视起来。而国内的软件维护发展至今，依然存在着这样一些问题，这会影响到软件
34、质量维护的效率以及工作量：第一是客户提的需求不明确，或者总是修改需求，而企业的管理人员也不向客户解释需求变更的困难性，为了讨好客户或者功利性，直接答应客户的需求变更，这就增加了软件维护的工作量与不稳定性。第二是部门职能分配不明确，部门之间的关系错综复杂，维护人员不熟悉软件，就直接交给开发人员修改，从而使开发人员的工作量变大，问题解决的时间也就随之变长。第三是测试人员对软件未发布前的测试少，或对维护人员提出的解决方案测试少，这就导致了可能在本地能解决的解决方案，到用户或客户的手上，却不能解决问题，这也就增加了问题解决的时间以及维护人员工作量。第四是维护流程的混乱，标准严谨的维护流程能更好地提高维
35、护人员的效率。第五是软件维护成本太高，比软件开发的成本高十几倍，甚至几十倍，使一些国内企业不愿意花如此巨大的成本来对软件进行维护。3.2 国外软件质量维护情况简单分析国外的软件行业的发展与国内的软件行业的发展类似，但是国外的软件行业更早地发现了软件维护的重要性，并进行了修正，加上国外的软件行业本来就比国内的软件行业发展得早，所以国外的软件维护的经验会领先国内不少，所以很多软件维护的经验都值得我们借鉴。国外的软件维护有几点值得我们学习的地方，第一是部门职能明确，没有错综复杂的部门关系，相对独立，也能相互协助解决问题。第二是国外对新员工的培训十分到位，做维护工作，重要的是对软件熟悉与理解，不像国内
36、的很多企业，招进来一些新员工，不经过什么培训，就直接上岗，要求员工自学，这样，新员工对软件不熟悉，维护效率自然就比较低，管理层又对新员工不满意，这就造成两边不讨好的情况。第三是国外的企业会进行大量各方面的测试，以保证维护人员提出的解决方案是准确可行的。第四是有一套规范严谨的维护工作流程。4 软件质量维护案例分析下面是两个案例，一个是国外的电子政务系统的维护案例；一个是国内某外包公司的案例。4.1 国外电子政务系统的维护实例本人实习的单位是大展信息科技有限公司，这个电子政务系统面向的都是外国客户，而且公司内制度以及企业文化与国外软件企业相仿。此电子政务系统是为国外政府做的，所以客户就是国外一些政
37、府机构的官员，而本人负责的是其中一个子系统，叫做互动式语音应答系统，简称AIVR。在本人正式开始独立处理软件维护问题之前，公司进行了一个多月的公司大培训，以及一个多月的单独培训，使实习生更加了解系统。而每日的工作流程如下：问题都先被收集在维护组的项目经理或项目组长的手上，再由项目经理或项目组长进行指派哪个维护人员解决此类问题，维护人员提出的解决方案要经过项目经理判断是否可行，再由负责同一子系统的测试人员进行反复测试（例如我是AIVR的维护人员，我提出的解决方案，要由负责AIVR的测试人员进行反复测试），解决方案通过之后再发送给客户，而问题的维护详情会记录在公司内部的站点里，维护流程很清晰明了，
38、部门职能也十分明确。举个例子，某一天早上，维护组的测试人员Kelly会把这一天客户的所有问题提交给项目组长Peter（因为是对国外的，所以有时差，这一天需要解决的问题，就相当于国外客户前一天提出的问题），Peter把有关AIVR的产品问题分配给我本人，而本人需要向客户收集此问题的所有相关信息，例如AIVR不能做schedule这个问题，有可能是很多方面的原因造成的，就需要客户提供相应的AIVR的log信息、服务器端的log信息、数据库的备份等信息来对原因进行分析，在找到造成这个问题发生的原因之后，就会跟Peter报告。如果Peter认同此原因是造成这个问题的关键，就由本人整理出解决方案，经过P
39、eter的审核，由负责AIVR产品的测试人员Janice对解决方案进行验证，通过了的话就跟用户沟通，说明情况；如果Peter认为此原因并不是造成这个问题的关键，就需要跟Peter以及AIVR的测试人员Janice讨论，因为本人是维护人员，所以会比较偏向代码、设计方面来提出解决方案，而测试人员对业务逻辑以及配置比较熟悉，Janice就会从业务逻辑以及配置方面给出建议，所以Peter认为不是这个原因的时候，就会让我们讨论出新的解决方案，经由他审核，再通过测试，才把新的解决方案提交给用户。而一般从找到问题根源，到提出解决方案，到验证解决方案这一系列过程，都需要在一天之内完成。如果出现的问题，维护组在
40、评定之后，确定组内无法解决，就会连同开发组与此问题相关模块的开发人员进行讨论，再确定最终的解决方案。图4-1 AIVR工作流程图4.2 国内软件维护的维护实例甲公司是软件外包公司，为乙公司做一个软件项目，软件开发项目总金额达到了1500多万元，一共12个子系统，参与人数众多。在代码实施与测试阶段，工程师人员达到了60多人，经过了5个月，系统开发与测试完成；在试运行阶段，撤离部分开发人员，留下25人进行后期开发与测试。系统正式上线运行后，甲公司与乙公司双方又签订了一项软件维护合同，为期一年，甲公司派了15人到现场负责技术支持、处理用户需求，其中程序员12人。随着系统运行了一段时间，用户不断提出新
41、要求，有些改动小，有些改动大，而大多数需求，在经过乙公司的讨论后都确认要跟进修改，项目组基本没有商量的余地。而被甲公司派过来进行软件维护工作的程序员都属于初级程序员，对整个软件并不是很熟悉，之前也没做过维护工作，改动前要花费大量的时间对系统业务需求、源代码进行了解、学习、研究，这就导致，问题解决速度较慢，这些程序员也开始抱怨起来。剽窃文字表述1.用户的问题以及给出解决方案；传统的C/S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。由于不能提供给用户真实期望的开放环境，C/S结构的软件需要针对不同的操作系统
42、以及不同的环境开发不同的版本，加上软件产品的更新换代十分迅速，已经很难适应百台电脑以上局域网用户同时使用。而且维护代价高昂，效率低下。与B/S模式的基于web的软件产品质量的维护_第2部分总文字复制比：4.1%（172）总字数：41781基于度量的软件维护过程管理的研究丁剑洁(导师：鱼滨) - 西北大学硕士论文- 2006-06-014.0%是否引用：否2从软件维护看软件开发李奇 - 河南冶金- 2001-12-152.5%是否引用：否而乙公司也对甲公司的程序员不满意，要求换人，换了几个，结果还是不太理想，乙公司就更不满意了，双方最后不欢而散。4.3 案例分析通过上面两个案例的对比分析，可以分
43、析出几个影响软件维护活动的因素：(1)代码熟悉度。软件维护的过程要阅读其他软件开发人员写的代码，这就意味着理解别人写的程序时会出现很多困难，这种困难随着软件配置成分的减少会出现较大的增幅。(2)客户或用户需求的经常性改变。如果客户或用户提出的问题的确是个bug，维护人员是要进行修改的，但是许多客户并不能分辨出问题的实质，便提交新需求，这就会使软件维护人员增加工作量。(3)人员流动性。软件人员流动性非常强，不管是开发人员、维护人员、还是测试人员，很少会在同一个项目组待很长时间。(4)维护流程。俗称没有规矩，不成方圆，不清晰的维护流程也会影响到软件维护人员的效率。除了从上面两个案例分析出来的因素，
44、当然还有一些其他的因素在影响软件维护活动：(1)系统大小。系统越是庞大，代码量就会越大，代码量越大，就导致需要花长时间去熟悉系统。系统越是庞大，业务功能也就越复杂。因而需要更多的维护工作量。(2)程序设计语言。使用强功能性的程序设计语言可以较好地控制程序的规模。语言的功能性越强，程序的模块化和结构化程度越高，程序的可读性就越好，也就容易维护。(3)系统年龄。系统生存的时间越长，随着不断被修改，结构就会在一定程序上被打乱。而许多老系统在当初并没有按照软件工程的要求进行开发，这就给维护工作造成了困难。(4)软件开发技术与规范。先进的软件开发技术往往结构化就更好，而按照代码规范写出来的程序，可读性就
45、越高，更利于软件维护。(5)文档不全。维护往往会出现文档不全的现象，这也会增加维护难度。(6)在软件的运营期，错误只有在软件的运行中才能发现，用户往往是在任务紧、时间急的情况下请求维护的，所以要求维护人员在短时间内能发现并解决问题。(7)软件维护的副作用大，一个小地方的改动，常常会影响到整个系统。而这种副作用往往在运行中造成了问题时才会被发现。这种不可预知性导致维护人员对维护工作产生了一定程度的惧怕和厌烦心理，而若要避免这种情况，就需要对系统进行大量的测试，但这就意味着要投入大量的资源，导致维护成本增高。(8)维护成本。在软件发展的前期，之所以软件维护会被忽视，其中一个原因就是维护成本的过高。
46、所以许多企业并不想付出比软件开发高出十几倍，甚至几十倍的成本去对软件进行维护。5 提高软件可维护性与维护效率的方法从上面的案例分析中可以得出软件维护活动的困难点分为两个方面，一个是不可控方面，如系统年龄、客户或用户的需求变更、人员流动性等；另一个就是可控方面，如文档不全、程序设计语言、软件开发技术与规范等。而本文研究的重点就在可控方面。第一，选择较容易维护的程序设计语言进行开发。第一代的机器语言与第二代的汇编语言明显不适合于现在的软件开发，这些语言的功能强大，却不容易理解与掌握，可读性相对来说并没有高级语言好，也就难以对其进行维护。高级语言相对来说就更好理解与掌握，第四代语言，例如图形语言、查
47、询语言等，有的是过程化的语言，有的是非过程化的语言，不管是哪一种语言，编写出的程序都更加容易理解和修改，并且，其产生的代码指令条数可能要比用低级语言编制出的少一个数量级，从而使开发速度快几倍。而即使是高级语言，其中也有难易之分，具体需要什么语言来开发就要根据环境而定，但是高级语言肯定是比低级语言具有更高的可维护性。图5-1 语言可维护性对比图第二，建立明确清晰的软件质量目标以及问题优先级。软件是不可能百分之百完美无缺陷无漏洞的，所以维护人员在维护的时候不能想着要把系统修改得完美，而是要建立明确清晰的软件质量目标，达到这个目标之后，就不要再钻牛角尖去完美这个软件，这不仅会使维护的时间增长，也会影响维护工作的效率，在你把某个维护问题解决到完美的时候，说