软件项目管理第十至十三章.ppt

第四篇 软件项目管理,计划（第十章） 组织（第十一章） 控制（第十二章） 国际标准（第十三章）,第十章 计划,如何度量软件规模？ 如何估算工作量？ 如何估算进度计划？,所谓管理就是通过计划、组织和控制等一系列的活动，合理地配置和使用各种资源，以达到既定目标的过程 项目管理优先于任何技术活动之前开始，并贯穿于软件的整个生命周期之中。 第一项计划活动是“估算”，它是所有其它项目计划活动的基础，而项目计划为软件工程指出了通往成功的道路。 估算包括“工作量估算”和“完成期限估算”,10.1 度量软件规模,软件度量域的分类,软件生产率度量的焦点集中在软件工程过程的输出； 软件质量度量则指明了软件适应明确和不明确的用户要求到什么程度； 技术度量的焦点则集中在软件的某些特性（如逻辑复杂性、模块化程度）上而不是软件开发的全过程。,另一种分类方法,面向规模的的度量用于收集与直接度量有关的软件工程输出的信息和质量信息。 面向功能的度量提供直接度量的尺度。 面向人的度量则收集有关人们开发计算机软件所用方式的信息和人们理解有关工具和方法的效率的信息。,面向规模的度量,面向规模的度量是对软件和软件开发过程的直接度量。 可以建立一个面向规模的数据表格来记录项目的某些信息。 该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。,面向规模的数据表格,项目aaa-01 规模为 114.1 KLOC（千代码行） 工作量用了 24个人月 成本为168,000元 文档页数为365 在交付用户使用后第一年内发现了29个错误， 有3个人参加了项目aaa-01的软件开发工作。,需要注意的是，在表格中记载的工作量和成本是整个软件工程的活动（分析、设计、编码和测试），而不仅仅是编码活动。 对于每一个项目，可以根据表格中列出的基本数据计算简单的面向规模的生产率和质量的度量。,根据数据表格可以对所有的项目计算出平均值： 生产率 KLOCPM（人月） 质量 错误数KLOC 成本 元LOC 文档 文档页数KLOC,代码行技术比较简单的定量估算软件规模的方法。 根据以往类似项目的历史数据，多名有经验的工程师分别估计程序的最小规模(a)、可能规模(m)、最大规模(b)，分别计算平均值。记作a*、m*、b*。 用下式计算程序规模的估计值L。 L （a*4m*b*）6,10.1.1 代码行技术,代码行是所有软件开发项目都有的“产品”，容易计算 许多现有的软件估算模型使用LOC或KLOC作为关键的输入数据 已有大量基于代码行的文献和数据存在,代码行技术的优点：,源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模不合理 用不同的语言实现同一个软件产品所需要的代码行数并不相同 这种方法不适用于非过程语言,代码行技术的缺点：,10.1.2 功能点技术,功能点技术利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点FP。,（1）输入项数（Inp） （2）输出项数（Out） （3）查询数（Inq） （4）主文件数（Maf） （5）外部接口数（Inf）,信息域的特性包括：,（1）计算未调整的功能点数,首先把产品信息域的每个特性都分类成简单级、平均级或复杂级。根据其等级，为每个特性都分配一个功能点数，例如一个平均级的输入项分配4个功能点，一个简单级输入项是三个功能点，一个复杂级的输入项分配6个功能点。如下计算未调整的功能点数： UFP=a1Inpa2outa3Inqa4Mafa5Inf，其中，ai是信息域特性系数,面向功能的数据表格,（2）计算功能点FP,将14种技术因素对软件规模的影响程度根据软件特点，为每个因素分配一个从0到5的值。 计算功能点，使用如下的关系式： FP UFPTCF UFP( 0.65 + 0.01SUM ( Fi ) ),Fi（i114）是复杂性校正值，它们应通过逐一回答如下提问来确定。 Fi的取值05： 0 没有影响 1 偶然的 2 适中的 3 普通的 4 重要的 5 极重要的 SUM（Fi）是求和函数。,复杂性校正值 Fi,1. 系统是否需要可靠的备份和恢复？ 2. 是否需要数据通信？ 3. 是否有分布处理的功能？ 4. 是否性能成为关键？ 5. 系统是否运行在既存的高度实用化的操作环境中？ 6. 系统是否需要联机数据项？,7. 联机数据项是否需要建立多重窗口显示和操作，以处理输入处理。 8. 主文件是否联机更新？ 9. 输入、输出、文件、查询是否复杂？ 10. 内部处理过程是否复杂？ 11. 程序代码是否可复用？ 12. 设计中是否包括了转移和安装？ 13. 系统是否设计成可以重复安装在不同机构中 14. 系统是否设计成易修改和易使用？,10.2 工作量估算,10.2.1 静态单变量模型,形式如下： E=A+B(ev)C 其中，A、B、C是经验导出的常数，E是以人月为单位的工作量，ev是估算变量（LOC或FP）。,1、面向LOC的估算模型： （1）WalstonFelix模型： E=5.2(KLOC)0.91 （2）BaileyBasili模型 E=5.50.73(KLOC)1.16 （3）Boehm简单模型 E=3.2(KLOC)1.05 （4）Doty模型（在KLOC9的情况下） E=5.288(KLOC)1.047,2、面向FP的估算模型： （1）Albrecht&Gaffney模型： E=-13.39+0.0545FP （2）Kemerer模型 E=60.627.72810-8FP3 （3）Maston、Barnett和Mellichamp模型 E=585.7+5.12FP,10.2.2 动态多变量模型,形式如下： E=LOCB0.333/P3(1/t)4 其中，E是以人月或人年为单位的工作量 t是以月或年为单位的项目持续时间 B是“特殊技术因子”，它随着对集成、测试、质量保证、文档及管理技术的需求的增长而缓慢增加。 P是“生产率参数”，它反映了下述因素对工作量的影响：总体的过程成熟度及管理水平；使用良好的软件工程实践的程度；软件环境状态；软件项目组的技术及经验；应用系统的复杂程度,软件方程式有两个独立变量： 对软件规模的估算值（用LOC表示）； 以月或年为单位的项目持续时间 开发同一个软件的时候，如果把项目持续时间延长一些，则可降低完成项目所需要的工作量,COCOMO模型 （COnstructive COst MOdel）,结构型成本估算模型是一种精确、易于使用的成本估算方法。在该模型中使用的基本量有以下几个： DSI（源指令条数）定义为代码的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。KDSI1000DSI。,COCOMO模型的分类 COCOMO模型按其详细程度分成三级： 基本COCOMO模型 中间COCOMO模型 详细COCOMO模型 基本COCOMO模型是一个静态单变量模型，它用源代码行数（LOC）为自变量的（经验）函数来计算软件开发工作量。,中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量（此时称为名义工作量）的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。 高级COCOMO模型包括中级CO COMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。,中级COCOMO模型,进一步考虑15种影响软件工作量的因素，通过定下乘法因子，修正COCOMO工作量公式和进度公式，可以更合理地估算软件（各阶段）的工作量和进度。 中间COCOMO模型把软件开发工作量表示成代码行数的非线性函数：,MM=C1KLOCa MM（度量单位为人月）表示开发工作量。 C1是模型系数 KLOC是估计的代码行数（以千行为单位） a是模型指数 fi（i=1到15）成本因素,15种影响软件工作量的因素 fi,产品因素：软件可靠性、数据库规模、产品复杂性 硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间 人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验 项目因素：现代程序设计技术、软件工具的使用、开发进度限制,软件开发项目的分类 软件开发项目的总体类型: 组织型 嵌入型 半独立型,中级COCOMO模型系数与模型指数,例1. 一个32KDSI的声音输入系统是一个输入原型，或是一个可行性表演模型。所需可靠性非常低。把此模型看做半独立型软件。则有 MM 3.0（32）1.12 146 又查表知 f10.75，其它 fi1.00，则最终有MM 1460.75 109.5,例14. 一个规模为10KDSI的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算。 MM 44.38 44.381.17 51.5（MM）,详细COCOMO模型,详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO模型相同。 工作量因素分级表分层、分阶段给出。针对每一个影响因素，按模块层、子系统层、系统层，有三张工作量因素分级表，供不同层次的估算使用。每一张表中工作量因素又按开发各个不同阶段给出。,例如，关于软件可靠性（RELY）要求的工作量因素分级表（子系统层），如表所示。 使用这些表格，可以比中间COCO MO模型更方便、更准确地估算软件开发工作量。,10.3 进度计划,项目管理者的目标是定义所有项目任务，识别出关键任务，跟踪关键任务的进展情况，以保证能够及时发现拖延进度的情况。 为此管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。,项目管理者的目标是定义所有项目任务，识别出关键任务，跟踪关键任务的进展情况，以保证能够及时发现拖延进度的情况。 为此管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。,常用的制定进度计划的工具主要有Gantt图和工程网络两种。 Gantt图历史悠久、直观简明、容易学习、容易绘制等优点。但是，它不能显式地表示各项任务彼此间的依赖关系，也不能显式地表示关键路径和关键任务，进度计划中的关键部分不明确。因此，在管理大型软件项目时，仅用Gantt图是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。,工程网络不仅能描绘任务分解的情况及每项作业的开始时间和结束时间，而且还能显式地表示各个作业彼此间的依赖关系。 从工程网络图中容易识别出关键路径和关键任务。因此，工程网络是制定进度计划的强有力的工具。 通常联合使用Gantt图和工程网络这两种工具来制定和管理进度计划，使它们互相补充取长补短。,第十一章 组 织,民主制程序员组 主程序员组 现代程序员组 软件项目组,11.1 民主制程序员组,主要优点：对发现错误抱着积极的态度，这种积极的态度有助于更快速地发现错误，从而得到高质量的代码。 另一个优点是：小组成员享有充分民主，小组有高度凝聚力，组内学术空气浓厚，有利于攻克难关。 因此，当所要开发的产品的技术难度较高时，采用民主制程序员组是适宜的,如果组内多数成员水平不高，或是缺乏经验的新手，那么这种非正式的组织方式也有严重缺点：由于没有明确的权威指导开发工程的进行，组员间将缺乏必要的协调，最终可能导致工程失败,11.2 主程序员组,关键特性： 专业化。该组每名成员仅完成那些他们受过专业训练的工作 层次性。主程序员对工程全面负责。,核心人员分工如下： 主程序员：既是成功的管理人员又是经验丰富能力强的高级程序员。 后备程序员：也是技术熟练而且富于经验，他协助主程序员的工作，在必要时接替主程序员的工作。 编程秘书：负责完成与项目有关的全部事务性工作。,11.3 现代程序员组,主程序员由两个人来担任：一个是技术负责人，负责技术活动；一个是行政负责人，负责所有非技术的管理决策。 技术组长只对技术负责，行政组长全权负责非技术事务。,将民主制程序员和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法。这样有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性。,11.4 软件项目组,三种组织方式： 民主分权制 控制分权制 控制集权式,四种组织范型： 封闭式范型 随机式范型 开放式范型 同步式范型,第十二章 控 制,风险管理 质量保证 配置管理,控制是十分重要的管理活动，就是掌握被控制的对象，不让它任意活动或超出规定范围活动，尽量使一切活动都按照预定的计划进行，向预期的目标前进。,每当新建一个程序时，总是存在某些不确定性。 用户要求是否能确切地被理解？ 在项目最后结束之前要求实现的功能能否建立？ 是否存在目前仍未发现的技术难题？ 在项目出现严重误期时是否 会发生一些变更？等等。,12.1 风险管理,风险分析对于软件项目管理是决定性的，然而现在还有许多项目不考虑风险就着手进行。 所谓风险分析实际上就是一系列风险管理步骤，其中包括风险识别、风险估计、风险优化、风险管理策略、风险解决和风险监督。这些步骤贯穿在软件工程过程中。,对付风险应当采取主动的策略，在工作开始之前就应该启动风险管理活动： 标识出潜在的风险 评估它们出现的概率和影响 按重要性排序,风险管理的主要目标是预防风险，但是并非所有风险都能预防，因此还需要制定一个计划来管理风险。,风险有两个特点： 不确定性：可能发生也可能不发生 损失：如果风险变成现实就有可能造成损失,12.1.1 软件风险分类,风险的分类： 按影响范围分类： 项目风险，技术风险，商业风险 按可预测性分类： 已知风险，可预测的风险，不可预测的风险,采用建立风险条目检查表的方法，可集中精力识别下列已知的和可预测的风险： 产品规模，商业影响，客户特性，过程定义，开发环境，所用技术，人员数目与经验,12.1.2 风险识别,1.评估风险后果 性能风险，成本风险，支持风险，进度风险 2.建立风险表,12.1.3 风险预测,1. 风险缓解 2.风险监控 3.风险管理和意外事件计划,12.1.4 处理风险的策略,软件质量 软件质量是软件符合明确地叙述的功能和性能要求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。 影响软件质量的主要因素是从管理角度对软件质量的度量：,12.2 质量保证,影响软件质量的主要因素是从管理角度对软件质量的度量，它们分别反映用户在使用软件产品时的三种不同的倾向或观点： 产品运行 产品修改 产品转移,软件质量保证措施： 复审 走查 审查 程序正确性证明,软件配置 软件质量是软件符合明确地叙述的功能和性能要求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。 影响软件质量的主要因素是从管理角度对软件质量的度量：,12.2 配置管理,软件配置管理,在软件建立时变更是不可避免的，因为在进行变更前没有仔细分析，或没有进行变更控制，变更加剧了项目中软件人员之间的混乱。 协调软件开发使得混乱减到最小的技术叫做配置管理。 配置管理是一组标识、组织和控制修改的活动，目的是使错误达到最小并最有效地提高生产率。,软件配置管理的概念,软件配置管理，简称SCM，是一种“保护伞”活动，它应用于整个软件工程过程。 SCM活动的目标是为了 (1) 标识变更； (2) 控制变更； (3) 确保变更正确地实现； (4) 向其他有关的人报告变更。,在软件工程过程中产生的所有信息项（文档、报告、程序、表格、数据）构成了软件配置。 软件配置是软件的具体形态在某一时刻的瞬时影像。 随着软件工程过程的进展，软件配置项(SCI)数目快速增加。系统规格说明可繁衍出软件项目实施计划和软件需求规格说明。它们又依次繁衍出建立信息层次的其它文档。,基线 (Baseline),基线是软件生存期中各开发阶段末尾的特定点，又称里程碑。 由正式的技术评审而得到的SCI协议和软件配置的正式文本才能成为基线。 基线的作用是把各阶段工作的划分更加明确化，以便于检验和肯定阶段成果。,软件开发各阶段的基线,软件配置管理过程,软件配置管理（SCM）的任务是： 标识软件配置中的对象 版本控制 变化控制 配置审计 状态报告,第十三章 国际标准,在IEEE标准1058.1中给出了软件项目管理计划的框架，它实质上是一