《软件工程》教学课件CH6 软件维护.ppt

《软件工程》 软件维护 陈巧丽 维护机构 Swanson给出了下述的项目表： （1）程序名称； （2）源程序语句条数； （3）机器代码指令条数； （4）使用的程序设计语言； （5）程序的安装日期； （6）程序安装后的运行次数； （7）与程序安装后运行次数有关的处理故障的次数； （8）程序修改的层次和名称； Swanson给出了下述的项目表： （9）由于程序修改而增加的源程序语句条数； （10）由于程序修改而删除的源程序语句条数； （11）每项修改所付出的“人时”数； （12）程序修改的日期； （13）软件维护人员的姓名； （14）维护申请报告的名称； （15）维护类型； （16）维护开始时间和维护结束时间； （17）用于维护的累计“人时”数； （18）维护工作的净收益。 6.3.5 评价维护活动 缺乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。至少可以从下述7个方面度量维护工作： （1）每次程序运行时的平均出错次数； （2）用于每一类维护活动的总“人时”数； （3）每个程序、每种语言、每种维护类型所做的平均修改数； （4）维护过程中，增加或删除每条源程序语句花费的平均“人时”数； （5）用于每种语言的平均“人时”数； （6）一张维护申请报告的平均处理时间； （7）各类维护类型所占的百分比。 软件维护的副作用 什么是软件维护的副作用 由于软件被修改而导致的错误或其他多余动作的发生，称为是软件维护的副作用。 软件副作用的类型 修改代码的副作用 修改数据的副作用 修改文档的副作用 修改编码的副作用 （1）对子程序的删除或修改； （2）对语句标号的删除或修改； （3）对标识符的删除或修改； （4）为改进程序执行性能所做的修改： （5）改变文件的打开或关闭； （6）对逻辑运算符的修改； （7）把设计的修改翻译成程序代码的修改； （8）对判定的边界条件所做的修改。 为确保编码修改没有引入新的错误，应进行严格的回归测试。一般情况下，通过回归测试，可以发现并纠正修改编码所带来的副作用。 修改数据的副作用 （1）重新定义局部常量或全程常量； （2）重新定义记录格式或文件格式； （3）改变一个数组或高阶数据结构的大小； （4）修改全程变量； （5）重新初始化控制标记或指针； （6）重新排列输入输出或子程序的自变量。 修改数据的副作用可以通过完善的设计文档来加以限制。这种文档描述了数据结构，并且提供了一种把数据元素、记录、文件及其它结构与软件模块联系起来的交叉对照功能。 修改文档的副作用 维护应该着眼于整个软件配置，而不只是源程序代码的修改。如果源代码的修改没有反映在设计文档或用户文档中时，就会发生文档的副作用。 每当对数据流图、软件结构、模块算法过程和其它有关的特征进行修改时，必须同时对相应的文档资料进行更新。 在软件再次交付使用之前，对整个软件配置进行评审将大大减少文档的副作用。实际上，某些维护申请的提出只是由于用户文档不够清楚。这时，只需对文档进行维护即可，并不要求修改软件设计或源程序。 谢谢使用 本课件! 维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息： （1）满足维护要求表中提出的要求所需要的工作量； （2）维护要求的性质； （3）这项要求的优先次序； （4）与修改有关的事后数据。 在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。 6.3.3 维护的事件流 ?  图6.3描绘了由一项维护要求而引出的一串事件。1、首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误（即改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。 从图6.3描绘的事件流看到： 2、对改（校）正性维护要求的处理，从估量错误的严重程度开始。如果是一个严重的错误（例如，一个关键性的系统不能正常运行），则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排。 3、适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样，如果一项维护要求的优先次序非常高，可能立即开始维护工作。 4、不管维护类型如何，都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、单元测试和集成测试（包括使用以前的测试方案的回归测试），验收测试和复审。不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检