【软件过程改进 学习笔记】过程思维 ( 软件危机 | 软件过程 | 过程改进 | 过程思维 | 过程描述 | ISO 9000 | 6σ | PCM | CMMI )

文章目录

• 一. 软件危机 及 过程
• • 1.软件面临的挑战
  • • ( 1 ) 提出问题
  • 2.软件危机
  • • ( 1 ) 软件危机存在
    • ( 2 ) 失控软件项目分析
    • ( 3 ) 软件危机不存在
  • 3.银弹存在研究
  • 4.软件危机 解决方案
  • 5.公司能力 与 能力改进
  • • ( 1 ) 公司能力 提出
    • ( 2 ) 能力改进作用
  • 6.软件过程发展
  • 7.以质量为中心的软件工程
  • 8.软件过程 定义 及 作用
• 二. 过程定义 及 特性
• • 1. 过程 及 过程成熟度发展
  • 2. 软件过程定义 及 特性
  • 3. 过程 3 个方面的特性
• 三. 过程的优劣
• • 1. 过程的基本要求
  • 2. 有效的软件过程
  • 3.成熟的软件过程
  • • ( 1 ) 成熟 与 不成熟
    • ( 2 ) 成熟 的 发展过程
    • ( 3 ) 软件过程成熟度
    • ( 4 ) 不成熟的组织标志
    • ( 5 ) 成熟的组织标志
  • 4. 过程规范 副作用
  • 5. 过程认知的 误区
• 四. 过程改进的必要性
• 五. 过程思维
• • 1. 过程思维简介
  • • ( 1 ) 过程思维 简介
    • ( 2 ) 过程思维 观点
  • 2. 面向过程 与 面向任务组织 区别
  • 3. 以过程为中心 与 以产品为中心 区别
• 六. 过程 描述方法
• • 1.文字描述法
  • 2.表格法
  • 3.图示法
  • 4.部门流程图法
• 七. ISO 9000 过程模型介绍
• • 1. IOS 9000 简介
  • 2. GB/T 19001-2008
  • 3. ISO 9000 标准的科学依据
  • 4. 质量管理八原则 ( 重点 )
  • 5. 质量管理
  • • ( 1 ) 质量形成
    • ( 2 ) 控制影响质量的全部因素
    • ( 3 ) 持续保持质量 的 能力
    • ( 4 ) 质量改进 - 质量管理必须坚持进行质量改进
    • ( 5 ) 质量管理中 体现 PDCA 循环 ( 戴明环 )
    • ( 6 ) 预防是核心 不是补救
• 八. SPICE ( ISO/IEC 15504 )过程模型介绍
• • 1. SPICE 标准简介
  • 2. SPICE 标准新进展
• 九. 6\sigma 过程模型介绍
• 1. 6\sigma 由来2. 6\sigma 管理法概念3. 6\sigma 定义4. 6\sigma 过程思想5. 6\sigma 等级6. 6\sigma 计算方法
• 十. PCM 过程模型介绍
• • 1. PCM 简介
  • 2. 计划阶段
  • 3. 设计阶段
  • 4. 实现阶段
  • 5. 稳定阶段
  • 6. 发布阶段
• 十一. SW-CMM 过程模型介绍
• • 1. CMMI 版本发展
  • • ( 1 ) CMMI 版本发展
    • ( 2 ) CMMI 2.0 重大变化
  • 2. CMMI 简介
  • 3. CMMI-DEV V2.0 模型结构
  • 4. CMMI 商业价值

博客相关资料下载 : 下载地址

一. 软件危机 及 过程

提出了软件开发中的几个问题, 以及软件危机的概念, 软件危机是否存在, 及理由; 软件危机解决方案 ( 银弹 ) 的发展历程; 软件过程的提出与发展, 及四个研究方向;

1.软件面临的挑战

( 1 ) 提出问题

提出一些问题 : 这门课程基本就是针对如下问题进行解决;

• 1.大型软件开发 : 开发大型软件, 需要做那些事情 ?
• 2.软件开发技术 : 当前的软件开发技术是否完美 ?
• 3.改进开发技术 : 如何针对当前的软件开发技术进行改进 ?

软件研发中的问题 :

• 1.几个公认的问题 : ① 软件项目 超出预算 ; ② 软件项目 进度落后 ; ③ 软件项目 质量不可靠 ;
• 2.软件危机 ( Software Crisis ) : 软件研发中, 是否存在软件危机 ?
• 3.银弹 ( Silver bullet ) : 银弹 即 软件危机的解决方案, 可以解决任何软件研发的问题, 银弹是否存在 ?

本门课程将会逐步针对上述问题给出对应的解决方案 ;

2.软件危机

( 1 ) 软件危机存在

软件危机存在的理由 :

• 1.开发中的一些事实 : ①软件可靠性没有保障, ②软件维护费用不断上升, ③软件进度无法预测, ④成本增长无法控制, ⑤无限度增加开发人员 ;
• 2.很多失败的项目 : ①美国水手1号出现软件错误没有达到金星, ②阿波罗14号飞行10天出现18个错误, ③IBM360操作系统 ;

( 2 ) 失控软件项目分析

失控软件项目分析 :

• 1.失控的软件项目分类 : ①目标不定 : 没有指定完整的目标, ②计划 : 计划和估算不准, ③新技术 : 新技术的采用, ④管理 : 管理方法缺少规范 或 不恰当, ⑤研发力量 : 高级员工不足, ⑥外部环境 : 供应商提供的软件或硬件性能不足, ⑦性能 : 软件性能或效率问题 ;
• 2.失控软件项目相同特性 :
  • ① 大型项目 : 多数失控的软件项目都是 大型项目 ;
  • ② 多种原因导致 : 导致失败的原因有多种; 不一定有某个失败原因起主导作用 , 有多个问题导致项目失败 ;
  • ③ 计划不足 : 很多软件项目初期都有重大进展, 与被替换的项目对比, 有很大优势; 但是项目一旦展开, 出现各种导致失败的问题 ;
  • ④ 技术问题 : 技术问题 也经常 成为失败的原因 ;
  • ⑤ 性能问题 : 软件的性能 成为主要的技术性问题 ; 如 需要高并发性能的12306订票网站数次瘫痪;

