项目的可行性研究及需求分析报告.docx

内部管理系统可行性研究及需求分析汇报

一． 项目开发背景
为了提高企业内部管理的效率，因此需要编制一套完整的用于企业内部管理的系统。这样一种系统可以在整个企业范围内使用，做到了企业资源的整合与共享。

二． 项目的可行性研究
1． 技术方面：
整个系统属于一种规模比较大的MIS系统。尽管其在组织关系上存在着很大的复杂性，繁琐性，不确定性，不过就整个系统的技术构成上来看，它还是属于一种数据库应用类的系统。其基本操作还是对存在数据库进行添加、删除、查找、编辑等。因此就单纯的数据库应用来看，暂不存在太大的技术问题。
2． 经济方面：
由于系统对企业的正常运行的影响是相称大的，因此必须要设置单独的服务器来运行这个系统。又考虑到所有计算机硬件软件都是存在出错也许的（详细到这个系统，由于其需要不间断的运行，因此其出错的也许就会变得更大），因此整个系统应当考虑使用双机热备份技术。使用两台服务器同步运行，一种为主一种作备份，这样可以防止服务器故障对整个系统的影响。又考虑到这个系统是为企业内部服务的，并且数据库设置和调试时候都必须要直接使用服务器，因此应当将服务器设置在企业内部。纵观整个系统需要的硬件，我们认为整个项目的投资将也许是比较巨大的。这方面，提请企业再作详细讨论。
3． 法律方面：
整个系统由于是自行开发，自行使用，因此系统自身不存在法律上的版权争议。在服务器软件方面，应当使用正版软件，由于整个系统尽管是开发给内部使用，但它毕竟诸多部分还是要依托Internet的，一旦服务器连接到Internet上，它的操作系统也许会被Microsoft跟踪，假如不是正版软件，将不得不面临民事诉讼的风险。
4． 目前存在的问题：
目前我们觉得最大的问题仍然是数据库访问方式上的问题。和一般的MIS系统不一样，我们面临着更广泛范围内的数据库访问。这个范围已经不也许用局域网处理了，但一旦使用Internet网，数据传播的有效性和安全性就会成为严重的问题。目前将三种也许数据访问的方式列举如下，并逐一作分析：
a． 使用纯单机版的数据库系统
这是最简朴的数据库访问方式。采用这种方式不波及网络传播，因此无论在哪个部门，也不管其上网设施是怎样的，总能采用这种措施的。采用这种系统后，假如要实现数据同步，必须定期将数据库所有上传（注意：这里应当是上传整个数据库，由于采用这种方式操作的系统，它上传的时间间隔一般是比较大的，假如记录哪些记录是更新的，在实际同步时候，将花费诸多时间作整个更新记录的比对，在记录量增大时候，这个检测的时间也会急剧增长，反而增长了处理时间），服务器在收到整个数据库后，在服务器端运行一种特殊的软件，用于数据的同步。然后将处理后的数据库放在一种特定的区域，客户端可以将处理后的数据库收下来，以实现数据库同步。
整个系统采用的传播示意图如下（仅以市场部为例）：

总部服务器
市场部
DB
DB
DB
市场部

总部服务器上应当运行特定软件用于数据同步，此过程也许需要人工干预。
这段传播可以采用任何传播方式，包括FTP，Email

b． 采用纯网络数据库的构造：
采用这个构造从理想的角度来看，是最适合这个系统的。由于它具有最佳的实时性，可以将目前获得的数据立即传播出去，这样其他部门也就立即可以得知目前的业务状况。并且采用这个构造，从数据库应用角度来看，对网络底层的传播状况不需要有太多的理解（这部分由SQLServer提供的网络传播协议保证）。不过就企业目前各市场部上网状况来看，由于诸多市场部采用的仍然是Modem和ISDN，不能24小时在线，因此再不对目前各市场部上网设备改造的状况下，很难使用这种构造。这种构造尚有一种问题是它很大程度上依赖于中心数据库，对中心数据库可靠性和稳定性的规定相称高。
这种构造的示意图如下（以市场部为例）：

总部服务器
DB
市场部

市场部

市场部

市场部

