CMM软件成熟度

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u013225150/article/details/51703000

Table of Contents

一、绪论

软件的定义

是使计算机能够工作的指令集合和相关数据结构以及文档
是一种产品,发挥计算机的硬件能力,传递信息的工具,处理信息的手段

软件的特征

  1. 逻辑元素
  2. 开发而不是制造
  3. 不能被用坏
  4. 定制时代
  5. 创新型和个人因素

软件危机产生的原因

  1. 需求二义性、遗漏、错误
  2. 大型软件合作,系统复杂,如何组织协调发挥团队作用
  3. 缺乏工具和方法支持,依赖程序设计的技巧和创造性,加剧个性化;没有统一、规范的工具方法支持,
    文档资料不齐全
  4. 缺乏相关经验和数据的积累,无法估计经费和进度,导致经费超支,工期一拖再拖
  5. 忽视测试阶段工作,提交产品质量差

软件过程

用于开发和维护软件,以及其相关过程的一系列活动(管理活动、工程活动)

软件过程能力

组织或者项目组遵循软件过程能够实现的*预期结果*

软件过程性能

组织或者项目组遵循软件过程所得到的*实际结果*

CMM定义

Capability Maturity Model for Software:
对于软件组织在 定义、实现、度量、控制、改善其软件过程的进程中各阶段的描述

CMM5各级别的内容和特征

初始级

软件过程是无序的,甚至是混乱的,没有什么是经过定义的

可重复

建立基本的项目管理过程去跟踪成本、质量、进度,必要的过程纪律已经就位,
可以重复类似项目的成功

已定义

管理活动和工程活动均已文档化和标准化,并集成到组织标准软件过程中。全部项目均采用组织标准软件
过程中一个经批准的普及剪裁版本

已管理

已采集详细的软件过程和产品质量的度量,过程和产品均得到了定量的认识

优化级

利用来自过程、新思想、新技术的先导性实验的定量反馈信息,使得持续的过程改进成为可能

KPA定义

识别出一串相关活动,全部完成时,能达到一组对增强过程能力至关重要的目标

KPA结构(目标、共同特点)

KPA目标

概括一个KPA中所有关键实践,用于确定一个组织是否有效实施该KPA

KPA共同特点

  1. 执行约定
  2. 执行能力
  3. 执行活动
  4. 测量、分析
  5. 验证实施

CMM每个成熟度等级的KPA

初始级KPA

可重复KPA

1.需求分析
2.项目策划
3.项目跟踪与监督
4.子合同管理
5.质量管理
6.软件配置管理

已定义KPA

  1. 组织过程焦点
  2. 组织过程定义
  3. 培训大纲
  4. 集成软件管理
  5. 软件产品工程
  6. 组间协调
  7. 同行评审

已管理KPA

  1. 定量过程管理
  2. 软件质量管理

优化级KPA

  1. 缺陷预防
  2. 技术改革管理
  3. 过程更改管理

二、软件项目管理概述

项目的定义

为创建某一独特的产品或者服务,在一定环境和约束条件下进行的
临时性努力

项目的特征

  1. 一个明确的范围和目标
  2. 一个预期完成时间
  3. 可以利用的资源
  4. 一个已定义的性能评估方法
  5. 不是例行任务

项目管理的概念

一定主体,为了实现目标,综合运用专门的知识、技能、工具、方法,
对执行中项目各阶段工作进行计划、组织、协调、控制,
以满足甚至超越项目干系人的需求和期望

项目管理的三要素

质量、进度、成本

项目管理的内容(9个: 4 + 4 + 1)

中文 English
范围管理 Scope Management
时间管理 Time Management
成本管理 Cost Management
质量管理 Quality Management
   
人力资源管理 Human Resource Management
通讯管理 Communication Management
风险管理 Risk Management
合同和采购管理 Procurement Management
   
项目综合管理 Integration Management

项目管理的阶段划分(了解即可)

  1. 项目规划
  2. 项目执行
  3. 项目收尾

三、需求分析

需求的定义

用户解决问题或达到目标所需要的条件或者权能(Capability)

需求分析的过程

  1. 准备阶段
  2. 采集、澄清需求
  3. 分析需求
  4. 准备SRS (Software Requirements Specification, 需求规格说明书)
  5. 评审SRS
  6. 客户认可并签署SRS

