[已答]
网站开发项目，根据合同，如何制定交付计划，交付计划包含哪些文档。
提问人： 柴方军 [富士康科技集团|||富士康]
提问时间：2014-07-04
提交回复
1.依据合同制定项目章程2.明确干系人，收集需求，确定需求3.制定范围管理计划和范围基准4.把WBS明确到活动，排列活动顺序，估算活动持续时间5.获取资源，分配资源到活动上，6.计算成本7.制定风险管理计划和应对措施8.沟通管理计划和干系人管理
1. 明确合同约定2. 明确工程进度特点和交付要求3.部分交付，部分验收,最后整体评价
首先：熟读客户界面合同，搞清楚交付内容、交付范围、客户要求的完工日期；然后：根据合同内容用“关键路径法”制定项目主交付计划；最后：与项目组各部门关键负责人一起，制定详细的支撑计划，包括人力资源、预算、分包、采购、物流、工具等各个细化项。
首先要制定具备交付条件的所有工作流程，再者就是逐项完成各项计划
回复会员： 风车在线 回复时间：2014-08-31
学习了，谢谢！
首先应明确合同时间要求,再合理分配资源,确定计划
学习了，谢谢
前期调研、流程很重要啊
确定交付内容，交付内容需要说明清楚，逐项确认。交付文档包含：网站的设计文档、功能说明书，网站部署文档、网站的架构文档等
不好意思 新手任务
审阅合同--竣工已完成---组织验收准备相关资料（洽商变更涉及费用的单子）网上查一下很多的
1、合同范围2、技术参数3、现场服务4、交付时间、地点5、监造、验收、包装6、违约责任7、备品备件8、其他
在项目初期就要与客户商定好交付计划，包括交付产品范围（功能要求、性能要求），交付时间，交付地点，交付方式，接收人员以及交付时所需的客户环境。
在项目的技术方面及合同方面全面摸清摸透彻，并制定合理的项目计划，记住一定是详细的项目计划，关键路径出来了，然后就按照技术及合同要求执行，交付的事情也就水到渠成啦。
根据合同要求，根据项目目标，范围，确定整体的项目计划，再根据不同的项目阶段，配合项目资源 ，确定明细的项目计划
按照实际的东西去实施
依照合同计划和项目经验。 依照合同计划和项目经验。
前期调研、流程很重要
回复会员： amy07 回复时间：2014-07-11
依照合同计划和项目经验。
首先先根据合同要求，及客户主观意见进行分析，然后开展制定开展计划，与实施过程中所需材料及人力财力支援，最后订立工期，交付
新手做任务，抱歉打扰了
我不知道 不懂哈
根据需求调研和分析，明确业务范围，明确开发范围，确定好和其它系统的边界，任何根据具体内容、投入人力等因素合理估算项目进度，制作交付计划。
根据项目实际情况，制定相应的计划。
个人粗浅认为可以这样做：1、按照合同计划进行目标任务分解（合同中应该规定了交付内容及形式），按照阶段（时间）或者按照模块（功能）相结合进行任务划分，列清所有需要做的事情，包括规划、开发、测试、用户演示、验收交付等。2、按照合同工期进行任务倒排（需要考虑任务、人力之间的并发或者串行），将所有任务合理分配到合同计划时间段内，同时最好预留5-10的时间以应付风险任务。3、对分解后的任务安排人力，通常会遇到配置人员能力不能满足项目经理的需求，因此需要在项目中同时考虑人员培养计划（对于项目工期较长的项目可以考虑），以保证后期人力需求。4、申请人力、资金、项目奖励计划、集中办公地点、便利的通信途径，将这些内容一并列入项目计划中。
还打不错，学习了。
个人理解：在项目初期就要与客户商定好交付计划，包括交付产品范围（功能要求、性能要求），交付时间，交付地点，交付方式，接收人员以及交付时所需的客户环境。
按时间按内容按计划的提交
我也不知道
文档和交付物提供了对正在开发中的系统的描述，同时也是进度的重要指标。它们是管理者关注的焦点，因为它们标志着软件生命周期中每个阶段的切换点。其中，下面的这些文档和交付物是管理者尤其关注的：l 需求与功能说明l 操作概念性文档l 软件开发/管理计划l 需求分析报告l 概要设计报告l 详细设计报告l 测试计划l 用户手册l 系统说明l 软件开发历史记录l 系统交付磁带——软件产品、支持文件及工具等 一个软件开发项目的文档和交付物是软件生命周期中的关键。图4-1显示了个阶段必须完成的文档和交付物。在某些情况下，初始的版本完成后，需要继续更新。在软件生命周期中的任何时候，管理者都要能够确定应该准备哪些文档和交付物了。本节给出了各种文档的建议的格式，还有评估文档完成情况的管理准则。a: 概要设计报告演变为详细设计文档。详细设计中的描述性材料成为系统说明的基础。在用户手册中则包括了应用了具体编程语言program designlanguage (PDL)并附上了最终的用户界面及操作场景、性能资料的详细设计文档。建议的文档内容 对于每个文档，都给出了建议的格式与内容，除了已经在第2节单独介绍过的“软件开发/管理计划”。各文档的实际的内容可能会与这里给出的提纲有一些出入。具体的项目开发环境使得管理者根据自己的判断选择更加有效与贴切的文档内容。学习下面这些图表时必须想着这种伸缩性是允许的。(P.S. 这里还有一些具体的文档格式，将在后面的文章中陆续给出）已完成文档的评估准则 软件项目的管理者应该严格地审核已完成的文档。这里会给出一些通用的准则，判断被审核的文档在以下五个方面的完整程度，这五个方面是一个成功的文档所应具备的五个基本属性。准确性（Accuracy）l 文档正确吗？l 是否有明显的错误？l 对资源和环境的假设是否可行？l 是否对问题或过程的某些重要方面有明显的理解不充分的地方？清晰性（Clarity）l 文档是否采用了易读并易于理解的格式？l 所用的表格和图表是否能清晰表达文字的意思？完整性（Completeness）l 根据文档的用途不同，是否把应该相关的信息都包括了？l 是否省略了一些必要的信息？l 当一个文档是从上一个开发阶段演进来的，其是否包括了之前阶段的所有的元素？一致性（Consistency）l 同一个文档中是否前后矛盾？l 各种符号是否表达了标准的含义？详细程度（Level of detail）l 某个用途的文档是否反映了该用途的所有细节？l 在某个特殊的方面是否还需要更多的描述？ 以下的问题可以被用来分析各文档的完成与质量的必备因素。需求与功能描述记录下的需求中的所有的假设条件是否都包含在了功能描述中？是否所有的记录下的需求与功能描述都是可试验的？是否包括了性能需求？是否明确了哪些需求与功能是与现有的系统是相同的或近似的？操作概念性文档操作场景是否真实？每个与需求对应的操作概念是否清晰？需求分析报告是否低估了待确定（TBD）的需求的影响？可重用的软件中还有哪些源代码可以使用？资源是否充足？概要设计报告是否所有的功能描述都已分割到了子系统？是否所有的界面都易于理解？选中的设计方案是否被证明是合理的？子系统的划分是否恰当？详细设计文档基本的图表是否细化到了子任务的级别？是否对所有的外部文件的内容和格式（直到byte级别）作了描述？是否已经解决了所有的待确定（TBD）的需求问题？如果按照此设计进行开发，最终的系统是否满足需求？是否还有隐蔽信息（information-hiding）的蛛丝马迹？比如局部数据的使用与访问？各模块之间是否是低耦合（low couple）的？各模块是否是内聚的（cohesive）？（P.S. 低耦合、高内聚是模块设计的一个基本要求）测试计划测试是否描述了期望的结果？测试是否是可重复的（repeatable）？例如，测试是否对软件安装步骤和环境进行了足够的描述，以便两个不同的人可以根据这些描述达到同样的效果。测试过程对于软件功能范围的覆盖程度如何？判断测试结果是否正确时，有没有特殊的、严格的要求？按照可用的测试资源，测试进度是否合理？用户手册是否通俗易懂？其内容的编排形式是否能同时被不同的用户群接受？是否有举例？对输入的描述是否足够详细？对状态信息、错误信息、恢复信息等是否有解释？系统说明是否能做到，文档的内容结构既适合于浏览系统的人，也适合于想查询系统细节的人？系统的范围是否明确？与其它系统的联系是否有解释？软件开发历史记录是否有能够标明何时做出软件规模、工作量、时间进度及成本估算的更新清单？是否所有的问题领域都已经过讨论？
如何制定交付计划 (咨询专家：陈和兰) [已答]
专家回复
