考点频率 ：项目估算 ★★★★☆（选择题常考），风险管理 ★★★★☆（选择题常考）
难度 ：⭐⭐⭐
建议：重点掌握三种估算方法的区别、COCOMO模型的公式及三种模式，以及风险管理的四步流程
1️⃣ 软件项目估算：为什么估不准，但必须估？
软件项目估算是估算软件项目的工作量、成本、进度的过程。它直接决定了项目能不能盈利、资源够不够、能不能按期交付。
一个悖论：软件项目估算永远不可能完全准确，但企业仍然必须估算------因为合同要签、预算要批、团队要招、排期要定。估算的准确性不是目标，控制误差范围才是。
1.1 三种估算方法
| 估算方法 | 全称 | 依据 | 适用阶段 |
|---|---|---|---|
| LOC | 代码行估算（Lines of Code） | 基于程序代码量（行数） | 项目后期、技术已确定 |
| FP | 功能点估算（Function Points） | 基于系统功能数量 | 项目早期、需求已定义 |
| COCOMO | 构造性成本模型（Constructive Cost Model） | 基于LOC/FP + 项目特征 | 各类项目 |
1.2 LOC（代码行估算）
核心思想：通过估算软件产品的规模（代码行数）来推算工作量和成本。
估算步骤：
- 将系统分解为各个模块/功能
- 估算每个模块的代码行数（范围：乐观值、可能值、悲观值）
- 用加权平均计算期望值：
期望值 = (乐观 + 4×可能 + 悲观) / 6 - 汇总得到总代码行数
优点 ：简单、直观，有历史数据支撑时比较准确。
缺点：依赖编程语言（同样的功能，C语言比Python多写几倍代码）；项目早期很难估算。
1.3 FP（功能点估算）
核心思想 ：从用户视角出发，根据软件的功能数量（而非代码行数）来估算规模，避免编程语言带来的偏差。
功能点由五种要素构成：
| 功能类型 | 说明 | 权重 |
|---|---|---|
| 外部输入（EI） | 用户输入数据（如添加订单） | 低3/中4/高6 |
| 外部输出（EO） | 系统输出给用户（如报表） | 低4/中5/高7 |
| 内部逻辑文件（ILF） | 系统内部维护的数据（如数据库表） | 低7/中10/高15 |
| 外部接口文件（EIF） | 系统引用的外部数据（如调用外部API） | 低5/中7/高10 |
| 外部查询（EQ） | 用户查询操作（如搜索商品） | 低3/中4/高6 |
计算步骤：
- 统计每个功能要素的数量，乘以对应权重，得到未调整功能点（UFP）
- 根据14个技术复杂度因子（如数据通信、性能要求等）计算技术复杂度因子（TCF）
- 调整后功能点 = UFP × TCF
优点 ：与编程语言无关，可在项目早期估算；便于不同项目之间横向比较。
缺点：计算过程较复杂，需要一定的经验和培训。
2️⃣ COCOMO模型（构造性成本模型）
COCOMO由Barry Boehm于1981年提出，是目前最常用的软件成本估算模型。它基于代码行数（KLOC） 和项目类型来估算工作量。
2.1 COCOMO的三种开发模式
| 模式 | 适用场景 | 特点 |
|---|---|---|
| 有机型（Organic） | 项目规模小、需求稳定、团队经验丰富 | 简单，如企业内部管理系统 |
| 半独立型（Semi-detached） | 中等规模、需求部分不确定、团队经验一般 | 介于两者之间 |
| 嵌入型（Embedded） | 大规模、需求复杂、硬件约束严格 | 复杂，如航天、电信系统 |
2.2 COCOMO基本模型公式
| 开发模式 | 工作量公式（人·月） | 开发时间公式（月） |
|---|---|---|
| 有机型 | E = 2.4 × (KLOC)^1.05 |
D = 2.5 × E^0.38 |
| 半独立型 | E = 3.0 × (KLOC)^1.12 |
D = 2.5 × E^0.35 |
| 嵌入型 | E = 3.6 × (KLOC)^1.20 |
D = 2.5 × E^0.32 |
关于公式的说明 ：在不同教材中，系数（如a=2.4）和指数（如b=1.05）的取值可能略有差异，但核心规律是一致的------项目规模越大、复杂度越高，工作量和时间增长越快。考试中如果给出的公式参数与你记忆的不同，建议以题目给出的公式为准。关键是要能够根据题目提供的公式进行套用和计算。
2.3 计算示例
题目：某项目预计代码量为20 KLOC，采用半独立型开发模式，求估算工作量和开发时间。
解：
- 工作量：
E = 3.0 × (20)^1.12 ≈ 3.0 × 27.86 ≈ 83.6 人·月 - 开发时间：
D = 2.5 × E^0.35 ≈ 2.5 × (83.6)^0.35 ≈ 2.5 × 4.72 ≈ 11.8 月
答案：约84人·月，12个月
3️⃣ 风险管理：把"定时炸弹"变成"已知量"
风险（Risk） 是指可能发生的、对项目目标造成负面影响的不确定事件。
风险管理的目标不是"消灭所有风险"（那不可能），而是识别风险、评估风险、制定应对计划，让团队有准备，不会被打个措手不及。
3.1 风险管理的四个阶段
| 阶段 | 核心活动 | 产出 |
|---|---|---|
| 风险识别 | 找出所有可能的风险，分类记录 | 风险清单 |
| 风险分析 | 评估概率和影响，排优先级 | 风险评估表 |
| 风险应对 | 制定应对策略 | 风险应对计划 |
| 风险监控 | 持续跟踪风险变化 | 风险状态报告 |
3.2 风险识别
从三个维度识别风险：
- 项目风险：进度延迟、预算超支、人员流失
- 技术风险：技术方案不可行、技术栈不成熟、性能达不到要求
- 商业风险：市场需求变化、竞争对手先发布、产品卖不出去
3.3 风险分析（两种常用方法）
方法一：风险优先级评估（概率×影响）
| 风险 | 概率 | 影响 | 风险值（P×I） | 优先级 |
|---|---|---|---|---|
| 核心开发人员离职 | 20% | 5 | 1.0 | 高 |
| 需求变更频繁 | 60% | 4 | 2.4 | 最高 |
| 服务器宕机 | 10% | 5 | 0.5 | 低 |
方法二：决策树分析（定量估算风险成本）
用期望货币价值（EMV）来量化风险的财务影响，计算公式为：期望损失（EMV）= 概率 × 影响（金额）。
示例：某个技术风险有30%的概率导致项目延期，延期造成的额外成本为50万元。则 EMV = 30% × 50 = 15万元。这意味着公司应当愿意投入最多15万元来规避此风险（如提前采购备用方案或安排人员培训）。
3.4 风险应对的四种策略
| 策略 | 含义 | 示例 |
|---|---|---|
| 规避（Avoidance） | 消除风险源，不让风险发生 | 放弃不成熟的技术方案，改用团队熟悉的技术 |
| 转移（Transfer） | 将风险后果转嫁给第三方 | 购买保险、外包非核心模块、签订固定总价合同 |
| 减轻（Mitigation） | 降低风险发生的概率或影响 | 代码审查降低Bug率、每周备份数据、定期Code Review |
| 接受（Acceptance） | 承认风险存在，预留应急预算 | 为可能的进度延迟预留10%的缓冲时间 |
4️⃣ 经典例题
例题1（估算）：某软件项目采用COCOMO基本模型进行估算，项目代码量为15 KLOC，采用半独立型模式（E=3.0×(KLOC)^1.12），估算工作量为多少？
A. 约45人·月
B. 约60人·月
C. 约84人·月
D. 约120人·月
解析 ：E = 3.0 × (15)^1.12 ≈ 3.0 × 19.7 ≈ 59.1 人·月。选 B。
例题2（风险管理）：某项目团队针对"关键技术方案可能存在兼容性问题"这一风险，决定在正式开发前先搭建一个小型原型系统进行验证。这属于哪种风险应对策略？
A. 风险规避
B. 风险转移
C. 风险减轻
D. 风险接受
解析 ：通过原型验证来降低技术失败的概率 ，这是典型的风险减轻 策略。选 C。
例题3（判断）：FP功能点估算方法与编程语言无关，因此可以在项目早期使用。（ ）
解析：正确。FP基于功能数量而非代码行数，与编程语言无关，适合项目早期使用。
5️⃣ 记忆口诀
估算三法：代码行、功能点、COCOMO。
COCOMO三种模式：有机半独嵌入型。
风险四步：识别分析应对监控。
应对四策：规避转移减轻接受。
6️⃣ 小测验（评论区对答案）
某公司评估一个项目，发现主要风险是"竞争对手可能提前发布类似产品"，导致项目商业价值降低。该风险属于哪一类风险？若公司决定将产品提前上市作为应对方案，这属于哪种应对策略？
A. 商业风险；减轻
B. 商业风险；规避
C. 项目风险；转移
D. 技术风险；接受
🔔 本专栏日更，点击头像 → 专栏《软考中级高频考点》订阅，第一时间接收新内容
#软考中级 #软件设计师 #项目估算 #风险管理 #COCOMO #软件工程