大型信息系统工程建设经验总结

大型信息系统工程建设经验总结

一、工程前期工作

1． 关于用户调研

用户调研的目的是收集需求；

用户调研的方法是直接面对面与用户交流，最好能亲身体验用户工作开展的过程，注重了解工作的细节。

用户调研的结束标志是完成了需求分析设计文档，并且得到用户的认可。在工程前期开展好用户调研对于工程的顺利进行和完成非常重要。

用户调研的人员应当集中、固定，具有多方面的经验，如：客户交流经验、程序设计经验、系统分析经验等，但调研人员数量不能太多，并能对重大问题进行独立决策。一般用户调研人员3人左右即可。

2． 关于需求分析

需求分析的目的是明确用户需要实现的内容。

可以采取多样的需求分析方法和技术，但是根本上必须描述清楚用户的业务工作、软件需求。可以有很多的需求分析的标准和规范可以采用，也可以自己根据实际情况制定需求分析的规范。

需求分析的人员可与调研人员重合，但要增加软件分析人员，并为调研人员提出调研的内容和方向。

需求分析结束的标志是程序员能够开始进行程序设计，并和建立系统原型的工作结合起来进行，因此只有程序员才能评判需求调研的质量。

关于需求分析阶段投入的时间一定不能少于全部工程时间的30%，当然40%会更好，否则很难保证需求分析的深度和质量。

需求分析阶段至少建立三类组织：调研组、需求分析组、原型开发组（可分成多个小组），统一由项目经理负责。

3． 关于建立系统原型

建立系统原型是完成需求分析的补充手段，目的是明确和确定用户需求，引导用户提出更具体的内容。

建立系统原型要求使用适当的工具和容易的软件环境，满足快速开发的要求。

系统原型一般不作为将来软件系统实现的基础，因为此时的原型系统只考虑反映用户需求的情况，缺乏统一的考虑因此最好在设计、实现阶段重新开始。

避免使用户产生" 软件开发已经开始，并会很快完成" 的观点，一定要明确此时软件还在前期的分析阶段，距离设计、实现还有很长的距离。

4． 关于建立总体实施方案

建立系统的总体实施方案是必须的，目的是使甲乙双方共同认可工程的实施计划，保持一定的耐心和总体意识。

总体实施方案应在需求分析基本完成的基础上开始。

总体实施方案应说明：任务量、计划进度、资金、实施阶段、各阶段结束的标志和开始的条件、完成时提交的内容。

总体建设方案应在项目经理、甲方负责人、乙方负责人共同认可的情况下，投入实施指导，否则要继续调整，此时项目经理一定要做好乙方负责人的工作，争取更多的时间（应

为从乙方负责人的角度希望项目能够尽快的结束。）

一旦总体实施方案确定，就必须按照实施方案的阶段安排逐步开展工作，并进行量化和考核，如果某一个阶段没有完成，则必须对照检讨，采取措施。否则将造成项目实施组织的混乱，因为大家无法再按照一致的实施方案开展工作了，为工程项目的顺利开展提出了警告。

5． 关于建立组织机构、制度

一定要明确组织机构是必不可少的，不要回避和搁置这个问题。

只有建立了工程组织机构和管理制度，才具备完成项目的基础，因为工作的完成归根结底是人的协作。

由于大型项目需要的人员比较多，因此没有完善的组织机构和制度是无法协调好各个部分的工作的。

组织机构的建立应在项目开始需求调研的时候就开始着手建立，在众多制度中" 个人激励制度" 是影响最大的一个制度。

二、软件系统实现

1． 系统设计

a ． 关于系统的体系结构

系统体系结构的确定是为软件需求服务的。没有必要为了结构而结构。在不同情况下采取不同的体系结构是明智的。体系结构的确定受到软件用户数量、运行环境、更新维护要求、软件分布等外部因素的影响。

b ． 关于各种分析方法

目前有很多系统设计的方法，选择某一方法（OMT 、UML 、OO ）要根据系统的特点来确定。针对信息系统而言，可以自己制定合适的分析设计方法，因为目前虽然有很多的方法，但不太适合信息系统建设的要求。在信息系统设计的时候要灵活应用各种分析方法，照搬哪一种方法都不太合适。（至少在现阶段信息系统开发水平下）

c ． 关于文档

在实际工作中的体会是：文档很重要，但是经常和编程工作产生矛盾，不能得到及时的更新。为此在项目进行过程中，需要确定当前工程文档的各种标准，以及工程需要哪几类文档，文档提交和发布的时机等内容。这些文档包括：工作规范、分析设计文档、工作计划文档、日志文档、任务分配考核文档等。

d ． 关于软件设计水平的定位

在软件工程开发工程中，不是采取越多新技术越好，软件的设计也不要走入" 尽量提高水平" 的误区。由于负责软件设计的技术人员客观上具有追求完美的特点，主观上尽力想将系统设计的完美，因此会造成软件实现需要的工作量增大，同时用户又不一定接受这些内容。在考虑软件水平的时候，主要考虑：新技术的采用和成熟技术的采用要成比例。 e ． 考虑到系统用户的特点了吗