( 3 ) 软件危机不存在

软件危机不存在的理由 :

• 1.失败数据使用不当 : 对失败软件的数据 使用不当, 导致人们人为存在 软件危机 ;
• 2.成功软件 : 计算机技术 已经成为社会的主导力量, 有大量的成功软件的案例 ;
• 3.不良企图 : ① 经销商 : 出售软件危机解决方案 ; ② 学者 : 获取针对软件危机的研究经费, 及让人们接受他们提出的解决方案;

3.银弹存在研究

关于银弹是否存在的研究 : 银弹是指一个问题的终极解决方案 ;

• 1.Brooks 在 1987年 论证 : 十年内没有 单项技术 或 实施方案 使得 软件的生产能力 得到完美改善 ; [Brooks, F. P… No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, 1987, 20(4): 10-19. ]
• 2.没有银弹的阶段 : 1970 ~ 1990 没有解决软件危机的有效办法 ;
• 3.银弹的持续研究 : 每当有 新技术出现 或者 新的工作方法出现 时, 都会被 误认为解决软件危机的 银弹, 如下 :
  • ① 工具 ( Tool )
  • ② 行为准则 ( Discipline )
  • ③ 形式方法 ( Formal Method )
  • ④ 过程 ( Process )
  • ⑤ 专业化 ( Professionalism )

4.软件危机 解决方案

软件危机 解决方案 :

• 1.多种手段公用 ( 技术 + 管理 ) : 没有单一的银弹可以解决, 使用多种手段; 单纯的技术手段无法解决 软件危机; 因此提出了 技术 与 管理 结合的方案, 即 过程 ;
• 2.软件危机解决方案进化 : ① 80年代的思路是 工具 + 方法 ; ② 80年代之后的思路是 过程, 解决方案是 基于过程 的软件工程 ;
• 3.主要技术 : 下面罗列出 软件危机解决方案 的主要相关技术 :
  • ① 软件的 分析技术, 需求分析, 建模技术
  • ② 设计技术 ( 结构化, 面向对象 )
  • ③ 程序设计, 开发工具
  • ④ 软件测试技术, 测试工具
  • ⑤ 组件 / 构件技术
  • ⑥ 程序证明
  • ⑦ 净室技术
  • ⑧ 软件可靠性工程 ( SRE )

5.公司能力 与 能力改进

( 1 ) 公司能力 提出

公司能力 提出 : 公司能力主要是能 稳定 提供 高质量 的软件产品 ;

• 1.公司负面情况 : 很多公司经历过 成本超支, 项目延期, 士气低落, 质量低下, 并引发 返工, 客户投诉 等负面情况;
• 2.重复出现 : 上述负面情况会经常重复出现 ;
• 3.解决方案 : 改进公司能力 可以解决上述问题 ;

( 2 ) 能力改进作用

能力改进作用 :

• 1.能力改进项目 : 建立适合的解决方案 识别 并 利用 公司的关键能力, 需要建立 能力改进项目 ;
• 2.积极作用 : 任何规模的公司都能从能力改进中获益, 公司的整体能力 和 日常业务运作能力 都可以提升;
• 3.公司能力提高关键 : 将 可获得的资源 和 技术 链接起来 是提高公司能力的关键因素 ;
• 4.公司能力本质 : 公司能力需要 牢固地建立在 获得 开发 保持 推进 这些能力的 人员 过程 技术 的 质量上面 ;

6.软件过程发展

软件过程的发展 :

• 1.软件过程也是软件 : Leon Osterweil 在 1987 年提出, 软件过程也是软件 ;
• 2.研究方向 : 软件过程建模方法 和 以过程为中心的软件工程环境 ( process-centered software engineering environment : PSEE) ; 该研究关注四个方面 :
  • ① 数据集成 ;
  • ② 工具集成 ;
  • ③ 控制集成 ;
  • ④ 软件过程及其模型的变更控制 ;

7.以质量为中心的软件工程

软件工程 三要素 : 三种 组成的体系, 要 以 质量 为中心 ;

• 1.方法 : 为 软件开发 提供 如何做 的技术;
• 2.工具 : 为 软件工程方法 提供 自动或半自动 软件支撑环境 ;
• 3.过程 : 综合 软件工程方法 和 软件工程工具, 以达到 合理 及时 地 进行软件开发;

8.软件过程 定义 及 作用

软件过程 简介 : 软件过程 是 为了 开发高质量软件 所需要完成的 任务框架, 即形成软件产品的 一系列步骤, 包括 中间产品, 资源, 角色 及 在过程中采取的 方法, 工具 等 ;

软件过程 作用 :

• 1.提高生产力 : 有效的 软件过程 能极大 提高 公司组织的 生产力 ;
• 2.明智决策 : 理解软件开发的 基本原则, 可以帮助我们做出明智的决策 ;
• 3.工作标准化 : 使工作标准化, 提高软件的可重用性, 和 员工之间的协作 ;
• 4.不断改进 : 软件过程的理论强调, 不断的进行过程的改进, 使软件开发 不断的 跟上潮流, 接收新的 软件开发经验;
• 5.降低成本 : 有效的软件过程, 能降低软件的维护成本 ;
• 6.合理变更 : 有效的 需求变更过程, 能合理的管理变更, 减少变更带来的混乱;
• 7.规范开发 : 可以规范软件开发方式;
• 8.资产积累 : 有助于积累组织过程资产 ;

