内部管理系统详细设计方案.doc

《内部管理系统详细设计方案.doc》由会员分享，可在线阅读，更多相关《内部管理系统详细设计方案.doc（25页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、 内部管理系统详细设计方案设计方案简介本设计方案是为内部管理程序开发而编写的，它包括了系统可行性研究，系统模块设计，模块的具体流程设计，一些需要进一步讨论或者研究的问题，需要的资料与硬件，数据表的定义等。但它没有包含关于编码的更多主题。例如编码的约定，注解的格式等。尽管这些问题对于实现这个系统都是非常重要的，但因为是设计方案它没有被包括在其中。整个设计方案的大致目录如下：一内部管理系统项目方案（第 2 页第 20 页）1 项目开发背景 （第 2 页）2 项目可行性研究 （第 2 页第 6 页）3 系统的大致模块划分 （第 6 页第 18 页） 31 市场部 （第 6 页第 17 页）311 系

2、统登陆模块 （第 8 页）312 系统设置模块 （第 8 页）313 事件添加模块 （第 8 页第 9 页）314 事件查找编辑 （第 9 页第 11 页）315 事件参数设置 （第 11 页）316 事件跟踪模块 （第 11 页第 13 页）317 人事基本管理 （第 13 页）318 部门参数设置 （第 14 页）319 资料票据管理 （第 14 页第 15 页）3110 业务收入统计 （第 15 页）3111 工资参数设置 （第 15 页）3112 员工工资管理 （第 15 页第 16 页）3113 数据加密备份模块 （第 16 页）3114 数据库管理模块 （第 16 页第 17 页）

3、 32 网管部 （第 17 页）33 制作部 （第 17 页第 18 页）4 数据流图 （第 19 页第 20 页）41 市场部业务数据流图 （第 19 页）42 市场部工资数据流图 （第 20 页）二内部管理系统所需资料 （第 21 页）三内部管理系统所需硬件 （第 22 页）四数据库设计 （第 23 页第 25 页）1 上层数据库设计 （第 23 页）2 市场部数据库设计 （第 24 页第 25 页）五项目工作量估算 （第 26 页）2内部管理系统项目方案一项目开发背景为了提高公司内部管理的效率，所以需要编制一套完整的用于公司内部管理的系统。这样一个系统可以在整个公司范围内使用，做到了公司

4、资源的整合与共享。二项目的可行性研究1 技术方面：整个系统属于一个规模比较大的 MIS 系统。尽管其在组织关系上存在着很大的复杂性，繁琐性，不确定性，但是就整个系统的技术构成上来看，它还是属于一个数据库应用类的系统。其基本操作还是对存在数据库进行添加、删除、查找、编辑等。所以就单纯的数据库应用来看，暂不存在太大的技术问题。2 经济方面：由于系统对公司的正常运行的影响是相当大的，所以必须要设置单独的服务器来运行这个系统。又考虑到所有计算机硬件软件都是存在出错可能的（具体到这个系统，由于其需要不间断的运行，所以其出错的可能就会变得更大） ，因此整个系统应该考虑使用双机热备份技术。使用两台服务器同时

5、运行，一个为主一个作备份，这样可以避免服务器故障对整个系统的影响。又考虑到这个系统是为公司内部服务的，而且数据库设置和调试时候都必须要直接使用服务器，所以应该将服务器设置在公司内部。纵观整个系统需要的硬件，我们认为整个项目的投资将可能是比较巨大的。这方面，提请公司再作详细讨论。3 法律方面：整个系统由于是自行开发，自行使用，所以系统本身不存在法律上的版权争议。在服务器软件方面，应该使用正版软件，因为整个系统尽管是开发给内部使用，但它毕竟很多部分还是要依靠 Internet 的，一旦服务器连接到 Internet 上，它的操作系统可能会被 Microsoft 跟踪，如果不是正版软件，将不得不面临

6、民事诉讼的风险。4 目前存在的问题：目前我们觉得最大的问题仍然是数据库访问方式上的问题。和一般的 MIS 系统不同，我们面临着更广泛范围内的数据库访问。这个范围已经不可能用局域网解决了，但一旦使用Internet 网，数据传输的有效性和安全性就会成为严重的问题。现在将三种可能数据访问的方式列举如下，并逐一作分析：a 使用纯单机版的数据库系统这是最简单的数据库访问方式。采用这种方式不涉及网络传输，所以无论在哪个部门，也不管其上网设施是如何的，总能采用这种方法的。采用这种系统后，如果要实现数据同步，必须定期将数据库全部上传（注意：这里应该是上传整个数据库，因为采用这种方式操作的系统，它上传的时间间

