知识源于沉淀 十项管理一直是信息系统项目管理师考试的重点。为了便于大家记忆，信息网特意在项目管理部安排了信息系统管理的六个流程。
项目范围管理
范围管理就是做范围内的事情，只做范围内的事情，不多也不少。范围管理有六个过程，即计划范围管理、收集需求、定义范围、创建工作分解结构、确认范围和控制范围。每个流程都有自己的输入、输出和工具技术。这些内容在复习过程中会不断出现在各类题型中。所以有必要记住。
规划范围管理
在论文中如何描述:
通过查阅项目管理计划、项目章程等资料，根据甲方的要求和甲方的关注，特别关注某一点，最终得到需求管理计划和范围管理计划。
例如:
俗话说，我们应该专注于第一小步，科学的范围管理计划是项目成功的一半。
从项目开始，基于项目章程，我组织项目组成员整理业务系统日志信息，邀请业务专家规划部署架构，邀请大数据专家提供数据访问方案，统计项目利益相关方信息，让相关利益相关方参与信息收集、资源应用、公共组件管理等工作，以获得利益相关方对工作的认可。我借鉴了以往类似项目的范围管理计划模板，详细描述了需求管理和范围管理的工作方法，为后续工作提供了书面指导。
收集需求
在论文中如何描述:
关注需求的重要性。只有明确了需求，才能解决项目边界，防止项目做多。为了收集需求，我们采用了各种技术、焦点小组、引导式研讨会等方式召集大家思考项目的需求，对需求进行分类分析，最终得到甲方的认可和确认，最终形成需求文档，为后续项目范围的界定奠定了基础。
例如:
范围定义是为了实现项目目标而必须完成的工作，它通常与需求相关。需求的“扩散”是项目失败最常见的原因之一。
在这个项目中，为了避免需求的遗漏和需求的重复变更，在定义范围之初，我召集项目干系人多次讨论需求，围绕项目章程和证监委秘书处的意见，确定了项目边界和实施范围。需求明确后，我安排需求分析工程师定期向用户确认功能性需求和非功能性需求，建立需求跟踪矩阵，确保项目团队和用户在需求理解上达成一致。
定义范围
在论文中如何描述:
首先明确范围的边界，通过产品分析、专家判断和对需求的准确把握，利用需求文档形成项目范围说明书，明确项目的重要工作。把需求变成范围，专家一起分析。范围说明书的主要内容是什么(至少写3分)？
例如:
上述需求确定后，为了进一步保证需求分析的准确性和需求的实现，我召集了公司的业务专家和大数据专家对需求文档进行审核。评审中发现系统间带宽有限，无法满足大数据传输的性能要求，硬件资源磁盘阵列错误，无法满足大数据查询的性能要求。经过与利益相关方的及时沟通，修改了磁盘阵列，扩大了系统之间的带宽，满足了要求。
最后，我将已定义的需求组织成项目范围陈述，形成该阶段的重要可交付成果，并将项目范围陈述提交给项目干系人和公司管理层。
创建WBS
在论文中如何描述:
为了更好地开展工作，使团队成员清楚地了解自己所负责的工作，根据范围规范，范围规范中定义的范围是通过分解结构的方式呈现的，使工作清晰直观，并将项目中的工作分解成工作包，为后续的成本、进度或其他工作起到了良好的前提和基础。
知道自己应该做什么，同时也能从全局上把握整个项目的脉络，知道如何去帮助别人，从而更好的让团队对项目的实施有一个更整体的认识。有前提条件，比如后续的成本和进度管理，还有一个重要的成果就是范围基准，范围基准对后续的工作有一个基准和重要的参考。知道整个项目有哪些重要工作，一目了然。这是一个非常好的项目开发工具。
确认范围
在论文中如何描述:
检查可交付成果的正确性，做出好成绩，范围做得好，主要是甲方认可可交付成果，通过验收召开验收会，通过内部检查不断测试改进，邀请甲方验收全部成果，评审产品，严格按照需求文件确认范围。为了更好的完成需求，它对需求进行了优化，针对不同的用户和场景展示了各种应用场景。
控制范围
在论文中如何描述:
在论文中，我们可以先谈控制范围的重要性，它决定了资源的分配和投入，然后再谈如何控制范围，每周例会，让每个成员汇报自己的工作以及做了多少工作，最后的体现就是可交付的成果。针对工作中的问题，我们去开了一个研讨会，应该改什么或者怎么改，关注后续工作是否按照相关要求完成。整改，根据范围基准，应该做的，不应该做的或者需要变更的变更流程。
