可行性分析

目录

第1章 系统分析

1.1 可行性分析

1.1.1 技术可行性分析
1.1.2 经济可行性分析
1.1.3 社会可行性分析
1.1.4 法律可行性分析
1.2 系统流程分析

1.2.1 系统开发总流程
1.2.2 登录流程
1.2.3 系统操作流程
1.2.4 系统性能分析

第1章 可行性分析
1.1可行性分析
下面分别从技术可行性、经济可行性、社会可行性以及法律可行性四个方面进行分析。

1.1.1 技术可行性分析
基于当前技术发展和应用实践，无障碍导航助手项目在大学生能力范围内已具备以下技术支撑：
轻量化多模态感知技术
采用手机摄像头作为核心传感器，结合 YOLOv5s 等轻量级目标检测模型（已实现 30fps 实时检测），可有效识别台阶、井盖等常见障碍物。通过 OpenCV 库进行图像预处理，利用手机边缘计算能力实现 0.8 秒内响应。针对低光照场景，可通过调用手机闪光灯或增强对比度算法提升识别效果，无需依赖复杂红外设备。
路径规划算法优化
依托高德地图 API 的 "无障碍路径" 功能接口，实现盲道优先的路线生成。通过参数调优（如设置最大坡度阈值）完成路线纠偏，避免复杂算法开发。历史路径数据存储于本地 SQLite 数据库，支持离线模式下的路径记忆与快速检索。
低成本交互系统设计
采用 "震动 + 语音" 双模态反馈：震动模块通过手机马达实现分级预警（0.5m/1m/2m 不同震频），语音合成调用百度 API 免费额度。北斗 / GPS 混合定位（精度 2-5 米）结合手机加速度传感器，提升导航稳定性。紧急 SOS 功能通过摇晃检测触发短信发送，集成手机内置定位信息。
开源生态与标准化基础
基于微信小程序开发前端界面，复用开源组件库（如 WeUI）降低设计成本。后端采用 Python Flask 框架本地部署，符合大学生技术栈。遵循《信息无障碍标准》基础要求，通过树莓派等开源硬件进行原型测试，设备总成本控制在 500 元以内。
潜在挑战与应对
数据隐私：所有用户数据本地存储，不上传云端，避免敏感信息泄露。
场景适配：优先实现室外场景，后期通过蓝牙信标扩展室内导航，采用低成本 Beacon 设备替代激光雷达。
模型优化：通过模型量化（如 YOLOv5s 转 ONNX 格式）和手机 GPU 加速，降低对硬件性能的依赖。

1.1.2 经济可行性分析

开发成本低
零硬件投入：核心依赖智能手机（用户自备），无需采购激光雷达等专业设备
开源工具链：Python/OpenCV/ 微信小程序均为免费开发工具
API 免费额度：高德地图 API（每月 10 万次免费调用）、百度语音合成（每月 5 万次免费）
维护成本可控
本地部署轻量级后端（Flask+SQLite），无需云服务器费用
模型更新通过 GitHub 开源社区协作完成
资金来源
学校创新创业基金（申请 5000 元以内）
公益机构捐赠（如残联提供测试场地）
团队成员自筹（主要为时间投入）
经济风险应对
采用最小可行产品（MVP）模式，分阶段开发
优先实现核心功能（障碍物检测 + 基础导航），后期扩展复杂模块
1.1.3 社会可行性分析

政策支持
符合《"十四五" 残疾人保障和发展规划》中 "推进信息无障碍建设" 要求
响应教育部《教育信息化 2.0 行动计划》中 "技术赋能特殊教育" 目标
用户需求明确
调研数据：82% 视障用户因障碍物检测缺失摔倒
现有痛点：需手动切换无障碍模式、无法应对临时障碍
实施路径清晰
校园场景验证：与校内公益社团合作，20 名视障用户参与测试
社会价值传播：
参加 "挑战杯" 等创新创业赛事
举办 "障碍识别技术工作坊"，邀请普通学生体验视障导航
通过短视频平台（抖音 / 快手）展示开发过程，提升公众认知
合作网络基础
技术指导：计算机学院教师提供算法优化建议
测试资源：学校无障碍设施（坡道 / 电梯）作为天然实验场景
1.1.4 法律可行性分析

