信息系统项目管理

信息系统项目管理 计算机科学技术发展系列讲座 第一节 概论 一、 项目的定义与特点 1 项目的定义 项目是在一定的 资源约束 下完成的 既定目标 的 一次性任务。 2 项目的特点 项目具有目的性 项目具有寿命周期 项目具有一定独特性 项目都有其固有客户 项目组织开放性 项目具有较强冲突性 项目具有一定风险性 二、 项目管理的定义与特点 1 项目管理的定义 项目管理是通过项目经理和项目组织机构运用系统理论和方法 对项目及其资源进行计划、组织、协调、控制，旨在实现项目 的特定目标的管理方法体系。 项目管理中的三要素 ： 目标、成本、进度 目标、成本、进度三者在项目管理过程中是互相制约的 进度 成本 目标 2 项目管理的基本特征： (1) 项目管理是一项复杂系统工程 项目需要 多种学科知识 来解决实际问题； 项目执行中的未知因决定项目的 不确定性 ； 项目的 临时性 给组织管理带来难度； 项目建设是在严格的 约束条件 下进行的； (2) 项目管理具有创造性，充满着权衡 创造带有探索性，有较高的失败率； 项目建设中对进度、费用与质量三者之间的权衡。 (3) 项目负责人在项目管理中起着非常重要的作用 项目管理的主要原理之一是项目经理负责制； 项目经理有权独立进行计划、资源分配、协凋和控制； 项目经理应有多学科知识、综合管理能力及现场处理能力； 项目经理应有迅速建立一支高效率群体的能力。 三、 信息系统项目特点 (1)信息系统项目的 目标不精确，任务的边界模糊 ，各种技术 指标更多地由项目组来定义。 (2)信息系统项目 客户需求不断激发 ，导致项目的进度、费用 等计划不断更改。 (3)信息系统项目是智力密集、劳动密集型， 受人力资源影响 最大 ，项目成员结构、责任心、能力和稳定性对信息系统 项目的质量以及是否成功有决定性的影响。 (4)信息系统项目的生命周期包括系统规划、系统分析、系统 设计、系统实施、系统运行和维护五个阶段，其各 阶段间 的关系密切、相互制约 。 (5)信息系统项目不是交钥匙工程，项目开发队伍通常要跟踪 到系统的使用生命周期结束，因此要求项目 开发队伍在较 长时间保持稳定 。 一、信息系统项目计划管理 1 项目计划用途： 项目计划是用来指导组织、实施、协调和控制信息系统建设的 重要文件 。 项目计划可作为客户与建设团队间解决冲突的依据。 项目计划可使项目成员有明确的分工及工作目标。 项目计划有助于项目成员之间的交流沟通。 项目计划可作为对项目过程控制和工作考核的基准。 2 项目计划分类： 进度计划 质量保证计划 费用计划 风险管理计划 人力计划 3 项目计划编制原则： 全过程计划（总体计划） ：应保持大体上稳定，并尽可能留有 一定余量和弹性， 阶段性计划 或 子系统计划 ：按近期精细、远期概略方法展开。 第二节 项目计划、费用与进度管理 4 项目计划管理： 通常信息系统项目计划的管理包含以下工作： 项目计划编制 ：项目经理或子项目负责人完成。 计划执行控制 ：定期进行检查、督导，并制定项目进度周 报、月报等相关制度。 计划变更处理 ：尽可能保证进度、费用和系统目标不变为 基础，运用一定的方法和理论调整、处理 各种复杂情况。 计划文档管理 ：计划文档应包含：各类项目计划文本；计 划执行检查情况记录及统计；计划变更、 调整记录等。 二、信息系统项目的成本估算 1 信息系统项目成本构成 信息系统项目的成本随着系统的类型、范围及功能的不同而有 较大差异。但是，可以从信息系统生命周期的各阶段划分为开 发成本和运行维护成本两大类： 信息系统成本 开发成本 运行维护成本 分析、设计费用 系统实施费用 管理费用 系统规划 系统分析 系统设计 系统开发成本 编程与调试 硬件平台费用 系统软件费用 网络施工费用 数据整理录入 系统运行费用 行政管理费用 维护费用 人员费用 消耗材料费用 固定资产折旧 硬件维护费用 软件维护费用 二次开发费用 技术资料获取 人员培训费用 系统平台成本 其它费用 信息系统项目的成本估算通常注意以下三个原则： 真实性与预见性原则 透明性与适应性原则 信息经济学教程 (陈禹主编。清华出版社） 方便性与稳定性原则 信息系统项目成本估算时，最难确定的是 软件开发成本 ，所以 成本估算的重点是软件开发成本。 2 软件开发规模与成本估算的方法 常用的四种估算方法 ： (1) 类比估算法 ：参照已完成类似项目，估算软件开发成本和工 作量。 (2) 分解估算法 ：将项目分解成若干子系统，先估算每个子系统 成本和工作量，再估算整个软件开发成本。 (3) 周期估算法 ：将系统按系统生命周期分解为若干阶段并估算 ，然后汇总出总工作量和成本。 (4) 经验估算法 ：根据实验或历史数据给出软件开发工作量或成 本的经验估算公式。 注意： 采用分解法估算时应考虑系统集成时需要的工作量。 信息系统开发成本测算的一般过程 ： 以往项目数据 待开发软件特征 硬件与系统软件特征 以往项目数据 对以往项目 数据的分析 软件开发 规模测算 硬件和系统 软件计划 培训和系统 切换计划 软件开发 成本测算 人力和时间 的分配 灵敏度与 风险分析 经验数据 环境因素 安装测试的 人力和时间 培训切换的 人力和时间 人力、时间测算数据 人力、进度及其他资源分配结果 3 软件规模度量方法 (1) 软件代码行的方式 用代码行 (LOC)数表示软件开发规模十分 自然、直观 。用代码 行数不仅能度量 软件的规模 ，而且可以度量软件 开发的生产 率 、每行代码的 平均成本 、千行代码 出错率 等。 软件开发的生产率： Pl L E 其中： L 软件总代码行数。 E 软件的总工作量，用人月 (PM)度量。 Pl 开发生产率，每人月完成代码行数 (LOC PM)。 每行代码的平均成本： Cl S L 其中： S 开发的总成本，用人民币元或美元度量。 Cl 每行代码平均成本，人民币元 (或美元 )代码行。 用软件代码行估算软件的开发规模直观、简单易行。 其 缺点 为： 代码行数估算依赖于开发工具的功能和表达能力； 项目开发初期估算它的代码行数十分困难； 用代码行估算方法会对需要设计精巧的项目产生不 利影响； 代码行估算不适宜非过程式的程序设计； (2) 软件功能点的方式 功能点度量是涉及多种因素的间接度量方式。该方法用 6个信息 量 的 “加权和 ”CT和 14个 复杂性调节值 Fi(i=1 14)。在系统分析 初期就能估算出软件开发的规模。 计算功能点 FP参数公式： FP CT0.65 0.0l 其中： CT 为信息量，按表 1计算， Fi 为影响因子，由表 2给出， Fi取值为 :0至 5，当 Fi 0 时 ,表示否定或不起作用， Fi 5时，表示肯定或 Fi 影响最大。 为复杂度，它是 Fi (i=1 14) 的类加和。 CT的度量（表 1）： Fi定值表 （表 2） 用功能点也可以定义软件的开发效率、成本等度量： 软件开发的生产率： Pf FP E 其中； Pf 表示每人月完成的功能点数。 每功能点的平均开发成本： Cf S fp 其中： Cf 为每功能点的平均成本； S为开发总成本； 采用功能点度量的 优点 ： （ 1） 与程序设计工具无关，适用于各种语言环境 ，这对于面向对象的开 发方式尤为有用； （ 2）由于项目启动时就能基本上确定系统的输入、输出等参数，所以功 能点度量能用于软件开发成本在初期预估。 采用功能点度量的 缺点 ： （ 1）该方法涉及到的主观因素比较多，如 Fi的选取与评估人的经验和 态度有较大的关系。 （ 2）计算公式中的 FP值的物理意义不直观，不易理解。 4 软件的经验估算模型 应用软件的估算模型是根据以前完成项目的实际情况导出的， 这些模型的结果仅有一定的参考价值。下面将介绍两个常用的 估算模型： CoCoMo模型和 Putnam模型。 (1)CoCoMo模型 CoCoMo模型是 “构造性成本模型 ”(Constructive cost model， 简称 CoCoMo模型 )的英文缩写，分为基本、中间、详细三个层次 ，分别用于软件开发的不同阶段。 基本 CoCoMo模型： 用于系统开发初期，估算整个系统的工作量 包括软件维护，和软件开发所需要的时间； 中间 CoCoMo模型： 用于估算各个子系统的工作量和开发时间； 详细 CoCoMo模型： 用于估算独立的软部件，如子系统内部的各 个模块。 本课程，我们只介绍基本 CoCoMo的情况，关于中间和详细 CoCoMo模型可以阅读Boehm B W的著作 Software Engineering Economics (Prentice-Hall ， 1981)。 基本 CoCoMo模型是静态、单变量模型，具有下列形式 E aLb D cEd C E 其中： L是项目的代码行估计值，单位是千行代码 ( KLOC ) 。 E 表示工作量，单位是人月 (PM)。 D 表示开发时间，单位为月。 C 表示开发成本，单位是万元。 表示每人月的人力成本，单位是万元人月。 a,b,c,d是常数。 不同软件类型 a,b,c,d 取值如下表所示 : 软件类型 a b c d 适用范围 组织型 2.4 1.05 2.5 0.38 各类应用程序 半独立型 3.0 1.12 2.5 0.35 各类实用程序、编译程序等 嵌入型 3.6 1.20 2.5 0.32 实时处理、控制程序、操作系统 (2) Putnam模型 Putnam模型是为大型软件项目 (一般 30人年以上 )进行估算的 模型。它是 动态多变量的模型 ，适用于软件开发各个阶段。估 算模型以项目实测数据为基础，描述开发工作量、开发时间和 软件代码行数之间的关系。相应的方程为： L Ck E1/3 td4/3 其中： L 表示源程序代码行数。 E 表示工作量 (以人年计，包括维护 )。 td 表示开发时间 (以年计 )。 Ck 表示技术状态常数，它反映 “妨碍程序员进展的限制 ”。 相应的方程为： L Ck E1/3 td4/3 技术状态常数 Ck的取值： Ck的典型值 开发环境 开发环境举例 2000 差 没有系统的开发方法，缺乏初期文档和复审，批处理方式 8000 好 有合适开发方法，有充分的文档和复审，交互执行方式 11000 优 有自动开发工具和技术 由上面方程可得到如下公式： E L3（ Ck3 td4 ） C E 其中， C 表示项目开发总成本； 表示每人年的人力成本。 (3) 软件的自动估算工具 以上介绍的经验估算模型已用软件，成为自动估算工具。项目管理可 能够使用这些工具自动估算项目的成本和工作量，还可对人员配置和 交付日期等进行估计。通常需要管理者提供以下数据： (1)定量估算软件项目规模 ，如：总代码行数或功能点数据； (2)定性地说明项目特性 ，如复杂性、可靠性或事件的关键性等； (3)开发人员和 (或 )开发环境的描述 。 根据这些数据，自动估算工具即可提供： 项目所需的工作量 、 成本 、 人 员配备 、 开发进度 和 相应风险等数据 。 目前几种具有代表性的自动估算工具： 工具名称 产品制作公司 工具基于原理 BYL Gordon 集团 基于 CoCoMo模型 WICOMO Wang 研究所 基于 CoCoMo模型 DECPlan DEC公司 基于 CoCoMo模型 SLIM - 基于 Putnam模型 SPQR/20 - 基于功能点模型 ESTIMACS - 基于功能点模型 三、信息系统项目的进度管理 1 建立项目成员责任矩阵 根据以上对项目工作量、成本的估算， 项目经理应组织项目团队， 并绘制 专业领域技术编制表 ，建立 工作分析结构 (WBS) ，在此基础 上建立 项目成员责任矩阵 ，落实任务。 （ 1）专业领域技术编制表 每个项目都需要多种技术与工作任务相匹配，分析、掌握项目组 成员技术特长，对项目管理者十分重要。 专业领域技术编制表的 X轴上为技术及专业领域， Y轴上为项目成 员，两 轴对应格为分数（ 最高分取专业领域个数 ）。例如： 人员 领域 系统分析 程序设计 系统测试 数据库技术 硬件技术 X X X 5 4 3 1 2 X X X 5 5 4 2 3 X X X 2 3 4 3 5 X X X 2 5 5 4 4 X X X 1 4 5 5 3 （ 2）工作分析结构 (WBS) 工作分析结构是指将一个信息系统项目分解成易于管理的几部分或几 个细目，细目再展开成子细目，任何分支最低层的细目叫 工作包 。待 建系统可以先按生命周期的阶段展开，然后按照子系统或系统功能点 展开。也可以直接按各子系统展开，但这时必须要考虑 总体设计的工 作任务 。 （ 3）项目组成员的责任矩阵 责任矩阵是将项目分解后工作包，依据项目成员的技术特长进行落实 ，其中 X轴为项目成员， Y轴为工作包，对应格中填写责任类 ： 任务 成员 X X X X X X X X X X X X X X X X X X X X X 系统分析 P S S S 数据库设计 S P S S 编程实现 S S P S S 系统平台建设 S P S 系统测试 S P S S P：主要工作 S：辅助工作 2 项目建设活动工期估计和预算分摊估计 项目建设工期估计和预算分摊估计可按下列步骤进行： 将待开发系统按阶段分割为若干基本活动如 系统规划、系 统分析、系统设计、系统实施、系统测试、系统切换等 ， 基本活动可再次分割为若干子活动，如： 系统规划 可 分割为 调研收集、数据可行性研究、系统规划报告 三项 子活动。 分别估算各子活动的工期及费用预算（构造项目建设工期 估计和预算分摊估计表）。 构造 项目开发活动网络图通过该网络图计算得到项目的最 早完成时间。 下例中假设该项目： 总成本为 100万元，工期为 50周： 活动 小活动 紧前活动 工期估计 (周 ) 预算分摊 (万元 ) 预算累计 (万元 ) 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、 I/O数据分析 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 83.5 15、系统实施报告 12， 13， 14 2 1.5 85 16、软件测试 15 6 6 91 17、硬件测试 15 4 1.5 92.5 18、网络测试 15 4 1.5 94 19、系统测试报告 16， 17， 18 1 1 95 20、人员培训 19 4 2 97 21、系统切换 19 2 2 99 22、系统切换报告 20， 21 1 1 100 系统 规划 系统 分析 系统 设计 系统 实施 系统 测试 系统 切换 项目工期估计和预算分摊估计表 (总成本 100万元 ) 经验表明 ，让某项工作的具体负责人 进行工期估算是较好的方法，因为这样做 既可以 得到该负责人的承诺 对他产生有效 的 参与激励 ，又可以 减少由项目经理个人 进行所有活动的工期估算所产生的偏差。 3 项目开发活动网络图 0 调研收集 数据 -8 1 3 3 -5 0 可行性调 研 -9 2 4 4 -5 4 系统规划 报告 -5 3 1 5 -4 5 与业务人 员沟通 -4 4 5 10 1 5 研究现有 系统 -2 5 8 13 6 15 系统分析报告 6 7 1 16 7 10 明确用户 需求 1 6 5 15 6 16 I/O 数据分析 9 8 8 24 17 16 数据库 分析 7 9 10 26 17 26 审核数据 字典 17 10 2 28 19 28 系统设计 报告 19 11 2 30 21 30 软件开发 21 12 15 45 36 30 硬件采购 与安装 26 13 10 40 36 30 网络实施 30 14 6 36 36 45 系统实施 报告 36 15 2 47 38 47 软件测试 38 16 6 53 44 47 硬件平台 测试 40 17 4 51 44 47 网络平台 测试 40 18 4 51 44 54 人员培训 45 20 4 58 49 53 系统测试 报告 44 19 1 54 45 54 系统切换 47 21 2 56 49 58 系统切换 报告 49 22 1 59 50 0 调研收集 数据 -8 1 3 3 -5 活动 描述 最早 结束 时间 最迟 开始 时间 活动 序号 工期 估计 最迟 结束 时间 活动负责人 最早 开始 时间 最早开始时间 (ES)： 取直接指向这项活动的所有活动的 最早结束时间 EF的最大值。 最早结束时间 (EF)： EF ES+工期估计 最迟开始时间 (LS) ： LS LF一工期估计 最迟开始时间 (LS) ： 取该活动直接指向的所有活动最迟开 始时间 LS的最早时间。 说 明： 上一页 4 项目的 工期规划 根据上工期估计和预算分摊估计 ，项目经理必须将项目活动及各活动分解后 的工作包进行工期规划，常用的方法有项目进度 甘特图 和 工作包进度表 。 项目进度甘特图 项目进度甘特图是帮助项目经理对项目进度进行总体规划的工具。如上面所 介绍的项目总开发时间为 50周。该项目可划分为六个大的活动，与其对应的 甘特图如下： 活 动 负责人 0 5 10 15 20 25 30 35 40 45 50 系统规划 XXX 系统分析 XXX 系统设计 XXX 系统实施 XXX 系统测试 XXX 系统切换 XXX 工作包进度表 项目进度表用于描述项目工作包的工期安排，为了确定这些工作包能在要求的 时间内完成。我们必须计算出每个项目进度计划（ 时间表 ），这个时间表主要解 决以下两个内容： 最早开始时间和最早结束时间 、 最迟开始时间和最迟结束时间 。 小活动 工期估计 （周） 最 早 最 晚 总时差 开始时间 结束时间 开始时间 结束时间 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、 I/O数据分析 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 或 总时差 LSES 当某项活动的总时差为正值，表明该项活动花费时间总量可以 适当延长。 当总时差为负值，则表明该项活动要加速完成以减少花 费的时间 。 要对项目的进度做到较好的控制，必须找到项目网络图中的 关 键路径 。一个项目的网络图从开始到完成可以有很多条路径。一些 路径可以有正的总时差，另一些可能有负的总时差。而那些总时差 为零或负值的路径被称为关键路径，并且将耗时最长的关键路径经 常称为 最关键路径 。 上例中项目网络图中的最关键路径为： 23 4 6 7 9 10 11 12 15 16 19 20 22 （其中数字为活动编号） 通过最关键路径可以看出开发该项目需要 59周，而不是前面项 目进度估算的 50周，这时，项目经理需要进一步核实，看是否 能够压缩相应工期和预算分摊，然后对进度和成本计划进行相 应凋整。 5 项目计划执行过程的控制与管理 （ 1） 项目计划执行过程控制流程 执行过程中，经常会出现一些预先无法想到的情况，而使项目的进度早干 或晚于计划进度或使项目的实际成本低于或高于计划成本，这时需要对项 目计划作出相应的调整，并对近期内即将发生的活动加强控制，以便积极 挽回时间和成本。项目控制或调整的过程如下： 制定计划 （进度、预算） 启动项目 采取纠正措 施吗？开始一个报告期 收集实际项 目进度情况 将变化列入计划 （进度、预算） 计算更新的项目 （进度、预算） 分析当前状况与计划差 异（进度、预算） 还有报告 期吗？ 项目结束确定纠正措施协调相关变化 项目计划执行过程控制流程 （ 2） 项目计划调整中应注意的问题 对近期内即将发生的活动加强控制，积极挽回时间和成本； 对工期估计较长或预算估计较大的活动应进一步进行审核预估依 据， 并做好该活动压缩时间和费用的准备工作，因为估计值越大 的项目更有压缩的可能； 将某些可以再细分的活动可进一步细分，研究细分活动之间并行 工作或技术重用的可行性，如可行，则可以有效地压缩时间和费 用。 （ 3） 信息系统项目计划调整的方法 时间一成本平衡法 时间与成本之间在一定的范围内具有一定的替代性。时间一成本 平衡法是一 种 用最低的相关成本的增加来缩短项目工期的方法 。 该方法基于以下假设： 每项活动有两组工期和成本估计： 正常的和应急的 。 应急时间 是指完成某项活动的最短估计时间； 应急成本 是指在应急时间内完成某项活动的预汁成本。 活动 A 正常： 7周， 50000元 应急： 5周， 62000元 活动 B 正常： 9周， 80000 元 应急： 6周， 110000元 活动 C 正常： 10周， 40000元 应急： 9周， 45000元 活动 D 正常： 8周， 30000元 应急： 6周， 42000元 开始 结束 一项活动的工期可以通过从正常时间减至应急时间得到有 效的缩减，这要投入更多的资源，如：指派更多的人、延 长工时、增加更多的设备或外包等。 应急时间是确保活动按质量完成的时间下限。无论对一项 活动投入多少额外的资源，也不可能在比应急时间短的时 间内完成这项活动。 当需要将活动的预计工期从正常时间缩短至应急时间时，必须有足够的 资源作保证。 在活动的正常点和应急点之间，时间和成本的关系是线性的。为了将活 动的工期从正常时间缩短至应急时间，每项活动都有自己的单位时间 加 急成本 。加急成本可用如下公式计算： 当使用 时间一成本平衡法对计划进行调整时应 注意以下几点： 重点调整关键路径上的活动，而调整的极限工期为关键路径上所有 活动的工期都被压缩为应急工期的累加和。 随着关键活动工期的调整变化，关键路径也在随之改变。 由于每项活动的单位时间加急成本是不同的，因此从降低成本考虑 ， 应尽量压缩加急成本较低的活动。 单位时间加急成本 成本指标监控法 在项目执行的过程中，总会有因各种因素引起项目成本的变动，为了 对计划成本进行有效控制，经常需要选取一些量化指标进行考察，下 面介绍利用项目的 预算累计量、实际成本累计量和盈余累计量 三个指 标监控成本变动的方法。 假没现有一个小型信息系统项目 个人理财信息系统 需要开发，合同总价 款为 10万元人民币 ，拟在 12周内开发成功 。项目采用原型法方式开发，为了 简单起见，项目 分为三个大的活动：需求分析与原型制作；原型改造与系统 实现；系统测试与转换。 预算累计量 (Cumulative Budged Cost， CBC) 个人理 财 信息系 统项 目三个活 动预 算分 摊 分 别为 ： 需求分析与原型制作 2.4 万元 原型改造与系统实现 6.0 万元 系统测试与转换 1.6 万元 周 分活动 1 2 3 4 5 6