第十二软件维护与项目管理.ppt

1、软件维护与项目管理,软件维护,软件维护的概念 软件维护活动 程序修改的步骤及修改的副作用 可维护性 提高可维护性的方法 软件再工程,编程大师说：“任何一个程序，无论它多么小，总存在着错误。” 初学者不相信大师的话，他问：“如果一个程序小得只执行一个简单的功能，那会怎样？” “这样的一个程序没有意义，”大师说，“但如果这样的程序存在的话，操作系统最后将失效，产生一个错误。” 但初学者不满足，他问：“如果操作系统不失效，那么会怎样？” “没有不失效的操作系统，”大师说，“但如果这样的操作系统存在的话，硬件最后将失效，产生一个错误。” 初学者仍不满足，再问：“如果硬件不失效，那么会怎样？” 大师长叹

2、一声道：“没有不失效的硬件。但如果这样的硬件存在的话，用户就会想让那个程序做一件不同的事，这件事也是一个错误。” 没有错误的程序世间难求。James 1999,软件维护的定义,在软件运行维护阶段对软件产品进行的修改就是所谓的维护。 维护的类型有四种： 改正性维护 适应性维护 完善性维护 预防性维护,改正性维护,在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。,适应性维护,在使用过程中，

3、外部环境（新的硬、软件配置） 数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质） 可能发生变化。 为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。,完善性维护,在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。 这种情况下进行的维护活动叫做完善性维护。,预防性维护,预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。 预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。,维护在软

4、件生 三类维护占 存期所占比例 总维护比例,系统大小 程序设计语言 系统年龄 数据库技术的应用 先进的软件开发技术,影响维护工作量的因素,软件维护的策略,改正性维护技术改进包括：数据库管理系统、软件开发环境、程序自动生成系统、较高级(第四代)的语言。以及新的开发方法、软件复用、防错程序设计及周期性维护审查等。,完善性维护1、数据库管理系统、程序生成器、应用软件包，可减少维护工作量。2、建立软件系统的原型，把它在实际系统开发之前提供给用户。,维护成本,有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。 一些合理的修复或修改请求不能及时安排，使得客户不满意； 变更的结果引入新的故障，使

5、得软件整体质量下降；,维护工作量包括生产性活动（如分析和评价、设计修改和实现）和“轮转”活动,软件维护的代价是降低了生产率，在做老程序的维护时非常明显。 例如，开发每一行源代码耗资25美元，维护每一行源代码需要耗资1000美元。 维护工作量包括生产性活动（如分析和评价、设计修改和实现）和“轮转”活动（如力图理解代码在做什么、试图判明数据结构、接口特性、性能界限等）。,维护工作量的模型,M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致复杂性的度量 d是对软件熟悉程度的度量。,软件维护活动,为了有效地进行软件维护，应事先就开始做组织工作。 首先

6、建立维护的机构 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动的登记制度以及规定评价和评审的标准。,软件维护的机构,软件维护工作流程,程序修改的步骤及修改的副作用,通常对源程序的修改不能无计划地仓促上阵，为了正确、有效地修改,需要经历以下三个步骤。 分析和理解程序 修改程序 重新验证程序,在修改源代码时，都可能引入错误。例如，删除或修改一个子程序、删除或修改一个标号、 删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效率，以及把设计上的改变翻译成代码的改变时，都容易引入错误。,修改代

7、码的副作用,(2) 修改数据的副作用,在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。 数据副作用就是修改软件信息结构导致的结果。,容易导致设计与数据不相容的错误可以有： 重新定义局部的或全局的常量 重新定义记录或文件的格式 增大或减小一个数组或高层数据结构的大小 修改全局或公共数据 重新初始化控制标志或指针 重新排列输入输出或子程序的参数,(3) 文档的副作用,对数据流、软件结构、 模块逻辑或任何其它有关特性进行修改时，必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配，缺省条件改变，新错误信息不正确等错误。使得软件文档不能反映软件的当前状态。 如果对可执

8、行软件的修改不反映在文档里，就会产生文档的副作用。,重新验证程序,在将修改后的程序提交用户之前，需要进行充分的确认和测试，以保证整个修改后程序的正确性。 静态确认 计算机确认(1) 确认测试顺序(2) 准备标准的测试用例。(3) 充分利用软件工具帮助重新验证过程。,软件可维护性的定义,软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。 可维护性、可使用性、可靠性是衡量软件质量的主要质量特性，也是用户十分关心的几个方面。 软件的可维护性是软件开发阶段各个时期的关键目标。,目前广泛使用的是用如下的七个特性来衡量程序的可维护性。 可理解性可重用性 可测试

