《软件工程》课件-21可行性分析

2026年3月8日可行性分析大数据技术BIGDATA2026年3月8日章节内容1可行性分析定义2可行性分析分类3成本/效益分析2026年3月8日可行性分析可行性分析定义2026年3月8日可行性分析定义1.1国标GB/T114572006定义可行性：feasibility，对于系统或部件的需求、设计或计划在存在的约束下仍能实现的程度。可行性分析/研究：feasibilityanalysis/study，辨别和分析某一问题及其可能解决方法，以确定其生命力，成本和效益的一种研究。微服务拆分合理性系统鲁棒性API兼容性分布式事务一致性服务依赖管理能力软件领域约束示例数据质量（完整性≥95%）存储能力（TB/PB级）隐私合规数据异构性处理能力数据时效性大数据领域约束示例算力适配（延迟≤500ms）模型可解释性训练数据规模与均衡性模型泛化能力伦理风险人工智能领域约束示例2026年3月8日可行性分析定义1.2校园案例智能教务服务平台微服务拆分合理性系统鲁棒性API兼容性分布式事务一致性服务依赖管理能力软件领域约束示例约束项智能教务服务平台约束示例微服务拆分合理性拆分为“用户模块（登录/权限）+数据模块（接口/格式转换）+AI模块（推荐计算）”，通过Istio服务网格解耦，避免依赖循环分布式事务一致性采用Seata框架保证“学生选课+学分扣减”流程的事务一致性，防止“选课成功但学分未扣”或反向异常服务依赖管理能力微服务间通过明确的API契约调用，如用户模块调用AI推荐时，仅需传递用户ID，无需依赖数据模块全量数据，避免依赖链过长API兼容性用户模块对接学校现有“统一身份认证系统”API，数据模块兼容教务系统（MySQL）与一卡通系统（Oracle）的接口协议系统鲁棒性选课高峰期（访问量从500次→5000次）可自动伸缩（2台→8台服务器），扩容延迟≤5分钟，保障系统稳定2026年3月8日可行性分析定义1.2校园案例智能教务服务平台数据质量（完整性≥95%）存储能力（TB/PB级）隐私合规数据异构性处理能力数据时效性大数据领域约束示例约束项智能教务服务平台约束示例数据质量（完整性≥95%）教务课程数据完整率98%（仅5门旧课程缺失已补录），一卡通消费数据完整率99%（故障缺失数据通过插值法修复）存储能力（TB/PB级）整合后5年数据共6TB，采用校园现有云存储（阿里云OSS校园版）承载，扩容成本约2000元/TB/年隐私合规采用联邦学习框架（FATE），教务与一卡通系统仅交换模型参数，原始数据不共享；学生敏感信息（身份证号、消费明细）脱敏处理，通过学校数据安全委员会审批数据异构性处理能力整合“教务结构化数据（MySQL）+一卡通半结构化数据（JSON）”，开发格式转换模块，实现多源数据统一特征提取数据时效性教务数据每日凌晨自动同步，一卡通数据实时同步（延迟≤10秒），满足AI推荐模型“近30天数据优先”的需求2026年3月8日可行性分析定义1.2校园案例智能教务服务平台算力适配（延迟≤500ms）模型可解释性训练数据规模与均衡性模型泛化能力伦理风险人工智能领域约束示例约束项智能教务服务平台约束示例算力适配（延迟≤500ms）课程推荐模型（LightFM框架）在便携算力设备（DeepXG20，4核CPU+16GB内存）上推理延迟≤300ms，支持5000人同时访问模型可解释性推荐结果可追溯数据血缘（如“Python编程”推荐基于“大一数学成绩85分+前2学期选修计算机基础”），辅导员可通过“数据溯源”功能理解推荐逻辑训练数据规模与均衡性训练集含3万学生样本，“课程类型、成绩区间”等维度均衡性≥0.8，避免因数据失衡导致推荐偏见模型泛化能力模型在“不同年级、不同专业”学生群体中推荐准确率均≥85%，如在“计算机专业”与“经管专业”场景下表现稳定伦理风险推荐模型仅基于“课程成绩、选课历史、专业培养方案”生成，不涉及学生隐私行为（如社交、定位），无性别、年级偏见，符合教育伦理2026年3月8日可行性分析可行性分析分类主要从技术角度确定现有的资源可否满足项目需求，支撑项目顺利进行：软硬件资源、技术水平、管理水平等。开发风险资源风险技术风险主要是对软件开发的成本以及效益进行估算，权衡公司长期经营策略及潜在市场前景等因素，确定项目是否值得开发。竞争实力及投资分析经济效益分析与预测回报法律及道德的可行性、安全因素、对经济政策和市场发展趋势的分析、用户组织的管理模式、业务规范、应用操作可行性及产生的后果与隐患等。是否存在侵权是否合规操作的可行性更侧重于组织管理，在软件项目实施前及及过程中的组织管理程序、方法运用起来是否好用、是否流畅新旧业务差异性分析用户操作便捷性分析2026年3月8日2.可行性分析分类2.1类别