二. 过程定义 及 特性

1. 过程 及 过程成熟度发展

过程 : 过程是 做事的 流程 , 规章制度 ;

过程成熟度 起源 与 发展 :

• 1.质量控制原理 : 发展统计学, 质量控制原理 ; Walter Shewhart ( 1930 )
• 2.质量控制原理加强 : 进一步发展 并 证明 Shewhart 原则 ; Edwards Deming ( 1956 ) , Joseph Juran ( 1956 )
• 3.量化 : 发展质量成熟度 量化 ; Phil Crosby ( 1956 )
• 4.软件过程 量化 : 软件过程中, 采用了 Crosby 量化, 加入成熟度等级概念 ; Watts Humphrey ( 1956 )
• 5.框架 : 发展成熟度框架, 成熟度问卷, SPA, SCE, CMM, CMMI ; SEI ( 1987-2000 )

2. 软件过程定义 及 特性

软件过程 定义 : 软件过程 ( Software Process ) 是 在 软件生存周期 中所实施的 一系列活动 ( Activity ) 的 集合, 每个活动都是由 一些 任务 ( Task ) 组成的 ; 软件生存周期 : 软件生存周期(SDLC，软件生命周期)是软件的 产生 直到 报废 的生命周期; 周期内 有 ①问题定义、②可行性分析、③总体描述、④系统设计、⑤编码、⑥调试和测试、⑦验收与运行、⑧维护升级到废弃 等阶段

过程特性 :

• 1.输入输出 : 过程 需要 输入 和 输出, 输入 是实施过程的 基础 和 依据, 输出 是过程完成的 结果, 过程会得到有形 或 无形 的产品;
• 2.资源活动投入 : 过程 完成 需要投入 适当的资源 和 开发相应的活动; 如 人员, 设备, 资金, (资源) 以及 设计, 计划, 检验 等活动 (活动) ;
• 3.增值效果 : 过程本身有增值效果, 是有益的经济行为 ;
• 4.过程质量控制 : 过程的质量需要保证, 针对 过程的输入 (资源 活动) 和 输出(中间件 产品) 需要在 适当的阶段 进行 检查, 评审 和 验证;

3. 过程 3 个方面的特性

过程特性 :

• 1.过程定义 : 过程需要被定义,一般是将过程所包含的 活动 及 程序 制定成 文档 ;
• 2.过程培训 : 过程需要培训, 需要 给过程中的 每一个相关人员 培训 过程涉及的知识 ;
• 3.过程结果 : 执行过程活动, 可以得到过程 结果 ;

三. 过程的优劣

过程优劣判定方向 : ① 过程的基本要求 ; ② 过程的有效性; ③ 过程的成熟性 ;

1. 过程的基本要求

过程的基本要求 :

• 1.干系人接收并执行 : 过程思想 已经 被干系人 理解, 遵守, 度量 并 严格执行;
• 2.目标明确 : 过程支持 商业目标, 是为 该目标进行 服务 的 ;
• 3.汇聚作用 : 过程实施过程中, 将 组织, 管理者, 人员, 技术, 基础设施 都汇聚起来;

2. 有效的软件过程

有效的软件过程 :

• 1.明确过程所有者 : 过程的所有者必须明确, SEPG ( Software Engineering Process Group ) 软件工程过程组 主持运行 软件过程, 负责对 软件过程的 维护 与 改进 ;
• 2.培训 : 软件过程需要培训, 培训对象包括 ①主管人员, ②SPEG, ③项目管理者, ④项目组成员, ⑤支持人员, ⑥质量保证人员 等 ;
• 3.实施 的 度量 和 反馈 : 过程实施的情况, 需要 针对以下几个方面进行 度量 和 反馈 ; ① 过程的有效性; ②过程效率; ③过程适用性;
• 4.使用者 的 反馈 : ① 鼓励员工主动反映意见和建议, 奖励突出者; ② 使用 调查表 , 提问表 ;
• 5.外部环境 : 吸收 外部的反映 建议, 这些外部环境包括如下几点 : ① 法律法规和标准的变更; ② 技术 方法 进步; ③ 政策调整 ; ④ 目标客户的 特征 需求的 变更 ;
• 6.检验 强制 机制 : ① 内部审核, ② 认证审核, ③依从性审核 或 评审 ;

3.成熟的软件过程

( 1 ) 成熟 与 不成熟

过程的 成熟 与 不成熟 :

• 1.过程发展 : 过程需要经历 不成熟 到 成熟 的发展历程 ; 成熟的过程才能 发挥应有的作用 ;
• 2.儿童 与 成熟的成年人 差异 : ① 计划性, ② 稳定性, ③ 能力, ④ 一致性, ⑤ 预测性 ;
• 3.组织成熟度 : 处于不同的 过程规范 成熟度 的 组织, 就像处于不同成熟状态的 人 一样 ;
• 4.过程的 成熟 关口 : 过程成熟需要经过 三个关口 : ① 僵化, ② 固化, ③ 优化 ;

( 2 ) 成熟 的 发展过程

成熟的发展过程 :

• 1.软件过程创建 : SPI ( Software Process Improvement ) 软件过程改进 的 第一步是 软件过程创建 ( SPC : Software Process Create ), 其中 C 是 Create ; 这是 SPIN ( Software Process Improvement Network ) 专家提出的;
• 2.僵化阶段 : 该阶段需要降低灵活性, 即 僵化, 障碍在这个阶段没有消除 ;
• 3.完成该步骤的条件 : 软件过程创建 需要行政力量 推进 ;
• 4.固化阶段 : 固化阶段开始真正消除障碍问题, 对应 障碍消除 ABO 阶段的 B 阶段; ABO : Awareness, Buy-in, Ownership, 即 了解, 接受, 拥有 ;
• 5.优化阶段 : 在上面 僵化 固化 的基础上, 开始改进, 开始 优化阶段 ;

