CMMI-项目管理过程域

合集下载

CMMI_过程域_简述

CMMI_过程域_简述

CMMI过程域介绍明确你如果要做一个产品开发,你首先要理解你要做的事,就是要做好需求开发(RD),又由于产品的需求经常会变,所以你要做好需求管理(REQM);你知道你要做什么事了,做这个事其实是一个项目,你要考虑如何管理,才能保质保量的实现需求,所以你需要做好项目计划(PP),根据计划做好项目监督和控制(PMC),项目如果需要采购,要做好供应商管理(SAM),项目都会有风险,所以要做好风险管理(RSKM),如果产品是集成产品,需要多个部门,甚至多个公司合作,就要做好集成团队管理(IT)、做好集成项目管理(IPM)、做好集成供应商的管理(ISM)。

如果可能,做到精细化管理就更好,这就是怎样做好定量项目管理(QPM)。

你知道要做什么了,你也知道怎么去管理了,你还需要有一定的环境支持,需要做好集成组织环境(OEI),你需要做好配置管理(CM),免得版本出错,工作中难免有遗漏、有人会不按规范做事,你需要做过程和产品质量保证(PPQA),产品开发中碰到问题,如何进行决策分析和解决方案(DAR)。

现在万事具备,你要考虑的是怎么做你的产品,就是怎么实现这些需求,你需要做好技术解决方案(TS),也就是产品的设计和实现,如果是集成产品,你要考虑怎样产品集成(PI),做出来后你需要知道实现的是否和设计的相一致,是否能满足需求,所以必须做好验证(VER)和确认(VAL)。

一个产品开发做好了,但公司一定不会仅仅是一个产品,会要做很多产品,要进行经验总结、吸取经验教训,进行改进提高,因此你需要在做产品开发的同时做好度量和分析(M&A),以了解公司产品开发的效率或其它信息,为其它产品计划做依据。

公司需要考虑公司哪些方面需要改进,组织过程核心(OPF),怎样改进,组织过程定义(OPD),过程出来后,人员水平也要提高,要考虑如何进行组织培训(OT)。

公司要做得更好,需要经常评估公司的过程是否合理,组织过程绩效(OPP),不合理就需要创新改进,那么如何组织创新和实施(OID)。

CMMI模型的级别及其过程域

CMMI模型的级别及其过程域

模型规范级别及其过程域成熟度1级:初始级①软件过程的特点是无序的,偶尔甚至是混乱的。

几乎没有什么过程是经过定义的,成功依赖于个人的努力;②一般不提供开发和维护软件的稳定环境,在危机时刻,项目一般抛弃预定的规程,回复到仅做编码和测试,性能依赖于个人的能力,且随个人固有的技能、知识和动机的不同而变化。

成熟度2级:受管理级①在成熟度等级2上,意味着组织要确保策划、文档化、执行、监督和控制项目级的过程;②为过程建立明确的目标,并能实现所确定的诸如成本、进度和质量目标等目标。

③换言之,组织已经营造出稳定的、受控的开发环境,项目是在受控状态下运行。

受管理级过程域•需求管理(REQM)•项目策划(PP)•项目监督与控制(PMC)•供方协定管理(SAM)•测量和分析(MA)•过程和产品质量保证(PPQA)•配置管理(CM)成熟度3级:已定义级在成熟度等级3上,项目执行过程是通过剪裁组织的标准过程集合和组织过程财富产生的“已定义过程”,并具备与该过程相适应的运行环境。

其与成熟度等级2的区别在于标准、过程描述、规程的应用范围是全组织级的。

•需求开发(RD)•技术解决(TS)•产品集成(PI)•验证(VER)•确认(V AL)•组织过程聚焦(OPF)•组织过程定义(OPD)•组织培训(OT)•集成项目管理(IPM)•风险管理(RSKM)•决策分析和决定(DAR)成熟度4级:定量管理级在成熟度等级4上,组织建立了关于产品质量、服务质量及过程性能的定量目标,运用统计技术和其他定量目标作为判断过程管理成功与否的标准。

在过程的整个生存周期里,对产品质量、服务质量和过程性能做到统计意义上的了解和管理。

•组织过程性能(OPP)•定量项目管理(QCM)成熟度5级:持续改进级成熟度等级5 的突出特征是过程性能的持续改进。

组织建立起整个组织的定量过程改进目标,并且把它们作为过程改进管理成功与否的判断标准;这些目标将适时修改,以反映不断变化的本组织的业务目标。

