十二 项目管理(考点篇)

1  进度管理

进度管理就是采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现工期目标。

具体来说，包括以下过程：

• (1)活动定义：确定完成项目各项可交付成果而需要开展的具体活动。
• (2)活动排序：识别和记录各项活动之间的先后关系和逻辑关系。
• (3)活动资源估算：估算完成各项活动所需要的资源类型和效益。
• (4)活动历时估算：估算完成各项活动所需要的具体时间。
• (5)进度计划编制：分析活动顺序、活动持续时间、资源要求和进度制约因素，制订项目进度计划。
• (6)进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。

软件项目往往是比较大而复杂的，往往需要进行层层分解，将大的任务分解成一个个的单一小任务进行处理。工作分解结构(WBS)如图所示，就是把一个项目，按一定的原则分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。

WBS 常见的分解方式包括：按产品的物理结构分解、按产品或项目的功能分解、按照实施过程分解、按照项目的实施单位分解、按照项目的目标分解、按部分或职能进行分解等。不管采用哪种分解方式，最终都要满足以下对任务分解的基本要求。

• (1)WBS 的工作包是可控和可管理的，不能过于复杂。
• (2)任务分解也不能过细，一般原则WBS 的树形结构不超过6 层。
• (3)每个工作包要有一个交付成果。
• (4)每个任务必须有明确定义的完成标准。
• (5)WBS 必须有利于责任分配。

进度的单位是活动，活动是比WBS更小的单位。

进度安排的常用图形描述方法有Gantt 图(甘特图)和项目计划评审技术(Program Evaluation&

ReviewTechnique,PERT)图。

甘特图：反应任务间并行关系；PERT图，不反应任务的并行，但反应了活动间依赖关系(顺序)。

活动定义的常用工具包括：分解(WBS分解更细 )、滚动式规划(近期细规划远期粗规划 )、模板(参考以往项目 )、专家判断(让经验丰富的人提供建议 )。

1.分解

采用分解技术来定义活动，就是要把项目工作包分解成更小的、更易于管理的组成部分，即活动——为完成工作包而必须开展的工作。定义活动过程最终输出的是活动，而非可交付成果。可交付成果是创建工作分解结构过程的输出。

WBS、WBS 词典与活动清单，既可依次编制，也可同时编制。WBS和 WBS 词典是制定最终活动清单的依据。WBS 中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果。让团队WBS成员参与分解，有助于得到更好、更准确的结果。

2.滚动式规划

滚动式规划是一种渐进明细的规划方式，即对近期要完成的工作进行详细规划，而对远期工作则暂 时只在WBS 的较高层次上进行粗略规划。因此，在项目生命周期的不同阶段，工作分解WBS的详细程度会有所不同。例如，在早期的战略规划阶段，信息尚不够明确，工作包也许只能分解到里程碑的水平；而后，随着了解到更多的信息，近期即将实施的工作包就可以分解成具体的活动。

3.模板

标准活动清单或以往项目的部分活动清单，经常可用做新项目的模板。模板中的活动属性信息，也 有助于定义活动。模板还可用来识别典型的进度里程碑。

4.专家判断

富有经验并擅长制定详细项目范围说明书、工作分解结构和项目进度计划的项目团队成员或其他专 家，可以为定义活动提供专业知识。

关键路径法

关键路径：是项目的最短工期，但却是从开始到结束时间最长的路径。进度网络图中可能有多条关键路径，因为活动会变化，因此关键路径也在不断变化中。关键路径可能有多条。

  

关键活动：关键路径上的活动，最早开始时间 = 最晚开始时间。

通常，每个节点的活动会有如下几个时间：Early  Start/Finsh;Last Start/Finsh

• (1)最早开始时间(ES),某项活动能够开始的最早时间。
• (2)最早结束时间(EF),某项活动能够完成的最早时间。EF=ES+工期
• (3)最迟结束时间(LF)。为了使项目按时完成，某项活动必须完成的最迟时间。
• (4)最迟开始时间(LS)。为了使项目按时完成，某项活动必须开始的最迟时间。LS=LF-工期

这几个时间通常作为每个节点的组成部分，如图所示：

顺推：最早开始 ES=所有前置活动最早完成 EF的最大值；最早完成 EF=最早开始 ES+持续时间。

逆推：最晚完成 LF=所有后续活动最晚开始 LS的最小值；最晚开始 LS=最晚完成 LF-持续事件。

总浮动时间(松弛时间):在不延误项目完工时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量，就是该活动的进度灵活性。正常情况下，关键活动的总浮动时间为零。 -- 针对路径的

