【转】软件项目策划过程（二）

       3.2.8    资源和能力要求

　　选择适用模型的人员具有如何利用软件过程资源方面的能力，如果未完全具备，应组织适当的培训。

      3.2.9    度量

　　项目经理负责统计软件过程选择与描述所花费的工时。

　　SEPG人员所花费的工时。

　　3.3    工作分解WBS

　　3.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    参与人员

　　项目经理：组织召开估算会议，进行软件估算

　　相关人员：在项目经理组织下，共同完成项目的各项估算，相关人员主要是指对本项目情况较熟悉的人员。