CMMI软硬件模式过程域的概述

 

CMMI 软硬件模式过程域的概述

 

 

简述

CMMI过程域间的相互作用

CMMI2级过程域的运用

CMMI3级过程域的理解

CMMI成熟度实践的理解

 

 

CMMI结构

CMMI结构总结起来就是一句话：一种模式，两种表现

如下图

Maturity Level 5     OID, CAR

Maturity Level 4     OPP, QPM

Maturity Level 3     REQD, TS, PI, VER,     VAL, OPF, OPD, OT,     IPM, RSKM, DAR

Overview     Introduction     Structure of the Model     Model Terminology     Maturity Levels, Common Features, and Generic Practices     Understanding the Model     Using the Model

Maturity Level 2     REQM, PP, PMC,     SAM, MA, PPQA, CM

Appendixes

Engineering     REQM, REQD, TS,     PI, VER, VAL

Project Management     PP, PMC, SAM     IPM, RSKM, QPM

Process Management     OPF, OPD, OT,     OPP, OID

Process Management     PAs     - Goals     - Practices

Support    CM, PPQA, MA,     CAR, DAR

Appendixes

CMMI-SE/SW Staged

Overview     Introduction     Structure of the Model     Model Terminology     Capability Levels and Generic Model Components     Understanding the Model     Using the Model

CMMI-SE/SW Continuous

 

 

CMMI过程域的四个种类

过程域可以归为四类：

§ 过程管理

§ 项目管理

§ 工程

§ 支持

 

为了更有效的应用CMMI模型，必须先弄清楚现存于CMMI模型中各组成部分间的相互作用关系。

 

1. 过程域之过程管理类

下面这些都是CMMI 里的过程管理PA ：

1.       机构过程聚焦； 2. 机构过程定义； 3. 机构的培训； 4. 机构过程执行； 5. 机构创新与部署

过程管理PA包含着一些涉及定义、计划、资源支持、配置、实施、监测、控制、评估、量化以及过程改进相关的cross-project行为。

 

特别注意：机构综合环境(Organizational Environment for Integration)将被IPPD所覆盖。

 

过程管理过程PA 的理解：

The process management Pas apply across the organization as a whole and provide details that support the Capability Level 3 Generic Goal.

 

对于已选择的PAs，企业必须有一套标准的过程，个体的项目都须符合该过程的需要。

 

定义在Capability Level2制度中的PAs，提供了project level stablility，过程管理PAs可以利用起来。如，策划、计划、资源、职责、培训、执行过程、配置管理、监控、目标验证、管理回顾。

 

基本过程管理过程域，如下图

 

高级过程管理过程域，如下图

2. 过程域之项目管理

下面这些都是CMMI 项目管理PA ：

项目计划(PP)。项目监控(PMC)。供应商协议管理(SAM)。项目集成管理(IPM)。风险管理(RSKM)。Quantitative Project Management(QPM)

 

特别注意：Integrated Teaming(IT) and IPM(IPPD)将被IPPD覆盖。集成供应商管理将被SS覆盖。

 

基本项目管理过程，如下图：

 

高级项目管理过程，如下图：

 

3. 过程域之工程

下面这些都是CMMI 中的工程PAs ：

需求管理(REQM)。需求开发(RD)。技术解决方案(TS)。产品集成(PI)。验证(VER)。确认生效(VAL)。

 

4. 过程域之支持

以下这些都是CMMI 中的技术PAs ：

配置管理(CM)。过程及产品质量保证(PPQA)。测量分析(MA)。因果分析及解决方案(CAR)。决策分析及解决方案(DAR)。

特别注意：Organizational Environment for Integration 将被IPPD覆盖。

 

支持过程域的理解

支持过程域涵盖了支持产品开发、维护、产出等方面的活动。

他们通过CMMI过程域来提供一些经使用的重要的过程，并在执行其他的过程中代表性的使用这些过程。

 

基本支持过程域，如下图：

 

高级支持过程域，如下图：

 

问题：CMMI过程域的四个种类分别是什么？

过程管理PAs、项目管理PAs、工程PAs、支持PAs。

 

小结

CMMI各过程域间的相互作用

CMMI LEVEL 2中过程域的应用

CMMI LEVEL 3的理解

CMMI高成熟度实践的理解

 

各管理级别下的过程域

 

需求管理(REQM)

目的：管理项目产品及产品组成的需求，并且鉴别需求与项目计划与产品间不一致的地方

 

需求管理结构图：

 

需求的含义如图：

 

客户指的是哪些？

客户也许是内部的，也可能是外部的。他们可能是系统工程师、市场人员、其他软件服务团队以及提出需求的任何人

 

技术性需求与非技术性需求

技术性需求技术了软件的技术概貌，例如：功能性需求、性能需求、界面需求。

非技术性需求描述了无技术的但在项目中要解决的需求，例如：表述产品的类型(图片格式、文档、测试软件)；表述日期；里程碑

 

 

需求变更追踪描述

当客户改进了他们的需求，当系统里的政策、机构或技术环境不得不变更时，需求的变更就在所难免了。

Refer to the Configuration Management process area for more information about baselines and controlling changes to configuration documentation for requirements.

描述信息是一种有助于我们评估需求变更所带来冲击的一种信息。它联系着需求与其他系统的请求。

Traceability matrices may be used to record traceability informantion.

 

需求追踪描述的范例

 

 

应用需求管理，如下图：

 

项目计划(PP)

目的：修订并维护一个定义项目活动的计划。

 

项目计划结构如图：

 

 

定义问题

确立一个限制问题的表述；确立功能划分

 

定义软件范围

上下文；信息目标；功能与执行

 

Problem Decomposition

功能必须表述清楚

