苏ICP备112451047180号-6
管理要求改变非正式的方式
管理要求改变非正式的方式：当说“不”不是选项
摘要 - 软件一直被认为是可塑的。 软件需求的变化在开发过程中是不可避免的。 尽管数十年来软件工程的进步很多，但需求变化是项目风险的来源，特别是当企业和技术发展迅速时。 虽然有效地管理需求变化是软件工程的一个重要方面，但文献中需求变化的概念和实践中的管理方法仍然似乎是基本的。
本研究的总体目标是更好地了解需求变更管理的过程。 我们从全球分布式环境中的需求变更管理的探索性案例研究中得出结论。 在这种情况下，我们注意到与传统的需求变化模型的对比。 理论上，变更控制政策和正式流程被认为是应对需求变化的自然策略。 然而，我们观察到“非正式需求变化”（InfRc）是普遍的和不可避免的。 我们的结果揭示了并行处理InfRc所需的同样“自然”的非正式变更管理流程。 我们提出一个新的需求变化模型，我们认为，更好地代表现象，更现实地将非正式和正式的变化类型结合起来。
关键词：非正式需求变化，范围变化，需求管理，需求变更管理
一，引言
窗体顶端
需求变化是当代软件开发中公认和接受的现象。 事实上，变革是欢迎和接受敏捷开发方法，作为增加价值和提高可用性的手段。 另一方面，不受控制的变更可能会对软件的成本和质量构成风险[1,2]，并通过错过的期限，预算超支和资源浪费来伤害组织[3]。
窗体顶端
由于内部和外部因素的组合触发变化，需求发展[1]。影响发展进程的一些不可避免的变化仍然是可管理的，因为它们是由客户发起的，外部的重点和评估的影响。因此，将这些变化的影响传达给客户是比较直接的，建立变更控制政策或对他们的保护是可能的[4,5]。在这项研究中，我们观察到另一类需求变化，我们称之为非正式要求变更（InfRC）。 InfRC更加内部关注，可能会颠覆开发过程，因此更难管理。我们将这些变革定义为绕过正式变更管理流程（例如正式审查和变更影响分析）所实施的大部分控制的变更，并在所得到的系统中实现。
有几个因素有助于Infra在软件开发项目中的表现。有时它们是由于过早的RE活动[6]而导致的，或者在项目中比平时更早地要求“冻结”，因此“潜在”，但需要改变[5]。在其他情况下，由于臭鼬工程（管理人员隐藏的工作，通过做出特定决策而绕过耗时的手续[7]），需求（需求增加和变更的不断涌入）[8] 9]，或爬行优雅[10]（添加在没有考虑延迟的时间表和项目成本[11]）。 InfrC也可能是由于未能创建一个实际过程来帮助管理变更[12]。
我们认为，尽管许多项目仍然使用以计划为导向的RCM流程，但出于好的原因，但他们似乎缺乏对识别和管理InfRC的充分支持。因此，本研究的总体目标是通过案例研究来探讨InfRC的概念。我们的目标是增加我们对这一复杂现象的理解，发现其来源，适应这些现象的原因以及以非正式方式处理这种变化的影响。我们研究的研究问题是：
RQ1。要求的非正式变更的来源是什么？
RQ2。在实践中如何处理非正式变更？
RQ3。管理需求变化的影响是非正式的？
窗体底端
除了介绍我们在软件开发项目中管理InfRC的探索性案例研究的结果，本文还为InfRC提出了一个更现实的变革管理流程模型。 据我们所知，这是第一个已知的模型，捕获正式和非正式的活动来管理需求。
本文组织如下：
第二部分简要介绍了需求的不可预测性质，并提出了对需求变更管理的经典观点。
第三节描述了本案例研究中使用的研究方法。
第四部分介绍了采用供应商观点的案例研究的研究情况和概况。
第五部分强调了调查结果，并介绍了本研究所提出的需求变化模型，讨论了InfRC的来源，非正式适应变化的原因及其影响。
第六部分反映了InfRC在现有的RCM模型中是不可避免的现象和对InfRC的监督。
本研究的局限性在下面的第七部分中讨论，
其次是第八部分研究结果的含义。
第九节简要总结了本文。
II。背景
商业定制项目继续面临从引出到交付的需求转变，甚至超越[1]。这个现实打破了管理层对项目进行叠加的僵化和不正当的正式变更管制政策，使其受到控制。
开发软件的现实是其天生的可塑性和新兴（有时是任意）的要求性质。软件解决方案的初步构想是通过动态人工制品探索项目进行演绎，阐明了对现实的初步认识[13]。同样具有不同观点和优先次序的利益相关者以不同的方式表达其要求，导致模糊和不一致[14]。通常需要做出改变来解决它们。其中一些更改由正式进程处理，而其他更改则遵循不同的（有时是非正式的）路径。
文献中发现的传统RCM过程模型旨在根据正式的变更控制政策来处理需求变化[5,9,15-17]。这些模型的驱动因素似乎既是商业的，也是项目管理关注控制成本和范围的问题。几乎所有模型中的基本假设是，只有当需求是基础的时候才会发生变化，因此只能正确地处理变更。然而，实际上，变更请求者与实施者之间的关系以及变革的紧迫性或重要性可能不允许改变始终遵循正式的实施途径[17,18]。例如，原型可以由客户和开发人员非正式地“共同入侵”。当客户或其代表轻松访问开发团队时，他们经常要求添加要求，而无需进行正式的更改审核过程[10]。
在这种情况下，客户通常会直接与开发人员接触，以便在系统中实现所需的更改。类似地，开发人员可以（非正式地）通过“镀金”将自己选择的功能添加到软件中[19]。因此，对于项目经理来说，要求可能会变得不稳定[10]。现有的需求管理流程模型不承认或处理这种非正式变更。在传统的变更管理方法下，有效管理范围蠕变的规定措施包括：单一通道用防火墙处理变更，防止不必要的变化[5]，基础要求[9]以及检查，成本核算和批准变更。然而，这些方法都不是专门设计来处理如前所述的需求的非正式变化。
我们已经确定了需求的非正式变化是不可避免的和无处不在的背景。正式的变革过程可能会出现一种“自然”的策略，以正式的方式应对需求的变化。然而，我们的研究表明，也有同样的“自然”和平行的过程，通过这些过程处理非正式的变化。
III。 研究方法
为了回答我们的研究问题，我们在美国和巴基斯坦的三个地理位置分布的客户和供应商网站上进行了一个软件开发项目的案例研究。 应用探索性案例研究方法[16]，以更深入地了解需求变化现象，我们认为这是软件工程中的一个不理论的领域。 数据主要来自半结构化访谈，观察需求管理流程和检查变更相关文物（例如，RM流程文档，需求变更日志和问题跟踪系统）。
A.访谈
第一作者前往巴基斯坦，对供应商方面的关键项目利益相关者进行访谈。在本案例研究中进行了大约45分钟的十七次半结构化访谈。受访者角色包括开发经理，两名团队领导，两名开发人员和质量保证经理。为了覆盖客户的角度，公司的CEO被采访了谁也是代理客户。
采访由高层次的问题引导，如：“实施和管理需求变化的做法是什么”，“从业人员管理要求面临的挑战是什么？”。这些采访的目标是了解变革管理实践并确定重大挑战。然而，在这项研究过程中，确定了一个非正式的变革管理过程，这个过程随后进行了探讨。采访记录完整录入并进行转录，供进一步分析。数据收集过程跨越10个月（2013年2月至2014年1月）。
主题内容分析（TCA）技术[20]应用于分析从半结构化访谈收集的定性数据。在分析过程中，数据的组织，合成，评估，解释和分类，以便查看模式，识别主题和发现关系[21]。
管理需求变化的挑战，导致这些挑战的主要因素及其影响被纳入专题分析中的适当类别。与实际做法有关的其他紧急主题，包括InfRC也被确定并进一步探讨。第一作者进行的TCA研究结果由其他两位合着者进行了审查和确认。
研究的意义
在这项研究中，代理客户端的角色似乎产生了大量的InfRC，无论是特定于这种情况还是代理客户端跨越角色的更为普遍的缺陷将成为研究的成果之一。
此外，更好地了解InfRC及其在其他领域软件开发项目中的适用性需要进一步调查。我们认为敏捷方法主要通过优先考虑机制和时间拳击来处理Infra，但我们认为Infra仍然在敏捷项目中面临挑战，并且要进行更密切的调查。
[33]所述的这项研究的市场驱动的软件方面突出显示了驱动InfRC的挑战。有必要在与感知的用户需求相对应的需求与可能通过突破性技术提供竞争优势的新的，发明的需求之间找到良好的权衡。在技术驱动和需求驱动的需求之间找到良好的平衡可能是一个微妙的挑战。研究市场驱动的软件开发方法和Infra的管理可以帮助应对这些挑战。
更一般来说，需求变化似乎是一个现象都在理论上，在实践中构成挑战。在本研究中开发的精细理解可以导致更深入的研究，重点是开发更广泛的软件变更理论，可能类似于组织环境中提出的[35]。
IX。结论
在本文中，我们提出了非正式需求变化的现象。我们为正式的变革管理和InfRC提出了一个新颖的流程模型，从供应商的角度，借鉴了采购和软件开发环境。在这种情况下，InfRC代表了一个报告不一的管理项目层面的隐藏工作，需要适当的缓冲区来适应开发项目中的这些活动。非正式需求与需求变更管理的经典观点相反，这涉及到高度正式化和严格的变更流程。此外，在面向变革的敏捷开发环境中，我们认为，InfRC是一个未被研究的现象（更不用说全面的需求变化概念）。
我们认为，InfRC是软件开发的特有之处，并且对开发团队施加压力。因此，有必要进一步研究，更好地了解这一现象，制定适合的实践指导方针。我们还需要认识到，非正式需求变化是一个必要和有用的目的，而不是仅仅是发展实践不佳和项目管理薄弱的产物。因此，我们需要制定战略和做法，以适应其在实践中的流行。