软件工程PPT.ppt

《软件工程PPT.ppt》由会员分享，可在线阅读，更多相关《软件工程PPT.ppt（47页珍藏版）》请在课桌文档上搜索。

1、软件工程,第15章 软件维护,2/47,一位编程大师曾说过：“哪怕程序只有三行长，总有一天你也不得不对它进行维护。”,3/47,在软件开发过程中始终强调软件的可维护性。原因是，一个应用系统由于需求和环境的变化以及自身暴露的问题，在交付用户使用后，对它进行维护是不可避免的，统计和估测结果表明，信息技术中硬件费用一般占35%，软件占65%，而软件后期维护费用有时竟高达软件总费用的80%，所有前期开发费用仅占20%。许多大型软件公司为维护已有软件耗费大量人力、财力。因此，必须建立一套评估、控制和实施软件维护的机制。,4/47,软件维护的概念,什么是软件维护是指软件系统交付使用以后，为了改正错误或满足

2、新的需要而修改软件的过程 国标GB/T 11457-95给出如下定义 在一软件产品交付使用后对其进行修改，以纠正故障、改进其性能和其它属性，或使产品适应改变了的环境,5/47,1、软件维护分类,根据软件维护的原因不同，可以分为:纠错性维护适应性维护完善性维护预防性维护,6/47,纠错性维护,在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的错误使用，应当进行的诊断和改正错误的过程就叫做纠错性维护。,7/47,适应性维护,在使用过程中，外部环境（新的

3、硬、软件配置）数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。,8/47,完善性维护,在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种维护活动叫做完善性维护。,9/47,预防性维护,为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试，称为预防性维护。,10/47,改错性维护占全部维护工作量的

4、比率已从上世纪80年代初的20%大幅度下降,上世纪90年代初一些公司的产品差错率已接近于零!,各种维护类型和维护工作量的比例,11/47,2、软件维护的特点,结构化维护和非结构化维护差别巨大软件维护的代价高昂维护问题多多,12/47,结构化维护VS非结构化维护,如果采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档，这样维护会相对容易，被称为结构化的维护。如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作变得十分困难，被成为非结构化的维护。,13/47,14/47,结构化维护,在结构化维护的过程中，所开发的软件具有各个阶段的文档，它对于理解和掌握软件的功能、性能、

5、体系结构、数据结构、系统接口和设计约束等有很大的作用。维护时，开发人员从分析需求规格说明开始，明白软件功能和性能上的改变，对设计说明文档进行修改和复查，再根据设计修改程序，并用测试文档中的测试用例进行回归测试，最后将修改后的软件再次交付使用。这种维护有利于减少工作量和降低成本，大大提高软件的维护效率。,15/47,非结构化维护,在非结构化维护过程中，开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等，这样做是十分困难的，也容易产生误解。要弄清楚整个系统，势必要花费大量的人力和物力，对源程序修改产生的后果难以估计。在没有文档的情况下，也不可能进行回归测

6、试，很难保证程序的正确性。,16/47,软件维护的代价高昂,有形代价：1970年软件维护费用占总费用的35%40%；1980年软件维护费用占总费用的40%60%；1990年软件维护费用占总费用的70%80%。,无形代价:占用资源以致延误开发；修改不及时引起用户不满；维护引入新错误，降低了软件质量；等等,维护费用逐年上升,17/47,软件维护的代价高昂,维护费用只不过是软件维护最明显的代价，其他一些还不明显的代价将来可能更为人们关注。其他无形的代价还有：可用的资源被软件维护所占用。未能及时满足用户的维护要求时引起用户不满。维护时改动软件，引入了潜在故障，降低了软件质量。抽调人员从事维护工作，对新

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

8、件定义和开发方法上的不足。软件开发时采用急功近利，还是放眼未来的态度，对软件维护影响极大。一般说来，软件开发若不严格遵循软件开发标准，软件维护就会遇到许多困难。,21/47,维护问题,和软件维护有关的部分问题：理解别人的代码通常是非常困难的，而且难度随着软件配置成分的缺失而迅速增加需要维护的软件往往没有文档、或文档资料严重不足、或软件的变化未在相应的文档中反映出来,22/47,维护问题,当软件要求维护时，不能指望由原来的开发人员来完成或提供软件的解释。由于维护持续时间很长，因此当需要解释软件时候，往往开发人员已经不在附近了绝大多数软件在设计时没有考虑到将来的修改问题软件维护这项工作毫无吸引力。

