第三章生存期模型知识点速记
核心模型对比表
表格
| 模型 | 适用场景 | 关键优势 | 风险点 |
|---|---|---|---|
| 瀑布模型 | 需求明确、变更少、小型项目 | 流程简单，文档清晰 | 需求变更成本高 |
| V模型 | 需求明确、解决方案明确、高可靠性要求（安全/性能） | 测试前移，质量保障强 | 需求不明确时失效 |
| 增量式模型 | 需求部分明确，需分阶段交付 | 降低投资风险，早期收益 | 增量间集成复杂度高 |
| 快速原型 | 需求模糊，需用户反馈 | 快速探索需求，减少误解 | 原型可能被误当作最终产品 |
| Scrum/XP | 需求易变，需快速响应 | 拥抱变更，用户参与度高 | 文档较弱，依赖团队协作 |
关键原则速记
- 瀑布/V模型：
- “输出驱动输入”：前一阶段输出 = 下一阶段输入。
- 禁用场景：需求不明确、变更频繁。
- 敏捷模型（Scrum/XP）：
- “迭代 + 反馈”：短周期交付，每日站会、燃尽图是Scrum标志。
- XP原则：快速反馈、假设简单、包容变化（排除V模型等外部概念）。
- 风险控制：
- 避免大额投资 →增量式模型。
- 需求探索 →快速原型模型。
- 模型选择逻辑：
- 需求明确 + 高可靠性 →V模型。
- 需求模糊 →避免V/瀑布，选敏捷/原型。
第四章软件项目范围计划扩展知识点速记
1. 需求分类速查表
表格
| 类型 | 定义 | 典型例子 | 常见错误 |
|---|---|---|---|
| 功能性需求 | 系统必须完成的具体行为 | “用户可修改个人资料” | 混淆为技术实现（如“用API修改”） |
| 非功能性需求 | 系统质量属性要求 | “资料修改响应时间≤1秒”（性能） | 误归为功能性需求 |
| “支持1000并发用户”（容量） | |||
| “密码加密存储”（安全） |
需求管理包括需求获取、需求分析、需求规格编写、需求验证、需求变更5个过程
2. 需求管理关键原则
- 需求 ≠ 解决方案：
- 正确需求：“系统应支持在线支付”
- 错误需求：“系统需集成支付宝SDK”（技术方案应留待设计阶段）。
- SRS完成标志：
- 必须通过正式评审（用户/开发方签字确认），基线化后才生效。
- 未基线化的SRS不能作为开发依据。
- 变更控制铁律：
- 所有变更需提交变更请求单（CR）→CCB评估影响（成本/进度/风险）→批准后更新基线。
- 无流程的变更 = 项目失控主因。
3. 常见工具辨析
表格
| 工具 | 所属方法 | 阶段 | 用途 | 易混点 |
|---|---|---|---|---|
| 数据流图(DFD) | 结构化分析 | 需求 | 描述数据流动与处理过程 | vs. 程序流程图（设计阶段） |
| 用例图 | 面向对象分析 | 需求 | 定义功能范围与参与者交互 | vs. 活动图（描述业务流程） |
| 数据字典 | 结构化分析 | 需求 | 定义DFD中所有数据元素 | 不包含“操作指令” |
| 燃尽图 | 敏捷实践 | 开发 | 跟踪Sprint剩余工作量 | 非需求管理工具 |
4. 高频考点总结
- 需求验证 vs. 验收测试：
- 验证：检查SRS是否正确（“我们是否构建了正确的产品？”）
- 验收测试：检查产品是否符合SRS（“我们是否正确构建了产品？”）
- 为什么运行环境属于需求？
- 环境限制直接影响功能实现（如移动端APP需声明“支持iOS 12+”）。
- 结构化分析为何必须自顶向下？
- 自下而上易遗漏系统整体目标（例：先设计登录模块，却忽略与支付模块的集成需求）。
第五章软件项目范围计划核心知识点速记表
表格
| 概念 | 关键规则 | 常见错误 |
|---|---|---|
| WBS定义 | 工作分解结构（非“任务分解”）；可交付成果导向，非活动列表。 | 误认为WBS包含进度/责任分配。 |
| 工作包 | 最底层；唯一责任人；8-80小时；需有验收标准。 | 与“活动”混淆（活动用于进度计划）。 |
| 分解方法 | - 自顶向下：目标明确项目（主流） - 自底向上：全新/模糊项目（辅助） | 认为自底向上是首选方法。 |
| 100%规则 | WBS必须100%覆盖项目范围，无遗漏/冗余。 | 拆分时忽略隐性工作（如文档、测试）。 |
| 范围基准 | = WBS + WBS词典 + 范围说明书；变更需走正式流程。 | 未经批准修改WBS。 |
第六章项目成本计划核心知识点速记表
1. 成本分类与估算基础
- 直接成本：直接归属项目的支出（人力、专用设备、材料）。
- 间接成本：分摊至多个项目的支出（管理费、场地租金）。
- 规模是成本估算的基石：功能点（FP）、代码行（LOC）等规模度量决定成本框架。
2. 估算方法适用场景
表格
| 方法 | 适用阶段 | 特点 | 误差范围 |
|---|---|---|---|
| 类比估算 | 项目初期 | 依赖历史数据，快速但粗糙 | -50% ~ +100% |
| 参数估算 | 需求较明确阶段 | 基于数学模型（如COCOMO） | -15% ~ +20% |
| 自下而上 | 详细规划阶段 | 逐项汇总，精确但耗时 | -5% ~ +10% |
代码行（LOC）、功能点（FP）、类比法均为标准成本估算方法
3. 关键概念辨析
- 功能点法（FPA）：
- 语言无关，仅关注用户可见功能。
- 5类计数项缺一不可，遗漏会导致规模低估。（功能点方法中5类功能组件的计数项是外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件）
- 成本基准 vs 项目预算：
- 成本基准= 活动成本 +应急储备（用于"已知-未知"风险）。
- 项目预算= 成本基准 +管理储备（用于"未知-未知"风险）714。
4. 常见误区
- 混淆规模与工作量：规模是输入，工作量 = 规模 × 生产率。
- 忽略隐性成本：学习曲线、沟通成本、质量保障成本常被低估46。
- 误用估算方法：在需求模糊阶段强行使用参数估算，导致结果失真。
第七章软件项目进度计划核心知识点速记表
总浮动时间 = 总时差 = 最晚完成时间 — 最早完成时间
或者
总浮动时间 = 总时差 = 最晚开始时间 — 最早开始时间
自由浮动时间 = 自由时差 = 紧后活动的最早开始时间最小值 — 本活动的最早完成时间
关键路径上的总浮动时间、自由浮动时间都为0
1. 关键概念辨析
表格
| 概念 | 关键点 | 常见误区 |
|---|---|---|
| 关键路径 | 总浮动=0的任务链；决定项目最短工期；动态变化 | 误认为固定不变 |
| 总浮动 vs 自由浮动 | 总浮动：不影响项目完工的最大延迟时间 自由浮动：不影响后续任务的延迟时间 | 混淆两者，误用自由浮动控制关键路径 |
| PERT vs CPM | PERT：三点估算，适用不确定性高任务 CPM：单点估算，适用确定性高任务 | 高不确定性时误用CPM |
| Lag vs Lead | Lag：任务间等待时间（延长进度） Lead：任务间重叠时间（压缩进度） | 将Lag误加到任务历时计算中 |
2. 进度压缩技术对比
表格
| 方法 | 操作方式 | 代价 | 适用场景 |
|---|---|---|---|
| 应急法 | 增加资源（人力/设备） | 成本显著增加 | 关键路径任务可并行化 |
| 快速跟进 | 顺序任务改为并行 | 返工风险上升 | 任务间依赖弱、返工成本低 |
3. 依赖关系快速判断
- 强制性依赖：不做A就无法做B（技术/法律强制）。
- 选择性依赖：A在B前是最佳实践，但非必须（可协商调整）。
- 外部依赖：B依赖外部事件（如“等待供应商交付”）。
4. 必考公式与规则
- PERT历时= (O + 4M + P) / 6
- 标准差= (P - O) / 6
- 关键路径判定：总浮动 = LS - ES = LF - EF = 0
- 工期压缩原则：只压缩关键路径任务，且成本增量最小的优先。
- 甘特图（Gantt Chart）：横轴为时间，纵轴为任务，直观展示工期、起止时间、资源分配。
- 对比：
- 网络图：聚焦逻辑关系，非时间细节。
- 里程碑图：仅标示关键节点。
- 资源图：展示资源负荷，非任务时间线。
第八章软件项目质量计划核心扩展知识点速记（汇总）
软件质量管理三大核心过程：
- 质量计划：定义质量标准和实现方法（如制定检查表）。
- 质量保证（QA）：过程导向，确保流程合规（如审计）。
- 质量控制（QC）：产品导向，验证交付物质量（如测试）。
- 三者构成PDCA循环（计划-执行-检查-改进）。
表格
| 主题 | 关键内容 | 依据来源 |
|---|---|---|
| 质量成本(CoQ) | 预防成本（培训/评审） + 鉴定成本（测试/审计） + 缺陷成本（内部/外部失败） 口诀：预防投入1元，缺陷成本省100元 | PMBOK指南第7版、Crosby理论 |
| McCall模型 | 三视角： - 产品运行（正确性、可靠性） - 产品转移（可移植性、互操作性） - 产品修改（可维护性、灵活性） | McCall 1977论文 |
| QA vs QC | - QA：过程导向，预防性（如审计、流程改进） - QC：产品导向，检测性（如测试、代码审查） 口诀：QA管“如何做”，QC管“做得对” | CMMI-DEV v2.0、ISO/IEC 12207 |
| 软件质量定义 | 满足明示需求 + 隐含需求的程度（非仅代码正确） 隐含需求示例：易用性、安全性、响应时间 | ISO/IEC 25010:2011 |
| 质量计划方法 | 质量成本分析、因果图（鱼骨图）、基准对照 非计划方法：抽样分析（属QC）、质量优化（属改进） | PMBOK指南第7版（4.5.2.3节） |
| ISO 25010模型 | 8大特性：功能性、性能效率、兼容性、易用性、可靠性、安全性、可维护性、可移植性 替代旧标：ISO 9126 → ISO 25010 | ISO/IEC 25010:2011 |
第九章软件配置管理计划核心扩展知识点速记（汇总）
1. 配置管理四大目标
- 完整性：所有配置项齐全且受控。
- 一致性：关联配置项版本匹配（如代码与文档同步）。
- 追溯性：可追踪需求→设计→代码→测试的全链路变更。
- 可控性：变更需经SCCB审批，不可绕过流程13。
2. 基线管理关键规则
基线定义与变更
- 基线本质：通过正式评审的配置项集合，代表阶段里程碑。
- 基线可变性：
- 可修改，但必须走变更流程（否则失去基准意义）；
- 修改后生成新基线，旧基线存档不可删除。
- SCCB权限：
- 唯一批准机构，项目经理无权直接授权；
- 职责：评估影响、审批变更、反馈结果35。
3. 配置项与标识规范
配置项范围
- 典型配置项：需求文档、设计文档、源代码、测试用例、用户手册。
- 项目差异性：配置项范围因项目类型而异（如硬件项目含电路图）。
标识规则
- 唯一标识符：每个配置项必须有全局唯一ID（如REQ-001）；
- 禁止多标识：避免追溯混乱，标识规则需在配置管理计划中明确定义
- 写出配置管理的基本过程。
答：（1）配置项标识、跟踪：（2）配置管理环境建立：（3）基线变更管理：（4）配置管理审计：（5）配置状态统计；（6）配置管理计划。
第十章软件项目人员与沟通计划关键扩展知识点速记
1.沟通方法分类
- 交互式沟通：实时互动（会议、电话），解决复杂问题。
- 推式沟通：单向发送（邮件、报告），确保信息触达。
- 拉式沟通：自主获取（文档库、Wiki），适合海量信息314。
2.组织结构选择逻辑
表格
| 类型 | 适用场景 | 风险点 |
|---|---|---|
| 职能型 | 单部门主导、技术成熟项目 | 跨部门协作效率低 |
| 项目型 | 高优先级、独立项目 | 资源浪费，成员归属感弱 |
| 矩阵型 | 跨领域复杂项目（最常用变体：强矩阵） | 双重汇报引发冲突 |
3.沟通计划核心要素
- 受众分析：区分干系人需求（高管重结果，执行层重细节）。
- 渠道匹配：紧急事务→电话；决策确认→书面；知识共享→拉式系统。
- 变更管理：计划需随项目阶段动态调整（如启动期高频会议，收尾期减少沟通）
第十一章软件项目风险计划
定量分析技术：访谈（获取概率数据）、盈亏平衡分析（成本临界点）、决策树（路径价值计算）、模拟法（蒙特卡洛）、敏感性分析（单变量影响）
"风险识别工具包括：德尔菲法（专家匿名迭代）、头脑风暴（团队集思）、情景分析（未来推演）、风险条目检查表（历史经验库）"
项目风险的三要素是风险事件、风险事件发生的概率、风险造成的影响
风险应对四大策略：
- 回避：消除风险源；
- 转移：外包/保险将责任转给第三方；
- 损失控制（减轻）：降低概率或影响（如培训、原型验证）；
- 自留：主动接受风险（预留应急储备）。
| 策略 | 适用场景 | 教材案例 |
|---|---|---|
| 回避 | 风险值极高且不可控 | 取消不成熟需求 |
| 转移 | 风险影响大但第三方更擅长管理 | 外包安全测试 |
| 损失控制 | 可通过行动降低概率/影响 | 人员培训防流失 |
| 自留 | 风险值低或应对成本高于损失 | 接受轻微进度波动 |
