软件项目中的变更及其应对.docx
《软件项目中的变更及其应对.docx》由会员分享，可在线阅读，更多相关《软件项目中的变更及其应对.docx（8页珍藏版）》请在冰豆网上搜索。
软件项目中的变更及其应对
软件项目中的变更及其应对
软件项目依据统计有80%以上的项目不能够按时提交给客户使用，与其它类型的项目比是失败率最高的。
是什么导致项目的延期甚至失败呢？
本文再此必要对项目的失败的原因作一个深入的分析，并提出一些解决的思路
打算一个项目成功的因素有许多：
高质量的团队、清楚的项目目标、对项目进行的有效管理、有效掌握的客户需求等。
在ＣＭＭ软件成熟度模型的５个级别中，第２级中第一个ＫＰＡ（关键过程域）就是需求管理，ＣＭＭ中第一级的概念是初始状态的公司，需求管理实际上是ＣＭＭ模型里面第一个要求实现的关键过程域，可见其重要性。
总结在多年的软件项目管理实践，我认为：
软件项目管理过程中，需求的变更是无法避免的。
假如哪一个开发商要对客户说：
客户需求在开头确定后就不能修改，我估计他十有八、九拿不到这个订单，没有哪一个客户情愿。
如何才能改善需求的管理，削减需求变更或需求变更的影响了，我认为要在以下三个方面做好相应的工作：
１）与客户建立良性的、基于理性的合作环境
２）在软件工程的方位内，尽量削减需求变更的影响
３）建立一套行之有效的，在项目启动阶段就应当得到客户认可的需求管理制度
一、与客户建立良性的、基于理性的合作环境
需求过程本身的问题
·在需求确定的过程中，客户往往会把他建议的解决方法当成了需求本身
·客户或开发者有时候会假定对方已经明白自己的意思，有些需求是理所当然的。
外部因素导致的变更
·经营方向的转变
·政策因素的影响
我们能够因为客户的变更不在合约的目标范围之内而拒绝变更呢？
在国内的软件项目实践中，在目前主要是以客户关系为中心的销售模式下，要做到这点特别的困难。
我们必需要假定需求是一定会修改的，
1）与客户建立良性的、基于理性的关系
如何与客户建立理性和良好的关系呢？
我们首先要对客户有一个分析和了解：
国内的客户分为两类：
一类为国家单位和大型企业的IT部门，这些部门对项目的成本的敏感性比较低，但对项目的成功与否，是否会延期等特别敏感，因为在一个大型的企业或单位里面，这关系自己的表现。
另一类为小规模的企业，这类小规模的企业往往是由企业的负责人（或者直接就是老板）来拍板某一个系统，这类企业对项目的成本就会特别敏感。
在项目管理的概念中，有一个客户的干系人的概念，什么是项目的干系人？
在需求调研分析阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。
由于项目经理和需求分析员的工作问题，客户参与程度部不高，客户方相关责任人不明确或对范围和需求责任心不强，提出的需求具有随便性，项目前期对需求的确认不够积极；或者是多个用户代表各说各话、昨是今非但同时又期望软件尽早交付；项目后期需求变化随便，造成项目范围的扩散，进度的拖延，成本的扩大。
造成上述现象的原因是系统分析人员没有全面了解全部项目干系人的需求，并根据重要性优先级进行权衡取舍。
全面的需求来自全部项目干系人。
项目干系人STAKEHOLDER也有的翻译成利益关系人、利害关系人、利益干系人、利益共享者、涉众，如此等等，即全部可能受到项目结果重大影响的人。
项目干系人即可能是项目的受益者，也是项目的风险担当者，甚至有可能是项目的受害者。
项目干系人的需求包含明确的和隐含的，也可以分为NEED、WANT、WISH等不同层次。
不同的干系人其愿望和追求的目标往往相差甚远，因此对项目干系人的愿望进行平衡可能是相当困难的事情。
例如政府部门预备建设的不少对群众办公的信息系统，上层管理机关往往期望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析，同时为了对信息进行有效掌握而增加一些审批流程；基层对外办公的窗口则因为办公速度的压力期望削减信息项的输入量；甚至有些不良的基层客户由于可怕建立透明度高的信息系统会影响他们的工作考核成果而消极地应付，即所谓反需求；而客户的客户（办事群众）则期望相关政府机构能够简化工作流程，加快办事速度；一些客户相关的管理机构或组织也会制定一些有关的标准规范；作为项目干系人的公司领导层也可能会提出一些技术上、接口上、环境上的需求；甚至项目组本身因为技术、资源、进度等原因，需要对一些功能进行优先级排序和取舍。
虽然不是全部人的需求都是可以满意的，特殊是消极的反需求是不能接受的，但他们的需求都是应当考虑全面并进行平衡的。
软件开发项目的目的就是实现项目干系人的需求和愿望。
假如对项目全部干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则可能因为项目开头时项目范围和一些详细需求不够完整清楚，也可能因为某个项目干系人后期因为熟悉的变化而提出新的需求，造成工期的延长，成本的增加，甚至项目的完全失败。
因此，应当从项目的启动开头，需求分析员及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。
以下是一些有效的措施：
1、尽快熟识项目干系人全貌
有些项目在做需求调查时，由于受进度要求等客观因素影响，需求分析员与建设单位的技术部门交流较多，向业务管理部门和实际使用者调查不够深入，造成软件试用后不得不再对需求做较大调整，"从头再来"的部分比例很高，大大超过进度要求时间。
因此，熟识项目干系人全貌是进行需求调查的第一步，也是需求调查的基础。
在定制开发项目的项目干系人中，最重要的是建设单位中的人事组织、业务关系。
最好是能够用组织结构图画出相关单位的组织结构；用责任矩阵确定各部分的调研对象；建立调研对象通讯录以保证调研及分析期间准时的沟通。
与此同时要留意项目干系人的主次关系，以便在他们之间的需求出现矛盾时能够进行合理的取舍。
熟识建设单位内部相关部门的业务划分及它们之间的相互关系,为功能分析预备了必要的资料,同时可以熟识用户方的各类人员，并准时进行广泛、有效的沟通与交流。
特殊要与客户方业务与技术的规划者和实际使用者进行深入探讨，收集必要的原始资料，保证需求调查的完整性、正确性。
建设单位只是项目干系人中的一部分（当然是主要的部分），为了更好地了解项目干系人全貌，还应当在建设单位组织结构图基础上全体项目干系人结构图，以便更好更全面地进行需求调研分析。
2、具体描述各项业务，以利于让全部客户确认
尽可能全面具体地调查并且描述原有系统和用户期望将来系统具有的各项业务的流程，并将这些业务流程文档化后与客户进行争论，对描述错误或不精确不精确的进行修改，最终让客户进行确认。
从近年来开发的软件看，对业务处理过程了解的完整性和精确性特别重要。
虽然对数据来说都是SIDUT（查增删改传），但详细业务都是分为若干步骤，每个步骤都有其业务名称，同一步骤可能对多个数据集进行不同操作，需要调查了解清晰才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。
当然在进行软件概要设计时，要尽量排解业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，充分考虑他们与其他各种业务对象的接口，在流程之间通过业务对象的相互调用实现其业务流程，这样，在业务流程发生有限的变化时，就能够比较便利地修改系统程序而实现新的需求。
对于各项业务的调查可以通过对以下资料的收集整理分析，这些资料来自各种各样的项目干系人：
遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。
3、可视化需求调研，引导各种客户挖掘他们的需求
有的客户因为自己缺乏计算机学问，无法提出完整精确、隐含的或潜在的需求。
但若这些需求不能满意将导致用户的不满。
因此需求调研分析人员应擅长想用户所想，不但要确定明确的需求，还要擅长用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。
这就要求需求调研分析员要尽快完整地熟识相关业务，从而能够站在用户的立场看待软件需求，想用户所想，做好业务与计算机之间的桥梁。
利用可视化需求调研的方法可以很好地启发用户深入挖掘潜在的需求。
可视化需求调研就是使用图表等工具来启发引导用户清晰地叙述需求，并且使需求更加全面完善。
对于高层领导，可以供应系统总体框架图；对于业务管理人员，可以用业务流程图来描述新旧系统的业务流程；对于客户中的技术人员，可以用数据流图、实体关系图或UML中的各种图形对系统进行各种角度的描述；而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。
[NextPage]
这里特殊说明一下用户界面的重要性。
用户界面的设计按理来说是软件设计的责任，当然客户自己对界面有特殊提出要求的除外。
但是，假如把它提前到需求调研时（紧接着原有系统调研分析和系统模型完成之后）与客户进行争论，则可以大大改善需求调研的效果。
因此不少需求分析的著作把用户界面说成是“设计层”的需求之一。
因为这时客户对于将来的系统还没有一个形象上的概念，或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化。
以笔者的经验，画出用户界面草图与客户进行争论，可以大大激发他们供应更为精确全面的需求。
原来收集资料，描述业务，说明系统模型到了山穷水尽的时候，这种方法可以达到柳暗花明又一村的效果。
在《微软项目：
求生法则》的第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类全部可能的状态，并预先加入设计，这种需要付出更多的设计、开发、维护的代价，而且也很难达到完美的效果，所以不多说了。
[NextPage]
下面介绍一种经典的设计思路，这种设计可以充分体现“为（系统）将来转变预留接口”的可扩展性（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）中，独立于底层实现和客户需求的变更。
[NextPage]
·服务的互操作（interoperability）。
互操作并不是一个新概念。
在CORBA、DCOM、webservice中就已经采用互操作技术了。
在SOA中，通过服务之间既定的通信协议进行互操作。
主要有同步和异步两种通信机制。
SOA供应服务的互操作特性更利于其在多个场合被重用。
·服务是自治的（Autonomous）功能实体。
服务是由组件组成的组合模块，是自包含和模块化的。
SOA特别强调架构中供应服务的功能实体的完全独立自主的能力。
传统的组件技术，如.NETRemoting，EJB，COM或者CORBA，都需要有一个宿主（Host或者Server）来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。
这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。
SOA架构中特别强调实体自我管理和恢复能力。
常见的用来进行自我恢复的技术，比如事务处理（Transaction），消息队列（MessageQueue），冗余部署（RedundantDeployment）和集群系统（Cluster）在SOA中都起到至关重要的作用。
·服务之间的松耦合度（LooslyCoupled）。
服务恳求者到服务供应者的绑定与服务之间应当是松耦合的。
这就意味着，服务恳求者不知道供应者实现的技术细节，比如程序设计语言、部署平台，等等。
服务恳求者往往通过消息调用操作，恳求消息和响应，而不是通过使用API和文件格式。
这个松耦合使会话一端的软件可以在不影响另一端的状况下发生转变，前提是消息模式保持不变。
在一个极端的状况下，服务供应者可以将以前基于遗留代码（例如，COBOL）的实现完全用基于Java语言的新代码取代，同时又不对服务恳求者造成任何影响。
这种状况是真实的，只要新代码支持相同的通信协议。
·服务是位置透明的（bbbbbbbbtransparency）。
服务是针对业务需求设计的。
需要反应需求的变化，即所谓机敏（agility）设计。
要想真正实现业务与服务的分别。
就必需使得服务的设计和部署对用户来说是完全透明的。
也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道详细是哪个服务参与了响应。
4.三个抽象级
从概念上讲，SOA中有三个主要的抽象级别：
·操作：
代表单个规律工作单元（LUW）的事务。
执行操作通常会导致读、写或修改一个或多个长久性数据。
SOA
升级会员 