热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

大型企事业信息管理系统非功能性需求&软件架构技术参考(转)

大型企事业信息管理系统非功能性需求&软件架构技术参考骆金松      管理信息系统总结起来一般有三种典型的架构模式,现取主要的几个非功能性指标比较如
大型企事业信息管理系统非功能性需求&软件架构技术参考
骆金松
  
     管理信息系统总结起来一般有三种典型的架构模式,现取主要的几个非功能性指标比较如下:
大型企事业信息管理系统非功能性需求&软件架构技术参考 (转)
  图:三种典型的架构模式
      一般产品模式比较适合有一大批功能需求极为相似的客户群,软件开发商所追求的是软件的边际效益,例如杀毒软件、办公软件、绘图软件等一般都具有很强的通用性,适合采用产品模式,在企业战略方面一般注重占有率,打造品牌,通过大量销售来降低单位成本。大型企事业单位的管理信息系统一般具有较多的个性需求,显然大多数情况下不适合。
      项目模式是另外一个极端,完全按企业的需求量体裁衣,但是也存在许多缺点:一般受限于开发团队的能力、投入财力等原因不按高扩展性和灵活性设计,影响系统的维护;一般实施周期很长,超过6个月很常见,有的甚至持续数年;需要保持一个较大的团队持续维护,总体投入较大;统计数据表明定制开发项目有超过50%的失败率,风险高。当然有时只能选择此模式,比如极个性的需求,找不到类似产品或平台。
     一个中间的模式是“平台”+“服务”模式,这种模式能够兼顾前两种模式的优势,公共平台以及大多数标准模块选配就可以了,在其之上通过二次开发、建模等手段进行个性化定制扩展,满足企业个性需求,是大多数大型企事业单位最合理的选择。大型企事业单位选型时,选择一个好的架构可能比功能齐全更加重要,因为这种模式下,个性需求可以通过“服务”加以满足,在满足个性化需求、降低总体拥有成本(非一次性投资)、提升未来的扩展和调整、与现有系统集成等方面可以良好平衡。 这里所说的服务是指专业的服务,与通常所说的安装、配置、培训和少量的二次开发是不样的,需要建立按行业分工的专业服务体系。
 
     现在许多企事业管理信息系统提供商都声称其软件是平台化架构的(鱼目混珠),可以满足大型集团性企业的需求,实际上这些产品的平台化水平参差不齐(大多数产品很差)。许多集团大型企事业单位在选型方面经验不足,重视功能性需求而忽视非功能性需求(我感觉十分明显),这是极端错误的。越是大型的企事业单位,在管理信息类系统选型时应该加大非功能性需求在整个选型评价体系中的比重,对关键指标一票否决。
    国内许多大型企业在信息化方面的投入惊人。有的企业就CAPP方面的项目就有17个,涉及到四次重新选型。有的企业规模不算大,就PDM产品就有3套,而且互相不集成,大多数都用的不好。其中许多是非功能原因导致的,我见过太多因为非功能性的原因导致系统最终失败的案例,其原因举例如下
(1) 采用了传统的C/S架构,不支持Internet,当企业规模扩展之后,只有更换系统,重复投资倒在其次,数据(知识)迁移和继承问题多多。如果每个地点分别实施几套C/S系统,则面临集成问题。
(2) 由于采用传统C/S结构,如未采用可降低数据库负载的集群和缓存的中间层服务器,企业数据量和用户数上升以后数据库服务器不堪重负,系统性能日益下降却无能为力。
(3) 系统的扩展性和灵活性不够,比如有局限性的工作流建模、非可插拔模块架构等,难以满足企业个性化需求扩展以及业务调整以后的随需而变,无法支撑IT战略,而今影响到企业战略的调整。有些企业是两层皮,企业完全没有按IT系统运行。
(4) 一些企业完全定制开发自己的信息系统,有全套的源代码,自认为系统就容易扩展和调整,其实这样的系统一般都未按扩展性和灵活性来设计架构,一旦核心成员离职、文档不齐全造成的后果更严重。
      
    一般而言,大型企事业单位对管理信息系统选型时应考虑如下非功能性需求: 
