信息系统项目管理

1、信息系统项目管理1第一节 概论一、 项目的定义与特点 1 项目的定义 项目是在一定的资源约束下完成的既定目标的一次性任务。 2 项目的特点 项目具有目的性 项目具有寿命周期 项目具有一定独特性 项目都有其固有客户 项目组织开放性 项目具有较强冲突性 项目具有一定风险性人员、资金、时间、技术、环境、等2二、 项目管理的定义与特点 1 项目管理的定义 项目管理是通过项目经理和项目组织机构运用系统理论和方法 对项目及其资源进行计划、组织、协调、控制，旨在实现项目 的特定目标的管理方法体系。 项目管理中的三要素 ：目标、成本、进度 目标、成本、进度三者在项目管理过程中是互相制约的进度成本目标最佳进度控

2、制点3 2 项目管理的基本特征： (1) 项目管理是一项复杂系统工程 项目需要多种学科知识来解决实际问题； 项目执行中的未知因素决定项目的不确定性； 项目的临时性给组织管理带来难度； 项目建设是在严格的约束条件下进行的； (2) 项目管理具有创造性，充满着权衡 创造带有探索性，有较高的失败率； 项目建设中对进度、费用与质量三者之间的权衡。 (3) 项目负责人在项目管理中起着非常重要的作用 项目管理的主要原理之一是项目经理负责制； 项目经理有权独立进行计划、资源分配、协凋和控制； 项目经理应有多学科知识、综合管理能力及现场处理能力； 项目经理应有迅速建立一支高效群体的能力。4 三、 信息系统项目

3、特点 (1)信息系统项目的目标不精确，任务的边界模糊，各种技术 指标更多地由项目组来定义。 (2)信息系统项目客户需求不断激发，导致项目的进度、费用 等计划不断更改。 (3)信息系统项目是智力密集、劳动密集型，受人力资源影响 最大，项目成员结构、责任心、能力和稳定性对信息系统 项目的质量以及是否成功有决定性的影响。 (4)信息系统项目的生命周期包括系统规划、系统分析、系统 设计、系统实施、系统运行和维护五个阶段，其各阶段间 的关系密切、相互制约。 (5)信息系统项目不是交钥匙工程，项目开发队伍通常要跟踪 到系统的使用生命周期结束，因此要求项目开发队伍在较 长时间保持稳定。5 一、信息系统项目计

4、划管理 1 项目计划用途： 项目计划是用来指导组织、实施、协调和控制信息系统建设的 重要文件。 项目计划可作为客户与建设团队间解决冲突的依据。 项目计划可使项目成员有明确的分工及工作目标。 项目计划有助于项目成员之间的交流沟通。 项目计划可作为对项目过程控制和工作考核的基准。 2 项目计划分类： 进度计划 质量保证计划 费用计划 风险管理计划 人力计划 3 项目计划编制原则： 全过程计划（总体计划）：应保持大体上稳定，并尽可能留有 一定余量和弹性， 阶段性计划或子系统计划：按近期精细、远期概略方法展开。第二节 项目计划、费用与进度管理6 4 项目计划管理： 通常信息系统项目计划的管理包含以下工

5、作： 项目计划编制 ：项目经理或子项目负责人完成。 计划执行控制 ：定期进行检查、督导，并制定项目进度周 报、月报等相关制度。 计划变更处理 ：尽可能保证进度、费用和系统目标不变为 基础，运用一定的方法和理论调整、处理 各种复杂情况。 计划文档管理 ：计划文档应包含：各类项目计划文本；计 划执行检查情况记录及统计；计划变更、 调整记录等。 7 二、信息系统项目的成本估算 1 信息系统项目成本构成 信息系统项目的成本随着系统的类型、范围及功能的不同而有 较大差异。但是，可以从信息系统生命周期的各阶段划分为开 发成本和运行维护成本两大类：信息系统成本开发成本运行维护成本分析、设计费用系统实施费用管

