IT软件项目维护管理

第9章IT软件项目维护管理9.1软件项目维护概述

9.2软件项目维护成本

9.3项目可维护性的度量

9.4软件再造工程

2/4/202319.1软件项目维护概述9.1.1软件项目维护管理理论

9.1.2软件项目发展动力学

9.1.3软件项目维护的特点

2/4/202329.1.1软件项目维护管理理论IT软件项目维护主要包括以下工作完善性维护：在不改变系统整体功能的前提下，提高和改善某部分的功能。一般占65%。适应性维护：调整系统使之能适应一个已经发生变化的系统环境。一般占17%。纠错性维护：纠正以前未发现的系统错误。一般占17%。预测性维护：为了提高软件项目的可维护性、可靠性等，为以后进一步改善软件项目功能和使用而进行的活动。一般占1%。2/4/202339.1.1软件项目维护管理理论图9.2软件项目维护的主要过程需求变化冲突分析化维护计划功能更改系统发布完善维护适应性维护纠错维护2/4/202349.1.1软件项目维护管理理论在实际项目开发中，要想提高员工维护的积极性，可以考虑从以下几个方面来进行：把项目目标与组织目标相结合。

把项目维护报酬与工作相结合。

使维护人员参与到开发小组中去。

制定一个完善的维护计划，并允许维护人员决定系统是否该重新设计。

使维护人员介入到系统目标准备、测试等工作中去。

2/4/202359.1.2软件项目发展动力学（1）项目发展动力学是Lehman和Belady(1985)进行系统变化研究，并在该领域里从事的主要工作。表9.1Lehman规律

规

律定义

连续变化规律在不断变化的环境里，软件必须要发生变化，不然，该软件的用途就变得会越来越小

复杂度增加规律作为一个不断发展和变化的软件，其结构将会变得更加复杂，必须引入外在的资源来保持和简化这个结构

大规模软件发展规律

软件的发展变化是一个自我调节的过程，系统属性（如规模、版本发布间隔时间、发现的错误数等）对每个系统版本来说都应当是大致不变的

组织稳定规律在软件的整个生命周期里，它的发展变化速度大致是不变的，并且与投入系统开发的资源无关保持一致规律在软件的整个生命周期中，每个版本增加的系统变化量都是大致相当的

2/4/202369.1.2软件项目发展动力学（2）连续变化规律表明系统维护是一个必须的过程。错误修复只是维护活动的一小部分工作。一个设计好的软件系统必须是可维护的。复杂度增加规律说明随着系统的变化，软件原有的整体结构将不断退化。如果希望改变这种结构退化的趋势，就必须增加一些额外的成本，有时这种成本将成为是否实施软件改变的重要影响因素。因此，减少结构退化的成本必须是可以接受的，而且，维护过程可能要包括系统结构的重新设计。组织稳定规律说明大多数大规模的软件项目都处于一种“饱和”的状态。即任何一个资源或人员的变化都会对系统的长期发展产生不利的影响。2/4/202379.1.2软件项目发展动力学（3）大规模软件发展规律表明大型系统在开发的早期阶段就有了自身的动态性和可调节能力，即决定了系统维护过程大致的趋势和系统可能变化的数量，维护管理不能也不应该做系统变化所要求的所有事情。由于变化是针对整个系统的，所以变化也会引入新的错误到系统中，这时就需要更多的变化来纠正这些错误，一旦系统超过了一定的规模，这些变化所起的作用如同惯性系统一样，同时也阻碍着更大的变化，这些变化导致系统的可靠性降低。所以在任何时候实施的变化数量都是有限的。系统变化的过程在一定程度上受组织的决策过程所控制。保持一致规律关心的是软件系统每个版本发行时的变化增加量，变化量保持适度的增加是必须的。2/4/202389.1.3软件项目维护的特点

软件项目开发过程对软件的维护有较大的影响，如果不遵循软件工程的方法开发软件项目，软件往往只有程序而没有文档，这样软件维护工作是非常困难的。这是一种非结构化的维护。若采用软件工程方法进行软件项目开发，则各个阶段都有相应的文档，使软件容易进行维护工作，这是一种结构化的维护。无论哪种维护方式，软件项目的维护都存在着一定的困难，它主要是由软件需求分析和开发方法的缺陷造成的。困难主要表现在如下几个方面：读懂别人的程序一般是非常困难的。文档的不一致性。软件开发和软件维护在人员和时间上的差异。软件维护在大多数人看来是一件没有挑战性的工作。

2/4/202399.2软件项目维护成本

9.2.1影响软件项目维护成本的因素

9.2.2软件项目维护成本的预测

2/4/2023109.2.1影响软件项目维护成本的因素一般来说，软件项目维护成本很难预测，因为产生维护成本与很多产品、过程和组织因素有关。而且不同应用领域的项目维护成本存在很大的差别。从多数软件项目经验看，在系统设计和开发中投入大量的人力物力是减少维护成本的最好办法。影响项目的维护成本主要因素分为技术因素和非技术因素。非技术因素一般包括应用领域、员工稳定性、软件生命周期、外部环境、硬件的稳定性等方面。

技术因素主要包括模块的独立性、编程语言、编程风格、软件有效性和测量、文档的质量和配置管理的技术等。

2/4/2023119.2.1影响软件项目维护成本的因素系统1系统205101520253035404550

