企业内部管理系统详细设计方案.docx
- 文档编号:2162140
- 上传时间:2022-10-27
- 格式:DOCX
- 页数:33
- 大小:470.97KB
企业内部管理系统详细设计方案.docx
《企业内部管理系统详细设计方案.docx》由会员分享,可在线阅读,更多相关《企业内部管理系统详细设计方案.docx(33页珍藏版)》请在冰豆网上搜索。
企业内部管理系统详细设计方案
内部治理系统详细设计方案
二○○二年七月二十七日
设计方案简介
本设计方案是为内部治理步伐开发而编写的,它包罗了系统可行性研究,系统模块设计,模块的具体流程设计,一些需要进一步讨论大概研究的问题,需要的资料与硬件,数据表的界说等。
但它没有包罗关于编码的更多主题。
例如编码的约定,注解的格式等。
尽管这些问题对付实现这个系统都是非常重要的,但因为是设计方案它没有被包罗在其中。
整个设计方案的大抵目录如下:
一.内部治理系统项目方案(第2页-第20页)
1.项目开发配景(第2页)
2.项目可行性研究(第2页-第6页)
3.系统的大抵模块分别(第6页-第18页)
3.1市场部(第6页-第17页)
3.1.1系统登岸模块(第8页)
3.1.2系统设置模块(第8页)
3.1.3事件添加模块(第8页-第9页)
3.1.4事件查找编辑(第9页-第11页)
3.1.5事件参数设置(第11页)
3.1.6事件跟踪模块(第11页-第13页)
3.1.7人事根本治理(第13页)
3.1.8部分参数设置(第14页)
3.1.9资料票据治理(第14页-第15页)
3.1.10业务收入统计(第15页)
3.1.11人为参数设置(第15页)
3.1.12员工人为治理(第15页-第16页)
3.1.13数据加密备份模块(第16页)
3.1.14数据库治理模块(第16页-第17页)
3.2网管部(第17页)
3.3制作部(第17页-第18页)
4.数据流图(第19页-第20页)
4.1市场部业务数据流图(第19页)
4.2市场部人为数据流图(第20页)
二.内部治理系统所需资料(第21页)
三.内部治理系统所需硬件(第22页)
四.数据库设计(第23页-第25页)
1.上层数据库设计(第23页)
2.市场部数据库设计(第24页-第25页)
五.项目事情量估算(第26页)
内部治理系统项目方案
一.项目开发配景
为了提高公司内部治理的效率,所以需要体例一套完整的用于公司内部治理的系统。
这样一个系统可以在整个公司范畴内使用,做到了公司资源的整合与共享。
二.项目的可行性研究
1.技能方面:
整个系统属于一个范围比力大的MIS系统。
尽管其在组织干系上存在着很大的庞大性,繁琐性,不确定性,但是就整个系统的技能组成上来看,它照旧属于一个数据库应用类的系统。
其根本操纵照旧对存在数据库进行添加、删除、查找、编辑等。
所以就单纯的数据库应用来看,暂不存在太大的技能问题。
2.经济方面:
由于系统对公司的正常运行的影响是相当大的,所以必须要设置单独的办事器来运行这个系统。
又考虑到所有盘算机硬件软件都是存在堕落可能的(具体到这个系统,由于其需要不中断的运行,所以其堕落的可能就会变得更大),因此整个系统应该考虑使用双机热备份技能。
使用两台办事器同时运行,一个为主一个作备份,这样可以制止办事器妨碍对整个系统的影响。
又考虑到这个系统是为公司内部办事的,并且数据库设置和调试时候都必须要直接使用办事器,所以应该将办事器设置在公司内部。
纵观整个系统需要的硬件,我们认为整个项目的投资将可能是比力巨大的。
这方面,提请公司再作详细讨论。
3.执法方面:
整个系统由于是自行开发,自行使用,所以系统自己不存在执法上的版权争议。
在办事器软件方面,应该使用正版软件,因为整个系统尽管是开发给内部使用,但它究竟许多部分照旧要依靠Internet的,一旦办事器连接到Internet上,它的操纵系统可能会被Microsoft跟踪,如果不是正版软件,将不得不面临民事诉讼的风险。
4.目前存在的问题:
目前我们觉得最大的问题仍然是数据库访问方法上的问题。
和一般的MIS系统差别,我们面临着更遍及范畴内的数据库访问。
这个范畴已经不可能用局域网解决了,但一旦使用Internet网,数据传输的有效性和宁静性就会成为严重的问题。
现在将三种可能数据访问的方法列举如下,并逐一作阐发:
a.使用纯单机版的数据库系统
这是最简朴的数据库访问方法。
接纳这种方法不涉及网络传输,所以无论在哪个部分,也不管其上网设施是如何的,总能接纳这种要领的。
接纳这种系统后,如果要实现数据同步,必须定期将数据库全部上传(注意:
这里应该是上传整个数据库,因为接纳这种方法操纵的系统,它上传的时间隔断一般是比力大的,如果记载哪些记载是更新的,在实际同步时候,将耗费许多时间作整个更新记载的比对,在记载量增大时候,这个检测的时间也会急剧增加,反而增加了处置惩罚时间),办事器在收到整个数据库后,在办事器端运行一个特殊的软件,用于数据的同步。
然后将处置惩罚后的数据库放在一个特定的区域,客户端可以将处置惩罚后的数据库收下来,以实现数据库同步。
整个系统接纳的传输示意图如下(仅以市场部为例):
b.接纳纯网络数据库的结构:
接纳这个结构从理想的角度来看,是最适合这个系统的。
因为它具有最好的实时性,可以将当前得到的数据立即传输出去,这样其他部分也就立即可以得知目前的业务情况。
并且接纳这个结构,从数据库应用角度来看,对网络底层的传输情况不需要有太多的了解(这部分由SQLServer提供的网络传输协议包管)。
但是就公司目前各市场部上网情况来看,由于许多市场部接纳的仍然是Modem和ISDN,不能24小时在线,因此再不对目前各市场部上网设备改革的情况下,很难使用这种结构。
这种结构另有一个问题是它很大水平上依赖于中心数据库,对中心数据库可靠性和稳定性的要求相当高。
这种结构的示意图如下(以市场部为例):
C.接纳当地数据库和网络数据库同时使用的结构:
这是这个系统最有可能接纳的数据库结构。
它的特点是平时数据存储在当地数据库,以天为单元,让当地数据库和总部的一个共享数据库进行交互,以实现数据的同步。
这种方法的优点是数据因为在当地和网络数据库上共存,所以可靠性是比力高的。
并且就Modem,ISDN和宽带共存的情况下使用这种结构也是比力现实的。
它的缺点是:
在每日用于同步的数据量大的情况下是无法使用的,另外,纵然每天用于同步的数据量并不是很大,但是当地数据库大概网络共享数据库的存储量已经很大,这样再搜索用于需要同步的数据的时间也将成倍增加。
系统在刚投入使用时候可能速度比力快,但是存储量到达一定步伐后,系统运行速度将会急剧减慢。
(凭据实验,当数据记载条数到达5万条以上时,完整的数据库搜索耗费的时间会很长很长),而在这种系统结构下,为了保持两者数据库的完全同步,可能要重复搜索数据库。
此段时间的开销是相当大的。
除此之外,这个结构最大的问题是:
如何包管数据的完整同步。
因为诸如Modem等上网设备,其传输历程极易由于外界滋扰大概线路传输速率的突变造成传输中断。
重传这些数据可能会造成数据的重复。
(好比经过检测,这次需要上传10条记载,现在客户端开始上传,上传一半Modem断线了,所以实际只传了五条。
客户端检测到这一错误,开始重传,但实际上尽管断线仍然有五条记载是乐成传送的,重传全部肯定造成重复,但是要很准确的定位具体是在那条中断是相当困难的。
这和网络传输协议里错误检测是类似的)
接纳这个结构的示意图如下:
介于以上原因,我们认为选用何种数据库结构需要进行进一步研究。
可以作一下实验,好比使用种种现有的上网设备来进行一下数据库连接。
测试在差别的数量情况下,对性能的影响。
特别要对Modem连接SQLServer作更多的实验。
因为其连接速度比力慢,必须要对数据库连接超时时间作调解。
(此值过小大概过多数会对性能造成影响。
过小的值可能会使使用Modem的呆板无法连上SQLServer,过大的值在确实产生错误时候,需过许多时间才气检测到此错误)
三.系统的大抵模块分别
由于整个系统最后使用的结构还没有最后确定,所以这里的模块分别只是一个大抵的分别。
在经过实验,确定使用哪种数据库结构后,需要对此部分进行进一步修正。
1.市场部
从最大的方面市场部治理系统可以分别成业务治理、人事治理、财政治理、数据统计与备份、系统设置等模块。
其中业务治理模块包罗事件记载添加、事件记载修改,事件记载删除、事件提醒等功效。
这部分偏重的是对客户办事的,它是以客户为中心开展的。
是整个系统数据的入口处。
在人事治理和财政治理等模块中,有许多数据是要依靠业务治理模块的。
人事治理模块指对分公司内部人员的治理,包罗用工、退工、员工平时所领取资料、条约等其他凭证的治理与查询。
这里要注意种种凭证领取时候的记载;在凭证丢失时候的处置惩罚。
这些凭证都是由业务产生的,所以其与业务治理模块之间存在许多相互访问的情况。
由于存在这个特性,所以必须要做好数据掩护,以防备数据交织访问时候对原先数据的破坏。
财政治理模块是用于市场部内部人为结算的。
由于市场部人为很大部分是有业务员的业绩决定的,所以其在很大水平上也是依赖于业务治理模块的。
它就是凭据业务治理模块的统计结果,再利用一定的算法来盘算业务员当月的人为和市场部治理人员当月的人为。
这部分繁琐的地方在人为结算要领和各分公司之间算法的差别上,尽管可以设置一些可选项,但如果差别太过悬殊则可能需要为有些分公司编写单独的处置惩罚模块。
数据统计功效依赖于业务治理模块和财政治理模块,它凭据一定的时限生成种种业务报表供公司内部留存、上交等。
除了打印出来的陈诉外,步伐应该提供一定的界面供数据查阅(不打印)。
备份是所有MIS系统都应该具备的,尽管数据宁静可靠存储大部分应该由办事器来包管,但是步伐中仍然应该具备数据备份功效,用于数据定时的导入导处。
大概与其他步伐交互时候可以使用。
系统设置模块用于对步伐进行初始设置。
这部分应该尽量考虑到可扩展性。
对付能够进行设置的部分在此处应尽量设置设置选项。
固然,调解只能在一定范畴内进行,一般是数值上大概选项组合上的。
由于系统设置对付系统的运行是起全局影响的,所以再调解前要进行宁静性验证。
整个市场部步伐模块示意图如下:
(本图仅供参考)
注意
各模块的功效解释与数据表之间的对应干系:
1.系统登岸模块:
a.寄义解释:
用于市场部正当身份的验证,使用加密密码验证方法。
b.相关数据表:
上层数据表
(1)
c.流程:
d.其他说明:
密码信息应进行加密存贮。
加密方法不消过于庞大,可以使用ASCII码移位变更的要领。
2.系统设置模块:
a.寄义解释:
系统设置模块是对系统的一些运行参数进行调解。
它可以分为两部分,一是为了适应差别的网络传输而进行的呆板系统参数设置,二是对本市场部的一些本性化经营方法进行的设置,它偏向于业务。
好比说套餐代价,限价等。
这些数值都市有默认值,并且允许在运行时候,通过其他部分,好比财政治理,人事治理,业务治理等操纵界面里进行分别设置。
但由于其代码的重用性,这里保存了一个入口,可以对这些参数进行全面的调解,这样不消分别进入每一个界面调解了。
这种调解方法通常只在步伐第一次运行时候才需要。
b.相关数据表:
市场部数据表
(1)
(2)(3)(16)(17)(19)(20)(21)
c.其他说明:
在具体设计时候,对有逻辑联系的部分应结合在一起,使界面做到直观,简化,并且这些调解数值应该是要立即生效的,所以要接纳直接的方法,不然如果需重启步伐甚至重启windows才气生效,那么会带来许多麻烦。
3.事件添加模块:
a.寄义解释:
事件添加模块是整个系统运行的底子。
整个系统的业务数据都是由这里提供的。
这里录入的事件信息包罗两部分,一是业务相关客户信息,二是业务信息自己。
它同时也存在两种可能性,一是新客户,这样就要同时添加客户信息与业务信息,二是老客户新业务,此时只需要对业务信息进行增加就可以了。
但不管是何种方法,这里都提供了一个统计的入口――从查找客户开始,以确
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 企业内部 管理 系统 详细 设计方案