6、理费用 系统规划 系统分析 系统设计系统开发成本编程与调试硬件平台费用系统软件费用网络施工费用数据整理录入系统运行费用行政管理费用维护费用人员费用消耗材料费用固定资产折旧硬件维护费用软件维护费用二次开发费用技术资料获取人员培训费用系统平台成本其它费用8 信息系统项目的成本估算通常注意以下三个原则： 真实性与预见性原则 透明性与适应性原则 信息经济学教程(陈禹主编。清华出版社） 方便性与稳定性原则 信息系统项目成本估算时，最难确定的是软件开发成本，所以 成本估算的重点是软件开发成本。 2 软件开发规模与成本估算的方法 常用的四种估算方法： (1) 类比估算法：参照已完成类似项目，估算软件开发成本

7、和工 作量。 (2) 分解估算法：将项目分解成若干子系统，先估算每个子系统 成本和工作量，再估算整个软件开发成本。 (3) 周期估算法：将系统按系统生命周期分解为若干阶段并估算 ，然后汇总出总工作量和成本。 (4) 经验估算法：根据实验或历史数据给出软件开发工作量或成 本的经验估算公式。 注意：采用分解法估算时应考虑系统集成时需要的工作量。9信息系统开发成本测算的一般过程 ： 以往项目数据待开发软件特征硬件与系统软件特征以往项目数据对以往项目数据的分析软件开发规模测算硬件和系统软件计划培训和系统切换计划软件开发成本测算人力和时间的分配灵敏度与 风险分析经验数据环境因素安装测试的人力和时间培训切

8、换的人力和时间人力、时间测算数据人力、进度及其他资源分配结果10 3 软件规模度量方法 (1) 软件代码行的方式 用代码行(LOC)数表示软件开发规模十分自然、直观。用代码行数不仅能度量软件的规模，而且可以度量软件开发的生产率、每行代码的平均成本、千行代码出错率等。 软件开发的生产率： Pl LE 或 E L Pl 其中：L 软件总代码行数。 E 软件的总工作量，用人月(PM)度量。 Pl 开发生产率，每人月完成代码行数(LOCPM)。 每行代码的平均成本： Cl SL 其中：S 开发的总成本，用人民币元或美元度量。 Cl 每行代码平均成本，人民币元(或美元)代码行。 11 用软件代码行估算软

9、件的开发规模直观、简单易行。 其缺点为： 代码行数估算依赖于开发工具的功能和表达能力； 项目开发初期估算它的代码行数十分困难； 用代码行估算方法会对需要设计精巧的项目产生不 利影响； 代码行估算不适宜非过程式的程序设计；12 (2) 软件功能点的方式 功能点度量是涉及多种因素的间接度量方式。该方法用6个信息量的“加权和”CT和14个复杂性调节值Fi(i=114)。在系统分析初期就能估算出软件开发的规模。 计算功能点FP参数公式： FPCT0.65 0.0l 其中：CT 为信息量，按表1计算， Fi 为影响因子，由表2给出， Fi取值为:0至5，当Fi0 时,表示否定或不起作用， Fi5时，表示

10、肯定或Fi 影响最大。 为复杂度，它是 Fi (i=114) 的类加和。 =141iiF=141iiF13CT的度量（表1）：（）（）（）算法（）（）外部界面数（)（）文件数（）（）用户查询数（）（）用户输出数（）（）用户输入数加权结果权值值测量参数=CT3*7*7*4*5*4*14 Fi定值表 （表2）用功能点也可以定义软件的开发效率、成本等度量： 软件开发的生产率： Pf FPE 其中； Pf 表示每人月完成的功能点数， E 软件的总工作量，用人月(PM)度量。 的修改和使用吗？系统的设计有利于用户织的多次安装吗？系统的设计支持不同组吗？设计中包括转换和安装代码设计可重用吗？系统的内部处理

11、复杂吗件、查询复杂吗？系统的输入、输出、文件吗？系统需要联机更新主文复杂界面或操作吗？联机数据入口需要建造数据入口吗？系统需要联机（操作环境下运行？系统是否在一个实用的性能是临界状态吗？系统有分布处理功能吗系统需要数据通信吗？复原吗？系统需要可靠的备份和，取值问题序号1413121110987)654321543210F ilineon-15 每功能点的平均开发成本： Cf Sfp 其中： Cf 为每功能点的平均成本； S为开发总成本； 采用功能点度量的优点： （1）与程序设计工具无关，适用于各种语言环境，这对于面向对象的开 发方式尤为有用； （2）由于项目启动时就能基本上确定系统的输入、输出

12、等参数，所以功 能点度量能用于软件开发成本在初期预估。 采用功能点度量的缺点： （1）该方法涉及到的主观因素比较多，如 Fi的选取与评估人的经验和 态度有较大的关系。 （2）计算公式中的 FP值的物理意义不直观，不易理解。 16 4 软件的经验估算模型 应用软件的估算模型是根据以前完成项目的实际情况导出的，这些模型的结果仅有一定的参考价值。下面将介绍两个常用的估算模型：CoCoMo模型和Putnam模型。 (1)CoCoMo模型 CoCoMo模型是“构造性成本模型”(Constructive cost model，简称CoCoMo模型)的英文缩写，分为基本、中间、详细三个层次，分别用于软件开发

13、的不同阶段。 基本CoCoMo模型：用于系统开发初期，估算整个系统的工作量 包括软件维护，和软件开发所需要的时间； 中间CoCoMo模型：用于估算各个子系统的工作量和开发时间； 详细CoCoMo模型：用于估算独立的软部件，如子系统内部的各 个模块。 本课程，我们只介绍基本CoCoMo的情况，关于中间和详细CoCoMo模型可以阅读Boehm B W的著作 Software Engineering Economics (Prentice-Hall，1981)。 17 基本CoCoMo模型是静态、单变量模型，具有下列形式 E aLb D cEd C E 其中：L是项目的代码行估计值，单位是千行代码(

14、 KLOC ) 。 E 表示工作量，单位是人月(PM)。 D 表示开发时间，单位为月。 C 表示开发成本，单位是万元。 表示每人月的人力成本，单位是万元人月。 a,b,c,d是常数。不同软件类型a,b,c,d 取值如下表所示:软件类型abcd适用范围组织型2.41.052.50.38各类应用程序半独立型3.01.122.50.35各类实用程序、编译程序等嵌入型3.61.202.50.32实时处理、控制程序、操作系统18(2) Putnam模型 Putnam模型是为大型软件项目(一般30人年以上)进行估算的模型。它是动态多变量的模型，适用于软件开发各个阶段。估算模型以项目实测数据为基础，描述开发

