最新企业软件项目管理

1,第11章软件项目管理,2,软件项目管理,在经历了几个像操作系统开发这样的大型软件工程项目的失败以后，人们才逐渐认识到软件管理中的独特问题。事实上，这些工程项目的失败并不是由于从事开发工作的软件工程师无能，正相反，他们之中的绝大多数是当时杰出的技术专家。这些工程项目的失败主要是由于使用的管理技术不适当。总结历史经验教训，逐渐形成了软件工程这门新学科，它包括方法、工具和管理等广泛的研究领域。十几年来已经研究出一些用于软件规格说明、设计、实现和验证的先进方法学，对软件管理的认识也有一定进步。但是，在软件管理方面的进步远比在设计方法学和实现方法学方面的进步小，至今还提不出一套管理软件开发的通用指导原则。软件经理（管理人员）的责任是制定软件开发工程的计划，监督和检查工程进展情况，保证工程按照要求的标准，准时在预算成本内完成。虽然目前好的管理还不一定能保证工程成功，但是坏的管理或不适当的管理技术却一定会导致工程失败软件交付使用的日期将大大拖后，成本可能比预计成本高几倍，而且最终的软件产品很难维护。,3,11.1成本估算,4,11.1.1参数方程,静态单变量静态单变量模型的一般形式如下：资源C1(估计的特点)*exp(C2)其中“资源”通常是人力（即开发工作需要的工作量，以人月或人日、人年为单位），也可以是工程期限，需要的人数或文档数量等等，常数C1和C2根据历史经验数据得出；“估计的特点”通常是源代码的行数。例如，Doty提出的估算开发工作量的算法列在表。表中MM是开发（包括分析、设计、编码、测试和调试等工作）需要用的人力（以人月为单位）；I是估计的程序长度，表内中间一列是用目标指令数度量长度，右边一列是用源代码行数度量长度，长度单位是千条（或千行）。,5,11.1.1参数方程,6,11.1.1参数方程,静态多变量静态多变量模型也是根据历史数据导出经验公式，公式的典型形式如下：资源c11e1exp(c12)+c21e2exp(c22)+其中ei是软件的第i个特点，ci1和ci2是与第i个特点有关的经验常数。,7,11.1.1参数方程,动态多变量这类模型把资源需求看作是开发时间的函数。例如，根据大型软件工程项目(总工作量30人年以上)的数据导出的Putnam模型如下：(1)其中L是源代码行数；K是开发需用的人力（以人年为单位）；td是开发需用的时间（以年为单位）；Ck是技术水平常数，它的典型值如下：对于差的开发环境2500；对于好的开发环境10000；对于优越的开发环境12500。从方程(1)可以解出开发需要的工作量：,8,11.1.2标准值法,这种方法主要使用开发各类程序的标准生产率估计开发工程的总工作量。标准生产率根据以往的开发经验导出。主要从下述几个方面划分程序开发类型：使用的程序设计语言。处理方式（批处理，实时处理等）。程序难易程度。技术人员的水平。开发范围（从需求分析到测试，或者从程序设计到测试）。使用标准值法估算开发工作量，首先需要确定程序的开发类型，并且估计程序的规模。为了使程序规模的估计值更接近实际值，可以请几名有经验的软件工程师分别作出计。每个人都应该估计程序的最小规模(a)，最大规模(b)和最可能的规模(m)，分别求让这三种规模的平均值，a、b和m之后，再用下式计算程序规模的估计值：,9,11.1.2标准值法,然后使用开发该类程序的标准生产率和适当的修正系数估算开发工作量：工作量修正系数其中标准生产率的单位通常是每人日可以开发的程序长度（源程序行数或目标指令条数）；修正系数反映其他因素对开发工作量的影响，当考虑从需求分析直到测试的开发过程时，它的算法是：修正系数1+0.1*n其中n是符合下列条款的数目：,10,11.1.2标准值法,目标系统情况修改文档不完备的程序需求中有不明确的或尚未决定的内容系统规模较大工作带有试探性质（需多次试探）系统接口不明确或接口复杂联机实时系统（测试困难）数据库需要复杂的安全措施,11,11.1.2标准值法,项目管理和人员组成情况中途改变项目管理人项目组不协调（人事关系不好）新手或初级人员比例较高需要培训程序员项目管理人没有数据处理经验项目管理人没有应用领域经验系统分析员没有应用领域经验系统设计员没有应用领域经验程序员没有应用领域经验,12,11.1.2标准值法,用户情况用户对计算机数据处理知之甚少系统需要在不同场合使用系统需满足使用部门的标准或手续使用部门提供的测试数据没经过验证使用部门不同意开发计划开发过程中用户需求发生了变化使用部门负责人变动,13,11.1.2标准值法,开发环境情况现有的操作系统功能不足将来预定使用的计算机尚未测试工作场所分散主存和辅存受限制计算机使用时间不能充分保障计算机机房管理不善工作中途中断,14,11.1.3COCOMO模型,所谓COCOMO模型就是Boehm提出的构造性成本模型（ConstructiveCostModel）。在这种模型中，软件开发工作量表示成据估计应该开发的代码行数的非线性函数：其中MM是开发工作量（以人月为单位），是模型系数，KLOC是估计的代码行数（以千行为单位），a是模型指数，fi（i1到15）是成本因素。,15,11.1.3COCOMO模型,16,11.1.3COCOMO模型,COCOMO模型是层次型模型，按详细程度分成3级。最上层是对各种规模软件的宏观估计模型；最下层是微观模型，它具有任务分解结构和一系列阶段敏感因子。下面简单介绍中层COCOMO模型。软件开发项目可以分成组织式、半独立式和嵌入式三种模式。对组织式软件的要求通常不苛刻，开发人员经验丰富，而且对软件的使用环境很熟悉（通常是为自己所在的组织开发软件），程序规模一般不大（小于50000行代码）。,17,11.1.3COCOMO模型,【例】一个规模10KDSI的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行软件成本估算。程序名义工作量MM2.8(10)1.20=44.38(MM)程序实际工作量MM=44.38=44.381.17=51.9(MM)开发所用时间TDEV=2.5(51.9)0.32=8.8(月)如果分析员与程序员的工资都按每月6000美圆计算，则该项目的开发人员的工资总额为：51.96000=311400(美圆),18,11.1.3COCOMO模型,19,11.1.3COCOMO模型,现在用一水平较低的开发人员,其工资为每月5000美圆,但人员的水平的两个调节因子从0.86调高到1.00,则整个调节因子从原来的1.17上升到1.58,其开发成本为:500044.381.58=350602,20,11.2进度计划,21,进度计划,管理复杂的工程项目非常困难，最好的办法是把它分解成一系列比较容易管理的子任务。但是分解后也容易只注意对各个子任务的管理，以致忽略了对工程总体情况的了解和管理。因此需要有某种工具既支持把项目分解成较小的子任务(又称为作业)，又能帮助管理人员保持对工程总体情况的洞悉和管理。通常的做法是按工程项目分解成许多逻辑步骤(作业)，然后安排这些作业的顺序，确定每项作业需要用的时间，以及作业开始和终止的时间。这也就是制定进度计划的任务。Gantt图和工程网络图是制定进度计划时常用的两个图形工具。,22,11.2.1工程网络图,工程网络是制定进度计划时一种常用的图形工具，它能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显式地描绘各个作业彼此间的依赖关系。因此，工程网络是系统分析和系统设计的强有力的工具。系统分析员就可以借助它的帮助估算工程进度了。为此需要在工程网络上增加一些必要的信息。首先，把每个作业估计需要使用的时间写在表示该项作业的箭头上方。注意，箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系；它上方的数字才表示作业的持续时间。其次，为每个事件计算下述两个统计数字：最早时刻EET和最迟时刻LET。这两个数字将分别写在表示事件的圆圈的右上角和右下角。,23,11.2.1工程网络图,事件的最早时刻是该事件可以发生的最早时间。通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。计算最早时刻EET使用下述三条简单规则：考虑进入该事件的所有作业；对于每个作业都计算它的持续时间与起始事件的EET之和；选取上述和数中的最大值作为该事件的最早时刻EET。,24,11.2.1工程网络图,25,11.2.1工程网络图,事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。按惯例，最后一个事件（工程结束）的员迟时刻就是它的最早时刻。其他事件的员迟时刻在工程网络上从右至左按逆作业流的方向计算。计算最迟时刻LET使用下述三条规则：考虑离开该事件的所有作业；从每个作业的结束事件的最迟时刻中减去该作业的持续时间；选取上述差数中的最小值做为该事件的最迟时刻LET。,26,11.2.2关键路径,有几个事件的最早时刻和最迟时刻相同，这些事件定义了关键路径，在图中关键路径用粗线箭头表示。关键路径上的事件（关键事件）必须准时发生，组成关键路径的作业（关键作业）的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。工程项目的管理人员应该密切注视关键作业的进展情况，如果关键事件出现的时间比预计的时间晚，则会使最终完成项目的时间施后；如果希望缩短工期，只有往关键作业中增加资源才会有效果。,27,11.2.3机动时间,不在关键路径上的作业有一定程度的机动余地实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预计的持续时间长一些，而并不影响工程的结束时间。一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间：机动时间(LET)结束-(LET)开始-持续时间,28,11.2.4Gantt图（甘特图）,29,11.3人员组织,30,传统的管理结构是层次结构。在层次结构内，每一级人员向其上级报告工作并且管理下一级的人员。典型地，一个经理管理12-25个下级人员。管理软件开发通常也采用层次结构，但是，软件工程项目的管理很复杂，因此每个经理一般只直接管理6名下级人员。在同时从事多个软件开发项目的大型软件开发组织中，管理结构可能如同图13.5描绘的那样。软件经理负责管理软件开发部门，在各个项目间分配和协调各种资源。项目经理管理一个具体的开发项目的各个方面（计划、进度、审查和复审、用户界面等等），领导1-6个程序设计小组，每个小组负责项目的一部分开发工作（一个子系统的开发或系统开发的某些阶段）。审查小组从事质量保证活动，在项目开发的里程碑（例如，生命周期每个阶段结束之前）进行技术审查和管理复审。,31,11.3.1程序设计小组的组织,程序设计小组的人数不能太多，否则组员间彼此通信的时间将多于程序设计时间。此外，通常不能把一个软件系统划分成大量独立的单元，因此，如果程序设计小组人数太多，则每个组员所负责开发的程序单元与系统其他部分的界面将是复杂的，不仅出现接口错误的可能性增加，而且软件测试将既困难又费时间。一般说来，程序设计小组的规模应该比较小，以2-8名成员为宜。如果项目规模很大，用一个小组不能在预定时间内完成开发任务，则应该使用多个程序设计小组，每个小组承担工程项目的一部分任务，在一定程度上独立自主地完成各自的任务。系统的总体设计应该能够保证由各个小组负责开发的各部分之间的接口是良好定义的，并且是尽可能简单的。,32,11.3.1程序设计小组的组织,小组规模小，不仅可以减少通信问题，而且还有其他好处。例如，容易确定小组的质量标准，而且用民主方式确定的标准更容易被大家遵守；组员间关系密切，能够互相学习等等。小型的程序设计小组通常采用非正式的组织方式，也就是说，虽然名义上有一个组长，但是他和组内其他成员完成同样的任务。在这样的小组中，由全体讨论决定应该完成的工作，并且根据每个人的能力和经验分配适当的任务。如果组内多数成员是经验丰富技术熟练的程序员，那么上述非正式的组织方式可能会非常成功。在这样的小组内组员享有充分民主，通过协商，在自愿的基础上作出决定，因此能够增强团结、提高工作效率。但是，如果组内多数成员技术水平不高，或是缺乏经验的新手，那么这种非正式的组织方式也有严重缺点：由于没有明确的权威指导开发工程的进行，组员间将缺乏必要的协调，最终可能导致工程失败。为了使少数经验丰富、技术高超的程序员在软件开发过程中能够发挥更大作用，程序设计小组也可以来用下一小节中介绍的另外一种组织形式。,33,11.3.2主程序员组,美国IBM公司在70年代初期开始采用主程序员组的组织方式。采用这种组织方式主要出于下述几点考虑；软件开发人员多数比较缺乏经验；程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；多渠道通信很费时间，将降低程序员的生产率。主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支待，而且所有通信都通过一两个人进行。这种组织方式类似于外科手术小组的组织：主刀大夫对手术全面负责，并且完成制；订手术方案、开刀等关键工作，同时又有麻醉师、护士长等技术熟练的专门人员协助和配合他的工作。,34,11.3.2主程序员组,主程序员组的核心有3个人：主程序员是经验丰富能力强的高级程序员，全面负责系统的设计、编码、测试和安装。辅助程序员也应该技术熟练而且富于经验，他协助主程序员工作并且在必要时能代替主程序员。他的主要任务是设计测试方案和分析测试结果，以验证主程序员的工作。程序管理员完成和项目有关的全部事务性工作，例如，提交上机程序，保存运行记录，进行软件配置管理等。,35,11.3.2主程序员组,根据应用规模和类型，可能需临时或长期地往组内增加一些其他方面的专门人员，例如：项目管理员，负责行政后勤方面的管理事务。工具员，负责开发必要的软件工具。文档编辑，负责对主程序员或辅助程序员书写的文档进行编辑加工。语言和系统专家，他对正在使用的程序设计语言和系统的特点比较熟悉，他的任务是给主程序员提建议，以便更好地利用这些特点。测试员，任务是提出具体的测试方案，编写测试驱动程序和存根程序，并且进行测试以验证主程序员的工作。一个或多个后援程序员，他们的任务是按照主程序员的设计去编码。当项目规模很大，主程序员和辅助程序员无力独立完成详细的程序设计工作时，需在组内增加后援程序员。,36,11.4项目计划,37,对软件项目的有效管理取决于对项目的全面计划。根据美国联邦政府的调查统计，因软件计划不当而造成的项目失败数占失败总数的一半以上。制订计划时应该预见到可能发生的问题，并且预先准备好试探性的解决办法。下面讨论的计划适用于大型软件系统，这样的系统需要多个小组同时参加工作，才能在给定时间内完成项目开发任务。,38,11.4.1项目计划的内容,为大型软件开发项目所制定的计划通常包括下列基本内容：概述一般性地叙述开发项目，描述计划组织，并且概述这个文档其余部分的内容。阶段计划讨论项目开发周期需求分析阶段，总体设计阶段，详细设计阶段等等。详细说明每个阶段应该完成的日期，并且指出不同阶段可以互相重叠的时间等等。组织计划规定从事这个开发项目的每个小组的具体责任。测试计划概述应进行的测试和需要的工具，以及完成系统测试的过程和分工。在这一节中并不包括具体的测试方案。变动控制计划确定在系统开发过程中需求变动时的管理控制机制。文档计划这一节的目的是定义和管理与项目有关的文档。,39,培训计划培训从事开发工作的程序员和使用系统的用户的计划。复审和报告计划讨论如何报告项目的状况，并且确定对项目进展情况进行正式复审的计划。安装和运行计划描述在用户现场安装该系统的过程。资源和配置计划概述关键的细节计划进度、里程碑和按合同规定应该交付的系统配置成分。索引上述项目计划内容大部分已经在前面的章节中详细讨论过，本节只讨论项目报告和变动控制两个问题。,40,11.4.2项目报告,定期把有关项目进展情况的信息，反馈给管理人员是极端重要的。应该报告的信息通常包括：在这段时间内已经完成的工作；下阶段计划要完成的工作；问题范围；到目前为止已经用掉的成本；项目预算执行情况及其他有关的信息。没有这些信息管理人员就失掉了对项目的控制，也不能及时修正成本估计和进度计划。为项目制定计划时，应该确立一系列里程碑。在每个里程碑，开发人员都应该把正式的进展报告提交给管理人员。如果不能毫不含糊地判断是否计划中确定的里程碑已经到达，那么这样的里程碑就是毫无意义的。应该使一个里程碑代表项目开发过程中一个独特阶段的顶峰。好里程碑的特点通常是完成了某个文档，例如，“完成了总体设计”或“正式提出了测试计划”等。相反，像“完成了80编码工作”这样的里程碑是不好的，因为很难准确断定什么时候完成了80的编码工作。,41,11.4.3变动控制,任何软件开发都是迭代过程，也就是说，在设计软件时会发现需求说明中的问题，在实现过程中又会暴露出设计中的错误，如此等等。因此，变动既是必要的，又是不可避免的。但是，变动也很容易失去控制，因此，对于管理人员来说，预先计划控制变动的机制，建立评价变动的影响和把发生的变动记入文档的过程，就是十分重要的了。,42,11.4.3变动控制,变动通常可以分为两类：第一类是为了改正小错误需要的变动，第二类是为了增加或删掉某些功能，或者为了改变完成某个功能的方法而需要的变动。第一类变动是必须进行的，通常不需要从管理角度对这类变动进行审查和批准。但是，如果发现错误的阶段在造成错误的阶段的后面（例如，在实现阶段发现了设计错误），那么使用标准的变动控制过程，把这个变动正式记入文档，是十分必要的。这样做有可能保证：所有受这个变动影响的文档，实际上都做了相应的修改。,43,11.4.3变动控制,第二类变动总是需要经过从管理角度进行的审批过程。这类