总浮动时间 = 最迟开始 LS-最早开始 ES 或 最迟完成LF-最早完成EF 或 关键路径-非关键路径时长。

自由浮动时间：是指在不延误任何紧后活动的最早开始时间且不违反进度制约因素的前提下，活

动可以从最早开始时间推迟或拖延的时间量。 -- 针对单个活动的

自由浮动时间  =  紧后活动最早开始时间的最小值  -  本活动的最早完成时间。

总结：

1. 顺推取最大（前置的右上角最大）， 逆推取最小(后置的左下角的最小)。

顺推：最早开始ES = 所有前置活动最早完成EF的MAX

逆推：最晚完成LF=所有后续活动最晚开始LS的MIN

   顺推取最大值理解方式：当前活动的最早开始要开始那么它的前置活动必须都完成，前置活动中最早完成有大有小，要全部完成只能取最大的。

   逆推取最小值理解方式：当前活动的最晚完成要完成那么它不能耽误后置活动的进行，因为后续的活动开始的越早越好，所以后续后动最晚开始有大有小，取最小的。

2. 关键路径上的最早和最晚都是一样的

3. 总浮动时间/时差  =  最早 -  最早 = 最迟 - 最迟 = 关键路径 -  非关键路径(包含该活动的、并且是最长的那条)

4. 自由浮动时间/时差 = 后续活动的最早开始的Min（后置的左上角的最小）  -  本活动的最早完成（本活动的右上角）

C，C

表画图，

先求关键路径：ADFG=2+6+6+3=17

包含C的最长的一条非关键路径，ACEG=2+5+4+3=14。

总浮动时间 =  关键路径 - 非关键路径 = 3

2  软件配置管理

配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。在GB/T11457-2006 中将“配置管理”正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”

配置管理的6个活动： 制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

计划，做计划；然后标识哪些是配置项；知道了配置项得控制，比如版本；状态报告是方便查的，比如某个需求，从诞生到经过几个版本最终形成的；审计审查；最终发布管理，并交付用户。

 

配置项：GB/T11457-2006 对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待”。

 

以下内容都可以作为配置项进行管理：外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。

典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。

 

配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

 

所有配置项的操作权限应由CMO(配置管理员)严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向 PM、CCB及相关人员开放。

  

配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。

  

配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。如图所示

配置项版本号

(1)处于“草稿”状态的配置项的版本号格式为0.YZ,YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。

(2)处于“正式”状态的配置项的版本号格式为X.Y,X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0一9。

配置项第一次成为“正式”文件时，版本号为1.0。

如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0,1.1…。

当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时，X值将适量增加。

当配置项升级幅度比较大时，才允许直接增大X值。

(3)处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0,增加 X.Y值。参见上述规则(2)。

 

配置项版本管理：在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。

对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”,所以不能抛

弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

  

配置基线(常简称为基线)由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线

中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。

3 质量管理

质量是软件产品特性的综合，表示软件产品满足明确(基本需求)或隐含(期望需求)要求的能 力。

质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动；

主要包括以下过程：

(1)质量 规划 ：识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。-- 也是做个计划

(2)质量 保证 ：一般是每隔一定时间(例如，每个阶段末)进行的，主要通过系统的 质量审计(软件评审)和过程分析 来保证项目的质量。

(3)质量 控制 ： 实时监控项目的具体结果，以判断它们是否符合相关质量标准 ，制订有效方案，以消除产生质量问题的原因。

  

从管理角度出发，可以将影响软件质量的因素划分为 3 组，分别反映用户在使用软件产品时的3 种不同倾向和观点。这3 组分别是：产品运行、产品修改和产品转移。

软件质量保证(SQA)的关注点集中在于一开始就避免缺陷的产生。质量保证的主要目标是：

• (1)事前预防工作，例如，着重于缺陷预防而不是缺陷检查。
• (2)尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到下一个阶段。
• (3)作用于过程而不是最终产品，因此它有可能会带来广泛的影响与巨大的收益。
• (4)贯穿于所有的活动之中，而不是只集中于一点。

软件质量保证的主要任务：SQA 审计与评审、SQA报告、处理不符合问题。

4 风险管理

风险管理就是要对项目风险进行认真的分析和科学的管理，这样，是能够避开不利条件、少受损

失、取得预期的结果并实现项目目标的，能够争取避免风险的发生或尽量减小风险发生后的影响。但是，完全避开或消除风险，或者只享受权益而不承担风险是不可能的。

  

 风险管理过程

风险管理 计划 编制：如何安排与实施项目的风险管理，制定下列各步的计划。

 

风险 识别 ：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征

以及哪些项目可以产生风险，形成一个风险列表。

 