15、工作量、开发时间和软件代码行数之间的关系。相应的方程为： L Ck E1/3 td4/3 E L3（ Ck3 td4 ）其中：L 表示源程序代码行数。 E 表示工作量(以人年计，包括维护)。 td 表示开发时间(以年计)。 Ck 表示技术状态常数，它反映“妨碍程序员进展的限制”。19相应的方程为： L Ck E1/3 td4/3技术状态常数Ck的取值： Ck的典型值开发环境 开发环境举例2000差 没有系统的开发方法，缺乏初期文档和复审，批处理方式8000好 有合适开发方法，有充分的文档和复审，交互执行方式11000优 有自动开发工具和技术由上面方程可得到如下公式： E L3（ Ck3 td4

16、 ） C E其中， C 表示项目开发总成本； 表示每人年的人力成本。20 (3) 软件的自动估算工具 以上介绍的经验估算模型已用软件，成为自动估算工具。项目管理可 能够使用这些工具自动估算项目的成本和工作量，还可对人员配置和 交付日期等进行估计。通常需要管理者提供以下数据： (1)定量估算软件项目规模，如：总代码行数或功能点数据； (2)定性地说明项目特性，如复杂性、可靠性或事件的关键性等； (3)开发人员和(或)开发环境的描述。 根据这些数据，自动估算工具即可提供：项目所需的工作量、成本、人 员配备、开发进度和相应风险等数据。 目前几种具有代表性的自动估算工具： 工具名称产品制作公司工具基于

17、原理BYLGordon 集团基于CoCoMo模型WICOMOWang 研究所基于CoCoMo模型DECPlanDEC公司基于CoCoMo模型SLIM-基于Putnam模型SPQR/20-基于功能点模型ESTIMACS-基于功能点模型21三、信息系统项目的进度管理 1 建立项目成员责任矩阵 根据以上对项目工作量、成本的估算，项目经理应组织项目团队，并绘制专业领域技术编制表，建立工作分析结构(WBS)，在此基础上建立项目成员责任矩阵，落实任务。 （1）专业领域技术编制表 每个项目都需要多种技术与工作任务相匹配，分析、掌握项目组成员技术特长，对项目管理者十分重要。 专业领域技术编制表的X轴上为技术及

18、专业领域，Y轴上为项目成员，两 轴对应格为分数（最高分取专业领域个数）。例如：人员 领域系统分析程序设计系统测试数据库技术硬件技术X X X54312X X X55423X X X23435X X X25544X X X1455322 （2）工作分析结构(WBS) 工作分析结构是指将一个信息系统项目分解成易于管理的几部分或几个细目，细目可再展开成子细目，任何分支最低层的细目叫工作包。待建系统可以先按生命周期的阶段展开，然后按照子系统或系统功能点展开。也可以直接按各子系统展开，但这时必须要考虑总体设计的工作任务。 22、系统切换报告21、系统切换20、人员培训19、系统测试报告18、网络测试17

19、、硬件测试16、软件测试15、系统实施报告14、网络实施13、硬件采购安装12、软件开发11、系统设计报告10、审核数据字典9、数据库分析8、I/O数据分析7、系统分析报告6、明确系统需求5、研究现有系统4、与业务人员沟通3、系统规划报告2、 可行性研究1、 调研、收集数据工作包细目系统规划系统分析系统设计系统实施系统测试系统切换23（3）项目组成员的责任矩阵 责任矩阵是将项目分解后工作包，依据项目成员的技术特长进行落实，其中X轴为项目成员，Y轴为工作包，对应格中填写责任类： 任务 成员X X XX X XX X XX X XX X XX X XX X X系统分析PSSS数据库设计SPSS编程

20、实现SSPSS系统平台建设SPS系统测试SPSSP：主要工作 S：辅助工作242 项目建设活动工期估计和预算分摊估计 项目建设工期估计和预算分摊估计可按下列步骤进行： 将待开发系统按阶段分割为若干基本活动如系统规划、系统分析、系统设计、系统实施、系统测试、系统切换等，基本活动可再次分割为若干子活动，如：系统规划可分割为调研收集、数据可行性研究、系统规划报告三项子活动。 分别估算各子活动的工期及费用预算（构造项目建设工期估计和预算分摊估计表）。 构造项目开发活动网络图通过该网络图计算得到项目的最早完成时间。 25估计工作时间的方法主要有： a. 专家判断：专家判断主要依赖于历史的经验和信息，其时

21、间估计的结果具有一定的不确定性和风险。 b. 类比估计：类比估计意以先前类似的实际项目工作时间推测估计当前项目各工作的实际时间。当项目的一些详细信息获得有限的情况下，这是一种最为常用的方法，类比估计可以说是专家判断的一种形式。c. 单一时间估计法：估计一个最可能工作实现时间。d. 三个时间估计法：估计工作执行的三个时间，乐观时间a、悲观时间b、正常时间c，期望时间t(a+4c+b)/6。 下例中假设该项目：总成本为100万元，工期为50周：26活动小活动紧前活动工期估计 (周)预算分摊 (万元)预算累计 (万元)1、 调研、收集数据31.51.52、 可行性研究423.53、系统规划报告1，2

22、10.544、与业务人员沟通35375、研究现有系统384116、明确系统需求452137、系统分析报告5，611148、I/O数据分析784189、数据库分析71042210、审核数据字典8，9212311、系统设计报告10222512、软件开发1115154013、硬件采购安装1110387814、网络实施1165.583.515、系统实施报告12，13，1421.58516、软件测试15669117、硬件测试1541.592.518、网络测试1541.59419、系统测试报告16，17，18119520、人员培训19429721、系统切换19229922、系统切换报告20，2111100

