管理信息系统最早发端于上世纪五十年代，来自美国国家电器的薪金计算系统可以说是开启了企业信息化管理的先河。初代的信息管理系统更多体现在简单的数据处理，而现在已经发展到商务应用，并由财务处理升级发展至ERP系统，物料管理升级至供应链管理系统等。发展至今，管理信息系统无论是从外延还是自身的内容都得到了极大的发展，对于企业的办事效率起到良好的促进作用，甚至在某些程度上还能够展现出企业自身的核心竞争力。不过以辩证唯物主义观点来看，任何事物都会起两面性，所以信息管理系统也有一些运用上的困难，比如管理和维护就是其重要的难题。因为在信息时代，企业的内外因素的改变会越来越快，这就让信息系统和企业的发展形成一致的对应关系就变得极为困难。于是信息系统的需求变更问题就开始被不断提出，同时这个课题也开始成为当前需求管理的重要的研究热点。同时也是信息系统开发的重要环节。需求变更的日益频繁必然会让信息系统的开发面临巨大的风险和挑战。
1需求变更的基本概念分析
软件需求从本质上来说就是为了消除用户提出的问题而需要让软件达到的功能，因此这个阶段就成了软件开发时最为重要的输入。然而软件需求具有变化性以及不明确性以及模糊性和主观性等特性，所以这个阶段又是在软件开发过程中最难管控的环节，然而这个环节对于整个软件的开发成败却具有决定性的影响，正是如此，需求变更的管理就显得极为重要。就我们公司从事了近十年的铁路列车到发信息系统来说，由于用户（各类铁路车站）在发展过程中面临各种各样的不确定性，那么这类车站的需求就会出现变化频繁的问题，而这种频繁的需求变更必然会给整个项目的开发带来巨大的风险和挑战，比如导致信息系统开发的成本规模不断增长，开发周期将会不断延长，而且信息系统的稳定性和可靠性等也会受到负面影响。因此需求的频繁变更又成了信息系统不稳定的重要潜在因素。当前需求变更的概念主要是，在需求分析的相邻子阶段里，或者在迭代开发过程中能够，两次相邻迭代周期的需求分析结果存在着显著的不一致性。于是就出现了信息系统的变更。
2需求变更对企业信息系统开发的影响分析
在软件开发过程中，需求变更难以规避，而且需求变更愈加频繁，必然会导致质量下降，成本上升。而且变更如果出现在开发的后期，还会进一步增加软件开发的风险。如果需求变更在软件开发的前期，那么此时只需要修改设计即可。而变更产生在编码或者测试阶段，那么需要对设计和编码加以修改，然后再进行重新测试。如果在后期的维护以及实施阶段，就需要重新进行设计和编码工作。通常在软件开发的整个过程中，需求变更都会随时发生，而在不同的阶段，所产生的影响也会存在着区别。其中发生的越早，那么风险越小，解决的可能性就会越高。其主要产生的影响主要体现在以下几点：第一，影响软件质量和开发周期。软件开发和需求产生显著关系，而且和相关性的需求还会形成需求链。如果在设计开发阶段会遗漏某些需求，那么可能在实施变更过程中就会导致一些难以发现的错误，进而导致系统的稳定性下降，甚至容易爆发宕机问题。第二，文档和代码的一致性会受到负面影响。在软件开发领域，文档同样是其重要的构成，同时也是后期维护的重要凭据。在处理需求变更时，如果没有应用规范的流程来对需求变更进行评估和实施，那么就会导致文档和最终的软件具有不对应的关系，进而影响到后期的维护。第三，对开发者以及用户的和谐造成负面影响。需求变更的实施必然需要开发单位和用户之间的相互协作，但是正是这种需求变更的出现，往往会导致双方意见的差异，假设不能够得到正确处理，那这种合作关系就会受到负面影响，最终还会对软件的开发进程产生负面影响。
3需求变更出现的根本原因分析
需求变更的产生主要有内外两种因素，其中内部因素是控制焦点。而对于外部因素而言，项目团队的控制就相对较难。
3.1外部变更因素
这主要体现在以下几点：第一，技术发展快，运用新的技术来进行系统开发，此种变更在消除用户所提出的最初问题之前，很可能发生。第二，因为外部经济环境的改变，铁路行业政策法规的不断改变，铁路车站不断提升扩建，更好地满足旅客和货主的需求，铁路车站会不断产生这种变更需求。第三，对于铁路车站而言，由于最初提供软件需求的人员调动频繁，而代替这个职务的新人往往会产生自己的新观点，从而引起需求变更。
3.2需求变更的内部因素
这一点主要体现在以下几点：第一，需求收集前期，由于和车站用户交流不够充分，对系统的功能需求了解不够，从而导致后期的需求变更，因此只需要前期能够充分沟通，加强理解，这种变更教会减少甚至规避。第二，用户对于自己的需求不能够准确描述，没有相关的经验，并不知道这个系统能够产生什么样的功能，也不了解这些需求需要使用什么技术实现。只是随着软件的开发，当系统有了初步结果时，此时用户的了解会变得深入，接着就会凭借着自身的了解来提出新的功能，或者对之前的需求提出一些改动。而且随着用户了解的越来越深入，这种需求的变更就会变得越来越频繁。而对于开发团队而言，只是希望在进入开发之后，就需要完成需求的全封闭。可是大部分情况，用户并不能够在需求设计阶段就能够完全的了解自己最终需要什么的产品，不过此时的用户往往自认为清楚，而提出的需求大多是为了满足当前工作需要。在需求变更被封闭之后，随着需求变更的不断增多和堆积，必然会对软件开发产生巨大的压力，最终导致的结果就是重新返工。第三，由于最初的需求范围没有明确就开始细化。通常细化工作是由需求分析工作人员完成，主要依据用户的描述性语言，或者总结语进行细化。提取这些描述中涉及的功能，然后给出程序语言的描述。当这些细化工作进入到一定阶段之后，此时涉及范围却发生改变，那么用于描述用例的细节也会随之发生改变。比如之前需要手工录入数据，后来需要改成通过系统进行计算自动录入。除了上述的基本内部因素之外，还包括软件架构自身的适应能力较低，也是导致需求变更的重要内部因素。
4工程变更管控实现的设计
在开发铁路列车到发信息系统时，根据车站不断变化的需求，我们也完善了工程变更管理的内部流程，针对变更管理和控制的实现步骤分别设置为申请、批准、操作以及审核以及变更执行。
4.1工程变更申请
想要实现变更，首先要进行申请单的填写。申请主体通常为用户或者是来自本公司的不同部门，如研发部门、采购、财务等。在进行申请时，需要详细的填写申请内容，然后对需要变更的内容当前所实施的情况加以说明，进行变更之后的影响同样加以披露，这样才能够为决策者的最终决定提供依据。另外还需要对产品图号构建变更申请标志，于是工程变更申请完成。
4.2工程变更批准
批准环节主要是由公司分管领导或者该车站铁路列车到发信息系统研发负责人进行管理，如果涉及变更项目较大，那还需要企业的高层领导进行批准。在进行批准时，需要对申请单加以分析，获得具体的变更目标，然后根据需求了解变更申请原因，以及当前需要变更项目的具体进展以及这个变更后的影响，从而保障自身决策的准确性。
4.3工程变更操作
当变更被批准之后，就需要开放相应的权限，实现相应的变更操作。此时需要设计人员对更改的内容加以设计，也就是要对图纸进行修改。工程变更所反映到的设计图纸的改动大多集中在明细表内容的修改上。这些设计内容的修改主要集中在对应的图号、序号以及编号组织等方面的修改。其中序号项涉及改动结果包括新增、品质修改以及删除和数量修改等层面。也就是对旧代码的删除，新代码的添加。构建变更历史库，要对具体的变更内容进行记录，实现对这些历史记录的保存。同时还需要构建变更数据库，对相应的变更内容进行保存。通过历史库和变更库就能够完成工程变工数据的全部记录。而这两个数据库的内容来源主要是通过录入，或者当变更的设计图纸完成之后，系统通过自动对比前后图纸得到变化实现对变更库内容的自动更新。
4.4工程变更审核
在变更工作之后，还需要相关的人员进行审核。此时需要对变更结果加以汇总，如果不存在影响的变更则纳入汇总数据中，然后由审核人员根据变更单进行审核。审核结果如果不通过，需要发回至相关流程，使之进行修改。如果审核通过，那么就需要自动产生新的工程，然后根据这个新的清单，以及之前的变更历史库以及工程变更库，自动产生相应的变更内容，如采购变更或者生产变更等，然后由后续工作来执行相应的变更。另外这些变更内容还需要存储至历史数据库以及工程变更数据库，当然也能够当成外部文件进行输出。
4.5工程变更后执行处理
在审核环节之后，变更内容及通知单需要及时的发送至相关部门，然后进行变更后的执行处理。如果工程变更产生了相应的变更，比如采购或者生产变更等，那么就需要进行清单变更描述。当这些变更影响到其他部门工作时，就需要加以控制处理。比如某个物流部，因为工程变更致使采购和外协加工工作产生影响，那么就可以通过采购清单变更加以反映。而这个采购清单变更则会受到工程清单变更的影响。于是就需要对工程清单变化状态加以分析，并结合相应的采购执行结果来进行采购清单的修改。在我公司近十年的铁路列车到发信息系统不断提升研发和应用过程中，最大的体会与挑战就是加强工程变更的管理。变更管理的有效实施，也是提升产品开发效率，降低产品研发成本的重要基础。本文对铁路列车到发信息系统的工程变更要求进行了分析，并提出了对应的解决方法，结合我公司在铁路列车到发信息系统的实践来分析了工程变更的设计和实现。
作者：徐齐正 单位：浙江铁道科技实业有限公司
相关专题：商标查询 中小企业存货管理论文