cmmi整体框架和重点过程域解释

cmmi整体框架和重点过程域解释

组织级过程定义(OPD)
成熟度3级过程管理类过程域
• 组织级过程定义(Organizational Process Definition, OPD)的目的在于建立并维护一套可用的组织级过程资产、 工作环境标准以及团队规则与指南。
• 组织级过程资产使得整个组织具有一致的过程执行,并且为组织提供 一个累积的、长期收益的基础。 • 组织的过程资产库通过让整个组织内共享最佳实践与经验教训来支持 组织级学习与过程改进。 • 组织的标准过程集也描述与供方之间标准的交互。供方交互由下面典 型的事项所描述:期望供方提供的交付物、适用于那些交付物的验收 准则、标准(例如,架构与技术标准),以及标准里程碑与进展评审。
“度量与分析”过程域涉及以下活动: • 明确说明度量与分析的目标,使其与所识别的信息需要及项目、 组织级或业务目标协调一致 • 明确说明度量项、分析技术以及数据收集、数据存储、报告与反 馈的机制 • 实施分析技术以及数据收集、数据报告与反馈的机制 • 提供客观的结果,这些结果可用于做出有根据的决策以及采取适 当的纠正措施
组织级培训(OT)
成熟度3级过程管理类过程域
• 组织级培训(Organizational Training,OT)的目的在于发展 人员的技能与知识,使其能够有效且高效地执行他们的角色。
• “组织级培训”涉及用于支持组织战略业务目标的培训,并满足跨项目、 跨支持组的通用战术培训需要。由个别项目与支持组识别的、用以满足 其特定需要的培训在项目与支持组层面进行处理,处于“组织级培训” 过程域的范围之外。 组织级培训项目包括以下活动: • 识别组织所需要的培训 • 获得并提供培训,以解决已识别的培训需要 • 建立并维护培训能力 • 建立并维护培训记录 • 评估培训有效性

CMMI的22个过程域及其特定目标和实践

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记录数据。

CMMI过程域一览表

CMMI过程域一览表

CMMI过程域一览表CMMI-DEV 1.2过程域一览表CMMI-DEV 1.2的22个过程域CMMI等级2级 2级 2级 2级 2级 2级中文名称需求管理项目规划项目监控供应商协议管理度量分析过程和产品质量保证英文名称Requirements Management Project PlanningProject Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance2级 3级 3级 3级 3级 3级 3级 3级 3级 3级 3级 3级 4级配置管理需求开发技术方案产品集成验证确认组织过程焦点组织过程定义组织培训集成化项目管理风险管理决策分析与解决方案组织过程绩效Configuration Management Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational TrainingIntegrated Project Management Risk ManagementDecision Analysis and Resolution Organizational Process Performance4级 5级定量项目管理组织革新与部署Quantitative Project Management Organizational Innovation and Deployment5级原因分析与解决方案Causal Analysis and ResolutionCAR支持QPM OID项目管理过程管理CM RD TS PI VER VAL OPF OPD OT IPM RSKM DAR OPP支持工程工程工程工程工程过程管理过程管理过程管理项目管理工程支持过程管理缩写 REQM PP PMC SAM MA PPQA过程类型工程项目管理项目管理项目管理支持支持。

cmmi整体框架和过程域解释讲解

cmmi整体框架和过程域解释讲解

• 2. 阶段式:
• 把CMMI 中的若干个过程区域分成了5 个成熟度级别,帮 助实施CMMI 的组织建议一条比较容易实现的过程改进发 展道路。
连续式与阶段式表现形式
CMMI模型(连续式表达)
• 成熟度等级
CMMI(连续式表达) - 过程能力
• • • • • • 5 4 3 2 1 0 优化级 已定量管理级 已定义级 已管理级 已执行级 不完整级
能力等级 成熟度等级1
2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 5 5
成熟度等级2
成熟度等级3
目标概览2
目标概览3
目标概览4 目标概览5
CMMI重点过程域解释
配置管理(CM)
成熟度2级支持类过程域
• 配置管理(Configuration Management,CM)的目 的在于使用配置识别、配置控制、配置状态记录与报告以 及配置审计,来建立并维护工作产品的完整性。
“度量与分析”过程域涉及以下活动: • 明确说明度量与分析的目标,使其与所识别的信息需要及项目、 组织级或业务目标协调一致 • 明确说明度量项、分析技术以及数据收集、数据存储、报告与反 馈的机制 • 实施分析技术以及数据收集、数据报告与反馈的机制 • 提供客观的结果,这些结果可用于做出有根据的决策以及采取适 当的纠正措施
CMMI-软件能力成熟度集成 模型 整体框架和重点过程域解释
CMMI是什么?
• CMMI: Capability Maturity Model Integration(能力 成熟度模型集成)
CMMI的关注点
CMMI三要素:人、技术、过程 CMMI关注的是过程,也就是管理
三要素相互影响,过程的改进会持续会持续从正面影响人和资 源,人的士气和能力持续提高,资源被最合理最优化的配置。

