人人范文网 范文大全

浅谈项目进度管理之计划编制

发布时间:2020-03-03 19:07:38 来源:范文大全 收藏本文 下载本文 手机版

浅谈项目进度管理之计划编制

软件项目计划(SPP:Software Project Plan)是CMM二级中列出的第二个关键过程域。这是因为CMM2软件项目计划需要根据纳入配置管理后的软件需求进行项目估算,并依据文档化的流程,形成项目计划文档。软件项目计划的目的在于建立合理的计划,执行软件工程和管理软件项目。软件项目计划管理在软件开发过程中处于十分重要的地位,它体现了对客户需求的理解,是开展项目活动的基础,是软件项目跟踪与监控(SPTO)的基础。

一、软件项目计划这一关键过程域在实施的过程中应该贯彻如下方针:

1.以分配的软件需求作为计划软件项目的基础。

在项目定义阶段,针对用户提出的原始需求(又称statements of work ,SOW),通过用户方和承接方的相互协商,确定双方一致同意的、项目组承诺实现的需求,这个需求即是“分配给软件的系统需求”或者更简洁地说,“分配需求”,然后根据它来提出项目意见,制定初始的项目计划。由此可见项目计划是以分配给软件需求作为软件项目的基础。

2.由项目经理、项目软件经理和其他软件经理共同协商软件项目的各项约

定,并与系统工程组、硬件工程组和系统测试组协商,这些组介入该活

动的有关事宜,同时记入文档。

所谓约定有对外约定和对内约定。对外约定如与客户、分包商有关部门约定。对内约定包含两方面:一是项目组与组织内部其他组,如测试组、硬件组、系统组的约定。二是项目组内部的约定。对软件而言,对外约定像用户需求的更改是不可避免的,一旦有变动会影响整个项目。因此CMM提出由高级管理者控制对外约定。约定是计划的基础,CMM SPP中将其列为一个目标,即约定必须是有关各方一致同意、认可的。

另外,软件计划要包括所有项目活动和所有参加方面的责任,这些活动和责任都要文档化,以保证有效地将计划传达给项目各个参加方。在项目计划执行前,各个项目参加方要认同所承担的项目责任,这种认同是项目计划有效性的一个基本保证。

3.软件项目的规模、工作量和成本估计、进度和其他约定必须通过相关组

的审查,以获得相关组及个人的支持。

CMM中的一个组织或一个机构里,通常有许多小组,比如软件质量保证组,负责计划和实施项目的质量保证活动的团队;软件配置管理组,负责策划、协调和实施软件项目正式配置管理活动的团队等等。在执行每个活动时候,这些组并不是独自行事的,而是相互影响的。在SPP这个关键过程域中受影响的组包括软件工程组、软件估计组、系统工程组、系统测试组、软件质量保证组、软件配置管理组、合同组和文档组。但是在对所有与组织外部的个人和组所作的软件项目约定,则由高级管理人评审。所以CMM中提出“高级管理者参加按照文档化规程对组织外部个人和组所作的软件项目约定的评审”以此作为一项活动。

4.项目软件开发计划需要进行管理和控制

项目计划是CMM实施一开始就涉及且最后才能相对完善的关键过程域,它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资源计划。在其他关键过程域的实践相对稳定之前,项目计划的实践总是处于需要改动的状态。 所以需要对项目软件开发计划进行管理和控制以保证项目顺利实施。

二、软件项目计划的关键问题及解决方案

1.关于软件项目的估计

建立合理的软件计划的基础是对软件项目规模、资源要求和风险等要有一个合理的估算。这个估算过程应是规范的,而不是任意的。例如,如果提出一个项目计划需十个软件工程师工作六个月的计划,那么就要问这些数据是如何得到的。用户提出的时间和费用的要求仅能作为项目计划约束的条件,而不能作为项目计划的基础。

根据CMM SPP 的活动

9、

10、11,估计对象应该包括软件规模、工作产品的工作量和成本、软件进度、风险、关键计算机资源等。项目计划的基础要求是估计项目中的各种工作所需的工作量和进度,软件成本通常由工作量换算而得到。

估计模型有很多种,常用的如下:

