1 / 75

第二章

第二章. 软件项目管理与计划. 第二章 软件项目管理与计划. 2.1 项目管理的基本概念 2.2 团队管理 2.3 项目计划 2.4 风险分析的管理 2.5 项目进度计划与控制 2.6 软件质量保证 2.7 软件配置管理. 2.1 项目管理的基本概念. Pressman ：的软件工程管理要点： People ： 项目组成人员的选择，分工，组织和协调原则。 Product ： 项目规模、涉及范围的最终目标的准确确定。 Process ： 过程模型的确定，及相应过程活动的战略和度量 Project ： 项目实施的技术原则、度量、计划和控制.

durin
Download Presentation

第二章

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 第二章 软件项目管理与计划

  2. 第二章 软件项目管理与计划 2.1 项目管理的基本概念 2.2团队管理 2.3项目计划 2.4风险分析的管理 2.5项目进度计划与控制 2.6软件质量保证 2.7 软件配置管理

  3. 2.1项目管理的基本概念 Pressman：的软件工程管理要点： People： 项目组成人员的选择，分工，组织和协调原则。 Product： 项目规模、涉及范围的最终目标的准确确定。 Process： 过程模型的确定，及相应过程活动的战略和度量 Project： 项目实施的技术原则、度量、计划和控制 Project（项目) 项目的基本要素 制定项目计划的要点 项目的决定因素 项目协调通讯途径 Process:(过程) 决定过程模型的目的、原则 项目适应模型的规律 过程活动准确选择 People(人员) 负责人的能力 组织结构选择 内部的管理方式 达到高性能的条件 导致项目组挫败的因素 防止项目组挫败的措施 Product:(产品） 确定项目的范围（约束） 范围界定的量化 使用功能模块确定成本和进度

  4. People(人员) 负责人的能力 组织结构选择 内部的管理方式 达到高性能的条件 导致项目组挫败的因素 防止项目组挫败的措施 1 项目负责人领导水平的ＭＯＩ模型 • 刺激，鼓励技术人员发挥最大能力 • 能读懂人、组织，融合以有的过程的能力 • 有想法或创新，即鼓励技术人员主动创造 • 解决问题，能够准确无误的诊断出技术问题和管理问题 • 在高压下坚持有信心、能力、主动性和做出成绩的人 2 组织结构选择： 单独管理：n个人分m个功能任务，全程由管理者协调 非正式组合： n个人分m个功能任务（m<n)，组间由管理者协调 正式组合: n个人分成t个小组，组有特定任务，组和管理者共同协调 组织方式:封闭式、随机式、开放式、同步式

  5. People(人员) 负责人的能力 组织结构选择 达到高性能的条件 导致项目组挫败的因素内部的管理方式 防止项目组挫败的措施 • 达到高性能的条件： • 成员间相互信任 • 技术分布适合问题 • 无独立性成员 导致项目组挫败的因素 混乱无序的工作环境和人与人间的摩擦 不适当的过程选择和不确定的角色按排 连续的失败引起信心的丢失 • 防止项目组挫败的措施: • 不要盲目修改目标和范围 • 给小组多点决策权 • 选用好过程，防止超负荷任务 • 明确成员的角色 • 内部管理方式： • 民主分散：临时性问题，个人间交流讨论 • 控制分散：子任务与个人问题，集体讨论 • 控制集中：子任务问题小组讨论，项目组 • 解决高层问题

  6. 对于一些规模较小的项目（1个人年或者更少），只要向专家做些咨询，也许一个人就可以完成所有的软件工程步骤。对一些规模较大的项目，在整个软件生存期中，各种人员的参与情况是不一样的。下面是各类不同的人员随开发工作的进展在软件工程各个阶段的参与情况的典型曲线。对于一些规模较小的项目（1个人年或者更少），只要向专家做些咨询，也许一个人就可以完成所有的软件工程步骤。对一些规模较大的项目，在整个软件生存期中，各种人员的参与情况是不一样的。下面是各类不同的人员随开发工作的进展在软件工程各个阶段的参与情况的典型曲线。

  7. 确定项目的范围（约束) 产品在商业语境下，怎样约束 以什么数据对象输入，输出什么格式的数据对象 执行什么功能、什么性能、如何满足输入输出 Product:(产品） 确定项目的范围（约束） 范围界定的量化 使用功能模块确定成本和进度 范围界定的量化: 管理层： 技术层： 如：成本限制 如：用户数量限定 工期限定 列表的大小 销售定位 允许响应时间 使用面向 算法理解与采用语言 内存大小 使用功能模块确定成本和进度： 采用分块实现的策略 分解要交付的功能，以及实现该功能的过程，确定进度和成本 分析 分析

  8. Process:(过程) 决定过程模型的目的、原则 项目适应模型的规律 过程活动准确选择 • 决定过程模型的目的、原则: • 工作任务适量划分 • 质量措施 • 使用该项目产品的用户情况 • 产品的特征是什么 • 开发环境如何 • 过程活动准确选择: • 产品功能的实现与确定过程活动相对应 • 过程活动根据项目设定

  9. Process:(过程)举例 对产品各项功能在定义的活动中的任务记录

  10. 例2: 按项目设定活动

  11. 项目的基本要素: 有明确的开始 有保持动力的因素 进度必须可跟踪 保持明确的决策 有过程分析活动 Project（项目) 项目的基本要素 制定项目计划的要点 项目的决定因素 项目协调通讯途径

  12. 项目协调通讯途径

  13. 协调和通信问题 6 个人间讨论 文档 设计复审 项目里程碑 协调技术的价值 5 需求复审 错误追踪报告 配置 电子邮件 小组会议 代码检查 4 正式的。非个人的方法 项目公告栏 正式的。个人间的规程 非正式的，个人间的规程 源代码 3 电子通信 中心库数额 个人间的网络 项目控制工具 2 2 3 4 5 6 7 协调技术的使用

  14. 第二章 软件项目管理与计划 2.1 项目管理的基本概念 2.2团队管理 2.3项目计划 2.4风险分析的管理 2.5项目进度计划与控制 2.6软件质量保证 2.7 软件配置管理

  15. 2.2团队管理 • 团队组织原则: • 要适应不断变化需求 • 有利于团队成员间交流 • 有利于迅速做出决策 • 有利于与管理层的沟通 团队理要点： 团队组织原则 微软团队模型（MSF） • MSF团队模型的特点: • 每个成员是平等，有规定的角色和任务 • 每个成员都共享项目成果 • 团队文化：鼓励透明、讲效率、贵在参与，遵守承诺等 • 不断进取 • 关注用户开发 • 团队角色： • 产品规划员，关注市场 • 产品管理员：关注用户服务 • 程序员：有开发项目能力 • 测试员：掌握测试技术和测试策略 • 教育人员：参与培训，有良好技术 • 和写作能力 • 项目保障员：保证产品发佈、安装 • 移植、环境支持

  16. 2.3项目计划 1 软件度量与测量 2 软件估算 3 软件质量度量 4 软件复杂性度量 5 可靠性度量 质量度良 面向规模的度量 面向功能的度量 面向人的度量 技术度量 生产率度量 软件度量分类 什么是软件度量： 软件工程范围内的度量是软件产品、软件开发过程或资源简单属性的定量描述。如程序的规模、操作符个数、程序错误个数等。

  17. 测量和度量的区别 作为名词： measurement 如某软件的代码行数、操作符个数定量指示 测量（measure) 作为动词： measure 一次测量的行为，如软件复杂性、模块性等 度量（metrics)

  18. 测量和度量的区别举例： 汽车的属性包括： 车体的重量、载重量、每公里耗油量、可达的最大时速（公里/小时）等等 对汽车的三个测量，是对某辆汽车的上述三个属性的一次测量行为。 测度，是对多个汽车的属性测量的结果之后，给出的属性的度。 汽车的三个测度： 1）测试多个汽车的耗油量的结果之后，给出汽车耗油量的度，指标：在每100公里应该在3公斤以下 2）测试多个汽车的重量和载重量之后，给出汽车重量与载重量的比，指标：在1/6以下。(对应某一车型)。 3）测试多个汽车的最大时速之后，给出汽车的最大时速（公里/小时），指标：在每小时40公里以上，100公里以下（对应某一车型）。

  19. (1) 软件过程度量 软件过程度量包括： 软件发佈前的发现的错误数量 交付最终用户后，用户报的缺陷数量 花费的工作量（工作日和人力) 进度计划的一致性 某时间发生的事件数 过程度量连接三个重要因素 产品 除软件过程外，决定软件质量的主要影响有 人员技能 产品复杂性 采用的软件工程的方法 项目的环境：用户条件、开发条件、商业条件 商业条件 用户特性 过程 人员 技术 开发环境

  20. 软件、系统或产品开发分析缺陷的方法 按来源分类 记录修改每个错误和缺陷的成本 统计每一类错误和缺陷的数目，并按降序排 计算每一类错误和缺陷的总成本 分析结果数据，了解造成最高成本错误的原因 制定修定过程的计划

  21. 错误和缺陷分部情况图 错误来源于： 来源于处理逻辑 来源于数据处理 来源于标准化处理 来源于规约（规定和要求） 来源于用户界面 来源于错误检测 来源于硬件检测 来源于软件接口 逻辑20% 数据处理10.5% 软件接口6.0% 标准6.9% 硬件检测10.9% 错误检测10.9% 规约25.5% 用户界面 11.7% 错误来源:规约、需求、设计、编码

  22. (2) 软件项目度量 软件项目度量： 改善项目的工作流程和技术活动，、减少风险、提高质量 项目度量方法： 1）从过去项目的进展，所花费的工作量来估算现在的软件项目工作量及时间。 2）用估算值与实际项目进度比较，以分析监控项目 软件项目生产率测量： •文档页数 •评审次数 •发现的错误数 •功能点 •交付源代码行数 软件项目度量模型之一 测量工作完成所需要的资源(人员、环境)--输入 测量软件过程中产生的中间和交互物-- 输出 测量交互物的有效性------------------------结果

  23. （3）、软件产品度量 直接测量： 代码行 程序功能 模块化 重用性 控制流、数据流结构 模块偶合度与内聚度 间接测量： 功能 质量 复杂性 有效性 可靠性 可维护性 等 较容易 较困难 形成 形成 项目度量 过程度量 个人 度量

  24. 度量的规范化 规范化的方法： 面向规模的度量 面向功能的度量 规范化的作用：为度量定义统一标准 (1) 面向规模的度量 L代码行数用KLOC（千行代码） 其 E 工作量用人月（PM）度量 S 项目总开销（人民币，美元） 中 Pd项目文档页数 Ne项目代码错误数 生产率：P1=L/E 每行代码的平均成本：C1=S/L 文档与代码比：D1=Pd/L 代码出错率：EQR1=Ne/L 例1：国外典型软件项目记录如表可计算： P1、C1 、D1 、EQR1的值

  25. (2) 面向功能的度量 特点：涉及多种因素的间接度量方式，可根据事务信息处理程序的基本功能定义。 （1）面向功能的度量是用5个信息域取值 • 用户输入数:计算每个用户输入数据数 • 用户输出数:计算每个用户输出数据 (报表、屏幕、出错信息） • 用户查询数：一个查询被定义为一次联机输入，每一个不同查询都计算。 • 文件数：计算每个逻辑的主文件数 • 外部接口数：计算可读的接口（如磁盘、磁带上的数据文件)。 复杂度加权因子值

  26. 每个功能点计算关系式：FP=总计数值[0.65+001Fi]其中：总计数值为所有条目的总和 Fi =14个复杂化度调整值的累加和Fi 取值0到5 0 1 2 3 4 5 没有 偶有 轻微 平均 较大 严重 影响 影响 影响 影响 影响 影响 加权因子 计数 简单 平均 复杂 测量参数 用户输入数  3 4 6 = 用户输出数化  4 5 7 = 用户查询数  3 4 6 = 文件数  7 10 15 = 外部界面数  5 7 10 = 对象点总计数值 计算对象点的度量

  27. 确定Fi下标调整值的因素有14项 1）系统需要可靠的备份和复原吗？ 2）是否需要数据通信 3）是否有分布处理功能 4）性能是否很关键 5）系统环境是否合乎要求 6）系统是否需要联机数据项 7）联机数据项是否要在多屏幕或多操作之间切换以完成操作 8）是否需要联机更新主文件 9）输入、输出、文件或查询是否很复杂 10）内部处理是否复杂 11）代码是否要求设计为可复用 12）是否要求设计包括转换或安装 13）系统是否要求设计支持不同组织的多次安装 14）应用设计是否要求用可修改和使用

  28. 调和不同的度量方法 代码行(Lines of code,LOC)和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设计的质量. 对于相同功能点各种语言的平均代码行数的估算。 语言 LOC/FP（平均值） 汇编 320 C 128 Ada 70 面向对象 30 4GLs20 代码生成器 15 电子表格 6 图形语言 4

  29. lOC和FP度量常用于导出生产率的度量，但评价影响生产率的因素有：lOC和FP度量常用于导出生产率的度量，但评价影响生产率的因素有： • 人的因素：开发组织的规模和专业技能 • 问题因素:别待解决问题的复杂性及设计约束或需求的改变次数 • 过程因素:使用分析、设计的技术，是否使用CASE工具，复用技术 • 产品因素：使用计算机硬件系统的可靠性及性能 • 资源因素：CASE工具、硬件、软件的可用性 对任一项目，任一生产因素高于平均值，则效高

  30. 1 软件度量与测量 2 软件估算 3 软件质量度量 4 软件复杂性度量 5 可靠性度量 2 软件估算 • (1）软件估算的第一点为系统的总体估算 • (2）按项目计划目标是提供一个框架，使管理人员进行合理的估算，定义系统的范围 • (3）软件估算第二点为系统使用资源的估算,开发项目资源可看为一个金字塔. 每一类资源的特征说明方法: 1. 资源描述 2. 可用性说明 3. 需要资源的时间 4. 及资源被使用的持续时间 人力资源可复用性资源环境资源的金字塔

  31. 项目估算常用技术： 规模估算 过程估算 问题估算 为得到可靠估量成本和工作量估算的几种选择： 1）项目结束后进行  2）基于已完成的相似类型项目进行  3）使用“分解技术”进行  4）使用一个或多个经验模型进行  常用后两种： 可用 d=f(v) 进行 其中：v选择出的独立参数，如被估算的LOC或FP 分解估算技术 工作量估量模型 构造性成本模型 动态多变量模型 经验估量模型

  32. 分解估算技术---规模估算 规模：指软件项目的大小、复杂程度、可量化的数据。如代码行LOC或功能点FP

  33. LOC和FP估量技术在分解的详细程度存在差别 书上例2.2（CAD）软件项目估量用LOC和FP 作规模估算 P36-P37

  34. 采用分解软件开发成本估算: • 软件开发成本:指软件开发过程中所花费的工作量及相应的代价。不包括原材料和能源的消耗，主要是人的劳动消耗。 • 人的劳动消耗所需代价就是软件产品的开发成本。 • 软件产品开发成本的计算方法不同于其它物理产品成本的计算 • 软件开发成本估算方法: • 对一个大型项目，由于项目的复杂性，开发成本的估算不简单，要进行一系列的估算处理。主要靠分解和类推。 • 基本估算方法分为三类。 • 自顶向下的估算方法 • 自底向上的估计法 • 差别估计法 • 开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发全过程所花费的代价作为依据的。

  35. 自顶向下的估算方法 • 这种方法的主要思想是从项目的整体出发，进行类推。 • 估算人员根据以前完成项目所消耗的总成本，推算将要开发的软件的总成本，然后按比例将它分配到各开发任务单元中去，再来检验它是否能满足要求

  36. 自底向上的估计法: 自顶向下的估算方法: • 这种方法的优点是估算工作量小，速度快。 • 缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分 • 这种方法的主要思想是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。 • 它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量.

  37. 分解估算技术---过程估算 过程估算模型的基本思想： 将过程分解为相对较小的任务集合。估算完成每个任务所需要的人员，时间和工作量

  38. 经验估量模型----COCOMO模型 (Constructive Cost Model) (1) COCOMO模型对软件项目进行三种划分 组织模式：小型、简单的软件，不是很严格的需求开展工作 半分离模式：中等的软件项目，不同项目组按严格或不严的需求开展工作。例一个事务处理系统 嵌入式系统：在一组严格的硬件、软件及操作约束下开发项目。如：飞机的航空控制系统、手机信息接收、发送系统。 有三个层次，分别用于开发3个阶段性的COCOMO模型： 基本模型1：用于系统初期估算软件开发工作量（及成本）和软件开发所需时间 中间模型2：用于估算软件各个子系统开发工作量（及成本）和开发所需时间 详细模型3：包含模型2的所有特性，对软件开发过程中每一步骤的影响评估。

  39. (2) COCOMO基本模型 E=abKLOCbb D=cbEdb 其中：E为以人月为单位的工作量 D为以月表示的开发时间 KLOC是估算的项目代码行（以千行为单位） 软件项目 ab bb cb db 适用范围 组织模式 2.4 1.05 2.5 0.38 各类应用 半分离模式 3.0 1.12 2.5 0.35 实用、编译等 嵌入模式 3.6 1.20 2.5 0.32 实时、控制、操作系统 按三类软件的适用范围选取相应的参数ab、bb、cb、db

  40. (3) COCOMO中等模型 E=aiKLOCbiEAF D=cbEdb 其中：E为人月为单位的工作量 KLOC是估算的项目代码行（以千行为单位） 系数ai、bi如下表(中级） 软件项目 ai bi 组织模式 3.2 1.05 半分离模式 3.0 1.12 嵌入模式 2.8 1.20 按三类软件的适用范围选取相应的参数: ai、bi、

  41. (4) COCOMO结构模型算举例1 按基本模型估算：设一个CAD应用软件包，要求运行在工作站上，配置数字化仪、高分辨率显示器、激光打印机。 软件功能： • 用户界面和控制机制、 • 二维或三维几何分析、 • 数据库管理、 • 图形显示、 • 外设控制、 • 设计分析模块 按LOC的三点估算技术： 对应功能估算为： 2300 5300 6800 3350 4650 2100 8400 总代码行为： 33200 三维几何分析的LOC估算值：乐观值 4600、可能值 6900 最坏值 8600 期望值 6800LOC

  42. 项目初期设定工作量和人员 确定项目人员数： N=E/D =95/12.3 =约8人 项目的持续时间为： D=2.5E 0.35 =2.5(95)0.35 = 12.3个月 软件估算值为：E=2.4(KLOC)1.05 =2.4(33.2)1.05 =95个人月 计算组间、人间的通信开销为： Ec=N(N-1)/2 设N取8 Ec(8)= 8(8-1)/2=28 为每次通信和交换意见的平均工作量 例2见教材P38

  43. 按基本模型估算：设一个集计量站管理软件包，要求运行在局域网上，配置14个站点、高分辨率显示器、激光打印机。按基本模型估算：设一个集计量站管理软件包，要求运行在局域网上，配置14个站点、高分辨率显示器、激光打印机。 软件功能： • 站财务管理、 • 科研管理、 • 数据库和网络管理、 • 设备管理、 • 人事、 • 邮件和量传 • 设计分析模块 按LOC的三点估算技术： 对应功能估算为： 2500 6300 4350 3300 6650 5800 3500 3200 7400 总代码行为： 43000

  44. 5、动态多变量模型-----Putnam软件方程式 软件方程式假设在软件生命周期中的一个工作量分布。通过对4000多个软件项目生产率的统计获得： E=[LOCB 0.333 /P]3（1/t4） 其中： E=人月或人月为单位的工作量 t=以月或年表示的项目持续时间 B=记数因子， P=生产率参数 教材P39-41为另一种-Putnam软件方程式 特殊技能因子： 随集成、测试、质量保证、文档、管理技能的需求增长“ KLOC=5到15、B=0.16、超过70的KLOC程序B=0.39 一组典型的生产率参数值： 实时嵌入式软件开发 P=2000 电讯及系统软件 P=10000 商业系统应用软件 P=28000 科学计算软件开发 P=12000 当前P值，从过去开发中收集

  45. ？ 估算模型的结构举例 • LOC估算模型 E=5.2(KLOC)0.91 Walston-Felix模型 E=5.5+0.73 (KLOC)1.16 Bailey-Basili模型 E=3.2 (KLOC)1.05 Boehm的简单模型 E=5.288 (KLOC)1.047 Doty模型, 当KLOC>9 • FP估算模型 E=-13.39+0.0545FP Albrecht和Gaffney模型 E=60.62 7.72810-8FP3 Kemerer模型 E=585.7+5.12FP Maston、Barnett和Mellichamp模型

  46. 3 软件质量度量软件质量要素软件质量要素评价标准 1 软件度量与测量 2 软件估算 3 软件质量度量 4 软件复杂性度量 5 可靠性度量 影响软件质量的因素 人的因素 软件需求 测试的局限性 质量管理的困难 软件人员的传统习惯 开发规范 开发工具支持不够 及时 交付 功能 成本 正确 功能 可靠 及时 交付 成本 维护 软件质量的若干侧面

  47. 3 软件质量度量软件质量要素软件质量要素评价标准 软件质量要素基本指标：正确性 可维护性 可用性 完整性 移植性 重用性 互操作性 可维护性 灵活性 测试性 修正性 转移性 运行性 可用性、正确性、有效性 可靠性、完整性 McCall提出的表明软件质量11个要素

  48. 正确性:满足规范化说明书和用户指标，度量标准是在标准时间发布前后的缺陷数正确性:满足规范化说明书和用户指标，度量标准是在标准时间发布前后的缺陷数 可维护性:错误容易修改、环境变化容易适应、可用间接测量技术：可维护与不可维护软件相比，MTTC（mean-time-to-change)平均修改时间要低 软件质量要素基本指标：正确性 可维护性 可用性 完整性 可用性:使用软件的难易程度、量化有效性。为之准备的输入数据以及解释软件的输出结果。 完整性：控制未授权人使用的程度。 完整性=[1-威胁性（1-安全性)] 威胁性:规定时间内某类攻击的可能性 安全性：对某类攻击击退的可能性 其它要素看教材P43

  49. 3 软件质量度量软件质量要素软件质量要素评价标准 计算看教材P45-47 McCall评价软件质量要素评价标准共21种： (1）可审查性（auditability) (2) 准确性（accuracy) (3)通信通用性(communication commonality)（4）完全性（completeness） (5）简明性（conciseness） （6）一致性（consistency） (7) 数据通用性（data commonality） （8）容错性（erro－tolerance） (9）执行效率（execution Efficiency）(10）可扩充性（expandabil…） (11)硬件独立性（hardware independence) (12）通用性（generality） (13）检测性（instrumentation） （14）模块化（modularity） (l5）可操作性（operability） （16）安全性（security） (17）自文档化（sel－documentation） （18）简单性 （simplicity） (19)系统独立性（software system independenc） (20）可追踪性（tracebility) （21）易培训性（training） 。

More Related