【精品】软件项目策划规程.doc

【精品】软件项目策划规程 ?应用范围事业中心、项目中心、管理中心。 ?读者对象事业中心、项目中心、管理中心相关人员。 2.角色职责角色名称职责描述高级经理1.评审软件项目计划、软件项目进度计划、软件项目成本计划。 2.担任评审组长。 项目经理、软件经理主导项目策划活动，组织软件项目计划、软件项目进度计划、软件项目成本计划的编写。 咨询工程师、系统架构师、软件工程师、实施工程师1.参与项目策划。 2.参与相关计划评审。 QA工程师1.参与并指导项目策划活动。 2.编制项目质量保证计划。 3.参与所有计划评审。 4.跟踪计划修订情况。 CM工程师1.编制软件配置管理计划。 2.参与相关计划评审。 3.将项目各类计划纳入配置库进行受控管理。 4.发布项目各类计划。 测试工程师1.编制测试计划。 2.参与相关计划评审。 技术总监1.参与软件项目计划、软件项目进度计划评审。 2.审核项目自定义的工程管理类标准或模板。 管理者代表1.参与软件项目计划、软件项目进度计划、软件项目成本计划评审。 2.审核项目自定义的支持工程类标准或模板。 3.批准项目自定义的所有标准或模板。 项目总监1.参与软件项目计划、软件项目进度计划、软件项目成本计划评审。 2.审核项目自定义的项目管理类标准或模板。 人资总监、财务总监参与软件项目成本计划评审。 3.术语定义?PMBOK项目管理知识体系，由美国项目管理学会建立，它包括五个过程组（启动、计划、实施、控制、收尾）；九大知识领域（项目整体管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理、项目采购管理）。 ?WBS工作分解结构，对项目工作的一种针对结果的分析，它定义了项目的范围。 ?行动计划项目策划完成前的计划，用于指导软件项目计划正式发布前的任务分配、人员安排、时间要求等。 ?里程碑由相关人负责、按计划预定、具有零历时的重要事件，通常用于测量工作进度。 ?阶段里程碑指在项目阶段结束时设置的里程碑点，如“精化阶段”结束时标志着“生命周期体系结构里程碑”的到达。 ?关键事件里程碑指不是阶段里程碑，但又非常关键的重要事件，通常于关键路径上那些一旦延期将会对后续工作造成较大影响或客户方要求的重要事件，如需求调研、设备采购、内部验收、专家评审、客户验收等。 ?高级经理指项目的直接上级经理，有可能是事业部总经理、也有可能是总裁或其他高级管理人员。 4.活动规程项目策划是一项贯穿项目全程的活动，并非仅在项目前期才存在，它包括策划准备、项目估计、制定计划、计划评审、计划维护等5项子活动。 项目立项后，项目经理应及早开始项目策划活动，以便及时为后续工作提供指导和执行的依据。 4.1策划准备4.1.1召开启动会议收到经批准的项目立项申请表后，项目经理可根据需要召开项目启动会议，参与人员包括与项目相关的组和个人，如咨询工程师、系统架构师、软件经理、软件工程师、实施工程师、QA工程师、CM工程师、测试工程师、美工等。 启动会议议题可包括但不局限于以下方面1.向与会人员简要介绍项目背景、特性、风险、依赖、约束、合同要求等；2.简要介绍项目相关成员姓名、所承担角色以及工作职责等；3.简要介绍项目组的工作方式及工作流程等；4.共同约定软件开发计划正式发布之前的任务、人员、时间等工作安排，内容可包括需求获取、项目估计、计划编制、计划评审等方面；5.讨论可能出现的问题，尤其是需要与其他部门进行协调的问题。 4.1.2制定行动计划1.项目经理制定策划完成之前的行动计划，并得到本项目高级经理的批准（批准形式不限，推荐采用邮件确认形式），将行动计划通知相关人员。 2.批准之后的行动计划也可根据实际情况进行调整，但每次重大调整均需得到高级经理的再次批准并通知相关人员。 3.高级经理依据批准后的行动计划提供在项目启动之后，计划完成之前的资源。 4.行动计划可在软件项目进度计划中体现。 4.2项目估计4.2.1确定生命周期公司所有的软件项目均采用迭代式生命周期模型进行开发，统一划分为先启、精化、构造、移交四个生命周期阶段。 四个阶段结束时对应的里程碑分别为生命周期目标里程碑、生命周期体系结构里程碑、初始操作能力里程碑、产品发行里程碑。 具体规定详见软件项目生命周期模型。 4.2.2项目范围估计1.项目经理应建立和维护顶层的WBS来估计项目的范围（可直接用进度计划形式表现），WBS应与生命周期阶段划分保持一致。 可以通过工作分解结构把一个整体项目划分成若干互连的可管理的组成部分来完成。 工作分解结构可以作为一种参考机制或框架，用于考虑分配工作量、进度和责任，并且还可以用于策划、组织和控制围绕该项目进行的工作。 2.顶层WBS可体现在软件项目进度计划的顶层任务安排中体现。 4.2.3项目过程定义1.确定项目生命周期模型后，项目经理应和QA工程师一起根据项目特性，在组织标准软件过程的基础上，共同裁剪制定项目定义软件过程。 2.项目过程定义是根据项目的实际情况，在一定的裁剪准则下，为项目量身定制一套合适本项目过程的工作。 裁剪并不仅仅意味着减少，而是包括增加、删除、修改三种方式。 裁剪不是随意的行为，它应依据软件项目裁剪指南和所选的每个过程文档后的裁剪指南进行。 3.项目过程定义可以体现在软件项目计划当中。 4.2.4项目风险估计1.完成项目过程定义后，项目经理应组织相关人员开展风险管理策划活动，风险管理策划包括风险识别、风险分析、风险计划三项内容。 2.项目组应尽可能在项目策划之初将项目的较大风险识别出来，风险管理计划体现在软件项目计划即可，风险规避措施如涉及到工作量较大的任务时，该任务应体现在软件项目进度计划当中，并且考虑为有发生概率较高的风险预留进度缓冲时间。 3.各类风险相关参数定义详见风险管理规程。 4.2.5项目数据估计上述工作完成后，项目经理组织项目组的相关成员或专家进行相关数据估计，估计时可考虑但不局限于以下方面1.需求的规模大小、明确程度、难易程度、复杂程度；2.系统架构成熟情况、可靠性等；3.项目范围、生命周期及项目定义过程；4.项目风险情况；5.项目工作分解结构WBS；6.客户特殊要求、合同约定；7.公司同类项目的经验历史数据；8.公司的项目预算标准。 估计的基本步骤是“工作产品规模估计”“工作量估计”“进度估计”“成本估计”。 项目估计工作过程记录及相关资料应当妥善保存在项目的配置库中，以便为将来重新调整估计提供背景参考资料。 4.2.6估计方法1Delphi方法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家“专”的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。 Delphi法鼓励参加者就问题相互讨论。 这个技术，要求有多种软件相关经验人的参与，互相说服对方。 Delphi法步骤1)协调人向各专家提供项目规格和估计表格;2)协调人召集小组会各专家讨论与规模相关的因素;3)各专家匿名填写迭代表格;4)协调人出一个估计总结，以迭代表的形式返回专家;5)协调人召集小组会，讨论较大的估计差异;6)专家复查估计总结并在迭代表上提交另一个匿名估计;7)重复4-6，直到达到一个最低和最高估计的一致。 2类比法类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。 类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。 类比法的基本步骤是1)出项目功能列表和实现每个功能的代码行；2)标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；3)通过步骤1和2得出各个功能的估计值；4)产生规模估计。 3Pert方法Pert方法是一种基于统计原理的估计方法，是一种简单易用、实效性强的软件估计方法对于指定的估计单元（可能是规模、进度、工作量、费用等），由直接负责人给出估计结果，估计结果由3个值构成最乐观值、最悲观值、最可能值，通过下面的计算公式得到估计的结果。 期望值=（最乐观值+4*最可能值+最悲观值）6标准偏差=（最乐观值-最悲观值）/6建议（最高-最低）/最可能40由此，推算出来最有可能接近实际情况的值。 期望值-标准偏差，期望值+标准偏差是一个可以接受的估计范围，如果你的最终实际值能够落到该范围内，则可以被认为你的估计是成功的。 初期该范围可以较大，随着估计的不断精确，该范围应该逐渐被有意识的减少以求得更准确的估计。 4估计方法使用说明对于规模、工作量、进度等可以采用Delphi方法及Pert方法相结合的方式，即扩展Delphi法。 对于成本估计，在工作量估计数据的基础上，需根据工资定额标准、分摊成本等按照公式计算得来。 成本的工作量估计有三种方法1)自底向上估计法；2)经验估计法，也就是自顶向下估计法；3)按软件工程活动估计法，参照历史数据、开发管理经验进行工作量估计。 估计数据的格式参见项目估计数据表。 4.3制定计划1.项目计划是执行和监控项目活动的基础，它的主要目的就是指导项目的具体实施，为了有效地指导项目实施，因此计划必须具有现实性和有用性。 2.在PMBOK中，项目计划过程全面涉及到九大知识领域的过程组，是项目管理中最为复杂同时也最容易受到忽视的一个环节，因此制定一个合理、有效的计划是成功的第一步。 3.注本小节中所提及的“过程”是指在PMBOK中的“过程组”，和TUP中所指的“过程”含义有所不同。 4.3.1制定软件项目计划项目经理应在需求调研首次完成后的5个工作日内完成软件项目计划初稿并提交评审，需求调研首次完成的标志为项目调研报告1.0版本通过评审并正式发布。 计划中可包括但不局限于以下方面1.项目客户信息；2.项目风险策划；3.设置里程碑、迭代个数及各自到达标志，其中四个阶段里程碑为必选里程碑；4.相关估计数据；5.项目资源安排；6.项目所需的知识和技能以及必要的培训；7.采购、外包等计划，具体可参照采购供应程序、项目外包管理规程；8.工件计划；9.数据管理计划；10.相关涉众的沟通协调活动；11.项目监控频度、方法等；12.版本交付计划。 4.3.2制定进度计划1.项目经理应在需求调研首次完成后的5个工作日内完成软件项目进度计划初稿并提交评审。 2.项目经理结合合同工期要求、WBS、项目进度估计结果、风险策划情况、缺陷预防计划、度量分析计划、决策分析活动、集成部署计划等安排等制定软件项目进度计划，进度计划推荐采用甘特图形式。 3.在项目前期制定的进度计划通常比较粗略，但在阶段划分、各阶段主要里程碑时间点、关键可交付工件、本阶段迭代计划等方面应当予以明确，同时随着项目的推进，进度计划在每个阶段、每个迭代中应不断细化。 4.为了降低风险，应采用迭代方式递进开发，一个迭代的周期通常为14周，项目可根据项目总周期进行选择，并定义阶段内迭代的数量、长度和目标。 在同一个阶段中，各次迭代的时间周期通常是等长的；但在不同的阶段中，各次迭代的时间周期长度有可能不同（如精化阶段的迭代周期可能会比构造阶段的迭代周期长一些）。 5.如果同一阶段中各迭代的长度相差较大，可通过增删改每个迭代中要实现的目标及任务范围来保持每个迭代为等长工期。 6.通常情况下，每次迭代完成后都应提交一个可执行的文件。 7.确定了各阶段划分及迭代周期后，应制定最近一次迭代的进度计划，同时每次迭代完成之际，应及时细化下一迭代的进度计划，迭代计划制定的主要步骤为a)决定迭代范围；b)明确迭代评估标准；c)定义迭代活动；d)分配职责。 4.3.3制定成本计划1.项目经理应在软件项目计划、软件项目进度计划首次完成后的5个工作日内组织完成软件项目成本计划初稿并提交评审，首次完成的标志为软件项目计划及软件项目进度计划1.0版本通过评审并正式发布。 2.项目经理作为项目的整体负责人，要组织、收集、汇总软件项目成本计划中的各项数据。 其中关于人力成本部分由人资提供，参照依据为项目预算及核算标准。 项目商务、外包等费用由项目经营部提供。 3.成本计划可用Excel表格的形式体现。 4.3.4制定支持计划1.QA、CM、测试工程师根据项目相关计划完成各自的支持计划，支持计划的制定必须与项目经理及其他相关人员协商沟通，以确保一致性。 2.项目质量保证计划的编制遵循质量保证程序。 3.软件配置管理计划的编制遵循配置管理程序。 4.测试计划的编制遵循测试规程。 4.4计划评审1.项目计划在提交正式评审前，应先和相关人员进行过充分沟通。 2.项目各计划的评审可以一次评审完成，也可以分情况多次进行评审，但必须保证软件项目进度计划的评审时间不得晚于其他计划评审通过的时间。 3.其中软件项目进度计划、软件项目计划、软件项目成本计划建议采用正式评审的方式。 其他计划可采用检查确认的方式，不同角色评审项目计划时，所关注的内容不同。 4.如项目制定了行动计划，则按行动计划中计划评审时间安排执行。 5.如无行动计划，则项目经理应于项目立项后的2周内完成并提交软件项目计划、软件项目进度计划、软件项目成本计划进行正式评审。 如遇特殊情况，允许评审实际日期与以上规定时间存在一定偏差，但最迟不应超过1周。 6.项目相关计划评审完成后，如结论为不通过，则作者需修订后进行再次评审；如结论为有条件通过，则计划修订后由QA进行跟踪检查。 确认无误后由QA工程师提交给CM工程师；如结论为无条件通过，则由QA工程师直接提交CM工程师。 7.CM收到通过评审后的项目相关计划后，纳入项目配置库进行受控管理，并通知项目相关人员进行计划发布。 计划发布后，项目相关人员依据项目计划开展执行相关工作。 8.关于计划评审的具体人选及详细流程，请参见评审管理规程。 4.5客户确认1.项目计划通过内部评审后，项目经理应将项目计划中适宜向客户公开的内容和客户进行确认。 2.必要时需召开客户方计划评审会，参加人员包括客户主要负责人、客户项目责任人、我方咨询工程师、我方软件经理等主要参与人员。 3.会议可选择照相、录像、录音、会议记录等适当方式保留相关证据和记录。 计划评审通过后，请用户在认可的计划上签字盖章。 4.CM工程师对外发布计划摘要内容到.toone.:9079“同望项目实施专区”页面中。 4.6计划维护1.计划通常需要根据项目的进展情况不断进行调整和修改，以便应对需求范围变更、估计不够准确、控制出现偏差、纠正措施、过程变更、项目暂停后重新启动等各类情况。 2.计划维护分为两种情况3.一种是不断对软件项目进度计划进行定期或事件驱动的各阶段及各迭代中具体任务进行细化，如果不涉及到里程碑变化、进度超出允许偏差范围、合同发生重大变化等情况时，计划不需做变更处理。 4.另一种是达到计划变更的触发条件，如当实际情况和计划存在较大的偏差、合同发生变化、里程碑时间发生调整、迭代个数调整等情况时，应当及时进行项目再策划，并根据实际情况调整并变更项目计划，变更后的计划要及时通知相关涉众，变更流程遵循变更控制规程。 5.具体计划变更触发条件应依据该项目软件项目计划中“计划变更条件”的界定。 5.裁剪指南1.如果项目早期策划（从项目立项起，到项目计划提交评审止）的持续时间较短（不超过2周），则可不必制定策划前的行动计划。 2.当项目预计周期小于1个月时，则项目相关所有计划（包括QA、CM、测试）