需求规格说明书的要求(六点)

正确性、无二义性、
完整性、一致性、
可测试性、可跟踪性

需求变更管理的过程(8个步骤: 4+2+2)

No. 过程步骤
1. 记录变更
2. 分析影响
3. 估计变更工作量
4. 重新估计交付时间表
   
5. 执行累计成本影响风险
6. 影响超出限度,与高级主管评审
   
7. 客户不再提出变更申请
8. 修改工作产品

四、过程定义和过程裁剪

过程的定义(了解)

遵照执行某些任务的一系列步骤,以及执行这些步骤的指南
开发过程是提炼用户需求,设计、构建和测试满足需求的软件并交付给客户的过程

一般软件开发的子过程

需求分析 -> 概要设计 -> 详细设计 -> 编码和单元测试 -> 集成测试 -> 系统测试 -> 验收测试和安装 -> 文档 -> 系统维护

每个子过程的参加者

子过程 参加者
需求分析  
概要设计 设计团队、评审团队、客户
详细设计 设计团队
编码和单元测试 项目组成员、项目经理
集成测试 集成测试团队
系统测试 系统测试团队
验收测试和安装 安装团队、客户、项目经理
文档 //
系统维护 安装团队、维护团队

子过程的五要素(2+2+1)

  1. 输入准则
  2. 输入
  3. 输出准则
  4. 输出
  5. 度量

过程裁剪的定义

调用组织标准过程的过程,以获得用于项目特定业务或技术需要的过程

过程裁剪的分类(两类)

  1. 概要裁剪指南
  2. 详细裁剪指南

概要裁剪可依据的项目特征

  1. 团队和项目经理的 经验、熟练程度
  2. 团队最大人数
  3. 需求透明度
  4. 项目持续时间
  5. 应用的关键程度

五、过程数据库和过程能力基线

软件度量的含义

量化地描述*软件过程*和*软件产品*不同方面的特点

软件度量的作用

  1. 项目计划
  2. 控制项目过程
  3. 分析和改进软件过程

过程数据库定义PDB

存放 从项目可获得的 过程性能数据的 数据库 (用于计划、估计、生产率和质量分析)

过程数据库的数据

  1. 项目特征
  2. 项目进度
  3. 项目工作量
  4. 项目规模
  5. 故障和风险

过程能力基线定义PCB

用 基线形式 量化地表示过程能力(有助于对过程进行分析和改进)

过程能力基线的数据

  1. 已交付软件的质量
  2. 生产率
  3. 进度计划
  4. 工作量分布

  5. 故障引入率

  6. 过程中故障排除率
  7. 故障分布

  8. 质量成本

PCB数据项的计算方法

Data Calculations Meaning
F   用功能点描述的软件规模
E   总工作量(人月)
D1   开发过程(提交前)发现的所有缺陷数
D2   提交后发现的缺陷数
     
D D1 + D2 总缺陷数
生产率 F / E 功能点规模 / 工作量
质量 D2 / F 提交后缺陷数 / 功能点规模
缺陷注入率 D / F 平均每个功能点的缺陷
整体缺陷清除率 D1 / D 提交前检出的缺陷占总缺陷的比重

PDB的建立以及访问权限

  1. 建立: SEPG (Software Engineering Process Group, 软件工程过程小组)
  2. 项目经理可以阅读

过程财富的含义

  • 组织标准软件过程
  • 组织关键过程数据库/过程能力基线 (PDB and PCB)
  • 软件生命周期描述
  • 标准软件过程的裁剪指南和准则
  • 软件有关文档

六、工作量估计和进度安排

软件规模的估计方法(代码行、功能点)

代码行法

   
优点 1. 不管用什么编程语言,都容易计算
  2. 存在很多基于LOC的软件估算模型和文献数据
  3. 容易导出其他度量
   
缺点 1. 只有在产品完成后才能计算
  2. 依赖设计语言
  3. 不利于好的设计而产生短小程序

功能点法

编号 步骤内容 计算方法
A 计算未调整的功能点UFP 确定输入、输出、查询、数据文件、界面元素数量和复杂度,计算功能点
B 计算技术复杂度因子TCF 14个因子评估,并相加 TCF = F1 + F2 +… + F14
C 计算功能点 FP = UFP \* (0.65 + 0.01 \* TCF)
D 功能点与代码行的转换 根据 LOC/FP 表的内容计算