数据安全合规
用户数据本地存储（SQLite），不上传云端
仅收集必要信息（位置信息需用户授权）
符合《个人信息保护法》最小必要原则
知识产权合规
使用开源协议（MIT/Apache）的第三方库（YOLOv5s、OpenCV）
地图数据来自高德 API，遵守《高德地图 API 服务条款》
代码开源至 GitHub，声明知识共享许可
功能合法性
SOS 功能通过调用手机系统短信接口，不涉及电信业务资质
语音合成使用百度 API，符合《互联网信息服务管理办法》
紧急模式触发需用户手动开启，避免误操作纠纷
风险防控措施
开发前与学校法律顾问沟通合规性
在用户协议中明确免责条款（如不保证 100% 安全）
测试阶段签署知情同意书，保障参与者权益
1.2 系统流程分析
1.2.1 系统开发总流程
开发阶段：需求分析 → 原型设计 → 核心开发 → 测试迭代 → 部署推广
关键任务：
需求分析：完成 200 份问卷调研，确定核心功能
原型设计：用 Axure 制作低保真交互原型
核心开发：分模块实现（前端小程序 / 后端 Flask / 算法集成）
测试迭代：校园场景测试，收集 20 名视障用户反馈
部署推广：提交应用市场，参与创新创业赛事
本系统的开发流程如图1-1所示。

图1-1系统开发流程图

1.2.2 登录流程
用户登录流程是系统安全访问的重要组成部分，确保了用户能够安全地访问并操作系统。如图 1-2 所示，登录流程遵循以下步骤：

用户输入凭证
用户在登录页面输入手机号和密码，支持语音输入辅助（调用微信小程序语音转文字 API）。
本地验证
系统通过 Flask 后端查询本地 SQLite 数据库，验证账号密码匹配性。密码采用 SHA-256 哈希存储（符合《个人信息保护法》要求）。
会话生成
验证成功后生成唯一会话 Token（有效期 24 小时），加密存储于手机本地缓存，避免敏感信息泄露。
界面跳转
验证通过则跳转至主界面，显示实时障碍物检测画面；验证失败则弹出提示框（语音播报 + 文字显示），并记录错误次数（3 次错误后锁定账号 20 分钟）。
借助上述流程设计，实现了无密码明文传输和会话自动过期机制，在保障安全性的同时兼顾视障用户的操作便捷性。

图1-2 登录流程图

1.2.3 系统操作流程
主流程：
用户启动 APP → 进入语音引导界面
开启摄像头 → 实时检测障碍物（YOLOv5s）
检测到障碍物 → 震动 + 语音预警（距离分级）
语音指令触发导航 → 调用高德 API 生成路径
到达终点 → 语音提示完成
子流程：
紧急 SOS：摇晃手机 → 发送含定位的短信给预设联系人
离线模式：本地加载常用路线 → 仅使用摄像头检测

图1-3系统操作流程图