开发及维护成本开发成本维护成本从多数的软件项目经验看，在系统设计和开发中投入大量的人力物力是减少维护成本的最好办法。如果系统开发成本增加的百分比与系统维护成本减少的百分比相当的话，增加开发成本将会导致整个系统成本的减少。上图表明了系统开发成本和维护成本之间关系。通常维护成本很难估计，因为它们与产品、过程及组织因素有关。2/4/202312影响软件项目维护成本的因素——非技术因素应用领域：如果应用软件系统能够很清楚地定义并且很好地理解，则系统的需求就可以完全准确定义，适应性维护就相对较少。而如果一个应用软件是在全新的领域中进行的，则原始的需求就可能随着开发人员不断获得该领域的经验而经常变化。员工稳定性：如果是系统开发人员负责维护本人负责开发的部分，维护成本将大大减少。软件生命周期：随着软件生命周期的进展，相应的软件或硬件已不适应，被抛弃的部分变多，维护成本相应增加。外部环境：如果一个软件依靠它的外部环境，则当外部环境发生改变时，软件也要发生相应的改动。如：税法的改变，要求相应的工资等程序模块要发生变化。硬件的稳定性：软件和程序需要不断更新以使能用新的硬件来取代过时的硬件，因此也会发生相应的维护费用。2/4/202313影响软件项目维护成本的因素——技术因素模块的独立性：修改一个模块时不影响其他模块的功能。编程语言：用高级语言编写的程序一般比用低级语言编写的程序易于理解和维护。编程风格：采取易于理解的方式编写的软件更容易修改和维护。软件有效性和测量：一般花在软件有效性验证和测量的时间越长，软件潜在的错误就越少。文档的质量：如果软件有清楚、完全并且简洁的文档支持，软件和程序也会相对好读懂，维护成本相对较低。配置管理的技术：维护成本的一个重要组成部分是对系统所有文档的保存，有效配置管理技术能帮助控制这些成本。2/4/2023149.2.2软件项目维护成本的预测(1)年变化冲突(ACT)的定义：软件产品一年中变化资源(可以是增加的也可以是减少的)在总资源中所占的比例。

Boehm对维护成本的估计方法是采用年变化冲突(ACT)和开发时的估计或者实际成本(以人月表示)来求得软件维护的年成本。在Boehm模型中，维护成本的计算公式为：

AME=ACT*SDT其中：AME是年维护成本；

SDT是项目开发时间，以人月(PM)为基本单位；

ACT是年变化冲突。如：一个软件项目需要236PM开发并且估计大概有15%的ACT，则基本的维护成本预测值为：

AME=0.15*236=35.4PM2/4/2023159.2.2软件项目维护成本的预测(2)上面的公式给出了项目维护成本的一个大概评估，它是进行进一步精确计算的基础。进行精确计算，需要考虑项目过程、项目产品和人员因素等。维护成本预测可以通过判断每个影响成本因素的重要性，选择大概的权重，然后再进行提炼。基本的维护成本预测公式可以通过每个因素的影响权重来修正成本预测。2/4/2023169.2.2软件项目维护成本的预测(3)例如：在上面的例子中，对维护成本影响最大的因素有：可靠性（RELY），可靠性必须高有应用开发及编程语言经验的开发人员(AEXP和LEXP)为开发系统所用的编程方法（MODP）等。这些因素的权重分别是：RELY:1.10AEXP:0.91LEXP:0.95MODP:0.72通过应用以上的权重，计算最初的维护成本估计值：AME=35.4*1.10*0.91*0.75*0.72=24.2PM2/4/2023179.2.2软件项目维护成本的预测(4)

IT软件项目管理和其他项目管理相比，具有很大的独特性。生产无形的产品

过程没有明显的划分大都是“一次性”的人力消耗型项目2/4/2023189.3项目可维护性的度量（1）

维护度量标准并不测量系统某个特定变化的成本，也不预测某个组件是否应该维护。它是建立在软件的可维护性与复杂性相关的基础上的。软件可维护性是指软件能够被理解、改正、适应和完善，以适应新的环境的难易程度。软件项目最终的可维护性受许多因素的影响，从而度量的方法也不相同。目前对项目可维护性的度量的方法主要有：McCabe在1976年提出的“曲线图技术”：假设程序的复杂性不在于程序的大小而在于程序的判断结构。Halstead在1977年提出的“参数法”：参数有算子的数量、操作数的数量、算子使用的总频率、操作数使用的总频率等。2/4/2023199.3项目可维护性的度量（2）Gilb提出的间接估算可维护性法：提出了一些与可维护工作量有关的可维护性度量。主要有：问题确定时间管理延迟时间维护工具收集时间问题分析时间规格说明修改时间改正或修改活动时间局部测试时间全局测试时间维护评审时间整个恢复时间2/4/2023209.4软件再造工程

软件再造工程：在项目的生命周期中，存在这样一个阶段，对软件系统进行增量变化时，其成本非常高，以至于我们要么抛弃并重新编制或者完全（或部分）地设计其结构，这就是软件再造工程。在考虑是否要进行“软件再造工程”时，主要要考虑以下主要因素：是否该系统大部分都稳定并不经常变化？

是否程序单纯依靠支持软件(如编辑器等)？

是否有工具来进行项目再造工程？

软件再造工程的重要性越来越高，如果系统的使用期限需要延长的话，进行一些软件再造