C．采用当地数据库和网络数据库同步使用的构造 这里的构造和示意图a）中的构造看上去有些相似。但其原理是完全不一样的。图a）中，需要上传的是完整的数据库，它依托运行在服务器端的程序对数据进行整顿以到达同步的目的。而这个构造中，实际上并不存在一种文献上传的过程，它是依托数据库访问接口来直接实现数据交互的。数据库访问接口屏蔽了诸多网络的细节。在这个构造中，在服务器上不需要再单独运行管理程序来实现数据同步。
：
这是这个系统最有也许采用的数据库构造。它的特点是平时数据存储在当地数据库，以天为单位，让当地数据库和总部的一种共享数据库进行交互，以实现数据的同步。这种方式的长处是数据由于在当地和网络数据库上共存，因此可靠性是比较高的。并且就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． 流程：

End of processing
DB Search Operating
Input Client ID

Display Event Info.

1． 查看某一事件过程（资料，钱款收取状况）
2． 记录某一事件过程（资料，钱款收取状况）

Mark Rece. Data.

Refresh the disp.
Display Event Info.

End of processing
DB Search Operating
Input Client ID

Some module details:
DB Search Operating
1．

Input Client ID

Disp Error Msg.
Look up it in DB

Found?

Disp. Info.

It’s the entire process of DB Search

include
2．
Display Event Info.

include
Disp event process.
Disp client info.

Finished？
Data info.
Money info
Process describe

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）（9）（11）（16）－（22）
c． 流程：
这部分由于要波及提成，因此计算措施比较复杂。如下是提成的计算措施：

业务员接到一笔业务

资料钱款与否在当月收到？

在当月不计算提成
将此提成记录在当月

将此业绩记录

底薪（也许没有）

底薪算法
＋

业务提成
一般业务员的工资构成
＋

缴纳三金（可空）
－
业务员工资
提成算法

其他奖励（可空）
＋

其他罚款（可空）
－

管理费算法
＋
管理员工资
管理费
＋

管理人员工资构成

最终实际工资
工资项目
计算根据

d．其他阐明：更详细的计算措施可以参照最终的数据流图。

数据加密备份模块：
这个模块属于为了维护数据安全而设置的模块。在SQLServer里面，自身就有数据加密传播功能。这里只对某些敏感的重要的数据进行再次的加密，使其在数据库里面就是加密后来的状态（既虽然不通过网络传播，也无法直接解读这些数据）。当然实际应用时候，可以采用简朴的加密措施，如ASCII移位等，不要太复杂。并且只对重要的数据，例如财务数据和业务数据进行保护。数据备份可以按照按日，按月对数据进行备份，以防止数据库的意外破坏。

数据库管理模块：
数据库管理模块完毕常规的数据库录入查找等功能。它除了数据库常规操作以外要进行错误检测和可恢复错误的处理。将其单独成为几种模块是为了是上层模块对数据库的操作更为简朴和灵活，并提供了一定的可靠性保证。
远程数据同步模块：
这一模块采用何种同步方式是目前需要讨论的问题。设计这一模块的目的是使上层操作可以与数据远程访问完全分离。未来假如改换了数据远程访问的方式，那么只需要修改此模块，而在这一模块之上的部分，可以不作改动。
2． 网管部
网管部程序重要是用来记录和查询申请的域名信箱等的状况。相对于市场部程序来说，网管部程序功能上比较简朴与单一，需要记录的数据较少。需要完毕的功能是从共享数据库中获取消息，按照消息内容进行处理（如进行空间设置，设置邮箱等），将处理成果返回共享数据库。辅助功能如查询等。总的模块示意图如下：
流程控制模块
数据查找模块
数据编辑模块
远程数据库（运行SQLServer的服务器）
数据添加模块
数据交互模块

再对这一流程进行一下解释，网管部的数据都来自于市场部，它是一种被动的执行机构，但它执行的成果又是必须要返回给市场部的，否则是毫无意义的。
总数据库

填上时间，原因
填上时间，操作成功
接受属于本部门信息

是
设置成功？
分派工作
否

按客户规定进行设置

记录好工作流程

