这些都是产品或者需求基本具备能力和水平，介绍完了项目组和人员的情况接下就是大中型系统的介绍。

一、多个系统组合

一个大中型系统可能拆分N多系统同时由多个系统进行组合，可见政企在便民服务中投入是不低的。

如果只是单纯的了解一个系统是远远不够，需要同时了解三个或者五个系统，这些系统也一样都是大中型系统，可能A系统中a功能和B系统中d功能之间有着联系，也有可能数据是一样或者数据库表相互关联，后期需求会面临的是需要构建一个F系统，需要在已有的大中型系统进行拆分组合。

这样就需要产品或者需求对于其他系统有一定了解，做好前期准备的工作，在项目开始时面对问题会有一定的了解，同时对于开发的提出问题能够有很好的应对之策。

大中型系统的复杂程度其实在与多个系统功能相互关联，多个功能穿插，其中最关键就是数据的问题，数据问题需要和不同的系统进行比对，不管是产品还是需求都会面临自己写sql校验数据准确性，以及对应的数据表结构要自己去了解。

这些问题如果自己当初设计的就需要在接到不合理的需求时尽可能设计的合理，如果不是自己进行设计就需要首先进行业务的了解和熟悉，进而对于数据库的表进行查看，保证开发有问题时能够及时解决，因为开发会是临时抽调过来，他们不了解具体业务和数据，这些需要产品和需求自己进行了解。

二、业务层级功能深

大中型系统在构建时候因涉及的人员较多、业务复杂会构建很深的层级，在每一个层级功能下面会挂着七八个相关子功能系统，同时这些子系统中数据来源会是其他几个系统数据库中提取数据。

对于这种层级很深的情况，就不要去看任何需求文档和测试环境系统，最好是正式环境和测试一起看，同时需要相关开发人员多沟通，整理自己在使用中遇到的问题和不明白的地方，集中时间进行沟通。

很多细小的功能在大功能模块下起到主要作用，同时这种功能会是很常用功能，有一些功能使用频率不会很高，往往是这些不高的功能后期会展开二期、三期等。

对于大中型系统来说，实用性是较为关注的，相对UI界面设计这些则是关注点较低，这就是为什么会在一个菜单下面挂着七八个子功能，同时扩展会在子功能中不定期修改、增加、删除字段信息。

可能一个功能中的表单会在不同版本中出现好几个，乍一看已经改变了，能够加个字段解决问题就不会让需求或者是产品在业务层面修改，这也是开发和产品共同默认的默契。

三、庞大的架构

大中型系统会由三个和五个系统构成，所以整体架构是一部分，单个系统架构是一部分，这两部分架构构成一个整体系统。

不管是后期的维护还是开始新构建，都需要将这两个架构整理明白，搞清楚业务的整体方向，这也是前期比较耗费精力的部分，需要不断进行调整和沟通，需求方案调整次数会多。在整体架构中经过已经报备之后后期不会进行改动，在功能上面也需要根据相关资料贴合。

大中型系统会有两种存在：一种是完全新开始构建；另一种是已经整体已经完成构建。

先来说新开始构建，需要在较短时间内将整体业务的系统部署到测试环境，同时进行演示，这里会在演示环节进行修改和增加不少，很多大型项目就是从一个测试环境demo开始往里增加功能需求，修改之前的需求进行构建，这里不过多解释相信很多有经验产品自然会懂。

另一种已经存在就是从前面的描述开始进行后半部分，那就是不断的修改和调整功能，增加大功能模块和小功能模块需要根据这个已经改过不知道合不合适的架构上面进行扩展，所以对于整体架构进行整体重构基本上不会出现。

四、维护更新

维护和更新的主要重点则是数据部分，对于功能在业务层面没有大问题将基本上不会进行修改和更新。一个大中型项目在开始时就会分为简单两个步骤，第一步就是业务功能构建，第二部分就是数据。

在确定业务功能之后就会开始数据治理部分，后期对于每一个数据要达到一定的标准值，数据问题主要是新系统和老系统进行数据比对，在一定时间内数据没有误差，就可以完成项目的交付，但是还是要留一部分时间的过渡期。后期维护更新主要侧重点是数据治理部分，对于业务层面的修改调整基本上不会有很多。

构建大中型系统需要的前期准备基本上就是以上内容，下一篇文章将介绍具体实施部分。

文章来源：《电力系统保护与控制》 网址: http://www.dlxtbhykzzz.cn/zonghexinwen/2021/0314/742.html