(1) 海量数据高并发:一般集团性、大型企事业单位的用户为数千和数万甚至更多,而涉及的数据量也可能数TB甚至数十TB,应明确提出应用条件下的性能要求。
(2) 基于Internet分布式应用:一般大型企事业存在多个分支结构,跨越城市、省甚至国家,一般需要基于Internet,传统的C/S模式无法满足需求,必须处理好集中管理与分布管理的关系。
(3) 异构系统的集成:一般大型企业存在较多的各类信息管理系统,而且可能是异构的,不同的操作系统,不同的架构技术等,所以如何实现与诸多信息系统的集成是一个挑战。
(4) 业务流程自定义:为了开展新业务或对现有业务进行优化,系统应该提供强大的业务流程自定义功能,必须与表单、权限、任务管理、email等进行紧密的集成。
(5) 全面的个性化定制能力:除了考虑业务流程自定义外,还应该考虑数据结构自定义、功能模块自定义、表单自定义、报表自定义、主菜单和主页自定义、权限自定义等。
(6) 架构的随需而变:对于大型集团性企业而言, IT必须快速适应IT战略,IT战略必须快速适应企业战略。除了全面的个性化定制之外,系统的架构设计必须具备随需而变的能力,否则IT会***企业。
(7) 安全性:略
 
    我将大型企事业单位的非功能性需求简单图示化总结为如下几点:
大型企事业信息管理系统非功能性需求&软件架构技术参考 (转)
图:大型企事业单位的主要非功能性需求
    要给出一个最合理的大型企事业信息管理系统的软件参考架构技术是不可能的,事实上不存在所谓的最优参考架构,基于成本、进度、功能需求、非功能需求、技术条件、人力条件、外部条件等综合最优的架构是最好的架构。基于我们的经验,虽然不存在最优参考架构,但是存在一些最佳实践,具有参考价值,欢迎讨论
指标
建议
部署
建议采用B/S(浏览器/服务器)模式,或Smart Client(智能客户端)模式。比如XBAP就是Smart Client的一种,对于企业应用可以相对B/S模式提升交互式体验。Silverlight也是一种智能客户端技术。
高并发、海量数据、性能
建议三层及以上架构:中间层采用集群、负载均衡、缓存等技术。表示层采用延迟加载、多线程、异步、分页等性能优化技术。数据库采用SQL性能优化、索引、分区表、物化视图、磁盘阵列、集群、数据仓库等技术。低带宽还可以采用压缩传输。
高可用性
看是否有高可用性要求。比如建立高可用性集群,在整个服务不中断的情况下对服务器软硬件进行维护,可以将集群中某台服务器暂停使用,进行临时性维护,比如可动态向高可用性集群中添加和移除硬件等。
安全性
加密传输、加密存储、电子签名、身份认证、访问控制、备份恢复、分级管理、审计管理等。
安全性对于大型集团型企业的重要性不言而喻。
分布式、集成
系统自身基于SOA(面向服务的体系结构),SOA提供分布式通信编程框架,这对于集团性和大中型企业,复杂的应用环境和集成的需要是非常重要的。
另外提供良好的集中式管理与分布式管理的支持。一般小型系统采用集中式管理,对大型企业而言集中管理是无法实现的。而缺少集中管理则会加大管理的难度,提高管理成本。
扩展性、灵活性
基于平台和插件体系构建。
平台上提供较多的标准可选模块(可按领域或行业细分),而不是完全定制。
采用主流的二次开发环境和语言进行开发。
提供工作流建模能力,最好是成熟商用工作流引擎。
最好提供数据模型的扩展能力(往往被忽视),最好是面向对象的。
提供各种表单的定制能力。
状态模型(或生命周期模型)与权限、流程、数据等紧密相关,最好也可以定制。
主菜单和主页(类似Web part)、菜单等UI界面可以定制。
最好权限模块也具有扩展能力(不同数据类型不同)。
集成开放的商用报表引擎(比如水晶报表)。
 

