《软件工程》第14章 软件项目管理.ppt

1、第 14 章软件项目管理,邢承杰 北京大学计算中心管理信息中心 E-mail: ,我们的目标,Project Manager！ 项目经理（微软） ：是负责并保证高质量的软件产品按时完成和发布的专职管理人员。他的任务包括倾听用户需求；负责产品功能的定义、规划和设计；做各种复杂决策，保证开发队伍顺利开展工作及跟踪程序错误等。总之，项目经理全权负责产品的最终完成。,中美软件项目现状对比,国际Standish Group, CHAOS, 2000统计报告 只有28%IT项目成功，不幸的是，72%都是失败。 国内 中国计算机报报道：在为政府和企业做相关应用软件的实施成功率不超过30%,本章主要内容,14

2、.1软件项目管理的概念 14.2软件度量 14.3成本管理 14.4时间管理 14.5风险分析和管理 14.6软件配置管理,14.1 软件项目管理的概念,What is Project Management? 为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。 Project management is the application of knowledge , skills , tools , and techniques to project activities in order to meet or exceed stake

3、holder needs and expectations from a project.,项目管理的历史和发展1,古代,项目管理的历史和发展2,近代 萌芽：公认为20世纪40年代，“曼哈顿计划” 成熟：50年代，关键路线法（CPM）和计划评审技术(PERT）， 阿波罗登月计划 传播和现代化 20世纪7080年代，面向市场，迎接竞争，初步形成现代项目管理的框架 新发展 20世纪90年代 注重人的因素 注重顾客 注重柔性管理 注重管理工具 应用领域扩大：IT （软件）项目管理,项目管理的历史和发展3,软件项目管理最早源于70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70的项

4、目是由于管理不善引起的，而并不是应为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只是影响局部。 到了90年代中期，软件项目管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10的项目能够在预定的费用和进度下交付。 目前，软件项目管理许多技术还很不成熟。但一些大型软件公司多采用一定的标准规范如CMM和ISO9000，以及一些软件项目管理辅助工具进行软件项目管理，并取得了较好的效果。,软件项目管理的特点,软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。 软件系统的复杂性也导致了开发过程中各种风险的难以

5、预见和控制。 例：Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。 结论：软件的管理比其它领域的管理要复杂的多。,软件项目的三约束,项目管理的五个阶段,项目启动阶段 项目计划阶段 项目实施阶段 项目控制阶段 项目收尾阶段,项目阶段,每一个项目阶段的标记是一个或几个可倨傲府的物件，物件是一个具体的可验证的工作产品，如可行性研究，详细设计或者一个工作原型。 项目阶段的结束是由关键交付物或者项目性能作为标记的，以确定项目是否能够继续进行下一阶段或者检测和修正错误。,项目管理框架图,项目管理知识要学什么？,以上三个约束、五个阶段和九大知识领域，统

6、称为“项目管理的三五九”。 “项目管理的三五九”就是我们项目管理要学习和研究的内容。 将项目管理的九大知识领域的知识，运用在项目管理的五个阶段中，以平衡和满足项目的三个约束条件。,本章主要内容,14.1软件项目管理的概念 14.2软件度量 14.3成本管理 14.4时间管理 14.5风险分析和管理 14.6软件配置管理,14.2 软件度量（metrics）,软件度量：是软件产品、软件开发过程、资源和环境等的定量描述。如程序规模、操作符个数、程序中错误的个数等。,软件度量的目标,管理人员 每个过程所耗费的成本是多少？ 所有成员的生产力如何？ 正在开发的代码质量如何？ 用户对产品是否满意？ 如何改

7、进？ 工程师 需求是不是可以测试的？ 是否发现了所有的缺陷？ 是否实现了产品和过程目标？ 今后会出现什么情况？ ,软件度量的作用,刻画（characterize） 获得理解、发现问题、确定改进的目标。 评估（evaluate） 期望与实际相比较 预测（predict） 由已知要素推算、估计其它要素 改进（improve） 识别问题、查找问题的根源,软件度量的一般步骤,软件度量的组成部分,度量方法面向规模的度量,面向规模的度量是通过规范化质量和生产率的测量而得到的，这些测量是基于所生产的软件的规模。 代码行估算方法 计算： 软件项目的生产率 每行代码的平均成本 文档与代码比 代码出错率,代码行估

8、算软件规模的优缺点,优点： 简单，容易实行 缺点： 代码行数的估算依赖于程序设计语言的功能和表达能力； 采用代码行估算方法会对设计精巧的软件项目产生不利的影响； 代码行估算只适用于过程式程序设计语言，不太适用于非过程式的程序设计语言。,度量方法面向功能的度量,面向功能的软件度量使用软件所提供的功能的测量作为规范化值。因为功能不是直接测量的，所以必须通过利用其它直接的测量来间接的导出。 软件功能点度量方法 FP=CT 0.65+0.01Fi CT: 总计数值，是5个信息量的加权和 Fi : 14个因素的复杂性调节值 以上公式中的常量值和被应用的加权因子是根据经验确定的,5个信息量定义,用户输入数

9、：计算每个用户输入，输入向软件提供不同的面向应用的数据。 用户输出数：计算每个用户输出，输出向用户提供面向应用的信息。主要指的是报表、屏幕、出错信息等等。 用户查询数：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。 文件数：计算每个逻辑的主文件。 外部接口数：计算所有机器可读的接口。,总计数值计算,14个因素,系统需要可靠的备份和恢复吗？ 需要数据通信吗？ 有分布处理功能吗？ 性能很关键吗？ 系统是否在一个现存的、重负的操作环境中运行？ 系统需要联机数据登录？ 联机数据登录是否需要在多屏幕或多操作之间切换以完成输入？ 需要联机更新主文件吗？

10、输入、输出、文件或查询很复杂吗？ 内部处理复杂吗？ 代码需要被设计成可复用的吗？ 设计中需要包括转换及安装吗？ 系统的设计支持不同组织的多次安装吗？ 应用的设计方便用户修改和使用吗？ 对每个问题的回答的取值范围为0-5,功能点度量方法的优缺点,优点： 与程序设计语言无关，适用于过程式与非过程式语言； 功能点度量能适用于软件项目的开发初期。 缺点： 涉及到的主观因素比较多，如各种权函数的取值； 信息领域中的某些数据有时不容易采集； FP的值没有直观的物理意义。,本章主要内容,14.1软件项目管理的概念 14.2软件度量 14.3成本管理 14.4时间管理 14.5风险分析和管理 14.6软件配置

11、管理,14.3 软件项目成本管理,成本估算的原则 估算中的计量单位 成本估算方法 软件效益分析,软件的成本是以一次性开发过程中所花费的代价来计算的，也就是软件计划、需求分析、设计、编码、测试的全过程中所付出的费用作为软件的开发成本。 对软件成本的估算中存在着许多可变因素，如人的素质、技术水平、环境等，所以想要准确估算软件开发成本不是一件容易的事。同时如果软件成本的估算有大的偏差，将造成整个系统费用估计的错误，严重的会导致软件项目开发的失败。,成本估算中的原则,项目范围必须被精确定义 任务和功能的分解是必须的 历史的度量数据是非常有帮助的 至少要使用两种估算方法 不确定性是不可避免的,估算中的计

12、量单位,代码行数 软件是代码行的集合。 一个软件的代码行总数是软件成本估算中的基本数据。 开发工作量 开发工作量是指完成一项开发任务所需要的计量单位， 软件工程中用于计量开发工作量的单位主要有“人-月”，“人-年”，“人-日”。 如：某个项目需5人-月的工作量，它表示该项目的开发工作量实际为5每个程序员一个月应完成的“标准劳动量”。,常规的成本估算技术 代码行估算法（LOC） 功能点估算法（FP） 运用估算模型进行成本估算（完全经验） 静态单变量模型 COCOMO模型 动态多变量模型 使用自动估算工具进行估算 利用软件工具进行自动估算。须长期搜集大量的历史资料、数据和建立良好的数据库管理系统。

13、,成本估算方法（技术）,代码行估算法举例,功能点估算法举例,静态单变量模型,工作量K（人-月）= 5.2 L0.91 项目所需时间T（月）= 4.1 L0.36 文档页数DOC = 49 L1.01 需要人数S = 0.54 K0.6 上述公式是从60个已完成的项目中收集到的数据而得到的。,COCOMO模型,构造性成本模型（COnstructive Cost MOdel） 以静态但变量模型为基础，在两个方面进行扩充 考虑软件项目的特性，将软件项目按其应用领域及复杂程度划分为组织、半独立性和嵌入3种类型，每种类型的公式有所调整 对公式计算出的结果，再综合4类15种因素，分别根据软件项目的具体特性

14、确定不同因素的调整系数。 参考教材26页,一个估算模型的例子：CoCoMo,CoCoMo = Constructive Cost Model（构造性成本模型） 公式：E = a ( kLOC )b D = c Ed N = E/D 其中，E-工作量 D-开发时间 N-参加项目的人数 kLOC-代码行估计值 a, b, c, d-常数,用基本CoCoMo模型估算,工作量 E = a ( kLOC )b =3.0*(33.3) 1.12 =152 PM （PM：每人/月） 开发时间 D = c Ed =2.5*152 0.35 =14.5 参加项目人数 N=E/D=152/14.511,软件效益分

15、析,软件产品的效益分为 经济效益 社会效益 软件产品的经济效益从两个方面评价 开发者获得的收益 软件应用方获得的收益 效益分析方法 现值分析法，参考教材29页,自动估算工具的功能,项目交付产品的规模估算 选择项目活动 预测人员层次 预测软件工作量 预测软件成本 预测软件进度,本章主要内容,14.1软件项目管理的概念 14.2软件度量 14.3成本管理 14.4时间管理 14.5风险分析和管理 14.6软件配置管理,14.4软件项目时间管理,开发小组人数与软件生产率的关系 按开发进程合理调配人力资源 制定软件进度时间表,项目的最后交付日期已经确定，负责开发工作的软件机构将在一个规定的时间范围内非

16、配其工作量。 项目的最后交付日期由软件开发机构自己决定。,软件开发项目的进度安排可以有以下两种不同的情况：,实际工作中经常遇到的是第一种情况。对于一个实际的项目来说，开发进度的要求有时比成本的要求更为重要，或者说开发进度安排失误比成本的估算错误更为致命,开发小组人数与软件生产率的关系,当一定数目的开发人员被组织成共同完成软件项目的成员时，他们之间就要通过信息交流来解决各自承担任务之间的接口问题，也就是所谓的通讯问题。 通讯要花费时间和精力，同时还会增加软件出错的概率，降低软件生产率。 结论：参加软件项目的工作人员数量与整体生产率之间的关系不是线性的。,通过在略为延长的时间内使用较少的人员，可以

17、实现相同的目标。,一个软件工程原则：,10个人 1年,20个人 6个月,5个人 2年,20个人 9个月,5个人 1.5年,按开发进程合理调配人力资源,一个软件项目完成的快慢，不完全取决于参与人员的多少，而主要在于人员调配的合理性。 一种比较好的分配方案时采用402040原则，在项目进行的不同阶段调配不同数量的工作人员。 软件项目各个阶段工作量分配的百分比大致如右图： 402040原则是一个定性的指导性原则，要根据项目的不同情况灵活处理。,制定软件进度时间表,开发进度安排工作的结果是形成一张软件进度时间表。 在进度时间表上必须规定每项任务完成的起止时间、任务完成的标志、各项任务中参与人员数、工作

18、量和各个任务之间的衔接情况。另外，还必须明确完成该任务所必须的资源。 注意：每个任务完成的标志，不是以下一阶段任务能否开始为标准，而应该以该任务必须交付的文档资料和复审是否已通过为标准。,软件进度时间表的实例参考（甘特图）,教材第32页。 国外一个项目计划文档中的进度安排表。,本章主要内容,14.1软件项目管理的概念 14.2软件度量 14.3成本管理 14.4时间管理 14.5风险分析和管理 14.6软件配置管理,14.4 风险分析和管理,风险的类型： 项目风险：项目在预算、进度、人力、资源、顾客和需求等方面的原因对软件项目产生的不良影响； 技术风险：项目在设计、实现、接口、验证和维护过程中

19、可能发生的潜在问题对项目带来的危害； 商业风险：开发了一个没人需要的优质软件，开发的产品不符合公司的产品销售战略等。,风险的分析管理过程,风险识别：系统化地确定对项目计划（估算、进度、资源分配）的威胁。 风险预测：又称风险估算，试图从风险发生的可能性或概率以及如果风险发生所产生的后果这两个方面评估每一个范型。 风险求精：将风险进一步细化。 风险缓解、监控和管理：辅助项目组建立处理风险的策略。,风险识别风险表现,产品规模与要建造或要修改的软件的总体规模相关的风险 商业影响与管理或市场所加诸的约束相关的风险 客户特征与客户的素质以及开发者和客户及时通信能力相关的风险 过程定义与软件过程被定义的程度

20、以及它们被开发组织所遵守的程度相关的风险 开发环境与用以建造产品的工具的可用性及质量相关的风险 将采用的技术与待开发软件的负责性及系统所包含技术的“新奇性”相关的风险 参与项目的各类人员与参与工作的软件工程师的总体技术水平及项目经验相关的风险,风险识别风险因素,性能风险产品能够满足需求且符合于其使用目的的不确定的程度 成本风险项目预算能够被维持的不确定的程度 支持风险软件易于纠错、适应修改、及增强的不确定的程度 进度风险项目进度能够被维持且产品能按时交付的不确定的程度,风险识别风险驱动因子,每一个风险驱动因子对风险元素的影响均可分为以下四个类别，影响评估图指出了由于错误而产生的潜在影响（标为1

21、的行）或没有达到预期的结果所产生的影响（标为2的行）。 可忽略的 轻微的 严重的 灾难的,风险影响评估图,风险预测建立风险表,风险表说明,风险表为项目管理者提供了一种简单的风险预测技术。 项目组一开始根据风险表现在表中的第一列列出所有风险。每一个风险在第二列上加以分类（例如，PS表示产品规模风险，BU表示商业风险）。每个风险发生的概率则输入到第三列中。 下一步是评估每个风险所产生的影响。使用影响评估图所述的特性评估每个风险元素，并确定其影响的类别。四个风险元素性能、支持、成本及进度的影响类别被求平均以得到一个整体的影响值。 根据概率及影响来进行排序，高发生概率、高影响的风险放在表的上方，而低概

22、率风险则移到表的下发。 项目管理者根据已排序的表，定义一条中止线。该中止线表示：只有在线之上的风险才给予关注，线之下的风险则需要进一步评估才能决定。,风险求精的方式,在项目计划的早期阶段，风险可能是相当一般性地陈述的。随着时间推移，关于项目和风险的了解加深，有可能将风险精化为一组更详细的风险，而每个风险在某种程度上更易于被缓解、监控和管理。这样做的一种方式是： 条件变迁结果（conditiontransitionconsequence） 即风险按如下方式描述： 给定，则存在担忧（可能）,本章主要内容,14.1软件项目管理的概念 14.2软件度量 14.3成本管理 14.4时间管理 14.5风险

23、分析和管理 14.6软件配置管理,软件配置管理的概念,软件配置管理（Software Configuration Management），简称SCM，是一组用于在计算机软件的整个生存期内管理变更的活动。 SCM活动的目标是为了 (1) 标识变更； (2) 控制变更； (3) 确保变更正确地实现； (4) 向其他有关的人报告变更。,软件配置管理的概念-1,软件配置项（software configuration item ） 软件开发的过程中，会得到许多工作产品或阶段产品，还会用到许多工具软件，这可能是外购软件，也可能是用户提供的软件。所有这些独立的信息项都要得到妥善的管理，绝不能出现混乱，以便

24、在提出某些特定的要求时，能将其进行约定的组合来满足使用的目的。 这些信息项是配置管理的对象，称为软件配置项。例如，需求规格说明、设计规格说明、用户手册、维护使用手册都属于此。 如果说软件配置项是一个独立存在的信息项，我们可以把它看成一个元素。单独的一个元素发挥不了什么作用，但随着工作的进展，出于不同的要求，需要将这些元素进行不同的组合。软件配置是一个软件产品在生存期各个阶段的不同形式（记录特定信息的不同媒体）和不同版本的程序、文档及相关数据的集合，或者说是配置项的集合。,软件配置项（SCI）的内容,系统规格说明 软件项目实施计划 软件需求说明 可执行的原型 初步的用户手册 设计规格说明 源代码

25、清单 测试计划和过程、测试用例和测试结果记录 操作和安装手册 可执行程序（可执行程序模块、连接模块） 数据库描述（模式和文件结构、初始内容） 正式的用户手册 维护文档（软件问题报告、维护请求、工程变更次序） 软件工程标准 项目开发总结 除以上所列SCI以外，许多软件工程组织还把配置控制之下的软件工具列入其中，即编辑程序、编译程序、其它CASE工具的特定版本。因为要使用这些工具来生成文档、程序和数据，如果编译程序的版本不同，可能产生的结果也不同。,软件配置管理的概念-2,基线 (Baseline) 基线是软件生存期中各开发阶段末尾的特定点，又称里程碑。 其标记是通过一个或多个软件配置项的交付，且

26、这些软件配置项已经经过正式技术评审而获得认可。 基线的作用是把各阶段工作的划分更加明确化，以便于检验和肯定阶段成果。,软件开发各阶段的基线,软件配置管理的概念-3,项目数据库 项目数据库也称为项目或软件中心存储库。 一旦一个软件配置项（SCI）成为基线，就把它存放到项目数据库中。 当软件组织成员想要对基线SCI进行修改时，把它从项目数据库中复制到该工程师的专用工作区中。 例如，把一个名为B的SCI从项目数据库复制到工程师的专用工作区中。工程师在B（B的副本）上完成要求的变更，再用B来更新B。 有些系统中把这个基线SCI锁定。 在变更完成、评审和批准之前，不许对它做任何操作。,基线SCI和项目数

27、据库,软件配置管理（SCM）的任务是： 标识软件配置项SCI 标识和管理软件各种版本 控制变更 报告所有加在配置上的变更 审查软件配置,软件配置管理的任务,标识软件配置项,一方面随着软件生存期的向前推进，SCI的数量不断增多。 整个软件生存期的软件配置就象一部不断演变的电影，而某一时刻的配置就是这部电影的一个片段。 为了方便对软件配置的各个片段（SCI）进行控制和管理，不致造成混乱，首先应给它们命名。 为了控制和管理SCI，每个SCI必须被独立命名，然后用面向对象的方法组织，有两种类型的对象可以被标识，分别是基本对象和复合对象。,版本控制,版本控制是SCM的基础，它管理并保护开发者的软件资源。

28、 版本控制管理在软件工程过程中建立起配置对象的不同版本。 版本管理可以把一些属性结合到各个软件版本上。 通过描述所希望的属性集合来确定（或构造）所想要的配置。 使用演变图来表示系统的不同版本。,变更控制（修改控制）,软件生存期内全部的软件配置是软件产品的真正代表，必须使其保持精确。 软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息。 变更控制包括建立控制点和建立报告与审查制度。,变更控制过程,配置状态报告,为了清楚、及时地记载软件配置的变化，需要对开发的过程做出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。 登录主要根据变更控制小组会议的记录，并产生配置状态报告。 对于每一项变更，记录：发生了什么？为什么会发生？谁做的？什么时侯发生的？会有什么影响？,配置状态报告信息流,配置审计,软件的完整性，是指开发后期的软件产品能够正确地反映用户要求。 软件配置审计的目的就是要 证实整个软件生存期中各项产品在技术上和管理上的完整性。 确保所有文档的内容变动不超出当初确定的软件要求范围。使得软件配置具有良