软件项目计划的计划制定
展开全部项目计划详细说明了所需软件工作及如何实现。
它定义了每一个主要任务,并估算其所需时间和资源,同时为管理层的评估和控制提供了一个框架。
项目计划也提供了一种很有效的学习途径。
如果能合理建档,它便是一个与实际运行效能比较的基准。
这种比较可以使计划者看到他们的估算误差,从而提高其估算精确度。
我们着重强调对项目规模和资源的估算,是因为低质量的项目资源估算将不可避免地造成资源短缺,进度延迟和预算超支。
又由于项目资源估算是从软件规模估算中直接衍生出来的,所以低质量的规模估算是造成许多软件项目问题的根本原因。
项目计划应在项目开始初期制定出,并随着工程的进展不断地加以精化。
起初,由于软件需求通常是模糊而又不完整的,我们的工作重点应在于明确该项目需要哪些领域的知识,并且如何获取这些知识。
如果不遵循这一指导原则,程序员们通常会积极地投入到那部分已知的工作中去,而把未知部分留滞到以后。
这种工作方式通常会产生很多问题,因为未知部分具有最高的风险系数。
软件项目计划的逻辑如下所述 :由于软件需求在初始阶段是模糊而又不完整的,质量计划只能建立在对客户需求的大致而不确切的理解之上。
因此,项目计划应该从找出含糊不确切与准确恰当的软件需求间的映射关系入手。
接着建立一种概念设计。
项目初始架构的建立要十分谨慎,因为它通常标定了产品模块的分割线,同时描述了这些模块所实现的功能及所有模块间的关系。
这就为项目计划和项目实施提供了组织框架,因此一个低质量的概念设计是不能满足要求的。
在每一次后续的需求精化时,也应同时精化资源映射,项目规模估算和工程进度。
软件项目计划-制订软件项目计划的方法与策略制订软件项目计划的目的在于建立并维护软件项目各项活动的计划,软件项目计划其实就是一个用来协调软件项目中其它所有计划,指导项目组对项目进行执行和监控的文件。
一个好的软件项目计划可为项目的成功实施打下坚实的基础。
软件项目有其特殊性,不确定因素多,工作量估计困难,项目初期难于制定一个科学、合理的项目计划。
我曾主持和参与过大大小小的软件项目十余项,下面我将把我制订软件项目计划的经验分享给大家。
1.注重项目计划的层次性软件项目计划的层次及其关系如下图所示。
高级计划,是项目的早期计划。
高级计划应当是粗粒度的,主要是进行项目的阶段划分,确定重大的里程碑,所需相关的资源,包括人力资源、设备资源、资金资源,即所谓的人、财、物三个要素。
大的阶段交替之前,应做好下一阶段的详细计划,我们称之为二级计划。
详细计划要确定各项任务的负责人,开始时间,结束时间,任务之间的依赖关系,设备资源,小的事件点(即里程碑)。
如果项目规模相对较大,可以有多级的计划,比如说,一个项目组可能分为几个开发组,二级计划是各开发组制订的适合的自己小组的计划。
如果开发组还分了小组,可以有小组的三级计划。
开发人员的个人计划是低级计划,由开发人员根据自己的任务自行制定,要把任务细化到人·日。
一般的,软件项目计划至多有四级就够了,过多的等级将会引发效率的瓶颈。
大的项目不见得要有庞大的组织和人员数量来支撑,合理的划分小组,减少组织的层次,有利于项目计划的制订和实施。
较小的软件项目由于工期不长,人员较少,有二级计划(高级计划与低级计划)也是可行的。
2.重视与客户的沟通与客户的沟通是很重要的。
不必害怕客户知道我们的开发计划,特别是项目进度情况,应当和客户共享这些信息。
首先,客户会提出一些对项目时间、进度、效果上的要求,这个指标往往经不起推敲,有的还带有较强的政策性。
如:在我主持的一个某单位人nnerlink>MIS系统的开发中就发现,客户方对时间上的约束是有成形的文件的,是他们单位领导们开会的决定。
客户给出的从项目启动到验收的时间只有三个月,但是,经过我们认真的需求调研,做出项目进度的粗计划和部分的二级计划后,发现三个月的时间是难于实现的。
我们把做出的调研文档和项目计划摆出来和和客户讨论,最终使项目的开发时间延长为六个月。
站在为了科学地分析和解决问题的立场上来看,项目组和客户的目的是一致的,所以对于合理的项目进度客户是会理解与支持的。
其次,我们有义务要让客户知道项目的计划。
这样才能让客户和用户主动、积极参与项目,达到项目的最终目标。
项目计划取得双方签字认可是一种好的习惯。
客户可能不愿意签正式的文件,那么在文档的封面上签上双方负责人的姓名、联系方式也行,虽然是非正式的,但留下了项目工作的痕迹。
有必要想办法让客户清楚签字意味着什么。
这就意味说双方有了一个约定,既让用户感觉心里踏实,也让自己的项目组有了责任感,有一种督促和促进的作用。
3.该详细的详细,该简略的就简略软件项目计划就如同软件项目本身一样有它特殊性,一个三五个人花两三个月就可以完工的小项目,可能项目计划就四五页纸,包括一个WBS(工作分解结构)和一个Gantee图(甘特图)。
一个需要五六十个人甚至上百人,要花上半年或更...
如何制定项目计划
是的,制定项目计划,确实是不难。
但是要制定出科学合理,且在项目进行中真正起到指导和控制项目进度的计划,绝非易事。
为什么这么说,因为大多数项目经理在制定计划的时候,忽略了两个关键的因素:态度和方法。
首先说态度。
很多项目经理都不想花太多的时间在计划上,这类项目经理一般都是项目冠军类的,技术骨干,有丰富的项目经验,更看重action。
因为他们认为计划不如变化快,项目具有太多的未知性,所以就算计划作得再漂亮,有了变化都需要他们以往的经验来解决。
因此,他们作计划一般只是为了满足立项的checklist。
他们并不会严格按照schedlue 来控制项目进度。
事实上,项目大多数也无法按照schedule来进行,理由是制定schedule时考虑不全面,导致schedule不够合理和客观。
正因为如此,立项之后,项目进度经常delay。
通常最先,进度一delay,项目经理就更新schedule。
这时,Schedule对于项目进度而言,已经没有任何指导和控制的意义,项目经理只是为了作计划而计划。
到了项目进行到后阶段,项目小组已经不看计划了。
其次是方法。
现在越来越多的项目,都不止一个部门参与合作。
项目经理在制定进度计划的时候,通常只给出了各部门的独立进度计划。
然而项目是作为一个整体在进行,如果没有理清楚各部门之间的逻辑关系,就佷难制定出一个系统的项目schedule。
当项目进行到交互界面的时候,由于各部门的输入输出不明确,导致部门间可能相互等待,从而影响项目进度。
那么,如何才能制定出科学合理的项目计划呢?第一, 项目经理端正态度,重视项目计划制定。
PMI里提到:经过统计分析得出,当投入在项目规划的时间为项目总时间的十分之一的时候,项目成功的概率最高。
这里提到的项目规划除了包含各模块的设计、项目管理计划之外,还包含项目schedule。
第二, 正确理解《产品定义》,将BU提供的产品定义,转化成《项目范围说明书》。
即包含:主要的可交付成果、项目目标描述。
完成后必须跟BU确认。
第三, 项目经理安排将投入到项目中的各职能部门负责人梳理出:各部门所包含的活动list。
具体要求包含:1、每项活动的执行人;2、每项活动的持续工作日;3、每项活动的输入和输出。
第四, 制定进度表。
1、根据各部门提供的活动的输入和输出,得到活动排序;2、根据每项活动持续的时间,方可得到初步的项目schedule;3、项目经理跟各部门负责人确认后,得到最终的项目schedule。
如何制定项目战略计划
制定项目战略计划:1、外部因素分析:(1)外部因素分析内容a)宏观环境分析宏观环境指产生于企业操作范围之上,不受企业运营状况影响的因素,分析时通常应了解:政治环境、经济环境、法律环境、文化环境、科学技术环境等。
b)市场及行业因素分析市场及行业因素指能影响企业的竞争行为和在特定行业中获利性的因素,分析时通常考虑:市场供需状况、行业发展趋势、行业特性和结构、消费者行为、竞争对手、替代品等。
(2)外部分析具体步骤和方法a)宏观环境分析(PEST框架)b)行业驱动力分析2、内部因素分析:(1)内部因素分析原则和范围a)内部因素分析的原则-确定对企业可能造成关键影响的内部因素-在鉴别企业内部的关键因素时,对销售额、成本、利润的分析是必不可少的b)关键内部因素分析范围包括:营销;生产、运营和技术;人力资源;质量管理;信息体系;组织和管理体系等。
(2)确定所需数据、资料的来源。
(3)内部因素分析方法:方法一:市场定位/行业吸引力模型; 方法二:内部价值链分析;(4)总结内部因素分析并得出结论:明确为企业资源增值做出贡献的环节;这些环节内部核心能力的形成过程;企业的优势和劣势等。
如何利用Project软件编制项目计划
展开全部 使用Project软件的最大目的是编制计划与跟踪计划,而且为了能够精细化的跟踪计划的变化过程,计划的科学合理的编制是前提条件。
在一般的项目管理要求中,也许不会要求上述计划全部编制出来,但是最起码的进度计划、资源计划、成本计划是在大多数项目管理要求中被提到的。
用Project软件便可以很方便的帮助您编制出上述三个计划。
本文介绍大致的计划编排顺序,详细的步骤和技巧请参考本网站其他的条目信息。
进度计划编制顺序: 2,做任务分解(WBS),就是把你项目分解成一系列需要完成的任务,这些任务是按照某种层次结构来划分的,所以叫WBS(work breakdown structure)。
在分解的过程中可以进行升降机操作。
3,设置任务的工期,每个任务需要执行的时间跨度是多大,注意不是工作量,是时间周期。
4,设置任务之间的逻辑关系,尽量不要手工的设置任务的开始时间或者完成时间,而应该让Project根据任务的逻辑关系来自动安排时间,以便检查我们的计划是否合理。
5,寻找出关键路径,关键路径对于计划的监控尤为重要,如果关键路径不能够正确完整的展现,说明计划编制的有问题,并且对将来的监控会带来很大的困难。
6,进度计划的优化与调整。
费用计划的编排顺序: 1,建立资源信息,包括人力资源、设备资源、材料资源、成本资源等信息 2,分配资源到任务上,可以给一个任务分一个资源,可以批量分配 3,查看分配是否出现冲突,如果出现冲突进行调整 4,资源计划的优化与调整 成本计划的编排顺序: 1,设置成本资源的类型,也就是费用的科目,例如差旅费、交通费等等 2,将成本资源分配到任务上,由Project自动计算出每个摘要任务、阶段、项目的总体费用 3,进行成本计划的优化 述三种计划编制完成后,需要进行整体优化调整。
...
如何安排软件项目的进度?
制定软件项目进度表有两种途径:其一是软件开发小组根据提供软件产品的最后期限从后往前安排时间;其二是软件项目开发组织根据项目和资源情况制定软件项目开发的初步计划和交付软件产品的日期。
多数软件开发组织当然希望按照第二种方式安排自己的工作进度。
然而遗憾的是,大多数场合遇到的都是比较被动的第一种方式。
在软件项目管理工作中,对软件项目的进度安排有时比对软件成本的估算要求更高。
成本的增加可以通过提高产品定价或通过大批量销售得到补偿,而项目进度安排不当会引起顾客不满,影响市场销售。
软件项目的进度安排必须妥善处理以下几个问题: 1、任务分配、人力资源分配、时间分配要与工程进度相协调 在小型软件开发项目中,一个程序员能够完成从需求分析、设计、编码,到测试的全部工作。
随着软件项目规模的扩大,人们无法容忍一个人花十年时间去完成一个需要十几个人年才能完成的软件项目。
大型软件的开发方式必然是程序员们的集体劳动。
由于软件开发是一项复杂的智力劳动,在软件开发过程中加入新的程序员往往会对项目产生不良影响。
因为新手要从了解这个系统和以前的工作做起,当前正在从事这项工作的“专家”不得不停下手中的工作,抽出时间对他们进行培训。
于是,在一段时间内,工作进度便拖后了。
软件开发人数的增加将导致信息交流路径和复杂性的增加,项目进行中盲目增加人员可能造成事倍功半的效果。
适用于大型项目的Rayleigh-Norden曲线[4]表明,完成软件项目的成本与时间的关系不是线性的,使用较少的人员,在可能的情况下,相对延长一些工作时间可以取得较大的经济效益。
然而值得指出的是,程序员小组的正常技术交流能改进软件质量,提高软件的可维护性,减少软件错误,降低软件测试和正确性维护的开销。
任务、人力、时间三者之间存在最佳组合,必须引起项目负责人的足够重视。
2、任务分解与并行化 软件工程项目既然需要软件开发人员集体的劳动,就需要采取一定的组织形式,将软件开发人员组织起来。
软件人员的组织与分工是与软件项目的任务分解分不开的。
为了缩短工程进度,充分发挥软件开发人员的潜力,软件项目的任务分解应尽力挖掘并行成分,以便软件施工时采用并行处理方式。
3、工作量分布 用前几节介绍的软件估算技术可以估算出软件开发各个阶段所需要的工作量,通常用人月或人年表示。
软件在需求分析和设计阶段占用的工作量达到总工作量的40%~50%,说明软件开发前期的活动多么重要。
当然这也包括分阶段开发原型的开销。
大家熟悉的编码工作只占全部工作量的10%~20%,而软件测试和调试的工作量占到总工作量的30%~40%。
这对于保证软件产品质量是十分必要的,实时嵌入式系统软件的测试和调试工作量所占的比例还要大些。
4、工程进度安排 软件项目的工作安排与其他工程项目的进度安排十分相似,通常的项目进度安排方法和工具稍加改造就可以用于软件项目的进度安排。
目前,程序评估与审查技术(PERT)和关键路径方法(CPM)是两种比较常用的项目进度安排方法。
两种方法都生成描述项目进展状态的任务网络图。
网络图中按一定的次序列出所有的子任务和任务进展的里程碑,它表示各子任务之间的依赖关系。
网络图也是作业分解结构(WBS)的发展。
20世纪70年代,作业分解结构就已广泛应用于航天、航空、航海、雷达、通信、火控系统等领域的基于计算机项目的分解,并用以命名各项子任务,这些子任务不仅可以用网络图的形式表示,还可以用树型或层次结构图表示。
PERT和CPM方法为软件规划人员提供了定量描述工具,包括: ①关键路径。
完成关键路径上所有任务时间的总和,就是项目开发所需要的最短时间。
②用统计模型估算开发每个子任务需要的工作量和时间。
③计算各子任务的最早启动时间和最迟启动时间,即确定启动子任务的时间窗口边界。
某个子任务的最早启动时间被定义为该子任务的所有前导任务完成的最早时间。
反之,某个子任务的最迟启动时间被定义为在保证项目按时完成的前提下,最迟启动该子任务的时间。
与最早启动时间和最迟启动时间对应的概念是最早结束时间和最迟结束时间。
它们分别是最早启动时间和最迟启动时间与完成该子任务所需要时间的和:在任务进度安排过程中,应先寻求关键路径并在关键路径上安排一定的机动时间和节假日,以便应付意想不到的困难和问题。
采用这些工具可以大大减轻软件项目管理人员在制定软件项目进度表方面的工作量,并可提高工作质量。
软件项目计划的目标是什么?
软件项目的进度安排与任何一个工程的进度安排没有实质上的不同。
首先识别一组项目任务,建立任务间的相互关联,然后估计各个任 务的工作量,分配人力和其他资源,指定进度时序。
软件开发任务的并行性若软件项目有多人参加时,多个开发者的活动将并行进行。
Gantt图Gantt图常用水平线段来描述把任务分解成子任务,以及每个子任务的进度按排,该图表示方法简单易懂, 一目了然,动态反映软件开发进度情况。
如下表:进程计划时间表工程网络图工程网络图是一种有向图,该图中用圆表示事件,有向弧或箭头表示子任务的进行,箭头上的数字称为权,该权表示此子任务的持续时间,箭头下面括号中的数字表示该任务的机动时间,图中的圆表示与某个子任务开始或结束事件的时间点。
如下图:软件质量保证 软件质量保证是软件工程管理的重要内容,软件质量保证应作好以下几个方面的工作:(1)采用技术手段和工具。
(2)组织正式技术评审。
(3)加强软件测试。
(4)推行软件工程规范(标准)。
(5)对软件的变更进行控制。
(6)对软件质量进行度量。
如何制定软件测试计划
展开全部 制定计划 1. 分析产品 分析什么 用户(他们是谁,他们做什么的) 操作(这个操作是干什么用的) 产品结构(代码,文件,等) 产品功能(这些功能是干什么用的) 产品数据(输入的,输出的,状态,等) 平台(外部的硬件和软件) 怎么分析 走一下产品/原型的主要流程 评审产品和项目文档 咨询设计人员和用户 与类似的产品做比较 可能的工作产出 产品的功能范围概要 注释性的文档 产品的问题列表 执行状态检查 设计人员有没有确认以及批准了产品的功能范围概要? 设计人员有没有认为你已经正确理解了这个产品? 你能不能将这个产品形象化并且预测正确的行为? 你能不能造出产品的测试数据(输入和结果)? 你能不能配置和操作这个产品? 你有没有理解这个产品是怎么样被使用的? 你有没有注意到设计中的漏洞或不一致的地方? 关于这个产品你还有没有未解决的问题? 2. 分析产品的风险 分析什么 产品受到的威胁 产品的易受攻击的地方 失败的方式 失败后的影响 怎么分析 评审需求和规格说明书 评审出现问题的一些事件 咨询设计人员和用户 通过探索性风险分析和质量判据列表来评审产品 识别基本的错误/失败方式 可能的工作产出 组件风险列表矩阵 失败模型概要 执行状态检查 设计人员和用户有没有对风险分析达成一致? 你有没有发现所有的重要的问题,而这些问题是否在测试过程出现呢? 你是否知道在哪些地方要集中测试精力并获得最大的效率呢? 设计人员有没有做一些事情使得重要的问题更容易的发现,或减少其发生的概率呢? 如果你的风险分析是正确的,你是怎么发现的呢? 3. 设计测试策略 基本策略 Domain testing(包括边界值) 用户测试 压力测试 回归测试 Sequence testing State testing 基于文档的测试 结构化测试(单元测试等) 怎么计划 对于风险和产品功能匹配策略 将特殊的和实际的策略形象化 分析是否可用自动化的机会 使用原型去测试probes和harnesses 不要强加计划,让测试人员自己决定 可能的工作产出 各个类型的报告怎样应用的测试策略文档 风险/任务的matrix 已选择的策略中存在的问题或挑战列表 对产品覆盖比较少的部分提供的建议 测试用例(如果是必须的) 执行状态检查 设计人员对这个测试策略达成一致了吗? 这个策略对于项目每个参与人员以及协助人员都有用吗? 这个测试策略是否很基本了?是否也容易的应用到这个产品中? 这个测试策略是否透露了所以的重要的问题 4. 计划安排 安排的内容 测试时间的评估和计划 易测性的工程分析 测试团队人员(详细的能力) 测试人员的培训和监督 测试人员的任务的指定 产品开发信息的收集和管理 项目会议,沟通,协调的方式 与其他已存在的功能之间的关系,包括开发过程中 测试平台的认购和配置 测试工具盒自动化 需要用到的测试桩和mock 测试套的管理和维护 建立和输出协议约定 测试周期管理 问题报告系统和约定 测试状态报告的约定 代码冻结和增量测试 测试后期的压力管理 项目阶段输出协议约定 测试效率的预估 可能的工作产出 问题列表 项目风险分析 任务和责任matrix 测试时间表 与开发之间的约定和协议 执行状态检查 这个项目所列的安排是否支持测试策略? 是否存在一些问题会阻碍测试的执行? 在可见性的问题面前,这些安排和策略是否适合? 你现在是否开始测试还是以后整理剩下的问题? 5. 分享计划 分享的方式 让设计人员和股东都参与到整个测试计划的制定过程中 更主动的获取关于测试计划的意见 尽最大可能帮助开发人员保持进度 帮助开发人员理解他们做什么会影响测试 与技术支持和写技术文档的人分享产品质量信息 让设计人员和开发人员评审并且批准所以相关的文档 记录并加强与开发之间的约定 让参与人员评审测试计划的细节 在测试计划中尽量减少没必要的信息以增加评审的效率 目标 对于测试过程达到一致的理解来自:领测软件测试网。
我本人觉得挺赞的。
转载请注明出处51数据库 » 如何制定软件项目计划