第二讲项目管理 软件改进过程

SQA, Software Quality Assurance
SCM, Software Configuration Management

保密原则
– –
–

卷入高层管理者的原则
– – –

吸取被评估组织观点的原则
–
–
–

面向活动的原则
– –
4.3 项目管理在CMM中的位置
软件能力成熟度模型CMM（Capacity Maturity Model），由美国国防部资助，于1986年在Carnegie Mellon University的SEI开始研究，于1991正式推出 CMM 1.0，1993年推出CMM 1.1。此后，SEI还完成 了CMMI（Capacity Maturity Model Integration）。目 前推出了CMM 2.0。CMM事实上已经成为国际软件业 衡量软件企业软件过程改进管理水平的标准。本讲稿 重要参考资料《软件过程管理》的作者瓦茨·汉弗莱 （Watts S. Humphrey）是CMM的提出者。
4.4 项目管理推动软件过程改进
计划 跟踪 控制 分包
可 重 复 级
已 定 义 级 已 管 理 级 可 优 化 级
阶段的计划：产品大小、资 源、人员、进度、检查点
SQA下标准和过程的监 管：达到阶段计划的阶 段内容（如左）。
需求、编码、测试阶段 的变更与配置，稳定的 工作量估计
分包者的责任-资源， 分包计划、SQA标准、 过程标准的评审和复 审
4.1 软件过程改进的六条原则



改变的动力来自于领导 过程问题是管理者的责任；通过管理活动改变系统；长期计划、优先级、资源的支持。 改变将卷入每个人 成熟的软件过程，人的活动更结构化、更有效、更相关；组织的活动而不是个人的活动。 改变需要当前过程的知识和明确的目标 是什么的问题；改变处于什么位置的问题；评估知识；控制、协调的知识。 改变是持续过程 人敏感的活动；动态的而不是静态的；三个特点：反作用；“背叛”；“放把火的英 雄”。 改变需要自觉的努力和定期加固 如果没有持续的推进工作，要人保持一种精确的活动，很难。 引入（installation） 实践（practice） 熟炼（proficiency） 成为自然（naturalness） 改变需要投资 训练！训练！训练！
SQA下标准和过程的监 SCM下的工具和方法， SCM下的过程定义和标 管：到达过程计划的活 动级，包括设计、编码， 准 和标准与方法 SQA下质量计划，质量 改进计划 SCM下针对每个项目的 标准过程的具体化， SCM下的过程矩阵（如 WBS）维护 SCM下的对构件维护： 定义与复用
SQA下生产力计划和过 程改进计划
3.4 改进的思路

系统化的项目管理 严密的变更管理规程 独立的项目管理组织



计划 跟踪和维护计划 工作细分 每件工作的精确定义 严格控制部分与整体的关系 把软件开发当作学习过程 辨识出不知道的东西 要处理它必须先知道它 管理、评审和复审 适时改进计划
4 项目管理与软件过程
I ）初始级：可能是无序的。可能的初步统计控制，能够达到初步的进度和 费用预算。不能够有序地支持过程改进。
II ）可重复级：在严格的任务、费用、进度和变更管理下建立起稳定的过程 和可重复的统计控制。
III ）已定义级：组织的统一、一致、易于理解的过程基准已经建立，先进的 技术可以充分引进。
IV） 已管理级：组织的完整的综合的过程度量和分析体系已经建立。这意味 着有意义的过程改进可以开始。 V ）优化级：组织的持续创新基础已经建立，可优化的过程体制已经形成。
3.3 软件过程熵
软件过程的熵是评定软件过程无序程度的 等级。存在若干因素，即使对于一个已经建立 了项目管理体制的组织，趋向于破坏有序的软 件过程管理（即熵的增加）。影响软件过程熵 最主要的因素有三类：
– – –
不确定的需求（直到项目完成前，不能真正理解 “做什么”和“怎样做”） 增长的软件编码（需求变更，问题暴露） 人的天性（情感影响行为，动机、等级、责任）
建立分类的分包标准 过程，分包的跟踪机 制，分包的SQA监管 分包耦合控制；分包 质量矩陈、分包SQA 的执行的跟踪 分包过程改进机制， 分包的过程改进和生 产力改进的SQA监管
过程的计划：资源估计到达 活动点，异常的经验估计， 引入风险计划，专门技能人 员配置 质量计划：质量保证导入过 程，可适时引入质量改进计 划 量化的度量与统计：每个项 目的过程改进计划，组织的 生产力改进计划
“古鲁的自信”
– – – – – –
–
–
只有一个人知道程序细节和存在问题。 不知道怎样从分析，到设计，再到编码 的过渡。 不知道分解系统成为子系统和构件。 多个版本出现而不知道我现在用的是哪 个版本。 公共使用的符号、词汇没有准确定义。 标准之间的矛盾没有解决。 不可能一次完成所有的模块，不只道怎 样安排进度。 在看不到运行效果时不知道设计是否正 确。 版本更新时不知道新版本对系统的影响。