( 3 ) 软件过程成熟度

软件过程的成熟度 :

• 1.软件过程成熟度 定义 : 软件过程的成熟度 指的是 特定的 软件过程 被 显式 ①定义, ②管理, ③度量, ④控制 和 ⑤执行 的程度 ;
• 2.软件过程成熟度 作用 : 成熟度 可以用于 指示 组织加强其软件过程能力的 潜力 ;
• 3.软件过程成熟度高级表现 : 当 组织 达到了 一定的 软件过程成熟度级别后, 软件过程会被 制度化, 进而成为 组织文化 ;

( 4 ) 不成熟的组织标志

不成熟的组织标志 :

• 1.没有软件过程 : 缺乏 确定的 软件过程 和 其相应的 管理 和 控制 ( 软件过程的 ) ;
• 2.有软件过程但不执行 : 定义了软件过程, 但是 不能严格 遵循 和 强制执行 ;
• 3.被动管理 : 管理完全是被动的方式, 策略是 救火 ;
• 4.计划不准 : 没有有效的 估算依据, 软件的 预算 和 计划 不准确, 经常超标 ;
• 5.产品不稳定 : 如果强制软件在预订期限完成, 那么软件的 功能 和 质量 无法保证 ;
• 6.没有评价体系 : 缺乏 ①评价软件产品质量 和 ②解决产品缺陷 和 过程问题 的 客观基础;

( 5 ) 成熟的组织标志

成熟组织的标志 :

• 1.有软件过程 : 在组织范围内, 有 管理软件开发 和 维护 过程的 能力 ;
• 2.过程得到遵守 : 所有人员都 ① 了解其要遵循的 软件过程, ②所有的工作都按照事先的计划完成 ;
• 3.责任分明 : 在被定义好的软件过程中, 所有 项目 和 机构 中的 角色 和 责任分明 ;
• 4.计划准确 : 计划 和 预算 有章可循, 基于***历史数据***, 因此计划是实际可行的 ;
• 5.预算准确 : 预算的结果通常能够达到, 如 ①成本, ②时间表, ③产品功能, ④质量 等 ;
• 6.有评价体系 : 有 客观 和 定量化 的措施, 用于判定 产品质量 并 分析 产品 与 生产过程中的问题 ;
• 7.基础设施 : 基础设施用于 支撑 软件过程, 如 标准过程库, 历史数据 ;

4. 过程规范 副作用

过程规范 的 副作用 : 过程规范要有一个度, 过犹不及;

• 1.无法定义具体工作 : 当前的软件工程技术, 无法 具体定义 软件开发的大多数 工作;
• 2.强制手段作用 :
  • ① 少用 : 强制手段的作用是 发现 并 纠正 少数 不符合过程要求的行为 ;
  • ② 威慑 : 强制手段 仅仅是 对破坏过程实施的人 的 威慑 ;

5. 过程认知的 误区

过程认知 的 误区 :

• 1.文件误区 : 有了文件 并 不等于 建立了过程, 还必须 遵守 并实施 过程 ;
• 2.记录误区 : 过程执行了, 必须记录, 不记录就不完整 ;
• 3.信任误区 : 员工按照 要求 执行过程, 必须进行培训, 改变平时的习惯需要 强制执行 ;
• 4.验证误区 : 过程不会自动实施, 实施了过程必须要验证, 目标是否达到 ;
• 5.稳定误区 : 过程建立了, 不能一成不变, 要 根据 环境, 商业目标 改变 而 改进 软件过程 ;
• 6.保证误区 : 得到了高层领导支持, 不一定有保证, 为业务工作带来效益才有保证 ;

四. 过程改进的必要性

过程改进的必须要性 : 给出了以下 六个 必须要持续改进过程的 理由 ;

• 1.性能降低 : 过程经过一段时间后, 其性能就会趋于降低 ;
• 2.需求提高 : 客户的需求会越来越高 ;
• 3.目标变化 : 组织的目标一直是变化的 ;
• 4.环境变化 : 组织所在的环境在不断变化 ;
• 5.对手改进 : 竞争对手在不断改进 ;
• 6.逐步成熟 : 组织的过程是 逐步成熟 的 ;

总结 : 凡是活动, 都存在过程 ; 凡是过程, 都存在改进 ; 凡是改进, 都没有终点 ;

五. 过程思维

1. 过程思维简介

( 1 ) 过程思维 简介

过程思维 :

• 1.过程思维定义 : 一个群里 为了 某个目标, 将每个人的 精力 和 活动 汇聚在一起, 用 对过程的 共同理解 去考虑问题 ;
• 2.自然思维方式 : 过程思维 是 一种 自然思维方式 ;
• 3.传统思维 : 过程思维 和 传统的任务思维 有着本质的区别 ;

( 2 ) 过程思维 观点

过程思维观点 :

• 1.马云: 不要让你的同事为你干活, 要让他们为共同的目标干活; 团结在一个共同的目标下, 比在一个人周围容易的多 ;
• 2.Watts Humphrey : 解决软件问题的重要一步, 是 把整个软件工作, 当做一个过程 来对待, 使其能够控制 度量 和 改进 ;
• 3.James Harrinton : 要学会用过程来思考事物 ;

2. 面向过程 与 面向任务组织 区别

面向过程 与 面向任务 组织 的区别 :

• 1.面向任务的思维 :
  • ① 注重点 : 注重 任务, 作业, 人员, 组织架构
  • ② 流行期 : 在最近 200 年 流行 ;
  • ③ 特点 : 将任务分解, 指派人员完成, 解决局部问题 ;
  • ④ 影响范围 : 机构的 组织结构 ;
