软件项目管理.doc

软件工程导论讲义2010版：第六讲 软件项目管理第六讲 软件项目管理一、 软件开发工作量估算1、 软件规模估算（1） 代码行技术代码行技术是以历史经验和任务分析为基础,估算软件的源程序代码行数，以此作为软件的规模，一般单位为KLOC（Kilo-Line Of Code）。代码行技术的优点是简单直接，缺点是不适用于非过程语言，并且采用不同的编程语言代码行差距也比较大。（2）功能点技术（FP）功能点技术是以软件“功能点”（Function Point）为单位来估算软件规模的方法，它是从软件的逻辑功能和复杂性程度两方面来对软件规模进行度量。需要注意的是：一个功能点并不是软件的一项功能，而是包含输入、输出、处理等多方面复杂程度的度量单位。使用功能点技术进行软件规模估算，其基本思路是首先计算功能点的数量，再根据各种因素进行调整。具体步骤为：第一步，计算每个模块的未调整功能点数UFP：信息域 复杂级别特性系数简单平均复杂输入项数Inp输入系数a1346输出项数Out输出系数a2457查询数Inq查询系数a3346主文件数Maf文件系数a471015外部接口数Inf接口系数a55710UFPa1Inp a2Out a3Inq a4Maf a5Inf第二步，计算技术复杂性因子TCF技术复杂性因子由14个方面的技术因素构成，显示了各种技术因素对软件复杂度的影响。，TCF的值在0.651.35之间。各项技术因素的含义分别为：序号Fi技术因素1F1数据通信2F2分布式数据处理3F3性能标准4F4高负荷的硬件5F5高处理率6F6联机数据输入7F7终端用户效率8F8联机更新9F9复杂的计算10F10可重用性11F11安装方便12F12操作方便13F13可移植性14F14可维护性第三步，计算功能点数FP：FPUFPTCF功能点技术的优点是比较准确可信，与编程语言无关，缺点是在各项技术因素的复杂因子取值时有很大的主观性。2、软件开发工作量估算（人月） 软件开发的工作量是软件规模的函数，但是由于软件开发的复杂性，其函数关系只能总结出一些经验公式，缺乏通用的模型。（1）静态单变量模型静态单变量模型是指软件开发的工作量仅仅是软件规模的函数，通常具有如下的形式：E=A+B(ev)C其中E是估算的工作量（单位是人月），A、B、C是经验常数，ev是估算变量，代表软件规模。常用的静态单变量模型有：l 面向代码行的模型Walston_Felix模型： E=5.2(KLOC)0.91Bailey_Basili模型： E=5.5+0.73(KLOC)1.16Boehm简单模型： E=3.2(KLOC)1.05Doty模型（KLOC9时）： E=5.288(KLOC)1.047l 面向功能点的模型Albrecht & Gaffney模型： E= -13.39+0.0545FPMaston,Barnett和Mellichamp模型： E=585.7+15.15FP2）动态多变量模型动态多变量模型也称为“软件方程式”，它是从4000多个软件项目中搜集的数据推导出的经验公式，在该模型中软件开发的工作量是软件规模、软件复杂度、开发单位的开发能力和项目持续时间等多个变量的函数。具体公式为：E=（LOCB0.333/P）3（1/t）4E：估算的工作量LOC：代码行数B：特殊技术因子，随着软件规模和过程复杂度增加，对于较小的程序（KLOC515），B0.16；对于超过70KLOC的程序，B0.39；P：生产率系数，反映开发单位的软件开发能力和软件的复杂程度之间的关系，可从开发单位的历史数据中计算得到，典型值在2000到28000之间；t：项目持续时间 从公式可以看出，软件开发的工作量与软件规模的3次幂成正比，与生产率的3次幂成反比，与项目持续时间的4次幂成反比。（3）COCOMO2模型 COCOMO模型（构造性成本模型Constructive cost model）由Boehm在1981年首次提出，1997年升级为COCOMO2模型。 COCOMO2分为三个层次的模型，分别用于不同阶段或不同类型的软件开发项目：l 应用系统组成模型：用于估算构建原型的工作量，在构建是要采用大量的可重用构件。l 早期设计模型：用于估算体系结构设计的工作量。l 后体系结构模型： 用于完成体系结构设计后到软件完全实现的软件开发工作量以后体系结构模型为例，其工作量估算值是软件规模的幂函数，但由多项系数进行修正：a：模型系数，与历史开发数据有关，典型值为3.0 KLOC：代码行数 b：模型指数， 模型指数b由5个分级因素决定：l 项目先例性l 开发灵活性l 风险排除度l 项目组凝聚力l 过程成熟度每个因素赋予一个05的值Wi，取值越高表示对工作量的增长影响越大。最终的b值为：因此b的取值范围为1.011.26。 fi（i=117）：成本因素成本因素fi分为4类，根据其重要程度和对于工作量影响的大小赋予一定的值。 二、 人员组织软件开发项目的人员组织主要指开发小组的组织模式。人员组织的目标是既能增强开发小组整体的开发能力，保证开发的进度和质量。在软件工程的发展历史上，出现过以下几种人员组织方式。1、 民主制程序员组民主制程序员组中的程序员没有等级区别，完全平等，通过协商进行任务分配和技术决策。因为每个人的主动性和工作积极性都能得到激发和保护，团队的凝聚力比较强，规则和标准比较容易形成和遵守，同时团队内的信息共享和知识流动也比较顺畅。民主制程序员组的缺点在于通讯路径太多，同时因为缺少权威指导，要求所有成员都具有较高的技术水平和工作热情，对外接口也不太明确，团队开发工作容易受到各种外力的影响。2、 主程序员组主程序员组最早在IBM公司采用，他是由一个技术能力强、开发经验丰富的主程序员为核心来构建开发小组，所有小组成员都只与主程序员之间建立通讯管道，避免了整个开发小组的通讯路径呈指数性增长，也可以使最重要的开发工作被有效地控制，保证软件开发的进度和质量。在主程序员组中，主程序员是开发小组的领导，工作安排、技术决策、对外接口都由他来承担，同时主程序员还要完成几乎所有的关键性技术工作，包括分析、设计、编码、测试及文档撰写。主程序员有两个助手：行政秘书和后备程序员。行政秘书负责在主程序员的领导下具体管理财务、人事、后勤等各方面的具体事务，减轻主程序员的工作量。后备程序员是主程序员的备份，他虽然不做决策，但要协助主程序员完成各项工作，详细了解开发工作的所有细节，以在需要的时候随时代替主程序员。在主程序员组中，还有若干程序员，他们接受主程序员分配的任务，完成具体模块的设计、编程和测试，其工作结果由主程序员负责审查和接纳。主程序员组就是Brooks在人月神话里推荐的“外科手术小组”的人员组织方式，其优点是能保持概念的完整性，团队接口简单，内部通讯代价低，团队成员的分工明确，工作效率理论上会比较高，主程序员的水平也可以保证软件的质量。但是这种人员组织模式在现实中确会遇到很多问题，例如主程序员的工作压力太大，对他在技术和管理上双重的能力要求不容易满足，团队其它成员工作积极性不高，最后很容易变成一个人享受好的待遇，但在巨大压力下单打独斗。3、 双组长制双领导制是在一个开发小组中，设立技术组长和行政组长两个领导：技术组长类似于主程序员，主要负责小组的技术决策和开发管理；行政组长则负责人事、后勤、业绩考核等工作，两个组长是平级的。双组长制可以避免主程序员陷入大量行政事务管理中耗费时间和精力，又可以避免对程序员的开发结果技术审查与工作业绩考核挂钩，更好地保障软件开发质量，同时整个团队的通讯路径也比较少，工作效率高。这种人员组织方式必须建立在两个组长配合默契，沟通良好的基础上，彼此权限的协调决定了开发工作的管理模式和效率，这是天然的困难之处。同时，每个程序员仍然是被动的开发主体，积极性不容易调动。在微软公司的早期产品开发阶段，双组长制是主要的人员组织模式。三、 进度计划软件开发的进度保障是软件工程要解决的主要问题之一。对于整体如何估算和控制开发进度，目前的方法以时间段分解为主。当一个长期的软件开发过程被分解为小的阶段时，进度的估计和管理都会变得比较容易。需要注意的问题是：在一定的开发工作量下，开发时间不会因为开发人员的数量增加而线性下降。开发人员越多，沟通和协调的代价越大，根据Boehm的研究，软件项目的开发时间最多只能减少到正常开发时间的75%。而在已经落后的项目中增加人员，不仅不会缩短开发时间，而且会使得进度更加延后。除了时间分解的方法，软件开发中还会大量遇到开发任务耦合的问题。当多个开发任务存在相互关联和依存时，如何安排和协调开发顺序就变得非常重要。下面介绍两种在软件开发项目中进行任务安排的实用工具。1、 甘特图甘特图是由亨利劳伦斯甘特（Henry Laurence Gantt,18611919）在一战期间发明的，由于它简单有效，成为了 工程项目中历史最悠久、应用最为广泛的进度计划工具。甘特图由横道图形表示出各项任务的开始和结束时间，并可以纵向比较和协调安排。例如：要开发三个类，它们之间存在关系，对每个类的开发工作量估算如下： 定义时间（天）实现时间（天）测试时间（天）类 A233类 B242类 C222总体003由于每个类的定义、实现、测试都需要顺序进行，而类B的测试必须在类A的测试结束后才能进行，类C的定义必须在类B的定义结束后才能进行，可以画出甘特图如下：时间任务 123456789101112131415类A定义类A实现类A测试类B定义类B实现类B测试类C定义类C实现类C测试总体测试甘特图不仅可以表示各任务的进度，更重要的是它可以用于安排人力，甘特图的纵向线就表示了当前同时需要并行完成的任务数量，也就是需要的人力和资源数量。2、 工程网络工程网络是另一种非常有效的进度计划图形工具，它不仅可以描述各项任务的开始和结束时间，而且可以非常清楚地表达任务之间的依赖关系。在工程网络中，用圆圈表示事件，是任务的开始和结束，带箭头的实线段表示具体执行的任务，带箭头的虚线段表示事件间的依赖关系。圆圈左半部的数字代表事件编号，右上部的数字为该事件允许发生的最早时间EET，右下部的数字表示该事件允许发生的最晚时间LET。（1）计算EET整个工程网络的第一个事件的EET为0，然后顺序计算各个事件的最早时间EET：a、考虑进入该事件的所有任务；b、对于每个任务都计算它的持续时间与最早开始时间之和；c、选取上述和数中最大值为该事件的最早时间EET。（2）计算LET整个工程网络的最后一个事件的LET等于其EET，然后逆序计算各个事件的最晚时间LET：a、考虑离开该事件的所有任务；b、对于每个任务都计算它的最晚结束时间与持续时间之差；c、选取上述差值中