CMMI需求开发
cmmi软件开发流程
软件开发流程软件项目生命周期模型需求分析需求分析流程图过程描述1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。
3、PM指示配置管理员建立配置库。
4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。
5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。
6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。
7、项目组人员与客户进行沟通，编写需求清单列表。
8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。
架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。
对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。
关于自行开发和采购复用的分析，如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用；本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购；否则，由项目组自行开发。
架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。
10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。
11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。
12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。
13、PM、测试负责人与临时项目组确定项目关键参数。
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：市场营销用户需求管理层需求开发需求管理市场营销管理层项目环境项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理在CMMI 中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。
●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者l 识别出需求的接受标准：a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证（测试）g. Traceable可追溯l 分析需求，确保符合已建立的准则。
CMMI标准学习需求开发(RD)课件
CMMI标准学习需求开发(RD)
SG 1 开发客户需求
SP1.1 提取需求：
子实践 ：
使相关的关系人一起参与，使用方法以便提取需求、期望、约束和外部 接口
CMMI标准学习需求开发(RD)
SG 1 开发客户需求
代表产品生命周期各个阶段的相关干系人，应该包括商业和技术功 能。如此以来，才能考虑产品生命周期过程概念和产品概念。客户 需求是通过商业和技术的影响而产生共识性的结论。
CMMI标准学习需求开发(RD)
SG 1 开发客户需求
SP1.2 开发客户需求： 把干系人的需要、期望、约束条件和接口转换为客户
CMMI标准学习需求开发(RD)
需求开发示意图
开发客户需求
开发产品需求
分析和确认需求
客户需求 产品、产品组件和接口需求 确认后的需求
CMMI标准学习需求开发(RD)
本PA一些常用词
• Requirements Development 需求开发 • product component 产品组件 • Elicitation 提取 • Expectation 期望 • Constraints 约束 • Interfaces 接口 • Stakeholders 干系人 • Derived 衍生 • refined and elaborated 详细和明确 • operational concepts 操作概念 • product concepts 产品概念 • operational scenarios 操作场景 • acquisition strategy 采购策略 • functional architecture 功能架构
CMMI介绍
CMMI 能解决我们的问题吗（3）
• 更多的问题… • CMMI的实践能帮助我们逐步改善上述问题，直到
最终的解决。
• CMMI是一门科学，是一门经验科学。 • CMMI是世界上优秀的软件开发组织的最佳实践的
集合。CMMI不会给出文档的格式，实践CMMI需 要结合公司的实际。
• CMMI与敏捷编程是完全相容的，二者并不矛盾。
医头，脚疼医脚。 – 评价解决后的改进效果。 – 为什么在5级，因为改进效果必需被精确度量。
RD 需求开发 CMMI评估提问单(重要)产品经理学习资料
在输出需求规格说明书后评审之前，QA会检查，有不符合 项的，对不符合项整改之后，QA再次检查确认。
GP 2.9
2、检查发现的不符合项记录在QA不符合项跟踪表里，明确
解决责任人，跟进解决情况。 要点：
1、项目周报、项目月报、里程碑报告等会发送给高层经理 GP 2.10
。 要点：
1、无裁剪
GP 3.1
2、有裁剪(《项目PDP》)
GP 2.2
要点：
1、标准过程和输入、输出工作模板文件。
2、手提电脑、台式机等工作电脑；投影仪等硬件设备。 GP 2.3
3、SVN配置库；OFFICE、Vision等所需的软件 。
4、人力资源支持。
要点：
1、项目管理计划有需求人员的工作职责。
GP 2.4
2、每周一例会上也会说明各个角色的人员职责。
1、需求调研计划中识别了需求调研干系人。
2、通过WBS任务项，以需求会议、需求访谈等。
3、会议纪要、评审报告等记录了干系人的参与。 要点：
通过项目周报、例会、WBS任务项进行跟踪。 要点：
GP 2.8
1、QA会检查需求开发和管理的过程有没有符合标准过程。
ATMs Mini Team Memebr Names:
Q. No. Questions and Follow Up Questions
RD 需求开发
1
如何获得用户对系统的要求、期望、约束条件等内 容?
2 用户需求是如何形成的？
3 产品需求是怎么形成的
4 有哪些接口性需求？
5
在需求分析的时候，你采用了哪些方法来清楚的描 述一个功能性需求的？
CMMI PPSP/PP-GP SP 1.1 SP 1.2
cmmi评估范围
cmmi评估范围
1. 软件开发：CMMI 针对软件开发过程提供了评估标准，包括需求管理、项目策划、软件设计、编码与测试、配置管理等方面。
2. 系统工程：CMMI 可以评估系统工程过程，包括需求开发、系统设计、系统验证与确认、系统集成等方面。
3. 集成产品开发：CMMI 也适用于集成产品开发过程，包括产品规划、产品设计、产品开发、产品验证与确认等方面。
4. 服务管理：CMMI 可以评估服务管理过程，包括服务策划、服务提供、服务监控与度量等方面。
5. 采购与供应管理：CMMI 还涵盖了采购与供应管理过程，包括供应商选择、采购合同管理、供应绩效监控等方面。
需要注意的是，CMMI 评估的具体范围和内容可以根据组织的业务需求和目标进行定制和调整。
评估的目的是帮助组织识别改进的机会，并推动持续的过程改进和能力提升。
cmmi软件开发流程图
软件开发流程软件项目生命周期模型需求分析需求分析流程图过程描述1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。
3、PM指示配置管理员建立配置库。
4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。
5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。
6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。
7、项目组人员与客户进行沟通，编写需求清单列表。
8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。
架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。
➢对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。
➢关于自行开发和采购复用的分析，如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用；本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购；否则，由项目组自行开发。
架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。
10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。
11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。
12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。
13、PM、测试负责人与临时项目组确定项目关键参数。
CMMI3级18个过程域
CMMI3级18个过程域CMMI（Capability Maturity Model Integration）是一种用于评价和改进组织的软件工程能力的模型。
CMMI模型将软件工程能力分为不同的级别，目前最高级别是CMMI级别5、在CMMI模型中，共有18个过程域，每个过程域都包含一组过程目标和过程实践。
下面将介绍CMMI级别3中的18个过程域，并对每个过程域进行详细解析。
1. 要求开发（Requirements Development）：该过程域涉及确定、分析和记录系统和软件需求的活动。
它包括需求的获取、管理、分析和验证。
2. 要求管理（Requirements Management）：该过程域涉及组织和控制项目的需求。
它包括需求的识别、跟踪、控制和变更管理。
3. 项目计划和监控（Project Planning and Monitoring）：该过程域涉及制定和维护项目计划，并监控项目活动的执行。
它包括识别和规划项目活动、建立项目计划、监控项目进展和基于此进行调整。
4. 项目监控和控制（Project Monitoring and Control）：该过程域涉及监控和控制项目执行过程中的工作和活动。
它包括收集和分析项目绩效数据、对比实际和计划绩效，对项目进展进行控制。
5. 供应商协议管理（Supplier Agreement Management）：该过程域涉及与供应商达成协议，并管理和监控供应商的活动。
它包括选择供应商、与供应商协商、管理和控制供应商的交付和绩效。
6. 产品集成（Product Integration）：该过程域涉及对各个组成部分进行整合，形成最终产品。
它包括定义和实施产品集成策略、执行产品集成和验证集成后的产品。
7. 风险管理（Risk Management）：该过程域涉及识别、评估和控制项目和产品的风险。
它包括制定风险管理计划、识别和评估风险、并采取相应的风险缓解措施。
8. 决策分析和解决方案评估（Decision Analysis and Resolution）：该过程域涉及通过分析和评估不同的解决方案，制定决策。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
成熟度3级的工程过程域目的需求开发(Requirements Development, RD)的目的，在于产出并分析客户、产品及产品组件的需求。
业界注释本过程域描述客户、产品及产品组件等三种需求，这些需求说明相关关键人员的需要，包括与产品生命周期各阶段 (如，验收测试准则)及产品属性 (如，安全性、可靠性、与维护能力等) 有关的需要。
需求也包括选择某设计解决方案而产生的限制条件。
例如：与现成品整合的需求。
所有开发项目都有需求，从项目于维护活动的项目案例来看，产品或产品组件的变更，是基于现有需求、设计、或实作的变更。
需求变更可能来自顾客或用户所记载的变更请求单，或来自于需求开发过程的新需求形式。
不论需求来源或型式，变更所驱动的维护活动也要加以管理。
需求是设计的基础，需求的开发包括下列活动：引导、分析、验证，以及沟通客户的需要、期望及限制，以获得客户需求，并达成关键人员的共识搜集和协调关键人员的需要开发产品的生命周期需求建立客户需求建立与客户需求一致的原始产品及产品组件需因为客户也可能提出特定的设计需求，本过程域讨论所有客户的需求，而非局限于产品层次的需求。
客户需求可进一步细化为产品及产品组件需求。
除客户需求外，选定的解决方案也可能衍生产品及产品组件需求。
整个过程域中，产品及产品组件的意涵也包括服务及其组件。
在整个产品生命周期中识别并修订需求。
对设计决策、后续的纠正措施，以及产品生命周期各阶段所产生的回馈进行分析，以了解它们对衍生及已配置需求的影响。
需求开发过程域包括三项特定目标。
”开发客户需求」特定目标说明如何定义完整的客户需求，以使用于产品需求开发。
”开发产品需求」特定目标说明如何定义完整的产品和产品组件需求，以使用于产品和产品组件设计。
”分析并确认需求」特定目标说明客户、产品及产品组件需求须执行的必要分析，以定义、衍生及了解需求。
第三项特定目标的特定执行方法，用以辅助前两项特定目标的特定执行方法。
需求开发过程域的过程和技术解决方案过程域的过程，可彼此相互循环互动。
对竞争的备选方案进行分析，以了解、定义及选用各层次的需求。
这些分析活动包括：分析产品生命周期每阶段的需要和需求，包括：相关关键人员的需要、操作环境，以及反映所有客户及使用者的期望和满意的因素(如安全性、保密性及负担能力)开发操作观念定义必要的功能功能的定义，也称为“功能分析”，与软件开发的结构化分析不同，也不能假定为功能导向的软件设计。
在面向对象的软件设计里，它相当于定义所谓的“服务”或“方法”。
功能、功能的逻辑群组，以及它们和需求之间关联的定义，就是所谓的”功能架构」。
对产品架构更细层次不断地分析，直到获得足够的细节以进行产品的细部设计、采购及测试。
经由分析需求的结果及操作概念(包括功能性、支持、维护及销毁)，制造或生产的概念会产生出更多的衍生需求，包括下列考量：不同类型的限制技术的界限成本和成本因素时间限制和日程因素风险客户或使用者所暗示但未明确陈述的议题的考量开发者独特的经营考量、规定及法律等所产生的因素逻辑实体的层次架构(功能及子功能，对象类别及子类别)，建立在反复开发的操作观念里。
需求经过细化、衍生，才能配置到该逻辑实体。
需求和逻辑实体再被配置于产品、产品组件、人员、或相关过程。
I在需求开发和分析时，纳入相关关键人员的参与，藉此使他们了解需求的演进过程。
本活动持续向相关关键人员提供保证：需求已适切定义。
相关过程域有关管理客户及产品需求、取得需求提供者同意、取得需求执行者承诺及维护追溯性，请参考需求管理过程域，以获得更多信息。
有关如何使用需求开发过程域的输出，以及开发替代方案和设计，以用于细化和衍生需求，请参考技术解决方案过程域，以获得更多信息。
有关验证最终产品是否符合需求，请参考验证过程域，以获得更多信息。
有关确认如何依照客户需要建置产品，请参考确认过程域，以获得更多信息。
有关需求相关风险的识别和管理，请参考风险管理过程域，以获得更多信息。
有关确保重要工作产品的控管，请参考配置管理过程域，以获得更多信息。
.特定目标及实践摘要SG 1开发客户需求SP 引导需要SP 开发客户需求SG 2开发产品需求SP 建立产品与产品组件需求SP 配置产品组件需求SP 识别接口需求SG 3分析并确认需求SP 建立操作概念及场景SP 建立必要功能的定义SP 分析需求SP 分析需求以取得平衡SP 确认需求各特定目标的实践SG 1 开发客户需求关键人员(例如：客户、最终使用者、供货商、建置人员、测试人员、制造人员，与后勤支持人员)的需要，是决定客户需求的基础。
进行关键人员的需要、期望、限制、接口、操作概念，以及产品观念的分析、协调、细化及详细说明，以转换成客户需求。
关键人员的需要、期望、限制及接口，经常被粗略的识别或相互矛盾。
因为必须清楚识别和了解关键人员的需要、期望、限制及界限，在整个项目的生命周期里可使用反复的过程，以达到这目标。
为协助此必要的循环过程，最终用户或客户的代表，通常会加入此过程，以说明其需要并协助解决矛盾。
组织的客户关系或营销部门，以及来自人际工程或支持部门的开发团队成员，可视为此类的代表。
在研拟和解决客户需求时，也应考量客户的外在环境、法规及其他限制.SP 引导需要引导相关干系人提出有关产品生命周期各阶段的需要、期望、限制及接口.引导不只是积极识别尚未经客户明确提出的新增需求。
新增的需求应描述各种生命周期的活动，以及它们对产品的影响。
引导需要的技术，举例如下：技术展示接口管制工作组技术管制工作组临时的项目审查由最终使用者取得的问卷、访谈及操作场景等数据操作的审查和最终使用者的工作分析原型和模型脑力激荡质量机能展开市场调查试用版本的试用由文件、标准或规格等来源中抽取观察现行产品、环境及工作过程的样式（patterns）使用案例（use cases）经营案例分析采取反向工程（针对现有产品）客户满意度调查可能未被客户识别的需求来源，举例如下：经营策略标准经营环境要求（例：研究室、测试其他设施、信息科技基础建设等）技术现有产品或产品组件(可再用产品组件)子实践1. 与相关的干系人一起参与，并使用方法，以引导出需求、期望、限制及外部接口。
SP 开发客户需求来自相关关键人员的各种输入，须经合并、取得遗漏的信息，以及解决冲突等过程，并记录为客户需求。
客户需求可包括与验证和确认有关的需要、期望及限制。
某些情况来说，客户提供项目的一套需求，或者之前项目活动的需求产出。
以这些情况来说，客户需求与相关关键人员的需要、期望、限制及接口可能有所冲突，所以在冲突适当解决之后，需要转换成被认可的客户需求。
代表产品生命周期的所有阶段的相关关键人员，应包括经营及技术功能。
因此，所有与产品生命周期相关的过程概念，都应与产品的概念同步考量。
客户需求来自信息充分的决策，同时考量需求在经营面与技术面的影响。
典型的工作产品1. 客户需求。
2. 执行验证时的客户限制。
3. 执行确认时的客户限制。
子实践1.转换关键人员的需要、预期、限制及接口，成为客户需求。
2. 定义验证及确认时的限制。
SG 2 Develop Product Requirements分析客户需求并开发操作概念，以衍生更详细和精准的需求，此需求称为“产品与产品组件需求”。
“产品与产品组件需求”说明产品生命周期每一阶段的相关需要。
衍生需求是由限制、对某些隐含议题的考量及某些因素而间接产生，这些议题在客户需求基准中并未明确说明；而这些因素是基于所选用的架构、设计，以及开发者独特的经营考量等而产生。
需求须以后续的、较低阶的需求及功能架构再检查，并细化优先的产品概念。
配置需求于产品功能及产品组件，包括对象、人员及过程，并记录需求到功能、对象、测试、议题，或其他实体的追溯性。
已配置的需求及功能是组成技术解决方案的基础。
当开发内部组件时，须定义新增的接口，并建立接口需求。
有关维护双向追溯性，请参考需求管理过程域的「维护需求的双向追溯性」特定执行方法，以获得更多信息.SP Establish Product and Product Component Requirements根据客户需求，建立和维护产品和产品组件的需求。
客户需求可能以客户术语表示，且以较不具技术的方式描述。
产品需求则是以专业术语表示这些客户需求，以用来进行设计的决策。
“质量机能展开”是此转换的范例，它描述客户期望与技术参数的对应关系。
例如：“结实的门”可能对应到尺寸规模大小、重量、适合、湿度及共振频率。
“产品与产品组件需求”强调客户、经营，以及项目目标和相关属性(如有效性和负担能力)的满足。
衍生需求也包括其他生命周期阶段的成本和绩效 (如，生产、操作及销毁)，以与经营目标兼容。
.需求管理过程域涵盖需求变更的管理，而本特定执行方法的“维护”部分，涵盖因已核准的需求变更而引起的需求修改活动。
有关管理需求变更，请参考需求管理过程域，以获得更多信息。
.典型的工作产品1. 衍生需求2. 产品需求3. 产品组件需求子实践1. 以专业术语开发产品与产品组件设计的需求。
针对产品架构设计所需的重要的产品质量和绩效，开发架构需求。
2. 由设计决策衍生需求。
有关开发解决方案以产生其他衍生需求，请参考技术解决方案过程域，以获得更多信息。
.技术的选用会引进其他的需求。
例如：运用电子学将增加特定技术的需求，如电磁干扰的界限。
3. 建立并维护需求间的关连性，并考量在变更管理和需求配置时的影响。
有关维护需求追溯，请参考需求管理过程域，以获得更多信息。
需求间的关连有助于评估变更的影响。
SP 分配产品组件需求为每个产品组件分配需求。
有关配置需求到产品和产品组件，请参考技术解决方案过程域，以获得更多信息。
本执行方法提供信息以定义需求配置，但必须和技术解决方案过程域的执行方法互动，以建立配置需求的解决方案。
上述中所定义的解决方案，其产品组件的需求，包括所配置的产品绩效、设计限制，以及符合需求和有助于生产的合适、形式及功能。
假使较高阶需求的指定绩效归属于两组或以上的产品组件时，该绩效必须进行切割，并单独配置到各个产品组件，就像是衍生需求一样。
.典型的工作产品1. 需求配置表2. 暂时性的需求配置3. 设计限制4. 衍生需求5. 衍生需求间的关系细部执行方法子实践1. 分配需求于功能。
2. 分配需求于产品组件。
3. 配置设计限制于产品组件。
4. 记录已配置需求间的关系。
关系包括依赖性，在这情境下，某需求的改变可能会影响其他的需求。
SP 识别接口需求定义功能之间(或对象之间)的接口。
功能接口可能衍生出替代方案的开发，替代方案在技术解决方案过程域中描述。
有关接口管理以及产品和产品组件的整合，请参考产品整合过程领域，以获得更多信息。
定义产品架构中所识别之产品与产品组件间的接口需求，并将它们当做产品与产品组件整合的一部分来管制，它们也是架构定义中不可缺少的部分。