MIS 系统开发中的项目管理

【本文由PB创新网为您整理】摘要：分析软件开发过程中项目管理的一些问题，探讨软件项目管理中的人员角色及其职责，以及各种关系的处理及解决策略。

     关键词：软件工程；项目管理；角色

   计算机管理信息系统(简称 MIS系统)的开发是一项复杂的系统工程。从 70年代开始，人们逐渐认识到，为了保证 MIS系统开发成功，必须采用工程化的系统开发方法，并研究出一些符合工程化标准的开发方法。这些方法旨在指导开发者进行工程化的系统开发，从而加快 MIS系统开发的速度、保证质量、以及降低开发成本。工程化的系统开发方法确实在开发实践中取得了一定的效果。

    那么，是不是采用了工程化的系统开发方法便一定能保证 MIS系统开发的成功呢？答案是否定的。有许多失败的 MIS系统的例子，其开发也是采用了工程化的方法，或声称采用了这种方法。但结果在投入了大量资金后，系统却不能达到预期的目标，满足不了用户的需求，以致用户方怀疑是否应进行该项目的开发，或者开发所选择的硬件、软件以及开发工具是否得当。究竟问题出在哪里呢？通过对一些失败的 MIS系统的分析，发现问题并没有出在开发方法本身，以及硬软件的选择上，而是出在了开发方法的实施过程中，也就是说主要出在开发项目的管理上。

    任何一种开发方法最终是要由人来实施的，人们在开发工作实施过程中不可避免地要遇到许多项目管理方面的问题，如何正确对待、解决这些问题，直接关系到 MIS系统开发的成败。目前计算机界虽有许多关于 MIS系统开发中项目管理方面的问题的讨论，但大多局限于针对理想开发环境中的理想开发模型的讨论。而实际的开发环境和开发模型却各不相同，它受到各种客观因素的影响，忽略这些因素，或者回避、不解决存在的问题，必将导致开发工作的不完善、甚至于失败。本文就是要通过讨论如何处理实际 MIS系统开发中一些重要因素之间的关系，分析项目管理中存在的矛盾，来揭示其中存在的问题并探讨解决的方案。

１　　什么是 ＭＩＳ 系统开发的项目管理　　

    MIS 系统开发的项目管理是根据管理科学的理论，联系 MIS 系统开发的实际，保证工程化系统开发方法顺利实施的管理实践。它包括 MIS系统开发中的项目评估及可行性分析、人员管理、进度管理及成本控制等方面。

２　　项目开发中的角色及其职责　　

    一个 MIS系统的开发需要用户方与开发方的共同协作。在一个 MIS系统开发中，开发方人员和用户方人员各自扮演着不同的角色。主要角色有：

    用户方的项目管理人员：他是开发项目的组织者，负有开发项目的计划、系统的阶段验收及对系统整体进度的监控、经费的使用、与开发方的项目管理人员工作的协调、用户方的使用人员的组织与培训等职责。

用户方的业务人员：MIS系统需求的提出者，也是 MIS系统的最终用户。他们是对应用系统开发成功与否的最终评判者。

  用户方的决策层：MIS系统开发的最终决策机构，决策层要对 MIS系统开发的项目的上马、经费的预算以及系统所要达到的总目标等作出决策。其决策直接关系到 MIS系统的开发能否成功与顺利实施。

  开发方的项目管理人员：负责项目的计划、开发人员的组织与调度、开发进度的检查、以及与用户方项目管理人员工作的协调。

  开发方的软件编程人员：根据用户方的需求、按照项目的计划及进度进行系统开发。

３　　项目管理中各种问题及各种关系的处理　　

３．１　用户方与开发方的关系　　

  用户方与开发方是对立的统一体，双方均希望将开发项目做好。但用户方可能对计算机系统工程，如工程组织，缺乏全面的了解；而开发方对用户方的需求、细节也可能了解不充分。由此使得用户方与开发方对工程的理解从一开始就存在着差异。而这种认识上的差异与理解的不同往往在开发初期并没有表现出来，当系统开发结束时，双方才发现这种差异使开发出的系统与实际需求偏差甚远。因此，MIS 系统开发项目管理的重要目标便是建立一个便于开发方与用户方之间进行交流的环境。在系统需求分析阶段，开发方与用户方的深入的交流是项目获得成功的关键。但这种交流却经常由于各种双方的误解而难以沟通。

  在需求分析阶段，开发方的分析人员总是先把精力集中在整个系统的总的需求上，而不会对具体细节作过多的考查。当用户方提出一些细节要求时，开发方往往说：“这些问题留待后面讨论”，而糟糕的是以后却可能永远不会再谈及这个问题。当用户方认为已经向开发方提出这些需求时，开发方却根本未予考虑。

因此，开发初期，用户方的项目管理人员应该把这些“留待后面讨论”的需求单独记录整理，在开发方做完系统的整体需求分析后，项目管理人员应及时提出对系统进行进一步的、更深入细致的、具体的需求分析，以解决那些开发方要“留待后面讨论”的问题。

  在某些需求尚未确定时，用户方项目管理人员往往会说：“这部分需求我们还要考虑，不过你们可以先按现在的模式做。”遗憾的是，开发方经常就会把现在的工作模式作为将来的、确定的需求去设计开发系统，而把用户方在此需求上的未确定因素抛在脑后。当后来用户方要求其改变时，开发方便陷入了窘境。因此，用户方管理人员应尽量

[1] [2] [3]  下一页