算法模型:包括一个或多个算法,生成的软件估计是一些变量的函数,如COCO-MO

专家判断:利用一个或多个专家的经验作估计。

类比:和已完成的与新项目的规模和功能十分类似的项目做比较,作估计 自顶向下的估计:从项目的全局特性导出项目的整体估计,然后将其分配到各个分量上

自底向上的估计:分别估计软件作业的各个分量,再综合出整体估计

在具体进行估计的时候应该注意以下几个问题:

1) 选择科学的估计方法。CMM的核心思想是不断学习、不断改进。在项

目过程中,计划是被不断修订的,所以每做一次修订,就必须作估计。

因此在某个项目中只对项目选定一种(几种)能改进的估计方法,多次

估计的结果进行比较,才能积累经验和数据,估计也才能越来越精确。

2) 必须积累本组织自己的数据

随着生命周期阶段的进展,估计会越来越精确。一方面是不确定性随着

阶段的进展而减少,另一方面基于对估计值与实际值的分析比较,可合理选择估计模型的参数。组织在每一个项目结束时,需要将项目数据综合归纳,保留。如果在刚开始没有估计值的情况下,我们只要选定方法,做就是了。需要数据的地方如项目有数据用自己的数据,否则用本组织数据。对于无组织的数据,则一次选定本地区的数据、本国行业数据,国际上的行业数据。CMM 2级SPP的活动场15要求建立一个数据库,记录项目估计数据,包括计划时的数据、再次调整计划后的数据。为使数据可用,必须记录下估计的假定,如采用的估计模型、模型参数、估计时作业的描述等。

另外,CMM2的本关键过程域还提到要按照文档化规程进行估计。由前面,在整个生存期内,随着项目的发展,需要不断进行估计。为确保估计的有效性,结果的可比性,必须描述项目进行估计的具体步骤,即所谓规程。这样一来就能保证估计过程的可重复性,无论什么人去估计,或是在不同时间估计、估计的步骤都是一致的,估计的假设也是一致的。CMM SPP中要求有4个文档化的估计规程,具体的规程形式由项目自己确定,CMM仅提出了对规程的一般要求。这些规程指出:

估计假定要记入文档;

如有历史数据,使用历史数据;

估计要经过评审;

规模估计是多种估计的基础;

在用CMM进行过程改进的实践中,许多项目常常忘记进行规模估计,认为项目计划内容未明显包含规模。然而正是规模大小会影响技术解决方案。对于同一计划,人和月是不能交换的,比如说5个人干3个月的活就不等于4个人干4个月的工作。规模越大。通信与管理的开销越大。规模直接影响进度的安排、人力资源的安排、计算机资源的安排以及风险的分析。所以最初的模型估计也应该在项目定义阶段给出。其中代码行技术和功能点技术两个技术用来对软件规模进行估计。代码行技术是比较简单的定量估计软件规模的方法。这种方法根据以往开发类似产品的经验和历史数据,估计实现一个功能需要的源程序行数。功能点估计依据对软件信息域特性和软件复杂性的评估结果,估计软件规模。

在进行估计的时候我们可以参考如下几点建议:

首先下功夫精简软件需求规格说明书。从根本上来讲,估计的输入是需求规格说明书。要做合理的估计首先要力争使需求规格说明清晰。

尽可能将工作分解得详细。分解得越详细,对开发软件的技术方面理解越透,估计越精确。

采用几种独立的技术,没有一种估计技术是万能的,所以要避免其弱点利用其强处,最好采用技术组合。可以按情况对不同软件成分采用不同的估计技术。

比较与印证。对同一对象采用不同的估计技术,然后比较其结果,研究为何它们得到不同估计,从中能做出较精确的估计。

注意采集数据,将实际数据与估计值进行比较,不断修订估计值和估计模型的参数。

