导图社区 IT项目管理
- 134
- 3
- 1
- 举报
IT项目管理
IT项目管理期末复习笔记， 包含项目确立、软件项目管理、软件项目进度管理、软件项目成本管理、软件项目质量管理等内容。适用于期中期末复习。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
- IT项目管理
- 软件项目管理
- 相似推荐
- 大纲
IT项目管理
第一章 概述
1.1 项目管理的重要性
1.2 什么是项目和项目管理
项目的概念
项目是在一定的资源约束下完成既定目标的一次性任务
为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力；是以一套独特而相互联系的任务为前提，有效地利用资源，在一定时间内满足一系列特定目标的多项相关工作的总称
项目与日常活动的比较
项目的要素
时间、质量和成本三要素简称TQC
质量、成本、时间三者相互制约
范围
指为了实现项目目标必须完成的所有工作
时间
指与项目有关的时间因素，用进度计划描述
成本
指完成项目所需要的所有费用
质量
指项目明确或隐含的需求，与绩效和满意度有关
项目的主要特点
具有明确的目标
受预算、时间等限制
具有生命周期
独特性
风险性
项目管理的概念
原始概念“对项目进行管理”
内涵
项目管理属于管理的大范畴 项目管理的对象是项目
三种不同的含义
指一种管理活动，即有意识地按照项目的特点和规律，对项目进行组织管理的活动
指一种管理学科即以项目管理活动为研究对象的一门学科，探求项目活动科学组织管理的理论与方法
已成为一种最受组织欢迎的管理工具，组织、公众或个人通过项目管理改善内部运作，快速响应外部机遇，取得技术突破，改进新产品开发
以项目为对象的系统管理方法
通过一个临时性的专门的柔性组织，对项目进行高效率的计划、组织、指导和控制；以实现项目全过程的动态管理和项目目标的综合协调与优化
项目全过程的动态管理
在项目的生命周期内，不断进行资源的配置和协调，作出科学决策，从而使项目执行的全过程处于最佳的运行状态
项目目标的综合协调与优化
项目管理应综合协调好时间、费用及质量等约束性条件，在资源约束下成功地实现特定目标
1.3 项目管理应用的发展
1.4 项目管理过程
1.5 项目成功与失败
第二章 项目确立
2.1 项目评估
2.1.1 项目启动背景
2.1.2 可行性分析
评估
战略评估
从整个企业的角度来评估项目的可行性
操作性评估
重点从系统本身、人员等方面进行评估
计划评估
重点评估项目计划是否可行
技术评估
对开发的系统进行功能、性能和限制条件的分析，确定技术风险的大小
社会可行性评估
从法律、社会等方面进行评估
经济可行性评估
对项目投资和可能产生的效益进行分析
2.1.3 成本效益评价
经济评价指标
现金流预测
描述何时支出费用、何时有收益的过程
净利润
在项目的整个生命周期中总成本和总收入之差
投资回报期
达到收支平衡或者偿还初始投入所花费的时间
投资回报率（ROI）
ROI=（平均年利润/总投资）*100%
净现值（NPV）
NPV=第t年的NPV/(1+r)t，r为贴现率，t为现金流在未来出现的年数
2.2 项目立项
2.2.1 立项流程
2.3 项目招投标
甲乙双方任务
甲方（需方）
招标书定义、供方选择、合同签署
乙方（供方）
项目选择（从获得商机到与客户签订项目合同的过程），具体包括项目分析、竞标、合同签署三个过程
2.3.1 甲方招标书定义
招标书定义过程图
具体活动
定义采购需求并对采购需求进行评审 根据采购需求确定采购商务条件（如甲乙双方的职责、控制方式、价格等） 确定采购对象的验证、检验标准与方式 收集和汇集其它相关采购资料（如产品提交清单等） 项目决策者负责认可采购需求、验收标准和相关资料 根据上述信息编写招标书（招标文件），必要时可以委托招标公司进行招标。
招标书内容
技术说明
对采购的产品或委托的项目进行详细的描述
商务说明
主要包括合同条款
投标说明
对项目背景、标书的提交格式、内容、提交时间等做出规定
要求明确投标书的评估标准
第三章 生存期模型
第4章 软件项目范围管理
4.1 项目描述
对完成项目所需相关工作的描述
项目目标的关键信息：清晰
对要执行工作所做的简要描述
问题与需求说明
约束：时间、预算、客户需求
4.2 工作分解
概述
定义
针对可交付成果对项目要素的分组，归纳和定义整个项目范围，每下降一层代表对项目工作做更详细的定义
将项目产品和活动按照其内在结构或实施过程的顺序进行逐层分解而形成的结构示意图（WBS）
WBS组织并定义了整个项目范围
WBS是对项目由粗到细的分解过程
作用
说明所有项目工作的组织情况及隶属关系，方便项目团队对项目进行观察、跟踪、检测和控制
反映项目目标
项目任务的结构示意图（WBS）
为控制具体任务的成本、进度及质量建立基础
提供项目状态信息
改善项目的信息交流
4.2.1 WBS制作步骤
根据项目描述分析项目目标
确定可交付成果，保证所有的可交付成果可以进行管理、监测以及分配
确定子可交付成果
确定具体的工作包
树形结构的WBS
清单形式的WBS
4.2.2 工作包
WBS结构底层，是项目的最小可控单元，应能满足用户对交流或监控的需要
WBS最低层次的可交付成果
短期任务，可能包含不同的工作种类，有明确的起点和终点，消耗一定的资源
实际工作表明，一个工作包的工期应该不超过10天。如果一个工作包的工期超过10天，就应在这个工期内设立检查或监视点，一般3至5天设立一个检查或监视点，以便使进度和成本等问题能及时发现
工作包的特点
① 与上一层相应单元关联，与同组其他工作包有关
② 责任可以落实到具体单位或个人
③能够确定工期，时间跨度较短
④ 能够确定实际预算、人员和资源需求
工作包应当由唯一主体负主要责任
4.2.3 工作分解方法
模版参照
将各个应用领域的标准或班标准的WBS当做模板参考使用
类比
采用类似项目的WBS作为参考
自上而下
创建WBS的最好方法
步骤
首先确定主要交付成果或者阶段
接着逐个将主要交付成果分解为更小的交付成果
继续分解直到比较容易管理的工作包
自下而上
步骤
首先定义项目的一些特定任务
然后将这些任务组织起来，形成更高级别的WBS
将详细的任务罗列，形成更高层次，然后组织成更高的层次
4.2.4 软件项目工作分解
确认并分解项目的主要组成要素 （明确项目的主要可交付成果）
以项目目标作为第一级的整体要素
项目组成要素应该用有形的、可证实的结果来描述
目的是使绩效易检测
确定分解标准
生存期阶段、功能组成等
不能有双重标准
确认分解是否详细
确定项目交付成果：有衡量标准
验证分解正确性，并建立一套编号系统
任务分解结果的检验
明确项目的主要可交付成果
确定每个可交付成果的详细程度适合编制恰当的成本和进度计划
确定可交付成果的组成元素
核实分解的正确性
工作包对于项目分解来说是否必要而充分？
每项定义是否清晰完整？
每项任务是否能够恰当地编制进度和预算？
与相关人员对WBS结果进行评审
4.2.5 WBS字典
包括对工作包的阐述和其他信息（如进度表的日期、成本预算和员工分配）的阐述
4.2.6 WBS小结
项目中的工作包是明确的，WBS应具有一定的层级关系
所确立的工作包应该是可以进行管理、测量以及分配的独立工作,全部工作包能完整表示项目进程
建立WBS时，每项工作应有唯一的编码，由高层向下层用多位码编排，这些号码的全体叫做编码系统
在编码时，在同一个层次上应尽量将同类型代码用于同级的工作包，使编码更容易理解
注意事项
WBS一旦确定，除非特殊情况，不能随便改动
遇到需要改动的情况，需召开各方会议，如部门主管、项目经理、执行人员、客户和承包商等参与的大会，就项目目标、WBS等问题共同协商，达成一致。
在WBS中不需要显示任务之间的所有联系
①确认并分解项目的组成要素(WBS编号) ②确定分解标准 ③确定分解是否详细 ④确定项目交付成果（可以编制WBS字典） ⑤验证分解的正确性
4.3 责任矩阵
责任矩阵制作步骤
确定WBS中的所有工作包，填在责任矩阵列中
确定所有项目参与者，填在责任矩阵的标题行中
针对每个具体工作包，明确个人或组织对其负主要责任
针对每个具体工作包，明确其余的职责承担者
检查责任矩阵，确保所有成员都有责任分派；同时，所有的工作包都已经确定了合适的责任承担人
责任矩阵中责任代号
责任代号
在责任矩阵中，对每一个任务，在分配给不同的团队成员时，都有不同的代号
通过合理的安排，一个团队成员可以分配一个以上的任务
责任矩阵中具体代号
I－Intiate（总指挥）：有权决定任务是否可以开始 G－General responsibility（主要负责人）：对任务负全责，有权作出相应的决策，可以分派工作给其他人；在不需要分派工作的情况下，所有工作都由主要责任人一人完成 S－Sub-contracting（次要负责人）：对主要负责人分配的工作负责任 A－Approval（审批）：有权批准任务结束，并确定交付物符合验收标准 F－Follow or monitor（监督人）：至少安排一个人，对分配下来的工作进行监督 E－Exception（意外事件处理负责人）：当意外事件发生时，有权对如何解决作出决策
备注清楚
4.4 工作授权
4.5 范围报告
4.6 范围控制
第五章 项目进度管理
5.1项目进度计划
5.1.1里程碑法
里程碑法是最简单的一种进度计划方法，仅表示主要可交付成果的计划开始时间和完成时间双关键的可交付成果
到达一个阶段可以让客户看到部分结果的地方就是里程碑。
软件项目∶需求说明书、功能说明书、系统逻辑说明与数据流（DFD）图、测试报告
5.1.2 甘特图法
甘特图由哈维甘特于1917年发明，是创建项目网络的有用工具。
通过项目进度基准计划连接项目活动
作为项目追踪工具，用作评价计划和实际进展之间的差别
甘特图的早期版本只是在左边的一栏中列出项目活动或任务、在右边的一栏中列出日历时间单位，人们形象地叫它为横道图。
表示方法
棒状甘特图
表示实际起止时间
空心棒状图
计划起止时间
实心棒状图
实际起止时间
三角形甘特图
用三角形标识特定日期
向上三角形
表示开始时间
向下三角形
表示结束时间
计划时间和实际时间分别用空心三角和实心三角表示
甘特图通过日历形式列出项目活动及其相应的开始和日期，为反映项目进度信息提供了一种标准格式
甘特图中的活动应该与WBS中的活动相一致
优缺点
优点
易读易懂
容易创建
能联合进度基准计划识别项目网络
允许变更，能帮助进行项目控制
有助于识别资源需求以及给任务分配资源
缺点
不能反映某项任务的进度变化对整个项目的影响
不能明显地表示各项任务彼此间的依赖关系
不能明显地表示关键路径和关键任务
5.1.3 网络图法
作用
完整地揭示一个项目所包含的全部工作包以及它们之间的关系
揭示整个项目的关键工作并合理地安排计划中的各项工作
方便项目管理人员管理和控制
前提
WBS
工作包的历时估计
估计工作时间时，不应受到工作重要性及工程完成期限的影响，要在考虑到各种资源、人力、物力、财力的情况下，把工作置于独立的正常状态进行估计。
工作时间估计主要依赖的数据基础
工作详细列表
项目约束和限制条件
资源需求
资源能力
历史信息
活动持续时间估算是项目制定计划的一项重要工作，它直接关系到各事项、各工作网络时间的计算和完成整个项目任务所需要的总时间
历时（经过的时间）=实际时间 + 间歇时间
工程评估评审技术PERT
利用网络顺序图的逻辑关系和加权历时估算来计算项目历时
当具体活动的估算存在很大的不确定性时，用来估算项目历时的一种网络分析技术。
PERT将关键路径法应用于加权平均历时估算∶采用概率时间估算，根据乐观的、最可能的、悲观的活动历时估计进行项目历时估算。
项目工作关系表
任务之间的关系
网络图制作步骤
确定所有工作分解结构中级别最低的工作，将这些工作的名称写在一个列表中。
按照上述工作的内在先后顺序进行安排，尽可能使所有的工作并行进行。
制作基本网络图，在网络图中每一个横道上面标注上估算工期，并对每一条路径进行工期计算
工期最长的路径是关键路径，其它路径为非关键路径。
找出网络图中的关键路径和所有的非关键路径。
网络图绘制方式
前导图法 PDM
用节点表示活动，箭线表示各任务之间的逻辑关系的项目网络图，也叫单代号网络图（PDM）
前导图法如下表示活动的依赖关系
箭尾节点表示的活动是箭头节点的紧前活动
箭头节点所表示的活动是箭尾节点的紧后活动
在绘制前导图法时，需要遵循下列规则
必须正确表达项目中活动之间的逻辑关系
在图中不能够出现循环回路
图中不能出现无箭尾节点的箭线或无箭头节点的箭线
图中只能有一个起始节点和一个终止节点
当图中出现多项无内向箭线的活动或无外向箭线的活动时，应在前导图的开始或者结束处设置一项虚活动，作为该前导图的起始或终止节点
有多个起点或终点时，需添加虚拟“开始”或“终止”
箭线图法 ADM
用箭线表示活动、节点表示活动排序的一种网络图方法，又叫双代号网络图（ADM）
两个代号唯一确定一个任务
有时为了表示逻辑关系，需要设置一个虚活动（不需要时间和资源）
如下表示活动的依赖关系
箭线表示项目中独立存在、需要一定时间或资源完成的活动
每项活动用一根箭线和两个节点来表示，每个节点都编以号码
箭线的箭尾节点和箭头节点是该项活动的起点和终点
在箭线图中，依据是否需消耗时间或资源，可将活动分为实活动或虚活动
实活动是需要消耗时间和资源的活动
虚活动是既不消耗时间、也不消耗资源的活动，只表示相邻活动之间的逻辑关系，在箭线图中用虚线表示
PDM与ADM的比较
PDM
PDM的优势
软件中构造网络图的主流方法
网络更容易标识
非常易于阅读和理解
PDM的缺陷
在大量路径的复杂项目中，多个活动汇聚或发散时需要大量的剪线或节点相连，网络难以理解
ADM
ADM的优势
在某些特殊行业如建筑业应用较多
更适合大型复杂项目
容易标识里程碑
ADM的缺陷
信息更为分散
使用相对麻烦
时标网络图
在基本网络图基础上，在水平方向上增加对项目的进度描述
活动关系的类型
串行活动
顺次进行的一系列活动
并发活动
同时进行的多项活动
汇聚活动
有两个或多个紧前活动的活动
发散活动
有两个或多个紧后活动的活动
5.1.4 关键路径法（CPM）
也称为关键路径分析，是预测总体项目历时的网络分析技术，帮助人们分析与解决进度滞后的重要工具。项目的关键路径是指一系列决定项目最早完成时间的活动，是项目网络图中最长的路径，并且有最少的浮动时间。
利用关键路径分析平衡进度计划、缩短关键路径上的活动历时、关注与及时更新关键路径数据
确定关键路径的方法
计算网络
首先利用活动间的先后逻辑关系构建项目网络，接着进行项目历时估计，利用每项活动的历时估计值进行结构化计算，就能确定整个项目的历时。
识别出网络图中的所有路径，并计算关键路径的历时
项目中的关键路径可能不止一条
基本术语
最早开始时间 （ES）
如果有多条路径指向此活动，则计算需要时间最长的那条路径。计算公式如下∶ES=max（紧前活动的EF）
取决于其紧前活动的完成时间
通过计算到该活动路径上所有活动的完成时间的和，得到指定活动的ES
最早完成时间 （EF）
取决于该工作的最早开始时间和其持续时间D。计算公式为∶ EF=ES+D
最迟开始时间 （LF）
在不影响项目完成时间的条件下，一项活动可能完成的最迟时间
计算公式∶LF=min（紧后活动的LS）
最迟完成时间 （LS）
在不影响项目完成时间的条件下，一项活动可能开始的最晚时间
计算公式∶LS=LF-D
浮动时间
浮动时间（又称时差）指一个任务在不影响其它任务或者项目完成的情况下可以延迟的时间量。浮动时间反映任务的机动性。
自由浮动 （FF，自由时差）
在不影响后置任务最早开始时间的前提下任务可以延迟的时间
汇聚活动的前置任务可能有自由时差?
可能有
总浮动 （TF，总时差）
在不影响项目最早完成时间的前提下任务可以延迟的时间
时差的确定方法
总时差（TF）
当一项活动的最早开始时间和最迟开始时间不相同时，它们之间的差值。
计算公式∶ TF=LS-ES
自由时差（FF）
在不影响紧后活动最早开始时间的条件下，一项活动可能被延迟的时间是该项活动的自由时差。
计算公式∶ FF=min（紧后活动的ES）-EF
关键路径（Critical Path）
时差为0（Float=0）的路径
条件：项目时间与关键路径时间一致
网络图中最长的路径
关键路径决定项目完成的最短时间
关键路径上的任何活动延迟，都会导致整个项目完成时间的延时
注：活动提前不一定使整个项目提前（关键路径可能有许多条时间一致）
关键路径可能不止一条
正推法
按照时间顺序计算最早开始时间和最早完成时间的方法，称为正推法
从网络图的第一项任务开始计算，直至最后一项任务，逐步相加，用来计算每项活动最早开始时间（ES）和最早结束时间（EF）
每项任务的计算皆依赖于已得出的前置任务的信息
注意：汇聚活动ES的计算
步骤
1）确定项目开始时间∶网络图中第一个任务的最早开始时间是项目开始时间
2）从左到右，从上到下，计算每个任务的最早开始时间ES和最早完成时间EF∶ES+Duration=EF
3）当一个任务有多个前置任务（汇聚活动）时，选择前置任务中最大的EF加上Lag作为其ES∶EF+Lag-ES (s)
s：后置任务
Lag：本任务与后置任务之间的滞后时间
逆推法
按照完成时间倒推计算各项任务最晚开始时间和最晚结束时间的方法，称为逆推法
从网络的终点开始，逐步向前迭代，直至最开始的节点，用来计算每项活动的最迟开始时间（LS）和最迟结束时间（LF）
注意∶发散活动LF的计算
步骤
1）确定项目的结束时间∶网络图中最后一个任务最晚完成时间是项目的结束时间
2）从右到左，从上到下，计算每个任务的最晚开始时间LS和最晚完成时间 LF >LF-Duration=LS
3）当一个任务有多个后置任务时，选择其后置任务中最小LS减Lag作为其LF∶LS-Lag=LF(p)
5.2项目进度监控
进度前锋线
绘制前锋线∶ 双时标网络图
定义检查点
比较实际进度与计划进度，预测分析、修正实际进度状况，提前采取预防措施，确保计划顺利实现
指在原时标网络计划上，从检查时刻的时标点出发，用点划线依此将各项工作实际进展位置点连接而成的折线。
通过实际进度前锋线与原进度计划中各工作箭线交点的位置来判断工作实际进度与计划进度的偏差，进而判定该偏差对后续工作及总工期影响程度的一种方法。
绘制步骤
①绘制时标网络图。为清楚起见，可在时标网络图的上方和下方各设一时间坐标（双时标）
②确定检查日期，开始绘制，依次连接相邻工作的实际进展位置点，最后与时标网络计划图下方坐标的检查日期相连接。
③前锋线采用点划线的方式标注
实际进度与计划进度的比较
前锋线可以直观地反映出检查日期有关工作实际进度与计划进度之间的关系。
对某项工作来说可能存在以下三种情况
工作实际进展位置点与检查日期重合∶表明该工作实际进度与计划进度一致。
工作实际进展位置点落在检查日期的右侧∶表明该工作实际进度超前，超前的时间为二者之差。
工作实际进展位置点落在检查日期的左侧∶表明该工作实际进度拖后，拖后的时间为二者之差
5.3项目赶工
项目赶工指在不改变项目范围的前提下缩短项且工期的方法。
项目赶工的原因
最初的进度计划过于乐观
市场变化导致项目需要比预期更早地完成
项目进展严重落后于进度计划
项目赶工的方法
提高现有资源的生产率
改变活动的工作方式，通常通过改变技术和资源类型来实现
降低质量/缩短项目范围
快速跟进项目
安排加班
增加项目资源
时间压缩法
应急法
在最小相关成本增加的条件下，压缩关键路径上的关键活动历时的方法
时间-成本平衡方法（压缩单位成本）
单位进度压缩成本=（可压缩成本-正常成本）/（正常进度-可压缩进度）
进度压缩因子方法
进度压缩因子=压缩进度/正常进度 压缩进度的工作量=正常工作量/进度压缩因子
研究表明：进度压缩因子〉0.75，最多可以压缩25％
平行作业法（快速跟进法）
改变活动间的逻辑关系，并行开展某些活动
任务超前
例如
作用
1）解决任务的搭接 2）对任务可以进行合理的拆分 3）缩短项目工期
任务拆分
缩短管理预留时间
管理预留是一项加在项目末端的人为任务
缩短项目工期的方法
减少关键路径上的活动 重新调整活动，使串行活动变成并行活动 重叠连续任务 缩短关键路径的历时 缩短早期任务 缩短最长的任务 缩短最容易的任务 缩短成本最少的活动
第6章 软件项目成本管理
6.1 概述
6.1.1 PMBOK定义的项目成本管理过程
项目管理知识体系
成本估算
编制完成项目活动所需资源的大致成本
成本预算
合计各个活动或工作包的估算成本，以建立成本基准
成本控制
分析造成成本偏差的因素，控制项目预算的变更
6.1.2 项目成本管理的有关术语
6.1.3 软件项目成本的构成
第一种划分
硬件成本
硬件设备成本
硬件维护成本
软件开发成本
数据资源购置
系统软件成本
开发人工成本
开发消耗成本
培训成本
开发人员培训费用
用户培训费用
项目管理费用
项目组织费用
项目管理费用
项目控制费用
第二种划分
环境运行成本
不可干扰的能源供应
硬件成本
文件服务器、终端、网络打印机、存储设备
软件成本
主要的软件开发、数据库软件、网络软件
安装与测试成本
咨询支持、安装硬件设施、网络连接、内部调试时间、应用新软件而重新设计业务流程
经常性支出
运行成本、保险费、低值易耗品支出
培训费用
数据库软件课程等
维护费用
年度服务合同（硬件）、数据库使用费
6.2 项目成本估算
概述
在项目开始阶段各种成本定义得越清晰，成本估算的准确率越高
成本估算越准确，制定的项目预算越可靠
尽量基于成本分解原则识别各个成本项，即按照可交付成果和工作包分解项目，估算每项任务的成本
6.2.1 项目成本估算方法
比较估算法
依赖于以前类似项目的历史数据
例如，波音公司定期进行参数成本估算，以过去的工作数据为依据，用一个乘数代表通货膨胀、劳动力等的影响，估算目前项目的成本
可行性估算法
以实际数据为依据或从最初设计工作中获取数据（邀请供应商报价）
6.2.2 软件项目成本估算
内容
根据待开发软件的特征、用户环境及以往同类项目的基础数据进行软件规模测算（代码行LOC、功能点FP等）
基于软件规模测算的数据，结合成本影响因子与以往同类项目的数据分析，进行软件成本估算（LOC估算法、FP估算法等）
过程
估算输入
需求或WBS 资源要求与资源消耗率（资源单价） 进度计划 相似项目历史数据
成本估算中的学习曲线
完成第一个活动的必要时间通常不等于完成第N个活动的必要时间
随着时间的推移，重复某项活动会使得完成该活动的必要时间逐渐减少
单位产量的生产时间公式： Yx=aXb
Yx为稳定状态下生产第x单位产品所需的时间
a为生产第一单位产品所需的时间
X为达到稳定状态需要生产的产品数量
b为学习曲线的斜率，log(十进制学习率)/log2
估算处理（估算算法）
估算输出：劳力、材料及其它
方法
（1） 最小、最大和最有可能的估算
（2） 按阶段估算
在需求定义前，根据以往同类项目的经验和对项目的主观估计进行项目成本估算
在系统分析前，给出比较确定的成本估算范围
在系统分析后，提供给管理层或用户较为精确的成本估算值
专业估算方法
代码行估算法 L0C
依据以往开发类似产品的经验和数据，估计实现软件功能所需要的源程序行数
功能点估算法 FP
用系统的功能数量来测量其规模，以一个标准的单位来度量软件产品的功能。（*）
用例点估算法
用系统的功能数量来测量其规模，以一个标准的单位来度量软件产品的功能。（*）
参数模型估算法
找到软件工作量的各种成本影响因子，并判定其对工作量产生影响的程度，以期得到最佳的算法进行估算
类比估算法
通过对已完成的类似项目与当前项目的对比预测当前项目的成本
功能点估算法
功能点
一种测量的标准单位，能表示软件应用功能规模的大小
功能点分析
依据软件功能估计系统规模的方法
功能点分析的特点
与实现的语言和技术没有关系
通过评估、加权、量化得出功能点
用功能数量测量系统规模
使用功能点估算法，需要评估产品所需要的内部基本功能和外部基本功能，然后根据技术复杂度因子（权）对他们进行量化，产生规模的最终结果。
功能点公式
因素权重的确定主要基于技术复杂度和环境复杂度
技术复杂度
描述所开发系统的复杂程度
环境复杂度
考虑系统运行的性质：用户数、语言等
功能点分析中的五类组件
外部输入 EI
给软件提供面向应用的数据项（如屏幕、表单、对话框、控件、文件等）
在这个过程中，数据穿越外部边界进入到系统内部
外部输入定级表
外部输出 EO
向用户提供面向应用的信息，例如报表和出错信息等
外部查询 EQ
外部查询是输入/输出组合，即一个输入引出一个即时的简单（没有处理过程）输出
外部接口文件 EIF
外部接口文件是用户可以识别的一组逻辑相关数据， 这组数据只能被引用
机器可读的全部接口数量，通过接口把信息传送给另一 个系统
数据完全存在于应用外部，由另一个应用维护
内部逻辑文件 ILF
用户可以识别的逻辑数据，而且完全存在于应用的边界之内，通过外部输入维护
意味着存在一个相应处理，该处理具有一定的复杂性，具有最高的权
功能点的计算
FP =UFC*TCF
UFC：未调整功能点计数
功能计数项:(从处理逻辑的角度)
功能计数项的复杂度等级（整理得来）
TCF：技术复杂度因子
技术因素对软件规模的综合影响程度
UFC
定级表
外部输入
外部输出、外部查询
定级取值表
内部逻辑文件、外部接口文件
定级取值表
功能计数项的复杂度等级
TCF
TCF=0.65+0.01（sum（Fi））： Fi：0-5， TCF：0.65-1.35
技术复杂度因子
取值范围
参数模型估算法
也称为算法模型或经验导出模型，一种使用项目特性参数建立数学模型估算成本的方法，通过大量的项目数据进行数学分析导出模型
基本思想：找到软件工作量的各种成本影响因子，判定它们对工作量所产生的影响
COCOMO模型
世界上应用最广泛的参数型软件成本估计模型，由B.W.Boehm在1981年出版的《软件工程经济学》中首先提出
COCOMO 81 模型
项目模式
有机型
主要指各类应用软件项目，如数据处理、科学计算。指相对较小、较简单的软件项目
嵌入型
主要指各类系统软件项目，通常与某种复杂的硬件设备紧密结合在一起，如实时处理、控制程序等，大且复杂的事务处理系统、大型、超大型操作系统、大型指挥系统。
半嵌入型
主要指各类实用软件项目，介于上述两种模式之间，规模和复杂度中等或者更高，如编译器（程序）、连接器（程序）等
3个等级的模型
级别越高，模型中的参数约束越多。（分别适用于项目的不同阶段，在估算出源代码行数基础上使用）
通用公式：
Effort为工作量，表示为人月
a和b为系数，取决于建模等级（即基本、中等或详细）及项目规模（即有机型、半嵌入型或嵌入型）
KLOC即千行代码，为软件项目开发中交付的有用代码行，代表软件规模
F为调整因子
不同模型F值确定方法不同
基本模型
在项目相关信息极少的情况下使用
静态、单变量模型，不考虑任何成本驱动，用一个已估算出来的源代码行数为自变量的函数来计算软件开发工作量，只适于粗略迅速估算，F=1
中等模型
在需求确定以后使用
在用LOC为自变量的函数计算软件在开发工作量的基础上，结合对产品、硬件、项目的特性等因素的主观评估，用15个成本驱动因子改进基本模型
调整因子F：每个成本驱动因子按照不同等级取值，然后相乘得到
成本驱动因子
高级或详细模型
在设计完成后使用
包括中间模型所有特性的同时考虑软件工程过程中分析、设计等各步骤的影响，将项目分解为一系列的子系统或子模型
在子模型的基础上更加精确地调整一个模型的属性，通过更细粒度的因子影响分析、考虑阶段的差别，更好地控制预算
6.3 项目成本预算
项目预算
项目成本计划，必须按照WBS中的活动确定资源分配，帮助组织实现目标
制定项目预算的过程是估算、分析、直觉和经验的结合，结合项目进度计划进行编制
6.3.1 制定项目预算的方法
（1）自上而下的预算
高层管理人员根据经验和判断，结合以前类似软件项目的历史数据，估算项目总成本和主要工作包的成本。 把估算的项目总成本告知低层管理人员，低层管理人员再对任务和子任务的成本进行估计和分配，直至最底层的工作包
优点：管理层会综合考虑项目中的资源分配，避免有些任务有过多的预算而另外一些被忽视
缺点：如果下层人员认为活动的预算成本不足以完成任务时，很可能保持沉默，这样会使项目的执行出现困难
（2） 自下而上的预算
把各个工作包的成本相加，形成子任务的预算，再把每个子任务的预算相加，产生更高一层的任务预算，直至完成整个项目的预算
优点：在任务和子任务上的预算更为精确，能避免项目实施人员对管理层所估算值的不满和对立
6.3.2 编制软件项目成本预算
① 将项目的总预算成本分摊到各项活动。 ② 将活动总预算成本分摊到工作包。 ③ 在整个项目的实施期间内，对每个工作包的预算进行分配。
6.3.3 制定应急费用预算
应急费用是项目的所有成本计算出来之后的缓冲资金
作用：分配额外资金以减少不确定情况带来的风险，并提高项目能在最初计划的时间内完成的概率
墨菲定律
爱德华.墨菲提出的一种心理学效应 原句：如果有两种或两种以上的方式去做某件事，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。
主要内容：事情如果有变坏的可能，不管这种可能性多小，它总会发生。
墨菲定律、帕金森定律和彼德原理并称为二十世纪西方文化三大发现
帕金森定律
官僚主义或官僚主义现象的一种别称，也可称为“官场病”、“组织麻痹病”或者“大企业病”，源于斯古德·帕金森1958年出版的《帕金森定律》一书的标题，该书阐述了机构人员膨胀的原因及后果
主要思想：在行政管理中，行政机构会像金字塔一样不断增多，行政人员会不断膨胀，每个人都很忙，但组织效率越来越低下
彼得原理
彼得通过分析千百个不能胜任的失败实例归纳而来
具体内容：在一个等级制度中，每个员工都趋向于上升到他所不能胜任的地位
原因
项目范围有变更的倾向 墨菲定律永远存在 成本估算必须预见关联成本 正常情况很少出现
6.4 项目成本控制
6.4.1 相关概念
成本控制
保证各项工作在其预算范围内进行
项目成本控制是按照事先确定的项目成本预算基准计划，通过运用恰当方法对项目实施过程中所消耗成本的使用情况进行管理控制，以确保项目的实际成本限定在项目成本预算范围内的过程
项目实际成本
项目实际开始实施后，需要不断地消耗资金，如员工的工资、购买的原材料、管理成本等，这些实际支出的总和是项目当前的实际成本
项目预算成本
事先确定的项目成本预算
详细预算一般与每个工作包相结合
预算需要与项目进度计划相结合
累加预算成本
在项目计划中，每个工作包都有自己的成本预算和进度计划。 根据这些数据，能够确定在某个时间点上的项目所需要的资源和成本。 把这个时间点以前的所有成本累加的值称为累加预算成本
分别控制产生的问题
一般来说，累计实际成本支出与项目进度成正比
单纯观察成本消耗的大小，不能对成本消耗和项目进度做出完全准确的判断
要真正有效地控制成本，必须连续监督消耗在项目上的资金量并与工作进度进行对比
如果实际完成的工作量超过计划的任务量，实际的花费大于计划成本，不能简单地认为成本超支
6.4.2 挣值管理
项目控制的主要内容：质量控制、进度控制和费用控制
进度和费用控制是项目的主要目标，质量控制是基础
将成本计划与进度计划结合起来进行控制，对项目进行有效的管理
挣值分析（简称EVC）借用统计学中因素分析的中间变量替代原理，引入“挣值”作为中间变量，对实际成本和预算成本的差值进行分解
即将已完成工作量的预算值与实际成本消耗值作对比，评估和测算其成本的执行情况
挣值管理5步骤
（3）建立一个阶段性预算以显示整个项目生命周期内的支出
（4）确定执行每项活动的实际成本总和即已完成工作实际成本
（5）计算项目成本偏差和进度偏差
（1）清楚地定义项目将要执行的每项活动或任务，包括所需的资源及一份详细预算
（2）制订活动和资源使用进度计划，将项目预算与项目进度联系起来
挣值分析模型的输入
BCWS（PV）计划完成工作的预算成本
到某时刻为止的总预算成本，是指到项目某时刻为止计划应完成工作量的累计预算成本
ACWP（AC）已完成工作的实际成本
到某时刻为止实际已完成工作产生的实际成本；主要反映项目执行的实际消耗指标
BCWP（EV） 已完成工作的预算成本
到某时刻为止实际已完成工作的原预算成本
BAC 工作完成的预算成本
项目计划中的成本估算结果，是项目完成的预计总成本
TAC 计划完成时间
项目计划中完成时间的估算结果
挣值分析模型的输出
进度差异（SV）
检查日期EV与PV之间的差值
SV = BCWP-BCWS = EV-PV
当SV为正值时，表示进度提前
当SV为负值时，表示进度延期
当SV为零，表示按照进度进行
成本差异（CV）
检查期间EV与AC之间的差异
CV = BCWP-ACWP = EV-AC
当CV为正值时，表示实际消耗费用低于预算费用即有节余或效率高
当CV为负值时，表示执行效果不佳，实际消耗费用超过预算费用即超支
当CV等于零时，表示实际消耗费用等于预算费用
进度绩效指数（SPI）
项目挣得值与计划之比，表示完成任务的百分比
SPI = BCWP/BCWS = EV/PV
当SPI>1，表示进度提前，即实际进度比计划进度快
当SPI<1，表示进度延误，即实际进度比计划进度慢
当SPI=1，表示实际进度等于计划进度
成本绩效指数（CPI）
预算费用与实际费用值之比（或工时值之比）
CPI = BCWP/ACWP = EV/AC
当CPI>1，表示低于预算，即实际费用低于预算费用
当CPI<1，表示超出预算，即实际费用高于预算费用
当CPI=1，表示实际费用与预算费用正好吻合
6.4.3 成本控制
控制成本一般考虑两类活动
当前正在进行的活动 成本预算偏大的活动
控制成本的基本程序
各部门定期提交成本报告 控制部门对成本报告进行审核，以保证各种支出的合法性 将已经发生的成本与预算相比较，分析其是否超支 采取相应措施控制成本
软件项目开发成本难以控制
(1)确定软件项目的需求很不容易 (2)技术风险很大 (3)工作效率无法确定 (4)项目独特性强
软件项目成本控制
技术措施
实施方法的确定
实施工具的选择
实施顺序的安排
组织措施
项目经理应组织项目部的成本管理工作，及时掌握和分析盈亏状况，迅速采取有效措施
研发部在保证质量、按期完成任务的前提下尽可能采取先进技术，以降低开发成本
财务部主管工程项目的财务工作，应随时分析项目的财务收支情况，合理调度资金
经济措施
人员费用控制管理
开发工具控制管理
其他费用控制
6.4.4 项目完工再估算
项目完工再估算（EAC）:项目成本和进度出现偏差，需要重新估算项目的成本和周期，这个重新估算的成本和周期称为项目完工再估算
项目完工成本再估算
(1) 认为未完成工作的成本消耗将与已完成工作的成本消耗相同
EAC =（AC/EV）×BAC
（BAC：项目的预算总成本）
(2) 假定未完成工作的成本消耗情况和已完成工作的成本消耗情况没有关系，对未完成的工作依然使用原来的成本预算值
EAC= BAC+(AC-EV)
(3) 重新对未完成的工作进行估算工作
EAC=AC+重新进行的成本估算
项目完工时间再估算
(1) 认为项目日后的工作将和以前的工作效率相同
EAC（时间）=(PV/EV)×BAC（时间）
(2) 假定未完成的工作的效率和已完成工作的效率没有关系，对未完成的工作，依然使用原来的计划值
EAC(时间)= (总工作量-实际已完成工作量)/计划效率+已工作时间
(3)重新对未完成的工作进行预算工作
EAC（时间）=实际已工作时间+重新进行的时间估算（剩余工作量）
第7章 软件项目质量管理
7.1 质量概述
概述
质量
质量定义
产品或服务满足明确和隐含需要能力的性能特性的总体
在商业上，人们从“适合使用”和“符合要求”的角度来定义质量一词
适合使用着眼于交付的系统能满足顾客的需要或预期
符合要求的重点在于达到预先明确的标准
软件质量反映以下3方面的问题
软件需求是度量软件质量的基础
不遵循各种标准中定义的开发规则，软件质量就得不到保证
只满足明确定义的需求，而没有满足应有的隐含需求，软件质量也得不到保证
目标
基于收集的实际绩效数据，持续改善项目过程，交付给客户满意的产品和服务
质量与等级
等级
对具有相同功能的实体按照不同技术特征进行分类或分级。 （樱桃）
质量
无论产品采用任何等级标准，它都应该具备能满足相应功能要求的各种特征，这些特征的总和就是质量
产品可以有不同等级，但无论等级高低，都可以实现自己等级内的高质量
质量低通常是一个问题，级别低则可能不是
质量管理的过程
质量保证：贯穿整个项目生命周期
质量控制：对阶段性成果进行检测、验证
质量计划：明确质量标准、确定关键因素、建立控制流程
7.1.1 软件项目质量管理基本概念
软件项目质量
软件满足软件需求规格中明确说明以及隐含的需求的程度
明确说明的需求：指在合同环境中，用户明确提出的需求或需要，通常是合同、标准、规范、图纸、技术文件中做出的明确规定
隐含的需求：顾客或社会对实体的期望，或人们所公认的、不言而喻的、不需要做出规定的需求
软件项目质量控制
为了保证和提高项目质量所进行的质量调查、研究、组织、协调、控制、信息反馈、改进等各种工作的总称
软件质量模型
人们通常把影响软件质量的特性用软件质量模型来描述
1976年 Boehm质量模型
Boehm模型与McCall模型相似，是一种由纵向软件特征构成的层次模型，差别在于特征的种类；同时包括McCall模型没有的硬件领域的质量要素
1979年 McCall质量模型
贡献：建立了软件质量特征和软件度量项之间的关系
不足：有些度量项不是客观指标，而是主观判断； 不利于在软件产品早期发现缺陷和降低维护成本
1985年 ISO质量模型
贡献：考虑到软件产品不同生命周期阶段的不同形态问题
不足：没有清楚说明软件质量特征如何度量
7.1.2 质量管理主要理论
石川馨
1972年著有《质量控制指南》一书
质量圈
在公司内部建立一个单独组织，由非监督人员和领导人员组成，自发研究如何改进其工作的有效性
石川馨图
又称因果图、鱼刺图、特性要因图等。利用“头脑风暴法”，集思广益，寻找影响软件项目质量、时间、成本等问题的潜在因素，然后用图形形式来表示，这是一种十分有用的方法
克劳士比
在《质量是免费的》中提出“组织向零缺陷突破”，强调低劣的软件项目质量的成本应包括第一次没有做对这件事情所消耗的所有成本
① 软件项目质量执行目标的“零缺陷”概念
② 根据客户的要求确定质量执行的标准
③ 团队合作的工作原则
④ 为企业进步而对领导能力的要求
⑤ 用劣质成本衡量不符合要求的代价
⑥ 预防即意味着消除软件项目质量问题
朱兰
1904年出生，1974年出版《质量控制手册》
朱兰三部曲
软件项目质量计划
软件项目质量控制
软件项目质量改进
朱兰理论的核心
软件项目管理就是不断改进工作
80/20原则
朱兰博士提出软件项目管理质量责任的权重比例问题
戴明
世界著名的质量管理专家，以戴明命名的“戴明品质奖”至今仍是日本品质管理的最高荣誉
PDCA循环
戴明博士最早提出PDCA循环的概念，所以又称为“戴明环”
P（Plan）计划
包括方针和目标的确定以及活动计划的制定
D（do）执行
就是具体运作，实现计划中的内容
C（check）检查
总结执行计划的结果
A（action）行动
处理检查的结果
特点
周而复始、大环带小环、阶梯式上升
戴明学说的核心
① 高层管理者的决心及参与 ② 群策群力的团队精神 ③ 通过教育来提高质量意识 ④ 加强软件项目质量技术训练 ⑤ 制定衡量软件项目质量的尺度标准 ⑥ 认识软件项目质量成本分析表 ⑦ 不断改进运动 ⑧ 各级员工参与
7.1.3 质量管理组织
美国质量学会(ASQ)
由美国民间基金赞助成立的非盈利性科技社团组织，成立于1946年
ASQ成员创建了诸多质量技术概念及方法，如质量成本、零缺陷、可靠性、用户满意度指数调查、六西格玛方法等
欧洲质量组织(EOQ)
由欧洲31个国家参加的质量组织
日本科学技术联盟(JUSE)
简称日科技联，成立于1946年，1951年设立戴明奖
7.1.4 PMBOK2004定义的项目质量管理
质量计划
判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准
实施质量保证
开展规划所确定系统的质量活动，确保项目实施满足要求的所有过程
实施质量控制
监控项目的具体结果，判断它们是否符合相关质量标准，并找出消除不合绩效的方法
质量理念和规则
重视顾客满意度 预防而不是检查 通过改进过程来改进产品 质量是每个人的责任 以事实为依据的管理
7.2 软件项目质量计划编制
质量标准
软件开发常用技术标准
知识体系：软件工程知识体系指南SWEBOK2004等 过程标准：CMMI、PSP等 建模标准：软件工程规范国家标准 质量管理标准：ISO9001:2000、TQC 程序语言标准：Java、C++、编程规范等 数据库标准：Oracle数据库规范等
质量度量
指把软件项目的属性按照一定规则进行处理得到的数值或类别
数值是指对能够量化的数据进行综合得到的结果，比如平均无故障时间、系统响应时间等
类别是指列举无法量化的属性，比如采用的编程语言是Java还是C
质量目标
为一个软件项目确立量化数值或类别
如正确性、可实现性、集成性、可用性、有效性、可管理性、可测试性、可交互性、稳定性、可重用性、可修改性、文档情况、易理解性、可验证性等
7.3 软件质量保证
软件质量保证(SQA)是一个系统性的活动，为软件产品的可用性提供了保证
SQA的目的
可视化软件项目正在进行的过程和正在构造的产品，并向管理者提供
包括评估和审计软件产品和开发活动以验证它们符合适用的规程和标准
SQA负责审计产品的质量活动并消除偏差
软件验证和确认是在软件生命周期中对其进行评估的规范化方法
验证是用于保证前面的活动满足特定需求，强调过程的正确性
确认是在各个阶段结束时检查系统是否满足客户需要，强调结果的正确性
软件验证和确认的主要活动包括关键性分析、可跟踪性分析、评估、接口分析和测试
各阶段的质量保证
需求阶段
软件需求分为3个不同层次
业务需求
反映组织机构或客户对系统、产品的高层次目标要求，在项目视图与范围文档中予以说明
用户需求
描述用户使用产品必须要完成的任务，在用例文档或方案脚本中予以说明
系统需求
是从系统的角度来描述的软件需求，包括系统隐含的特性，功能要求和质量属性等
质量保证要点和关键活动
准确获取需求 精确分析需求 建立合适的模型 严格评审需求 控制需求变更
设计阶段
软件设计是一个从概念到实体逐步细化的过程，包括架构设计、概要设计、详细设计，不同的设计层次体现了从抽象到具体的思维过程
根据设计关注点的不同，又可分为模块设计、接口设计、数据库设计、功能设计、界面设计等
软件设计质量评价的标准
设计结果的稳定性 设计的合理性 模块间的耦合度和模块的内聚性 可追溯性 可测试性
软件设计阶段提高质量的方法和建议
进行设计评审
使用检查表对设计进行正式的评审
复用设计模式
将设计模式引入软件设计，充分利用已有软件开发经验，提高质量和效率
实现阶段
在编码阶段质量保证的措施
统一风格 严格遵守编程规范 进行代码静态分析和代码复查 进行完善的单元测试
测试阶段
内容
测试计划的质量保证 测试用例设计的质量及测试用例评审 测试执行过程的质量及缺陷跟踪 测试结果的评估 测试组织和管理的质量保证
发布及维护
内容
建立以客户为中心的质量文化和方针 制定有效的软件发布策略和流程 建立完善的配置管理数据库 制定有效的客户需求变更流程 建立合理的技术支撑体系 与客户进行有效地沟通交流 及时更新软件文档
7.4 软件质量控制
软件质量控制模型
PDCA模型
影响PDCA过程的关键
产品
一个过程的输出不会比输入的质量更高
软件产品的各个部件和模块必须达到预定的质量要求
过程
技术过程如需求分析、架构设计、编码实现等直接决定软件的质量特性
管理过程如技术评审、软件测试等对技术过程的成果进行检查和验证，发现问题并进行纠正，间接地决定最终产品的质量
资源
包括人、时间、设备和资金
缺陷跟踪管理
概念
软件缺陷
程序中存在的破坏正常运行能力的问题或错误
软件错误
属于缺陷的一种，往往是程序本身的问题，如算法错误、语法错误、计算不准确等
软件故障
指运行过程中出现的一种不希望或不可接受的内部状态
软件失效
指软件所提供给用户的功能或服务不能达到用户的要求，描述软件行为对用户要求的偏离
软件缺陷的类型
功能特性没有实现 设计不合理 实际结果与预期结果不一致 没有达到规格说明书的性能指标 运行过程中异常中断、系统崩溃 数据结果不正确、精度不够 界面混乱 运行等待时间过长，用户不能接受
严重性
严重：系统崩溃、数据丢失、数据损坏 较严重：操作性错误、结果错误、功能遗漏 一般：小问题、错别字、界面布局、罕见故障 建议：不影响使用的瑕疵或更好的实现建议
7.5 IT项目质量控制技术
7.5.1 帕累托分析
80/20效率法则又称为帕累托法则、帕累托定律、不平衡原则，由意大利经济学家帕累托提出
80/20法则认为
原因和结果、投入和产出、努力和报酬之间本来存在着无法解释的不平衡
帕累托分析指确认造成质量问题的诸多因素中最为重要的几个因素
影响项目质量的因素分类
A类
关键的少数，其影响程度的累计百分数在70%-80%范围内的因素
B类
一般的因素，除A类之外的累计百分数在80%-90%范围内的因素
C类
次要的因素，除A、B两类外累计百分数在90%-100%范围内的因素
目的
帮助确认问题并对问题进行排序，对A类问题实行严格质量控制，而对C类因素实行较为宽松的质量控制
使得项目团队首先采取措施纠正造成最多质量缺陷的问题
7.5.2 统计抽样
7.6 提高IT项目质量
7.6.1 “一把手”重视
很多专家认为，质量问题的最主要原因是缺乏领导
在IT项目中，“一把手”指实际主管IT项目的人，有权对有关IT项目事务做出最终决策
7.6.2 理解质量成本
看书
7.6.3 组织和工作环境
7.6.4 建立IT企业质量管理体系
IT企业建立质量管理体系的原因
技术人员和管理人员在软件开发工作中仍有一些不正确的认识需要纠正
目前多数IT企业的质量管理尚未得到应有的重视
IT项目必须靠加强管理来实现工程化，质量管理要体现在建立和实施开发规范中
软件本身的特点和目前的软件开发模式，使得隐藏在软件内部的质量缺陷不能完全避免
找不到理想的软件开发技术从根本上防止缺陷出现
不同类型IT企业关注的质量焦点
项目型软件企业
以承接客户的委托开发项目为主，在“与客户有关的过程”和“设计和开发更改的控制”等条款上要特别强调
产品型软件企业
以某产品的研发和提供为主，应加强产品市场部门的职能，加强软件的配置管理和市场调查，并定期开展“顾客满意”分析等
服务型软件企业
主要关注服务的质量和服务的竞争型，应设立客户服务中心
系统集成型IT企业
具有较多的项目实施任务和设备采购任务，需要在相关条款上特别强调和重视
管理咨询型IT企业
以项目实施为主，要注意建立售后服务和客户满意度等方面的质量管理工作
ISO9000:2000标准体系
ISO9000是目前比较流行的质量管理体系，是组织在质量管理方面的最低标准
IT企业贯彻实施ISO9000质量体系认证，可以选择质量标准ISO9001和ISO9003
ISO9001:2000
把ISO9001-3合并为一，并结合了CMM的一些精髓，使其适合IT企业作为实施ISO9001质量保证模式的实施指南
通过对IT产品从市场调查、需求分析、编码、测试等开发工作，直至作为商品软件销售，以及安装以及维护整个过程进行控制，保障IT产品的质量
CMM标准体系
软件能力成熟度模型
指导企业不断改进软件工程，达到较高的软件质量和生产率
现在已被广泛用于评定软件企业的授证标准
提供软件工程成果和管理方法的框架
可用来衡量、评估软件企业过程管理水平的成熟度
CMM模型描述和分析了软件过程能力的发展过程，确立了一个软件过程成熟度的分级标准
基本概念
软件过程（SP）
指人们用于开发和维护软件及其相关产品的一系列活动、方法、时间和革新；相关产品是指项目计划、设计文档、编码、测试和用户手册
软件过程能力（SPC）
表示遵循一个软件过程后能够得到的预期结果的界限范围
软件过程性能（SPP）
表示遵循一个软件过程后所得到的实际结果
软件过程成熟度（SPM）
指一个具体的软件过程被明确地定义、管理、评价、控制和产生实效的程度
软件过程成熟度模型（CMM）
卡内基-梅隆大学软件工程研究院为了满足美国联邦政府评估软件供应商能力的要求，于1986年开始研究的模型
能力成熟度模型集成（CMMI）
为了将能力成熟度模型整合成一个单一的框架，用于改进整个企业的过程，于1991年发布原始的CMMI
基本框架
CMM定义的五种过程成熟等级
可管理级
软件过程和产品质量有详细的度量标准
最优化级
通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断、持续地对促进过程进行改进
初始级
软件过程无秩序，有时甚至混乱
可重复级
已建立基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪
明确级
用于管理的和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程
主要内容
初始级的改进方向
建立项目过程管理和规范化管理，保障项目的承诺； 进行需求管理方面的工作，建立用户域软件项目之间的沟通，使项目真正反映用户的需求； 建立各种软件项目计划； 积极开展软件质量保证活动
可重复级的改进方向
不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为全组织的标准软件过程；确定全组织的标准软件过程； 建立软件工程过程小组长期承担评估域、调整软件过程的任务； 积累数据；加强培训
已定义级的改进方向
着手软件过程的定量分析，已达到定量地控制软件项目过程的效果； 通过软件的质量管理达到软件质量的目标
已管理级的改进方向
防范缺陷，不仅在发现了问题后能及时改进，而且应采取特定行动防止将来出现这类缺陷； 主动进行技术改革管理、标识、选择和评价新技术，使有效的新技术能在开发组织中实施； 进行过程变更管理，定义过程改进的目的，经常进行过程改进
优化级的改进方向
保持持续不断的软件过程改进
软件过程评估和软件能力评价
软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于按缺陷提出改进方向
评估组以CMM模型为指引调查、鉴别软件过程中的问题，将这些问题与CMM关键实践活动所提出的指导一起用于确定组织的软件过程改进策略
软件能力评价是对接受评价者在一定条件下、规定时间内能否完成特定项目的能力的考核，即承担风险的系数大小。 评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。 通过利用CMM模型确定评价结果后，就可以利用这些结果确定选择某一承包商的风险。也可以用来判断承包者的工作进程，推动他们改进软件过程
软件过程评估和软件能力评价的步骤
软件过程评估和软件能力评价的不同
软件过程评估和软件能力评价在出发点和目标方面不同。 软件过程评估和软件能力评价的结果与其所起的作用不同
被评估和评价单位的态度对评估和评价活动的态度不同
评估:被评估单位的态度较积极 评价:被评价单位的态度可能比较慎重