公司IE模版软件项目规划过程

1、39/39目 录 TOC o 1-3 h z u HYPERLINK l _Toc309116741 1简介 PAGEREF _Toc309116741 h 3 HYPERLINK l _Toc309116742 1.1目的 PAGEREF _Toc309116742 h 3 HYPERLINK l _Toc309116743 1.2 适用范围 PAGEREF _Toc309116743 h 3 HYPERLINK l _Toc309116744 2 过程总体描述 PAGEREF _Toc309116744 h 3 HYPERLINK l _Toc309116745 2.1 过程概述 PAGE

2、REF _Toc309116745 h 3 HYPERLINK l _Toc309116746 2.2 过程结构描述 PAGEREF _Toc309116746 h 5 HYPERLINK l _Toc309116747 3 过程元素描述 PAGEREF _Toc309116747 h 5 HYPERLINK l _Toc309116748 3.1 项目定义 PAGEREF _Toc309116748 h 5 HYPERLINK l _Toc309116749 3.1.1 工作流程概述 PAGEREF _Toc309116749 h 5 HYPERLINK l _Toc309116750 3.

3、1.2 参与人员 PAGEREF _Toc309116750 h 6 HYPERLINK l _Toc309116751 3.1.3入口准则 PAGEREF _Toc309116751 h 6 HYPERLINK l _Toc309116752 3.1.4 输入 PAGEREF _Toc309116752 h 6 HYPERLINK l _Toc309116753 3.1.5 任务 PAGEREF _Toc309116753 h 6 HYPERLINK l _Toc309116754 3.1.6 出口准则 PAGEREF _Toc309116754 h 8 HYPERLINK l _Toc30

4、9116755 3.1.7 输出（工作产品） PAGEREF _Toc309116755 h 9 HYPERLINK l _Toc309116756 3.1.8 资源和能力要求 PAGEREF _Toc309116756 h 9 HYPERLINK l _Toc309116757 3.1.9 度量 PAGEREF _Toc309116757 h 9 HYPERLINK l _Toc309116758 3.2 选用软件生命周期模型 PAGEREF _Toc309116758 h 9 HYPERLINK l _Toc309116759 3.2.1 工作流程概述 PAGEREF _Toc309116

5、759 h 9 HYPERLINK l _Toc309116760 3.2.2 参与人员 PAGEREF _Toc309116760 h 9 HYPERLINK l _Toc309116761 3.2.3 入口准则 PAGEREF _Toc309116761 h 9 HYPERLINK l _Toc309116762 3.2.4 输入 PAGEREF _Toc309116762 h 10 HYPERLINK l _Toc309116763 3.2.5 任务 PAGEREF _Toc309116763 h 10 HYPERLINK l _Toc309116764 3.2.6 出口准则 PAGER

6、EF _Toc309116764 h 10 HYPERLINK l _Toc309116765 3.2.7 输出（工作产品） PAGEREF _Toc309116765 h 10 HYPERLINK l _Toc309116766 3.2.8 资源和能力要求 PAGEREF _Toc309116766 h 11 HYPERLINK l _Toc309116767 3.2.9 度量 PAGEREF _Toc309116767 h 11 HYPERLINK l _Toc309116768 3.3 工作分解WBS PAGEREF _Toc309116768 h 11 HYPERLINK l _Toc

7、309116769 3.3.1 过程元素概述 PAGEREF _Toc309116769 h 11 HYPERLINK l _Toc309116770 3.3.2 参与人员 PAGEREF _Toc309116770 h 12 HYPERLINK l _Toc309116771 3.3.3 入口准则 PAGEREF _Toc309116771 h 12 HYPERLINK l _Toc309116772 3.3.4 输入 PAGEREF _Toc309116772 h 12 HYPERLINK l _Toc309116773 3.3.5 任务 PAGEREF _Toc309116773 h 1

8、3 HYPERLINK l _Toc309116774 3.3.6 出口准则 PAGEREF _Toc309116774 h 14 HYPERLINK l _Toc309116775 3.3.7 输出（工作产品） PAGEREF _Toc309116775 h 14 HYPERLINK l _Toc309116776 3.3.8 资源和能力要求 PAGEREF _Toc309116776 h 14 HYPERLINK l _Toc309116777 3.3.9 度量 PAGEREF _Toc309116777 h 14 HYPERLINK l _Toc309116778 3.4 制订风险治理打

