《第13讲 软件项目管理.ppt》由会员分享，可在线阅读，更多相关《第13讲 软件项目管理.ppt（24页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、v 在经历了若干个大型软件工程项目的失败之后，人们才逐渐认识到软件项目管理的重要性和特殊性。事实上，这些项目的失败并不是由于从事软件开发工作的软件工程师无能，正相反，他们之中的绝大多数是当时杰出的技术专家。这些工程项目的失败主要是因为管理不善。一 项目规模估计v 1 代码行估算技术v 使用多名有经验的软件工程师,每个人估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3 种规模的平均值,和之后:v 代码行技术的主要优点是，代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。v 代码行技术的缺点是：源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太
2、合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程 语言。v 2 功能点技术 v 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。v 1.信息域特性 v 功能点技术定义了信息域的5 个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。下面讲述这5 个特性的含义。v（1）输入项数：用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。v（2）输出项数：软件向用户输出的项数，它们向用户提供面向应用
3、的信息，例如，报表和出错信息等。报表内的数据项不单独计数。v（3）查询数：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。v（4）主文件数：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。v（5）外部接口数：机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。估算功能点的步骤 v（1）计算未调整的功能点数UFP v 首先，把产品信息域的每个特性都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数。然后根据特性数目,对功能点数求和估算功能点的步骤v(2)计算技术复杂性因子TCFv 度
4、量14 种技术因素对软件规模的影响程度,每个因素分配0-5估算功能点的步骤v（3）计算功能点数FPv 用下式计算功能点数FP：v FP=UFPTCFv 功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。二工作量估算 v 软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC 或FP）的函数，工作量的单位通常是人月（pm)。v 支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。1 静态单变量模型 v
5、 这类模型的总体结构形式如下：E=A+B(ev)Cv 其中，A、B 和C 是由经验数据导出的常数，E 是以人月为单位的工作量，ev 是估算变量（KLOC 或FP）。下面给出几个典型的静态单变量模型。1 静态单变量模型 v 1.面向KLOC 的估算模型(1)Walston_Felix 模型 E=5.2(KLOC)0.91(2)Bailey_Basili 模型 E=5.5+0.73(KLOC)1.16(3)Boehm 简单模型 E=3.2(KLOC)1.05(4)Doty 模型（在KLOC9 时适用）E=5.288(KLOC)1.047v 2.面向FP 的估算模型(1)Albrecht&Gaffn
6、ey 模型 E=-13.39+0.0545FP(2)Maston,Barnett 和Mellichamp 模型 E=585.7+15.12FP2 动态多变量模型 v 动态多变量模型也称为软件方程式，它是根据从4000 多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下 v E=(LOCB0.333/P)3(1/t)4v 其中，E 是以人月或人年为单位的工作量；v t 是以月或年为单位的项目持续时间；v B 是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=515
7、），B=0.16,对于超过70 KLOC 的程序，B=0.39;v P 是生产率参数，它反映了下述因素对工作量的影响：v.总体过程成熟度及管理水平；v.使用良好的软件工程实践的程度；v.使用的程序设计语言的级别；v.软件环境的状态；v.软件项目组的技术及经验；v.应用系统的复杂程度。v 开发实时嵌入式软件时，P 的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。v 从式可以看出，开发同一个软件（即LOC 固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。3 COCOMO2 模
8、型 v COCOMO 是构造性成本模型（constructive cost model)的英文缩写 v COCOMO2 给出了3 个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。这3 个层次的估算模型分别是：v（1）应用系统组成模型。这个模型主要用于估算构建原型的工作量。v（2）早期设计模型。这个模型适用于体系结构设计阶段。v（3）后体系结构模型。这个模型适用于完成体系结构设计之后的软件开发阶段。3 COCOMO2 模型 v 体系结构模型为例，介绍COCOMO2 模型。该模型
9、把软件开发工作量表示成代码行数（KLOC）的非线性函数：其中，E 是开发工作量（以人月为单位），a 是模型系数，KLOC 是估计的源代码行数（以千行为单位），b 是模型指数，fi(i=117)是成本因素。v COCOMO2 使用的求b 的5 个分级因素如下所述(w=05)v（1）项目先例性。这个分级因素指出，对于开发组织来说该项目的新奇程度。诸如开发类似系统的经验，需要创新体系结构和算法，以及需要并行开发硬件和软件等因素的影响，都体现在这个分级因素中。v（2）开发灵活性。这个分级因素反映出，为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。v（3）风险排除度。这个分级因素反
10、映了重大风险已被消除的比例。在多数情况下，这个比例和指定了重要模块接口（即选定了体系结构）的比例密切相关。v（4）项目组凝聚力。这个分级因素表明了开发人员相互协作时可能存在的困难。这个因素反映了开发人员在目标和文化背景等方面相一致的程度，以及开发人员组成一个小组工作的经验。v（5）过程成熟度。这个分级因素反映了按照能力成熟度模型（见13.7 节）度量出的项目组织的过程成熟度。v 工作量方程中模型系数a 的典型值为3.0，在实际工作中应该根据历史经验数据确定一个适合本组织当前开发的项目类型的数值四 人员组织v 大多数软件的规模都很大，单个软件开发人员无法在给定期限内完成开发工作，因此，必须把多名
11、软件开发人员合理地组织起来，使他们有效地分工协作共同完成开发工作。1 民主制程序员组 v 民主制程序员组的一个重要特点是，小组成员完全平等，享有充分民主，通过协商做出技术决策。因此，小组成员之间的通信是平行的，如果小组内有n 个成员，则可能的通信信道共有n(n-1)/2 条。v 程序设计小组的人数不能太多,否则组员间彼此通信的时间将多于程序设计时间。此外,通常不能把一个软件系统划分成 大量独立的单元,因此,如果程序设计小组人数太多,则每个组员所负责开发的程序单元与系统其他部分的界面将是复杂的,不仅出现接口错误的可能性增加,而且 软件测试将既困难又费时间。v 一般说来，程序设计小组的规模应该比较
12、小,以2 8 名成员为宜。如果项目规模很大,用一个小组不能在预定时间内完 成开发任务,则应该使用多个程序设计小组,每个小组承担工程项目的一部分任务，在一定程度上独立自主地完成各自的任务。系统的总体设计应该能够保证由各个 小组负责开发的各部分之间的接口是良好定义的,并且是尽可能简单的。v 小组规模小,不仅可以减少通信问题,而且还有其他好处。例如,容易确定小组的质量标准,而且用民主方式确定的标准更容易被大家遵守;组员间关系密切,能够互相学习等等。民主制程序员组 v 民主制程序员组通常采用非正式的组织方式，也就是说，虽然名义上有一个组长，但是他和组内其他成员完成同样的任务。在这样的小组中，由全体讨论
13、协商决定应该完成的工作，并且根据每个人的能力和经验分配适当的任务。v 民主制程序员组的主要优点是，组员们对发现程序错误持积极的态度，这种态度有助于更快速地发现错误，从而导致高质量的代码。v 民主制程序员组的另一个优点是，组员们享有充分民主，小组有高度凝聚力，组内学术空气浓厚，有利于攻克技术难关。因此，当有难题需要解决时，也就是说，当所要开发的软件的技术难度较高时，采用民主制程序员组是适宜的。v 如果组内多数成员是经验丰富技术熟练的程序员,那么上述非正式的组织方式可能会非常成功。在这样的小组内组员享有 充分民主,通过协商,在自愿的基础上作出决定,因此能够增强团结、提高工作效率。但是,如果组内多数
14、成员技术水平不高,或是缺乏经验的新手,那么这种非正 式的组织方式也有严重缺点：由于没有明确的权威指导开发工程的进行,组员间将缺乏必要的协调,最终可能导致工程失败。2 主程序员组 v 主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行。2 主程序员组 v 主程序员组核心人员的分工如下所述：v（1）主程序员既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分（或复杂部分）的详细设计，并且负责指导其他程序员完 成详细设计和编码工作。如图13.5 所示，程序员之间没有通信渠
15、道，所有接口问题都由主程序员处理。主程序员对每行代码的质量负责，因此，他还要对组内其 他成员的工作成果进行复查。v（2）后备程序员也应该技术熟练而且富于经验，他协助主程序员工作并且在必要时（例如，主程序员生病、出差或“跳槽”）接替主程序员的工作。因此，后备程序员必 须在各方面都和主程序员一样优秀，并且对本项目的了解也应该和主程序员一样深入。平时，后备程序员的工作主要是，设计测试方案、分析测试结果及独立于设计 过程的其他工作。v（3）编程秘书负责完成与项目有关的全部事务性工作，例如，维护项目资料库和项目文档，编译、链接、执行源程序和测试用例。v 注意，上面介绍的是20 世纪70 年代初期的主程序
16、员组组织结构，现在的情况已经和当时大不相同了，程序员已经有了自己的终端或工作站，他们自己完成代码的输入、编辑、编译、链接和测试等工作，无须由编程秘书统一做这些工作。2 主程序员组 v 首先，如前所述，主程序员应该是高级程序员和优秀管理者的结合体。承担主程序员工作需要同时具备这两方面的才能，但是，在现实社会中这样的人才并不多见。通常，既缺乏成功的管理者也缺乏技术熟练的程序员。v 其次，后备程序员更难找。人们期望后备程序员像主程序员一样优秀，但是，他们必须坐在“替补席”上，拿着较低的工资等待随时接替主程序员的工作。几乎没有一个高级程序员或高级管理人员愿意接受这样的工作。v 第三，编程秘书也很难找到
17、。专业的软件技术人员一般都厌烦日常的事务性工作，但是，人们却期望编程秘书整天只干这类工作。3 现代程序员组 v 技术组长自然要参与全部代码审查工作，因为他要对代码的各方面质量负责；相反，行政组长不可以参与代码审查工作，因为他的职责是对程序员的业绩进行评价。行政组长应该在常规调度会议上了解每名组员的技术能力和工作业绩。3 现代程序员组 v 由于程序员组成员人数不宜过多，当软件项目规模较大时，应该把程序员分成若干个小组，采用图13.7 所示的组织结构。该图描绘的是技术管理组织结构，非技 术管理组织结构与此类似。由图可以看出，产品开发作为一个整体是在项目经理的指导下进行的，程序员向他们的组长汇报工作，而组长则向项目经理汇报工作。当 产品规模更大时，可以适当增加中间管理层次。3 现代程序员组 v 把民主制程序员组和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法，如图13.8 所示。这样做有利于形成畅通的通信渠道，以 便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。这种组织方式对于适合采用民主方法的那类问题（例如，研究性项目或遇到技术难题需要用集体 智慧攻关）非常有效。尽管这种组织方式适当地发扬了民主，但是上下级之间的箭头（即管理关系）仍然是向下的，也就是说，是在集中指导下发扬民主。显然，如 果程序员可以指挥项目经理，则只会引起混乱。