23、系统规划系统分析系统设计系统实施系统测试系统切换项目工期估计和预算分摊估计表 (总成本100万元)27 经验表明，让某项工作的具体负责人进行工期估算是较好的方法，因为这样做既可以得到该负责人的承诺对他产生有效的参与激励，又可以减少由项目经理个人进行所有活动的工期估算所产生的偏差。28 3 项目开发活动网络图-8031调研收集数据-53-9042可行性调研-54-5413系统规划报告-45-4554与业务人员沟通 110-2585研究现有系统 61361517系统分析报告 71611056明确用户需求 61591688I/O 数据分析1724716109数据库 分核数据

24、字典19281928211系统设计报告213021301512软件开发364526301013硬件采购与安装36403030614网络实施36363645215系统实施报告38473847616软件测试44534047417硬件平台测试44514047418网络平台测试44514554420人员培训49584453119系统测试报告45544754221系统切换49564958122系统切换报告5059290调研收集数据-8133 -5活动描述最早结束时间最迟开始时间活动序号工期估计最迟结束时间活动负责人最早开始时间 最早开始时间(ES)： 取直接指向这项活动的所有活动的 最早结束时间EF的最

25、大值。 最早结束时间(EF)： EFES+工期估计 最迟开始时间(LS) ： LSLF一工期估计 最迟结束时间(LF) ： 取该活动直接指向的所有活动最迟开 始时间LS的最早时间。 说 明：上一页30 4 项目的工期规划方法 根据上工期估计和预算分摊估计 ，项目经理必须将项目活动及各活动分解后的工作包进行工期规划，常用的方法有项目进度甘特图和工作包进度表。 项目进度甘特图 项目进度甘特图是帮助项目经理对项目进度进行总体规划的工具。如上面所介绍的项目总开发时间为50周。该项目可划分为六个大的活动，与其对应的甘特图如下：40 45XXX系统测试XXX系统切换XXX系统实施XXX系统设计XXX系统分

26、析XXX系统规划5030 35 20 2510 15 0 5负责人活 动工作包进度表 项目进度表用于描述项目工作包的工期安排，为了确定这些工作包能在要求的时间内完成。我们必须计算出每个项目进度计划（时间表），这个时间表主要解决以下两个内容：最早开始时间和最早结束时间、最迟开始时间和最迟结束时间。31工作包工期估计（周）最 早最 晚总时差开始时间结束时间开始时间结束时间 1、 调研、收集数据303-8-5-8 2、 可行性研究404-9-5-9 3、系统规划报告145-5-4-9 4、与业务人员沟通5510-41-9 5、研究现有系统8513-26-7 6、明确系统需求5101516-9 7、系

27、统分析报告1151667-9 8、I/O数据分析81624917-7 9、数据库分析101626717-9 10、审核数据字典226281719-9 11、系统设计报告228301921-9 12、软件开发1530452136-9 13、硬件采购安装1030402636-4 14、网络实施6303630360 15、系统实施报告245473638-9 16、软件测试647533844-9 17、硬件测试447514044-7 18、网络测试447514044-7 19、系统测试报告153544445-9 20、人员培训454584549-9 21、系统切换254564749-7 22、系统切换

28、报告158594950-9项目工作包进度表：32 关键路径和总时差 上表中最后一列的数据为各项目活动工期时间差 ，它是活动的最早结束时间（EF）和项目的要求完工时间（LF）之间的差距，这个差距叫做总时差，有时也叫浮动量。 总时差可以用下列公式计算： 总时差 LFEF 或 总时差 LSES 当某项活动的总时差为正值，表明该项活动花费时间总量可以适当延长。当总时差为负值，则表明该项活动要加速完成以减少花费的时间。 要对项目的进度做到较好的控制，必须找到项目网络图中的关键路径。一个项目的网络图从开始到完成可以有很多路径。一些路径可以有正的总时差，另一些可能有负的总时差。而那些总时差为零或负值的路径被

29、称为关键路径，并且将耗时最长的关键路径称为最关键路径。 33 上例中项目网络图中的最关键路径为： 23 4 6 7 9 10 11 12 15 16 19 20 22 （其中数字为活动编号） 通过最关键路径可以看出开发该项目需要59周，而不是前面项目进度估算的50周，这时，项目经理需要进一步核实，看是否能够压缩相应工期和预算分摊，然后对进度和成本计划进行相应凋整。-8031调研收集数据-53-9042可行性调研-54-5413系统规划报告-45-4554与业务人员沟通 110-2585研究现有系统 61361517系统分析报告 71611056明确用户需求 61591688I/O 数据分析17

30、24716109数据库 分核数据字典19281928211系统设计报告213021301512软件开发364526301013硬件采购与安装36403030614网络实施36363645215系统实施报告38473847616软件测试44534047417硬件平台测试44514047418网络平台测试44514554420人员培训49584453119系统测试报告45544754221系统切换49564958122系统切换报告505934工期完工概率估算方法设关键路径T的总工期（即路径T上各项目工作的时间和）为T（ T =t作业路径），标准差为T，则在工期 D内完工的