推荐阅读
  • Android中高级面试必知必会,积累总结
    本文介绍了Android中高级面试的必知必会内容,并总结了相关经验。文章指出,如今的Android市场对开发人员的要求更高,需要更专业的人才。同时,文章还给出了针对Android岗位的职责和要求,并提供了简历突出的建议。 ... [详细]
  • 一句话解决高并发的核心原则
    本文介绍了解决高并发的核心原则,即将用户访问请求尽量往前推,避免访问CDN、静态服务器、动态服务器、数据库和存储,从而实现高性能、高并发、高可扩展的网站架构。同时提到了Google的成功案例,以及适用于千万级别PV站和亿级PV网站的架构层次。 ... [详细]
  • 本文介绍了Redis中RDB文件和AOF文件的保存和还原机制。RDB文件用于保存和还原Redis服务器所有数据库中的键值对数据,SAVE命令和BGSAVE命令分别用于阻塞服务器和由子进程执行保存操作。同时执行SAVE命令和BGSAVE命令,以及同时执行两个BGSAVE命令都会产生竞争条件。服务器会保存所有用save选项设置的保存条件,当满足任意一个保存条件时,服务器会自动执行BGSAVE命令。此外,还介绍了RDB文件和AOF文件在操作方面的冲突以及同时执行大量磁盘写入操作的不良影响。 ... [详细]
  • t-io 2.0.0发布-法网天眼第一版的回顾和更新说明
    本文回顾了t-io 1.x版本的工程结构和性能数据,并介绍了t-io在码云上的成绩和用户反馈。同时,还提到了@openSeLi同学发布的t-io 30W长连接并发压力测试报告。最后,详细介绍了t-io 2.0.0版本的更新内容,包括更简洁的使用方式和内置的httpsession功能。 ... [详细]
  • 图解redis的持久化存储机制RDB和AOF的原理和优缺点
    本文通过图解的方式介绍了redis的持久化存储机制RDB和AOF的原理和优缺点。RDB是将redis内存中的数据保存为快照文件,恢复速度较快但不支持拉链式快照。AOF是将操作日志保存到磁盘,实时存储数据但恢复速度较慢。文章详细分析了两种机制的优缺点,帮助读者更好地理解redis的持久化存储策略。 ... [详细]
  • 本文介绍了操作系统的定义和功能,包括操作系统的本质、用户界面以及系统调用的分类。同时还介绍了进程和线程的区别,包括进程和线程的定义和作用。 ... [详细]
  • 篇首语:本文由编程笔记#小编为大家整理,主要介绍了软件测试知识点之数据库压力测试方法小结相关的知识,希望对你有一定的参考价值。 ... [详细]
  • 基于PgpoolII的PostgreSQL集群安装与配置教程
    本文介绍了基于PgpoolII的PostgreSQL集群的安装与配置教程。Pgpool-II是一个位于PostgreSQL服务器和PostgreSQL数据库客户端之间的中间件,提供了连接池、复制、负载均衡、缓存、看门狗、限制链接等功能,可以用于搭建高可用的PostgreSQL集群。文章详细介绍了通过yum安装Pgpool-II的步骤,并提供了相关的官方参考地址。 ... [详细]
  • 这是原文链接:sendingformdata许多情况下,我们使用表单发送数据到服务器。服务器处理数据并返回响应给用户。这看起来很简单,但是 ... [详细]
  • 网卡工作原理及网络知识分享
    本文介绍了网卡的工作原理,包括CSMA/CD、ARP欺骗等网络知识。网卡是负责整台计算机的网络通信,没有它,计算机将成为信息孤岛。文章通过一个对话的形式,生动形象地讲述了网卡的工作原理,并介绍了集线器Hub时代的网络构成。对于想学习网络知识的读者来说,本文是一篇不错的参考资料。 ... [详细]
  • 本文介绍了一个React Native新手在尝试将数据发布到服务器时遇到的问题,以及他的React Native代码和服务器端代码。他使用fetch方法将数据发送到服务器,但无法在服务器端读取/获取发布的数据。 ... [详细]
  • 统一知识图谱学习和建议:更好地理解用户偏好
    本文介绍了一种将知识图谱纳入推荐系统的方法,以提高推荐的准确性和可解释性。与现有方法不同的是,本方法考虑了知识图谱的不完整性,并在知识图谱中传输关系信息,以更好地理解用户的偏好。通过大量实验,验证了本方法在推荐任务和知识图谱完成任务上的优势。 ... [详细]
  • 本文介绍了OkHttp3的基本使用和特性,包括支持HTTP/2、连接池、GZIP压缩、缓存等功能。同时还提到了OkHttp3的适用平台和源码阅读计划。文章还介绍了OkHttp3的请求/响应API的设计和使用方式,包括阻塞式的同步请求和带回调的异步请求。 ... [详细]
  • 上图是InnoDB存储引擎的结构。1、缓冲池InnoDB存储引擎是基于磁盘存储的,并将其中的记录按照页的方式进行管理。因此可以看作是基于磁盘的数据库系统。在数据库系统中,由于CPU速度 ... [详细]
  • 基于移动平台的会展导游系统APP设计与实现的技术介绍与需求分析
    本文介绍了基于移动平台的会展导游系统APP的设计与实现过程。首先,对会展经济和移动互联网的概念进行了简要介绍,并阐述了将会展引入移动互联网的意义。接着,对基础技术进行了介绍,包括百度云开发环境、安卓系统和近场通讯技术。然后,进行了用户需求分析和系统需求分析,并提出了系统界面运行流畅和第三方授权等需求。最后,对系统的概要设计进行了详细阐述,包括系统前端设计和交互与原型设计。本文对基于移动平台的会展导游系统APP的设计与实现提供了技术支持和需求分析。 ... [详细]
author-avatar
淑敏惟雄988
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有