9、算 PAGEREF _Toc309116778 h 14 HYPERLINK l _Toc309116779 3.4.1 过程元素概述 PAGEREF _Toc309116779 h 14 HYPERLINK l _Toc309116780 3.4.2 参与人员 PAGEREF _Toc309116780 h 15 HYPERLINK l _Toc309116781 3.4.3 入口准则 PAGEREF _Toc309116781 h 15 HYPERLINK l _Toc309116782 3.4.4 输入 PAGEREF _Toc309116782 h 15 HYPERLINK l _To

10、c309116783 3.4.5 任务 PAGEREF _Toc309116783 h 15 HYPERLINK l _Toc309116784 3.4.6 出口准则 PAGEREF _Toc309116784 h 17 HYPERLINK l _Toc309116785 3.4.7 输出（工作产品） PAGEREF _Toc309116785 h 17 HYPERLINK l _Toc309116786 3.4.8 资源和能力要求 PAGEREF _Toc309116786 h 17 HYPERLINK l _Toc309116787 3.4.9 度量 PAGEREF _Toc3091167

11、87 h 17 HYPERLINK l _Toc309116788 3.5 项目估算 PAGEREF _Toc309116788 h 17 HYPERLINK l _Toc309116789 3.5.1 概述 PAGEREF _Toc309116789 h 17 HYPERLINK l _Toc309116790 3.5.2 参与人员 PAGEREF _Toc309116790 h 18 HYPERLINK l _Toc309116791 3.5.3 入口准则 PAGEREF _Toc309116791 h 18 HYPERLINK l _Toc309116792 3.5.4 输入 PAGER

12、EF _Toc309116792 h 18 HYPERLINK l _Toc309116793 3.5.5 任务 PAGEREF _Toc309116793 h 19 HYPERLINK l _Toc309116794 3.5.6 出口准则 PAGEREF _Toc309116794 h 21 HYPERLINK l _Toc309116795 3.5.7 输出（工作产品） PAGEREF _Toc309116795 h 21 HYPERLINK l _Toc309116796 3.5.8 资源和能力要求 PAGEREF _Toc309116796 h 21 HYPERLINK l _Toc3

13、09116797 3.5.9 度量 PAGEREF _Toc309116797 h 21 HYPERLINK l _Toc309116798 3.6 项目打算审批 PAGEREF _Toc309116798 h 22 HYPERLINK l _Toc309116799 3.6.1 概述 PAGEREF _Toc309116799 h 22 HYPERLINK l _Toc309116800 3.6.2 参与人员 PAGEREF _Toc309116800 h 22 HYPERLINK l _Toc309116801 3.6.3 入口准则 PAGEREF _Toc309116801 h 22 H

14、YPERLINK l _Toc309116802 3.6.4 输入 PAGEREF _Toc309116802 h 22 HYPERLINK l _Toc309116803 3.6.5 任务 PAGEREF _Toc309116803 h 23 HYPERLINK l _Toc309116804 3.6.6 出口准则 PAGEREF _Toc309116804 h 24 HYPERLINK l _Toc309116805 3.6.7 输出（工作产品） PAGEREF _Toc309116805 h 24 HYPERLINK l _Toc309116806 3.6.8 资源和能力要求 PAGER

15、EF _Toc309116806 h 24 HYPERLINK l _Toc309116807 3.6.9 度量 PAGEREF _Toc309116807 h 24 HYPERLINK l _Toc309116808 3.7.1 概述 PAGEREF _Toc309116808 h 24 HYPERLINK l _Toc309116809 3.7.2 参与人员 PAGEREF _Toc309116809 h 24 HYPERLINK l _Toc309116810 3.7.3 入口准则 PAGEREF _Toc309116810 h 25 HYPERLINK l _Toc309116811

