CMMI2 PA之 需求管理(REQM)
CMMI体系22个PA信息文件清单
实践 对应规程文件 小组 责任人 GP 2.1 建立组织级方针 GP 2.2 计划过程 GP 2.3 提供资源 GP 2.4 分派职责 GP 2.5 培训人员 QMS-ARCH-P01规程概述与方 GP 2.6 控制工作产品 针 领导小组 GP 2.7 识别相关干系人,并使之参与 QMS-PI-P01 过程改进规程 GP 2.8 监督并控制过程 GP 2.9 客观评价遵守程度 GP 2.10 与上级管理层一起进行状态评审 GP 3.1 建立已定义的过程 GP 3.2 收集与过程相关的经验 SP 1.1 识别配置项 QMS-CM-P01 配置管理规程 SP 1.2 建立配置管理系统 QMS-NA-P01 系统网络管理规 SP 1.3 创建或发布基线 程 配置管理改进 SP 2.1 跟踪变更请求 QMS-PAM-P01 产品档案管理 SP 2.2 控制配置项 规程 SP 3.1 建立配置管理记录 QMS-RC-P01 文件控制规程 SP 3.2 执行配置审计 SP 1.1 建立度量目标 SP 1.2 明确说明度量项 SP 1.3 明确说明数据收集与存储的规程 QMS-MA-P01 度量分析规程 SP 1.4 明确说明分析规程 度量改进 SP 2.1 获得度量数据 SP 2.2 分析度量数据 SP 2.3 存储数据与结果 SP 2.4 沟通结果 SP 1.1 监督项目计划参数 SP 1.2 监督承诺 QMS-PM-P01 项目管理规程 SP 1.3 监督项目风险 QMS-PM-P02 系统集成项目管 SP 1.4 监督数据管理 理规程 CMMI2-3级改 SP 1.5 监督干系人的参与 QMS-MRP-P01 项目管理评审 善小组 SP 1.6 进行进展评审 规程 SP 1.7 进行里程碑评审 QMS-RC-P01 质量记录监控规 SP 2.1 分析问题 程 SP 2.2 采取纠正措施 SP 2.3 管理纠正措施 SP 1.1 估算项目范围 SP 1.2 建立对工作产品与任务属性的估算 SP 1.3 定义项目生命周期阶段 SP 1.4 估算工作量与成本 SP 2.1 建立预算与进度 SP 2.2 识别项目风险 SP 2.3 计划数据管理 QMS-SEM-P01软件估算管理规程 CMMI2-3级改善小组 SP 2.4 计划项目资源 SP 2.5 计划所需的知识与技能 SP 2.6 计划干系人的参与 SP 2.7 建立项目计划 SP 3.1 评审影响项目的各项计划 SP 3.2 协调工作与资源水平 SP 3.3 获得对计划的承诺
CMMI3-PA解读 (需求管理培训)_V2
需求管理(REQM)培训授课说明REQM: Requirements Management •保持课堂安静•手机设置为震动•任何人可以提议休息•签到课程目的•理解需求管理的目标与内容•需求管理与其他过程域的关系•了解需求管理的应用议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例需求管理的目的•需求管理目的:管理产品需求和产品组件的需求,并且确保能把需求的更改反映到项目计划、活动和工作产品中。
•需求:项目接收的或项目产生的产品和产品组件需求以及组织对项目实施的要求。
议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例工程类过程域••RDPIValCustomerTSVerREQMRequirements 需求Customer needs 客户需求Product and productcomponent requirements 产品和产品构件需求Product components, work products,verification and validation reports 产品组件、中间产品以及验证和确认报告Productcomponents产品组件Alternative solutions供选择方案Require-mentsProduct与其他过程域的关系-1注:REQM:需求管理RD :需求开发TS :技术解决PI :产品集成VER :验证VAL :确认与其他过程域的关系-2z需求开发(RD):将关键人士需求转为产品需求,并决定如何配置到产品组件z技术解决(TS):将需求转为技术解决方案z项目计划(PP):有关于项目计划如何反应需求或因应需求而变动z配置管理(CM):有关与需求相关之文件控制管理部分z项目监督和控制(PMC):有关需求之各项项目活动与工作产品之跟踪监控议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例RequirementsObtain an UnderstandingofRequirements 获得可理解需求Obtain CommitmenttoRequirements 获得对需求的承诺Traceability Matrix orRequirements Tracking SystemMaintain Bidirectional Traceability of Requirements 维护需求的双向可溯性Identify Inconsistencies Between Project Work and Reqmts 识别需求和工产品不一致性Manage Requirements 需求管理Manage Requirements Changes 管理需求的变更需求管理内部结构议程•需求管理的目的和意义•与其他过程域的关系•需求管理的内部结构•特定目标与特定实践•共性目标与共性实践•需求管理过程的示例特定目标与特定实践•SG1 管理需求对需求进行管理并识别与项目计划和工作产品之间的不一致之处。
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的22个过程域及其特定目标和实践
CMMI的22个过程域及其特定目标和实践CMMI共含有22个过程域:一、项目管理类:1、项目策划(PP):SG1 完成参数估计SP1.1 估计项目的范围SP1.2估计项目属性SP1.3确定项目生存周期SP1.4 确定工作量和成本的估计值SG2 拟订项目计划SP2.1 编制预算和进度 SP2.2识别项目风险 SP2.3策划数据管理 SP2.4策划项目资源 SP2.5 策划必要的知识和技能 SP2.6策划共利益者的介入 SP2.7拟订项目计划SG3 获得对计划的承诺SP3.1 审查从属计划 SP3.2使工作与资源配备协调 SP3.3获得计划承诺2、项目监督和控制(PMC):SG1 对照计划监督项目SP1.1 监督项目策划参数 SP1.2 监督承诺 SP1.3监督项目风险 SP1.4监督资料管理 SP1.5监督共利益者介入情况 SP1.6进行进展审查 SP1.7里程碑审查SG2 管理纠正措施,直到结束SP2.1 分析问题:收集并分析问题,确定处理这些问题所需的纠正措施SP2.2 采取纠正措施:对所识别的问题采取纠正措施3、集成项目管理(IPM)+IPPDSG1运用项目已定义过程SP1.1建立项目已定义过程 SP1.1运用组织过程财务策划项目活动 SP1.1建立项目工作环境综合计划 SP1.1运用综合计划管理项目 SP1.1充实组织过程财富SG2与相关的共利益者协调和合作SP2.1管理共利益者介入 SP2.2管理依存关系 SP2.3解决协调问题SG3IPPD应用(应用IPPD原则)SP3.1 建立项目的共同愿景 SP3.2 建立集成团队架构 SP3.3 分配需求至集成团队 SP3.4 建立集成团队 SP3.5确保跨团队间的合作4、供方协定管理(SAM)SG1 建立供方协定SP1.1分析由项目所决定的需求 SP1.2选择供方 SP1.3 建立供方协定SG2 满足供方协定SP2.1执行供方协定 SP2.2监督选定的供方过程 SP2.3评估选定的供方工作产品 SP2.4接受取得的产品 SP2.5移交产品5、风险管理(RSKM)SG1 准备风险管理SP1.1确定风险来源和类别 SP1.2定义风险参数 SP1.3建立风险管理战略SG2 识别和分析风险SP2.1识别风险 SP2.2对风险进行评价、分类和排列优先顺序SG3 缓解风险SP3.1拟订风险缓解方案 SP3.2实施风险缓解6、定量项目管理(QPM)SG1定量管理项目SP1.1建立项目目标 SP1.2组成已定义过程 SP1.3选择将予以管理的子过程 SP1.4管理项目性能SG2对子过程进行统计管理SP2.1选择度量值和分析技术 SP2.2运用统计方法,以掌握变化情况 SP2.3监督所选择的子过程的性能 SP2.4记录统计管理数据二、工程类1、需求管理(RM)2、需求开发(RD)3、技术解决(TS)SG1 选择产品构建解决方案SP1.1开发详细候选解决方案和选择准则 SP1.2开发操作概念和场景 SP1.3选择产品构件解决方案SG2 设计SP2.1运用有效的设计方法 SP2.2建立完备的技术数据包 SP2.3设计综合性接口 SP2.4进行制作、购买或复用分析SG3 实现产品设计SP3.1实现设计 SP3.2编制产品支持文档4、产品集成(PI)SG1 准备产品集成SP1.1建立产品集成战略 SP1.2建立产品集成环境 SP1.3规定详细的产品集成规程SG2 确保接口兼容性SP2.1审查接口描述的完备性 SP2.2管理接口SG3 组装产品构件和交付产品SP3.1确认集成用的产品构件已经准备就绪 SP3.2组装产品构件 SP3.3核查组装的产品构件 SP3.4打包和交付产品或产品构件5、验证(VER)6、确认(VAL)三、组织过程类:1、组织过程定义(OPD)SG1 建立组织过程资产SP1.1建立标准过程 SP1.2 建立生命周期模型描述 SP1.3建立裁剪准则及指南 SP1.4建立组织度量库 SP1.5建立组织过程资产库 SP1.6建立工作环境标准SG2 促成IPPD管理SP2.1建立授权机制 SP2.2建立集成团队规则与指南 SP2.3平衡团队与原隶属组织的责任2、组织过程聚焦(OPF)SG1 确定过程改进机会SP1.1确定组织的过程需求 SP1.2评估组织的过程 SP1.3识别组织的过程改进项目SG2 策划和实施过程改进活动SP2.1制定过程行动计划 SP2.2实施过程行动计划 SP2.3部署过程和相关的过程财富 SP2.4把过程相关的经验纳入本组织的过程财富3、组织培训(OT)SG1 确定培训需求并且使培训现成可用SP1.1 确定战略培训需求 SP1.2确定有哪些培训需求由组织负责满足 SP1.3 建立组织培训战术计划 SP1.4建立培训能力SG2 提供必要的培训SP2.1交付培训 SP2.2建立培训记录 SP2.3评价培训效果4、组织过程性能(OPP)SG1 建立性能基线和模型SP1.1 选择过程 SP1.2建立过程性能度量值 SP1.3建立质量和过程性能目标 SP1.4建立过程性能基线 SP1.5建立过程性能模型5、组织革新与部署(OID)SG1 选择改进项目SP1.1 收集和分析改进建议 SP1.2 识别革新 SP1.3 试行改进 SP1.4 选择改进建议,用于部署SG2 部署改进SP2.1策划部署 SP2.2管理部署 SP2.3度量改进效果四、支持类1、过程和产品质量保证(PPQA)SG1 客观评价过程和工作产品SP1.1客观评价过程 SP1.2客观评价工作产品和服务SG2 客观提供情况SP2.1通报不符合问题,并且确保解决它们 SP2.2建立记录2、配置管理(CM)SG1 建立基线SP1.1识别配置项 SP1.2建立配置管理系统 SP1.3建立或放行基线SG2 跟踪并控制变更SP2.1跟踪变更 SP2.2控制变更SG3 建立完整性SP3.1建立配置管理记录 SP3.2进行配置审计3、测量和分析(MA)SG1 协调测量和分析活动SP1.1 建立测量目标 SP1.2详细说明度量值 SP1.3说明数据收集和存储规程 SP1.4规定分析规程SG2 提供度量结果SP2.1收集度量数据 SP2.2分析度量数据 SP2.3存储数据和结果 SP2.4通报分析结果4、决策分析和决定(DAR)SG1 评价候选方案SP1.1拟订并运用决策分析的指导原则 SP1.2选择评价技术 SP1.3拟订评价准则 SP1.4确定推荐的侯选方案 SP1.5评价候选方案 SP1.6选择解决方案5、原因分析和决定(CAR)SG1 确定缺陷的原因SP1.1选择缺陷数据,用于分析、选择缺陷和其他问题,以供分析使用 SP1.2分析原因SG2 处理缺陷原因SP2.1实施措施建议 SP2.2评价变更的效果 SP2.3记录数据。
CMMI2 KPA-需求管理
需求管理目标是在客户和根据客户要求在软件项目中定义的内容之间建立一种良好的理解。
需求管理包括就软件项目与客户之间达成和维持共识。
这种共识被称作"软件的系统需求"。
"客户"可被理解为系统工程部,市场部,另一个内部机构或外部客户.该共识同时涵盖技术和非技术(如提交日期)的需求。
这种共识形成了评估、计划、实行和跟踪软件项目活动的基础,贯穿整个软件生命周期。
系统需求在软件,硬件和其他系统元素(如人力)上的分配可能是由软件工程部之外的部门执行(如系统工程部),软件工程部可不直接控制这种分配。
在项目约束下,软件工程部采取适当的步骤确保控制和存档软件方面的系统需求。
为达到这一控制,软件工程部门在最初及修改过的软件方面的系统需求被纳入软件项目之前对其进行审核以解决问题。
无论软件方面的系统需求何时变化,都要调整受影响的软件计划、工作产品和活动以保持与更新后的需求一致。
目标目标 1 控制软件方面的系统需求,建立一个基线用于软件工程和管理。
目标 2 保持软件计划、产品和活动与软件方面的系统需求一致。
行为的责任责任 1 项目依照一个书面的组织性的原则,以管理软件方面的系统需求。
在这些实践中软件方面的系统需求被称为"分配需求"(allocated requirements).分配需求是系统需求的子集,在系统的软件部分中执行。
它是软件开发计划中的主要部分。
软件需求分析详细阐述和提炼了分配需求,结果体现为文档化的软件需求。
这一原则代表性地说明了:1.分配需求是文档化的;2.分配需求由:☐ 软件经理及其他受影响部门进行审核。
受影响部门的例子包括:☐ 系统测试软件工程(包括所有的子部门,例如软件设计)☐ 系统工程☐ 软件质量保证☐ 软件配置管理☐ 文档支持3.软件计划、工作产品和活动应随分配需求的变化而修改,以与其保持一致。
行为的能力能力1 对于每个项目而言,建立分析系统需求和将其划分到硬件、软件和其他系统元素上的责任。
CMMI过程域
CMMI过程域CMMI(Capability Maturity Model Integration)是一种用于评估和改进组织的软件工程能力的模型。
它定义了一组评估标准和最佳实践,包括了五个过程域(process area),分别是需求管理、项目管理、工程(软件)过程、配置管理和产品质量保证。
接下来,我将详细介绍这五个过程域。
1. 需求管理(Requirements Management)需求管理是指在整个软件开发过程中,对需求的分析、收集、跟踪和变更进行管理。
主要活动包括需求识别、需求分析和建模、需求验证和确认以及需求变更管理。
需求管理的目标是明确项目的需求,确保需求的准确性和可追溯性,以及及时有效地处理需求变更。
通过有效的需求管理,可以实现项目的高效开发和产品的质量保证。
2. 项目管理(Project Management)项目管理是指对软件开发项目进行计划、组织、指导和控制,以实现项目目标的过程。
主要活动包括项目计划制定、资源分配和调度、进度控制和风险管理。
项目管理的目标是确保项目按时、按质量要求完成,最大程度地满足客户需求。
通过有效的项目管理,可以提高项目的可预测性和控制性,减少项目风险,并提高项目团队的合作效率。
3. 工程(软件)过程(Engineering Process)工程过程是指在软件开发过程中,进行软件需求分析、设计、编码、测试和维护的一系列工作。
主要活动包括软件需求分析、软件构架设计、编码和单元测试、集成测试和系统测试以及软件维护。
工程过程的目标是确保软件开发过程高效、规范和可靠,以达到预期的质量和性能要求。
通过有效的工程过程,可以提高软件开发效率,减少错误和缺陷,提高软件的可维护性和可靠性。
4. 配置管理(Configuration Management)配置管理是指对软件产品配置项进行识别、控制、记录和审计的过程。
主要活动包括配置项识别和建立配置管理库、配置项控制和跟踪变更、配置项版本管理和配置项审核。
CMMI 22个PA缩写及主要内容
CMMI 22个PA缩写及主要内容CMMI 22个PA缩写EPG:工程过程组(Engineering Process Group)MSG:管理指导组/高层管理组(Management Steering Group)SPI:软件过程改进(Software Process Improvement)PAT:过程行动组(Process Action Team)PA:过程域(Process Area)PP:项目策划(Project Planning)PMC:项目监控(Project Monitoring and Control)IPM:集成的项目管理(Integrated Project Management)RSKM:风险管理(Risk Management)CM:配置管理(Configuration Management)PPQA:过程和产品质量保证(Process and Product Quality Assurance)MA:度量和分析(Measurement and Analysis)DAR:决策分析和解决方案(Decision Analysis and Resolution)REQM:需求管理(Requirements Management)RD:需求开发(Requirements Development)TS:技术解决方案(Technical Solution)PI:产品集成(Product Integration)Ver:验证(Verification)Val:确认(Validation)OPF:组织过程焦点(Organization Process Focus)OPD:组织过程定义(Organization Process Definition)OT:组织培训(Organizational Training)22个PA的主要内容有:1.CM:(Configuration Management)软件配置管理。
2.CMMI Training for REQM
IBM Confidential
4
Requirements Management (REQM)
Assign the responsibility of Requirements Management activities in the project. (GP 2.4) Requirements Management roles (like PM) and responsibility is defined in OBS. Requirement roles and actual resource is defined in staffing plan. Requirement related owner/reviewer/approver responsibility is defined in 'Review and Approval Authorities‘ page of PDP Plan and track the trainings related to Requirements Management . What training have you attended to perform requirement management activities . (GP 2.5) Requirements management related training like requirement business training, OPAL training (including requirement management) need and training plan are included in project Training Plan with actual track. Training materials are in place. Place the work product related to Requirements management process under appropriate level of control . (GP 2.6) Configuration Management Plan defined work products related to Requirements management (like RD/ED document) as CI (Configuration Item). Data Management Plan defined the storage, access control, backup of requirements management related files like RD/ED, RTVM . Tools like PCB, teamroom etc. are used to store the Requirement Management documents. These tools are access controlled, with ACL (Access Control List).
用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所示。
获得对需求的理解。
需求接收者与需求提供者就需求达成共识。
获取项目参与者对需求的承诺。
通过书面承诺,建立各方、各项工作的基准。
管理需求变更。
维护变更历史,为调整与控制提供数据。
维护对需求的双向可追溯性。
这是从软件的可维护性角度提出的管理要求。
标识项目计划和工作产品与需求的不一致性。
旨在发现不一致性,并且启动纠正措施。
CMMI 22个PA缩写及主要内容
CMMI 22个PA缩写及主要内容CMMI 22个PA缩写EPG:工程过程组(Engineering Process Group)MSG:管理指导组/高层管理组(Management Steering Group)SPI:软件过程改进(Software Process Improvement)PAT:过程行动组(Process Action Team)PA:过程域(Process Area)PP:项目策划(Project Planning)PMC:项目监控(Project Monitoring and Control)IPM:集成的项目管理(Integrated Project Management)RSKM:风险管理(Risk Management)CM:配置管理(Configuration Management)PPQA:过程和产品质量保证(Process and Product Quality Assurance)MA:度量和分析(Measurement and Analysis)DAR:决策分析和解决方案(Decision Analysis and Resolution)REQM:需求管理(Requirements Management)RD:需求开发(Requirements Development)TS:技术解决方案(Technical Solution)PI:产品集成(Product Integration)Ver:验证(Verification)Val:确认(Validation)OPF:组织过程焦点(Organization Process Focus)OPD:组织过程定义(Organization Process Definition)OT:组织培训(Organizational Training)22个PA的主要内容有:1.CM:(Configuration Management)软件配置管理。
cmmi关于需求管理成熟度的评估方法
cmmi关于需求管理成熟度的评估方法CMMI(Capability Maturity Model Integration,能力成熟度模型集成)是软件工程领域中最常用的过程改进方法,它提供了一个标准化的框架,帮助组织评估和改善其软件开发过程的成熟度。
在CMMI 中,需求管理是软件开发过程的关键环节之一。
本文将介绍CMMI对需求管理成熟度的评估方法。
CMMI中的需求管理属于项目管理过程领域,主要包括需求发现、需求分析、需求验证和需求变更控制等活动。
需求管理的目标是确保项目团队对于项目需求的理解一致,能够满足利益相关者的期望,并能够有效地控制需求的变更。
CMMI对需求管理成熟度的评估方法主要通过对特定的指标和实践的评估来确定一个组织在需求管理方面的成熟度水平。
CMMI的需求管理过程包括5个级别,分别是初始级、被管理级、被定义级、被量化级和优化级。
首先是初始级,表明组织在需求管理方面还没有建立明确的过程,需求管理是一个不稳定且随机的过程。
在这个级别下,组织可能缺乏对需求的明确定义和分析,缺乏对需求变更的有效控制。
接下来是被管理级,标志着组织开始将需求管理作为一个可识别和可管理的过程。
在这个级别下,组织建立了基本的需求管理过程,但这些过程还没有明确定义和监控。
组织可能会使用一些基本的技术工具来帮助管理需求。
被定义级是在被管理级的基础上进一步完善需求管理过程,为管理和控制需求提供了一定的可见性和可测量性。
在这个级别下,组织已经明确定义和记录了关键的需求管理过程,包括需求定义、需求分析和需求变更控制等。
组织可能会使用一些工具和方法来帮助分析和评估需求。
被量化级是在被定义级的基础上引入了度量和度量分析的过程。
在这个级别下,组织能够收集和分析与需求相关的数据,并对需求管理过程进行量化评估。
组织可能会使用一些度量工具和技术来衡量和监控需求的执行情况。
最后是优化级,标志着组织已经形成了连续改进的需求管理过程。
在这个级别下,组织能够通过收集和分析实际需求执行结果的数据,并根据这些数据进行持续的改进和优化。
CMMI基础知识2-2和3级
项目计划(Project Planning)(PP)
Project Planning的目的:
建立和维护计划,计划规定了项目需要做 的活动。
那么,需要做到怎样的程度,才算把 PP做好考虑,发表一下?
4
1.基础工作
1. 2. 3. 4.
分解项目任务,做WBS 列出工作产品和工作任务 考虑采用怎样的软件开发生命周期 确定工作量、费用等
8
2级特点小结
软件开发的一些细节没有定义:如需求 开发、设计、编码、测试 全部的PA都是针对项目这一级的,没 有组织级的PA。
9
2级和我们的水平比较
我们完全达到了2级的水平! 大家充分理解了2级所需要做的各项工 作!
10
3级的特点
项目管理水平升级 细化了软件工程的各个环节 增加了决策流程 加入了组织级方面的要求
27
组织级方面的要求
组织过程聚焦(Organizational Process Focus)(OPF) 组织过程定义(Organizational Process Definition)(OPD) 组织培训(Organizational Training)
28
3级小结-1
项目管理水平升级
这类工作,就是要满足项目计划的第一个目 标(Goal):建立评估(Establish Estimates) 而以上每一项,就是一个实践(Practice)
5
2.写计划
1. 2. 3.
4.
5. 6. 7.
建立预算和进度 识别项目风险 计划好如何管理各类文档、代码等 计划好软硬件资源 计划好需要哪些培训或者技术支援 计划好与用户、外单位的交涉 把以上内容文档化 这是项目计划的第二个Goal:开发一个项目 计划(Develop a Project Plan)
REQM_需求管理
常见提问: 常见提问: 1、通过什么方式取得承诺,如何证明相关人员的承诺记录? 、通过什么方式取得承诺,如何证明相关人员的承诺记录? 2、什么人参加需求的评审? 、什么人参加需求的评审?
SP 1.3 Manage Requirements Changes; Manage changes to the requirements as they evolve during the project. 管理需求变更;当需求在项目执行期间逐渐开发时,管理需求的变更。 管理需求变更;当需求在项目执行期间逐渐开发时,管理需求的变更。 Typical Work Products典型的工作产品 典型的工作产品 1.Requirements status 1.需求状态表 需求状态表 2.Requirements database 2.需求数据库 需求数据库 3.Requirements decision database 3.需求决策数据库 需求决策数据库
常见提问: 常见提问: 1、通过什么方式管理需求变更?变更记录包括哪些内容?如何追踪并更新需求状 、通过什么方式管理需求变更?变更记录包括哪些内容? 态? 2、需求变更前后记录如何区分体现? 、需求变更前后记录如何区分体现? 3、需求变更申请后,通过什么方式决定是否变更需求 如何记录追溯。 如何记录追溯。 、需求变更申请后,通过什么方式决定是否变更需求?如何记录追溯
常见提问: 常见提问: 1、双向跟踪表模式是怎样的?包括哪些产品之间的追踪?包括哪些具体内容? 、双向跟踪表模式是怎样的?包括哪些产品之间的追踪?包括哪些具体内容?
SP 1.5 Identify Inconsistencies between Project Work and Requirements; Identify inconsistencies between the project plans and work products and the requirements. 识别项目工作与需求间的差异;识别需求与项目计划和工作产品间的差异。 识别项目工作与需求间的差异;识别需求与项目计划和工作产品间的差异。 Typical Work Products典型的工作产品 典型的工作产品 1.Documentation of inconsistencies including sources, conditions, and rationale. 1.差异纪录,包括差异来源、条件及理由。 差异纪录, 差异纪录 包括差异来源、条件及理由。 2.Corrective actions 2.纠正措施 纠正措施 常见提问: 常见提问: 1、通过什么方式来识别差异?结果如何管理?有差异的时候通过什么方式跟踪? 、通过什么方式来识别差异?结果如何管理?有差异的时候通过什么方式跟踪? 差异内容如何处理? 差异内容如何处理?
cmmi 需求管理过程
cmmi 需求管理过程CMMI需求管理过程CMMI(Capability Maturity Model Integration)是一种用于评估和改进组织的过程能力的模型。
在软件开发领域,CMMI被广泛应用于提高组织的软件开发过程的效率和质量。
需求管理是CMMI 模型中的一个重要过程领域,本文将重点介绍CMMI需求管理过程。
需求管理是指在软件开发过程中,对需求进行全面的管理和控制,确保开发出符合用户需求的软件产品。
CMMI需求管理过程旨在帮助组织建立有效的需求管理机制,确保需求的准确性、一致性和可追踪性,最大程度地满足用户的期望。
CMMI需求管理过程包括以下几个主要活动:1. 需求收集和分析:在这个阶段,需求工程师与用户和相关利益相关者密切合作,收集和分析用户需求。
通过面对面的讨论、问卷调查等方式,确保对需求的全面理解和准确把握。
2. 需求规格说明:在这个阶段,需求工程师将需求转化为详细的需求规格说明。
需求规格说明应包括功能需求、性能需求、可靠性需求等方面的内容,并且应符合CMMI模型的要求,如清晰、可测量、可追踪等。
3. 需求验证和确认:在这个阶段,需求工程师与用户一起对需求进行验证和确认。
通过原型演示、评审会议等方式,确保需求的正确性和完整性。
同时,也要确保需求与用户的期望一致,并及时处理用户的反馈和变更请求。
4. 需求变更控制:在软件开发过程中,需求往往会发生变化。
需求变更控制是指对需求变更进行管理和控制,确保变更的合理性和影响的可控性。
需求变更控制包括需求变更评估、变更影响分析、变更批准等环节,以确保变更的有效性和可追溯性。
5. 需求跟踪和配置管理:需求跟踪是指对需求进行追踪和管理,确保需求的可追溯性和一致性。
配置管理是指对需求文档和相关文档进行版本控制和变更管理,以确保需求的正确性和完整性。
需求跟踪和配置管理是CMMI需求管理过程中非常重要的环节,对于确保需求的有效性和可控性具有重要作用。
1 CMMI L2 REQM(需求管理)
CMMI L2 REQM需求管理过程域赛柏科技n初始级o 已管理级p 已定义级r 优化级n 初始级已管理级p 已定义级q 定量管理级主题I 需求开发与需求管理II REQM的SG和SPsIII REQM的GGs和GPsIV 需求管理示例V 小结VI 参考材料#已管理级的特点•特点是:项目级。
建立了基本的项目管理过程来跟踪成本、进度和功能特性,制定了必要的过程纪律,能重复早先类似项目取得的成功。
•项目过程得到计划和执行,并遵循相应的方针•提供了适当的资源来执行过程,并分配了执行过程的职责•对执行过程的人进行培训•过程的工作产品得到了管理和控制•过程本身得到了监督、控制和评审,并得到了客观评价#过程域图示表示法II #需求开发和需求管理需求相关活动需求开发需求管理需求调研需求分析需求定义需求确定管理需求实现管理需求变更管理#需求开发的目的#客户、产品及产品构件的需求-1#客户、产品及产品构件的需求-2#需求开发语境图确认后的客户需求产品需求需求需求管理的目的需求要控制•将需求交给开发组之前,必须对需求进行评审并解决发现的问题•所有需求要文档化并且受到控制•所有相关的计划、活动及其它与生命周期相关的工作产品要与需求保持一致•在整个产品开发过程中,建立并维护可跟踪性#需求管理过程#需求管理过程的流程图#需求管理过程流示例需求是构建系统的基础•构建任何系统,都是基于我们与客户共同确认的最小需求,对于用户的需求了解得越是确切,需求的稳定性就越高。
解决方案的不断演化,就是不断满足客户需求的过程(需求基线/变更)•对于大型系统,系统设计应从客户问题的专门知识入手,通过不断提炼的系统设计和软件设计,逐步增强对客户问题及相关知识的理解(需求确认)•如果上层设计选择正确,则很多低层设计将不会影响需求。
当然,需求问题可能在任何开发阶段出现,此时必须在需求层次上恰当地解决,不能只是在设计或编码上修补了事(追溯性)需求管理的基本任务•项目要采取适当的步骤来确保管理已得到批准的需求集,以便支持项目的计划和执行的需要–获得对需求的理解:从被认可的需求提供者收集需求,并与他们共同评审,以便在将需求纳入项目计划之前,解决不明确的问题并排除误解–获得对需求的承诺:一旦需求提供者和需求接收者达成了协议,从项目参与者获得对需求的承诺–管理需求变更:随着项目进展,当计划、工作产品和需求之间出现不一致时,项目经理要更改需求或更改计划–维持需求的双向可跟踪性:需求管理要将需求的变更及其变更的理由文档化,并维持源需求与所有产品和产品构件的需求之间的双向可跟踪性#有哪几类需求?•功能需求•性能需求•界面需求•接口需求•资源需求(管理方面的需求)•潜在需求(potential requirements)等#Requirements与Specification?•生命周期分若干个阶段,每个阶段的输出是下一阶段的Requirements,每个阶段的输出是该阶段的Specification •看Specification是否满足Requirements:称Verification •看每个阶段的输出是否满足最初的输入:称Validation •对第一阶段来讲:Verification也叫Validation•每个阶段既要进行Verification,也要进行Validation需求的双向可跟踪性-1•没有需求的可跟踪性,就不能有效地管理需求•一个需求是可跟踪的,其条件是当且仅当:–知道每个需求的源–知道为什么需要这个需求–知道哪些需求与它相关–知道需求如何与其它信息(如系统设计、实现及用户文档等)相关•可跟踪信息可用于发现哪些需求可能会受到需求变更的影响需求的双向可跟踪性-2•如果在系统实现过程中提出需求变更,应考虑以下情况:–变更对需求、系统设计及其实现影响的程度•如果在系统运行后提出需求变更,还应考虑以下情况:–该系统中有多少利益相关者受到此变更的影响需求的双向可跟踪性-3•在整个产品生命周期中,要捕捉所有需求和需求变更请求,并将他们放在配置管理之下(需求库)•在对项目计划、活动及工作产品执行需求变更请求的影响进行分析时,需求应该是可跟踪的(每项需求有唯一的标识符)•要生成一个需求跟踪矩阵,并可用于向前和向后的(双向)跟踪#需求跟踪矩阵•需求跟踪矩阵用于在各个生命周期阶段跟踪所有需求,确保每一项需求可以跟踪到实现该需求的设计、编码以及测试实现的测试用例•需求跟跟矩阵建立了从需求单元到设计单元、从设计单元到编码单元、从编码单元到测试用例的映射•通过跟踪,可以验证软件是否实现了所有需求以及软件是否对所有需求进行过测试,还可以在需求变更时分析变更带来的影响#前向跟踪和反向跟踪•存在两种类型的跟踪:–前向跟踪–后向跟踪•前向跟踪意味着看需求是否在生命周期的后期阶段(如设计和编码阶段)的输出元素中得到体现•后向跟踪则相反,它意味着后期各个阶段的输出元素满足何种需求。
CMMI 标准学习需求管理(REQM)解读
Validation (VAL)-确信
REQM
Requirements
Product and product component requirements Alternative solutions
Product components
Product
RD
TS
Requirements work products, validation reports
GP1.1 完成特定实践
执行需求管理过程的特定实践,为达成过程域的特定目 标而开发工作产品和提供服务。
把该过程制度化为已管理的过程
建立并组护一个组织级的方针用于计划和执行需 求管理过程。
该方针建立组织对以下活动的期望,收集干系人的需 求,阐述产品和产品组件的需求,以及分析和确认需 求
详细说明:
SG详解
管理需求并识别项目计划和工作产品之间的差 异
通过下面实践来保证在项目整个生命周期中有一组经核 实的最新需求:
管理所有变更需求 维护需求,项目计划,工作产品之间的关系 识别需求,项目计划,工作产品之间的差异 采取纠正措施
和需求提供者一起开发理解需求的含义 当项目成熟或者需求产生后,所有活动都要接受需求,为避免需求突然 产生,要建立准则以指导获取需求的正式渠道和适当来源。
子实践:
1. 评估对现有承诺的影响 当需求变更或新需求时,要评估对项目成员的影响 2. 协商并记录承诺 在项目成员对需求和需求变更承诺前必须对现有承诺进行 协商
在项目开发中,管理需求变更
进行有效的变更影响分析,必须知道需求的来源,并记录变 更的原因。然而项目经理或许要追踪变更程度以判断是否需 要新建或修改变更控制。 典型工作产品: 需求状态表 需求数据库 需求决策数据库
CMMI-REQM需求管理
© 1995-2004 Soft Tech Development, Inc. All rights reserved. 199513
一个字处理程序的例子
业务需求可能是:“用户能有效地纠正文档中的拼写 错误”,该产品的包装盒封面上可能会标明这是个满 足业务需求的拼写检查器。 而对应的用户需求可能是“找出文档中的拼写错误并 通过一个提供的替换项列表来供选择替换拼错的词”。 同时,该拼写检查器还有许多功能需求,如找到并 高亮度提示错词的操作;显示提供替换词的对话框 以及实现整个文档范围的替换。
用户
以某种方式使用系统,因此必须从实际使用的观点理解系 统的任何项目有关人员。
客户不一定是用户。
© 1995-2004 Soft Tech Development, Inc. All rights reserved. 199511
需求的层次
软件项目管理中的有关需求管理共性问题
目标被误解 定义很差的需求 没有充分的技能或资源 通信效率低下 缺少变更控制 缺少足够的文档
© 1995-2004 Soft Tech Development, Inc. All rights3 reserved. 1995-
© 1995-2004 Soft Tech Development, Inc. All rights7 reserved. 1995-
名言
开发软件系统最困难的部分就是准确说明 开发什么。最困难的概念性工作是编写出 详细的需求,包括所有面向用户、面向机 器和其它软件系统的接口。此工作一旦做 错,将会给系统带来极大的损害,并且以 后对它修改也极为困难。
© 1995-2004 Soft Tech Development, Inc. All rights9 reserved. 1995-
CMMI需求管理规范
CMMI需求管理规范目录一.概述 (3)二.需求管理的基本活动 (3)1、需求提出 (3)2、需求分析及评审 (3)3、需求计划定制及跟踪 (3)4、需求变更控制 (3)5、需求制度建立及其优化 (4)6、需求成本控制 (4)三.项目实践过程示例 (4)1 、建立需求管理制度 (4)2、需求接收及其分析 (5)3、需求评审 (5)4、需求计划定制及跟踪 (5)5、需求开发及更新过程 (5)6、需求变更 (5)7、团队培训 (5)8、过程改进 (6)一.概述项目需求管理(Requirements Management, REQM)的目的,在于管理项目产品及产品组件的需求,并界定这些需求与项目计划及工作产品间的差异。
项目实行适当的步骤,确保议定的需求是受管理的,以支持项目策划和执行的需要。
需求管理也须记录需求变更及其理由,并维护原始需求与所有产品和产品组件需求的间的双向追溯性。
从实践意义上讲,需求是针对客户各类需求经双方(或多方)沟通确认后形成的一种协议,协议的范围是明确的、可控的。
在协议签订后,需求的计划有定制、进度有跟踪、结果有度量。
针对需求的变化,需要明确需求变化的原因及变更内容。
需求的紧急程度及严重程度可评估,以确定需求及其变更的优先级,从而排定切实可行的需求计划。
下面我们就如下几个方面对需求管理体系进行分析、研究:1,需求的管理的基本活动2,结合当前项目简述需求管理实践中的问题、解决方案(结合7命题)。
二.需求管理的基本活动在需求管理过程中,包含如下关键活动:1、需求提出针对客户的需求提出,开发方进入需求了解环节。
需求了解采用访谈、文档、多方会议等形式采集基础信息,在此基础上结合系统原型进行差异化分析。
2、需求分析及评审需求分析中,针对需求、系统差异进行差异记录并制定相应的矫正方案。
3、需求计划定制及跟踪需求计划的定制以用户、开发团队、计划跟踪者协商一致的结果为依据。
其过程实质是取得用户对于进度的认可、取得团队对于进度的承诺。
项目管理之REQM需求管理
需求工程
需求开发,关注
需求的引出、收集、分析,以及客户需求的分配、从 客户需求向产品需求的转化
需求管理,关注
对已建立和分配的需求的管理和跟踪
2008-3-4 2
中国科学院软件研究所
Institute of Software,Chinese Academy of Sciences
2008-3-4 13
中国科学院软件研究所
Institute of Software,Chinese Academy of Sciences
SP 1.4 维护需求的双向跟踪性
维护需求、工作产品和项目计划之间 的双向跟踪关系
1. 维护需求的跟踪性,确保需求源头的文档化 2. 跟踪需求和导出需求的对应关系,以及与功能、 对象、人员、过程和工作产品之间的跟踪关系 3. 生成需求跟踪矩阵
中国科学院软件研究所
Institute of Software,Chinese Academy of Sciences
工程过程域
REQM
需求
产品和产品构件需求
可选择的方案
RD
需求
TS
产品构件
PI
产品
客户
产品构件, 工作产品, 验证 和 确认报告
VER
VAL
客户需求 2008-3-4 1
中国科学院软件研究所
中国科学院软件研究所
Institute of Software,Chinese Academy of Sciences
SP 1.2 获取对需求的承诺
从项目参与方获取对需求的承诺
⌧随着项目的进展会收到新需求,承诺意味着当需求 变更时对项目的计划变更、增加的活动也应作出相 应的承诺
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
CMMI2 PA之需求管理(REQM)
人是会死的,需求是会变的。
相信大家都经历了很多需求变更的痛苦,项目被拖延,成本高涨,十有七八是需求管理(REQM)没有做好导致的。
有哪一些需求管理方面的常见问题呢,这里列举一下:
1.因为项目进度赶等原因,在很多需求还没有明确情况下,便开始开发的工作。
2.开始客户只能提出模糊的需求,客户喜欢先让你做个东西给他看,然后他才可能逐渐提出真正的需求,而需求调研人员,对此没有什么好的处理办法。
3.客户以种种原因不签需求,项目组在不签需求的情况下,便开始开发工作。
4.客户不承认之前提出来的需求,项目组又不能得失客户,项目成员苦不堪言。
5.需求经常变化,无法控制。
6.设计、代码与需求不对应,特别是需求变更时,不知道应该修改哪部分,也不知道会有哪些影响。
......
这方面的问题可真是“罄竹难书”了,需求管理这个PA提供了能解决以上大部分问题的最佳实践。
RM(Requirements Management)只有一个Specific Goals:Manage Requirements Requirements are managed and inconsistencies with project plans and work products are identified.
中文大意是:
管理需求(REQM)并且识别出需求与项目计划、工作产品不一致的地方。
这句话有两层意思:
1.需求要被管理,被管理的意思又有两层:一是需求要被确认,二是要控制需求变更
2.需求要用来指导下游的工作产品,如:计划、设计、测试等
下面简单介绍一下这个Specific Goals下的5个Specific Practice:
第一个SP是:理解需求。
开发者应该理解客户的需求,如果这点做不到,后面的工作是没有意义的。
所以,那种在没有理解需求的情况下,就仓促开发的做法是不合适的。
当然,如果想通过做原型来获取需求不在此列,另外,大家也千万不要误解,在没有完全理解需求前一定不能开展开发工作,如果部分需求已经掌握,有部分需求还没有掌握,那也是可以先开展已掌握部分需求的设计、编码工作的,这时需要考虑没有确定部分的需求对这些工作可能带来的影响。
这个SP的英文原文是:Develop an understanding with the requirements providers on the meaning of the requirements.
第二个SP是:确认需求,就是要和客户签署需求。
我想大家都非常理解这点的重要性,但大家可能会说,说得容易,客户就是不签,咋办?客户不签需求,主要是两方面的原因:
1)客户不确定需求。
2)客户担心签了需求后,他就不好变了。
对于原因一,解决办法就是大家需要把SP1理解需求做好,如何把需求理解做好,更详细的内容可以参考3级的需求开发(RD),这里先不详细解说。
对于原因二,要消除客户的顾虑,首先签署需求不是单方面的约束,其实也是对开发方的约束,就是说我们要承诺做出这样的一个东西,如果做不出来,客户可以追究我们的责任,另外一个方面,要跟客户说清楚,需求是可以变的,现在签署只是标志着当前的一个工作里程碑,当前签订的需求,是我们后续工作的一个基准。
大家可能又会问如果只能确定一部分需求,客户还是不愿意签,咋办?那就先签确定部分的需求呗!
这个SP的英文原文是:Obtain commitment to the requirements from the project participants.
第三个SP是:管理需求变更。
需求不是不可以变,只不过需要管理。
客户今天说改这,明天改那,后天又不算
数,咋办?怎样才算管理需求变更呢?
1.要充分理解客户提出来的需求变更,深究其原因,不能客户一说变就变,超过一半的客户变更要求,其实都是不合理的,或者是有其它更好的替代办法的。
2.客户提出来的变更要求,要书面记录,并让客户确认,和客户讨论需求变更过程来往的邮件要保存好,和客户面谈、聊电话后,要发邮件总结当此会谈达成的要点共识,总之就是要有书面记录。
3.客户提出来的需求变更,要分析所有的影响,包括增加多少的工作量,需要修改或者增加哪些设计文档代码等,可能会引发什么风险等。
所有这些要列出清单,反馈给客户,让客户确认。
4.如果需求变更导致项目成本和进度变化太大,超出可承受范围,则需要高层领导出面,和客户协商调整费用。
这个SP的英文原文是:Manage changes to the requirements as they evolve during the project.
第四个SP是:维护需求的双向跟踪。
需求是用来指导后续工作的,所以需求与计划、设计、编码、测试等后续工作都需要维护好对应的关系,这个工作与第三个SP是关系密切的,如果这个关系没有维护好,那么SP1.3也不可能做好。
这样是不是双向跟踪就能做好呢?不是,双向跟踪的意思不是由A能找到B,由B又能找到A就叫双向跟踪。
双向跟踪是只纵向和横向跟踪,前面提到的只是纵向跟踪,纵向跟踪的意思是上下游工作产品之间的跟踪关系。
而横向跟踪指的是需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等。
其中一个需求变化了,有可能影响另外一些需求,其中一个设计变了也可能影响另外一些设计。
所以,这个双向跟踪网络,将会是一个很强的网络,任何一点发生变化,能找出全部受牵连的地方。
这个SP的英文原文是:Maintain bidirectional traceability among the requirements and the project plans and work products.
第五个SP是:识别出需求与下游工作产品不一致的地方。
这里有两层意思:
1.需求变更时,利用双向跟踪表找出需要修改的地方,并用跟踪表来发现不一致的地方并调整。
2.编写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品的时候,要注意要与需求保持一致。
这个SP的英文原文是:Identify inconsistencies between the project plans and work products and the requirements.。