招标项目性质：公开招标

为保障业务系统正常稳定运行，预算管理一体化系统服务内容主要包含常规级运维和代码级运维。

常规级运维服务涉及到的业务系统包含：预算指标管理系统、国库集中支付系统、其他财政直接支付管理（原拨款支付系统，现已整合至国库集中支付系统）、总会计系统、外贷系统、国库现金债券管理系统、银行账户管理系统、上下级贯通、数据管理、财政转移支付系统。

以上系统所涉及到的常规级运维内容如下：

主要包含热线电话接听、二线电话接听及处理、局内现场问题处理、局外现场问题处理四项，内容涉及为问题收集、整理、处理及归档，同时将问题方案及时反馈用户。其中，热线电话提供5*10.5小时服务，一线问题、局内和局外现场处理提供5*8小时服务。

操作讲解主要包括（1）服务台热线人员接听的来自预算单位的操作指导和问题咨询工作。（2）驻场的二线运维工程师提供的局内处室业务人员的操作讲解。

运维人员会总结归纳操作讲解的内容，以便及时的更新系统操作手册，提高操作手册的可读性和实时性。

根据业务处室启文要求对业务应用系统的用户权限、数据权限、功能权限以及角色权限进行变更。

基础数据的运维工作主要包括功能科目、经济科目、资金性质、项目类型、支付方式、转移支付分类项目、业务处室、预算单位等基础信息项的变更工作。基础数据信息项变更时，业务处室对基础数据提出的特殊要求，运维需考虑业务系统的关联性和历史数据。例如年中要变更预算单位名称，需要优先处理在途数据，然后再做单位名称的变更；

运维人员对单位、处室、及一线电话所接收到的问题进行整理、跟踪并进行处理。

2.5 梳理运维知识库

日常问题汇总、汇报，按日分别向信息中心和总服务台提供《北京市财政局应用系统汇总表》，对于共性问题、重复性问题，整理到知识库给后期系统优化及功能修改提供基础数据根据。

为保障业务系统稳定运行，每日运维人员会对财政各业务系统进行巡检，并提供纸质巡检报告，每周统一提交到运维监理处备案。

如果特殊时期还会缩短巡检周期并进行系统截图，整理成巡检日志发送至总包和运维监理。

派工系统中的工单主要来自根据业务处室OA文派工事项和非OA文的派工事项。

日常运维工作需总包在系统中派工，各运维厂商按照派工单的要求进行处理，每个派工单完成后，运维商需拿纸质版派工单找需求处室进行签字验收并对运维服务进行评价，每月将已经完成的派工单提交总包进行归档。

用户在系统使用过程中发现的系统BUG或校验遗漏需要通过版本维护来解决。每次版本维护工作都需要经过局内的安全测试，安全测试通过后才可以在生产环境进行版本维护来修复系统BUG。

系统维护还包括局内提出的安全漏洞整改。局内安全包会不定期的对各业务系统进行系统安全漏洞扫描，运维商需要按照整改方案按时完成系统整改。

协助数据备份服务，协助配置演示环境服务，系统基本调整，系统关闭、重启及现场重点运维服务。

为市局新到或岗位变更的业务人员进行一对一的系统操作讲解，或新的功能上线后软件使用的操作讲解，还有系统衔接方面的技术环节的操作讲解等等。

为市局业务处室人员进行一对一的业务流程讲解，定期与各业务处室的人员进行业务沟通，相互学习业务知识进而提高系统的易用性。

上门为业务处室人员调试浏览器及安装插件解决报表查询异常，并教会业务人员如何正确安装插件。

按处室需求给业务处室、预算单位进行系统培训，业务流程指导，技术讲解。

4.1新年度数据初始化、新年度服务搭建

每年在8月份需要开始搭建新年度的业务库，需要提取旧的业务系统数据库，对该数据库进行业务数据的清理，对业务年度、数据库序列进行初始化。数据库初始化工作完成后，还需向局内申请新年度应用服务部署的资源来搭建新年度应用服务。

4.2新年度接口配置及调试应用支撑平台与外围系统接口情况：

1）通过DBLink方式进行数据交换的接口一共有13个；

2）通过WebService方式进行数据交互的接口一共有22个，涉及到厂商10个；

每年新年度服务部署后要进行系统的配置工作和与外围业务系统的调试工作，保证新年度对各业务系统之间的数据传输正常和业务的正常流转。

4.3多年度登录门户配置及调试

历史年度、当前年度和新年度门户登录配置及调试。

4.4新年度基础数据调整

每年财政部下发的政府收支功能科目较上年都会发生比较大的调整，有些功能科目是北京市财政局根据管理要求扩展的，北京市财政局自用的功能科目都需要找相关支出处室再次进行确认在新年度是否继续留用。

按处室要求，新年度需要确认启用的预算单位、银行账户、项目类型、转移支付分类项目等。

4.5新年度系统界面调整

根据业务政策的变化，业务系统界面的一些信息项和显示顺序也需要同步跟着做相应的调整。

在现有报表功能不能满足用户需求的情况下，按照用户所提新需求，制作新的报表提供用户进行查询。

根据处室需求对现有的报表进行调整。

系统现有报表无法满足查询的条件下进行后台数据查询并提供报表，这类需求提出者大多数为：预算处、国库处、审计署。

6.1预算指标管理系统

业务系统中的有些报表是在特定的业务要求下定制的，在后台中部分代码已写死，年度初始化时需要对这些条件语句进行修改，保证新的年度不会影响数据的查询。

根据新的预算预拨规则对新年度的指标提前预拨，保证按照处室要求的时间完成预拨任务。

根据新的预算批复规则对新年度基本经费和项目经费进行批复工作，保证批复数据的准确性。

6.1.4待下达指标结转

上年待下达指标结转至新年度供预算单位可以使用到新年度的四五月份。

根据预算处要求，确认回收资金范围的口径；回收上一年度未使用完的资金。

对当年未支用完的指标，运维人员通过系统向银行发送注销额度，保证在新年度之前将当年未支用的指标进行结转。

预算编审系统与指标管理系统按照预算处要求的汇总表对账，还需要按照功能科目、资金性质、经济科目、处室、单位等明细口径核对年终批复的指标。

6.1.8数据中心相关工作

通过dblink将增量总账等业务数据传送至华宇数据库后，定期与华宇进行数据核对、数据处理等相关工作。

6.2国库集中支付系统

对支付系统在新年度中新提的报表需求进行初始化。

预算单位与代理银行对账；

总会计与支付系统对账；

其他财政直接支付与支付系统对账。

6.2.3年中结余回收

根据北京市财政局的预算资金管理办法，对上年及以前年度结转的资金，各预算单位统一支付截止时间至年中，年中进行上年结转资金的统一回收。

6.2.4待下达指标结转

与预算处进行相关的数据核对及规则确认后，通过结转功能将上一年的中央待下达指标结转到下一年度。

年终结转工作流等初始化配置及回收口径确认；

相关业务在途数据确认并处理；

屏蔽系统所有操作权限。

6.2.6电子签名签章的维护

对预算单位端使用授权凭证，公务卡、直接支付等审核流程中岗位操作进行电子签名签章的校验，对岗位进行签名签章的维护。