过程将被用于表述这些问题

 

合并问题与过程，如下图

 

 

 

The W5HH Principle

获取项目的本质

       Why is the system being developed?

       What will be done? By when?

       Who is responsible for a function?

       Where are they organizationally located?

       How will the job be done technically and managerially?

       How much of each resource (e.g., people, software, tools, database) will be needed?

 

步骤：

范围：弄清必须解决的问题及工作

评估：获得多大的成果？花费多长时间？

风险：哪些地方可能出错？

进度：我们如何长期有效地去布署资源？哪些是里程碑？

控制策略：我们如何控制质量？我们如何控制变化？

 

软件范围：

描述要处理的数据并作展示：控制参数、功能、执行、约束、外部接口、可靠性

从软件范围定义中提练出其所描述的功能，来更好的评估成本与进度

 

理解范围的含义

理解用户的需求、理解商务应用的全貌、理解项目界线、理解用户的动机、理解变更可能出现的方式...

 

资源

人力资源：完成项目所需的人数和技术

可复用的软件资源：一些未发布的组件、使用充分的组件、部分使用的组件、新的组件

环境资源：开发期间所需访问到的软硬件资源

 

软件项目评估

明确定义软件的范围

任务或功能的区分是必要的

historical measure(metrics)是很有帮助的

至少使用两种不同的技术

牢记不确定性是会一直存在的

 

技术评估

以前(相似)的项目经验

常规的技术

任务分解和成果评估

按重要性将估量结果排列出来

工具

 

Work Breakdown Structure(WBS)

WBS是项目工作包的一个逻辑层，它是项目计划过程中不可缺少的工具。

 

WBS 的目的

WBS可以帮助定义项目需求，并将这些需求划分出来归入到每个称为work package的功能区块里。

一个好的WBS可以帮助开发进度、预算和资源需求。

WBS是一个身分激活与责任分配的好工具

WBS 图解实例

 

WBS 例子小结

1. retail web site

2.项目管理

3.收集需求

4.分析设计

5.站点软件开发

 5.1 HTML设计与实现

 5.2后台软件

    5.2.1数据库建立

    5.2.2中间件开发

    5.2.3安全控制系统

    5.2.4目录引擎

    5.2.5事务处理

 5.3图形界面

 5.4content creation

6.测试发布

 

WBS 类型

WBS流程：a.k.a Activity-oriented。如：需求管理、分析、设计、测试

 

项目管理有条件地使用：product WBS。a.k.a. Entity-oriented。如：功能引擎、接口系统、数据库。项目经理有条件地使用

Hybrid WBS:both above：详细请看“Melding Problem and Process”(合并问题与过程)。Rationale: processes produce products

 

WBS 产品

 

WBS 流程

 

WBS 开发入门

自上而下地开发WBS，而不是自底向上

在一个WBS中不能超过5个级别

List of items can come from many sources

 

项目风险

什么是可能出错的？

出现可能性的地方在哪儿？

预计会出现什么故障？

我们如何去做？

 

风险管理的反应

项目团队在风险出现时的反应

减少风险：为预计的突发状况准备额外的资源

确定故障：当风险出现时找到并应用那些资源

危机管理：

 

预警管理

正规地实施风险分析

企业找到风险的根源并校正：1. TQM concepts and statistical SQA；2. 检查存在于软件范围外的风险的根源；3. 开发管理变更的技术

 

风险规避、监测与管理

规避：如何避开风险

监测：我们要追踪哪些要素，可以使我们判断风险变好或变坏的要素

管理：我们制定了什么应急计划以当风险转化为现实？

 

记录风险信息

 

 

 

提炼一个软件生命周期

 

 

 

定义项目软件过程

宏观的项目进度需要提炼，以建立更周详的进度表。

通过提取单个任务，将该任务分解为一系列的子任务来提炼。

将任务和子任务记录为周详的进度。

 

定义一个任务网络

 

用工具得出一个长线的图表

 

应用项目计划(PP)

 

项目计划

各软件项目计划可能拥有不一样的名字。

软件开发计划

软件项目管理计划

软件项目计划

项目管理计划

软件工程管理计划

 

项目监控(PMC)

目的：

为项目过程文件提供注解，以便在项目的执行偏离计划的目的时，矫正我们的行为。

 

图解：

 

监测与项目计划是相对的

项目监测是用来针对(PP)过程中制定的项目计划的。

比较现实的与预估的情况，再决定过程：

1.       预估的与实际的产品大小

2.       预期的与实际的成果与成本

3.       预估的与实际的进度

4.       预估的与实际的SE技术性活动

5.       与上述因素有关联的风险

 

必要时矫正行为

如果计划与实际过程间产生差异，该项目组必须想办法如何矫正该问题。

项目组可以改变当前做事的方式

项目组可以改变计划以适应当前的情况

将原来的计划归档并根据历史原因修改当前的计划是非常重要的。

 

责任改变

当最初定义的需求因为下列原因变更时，责任也需随之修改：

1.       客户的需求有变；

2.       原型定义或其他活动带来了新的知识点。

当然需求改变时，项目计划必须改变以适应新的义务。

 

应用项目监控(PMC)

PMC：让进度与计划可见，这样每个人都可以了解到他们的目标以及不能完成该目标的后果。跟踪过程以记录成功的事件，并更好的理解进度间的冲突或是特性的改变。随时提醒管理人员当前的状态、风险与问题。当最初的设想改变时，修改进度与计划。

跟踪两块：检验与测量系统。他们俩提供监测部分来矫正行为。

 

量化分析

目的：开发与维护一个可量化的能力，该能力用以支持管理信息所需。

图解：

 

测量& 规则

 

我们为什么测量