信息系统的开发与管理教程
中国人民大学：左美云
zuomy@ruc.edu.cn
第九章
一、信息系统与项目管理
信息系统的建设是一类项目
? 信息系统的建设是一次性的任务, 有一定的
任务范围和质量要求,
? 有时间或进度的要求,
? 有经费或资源的限制 。
? 信息系统具有生命周期
– 系统规划, 系统分析, 系统设计, 系统实施, 系
统运行和维护五个阶段 。
? 从具体构成来看, 信息系统项目可分为客户
需求分析, 应用软件开发, 网络规划与设计,
设备采购以及系统调试与集成等多项内容 。
信息系统项目的特点
? 信息系统项目的目标是不精确的, 任务的边界是模
糊的, 质量要求更多是由项目团队来定义的 。
? 信息系统项目进行过程中, 客户的需求会不断被激
发, 被不断地进一步明确, 导致项目的进度, 费用
等计划不断更改 。
? 信息系统项目是智力密集, 劳动密集型的项目, 受
人力资源影响最大, 项目成员的结构, 责任心, 能
力和稳定性对信息系统项目的质量以及是否成功有
决定性的影响 。
二、计划、费用与进度管理
信息系统项目的计划
? 信息系统项目的计划是用来指导组织, 实施, 协调
和控制信息系统建设的文件, 制订一个良好的计划
有诸多好处, 比如,
– 可以将计划的假设与前提写成书面文件, 以备发生变更
时查考；
– 有助于项目成员之间的交流沟通, 有助于大家统一认识；
– 可以确定测量项目进展, 对项目进行控制和考核工作业
绩的基准 。
? 进度计划, 费用计划, 人力计划, 质量保证计划,
风险管理计划等 。
? 全过程计划, 也可以是阶段性计划或子系统计划
（一）,成本的构成及测算
信息系统项目成本的构成
信息系统项目成本的测算分析
? 信息系统项目的成本测算, 就是根据待开发信息系
统的成本特征以及当前能够获得的有关数据和情况,
运用定量和定性分析方法对信息系统生命周期各阶
段的成本水平和变动趋势做出尽可能科学的估计 。
– 最难确定的是开发成本中的软件开发成本, 而硬件成本
和其他成本相对容易估算出来 。
– 至于运行维护成本, 则可以根据开发成本与运行维护成
本比值的经验数据和测算出来的开发成本一起计算 。
– 并且, 对于信息系统项目的用户来讲, 项目开发成本的
不确定性因素较大, 而项目的运行维护成本由于多次发
生, 且在自身的使用中发生, 相对来讲容易控制一些 。
所以信息系统项目成本测算的重点是软件开发成本 。
信息系统项目成本测算过程
（二）、软件规模与 成本的估算
软件常用的估算方法
? 参照已经完成的类似项目, 估算待开发项目
的软件开发成本和工作量 。
? 将大的项目分解成若干小的子系统, 在估算
出每个子系统软件开发成本和工作量之后,
再估算整个项目的软件开发成本 。
? 将软件按信息系统的生命周期分解, 分别估
算出软件开发在各个阶段的工作量和成本,
然后再把这些工作量和成本汇总, 估算出整
个软件开发的工作量和成本 。
? 根据实验或历史数据给出软件开发工作量或
成本的经验估算公式 。
软件代码行的方式
? 软件开发的生产率,Pl＝ L／ E 其中,
– L是应用软件的总代码行数 。 用千行代码 KLOC
（ 1KLOC＝ 103LOC） 度量 。
– E是应用软件的工作量, 用人月 （ PM） 度量 。
– Pl是软件开发的生产率, 用每人月完成的代码行
数 （ LOC／ PM） 度量 。
? 每行代码的平均成本,Cl＝ S／ L 其中,
– S是软件开发的总成本, 用人民币元或美元度量 。
– Cl是软件项目每行代码的平均成本, 用人民币元
（ 或美元 ） ／代码行度量 。
软件代码行方式的缺点
? 用软件代码行数估算软件的开发规模简单易
行, 其缺点也有不少,
? 代码行数的估算依赖于程序设计语言的功能
和表达能力；
? 采用代码行估算方法会对设计精巧的软件项
目产生不利的影响；
? 在软件项目开发前或开发初期估算它的代码
行数十分困难；
? 代码行估算只适用于过程式程序设计语言,
对非过程式的程序设计语言不太适用, 等等 。
功能点计算中 CT的度量
? 这种方法用 6个信息量的, 加权和, CT和 14
个因素的, 复杂性调节值, Fi （ i＝ 1,2,…,
14） 计算功能点 FP,
? 软件开发的生产率,Pf＝ FP／ E 其中,
– Pf表示每人月完成的功能点数 。
– E是工作量, 用人月 （ PM） 度量 。
? 每功能点的平均开发成本,Cf＝ S／ FP 其中,
– S是软件开发的总成本
– Cf表示每功能点的平均开发成本
软件功能点的方式
]01.065.0[
14
1
?
?
??
i
iFCTFP
功能点计算中 Fi的估值
? 采用功能点度量的优点主要有两条,
– 第一, 与程序设计语言无关, 它不仅适用于过程
式语言, 也适用于非过程式的语言, 这对于面向
对象的开发方式尤为有用；
– 第二, 由于在信息系统项目启动时就能基本上确
定系统的输入, 输出等参数, 所以功能点度量能
用于软件开发成本在初期的预估 。
? 缺点主要是它涉及到的主观因素比较多, 如
Fi的选取与评估人的经验和态度有较大的关
系, 并且 FP的值没有直观的物理意义 。
软件功能点方式的优缺点
? 采用前述四种估算方法估算出 L或 FP的乐观
值 a,悲观值 b和一般值 m,然后根据下列加
权公式计算出期望值,e＝ (a十 4m十 b)／ 6
? 当 L或 FP的期望值估算出来之后, 根据以前
开发软件的数据可知软件开发平均生产率
（ KLOC／ PM或 FP／ PM） 计算出工作量 。
? 比如软件项目规模按功能点估算为 3l0 FP，
假设以前完成项目的平均生产率为 5.5FP／
PM,已知每人月的开发成本为 1万元, 于是,
? 工作量估算为,E＝ 310／ 5.5＝ 56PM
? 软件开发成本估算为,C＝ 56× 1＝ 56万元
软件规模和成本的的测算
? CoCoMo 模 型 是, 构 造 性 成 本 模
型, (Constructive Cost Model, 简称
CoCoMo模型 )的英文缩写, 分为基本, 中间,
详细三个层次, 分别用于软件开发的不同阶
段 。
– 基本 CoCoMo模型用于系统开发的初期, 估算整
个系统的工作量 （ 包括软件维护 ） 和软件开发所
需要的时间；
– 中间 CoCoMo模型用于估算各个子系统的工作量
和开发时间；
– 详细 CoCoMo模型用于估算独立的软部件, 如子
系统内部的各个模块 。
CoCoMo模型简介
? 基本 CoCoMo模型是静态, 单变量模型, 具
有下列形式,
? E＝ aLb
? D＝ cEd
? C＝ λE
? 其中,
– L是项目的代码行估计值
– E表示工作量, 单位是人月 （ PM）
– D表示开发时间, 单位是月 。
– C表示开发成本, 单位是万元 。
– λ表示每人月的人力成本, 单位是万元 /人月
– a,b,c,d是常数
基本 CoCoMo模型
基本 CoCoMo模型参数取值
? Putnam模型, 是由 Putnam提出的大型软件
项目工作量 （ 一般在 30人年以上 ） 估算模型 。
? 它是一个动态多变量模型, 适用于软件开发
的各个阶段 。
? 估算模型以大型软件项目的实测数据为基础,
描述了开发工作量, 开发时间和软件代码行
数之间的关系 。
Putnam模型简介
? 相应的方程是,
? 其中,
– L表示源程序代码行数
– E表示工作量 （ 以人年记, 包括维护 ）
– td表示开发时间 （ 以年记 ）
– Ck表示技术状态常数, 它反映出, 妨碍程序员进
展的限制,, 并因开发环境而异 。
? 显然,
? C＝ λE 其中,
– C表示开发成本, 单位是万元；
– λ表示每人年的人力成本, 单位是万元 /人年 。
Putnam模型
3/43/1
dk tECL ?
)/( 433 dk tCLE ?
Putnam模型技术状态常数 Ck的取值
? 在 Putnam模型中, 开发软件项目的工作量与交付
时间的 4次方成反比, 将 0.9 td代替式中的 td计算 E，
我们发现, 提前 10％ 的时间要增加 52％ 的工作量,
显然是降低了软件开发生产率 。 因此, 软件开发过
程中人员与时间的折衷是一个十分重要的问题 。
? 由上述对两个经验模型的分析可知, CoCoMo模型
和 Putnam模型都是在估算软件代码行的方式基础上,
估算出了软件开发的工作量和软件开发的成本 。
? 对于软件的开发时间, CoCoMo模型是根据经验公
式估算出来的, 对于 Putnam模型则是与工作量相权
衡的结果 。
? 对于软件的人力投入, 两个模型都可以根据工作量
和开发时间的比值测算出来 。
两个经验模型点评
? 到此, 我们就讨论完了软件规模, 成本, 开
发时间, 人力投入的测算过程 。
? 在此基础上, 就可以根据测算的软件开发成
本, 硬件成本和信息系统开发期间的其他成
本计算出信息系统的开发成本, 再根据信息
系统开发成本占信息系统总成本比例的经验
数据得出信息系统项目的总成本 。
? 相应地, 也可以根据软件开发时间或人力投
入占信息系统项目总时间或总人力比例的经
验数据知道信息系统项目建设所需要的总时
间, 总人力 。
信息系统项目的总成本
（三）、项目的进度与 成本计划
? 项目经理组织队伍形成项目团队, 绘制专业领域技术编制表, 建立一个工作分析结构 （ WBS）, 并在
此基础上建立项目组成员的责任矩阵 。
? 所谓工作分析结构是指将一个信息系统项目分解成
易于管理的几部分或几个细目, 细目再展开成子细
目, 任何分支最低层的细目叫工作包 。
? 比如对于一个待建系统可以先按照生命周期的各阶段展开, 然后按照子系统或系统功能点展开 。
? 责任矩阵一旦建立, 就可以进行项目各建设活动的
工期估计和预算分摊估计 。
? 工期估计和预算分摊估计各有两种办法, 一种是自
上而下法, 即在项目建设总时间和总成本之内按照
每一工作包的相关工作范围来考察, 以项目总时间
或总成本的一定比例分摊到各个工作包中 。 另一种
方法是自下而上法, 它是由每一工作包的具体负责
人来做估计的方法 。
工作包、分摊
? 现在某企业准备开发一个客户关系管理的信
息系统, 合同双方将系统交付使用作为项目
终结的依据, 双方同意维护期间费用另行支
付 。 经上述测算, 估算该项目总开发工作量
为 4人年, 项目总开发时间为 50周, 项目的总
成本 （ 包括软件开发成本, 硬件成本和开发
中的其他成本 ） 是 100万元人民币 。
? 将该项目划分为六个大的活动, 并明确了各
活动的工期：系统规划 （ 5周 ）, 系统分析
（ 10周 ）, 系统设计 （ 10周 ）, 系统实现
（ 15周 ）, 系统测试 （ 8周 ） 和系统转换 （ 5
周 ） 。
分摊实例
客户关系信息系统项目甘特图
客户关系信息系统项目分摊
客户关系信息系统项目
活动 小活动 紧前
活动
工期估计
（周）
预算分摊
（万元）
预算累计
（万元）
1, 收 集 数 据 一 3 1,5 1,5
2, 可 行 性 研 究 一 4 2 3, 5
系统
规划
3, 准 备 系 统 规 划 报 告 1, 2 1 0, 5 4
4, 与 业 务 人 员 沟 通 3 5 3 7
5, 研 究 现 有 系 统 3 8 4 11
6, 明 确 用 户 需 求 4 5 2 13
系统
分析
7, 准 备 系 统 分 析 报 告 5, 6 1 1 14
8, 分 析 数 据 输 入 和 输 出 7 8 4 18
9, 处 理 数 据 和 建 数 据 库 7 10 4 22
10, 审 查 数 据 字 典 8, 9 2 1 23
系统
设计
11, 准 备 系 统 设 计 报 告 10 2 2 25
12, 开 发 软 件 11 15 15 40
13, 硬 件 规 划 与 采 购 11 10 38 78
14, 网 络 实 现 11 6 5,5 8 3, 5
系统
实现
15, 准 备 系 统 实 现 报 告 12, 13, 14 2 1, 5 85
16, 测 试 软 件 15 6 6 91
17, 测 试 硬 件 15 4 1, 5 9 2, 5
18, 测 试 网 络 15 4 1, 5 94
系统
测试
19, 准 备 系 统 测 试 报 告 16, 17, 18 1 1 95
20, 人 员 培 训 19 4 2 97
21, 系 统 转 换 19 2 4 101
系统
转换
22, 准 备 系 统 转 换 报 告 20, 21 1 1 102
? 最早开始时间 （ Earliest Start time,ES） 和最早结
束时间 （ Earliest Finish time,EF）
? ES和 EF是通过网络图的正向计算得到的 。
? 规则：某项活动的最早开始时间 （ ES） 必须相同或
晚于直接指向这项活动的所有活动的最早结束时间
（ EF） 中的最晚时间 。
? EF＝ ES十工期估计 。
? 最迟开始时间 （ Latest Start time,LS） 和最迟结束
时间 （ Latest Finish time,LF） 。
? LF和 LS可以通过网络图的反向推算得出 。
? 规则：某项活动的最迟结束时间 （ LF） 必须相同或
早于该活动直接指向的所有活动最迟开始时间 （ LS）
的最早时间 。
? LS＝ LF－工期估计 。
ES,EF, LS,LF
客户关系信息系统项目进度
最早 最迟
活 动
工期
估计
（周）
开始
时间
结束
时间
开始
时间
结束
时间
总
时差
1, 收 集 数 据 3 0 3 -8 -5 -8
2, 可 行 性 研 究 4 0 4 -9 -5 -9
3, 准 备 系 统 规 划 报 告 1 4 5 -5 -4 -9
4, 与 业 务 人 员 沟 通 5 5 10 -4 1 -9
5, 研 究 现 有 系 统 8 5 13 -2 6 -7
6, 明 确 用 户 需 求 5 10 15 1 6 -9
7, 准 备 系 统 分 析 报 告 1 15 16 6 7 -9
8, 分 析 数 据 输 入 和 输 出 8 16 24 9 17 -7
9, 处 理 数 据 和 建 数 据 库 10 16 26 7 17 -9
10, 审 查 数 据 字 典 2 26 28 17 19 -9
11, 准 备 系 统 设 计 报 告 2 28 30 19 21 -9
12, 开 发 软 件 15 30 45 21 36 -9
13, 硬 件 规 划 与 采 购 10 30 40 26 36 -4
14, 网 络 实 现 6 30 36 30 36 0
15, 准 备 系 统 实 现 报 告 2 45 47 36 38 -9
16, 测 试 软 件 6 47 53 38 44 -9
17, 测 试 硬 件 4 47 51 40 44 -7
18, 测 试 网 络 4 47 51 40 44 -7
19, 准 备 系 统 测 试 报 告 1 53 54 44 45 -9
20, 人 员 培 训 4 54 58 45 49 -9
21, 系 统 转 换 2 54 56 47 49 -7
22, 准 备 系 统 转 换 报 告 1 58 59 49 50 -9
? 总时差可以用每项活动的最迟结束 （ 开始 ） 时间减
去它的最早结束 （ 开始 ） 时间算出, 即,
? 总时差＝ LF— EF 或 总时差＝ LS— ES
? 如果某项活动的总时差为正值, 表明该项活动花费
时间总量可以适当延长, 而不必担心会出现在要求
完工时间内活动无法完成的窘况 。 反之, 如果总时
差为负值, 则表明该项活动要加速完成以减少花费
的时间 。
? 要对项目的进度作到较好的控制, 必须找到项目网
络图中的关键路径 。
? 那些具有正的总时差的路径有时被称为非关键路径,
而那些总时差为零或负值的路径被称为关键路径,
并且我们将耗时最长的关键路径经常称为最关键路
径 。
总时差、关键路径
网
络
图
实
例
（
上
）
网
络
图
实
例
（
下
）
（四）、项目计划的变更管理
信
息
系
统
项
目
变
更
管
理
过
程
制定基准计划（进
度，预算）
启动项目
开始一个报告期
收集实际进程数据
（进度，成本）
将变化列入项目计划
（范围，进度，预算）
计算出更新的项目
（进度，预算）
分析当前状况并与计划
比较（进度，预算）
需采取纠正
措施吗？
识别纠正措施
和协调相关变化
还有下一个
报告期吗？
项目结束
是
是
否 否
? 第一是对近期内即将发生的活动加强控制,
积极挽回时间和成本, 这是因为早控制早主
动；
? 第二是工期估计最长或预算估计最大的活动
应进一步审核预估依据, 并做好该活动压缩
时间和费用的准备工作, 因为估计值越大的
项目更有压缩的可能；
? 第三, 将某些可以再分的活动进一步细分,
研究细分活动之间并行工作或知识重用的可
行性, 如可行, 则可以有效地压缩时间和费
用 。
计划调整的重点
? 时间与成本之间在一定的范围内有一定的替
代性, 时间 — 成本平衡法就是一种用最低的
相关成本的增加来缩短项目工期的方法 。 该
方法基于以下假设,
– 每项活动有两组工期和成本估计：正常和应急 。
– 一项活动的工期可以通过从正常时间减至应急时
间得到有效的缩减, 这要靠投入更多资源来实现
– 应急时间是确保活动按质量完成的时间下限 。
– 当需要将活动的预计工期从正常时间缩短至应急
时间时, 必须有足够的资源作保证 。
– 在活动的正常点和应急点之间, 时间和成本的关
系是线性的 。
时间 — 成本平衡法
附有正常和应急时间及成本的网络图
? 缩短工期的单位时间加急成本可用如下公式
计算,
? 每项活动的每周加急成本可根据上述公式分
别计算出来,
? 活动 A,6 000元／周
? 活动 B,10 000元／周
? 活动 C,5 000元／周
? 活动 D,6 000元／周
单位时间加急成本
应急时间正常时间
正常成本应急成本
成本加急单位时间
?
?
?
时间 — 成本平衡法的举例
? 下面介绍利用项目的预算累计量, 实际成本
累计量和盈余累计量三个指标监控成本变动
的方法 。
? 假设现有一个小型信息系统项目 —— 个人理
财信息系统需要开发, 合同总价款为 10万元
人民币, 拟在 12周内开发成功 。 项目采用原
型法方式开发, 为了简单起见, 将该项目分
为三个大的活动：需求分析与原型制作, 原
型改造与系统实现, 系统测试与转换 。
项目成本计划的变更控制
预算累计量（ Cumulative Budged Cost,CBC）
实际成本累计量（ Cumulative Actual Cost,CAC)
盈余累计量（ Cumulative Earned Value,CEV)
CBC, CAC, CEV的比较
个人理财信息系统三个累计量的比较图
三,IS项目的人员管理
? 信息系统项目的人力计划, 主要基于前面说
到的工作量和进度预估, 工作量与项目总时
间的比值就是理论上所需的人力数 。
? 人员 — 进度权衡定律
? Brooks定律
? 曾担任 IBM 公司操作系统项目经理的
F.Brooks从大量的软件开发实践中得出了另
一条结论：, 向一个已经拖延的项目追加开
发人员, 可能使它完成得更晚, 。
两个重要定律
)/( 433 dk tCLE ?
用作人力计划的 Rayleigh-Norden曲线
? 信息系统开发人员作为技术工种, 可不是一旦需要
就马上找得到的, 那么在制定人力资源计划时, 就
要在基本按照上述曲线配备人力的同时, 尽量使某
个阶段的人力稳定, 并且确保整个项目期人员的波
动不要太大 。 我们称这样的过程为人力资源计划的
平衡 。
? 人力资源平衡法是制定使人力资源需求波动最小化
的进度计划的一种方法 。
? 这种平衡人力资源的方法是为尽可能均衡地利用人
力资源并满足项目要求完成的进度 。
? 人力资源平衡是在不延长项目求完工时间的情况下
建立人力资源均衡利用的进度计划 。
人力资源平衡
反映学籍信息管理系统项目
人力资源需求的的网络图
基
于
活
动
最
早
开
始
时
间
的
人
力
资
源
计
划
图
基
于
资
源
平
衡
的
人
力
资
源
计
划
图
? 每个项目小组的人数不能太多, 否则组员间彼此通
信的时间将占系统建设时间的一个很大比重 。
? 通常不能把一个信息系统划分成大量独立的单元模
块或子系统, 否则, 不仅出现接口错误的可能性增
加, 而且系统测试将既困难又费时间 。
? 一般说来, 每个项目小组的规模应该比较小, 以
2— 8名成员为宜 。
? 如果项目属于中小型规模且建设时间在一年以内,
那么项目小组的成员可以是活动负责人制 。
? 如果项目属于大中型规模, 建设时间在一年以上,
那么就必须考虑项目建设人员因各种原因发生变动
的情况 。
项目小组的构成
大
型
信
息
系
统
项
目
基
层
项
目
小
组
的
具
体
构
成
及
举
例
? 项目团队成长的阶段
– 形成 （ forming） 阶段
– 震荡 （ storming） 阶段
– 正规 （ norming） 阶段
– 表现 （ performing） 阶段
? 激励的结果是使参与信息系统的所有成员组
织成一个工作富有成效的项目团队 。 有成效
的项目团队具有如下特点,
– 能清晰理解项目的目标；
– 每位成员的角色和职责有明确的期望；
– 以项目的目标为行为的导向；
– 项目成员之间高度信任, 高度地合作互助等 。
项目团队的成长与激励
信息系统项目团队的成长与激励
团队有效性自测表
问题 得分
1, 你 的 团 队 对 项 目 目 标 有 明 确 的 理 解 吗? （ ）
2, 项 目 工 作 内 容, 质 量 标 准, 预 算 及 进 度 计 划 有 明 确 规 定 吗? （ ）
3, 每 个 成 员 都 对 他 （ 她 ） 的 角 色 及 职 责 有 明 确 的 期 望 吗? （ ）
4, 每 个 成 员 对 其 他 成 员 的 角 色 和 职 责 有 明 确 的 期 望 吗? （ ）
5, 每 个 成 员 了 解 所 有 成 员 为 团 队 带 来 的 知 识 和 技 能 吗? （ ）
6, 你 的 团 队 是 目 标 导 向 吗? （ ）
7, 每 个 成 员 是 否 强 烈 希 望 为 实 现 项 目 目 标 做 出 努 力? （ ）
8, 你 的 团 队 有 高 度 的 热 情 和 力 量 吗? （ ）
9, 你 的 团 队 是 否 能 高 度 地 合 作 互 助? （ ）
10, 是 否 经 常 进 行 开 放, 坦 诚 而 及 时 的 沟 通? （ ）
11, 成 员 愿 意 交 流 信 息, 想 法 和 感 情 吗? （ ）
12, 成 员 是 否 能 不 受 拘 束 地 寻 求 别 人 的 帮 助? （ ）
13, 成 员 愿 意 相 互 帮 助 吗? （ ）
14, 团 队 成 员 能 否 做 出 反 馈 和 建 设 性 的 批 评? （ ）
15, 团 队 成 员 能 否 接 受 别 人 的 反 馈 和 建 设 性 的 批 评？ （ ）
16, 项 目 团 队 成 员 中 是 否 有 高 度 的 信 任? （ ）
17, 成 员 是 否 能 完 成 他 们 要 做 或 想 做 的 事 情? （ ）
18, 不 同 的 观 点 能 否 公 开？ （ ）
19, 团 队 成 员 能 否 相 互 承 认 并 接 受 彼 此 的 差 异？ （ ）
20, 你 的 团 队 能 否 建 设 性 地 解 决 冲 突？ （ ）
总计得分 （ ）
四,IS项目的质量管理
信
息
系
统
生
命
周
期
各
阶
段
之
间
的
关
系
? 目前人们对信息系统项目提出的要求, 往往只强调
系统必须完成的功能, 应该遵循的进度计划, 以及
生产这个系统花费的成本, 却很少注意在整个生命
周期中信息系统应该具备的质量标准 。 这种做法的
后果是, 许多系统的维护费用非常高, 为了把系统
移植到另外的环境中, 或者使系统和其他系统配合
使用, 都必须付出很高代价 。
? 信息系统的质量管理不仅仅是项目开发完成后的最
终评价, 而是在信息系统开发过程中的全面质量控
制 。 也就是说, 不仅包括系统实现时的质量控制,
也包括系统分析, 系统设计时的质量控制；不仅包
括对系统实现时软件的质量控制, 而且还包括对文
档, 开发人员和用户培训的质量控制 。
IS项目的全面质量控制
变更时间与所付代价关系图
软件质量因素与产品活动的关系
表 软 件 质 量 因 素 的 定 义
质量因素 定 义
正确性 系统满足规格说明和用户 目 标的程度，即在预定环 境 下 能正确地完成预期功能 的
程度。
健壮性 在硬件发生故障,输入的 数 据无效或操作错误等意 外 环 境下,系统能做出适当响 应
的程度。
效率 为了完成预定的功能，系 统 需要的计算机资源的多 少 。
完整性
( 安全性 )
对未经授权的人使用软件 或 数据的企图，系统能够 控 制 ( 禁止 ) 的 程度 。
可用性 系统在完成预定应该完成 的 功能时令人满意的程度 。
风险性 按预定的成本和进度把系 统 开发出来，并且为用户 所 满 意的概率。
可理解性 理解和使用该系统的容易 程 度。
可维修性 诊断和改正在运行现场发 现 的错误所需要的工作量 的 大 小。
灵活性
( 适应性 )
修改或改进正在运行的系 统 需要的工作量的多少。
可测试性 软件容易测试的程度。
可移植性 把程序从一种硬件配置和 ( 或 ) 软 件 系 统 环 境 转 移 到 另 一 种 配 置 和 环 境 时, 需 要 的
工作量多少。
可重用性 在其他应用中该程序可以 被 再次使用的程度 ( 或范围 ) 。
互运行性 把该系统和另一个系统结 合 起来需要的工作量的多 少 。
? 实行工程化的开发方法
? 实行阶段性冻结与改动控制
? 实行里程碑式审查与版本控制
? 实行面向用户参与的原型演化
? 强化项目管理, 引入外部监理与审计
? 尽量采用面向对象和基于构件的方法进行系
统开发
? 进行全面测试
IS项目全面质量控制的办法
中国人民大学：左美云
zuomy@ruc.edu.cn
第九章
一、信息系统与项目管理
信息系统的建设是一类项目
? 信息系统的建设是一次性的任务, 有一定的
任务范围和质量要求,
? 有时间或进度的要求,
? 有经费或资源的限制 。
? 信息系统具有生命周期
– 系统规划, 系统分析, 系统设计, 系统实施, 系
统运行和维护五个阶段 。
? 从具体构成来看, 信息系统项目可分为客户
需求分析, 应用软件开发, 网络规划与设计,
设备采购以及系统调试与集成等多项内容 。
信息系统项目的特点
? 信息系统项目的目标是不精确的, 任务的边界是模
糊的, 质量要求更多是由项目团队来定义的 。
? 信息系统项目进行过程中, 客户的需求会不断被激
发, 被不断地进一步明确, 导致项目的进度, 费用
等计划不断更改 。
? 信息系统项目是智力密集, 劳动密集型的项目, 受
人力资源影响最大, 项目成员的结构, 责任心, 能
力和稳定性对信息系统项目的质量以及是否成功有
决定性的影响 。
二、计划、费用与进度管理
信息系统项目的计划
? 信息系统项目的计划是用来指导组织, 实施, 协调
和控制信息系统建设的文件, 制订一个良好的计划
有诸多好处, 比如,
– 可以将计划的假设与前提写成书面文件, 以备发生变更
时查考；
– 有助于项目成员之间的交流沟通, 有助于大家统一认识；
– 可以确定测量项目进展, 对项目进行控制和考核工作业
绩的基准 。
? 进度计划, 费用计划, 人力计划, 质量保证计划,
风险管理计划等 。
? 全过程计划, 也可以是阶段性计划或子系统计划
（一）,成本的构成及测算
信息系统项目成本的构成
信息系统项目成本的测算分析
? 信息系统项目的成本测算, 就是根据待开发信息系
统的成本特征以及当前能够获得的有关数据和情况,
运用定量和定性分析方法对信息系统生命周期各阶
段的成本水平和变动趋势做出尽可能科学的估计 。
– 最难确定的是开发成本中的软件开发成本, 而硬件成本
和其他成本相对容易估算出来 。
– 至于运行维护成本, 则可以根据开发成本与运行维护成
本比值的经验数据和测算出来的开发成本一起计算 。
– 并且, 对于信息系统项目的用户来讲, 项目开发成本的
不确定性因素较大, 而项目的运行维护成本由于多次发
生, 且在自身的使用中发生, 相对来讲容易控制一些 。
所以信息系统项目成本测算的重点是软件开发成本 。
信息系统项目成本测算过程
（二）、软件规模与 成本的估算
软件常用的估算方法
? 参照已经完成的类似项目, 估算待开发项目
的软件开发成本和工作量 。
? 将大的项目分解成若干小的子系统, 在估算
出每个子系统软件开发成本和工作量之后,
再估算整个项目的软件开发成本 。
? 将软件按信息系统的生命周期分解, 分别估
算出软件开发在各个阶段的工作量和成本,
然后再把这些工作量和成本汇总, 估算出整
个软件开发的工作量和成本 。
? 根据实验或历史数据给出软件开发工作量或
成本的经验估算公式 。
软件代码行的方式
? 软件开发的生产率,Pl＝ L／ E 其中,
– L是应用软件的总代码行数 。 用千行代码 KLOC
（ 1KLOC＝ 103LOC） 度量 。
– E是应用软件的工作量, 用人月 （ PM） 度量 。
– Pl是软件开发的生产率, 用每人月完成的代码行
数 （ LOC／ PM） 度量 。
? 每行代码的平均成本,Cl＝ S／ L 其中,
– S是软件开发的总成本, 用人民币元或美元度量 。
– Cl是软件项目每行代码的平均成本, 用人民币元
（ 或美元 ） ／代码行度量 。
软件代码行方式的缺点
? 用软件代码行数估算软件的开发规模简单易
行, 其缺点也有不少,
? 代码行数的估算依赖于程序设计语言的功能
和表达能力；
? 采用代码行估算方法会对设计精巧的软件项
目产生不利的影响；
? 在软件项目开发前或开发初期估算它的代码
行数十分困难；
? 代码行估算只适用于过程式程序设计语言,
对非过程式的程序设计语言不太适用, 等等 。
功能点计算中 CT的度量
? 这种方法用 6个信息量的, 加权和, CT和 14
个因素的, 复杂性调节值, Fi （ i＝ 1,2,…,
14） 计算功能点 FP,
? 软件开发的生产率,Pf＝ FP／ E 其中,
– Pf表示每人月完成的功能点数 。
– E是工作量, 用人月 （ PM） 度量 。
? 每功能点的平均开发成本,Cf＝ S／ FP 其中,
– S是软件开发的总成本
– Cf表示每功能点的平均开发成本
软件功能点的方式
]01.065.0[
14
1
?
?
??
i
iFCTFP
功能点计算中 Fi的估值
? 采用功能点度量的优点主要有两条,
– 第一, 与程序设计语言无关, 它不仅适用于过程
式语言, 也适用于非过程式的语言, 这对于面向
对象的开发方式尤为有用；
– 第二, 由于在信息系统项目启动时就能基本上确
定系统的输入, 输出等参数, 所以功能点度量能
用于软件开发成本在初期的预估 。
? 缺点主要是它涉及到的主观因素比较多, 如
Fi的选取与评估人的经验和态度有较大的关
系, 并且 FP的值没有直观的物理意义 。
软件功能点方式的优缺点
? 采用前述四种估算方法估算出 L或 FP的乐观
值 a,悲观值 b和一般值 m,然后根据下列加
权公式计算出期望值,e＝ (a十 4m十 b)／ 6
? 当 L或 FP的期望值估算出来之后, 根据以前
开发软件的数据可知软件开发平均生产率
（ KLOC／ PM或 FP／ PM） 计算出工作量 。
? 比如软件项目规模按功能点估算为 3l0 FP，
假设以前完成项目的平均生产率为 5.5FP／
PM,已知每人月的开发成本为 1万元, 于是,
? 工作量估算为,E＝ 310／ 5.5＝ 56PM
? 软件开发成本估算为,C＝ 56× 1＝ 56万元
软件规模和成本的的测算
? CoCoMo 模 型 是, 构 造 性 成 本 模
型, (Constructive Cost Model, 简称
CoCoMo模型 )的英文缩写, 分为基本, 中间,
详细三个层次, 分别用于软件开发的不同阶
段 。
– 基本 CoCoMo模型用于系统开发的初期, 估算整
个系统的工作量 （ 包括软件维护 ） 和软件开发所
需要的时间；
– 中间 CoCoMo模型用于估算各个子系统的工作量
和开发时间；
– 详细 CoCoMo模型用于估算独立的软部件, 如子
系统内部的各个模块 。
CoCoMo模型简介
? 基本 CoCoMo模型是静态, 单变量模型, 具
有下列形式,
? E＝ aLb
? D＝ cEd
? C＝ λE
? 其中,
– L是项目的代码行估计值
– E表示工作量, 单位是人月 （ PM）
– D表示开发时间, 单位是月 。
– C表示开发成本, 单位是万元 。
– λ表示每人月的人力成本, 单位是万元 /人月
– a,b,c,d是常数
基本 CoCoMo模型
基本 CoCoMo模型参数取值
? Putnam模型, 是由 Putnam提出的大型软件
项目工作量 （ 一般在 30人年以上 ） 估算模型 。
? 它是一个动态多变量模型, 适用于软件开发
的各个阶段 。
? 估算模型以大型软件项目的实测数据为基础,
描述了开发工作量, 开发时间和软件代码行
数之间的关系 。
Putnam模型简介
? 相应的方程是,
? 其中,
– L表示源程序代码行数
– E表示工作量 （ 以人年记, 包括维护 ）
– td表示开发时间 （ 以年记 ）
– Ck表示技术状态常数, 它反映出, 妨碍程序员进
展的限制,, 并因开发环境而异 。
? 显然,
? C＝ λE 其中,
– C表示开发成本, 单位是万元；
– λ表示每人年的人力成本, 单位是万元 /人年 。
Putnam模型
3/43/1
dk tECL ?
)/( 433 dk tCLE ?
Putnam模型技术状态常数 Ck的取值
? 在 Putnam模型中, 开发软件项目的工作量与交付
时间的 4次方成反比, 将 0.9 td代替式中的 td计算 E，
我们发现, 提前 10％ 的时间要增加 52％ 的工作量,
显然是降低了软件开发生产率 。 因此, 软件开发过
程中人员与时间的折衷是一个十分重要的问题 。
? 由上述对两个经验模型的分析可知, CoCoMo模型
和 Putnam模型都是在估算软件代码行的方式基础上,
估算出了软件开发的工作量和软件开发的成本 。
? 对于软件的开发时间, CoCoMo模型是根据经验公
式估算出来的, 对于 Putnam模型则是与工作量相权
衡的结果 。
? 对于软件的人力投入, 两个模型都可以根据工作量
和开发时间的比值测算出来 。
两个经验模型点评
? 到此, 我们就讨论完了软件规模, 成本, 开
发时间, 人力投入的测算过程 。
? 在此基础上, 就可以根据测算的软件开发成
本, 硬件成本和信息系统开发期间的其他成
本计算出信息系统的开发成本, 再根据信息
系统开发成本占信息系统总成本比例的经验
数据得出信息系统项目的总成本 。
? 相应地, 也可以根据软件开发时间或人力投
入占信息系统项目总时间或总人力比例的经
验数据知道信息系统项目建设所需要的总时
间, 总人力 。
信息系统项目的总成本
（三）、项目的进度与 成本计划
? 项目经理组织队伍形成项目团队, 绘制专业领域技术编制表, 建立一个工作分析结构 （ WBS）, 并在
此基础上建立项目组成员的责任矩阵 。
? 所谓工作分析结构是指将一个信息系统项目分解成
易于管理的几部分或几个细目, 细目再展开成子细
目, 任何分支最低层的细目叫工作包 。
? 比如对于一个待建系统可以先按照生命周期的各阶段展开, 然后按照子系统或系统功能点展开 。
? 责任矩阵一旦建立, 就可以进行项目各建设活动的
工期估计和预算分摊估计 。
? 工期估计和预算分摊估计各有两种办法, 一种是自
上而下法, 即在项目建设总时间和总成本之内按照
每一工作包的相关工作范围来考察, 以项目总时间
或总成本的一定比例分摊到各个工作包中 。 另一种
方法是自下而上法, 它是由每一工作包的具体负责
人来做估计的方法 。
工作包、分摊
? 现在某企业准备开发一个客户关系管理的信
息系统, 合同双方将系统交付使用作为项目
终结的依据, 双方同意维护期间费用另行支
付 。 经上述测算, 估算该项目总开发工作量
为 4人年, 项目总开发时间为 50周, 项目的总
成本 （ 包括软件开发成本, 硬件成本和开发
中的其他成本 ） 是 100万元人民币 。
? 将该项目划分为六个大的活动, 并明确了各
活动的工期：系统规划 （ 5周 ）, 系统分析
（ 10周 ）, 系统设计 （ 10周 ）, 系统实现
（ 15周 ）, 系统测试 （ 8周 ） 和系统转换 （ 5
周 ） 。
分摊实例
客户关系信息系统项目甘特图
客户关系信息系统项目分摊
客户关系信息系统项目
活动 小活动 紧前
活动
工期估计
（周）
预算分摊
（万元）
预算累计
（万元）
1, 收 集 数 据 一 3 1,5 1,5
2, 可 行 性 研 究 一 4 2 3, 5
系统
规划
3, 准 备 系 统 规 划 报 告 1, 2 1 0, 5 4
4, 与 业 务 人 员 沟 通 3 5 3 7
5, 研 究 现 有 系 统 3 8 4 11
6, 明 确 用 户 需 求 4 5 2 13
系统
分析
7, 准 备 系 统 分 析 报 告 5, 6 1 1 14
8, 分 析 数 据 输 入 和 输 出 7 8 4 18
9, 处 理 数 据 和 建 数 据 库 7 10 4 22
10, 审 查 数 据 字 典 8, 9 2 1 23
系统
设计
11, 准 备 系 统 设 计 报 告 10 2 2 25
12, 开 发 软 件 11 15 15 40
13, 硬 件 规 划 与 采 购 11 10 38 78
14, 网 络 实 现 11 6 5,5 8 3, 5
系统
实现
15, 准 备 系 统 实 现 报 告 12, 13, 14 2 1, 5 85
16, 测 试 软 件 15 6 6 91
17, 测 试 硬 件 15 4 1, 5 9 2, 5
18, 测 试 网 络 15 4 1, 5 94
系统
测试
19, 准 备 系 统 测 试 报 告 16, 17, 18 1 1 95
20, 人 员 培 训 19 4 2 97
21, 系 统 转 换 19 2 4 101
系统
转换
22, 准 备 系 统 转 换 报 告 20, 21 1 1 102
? 最早开始时间 （ Earliest Start time,ES） 和最早结
束时间 （ Earliest Finish time,EF）
? ES和 EF是通过网络图的正向计算得到的 。
? 规则：某项活动的最早开始时间 （ ES） 必须相同或
晚于直接指向这项活动的所有活动的最早结束时间
（ EF） 中的最晚时间 。
? EF＝ ES十工期估计 。
? 最迟开始时间 （ Latest Start time,LS） 和最迟结束
时间 （ Latest Finish time,LF） 。
? LF和 LS可以通过网络图的反向推算得出 。
? 规则：某项活动的最迟结束时间 （ LF） 必须相同或
早于该活动直接指向的所有活动最迟开始时间 （ LS）
的最早时间 。
? LS＝ LF－工期估计 。
ES,EF, LS,LF
客户关系信息系统项目进度
最早 最迟
活 动
工期
估计
（周）
开始
时间
结束
时间
开始
时间
结束
时间
总
时差
1, 收 集 数 据 3 0 3 -8 -5 -8
2, 可 行 性 研 究 4 0 4 -9 -5 -9
3, 准 备 系 统 规 划 报 告 1 4 5 -5 -4 -9
4, 与 业 务 人 员 沟 通 5 5 10 -4 1 -9
5, 研 究 现 有 系 统 8 5 13 -2 6 -7
6, 明 确 用 户 需 求 5 10 15 1 6 -9
7, 准 备 系 统 分 析 报 告 1 15 16 6 7 -9
8, 分 析 数 据 输 入 和 输 出 8 16 24 9 17 -7
9, 处 理 数 据 和 建 数 据 库 10 16 26 7 17 -9
10, 审 查 数 据 字 典 2 26 28 17 19 -9
11, 准 备 系 统 设 计 报 告 2 28 30 19 21 -9
12, 开 发 软 件 15 30 45 21 36 -9
13, 硬 件 规 划 与 采 购 10 30 40 26 36 -4
14, 网 络 实 现 6 30 36 30 36 0
15, 准 备 系 统 实 现 报 告 2 45 47 36 38 -9
16, 测 试 软 件 6 47 53 38 44 -9
17, 测 试 硬 件 4 47 51 40 44 -7
18, 测 试 网 络 4 47 51 40 44 -7
19, 准 备 系 统 测 试 报 告 1 53 54 44 45 -9
20, 人 员 培 训 4 54 58 45 49 -9
21, 系 统 转 换 2 54 56 47 49 -7
22, 准 备 系 统 转 换 报 告 1 58 59 49 50 -9
? 总时差可以用每项活动的最迟结束 （ 开始 ） 时间减
去它的最早结束 （ 开始 ） 时间算出, 即,
? 总时差＝ LF— EF 或 总时差＝ LS— ES
? 如果某项活动的总时差为正值, 表明该项活动花费
时间总量可以适当延长, 而不必担心会出现在要求
完工时间内活动无法完成的窘况 。 反之, 如果总时
差为负值, 则表明该项活动要加速完成以减少花费
的时间 。
? 要对项目的进度作到较好的控制, 必须找到项目网
络图中的关键路径 。
? 那些具有正的总时差的路径有时被称为非关键路径,
而那些总时差为零或负值的路径被称为关键路径,
并且我们将耗时最长的关键路径经常称为最关键路
径 。
总时差、关键路径
网
络
图
实
例
（
上
）
网
络
图
实
例
（
下
）
（四）、项目计划的变更管理
信
息
系
统
项
目
变
更
管
理
过
程
制定基准计划（进
度，预算）
启动项目
开始一个报告期
收集实际进程数据
（进度，成本）
将变化列入项目计划
（范围，进度，预算）
计算出更新的项目
（进度，预算）
分析当前状况并与计划
比较（进度，预算）
需采取纠正
措施吗？
识别纠正措施
和协调相关变化
还有下一个
报告期吗？
项目结束
是
是
否 否
? 第一是对近期内即将发生的活动加强控制,
积极挽回时间和成本, 这是因为早控制早主
动；
? 第二是工期估计最长或预算估计最大的活动
应进一步审核预估依据, 并做好该活动压缩
时间和费用的准备工作, 因为估计值越大的
项目更有压缩的可能；
? 第三, 将某些可以再分的活动进一步细分,
研究细分活动之间并行工作或知识重用的可
行性, 如可行, 则可以有效地压缩时间和费
用 。
计划调整的重点
? 时间与成本之间在一定的范围内有一定的替
代性, 时间 — 成本平衡法就是一种用最低的
相关成本的增加来缩短项目工期的方法 。 该
方法基于以下假设,
– 每项活动有两组工期和成本估计：正常和应急 。
– 一项活动的工期可以通过从正常时间减至应急时
间得到有效的缩减, 这要靠投入更多资源来实现
– 应急时间是确保活动按质量完成的时间下限 。
– 当需要将活动的预计工期从正常时间缩短至应急
时间时, 必须有足够的资源作保证 。
– 在活动的正常点和应急点之间, 时间和成本的关
系是线性的 。
时间 — 成本平衡法
附有正常和应急时间及成本的网络图
? 缩短工期的单位时间加急成本可用如下公式
计算,
? 每项活动的每周加急成本可根据上述公式分
别计算出来,
? 活动 A,6 000元／周
? 活动 B,10 000元／周
? 活动 C,5 000元／周
? 活动 D,6 000元／周
单位时间加急成本
应急时间正常时间
正常成本应急成本
成本加急单位时间
?
?
?
时间 — 成本平衡法的举例
? 下面介绍利用项目的预算累计量, 实际成本
累计量和盈余累计量三个指标监控成本变动
的方法 。
? 假设现有一个小型信息系统项目 —— 个人理
财信息系统需要开发, 合同总价款为 10万元
人民币, 拟在 12周内开发成功 。 项目采用原
型法方式开发, 为了简单起见, 将该项目分
为三个大的活动：需求分析与原型制作, 原
型改造与系统实现, 系统测试与转换 。
项目成本计划的变更控制
预算累计量（ Cumulative Budged Cost,CBC）
实际成本累计量（ Cumulative Actual Cost,CAC)
盈余累计量（ Cumulative Earned Value,CEV)
CBC, CAC, CEV的比较
个人理财信息系统三个累计量的比较图
三,IS项目的人员管理
? 信息系统项目的人力计划, 主要基于前面说
到的工作量和进度预估, 工作量与项目总时
间的比值就是理论上所需的人力数 。
? 人员 — 进度权衡定律
? Brooks定律
? 曾担任 IBM 公司操作系统项目经理的
F.Brooks从大量的软件开发实践中得出了另
一条结论：, 向一个已经拖延的项目追加开
发人员, 可能使它完成得更晚, 。
两个重要定律
)/( 433 dk tCLE ?
用作人力计划的 Rayleigh-Norden曲线
? 信息系统开发人员作为技术工种, 可不是一旦需要
就马上找得到的, 那么在制定人力资源计划时, 就
要在基本按照上述曲线配备人力的同时, 尽量使某
个阶段的人力稳定, 并且确保整个项目期人员的波
动不要太大 。 我们称这样的过程为人力资源计划的
平衡 。
? 人力资源平衡法是制定使人力资源需求波动最小化
的进度计划的一种方法 。
? 这种平衡人力资源的方法是为尽可能均衡地利用人
力资源并满足项目要求完成的进度 。
? 人力资源平衡是在不延长项目求完工时间的情况下
建立人力资源均衡利用的进度计划 。
人力资源平衡
反映学籍信息管理系统项目
人力资源需求的的网络图
基
于
活
动
最
早
开
始
时
间
的
人
力
资
源
计
划
图
基
于
资
源
平
衡
的
人
力
资
源
计
划
图
? 每个项目小组的人数不能太多, 否则组员间彼此通
信的时间将占系统建设时间的一个很大比重 。
? 通常不能把一个信息系统划分成大量独立的单元模
块或子系统, 否则, 不仅出现接口错误的可能性增
加, 而且系统测试将既困难又费时间 。
? 一般说来, 每个项目小组的规模应该比较小, 以
2— 8名成员为宜 。
? 如果项目属于中小型规模且建设时间在一年以内,
那么项目小组的成员可以是活动负责人制 。
? 如果项目属于大中型规模, 建设时间在一年以上,
那么就必须考虑项目建设人员因各种原因发生变动
的情况 。
项目小组的构成
大
型
信
息
系
统
项
目
基
层
项
目
小
组
的
具
体
构
成
及
举
例
? 项目团队成长的阶段
– 形成 （ forming） 阶段
– 震荡 （ storming） 阶段
– 正规 （ norming） 阶段
– 表现 （ performing） 阶段
? 激励的结果是使参与信息系统的所有成员组
织成一个工作富有成效的项目团队 。 有成效
的项目团队具有如下特点,
– 能清晰理解项目的目标；
– 每位成员的角色和职责有明确的期望；
– 以项目的目标为行为的导向；
– 项目成员之间高度信任, 高度地合作互助等 。
项目团队的成长与激励
信息系统项目团队的成长与激励
团队有效性自测表
问题 得分
1, 你 的 团 队 对 项 目 目 标 有 明 确 的 理 解 吗? （ ）
2, 项 目 工 作 内 容, 质 量 标 准, 预 算 及 进 度 计 划 有 明 确 规 定 吗? （ ）
3, 每 个 成 员 都 对 他 （ 她 ） 的 角 色 及 职 责 有 明 确 的 期 望 吗? （ ）
4, 每 个 成 员 对 其 他 成 员 的 角 色 和 职 责 有 明 确 的 期 望 吗? （ ）
5, 每 个 成 员 了 解 所 有 成 员 为 团 队 带 来 的 知 识 和 技 能 吗? （ ）
6, 你 的 团 队 是 目 标 导 向 吗? （ ）
7, 每 个 成 员 是 否 强 烈 希 望 为 实 现 项 目 目 标 做 出 努 力? （ ）
8, 你 的 团 队 有 高 度 的 热 情 和 力 量 吗? （ ）
9, 你 的 团 队 是 否 能 高 度 地 合 作 互 助? （ ）
10, 是 否 经 常 进 行 开 放, 坦 诚 而 及 时 的 沟 通? （ ）
11, 成 员 愿 意 交 流 信 息, 想 法 和 感 情 吗? （ ）
12, 成 员 是 否 能 不 受 拘 束 地 寻 求 别 人 的 帮 助? （ ）
13, 成 员 愿 意 相 互 帮 助 吗? （ ）
14, 团 队 成 员 能 否 做 出 反 馈 和 建 设 性 的 批 评? （ ）
15, 团 队 成 员 能 否 接 受 别 人 的 反 馈 和 建 设 性 的 批 评？ （ ）
16, 项 目 团 队 成 员 中 是 否 有 高 度 的 信 任? （ ）
17, 成 员 是 否 能 完 成 他 们 要 做 或 想 做 的 事 情? （ ）
18, 不 同 的 观 点 能 否 公 开？ （ ）
19, 团 队 成 员 能 否 相 互 承 认 并 接 受 彼 此 的 差 异？ （ ）
20, 你 的 团 队 能 否 建 设 性 地 解 决 冲 突？ （ ）
总计得分 （ ）
四,IS项目的质量管理
信
息
系
统
生
命
周
期
各
阶
段
之
间
的
关
系
? 目前人们对信息系统项目提出的要求, 往往只强调
系统必须完成的功能, 应该遵循的进度计划, 以及
生产这个系统花费的成本, 却很少注意在整个生命
周期中信息系统应该具备的质量标准 。 这种做法的
后果是, 许多系统的维护费用非常高, 为了把系统
移植到另外的环境中, 或者使系统和其他系统配合
使用, 都必须付出很高代价 。
? 信息系统的质量管理不仅仅是项目开发完成后的最
终评价, 而是在信息系统开发过程中的全面质量控
制 。 也就是说, 不仅包括系统实现时的质量控制,
也包括系统分析, 系统设计时的质量控制；不仅包
括对系统实现时软件的质量控制, 而且还包括对文
档, 开发人员和用户培训的质量控制 。
IS项目的全面质量控制
变更时间与所付代价关系图
软件质量因素与产品活动的关系
表 软 件 质 量 因 素 的 定 义
质量因素 定 义
正确性 系统满足规格说明和用户 目 标的程度，即在预定环 境 下 能正确地完成预期功能 的
程度。
健壮性 在硬件发生故障,输入的 数 据无效或操作错误等意 外 环 境下,系统能做出适当响 应
的程度。
效率 为了完成预定的功能，系 统 需要的计算机资源的多 少 。
完整性
( 安全性 )
对未经授权的人使用软件 或 数据的企图，系统能够 控 制 ( 禁止 ) 的 程度 。
可用性 系统在完成预定应该完成 的 功能时令人满意的程度 。
风险性 按预定的成本和进度把系 统 开发出来，并且为用户 所 满 意的概率。
可理解性 理解和使用该系统的容易 程 度。
可维修性 诊断和改正在运行现场发 现 的错误所需要的工作量 的 大 小。
灵活性
( 适应性 )
修改或改进正在运行的系 统 需要的工作量的多少。
可测试性 软件容易测试的程度。
可移植性 把程序从一种硬件配置和 ( 或 ) 软 件 系 统 环 境 转 移 到 另 一 种 配 置 和 环 境 时, 需 要 的
工作量多少。
可重用性 在其他应用中该程序可以 被 再次使用的程度 ( 或范围 ) 。
互运行性 把该系统和另一个系统结 合 起来需要的工作量的多 少 。
? 实行工程化的开发方法
? 实行阶段性冻结与改动控制
? 实行里程碑式审查与版本控制
? 实行面向用户参与的原型演化
? 强化项目管理, 引入外部监理与审计
? 尽量采用面向对象和基于构件的方法进行系
统开发
? 进行全面测试
IS项目全面质量控制的办法