9、一方面是因为软件维护，看不到什么“成果”，但工作量很大，更重要的是维护工作难度大，软件维护人员经常遭受挫折。,23/47,软件维护的过程,软件维护工作在维护申请提出之前就开始了，它包括：建立维护组织，强制报告和评估的过程；为每个维护申请确定标准化的事件序列；制定保存维护活动记录的制度和有关复审及评估的标准。,24/47,维护组织,维护决策机构,维护管理员,系统管理员,维护人员,配置管理员,维护申请,每个维护申请通过维护管理员转告给系统管理员，系统管理员一般都是对程序(某一部分)特别熟悉的技术人员，他们对维护申请及可能引起的软件修改进行评估，并向修改控制决策机构(一个或一组管理者)报告，由它最后

10、确定是否采取行动。,在维护活动开始之前就明确维护责任是十分必要的，可以大大地减少维护过程中可能出现的混乱。,25/47,维护请求报告(MRF),该报告（表）由要求一项维护活动的用户填写应该用标准的格式来表达维护要求。软件维护人员通常提供给用户空白的维护请求表（报告）即软件问题报告，主要内容：如遇到什么错误，用户详细描述错误出现的现场信息(包括输入数据、列表文件和其他有关信息)；对适应性维护、完善性维护应该给出一个简短的需求规格说明书。最终由维护管理员和系统管理员评价用户用户提出的维护请求表。,一个维护申请被核准后，维护请求表就成为外部文档，视作规划本次维护任务的依据。,26/47,软件维护请求

11、报告(MRF),27/47,软件修改报告(SCR),依据维护请求表，软件组织内部应该制定出一个软件修改报告，它给出下述信息：满足维护请求表中提出的要求所需的工作量；维护要求的性质；维护要求的优先次序；与修改有关的背景数据。在拟定进一步维护计划前，把软件修改报告提交控制决策机构审查批准。,28/47,软件修改报告(SCR),29/47,维护过程,30/47,维护过程,虽然每种维护请求类型着眼点不同，但总的维护方法是相同的。维护工作最后一步是复审,主要审查修改过的软件配置，以验证软件结构中的所有成分的功能，保证满足维护请求表中的要求。依照当前状态，在设计、编码和测试的哪些方面还能用其他方法进行?哪

12、些维护资源可用但未用?这次维护活动中主要(或次要)的障碍有哪些?在维护请求中有预防性维护吗?,31/47,软件维护记录的保存,有效的保存维护记录是极端重要的。保存维护记录的第一个问题就是那些数据值得保存？Swanson为我们指出了下述内容：程序标识、源语句数、机器指令数、使用的程序设计语言、软件安装的日期、自安装以来软件运行的次数、自安装以来软件失败的次数、程序变动的层次和标识、因程序变动而增加的源语句数、因程序变动而删除的源语句数、每个改动消耗的人时数、程序改动的日期、软件工程师的名称、维护要求的标识、维护类型、维护开始和完成的时间、用于维护的累计人时数、与完成的维护相关联的纯收益。应该为每

13、项维护工作都收集上述数据。可以利用这些数据构成一个维护数据库。,32/47,软件维护记录,33/47,评价维护活动,缺乏有效的数据就无法评价软件维护活动。如果已经开始保存维护记录，则可以对维护工作做一些定量度量，至少可以从如下7方面进行评价：每次程序运行平均失败的次数；用于每一类维护活动的总人时数；平均每个程序、每种语言、每种维护类型所必需的程序变动数；维护过程中增加或删除源语句平均花费的人时数；维护每种语言平均花费的人时数；一张维护要求表的平均周转时间；不同维护类型所占的比例；,34/47,软件可维护性即软件被理解、改正、调整和改进的难易程度。可维护性是指导软件工程各个阶段工作的一条基本原则

14、，也是软件工程追求的目标之一对软件可维护性影响的主要因素有：可理解性（understandability）可测试性（testability）可修改性（modifiability）可移植性（portability）,软件可维护性,35/47,可理解性：指理解软件的结构、接口、功能和内部过程的难易程度。提高软件可理解性的措施有：采用模块化的程序结构；书写详细正确的文档；采用结构化程序设计；书写源程序的内部文档；使用良好的编程语言；具有良好的程序设计风格等可测试性：指测试和诊断软件（程序）中错误的难易程度。提高软件可测试性的措施有：采用良好的程序结构；书写详细正确的文档；使用测试工具和调试工具；保存

