1第11章软件项目管理第11章软件项目管理2软件项目管理在经历了几个像操作系统开发这样的大型软件工程项目的失败以后,人们才逐渐认识到软件管理中的独特问题。事实上,这些工程项目的失败并不是由于从事开发工作的软件工程师无能,正相反,他们之中的绝大多数是当时杰出的技术专家。这些工程项目的失败主要是由于使用的管理技术不适当。总结历史经验教训,逐渐形成了软件工程这门新学科,它包括方法、工具和管理等广泛的研究领域。十几年来已经研究出一些用于软件规格说明、设计、实现和验证的先进方法学,对软件管理的认识也有一定进步。但是,在软件管理方面的进步远比在设计方法学和实现方法学方面的进步小,至今还提不出一套管理软件开发的通用指导原则。软件经理(管理人员)的责任是制定软件开发工程的计划,监督和检查工程进展情况,保证工程按照要求的标准,准时在预算成本内完成。虽然目前好的管理还不一定能保证工程成功,但是坏的管理或不适当的管理技术却一定会导致工程失败——软件交付使用的日期将大大拖后,成本可能比预计成本高几倍,而且最终的软件产品很难维护。第11章软件项目管理311.1成本估算第11章软件项目管理411.1.1参数方程⒈静态单变量静态单变量模型的一般形式如下:资源=C1×(估计的特点)*exp(C2)其中“资源”通常是人力(即开发工作需要的工作量,以人月或人日、人年为单位),也可以是工程期限,需要的人数或文档数量等等,常数C1和C2根据历史经验数据得出;“估计的特点”通常是源代码的行数。例如,Doty提出的估算开发工作量的算法列在表。表中MM是开发(包括分析、设计、编码、测试和调试等工作)需要用的人力(以人月为单位);I是估计的程序长度,表内中间一列是用目标指令数度量长度,右边一列是用源代码行数度量长度,长度单位是千条(或千行)。第11章软件项目管理511.1.1参数方程估算开发工作量的算法应用范围目标代码源代码全部命令和控制科学计算商业实用程序MM=4.079I0.991MM=4.573I1.228MM=4.495I1.058MM=2.895I0.784MM=12.039I0.719MM=5.528I1.057MM=4.089I1.263MM=7.054I1.019MM=4.495I0.781MM=10.078I0.811第11章软件项目管理611.1.1参数方程⒉静态多变量静态多变量模型也是根据历史数据导出经验公式,公式的典型形式如下:资源=c11×e1×exp(c12)+c21×e2×exp(c22)+…其中ei是软件的第i个特点,ci1和ci2是与第i个特点有关的经验常数。第11章软件项目管理711.1.1参数方程⒊动态多变量这类模型把资源需求看作是开发时间的函数。例如,根据大型软件工程项目(总工作量30人年以上)的数据导出的Putnam模型如下:(1)其中L是源代码行数;K是开发需用的人力(以人年为单位);td是开发需用的时间(以年为单位);Ck是技术水平常数,它的典型值如下:对于差的开发环境=2500;对于好的开发环境=10000;对于优越的开发环境=12500。从方程(1)可以解出开发需要的工作量:3/43/1dktKCL433dktCLK第11章软件项目管理811.1.2标准值法这种方法主要使用开发各类程序的标准生产率估计开发工程的总工作量。标准生产率根据以往的开发经验导出。主要从下述几个方面划分程序开发类型:①使用的程序设计语言。②处理方式(批处理,实时处理等)。③程序难易程度。④技术人员的水平。⑤开发范围(从需求分析到测试,或者从程序设计到测试)。使用标准值法估算开发工作量,首先需要确定程序的开发类型,并且估计程序的规模。为了使程序规模的估计值更接近实际值,可以请几名有经验的软件工程师分别作出计。每个人都应该估计程序的最小规模(a),最大规模(b)和最可能的规模(m),分别求让这三种规模的平均值,a、b和m之后,再用下式计算程序规模的估计值:64bmaK第11章软件项目管理911.1.2标准值法然后使用开发该类程序的标准生产率和适当的修正系数估算开发工作量:工作量=修正系数×其中标准生产率的单位通常是每人日可以开发的程序长度(源程序行数或目标指令条数);修正系数反映其他因素对开发工作量的影响,当考虑从需求分析直到测试的开发过程时,它的算法是:修正系数=1+0.1*n其中n是符合下列条款的数目:标准生产率程序长度第11章软件项目管理1011.1.2标准值法⒈目标系统情况①修改文档不完备的程序②需求中有不明确的或尚未决定的内容③系统规模较大④工作带有试探性质(需多次试探)⑤系统接口不明确或接口复杂⑥联机实时系统(测试困难)⑦数据库需要复杂的安全措施第11章软件项目管理1111.1.2标准值法⒉项目管理和人员组成情况①中途改变项目管理人②项目组不协调(人事关系不好)③新手或初级人员比例较高④需要培训程序员⑤项目管理人没有数据处理经验⑥项目管理人没有应用领域经验⑦系统分析员没有应用领域经验⑧系统设计员没有应用领域经验⑨程序员没有应用领域经验第11章软件项目管理1211.1.2标准值法⒊用户情况①用户对计算机数据处理知之甚少②系统需要在不同场合使用③系统需满足使用部门的标准或手续④使用部门提供的测试数据没经过验证⑤使用部门不同意开发计划⑥开发过程中用户需求发生了变化⑦使用部门负责人变动第11章软件项目管理1311.1.2标准值法⒋开发环境情况①现有的操作系统功能不足②将来预定使用的计算机尚未测试③工作场所分散④主存和辅存受限制⑤计算机使用时间不能充分保障⑥计算机机房管理不善⑦工作中途中断第11章软件项目管理1411.1.3COCOMO模型所谓COCOMO模型就是Boehm提出的构造性成本模型(ConstructiveCostModel)。在这种模型中,软件开发工作量表示成据估计应该开发的代码行数的非线性函数:其中MM是开发工作量(以人月为单位),是模型系数,KLOC是估计的代码行数(以千行为单位),a是模型指数,fi(i=1到15)是成本因素。1511iiafkLOCCMM第11章软件项目管理1511.1.3COCOMO模型表15种影响软件工作量的因素fi的等级分类工作量因素fi非常低低正常高非常高超高产品因素软件可靠性数据库规模产品复杂性0.750.881.001.151.400.941.001.081.160.700.851.001.151.301.65计算机因素执行时间限制存储限制虚拟机*易变性环境周转时间1.001.111.301.661.001.061.211.560.871.001.151.300.871.001.071.15人员的因素分析员能力应用领域实际检验程序员能力虚拟机*使用经验程序语言使用经验1.461.000.861.291.131.000.910.711.421.171.000.860.821.211.101.000.900.701.411.071.000.95项目因素现代程序设计技术软件工具的使用开发进度限制1.241.101.000.910.821.241.101.000.910.831.231.081.001.041.10*虚拟机是指为完成某一个任务所使用硬、软件的结合。第11章软件项目管理1611.1.3COCOMO模型COCOMO模型是层次型模型,按详细程度分成3级。最上层是对各种规模软件的宏观估计模型;最下层是微观模型,它具有任务分解结构和一系列阶段敏感因子。下面简单介绍中层COCOMO模型。软件开发项目可以分成组织式、半独立式和嵌入式三种模式。对组织式软件的要求通常不苛刻,开发人员经验丰富,而且对软件的使用环境很熟悉(通常是为自己所在的组织开发软件),程序规模一般不大(小于50000行代码)。基本COCOMO模型的工作量和进度公式总体类型工作量进度组织型半独立型嵌入型MM=2.4(KDSI)1.05TDEV=2.5(MM)0.38MM=3.0(KDSI)1.12TDEV=2.5(MM)0.35MM=3.6(KDSI)1.20TDEV=2.5(MM)0.32第11章软件项目管理1711.1.3COCOMO模型【例】一个规模10KDSI的商用微机远程通信的嵌入型软件,使用中间COCOMO模型进行软件成本估算。程序名义工作量MM2.8×(10)1.20=44.38(MM)程序实际工作量MM=44.38×=44.38×1.17=51.9(MM)开发所用时间TDEV=2.5×(51.9)0.32=8.8(月)如果分析员与程序员的工资都按每月6000美圆计算,则该项目的开发人员的工资总额为:51.9×6000=311400(美圆)51iif151iif第11章软件项目管理1811.1.3COCOMO模型影响负责量因素fi取值表影响工作量因素fi情况取值1软件可靠性只用于局部地区,恢复问题不严重1.00(正常)2数据库规模20000字节0.94(低)3产品复杂性用于远程通信处理1.30(很高)4时间限制使用70%的CPU时间1.10(高)5存储限制64KB中使用45KB1.06(高)6机器使用商用微处理机1.00(额定值)7周转时间平均2小时1.00(额定值)8分析员能力优秀人才0.86(高)9工作经验远程通信工作3年1.10(低)10程序员能力优秀人才0.86(高)11工作经验微型机工作6个月1.00(正常)12语言使用经验12个月1.00(正常)13使用现代程序设计技术1年以上0.91(高)14使用软件工具基本的微型机软件1.10(低)15工期9个月1.00(正常)第11章软件项目管理1911.1.3COCOMO模型现在用一水平较低的开发人员,其工资为每月5000美圆,但人员的水平的两个调节因子从0.86调高到1.00,则整个调节因子从原来的1.17上升到1.58,其开发成本为:5000×44.38×1.58=350602第11章软件项目管理2011.2进度计划第11章软件项目管理21进度计划管理复杂的工程项目非常困难,最好的办法是把它分解成一系列比较容易管理的子任务。但是分解后也容易只注意对各个子任务的管理,以致忽略了对工程总体情况的了解和管理。因此需要有某种工具既支持把项目分解成较小的子任务(又称为作业),又能帮助管理人员保持对工程总体情况的洞悉和管理。通常的做法是按工程项目分解成许多逻辑步骤(作业),然后安排这些作业的顺序,确定每项作业需要用的时间,以及作业开始和终止的时间。这也就是制定进度计划的任务。Gantt图和工程网络图是制定进度计划时常用的两个图形工具。第11章软件项目管理2211.2.1工程网络图工程网络是制定进度计划时一种常用的图形工具,它能描绘任务分解情况以及每项作业的开始时间和结束时间,此外,它还显式地描绘各个作业彼此间的依赖关系。因此,工程网络是系统分析和系统设计的强有力的工具。系统分析员就可以借助它的帮助估算工程进度了。为此需要在工程网络上增加一些必要的信息。首先,把每个作业估计需要使用的时间写在表示该项作业的箭头上方。注意,箭头长度和它代表的作业持续时间没有关系,箭头仅表示依赖关系;它上方的数字才表示作业的持续时间。其次,为每个事件计算下述两个统计数字:最早时刻EET和最迟时刻LET。这两个数字将分别写在表示事件的圆圈的右上角和右下角。第11章软件项目管理2311.2.1工程网络图事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零,其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。计算最早时刻EET使用下述三条简单规则:⑴考虑进入该事件的所有作业;⑵对于每个作业都计算它的持续时间与起始事件的EET之和;⑶选取上述和数中的最大值作为该事件的最早时刻EET。第11章软件项目管理2411.2.1工程网络图起点00分析33设计7734测试计划25测试数据51122编码1111终点1515测试软件811产品测试1515文档9152446442第11章软件项目管理2511.2.1工