7、隔一般是比较大的，如果记录哪些记录是更新的，在实际同步时候，将花费很多时间作整个更新记录的比对，在记录量增大时候，这个检测的时间也会急剧增加，反而增加了处理时间） ，服务器在收到整个数据库后，在服务器端运行一个特殊的软件，用于数据的同步。然后将处理后的数据库放在一个特定的区域，客户端可以将处理后的数据库收下来，以实现数据库同步。整个系统采用的传输示意图如下（仅以市场部为例）：3b 采用纯网络数据库的结构：采用这个结构从理想的角度来看，是最适合这个系统的。因为它具有最好的实时性，可以将当前获得的数据立即传输出去，这样其他部门也就立即可以得知目前的业务情况。而且采用这个结构，从数据库应用角度来看，

8、对网络底层的传输情况不需要有太多的了解（这部分由 SQLServer 提供的网络传输协议保证） 。但是就公司目前各市场部上网情况来看，由于很多市场部采用的仍然是 Modem 和 ISDN，不能 24 小时在线，因此再不对目前各市场部上网设备改造的情况下，很难使用这种结构。这种结构还有一个问题是它很大程度上依赖于中心数据库，对中心数据库可靠性和稳定性的要求相当高。这种结构的示意图如下（以市场部为例）：市场部DB总部服务器DB市场部这段传输可以采用任何传输方式，包括FTP，Email总部服务器上应该运行特定软件用于数据同步，此过程可能需要人工干预。DB市场部市场部市场部市场部总部服务器DB4C采用

9、本地数据库和网络数据库同时使用的结构 1：这是这个系统最有可能采用的数据库结构。它的特点是平时数据存储在本地数据库，以天为单位，让本地数据库和总部的一个共享数据库进行交互，以实现数据的同步。这种方式的优点是数据因为在本地和网络数据库上共存，所以可靠性是比较高的。而且就Modem，ISDN 和宽带共存的情况下使用这种结构也是比较现实的。它的缺点是：在每日用于同步的数据量大的情况下是无法使用的，另外，即使每天用于同步的数据量并不是很大，但是本地数据库或者网络共享数据库的存储量已经很大，这样再搜索用于需要同步的数据的时间也将成倍增加。系统在刚投入使用时候可能速度比较快，但是存储量达到一定程序后，系统

10、运行速度将会急剧减慢。 （根据实验，当数据记录条数达到 5 万条以上时，完整的数据库搜索花费的时间会很长很长） ，而在这种系统结构下，为了保持两者数据库的完全同步，可能要反复搜索数据库。此段时间的开销是相当大的。除此之外，这个结构最大的问题是：如何保证数据的完整同步。因为诸如 Modem 等上网设备，其传输过程极易由于外界干扰或者线路传输速率的突变造成传输中断。重传这些数据可能会造成数据的重复。 （比如经过检测，这次需要上传 10 条记录，现在客户端开始上传，上传一半 Modem 断线了，所以实际只传了五条。客户端检测到这一错误，开始重传，但实际上尽管断线仍然有五条记录是成功传送的，重传全部必

11、定造成重复，但是要很准确的定位具体是在那条中断是相当困难的。这和网络传输协议里错误检测是类似的）采用这个结构的示意图如下：介于以上原因，我们认为选用何种数据库结构需要进行进一步研究。可以作一下实验，比如使用各种现有的上网设备来进行一下数据库连接。测试在不同的数量情况下，对性能的影响。特别要对 Modem 连接 SQLServer 作更多的实验。因为其连接速度比较慢，必须要对数据库连接超时时间作调整。 （此值过小或者过大都会对性能造成影响。过小的值可能会使使用 Modem 的机器无法1 这里的结构和示意图 a）中的结构看上去有些相似。但其原理是完全不同的。图 a）中，需要上传的是完整的数据库，它

12、依靠运行在服务器端的程序对数据进行整理以达到同步的目的。而这个结构中，实际上并不存在一个文件上传的过程，它是依靠数据库访问接口来直接实现数据交互的。数据库访问接口屏蔽了很多网络的细节。在这个结构中，在服务器上不需要再单独运行管理程序来实现数据同步。市场部DBDB市场部总部服务器DB直接数据库交互5连上 SQLServer，过大的值在确实发生错误时候，需过很多时间才能检测到此错误）三系统的大致模块划分由于整个系统最后使用的结构还没有最后确定，所以这里的模块划分只是一个大致的划分。在经过实验，确定使用哪种数据库结构后，需要对此部分进行进一步修正。1 市场部从最大的方面市场部管理系统可以划分成业务管