15、以前的测试过程和测试用例等,36/47,可修改性：指修改软件（程序）的难易程度。修改软件时经常会发生的情况：修改了程序中某个错误的同时又产生新的错误（由程序的修改引起的）；或者在程序中增加了某个功能后，导致原先的某些功能不能正常执行。可移植性：指程序转移到一个新的计算环境的难易程度。影响软件可移植性的因素有：信息隐蔽原则；模块独立；模块化；高内聚低耦合；良好的程序结构；不用标准文本以外的语句等一个可移植的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统的性能,37/47,除了与开发方法的因素有关外，还与下列开发环境的因素有关:是否拥有一组训练有素的软件人员；系统结构是否可理解；是否使

16、用标准的程序设计语言；是否使用标准的操作系统；文档的结构是否标准化；测试用例是否合适；是否已有嵌入系统的调试工具；是否有一台计算机可用于维护。除此之外，软件开发时的原班人马是否能参加维护也是一个值得考虑的因素。,38/47,软件可维护性与软件质量和可靠性一样是难于量化的，然而借助维护活动中可以定量估算的属性，能间接地度量可维护性:察觉到问题所耗的时间；收集维护工具所用的时间；分析问题所需时间；形成修改说明书所需时间；纠错(或修改)所用时间；局部测试所用时间；整体测试所用时间；维护复审所用时间；完全恢复所用时间。,可维护性的度量,39/47,建立明确的软件质量目标和优先级使用提高软件质量的技术和

17、工具进行明确的质量保证审查选择可维护的程序设计语言改进程序的文档进行质量保证审查,提高可维护性的方法,40/47,确定质量管理目标和优先级 可维护的程序应该是可理解的，可修改的和可测试的。在软件开发的每一个阶段都应尽力考虑软件的可维护性。使用提高软件质量的技术与工具设计时，采用模块化程序设计、结构化程序设计等程序设计方法开发中，建立主程序小组，实现严格的组织化管理，职能分工，规范标准选择可维护性高的程序设计语言高级语言比低级语言容易理解，具有更好的可维护性。高级语言，一些语言可能比另外一些语言更容易理解。改进程序文档对于维护人员来说，要重新修改程序编制人员的意图，并对今后可能出现的变化估计，必

18、须依赖于文档。程序文档一定要能及时反映程序的变化，否则将对后续维护人员产生误导。进行质量保证审查 审查可以检测开发和维护阶段发生的质量变化。一旦检测出问题来，就可以采取措施来纠正，以控制不断增长的软件维护成本，延长软件系统的有效生命期。为了保证软件的可维护性，有四种类型的软件审查：在检查点进行复审、验收检查、周期性地维护审查、对软件包进行检查。,41/47,软件修改是一项很危险的工作，对一个复杂的逻辑过程，那怕做一项微小的改动，都可能引入潜在的错误，虽然设计文档化和细致的回归测试有助于排除错误，但是维护仍然会产生副作用。软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误，

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

20、任何修改都应在相应的技术文档中反映出来，如果设计文档不能与软件当前的状况对应则比没有文档更糟。对用户来说，若使用说明中未能反映修改后的状况，那么用户在这些问题上必定出错。一次维护完成之后，再次交付软件之前应仔细复审整个配置，有效地减少文档副作用。某些维护申请不必修改设计和代码，只需整理用户文档便可达到维护的目的。,文档的副作用,45/47,软件维护的管理,软件维护不仅仅是技术性的，还需要大量的管理工作予以配合，才能保证维护工作的质量。,46/47,为了确保维护中所作修改的正确性，消除因不当修改给用户带来不良影响，要求对修改工作持谨慎态度。维护人员应和用户充分讨论，在说明情况、弄清要求的基础上，提出修改意见。,软件维护的管理,47/47,由谁来承担软件维护管理工作一般认为应该由开发人员来维护，因为他们对软件最熟悉，维护起来最方便另一种做法是安排专职维护人员负责维护工作，而非开发人员。这样的好处是开发人员可以集中精力做好开发工作，有利于坚持实施开发标准，有利于保证文档的编制质量。同时专职的维护人员可以深入透彻的分析软件，从而更有利于维护的开展。还有一种较好的做法，安排软件人员开发任务和维护任务的定期轮换。这样可以使软件人员体会到开发和维护工作的具体要求、开发和维护的关系，有利于软件人员的技术水平和软件系统的质量。,软件维护的管理,