如何应对软件开发中的需求变更

如何应对软件开发中的需求变更

【摘要】在软件项目开发的过程中，软件的需求变更是一个回避不了的问题，它的处理的好坏，更是决定软件开发项目是否能够顺利、完美、高效率得到实现的关键。本文针对STS8000测试系统在软件项目开发过程中出现的常见问题，探讨了如何应用项目需求变更管理、项目目标管理、版本更新管理与软件测试管理，从而帮助并促进软件开发人员开发出更加完美、高效、稳定、有质量的软件产品。

【关键词】需求变更管理；软件项目目标管理；版本更新管理；软件测试管理

随着软件系统的规模、复杂度日益上升，软件开发过程中的各种质量管理已经成为保证软件系统开发效率、质量、成本的关键性因素。软件行业在现在的众多行业里是一个极具挑战性和创造性的行业，体现了软件开发者的智慧和汗水，同时软件开发是一项复杂的系统工程，牵涉到许多方面的因素，在实际工作中，经常会出现各种各样的问题。如何总结、分析并解决软件开发过程中各种问题，对于项目开发人员与管理人员来说，是在今后的项目中取得成功的关键。

目前，STS8000系统在软件方面出现的问题主要有下面几方面：

1、客户不断提出新的需求。软件开发人员不断地陷于满足用户需求的过程中。似

乎，我们在需求上无能为力，我们永远在追赶客户的需求，满足他们的现状，

把N多家的客户需求都加进软件中，只要能实现的，我们尽量咬牙实现了。最

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

的。因为无比复杂，所以稳定性更成了问题。代码互相交叉，根本无法理清有

多少交叉影响点。

2、改正了旧问题，又冒出更多新问题，问题层出不穷；维护的工程师都快崩溃了，

天天在祈求，千万别接到客户电话。对于修改现有代码适应新客户新项目，这

种情况出现的非常多。客户打电话说了一个需求，能技术达到就答应下来修改，

修改完就给客户覆盖，根本没有需求变更管理、版本更新管理。而这样的代码，

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

这个客户好使，那个客户使用其他功能的时候就出了错。按下葫芦起了瓢，是

很常见的现象。

3、由于长期陷于满足用户需求的过程中，天长日久，软件工程师就会木然、倦怠，

会形成做一天和尚撞一天钟。有问题就打补丁，客户不嚷嚷就懒的修改，代码

不优化、不封装，界面不友好，架构更是没架构。模块难度、工期质量考核无

法量化，更无法与个人收入挂钩。

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

一、必须进行需求变更管理

软件，尤其项目型软件，不修改是不太可能的。但是，在修改软件时，不能进行就事论事的修改。否则很容易陷入到某一家客户具体的需求中，而不会考虑其他客户的需求兼容，

从而导致修改的软件有很大局限性。最后形成只能一家维护一套代码，最后客户越多就越累，维护成本也越高，从而由于客户多而拖累死。软件质量也没法保证。要想改变这种现状，就必须把需求整理好。

需求变更的出现主要是因为在项目的需求确定阶段，用户与软件项目组往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需；软件项目组以为自己清楚，但实际上他们是根据目前已知的有限了解来确定软件的具体需求。随着开发工作的不断进展，系统功能的开始展现，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色。特别是在用户已经长期使用过同类产品以后，针对一个新的测试系统，他们提的新要求就更多，需求变更因此不可避免地一次又一次出现。

这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目不断处于更新、待完善状态中。如果再加上没有一个完善的软件测试与发布系统，软件新的更改的质量就没法得到保证，更会让软件项目组整天处于焦头烂额中，甚至导致整个项目的失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。针对变更控制流程，通常实施需求变更管理需要遵循如下原则：

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

第二、把需求分类，做个EXCEL表格，量化解决。这个需求管理表格会有下列这些项：客户名称、需求提出人、提出日期、功能模块名、客户现在版本号、需求描述、需求分类（需求、BUG）。需求描述不清晰是反复修改的罪魁祸首。对于BUG，要有

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

第三、对需求进行评估。一个项目中需求调研的充分与否是项目日后成败的关键要素之一。

在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。

客户想要什么？要这干什么？为什么这么想？会不会有别的想法？

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

第四、在需求变更评估通过后，在修改需求或BUG的时候，要按照模块来集中修改，而不要挑好改的先改了，不好改的就最后改。按照模块来集中修改，你会通盘考虑所有这些需求和BUG，而不是糊窗户式的补窟窿。

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

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

二、实施阶段性的目标管理

目标管理以制定目标为起点，以目标完成情况的考核为终结。目标管理通过专门设计的过程，将团队的整体目标逐级分解，转换为各成员的分目标。同时，目标管理是以目标的实施及完成情况的检查、奖惩为手段。其中成果考核是评定目标完成程度的标准，也是人事考核和奖评的依据。目标管理加大了对员工成果绩效的考核力度。简单点说：可能管理过程是松散的，完成目标的具体过程、途径和方法，项目经理并不过多干预，但目标成果考核是严谨的。所以，在目标管理制度下，过程监督的成分很少，但控制目标实现的能力却很强。故能降低软件开发项目的管理成本，使开发项目更易生存。