1.2.4 系统性能分析
定位精准度
室外定位
在室外环境下，我们主要依靠手机内置的 GPS 模块来实现定位。考虑到我们的技术能力和资源限制，暂不涉及复杂的多卫星系统融合。在开阔的室外环境，比如校园操场、空旷广场等，手机 GPS 一般能实现数米级别的定位精度，这对于我们开发的无障碍导航系统来说基本能满足需求。
然而，在校园内高楼密集的区域，像教学楼林立的地方，GPS 信号可能会受到遮挡和反射的影响，导致定位误差增大。为了应对这种情况，我们可以利用手机的加速度计和陀螺仪等传感器，采用简单的惯性导航算法进行位置推算。虽然这种推算的精度有限，不能长时间维持高精度定位，但可以在 GPS 信号短暂丢失时，保证定位的连续性，让系统能持续为用户提供大致的位置信息。
室内定位
对于室内定位，考虑到成本和实现难度，我们采用 Wi - Fi 定位作为主要手段。在校园的教学楼、图书馆等场所，利用已有的 Wi - Fi 信号进行区域粗定位。通过收集校园内各个位置的 Wi - Fi 信号强度数据，建立简单的数据库，当用户进入室内时，系统根据接收到的 Wi - Fi 信号特征，在数据库中匹配大致位置。
对于一些关键区域，如无障碍电梯口、卫生间等，我们可以在这些地方安装低成本的蓝牙信标，使用蓝牙定位技术进行精确定位。通过这种多技术融合的方式，争取实现室内定位精度在 5 米左右，帮助残障人士在室内能较为准确地找到目的地。
响应速度
路径规划响应
当用户输入目的地后，我们采用经典的 Dijkstra 算法进行路径规划。虽然它不是最高效的算法，但对于校园内的小范围路径规划，能在普通智能手机上较快地完成计算。在校园内常见的出行距离（如从宿舍到教学楼，一般在 1 - 2 公里），系统应能在 3 - 5 秒内完成路径规划并展示给用户。
由于校园内的交通状况相对简单，没有复杂的道路限行和实时交通拥堵情况，我们暂不考虑实时交通信息的处理。不过，在后续的开发中，如果有条件可以收集校园内的施工信息等动态情况，当遇到此类情况时，系统能在 10 - 15 秒内重新规划路径。
实时导航响应
在导航过程中，系统会实时获取手机的位置信息。我们通过优化传感器数据的采集频率和处理逻辑，结合简单的地图渲染算法，确保当用户位置发生移动后，地图显示和语音提示能在 1 - 2 秒内做出响应。这样可以让残障人士及时根据导航指引调整行动。
兼容性
设备兼容性
我们开发的无障碍导航系统主要针对常见的智能手机。在开发过程中，我们会考虑不同品牌和型号的安卓手机以及 iOS 手机。对于屏幕尺寸和分辨率的差异，我们采用响应式设计，让界面能自适应不同的屏幕。
对于不同版本的操作系统，我们会在主流的安卓和 iOS 版本上进行测试，确保系统能正常运行。在低配置的手机上，我们会采用轻量化的算法和数据存储方式，比如减少地图数据的缓存量，只保留当前区域和常用区域的地图信息，以保证系统在各种设备上都能流畅运行。
辅助设备兼容性
对于视障人士常用的屏幕阅读器，我们会遵循基本的无障碍访问标准，对系统界面元素进行合理的标签设置，确保屏幕阅读器能准确读取导航提示、目的地信息等内容。
对于盲人手表、智能拐杖等可穿戴辅助设备，我们可以通过蓝牙通信技术，将导航信息（如前方有障碍物、到达目的地等）传递给这些设备，实现震动、语音等多模态提示。不过，考虑到开发难度，我们先从简单的信息传递开始，后续再逐步完善功能。
可靠性
数据可靠性
导航数据主要包括校园地图数据和一些基本的兴趣点（POI）数据。校园地图数据我们可以通过实地测量和学校提供的建筑图纸来绘制，确保道路、建筑等信息准确无误。这些数据可以定期更新，比如每学期更新一次校园内的建筑变化信息。
对于兴趣点数据，如无障碍设施的位置等，我们可以通过人工收集和整理，每学期进行一次检查和更新。由于校园内的数据相对稳定，我们不需要复杂的数据备份和冗余存储技术，只需要定期将数据备份到本地硬盘或云盘即可。
系统稳定性
为了保证系统的稳定性，我们会进行功能测试，确保系统的各项功能正常运行。由于我们的系统主要面向校园内的用户，用户数量相对较少，暂不涉及高并发用户访问的压力测试。
在部署服务器时，我们可以选择一些免费的云服务器平台，如腾讯云的轻量应用服务器（学生版），利用其提供的基本负载均衡功能，合理分配用户请求，确保系统在校园内的正常使用。同时，在开发过程中，我们会及时修复发现的问题，提升系统的稳定性和用户信任度。