CMMI3级过程域

CMMI3级过程域

CMMI3级过程域CMMI3级是CMMI(Capability Maturity Model Integration,能力成熟度模型集成)的一个等级,它代表了一个组织在其软件开发和管理过程方面的成熟度水平。

CMMI3级要求组织在战略规划、项目管理和工程实践等方面都进行了规划和实施,并能够通过度量和分析来改进其过程。

本文将针对CMMI3级中的过程域(PA)进行详细介绍。

1. Requirements Development (RD) —需求开发需求开发是指定义和收集项目所需的功能和约束条件,并确保其正确性、准确性和一致性的过程。

这个过程域包括需求的获取、分析、规范和验证等活动。

在CMMI3级中,组织需要建立适当的需求开发过程,确保需求的完整性和明确性,同时也要进行需求的管理和变更控制。

2. Technical Solution (TS) —技术解决方案技术解决方案是指开发和维护软件的过程,包括软件架构设计、详细设计、编码和单元测试等活动。

在CMMI3级中,组织需要确保对技术解决方案进行详细规划和实施,包括选择合适的架构和技术,检查和审查设计和代码等。

同时,组织也需要建立和执行软件配置管理和版本控制等活动。

3. Product Integration (PI) —产品集成产品集成是指将不同的软件构件组合起来,并进行验证和部署的过程。

在CMMI3级中,组织需要建立适当的产品集成过程,确保集成的正确性和稳定性,同时也要进行集成测试和验证。

组织还需要建立相应的配置管理和版本控制机制,确保产品集成的可控性和可追溯性。

4. Verification (VER) —验证验证是指在软件开发过程中对产品的需求进行确认和验证的过程。

在CMMI3级中,组织需要建立适当的验证过程,包括验证计划的制定、验证活动的执行和验证结果的分析。

验证活动可以包括软件测试、代码审查、功能验证等,以确保开发的产品符合需求和规范。

5. Validation (VAL) —验证确认验证确认是指在软件开发过程结束后对最终产品进行确认和验证的过程。

CMMI的5个级别和25个过程域

CMMI的5个级别和25个过程域

CMMI的5个级别和25个过程域CMMI (Capability Maturity Model Integration)是一个结构化的过程改进方法,用于评估和提升组织的软件工程能力。

CMMI分为五个不同的成熟度级别,每个级别都有一组相关的过程域。

本文将详细介绍CMMI的五个级别和25个过程域。

1. 初始级别 (Level 1 - Initial)初始级别指的是一个组织在软件开发方面缺乏组织化和预测性的过程。

在这个级别上,软件开发过程通常是不可控制的,且无法重复使用。

这意味着项目结果无法预测和控制,导致成本和进度的不确定性。

2. 执行级别 (Level 2 - Managed)执行级别指的是一个组织开始建立和管理自己的软件开发过程。

在这个级别上,组织已经建立了一些基本的软件开发过程,并能够在不同的项目中重复使用这些过程。

然而,这些过程还没有得到完全的规范和标准化。

2.1 需求管理 (Requirements Management)需求管理是确保正确、一致和可追踪需求的过程。

它涉及定义、确认和维护需求,以确保项目能够满足用户的期望。

2.2 项目计划与监控 (Project Planning and Monitoring)项目计划与监控是制定和监控项目时间表、成本和资源的过程。

它确保项目能够按计划进行,并能够做出合适的调整以达到预期的目标。

2.3 供应商协商 (Supplier Agreement Management)供应商协商是与供应商建立和维护合作关系的过程。

它确保与供应商的交付和管理能够满足项目的需求。

2.4 产品质量保证 (Product Quality Assurance)产品质量保证是确保项目交付的产品符合质量标准和用户期望的过程。

它涉及质量计划、质量审查和质量度量等活动。

