- · 《电力系统装备 》栏目设[06/28]
- · 《电力系统装备 》投稿方[06/28]
- · 《电力系统装备 》征稿要[06/28]
- · 《电力系统装备 》刊物宗[06/28]
一、稿件要求： 1、稿件内容应该是与某一计算机类具体产品紧密相关的新闻评论、购买体验、性能详析等文章。要求稿件论点中立，论述详实，能够对读者的购买起到指导作用。文章体裁不限，字数不限。 2、稿件建议采用纯文本格式(*.txt)。如果是文本文件，请注明插图位置。插图应清晰可辨，可保存为*.jpg、*.gif格式。如使用word等编辑的文本，建议不要将图片直接嵌在word文件中，而将插图另存，并注明插图位置。 3、如果用电子邮件投稿，最好压缩后发送。 4、请使用中文的标点符号。例如句号为。而不是.。 5、来稿请注明作者署名(真实姓名、笔名)、详细地址、邮编、联系电话、E-mail地址等，以便联系。 6、我们保留对稿件的增删权。 7、我们对有一稿多投、剽窃或抄袭行为者，将保留追究由此引起的法律、经济责任的权利。 二、投稿方式： 1、 请使用电子邮件方式投递稿件。 2、 编译的稿件，请注明出处并附带原文。 3、 请按稿件内容投递到相关编辑信箱 三、稿件著作权： 1、 投稿人保证其向我方所投之作品是其本人或与他人合作创作之成果，或对所投作品拥有合法的著作权，无第三人对其作品提出可成立之权利主张。 2、 投稿人保证向我方所投之稿件，尚未在任何媒体上发表。 3、 投稿人保证其作品不含有违反宪法、法律及损害社会公共利益之内容。 4、 投稿人向我方所投之作品不得同时向第三方投送，即不允许一稿多投。若投稿人有违反该款约定的行为，则我方有权不向投稿人支付报酬。但我方在收到投稿人所投作品10日内未作出采用通知的除外。 5、 投稿人授予我方享有作品专有使用权的方式包括但不限于：通过网络向公众传播、复制、摘编、表演、播放、展览、发行、摄制电影、电视、录像制品、录制录音制品、制作数字化制品、改编、翻译、注释、编辑，以及出版、许可其他媒体、网站及单位转载、摘编、播放、录制、翻译、注释、编辑、改编、摄制。 6、 投稿人委托我方声明，未经我方许可，任何网站、媒体、组织不得转载、摘编其作品。
以电力系统为例：如何构建大中型系统（一）(2)
作者:网站采编关键词:
摘要：开会要积极参与 和开发沟通要到位 任务安排要细 这些都是产品或者需求基本具备能力和水平，介绍完了项目组和人员的情况接下就是大中型系统的介绍。
这些都是产品或者需求基本具备能力和水平，介绍完了项目组和人员的情况接下就是大中型系统的介绍。
一、多个系统组合
一个大中型系统可能拆分N多系统同时由多个系统进行组合，可见政企在便民服务中投入是不低的。
如果只是单纯的了解一个系统是远远不够，需要同时了解三个或者五个系统，这些系统也一样都是大中型系统，可能A系统中a功能和B系统中d功能之间有着联系，也有可能数据是一样或者数据库表相互关联，后期需求会面临的是需要构建一个F系统，需要在已有的大中型系统进行拆分组合。
这样就需要产品或者需求对于其他系统有一定了解，做好前期准备的工作，在项目开始时面对问题会有一定的了解，同时对于开发的提出问题能够有很好的应对之策。
大中型系统的复杂程度其实在与多个系统功能相互关联，多个功能穿插，其中最关键就是数据的问题，数据问题需要和不同的系统进行比对，不管是产品还是需求都会面临自己写sql校验数据准确性，以及对应的数据表结构要自己去了解。
这些问题如果自己当初设计的就需要在接到不合理的需求时尽可能设计的合理，如果不是自己进行设计就需要首先进行业务的了解和熟悉，进而对于数据库的表进行查看，保证开发有问题时能够及时解决，因为开发会是临时抽调过来，他们不了解具体业务和数据，这些需要产品和需求自己进行了解。
二、业务层级功能深
大中型系统在构建时候因涉及的人员较多、业务复杂会构建很深的层级，在每一个层级功能下面会挂着七八个相关子功能系统，同时这些子系统中数据来源会是其他几个系统数据库中提取数据。
对于这种层级很深的情况，就不要去看任何需求文档和测试环境系统，最好是正式环境和测试一起看，同时需要相关开发人员多沟通，整理自己在使用中遇到的问题和不明白的地方，集中时间进行沟通。
很多细小的功能在大功能模块下起到主要作用，同时这种功能会是很常用功能，有一些功能使用频率不会很高，往往是这些不高的功能后期会展开二期、三期等。
对于大中型系统来说，实用性是较为关注的，相对UI界面设计这些则是关注点较低，这就是为什么会在一个菜单下面挂着七八个子功能，同时扩展会在子功能中不定期修改、增加、删除字段信息。
可能一个功能中的表单会在不同版本中出现好几个，乍一看已经改变了，能够加个字段解决问题就不会让需求或者是产品在业务层面修改，这也是开发和产品共同默认的默契。
三、庞大的架构
大中型系统会由三个和五个系统构成，所以整体架构是一部分，单个系统架构是一部分，这两部分架构构成一个整体系统。
不管是后期的维护还是开始新构建，都需要将这两个架构整理明白，搞清楚业务的整体方向，这也是前期比较耗费精力的部分，需要不断进行调整和沟通，需求方案调整次数会多。在整体架构中经过已经报备之后后期不会进行改动，在功能上面也需要根据相关资料贴合。
大中型系统会有两种存在：一种是完全新开始构建；另一种是已经整体已经完成构建。
先来说新开始构建，需要在较短时间内将整体业务的系统部署到测试环境，同时进行演示，这里会在演示环节进行修改和增加不少，很多大型项目就是从一个测试环境demo开始往里增加功能需求，修改之前的需求进行构建，这里不过多解释相信很多有经验产品自然会懂。
另一种已经存在就是从前面的描述开始进行后半部分，那就是不断的修改和调整功能，增加大功能模块和小功能模块需要根据这个已经改过不知道合不合适的架构上面进行扩展，所以对于整体架构进行整体重构基本上不会出现。
四、维护更新
维护和更新的主要重点则是数据部分，对于功能在业务层面没有大问题将基本上不会进行修改和更新。一个大中型项目在开始时就会分为简单两个步骤，第一步就是业务功能构建，第二部分就是数据。
在确定业务功能之后就会开始数据治理部分，后期对于每一个数据要达到一定的标准值，数据问题主要是新系统和老系统进行数据比对，在一定时间内数据没有误差，就可以完成项目的交付，但是还是要留一部分时间的过渡期。后期维护更新主要侧重点是数据治理部分，对于业务层面的修改调整基本上不会有很多。
构建大中型系统需要的前期准备基本上就是以上内容，下一篇文章将介绍具体实施部分。
文章来源：《电力系统装备》 网址: http://www.dlxtzbzz.cn/zonghexinwen/2021/0314/836.html