31、概率为： p(TD)=0(D-T)/T(标准正态分布函数）设某工程图的关键路径为D-F-G-I-J-K-L（其关键路径所需时间 T31610151301590天 ，合同工期D=100天，活动D至L的完工概率方差分别为1.33,2.66,2.66，1.66,0.166,4.66,0).利用正态分布表，获得。35 5 项目计划执行过程的控制与管理（1）项目计划执行过程控制流程 执行过程中，经常会出现一些预先无法想到的情况，而使项目的进度早干或晚于计划进度或使项目的实际成本低于或高于计划成本，这时需要对项目计划作出相应的调整，并对近期内即将发生的活动加强控制，以便积极挽回时间和成本。项目控制或调整的

32、过程如下：制定计划（进度、预算）启动项目采取纠正措施吗？开始一个报告期收集实际项目进度情况将变化列入计划（进度、预算）计算更新的项目（进度、预算）分析当前状况与计划差异（进度、预算）还有报告期吗？项目结束确定纠正措施协调相关变化项目计划执行过程控制流程36（2）项目计划调整中应注意的问题 对近期内即将发生的活动加强控制，积极挽回时间和成本； 对工期估计较长或预算估计较大的活动应作为审核的重点，因为估计值越大的工作包往往更有压缩的可能； 将某些可以再细分的活动可进一步细分，研究细分活动之间并行工作或技术重用的可行性，如可行，则可以有效地压缩时间和费用。（3）信息系统项目计划调整的方法 工期一成本

33、平衡法 工期与成本之间在一定的范围内具有一定的替代性。工期一成本平衡法是一 种用最低的相关成本的增加来缩短项目工期的方法。 37 该方法基于以下假设： 每项活动有两组工期和成本估计：正常的和应急的。 应急时间：是指完成某项活动的最短估计时间； 应急成本：是指在应急时间内完成某项活动的预汁成本。活动A正常：7周，50000元应急：5周，62000元活动B正常：9周，80000 元应急：6周，110000元活动C正常：10周，40000元应急： 9周，45000元活动D正常：8周，30000元应急：6周，42000元开始结束一项活动的工期可以通过从正常时间减至应急时间得到有效的缩减，这要投入更多的

34、资源，如：指派更多的人、延长工时、增加更多的设备或外包等。38 应急时间是确保活动按质量完成的时间下限。无论对一项活动投入多少额外的资源，也不可能在比应急时间短的时间内完成这项活动。 当需要将活动的预计工期从正常时间缩短至应急时间 时，必须有足够的资源作保证。 在活动的正常点和应急点之间，工期和成本的关系是线性的。为了将活动的工期从正常时间缩短至应急时间，每项活动都有自己的单位时间的加急成本。加急单位成本可用如下公式计算：加急单位成本39 上例中可计算出下列结果： 活动A=（62000-50000）/（7-5） =6000 （元） 活动B=（110000-80000）/（9-6）=10000（

35、元） 活动C=（45000-40000）/（10-9）=5000 （元） 活动D=（42000-30000）/（8-6） =6000 （元） 当使用工期一成本平衡法对计划进行调整时应注意以下几点： 重点调整关键路径上的活动，而调整的极限工期为关键路径上 所有活动的工期都被压缩为应急工期的累加和。 随着关键活动工期的调整变化，关键路径也在随之改变。 由于每项活动的单位时间加急成本是不同的，因此从降低成考 虑，应尽量压缩加急成本较低的活动。活动A正常：7周，50000元应急：5周，62000元活动B正常：9周，80000 元应急：6周，110000元活动C正常：10周，40000元应急： 9周，4

36、5000元活动D正常：8周，30000元应急：6周，42000元开始结束40用工期成本平衡法确定项目最短完成时间举例： 第一次调整：计算单位时间加急成本得CA=6000，CB=10000，CC=5000，CD=6000。为了将项目的工期从18周减至17周，针对关键路径C-D。可以看出CC=5000最小，因此将活动C的工期压缩1周。得出项目周期17周，总成本为205000。活动A正常：7周，50000元应急：5周，62000元活动B正常：9周，80000 元应急：6周，110000元活动C正常：10周，40000元应急： 9周，45000元活动D正常：8周，30000元应急：6周，42000元开

37、始结束活动A正常：7周，50000元应急：5周，62000元活动B正常：9周，80000 元应急：6周，110000元活动C调后： 9周，45000元应急： 9周，45000元活动D正常：8周，30000元应急：6周，42000元开始结束第一次压缩41 第二次调整，为进一步缩短工期，必须再次找出关键路径，两路径的工期分别是A-B为16周，C-D为17周，因此关键路径仍是C-D，它必须再次被减少。活动C已达到它的应急时间9周了。因此，仅有的选择是加速活动D的进程。将活动D的工期压缩1周，项目工期为16周，总成本为211000。活动A正常：7周，50000元应急：5周，62000元活动B正常：9周

38、，80000 元应急：6周，110000元活动C正常： 9周，45000元应急： 9周，45000元活动D正常：8周，30000元应急：6周，42000元开始结束活动A正常：7周，50000元应急：5周，62000元活动B正常：9周，80000 元应急：6周，110000元活动C调后： 9周，45000元应急： 9周，45000元活动D正常：7周，36000元应急：6周，42000元开始结束第二次压缩42第三次调整，再次将项目工期缩短1周，有两条关键路径。为了将项目总工期从16周减至15周，必须将每个路径都加速1周。路径A-B压缩活动A，路径C-D压缩活动D，项目周期15周，总成本223000

