IT项目时间管理.ppt

  1. 1、本文档共128页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
IT项目时间管理.ppt

第4章 IT项目时间管理 单代号网络图的特点 1) 工作之间的逻辑关系容易表达,且不用虚箭线,故绘图较简单; 2) 网络图便于检查和修改; 3) 由于工作持续时间表示在节点之中,没有长度,故不够形象直观; 4) 表示工作之间逻辑关系的箭线可能产生较多的纵横交叉现象。 绘图规则 1)单代号网络图必须正确表述已定的逻辑关系。 2) 单代号网络图中,严禁出现循环回路。 3) 单代号网络图中,严禁出现双向箭头或无箭头的连线。 4) 单代号网络图中,严禁出现没有箭尾节点的箭线和没有箭头节点的箭线。 5) 绘制网络图时,箭线不宜交叉。当交叉不可避免时,可采用过桥法和指向法绘制。 6) 单代号网络图只应有一个起点节点和一个终点节点。当网络图中有多项起点节点或多项终点节点时,应在网络图的两端分别设置一项虚工作,作为该网络图的起点节点和终点节点。 网络计划技术 用网络图来表达项目中各项活动的进度和它们之间的相互关系,并在此基础上,进行网络分析,计算网络中各项时间参数,确定关键活动与关键路线,利用时差不断地调整与优化网络,以求得最短周期。 单一时间估计法:估计一个最可能工作实现时间,对应于CPM网络 三个时间估计法:估计工作执行的三个时间,乐观时间a、悲观时间b、正常时间m,对应于PERT网络 关键工作指的是网络计划中总时差最小的工作。当计划工期等于计算工期时,总时差为零的工作就是关键工作。 关键路径是自始至终全部由关键工作组成的线路或线路上总的工作持续时间最长的线路。 正推法:起点? 终点:所有活动的ES、EF 逆推法:终点?起点:所有活动的LS、LF 最早开始时间TES=所有前序活动的EF中的最晚时间 最早结束时间TEF =本活动ES+本活动的工时估算 最迟开始时间TLS =本活动LF-本活动的工时估算 最迟结束时间TLF=所有后序活动的LS中的最早时间 最早时间参数计算 最早开始时间=MAX{紧前工作的TEF} 例: TES(7)= MAX{12,16}=16 最早结束时间=TES+工作延续时间t 例: TEF(7)= 16+1=17 最迟时间参数计算 最迟结束时间TLF=MIN{紧后工作的TLS} 例:TLF(2)=MIN{10,7}=7 最迟开始时间TLS=LFS—工作延续时间t 例:TLS(2)=7-7=0 时差(机动时间)计算 自由时差: 自由时差是指在不影响其紧后工作最早开始时间的前提下,该工作所具有的机动时间; 自由时差等于它的紧后工作的最早开始时间减去该项工作的最早完成时间所得结果 自由时差=min{TES(紧后工作)} —TEF 例:FF(2)=10-10=0 FF(3)=16-12=4 当计划工期等于计算工期时,关键工作的总时差和自由时差等于零。 时差计算 例题:在某工程网络计划中,工作M的最早开始时间为第15天,其持续时间为7天。该工作有两项紧后工作,它们的最早开始时间分别为第27天和第30天,最迟开始时间分别为第28天和第33天,则工作M的时差和自由时差(??? )天。 ?? A。均为5??? B.分别为6和5?? C.均为6??? D.分别为11和6 1、工作M的最迟完成时间应等于其紧后工作最迟开始时间的最小值: 所以工作M的最迟完成时间等于MIN[28,33]=28 2、工作M的时差为工作M的最迟完成时间减工作M的最早完成时间等于28-(15+7)=6 3、工作M的自由时差为工作M的紧后工作最早开始时间减工作M的最早完成时间所得之差最小值:MIN[27-22;30-22]=5。 答案:B。 案例:过分乐观的估算 Microsoft Word for Windows 1.0开发。包含249,000行代码,投入660人月,前后历时5年,实际花费时间为预期时间的5倍 案例分析(续) 导致WinWord1.0开发延迟的几个主要因素: 项目初期制定的开发目标是不可实现的。 盖茨下达的指示是用最快的速度开发最好的字处理软件,争取在12月内完成。实现这两个目标中的任何一个都是困难的,同时达到则是不可能的。 过紧的进度计划降低了计划的精确度。 开发过程中频繁换人。5年中共换了4个组长,其中有2人因进度压力离职,1人是出于健康的原因而离职。 案例分析(续) 迫于进度压力,开发人员匆忙写出一些低质量的和不完整的代码,然后宣称已实现某些性能。这造成了WinWord不得不将用于提高软件稳定性的时间由预计的3个月增加到12个月。 由于该项目中,创新比速度更重要,因而试图缩短开发周期,反而使周期变长 案例总结 高层的决定不总是睿智的 启示:估算应该征求所有项目相关人员的意见 案例总结(续) 过大的压力带来意想不到的结果 案例总

文档评论(0)

cai + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档