软件项目管理考试复习

加了的是考点

第一章软件项目管理概述

1.1.1项目及其特征

项目定义：

• 项目就是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力；
• 是以一套独特而互相联系的任务为前提，有效地利用资源，在一段时间内满足一系列特定目标的多项相关工作的总称。

日常运作和项目的区别：

1. 项目是一次性的，而日常运作是重复进行的。
2. 项目是以目标为导向的，日常运作是通过效率和有效性体现的。
3. 项目是通过项目经理及其团队工作完成的，日常运作是职能式的线性管理。
4. 项目存在大量的变更管理，日常运作基本保持持续的连贯性。

项目特征：

1. 目标性。
2. 相关性。
3. 临时性。
4. 独特性。
5. 资源约束性。
6. 不确定性。
7. 结果不可逆性。（早期教材中有）

1.1.3软件项目

特点：

1. 软件是一种逻辑实体而非具体的物理实体，具有抽象性，这使软件与其他的诸如硬件或者工程类项目有很多的不同之处。
2. 软件的生产与硬件不同，开发过程中没有明显的制造过程，也不存在重复生产过程。
3. 软件没有硬件的机械磨损和老化问题，然而，软件存在退化问题。在软件的生存期中，软件环境的变化导致软件的失效率提高。
4. 软件的开发收到计算机系统的限制，对计算机系统有不同程度的依赖。
5. 软件开发至今没有摆脱手工的开发模式，软件产品基本上是“定制的”，无法利用现有的软件组装成所需要的软件。
6. 软件本身是复杂的，其复杂性来自应用领域实际问题的复杂性和应用软件技术的复杂性。
7. 软件的成本相当高昂，软件开发需要投入大量资金和高强度的脑力劳动，因此成本比较高。
8. 很多软件工作涉及 会的因素，例如，许多软件开发受到机构、体系和管理方式等方面的限制。

软件项目是一种特殊的项目，她所创造的唯一产品或服务是逻辑载体，没有具体的形状和尺寸，只有逻辑的规模和运行的效果。

1.3.1项目管理的知识领域

1. 项目集成管理
2. 项目范围管理
3. 项目进度管理
4. 项目成本管理
5. 项目质量管理
6. 项目资源管理
7. 项目沟通管理
8. 项目风险管理
9. 项目采购管理
10. 项目干系人管理

1.3.2项目标准化过程组

1. 启动过程组：

   主要确定一个项目或一个阶段可以开始了，并要求着手实行；定义和授权项目或者项目的某个阶段

2. 计划过程组：

   为完成项目所要达到的商业要求而进行的实际可行的工作计划的设计、维护，确保实现项目的既定商业目标。计划基准是后面跟踪和监控的基础。

3. 执行过程组：

   根据制定的基准计划，协调人力和其他资源，执行项目管理计划或相关的子计划。执行过程存在两个方面的输入，一个是根据原来的基准来执行，另一个是根据监控中发现的变更来执行。主要变更必须在整体变更控制得到批准后才能够执行。

4. 控制过程组：

   通过监督和检测过程确保项目达到目标，必要时采取一些修正措施。集成变更控制是一个重要的过程。

5. 收尾过程组：

   去的项目或阶段的正式认可并且有序地结束该项目或阶段。向客户提交相关产品，发布相关的结束 告，更新组织过程资产并释放资源。

关系：

各个过程通过其结果进行连接，一个过程组的结果或输出是另一个过程组的输入。其中，计划过程组、执行过程组和控制过程组是核心管理过程组。

1.5.2敏捷宣言

4个核心价值：

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

12个敏捷原则：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。（持续交付）
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。（拥抱变化）
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。（时间盒）
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。（客户合作）
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。（信任团队）
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。（沟通方式，个体与互动）
7. 可工作的软件是进度的首要度量标准。（交付产品价值，可工作的软件）
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。（团队节奏）
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。（持续改进）
10. 以简洁为本，它是极力减少不必要工作量的艺术。（简洁）
11. 最好的架构、需求和设计出自自组织团队。（自组织，自管理）
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。（检视与调整）

