软件项目管理期末复习（看这一篇就够了）_软件项目管理主要知识点

软件项目管理考试复习

🔶🔶🔶🔶🔶加了🔶的是考点

第一章软件项目管理概述

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.2项目立项

2.2.1立项流程🔶

立项阶段:

明确项目的目标、时间表、项目使用的资源和经费，而且得到项目发起人的认可。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S4qwFacL-63)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-.png)]

2.2.2自造-购买决策

在立项阶段，产品负责人进行自造-购买决策，确定待开发产品的哪些部分应当采购、外包开发或自主研发。

流程如下：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Gkhdn1sC-64)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yrSNeH2b-65)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-.png)]

2.3项目招投标

我们来梳理下甲方和乙方两者各自的区别：

甲方（需方） —— 提供需求方，一般是企业，作为客户。

乙方（供方） —— 满足需求方，一般是软件开发商。

甲方和乙方的职责：🔶

甲方（需方） —— 招标书定义，供方选择，合同签署。

乙方（供方） —— 项目分析，竞标，合同签署。

2.4项目章程🔶

项目章程，也可以称为是授权书。它包含以下两个部分：

（1） 一份正式批准项目并且授权项目经理在项目活动中使用组织资源的文件。

（2） 确认项目存在的文件，包括对项目的确认、对项目经历的授权和项目目标的概述等。

2.4.3项目经理的能力和职责

能力：

• 领导力
• 技术项目管理
• 战略和上午管理

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0skzalEG-68)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-.png)]

职责：

• 开发计划
• 组织实施
• 项目控制

第二章课后习题💯

第三章生存期模型

软件生存期模型的基本特征：

• 描述开发的主要阶段
• 定义每一个阶段要完成的主要过程和活动
• 规范每一个阶段的输入和输出

3.1.2生存期模型的类型🔶

生存期的模型的分类有以下四种，分别是：

• 预测型 —— 需求固定，项目活动只执行一次，提交一次，目标是成本可管理。
• 迭代型 —— 需求变化，重复执行直到正确为止，提交一次，目标是得到正确的解决方案。
• 增量型 —— 需求变化，特定增量的活动只执行一次，频繁地小增量提交，以速度为目标。
• 敏捷型 —— 需求变化，重复执行知道正确为止，频繁地小增量提交，通过频繁提交和反馈来体现客户价值。

选择生存期模型的步骤如下：

①熟悉各种生存期模型→②评审、分析项目的特性→③选择适合项目的生存期模型→④表示生存期模型与项目不一致地方，并进行裁减。

3.2预测型生存期模型

提前进行大量计划工作，然后一次性执行；执行是一个连续的过程。

3.2.1瀑布模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OTxGdXfO-73)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-.png)]

只能从上往下，不能返回。编码阶段不能修改需求和设计。

优点：

管理方便，只需要严格控制项目的执行顺序。

缺点：

项目的可变性无法适应瀑布模型的要求。

适用范围：

一般对需求很明确，且方案也很明确的项目使用，短期项目比较适应。

3.2.2v模型

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

3.3.迭代型生存期模型

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

原型模型：

通过构建不断构造原型来设计方案，最后确定了项目需求和系统设计。

优点：

可以应对需求的变化

适用范围：

适应于需求不明确，复杂度高，变更频繁的项目b

3.4增量型生存期模型

不同时开发项目需求，而是将需求分段，使其成为一系列增量产品，每一个增量可以分别实施。

每一个增量都是一个可交付成果，第一个往往是实现基本需求的核心产品。

①需求基本明确，但也有可能发生变化；②对于市场和用户把握需要逐步了解；③系统改造需要一步步实施。

适用范围：

• 对已有的产品升级或者新版本开发
• 对于完成期限要求严格的产品
• 对于所开发的领域比较熟悉而且已经有原型模型
• 对市场和用户把握不是很准

渐进式阶段模型

渐进式阶段模型是一种特殊的增量型生存期模型，每一个增量就是一个比较完整的系统

优点：

• 阶段式提交一个可运行的产品，而且每个阶段提交的产品是独立的系统
• 关键的功能更早出现，可以提高开发人员和客户的信心
• 通过阶段式的提交，可以早期预警问题，避免后期发现问题的高成本
• 通过阶段式提交可以运行的产品来说明项目的实际进展，减少项目报告的负担
• 阶段性完成可以减少估计失误，因为通过阶段完成的评审，可以重新估算下一阶段的计划
• 阶段性完成均衡了弹性与效率，提高开发人员的效率和士气

缺点：

• 需要精心规划各个阶段的目标
• 每一个阶段提交的是正式版本，所以工作量会增加

3.5敏捷型生存期模型

3.5.1Scrum🔶

核心是迭代和增量

一个迭代就是一个Sprint（冲刺），Sprint的周期被限制在一个月左右。Sprint是Scrum的核心。

• 团队角色
  • 产品负责人
  • Scrum主管
  • 开发团队
