软件项目管理-期末收藏版

最新推荐文章于 2025-06-11 22:16:07 发布

原创最新推荐文章于 2025-06-11 22:16:07 发布 · 1.3k 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#软件项目管理 #期末 #笔记 #项目管理 #速成大全 #软件构建

考证与考试分享专栏收录该内容

5 篇文章

订阅专栏

前言 | 软件项目管理期末笔记速成指南

本博客旨在为大家提供一份精炼、易懂、速成的知识点梳理，帮助你在短时间内抓住考试重点，快速回顾关键概念，提高复习效率。无论你是想查漏补缺，还是临考突击，这份笔记都能助你一臂之力！

事先声明：本文是作者在上学期临近考试之余总结的笔记（转载请标明出处）

第一章-项目管理概述

项目的特征：（项目是为创造独特的产品，服务或成果而进行的体系化工作）

项目管理的定义：（特性：不可见，复杂，非一致性，易变形）

软件项目管理-两个层面

识别项目干系人：（重要性关注：影响项目程度高的+态度不支持）

项目管理知识体系-PMBOK

敏捷开发（计划驱动->价值驱动）--理念+优秀实践+具体应用

敏捷开发-价值观

1.个体和互动高于流程和工具

2.可工作的软件高于详尽的文档

3.客户合作高于合作谈判

4.响应变化高于遵循计划

常见的敏捷开发方法：Scrum,FDD,XP

敏捷原则

Scrum-敏捷方法

Scrum的优点：（精髓-小团队）

价值观：承诺-专注-勇气-公开-尊重

Scrum三大角色

Scrum三大工件（产品代表列表，迭代待办列表，产品增量）--必须可视化且透明

产品待办列表：反映产品的全貌和所有需求，动态变化。(产品负责人负责优先级排序）
迭代待办列表：反映当前Sprint的任务，开发团队全权负责。
产品增量：Sprint结束时交付的可用成果，是对之前工作的积累。

Scrum五个事件

Sprint规划会议：决定Sprint目标和工作范围。
每日站会：团队同步和问题透明化。（昨天完成了什么，今天将要完成什么，遇到什么困难风险）
Sprint评审会议：展示成果，收集反馈，调整产品方向。
Sprint回顾会议：分析流程改进，强化团队协作，反思优缺点提高团队效率。
Sprint本身：是时间固定、目标清晰的开发周期。

Scrum原则：

Srcum规划原则：

软件项目管理过程（项目初始-项目计划-项目执行控制-项目结束）

多层级规划

1. 产品规划

特点：
- 产品规划是最高层级的规划，目的是描述产品的愿景和整体方向。
- 它提供了产品的基本特性、功能范围以及实现目标的战略规划。
内容扩展：
- 产品规划以市场和用户需求为驱动，确定产品的核心价值和差异化优势。
- 产品规划并非一次性任务，应随着市场变化进行动态调整。

2. 版本规划

特点：
- 版本规划是中层规划，具体说明如何将产品目标分阶段实现。
- 每个版本代表产品的一个可交付阶段，输出的是“版本计划”。
内容扩展：
- 版本规划连接产品目标与迭代执行，明确短期实现的功能模块和时间节奏。
- 它的重点是合理拆解产品目标，同时保持与整体愿景的衔接。

3. 组合规划

特点：
- 组合规划是跨产品、跨版本的资源统筹与优先级管理工具。
- 通过组合规划，可以在资源有限的情况下优化多个项目之间的利益分配。
内容扩展：
- 组合规划需要从战略优先级出发，根据资源和业务价值最大化原则协调多个产品或版本的开发工作。
- 它注重资源利用效率，确保关键任务或高优先级目标优先实现。

第二章-项目策划与项目集管理

可行性成本效益分析：

净现金流量

投资回收期（关注累计净现金流转正的时间，转正时间-1+（累计现金流/当年现金流

投资收益率

资金时间价值-净现值-折现率

净现值-现值-折现率

内部收益率：是指项目在计算期内各年净现金流量现值累计等于0时的折现率

常见：试值法--找一正一负

IRR：找相似三角形

项目集经理和项目经理的区别

常见的生存期模型：

第三章-范围管理

敏捷需求管理

产品单板事项

用户故事（故事优先级：商业价值，收益，风险）

INVEST特性

独立性，清晰描述，有业务价值，小到可估算，可测试。

用户故事层级：

史诗（Epic）：史诗是大型的功能或一系列相关特性的集合，它可以进一步分解为更小的用户故事。史诗通常跨越多个迭代周期，并且可能涉及多个团队。
特性（Feature）：特性是一组相关的用户故事，它们共同实现一个具体的业务功能。特性比史诗更具体，但仍可能需要进一步细化。
用户故事（User Story）：用户故事是特性的组成部分，代表了最小可交付的工作单元，它是从终端用户角度描述软件需求的一种简洁方式。用户故事应当足够小，可以在一个迭代周期内完成。
任务（Task）：在一些框架中，任务被认为是实现用户故事的具体步骤。开发团队会将每个用户故事进一步分解成一系列具体的技术任务，这些任务是实现用户故事所需的工作单元。
子任务（Subtask）：子任务是任务的一个细分，通常是开发者为了跟踪具体的工作项而创建的细粒度工作项。

敏捷任务分解：

任务分解（WBS)

