IT软件项目维护管理
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Fra Baidu bibliotek
读懂别人的程序一般是非常困难的。 文档的不一致性。 软件开发和软件维护在人员和时间上的差异。 软件维护在大多数人看来是一件没有挑战性的工作。
9
2014-7-15
9.2 软件项目维护成本
火龙果 整理 uml.org.cn
9.2.1 影响软件项目维护成本的因素
9.2.2 软件项目维护成本的预测
这些因素的权重分别是:
RELY:1.10
AEXP:0.91 LEXP:0.95
MODP:0.72
通过应用以上的权重,计算最初的维护成本估计值:
AME=35.4*1.10*0.91*0.75*0.72=24.2PM
17
2014-7-15
9.2.2 软件项目维护成本的预测(4)
火龙果 整理 uml.org.cn
2014-7-15 12
影响软件项目维护成本的因素——非技术因素
火龙果 整理 uml.org.cn
应用领域: 如果应用软件系统能够很清楚地定义并且很好 地理解,则系统的需求就可以完全准确定义,适应性维护就 相对较少。而如果一个应用软件是在全新的领域中进行的, 则原始的需求就可能随着开发人员不断获得该领域的经验而 经常变化。 员工稳定性:如果是系统开发人员负责维护本人负责开发的 部分,维护成本将大大减少。 软件生命周期:随着软件生命周期的进展,相应的软件或硬 件已不适应,被抛弃的部分变多,维护成本相应增加。 外部环境:如果一个软件依靠它的外部环境,则当外部环境 发生改变时,软件也要发生相应的改动。如:税法的改变, 要求相应的工资等程序模块要发生变化。 硬件的稳定性:软件和程序需要不断更新以使能用新的硬件 来取代过时的硬件,因此也会发生相应的维护费用。
McCabe 在1976年提出的“曲线图技术”:假设程序的复杂性不 在于程序的大小而在于程序的判断结构。 Halstead 在1977年提出的“参数法”:参数有算子的数量、操 作数的数量、算子使用的总频率、操作数使用的总频率等。
19
2014-7-15
9.3 项目可维护性的度量(2)
火龙果 整理 uml.org.cn
6
规 律 连续变化规律 复杂度增加规律 大规模软件发展 规律 组织稳定规律 保持一致规律
2014-7-15
9.1.2 软件项目发展动力学(2)
火龙果 整理 uml.org.cn
连续变化规律表明系统维护是一个必须的过程。错误修复只 是维护活动的一小部分工作。一个设计好的软件系统必须是 可维护的。 复杂度增加规律说明随着系统的变化,软件原有的整体结构 将不断退化。如果希望改变这种结构退化的趋势,就必须增 加一些额外的成本,有时这种成本将成为是否实施软件改变 的重要影响因素。因此,减少结构退化的成本必须是可以接 受的,而且,维护过程可能要包括系统结构的重新设计。 组织稳定规律说明大多数大规模的软件项目都处于一种“饱 和”的状态。即任何一个资源或人员的变化都会对系统的长 期发展产生不利的影响。
2014-7-15
16
9.2.2 软件项目维护成本的预测(3)
火龙果 整理 uml.org.cn
例如:
在上面的例子中,对维护成本影响最大的因素有:
可靠性(RELY),可靠性必须高 有应用开发及编程语言经验的开发人员(AEXP和LEXP) 为开发系统所用的编程方法(MODP)等。
2014-7-15 7
9.1.2 软件项目发展动力学(3)
火龙果 整理 uml.org.cn
大规模软件发展规律表明大型系统在开发的早期阶段就有了 自身的动态性和可调节能力,即决定了系统维护过程大致的 趋势和系统可能变化的数量,维护管理不能也不应该做系统 变化所要求的所有事情。由于变化是针对整个系统的,所以 变化也会引入新的错误到系统中,这时就需要更多的变化来 纠正这些错误,一旦系统超过了一定的规模,这些变化所起 的作用如同惯性系统一样,同时也阻碍着更大的变化,这些 变化导致系统的可靠性降低。所以在任何时候实施的变化数 量都是有限的。系统变化的过程在一定程度上受组织的决策 过程所控制。 保持一致规律关心的是软件系统每个版本发行时的变化增加 量,变化量保持适度的增加是必须的。
其中:AME是年维护成本; SDT是项目开发时间,以人月(PM)为基本单位; ACT是年变化冲突。 如:一个软件项目需要236PM开发并且估计大概有15%的ACT, 则基本的维护成本预测值为: AME=0.15*236=35.4PM
2014-7-15 15
9.2.2 软件项目维护成本的预测(2)
火龙果 整理 uml.org.cn
上面的公式给出了项目维护成本的一个大概评估,它 是进行进一步精确计算的基础。 进行精确计算,需要考虑项目过程、项目产品和人员 因素等。 维护成本预测可以通过判断每个影响成本因素的重要 性,选择大概的权重,然后再进行提炼。 基本的维护成本预测公式可以通过每个因素的影响权 重来修正成本预测。
2014-7-15
2
9.1.1 软件项目维护管理理论
火龙果 整理 uml.org.cn
IT 软件项目维护主要包括以下工作 完善性维护:在不改变系统整体功能的前提下,提高 和改善某部分的功能。一般占65%。 适应性维护:调整系统使之能适应一个已经发生变化 的系统环境。一般占17%。 纠错性维护:纠正以前未发现的系统错误。一般占 17%。 预测性维护:为了提高软件项目的可维护性、可靠性 等,为以后进一步改善软件项目功能和使用而进行的 活动。一般占1%。
项目发展动力学是Lehman和Belady(1985)进行系 统变化研究,并在该领域里从事的主要工作。
表9.1 Lehman 规律
定 义 在不断变化的环境里,软件必须要发生变化,不然,该软件的用途 就变得会越来越小 作为一个不断发展和变化的软件,其结构将会变得更加复杂,必须 引入外在的资源来保持和简化这个结构 软件的发展变化是一个自我调节的过程,系统属性(如规模、版本 发布间隔时间、发现的错误数等)对每个系统版本来说都应当是大 致不变的 在软件的整个生命周期里,它的发展变化速度大致是不变的,并且 与投入系统开发的资源无关 在软件的整个生命周期中,每个版本增加的系统变化量都是大致相 当的
2014-7-15 13
影响软件项目维护成本的因素——技术因素
火龙果 整理 uml.org.cn
模块的独立性:修改一个模块时不影响其他模块的功能。 编程语言:用高级语言编写的程序一 般比用低级语言编写 的程序易于理解和维护。 编程风格:采取易于理解的方式编写的软件更容易修改和维 护。 软件有效性和测量:一般花在软件有效性验证和测量的时间 越长,软件潜在的错误就越少。 文档的质量:如果软件有清楚、完全并且简洁的文档支持, 软件和程序也会相对好读懂,维护成本相对较低。 配置管理的技术:维护成本的一个重要组成部分是对系统所 有文档的保存,有效配置管理技术能帮助控制这些成本。
9.4 软件再造工程
火龙果 整理 uml.org.cn
软件再造工程:在项目的生命周期中,存在这样一个阶 段,对软件系统进行增量变化时,其成本非常高,以至 于我们要么抛弃并重新编制或者完全(或部分)地设计 其结构,这就是软件再造工程。 在考虑是否要进行“软件再造工程”时,主要要考虑以 下主要因素: 是否该系统大部分都稳定并不经常变化? 是否程序单纯依靠支持软件(如编辑器等)? 是否有工具来进行项目再造工程? 软件再造工程的重要性越来越高,如果系统的使用期限 需要延长的话,进行一些软件再造工程是必须的。
2014-7-15
11
9.2.1 影响软件项目维护成本的因素
开发成本
火龙果 整理 uml.org.cn
系统1 系统2
0 5 10 15 20 25 30 35 40 45
维护成本
50 开发及维护成本
从多数的软件项目经验看,在系统设计和开发中投入大量的
人力物力是减少维护成本的最好办法。如果系统开发成本增 加的百分比与系统维护成本减少的百分比相当的话,增加开 发成本将会导致整个系统成本的减少。上图表明了系统开发 成本和维护成本之间关系。 通常维护成本很难估计,因为它们与产品、过程及组织因素 有关。
2014-7-15 14
9.2.2 软件项目维护成本的预测(1)
火龙果 整理 uml.org.cn
年变化冲突(ACT)的定义:软件产品一年中变化资源(可以 是增加的也可以是减少的)在总资源中所占的比例。 Boehm对维护成本的估计方法是采用年变化冲突(ACT)和 开发时的估计或者实际成本(以人月表示)来求得软件维护 的年成本。在Boehm模型中,维护成本的计算公式为: AME=ACT * SDT
2014-7-15
10
9.2.1 影响软件项目维护成本的因素
火龙果 整理 uml.org.cn
一般来说,软件项目维护成本很难预测,因为产生维护成本 与很多产品、过程和组织因素有关。而且不同应用领域的项 目维护成本存在很大的差别。 从多数软件项目经验看,在系统设计和开发中投入大量的人 力物力是减少维护成本的最好办法。 影响项目的维护成本主要因素分为技术因素和非技术因素。 非技术因素一般包括应用领域、员工稳定性、软件生命周期、 外部环境、硬件的稳定性等方面。 技术因素主要包括模块的独立性、编程语言、编程风格、软 件有效性和测量、文档的质量和配置管理的技术等。
Gilb提出的间接估算可维护性法:提出了一些与可维护 工作量有关的可维护性度量。主要有: 问题确定时间 管理延迟时间 维护工具收集时间 问题分析时间 规格说明修改时间 改正或修改活动时间 局部测试时间 全局测试时间 维护评审时间 整个恢复时间
2014-7-15 20
第9章 IT软件项目维护管理
火龙果 整理 uml.org.cn
9.1 软件项目维护概述 9.2 软件项目维护成本 9.3 项目可维护性的度量 9.4 软件再造工程
2014-7-15
1
9.1 软件项目维护概述
火龙果 整理 uml.org.cn
9.1.1 软件项目维护管理理论 9.1.2 软件项目发展动力学 9.1.3 软件项目维护的特点
把项目目标与组织目标相结合。
把项目维护报酬与工作相结合。
使维护人员参与到开发小组中去。 制定一个完善的维护计划,并允许维护人员决定系统是
否该重新设计。
使维护人员介入到系统目标准备、测试等工作中去。
2014-7-15
5
9.1.2 软件项目发展动力学(1)
火龙果 整理 uml.org.cn
IT软件项目管理和其他项目管理相比,具有很
大的独特性。
生产无形的产品 过程没有明显的划分 大都是“一次性”的人力消耗型项目
2014-7-15
18
9.3 项目可维护性的度量(1)
火龙果 整理 uml.org.cn
维护度量标准并不测量系统某个特定变化的成本,也不预 测某个组件是否应该维护。它是建立在软件的可维护性与 复杂性相关的基础上的。 软件可维护性是指软件能够被理解、改正、适应和完善, 以适应新的环境的难易程度。 软件项目最终的可维护性受许多因素的影响,从而度量的 方法也不相同。 目前对项目可维护性的度量的方法主要有:
2014-7-15 8
9.1.3 软件项目维护的特点
火龙果 整理 uml.org.cn
软件项目开发过程对软件的维护有较大的影响,如果不遵 循软件工程的方法开发软件项目,软件往往只有程序而没 有文档,这样软件维护工作是非常困难的。这是一种非结 构化的维护。 若采用软件工程方法进行软件项目开发,则各个阶段都有 相应的文档,使软件容易进行维护工作,这是一种结构化 的维护。 无论哪种维护方式,软件项目的维护都存在着一定的困难, 它主要是由软件需求分析和开发方法的缺陷造成的。 困难主要表现在如下几个方面:
3
2014-7-15
9.1.1 软件项目维护管理理论
火龙果 整理 uml.org.cn
需求变化
冲突分析化
维护计划
功能更改
系统发布
完善维护
适应性维护
纠错维护
图9.2 软件项目维护的主要过程
2014-7-15
4
9.1.1 软件项目维护管理理论
火龙果 整理 uml.org.cn
在实际项目开发中,要想提高员工维护的积极性, 可以考虑从以下几个方面来进行: