改正性维护

为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的错误进行的诊断和改正错误的过程

改正性维护是指为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的错误，应当进行的诊断和改正错误的过程。

工作原理

改正性维护是在软件运行中发生异常或故障时进行的维护工作。在软件交付使用后，由于开发时测试的不彻底、不完全，必然会有一部分隐藏的错误被带到运行阶段来。这些隐藏下来的错误在某些特定的使用环境下会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应进行的诊断和改正错误的过程，是改正性维护。例如，改正性维护可以是改正原来程序中开关使用的错误；解决开发时未能测试各种可能情况带来的问题；解决原来程序中遗漏处理文件中最后一个记录的问题等。

目的

改正性维护作业的目的是改正软件中原有的错误、缺陷和不足，以完善原有的软件。它从接到错误申报开始。首先，要收集和占有与错误申报有关的信息或数据，然后据此判断错误申报是否应被接受。由于可能会有不正确的错误申报，因此改正性作业中还包括最终不导致修改软件的作业。根据资料统计，操作系统和数据库系统等基本软件的错误申报中，只有1/3~1/5与软件中的错误有关。用户提出的错误申报大多数是因文档（如操作使用手册）质量不高引起的。因此也属于软件错误范畴。判断出软件确有错误后，接着要分析错误原因，确定修改方案。在确定修改方案时，应尽可能地使修改对程序的其它部分影响最小。修改后，不仅要确认申报的错误已经改正，还要检查所做的修改是否向软件引进了新的错误。最后，还要相应地修改有关文档。

改正性维护中，各个阶段的工作量大致如下：收集与错误有关的信息占14%，错误原因分析占41%；修改程序占27%；检查修改是否正确占21%；相应地修改文档6%。

软件改正性维护度量

软件改正性维护度量涉及维护服务质量的许多方面。需要将维护组处理的软件系统失效和维护服务失效区别开来，后者指的是维护不能提供满足指定标准或合同需求的修复的情况。因此，软件维护度量的分类如下：

软件系统失效密度度量——同对改正性维护要求的程度有关，基于软件系统常规运行期内识别的失效记录。

软件系统失效严重性度量——同改正性维护组修复的软件系统失效的严重性有关。

维护服务失效度量——同维护服务不能按时完成失效改正或改正失败的情况有关。

软件系统可用性度量——同顾客通过一段时间认识到软件系统的服务不可用或只有部分可用引起的麻烦的程度有关。

1．软件系统失效密度度量

这里介绍的软件系统失效密度度量与故障数和/或故障的加权数相关。维护任务的规模是通过被维护软件的代码行数或通过功能点评估来测量的。这些度量的数据源都是软件维护报告。

2．软件系统失效严重性度量

该组度量检测被维护软件中增加的严重失效的有害情况。结果可能促使软件系统的全部或部分重新测试。测量的事件与给顾客造成的麻烦或损害（代表顾客观点的）或解决失效所需的资源（代表维护组的利益）有关。这里介绍的度量可用于两个目的，即如何对顾客经受的麻烦或损害的严重性使用权重或维护人员所需资源的范围使用权重。软件系统失效的平均严重性（Average Severity ofSoftware System Failures，ASSSF）指的是一年（或半年或一个季度，如果合适的话）内检测到的软件失效数：

3．维护服务失效度量

如上提到的，维护服务可能失败，可能是因为它们不能按时完成失效改正，或者是执行的改正失败并需要一次重复的改正。

如果一个顾客召唤同先前一次召唤之后假设已经解决了的软件失效问题有关，它通常被看成是维护服务失效。在实际使用中，许多机构把重复召唤的时间框限制在三个月内，然而这个时期的长短可能由于故障的类型或一些其他机构准则不同而不同。维护重复修复失效（Maintenance Repeated repair Failure，MRepF）度量的定义如下：

4．软件系统可用性度量

用户度量区分：

完全可用——所有的软件系统功能都正常地运行。

关键可用——没有关键功能的失效（但是不关键的功能可能失效）。

整体不可用——所有的软件系统功能都失效。

所有可用性度量的数据源都是用户故障记录。后者说明了损害的程度（不关键失效、关键失效和整个系统失效）和每个失效持续时间（小时）。

全国各地天气预报查询

上海市

市辖区

云南省

临沧市

云南省