风险 定性分析 ：对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风

险类型。

 

风险 定量分析 ：进一步了解风险发生的可能性具体由多大，后果具体由多严重。包括灵敏度分析、

期望货币价值分析、决策树分析、蒙特卡罗模拟。

 

风险 应对计划 编制：对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风

险应对计划。包括消极风险(避免策略、转移策略、减轻策略);积极风险(开拓、分享、强大)。

 

风险 监控 ：监控风险计划的执行，检测残余风险，识别新的风险，保证风险计划的执行，并评价

这些计划对减少风险的有效性。

 

项目风险 ：作用于项目上的不确定的事件或条件，既可能产生威胁，也可能带来机会。

• 通过积极和合理的规划，超过90%风险都可以进行提前应对和管理。
• 风险应该尽早识别出来，高层次风险应记录在章程里。
• 应由对风险最有控制力的一方承担相应的风险。
• 承担风险程度与所得回报相匹配原则，承担的风险要有上限。

在信息系统项目中，从宏观上来看，风险可以分为项目风险、技术风险和商业风险。

项目风险是指潜在的预算、进度、个人(包括人员和组织)、资源、用户和需求方面的问题，以及它们对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的(估算)风险因素。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。

 

技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外，规格说明的多义性、技 术上的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。技术风险威胁到待开发系统的质量 和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。

 

商业风险威胁到待开发系统的生存能力，主要有以下5 种不同的商业风险：

(1)市场风险。开发的系统虽然很优秀但不是市场真正所想要的。

(2)策略风险。开发的系统不再符合企业的信息系统战略。

(3)销售风险。开发了销售部门不清楚如何推销的系统。

(4)管理风险。由于重点转移或人员变动而失去上级管理部门的支持。

(5)预算风险。开发过程没有得到预算或人员的保证。

补充其他：

项目范围：

在初步项目范围说明书中已文档化的主要的可交付物、假设和约束条件的基础上 准备详细的项目范围说明书，是项目成功的关键。

范围定义的输入包括以下内容：

• ①项目章程。如果项目章程或初始 的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。
• ②项目范围管理计划。
• ③ 组织过程资产，包括：

1. 用于制定项目范围说明书的政策、程序和模板；
2. 以往项目的项目档案；
3. 以往阶段或项目的经验教训。

• ④批准的变更申请。
• ⑤需求文件：使用需求文件来选择哪些需求将包含在项目中。

产品范围(Product Scope)

产品范围指的是与项目相关的特定产品、服务或成果的功能和特性。在信息系统项目中，产品范围可以包括软件应用程序的特定功能、系统的性能标准、技术规格和数据要求等。产品范围的定义通常包含在产品需求文档或系统需求规格(SRS)中。
产品范围的主要内容包括：

• 1.功能性要求：软件或系统必须执行的具体功能，如数据处理、用户管理、报告生成等。
• 2.非功能性要求：系统的性能标准，如响应时间、安全性、可用性等。
• 3.界面要求：系统与其他系统、硬件或软件的交互界面。
• 4.数据管理：数据结构、存储、处理和安全性要求

项目范围(Project Scope)
项目范围指的是为了做出具有既定功能或特性的最终可交付成果而必须实施的项目工作，包括技术工作和管理工作。它定义了项目的边界，包括项目的任务、活动、里程碑、资源、预算和时间表。项目范围通常在项目范围说明书或项目计划文档中详细描述。
项目范围的主要内容包括：

• 1.工作分解结构(WBS)：将项目工作细分为可管理和可控的小任务。
• 2.里程碑：项目的关键时间点和重要事件。
• 3.资源分配：项目所需的人员、资金、设备和材料。
• 4.风险管理：识别、评估和控制项目风险的计划。

联系与区别

联系：

• 1.产品范围和项目范围都是确保项目成功的关键要素。
• 2.产品范围直接影响项目范围，因为产品的功能和特性需求将决定必须完成哪些工作。
• 3.项目范围的制定和管理是为了确保满足产品范围的要求。

区别：

• 1.定义的焦点不同：产品范围关注的是最终交付的产品或服务的特性和功能，而项目范围关注的是实现这些产品或服务所需的工作。
• 2.变更管理：产品范围的变更通常影响项目的成本和时间线，而项目范围的变更可能不直接影响产品的功能或特性。
• 3.管理过程：产品范围的定义和变更通常需要客户或利益相关者的密切参与，而项目范围的管理更多是项目团队的责任。
• 4、先后顺序不同，先确定产品范围，后确定项目范围。
• 5、产品范围主要由项目发起人和客户确定，项目范围主要由项目经理和项目管理团队确定。