软件工程管理第十章第十章 软件工程管理10
10.1 软件工程管理概述
10.2 可行性研究
10.3 成本估算技术
10.4 软件项目的组织与计划
10.6 软件能力成熟度模型
10.5 软件质量保证第十章 软件需求分析
10.1 软件工程管理概述软件工程管理是对软件项目的开发管理，是对整个软件生存期的所有活动进行管理。任何工程的成败，都与管理的好坏密切相关，软件工程更不例外。尤其是软件产品的特殊性，软件工程的管理对于保证软件产品的质量具有极为重要的作用。
随着软件的规模和复杂度的不断增大，开发人员的增加以及开发时间的增长，这些都增加了软件工程管理的难度。
例如,Windows 2000的开发 是微软公司历史上最艰巨的任务，仅核心部门的的成员就有 2500人，测试用的代码就有 1000万行，测试中所用到的脚本程序就有 6500种 … 。象规模如此之大的软件系统，如果没有科学的、规范的、有效的管理，是不可能成功的。因此 软件工程管理成为软件工程的重要研究内容之一。
10.1 软件工程管理概述任何技术先进的大型项目的开发如果没有一套科学的管理方法和严格的组织领导,是不可能取得成功的 。 即使在管理技术较成熟的发达国家中尚且如此,在我国管理技术不高,资金比较紧缺的情况下,大型软件项目开发的管理方法及技术就显得尤为重要 。
软件工程管理的对象是软件工程项目,因此 软件工程管理涉及的范围覆盖了整个软件工程过程 。
软件工程管理的主要任务有：
一,软件可行性分析与成本估算二,软件生产率及质量管理三,软件计划及人员管理
10.1.1 软件管理的任务与目标
10.1.1 软件管理的任务与目标
10.1.2 软件作用的范围确定软件的作用范围是软件项目计划的第一项活动 。 是要对 用户要求解决的问题进行确切定义,进一步分析软件开发的风险,以便制定软件计划 。
10.1.2 软件作用的范围从以下方面考虑软件的作用范围：
软件的功能,性能
接口 （ 与硬件,软件工具,人,过程的一系列操作 ）
软件的可靠性关于软件范围的叙述都应给出定量的数据 （ 例如,同时使用该软件的用户数目,发送表格的长短,最大允许响应时间等等 ）,指明约束条件或限制 （ 例如,产品成本限制了存储的容量 ） 。 此外还要叙述某些质量因素 （ 例如,给出的算法是否容易理解,是否使用 Ada语言等 ） 。
10.1.3 资源要求
1,人力资源 ——在考虑各种软件开发资源时,人是最重要的资源 。
在安排开发活动时必须考虑人员的技术水平,专业,人数,以及在开发过程中各阶段对各种人员的需要 （ 图 10.2） 。
2,硬件资源 ——主要包括宿主机 Host Machine（ 软件开发时使用的计算机及外围设备 ）,目标机 Target Machine（ 运行已开发成功的软件的计算机及外围设备 ） 和其他硬件设备 （ 专用软件开发时需要的特殊硬件资源 ） 。
3,软件资源 ——即软件工具集,主要有业务系统计划工具集,项目管理工具集,支援工具,分析和设计工具,编程工具,组装和测试工具,原型化和模拟工具,维护工具,框架工具等 。
4,软件复用性及软件部件库 ——为了促成软件的复用,以提高软件的生产率和软件产品的质量,应建立可复用的软件部件库 。 对于软件的复用,人们经常忽略,但这却是相当重要的一环 。
10.1.3 资源要求图 10.2 Putnam _ Norden 曲线高低计划需求分析初步设计详细设计编码单元测试整体测试功能测试管理人员 高级技术人员初级技术人员通常，软件开发所需的资源，可由“金字塔“型（图 10.1）,描述。
人 — 人员的技术水平，专业和数量。
工具 — 主要是软、硬件工具。
根据统计结果,在软件开发过程中,不同阶段的人员需求情况如 图
10.2,按照 Putnam _ Norden 曲线所示 。
人工具问 题分析在软件开发的不同阶段各类人员的需求情况，为什么？
图 10.1
10.1.3 资源要求 Putnam _ Norden 曲线
10.2 可行性研究可行性研究又称为可行性分析,目的是避免盲目投资,减少不必要的损失 。 即以最小的代价在最短的时间内确定该项目是否可能开发,是否值得 。
任何软件的开发,都会受到开发时间,经费及开发环境及技术的限制 。
及早对软件项目的可行性做出细致而谨慎的评估是十分必要的 。 若在定义阶段及早发现将来开发工作中可能出现的问题,及早地作出决定,可将项目开发的风险降到最低 。
可行性研究的主要内容有：
技术上可行 经济上可行 社会上可行可行性报告可行性报告可行性报告可行性报告 可行性分析的结果报告
10,2 可行性研究
10.2.1 可行性研究的任务
10.2.1 可行性研究的任务技术上可行经济上可行社会上可行技术上可行经济上可行社会上可行现有技术,资源及限制能否支持和实现系统的功能,
性能 。 主要是技术风险问题 。
进行成本估算及效益评估,确定项目是否值得开发 。
主要指系统开发后能否运行,是否存在合同,责任,
侵权,用户组织管理等方面的问题 。
一、可行性分析的任务二,可行性分析步骤确定项目规模和目标 。
研究现行系统 （ 如果存在 ） 。
建立新系统的高层逻辑模型 。
用系统流程图或数据流图 （ DFD图 ） 描述 。
提出实现高层逻辑模型的各种方案,并对各方案进行评价 。
推荐可行的方案 。
编写可行性报告 。
进行可行性分析时,通常用系统流程图来描述所要开发的系统 。 用于描述项目的处理流程,范围,功能等 。
1、系统流程图的基本符号处理框输入 /输出文档连接换页连接数据流磁盘联机存储显示人工输入人工操作辅助操作通信链路一、系统流程图
10.2.2 可行性分析的描述手段
10.2.2 可行性分析的描述手段
2、系统流程图举例 — 库存管理系统功能：
库存零件的种类和数量存放在库存清单主文件中。
随时更新库存文件。
当某零件少于库存临界值时，产生订货报告，通知采购部门。
输入变更记录库存管理模块订货信息报告生成模块订货报告库存清单
10.2.2 可行性分析的描述手段二、数据流图也可以用ＤＦＤ图来对系统进行描述。
图 10.3
可行性研究报告（参考格式）
一,引言系统名称,目标,功能,开发组织单位,服务对象等 。
二,系统开发的背景,必要性和意义
1,现行系统的调查研究组织机构,业务流程,工作负荷,费用,人员,设备,计算机应用情况,存在问题等 。
2,需求调查和分析用户提出的需求及考虑经济改革和发展需要进行预测结果 。
三,新系统的几种方案介绍
1,拟建系统目标
2,系统规模及初步方案 (粗略的逻辑模型 )
3,系统的实施方案 (计划安排 )
4,投资方案
5,人员培训及补充方案
6,其它可供选择的方案
10.2.3 可行性研究报告
10.2.3 可行性研究报告
10.2.2 可行性研究报告 (续 )
可行性研究报告（参考格式）
可行性研究报告（参考格式）
四,可行性研究
1,技术上的可行性 (按系统目标衡量 )
(1)对现有技术的估价
(2)使用现有技术进行系统开发的可行性
(3)对技术发展可能产生影响的预测
(4)关键技术人员的数量和水平估计
2,经济上的可行性 (估算成本 /效益比 )
(1)现有的经济条件
(2)开发,运行费用
(3)对系统效益的估计
(4)投资回收期
(5)成本 /效益比
3,系统运行的可行性
(1)对组织机构的影响
(2)人员适应的可行性
(3)环境条件的可行性五,几种方案的比较分析六,结论
(可按某方案立即执行,等某些条件成熟后再执行或不可行等等 )
可行性分析报告经审批后,可进行需求分析工作 。
10.3 成本估算技术
10.3 成本估算技术成本估算是可行性分析的重要依据，也是软件管理的重要内容，直接影响到软件开发的风险。
软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价,即主要是人的劳动的消耗 。 因此,软件产品开发成本的计算方法不同于其它物理产品的成本的计算 。
软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此软件成本估算，应以软件计划、需求分析、
设计、编码到测试的软件开发全过程所花费的代价为依据。
另外，必须注意，对于一个大型项目，由于其项目的复杂度，成本估算并不是一件简单的事，必须建立相应的估算模型，按照一定的方法、
技术来进行估算。
10.3.1 影响成本估算的因素为了正确进行成本估算,首先要了解影响成本估算的主要因素：
1,软件人员的业务水平 软件人员的素质,经验,掌握知识的不同,在工作中表现出很大的差异 。
2,软件产品的规模及复杂度规模,按 YOURDON分类法将软件产品的规模分为超小型,小型,中型,
大型,超大型,极大型 。
复杂性,应用程序,实用程序,系统程序分别由低到高排列 。
3,开发所需时间显然,开发时间越长成本越高 。 对确定规模,复杂度的软件存在一个
,最佳开发时间,,即是完成项目的最短时间,选取最佳开发时间来计划开发过程,可以取得最佳经济效益 。
4,软件开发技术水平指开发方法,工具,语言等,技术水平越高,效率越高 。
5,软件可靠性要求一般可靠性要求愈高,成本愈高 。
§ 10.3.1 影响成本估算的因素类 别 参加人数 研制期限 产品规模（源代码行）
微 型 1 1 –4 周 0.5K
小 型 1 1 – 6 月 1K – 2K
中 型 2 - 5 1 – 2 年 5 – 50 K
大 型 5 - 20 2 – 3 年 50 – 500 K
甚大型 100 - 1000 4 – 5 年 1M
极大型 2000 -5000 5 – 10 年 1M – 10 M
微型 可不作严格的系统分析和设计,在开发过程中应用软件工程的方法 。
小型 如数值计算或数据处理问题，程序往往是独立的，与其它程序无接口，
应按标准化技术开发。
中型 如应用程序及系统程序，存在软件人员之间，软件人员与用户之间的密切联系、协调配合。应严格按照软件工程方法开发。
大型 编译程序、小型分时系统、应用软件包、实时控制系统等。必须采统一标准，严格复审，但由于软件规模庞大，开发过程可能出现不可预知的问题。
甚大型 如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、
军事指挥系统等。子项目间有复杂的接口，若无软件工程方法支持，开发工作不可想象。
极大型 如大型军事指挥系统、弹道防御系统等，这类系统极少见，更加复杂。
规模表 10.1
10.3.2 成本估算模型二,成本估算模型软件成本估算模型可分为两大类：理论模型和统计模型,具体介绍以下模型：
1,Halstead理论模型
2,统计估算模型
3,构造性成本模型
10.3.2 成本估算模型一,软件成本估算量软件成本 估算通常是对以下量进行估算：
源代码行 （ LOC）
是指机器指令行 /非机器语言的执行步开发工作量常用的单位是：人 -月 （ PM） 人 -年 （ PY） 人 -日 （ PD）
软件生产率单位劳动量所能完成的软件数量：
LOC/PM ￥ /LOC ￥ /PM
软件开发时间
10.3.3 Halstead 理论模型理论模型来源于软件度量学的研究，根据四个原始量进行估算：
n1：不同运算符个数 n2：不同运算对象个数
N1：运算符总数 N2：运算对象总数估算模型：
程序长度 Ｎ＝ n1log2 n1＋ n2 log2 n2
程序量 V＝Ｎ log2(n1＋ n2)
程序级别的度量 Ｌ＝Ｖ ＊ ／Ｖ （Ｖ?Ｖ ＊ ）
其中Ｖ ＊ 为无暇程序的程序量，对特定程序Ｖ ＊ 为常数。程序级别愈低，程序量愈大。
由于Ｖ ＊ 不易计算，可按照以下公式计算：
所花费精力 Ｅ＝Ｖ／Ｌ
程序开发时间 Ｔ＝Ｅ／Ｓ
10.3.3 Halstead 理论模型 理论模型１
Ｌ＝ ２ Ｎ２n1 Ｎ２×
该模型经过实际检验,估算结果是准确的,但由于四个原始量在可行性分析阶段根本无法获得,因此 Halstead 理论模型往往并不用于实际成本估算,而是用于验证其它估算模型的准确性 。
10.3.3 Halstead 理论模型
ai — 估计的最小行数
bi — 估计的最大行数
mi — 最可能的行数
10.3.4 专家估算模型即 源代码行 估算模型 （ Deiphi技术 ）
由 Rand公式提出的 Deiphi技术,又称为专家估算模型,是由 n位专家进行成本估算 。 每位专家根据系统规格说明书,反复讨论给出 ai,bi及
mi的值,并按照下式反复估算 源代码 的 期望值 Li,期望中值 L。
ai+4mi+bi
6
1
n?
n
i
iL
1
Li = L=
将估算的源代码行数,乘以根据经验推算的每行源代码所需成本,
即为该软件的成本 。
10.3.4 专家估算模型10.3.4 专家估算模型
10.3.5 IBM估算模型
10.3.5 IBM 估算模型 （ 静态,单变量模型 ）
1977年由 Waiston 和 Felix 总结了 IBM联合系统分部 （ FSD） 负责的６０个项目的数据,利用最小二乘法拟合,得到如下估算公式：
工 作 量,E=5.2*L （ PM）
项目持续时间,D=4.1*L （ 月 ）
人员需要量,S=0.54*E （ 人 ）
文 档 数,DOC=49*L （ 页 ）
其中,L ＿ 源代码行,以千行计 。
IBM估算模型是一种静态单变量模型,它利用已估算的结果,如源代码行,来估算各种资源的需求量,
但 IBM 估算模型不是一种通用模型,因此应用中应根据具体实际情况调整模型中的参数,
10.3.5 IBM 估算模型
10.3.6 Putnam 估算 模型 （动态、多变量模型）
L
Ck td
3
3 4Ｋ＝
31 34Ｌ＝ Ck K td
Putnam 估算 模型 是一种动态多变量模型,是根据一些大型项目中工作量的分布情况 （ 图 10.4） 而推导出来的,
10.3.6 Putnam 估算 模型其中,L- 源代码行,K - 所需人力 （ PY）,td - 开发时间,
CK -技术水平常数,CK值与开发环境有关 。 （ 差,2500-2000，
正常,10000-8000,好,12500-11000）
10.3.2 成本估算模型图 10.4 大型项目的工作量分布情况运行与维护系统开发功能设计规格说明系统定义安装测试与确认设计与编码系统定义功能设计规格说明时间
10.3.7 COCOMO模型
10.3.7 COCOMO模型
COCOMO模型 （ Constructive Cost Model） 由 TRW公司开发,是由
Boehm提出的结构型成本估算模型,其特点是精确,易用 。
是一种层次模型,按照其祥细程度分为三级：即基本的 COCOMO模型,
中间的 COCOMO模型和详细的 COCOMO模型 。
该模型主要对工作量ＭＭ （ 单位,PM） 和进度 TDEP（ 单位：月 ） 进行估算 。 模型中考虑到估算量与开发环境有关,将开发项目分为三类：
组织型 （ Organic）
规模不大 (<5万 ),较简单,开发人员对产品目标理解充分,经验丰富,
对软件开发环境熟悉 。 大多数应用软件及老的操作系统,编译系统属此类 。
嵌入型 （ Embadded)
软件,硬件的关系紧密,操作有限制条件,对接口,数据结构,算法要求较高 。 如大型复杂的事务处理系统,大型,超大型的操作系统,军事指挥系统,航天控制系统等 。
半独立 型 （ Semidetached)
对项目要求界于上述两者之间,规模复杂度中等 。 如新操作系统,大型数据库,生产控制等软件属此类 。
10.3.7 COCOMO模型
al k lo cc?ＭＭ＝
① 基本的 COCOMO模型 （ 静态单变量模型 ）
其中,MM — 工作量 （ PM）,KLOC — 估计的源代码行
Cl — 模型系数,?—模型指数
Cl,? 取决于开发项目的模式为组织型,半独立型或嵌入型 。
10.3.7 COCOMO模型 ① 基本的 COCOMO模型下表是根据 63个项目的数据统计结果,按照 基本的 COCOMO模型估算的工作量和进度 。
总体类型 工作量 进度组织型 MM=10.4（ KLOG） 1.05 TDEV=10.5（ MM） 0.38
半独立型 MM=3.0（ KLOG） 1.12 TDEV=10.5（ MM） 0.35
嵌入型 MM=3.6（ KLOG） 1.20 TDEV=10.5（ MM） 0.32
表 10.2
其中,fi — 成本因素包括：
生产因素 （ 可靠性,数据库规模,软件复杂度 ）
计算机因素 （ 时间约束,存储约束,环境变更率,计算机换向时间 ）
人员因素 （ 系统分析员能力,经验,程序员能力,开发人员环境知识,程序时间语言知识 ）
项目工程因素 （ 设计技术,软件工具,进度限制约束 ）
③ 详细的 COCOMO模型在考虑成本因素 fi时,按照开发阶段分别给出更加详细的值 。
al k lo cc
15
1i
ifＭＭ＝
② 中间的 COCOMO模型进一步考虑了 15种影响软件工作量的因素,更加合理的估算软件工作量和进度 。
② 中间的 COCOMO模型10.3.7 COCOMO模型
10.3.8 成本估算方法
1,自顶向下的估算方法从项目的整体出发,进行类推 。 即据以前完成的同类项目的总成本,推算当前项目的总成本,再将其分配到各开发任务中 。
特点：简便,估算工作量小,误差大 。
2,自底向上的估计法把待开发的软件细分,直到每一子任务都已经明确所需要的开发工作量,
然后把它们累加起来 。
特点：精确度高,但缺少子任务 （ 模块 ） 间的联系 。
3,差别估计法综合上述两种方法而得,将项目与已经完成的项目进行类比,相同部分按照已经完成的项目估算,不同部分另行估算 。
特点：估算较精确,但区分类比较困难 。
10.3.8 成本估算方法对于大型软件项目来说,由于项目的复杂型,成本估算并不单纯是一个计算过程,还需要进行一系列的估算处理,处理手段主要是分解和类比 。
一般有以下方式：
注意,在对实际项目进行估算时,通常使用综合方法 。
10.3.9 成本 /效益分析成本／效益分析的第一步是估算成本和运行费用 （ 系统的操作费用和维护费用 ）,系统的经济效益则等于因使用新系统而增加的收入,加上使用新系统可以节省的运行费用 。
1,货币的时间价值通常以利率形式表示 。 假设,年利率为 i,P元钱在 n年后的价值 F为：
2,投资回收期投资回收期即工程累计经济效益等于最初投资所需要的时间 。
3,纯收入在整个生存周期内新系统的累计经济效益与投资之差称为纯收入 。
4,投资回收率用于衡量投资效益的大小,并且可以用它和年利率比较,。 设现在的投资额为Ｐ：
Ｐ＝Ｆ 1 /（ 1+j） ＋Ｆ 2 /（ 1+j） 2 ＋ … ＋Ｆ n /（ 1+j） n
其中：Ｆ i是第 i年年底的效益 （ i=1,2,3,… n） ；
n是系统的使用寿命； j是投资回收率 。
10.3.9 成本 /效益分析
nF＝ P（ 1+i）
10.4 软件项目的组织与计划
10.4 软件项目的组织与计划软件项目的组织管理,需要多方面的综合知识,涉及到系统工程,统计学,心理学,社会学,经济学,乃至法律等方面的问题 。 尤其涉及到社会因素,精神因素,人的因素,比技术问题要复杂得多 。
软件项目的管理，也不能完全照搬外国的经验，还必须结合我国的实际情况，结合我们的工作条件、人员和社会环境等多种因素考虑。
此外，实践是取得管理经验的重要途径。很显然，管理能够取得效率，能够赢得时间，是软件能够开发成功的关键。
10.4.1 软件项目管理的特点软件产品与其他任何产业的产品不同,它是非物质性的产品,是知识密集型的逻辑思维产品 。 由于软件的这种独特性,使软件项目管理过程更加复杂和难以控制 。
软件项目管理的主要特点是：
1,软件项目管理涉及的范围广,涉及到软件开发进度计划,人员配置与组织,项目跟踪与控制等 。
2,应用到多方面的综合知识,特别是要涉及到社会的因素,精神的因素,认知的因素,这比技术问题复杂得多 。
3,人员配备情况复杂多变,组织管理难度大 。
4,管理技术的基础是实践,为取得管理技术成果必须反复实践 。
10.4.1 软件项目管理的特点
10.4.2 软件开发进度计划
10.4.2 软件开发进度计划软件开发进度计划安排是一件困难的任务,既要考虑各个子任务之间的相互联系,尽可能并行地安排任务,又要预见潜在的问题,提供意外事件的处理意见 。
描述计划进度的主要工具有：一般的表格工具,甘特图,PERT技术与
CPM方法 。
１,一般的表格工具例如：进度表 （ 图 10.5）
▲ ▲ ▲软件测试
▲ ▲ ▲编码
▲ ▲详细设计
▲ ▲ ▲总体设计
▲ ▲ ▲需求分析
１ 2 3 4 5 6 7 8 9 10 11 12 任务 月份图 10.5 进度表
0
10
20
30
40
50
60
70
一月 二月 三月 四月 五月 六月需求分析总体设计详细设计编码、测试
10.4.2 软件开发进度计划
2,甘特图 （ Gantt Chart）
用水平线段表示任务的工作阶段；线段的起点和终点分别表示任务的开始和完成时间,线段的长度表示完成任务所需的时间 。 图 10.6给出了具有五个任务的甘特图 。
2、甘特图（ Gantt Chart）
图 10.6 甘特图周
1 2 3 4 5 6 7 8 9 10 11
任务
A
B
C
D
E
当前进度
○△
○△
○△
○△
○△ 优点,标明了各任务的计划进度和当前进度。能够动态反映软件开发的进展情况。
缺点,不能够反映多个任务之间的复杂逻辑关系 。
完成 计划完成
○ 文档编写 △ 评审图 例
3,时标网状图 （ timescalar network）
也称为改进的 Gantt图,增加了各子任务之间的逻辑依赖关系 。 如图
10.7所示；表示 A,B,C,D,E５个任务之间在进度上的依赖关系 。 例如 E2
的开始取决于 A3的完成 。 虚箭头表示虚任务 。
10.4.2 软件开发进度计划
4,PERT技术和 CPM方法
PERT（ Program evaluation & review technique)计划评审技术或
CMP（ Critical path method） 关键路径法,都是采用网络图来描述项目的进度安排 。 如图 10.9描述了开发模块 A,B,C的任务网络图 。 图中各边上所标注的数字为该任务所持续的时间,数字结点为任务的起点和终点 。
1 2
0 3 7 8
4 5
6 周任务
5 10 15 20
A1 A2 A3
B1
B2 E1 E2
C
D1 D2
D3
图 10.8 网状时标图
0
2
3
4
5
6
7
1
8起点
A
编码
A调试
B编码
6
6
8
78 8 7 9
6 8 BC组装测试
5
图 10.9 任务网络图假设红线为关键路径,即完成所有任务的主要路径 。
3、时标网状图
10.4.3 人员配备与组织三,评价人员的条件
1,掌握计算机软件的基本知识和技能；
2,善于分析和综合问题,具有严密的逻辑思维能力；
3,工作踏实,细致,不靠运气,遵循标准和规范,具有严格的科学作风；
4,工作中耐心,有毅力,有责任心；
5,善于听取意见,善于团结协作,有良好的人际关系；
6,具有良好的书面和口头表达能力 。
10.4.3 人员配备与组织如何合理的配备人员是成功的完成软件项目的切实保证 。 所谓合理配备人员应该包括：按不同阶段适时任用人员,恰当掌握人员标准 。
一,项目各阶段所需人员按照 Putnam_Norden 曲线进行分配 。
图 10.10 Putnam _ Norden 曲线高低 计划需求分析初步设计详细设计编码单元测试整体测试功能测试管理人员 高级技术人员初级技术人员二,配备人员应该遵守的原则
1,重质量；
2,重培训
3,阶梯提升：
10.4.4 软件开发小组与软件生产率随着软件项目规模的增大,需要组成开发小组共同承担软件开发项目中的某一任务,于是人与人之间必须通过交流来解决各自承担任务之间的接口问题,即通信问题 。 通信需要的时间和代价,会降低软件的生产率 。
开发小组的组织有以下原则：
1,软件开发小组的规模不宜太大,人数不能太多,一般 3-5人左右为宜 。
2,切忌在开发过程中增加人员,这将因增加人员之间的联系而降低效率 。
10.4.4 软件开发小组与软件生产率例：设一开发小组有 4个软件工程师 （ 图 10.11）,开发效率为 5000行 /年,
共有 6条通信路径,每条路径降低生产率 250行 /年,则小组生产率为：
5000× 4－ 250× 6＝ 18500（ 行 /年 ）
图 10.11
如为了加快进度,新增加 2人 （ 图 10.12）,
每人效率为 840行 /年,通信路径增加到 15条,
此时的小组生产率为：
20000＋ 840× 2－ 250× 15＝ 17930 （ 行 /年 ）
即新增加人,并未提高生产率 。
图 10.12
软件质量是一个软件企业成功的必要条件，其重要性无论怎样强调都不过分。而软件产品生产周期长，耗资巨大,如何有效地管理软件产品的质量一直是软件企业面临的挑战。 由于软件质量是难于定量度量的软件属性，主要从管理的角度讨论影响软件质量的因素。
我们把影响软件质量的因素分成三组,分别反映用户在使用软件产品时的三种不同倾向或观点 。 这三种倾向是：产品运行,产品修改和产品转移 。 信息系统作为一个产品,也可以参照这三种倾向来定义 。
10.5 软件质量保证产品运行产品修改产品转移
● 可移植性
● 可重用性
● 互运行性 （ 与另一个系统结合 ）
● 正确性 ● 完整性
● 健壮性 ● 可用性
● 效 率 ● 风险性
● 可理解性
● 可修改性
● 灵活性
● 可测试性
10.5 软件质量评价标准
10.5.1 软件质量因素的定义质量因素 定 义正确性 系统满足规格说明和优化目标的程度，即在预定环境下能正确地完成预期功能的程度。
健壮性 在硬件故障、操作错误等意外情况下，系统能作出适当反应的程度。
效 率 为完成预定功能，系统需要的计算资源的多少。
完整性 即安全性，对非法使用软件或数据，系统能够控制（禁止）的程度。
可用性 对系统完成预定功能的满意程度。
风 险 能否按照预定成本和进度完成系统看法,并为用户满意的程度 。
可理解性 理解和使用该系统的容易程度。
可维护性 诊断和改正运行时所发现错误所需工作量的大小。
灵活性 即适应性，修改或改进正在运行的系统所需工作量的大小。
可测试性 软件易测试的程度。
可移植性 改变系统的软、硬件环境及配置时，所需工作量的大小。
可再用性 软件在其它系统中可被再次使用的程度（或范围）。
互运行性 把该系统与另一个系统结合起来所需工作量。
10.5.1 软件质量因素的定义可以从两个方面来理解软件质量保证工作 。 一方面,从顾客驱动观点看,
注重于复审和校核方法并保证一致性,其关键是需要一种客观的标准来确定并报告软件开发过程及其成果的质量,一般由,软件质量保证小组,完成 。
另一方面，从管理者驱动观点看，注重于确定为了产品质量必须做些什么，并且建立管理和控制机制来确保这些活动能够得到执行。关键步骤如下：
１,以客户对于质量的需求为基础,对项目开发周期的各个阶段,建立质量目标 。
２、定义质量度量（ metrics）以衡量项目活动的结果，协助评价有关的质量目标是否达到。
３、确定质量活动。对于每一个质量目标，确定那些能够帮助实现该质量目标的活动，并将这些活动集成到软件生命周期模型中去。
４、执行已经确定的质量活动。
５、评价质量。在项目开发周期的各阶段，利用已经定义好的质量度量来评价有关的质量目标是否达到。
６、若质量目标没有达到，采取修正行动。
10.5.２软件质量保证工作
10.5.２软件质量保证工作软件度量和保证的条件通常包括,
1,适应性； 2,易学性； 3,可靠性
4,针对性； 5,客观性； 6,经济性软件质量度量方法有以下三种,
1,精确度量：使用质量度量评价准则进行详细度量,工作量大,
但度量精确度也高；
2,全面度量：可以与简易度量并用对各个质量设计评价准则进行度量,工作量可以控制在一定的范围内 。
3,简易度量
10.5.３软件项目的跟踪与控制
10.5.３ 软件项目的跟踪与控制在软件项目实施过程中进行跟踪与控制,是软件项目管理的重要内容,
也是保证软件质量的重要措施 。
可用不同的方法进行追踪：
10.6 软件能力成熟度模型（ CMM）
软件能力成熟度模型 CMM（ Capability Maturity Model） 是由美国卡内基 -梅隆大学软件工程研究所 (CMU/SEI)推出的评估软件能力与成熟度的一套标准 。 并提供了 软件过程评估 和 软件能力评价 两种评估方法和软件成熟度提问单 。 4年之后,SEI将软件过程成熟度框架进化为 软件能力成熟度模型 （ Capability Maturity Model For Software,简称 SW-CMM） 。
该标准基于众多软件专家的实践经验,侧重于软件开发过程的管理及工程能力的提高与评估,是国际上流行的软件生产过程标准和软件企业成熟度等级认证标准,它更代表了一种管理哲学在软件工业中的应用 。
目前,CMM认证已经成为世界公认的软件产品进入国际市场的通行证 。 为推动我国软件产业的发展,促进软件企业向正规化和国际化迈进,
应进一步引入和推广 CMM认证 。
10.6 软件能力成熟度模型 （ CMM）
10.6.1 CMM的基本概念
1,软件过程一个软件过程是指人们开发和维护软件及其相关产品所采取的一系列活动 。 其中软件相关产品包括项目计划,设计文档,源代码,测试用例和用户手册等 。 软件产品的质量主要取决于产品开发和维护的软件过程的质量 。 一个有效的,可视的软件过程能够将人力资源,物理设备和实施方法结合成一个有机的整体,并为软件工程师和高级管理者提供实际项目的状态和性能,从而可以监督和控制软件过程的进行 。
2,软件过程能力与性能软件过程能力是软件过程本身具有的按预定计划生产产品的固有能力 。
一个组织的软件过程能力为组织提供了预测软件项目开发的数据基础 。 软件过程性能是软件过程执行的实际结果 。 一个项目的软件过程性能决定于内部子过程的执行状态,只有每个子过程的性能得到改善,相应的成本,
进度,功能和质量等性能目标才能得到控制 。 由于特定项目的属性和环境限制,项目的实际性能并不能充分反映组织的软件过程能力,但成熟的软件过程可弱化和预见不可控制的过程因素 （ 如客户需求变化或技术变革等 ） 。
10.6.1 CMM的基本概念
3,软件过程成熟度软件过程成熟度是指一个软件过程被明确定义,管理,度量和控制的有效程度 。 成熟意味着软件过程能力持续改善的过程,成熟度代表软件过程能力改善的潜力 。
成熟度等级用来描述某一成熟度等级上的组织特征,每一等级都为下一等级奠定基础,过程的潜力只有在一定的基础之上才能够被充分发挥 。
成熟级别的改善包括管理者和软件从业者基本工作方式的改变,组织成员依据建立的软件过程标准执行并监控软件过程,一旦来自组织和管理上的障碍被清除后,有关技术和过程的改善进程能迅速推进 。
10.6.1 CMM的基本概念
10.6.2 软件过程的成熟度等级
CMM将软件过程的成熟度分为 5个级别 （ Maturity Levels）,如图所示,5个等级分别是：
初始级可重复级已定义级已管理级优化级
10.6.2 软件过程的成熟度等级
1,初始级 （ Initial）
2、可重复（ Repeatable）
3,已定义级 （ Defined）
4,已管理级 （ Managed）
5,优化级 （ Optimizing）
SW-CMM为每个软件组织建立和改善软件过程提供了一个阶梯式的过程成熟度框架,这一框架由 5个成熟度等级构成 。 除初始级以外,其余的成熟度等级都包含了若干个关键过程区域,每个关键过程区域又包含了若干个关键实践,这些关键实践按照 5个共同特点加以组织 。
图 10.13 成熟度等级单击鼠标左键查看相应内容初始级可重复级已定义级已管理级优化级初始级（ Initial）
在初始级,企业一般不具备稳定的软件开发与维护环境 。 项目成功与否在很大程度上取决于是否有杰出的项目经理和经验丰富的开发团队 。 此时,
项目经常超出预算和不能按期完成,
组织的软件过程能力不可预测 。
初始级
10.6.2 软件过程的成熟度等级图 10.14 初始级初始级可重复级已定义级已管理级优化级可重复级 (Repeatable),
在可重复级,组织建立了管理软件项目的方针以及为贯彻执行这些方针的措施 。 组织基于在类似项目上的经验对新项目进行策划和管理 。 组织的软件过程能力可描述为有纪律的,并且项目过程处于项目管理系统的有效控制之下 。
可重复级
10.6.2 软件过程的成熟度等级图 10.14 可重复级初始级可重复级已定义级已管理级优化级已定义级（ Defined）：
在已定义级,组织形成了管理软件开发和维护活动的组织标准软件过程,
包括软件工程过程和软件管理过程 。
项目依据标准定义自己的软件过程进行管理和控制 。 组织的软件过程能力可描述为标准的和一致的,过程是稳定的和可重复的并且高度可视
10.6.2 软件过程的成熟度等级图 10.15 已定义级初始级可重复级已定义级已管理级优化级已管理级（ Managed）：
在已管理级,组织对软件产品和过程都设置定量的质量目标 。 项目通过把过程性能的变化限制在可接受的范围内,实现对产品和过程的控制 。 组织的软件过程能力可描述为可预测的,
软件产品具有可预测的高质量已管理级
10.6.2 软件过程的成熟度等级图 10.16 已管理级初始级可重复级已定义级已管理级优化级优化级（ Optimizing）：
在优化级,组织通过预防缺陷,技术创新和更改过程等多种方式,不断提高项目的过程性能以持续改善组织软件过程能力 。 组织的软件过程能力可描述为持续改善的 。
优化级
10.6.2 软件过程的成熟度等级图 10.17 优化级表 1描述了 SW-CMM不同成熟度等级过程的可视性和过程能力 。
等级 成熟度 可视性 过程能力
1 初始级 有限的可视性 一般达不到进度和成本的目标
2 可重复级 里程碑上具有管理可视性 由于基于过去的性能，项目开发计划比较现实可行
3 已定义级 项目定义软件过程的活动具有可视性基于已定义的软件过程，组织持续地改善过程能力
4 已管理级 定量地控制软件过程 基于对过程和产品的度量，组织持续地改善过程能力
5 优化级 不断地改善软件过程 组织持续地改善过程能力表 10.3 可视性与过程能力的比较
10.6.2 软件过程的成熟度等级表 10.4 SW-CMM的关键过程区域
10.6.3 关键过程区域过程分类成熟度等级管理过程 组织过程 工程过程
5、优化级 技术改革管理过程更改管理缺陷预防
4、已管理级 定量过程管理 软件质量管理
3、已定义级集成软件管理组间协调组织过程焦点组织过程定义培训大纲软件产品工程同行评审
2、可重复级需求管理软件项目策划软件项目跟踪与监督软件子合同管理软件质量保证软件配置管理
1、初始级 无序过程
10.6.3 关键过程区域除了初始级外,每一成熟度等级又由若干个关键过程区域 (Key Process
Areas)构成 。 关键过程区域指出为了达到某个成熟度等级所要着手解决的问题 。 达到一个成熟度等级,必须实现该等级上的全部关键过程区域 。 要实现一个关键过程区域,就必须达到该关键过程区域的所有目标 。
关键过程区域 KPY(Key Process
Areas)是一组相关的活动，可按照上表描述，也可按照图 10.18描述。
10.6.3 关键过程区域初始级需求管理软件项目计划软件项目跟踪与监督软件子合同管理软件质量保证软件配置管理可重复级软件机构过程关注点软件机构过程定义培训计划整体化软件管理软件产品工程组间合作同行评审已定义级定量过程管理软件质量管理已管理级过程变更管理预防故障技术变更管理优化级图 10.18 关键过程域
10.6.4 软件企业如何实施 CMM
软件是促进我国电子信息产业发展的关键技术 。 而要发展我国的软件产业,在战略上,必须将软件产业作为我国高新技术产业的龙头和国民经济发展的新增长点,在策略上,必须走软件过程管理专业化的道路 。
但目前国内的绝大部分软件企业处于 CMM的初级阶段，没有基础和经验。本节讨论软件企业实施 CMM或通过 CMM评估所必须经历的步骤。
提高思想认识进行 CMM培训和咨询工作 确定合理的目标 成立工作组制定和完善软件过程内部评审正式评估根据评估结果改进软件过程
10.6.4 软件企业如何实施 CMM
图 10.19 CMM步骤单击 处查看相关内容中国这样的一个大国,软件销售额还不到世界市场的 0.5%。 我国软件企业除少数几家在 500人以上外,多数是在 50人以下的民营,
集体和个人的软件公司 。 以开发技术和规范化程序来衡量,总体上仍是相当落后的,大多数企业仍为手工作坊式制作,产品缺乏市场竞争力 。 因此,软件过程管理已成为发展我们软件产业的一个关键性问题 。
实施 CMM对软件企业的发展起着至关重要的作用,CMM过程本身就是对软件企业发展历程的一个完整而准确的描述,企业通过实施 CMM,可以更好地规范软件生产和管理流程,使企业组织规范化 。 而且,只有在国际市场取得成功的产品和企业才具有长久的竞争力和生命力,
10.6.4 软件企业如何实施 CMM
１,提高思想认识根据 CMM模型的要求,一个项目的开发一定要有章可循,而且要做到有章必循,这两点都离不开培训 。 培训工作需要投入很大的人力,物力和财力,只有企业的管理人员和软件开发人员对 CMM真正了解和认识了,自觉地按 CMM的方法去进行工作,才能真正实施
CMM，
培训的内容需要精心地准备,主要有两个方面,第一,对所有员工包括经理在内的最基本的软件工程和 CMM培训知识；第二,对各个工作组的有关人员提供专业领域知识等方面的培训；此外,在每次开发过程中,还要对普通人员进行软件过程方面的培训 。
10.6.4 软件企业如何实施 CMM
２、进行 CMM培训和咨询工作
CMM模型划分为 5个级别,共计 18个关键过程域,52个目标,300
多个关键实践 。 每一个 CMM等级的评估周期 （ 从准备到完成 ） 约需 12-
30个月 。 无论一个软件企业的软件过程处于什么样的水平,都可以在
CMM框架的 5个级别中找到自己的位置 。
因此,要实施 CMM,首先应该对本企业的现状有一个准确的评估,
然后再结合企业的实际情况选择 CMM的切入点,确定总体目标 。 这个目标包括在多长时间之内,需要投入多少人力,物力和财力,要达到哪一级 。
由于软件过程的建立和改进是一个渐进的,分轻重缓急的,逐步完善的过程 。 所以,在总体目标已经确定的前提下,还要制订近期目标和长期目标 。
10.6.4 软件企业如何实施 CMM
３,确定合理的目标在 CMM的实施过程中,工作组的成立是一个关键步骤 。 有几个必不可少的重要的组织包括：软件工程过程组,软件工程组,系统工程组,
系统测试组,需求管理组,软件项目计划组,软件项目跟踪与监督,软件配置管理组,软件质量保证组,培训组 。 例如：
软件工程过程组 由专家组成,统领 CMM实施活动,协调全组织软件过程的开发和改进活动,制定,维护和跟踪与软件过程开发和改进活动有关的计划,定义用于过程的标准和模板,负责对全体人员培训有关软件过程及其相关的活动 。
软件工程组 负责一个项目的软件开发和维护活动 （ 即需求分析,设计,编码和测试 ）
系统工程组 负责规定系统需求；将系统需求分配给硬件,软件和其他成分；规定硬件,软件和其他成分的界面；以及监控这些成分的设计和开发以保证它们符合其规格说明 。
10.6.4 软件企业如何实施 CMM
４,成立工作组
CMM模型强调软件过程的改进,如果企业还没有一个文档形式的软件过程,则首要任务是对当前的工作流程进行分析,整理及文档化,从而制定出一个具有本企业风格的软件过程,并用该文档化的过程指导软件项目的开发 。
如果已经具备了软件过程,则要对这个过程做内部评估,对照
CMM的要求,找出问题,然后对这个过程进行补充修改 。 在具体实施的过程中,可以选择有一定代表性和完善性的项目组或项目进行试点,跟踪,监督改进后的软件过程的实施情况,执行改进活动的状态 。
10.6.4 软件企业如何实施 CMM
５、制定和完善软件过程
CMM每一级别的评估都由美国卡内基梅隆大学的软件工程研究所
（ CMU/SEI） 授权的主任评估师领导一个评审小组进行 。 目前,全世界一共只有三百多个主任评估师大部分在美国,而我国大陆还没有一个主任评估师 。 CMM评估中要聘请外籍主任评估师费用较高 。 据估计,要通过一个级别的 CMM评估,费用是通过 ISO9000认证的十多倍 。
因此,建议软件企业在进行正式评估之前,先进行内部评审或评估 。
这种内部评审包含两层含义 。 第一种就是软件企业组织自己内部成员,
严格,认真地按照 CMM规范评估过程,对自己的软件过程进行评审,
找出其中的不足点并进行改进 。
第二种含义就是在全国范围内,由有关软件工程和 CMM专家组成一个专门的 "内部评审 "机构,负责指导协调实施 CMM的活动,对国内软件企业 CMM评估进行 "预先评估 "。 这种预先评估,可降低软件企业通过正式 CMM评估的风险,减少软件企业实施 CMM的成本,为企业最终获得国际 CMM认证打下基础 。
10.6.4 软件企业如何实施 CMM
６,内部评审目前主要有两种基于 CMM的评估方法,一种是 CBA-SCE(CMM-
Based Appraisal for Software Capability Estimation),它是基于 CMM对组织的软件能力进行评估,是由组织外部的评估小组对该组织的软件能力进行的评估 。 另一种是 CBA-IPI(CMM-Based Appraisal for Internal
Process Improvement),它是基于 CMM对内部的过程改进进行的评估,
是由组织内部的小组对软件组织本身进行评估以改进质量,结果归组织所有,目的是引导组织不断改进质量 。
CBA评估过程主要分成两个阶段：准备阶段和评估阶段 。 在评估的最初几天,小组成员的主要任务是采集数据,回答 SEI的 CMM提问单,文档审阅以及进行交谈,对整个组织中的应用有一个全面的了解 。
然后进行数据分析 。 评估员要对记录进行整理,把这些数据与 CMM模型进行比较,最后给出一个评估报告 。 在评估报告的基础上,评估小组成员起草一个评估结果 。
10.6.4 软件企业如何实施 CMM
７,正式评估根据 IDEAL模型,成熟度的评估只是软件过程改进中的一个环节,
如果这个环节与软件过程改进的其他环节不能很好地结合,那么,
CMM评估对于软件过程改进所应具有的作用就得不到发挥 。
一般来说,应该在评估之后很快地作出软件过程改进的计划,因为这时大家对评估结果和存在的问题仍有一个深刻的认识 。 计划在软件过程改进中是一个非常必要的阶段,只有有效的计划,才能确保软件过程得到有效的改进 。
10.6.4 软件企业如何实施 CMM
８,根据评估结果改进软件过程因为软件过程成熟度的升级本身就是一个过程,而且全面引进应用 CMM所涉及的范围非常广,要求人力,财力与设备资源的投入相当大 。 所以在实施 CMM时,企业千万不要一开始就把目标定位过高,不必一下子去满足某一能力成熟度等级的所有目标 。 而要根据企业自身的情况,试行某些关键过程域的一部分关键实践活动,
逐步完善软件过程和成熟度的升级 。
软件企业在实施 CMM的过程中,应当处理好 CMM实施和认证的关系 。 实施是基础,认证是结果 。 只有认真扎实的实施,才可能有认证的通过 。 由于我国大部分软件企业距离 CMM的认证有相当大的距离,最好先按照 CMM严格的软件工程方法,致力于改进企业的管理,提高软件开发能力,而先不要搞软件能力评鉴,追求认证,
评级等 。 等到能力成熟后,再进行认证 。 这样可以避免和杜绝华而不实,弄虚作假的现象 。 应该把实施 CMM作为提高软件企业管理水平和提高软件质量的突破口,追求真正的软件能力和水平的提高,
而不是把单纯的 CMM软件认证作为一个唯一的目标 。
ＣＭＭ小结
10.1 软件工程管理概述
10.2 可行性研究
10.3 成本估算技术
10.4 软件项目的组织与计划
10.6 软件能力成熟度模型
10.5 软件质量保证第十章 软件需求分析
10.1 软件工程管理概述软件工程管理是对软件项目的开发管理，是对整个软件生存期的所有活动进行管理。任何工程的成败，都与管理的好坏密切相关，软件工程更不例外。尤其是软件产品的特殊性，软件工程的管理对于保证软件产品的质量具有极为重要的作用。
随着软件的规模和复杂度的不断增大，开发人员的增加以及开发时间的增长，这些都增加了软件工程管理的难度。
例如,Windows 2000的开发 是微软公司历史上最艰巨的任务，仅核心部门的的成员就有 2500人，测试用的代码就有 1000万行，测试中所用到的脚本程序就有 6500种 … 。象规模如此之大的软件系统，如果没有科学的、规范的、有效的管理，是不可能成功的。因此 软件工程管理成为软件工程的重要研究内容之一。
10.1 软件工程管理概述任何技术先进的大型项目的开发如果没有一套科学的管理方法和严格的组织领导,是不可能取得成功的 。 即使在管理技术较成熟的发达国家中尚且如此,在我国管理技术不高,资金比较紧缺的情况下,大型软件项目开发的管理方法及技术就显得尤为重要 。
软件工程管理的对象是软件工程项目,因此 软件工程管理涉及的范围覆盖了整个软件工程过程 。
软件工程管理的主要任务有：
一,软件可行性分析与成本估算二,软件生产率及质量管理三,软件计划及人员管理
10.1.1 软件管理的任务与目标
10.1.1 软件管理的任务与目标
10.1.2 软件作用的范围确定软件的作用范围是软件项目计划的第一项活动 。 是要对 用户要求解决的问题进行确切定义,进一步分析软件开发的风险,以便制定软件计划 。
10.1.2 软件作用的范围从以下方面考虑软件的作用范围：
软件的功能,性能
接口 （ 与硬件,软件工具,人,过程的一系列操作 ）
软件的可靠性关于软件范围的叙述都应给出定量的数据 （ 例如,同时使用该软件的用户数目,发送表格的长短,最大允许响应时间等等 ）,指明约束条件或限制 （ 例如,产品成本限制了存储的容量 ） 。 此外还要叙述某些质量因素 （ 例如,给出的算法是否容易理解,是否使用 Ada语言等 ） 。
10.1.3 资源要求
1,人力资源 ——在考虑各种软件开发资源时,人是最重要的资源 。
在安排开发活动时必须考虑人员的技术水平,专业,人数,以及在开发过程中各阶段对各种人员的需要 （ 图 10.2） 。
2,硬件资源 ——主要包括宿主机 Host Machine（ 软件开发时使用的计算机及外围设备 ）,目标机 Target Machine（ 运行已开发成功的软件的计算机及外围设备 ） 和其他硬件设备 （ 专用软件开发时需要的特殊硬件资源 ） 。
3,软件资源 ——即软件工具集,主要有业务系统计划工具集,项目管理工具集,支援工具,分析和设计工具,编程工具,组装和测试工具,原型化和模拟工具,维护工具,框架工具等 。
4,软件复用性及软件部件库 ——为了促成软件的复用,以提高软件的生产率和软件产品的质量,应建立可复用的软件部件库 。 对于软件的复用,人们经常忽略,但这却是相当重要的一环 。
10.1.3 资源要求图 10.2 Putnam _ Norden 曲线高低计划需求分析初步设计详细设计编码单元测试整体测试功能测试管理人员 高级技术人员初级技术人员通常，软件开发所需的资源，可由“金字塔“型（图 10.1）,描述。
人 — 人员的技术水平，专业和数量。
工具 — 主要是软、硬件工具。
根据统计结果,在软件开发过程中,不同阶段的人员需求情况如 图
10.2,按照 Putnam _ Norden 曲线所示 。
人工具问 题分析在软件开发的不同阶段各类人员的需求情况，为什么？
图 10.1
10.1.3 资源要求 Putnam _ Norden 曲线
10.2 可行性研究可行性研究又称为可行性分析,目的是避免盲目投资,减少不必要的损失 。 即以最小的代价在最短的时间内确定该项目是否可能开发,是否值得 。
任何软件的开发,都会受到开发时间,经费及开发环境及技术的限制 。
及早对软件项目的可行性做出细致而谨慎的评估是十分必要的 。 若在定义阶段及早发现将来开发工作中可能出现的问题,及早地作出决定,可将项目开发的风险降到最低 。
可行性研究的主要内容有：
技术上可行 经济上可行 社会上可行可行性报告可行性报告可行性报告可行性报告 可行性分析的结果报告
10,2 可行性研究
10.2.1 可行性研究的任务
10.2.1 可行性研究的任务技术上可行经济上可行社会上可行技术上可行经济上可行社会上可行现有技术,资源及限制能否支持和实现系统的功能,
性能 。 主要是技术风险问题 。
进行成本估算及效益评估,确定项目是否值得开发 。
主要指系统开发后能否运行,是否存在合同,责任,
侵权,用户组织管理等方面的问题 。
一、可行性分析的任务二,可行性分析步骤确定项目规模和目标 。
研究现行系统 （ 如果存在 ） 。
建立新系统的高层逻辑模型 。
用系统流程图或数据流图 （ DFD图 ） 描述 。
提出实现高层逻辑模型的各种方案,并对各方案进行评价 。
推荐可行的方案 。
编写可行性报告 。
进行可行性分析时,通常用系统流程图来描述所要开发的系统 。 用于描述项目的处理流程,范围,功能等 。
1、系统流程图的基本符号处理框输入 /输出文档连接换页连接数据流磁盘联机存储显示人工输入人工操作辅助操作通信链路一、系统流程图
10.2.2 可行性分析的描述手段
10.2.2 可行性分析的描述手段
2、系统流程图举例 — 库存管理系统功能：
库存零件的种类和数量存放在库存清单主文件中。
随时更新库存文件。
当某零件少于库存临界值时，产生订货报告，通知采购部门。
输入变更记录库存管理模块订货信息报告生成模块订货报告库存清单
10.2.2 可行性分析的描述手段二、数据流图也可以用ＤＦＤ图来对系统进行描述。
图 10.3
可行性研究报告（参考格式）
一,引言系统名称,目标,功能,开发组织单位,服务对象等 。
二,系统开发的背景,必要性和意义
1,现行系统的调查研究组织机构,业务流程,工作负荷,费用,人员,设备,计算机应用情况,存在问题等 。
2,需求调查和分析用户提出的需求及考虑经济改革和发展需要进行预测结果 。
三,新系统的几种方案介绍
1,拟建系统目标
2,系统规模及初步方案 (粗略的逻辑模型 )
3,系统的实施方案 (计划安排 )
4,投资方案
5,人员培训及补充方案
6,其它可供选择的方案
10.2.3 可行性研究报告
10.2.3 可行性研究报告
10.2.2 可行性研究报告 (续 )
可行性研究报告（参考格式）
可行性研究报告（参考格式）
四,可行性研究
1,技术上的可行性 (按系统目标衡量 )
(1)对现有技术的估价
(2)使用现有技术进行系统开发的可行性
(3)对技术发展可能产生影响的预测
(4)关键技术人员的数量和水平估计
2,经济上的可行性 (估算成本 /效益比 )
(1)现有的经济条件
(2)开发,运行费用
(3)对系统效益的估计
(4)投资回收期
(5)成本 /效益比
3,系统运行的可行性
(1)对组织机构的影响
(2)人员适应的可行性
(3)环境条件的可行性五,几种方案的比较分析六,结论
(可按某方案立即执行,等某些条件成熟后再执行或不可行等等 )
可行性分析报告经审批后,可进行需求分析工作 。
10.3 成本估算技术
10.3 成本估算技术成本估算是可行性分析的重要依据，也是软件管理的重要内容，直接影响到软件开发的风险。
软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价,即主要是人的劳动的消耗 。 因此,软件产品开发成本的计算方法不同于其它物理产品的成本的计算 。
软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此软件成本估算，应以软件计划、需求分析、
设计、编码到测试的软件开发全过程所花费的代价为依据。
另外，必须注意，对于一个大型项目，由于其项目的复杂度，成本估算并不是一件简单的事，必须建立相应的估算模型，按照一定的方法、
技术来进行估算。
10.3.1 影响成本估算的因素为了正确进行成本估算,首先要了解影响成本估算的主要因素：
1,软件人员的业务水平 软件人员的素质,经验,掌握知识的不同,在工作中表现出很大的差异 。
2,软件产品的规模及复杂度规模,按 YOURDON分类法将软件产品的规模分为超小型,小型,中型,
大型,超大型,极大型 。
复杂性,应用程序,实用程序,系统程序分别由低到高排列 。
3,开发所需时间显然,开发时间越长成本越高 。 对确定规模,复杂度的软件存在一个
,最佳开发时间,,即是完成项目的最短时间,选取最佳开发时间来计划开发过程,可以取得最佳经济效益 。
4,软件开发技术水平指开发方法,工具,语言等,技术水平越高,效率越高 。
5,软件可靠性要求一般可靠性要求愈高,成本愈高 。
§ 10.3.1 影响成本估算的因素类 别 参加人数 研制期限 产品规模（源代码行）
微 型 1 1 –4 周 0.5K
小 型 1 1 – 6 月 1K – 2K
中 型 2 - 5 1 – 2 年 5 – 50 K
大 型 5 - 20 2 – 3 年 50 – 500 K
甚大型 100 - 1000 4 – 5 年 1M
极大型 2000 -5000 5 – 10 年 1M – 10 M
微型 可不作严格的系统分析和设计,在开发过程中应用软件工程的方法 。
小型 如数值计算或数据处理问题，程序往往是独立的，与其它程序无接口，
应按标准化技术开发。
中型 如应用程序及系统程序，存在软件人员之间，软件人员与用户之间的密切联系、协调配合。应严格按照软件工程方法开发。
大型 编译程序、小型分时系统、应用软件包、实时控制系统等。必须采统一标准，严格复审，但由于软件规模庞大，开发过程可能出现不可预知的问题。
甚大型 如远程通信系统、多任务系统、大型操作系统、大型数据库管理系统、
军事指挥系统等。子项目间有复杂的接口，若无软件工程方法支持，开发工作不可想象。
极大型 如大型军事指挥系统、弹道防御系统等，这类系统极少见，更加复杂。
规模表 10.1
10.3.2 成本估算模型二,成本估算模型软件成本估算模型可分为两大类：理论模型和统计模型,具体介绍以下模型：
1,Halstead理论模型
2,统计估算模型
3,构造性成本模型
10.3.2 成本估算模型一,软件成本估算量软件成本 估算通常是对以下量进行估算：
源代码行 （ LOC）
是指机器指令行 /非机器语言的执行步开发工作量常用的单位是：人 -月 （ PM） 人 -年 （ PY） 人 -日 （ PD）
软件生产率单位劳动量所能完成的软件数量：
LOC/PM ￥ /LOC ￥ /PM
软件开发时间
10.3.3 Halstead 理论模型理论模型来源于软件度量学的研究，根据四个原始量进行估算：
n1：不同运算符个数 n2：不同运算对象个数
N1：运算符总数 N2：运算对象总数估算模型：
程序长度 Ｎ＝ n1log2 n1＋ n2 log2 n2
程序量 V＝Ｎ log2(n1＋ n2)
程序级别的度量 Ｌ＝Ｖ ＊ ／Ｖ （Ｖ?Ｖ ＊ ）
其中Ｖ ＊ 为无暇程序的程序量，对特定程序Ｖ ＊ 为常数。程序级别愈低，程序量愈大。
由于Ｖ ＊ 不易计算，可按照以下公式计算：
所花费精力 Ｅ＝Ｖ／Ｌ
程序开发时间 Ｔ＝Ｅ／Ｓ
10.3.3 Halstead 理论模型 理论模型１
Ｌ＝ ２ Ｎ２n1 Ｎ２×
该模型经过实际检验,估算结果是准确的,但由于四个原始量在可行性分析阶段根本无法获得,因此 Halstead 理论模型往往并不用于实际成本估算,而是用于验证其它估算模型的准确性 。
10.3.3 Halstead 理论模型
ai — 估计的最小行数
bi — 估计的最大行数
mi — 最可能的行数
10.3.4 专家估算模型即 源代码行 估算模型 （ Deiphi技术 ）
由 Rand公式提出的 Deiphi技术,又称为专家估算模型,是由 n位专家进行成本估算 。 每位专家根据系统规格说明书,反复讨论给出 ai,bi及
mi的值,并按照下式反复估算 源代码 的 期望值 Li,期望中值 L。
ai+4mi+bi
6
1
n?
n
i
iL
1
Li = L=
将估算的源代码行数,乘以根据经验推算的每行源代码所需成本,
即为该软件的成本 。
10.3.4 专家估算模型10.3.4 专家估算模型
10.3.5 IBM估算模型
10.3.5 IBM 估算模型 （ 静态,单变量模型 ）
1977年由 Waiston 和 Felix 总结了 IBM联合系统分部 （ FSD） 负责的６０个项目的数据,利用最小二乘法拟合,得到如下估算公式：
工 作 量,E=5.2*L （ PM）
项目持续时间,D=4.1*L （ 月 ）
人员需要量,S=0.54*E （ 人 ）
文 档 数,DOC=49*L （ 页 ）
其中,L ＿ 源代码行,以千行计 。
IBM估算模型是一种静态单变量模型,它利用已估算的结果,如源代码行,来估算各种资源的需求量,
但 IBM 估算模型不是一种通用模型,因此应用中应根据具体实际情况调整模型中的参数,
10.3.5 IBM 估算模型
10.3.6 Putnam 估算 模型 （动态、多变量模型）
L
Ck td
3
3 4Ｋ＝
31 34Ｌ＝ Ck K td
Putnam 估算 模型 是一种动态多变量模型,是根据一些大型项目中工作量的分布情况 （ 图 10.4） 而推导出来的,
10.3.6 Putnam 估算 模型其中,L- 源代码行,K - 所需人力 （ PY）,td - 开发时间,
CK -技术水平常数,CK值与开发环境有关 。 （ 差,2500-2000，
正常,10000-8000,好,12500-11000）
10.3.2 成本估算模型图 10.4 大型项目的工作量分布情况运行与维护系统开发功能设计规格说明系统定义安装测试与确认设计与编码系统定义功能设计规格说明时间
10.3.7 COCOMO模型
10.3.7 COCOMO模型
COCOMO模型 （ Constructive Cost Model） 由 TRW公司开发,是由
Boehm提出的结构型成本估算模型,其特点是精确,易用 。
是一种层次模型,按照其祥细程度分为三级：即基本的 COCOMO模型,
中间的 COCOMO模型和详细的 COCOMO模型 。
该模型主要对工作量ＭＭ （ 单位,PM） 和进度 TDEP（ 单位：月 ） 进行估算 。 模型中考虑到估算量与开发环境有关,将开发项目分为三类：
组织型 （ Organic）
规模不大 (<5万 ),较简单,开发人员对产品目标理解充分,经验丰富,
对软件开发环境熟悉 。 大多数应用软件及老的操作系统,编译系统属此类 。
嵌入型 （ Embadded)
软件,硬件的关系紧密,操作有限制条件,对接口,数据结构,算法要求较高 。 如大型复杂的事务处理系统,大型,超大型的操作系统,军事指挥系统,航天控制系统等 。
半独立 型 （ Semidetached)
对项目要求界于上述两者之间,规模复杂度中等 。 如新操作系统,大型数据库,生产控制等软件属此类 。
10.3.7 COCOMO模型
al k lo cc?ＭＭ＝
① 基本的 COCOMO模型 （ 静态单变量模型 ）
其中,MM — 工作量 （ PM）,KLOC — 估计的源代码行
Cl — 模型系数,?—模型指数
Cl,? 取决于开发项目的模式为组织型,半独立型或嵌入型 。
10.3.7 COCOMO模型 ① 基本的 COCOMO模型下表是根据 63个项目的数据统计结果,按照 基本的 COCOMO模型估算的工作量和进度 。
总体类型 工作量 进度组织型 MM=10.4（ KLOG） 1.05 TDEV=10.5（ MM） 0.38
半独立型 MM=3.0（ KLOG） 1.12 TDEV=10.5（ MM） 0.35
嵌入型 MM=3.6（ KLOG） 1.20 TDEV=10.5（ MM） 0.32
表 10.2
其中,fi — 成本因素包括：
生产因素 （ 可靠性,数据库规模,软件复杂度 ）
计算机因素 （ 时间约束,存储约束,环境变更率,计算机换向时间 ）
人员因素 （ 系统分析员能力,经验,程序员能力,开发人员环境知识,程序时间语言知识 ）
项目工程因素 （ 设计技术,软件工具,进度限制约束 ）
③ 详细的 COCOMO模型在考虑成本因素 fi时,按照开发阶段分别给出更加详细的值 。
al k lo cc
15
1i
ifＭＭ＝
② 中间的 COCOMO模型进一步考虑了 15种影响软件工作量的因素,更加合理的估算软件工作量和进度 。
② 中间的 COCOMO模型10.3.7 COCOMO模型
10.3.8 成本估算方法
1,自顶向下的估算方法从项目的整体出发,进行类推 。 即据以前完成的同类项目的总成本,推算当前项目的总成本,再将其分配到各开发任务中 。
特点：简便,估算工作量小,误差大 。
2,自底向上的估计法把待开发的软件细分,直到每一子任务都已经明确所需要的开发工作量,
然后把它们累加起来 。
特点：精确度高,但缺少子任务 （ 模块 ） 间的联系 。
3,差别估计法综合上述两种方法而得,将项目与已经完成的项目进行类比,相同部分按照已经完成的项目估算,不同部分另行估算 。
特点：估算较精确,但区分类比较困难 。
10.3.8 成本估算方法对于大型软件项目来说,由于项目的复杂型,成本估算并不单纯是一个计算过程,还需要进行一系列的估算处理,处理手段主要是分解和类比 。
一般有以下方式：
注意,在对实际项目进行估算时,通常使用综合方法 。
10.3.9 成本 /效益分析成本／效益分析的第一步是估算成本和运行费用 （ 系统的操作费用和维护费用 ）,系统的经济效益则等于因使用新系统而增加的收入,加上使用新系统可以节省的运行费用 。
1,货币的时间价值通常以利率形式表示 。 假设,年利率为 i,P元钱在 n年后的价值 F为：
2,投资回收期投资回收期即工程累计经济效益等于最初投资所需要的时间 。
3,纯收入在整个生存周期内新系统的累计经济效益与投资之差称为纯收入 。
4,投资回收率用于衡量投资效益的大小,并且可以用它和年利率比较,。 设现在的投资额为Ｐ：
Ｐ＝Ｆ 1 /（ 1+j） ＋Ｆ 2 /（ 1+j） 2 ＋ … ＋Ｆ n /（ 1+j） n
其中：Ｆ i是第 i年年底的效益 （ i=1,2,3,… n） ；
n是系统的使用寿命； j是投资回收率 。
10.3.9 成本 /效益分析
nF＝ P（ 1+i）
10.4 软件项目的组织与计划
10.4 软件项目的组织与计划软件项目的组织管理,需要多方面的综合知识,涉及到系统工程,统计学,心理学,社会学,经济学,乃至法律等方面的问题 。 尤其涉及到社会因素,精神因素,人的因素,比技术问题要复杂得多 。
软件项目的管理，也不能完全照搬外国的经验，还必须结合我国的实际情况，结合我们的工作条件、人员和社会环境等多种因素考虑。
此外，实践是取得管理经验的重要途径。很显然，管理能够取得效率，能够赢得时间，是软件能够开发成功的关键。
10.4.1 软件项目管理的特点软件产品与其他任何产业的产品不同,它是非物质性的产品,是知识密集型的逻辑思维产品 。 由于软件的这种独特性,使软件项目管理过程更加复杂和难以控制 。
软件项目管理的主要特点是：
1,软件项目管理涉及的范围广,涉及到软件开发进度计划,人员配置与组织,项目跟踪与控制等 。
2,应用到多方面的综合知识,特别是要涉及到社会的因素,精神的因素,认知的因素,这比技术问题复杂得多 。
3,人员配备情况复杂多变,组织管理难度大 。
4,管理技术的基础是实践,为取得管理技术成果必须反复实践 。
10.4.1 软件项目管理的特点
10.4.2 软件开发进度计划
10.4.2 软件开发进度计划软件开发进度计划安排是一件困难的任务,既要考虑各个子任务之间的相互联系,尽可能并行地安排任务,又要预见潜在的问题,提供意外事件的处理意见 。
描述计划进度的主要工具有：一般的表格工具,甘特图,PERT技术与
CPM方法 。
１,一般的表格工具例如：进度表 （ 图 10.5）
▲ ▲ ▲软件测试
▲ ▲ ▲编码
▲ ▲详细设计
▲ ▲ ▲总体设计
▲ ▲ ▲需求分析
１ 2 3 4 5 6 7 8 9 10 11 12 任务 月份图 10.5 进度表
0
10
20
30
40
50
60
70
一月 二月 三月 四月 五月 六月需求分析总体设计详细设计编码、测试
10.4.2 软件开发进度计划
2,甘特图 （ Gantt Chart）
用水平线段表示任务的工作阶段；线段的起点和终点分别表示任务的开始和完成时间,线段的长度表示完成任务所需的时间 。 图 10.6给出了具有五个任务的甘特图 。
2、甘特图（ Gantt Chart）
图 10.6 甘特图周
1 2 3 4 5 6 7 8 9 10 11
任务
A
B
C
D
E
当前进度
○△
○△
○△
○△
○△ 优点,标明了各任务的计划进度和当前进度。能够动态反映软件开发的进展情况。
缺点,不能够反映多个任务之间的复杂逻辑关系 。
完成 计划完成
○ 文档编写 △ 评审图 例
3,时标网状图 （ timescalar network）
也称为改进的 Gantt图,增加了各子任务之间的逻辑依赖关系 。 如图
10.7所示；表示 A,B,C,D,E５个任务之间在进度上的依赖关系 。 例如 E2
的开始取决于 A3的完成 。 虚箭头表示虚任务 。
10.4.2 软件开发进度计划
4,PERT技术和 CPM方法
PERT（ Program evaluation & review technique)计划评审技术或
CMP（ Critical path method） 关键路径法,都是采用网络图来描述项目的进度安排 。 如图 10.9描述了开发模块 A,B,C的任务网络图 。 图中各边上所标注的数字为该任务所持续的时间,数字结点为任务的起点和终点 。
1 2
0 3 7 8
4 5
6 周任务
5 10 15 20
A1 A2 A3
B1
B2 E1 E2
C
D1 D2
D3
图 10.8 网状时标图
0
2
3
4
5
6
7
1
8起点
A
编码
A调试
B编码
6
6
8
78 8 7 9
6 8 BC组装测试
5
图 10.9 任务网络图假设红线为关键路径,即完成所有任务的主要路径 。
3、时标网状图
10.4.3 人员配备与组织三,评价人员的条件
1,掌握计算机软件的基本知识和技能；
2,善于分析和综合问题,具有严密的逻辑思维能力；
3,工作踏实,细致,不靠运气,遵循标准和规范,具有严格的科学作风；
4,工作中耐心,有毅力,有责任心；
5,善于听取意见,善于团结协作,有良好的人际关系；
6,具有良好的书面和口头表达能力 。
10.4.3 人员配备与组织如何合理的配备人员是成功的完成软件项目的切实保证 。 所谓合理配备人员应该包括：按不同阶段适时任用人员,恰当掌握人员标准 。
一,项目各阶段所需人员按照 Putnam_Norden 曲线进行分配 。
图 10.10 Putnam _ Norden 曲线高低 计划需求分析初步设计详细设计编码单元测试整体测试功能测试管理人员 高级技术人员初级技术人员二,配备人员应该遵守的原则
1,重质量；
2,重培训
3,阶梯提升：
10.4.4 软件开发小组与软件生产率随着软件项目规模的增大,需要组成开发小组共同承担软件开发项目中的某一任务,于是人与人之间必须通过交流来解决各自承担任务之间的接口问题,即通信问题 。 通信需要的时间和代价,会降低软件的生产率 。
开发小组的组织有以下原则：
1,软件开发小组的规模不宜太大,人数不能太多,一般 3-5人左右为宜 。
2,切忌在开发过程中增加人员,这将因增加人员之间的联系而降低效率 。
10.4.4 软件开发小组与软件生产率例：设一开发小组有 4个软件工程师 （ 图 10.11）,开发效率为 5000行 /年,
共有 6条通信路径,每条路径降低生产率 250行 /年,则小组生产率为：
5000× 4－ 250× 6＝ 18500（ 行 /年 ）
图 10.11
如为了加快进度,新增加 2人 （ 图 10.12）,
每人效率为 840行 /年,通信路径增加到 15条,
此时的小组生产率为：
20000＋ 840× 2－ 250× 15＝ 17930 （ 行 /年 ）
即新增加人,并未提高生产率 。
图 10.12
软件质量是一个软件企业成功的必要条件，其重要性无论怎样强调都不过分。而软件产品生产周期长，耗资巨大,如何有效地管理软件产品的质量一直是软件企业面临的挑战。 由于软件质量是难于定量度量的软件属性，主要从管理的角度讨论影响软件质量的因素。
我们把影响软件质量的因素分成三组,分别反映用户在使用软件产品时的三种不同倾向或观点 。 这三种倾向是：产品运行,产品修改和产品转移 。 信息系统作为一个产品,也可以参照这三种倾向来定义 。
10.5 软件质量保证产品运行产品修改产品转移
● 可移植性
● 可重用性
● 互运行性 （ 与另一个系统结合 ）
● 正确性 ● 完整性
● 健壮性 ● 可用性
● 效 率 ● 风险性
● 可理解性
● 可修改性
● 灵活性
● 可测试性
10.5 软件质量评价标准
10.5.1 软件质量因素的定义质量因素 定 义正确性 系统满足规格说明和优化目标的程度，即在预定环境下能正确地完成预期功能的程度。
健壮性 在硬件故障、操作错误等意外情况下，系统能作出适当反应的程度。
效 率 为完成预定功能，系统需要的计算资源的多少。
完整性 即安全性，对非法使用软件或数据，系统能够控制（禁止）的程度。
可用性 对系统完成预定功能的满意程度。
风 险 能否按照预定成本和进度完成系统看法,并为用户满意的程度 。
可理解性 理解和使用该系统的容易程度。
可维护性 诊断和改正运行时所发现错误所需工作量的大小。
灵活性 即适应性，修改或改进正在运行的系统所需工作量的大小。
可测试性 软件易测试的程度。
可移植性 改变系统的软、硬件环境及配置时，所需工作量的大小。
可再用性 软件在其它系统中可被再次使用的程度（或范围）。
互运行性 把该系统与另一个系统结合起来所需工作量。
10.5.1 软件质量因素的定义可以从两个方面来理解软件质量保证工作 。 一方面,从顾客驱动观点看,
注重于复审和校核方法并保证一致性,其关键是需要一种客观的标准来确定并报告软件开发过程及其成果的质量,一般由,软件质量保证小组,完成 。
另一方面，从管理者驱动观点看，注重于确定为了产品质量必须做些什么，并且建立管理和控制机制来确保这些活动能够得到执行。关键步骤如下：
１,以客户对于质量的需求为基础,对项目开发周期的各个阶段,建立质量目标 。
２、定义质量度量（ metrics）以衡量项目活动的结果，协助评价有关的质量目标是否达到。
３、确定质量活动。对于每一个质量目标，确定那些能够帮助实现该质量目标的活动，并将这些活动集成到软件生命周期模型中去。
４、执行已经确定的质量活动。
５、评价质量。在项目开发周期的各阶段，利用已经定义好的质量度量来评价有关的质量目标是否达到。
６、若质量目标没有达到，采取修正行动。
10.5.２软件质量保证工作
10.5.２软件质量保证工作软件度量和保证的条件通常包括,
1,适应性； 2,易学性； 3,可靠性
4,针对性； 5,客观性； 6,经济性软件质量度量方法有以下三种,
1,精确度量：使用质量度量评价准则进行详细度量,工作量大,
但度量精确度也高；
2,全面度量：可以与简易度量并用对各个质量设计评价准则进行度量,工作量可以控制在一定的范围内 。
3,简易度量
10.5.３软件项目的跟踪与控制
10.5.３ 软件项目的跟踪与控制在软件项目实施过程中进行跟踪与控制,是软件项目管理的重要内容,
也是保证软件质量的重要措施 。
可用不同的方法进行追踪：
10.6 软件能力成熟度模型（ CMM）
软件能力成熟度模型 CMM（ Capability Maturity Model） 是由美国卡内基 -梅隆大学软件工程研究所 (CMU/SEI)推出的评估软件能力与成熟度的一套标准 。 并提供了 软件过程评估 和 软件能力评价 两种评估方法和软件成熟度提问单 。 4年之后,SEI将软件过程成熟度框架进化为 软件能力成熟度模型 （ Capability Maturity Model For Software,简称 SW-CMM） 。
该标准基于众多软件专家的实践经验,侧重于软件开发过程的管理及工程能力的提高与评估,是国际上流行的软件生产过程标准和软件企业成熟度等级认证标准,它更代表了一种管理哲学在软件工业中的应用 。
目前,CMM认证已经成为世界公认的软件产品进入国际市场的通行证 。 为推动我国软件产业的发展,促进软件企业向正规化和国际化迈进,
应进一步引入和推广 CMM认证 。
10.6 软件能力成熟度模型 （ CMM）
10.6.1 CMM的基本概念
1,软件过程一个软件过程是指人们开发和维护软件及其相关产品所采取的一系列活动 。 其中软件相关产品包括项目计划,设计文档,源代码,测试用例和用户手册等 。 软件产品的质量主要取决于产品开发和维护的软件过程的质量 。 一个有效的,可视的软件过程能够将人力资源,物理设备和实施方法结合成一个有机的整体,并为软件工程师和高级管理者提供实际项目的状态和性能,从而可以监督和控制软件过程的进行 。
2,软件过程能力与性能软件过程能力是软件过程本身具有的按预定计划生产产品的固有能力 。
一个组织的软件过程能力为组织提供了预测软件项目开发的数据基础 。 软件过程性能是软件过程执行的实际结果 。 一个项目的软件过程性能决定于内部子过程的执行状态,只有每个子过程的性能得到改善,相应的成本,
进度,功能和质量等性能目标才能得到控制 。 由于特定项目的属性和环境限制,项目的实际性能并不能充分反映组织的软件过程能力,但成熟的软件过程可弱化和预见不可控制的过程因素 （ 如客户需求变化或技术变革等 ） 。
10.6.1 CMM的基本概念
3,软件过程成熟度软件过程成熟度是指一个软件过程被明确定义,管理,度量和控制的有效程度 。 成熟意味着软件过程能力持续改善的过程,成熟度代表软件过程能力改善的潜力 。
成熟度等级用来描述某一成熟度等级上的组织特征,每一等级都为下一等级奠定基础,过程的潜力只有在一定的基础之上才能够被充分发挥 。
成熟级别的改善包括管理者和软件从业者基本工作方式的改变,组织成员依据建立的软件过程标准执行并监控软件过程,一旦来自组织和管理上的障碍被清除后,有关技术和过程的改善进程能迅速推进 。
10.6.1 CMM的基本概念
10.6.2 软件过程的成熟度等级
CMM将软件过程的成熟度分为 5个级别 （ Maturity Levels）,如图所示,5个等级分别是：
初始级可重复级已定义级已管理级优化级
10.6.2 软件过程的成熟度等级
1,初始级 （ Initial）
2、可重复（ Repeatable）
3,已定义级 （ Defined）
4,已管理级 （ Managed）
5,优化级 （ Optimizing）
SW-CMM为每个软件组织建立和改善软件过程提供了一个阶梯式的过程成熟度框架,这一框架由 5个成熟度等级构成 。 除初始级以外,其余的成熟度等级都包含了若干个关键过程区域,每个关键过程区域又包含了若干个关键实践,这些关键实践按照 5个共同特点加以组织 。
图 10.13 成熟度等级单击鼠标左键查看相应内容初始级可重复级已定义级已管理级优化级初始级（ Initial）
在初始级,企业一般不具备稳定的软件开发与维护环境 。 项目成功与否在很大程度上取决于是否有杰出的项目经理和经验丰富的开发团队 。 此时,
项目经常超出预算和不能按期完成,
组织的软件过程能力不可预测 。
初始级
10.6.2 软件过程的成熟度等级图 10.14 初始级初始级可重复级已定义级已管理级优化级可重复级 (Repeatable),
在可重复级,组织建立了管理软件项目的方针以及为贯彻执行这些方针的措施 。 组织基于在类似项目上的经验对新项目进行策划和管理 。 组织的软件过程能力可描述为有纪律的,并且项目过程处于项目管理系统的有效控制之下 。
可重复级
10.6.2 软件过程的成熟度等级图 10.14 可重复级初始级可重复级已定义级已管理级优化级已定义级（ Defined）：
在已定义级,组织形成了管理软件开发和维护活动的组织标准软件过程,
包括软件工程过程和软件管理过程 。
项目依据标准定义自己的软件过程进行管理和控制 。 组织的软件过程能力可描述为标准的和一致的,过程是稳定的和可重复的并且高度可视
10.6.2 软件过程的成熟度等级图 10.15 已定义级初始级可重复级已定义级已管理级优化级已管理级（ Managed）：
在已管理级,组织对软件产品和过程都设置定量的质量目标 。 项目通过把过程性能的变化限制在可接受的范围内,实现对产品和过程的控制 。 组织的软件过程能力可描述为可预测的,
软件产品具有可预测的高质量已管理级
10.6.2 软件过程的成熟度等级图 10.16 已管理级初始级可重复级已定义级已管理级优化级优化级（ Optimizing）：
在优化级,组织通过预防缺陷,技术创新和更改过程等多种方式,不断提高项目的过程性能以持续改善组织软件过程能力 。 组织的软件过程能力可描述为持续改善的 。
优化级
10.6.2 软件过程的成熟度等级图 10.17 优化级表 1描述了 SW-CMM不同成熟度等级过程的可视性和过程能力 。
等级 成熟度 可视性 过程能力
1 初始级 有限的可视性 一般达不到进度和成本的目标
2 可重复级 里程碑上具有管理可视性 由于基于过去的性能，项目开发计划比较现实可行
3 已定义级 项目定义软件过程的活动具有可视性基于已定义的软件过程，组织持续地改善过程能力
4 已管理级 定量地控制软件过程 基于对过程和产品的度量，组织持续地改善过程能力
5 优化级 不断地改善软件过程 组织持续地改善过程能力表 10.3 可视性与过程能力的比较
10.6.2 软件过程的成熟度等级表 10.4 SW-CMM的关键过程区域
10.6.3 关键过程区域过程分类成熟度等级管理过程 组织过程 工程过程
5、优化级 技术改革管理过程更改管理缺陷预防
4、已管理级 定量过程管理 软件质量管理
3、已定义级集成软件管理组间协调组织过程焦点组织过程定义培训大纲软件产品工程同行评审
2、可重复级需求管理软件项目策划软件项目跟踪与监督软件子合同管理软件质量保证软件配置管理
1、初始级 无序过程
10.6.3 关键过程区域除了初始级外,每一成熟度等级又由若干个关键过程区域 (Key Process
Areas)构成 。 关键过程区域指出为了达到某个成熟度等级所要着手解决的问题 。 达到一个成熟度等级,必须实现该等级上的全部关键过程区域 。 要实现一个关键过程区域,就必须达到该关键过程区域的所有目标 。
关键过程区域 KPY(Key Process
Areas)是一组相关的活动，可按照上表描述，也可按照图 10.18描述。
10.6.3 关键过程区域初始级需求管理软件项目计划软件项目跟踪与监督软件子合同管理软件质量保证软件配置管理可重复级软件机构过程关注点软件机构过程定义培训计划整体化软件管理软件产品工程组间合作同行评审已定义级定量过程管理软件质量管理已管理级过程变更管理预防故障技术变更管理优化级图 10.18 关键过程域
10.6.4 软件企业如何实施 CMM
软件是促进我国电子信息产业发展的关键技术 。 而要发展我国的软件产业,在战略上,必须将软件产业作为我国高新技术产业的龙头和国民经济发展的新增长点,在策略上,必须走软件过程管理专业化的道路 。
但目前国内的绝大部分软件企业处于 CMM的初级阶段，没有基础和经验。本节讨论软件企业实施 CMM或通过 CMM评估所必须经历的步骤。
提高思想认识进行 CMM培训和咨询工作 确定合理的目标 成立工作组制定和完善软件过程内部评审正式评估根据评估结果改进软件过程
10.6.4 软件企业如何实施 CMM
图 10.19 CMM步骤单击 处查看相关内容中国这样的一个大国,软件销售额还不到世界市场的 0.5%。 我国软件企业除少数几家在 500人以上外,多数是在 50人以下的民营,
集体和个人的软件公司 。 以开发技术和规范化程序来衡量,总体上仍是相当落后的,大多数企业仍为手工作坊式制作,产品缺乏市场竞争力 。 因此,软件过程管理已成为发展我们软件产业的一个关键性问题 。
实施 CMM对软件企业的发展起着至关重要的作用,CMM过程本身就是对软件企业发展历程的一个完整而准确的描述,企业通过实施 CMM,可以更好地规范软件生产和管理流程,使企业组织规范化 。 而且,只有在国际市场取得成功的产品和企业才具有长久的竞争力和生命力,
10.6.4 软件企业如何实施 CMM
１,提高思想认识根据 CMM模型的要求,一个项目的开发一定要有章可循,而且要做到有章必循,这两点都离不开培训 。 培训工作需要投入很大的人力,物力和财力,只有企业的管理人员和软件开发人员对 CMM真正了解和认识了,自觉地按 CMM的方法去进行工作,才能真正实施
CMM，
培训的内容需要精心地准备,主要有两个方面,第一,对所有员工包括经理在内的最基本的软件工程和 CMM培训知识；第二,对各个工作组的有关人员提供专业领域知识等方面的培训；此外,在每次开发过程中,还要对普通人员进行软件过程方面的培训 。
10.6.4 软件企业如何实施 CMM
２、进行 CMM培训和咨询工作
CMM模型划分为 5个级别,共计 18个关键过程域,52个目标,300
多个关键实践 。 每一个 CMM等级的评估周期 （ 从准备到完成 ） 约需 12-
30个月 。 无论一个软件企业的软件过程处于什么样的水平,都可以在
CMM框架的 5个级别中找到自己的位置 。
因此,要实施 CMM,首先应该对本企业的现状有一个准确的评估,
然后再结合企业的实际情况选择 CMM的切入点,确定总体目标 。 这个目标包括在多长时间之内,需要投入多少人力,物力和财力,要达到哪一级 。
由于软件过程的建立和改进是一个渐进的,分轻重缓急的,逐步完善的过程 。 所以,在总体目标已经确定的前提下,还要制订近期目标和长期目标 。
10.6.4 软件企业如何实施 CMM
３,确定合理的目标在 CMM的实施过程中,工作组的成立是一个关键步骤 。 有几个必不可少的重要的组织包括：软件工程过程组,软件工程组,系统工程组,
系统测试组,需求管理组,软件项目计划组,软件项目跟踪与监督,软件配置管理组,软件质量保证组,培训组 。 例如：
软件工程过程组 由专家组成,统领 CMM实施活动,协调全组织软件过程的开发和改进活动,制定,维护和跟踪与软件过程开发和改进活动有关的计划,定义用于过程的标准和模板,负责对全体人员培训有关软件过程及其相关的活动 。
软件工程组 负责一个项目的软件开发和维护活动 （ 即需求分析,设计,编码和测试 ）
系统工程组 负责规定系统需求；将系统需求分配给硬件,软件和其他成分；规定硬件,软件和其他成分的界面；以及监控这些成分的设计和开发以保证它们符合其规格说明 。
10.6.4 软件企业如何实施 CMM
４,成立工作组
CMM模型强调软件过程的改进,如果企业还没有一个文档形式的软件过程,则首要任务是对当前的工作流程进行分析,整理及文档化,从而制定出一个具有本企业风格的软件过程,并用该文档化的过程指导软件项目的开发 。
如果已经具备了软件过程,则要对这个过程做内部评估,对照
CMM的要求,找出问题,然后对这个过程进行补充修改 。 在具体实施的过程中,可以选择有一定代表性和完善性的项目组或项目进行试点,跟踪,监督改进后的软件过程的实施情况,执行改进活动的状态 。
10.6.4 软件企业如何实施 CMM
５、制定和完善软件过程
CMM每一级别的评估都由美国卡内基梅隆大学的软件工程研究所
（ CMU/SEI） 授权的主任评估师领导一个评审小组进行 。 目前,全世界一共只有三百多个主任评估师大部分在美国,而我国大陆还没有一个主任评估师 。 CMM评估中要聘请外籍主任评估师费用较高 。 据估计,要通过一个级别的 CMM评估,费用是通过 ISO9000认证的十多倍 。
因此,建议软件企业在进行正式评估之前,先进行内部评审或评估 。
这种内部评审包含两层含义 。 第一种就是软件企业组织自己内部成员,
严格,认真地按照 CMM规范评估过程,对自己的软件过程进行评审,
找出其中的不足点并进行改进 。
第二种含义就是在全国范围内,由有关软件工程和 CMM专家组成一个专门的 "内部评审 "机构,负责指导协调实施 CMM的活动,对国内软件企业 CMM评估进行 "预先评估 "。 这种预先评估,可降低软件企业通过正式 CMM评估的风险,减少软件企业实施 CMM的成本,为企业最终获得国际 CMM认证打下基础 。
10.6.4 软件企业如何实施 CMM
６,内部评审目前主要有两种基于 CMM的评估方法,一种是 CBA-SCE(CMM-
Based Appraisal for Software Capability Estimation),它是基于 CMM对组织的软件能力进行评估,是由组织外部的评估小组对该组织的软件能力进行的评估 。 另一种是 CBA-IPI(CMM-Based Appraisal for Internal
Process Improvement),它是基于 CMM对内部的过程改进进行的评估,
是由组织内部的小组对软件组织本身进行评估以改进质量,结果归组织所有,目的是引导组织不断改进质量 。
CBA评估过程主要分成两个阶段：准备阶段和评估阶段 。 在评估的最初几天,小组成员的主要任务是采集数据,回答 SEI的 CMM提问单,文档审阅以及进行交谈,对整个组织中的应用有一个全面的了解 。
然后进行数据分析 。 评估员要对记录进行整理,把这些数据与 CMM模型进行比较,最后给出一个评估报告 。 在评估报告的基础上,评估小组成员起草一个评估结果 。
10.6.4 软件企业如何实施 CMM
７,正式评估根据 IDEAL模型,成熟度的评估只是软件过程改进中的一个环节,
如果这个环节与软件过程改进的其他环节不能很好地结合,那么,
CMM评估对于软件过程改进所应具有的作用就得不到发挥 。
一般来说,应该在评估之后很快地作出软件过程改进的计划,因为这时大家对评估结果和存在的问题仍有一个深刻的认识 。 计划在软件过程改进中是一个非常必要的阶段,只有有效的计划,才能确保软件过程得到有效的改进 。
10.6.4 软件企业如何实施 CMM
８,根据评估结果改进软件过程因为软件过程成熟度的升级本身就是一个过程,而且全面引进应用 CMM所涉及的范围非常广,要求人力,财力与设备资源的投入相当大 。 所以在实施 CMM时,企业千万不要一开始就把目标定位过高,不必一下子去满足某一能力成熟度等级的所有目标 。 而要根据企业自身的情况,试行某些关键过程域的一部分关键实践活动,
逐步完善软件过程和成熟度的升级 。
软件企业在实施 CMM的过程中,应当处理好 CMM实施和认证的关系 。 实施是基础,认证是结果 。 只有认真扎实的实施,才可能有认证的通过 。 由于我国大部分软件企业距离 CMM的认证有相当大的距离,最好先按照 CMM严格的软件工程方法,致力于改进企业的管理,提高软件开发能力,而先不要搞软件能力评鉴,追求认证,
评级等 。 等到能力成熟后,再进行认证 。 这样可以避免和杜绝华而不实,弄虚作假的现象 。 应该把实施 CMM作为提高软件企业管理水平和提高软件质量的突破口,追求真正的软件能力和水平的提高,
而不是把单纯的 CMM软件认证作为一个唯一的目标 。
ＣＭＭ小结