对财政端操作用款计划、直接支付等审核岗位进行电子签名签章校验，对岗位进行签名签章的维护。

6.2.7用款计划流程审核查询

根据用户要求，指导处室查询、审核或退回用款计划数据。

6.2.8直接支付流程审核查询

根据用户要求，指导处室查询、审核或退回直接支付数据。

6.2.9公务卡系统数据上传下载查询维护

根据银行及用户要求，协助查询及处理代理银行上传的公务卡卡信息数据，对于签收失败的情况进行分析处理，并反馈银行及用户。

根据银行及用户要求，协助查询及处理代理银行上传的公务卡消费信息数据，对于签收失败的情况进行分析处理，并反馈银行及用户。

根据银行及用户要求，协助查询及处理代理银行上传的公务卡明细汇总信息数据，对于签收失败的情况进行分析处理，并反馈银行及用户。

6.2.10日常支付及额度数据签收、发送、回单情况查询

根据财政和代理银行要求，运维人员需要：

1）协助国库处查询并处理代理银行、人行与财政端直接支付、授权支付及汇总额度数据的传输和接收情况，并对签收失败、退回等情况进行分析处理。

2）协助国库处查询代理银行上传的额度到账通知书的接收情况和预算单位查询打印情况。

6.2.11总会计系统每日记账数据核对不一致查询及处理

根据国库处要求，协助查询支付系统与总会计系统每日支出记账情况，并对问题数据进行分析，按国库处要求进行处理。

6.2.12其他财政直接支付管理

年初，待指标批复完成后，对待均衡的拨款计划进行均衡，并协助处室核对计划金额。

年初，待工会经费批复完成后，对待均衡的工会经费计划进行均衡，并协助处室核对计划金额。

年底协助处室对工资账，使工资支出数与指标登账数相同。

配合国库会计组保障每月工资顺利发放工作。

根据新年度的新需求进行报表的初始化。

指标与拨款系统指标数对账；

总会计与拨款系统预算拨款对账；

总会计与拨款系统预算外收支情况对账；

实拨审批单国库处与总会计支出对账；

实拨审批单国库处与非指系统（国库）对账；

实拨审批单国库处与社保资金（社保处）对账。

根据新年度的新需求进行报表的初始化。

6.3.2年初期初数处理

总会计系统各账套期初数整理、修改、导入等相关处理。

集中支付与总会计对账；

拨款与总会计对账需后台查询数据。

6.3.4旬报、月报修改

按照财政部要求修改报表数据源和模版。

对系统中的11个账套分别结转，查询核对数据。

每年7月份、12月份协助外事处将各代理银行的人行月报导入外贷系统，根据外事处要求出报表。

配合北京市财政局委托的具备等保测评资质的单位对北京市财政局预算管理一体化系统进行信息安全等级测评。

代码级运维服务涉及到的业务系统包含预算指标管理系统、国库集中支付系统、总会计系统、银行账户管理系统、上下级贯通、数据管理。

预算管理一体化系统如有一些简单功能的代码修改，则需要通过系统小版本的维护来完成，完成新版本的维护发布过程，需总包派工由其他相关厂商配合完成局内版本维护安全测试、停服务、版本维护、启服务、验证服务等事项。

对系统在使用过程中用户反馈的问题和运维人员发现的可以进行优化的操作，需及时提交研发优化操作和流程，确保在不影响现有业务的前提下，对系统进行优化处理，提高系统的易用性。

系统在运行过程发生故障，运维人员应及时响应给出应急方案，运维人员无法消除故障时，需及时汇报公司寻求技术支援，确保故障能在最早的时间内被排除。事后需编写故障报告，总结故障发生的原因以和解决方案。

系统功能不能满足用户的报表查询或数据核对的需求时，依据业务需求通过管理员权限或者进入数据库查询或提取相对应口径的数据。

业务系统在使用过程中，由于业务人员的误操作或者在某些特定时期处室所提新的业务功能还没有上线的情况下，业务处室会通过局内传文协办信息中心要求通过后台来修补数据。

年初预拨、年初批复、年终结转、对账等重点性运维工作都需要通过后台来完成数据的核对工作。例如每年12月31号需要通过后台查询来完成年终各业务系统的对账工作。

现有页面无法满足用户需求时，需修改对应页面的数据展示规则来满足需求。

业务处室提出的部分新需求，运维人员可以通过后台修改现有视图、触发器或存储过程来完成。

7.1预算指标管理系统

7.1.1预拨指标生成规则变更

根据预算要求变更预算编审生成预拨指标的预拨规则、更改程序。

7.1.2预拨指标支付方式规则整理

根据处室要求收集并整理所有预拨指标支付方式生成规则，并按照规则写入代码。

7.1.3预拨指标数据核对

根据预算编审系统发送的数据，后台出项目口径的脚本核对预拨基本经费和项目经费。

7.1.4预拨指标调整

根据处室用户要求将已导入的预拨指标进行后台变更调整。

7.1.5预拨指标导入性能优化

每年根据预拨指标导入的数据量程序优化导入性能。

7.1.6年初批复指标生成规则变更

根据预算要求变更预算编审生成批复指标的批复规则、更改程序。

7.1.7年初批复指标文号建立

年初批复时建立正式文号，待批复导库时使用。

7.1.8建立正式文号指标数据对应关系

根据正式文号与指标建立关系，将指标数据与文号做挂接。

7.1.9中央项目与预算指标系统中中央安排指标进行核对

根据预算编审系统中中央项目核对预算指标系统中是否存在对应的待下达资金，根据核对结果建立对应关系。

7.1.10年初批复指标导入性能优化

每年根据批复指标导入的数据量程序优化导入性能

7.1.11年初已导入数据变更

根据处室需要对已导入的年初批复数据进行经济科目，预算科目等字段的变更。

7.1.12追加指标安排和下达流程维护

根据处室要求对相关流程进行变更维护，解决审核过程的问题。

7.1.13追加指标下达支付方式生成规则变更

跟处室要求将追加指标下达时生成的支付方式进行程序变更。

7.1.14处室内处室间指标调整变更

根据处室要求，变更预算科目，资金投向，市级区级等字段的调整规则。

7.1.15指标系统相关数据的出示

根据处室要求，按照处室提供的出数口径，后台根据编写脚本完成相关数据出示。

7.1.16指标系统报表变更维护

根据处室要求对指标安排，下达相关报表进行字段和查询条件的增加，报表口径的变更，保持与现有业务的一致性。

7.1.17对已下达核减的指标数据后台变更

根据处室要求，后台变更已下达数据变更是否采购，采购类别，是否补贴等字段。

7.1.18系统修改后，四系统联调

在指标系统里，增加指标，然后进行支付、记账联调针对测试发现,有问题的特殊场景,进行补充维护，发现问题的修改调整。

7.1.19指标系统与外围系统接口维护

根据业务需要，指标系统政府采购系统接口进行字段增加，规则变更等，需要变更程序完成维护工作。

指标系统登账成功后，在原有指标系统到公文系统接口中增加一条数据“是否中央转移资金下达”。

当指标下达完成时，公文系统给指标系统发送正式文号时，指标系统给公文返回的接口中增加“是否完成下达”字段。