9、性可移植性 可修改性效率 可靠性 而且对于不同类型的维护，这七种特性的侧重点也不相同。,可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度。 可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。 可测试性表明论证程序正确性的容易程度。 可修改性表明程序容易修改的程度。 可移植性表明程序转移到一个新的计算环境的可能性的大小。 效率表明一个程序能执行预定功能而又不浪费机器资源的程度。 从用户观点出发，可使用性定义为程序方便、实用、及易于使用的程度。,在各类维护中的侧重点,可维护性的度量,人们一直期望对软件的可维护性做出定量度量。 常用的度量一个可

10、维护的程序的七种特性的方法。就是： 质量检查表 质量测试 质量标准,质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。 评价者针对检查表上的每一个问题，依据自己的定性判断，回答“Yes”或者“No”。 质量测试与质量标准则用于定量分析和评价程序的质量。 由于许多质量特性是相互抵触的，要考虑几种不同的度量标准，相应地去度量不同的质量特性。,度量可靠性的方法,根据程序错误统计数字，进行可靠性预测。常用方法是利用一些可靠性模型，根据程序测试时发现并排除的错误数预测平均失效间隔时间MTTF。 根据程序复杂性，预测软件可靠性。用程序复杂性预测可靠性，前提条件是可靠性与复杂性有关。因此可用复杂

11、性预测出错率。程序复杂性度量标准可用于预测哪些模块最可能发生错误，以及可能出现的错误类型。,提高可维护性的方法,建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档,提高软件质量的技术和工具,模块化 如果需要改变某个模块的功能，则只要改变这个模块，对其它模块影响很小； 如果需要增加程序的某些功能，则仅需增加完成这些功能的新的模块或模块层； 程序的测试与重复测试比较容易； 程序错误易于定位和纠正； 结构化程序设计 面向对象的开发方法,保证软件质量的最佳方法是在软件开发的最初阶段把质量要求考虑进去，并在开发过程每一阶段的终点

12、，设置检查点进行检查。 检查的目的是要证实，已开发的软件是否符合标准，是否满足规定的质量需求。在不同的检查点，检查的重点不完全相同。,在检查点进行复审,软件开发期间各个检查点的检查重点,机器语言 汇编语言 高级语言 查询语言 (FORTRAN、报表生成语言 COBOL等) 图象语言 应用生成语言,选择可维护的程序设计语言,软件再工程,逆向工程,软件项目管理,软件项目管理,1. 估算软件规模 2. 工作量估算 3. 进度计划 4.人员组织 5.质量保证 6.能力成熟度模型 7.软件配置管理,软件工程 包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。,导言,俗话说“三分技术，七分

13、管理”,软件项目管理贯穿于软件的整个生命周期,导言,软件项目管理,什么是管理（management）? 管理就是通过计划、组织和控制等一系列活动，合理地配置和使用资源，达到既定目标的过程。,导言,计划,组织,控制,过程,资源,合理使用与配置,效率 质量,软件项目管理的内容,导言,时间管理,人员管理,配置管理,质量管理,项目的时间管理,导言,估算 工作量,软件 需求,KLOC FP,估算 规模,人月,估算 进度,Gantt Pert,模型,模型,模型,项目的人员管理,导言,民主制程序员组,主程序员组,现代程序员组,项目的质量管理,导言,SQA小组,计划,监督,记录,分析,报告,活动,措施,基于非