• 2.面向过程的思维 :
  • ① 注重点 : 注重 总体目标, 协调性, 一致性 ;
  • ② 流行期 : 在最近 20 年 流行 ;
  • ③ 特点 : 清除各部分工作之间的冲突, 提高总体效率, 有效达到总体目标 ;
  • ④ 影响范围 : 机构的全部活动 ;

面向任务思维型的组织不是没有过程, 只是这些组织的 过程不一致, 不协调, 每个人都有自己的过程, 过程有很大随机性, 并且改变没有规则 ;

3. 以过程为中心 与 以产品为中心 区别

以过程为中心 与 以产品为中心 的区别 :

• 1.以产品为中心 :
  • ① 结果 : 产生 更多的 具体结果, 将文档化的工作程序 理解成 过程 ;
  • ② 对结果的认知 : 人为 每个 活动 都应该直接 产生短期结果 ;
  • ③ 过程的重视程度 : 管理者 将 与过程相关的工作 当成 低优先级的活动, 人为 过程 无关紧要 ;
• 2.以过程为中心 :
  • ① 结果 : 过程 会对 最终结果, 组织, 生产者 , 及 三者间关系 造成影响 ;
  • ② 对结果的认知 : 认为 具体结果 只是 全局中的一部分 ;
  • ③ 对过程的重视程度 : 过程文档 是执行过程的一个工具, 过程本身被认为是 商业运作的规范 ;

六. 过程 描述方法

1.文字描述法

文字描述法 描述 过程 :

• 1.描述方式及内容 : 以 流水账的形式 描述过程, 说明 完成工作 的 时间 地点 人员, 交付的产品, 以及如何 验证结果 ;
• 2.优点 : 内容翔实, 交代透彻 ;
• 3.缺点 : 过程枯燥繁杂, 不利于查阅 ;
• 4.格式 : 分为 一级, 二级, 三级 等 分层 描述 , 类似于本博客 ;

2.表格法

表格法描述过程 :

• 1.描述方式及内容 : 表格法易于表示二维 或 三维 关系, 如 事件, 角色, 输出 之间的 关系, 对于表达 复杂角色之间的流程转换 具有优势 ;
• 2.横轴 : 团队 或 角色 ;
• 3.纵轴 : 活动 ;
• 4.平面 : 关系 与 流程 ;

3.图示法

图示法 :

• 1.前提 : 使用图示法之前, 先要定义 图片符号的 含义 ; ANSI ( 美国标准协会 ) 编制了比较完善的 图例 ;
• 2.优点 : 清晰简明, 信息量高;
• 3.缺点 : 对于复杂的情况, 图示法不能表示清除, 常用 图示法 + 文字法 结合使用 ;

4.部门流程图法

部门流程图 : 部门流程图 用于 反映 信息在不同部门之间的 流转; 尤其是 部门 和 角色转换频繁的情况;

七. ISO 9000 过程模型介绍

1. IOS 9000 简介

ISO 9000 简介 :

• 1.简介 : ISO 9000 是一个 质量管理体系 的标准族, 用于帮助 组织确保满足 客户 和 利益相关者的需求 ;
• 2.ISO 9000 作用 : ① 指导 组织 建立 和 改进 质量体系 ; ② 质量体系评估 ;
• 3.制定者 : ISO 在 1994 年被提出, 由 ISO( 国际标准化组织 )/TC176 ( 质量管理和质量保证技术委员会 ) /SC2 ( 质量体系分委员会 ) 制定的国际标准 ;
• 4.实施时间 : ISO 9001:2008 质量管理系统 标准 在 20098年10月31日 正式发布实施 ;
• 5.ISO 9000 标准族 :
  • ① ISO 9001:2008 : 规定了质量管理体系的要求 ;
  • ② ISO 9000:2005 : 涵盖了基本的概念和语言 ;
  • ③ ISO 9004:2009 : 重点说明如何使质量管理体系更有效;
  • ④ ISO 19011:2011 : 规定了质量管理体系 内部 和 外部 的 设计指南 ;
• 6.ISO 9000 主要内容 :
  • ① 范围
  • ② 引用标准
  • ③ 术语 与 定义
  • ④ 质量管理体系
  • ⑤ 管理职责
  • ⑥ 资源管理
  • ⑦ 产品 / 服务 实现
  • ⑧ 测量 , 分析 和 改进

2. GB/T 19001-2008

中文版本 GB/T 19001-2008 : GB/T 19001-2008 是我国 全国质量管理和质量保证标准化技术委员会 （CSBT/TC151） 针对ISO9001:2008标准翻译而来的 中文版国家推荐性标准，标准的内容保持一致。

• 1.标准号 : GB/T 19001-2008 ;
• 2.标准名称 : 质量管理体系 要求
• 3.发布实施日期 : 2008-12-30 发布, 2009-03-01 实施 ;

3. ISO 9000 标准的科学依据

ISO 9000 标准的 科学 依据 :

• ① 质量检验 ( Quality Inspection )
• ② 质量控制 ( Quality Control )
• ③ 质量保证 ( Quality Assurance )
• ④ 全面质量控制 ( Total Quality Control )
• ⑤ 全面质量管理 ( Total Quality Management )

4. 质量管理八原则 ( 重点 )

质量管理八原则 :

