DL/T 1731-2017 电力信息系统......

  • DL/T 1731-2017  电力信息系统......为pdf格式
  • 文件大小:8.2M
  • 下载速度:极速
  • 文件评级
  • 更新时间:2020-01-07
  • 发 布 人: 13648167612
  • 原始文件下载:
  • 原始文件是会员上传的无错版,推荐下载这个版本

  • 电力弱电,pdf格式,下载需要20积分
  • 立即下载

  • word版文件下载:
  • 特别提醒:word版是本站通过人工智能从pdf转换成的word版本,正确率只有90%左右(正在通过训练继续提高准确率),排版恢复的也并不完全准确,没有进行任何人工校对,VIP会员直接免费下载即可,普通会员无法通过点数下载,算是给VIP的活动。

    特别提醒:word版是不完美的,错误较多,只能参考,有需要的可以少打一些字,别下载了找我们说word内容有问题,这是送给VIP会员的。

  • 文档部分内容预览:
  • DL/T 1731-2017  电力信息系统非功能性需求规范

    6.1.5服务器内存利用率

    信息系统应用服务器和数据库服务器在需求规格说明书明确的内存最低配置或推荐配置下, 发用户数持续运行2小时,或40%的最大并发用户数持续运行8小时,运行过程中系统平稳 现内存泄漏。内存利用率指标要求见附录A。

    6.2.1.1信息系统在需求分析阶段宜明确系统运行所需依赖的硬件基准环境以及系统的适用范 围,对于多层结构的软件系统来说,宜分别说明其服务器端、客户端以及网络所需的环境以及所 需要支撑的软件环境(包括数据库、中间件、操作系统及客户端浏览器),软件环境宜明确软件 版本号信息。 6.2.1.2信息系统宜根据面对的客户情况,提供多语言和多币种支持。 6.2.1.3信息系统在指定的运行环境中,系统全部设计功能宜能够完整地实现

    6.2.2.1当用户或维护者按照 提供的安装向导或安装步骤进行安装操作时,宜能成功实现 安装。安装软件应正确处理安装过程中所出现的失败现象(如无法安装某些DLL)工程质量标准规范范本,不宜使系统处于某 个不确定的状态(如软件只安装了一部分或造成错误的系统配置)。 6.2.2.2宜保证用户或维护者能够从运行环境中成功卸载软件

    .3.1信息系统在需求分析阶段宜陈述系统运行时与其他软件的共存性约束。 .3.2信息系统在运行环境中加载其他应用程序或修复、升级操作系统时,宜保证信息系统功能 整地实现。

    信息系统在支撑的软件环境(包括数据库、中间件、操作系统及客户端浏览器)版本升级或 换时,系统数据宜能连续使用不丢失,被替代的软件中的类似功能仍然完整实现。

    6.3.1.1软件配置项的各项功能宜容易被识别,信息系统功能描述宜容易被用户理解,信息系统界面元 素宜使用简洁文字或提供“帮助框”“工具条”。 6.3.1.2信息系统中要求具有演示能力的功能,宜确保演示容易被访问,且演示充分和有效。 6.3.1.3信息系统运行参数宜提供图形化配置功能,不宜通过直接编辑数据库、配置文件或注册表等方 法进行参数配置。 6.3.1.4信息系统输入输出提示信息宜简洁明确,易于理解。 6.3.1.5信息系统数据在转换过程中,宜采用通用的标准格式,宜考虑相关的不同系统和不同应用的格 式需求

    DL/T17312017

    6.3.2.1信息系统宜提供在线帮助,且在线帮助容易定位和有效。 6.3.2.2信息系统宜在开发过程中编制准确和完整的文档,包含信息系统的需求分析、架构设计、概要 设计、详细设计、维护手册等。 6.3.2.3信息系统宜提供配置的详细说明文档,描述每项系统配置的作用、影响等。

    6.3.4.1信息系统宜对界面色调进行统一,界面色彩宜控制在3种以下,如涉及地图、电子商务类相关 系统界面色彩宜控制在5种以下,且每种颜色的业务含义在同一系统中宜统一。 6.3.4.2信息系统界面设计配色宜遵循对比原则,在浅色背景上使用深色文字,深色背景上使用浅色文 字;尽量将“红色”“橙色”等具有告警特征的颜色预留给系统告警功能和强制性提示功能,避免滥用 告警色。 6.3.4.3信息系统宜使用统一字体,字体标准的选择依据操作系统类型决定。所有控件尽量使用大小统 的字体属性,除了特殊提示信息、加强显示等例外情况。建议使用通用字体,避免用户因操作系统 字体字库不全而影响应用。 6.3.4.4信息系统的操作界面宜标识出必填的输入信息。通常的出错处理包含“提交前处理一前端处 理”和“提交后处理一后台处理”两种模式,宜使用前端处理模式,在有填写错误时,使用焦点离开 事件触发错误提示。 6.3.4.5信息系统在后端出错及异常提示后返回原界面时,宜保留原界面中用户已经填写的内容,防止 界面信息丢失、用户重新填写。对提交后出错或异常状态系统宜给予用户一个友好的提示和帮助,并 将界面控制焦点置于发生错误的控件对象上,将用户在该界面中所有的填写异常信息完整提示,避免 多次提交失败。 6.3.4.6信息系统中所有提示信息宜使用用户可以读懂的业务语言,不宜在出错/异常提示中出现用户 看不懂的开发专业术语。

    6.4.1.1信息系统宜具备在规定时间内不间断工作的能力、具备避免因信息系统出现故障导致失效的能 力,在网络出现局部中断的情况下,仍能保持信息系统服务持续稳定。 6.4.1.2敏感数据或可用性要求高的数据在传输时不宜采用UDP协议,宜采用TCP协议传输,同时具 备断线重传功能确保其可用性。

    6.4.2.1信息系统宜在输入错误数据或进行错误操作时不崩溃、不异常退出也不丢失数据。 6.4.2.2多机系统在出现故障需要切换时宜保证系统的功能和性能的连续平稳性。 6.4.2.3信息系统在出错时,宜正确提示异常信息。异常信息宜包含针对开发和维护人员调试使用的系 统信息。 6.4.2.4信息系统发生异常时,宜向外部服务或应用程序的客户发送通用的信息或重定向到特定应用网 页,不宜暴露可能导致信息泄露的消息。不宜暴露包括函数名以及调试内部版本时出问题的行数的堆 栈跟踪详细信息。 6.4.2.5信息系统发生异常时,宜终止当前业务,并对当前业务进行回滚操作,保证业务的完整性和有

    ,不宜暴露可能导致信息泄露的消息。不宜暴露包括函数名以及调试内部版本时出问题的行数 眼踪详细信息。 2.5信息系统发生异常时,宜终止当前业务,并对当前业务进行回滚操作,保证业务的完整性 性,必要时可以注销当前用户会话

    6.4.3.1信息系统在出现系统异常(如网络不通、服务器机)时,宜可捕获异常,并提供友好的信息 提示,系统恢复后宜能够保证业务和数据的完整性。 6.4.3.2信息系统在出现服务器断电时宜具备数据保留能力,当系统恢复后宜能够保证业务和数据的完 整性。 6.4.3.3信息系统宜提供完善的业务异常处理机制。异常描述宜清晰、规范。保证数据的一致性和完整 性。系统在运行过程中所发生的错误应该有明确的错误编号,并能在系统的相应维护手册中查到错误 的发生原理与处理步骤。 6.4.3.4宜保证具有自动修复功能的信息系统能在规定时间内实现自动修复,保障信息系统的可用性。 6.4.3.5信息系统数据及配置信息宜可备份可恢复,针对不同信息系统级别采取本地备份或异地备份策 略。备份和恢复应当高效并支持增量备份和恢复。如有灾备系统,宜满足附录A的时间恢复目标、恢 复点目标要求。

    6.5.1.1信息系统的软件架构宜层次分明、功能清晰。 6.5.1.2 信息系统开发过程中宜使用业界标准的框架模式。 6.5.1.3信息系统的部署架构应进行分层设计。 6.5.1.4信息系统宜提供多种日志类型的记录,包括系统运行日志、错误日志、登录日志、调试日志 6.5.1.5程序发生异常时,宜在日志中记录详细的错误消息,便于维护者查找失效的原因。 6.5.1.6信息系统宜支持日志开关配置,在需要调试的时候由运行维护人员决定是否开启日志,调试 志宜把执行的SQL语句的执行时间、所用时长、执行结果写到日志文件中。

    6.5.2.1信息系统架构宜遵循易配置性,在软件维护过程中仅需通过简单配置即可满足系统修改需求。 6.5.2.2信息系统宜遵循结构化设计主要原则,即模块化、信息隐蔽、高内聚、低耦合。 6.5.2.3信息系统宜梳理提取代码公共部分并独立成公共模板,以提高系统的代码复用性,降低代码修 改工作量。 6.5.2.4信息系统宜保持代码风格的一致性,并提供准确和详细的代码注释,为系统后续修改提供便 利,涉及规格说明和程序模块的修改,宜在代码的注释行中充分记录下来。 6.5.2.5信息系统宜保持函数与对象的封闭性,以保证将来针对函数及对象的内部修改不会影响整 个程序。 6.5.2.6信息系统宜使用面向对象的设计方法,提高系统的重用性、灵活性和扩展性,为后期修改预留 充足的编码空间,在系统升级或迁移后原有数据能够继续使用。

    6.5.3.1信息系统宜提供数据校验机制(数据类型、长度、字符格式等)和多层校验机制(支持在服务 器端和客户端同时进行数据校验),信息系统宜尽量在客户端实现数据校验功能,减小服务器压力。 6.5.3.2信息系统需要有内置测试功能的,宜保证内置测试功能完整和有效。 6.5.3.3信息系统采集或输入数据后,宜提供图形界面对数据的格式进行验证,以确保其可用性。 6.5.3.4信息系统输入输出提示信息宜简洁明确,易于理解。信息系统宜根据要求显示所有的输入,并 以清楚的描述方式说明系统的输出。 6.5.3.5信息系统宜支持业界主流测试工具。

    6.6.1信息系统监控要习

    6.6.1.1信息系统宜具备开放的监控功能或接口,如已具备统一的监控系统,宜在上线过程中完成 与监控系统的接口部署和数据贯通。需求分析阶段宜明确信息系统需接入监控的应用指标和运行指 标信息。 6.6.1.2信息系统运行指标宜包括系统运行的稳定性、可靠性等方面。 6.6.1.3信息系统应用指标宜根据信息系统业务应用的专业领域不同,选取能够准确反映应用状况 的指标。

    6.6.2.1信息系统宜针对系统运行及系统故障等事件具 总进行刀 类,有选择性地通知到用户或信息系统运维人员。信息系统宜在需求规格说明书中明确应该主动生成 完备告警信息的事件信息。 6.6.2.2信息系统宜针对告警信息的重要与紧急级别进行定义。 6623生愁的内容宜至小包含告整来源、告警标题、告警级别、告警时间等信息

    7信息系统非功能性需求指标要求

    本规范中信息系统非功能性需求指标要求属于一般性要求,可根据信息系统特点进行裁剪,如需

    特别说明的,应在系统需求规格说明书中说明。

    7.2信息系统非功能性需求指标表

    7.2.1信息系统非功能性需求指标字段

    信息系统非功能性需求指标主要包含以下字段: a)指标分类(描述信息系统非功能性需求指标所属分类,包括一级分类与二级分类); b)指标名称(描述信息系统非功能性需求指标的名称); c)指标目的(对指标评价的目的进行描述); d)指标描述(对评价指标的内容进行解释性描述); e)评价方法(对评价指标的评分计算方法进行描述); f)指标要求(对信息系统非功能性需求指标应达到的目标值进行描述); g)指标等级(对指标的等级进行描述,强制性指标为应满足指标,评价性指标为推荐满足 指标); h)参考评价阶段(对指标评价应处的阶段进行描述,主要包含可研评审、概设评审及测试确认三 个阶段)。

    7.2.2信息系统非功能性需求指标评价

    工程施工数据7.2.2.2如未满足相关指标要求

    2.1信息系统在建设各个阶段应结 统非功能性需求指标进行测试评价工作, 2.2.2如未满足相关指标要求

    DL/T17312017

    DL/T17312017

    DL/T17312017

    建筑造价、预算、定额DL/T17312017

    DL/T1731—2017

    DL/T 1731—2017

    ....
  • 电力标准
  • 相关专题: 电力  
专题: 螺丝标准 |公路工程 |城镇建设标准 |国家标准 |纸箱标准 |

常用软件