比对上面两张图，其构造是完全不一样的，这是相称自然的，由于一种是模块图，而此外一种是业务流程图。每一种流程环节，需要某些模块的参与来完毕的。简朴的说，流程图侧重了事情的描述或者是编程时候的界面实现，而模块图侧重于了技术上的模块划分，其主线目的是代码的重用，它只是一种技术层面的划分。举个例子，这里“接受本部门信息”就需要数据库交互模块的支持，而数据库交互模块将调用数据库查找模块来详细实现这件事情。而在整个流程结束需要上传这条数据的时候，仍然需要数据交互模块，此时交互模块调用数据查找模块来定位数据，用数据编辑模块来将完毕状况添加上去。

3． 制作部
制作部的程序和网管部类似，整个模块构造也可以参照网管部的，在这里就不再反复。两者重要的区别体目前流程控制模块，这是由两个部分的业务所决定的。
制作部的大体流程如下：

总数据库

填上时间，操作成功
接受属于本部门信息

校对（记录这一过程）
分派工作（记录分派）

制作（记录这一过程）
打字（记录这一过程）

对上面的流程图的阐明：
首先它仍然是一种业务上的流程，括号里面指出了这个流程时候，对于整个系统所进行的操作。省略号地方省略了制作时候的详细环节（这部分是需要制作部提供资料的）

对上面的模块图（不是流程图）作一种阐明：
由于制作部和网管部操作都具有被动性和诸多确定性，因此这一部分的管理程序是相对比较简朴的。其数据库操作也是比较简朴的，只要能记录流程、操作人员和完毕的详细工作就可以了。需要阐明的是这里的数据添加模块和数据交互模块在功能上是有反复的，设计这样一种构造是从性能考虑上出发的。数据添加功能侧重对大批量的直接添加，它侧重速度，只提供有限的错误控制。数据交互模块则进行更完整的数据库操作，它侧重应用功能，应当提供更多的可以供上层调用的函数和错误检测。
两个部门最大的差异是在流程控制上。。

四． 数据流图
市场部业务数据流图
业务员在谈成一笔业务、接受到一份资料或接受到一笔款项等可以产生单据或可记录或可对原先记录进行修改的事情后，会自动触发一种事件，接下来就会触发一连串的动作。
Ø 业务员将资料交给市场部的文员，文员将此事件资料整顿并录入数据库后，上传至数据库服务器；
Ø 制作部从数据库服务器上下载制作资料，然后开始制作；
Ø 网管部也从数据库服务器上下载资料，接下来就按照规定申请域名或是设置邮箱；
Ø 无论是市场部、制作部还是网管部都应当在对应的工作完毕后将完毕的成果反馈到
数据库服务器。
详细示意图如下：

事件发生

资料

市场部文员录入与整顿

数据

数据上传至数据库

数据

数据库服务器

网管部处理成果的反馈
制作部处理成果的反馈

域名及邮箱信息
制作资料

网管部下载资料
制作部下载资料

网管部处理（申请域名等）
制作部制作（网页制作与上传）

阐明：从软件工程学的观点来看，上图是一种不规范的数据流图，不过为了理解的以便，就借用了某些不规范的元素。

市场部工资数据流图
市场部工资计算比较复杂，各分企业市场部的工资结算措施也不大同样。
一、 业务员的工资由两部分构成
Ø 第一部分 基本工资（若基本工资不存在则设置为零）
Ø 第二部分 业务提成（根据业务员当月业绩来计算）
Ø 第三部分 三金的缴纳状况（若三金可以不交则设置为零）
二、 管理人员的工资分为三部分
Ø 第一部分 基本工资（若基本工资不存在则设置为零）
Ø 第二部分 业务提成（假如仍兼做业务员的话）
Ø 第三部分 三金的缴纳状况（若三金可以不交则设置为零）
Ø 第四部分 管理费（按当月业绩来计算）。
数据流图如下：页：36

本部门业绩

业绩考核
基本工资

业务员业绩

业绩
读基本工资

计算实际业务数量

获得奖励比例

三金算法
基本工资
实际业务量

奖励比例

提成因子

计算三金
计算管理费
计算业务提成

管理费
业务提成

三金

