实验二 传统软件工程的可行性分析
一、目的与任务
目的：确定课题，熟悉软件开发环境，写出可行性报告。
任务：根据提供的课题需求和条件，按照软件开发国家标准可行性报告书写格式，写出该课题的可行性报告，并熟悉相应的软件开发环境。
二、内容
1. 引言
患者监护系统是一个以计算机为中心的系统，旨在提高医院对病人的监护效率和响应速度。该系统将通过实时监测病人的生理信号来减少对护士数量的依赖，并及时响应病人病情的变化。
2. 项目背景
目前，医院病人监护主要依赖于护士的人工护理，这种方法存在监控不及时和人力资源消耗大的问题。开发患者监护系统可以改善这些问题，提高医疗服务质量。
3. 项目概述
患者监护系统的主要目标是实现对病人生理信号的实时监控，自动记录病历，以及在病人生理信号异常时及时报警。系统将减少护士的工作量，提高病人护理的及时性和准确性。
4. 可行性分析的前提
4.1 项目的要求
功能要求：系统需要能够接收和处理病人的生理信号，包括血压、体温、脉搏和心电图等；定时更新病历；在生理信号异常时发出警告；按需打印病情报告。
性能要求：系统应具备高可靠性和实时性，以确保病人安全。
安全与保密要求：病人的生理数据和病历信息需要严格保密，只能由授权的医护人员访问。
输入和输出要求：系统应能处理各种生理信号的输入，并能生成和打印病历报告。
4.2 项目的目标
通过实施患者监护系统，提高病人护理的效率和质量，减少医疗事故，提升医院的服务质量。
4.3 项目的环境、条件、假定和限制
技术环境：系统需要在医院内部网络环境中运行，要求有稳定的网络连接和足够的计算资源。
法律和政策限制：系统开发和运行需遵守医疗行业的相关法律法规。
硬件和软件条件：需要配备相应的传感器、计算机和软件系统。
5. 技术可行性
患者监护系统的技术可行性较高。现代传感器技术和计算机技术的发展已经能够支持实时生理信号的监测和处理。数据库技术可以用于存储和管理大量的病历数据。此外，现有的报警系统技术也可以集成到患者监护系统中。
6. 经济可行性
患者监护系统的开发和运行成本包括硬件设备、软件开发、人员培训和维护费用。然而，长期来看，系统可以减少护士的数量，降低人力成本，提高病人护理的效率，从而带来经济效益。
7. 法律可行性
系统开发需遵守医疗行业的法律法规，保护病人隐私。医院需确保系统的合法合规性，并取得必要的许可和认证。
8. 用户使用可行性
系统操作应设计得简单直观，以便护士和其他医护人员能够快速学习和使用。系统的用户友好性是确保其广泛使用和接受的关键。
9. 其他与项目有关的问题
系统的外部项包括病人和护士，他们将是系统的主要用户。系统的设计需要考虑他们的使用习惯和需求。
综上所述，患者监护系统的开发在技术、经济和法律上都是可行的，并且能够提高医院的护理质量和效率。
实验三 传统软件工程的需求分析建模
一、目的与任务
目的：确定项目要做什么及其可实施性，在此基础上完成系统的逻辑功能模型的建立。
任务：可采用不同的需求分析技术，完成对项目的需求分析过程，给出系统的逻辑功能模型，数据字典以及规格说明书。
二、内容
顶层数据流图
一层数据流图
二层数据流图
（1）数据流条目
基本信息 =姓名+年龄+性别+科室+床号+编号
生理信号 =血压+体温+脉搏
病人危急信息 =患者姓名 +年龄 +性别+科室 +床号 +编号+生理数据
警报信息 =姓名+年龄+性别+科室+床号+编号+非正常生理数据
病情报告 =患者姓名 +年龄+性别+科室+床号+编号+生理数据
（2）数据存储条目
文件名：病人信息
组成：姓名 +年龄+性别+科室+床号+编号
组织方式：索引文件，以编号为关键
文件名：患者安全范围
组成：生理信号名称 +正常数据范围 （心电、体温、血压）
文件名：患者日志
组成：姓名 +年龄+性别+科室+床号+编号+病人情况
组织方式：索引文件，以编号为关键
文件名：病情报告
组成：病人信息 + 生理信号
（3）数据项
患者名字：别名：无
类型：字符型
长度： 2{ 汉字}15
编号：别名：无
类型：整型
长度： 5 位
生理信号：别名：无
类型：浮点型
长度： 6 位
（4）加工条目
加工名：患者监护系统
输入：生理信号，安全范围
输出：患者日志，病情报告
加工名：录入储存处理
输入：生理信号
加工逻辑：接收存储生理信号
If 生理信号正常
Then 定时更新到患者日志中
Else 发出警报
加工名：更新日志
输入：生理信号
输出：日志数据
加工逻辑：添加生理信号信息
加工名：护士查询
输入：患者信息
输出：病情报告
加工逻辑：If 信息正确
Then 从患者日志中查询到该病人信息并打印病情报告
Else 显示错误
新系统模型
《需求规格说明书》
1引言
1.1编写目标
在可行性研究基础上，经过了解并调查医院患者监护系统，深入明确了医院患者监护系统软件需求，让系统开发者能够基础了解本系统开发目标，开发方法，和现在软件、硬件情况，和让项目组长或责任人安排项目计划和进度，并组织人员进行软件开发和测试。
本文档供项目责任人，系统分析人员和软件开发人员参考。
1.2背景
项目名称：医院患者监护系统
项目提出者：XX医院
项目开发者：软件编程人员
用户：XX医院医生，护士及其它工作人员
1.3定义
数据流图：它描绘信息流和数据从输入移动到输出过程中所经受改变。
层次方框图：表示一个系统各部分和各步骤之间关系图示，它作用在于能够清楚地表示比较复杂系统各部分之间关系。
实体—联络图：描述了从用户角度看到数据，它反应了用户现实环境，将用户数据要求清楚正确描述出来。
1.4参考资料
[1] 自编《软件工程实验指导书》
[2] 李爱萍、崔冬华、李东生等编著《软件工程》
[3] 张海藩编著，软件工程导论，北京：清华大学出版社，2003 第4版
2任务概述
2.1目标
伴随科技快速发展，医院理念和服务也应该对应改变。利用计算机技术和网络技术等现代科技优异结果，改善传统医院患者监护系统势在必行，智能化医院病房监护系统实现使住院患者，尤其是重危病人康复愈加安全有效。医院可经过患者监护系统随时对病人进行监控和会诊，这么既能够完善医院服务，还能够加紧医院现代化管理进程。
此系统首先输入病人基础信息（姓名、住址、电话号码、住院日期，身体情况等），随时接收每个病人生理信号（脉搏、体温、血压、心电图等），定时统计病人情况以形成患者日志，当某个病人胜利信号超出医生要求安全范围时向值班护士发出警告信息，另外，护士在需要时还能够要求系统印出某个指定病人病情汇报。
2.2用户特点
此系统用户关键为医生，护士，系统管理员，这三方人员受教育程度较高，比较轻易了解和使用这个系统，系统管理员还掌握一定计算机操作水准。本系统估计使用频率较高，而且使用者不一样，要求也有不一样，所以设计时需要考虑这方面内容。
2.3假定和约束
3需求要求
3.1对功效要求
1系统层次方框图：
2.系统IPO表：
<1>接收患者信号模块IPO：
|
<2>患者信号分析模块IPO：
|
<3>警告模块IPO：
|
<4>更新日志模块：
|
<5>产生患者病情汇报模块IPO：
|
- 系统数据流图：
- 该系统ER图：
3.2对性能要求
3.2.1精度
输入、输出数据通常为整型、字符型数据，具体数据精度根据医学标准来衡量。
3.2.2时间特征要求
- 对事务响应时间（平均0.5s、最长1s）；
- 更新处理时间和对事务响应时间一致；
- 系统数据吞吐量，每秒处理事务数最多为5人；
- 系统容量，系统能够容纳事物数为300人。
3.2.3灵活性
- 操作方法上改变：支持手动输入和语音输入；
- 运行环境改变：支持多种操作系统，在Win10操作系统下也可运行；
- 同其它软件接口改变：无
- 精度和有效时限改变：精度在原有基础上有很大提升，便于护士分析管理数据；
- 计划改变或改善：将模拟信号输出为数字信号，并增加了安全模块，用于保护病人数据。
3.3输人输出要求
数据输入和输出通常采取十进制方法进行，便于用户读取和管理；输入和输出数据应一一对应，方便用户观察病人生理特征；另外，输入数据类型通常为整型（int）、字符型(char)和浮点型（double），输出能够为多个类型；病人部分生理特征也能够采取图形化方法表现出来。
3.4数据管理能力要求
系统应该有一个属于自己数据库，数据库中每个表语每个病人一一对应；系统也能够为每个病人建立单独数据库表格。通常来说，需要管理文件及统计较大，需要分配较大存放空间。
3.5故障处理要求
本系统可能出现故障为数据库数据出现混乱，产生错误信息，从而造成一定损失；也可能出现安全问题比如数据泄露等等。要处理这些故障及问题，需要医院有专门数据库管理员，对数据进行管理维护，还需要定时对数据进行备份。另外，系统也需要增加防火墙，保障数据安全性。
3.6其它专门要求
在本系统中，医院纪录患者多种数据及信息必需确保安全性和完整性。系统也应该增加部分安全方法，比如设置登录或删除时需要密码。另外，设置多个监护器来保障系统稳定性，还需确保系统更换运行环境时能够继续使用。
4运行环境要求
4.1设备
运行该软件时所需要以下设备及要求：
- 传感器，服务器，监护器，报警器；
- CPU主频应在1.0GHZ及以上，内存最少1G；
- 输入设备：键盘，鼠标；
- 输出设备：显示器，打印机；
- 需要联机存放且备份，外存应尽可能大。
4.2支持软件
软件可由Win7，Win8，Win10，WinXP，Win11等操作系统控制运行；用户注册登录后即可运行此软件。
4.3接口
本软件外部接口仅包含键盘，鼠标及显示器；用户接口为图形接口，用户可经过菜单、对话框提醒来完成对应程序和文件操作。
4.4控制
- 服务器控制包含对数据库管理和报警信号处理，管理者为医护人员；
- 中心控制机数据起源是监护器所得数据，管理者为系统管理员。
实验四 传统软件工程的结构设计
一、目的与任务
目的：在实验三基础上完成系统的体系结构的建立和系统详细设计，并给出相应的系统设计说明书。
任务：认真分析实验三的结果，给出系统合理的体系结构，描绘系统结构图，并合理划分系统的各组成模块，最后给出系统的各部分设计说明书。
二、内容
1、系统结构图
软件结构图
2、选择报警模块描绘其程序流程图
3、选择一个模块进行输入输出界面设计，输出设计主要指打印输出，输入设计主要指数据录入界面的表单设计。
患者系统管理界面设计要求元素
| 界面标识 | A1 模板文件 index.htm |
| 界面尺寸 | 1024*768 pixels |
| 界面功能 | 记录患者病情，对比安全范围，超出时警报。 |
| 备注 | 随时更新病人病情。 |
| 界面图 | 待定 |
患者系统警报界面设计要求元素
| 界面标识 | A2 模板文件 index.htm |
| 界面尺寸 | 1024*768 pixels |
| 界面功能 | 患者生理信号超出安全范围，给出警报。 |
| 备注 | 发出警报同时输入患者号码，房间号码。 |
| 界面图 | 待定 |
4、选择ACCESS，SQL SERVER等任何数据库进行存储文件格式设计（数据库结构设计）
患者表与生理参数表通过患者ID关联。
生理参数表与警报记录表通过参数ID关联。
警报规则表定义了警报触发的条件。
警报记录表记录了警报触发的事件。
警报处理表记录了警报的处理情况。
索引：为了提高查询效率，可能需要在患者ID、参数ID、警报ID等字段上建立索引。
数据完整性：确保通过外键约束和触发器来维护数据的完整性。
安全性：确保敏感数据（如患者个人信息）的存储和访问符合HIPAA等医疗数据保护法规。
可扩展性：设计数据库时考虑未来可能的扩展，如增加新的生理参数类型或警报规则。
实验五 测试
一、目的与任务
目的：在实验四基础上选择一个模块进行编码，完成相关的测试。
1、了解软件测试方法分类，其中包括：
1）白盒测试
2）黑盒测试
3）静态测试
4）动态测试
2、了解测试类型
1）单元测试
2）集成测试
3）确认测试
4）黑盒测试
5）白盒测试
6）功能测试
7）α测试
8）β测试
任务：正确运用软件测试技术和方法，完成系统的单元测试、综合测试、确认测试、系统测试的方法，掌握测试用例的设计方法，并给出测试报告。
二、内容
报警模块程序流程图：
模块程序代码：
#include <iostream>
#include <vector>
#include <string>
#include <cassert>
class Patient {
public:
Patient(int heartRate, double bloodPressure, double temperature)
: heartRate(heartRate), bloodPressure(bloodPressure), temperature(temperature) {}
int getHeartRate() const { return heartRate; }
double getBloodPressure() const { return bloodPressure; }
double getTemperature() const { return temperature; }
private:
int heartRate;
double bloodPressure;
double temperature;
};
class AlarmModule {
public:
std::vector<std::string> checkPatient(const Patient& patient) {
std::vector<std::string> alarms;
if (patient.getHeartRate() < 60 || patient.getHeartRate() > 100) {
alarms.push_back("Heart rate alarm: Abnormal heart rate detected.");
}
if (patient.getBloodPressure() < 90 || patient.getBloodPressure() > 120) {
alarms.push_back("Blood pressure alarm: Abnormal blood pressure detected.");
}
if (patient.getTemperature() < 36.5 || patient.getTemperature() > 37.5) {
alarms.push_back("Temperature alarm: Abnormal temperature detected.");
}
return alarms;
}
private:
// Normal ranges for physiological parameters
const int MIN_HEART_RATE = 60;
const int MAX_HEART_RATE = 100;
const double MIN_BLOOD_PRESSURE = 90;
const double MAX_BLOOD_PRESSURE = 120;
const double MIN_TEMPERATURE = 36.5;
const double MAX_TEMPERATURE = 37.5;
1、白盒测试：采用语句覆盖方法
覆盖（A B）：用例：patient1(30, 100, 36.5)，报警
覆盖（A C D）：用例：patient2(80, 180, 36.5)，报警
覆盖（A C E F）：用例：patient3(90, 100, 40.2)，报警
覆盖（A C E F G）：用例： patient4(65, 100, 36.5)，不报警
2、黑盒测试：采用等价类划分法
根据输入条件的合理和不合理范围，将输入划分为等价类。
心跳等价类：
正常心跳范围（60-100次/分钟）
低于正常范围（小于60次/分钟）
高于正常范围（大于100次/分钟）
血压等价类：
正常血压范围（90-120mmHg）
低于正常范围（小于90mmHg）
高于正常范围（大于120mmHg）
体温等价类：
正常体温范围（36.5-37.5°C）
低于正常范围（小于36.5°C）
高于正常范围（大于37.5°C）
至少设计3*3=9组用例，分别覆盖每个生理信号的低值、正常值、高值。
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ||
| 心率 | 40 | 45 | 22 | 70 | 78 | 88 | 180 | 200 | 222 | |
| 血压 | 40 | 92 | 180 | 40 | 100 | 180 | 40 | 100 | 200 | |
| 体温 | 38.8 | 36.6 | 34.4 | 38.8 | 36.7 | 35.1 | 38.8 | 36.6 | 35.0 | |
| 报警 | √ | √ | √ | √ | √ | √ | √ | √ |
实验六 面向对象的分析与设计
一、目的与任务
目的：掌握面向对象的分析、设计方法，建立对象模型、功能模型和动态模型，并掌握UML中常用的模型符号的使用方法。
任务：用一个简单项目（可以考虑仍然选择前面面向过程软件工程所选定的项目），通过分析，建立系统用例图，抽取出类，建立顺序图及类的状态图等。
二、内容
1、类图
2、用例的交互顺序图
3、类的状态图
4、类的所有服务（护士类）
扫一扫
3160
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
