十：软件维护.ppt

对代码分段构建和测试，最后合在一起形成更大的部分，是目前常用的测试策略。 * 非结构化维护 如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作将变得十分困难 结构化维护 采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档 维护时，开发人员从分析需求规格说明开始，明白软件功能和性能上的改变，对设计说明文档进行修改和复查，再根据设计修改进行程序变动，并用测试文档中的测试用例进行回归测试，最后将修改后的软件再次交付使用。 * 软件维护概述 软件维护的特征 软件维护实施 软件可维护性 软件维护的副作用 逆向工程和再工程 提纲 非结构化维护 如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作将变得十分困难 结构化维护 采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档。 软件维护的特征 不按照科学软件工程方法来开发软件造成的后果就是使维护成为一项复杂而艰难的工作。 下面是一些典型的问题： 无法追踪软件的整个创建过程 无法追踪软件版本的进化过程 理解别人的程序非常困难 得不到开发人员的帮助 软件配置不完整或不正确 分析和设计的缺陷 维护工作让人没有成就感 维护可能存在的问题 影响维护工作量主要有如下因素: 系统规模大小 程序设计语言 系统年龄 数据库技术的应用 先进的软件开发技术 影响软件维护工作量的因素 软件维护概述 软件维护的特征 软件维护实施 软件可维护性 软件维护的副作用 逆向工程和再工程 提纲 从本质上看，软件维护是修改和压缩了的软件定义和开发的过程 软件维护要有严格的规范，才能保证软件的质量 软件维护的实施过程如下： Step 1: 建立维护组织 Step 2: 制定维护申请报告 Step 3: 进行维护并做详细记录 Step 4: 复审 软件维护实施 在维护活动开始之前就明确维护责任是十分必要的，这样可以大大减少维护过程中可能出现的混乱。 软件维护组织 维护申请单如果是纠错性维护，应填写软件问题报告单。由用户填写的外部文件，提供错误情况说明（输入数据，错误清单等），或修改说明书等。 其他种类的维护，要填维护申请单 维护申请单将由维护管理员和系统管理员来研究处理。他们应相应地做出软件修改报告 软件维护申请 软件修改报告要求说明： 满足维护申请单中提出的要求所需的工作量 维护申请的性质。 这项申请的优先次序。 与修改有关的事后数据，也就是修改后的结果。 软件修改报告 维护过程 程序标识、源语句数、机器指令数、使用的程序设计语言、 软件安装的日期、自安装以来软件运行的次数、自安装以来软件失败的次数、 程序变动的层次和标识、因程序变动而增加的源语句数、因程序变动而删除的源语句数、每个改动消耗的人时数、 程序改动的日期、软件工程师的姓名、 维护要求的标识、维护类型、维护开始和完成的时间、 用于维护的累计人时数、与完成的维护相关联的纯收益。 维护档案记录 维护记录的保存和维护的评价是两个相关的过程， 只有保存了软件维护的记录，才能对维护的过程进行评审。 维护评价 软件维护概述 软件维护的特征 软件维护实施 软件可维护性 软件维护的副作用 逆向工程和再工程 提纲 定义： 软件能够被理解、改正、适应和完善，以适应新的环境的难易程度，是软件产品的一个重要质量特性，是软件开发阶段各个时期的关键指标 软件可维护性 设计、编码和测试时漫不经心，软件配置(一个软件在生存周期内，它的各种形式、各种版本的文档与程序的总称)不全，都会给维护带来困难。 软件开发时的原班人马是否能参加维护也是一个值得考虑的因素。 影响软件可维护性的因素 是否拥有一组训练有素的软件人员？ 系统结构是否可理解？ 是否使用标准的程序设计语言? 是否使用标准的操作系统? 文档的结构是否标准化? 测试用例是否合适? 是否已有嵌入系统的调试工具? 是否有一台计算机可用于维护。 影响软件可维护性的环境因素 用于衡量可维护性的软件特性七个方面 软件可维护性的度量 可理解性指对软件的结构、接口、功能、内部过程理解的难易程度。 程序模块化的结构特性、详细一致的设计文档、结构化设计的模块化、源代码的选取结构化语言描述、采取良好的设计风格都对软件可理解性起决定作用。 度量方法：90 - 10 Test ——读源程序10分钟，能否默写出90%？ 1.可理解性 可靠性：表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率,是软件整体质量的一个重要因素。 MTBF=MTTF+MTTR MTBF： 是平均失败间隔时间(Mean Time Between Failure)； MTTF： 是平均无效间隔时间(Mean Time to Failure)