软件项目中的变更及其应对.doc
软件项目中的变更及其应对 软件项目根据统计有 80%以上的项目不能够按时提交给客户使用,与其它类型的项目比是失败率最高的。是什么导致项目的延期甚至失败呢? 本文再此必要对项目的失败的原因作一个深入的分析,并提出一些解决的思路 决定一个项目成功的因素有很多:高质量的团队、清晰的项目目标、对项目进行的有效管理、有效控制的客户需求等。 在CMM 软件成熟度模型的5个级别中,第2级中第一个 KPA(关键过程域) 就是需求管理,CMM 中第一级的概念是初始状态的公司,需求管理实际上是CMM模型里面第一个要求实现的关键过程域,可见其重 要性。 总结在多年的软件项目管理实践,我认为:软件项目管理过程中,需求的变更是无法避免的。如果哪一个开发商要对客户说:客户需求在开始确定后就不能修改,我估计他十有八、九拿不到这个订单,没有哪一个客户愿意。 如何才能改善需求的管理,减少需求变更或需求变更的影响了,我认为要在以下三个方面做好相应的工作: 1)与客户建立良性的、基于理性的合作环境 2)在软件工程的方位内,尽量减少需求变更的影响 3)建立一套行之有效的,在项目启动阶段就应该得到客户认可的需求管理制度 一、与客户建立良性的、基 于理性的合作环境 需求过程本身的问题 ·在需求确定的过程中,客户往往会把他建议的解决方法当成了需求本身 ·客户或开发者有时候会假定对方已经明白自己的意思,有些需求是理所当然的。 外部因素导致的变更 ·经营方向的改变 ·政策因素的影响我们能够因为客户的变更不在合约的目标范围之内而拒绝变更呢?在国内的软件项目实践中,在目前主要是以客户关系为中心的销售模式下,要做到这点非常的困难。 我们必须要假定需求是一定会修改的, 1)与客户建立良性的、基于理性的关系 如何与客户建立理性和良 好的关系呢?我们首先要对客户有一个分析和了解: 国内的客户分为两类: 一类为国家单位和大型企业的 IT 部门,这些部门对项目的成本的敏感性比较低,但对项目的成功与否,是否会延期等非常敏感,因为在一个大型的企业或单位里面,这关系自己的表现。 另一类为小规模的企业,这类小规模的企业往往是由企业的负责人(或者直接就是老板)来拍板某一个系统,这类企业对项目的成本就会非常敏感。 在项目管理的概念中,有一个客户的干系人的概念,什么是项目的干系人? 在需求调研分析阶段,项目组对客户的整体组织结构、有关人员 及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理和需求分析员的工作问题,客户参与程度部不高,客户方相关责任人不明确或对范围和需求责任心不强,提出的需求具有随意性,项目前期对需求的确认不够积极;或者是多个用户代表各说各话、昨是今非但同时又希望软件尽早交付;项目后期需求变化随意,造成项目范围的蔓延,进度的拖延,成本的扩大。 造成上述现象的原因是系统分析人员没有全面了解所有项目干系人的需求,并按照重要性优先级进行权衡取舍。全面的需求来自所有项目干系人。项目干系 人 STAKEHOLDER 也有的翻译成利益关系人、利害关系人、利益干系人、利益共享者、涉众,如此等等,即所有可能受到项目结果重大影响的人。项目干系人即可能是项目的受益者,也是项目的风险承担者,甚至有可能是项目的受害者。项目干系人的需求包含明确的和隐含的,也可以分为 NEED、WANT、 WISH 等不同层次。 不同的干系人其愿望和追求的目标往往相差甚远,因此对项目干系人的愿望进行平衡可能是相当困难的事情。例如政府部门准备建设的不少对群众办公的信息系统,上层管理机关往往希望能够采集尽可能多的信息项以便对数据进行 多种多样的统计分析,同时为了对信息进行有效控制而增加一些审批流程;基层对外办公的窗口则因为办公速度的压力希望减少信息项的输入量;甚至有些不良的基层客户由于害怕建立透明度高的信息系统会影响他们的工作考核成绩而消极地应付,即所谓反需求;而客户的客户(办事群众)则希望相关政府机构能够简化工作流程,加快办事速度;一些客户相关的管理机构或组织也会制定一些有关的标准规范;作为项目干系人的公司领导层也可能会提出一些技术上、接口上、环境上的需求;甚至项目组本身因为技术、资源、进度等原因,需要对一些功能进行优先级排序和取舍。 虽然不是所有人的需求都是可以满足的,特别是消极的反需求是不能接受的,但他们的需求都是应当考虑全面并进行平衡的。 软件开发项目的目的就是实现项目干系人的需求和愿望。如果对项目所有干系人没有进行足够的沟通和影响,使其尽可能地参与项目,则可能因为项目开始时项目范围和一些具体需求不够完整清晰,也可能因为某个项目干系人后期因为认识的变化而提出新的需求,造成工期的延长,成本的增加,甚至项目的完全失败。因此,应当从项目的启动开始,需求分析员及其项目成员就要分清项目干系人包含哪些人和组织,通过沟通协调对他们施加影响,驱 动他们对项目的支持,调查并明确他们的需求和愿望,减小其对项目的阻力,以确保项目获得成功。以下是一些有效的措施: 1、尽快熟悉项目干系人全貌 有些项目在做需求调查时,由于受进度要求等客观因素影响,需求分析员与建设单位的技术部门交流较多,向业务管理部门和实际使用者调查不够深入,造成软件试用后不得不再对需求做较大调整, "从头再来 "的部分比例很高,大大超过进度要求时间。因此,熟悉项目干系人全貌是进行需求调查的第一步,也是需求调查的基础。在定制开发项目的项目干系人中,最重要的是建设单位中的人事组织、业务关系。 最好是能够用组织结构图画出相关单位的组织结构;用责任矩阵确定各部分的调研对象;建立调研对象通讯录以保证调研及分析期间及时的沟通。与此同时要注意项目干系人的主次关系,以便在他们之间的需求出现矛盾时能够进行合理的取舍。 熟悉建设单位内部相关部门的业务划分及它们之间的相互关系 ,为功能分析准备了必要的资料 ,同时可以熟悉用户方的各类人员,并及时进行广泛、有效的沟通与交流。特别要与客户方业务与技术的规划者和实际使用者进行深入探讨,收集必要的原始资料,保证需求调查的完整性、正确性。建设单位只是项目干系人中的一部分(当 然是主要的部分),为了更好地了解项目干系人全貌,还应当在建设单位组织结构图基础上全体项目干系人结构图,以便更好更全面地进行需求调研分析。 2、详细描述各项业务,以利于让所有客户确认 尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有的各项业务的流程,并将这些业务流程文档化后与客户进行讨论,对描述错误或不准确不精确的进行修改,最终让客户进行确认。从近年来开发的软件看,对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是 SIDUT(查增删改传),但具体业务都是分为若干步骤,每个步骤都有 其业务名称,同一步骤可能对多个数据集进行不同操作,需要调查了解清楚才能设计出适合各流程业务节点用户业务特点和习惯的软件,使开发出来的软件更受欢迎。当然在进行软件概要设计时,要尽量排除业务流程的制约,即把流程中的各项业务结点工作作为独立的对象,充分考虑他们与其他各种业务对象的接口,在流程之间通过业务对象的相互调用实现其业务流程,这样,在业务流程发生有限的变化时,就能够比较方便地修改系统程序而实现新的需求。 对于各项业务的调查可以通过对以下资料的收集整理分析,这些资料来自各种各样的项目干系人:遵循的标准、组 织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。 3、可视化需求调研,引导各种客户挖掘他们的需求 有的客户因为自己缺乏计算机知识,无法提出完整准确、隐含的或潜在的需求。但若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想,不但要确定明确的需求,还要善于用启发的方式与用户探讨隐含的或潜在的需求,并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研 分析员要尽快完整地熟悉相关业务,从而能够站在用户的立场看待软件需求,想用户所想,做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深入挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求,并且使需求更加全面完善。 对于高层领导,可以提供系统总体框架图;对于业务管理人员,可以用业务流程图来描述新旧系统的业务流程;对于客户中的技术人员,可以用数据流图、实体关系图或 UML 中的各种图形对系统进行各种角度的描述;而对于业务管理人员、客户中的技术人员、以及各层次各流程中的 用户,画出用户界面图来进行需求挖掘,是个比较有效的沟通方式。 这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任,当然客户自己对界面有特别提出要求的除外。但是,如果把它提前到需求调研时(紧接着原有系统调研分析和系统模型完成之后)与客户进行讨论,则可以大大改善需求调研的效果。因此不少需求分析的著作把用户界面说成是“设计层”的需求之一。因为这时客户对于将来的系统还没有一个形象上的概念,或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化。以笔者的经验,画出用户界面草图与客户进行讨论 ,可以大大激发他们提供更为准确全面的需求。原来收集资料,描述业务,说明系统模型到了山穷水尽的时候,这种方法可以达到柳暗花明又一村的效果。在《微软项目:求生法则》的第 8 章“需求开发”中,从头到尾都是围绕着“使用者接口”( USERINTERFACE 也可以翻译成“用户界面”)进行讨论,如“建立简单的使用者接口雏形”、“不断修订使用者接口雏型,直到使用者对软件感到兴趣盎然为止”、“完全扩展使用者接口”,同时还要“区分一份非使用者接口需求文件”,等等。因此,所谓需求就是“当你按下各种相关按钮(或输入各种相关命令)时系 统做什么”,所谓设计就是“当你按下各种相关按钮(或输入各种相关命令)时系统怎么做”。虽然在英语中“接口”与“界面”实际是同一个单词,但“接口”的含义似乎比“界面”来得广泛,如功能之间的接口、与其他软件的接口、与其他硬件的接口等等。需求的最终目的实际上是完整准确地描述系统需要的各种接口或“界面”,及它们的相互关系或与外部环境的关系,如界面中的某个按钮按下去时,可能产生新的界面、新的按钮、或者调用其他软件硬件完成某些功能。自顶向下,把这些界面及涉及到的数据描述清楚,就是一份不错的需求。 4、与其他项目小组成 员共同协作、持续完善系统需求 需求文档完成之后,并不是万事大吉,把它扔给后面的设计人员就了事了。作为项目干系人之内的项目组其他成员,对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分,但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目,上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受,其有效性、合理性也要被下一阶段的工作所检验,通过检验有时也有必要对上一阶段的工作结果进行相应的调整,需求更是如此 。因此,无论是同一阶段不同人员之间,或是不同阶段人员之间都应根据需要相互协作,相互配合,共同完成软件开发任务。 二、在软件工程的方位内,尽量减少需求变更的影响 系统的各模块应该设计成送耦合的,采用 OO 技术可以建立易于改变和加强可重用性的软件系统。对于 OO 技术,我想现在已经不是什么陌生的概念: 1 封装( Encapsulation)可以把问题影响的范围缩小,外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中,从而改变系统的一部分相对简单; 2 继承( Inheritance)可以使改变基于原 有技术基础,很大程度上减少重复开发工作; 3 多态( Polymorphism)的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节,从而改变系统的行为; 4 而且由于对 OO的类体系结构业界有非常清楚明晰的描述方式,就是目前规范的描述语言 -UML,非常易于被开发组的理解并达成共识,促进开发组成员之间的合作以及加强软件开发工作的可延续性;可见本身即是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法,本身可以在一定程度上快速对需求变更进行反应,并可相对减少需求变更需要的成本。( OO 的意义在于分析和设计软件系统的思考方式,以及建立对象库以后的软件重用将给软件系统的开发带来质的改变,但是在建立 OO 开发体系之前的过程,一定会是一段荆棘遍布的路,需要付出加倍的努力以及达成思想的转变。这里还有一个误区需要澄清的是很多人以为用了C++, PB, VB, DELPHI 就是面向对象的开发了,其实只是用了一些面向对象的工具,骨子里仍然是结构化的分析和设计方法,套上一层 OOP 的外壳而已。) 可扩展性设计( Extensible-Design) 其次,从我们可以控制的软件设计来说,怎样进行合适的设计才能最 大程度减少需求变更带来的代价? 也许有人说,我的设计极为灵活,我已经预计了客户可能提出的要求,并设计几种应对的方式,到时候客户提出来,呵呵,我已经解决了。这样的想法不错,至少比僵硬的设计强,但是谁可以保证设计者可以预知以后的需求变化?而同时为了达到这种灵活(万能 /多能?)的设计,设计将变得复杂,而且可能那些多余的设计从来不会被用到?复杂的设计将增加实现的难度和提高成本,并有可能带来潜在的 Bug,使得系统难以维护。 设计的思想应该有一些小小的转变,那就是,设计确实要灵活,但是要体现在可扩展性上面,也就 是说,设计可以简单,但是一定要易于转变,需要给出便于改变的接口,这一点很重要。 例如,现在有一个类叫做 TCPConnection,来代表计算机网络通信中典型的 TCP 连接,对于这个连接而言,它可能处于以下几种状态: Established(连接已建立), Listening(正在侦听), Closed(连接关闭)。一个连接对象需要从其他的对象接受请求,至于它的反应则决定于连接对象所处的状态,对于(打开连接的请求),如果是在连接关闭状态,则进行 Open(),处于其他状态则不做反应;同样,如果在连接建立和侦听状态, 可以进行 Close(),在连接建立状态可以进行 Acknowledge(),即接收数据。 对于这样的状况,最不可取的设计应该是用一系列的Switch 语句(甚至 If/else 语句)进行 Hard 设计,对于以后每一次需求改变,都需要改变源代码,接踵而来的系统一致性、文档更新等工作将使开发人员不可避免地陷入一场灾难,这样的后果将导致原来就不合理的设计变得更加支离破碎,系统维护的代价将越来越大;就算没有需求变更发生,这些设计的可重用性也会极差。 稍好一些的设计是预先估计并设置 TCPConnection 类所有可能 的状态,并预先加入设计,这种需要付出更多的设计、开发、维护的代价,而且也很难达到完美的效果,所以不多说了。 下面介绍一种经典的设计思路,这种设 计 可 以 充 分 体 现 “ 为 ( 系 统 ) 将 来 改 变 预 留 接 口 ” 的 可 扩 展 性( Extensible-Design)思想,并且很好的实现了这一思想。在这里,我们引入一个抽象类 TCPState 来代表 TCPConnection 类的状态,给出具体各种状态的通用操作接口,并派生出不同的子类(实现具体的操作)去实现 TCPConnection类的不同状态,例如派生 TCPEstablished 类来实现 TCPConnection 类的连接建立状态。 只需要在 TCPConnection 类中包含一个 TCPState 的状态引用,并在 TCPConnection 的状态改变时更新为当前的状态引用,例如在连接关闭时进行Open(),状态引用就应该从 TCPClosed 变成 TCPEstablished,这样就实现了原来的要求。 但这个设计思路的意义远不止于此。我们可以看到,抽象类TCPState 已经为 TCPConnection 类将来可能的状态留出接口,只需要不断派生具体的不同状态子类就可以实现将来的状态变更,并且无须影 响原有的设计,也无须加入多余的代码来实现现在还不需要的功能,所以这是一个优美的、可扩展的设计思路,非常清晰,易于维护,相信可以给我们在做软件设计时带来一些启发。 系统应该采用 Open 的技术标准 采用 SOA 的开发架构,是进一步降低系统耦合度的措施在经典软件工程理论中,不管是瀑布方法还是原型方法,都是从需求分析做起,一步一步构建起形形色色的软件系统。但是,需求变更像一个挥之不去的阴影,时刻伴随着系统左右。每一个实际应用系统的开发者都饱尝了在系统进入开发阶段、测试阶段,甚至上线阶段遭遇应接不暇的需求变更 的极端痛苦。客户将变更的需求视为 bug(错误 )是测试上线阶段的主要问题。 如何解决这一问题?能否来一场软件开发和架构的革命? SOA 架构的提出,就是被人看成这样的一场革命。其实质就是要将系统模型与系统实现分割开来。 1.定义 SOA 并不是一个新概念,有人就将 CORBA 和 DCOM 等组件模型看成 SOA 架构的前身。早在 1996 年, GartnerGroup 就已经提出了 SOA 的预言,不过那个时候仅仅是一个“预言”,当时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。到了近一两年, SOA 的技术实 现手段渐渐成熟了。在BEA、 IBM 等软件巨头的极力推动下,才得以慢慢风行起来。 Gartner 为 SOA 描述的愿景目标是实现实时企业 (Real-TimeEnterprise)。 关于 SOA,目前尚未有一个统一的、业界广泛接受的定义。一般认为: SOA,面向服务的架构是一个组件模型,它将应用程序的不同功能单元 ----服务 (service),通过服务间定义良好的接口和契约 (contract)联系起来。接口采用中立的方式定义,独立于具体实现服务的硬件平台、操作系统和编程语言,使得构建在这样的系统中的服务可以使用统一 和标准的方式进行通信。这种具有中立的接口定义 (没有强制绑定到特定的实现上 )的特征称为服务之间的松耦合。 从这个定义中,我们看到下面两点: ·软件系统架构: SOA 不是一种语言,也不是一种具体的技术,更不是一种产品,而是一种软件系统架构,它尝试给出在特定环境下推荐采用的一种架构,从这个角度上来说,它其实更像一种架构模式 (Pattern),是一种理念架构,是人们面向应用服务的解决方案框架。 ·服务 (service)是整个 SOA实现的核心。 SOA 架构的基本元素是服务, SOA 指定一组实体 (服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约 ),这些实体详细说明了如何提供和消费服务。遵循 SOA 观点的系统必须要有服务,这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的并且可以通过网络查找其地址。 2.SOA 三种角色的关系 服务是一个自包含的、无状态 (stateless)的实体,可以由多个组件组成。它通过事先定义的界面响应服务请求。它也可以执行诸如编辑和处理事务 (transaction)等离散性任务。服务本身并不依赖于其他函数和过程的状态。用什么技术实现服务,并不在其定义中加以限制。 服务提供者 (serviceprovider)提供符合契约 (contract)的服务,并将它们发布到服务代理。 服务请求者 (serviceconsumer)也叫服务使用者,它发现并调用其他的软件服务来提供商业解决方案。从概念上来说, SOA 本质上是将网络、传输协议和安全细节留给特定的实现来处理。服务请求者通常称为客户端,但是,也可以是终端用户应用程序或别的服务。 服务代理者 (servicebroker)作为储存库、电话黄页或票据交换所,产生由服务提供者发布的软件接口。 这三种 SOA参与者:服务 提供者、服务代理者以及服务请求者通过 3 个基本操作:发布(publish)、查找 (find)、绑定 (bind)相互作用。服务提供者向服务代理者发布服务。服务请求者通过服务代理者查找所需的服务,并绑定到这些服务上。服务提供者和服务请求者之间可以交互。 所谓服务的无状态,是指服务不依赖于任何事先设定的条件,是状态无关的 (state-free)。在 SOA 架构中,一个服务不会依赖于其他服务的状态。它们从客户端接受服务请求。因为服务是无状态的,它们可以被编排 (orchestrated)和序列化 (sequenced)成多个序列 (有时还采用流水线机制 ),以执行商业逻辑。编排指的是序列化服务并提供数据处理逻辑。但不包括数据的展现功能。 3.SOA 特征 基于上面讨论,我们给出 SOA的下面一些特征: ·服务的封装 (encapsulation)。将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的 API 保持不变,使得用户远离具体实施上的变更。·服务的重用 (reuse)。服务的可重用性设计显著地降低了成本。为了实现可重用性, 服务只工作在特定处理过程的上下文(context)中,独立于底层实现和客户需求的变更。 ·服务的互操作(interoperability)。互操作并不是一个新概念。在 CORBA、 DCOM、 webservice中就已经采用互操作技术了。在 SOA 中,通过服务之间既定的通信协议进行互操作。主要有同步和异步两种通信机制。 SOA 提供服务的互操作特性更利于其在多个场合被重用。 ·服务是自治的 (Autonomous)功能实体。服务是由组件组成的组合模块,是自包含和模块化的。 SOA 非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术,如 .NETRemoting, EJB, COM 或者 CORBA,都需要有一个宿主 (Host 或者 Server)来存放和管理这些功能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候,在该宿主上运行的其它应用服务就会受到影响。 SOA 架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术,比如事务处理 (Transaction) ,消息队列 (MessageQueue) ,冗余部署(RedundantDeployment)和集群系统 (Cluster)在 SOA 中都起到至关重要的作用。 ·服务之间的松耦合度 (LooslyCoupled)。服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着,服务请求者不知道提供者实现的技术细节,比如程序设计语言、部署平台,等等。服务请求者往往通过消息调用操作,请求消息和响应,而不是通过使用 API 和文件格式。 这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变,前提是消息模式保持不变。在一个极端的情况下,服务提供者可以将以前基于遗留代码 (例如, COBOL)的实现完全用 基于 Java 语言的新代码取代,同时又不对服务请求者造成任何影响。这种情况是真实的,只要新代码支持相同的通信协议。 ·服务是位置透明的 (locationtransparency)。服务是针对业务需求设计的。需要反应需求的变化,即所谓敏捷 (agility)设计。要想真正实现业务与服务的分离。就必须使得服务的设计和部署对用户来说是完全透明的。也就是说,用户完全不必知道响应自己需求的服务的位置,甚至不必知道具体是哪个服务参与了响应。 4.三个抽象级 从概念上讲, SOA 中有三个主要的抽象级别: ·操作 :代表单个逻辑工作单元 (LUW)的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。 SOA 操作可以直接与面向对象 (OO)的方法相比。它们都有特定的结构化接口,并且返回结构化的响应。完全同方法一样,特定操作的执行可能涉及调用附加的操作。 ·服务:代表操作的逻辑分组。服务可以分层,以降低耦合度和复杂性。一个服务的粒度 (granularity)大小也与系统的性能息息相关。粒度太小,会增加服务间互操作通讯的开销;粒度太大,又会影响服务面对需求变化的敏捷性。 ·业务流程:为实现特定业务目标而执行的一组 长期运行的动作或活动。业务流程通常包括多个业务调用。 在 SOA 中,业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。从建模的观点来看,由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。这些涉及服务建模、特征抽取的问题已经成为现阶段人们关注的焦点。 三、建立一套行之有效的,在项目启动阶段就应该得到客户认可的需求管理制度对变更的内容进行严格的控制实施需求变更管理需要遵循如下原则: 1.建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。 2..制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。 3.成立项目变更控制委员会( CCB)或相关职能的类似组织,负责裁定接受哪些变更。 CCB 由项目所涉及的多方人员共同组成,应该包括用户方和开发 方的决策人员在内。 4.需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。 5.需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。 6.妥善保存变更产生的相关文档。 需求变更既然不可避免,那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分以下步骤:提出变更à变更评估à实施变更。 需求变更处理流程 因为现实世界的软件系统可能有不同的严格程度和复杂性,所以事先预言所有的相关需求是不可能的。系统原计划的操作环境会改变,用户的需 求会改变,甚至系统的角色也有可能改变。实现和测试系统的行为可能导致对正解决的问题产生新的理解和洞察,这种新的认识就有可能导致需求变更。 CMM 提出“分配需求的变更被复审,并加入到软件项目中来”,其关键是在需求发生变更时,没有必要马上把这些变更付诸于软件开发工作之中。实际上,坚持把需求变更付诸开发努力,企业就会形成一种混乱且不稳定的氛围,进而严重破坏项目的控制和管理。需求管理关键过程试图通过把分配需求的变更囤积到可管理的组中,等到开发工作允许的时候再引人相应的方法,避免产生这种混乱的氛围。结果,需求管理创建了一 个隔绝开发工作与所有真实的、潜在无序的、来自于客户的变更。这个缓冲器允许真实的变更被注意、记录、追踪,同时开发工作又不会因此而被扰乱。开发项目应该周期性地暂停来吸收最新的需求变更积累,此时,所有的计划、设计、行为都根据刚刚吸收的需求变更的影响进行更新。 需求变更的控制当然与项目管理范畴之外的纯技术因素息息相关,比如面向对象的分析、面向对象的设计、面向对象的编码方式等等。但所有技术的发展趋势都是一样,那就是为了使变更管理变得更容易,因此,不论在项目变更控制中采取什么方法、策略,对于项目本身的变化一定要时时 洞悉,处处留意,只有这样才能从真正意义上对项目进行很好的变更控制。