遵循评估基准的原则
– – –
必须有一个同类型的参考模式，如CMM框架（必须适合企业，有基准参数，如能力、成本） 坚持全局概念，避免只集中于自己参与的部分 单一目标可能导致不一致的结果 保持被评估企业的商业秘密 尊重被调查者的隐私权 领导者不在场的调查 “没有领导者参与的评估是浪费时间” 解决方案必须得到管理者的支持 管理者的观点是最有影响的观点 外部专家并不像想象的聪明 外部专家不能只是“能够理解”，而且要“适当”分析 要有享用企业知识的自觉 不能满足于一般的解释 必须集中于问题所在，获得解答方案
4.2 软件过Hale Waihona Puke Baidu评估
软件过程评估是为了找出当前软件开发过程中存 在的问题，区分问题的程度，提出过程改进提案的活 动。“人很难发现自己的问题”，区分软件评估活动 和软件开发活动是必要的。过程评估与产品评估也是 不一样的，后者是对生产物是否满足要求的检查，前 者是对生产过程是否满足要求，是否存在改进可能的 检查。




准备阶段：高层领导对评估提案的目的、原因、计划、预期的建议、评 估小组的体制和人选、费用进行研究、评审，并做出结论和指示。可能 需要1-2天，进行评估小组的培训。 评估阶段：实施评估活动和写出“问题定义报告”（Finding Report）。 可能需要几天或几周，取决于企业的规模和可采用的技术。 建议阶段：研究“问题定义报告”，提出解决方案，写出评估报告 （Evaluation Report）。
一种评估报告的三段论式：[参见《美国总统信息技术咨询委员会给总统的报告 1998.8》]
– – – – –
标题（Title） 概述（High Spots） 目的（Objectives） 问题（Findings） 建议（Recommendations）
4.2.3 过程评估的五项基本原则
“成功的评估需要权威能干的评估小组、有力的领导和合作的组 织。”这是一条基本原理。针对软件过程的特殊性，还有以下五条特殊原则：
3 无序的软件过程
无序的软件过程是卡内基.梅农大学SEI对 缺乏有效管理控制的软件过程的定义，被列为 CMM初始级。本节通过无序过程的讲述，提 出造成过程无序的原因，最重要的影响因子和 改进的思路。
3.1 无序的软件过程特征
无序的软件过程就是缺乏有效管理、准确定义、 事前计划和过程控制的软件开发过程。 做计划、做预算、搞开发没有一套规格化的表达形式 和评估机制。 所采用的工具不一致，也没有集成。 变更控制是松散的。 缺乏管理经验和正确理解问题的能力。 问题被遗忘或者经常被推迟解决，到安装或运行中才 发现。
4.3.3 CMM框架中项目管理的内容
I）初始级PM：可能是无序的。不能够有序地支持过程改进。 II）可重复级PM：实施计划管理。计划达到阶段。按计划进行阶段评审。 外包项目亦纳入计划管理范围。 III）已定义级PM：风险管理被纳入计划。项目过程已定义，计划达到过 程。评审跟踪到过程。外包项目亦纳入已定义过程的跟踪评审。 IV）已管理级PM：质量管理被纳入计划。包括项目的质量计划和项目 质量改进活动计划。 V）优化级PM：生产力的效果、过失可以被度量、统计、分析。阶段的 计划、过程的计划、质量的计划可以被改进。相应的机制、组织、责任 已经建立和落实。
项目管理通过过程控制进行。第一、二章 讲了项目管理的基本原理、基本方法和基本过 程，下文还要分章节细致讨论。正如第三章所 述，熵的增加“即使对于一个已经建立了项目 管理体制的组织，趋向于破坏有序的软件过程 管理”，本章引入软件过程改进概念，任何规 范的软件过程都不是一成不变的，必须能够改 进，以适应具体的组织、工程、技术、人员的 特点。[《软件过程管理》Cpt.1,2,3]