13、理、人事管理、财务管理、数据统计与备份、系统设置等模块。其中业务管理模块包括事件记录添加、事件记录修改，事件记录删除、事件提醒等功能。这部分侧重的是对客户服务的，它是以客户为中心开展的。是整个系统数据的入口处。在人事管理和财务管理等模块中，有很多数据是要依靠业务管理模块的。人事管理模块指对分公司内部人员的管理，包括用工、退工、员工平时所领取资料、合同等其他凭证的管理与查询。这里要注意各种凭证领取时候的记录；在凭证丢失时候的处理。这些凭证都是由业务产生的，所以其与业务管理模块之间存在很多相互访问的情况。由于存在这个特性，所以必须要做好数据保护，以防止数据交叉访问时候对原先数据的破坏。财务管理模块

14、是用于市场部内部工资结算的。由于市场部工资很大部分是有业务员的业绩决定的，所以其在很大程度上也是依赖于业务管理模块的。它就是根据业务管理模块的统计结果，再利用一定的算法来计算业务员当月的工资和市场部管理人员当月的工资。这部分繁琐的地方在工资结算方法和各分公司之间算法的差异上，尽管可以设置一些可选项，但如果差异过分悬殊则可能需要为有些分公司编写单独的处理模块。数据统计功能依赖于业务管理模块和财务管理模块，它按照一定的时限生成各种业务报表供公司内部留存、上交等。除了打印出来的报告外，程序应该提供一定的界面供数据查阅（不打印） 。备份是所有 MIS 系统都应该具备的，尽管数据安全可靠存储大部分应该由

15、服务器来保证，但是程序中仍然应该具备数据备份功能，用于数据定时的导入导处。或者与其他程序交互时候可以使用。系统设置模块用于对程序进行初始设置。这部分应该尽量考虑到可扩展性。对于能够进行设置的部分在此处应尽量设置设置选项。当然，调整只能在一定范围内进行，一般是数值上或者选项组合上的。由于系统设置对于系统的运行是起全局影响的，所以再调整前要进行安全性验证。6整个市场部程序模块示意图如下：（本图仅供参考）注意 22这里一个粗的双箭头表示这些数据库访问之间将有频繁的交互。市场部管理程序业务管理模块 人事管理模块 财务管理模块系统设置模块系统登陆模块事件添加模块 事件查找编辑 事件参数设置 人事基本管理

16、 资料票据管理 业务收入统计 员工工资管理业务数据存取模块 人事数据存取模块 财务数据存取模块数据加密与备份模块远程数据同步模块远程数据库（运行SQLServer 的服务器）注：这里的资料票据管理模块被放在人事管理模块下面了，主要是处于以下考虑：资料票据总是由特定的业务员领取的，它需要不断的与人事数据库交互，放在人事里面可以减少交叉访问带来的开销。部门参数设置 工资参数设置事件跟踪模块7各模块的功能解释与数据表之间的对应关系：1 系统登陆模块： a含义解释：用于市场部合法身份的验证，使用加密密码验证方式。b相关数据表：上层数据表（1）c流程：d其他说明：密码信息应进行加密存贮。加密方式不用过于

17、复杂，可以使用 ASCII 码移位变换的方法。2 系统设置模块：a含义解释：系统设置模块是对系统的一些运行参数进行调整。它可以分为两部分，一是为了适应不同的网络传输而进行的机器系统参数设置，二是对本市场部的一些个性化经营方式进行的设置，它偏向于业务。比如说套餐价格，限价等。这些数值都会有默认值，并且允许在运行时候，通过其他部分，比如财务管理，人事管理，业务管理等操作界面里进行分别设置。但由于其代码的重用性，这里保留了一个入口，可以对这些参数进行全面的调整，这样不用分别进入每一个界面调整了。这种调整方式通常只在程序第一次运行时候才需要。b相关数据表：市场部数据表（1） （2） （3） （16）

18、（17） （19） （20） （21）c其他说明：在具体设计时候，对有逻辑联系的部分应结合在一起，使界面做到直观，简化，并且这些调整数值应该是要立即生效的，所以要采用直接的方式，不然如果需重启程序甚至重启 windows 才能生效，那么会带来很多麻烦。3事件添加模块：a含义解释：事件添加模块是整个系统运行的基础。整个系统的业务数据都是由这里提供的。这里录入的事件信息包含两部分，一是业务相关客户信息，二是业务信息本身。它同时也存在两种可能性，一是新客户，这样就要同时添加客户信息与业务信息，二是老客户新业务，此时只需要对业务信息进行增加就可以了。但不管是何种方式，这里都提供了一个统计的入口从查找客