• 工件
  • 增量
  • 产品待办事项列表
  • Sprint待办事项列表
  • 燃尽图
• Scrum活动
  • 产品待办事项列表梳理
  • Sprint计划会议
  • 迭代式软件开发
  • 每日站立会议
  • 持续集成
  • Sprint评审会议
  • Sprint回顾会议

第三章课后习题💯

第四~五章软件项目范围计划

软件需求是值用户对软件的功能和性能要求，就是用户希望软件能做什么事情，完成什么功能，达到什么样的性能。软件需求的层次有以下三个方面的内容：

业务需求→用户需求→功能需求

4.2需求管理过程🔶

可以保证软件需求以一种形式描述一个产品应该具有的功能、性能等。需求过程的一个重要活动是系统需求，并建立相应的文档，好处是在开发后期和整个维护阶段的返工的工作量可以大大减少。

软件需求管理过程包含两个方面的内容，分别是需求开发和需求管理。

需求开发的路径是：需求获取→需求分析→需求规格编写→需求验证；而需求管理指的是：需求变更。

4.2.1需求获取

软件的需求具有模糊性、不确定性、变化性和主观性的特点。

首先我们要先分析用户的要求，分析完成之后，那么我们就要去获取这个用户的要求，并让软件去实现它。随之，软件就得到了软件需求。如下图所示：

4.2.2需求分析

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

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

4.2.3需求规格编写

需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。

4.2.4需求验证

在确定了需求之后，我们需要进行以下验证：

• 需求是正确的吗？正确性
• 需求是一致的吗？一致性
• 需求是完全的吗？完整性
• 需求是实际可行的吗？可行性
• 需求是必要的吗？必要性
• 需求是可检验的吗？可检验性
• 需求是可跟踪的吗？可跟踪性
• 最后的签字

4.2.5需求变更

是软件项目一个突出的特点，也是软件项目最为普遍的一个特点，是导致项目失败的主要原因之一

在软件的某些周期，我们总会遇到需求变更的问题。那对于需求变更来说，主要需要了解以下内容。

需求变更管理的主要工作有：

• 建立需求基线
• 确定需求变更控制过程
• 建立变更控制委员会 (SCCB)
• 进行需求变更影响分析
• 跟踪所有受需求变更影响的工作产品
• 建立需求基准版本和需求控制版本文档
• 维护需求变更的历史记录
• 跟踪每项需求的状态
• 衡量需求稳定性

需求变更控制流程

• 

4.3软件需求分析方法

4.3.1原型分析方法

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

结构化分析法（基于数据流建模）

（1）定义

• 20世纪70年发展起来的面向数据流的方法
• 是一种自顶向下逐步求精的分析方法
• 根据软件内部数据传递、变换的关系进行分析的
• 是结构化分析的主要方法

（2）结构化分析方法的技术

• 数据流图 (DFD)
  • 是一种描述软件系统逻辑模型的图形符号，无法判断活动的时序顺序
• 数据字典 (DD)
  • 用来描述系统中涉及的每个数据，是数据描述的集合，通常和DFD配合使用
• E-R 图
  • 用来描述系统需求要存储的数据信息
• 系统流程图
  • 表示操作顺序和信息流动过程的图标

3、面向对象的用例分析法（基于UML建模）

（1）定义

• 基于面向对象的情景分析方法
• 从用户角度出发考虑的功能需求
• 用例是系统向用户提供一个有价值的结果的某项功能
• 功能规范说明可以描述为对“需要系统做什么”的问题回答。
• 用例分析可以通过在该问题中添加几个字来描述：“需要该系统为每个用户做什么”

（2）UML需求视图

• 用例视图 - Use case Diagram
• 顺序图 - Sequence Diagram
• 状态图 - State Diagram
• 活动图 - Activity Diagram

4.3.4基于功能列表的实例

现在，我们来看一个基于功能列表的实例。如下图所示：

4.4敏捷项目需求分析🔶

4.4.3用户故事

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

• 用户故事模板

  As a<type of user>, I want<some goal>, So that<some reason>. 123 

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

• 评价用户故事
• 用户故事迭代优先级

  第一组： ①must have;②should have;③could 第二组： have/want to have 

5.1任务分解定义

5.1.1WBS🔶

（1）定义

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

（2）WBS和工作包

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

（3）WBS和工作包的区别

WBS 和工作包的区别如下：

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

5.1.3任务分解的形式

任务分解主要有两种形式，分别为：

• 提纲式WSB
  • 将任务分解的结果以清单的表述形式进行层层分解的方式
  • 类似于下方这样：

    1 变化计数器 1.1 比较两个版本的程序 1.1.1 1.1.2 1.1.3 1.2 找出修改后的程序中增加和删除的代码行 1.2.1 1.2.2 1.3 统计修改后的程序中增加和删除的代码行数 1.3.1 1.3.2 

• 图表形式WBS（组织机构图式WBS）

到此这篇软件项目管理期末复习（看这一篇就够了）_软件项目管理主要知识点的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/jszy-gual/8998.html