• 1.以顾客为关注焦点 : 组织***依存于客户*** ; 组织需要 理解 顾客 当前 和 未来 需求 , 满足顾客要求 并 争取 超越 顾客 的期望 ;
• 2.领导的作用 : 领导者 需要 确定 本组织 统一 的 宗旨 和 方向, 营造 和 保持 一种内部环境, 使员工 能 充分参与 , 并实现组织目标 ;
• 3.全员参与 : 各级人员都是组织之本 ; 只有所有人员充分参与, 才能使 他们的 才干 为 组织 带来收益 ;
• 4.过程方法 : 将先关 资源 和 活动 作为 过程 进行管理, 可以高效地得到期望的结果 ;
• 5.系统管理 : 将 相互关联的过程 作为系统 加以识别, 有助于组织 提高实现其目标的 有效性 和 效率 ;
• 6.持续改进 : 组织的 一个关键的 永恒目标是 持续改进 总体业绩 ;
• 7.以事实为决策依据 : 有效的决策 是 建立在 数据 和 信息分析 的基础上的 ;
• 8.互利的供方关系 : 组织 与 供方是 相互依存的, 互利的关系 可以增加 双方创造价值 的能力 ;

5. 质量管理

( 1 ) 质量形成

质量形成 :

• 1.观点 : 质量形成于生产过程 ;
• 2.涉及范围 ( 所有环节 人员 ) : 产品质量 涉及到生产的所有环节, 只有 与生产有关的所有人员 重视 质量, 最后才能得到高质量的产品 ;
• 3.质量制造 : 质量是制造出来的 ;
• 4.管理问题 : 85% 的 质量责任 在于 管理不善; 各层管理人员 和 操作人员 一起学习 和 运用 统计技术, 用 数据说明问题, 指导质量的改进 ;

( 2 ) 控制影响质量的全部因素

全面质量控制 :

• 1.观点 : 必须使 影响处理产品质量的全部因素 在生产全过程中 始终处于受控状态 ;
• 2.贡献者 : 质量管理专家 A.V.Feigenbaum 提出 质量体系概念, 形成 全面质量控制 TQC 的最重要的内容 ;
• 3.质量体系 : 制造 及 传递 某种 合乎特定质量的 标准产品 时, 必须配合适当的 管理 及 技术作业程序, 这些 程序所组成的 结构 称之为 质量体系 ;

( 3 ) 持续保持质量 的 能力

持续保持质量的能力 : 生产企业 建立 质量体系, 就能 对所有影响质量的因素, 包括 技术, 管理, 人员 等诸方面 采取有效方法进行控制, 具有 减少, 消除 和 预防质量缺陷 的机制 ;

( 4 ) 质量改进 - 质量管理必须坚持进行质量改进

质量改进 :

• 1.持续改进观点 : 质量管理 必须坚持进行 质量改进 ;
• 2.主动改进 : 质量改进工作 应该 致力于 经常寻求改进机会, 不能 等待问题暴露后再去抓机遇 ( 被动改进 ) ; 质量改进是永无止境的 ;
• 3.改进没有期限 : 质量改进是长期的, 采用专案小组的形式, 不断提高标准 并 及时解决质量改进的问题 ;
• 4.全员负责 : 不断研究 和 改善质量制度, 是各级生产人员的责任 ;

( 5 ) 质量管理中 体现 PDCA 循环 ( 戴明环 )

质量管理中的 PDCA 循环 :

• 1.PDCA 循环 : Plan 计划, Do 实施, Check 检查, Action 措施 ;
• 2.管理工作要求 : 任何管理工作 ( 包括 质量管理 工作 ) , 都应该按照 PDCA 循环进行 ;
  • ① Plan 计划 : 计划 , 策划 , 工程设计 ;
  • ② Do 实施 : 实施计划 , 组织施工 ;
  • ③ Check 检查 : 检查 , 检验 , 测试 ;
  • ④ Action 措施 : 针对发现的问题 , 采取纠正措施 或 相关行动 ;

( 6 ) 预防是核心 不是补救

预防 是 核心 : 质量管理的核心是预防, 不是补救 ;

• 1.成熟机构的素质 : 建立了有效的质量保证体系以后, 可以 及时 纠正, 特别是能 预防质量问题的发生, 这是 成熟的 生产机构 的良好素质 ;
• 2.主动预防优势 : 预防是主动的, 在 质量事故之前 发生的 ; 检验 和 补救 是被动的, 代价昂贵 ;

八. SPICE ( ISO/IEC 15504 )过程模型介绍

1. SPICE 标准简介

SPICE 简介 :

• 1.全称 : Software Process Improvement and Capability Determination , 软件过程改进和能力测定 ;
• 2.发起人 : ISO , IEC, JTC1 在 1993 年发起 ISO 15504 标准, 即 SPICE ;
• 3.发布过程 :
  • ① 1994年 , SPICE 第一个基准文件发布 ；
  • ② 1998年 , SPICE 发布 ISO 15504TR 技术报告 ;
  • ③ 2003 ~ 2004 , SPICE 正式发布 ISO 15504 前四部分, <1>概念和词汇 , <2>实施评估 , <3>实施评估指南 , <4>过程改进 和 能力确定应用指南 ;
  • ④ 2006 年 , SPICE 公布 ISO 15504 第五部分, <5>软件过程评估 ;
  • ⑤ 2008 年, SPICE 公布 ISO 15504 第六部分 , <6>系统过程评估 ;

2. SPICE 标准新进展

SPICE 新进展 :

• 1.开放集成 : SPICE 标准 更加 开放 和 集成 , 备受产业用户欢迎 ;
• 2.行业自订 SPICE 标准 : 很多行业对软件开发有特殊要求, 行业内会建立自己行业特定的 SPICE 标准, 如 金融, 汽车制造, 航空航天, 医疗仪器, 铁路等 ;
• 3.中航天 SPICE 标准 : 中航天的 SPICE 标准 S4S 得到欧洲航天局支持, 其特色是 风险管理 ;

九. 6

过程模型介绍

1. 6

由来

6

提出 :

• 1.概念提出 :
  • ① 提出者 : 6

  \sigma

  概念是 1986 年摩托罗拉的 比尔 史密斯 提出 ;

  • ② 范畴 : 6

  \sigma

  概念属于质量管理范畴 ;

  • ③ 统计学单位 :

  \sigma

  是统计学单位, 表示与平均值的标准偏差 ;

  • ④ 目的 : 6

  \sigma

  目的是为了在生产过程中降低产品 及 流程的缺陷次数 ;