2.5 配置管理 (Configuration Management)配置管理是管理项目的配置项(包括软件、硬件和文档等)的过程。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
• 需要尽早识别那些限定管理决策的因素,而这些因素往往是 我们首先应该关注的因素:例如任务工期、所需资源、输入 和输出
• 识别约束
2012-12-24
38
SP 2.1
建立预算和工期2
• 识别任务依赖关系
• 关键路径法 (CPM),项目评价与评审技术 (PERT),资源限制排序
• 确定预ቤተ መጻሕፍቲ ባይዱ和工期 • 建立纠正措施标准
• 架构特征(例如分布式或客户机服务器类型) • 新技术或成熟技术 • 最终产品功能的安全、保密和工效特征
2012-12-24
27
SP 1.2 建立工作产品和任务属性的估计2
• 2.确定估算资源需求的方法
• 使用经验证的模型或历史数据估计规模和复杂 度 • 下面是一些常用的方法:
• 集成电路设计中的逻辑门数目 • 软件中的代码行或功能点 • 系统工程中的需求个数/复杂度
2012-12-24
8
基本项目管理过程域
PMC
纠正措施 再计划 要监督什么 要开发什么 纠正措施 项目执行状态、 问题 、度量分析结果
项目执行状态、 问题,进展和里程 碑评审结果
RD, REQM
PP
任务拆分
RD,TS,PI,VER,VAL 工程和支持过程域
度量需求
计划
供应商协议
SAM
产品构件需求 技术问题 完成的产品构件 验收测试
项目定义过程和 工作环境
适合团队构成 的产品架构 协调, 承诺, 要解决的问题 执行工程过程和支持过 程的集成团队
项目定义过程 风险减缓计划 项目愿景 纠正措施 项目性能数据
工程和支持过程域
2012-12-24
基本的项目 管理过程域
10
项目策划
Project Planning
2012-12-24
11
36
SG2 开发项目计划
• • •
• •
• •
SP 2.1 SP 2.2 SP 2.3 的管理 SP 2.4 SP 2.5 技能 SP 2.6 SP 2.7
建立预算和工期 识别项目风险 计划对项目资料
计划项目资源 计划所需知识和
计划的数据 SG2 开发项目计划
建立预算和 工期 计划对项目 资料的管理 计划项目 资源
项目的要素:
• 目标、应用、技术、规模、历时 • 客户、项目组
4
2012-12-24
日常的项目行为应该是……
• 计划第一,依据计划办 事 • 事后反应 • 用事实决策 • 以感觉代替现状 • 反省和体会 • 边走边看,等待非常事 件 • 做好准备 • 靠“勇气”决断 • 观察和度量工作绩效 • 除了自己指责他人
2012-12-24
13
如果PP执行地不好……
• • • • 项目属性的估算是不准确的 从一个简陋的计划文档中难以识别到偏差 当需要的时候,资源却不可用 未来的项目不能从已结束的项目中获得经验
2012-12-24
14
特定目标
• SG 1 建立估算
• 建立和维护项目计划的估计参数
• SG 2
• SG 3
• 工作量估算
• 运算法 2012-12-24 • 专家判断法
32
Wideband Delphi方法
步骤 活动 1. 2. 3. 4. 5. 6.
2012-12-24
召集人召集所有参加估计的人员,并将软件项目的需求和估计用表格 分发给大家 召集人召集所有参加估计的人员进行一个会议,讨论有关软件规模的
2012-12-24
25
SP 1.1 估计项目范围-子实践
• 3. 识别需要外购的工作产品或工作产品模块 • 4. 识别需要重用的工作产品 • 典型的工作产品包括
• 任务描述 • 工作包描述 • WBS
2012-12-24
26
SP 1.2 建立工作产品和任务属性的估计1
• 1. 确定技术方法
• 项目技术路线,定义产品开发的高层策略,例如
• • • • • • • • • 估计范围和必须执行的工作 建立产品的开发机制 开发项目计划 获得对计划的承诺 与供应商的工作 依据计划监控项目进展 识别和分析风险 对重大偏差采取措施 为减缓风险采取措施
7
2012-12-24
项目管理的过程域
• 包括
• • • • • • Project Planning (PP) Project Monitoring and Control(PMC) Supplier Agreement Management (SAM) Integrated Project Management for IPPD (IPM/IPPD) Risk Management (RSKM) Quantitative Project Management(QPM)
2012-12-24
5
规范:按照行为准则行事
规范是联结整个项目的粘合剂 创建和维护标准化的环境 帮助所有人建立起对他人的正常期待 使人们能够摆脱他人创造的危机,从而提高生 产力 • 提升士气 • • • •
2012-12-24
6
理解项目管理
• 目的:保证项目成功 • 覆盖策划、监督和控制项目的活动
• 3. 估计工作产品和任务的属性 • 4. 估计项目所需要的人力、机器、材料和方法
2012-12-24 28
SP 1.3
定义项目生命周期
• 定义项目生命周期并确定每阶段需要投入的工 作量
• 项目生命周期包含什么阶段由许多因素确定,例如需求范围、 资源要求以及项目特征等。大项目有可能包含多重阶段,例 如概念研究、开发、生产、运维以及退出。而这些阶段内部 有可能还会包含不同的阶段,例如开发可能包括需求分析、 设计、制造、集成和验证。根据开发策略,还可能有原型、 增量迭代或者螺旋模型 • 项目生命周期模型对于计划的工作量和时间以及重计划来说 都是至关重要的
识别项目 风险
计划相关人参与 建立项目计划
计划相关人 参于
建立项目 计划
计划所需 知识和技能
项目计划
PMC
2012-12-24
37
SP 2.1
建立预算和工期1
• 识别主要的里程碑 • 识别进度假设
• 设定里程碑通常为了确保在里程碑之前完成某种交付物。里 程碑可以是事件驱动也可以是日期驱动。对于日期驱动的里 程碑,一旦设定里程碑就很难更改它的日期 • 最初设定的进度往往伴随着对某些活动所作的假设,这些假 设往往又没有太多的可参考的估计数据。识别这些假设有助 于理解整个工期的置信水平(不确定性)
问题 参加估计的每个人匿名的填写估计表格
召集人收集所有的估计表格,然后形成反馈表返回给参加估计的人员, 召集人召集所有参加估计的人员进行一个会议,主要是讨论估计上差 异 参加估计的人员根据讨论的结果,在反馈表上提交另一个匿名的估计 重复4~6直到达成关于软件规模最大程度的一致
33
7.
Pert方法
• • • • • E=(a + 4b + c)/6 SD=(c – a)/6 a=最小可能的规模 b=软件产品的正常规模 c=软件产品的最大可能规模
为成功而计划
• If you don’t know where you are going, you’ll end up someplace else.
-- Yogi Berra
2012-12-24 12
目的
• 建立和维护定义项目活动的项目计划 • 项目计划牵涉到:
• • • • 开发计划 定义相关人的参与 获得承诺 维护项目计划
2012-12-24
18
SP 1.1 估计项目范围-子实践
• 1. 制定基于产品结构的WBS结构
• WBS可以将项目工作和要完成的产品内容有机 结合在一起,WBS通常识别下列内容: • 识别的风险与相应的应对计划 • 交付物对应的活动和支持活动 • 获取知识和技能的活动 • 准备相关计划活动 • 非开发任务所对应的管理活动
阶段3 2012-12-24
产品 23 任务
WBS-分解的基本要素
示例:
过程
需求分析 过程
产品1
产品2
原型
需求规约
任务1
任务2
任务1:制 作原型
任务2:评 审原型
任务3:培训制 作原型的方法
2012-12-24
24
WBS-2周原则
• 所有的项目活动最终都要拆分成由一个人在2 周内完成的任务 • 任务划分的比较细有利于精确的估算 • 监控和评估进度比较容易 • 跟踪项目进度和成本的时候及时更新状态信息 成为可能
2012-12-24
34
运算法
• 工作量 = p*s*l*e
• • • • p = 软件产品的规模(SLOC) s = 生产力系数(1/每人月的代码行) l = 开发工具系数 e = 规模系数
2012-12-24
35
特定目标的关系
建立估算
计划的数据
开发项目计划
获得对计划的 承诺
项目计划
PMC
2012-12-24
CMMI-项目管理过程域
PP,PMC, SAM,RSKM,IPM QPM
2012-12-24
1
主要内容
• 项目管理的概念 • 项目管理过程域 • 总结
2012-12-24
2
项目管理的概念
2012-12-24
3
什么是项目
• 管理为客户或最终用户交付产品的相关资源和 活动 • 依据计划,为这些相关资源确定一个明确的开 始、运作和结束
开发项目计划
获取对计划的承诺
• 建立并维护作为项目管理基准的项目计划 • 建立并维护对计划的承诺
2012-12-24
15
相关文档
最新文档