如何应对软件开发中的需求变更【摘要】在软件项目开发的过程中，软件的需求变更是一个回避不了的问题，它的处理的好坏，更是决定软件开发项目是否能够顺利、完美、高效率得到实现的关键。

本文针对STS8000测试系统在软件项目开发过程中出现的常见问题，探讨了如何应用项目需求变更管理、项目目标管理、版本更新管理与软件测试管理，从而帮助并促进软件开发人员开发出更加完美、高效、稳定、有质量的软件产品。

【关键词】需求变更管理；软件项目目标管理；版本更新管理；软件测试管理随着软件系统的规模、复杂度日益上升，软件开发过程中的各种质量管理已经成为保证软件系统开发效率、质量、成本的关键性因素。

软件行业在现在的众多行业里是一个极具挑战性和创造性的行业，体现了软件开发者的智慧和汗水，同时软件开发是一项复杂的系统工程，牵涉到许多方面的因素，在实际工作中，经常会出现各种各样的问题。

如何总结、分析并解决软件开发过程中各种问题，对于项目开发人员与管理人员来说，是在今后的项目中取得成功的关键。

目前，STS8000系统在软件方面出现的问题主要有下面几方面：1、客户不断提出新的需求。

软件开发人员不断地陷于满足用户需求的过程中。

似乎，我们在需求上无能为力，我们永远在追赶客户的需求，满足他们的现状，把N多家的客户需求都加进软件中，只要能实现的，我们尽量咬牙实现了。

最后，我们发现，我们的软件无比复杂，谁也不知道这个需求当时为什么是这样的。

因为无比复杂，所以稳定性更成了问题。

代码互相交叉，根本无法理清有多少交叉影响点。

2、改正了旧问题，又冒出更多新问题，问题层出不穷；维护的工程师都快崩溃了，天天在祈求，千万别接到客户电话。

对于修改现有代码适应新客户新项目，这种情况出现的非常多。

客户打电话说了一个需求，能技术达到就答应下来修改，修改完就给客户覆盖，根本没有需求变更管理、版本更新管理。

而这样的代码，还不是一个特定客户一套特定定制化代码，是要给其他客户也更新的。

很可能这个客户好使，那个客户使用其他功能的时候就出了错。

按下葫芦起了瓢，是很常见的现象。

3、由于长期陷于满足用户需求的过程中，天长日久，软件工程师就会木然、倦怠，会形成做一天和尚撞一天钟。

有问题就打补丁，客户不嚷嚷就懒的修改，代码不优化、不封装，界面不友好，架构更是没架构。

模块难度、工期质量考核无法量化，更无法与个人收入挂钩。

以上三个问题，其实归纳起来就一个关键点：如何处理好需求这个问题，从而使客户、公司、研发人员多方达到共赢。

下面，就这个关键点，谈谈我的一些看法。

一、必须进行需求变更管理软件，尤其项目型软件，不修改是不太可能的。

但是，在修改软件时，不能进行就事论事的修改。

否则很容易陷入到某一家客户具体的需求中，而不会考虑其他客户的需求兼容，从而导致修改的软件有很大局限性。

最后形成只能一家维护一套代码，最后客户越多就越累，维护成本也越高，从而由于客户多而拖累死。

软件质量也没法保证。

要想改变这种现状，就必须把需求整理好。

需求变更的出现主要是因为在项目的需求确定阶段，用户与软件项目组往往不能确切地定义自己需要什么。

用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需；软件项目组以为自己清楚，但实际上他们是根据目前已知的有限了解来确定软件的具体需求。

随着开发工作的不断进展，系统功能的开始展现，用户对系统的了解也逐步深入。

于是，他们可能会想到各种新的功能和特色。

特别是在用户已经长期使用过同类产品以后，针对一个新的测试系统，他们提的新要求就更多，需求变更因此不可避免地一次又一次出现。

这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目不断处于更新、待完善状态中。

如果再加上没有一个完善的软件测试与发布系统，软件新的更改的质量就没法得到保证，更会让软件项目组整天处于焦头烂额中，甚至导致整个项目的失败。

当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。

但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。

如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。

针对变更控制流程，通常实施需求变更管理需要遵循如下原则：第一、需求变更要有统一的归口。

所有的需求变更都必须汇总到项目经理或专门负责需求变更管理的人员手中。

第二、把需求分类，做个EXCEL表格，量化解决。

这个需求管理表格会有下列这些项：客户名称、需求提出人、提出日期、功能模块名、客户现在版本号、需求描述、需求分类（需求、BUG）。

需求描述不清晰是反复修改的罪魁祸首。

对于BUG，要有错误报错整个的屏幕截图，千万不要就截那个错误消息框那么一小块。

第三、对需求进行评估。

一个项目中需求调研的充分与否是项目日后成败的关键要素之一。

在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。

即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。

客户想要什么？要这干什么？为什么这么想？会不会有别的想法？通过以上四步我们的目标是：搞清客户的要求，找出要求的逻辑，客户想要的结果，同时排除开发的风险，挖掘与控制潜在的要求，把客户的需求合理化，简单化，说白了就是别搞个逻辑又复杂又不实用的东西出来。

第四、在需求变更评估通过后，在修改需求或BUG的时候，要按照模块来集中修改，而不要挑好改的先改了，不好改的就最后改。

