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

内部管理系统具体设计方案

二○○二年七月二十七日

设计方案介绍
本设计方案是为内部管理程序开发而编写，它包含了系统可行性研究，系统模块设计，模块具体步骤设计，部分需要深入讨论或研究问题，需要资料和硬件，数据表定义等。但它没有包含相关编码更多专题。比如编码约定，注解格式等。尽管这些问题对于实现这个系统全部是很关键，但因为是设计方案它没有被包含在其中。

整个设计方案大致目录以下：
一． 内部管理系统项目方案（第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，不能二十四小时在线，所以再不对现在各市场部上网设备改造情况下，极难使用这种结构。这种结构还有一个问题是它很大程度上依靠于中心数据库，对中心数据库可靠性和稳定性要求相当高。
这种结构示意图以下（以市场部为例）：

总部服务器
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． 制作部
制作部程序和网管部类似，整个模块结构也能够参考网管部，在这里就不再反复。二者关键区分表现在步骤控制模块，这是由两个部分业务所决定。
制作部大致步骤以下：

总数据库

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

校对（统计这一过程）
分配工作（统计分配）

制作（统计这一过程）
打字（统计这一过程）

对上面步骤图说明：
首先它仍然是一个业务上步骤，括号里面指出了这个步骤时候，对于整个系统所进行操作。省略号地方省略了制作时候具体步骤（这部分是需要制作部提供资料）

对上面模块图（不是步骤图）作一个说明：
因为制作部和网管部操作全部含有被动性和很多确定性，所以这一部分管理程序是相对比较简单。其数据库操作也是比较简单，只要能统计步骤、操作人员和完成具体工作就能够了。需要说明是这里数据添加模块和数据交互模块在功效上是有反复，设计这么一个结构是从性能考虑上出发。数据添加功效侧重对大批量直接添加，它侧重速度，只提供有限错误控制。数据交互模块则进行更完整数据库操作，它侧重应用功效，应该提供更多能够供上层调用函数和错误检测。
两个部门最大差异是在步骤控制上。。

四． 数据流图
市场部业务数据流图
员工在谈成一笔业务、接收到一份资料或接收到一笔款项等能够产生单据或可统计或可对原先统计进行修改事情后，会自动触发一个事件，接下来就会触发一连串动作。
Ø 员工将资料交给市场部文员，文员将此事件资料整理并录入数据库后，上传至数据库服务器；
Ø 制作部从数据库服务器上下载制作资料，然后开始制作；
Ø 网管部也从数据库服务器上下载资料，接下来就根据要求申请域名或是设置邮箱；
Ø 不管是市场部、制作部还是网管部全部应该在对应工作完成后将完成结果反馈到
数据库服务器。
具体示意图以下：

事件发生

资料

市场部文员录入和整理

数据

数据上传至数据库

数据

数据库服务器

网管部处理结果反馈
制作部处理结果反馈

域名及邮箱信息
制作资料

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

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

说明：从软件工程学见解来看，上图是一个不规范数据流图，不过为了了解方便，就借用了部分不规范元素。

市场部工资数据流图
市场部工资计算比较复杂，各分企业市场部工资结算方法也不大一样。
一、 员工工资由两部分组成
Ø 第一部分 基础工资（若基础工资不存在则设置为零）
Ø 第二部分 业务分成（依据员工当月业绩来计算）
Ø 第三部分 三金缴纳情况（若三金能够不交则设置为零）
二、 管理人员工资分为三部分
Ø 第一部分 基础工资（若基础工资不存在则设置为零）
Ø 第二部分 业务分成（假如仍兼做员工话）
Ø 第三部分 三金缴纳情况（若三金能够不交则设置为零）
Ø 第四部分 管理费（按当月业绩来计算）。
数据流图以下：页：45

本部门业绩

业绩考评
基础工资

员工业绩

业绩
读基础工资

计算实际业务数量

取得奖励百分比

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

奖励百分比

分成因子

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

管理费
业务分成

三金

计算本月实领工资

实发工资
单位：元

说明：针对上图说明
（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 Ad