第一章课后习题

2.3项目招投标

V模型是瀑布模型的一个变种，但强调测试与开发的利益关系，对系统性能、安全等有严格要求。

3.3.迭代型生存期模型

运行对未完成的工作进行反馈，从而改进和修改该工作

4.2.2需求分析

任务是借助当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统”做什么“的问题

需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 如下图所示：

4.3.1原型分析方法

原型分析方法是一种需求模型建模方法，需要经过三个步骤，分别是需求分析→原型方法→原型评价。如下图所示：

4.4敏捷项目需求分析

4.4.3用户故事

敏捷分析法包含以下三个部分，分别是：

• 用户故事模板

  用户故事常常写在卡片上，然后将其部署到墙上，便于讨论。

• 评价用户故事

• 用户故事迭代优先级

5.1任务分解定义

5.1.1WBS

（1）定义

• 任务分解指的是将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。

（2）WBS和工作包

• ，即 ，表示任务分解结构。 是任务分解的结果。
• 工作包，是 最低层次的可交付结果，是 的最小元素。

（3）WBS和工作包的区别

和工作包的区别如下：

• 是对项目由粗到细的分解过程；
• 是面向交互结果的；
• 同时， 组织定义了整个项目范围；
• 而工作包是 中最低层次的可交付成果（如下图所示）；
• 且工作包应当由唯一主体负责。

五大步骤

任务分解的过程要经过三个过程，输入→分解→ 。有以下步骤：

• 确认并分解项目的主要组成要素
• 确认分解标准
• 确认分解是否详细
• 确认项目交付成果（可以编写 WBS 字典 ）
• 验证分解正确性

分解标准

任务分解的过程有两大标准，分别是：

• 分解标准应统一；
• 不能同时使用两种标准进行分解。

5.2.2任务分解方法

任务分解有4种方法，分别是：

• 模板参照
  • 用该项目的领域WBS参照分解
• 类比
  • 有些项目在某种程度上具有相似性；
  • 可以采用类似的 作为参考。
• 自顶向下
  • 最好的方法

5.3任务分解结果

（1）检验分解结果标准

• 最底层要素是否是实现目标的充分必要条件；
• 最底层要素是否有重复的；
• 每个要素是否清晰完整定义；
• 最底层要素是否有定义清晰的责任人；
• 是否可以进行成本估算和进度安排。

（2）WBS任务分解建议

• 最低层是可控的和可管理的，但是不必要过细；
• 每个 必须有一个提交物；
• 定义任务完成的标准；
• 有利于责任分配；
• 推荐任务分解到40小时以内。

5.3.2任务分解的重要性

WBS重要性：

• WBS明确了完成项目所需的工作
• WBS建立时间观念
• WBS提供了一种控制手段
• WBS是范围基线的重要组成部分
• WBS可以即使提示是否更变

第四五章课后习题

2）外部输出(External Outputs:EO)

向用户提供（经过处理的）面向应用的信息，例如， 表和出错信息等。 如下图所示：

4）外部接口文件（External Interface Files :EIF’s）

用户可以识别的一组逻辑相关数据，这组数据只能被引用。用这些接口把信息传送给另一个系统。 如下图所示：

（5）功能计数项的复杂度等级

下面给出功能计数项的复杂度等级，如下图所示：

（2）基本步骤

用例点估算方法的基本步骤为：

• 计算未调整的角色的权值 ;
• 计算未调整的用例的权值 ;
• 计算未调整的用例点 ;
• 计算技术和环境因子 和 ;
• 计算调整的用例点 ;
• 计算工作量 ( ) 。

接下来将依据这几个内容进行展开介绍。

（3）计算未调整的角色的权值UAW

公式： U A W = ∑ C = c a W e i g h t ( c ) × a C a r d i n a l i t y ( c ) UAW=∑_{C=c}aWeight× aCardinalityem>UAW=∑C=caWeigh**t(c)×aCardinalit**y(c)