系统的设计起主导作用之一的因素是用户的特点。不论什么特点的用户都采用一致的设计思路、风格、特点不是太好的选择。脱离对用户实际情况的考虑的设计太学术化。并且在设计的时候要照顾到系统的可维护性、易用性、实现的容易性等问题。

原则之一是：能简化设计就简化，降低设计的复杂度。不要采用太复杂的设计。因为，这样的设计不便于理解、和维护。

2． 程序质量

程序质量是项目全方位的体现，包括管理水平、程序员的工作状况、相应的标准规范、文档的考核、个人激励制度等等所有的因素，这里仅就狭义的范围，讨论一下程序质量。 a ． 关于标准规范的制定

多人协作编写一个工程项目的工作的确具有挑战性，要完成好项目工作，没有 统一的标准规范是不可能的。标准规范是位程序设计服务的，因此要尽量消化，不要模糊照搬，那样不会有帮助。关于程序设计要制定的规范包括：如何注释、注释量、变量命名规范、函数程序命名规范等，并针对这些规范的要求详细考核每个程序的设计情况。

b ． 关于编码质量控制

编码质量包括：正确、易读、易维护。正确取决于设计文档和程序员的水平，并且可以通过控制编码的易读和易维护来报我编码的正确性。并且编码的质量控制需要量化指标和规范。

c ． 关于版本的控制

在大型信息系统开发工程中，采用适当的版本控制工具对程序代码进行控制是非常必要的。

d ． 关于文档管理

文档的管理主要是更新、维护，并且要持之以恒，坚持到底。在程序设计的过程中以一定的粒度要求，在不同阶段要完成不同阶段的文档，这样才能以文档作为协同工作的基础。这点对于大型信息系统的开发非常重要。

e ． 编程时间投入到什么阶段

这里需要说明的是编程的工作在需求分析阶段、程序实现阶段、系统运行维护阶段等都要有时间的投入，认识到这一点的意义在于：为了保证每个阶段的编程时间投入的最经济，就要控制好程序的质量。假设程序设计阶段代码很潦草，那么在运行维护阶段就要受到惩罚。

f ． 关于用户界面

纵观众多得到用户认可的信息系统界面的共同特点是简洁，从而易学易用。如果组织的过于复杂的用户界面，比如Office Word的多层次的菜单界面虽然是非常不错的界面风格，但是对于众多计算机水平一般的用户而言就过于复杂，而对于计算机应用水平比较高的用户而言则容易掌握。所以在系统实现的过程中，要不断的与用户交流，确定用户喜欢的界面风格。

3． 组织管理

除了技术本身之外，另一个影响项目进展和质量的重要因素是组织管理水平。这里有两个问题：组织水平和管理水平。一般" 组织" 、" 管理" 总是放在一起使用，实际上组织是管理发挥作用的基础。哪怕一个人总负责，那么这也是一群人组成的组织，也要有组织制度。所以，在实施过程中，建立组织、制度，提高管理水平不仅是信息系统工程建设需要考虑的问题。

就管理的客体而言，无非是人、财、物，并通过合理搭配完成一定的生产任务。就这些问题有很多需要研究的内容。对人的管理包括：建立组织、建立制度、明确责任、权力、利益；对财而言，做好预算、合理分配、收支分明；对物而言做到合理分配、动态调整；对完成任务而言，好做好规划、计划、监督考核等。

a ． 再谈建立组织

组织是管理施加的客体，对于人数相对较少的项目，管理可以针对每个人，而对于人数庞大的项目，管理就要施加到组织上去。这里所说的组织可以根据项目的不同进行不同的

组织，最基本的组织之一就是" 程序组" ，主要职责是完成程序编码，一个程序组就是项目经理管理施加的客体，而对于组员来讲则是组长施加的客体。所以可以看出没有合理和稳定的组织，项目的管理就难以实施。

b ． 建立在组织之上的管理

管理的本质是解决问题，如果在项目过程中没有问题，那么管理就不需要存在，而实施恰恰相反，在项目开发过程中有很多的问题，因而管理工作不但繁重而且重要。最日常的工作在于计划的制定、任务的安排、工作考核等等。

要完成好管理不仅是项目经理一个人的事情，它需要组织内有机的联系自动的对管理产生反应，得以落实管理的思想。

c ． 关于工作计划和进度控制

工作计划由长期的和短期的，长期可以是整个项目实施期内的计划，短期可以是一天的计划，针对小组比较适用周计划和日计划，而对于项目组要详细制定月计划和周计划来控制项目的进度并作为工作的考核依据。

d ． 关于弥补措施

什么情况下都难免会有以外发生，为此在管理以及制定计划的时候一定要考虑弥补措施，做到防患于未燃。这些措施包括：突发的技术难题、突然的人员更换、突然的用户需求、突然的计划变动等等。