16、3.7.4 输入 PAGEREF _Toc309116811 h 25 HYPERLINK l _Toc309116812 3.7.5 任务 PAGEREF _Toc309116812 h 25 HYPERLINK l _Toc309116813 3.7.6 出口准则 PAGEREF _Toc309116813 h 25 HYPERLINK l _Toc309116814 3.7.7 输出（工作产品） PAGEREF _Toc309116814 h 26 HYPERLINK l _Toc309116815 3.7.8 资源和能力要求 PAGEREF _Toc309116815 h 26 HYP

17、ERLINK l _Toc309116816 3.7.9 度量 PAGEREF _Toc309116816 h 26 HYPERLINK l _Toc309116817 4 附录 PAGEREF _Toc309116817 h 27 HYPERLINK l _Toc309116818 4.1 附表1：风险分析 PAGEREF _Toc309116818 h 27 HYPERLINK l _Toc309116819 4.2 附表2：风险处理和减缓 PAGEREF _Toc309116819 h 291简介1.1目的软件项目打算的目的是为执行软件工程和治理软件项目制定合理的打算。本过程旨在使软件开

18、发人员及治理人员充分了解软件项目打算过程，使项目治理人员遵照本过程实施项目打算活动、制定软件开发打算及执行相关打算活动。1.2 适用范围本过程适用于组织中所有的软件开发项目，从需求时期开始，至维护时期完成，贯穿项目的整个生命周期。 转自项目治理者联盟1.3 术语表 WBS：工作分解结构（Work Breakdown Structure, WBS）是一种以分级方式表述项目工作和任务的技术。一个定义良好的WBS不仅体现了项目所采纳的软件过程，而且指明了整个生命周期中所要产生的各种工作产品。WBS的建立能够有助于在项目打算期间防止遗漏某些重要的事项和活动，同时保证所需要的活动都能明确识不和关联。BC

19、WS：Budgeted Cost of Work Scheduled，项目基准，也叫做打算工作的预算成本（BCWS）2 过程总体描述2.1 过程概述为了对软件项目实施有效的治理，通常将整个项目划分成四个大的时期，即：立项时期、打算时期、开发时期和交付时期。从项目治理的要求来讲，在立项时期，对项目做可行性分析；在打算时期，要进行项目打算，即对项目进行整体打算，打算的结果将作为项目后续开发和治理活动的基础；在项目的开发时期，为了确保项目能按预定打算、预定成本完成开发任务，需要对其进行跟踪和监控；在项目的交付时期，项目验收交付后应进行项目总结。项目打算过程是软件项目治理的一个重要过程。打算又是一个重

20、要的活动，许多过程活动都和它相关，作为一个完整的项目打算，它包括：项目任务书、生命周期模型选用、项目定义的软件过程、软件开发打算制定（产品识不与WBS制定、软件估算、风险治理打算、进度表制定）、软件配置治理打算、软件质量保证打算、测试打算等。在打算时期，上述的活动是协调一致的，其他打算的制定和开发打算制定同步。2.2 过程结构描述3 过程元素描述3.1 项目定义3.1.1 工作流程概述进行项目定义的目的是要确保在项目生命周期的早期打下成功的基础。它包括依照客户需求确定的项目范围建立项目任务书、同时组织起适当的人员。 3.1.2 参与人员项目经理：编写项目任务书高层经理：下达任务书、批准任务书、

21、组织项目团队 3.1.3入口准则已收集完成客户需求并通过评审。3.1.4 输入客户需求讲明书3.1.5 任务3.1.5.1 确定项目任务书内容项目任务书确实是对该项目的简要的、理解透彻的描述。它有助于客户和治理人员进行相关的业务决策，同时有助于项目参与人员理解其总的期望和今后项目启动后所要处于的业务环境。项目任务书必须在客户需求收集完成之后开始起草，在项目启动之前完成。它的内容一般包括：项目的治理和技术目标客户和用户识不软件要紧功能的一般描述项目论证，包括商业目标和结果软件系统所期望的收益要紧成本、时刻表、资源、或其他约束项目的性能目标关键责任与其他项目和组织之间的依靠关系项目任务书必须通过高