39、。活动A正常：7周，50000元应急：5周，62000元活动B正常：9周，80000 元应急：6周，110000元活动C正常： 9周，45000元应急： 9周，45000元活动D正常：7周，36000元应急：6周，42000元开始结束活动A正常：6周，56000元应急：5周，62000元活动B正常：9周，80000 元应急：6周，110000元活动C调后： 9周，45000元应急： 9周，45000元活动D正常：6周，42000元应急：6周，42000元开始结束第三次压缩43 经三次调整后，网络图有两条相同的关键路径。必须将两条路径同时加速1周。路径C-D，均已达到它们的应急时间。加速路径A-

40、B的进程会毫无意义。停止优化过程。第1次调整后：项目总工期减少l周，项目总成本将增加5000元；第2次调整后：项目工期减少2周，项目总成本将增加l1000元；第3次调整后：项目工期减少3周，项目总成本将增加23000元。未调整前第1次调整后第2次调整后第3次调整后C D，A-B44 6 成本指标监控法 在项目执行的过程中，总会有因各种因素引起项目成本的变动，为了对计划成本进行有效控制，经常需要选取一些量化指标进行考察，下面介绍利用项目的预算累计量、实际成本累计量和盈余累计量三个指标监控成本变动的方法。 假没现有一个小型信息系统项目个人理财信息系统需要开发，合同总价款为10万元人民币，拟在12周

41、内开发成功。项目采用原型法方式开发，为了简单起见，项目分为三个大的活动：需求分析与原型制作；原型改造与系统实现；系统测试与转换。 预算累计量(Cumulative Budged Cost，CBC) 个人理财信息系统项目三个活动预算分摊分别为： 需求分析与原型制作 2.4 万元 原型改造与系统实现 6.0 万元 系统测试与转换 1.6 万元周分活动123456789101112小计需求分析与原型制作0.40.40.80.82.4原型改造与系统实现0.80.81.21.2116系统测试与转换0.80.81.6每周预算小计0.40.40.80.80.80.81.21.2110.80.810项目开始预

42、算累计0.40.81.62.43.24.05.26.47.48.49.21045周分活动123456789101112小计需求分析与原型制作0.20.50.90.50.12.2原型改造与系统实现0.20.811.41.24.6系统测试与转换0每周预算小计0.20.50.90.70.911.41.26.8项目开始预算累计0.20.71.62.33.24.25.66.8 实际成本累计量(Cumulative Actual Cost，CAC) 将项目三个活动在每周发生的实际成本记录下来，现假设项目已进行到第八周。 盈余累计量(Cumulative Earncd Value，CEV) 盈余量，也可称绩

43、效量，是用来衡量实际工作价值的一个重要参数。 通常用每个报期收集到的活动完工比率来确定盈余量。假设每周为一个报告期，每项活动的完成情况用百分比表示：周分活动123456789101112小计需求分析与原型制作10258090100100原型改造与系统实现00051525405050系统测试与转换00000000046 比较主要按三种情况进行： (1)如果在某个报告期实际成本累计量(CAC)大于分摊预算累计量(CBC)，一般来讲预示着项目的成本计划没有得到好的执行，实际发生的成本超出预算。 (2)如果在某个报告期实际成本累计量(CAC)小于分摊预算累计量(CBC) ，也不能高兴得太早，因为虽然在

44、报告期没有超出预算，但有可能没有完成既定的工作量，这时要看盈余累计量(CEV)指标，如果这时CEV大于CAC，则表明成本与进度都得到了很好的控制，如果这时CEV小于CAC，则说明“劳无所值”，没有实现应该完成的工作量，进度产生了拖延。 (3)在第一种情况中，如果虽然实际成本累计量(CAC)大干分摊预算累计量(CBC)，若此时盈余累计量(CEV)也大于实际成本累计量(CAC)，那么可能问题不大，有可能是进度加快的结果，这时要按前面谈到的时间一成本平衡分析。47 1 人与信息系统建设 信息系统项目的特点使其受人力资源影响非常大，项目成员结构、能力和稳定性对项目的成功有决定性影响。 人在信息系统项目

45、中是成本，人力成本是信息系统项目成本构成最大部分，这就要求我们对人力资源从成本上去衡量； 人在信息系统项目中又是资本，作为资本，项目管理者就要尽量去发挥资本的价值。 2 信息系统项目的人力资源计划 信息系统项目的人力计划是基于项目的工作量和进度预估，工作量与项目总时间的比值就是理论上所需的人力数。下面介绍通常情况下人力资源计划的安排方法。第三节 信息系统项目的人员管理48 (1)人力资源计划的安排的理论基础 人员进度权衡定律 Putnam模型的公式：EL3（ Ck3 td4 ），工作量(E)与交付时间(td) 的4次方成反比，其表明软件开发过程中人员与时间是一种非线性替代关系，Putnam将该

46、结论称为“软件开发权衡定律”。 Brooks定律 曾担任IBM公司操作系统项目经理的 FBrooks ，从大量的软件开发实践中得出了一条结论：“向一个已经拖延的项目追加开发人员，可能使它完成得更晚” 后来，许多文献称这一发现为Brooks定律。Brooks从另一个角度说明了“时间与人员不能线性互换”这一原则。 49 RayleighNorden曲线 Rayleigh曲线本来是用来解释某些科学现象的。1985年， Norden 发现这一曲线可用来说明科研及开发项目在实施期间所需要的人力。1986年，Putnam又把这一曲线与软件开发联系起来，发现在软件生存期内各个阶段需要的人力成本，具有与Ray

