软件项目进度周报 项目进度软件
如何安排软件项目的进度？
制定软件项目进度表有两种途径：其一是软件开发小组根据提供软件产品的最后期限从后往前安排时间；其二是软件项目开发组织根据项目和资源情况制定软件项目开发的初步计划和交付软件产品的日期。
多数软件开发组织当然希望按照第二种方式安排自己的工作进度。
然而遗憾的是，大多数场合遇到的都是比较被动的第一种方式。
在软件项目管理工作中，对软件项目的进度安排有时比对软件成本的估算要求更高。
成本的增加可以通过提高产品定价或通过大批量销售得到补偿，而项目进度安排不当会引起顾客不满，影响市场销售。
软件项目的进度安排必须妥善处理以下几个问题： 1、任务分配、人力资源分配、时间分配要与工程进度相协调 在小型软件开发项目中，一个程序员能够完成从需求分析、设计、编码，到测试的全部工作。
随着软件项目规模的扩大，人们无法容忍一个人花十年时间去完成一个需要十几个人年才能完成的软件项目。
大型软件的开发方式必然是程序员们的集体劳动。
由于软件开发是一项复杂的智力劳动，在软件开发过程中加入新的程序员往往会对项目产生不良影响。
因为新手要从了解这个系统和以前的工作做起，当前正在从事这项工作的“专家”不得不停下手中的工作，抽出时间对他们进行培训。
于是，在一段时间内，工作进度便拖后了。
软件开发人数的增加将导致信息交流路径和复杂性的增加，项目进行中盲目增加人员可能造成事倍功半的效果。
适用于大型项目的Rayleigh-Norden曲线[4]表明，完成软件项目的成本与时间的关系不是线性的，使用较少的人员，在可能的情况下，相对延长一些工作时间可以取得较大的经济效益。
然而值得指出的是，程序员小组的正常技术交流能改进软件质量，提高软件的可维护性，减少软件错误，降低软件测试和正确性维护的开销。
任务、人力、时间三者之间存在最佳组合，必须引起项目负责人的足够重视。
2、任务分解与并行化 软件工程项目既然需要软件开发人员集体的劳动，就需要采取一定的组织形式，将软件开发人员组织起来。
软件人员的组织与分工是与软件项目的任务分解分不开的。
为了缩短工程进度，充分发挥软件开发人员的潜力，软件项目的任务分解应尽力挖掘并行成分，以便软件施工时采用并行处理方式。
3、工作量分布 用前几节介绍的软件估算技术可以估算出软件开发各个阶段所需要的工作量，通常用人月或人年表示。
软件在需求分析和设计阶段占用的工作量达到总工作量的40%~50%，说明软件开发前期的活动多么重要。
当然这也包括分阶段开发原型的开销。
大家熟悉的编码工作只占全部工作量的10%~20%，而软件测试和调试的工作量占到总工作量的30%~40%。
这对于保证软件产品质量是十分必要的，实时嵌入式系统软件的测试和调试工作量所占的比例还要大些。
4、工程进度安排 软件项目的工作安排与其他工程项目的进度安排十分相似，通常的项目进度安排方法和工具稍加改造就可以用于软件项目的进度安排。
目前，程序评估与审查技术（PERT）和关键路径方法（CPM）是两种比较常用的项目进度安排方法。
两种方法都生成描述项目进展状态的任务网络图。
网络图中按一定的次序列出所有的子任务和任务进展的里程碑，它表示各子任务之间的依赖关系。
网络图也是作业分解结构（WBS）的发展。
20世纪70年代，作业分解结构就已广泛应用于航天、航空、航海、雷达、通信、火控系统等领域的基于计算机项目的分解，并用以命名各项子任务，这些子任务不仅可以用网络图的形式表示，还可以用树型或层次结构图表示。
PERT和CPM方法为软件规划人员提供了定量描述工具，包括： ①关键路径。
完成关键路径上所有任务时间的总和，就是项目开发所需要的最短时间。
②用统计模型估算开发每个子任务需要的工作量和时间。
③计算各子任务的最早启动时间和最迟启动时间，即确定启动子任务的时间窗口边界。
某个子任务的最早启动时间被定义为该子任务的所有前导任务完成的最早时间。
反之，某个子任务的最迟启动时间被定义为在保证项目按时完成的前提下，最迟启动该子任务的时间。
与最早启动时间和最迟启动时间对应的概念是最早结束时间和最迟结束时间。
它们分别是最早启动时间和最迟启动时间与完成该子任务所需要时间的和：在任务进度安排过程中，应先寻求关键路径并在关键路径上安排一定的机动时间和节假日，以便应付意想不到的困难和问题。
采用这些工具可以大大减轻软件项目管理人员在制定软件项目进度表方面的工作量，并可提高工作质量。
请用软件项目管理角度分析,某软件公司一个大型项目进度失控的原因 ...
这问题刚回答过，怎么没提示？重新提交如下：1、进度失控分析：任务本身估算出现偏差，WBS本身存在问题；项目需求偏移也有可能，毕竟项目中需求把控是影响进度的另一大诱因；进度控制松紧不一致在项目进行到一半时常常才发现时间不够用，进度表经过调整后，谁知道没过多久进度表滞后又来了。
原因在于项目开始时前期太过拖沓，导致进度远远落后于进度表；项目组组建方面一定有问题；项目是各级一把手工程，既然是大型项目，则一定要构建好三层或多层项目组架构；项目沟通计划未得到有效管理：例会、周报、月度进度会等；干系人管理不到位；拖期后未及时采取措施，实施变更加强，以至于分工存在混淆，项目工作拖拉，难以持续；进度控制循环未建立，其包括：(1)执行计划的事前进度控制，体现对计划、规划和执行进行预测的作用；(2)执行计划的过程进度控制，体现对进度计划执行的控制作用，以及在执行中及时采取措施纠正偏差的能力；(3)执行计划的事后进度控制，体现对进度控制每一循环过程总结整理的作用和调整计划的能力；项目监控及应急机制未真正建立；2、下步行动计划：分析存在问题并解释下步安排计划，向公司高层申请项目暂停；（可选）详细了解项目进展状况，写出项目执行报告及总结；明确项目目标，锁定需求，避免无休止的变更；重新规划项目组成员；建立项目高层委员会；执行项目过程控制机制，重新订立项目沟通汇报秩序：周报、月报等，明确高层分工；制定新的项目执行主计划，重新做项目WBS;重新制定奖惩制度；关键干系人和各级一把手都要缜密考虑；如果需要赶工，制定赶工计划与所需资源，制定成本预算报批；申请项目变更；重新召开项目动员会，请一把手出面造势，稳定人心，措施发布，切中要害；项目赶工……3、当然，如果不得已需要有人承担责任，而项目经理要被撤换，则需要制定好交接程序；
什么是项目进度管理软件？
1、项目组长或项目经理，一定对整个项目的开发周期有一个清楚的了解，把任务的划分一定要一天为单位，不要一模块为单位，而每天无论是开发人员还是测试人员，都要对自己的工作有一个大致的估计。
即每天下午，有项目组长组织开发人员进行系统的了解，并且作好相应的记录。
对已经解决的问题一定要一个详细的记录。
而对没有解决的问题一定要重视起来。
不要向后退。
找到根本的原因所在。
2、沟通和交流，作为项目组长一定要多多与开发人员进行交流，要调动其的积极性，让他们学会问题该如何解决，不要让他等待问题的解决。
了解其实际的进展以及对开发工具的熟练程度，这对以后的任务的重新安排有重要的借鉴意义。
3、把一些难点提出，让大家共同克服，或者有一些技术比较精通的人来解决。
解决完以后一定，让大家都熟悉其编程思路。
而对经常用的知识点，一定有详细的说明。
这样实现资源的共享。
什么是项目进度管理软件？
1. 项目进度管理是指在项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的管理，是在规定的时间内，拟定出合理且经济的进度计划。
2. 项目管理软件是一种辅助项目管理的手段，起到提供便捷沟通、信息快速传递的作用。
项目管理软件能够便于项目管理者规范化管理项目成员工作汇报。
项目成员利用项目管理软件能够做好工作记录。
3. 可以通过以下方法进行管理：(1)行政管理革新通过上级领导，发布进度指令，进行指导、协调和考核。
利用激励手段（奖、罚、表扬、批评），监督、督促等方式进行进度控制。
(2)合同措施施工材料、设备供应合同中应加进对工期的控制，要有拖期违约金方面的约束条件等。
（4）技术措施①运用网络计划技术编制科学、合理的工程总体工期控制计划，并据此细化材料、设备、加工订货采购计划，专业分包招标计划、进场计划及分阶段进度计划。
日事清可以通过看板按照项目、部门、时间等维度组织团队工作清单，梳理团队任务，创建团队工作计划，让团队工作可视化。
②建立在看板的任务会落实到人，这些任务会自动分解至团队相关成员的个人日程中去，让个人的日程和团队的工作安排打通，实时跟进。
通过这样的方式，使团队有计划、有反馈、有总结、有调整。
(3)管理技术方法主要通过监理工程师的规划、控制和协调。
软件开发项目的进度安排方式有哪些？
软件开发项目的进度安排可以有两种考虑方式。
第一种，系统最终交付使用的日期已经确定，软件开发机构必须在合同规定的时间内安排；第二种，只确定了大致的年限，最后交付使用的日期由软件开发机构根据具体情况确定。
后一种考虑能够对软件开发任务进行细致的分析；能够最好地利用资源，合理地分配工作量，但实际工作中常常遇到第一种情况，问题是软件管理人员如何在规定的期限内分配人力和安排进度。
进度安排的好坏往往影响整个项目的按期完成和用户的使用，如不能按期完成，用户就会不满，而且需向用户赔偿损失。
如作为商品，将会失去市场竞争力。
进度安排的精确性有时比成本估算更重要。
在商品生产的社会中，某种商品的损失往往还可以通过其他商品或分期偿还来承担。
而进度拖延的损失是无法弥补的。
下面就软件开发项目进度安排中的几个问题进行讨论。
1.软件工作的特殊性 制定软件进度与其他工程没有很大的区别，因此使用一般的通用技术和工具即可。
但重点要强调的是软件产品是逻辑产品，这与其他工程不同。
因此当几个人共同完成某项任务时，人与人之间就有一个思想交流问题，称之为通信关系。
通信是要付出代价的，不只是要花时间，同时由于通信中的疏忽常常会使错误增加。
如一个组有4个软件工程师，两两之间进行通信联系，通信路径有6条；对6个软件工程师，则通信路径增加至14条。
因此所付的代价就必然会增加，所以工作组的人员不宜太多，一般3—5人为好，目前国外一般采用主程序员组的制度。
另一点要强调的是软件工作切忌中间临时加人，必须在安排进度时就考虑周到。
2.各阶段工作量的分配 估算出总的工作量以后，就需要一个可以进行各阶段工作量分配的模型。
某一阶段工作量所占的百分比必须根据经验数据确定。
这里要再一次强调，在开发过程中保存的记录将增加经验数据库存，而且将改善今后估算的准确性。
R.S.Pessman提出一种称作40-20-40的工作量分配规则，即前期工作（计划、需求分析、概要设计和详细设计阶段）和后期工作（测试阶段）各占40%，编码阶段占20%。
应该强调要重视前期和后期工作。
前期工作容易被忽视，主要原因是：管理人员认为不开始编码工作就算没有进行，他们不了解前期工作的重要性；技术人员往往也急于编码，认为写出代码任务就算完成了。
后期工作也容易被忽视，认为编码出来就完事了，对测试工作要占这么大的工作量没有思想准备。
所以要制定好进度计划，就要研究软件工作的规律，前期基础工作没做好，将会给后期工作带来很大困难，往往使工程进度一拖再拖，难以坚持，有的不得不中途夭折。
3.制定开发进度 需要涉及的下一个未知量是开发进度。
进度安排是软件计划工作中一项最困难的任务，计划人员要把可用资源与项目工作量协调好；要考虑各项任务之间的相互依赖关系，并且尽可能地平行进行；预见可能出现问题和项目的“细脖子”，并提出处理意见；以及规定进度，评审和应交付的文档。
假设用作变量的开发时间TD按线性变化，而且已经得到了总的开发工作量估算值ED，要求在规定的时间TD内完成，在项目中最好有参加工作的人员平均值M，即M=EDTD，这将是一个非常有用的数据。
遗憾的是在上述算式中，项目的工作量和开发时间不能作为独立的变量。
Books定律描述了这种现象的最极端情况：为误期的软件项目增加人员将会使其进度更慢。
来源：www.examda.com （四） 软件开发组织 有多少个软件开发机构，几乎也就有多少人员的组织机构。
不管这些组织机构是好或坏，一般是不可能轻易改变的。
尽管组织机构的改变不属于软件计划人员的职责范围内的事。
不过，在一个新的软件项目中直接涉及人员的组织问题却是可以，也应该在软件计划阶段加以认真考虑的。
软件项目进度管理如何才能及时、准确地获知项目进展的实际情况？
两方面的因素。
1、软件的功能足够满足，进度管理的全面性，以及项目个性化需求的差异。
简单、易用。
2、项目在使用过程中，对待软件的使用进行流程上和制度上的约束，按周期的将现实数据，真实的反应到系统当中。
自然而然的，期望的进度啊、成本啊以及所有项目上关注的点都可以在软件上体现出来。
软件开发项目进度如何控制？
文主要谈谈影响软件开发项目进度的因素、项目进度控制的目的、常用项目进度控制措施，软件开发项目进度控制中对项目经理而言需要注意的问题和一些工作经验、工作方法。
关键词：项目管理、进度、控制 一、影响软件开发项目进度的因素 要有效地进行进度控制，必须对影响进度的因素进行分析，事先或及时采取必要的措施，尽量缩小计划进度与实际进度的偏差，实现对项目的主动控制。
软件开发项目中影响进度的因素很多，如人为因素、技术因素、资金因素、环境因素等等。
在软件开项目的实施中，人的因素是最重要的因素，技术的因素归根到底也是人的因素。
软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。
常见的问题有以下几种情况： 1、80-20原则与过于乐观的进度控制 80-20原则在软件开发项目进度控制方面体现在：80%的项目工作可以在20%的时间内完成，而剩余的20%的项目工作需要80%的时间。
这个80%的项目工作不一定是在项目的前期，而可能是分布在项目的各个阶段，但是剩余的20%左右的项目工作大部分是在后期。
所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉，使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。
有些领导看到软件交付给用户了，就一块石头落地“总算交差了”，同时又可能撤出一些被认为不必要的人力资源。
但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。
这样的结果是拖延了后期的工作，同时如果软件还不成熟的话，会给用户造成不好的影响。
2、范围、质量因素对进度的影响 软件开发项目比其他任何建设项目都会有更经常的变更，大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧，用户是想改就改，造成需求的蔓延，项目经理有时还不知如何拒绝，加上要说“我能”的心理因素，一般都会答应修改。
这样集少成多，逐渐影响了项目进度。
如果某项工作在进度上表面上达到目标了，但经检验其质量没有达到要求，则必然要通过返工等手段，增加人力资源的投入，增加时间的投入，实际上是拖延了进度。
不管是从横向或纵向来看，部分任务的质量会影响总体项目的进度，前面的一些任务质量中会影响到后面的一些任务质量。
3、资源、预算变更对进度的影响 资源，最主要的还是人力资源，有时某方面的人员不够到位，或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。
还有一个很重要的资源，就是信息资源，如某些国家标准、行业标准，用户可能提供不了，而是需要去收集或购买，如果不能按时得到，就会影响需求分析、设计或编码的工作。
其他资源，如开发设备或软件没有到货，也会对进度造成影响。
预算其实就是一种资源，它的变更会影响某些资源的变更，从而对进度造成影响。
4、低估了软件开发项目实现的条件 低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。
首先是低估技术难度。
软件开发项目团队成员，有时甚至是企业的高级项目主管也经常低估项目技术上的困难。
低估技术难度实际上也就是高估人的能力，认为或希望项目会按照已经制定的乐观项目计划顺利地实施，而实际则不然。
软件开发项目的高技术特点本身说明其实施中会有很多技术的难度，除了需要高水平的技术人员来实施外，还要考虑为解决某些性能问题而进行科研攻关和项目实验； 其次，低估了协调复杂度，也低估了多个项目团队参加项目时工作协调上的困难。
软件开发项目团队成员比较强调个人的智慧、强调个性，这给项目工作协调带来更多的复杂度。
当一个大项目由很多子项目组成时，不仅会增加相互之间充分沟通交流的困难，更会增加项目协调和进度控制上的困难。
另外，企业高级项目主管和项目经理也经常低估环境因素，这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。
低估这些条件，既有主观的原因，也会有客观的原因。
对项目环境的了解程度不够，造成没有做好充分的准备。
5、项目状态信息收集的情况 由于项目经理的经验或素质原因，对项目状态信息收集的的掌握不足，及时性准确性完整性比较差。
另外其它一些原因也会造成这种现象。
某些项目团队成员报喜不报忧，不希望别人知道自己工作的不好的情况，例如软件程序的编制，可能会先编制一些表面的东西，现有界面，看起来好像完成任务了，实际上只是一个“原型系统”或演示系统。
给领导造成比较乐观的感觉。
如果项目经理或者管理团队没有及时地检查发现这种情况，将对项目的进度造成严重的影响。
当然，如果出现这种需要时时刻刻都互相提防的氛围，管理人员就应该从管理的角度，从制度的角度检讨一下，进行改进，让大家实事求是地进行沟通。
温伯格说：“无论你多么聪明，离开了信息，对项目进行成功的控制就是无源之水、无本之木。
” 6、执行计划的严格程度 没有把计划作为项目过程行动的基础，而是把计划放在一边，比较随意去做。
例如对于项目团队内部沟通或外部沟通，在计划中要说明清楚...
软件开发项目进度如何控制呢？
2、项目进度控制主要手段 项目计划书：作为项目进度控制的基准和依据，项目负责人负责制作项目计划书。
项目进度监控人员根据项目计划书对项目的阶段成果完成情况进行监控，如果由于某些原因阶段成果提前或延后完成，项目负责人应提前申请并做好开发计划的变更。
对于项目进度延后的，应当分析产生进度延后的原因、确定纠正偏差的对策、采取纠正偏差的措施，在确定的期限内消除项目进度与项目计划之间的偏差。
项目计划书应当根据项目的进展情况进行调整，以保证基准和依据的新鲜性、有效性。
项目阶段情况汇报与计划：项目负责人按照预定的每个阶段点（根据项目的实际情况可以是每周、每双周、每月、每双月、每季、每旬等等）定期在与项目成员和其他相关人员充分沟通后，向相关管理人员和管理部门提交一份书面项目阶段工作汇报与计划，内容包括： a、对上一阶段计划执行情况的描述 、下一阶段的工作计划安排 c、已经解决的问题和遗留的问题 d、资源申请、需要协调的事情及其人员 e、其他需要处理的问题 这些汇报将存档，作为对项目进行考核的重要材料。
在计划制定时就要确定项目总进度目标与分进度目标；在项目进展的全过程中，进行计划进度与实际进度的比较，及时发现偏离，及时采取措施纠正或者预防；协调项目参与人员之间的进度关系。
在项目计划执行中，做好这样几个方面的工作： 检查并掌握项目实际进度信息。
对反映实际进度的各种数据进行记载并作为检查和调整项目计划的依据，积累资料，总结分析，不断提高计划编制、项目管理、进度控制水平。
做好项目计划执行中的检查与分析。
通过检查，分析计划提前或拖后的主要原因。
项目计划的定期检查是监督计划执行的最有效的方法。
及时制定实施调整与补救措施。
调整的目的是根据实际进度情况，对项目计划作必要的修正，使之符合变化的实际情况，以保证项目目标其顺利实现。
由于初期编制项目计划时考虑不周，或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑，计算调整后的各时间参数、关键线路和工期。
3、进度控制内容 从内容上看，软件开发项目进度控制主要表现在组织管理、技术管理和信息管理等这几个方面。
组织管理包括这样几个内容： （1）项目经理监督并控制项目进展情况； （2）进行项目分解，如按项目结构分，按项目进展阶段分，按合同结构分，并建立编码体系； （3）制订进度协调制度，确定协调会议时间，参加人员等； （4）对影响进度的干扰因素和潜在风险进行分析。
技术管理与人员管理有非常密切的关系。
软件开发项目的技术难度需要引起重视，有些技术问题可能需要特殊的人员，可能需要花时间攻克一些技术问题，技术措施就是预测技术问题并制订相应的应对措施。
控制的好坏直接影响项目实施进度。
在软件开发项目中，合同措施通常不由项目团队负责，企业有专门的合同管理部门负责项目的转包、合同期与进度计划的协调等。
项目经理应该及时掌握这些工作转包的情况，按计划通过计划进度与实际进度的动态比较，定期向客户提供比较可靠的报告等。
软件开发项目进度控制的信息管理主要体现在编制、调整项目进度控制计划时对项目信息的掌握上。
这些信息主要是：预测信息，即对分项和分阶段工作的技术难度、风险、工作量、逻辑关系等进行预测；决策信息，即对实施中出现的计划之外的新情况进行应对并做出决策。
参与软件开发项目决策的有项目经理、企业项目主管及客户的相关负责人；统计信息，软件开发项目中统计工作主要由参与项目实施的人员自己做，再由项目经理或指定人员检查核实。
通过收集、整理和分析，写出项目进展分析报告。
根据实际情况，可以按日、周、月等时间要求对进度进行统计和审核，这是进度控制所必须的。
4、不同阶段的项目进度控制 从项目进度控制的阶段上看，软件开发项目进度控制主要有：项目准备阶段进度控制，需求分析和设计阶段进度控制，实施阶段进度控制等这几个部分。
准备阶段进度控制任务是：向业主提供有关项目信息，协助业主确定工期总目标；编制阶段计划和项目总进度计划；控制该计划的执行； 需求分析和设计阶段控制的任务是：编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划，控制相关计划的执行等。
实施阶段进度控制的任务是：编制实施总进度计划并控制其执行；编制实施计划并控制其执行等。
由甲乙双方协调进度计划的编制、调整并采取措施确保进度目标的实施。
为了及时地发现和处理计划执行中发生的各种问题，就必须加强项目的项目的协同工作。
协同工作是组织项目计划实现的重要环节。
它要为项目计划顺利执行创造各种必要的条件，以适应项目实施情况的变化。
5、关于进度落后时的“赶工”措施 进度落后的情况下，有几种措施来弥补，如加人、加班、加激励等等，这些都是增加资源而又未必会见效的方法。
根据Books原则，在某些项目进度延迟的情况下增加人手，有可能会使项目的进度更加延后。
因为对于新加入本项目的员工来说，对项目相关背景、需求、设计的培训、对项目环境的熟悉和项目团队...
软件项目进度表包含什么内容
一是参考其它项目.另一个现在的可参考项目是安装 Microsoft Office Project 2003， 内有好几个相关模板.供参：项目启动 6 工作日 组建工作组 6 工作日 定义工作组角色 2 工作日 确定所需技能 2 工作日 确定资源 2 工作日 将角色赋予资源 2 工作日 工作组成立 0 工作日 构想 44 工作日 定义初步的商业需求（持续性工作） 29 工作日 风险管理 1 工作日 定义项目结构 9 工作日 定义跟踪项目的步骤 5 工作日 定义解决问题的步骤 4 工作日 定义跟踪问题的步骤 3 工作日 定义控制变更的步骤 4 工作日 定义责任和期望 2 工作日 项目结构确定完毕 0 工作日 研究和收集设想 25 工作日 进行初步的用户访问 2 工作日 定义使用场合 10 工作日 制定初步的用户描述 5 工作日 制定初步的构想说明 1 工作日 确立设计目标 8 工作日 制定初步的解决方案概念 5 工作日 制定初步的项目范围 19 工作日 定义关键的成功因素 2 工作日 定义衡量成功的标准 1 工作日 定义主要的可交付结果（初步） 3 工作日 起草构想/范围 3 工作日 审阅构想/范围 2 工作日 更新构想/范围 3 工作日 缓冲时间 4 工作日 进行里程碑检查 1 工作日 构想得到批准 0 工作日 规划 59 工作日 更新风险评估 1 工作日 进行用户访问 10 工作日 创建功能描述 31 工作日 制定功能描述： 第 0 批 5 工作日 制定功能描述： 第 1 批 5 工作日 制定功能描述： 第 2 批 5 工作日 制定功能描述： 第 n 批 5 工作日 功能描述基准 0 工作日 开发计划 28.25 工作日 创建开发计划 28 工作日 进行概念性设计 10 工作日 进行逻辑设计 15 工作日 进行物理设计 19 工作日 制定开发日程 5 工作日 测试计划 35 工作日 制定测试计划 30 工作日 制定测试日程 5 工作日 用户培训计划 36 工作日 制定用户培训计划 30 工作日 制定用户培训日程 6 工作日 后勤计划 48 工作日 制定后勤计划 43 工作日 进行基础设施分析 15 工作日 制定安全计划 2 工作日 制定部署计划 27 工作日 定购组件 15 工作日 后勤计划完成 0 工作日 创建后勤日程 7 工作日 产品管理计划 18 工作日 制定产品管理计划 14 工作日 制定产品管理日程 5 工作日 程序管理计划 41 工作日 创建程序管理计划 21 工作日 创建程序管理日程 20 工作日 建立项目计划基准 0 工作日 合并项目计划 11 工作日 审阅合并计划 4 工作日 创建合并日程 2 工作日 缓冲时间 4 工作日 确定交货日期 0 工作日 构想/范围冻结 0 工作日 进行里程碑检查 1 工作日 项目计划得到批准 0 工作日 开发 81 工作日 更新风险评估 1 工作日 提供开发所需的设备/检验概念是否达到 0 工作日 建立开发环境/实验室 5 工作日 内部发布 #1 24 工作日 开发目标组件 9 工作日 测试单个组件 5 工作日 测试组装为整体的应用程序 6 工作日 开发增强性能的材料 4 工作日 测试和审查材料 3 工作日 制定分发步骤 9 工作日 创建分发产品 2 工作日 分发给合适的对象 1 工作日 缓冲时间 8 工作日 内部发布 #1 结束 0 工作日 审阅来自内部发布的结果 2 工作日 进行发布后的审阅 1 工作日 内部发布 #n 24 工作日 开发目标组件 10 工作日 测试单个组件 4 工作日 测试组装为整体的应用程序 5 工作日 开发增强性能的材料 4 工作日 测试和审查材料 3 工作日 制定分发步骤 3 工作日 创建分发产品 4 工作日 缓冲时间 6 工作日 分发给合适的对象 1 工作日 内部发布 #n 结束 1 工作日 审阅来自内部发布的结果 2 工作日 功能说明冻结 1 工作日 最后的特性开发 10 工作日 最后的后勤开发 9 工作日 最后的性能支持开发 5 工作日 特性开发结束 0 工作日 更新计划和日程 13 工作日 更新开发计划 4 工作日 更新测试计划 3 工作日 更新后勤计划 13 工作日 更新程序管理计划 3 工作日 更新产品管理计划 3 工作日 更新用户培训计划 6 工作日 缓冲时间 3 工作日 进行里程碑检查 2 工作日 项目范围规划完成 1 工作日 稳定 73 工作日 更新风险评估 1 工作日 发布测试版 1 32 工作日 制定测试版计划 3 工作日 征寻和选择用户 2 工作日 准备测试版产品包 8 工作日 开始测试 0 工作日 提供测试支持 8 工作日 收集用户反馈 7 工作日 结束测试支持 0 工作日 修补缺陷 10 工作日 结束测试 0 工作日 发布测试版 n 1 工作日 修补缺陷 10 工作日 收集错误 1 工作日 改正高优先级的错误 10 工作日 发布无错误版 0 工作日 进行最后的错误分类 5 工作日 发布版候选 1 7 工作日 进行工作组评估 2 工作日 客户/用户评估 2 工作日 支持评估 3 工作日 发布版候选 n 6 工作日 黄金发布版 0 工作日 发布 1 工作日 项目后检查 2 工作日 软件开发：------------------------- 项目范围规划 3.5 工作日 确定项目范围 4 工时 获得项目所需资金 1 工作日 定义预备资源 1 工作日 获得核心资源 1 工作日 项目范围规划完成 0 工作日 分析/软件需求 14 工作日 行为需求分析 5 工作日 起草初步的软件规范 3 工作日 制定初步预算 2 工作日 工作组共同审阅软件规范/预算 4 工时 根据反馈修改软件规范 1 工作日 确定交付期限 1 工作日 获得开展后续工作的批准（概念、期限和预算） 4 工时 获得所需资源 1 工作日 分析工作完成 0 工作日 设计 14.5 工作日 审阅初步的软件规范 2 工作日 制定功能规范 5 工作日 根据功能规范开发原型 4 工作日 审阅功能规范 2 工作日 根据反馈修改功能规范 1 工作日 获得开展...
-