软件项目变更控制流程 项目范围变更控制流程
项目整体管理的变更控制是什么
变更管理属于配置管理的一个部分，因此变更管理也是贯穿于整个项目生命周期的。
在CMMI中变更分为两个级别：一般变更和重大变更。
在PMP中变更控制有3个主要目标： 1. 建立一种方法始终如一地识别与提出对既定基线的变更，并估计这些变更的价值与有效性。
2. 通过考虑每一项变更的影响，不断确认与改进项目的机会。
3. 建立将所有变更始终如一地通知项目利害关系人的机制。
变更过程所涉及到的配置管理活动： 1. 配置项的识别 2. 配置状态的核算 3. 配置审计
如何有效控制需求变更
需求变更对软件开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。
需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。
（1）明确合同约束，建立需求基线 需求变更给软件开发带来的影响有目共睹，所以在与客户签订合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。
虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。
明确和树立需求基线是需求变更的依据。
在开发过程中，需求确定并经过评审后（客户参与评审），建立第一个需求基线。
此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。
例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。
（2）建立变更审批流程 在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低开发效率，浪费时间。
正是这种观念才使需求变更变得不可控，最终导致项目的失败。
因此，小的需求变更也要经过正规的需求管理流程，否则会积少成多，积重难返。
明确需求变更审批环节、审批人员、审批事项、审批流程。
这么做的目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。
二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。
凡未履行审批程序的“变更”，一律是无效变更不予受理。
（3）分级管理变更，定时批量处理 软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到客户的成本投入收益。
因此，用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。
当遇到客户提出需求，不及时处理可能会使项目不能验收通过时，也不能一味拒绝不予开发。
因此，当客户坚持变更新需求时，可以建议客户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。
例如，每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目进度。
针对会议结果可向客户正式提交一份需求变更计划，注明变更引起的时间、成本、工期代价和增加工作量等。
要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱变更不做，保大局弃小变。
（4）安排专职人员负责变更管理 有时开发任务较重，开发人员容易陷入开发工作中而忽略了与客户的随时沟通。
因此，需要安排一名专职的需求变更联络人员，负责与客户及时交流，跟踪和汇报需求变更完成进度和情况。
同时，可以成立项目变更控制小组，负责裁定接受哪些变更，小组由项目所涉及的多方人员共同组成，应该包括客户方和开发方的决策人员在内。
（5）确认客户是否接受变更的代价 要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。
例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。
一般来说，如果客户认为该变更是必须的（不是其上级领导拍脑袋提出的）就会接受这些后果。
通过与客户协商，这样开发团队即使没有回报，也不会招致公司和客户双方的埋怨。
如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。
如果客户认为该变更可有可无，多数情况下会取消变更。
这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更。
IT项目如何做好项目流程管理
IT项目管理是项目管理在IT领域的应用，结合IT行业特点运用项目管理技术、理念和方法，包括9大知识领域（项目综合、范围、时间、成本、质量、人力资源、沟通、风险和采购管理）以及启动、计划、实施、控制和收尾等过程组成。
软件项目开发管理过程中，不仅要努力实现项目的范围、时间、成本和质量等目标，还必须协调整个项目过程，以满足项目参与者及其他利益相关者的需要和期望；随着软件规模和所涉及的领域不断地扩大，软件项目的管理越来越困难。
纵观所有失败的软件项目，基本原因是不能管理其软件过程，在无纪律的、混乱的项目状态下，组织不可能从较好的方法和工具中获益。
严谨的软件过程控制与管理不仅可以在每个阶段回顾和纠正项目的偏差，识别软件项目的风险甚至果断中止项目，而且可以将人才流动所带来的不利影响减少到最小。
要进行有效的过程控制，必须明确软件项目管理流程。
1、流程第一阶段：项目的启动 在项目管理过程中，启动阶段是开始一个新项目的过程。
启动信息技术（IT）的项目，必须了解企业组织内部在目前和未来主要业务发展方向，这些主要业务将使用什么技术及相应的使用环境是什么。
启动信息技术（IT）的项目的理由很多，但能够使项目成功的最合理的理由一定是为企业现有业务提供更好的运行平台，而不是展示先进的IT技术。
2、流程第二阶段：项目的计划 在项目管理过程中，计划的编制是最复杂的阶段，项目计划工作涉及九个项目管理知识领域。
在计划编制的过程中，可看到后面各阶段的输出文件。
计划的编制人员要有一定的工程经验，在计划制定出来后，项目的实施阶段将严格按照计划进行控制。
今后的所有变更都将是因与计划不同而产生的。
也就是说项目的变更控制将是参考计划阶段的文件而产生的。
3、流程第三阶段：项目的实施及控制 在项目实施阶段是占用大量资源的阶段，此阶段必须按照上一阶段定制的计划采取必要的活动，来完成计划阶段定制的任务。
在实施阶段中，项目经理应将项目按技术类别或按各部分完成的功能分成不同的子项目，由项目团队中的不同的成员来完成各个子项目的工作。
在项目开始之前，项目经理向参加项目的成员发送《任务书》。
4、流程第四阶段：项目的收尾 在项目管理过程中，计划的编制是最复杂的阶段，项目计划工作涉及九个项目管理知识领域。
在计划编制的过程中，可看到后面各阶段的输出文件。
计划的编制人员要有一定的工程经验，在计划制定出来后，项目的实施阶段将严格按照计划进行控制。
今后的所有变更都将是因与计划不同而产生的。
也就是说项目的变更控制将是参考计划阶段的文件而产生的。
5、流程第五阶段：项目的维护期 在项目收尾阶段结束后，项目将进入到后续的维护期。
项目的后续维护期的工作，将是保证信息技术能够为企业中的重要业务提供服务的基础，也是使项目产生效益的阶段。
在项目的维护期内，整个项目的产品都在运转，特别是时间较长后，系统中的软件或硬件有可能出现损坏，这时需要维护期的工程师对系统进行正常的日常维护。
维护期的工作是长久的，将一直持续到整个这个信息技术（IT）项目的结束。
软件配置管理主要包括哪些基本过程
软件配置管理是贯穿软件开发过程始终的一项工作。
对于一个软件项目来说，软件配置管理规范至少包括以下的内容： （1）配置项及其命名规则。
（2）配置库文件目录结构。
（3）角色和权限定义。
（4）配置项变更流程。
（5）配置项发布。
（6）基线定义和基线变更。
项目中的基线有两个方面：一是作为里程碑的基线；另一个是模块的阶段性成果基线（对工作产品而言），一般来说都要避免变更基线。
对这两种不同的基线，其影响的范围不同，确立和变更方式也不一样。
项目的基线变更控制委员会由客户代表、产品经理、项目经理和技术经理组成，对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录，所有被变更影响的配置项都需要重新同步后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在QA进行记录即可。
项目变更管理相关书籍有什么
变化并不是人们最害怕的，最怕的是跟不上变化的步伐。
同样，在软件研发过程中需求的变更会给研发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件研发的进度、成本和质量也就有了＂安全＂的基础。
需求变更管理的需求 需求变更是因为需求发生变化。
根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。
需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。
用户常常以为自己清晰，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改动他们的工作方式；或要研发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。
随着研发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。
于是，他们可能会想到各种新的功能和特色，或对以前提出的需求进行改动。
他们了解得越多，新的需求也就越多，需求变更因此不可避免地一次又一次出现。
这时，如果研发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么非常可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。
当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。
但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。
六大原则 实施需求变更管理需要遵循如下原则： 1.建立需求基线。
需求基线是需求变更的依据。
在研发过程中，需求确定并经过评审后（用户参和评审），能建立第一个需求基线。
此后每次变更并经过评审后，都要重新确定新的需求基线。
2.制订简单、有效的变更控制流程，并形成文件。
在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。
同时，这个流程具有一定的普遍性，对以后的项目研发和其他项目都有借鉴作用。
3.成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。
CCB由项目所涉及的多方人员一起组成，应该包括用户方和研发方的决策人员在内。
4.需求变更一定要先申请然后再评估，最后经过和变更大小相当级别的评审确认。
5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
6.妥善保存变更产生的相关文件。
应对之道 需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。
如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。
变更控制流程如图所示。
针对变更控制流程，笔者在实际工作中总结出了软件研发人员在需求变更管理实践中的几点对策： 相互协作 非常难想像遭到用户抵制的项目能够成功。
在讨论需求时，研发人员和用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。
即使用户提出了在研发人员看来＂过分＂的需求，也应该仔细分析原因，积极提出可行的替代方案。
充分交流 需求变更管理的过程非常大程度上就是用户和研发人员的交流过程。
软件研发人员必须学会认真听取用户的需求、考虑和设想，并加以分析和整理。
同时，软件研发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个研发工作带来什么样的冲击和不良后果。
安排专职人员负责需求变更管理 有时研发任务较重，研发人员容易陷入研发工作中而忽略了和用户的随时沟通，因此需要一名专职的需求变更管理人员负责和用户及时交流。
合同约束 需求变更给软件研发带来的影响有目共睹，所以在和用户签订合同时，能增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更能接受、拒绝接受或部分接受，还能规定发生需求变更时必须执行变更控制流程。
差别对待 随着研发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。
遇见这种情况，研发人员能向用户说明，项目的启动是以最初的基本需求作为研发前提的，如果大量增加新的需求（虽然用户认为是细化需求，但实际上是增加了工作量的新需求），会使项目不能按时完成。
如果用户坚持实施新需求，能建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。
同时，还要注意控制新需求提出的频率。
选用适当的研发模型 采用建立原型的研发模型比较适合需求不明确的研发项目。
研发人员先根据用户对需求的说明建立一个系统原型，再和用户沟通。
一般用户看到一些实际的东西后，对需求会有更为周详的解释，研发人员可根据用户的说明进一步完善系统原型。
这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。
目前业界较为流行的叠代式研发方法对工期紧迫的项目的需求变更控制非常有成效。
项目管理论坛 用户参和需求评审 作为需求的提出者，用户理所当然是最具权威的发言人...
软件项目管理中的需求变更和配置管理中的配置变更有什么关系和区别...
软件配置管理，贯穿于整个软件生命周期，它为软件研发提供了一套管理办法和活动原则。
软件配置管理无论是对于软件企业管理人员还是研发人员都有着重要的意义。
软件配置管理可以提炼为三个方面的内容：VersionControl-版本控制ChangeControl-变更控制ProcessSupport-过程支持目标 1： 软件配置管理的各项工作是有计划进行的。
目标 2： 被选择的项目产品得到识别，控制并且可以被相关人员获取。
目标 3： 已识别出的项目产品的更改得到控制。
目标 4： 使相关组别和个人及时了解软件基准的状态和内容。
关键活动包括：配置项、工作空间管理、版本控制、变更控制、状态报告、配置审计等....
如何在软件项目中进行有效的管理
及时向开发组反映客户的新要求。
让客户得到一个质量上乘功能齐全的产品。
完备的项目管理拥有一支经验丰富的项目管理队伍，计划中规定出项目目标、质量目标，这是项目经理应凭自己的经验调整进度、系统测试阶段和客户测试阶段、质量管理、配置管理、资源状况和调配，在项目初期指定配置管理计划，以质量取信于市场。
CMM2的六个关键域为：需求管理，对项目及项目经理做出合理评价。
配置管理采用先进的配置管理方法。
项目进程中避免不了因需求或其他技术问题干扰进度。
通过CMM2的六个关键域职称项目管理以CMM为目标和支撑进行项目的管理。
在国内软件开发行业一片混乱中，减少双方需求误会和严格控制进度，这依赖于我们有一套严格的项目管理体系。
领导的重视对于一个企业来说领导的重视莫过于的项目管理的最大支持，设置多个检验点，分析态势、重新调配资源项目管理我们不能保证我们的技术方案在各个方面都是最优的，但是我们能够保证最终交给用户的是一套高质量、高可用的系统，让所有客户满意，使公司的开发过程与国际接轨，由QA监督个检验点评审过程，项目外部的QA人员对整个项目的过程进行监控，并严格控制变更。
客观上、分承包商管理。
需求管理在项目经理运用娴熟的项目管理技巧进行客户与公司的沟通，从而达到明确需求和管理需求的目的，通过这支队伍的努力、设计阶段、编码阶段、项目组结构，在严格符合规程的条件下运用项目经理丰富的管理经验将技术和人力资源合二唯一进行管理。
项目经理对外代表公司与客户做最充分的沟通，对内代表客户严格要求质量、资源调配情况心中有数，从而及时化解突发事件。
项目计划我们的项目经理会最终依照客户需求给出该项目的实施计划，我们已拥有规范化和适用于的项目管理流程。
记录较大的需求变更，并愿意通过项目管理提高产品质量。
质量管理无论在项目内部还是项目外部我们都由QA人员对项目进行监督。
多名经验丰富的项目经理管理个项目。
突出管理我们的项目管理决不只是单纯的对规程的遵照，而是注重管理，以该项目计划为基准进行项目的开发和实施。
QA按照事先规定的配置管理基线和项目里程碑进行审核。
重视项目经理的管理技巧和沟通能力，以便在更大程度上满足客户的需求。
项目管理方式项目管理流程介绍： 我们的项目的生命周期大致分为以下几个阶段：需求阶段，规定各阶段的流程并指定责任人。
按照规程和项目实际情况确定个项目的里程碑，决定走国际化的标准轨道，以提高高层的项目管理意识来带动整个公司的项目管理体系日益成熟化、风险预期以成本估算等。
在项目执行过程中，以标准保证质量。
特别要指出的是、项目开发及实施进度，并在开发期间应用。
按照项目生命周期建立配置管理基线，把握项目大方向，接受美国的成熟方法，项目内部QA人员负责测试和配置管理的计划及落实，我们有一部分来自外企和国外的高层人员，我们的高层人员有成熟的项目管理理念，关注项目管理：在我们公司的培训内容上有针对于领导层的项目管理培训系列培训。
项目追踪在项目实施过程中我们要求我们的项目经理每周至少运用项目管理工具Project跟踪两次项目做到对项目的进程，并按照项目管理流程严格监督、项目计划、项目跟踪
如何在项目执行过程中加强质量控制？
1. 事前、事中、事后 三控制2. 事前质量控制，有2点必须做到，具体如下：3. 指项目在实施之前，成立项目质量控制小组；4. 质量控制小组在项目实施之前进行关键质量问题控制研讨，制定质量问题预控制方案，制定质量问题出现后的处理方案；5. 事中质量控制，有2点必须做到，具体如下：6. 在项目实施过程中，按照质量问题预防控制方案，对质量关键问题随时观测并预防，把质量问题控制在萌芽状态，以减少质量问题发生后所造成的严重损失；7. 在项目实施过程中，对于已经发生的质量事故问题，按照事前制定的质量问题处理方案进行处理，并根据现场实际情况对其方案进行调整完善；8. 事后质量控制，在质量问题处理之后，需要做注意的事件有2点如下：9. 一方面是对已经处理完成的质量问题进行监测，及时控制次生质量问题的发生，另一方面是总结已经发生的质量问题，及时调整质量问题预控方案措施，为之后的质量控制做好铺垫工作。
-