47、leigh曲线十分相似的形状。 平均人力人力时间 浪费人力 不足人力 过剩人力50 结论： 信息系统项目建设中人员与进度是一种非线性替代关系。 系统项目的人力分配基本符合Rayleigh Norden 曲线的分布，呈现出前、后用人少、中间用人多的不稳定人员需求情况。 信息系统开发在制定人力资源计划时，既要基本符合Rayleigh Norden 曲线的人力分布原则，又要尽量使某个阶段的人力稳定。并且确保整个项目开发期内人员的波动不要太大。我们称这样的过程为人力资源计划的平街。 51 (2) 人力资源计划平衡法 人力资源平衡法是：制定使人力资源需求波动最小化的进度计划的一种方法，这种平衡人力资源的

48、方法是为尽可能均衡地利用人力资源。 举例具体说明： 原型设计开发（7周）信息技术人员（4人）网络设计实施（4周）信息技术人员（2人）设备采购安装（3周）信息技术人员（1人）系统测试切换（4周）信息技术人员（2人）文档编制 （2周）信息技术人员（1人）项目开始项目结束人员培训 （2周）信息技术人员（2人）52活动人周原型设计开发16网络设计实施5设备采购安装3系统测试切换6文档编制2人员培训1第几周12345678910111213总计每周人数444332222222133人周基于活动最早开始时间的人力计划图：1234人员数1312111098765432561753活动人周原型设计开发16网络

49、设计实施5设备采购安装3系统测试切换6文档编制2人员培训1第几周12345678910111213总计每周人数444332222222133人周1234人员数1312111098765432基于人力资源平衡法的人力计划图：561754 (3) 几点说明： 由于本例采用原型法开发，系统调研、原型制作和原型改造都在前期进行，用的人力较多，所以是直接从RayleighNorden曲线分布的中部开始的。 本例中通过推迟非关键路径上的活动使人力资源需求尽可能平衡，因而并末影响进度。 上例中是在资源没有约束的情况下讨论的，如果资源有约束，比如只有两个开发人员，这种有约束的情况仍可用上面的方法进行人力平衡，

50、进度可能就会有较大的变化。 人力资源计划是基于项目的网络图制定的，有时为了得到一个合理的人力计划需要多次考察、调整项目网络图。55 3 信息系统项目的团队组织与管理 信息系统的开发首先要做好人员的组织工作。开发过程所需要的人员有：用户、系统分析员、数据库管理员、系统设计员、硬件技术人员、网络设计员、程序设计员等。他们在系统开发过程中所处的地位和作用是不同的。如何组织好这些参加项目的人员，使其发挥最大的工作效率，对项目成功至关重要。（1）项目团队的建立 项目团队采用什么组织形式。要根据信息系统项目的特点来决定，同时也与参与人员的素质有关。在建立项目小组时应注意以下几项原则： 尽早落实责任，明确每

51、个成员之间的责任； 知人善任，将每个人的专长尽可能地发挥出来； 项目团队通常又可分为若干项目小组，比如一个大的项目开发 团队可以分为总体组、软件开发组、硬件网络组、测试组等若干个项目小组，项目小组是项目团队的基层单位。56 每个项目小组的规模应该尽量小，以28名成员为宜，在开发过程中，人与人之间的联系被称为通信路径。经验表明，信息系统的生产率与通信路径数目有关。 如果项目属于中小型规模且建设时间在一年以内，项目小组的成员可以是活动负责人制。活动负责人既负责该活动的日常管理工作，同时又是该活动的技术负责人。 如果项目属于大中型规模，建设时间在一年以上，那么就必须考虑项目建设人员因各种原因发生变动

52、的情况。这时项目小组推荐的组织结构为：一个高级系统开发人员带两个中级系统开发人员，每个中级开发人员再带2个初级开发人员。高级系统开发员（1名）中级系统开发员（1名）中级系统开发员（1名）初级系统开发员（1名）初级系统开发员（1名）初级系统开发员（1名）初级系统开发员（1名）57 采用按技术水平分层的组织结构模式，主要基于两点考虑： 信息系统的建设工作中既有创造性很强的事务，也有经验性很 强的事务和重复简单事务，如果所有活动都让高级人员去完成，是人力资源的极大浪费，还会引起高级人员的不满，而上述三类活动刚好适合三类人员去完成。 由于项目建设时间太长，容易发生人员变更，中级和初级开发人员在系统建设

53、的过程中会成长起来，如果一旦发生上一层次人员的变动，下层人员基本上可以“无缝”地把工作承接起来。 这里上下层的开发人员之间的比例定为2，这个比例也可以随不同项目小组的情况具体调整，比如为l或3，但最好不要超过3个。58（2）项目团队的组织结构的三种模式 按子课题或子系统划分模式 把项目成员按子课题或子系统组成小组，小组成员自始至终参加所承担子系统的各项任务。如：子系统的规划、需求分析、设计、实现、测试以及包括维护在内的全过程。这种模式不利于发挥每个人的特长，但由于通信接口较少，也具有一定优势。 按职能划分的模式 把参加项目开发的所有人员按任务的阶段划分成若干个专业组。待开发系统在每个专业组完成