可行性分析/研究目的是用最小的代价在尽可能短的时间内确定问题是否得到解决。因此，可行性研究之后必须下一个结论，即软件项目是否值得开发。主要从技术、经济、社会及操作等方面进行分析。技术可行性经济可行性社会可行性操作可行性2026年3月8日2.可行性分析分类2.2示例智能教务服务平台可行性维度核心关注点可能遇到的跨领域问题达标要求技术可行性1.用工具把系统拆成“用户登录/数据处理/智能推荐”等小功能，方便管理和维护；2.用安全工具保证“选课扣学分”这类操作不出错；3.用数据共享工具整合教务和一卡通数据（不直接传原始数据，更安全）；4.用便携设备跑“推荐课程”的智能功能，保证速度快1.不同小功能之间数据传不动、不匹配；2.智能推荐功能反应太慢，影响使用体验1.管理工具能让各小功能顺畅配合；2.智能推荐反应时间≤0.3秒经济可行性1.开发“用户登录/数据处理”等功能大概花4万元；2.存5年的教务+一卡通数据大概花1.2万元；3.智能推荐功能用现有设备，后续更新每年大概花2万元1.智能功能后续加新需求，花钱超预算；2.数据存储或处理要额外加钱，成本不可控1.用“现有设备+偶尔云服务”的方式，总成本比纯用云服务省2/3；2.3年内能靠节省人工成本赚回2倍投资（比如少雇人统计选课数据）社会可行性1.对接学校现有登录系统，保证师生信息不泄露；2.学生身份证、消费记录等敏感信息要隐藏部分内容；3.智能推荐只看课程、成绩，不看隐私（比如定位），不偏袒某类学生1.系统接口没做好，导致学生隐私泄露；2.智能推荐总给女生推文科课、给男生推理科课，不公平1.登录和数据接口通过安全测评；2.智能推荐的公平性通过检测，不偏袒任何群体操作可行性1.运维老师能学会管理各小功能、处理简单故障；2.师生用的界面和原来的教务系统差不多，不用重新学；3.辅导员能看懂智能推荐的报表（比如“为什么给学生推这门课”）1.运维老师不会修跨功能的故障（比如登录和推荐功能连不上）；2.师生觉得新界面或智能推荐太复杂，不想用1.培训运维老师的费用≤800元/人；2.师生觉得界面“好用、眼熟”的比例≥85%数据可行性1.教务和一卡通的数据格式统一，能一起用；2.数据完整（比如98%的课程信息、99%的消费记录都没丢）；3.智能推荐用的学生数据够多（3万人的样本），覆盖不同专业、成绩的学生1.教务数据是一种格式、一卡通是另一种，没法一起处理；2.智能推荐只用了理工科数据，给文科学生推的课不准1.数据格式符合教育行业通用标准，能顺畅整合；2.智能推荐用的数据覆盖全校95%的专业，不同类型数据占比均衡2026年3月8日可行性分析成本/效益分析2026年3月8日3.成本/效益分析3.1成本估算/效益分析

成本/效益分析目的是从经济角度评价开发一个新的软件项目是否可行。主要有成本估算和效益分析两个方面的内容。基于