功能点法估计软件规模的步骤

  1. 计算 输入(4)、输出(5)、查询(4)、主控文件(10)、接口需求数目(10)
  2. 加权乘
  3. 根据复杂度的判断

自底向上的工作量估计方法步骤

步骤编号 步骤内容
1 确定系统中的程序,分为简单、中等、复杂(S/M/C)
   
2 存在特定基线,从中构建 S/M/C 程序平均工作量
3 基线不存在,查找类似项目(类型、技术、语言)来定义S/M/C程序工作量
4 没有类似项目和特性基线,用通用过程能力基线定义S/M/C构建工作量
   
5 使用项目特定因素 改进S/M/C程序构建工作量
6 使用S/M/C构建工作量和被调用次数获得 总构建工作量和总工作量
   
7 给予项目特定的因素重新改进估计

自顶向下的工作量估计方法步骤

步骤编号 步骤内容
1 获得按照功能点计算的 软件规模估计
   
2 使用类似 过程类型的PCB生产率数据 或 PDB种类似项目的生产率数据 确定项目生产率级别
   
3 从生产率 和 规模 获得整体工作量估计
4 使用PCB获得的工作量分布数据 估计工作量
   
5 用项目的特定因素 修正估计

COCOMO初级模型

COCOMO初级模型概述

应用于中小规模项目进行快速又粗略的估计,将开发工作量作为软件规模函数进行计算
软件规模以代码行来表示

计算公式

注: a, b, c, d是不同项目的常数系数(考试会给出)

Symbols Calculation Meaning
S   代码行数(千行)
E a \* S^b 工作量估算(人月)
D c \* E^d 开发时间估计(月)

COCOMO中级模型

COCOMO中级模型概述

将软件开发工作量作为“软件规模”及“工作量调整因子EAF”的函数进行计算
精度有所提高

工作量调整因子EAF(Effort Adjustment Factor)

包括一组“成本驱动因子属性”值的评估,ci为成本驱动因子属性值,共四类15个,在六个等级上取值

计算公式

Symbols Calculation Meaning
EAF ci1 \* ci2 \*… \* ci15 工作量调整因子
E a \* S^b \* EAF 工作量估算(人月)

七、质量计划和缺陷估计

软件质量的定义

已交付软件的故障密度

缺陷注入和清除的环节

Process In / Out
需求分析 注入
  R
设计 注入
  R
编码 注入
  R
单元测试 UT R
集成和系统测试IT/ST R
验收测试AT R

质量管理的主要任务

规划合理的质量控制任务,然后正确地执行和控制它们,实现项目质量目标

如何制定量化质量管理计划

直接设定质量目标的方法

  1. 设定质量目标
  2. 估计规模
  3. 估计验收测试(AT)缺陷数
  4. 估计各阶段缺陷数
  5. 质量过程计划

直接设定缺陷注入率的方法

  1. 设定缺陷注入率(D/S)
  2. 估计规模S
  3. 估计总缺陷数D
  4. 估计验收测试缺陷数D2
  5. 质量过程计划

八、风险管理

风险的定义

可能发生的事件或条件,如果发生,对项目产生负面影响

风险管理的含义

试图使由于意外事件 导致项目失败的概率最小化

风险管理的内容

风险评估、风险管理

风险管理的目标

识别风险,最小化它们的影响

风险管理的特点

付出额外成本,价值不易度量

如何进行风险评估

确定风险 –> 风险分析 –> 风险等级划分

常见风险种类或类型

分类 原因
人员 人员流动
  缺乏经验
  不充分的业务知识
   
客户 需求变更过多
  需求不清晰
  不能满足的性能需求
   
管理 强加于项目的外部决策
  不切实际的进度
  使用新技术

九、项目管理计划

项目管理计划定义

Project Management Plan (PMP):
项目经理承担的所有规划任务的核心,各规划任务的结果都出现在PMP中,
是指导所有项目执行的基准文档

项目管理计划的内容

1.项目概述
2.项目计划
3.项目跟踪
4.团队

项目管理计划的主要使用者

1.业务主管
2.项目经理
3.开发人员

十、配置管理

配置管理的概念

项目管理的一项内容,系统控制变更,建立和维护在项目的整个生存周期中 项目产品的完整性

