五软件项目管理二REV.PPT课件

1 风险管理 当在软件工程的环境中考虑风险时 主要基于Charette提出的这3个概念 一是关心未来 风险是否会导致软件项目失败 二是关心变化 在用户需求 开发技术 目标机器 以及所有其他与项目有关的实体中会发生什么变化 三是必须解决选择问题 应当采用什么方法和工具 应当配备多少人力 在质量上强调到什么程度才满足要求 风险分析实际上是4个不同的活动 风险识别 风险估计 风险评价和风险驾驭 2 风险识别 可用不同的方法对风险进行分类 从宏观上来看 可将风险分为项目风险 技术风险和商业风险 3 风险类型 1 项目风险识别潜在的预算 进度 个人 包括人员和组织 资源 用户和需求方面的问题 以及它们对软件项目的影响 如项目复杂性 规模和结构等都可构成风险因素 2 技术风险识别潜在的设计 实现 接口 检验和维护方面的问题 此外 规格说明的多义性 技术上的不确定性 技术陈旧 最新技术 不成熟 也是风险因素 技术风险之所以出现是由于问题的解决比所预想的要复杂 3 而主要的商业风险有以下5种 1 建立的软件虽然很优秀但不是真正所想要的 市场风险 2 建立的软件不适合整个软件产品战略 3 销售部门不清楚如何推销这种软件 4 由于课题改变或人员而失去上级管理部门的支持 5 失去预算或人员的承诺 预算风险 4 风险识别 风险识别就是要识别属于上述类型中某些特写项目的风险 方法是利用一组提问来帮助项目计划人员了解在项目和技术方面有哪些风险 Boehm建议使用一个 风险项目检查表 列出所有可能的与每一个风险因素有关的提问 例如 管理或计划人员可以通过回答下列问题得到有关人员风险的认识 可投入的人员是最优秀的吗 按技能对人员做了合理的组合了吗 投入的人员足够吗 整个项目开始进行期间人员如何投入 有多少人员不是全时投入这个项目的工作 人们对于手头上的工作是否有正确的目标 项目的成员接受过必要的培训吗 项目中的成员是否稳定和连续 对于这些提问 通过判定分析或假设分析 给出确定的回答 就可以帮助管理或计划人员估算风险的影响 5 风险估计 风险估计使用两种方法来估价每一种风险 一种方法是估计一个风险发生的可能性 另一种方法是估计那些与风险有关的问题可能产生的结果 6 风险估计 通常 项目计划人员与管理人员 技术人员一起 进行4种风险估计活动 1 建立一个尺度或标准来表示一个风险的可能性 2 描述风险的结果 3 估计风险对项目和产品的影响 4 确定风险估计的正确性 尺度可以用布尔值 定性的 或定量的方式定义 一种比较好的方法是使用定量的概率尺度 它具有下列的值 极罕见的 罕见的 普通的 可能的 极可能的 7 风险估计 根据已掌握的风险对项目的影响 可以给风险加权 且把它们安排到一个优先队列中 造成影响的因素有三种 风险的表现 风险的范围和风险的时间 风险的表现指出在风险出现时可能出现的问题 例如 一个定义得很差的用户硬件的外部接口 技术风险 会妨碍早期的设计和测试而且很可能在项目后期造成系统组装上的问题 风险的范围则组合了风险的严重性 即它严重到什么程度 与其总的分布 即对项目的影响有多大 对用户的损害又有多大 风险的时间则考虑风险的影响什么时候开始 要影响多长时间 在多数情况下 项目管理人员可能希望 坏消息 出现得越早越好 但在有些情况下则拖得比较长 8 风险评价 在风险分析过程中进行风险评价的时候 应当建立一个三元组 ri li xi 其中 ri是风险 li是风险出现的可能性 概率 而xi是风险的影响 在做风险评价时 应当进一步检验在风险估计时所得到的估计的准确性 尝试对已暴露的风险进行优先排队 并着手考虑控制和 或 消除可能出现风险的方法 9 风险评价 一个对风险评价很有用的技术就是定义风险参照水准 10 风险评价 在做风险评价时 按以下步骤执行 1 为项目定义风险参照水准 2 尝试找出在每个 ri li xi 和每个参照水准之间的关系 3 预测参照点组以定义一个终止区域 用一条曲线或一些易变动区域来界定 4 努力预测复合的风险组合将如何形成一个参照水准 11 风险驾驭和监控 风险驾驭是指利用某些技术 如原型化 软件自动化 软件心理学 可靠性工程学以乃某些项目管理方法等设法避开或转移风险 与每一风险相关的三元组 风险描述 风险可能性 风险影响 是建立风险驾驭 风险消除 步骤的基础 12 风险驾驭和监控 假如人员的频繁流动是一项风险ri 基于过去的历史和管理经验 频繁流动可能性的估算值li为0 70 70 相当高 而影响xi的估计值是 项目开发时间增加15 总成本增加12 给出了这些数据之后 建议可使用以下风险驾驭步骤 1 与现在在职的人员协商 确定人员流动的原因 如 工作条件差 收入低 人才市场竞争等 2 在项目开始前 把缓解这些原因 避开风险 的工作列入已拟定的驾驭计划中 3 当项目启动时 做好人员流动会出现的准备 采取一些办法以确保人员一旦离开时项目仍能继续 削弱风险 4 建立项目组 以使大家都了解有关开发活动的信息 5 制定文档标准 并建立一种机制以保证文档能够及时产生 6 对所有工作组织细致的评审 以使更多的人能够按计划进度完成自己的工作 7 对每一个关键性的技术人员 要培养后备人员 13 风险驾驭和监控 对于一个大型的软件项目 可能识别30 40项风险 如果每一项风险有3 7个风险驾驭步骤 那么风险驾驭也可能成为一个项目 正因为如此 可以把Pareto80 20规则应用到软件风险上来 经验表明 所有项目风险的80 即是使项目失败的潜在因素的80 能够通过20 的已识别风险来说明 14 风险驾驭与监控计划 RMMP记叙了风险分析的全部工作 并且作为整个项目计划的一部分为项目管理人员所使用 1 做里程碑事件跟踪和主要风险因素跟踪 判断一个预测的风险事实上是否发生了 2 进行风险再估计 确保针对某个风险而制定的风险消除步骤正在合理地使用 3 收集可用于将来的风险分析的信息 15 风险驾驭与监控计划概要 16 软件质量保证 软件质量 是贯穿软件生存期的一个极为重要的问题 是软件开发过程中所使用的各种开发技术和验证方法的最终体现 因此 在软件生存期中要特别重视质量的保证 以生成高质量的软件产品 17 软件质量的概念 ANSI IEEEStd729 1983定义软件质量为 与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体 M J Fisher定义软件质量为 所有描述计算机软件优秀程度的特性的组合 也就是说 为满足软件的各项精确定义的功能 性能需求 符合文档化的开发标准 需要相应地给出或设计一些质量特性及其组合 作为在软件开发与维护中的重要考虑因素 如果这些质量特性及其组合都能在产品中得到满足 则这个软件产品质量就是高的 18 软件质量的概念 软件质量反映了以下三方面的问题 1 软件需求是度量软件质量的基础 不符合需求的软件就不具备质量 2 在各种标准中定义了一些开发准则 用来指导软件人员用工程化的方法来开发软件 如果不遵守这些开发准则 软件质量就得不到保证 3 往往会有一些隐含的需求没有明确地提出来 例如 软件应具备良好的可维护性 如果软件只满足那些精确定义了的需求而没有满足这些隐含的需求 软件质量也不能保证 19 软件质量特性 软件质量特性 反映了软件的本质 讨论一个软件的质量 问题最终要归结到定义软件的质量特性 而定义一个软件的质量 就等价于为该软件定义一系列质量特性 人们通常用软件质量模型来描述影响软件质量的特性 已有多种有关软件质量的模型 它们共同的特点是把软件质量特性定义成分层模型 在这种分层的模型中 最基本的叫做基本质量特性 它可以由一些子质量特性定义和度量 二次特性在必要时又可由它的一些子质量特性定义和度量 20 互连性 Interoperability 可移植性 Portability 复用性 Reusability McCall软件质量模型 21 McCall质量度量模型框架 22 ISO的软件质量评价模型 按照ISO TC97 SC7 WG3 1985 1 30 N382 软件质量度量模型由三层组成高层 toplevel 软件质量需求评价准则 SQRC 中层 midlevel 软件质量设计评价准则 SQDC 低层 lowlevel 软件质量度量评价准则 SQMC 23 软件质量特性之间的竞争 在软件的质量特性与质量特性之间 质量特性与质量子特性之间存在着有利的影响和不利的影响 24 质量特性间的有利和不利影响 25 质量控制 质量控制 是为了保证每一件工作产品都满足对它的需求而应用于整个开发周期中的一系列审查 复审和测试 质量控制在创建工作产品的过程中包括一个反馈循环 度量和反馈相结合 使得我们能够在得到的工作产品不能满足其规约时调整开发过程 这种方法将质量控制视为整个制造过程的一部分 26 质量保证 质量保证 由管理层的审计和报告功能构成 质量保证的目标是为管理层提供为获知产品质量信息所需的数据 从而获得产品质量是否符合预定目标的认识和信心 当然如果质量保证所提供的数据发现了问题 则管理层负责解决这一问题 并为解决质量问题分配所需的资源 27 质量的成本 质量成本包括所有由质量工作或者进行与质量有关的活动所导致的成本 质量成本可以被划分为与预防 鉴定及失败相关的成本 28 质量的成本 预防成本 包括 质量计划 正式技术复审 测试设备 培训 鉴定成本 包括为深入了解 首次通过 各个过程时产品的状态而开展的那些活动 鉴定成本的例子如下 过程内和过程间审查 设备校准和维护 测试 29 质量的成本 失败成本 是指如果在将产品交付给客户之前已经消除了缺陷时就不会存在的成本 失败成本可以进一步划分为内部失败成本和外部失败成本 内部失败成本 是指在产品交付之前发现错误而引发的成本 内部失败成本包括 返工 修复 失败模式分析 外部失败成本 是指与产品交付给客户之后所发现的缺陷相关的成本 外部失败成本的例子如下 解决客户的抱怨 退换产品 求助电话支持 保修工作 30 软件质量保证 在今天 这一定义的含义是在一个组织中有多个机构负有保证软件质量的责任 包括软件工程师 项目管理者 客户 销售人员和SQA小组的成员 SQA小组充当客户在公司内部的代表 这就是说 SQA小组的成员必须以客户的观点看待软件 软件是否充分满足各项质量因素 软件开发是否依照预先设定的标准进行 作为SQA活动的一部分的技术规程是否恰当的发挥了作用 SQA小组的工作将回答上述的及其他的问题 以确保软件质量得到维护 31 SQA活动 软件质量保证由各种任务构成 这些任务分别与两种不同的参与者相关 做技术工作的软件工程师和负责质量保证的计划 监督 记录 分析及报告工作的SQA小组 32 SQA活动 为项目准备SQA计划 参与开发该项目的软件过程描述 软件工程小组为要进行的工作选择一个过程 复审各项软件工程活动 对其是否符合定义好的软件过程进行核实 SQA小组识别 记录和跟踪与过程的偏差 并对是否已经改正进行核实 审计指定的软件工作产品 对其是否符合定义好的软件过程中的相应部分进行核实 SQA小组对选出的产品进行复审 识别 记录和跟踪出现的偏差 对是否已经改正进行核实 定期将工作结果向项目管理者报告 确保软件工作及工作产品中的偏差已被记录在案 并根据预定规程进行处理 偏差可能出现在项目计划 过程描述 采用的标准或技术工作产品中 记录所有不符合的部分 并报告给高级管理者 不符合的部分将受到跟踪直至问题得到解决 除进行上述活动之外 SQA小组还需要协调变化的控制和管理 并帮助和分析软件度量信息 33 软件复审 软件复审是软件工程过程中的 过滤器 复审被用于软件开发过程中的多个不同的点上 起到发现错误 进而引发排错活动 的作用 复审是一种借助一组人的差异性来达到目的的方法 1 指出一个人或小组生产的产品所需进行的改进 2 确定产品中不需要或者不希望改进的部分 3 得到与没有进行复审相比更加一致 或者至少更可预测的技术工作的质量 从而使得技术工作更易于管理 34 正式技术复审 正式技术复审 FTR 是一种由软件工程师进行的软件质量保证活动 FTR的目标是 1 在软件的任何一种表示形式中发现功能 逻辑或实现的错误 2 证实经过复审的软件的确满足需求 3 保证软件的表示符合预定义的标准 4 得到以一种一致的方式开发的软件 5 使项目更易于管理 由于FTR的进行使大量人员对软件系统中原本并不熟悉的部分更为了解 因此 FTR还起到了提高项目连续性和培训后备人员的作用 35 正式技术复审 FTR实际上是一类复审方式 包括 走查 Walkthrough 审查 Inspection 轮查 Round robinReview 以及其他软件小组的技术评估 每次FTR都以会议形式进行 只有经过适当的计划 控制和参与 FTR才能获得成功 36 1 复审会议 不论选择何种FTR形式 每个复审会议都应该遵守下面的约束 复审会议 通常 应该在3到5个人之间进行 应该进行提前准备 但是每人占用工作时间应该少于2小时 复审会议时间应该不超过2小时 37 2 复审报告和记录保存 在FTR期间 一名复审者 记录员 主动记录所有被提出的问题 在复审会议结束时 对这些问题进行小结 并生成一份 复审问题列表 此外 还要完成一份简单的 复审总结报告 复审总结报告将回答以下问题 1 复审什么 2 由谁复审 3 发现了什么 结论是什么 38 3 复审指南 复审产品 而不是复审生产者 2 制定日程 并且遵守日程 3 限制争论和辩驳 4 对各个问题都发表见解 但是不要试图解决所有记录的问题 5 作书面笔记 39 3 复审指南 6 限制参与者人数 并坚持事先做准备 7 为每个可能要复审的工作产品建立一个检查表 8 为FTR分配资源和时间 9 对所有复审者进行有意义的培训 10 复审以前所作的复审 40 统计质量保证 统计质量保证反映了一种在产业界不断增长的趋势 质量的量化 对于软件而言 统计质量保证包括以下步骤 1 收集和分类软件缺陷信息 2 尝试对每个缺陷的形成原因 例如 不符合规约 设计错误 违背标准 与客户通信不力等 进行追溯 3 使用Pareto规则 80 的缺陷的20 成因有可能可以追溯到 将这20 少数重要的 分离出来 4 一旦标出少数重要的原因 就叮以开始纠正引起缺陷的问题 这一相对简单的概念代表的是为创建适合的软件工程过程的一个重要步骤 在该过程中将进行修改 以改进那些引入错误的过程要素 41 ANS IEEEStd 730 1984和983 1986软件质量保证计划 42 软件配置管理 在软件开发过程中 变动和修改是不可避免的 这些变动常常在项目开发人员之间引起混乱和误会 如果修改之前不作分析 修改后也不作记录 不通知有关的人员 修改时亦不注意质量和正确性 混乱的程度必将更加严重 软件配置管理 Software工作ConfigurationManagement 简称SCM 的目的是为了减少混乱 提高软件生产率 配置管理是对软件修改进行标识 组织和控制的技术 用来协调和控制整个系统过程 43 软件配置管理 软件开发过程的最终结果包括三类信息 1 计算机程序 包括源程序和目标程序 2 描述计算机程序的文档 包括面向技术人员和面向用户两类 3 数据结构 包括程序内部和外部定义两部分 组成上述信息的所有项目构成一个软件配置 其中每一项称为一个软件配置项 SoftwareConfigurationltem 简称SCl 它是配置管理的基本单位 一个SC中最早的SCI是系统规格说明书 随后是软件项目规划和软件需求规格说明书 随着软件开发过程的不断深入 SCI也迅速增加起来 44 基线技术 基线标志软件开发过程的各个里程碑 任一SCI 例如 设计说明书 一旦形成文档并复审通过 即成为一个基线 它标志开发过程中一个阶段的结束 对于已成为基线的SCI 虽然可以修改 但必须按照一个特殊的 正式的过程进行评估 确认每一处修改 相反 对于未成为基线的SCI 可以进行非正式修改 45 软件配置项 一般软件配置需包括下列SCI 1 系统规格说明书2 软件项目规划3 需求分析结果a 软件需求规格说明书b 可执行的或 纸样 原型4 初步用户手册5 设计规格说明书a 数据设计描述 46 软件配置项 b 总体结构设计描述c 模块设计描述d 界面设计描述e 对象描述 若采用面向对象技术 6 源代码清单7 测试规格说明书a 测试计划和过程b 测试用例和实验结果8 操作和安装手册 47 软件配置项 9 可执行程序a 每个模块的可执行代码b 链接到一起的代码10 数据库描述a 数据模型和文件结构b 初始化映象11 联机用户手册12 维护文挡a 软件问题报告单b 维护申请单c 预计变动的顺序13 软件工程的标准和过程 48 软件配置管理的任务 1 标识软件配置中各种对象 2 管理软件的各种