第四章-成本管理（金钱）

工作量-软件规模-成本

三种估算方法：

1.代码行估算法

先算出每个模块的期望规模行数 Ei=(ai+4mi+bi)/6

在根据劳动生产率算出工作量（Ei/Eoi=Mi)人月

最后根据成本费用*代码行数=成本--Ci=Coj*Ei（Coj为每行成本费用）

最后汇总

优缺点：

简单直观 易于适应小型项目

缺点： 不适用于不同的编程语言之间的对比 质量和复杂度的忽略

第二种算法：

根据第二种阶段性算法

Ci=Mi*ai i为第几个阶段，ai是某个阶段的工时费用率，Mi是每个模块的某个阶段的总和工时

四个阶段汇总可得C

两种算法对比

2.功能点估算法（FP--功能点）

根据元素个数或者引用文件类型查表--定级（计算每个部分的权重值汇总）==UFC未调整功能点

TCF=0.65+0.01（sum(Fi)),Fi各项复杂度

计算工时Effort与花费Cost

3.参数模型估算方法-COCOMO模型--计算工作量

基本模型

Effort= a*KLOCb

基本系数表

中级模型

Effort=a*KLOCb *F

乘法因子F=累乘可靠性因子（正常=1）

第五章-项目进度管理（时间）

任务定义：确定为完成项目的各个交付成果必须进行的各项活动。

网络图

PDM-单代号（有箭头，描述需要从开始--结束，方形图节点）-->ADM时，若是同时开始同时结束关系，需要一个虚活动代之

ADM-双代号（有箭头，箭头上是路径名称--描述完整路径即可--代号表示前一个任务的结束和后一个任务的开始，圆形图节点）

甘特图适用于可视化项目的任务时间安排和依赖关系，非常适合传统项目管理。

资源图用于管理和平衡资源的分配，确保资源不过载或闲置。

燃尽图用于敏捷项目中，展示剩余的工作量，便于团队跟踪冲刺的进度。

燃起图用于展示已完成工作和项目总工作量，特别适合项目需求变动较多的场景。

历时估算

定额估算

经验导出模型估算

关键路径法估算（总浮动=0，最长）

一般结合ADM图来计算项目历时和浮动时间--正推最早，逆推最晚

浮动时间：在不影响其他任务完成的情况下可以延迟的时间

TF总浮动：一个任务的上下减（LS-ES,LF-EF)

FF（自由浮动）：两个任务之间的差值

Druation:一般用PERT的值来代替，多个任务则取平均

工程评估评审技术（PERT）--计算历时

预留分析估算

管理预留：管理预留是为了管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的风险

应急预留：包含在进度基准中的一段储备时间，用来应对已经接受的已识别风险以应对进度方面的不确定性。

时间压缩法

1.先算每个任务的单位压缩成本

2.找关键路径上的任务进行压缩，压便宜的

3，注意压缩后关键路径可能会变化

敏捷开发下的估算方法

开发速度稳定前：举手表决

开发速度稳定后：基于故事点生产率估算，基于迭代生产率的估算

作业4选择题部分：

1. 关于迭代计划活动的错误理解

总结：迭代计划中的任务应以较小的工作量为单位（例如不超过8小时），以便于管理和跟踪；不应为未完成的任务设定绝对“零容忍”，而是关注问题并寻找解决方案；基础框架不是构建可靠计划的唯一手段，团队的承诺和协作同样重要。
扩展：迭代计划的核心在于让团队清晰了解目标、任务及时间分配，并灵活应对变化，而不是单纯依赖计划本身。

2. 关于迭代执行活动的正确描述

总结：每日站会是关键的团队同步会议，旨在发现问题和调整计划，但并非深入问题解决的场合。需求的优先级由产品负责人设定，团队需严格执行承诺的工作量。
扩展：执行活动的目标是保证开发进度的透明性和协作效率，站会应避免成为冗长的讨论或问题解决会，这些问题可以另行安排时间处理。

3. 关于迭代评审活动的错误理解

总结：评审的目标是展示成果、增加完成的目标，而非正式解决问题；不应强制使用复杂的PPT形式，关键在于让团队和利益相关者清晰理解增量价值。
扩展：评审是拉近团队与客户或利益相关者的关键机会，应更注重交流成果和获取反馈，而不是追求形式化的展示工具。

4. 关于看板法的错误认识

总结：看板法来源于精益思想，强调可视化管理和流程优化，其价值不仅体现在直观呈现业务，还包括持续改进的能力。单纯以看板为工具而无业务支撑将难以奏效。
扩展：看板法的成功关键在于合理设计工作流、明确每个任务的状态，并通过限制在制品数量（WIP）提升效率和质量。