22、层治理者的批准。批准就等于授权同意推进到项目的启动时期。项目任务书的书写要求参见项目任务书模版。3.1.5.2 组织适当的人员 项目经理博客有效的项目组胜于所有个体的总和。每一个项目先要组织项目组，识不所有需要的角色，确保不要忽略任何应由软件开发组以外人员来充当的角色。角色应该包括： 需求分析员：由客户需求析出其中归于软件的需求。开发人员：依照需求，通过设计和编码实现软件的需求。客户：需求的提出者，也是软件开发的约定者。用户：软件产品的使用者，有时与客户是同一对象。测试人员：对软件产品进行测试，保证满足软件设计要求和客户的需求。 质量保证人员：在整个软件生命周期中，监督和检验软件过程与标准的符

23、合性以及软件产品生产规范的符合性。配置治理人员：在整个软件生命周期中，操纵软件产品的状态和一致性，确保产品的有序变更和公布。数据库/运行/网络支持：假如需要的话，对项目给予后勤保障。治理者：获得对项目的承诺和支持，以及对项目的总体操纵。 接下来要与适当的组进行接触，并与他们协商参与项目打算时期。要落实每个组都究竟让谁参与该项目。在进行项目估算时，还要对所需的其它资源和支持接着进行沟通和协商。当分配好人员并组织起项目组时，就要清晰地讲明责任，以使每个项目组成员了解项目对他们寄予的期望是什么。3.1.5.3 确定项目范围 由客户需求讲明书通过分析得到归于软件的需求，再通过文档化，形成软件需求规格讲

24、明书。系统分析活动也应由项目经理先制订打算，打算内容包括：要达到的目标；确定系统分析的任务，包括：确定系统架构、可行性分析、用工程方法和技术语言对客户需求讲明书的需求进行重新组织和描述（例如分解成软件部分和硬件部分的需求）等；工作时期及每个时期应产生的中间工作产品；按历史数据或依照业界标准进行工作量估算和日程安排。将任务分配给项目组成员。软件需求必须通过正式评审，同时对需求的改动也必须进行正式的操纵，操纵方式由软件配置治理过程的操纵。项目经理按照系统分析打算推进分析活动，直至形成软件需求规格讲明书并获得正式评审通过。 3.1.5.4 项目任务书文档化 在项目打算进行到那个地点时，要开始利用软件

25、开发打算模板的项目任务书模板对软件开发打算进行文档化，项目任务书是单独的一个文档，然而项目打算能够由项目任务书逐步细化衍生出来。在项目任务书的基础上，完成项目打算的制订工作。 3.1.6 出口准则项目任务书得到高层经理批准。项目开发组织要紧成员差不多确定，责任差不多清晰。形成软件需求规格讲明书并通过正式评审。 3.1.7 输出（工作产品）项目任务书 软件需求规格讲明书 3.1.8 资源和能力要求与客户需求有关的信息资源；确定项目的要紧成员所需要的人力资源；系统分析所要求的人员能力。3.1.9 度量项目经理编制项目任务书所花费的工时。系统分析所花费的工时。3.2 选用软件生命周期模型 3.2.1

26、 工作流程概述结合项目的具体情况，选择适合本项目的软件生命周期模型，以此定义项目开发的过程，并识不各过程应产生的工作产品。3.2.2 参与人员项目经理：负责组织项目的软件过程的定义。SEPG：对项目选择的模型与开发过程进行评审。 高层经理：批准项目选择的软件过程。3.2.3 入口准则 项目软件需求差不多明确 3.2.4 输入软件需求规格讲明书 项目任务书软件生命周期模型选用规程3.2.5 任务 （1）依照软件需求规格讲明书和项目任务书中描述的项目实际情况，按照软件生命周期模型选用规程选择适合的软件生命周期模型。（2）对模型定义的各软件过程进行详细描述，描述应包括：过程的入口准则、出口准则、要执

27、行的任务以及产生的工作产品。（3）选择的模型与开发过程，经SEPG评审后由高层经理批准。依照项目的具体情况，项目的过程描述文件能够不单独成文，而作为项目开发打算文件的组成部分并入开发打算文件。（4）如项目开发与模型定义的软件过程存在偏差，则应在软件过程描述文件中进行讲明，并经SEPG评审后，由高层经理（如需要，还应由客户）进行审批。上述任务由软件项目经理（以下如无特不讲明，均简称项目经理）负责，组织有关人员完成。3.2.6 出口准则软件过程描述文件已形成文件，并已通过评审并经批准。3.2.7 输出（工作产品）项目选用的模型与其软件过程描述文档，（名称一般是项目软件工程过程描述） 3.2.8 资

