开发管理：让项目不再翻车 📊

13.1.1 范围管理5部分

项目启动→范围计划编制→范围定义→范围核实→范围变更控制。

• 范围定义：把可交付成果分解成更小更易管理单元。目的：提高成本/时间/资源估算准确性、为绩效测量定义基准、便于职责分配
• 范围核实：干系人正式接受项目范围，审查可交付成果。注意：范围核实≠质量控制(核实是"接收"，质控是"正确性")
• 范围变更控制：影响变更因素、确定变更是否发生、管理实际变更。必须与其他控制结合

13.1.2 成本管理4部分

资源计划编制→成本估算→成本预算→成本控制。

成本估算≠定价。估算是"花费多少"(近似值)，定价是"收多少"(商业决策)。成本控制含：监测偏差及原因、确保变更准确记录、防止不正确变更纳入、通知干系人、控制预计成本。

13.1.3 时间管理5部分

活动定义→活动排序→活动历时估算→进度计划编制→进度控制。

13.2.1 SCM概念6功能

IEEE 729定义SCM 6功能：配置标识、版本控制、状态统计、审计和审查、生产、过程管理、小组协作。

ISO9000.3要求：唯一标识版本、标识构成完整产品的各软件项版本、控制多人同时更新、协调复杂产品更新、标识跟踪所有措施和更改。

13.2.2 SCM工具4种

13.2.3 软件文档管理

文档7作用：管理依据、任务联系凭证、质量保证、培训与参考、维护支持、历史档案、销售可能。

文档3类：开发文档(需求/设计/测试/质量)、产品文档(培训手册/参考手册/用户指南/支持手册)、管理文档(计划/进度/变更/判定/职责/报告)。

按用途分内部文档(计划/需求/架构/详设/构件/类/测试/源码)和外部文档(安装/操作/在线帮助/性能/操作索引)。

好文档5特征：针对性(分清读者)、精确性(无歧义)、清晰性(配图表)、完整性(自成体系)、灵活性(按项目定)。

13.3.1 需求变更

两阶段措施：

• 启动阶段预防：基准文件定义越详细清晰，后期分歧越少。需求文档清晰且有客户签字，超出合同范围的变更需另外处理
• 实施阶段控制：分析变更请求，评估风险，修改基准文件。注意：需求必须与投入联系(需求变投入也变)、变更需出资者认可、小的变更也要走正规流程、注意沟通技巧

13.3.2 需求跟踪5项

1. 确定需求变更控制过程(标准过程)
2. 进行需求变更影响分析(对计划和其他需求)
3. 建立需求基准版本和控制版本文档
4. 维护需求变更历史记录(日期/原因/负责人/版本号)
5. 跟踪每项需求状态(已推荐/已通过/已实施/已验证)

13.4.1 软件质量管理3部分

质量计划：判断哪些质量标准相关+如何达到。活动含计划质量活动、定义可测量目标、确定可量化管理、提供资源资金、培训人员。

质量保证：定期评估总体绩效，建立能达到质量标准的信心。贯穿始终。

质量控制：监测具体结果是否符合标准+消除不合格根源。含评审、调试、测试。

软件评审目标5点：发现错误、验证需求、保证按标准表示、统一形式开发、使项目更易管理。评审过程：召开会议→决策(接受/拒绝/暂接受)→报告记录。评审准则：分配资源和时间表、评产品不评人、不脱离主题、不为解决问题而是发现问题、建立评审清单。

测试3文档：测试计划(范围/方法/资源)、测试过程(步骤和数据)、测试结果(归档+问题报告)。

13.4.2 项目风险管理

风险管理=识别+分析+应对的系统过程。三时段：事前控制(规划)、事中控制(方法)、事后控制(报告)。

4风险类型：内部技术风险(新技术/不切实际要求)、内部非技术风险(战略/管理/质量/进度/成本)、外部法律风险(规章/专利/合同)、外部非法律风险(政治/经济/通胀/灾害)。

风险管理6过程：规划→识别→定性分析→定量分析→应对计划→监督控制。

3个关键概念：

• 风险得失值：风险发生的损失大小(可折算为时间影响)
• 风险概率：发生可能性的百分比(主观判断)
• 风险值(风险曝光度)=风险概率×风险影响。例：25%概率延4周→风险值=1周

4种应对策略(PMBOK 2012)：

风险监控最有效工具之一："前10个风险列表"——按风险值排序前10个，每次检查后形成新列表。含跟踪已识别风险+识别新风险+调整应对计划。