第4章 范围管理

软件项目管理与案例分析

第四章范围管理知识目标:了解软件范围管理的定义和过程能力目标:能够准确地进行需求分析和规格定义，能够使用软件范围管理相关工具和技术学习目标1.需求获取：范围的起点类型2.需求范围定义：界定边界3.创建工作分解结构（WBS）：构建可控结构4.范围确认：信任的交付5.范围控制：应对变更6.案例分析：工商审批系统项目本章小节第四章范围管理需求获取：范围的起点

01123需求是软件项目范围的起点，而沟通是成功的关键。准确的需求获取能够确保项目方向正确，避免后续的返工和变更。如果需求不明确，项目可能会偏离目标，导致时间和资源的浪费。因此，需求获取是项目成功的基石。需求获取的重要性需求可以分为多种类型，包括界面需求、功能需求、性能需求、质量需求、资源使用需求、成本与进度需求以及异常处理需求等。每种需求都对应着不同的用户关注点和项目目标。例如，界面需求关注用户体验，性能需求则确保系统的高效运行。需求的常见类别常用的需求获取方法包括访谈、讨论会、观察法、问卷调查和快速原型法。访谈适合深入了解用户需求，讨论会可以集思广益，观察法能发现用户未表达的需求，问卷调查适合大规模收集意见，快速原型法则通过可视化的原型快速验证需求。每种方法都有其适用场景和特点。需求获取方法需求获取：沟通与分类需求范围定义：界定边界

02产品范围与项目范围的区别产品范围是指最终交付物所应具备的功能和特性，例如软件需求规格说明书（SRS）所描述的内容。而项目范围则是为交付产品所必须完成的所有工作，包括开发、测试、部署等环节。产品范围关注的是交付物本身，项目范围则关注如何实现交付。范围定义的重要性范围定义是项目管理的关键环节，它帮助明确项目的边界，避免范围蔓延。通过界定边界，项目团队可以集中精力完成必要的工作，而不是被无关的需求分散注意力。明确的范围定义有助于控制项目成本、进度和质量。0102产品范围与项目范围产品范围描述产品范围描述是范围说明书的核心内容，它详细说明了产品应具备的功能和特性。这一部分需要清晰、准确，以便所有项目干系人能够理解产品的目标和预期成果。验收标准验收标准是判断项目是否完成的关键依据。它明确了产品范围的可接受条件，包括功能、性能、质量等方面的指标。验收标准应具体、可衡量，以便在项目结束时能够客观地评估产品是否符合要求。可交付成果与除外责任可交付成果是指项目团队需要交付的具体成果物，如软件、文档、测试报告等。除外责任则明确指出哪些内容不在项目范围内，避免因误解而产生不必要的工作。这两部分内容有助于明确项目团队的责任和边界。制约因素与假设条件制约因素是指对项目产生限制的外部条件，如技术限制、法律法规限制等。假设条件则是项目团队在规划时所假设的条件，如资源可用性、市场环境等。明确这些内容有助于在项目实施过程中更好地应对风险。项目范围说明书内容创建工作分解结构（WBS）：

构建可控结构03WBS是一种树形结构，展示了系统、子系统、模块和工作包之间的层次关系。通过这种结构，项目团队可以清晰地看到项目的整体架构和各个组成部分之间的关系，从而更好地管理和控制项目。WBS的结构示意创建WBS的常用方法包括类比法、自顶向下法、自底向上法和混合法。类比法适用于类似项目，自顶向下法从整体到局部分解，自底向上法从细节到整体整合，混合法则结合多种方法的优点。每种方法都有其适用场景和优缺点。创建WBS的方法WBS的分解策略包括按交付物分解、按项目阶段分解和按功能模块分解。分解时需确保工作包必要且充分，工作独立，可判断完成度，并有明确交付成果。这些要求有助于确保WBS的完整性和可操作性。WBS分解策略132WBS结构示意与分解策略范围确认：信任的交付

04范围确认的重要性范围确认不仅是签字确认，更是信任的交付。它确保项目成果符合客户的期望和需求。范围确认通常由客户或发起人主导，且在质量控制（如系统测试）之前进行。通过制定验收标准、组织验收过程和编写验收报告，范围确认为项目的成功交付提供了保障。范围确认流程与成果范围控制：应对变更

05范围蔓延的危害范围蔓延会导致工期延误、成本超支和团队士气下降。例如，一个项目在开发过程中不断添加新的功能，可能会使原本计划的6个月工期延长到12个月，成本增加一倍，同时团队成员也会因不断变化的目标而感到疲惫和挫败。范围控制机制范围控制机制包括建立变更控制系统、配置管理系统和严格变更审批流程。变更控制系统用于记录和管理变更请求，配置管理系统确保变更的可追溯性，变更审批流程则确保变更经过严格评估和批准。通过这些机制，可以科学管理变更，而不是简单地拒绝变更。范围蔓延的危害与控制机制案例分析：

工商审批系统项目

06工商审批系统项目是一个典型的政务系统项目，具有涉密双网结构。项目初版功能虽然满足基本需求，但界面体验差，导致用户满意度低。在后续的开发过程中，由于界面需求未被识别、代码耦合度高以及变更控制失效等问题，项目工期延误了100%。案例背景通过时间轴展示项目变更过程，分析项目中存在的问题。界面需求未被识别导致用户反馈不佳，代码耦合度高使得修改一处功能可能影响其他功能，变更控制失效则使项目不断偏离原计划。这些问题的根本原因是需求获取不全面和范围控制不严格。问题分析该案例启示我们，需求获取需关注隐性需求，如用户体验；范围定义应结合行业特点与用户场景；控制变更不等于拒绝变更，而是科学管理变更。通过这些措施，可以有效避免范围失控，确保项目成功交付。案例启示案例背景与问题分析案例启示工商审批系统项目强调了需求获取需关注隐性需求，如用户体验，范围定义应结合行业特点与用户场景，控制变更不等于拒绝变更，而是科学管理变更。这些启示有助于我们在实际项目中更好地进行范围管理，避免类似问题的发生。经验教训结合实际项目经验，分享一些范围管理的最佳实践和注意事项。例如，在需求获取阶段，应多与用户沟通，了解其潜在需求；在范围定义阶段，要明确边界，避免范围蔓延；在变更控制阶段，要建立严格的审批流程，确保变更的必要性和可行性。12案例启示与经验教训本章小结

07需求获取的重要性需求获取是范围管理的基础，准确的需求获取能够确保项目方向正确，避免后续的返工和变更。需求获取需关注隐性需求，如用户体验，通过多种方法获取全面的需求。WBS的作用WBS是范围落地的关键工具，通过树形结构展示项目的层次关系，采用合适的分解策略，确保工作包必要且充分、工作独立、可判断完成度。范围定义的作用范围定义决定项目边界，明确产品范围与项目范围的区别，制定详细的范围说明书，包括产品范围描述、验收标准、可交付成果等内容。范围确认与控制范围确认与控制是交付保障，通过严格的范围确认流程和变更控制机制，确保项目成果符合客户期望，避免范围失控。本章小结课后作业

08如何协调用户、管理层与开发团队对需求的不同看法？思考方向包括：建立有效的沟通机制，确保各方能够充分表达意见；明确需求优先级，平衡各