据预算编审系统的需求调整指标模块基本经费的衔接。

7.1.20系统接口与外围系统联调测试

维护完成后对所有场景进行在线联调，针对测试发现,有问题的特殊场景,进行补充维护，发现问题的修改调整。

7.2国库集中支付系统

7.2.1用款计划流程性能及审核页面优化

根据业务需求对现有用款计划流程进行变更，增加重点项目处室审核岗位。

7.2.2直接支付申请流程性能及审核页面优化

根据直接支付申请业务量的增加，对计划逐岗进行性能及页面展示优化，提高审核速度。

7.2.3直接支付合同的查询及处理

对于采购合同中存在合同支付金额，供应商信息情况，根据处室要求进行合同的更改及维护工作。

7.2.4直接、授权额度汇总清算通知单查询及处理

根据业务要求，针对于银行传输的存在问题的直接、授权额度汇总清算通知单进行查询及处理。

7.2.5相关业务数据的出示

按照国库提供的具体口径通过脚本从后台数据库中按照用户要求，提取出相关的数据信息。

7.2.6优化公务卡报销管理流程

根据预算单位及国库处提出的相关需求，修改公务卡报销管理流程。

7.2.7完善公务卡管理

根据预算单位及国库处提出的需求，完善公务卡管理流程。

7.2.8跨行公务卡共享

根据预算单位及国库处的需求，实现跨行公务卡共享需求，方便相同持卡人在不同的单位进行报销。

7.2.9增加与教委内部财务公务卡管理系统对接，实现自动导入

根据预算单位及国库处需求，增加与教委内部财务公务卡管理系统对接，实现自动导入。

7.2.10基础数据传输方式变更

