第6章 软件维护管理.pptVIP

第六章 软件维护管理 方海光 fanghg@ 数字化学习实验室 第六章 软件维护管理 6.1 软件维护过程及其模型 6.2 软件的可维护性及其度量 6.3 软件维护文档 6.4 用户培训 习题 所谓软件维护就是在软件已经交付使用以后，为了改正错误或满足新的需要而修改软件的过程。在一项维护需求提出之前，与软件维护相关的工作就已经开始了。 根据维护工作的性质，维护活动可以分为以下四种类型： 改正性维护 适应性维护 完善性维护 预防性维护 第六章 软件维护管理 6.1 软件维护过程及其模型 6.1.1 维护组织 6.1.2 维护报告 6.1.3 软件维护过程模型 6.1.4 软件维护工作流程 6.1.5 评价维护活动 6.1.1 维护组织 虽然通常不是必须建立正式的维护组织的，但是对于一个小的软件开发团队而言，非正式地委托维护责任是绝对必要的。 每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由授权人决定应该进行的活动，明确维护责任。在维护活动开始之前就明确维护责任是十分必要的，这样做可以大大减少维护过程中可能出现的混乱。 6.1.2 维护报告 维护需求表是一个由外部产生的文件，它是计划维护活动的基础。软件组织内部应该指定一个软件修改报告，需要列举出的信息如下： 满足维护需求表中提出的要求； 维护需求的性质； 这项需求的优先次序； 与修改有关的事后数据。 6.1.3 软件维护过程模型 软件维护模型随着软件工程的发展在不断的向前发展。20世纪80年代主要存在两类维护模型：一类是面向过程的维护模型；一类是面向业务的维护模型。 随着软件业的发展，人们认识到需要对软件维护进行标准化的重要性，因此，IEEE计算机学会软件工程标准化分委会颁布了IEEE软件维护标准（IEE。该标准详细阐述了管理与执行软件维护活动的迭代过程，该过程模型包括软件维护的输入、处理、控制及输出。 6.1.3 软件维护过程模型 标准指出，应该在规划软件开发时规划软件维护。 问题/更改鉴别、分类与优先级别的确定 维护的可行性分析和维护需求分析 设计阶段 实现阶段 系统测试阶段 验收测试阶段 交付阶段 6.1.4 软件维护工作流程 图6.1 软件维护工作流程图 6.1.5 评价维护活动 缺乏有效的数据就无法评价维护活动。如果已经开始保存维护纪录，则可以从下述七个方面对维护工作进行一些定量度量： 程序运行的平均失败次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所做的程序变动数量； 维护过程中增加或者删除一个源语句所平均花费的人时数； 维护每种语言所平均花费的人时数； 一张维护需求表的平均周转时间； 不同维护类型所占的百分比。 6.2 软件的可维护性及其度量 6.2.1 影响可维护性的因素 6.2.2 软件可维护性的度量 6.2.1 影响可维护性的因素 软件的可维护性,可以简单定义为：维护人员理解、改正、改动或改进这个软件的难易程度。 除了与开发方法有关的因素之外，以下因素对可维护性有重要影响： 软件设计人员是否受到严格的规范化工作培训； 是否采用主流的编程语言； 是否采用主流的操作系统； 是否采用标准化的文档资料结构和文档形成机制； 是否保存规范化的测试资料。 6.2.2 软件可维护性的度量 （1）可理解性 可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度。 （2）可靠性 可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。 （3）可测试性 可测试性表明论证程序正确性的容易程度。 （4）可修改性 可修改性表明程序容易修改的程度。 6.2.2 软件可维护性的度量 （6）效率 效率表明一个程序能执行预定功能而又不浪费机器资源的程度。 （7）可使用性 从用户观点出发，把可使用性定义为程序方便、实用以及易于使用的程度。 （8）间接度量可维护性的方法 采用能够度量的维护活动的属性来间接地估计可维护性。 （5）可移植性 可移植性表明程序转移到一个新的计算环境的可能性的大小，或者表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度 6.3 软件维护文档 对于结构化维护来说，软件维护文档就是对原来已有的分析文档、设计文档、实现文档、测试文档、用户指南进行修改，形成新的开发文档。新的开发文档的组织方式有两种格式： 格式1：在先保存好原有的开发文档之后，直接在原来已有的文档上面修改，修改后形成新的小版本号文档，即在原来版本号中小圆点的右一位或右二位上加1。 格式2：不直接在原来已有的文档上