19、户开始，以确定客户信息是否存在。b相关数据表：市场部数据表（1） （2） （3） （4） （5） （6） （7） （8） （9）输入用户名，密码到公司总数据库进行验证通过否？显示操作界面，进行操作显示错误提示是否8c流程：事件添加应该以客户查询作为整个事件添加的开始。以查询结果作为添加或者编辑的依据。整个过程可以用以下流程表示：d其他说明：按照这个流程，对于第一次在我们这里开办业务的客户，需要同时录入客户资料以及事件（业务）资料，而对于老客户来说，其客户资料已经存在，所以只要录入事件（业务）资料就可以了，但在录入前应该将原先资料显示一遍，这样比较符合软件设计惯例与用户操作习惯。4事件查找编辑：

20、a 含义解释：这一模块实现了对现有事件的查找和对输入有错并且已经添加的资料的编辑。查找分为两种信息的查找，一是客户资料的查找，二是业务资料的查找。当然这两种查找模式会有交叉，比如，查到某一客户后，希望查看这个客户的所有我们对其开展的业务情况，或者，查到某一业务资料后，需要列出这个业务所对应的客户资料，因此在设计时候，接到一客户某项业务进行客户查询客户资料是否存在录入客户资料是否显示客户资料显示客户以前的事件资料录入事件资料 添加此次新事件9要考虑到这些方面，在代码重用和灵活性上要作好调整。另外此处的编辑是出于这样一种考虑的，在有些数据输入时候有错，但并没有立即发现，隔了一段时间后，通过查找或者

21、突然记起发现了这个错误，那么这里就要提供一个功能，允许用户修改原先的客户资料或者业务资料。b 相关数据库：市场部数据表（1） （2） （3） （4） （5） （6） （7） （8） （9）c 流程： 显示提示，选择查找内容查找客户资料？输入客户编号或姓名进行数据库查找找到否？显示提示否是显示客户资料是否进一步显示业务资料？显示业务资料是输入业务编号或按内容查找否进行数据库查找找到否？显示业务资料是否进一步显示客户资料？显示客户资料显示提示是 是否否 否是10d 其他说明：这里的查找以及显示流程应该是很清楚的，但要对编辑功能做一下说明。整个流程里面似乎没有出现编辑部分，我们的考虑是将编辑功能融合

22、在显示的时候，显示的时候用户就可以进行编辑，显示界面下面有一个修改确认按钮，这样用户按下这个按钮时候，编辑过程就完成了，这样一个操作方式在其他工程里面已经被普遍采用了，经过几个项目的考察与用户那里得到的反馈来看，这一操作方式被认为是最符合修改这一功能操作习惯的，而且也是最直观的。对于程序设计人员来看，它由于将显示与编辑界面复用了，有效的控制了由于界面过多而带来的混乱。5事件参数设置：a 含义解释：通过这个模块，各市场部可以设置一些关于业务有关的数据，包括市场部能提供的业务，价格，限价，套餐组合等。b 相关数据库：市场部数据库（1） （2） （3）c 其他说明：这个功能是整个系统设置功能的一部分

23、。操作人员可以在这里调整业务有关的参数，也可以在一个总的设置里面调整这些数据，具体使用哪种方式，则由操作人员根据自己的习惯决定。6事件跟踪模块a 含义解释：这个模块主要用来跟踪一笔业务的服务过程。我们可以用它来检查业务所需资料是否收到，钱款是否收到，票据是否收到，赠品是否给出，合同是否签订，是否制作完成等诸如此类的信息。相对于完整的事件查找而言，它更侧重于服务的过程，而不是单纯的让操作人员了解这个事件。事件查找模块它只能进行一个事件的查找或者编辑，它不带有对这个事件发展过程进行记录的过程，而此处的记录功能则显得非常重要了。b 相关数据表：市场部数据表（1） （2） （3） （4） （5） （6） （7） （8） （9） （9） （10） （11）上层数据表（2） （4） （6）c 流程：流程结束1 查看某一事件过程（资料，钱款收取情况）2 记录某一事件过程（资料，钱款收取情况）Input Client ID DB Search OperatingDisplay Event Info.Input Client ID DB Search OperatingDisplay Event Info.Mark Rece. Data.Refresh the disp.End of processingEnd of processing