计算本月实领工资

实发工资
单位：元

阐明：针对上图的阐明
（1） 分企业市场部业务员工资分派情況不尽相似，某些地区市场部的业务员没有基本工资，则基本工资按零计算。
（2） 管理人员的业务提成设置为零。
（3） 对于业务员来说，未考虑到的工资部分或者某些额外奖励可以归入业务提成；对于管理人员来说，未考虑到的工资部分或者某些额外奖励可以归入管理费。
内部管理系统所需资料

一：市场部
1．企业的网站套餐清单及价目表
2．套餐清单中，每一种套餐详细服务项目及价目，企业可选服务项目清单及价目
3．市场部内部的部门设置组织图
4．市场部内部各部分的详细职责
5．发票样张
6．协议样张
7．发行凭证样张
8．赠品清单
9．其他所有表单（如需打印）样张
10．人事档案需要录入的内容
11．工资结算（包括提成的详细计算算法、业绩记录措施）
12．多种票据假如丢失处理措施（如需罚款的，详细罚款数额，或票据注销措施）
13．各市场部、计算机及打印机配置状况（详细操作系统、打印机种类（与否喷墨/针打））
14．各市场部上网设施
15．各市场部业务上独特的地方的清单
16．市场部需打印报表的清单样张

二：制作部
1． 部门内组织构造图
2． 详细工作流程及工序
3． 各记录报表清单及样张

三：网管部
1． 部门内组织构造图
2． 详细工作流程及工序
3． 各记录报表清单及样张

四：补丁程序
既有数据库的字段定义及各字段含义

五：其他资料
既有各部门之间递交表单的样式

内部管理系统硬件需求

为了保证内部管理系统的稳定高速运行，必须要增长硬件并对既有的硬件进行改造，特提出如下硬件需求。（注：这里的硬件指一种完整的硬件系统，其部分的包括了对软件的需求，这些软件是为了正常运行管理系统所必须配置的）

一． 对服务器的规定
1． 服务器的中央处理部件（CPU）提议使用PIII 1G（以上） Xeon处理器芯片。
2． 服务器内存必须使用服务器专用ECC内存
3． 为了保证数据存储的绝对可靠，硬盘应使用磁盘冗余阵列（RAID 01）
4． 为了防止服务器不可预测的故障，或者服务器的定期维护对企业整个业务导致的影响，所有提议使用两台服务器。两台服务器应构成双机热备份。中间使用WatchDog电路。这样的构造可以保证整个系统的长时间不间断工作，虽然在服务器定期维护的时候也可以使用后备另一台服务器工作。
5． 服务器应支持热插拔电源
6． 服务器必须配置UPS（不间断电源）。
7． 服务器应当放在企业内部。否则无法进行程序调试。
8． 服务器应当必须有固定IP地址。
9． 其他性能在经济条件容许的状况下，应当尽量使用高速稳定的配件。

二． 服务器上应当配置的软件
1． 操作系统：Microsoft Windows server 或者 Microsoft Windows Advanced server
2． 数据库：Microsoft SQL Server (简体中文版)
3． 服务器必须使用专业的防火墙和反病毒软件。
4． 除了为了运行必须配置的程序以外，服务器上提议尽量不要安装其他无关程序，以减少程序的混乱或者程序的意外冲突。
5． 各其他分企业的操作系统尽量统一。（Windows 9x系列或者Windows 系列）。这样可以防止管理软件在出来由于操作系统版本不一致导致的过多的开销。
6． 各分企业的机器必须也安装反病毒软件和防火墙。以防止网络上的蠕虫病毒在整个网络范围内的蔓延。
7． 假如要打印波及字段比较多的报表，应当配置针式打印机。

注：提议首先把服务器定下来，否则无法进行数据库定义了。其他内容可以在编制过程中慢慢配上。假如实在不行，可以先用临时的替代一下，在正式使用时候再作更新。

内部管理系统上层数据库设计

数据表定义
1、 安全性验证：
属性：部门编号（2）这里的部门对于市场部或分企业来说就是市场部或分企业编号
密码
主键：部门编号

2、 部门编号—名称数据库
属性：部门（分企业）编