项目管理project management涉及项目的一般活动
– – – –

过程管理process management涉及导入项目和支持项目的活动
– – – –

技术technology涉及应使用的技术和环境
–
4.3.2 CMM等级框架
CMM按照过程管理的水平分为五个等级。每个等级都有相同的结构框架 和要素。只是每个要素在不同等级有不同水平要求。

过程评估的目的 过程评估的阶段 过程评估的五项基本原则
4.2.1 过程评估的目的

研究怎样组织企业的开发、管理与控制活动； 发现过程中存在的问题，并且定义主要问题； 提出改进过程的解决方案，使之成为领导人的 主张。
4.2.2 过程评估的阶段
分为准备、评估、建议三阶段。针对过程变更提案（任何人所提出的）：



3.2 软件过程无序的原因
“人不愿意承认自己的无知”— —软件复杂性问题。
–
“软件魔方”——软件规模问题
– – – – – – –
–
–
客观存在太多的未知因素：问 题域和软件本身 竞争的压力导致无计划的承诺： 目的和内容不明确 看似简单而忽略了计划：时间 和资源不足 相信自己能够做任何事情 拒绝承认和利用前期成果 随意改变原来的安排 “相信奇迹会发生” 不愿意花费时间做项目的前期 工作（需求分析） 在复杂问题面前徘徊


CMM结构框架 CMM等级框架 CMM框架中项目管理的内容
4.3.1 CMM结构框架

组织organization涉及软件组织的管理领导活动
– – – – –
政策policy建立组织行为的基准。 资源resources分配工作责任和资源。 失察oversight察觉执行情况。 通信communication保证活动及时利用适当的知识。 训练training开发使用适当的标准、过程、方法和工具的个人能力。 计划planning提出项目提案并在计划体制下实施项目计划活动。 跟踪tracking检查是否按计划执行及其效果。 项目控制project control对项目的关键要素提供保证与控制。 分包subcontracting按照既定政策、标准、过程，分解责任-资源。 过程定义process definition定义任务的执行、评价、改进过程标准框架。 过程执行process execution定义生产高质量产品的方法和技术。 过程分析process analysis定义软件产品和过程的度量模式及其数据模型。 过程控制process control定义过程执行、监管、改进所应遵循的机制。 技术置入insertion提出和导入所需要的技术，集成支持过程执行和管理的设施和工具。
项目管理
第二讲 软件改进过程
丁志强 2005-5-18
主要内容

无序的软件过程 项目管理与软件过程
– – –
–
–

软件过程改进的六条原则 软件过程评估 项目管理在CMM中的位置 CMM框架中项目管理的内容 项目管理推动软件过程改进
参考书:瓦茨.S.汉弗莱，《软件过程管理》，清华大学出版社，2002.