28、源和能力要求选择适用模型的人员具有如何利用软件过程资源方面的能力，假如未完全具备，应组织适当的培训。3.2.9 度量项目经理负责统计软件过程选择与描述所花费的工时。SEPG人员所花费的工时。3.3 工作分解WBS3.3.1 过程元素概述WBS (Work Breakdown Structure工作分解结构)是一种以分级方式表述项目工作和任务的技术，一个定义良好的WBS不仅体现了项目所采纳的软件过程，而且指明了整个生命周期中所要产生的各种工作产品。WBS的建立能够有助于在项目打算期间防止遗漏某些重要的项和活动，同时保证所需要的活动都能得以逻辑的识不和关联。一个定义清晰的WBS是项目打算的基础。在

29、项目的早期时期对整个生命周期中的所有任务是无法完全而准确识不的，因此项目打算会在不同的时期分不进行工作任务分解。而WBS又先于其他的打算活动（比如：估算、进度表等）产生。因此，对完成的WBS首先要进行组内评审，将组内评审通过的WBS作为下步策划的基础。因此，工作任务分解也是一个迭代的过程。打算过程也会对它进行完善和维护，最终的WBS将和项目打算所有其它工作产品一起进行评审。WBS工作分解结构示例图如下： 3.3.2 参与人员项目经理：组织对本项目组内对所涉及技术较熟悉的人员分工完成工作任务的拆分。相关人员：协助、配合项目经理进行任务拆分。相关人员是指：开发组、测试组、文档支持人员的代表，以及S

30、QA和SCM等。3.3.3 入口准则项目的软件过程描述文件已通过评审并通过批准3.3.4 输入项目选用的模型与其软件过程描述文档项目任务书3.3.5 任务3.3.5.1 识不工作产品 在定义了项目工程过程模型和技术方法之后，要确定待产生的工作产品的类型，工作产品和过程时期的对应关系能够参见工作产品列表，这是一个标准的列表，假如项目有专门要求，能够增加或删减。每一个项目需要在项目打算中引用它，详细的工作产品和子工作产品在WBS中详细列出。这一步专门重要，因为在详细的时期打算期间，要定义许多项目任务，其中的一部分确实是依照所要产生的工作产品定义的。同时，当项目执行时，进度度量的基础确实是工作产品的

31、完成。3.3.5.2 用WBS定义技术活动用WBS定义技术活动，其定义要点为：在项目的早期定义WBS的高层元素，然后在进行详细策划时再定义WBS的低层元素；拆分从WBS的第一层开始。通常利用所选定的过程模型确定第一层和第二层，然后逐层确定各层元素，包括开发时期、过程和产品；一般可不能超过五层，最低层的元素通常在详细设计时期打算时定义；当定义详细任务（最低层的元素）时，应考虑“80小时原则”，即所定义的任务应当是一个人不承担其他任务，能在两周（80小时）内完成的任务； 按项目任务单模板填写项目任务单，对所定义的详细任务进行讲明； 详细任务的定义能够分时期完成。3.3.5.3 用WBS定义治理和支

32、持活动 参考上述方法对治理和支持活动进行定义，包括项目治理、软件质量保证、软件配置治理等。将拆分结果按工作拆分结构模板填写到工作任务拆分表中。3.3.5.4 更新项目打算WBS完成后，利用项目打算模板对软件开发打算进行文档化。在软件开发打算模板的指导下，把工作分解结构（WBS）写成文档，更新到软件项目打算中，必要的话，更新或修改软件项目打算的其它部分。3.3.6 出口准则工作任务拆分WBS已完成，并形成文件。本时期确定的任务已填写任务任务单。3.3.7 输出（工作产品）WBS 项目任务单3.3.8 资源和能力要求进行任务拆分的人员具有如何进行任务拆分的能力，假如未完全具备，应组织适当的培训。3

