系统的可行性分析
本系统是针对网上图书销售的一种尝试。目前,在网上有许多的销售系统,从小的化妆品的在线销售到大的机械设备的在线销售都应有尽有。
网上图书销售系统标志着信息的多元化。长期以来,对于图书销售都是以店面为主要的经营方式,而这种以店面为主的经营方法不仅不便于管理,还浪费了大量的人力物力,不能带来好的经济效益。针对图书管理的弊端,根据图书销售的基本流程,实现图书管理的电子化,减轻管理人员的负担。借助计算机,管理人员能够很好的对现有图书进行管理(包括图书的分类、添加、删除等)。同时也为广大群众提供了方便。人们现在可以足不出户就可以买到自己想要的书。这样,既简便又快捷。
下面从技术可行性、经济可行性、操作的可行性几方面进行可行性研究。
- 技术可行性
本系统分为前台系统、后台系统。前台是直接面向顾客,进行查询和销售处理,后台是进行系统管理和控制,为决策提供辅助。在网络的构建上利用客户端/服务器(C/S)体系结构。由于现在的个人用户计算机性能很高,而且Microsoft XP Professional可以建立IIS环境,所以在调试中可以替代服务器。该网站的页面采用ASP脚本编写,用SQL Server2000作为数据库,使用Microsoft的IIS5.0作为系统服务器。用大学四年所学的知识再加上平时对计算机专业知识的积累,通过制作本系统的ASP动态网页,并且在总的系统配置上是能实现网站的正常用作,因此,在技术的实现上是可行的。
- 经济可行性
从目前开发小型网站系统耗资问题上,除了购买服务器的开支较大外,其它的费用支出包括硬件购置费用、软件购置费用、网络搭建费用、开发人员人工费、系统使用人员的培训费和系统运行期间的维护费用,而且这些开发费用对于一般的公司来说是完全可以承受的。
在系统开发成功后扩大了销售的渠道,可大大提高各方面管理的效率和准确性,从而降低成本,更及时有效的辅助管理人员对网络营销进行决策,新系统的实施带来的经济效益将远远超过它的成本费用。因此,从经济效益上看新系统的开发是可行的。
- 操作的可行性
本系统良好的安全性设置,在系统的后台采用密码和用户名验证,极大的保证系统的信息安全。而且,系统操作员可以稍加培训就能很快掌握系统的后台维护方法,不会因员工操作失误而导致系统出错。不仅如此,我们还可以编写出详尽的用户操作说明书,为用户的正确操作给以图文并茂的形式加以说明。在系统前台的购买订单也是采用密码验证手段,保证客户的正常交易。网站的主页采用人性化的设计方法,为客户提供直观动态的页面设计,易于操作。
综上所述,网上图书销售系统是可行的,可以马上进行开发。
为了开发出真正满足用户需求的产品——网上图书销售系统,首先必须要知道客户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件,不论我们把设计和编码工作做得如何出色,不能满足用户需求的程序只会给客户带来失望,给开发带来麻烦。虽然在可行性研究阶段已经粗略了解用户的需求,甚至还提出了一些可行的方案,但是,可行性研究的基本目的使用较小的成本在较短时间内确定是否存在可行的解法,因此,在需求分析阶段要确定系统必须完成哪些工作,也就是对系统提出完整、准确、清晰、具体的要求。
需求分析的基本任务是准确地回答“系统必须做什么?”这个问题。我们通过和客户的沟通基本确定了“网上图书销售系统”的基本功能以及客户在性能、可靠性、可用性、出错处理的基本需求。
- 功能需求,这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。
- 图书管理,主要有修改图书信息、添加图书、删除图书。
- 图书销售管理,主要包括:图书查找、购物车管理、订单提交。
- 用户管理,主要有用户注册、注册检查、修改用户信息。
- 性能需求,指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的要求。
- 用户在客户端点击存在服务器中的主页时,系统能快速响应。
- 在安全性方面,ASP程序要满足客户传输信息的基本安全。
- 可靠性需求,定量的指定系统的可靠性。
订购交易一旦发生必须立即处理,如果由于系统故障延迟处理,不但会造成跑帐,而且会因此不得不用几倍乃至十几倍的人工代替机器而打乱公司的正常工作秩序。所以在考虑系统选型的时候应该把系统的可靠性放在第一位。
- 出错处理的需求。
根据客户的需求的要求,被客户登陆浏览的网页如果出现数据冗余或输入错误,则在浏览器端有相应的错误提示,而且一般的错误输入在系统通过相应的处理后要求客户通过浏览器重新输入而不做报错处理。
- 可用性与可靠性密切需求,它量化了用户可以使用系统的程度。对于一般客户登录该网站的网页后无需填写客户登录的操作直接就可以进行查找操作。
- 可维护性,一个好的系统应向用户提供纠错功能和多种数据恢复的手段。使网络管理员无所作为的网站系统不是一个好的系统。
- 客户说不清楚需求
我们不能够客户对软件开发有清晰的概念,不能够很清楚的把需求表述出来,那是多么令人愉快的事情。更多的时候,客户只有朦胧的感觉,没有给出具体的需求。开发人员不能过分苛求。只能从自身找出解决问题的办法。如果客户本身就懂软件开发,能把需求说得清清楚楚,这将减少很大沟通时间。如果客户全不懂软件,但信任软件开发方,这事也好办。分析人员可以引导客户,先阐述常规的需求,再由客户否定不需要的,最终确定客户真正的需求。
- 需求自身经常变动
首先,更改一个概念:需求自身肯定要变动的。这是符合自然规律的,事物总是随时间空间的推移发生着喜人的变化在分析客户需求时尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求。分析出不稳定因素的潜在威胁。聪明的工程师在进行系统设计时,将软件的核心建筑在稳定的需求上。跟上“时代的脚步”——客户的需求总是合理的,开发“网上图书销售系统”过程中就可以体会到,客户并非随意的改变需求,随着服务专业的发展和实际需求变动,对软件开发就有了新的要求。作为开发人员,只能愉快的接受并解决这些变动。
- 分析人员或客户理解有误
正如前面所讲,术业有专攻,软件系统分析人员和客户(某一专业研究人员)都不可能是熟络两个领域的全才。甚至,客户表达的需求,不同的分析人员有不同的理解。如果分析人员理解错了,会导致开发人员的劳动付之东流,如跑题的作文总是零分。
解决的办法似乎很简单实效,在分析人员写好需求说明书后,要反复验证客户及各方代表。作为开发人员这时要有足够的耐心和智慧去沟通,使模糊的问题清晰化。使双方的意见走到同一轨道上来。开发人员快速构造复杂问题的软件原型,多次论证需求说明书是否正确。
-
- 系统的模块分析
系统模块的划分要从不同的角度进行,我们要把具有相似功能或相互关联功能的部分划分成一个模块,主要是从用户角度和便于管理的角度进行模块的分析。根据客户在需求阶段提出的主要功能,经过分析研究确定了本系统的三大模块,即图书销售模块、用户管理模块、后台管理模块,这三个模块共同构成系统的三大页面,其各功能的主要关系如图2-1所示。
图2-1 系统主要功能关系图
对于一个网上销售系统来说分析系统的业务流程是至关重要的,通常用业务流程图来描述整个系统或局部模块的业务走向。
网上图书销售系统的业务由前台业务和后台业务组成。前台处理客户的查询和订购业务,而后台则支持管理员的操作。
图2-2 前台业务流程图
图2-2步骤说明:
当用户登录网站后,如果用户没有注册,则要进行注册,在注册时要按照要求填写,经过系统校验后如果所填写的数据类型不合格,则返回上一层重新注册,如果注册成功系统自动把客户信息存入客户表。有用户名的用户就可以通过查询来进行网上订购,用户在填写订购单时要根据库存量填写,只有填写正确的订购单才可以存入数据库,即订购单台帐。同时数据统计员把每个月的订购及客户数据上报主管部门。
该系统的后台管理图书信息和管理员信息的修改,并可以查阅客户的订购情况。其业务流程如图2-3所示。
图2-3 后台业务流程图
后台业务流程说明:
管理员管理后台数据的录入、修改、删除等工作。而所有的图书均有入库员和检验员统计后交由数据录入人员(管理员)进行数据的录入工作。送货员则根据客户填写的订购单提取书后进行送货处理。
该系统的实现除了技术、经济的支持外不能忽略公司的组织机构在系统运营中的作用,而且其个机构都有其职能范围。
图2-4 系统的组织机构图
从上图可以看出公司经理分管下属的五个部门,图书回收部门负责回收可利用的保护相对完好的书籍,并将所回收的书籍进行分拣、归类,网络维护部门对每天的网页进行维护和更新。信息录入部门对可利用的图书进行系统的录入。货物配送部门对客户的订购进行配送。财务部门是整个网站运作的支柱,它为整个系统提供了强大的经济支持,而且销售收入的全部资金均得交财务部门统一管理。
根据需求分析阶段客户所提出的基本需求并结合业务流程的分析本系统的主要数据用下表描述。
表2-1 管理员信息表
管理员名 | 管理员密码 |
admin | 0 |
ly | 1234 |
表2-2 库存图书信息表
书编号 | 类编号 | 子类编号 | 出版社编号 | 书名 | 内容介绍 | 原价 | 售价 | 折扣率 | 图片位置 | 可供销售的数目 | 是否发布 |
1 | 1 | 1 | 1 | ASP 基础 | ASP的网站建设 | 25 | 35 | 0 | 20 | 是 |
表2-3 图书分类表
图书类编号 | 类名 |
1 | 计算机 |
2 | 化学 |
表2-4 图书子类表
图书子类编号 | 子类名 | 图书类编号 |
1 | 1 | 程序设计 |
2 | 1 | 教科书 |
表2-5 出版社表
出版社编号 | 出版社名 |
1 | 清华大学 |
2 | 高等教育 |
表2-6 出版社表
客户编号 | 客户名 | 密码 | 真实姓名 | 电话 | | 地址 | 城市 | 省份 | 邮政编码 |
1 | zs | 12346 | 张三 | 2354612 | zs@163.com |
表2-7 图书更改信息表
图书编号 | 操作日期 | 操作数量 |
表2-8 销售图书信息表
订货编号 | 订货日期 | 客户编号 | 图书编号 | 售出价 | 该类图书总数 | 送货地址 | 送货城市 | 送货省份 | 付款要求 | 是否已送货 | 备注 |
1 | 2005-5-2 | 1 | 1 | 35 | 1 | 和平区 | 天津 | 天津 | 送货上门 | 是 | |
- 数据流分析
系统数据流图是在对系统调研阶段绘制业务流程图进行分析的基础上,从系统的科学性、管理的合理性、实际运行的可行性角度出发,将信息处理的功能自顶向下、逐层分解,从逻辑上精确的描述新系统应具有的数据加工功能、数据输入、数据输出、数据来源和去向。
F1 F2
F3
图2-6 系统的顶层数据流程图
F1 F3 F2
F1 F3 F2
D1 订购协议单 D3 送货单 D2 后台信息单
F4 F6 F5
F7
F8
图2-7 系统第一层的数据流图
图2-7中的数据流的说明:
F1:正确的订购信息
F2:正确的修改信息
F3:送货单信息
F4:每日的订购入库信息
F5:每次修改成功的信息
F6:以实施的送货单
数据词典描述的主要成分有:数据流、数据元素、数据存储、数据处理,其中数据元素是组成数据流的基本成分。一般来说,把不便在数据流图上注明而对于系统分析应该获得,对整个系统开发以至将来系统运行与维护是必须的信息尽可能放入数据字典。
-
- 数据流的定义
数据流是与所描述系统信息处理功能有关的各类信息的载体,是个加工环节进行处理和输出的数据集合。本系统有两个重要的数据流。其一订购协议数据,其二是书籍信息。
表2-9 数据字典《数据流》条目示例
数据流 系统名:网上图书销售系统 编号: F4 条目名:订购协议单 别名: | |||||
来源:客户处理 | 去处:数据库 | ||||
数据流结构: 订购单={订货编号+订货日期+客户编号+图书编号+图书价格+送货地址+送货城市} | |||||
简要说明:通过前台访问订购的ASP网页,通过处理后把数据存入数据库 | |||||
修改记录: | 编写 | 李淑芝 | 日期 | 2005.7.15 | |
审核 | 于健 | 日期 | 2005.7.15 |
-
- 数据元素
数据元素是数据流的分量,数据元素描述数据流的组成。
表2-10 数据字典《数据元素》条目示例
数据元素 系统名:网上图书销售系统 编号: I1 条目名:登录用户名 别名: | |||||
所属数据流:D1 | 存储处:D1 | ||||
数据元素属性: 类型:字符型 长度:6 | |||||
简要说明:用户名是用来登记客户身份的 | |||||
修改记录: | 编写 | 李淑芝 | 日期 | 2005.7.15 | |
审核 | 于健 | 日期 | 2005.7.15 |
-
- 数据存储
数据存储是逻辑意义上的数据存储环节,即系统信息处理功能需要的、不考虑存储物理介质和技术手段的数据存储环节。本系统定义了协议单数据存储。这也是本系统中最为关键的数据存储。
表2-11 数据字典《数据存储》条目示例
数据存储 系统名:网上图书销售系统 编号: D1 条目名:订购信息 别名: | ||||||
存储组织:对每次的定购进行时事存储 | 数据量:1份/天 | 主关键字:客户编号 辅关键字: | ||||
记录组成: 项名: | ||||||
简要说明:根据硬件的价格更新当天的硬件报价。 | ||||||
修改记录: | 编写 | 李淑芝 | 日期 | 2005.7.15 | ||
审核 | 于健 | 日期 | 2005.7.15 |
-
- 外部实体定义
外部项在数据流图中表示所描述系统的数据来源和去处的各种实体或工作环节。这些实体或环节向所开发的系统发出或接受信息。系统开发不能改变这些外部项本身的结构和固有的属性。
表2-12 数据字典《外部项》条目示例
外部项 系统名:网上图书销售系统 编号: S2 条目名:管理员 别名: | |||||
输入数据流:后台信息修改 | 输出数据流:数据库图书信息更新 | ||||
主要特征: 只有管理员才能进行后台管理 | |||||
简要说明:基本的图书信息、管理员密码更新都是管理员输入更新的。 | |||||
修改记录: | 编写 | 李淑芝 | 日期 | 2005.7.15 | |
审核 | 于健 | 日期 | 2005.7.15 |