CMM需求管理实践经验记录谈
实习报告：软件开发项目中的需求管理与变更控制
实习报告：软件开发项目中的需求管理与变更控制一、引言需求管理和变更控制是软件开发项目中至关重要的环节。
合理的需求管理和变更控制可以确保项目的顺利进行，并最大程度地满足客户的需求，同时避免项目的范围扩张和风险的增加。
本文将从需求管理和变更控制的概念、方法和实施步骤等方面进行详细论述，并结合我的实习经历进行分析。
二、需求管理1. 需求管理的概念需求管理是指对软件开发项目中的需求进行规范、控制和追踪的过程。
它涵盖了需求的获取、分析、规划、确认、变更管理和跟踪等环节，旨在确保需求的准确性、完整性和一致性。
2. 需求管理的方法（1）需求获取：通过与客户沟通、需求调研和文档分析等方式，获取项目的需求。
在实习中，我参与了与客户的沟通，通过详细了解客户的需求，确保需求获取的准确性。
（2）需求分析：对需求进行分解、整理和分类，形成可执行的需求文档。
在实习中，我参与了需求分析的过程，通过与开发团队的讨论和确认，将需求转化为可行的开发任务。
（3）需求规划：对需求进行优先级排序、时间估计和资源分配，确定项目的需求计划。
在实习中，我参与了需求规划的过程，与项目经理一起制定了合理的需求计划，确保项目的进度可控。
（4）需求确认：与客户共同确认需求是否满足其期望，并形成正式的需求文档。
在实习中，我参与了需求确认的过程，与客户进行了多次会议，及时沟通并记录客户的反馈意见。
（5）需求变更管理：对需求变更进行评审、控制和处理，确保变更的合理性和可行性。
在实习中，我参与了需求变更管理的过程，及时评估变更对项目进度和资源的影响，并与相关方面进行协调。
三、变更控制1. 变更控制的概念变更控制是指对软件开发项目中需求的变更进行管理和控制的过程。
通过合理的变更控制，可以避免项目范围的扩大、风险的增加和资源的浪费，确保项目的稳定性和可行性。
2. 变更控制的实施步骤（1）需求变更的登记：在项目中设立变更控制机制，建立需求变更登记表，及时记录需求变更的内容、原因和提出者等信息。
CMM中的需求管理分析
【 关键词 】 能力成熟度模型 （ Ｍ ；需求管 理 ；变更控制 ；版本控制 ；需 Ｃ Ｍ）
求 跟踪
引 言
由此可 以看 出：需求 阶段在整个 软件生命
周 期 中是 非 常重 要 的 ，也是 非 常 基 础 的 。很 多
在软件 开发维护过程 中许多错误都是潜伏 的。一项对 Ｔ Ｍ公 司所做过 的软件项 目的分析 Ｒ 结果表明 ：所有被检测出来的错误 中 ，５ ％是 ４
在 编码 和单 元测 试 阶段 以后 才 被 发 现 的 ，更 糟
软件产品最终失败了 ，根本的原 因都是需求管 理没有做好 。做好需求的管理 ，不仅可以减少 软件开发中的错误 ，还可以减少修复错误的费
用 ，从而大大降低软件开发 成本和缩短软件开
发时 间 。
糕的是此类错误中的绝大部分（ ４％） 占 ５ 是在需求
维护阶段做同样 的工作所付 出的代价却是编码 阶段 的 ２ 倍。这就意味着在需求阶段和维护阶 ０ 段修复一个错误 的比值可高达 ｌ ０ 。 ：２０ 从事软件管理的人都 有一个 同感 ：软件管 理 是无 规 律 的 黑 团 ，而 产 生这 个 黑 团 的原 因就
是需 求 不明 朗 。
需求管理包括两个部分 ：需求和管理。按 照 Ｃ Ｍ 的定义 ，需求是指和客户一起建立并 Ｍ 不断更新的对各项 软件工作所达成 的协议。该 协议称为 ‘ 定（ 指 或分配） 给软件 的系统需求 ” ， 也叫给定需求（ 或分配需求） 。它是系统需 求的 部分 ，在系统 的软件部分实现 。给定需求作 为软件开发的初始输入 ，需要进行精确 的描述
络编程技术。
— ．
需求分析 的结 果 ，并确保软件项 目的开发活 动始终与它保持一致。
１ ． ２需求 的特 点 活动 、测量 和分 析 、验 证执 行 ，来 达 到 这 两个 目标 。 ２ 需 求管理 的任 务 ．
软件开发岗位实习报告：软件项目需求管理与变更控制
软件开发岗位实习报告：软件项目需求管理与变更控制一、引言在软件开发过程中，需求管理与变更控制是非常重要的步骤。
本文将对我在软件开发岗位的实习经历进行总结与报告，重点讨论软件项目需求管理与变更控制的实践与体会。
二、需求管理的重要性软件开发项目从需求阶段开始，需求管理是确保项目成功的关键。
需求管理涉及到识别、分析、规划、跟踪和控制需求的整个过程。
合理的需求管理可以确保项目团队对于客户需求的理解准确，避免项目在后期出现大规模变更，提高项目的质量和交付效率。
三、需求管理的实践过程1. 需求收集与分析在项目启动时，我与项目经理一起参与了需求收集与分析的工作。
我们与客户进行了多次沟通，使用了面谈、问卷调查等多种方法，明确了客户的需求和期望。
通过分析需求，我们确定了项目的范围和目标，并将其转化为详细的需求文档。
2. 需求规划与验证基于需求文档，我们进行了需求规划和验证的工作。
首先，我们根据需求的优先级和复杂度，制定了需求的排期和分解计划。
然后，我们与开发团队一起进行了需求验证，确保需求符合客户期望，并且能够在技术上实现。
3. 需求跟踪与变更控制在项目的开发过程中，我们使用了需求跟踪工具，对需求的状态和进度进行了实时跟踪。
一旦客户提出了新的需求或者变更请求，我们会进行评估，确定其对项目进度和资源的影响。
如果变更对项目有较大的影响，我们会与客户进行沟通，讨论可能的调整方案，并根据客户的决策进行变更控制。
四、需求管理的实践体会1. 沟通的重要性在需求管理过程中，与客户的沟通非常重要。
通过与客户充分沟通，我们能够更好地理解其需求和期望，避免后期出现大规模变更。
同时，我们也需要与开发团队进行有效的沟通，确保需求的准确传达和理解。
2. 需求变更的控制需求变更是不可避免的，在实践过程中，我们要学会进行变更控制。
对于小规模的变更，可以根据实际情况进行快速响应；对于大规模的变更，需要与客户进行深入沟通和评估，确保变更的合理性和可行性。
用CMMI指导需求管理
能力成熟度模型集成（CMMI，Capability Maturity Model Integration）已逐步成为IT业的标准。
CMMI定义了5个组织成熟度级别，包含25个过程域（PA,Process Area），这些过程域全面涵盖了软件生命周期的各个领域。
特别是在业界普遍感到难以控制的需求方面，它定义了两个过程域：需求管理和需求开发。
需求管理（REQM,Requirements Management）属于成熟度2级（受管理级）的过程域，是其他许多过程域实施的前提。
对于暂未实施CMMI的企业，同样也可以借鉴CMMI的原则，实施和优化需求管理。
本文从实际工作的角度，阐述如何用CMMI指导需求管理工作。
一、需求管理概述许多IT企业都有过需求失控的痛苦经历，我们不难体会，没有好的需求管理会给我们带来什么：需求以失控的状态进入软件过程，从源头上失去了项目的质量保证；需求范围界定不清，使项目缺乏计划性，导致成本、研制周期失控；需求变更失控，使组织处于被动反应式的环境中，项目组成为救火队；需求管理不当，导致项目延期、士气低落，增加了项目的失败风险；……为了避免上述情况的出现，CMMI对需求管理提出了明确的目的：一是管理项目的产品和产品构件的需求；二是标识哪些需求与项目计划及工作产品之间不一致。
通过适当的步骤，确保需求在项目的各个层面上动态地保持一致，一旦出现不一致，则启动相关的处理过程域，使其调整到一致。
需求管理包含5个特定实践（SP,Specific Practice），这5个特定实践的关系如图1所示。
获得对需求的理解。
需求接收者与需求提供者就需求达成共识。
获取项目参与者对需求的承诺。
通过书面承诺，建立各方、各项工作的基准。
管理需求变更。
维护变更历史，为调整与控制提供数据。
维护对需求的双向可追溯性。
这是从软件的可维护性角度提出的管理要求。
标识项目计划和工作产品与需求的不一致性。
旨在发现不一致性，并且启动纠正措施。
基于CMM中需求管理活动的应用研究
ｗ ｅｐｏ ｏ ｏ ｓ ｍ ｒ’ ｑｉ ｍ ｎ ａ ｉ ｔ ｂ ｄｒｓ ｄｂ ｅｓｆ ａｅｐｏ ｃ．ｔｓ ｈ ａｉ ｆ ｌ ｎ ｇ ｒ ａ ｒ ｃｔ ｆ ｕｔ ｅｓ ｒ ｕｒ ｅｔ ｔ ｔ ｓｏ ｅａｄｅｓ ｙｔ ｏ ｒ ｒ ｅｔＩ ｉｔｅｂｓ ｒ ａ ｉ ｊ ｃ ｏ ｅ ｅ ｓｈ ｅ ｈ ｗ ｔ ｊ ｓｏ ｐ ｎ ｎ
Ｔ ｅ ｐ ｒ ｏ ｅ ｏ ｅ ｕ ｒｍｅ ｔ ｍａ ａ ｅ ｎ ｓ ｔ ｓａ ｌ ｈ ａ ｃ ｍｍｏ ｎ ｅ ｓａ ｄ ｎ ｅ ｗ ｅ ｕ ｔｍｅｓ ａ ｄ ｔ ｏｔ ｈ ｕ ｐ ｓ ｆｒ ｑ ｉ ｅ ｎｓ ｎ ｇ ｍｅ ｔｉ ｏ ｅ ｔ ｉ ｏ ｂ ｓ ｎ ｕ ｄ ｒ ｔ ｉ ｇ ｂ ｔ ｅ ｎ ｃ ｓｏ ｒ ｎ ｎ ｈｅｓ ｆ－
Ａｂ ｔａ ｔ ｏ ｏ ｎ ｈ ｔ ｄ ｃｉｎｏ ＭＭ ｎ ｗ ｅ ｇ ，ｈ ｒｃ ｓ ｓｃ ｍｉｇｔ ｈ ｔｇ ｆａ ｐｙｎ ＭＭ ｏ ｓｒ ｃ ：Ｆ Ｕ ｗｉｇｔｅｉ ｒ ｕ ｔ ｆＣ ｎ ｏ ｏ ｋ ｏ ｌｄ ｅ ｔｅ ｐｏ ｅｓｉ ｏ ｎ ｏｔｅｓａ ｅｏ ｐ ｌｉｇ Ｃ ｔ
了软件组织实施 Ｃ Ｍ需求管理中应改进的措施 ． Ｍ
关键词 ：Ｃ ＭＭ； 软件过程 ； 能力成熟度模型 ； 可重复级 ； 求管 理 需 中图分类 号：Ｔ ３ １５ Ｐ １． 文献标识码 ： Ａ 文章编号 ：０ ８２ ９ （０ ６ ０ ・０ ３０ １０ －３５ ２ ０ ）２０ ６ — ５
关键过程域 （ Ｐ ， Ｋ Ａ） 是在客户和解决客户需求 的软件项 目之 间建立对 客户需求 的共 同理解 ， 是计划 和管理
软件的基础． 在通过探讨需 求管理在 实践应用 中所要涉及 的任务 和如何实施的方法 ， 分析了软件组 织的 软
件过程现状 ， 提出了他们在实施需求管理关键 过程域 中存 在 的问题． 同时根据 Ｓ Ｉ Ｅ 制订 的 ＭＱ问卷 ， 探讨
CMM中的关键实践
CMM中的关键实践1、初始级无2、重复级2.1需求管理1.在分配的需求被纳入软件项目之前，软件工程组须评审它们。
2.软件工程组采用分配需求作为软件计划、工作产品和活动的基础。
（分配需求是被管理和控制的，是软件开发计划的基础，是制定软件需求的基础。
）3.评审对分配需求的更改，将其归入软件项目。
2.2软件项目计划1.软件工程组参与项目建议组。
2.软件项目计划应在整个项目计划的早期阶段启动。
3.在项目的整个开发期内，软件工程组会与其中有关系的组一起参加计划整个项目。
4.根据已文档的规程，高级管理层参加对组织外部的个人和组所做的软件项目约定来评审。
5.识别或确定项目的软件生存周期。
例如，以瀑布或螺旋开发模型作为此项目的软件生存周期。
6.根据已文档的规程，制定项目的软件开发计划。
7.对有关软件项目的计划建立文档。
8.识别为建立和保持对软件项目的控制所必须的工作产品。
9.根据已文档的规程，得出对软件工作产品规模（或对软件工作产品规模的更改）的估计。
10.根据已文档的规程，得出对软件项目的工作量及成本的估计。
11.根据已文档的规程，得出对项目的关键计算机资源的估计。
12.根据已文档的规程，得出项目的软件进度表。
13.对与项目成本资源、进度和技术方面相联系的风险进行评估和建立文档。
14.制定关于项目软件工程设施和支持工具的计划。
15.记录软件计划数据。
2.3软件项目跟踪监督1.将已文档的软件开发计划用于跟踪的软件活动和沟通其状态。
2.按照已文档的规程，更新软件开发计划。
3.按照已文档的规程，高级管理者参与评审那些对组织外部的个人和组所做的软件项目约定和约定的更改。
4.将已批准的、影响软件项目约定的更改内容传送给软件工程组和其他软件有关组的成员。
5.跟踪软件工作产品的规模（或者软件工作产品更改的规模），必要时采取纠正措施。
6.跟踪项目的软件工作量和成本，必要时采取纠正措施。
7.跟踪项目的关键计算机资源，必要时采取纠正措施。
论需求管理和范围管理
论项目范围管理【摘要】2010年4月,我所在的单位承担了某市安全生产综合信息化管理平台的建设工作。
我有幸参与了该项目并担任了项目经理,主要负责系统整体规划、组织实施和管理控制工作。
本文结合作者的实践经验就项目管理工作中的需求管理和项目范围管理进行翔实的论述,首先讨论了需求开发、需求管理和范围管理的区别与联系。
以该项目为例,介绍了在项目需求管理和范围管理中所采取的措施和手段,包括制定符合项目实际情况的项目范围管理计划、定义清晰的项目需求和范围、创建WBS和WBS清单、进行项目范围确认、项目范围控制五个方面的内容。
最后总结了在这个项目中,需求管理和范围管理所收到的效果和不足之处。
【正文】项目概述2010年4月,我所在的单位受某市安全生产监督管理部分的委托为其开发一套安全生产综合信息化管理平台,该平台包括安全生产监测监控系统、应急救援抢险系统、安全生产监督信息管理系统和门户网站四个系统21个子系统组成。
安全生产监测监控系统实现将全市煤矿瓦斯监测数据、井下人员定位数据、重大危险源监测监控数据通过接入到应急指挥中心,实现对全市煤矿、重大危险源全天候24小时监控,将安全生产事故消灭在萌芽状态。
安全生产监督信息管理系统实现将全市被监管企业信息全方位、动态化管理,为安全执法检查提供信息支持。
应急救援抢险系统以地理信息平台为基础实现可视化的指挥调度、有序调度救援物资、救援力量,综合分析各种因素科学准确决策;门户网站实现各类监管信息、工作动态等发布,实现监管部门与公众互动。
经过项目团队的努力工作和建设方的大力支持项目于2010年10份顺利通过验收。
需求开发、需求管理和范围管理的区别与联系需求开发是通过调查与分析,获取用户需求并定义最终产品需求;需求管理是确保各方对需求的一致理解,管理和控制需求的变更,实现从需求到最终产品的双向跟踪;项目范围管理是确保项目包含且包含所必须完成的工作。
需求管理贯穿于信息系统项目的整个生命周期,只有经过需求分析才能确定项目范围。
实施CMM的常见问题及对策
文章运用 Ｃ ＭＭ 原 则． 企 业在 软 件 开发 和 管理 过 程 中常 见 的 问题 提 出相 应 的 对 策 。 结合
【 关键词 】 软件过程成熟度； ： 实施 Ｃ ＭＭ 常见 问题； 对策
０ ．引言 ：
员 补 充 学 习需 求 管 理 的知 识 和一 些 常 用 工具 和方 法 。 软 件 产业 是 信 息 产业 的重 要 组 成 部 分 ， 以高 附 加 值 、 它 高科 ２１ ．２软 件项 目计 划 问题 ． 技 水 平 的特 点 ， 渗透 到 国 民 经济 和社 会 生 产 生 活 的各 个 方 面 。 它 进 行 软 件项 目计 划 常见 的问 题 如下 ： 与传统的产业结合并进一步促进传统产业的提升 ．引导产 品更 问题 一 缺乏 书面 的用 于制 定 项 目的软 件 开 发计 划 的 规程 。 新 换代 ． 动产 业 结 构 的 调 整 。 力 发 展 软 件产 业 就 成 为促 进 社 企 业 重 视 软件 开 发 计划 ．但 是 软 件 开发 计 划 常 没 有 按 照 一定 的 推 大 会 经 济发 展 的重 要 环节 规程 或 标 准制 定 。作 为 Ｃ ＭＭ 的第 ２等 级 ， 该 制定 用 于 策 划软 应 件 项 目的 组织 方 针 和标 准 １ ＣＭＭ 的 ５个 级 别 ． Ｃ ＭＭ 描 述 了五 个 级 别 的 软 件 过 程 成 熟 度 （ 始 级 、 重 复 初 可 问题 二 对 项 目计 划 的估 计 具有 一定 的盲 目性 ． 计划 的费 所 级 、 定义级、 已 已管 理 级 、 化 级 ）成 熟 度 反 映 了 软 件 过 程 能 力 用 、 作量 、 度 太 过粗 糙 。 优 ， 工 进 用 于构 建 软件 开 发 计划 的估 计 （ 费 用 、 作 量 、 度 等 ） 如 工 进 不 （ ｆ ａ ｒｃｓ Ｃ ｐｂ ｉ ） Ｓ ｔ ｒ Ｐｏｅｓ ａａ ｉｔ ￣大小 ． ｏｗ ｅ ｌｙ 任何一个软件机构的软件 过 程 必 定 属 于其 中某 个级 别 。 了第 一级 以外 ． 除 每级 成 熟 度 由若 干 能是 虚 构 的 。 须 在 计划 中提 出估 计 时所 作 的假 设 和 根 据 ． 必 理想 关 键 过 程域 （ｅ ｒｃ ｓ Ａ ｅ） 成 可重 复级 包 括 ： 件 配 置 管 的情 况 下 。 该 使 用某 类 公 式导 出它 们 。 于企 业 缺乏 项 目管理 Ｋ ｙＰｏｅｓ ｒａ 构 软 应 由 理 、 件 质 量 保 证 、 合 同 管 理 、 目的 追 踪 与 监 督 、 目策 划 、 经验 ． 对 项 目进 行 估 算 时 过 于粗 略 。 软 子 项 项 在 需求管理 ； 已定 义 级 包 括 ： 同行 评 审 、 间协 调 、 件 产 品工 程 、 组 软 问题 三 没有 风险 识 别 、 估 和 文档 化 过 程 。 评 集 成 软 件 管理 、 培训 管 理 、 构 过 程 定 义 、 机 机构 过程 焦 点 ； 已控 制 制定 软件 开 发 计划 时 常 见 的问 题 是 没有 风 险识 别 、评 估 和 级 包 括 ： 件 质 量管 理 、 软 过程 的量 化 管 理 ： 化 级 包 括 ： 程 变 更 文档 化过 程 。 险识 别及 防范 十 分重 要 ． 优 过 风 是项 目成 功 的关 键 因 素 管 理 、 术 变 更 管理 、 陷 预 防 。 技 缺 之一 。Ｃ ＭＭ 要 求 要 鉴 别 、 估 与 项 目成 本 、 源 、 度 计 划 和技 评 资 进 任 何 一 个 成熟 度 级 别 的 关键 过程 域 都 是 本 级 描 述 的 关键 过 术方 面相 关 的 软件 风 险 ． 归人 文 档 。 并 程 域 和所 有 下 级 的 关键 过程 域 的 并 集 如 ３级 的 关 键 过 程域 应 对策 ：如 果要 想 带 来 经济 效 益 ， 业 必 须 提 高 软件 过 程 、 企 工 有 １ 不 同 的域 ，其 中 ７个 是 ３级 自 己包 含 的 ， 属 于 ２级 具 、 发 方 法 、 ３个 ６个 开 人员 等 多 种 因 素． 关 注一 个 方 面 ． 忽 略 了 其他 只 而 成 熟 度 ． ４级应 有 １ 而 ５个域 。 方 面 。 是有 害 的。 为做 好 风 险 识别 ． 求 依 据 风 险对 项 目的 潜 都 要 ２ 企 业 实施 Ｃ Ｍ 常 见 问题 及 对 策 ， Ｍ 在影 响进 行 分 析 和排 序 。 标 明对 这 些 风 险 的应 急 措 施 。 见 的 并 常 企业在实施 Ｃ ＭＭ 时 往 往 会 因 为 未 能 发现 问题 或 无 法解 决 措施 有 ： 度 缓 冲 机 制 、 进 人员 备 用 计 划 和 追加 设 备 的备 用 计 划 各 种 问 题 而 导 致其 失 败 。特 别 是 刚刚 采 纳 Ｃ ＭＭ 的企 业 ． 级 ２ ２１ 软件 项 目跟 踪 和 监督 等 ，３ 是 最 困难 的一 步 。 以下 是 分 析 实现 Ｃ ＭＭ 等 级 ２时遇 到 的 主要 问 软 件项 目跟踪 和监 督 过 程 是 Ｃ Ｍ 等 级 ２大 多 数 活 动 的 汇 Ｍ 题． 同时 以资 源管 理 为主 线 提 出 实施 Ｃ Ｍ 的 几 点对 策 Ｍ 合 。 里 ， 求 管 理 、 目计 划 、 件 质 量保 证 和 软 件 配 置管 理将 这 需 项 软 ２１实 现 Ｃ ， ＭＭ 等 级 ２常 见 的 问题 及 对 策 彼 此 协调 进 行 。 常 见 的问题 如下 ： ２１１需 求管 理 问 题 ．． 问 题 一 在形 成 相 应 的 组织 机构 的 同时 ． 没有 相应 的软 件 跟 需求管理在 Ｃ ＭＭ 中 强 调 两 种 管 理 技 术 ：一 是 对 需求 的 分 踪 和 监督 规 程 和方 针 析 ， 得 对 需 求 的 理 解 以便 进 行 项 目策 划 ： 是 密 切 跟 踪 需 求 ． 获 二 这 一 规程 十 分 重要 ．不 仅要 保 证 软 件 项 目跟 踪 和监 督 活 动 进 行 需求 变 更 管 理 和控 制 。 以下 是 企 业 在 需 求 管 理 上 常 出现 的 的顺 利进 行 ，还要 保 证 在项 目更 改 时 采 取 相 应 的 评 审制 度 和 措 问题。 施 ， 别 是在 跟 踪 和 监督 过 程 各 小组 的 责 任 分配 。 特 问 题 一 需求 管 理 人 员 缺 乏 经验 并 且 很 少 接受 培训 问 题 二 缺 乏 相应 的调 整项 目变动 的 能 力 由于 需 求 管理 人 员 是 由开 发 人 员 承担 ．要 求 需 求 管 理 人 员 由于 缺乏 经 验 。 项 目变更 时 难 于做 出判 断 ． 没有 利 用 相 在 也 有 相 关 的项 目应 用 领域 的业 务 知 识 ．需 求 管 理 人 员 往 往 缺 乏 这 应 的 技术 和工 具 来 实现 项 目更 改 控 制 方 面 的 经 验 。 另外 ， 其 他 很 多 企 业 一 样 ． 业 往 往 忽 视 对 需 求 像 企 问 题 三 没 有 相应 的 机 制 确 保 有 关 项 目的情 况 及 时 向 有 关 管 理 人员 的培 训 。Ｃ Ｍ 特 别 强调 了 对需 求 管 理 人 员 的培 训 ． Ｍ 同 的 全 部项 目成 员 通报 时 也 意识 到 需 要 对 项 目团 队进 行 有 关 的应 用 业 务 领 域 的 指 导 软 件 项 目跟踪 和 监 督过 程 除 了 确保 使 用 一 个 计 划 来 管 理项 问 题 二 分 配 给 定 需 求 ， 给 定 需 求 作 为 软 件 开 发 计 划 、 作 产 目进 展 外 ．还 要 确 保有 关 项 目的 情况 及 时 向有 关 的 全 部 项 目成 将 工 品 和 活 动 的基 础 时 ． 有 一 定 的 盲 目性 。 具 员 通 报 的 重任 由于 需求 管理 人 员 缺 乏 经验 并 且很 少 接 受 培 训 ．导 致 把 给 ２１ ．４软 件质 量 保 证 ． 定 需求 作 为软 件 开 发 计 划 、 作 产 品 和 活 动 的 基础 时 ． 有 一 定 工 具 软 件 质 量保 证 是 大 多数 企 业 较 为 薄弱 的环 节 常 见 问题 如 的 盲 目性 。 目策 划 工作 与需 求 之 间很 难 衔 接 ． 没 有 什 么根 据 下 ： 项 也 或 标 准 去 管理 给 定 需 求 ， 么 ． 定 需 求 将 失 去 软 件 工 程 和 管 理 那 给 软 件 质 量 保证 往 往 只 注 重 软件 产 品 的 质量 ．而 没有 注 重 软 的 基 线作 用 件 开 发 活 动 的质 量 保证 ；没 有 形 成一 个 书 面 的实 施 质 量 保 证 的 以上 两 个 问题 的 根 本 原 因 在 于 需 要 管 理 人 员 经 验 不 足 ． 组 织 方 针 或 文档 化 规程 ：没 有使 用测 量 来 确 定 质 量 保 证 活 动的 因
CMMI模型与实践
PA关系
小结
CMMI概念
过程改进
CMMI模型
13
谢谢观看！
14
了产品。
4
核心思想——过程改进
不成熟过程或组织的特点？
无序的过程是由实践者和管理者临时拼凑的 末得到严格定义 高度依赖于当事者 对进展和质量的低可视性
产品功能性和质量可能因满足进度而作出让步
新技术的应用有很大风险 过量的维护费用 质量难以预测 缺少进一步改进的客观基础
它们是建立过程能力最主要的元4级量化管理级量化项目管理组织过程性能3级已定义级需求开发5级优化级组织创新和实施原因分析和解决9能力最主要的元素模块5优化级24定量管理级23已定义级132已管理级71初始级02级已管理级配置管理过程和产品质量保证供应商合同管理项目监控项目计划需求管理度量和分析需求开发技术解决方案验证确认产品集成集成项目管理组织过程焦点组织过程定义组织培训风险管理决策分析和解决集成化组织环境集成化的团队核心思想过程改进需求开发requirementsdevelopment技术解决方案technicalsolution产品集成pdtittiml5优化级组织变革和发展organizationalinnovationanddeployment原因分析与方案causalanalysisandresolution组织过程绩效organizationalprocessperformance量化的项目管理quantitativeprojectmanagementml4定量管理级分类过程域特征持续改进定量管理持续改进定量管理10产品集成productintegration验证verification确认validation组织过程焦点organizationalprocessfocus组织过程定义organizationalprocessdefinition组织培训organizationaltraining风险管理riskmanagement集成的项目管理integratedprojectmanagement决策和分析decisionanalysisandresolutionml3已定义级需求管理requirementsmanagement项目策划projectplanning项目监控projectmonitoringandcontrol分供方协议管理supplieragreementmanagement度量和分析measurementandanalysis配置管理configurationmanagement过程和产品的质量管理processandproductqualityassuranceml2已管理级组织过程标准化基本项目管理组织过程标准化基本项目管理cmmi模型过程域maturitylevelprocessareaprocessareaprocessarea通用目标特定目标通用实践特定实践pa解读cmm
CMM实践-利用RequisitePro进行需求管理[1]
CMM实践-利用RequisitePro进行需求管理[1]需求管理中的问题在CMM3中需求管理(RM)关键过程域是非常重要的一个环节。
在我们公司CMM3级的实践中，需求管理往往是非常花费成本的一个工作，比如，在需求分析、建立需求跟踪矩阵等活动中，如果是一个团队或是几个小组在进行协作时，会有大量的Word、Excel文件需要在不同的人员间传递，其间即使用了类似VSS等工具，仍然没办法避免繁琐低效的工作方式，其间会产生例如文档传递不顺畅、协作人员的需求用例重叠、扩展需求遗漏等等问题，在实施CMM3时，此环节更为公司增加了大量运作成本。
比如，在多人协作完成需求分析，对所有需求用例进行管理的活动中，需求人员只能根据前面的需求调研报告，所有的人使用同一份Word文档模版，分别详细分析与描述属于自己任务内的需求用例，然后负责人再把每个人写好的Word文档进行合并，这种合并完全是手工的合并，同时，对于每个人需求分析的情况，只能阅读所有的文档内容才能检查出是否有所遗漏等严重问题。
再比如，公司在使用最原始方法建立需求跟踪矩阵时，往往是用一个Excel表，列出一个二维表，把软件生存期的几个阶段做为几列，例如“需求”，“设计”、“编码”、“测试”、“发布”等，然后首先由需求分析人员在第一列的“需求用例”上，列出所有的需求点，然后再把这个Excel表交给设计人员，再由设计人员在第二列的“设计”上，列出每个需求对应的设计项，这样一直传递下去。
其间这张表也不知经过了多少人的手，一旦其中某阶段一项做了修改，很难安全保障正确的向前追溯。
如果为了解决以上问题，公司自行开发一些管理工具，仍然需要花较大成本。
Rational RequisitePro特性IBM® Rational® RequisitePro® 解决方案是一种需求和用例管理工具，能够帮助项目团队改进项目目标的沟通，增强协作开发，降低项目风险，以及在部署前提高应用程序的质量。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CMM需求管理实践经验记录谈
在做了近四个多月的CMM翻译及文档整理资料工作后，为了验证CMM理论是否真正适合本部门的开发过程及引导提升的作用，最近参与一个项目的需求调研工作，这时候所处的角度就与原先处于开发人员的角度有所差异，此时，考虑的是如何在开发过程中加入CMM的KPA过程活动，在这个不大不小的项目中，在近一个多月的需求调研中，确确实实存在一些问题，值得我们开发人员去思考，这不仅仅涉及是否要按CMM要求去做，更涉及了如何做好需求，如何在需求调研中少走弯路，如何更能准确地制定需求;需求过程中的控制点、操作规程、协同运作等等。
分析阶段：“准备需求采集和分析”
管理要求：
①阅读有关行业/技术概念上的背景资料或相关标准、公文、规则等等
②熟悉客户的操作流程
③确定信息采集和分析的方法
④确定用户组和评审组，及评审方式
⑤项目风险的评估
大部分的需求调研中，以上的准备工作常常被忽略，在这次的操作中，虽然注意了该方面的运作，但还是出现了一些问题，影响了需求调研的工期。
首先，确定信息采集和分析的方法，由于该系统是客户方的一个类似商务操作流的控制系统，在收集信息过程中，我们过于相信客户方最初提供的资料，在熟悉客户的流程后，依照客户方提供的资料进行项目的初步成本、工期、资源的核算。
但是，在后面的调研时，客户业务流程发生较大的变动，细化点众多，功能点较原先估计的繁杂。
出现这样的问题原因在于：1、客户原先手工操作无任何限制，而系统约束性较高。
2、在需求调研中客户方发现其流程存在不合理的地方即产生变动，变动性大(该点我们无法控制)。
3、与我们进行沟通的客户方人员无决策权。
双方在讨论一个流程的实现过程中，对方无权对流程的简、繁进行决策，往往讨论半天实现该功能后，其部门经理一句话就推翻原先拟定的流程，在这点上浪费了许多时间，这也是我们准备过程中的一个失误，当初应该事先申明，沟通人员必须有一定的决策权(这是在确定用户组上的失策)。
当在熟悉、确定客户操作流程上，我们浪费了很多时间，至后来双方在沟通及决策上达成一定的协议后，后期的调研工作顺利很多，但最终产生的系统需求与原先客户提供的需求已经是截然不同的了，最终需求得出的成本、工期、使用资源都已翻了好几番。
分析阶段：“收集和分辨需求”
管理要求：
①分辨技术(功能点)与非技术(交货日期、里程碑、协议条件等)需求
②建立系统目标和范围
③收集相关技术需求(功能点、约束、处理等)
④收集用户特殊需求
⑤分析用户工作流程
⑦准备原型
该阶段工作较顺利，基本上按要求完成，其实该阶段与第一阶段―――“准备需求采集和分析”基本上可融合，故在双方按一定要求达成沟通协议后，在业务流程及功能点收集上进展较顺利，准确性也较高。
分析阶段：“分析—编写文档—评审”
根据收集到的功能需求，接下来，项目组各人分工进行模块功能需求的分析工作，按模块的操作角色、模块功能、输入、处理流程、输出等进行技术需求的细分析，该部分与编写文档同步进行。
在进行分析及编写文档时，为了确定较准的最终功能需求，分析做得比较细，可以避免后期与客户的纠缠不清。
分析时用UML画的业务流图在与客户沟通时发生一点问题，客户无法看懂其图内容，故建议以后项目内部沟通分析时采用UML用例图及流程图，与客户进行沟通时使用通用的流程图较方便。
当各模块的分析文档完成时，单单模块功能就写了160多页，其中还不包括近五十张报表的分析数据。
此时的功能需求与原先客户给的9页的需求已经大相径庭了。
最终整合的需求依照“CMM系统需求规格说明书模板”进行编写，由于在每个模块分析时均注上标号，便于其后需求变更的跟踪及修改。
评审时准备采用CMM软件质量保证过程要求的“系统需求分析过程评审检查列表”，实际评审中与列表要求的还是会有一定的距离，标准度及执行度暂无法做到CMM完全要求的，只能尽量往其中的要求点靠拢了。
其中“系统需求分析过程评审检查列表”的基本内容要求如下：
____软件需求分析被记录在软件需求说明书或者其他经核准的正式文档中
____软件来源的明确性
____对于用户给定的需求，文档记录是否完整及有遗漏项
____软件需求在配置管理下维持(配置标识)
____文字说明清晰、适当
____前后一致，变更依据是否充分，是否有正常的记录
____功能的可测试性
____评估需求的可行性，是否适用于软件实现
____软件开发计划、工作产品，以及活动的变更与软件需求的变更相一致
____验收被制定，并且使用来确定需求管理的状态
在评审中，以上的要求可以起到一定的引导作用。
分析阶段：“交付验收”
在交付给用户验收时，所需附上的产品有：各模块的功能分析文档、整合的需求规格说明书、需求验收文档。
管理要求：
①客户对确定的需求无疑异，在验收文档上签字
②若客户提出相应的变更，则为变更做好记录，修改后的变更依然应通过评审才能交付用户。
③客户签收的需求作为系统的需求基线确立下来，
分析阶段：“需求变更过程”
该过程主要针对确立需求基线后的变更。
目前该项目还未涉及(待续!)
管理要求：
①提出变更请求(变更项、变更原因)
②变更可行性评估
③变更评审
④更新基线
CMM过程中有一个详细的“日常工作变更请求过程样例”，日后有机会再细谈该变更的管理过程及实现方式。