软件工程文档合集.docx
- 文档编号:11115918
- 上传时间:2023-02-25
- 格式:DOCX
- 页数:87
- 大小:835.08KB
软件工程文档合集.docx
《软件工程文档合集.docx》由会员分享,可在线阅读,更多相关《软件工程文档合集.docx(87页珍藏版)》请在冰豆网上搜索。
软件工程文档合集
总分:
_____
班次:
3组号:
14作业序号:
5
《软件工程》阶段性综合大作业级差报告
班组序号:
3班14组5次
作业名称:
系统设计与实现——完整工程文档
作业序号:
5
学院:
计算机与软件学院
专业:
计算机科学与技术
指导教师:
钱嘉伟组长姓名:
汪洋
作业时间:
FROM:
2014-12-22TO:
2015-1-5
作业提交时间:
2015年1月5日
拒交记录及处理:
钱记
实验小组明细:
学号
姓名
完成部分
个人等级及百分比
实际分数
校验分数
2012150254
汪洋
UML
95%
2009150148
马思原
可行性研究报告
该生拒交
2009150261
李子豪
软件规格需求说明书
该生拒交
2010150303
沈俊杰
系统原型设计之概要与详情
该生拒交
班次:
3组号:
14作业序号:
5
批阅小组明细:
学号
姓名
分数详情列式
组长算出的平均分数:
组长本人的责任分数:
目录1
可行性研究报告1
1.引言1
1.1.编写目的1
1.2.项目背景1
1.3.术语说明2
1.4.参考资料2
2.可行性研究的前提2
2.1.要求2
2.2.开发目标6
2.3.具备条件7
2.4.进行可研究性研究的方法7
2.5.评价尺度8
3.对现有系统的分析8
3.1.处理流程和数据流程8
3.2.工作负荷8
3.3.费用开支9
3.4.人员9
3.5.局限性9
4.所建议的系统的技术可行性分析9
4.1.对所建议系统的简要描述9
4.2.与现有系统比较的优越性9
4.3.采用建议系统可能带来的影响10
4.4.局限性10
4.5.技术条件方面的可行性11
5.所建议系统的经济可行性分析11
5.1.支出11
5.2.效益12
5.3.收益/投资比12
5.4.投资回收周期12
5.5.敏感性分析12
6.社会因素方面的可行性13
6.1.法律方面的可行性13
6.2.使用方面的可行性13
7.结论13
软件规格需求说明书14
1.引言14
1.1.编写目的14
1.2.项目背景14
1.3.术语说明14
1.4.参考资料14
2.项目概述15
2.1.待开发软件的一般概述15
2.2.待开发软件的功能15
2.3.用户特征17
2.4.运行环境19
2.5.条件与限制19
3.功能需求20
3.1.功能划分及描述20
4.外部接口需求23
4.1.用户界面23
4.2.硬件接口24
4.3.软件接口24
4.4.通信接口24
4.5.故障处理24
5.性能需求24
5.1.数据精确度24
5.2.时间特性24
5.3.适应性24
6.软件属性需求25
6.1.正确性25
6.2.可靠性25
6.3.效率25
6.4.完整性25
6.5.易使用性25
6.6.可维护性25
6.7.可测试性26
6.8.复用性26
6.9.安全保密性26
6.10.可理解性26
6.11.可移植性26
6.12.互联性27
7.其他需求27
8.数据描述27
8.1.静态数据27
8.2.动态数据28
8.3.数据库概述28
8.4.数据字典28
8.5.数据采集30
9.结论30
系统原型设计之概要与详情31
1.引言31
1.1.编写目的31
1.2.项目背景31
1.3.术语说明31
1.4.参考资料31
2.任务概述32
2.1.目标32
2.2.运行环境32
2.3.需求概述32
2.4.软件结构34
2.5.条件与限制34
3.总体设计34
3.1.处理流程34
3.2.总体结构和模块外部设计35
3.3.功能分配35
4.程序总体设计与说明36
4.1.模块描述36
4.2.病人注册模块37
4.3.病人登陆模块38
4.4.个人基本信息查询模块38
4.5.患者信息个人修改模块39
4.6.当前预约情况查询模块40
4.7.历史预约情况查询模块40
4.8.取消预约模块40
4.9.病例查看模块41
4.10.按医院搜索医生模块41
4.11.按科室搜索医生模块42
4.12.按姓名搜索医生模块42
4.13.查询医生值班表模块42
4.14.查询预约详细信息模块43
4.15.预约挂号模块43
4.16.病人评价模块44
4.17.优秀医生推荐模块44
4.18.用户管理(后台)模块44
4.19.就诊管理(后台)模块44
4.20.病历管理(后台)模块45
4.21.医生值班管理(后台)模块45
4.22.用户评价管理(后台)模块45
5.接口设计46
5.1.外部接口46
5.2.内部接口47
6.数据结构设计47
6.1.逻辑结构设计47
6.2.物理结构设计48
6.3.数据结构与程序的关系48
7.运行设计48
7.1.运行模块的组合49
7.2.运行控制49
7.3.运行时间49
8.出错处理设计49
9.安全保密设计49
10.维护设计49
UML51
1.引言51
1.1.编写目的51
1.2.项目背景52
2.需求分析52
2.1.系统参与者53
2.2.系统用例说明53
2.3.补充规格说明53
2.4.业务规则53
2.5.领域对象分析54
3.系统分析55
3.1.系统整体的用例模型55
3.2.系统整体的用户类图56
3.3.系统总体的顺序图57
3.4.查询58
3.5.预约挂号60
3.6.收费系统61
3.7.办理就诊卡系统63
3.8.自助挂号64
4.架构设计说明66
4.1.逻辑视图66
4.2.进程视图67
4.3.开发视图68
4.4.物理视图68
4.5.用例视图69
5.设计类说明70
5.1.设计类字典70
5.2.物理包设计71
医疗中心预约管理系统
可行性研究报告
1.引言
1.1.编写目的
我国现行医疗体制所带来的患者就诊观念僵化、医患关系紧张、医生水平差距悬殊及医疗资源分布不均的实际,客观上加剧了挂号难、挂专家号更难的现状。
为此,很多看病的人就诊挂号,只能找号贩子或者找关系。
我们需要一个能支撑很多人都能同时网上预约挂号的系统。
如果人使用传统的排队挂号方法,不仅浪费了大量的医疗资源,而且可能会使得病情严重的病人得不到及时的救治。
为此开发医疗中心预约管理系统软件,方便广大用户就医问诊、缓解医院挂号压力、提高医疗服务质量和工作效率而定制开发的医院门诊预约挂号系统。
系统采用先进.NET技术,为医院提供一个使用的多路分诊挂号渠道,有效缓解医院高峰期挂号分诊难的问题;为广大用户提供一个便捷的数字化挂号就医渠道,节省大量的时间和费用。
可行性研究的目的是为了对问题进行研究,以最小的代价在最短的时间内确定问题是否可解。
再经过对此项目进行详细调查研究,初步拟定系统的实现报告,对软件开发中将要面临的问题及其解决方案进行初步设计及合理安排。
明确开发风险及其所带来的经济效益。
通过可行性研究,该计划是否应该执行,便显而易见。
医疗中心预约管理系统能够实时的和准确的反应每个时间段需要接受治疗的病人情况。
也可以让医院适宜的调度医疗资源,并且可以在看病和被看病之间进行进一步的审查登记,提高效率。
预期的读者为软件管理人员,开发人员,维护人员以及相应的医院及医疗中心。
1.2.项目背景
项目名称:
医疗中心预约管理系统(HospitalAppointmentSystem)
项目提出者:
医院管理运营者
项目开发者:
深圳大学软件工程3班14组
预期的用户:
需要预约的病人,各大医院和医疗中心
1.3.术语说明
HAS(HospitalAppointmentSystem):
医疗中心预约管理系统
TFD(TransactionFlowDiagram):
系统业务流程图
DFD(DataFlowDiagram):
数据流程图
Dataprocessing:
数据处理
Transactionprocessing:
事务处理
Dataprocessingcycle:
数据处理流程
Dataacquisition:
数据采集
Dataprocessingsystemsecurity:
数据处理系统安全性
1.4.参考资料
《管理信息系统》黄梯云编著高等教育出版社
《软件工程》张海藩编著人民邮电出版社
《Delphi实用教程》郑阿奇主编电子工业出版社
《SQLServer实用教程》刘卫宏编著科学出版社
《C程序设计》谭浩强清华大学出版社
1.2.可行性研究的前提
2.1.要求
●功能
1)为患者提供个人信息登记、查询、挂号等功能;为医师提供病人信息查询、添加等功能;为管理人员提供病人信息管理,医师信息管理,信息发布等功能。
2)如果用户要进行预约挂号操作,必须先要成为网站的注册会员。
如果已经是会员,先输入会员名和密码,进行登陆;非会员到注册页面,输入提示必须要填写的信息,注册成功以后,用自己的会员名和密码登陆,才能进行下一步的预约挂号操作。
为选择要挂号的科室、专家或医生以及预约时间等必须选择的信息,确认挂号以后,选择缴费方式,经过网站后台审核通过以后,提交挂号信息,系统提示挂号成功,并反馈给客户一个挂号编号。
图1病人预约挂号流程图
图2系统管理功能模块图
图3各部分之间的关系
●性能
病人用户能够即使得到医院信息和医师信息,医院管理人员录入的信息必须快速且无差错地存储至中心服务器,且对浏览器端的数据应该及时进行更新。
应该达到10000人同时访问而不出现服务器瘫痪的情况。
●系统的输入
输出医院不同门诊部各位接诊医师资料,不同医师的挂号费用,以及各位医师的忙闲状态,供病人选择不同的就诊医师。
输出数据要简捷、祥实。
●系统的输出
方便、简捷、快速的输入病人信息或者医师信息。
●安全和保密要求
病人用户只能查询与自己有关的信息和公布的公共信息,不能对任何收费数据进行更改;医师用户有权在有限次数和有限期限内对所负责病人的信息进行输入和修改;管理人员则拥有在其权限内的查询、修改、删除病人信息,医师信息,通知信息的权限。
该系统可以与医师管理系统,医院收费管理系统,药房管理系统,医疗器械管理系统,病房管理系统等配合使用,具有一定的兼容性。
●数据流程图
1)顶层数据流程图(DFD)
2)功能级数据流程图(DFD)
3)底层数据流程图(DFD)
●完成期限要求
本门实验课程的最后一个课时。
2.2.开发目标
旨在开发一个统一的医院信息管理平台,利用信息化手段辅助医院管理,达到提升医院信息化管理水平的目的。
1)医院管理人员能够更方便的进行管理工作,包括患者信息管理、医师信息管理医院信息管理、收费信息管理等;
2)患者用户能够利用该系统进行信息查询、挂号、充值、结账;
3)医师则能够更方便的获取患者信息;
4)医院可以更方便的对患者和本院医师的信息进行管理。
2.3.具备条件
项目开发中所具备的条件、假定和所受到的限制,如:
●所建议系统运行寿命的最小值
系统运行寿命的最小值应达三年。
●进行系统方案选择比较的时间
系统方案选择比较的时间为一个月。
●硬件、软件、运行环境和开发环境方面的条件
硬件环境:
•PII或更高档微机,笔记本电脑
•运行时内存要求:
1MB;
•安装所需硬盘:
5MB;
•打印机:
可选。
软件环境:
•中文Windows98/2000/XP
•英文Windows98/2000/XP
•WindowsNT4.0
●可利用的信息和资源
可参考已有的应用程序和数据库管理系统。
●系统投入使用的最晚时间
该门课程实验课程完成的时间。
2.4.进行可研究性研究的方法
可行性研究采用的方法如下:
1)对医院和客户的前期调查;
2)系统试行阶段的评价和改进;
3)摘要说明使用的策略和基本方法,如调查,加权,确定模型和仿真;
4)市场相关产品、同类产品调查等。
2.5.评价尺度
系统进行评价时所使用的主要尺度为各项功能的优先次序、开发时间的长短及使用中的难易程度。
3.对现有系统的分析
3.1.处理流程和数据流程
我们从业务和管理两大方面对医院的流程进行了分析。
图4现有系统流程图
3.2.工作负荷
现有系统是手工操作的,病人需要花费大量时间取号和等待叫号,医院需要安排专门的人员发号和叫号,不仅速度慢,效率低,而且信息也不易长期保存,操作时需要花费大量的人力物力资源,已经与现在经济高效的时代不相符了。
3.3.费用开支
由于现有系统的工作负荷严重超载,在现有系统上投入的人力,设备,空间,材料,等等与其他的一系列支持性服务越来越大,导致开发费用支出巨大,严重影响系统的可用性,急需改进。
3.4.人员
医院安保人员,发号叫号人员,提供咨询服务等人员。
3.5.局限性
我们认为目前状况的局限性主要体现在以下几个方面:
1)医院整体反应速度慢,可能会延误病情,导致病人得不到及时的救冶;
2)采用人工方式进行数据处理,速度慢,而且效率不高;
3)人工管理效率低下,容易造成资源的浪费;
4)各部门协调性低,协调成本高;
5)信息交流慢,医院和其他相关医疗机构在合作方面差;
6)信息反馈速度慢,没有设置较好的病人反馈平台。
4.所建议的系统的技术可行性分析
4.1.对所建议系统的简要描述
利用.NET技术,开发医院网站挂号平台,系统稳定性好,安全性强,易维护,菜单导航,方便患者操作。
专家情况介绍详细全面,有利于患者正确选择;通过选择就科室、专家,预约日期,提交预约信息。
4.2.与现有系统比较的优越性
1)利用计算机处理数据的快速有效的优点,将本系统安装在计算机上,提供人性化的界面供用户进行操作,用户就可以对各种信息进行操作,这样不仅可以减少人员的工作量,提高操作效率,也可以避免有人工输入的某些信息的错误,操作起来简便,快捷,数据的准确性高,使管理效率大大提高。
2)由于使用系统可以大大提高处理速度和效率,可以减少人力和其他设备的使用,从而减少人力和设备的费用支出。
3)提高病人信息的安全性和保密性,需要设置登录该系统的用户名和密码,供登录时身份认证,并且设置访问权限来限制不同用户的操作权利。
4.3.采用建议系统可能带来的影响
●对设备的影响
可能需要用户用一些比较适应系统的硬件设备,比如安装某些软件,可能占用一部分存储空间,所以要求用户机器存储空间要足够。
●对软件的影响
该系统需要在Windows2000及其以上的版本上运行。
●对用户单位机构的影响
由于本系统完全考虑了各个文化水平的用户的使用,因此在用户使用该系统之前无须进行太多培训,用户可以参考用户手册便可灵活运行该系统。
●对系统运行过程的影响
1)用户的操作规程,本系统的操作规程通俗易懂;
2)运行中心的操作规程也很简单
●对开发的影响
开发过程中需要用户大力支持。
一个新系统的开发,必然会减少用户们的工作量。
●对地点和设施的影响
对原有地点设施无影响。
●对经费开支的影响
除了需要支付开发单位的有关费用外,每年还需要一定的运行维护费用。
4.4.局限性
由于医院信息系统是一个信息量大,而且还有一些信息,如药品的在存储量,预约前的一些信息等,都需要及时的进行反馈,如果建立统一的数据中心可能在前期不能及时地处理好数据,耽误一小段时间的运营。
4.5.技术条件方面的可行性
本系统是采用visualc++6.0开发的,提供了强大的视图编程集成环境,所以在一些基本的界面设计上使开发变得很容易。
另外通过SqlServer这种高效的关系数据库,还有Windows系列的操作系统紧密集成,这种安排使SqlServer能充分利用系统提供的特性。
对于即将开发的该系统来说,SqlServer是一个很好的选择。
而开发人员都具有一定的编程基础和系统开发经验,并且已经熟练掌握。
同时,考虑到开发期限较为充裕,预计可以在规定期限内完成开发。
5.所建议系统的经济可行性分析(投资和效益分析)
5.1.支出
●基本建设投资
网络平台的建设:
5万元左右;
服务器与存储系统:
10万元左右;
系统开发:
30万元左右;
总计45万元左右
●其他一次性支出
外购开发工具、软件环境费用共3万元。
总计3万元
●经常性支出
运行维护费用
1)硬件维护运行,包括设备耗电量和检修维护,这块费用在每年10万左右;
2)软件运行维护,按开发费用的5%计算1.5万/年左右
3)人员成本与办公经费28.2万/年左右
总计39.7万/年左右
5.2.效益
●一次性收益
本系统将主要从以下几个方面减少支出以及提高效益:
1)减少药房,门诊的员工人数,减少工资的支出。
2)减少各部门之间协调,以及管理的成本。
3)通过该系统提高各部门的工作效率,达到事半功倍的效果。
4)提高病人的满意度,提升医院的知名度。
●非一次性收益
原先每年需支出员工工资123.6万元,现每年需支出员工工资28.2万元,每年共节省工资支出95.4万。
●不可定量的收益
进一步实现办公自动化,减少人力投资和办公费用,极大提高办公效率。
5.3.收益/投资比
在6年期内,系统总成本286.2万元,系统总收益572.4万元。
1)投资回收期:
2年内;
2)纯收益:
572.4-286.2=286.2万元
从经济上考虑,开发本系统完全可行的。
5.4.投资回收周期
根据投资回收周期的计算方法收益的累计数开始超过支出累计数的时间为2年。
5.5.敏感性分析
系统生存周期长度、系统工作负荷量变化、处理速度要求、设备和软件配置变化对支出和效益的影响小。
6.社会因素方面的可行性
6.1.法律方面的可行性
所有软件都选用正版,一方面不会在开发软件工程过程中出现因不正版软件的问题出现错误;另一个方面是涉及到版权问题以免侵犯到该软件的专利权。
我们所采用的MicrosoftVisualBasic、Delphi、SQL等都是正版的软件。
所有技术资料都由提出方保管,这样才能保证技术材料的可靠性以及权威性。
同时让提出方对这个技术资料持有专利权。
而我们的技术资料一方面是上网寻找的相关材料,还有是从一些相关书籍上借用的。
所有的资料都是由提出方拥有跟保管。
合同制定确定违约责任。
这是软件工作当中最敏感的问题,所以我们只有制定合同确定一切问题,以免因为被人推卸责任和侵犯到专利和版权。
具体的我们会先申请专利,注册商标。
还有跟某些开发过程中的商家签定合同。
跟要利用我们的开发的软件的合作人签定合同。
6.2.使用方面的可行性
就用户单位的行政管理、工作制度、人员素质考虑:
用户单位的部分工作人员会熟练操作WINDOW2003、XP,LINUX等普遍使用系统,在对用户单位的具有一定计算机专业知识的员工进行培训前提下,挑选适合人选作为系统管理员及审计员,本管理系统还是有相当大的可行性的。
而且我们是在其他医院所使用的信息管理系统的基础上借鉴开发的,所以本小组开发的系统能适用一般的行政管理、工作制度上。
7.结论
从以上分析可以看到,医疗中心预约管理系统在技术、操作、经济都有充分的可行性,其所带来的经济效益及社会效益是不可比拟的,即投资效益比远大于100%,具有较大的开发性,可投资人力、物力进行开发。
医疗中心预约管理系统
软件需求规格说明书
1.引言
1.1.编写目的
在完成了针对《医疗中心预约管理系统》软件市场的前期调查,同时与多位软件使用者进行了全面深入的探讨和分析的基础上,项目小组提出了这份软件需求规格说明书。
此需求规格说明书对《医疗中心预约管理系统》软件做了全面细致的用户需求分析,明确所要开发的软件应具有的功能、性能与界面,使系统分析人员及软件开发人员能清楚的了解用户的需求,并在此基础上进一步提出概要设计说明书和完成后续设计与开发工作。
1.2.项目背景
经过项目开发小组的前期调查工作,并与用户进行多方面的交流,我们的调查人员发现:
随着社会的进步,信息技术的不断发展,传统的医院看病管理模式不再适应医院现在的发展模式,甚至还对医院更进一步的发展造成阻碍的作用。
看病难,主要体现在医院过多繁杂的程序上浪费了大量的时间,挂号系统的不灵便使病人头疼,而医院再管理的过程虽然投入了大量的人力物力,但收到的效果不甚了了,故我们提出对医院《医疗中心预约管理系统》的研究与开发,可以解决当前医院种种看病难、管理难的难题。
1.3.术语说明
术语、缩略语
解释
OPS
OutPatientSystem,门诊系统
HIS
HospitalInformationSystem,医院信息系统
1.4.参考资料
资料名称[标识符]
出版单位
作者
软件工程导论(第五版)
清华大学出版社
张海藩(编著)
《基于CMMI的软件工程实训指导》
清华大学出版社,北京交通大学出版社
郑宁,吴昊
《JHIS门诊挂号需求规格说明书》
张万军
2.项目概述
2.1.待开发软件的一般概述
此软件旨在使医院更好的为病人服务,提高医院挂号的效率,并完成挂号工作人员,病人,医生以及科室信息的基本维护。
系统
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 文档