学前说两句
项目管理是非常重要的一个章节，你可以理解位整个项目管理贯穿于整个软件开发的周期，无论是需求、设计、开发、测试等等，这个章节会有一些计算题，还会有关键路劲的计算，这是必须要掌握的。
盈亏平衡分析
盈亏平衡的时候，说明利润为0
税费=销售额*税率
固定成本：无论卖多少台电脑，都要花费240w
可变成本和卖的设备数量有关系，卖2w台设备会变为3000w的成本，那么一台成本在1500块
此时假设A台会平衡
2500*A=2400000+1500*A+2500*A*0.16
A=4000
进度管理
工作分解结构【WBS】
工作分解结构（Work Breakdown Structure，简称 WBS）是项目管理中的核心工具，用于将项目整体目标分解为可管理、可交付的具体任务或工作包。
进度管理
WBS工作包确定好之后，就可以作为进度管理的输入了
活动定义
就是在这个项目中应该开展的工作
活动排序
就是给工作定义依赖关系，比如先干什么后干什么，因为有些工作需要依赖其它的工作，必须要有先后顺序
B和D依赖A，所以B需要在A完成之后，才能开始进行
活动资源估算
每项工作是多少人/日
活动历时估算
可以估算出需要多少时间完成，比如评估10/人日，那么安排5个人来做，差不多就是2天了
制定进度计划
制定进度计划（关键路径法）
基于关键路径法，可以将整个项目中的每一个节点计算出：最早开始时间、最早完成日期、最迟开始时间、最迟完成日期，然后再此基础上计算出松弛时间，并且规划出最长路径。
关键路径是最长路径，最长路径对应最短工期
A->H有多条路径，怎样才算把整个项目完成了呢，应该是A到H中的每个节点的任务都完成了。所以当你把最长的路径的活干完了，那么就意味着，从A到H的所有节点都完成了，所以关键路径是最长路径，此时对应的是最短工期。并不是最短路径，最短路径意味着可能把一些节点给丢掉了
如何求解最长路径？
笨方法：只需要把A到H的所有的路径全部列出来，此时求最大的，就是真个项目的最长路径
好方法：每个节点的总时差是LS-ES或者LF-EF，然后把总时差为0的节点连起来，就构成了关键路径
关键路径可能有多条，项目管理人员不希望有多条关键路径，关键路径的资源是必须要保证的
总时差越大说明宽松时间是比较高的，总时差越小说明时间越紧张
实例：
为了便于讲解，我将一个节点的6个数字，分别表示为节点名+左上、节点名+上、节点名+右上、节点名+左下、节点名+下、节点名+右下，以A节点举例：
A+左上 0
A+上 5
A+右上 5
A+左下 0
A+下 0
A+右下 5
关键计算路径是这样的：
第一步：构建初始的项目图，只有每个项目节点的估算的工作量
第二步：从左到右，计算每个项目节点的最早开始时间和最早完成时间，也就是每个项目节点的左上和右上两个节点的值
首先A作为起始点，那么A的最早开始时间肯定是0，那么A的最早结束时间是0+5=5
B和C依赖A：
先看B,A在5的时候开始完成，那么5就是B的最早开始时间，B的最早结束时间就是5+2=7
再看C,C在5的时候开始完成，那么5就是C的最早开始时间，C的最早结束时间就是5+8=13
E依赖C，那么E的最早开始时间就是13，E的最早结束时间就是18
D依赖B和C，那么C比B要完成的晚，所以D的最早开始时间只能是13，最早结束时间为23
F依赖D，那么F的最早开始时间为23，那么最早结束时间为23+10=33
G依赖D，那么D的最早开始时间为23，那么最早结束时间为23+15=38
H依赖F和G，那么H的最早开始时间为38，那么最早结束时间为38+10=48
此时就正向算完了，我们可以得到下面的图：
第三步：
从右到左。
H的最早完成时间为48,那么H的最晚结束时间也要为48，此时H的最晚开始时间就是48-10=38
F和G依赖H，那么F和G的最晚结束时间为38，此时F的最晚开始时间为38-10=28，G的最晚开始时间为38-15=23
D依赖F和G，那么D的最晚结束时间为23（取F和G的最早开始时间中最小的），D的最晚开始时间为13
E依赖G，所以E的最晚结束时间为23，最晚开始时间为18
B依赖D,B的最晚结束时间为13，B的最晚开始时间为11
C依赖E和D，C的最晚结束时间为13，C的最晚开始时间为13-8=5
A依赖B和C，A的最晚结束时间为5，A的最晚开始时间为0
所以此时可以得到：
第四步：计算出松弛时间
第五步：得到关键路径
关键路径就是路径上为松弛时间为0的节点的连接线，我们可以看到B的松弛时间为6，也就意味着B项目的人员摸鱼6天都是可以的，不会影响到整个项目的推进。
这个项目最终的节点有E和F，由于E的最早完成时间为14大于F的最早完成时间，所E和F的最晚结束时间应该为14
首先我们必须可以得到的是，整个项目的网络图，那么关键路径就很好算了，目前来看只有两条路径：
=========================================================================
A-B 10天
A-C-D 12天
此时可以说明A-C-D就是关键路径，此时的总花费为
12*5=60 （间接费用）
10+15+12+18=55 （A B C D 的总费用）
总共115
=======================================================================
现在我们的思路很简单，就是先想办法改变关键路径
首先可以修改D，将D的总时间从5天缩短为2天，此时A-C-D的总时长变为了9天
A-B 10天
A-C-D 9天
此时的关键路径就是A-B了，此时的总花费为
10*5=50
10+15+12+18+2*3=61（A B C D 的总费用，包含D的加班费用）
此时总花费为111
=======================================================================
现在要考虑A-B，假设改变B，将B的工时缩短两天（不能再缩短了，缩短也没有意义了，因为关键路径变为A-C-D了），此时A-B为8，
A-B 8天
A-C-D 9天
此时，关键路径变为了A-C-D 9天了，此时总花费为
9*5=45
10+15+12+18+2*3+2*2=65
此时总花费为110
========================================================================
现在考虑A-C-D，只能修改A和C，先来看C，如果将C缩短至2天，此时关键路径为A-B，为8，
A-B 8天
A-C-D 7天
此时的费用为
8*5=40
10+15+12+18+2*3+2*2+2*4=71
总费用为111，不降反升，说明不能修改C
=========================================================================
再来看A，A只要降低，会影响到所有，直接将A降低至1天，此时关键路径A-C-D为7，
A-B 6天
A-C-D 7天
此时花费为
7*5=35
10+15+12+18+2*3+2*2+4*2=73
总费用为108
=======================================================================
现在能降低的都已经降低了，现在看看能不嫩将A-B中的B升高掉，将B由降低两天变为降低一天，这样就可以再次减少2w的花费
A-B 7天
A-C-D 7天
7*5=35
10+15+12+18+2*3+2*2+4*2-2=71
总花费为106
一些项目节点关系的说明
F表示完成，S表示开始，FS表示完成开始，以此类推
FS：A完成B开始
FF：A完成B完成
SS：A开始B开始
SF：A开始B完成
以上表示活动和活动之间的关系
进度计划的工作（甘特图Gantt）
细线代表估计完成的时间安排
粗线代表目前的现状
甘特图的缺陷就是关键路径法网络图的优点
进度控制
已经排了计划，但是计划执行过程中可能会存在一些问题，使得某些活动延误了。
比如某个活动延误了，我们需要确定它是不是关键活动，如果是关键活动，那么延误了2天，就有可能造成整个项目延迟2天了。那么不是关键活动是不是就可以随便延误了，其实要看单个活动的松弛时间，以及整个项目的总时差，如果在这个允许的范围内，那么不会对项目造成影响的。如果超过了，那么这个节点就会从非关键路径的节点到关键路径上的节点了，此时就不得不考虑它了
软件质量
影响软件质量的3组因素
软件质量控制与质量保证
质量保证是QA，指令控制是QC
质量保证是过程中管理
质量控制是结果的审核
软件能力成熟度模型集成(CMMI）
随便给一个特点，需要知道是哪个等级
软件配置管理
软件变更控制
软件再变更过程中需要依据一定的流程和规则，不能随便变更
软件版本控制
1.1不能直接跳转到1.5
1.1也不能直接跳转到2.1，只能到2.0
软件工具
思维导图
### 项目管理
├── 0️ 软件项目管理的主要管理要素
│ ├── 人员
│ ├── 产品
│ ├── 过程
│ └── 项目
├── 1️ 盈亏平衡分析（★）
│ ├── 基本概念
│ │ ├── 正常情况下：销售额 = 固定成本 + 可变成本 + 税费 + 利润
│ │ └── 盈亏平衡时：销售额 = 固定成本 + 可变成本 + 税费
│ ├── 关键术语
│ │ ├── 固定成本：不随产量变化
│ │ │ ├── 酌量性固定成本（广告费、员工培训费、技术开发经费）
│ │ │ └── 约束性固定成本（折旧费、租金、管理人员工资）
│ │ ├── 可变成本：随产量正比例变动
│ │ │ ├── 酌量性变动成本（开发奖金、外包费用）
│ │ │ └── 约束性变动成本（直接材料费、产品包装费）
│ │ └── 税费：按销售额一定比例计算
│ ├── 示例
│ │ └── 20万信息费带来100万利润，信息利润80万
│ └── 计算步骤（★★★）
│ ├── 第一步：单件可变成本 = 总可变成本 ÷ 总商品数
│ ├── 第二步：设盈亏平衡销量为 x
│ ├── 第三步：方程 单价×x = 固定成本 + (单件可变成本×x) + (单价×x×税率)
│ └── 第四步：x = 固定成本 ÷ [单价×(1−税率) − 单件可变成本]
├── 2️ 进度管理（★★★）：对时间的管理
│ ├── 项目时间管理中的过程
│ │ ├── 活动定义：WBS
│ │ │ └── WBS分解原则（≤6层、可控、有交付成果、有完成标准）
│ │ ├── 活动排序
│ │ ├── 活动资源估算
│ │ ├── 活动历时估算（专家判断、三点估算法、功能点、自上而下、自下而上）
│ │ ├── 制定进度计划（关键活动：总时差=0且自由时差=0）
│ │ └── 进度控制（赶工、快速跟进）
│ └── 进度管理工具
│ ├── 关键路径法（ES、EF、LS、LF、总时差）
│ └── 甘特图（直观、简单、不能表示依赖关系）
├── 3️ 软件质量管理（★★）
│ ├── 影响软件质量的三大因素
│ │ ├── 产品运行（正确性、健壮性、效率、完整性、可用性、风险）
│ │ ├── 产品修改（可理解性、可维修性、灵活性、可测试性）
│ │ └── 产品转移（可移植性、可再用性、互运行性）
│ ├── 软件质量控制：实时监控、纠偏
│ ├── 软件质量保证：事前预防、过程审计（代码评审）
│ ├── 软件能力成熟度模型集成（CMMI）
│ │ ├── 定义：CMMI是软件企业进行多方面能力评价的、集成的成熟度模型
│ │ ├── 五个成熟度等级
│ │ │ ├── 1. 初始级：过程不可预测，架构常缺失或混乱；组织过程完全依赖于个人能力和英雄主义
│ │ │ ├── 2. 已管理级：需求可追溯，架构文档化逐步建立（项目级，单个项目）；组织能够策划、执行、监督和控制项目级过程
│ │ │ ├── 3. 已定义级：标准架构模板、设计评审制度化（企业级，多个项目）；组织资产的积累从已定义级（Level 3）就开始了
│ │ │ ├── 4. 量化管理级：架构质量属性（性能、可修改性）被量化度量；核心在于建立了产品质量、服务质量以及过程性能的定量目标，并能够对过程性能进行可靠的预测；与已定义级（Level 3）的关键区别在于过程性能的可预测性
│ │ │ └── 5. 优化级：基于架构度量数据进行持续优化；组织能够持续优化和创新过程；组织使用从多个项目收集来的数据对整体的组织级绩效进行关注
│ │ ├── 注：连续式与阶段式本质一致
│ │ └── 实施本地化与体系文件结构
│ │ ├── 组织体系编写组，建立基于CMMI的软件质量管理体系文件
│ │ └── 四层文件层次（自顶向下）
│ │ ├── 1) 方针文件
│ │ ├── 2) 过程文件
│ │ ├── 3) 指南/规范文件
│ │ └── 4) 模板文件（Word/Excel）
│ ├── 数据管理能力成熟度模型（DCMM）
│ │ ├── 定义：定义了数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准和数据生存周期等8个核心能力域，细分为28个过程域和445条能力等级标准
│ │ ├── 成熟度等级（5级）：初始级(1级) → 受管理级(2级) → 稳健级(3级) → 量化管理级(4级) → 优化级(5级)
│ │ ├── 8个核心能力域
│ │ │ ├── 数据战略（规划、实施、评估）
│ │ │ ├── 数据治理（组织、制度建设、沟通）
│ │ │ ├── 数据架构（数据模型、分布、集成与共享、元数据管理）
│ │ │ ├── 数据应用（分析、开放共享、服务）
│ │ │ ├── 数据安全（策略、管理、审计）
│ │ │ ├── 数据质量（需求、检查、分析、提升）
│ │ │ ├── 数据标准（业务数据、参考数据和主数据、数据元、指标数据）
│ │ │ └── 数据生存周期（需求、设计和开发、运维、退役）
│ │ ├── 核心价值点（数据地位升级、管理方式进化、组织影响深化）
│ │ └── 适用对象与用途
│ └── 数据安全治理体系
│ ├── 三大目标（合规、风险、开发利用）
│ ├── 目标双重性
│ └── 能力框架（评估维度、评估框架金字塔、评估等级）
├── 4️ 软件配置管理（SCM）（★★）
│ ├── 定义：通过技术和行政手段对产品及其开发过程和生命周期进行控制
│ ├── 基本概念
│ │ ├── 产品配置：生命周期各阶段产生的各种形式的文档、计算机程序、部件及数据的集合
│ │ └── 配置项：基线配置项（需求、设计、源代码、可执行代码、测试用例）、非基线配置项（计划、报告）
│ ├── 配置项的状态：草稿、正式发布、正在修改
│ ├── 核心内容：版本控制、变更控制
│ ├── 配置库的类型：动态库（开发库）、受控库（主库）、静态库（产品库）
│ ├── 版本控制规则（0.YZ → X.Y → X.YZ）
│ ├── 版本控制流程
│ └── 包括配置管理的体系：ISO9000、PMBOK、CMMI
├── 5️ 软件工具分类
│ ├── 软件开发环境（Software Development Environment）
│ │ ├── 定义：支持软件产品开发的软件系统，由软件工具集和环境集成机制构成
│ │ ├── 软件工具集：用来支持软件开发的相关过程、活动和任务
│ │ └── 环境集成机制：为工具集成和软件开发、维护和管理提供统一的支持
│ │ ├── 数据集成机制：提供存储或访问环境信息库的统一数据接口规范
│ │ ├── 控制集成机制：支持各开发活动之间的通信、切换、调度和协同工作
│ │ └── 界面集成机制：采用统一的界面形式，提供统一的操作方式
│ └── 按软件过程活动分类
│ ├── 软件开发工具：辅助开发人员进行软件开发活动
│ │ ├── 需求分析工具：辅助生成完整、清晰、一致的功能规范
│ │ │ ├── 基于自然语言或图形描述的工具（如数据流图）
│ │ │ ├── 基于形式化需求定义语言的工具（知识库+推理机制）
│ │ │ └── 其他需求分析工具（可执行规范、原型技术）
│ │ ├── 设计工具：辅助从功能规范得到设计规范
│ │ ├── 编码与排错工具
│ │ │ ├── 编码工具（编辑程序、汇编程序、编译程序、生成程序）
│ │ │ └── 排错工具（源代码排错程序、排错程序生成程序）
│ │ └── 测试工具：辅助软件测试活动
│ ├── 软件维护工具：辅助维护人员对代码及文档进行维护
│ │ ├── 版本控制工具（VSS、CVS、SCCS、SVN）
│ │ ├── 文档分析工具
│ │ ├── 开发信息库工具
│ │ ├── 逆向工程工具
│ │ └── 再工程工具
│ └── 软件管理和软件支持工具：辅助管理人员和支持人员
│ ├── 项目管理工具
│ │ ├── 定义：辅助计划、调度、通信、成本估算、资源分配及质量控制
│ │ ├── 特征（9项）：覆盖全周期、多种调度手段、估算模型、多项目管理、关键路径/松弛时间等、辅助通信、资源平衡、资源跟踪、生成报表
│ │ └── 典型例子：成本估算工具
│ ├── 配置管理工具（版本控制、变更管理、状态管理、访问控制）
│ └── 软件评价工具
├── 6️ 范围管理
│ ├── 产品范围：产品应包含的功能
│ ├── 项目范围：为交付产品所必须做的工作
│ ├── 关系：产品范围是项目范围的基础
│ ├── 产品范围定义：信息系统要求的度量
│ ├── 项目范围定义：生产项目计划的基础
│ ├── 产品范围描述：项目范围说明书的重要组成部分
│ └── 项目范围定义的输入
│ ├── 范围管理计划
│ ├── 项目章程
│ ├── 需求文件
│ ├── 批准的变更申请
│ └── 组织过程资产（政策/模板、项目档案、经验教训）
├── 7️ 风险管理
│ ├── 项目风险定义：不确定的事件或条件，可能对项目目标产生正面或负面影响
│ └── 软件风险分类
│ ├── 项目风险
│ ├── 技术风险
│ └── 商业风险（5方面：无人使用、不符公司策略、销售部不知如何销售、失去高层支持、预算/人员未保证）
├── 8️ 软件文档管理
│ ├── 用户文档：功能描述、安装文档、使用手册、参考手册、操作员指南
│ └── 系统文档：问题定义、需求说明、设计、实现、测试等
└── 9️ 成本管理
└── 成本预算：将总成本估算分配到各项活动和工作包，建立成本基线项目管理
├── 0️ 软件项目管理的主要管理要素
│ ├── 人员
│ ├── 产品
│ ├── 过程
│ └── 项目
├── 1️ 盈亏平衡分析（★）
│ ├── 基本概念
│ │ ├── 正常情况下：销售额 = 固定成本 + 可变成本 + 税费 + 利润
│ │ └── 盈亏平衡时：销售额 = 固定成本 + 可变成本 + 税费
│ ├── 关键术语
│ │ ├── 固定成本：不随产量变化（如设备折旧、租金、管理人员的工资、办公费、固定资产折旧费、员工培训费）
│ │ │ ├── 分类
│ │ │ │ ├── 酌量性固定成本：管理层的决策可以影响其数额（如广告费、员工培训费、技术开发经费）
│ │ │ │ └── 约束性固定成本：管理层无法决定其数额，必须开支（如办公场地及机器设备的折旧费、房屋及设备租金、管理人员的工资）
│ │ ├── 可变成本：随产量变化，与销售额成比例。在一定时期和一定业务量范围内其总额随着业务量的变动而成正比例变动
│ │ │ ├── 示例：直接材料费、产品包装费、外包费用、开发奖金
│ │ │ ├── 分类
│ │ │ │ ├── 酌量性变动成本：如开发奖金、外包费用
│ │ │ │ └── 约束性变动成本：通常表现为系统建设的直接物耗成本，以直接材料成本最为典型
│ │ └── 税费：按销售额的一定比例计算
│ ├── 示例
│ │ └── 某公司支出20万元购买了某市场预测信息，由于此信息的采纳，公司多得到了100万元的利润，对公司而言，这个市场预测信息的利润是80万元
│ └── 计算步骤（★★★）
│ ├── 第一步：计算单件商品的可变成本
│ │ ├── 已知：总商品数、总可变成本
│ │ └── 公式：单件可变成本 = 总可变成本 ÷ 总商品数
│ ├── 第二步：设定变量
│ │ └── 设盈亏平衡时的销售数量为 x（台/件）
│ ├── 第三步：建立方程
│ │ ├── 销售额 = 单价 × x
│ │ ├── 可变成本总额 = 单件可变成本 × x
│ │ ├── 税费总额 = 单价 × x × 税率
│ │ └── 方程：单价 × x = 固定成本 + (单件可变成本 × x) + (单价 × x × 税率)
│ └── 第四步：解方程求 x
│ ├── 移项合并同类项
│ ├── 解得 x = 固定成本 ÷ 单价 × (1 − 税率) − 单件可变成本
│ └── 注：注意单位统一（元/万元）
├── 2️ 进度管理（★★★）：对时间的管理
│ ├── 项目时间管理中的过程包括
│ │ ├── 活动定义：工作分解结构WBS
│ │ │ └── WBS分解原则
│ │ │ ├── WBS的工作包应该是可控和可管理的，不能过于复杂
│ │ │ ├── 任务分解不能过细，一般原则是WBS的树形结构不超过6层
│ │ │ ├── 每个工作包应该有一个交付成果，而不是多个
│ │ │ └── 每个任务必须有明确定义的完成标准
│ │ ├── 活动排序
│ │ ├── 活动资源估算
│ │ ├── 活动历时估算
│ │ │ ├── 专家判断法
│ │ │ ├── 三点估算法：（乐观时间 + 悲观时间 + 最可能时间 × 4）/ 6
│ │ │ ├── 功能点估算法
│ │ │ ├── 自上而下估算
│ │ │ └── 自下而上估算
│ │ ├── 制定进度计划
│ │ │ ├── 判断是否为关键活动
│ │ │ ├── 关键活动的核心特征是总时差为0且自由时差为0
│ │ │ ├── 偏差是否大于总时差
│ │ │ └── 偏差是否大于自由时差
│ │ └── 进度控制
│ │ ├── 赶工：增加资源压缩工期
│ │ └── 快速跟进：活动并行执行
│ │
│ └── 进度管理工具【制定进度计划、进度控制】
│ ├── 关键路径法
│ │ ├── 定义：不考虑资源限制，计算最早/最晚时间
│ │ ├── 最早开始时间（ES）
│ │ ├── 最早完成时间（EF）
│ │ ├── 最迟开始时间（LS）
│ │ ├── 最迟完成时间（LF）
│ │ └── 总时差（松弛时间）
│ │ ├── 公式：LS − ES 或 LF − EF
│ │ └── 意义：活动可延迟时间，不影响总工期
│ └── 甘特图（Gantt）
│ ├── 特点：能清晰描述每个任务的开始和截止时间，能有效获得任务并行进行的信息
│ ├── 优点：直观、简单、易制作、便于理解
│ ├── 适用：小型项目、WBS任意层次、进度控制、资源优化
│ └── 缺点：不能表示各任务之间的依赖关系
├── 3️ 软件质量管理（★★）
│ ├── 影响软件质量的三大因素
│ │ ├── 产品运行
│ │ │ ├── 正确性：是否按需求工作
│ │ │ ├── 健壮性：对意外环境的响应
│ │ │ ├── 效率：资源消耗情况
│ │ │ ├── 完整性：安全性
│ │ │ ├── 可用性：是否易用
│ │ │ └── 风险：是否按计划完成
│ │ ├── 产品修改
│ │ │ ├── 可理解性：是否易于理解
│ │ │ ├── 可维修性：是否易于修复
│ │ │ ├── 灵活性：是否易于变更
│ │ │ └── 可测试性：是否易于测试
│ │ └── 产品转移
│ │ ├── 可移植性：是否可在其他环境运行
│ │ ├── 可再用性：是否可复用部分组件
│ │ └── 互运行性：是否可与其他系统集成
│ │
│ ├── 软件质量控制
│ │ ├── 定义：实时监控，判断是否符合软件质量标准
│ │ ├── 目的：制定有效方案，消除质量产生的原因
│ │ └── 特点：实时性、监控性、纠偏性
│ ├── 软件质量保证
│ │ ├── 定义：周期性执行的质量管理活动
│ │ ├── 特点：事前预防，不让缺陷扩散到下一阶段
│ │ ├── 作用：作用于过程，贯穿于活动之中
│ │ └── 主要活动
│ │ ├── 质量审计（代码评审）
│ │ └── 过程分析
│ │
│ ├── 软件能力成熟度模型集成（CMMI）
│ │ ├── 成熟度等级（阶段式）
│ │ │ ├── 初始级（L1）：随意、混乱、依赖个人能力
│ │ │ ├── 已管理级（L2）：项目级可重复，建立项目级控制过程
│ │ │ ├── 已定义级（L3）：组织级文档化、标准化，到公司层面了
│ │ │ ├── 定量管理级（L4）：量化式管理，过程性能可预测
│ │ │ └── 优化级（L5）：持续优化
│ │ ├── 文件体系
│ │ │ ├── 方针文件：过程文件及其他相关文件都应遵循方针文件
│ │ │ ├── 过程文件：根据过程文件模板编制各 PA 过程文件，并对流程进行描述
│ │ │ ├── 指南/规范文件：结合相应模板清晰说明如何完成这项工作，并标明对应的标准和需求
│ │ │ └── 模板文件：模板分为两类，一类是 word 文档模板，一类是 excel 表格模板
│ │ └── 注：连续式与阶段式本质一致
│ │
│ ├── 数据管理能力成熟度模型（DCMM）
│ │ ├── 核心能力域（8个）
│ │ │ ├── 数据战略
│ │ │ ├── 数据治理
│ │ │ ├── 数据架构
│ │ │ ├── 数据应用
│ │ │ ├── 数据安全
│ │ │ ├── 数据质量
│ │ │ ├── 数据标准
│ │ │ └── 数据生存周期
│ │ ├── 成熟度等级（5级）
│ │ │ ├── L1 初始级：数据需求管理是项目级体现；无统一流程；被动式管理
│ │ │ ├── L2 受管理级：组织意识到数据是资产；按策略制定流程；指定人员初步管理
│ │ │ ├── L3 稳健级：数据是绩效目标资产；组织层面建立标准化流程，促进规范化管理
│ │ │ ├── L4 量化管理级：数据是竞争优势资源；效率可量化分析和监控
│ │ │ └── L5 优化级：数据是组织生存发展的基础；管理流程可实时优化；行业最佳实践分享
│ │ ├── 核心价值点
│ │ │ ├── 数据地位升级：从"项目附属品" → "战略资产" → "竞争优势源泉"
│ │ │ ├── 管理方式进化：从"被动/零散" → "主动/规范" → "量化/智能优化"
│ │ │ └── 组织影响深化：从"局部执行" → "部门协同" → "全组织标准化" → "行业标杆"
│ │ ├── 适用对象与用途
│ │ │ ├── 适用于企业、政府机构等组织进行数据管理能力自评或第三方评估
│ │ │ ├── 用于指导数据治理体系建设、数字化转型路径规划
│ │ │ └── 是衡量数据驱动型组织成熟度的重要标尺
│ │ └── 总结：DCMM 提供了一个从 L1 到 L5 的五级成熟度模型，帮助组织系统评估并提升其在数据战略、治理、架构、应用、安全、质量、标准及生命周期等方面的综合管理能力，最终实现数据驱动的价值最大化
│ │
│ └── 数据安全治理体系
│ ├── 三大目标（前提）
│ │ ├── 满足合规要求
│ │ ├── 管理数据安全风险
│ │ └── 促进数据开发利用
│ ├── 目标双重性：既保障安全，又推动业务发展
│ ├── 能力框架（三个维度）
│ │ ├── 评估维度（左侧）------"从哪方面看能力？"
│ │ │ ├── 组织架构
│ │ │ ├── 制度流程
│ │ │ ├── 技术工具
│ │ │ └── 人员能力
│ │ ├── 评估框架（中间金字塔结构）------"能力如何分层构建？"
│ │ │ ├── 顶层：数据安全战略
│ │ │ │ ├── 数据安全规划
│ │ │ │ └── 机构人员管理
│ │ │ ├── 中层：数据全生命周期安全
│ │ │ │ ├── 数据采集
│ │ │ │ ├── 数据传输
│ │ │ │ ├── 数据存储
│ │ │ │ ├── 数据使用
│ │ │ │ ├── 数据共享
│ │ │ │ └── 数据销毁
│ │ │ └── 底层：基础安全
│ │ │ ├── 数据分类分级
│ │ │ ├── 合规管理
│ │ │ ├── 合作方管理
│ │ │ ├── 监控审计
│ │ │ ├── 身份认证及访问控制
│ │ │ ├── 安全风险分析
│ │ │ └── 安全事件应急
│ │ └── 评估等级（右侧）------"能力达到什么水平？"
│ │ ├── 初始级
│ │ ├── 重点执行级
│ │ ├── 全面治理级
│ │ ├── 量化评估级
│ │ └── 持续优化级
├── 4️ 软件配置管理（SCM）（★★）
│ ├── 配置管理定义：配置管理是PMBOK®、ISO9000和CMMI中的重要组成元素，它在产品开发的生命周期中，提供了结构化的、有序化的、产品化的管理方法，是项目管理的基础工作。配置管理是通过技术和行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施和过程。信息系统开发过程中的变更以及相应的返工会对产品的质量有很大的影响。
│ ├── 基本概念
│ │ ├── 产品配置：一个产品在其生命周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项（Configuration Item，CI）。配置项主要有两大类：
│ │ │ ├── 属于产品组成部分的工作成果，如需求文档、设计文档、源代码、测试用例等
│ │ │ └── 属于项目管理和机构支撑过程域产生的文档，如工作计划、项目质量报告、项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。
│ │ └── 配置项
│ │ ├── 定义：软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项
│ │ ├── 基线配置项：需求文档、设计文档、源代码、可执行代码、测试用例、运行数据
│ │ └── 非基线配置项：各类计划（项目管理计划、进度管理计划）、各类报告
│ ├── 配置项的状态
│ │ ├── 草稿
│ │ ├── 正式发布
│ │ └── 正在修改
│ ├── 核心内容
│ │ ├── 版本控制
│ │ └── 变更控制
│ ├── 配置库的类型
│ │ ├── 受控库：也称为主库或系统库，用于管理当前基线和控制对基线的变更。不允许自由修改，需要适当的权限授权
│ │ ├── 动态库：也称为开发库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。允许开发人员自由修改
│ │ └── 静态库：也称为软件仓库或软件产品库，用于存档各种广泛使用的已发布的基线。不允许修改
│ ├── 版本控制规则
│ │ ├── 版本状态与编号规则
│ │ │ ├── 草稿状态：0.YZ（YZ：01~99，递增）
│ │ │ │ └── 示例：版本号从0.01变为0.05，符合草稿状态的版本号规则
│ │ │ ├── 正式状态：X.Y（首次发布：1.0）
│ │ │ │ ├── 小改动：Y 值增加
│ │ │ │ └── 大改动：X 值增加
│ │ │ └── 修改状态：X.YZ（Z 值增加，X.Y 不变）
│ │ └── 版本状态流转
│ │ ├── 草稿 → 正式
│ │ └── 正式 → 修改 → 正式
│ ├── 版本控制流程
│ │ ├── ② 创建配置项
│ │ ├── ④ 对工作状态的配置项进行修改
│ │ ├── ⑤ 提交评审或审批
│ │ ├── ① 通过后正式发布
│ │ └── ③ 因变更更新版本号
│ └── 包括配置管理的体系
│ ├── ISO9000：包括配置管理。ISO9000 是一个质量管理标准系列，其中包括对配置管理的要求，如在软件开发中管理质量相关的文档和配置项。
│ ├── PMBOK：包括配置管理。PMBOK 是项目管理的知识体系，其中包含配置管理相关内容，例如配置变更控制过程。
│ └── CMMI：包括配置管理。CMMI 涵盖了软件工程的多个方面，其中专门有一部分内容（配置管理过程域）用于指导配置管理的实施。
├── 5️ 软件工具分类
│ └── 按软件过程活动分类
│ ├── 软件开发工具
│ │ ├── 需求分析工具
│ │ ├── 设计工具
│ │ └── 编码与排错工具
│ ├── 软件维护工具
│ │ ├── 版本控制工具（VSS、CVS、SCCS、SVN）
│ │ │ └── 描述：版本控制就是用来管理多个版本变迁的工具
│ │ ├── 文档分析工具
│ │ ├── 开发信息库工具
│ │ ├── 逆向工具
│ │ └── 再工程工具
│ └── 软件管理和软件支持工具
│ ├── 项目管理工具
│ ├── 配置管理工具
│ │ ├── 常见功能：版本控制、变更管理、配置状态管理、访问控制和安全控制
│ │ └── 说明：配置管理工具包含了版本控制工具
│ └── 软件评价工具
├── 6️ 范围管理
│ ├── 产品范围：信息系统产品或者服务所应该包含的功能
│ ├── 项目范围：为了能够交付信息系统项目所必须做的工作
│ ├── 关系：产品范围是项目范围的基础
│ ├── 产品范围定义：信息系统要求的度量
│ ├── 项目范围定义：生产项目计划的基础
│ ├── 产品范围描述：是项目范围说明书的重要组成部分
│ └── 项目范围定义的输入
│ ├── 范围管理计划：范围管理计划是项目管理计划的组成部分，确定了制定、监督和控制项目范围的各种活动。
│ ├── 项目章程：项目章程中包含对项目和产品特征的概括性描述，以及项目审批要求。如果执行组织不使用项目章程，则应取得或编制类似的信息，并用作制定详细范围说明书的基础。
│ ├── 需求文件：使用需求文件来选择哪些需求将包含在项目中。
│ ├── 批准的变更申请
│ └── 组织过程资产：可能影响定义范围过程的组织过程资产包括（但不限于）：
│ ├── 1、用于制定项目范围说明书的政策、程序和模板
│ ├── 2、以往项目的项目档案
│ └── 3、以往阶段或项目的经验教训
├── 7️ 风险管理
│ ├── 项目风险定义：一种不确定的事件或条件，可能对项目目标产生正面或负面影响
│ └── 软件风险分类
│ ├── 项目风险
│ ├── 技术风险
│ └── 商业风险
│ └── 主要包括5个方面
│ ├── 开发了一个没有人真正使用的优良产品或系统
│ ├── 开发的产品不符合公司的整体策略
│ ├── 开发了一个销售部不知如何销售的软件
│ ├── 失去了高层管理人员的支持
│ └── 没有得到预算或人员的保证
├── 8️ 软件文档管理
│ ├── 软件系统的文档可以分为用户文档和系统文档两类
│ │ ├── 用户文档：主要描述系统功能和使用方法，并不关心这些功能是怎样实现的
│ │ └── 系统文档：描述系统设计、实现和测试等各方面的内容
│ ├── 用户文档
│ │ ├── 用户文档是用户了解系统的第一步，它可以让用户获得对系统的准确的初步印象
│ │ └── 用户文档至少应该包括下述5方面的内容
│ │ ├── （1）功能描述：说明系统能做什么
│ │ ├── （2）安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置
│ │ ├── （3）使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误时怎样恢复和重新启动）
│ │ ├── （4）参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）
│ │ └── （5）操作员指南（如果需要有系统操作员的话）：说明操作员应如何处理使用中出现的各种情况
│ └── 系统文档
│ └── 所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。
└── 9️ 成本管理
└── 成本预算：在项目的成本管理中，成本预算是将总的成本估算分配到各项活动和工作包上的过程，以此来建立一个成本的基线。成本预算是成本管理的一个关键步骤，它涉及将项目的总体成本估算细分为各个工作包或活动的成本估算，为项目的成本控制提供了基准。