54、阶段加工，达到每个阶段相应的里程碑后，沿开发工序流水线向下传递，如：分别建立规划组、需求分析组、设计组、系统实施组、系统测试组、网络组、维护组等。各种文档资料按工序在各组之间传递。这种模式在小组之间的联系形成接口较多，但便于组内成员互相交流，进而变成这方面的专家，从而提高效率。 矩阵形模式 这模式是以上两种模式的复合。一方面，按职能成立一些专业组，如规划组、设计组、实现组、业务组、测试组等；另一方面，又将整个项目分为一些子系统课题组，指派专门的负责人。这样，每个成员既属于某一个职能小组，又参加某一子课题组的工作。矩阵形结构组织的优点是：便于小组之间互相交流及经验互补。而且各个项目有专人负责，有

55、利于项目的完成。59（3）明确项目组各成员的职责 为了让项目组成员各负其责，在项目开始时恰当地把人选、技术与工 作任务搭配好是很重要的。我们可用前面介绍的专业领域技术编制表 和项目组成员责任矩阵的方法为每一位项目成员确定其工作范围和责 任。人员 领域系统分析程序设计系统测试数据库技术硬件技术X X X54312X X X55423X X X23435X X X25544X X X14553任务 成员X X XX X XX X XX X XX X XX X XX X X系统分析PSSS数据库设计SPSS编程实现SSPSS系统平台建设SPS系统测试SPSS在确定项目组成员职责时应注意下列问题： 每

56、项活动只能安排一名成员负主要责任； 安排工作岗位应主要考察该成员的技术特长； 不要安排太多的人到同一活动中； 确定项目组成员职责时，可采用双向选择方式进行； 确定项目组成员职责时，应将未来人员波动因素考虑进去；60（4）项目团队成立以后的第一次全体会议 上述工作都准备好之后，必须召开一次项目团队成立会议，这是信息系统项目成立以后的第一次全体会议，其目的是： 项目组成员的集体亮相和初步交流。会议可以为项目成员之间的相互了解提供一个机会，为以后的合作打下一个基础。 加深对项目目标的理解。这是会议的主要目的，项目组各成员对信息系统建设的目标和意义的全面深入理解，对项目的成功是非常关键的。 统一思想认

57、识。对项目的组织结构、工作方式、管理方式及一些方针政策等取得一致的认识，以确保项目顺利实施。 明确岗位职责。明确每位成员的权利职责范围，明确项目中各个岗位的角色、主要任务、要求等，帮助项目成员更好地理解他们的工作任务。61（5）项目团队的成长与激励 信息系统项目团队的成长与其他项目一样，需要经过如下四个阶段： 形成(forming)阶段 人员特点：具有较高工作激情；对项目目标、任务缺乏了解；急于知道他 们能否与其他成员合得来，自己能否被接受，担心他们在项目中的角色是 否会与个人兴趣及专长相一致等。 对项目成员采取的激励方式主要为：预期激励、信息激励和参与激励。 形成震荡正规表现工作业绩团队精神

58、预期激励信息激励参与激励信息激励责任激励参与激励自我激励知识激励参与激励危机激励目标激励知识激励62 震荡(storming)阶段 人员特点： 成员工作情绪开始出现波动；现实与个人当初设想不一致；不适应任务繁重或困难大工作环境；成员间的个性冲突磨合等，土气的低落有时可能会抵制团队的形成，将项目的成功置于危险之中。 对项目成员采取的激励方式主要有参与激励、责任激励和信息激励。 正规(norming)阶段 人员特点： 项目团队就进入了发展的正规阶段；团队成员之间关系已确立；项目团队逐渐接受了现有的工作环境；项目规程也得以改进和规范化团队的 凝聚力开始形成。 在正规阶段，项目经理采取的激励方式除参与

59、激励外，还有两个重要方式： 发掘每个成员的自我创造性和责任意识，诱导员工进行自我激励； 尽可能地多创造团队成员之间互相沟通、互相学习的好环境，以及从项目外部聘请专家讲解与项目有关的新知识和新技术，给员工充分的知识激励。 63 表现(performing)阶段 人员特点：项目团队积极工作工作绩效很高；团队有集体感利荣誉感，信心十足；项目团队能开放、坦诚、及时地进行沟通，在自己的工作任务外尽力相互帮助；解决共性问题时有关的知识或技巧在团队内部可得到快速共享。这一阶段。项目经理应集中注意关于预算、进度计划、工作范围及计划方面的项目业绩。 因而，这一阶段激励的主要方式是危机激励、目标激励和知识激励。

60、激励的结果是使参与项目的所有成员组织成一个富有成效团队 。要强调的是，对于信息系统建设要更多地引导项目成员进行自我激励，要更多地进行知识激励。当然，足够的物质激励是不言而喻的有效的激励方式。 64第四节 信息系统建设的质量管理 目前人们对信息系统项目的要求，往往只强调系统的功能、进度、计划以及开发成本，却很少注意在整个生命周期中信息系统应具备的质量标准。缺乏质量管理开发的的系统后果是： 系统的可理解性差，造成后期维护费用非常高。 系统的安全得不到保证。 系统的灵活性差，不便于系统的修改或改进。 系统不能或难于移植到另外的环境中运行。 系统难于和其他系统配合使用或必须付出很高代价。1 信息系统建