33、.3.9 度量项目经理负责统计用于WBS的工时。 3.4 制订风险治理打算 3.4.1 过程元素概述为了治理项目可能存在的风险，在进行项目打算时需要进行风险分析并制订风险治理打算，该打算可作为项目开发打算的一部分进行描述。风险治理应贯穿于项目工程的始终。风险治理不是项目经理一人的任务，也不是一次性的任务。它是一个迭代的过程，任一项目成员都有责任进行风险治理。建立一种有助于对潜在的风险及其发生的可能性和阻碍进行交流的环境对项目经理来讲是重要的。制定风险治理打算包括：风险识不、风险分析、风险的处理和减缓行动。 3.4.2 参与人员项目经理：组织项目组内有关人员制定风险治理打算。项目组成员：配合项目

34、经理制定风险治理打算。3.4.3 入口准则 WBS已完成。3.4.4 输入 项目任务书客户需求、软件需求 WBS 3.4.5 任务1、在项目估算开始前，通常要对项目进行风险分析。2、风险分析通常是由项目经理和组员参照软件开发潜在风险分析列表以及曾经开发过的项目所积存的经验来进行。3、制定风险治理打算包括识不风险、然后进行风险分析并制定风险处理和减缓行动。识不风险：识不风险的要紧方法：就项目可能存在的问题和不确定因素，征求项目组成员的意见。 参考以往项目的风险情况。 针对所识不的潜在风险，采纳提问的方式确定是否应认定为风险. 确定所识不的风险的类型，风险类型要紧由三类：规模风险：项目产品本身（大

35、系统和小系统）或由项目团队引起的风险。 结构风险：由商业环境（客户的业务流程变动性）、不确定的客户需求、组织自身的治理水平、能力成熟度引发的风险。技术风险：由人员的技术水平和经验、使用的工具和技术的成熟度等引发的风险。 项目经理将识不出的风险记录到风险减缓活动日志的风险列表中。 风险分析：风险分析步骤： 评价风险可能性和阻碍 计算风险值和风险等级（分为1级、2级）确定风险优先级 具体的风险分析方法参见附表：风险分析 当风险分析完成后，将风险值、风险等级、排出的风险优先级以及对每个风险的分类，记录到风险减缓活动日志中。 风险处理和减缓活动： 对每个高优先级风险，项目组都要制定出处理和减缓风险的活

36、动打算。 通常采取以下4种途径：幸免、转移、同意、减缓。具体方法参见附表风险处理和减缓 将每个处理和减缓活动打算记录到风险减缓活动日志中。 4、在项目跟踪过程中，风险需要被定期跟踪，对已识不的风险进行处理。并识不新的风险及对应的减缓活动。5、对风险的治理是定期进行识不和治理的，与其它按时期进行打算的活动有所区不。6、利用项目打算模板，在项目开发打算的风险部分，记录识不出来的风险列表、风险减缓活动日志。需要的话，对软件项目开发打算的其它部分进行适当的修改。3.4.6 出口准则制定风险治理打算并得到批准。3.4.7 输出（工作产品） 风险治理打算或更新后的项目打算 3.4.8 资源和能力要求一定的

37、治理储备、风险治理人员有比较多的项目经验。3.4.9 度量项目组识不风险、分析风险、制定风险处理措施所花费的工时。3.5 项目估算3.5.1 概述每一个项目都要对项目进行估算，并将估算的结果作为项目打算的基础。 估确实是项目打算的核心。目的是为项目建立合理的预算和进度表，确定合适水平的职员，并为项目承诺提供基础。一个没有建立在合理估算基础上的打算会提供一种错误的安全感，可能比全然没有打算更糟。估算的内容通常包括：规模、工作量/成本、外部成本、关键计算机资源、进度表、治理储备等。 在项目进度表中要安排里程碑点，里程碑点一般选在有特定意义的时期点，如重要时期的开始或结束。项目估算的流程如下： 3.