对于开发项目而言，目标管理的好处是：①目标管理对项目内易于度量和分解的目标会带来良好的绩效。例如，对于在技术上具有可分性、可量化的工作，由于责任和任务明确，因而常常能起到立竿见影的效果。②是目标管理有助于改进团队的职责分工。③通过目标管理，可以明确目标优先次序。④目标管理启发了自觉，调动了各成员的主动性、积极性、创造性，强调自我控制，自我调节，将个人考核和团队利益紧密联系起来，因而提高了士气。

目标管理可以具备阶段性，并要对目标进行深度分解。一个终期目标需要由几个阶段性目标组成。这就好像驾驶飞机，需要把每一次长距离飞行任务，分解成几个航程，在每一个航程预定的结束时间，检查飞机的位置、状态和航向。只有通过这种方式才能及时发现问题，进而解决问题。

好的软件是做出来的，不是改出来的。软件必须依靠具有一定水平的开发人员集中精力开发，不可能靠反复的修改来完成。软件修改次数越多，出错的可能性就越大。因此，对于一个已经累计了许多变更需求的软件。实施一个具有阶段性的目标管理，更能将软件做好。

STS8000测试系统的校准软件是由我负责上层软件的开发。STS8000校准软件最开始的软件需求就是调用各模块的下层校准程序，进行校准，并在上层显示校准结果。当时只有DVI、PVI、PVM、POW、CBIT几种硬件的校准。因此，老版本的校准软件是分别调用不同的校准函数校准不同类型的硬件。同时由于显示的差异性，显示也是分别写函数显示不同格式的校准。

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

了QTMU、OVI、DVI等多种类型的硬件的校准。同时，校准时不仅要开放通道的选择，同时还必须开放量程的选择。在这些不断增加的需求变更面前，通过在原有的校准软件的基础上进行不断的修改，不断的打补丁，只会让软件越来越复杂，条理性也变得更罗嗦、更不清楚。因此，在总结了众多硬件类型的校准要求的基础，重新开发了新版的校准软件。新版的校准软件与老版的校准软件相比，其优点有：

1、在总结了众多硬件类型的校准要求的基础上，重新规划了校准时的数据结构与

判据文件，将许多差异性的东西归纳并在判据文件中给以了描述，从而达到了

再新增加一种硬件，不需要修改校准软件的这样一个目标。即程序的易用性更

好。

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

容易出错。

另外，落实奖罚是激励成员实现自己所规划的分目标的最好方式。一般来说，没有人会不受到奖赏和处罚刺激的影响，这种影响所带来的是激励人员全力以赴的工作。总之，有效的奖罚能使工作更具效率，也更为成功。

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

三、以测试为核心控制软件开发过程

软件系统往往体现一定的功能，这些功能要符合一定的使用目的。现实世界是在不断变化的，而且变化的速度是越来越快，唯一不变的就是“变化”的主题。这一现实也就直接影响到了实现实际功能的软件系统，体现在需求、技术实现手段、应用环境等多个方面，这些都直接影响到了软件系统自身的稳定性。如何让软件系统在不断的改进中依然表现完美，以测试为核心控制软件开发过程，是一不可缺少的环节。

测试的主要任务是控制开发人员随意提交低质量的程序。例如：在测试中有个定义叫返回，意思是，当开发人员提交了问题过多的程序后，测试人员可以不用告知程序中的问题，直接返回程序要求开发人员重新修改。这样既控制了被提交程序的质量，也使测试人员把工作重点从寻找简单的低级错误，转移到寻找程序中复杂的逻辑错误。坚决反对“测试人员是帮助程序人员发现问题的”说法，而应该强调测试人员是站在一个更高的管理控制层面上。

测试可分为黑盒测试、灰盒测试、白盒测试等多种测试。通常用的最多的就是黑盒测试。

黑盒测试检验是否符合系统需求，也称功能测试或数据驱动测试。它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

最后给一个与测试相关的建议：重视设计复查和代码复查。

很多程序员习惯于这样一种工作方式:只做不想。他们更关心每天可以写多少行代码,完成几个模块。在这种态度下,他们都很不愿意复查自己的工作,而习惯于在软件测试阶段把隐藏的错误改正过来。但设计复查和代码复查在大型的软件项目中已经有30年的应用历史,而且已经被证明在设计和代码编写阶段的复查比软件测试更能有效的消除错误,一些经验数据表明,在设计和代码复查时发现的错误是在同等工作量下软件测试发现的错误的两倍。

四、建立一个完善的、快捷的版本更新机制

在项目的维护期，就涉及到版本更新的问题。尤其是有些行业客户，需要你在实施过程中就修改需求定制化软件，非要按照他们的习惯做才肯用，自然更新版本不断。

而客户端一多，自然更新一次就非常累。而且哪个更新了哪个忘了更新，更新的版本一致不一致，都会引起各种问题。所以，为了更新，咱们可以直接在软件中集成同步更新功能。客户端软件一启动的时候，先自动监测服务器上的版本一致不一致？如果不一致，就自动更新同步服务器上的软件文件。这样可以达到下面的目标：有的客户还没有发现那个BUG的时候，就已经被我们更新了。从而提高用户的满意度。

结束语

所有的管理方法，实施起来最终只有一个目的：做出好软件。

参考文献

[1]贾慧《软件开发项目需求变更管理及应对之道》

[2]《如何走出软件作坊成为开发正规军》