5. 关于精益的错误理解

总结：精益的核心在于消除浪费，包括不必要的流程、代码冗余及资源浪费；同时，决策时的方案比较是优化的过程，不是浪费。误解多方案选择为浪费，是对精益概念的误用。
扩展：精益强调价值最大化与浪费最小化，需要结合系统性思考，避免将不必要的约束误认为精益原则的一部分。

第六章-质量管理

质量定义：是满足要求的程度，包括符合规定的要求和满足用户隐含需求。

软件质量：是指软件满足明确说明或者隐含的需求的程度

显性需求+隐性需求=开发规则

软件质量的属性：

质量的形成：在与产品或者服务的开发过程中，而不是事后的检查与测试。

质量成本：预防成本-前期缺陷成本-后期（质量是计划出来的，而非检查出来的）-越后发现质量成本越高

个体软件过程的原则（PSP)

软件系统的整体质量由该系统中质量最差的组件决定（木桶效应）

合格的软件工程师要求：

自己度量（时间，缺陷，规模），跟踪管理软件组件的质量
建立持续的自我改进机制

Yield指标（用于度量每个阶段在消除缺陷方面的效率）

Phase Yield=该阶段进入的缺陷数量/该阶段消除的缺陷数量

Process Yield=注入的缺陷总数/消除的缺陷总数（注意是在第一次编译前的阶段，不包括单元测试）

自主团队的定义：

软件质量管理活动

软件质量控制：确定项目结果与质量标准是否相符，同时确定不符的原因及其消除的方法，控制产品质量，及其纠正缺陷的过程。

质量管理的对象：

过程的质量：需求过程，设计过程
产品的质量：需求，设计说明书

常见的质量保证活动：技术审评，代码走查与审计，测试，数据分析。

敏捷项目质量（简答-辨析）

规划特征

全程质量审查
早发现问题，多版本提交
不断进行质量方法评估和改进

质量保证活动

结对编程： 、

结对编程通过协作、实时审查、知识共享和风险分散，提高代码质量、开发效率以及团队合作水平，特别适用于复杂问题的解决和敏捷开发环境。尽管结对编程需要更多的时间和人力投入，但长期来看其带来的收益往往超过成本。

TDD(测试驱动开发）：

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后编写相关的代码满足这些测试用例。
TDD具有以下几个优点：
它可以实现更快的创新和持续交付，因为代码是健壮的。
它使代码灵活且可扩展。可以重构或移动代码，将破坏代码的风险降至最低。
测试的一个关键特征是它可能会失败，开发团队会验证每个新测试是否失败。
根据设计，生成的代码易于测试。
实现需求几乎不需要浪费精力，因为只编写了所需的函数。

DevOps定义：DevOps是“开发（Development）”和“运维（Operations）”的融合，旨在通过流程、工具和文化的整合，实现软件开发与运维的高效协作，快速交付高质量的软件产品。

特点：

协作与整合：打破开发与运维之间的隔阂，促进团队协作。

持续交付：核心目标是从开发到部署的快速、持续交付。

自动化：强调流程自动化（如CI/CD流水线）以提升效率。

反馈快速：快速获取用户反馈并进行迭代优化。

高可靠性：通过监控和自动化工具，保证系统的稳定性和可用性。

第七章-辅助管理

决策树：

基线定义：它提供了软件生存期中各个开发阶段的一个特定点，标志开发过程一个阶段的结束，或者里程碑（它是配置项形成并通过审核从而形成的基线）

基线的修改需要按照正式的程序执行评估。（变更请求需要将相关配置项分配给SCCB，SCCB从技术，逻辑，策略，经济，组织及其基线层次来判断是否变更）

配置项-管理系统作用：1.维持产品完整性，2.版本管理，3.变更管理

软件风险管理：

三要素：风险事件，事件概率，事件影响

风险管理的过程：风险识别--风险评估--风险规划--风险控制

风险规划的策略：回避风险，转移风险，损失控制，自留风险

回避风险是指通过分析找出发生风险事件的原因，尽可能地规避可能发生的风险，采取主动放弃或拒绝使用导致风险的方案，进而直接消除风险损失，回避风险，具有简单、易行、全面、彻底的优点。
转移风险是指为避免承担风险损失，而有意识地将损失或与损失有关的财务后果转嫁给另外的单位或个人去承担。
损失控制是指在风险发生前消除风险可能发生的根源，并减少风险事件发生的概率，在风险事件发生后减少损失的程度。根据目的不同，又可进一步细分为损失预防和损失抑制。
自留风险是指由项目组织自己承担风险事件所致损失的措施。这种接受可以是积极的，一般是经过合理判断和谨慎研究后决定承担风险；或不知道风险因素的存在而承担下来，这是消极的自我承担。

敏捷项目风险应对方法：