总之,根据CMM,当我们需要制定项目计划,首先确定了项目的需求后,估计出所有的可交付产品,以及这些产品的规模。比如,规模可能包括哪些?如果是生产类项目,可能估计的是交付的东西的数量,比如凳子多少条,牛奶多少箱等,如果软件开发类项目,可能是特性多少个,代码行多少行等,这些根据你所估计的对象来确定。另外,规模估计出来后,需要根据生产率估计项目可能的工作量,比如生产一条凳子要多长时间,一箱牛奶要多长时间,软件开发的话,可能就是一天生产多少行代码。在设计阶段,可能就是一天设计几个特性或者几页设计文档等。根据生产率再估计出总工作量。 最后,根据你所拥有的人力,来确定出项目的进度计划。

根据这个再对应到软件开发上来。一个软件开发项目可能的生命周期有可能包括以下几个阶段: 需求分析、软件设计、编码、单元测试、系统测试、交付。不同的项目有不同的生命周期,但项目计划阶段一定要把项目的生命周期确定下来,这也是计划的一部分。那么,在制定计划时,怎么估计这几个阶段的里程碑时间呢?在处于二级的组织,由于之前没有什么量化的能力基线(也就是一般的每个阶段的生产率),那么也只能去参考历史项目的信息。假使以前的项目刚好做了这些度量的话,比如度量过每个阶段花费的时间,投入的人力,统计过交付件的规模(文档页数、代码行数等)。那么,项目刚好可以参考这些历史的数据,大致估计一下这个项目各个阶段可能需要的时间,来确定这个项目的阶段里程碑时间。假使没有类似的项目数据的话,可能估计的可信度就不高了。业界有估计方法,都是用来帮助我们得到比较可信的估计结果的,比如Delphe、Pert sizing。

在项目的生命周期不同阶段,因为所作的工作不同,生产率也就不同,每个阶段甚至都有不同的生产率度量单位,比如需求分析阶段,可能就是需求分析文档页数/人天。在编码阶段,可能就是代码行/人天等。一个组织需要积累和建立

这些能力数据,才能保证后面的项目有可信赖的数据参考,支撑后面的项目进行估计和计划的制定。

2.鉴别和评估软件风险

风险管理是项目管理的重要内容之内,从某种意义上讲,项目管理就是风险管理。风险就是不利事件发生的不确定性。所有。首先必须清楚风险是可能事件,它可能发生,也可能不发生。所以决定了风险的动态性。

风险评估是项目计划时必不可少的一项工作。正如前面提到的项目成本估算和进度估计一样都是项目管理的重要活动。忽略了风险,轻者给项目工作带来被动,重者可能对项目造成严重的灾难性后果。

CMM实际上在本关键过程域的活动13是如此表述这个问题的:

“对与项目的成本、资源、进度和技术方面相联系的软件风险进行鉴别、评估和建立文档”。

风险评估包括风险识别、风险分析和对风险进行优先级排序。

风险识别是风险评估的第一步。就某个特定的软件工程项目来说,从项目具体情况出发,列举出可能出现的风险。真正弄清每一个可能风险的情况是风险识别的主要任务。检查单是风险识别的一个有力的工具。采用检查单中所列举的各种风险,对照即将开发的软件项目,逐一加以甄别,判定检查单中哪些风险在该项目中可能发生。在进行风险识别时采用访谈、调查还是会议方式应根据软件项目的具体情况决定。

风险识别以后需要弄清楚已识别的风险可能何时何地发生,发生了会怎么样。风险分析的任务是分析每个风险可能造成的影响,给出比较风险大小的量值。进行分析可以借助一些已有的模型,但不是所有列出的风险都可以借助模型进行分析的,因此常常采用主观分析。

识别出风险,对其进行分析后就要对其进行排序了。排序步骤包括对已识别和分析的风险估计概率类型,如高概率风险、低概率风险;评估每个风险对项目的影响级,如低级、中级、高级。风险排序应该根据该项目各有关风险的概率和影响级。显然高概率和高影响级的风险应该排在中概率和高影响级风险的前面。最后针对排序列在前几位的风险采取缓解措施和跟踪措施。

3.确定软件生存周期

确定软件的生命周期,这在CMM本关键过程域活动5也有体现“识别和确定具有可管理的预先规定阶段的软件生命周期”。典型的几种生命周期模型包括瀑布模型、快速原型模型、渐进模型、喷泉模型等。

