南京大学-软件工程-21-软件维护与演化.ppt

总结 软件维护与一般工程领域的维护活动不同，软件维护主要是进行修改（尤其是需求变更），而不是进行零件保养、维修与替换 虽然软件开发是软件工程的主要关注点，但软件维护耗费了更多的成本，所以需要在软件开发阶段进行一些预备工作以降低软件维护阶段的成本 软件演化式的开发模糊了开发与维护的边界，既解决了软件开发周期太长的问题，又降低了“修改”所导致的软件质量下降的速度，延长了整个产品的有效生命周期 软件维护与开发中常用的专门技术有：遗留软件处理、逆向工程和再工程 主要内容 维护 软件维护的主要工作是“修改” 软件维护代价高昂 软件维护的过程 演化 软件维护与演化的技术 软件维护过程 步骤1 问题/修改的标识、分类与划分优先级 该步骤的主要任务是进行变更管理（Change Management）： 1. 用户、客户或其他人员提出变更请求； 2. 维护人员为变更请求建立变更记录（Change Record），赋予标识，进行变更类别分类，确定其优先级。 3. 初步评估变更的可能影响，并据此确定是否接受该变更请求。 4. 如果决定执行变更，就为其安排修改时间。通常多个小的修改会安排到一个时间内批量完成。 步骤 2 分析 该步骤的主要任务是为后续的修改（设计、实现、测试、交付发布等）确定一个基本的规划，包括2个阶段： 步骤2.1 可行性分析。 该步骤的任务是提出候选方案，并分析方案的可行性，建立可行性报告。 可行性报告的内容包括：变更的影响范围、候选方案、需求变化分析、对安全性和保密性的影响、人的因素、短期和长期成本、修正的价值与效益等。 步骤2.2 详细分析 该步骤的任务是准确定义修改的需求，标识需要修改的元素、标识修改中的安全与保密因素、确定一个测试策略和建立一个实现计划。 步骤 3 设计 该步骤的主要任务是依据变更分析的结果和已有系统的信息，完成对系统设计的变更。 具体工作包括：标识被影响的软件模型、修改软件设计文档、为新的设计创建测试用例、更新回归测试集、更新需求文档。 在进行完善性维护和适应性维护时，设计步骤要针对新的功能需求执行一个完整的详细设计过程。 在进行修正性维护时，设计要防止程序修改带来连锁的负面效应。 在进行预防性维护时，设计要重点关注软件结构的质量，以此为依据修改程序代码和软件系统结构。 步骤 4 实现 该步骤的主要任务是根据变更的设计，完成代码实现。 具体工作包括：编码与单元测试、集成新修改代码、集成测试、风险分析和代码评审。 步骤 5 回归测试 该步骤的主要任务是确保对变更的修改不会带来连锁的负面效应，要保证系统仍然能够满足其他未被修改的需求。 具体工作包括：针对变更情况进行功能测试和界面测试、对整个系统进行回归测试、验证系统是否准备好进行验收测试。 步骤 6 验收测试 该步骤的主要任务是由用户、客户或客户指定的第三方来验证系统是否满足用户的变更请求。 具体工作包括：针对变更请求的功能测试、针对用户使用环境的兼容性测试、对整个系统进行回归测试。 步骤 7 交付 该步骤的主要任务是将修正的系统发布用于安装和运营。 具体工作包括：进行配置审计；通知用户团体、为了备份系统而开发一个阶段性版本、在客户的设施上进行安装和培训。其中配置审计是要通过配置管理系统确定一个系统的发布包，包括文档、软件程序、培训文档、以及其他相关文档。 主要内容 维护 软件维护的主要工作是“修改” 软件维护代价高昂 软件维护的过程 演化 软件维护与演化的技术 维护 VS 演化 经常被作为等价词使用，意指软件交付的“修改”活动 但有时软件演化拥有特殊的含义，意指软件初期交付后，一边“修改”已有软件，一边开发新的增量需求软件部分 即演化有时是开发与维护的综合 维护 开发 History 1960s – 1970s Inclusion of maintenance in waterfall lifecycle after delivery of the software product. Perception that post-delivery activities only consisted of bug fixes and minor adjustments. 1970s Lehman postulated the initial laws of program evolution. Stressed the need for continuous evolution due to changes in the software’s operational environment. Late 1970s – 1980s Initial process models that handled change requests. 1990s