14、执行的测试,程序正确性证明,软件的配置管理,导言,变化管理,标识变化,版本控制,变化控制,报告,配置审计,能力成熟度模型：评价软件机构的软件过程能力成熟度的模型。,导言,1.代码行（KLOC/LOC）技术,13.1 估计软件规模,出发点：依据以往开发类似产品的经验和历史数据。,加权平均法：多名有经验的软件工程师每人都估计程序的最小规模(a）、最大规模（b）和最可能的规模(m)，分别计算出这3中规模的平均值a,b和m之后，计算L。,-,-,-,1.代码行（KLOC/LOC）技术,13.1 估计软件规模,=,6,11+414+12,=13.17,1.代码行（KLOC/LOC）技术,13.1 估计软

15、件规模,优点：代码是所有软件项目的产品，且代码行易于计算。 缺点：（1）代码仅是软件配置的成分之一，用代码行表示软件规模不尽合理； （2）用不同语言实现统一软件，代码行数并不相同。,2.功能点（FP）技术,13.1 估计软件规模,克服代码行技术的缺点； 依据软件信息域特性和软件复杂性的评测结果。 用功能点（FP）为单位度量软件规模。,2.功能点（FP）技术,13.1 估计软件规模,（1）信息域特性,输入项数（Inp）,输出项数（Out）,查询数（Inq）,主文件数（Maf）,外部接口数（Maf）,信息域,2.功能点（FP）技术,13.1 估计软件规模,（1）信息域特性,输入项数(Inp):用户

16、向软件输入的项数，这些输入给软件提供面向应用的数据,不包括查询。 输出项数(Out): 查询数 主文件数 外部接口数,2.功能点（FP）技术,13.1 估计软件规模,（2）估算功能点的步骤,计算未调整的功能点UFP,计算技术复杂性因子TCF,计算功能点数FP,2.功能点（FP）技术,13.1 估计软件规模,（2）估算功能点的步骤,计算未调整的功能点UFP,UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf,2.功能点（FP）技术,13.1 估计软件规模,（2）估算功能点的步骤,计算技术复杂性因子TCF,确定技术因素对软件规模的影响值F1F14； 0Fi 5 计算技术因素对软件规

17、模的综合影响程度DI；,DI= Fi,计算技术复杂性因子TCF。 TCF=0.65+0.01DI,i=1,14,2.功能点（FP）技术,13.1 估计软件规模,（2）估算功能点的步骤,技术因素,计算技术复杂性因子TCF,2.功能点（FP）技术,13.1 估计软件规模,（2）估算功能点的步骤,计算功能点数FP,FP=UFPTCF,2.功能点（FP）技术,13.1 估计软件规模,（3）FP技术的优缺点 优点：与编程语言无关，比代码行技术更加合理； 缺点：在判断信息与特性复杂级别和技术因素的影响度 时，主观性较大。,13.2 工作量估计,工作量单位：人月（pm）。 工作量估算：是估算而不是计算，因为

18、是事先而不是事后。 工作量模型:是经验公式，是KLOC或FP的函数。 模型类别:静态模型 动态模型 构造模型,13.2 工作量估计,1.静态单变量模型,E=A+B(ev)C 其中： E:工作量 A,B,C：经验常数 ev:估算变量（KLOC或FP）,总体结构形式,13.2 工作量估计,1.静态单变量模型,Walston_Felix模型： E=5.2(KLOC)0.91,（1）面向KLOC的估算模型,Bailey_Basili模型： E=5.5+0.73(KLOC)1.16,Boehm简单模型： E=3.2(KLOC)1.05, Doty模型(KLOC9时)：E=5.288(KLOC)1.047

19、,13.2 工作量估计,1.静态单变量模型,Albrecht&Gaffney模型： E=-13.39+0.0545FP,（2）面向FP的估算模型,Maston,Barnett和Mellichamp模型： E=5.587+15.12FP,13.2 工作量估计,1.静态单变量模型,对于相同的KLOC或FP用不同的模型得到的结果不同，这是因为模型经验来自于有限领域和有限项目，进而适用范围有限，因此实际应用时应适当调整模型（如，修改常数）。,（3）静态单变量模型的评价,13.2 工作量估计,2.动态多变量模型,E=(LOCB0.333/P)3(1/t)4 其中E是工作量；t是项目持续时间；B是特殊技术

20、因子，当KLOC=515时B=0.16，当KLOC70时B=0.39；P是生产率参数，P=2000（嵌入式软件），P=10000（电信系统/系统软件），P=28000（商业应用系统）。,（1）总体结构形式,13.2 工作量估计,2.动态多变量模型,是软件规模和开发时间的函数； 开发统一软件时，延长项目持续时间可降低完成项目所需的工作量。,（2）模型评价,13.2 工作量估计,3.构造性成本模型：COCOMO2模型,应用系统组成模型：估算构建原型的工作量； 早期设计模型：适用于体系结构设计阶段； 后体系结构模型：适用于体系结构设计之后的开发阶段。,（1）模型层次,13.2 工作量估计,3.构造性

21、成本模型：COCOMO2模型,（2）后体系结构模型,其中： E是工作量 a是模型系数 b是模型指数 fi是成本因素,13.3 进度计划,1.估算开发时间 2.Gantt图 3.工程网络 4.估算工程进度 5.关键路径 6.机动时间,13.4 人员组织,1.民主制程序员组 2.主程序员组 3.现代程序员组,民主制程序员组,主程序员组,现代程序员组,13.4 人员组织,1.民主制程序员组,特点：地位平等，充分民主，协商决策。 通信路径：n(n-1)/2 规模：较小，2-8人为宜 优点：积极面对程序错误，质量较高； 充分民主，凝聚力高，利于攻关； 实用于成员经验均丰富时。 缺点：成员经验均不丰富，缺

22、乏协调，导 致失败。,13.4 人员组织,2.主程序员组,13.4 人员组织,2.主程序员组,产生背景：IBM公司20世纪70年代初期发明。 （1）软件开发人员多数比较缺乏经验； （2）程序设计过程中有许多事务性工作，如信息存储和更新； （3）多渠道通信很费时间，将降低程序员的生产率。,13.4 人员组织,2.主程序员组,特性： (1)专业化：该组每名成员仅完成他们受过专业训练的那些工作。 (2)层次化：主程序员指挥每名组员工作，并对工作全面负责。,13.4 人员组织,2.主程序员组,分工： (1)主程序员：体系结构设计、关键部分详细设计，技术指导。 (2)后备程序员：协助主程序员，必要时接替

23、主程序员。 (3)编程秘书：负责事务性工作。,13.4 人员组织,2.主程序员组,缺点： (1)主程序员：是高级程序员和优秀管理者的结合体，难找。 (2)后备程序员：期望与主程序员一样优秀，难找。 (3)编程秘书：专业人员厌烦事务工作，难找。,13.4 人员组织,3.现代程序员组,（1）现代程序员组的结构,技术管理,非技术管理,13.4 人员组织,3.现代程序员组,程序员,程序员,程序员,（2）大型项目的技术管理组织结构,技术管理,组长,程序员,程序员,程序员,程序员,程序员,组长,组长,项目经理,13.4 人员组织,3.现代程序员组,程序员,程序员,程序员,（3）包含分散决策的组织方式,技术

24、管理,组长,程序员,程序员,程序员,程序员,程序员,组长,组长,项目经理,项目的质量管理,13.5 质量保证,SQA小组,计划,监督,记录,分析,报告,活动,措施,13.5 质量保证,1.何谓软件质量？,定义：软件与明确地和隐含地定义的需求相一致的程度。,明确地叙述的功能和性能需求、文档中明确描述的开发标准。,任何专业开发的软件产品都应该具有的隐含特征。,13.5 质量保证,1.何谓软件质量？,定义：软件与明确地和隐含地定义的需求相一致的程度。 要点：（1）与需求不一致就是质量不高。 （2）没有遵守开发准则会导致质量不高。 （3）不满足隐含的需求，质量仍然是值得怀疑的。,13.5 质量保证,1

25、.何谓软件质量？,软件质量因素与产品活动的关系,正确性（它按我的需要工作吗？） 健壮性（对意外环境它能适当地响应吗？） 效率 （完成预定功能时它需要的计算机资源多吗？） 完整性（它是安全的吗？） 可用性（我能使用它吗？） 风险 （能按计划完成它吗？）,可理解性（我能理解它吗？） 可维修性（我能修复它吗？） 灵活性 （我能改变它吗？） 可测试性（我能测试它吗？）,可移植性(我能在另一台机器上使用它吗？) 可再用性(我能再用它的某些部分吗？） 互运行性(我能把它和另一个系统结合吗？),13.5 质量保证,2.软件质量保证措施,措施,基于非执行的测试 （也称为复审或评审）：用来保证在编码之前各阶段产

26、生的文档的质量。,基于执行的测试 在程序编写出来之后保证软件质量的最后一道防线。,程序正确性证明 使用数学方法严格验证程序是否与它说明的完全一致。,13.5 质量保证,2.软件质量保证措施(人员),软件工程师 采用先进的方法和度量，进行正式的技术复审以及完成计划周密的软件测试来保证软件质量。,SQA小组 通过计划、监督、记录、分析和报告等活动，辅助软件工程师，通过确保软件过程的质量来保证软件产品的质量。,软件工程师,SQA小组,13.5 质量保证,2.软件质量保证措施(技术复审),(1)技术复审=走查(walkthrough)+审查(inspection),(2)技术复审的必要性 能够较早发现软件错误，从而防止错误传播到软件过程的后续阶段。,4030%其它错误,6070% 规格说明或设计错误,复审发现规格说明或设计错误的75%,13.5 质量保证,2.软件质量保证措施(技术复审),(3)走查 小组：46人组成 走查方式： 参与驱动法：参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须回答每个质疑，要么承认确实有错误，要