e ． 关于环境建立和管理

好的项目开发要建立稳定的开发环境，并要确保项目的开发环境与目标环境的一致性。否则将造成巨大的困难。保持环境的相对问题也非常重要，即在项目的开发过程中环境不要变动，包括系统的升级，不必要的或相关的软件的更换等等。如果目标环境为IE 4.0，而使用IE5.0来作为开发环境则会产生很多不必要的问题。

f ． 关于人员培训和知识更新

大型信息系统一般经历的时间都比较长，参与的人员比较多，因此进行必要的培训和知识更新是非常必要的。尤其是在项目开始实施之前，针对项目的若干总体要求要详细的说明并力求达成共识，这为今后大家很好的协同工作创造了一个基础。

培新的内容是多方面的：技术、标准、规范、管理制度等等。

4． 实现技术

a ． 关于数据库的设计

数据库的设计是信息系统设计的基础，关于数据库的设计在考虑设计要求的前提下，尽量考虑如何简化系统的实现。因为有的时候好的数据库设计会大大增加系统实现的复杂度和工作量。这需要不断的积累经验。

b ． 关于开发语言版本

多人参与的信息系统设计要保持各个程序开发语言版本的高度一致，这个问题很容易被忽略，但是到系统集成的时候会给你造成很多的问题。为此，最好所有的人都适用同一个安装程序。

c ． 关于开发平台

除了开发语言之外的其他软件环境组成的开发平台也要保持一致和稳定，才能减少系

统集成时出现的问题。

d ． 关于新技术的采用

新技术的采用是一把双刃剑，如果采用过多会阻碍系统的开发进度。因此要从实际考虑，采用合理数量的信息的技术。这一点还受程序员的接受能力等因素的影响，如果接受能力强，则不必太担心。

5． 关于软件测试

a ． 程序员编码过程中的测试

程序员的测试在很多软件测试的文献中经常被忽略，如果程序员提交的程序代码，他自己从未进行过测试，就提交给测试人员测试是不可想象的。程序员测试的一个基本原则是要确保所有的代码在正确使用下不会有问题，否则将浪费大量的时间修改代码。 b ． 组织测试人员

对于测试的问题大家都有一致的认识, 但在项目实施中, 关键的是按照规范要求组织项目测试小组。这主要受到人员的限制，即组织起来有经验的测试人员跟踪测试是比较困难的，同时也要有一定的投入。

不论如何，还是要建立一个问题的测试小组，随着系统的初步开展进行系统测试。测试的工作量是巨大的, 应得到正确的和足够的认识, 否则交付的软件质量无法保证, 那么项目是否成功又失去了一次机会。应该认识不仅按时完成重要，按质完成更重要。这一点说起来并不特别，但还需要重视才能做好。

c ． 用户测试

大家都知道，面向应用的项目，在交付用户正是使用之前要经过一定时间的用户测试，但目前的实际情况是用户测试组织的不是太好，原因是：真正的用户由于工作的繁重较少的投入到系统测试中，项目组也希望测试期间问题越少越好，可是就为今后不断的出现问题埋下了伏笔。

因此，针对用户测试要组织好，同时还要对资金、人力投入做一个合理的预算。

三、实施及维护

一般认为项目到实施维护阶段，就基本上结束了。实际并非如此，因为就软件开发周期而言，实施阶段的时间投入还要占一定的比例，并且在这个阶段由于对系统的切身使用，多数用户会提出很多的意见和建议，抛开很多不合理问题，还有很多问题需要解决，这就要求项目组还不能放松，还要再紧张地工作一段时间。

1．管理者完成的工作

针对项目实施过程中，管理者要完成的工作实际上不是用几句话能说清楚的，在此仅就某些工作进行简单的说明，更多的内容要在实践中多思考、多总结，不断的提高。

A ． 树立用户意见之上的意识，并让项目组全体普遍接受；

B ． 做好与用户的沟通，尤其针对不合理的问题，要给出合理的解释。

C ． 使用户欣然接受你交付的系统是不断努力才能有的结果；

D ． 要做到不急不躁，同时要注意调整程序员的情绪；

2．关于维护阶段的投入

维护阶段除了项目设计阶段的投入外，还要增加投入包括：现场维护的费用、培训的费用（尤其是组织培训班）、人员的增加（增加与用户交互的人员，再次启用调研组）等等。

3．加强与用户的沟通

加强与用户的沟通不仅是实施阶段应当注意的，但是实施阶段是使用户产生意见的最关键的阶段。

首先作为项目的双方负责人要做到及时、有效的沟通；

其次，各个程序组在与普通用户进行沟通的时候也要注意方式、方法，同时要尽量能用简洁的语言给出明确的解释和说明。

最后需要说明的是：没有每一个用户（乙方负责人、普通用户）的认可和支持就是失败。