CMMSPM 系统培训.pptVIP

前言 培训目的 协助PL在软件项目中的管理 软件工程相关规范的概念导入 培训目标： 理解软件工程背景，了解CMM相关模型 培训方式 培训 + 讨论 培训提纲 CMM系统培训之一：CMM基本概念 CMM系统培训之二：软件项目管理 CMM系统培训之一：CMM基本概念 软件工程背景 CMM基本概念 矛盾引发软件危机 软件危机 在计算机软件的开发和维护过程中所遇到的一系列严重问题。 具体体现 软件开发进度难以预测 软件开发成本难以控制 用户对软件功能难以满意 软件产品质量无法保证 软件产品难以维护 软件通常缺少适当的文档资料 软件工程 提出 “软件工程”一词是1968年北大西洋公约组织的计算机科学家在当时联邦德国召开的专门讨论解决“软件危机”的国际会议上正式提出并使用的，并由此诞生了一门新兴学科——软件工程学 定义 Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料 Fritz Bauer：是为了经济地获得可靠的、能在实际环境中高效运行的软件而建立和使用的好的工程原则 IEEE：①将系统的、规范的、可度量的方法应用于软件的开发、运行、维护的过程，即将工程化应用于软件中； ② ①中所描述的方法的研究。 软件工程项目的基本目标 付出较低的开发成本 达到要求的软件功能 取得较好的软件性能 开发的软件易于移植 需要较低的维护费用 能按时完成开发工作，及时交付使用 CMM背景 1986年11月，SEI开始开发软件过程成熟框架 1987年9月，成熟度问卷 1991年8月，CMM V1.0 1993年，CMM V1.1 [CMU/SEI-93-TR-024] P-CMM，SE-CMM，SA-CMM CMMI，TSP， PSP CMMI 目的：解决多种CMM模型并行应用的矛盾和问题 SW-CMM 2.0 Draft C EIA/IS 731 IPD-CMM 0.98 历史 2000/8，CMMI 1.0 2000/11，CMMI-SE/SW V1.02 [CMU/SEI-2000-TR-018/019] 2001/12，CMMI-SE/SW V1.1 [CMU/SEI-2002-TR-001/002] 2000/11，PSP，TSP CMM有关名词 CMM核心思想：过程管理 不成熟与成熟的软件过程 混乱 高度依赖于项目参与者 项目结果不可预测 容易出现超预算、拖期、质量问题 使用新技术有很大风险 反应式、消防 定义明确、文档化 严格控制 严格度量 以过程改良为核心 以先导试验或费效分析为依托 主动式、预防 CMM结构 关键过程域（KPA） SEI CMM模型 1-5级软件过程的特点(Ⅰ) 可视性增强 可控性增强 自我改进能力 1-5级软件过程特点(Ⅱ) 敢于承诺的项目目标提前 承诺的项目目标和实际的完成情况间的偏差减小 实际的完成情况的可控性增强 总结 CMM只是提供了一份导向图，目的在于指导组织前进并标识其缺陷，并不在于对有麻烦的项目提供快速解决方案。 CMM过程的不断改进是基于许多小的渐进的步骤，而不是革命性的创新。 搞不搞CMM并不重要，重要的是软件开发的过程要不断地进行改良，CMM是实现这一目标所借助的工具 参考资源 CMM系统培训之二：软件项目管理 软件项目管理综述 软件项目管理专题 工作细分 估计 进度计划/阶段计划 沟通 项目控制 项目管理流程 1.3 组建项目团队 2.1 项目过程 过程模型：增量式 2.2 项目过程 过程活动及相关工作产品 PTO 项目策划 PTO 跟踪监控 项目管理专题 工作细分和估计 估计的漫谈 估计的前期基础工作：工作细分 估计基本方法，原则 DELPHI方法简介 一、估计漫谈 合理估计的重要性 1、估计目标：寻找估算和实际情况的交汇点 3、合理的估计是准确的进度，有效进度计划的基础 4、对项目的影响：不合理的估计比没有估计更为糟糕 可靠估计的障碍 管理者/客户的压力 总体已经确定然后直接分配给项目成员 缺乏历史数据 混乱的估计方法 太理想主义 忽视了必要的活动 过高的估计自己的能力 打折扣 可靠估计的障碍 9、即使需求分析已完成，对需要的工作量的了解也只在50%以下 合理估计的前提--详细理解每个功能。 软件开发是一个不断细化的过程，产品概念逐步细化为需求说明 随着项目的进展，估计会越来越准确 估计的原则 估计的原则：估计、估计、再估计； 产品规模估计是基础 避免不成熟的估计 第一次估计的印象太深刻了 需求和设计活动没有很好的界定 在项目早期阶段，项目成员的能力不很清楚 实施活动要很好的界定且尽早准确的理解 估计方法 从上至下估计→产品（软件）规模估计→工作量估计→外部成本估计→