38、5.2 参与人员项目经理：组织召开估算会议，进行软件估算 转自项目治理者联盟相关人员：在项目经理组织下，共同完成项目的各项估算，相关人员要紧是指对本项目情况较熟悉的人员。3.5.3 入口准则软件需求规格讲明书已完成 项目治理者联盟WBS已完成风险已识不3.5.4 输入软件需求规格讲明书WBS风险治理打算或包括风险治理打算的项目打算 3.5.5 任务3.5.5.1 估算方法： 估算和打算贯穿了整个项目。在项目的早期时期，采纳从上到下的估算方法，整个项目的估算粗略的分配给各个时期。项目进展过程中，从下到上的方法被用于详细的时期打算来为子时期进行更详细的打算和估算，并更新总的项目估算。3.5.5.2

39、 估算策略：确定估算内容（如规模、工作量等）确定估算时刻（策划时估算日期的确定）确定估算技术（如Delphi估算方法）确定估算粒度（如人天，人月）。3.5.5.3 估算内容：1、估算软件规模估算软件规模时通常采纳的方法有两种：功能点（FP）可能法 代码行（LOC）可能法2、估算成本和工作量 估算开发活动时通常采纳以下两种方法：利用生产率数据的可能法 Wideband-Delphi 可能法 估算支持及治理活动的工作量时，将支持活动和项目治理所需工作量可能为开发工作量的某个适当的比例：支持活动大约在5%-10%（如SCM、SQA） 项目治理大约在15-20%。3、估算外部成本 转自项目治理者联盟

40、需要估算的外部成本包括： 开发或测试所用的硬件。开发或测试所用的软件工具。将要集成到软件产品中的软件。（如DBMS、中间件）培训（课程费和其它费用）约定的维护4、估算关键计算机资源 项目经理圈子 关键计算机资源是软件开发和操作中受到约束的硬件资源。包括：计算机内存、磁盘容量、网络容量、处理器性能。 5、建立治理储备 建立治理储备是为了适应那些即使在最好的项目中也不可幸免出现的变更。 它代表了为用于批准的变更而保留的部分项目资金。治理储备不能由项目经理单独批准使用，只能用于那些由客户和高层经理都同意的变更。6、制定进度表 首先依照规模及工作量估算结果估算每个活动的工期。 然后确定活动之间的所有关

41、系，识不关键路径。 画一个Gantt图表，表示各活动的起始和结束日期。 确定项目的里程碑。7、建立项目基准 项目基准，也叫做打算工作的预算成本（BCWS）。 是通过把每个任务的预算（可能）成本和打算完成的指定时刻段相联系建立起来的。 在项目的跟踪与监控过程中，通过获得挣值图对成本进行度量。 8、时期详细估算 在项目每个时期开始前，要作时期详细估算（工作量和时刻表）。估算的步骤同上述的过程相同。 把详细估算累计起来，确定项目和时期的总估算。 完成后更新总体的项目估算和时刻表。 详细估算完成后，更新项目打算。3.5.5.4 形成软件可能书 将上述估算的结果记录到软件可能书中。 软件估算要在项目的不

42、同时期进行，一般是在本时期完成时进行下一时期的详细估算。软件可能书作为项目打算的一部分一起评审。 3.5.6 出口准则 估算活动完成。估算结果得到批准。3.5.7 输出（工作产品）软件可能书项目进度表或包括了进度信息的WBS 修订过的WBS 3.5.8 资源和能力要求进行项目估算的人员应掌握估算的方法。3.5.9 度量项目经理进行以下统计：项目估算所花费的工时；实际结果和项目估算结果的偏差（项目结束时统计计算）。3.6 项目打算审批 3.6.1 概述一个完整的项目打算活动包括专门多内容，如：项目任务书、生命周期模型的选用、软件开发打算（WBS、风险治理打算、软件估算、项目培训打算、工具及设备的识不等）、软件测试打算、软件配置治理打算、软件质量保证打算等，这些打算的制定在整个生命周期中是相关的，在项目打算时它们也是保持着同步，并作为一个项目打算的整体来保证项目的开发有序进行，一个打算的变更将阻碍着另一个打算的变更，项目打算始终是作为一个整体存在的。项目打算时，要将打算的结果形成书面文档项目打算等。对形成的打算要分不进行讨论、评审、批准、对客户做出承诺、配置治理。3.6.2 参与人员 项目经理：编写项目打算。 相关组负责人：其他打算的编制。 SQA：评审主持人、批准项目打算。高层经理：批准项目打算。客户代表：参加项目打算的评审。