IE-模版-软件项目策划过程.doc

目 录1简介31.1目的31.2 适用范围32 过程总体描述32.1 过程概述32.2 过程结构描述53 过程元素描述53.1 项目定义53.1.1 工作流程概述53.1.2 参与人员63.1.3入口准则63.1.4 输入63.1.5 任务63.1.6 出口准则83.1.7 输出（工作产品）93.1.8 资源和能力要求93.1.9 度量93.2 选用软件生命周期模型93.2.1 工作流程概述93.2.2 参与人员93.2.3 入口准则93.2.4 输入103.2.5 任务103.2.6 出口准则103.2.7 输出（工作产品）103.2.8 资源和能力要求113.2.9 度量113.3 工作分解WBS113.3.1 过程元素概述113.3.2 参与人员123.3.3 入口准则123.3.4 输入123.3.5 任务133.3.6 出口准则143.3.7 输出（工作产品）143.3.8 资源和能力要求143.3.9 度量143.4 制订风险管理计划143.4.1 过程元素概述143.4.2 参与人员153.4.3 入口准则153.4.4 输入153.4.5 任务153.4.6 出口准则173.4.7 输出（工作产品）173.4.8 资源和能力要求173.4.9 度量173.5 项目估算173.5.1 概述173.5.2 参与人员183.5.3 入口准则183.5.4 输入183.5.5 任务193.5.6 出口准则213.5.7 输出（工作产品）213.5.8 资源和能力要求213.5.9 度量213.6 项目计划审批223.6.1 概述223.6.2 参与人员223.6.3 入口准则223.6.4 输入223.6.5 任务233.6.6 出口准则243.6.7 输出（工作产品）243.6.8 资源和能力要求243.6.9 度量243.7.1 概述243.7.2 参与人员243.7.3 入口准则253.7.4 输入253.7.5 任务253.7.6 出口准则253.7.7 输出（工作产品）263.7.8 资源和能力要求263.7.9 度量264 附录274.1 附表1：风险分析274.2 附表2：风险处理和减缓291简介1.1目的软件项目计划的目的是为执行软件工程和管理软件项目制定合理的计划。本过程旨在使软件开发人员及管理人员充分了解软件项目计划过程，使项目管理人员遵照本过程实施项目计划活动、制定软件开发计划及执行相关计划活动。1.2 适用范围本过程适用于组织中所有的软件开发项目，从需求阶段开始，至维护阶段完成，贯穿项目的整个生命周期。 转自项目管理者联盟1.3 术语表 WBS：工作分解结构（Work Breakdown Structure, WBS）是一种以分级方式表述项目工作和任务的技术。一个定义良好的WBS不仅体现了项目所采用的软件过程，而且指明了整个生命周期中所要产生的各种工作产品。WBS的建立可以有助于在项目计划期间防止遗漏某些重要的事项和活动，并且保证所需要的活动都能明确识别和关联。BCWS：Budgeted Cost of Work Scheduled，项目基准，也叫做计划工作的预算成本（BCWS）2 过程总体描述2.1 过程概述为了对软件项目实施有效的管理，通常将整个项目划分成四个大的阶段，即：立项阶段、计划阶段、开发阶段和交付阶段。从项目管理的要求来说，在立项阶段，对项目做可行性分析；在计划阶段，要进行项目计划，即对项目进行整体计划，计划的结果将作为项目后续开发和管理活动的基础；在项目的开发阶段，为了确保项目能按预定计划、预定成本完成开发任务，需要对其进行跟踪和监控；在项目的交付阶段，项目验收交付后应进行项目总结。项目计划过程是软件项目管理的一个重要过程。计划又是一个重要的活动，许多过程活动都和它相关，作为一个完整的项目计划，它包括：项目任务书、生命周期模型选用、项目定义的软件过程、软件开发计划制定（产品识别与WBS制定、软件估算、风险管理计划、进度表制定）、软件配置管理计划、软件质量保证计划、测试计划等。在计划阶段，上述的活动是协调一致的，其他计划的制定和开发计划制定同步。2.2 过程结构描述3 过程元素描述3.1 项目定义3.1.1 工作流程概述进行项目定义的目的是要确保在项目生命周期的早期打下成功的基础。它包括根据客户需求确定的项目范围建立项目任务书、并且组织起适当的人员。 3.1.2 参与人员项目经理：编写项目任务书高层经理：下达任务书、批准任务书、组织项目团队 3.1.3入口准则已收集完成客户需求并通过评审。3.1.4 输入客户需求说明书3.1.5 任务3.1.5.1 确定项目任务书内容项目任务书就是对该项目的简要的、理解透彻的描述。它有助于客户和管理人员进行相关的业务决策，并且有助于项目参与人员理解其总的期望和将来项目启动后所要处于的业务环境。项目任务书必须在客户需求收集完成之后开始起草，在项目启动之前完成。它的内容一般包括：项目的管理和技术目标客户和用户识别软件主要功能的一般描述项目论证，包括商业目标和结果软件系统所期望的收益主要成本、时间表、资源、或其他约束项目的性能目标关键责任与其他项目和组织之间的依赖关系项目任务书必须经过高层管理者的批准。批准就等于授权允许推进到项目的启动阶段。项目任务书的书写要求参见项目任务书模版。3.1.5.2 组织适当的人员 项目经理博客有效的项目组胜于所有个体的总和。每一个项目先要组织项目组，识别所有需要的角色，确保不要忽略任何应由软件开发组以外人员来充当的角色。角色应该包括： 需求分析员：由客户需求析出其中归于软件的需求。开发人员：根据需求，通过设计和编码实现软件的需求。客户：需求的提出者，也是软件开发的约定者。用户：软件产品的使用者，有时与客户是同一对象。测试人员：对软件产品进行测试，保证满足软件设计要求和客户的需求。 质量保证人员：在整个软件生命周期中，监督和检验软件过程与标准的符合性以及软件产品生产规范的符合性。配置管理人员：在整个软件生命周期中，控制软件产品的状态和一致性，确保产品的有序变更和发布。数据库/运行/网络支持：如果需要的话，对项目给予后勤保障。管理者：获得对项目的承诺和支持，以及对项目的总体控制。 接下来要与适当的组进行接触，并与他们协商参与项目计划阶段。要落实每个组都究竟让谁参与该项目。在进行项目估算时，还要对所需的其它资源和支持继续进行沟通和协商。当分配好人员并组织起项目组时，就要清楚地说明责任，以使每个项目组成员了解项目对他们寄予的期望是什么。3.1.5.3 确定项目范围 由客户需求说明书经过分析得到归于软件的需求，再经过文档化，形成软件需求规格说明书。系统分析活动也应由项目经理先制订计划，计划内容包括：要达到的目标；确定系统分析的任务，包括：确定系统架构、可行性分析、用工程方法和技术语言对客户需求说明书的需求进行重新组织和描述（例如分解成软件部分和硬件部分的需求）等；工作阶段及每个阶段应产生的中间工作产品；按历史数据或根据业界标准进行工作量估算和日程安排。将任务分配给项目组成员。软件需求必须经过正式评审，并且对需求的改动也必须进行正式的控制，控制方式由软件配置管理过程的控制。项目经理按照系统分析计划推进分析活动，直至形成软件需求规格说明书并获得正式评审通过。 3.1.5.4 项目任务书文档化 在项目计划进行到这里时，要开始利用软件开发计划模板的项目任务书模板对软件开发计划进行文档化，项目任务书是单独的一个文档，但是项目计划可以由项目任务书逐步细化衍生出来。在项目任务书的基础上，完成项目计划的制订工作。 3.1.6 出口准则项目任务书得到高层经理批准。项目开发组织主要成员已经确定，责任已经清楚。形成软件需求规格说明书并通过正式评审。 3.1.7 输出（工作产品）项目任务书 软件需求规格说明书 3.1.8 资源和能力要求与客户需求有关的信息资源；确定项目的主要成员所需要的人力资源；系统分析所要求的人员能力。3.1.9 度量项目经理编制项目任务书所花费的工时。系统分析所花费的工时。3.2 选用软件生命周期模型 3.2.1 工作流程概述结合项目的具体情况，选择适合本项目的软件生命周期模型，以此定义项目开发的过程，并识别各过程应产生的工作产品。3.2.2 参与人员项目经理：负责组织项目的软件过程的定义。SEPG：对项目选择的模型与开发过程进行评审。 高层经理：批准项目选择的软件过程。3.2.3 入口准则 项目软件需求已经明确 3.2.4 输入软件需求规格说明书 项目任务书软件生命周期模型选用规程3.2.5 任务 （1）根据软件需求规格说明书和项目任务书中描述的项目实际情况，按照软件生命周期模型选用规程选择适合的软件生命周期模型。（2）对模型定义的各软件过程进行详细描述，描述应包括：过程的入口准则、出口准则、要执行的任务以及产生的工作产品。（3）选择的模型与开发过程，经SEPG评审后由高层经理批准。根据项目的具体情况，项目的过程描述文件可以不单独成文，而作为项目开发计划文件的组成部分并入开发计划文件。（4）如项目开发与模型定义的软件过程存在偏差，则应在软件过程描述文件中进行说明，并经SEPG评审后，由高层经理（如需要，还应由客户）进行审批。上述任务由软件项目经理（以下如无特别说明，均简称项目经理）负责，组织有关人员完成。3.2.6 出口准则软件过程描述文件已形成文件，并已通过评审并经批准。3.2.7 输出（工作产品）项目选用的模型与其软件过程描述文档，（名称一般是项目软件工程过程描述） 3.2.8 资源和能力要求选择适用模型的人员具有如何利用软件过程资源方面的能力，如果未完全具备，应组织适当的培训。3.2.9 度量项目经理负责统计软件过程选择与描述所花费的工时。SEPG人员所花费的工时。3.3 工作分解WBS3.3.1 过程元素概述WBS (Work Breakdown Structure工作分解结构)是一种以分级方式表述项目工作和任务的技术，一个定义良好的WBS不仅体现了项目所采用的软件过程，而且指明了整个生命周期中所要产生的各种工作产品。WBS的建立可以有助于在项目计划期间防止遗漏某些重要的项和活动，并且保证所需要的活动都能得以逻辑的识别和关联。一个定义清晰的WBS是项目计划的基础。在项目的早期阶段对整个生命周期中的所有任务是无法完全而准确识别的，所以项目计划会在不同的阶段分别进行工作任务分解。而WBS又先于其他的计划活动（比如：估算、进度表等）产生。因此，对完成的WBS首先要进行组内评审，将组内评审通过的WBS作为下步策划的基础。当然，工作任务分解也是一个迭代的过程。计划过程也会对它进行完善和维护，最终的WBS将和项目计划所有其它工作产品一起进行评审。WBS工作分解结构示例图如下： 3.3.2 参与人员项目经理：组织对本项目组内对所涉及技术较熟悉的人员分工完成工作任务的拆分。相关人员：协助、配合项目经理进行任务拆分。相关人员是指：开发组、测试组、文档支持人员的代表，以及SQA和SCM等。3.3.3 入口准则项目的软件过程描述文件已通过评审并经过批准3.3.4 输入项目选用的模型与其软件过程描述文档项目任务书3.3.5 任务3.3.5.1 识别工作产品 在定义了项目工程过程模型和技术方法之后，要确定待产生的工作产品的类型，工作产品和过程阶段的对应关系可以参见工作产品列表，这是一个标准的列表，如果项目有特殊要求，可以增加或删减。每一个项目需要在项目计划中引用它，详细的工作产品和子工作产品在WBS中详细列出。这一步很重要，因为在详细的阶段计划期间，要定义许多项目任务，其中的一部分就是根据所要产生的工作产品定义的。并且，当项目执行时，进度度量的基础就是工作产品的完成。3.3.5.2 用WBS定义技术活动用WBS定义技术活动，其定义要点为：在项目的早期定义WBS的高层元素，然后在进行详细策划时再定义WBS的低层元素；拆分从WBS的第一层开始。通常利用所选定的过程模型确定第一层和第二层，然后逐层确定各层元素，包括开发阶段、过程和产品；一般不会超过五层，最低层的元素通常在详细设计阶段计划时定义；当定义详细任务（最低层的元素）时，应考虑“80小时原则”，即所定义的任务应当是一个人不承担其他任务，能在两周（80小时）内完成的任务； 按项目任务单模板填写项目任务单，对所定义的详细任务进行说明； 详细任务的定义可以分阶段完成。3.3.5.3 用WBS定义管理和支持活动 参考上述方法对管理和支持活动进行定义，包括项目管理、软件质量保证、软件配置管理等。将拆分结果按工作拆分结构模板填写到工作任务拆分表中。3.3.5.4 更新项目计划WBS完成后，利用项目计划模板对软件开发计划进行文档化。在软件开发计划模板的指导下，把工作分解结构（WBS）写成文档，更新到软件项目计划中，必要的话，更新或修改软件项目计划的其它部分。3.3.6 出口准则工作任务拆分WBS已完成，并形成文件。本阶段确定的任务已填写任务任务单。3.3.7 输出（工作产品）WBS 项目任务单3.3.8 资源和能力要求进行任务拆分的人员具有如何进行任务拆分的能力，如果未完全具备，应组织适当的培训。3.3.9 度量项目经理负责统计用于WBS的工时。 3.4 制订风险管理计划 3.4.1 过程元素概述为了管理项目可能存在的风险，在进行项目计划时需要进行风险分析并制订风险管理计划，该计划可作为项目开发计划的一部分进行描述。风险管理应贯穿于项目工程的始终。风险管理不是项目经理一人的任务，也不是一次性的任务。它是一个迭代的过程，任一项目成员都有责任进行风险管理。建立一种有助于对潜在的风险及其发生的可能性和影响进行交流的环境对项目经理来说是重要的。制定风险管理计划包括：风险识别、风险分析、风险的处理和减缓行动。 3.4.2 参与人员项目经理：组织项目组内有关人员制定风险管理计划。项目组成员：配合项目经理制定风险管理计划。3.4.3 入口准则 WBS已完成。3.4.4 输入 项目任务书客户需求、软件需求 WBS 3.4.5 任务1、在项目估算开始前，通常要对项目进行风险分析。2、风险分析通常是由项目经理和组员参照软件开发潜在风险分析列表以及曾经开发过的项目所积累的经验来进行。3、制定风险管理计划包括识别风险、然后进行风险分析并制定风险处理和减缓行动。识别风险：识别风险的主要方法：就项目可能存在的问题和不确定因素，征求项目组成员的意见。 参考以往项目的风险情况。 针对所识别的潜在风险，采用提问的方式确定是否应认定为风险. 确定所识别的风险的类型，风险类型主要由三类：规模风险：项目产品本身（大系统和小系统）或由项目团队引起的风险。 结构风险：由商业环境（客户的业务流程变动性）、不确定的客户需求、组织自身的管理水平、能力成熟度引发的风险。技术风险：由人员的技术水平和经验、使用的工具和技术的成熟度等引发的风险。 项目经理将识别出的风险记录到风险减缓活动日志的风险列表中。 风险分析：风险分析步骤： 评价风险可能性和影响 计算风险值和风险等级（分为1级、2级）确定风险优先级 具体的风险分析方法参见附表：风险分析 当风险分析完成后，将风险值、风险等级、排出的风险优先级以及对每个风险的分类，记录到风险减缓活动日志中。 风险处理和减缓活动： 对每个高优先级风险，项目组都要制定出处理和减缓风险的活动计划。 通常采取以下4种途径：避免、转移、接受、减缓。具体方法参见附表风险处理和减缓 将每个处理和减缓活动计划记录到风险减缓活动日志中。 4、在项目跟踪过程中，风险需要被定期跟踪，对已识别的风险进行处理。并识别新的风险及对应的减缓活动。5、对风险的管理是定期进行识别和管理的，与其它按阶段进行计划的活动有所区别。6、利用项目计划模板，在项目开发计划的风险部分，记录识别出来的风险列表、风险减缓活动日志。需要的话，对软件项目开发计划的其它部分进行适当的修改。3.4.6 出口准则制定风险管理计划并得到批准。3.4.7 输出（工作产品） 风险管理计划或更新后的项目计划 3.4.8 资源和能力要求一定的管理储备、风险管理人员有比较多的项目经验。3.4.9 度量项目组识别风险、分析风险、制定风险处理措施所花费的工时。3.5 项目估算3.5.1 概述每一个项目都要对项目进行估算，并将估算的结果作为项目计划的基础。 估算是项目计划的核心。目的是为项目建立合理的预算和进度表，确定合适水平的员工，并为项目承诺提供基础。一个没有建立在合理估算基础上的计划会提供一种错误的安全感，可能比根本没有计划更糟。估算的内容通常包括：规模、工作量/成本、外部成本、关键计算机资源、进度表、管理储备等。 在项目进度表中要安排里程碑点，里程碑点一般选在有特定意义的阶段点，如重要阶段的开始或结束。项目估算的流程如下： 3.5.2 参与人员项目经理：组织召开估算会议，进行软件估算 转自项目管理者联盟相关人员：在项目经理组织下，共同完成项目的各项估算，相关人员主要是指对本项目情况较熟悉的人员。3.5.3 入口准则软件需求规格说明书已完成 项目管理者联盟WBS已完成风险已识别3.5.4 输入软件需求规格说明书WBS风险管理计划或包括风险管理计划的项目计划 3.5.5 任务3.5.5.1 估算方法： 估算和计划贯穿了整个项目。在项目的早期阶段，采用从上到下的估算方法，整个项目的估算粗略的分配给各个阶段。项目进展过程中，从下到上的方法被用于详细的阶段计划来为子阶段进行更详细的计划和估算，并更新总的项目估算。3.5.5.2 估算策略：确定估算内容（如规模、工作量等）确定估算时间（策划时估算日期的确定）确定估算技术（如Delphi估算方法）确定估算粒度（如人天，人月）。3.5.5.3 估算内容：1、估算软件规模估算软件规模时通常采用的方法有两种：功能点（FP）估计法 代码行（LOC）估计法2、估算成本和工作量 估算开发活动时通常采用以下两种方法：利用生产率数据的估计法 Wideband-Delphi 估计法 估算支持及管理活动的工作量时，将支持活动和项目管理所需工作量估计为开发工作量的某个适当的比例：支持活动大约在5%-10%（如SCM、SQA） 项目管理大约在15-20%。3、估算外部成本 转自项目管理者联盟 需要估算的外部成本包括： 开发或测试所用的硬件。开发或测试所用的软件工具。将要集成到软件产品中的软件。（如DBMS、中间件）培训（课程费和其它费用）约定的维护4、估算关键计算机资源 项目经理圈子 关键计算机资源是软件开发和操作中受到约束的硬件资源。包括：计算机内存、磁盘容量、网络容量、处理器性能。 5、建立管理储备 建立管理储备是为了适应那些即使在最好的项目中也不可避免出现的变更。 它代表了为用于批准的变更而保留的部分项目资金。管理储备不能由项目经理单独批准使用，只能用于那些由客户和高层经理都同意的变更。6、制定进度表 首先根据规模及工作量估算结果估算每个活动的工期。 然后确定活动之间的所有关系，识别关键路径。 画一个Gantt图表，表示各活动的起始和结束日期。 确定项目的里程碑。7、建立项目基准 项目基准，也叫做计划工作的预算成本（BCWS）。 是通过把每个任务的预算（估计）成本和计划完成的指定时间段相联系建立起来的。 在项目的跟踪与监控过程中，通过获得挣值图对成本进行度量。 8、阶段详细估算 在项目每个阶段开始前，要作阶段详细估算（工作量和时间表）。估算的步骤同上述的过程相同。 把详细估算累计起来，确定项目和阶段的总估算。 完成后更新总体的项目估算和时间表。 详细估算完成后，更新项目计划。3.5.5.4 形成软件估计书 将上述估算的结果记录到软件估计书中。 软件估算要在项目的不同阶段进行，一般是在本阶段完成时进行下一阶段的详细估算。软件估计书作为项目计划的一部分一起评审。 3.5.6 出口准则 估算活动完成。估算结果得到批准。3.5.7 输出（工作产品）软件估计书项目进度表或包括了进度信息的WBS 修订过的WBS 3.5.8 资源和能力要求进行项目估算的人员应掌握估算的方法。3.5.9 度量项目经理进行以下统计：项目估算所花费的工时；实际结果和项目估算结果的偏差（项目结束时统计计算）。3.6 项目计划审批 3.6.1 概述一个完整的项目计划活动包括很多内容，如：项目任务书、生命周期模型的选用、软件开发计划（WBS、风险管理计划、软件估算、项目培训计划、工具及设备的识别等）、软件测试计划、软件配置管理计划、软件质量保证计划等，这些计划的制定在整个生命周期中是相关的，在项目计划时它们也是保持着同步，并作为一个项目计划的整体来保证项目的开发有序进行，一个计划的变更将影响着另一个计划的变更，项目计划始终是作为一个整体存在的。项目计划时，要将计划的结果形成书面文档项目计划等。对形成的计划要分别进行讨论、评审、批准、对客户做出承诺、配置管理。3.6.2 参与人员 项目经理：编写项目计划。 相关组负责人：其他计划的编制。 SQA：评审主持人、批准项目计划。高层经理：批准项目计划。客户代表：参加项目计划的评审。3.6.3 入口准则 任务拆分已完成 项目经理博客项目估算已完成 日程编制已完成 3.6.4 输入WBS 软件估计书项目进度表或包括了进度信息的WBS 3.6.5 任务3.6.5.1 项目计划文档化1、项目经理将计划活动的结果按照项目计划模板要求编写成项目计划。2、计划包括的内容有：项目介绍、参考文件、组织结构、角色及职责、软件生命周期模型定义、WBS、风险管理、估算、进度表、培训计划、开发设施和支持工具计划等。3、其中WBS、估计书、进度表都作为项目计划的附件存在，并和项目计划文档一同评审。4、相关组负责人将SQA计划、SCM计划等其他计划形成书面文档，作为项目计划的组成部分一同评审。5、项目计划是按阶段进行的，对项目计划也要按阶段进行更新和维护。3.6.5.2 项目计划的审批1、对形成文档的项目计划要进行评审和批准。2、项目计划活动是按阶段进行的，对项目计划的评审根据情况也要分阶段进行，具体在哪些阶段评审哪些产品，参见项目计划阶段活动表。3、对项目计划一般要进行正式评审。主持人可由项目经理或项目的SQA人员担任。评审人员通常由下列人员担任：项目经理、其它项目组的项目经理（可选）、开发组代表、测试人员、SQA、SCM、客户代表等，具体评审方式参见评审规程。4、评审可将所有计划文档一同评审，也可排定时间表分别评审，但都属于对一个产品的评审。5、评审通过后，所有参加人员要在评审记录单上签字。6、高层经理、SQA要在项目计划中的文件批准单部分签字，表明对计划的批准。 7、每次计划得到批准后，项目经理和其他组负责人要将项目计划纳入到配置管理工具的管理文档域对应目录下存放，并发mail通知所有相关组和个人。3.6.6 出口准则各阶段计划活动完成，结果得到批准。 3.6.7 输出（工作产品） 项目计划 3.6.8 资源和能力要求项目经理经过评审过程培训 3.6.9 度量项目经理进行以下统计：项目开发计划编写和评审所花费工时评审过程中发现的问题数量。3.7 建立项目控制数据库3.7.1 概述 为了对项目进行有效的管理和监控，项目经理需要建立项目控制数据库，供自己在项目过程中使用。3.7.2 参与人员 项目经理：组织建立项目控制数据库；负责维护项目控制数据库。项目组成员：配合建立项目控制数据库；提交应放入数据库的数据。 3.7.3 入口准则 项目计划已经批准3.7.4 输入项目计划3.7.5 任务以项目计划的结果为基础，建立“项目控制数据库”。根据项目的具体情况，“项目控制数据库”可以是一个数据库，也可以是一个专用的文件夹等。在项目计划阶段，应将以下内容加入数据库：估算结果和日程；工作任务拆分结构项目任务单风险管理计划或包括风险管理计划的项目计划。随着项目的进展，还可以加入实际执行结果，如：个人周报；项目周报；统计数据；问题状态登录表；风险对策登录表；会议记录等。“项目控制数据库”由项目经理负责维护，项目成员有责任将应放入数据库的数据提交项目经理。具体的提交方法可根据项目的实际情况决定，例如：手工提交、通过局域网、利用电子邮件等。3.7.6 出口准则项目控制数据库已建立并可以投入使用3.7.7 输出（工作产品）项目控制数据库。3.7.8 资源和能力要求建立项目控制数据库所需的硬件和软件。3.7.9 度量项目经理进行以下统计：建立项目控制数据库所花费的工时。4 附录 4.1 附表1：风险分析 4.2 附表2：风险处理和减缓