• 2.6

演进 : 90 年代中期, 6

被 GE 从 全面质量管理方法 演变成 高度有效的企业流程设计, 改善 和 优化 的技术 ;

• 3.内容 : 提供了一系列适用性广泛的 用于 设计 , 生产 , 服务 的 新产品开发工具 ;

2. 6

管理法概念

6

管理法 概念 :

• 1.概念 : 6

是 统计评估方法, 其核心是 ①生产时 追求 0 缺陷 , ②防范产品责任风险 , 降低成本 , ③提高生产率 和 市场占有率 , ④提高顾客满意度 和 忠诚度 ;

• 2.关注点 : 6

管理 关注 产品 , 服务 质量, 同事也关注 过程改进 ;

• 3.目标 : 6

是 质量目标, 所有过程 和 结果 中 99.99966% 是没有缺陷的, 即 100 万产品中 , 只能有 3.4 个是有缺陷的, 这是人类当前能达到的最高水平 ;

3. 6

定义

6

管理定义 :

• 1.定义 : 6

管理 是 通过 减少波动, 不断创新, 达到 缺陷率逼近 百万分之3.4 的质量水平, 实现顾客满意 和 最大收益 的 系统科学 ;

• 2.6

作用 :

• ① 管理 : 6

是 卓越 管理 的 指南针 ;

• ② 流程能力 : 6

是 衡量流程能力 的尺子 ;

• ③ 流程改进 : 6

是 进行 流程改进 的工具 ;

4. 6

过程思想

6

过程思想 :

• 1.关注过程 : 6

管理 关注 过程 , 重点是 企业 为 市场 和 顾客提供价值 的 核心过程 ;

• 2.过程能力度量 : 过程能力 使用

进行度量,

值越大, 过程的 波动就越小 , 过程以最低的成本损失 , 最短的时间周期, 满足顾客要求 的能力就越强 ;

5. 6

等级

6

等级 :

• 1.等级说明 : 针对 1 ~ 6 级

等级, 分别对 缺陷个数, 失败率 进行说明 :

• ① 1

: 100万 中 有 69.1462 万 个次品, 69% 次品率 ;

• ② 2

: 100万 中 有 30.8538 万 个次品, 31% 次品率 ;

• ③ 3

: 100万 中 有 6.6807 万 个次品, 6.7% 次品率 ;

• ④ 4

: 100万 中 有 6210 个次品, 0.62% 次品率 ;

• ⑤ 5

: 100万 中 有 233 个次品, 0.023% 次品率 ;

• ⑥ 6

: 100万 中 有 3.4 个次品, 0.00034% 次品率 ;

• 2.现状 : 多数企业在 3

~ 4

之间的状态运转, 100万产品中 有 6210 ~ 66800 个次品, 需要 15% ~ 30% 的销售额弥补带来的损失, 如果做到 6

, 只需要 5% 销售额损失 ;

6. 6

计算方法

过程能力指数 :

• 1.指标 : 过程能力指数 ( Process Capability Index ) 有两个 指标, Cp 和 Cpk ;
• 2.Cp : 过程满足技术要求的能力 ;
  • ① 计算公式 : Cp = ( 最大值 - 最小值 ) / 6

  \sigma

• 3.Cpk : 过程平均值 与 产品标准规格 发生偏移 的大小 ;
  • ① 计算公式 : Cpk = MIN( 最大值 - 过程平均值, 过程平均值 - 允许最小值 ) / ( 3 *

  \sigma

  )

十. PCM 过程模型介绍

1. PCM 简介

PCM 过程模型简介 :

• 1.PCM 定义 : PCM ( Product Cycle Model ) 是微软的 开发产品 和 服务 的模型 ; 其 提供 以下标准 ;
  • ① 待开发的产品 及 服务 的 类别 ;
  • ② 如何 定义 开发团队 ;
  • ③ 如何 确定 最终客户 及 市场 ;
• 2.迭代特点 : PCM 是一个 迭代的, 非线性的过程 ;
• 3.五个阶段 : PCM 有 5 个不同的阶段 ;
  • ① 计划 ( Plan )
  • ② 设计 ( Design )
  • ③ 实现 ( Implement )
  • ④ 稳定 ( Stabilize )
  • ⑤ 发布 ( Release )

2. 计划阶段

PCM 计划阶段 :

• 1.主要工作 : 在 PCM 计划阶段, 团队成员 需要 评估 产品 及 服务 的 市场机会 ;
• 2.工作内容 : 研究客户对于 产品 及 服务 的 需求 , 依赖于产品 及 服务 的远景规划 , 根据规划定义产品 及 服务 的 功能及基数范围 , 并且 制定详细的过程 ;

3. 设计阶段

PCM 设计阶段 :

• 1.主要工作 : PCM 设计阶段, 团队成员 需要从客户角度思考 如何设计产品 及 服务 ;
• 2.PCM 设计阶段的决策 : 以下决策是在 设计阶段 完成的 :
  • ① 产品特征 : 产品 及 服务 功能 的特征 ;
  • ② 协调工作 : 各功能模块 如何 协调一致 工作 ;
  • ③ 构建方式 : 开发团队 如何构建产品 及 服务 ;
  • ④ 周期评估 : 开发周期评估 ;
• 3.屏蔽开发问题 : 该阶段 不考虑 开发问题, 如 实现难度 , 程序框架 等 问题 ;

4. 实现阶段

PCM 实现阶段 :

• 1.主要工作 : 依赖于 前两个 阶段的工作, 开发团队在 实现阶段 开始 构建所需的产品 及 服务 ;
• 2.编码 : 对于软件工程师来说, 主要工作就是编码 ;
• 3.宣传 : 同时开启市场的前期宣传 ;

