职教软件开发管理
1. 总体建设
新一代互联网、云计算、卫星定位、地理信息系统……借助这些新技术体系正在改变着城市管理的传统模式。
职教软件信息化项目流程管理是贯穿于具体某个职教软件信息化项目的全部阶段,将项目前期工作阶段与后期项目完成阶段所有流程进行闭环管理,将项目整体实施过程进行规范化、全面化的管控,实现各个具体项目的完整管理。
全国各地职教信息化项目建设的主要发展目标是促进整个各地区教学更便捷、快速的运行。在具体信息化建设项目过程中,科技方法与整体项目的软件涉及、流程管理是不可分割的,在各类相关建设领域引导业务人员进行高效的信息化协同。
职教软件信息化项目通过招标方式,甲乙双方进一步明确相关软件设计管理,通过本项目我司总结了以下软件设计管理经验:
2. 软件开发
2.1 系统总体设计
2.1.1 系统技术路线
我司基于通过采购单位现有自主知识产权教学应用软件系统(B/S架构、本地化部署,包含教学服务大厅、教学互动平台、教学保障管理系统、教室设备集中管控平台、教学服务终端管理系统、教学巡视督导系统、教学指挥中心系统、教学数据资源管理系统、教学基础支撑平台)进行二次开发,采用我司底层研发平台支撑二次开发。
系统整体采用B/S架构,实现目标需求开发。
2.1.2 系统优越性
我司微服务系统平台的技术架构采用的B/S架构,自下而上分为六层,分别为系统层、数据层、平台层、服务层、应用层和表现层,如图:
图2- 1综合管理一体化平台技术架构
网络层:主要包含硬件平台、网络平台、系统软件平台、各类网络协议。
数据层:数据层包括关系型数据库和非关系型数据库,关系型数据库支持Oracle、SQL server数据库,非关系数据库支持FastDFS、MongoDB等,关系型数据库存储收发文的来源、类别,项目的项目基本信息、审批信息,门户系统的组织、岗位、用户等结构化信息,非关系型数据库存储收发文的附件内容、图标文件、培训材料、会议材料等非结构化的信息。本项目推荐采用Oracle和FastDFS进行数据存储。
平台层:提供基础技术、微服务技术、分布式技术、通用基础平台等。其中,基础技术包括SpringMvc控制器,事务管理Spring4,日志技术Logback,认证授权技术Shiro; 微服务采用SpringCloud架构,微服务注册中心使用Zookeeper,微服务技术使用了RESTEasy,RESTEasy提供一套完整的框架帮助开发人员构建RESTful Web Service和RESTful Java应用程序,微服务网关采用Zuul。分布式技术包括分布式事务LCN,消息队列Kafaka,缓存技术Redis,分布式存储采用FastDFS。通用平台服务包括容器技术Docker,容器编排Kubernetes,开发运维一体化DevOps。
服务层:主要包含多应用管理、多组织管理、流程管控中心、角色集中管理、权限控制集中管理、统一用户管理、统一报表中心,以及流程引擎、搜索引擎、表单管理、文件管理、三员管理、待办服务、数据权限管理、安全管理、缓存管理、文档转换、数据迁移、数据同步等。
应用层:提供需求管理、项目管理、质量管理、配置管理应用功能。
表现层:主要包含角色化门户展示,采用多种web技术,支持PC端多种浏览器内核。
集成组件:根据实际情况,数据集成可选用的方式有http、JDBC/ODBC、数据视图、RESTful、Webservice、Micro-service等。
2.1.3 系统平台优势
平台基于微内核、组件化、服务化的架构设计思想构建。平台微内核架构的核心系统提供系统运行所需的最小功能集,其它功能通过组件化机制向核心系统添加额外的功能,保证了功能的独立和分离,极大地提升了系统的可扩展。平台通过Web Service、Restful、MQTT等服务/消息适配技术,可以跟第三方系统以及大数据平台、移动开发平台、物联网平台快速集成,大大提升了平台的集成能力和新技术的适配能力。
面向业务应用的快速开发,适应业务随需而变
平台提供了完善的基础功能、丰富的应用模板、可视化拖拽开发、开箱即用的技术组件、完善开发规范和技术支持服务,快速构建应用系统,从而适应客户不断变化的需求。
基于组件化思想,实现软件资产积累和复用
通过组件化研发,可逐步积累和沉淀客户软件组件库,形成组件化模式下可灵活组装和配置的模块,能够按需进行灵活装配,快速构建客户应用。
多应用共享平台,实现基础资源统一管理
基于多个应用共享一个平台的机制,一个客户只需部署一个平台,满足客户统一技术平台的需求,实现基础资源的统一管理,简化多个应用系统重复管理的繁琐。
具备强大的系统集成能力,满足多层次集成需求
平台提供了多层次的集成体系规范和相关系统,支持应用系统间的界面集成、流程集成、服务集成、数据集成。
采用多种安全机制,符合安全保密要求
平台内置了防SQL注入、XSS注入的等OWASP十大攻击技术手段,还提供了日志审计、三员管理等BMB17和BMB20规定的安全保密功能。
支撑集群分布式部署,满足高可用高性能要求
基于组件化服务化的架构技术,支持应用系统横向扩展部署,满足高可用需求,也支持按照业务组件分布式部署,满足高性能需求。
支撑多种异构环境部署,提升系统的兼容性
平台不仅支持多种主流操作系统(Windows、Linux、AIX等)、WEB中间件(Tomcat、Web Sphere等),数据库(Oracle、MySql等)的部署,还支持IT国产环境的部署。
完全自主开发、安全自主可控
平台代码完全自主开发,而且支持大部分国产化软硬件运行,包括国产化龙芯芯片、中标麒麟操作系统、东方通WEB中间件、达梦数据库等。
2.1.3.1 系统平台安全保障技术
我司二次开发各系统业务时设计和实现遵照《涉及国家秘密的信息系统分级保护技术要求》,并满足国家有关保密管理要求,所有信息系统均具有三员管理功能。
2.1.3.2 安全机制
二次开发的系统采用多种安全机制,符合安全保密要求。按照系统非功能需求中对安全的要求,平台从网络传输、系统安全、数据安全等多个维度进行安全设计,安全设计是充分考虑到系统安全风险及用户安全需求的前提下,对系统安全进行的总体性设计。通过系统安全设计,为用户提供安全、可靠的应用系统,避免系统使用过程中由于风险造成的损失。
图2- 2平台安全标准
系统安全体系采用通过由外到内的安全策略,实现对于系统核心信息数据的保护,为保证整个系统的安全,对于系统的安全保密防范措施,进行了如下设计,总体安全设计如下图所示:
图2- 3安全设计框架
每一项安全保密方案设计的具体功能如下表所示:
序号 | 保密方案 | 功能描述 |
1 | 系统密标设计 | 用于管理系统中涉密信息,采取严格的管理流程手段对涉密数据定级、发布范围确认进行审批 |
2 | 强身份鉴别设计 | 用户鉴别用户身份,通过系统口令设计,实现对用户身份的识别,保障系统安全 |
3 | 访问控制设计 | 用于管理数据的访问权限,实现涉密数据的分类分级访问控制和非密数据的分类访问控制 |
4 | 数据输入输出控制设计 | 在系统层面对相关数据的输入输出进行安全设计,保证数据的安全合法性 |
5 | 数据完整性设计 | 确保数据库关联信息的齐全,防止误操作导致的数据链条断链 |
6 | 系统三权分离设计 | 按照标准的安全保密方案设计了系统三员管理方式,通过三者权限的互相制约,实现三权分离,并实现系统分级三员的管理 |
7 | 安全审计设计 | 用于审计系统中用户的操作日志 |
8 | 抗抵赖性和完整性设计 | 保证系统关键信息在流动时安全可靠,引入操作审计方式,保障信息的抗抵赖性和完整性 |
9 | 备份与恢复措施 | 为应对数据库系统出现问题,对系统进行备份和恢复措施,以降低风险 |
数据层安全主要有数据库管理安全和数据加密存储安全,数据库管理安全依赖数据库软件,以及对数据库日常的管理维护。数据加密存储安全基于 128位 AES 加密算法,给关键信息提供加密手段。在数据加密时,我们调用了AES做加密,也可以和国密算法做集成。
在数据传输层,采用 https 传输加密技术保证数据在网络的传输安全,这一层次的防护采用 Web 中间件的功能。
图2- 4系统安全设计原理图
对于涉密数据而言,系统在数据输出时进行严格的控制。
对于基于网络传输的方式,为保证涉密信息的安全,采用加密技术进行加密,保证数据的安全性。本系统采用SSL协议加密保护,通过与第三方支持SSL协议的软件集成,实现涉密数据在网络传输时的安全控制。
对于涉密数据的物理导出,如保存为本地文档的管理,系统将导出功能授权给特定的用户,在导出时经由相关领导进行审批,审批通过后方可进行导出操作。系统将会对用户的导出操作进行记录,由安全审计员进行审计。
平台支持和CA软件做集成,且已经实现了与格尔的完整集成。CA是负责签发证书、认证证书、管理已颁发证书的机关。它要制定政策和具体步骤来验证、识别用户身份,并对用户证书进行签名,以确保证书持有者的身份和公钥的拥有权,基于CA技术的数字签名技术保证了用户身份的真实性与业务数据的保密性。
平台用户信息均包括密级属性,密级等级为:非涉密人员、一般涉密人员、重点涉密人员、核心涉密人员。用户密级与业务数据密级存在约束关系,即低密级用户不能访问高密级数据及文件,不能参与高密级流程审批等,只有用户密级与数据密级符合,才有权限进行访问。平台提供人员文档密级配置功能,根据业务场景实时进行配置。
图2- 5密级属性配置
为了满足 BMB17、BMB21 保密安全管理规定,系统采用的身份识别方式为系统口令鉴别。用户名/口令是最简单的身份鉴别方式,采用用户名+口令的方式进行用户身份的确认,这种方式是公司任何一个软件系统都必须提供的方式。为了最大化保证用户口令的安全性,系统对口令采用口令限制和鉴别处理进行管理。在采用用户名/口令方式时,在用户口令的数据库设计中口令不能明文保存,采用单向(不可逆)的 MD5+SALT 加密算法。
图2- 6用户密级属性配置
同时提供密码配置管理,确保不同的密级类型可以设置不同等级的密码配置规则。其规则包括:
密码差异度:新旧口令至少有4位差别,可逐个字符匹配校验;
密码最大长度:规定密码的最大长度;
密码最小长度:规定密码的最小长度;
密码多少天需要修改一次:规定修改密码的频率,需要多少天修改一次;
默认密码几天修改:规定在系统初始化用户以后,规定用户在多长时间内要修改系统的初始密码;
密码到期多少天前提示:设置密码到期前多少天进行消息提示;
密码配置管理要实现对不同密级分类建立不同密码模板的基本操作(添加、编辑、删除)以及各配置的启用以及停用的功能控制。
用户登录错误几次密码锁定:若用户连续登录错误,并且次数达到设置的次数,系统会自动锁定用户。提示用户联系管理员进行解锁操作;
密码强度:规定设置的密码格式,包括大写字母、小写字母、数字、特殊字符4种,密码强度最高为4级,最低为1级;
密码不能和以前多少次密码重复:重新设置的密码不能和以前多少次的密码重复;
图2- 7用户密码模板配置
平台提供IP白名单功能,主要用来实现对系统的访问控制,系统可根据不同的访问策略设置访问(禁止)系统的 IP 范围,同时也可以对具体的某个人设置可访问(禁止)系统的 IP 范围。其中 IP 类型可以是一个具体的 IP 点,也可以是若干个 IP 段。用户 IP 限制管理实现对系统或者是个人设置访问(禁止访问)系统操作(添加、编辑、删除、查询)的功能控制。
平台的三员管理中实现了系统管理权限的三权分立,相互制约,相互监督。系统默认不启动三员管理功能。当系统启动三员管理时,对于设置角色的权限,以及角色分配用户的授权功能,只有当三员同时登录时,安全管理员才能够修改相关角色的功能权限。系统管理员:该角色的职责是管理整个系统,比如添加用户、修改通用代码等。该角色产生的日志类型为系统管理日志,接受安全管理员和安全审计员的审计和监督。安全管理员:该角色的职责是负责系统的安全管理,比如资源授权,角色管理等;并有权审计系统管理日志和安全审计日志,实现监督系统管理员和安全审计员的系统操作行为。该角色产生的日志类型为安全管理日志,接受安全审计员的审计和监督。安全审计员:该角色的职责是只有审计安全管理日志和系统管理日志,实现监督系统管理员和安全管理员的系统操作行为。该角色产生的日志类型为安全审计日志,接受安全管理员的审计和监督。其他角色:产生业务操作日志,接受系统管理员的审计和监督。
图2- 8三员权限图
平台提供了三种附件存储的方式:磁盘、数据库和文件分布式存储(FastDFS)。其中,使用磁盘、数据库存储附件时,可通过参数设置实现对附件进行加密存储。存储附件的方式如下:
类型一:使用电子表单开发的业务模块,在表单设计器的文件上传控件中选择存储类型及是否允许加密存储。
图2- 9电子表单附件加密存储配置
类型二:使用代码生成器开发的业务模块,在表单添加、编辑、详细页面,附件初始化参数中,添加 saveType 和 allowEncry。其中,saveType 参数值为:DataBase、Disk、Fastfds。allowEncry 参数值为:false、true。
图2- 10代码生成器加密存储配置
类型三:更改系统的附件存储方式,打开 uploader-ext.js 文件,更改 saveType、allowEncry 参数。其中,saveType 参数值为:DataBase、Disk、Fastfds。默认值 DataBase。allowEncry参数值为:false、true。默认值为 true。注意:当在表单页面设置 saveType 和 allowEncry 参数时,表单设置的参数优先级最高,当表单页面未设置该参数时,附件存储位置和是否加密读取的是 uploader-ext.js 文件内容。
图2- 11附件参数配置
2.1.3.3 三员管理
平台提供多组织应用管理,可满足院所两级组织机构分级管理、分级授权,三员分院所两级设置的需求。每一个组织应用拥有独立的角色、岗位、部门、菜单、权限资源等,每个组织应用具有独立的三员。
多组织应用的核心设计理念是多个组织机构的用户共享一个应用和平台实例,通过数据和权限的隔离,来实现不同组织应用的用户使用平台服务,如登录认证服务、权限管理服务、日志服务等其他业务服务。
由于多组织应用的定制化特点,院所内各组织部门有不同的权限集合,此外各个组织的架构和管理方式也不尽相同,组织内部用户的授权策略也是不相同的。因此多组织应用首先要实现为每一个组织应用分配适合的权限集合,保证各个组织能够实施规范化管理和配置。
平台权限授权体系中,通过不同维度的权限并集与拒绝优先策略保证了资源授权的灵活性。通过平台的天然特性,在多组织应用中通过角色间接映射到组织用户的权限集合中,从而实现对系统资源的访问控制。组织应用内部拥有独立的三员角色集合,组织应用内的三员管理员能够完成系统内部的授权和角色定义,从而实现各个组织应用之间的独立性,且保证了整个院所权限管理的灵活性。
平台的三员管理中实现了系统管理权限的三权分立,相互制约,相互监督。三员包括:系统管理员、安全管理员、安全审计员,三员职责分配图如下:
图2- 12三员职责划分图
其中系统管理员主要负责系统的日常运行维护工作,包括维护、运行、管理整个系统,系统的用户增加或删除,系统的数据备份,接受安全管理员的审计和监督。
安全管理员主要负责系统的日常安全保密管理工作,包括系统用户权限的授予与撤销;用户操作行为的安全设计,安全保密设备管理,系统安全事件的审计、分析和处理,应急条件下的安全恢复,审计系统管理员管理平台时产生的日志,监督系统管理员的管理行为,同时审计安全审计员的管理操作,监督安全审计员的管理行为,管理平台系统权限,对平台的系统权限进行授权,接受安全审计员的审计和监督。
安全审计员主要负责对系统管理员和安全管理员的操作行为进行审计跟踪、分析和监督检查,及时发现违规行为,并定期向系统安全保密管理机构汇报情况,审计安全管理员管理平台时产生的日志,监督安全管理员的管理行为。接受安全管理员的审计和监督。
当系统启动三员管理时,对于设置角色的权限,以及角色分配用户的授权功能,只有当三员同时登录时,安全管理员才能够修改相关角色的功能权限。为了防止系统管理员通过密码重置功能,重置三员的密码,然后以默认密码通过三员登录的方式扩大自己所属的权限,平台通过如下策略限制此种情况的方式。三员同时登录时,平台会校验三员登录的密码,如果有任何一员的密码是默认密码,则登录失败。同时平台会记录密码重置操作的审计日志,为此安全风险提供审计追踪的入口与线索。从而实现三员权限的分立,监督,以及相互制约,达到系统平稳,安全运行的目标。
2.1.3.4 权限控制
平台提供多组织应用管理,实现多个组织共用一套平台,使用一套用户资源,并且每一个组织拥有独立的角色、岗位、部门、菜单、权限资源。平台的通用代码和系统配置使用的是一套数据。每个组织应用租用平台的公共的组织机构资源实现独立的管理运行。
图2- 13多组织设计图
平台多组织应用的核心设计理念是多个组织结构中的用户共享一个应用和平台实例,通过数据和权限的隔离,来实现不同组织下面的用户使用平台服务,如登录认证服务、权限管理服务、日志服务等其他业务服务。同时平台支持基于多组织的三员管理机制,各组织分别配置自己的三员安全管理机制,相互独立。平台的多组织应用技术完全支持一个系统多用户单位的权限控制,不同用户单位具有自己一整套数据管理授权体系,数据之间进行组织隔离,满足不同用户单位之间的权限划分和控制。
2.1.3.5 服务访问权限
服务授权管理主要是用来管理服务授权中API访问地址的信息。包括增加、编辑与删除的功能。服务授权管理主界面由单位系统树和服务资源列表两部分组成。在应用端通过平台权限系统控制用户角色与API的访问关系,包括接口调用范围的控制和数据访问范围的控制。
系统内应用间服务调用通过SDK依赖的方式,跨系统服务调用必须经过网关中转,消费服务时需要先申请应用编码和AccessKey,系统通过应用编码和AccessKey访问网关服务,网关检查消费者的请求是否合法以及API范围是否超限,应用只有申请了Accesskey之后才能注册和订阅服务。服务授权还提供了应用授权管理功能,通过该功能可以授权/禁止应用消费服务的权限。
平台通过与Zuul的集成实现微服务API网关对流控,流量、IP、并发数的控制。
2.1.3.6 数据授权管理
平台提供集中授权管理和行数据权限授权功能,集中授权管理主要是对前台菜单、界面组件进行授权,授权对象为用户角色,根据角色配置界面组件的操作权限,用来区分不同角色对数据的编辑、修订权限。行数据权限主要用来配置查看数据的权限,配置上可分为两大块,一是通过配置达到对用户的授权,二是通过配置实现行数据的密级权限控制。
图2- 14行数据授权管理配置
“用户授权”支持多维度的授权,包括“角色”、“群组”、“岗位”、“部门”、“用户”五个页签,通过在每个页签的配置,实现对用户的授权,根据配置权限的不同,区分用户对数据的查看权限。“用户权限参数配置”包括多个维度:
自己的数据:指数据的创建人为“当前登录人”时,满足过滤要求。
自己部门的数据:指数据的创建人属于当前用户所在部门下的所有用户这个范围时,满足过滤要求。
自己部门下N级数据:指数据的创建人属于当前用户所在部门向下 N 级部门所对应的用户范围时,满足过滤要求(不包括当前登陆人所在部门)。
自己部门上N级数据:指数据的创建人属于当前用户所在部门向上 N 级部门所对应的用户范围时,满足过滤要求(不包括当前登陆人所在部门)。
指定部门的数据:指数据的创建人属于指定部门下的所有用户范围时,满足过滤要求。
指定用户的数据:指数据的创建人属于指定的用户范围时,满足过滤要求。
指定范围:该参数为用户自定义的类,如果该参数不为空,那么会通过反射执行用户自定义的类获取用户拼装的SQL,实现数据过滤。
应用密级权限:如果该参数被勾选,那么会通过当前登陆人的密级等级,获取用户在通用代码中配置的密级范围。如果行数据的密级等级属于该密级范围时,满足过滤条件。
密级授权:在配置时,如果选择了“应用权限控制”,则会根据当前用户的密级,通过通用代码获取对应的密级范围,该范围就是行数据密级字段所在的范围权限。例如:当前用户为平台管理员,它的密级为“一般涉密”(2),对应的通用代码范围值为(“1”,“2”),那么用户的行数据的密级字段值就要在这个密级范围中,以此来达到对行数据的密级权限控制。
2.1.3.7 业务类型授权管理
平台的权限分配和控制是整个系统的核心功能,支持按照角色授权,不仅可以对系统菜单进行权限控制,还可以对菜单页面的各个HTML元素标签进行控制,例如页面的添加、编辑、删除操作按钮和页面的列表数据等,同时还可以对页面上各种AJAX请求资源进行控制。在多应用环境下,可以实现多个应用系统权限的集中管控和授权。
平台权限控制功能共分为三层,菜单权限、资源权限和数据权限,权限范围层层递进。菜单权限主要包括前台菜单授权、后台菜单授权,资源权限主要为集中授权。
平台对前后台菜单进行分类管理,分类授权,系统管理员在菜单管理页面,添加的前台菜单,前台用户是无法使用的,需要安全管理员在前台菜单管理授权中给相应的角色授权后,该角色下的用户才能有权限使用这些前台菜单。
图2- 15前台菜单授权管理
系统管理员在菜单管理页面,添加的后台菜单,后台用户是无法使用的,需要安全管理员在后台菜单管理授权中给相应的角色授权后,该角色下的用户才能有权限使用这些后台菜单。
图2- 16后台菜单授权管理
集中授权主要是对前台菜单以及菜单的界面组件进行授权,授权对象为用户角色,权限粒度更细。不仅可以根据角色授予菜单权限,还可对界面中的业务操作类型进行授权,例如对界面的新建、修改、删除、启动流程等操作按钮以及界面列表字段进行授权。
图2- 17集中授权管理
平台的权限分配功能满足多种应用场景,权限分配范围可大可小,权限分配粒度可粗可细,完全符合业务的授权需求。
2.1.3.8 安全保密技术
平台采用多种安全机制,符合安全保密要求。内置了防 SQL 注入、XSS 注入等 OWASP 十大攻击技术手段,还提供了文件加密存储,日志审计、三员管理等 BMB17 和 BMB21规定的安全保密功能。并且能够对常见的 Web 攻击进行防范,以实现平台的最高安全性。然而安全性的实现过程中,并不是简单依靠防火墙、防病毒程序的功能,而是在软件开发过程中就要考虑到安全性的要求,将不安全的请求进行拦截和处理,平台提供了相关的开发规范和技术手段可以实现必要安全防护,同时平台支持使用分布式文件存储系统作为文件服务器,文件采用加密冗余存储,只有通过平台的下载功能,调用解密模块后,才能获取到解密后的文件。按照系统非功能需求中对安全的要求,平台从网络传输、系统安全、数据安全等多个维度进行安全设计,确保平台符合国家相关保密要求。
图2- 18系统安全设计原理图
数据库层面提供了包括用户标识与鉴别、自主与强制访问控制、通信与存储加密、审计等丰富的安全功能,且各安全功能都可进行配置,满足各类型用户在安全管理方面不同层次的需求,数据库层面的安全体系如下图所示:
图2- 19数据库层安全体系
用户标识与鉴别
用户标识与鉴别对试图登录数据库进行数据访问的用户进行身份验证, 以确认此用户是否能与某一数据库用户进行关联,并根据关联的数据库用户的权限对此用户在数据库中的数据访问活动进行安全控制。
数据库身份验证模式需要利用数据库口令,即在创建或修改用户时指定用户口令,用户在登录时输入对应口令进行身份验证;外部身份验证模式支持基于操作系统(OS)的身份验证、 LDAP身份验证和 KERBEROS 身份验证
自主访问控制
由数据库对象的拥有者自主决定是否将自己拥有的对象的部分或全部访问权限授予其他用户。也就是说,在自主访问控制下,用户可以按照自己的意愿,有选择地与其他用户共享他拥有的数据库对象。
强制访问控制
根据客体的敏感标记和主体的访问标记对客体访问实行限制的一种方法。在强制访问控制中,系统给主体和客体都分配一个特殊的安全标记,主体的安全标记反映了该主体可信的程度,客体的安全标记则与其包含信息的敏感度一致,且主体不能改变他自己及任何其它客体的安全标记,主体是否可以对客体执行特定的操作取决于主体和客体的安全标记之间的支配关系。因此,强制访问控制可以控制系统中信息流动的轨迹,能有效地抵抗特洛伊木马的攻击,这在一些对安全要求很高的数据库应用中是非常必要的。
强制访问控制功能仅在数据库的安全版中提供。
通信、存储加密
数据库提供三种通信方式:不加密、SSL 加密、SSL 认证,是否使用通信加密以数据库服务器端的设置为准,即通过设置服务器配置文件中的参数来指定,客户端以服务器,采用的通信方式与其进行通信,同时支持通过参数用来指定消息通信的加密算法。
为了防止用户直接通过数据文件获取用户信息, 数据库提供了全面的数据加密的功能,包括: 透明加密、半透明加密、非透明加密,存储加密在保证数据文件安全性的同时,也会带来一定的性能影响,不同的加密算法对性能的影响各有不同,用户需要根据自己的需求来决定是否进行加密以及加密算法的选择。
透明加密:在透明加密中,密钥生成、密钥管理和加解密过程由数据库管理系统自动完成,用户不可见。透明加密的目的主要是保证存储在数据文件中的敏感数据的安全,并不能保护合法用户的个人私密数据。系统内置了常用的 DES, AES, RC4 等类型的加密算法,以此来保护数据的安全性。
半透明加密:创建用户时可以指定存储加密密钥,这个密钥就是为了进行半透明加密时使用的。如果在创建用户时并没有指定存储加密密钥,系统也会自动为用户生成一个默认的加密密钥。如果在创建表或修改表时指定对表列进行半透明加密,数据库会使用用户的存储加密密钥对数据进行加密。
非透明加密:通过对用户提供加解密接口实现的。用户在使用非透明加密时,需要提供密钥并调用加解密接口。采用非透明加密可以保证个人私密数据不被包括DBA 在内的其他人获取。非透明加密通过用户调用存储加密函数来进行, 数据库提供了一系列的存储加密函数。
审计
数据库除了提供数据安全保护措施外,还提供对日常事件的事后审计监督。审计功能可以记录系统级事件、个别用户的行为以及对数据库对象的访问。通过考察、跟踪审计信息,数据库审计员可以查看用户访问的形式以及曾试图对该系统进行的操作,从而采取积极、有效的应对措施。
加密引擎
数据库内置了常用的 DES, AES, RC4 等类型的加密算法供用户使用,以此来保护数据的安全性。然而在有些特殊的环境下,这些加密算法可能不能满足用户的需求,用户可能希望使用自己特殊的加密算法,或强度更高的加密算法。 数据库的加密引擎功能则可以满足这样的需求。
资源限制
数据库支持在创建和修改用户时指定对用户进行资源限制,资源限制用于限制用户对数据库系统资源的使用。
2.1.3.9 系统备份
平台具备完整的软件、数据库备份及恢复方案,保证备份方案覆盖系统平台全部功能及数据。在平台使用过程中,可以参照恢复方案快速恢复全部或部分系统功能及数据。
系统具备完整的备份方案,如下所示:
其一,针对系统本身的应用程序,通过批处理功能进行打包压缩,定期自动转移备份,或根据需要进行恢复。
其二,针对本系统中的创建并存储的结构化的业务数据,存储在数据库中,通过调用数据库管理程序DBMS进行物理备份或恢复,数据库管理员应该及时对数据进行备份,防止系统、数据的丢失;涉及数据备份和恢复的单位要由专人负责数据备份工作,并认真填写备份日志;系统数据库备份工作,由数据库管理员通过配置系统参数来实现,数据库每日自动备份,系统每周自动备份。定期将备份文件转入磁带或磁盘阵列做二次备份,备份数据应该严格管理,妥善保存;备份数据资料保管地点应有防火、防热、防潮、防尘、防磁、防盗设施,数据的备份、恢复、转出、转入的权限都应严格控制。严禁未经授权将数据备份出系统,转给无关的人员或单位;严禁未经授权进行数据恢复或转入操作,一旦发生数据丢失或数据破坏等情况,要由系统管理员对备份数据恢复,以免造成不必要的麻烦或更大的损失,必须定期检查保存备份数据能否正常使用,需刻录光盘的数据应经过检验确保数据备份的完整性和可用性后,方可刻录光盘。
其三,针对本系统中的创建并存储的图文档类型的非结构化的业务数据,通过批处理功能将数据进行打包压缩,定期自动转移备份,或根据需要进行恢复。
其四,针对本系统中的采集其他业务系统的数据,存储在数据库或索引库中,通过批处理功能将数据进行打包压缩,或调用数据库管理程序DBMS进行物理备份或恢复。
为了确保计算机系统的数据安全,使得在计算机系统失效或数据丢失时,能依靠备份尽快地恢复系统和数据,保护关键应用数据的安全,平台提供Windows、Linux环境下Oracle数据库的自动备份脚本:
win-exp脚本
win-rman脚本
linux-exp脚本
linux-rman脚本
2.1.3.10 平台安全性
根据国家有关保密工作的政策要求及集团公司有关保密规定,我方制定了严格完善的保密体系及保密制度,保证在项目实施及服务的过程中达到国家的保密要求。在制度建设的基础上,平时能够做到随时检查,不断完善,根据需要进行调整,不会存在安全隐患,没有预留后门。
2.1.3.11 平台售后保障
系统在开发过程中或者正式上线后,我方及时提供补丁、漏洞、版本升级,确保平台稳定运行。对于硬件维护支持、系统软件维护支持、应用软件维护支持,在产品生命周期内,我方公司均提供7×24小时免费技术支持响应服务。对于系统重大故障,4小时内解决问题,若无法解决则启动应急方案,以保证系统在短时间内的恢复运行。
2.1.4 二次开发实施流程设计
各系统的二次开发实施不仅仅是一个软件应用的问题,而是事关管理提升的大事,其本身的实施管理也是一个系统的管理工程。招标人决定引入系统,要取得良好的应用效果,决不可能仅仅像对待工具软件一样拿来即用,而是需要提前做好规划,明确业务需求和建设目标,投入适当人力和其它资源,严格监督和管控项目过程,这样才能让二次开发系统很好的辅助和加强对招标人的业务管理。在应用和推广上,总结起来,建议遵循以下几点:
领导重视。信息化系统大部分都是一把手工程,领导要把系统的实施应用作为管理提升的一个重要;
组织保证。成立项目小组,全程管理和跟踪各系统的应用过程;
制度保证。结合招标人现有的管理制度和流程体系,制定各个系统实施和应用标准和规范,使各个系统应用有章可循;
总体规划,分步实施。确定各个系统建设的长期目标和各阶段的建设内容;
试点先行。先选择合适的项目、参与业务部门和人员小范围试点验证,对暴露的问题跟踪整改、解决,成功后再逐步推广;
管理与各个系统相融合。做好招标人业务流程与各个系统流程的匹配工作,相互促进、改进、融合,不能一方一味的迎合另一方;
需求管控和问题跟踪。全程加强需求管控和问题跟踪;
严格控制变更。严格评审变更带来的影响,强制变更必须走正式的变更流程,控制各个系统随意变更。
加强培训。重视和加强培训、辅导工作,定期或不定期的开展不同角色的系统培训工作。
定期例会和汇报。建立项项目例会和汇报机制,通报项目进展和实施中的问题和风险,共同讨论问题的解决方法,确保项目成功。
2.1.5 项目实施组织
本单位承诺在中标后,将为本次项目成立专门的项目实施团队,团队人员有实施相关管理系统的丰富经验和能力,保证招标方能够得到良好的服务内容和服务质量。并建立完善的各项管理制度和质量保证体系以保障项目的顺利实施。
2.1.5.1 实施过程职责划分
表 实施过程任务分解及职责列表
阶段 | 任务分解 | 职责单位 | 备注 |
项目启动阶段 | 工作方法与制度 | 乙方 | 由领导组批准 |
总体目标 | 双方,以甲方为主 | 由领导组批准 | |
阶段目标 | 乙方 | 客户评议 | |
总体计划 | 乙方 | 由领导组批准 | |
各阶段计划 | 双方 | 以乙方为主 | |
风险分析报告 | 双方 | 以乙方为主 | |
需求分析阶段 | 需求调研方法分析、准备 | 双方 | |
调研表格发放与收集 | 甲方 | ||
部门需求调研 | 乙方,甲方协助 | ||
编写需求分析 | 乙方 | ||
形成需求分析报告并签字确认 | 甲方签字认可 | 签字后在开发阶段不可修改,修改需经项目协调委员会批准。 | |
系统设计阶段 | 详细设计编写 | 乙方 | |
详细设计评审 | 乙方 | ||
详细设计定稿 | 甲方签字认可 | ||
界面风格定稿 | 甲方签字认可 | ||
系统开发阶段 | 系统编码 | 乙方 | |
联调方案 | 双方 | ||
测试大纲与计划 | 双方 | ||
案例设计 | 甲方 | ||
测试实施 | 双方 | 甲方为主 | |
测试报告 | 甲方 | ||
系统实施阶段 | 用户手册 | 乙方 | |
安装手册 | 乙方 | ||
数据转换与初始化方法 | 乙方 | 客户协助 | |
数据准备与实施 | 客户 | ||
用户培训 | 乙方 | ||
试运行 | 甲方 | 乙方协助 | |
项目验收阶段 | 验收方案与标准大纲 | 双方 | |
验收实施 | 甲方 | 乙方技术配合 | |
验收报告 | 甲方 | ||
维护与维护报告 | 甲方 | 乙方服务并支持 |
2.1.5.2 实施团队职责
表8-2实施团队职责列表
机构 | 组成 | 职责 |
工作领导组 | 以甲方为主,双方组成。 | 项目的最高决策机构; 批准项目目标与总体进度; 批准项目章程; 批准重大项目变更; 了解项目进展,指出项目风险。 |
甲方项目经理组 | 由甲方成员组成,甲方自行安排组成人员。 | 代表甲方签署一切需签署的文件、承诺、工作与成果; 接收项目组委派的工作,并组织甲方完成这些工作; 接受项目组提交工作成果,并进行验收; 甲方提出要求的唯一权威人士; 甲方人员组织的窗口与联络人。 |
乙方项目经理组 | 由乙方成员组成,包含人员:项目经理、技术经理、商务代表。 | 代表乙方签署一切需签署的文件、承诺、工作与成果; 完成设计、实施及成果整理工作; 完成技术实现及规范指导工作; 代表乙方提出要求的唯一机构。 |
乙方软件开发组 | 由乙方公司成员组成。 | 系统的设计、开发和测试。 |
乙方项目实施组 | 乙方为主,乙方人员参加。 | 系统的安装、联调、使用管理; 系统初始化及安装调试; 修改意见的整理及规范化; 对最终用户的培训。 |
项目验收组 | 由甲方聘请的专家组成。 | 负责验收工作。 |
2.1.6 实施过程控制
2.1.6.1 实施过程控制
(1)启动
由乙方项目经理根据已获得的资料和经验,提前编写计划书初稿。合同签订后,第一时间与双方领导层进行确认。并根据计划书提炼启动会PPT。
(2)策划阶段
策划阶段的主要工作内容是调研甲方及各承研单位的需求,并形成详细的解决方案。为了保证进度,调研工作和需求规格说明书、详细解决方案等文档编制工作采用并行的方式。
按照业务将调研工作分为多类业务,乙方分派多个小组对业务同时进行调研,各小组根据已获得的信息和经验提前准备调研提纲,调研完成后,分别编写调研报告、需求规格说明书和详细解决方案等。为了保证需求和方案的完整性和一致性,全部调研完成后,由项目经理组织整个实施小组对需求规格说明书和详细解决方案进行合稿。
为了保证详细技术方案的质量,需求规格说明书和详细解决方案的初稿完成后,由双方项目经理协商、组织双方的业务顾问、其他专家对方案进行评审,评审需从解决方案是否覆盖调研时的需求和潜在需求、技术上是否可行等方面进行评审。保障该方案能够指导下一步工作。
(3)执行阶段
制定执行阶段计划
由乙方项目经理根据具体的详细解决方案,分解任务、制定执行阶段计划初稿,发送给整个项目团队。项目组成员接到任务后对任务进行评估。项目经理组织召开项目计划发布会,在会上项目组成员提出计划修改建议,经整个项目组协商后,形成最终计划进行发布。后续工作严格按此计划执行。
系统概要设计
概要设计的主要工作内容是根据解决方案要求,形成系统的处理流程、总体结构与模块、功能与模块的关系、接口关系、数据关系等信息。为了保证进度,概要设计编制工作采用并行的方式。同样根据策划阶段的分工,分派多个小组针对各板块的业务编写概要设计,全部编写完成后,由项目经理组织整个编写小组对概要设计进行合稿。
为了保证概要设计的质量,一阶段概要设计的初稿完成后,由双方项目经理协商、组织双方的业务顾问、其他专家对方案进行评审,保障该设计能够指导下一步工作。
系统详细设计
详细设计是根据概要设计内容,对各个层次中的每一个程序 (每个模块或子程序)的设计细节进行描述。详细设计由研发团队完成,为了保证进度,根据概要设计的功能划分,研发团队可分为多个小组并行开工,同时要求在概要设计完成前10天,研发人员就开始介入,根据已确认的部分概要设计,提前进行详细设计。
为了保证详细设计的质量,详细设计完成后,首先由对口的实施顾问进行初步评估。详细设计所有部分完成后,要研发团队负责人进行合稿,形成详细设计初稿。并组织相关的实施团队、研发团队、其他专家进行评审。
程序开发
详细设计通过评审后,研发负责人制定详细的研发计划,下达给整个研发团队后,开始按计划进行系统代码的开发、单元测试工作。
程序的质量包括两大部分:1、功能部分,研发人员需要对功能的操作、界面、性能等进行交叉测试。2、代码质量,由质量部组织内部专家进行抽查。
系统测试
系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方,从而提出更加完善的方案。
为了保证测试的进度,系统测试分多个业务线并行开展,由相应的实施顾问主导。实施顾问需在测试前,根据对业务的理解准备测试用例,在测试过程中,记录测试结果、改进意见等,并形成测试报告。测试报告每天通过公司的JIRA系统提交研发团队。研发团队根据具体需要定期提交修改的信息及程序包、数据库脚本等。
用户验证
用户验证是甲方业务人员模拟实际业务对系统进行功能上、操作上、界面上、流程上的各种综合测试验证。
1)提交用户验证前,实施顾问需提前准备以下内容:
现场测试软硬件环境;
搭建已测试过的应用系统;
准备测试的系统基础数据(组织机构、人员、权限等)。
2)培训
对关键用户进行模块功能培训和模块业务操作培训。
3)用户验证及需求收集
关键用户模拟真实项目对系统进行全面的应用测试,测试过程中,实施顾问现场进行支持,支持工作包括解答关键用户的疑问、处理使用中的各种问题,记录出现的BUG及用户就系统提出的需求等。
4)用户验证的进度
如测试过程中出现的问题导致系统不能继续运行或系统中某项业务(某一模块)无法进行,实施顾问第一时间反馈给相关的技术人员进行处理,并反馈给双方项目经理。
(4)系统上线
双方项目经理必须确保提供足够的项目资源。
为上线初期制定一个“回退”或者应急措施。
(5)验收阶段
项目经理根据经验提前整理前期工作中产生的文档,根据用户具体的验收要求进行修改、完善、补充,准备验收申请、验收汇报的PPT等,召开验收会议并签署验收报告。
2.1.6.2 需求变更控制
变更控制是通过有序地管理变更来稳定开发过程、减少项目风险。本程序的制定是为了检查所有的变更请求,决定哪些需要实施、哪些需要推延、哪些需要否决。在得到对方的认可后,进度和成本将相应地做出调整。一个有效的变更控制程序对于避免项目延期和超支是必要的。
图8- 1需求变更控制流程
图8- 1需求变更控制流程
1) 提出变更
提出变更需首先填写“变更申请表”,“变更申请表”需由申请方项目经理交给对方项目经理。
2) 接收方的响应
接收方项目经理将在接到“变更申请表”的三个工作日内确认,接收方项目经理将就“变更申请表”的技术可靠性以及对整个项目的影响做出评估(评估结论必须确定变更的类型(重大变更和一般变更))。
3) 变更的审批流程
一般变更由接收方项目经理确认后即可进行实施。
重大变更经接收方项目经理同意的“变更申请表”将提交项目领导小组批准备案,未被批准的“变更申请表”将退还给申请方项目经理。任何双方项目经理不能解决的争议将提交项目领导小组审议。
4) 变更实施
双方将根据经确认批准的“变更申请表”重新调整项目计划,并进行任务分配。
双方将根据新的项目计划履行各自的责任。
2.1.6.3 项目质量控制
在项目正式开始实施之前,乙方承诺向招标方提供软件开发和系统安全的相关资质。
总体要求
产品以性能稳定、界面友好、安全可靠、满足用户需求为目标。为保证质量,系统上线运行前将进行充分的测试。测试前制定测试计划和方案,准备测试数据,测试完成后出具相应的测试报告。在系统开发环节,要求开发人员完成单元测试和集成测试。在系统实施环节,要求实施人员完成单元测试和集成测试。实施项目经理组织完成系统测试。试运行期间,针对用户反馈的问题,承诺实施人员及时完成修改,并更新试运行的系统版本。
实现过程
产品实现主要包括需求分析、解决方案、概要设计、详细设计、代码开发、单元测试、系统测试和用户测试等核心过程:
图8- 2产品实现过程
控制点
甲方各个系统的实施过程,主要设置以下质量控制点:
需求分析评审
解决方案评审
概要设计评审
详细设计评审
代码质量检查
系统功能单元测试
系统测试
用户测试
2.1.6.4 项目测试管理
(1)测试概述
系统测试主要是通过功能测试和自动化性能测试来验证本次投标各个系统软件的功能和性能及其他特性与用户需求和系统设计的一致性。功能测试主要是通过测试用例验证系统功能是否符合预期结果,本项目中功能测试采用的测试方法主要包括等价类划分法、边界值分析法和错误推测法等。性能测试主要是选取项目管理系统部分常用业务,通过场景法编写测试脚本,采用性能测试工具LoadRuner对系统进行负载、压力测试;根据系统资源的使用情况,验证系统在测试网络和硬件环境下的性能表现。并针对性能测试发现的问题,进行性能分析,提出系统需要进行性能优化的整改意见。其他特性测试主要是对项目管理系统的易用性、兼容性、安全性等内容进行测试,使提示信息、页面布局等内容更加人性化,提高系统的用户亲和力。最后对系统进行回归测试,验证已发现问题的解决情况,同时验证在修复问题的过程中是否引入了其他问题。
(2)测试目的
通过系统整体测试,发现系统在设计开发过程中出现的问题/BUG,并对问题/BUG进行总结分析。根据测试结论反馈,处理修复已发现的问题/BUG,提高系统质量和系统健壮性。保障系统符合上线运行的具体要求。
(3)测试工具及测试环境
测试工具
系统测试工具主要包括缺陷管理工具、性能测试工具和数据库监控工具。其中JIRA用于管理测试缺陷,LoadRunner 用于进行压力测试,Spotlight 用于进行数据库性能监控。
测试环境
测试环境包括整个测试过程中测试数据库服务器的软、硬件环境配置,测试Web应用服务器的软、硬件环境配置以及测试客户端的软、硬件环境配置。
建议测试环境不低于下表中推荐的配置,如下表所示。
表8-3测试环境要求清单
类别 | 测试环境要求 | |
客户端 | 软件环境 | 操作系统: Win7 浏览器:IE8 |
硬件环境 | 内存:4G CPU: Intel(R) Core(TM) 2 Duo CPU E7300 2.66GHZ | |
Web应用服务器端 | 软件环境 | 操作系统:Windows Server 2008 |
硬件环境 | 内存:32G CPU:Intel Xeon E7-4800V2,主频:3.2G | |
数据库服务器端 | 软件环境 | 操作系统:Windows Server 2008 数据库:Oracle 11g |
硬件环境 | 内存:64G CPU:Intel Xeon E7-4800V2,主频:3.2G |
(4)测试计划
测试计划说明整个测试工作的计划安排,主要目标是规范测试工作过程,保证测试工作进度,确保测试过程中发生问题时能够得到快速解决和响应,项目测试团队负责人为项目实施经理。
测试计划表,如下表所示。
表8-4测试计划表
工作内容 | 负责人 | 工期(天) | 备注 |
制定测试计划,部署测试系统,安排系统测试相关工作 | 项目经理 | 1 | |
熟悉业务及参加培训 | 测试团队 | 1 | |
测试用例编写 | 测试团队 | 10 | |
测试用例评审 | 项目团队 | 1 | |
首轮测试 | 测试团队 | 6 | |
末轮测试 | 测试团队 | 6 | |
编写系统测试报告 | 测试经理 | 1 |
此阶段的主要工作是在用户真实环境下,验证系统功能符合用户签署的《项目需求规格说明书》中描述的需求,同时把尽可能多的潜在问题在系统正式运行之前发现并改正。并帮助用户的有关人员在系统正式运行前能进一步提高操作水平,掌握操作规范。此阶段的主要工作内容为:
1)编制计划:与用户实施负责人商议具体测试时间,地点,人员等安排,项目组编制《系统测试计划》。
2)签署计划:用户签署《系统测试计划》,进一步确认测试及试运行安排。
3)发布测试通知:在测试开始前2天,按照签署的《系统测试计划》,将时间,地点,人员等信息通知用户实施负责人。
4)搭建环境及数据准备:在测试工作开始前搭建好软件环境、硬件环境、网络环境、调通线路;检查软件、硬件、网络、线路等各个环节是否有问题。
5)组织测试:用户相关各级领导给予全面配合,组织相关人员进行测试。
6)测试总结:测试完成,总结测试中设备、软件的运行情况,总结测试中业务流程和操作环节的情况,以书面总结形式将测试结果通知相关负责人,提交《系统测试报告》。
(5)结果记录
为了保证测试的进度,系统测试分多个业务领域并行开展,由相应的测试人员主导。测试人员需在测试前,根据对业务的理解准备测试用例;在测试过程中,通过乙方的JIRA系统记录测试结果、改进意见等。开发团队根据结果记录要求定期提交修改的信息及程序包、数据库脚本等。
(6)跟踪机制
测试团队将分块测试,并应用测试用例和JIRA系统记录测试过程。测试问题提交JIRA系统后,系统自动提醒问题责任人处理相关问题,问题责任人问题处理完毕后需要由测试人员进行验证,确认问题解决之后,测试问题关闭。如果在此过程中出现反复,由项目经理负责协调解决,并就规划设计是否需要修改和调整做出决定,保证问题圆满解决。
项目团队测试工作完成之后,部署已经测试过的应用系统并准备测试系统基础数据(组织机构、人员、权限配置等)。同时对关键用户进行模块功能培训和模块业务操作培训。由招标方组织人员完成用户验证工作,即招标方业务人员模拟实际业务对系统进行功能上、操作上、界面上、流程上的各种综合测试验证。
在用户验证过程中,乙方承诺提供现场技术支持,支持工作包括解答用户的疑问、处理使用中的各种问题,记录出现的BUG及用户就系统提出的需求等。 如测试过程中出现的问题导致系统不能继续运行或系统中某项业务无法进行,实施顾问第一时间反馈给相关的技术人员进行处理,并反馈给双方项目经理。
2.1.6.5 沟通机制
项目沟通形式是指项目组工作汇报、计划控制等项目的管理活动,是稳健推进项目实施的重要依据。项目成员应严格执行如下4个沟通流程。
项目周报机制
项目经理在每周一上午提交项目周报给:
项目领导小组成员;
项目成员;
招标人主要项目成员。
项目双周例会
会议主持:项目经理。
主要参加人员:双方项目组成员。
时间:每周五下午。
会议内容:对两周工作的总结并制定下一阶段工作计划。若遇有重大事项需要双方领导小组成员共同参加项目会议对重大事项进行决策。
注:会议结论以会议纪要方式发送双方项目组成员,关键文档需要双方项目经理书面签字确认。
项目月例会:
会议主持:项目经理。
主要参加人员:双方项目组成员。
时间:根据项目情况确定。
会议内容:进行本月工作总结并制定下月工作计划,对项目过程中的未决重大问题进行确认。
注:会议结论以会议纪要方式发送双方项目组成员,关键文档需要双方项目经理书面签字确认。
可根据需要,不定期召开项目特别会议:
不定期项目特别会议议题主要是对在项目实施过程中间出现的重大决策尽享商讨,会议召集人可以为双方的项目经理,双方项目成员必须参加。
会议结论以会议纪要方式发送双方项目组成员,关键文档需要双方项目经理书面签字确认。会议纪要的内容包括如下几方面:
任务的当前状况(人员、进度等);
对以前明确的问题的解决进展;
自上次以来的问题或潜在的问题;
计划纠正措施;
下一报告期内预期实现的里程碑。
2.1.6.6 实施技术服务
乙方负责所提供应用软件的现场安装、调试、上线和开发。应用软件安装、调试时所需的工具软件、补丁包等均由乙方负责提供。在系统安装调试过程中对相关工作过程进行详细记录,安装调试通过后,与客户沟通试运行的时间,保证不少于1个月的试运行时间,乙方负责解决试运行期出现的问题,安装和调试工作结束后,保障系统功能、性能完好,由乙方技术人员在记录文件上签字并交招标方备案。系统实施完成后保证满足甲方在招标文件中提出的应用要求。
(1)安装与调试
乙方负责系统的包装运输,交货地点为买方使用现场,乙方提供系统运行所需的最低硬件配置要求。
乙方派技术人员在甲方现场负责软件的安装、调试,且调试人员具备此系统3年及以上安装调试经验,自备必要工具,并在安装现场对使用操作、维护管理人员进行技术培训。同时解答招标方技术人员提出的问题。
(2)系统配置与开发
乙方将根据招标人实际业务现状和需求,结合系统特点、以及周边系统的情况,制定具体的实现方案,在招标方指定地点进行配置与开发,对历史数据梳理与导入,制定详细的测试方案和计划,进行严格的功能测试、集成、性能、安全性、用户接收、备份与恢复等一系列测试,确保系统质量,并提供产品相应模块的使用说明、系统设计与实现方案、测试报告、操作手册等文档。
(3)系统的补丁和升级
在服务期内,在招标人要求下,乙方为招标人及时提供产品升级版本或补丁的服务,以保证解决各个系统中的问题、改善各个系统性能或应用最新业务模式等。
(4)系统数据库维护
在服务期内,乙方实施或服务人员与招标人沟通后,确定数据库安装配置方案。在招标人要求下,乙方为招标人提供数据库维护技术支持服务,以保证解决各个系统中数据库的问题、保证各个系统性能等。
(5)实施顾问服务
乙方专注于提供系统性的软件研发工程同解决方案,经过多年在军工行业内开展系统设计、开发和实施活动,积累了大量的程中,乙方可以为项目实施提供咨询和顾问服务,明确项目实施中的关键点,提供最合理的业务解决方案,避免项目实施中的盲点,为甲方本次招标的五个系统实施保驾护航。
乙方承诺针对招标人的项目能进行规划,主动推动、进度监控与阶段报告反馈,并且在项目进行中进行工作协调、组织分工与专业的编码建议、流程规划、与软件运作规划,以保障项目顺利上线运行,以达到项目目标;乙方承诺提供详尽的项目实施计划,包括日历计划和月度计划及各项测试计划、上线切换计划等。
乙方提供顾问实施服务,拟派具有独立成功实施大型装备制造业客户和集团型客户项目实施经验的实施顾问。实施顾问提供已实施类似项目的数据搜集文档模板样张、标准流程文档模板样张、重要步骤中的产出文件样张。实施顾问在项目实施过程中详实记录项目实施情况与会议情况,最终提供实施结项报告和实施系统配置文档,并经过招标人确认。
当甲方出现使用问题或技术问题时,乙方及时提供有效的技术解决方案和必要的驻场支持。
(6)项目验收
1)验收标准
具体验收标准如下:
软件安装、调试达到技术规格书规定的指标,由双方采用试运行1个月的方式共同对交付的软件进行验收,验收合格后由甲方出具验收报告作为产品交付验收证明;
甲方组织在软件试用满足要求后,依据技术协议进行项目验收评审,验收小组签署项目验收评审意见,并以此作为验收依据。
2)验收程序
试运行工作结束后,由乙方技术人员提出验收申请;
甲方收到乙方验收申请后,甲方组织验收会议;
按双方认可的方式和标准验收,最终验收合格后双方签字生效。
2.2 体系结构
2.2.1 教学大厅
我司利用系统二次开发,通过对招标人业务进行调研后形成需求分析。依据需求分析结果进行系统二次开发,二次开发后的系统提供各类教学应用系统的统一访问入口,包含并不限于以下功能:
开发完成后的教学服务大厅包含但不限于登录认证、首页、教学数据、信息中心、应用中心、个人中心、校园导览、统计分析等,并针对不同用户在登录后所看到的内容进行区分。
开发完成后的系统支持统一身份认证,与采购单位信息门户、统一认证系统对接。
开发完成后的系统支持采购单位其他相关教学服务应用系统跳转访问。
开发完成后的系统提供各类在线教学服务的统一访问入口,并按照使用对象、归属部门、应用类型、自建或者第三方等,对应用进行分类和筛选。常用服务类型,包括但不限于:课表查询、学生名单、教室借用申请、教室调整申请、空闲教室查询、教室设备报修、教室使用说明、教学软件使用说明、随堂录课预约、精品课录制预约、各类活动发布申请等。
开发完成后的系统支持内容管理(CMS)。管理员可自定义栏目、发布维护内容资讯。实现教学内容资讯的集中管理。
开发完成后的系统用户登录后,可查看、修改完善个人信息、修改密码、查看访问历史,以及退出当前登录系统。
开发完成后的系统支持教学相关公告、资讯等的发布和管理。支持教学相关专题的管理和维护,支持按照专题设置独立子栏目,集中展示该专题下的所有资讯、活动、视频、成果等内容,并实现对该专题下的所有内容的集中管理。具有新增、编辑、上下架、启用/禁用和删除等功能,新增时可设置所属的用户分组。
开发完成后的系统提供各类教学活动的统一访问入口。包括讲座、答辩、会议、沙龙、实训、投票、需求调研等活动。支持后台发布各类活动信息,允许用户自定义活动在线报名表单,并提供报名人员查询、活动现场核验、共享活动资料、统计报名人数、投票结果统计、调研表单模板、调研结果统计等相关功能。管理教学活动列表和活动内容,包括发布、审核、编辑、上下架、删除、查询等功能。用户可发布不同类型、归属不同部门的活动数据。管理员可对活动申请进行审核等操作。教学活动根据活动开始和结束时间对活动进程状态进行划分,可根据活动进程状态(进行中、待开始、已结束)查看活动数据。
开发完成后的系统支持系统管理员新增、维护应用系统。维护系统基本信息、设置应用系统跳转地址、设置用户统一认证方式(独立认证、统一认证等)、维护可访问该系统的用户组及用户、设置系统可用状态等信息。
开发完成后的系统支持系统管理员新增、维护在线服务。维护服务基本信息、设置服务跳转地址、设置是否需要用户访问方式、设置用户认证方式(独立认证、统一认证等)、维护可访问该服务的用户组及用户、设置服务可用状态等信息。
开发完成后的系统支持按照图表、表单两种方式查询各种与教学相关的数据。
开发完成后的系统支持“零编码”方式快速创建数据图表、可视化大屏,直观展现教学数据,我司承诺定制开发不少于3个的单页面数据可视化大屏交付给客户。
开发完成后的系统支持通过配置方式建立对其它资源的访问,实现与第三方应用系统、数据源、服务接口的对接。支持与第三方服务接口等,获取相关服务和资源。
开发完成后的系统支持集成第三方应用,后台可直接设置第三方应用后,终端可进行访问。
2.2.2 教学互动平台
我司利用系统二次开发,通过对招标人业务进行调研后形成需求分析。依据需求分析结果进行系统二次开发,二次开发后的教学互动平台能够提供课堂授课及互动功能,包含并不限于以下功能。
开发完成后的系统支持与教室设备集中管控平台对接,实现对教学设备控制。我司在二次开发过程中通过开发接口实现与教室设备集中管控平台对接,获取教学设备状态信息,通过接口进行控制指令下发实现教学设备控制,包括不限于开关、重启、显示等操作。
开发完成后的系统支持教师双屏教学;支持双屏独立显示、联动显示;支持教师在不同屏幕上打开和显示、操作不同的课件讲义资料;支持主副屏分别显示PPT上下页等。
老师可通过讲台双屏进行双板授课,两块屏分为主、辅屏,有四种模式可以切换,老师可点击下方条目栏进行模式切换;
白板模式
复制模式
PPT模式(上下页翻页联动)
讨论模式(可调取其他小组屏的画面进行讨论)
开发完成后的系统支持课件展示,支持Word、Execl、PPT、PDF、视频、图片、音频等的正常播放;系统支持课件批注功能,支持批注笔迹颜色、粗细等的设置;系统支持笔迹撤销、恢复、清除等;支持在课件中保存批注;系统支持PPT的翻页、前进等功能;系统支持课件的在线编制上传功能,系统内置了诸多教学课件模板,帮助用户快速制作课件。
课件模板
开发完成后的系统支持教师多视窗教学;多视窗教学模式下,支持教师同时打开多个课件;教师可以在多个课件中平滑切换。
教师进入多视窗界面后,在视窗模式下可在下方预览所有教学资源,能进行“切换”“批注”、“截图”、“全屏/缩小”等功能操作。
视窗模式
开发完成后的系统支持教师研讨交互教学,支持与多屏互动设备接口对接,可一键切换、调度教师屏、各个小组屏的画面,实现教师主讲、小组讨论、小组分享、教师点评等授课模式。并支持对各模式屏幕连接方式的自定义配置。
如老师讲解或学生讨论时可新建白板进行空白批注讲解,白板批注将单独保存为一个画板,不会对其他页面产生影响。
开发完成后的系统支持教师在登录后,根据课表同步课程与班级信息、学生信息等,支持教师临时更换课程、班级信息。
开发完成后的系统支持教师在工作模式与授课模式的无缝切换。
系统提供备课工作模式和授课模式,教师可以在备课模式下编辑课件元素,例如文字、形状、图片、音视频等,
也可以使用本软件特别提供的课堂活动模板、思维导图等进行趣味性的课堂教学。
下面将对备课模式下的页面分区域进行说明,请参考以下区域划分进行功能查看。系统提供便捷按钮,可以实现一键无缝切换。
备课工作模式
开发完成后的系统支持对界面风格主题的切换,系统支持教师定制个性化桌面。
开发完成后的系统课表查询;支持创建课堂;支持创建日程。
开发完成后的系统教师通过光盘、U盘、本地OPS电脑以及教师个人网盘等多种方式打开课件讲义资料。
开发完成后的系统电子白板功能。支持白板底色、笔迹颜色自定义;支持笔迹撤销、恢复、清除等;支持连续滚动翻页,上下页内容连贯;支持各种图形的绘制,授课板书可保存及分享。
开发完成后的系统支持屏幕截图功能。支持框选屏幕任意大小区域进行截图;支持对截图区域进行标注,并可对标注进行撤销、恢复,支持自定义标注笔迹的颜色、粗细、形状等;支持对屏幕截图的上传和分享。系统支持用户自定义授课工具列表,实现灵活使用。
开发完成后的系统支持全局标注功能。支持白板底色、笔迹颜色自定义;支持以当前屏幕为底的标注功能,并可对标注进行撤销、恢复,支持自定义标注笔迹的颜色、粗细、形状等;支持对屏幕截图的上传和分享。
开发完成后的系统支持录屏分享功能。支持对屏幕和声音的录制;支持以录制的开始、暂停、停止等控制功能;支持对录制完成视频的上传和分享。
开发完成后的系统支持物联黑板功能。支持对物联黑板上的教师粉笔板书内容的实时展示;支持对板书内容截取快照;支持查看历史板书和截图;支持板书回放的暂停、播放、倍速、进度调节等功能;支持快照预览的上下页切换功能。
开发完成后的系统支持教学备课区分为个人备课和小组备课两种类型。教师在备课模块可以进行互动课件、资料、作业、话题、公告等课程内容进行提前的上传、编辑,还可以创建题目形成题库或试卷进行长期备用。
开发完成后的系统支持学生可进行课程的加入、作业的提交、互动课件和资料的预习、话题和公告的参与、互动答题和测试的参与及答案的提交等操作。
开发完成后的系统支持抽取原生资源数据、操作日志数据,导入到教学数据资源管理系统,作为采购单位资源积累。
2.2.3 教学保障管理系统
对教学楼、教室中教学设备的集中一体化管理和控制,包含并不限于以下功能。
1.提供工作记录功能。可按周、月等周期提供工作日志填报。
2.支持故障报修记录,登记设备故障、问题信息,且用户也可在其他软件模块上提交,自动汇总至教学保障管理系统的工作人员界面。
3.支持日常巡检记录,根据巡检情况记录巡检结果。
4.支持日常设备维修记录,记录设备的维修记录,维修时间,维修单位。
5.支持批量导出、导入操作,导出、导入设备维修单,设备保养单,设备检定/校准单等。
6.支持定期巡检:管理员可设置巡检策略(巡检时间、巡检对象、巡检内容、结果填报表单、涉及管理员等),系统按预设规则,自动创建巡检任务,并将巡检任务下发给各级管理员,并通过系统内消息方式进行提醒;管理员巡检结束后,填写结果表单并上传;对巡检结果进行统计分析。
7.支持维修工单管理,对教室的维修业务工单进行流程化管理。实现包括受理核实、派工、执行、回访的全流程管理,包括:维修人员管理、维修任务分派、维修信息录入、维修结果确认、电话回访、工单进度分析、工单数量统计分析;维修工单来源有三个,一是来源于IP呼叫,二是来源于日常工作,三是来源于定期巡检。
8.支持定义和设置设备、耗材、配件类型;支持定义和管理设备类型,管理和维护系统中的所有设备、配件、耗材具体型号规格,支持Excel导出与导入。
9.支持合作商管理:管理和维护所有的第三方合作方。包括产品生产商、系统集成商、售后服务商等,提供合作商名称、联系方式等,支持Excel导出与导入。
10.支持定义、记录以及快速检索设备台账信息。可根据名称,型号,管理人,仪器类型等信息进行快速检索设备信息。对设备的类型、品牌、规格、型号、技术参数、用途、性能指标、编号、供应商、购置时间、购置部门,设备价格等信息进行统计、管理。支持Excel导出与导入。
11.支持在设备安装部署到教室时,对设备的具体安装部署信息进行登记记录。
12.在设备维修、设备移交、坏件更换、配件更换、设备移出、设备报废等操作时,支持设备信息变更,变更操作在更新设备基本信息的同时,记录操作日志。
13.支持实现根据时间段进行统计数据,并以图表的形式展现出来,这样更直观的反映设备用量,设备维护,设备报废,设备故障率等统计信息;实现图表形式打印;实现对数据进行收集,整理,分类和汇总。
14.支持查看库存设备情况,支持多种预设的查询条件(按仓库、按设备类型、按设备品类等),支持任意、多条件组合查询。以帮助管理员实时掌握设备、耗材、配件的库存情况。
15.支持在库设备管理:对在库的设备、配件、耗材等进行管理,包括库存查看、入库登记、出库登记、库间调拨、盘点核对、库存预警等功能。
16.支持入库登记记录本次入库的调入仓库、入库类型、调入时间、操作人等概要信息,以及该次入库中包含的具体设备信息,如具体的设备类型、品类、数量等信息。
17.支持出库登记记录本次出库的出库类型、调出仓库、出库时间、操作人等概要信息,以及该次出库中包含的具体设备信息,如具体的设备类型、品类、数量等信息。
18.支持调拨登记记录本次调拨的调拨类型、调出仓库、调入仓库、调拨时间、操作人等概要信息,以及该次调拨中包含的具体设备信息,如具体的设备类型、品类、数量等信息。
19.支持查询历史的盘点核对信息。创建新的盘点。包括:盘点时间、盘点范围、盘点类型、盘点设备对象等。支持多种盘点方式,支持按类型、按时间进行盘点。根据盘点信息,查询本次盘点中包含的系统数据,生成盘点表。导出(支持EXCEL)/打印盘点表。录入/导入(支持EXECL)实际盘点结果。根据系统数据、实际盘点数据形成盘点结果(一致、盘盈、盘亏),并对盘盈、盘亏的原因能进行记录。
20.支持根据预设的预警阀值,系统在每天晚上跑批的时候,对库存设备的实际数量和预警数量进行比对,并对低于或者超去阀值数量的设备进行预警。查询已经生成的预警信息。处理已经生成的预警信息。
21.支持实现根据时间段进行统计数据,并以图表的形式展现出来,这样更直观的反映设备用量,设备维护,设备报废,设备故障率等统计信息。实现图表形式打印。实现对数据进行收集,整理,分类和汇总。
22.支持批量检测教室设备是否正常,并支持根据课表安排或考试安排,课前或考前对设备进行故障检测,检测记录汇总分析,生成检测报告,并将故障推送工作人员。
23.支持教室设备的远程管理控制,支持一键操作,支持对单个设备的精准操控,支持设备状态监控(包含但不限于开机、关机、故障、网络故障等状态)。
功能界面介绍如下:
我司二次开发后教学保障管理系统,基于网络可实现移动端或PC服务器后台登录,对多个子系统或模块进行综合管理;采用云计算、物联网构建一个统一管理,统一运维,统一监控的综合管理平台,教学保障管理系统具有远程控制、智慧教室监控、智慧教室管理、资产管理等功能,实现智慧教室远程集中管理控制,降低管理工作量,提升运维效率,满足智慧教室的管控要求,支撑信息化技术改革和创新教学的教育模式。
智慧教室设备多,随着规模扩大,对于设备管理复杂程度越来越高,通过部署教学保障管理系统,对智慧教室内设备进行远程控制,实现智慧教室监控、管理、数据分析功能。
可远程实时查看智慧教室的上课情况,可直接对智慧教室设备进行远程控制,提高管理效率。具备巡课功能,能够同时监看网络中各智慧教室的视音频和教师计算机屏幕画面,对各个智慧教室进行远程监看。教学保障管理系统可和其他系统对接,通过教学保障管理系统,实现集中管控,提高管理效率,实现对教室的精细化管理。
A)教学楼实况预览
可对教学楼栋进行综合管理,可以显示所有智慧教室及受控设备的运行状态;实时监测智慧教室设备使用状态,方便对智慧教室的任一多媒体设备进行远程管理,管理界面图表化显示。可远程控制投影机延时开关机、幕布升降、音量加减、中控开关等功能。
教室设备为主的总览界面,可实时看到各个教室设备的运行状态,绿色表示运行,灰色表示关闭,红色感叹号,表示设备出现故障。学校的运维管理人员可根据此界面的显示,可对于电脑的关机、投影机开机异常、关机异常、使用异常,投影幕的操作不当、电机故障,电话的运行状态等进行实时监控并反馈系统获取设备实时状态并反馈给后台管理端,管理员可随时查看设备使用情况,若出现非正常状态时可以给出提示,实现对设备的监测及告警。
在课前对教室有故障的设备进行提前的维修或者替换。避免老师上课时发现设备出现问题,影响正常的教学,可对故障设备进行故障报修。
灯光控制:
教学保障管理系统,能通过本地平台控制灯光的开关同时也可远程关闭灯光,对智慧教室里的灯光进行统一并精细化的控制,如实验里没有人,但智慧教室灯却是开的,可在移动端登录后台在任意位置关闭灯,实现节能。
空调控制
空调是智慧教室耗电非常多的设备,教学保障管理系统,能通过本地平台控制空调的开关同时也可远程关闭空调,保证空调在非活动时间段是全部处于开关闭状态的。
B)巡课管理
在智慧教室内安装摄像机管理平台视频监控中心可以通过网络的形式将前端摄像头的视频图像调取过来,在同一套管理平台中实现安防监控,可实时监看、监听各个教室和走廊的情况,完成对智慧教室设备的监看,也可通过网络完成对教师的教学评估。可远程控制智慧教室内的管理设备。
画面显示
画面显示
画面显示
设置轮巡时间
监考功能:
显示学生摄像机,也可9/4/1画面,以及轮巡;
IP对讲:
结合IP语音对讲和摄像机,可同智慧教室老师进行可视对讲;
视频督导巡课,集成智慧教室内部网络摄像头可在终端实时查看视频影像助力高校开展教学督导巡查,正常教学秩序不受干扰,和正在进行的课程。可通过后台服务器或移动端登录查看任意教室授课状态,可做6分屏、8分屏、9分屏等多画面;
C)课程管理
打通学校教务系统导入教师课程表,并可在后台随时对课表进行增删修改操作。教务系统的对接或手动课表的导入,都会在平台上呈现,可以通过不同维度去查看导入的课表信息,学期、周、教室查看课表情况,同样可以在线编辑课表。可与电子班牌课表联动,查看任意教室课表,进入课程编辑状态,可以手动输入授课老师姓名、课程名称、起始/终止时间;
D)远程升级
对各教学楼和楼层以及教室进行远程升级,选中所需升级的楼层和教室即可进行升级更新;
E)任务管理
如教室需要测试,则可点击「任务计划」,可以看到所需要测试的所有教室数量和测试时间;老师也可以对需要测试的教室进行编辑;如:通过此界面,管理员在特定时间,例如午休、放学、放假、期间,一键关闭教室设备,从而保障设备安全、节约能源。
F)系统日志
自动记录教师的使用情况,包括开启时间、关闭时间等,系统日志里可以查看到每间教室具体各项日志和具体刷卡记录;
G)资产管理
教学保障管理系统可以通过对教室里所有的设备进行资产登记,如:教学PC、笔记本、投影机、功放、音箱、一体机等信息,及时形成资产报表,可以对资产进行变更,使学校快速准确的掌握自身的IT资产状况,提高管理效率。同时可以在计算机的硬件和或软件配置更改、投影机灯泡需要更换时向服务器发出警报,这个功能真正实现了资产管理,它可以让管理员做到随时监视资产情况。
除了可以进行基本的信息收集,还能进行分组条件查询、报表输出等高级管理、统计工作,提高整体的管理效率。
教学保障管理系统可检测能对投影机灯泡使用时长进行统计、投影机本次工作时长进行统计、累计工作时长、功率及耗能进行统计可检测教室端幕布的使用状态,确认是处在上升/下降/停止。且可形成资产统计报表。同时能根据课程表及自定义时间规则实现对设备的操作
可查看设备品牌、购买时间、使用寿命等具体信息;也可以对设备的具体信息进行编辑修改;设备资产管理界面,显示教室各种设备,可对设备的添加、借还、维修、报废等功能,并形成图表及日志,为后续的设备的更新换代提供数据支持。
H)门锁管理
通过对物联网技术的有机融合,智慧教室环境控制模块中门锁系统功能将面临前所未有的改革以及提升,智能化以及统一管理将成为门锁系统的重要特性之一。教学保障管理系统可与智能门锁对接,对各智慧教室实现远程开锁,也可点击「编辑」,对各门锁状态进行编辑提交;
统一管理平台可以根据前端智慧教室控制单元与后台的电子课表进行信息的收集与提取,从而根据一定的判断原则对门锁系统发送操作指令,当该智慧教室有课时,门磁会自动处于撤防状态,当到了学校规定关门的时间后,门磁会自动进入布防状态,通过融合到整个智慧教室环境的控制后,通过不同子系统的相互协调还可以根据电子课表内容提前10~20分钟(时间可以自定义)对相应的教室自动、统一的开门,允许学生进入教室;智慧教室门锁系统相对于传统的门锁系统,将更加的智能化、自动化、合理化,不但减轻了管理人员的负担,并可以通过一系列的设置操作,让整个门锁系统提高安全性,并减轻环境负担。
I)故障报修
故障报修,可查看具体设备故障情况,也可「新增工单」描述报备提交最新故障情况;设备故障可以设置提醒;
J)权限管理
教学保障管理系统可根据老师角色设置权限可对角色进行分配,分权限,分层级管理;
2.2.4 教学服务终端管理系统
对教室电子班牌以及其他各类教学服务相关的自助终端远程统一管理和可视化信息的播放展示,包含并不限于以下功能。
支持对电子班牌集中管理,可进行个体、分组、批量显示,定制开发不少于3个电子班牌显示页面,支持信息发布页面自定义。
支持对接采购单位教务系统,显示当前教室老师、学生及课程相关信息,支持显示非课程使用的教室预约信息。
支持个性化信息发布,可发布定制化页面、视频、图片等。
提供后续新增类别设备接入接口。考勤签到与身份识别。
考勤签到,包括常规签到、走班制签到、签到查询、考勤统计。
考勤方式可分为卡片刷卡考勤、RFID考勤和人脸识别考勤。
班主任通过后台查看该班级的考勤信息,可以按照时间段查看并打印考勤记录。老师通过手机可以按日期统计查看考勤记录,每天考勤报表实时微信通知老师。
考勤签到与身份识别。
可实时显示考场信息,包括科目、时间、考生年级、监考老师等相关信息,让考生快速的找到相关考场。
考勤签到与身份识别。
和上课考勤签到功能类似,考生和监考老师通过刷卡、RFID识别及人脸识别将自己到场的信息录入系统,系统以此分析判定考生和监考老师是否在规定时间内到达正确的考场,是否出现迟到、走错考场、缺考等情况,并将其记录整理存储以便后期查询。通过考试人脸实名身份验证功能,提供活体检测、人脸、身份证比对,确认考生本人与准考证照片一致,避免出现代考行为。
权限管理。
权限管理,可以划分为不同的权限,包含管理员权限、班主任权限、管理权限。实现不同角色分组具有不同的权限,使用和管理不同的功能模块。
教室管理。
根据学校物理教室位置创建组织分部架构,创建每个教室名称,根据教室属性可以绑定班级。每个教室可以添加教室内的监控视频流地址,供上课时巡检老师查看室内情况。
班牌机管理。
班牌机管理,支持自动扫描添加设备,与多媒体设备管理结合自动导入教室的设备管理中。设备按楼层分组按教室命名,支持检索查询功能。
教师管理。
教师管理,创建、修改、删除教师信息。教师信息可以通过教务系统导入和人工导入,也可以后台添加,支持检索查询功能。
学生管理。
学生管理,添加、删除、修改学员、ID(学号+密码+手机号(附加))、RFID卡号、备注信息,可以把一个学员从一个虚拟班级中晋升、降级至其他虚拟班级中。
考勤签到。
签到考勤,包括签到、签到查询、考勤统计。
签到
可通过模板设定签到模块在首页显示与不显示,考勤时间段由后台统一设定。
签到读卡、自动拍照在1秒内,打卡时显示持卡人信息及打卡记录及照片内容,考勤时间段内支持重复打卡,更新照片信息及打卡时间;考勤时间外,刷卡自动跳入个人查询界面。
考勤时只能在本教室的班牌机上打卡,其他教室上的设备将无法打卡。
签到查询
班牌机首页的签到区显示正常、迟到、早退、缺卡、请假等5种状态的数据,定期刷新。通过个人信息查询中可以查看个人考勤记录,查询状态下,提供触控超时时间倒计时,超时自动注销返归首页。
后台查询可以选择日历查看某一天的考勤信息,可以查询学生考勤记录,并打印。
考勤查询能查看到所有考勤时学生打卡的现场画面,以核对人员信息。
考勤方式。
卡片刷卡
采用卡片贴合读卡器的考勤方式,是市面上比较常见的考勤形式。通过主动的人为动作,将卡片与读卡器接触,达到读码考勤的目的。现我司设备读卡器为复合型读卡器,可读的卡片类型有IC卡、CPU卡、NFC卡等。
优势:
刷卡考勤为市面上非常常见的考勤形式,品牌多样,实现技术简单,成本较低;
识别速度较快,灵敏度比较高;
对使用环境要求较低,能适应比较恶劣的使用环境。
人脸识别考勤
采用人脸识别算法技术,通过摄像头抓拍人像进行数据比对,从而达到考勤的目的。
优势:
人脸识别技术是现代比较先进的技术,通过人脸识别算法,可达到精准的数据识别和对比;
人脸识别有效的避免了代打卡的情况出现;
人脸识别无需考勤人额外佩戴设备,减少了硬件成本,也避免了由于硬件丢失造成的无法考勤的情况;
人脸识别的维护主要是对数据库的维护,减少了人工维护的成本。
考勤统计。
考勤统计,通过后台查看该班级的考勤信息,可以按照时间段查看并打印考勤记录。
课程表。
课程表包括:课程表展现和课程表管理。
课程表展现
课程表展现,通过模板设定课程表模块在首页显示与不显示。学生通过点击,可以按照日期查看每天课程内容。
课程表管理
增、删、改灵活后台编辑课程表,可设置老师审核权限,老师也可以授权某一学生审核与管理。
公告消息。
消息管理管理模块是将一些消息及时发布到终端上,包括欢迎词、公告、跑马灯、倒计时、考试信息。
公告消息,包含公告展示和公告管理。
公告展示
公告展示,区域显示公告时,如有多条消息,自动定时切换。点击公告区时,全屏展现可查看多条公告。领导欢迎词可全屏展示和区域显示,按时间定时显示。
公告管理
公告管理,分权限、分级别管理、有全校统一公告,有老师对班级发的公告。公告发布可以设置是否审核,不同老师在公告管理中只能看到和管理自己的公告。
个人信息。
个人信息,学生可以在学校任意班牌机上进行个人信息查询,查看个人信息时,提供触控超时时间倒计时,超时自动注销返归首页。
2.2.5 教学数据资源管理系统
我司承诺汇集采购单位教学相关数字资源,建立跨部门、跨系统、跨介质、跨平台的互联互通机制,实现数字资源快速、无缝、智能的流转与应用,建设完成后的系统包含并不限于以下功能。
开发完成后的系统支持对接采集各子系统数据,包含但不限于基础数据、考勤数据、课堂数据(能采集所提供的硬件系统在教学过程汇总涉及的课件、音频、视频、板书等数据。我司承诺向采购单位开放开关机、数据交换、状态监控等通讯协议和报文格式等设备级接口)、教室使用数据、设备操作日志数据、师生系统操作数据、巡课数据、作业数据、资源数据等,实现对教学资源数据、学情分析数据和服务资讯数据的存储、清洗、自动分类标注及汇集加工。我司基于系统二次开发,采用资源树概念对资源进行分类集中管理,对数据进行结构化管理,对于大体量数据资源采用大数据技术进行存储,保证客户教学资源数据得以完整保存。利用知识管理功能,实现对相应数据清洗和自动分类标准。
开发完成后的系统实现教学资源数据按课头进行分类汇聚,在各类数据资源分别存储的基础上,我司承诺系统支持课堂画面合成,至少包含板书、电脑画面、教师全景、语音转写(预留接口)等,支持各课程管理员自定义合成内容。我司基于标准接口规范设计相应接口,为数据共享和处理提供相应基础。
开发完成后的系统支持查看各课头、各课程资源建设详情,如资源类型、资源总量、下载次数等,并图表化展示。我司二次开发将支持内置资源建设分析图表,以可视化的方式呈现相应内容。
开发完成后的系统支持定义和管理数据采集任务,设置任务基本信息、上传和管理数据采集流程设计文件、配置任务执行策略。支持对采集任务执行情况的监控,并支持启动、暂停、重启任务等功能。我司系统二次开发将提供任务管理功能,提供任务策划,支持用自定义数据采集和管理任务,支持设置相应条件自动触发执行任务,也支持用户手动启动、暂停、重启任务,对任务执行的情况以可视化图表方式进行展现。
开发完成后的系统具备数据清洗、数据转化、数据提取、数据计算功能。我司利用知识图谱功能从异构数据源抽取数据本体,进行局部数据本体和领域数据本体等知识数据构建,并利用本体集成和实例匹配等技术进行知识融合,实现对数据的清洗、转化、提取、计算,从而得到知识图谱,并进一步通过实体链接丰富知识图谱,形成业务知识谱系,利用大数据平台,实现知识图谱在大数据处理平台中进行分布式存储、查询、语义搜索、文本搜索等智能应用。
开发完成后的系统提供可视化分析数据及图表。我司提供含报表和大屏设计器,像搭建积木一样在线分析数据及设计相应报表。系统功能涵盖数据报表、样式设计、图表报表、大屏可视化设计等。
我司提供Web 版报表设计器,类似于excel操作风格,通过拖拽完成报表设计。通过SQL、API等方式,将数据源与模板绑定。同时支持表达式,自动计算合计等功能,使计算工作量大大降低开发效率很高,傻瓜式在线报表设计,一分钟设计一个报表,又简单又强大,系统支持 ECharts各类型图表,能够进行在线拖拽设计,支持SQL和API两种数据源。
支持分组、交叉,合计、表达式等复杂报表
支持打印设计(支持套打、背景打印等)可设置打印边距、方向、页眉页脚等参数 一键快速打印 同时可实现发票套打,不动产证等精准、无缝打印
图表设计器支持几十种图表样式,可自由拼接、组合,设计炫酷大屏。
报表设计
图表设计
开发完成后的系统将教材数据纳入资源管理,并具备教材管理功能,支持出库、入库、查询、统计功能。
开发完成后的系统开放数据输出接口,可为第三方软件提供数据。我司承诺依据客户要求提供开发数据输出接口。
教学数据资源管理平台是一个大型复杂的计算机网络信息系统,我司采用基于浏览器/服务器(B/S)应用体系结构来建设教学数据资源管理平台,使真正实现多样化。满足各类现在和将来对信息资源采集、存储、处理、组织、管理和利用的需求,实现信息资源的高度集成与共享,实现信息资源的集中管理和统一调度。为各级决策管理部门提出准确、及时的相关信息和快捷、方便、科学的决策分析处理系统;为信息交流、教务管理提供一个高效快捷的电子化手段;最终达到进一步提高各级领导科学决策水平,提高各院系、各部门管理人员管理水平与办公效率,减轻工作负担的目的。
通过教学数据资源管理平台,实现在线备课等应用。支持对课前阶段教学数据的生成、录入、输出与检索操作。能够实现课前学情统计分析、教学资源推送、教学设计、教案撰写与归档。提供课件素材模板库、互助类教学和可视化数据分析工具,为教员全面掌握学员情况、共享与优化教学资源提供支撑。
A)课前学情统计
课前练习,作为收集和反馈学员知识掌握情况的重要手段,在课程教学当中起到了非常关键的作用。教员可通过布置课前线上练习,通过课前的预习训练快速获取学员的反馈和统计分析数据。
B)教学资源推送
基于课前的线上课程教学,教员可依据课程结构发布对应的线上学习资料和布置线上作业,学员完成课程学习和练习之后,教员可查看学员的学习进度和作业完成情况,进行批改分析,并针对学员学习情况开展线上答疑和讨论。
C)课程教学设计
教员可自主进行课程建设和教学设计,可根据自己的课程进度和安排自定义课程结构,上传教案,设定教学目标、教学重难点和进行教学总结和反思。
D)教学资源归档与共享
教员通过线上的教学设计,可自由进行资源库建设,通过教案、课件资源的上传和归档,形成自己的教学资源库,基于教学资源库,还可进行教学的应用、推送和共享。
E)教学数据可视化
教员进行在线备课,通过教学设计、发布预习、进行资料推送等一系列活动,均可自动进行记录并形成可视化数据,为教员全面掌握学员学情提供支撑。
2.3 流程图
2.3.1 实施流程路线总图
乙方为应用的软件实施项目提供了面向过程、清晰的、准确的实施路线,这个路线起到了项目实施向导的作用,用来确定步骤,明确接口,并且用来设定项目的进度,使得以最优的资源和预算,快速高质量的完成系统的实施。乙方软件系统实施主要包含以下几个阶段:项目售前、项目启动、项目策划、项目执行、项目验收和售后服务。
图8- 3实施路线总图
2.3.2 售前阶段
1)目标/任务
图8- 4售前阶段
售前阶段是为客户提供管理方法、业务运行上的咨询,软件系统为客户带来的价值,最终目标是签订合同。
具体的工作包括:初步的了解客户的情况,为客户提供基本的解决方案,演示系统并提供最佳实践经验。提供报价、拟定投标书以及签订合同。
1) 流程及规范
图8- 5流程及规范
2.3.3 启动阶段
1)目标/任务
启动阶段的主要是为了项目启动后项目能顺利的执行,制定明确里程碑节点、明确的管理规章制度、明确的组织及职责等。
具体的工作包括,确定甲乙双方的项目团队及职责、售前团队与项目经理交接、制定项目的管理计划书、召开启动会宣布项目的管理计划书。
图8- 6项目启动
2)流程及规范
图8- 7流程及规范
2.3.4 策划阶段
1)目标/任务
图8- 8目标/任务
2)流程及规范
图8- 9流程及规范
2.3.5 执行阶段
1)目标/任务
图8- 10目标/任务
执行阶段的目标是为客户提供一套符合客户特点的应用系统。
主要依据前期的策划方案、软件工程的标准方法,制定具体的任务,本阶段的任务包括:系统概要设计、详细设计、代码开发、测试验证、试运行和正式上线。
2)流程及规范
图8- 11流程及规范
2.3.6 验收阶段
5)目标/任务
验收阶段是让用户方负责人对合同中规定的系统功能、文档等等进行验证的过程,是整个项目结束的最终节点。验收后,将进入到后期服务阶段。
验收主要将前期工作中产生的文档进行整理,根据用户具体的验收要求进行修改、完善、补充,准备验收申请、验收汇报的PPT等,召开验收会议并签署验收报告。
6)流程及规范
图8- 12流程及规范
2.3.7 售后服务阶段
7)目标/任务
软件信息系统是一种特殊商品,售后服务工作的好坏直接影响系统的使用效果和使用价值。售后服务是为了保障系统的稳定运行,所提供的及时、优质的服务,是用户能把系统正常使用起来,真正发挥系统作用。
图8- 13目标/任务
8)流程及规范
图8- 14流程/规范
由乙方项目经理指派一名支持人员,建议该支持人员从本项目实施团队中指派。要求对该项目非常熟悉、技术水平和沟通协调能力达到一定程度的人员。
甲乙双方项目经理共同制定售后服务流程及规范,包括问题提出的方式、审批的流程,响应的方式等。
技术支持人员在现场处理时,对程序修改记录、修改后的程序等进行测试、记录、并争得甲方项目经理的签字后备案。
2.4 系统灵活配置、便于用户直接维护
2.4.1 平台扩展
2.4.1.1 平台扩展性
(1)平台开发扩展性
平台通过后端接口和前端扩展机制来满足业务系统的定制化需求。在后端接口上,除了使用Java传统的继承机制扩展外,平台还提供了前后拦截器的机制,业务代码通过实现平台的拦截器接口即可实现业务上的扩展;在WEB前端扩展机制上,平台采用了extend文件夹。可通过接口的扩展来实现外部程序包的扩展调用。
平台自身实现组件化开发,采用微内核、插件化的体系结构,易于积木式组装、扩展和升级。符合组件化规范新研组件均可无缝集成到平台中运行。全组件化结构设计,使每个组件都被独立地实现,并通过标准接口联系在一起。每个功能组件在功能上独立,同时可根据用户需求灵活配置、组合,实现平滑升级扩容,功能实体可使业务和开发人员根据具体使用要求增加或减少系统应用模块。
平台采用标准统一的接口设计,所有功能实体间的数据交换以及对其他模块的数据引用都通过标准接口完成,使多个组件对接时在开放性、稳定性、扩展性与集成性上有着很好的适配空间。平台系统处理组件化结构设计与标准化接口设计以支撑开放体系结构外,为了方便用户个性应用的开发,还封装系统及其组件所需的二次开发应用工具包,使其他技术团队对平台进行二次开发时能够更好地复用。
平台的分层架构设计,采用横向分层和纵向分割架构设计。将层与层之间相互分离,每层的应用和服务,采用独立的模块开发和部署,模块间交互标准化,新增功能模块分解到各层,以插件形式加入原系统,既不影响整体架构,也不影响本层功能提供,具备高模块化设计,保证了系统功能的可扩展性;纵向分割将业务和可复用服务分离出来,通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑,而对现有产品没有任何影响。可复用服务升级变更的时候,也可以通过提供多版本服务队应用实现透明升级,不需要强制应用同步变更。
(2)平台运行扩展性
平台部署时,考虑实际应用在一台服务器上能提供服务能力总是有瓶颈,当出现性能瓶颈的时候可添加服务节点来提高系统的吞吐量。平台相对于业务规则来说都是无状态的,每台服务器之间都是对称的,这样可以很方便的在负载均衡设备F5、NGINX或LVS下动态的添加、删除节点,保障水平集群部署的弹性扩展。部署和升级的扩展性:平台组件采用开源成熟核心项目,软件系统可运行于通用的主流硬件平台上,不依赖于特定的、专用的硬件设备或者系统软件。系统配置(硬件系统、操作系统、数据库系统)的升级一般情况下,不会引起系统的修改和再次开发,适应于任何硬件平台。
平台基于组件化服务化的架构技术,支持应用系统运行时横向扩展部署,或按照业务组件分布式部署。平台支撑软件集群架构部署,可实现系统多台应用服务负载均衡;单台服务器发生故障后不影响用户的正常使用。平台可支撑异地多台应用服务器分布式部署,同时可以横向任意扩展部署。平台组件化服务化的架构技术,可支撑基础服务组件任意拆装部署,实现应用和数据的集群分布式部署。平台支撑数据库集群化部署,保证运行时的扩展性。
2.4.1.2 服务实例扩展
(1)微服务架构
平台微服务架构是实现业务架构服务化的技术基础。具有细粒度、去中心化的特点,可以解决更新迭代的影响范围、代码腐化、服务局部弹性、沟通协作瓶颈等问题。
微服务架构可使用一套小服务来开发单个应用,每个服务运行在自己的进程中,使用轻量级机制通信,通常是 HTTP API。由微服务开发的服务实例具有以下特点:
解耦灵活:微服务架构组件间更解耦,相互影响最小化。
专业专注:每个服务组件可由一个小团队负责开发。
扩展性强:依据业务性能要求,关键服务可独立于整个系统水平扩展。
语言无关:微服务架构与语言工具无关,自由选择合适的语言和工具。
服务重用:真正实现服务重用,业务服务不断进化,沉淀为 IT 资产。
微服务促使原单个业务系统服务实例被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。因此服务组件的粒度大小会直接决定业务系统的质量,在拆分服务组件时,基于如下四个维度:
1)基于业务逻辑拆分:将系统中的业务模块按照职责范围进行识别,每个单独的业务模块拆分为一个独立的服务。
2)基于稳定性拆分:将系统中的业务模块按照稳定性排序,将已经成熟和改动大的服务拆分为稳定服务,将经常变化和迭代的服务拆分为变动服务。提升项目快速迭代的效率,避免在开发的时候不成熟的功能导致的线上问题。
3)基于可靠性拆分:将系统中的业务模块按照可靠性优先级排序,将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来,然后重点保证核心服务的高可用。避免非核心服务故障影响核心服务,降低高可用成本。
4)基于性能拆分:将性能要求高或者性能压力大的模块拆分出来,避免性能压力大的服务影响其他服务。
(2)容器化与扩展
在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,平台在此基础上通过整合从开发到运维的工具链,实现Docker镜像的管理、服务管理、API管理、监控告警管理、CI&CD集成管理,通过控制台单一入口组件为客户提供应用支撑平台。
图2- 20 CI&CD的整体流程示意图
开发人员可在应用程序和运行平台这两层进行应用程序的编码、构建、测试和发布;
测试人员可进行环境的快速搭建,测试环境的一致性和持续集成等工作;
运维人员可进行从硬件、操作系统到运行时平台的安装、配置、运行监控、升级和优化等工作。
开发使用不同的镜像服务部署开发环境,方便本地开发环境的搭建和一致性;
测试通过使用镜像完成服务持续集成,简化测试环境的搭建;
运维使用同一份镜像服务部署,保持环境的一致性,也可以制作镜像并进行快速部署;在应用大流量的情况,能做到秒级的扩容。平台的应用构建服务处理CI过程,将输入源包括源代码或Docker镜像或应用市场应用进行解析、编译、打包,最终生成应用(服务)抽象介质。
传统意义上说,完整的CI过程会包括:设计、编码、打包、测试和发布,Docker镜像自推出以来逐步成为众多应用代码打包的新形式。现有的CI产品中已经在源码测试和Pipline方面做得非常成熟,例如Jenkins,Gitlab等,平台在对于源码或Docker镜像的前置处理方面可以直接对接第三方服务,由第三方服务处理完成的源码或镜像再对接到平台中进行应用抽象。
平台应用抽象的输入源是支持Git、Svn协议的代码仓库,Docker镜像仓库。当输入源代码,平台智能判断源码的类型,例如Java,Python,Dockerfile等,根据不同的源码类型选择对应的源码构建器进行源码编译,同时识别源码中定义的运行环境要求参数,应用端口、环境变量等参数,形成应用抽象的配置雏形。除了Dockerfile以外的源码类型将被编译成应用代码环境包存储于分布式存储中,其他的生成Docker本地镜像存储于数据中心镜像仓库中,结合应用的各类属性信息形成应用抽象包方便进行扩展使用。
2.4.1.3 接口标注规范
平台使用RESTful 框架、符合JAX-RS标准、模块使用注解实现服务化,同时平台提供了统一的传输报文格式,并且所有的组件都有服务发布,使用时只需注册即可,这样为系统集成提供了统一技术规范,为移动互联接入提供了方便。
Rest服务接口发布规范:
在类头必须添加注解@RestEasyController,目的是为了平台框架自动快速加载服务类。
注解@Path的写法要符合规范:即/api/子系统名/组件名/服务名。目的是在整个产品里该服务名不会冲突,同时通过服务名可以直接定位到具体的Java类。
Rest服务的报文格式平台有统一的规定:
其中:任何返回消息必须以ResponseMsg包装。
图2- 21 Rest报文
基于平台开发的所有rest服务都必须符合此报文规范。
其中:responseBody:类型为泛型,传递业务对象信息,数据格式为JSON。
retCode:为状态码,系统目前200(成功)、404(找不到资源)、500(服务器内部错误)这几种状态码,开发者也可以返回自定义的状态码。
errorDesc:为异常信息描述,该信息默认由平台异常拦截器自动封装,当然开发者也可以自定义异常信息。
(1) 带查询条件且分页获取数据的服务开发必须符合如下规范:
输入参数必须符合QueryReqBean类型报文结构:
图1. 图2- 22 QueryReqBean类型报文
输出参数必须符合QueryRespBean类型报文结构:
图2. 图2- 23 QueryRespBean类型报文
注意:平台的Rest服务需要安全认证才能访问,所以必须设置Authentication为Basic Authenticaton,弹出框里需要输入用户名和密码,该用户名和密码是平台rest-client.xml文件中的username 和 password。
(2) 对于Rest的其它用法,平台没有做任何限制,具体请查阅RestEasy的官方文档或者JAX-RS 2.0规范文档。
(3) Rest服务调用方法
V6R3+系统间的服务调用
直接调用V6R3平台的RestClient类的doPost和doGet接口即可。
其它系统跟V6R3系统间的服务调用
使用HttpURLConnection进行连接一样,但由于调用V6 rest服务时需要进行身份认证,所以需要将验证信息设置到请求属性中:
httpConn.setRequestProperty("Basic", "avicit2015");
httpConn.setRequestProperty("Sign", EncryptUtil.MD5("avicit2015: avicit2015"));
其中“Basic”属性为rest注册用户名,“Sign”属性为rest注册密码,是通过用户和密码进行MD5编码后得到的。
2.4.2 二次开发底层平台基础功能
2.4.2.1 配置功能
平台具有丰富的配置功能,能够根据业务需要配置菜单、功能、服务、资源、权限,功能操作简单、易用性好,支持向导式操作说明。
菜单配置:
可实现系统界面主题风格的自定义设置,平台的主菜单界面可以通过用户角色与权限等相关配置进行个性化调整,系统功能也可以进行个性化配置使平台开发与使用人员更方便操作。
资源权限配置:
权限分配和控制是整个系统核心功能,支持按照角色授权,不仅可以对系统菜单进行权限控制,还可以对菜单页面的各个HTML元素标签进行控制,以及页面上各种AJAX请求资源进行控制。在多应用环境下,可以实现多个应用系统权限的集中管控和授权。
前台菜单授权。系统管理员在菜单管理页面,添加的前台菜单,前台用户是无法使用的,需要安全管理员在前台菜单管理授权中给相应的角色授权后,该角色下的用户才能有权限使用这些前台菜单。
2.4.2.2 动态建模
平台支持动态建模能力,提供快速构建客户级应用需要的组织、人员、权限、流程、调度任务等功能,通过权限设置、流程装配、UI模板设计等工具快速生成业务系统需要的功能,支持具体应用的开发、定制和创新。
组织机构管理
平台提供组织机构建模,可用来添加、编辑组织和部门信息,维护组织与部门的层级关系等。通过使用组织机构建模工具,用户可全面、准确描述出客户组织机构关系。
人员用户管理
平台提供用户建模,该组件主要用于机构、部门、岗位、人员信息的增加、删除、修改、查询等管理功能,支持客户多级机构模式;支持一人多岗、兼职部门、用户锁定、密码恢复等功能。
角色管理
平台提供角色建模,该组件主要是用来管理角色信息。包括添加、编辑角色,维护角色与用户的关系等功能。通过门户配置模块可以实现不同角色的用户具有不同的显示界面和功能菜单。
权限管理
权限分配和控制是整个系统核心功能,支持按照角色授权,不仅可以对系统菜单进行权限控制,还可以对菜单页面的各个HTML元素标签进行控制,以及页面上各种AJAX请求资源进行控制。在多应用环境下,可以实现多个应用系统权限的集中管控和授权。
流程管理
平台提供可视化的Web版流程设计器,无需安装插件,可以在IE8+、Chrome、firefox等多种浏览器下运行,支持人工活动、分支合并、子流程、Java活动等多种节点类型,即使是不懂IT的业务人员,无需编码,也可以轻而易举完成流程搭建,最快只需要3分钟配置一支流程,鼓励业务人员自由设计流程和部署。
调度任务
定时任务是以Quartz为基础实现,经过对其扩展、深度集成后作为平台中的定时任务模块供开发人员使用。此模块提供可视化的任务管理界面,用于对定时任务进行诸如添加、编辑、删除、启动、暂停、查看运行历史等操作。
2.4.2.3 快速开发
基于业务基础平台的应用快速开发,使得“零技术”背景的业务人员通过采用零编码的方式,运用平台电子表单与代码生成器等组件,基于可视化的操作与灵活配置,打通业务流程从设计到代码生成的快速开发,实现业务需求快速变更与应用开发的快速迭代工作。
快速开发特点:
1)基于WEB的可视化业务流程场景与表单设计,开发不受环境、地点的限制;
2)工作流和管理功能的无缝结合,基于流程驱动的协同管理,满足随需应变的软件落地;
3)平台开发的功能将伴随平台升级平滑过渡,开发功能可以快速迁移;
4)对开发人员要求降低,只需熟悉简单SQL和业务逻辑;对于“组件、继承、多态”等复杂IT知识的要求降低,使开发和维护成本大幅降低;
5)强大流程定义功能,对业务逻辑、业务流程梳理再造、流程设计、流程配置、流程触发和归档等提供快速低成本的实现;
6)提供通用、成熟的组件库,方便用户组织管理独有的公共组件,提高组件重用性;
7)提供丰富的表单设计功能,通过模板与拖拽操作,快速构建从流程到表单的应用;
8)优化后的一体化建模工具提供代码自动生成功能,通过使用该功能,用户只需要选择业务数据表,即可创建出针对此数据表字段的新增、修改、删除、查询功能模块。
快速生成业务系统工具
平台通过代码生成工具、可视化流程设计器、交互式表单建模工具和视图建模工具、报表工具、开箱即用组件来满足业务功能快速定制开发及创新。
(1)代码生成工具
为提高的代码复用性,达到敏捷开发的目的,平台提供代码生成工具,面向业务人员、开发人员,以向导的方式,根据设计好的业务表,利用标准业务模板快速生成可运行的业务代码(前台、后台)。工具操作简单,支持多套业务模板、可视化视图,代码结构清晰,可统一规范代码、提升代码质量。
平台基于“可交付组件”模型,用来规范组件资产的开发、交付、管理、监管和再利用。基于代码生成工具开发的组件自动符合组件化规范,可以在平台运行框架中即插即用。运行时框架基于Java注解技术和智能识别技术,可以自动识别组件,零代码修改。平台功能的组件化,保证其平滑升级,方便其扩展。
丰富的应用模板包括:单表、单表带附件、单表带流程、主子表、主子表带流程、单表树等可视化开发模板,降低开发人员入门技术要求,将开发效率提升近40%。
(2)交互式表单建模工具和视图建模工具
Form Designer是一款可视化的Web表单构建器,HTML元素组件较丰富,可通过拖拽的方式生成完整可用的表单,支持多种样式、预览、打印等功能,可以生成物理代码,保证业务定制的灵活性。业务人员即使不懂编程技术,也可快速设计业务表单。视图建模工具View Designer,是一款可视化的Web界面视图构建器,支持表格、树、表单、页签等多种页面组件的自由布局,并可以设置组件间的数据联动关系。通过该工具,设施人员无需编码,就可交互式地完成页面视图的开发。
(3)报表工具
报表工具主要由报表设计器(设计模板)和报表服务器(解析模板)两大部分组成,使用层次鲜明的三层结构体系搭建,通过关系数据库接口连接数据源,所有的业务处理都在设计器(中间层)中完成,并最终通过服务器解析展现给用户。
报表设计器可以进行表样、数据、展现、打印等报表设计文件中各种元素的设计,支持多种交叉报表、统计图表等,其中图表交互这一强大的功能,通过在图表中使用如信息提示、颜色高亮、钻取等来表达产品要告诉用户的信息,让用户获得更好更舒适的体验。
(4)开箱即用组件
平台提供丰富的技术组件和业务组件,支持热插拔的方式加载和去除,都以软件资产的形式存储在公司的资产库中,项目开发时,可通过查找和申请获得这些组件,按照组件的配置使用说明,将组件加入到项目中即可使用。
目前组件库已入库组件数量已经接近400个,并进行持续丰富和完善。
2.4.2.4 日志管理
平台支持记录系统详细的运行日志,支持分类存储、查询、分析功能。
系统的日志分为“系统功能日志”、“系统管理日志”,具备将系统信息的增、删、改、查等全部记入系统管理日志的功能,并支持对日志的管理和查询。
系统日志分为四种类型:
系统功能日志:业务功能模块运行时产生的日志。
系统管理日志:系统管理员管理系统时所做的系统管理操作所产生的日志。
安全管理日志:安全管理员管理系统时所做的安全管理和日志审计操作所产生的日志。
安全审计日志:安全审计员审计系统管理日志与安全管理日志时所产生的日志,由系统统一管理,禁止篡改及备份处理。
支持对应用系统进行全面而深度的后台监测,并智能、自动地进行业务恢复,实时监控系统中的业务状态,一旦监控到异常,会通过内置的脚本自动地进行恢复性的尝试,来恢复出现故障的业务系统,通常可在1-3分钟内可使业务自愈。
支持对日志监控报警,支持运行状态报警,针对资源的监控属性制定告警规则,在资源状态异常时发出警告,当异常触发时能够及时通过短信、邮件、系统消息、等方式通知相关负责人。不仅仅支持日志,也支持业务数据的异常。支持高级报警配置,可以自定义报警升级(escalation)、接收者、报警策略及报警方式,以及自定义扩展。
2.5 二次开发系统数据集成
数据管理与集成实现以下功能:从多个业务系统中整合最核心的、需要共享并保持一致的数据(主数据),对主数据集中进行的清洗和丰富,并存储到主数据库。各业务系统所有需要其它系统共享的数据,都从主数据库直接获取。主数据可以通过该平台直接发布到各业务数据库,也可以以服务或数据库用户的方式把统一、完整、准确的主数据分发给客户范围内需要使用这些数据的业务系统、业务流程和决策支持系统。数据管理与集成平台的引入便于IT顶层设计、实现统一数据架构。
2.6 实施周期
按照《招标文件》要求。项目总体建设周期控制在90个日历日之内。具体实施进度计划节点如下表所示。
表 具体实施进度计划节点及交付物
序号 | 里程碑名称 | 完成时间节点 | 交付物 |
1 | 完成用户需求调研 | 合同签订后15个日历日内 | 调研报告 |
2 | 完成系统需求设计、概要设计和数据库设计 | 合同签订后30个日历日内 | |
3 | 完成系统详细设计及实施方案评审 | 合同签订后40个日历日内 | 实施方案 |
4 | 完成系统开发及测试 | 合同签订后80个个日历日内 | 软件源代码、编译工具 |
5 | 完成系统部署及培训 | 合同签订后85个日历日内 | 安装手册、操作手册、维护手册、培训手册、案例导航 |
6 | 系统上线试运行 | 合同签订后90个日历日内 | 试运行报告 |
7 | 完成产品功能完善及项目验收 | 合同签订后270个日历日内 | 验收报告 |
乙方承诺在试运行期间,如系统出现重大故障,则试运行期从故障修复之日起重新计算,顺延三个月,若仍达不到要求,继续顺延,直到系统连续三个月无故障方可进行终验。我方须在合同签订生效后,按甲方整体项目的进度,在项目现场具备条件后90个日历日内交付试用。在全部达到要求时,双方签署终验合格证书。
2.7 文档资料
我方将提交包含但不限于以下资料:
系统项目实施计划;
系统建设需求分析报告;
系统建设方案;
系统测试报告;
系统的用户操作说明书;
系统验收报告;
原型软件安装介质(光盘版)。
2.7.1 文档具体资料
我方将提交包含但不限于以下资料:
系统项目实施计划;
系统建设需求分析报告;
系统建设方案;
系统测试报告;
系统的用户操作说明书;
系统验收报告;
原型软件安装介质(光盘版)。
3. 保障措施
针对项目不同阶段可能的应急事件,实行动态的全程跟踪。
(1)制定应急控制策略
应急控制策略是一组缓解风险可能产生的负面影响的活动。
制定应急控制策略有三个主要方法:
1)事先:这是一个在问题发生之前就消除解决可能风险的活动;
2)直接:这是一个在明显的损失发生之前,采取行动减少和使风险无效;
3)间接:这是被动的而不是主动的。它是在问题发生之后采取的消除和减轻灾害的措施。
(2)确定应急处置行动
协助下对登记于风险登记表中每项风险进行正式评价,并根据风险的影响和概率,在正确的时间实施最适合的风险减轻措施。
工作步骤如下:
1)如果没有明显的行动,并且风险可能不再对项目有影响,就关闭这项风险;
2)如果为缓解风险需要实行项目的变更,按照“问题处理规程”提出变更请求;
3)平衡项目关键三因素(时间,费用和质量)的活动,指派风险行动以缓解风险;
4)确定风险发生后的应急行动;
5)项目负责人将此风险计划通知给乙方。