配置管理包括的内容

1.标识 在给定时间点上 软件的配置
2.控制对配置项的更改
3.维护在整个软件生存周期 配置的完整性和可跟踪性

配置管理的功能

  1. 给出程序的状态
  2. 给出一个程序的最新版本

  3. 处理并发更新申请

  4. 取消一个变更
  5. 防止未经授权的变更或删除

  6. 提供需求变更申请 和 程序变更之间的可跟踪性

  7. 取消一个需求变更

  8. 显示相关变更

  9. 收集当前系统所有 源代码、文档和其他信息

配置管理的主要任务

a) 程序状态转移管理
b) 必须被实现的变更申请管理

配置管理中如何执行变更申请

  1. 接受 变更申请(影响分析之后)
  2. 建立跟踪机制
  3. 检出需要变更的配置项
  4. 执行变更
  5. 检入配置项
  6. 在整个生命周期 维护该配置项

十一、评审

评审的功能和特点(5点)

  1. 各阶段、各类型–范围广
  2. 比测试更有效率:问题本身>>征兆
  3. 不仅发现错误,提出改进意见,防止再发生
  4. 可在开发阶段进行,作者熟悉细节,及时修改
  5. 利于评审员、项目组熟悉有关产品

评审的过程

  1. 评审规划
  2. 准备和概述
  3. 评审会议
  4. 返工和后续措施

评审分析指南(重要)

缺陷少于正常

Causes Solutions
产品非常简单 单人评审
没有仔细评审 重新安排评审
没有足够评审培训,或对评审材料经验不足 安排评审培训;安排其他队伍
产品质量高 确认事实,是否能够重现

缺陷多于正常

Causes Solutions
产品质量很低 培训?重做?重新考虑分配将来任务
产品非常复杂 确保良好的评审和测试;增加系统测试估计;划分成更小的组件
太多的小错误(以及很少的大错误) 确定小错误原因,增强检查表;另外选择评审专家
评审文档不够详细、清楚 评审、批准参考文档
评审模块是项目中的第一批模块 分析缺陷、更新评审检查表通知开发者安排培训

十二、项目监督和控制

项目监督和控制的主要活动

数据采集、项目跟踪、里程碑分析、缺陷级别定义

数据采集的内容(3个方面 2个数据1个测量)

  1. 工作量数据
  2. 缺陷数据
  3. 规模测量

项目跟踪的内容

  1. 任务跟踪
  2. 故障跟踪
  3. 问题跟踪
  4. 状态报告

里程碑分析的内容(工作量/进度、测试性能)

工作量、进度性能指南

  1. 如果实际比估计得少的程度超过了允许的度量(2点)

    Possible Causes Actions
    程序的估计太高,或者知识经验比预想的多 重新估计以后的模块,释放资源
    没有充分地执行当前任务 评审已经完成的任务,检查事宜记录
  2. 如果实际比估计得多的程度超过了允许的度量(7点:2+4+1 人员的:管理的:历史的)

    Possible Causes Actions to take
    该领域内知识匮乏 安排培训
    作者经验不足 重新分配工作
    新技术领域 重新估计或请求资源,协商交付日期
    估计太紧凑 确定组建额外工作量、更改估计,请求资源,协商降低目标
    资源优化差 重新安培任务并重新确定任务的优先级
    不能获得关键资源 向上级反映;获得备份资源重新安排进度
    一些早期阶段的输出质量差,引起太多的返工 确定问题来源并纠正,更改项目进度

测试性能指南

  1. 如果实际发现的缺陷数小于估计的数目(4点:2+2 好和不好)

    Possible Causes Actions
    高质量的工作产品 确定原因 查看过程的可取的教训
    早期质量控制活动执行细致 分析所有评审和测试记录,检查过程中可取教训
    不充分的测试 增加测试;评审、加强测试计划
    缺陷估计过高 确定原因,改正估计
  2. 如果实际发现的缺陷数大于估计的数目(2点)

    Possible Causes Actions
    质量控制活动不适当执行,或者不充分的评审、单元测试 检查所有测试评审记录,安排关键模块评审,加强测试
    缺陷估计太低 确定原因,改进估计

缺陷分析和预防的内容(两种分析方法)

帕累托分析

因果分析

阅读更多 登录后自动展开
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页