设为首页 | 加入收藏夹

八文网 - 汇聚八方文档 - 做最优秀的免费文档下载网站

项目的时间管理

文档类型：

Microsoft PowerPoint PPT 演示文稿文档大小：1.82M

第四章项目的时间管理
第四章目录项目时间管理的基本概念4.1项目的任务分解结构4.2项目进度计划的编制4.3项目进度计划的变更管理4.4使用Project2002管理项目计划4.5
4.1 项目时间管理的基本概念§4.1 项目时间管理的基本概念
4.1.1 项目时间管理的基本问题
4.1.2 PMBOK的项目时间管理概念
项目时间管理的概念:项目计划是指导项目实施和控制的一系列纲领性文件,是经高层管理批准的项目正式文档.
项目进度计划制定是根据项目的目标,在项目确定的范围内、依据确定的需求和质量标准,并在项目成本预算许可下,制定出一个周密的项目活动安排的过程.
项目时间管理是在项目的执行和实施过程中、经常检查实际进度是否按计划要求进行、若出现偏差,便要及时找出原因,采取必要的补救措施或调整,修改原计划,直至项目完成的过程.
项目经理的时间管理进度延误是项目的最主要问题项目进度计划是项目最基本的控制工具时间是最主要的成本依据项目经理最主要的工作,就是制定项目计划,并根据项目计划,安排工作,监督实施,考察进度,识别项目进度方面存在的风险与偏差.对不适应计划进度要求的情况,及时进行调整.
项目计划是组织考核项目经理工作的主要依据.计划既是组织对项目组和项目经理实行目标管理和目标考核依据,也是过程控制的依据.显然,项目阶段里程碑的达到与否,是最简单,最直接的考核标准.
为什么要制定一份项目计划(1)通过制定计划,使得项目组和有关管理人员,对项目有关事项、如资源配备,风险化解,人员安排,时间进度,内外接口等形成共识,形成事先约定,避免事后争吵不清;
(2)通过计划,可以使得一些支持性工作以及并行工作及时得到安排,避免因计划不周造成各子流程之间的相互牵掣.比如测试工具的研发,人员的培训都是需要及早计划和安排的.
(3)可以使项目实施人员明确自己的职责,便于自我管理和自我激励;
(4)计划可以有效的支持管理,作为项目经理,业务经理,技术经理,QA经理,测试经理,配置经理们对开发工作跟踪和检查的依据;
(5)做好事先计划,就可以使注意力专心于解决问题,而不会去想下一步做什么(6)计划是项目总结的依据之一、项目总结其实就是把实际运行情况与项目计划不断比较以提炼经验教训的过程.通过计划和总结,项目过程中的经验和教训会获得很好的记录和升华,成为组织的财富.
谁来制定,何时制定项目计划在项目进入到合同签订,正式展开需求获取和分析阶段以后,项目的具体目标和要求将开始逐步了解清楚,在开始建立项目的详细计划(WBS)前、可以先建立项目的里程碑计划.里程碑计划一般由项目经理来制定.
里程碑计划是非常粗的WBS计划.在后续阶段,项目经理应细化里程碑计划,形成WBS计划.如果项目的规模较大(例如项目组成员超过50人)、那么项目经理将工作任务分解到合适的粒度并分发给相应的小组,再由小组制订自己的详细计划,项目经理汇总所有小组的详细计划,形成项目的整体WBS计划.
谁来批准项目计划项目计划由项目经理的上一级高层经理,大型的项目,甚至需要组织的一个审核委员会来批准.
一般地,项目的里程碑计划会作为软件项目合同的附件,因此,签订软件项目合同时,用户方也会审查项目的计划.
作为用户方、所关注的要点是项目的时间进度和交付成果,作为开发方会检查项目计划的合理性,可行性,更重要的是检查,并承诺项目所需要的资源是否能够保证获得满足.例如:采购到货日期,人力资源,开发设备和环境保障等.
项目计划的类型项目计划是项目管理工作的中心内容.根据不同的目的和不同的时间进展,可以有不同类型的计划.
具体分为:里程碑计划,实施计划,项目进展计划.每一种项目计划都是为完成一个项目管理工作而安排的具体内容.
项目计划的里程碑计划里程碑计划是确定项目的关键交付物或者项目交付产品的具体时间表.里程碑计划可以看作是一个项目在初级阶段制订的蓝图,是对项目完成时间以及项目产品交付时间的计划.里程碑计划直接就可以在日历上用一个星号或者一个三角加以表示.如下表:里程碑事件进度时间一月二月三月四月五月六月七月八月签署合同__△需求说明书定稿
△系统设计评审子系统测试系统集成测试用户确认测试有多种可使用的方法用以显示里程碑网络图中的项目信息,△计划完成目标__项目实施计划与项目进度计划一个成功的项目管理是在有组织的人员和团体的基础上展开的,涉及到制订要完成的目标和工作,以及为保证工作得以实施而提供领导支持和指导.项目的全局目标需要用更加简短的期间目标明确表明,并且通过精心策划的计划,进度和预算等来完成.然后实施控制以确保计划和进度按照预期付诸实施.
项目的实施计划表现为整个项目实施的所有步骤,包括项目管理的各个方面.涉及到要制订完成的目标及其相应的工作,以及怎样为保证工作的实施提供相应的领导支持和指导.其中包括进度计划和成本预算,成本管理计划与风险管理计划等.
项目进度计划就是根据项目实施具体的日程安排,规划整个工作进展.也把它称为项目初步计划,详细计划或者整体计划和子计划等等.
项目计划制定的原则(1)目的性(2)系统性(3)动态性(4)职能性(5)完整性(6)相对稳定性
4.1.2 PMBOK的时间管理在PMBOK体系中、与项目计划管理有关的部分,体现在PMBOK9个知识领域之一的时间管理知识领域中.
回顾一下:项目的范围管理PMBOK中、与软件工程的需求获取和分析过程有相似关系的管理,称为:范围阐述.依据范围阐述,产生工作分解结构.这个过程,称为范围管理.
PMBOK的时间管理在方法,技术等方面,比较完整和全面,是我们项目管理比较好的参考依据.
PMBOK的项目范围管理范围产生项目产品所包括的所有工作及产生这些产品所用的过程产品、过程产品范围界定-产品范围的特征和功能包含在产品或服务中.工作范围界定-项目工作的完成为的是能交付一个有特殊的特征和功能的产品.
范围管理对项目包括什么和不包括什么的定义与控制过程这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程,有一个共同的理解.
项目范围管理的主要过程启动阶段-督促项目管理组织开始着手项目下一阶段的工作.范围计划-写出一份书面报告,作为未来项目决策基础.范围界定-把主要的项目工作细目分解成更小,更易管理操作的单元.范围核实-正式认可这个项目范围.范围控制-对项目范围的变更进行控制._
项目启动:战略计划与项目选择启动阶段是正式认可一个新项目的存在,或者是对一个已经存的项目让其继续进行下一阶段工作的过程.
在一些组织中、一个项目计划的正式启动,是在必要的学习,初步的计划和其他相当于划分项目开始阶段的工作完成后才进行的.
有些项目形式,如特殊的内部服务项目和新产品开发项目,它们的启动不是很正规,要受到所做的工作数量的制约,目的是为项目正式启动时,职员能牢固地掌握这些工作方法.
批准项目立项报告(项目章程)
1. 立项报告:项目的立项报告是正式认可项目存在的一个文件.它对其他文件既有直接作用,也有参考作用.
立项报告应描述:・既定的商业目标.・产品描述说明.项目的立项报告应该通过管理者对项目及项目所需的条件进行客观的分析后颁发,它提供给项目经理运用,组织生产资源,进行生产活动的权力.
项目启动的结果
2. 指定委派的项目经理.通常、项目经理应该尽可能在项目的早期进行指定和委派是比较合适的.项目经理应该在项目计划实施开始之前被委派,更应该在许多项目规划完成之前就委派好.
3. 制约因素.制约因素是限制项目管理团队进行运作的要素.例如:事先确定预算是制约项目团队的操作范围,职员调配和进步计划的一个很重要的因素.
当一个项目按照合同执行时,合同条款通常是受合同制约的.
4. 假设因素.为了规划目标的准确性,考虑到的假设因素必须具有科学性,真实性和确定性.例如:如果关键人物的到场日期不能落实,那么项目团队就应该设置一个具体的开始时间.假设通常包含有一定程序的风险.在此它们可能被确认或它们可能是一个风险界定的输出.
范围计划编制和范围说明书范围计划编制是创立书面文件,阐述项目范围为未来项目提供基础条件的过程,特别是包括了用以确定项目或阶段是否成功完成的标准.
范围说明书的基础是通过确认项目目标和主要项目的子项目,使项目团队与项目客户之间达成一个协议.
如果范围界定的所有要素已经具备(如:主要项目的子项目能够反映项目目标,项目立项报告能证明项目目标),那么,这个过程就仅剩实质性的制定书面文件的工作了.
范围定义与工作分解结构范围界定范围界定包括分解这个主要工作细目的子项目(象在范围阐述中界定的那样),使它变成更小,更易管理,操作的东西.目的是为了:・提高估算成本,时间和资源的准确性.・为绩效测量和控制确定一个基准线.・使工作变得更易操作的,责任分工更加明确.正确的范围界定是项目成功的关键.当它是一个很差劲的范围界定时,由于不可避免的变化会使最终项目成本可能会很高,因为这些不可避免的变化会破坏项目节奏,导致重复工作,增加项目运行的时间,降低生产功效和工作人员的士气.
项目时间管理的主要过程项目时间管理由一些过程组成,这些过程是为按时完成项目所必须的:
1,活动定义-指确认一些特定的工作.通过完成这些活动就完成了工程项目的各项目细目.
2,活动排序-明确各活动间的相互联系性.
3,活动历时估计-估计各活动所需时间.
4,制定进度计划-分析活动间排序,活动所需时间和资源以做出项目进度计划.
5,进度计划控制-控制项目进度变化.
过程一:活动定义
编制项目计划的相关人员:项目经理职能部门技术人员项目管理专家参与项目工作的其他人员
第一步:项目描述
内容:用表格的形式列出项目目标,项目的范围,项目如何执行、项目完成计划等.
目的:对项目的总体要求作一个概要性的说明.
用途:项目描述是制作项目计划和绘制工作分解结构图的依据.
依据:项目的立项规划书,已经通过的初步设计方案和批准后的可行性报告.
制作者:项目管理办公室或项目主管人员项目描述表格的主要内容项目名称项目目标_交付物_交付物完成准则_工作描述_工作规范_所需资源估计_重大里程碑_项目主管审核意见
第二步:项目分解
目的:明确项目所包含的各项工作
内容:项目分解就是先把复杂的项目逐步分解成一层一层的要素(工作),直到具体明确为止.
工具:项目分解的工具是工作分解结构WBS原理,它是一个分级的树型结构,是一个对项目工作由粗到细的分解过程.
工作分解结构(WBS)
WBS(Work Breakdown Structure)主要是将一个项目分解成易于管理的几个部分或几个细目,以便确保找出完成项目工作范围所需的所有工作要素.它是一种在项目全范围内分解和定义各层次工作包的方法,WBS按照项目发展的规律,依据一定的原则和规定,进行系统化的,相互关联和协调的层次分解.结构层次越往下层则项目组成部分的定义越详细,WBS最后构成一份层次清晰,可以具体作为组织项目实施的工作依据.
WBS通常是一种面向成果的树,其最底层是细化后的可交付成果,该树组织确定了项目的整个范围.但WBS的形式并不限于树状,还有多种形式.
有关WBS在以后详细介绍
第三步:工作描述
目的:更明确的描述项目包含的各项工作的具体内容和要求
用途:作为编制项目计划的依据,同时便于实施过程中更清晰的领会各项工作的内容
依据:项目描述和项目工作分解结构
结果:工作描述表及项目工作列表工作(任务)描述表任务名:订购材料交付物签并发出定单验收标准部门经理字,技术条件本公司采工作程序描述根据
第号表格和规完成报批假设所需存在信息源供商广告等约束必须考虑的价其它风险可能;防范计划事先通知潜了解今后该货性项目组员A工作列表包含的内容工作代码用计算机管理工作时的唯一标识符,可看出工作之间的父子关系工作名称该工作的名称输出完成该工作后应输出的信息(包括产品、图纸、技术文件,工装及有关决策信息)以及对输出信息的规范和内容定义输入完成本工作所要求的前提条件(包括设计文档,技术文件,资料等)内容定义本工作要完成的具体内容和流程(包括应用文件,支撑环境、控制条件,工作流程)负责单位本工作的负责单位或部门协作单位完成本工作的协作单位和部门子工作WBS树型结构中与本工作直接相连的下属工作项目工作列表相关工作工作编码
第四步:工作责任分配表制定
目的:对项目的每一项任务分配责任者和落实责任.
用途:明确各单位或个人的责任,便于项目管理部门在项目实施过程中的管理协调.
依据:以工作分解结构图表和项目组织结构图表为依据制作此表.
结果:工作责任分配表责任分配表
图例:
▲负责●辅助△通知责任者(个人或组织)工作分解结构任务编码任务名称
项目负责人审核意见:_
签名: 日期:
( ▲负责0审批●参加□通知)责任者_WBS技术经理质量经理财务经理计划部财务部商务部采购部原厂商顾问技术委公司用户需求评审
●
▲设计
□集成测试采购审批工程实施项目计划简化的责任矩阵案例讨论针对生日宴会进行讨论确定相关负责人生日宴会工作责任分配表
过程二:活动排序
概念:任何工作的执行必须依赖于一定工作的完成,也就是说它的执行必须在某些工作完成之后才能执行、这就是工作的先后依赖关系.
分类:工作的先后依赖关系有两种:一种是工作之间本身存在的,无法改变的逻辑关系;另一种是人为组织确定的,两项工作可先可后的组织关系.
原则:生产生产A产品生产B产品逻辑关系组织关系工作相互关系确定的主要内容
①强制依赖关系的确定:这是工作相互关系确定的基础、工作逻辑关系的确定相对比较容易,由于它是工作之间所存在的内在关系,通常是不可调整的,主要依赖于技术方面的限制,因此确定起来较为明确,通常由技术和管理人员的交流就可完成.
②自由依赖关系的确定:对于无逻辑关系的那些工作,由于其工作先后关系具有随意性,从而将直接影响到项目计划的总体水平.自由依赖关系的确定一般比较难,它通常取决于项目管理人员的知识和经验、因此自由依赖关系的确定对于项目的成功实施是至关重要的.
③外部依赖关系的确定:在项目的工作和非项目工作之间通常会存在一定的影响、因此在项目工作计划的安排过程中也需要考虑到外部工作对项目工作的一些制约及影响、这样才能充分把握项目的发展.
工作关系表示的工具和方法
1,前导图法(PDM)中、有二种方法:单代号网络计划(AON)双代号网络计划(AOA)
2,箭线图法(ADM)
3,条件图法图形评审技术GERT风险评审技术VERT
4,网络模板工作相互关系确定的最终结果工作相互关系确定的最终结果是要得到一张描述项目各工作相互关系的项目网络图以及工作的详细关系列表.项目网络图通常是表示项目各工作的相互关系基本图形,通常可由计算机或手工绘制,它包括整个项目的详细工作流程.工作列表包括了项目各工作的详细说明,是项目工作的基本描述.
案例讨论生日宴会工作关系确定
过程三:活动历时估计
作用:工作延续时间的估计是项目计划制定的一项重要的基础工作,它直接关系到各事项、各工作网络时间的计算和完成整个项目任务所需要的总时间.若工作时间估计的太短、则会在工作中造成被动紧张的局面;相反、若工作时间估计的太长,就会使整个工程的完工期延长.
观念:网络中所有工作的进度安排都是由工作的延续时间来推算,因此,对延续时间的估计要做到客观正确的估计.这就要求在对工作作出时间估计时,不应受到工作重要性及工程完成期限的影响、要在考虑到各种资源,人力、物力、财力的情况下,把工作置于独立的正常状态下进行估计,要做统盘考虑,不可顾此失彼.
工作时间的估计主要依赖的数据基础
①工作详细列表
②项目约束和限制条件
③资源需求:大多数工作的时间将受到分配给该工作的资源情况以及该工作实际所需要的资源情况,比如说当人力资源减少一半时工作的延续时间一般来说将会增加一倍.
④资源能力:资源能力决定了可分配资源数量的大小,对多数工作来说其延续时间将受到分配给它们的人力及材料资源的明显影响、比如说一个全职的项目经理处理一件事情的时间将会明显的少于一个兼职的项目经理处理该事情的时间.
⑤历史信息:许多类似的历史项目工作资料对于项目工作时间的确定是很有帮助的,主要包括:项目档案,公用的工作延续时间估计数据库,项目工作组的知识确定工作时间的主要方法
①专家判断:专家判断主要依赖于历史的经验和信息,当然其时间估计的结果也具有一定的不确定性和风险.
②类比估计:类比估计意味着以先前的类似的实际项目的工作时间来推测估计当前项目各工作的实际时间.当项目的一些详细信息获得有限的情况下,这是一种最为常用的方法,类比估计可以说是专家判断的一种形式.
③单一时间估计法:估计一个最可能工作实现时间.(对应于CPM网络)
④三个时间估计法:估计工作执行的三个时间,乐观时间a,悲观时间b,正常时间m.(对应于PERT网络)期望时间t=(a4mb)6示例某一工作在正常情况下的工作时间是15天,在最有利的情况下工作时间是9天,在最不利的情况下其工作时间是18天,那么该工作的最可能完成时间是多少呢正常工作时间t=(94×1518)6=14.5天工期估计示例工作时间估计结果
①各项工作时间的估计
②基本的估计假设
③工作列表的更新项目计划工作列表紧前工作(或紧后工作)时间估计(天)负责人
项目负责人审核意见:资源管理项目工序一览表
过程四:制定进度计划
目标:制定项目的详细安排计划,明确每项工作的起始终止时间,作为项目控制的有效手段
依据:项目内容的分解,各组成要素工作的先后顺序,工作延续时间的估计结果
人员:安排时间进度时,项目主管要组织有关职能部门参加,明确对各部门的要求,据此各职能部门可拟定本部门的项目进度计划.
形式:项目的进度计划目前多采用网络计划技术的形式,其有助于明确反映项目各工作单元之间的相互关系,有利于项目执行过程中各工作之间的协调与控制.
进度安排所依赖的有关资料和数据
①项目网络图
②工作延续时间估计
③_资源需求
④资源安排描述:什么资源在什么时候是可用的,以及在项目执行过程中每一时刻需要什么样的资源,是项目计划安排的基础.当几个工作同时都需要某一种资源时,计划的合理安排将特别重要.
⑤日历:明确项目和资源的日历是十分必要的,项目日历将直接影响到所有的资源,资源日历影响一个特别的资源.
⑥限制和约束:强制日期或时限,里程碑事件,这些都是项目执行过程中所必须考虑的限制因素.
项目进度安排的工具和技术(1)数学分析
关键线路法CPM:关键线路法是可以确定出项目各工作最早,最迟开始和结束时间,通过最早最迟时间的差额可以分析每一工作相对时间紧迫程度及工作的重要程度,这种最早和最迟时间的差额称为机动时间,机动时间为零的工作通常称为关键工作.关键线路法的主要目的就是确定项目中的关键工作,以保证实施过程中能重点关照,保证项目按期完成.
计划评审技术PERT:PERT的形式与CPM网络计划基本相同、只是在工作延续时间方面CPM仅需要一个确定的工作时间,而PERT需要工作的三个时间估计,包括最短时间a,最可能时间m及最长时间b,然后按照β分布计算工作的期望时间t.PERT通常使用的计算方法是CPM的方法.
过程五:控制项目的进度变更
项目计划的执行需要做如下两个方面的工作:需要多次反复协调消除与计划不符的偏差项目计划的控制就是要时刻对每项工作进度进行监督,然后,对那些出现偏差的工作采取必要措施,以保证项目按照原定进度执行、使预定目标按时和在预算范围内实现.
4.2 项目的任务分解与进度估算§4.2 项目的任务分解与进度估算
4.2.1 选择合适的项目的生存周期模型
4.2.2 项目任务分解结构WBS
4.2.3 软件项目的规模估算
4.2.4 软件项目的工作量估算
4.2.5 软件项目的进度估算由于软件开发项目的特点、在制定软件项目计划之前、我们必须针对不同的软件开发生命周期模型,了解项目的阶段,每个阶段的任务,以及各阶段工作之间的联系关系.特别是根据软件生命周期模型特点、制定可检查和监督的计划目标.
软件技术,软件产品和软件项目的包含关系:
优点:a.强调开发的阶段性;b.强调早期计划及需求调查;c.强调产品测试.软件项目的生存周期模型瀑布模型
缺点:a.依赖于早期进行的唯一一次需求调查,不能适应需求的变化;b.由于是单一流程,开发中的经验教训不能反馈应用于本产品的过程;
软件项目的生存周期模型演化模型a.任何功能一经开发就能进入测试以便验证是否符合产品需求.b.帮助导引出高质量的产品要求.如果没有可能在一开始就弄清楚所有的产品需求,它们可以分批取得.而对于已提出的产品需求,则可根据对现阶段原型的试用而做出修改.
c.风险管理可以在早期就获得项目进程数据,可据此对后续的开发循环做出比较切实的估算.提供机会去采取早期预防措施,增加项目成功的机率.
d.大大有助于早期建立产品开发的配置管理,产品构建(build ),自动化测试,缺陷跟踪,文档管理.均衡整个开发过程的负荷.
e.开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率.
f.如果风险管理发现资金或时间已超出可承受的程度,则可以决定调整后续的开发,或在一个适当的时刻结束开发,但仍然有一个具有部分功能的,可工作的产品.
g.心理上,开发人员早日见到产品的雏型,是一种鼓舞.h.使用户可以在新的一批功能开发测试后,立即参加验证、以便提供非常有价值的反馈.
i.可使销售工作有可能提前进行、因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用.
a.如果所有的产品需求在一开始并不完全弄清楚的话、会给总体设计带来困难及削弱产品设计的完整性,并因而影响产品性能的优化及产品的可维护性.
b.如果缺乏严格的过程管理的话、这个生命周期模型很可能退化为一种原始的无计划的试-错-改模式.
c.心理上,可能产生一种影响尽最大努力的想法,认为虽然不能完成全部功能,但还是造出了一个有部分功能的产品.
d.如果不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面的影响.
a.强调严格的全过程风险管理.b.强调各开发阶段的质量.c.提供机会检讨项目是否有价值继续下去.软件项目的生存周期模型螺旋模型引入非常严格的风险识别、风险分析,和风险控制,这对风险管理的技能水平提出了很高的要求.这需要人员,资金,和时间的投入.
软件生命周期模型的不同、对于软件项目管理,则有不同的影响:
由于生命周期模型不同、软件项目的开发可能被分为不同的阶段,例如:
在瀑布模型,可以比较严格地看到软件开发的需求,设计,编码、测试等阶段.每一阶段的目标,交付成果,审查和确认标准是非常明确的,唯一的和一致的.
在演化模型中、每一次迭代,可能是需求,设计,编码、测试过程的完整再循环.而在一次迭代内部,是一个完整的瀑布模型.因此,阶段标志比瀑布模型更多,但阶段之间的进展差异可能没有瀑布模型那么明显.
在不同的模型中、阶段审查和确认的要求程度也不同.瀑布模型的阶段审查非常严格,并假定前一阶段的输入状态不再变化.演化模型则只针对本次迭代开始时获得的需求,并假定还可以再发生需求变化,项目根据实际需要、还可能再次进入下一轮迭代.
不同的模型,要求也不同.在瀑布模型,每一阶段都是以项目最终目标的要求,来完成本阶段的任务职责.而演化模型则是以本次迭代目标为标准.而迭代的次数,一次迭代的规模(演进)大小,可以根据需求变化而变化.因此,迭代的目标可以调节.
所以,在制定软件项目管理计划的时候,确认该项目的生命周期模型,才能了解项目计划阶段的划分办法,才能定义项目的工作产品、进行工作任务分解等等计划制定的步骤.
生存周期模型对软件项目计划管理的影响在项目管理过程中、项目计划和控制是非常重要的一个环节,良好的项目计划能同时对项目进度,质量和投资起到很好的控制作用,失败的项目计划则有可能带来混乱,失控甚至项目的最终失败.
在项目计划的过程中、人们往往会求助于WBS方法进行项目工作任务的分解.在此基础之上再进行时间资源的估算,进度估计,最后形成项目的成本.
WBS随着项目规模的差异所起的作用不尽相同.小的项目只需要很简单的WBS结构,结构的划分基本上是一目了然的,获得的结果容易得到认可.项目规模越大,WBS也越重要、从另外一个角度来讲也越难做好.对大型项目而言、确定项目的WBS结构往往不可一蹴而就,需要经过多次反馈和迭代,修正,最后才能得到一个项目各方都能接受的WBS结构.
下面,我们就来仔细讨论有关WBS的相关话题.项目任务分解结构WBS的作用在开始了解什么是WBS结构之前、我们先来看一看WBS在项目过程中究竟起到什么作用_这个问题涉及到项目规划和管理的几个层次.良好的项目管理必须具备以下因素:对项目的认知,为项目提供良好的协同环境和有效的控制.这几个因素环环相扣,前者是后者的必要条件.
一个良好的WBS结构在项目管理中所起的作用也可以这三个层次来理解.
认知层次____站在认知的层次,WBS所起的作用是一目了然的.对项目的认知是协同和控制的基础、如果项目各方对项目本身如果没有一个清晰的无歧义认知的话、项目的成功几乎是不可想象的.WBS的层次结构为我们认识,把握复杂项目的逻辑关系提供了良好的工具.
协同环境层次____ 在共同认知的基础上,项目的成功还有赖于良好的协同环境.一个复杂的项目往往有许多参与者、像高速公路这样的大型基建项目,参与者会包括:政府部门,业主,设计咨询机构,施工单位、设备采购供应商,施工监理单位等.而一个软件项目,也可能有用户,硬件设备供应商,第三方软件供应商和组织内部的不同部门.项目的顺利进展有赖于这些不同角色的协同工作.由于这些参与者在项目过程中从事不同的工作,需要不同的信息.比如,复杂的项目会遵循先自上而下后自下而上的计划制定过程.两种计划的粒度和范围都是不一样的,但二者需要有机地结合起来形成统一的计划,WBS结构为这些信息提供了一个结构框架.另外和邮政系统中的邮政编码类似,WBS结构还可以成为进度,资源等信息的标签,使不同层次的信息就可以在预先规定的线路中漫游.
控制层次____认知和协同环境并不必然意味着项目的自动成功.项目管理者还必须对项目的进度,范围和资源进行有效的控制.为了进行有效的控制,必须对项目中的工作任务进行范围界定.清楚的范围界定能有效防止出现纠纷时合同双方牵扯不清、同时还有助于用户对项目组进行数量最少但最有效的控制.而WBS结构实际上有助于界定范围,当然,这实际上也是对WBS结构的要求.
WBS不但说明项目组应该做什么,还应该能说明,那些事情并不是项目组的工作.实际上,这个问题常常被忽略,项目组做了很多并不属于自己,自己也做不好的事情.这个问题,并不能用一切以用户满意为理由.
WBS还是以下过程的输入:
项目计划:WBS是范围,成本,进度和风险计划的基础;
状态报告:WBS提供组织对项目的成本,进度状态进行监督的依据;
变更管理:WBS可以使项目经理在合适的控制点、度量,评审,控制变更的发生,评估影响、做出变更控制的决定.
WBS的总体结构WBS结构的总体设计对于一个有效的工作系统来说是个关键.结构应以等级状(层次结构)或树状(组织结构)来构成,使底层代表详细的信息,而且其范围很大,逐层向上.即WBS结构底层是管理项目所需的最低层次的信息,在这一层次上,能够满足用户对交流或监控的需要、这是项目经理,项目组成员管理项目所要求的最低水平.
结构上的第二个层次将比第一层次要窄,而且提供信息的对象层次,也应比低一层WBS的用户层次要高,以后依此类推.
结构设计的原则是必须有效和分等级,但不必在结构内、建立太多的层次,因为层次太多了不易有效管理.对一个大项目来说,4到6个层次就足够了.
在设计结构的每一层中、必须考虑信息如何向上流入第二层次.原则是从一个层次到另一个层次的转移应当以自然状态发生.此外,还应考虑到使结构具有能够增加的灵活性,并从一开始就注意使结构被译成编码时对于用户来说是易于理解的.____WBS的层次结构对于一个软件项目,划分项目的WBS结构有许多方法,如按照专业划分,按照子系统,按照项目不同的阶段划分等、以上每一种方法都有其优缺点.一般情况下,确定项目的WBS结构需要组合以上几种方法进行、在WBS的不同层次使用不同的方法.
按专业划分在专业下按阶段划分在阶段内按子系统划分WBS的粒度(1)识别项目的主要产品、主要阶段(2)细分的原则考虑分解对象考虑使用者考虑编制者_任务单元的选择它们是一个工作产品;它们只代表自己,没有下属的单元;它们是没有必要再细分的工作;它们能比较直观地看出、是通过什么方式实现或获得的,如:外购、设计等;
它们需要达到什么目的能直观地被用户,项目组和任务执行者所理解.
我们用反问的方法,再来审查我们已经分解到最底层的任务:由最底层的任务单元来计算和控制成本和进度的精度是否足够完成此任务单元的责任人能力是否足够,任务是否过重或任务不饱满这些任务单元是否还有理由继续再细分下去是否有必要更详细地了解内部的过程和产品这些工作单元是否具有充分的独立性在任务单元内部,是否在时间,资源等方面受其他单元的牵制对任务单元的评价,度量尺度是否清楚用户,项目组和任务执行责任个人是否都能清楚,完整地理解这些任务WBS工作编码由高层向下层用多位码编排,要求每项工作有唯一的编码WBS工作编码的意义对WBS的任务进行编码、WBS就不仅是一个任务表示方式,它还可以充当一个共同的信息交换语言、为项目的所有信息建立一个共同的定义.例如:它是计划,成本,风险,监督和评审,考核等过程的基本信息来源和依据.
通过任务编码、我们就能够把项目的所有要素在一个共同的基础(WBS)上建立关联、在此基础上建立各管理过程的所有信息沟通.
应用WBS作为项目信息的共同基础的最大优点是,为监控及预测费用,进度,实施等不同过程,建立了一个统一的项目信息系统,WBS给所有阶段,过程的项目管理人员提供了一个均可以与之作对比的一致基准,并且在大型项目中、由于参加者众多及人员可能发生的变化,使所用的项目概念,阶段,任务对所有的参加者都具有相同意义是很重要的,而WBS通过编码和编码字典的编制可使这一点得到保证.
WBS的编码原则不论编码采用什么形式,编码应具备以下基本原则:
(1)编码应能反映出任务单元在整个项目中的层次和位置,例如:1.2.3和3.4.5显然是在不同层的不同位置.
(2)当发生任务增加和删减时,整个的层次体系不会发生巨大变化,只是在恰当的位置,进行增删.
(3)编码方便进行任务的索引.
(4)编码方便与其他过程管理的相互参照.WBS分解类型基于可交付成果的划分上层一般为可交付成果为导向下层一般为可交付成果的工作内容WBS工作分解的原则
功能或技术的原则:考虑到每一阶段到底需要什么样的技术或专家
组织结构:考虑项目的分解应适应组织管理的需要
地理位置:主要是考虑实施处于不同地区的子项目
系统或子系统原则:根据项目在某些方面的特点或差异将项目分为几个不同的子项目.
基于工作过程的划分上层按照工作的流程分解下层按照工作的内容划分软件项目开发的WBS
1 项目启动阶段
1.1 售前阶段
1.1.1 提供《技术白皮书》和现场的技术介绍、了解项目需求
1.1.2 提交《项目可行性研究报告》
1.1.2 提交《项目开发计划》
1.1.4 提交《项目风险管理计划》
1.1.5 通过公司的立项评审
1.1.6 进行项目前期开发(制作需求模板,功能演示系统,关键技术分析和实验等)
1.1.7 向用户提交《系统建设建议书》
1.2 招标和合同签订阶段
1.2.1 制作标书,参加投标和答标活动
1.2.2 中标后,根据商务谈判的结果,制作合同副本
1.2.3 合同签订
1.3 项目前期准备阶段
1.3.1 指定项目经理,子项目经理或技术经理,成立项目组.
1.3.2 完成《工作任务分解(WBS)》
1.3.3 划分接口人员责任
1.3.4 提交《项目进度计划》
1.3.5 提交《项目成本预算》
1.3.6 提交《风险控制计划》
1.3.7 其他专项计划:对本项目开发中需制订的各个专题计划(如分合同计划,开发人员培训计划,测试计划,安全保密计划,质量控制计划,配置管理计划,用户培训计划,系统安装计划等)、分别进行制订.
1.3.8 以上项目计划提交公司评审,并形成《项目任务责任书》下达
2 需求分析阶段
2.1 分析用户需求
2.1.1与用户一起分析需求,并形成用自然语言表述的《需求说明书》,由用户确认
2.1.2将用户确认的《需求说明书》,转化为用计算机术语描述的《系统需求规范书》
2.1.3提交《系统需求规范书》,进行评审
2.2 形成《集成测试计划》,提交公司评审
3 系统设计阶段
3.1 系统总体设计
3.1.1运行环境设计
3.1.2 基本业务处理流程描述
3.1.3 系统结构设计
3.1.4 模块关系设计
3.1.5 人工处理过程
3.1.6 尚未解决的问题
3.2 接口设计
3.2.1用户接口
3.2.2 外部接口
3.2.3内部接口
3.3 运行设计
3.3.1 运行模块组合:说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合,说明每种运行所历经的内部模块和支持软件.
3.3.2 运行控制:说明每一种外界的运行控制的方式方法和操作步骤
3.3.3运行时间:说明每种运行模块组合将占用各种资源的时间.
3.4 系统数据结构设计
3.4.1逻辑结构设计要点
3.4.2物理结构设计要点
3.4.3数据结构与程序的关系后备技术降效技术恢复及再启动技术企业经营决策系统项目网络软件硬件系统开发系统设计需求分析系统分析文档模块开发培训验收系统转换单元测试项目工作分解结构表
项目名称:
项目负责人:
单位名称:
制表日期:主要活动描述
_ 签名: 日期:WBS分解的一般步骤(1)总项目(2)子项目或主体工作任务(3)主要工作任务(4)次要工作任务(5)小工作任务或工作元素WBS注意事项
分解后的任务应该是:可管理的,可定量检查的,可分配任务的,独立的复杂工作至少应分解成二项任务表示出任务间的联系不表示顺序关系最低层的工作应具有可比性与任务描述表一起进行包括管理活动包括外包商的活动.WBS表达形式层次结构图和锯齿列表图形显示锯齿列表
1.1元素A
1.1.1任务
1.1.2任务
1.2元素B 假如您要在自己的家里举行一次生日宴会,请按WBS为你制定一份工作的分解计划生日宴会WBS(锯齿结构)
1.0 晚宴
1.1生日蛋糕
1.3.1食品
1.3.2餐具
1.4.1凉菜
1.4.2熟菜蔬菜类海鲜类其它类
2.2灯光布置
2.3室内布置
2.4CDVCD光碟生日宴会WBS(树型结构)
假如贵公司承接了某高校全省范围的远程教学网的建设项目,如果请你负责此项目,你将如何分解此项目所应包含的工作确定了软件项目开发的生命周期模型,进行了工作任务分解,就建立了一个项目任务整体的框架结构.
另外一方面,一个良好的软件项目计划的建立,还必须估算准备开发的软件项目的任务大小,资源情况,投入的成本,限制因素等、进行充分的估算,最后,根据估算,才能制定出合理的项目开发计划.
具体来说,要估算的内容包括:软件工作产品的规模软件项目的工作量和成本软件项目的进度项目所需要的人员,计算机等资源什么是软件项目的规模在一个软件项目中、项目组要完成的工作产品、是规模评估的对象,那么,项目组要完成的工作产品包括些什么是最后要交付的(向用户和向组织二个方面)程序,文档.
但是,项目组并不是只要完成最后交付的程序和文档,就可以了.在交付前、要进行确认和验证测试,为此,要进行质量控制有关的工作.再往前追述,项目组还必须做配置管理,需求管理,以及项目管理.这些都有工作量.那么,软件规模如何估算现在,常用的办法,是通过对软件程序的规模进行估算的办法,来间接反映软件项目的规模.规模是工作量的一个方面,并不能说规模大,工作量就大.在这方面,并不一定是完全等同的.显然,接口控制程序的程序量可能并不大,但并不能可能程序量比较大的报表处理程序的工作量就大.这种不合理性,一般通过相关的程序复杂度,难度,加以调节.这个问题,在相应的评估算法中、采用加权因子的方法,加以调整.同样,程序规模的增长,会带来支持和管理工作成指数规模的增长.因此,这也是需要注意的地方.
用什么来估算软件项目的规模软件的规模计算,从有软件的一天开始,就是一个没有解决的问题.没有解决的难题是,现在越来越没有办法给出评价程序量多少的统一尺度.在程序设计的早期,直接的编码量(字节数)是度量程序量的简单办法.但是,没有多久、这个办法就受到了挑战.因为有一个好的算法(例如:好的循环控制),可以节省大量的程序编码、但工作量(设计所花的时间,测试的复杂度)等、反而并没有节省开发的精力和时间.因此,程序量作为工作量的度量标准,显然是不正确的.那么现在,在完全不同的系统,应用环境下,提出统一和易于运用的度量标准,是非常困难的.
为了解决问题,在CMM2的计划管理中、已经提出了一些度量的实例,包括:功能点数,特征点数,编码行数(LOC),需求数或页数等.还可以有:模块数目,表格数,用户界面屏数,及数据结构等、作为规模评估的参考.
度量软件项目规模的尺度,是一个相对值,而不存在绝对值.软件项目规模的估算方法LOC法LOC(Line of Code)一个衡量软件项目规模最常用的方法:
LOC指所有的可执行的源代码行数,包括可交付的工作控制语言(JCL:Job Control Language)语句,数据定义、数据类型声明,等价声明,输入输出格式声明等.
单位编码行(1LOC)的价值和人月均编码行数可以体现一个软件生产组织的生产能力.组织可以根据对历史项目的审计来核算组织的单行编码价值.
例如,某软件公司统计发现该公司每一万行C语言源代码形成的源文件(.c和.h文件)约为250K.某项目的源文件大小为3.75M,则可估计该项目源编码大约为15万行、该项目累计投入工作量为240人月,每人月费用为10000元(包括人均工资,福利,办公费用公滩等)、则该项目中单位LOC的价值为:
(240×=16元LOC
该项目的人月均编码行数为:=625LOC人月软件项目规模的估算方法Delphi法Delphi法是最流行的专家评估技术,在没有历史数据的情况下,这种方式适用于评定过去与将来,新技术与特定程序之间的差别、但专家专的程度及对项目的理解程度是工作中的难点、尽管Delphi技术可以减轻这种偏差,专家评估技术在评定一个新软件实际成本时通常用得不多,但是,这种方式对决定其它模型的输入时特别有用.
Delphi法的步骤是:
1,协调人向各专家提供项目规格和估计表格;
2,协调人召集小组会各专家讨论与规模相关的因素;
3,各专家匿名填写迭代表格;
4,协调人整理出一个估计总结,以迭代表的形式返回专家;
5,协调人召集小组会,讨论较大的估计差异;
6,专家复查估计总结并在迭代表上提交另一个匿名估计;
7,重复4-6, 直到达到一个最低和最高估计的一致. 软件项目规模的估算方法类比法类比法适合评估一些与历史项目在应用领域,环境和复杂度的相似的项目,通过新项目与历史项目的比较得到规模估计.类比法估计结果的精确度取决于历史项目数据的完整性和准确度.因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的.
类比法的基本步骤是:
1,整理出项目功能列表和实现每个功能的编码行数;
2,标识出每个功能列表与历史项目的相同点和不同点、特别要注意历史项目做得不够的地方;
3,通过步骤1和2得出各个功能的估计值;
4,产生规模估计. 软件项目规模的估算方法功能点测量法功能点测量法是在需求分析阶段基于系统功能的一种规模估计方法.该方法通过研究初始应用需求,来确定各种输入,输出、计算和数据库需求的数量和特性.通常的步骤是:
1,计算输入,输出、查询,主控文件,和接口需求的数目.
2,将这些数据进行加权乘.下表为一个典型的权值表. 功能类型权值输入4输出5查询4主控文件10接口10
3,估计者根据对复杂度的判断、总数可以用25,0,或-25%调整.
据发现,对一个软件产品的开发,功能点对项目早期的规模估计很有帮助.然而、在了解产品越多后,功能点可以转换为软件规模测量更常用的LOC.
对规模估算的修正为了补充单一算法的不足,实际上,软件项目经理常采用其他方法,来进行校正和补充.这些方法是:
(1)把大块的任务分解为小规模的任务.例如:使用WBS对任务分解,然后对分解到的最末梢功能,进行规模估算,然后,在进行相加.这种方法的好处是化复杂为简单.当我们无法把握大系统的规模时,我们可以比较有把握地估算小模块的规模.但是,问题是,各单独模块的规模之合,一般(从工作量上)并不等于系统的工作量之合.这就是我们说到的系统集成的工作量.
(2)采用与历史数据比较、修正的方法.
(3)采用最大值,最小值和最可能值折算的方法.
(4)对同一项目,至少使用二种以上工具和方法进行测算,避免一种方法的局限性.
` (5)使用同行专家评审,评估小组集体投票取折中值的方法,博采众长.
(6)逐步逼近的方法;不把评估结果作为最终值,而是看成是一个逐步逼近的近似值,在以后的再评估中、可以进行调整.当项目刚刚启动,做第一次测算时,可以允许有30%以上的波动范围.在完成需求分析阶段,希望能达到波动控制在30%的范围内的目标.当基本完成详细设计的时候,估计的编码规模,应只能有20,甚至更低的误差.
对规模估算的迭代修正随着软件项目进程的逐步展开、需求被逐步地精细描述和定义、任务被依据需求进行分配、使用任务分解结构(WBS)的方法来建立需求(产品架构)与任务(软件开发过程)之间直接的,准确的联系,并实现详细化,文档化,工作产品被分解成各个工作元素.
产品架构必然要反映出项目的整体设计概念,层次结构,并从分解后的组件和模块功能分层中体现出来.
随着产品架构的精化,进一步定义出了开发各产品元素所需的过程任务.再把这些任务分配给不同的工程师.其目的是使任务分解架构中每一项任务,可以由个人或几个人的小组在较短的时间内完成.总之,任务分解架构越详细,则任务分配越明确,产品估算越准确,项目计划越完善,项目跟踪也越精确.
在这个基础上,经过一段时间的运行、一些典型的模块已经完成,所没有完成的只是相类似的模块等待接着继续开发.这时,对每一个产品元素的规模进行再估算和精细化调整的条件已经具备,根据一段时间的经验、重新调整软件项目规模估算,逐步求精,将获得更接近实际的估算结果.
序号系数因素因素取值准则得分创造性要求没有-在不同设备上重编程序很少-具有更严格的要求有限-具有新的接口相当多-具有相当多的技巧重大的-应用先进的技巧通用程度(数据库,中间平台,操作系统等)很强的限制-单一目标有限制-功能的范围是参量化的有限的灵活性-允许格式上有变化多用途格式有一个主题领域很灵活能多设备范围广泛工作范围同一办公室同一栋楼同一城市跨城市跨国目标范围的变化没有极少偶尔有经常不断体系结构单一结构CSBSBASCAS三层以上跨语言平台设备复杂性单机、常规处理单机、常规处理,扩充的外设系统多机、标准外设系统多机、复杂的外设系统一机控制多机自动IO和显示人员1~2人3~5人5~10人10~18人18人以上开发投资6人月以下6人月至3人年3人年至10人年10人年至30人年30人年以上重要程度数据处理对单一用户关系有影响对用户群关系有影响单位成败国家安危
1 对程序改变的完成时间要求2周以上1~2周3~7天1~3天24小时以内
1 对数据输入的响应时间要求1天以上60分钟~1天1~60分钟3秒~1分钟3秒钟编程环境等专业软件平台小中大型机平台汇编语言并行的软件开发有限中等程度很多完全的并行开发代码复用程度80~100%60~80%40~60%20~40%0~20%终端用户数2~56~2021~5051~总分规模评分必须具备20~3031~4849~6970~8889~100可行性研究报告
√项目开发计划风险管理计划表技术白皮书软件需求说明书数据要求说明书据实际决定系统概要设计说明书详细设计说明书数据库设计说明书用户手册或使用说明操作手册代码测试计划(单元)测试分析报告(单元)测试计划(集成)测试分析报告(集成)测试计划(系统)测试分析报告(系统)项目开发总结报告软件开发项目的工作量,主要指软件开发各过程中所花费的工作量.与传统的制造业不同、软件的成本基本可以不考虑原材料和能源的消耗,主要是人的劳动的消耗.另外,软件也没有一个明显的制造过程,它的开发过程具有明显的一次性过程特征.因此,软件开发工作量的估算,应是从软件计划,需求分析,设计,编码、单元测试,集成测试到认证测试,整个开发过程所花费的工作量,作为工作量测算的依据.
我们在前一小节已经介绍了软件的生命周期模型,采用什么样的生命周期模型,对使用什么样的工作量估算算法,有很大的影响.实际上,有些算法适合某一模型,有些则适合另一模型.采用面向对象技术为主的开发与传统的开发技术,在工作量的估算上,当然也不同.这些、都需要我们根据软件开发的具体特点、进行选择.
软件项目的工作量估算与进度估算的关系软件项目工作量估算的结果是任务的人力和需时.在工作量估算时,度量的任务需时是讨论以任务元素,子任务,项目任务为单位(我们称为:单位任务)的需时,它是计算成本,制定进度计划的依据.而在进度估算时,单位任务的需时,又是时间进度计划安排的基本数据来源.
二者最主要的区别是:
工作量估算时对时间的测算,注重的是最后获得的时间总量,或者是不同阶段,不同工作性质,不同成本因素下的时间量.例如:工作量估算结果会按人力资源层次的不同、进行分类:系统设计师需要多少人月,一般编程人员需要多少人月等.或者、在需求分析阶段,需要多少人月,在设计阶段需要多少人月等.这样,可以比较容易地获得人力资源需求和成本估算结果.
在进度估算时,注重的是任务单元的时间长度,任务之间的时间先后关系和联系关系.在做计划进度安排时,重点考虑单位任务的时间历时,不考虑由谁和完成什么样的单位任务(当然不会完全不考虑,例如,需要调整或协调的时候)软件项目工作量的估算方法软件工作量的估算,可以采取不同的操作方法,以下是几种常用的方法:
(1)自顶向下估算法:首先对整个系统进行总工作量估算,再考虑子系统,把总工作量逐步分解为各组成部分的工作量,并考虑到开发该软件所需要的资源,人员,质量保证、系统集成安装等的工作量.
优点是估算的工作量小,速度快.缺点是对项目中的特殊困难估计不足,估算出来的工作量盲目性大,有时会遗漏被开发软件的某些部分.
(2)自底向上估算法:先对开发各个子系统或每个模块的工作量进行估算,再逐步相加.这是一种常见的估算方法.
优点是估算各个部分的准确性高.缺点是缺少各项子任务之间相互联系所需要的工作量,还缺少许多与软件开发有关的系统级工作量(配置管理,质量管理,项目管理).所以往往估算值偏低,必须用其它方法进行检验和校正.
(3)相似比较估算法:把开发项目的工作分割到一定的程度,和过去的工作进行比较、对其中相同的或相近的部分,用已有的数据进行估算,对不同的部分再用其它的方法估算.
优点是可以提高估算的准确程度,缺点是不容易明确类似的界限.
(4)Delphi 估算法:请多位项目经理,系统分析员或其他专家,利用专家的经验来评估软件的开发成本.
优点是可以摈弃无根据的估算值,缺点是一些组员可能会受权威或政治因素的影响.
软件项目工作量的计算工作量评估评估是对项目有关工作的,以人时,人月,人年为单位进行的计算,它是成本和预算的依据.工作量估计的结果,一般是多少个人的多少工作时间.
项目工作量估算的来源,是项目任务的WBS分解.因此,在获得工作量的度量值之前、首先是对任务的分解.当然,在项目的不同阶段,对任务的认识和理解的程度不同、所能分解的粒度不同、获得的工作量估算的准确性也会不同、这是不用再说明的.
在前面,我们已经介绍了WBS分解方法.有了任务分解(暂时不考虑集成的相关工作),就可以对分解后获得的任务单元的性质,进行定义.例如:是概要设计,架构设计,还是接口设计等.定义的目的是分配不同级别的人力资源,并估计在这样(或不是这样)的人力资源条件下的任务历时时间.
软件项目工作量估算的案例经过测算,开发电信综合营业系统的工作量估计是122个人月.人力资源名称工作量(人月)资源数量(人)工期(月)项目管理系统需求分析系统设计师系统概要设计系统详细设计系统架构设计系统架构师核心模块编码高级程序员业务模块编码一般模块编码初级程序员测试工程师集成测试高级测试师文档编写文档编辑合计
122 下图是该项目的人力资源分布(按月)曲线.根据公司的人力资源情况,可以分析这个分布是否可以得到满足.
软件项目工作量的其他影响因素在做软件项目工作量的估计时,应考虑到以下几个其他因素:
项目复杂度,人为因素和工程因素,以外因素:
复杂度包括:问题领域,算法复杂性,程序设计语言、软件复用量,可靠性等性能要求,系统平台复杂性,资源的限制等.
人为因素包括:开发人员的能力、经验、稳定性,开发的组织管理能力、用户的配合等.
工程因素:包括开发技术的难度,进度的紧迫度,项目团队的凝聚力、多地点开发等.
意外事件也是一个影响因素,意外事件可以有以下几种:工程师的事假,产假和病假天数;工程师参加与项目无关的培训的天数;工程师需要为其它项目做软件质量保证工作的时间;工程师需要做非项目有关的工作,例如参加员工会议,软件工程过程小组的工作等;
软件项目工作量的其他构成因素在我们进行软件项目工作量估算的时候,我们可能会比较集中地考虑需求分析,设计,编码、测试等的工作量,但往往会忽略以下的一些工作量:用于各模块,子系统,软件系统与硬件网络系统等之间集成的测试,调试等的工作量;
用于编写用户文档和设计文档的工作量;用于需求管理,配置管理,质量管理,风险管理等支持过程的工作量;
用于项目管理的工作量.有关这些部分工作量的度量,目前还没有看到比较系统地,适用的度量和估算方法的介绍.
因为作为项目管理,本身就是全过程,随时性和零碎的,因此,对于它们的工作度量,确实更为困难.但是,这部分的工作又是非常关键和不可或缺、工作量也是比较大的.因此,如何规范地测量,是项目管理的一个新课题.
软件项目工作量的其他估算软件项目的成本估算,是一个非常重大的课题,我们将在第四章中、用一章的篇幅、来讨论软件成本的估算,预算,控制.
在CMM2软件项目计划管理活动的第7项、是对关键计算机资源的评估.所有项目必须进行关键计算机资源评估,并且必须将填写完成的关键计算机资源评估调查表存入项目文件夹中.对计算机资源的评估,可以借助一些软件工具,例如:MS的Project 2000.我们把对资源的规律,集中放在本课程的第11章《软件项目的综合管理》中介绍.
在CMM2的计划管理活动中、第9个活动是对软件项目的风险,进行识别和评估.在制定软件项目计划的时候,对所有项目都必须进行风险评估,并且必须将填写完成的风险评估调查表存入项目文件夹中.为了便于对软件风险管理能有一个系统的认识和理解,我们把软件风险的识别、评估,统一放在本课程的第7章《软件项目的风险管理》中集中讨论.
在前面的介绍中、我们已经讨论了软件项目工作量估算中的时间和软

ppt文档的标签：时间管理目的

更多推荐标签：设备检定张爱玲研究住宿水单体育总结技术专家竟聘新西兰专利法铁路机车论文校园电子板报仙客来天下郡国生物奥赛资料药剂师报名表机械电子前景商业企业园林绿化论文护理规划企业服务质量普特南姆抢答器钻研英语服装买手中译英平面构成教程农民工论文最新婚姻法评议考核林甸县统计诚信问题村小建设意见室内鉴赏论文