内部管理系统详细设计方案完整版.docx
《内部管理系统详细设计方案完整版.docx》由会员分享，可在线阅读，更多相关《内部管理系统详细设计方案完整版.docx（34页珍藏版）》请在冰豆网上搜索。
内部管理系统详细设计方案完整版
集团标准化办公室：
[VV986T-J682P28-JP266L8-68PNN]
内部管理系统详细设计方案
内部管理系统详细设计方案
【最新资料，WORD文档，可编辑】
设计方案简介
本设计方案是为内部管理程序开发而编写的，它包括了系统可行性研究，系统模块设计，模块的具体流程设计，一些需要进一步讨论或者研究的问题，需要的资料与硬件，数据表的定义等。
但它没有包含关于编码的更多主题。
例如编码的约定，注解的格式等。
尽管这些问题对于实现这个系统都是非常重要的，但因为是设计方案它没有被包括在其中。
整个设计方案的大致目录如下：
一．内部管理系统项目方案（第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．使用纯单机版的数据库系统
这是最简单的数据库访问方式。
采用这种方式不涉及网络传输，所以无论在哪个部门，也不管其上网设施是如何的，总能采用这种方法的。
采用这种系统后，如果要实现数据同步，必须定期将数据库全部上传（注意：
这里应该是上传整个数据库，因为采用这种方式操作的系统，它上传的时间间隔一般是比较大的，如果记录哪些记录是更新的，在实际同步时候，将花费很多时间作整个更新记录的比对，在记录量增大时候，这个检测的时间也会急剧增加，反而增加了处理时间），服务器在收到整个数据库后，在服务器端运行一个特殊的软件，用于数据的同步。
然后将处理后的数据库放在一个特定的区域，客户端可以将处理后的数据库收下来，以实现数据库同步。
整个系统采用的传输示意图如下（仅以市场部为例）：
总部服务器
市场部
DB
DB
DB
市场部
总部服务器上应该运行特定软件用于数据同步，此过程可能需要人工干预。
这段传输可以采用任何传输方式，包括FTP，Email
b．采用纯网络数据库的结构：
采用这个结构从理想的角度来看，是最适合这个系统的。
因为它具有最好的实时性，可以将当前获得的数据立即传输出去，这样其他部门也就立即可以得知目前的业务情况。
而且采用这个结构，从数据库应用角度来看，对网络底层的传输情况不需要有太多的了解（这部分由SQLServer提供的网络传输协议保证）。
但是就公司目前各市场部上网情况来看，由于很多市场部采用的仍然是Modem和ISDN，不能24小时在线，因此再不对目前各市场部上网设备改造的情况下，很难使用这种结构。
这种结构还有一个问题是它很大程度上依赖于中心数据库，对中心数据库可靠性和稳定性的要求相当高。
这种结构的示意图如下（以市场部为例）：
总部服务器
DB
市场部
市场部
市场部
市场部
C．采用本地数据库和网络数据库同时使用的结构：
这是这个系统最有可能采用的数据库结构。
它的特点是平时数据存储在本地数据库，以天为单位，让本地数据库和总部的一个共享数据库进行交互，以实现数据的同步。
这种方式的优点是数据因为在本地和网络数据库上共存，所以可靠性是比较高的。
而且就Modem，ISDN和宽带共存的情况下使用这种结构也是比较现实的。
它的缺点是：
在每日用于同步的数据量大的情况下是无法使用的，另外，即使每天用于同步的数据量并不是很大，但是本地数据库或者网络共享数据库的存储量已经很大，这样再搜索用于需要同步的数据的时间也将成倍增加。
系统在刚投入使用时候可能速度比较快，但是存储量达到一定程序后，系统运行速度将会急剧减慢。
（根据实验，当数据记录条数达到5万条以上时，完整的数据库搜索花费的时间会很长很长），而在这种系统结构下，为了保持两者数据库的完全同步，可能要反复搜索数据库。
此段时间的开销是相当大的。
除此之外，这个结构最大的问题是：
如何保证数据的完整同步。
因为诸如Modem等上网设备，其传输过程极易由于外界干扰或者线路传输速率的突变造成传输中断。
重传这些数据可能会造成数据的重复。
（比如经过检测，这次需要上传10条记录，现在客户端开始上传，上传一半Modem断线了，所以实际只传了五条。
客户端检测到这一错误，开始重传，但实际上尽管断线仍然有五条记录是成功传送的，重传全部必定造成重复，但是要很准确的定位具体是在那条中断是相当困难的。
这和网络传输协议里错误检测是类似的）
采用这个结构的示意图如下：
直接数据库交互
总部服务器
DB
市场部
DB
DB
市场部
介于以上原因，我们认为选用何种数据库结构需要进行进一步研究。
可以作一下实验，比如使用各种现有的上网设备来进行一下数据库连接。
测试在不同的数量情况下，对性能的影响。
特别要对Modem连接SQLServer作更多的实验。
因为其连接速度比较慢，必须要对数据库连接超时时间作调整。
（此值过小或者过大都会对性能造成影响。
过小的值可能会使使用Modem的机器无法连上SQLServer，过大的值在确实发生错误时候，需过很多时间才能检测到此错误）
三．系统的大致模块划分
由于整个系统最后使用的结构还没有最后确定，所以这里的模块划分只是一个大致的划分。
在经过实验，确定使用哪种数据库结构后，需要对此部分进行进一步修正。
1．市场部
从最大的方面市场部管理系统可以划分成业务管理、人事管理、财务管理、数据统计与备份、系统设置等模块。
其中业务管理模块包括事件记录添加、事件记录修改，事件记录删除、事件提醒等功能。
这部分侧重的是对客户服务的，它是以客户为中心开展的。
是整个系统数据的入口处。
在人事管理和财务管理等模块中，有很多数据是要依靠业务管理模块的。
人事管理模块指对分公司内部人员的管理，包括用工、退工、员工平时所领取资料、合同等其他凭证的管理与查询。
这里要注意各种凭证领取时候的记录；在凭证丢失时候的处理。
这些凭证都是由业务产生的，所以其与业务管理模块之间存在很多相互访问的情况。
由于存在这个特性，所以必须要做好数据保护，以防止数据交叉访问时候对原先数据的破坏。
财务管理模块是用于市场部内部工资结算的。
由于市场部工资很大部分是有业务员的业绩决定的，所以其在很大程度上也是依赖于业务管理模块的。
它就是根据业务管理模块的统计结果，再利用一定的算法来计算业务员当月的工资和市场部管理人员当月的工资。
这部分繁琐的地方在工资结算方法和各分公司之间算法的差异上，尽管可以设置一些可选项，但如果差异过分悬殊则可能需要为有些分公司编写单独的处理模块。
数据统计功能依赖于业务管理模块和财务管理模块，它按照一定的时限生成各种业务报表供公司内部留存、上交等。
除了打印出来的报告外，程序应该提供一定的界面供数据查阅（不打印）。
备份是所有MIS系统都应该具备的，尽管数据安全可靠存储大部分应该由服务器来保证，但是程序中仍然应该具备数据备份功能，用于数据定时的导入导处。
或者与其他程序交互时候可以使用。
系统设置模块用于对程序进行初始设置。
这部分应该尽量考虑到可扩展性。
对于能够进行设置的部分在此处应尽量设置设置选项。
当然，调整只能在一定范围内进行，一般是数值上或者选项组合上的。
由于系统设置对于系统的运行是起全局影响的，所以再调整前要进行安全性验证。
整个市场部程序模块示意图如下：
（本图仅供参考）
市场部管理程序
系统设置模块
系统登陆模块
业务管理模块
财务管理模块
人事管理模块
事件跟踪模块
员工工资管理
工资参数设置
资料票据管理
部门参数设置
事件添加模块
事件查找编辑
业务收入统计
人事基本管理
事件参数设置
注意
财务数据存取模块
业务数据存取模块
人事数据存取模块
数据加密与备份模块
注：
这里的资料票据管理模块被放在人事管理模块下面了，主要是处于以下考虑：
资料票据总是由特定的业务员领取的，它需要不断的与人事数据库交互，放在人事里面可以减少交叉访问带来的开销。
远程数据同步模块
远程数据库（运行SQLServer的服务器）
各模块的功能解释与数据表之间的对应关系：
1．系统登陆模块：
a．含义解释：
用于市场部合法身份的验证，使用加密密码验证方式。
b．相关数据表：
上层数据表
（1）
c．流程：
输入用户名，密码
显示错误提示
到公司总数据库进行验证
通过否？
否
是
显示操作界面，进行操作
d．其他说明：
密码信息应进行加密存贮。
加密方式不用过于复杂，可以使用ASCII码移位变换的方法。
2．系统设置模块：
a．含义解释：
系统设置模块是对系统的一些运行参数进行调整。
它可以分为两部分，一是为了适应不同的网络传输而进行的机器系统参数设置，二是对本市场部的一些个性化经营方式进行的设置，它偏向于业务。
比如说套餐价格，限价等。
这些数值都会有默认值，并且允许在运行时候，通过其他部分，比如财务管理，人事管理，业务管理等操作界面里进行分别设置。
但由于其代码的重用性，这里保留了一个入口，可以对这些参数进行全面的调整，这样不用分别进入每一个界面调整了。
这种调整方式通常只在程序第一次运行时候才需要。
b．相关数据表：
市场部数据表
（1）
（2）（3）（16）（17）（19）（20）（21）
c．其他说明：
在具体设计时候，对有逻辑联系的部分应结合在一起，使界面做到直观，简化，并且这些调整数值应该是要立即生效的，所以要采用直接的方式，不然如果需重启程序甚至重启windows才能生效，那么会带来很多麻烦。
3．事件添加模块：
a．含义解释：
事件添加模块是整个系统运行的基础。
整个系统的业务数据都是由这里提供的。
这里录入的事件信息包含两部分，一是业务相关客户信息，二是业务信息本身。
它同时也存在两种可能性，一是新客户，这样就要同时添加客户信息与业务信息，二是老客户新业务，此时只需要对业务信息进行增加就可以了。
但不管是何种方式，这里都提供了一个统计的入口――从查找客户开始，以确定客户信息是否存在。
b．相关数据表：
市场部数据表
（1）
（2）（3）（4）（5）（6）（7）（8）（9）
c．流程：
事件添加应该以客户查询作为整个事件添加的开始。
以查询结果作为添加或者编辑的依据。
整个过程可以用以下流程表示：
接到一客户某项业务
进行客户查询
是
客户资料是否存在
否
显示客户资料
录入客户资料
显示客户以前的事件资料
录入事件资料
添加此次新事件
d．其他说明：
按照这个流程，对于第一次在我们这里开办业务的客户，需要同时录入客户资料以及事件（业务）资料，而对于老客户来说，其客户资料已经存在，所以只要录入事件（业务）资料就可以了，但在录入前应该将原先资料显示一遍，这样比较符合软件设计惯例与用户操作习惯。
4．事件查找编辑：
a．含义解释：
这一模块实现了对现有事件的查找和对输入有错并且已经添加的资料的编辑。
查找分为两种信息的查找，一是客户资料的查找，二是业务资料的查找。
当然这两种查找模式会有交叉，比如，查到某一客户后，希望查看这个客户的所有我们对其开展的业务情况，或者，查到某一业务资料后，需要列出这个业务所对应的客户资料，因此在设计时候，要考虑到这些方面，在代码重用和灵活性上要作好调整。
另外此处的编辑是出于这样一种考虑的，在有些数据输入时候有错，但并没有立即发现，隔了一段时间后，通过查找或者突然记起发现了这个错误，那么这里就要提供一个功能，允许用户修改原先的客户资料或者业务资料。
b．相关数据库：
市场部数据表
（1）
（2）（3）（4）（5）（6）（7）（8）（9）
c．流程：
显示提示，选择查找内容
查找客户资料？
否
是
输入业务编号或按内容查找
输入客户编号或姓名
进行数据库查找
显示提示
显示提示
进行数据库查找
否
否
找到否？
找到否？
是
是
显示业务资料
显示客户资料
否
否
是否进一步显示客户资料？
是否进一步显示业务资料？
是
是
显示客户资料
显示业务资料
流程结束
d．其他说明：
这里的查找以及显示流程应该是很清楚的，但要对编辑功能做一下说明。
整个流程里面似乎没有出现编辑部分，我们的考虑是将编辑功能融合在显示的时候，显示的时候用户就可以进行编辑，显示界面下面有一个修改确认按钮，这样用户按下这个按钮时候，编辑过程就完成了，这样一个操作方式在其他工程里面已经被普遍采用了，经过几个项目的考察与用户那里得到的反馈来看，这一操作方式被认为是最符合修改这一功能操作习惯的，而且也是最直观的。
对于程序设计人员来看，它由于将显示与编辑界面复用了，有效的控制了由于界面过多而带来的混乱。
5．事件参数设置：
a．含义解释：
通过这个模块，各市场部可以设置一些关于业务有关的数据，包括市场部能提供的业务，价格，限价，套餐组合等。
b．相关数据库：
市场部数据库
（1）
（2）（3）
c．其他说明：
这个功能是整个系统设置功能的一部分。
操作人员可以在这里调整业务有关的参数，也可以在一个总的设置里面调整这些数据，具体使用哪种方式，则由操作人员根据自己的习惯决定。
6．事件跟踪模块
a．含义解释：
这个模块主要用来跟踪一笔业务的服务过程。
我们可以用它来检查业务所需资料是否收到，钱款是否收到，票据是否收到，赠品是否给出，合同是否签订，是否制作完成等诸如此类的信息。
相对于完整的事件查找而言，它更侧重于服务的过程，而不是单纯的让操作人员了解这个事件。
事件查找模块它只能进行一个事件的查找或者编辑，它不带有对这个事件发展过程进行记录的过程，而此处的记录功能则显得非常重要了。
b．相关数据表：
市场部数据表
（1）
（2）（3）（4）（5）（6）（7）（8）（9）（9）（10）（11）上层数据表
（2）（4）（6）
c．流程：
Endofprocessing
DBSearchOperating
InputClientID
DisplayEventInfo.
1．查看某一事件过程（资料，钱款收取情况）
2．记录某一事件过程（资料，钱款收取情况）
MarkRece.Data.
Refreshthedisp.
DisplayEventInfo.
Endofprocessing
DBSearchOperating
InputClientID
Somemoduledetails:
DBSearchOperating
1．
InputClientID
DispErrorMsg.
LookupitinDB
Found?
Disp.Info.
It’stheentireprocessofDBSearch
include
2．
DisplayEventInfo.
include
Dispeventprocess.
Dispclientinfo.
Finished？
Datainfo.
Moneyinfo
Processdescribe
d．其他说明：
总的来说，这个模块的设置是可以让操作人员方便的了解到一个事件整个的进展情况（也就是说，它不仅是业务那里的进展，也有制作的进展，业务员可以通过这里知道是否制作完成或者申请成功等消息）。
7．人事基本管理：
a．含义解释：
人事基本管理模块包含了人事管理的一些常规操作，包括用工，调动，退工。
其中用工，调动和一般的人事管理系统很类似，但是退工部分，由于要处理资料票据的上交，所以有相当的复杂性。
b．相关数据表：
市场部数据表（12）（13）（14）（15）（16）（17）（18）（19）（20）（21）
c．流程：
显示提示，接收用户操作选择（用，调，退）
用工？
是否
调部门？
是
否
记录员工离职原因为“调部门”
录入员工资料
资料是否都上交
否
重新录入员工资料与报到日期
是
同意退工
是否牵涉部门撤并？
是
调整部门设置
否
重新记录员工所属部门
打印未上交资料
d．其他说明：
这部分相关数据表里面有几张是财务部分的，在这里引用它是因为如果出现部门的撤并，将牵涉到计算底薪，提成时候部门见的差异（因为有可能有的部门要撤销了，那么财务提成或者底薪计算用到的数据库就要进行同步更新）
8．部门参数设置
a．含义解释：
这个功能是比较简单的。
它设置的是某个分公司的部门名称与编号。
在系统第一次运行时候，会要求用户录入这些信息（也可能使用某些默认值），但以后如果需要调整部门设置，可以在这里进行，也可以在总的系统设置里面进行。
这个依据操作人员的习惯而定。
但这里要强调一个问题：
部门的调整对于这个部门内所有人员来说都是有影响的。
调整一个部门的信息，要对涉及这一调整的所有信息做更新，这点非常非常重要。
不然很容易出现系统的不一致。
比如部门A被撤销了，那么原先属于部门A的所有成员信息就要作同步调整，否则在读取员工信息的时候，他们仍然指向A，这个数据显然是无效的。
同时，也要注意部门调整对计算工资部分数据的调整。
b．相关数据表：
市场部数据表（12）（13）（14）（15）（16）（17）（18）（19）（20）（21）
9．资料票据管理
a．含义解释：
这里在资料票据管理指业务员领取资料，发票，合同时候的登记，以及为为了避免遗失而做日常定期检查提供依据（它可以指出哪个业务员何时领取了何种物品票据，是否用掉，如果用掉是用到哪里去了）
b．相关数据库：
市场部数据表（5）（6）（7）（9）（10）（11）（12）（13）（14）（15）
c．流程描述：
因为这个过程很难用流程图来做完整表述，所以，改用文字表示。
首先，资料以及所有票据的来源。
市场部的资料，票据来源与总公司。
对于实物（比如：
书，盘等）可以给它编号，这样便于跟踪。
对于票据，其本身就带有编号，所以这里不再需要自行给它编号。
然后，根据业务需要，业务员领取了书、盘等。
这些领取的东西都必须要登记下来，并且记录领取人的姓名（实际内部操作的是编号）。
下面的部分，要与业务管理模块互操作了。
在业务管理那部分里面，有一个事件跟踪模块，它会记录业务员使用这些票据、资料的情况。
无论票据还是其他实物资料，一旦业务员领取后，那些资料要么在业务员手里，要么已经给客户了。
通过上面所述的流程，我们可以很容易的知道业务员用掉的资料或者票据。
在定期检查时候，系统可以自动得出业务员用掉的资料票据，这样很容易得出应该在手里的资料票据。
只要把这一个清单和业务员手里的资料、票据相比对，就可以了解是否有遗失情况。
业务员实际领取的资料、票据
市场部领取到的总的资料，票据
业务员手里应该有的资料、票据
－
业务员实际消耗掉的资料、票据
事件跟踪模块
d．其他说明：
这里提供了一种可以跟票据、资料的方法，但这里只是一种方法，它并不能解决所有的问题。
这里很大部分依赖了事件跟踪模块对数据库操作的结果。
但是如何判别业务员是否真的如他申明的那样把凭证交给客户了呢？
程序只能按照他所申明的那样做记录（换句话说，程序总是认为这个申明是真实的）。
所以通过这个系统只能识别非故意的单据实物丢失，而识别故意隐匿单据则是管理学和法学的范畴，并不是计算机科学的范畴了。
另外，这里的票据是指发票、合同、发行凭证、赠品、其他表单等。
对每一种票据的处理方式可以是类似的。
都包含查询与录入修改等。
10．业务收入统计：
a．含义解释：
这里统计的是每一个市场部业务上面的净收入，支出等。
这些数据是通过业务管理模块和财务部分的工资管理模块得到的。
b．相关数据表：
市场部数据表（11）（9）（22），上层数据表（7）
c．其他说明：
这部分需要提供给我们更多的资料，比如现在公司需要统计些什么，统计表的样式是怎样的，如果某些统计方法不是显而易见的，则需要给出算法。
11．工资参数设置：
a．含义解释：
由于每一个市场部，市场部的每一个部门的工资计算方法都不一样，所以需要对一些数据进行设置。
这些设置将影响到工资计算。
和其他设置相比，这里的设置可能进行的更频繁一些。
所以要对它的效率做一个准确的考虑。
和其他所有的设置一样，这里的所有数值都会有一个初始值。
b．相关数据库：
市场部数据表（19）（20）（21）（16）
12．员工工资管理：
a．含义解释：
市场部的工资计算方法比较特殊，所以在这一块里面是有一定麻烦的。
对于一般业务员需要考虑的是有没有底薪，有没有提成，需不需要缴纳三金，与之相关的还有底薪计算方法，提成计算方法等；管理人员除了这些基本工资外，还有管理费，但不同部门管理费又是不一样的，所以在具体设计时候要把这些问题都考虑进去。
b．相关数据表：
市场部数据表（7
升级会员 