代理银行下载基础数据(预算单位、预算科目、预算项目、资金性质、支出类型、业务处室、指标类型、指标来源、结算方式）通过凭证库绿色通道进行下载。

7.2.11预算科目更正功能

授权支付凭证更改查询、生成、审核及发送功能；

授权支付凭证科目更改凭证确认支付、清算接收及处理情况。

7.2.12财政与电子凭证库对账功能

完成凭证库及代理银行间关于公务卡卡信息、消费信息、明细汇总信息电子凭证对账。

支付凭证发送单、支付回单、清算回单、额度通知单、汇总额度清算通知单电子凭证对账（直接支付、授权支付、公务卡、工资直接支付）。

直接、授权退票电子申请数据对账。

工作人员业务权限分级管理；增加委托授权收回、查询功能。

7.2.14财政与代理银行对账维护

汇总对账结果推送代理银行。

7.2.15集中支付系统与外围系统接口变更及维护

根据业务需要，集中支付系统与动态监控系统，政府采购系统，结余系统，电子凭证库系统、人行、代理行电子化接口报文规范等接口进行字段增加，规则变更、增加数据抽取等。

7.2.16集中支付系统报表变更维护

根据处室要求对计划，支付报表进行字段和查询条件的增加，报表口径的变更，保持与现有业务的一致性；并根据处室要求，维护三公经费，单位执行进度表等满足现有业务的需要。

7.2.17完善部门决算与集中支付接口，自动完成接口数据的提取

现有的接口均需多次进行数据的手工导入，人工干预较多。根据国库处需求，通过信息化手段实现数据自动提取。

7.2.18年初拨款计划数据的初始化

根据各个处室要求将年初批复的指标进行拨款计划的导入并将拨款计划均分到各个月份。

7.2.19完善预算外基本经费生成审批单功能

根据教育事业处需求，增加预算外基本经费生成拨款审批单功能。

7.2.20拨款系统业务数据变更及处理

根据处室要求，后台变更拨款计划及审批单预算科目，是否补贴，是否大额等信息。

7.2.21核对工资拨款计划及数据处理

每月与人员经费系统核对在职工资和离退工资数据，对不一致的数据查明原因并进行处理。

7.2.22其他财政直接支付与外围系统接口变更维护

根据业务需要，拨款系统与人员经费系统，退役金系统，政府采购系统等接口字段变更，数据处理等维护工作。

7.2.23其他财政直接支付报表变更维护

根据处室要求对拨款计划，拨款审批单报表进行字段和查询条件的增加，报表口径的变更，保持与现有业务的一致性。

7.3.1接口调整及维护

根据业务需求与外围系统接口进行调整。

7.3.1.1与其他资金系统接口

各帐套与其他资金接口取数配置、数据核对。

7.3.1.2与国库集中支付系统接口

各帐套与国库集中支付系统接口取数配置、数据核对。

与非税系统自动任务异常问题处理、接口取数配置、数据核对。

根据国库要求，挂载核算要素后全年数据导出。

7.3.3完善非税财政专户帐套

非税财政专户账套非税收入数据退回功能变更。

7.3.4异地就医维护

异地就医拨款维护，对相应视图进行修改。

7.3.5总会计系统报表维护

与结余资金增加对账报表及对账功能。

7.3.6中央分成业务维护

中央分成由预算拨款凭证改到一般缴款书进行拨款。

7.3.7自动生成更正调库调库书匹配规则完善

更正调库通知书自动生成时，市级-中央，市级-市级，市级-区县科目匹配完善。

7.3.8国库非税收入账套收入科目与单位匹配规则

国库非税收入账套增加收入科目与增加单位匹配的规则维护。

7.3.9配合开展决算工作

配合开展决算工作，提供决算账务数据并进行数据核对。

7.3.10凭证模板配置维护

涉及新的基础信息，需更新凭证模板。

7.4银行账户管理系统

7.4.1简化审批流程

简化审批流程（五岗变三岗，如过部门3天不审直接送到国库审核）。

7.4.2修改开立界面字段

账户开立界面隐藏掉附件，单位信息维护都设置为必填。

7.4.3修改变更内容

财政批复文号可以在账户变更界面直接做变更（现在情况必须做撤销在做开立）。

7.4.4修改账户查看顺序

国库在查看审核后的账户时按照国库审核的时间顺序来排序

7.4.5修改单位信息维护字段

单位信息维护界面删除组织机构代码，增加市编办批复文号/社会统一代码证/事业单位法人证书字段。

7.4.6修改账户变更显示内容

账户变更时，审核人只需要看到做变更的字段或着重显示该字段。

7.5.1数据查询、变更、核对

查询、变更、核对“市级下发区级指标、区级返回市级指标、支付”数据。

7.5.2性能优化及故障处理

对本系统进行性能优化，代码进行故障排查及处理。

7.6.1数据查询、变更、核对

查询、变更、核对“单位、功能科目、收费项目”等基础数据。

7.6.2性能优化及故障处理

查询、变更、核对“单位、功能科目、收费项目”等基础数据。

7.7 财政供养人员信息表

7.7.1信息采集上报

由区县财政拨款（补助）的独立核算的行政事业单位的人员信息情况，共计3张数据表。采集北京市16个区县的约5000家预算单位的财政供养人员信息，并完成审核、汇总、并上报财政部。

1.站在底层原理的角度
 数据库指的是操作数据的进程(一堆代码)
2.站在实际应用的角度
 数据库指的是可视化操作界面(一些软件)
以后不做特殊说明的情况下讲数据库其实指的是数据库软件
数据库软件本质也是CS架构的程序
意味着所有的程序员其实都有资格编写一款数据库软件 
 特征1:拥有固定的表结构(字段名 字段类型)
 特征2:数据之间可以建立数据库层面关系
 1.MySQL:开源免费 使用最广 性价比贼高 
 2.Oracle:收费 使用成本较高但是安全性也最高 
 5.sqlite:小型数据库 主要用于本地测试
 特征1:没有固定的表结构 数据存储采用K:V键值对的形式
 特征2:数据之间无法建立数据库层面的关系
 可以自己编写代码建立逻辑层面的关系
 1.redis:目前最火 使用频率最高的非关系型数据库(缓存数据库)
 虽然缓存数据库是基于内存做数据存取但是拥有持久化的功能
 2.mongoDB:文档型数据库 最像关系型数据库的非关系型数据库
 主要用在爬虫以及大数据领域
虽然数据库软件有很多 但是操作方式大差不差 学会了一个几乎就可以学会所有 其中以MySQL最为典型
 ps:站在开发的角度使用哪个版本学习都没有关系
 5.选择对应系统的对应版本下载即可(zip压缩包)
bin目录：存放启动文件
data目录：存放核心数据
 

cmd建议你使用管理员身份打开
2.保持窗口不关闭 重新打开一个新的cmd窗口
直接使用mysql命令默认是游客模式 权限和功能都很少
管理员默认没有密码 连续回车即可
 

1.先把bin目录添加到环境变量
 清空之前打开的cmd窗口 一定要把之前用cmd启动的服务端关闭(ctrl+c)
2.将mysql添加到系统服务中
 鼠标右键任务栏选择服务
 2.以管理员身份打开cmd窗口
3.首次添加不会自动启动 需要人为操作一下
 方式2:直接修改存储用户数据的表
 方式3:冷门操作 有些版本可能还不支持 
 方式2:把data目录删除 拷贝同桌的目录
 2.以跳过授权表的方式重启服务端(不校验密码)
3.以管理员身份进入然后修改mysql.user表数据即可
4.关闭服务端 然后以正常方式启动即可
 

数据库服务端是可以服务多种类型的客户端
客户端可以是自己开发的 也可以是python代码编写 也可以是java代码编写
SQL:操作关系型数据库的语言
NoSQL:操作非关系型数据库的语言
要想跟数据库交互就必须使用数据库指定的语言
SQL有时候也指代关系型数据库
NoSQL有时候也指代非关系型数据库
 

强调:小白阶段为了更加方便的理解 做了以下比喻 本质其实有一点点的区别
库 就相当于是 文件夹
表 就相当于是 文件夹里面的文件
记录 就相当于是 文件夹里面的文件中的一行行数据
 

1.sql语句必须以分号结尾
2.sql语句编写错误之后不用担心 可以直接执行报错即可
 

• 如果想跨库操作其他表 只需要在表名前加库名即可:desc mysql.user;

需求分析说明书（一份全面的“需求分析说明书”是怎样的？）
对于需求分析说明书（又名需求规格说明书），有很多刚入行的小白对此有很多的迷惑，在这里我就接着多年的工作经验，并拿出曾经给负责的一个项目撰写的需求分析说明书来作为案例给大家展示一下，写得不好，其中也有很多欠缺之处，愿朋友们看过之后能够给出很好的批评，咱们在这里相互学习、共同进步！

本需求分析说明书主要以剖析的方式对“XXXXXXX管理平台”做全面细致的用户需求分析，明确所要研发的系统应具有的模块、功能与界面内的详细需求，以供业主能够确认项目的基本功能和具体性能，和业主达成一个立场，从而形成一致的理解和确定，是系统分析人员及后续的系统设计人员能够更加清楚地了解用户的具体需求，使得后面的设计、研发工作的基础。
本说明书的预期读者是：项目管理人员、系统设计人员、研发人员、文案、测试人员、业主。

3.1 所建议开发系统的名称
XXXX信息科技有限公司
近年来，随着经济社会和城市建设的快速发展，市政基础设施行业发展越来越快，投资规模也越来越大。
市政工程项目具有规模大、作业人员多、材料设备种类繁多、工序复杂、环境复杂、管理条线多、管理强度大、质量与安全隐患大等特点，使得工程项目管理要求及难度非常大。
目前相比制造、金融等行业，建筑业的信息化程度整体较低。传统的依靠人力来处理信息的管理方法已很难实现精细化、高效的项目管理，更无法适应建筑业快速发展的要求。因此，建筑企业纷纷进行信息化建设，通过信息技术的应用来强化企业的集约化管理，基于信息化系统的协同工作来提升项目的管理水平。
走在信息化前沿的各大企业，均将信息产业作为新兴业务板块，投入大量资源成立独立的公司以助力集团的数字化转型，进而驱动主营业务的发展。
如宝钢集团1996年就成立了宝钢软件公司，发展至今宝信软件在工信部发布的2021年中国软件业务收入前百家企业名单中排名第35位，为企业提供IT规划咨询、MES、ERP、BI等管理信息化整体解决方案以及个性化的软件定制服务。
行业内，华东建筑集团股份有限公司也于2021年底成立了华建数创（上海）科技有限公司，着力建设“互联网+设计”、“数字化+建筑”、“智慧化+工程”等三大业务引擎，意图发展成为工程行业互联网平台公司。
信息化已成为各大建筑企业发展战略的重要组成部分，加强信息化基础设施建设，推进管理信息系统升级换代，推动多方协同工作与数据共享，探索大数据技术的集成应用，已成为本行业发展的必然趋势。
3.4 集团建设工程项目信息化管理现状
3.4.1 项目信息化管理系统使用现状
在平台规划之前，我们首先对上海隧道、路桥集团和市政集团三家子公司在建工程项目的信息系统使用情况进行了调研。
从调研结果可以看出来，政府主管部门和业主对于项目管理信息化的要求不断提高，我们也应该相应地提升项目管理的信息化和智能化程度。
各子公司和项目经理对于信息化管理存在迫切需求，都在尝试开发或购买相关的信息管理系统来提高管理的能力和效率。
但目前不管是集团还是子公司，都没有统一的管理规定和开发标准，系统的应用深度参差不齐。众多的系统架构各异，数据也难以共享。同时各级的管理单位均有数据填报要求，项目没有实现业务数字化，数据都要人工进行分头填报，填报工作量大，存在多头填报、上报数据质量无法保证等问题。
3.4.2 集团现有项目管理系统基础
对于集团而言，项目管理已经有了一定的信息化基础，开发和全面推广了XX系统、XXXX平台、XXXXXX系统和XXX平台，取得了显著的效果，但使用中也暴露了一些不足，主要体现在：
XX系统经过几年的推广使用，培养了项目用户的使用习惯，形成了日报、周报、月报审阅制度，涵盖了项目信息、项目筹划、进度、风险、安全等重要管理功能。但XX系统是从上级监管的角度开发，以项目数据填报的形式为主，没有提供给项目经理进行业务管理的功能。每个项目只能通过项目经理的账号来进行所有数据的填报，无法将工作分解给项目相应的管理人员。而多数项目经理将数据填报工作分配给信息员，上报数据的完整性和准确性都有待提高。同时，XX的开发时间较早，受底层框架限制，再进行功能的扩展如新增项目成本管理、动态评估等功能非常困难；
XXXX系统和XXXXXX系统都是针对项目安全管理开发的专项应用系统。这两个系统与XX系统相互独立，建管与安全分离，数据没有联通。通过XX系统和XXXX系统抓取的安全隐患和整改情况无法直接同步到XX系统，项目上需要再次人工填报；
XXXXX平台采购系统逐步将项目大宗材料采购行为整合到了平台上，材料采购是项目管理的重要方面，与成本管理、供应商管理均有密切关系，目前该系统也是独立的，没有进行对接和整合。
因此，本项目拟融合集团现有系统功能，建立统一的集团建设工程管理体系和监管平台；开发项目端，为项目的全方位管理提供工具；实现系统间的数据共享和交互，为数据分析和辅助决策提供支持，实现业务数据化、数据业务化，通过项目业务的数字化开展来获取大量数据，通过数据的挖掘分析为项目提供价值。
3.5 建设必要性分析
现阶段，国家已将信息化建设提升到前所未有的高度，建设部指出建筑业信息化是建筑业发展战略的重要组成部分，也是建筑业转变发展方式、提质增效、节能减排的必然要求，对建筑业绿色发展、提高人民生活品质具有重要意义。
住建部《年建筑业信息化发展纲要》提出，“十三五”时期全面提高建筑业信息化水平，着力增强BIM、大数据、智能化、移动通讯、云计算、物联网等信息技术集成应用能力，建筑业数字化、网络化、智能化取得突破性进展，初步建成一体化行业监管和服务平台，数据资源利用水平和信息服务能力明显提升，形成一批具有较强信息技术创新能力和信息化应用达到国际先进水平的建筑企业及具有关键自主知识产权的建筑业信息技术企业。
《工程勘察设计行业发展“十三五”规划》及国家大数据战略、“互联网+”行动等相关要求，推动信息化与建筑业的深度融合发展，促进BIM、物联网、云计算、移动互联网、大数据、智能化等信息技术的集成应用能力，实现工程建设项目全生命周期数据共享和信息化管理，推动建造方式创新，助力企业转型升级，促进企业提升核心竞争力，实现业态创新。
作为基础设施领域的龙头企业，集团更应积极探索 “互联网+”协同工作模式，实现全过程信息化，强化企业知识管理，支撑智慧企业建设，以实现跨越式发展。

系统或者平台：如果没有特别的指出，则本文中述写的系统或者平台只指XXXXXXX管理平台。
用户：被授权使用或负责维护应用信息系统的人员。
用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、单位、联系方式等基本信息内容。
权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。
角色：应用信息系统中用于描述用户权限特征的权限类别名称。

《项目可行性建设方案》
《项目开发计划说明书》

假定：用户能够提供系统全面上线的测试环境，以及能够实地的参与到需求的核准工作中；
约束：本系统的全面上线日期为；

本项目将建立“XXXXXXX管理平台”，以项目为基点，通过平台提供覆盖建设工程的进度、质量、安全、成本、人员、设备、材料等要素的管理工具，项目业务应用数字化后产生大量数据，为集团、子公司、分公司各级的监管提供数据支撑。
同时以分级管理为导向，挖掘分析和可视化展示数据，通过数据应用为业务带来价值，基于平台实现集团建设工程的管理标准化，业务规范化，监控智能化，数据可视化，经验智库化，资源共享化。

XXXXXXX管理平台的主要建设任务包括以下几部分：
2.1 前期调研及总体规划
前期调研和总体规划阶段，将针对集团建设工程监管的实际情况进行深入的调研和需求分析，为项目的方案设计提供必需的基础资料。
调研目前政府相关主管部门、集团、子公司下发的管理办法和规定，在平台的设计里体现相应的管控要求和标准，对于目前尚未形成标准的，通过平台能够建立一套可行的通用管理流程。
对项目经理进行调研，了解目前项目的管理现状和信息化的需求。各位项目经理共性的需求包括在XX的基础上深化进度和风险模块，新增成本管理、知识库和项目过程资料管理等功能需求，并希望能够改变XX系统由项目经理进行数据填报的模式，将数据填报模式变为项目管理模式，相应的项目人员都能够使用系统开展工作，项目经理能够通过系统来管理项目和相应岗位人员的工作情况。
对集团的业务部门、子公司和分公司分别进行调研，了解他们对于项目的监管需求和数据分析展示需求，进行相应管理端模块的设计。
对项目上正在使用的系统（如XXXXX项目管理系统、技术管理系统等）、将与本平台进行对接和整合的系统（如XXXX平台、XXXXXX管理系统等）进行专题的深入调研。
根据调研结果，对平台进行顶层架构设计、数据库总体架构设计、数据信息汇集机制设计和平台主数据标准设计。
2.2 工程项目管控标准体系建设
建立集团建设工程项目的管控标准体系，基于平台实现六个统一：统一的流程管理体系；统一的业务框架体系；统一的项目进度体系；统一的项目评价体系；统一的信息发布与交流体系；统一的知识管理体系。
2.2.1 工程项目管控中心数据库建设
工程项目管控中心数据库汇集了相关的各类项目静态数据、动态业务数据、智能监测数据、环境数据等。
对各类数据的数据源、入库方式、数据量和数据更新频率进行分析，制订合理的数据标准和数据库结构，实现海量数据存储和数据预处理，并实现高效的多源异构数据融合、查询统计、智能分析预警等功能，同时提供标准的API接口，为外部系统的数据接入和共享提供支持。
2.2.2 工程项目智能管控平台开发
平台考虑集团、子公司、分公司和项目的不同需求，功能主要包括：
建设项目智能管控平台（项目端）：项目端平台主要通过对项目现场进度、质量、安全、风险、成本以及“人、机、料、法、环”等具体管理需求对各建设工程全要素进行精细化管理，以及信息的采集、汇聚、分析和应用，业务需求侧重于为项目提供全过程的管控功能；
建设项目智能管控平台（管理端）：管理端平台以项目端为基础，通过统一后台实时接入项目端的各类数据，实现多项目的集中管控、信息分类查询、统计分析等功能，满足管理者对各工程项目快速定位、分析预警、审核评价、决策分析等管控功能上的需要。同时管理端平台全面兼容项目端的信息查看功能，有助于各级管理单位及时准确掌握现场信息，更加高效合理的判断和决策。
2.2.3 工程实施及应用
本项目将深入探索信息化技术对建设工程全方位、全时段、全过程的即时监控管理功能，力争建立一套简单、高效、实用的监督管理和项目自检信息化流程。
为保证平台的稳定性和可靠性，首批拟在各子公司分别选择1-2个新建项目，对平台的各项功能进行多样本的充分试用。运行稳定后在集团全面推广，并将XX系统中的历史数据全部迁移至本平台，将存量项目逐步迁移至新平台。

1.04 计划、需求、设计阶段：编撰各项计划书；主要进行需求的分析和现状的调研；制作思维导图；进行平台的总体架构高保真原型（UE、UI）设计；
1.12 研发、测试阶段：根据需求分析、原型设计、以及项目开发计划书，实施相关工作，如下：
04-2021.08 第一阶段：XXXXXXX管理平台业务应用模块的开发和部署；中心数据库设计和基础架构的搭建；系统首页、项目筹划、进度管理、风险管理、人员管理功能模块的建设，试点工程实施方案设计，从而实现首批试点工程实施和数据上线为主等。除此之外还包括对已经上线的内容的单元测试和部分集成化测试；
08-2021.10 第二阶段：在第一阶段的基础之上，完成安全管理、材料采购、设备管理、供应商管理、视频监控、动态评价功能模块的研发，以及对完成的功能模块进行单元测试和部分集成化测试；
10-2021.12 第三阶段：在第一、第二阶段的基础上，完成XXXXXXX管理平台剩余功能模块的数据分析和内容开发，包括移动APP的开发，从而实现平台的全面上线；外部系统数据接口开发；原有XX系统历史数据接入；集团工程项目的全面深化实施应用、日常监管项目数据上线；相关标准规范体系和知识库建设完成。并生成目标系统，并确认是否达成项目目标。

必须保证程序正常的连接到服务器，并保持网络的畅通。

平台考虑不同层级的用户的需求，分为项目端和管理端。
平台一共有17个主要功能模块，对于项目端，我们提供项目经理工作台，能够一目了然地在首页上看到自己项目的总体情况，并为项目经理提供知识库进行参考。以及为项目提供一个全要素的项目管理工具，包括筹划、进度、质量、安全、风险、成本、人员、材料、设备、供应商、报表、文档，项目上不同岗位的管理人员能够各司其职，项目经理进行总体的把控和管理。
对于分公司和子公司来说，是处于执行管理的角色。平台主要是提供对多个项目的总览、业务的监督检查、流程审核、预警管理、报表审阅、绩效考核等功能。
集团主要是进行监管，因此提供给集团用户的功能偏重于数据分析总览、重大风险预警、管理行为、报表审阅和项目的动态评价。
高层级的用户可以穿透到项目端，进行详细的数据的查看。

2. 建设项目智能管控平台
管理端旨在为决策层、管理层提供业务监控和决策支持，平台从业务系统最底层直接获取数据，以各业态项目管理过程产生的一手数据为基础，用最直接、最直观、最及时的方式展示管理关键要素信息，并实现各类结构化数据的集中汇总、统计、分析与多维度展示。
管理端平台包括PC版、大屏展示版和移动APP。

项目端重点在于实现业务的全面管理，为项目经理提供标准化的工具、知识和决策辅助，并提供数字化工地智能监控数据全兼容的支持。
项目端的建立，首先为工程项目管理提供应用服务，同时为平台采集大量的业务数据，自动生成各类报表，为项目监管与决策服务。
3.1 功能模块结构图
平台从各模块得到的数据在我的工作台会得到更加精炼的整合，在这里利用图、表的方式来展示项目中的重要信息，具有一定的针对性和实时性，其相当于对每一个功能模块整理出来的信息梗概，并将这些信息进行了统一规划，形成一个具有一定操作性和层次性的并给用户以明朗和具有全局观的数据可视化窗口。

1.1 数据来源及流向示意图
平台中的数据来源分为内部和外部两大部分。
内部数据包括项目现场的业务数据、自动化监控数据和项目知识库。业务数据来源于项目过程管理，包括项目的筹划信息、进度数据、质量数据、安全数据、施工风险数据、供应商数据等。
自动化监控数据来源于项目智能监控设备，包括设备监控数据、施工监测数据、安全讲评台数据、用电监控数据、人员出入及定位数据、环境监测数据、视频监控数据等。
知识库初始来源于集团现有经验和知识的梳理，并在项目过程中不断补充和完善。
外部数据包括来自既有信息系统（如主数据系统、人力资源系统、阳光采购平台、资金管理系统）的工程基本信息和专题信息，以及通过离线方式导入的地理信息数据及其他数据。
以上数据均在平台数据标准的约束下进入数据中心，通过中心数据库与应用系统形成数据交换，并在此基础上开发标准化数据接口，将数据共享给其他需要的外部系统。

对数据进行逻辑描述时可把数据分为表态数据和动态数据两种。
进行描述时应把各数据元素逻辑地分成若干组，列如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定义（或物理意义）度量单位、值域、格式和类型等有关信息。
2.1 表态（静态）数据
表态数据就是所谓的静态数据，指在运行过程中主要作为参考的数据，它们在很长的一段时间内不会变化，一般不随运行而改变。
列出所有作为控制或参考用的静态数据元素如下表所示：
列出向用户或开发单位中的维护调试人员提供的内部生成数据。
所谓动态数据，包括所有在运行中要不断或者在特定的条件下而发生变化的数据，以及在运行中要输入、输出的数据。

对平台中所出现的各个实体的属性进行整理，使其形成数据词典，以此可以来作为后继研发过程中数据结构设计、数据库设计、数据库表结构设计的主要参考来源。
并说明对数据要求的制约，逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制（容 量、文卷、记录和数据元的个数的最大值）。
对于在设计和开发中确定是临界性的限制更要明确指出。
3.1 功能模块一（案例）

按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。
输入数据的来源，例如是单个操作员、数据输入站，专业的数据输入公司或它们的一个分组；
数据输入（指把数据输入处理系统网内部）所用的媒体和硬设备。如果只有指定的输入点的输入才是合法的，则必须对此加以说明；
接受者说明输出数据的接受者；
输出数据的形式和设备列出输出数据的形式和硬设备。无论接受者将接收到的数据是打印输出，还是CRT上的一组字符、一帧图形，或一声警铃，或向开关线圈提供的一个电脉冲，或常用介质如磁盘、磁带、穿孔卡片等，均应具体说明；
数据值的范围给出每一个数据元的合法值的范围；
量纲给出数字的度量单位、增量的步长、零点的定标等。在数据是非数字量的情况下，要给出每一种合法值的形式和含意；
更新和处理的频度给出预定的对输入数据的更新和处理的频度。如果数据的输入是随机的，应给出更新处理的频度的平均值，或变化情况的某种其他度量。
4.2 数据采集对象列表

5. 数据结构与程序的关系

建立完善的数据库结构管理设备的基本参数、运行状态和各种工作计划。
数据库的框架和结构必须根据设备和运行状态而设计，方便提供强大的录入、查询、统计、分析和报表等各种功能操作，较好的反映平台业务的基本情况和运行状况，满足平台的基本要求。
数据库表前缀：根据模块名定义（如用户模块：sys_）
说明：系统正式发布后，可能更改数据库用户/密码。
本系统主要利用java作为后端的应用开发工具，使用MySQL作为后台的数据库， Linux或Windows均可作为系统平台。
所有命名一定要具有描述性，杜绝一切拼音、或拼音英文混杂的命名方式。
字符集采用 UTF-8，请注意字符的转换。
所有数据表第一个字段都是系统内部使用主键列，自增字段，不可空，名称为：id，确保不把此字段暴露给最终用户。
除特别说明外，所有日期格式都采用date格式。
除特别说明外，所有字段默认都设置不充许为空， 需要设置默认值。
所有普通缩影的命名都是表名加设置缩影的字段名组合，例如用户表User中name字段设置普通所以，则缩影名称命名方式为user_name_index。
对本系统的开发者、使用这、测试员和维护人员，提出以下参考意见：
在使用数据库时，首先要参考上面的约定内容，做好软件的安装以及表格的建立。
数据库的输入统一采用键盘。对于数据库的使用权限，请参考本系统其他相关文档。
数据库的后台管理员没用等级差异，可根据实际情况添加删除管理员。
数据库系统：MySQL
命令行工具：mysql
注意：mysql 命令行环境下对中文支持不好，可能无法书写带有中文的 SQL 语句。
6.3.1 概念结构设计需求
概念数据库的设计是进行具体数据库设计的第一步，概念数据库设计的好坏直接影响到逻辑数据库的设计，影响到整个数据库的好坏。
我们已经得到了网系统的数据流程图和数据字典，现在就是要结合数据规范化的理论，用一种模型将用户的数据要求明确地表示出来。
概念数据库的设计应该极易于转换为逻辑数据库模式，又容易被用户所理解。概念数据库设计中最主要的就是采用实体-关系数据模型来确定数据库的结构。
数据是表达信息的一种重要的量化符号，是信息存在的一种重要形式。数据模型则是数据特征的一种抽象。它描述的是数据的共性，而不是描述个别的数据。
一般来说，数据模型包含两方面内容：
数据的静态特性：主要包括数据的基本结构、数据间的关系和数据之间的相互约束等特性;
数据的动态特性：主要包括对数据进行操作的方法。
在数据库系统设计中，建立反映客观信息的数据模型，是设计中最为重要的，也最基本的步骤之一。
数据模型是连接客观信息世界和数据库系统数据逻辑组织的桥梁，也是数据库设计人员与用户之间进行交流的共同基础。
概念数据库中采用的实体-关系模型，与传统的数据模型有所不同。实体-关系模型是面向现实世界，而不是面向实现方法的，它主要是用使用方便，因而在数据库系统应用的设计中，得到了广泛应用。
实体-关系模型可以用来说明数据库中实体的等级和属性。以下是实体-关系模型中的重要标识：
在数据库中存在的实体；
6.3.2 逻辑结构设计需求
项目结构实体、实体属性ER图如下：
用户权限实体、实体属性ER图如下：
进度计划权限实体、实体属性ER图如下：
6.3.3 物理结构设计需求
（1）定义数据库、表及字段的命名规范
数据库、表及字段的命名要遵守可读性原则；
数据库、表及字段的命名要遵守表意性原则；
数据库、表及字段的命名要遵守长名原则；
（2）选择合适的存储引擎
（3）为表中的字段选择合适的数据类型
6.4.1 表名的命名规范
表名以英文单词、单词缩写、简写、下划线构成，总长度要求小于30位。
6.4.2 表字段的命名规范
字段名以英文单词、单词缩写、简写、下划线构成，总长度要求不超过30位。
字段名以名词或名词短语，字段采用单数形式。若表名由多个单词组成，则取各个单词的缩写组成，单词缩写间使用下划线作为分隔
若某个字段是引用某个表的外键，则字段名应尽量与源表的字段名保持一致，一面混淆
6.5 安全保密设计需求
6.5.1 防止用户直接操作数据库的方法
通过把关键应用服务器和数据库服务器进行分离，防止用户对数据库服务器的直接操作，保证数据库安全。
6.5.2 应用系统的用户口令进行加密
在软件系统中，对于数据的保护、业务操作的许可是通过识别用户身份和权限来完成的。
用户口令相比较，相同的话系统将该用户的操作权限分配给用户，用户再根据所分配的权限对系统进行操作。
由以上过程可知，用户口令在传输过程中容易被窃取泄漏，另外如果数据库被非法进入则其中保存的口令能够被非法查看。
因此，在传输过程中和数据库中的口令记录字段不应使用明文传递和保存，应该在口令被传递前对其明文口令使用有效的主流技术对传输数据进行加密部分描述的加密算法进行加密，在加密后传输到系统。
系统将用户提交的经过加密的口令数据保存的加密口令进行比较，相一致则进行后续操作。通过以上措施和过程，证了加密口令即使被窃取仍无法得到原始口令。
6.5.3 对用户进行权限识别和分级
在集团建设智能管控平台中，不同的业务不同的人员处理，并且对于不同的操作人员其所能够访问的数据是不同的。
为了保障各功能模块的授权使用和数据不被非法访问，系统划分了不同的操作权限和数据读写等级。系统管理人员可以方便、灵活的将这些权限登记分配给某一个或某一类用户。
当用户登陆时，系统在用户身份验证通过后取得用户的权限，根据用户权限显示相应的功能菜单。
当用户对数据进行读、写、删除后浏览操作时，系统判断用户对该数据的访问权限确定是否允许该操作的执行。

平台支持不低于400个在建工地的数据汇集和分析计算，系统应满足如下技术指标：
统除支持一般结构性事务数据外，还需要支持主要二三维地理信息格式（shp、tiff、dem、3ds、max等），支持GPS、GLONASS、北斗等卫星定位数据，主要视频协议的接入。
系统对GIS数据的支持能力不小于20TB；对图片、视频等非结构化数据的支持能力不小于200TB；对结构化数据的存储和查询数据量支持能力不小于500GB。
1.3 数据库性能要求
根据本系统数据的特点，采用标准MYSQL语句，以便将来的扩展和移植。
系统将采用数据库建模工具，根据系统功能模块的设计，构建出整个数据库。在构建数据库时，也会定义好数据库表的约束、关联以及索引。
针对系统的具体特点和系统要求，我们在进行数据库方案设计时对数据库平台提出下列性能方面的要求：
标准化程度高，符合标准ANSI SQL 92语言的规范；
支持对称处理和多线程技术，支持XML/CORBA，支持数据分区；
可在多种操作系统，HP、IBM等服务器下运行，独立性强，对系统结构影响比较小；
高级语言、汉化功能先进，易于方便使用，支持汉字，GB18030标准；
能支持同构、异构网络分布操作，支持松散耦合及海量并行处理；
有足够的并发控制，授权控制和事务处理能力及恢复能力；
与异种数据源有良好的可互操作性；
具有可靠的数据安全保密措施以及故障恢复能力；
具有SMP和MPP功能，具有快速的并发用户查询速度，并发控制稳定可靠；
具有很强的容错能力，错误恢复能力，错误记录及预警能力，具备异地容灾能力；
允许行级锁，具有死锁自动解出功能而无需额外的数据一致性校验；
具有强大的复制能力，支持主从式、级连式、对等式以及N-向复制，并支持复制日志技术，具有分布式模式管理能力；
具有完整的安全性（帐号安全，系统级权限，对象安全性，审查等），细粒度化的访问控制，适合于多层环境的安全模式的能力；
拥有支持MIS的功能强大的开发工具，提供数据仓库和数据挖掘的工具。

数据库支持超过500个用户的并发访问能力。
管理端平台具备不少于100个访问并发的能力。
系统业务功能包括附件和图片的传输的时候，需提供稳定快网速的传输效率，以及支持多附件多图片并发上传和下载的能力。

一般数据查询响应时间3.2 制表速度
一般固定表格制表不超过10秒钟，复杂统计汇集表格不超过5分钟。

系统需提供7*24的不间断服务。
系统需合理的利用资源，保证前后台数据操作的效率，以及在数据响应和界面承载方面都要达到不会出现界面混乱、数据报错、触发按钮功能缺失、操作频繁或者快速容易崩溃的问题。
前端方面具有兼容各大主流浏览器的能力。
PC端前端自适应方面具有能够适配主流笔记本、台式电脑的能力，手机APP能够适应主流手机屏幕尺寸。
系统应便于新业务或者新功能的生成和实现第三方系统与平台的连接。另外系统提供动态页面定制组件，能够有效的帮助运营方生成产品和服务表单，方便管理人员扩充分类目录等信息，并在权限管理、用户管理上有高度的灵活性、合理性。
通过详细信息资料的方式确保用户身份的可靠性，线上实施管理操作时，需确认用户的身份。为了防止操作失误，应该将用户的操作过程信息以日志形式保存，以作为失误诊断的原始依据。
保证已有平台和系统的兼容性及对未来发展的适应性，使系统可在原有的基础升级改造和更新，并应当充分考虑技术进步因素的影响。
平台不是一个封闭的系统，今后必须通过接口和其他平台或系统相连，在平台建设中应充分考虑与外界信息系统交换的需求，保证既能满足基本功能的需要，有具有与外界系统进行信息交换与处理的能力。
要求在不用修改系统架构的情况下，通过增加或增强相应的设备即可实现系统功能的扩展支持，包括垂直扩展和水平扩展。
能够通过增加硬件资源提高目标平均性能和峰值性能（即响应时间、延迟等）及目标平均负荷和峰值负荷（即并发用户、信息量等）。
能够通过增加应用服务器及实现应用服务器负载均衡、多节点等措施提高目标平均性能和峰值性能（即响应时间、延迟等）及目标平均负荷和峰值负荷（即并发用户、信息量等）。
系统应符合开放的原则，充分考虑各种业务需求有机结合，建立完善的系统整体构架，可与外部系统进行通讯并可提供标准的接口。既能实现业主业务，还可以完成数据交换、信息共享功能。
系统应具备高性价比，能对系统资源的使用进行优化，在实现系统功能的前提下，尽量节省硬件资源的开销。
主要体现在能够通过冗余措施加以保证，具体包括线路冗余、设备备份措施；
能够在外网与Internet互连区采用安全可靠的防火墙；
能够建立完整的网络防毒机制，以及建立严格完善的防毒管理规范；
能够确保必须的网络服务的安全和可靠性。如DNS；对其它网络基本服务，限制使用范围，建立严格的使用管理规定，防止被黑客利用，绝对禁止匿名FTP服务，对需要使用又必须保证安全的场合，要经过身份认证、访问授权和审计记录机制的控制；
能够在Internet互联区域及与内网互连区域设置防火墙。并采用防黑客攻击软件实现安全漏洞的扫描，结合系统管理及时修补安全漏洞；提供网络实时入侵检测，在一定程度上实现对内网与外网的入侵阻隔；做好攻击的跟踪审计；
能够防止网站数据被非法篡改，并且在被篡改之后能够及时的恢复。
项目实施以提供业务支持为首要因素。应从业务实际需要出发，选择重点与关键的环节进行信息化管理与控制，在信息化价值和灵活性、管理工作量之间取得良好的平衡，保证在系统实施后能提高工作效率、降低成本。
系统具有良好的集成性，对流程审批、数据获取、信息集成等功能提供标准接口，以实现与其他相关系统的功能和数据集成。
系统可以统一各个层次管理规范，统一数据结构、数据表达方式、数据访问方式。
系统须提供通用的组件支持，能够减少重复开发工作，保证产品和项目的质量，缩短应用系统的开发周期，有利于系统的扩展。在统一的数据环境下集成化开发各个模块，模块的划分应独立于当前的组织机构，各个模块之间的数据交换是结构化的、公用的，从而也是高效的和完整的，最大限度消除冗余和不一致。
方案和产品的架构须紧密跟踪国家信息安全、业主标准和国际主流技术标准，开放性好，便于系统的升级维护、以及与各种信息系统进行集成。
系统规划和设计理念可对照现有技术先进、成熟的产品，提高用户体验，以减少系统开发的周期和成本；功能定位充分考虑平台服务对象的需求。

采用全屏网页设计，扁平化、视差化的化繁为简的设计思维，让整个网站的整体性、统一性、灵活性、自适应性、流畅性得到了相对的提高，也使得平台的功能处理和管理能力在这些特点的加持之下得到综合性的展示。
主题色值：深蓝、白、黑；
协调色值：灰、天蓝、红；
文本色值：浅黑、天蓝、红；
按钮色值：天蓝、草绿、灰；
在合理的布局下尽可能多的显示控件内的内容。
按照操作流程或浏览顺序自左至右、由上而下的排放各种控件，使界面整体协调、简洁、美观大方。
1.1.6 自适应父对象的尺寸改变
控件应具有自适应父对象的尺寸改变的能力，当父对象的尺寸发生变化时，控件应能自动改变自己的尺寸并使界面保持整体协调，尽量减少因父对象的尺寸改变而带来的操作或浏览上的不便。
考虑安全的问题，以供系统内部调用的接口。
硬件接口是软件所使用硬件设备的基本需求，在这里平台支持打印功能，应有对接相关打印设备的需求。
平台可以对接其他软件系统外放的接口，以此来获得相关功能模块所需的数据信息，需要对接的软件系统分别为工程管理（XX）、隐患排查系统、项目跟踪管理系统（CRM）、视频监控管理系统等。
有系统系统、有导入导出需求用户的基本需求。
遵循TCP/IP通信协议接口，要求开发人员使用规定的通讯接口，有协同系统的通讯标准需求，至少能够支持用手机信息进行互动的通讯方式。
需要有完善的监控系统、可以对网络，服务器CPU、负载、IO、内存、连接数（文件句柄数）以及应用系统性能、异常日志进行全面访问。
需要有分析问题发生的根源能力，思考是否对网络、硬件、应用进行升级，或者超过系统的承载量导致问题的发生。
需要在故障发生之后有尽快处理问题的效率，不仅能够恢复系统的正常运行，而且可以降低因系统故障对平台造成的损失。
恢复应急过程中可以对系统进行临时性的改变，用简单的方式尽快的采取补救的措施，从而降低对用户的影响。
分析问题的发生原因，该如何解决，怎么避免问题再次发生，并做好此次故障发生之前的预防错失。
对问题发生的原因，避免方法采取行动、执行相应的措施。
浏览器：国内主流浏览器，比如Google chrome、火狐浏览器、360安全/极速浏览器、QQ浏览器、IE10以上的版本浏览器等。

以第一章引言中参考资料所列出的文档内容为基础，结合XXXXXXX管理平台高保真原型（UE、UI）设计，根据这篇需求分析文档记录的内容为接引，从而来进行研发工作的推进，并以这篇文档为基础，通过全面性的论述来理清平台的需求，从而为以后项目的实际实施（研发和测试）提供可靠的依据或者参考。