软件维护培训课件.pptVIP

1.7 软件维护标准文档 可维护性评估 * 1.4.2 一般软件维护步骤 3、进行软件修改 1)由系统管理员提出软件修改请求报告。 2)由有关领导审批请求报告。 3)源程序清单存档。 4)手续完备后，实施软件的修改。 5)软件修改后形成新的文档资料。 6)发出软件修改和使用变更通知。 7)进行软件修改后的试运行。 8)根据运行情况作总结调整并修改文档资料 9)发出软件修改后正式运行通知。 10)软件做新的备份并同定稿的文档资料一起存档。这里的文档主要应包括以下内容护的提请人、审批人、维护人的姓名、维护时间、修改原因、修改的内容、修改后的现状。 * 1.4.2 一般软件维护步骤 * 1.4.2 一般软件维护步骤 4、保存维护记录 1)程序标识。 2)源语句数。 3)机器指令条数。 4)使用的程序设计语言。 5)程序安装的日期。 6)安装程序后运行的次数。 7)安装程序后失效的次数。 8)程序变动的层次和标识。 * 1.4.2 一般软件维护步骤 4、保存维护记录（续） 9)因为程序变动而增加的源语句数。 10)因为程序变动而删除的源语句数。 11)每个改动耗费的人时数。 12)程序改动的日期。 13)软件工程师的名字。 14)维护要求表的识别。 15)维护类型。 16)维护开始和完成的日期。 17)累计用于维护的人时数。 18)与完成的维护相联系的纯效益。 * 1.4.2 一般软件维护步骤 评价维护结果 维护结果的评价建立在相关数据的基础之上，所以，维护的档案记录要做好。 * 1.5 软件维护的副作用 编码修改的副作用 即使是对一个语句的简单修改，例如粗心地将逗号错改为句号，就曾经使美国宇航局的阿波罗宇宙飞船的控制软件失效，几乎造成悲剧性的后果。虽然并非所有的副作用都会造成如此严重的后果，但是修改编码的确可能引入错误，从而导致各种各样的问题发生。 每个程序的编码修改都可能引入新错误、产生副作用。尤其在删除或修改子程序(函数、过程)、标识符、语句标号、逻辑运算符、边界测试条件，以及将设计修改转换成编码修改、为改善执行性能所作的修改和修改文件打开与关闭的格式等情况下，更加容易引入各种各样的错误。 编码修改副作用的范围很广，从回归测试验证期间的检错、纠错到软件运行期间的故障，都有可能源于编码修改而引入的错误。 * 1.5 软件维护的副作用 编码修改的副作用（续） 经常发生修改代码产生副作用的可能有： 1．删除和修改一个子程序 必须查明与此子程序相关的模块和语句，修改删除之前做到有把握时再修改，修改后进行回归测试。 2．删除和改变一个语句标号 （处理同1 ）。 3．删除和改变一个标识符（ 处理同1）。 4．为改进执行性能所作的修改（ 处理同1，附加性能测试）。 * 1.5 软件维护的副作用 编码修改的副作用（续） 经常发生修改代码产生副作用的可能有(续)： 5. 改变文件的打开或关闭 反复检查处理的文件状态和内容的正确性。 6．改变运算逻辑符 反复检查计算结果和算法正确性。 7．把设计的修改翻译成代码的修改 修改后，应立即撤消这个修改，并作回归测试。 8．对边界测试所作的修改 * 1.5 软件维护的副作用 数据修改的剧作用 所谓数据修改副作用是指，维护期间对数据结构本身或其个别域进行修改时，很有可能使得软件设计与数据结构不匹配，从而导致软件错误。 ． 最容易产生数据修改副作用的修改有：增加或减少数组的大小，修改全局数据，重新初始化控制标志或指针，重新排列输入输出程序或过程(函数或子程序)中自变量的次序等。 为了减少数据修改的副作用，应当设计完善的文档资料来反映修改状态。这样的文档资料应该详细描述数据结构，并且提供将数据域、记录、文件及其它结构与软件模块联系起来的交叉对照表。 * 1.5 软件维护的副作用 数据修改的副作用（续） 经常发生的如下修改产生副作用的问题： 1．重新定义局部或全局常量， 2．重新定义记录或文件格式； 3．增大或减小一个数组、高阶数据结构的大小，全程数据； 4．重新初始化控制标记或指针， 5．重新排列I／O或子程序的自变量。 为避免修改数据的副作用，一是要有严密的数据要求与描述的文件，二是严格记录修改并进行回归测试。 * 1.5 软件维护的副作用 文档资料修改的副作用 如果没有将源程序或数据结构的任何修改在相应的文档资料中予以反映，就会产生文档资料修改副作用。 无论是修改数据流、软件结构和模块过程，还是修改其它有关的属性，都应该更新相关的技术文档资料以反映出这种修改。不能正确地反映软件当前状态的文档资料甚至比没有文档资料还要糟糕，因为它将导致维护过程中对软件性能结构的误解，并由此引入错误、造成软件失效。 另一方面，最终用户希望描述软件用法的文档资料是完善的，任何对软件的修改若没有反