患者监护系统可行性分析与需求分析.docx
- 文档编号:8728707
- 上传时间:2023-02-01
- 格式:DOCX
- 页数:10
- 大小:122.67KB
患者监护系统可行性分析与需求分析.docx
《患者监护系统可行性分析与需求分析.docx》由会员分享,可在线阅读,更多相关《患者监护系统可行性分析与需求分析.docx(10页珍藏版)》请在冰豆网上搜索。
患者监护系统可行性分析与需求分析
中央民族大学
软件工程实验报告
患者监护系统可行性分析与需求分析
姓名:
***
学号:
2013年10月26日
1.引言
1.1编写目的
【阐明编写可行性研究报告的目的,指明读者对象。
】
本系统以病房监护为目的,完成对病人身体指数的随时监测,方便医院对病人病历、身体指数等的管理。
1.2项目背景
【应包括:
a.所建议开发软件的名称;
b.项目的任务提出者、开发者、用户及实现软件的单位;
c.项目与其他软件或其他系统的关系。
】
在现代社会,病人管理通常要投入大量的人力资源,用于查房,看护等方面,方便于医院随时获取病人病情,和处理病人应急情况。
而本项目可以减少这些不必要的人力资源输出,降低医院在此方面的经济投入。
1.3定义
【列出文档中所用到的专门术语的定义和缩写词的原文。
】
本系统可以定义为一个主要为处理病人危急情况而设计的病房监护管理系统。
1.4参考资料
【列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括:
a.项目经核准的计划任务书、合同或上级机关的批文;
b.与项目有关的已发表的资料;
c.文档中所引用的资料,所采用的软件标准或规范。
】
《软件工程》,浙江大学出版社,王慧芳、毕建权编著,齐志昌、陈越主审。
2.可行性研究的前提
2.1要求
【列出并说明建议开发软件的基本要求,如
a.功能;
b.性能;
c.输出;
d.输入;
e.基本的数据流程和处理流程;
f.安全与保密要求;
g.与软件相关的其他系统;
h.完成期限。
】
本项目以简单的硬件接口,实现对病房的电子管理。
预计在本学期末完成。
2.2目标
【可包括:
a.人力与设备费用的节省;
b.处理速度的提高;
c.控制精度或生产能力的提高;
d.管理信息服务的改进;
e.决策系统的改进;
f.人员工作效率的提高,等等。
】
指导老师1人;
小组成员1人。
2.3条件、假定和限制
【可包括:
a.建议开发软件运行的最短寿命;
b.进行系统方案选择比较的期限;
c.经费来源和使用限制;
d.法律和政策方面的限制;
e.硬件、软件、运行环境和开发环境的条件和限制;
f.可利用的信息和资源;
g.建议开发软件投入使用的最迟时间。
】
本系统至少应使用5年。
应在一周内完成系统实现方案的选择比较。
本系统对客户机及服务器的硬件性能无特殊要求。
系统软件、数据库系统、开发工具都采用免费软件,本系统运行时要求计算机网络连接稳定可靠。
应在2014年1月20日投入使用。
2.4可行性研究方法
【说明这项可行性研究将是如何进行的,所建议的系统将是如何评价的,摘要说明所使用的基本方法和策略。
】
由于小组成员仅为一人,所以时间安排自由,尽量抓紧一切时间尽快完成任务。
2.5决定可行性的主要因素
本软件系统开发成本低,有较强的应用需求。
3.对现有系统的分析
3.1处理流程和数据流程
3.2工作负荷
经市场调查发现,目前医院尚无完善的患者监护系统,主要还是依靠医生、护士的定时查房。
这样不仅大量消耗人力、精力,而且还容易出现失误,致使救治不够及时。
3.3费用支出
【如人力、设备、空间、支持性服务、材料等项开支。
】
医务人员的工资及设备的耗损。
3.4人员
【列出所需人员的专业技术类别和数量。
】
医务人员若干。
3.5设备
医疗设备若干。
3.6局限性
【说明现有系统存在的问题以及为什么需要开发新的系统。
】
繁琐、易出差错、效率低。
4.所建议技术可行性分析
4.1对系统的简要描述
本项目实现的功能有:
1、病人病情应急处理;
2、医生调取病人病历,获悉特定病人病情;
3、系统定期对病人情况存档。
4.2处理流程和数据流程
第一层
第二层
E-R图:
数据字典:
名字:
患者信息
描述:
存储患者的个人详细信息
定义:
患者信息=患者编号+患者姓名+患者性别+患者年龄+患者病情
位置:
患者信息
名字:
护士信息
描述:
存储护士的个人详细信息
定义:
护士信息=护士编号+护士姓名+护士性别+护士年龄+护士级别
位置:
护士信息
名字:
患者日志
描述:
存储患者的生理信息
定义:
患者日志=患者姓名+日期+体温+血压
位置:
患者日志
名字:
安全范围
描述:
存储患者病情的安全范围
定义:
安全范围=病理名称+最大值+最小值
位置:
安全范围
4.3与现有系统比较的优越性
4.4采用建议系统可能带来的影响
4.4.1对设备的影响
基本上不损害设备。
4.4.2对现有软件的影响
大大提高了工作效率。
4.2.3对用户的影响
提高了工作效率,降低了劳动强度。
4.2.4对系统运行的影响
系统运行安全稳定。
4.2.5对开发环境的影响
4.2.6对运行环境的影响
4.2.7对经费支出的影响
大量节约了支出。
4.5技术可行性评价
【包括:
a.在限制条件下,功能目标是否能达到;
b.利用现有技术,功能目标能否达到;
c.对开发人员数量的和质量的要求,并说明能否满足;
d.在规定的期限内,开发能否完成。
】
中央民族大学信息工程学院目前的硬件设施满足本系统运行的需要。
实现本系统需要的技术包括:
PHP脚本的编程、Mysql数据库应用、ApacheWEB服务器的架设与管理、B/S结构的软件开发技术。
目前这些技术已经成熟。
《患者监护系统》是个小型软件系统,完全可以按时开发完成。
5.所建议系统经济可行性分析
5.1支出
5.1.1基建投资
无
5.1.2其他一次性支出
无
5.1.3经常性支出
网费等。
5.2效益
5.2.1一次性收益
未知
5.2.2经常性收益
患者的使用
5.2.3不可定量收益
及时监测患者生理情况,及时对患者进行救治,挽救更多生命。
5.3收益/投资比
5.4投资回收周期
5年
5.5敏感性分析
【敏感性分析是指一些关键性因素,如:
系统生存周期长短、系统工作负荷量、处理速度要求、设备和软件配置变化对支出和效益的影响等的分析。
】
是指一些关键性因素与这些不同类型之间的合理搭配、处理速度要求、设备和软件的配置等变化时,对开支和收益的影响最灵敏的范围的估计。
6.社会因素可行性分析
6.1法律因素
【如,合同责任、侵犯专利权、侵犯版权等问题的分析。
】
所用软件开发工具、系统软件都为免费。
利用本学校资源自主开发,具有独立版权,归中央民族大学信息工程学院所有。
6.2用户使用可行性
【如,用户单位的行政管理、工作制度、人员素质等能否满足要求。
】
医院的医生、护士及相关医务人员完全具备使用本软件系统的能力。
7.其他可供选择的方案
【逐个阐明其他可供选择的方案,并重点说明未被推荐的理由。
】
无其他方案。
8.结论意见
【结论意见可能是:
a.可着手组织开发;
b.需待若干条件(如资金、人力、设备等)具备后才能开发;
c.需对开发目标进行某些修改;
d.不能进行或不必进行(如技术不成熟,经济上不合算等);
e.其他。
】
可着手组织开发。
9.非功能性需求
本部分主要为阐述此项目的性能需求等一些次要需求。
9.1性能需求
时间特性需求中,要求相应时间按照优先级进行相应设定,高优先级的相应请求必须第一时间进行响应。
其余时间特性需求一般。
适应性需求中,要求能符合一般医院结构,并能在其中使用。
9.2其它需求
其它需求一般。
10运行需求
本部分主要描述此项目的运行需求,包括用户界面和故障处理两部分。
10.1用户界面
由于本项目是在医院使用的病房监护管理系统,因此本项目可运行在一个特定的电脑上,采用全屏模式。
10.2故障处理
具体故障处理,找项目设计师、软件升级人员,或者软件BUG处理人员。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 患者 监护 系统 可行性 分析 需求