5. 稳定阶段

PCM 稳定阶段 :

• 1.主要工作 : 在 PCM 稳定阶段, 开发团队 需要 确认 产品 及 服务 是否符合 认可的规则 ;
• 2.测试版本 : 发布测试版本 ;
• 3.具体工作 : 测试 , 修改 BUG, 完善产品 ;
• 4.避免重大变更 : 该阶段 一般 不对 产品 做 重大变更 ;

6. 发布阶段

PCM 发布阶段 :

• 1.主要工作 : 完成产品正式推出前的所有准备工作 ;
• 2.发布 RTM 版本 ;
• 3.维护 : 开启产品的运行维护服务 ;

十一. SW-CMM 过程模型介绍

1. CMMI 版本发展

( 1 ) CMMI 版本发展

CMMI 版本发展 :

• 1.CMMI V1.2 版本 : 2006.9 SEI/CMU 发布 CMMI V1.2 版本 , 扩展了 三个 模型 :
  • ① CMMI-DEV 开发能力成熟度模型 ;
  • ② CMMI-ACQ 采购能力成熟度模型 ;
  • ③ CMMI-SVG 服务能力成熟度模型 ;
• 2.CMMI V1.3 版本 : 2010年 11月 发布 ;
  • ① 高成熟度实践 , 评估效率 , 跨模型群一致性 , 简化通用实践 ;
  • ② 将 6

  \sigma

  和 敏捷 方法 加入到 模型相关的实践信息中 ;

• 3.CMMI V2.0 版本 : 2018.3.29 CMMI Development V2.0 发布, 过程改进领域进入到了新的阶段 ;

( 2 ) CMMI 2.0 重大变化

CMMI 2.0 变化 :

• 1.过程数量变化 :
  • ① 过程域增减 : 过程域由 22 个减少到 20 个, 取消了 共用目标 和 共用实践 , 将其放入新增的两个过程域 GOV 和 II 中 ;
  • ② 注重基础 : 共用目标 和 共用 实践 是组织实施 CMMI 的基础 , 提升了其重要性 , 使组织重新审视这些基础, 有效帮助 CMMI 更好执行 ;
• 2.专用目标 升为 过程域 : 专用目标 ①项目评估 和 ②同行评审 , 属于 项目策划过程域 和 验证过程域 ; 在 2.0 中, 其升级为 EST 和 PR ;
• 3.过程域整合 : 2.0 中一些 关联紧密的过程域 进行了 整合 ; 如 需求开发过程 RD + 需求管理过程 REQM = RDM 过程域 ; 验证过程 VER + 确认过程 VAL = VV 过程域 ;
• 4.每个过程域 都包含 1 ~ 5 级内容 :
  • ① 等级与过程域无关 : 过程域 与 CMMI 等级 不在挂钩, 每个过程域 都给出了 1 ~ 5 级要求 ;
  • ② 实践域域内部等级 : 每个 PA ( 实践域 Practice Area ) 都包含 1 ~ 5 及内容, 每一级别都要在前一个级别的基础上, 逐步提升 ; Practice x.y 代表 CMMi 的 x 等级 的 第 y 个实践 ;

2. CMMI 简介

CMMI 简介 :

• 1.CMMI 说明 : CMMI ( Capability Maturity Model Integration ) 能力成熟度模型集成 , 明确定义一个组织应该采取什么行动 来 定义 , 理解 , 推进 有助于提高其性能的 行为 ;
• 2.CMMI-DEV 开发能力成熟度模型 包含内容 : CMMI-DEV 有 5 个成熟度级别, 3 个能力级别 ; 定义了 开发产品 和 服务 最重要的 300 条实践, 将其囊括在一个综合模型中 ;
• 3.CMMI 作用 : CMMI 可以帮助公司 确定 并 实现 可度量 的业务目标 , 打造 出色产品, 保证客户满意 并 确保尽可能高效工作 ;
• 4.识别改进差距 : CMMI 可以帮助组织 识别 并 改进 差距 ;

3. CMMI-DEV V2.0 模型结构

CMMI-DEV V2.0 模型结构 :

• 1.实践域 : CMMI-DEV V2.0 有 20 个 实践域 ( PA - Practice Area ) , 每个 PA 中的 实践 按照 等级分组, PA 最少 2 级, 最多 5 级 ; 每个 PA 都需要包括 下述内容 :
• 2.必须满足的内容 :
  • ① 意图 ( Intent )
  • ② 价值 ( Value )
  • ③ 其它必要内容
• 3.阐述解释内容 :
  • ① 实践汇总
  • ② 其它阐述内容
  • ③ 相关实践域
  • ④ Context Specific 信息
• 4.实践组 :
  • ① 1 ~ 5 级级别之间的关系 : 1 ~ 5 级, 每一个级别都需要在前一个级别的基础上, 逐步提升 ;
  • ② 实践个数 : 每个级别都有 若干个 实践 ;
• 5.实践 :
  • ① 必须满足的内容
  • ② 阐述解释的内容

4. CMMI 商业价值

CMMI V2.0 商业价值 :

• 1.提升绩效 : 通过 给出 演示结果, 提供 基准 和 提升组织 绩效 的最佳解决方案 ;
• 2.提升效率 : 组织可以快速识别 直接 业务成果 , 投资回报率 , 质量 和 绩效 相关的关键能力 , 同时降低成本 并 加快上市时间 ;
• 3.提升能力 : 专注于将绩效优化到组织所需要的等级 , 利用 最佳实践 有效 建立 持续改进的 文化氛围 ;
• 4.量化分解 : CMMI 成熟度高时 , 对 风险 和 预测业务绩效目标成就 的 能力 进行量化分解 ;

博客相关资料下载 : 下载地址