瀑布模型严格规定各阶段的任务,上一阶段任务输 出作为下一阶段工作输入。此模型适合于用户需求明确、开发技术比较成熟、工程管理严格的场合使用,其缺点是:由于任务顺序固定,软件研制周期长,前一阶段 工作中造成的差错越到后期越大,而且纠正前期错误的代价高。

渐进模型是指从一组简单的基本用户需求出发,首先建立一个满足基本要求的原型系统。通过测试和运行原型系统,有用户提出进一步细致的需求,然后修改和完善原型系统,反复进行这个过程直到用户满意为止。该模型适合开发初期用户需求不甚明确,相关技术和理论需要不断研究、反复实验以及开发过程需要经常与用户交互的场合,学习或研究类软件的开发常用此法。

快速原型是指快速建立起来的可以在计算机上运行的程序,它所能完成的功能往往是最终产品能完成的功能的一个子集。这个模型的优点是软件产品的开发

基本上是线性顺序进行的。

喷泉模型主要用于面向对象软件技术开发项目,其特点是各项活动之间没有明显的界限。由于面向对象技术的优点,该模型软件开发过程与开发者对问题认识和理解的深化过程同步。该模型重视软件研发工作的重复与渐进,通过相关对象的反复迭代并在迭代中充实扩展,实现了开发工作的迭代和无间隙,该开发过程分为:分析、设计、实现、确认、维护和演化。

三软件项目计划的实际应用模式如下:

1.项目采用 Microsoft Word 拟定计划文档,以 Microsoft Project 拟定计

划的进度表。

2.项目经理根据项目软件需求进行估算,确定进行项目选择的生命周期、

项目规模、所需的人员、时间、进度、资源、风险等内容。将估算的结

果形成估算过程文档,并拟定软件开发计划。

3.软件开发计划内容包含:软件项目计划、迭代计划、进度时间表、配置

管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计

划、产品验收计划、问题解决计划、测试计划。

4.估算过程文档和软件项目计划文档必须通过相关组的审查,以获得相关

组及个人的支持,包括:系统分析组、设计组、编码组、测试组、质量

保证组、配置管理组、文档管理中心及个人。通过审查,发现并修正项

目估算和项目计划的偏差。只有获得了支持,软件项目组在开发过程中

才能尽量避免或消除风险。

5.在高层管理者复审通过后,项目经理指定人员或参与拟定软件开发计划

其它部分,并由相关组和个人复审。

6.配置管理人员将软件开发计划文档纳入配置管理。

7.实际项目中应用的文档有:

制定项目计划流程定义、项目估算流程定义、项目评估表、资源评估表、软件开发计划模板(包括:软件项目计划、迭代计划、配置管理计划、质量保证计划、需求管理计划、项目评测计划、风险管理计划、产品验收计划、问题解决计划、测试计划)、进度时间表、制订软件开发计划的指南。

综上所述,SPP阶段需要制定的计划不仅仅是进度计划,也包括需求管理计划(对需求如何管理,变更如何控制,谁来评审这些变更,如果变更了要怎么办),进度计划,配置管理计划(项目所有的交付件包括可交付的产品和中间的交付物等如何归档,如何变更,如何控制等),风险管理计划(项目开展中会碰到哪些风险,目前有哪些不确定因素后面可能发生,这些风险如何应对,假使风险发生如何处理,如何预防这些风险等等),资源配置计划(项目开展过程中需要哪些资源,包括办公用品,电脑,机器等等,这些资源何时提供,怎么分配,怎么管理等),等等这些都是项目计划要考虑的,比较复杂的内容,计划阶段会考虑所有的东西,甚至可能要包括利益关系人管理计划(比如识别项目的利益关系人,这些人应该如何管理,如何及时向他们汇报项目的信息等)。

总进度计划编制说明

进度计划编制说明(版)

施工总进度计划编制步骤

文件4:进度计划编制说明

项目进度管理研究报告

IT项目进度管理对策论文

项目管理心得—进度控制

项目进度管理学习心得体会

PMP项目进度管理测试

项目管理进度报告摘要

浅谈项目进度管理之计划编制
《浅谈项目进度管理之计划编制.doc》
将本文的Word文档下载到电脑,方便编辑。
推荐度:
点击下载文档
点击下载本文文档