? 项目管理过程
? 软件生产率和质量的度量
? 软件项目的估算
? 软件项目计划的目标
? 软件成本和工作量估算
? 进度安排
? 软件项目的组织与计划
? 软件过程与软件过程成熟度模型
项目管理过程
? 软件项目管理的对象是 软件工程
项目 。它所涉及的范围 覆盖了整
个软件工程过程 。
? 为使软件项目开发获得成功,关
键问题 是必须对软件项目的 工作
范围, 可能风险, 需要资源 (人,
硬件 ／ 软件 ),要实现的任务, 经
历的里程碑, 花费工作量 (成本 )、
进度安排 等做到心中有数。
启动一个软件项目
? 在制定软件项目计划之前，必须
? 明确项目的目标和范围
? 考虑候选的解决方案
? 标明技术和管理上的要求
? 有了这些信息，才能确定 合理,
精确的成本估算, 实际可行的任
务分解 以及 可管理的进度安排 。
? 软件人员和用户是在 系统工程步
骤 中 确定项目的目标和范围 。
? 目标 标明了 软件项目的目的 但不
涉及如何去达到这些目的。
? 范围 标明了 软件要实现的基本功
能,并尽量以定量的方式界定这
些功能。
? 当明确了软件项目的目标和范围
后，就应考虑 候选的解决方案 。
? 有了方案，管理人员和技术人员
就能够据此选择 一种“好的”方
法,给出诸如 交付期限, 预算,
个人能力, 技术界面 及其它许多
因素所构成的限制。
度量
? 进行度量工作，是为了 了解产品
开发的技术过程 和 产品本身 。
? 度量 开发过程 的目的是为了
改进过程,
? 度量 产品 的目的是为了提高
产品的质量 。
? 度量的作用是为了 有效地定量地
进行管理 。
? 为有效地度量，常常需要考虑：对
于 过程 和 产品,
? 合适的度量是什么？
? 所收集的数据如何使用？
? 用于比较个人、过程或产品的
度量是否合理？
? 管理人员和技术人员可利用这些度
量来了解软件工程过程的实际情况
和它所生产的产品质量 。
估算
? 在 软件项目管理过程 中关键的活
动就是 制定项目计划 。
? 在做计划时必须就 需要的人力
（ 以人月为单位 ）,项目持续时
间 （ 以年份或月份为单位 ）,成
本 （ 以元为单位 ）做出估算。
? 这种估算大多是 利用以前的花费
做为参考 而做出的。
? 如果新项目与以前的一个项目在
大小 上和 功能 上十分 类似,则新
项目需要工作量、开发持续时间、
成本大致与那个老项目相同。
? 假使项目背景完全生疏，只凭过
去的经验做出估算可能就不够了。
? 现在已有了许多用于软件开发的
估算技术 。其共同特点是：
? 事先建立软件范围
? 以软件度量（以往的度量）为
基础，以做出估算
? 项目被分解为可单独进行估算
的小块
? 管理人员大多使用不止一种估算
技术，并用一种估算技术做为另
一种估算技术的交叉检查。
风险分析
? 每当新建一个程序时，总是存在
某些不确定性。
? 用户要求是否能确切地被理解？
? 在项目最后结束之前要求实现
的功能能否建立？
? 是否存在目前仍未发现的技术
难题？
? 在项目出现严重误期时是否
会发生一些变更？等等。
? 风险分析 对于软件项目管理 是决
定性的,然而现在还有许多项目
不考虑风险就着手进行。
? 所谓 风险分析 实际上就是一系列
风险管理步骤,其中包括 风险识
别, 风险估计, 风险优化, 风险
管理策略, 风险解决 和 风险监督 。
这些步骤贯穿在软件工程过程中。
进度安排
? 每一个软件项目都要求制定一个
进度安排,但不是所有的进度都
得一样安排。
? 对于进度安排，需要考虑的是：
? 预先对进度如何计划？
? 工作怎样就位？
? 如何识别定义好的任务？
? 管理人员对 结束时间如何掌握?
? 如何 识别 和 监控关键路径 以 确保
结束？
? 对进展如何度量？
? 如何建立 分隔任务的里程碑 。
? 软件项目的进度安排与任一个工程
项目的进度安排基本相同。首先 识
别一组项目任务,再 建立任务之间
的相互关联,然后 估算各个任务的
工作量, 分配人力 和 其它资源, 制
定进度时序 。
追踪和控制
? 一旦建立了 开发进度安排,就可以
开始着手 追踪和控制活动 。
? 由 项目管理人员负责追踪在进度安
排中 标明的每一个任务。
? 如果任务实际完成日期滞后于进度
安排，则管理人员可以使用一种自
动的项目进度安排工具来确定在项
目的中间里程碑上进度误期所造成
的影响。
? 还可 对资源重新定向
? 对 任务重新安排
? （ 做为最坏的结果 ） 可以修改交
付日期以调整已经暴露的问题 。
用这种方式可以较好地控制软件
的开发。
软件生产率和质量的度量
? 生产率与质量的度量是 以投入工作
量 为依据的 软件开发活动 的度量和
开发成果 质量的度量。
? 为什么要对软件进行度量
? 面向规模的度量
? 面向功能的度量
? 软件质量的度量
? 在软件工程过程中使用度量
为什么要对软件进行度量
① 表明 软件产品的质量 ；
② 弄清 软件开发人员的生产率 ；
③ 给出使 用了新的软件工程方法和
工具 所得到的（在生产率和质量两
方面）的 效益 ；
④ 建立 项目估算 的,基线,；
⑤ 帮助 调整对新的工具 和 附加培训
的要求 。
度量的方式
? 在物理世界中的度量有两种方式。
? 直接度量（例如，度量一个螺
栓的长度）；
? 间接度量（例如，用次品率来
度量生产出的螺栓质量）。
? 软件度量也同样分为两类,直接
度量 与 间接度量 。
? 软件工程过程的直接度量包括 所投
入的成本 和 工作量 。
? 软件产品的直接度量包括 产生的代
码行数 （ LOC）,执行速度, 存储
量大小, 在某种时间周期中所报告
的差错数 。
? 软件产品的间接度量包括 功能性,
复杂性, 效率, 可靠性, 可维护性
和 许多其它的质量特性 。
软件度量域的分类
面向规模的度量
? 面向规模的度量 是对 软件 和 软件开
发过程 的直接度量。
? 可以建立一个 面向规模 的 数据表格
来记录项目的某些信息。
? 该表格列出了 在过去几年完成的每
一个软件开发项目 和 关于这些项目
的相应面向规模的数据 。
面向规模的数据表格
? 根据数据表格可以对所有的项目计
算出平均值：
生产率 ＝ KLOC／ PM（人月）
质量 ＝ 错误数／ KLOC
成本 ＝ 元／ LOC
文档 ＝ 文档页数／ KLOC
面向功能的度量
? 面向功能的软件度量是对 软件 和 软
件开发过程 的 间接度量 。
? 面向功能度量主要考虑 程序的, 功
能性,和,实用性,,而不是对
LOC计数 。
? 该度量是一种叫做 功能点方法 的生
产率度量法，利用 软件信息域 中的
一些计数 和 软件复杂性估计 的 经验
关系式 而导出 功能点 FP。
面向功能的数据表格
功能点计算
? 确定 五个信息域 的特征，并在表格
中相应位臵给出计数。
(1) 用户输入数,各个用户输入是
面向不同应用的输入数据 。
(2) 用户输出数,各个用户输出是
面向应用的输出信息,包括 报告,
屏幕信息, 错误信息 等。 在 报告 中
的各个数据项不应再分别计数 。
(3) 用户查询数,查询是一种联机
的交互操作，每次询问 /响应具备应
计数。
(4) 文件数,每一个逻辑主文件都
应计数。逻辑主文件是指逻辑上的
一组数据，可以是一个大数据库的
一部分，可以是一个单独的文件。
(5) 外部接口数,与系统中其他设
备通过外部接口读写信息次数均应
计数。
? 一旦收集到上述数据，就可以计算
出 与每一个计数相关的复杂性值 。
? 一个信息域是 简单的, 平均的 还是
复杂的,由使用功能点方法的机构
自行确定，从而计算出加权计数。
? 计算功能点，使用如下的关系式,
FP ＝ 总计数 × ( 0.65＋
+ 0.01× SUM ( Fi ) )
? 总计数是所有加权计数项的和
? Fi（ i＝ 1..14）是 复杂性校正值,它
们应通过逐一回答如下提问来确定。
? Fi的取值 0..5：
0 没有影响 1 偶然的
2 适中的 3 普通的
4 重要的 5 极重要的
? SUM（ Fi）是求和函数。
复杂性校正值 Fi
1,系统是否需要 可靠的备份 和 恢复？
2,是否需要 数据通信？
3,是否有 分布处理的功能？
4,是否 性能成为关键？
5,系统是否 运行在既存的高度实用化
的操作环境中？
6,系统是否需要 联机数据项？
7,联机数据项是否需要 建立多重窗口
显示和操作, 以处理输入处理 。
8,主文件是否 联机更新？
9,输入, 输出, 文件, 查询 是否 复杂？
10,内部处理过程 是否 复杂？
11,程序代码 是否 可复用？
12,设计中是否包括了 转移 和 安装？
13,系统是否设计成可以 重复安装在
不同机构中
14,系统是否设计成 易修改 和 易使用？
? 一旦计算出 功能点,就可仿照 LOC
的方式 度量软件的生产率、质量和
其它属性：
生产率 ＝ FP／ PM（人月）
质量 ＝ 错误数／ FP
成本 ＝ 元／ FP
文档 ＝ 文档页数／ FP
? 功能点度量 是为了 商用信息系统应
用 而设计的。
? 特征点度量 （ Feature Points）可以
用于 系统 和 工程软件应用
? 特征点度量适合于 算法复杂性高 的
应用。而实时处理、过程控制、嵌
入式软件应用的算法复杂性都偏高，
因此适合于特征点度量。
? 为了计算特征点，可以象 功能点计
算 那样,对 信息域值 进行计数和加
权 。此外,特征点度量要对一个新
的软件特征,算法,进行计数 。
? 计算特征点可使用一个计算表格。
对于每一个度量参数只使用一个权
值，并且使用 FP＝总计数 × ( 0.65
＋ 0.01× SUM ( Fi ) )
来计算总的特征点值。
特征点度量计算表格
软件质量的度量
? 质量度量贯穿于软件工程的全过程
中 以及 软件交付用户使用之后 。
? 在 软件交付之前 得到的度量可作为
判断设计和测试质量好坏的依据。
这一类度量包括程序复杂性、有效
的模块性和总的程序规模。
? 在 软件交付之后 的度量则把注意力
集中于还未发现的差错数和系统的
可维护性方面。
? 使用得最广泛软件质量的事后度量
包括 正确性, 可维护性, 完整性 和
可使用性 。
(1) 正确性,一个程序必须 正确地运
行,并 为它的用户提供某些输出 。
正确性要求软件执行所要求的功能。
正确性的度量 是 每千代码行 (KLOC)
的差错数,其中 将差错定义为已被
证实是不符合需求的缺陷 。
(2) 可维护性,软件维护比其它的软
件工程活动需要更多的工作量。还
没有一种方法可以直接度量可维护
性，因此 必须采取间接度量 。
有一种简单的面向时间的度量，叫
做 平均变更等待时间 MTTC。
这个时间包括 分析变更要求, 设计
适当的修改, 实现变更并测试,及
把变更发送给所有的用户 。
一个可维护的程序与不可维护的程
序相比，应有较低的 MTTC。
(3) 完整性,完整性 度量一个系统
抗拒对它的安全性攻击 （事故的和
人为的） 的能力 。软件的所有三个
成分 程序, 数据 和 文档 都会遭到攻
击。
度量 完整性,需要定义两个附加的
属性,危险性 和 安全性 。
危险性 是 特定类型的攻击将在一给
定时间内发生的概率, 安全性 是 排
除特定类型攻击的概率 。
一个系统的完整性可定义为 完整性
＝ ∑( 1－危险性 × ( 1－安全性 ) )
其中，对每一个攻击的 危险性 和
安全性 都进行累加。
(4) 可使用性,如果一个程序不具
有,用户友好性,，即使它所执
行的功能很有价值，也常常会失
败。可使用性量化,用户友好
性,，并依据以下四个特征进行
度量：
? 为学习系统所需要的 体力上的 和 智
力上的 技能；
? 为达到适度有效使用系统所需要的
时间；
? 当软件被某些人适度有效地使用时
所度量的 在生产率方面的净增值 ；
? 用户角度对 系统的主观评价 （可以
通过问题调查表得到）。
在软件工程过程中使用度量
? 建立基线
? 为了将 LOC和 FP用于软件估算技
术中，必须建立 历史数据基线 。
? 根据历史经验,在软件工程过程
的衔接处划出一条基线,在此基
线上 附有一些用于度量的经验目
标信息,作为工程过程评估的依
据，判断工程过程的完成是否达
到预想的要求。
? 质量度量数据一旦收集到，软件开
发组织就可以 根据它们来调整其软
件工程项目, 以消除那些对软件开
发有重大影响的差错产生的根源 。
? 大多数软件开发人员都希望了解：
哪些用户需求 可能会 变更？系统中
哪些模块 容易 出错？对 每一个模块
要 做多少测试？在测试时能够 预计
多少错误？如果能收集到相关的度
量数据，就能确定这些问题的答案。
软件项目的估算
? 软件项目管理过程开始于项目计划。
? 在做项目计划时，第一项活动就是
估算 。
? 在做估算时往往存在某些不确定性，
使得软件项目管理人员无法正常进
行管理而导致产品迟迟不能完成。
? 现在已使用的实用技术是 时间 和 工
作量估算 。
估算对风险的影响
? 项目的复杂性 对于 增加软件计划的
不确定性影响很大 。复杂性越高，
估算的风险就越高。
? 项目的规模 对于软件估算的精确性
和功效影响也比较大 。随着软件规
模的扩大，问题分解会变得更加困
难。 项目的规模越大, 开发工作量
越大, 估算的风险越高 。
? 项目的结构化程度 也影响项目估算
的风险。随着结构化程度的提高，
进行精确估算的能力就能提高，而
风险将减少。
? 历史信息的有效性 也 影响估算的风
险 。对过去的项目进行综合的软件
度量，可借用来比较准确地进行估
算，安排进度以避免重走过去的弯
路，而总的风险也减少了。
? 如果 对软件项目的作用范围还不十
分清楚,或者 用户的要求经常变更,
都会导致对 软件项目所需资源, 成
本, 进度 的估算频频变动，增加估
算的风险。
? 计划人员应当要求 在软件系统的规
格说明中给出完备的功能, 性能,
接口的定义 。
软件项目计划的目标
? 软件项目管理人员在 开发工作一开
始 需要进行 定量估算 。
? 软件项目计划的目标 是 提供一个能
使项目管理人员对资源, 成本和进
度做出合理估算的框架 。
? 这些估算应当在软件项目开始时的
一个有限的时间段内做出，并且随
着项目的进展定期进行更新。
软件的范围
? 软件范围包括 功能, 性能, 限制,
接口 和 可靠性 。
? 估算开始时，应对软件的功能进行
评价，对其进行适当的细化以便提
供更详细的细节。由于 成本和进度
的估算都与功能有关,因此 常常采
用某种程度的功能分解 。
? 性能的考虑包括 处理 和 响应时间 的
需求。
? 约束条件则 标识产品成本, 外部硬
件, 可用存储 或 其它现有系统 对软
件的 限制 。
? 功能、性能和约束必须在一起进行
评价 。当性能限制不同时，为实现
同样的功能，开发工作量可能相差
一个数量级。
? 还要叙述某些 质量因素 （例如，给
出的算法是否容易理解等）。
? 软件与其它系统元素是相互作用的。
要考虑 每个接口的性质和复杂性,
以确定对开发资源、成本和进度的
影响。接口的概念可解释为：
? 运行软件的硬件 （如处理机与外
设） 及间接受软件控制的设备
（如机器、显示器） ;
?必须与新软件链接的现有的软件
（如数据库存取例程、子程序包、
操作系统） ;
? 通过终端或其它输入／输出设备
使用该软件的人 ;
? 该软件运行前后的 一系列操作过
程 。
? 对于每一种情况，都必须清楚地了
解通过接口的信息转换。
软件开发中的资源
? 软件项目计划的第二个任务是对完
成该软件项目所需的资源进行估算。
? 软件开发所需的 资源 有
? 现成的用以支持软件开发的工具
──硬件工具 及 软件工具
? 最基本的资源
──人
软件开发中的资源
? 通常，对每一种资源，应说明以下
四个特性：
（ 1）资源的描述 ;
（ 2）资源的有效性说明 ;
（ 3）资源在何时开始需要 ;
（ 4）使用资源的持续时间。
? 最后两个特性统称为 时间窗口 。
1,人力资源
? 在考虑各种软件开发资源时,人是
最重要的资源 。在安排开发活动时
必须考虑 人员的技术水平, 专业,
人数,以及 在开发过程各阶段中对
各种人员的需要 。
? 计划人员首先 估算范围 并 选择为完
成开发工作所需要的技能 。还要在
组织 和 专业 两方面做出安排。
? 对于一些 规模较小的项目 （ 1个人
年或者更少），只要向专家做些咨
询，也许 一个人就可以完成所有的
软件工程步骤 。
? 对一些 规模较大的项目,在整个软
件生存期中,各种人员的参与情况
是不一样的 。下面是各类不同的人
员随开发工作的进展在软件工程各
个阶段的参与情况的典型曲线。
2,硬件资源
? 硬件是作为软件开发项目的一种工
具而投入的。
（ 1）宿主机 （ Host） ─ 软件开发时
使用的计算机及外围设备 ；
（ 2）目标机 （ Target） ─ 运行已开
发成功软件的计算机及外围设备 ；
（ 3）其它硬件设备 ─ 专用软件开发
时需要的特殊硬件资源 ；
3,软件资源
? 软件工程人员在软件开发期间使用
了许多软件工具来帮助开发。这种
软件工具集叫做 计算机辅助软件工
程 （ CASE）。
（ 1） 业务系统计划工具集
（ 2） 项目管理工具集
（ 3） 支援工具 ──文档生成工具、
网络系统软件、数据库、电子邮件、
通报板，以及配臵管理工具。
（ 4） 分析和设计工具
（ 5） 编程工具
（ 6） 组装和测试工具
（ 7） 原型化和模拟工具
（ 8） 维护工具
（ 9） 框架工具 ──这些工具能够提
供建立集成项目支撑环境（ IPSE）
的框架。
4,软件复用性及软件部件库
? 为了促成软件的复用，以提高软件
的生产率和软件产品的质量，可建
立可复用的软件部件库。
软件成本和工作量的估算
? 软件 成本和工作量的估算 中变化的
东西太多，人、技术、环境、政治，
都会影响软件最终成本和工作量。
? 软件项目的估算能够 通过一系列系
统化的步骤, 在可接受的风险范围
内提供估算结果 。
? 成本估算必须,事前,给出。时间
越久，了解得越多，估算中出现的
严重误差就越少。
分解技术
? 当一个 待解决的问题过于复杂 时，
我们可以把它 进一步分解,直到 分
解后的子问题变得容易解决 为止。
然后,分别解决每一个子问题,并
将这些子问题的解答综合起来,从
而 得到原问题的解答 。
LOC和 FP估算
? 在软件项目估算中，在两个方面
使用了 LOC和 FP数据：
? 把 LOC和 FP数据当做一个估算
变量，用于 量度软件每一个元素
的规模 。
? LOC和 FP数据作为从过去项目
中收集到的 基线数据,与其它估
算变量联合使用,进行成本和工
作量的估算 。
? LOC和 FP的共性在于,
? 给出一个有界的软件范围的叙述
? 由此叙述 把软件分解成一些小的
可分别独立进行估算的子功能
? 对每一个子功能 估算 LOC或 FP
? 把基线生产率度量 (如 LOC／ PM
或 FP／ PM) 用做特定的估算变量，
导出子功能的成本或工作量
?综合子功能的估算 得到 整个项目
的总估算 。
? 项目计划人员可 对每一个分解的功
能提出一个有代表性的估算值范围 。
? 利用历史数据 或 凭实际经验 （当其
它的方法失效时）,对每个功能分
别按 最佳的, 可能的, 悲观的 三种
情况给出 LOC或 FP估计值 。记作 a、
m,b。
? 接着计算 LOC或 FP的 期望值 E。
E ＝ （ a＋ 4m＋ b）／ 6
? 所有子功能的总估算变量值 除以 相
应于该估算变量的平均生产率度量
得到 项目的总工作量 。
? 例如，若假定总的 FP估算值 是 310，
基于过去项目的平均 FP生产率 是
5.5FP／ PM，则 项目的总工作量 是：
工作量 ＝ 310／ 5.5 ＝ 56 PM
作为 LOC和 FP估算的实例，考察
一个为 CAD应用而开发的软件包。
? 系统定义评审指明,软件是在一个
工作站上运行，其接口必须使用各
种计算机图形设备，包括鼠标器、
数字化仪、高分辩率彩色显示器和
激光打印机。
? 在这个实例中，使用 LOC做为估算
变量。
? 根据系统规格说明,软件范围 的初
步叙述如下
“软件将从操作员那里接收 2维或 3维
几何数据 。 操作员通过 用户界面 与
CAD系统 交互并控制它,这种用户
界面将表现出很好的人机接口设计
特性。所有的几何数据和其它支持
信息保存在一个 CAD数据库 内。要
开发一些 设计分析模块 以产生在各
种图形设备上显示的输出。软件要
设计得 能控制并与能各种外部设备,
包括鼠标器、数字化仪、激光打印
机和绘图仪 交互 。”
经过分解,识别出下列主要软件功能：
? 用户界面和控制功能
? 二维几何分析
? 三维几何分析
? 数据库管理
? 计算机图形显示功能
? 外设控制 PC
? 设计分析模块
? 通过分解，可得到如下估算表
估算表
软件开发成本估算
? 软件开发成本主要是指 软件开发过
程中所花费的工作量及相应的代价 。
它不包括原材料和能源的消耗，主
要是人的劳动的消耗。
? 人的劳动消耗所需代价就是软件产
品的开发成本。
? 软件产品开发成本的计算方法不同
于其它物理产品成本的计算。
? 软件的开发成本是 以一次性开发过
程所花费的代价 来计算的。
? 软件开发成本的估算，应是从 软件
计划, 需求分析, 设计, 编码, 单
元测试, 组装测试 到 确认测试,整
个软件开发全过程所花费的代价作
为依据的。
软件开发成本估算方法
? 对于一个大型的软件项目，由于 项
目的复杂性,开发成本的估算不是
一件简单的事，要进行一系列的估
算处理。主要靠 分解 和 类推 。
? 基本估算方法分为三类。
? 自顶向下的估算方法
? 自底向上的估计法
? 差别估计法
自顶向下的估算方法
? 这种方法的主要思想是 从项目的整
体出发, 进行类推 。
? 估算人员根据 以前已完成项目所消
耗的总成本 （ 或总工作量 ）,推算
将要开发的软件的总成本 （ 或总工
作量 ），然后 按比例将它分配到各
开发任务单元中去,再来检验它是
否能满足要求。
软件 库存情况更新 开发者 W,W ard 日期 2 / 8 / 82
阶 段 项目任务 工作量分布 (1 /53) 小计 (1/ 53 )
计划和需求 软件需求定义 5
开发计划 1 6
产品设计 6
产品设计 初步的用户手册 3
测试计划 1 10
详细 PD L 描述 4
详细设计 数据定义 4
过程设计 2
正式的用户手册 2 12
编码与 程序编码 6
单元测试 单元测试结果 10 16
组装与 编写文档 4
联合测试 组装与测试 5 9
总 计 53
? 这种方法的优点是估算工作量小，
速度快。
? 缺点是对项目中的特殊困难估计不
足，估算出来的成本盲目性大，有
时会遗漏被开发软件的某些部分。
自底向上的估计法
? 这种方法的主要思想是把 待开发的
软件细分, 直到每一个子任务都已
经明确所需要的开发工作量,然后
把它们加起来, 得到软件开发的总
工作量 。
? 它的优点是估算各个部分的准确性
高。缺点是缺少各项子任务之间相
互联系所需要的工作量，还缺少许
多与软件开发有关的系统级工作量,
差别估计法
? 这种方法综合了上述两种方法的优
点，其主要思想是 把待开发的软件
项目与过去已完成的软件项目进行
类比, 从其开发的各个子任务中区
分出类似的部分和不同的部分 。
? 类似的部分按实际量进行计算, 不
同的部分则采用相应方法进行估算 。
专家判定技术
? 由多位专家进行成本估算
? 单独一位专家可能会有种种偏见，
最好由多位专家进行估算, 取得多
个估算值 。
? 有多种方法把这些估算值合成一个
估算值。
? 一种方法是 简单地求各估算值的中
值或平均值 。其优点是简便。缺点
是可能会由于受一、二个极端估算
值的影响而产生严重的偏差。
? 一种方法是 召开小组会, 使各位专
家们统一于或至少同意某一个估算
值 。优点是可以摈弃蒙昧无知的估
算值，缺点是一些组员可能会受权
威或政治因素的影响。
Deiphi技术
? 标准 Deiphi技术
?组织者发给每位专家一份 软件系
统规格说明书 和一张 记录估算值
的表格,请他们进行估算。
?专家详细研究软件规格说明书的
内容，对该软件提出 三个规模 的
估算值，即,ai (最小 ),mi (可能 ),
bi (最大 ),无记名地填写表格
?组织者对专家们填在表格中的答
复 进行整理,
a,计算各专家估算的期望值 Ei;
b,对专家的估算结果分类摘要 。
专家对此估算值另做一次估算 。
?在综合专家估算结果的基础上，
组织专家再次无记名地填写表格 。
比较两次估算的结果。若差异很
大，要通过查询找出差异的原因。
?上述过程可重复多次。 最终可获
得一个得到多数专家共识的软件规
模 （源代码行数）。
? 最后，通过与历史资料进行类比，
根据过去完成软件项目的规模和成
本等信息，推算出该软件每行源代
码所需要的成本。然后再乘以该软
件源代码行数的估算值，就可得到
该软件的成本估算值。
软件开发成本估算的经验模型
? 软件开发成本估算是 依据开发成
本估算模型进行估算 的。
? 开发成本估算模型通常 采用经验
公式 来 预测软件项目计划所需要
的成本, 工作量和进度数据 。
? 用以支持大多数模型的经验数据
都是 从有限的一些项目样本 中得
到的。
IBM模型
E ＝ 5.2× L0.91
D ＝ 4.1× L0.36 ＝ 14.47× E0.35
S ＝ 0.54× E0.6
DOC ＝ 49× L1.01
? L 是 源代码行数 (KLOC),E 是 工
作量 (PM),D 是 项目持续时间
(月 ),S 是 人员需要量 (人 ),DOC
是 文档数量 (页 )。
? IBM模型是 静态单变量模型 。
? 在此模型中，一般指 一条机器指令
为一行源代码 。
? 一个软件的源代码行数 不包括程序
注释, 作业命令, 调试程序在内 。
? 对于非机器指令编写的源程序，例
如汇编语言或高级语言程序，应 转
换成机器指令源代码行数 来考虑。
转换系数表
语语 言言 转转 换换 系系 数数
简简 单单 汇汇 编编 11
宏宏 汇汇 编编 11,,22 ～～ 11,,55
FF OO RR TT RR AA NN 44 ～～ 66
PP LL // II 44 ～～ 11 00
定义, 转换系数＝机器指令条数／非机
器语言执行步数。
Putnam模型
? Putnam模型是一种 动态多变量模
型 。适用于大型项目，但也可以应
用在一些较小的软件项目中。
? 它是 假定在软件开发的整个生存期
中工作量有特定的分布 。
? 大型软件项目的开发工作量分布可
以用 Rayleigh-Norden曲线 表示。
? 用 Rayleigh-Norden曲线可以导出
一个“软件方程”
? td 是 开发持续时间 (年 ),K是 软件
开发与维护在内的整个生存期所花
费的工作量 (人年 ),L是 源代码行
数 (LOC),Ck是 技术状态常数,
因开发环境而异 。
3
4
3
1
tdKCkL ???
技术状态常数 Ck的取值
C
k
的
典型值
开发
环境
开 发 环 境
举 例
2000 差 没有系统的开发方法，缺乏
文档和复审，批处理方式。
8000 好 有合适的系统开发方法，有
充分的文档和复审，交互执
行方式。
1 1000 优 有自动开发工具和技术。
COCOMO模型
（ COnstructive COst MOdel）
? 结构型成本估算模型是一种 精确,
易于使用 的成本估算方法。
? DSI（ 源指令条数 ）定义为 代码 的
源程序行数 。若一行有两个语句，
则算做一条指令。它 包括作业控制
语句 和 格式语句, 但不包括注释语
句。 KDSI＝ 1000DSI。
? MM（度量单位为 人月 ）表示 开发
工作量 。
? TDEV（度量单位为 月 ）表示 开发
进度 。它由工作量决定。
? 软件开发项目的分类
软件开发项目的 总体类型,
? 组织型
? 嵌入型
? 半独立型
? COCOMO模型的分类
COCOMO模型 按其详细程度 分成
三级：
? 基本 COCOMO模型
? 中间 COCOMO模型
? 详细 COCOMO模型
? 基本 COCOMO模型 是 静态单变量
模型,用 源代码行数 (LOC) 为 自变
量 的经验函数计算软件开发工作量。
? 中间 COCOMO模型 在用 LOC为 自
变量 的函数计算软件开发工作量
（称为名义工作量）的基础上,用
涉及产品, 硬件, 人员, 项目等方
面的影响因素调整工作量估算 。
? 详细 COCOMO模型 包括中间 CO
COMO模型的所有特性，但用上述
各种影响因素调整工作量估算时，
还要考虑对软件工程过程中每一步
骤（分析、设计等）的影响。
基本 COCOMO模型
? 基本 COCOMO模型的工作量和进
度公式
总体类型 工 作 量 进 度
组织型 MM ＝
= 2.4 （ KD SI ） 1.05
TD EV ＝
= 2.5 （ MM ） 0,38
半独立
型
MM ＝
= 3.0 （ KD SI ） 1.12
TD EV ＝
= 2.5 （ MM ） 0,35
嵌入型 MM ＝
= 3.6 （ KD SI ） 1.20
TD EV ＝
= 2.5 （ MM ） 0,32
中间 COCOMO模型
? 进一步考虑 15种影响软件工作量的
因素,通过 定下乘法因子, 修正
COCOMO工作量公式和进度公式,
可以更合理地估算软件（各阶段）
的工作量和进度。
? 中间 COCOMO模型的名义工作量
与进度公式如下所示。
总体类型 工 作 量 进 度
组织型 MM ＝
= 3.2 （ KD SI ） 1.05
TD EV ＝
= 2.5 （ MM ） 0.38
半独立
型
MM ＝
= 3.0 （ KD SI ） 1.12
TD EV ＝
= 2.5 （ MM ） 0.35
嵌入型 MM ＝
= 2.8 （ KD SI ） 1.20
TD EV ＝
= 2.5 （ MM ） 0.32
中间 COCOMO模型的名义工作量
与进度公式
15种影响软件工作量的因素 fi
? 产品因素,软件可靠性、数据库规
模、产品复杂性
? 硬件因素,执行时间限制、存储限
制、虚拟机易变性、环境周转时间
? 人的因素,分析员能力、应用领域
实际经验、程序员能力、虚拟机使
用经验、程序语言使用经验
? 项目因素,现代程序设计技术、软
件工具的使用、开发进度限制
? 此时，工作量计算公式改成
? 例 1,一个 32KDSI的声音输入系统是
一个输入原型，或是一个可行性表
演模型。所需可靠性非常低。把此
模型看做半独立型软件。则有
MM ＝ 3.0（ 32） 1.12 ＝ 146
又查表知 f1＝ 0.75，其它 fi＝ 1.00，
则最终有 MM ＝ 146× 0.75 ＝ 110.
?
?
???
15
1i
c fi( K D E V )rMM
? 例 14,一个规模为 10KDSI的商用微
机远程通信的 嵌入型软件, 使用中
间 COCOMO模型 进行成本估算。
? 程序名义工作量
MM ＝ 2.8 (10)1.20 ＝ 44.38（ MM）
? 程序实际工作量
MM ＝ 44.38×
＝ 44.38× 1.17 ＝ 51.5（ MM）
?
?
15
1i
fi
影响工作量因素 f
i 情 况 取 值
1 软件可靠性 只用于局部地区，恢
复问题不严重
1,0 0 （正常）
2 数据库规模 2 0 0 0 0 字节 0,9 4 （低）
3 产品复杂性 用于远程通信处理 1,3 0 （很高）
4 时间限制 使用 70% 的 CP U 时间 1,1 0 （高）
5 存储限制 6 4 K 中使用 4 5 K 1,0 6 （高）
6 机器 使用商用微处理机 1,0 0 （额定值）
7 周转时间 平均 2 小时 1,0 0 （额定 值）
8 分析员能力 优秀人才 0,8 6 （高）
9 工作经验 远程通信工作 3 年 1,1 0 （低）
10 程序员能力 优秀人才 0,8 6 （高）
1 1 工作经验 微型机工作 6 个月 1,0 0 （正常）
12 语言使用经验 1 2 个月 1,0 0 （正常）
13 使用现代程序设计技术 1 年以上 0,9 1 （高）
14 使用软件工具 基本的微型机软件 1,1 0 （低）
15 工期 9 个月 1,0 0 （正常）
? 开发所用时间
TDEV ＝ 2.5 (51.5)0.32 ＝ 8.9 （ 月 ）
? 如果分析员与程序员的工资都按每
月 6,000美元计算，则该项目的开
发人员的工资总额为
51.5× 6,000 ＝ 309,000 （ 美元 ）
? 做为对比，现在用 IBM模型 计算,
PM ＝ 5.2 (10)0.91 ＝ 42.27 （人月）
D ＝ 4.1 (10)0.38 ＝ 9.84 （月）
S ＝ 0.54 (42.27)0.60 ＝ 5.1 (人 )
详细 COCOMO模型
? 详细 COCOMO模型的名义工作量
公式和进度公式与中间 COCOMO
模型相同 。
? 工作量因素分级表分层、分阶段给
出。针对每一个影响因素，按 模块
层, 子系统层, 系统层,有三张工
作量因素分级表，供不同层次的估
算使用。 每一张表中工作量因素又
按开发各个不同阶段给出 。
? 例如，关于软件可靠性（ RELY）
要求的工作量因素分级表（子系统
层），如表所示。
? 使用这些表格，可以比 中间 COCO
MO模型 更方便、更准确地估算软
件开发工作量。
软件可靠性工作量因素分级表
(子系统层 )
进度安排
? 软件开发项目的进度安排有两种
方式：
（ 1）系统 最终交付日期已经确定,
软件开发部门必须在规定期限内
完成；
（ 2）系统 最终交付日期只确定了
大致的年限,最後交付日期由软
件开发部门确定。
? 进度安排落空，会导致市场机会的
丧失，使用户不满意，而且也会导
致成本的增加。
? 因此，在考虑进度安排时，要把工
作量与花费时间联系起来，合理分
配工作量,利用进度安排的有效分
析方法严密监控软件开发的进展情
况，使软件开发进度不致拖延。
软件开发小组人数与软件生产率
的关系
? 当几个人共同承担软件开发项目中
的某一任务时,人与人之间必须通
过交流来解决各自承担任务之间的
接口问题,即所谓 通信问题 。通信
需花费时间和代价，会引起软件错
误增加，降低软件生产率。
? 若两个人之间需要通信，则称在这
两个人之间存在一条通信路径。如
果一个软件开发小组有 n 个人，每
两人之间都需要通信，则总的通信
路径有 n(n-1)/2 (条 )。
? 设一个人单独开发软件，生产率是
5000行／人年 。若 4 个人 组成一个
小组共同开发这个软件，则需要 6
条通信路径 。若在每条通信路径上
耗费的工作量是 250 行／人年 。则
小组中每个人的软件生产率降低为
5000－ 6× 250／ 4 ＝
= 5000－ 375 ＝
= 4625 行／人年。
? 从上述分析可知,一个软件任务由
一个人单独开发，生产率最高 ；而
对于一个稍大型的软件项目，一个
人单独开发，时间太长。因此 软件
开发小组是必要的 。
? 但是，开发小组不宜太大，成员之
间避免太多的通信路径。
? 在开发进程中，切忌中途加人，避
免太多的生产率损失。
任务的确定与并行性
? 当参加同一软件工程项目的人数不
止一人的时候，开发工作就会出现
并行情形。
? 软件开发进程中设臵许多里程碑。
里程碑为管理人员提供了指示项目
进度的可靠依据。
? 软件工程项目的并行性提出了一系
列的进度要求。
? 因为并行任务是同时发生的，所以
进度计划表必须决定任务之间的从
属关系，确定各个任务的先后次序
和衔接，确定各个任务完成的持续
时间。
? 项目负责人应注意构成关键路径的
任务，即若要保证整个项目能按进
度要求完成，就必须保证这些任务
要按进度要求完成。
制定开发进度计划
? 40－ 20－ 40规则
?在整个软件开发过程中，编码工
作量仅占 20％，编码前工作量占
40％，编码后工作量占 40％。
? 40－ 20－ 40 规则只应用来做为
一个指南。实际的工作量分配比
例必须按照各项目的特点来决定。
? COCOMO模型
?开发进度 TDEV与工作量 MM的
关系：
TDEV ＝ a（ MM） b
?如果想要缩短开发时间，或想要
保证开发进度，必须考虑影响工
作量的那些因素。按可减小工作
量的因素取值。
? 按此比例确定各个阶段工作量的分
配，从而进一步确定每一阶段所需
的开发时间，然后在每个阶段，进
行任务分解，对各个任务再进行工
作量和开发时间的分配。
进度安排的方法
? 可以把用于一般开发项目的进度安
排的技术和工具应用于软件项目。
? 为监控 软件项目的进度计划和工作
的实际进展情况,为表现 各项任务
之间进度的相互依赖关系,需要采
用图示的方法。
? 在图示方法中，必须明确标明：
? 各个任务的 计划开始时间, 完成
时间 ；
? 各个任务 完成标志 （即○文档编
写和△评审）；
? 各个任务与参与工作的人数，各
个 任务与工作量之间的衔接情况 ；
? 完成各个任务所需的物理资源和
数据资源。
(1) 甘特图（ Gantt Chart）
? 在甘特图中，每一任务完成的标准，
不是以能否继续下一阶段任务为标
准，而是 以必须交付应交付的文档
与通过评审为标准 。因此在甘特图
中，文档编制与评审是软件开发进
度的里程碑。
(2) PERT技术和 CPM方法
? PERT技术叫做 计划评审技术,
CPM方法叫做 关键路径法,它们
都是安排开发进度，制定软件开发
计划的最常用的方法。
? 它们都采用网络图来描述一个项目
的任务网络，也就是从一个项目的
开始到结束，把应当完成的任务用
图或表的形式表示出来。
三个模块开发的网络图
? 通常用两张表来定义网络图。
? 一张表给出 与一特定软件项目有关
的所有任务 （也称为任务分解结构
WorkBreakdown Structure） ;
? 另一张表给出 应当按照什么样的次
序来完成这些任务 （有时称为限制
表 RestrictionList）。
PERT技术和 CPM方法都为项目计
划人员提供了一些定量的工具。
?确定关键路径,即决定项目开发
时间的任务链。在关键路径上的
各个任务都是时间余量为零的关
键任务，不能有任何时间延误。
?应用统计模型,对每一个单独的
任务确定最可能的开发持续时间
的估算值。
?计算边界时间,以便为具体的任
务定义时间窗口。
项目的追踪和控制
软件项目管理一项重要工作就是 在
项目实施过程中 进行 追踪 和 控制,
? 定期举行项目状态会议。由每位项
目成员报告其进展和遇到的问题。
? 评价在软件工程过程中所产生的所
有评审的结果。
? 确定由项目的计划进度所安排的可
能选择的正式的里程碑。
? 比较在项目资源表中所列出的每一
个项目任务的实际开始时间和计划
开始时间。
? 非正式地与开发人员交谈，以得到
他们对开发进展和刚冒头的问题的
客观评价。
? 当问题出现的时候,项目管理人
员必须 实行控制以尽快地排解 问题。
软件项目的组织与计划
? 制定计划
? 软件项目组织的建立
? 人员配备
制定计划
? 软件开发项目的计划涉及到实施项
目的各个环节，带有全局性质。
? 计划的 合理性 和 准确性 往往关系着
项目的成败。
? 计划应力求完备。要 考虑到一些未
知因素和不确定因素, 考虑到可能
的修改 。计划应力求准确。 尽可能
提高所依据数据的可靠程度 。
1,制定计划目标和进行风险分析
? 制定计划的目的就是要回答：这
个软件项目的范围是什么？需要
哪些资源？花费多少工作量？要
用的成本有多少？以及进度如何
安排等等一系列问题。
? 这步工作应当以系统计划为基础，
以系统规格说明为依据。
? 在开发工作尚未开始之前，准确回
答这些问题是十分困难的。需要通
过以往的开发经验做出估算,很难
达到准确 。
? 从估算出发，项目必然带有一定的
风险 。估算的准确性越差，风险也
就越大。研制的软件项目越复杂，
规模越大，结构化程度越低，资源、
成本、进度等因素的不确定性越大，
承担这一项目所冒的风险也越大。
? 组织软件项目必须事先认清可能构
成风险的因素，并研究战胜风险的
对策，只有这样才能避免出现灾难
性的后果，取得项目预期的成果。
2,软件计划的类型
? 针对不同工作目标，软件计划有：
?项目实施计划 （ 软件开发计划 ）
这是软件开发的综合性计划，通常
应包括任务、进度、人力、环境、
资源、组织等多个方面。
?质量保证计划 把软件开发的质
量要求具体规定为每个开发阶段可
以检查的质量保证活动。
?软件测试计划 规定测试活动的
任务、测试方法、进度、资源、人
员职责等。
?文档编制计划 规定所开发项目
应编制的文档种类、内容、进度、
人员职责等。
?用户培训计划 规定对用户进行
培训的目标、要求、进度、人员职
责等。
?综合支持计划 规定软件开发过
程中所需要的支持，以及如何获取
和利用这些支持。
?软件分发计划 软件开发项目完
成后，如何提供给用户。
3,项目实施计划中任务的划分
? 如何进行工作划分是实施计划首先
应解决的问题。常用的计划结构有：
?阶段项目计划
按软件生存期，把开发工作划分为
若干阶段，对每一阶段工作做出计
划。再把每一阶段工作分解为若干
任务，做出任务计划。还要把任务
细分为若干步骤，做出步骤计划。
?任务分解结构
按项目的实际情况进行自顶向下的
结构化分解，形成树形任务结构。
进一步把工作内容、所需工作量、
预计完成的期限也规定下来。
?任务责任矩阵
在任务分解的基础上，把工作分配
给相关的人员，用一个矩阵形表格
表示任务的分工和责任。
任务分解结构
任务责任矩阵
软件项目组织的建立
? 开发组织采用什么形式，要针对 软
件项目的特点 来决定，同时也 与参
与人员的素质有关 。
1、组织原则
(1) 尽早落实责任,在软件项目工
作开始时，要尽早 指定专人负责 。
使他 有权进行管理,并 对任务的完
成负全责 。
（ 2）减少接口,一个组织的 生产
率随完成任务中存在的通信路径数
目增加而降低 。要有合理的人员分
工、好的组织结构、有效的通信，
减少不必要的生产率的损失。
（ 3）责权均衡,软件经理人员所
负的责任不应比委任给他的权力还
大。
2,组织结构的模式
（ 1）按课题划分的模式
把软件开发人员按课题组成小组，
小组成员自始至终参加所承担课题
的各项任务。他们应负责完成软件
产品的定义、设计、实现、测试、
复查、文档编制、甚至包括维护在
内的全过程。
（ 2）按职能划分的模式
把参加开发项目的软件人员按任务
的工作阶段划分成若干个专业小组。
要开发的软件产品在每个专业小组
完成阶段加工（即工序）以后，沿
工序流水线向下传递。例如，分别
建立计划组、需求分析组、设计组、
实现组、系统测试组、质量保证组、
维护组等。各种文档资料按工序在
各组之间传递。
（ 3）矩阵形模式
这种模式实际上是以上两种模式
的复合。一方面，按工作性质，
成立一些专门组，如开发组、业
务组、测试组等；另一方面，每
一个项目又有它的经理人员负责
管理。每个软件人员属于某一个
专门组，又参加某一项目的工作。
3.程序设计小组的组织形式
? 小组内部人员的组织形式对生产率
也有影响。现有的组织形式有三种。
（ 1）主程序员制小组
小组的核心由一位 主程序员 (高级
工程师 )、二至五位 技术员,一位
后援工程师 组成。主程序员负责小
组全部技术活动的计划、协调与审
查，设计和实现项目中的关键部分。
技术员负责项目的具体分析与开
发，文档资料的编写工作。后援
工程师支持主程序员的工作，为
主程序员提供咨询，也做部分分
析、设计和实现的工作。并在必
要时能代替主程序员工作。
主程序员制小组还可以由一些 专
家 (如通信专家或数据库设计专
家 ),辅助人员 (如打字员和秘书 )、
软件资料员 协助工作。
（ 2）民主制小组
在民主制小组中，遇到问题，组内
成员之间可以平等地交换意见。 工
作目标的制定及做出决定都由全体
成员参加。 虽然也有一位成员当组
长，但工作的讨论、成果的检验都
公开进行。 这种组织形式强调发挥
小组每个成员的积极性。 有人认为
这种组织形式适合于研制时间长、
开发难度大的项目。
（ 3）层次式小组
在层次式小组中，组内人员分为
三级,组长（项目负责人） 一人
负责全组工作，包括任务分配、
技术评审和走查、掌握工作量和
参加技术活动。 他直接领导二至
三名 高级程序员,每位高级程序
员通过基层小组，管理若干位 程
序员 。
? 这种组织结构 只允许必要的人际通
信 。比较 适用于项目本身就是层次
结构的课题 。因为这样可以把项目
按功能划分成若干个子项目，把子
项目分配给基层小组，由基层小组
完成。
? 这种组织方式比较适合于大型软件
项目的开发。
人员配备
? 如何合理地配备人员，也是成功
地完成软件项目的切实保证。所
谓合理地配备人员应包括：
? 按不同阶段适时任用人员
? 恰当掌握用人标准 。
1,项目开发各阶段所需人员
? 一个软件项目完成的快慢，取决于
参与开发人员的多少。
? 在开发的整个过程中，多数软件项
目是以恒定人力配备的。
? 实际人力需求与开发进度的关系如
下图中的曲线所示 。
? 按此曲线，需要的人力随开发进展
逐渐增加，在编码与单元测试阶段
达到高峰，以后又逐渐减少。
? 如果恒定地配备人力，在开发初期
将会有部分人力资源用不上而浪费
掉。在开发中期，需要人力不够，
造成进度的延误。在开发后期就需
要增加人力以赶进度。
? 恒定地配备人力将浪费人力资源。
2,配备人员的原则
? 重质量 软件项目是技术性很强的
工作，要任用少量有实践经验、有
能力的人员去完成关键性的任务。
? 重培训 培养所需技术人员和管理
人员是有效解决人员问题的好方法。
? 双阶梯提升 人员提升应分别按技
术职务和管理职务进行，不能混在
一起。
3,对项目经理人员的要求
? 软件经理人员是工作的组织者,他
的管理能力的强弱是项目成败的关
键 。他应具有以下能力：
? 把用户提出的非技术性要求加以
整理提炼,以技术说明书的形式转
告给分析员和测试员。
? 能说服用户放弃一些不切实际的
要求,以保证合理的要求得以满足。
?能够把表面上似乎无关的要求集
中在一起,归结为, 需要什么,,
“要解决什么问题,。这是一种综
合问题的能力。
?要懂得心理学,能说服上级领导和
用户，让他们理解什么是不合理的
要求。但又要使他们毫不勉强,乐
于接受，并受到启发。
4,评价人员的条件
? 软件项目中人的因素越来越受重视。
在评价和任用软件人员时，必须掌
握一定的标准。 人员素质的优劣常
常影响到项目的成败 。
?牢固掌握计算机软件的基本知识
和技能。
?善于分析和综合问题，具有严密
的逻辑思维能力。
?工作踏实、细致,不靠碰运气，遵
循标准和规范，具有严格的科学作
风。
?工作中表现出有耐心、有毅力、有
责任心。
?善于听取别人的意见，善于与周围
人员团结协作，建立良好的人际关
系。
?具有良好的书面和口头表达能力。
软件过程与过程成熟度模型
? 软件过程是软件生存期中的一系
列相关过程。
? 过程是活动的集合；
? 活动是任务的集合；
? 任务是将输入变换为输出的操作；
? 活动的执行可以是顺序的，重复
的，并行的、嵌套的；
? 为了得到满足要求的软件产品，不
但需要有好的开发方法，还需要有
好的工程支持和工程管理。
?基本过程
? 获取过程
? 供应过程
? 开发过程
? 运行过程
? 维护过程
?获取过程
? 是 需方 为了 获得 一个 软件产品 所进
行的一系列活动：该过程从为获取
该软件产品的需求定义开始，经过
招标准备，合同的准备和修改，对
供方的监督，直到验收完成。
? 供应过程
? 是 供方 为向需方 提供软件产品 所进
行的一系列活动：该过程从理解软
件的需求开始，经过投标准备，签
订合同，制定计划，实施计划及控
制，进行评审和评价，直至完成交
付。
? 开发过程
? 是 软件开发者 根据合同 开发 和 交付
软件 的一系列活动。包括的活动有：
? 过程的实施准备
? 系统需求分析
? 系统结构设计
? 软件需求分析
? 软件体系结构设计
? 软件详细设计
? 程序编码和单元测试
? 软件集成
? 软件确认测试
? 系统集成
? 系统确认测试
? 软件安装
? 软件验收支持
? 运行过程
? 软件开发完成后，软件从开发环境
转移到用户的实际运行环境。在运
行时对用户的要求提供帮助和咨询，
对运行效果进行评价。
? 实施过程的准备
? 运行测试
? 系统向实际运行环境转移
? 系统运行
? 对用户运行的支持
? 系统运行评价
? 用户运行评价
? 维护过程
? 过程的实施准备
? 问题分析和修改分析
? 修改的实施
? 对维护进行评审／验收
? 移植
? 软件退役
?支持过程
? 文档过程
? 配臵管理过程
? 质量保证过程
? 验证过程
? 确认过程
? 联合评审过程
? 审计过程
? 问题解决过程
?文档过程
? 文档过程是一个记录由某一过程或
活动所产生的信息的过程。它由以
下活动组成,
? 过程的实施准备
? 设计与开发
? 制作与发行
? 维护
? 配臵管理过程
? 过程的实施准备
? 配臵的确定
? 配臵的控制
? 配臵情况报告
?配臵的评价
?发行管理和提交
?质量保证过程
? 这是一个为使软件过程和软件产品
符合规定需求，并按预定计划按时
完成提供适当保证的过程。
? 过程的实施准备
? 软件产品的质量保证
? 软件过程的质量保证
?验证过程
? 确定系统或软件的需求是否完备和
正确,以及每一阶段的软件产品是
否达到前一阶段对它的要求和条件。
? 过程的实施准备 ? 验证
? 合同验证 ? 过程验证
? 需求验证 ? 设计验证
? 代码验证 ? 集成验证
? 文档验证
?确认过程
? 确认需求和最终建立的系统或软
件是否满足原计划的特定应用。
? 过程的实施准备
? 确认
?联合评审过程
? 这是评价项目的某个活动或阶段的
执行情况,以及产品是否合乎要求
的过程。
? 过程的实施准备
? 项目管理评审
? 技术评审
?审计过程
? 这一过程是要审计确定合作的另一
方遵照需求、计划合同到什么程度
的过程。
? 过程的实施准备
? 审计
?问题解决过程
? 这是一个用于分析和排除在开发、
运行、维护或其它过程中发现的
问题和不一致的过程。
? 过程实施准备
? 问题解决
?组织过程
? 管理过程
? 基础设施过程
? 改进过程
? 培训过程
?管理过程
? 管理包括进度管理、成本管理、质
量管理、人员管理、资源管理、标
准化管理。
? 管理的对象是进度、系统规模及工
作量估算、经费、组织机构很人员、
风险、质量、作业和环境配臵等。
? 过程的实施准备
? 管理计划的制定
? 计划的实施与控制
? 评审和评价计划的完成程度
? 编写管理文档。
?基础设施过程
? 该过程建立、维护各个过程所需
的基础设施。
? 基础设施包括硬件、软件、工具、
技术、标准,以及开发、运行、维
护所需的设施。
?改进过程
? 该过程建立、评估、度量、控制和
改进软件生存期的过程。主要活动
是制定一组组织计划,评估相关过
程,实施分析、改进过程。
?培训过程
? 该过程为系统或软件产品提供人
员培训。主要活动有制定所需人
员用人计划和培训计划,开发培训
资料,实施培训活动等。
?软件过程的度量
软件过程成熟度
? 是指对过程计划或定义水平、过
程实施水平、过程管理和控制水
平、过程改善潜力等指标的综合
评价。
? 分为 5 级, 初始级, 可重复级, 可
定义级, 可管理级, 可优化级 。
评估软件过程时遵循的原则
? 在很大程度上，软件产品的质量取
决于生产该产品的过程质量。
? 软件过程是一个可管理、可测量和
可改进的过程。
? 软件过程的质量受其支持技术的影
响。
? 用于软件工程的技术水平应与过程
的成熟度相适应。
1 初始级
? 特点 过程执行杂乱无序
? 关键问题 项目计划管理、配臵管
理、软件质量保证
? 达标标准 过程活动无一定秩序，
开发过程的可重复性差
2 可重复级
? 特点 过程管理工作依赖管理人员
的技能
? 关键问题 培训、技术评审、标准
? 达标标准 使项目管理处于严格控
制之下，包括严格的项目计划和追
踪、子合同管理、需求变更和产品
基线控制
3 可定义级
? 特点 过程可定义、可执行
? 关键问题 过程度量、过程分析、
质量计划
? 达标标准 定义一个适合该组织的
软件过程，有正规的文档化的规范，
并能根据不同项目的要求裁剪和优
化这个软件过程
4 可管理级
? 特点 过程成为可度量的
? 关键问题 改善技术, 问题分析,
防止出错
? 达标标准 为定义好的过程建立一
套详细的度量机制, 为产品和过程
设立质量目标, 度量软件过程和产
品
5 可优化级
? 特点 通过反馈来改善过程
? 关键问题 自动化、反馈技术
? 达标标准 用第 4 级建立的度量机
制，不断地指导过程改善，技术革
新和防止出错
关键过程领域 KPA
（ Key Process Area）
? 除去初始级以外，其它 4 级都有若
干个引导软件机构改进软件过程的
要点，称为关键过程领域。
? 每一个关键过程领域是一组相关的
活动，成功地完成这些活动，将会
对提高过程能力起重要作用。
11 初初 始始 级级
22 可可 重重 复复 级级 需需 求求 管管 理理
软软 件件 项项 目目 计计 划划
软软 件件 项项 目目 跟跟 踪踪 与与 监监 督督
软软 件件 分分 包包 合合 同同 管管 理理
软软 件件 质质 量量 管管 理理
软软 件件 配配 臵臵 管管 理理关键过程域
33 可可 定定 义义 级级 软软 件件 机机 构构 过过 程程 关关 注注 点点
软软 件件 机机 构构 过过 程程 定定 义义
培培 训训 计计 划划
整整 体体 化化 软软 件件 管管 理理
软软 件件 产产 品品 工工 程程
组组 间间 合合 作作
同同 行行 评评 审审
44 可可 管管 理理 级级 定定 量量 过过 程程 管管 理理
软软 件件 质质 量量 管管 理理
55 可可 优优 化化 级级 过过 程程 变变 更更 管管 理理
预预 防防 故故 障障
技技 术术 变变 更更 管管 理理
? 软件生产率和质量的度量
? 软件项目的估算
? 软件项目计划的目标
? 软件成本和工作量估算
? 进度安排
? 软件项目的组织与计划
? 软件过程与软件过程成熟度模型
项目管理过程
? 软件项目管理的对象是 软件工程
项目 。它所涉及的范围 覆盖了整
个软件工程过程 。
? 为使软件项目开发获得成功,关
键问题 是必须对软件项目的 工作
范围, 可能风险, 需要资源 (人,
硬件 ／ 软件 ),要实现的任务, 经
历的里程碑, 花费工作量 (成本 )、
进度安排 等做到心中有数。
启动一个软件项目
? 在制定软件项目计划之前，必须
? 明确项目的目标和范围
? 考虑候选的解决方案
? 标明技术和管理上的要求
? 有了这些信息，才能确定 合理,
精确的成本估算, 实际可行的任
务分解 以及 可管理的进度安排 。
? 软件人员和用户是在 系统工程步
骤 中 确定项目的目标和范围 。
? 目标 标明了 软件项目的目的 但不
涉及如何去达到这些目的。
? 范围 标明了 软件要实现的基本功
能,并尽量以定量的方式界定这
些功能。
? 当明确了软件项目的目标和范围
后，就应考虑 候选的解决方案 。
? 有了方案，管理人员和技术人员
就能够据此选择 一种“好的”方
法,给出诸如 交付期限, 预算,
个人能力, 技术界面 及其它许多
因素所构成的限制。
度量
? 进行度量工作，是为了 了解产品
开发的技术过程 和 产品本身 。
? 度量 开发过程 的目的是为了
改进过程,
? 度量 产品 的目的是为了提高
产品的质量 。
? 度量的作用是为了 有效地定量地
进行管理 。
? 为有效地度量，常常需要考虑：对
于 过程 和 产品,
? 合适的度量是什么？
? 所收集的数据如何使用？
? 用于比较个人、过程或产品的
度量是否合理？
? 管理人员和技术人员可利用这些度
量来了解软件工程过程的实际情况
和它所生产的产品质量 。
估算
? 在 软件项目管理过程 中关键的活
动就是 制定项目计划 。
? 在做计划时必须就 需要的人力
（ 以人月为单位 ）,项目持续时
间 （ 以年份或月份为单位 ）,成
本 （ 以元为单位 ）做出估算。
? 这种估算大多是 利用以前的花费
做为参考 而做出的。
? 如果新项目与以前的一个项目在
大小 上和 功能 上十分 类似,则新
项目需要工作量、开发持续时间、
成本大致与那个老项目相同。
? 假使项目背景完全生疏，只凭过
去的经验做出估算可能就不够了。
? 现在已有了许多用于软件开发的
估算技术 。其共同特点是：
? 事先建立软件范围
? 以软件度量（以往的度量）为
基础，以做出估算
? 项目被分解为可单独进行估算
的小块
? 管理人员大多使用不止一种估算
技术，并用一种估算技术做为另
一种估算技术的交叉检查。
风险分析
? 每当新建一个程序时，总是存在
某些不确定性。
? 用户要求是否能确切地被理解？
? 在项目最后结束之前要求实现
的功能能否建立？
? 是否存在目前仍未发现的技术
难题？
? 在项目出现严重误期时是否
会发生一些变更？等等。
? 风险分析 对于软件项目管理 是决
定性的,然而现在还有许多项目
不考虑风险就着手进行。
? 所谓 风险分析 实际上就是一系列
风险管理步骤,其中包括 风险识
别, 风险估计, 风险优化, 风险
管理策略, 风险解决 和 风险监督 。
这些步骤贯穿在软件工程过程中。
进度安排
? 每一个软件项目都要求制定一个
进度安排,但不是所有的进度都
得一样安排。
? 对于进度安排，需要考虑的是：
? 预先对进度如何计划？
? 工作怎样就位？
? 如何识别定义好的任务？
? 管理人员对 结束时间如何掌握?
? 如何 识别 和 监控关键路径 以 确保
结束？
? 对进展如何度量？
? 如何建立 分隔任务的里程碑 。
? 软件项目的进度安排与任一个工程
项目的进度安排基本相同。首先 识
别一组项目任务,再 建立任务之间
的相互关联,然后 估算各个任务的
工作量, 分配人力 和 其它资源, 制
定进度时序 。
追踪和控制
? 一旦建立了 开发进度安排,就可以
开始着手 追踪和控制活动 。
? 由 项目管理人员负责追踪在进度安
排中 标明的每一个任务。
? 如果任务实际完成日期滞后于进度
安排，则管理人员可以使用一种自
动的项目进度安排工具来确定在项
目的中间里程碑上进度误期所造成
的影响。
? 还可 对资源重新定向
? 对 任务重新安排
? （ 做为最坏的结果 ） 可以修改交
付日期以调整已经暴露的问题 。
用这种方式可以较好地控制软件
的开发。
软件生产率和质量的度量
? 生产率与质量的度量是 以投入工作
量 为依据的 软件开发活动 的度量和
开发成果 质量的度量。
? 为什么要对软件进行度量
? 面向规模的度量
? 面向功能的度量
? 软件质量的度量
? 在软件工程过程中使用度量
为什么要对软件进行度量
① 表明 软件产品的质量 ；
② 弄清 软件开发人员的生产率 ；
③ 给出使 用了新的软件工程方法和
工具 所得到的（在生产率和质量两
方面）的 效益 ；
④ 建立 项目估算 的,基线,；
⑤ 帮助 调整对新的工具 和 附加培训
的要求 。
度量的方式
? 在物理世界中的度量有两种方式。
? 直接度量（例如，度量一个螺
栓的长度）；
? 间接度量（例如，用次品率来
度量生产出的螺栓质量）。
? 软件度量也同样分为两类,直接
度量 与 间接度量 。
? 软件工程过程的直接度量包括 所投
入的成本 和 工作量 。
? 软件产品的直接度量包括 产生的代
码行数 （ LOC）,执行速度, 存储
量大小, 在某种时间周期中所报告
的差错数 。
? 软件产品的间接度量包括 功能性,
复杂性, 效率, 可靠性, 可维护性
和 许多其它的质量特性 。
软件度量域的分类
面向规模的度量
? 面向规模的度量 是对 软件 和 软件开
发过程 的直接度量。
? 可以建立一个 面向规模 的 数据表格
来记录项目的某些信息。
? 该表格列出了 在过去几年完成的每
一个软件开发项目 和 关于这些项目
的相应面向规模的数据 。
面向规模的数据表格
? 根据数据表格可以对所有的项目计
算出平均值：
生产率 ＝ KLOC／ PM（人月）
质量 ＝ 错误数／ KLOC
成本 ＝ 元／ LOC
文档 ＝ 文档页数／ KLOC
面向功能的度量
? 面向功能的软件度量是对 软件 和 软
件开发过程 的 间接度量 。
? 面向功能度量主要考虑 程序的, 功
能性,和,实用性,,而不是对
LOC计数 。
? 该度量是一种叫做 功能点方法 的生
产率度量法，利用 软件信息域 中的
一些计数 和 软件复杂性估计 的 经验
关系式 而导出 功能点 FP。
面向功能的数据表格
功能点计算
? 确定 五个信息域 的特征，并在表格
中相应位臵给出计数。
(1) 用户输入数,各个用户输入是
面向不同应用的输入数据 。
(2) 用户输出数,各个用户输出是
面向应用的输出信息,包括 报告,
屏幕信息, 错误信息 等。 在 报告 中
的各个数据项不应再分别计数 。
(3) 用户查询数,查询是一种联机
的交互操作，每次询问 /响应具备应
计数。
(4) 文件数,每一个逻辑主文件都
应计数。逻辑主文件是指逻辑上的
一组数据，可以是一个大数据库的
一部分，可以是一个单独的文件。
(5) 外部接口数,与系统中其他设
备通过外部接口读写信息次数均应
计数。
? 一旦收集到上述数据，就可以计算
出 与每一个计数相关的复杂性值 。
? 一个信息域是 简单的, 平均的 还是
复杂的,由使用功能点方法的机构
自行确定，从而计算出加权计数。
? 计算功能点，使用如下的关系式,
FP ＝ 总计数 × ( 0.65＋
+ 0.01× SUM ( Fi ) )
? 总计数是所有加权计数项的和
? Fi（ i＝ 1..14）是 复杂性校正值,它
们应通过逐一回答如下提问来确定。
? Fi的取值 0..5：
0 没有影响 1 偶然的
2 适中的 3 普通的
4 重要的 5 极重要的
? SUM（ Fi）是求和函数。
复杂性校正值 Fi
1,系统是否需要 可靠的备份 和 恢复？
2,是否需要 数据通信？
3,是否有 分布处理的功能？
4,是否 性能成为关键？
5,系统是否 运行在既存的高度实用化
的操作环境中？
6,系统是否需要 联机数据项？
7,联机数据项是否需要 建立多重窗口
显示和操作, 以处理输入处理 。
8,主文件是否 联机更新？
9,输入, 输出, 文件, 查询 是否 复杂？
10,内部处理过程 是否 复杂？
11,程序代码 是否 可复用？
12,设计中是否包括了 转移 和 安装？
13,系统是否设计成可以 重复安装在
不同机构中
14,系统是否设计成 易修改 和 易使用？
? 一旦计算出 功能点,就可仿照 LOC
的方式 度量软件的生产率、质量和
其它属性：
生产率 ＝ FP／ PM（人月）
质量 ＝ 错误数／ FP
成本 ＝ 元／ FP
文档 ＝ 文档页数／ FP
? 功能点度量 是为了 商用信息系统应
用 而设计的。
? 特征点度量 （ Feature Points）可以
用于 系统 和 工程软件应用
? 特征点度量适合于 算法复杂性高 的
应用。而实时处理、过程控制、嵌
入式软件应用的算法复杂性都偏高，
因此适合于特征点度量。
? 为了计算特征点，可以象 功能点计
算 那样,对 信息域值 进行计数和加
权 。此外,特征点度量要对一个新
的软件特征,算法,进行计数 。
? 计算特征点可使用一个计算表格。
对于每一个度量参数只使用一个权
值，并且使用 FP＝总计数 × ( 0.65
＋ 0.01× SUM ( Fi ) )
来计算总的特征点值。
特征点度量计算表格
软件质量的度量
? 质量度量贯穿于软件工程的全过程
中 以及 软件交付用户使用之后 。
? 在 软件交付之前 得到的度量可作为
判断设计和测试质量好坏的依据。
这一类度量包括程序复杂性、有效
的模块性和总的程序规模。
? 在 软件交付之后 的度量则把注意力
集中于还未发现的差错数和系统的
可维护性方面。
? 使用得最广泛软件质量的事后度量
包括 正确性, 可维护性, 完整性 和
可使用性 。
(1) 正确性,一个程序必须 正确地运
行,并 为它的用户提供某些输出 。
正确性要求软件执行所要求的功能。
正确性的度量 是 每千代码行 (KLOC)
的差错数,其中 将差错定义为已被
证实是不符合需求的缺陷 。
(2) 可维护性,软件维护比其它的软
件工程活动需要更多的工作量。还
没有一种方法可以直接度量可维护
性，因此 必须采取间接度量 。
有一种简单的面向时间的度量，叫
做 平均变更等待时间 MTTC。
这个时间包括 分析变更要求, 设计
适当的修改, 实现变更并测试,及
把变更发送给所有的用户 。
一个可维护的程序与不可维护的程
序相比，应有较低的 MTTC。
(3) 完整性,完整性 度量一个系统
抗拒对它的安全性攻击 （事故的和
人为的） 的能力 。软件的所有三个
成分 程序, 数据 和 文档 都会遭到攻
击。
度量 完整性,需要定义两个附加的
属性,危险性 和 安全性 。
危险性 是 特定类型的攻击将在一给
定时间内发生的概率, 安全性 是 排
除特定类型攻击的概率 。
一个系统的完整性可定义为 完整性
＝ ∑( 1－危险性 × ( 1－安全性 ) )
其中，对每一个攻击的 危险性 和
安全性 都进行累加。
(4) 可使用性,如果一个程序不具
有,用户友好性,，即使它所执
行的功能很有价值，也常常会失
败。可使用性量化,用户友好
性,，并依据以下四个特征进行
度量：
? 为学习系统所需要的 体力上的 和 智
力上的 技能；
? 为达到适度有效使用系统所需要的
时间；
? 当软件被某些人适度有效地使用时
所度量的 在生产率方面的净增值 ；
? 用户角度对 系统的主观评价 （可以
通过问题调查表得到）。
在软件工程过程中使用度量
? 建立基线
? 为了将 LOC和 FP用于软件估算技
术中，必须建立 历史数据基线 。
? 根据历史经验,在软件工程过程
的衔接处划出一条基线,在此基
线上 附有一些用于度量的经验目
标信息,作为工程过程评估的依
据，判断工程过程的完成是否达
到预想的要求。
? 质量度量数据一旦收集到，软件开
发组织就可以 根据它们来调整其软
件工程项目, 以消除那些对软件开
发有重大影响的差错产生的根源 。
? 大多数软件开发人员都希望了解：
哪些用户需求 可能会 变更？系统中
哪些模块 容易 出错？对 每一个模块
要 做多少测试？在测试时能够 预计
多少错误？如果能收集到相关的度
量数据，就能确定这些问题的答案。
软件项目的估算
? 软件项目管理过程开始于项目计划。
? 在做项目计划时，第一项活动就是
估算 。
? 在做估算时往往存在某些不确定性，
使得软件项目管理人员无法正常进
行管理而导致产品迟迟不能完成。
? 现在已使用的实用技术是 时间 和 工
作量估算 。
估算对风险的影响
? 项目的复杂性 对于 增加软件计划的
不确定性影响很大 。复杂性越高，
估算的风险就越高。
? 项目的规模 对于软件估算的精确性
和功效影响也比较大 。随着软件规
模的扩大，问题分解会变得更加困
难。 项目的规模越大, 开发工作量
越大, 估算的风险越高 。
? 项目的结构化程度 也影响项目估算
的风险。随着结构化程度的提高，
进行精确估算的能力就能提高，而
风险将减少。
? 历史信息的有效性 也 影响估算的风
险 。对过去的项目进行综合的软件
度量，可借用来比较准确地进行估
算，安排进度以避免重走过去的弯
路，而总的风险也减少了。
? 如果 对软件项目的作用范围还不十
分清楚,或者 用户的要求经常变更,
都会导致对 软件项目所需资源, 成
本, 进度 的估算频频变动，增加估
算的风险。
? 计划人员应当要求 在软件系统的规
格说明中给出完备的功能, 性能,
接口的定义 。
软件项目计划的目标
? 软件项目管理人员在 开发工作一开
始 需要进行 定量估算 。
? 软件项目计划的目标 是 提供一个能
使项目管理人员对资源, 成本和进
度做出合理估算的框架 。
? 这些估算应当在软件项目开始时的
一个有限的时间段内做出，并且随
着项目的进展定期进行更新。
软件的范围
? 软件范围包括 功能, 性能, 限制,
接口 和 可靠性 。
? 估算开始时，应对软件的功能进行
评价，对其进行适当的细化以便提
供更详细的细节。由于 成本和进度
的估算都与功能有关,因此 常常采
用某种程度的功能分解 。
? 性能的考虑包括 处理 和 响应时间 的
需求。
? 约束条件则 标识产品成本, 外部硬
件, 可用存储 或 其它现有系统 对软
件的 限制 。
? 功能、性能和约束必须在一起进行
评价 。当性能限制不同时，为实现
同样的功能，开发工作量可能相差
一个数量级。
? 还要叙述某些 质量因素 （例如，给
出的算法是否容易理解等）。
? 软件与其它系统元素是相互作用的。
要考虑 每个接口的性质和复杂性,
以确定对开发资源、成本和进度的
影响。接口的概念可解释为：
? 运行软件的硬件 （如处理机与外
设） 及间接受软件控制的设备
（如机器、显示器） ;
?必须与新软件链接的现有的软件
（如数据库存取例程、子程序包、
操作系统） ;
? 通过终端或其它输入／输出设备
使用该软件的人 ;
? 该软件运行前后的 一系列操作过
程 。
? 对于每一种情况，都必须清楚地了
解通过接口的信息转换。
软件开发中的资源
? 软件项目计划的第二个任务是对完
成该软件项目所需的资源进行估算。
? 软件开发所需的 资源 有
? 现成的用以支持软件开发的工具
──硬件工具 及 软件工具
? 最基本的资源
──人
软件开发中的资源
? 通常，对每一种资源，应说明以下
四个特性：
（ 1）资源的描述 ;
（ 2）资源的有效性说明 ;
（ 3）资源在何时开始需要 ;
（ 4）使用资源的持续时间。
? 最后两个特性统称为 时间窗口 。
1,人力资源
? 在考虑各种软件开发资源时,人是
最重要的资源 。在安排开发活动时
必须考虑 人员的技术水平, 专业,
人数,以及 在开发过程各阶段中对
各种人员的需要 。
? 计划人员首先 估算范围 并 选择为完
成开发工作所需要的技能 。还要在
组织 和 专业 两方面做出安排。
? 对于一些 规模较小的项目 （ 1个人
年或者更少），只要向专家做些咨
询，也许 一个人就可以完成所有的
软件工程步骤 。
? 对一些 规模较大的项目,在整个软
件生存期中,各种人员的参与情况
是不一样的 。下面是各类不同的人
员随开发工作的进展在软件工程各
个阶段的参与情况的典型曲线。
2,硬件资源
? 硬件是作为软件开发项目的一种工
具而投入的。
（ 1）宿主机 （ Host） ─ 软件开发时
使用的计算机及外围设备 ；
（ 2）目标机 （ Target） ─ 运行已开
发成功软件的计算机及外围设备 ；
（ 3）其它硬件设备 ─ 专用软件开发
时需要的特殊硬件资源 ；
3,软件资源
? 软件工程人员在软件开发期间使用
了许多软件工具来帮助开发。这种
软件工具集叫做 计算机辅助软件工
程 （ CASE）。
（ 1） 业务系统计划工具集
（ 2） 项目管理工具集
（ 3） 支援工具 ──文档生成工具、
网络系统软件、数据库、电子邮件、
通报板，以及配臵管理工具。
（ 4） 分析和设计工具
（ 5） 编程工具
（ 6） 组装和测试工具
（ 7） 原型化和模拟工具
（ 8） 维护工具
（ 9） 框架工具 ──这些工具能够提
供建立集成项目支撑环境（ IPSE）
的框架。
4,软件复用性及软件部件库
? 为了促成软件的复用，以提高软件
的生产率和软件产品的质量，可建
立可复用的软件部件库。
软件成本和工作量的估算
? 软件 成本和工作量的估算 中变化的
东西太多，人、技术、环境、政治，
都会影响软件最终成本和工作量。
? 软件项目的估算能够 通过一系列系
统化的步骤, 在可接受的风险范围
内提供估算结果 。
? 成本估算必须,事前,给出。时间
越久，了解得越多，估算中出现的
严重误差就越少。
分解技术
? 当一个 待解决的问题过于复杂 时，
我们可以把它 进一步分解,直到 分
解后的子问题变得容易解决 为止。
然后,分别解决每一个子问题,并
将这些子问题的解答综合起来,从
而 得到原问题的解答 。
LOC和 FP估算
? 在软件项目估算中，在两个方面
使用了 LOC和 FP数据：
? 把 LOC和 FP数据当做一个估算
变量，用于 量度软件每一个元素
的规模 。
? LOC和 FP数据作为从过去项目
中收集到的 基线数据,与其它估
算变量联合使用,进行成本和工
作量的估算 。
? LOC和 FP的共性在于,
? 给出一个有界的软件范围的叙述
? 由此叙述 把软件分解成一些小的
可分别独立进行估算的子功能
? 对每一个子功能 估算 LOC或 FP
? 把基线生产率度量 (如 LOC／ PM
或 FP／ PM) 用做特定的估算变量，
导出子功能的成本或工作量
?综合子功能的估算 得到 整个项目
的总估算 。
? 项目计划人员可 对每一个分解的功
能提出一个有代表性的估算值范围 。
? 利用历史数据 或 凭实际经验 （当其
它的方法失效时）,对每个功能分
别按 最佳的, 可能的, 悲观的 三种
情况给出 LOC或 FP估计值 。记作 a、
m,b。
? 接着计算 LOC或 FP的 期望值 E。
E ＝ （ a＋ 4m＋ b）／ 6
? 所有子功能的总估算变量值 除以 相
应于该估算变量的平均生产率度量
得到 项目的总工作量 。
? 例如，若假定总的 FP估算值 是 310，
基于过去项目的平均 FP生产率 是
5.5FP／ PM，则 项目的总工作量 是：
工作量 ＝ 310／ 5.5 ＝ 56 PM
作为 LOC和 FP估算的实例，考察
一个为 CAD应用而开发的软件包。
? 系统定义评审指明,软件是在一个
工作站上运行，其接口必须使用各
种计算机图形设备，包括鼠标器、
数字化仪、高分辩率彩色显示器和
激光打印机。
? 在这个实例中，使用 LOC做为估算
变量。
? 根据系统规格说明,软件范围 的初
步叙述如下
“软件将从操作员那里接收 2维或 3维
几何数据 。 操作员通过 用户界面 与
CAD系统 交互并控制它,这种用户
界面将表现出很好的人机接口设计
特性。所有的几何数据和其它支持
信息保存在一个 CAD数据库 内。要
开发一些 设计分析模块 以产生在各
种图形设备上显示的输出。软件要
设计得 能控制并与能各种外部设备,
包括鼠标器、数字化仪、激光打印
机和绘图仪 交互 。”
经过分解,识别出下列主要软件功能：
? 用户界面和控制功能
? 二维几何分析
? 三维几何分析
? 数据库管理
? 计算机图形显示功能
? 外设控制 PC
? 设计分析模块
? 通过分解，可得到如下估算表
估算表
软件开发成本估算
? 软件开发成本主要是指 软件开发过
程中所花费的工作量及相应的代价 。
它不包括原材料和能源的消耗，主
要是人的劳动的消耗。
? 人的劳动消耗所需代价就是软件产
品的开发成本。
? 软件产品开发成本的计算方法不同
于其它物理产品成本的计算。
? 软件的开发成本是 以一次性开发过
程所花费的代价 来计算的。
? 软件开发成本的估算，应是从 软件
计划, 需求分析, 设计, 编码, 单
元测试, 组装测试 到 确认测试,整
个软件开发全过程所花费的代价作
为依据的。
软件开发成本估算方法
? 对于一个大型的软件项目，由于 项
目的复杂性,开发成本的估算不是
一件简单的事，要进行一系列的估
算处理。主要靠 分解 和 类推 。
? 基本估算方法分为三类。
? 自顶向下的估算方法
? 自底向上的估计法
? 差别估计法
自顶向下的估算方法
? 这种方法的主要思想是 从项目的整
体出发, 进行类推 。
? 估算人员根据 以前已完成项目所消
耗的总成本 （ 或总工作量 ）,推算
将要开发的软件的总成本 （ 或总工
作量 ），然后 按比例将它分配到各
开发任务单元中去,再来检验它是
否能满足要求。
软件 库存情况更新 开发者 W,W ard 日期 2 / 8 / 82
阶 段 项目任务 工作量分布 (1 /53) 小计 (1/ 53 )
计划和需求 软件需求定义 5
开发计划 1 6
产品设计 6
产品设计 初步的用户手册 3
测试计划 1 10
详细 PD L 描述 4
详细设计 数据定义 4
过程设计 2
正式的用户手册 2 12
编码与 程序编码 6
单元测试 单元测试结果 10 16
组装与 编写文档 4
联合测试 组装与测试 5 9
总 计 53
? 这种方法的优点是估算工作量小，
速度快。
? 缺点是对项目中的特殊困难估计不
足，估算出来的成本盲目性大，有
时会遗漏被开发软件的某些部分。
自底向上的估计法
? 这种方法的主要思想是把 待开发的
软件细分, 直到每一个子任务都已
经明确所需要的开发工作量,然后
把它们加起来, 得到软件开发的总
工作量 。
? 它的优点是估算各个部分的准确性
高。缺点是缺少各项子任务之间相
互联系所需要的工作量，还缺少许
多与软件开发有关的系统级工作量,
差别估计法
? 这种方法综合了上述两种方法的优
点，其主要思想是 把待开发的软件
项目与过去已完成的软件项目进行
类比, 从其开发的各个子任务中区
分出类似的部分和不同的部分 。
? 类似的部分按实际量进行计算, 不
同的部分则采用相应方法进行估算 。
专家判定技术
? 由多位专家进行成本估算
? 单独一位专家可能会有种种偏见，
最好由多位专家进行估算, 取得多
个估算值 。
? 有多种方法把这些估算值合成一个
估算值。
? 一种方法是 简单地求各估算值的中
值或平均值 。其优点是简便。缺点
是可能会由于受一、二个极端估算
值的影响而产生严重的偏差。
? 一种方法是 召开小组会, 使各位专
家们统一于或至少同意某一个估算
值 。优点是可以摈弃蒙昧无知的估
算值，缺点是一些组员可能会受权
威或政治因素的影响。
Deiphi技术
? 标准 Deiphi技术
?组织者发给每位专家一份 软件系
统规格说明书 和一张 记录估算值
的表格,请他们进行估算。
?专家详细研究软件规格说明书的
内容，对该软件提出 三个规模 的
估算值，即,ai (最小 ),mi (可能 ),
bi (最大 ),无记名地填写表格
?组织者对专家们填在表格中的答
复 进行整理,
a,计算各专家估算的期望值 Ei;
b,对专家的估算结果分类摘要 。
专家对此估算值另做一次估算 。
?在综合专家估算结果的基础上，
组织专家再次无记名地填写表格 。
比较两次估算的结果。若差异很
大，要通过查询找出差异的原因。
?上述过程可重复多次。 最终可获
得一个得到多数专家共识的软件规
模 （源代码行数）。
? 最后，通过与历史资料进行类比，
根据过去完成软件项目的规模和成
本等信息，推算出该软件每行源代
码所需要的成本。然后再乘以该软
件源代码行数的估算值，就可得到
该软件的成本估算值。
软件开发成本估算的经验模型
? 软件开发成本估算是 依据开发成
本估算模型进行估算 的。
? 开发成本估算模型通常 采用经验
公式 来 预测软件项目计划所需要
的成本, 工作量和进度数据 。
? 用以支持大多数模型的经验数据
都是 从有限的一些项目样本 中得
到的。
IBM模型
E ＝ 5.2× L0.91
D ＝ 4.1× L0.36 ＝ 14.47× E0.35
S ＝ 0.54× E0.6
DOC ＝ 49× L1.01
? L 是 源代码行数 (KLOC),E 是 工
作量 (PM),D 是 项目持续时间
(月 ),S 是 人员需要量 (人 ),DOC
是 文档数量 (页 )。
? IBM模型是 静态单变量模型 。
? 在此模型中，一般指 一条机器指令
为一行源代码 。
? 一个软件的源代码行数 不包括程序
注释, 作业命令, 调试程序在内 。
? 对于非机器指令编写的源程序，例
如汇编语言或高级语言程序，应 转
换成机器指令源代码行数 来考虑。
转换系数表
语语 言言 转转 换换 系系 数数
简简 单单 汇汇 编编 11
宏宏 汇汇 编编 11,,22 ～～ 11,,55
FF OO RR TT RR AA NN 44 ～～ 66
PP LL // II 44 ～～ 11 00
定义, 转换系数＝机器指令条数／非机
器语言执行步数。
Putnam模型
? Putnam模型是一种 动态多变量模
型 。适用于大型项目，但也可以应
用在一些较小的软件项目中。
? 它是 假定在软件开发的整个生存期
中工作量有特定的分布 。
? 大型软件项目的开发工作量分布可
以用 Rayleigh-Norden曲线 表示。
? 用 Rayleigh-Norden曲线可以导出
一个“软件方程”
? td 是 开发持续时间 (年 ),K是 软件
开发与维护在内的整个生存期所花
费的工作量 (人年 ),L是 源代码行
数 (LOC),Ck是 技术状态常数,
因开发环境而异 。
3
4
3
1
tdKCkL ???
技术状态常数 Ck的取值
C
k
的
典型值
开发
环境
开 发 环 境
举 例
2000 差 没有系统的开发方法，缺乏
文档和复审，批处理方式。
8000 好 有合适的系统开发方法，有
充分的文档和复审，交互执
行方式。
1 1000 优 有自动开发工具和技术。
COCOMO模型
（ COnstructive COst MOdel）
? 结构型成本估算模型是一种 精确,
易于使用 的成本估算方法。
? DSI（ 源指令条数 ）定义为 代码 的
源程序行数 。若一行有两个语句，
则算做一条指令。它 包括作业控制
语句 和 格式语句, 但不包括注释语
句。 KDSI＝ 1000DSI。
? MM（度量单位为 人月 ）表示 开发
工作量 。
? TDEV（度量单位为 月 ）表示 开发
进度 。它由工作量决定。
? 软件开发项目的分类
软件开发项目的 总体类型,
? 组织型
? 嵌入型
? 半独立型
? COCOMO模型的分类
COCOMO模型 按其详细程度 分成
三级：
? 基本 COCOMO模型
? 中间 COCOMO模型
? 详细 COCOMO模型
? 基本 COCOMO模型 是 静态单变量
模型,用 源代码行数 (LOC) 为 自变
量 的经验函数计算软件开发工作量。
? 中间 COCOMO模型 在用 LOC为 自
变量 的函数计算软件开发工作量
（称为名义工作量）的基础上,用
涉及产品, 硬件, 人员, 项目等方
面的影响因素调整工作量估算 。
? 详细 COCOMO模型 包括中间 CO
COMO模型的所有特性，但用上述
各种影响因素调整工作量估算时，
还要考虑对软件工程过程中每一步
骤（分析、设计等）的影响。
基本 COCOMO模型
? 基本 COCOMO模型的工作量和进
度公式
总体类型 工 作 量 进 度
组织型 MM ＝
= 2.4 （ KD SI ） 1.05
TD EV ＝
= 2.5 （ MM ） 0,38
半独立
型
MM ＝
= 3.0 （ KD SI ） 1.12
TD EV ＝
= 2.5 （ MM ） 0,35
嵌入型 MM ＝
= 3.6 （ KD SI ） 1.20
TD EV ＝
= 2.5 （ MM ） 0,32
中间 COCOMO模型
? 进一步考虑 15种影响软件工作量的
因素,通过 定下乘法因子, 修正
COCOMO工作量公式和进度公式,
可以更合理地估算软件（各阶段）
的工作量和进度。
? 中间 COCOMO模型的名义工作量
与进度公式如下所示。
总体类型 工 作 量 进 度
组织型 MM ＝
= 3.2 （ KD SI ） 1.05
TD EV ＝
= 2.5 （ MM ） 0.38
半独立
型
MM ＝
= 3.0 （ KD SI ） 1.12
TD EV ＝
= 2.5 （ MM ） 0.35
嵌入型 MM ＝
= 2.8 （ KD SI ） 1.20
TD EV ＝
= 2.5 （ MM ） 0.32
中间 COCOMO模型的名义工作量
与进度公式
15种影响软件工作量的因素 fi
? 产品因素,软件可靠性、数据库规
模、产品复杂性
? 硬件因素,执行时间限制、存储限
制、虚拟机易变性、环境周转时间
? 人的因素,分析员能力、应用领域
实际经验、程序员能力、虚拟机使
用经验、程序语言使用经验
? 项目因素,现代程序设计技术、软
件工具的使用、开发进度限制
? 此时，工作量计算公式改成
? 例 1,一个 32KDSI的声音输入系统是
一个输入原型，或是一个可行性表
演模型。所需可靠性非常低。把此
模型看做半独立型软件。则有
MM ＝ 3.0（ 32） 1.12 ＝ 146
又查表知 f1＝ 0.75，其它 fi＝ 1.00，
则最终有 MM ＝ 146× 0.75 ＝ 110.
?
?
???
15
1i
c fi( K D E V )rMM
? 例 14,一个规模为 10KDSI的商用微
机远程通信的 嵌入型软件, 使用中
间 COCOMO模型 进行成本估算。
? 程序名义工作量
MM ＝ 2.8 (10)1.20 ＝ 44.38（ MM）
? 程序实际工作量
MM ＝ 44.38×
＝ 44.38× 1.17 ＝ 51.5（ MM）
?
?
15
1i
fi
影响工作量因素 f
i 情 况 取 值
1 软件可靠性 只用于局部地区，恢
复问题不严重
1,0 0 （正常）
2 数据库规模 2 0 0 0 0 字节 0,9 4 （低）
3 产品复杂性 用于远程通信处理 1,3 0 （很高）
4 时间限制 使用 70% 的 CP U 时间 1,1 0 （高）
5 存储限制 6 4 K 中使用 4 5 K 1,0 6 （高）
6 机器 使用商用微处理机 1,0 0 （额定值）
7 周转时间 平均 2 小时 1,0 0 （额定 值）
8 分析员能力 优秀人才 0,8 6 （高）
9 工作经验 远程通信工作 3 年 1,1 0 （低）
10 程序员能力 优秀人才 0,8 6 （高）
1 1 工作经验 微型机工作 6 个月 1,0 0 （正常）
12 语言使用经验 1 2 个月 1,0 0 （正常）
13 使用现代程序设计技术 1 年以上 0,9 1 （高）
14 使用软件工具 基本的微型机软件 1,1 0 （低）
15 工期 9 个月 1,0 0 （正常）
? 开发所用时间
TDEV ＝ 2.5 (51.5)0.32 ＝ 8.9 （ 月 ）
? 如果分析员与程序员的工资都按每
月 6,000美元计算，则该项目的开
发人员的工资总额为
51.5× 6,000 ＝ 309,000 （ 美元 ）
? 做为对比，现在用 IBM模型 计算,
PM ＝ 5.2 (10)0.91 ＝ 42.27 （人月）
D ＝ 4.1 (10)0.38 ＝ 9.84 （月）
S ＝ 0.54 (42.27)0.60 ＝ 5.1 (人 )
详细 COCOMO模型
? 详细 COCOMO模型的名义工作量
公式和进度公式与中间 COCOMO
模型相同 。
? 工作量因素分级表分层、分阶段给
出。针对每一个影响因素，按 模块
层, 子系统层, 系统层,有三张工
作量因素分级表，供不同层次的估
算使用。 每一张表中工作量因素又
按开发各个不同阶段给出 。
? 例如，关于软件可靠性（ RELY）
要求的工作量因素分级表（子系统
层），如表所示。
? 使用这些表格，可以比 中间 COCO
MO模型 更方便、更准确地估算软
件开发工作量。
软件可靠性工作量因素分级表
(子系统层 )
进度安排
? 软件开发项目的进度安排有两种
方式：
（ 1）系统 最终交付日期已经确定,
软件开发部门必须在规定期限内
完成；
（ 2）系统 最终交付日期只确定了
大致的年限,最後交付日期由软
件开发部门确定。
? 进度安排落空，会导致市场机会的
丧失，使用户不满意，而且也会导
致成本的增加。
? 因此，在考虑进度安排时，要把工
作量与花费时间联系起来，合理分
配工作量,利用进度安排的有效分
析方法严密监控软件开发的进展情
况，使软件开发进度不致拖延。
软件开发小组人数与软件生产率
的关系
? 当几个人共同承担软件开发项目中
的某一任务时,人与人之间必须通
过交流来解决各自承担任务之间的
接口问题,即所谓 通信问题 。通信
需花费时间和代价，会引起软件错
误增加，降低软件生产率。
? 若两个人之间需要通信，则称在这
两个人之间存在一条通信路径。如
果一个软件开发小组有 n 个人，每
两人之间都需要通信，则总的通信
路径有 n(n-1)/2 (条 )。
? 设一个人单独开发软件，生产率是
5000行／人年 。若 4 个人 组成一个
小组共同开发这个软件，则需要 6
条通信路径 。若在每条通信路径上
耗费的工作量是 250 行／人年 。则
小组中每个人的软件生产率降低为
5000－ 6× 250／ 4 ＝
= 5000－ 375 ＝
= 4625 行／人年。
? 从上述分析可知,一个软件任务由
一个人单独开发，生产率最高 ；而
对于一个稍大型的软件项目，一个
人单独开发，时间太长。因此 软件
开发小组是必要的 。
? 但是，开发小组不宜太大，成员之
间避免太多的通信路径。
? 在开发进程中，切忌中途加人，避
免太多的生产率损失。
任务的确定与并行性
? 当参加同一软件工程项目的人数不
止一人的时候，开发工作就会出现
并行情形。
? 软件开发进程中设臵许多里程碑。
里程碑为管理人员提供了指示项目
进度的可靠依据。
? 软件工程项目的并行性提出了一系
列的进度要求。
? 因为并行任务是同时发生的，所以
进度计划表必须决定任务之间的从
属关系，确定各个任务的先后次序
和衔接，确定各个任务完成的持续
时间。
? 项目负责人应注意构成关键路径的
任务，即若要保证整个项目能按进
度要求完成，就必须保证这些任务
要按进度要求完成。
制定开发进度计划
? 40－ 20－ 40规则
?在整个软件开发过程中，编码工
作量仅占 20％，编码前工作量占
40％，编码后工作量占 40％。
? 40－ 20－ 40 规则只应用来做为
一个指南。实际的工作量分配比
例必须按照各项目的特点来决定。
? COCOMO模型
?开发进度 TDEV与工作量 MM的
关系：
TDEV ＝ a（ MM） b
?如果想要缩短开发时间，或想要
保证开发进度，必须考虑影响工
作量的那些因素。按可减小工作
量的因素取值。
? 按此比例确定各个阶段工作量的分
配，从而进一步确定每一阶段所需
的开发时间，然后在每个阶段，进
行任务分解，对各个任务再进行工
作量和开发时间的分配。
进度安排的方法
? 可以把用于一般开发项目的进度安
排的技术和工具应用于软件项目。
? 为监控 软件项目的进度计划和工作
的实际进展情况,为表现 各项任务
之间进度的相互依赖关系,需要采
用图示的方法。
? 在图示方法中，必须明确标明：
? 各个任务的 计划开始时间, 完成
时间 ；
? 各个任务 完成标志 （即○文档编
写和△评审）；
? 各个任务与参与工作的人数，各
个 任务与工作量之间的衔接情况 ；
? 完成各个任务所需的物理资源和
数据资源。
(1) 甘特图（ Gantt Chart）
? 在甘特图中，每一任务完成的标准，
不是以能否继续下一阶段任务为标
准，而是 以必须交付应交付的文档
与通过评审为标准 。因此在甘特图
中，文档编制与评审是软件开发进
度的里程碑。
(2) PERT技术和 CPM方法
? PERT技术叫做 计划评审技术,
CPM方法叫做 关键路径法,它们
都是安排开发进度，制定软件开发
计划的最常用的方法。
? 它们都采用网络图来描述一个项目
的任务网络，也就是从一个项目的
开始到结束，把应当完成的任务用
图或表的形式表示出来。
三个模块开发的网络图
? 通常用两张表来定义网络图。
? 一张表给出 与一特定软件项目有关
的所有任务 （也称为任务分解结构
WorkBreakdown Structure） ;
? 另一张表给出 应当按照什么样的次
序来完成这些任务 （有时称为限制
表 RestrictionList）。
PERT技术和 CPM方法都为项目计
划人员提供了一些定量的工具。
?确定关键路径,即决定项目开发
时间的任务链。在关键路径上的
各个任务都是时间余量为零的关
键任务，不能有任何时间延误。
?应用统计模型,对每一个单独的
任务确定最可能的开发持续时间
的估算值。
?计算边界时间,以便为具体的任
务定义时间窗口。
项目的追踪和控制
软件项目管理一项重要工作就是 在
项目实施过程中 进行 追踪 和 控制,
? 定期举行项目状态会议。由每位项
目成员报告其进展和遇到的问题。
? 评价在软件工程过程中所产生的所
有评审的结果。
? 确定由项目的计划进度所安排的可
能选择的正式的里程碑。
? 比较在项目资源表中所列出的每一
个项目任务的实际开始时间和计划
开始时间。
? 非正式地与开发人员交谈，以得到
他们对开发进展和刚冒头的问题的
客观评价。
? 当问题出现的时候,项目管理人
员必须 实行控制以尽快地排解 问题。
软件项目的组织与计划
? 制定计划
? 软件项目组织的建立
? 人员配备
制定计划
? 软件开发项目的计划涉及到实施项
目的各个环节，带有全局性质。
? 计划的 合理性 和 准确性 往往关系着
项目的成败。
? 计划应力求完备。要 考虑到一些未
知因素和不确定因素, 考虑到可能
的修改 。计划应力求准确。 尽可能
提高所依据数据的可靠程度 。
1,制定计划目标和进行风险分析
? 制定计划的目的就是要回答：这
个软件项目的范围是什么？需要
哪些资源？花费多少工作量？要
用的成本有多少？以及进度如何
安排等等一系列问题。
? 这步工作应当以系统计划为基础，
以系统规格说明为依据。
? 在开发工作尚未开始之前，准确回
答这些问题是十分困难的。需要通
过以往的开发经验做出估算,很难
达到准确 。
? 从估算出发，项目必然带有一定的
风险 。估算的准确性越差，风险也
就越大。研制的软件项目越复杂，
规模越大，结构化程度越低，资源、
成本、进度等因素的不确定性越大，
承担这一项目所冒的风险也越大。
? 组织软件项目必须事先认清可能构
成风险的因素，并研究战胜风险的
对策，只有这样才能避免出现灾难
性的后果，取得项目预期的成果。
2,软件计划的类型
? 针对不同工作目标，软件计划有：
?项目实施计划 （ 软件开发计划 ）
这是软件开发的综合性计划，通常
应包括任务、进度、人力、环境、
资源、组织等多个方面。
?质量保证计划 把软件开发的质
量要求具体规定为每个开发阶段可
以检查的质量保证活动。
?软件测试计划 规定测试活动的
任务、测试方法、进度、资源、人
员职责等。
?文档编制计划 规定所开发项目
应编制的文档种类、内容、进度、
人员职责等。
?用户培训计划 规定对用户进行
培训的目标、要求、进度、人员职
责等。
?综合支持计划 规定软件开发过
程中所需要的支持，以及如何获取
和利用这些支持。
?软件分发计划 软件开发项目完
成后，如何提供给用户。
3,项目实施计划中任务的划分
? 如何进行工作划分是实施计划首先
应解决的问题。常用的计划结构有：
?阶段项目计划
按软件生存期，把开发工作划分为
若干阶段，对每一阶段工作做出计
划。再把每一阶段工作分解为若干
任务，做出任务计划。还要把任务
细分为若干步骤，做出步骤计划。
?任务分解结构
按项目的实际情况进行自顶向下的
结构化分解，形成树形任务结构。
进一步把工作内容、所需工作量、
预计完成的期限也规定下来。
?任务责任矩阵
在任务分解的基础上，把工作分配
给相关的人员，用一个矩阵形表格
表示任务的分工和责任。
任务分解结构
任务责任矩阵
软件项目组织的建立
? 开发组织采用什么形式，要针对 软
件项目的特点 来决定，同时也 与参
与人员的素质有关 。
1、组织原则
(1) 尽早落实责任,在软件项目工
作开始时，要尽早 指定专人负责 。
使他 有权进行管理,并 对任务的完
成负全责 。
（ 2）减少接口,一个组织的 生产
率随完成任务中存在的通信路径数
目增加而降低 。要有合理的人员分
工、好的组织结构、有效的通信，
减少不必要的生产率的损失。
（ 3）责权均衡,软件经理人员所
负的责任不应比委任给他的权力还
大。
2,组织结构的模式
（ 1）按课题划分的模式
把软件开发人员按课题组成小组，
小组成员自始至终参加所承担课题
的各项任务。他们应负责完成软件
产品的定义、设计、实现、测试、
复查、文档编制、甚至包括维护在
内的全过程。
（ 2）按职能划分的模式
把参加开发项目的软件人员按任务
的工作阶段划分成若干个专业小组。
要开发的软件产品在每个专业小组
完成阶段加工（即工序）以后，沿
工序流水线向下传递。例如，分别
建立计划组、需求分析组、设计组、
实现组、系统测试组、质量保证组、
维护组等。各种文档资料按工序在
各组之间传递。
（ 3）矩阵形模式
这种模式实际上是以上两种模式
的复合。一方面，按工作性质，
成立一些专门组，如开发组、业
务组、测试组等；另一方面，每
一个项目又有它的经理人员负责
管理。每个软件人员属于某一个
专门组，又参加某一项目的工作。
3.程序设计小组的组织形式
? 小组内部人员的组织形式对生产率
也有影响。现有的组织形式有三种。
（ 1）主程序员制小组
小组的核心由一位 主程序员 (高级
工程师 )、二至五位 技术员,一位
后援工程师 组成。主程序员负责小
组全部技术活动的计划、协调与审
查，设计和实现项目中的关键部分。
技术员负责项目的具体分析与开
发，文档资料的编写工作。后援
工程师支持主程序员的工作，为
主程序员提供咨询，也做部分分
析、设计和实现的工作。并在必
要时能代替主程序员工作。
主程序员制小组还可以由一些 专
家 (如通信专家或数据库设计专
家 ),辅助人员 (如打字员和秘书 )、
软件资料员 协助工作。
（ 2）民主制小组
在民主制小组中，遇到问题，组内
成员之间可以平等地交换意见。 工
作目标的制定及做出决定都由全体
成员参加。 虽然也有一位成员当组
长，但工作的讨论、成果的检验都
公开进行。 这种组织形式强调发挥
小组每个成员的积极性。 有人认为
这种组织形式适合于研制时间长、
开发难度大的项目。
（ 3）层次式小组
在层次式小组中，组内人员分为
三级,组长（项目负责人） 一人
负责全组工作，包括任务分配、
技术评审和走查、掌握工作量和
参加技术活动。 他直接领导二至
三名 高级程序员,每位高级程序
员通过基层小组，管理若干位 程
序员 。
? 这种组织结构 只允许必要的人际通
信 。比较 适用于项目本身就是层次
结构的课题 。因为这样可以把项目
按功能划分成若干个子项目，把子
项目分配给基层小组，由基层小组
完成。
? 这种组织方式比较适合于大型软件
项目的开发。
人员配备
? 如何合理地配备人员，也是成功
地完成软件项目的切实保证。所
谓合理地配备人员应包括：
? 按不同阶段适时任用人员
? 恰当掌握用人标准 。
1,项目开发各阶段所需人员
? 一个软件项目完成的快慢，取决于
参与开发人员的多少。
? 在开发的整个过程中，多数软件项
目是以恒定人力配备的。
? 实际人力需求与开发进度的关系如
下图中的曲线所示 。
? 按此曲线，需要的人力随开发进展
逐渐增加，在编码与单元测试阶段
达到高峰，以后又逐渐减少。
? 如果恒定地配备人力，在开发初期
将会有部分人力资源用不上而浪费
掉。在开发中期，需要人力不够，
造成进度的延误。在开发后期就需
要增加人力以赶进度。
? 恒定地配备人力将浪费人力资源。
2,配备人员的原则
? 重质量 软件项目是技术性很强的
工作，要任用少量有实践经验、有
能力的人员去完成关键性的任务。
? 重培训 培养所需技术人员和管理
人员是有效解决人员问题的好方法。
? 双阶梯提升 人员提升应分别按技
术职务和管理职务进行，不能混在
一起。
3,对项目经理人员的要求
? 软件经理人员是工作的组织者,他
的管理能力的强弱是项目成败的关
键 。他应具有以下能力：
? 把用户提出的非技术性要求加以
整理提炼,以技术说明书的形式转
告给分析员和测试员。
? 能说服用户放弃一些不切实际的
要求,以保证合理的要求得以满足。
?能够把表面上似乎无关的要求集
中在一起,归结为, 需要什么,,
“要解决什么问题,。这是一种综
合问题的能力。
?要懂得心理学,能说服上级领导和
用户，让他们理解什么是不合理的
要求。但又要使他们毫不勉强,乐
于接受，并受到启发。
4,评价人员的条件
? 软件项目中人的因素越来越受重视。
在评价和任用软件人员时，必须掌
握一定的标准。 人员素质的优劣常
常影响到项目的成败 。
?牢固掌握计算机软件的基本知识
和技能。
?善于分析和综合问题，具有严密
的逻辑思维能力。
?工作踏实、细致,不靠碰运气，遵
循标准和规范，具有严格的科学作
风。
?工作中表现出有耐心、有毅力、有
责任心。
?善于听取别人的意见，善于与周围
人员团结协作，建立良好的人际关
系。
?具有良好的书面和口头表达能力。
软件过程与过程成熟度模型
? 软件过程是软件生存期中的一系
列相关过程。
? 过程是活动的集合；
? 活动是任务的集合；
? 任务是将输入变换为输出的操作；
? 活动的执行可以是顺序的，重复
的，并行的、嵌套的；
? 为了得到满足要求的软件产品，不
但需要有好的开发方法，还需要有
好的工程支持和工程管理。
?基本过程
? 获取过程
? 供应过程
? 开发过程
? 运行过程
? 维护过程
?获取过程
? 是 需方 为了 获得 一个 软件产品 所进
行的一系列活动：该过程从为获取
该软件产品的需求定义开始，经过
招标准备，合同的准备和修改，对
供方的监督，直到验收完成。
? 供应过程
? 是 供方 为向需方 提供软件产品 所进
行的一系列活动：该过程从理解软
件的需求开始，经过投标准备，签
订合同，制定计划，实施计划及控
制，进行评审和评价，直至完成交
付。
? 开发过程
? 是 软件开发者 根据合同 开发 和 交付
软件 的一系列活动。包括的活动有：
? 过程的实施准备
? 系统需求分析
? 系统结构设计
? 软件需求分析
? 软件体系结构设计
? 软件详细设计
? 程序编码和单元测试
? 软件集成
? 软件确认测试
? 系统集成
? 系统确认测试
? 软件安装
? 软件验收支持
? 运行过程
? 软件开发完成后，软件从开发环境
转移到用户的实际运行环境。在运
行时对用户的要求提供帮助和咨询，
对运行效果进行评价。
? 实施过程的准备
? 运行测试
? 系统向实际运行环境转移
? 系统运行
? 对用户运行的支持
? 系统运行评价
? 用户运行评价
? 维护过程
? 过程的实施准备
? 问题分析和修改分析
? 修改的实施
? 对维护进行评审／验收
? 移植
? 软件退役
?支持过程
? 文档过程
? 配臵管理过程
? 质量保证过程
? 验证过程
? 确认过程
? 联合评审过程
? 审计过程
? 问题解决过程
?文档过程
? 文档过程是一个记录由某一过程或
活动所产生的信息的过程。它由以
下活动组成,
? 过程的实施准备
? 设计与开发
? 制作与发行
? 维护
? 配臵管理过程
? 过程的实施准备
? 配臵的确定
? 配臵的控制
? 配臵情况报告
?配臵的评价
?发行管理和提交
?质量保证过程
? 这是一个为使软件过程和软件产品
符合规定需求，并按预定计划按时
完成提供适当保证的过程。
? 过程的实施准备
? 软件产品的质量保证
? 软件过程的质量保证
?验证过程
? 确定系统或软件的需求是否完备和
正确,以及每一阶段的软件产品是
否达到前一阶段对它的要求和条件。
? 过程的实施准备 ? 验证
? 合同验证 ? 过程验证
? 需求验证 ? 设计验证
? 代码验证 ? 集成验证
? 文档验证
?确认过程
? 确认需求和最终建立的系统或软
件是否满足原计划的特定应用。
? 过程的实施准备
? 确认
?联合评审过程
? 这是评价项目的某个活动或阶段的
执行情况,以及产品是否合乎要求
的过程。
? 过程的实施准备
? 项目管理评审
? 技术评审
?审计过程
? 这一过程是要审计确定合作的另一
方遵照需求、计划合同到什么程度
的过程。
? 过程的实施准备
? 审计
?问题解决过程
? 这是一个用于分析和排除在开发、
运行、维护或其它过程中发现的
问题和不一致的过程。
? 过程实施准备
? 问题解决
?组织过程
? 管理过程
? 基础设施过程
? 改进过程
? 培训过程
?管理过程
? 管理包括进度管理、成本管理、质
量管理、人员管理、资源管理、标
准化管理。
? 管理的对象是进度、系统规模及工
作量估算、经费、组织机构很人员、
风险、质量、作业和环境配臵等。
? 过程的实施准备
? 管理计划的制定
? 计划的实施与控制
? 评审和评价计划的完成程度
? 编写管理文档。
?基础设施过程
? 该过程建立、维护各个过程所需
的基础设施。
? 基础设施包括硬件、软件、工具、
技术、标准,以及开发、运行、维
护所需的设施。
?改进过程
? 该过程建立、评估、度量、控制和
改进软件生存期的过程。主要活动
是制定一组组织计划,评估相关过
程,实施分析、改进过程。
?培训过程
? 该过程为系统或软件产品提供人
员培训。主要活动有制定所需人
员用人计划和培训计划,开发培训
资料,实施培训活动等。
?软件过程的度量
软件过程成熟度
? 是指对过程计划或定义水平、过
程实施水平、过程管理和控制水
平、过程改善潜力等指标的综合
评价。
? 分为 5 级, 初始级, 可重复级, 可
定义级, 可管理级, 可优化级 。
评估软件过程时遵循的原则
? 在很大程度上，软件产品的质量取
决于生产该产品的过程质量。
? 软件过程是一个可管理、可测量和
可改进的过程。
? 软件过程的质量受其支持技术的影
响。
? 用于软件工程的技术水平应与过程
的成熟度相适应。
1 初始级
? 特点 过程执行杂乱无序
? 关键问题 项目计划管理、配臵管
理、软件质量保证
? 达标标准 过程活动无一定秩序，
开发过程的可重复性差
2 可重复级
? 特点 过程管理工作依赖管理人员
的技能
? 关键问题 培训、技术评审、标准
? 达标标准 使项目管理处于严格控
制之下，包括严格的项目计划和追
踪、子合同管理、需求变更和产品
基线控制
3 可定义级
? 特点 过程可定义、可执行
? 关键问题 过程度量、过程分析、
质量计划
? 达标标准 定义一个适合该组织的
软件过程，有正规的文档化的规范，
并能根据不同项目的要求裁剪和优
化这个软件过程
4 可管理级
? 特点 过程成为可度量的
? 关键问题 改善技术, 问题分析,
防止出错
? 达标标准 为定义好的过程建立一
套详细的度量机制, 为产品和过程
设立质量目标, 度量软件过程和产
品
5 可优化级
? 特点 通过反馈来改善过程
? 关键问题 自动化、反馈技术
? 达标标准 用第 4 级建立的度量机
制，不断地指导过程改善，技术革
新和防止出错
关键过程领域 KPA
（ Key Process Area）
? 除去初始级以外，其它 4 级都有若
干个引导软件机构改进软件过程的
要点，称为关键过程领域。
? 每一个关键过程领域是一组相关的
活动，成功地完成这些活动，将会
对提高过程能力起重要作用。
11 初初 始始 级级
22 可可 重重 复复 级级 需需 求求 管管 理理
软软 件件 项项 目目 计计 划划
软软 件件 项项 目目 跟跟 踪踪 与与 监监 督督
软软 件件 分分 包包 合合 同同 管管 理理
软软 件件 质质 量量 管管 理理
软软 件件 配配 臵臵 管管 理理关键过程域
33 可可 定定 义义 级级 软软 件件 机机 构构 过过 程程 关关 注注 点点
软软 件件 机机 构构 过过 程程 定定 义义
培培 训训 计计 划划
整整 体体 化化 软软 件件 管管 理理
软软 件件 产产 品品 工工 程程
组组 间间 合合 作作
同同 行行 评评 审审
44 可可 管管 理理 级级 定定 量量 过过 程程 管管 理理
软软 件件 质质 量量 管管 理理
55 可可 优优 化化 级级 过过 程程 变变 更更 管管 理理
预预 防防 故故 障障
技技 术术 变变 更更 管管 理理