按照模块来集中修改，你会通盘考虑所有这些需求和BUG，而不是糊窗户式的补窟窿。

第五、需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

并妥善保存变更产生的相关文档。

变化并不是人们最害怕的，最怕的是跟不上变化的步伐。

同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，建立一个简单、有效的变更控制流程，按照需求变更管理规则来实施，那么软件开发的进度、成本和质量也就有了“安全”的基础。

二、实施阶段性的目标管理目标管理以制定目标为起点，以目标完成情况的考核为终结。

目标管理通过专门设计的过程，将团队的整体目标逐级分解，转换为各成员的分目标。

同时，目标管理是以目标的实施及完成情况的检查、奖惩为手段。

其中成果考核是评定目标完成程度的标准，也是人事考核和奖评的依据。

目标管理加大了对员工成果绩效的考核力度。

简单点说：可能管理过程是松散的，完成目标的具体过程、途径和方法，项目经理并不过多干预，但目标成果考核是严谨的。

所以，在目标管理制度下，过程监督的成分很少，但控制目标实现的能力却很强。

故能降低软件开发项目的管理成本，使开发项目更易生存。

对于开发项目而言，目标管理的好处是：①目标管理对项目内易于度量和分解的目标会带来良好的绩效。

例如，对于在技术上具有可分性、可量化的工作，由于责任和任务明确，因而常常能起到立竿见影的效果。

②是目标管理有助于改进团队的职责分工。

③通过目标管理，可以明确目标优先次序。

④目标管理启发了自觉，调动了各成员的主动性、积极性、创造性，强调自我控制，自我调节，将个人考核和团队利益紧密联系起来，因而提高了士气。

目标管理可以具备阶段性，并要对目标进行深度分解。

一个终期目标需要由几个阶段性目标组成。

这就好像驾驶飞机，需要把每一次长距离飞行任务，分解成几个航程，在每一个航程预定的结束时间，检查飞机的位置、状态和航向。

只有通过这种方式才能及时发现问题，进而解决问题。

好的软件是做出来的，不是改出来的。

软件必须依靠具有一定水平的开发人员集中精力开发，不可能靠反复的修改来完成。

软件修改次数越多，出错的可能性就越大。

因此，对于一个已经累计了许多变更需求的软件。

实施一个具有阶段性的目标管理，更能将软件做好。

STS8000测试系统的校准软件是由我负责上层软件的开发。

STS8000校准软件最开始的软件需求就是调用各模块的下层校准程序，进行校准，并在上层显示校准结果。

当时只有DVI、PVI、PVM、POW、CBIT几种硬件的校准。

因此，老版本的校准软件是分别调用不同的校准函数校准不同类型的硬件。

同时由于显示的差异性，显示也是分别写函数显示不同格式的校准。

随着时间的推移，硬件开发组研制出更多种类型的硬件，因而校准软件相应地逐渐增加了QTMU、OVI、DVI等多种类型的硬件的校准。

同时，校准时不仅要开放通道的选择，同时还必须开放量程的选择。

在这些不断增加的需求变更面前，通过在原有的校准软件的基础上进行不断的修改，不断的打补丁，只会让软件越来越复杂，条理性也变得更罗嗦、更不清楚。

因此，在总结了众多硬件类型的校准要求的基础，重新开发了新版的校准软件。

新版的校准软件与老版的校准软件相比，其优点有：1、在总结了众多硬件类型的校准要求的基础上，重新规划了校准时的数据结构与判据文件，将许多差异性的东西归纳并在判据文件中给以了描述，从而达到了再新增加一种硬件，不需要修改校准软件的这样一个目标。

即程序的易用性更好。

2、新的校准软件接口统一，因而整个程序的代码更清晰、更有条理，因而也更不容易出错。

另外，落实奖罚是激励成员实现自己所规划的分目标的最好方式。

一般来说，没有人会不受到奖赏和处罚刺激的影响，这种影响所带来的是激励人员全力以赴的工作。

总之，有效的奖罚能使工作更具效率，也更为成功。

总而言之，在复杂多变软件开发项目中，项目经理应该要应用和掌握高效的项目管理方法，而以目标实现为核心的目标管理就是其中一种方法。

三、以测试为核心控制软件开发过程软件系统往往体现一定的功能，这些功能要符合一定的使用目的。

现实世界是在不断变化的，而且变化的速度是越来越快，唯一不变的就是“变化”的主题。

这一现实也就直接影响到了实现实际功能的软件系统，体现在需求、技术实现手段、应用环境等多个方面，这些都直接影响到了软件系统自身的稳定性。

如何让软件系统在不断的改进中依然表现完美，以测试为核心控制软件开发过程，是一不可缺少的环节。

测试的主要任务是控制开发人员随意提交低质量的程序。

例如：在测试中有个定义叫返回，意思是，当开发人员提交了问题过多的程序后，测试人员可以不用告知程序中的问题，直接返回程序要求开发人员重新修改。

这样既控制了被提交程序的质量，也使测试人员把工作重点从寻找简单的低级错误，转移到寻找程序中复杂的逻辑错误。

坚决反对“测试人员是帮助程序人员发现问题的”说法，而应该强调测试人员是站在一个更高的管理控制层面上。

测试可分为黑盒测试、灰盒测试、白盒测试等多种测试。