1、第八章 维 护,软件维护的定义维护的特点维护过程可维护性软件质量,关于维护阶段,软件维护是软件生命周期的最后一个阶段，软件 维护就是在软件已经交付使用之后，为了改正错误或 满足新的需要而修改软件的过程。,软件工程方法学的主要目的就是要提高软件的可 维护性，减少软件维护所需要的工作量，降低软件系 统的总成本。,软件维护工作,软件交付使用后，有四项主要的维护工作：,改正性维护 诊断和改正错误的过程。适应性维护 是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。完善性维护 用户提出的一般性的改进意见。预防性维护 为了改进未来的可维护性和可靠性，或为了给未来的改进奠定更好
2、的基础而修改软件。,结构化维护和非结构化维护,结构化维护和非结构化维护,如果软件配置的唯一成分是程序代码，那维护活动 从艰苦地评价程序代码开始，而且常常由于程序内部文 档不足而使评价更困难。诸如软件结构、全程数据结构、 系统接口、性能和（或）设计约束等微妙的特点是难于 搞清的，而且常常误解了这一类特点。,如果有一个完整的软件配置存在，那么维护工作从 评价设计文档开始，确定软件重要的结构特点、性能特 点以及接口特点；估量要求的改动将带来的影响，并且 计划实施途径。,维护代价,维护的代价有时是无形的，应引起关注：,因为可用的资源必须供维护任务使用，以至于耽误甚至丧失了开发的良机；当看来合理的有关改
3、错或修改的要求不能及时满足是将引起用户的不满；由于维护是的改动，在软件中引入了潜伏的故障，从而降低了软件的质量；当必须把软件工程调去从事维护工作时，将在开发过程中造成混乱。,维护代价,维护工作的劳动可以分成：,生产性活动 分析评价，修改设计和编写程序代码非生产性活动 理解程序代码的功能，解释数据结构，接口特点和性能限度,维护代价,维护工作量的一个模型：,M = P + K * exp(c - d),M: 维护用的总工作量 P: 生产性工作量 K: 经验常数 c: 复杂程度 d: 维护人员对软件的熟悉程度,维护的问题,与软件维护有关的部分问题：,理解别人写的程序通常非常困难；需要维护的软件往往没
4、有合格的文档，或者文档资料显著不足；当要求对软件进行维护时，不能指望有开发人员给我们仔细说明软件；绝大多数软件在设计是没有考虑将来的修改。,维护过程,维护组织组织管理整个软件维护过程。,维护组织,维护报告,维护阶段,递交,维护,维护报告,维护报告包括下述信息：,满足维护要求表中提出的要求所需要的工作量；维护要求的性质；这项要求的优先次序；与修改有关的事后数据。,维护事件流,维护类 型识别,估计错误程度,问题分析,严重,分配的人员,评价 优先度,开始分析,高,计划改正,维护 任务,错误改正目录,不严重,分配的人员,复审,维护 要求,修改后的 软件配置,保存维护纪录,（1）程序标识； （2）源语句
5、数； （3）机器指令数； （4）使用的程序设计语言； （5）程序安装的日期； （6）自从安装以来程序运行的次数； （7）自从安装以来程序实效的次数； （8）程序变动的层次和标识； （9）因程序变动而增加的源语句数； （10）因程序变动而删除的源语句数； （11）每个改动耗费的人时数；（12）程序改动的日期； （13）软件工程师的名字； （14）维护要求表的标识； （15）维护类型； （16）维护开始和完成的日期； （17）累计用于维护的人时数； （18）与完成的维护相联系的纯效益。,评价维护活动,可以从以下七个方面评价维护工作：,每次程序运行平均实效的次数；用于每一类维护活动的总人时数；平均每
6、个程序、每种语言、每种维护类型所做的程序变动数；维护过程中增加和删除一个源语句平均花费的人时数；维护每种语言平均花费的人时数；一张维护要求表的平均周转时间；不同维护类型所占的百分比。,可维护性,软件可维护性可以定性的定义为：维护人员理解、 改正、改动和改进这个软件的难易程度。,可维护性特性,决定可维护的因素,可理解性 表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度；可测试性 良好的文档对诊断和测试是至关重要的。可修改性 耦合、内聚、局部化、控制域与作用域的关系等等，都影响软件的可修改性。,决定可维护的因素,可靠性 程序按用户的要求和设计目标，在给定时间内正确执行的概率。平均失效间
7、隔时间 MTTF度量 平均修复时间 MTTR有效性 A,可移植性 表明程序转移到一个新的计算环境的可能性大小。 效率 表明一个程序能执行预定功能而又不浪费机器资源的程度。 可使用性 从用户观点出发，程序方便、实用、易用的程度。,文 档,文档是影响软件可维护性的决定因素。,软件系统的文档分为两类：,用户文档 主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档 主要描述系统设计、实现和测试等各方面的内容。,总的文档要求,软件文档应该满足下述要求：,必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用；必须描述怎样安装和管理这个系统；必须描述系统需求和设计；必须描述系统
8、的实现和测试，以便使系统成为可维护的。,用户文档,用户文档至少应该包括下述几方面的内容：,功能描述 说明系统能做什么；安装文档 说明怎样安装这个系统以及怎样使系统使用特定的硬件配置；使用手册 简要说明如何着手使用这个系统；参考手册 相近描述用户可以使用的所有系统设施以及它们的使用方法；操作员指南 说明操作员应该如何处理使用中由系统规模决定。,可维护性复审,可维护活动后的软件系统或产品应是可以复查的。,应注意以下几点：,维护应该针对整个软件配置，不应该只修改源程序代码；每当对数据、软件结构、模块过程或任何其它有关的软件特点做了改动时，必须立即修改相应的技术文档；如果对软件的可执行部分的修改没有及
9、时反映在用户文档中，则必然会使用户因为受挫折而产生不满；如果在软件在此交付使用之前，对软件配置进行严格的复审，则可以大大减少文档的问题。,软件质量软件产品满足规定的和隐含的与需求能力有关特征、 特性的全体。包括：1） 软件产品质量满足用户要求的程度；2） 软件各种属性的组合程度；3） 用户对软件产品的综合反映程度；4） 软件在使用过程中满足用户要求程度。,软 件 质 量,软 件 质 量,软件质量特性定义一个软件的质量，就等价于为该软件定 义一系列质量特性。它反映了软件的本质。 （所有描述计算机软件优秀程度的特性的组合）,软件可靠性衡量在规定的条件和时间内，软件完成规定功能的能力。表明了一个程序
10、按照用户的要求和设计的目标，执行其功能的正确程度 。,McCall质量度量模型框架,质量要素,评价准则,度量,度量,度量,面向管理者的软件质量,面向技术、决定产品质量的软件属性,可以量化度量的软 件属性,可以交叉,McCall质量要素模型,产品运行,产品 转移,产品 修正,互连性可移植性复用性,可维护性 可测试性 灵活性,正确性 可靠性 可使用性 效率 完整性,1.预测型：利用定量或定性的方法，对软件质量的评价值进 行估计，以得到软件质量比较精确的估算值。 分为 尺度度量：适用于一些能够直接度量的特性。定量度量：适用于一些间接度量的特性。2.验收型：在软件开发各阶段的检查点。对软件的要求质量
11、进行确认性检查的具体评价值，可以看作是对预测型 度量的一种确认。,软件质量特性度量,技术评审 是以提高软件质量为目的的技术活动。设计质量评审：设计说明书要符合用户要求；程序质量评审：程序应按照设计说明书的规定正确执行。,评审对象包括软件规格说明书概要设计说明书详细设计说明书数据要求规格说明,软件技术评审,软件结构* 功能结构数据结构（数据名定义、数据项及之间的关系）；功能结构（功能名、定义、功能、子功能及之间关系）；数据结构与功能结构的一致性。* 功能的通用性反复出现的功能。,评 审 内 容,评 审 内 容,与运行环境的接口* 硬件： 与硬件的接口约定* 其他软件：与上层软件接口与同层软件接口与下层软件接口,评 审 内 容,变更的影响* 与运行环境的接口* 在每项设计工程规格内的影响* 在设计工程相互间的影响,小 结,软件维护的定义维护的特点维护过程可维护性软件质量,
