可行性分析报告.docx
《可行性分析报告.docx》由会员分享，可在线阅读，更多相关《可行性分析报告.docx（41页珍藏版）》请在冰豆网上搜索。
可行性分析报告
昆 明 学院
软件工程课程大作业
专业
计算机科学与技术专业2009级
班级
2班
设计系统
汽车维修管理系统
小组成员
组长：
平吉陶（2009110149）
组员：
王玉梅（2009110152）
李晓梅（2009110146）
崔金粉（2009110141）
杨彩（2009110153）
任课教师
刘渝妍
2011年9月至2011年12月
信息技术学院
“汽车维修管理系统”可行性分析报告
“汽车维修管理系统”需求分析报告
“汽车维修管理系统”分析设计报告
“汽车维修管理系统”测试
“汽车维修管理系统”可行性分析报告
1.引言
1.1编写目的
可行性分析报告是为“汽车维修管理系统”开发的可能性、可行性、必要性提供论据，为开发人员进行系统总体规划设计及具体实施开发工程提供必要的参考资料，在系统开发完成后期为系统的测试、验收提供帮助。
其编写过程由昆明学院信息技术学院学生完成。
预期读者是从事“汽车维修管理系统”开发的相关人员。
1.2项目背景
本项目名称为“汽车维修管理系统”。
系统功能主要包括数据登记、查询、编制并显示季度零件订货计划、打印发票、打印修理工工资月报表等。
本项目的任务提出者为昆明学院信息技术学院，开发者为信息技术学院学生。
1.3定义
AMMS：
AutoMaintenancManagementSystem汽车维修管理系统
SQLServer/ACCESS：
所用的数据库管理系统
eclipse：
所用的开发工具
1.4参考文献
（1）陈明.软件工程实用教程.北京：
电子工业出版社，2006年1月
（2）张海藩.《软件工程》.清华大学出版社.2006年1月
（3）潘孝铭.《软件文档编写》.高等教育出版社.2004年8月
（4）罗先文.《软件工程实物》.重庆大学出版社.2005年3月
2项目概述
2.1要求
该系统应该具有对数据即时登记到系统要定义的表中及对其进行修改、能查询登记单修理单等各种有关数据、编制零件订货计划需要找出要订货的零件、发票打印、修理工工资月报表打印等，给维修工和顾客提供辅助决策的功能。
2.1.1功能
汽车维修管理系统功能主要包括：
数据登记、查询、编制并显示季度零件订货计划、打印发票、打印修理工工资月报表等。
2.1.2性能
汽车维修管理系统使用者是维修人员和客户。
对于维修管理人员的管理工作，性能要求不是很严格，但需要方便车辆入库等操作。
对于客户的一般有接车登记、档案建立、车辆建档等功能，对性能要求较高，要求在这些过程中不能出错。
2.1.3系统的输出
（1）季度零件订货计划。
（2）汽车维修发票。
（3）零件出库单。
2.1.4系统的输入
（1）修车登记单。
（2）汽车维修单。
（3）零件入库单。
（4）零件出库单。
2.1.5处理流程和数据流程
图2—1
2.1.6可靠性和安全性需求
由于汽车维修管理系统对修车登记单和零件入库单的准确性要求很高，所以在对这些数据的导入导出时要保证其准确性。
在顾客取车时要对信息核对以及修改修车等记等操作。
对于整个系统，需要完整的权限控制，防止某些人恶意的攻击系统，修改原始记录。
同时对于数据库中的数据需要定时备份，防止系统数据丢失。
2.1.7完成期限
本项目的完成期限为2011年12月5日前。
具体进度见软件项目计划。
2.2项目基本目标
所建议的系统的开发目标应考虑以下几个方面：
（1）系统需要操作方便，方便管理员对整个系统的管理和顾客查询。
（2）系统需要提供综合查询系统，方便车辆的查询。
（3）系统需要良好的扩展性，方便功能扩展和性能扩展。
（4）系统需要较好的安全性和灾难恢复机制。
2.3条件、假定和限制
对本项目开发中给出的条件、假定和所受到的限制如下。
2.3.1所建议系统的运行寿命的最小值
系统运行寿命的最小值应为10年。
2.3.2进行系统方案选择比较的时间
系统方案选择比较的时间为1个月。
2.3.3经费、投资的来源和限制
经费、投资的来源是昆明学院信息技术学院，限制不超过合同上约定的条目。
2.3.4硬件、软件、运行环境和开发环境方面的条件和限制
（1）硬件资源
服务器：
工作站或小型机；
网络设备：
网络交换机，网卡，网线；
图书条码打印和扫描机。
打印机。
（2）软件资源
服务器端软件选择的具体说明：
操作系统：
Windows2000Server或Windows7。
数据库管理系统：
SQLServer。
开发语言：
C++/C#。
客户端软件选择的具体说明：
web浏览器。
2.3.5可利用的信息和资源
可参考传统的手工管理方式。
2.3.6系统投入使用的最晚时间
系统投入使用的最晚时间为2011年12月。
2.4进行可行性分析的方法
本次可行性分析是按照前面给出的步骤进行的，即按照复查项目目标和规模，研究目前正使用的系统，导出新系统的高层逻辑模型，重新定义问题这一循环反复过程进行的。
2.5评价尺度
本系统进行评价时的主要尺度有：
费用的多少，开发时间的长短，以及使用的难易程度等
3对现有系统的分析
3.1处理流程和数据流程
图2—2
3.2工作负荷
现有系统的工作主要有：
（1）车辆维修信息维护。
（2）顾客信息维护。
（3）零件入库出库维护。
3.3费用支出
运行现有系统所需要的费用支出包括：
汽车维修管理人员的工资等。
3.4人员
运行维护现有系统的人员为汽车维修管理人员。
3.5设备
现有系统所需要的设备有：
PC机、打印机、扫描仪等。
3.6局限性
现有系统的局限性表现在以下方面：
手工操作难度较大、易出错、工作量大；对顾客信息和零件出入库信息的查询困难。
4所建议的系统
4.1对所建议的系统的说明
所建议的系统是基于B/S结构的汽车维修管理系统，解决了对顾客的各个流程的控制，并供了一个良好的、易操作、直观的用户操作界面，从而实现自动化和系统化的管理。
4.2处理流程和数据流程
见图2.1。
4.3改进之处
所建议系统与现有系统比较，改进之处包括：
不需要管理人员手工操作查询、可及时更车辆维修和顾客信息，节省了大量的人力、物力资源，提高的管理质量和工作效率。
4.4影响
在建立所建议系统时，预期会带来的影响包括以下几个方面。
4.4.1对设备的影响
由于本系统开发时采用新的技术和手段，所以需要配备符合本报告2.3条件所列出的条件的计算机硬件。
4.4.2对软件的影响
软件环境需符合本报告2.3条件所列出的。
4.4.3对用户单位机构的影响
为了运行所建议系统，需要图书管理员熟悉计算机相关操作。
4.4.4对系统运行过程的影响
用户操作规程按照系统所建议系统的提示进行；系统失效后，数据库恢复到最新的更新备份状态进行保存。
4.4.5对开发的影响
开发过程需要及时与用户沟通、了解其需求，不断改进和完善系统。
4.4.6对地点和设施的影响
无。
4.4.7对经费开支的影响
需要支付开发单位有关费用。
5可行性分析
5.1技术条件可行性分析
本系统是一个基于C/S结构的汽车维修管理系统，采用面向对象技术、数据库技术、分布式技术等先进技术开发的应用程序，现有的开发技术已非常成熟，且被广泛应用于各行各业，利用现有技术完全可以达到功能目标。
考虑开发期限较为充裕，预计可以在规定的时间内完成开发。
5.2经济可行性分析
5.2.1支出
（1）基本建设投资
硬件设备：
服务器。
软件：
Windows2000Server或Linux、数据库管理系统：
SQLServer。
开发工具：
Eclipse。
软件平台：
Tomcat。
（2）其他一次性支出
系统设计和开发费用。
（3）非一次性支出
系统维护费用。
5.2.2收益
管理方式的自动化，减少了人力、物力费用，缩短了操作时间，极大地提高了工作效率和系统性能。
5.2.3投资回报周期
根据投资回收期计算方法，收益的累计数开始超过支出的累计数的时间为1个月。
6社会因素方面的可行性
6.1法律方面的可行性
所建议系统的研制和开发都选用正版软件，将不会侵犯他人、集体和国家的利益，不会违反相关的国家政策和法律。
6.2操作方面的可行性
本系统的研制和开发充分考虑用户工作流程、计算机操作水平等，尽可能提供更人性化、直观的界面，满足用户要求。
系统的操作方式在用户组织内可行。
7可行性的结论
经上述可行性分析，系统的研制和开发可以立即开始进行。
项目开发计划
1.引言
1.1编写目的
本文档对开发过程中人员分配、开发进度、经费预算、所需软、硬件等问题做出安排，以便根据计划开展并检查项目的开发工作。
其编写过程由昆明学院学生完成。
1.2项目背景（略）
1.3定义（略）
1.4参考文献
同可行性分析报告参考文献；
（1）-（4）
（5）《汽车维修管理系统可行性分析报告》。
2项目概述
2.1工作内容
参考《可行性分析报告》中2.1要求的内容。
在本项目开发过程中需要进行可行性分析、制定项目开发计划、软件需求、软件分析设计、软件实现、软件测试以及相应文档的编写工作。
2.2主要参加人员
平吉陶、王玉梅、李晓梅、杨彩、崔金粉均为大三学生，选择该项目作为软件开发设计题目，掌握软件工程的基本原理及思想，通过查阅资料及讨论的形式，能够解决问题。
2.3产品
2.3.1程序
所用的编程语言为C#。
2.3.2文件
向用户提交的文件名称LMS.WA
2.3.3服务
向用户提供的服务为需求分析文档和用户手册，用户可从中得到关于软件使用方面的信息。
2.3.4非移交的产品
所有文件都应上交项目委托单位昆明学院。
2.4验收标准
对于上述这些产品和服务，按照企业产品要求进行验收。
2.5本计划的批准者和批准日期
本计划的批准者为昆明学院，批准日期为2011年10月30日。
3实施计划
3.1工作任务的分解与人员分工
可行性分析：
平吉陶
项目开发计划：
平吉陶
软件需求：
李晓梅、王玉梅
软件分析设计：
杨彩、崔金粉
编码：
李晓梅、平吉陶、王玉梅、杨彩
测试与维护：
崔金粉
3.2联系人
本小组共有5个人，平吉陶作为本项目经理，负责本项目和委托单位的信息沟通。
3.3进度
可行性分析：
11月1日－11月5日标志：
提交可行性分析报告
项目开发计划：
11月6日－11月8日标志：
提交项目开发计划
需求分析：
11月6日－11月10日标志：
完成需求分析报告
软件设计：
11月11日－11月20日标志：
完成软件分析与设计文档
软件实现：
11月21日－11月30日标志：
代码编写全部完成
测试与实施：
12月1日－12月12日标志：
完成软件测试，可以投入使用
项目名称汽车维修管理系统
甘特图2.1项目进度表（假设）
甘特图2.1
3.4预算
人员成本：
500元/人-月，共计：
500*11.6=5800元
项目所需要的工作量（人-月）如下表所示：
其它经费：
办公费用：
700元差旅费：
无
机时费：
无资料费：
1000元
设备费：
（学校实验室提供）专用设备租金：
无
总计费用支出：
7500元
3.5关键问题
最主要的是技术方面的问题，即如何通过分析设计、软件实现完成系统需要的功能。
其它如空间数据与属性数据的关系、数据库设计、数据结构设计等问题，也起着关键性的作用。
4支持条件
4.1计算机系统支持
（1）服务器端软件选择的具体说明：
·操作系统：
Windows2000Server或WindowsNT。
·数据库管理系统：
SQLServer。
·开发工具：
Eclipse。
（2）客户端软件选择的具体说明：
操作系统：
Windows2000Profession。
4.2需由用户承担的工作
用户需提供内容详尽的系统需求。
4.3由外单位提供的条件
某高校提供相应的软件和硬件支持。
5专题计划要点
项目开发过程中需要制定各个专题计划，开发人员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装计划等，并给出计划要点。
“汽车维修管理系统”需求分析报告
1.引言
参见2.3可行性分析报告的引言。
2.需求概述
2.1目标
通过对当前系统的调查和与用户的共同讨论，对将要开发的目标系统提出了如下总体需求：
1）用数据文件代替现用的全部账册。
2）具有对各种数据文件装入和修改数据的功能。
3）能计算修车费用和开发票。
其中修车费按下列各式计算：
零件费=∑零件价格*耗用数量
修理费=小时工资*修理工时*3
总计=零件费+修理费
4）能找出需要订货的零件，编制并打印零件订货计划。
订货条件：
零件库存量<最低库存量
订货数量：
额定订货量
5）按现行格式和内容编制和打印零件耗用月报表和修理工资月报表。
6）有多种查询和统计功能。
2.2用户类和特征
最终的用户是汽车维修管理员和顾客，汽车维修管理员需要对顾客的资料进行录入和修车数据的输入以及工资报表的生成等工作，要求具备计算机知识，如权限管理等。
顾客以及修理工是普通用户，具备一定的计算机操作知识即可。
2.3运行环境
参见2.3可行性分析报告的运行环境。
3.功能需求
功能分析的任务是弄清用户对目标系统数据处理的功能所提出的需求，根据系统目标和数据需求并与用户充分讨论后才行。
（1）数据登记
登记功能用于把各种手填单据中的数据及进登记到系统将要定义的表中，还要求能进行修改，
（2）查询
能查询登记单、修理单、汽车、车主、修理工、零件库存的有关数据。
（3）编制零件订货计划需要找出要订货的零件。
（4）打印发票
（5）打印修理工工资表。
需求补充说明：
数据库设计：
逻辑设计：
设计从分析输入数据着手，输入数据中的某类相差数据可以归纳为一个表，对需要同时调用的若干表，应使它们符合关联的要求。
数据库设计好后，可通过分析输出数据来验证其可用性。
若发现有的输出数据不能从输入数据中导出，须继续向用户征集数据。
（1） 修理单：
XLD（编号，牌号，工号，修理项目，修理小时，送修日期，完工日期）
（2） 汽车：
QC（牌号，型号，生产厂，车主名）
（3） 车主CZ（车主名，姓名，地址，出生日期，进厂日期，小时工资）
（4） 零件用量：
LJYL（编号，零件号，数量）
修理单
汽车
修理工
零件用量
零件库存
车主
3.1确定执行者
执行者是与系统交互的外部实体，它既可以是人员也可以是外部系统或硬件设备。
确定执行者可以通过提出以下问题得到：
–谁使用系统的主要功能？
–谁需要系统的支持以完成日常工作任务？
–谁从系统获取信息？
–谁负责维护和管理系统以保证其正常运行？
–系统需要应付（处理）哪些外部硬件设备？
–系统需要和哪些外部系统交互？
在本系统中，可以确定“汽车维修管理员”和“顾客”为系统的执行者。
“汽车维修管理员”负责使用系统的主要功能，“顾客”从系统中获取所需的信息。
3.2确定用例
用例描述了一个完整的系统事件流程，其重点在于执行者与系统之间的交互而不是内在的系统活动，并对执行者产生有价值的可观测结果。
确定用例可以通过提出以下问题得到：
–参与者需要从系统中获得什么功能？
参与者需要做什么？
–参与者读取、产生、删除、修改或存储系统的某些信息吗？
–系统中发生事件需要通知参与者吗？
参与者需要通知系统某件事情吗？
–系统的输入/输出信息是什么？
这些信息从哪儿来到哪儿去？
–采用什么实现方法满足某些特殊要求？
本例中我们通过一定的调研和分析得到的“汽车维修管理系统”的用例图，如图3.1所示。
3.3编写用例文档
用例图不能提供用例所具有的全部信息，因此需要使用文字描述那些不能放映在图形上的信息。
用例文档是关于执行者与系统如何交互的规格说明，要求清晰明确，没有二义性。
在描述用例时，应该只注重外部能力，不涉及内部细节。
下面给出本例中的用例文档。
查询登记单用例
用例编号：
UC001
用例名：
查询登记单
参与执行者：
汽车维修管理员、顾客
入口条件：
汽车维修管理人员和顾客已经登录到该系统中
事件流：
1.当有顾客在系统中登记了维修信息时
2.需要核对以及检查信息正确时顾客和汽车维修管理员进入查询
3.查看信息后进行修改和删除之后按保存按钮
出口条件：
添加顾客信息时将新的信息保存到数据库中并做相应的更新
异常事件：
在查询时找不到相应的顾客信息询无结果时，则无法进行修改和删除操作。
查询车主用例
用例编号：
UC002
用例名：
查询车主
参与执行者：
汽车维修管理员、顾客
入口条件：
汽车维修管理人员和顾客已经登录到该系统中
事件流：
1.当有顾客在系统中登记了维修信息时
2.需要核对以及检查信息正确时顾客和汽车维修管理员进入查询
3.查看信息后进行修改和删除之后按保存按钮
出口条件：
添加顾客信息时将新的信息保存到数据库中并做相应的更新
异常事件：
在查询时找不到相应的车主信息询无结果时，则无法进行修改和删除操作。
查询汽车用例
用例编号：
UC003
用例名：
查询汽车
参与执行者：
汽车维修管理员、顾客
入口条件：
汽车维修管理人员和顾客已经登录到该系统中
事件流：
1.当有顾客在系统中登记了维修信息时
2.需要对汽车信息核对以及检查信息正确时顾客和汽车维修管理员进入查询
3.查看信息后进行修改和删除之后按保存按钮
出口条件：
添加顾客信息时将新的信息保存到数据库中并做相应的更新
异常事件：
在查询时找不到相应的汽车信息询无结果时，则无法进行修改和删除操作。
口令管理用例
用例编号：
UC004
用例名：
口令管理
参与执行者：
汽车维修管理员、顾客、修理工
入口条件：
用户已经登录到该系统中
事件流：
1.用户点击“修改密码”按钮
2.在口令修改页面输入新的密码
3.点击保存按钮。
出口条件：
数据库中的密码被修改成最新的密码。
异常事件：
修改或登录时密码输入不对则提示重输或者提示错误。
查询修理工用例
用例编号：
UC005
用例名：
查询修理工
参与执行者：
汽车维修管理员、顾客、修理工
入口条件：
用户已经登录到该系统中
事件流：
1.用户点击查询修理工表
2.查看表中数据进行相应修改和删除添加
3.点击保存按钮。
出口条件：
数据库中修理工被修改或添加删除
异常事件：
不允许修改、删除、添加等提示出错
查询零件库存用例
用例编号：
UC006
用例名：
查询零件库存
参与执行者：
汽车维修管理员、修理工
入口条件：
用户已经登录到该系统中
事件流：
1.进入零件库存页面输入要查询的零件编号
2.看到所查零件的个数及现有数量
3.点击退出按钮。
出口条件：
点击退出系统
异常事件：
输入零件编号错误查询不到所找零件。
编制零件订货计划用例
用例编号：
UC007
用例名：
编制零件订货计划
参与执行者：
汽车维修管理员
入口条件：
用户已经登录到该系统中
事件流：
1.管理员进入零件订货页面
2.点击添加按钮添加要定制的零件
3.点击保存按钮
出口条件：
添加信息时将新的信息保存到数据库中并更新数据库
异常事件：
添加时保存不到数据库
打印发票用例
用例编号：
UC008
用例名：
打印发票
参与执行者：
汽车维修管理员
入口条件：
用户已经登录到该系统中
事件流：
1.顾客维修已完成付款时。
2.点击打印发票按钮。
出口条件：
发票已经被打印。
异常事件：
发票无法正常打印。
打印修理工工资表用例
用例编号：
UC009
用例名：
打印修理工工资表
参与执行者：
汽车维修管理员
入口条件：
用户已经登录到该系统中
事件流：
1．月底发修理工工资进入页面
2．点击打印工资表按钮
出口条件：
工资表打印成功
异常事件：
工资表无法正常打印
数据登记用例
用例编号：
UC010
用例名：
数据登记
参与执行者：
汽车维修管理员
入口条件：
用户已经登录到该系统中
事件流：
1．有车辆、修理工、顾客零件需要添加时
2．点击相应添加按钮
3．点击保存
出口条件：
添加成功并把数据保存到数据库中，并更新数据库
异常事件：
无法修改和保存及更新
查询车辆维修情况用例
用例编号：
UC011
用例名：
查询车辆维修情况
参与执行者：
顾客
入口条件：
用户已经登录到该系统中
事件流：
1.顾客进入车辆页面
2.输入车辆识别号
3.点击查询按钮
4.查询完点击退出按钮
出口条件：
查询完毕点击退出系统
异常事件：
车辆识别号出错导致无法查询
顾客查询个人信息用例
用例编号：
UC012
用例名：
顾客查询个人信息
参与执行者：
顾客
入口条件：
用户已经登录到该系统中
事件流：
1.顾客进入个人信息页面
2.点击查询按钮
3.进行修改添加或删除
4.点击保存
出口条件：
添加成功并把数据保存到数据库中，并更新数据库
异常事件：
无法修改和保存及更新
查询工资情况用例
用例编号：
UC013
用例名：
查询工资情况
参与执行者：
修理工
入口条件：
用户已经登录到该系统中
事件流：
1.修理工进入工资页面
2.输入自己的工号点击查询按钮
3.点击退出按钮
出口条件：
修理工点击退出系统按钮
异常事件：
修理工工号输错或不存在
修理工查询个人信息用例
用例编号：
UC014
用例名：
修理工查询个人信息
参与执行者：
修理工
入口条件：
用户已经登录到该系统中
事件流：
1修理工进入个人信息页面
2.点击查询按钮
3.进行修改添加或删除
4.点击保存
出口条件：
修理工点击退出系统按钮
异常事件：
修理工工号输错或不存在
4.非功能需求
4.1性能需求
汽车维修管理系统的使用者是汽车维修管理员和顾客以及修理工。
对于汽车维修管理员的管理工作，性能要求不是很严格，但需要方便数据输入等操作。
对于顾客的信息录入、汽车维修查询等功能，对性能要求较高，一般需要达到并发数200以上。
对于修理工的工资报表查询和零件查询等功能，对性能要求相对较高，一般需要达到并发数100以上
升级会员 