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

内部管理系统可行性研究及需求分析报告 一． 项目开发背景 为了提高公司内部管理的效率，所以需要编制一套完整的用于公司内部管理的系统。这样一个系统可以在整个公司范围内使用，做到了公司资源的整合与共享。 二． 项目的可行性研究 技术方面： 整个系统属于一个规模比较大的MIS 系统。尽管其在组织关系上存在着很大的复杂性，繁琐性，不确定性，但是就整个系统的技术构成上来看，它还是属于一个数据库应用类的系统。其基本操作还是对存在数据库进行添加、删除、查找、编辑等。所以就单纯的数据库应用来看，暂不存在太大的技术问题。 经济方面： 由于系统对公司的正常运行的影响是相当大的，所以必须要设置单独的服务器来运行这个系统。又考虑到所有计算机硬件软件都是存在出错可能的（具体到这个系统，由于其需要不间断的运行，所以其 出错的可能就会变得更大），因此整个系统应该考虑使用双机热备份技术。使用两台服务器同时运行，一个为主一个作备份，这样可以避免服务器故障对整个系统的影响。又考虑到这个系统是为公司内部服务的，而且数据库设置和调试时候都必须要直接使用服务器，所以应该将服务器设置在公司内部。纵观整个系统需要的硬件，我们认为整个项目的投资将可能是比较巨大的。这方面，提请公司再作详细讨论。 法律方面： 整个系统由于是自行开发，自行使用，所以系统本身不存在法律上的版权争议。在服务器软件方面，应该使用正版软件，因为整个系统尽管是开发给内部使用，但它毕竟很多部分还是要依靠Internet 的，一旦服务器连接到Internet 上，它的操作系统可能会被Microsoft 跟踪，如果不是正版软件，将不得不面临民事诉讼的风险。 目前存在的问题： 目前我们觉得最大的问题仍然是数据库访问方式上的问题。和一般的MIS 系统不同，我们面临着更广泛范围内的数据库访问。这个范围已经不可能用局域网解决了，但一旦使用Internet 网，数据传输的有效性和安全性就会成为严重的问题。现在将三种可能数据访问的方式列举如下，并逐一作分析： 使用纯单机版的数据库系统 这是最简单的数据库访问方式。采用这种方式不涉及网络传 输，所以无论在哪个部门，也不管其上网设施是如何的，总能采用这种方法的。采用这种系统后，如果要实现数据同步，必须定期将数据库全部上传（注意：这里应该是上传整个数据库，因为采用这种方式操作的系统，它上传的时间间隔一般是比较大的， 如果记录哪些记录是更新的，在实际同步时候，将花费很多时间作整个更新记录的比对，在记录量增大时候，这个检测的时间也会急剧增加，反而增加了处理时间），服务器在收到整个数据库后，在服务器端运行一个特殊的软件，用于数据的同步。然后将处理后的数据库放在一个特定的区域，客户端可以将处理后的数据库收下来，以实现数据库同步。 整个系统采用的传输示意图如下（仅以市场部为例）： 市场部 市场部 总部服务器上应该运行特定软 件用于数据同步，此过程可能需要人工干预。 DB 总部服务 DB DB 这段传输可以采用任何传 输方式，包括FTP，Email 市场部 采用纯网络数据库的结构： 采用这个结构从理想的角度来看，是最适合这个系统的。因为它具有最好的实时性，可以将当前获得的数据立即传输出去， 这样其他部门也就立即可以得知目前的业务情况。而且采用这个结构，从数据库应用角度来看，对网络底层的传输情况不需要有太多的了解（这部分由SQLServer 提供的网络传输协议保证）。但是就公司目前各市场部上网情况来看，由于很多市场部采用的仍然是 Modem 和ISDN，不能 24 小时在线，因此再不对目前各市场部上网设备改造的情况下，很难使用这种结构。这种结构还有一个问题是它很大程度上依赖于中心数据库，对中心数据库可靠性和稳定性的要求相当高。 这种结构的示意图如下（以市场部为例）： 市场部 市场部 总部服务 市场部 市场部 DB 市场部 C．采用本地数据库和网络数据库同时使用的结构1： 这是这个系统最有可能采用的数据库结构。它的特点是平时数据存储在本地数据库，以天为单位，让本地数据库和总部的一个共享数据库进行交互，以实现数据的同步。这种方式的优点是数据因为在本地和网络数据库上共存，所以可靠性是比较高的。而且就 Modem，ISDN 和宽带共存的情况下使用这种结构也是比较现实的。它的缺点是：在每日用于同步的数据量大的情况下是无法使用的，另外，即使每天用于同步的数据量并不是很大，但是本地数据库或者网络共享数据库的存储量已经很大，这样再搜索用于需要同步的数据的时间也将成倍增加。系统在刚投入使用时候可能速度比较快，但是存储量达到一定程序后，系统运行速度 1 这里的结构和示意图 a）中的结构看上去有些相似。但其原理是完全不同的。图 a）中，需要上传的是完整的数据库， 它依靠运行在服务器端的程序对数据进行整理以达到同步