团队作业3--需求改进&系统设计

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience/homework/13482
这个作业的目标	完成项目需求迭代优化、系统架构/数据库设计、Alpha阶段任务分配及同步测试计划

第一部分：需求与原型改进

1. 课堂反馈与原型改进
   形式：问题与修改

问题1： 初版需求中对“高峰期并发”的处理描述不够具体，未能体现真实压力场景。

修改1： 在非功能性需求中明确量化指标：系统需支持至少100名员工/顾客同时在线操作，核心操作（点餐、结账）响应时间<2秒。并在系统架构设计中强调使用连接池、异步处理等技术来保障性能。

问题2：顾客点餐和服务员点餐的流程和界面是否有差异？

修改2： 明确区分两种场景。顾客点餐界面侧重于菜品展示、图文并茂和便捷支付；服务员点餐界面则集成桌台管理、快速下单、订单修改和结账等后台功能。将在原型中设计两套不同的UI流程。

用户痛点：

顾客： 排队时间长，菜单更新不及时，呼叫服务员困难。

服务员： 手写菜单易错易丢，桌台状态靠记忆，结账效率低。

2. 需求规格说明书完善
   初稿不足与改进：

不足1：功能考虑不全。 初稿缺少对“促销与会员积分”系统的详细描述。

改进： 新增“营销与会员模块”，包含功能：优惠券管理、会员等级与积分规则设置、积分兑换与流水查询。

不足2：需求描述缺少场景化。 功能列表较为干瘪，未能体现功能如何串联解决用户问题。

改进： 增加用户故事（如上文所述），描述顾客从预订、点餐、支付到评价的完整闭环，以及服务员、厨师、经理在此过程中的协同工作流程。

3. 功能分析与优先级
   根据《构建之法》功能定位四象限法，对功能进行划分：

象限	功能实例	说明
杀手功能	扫码点餐、实时桌台状态	直接提升顾客体验和运营效率的核心差异化功能。
外围功能	菜品评价、会员积分	增强用户粘性，提升服务满意度，但不是必需。
必要需求	下单、结账、库存扣减	没有这些功能，系统就无法运行，是基础保障
辅助需求	员工排班、数据报表导出	改善内部管理，但对核心业务流程影响相对间接

4. 任务分解与进度计划调整
   调整依据： 根据完善后的需求和功能优先级，重新评估WBS。
   关键调整： 将“营销与会员模块”拆分为独立子任务，但其开发优先级置于“核心订单流程”之后。在Alpha阶段，优先保证核心流程（点餐-下单-后厨-结账）的畅通。

第二部分：系统设计

1. 系统架构设计
   本系统采用经典的C/S（客户端/服务器）分层架构，以最大限度地实现需求，并保证清晰的分工和可维护性。
   表现层 (Presentation Layer):
   技术： Qt Widgets / QML
   职责： 提供用户交互界面。根据不同角色（顾客、服务员、厨师、经理）提供定制化的UI，如顾客的点餐界面、服务员的桌台管理界面、经理的数据报表界面。
   业务逻辑层 (Business Logic Layer):
   技术： C++ (Qt Framework)
   职责： 封装所有核心业务规则。例如：
   订单处理（创建、修改、状态流转）
   库存管理（自动扣减、预警逻辑）
   薪资计算（基于绩效的规则）
   数据访问层 (Data Access Layer):
   技术： Qt SQL Module (QSqlDatabase, QSqlQuery)
   职责： 封装所有对OpenGauss数据库的CRUD（增删改查）操作。为业务逻辑层提供统一、简洁的数据访问接口，隔离底层数据库的变化。
   数据层 (Data Layer):
   技术： OpenGauss 9.2.4
   职责： 持久化存储所有业务数据，包括用户、菜品、订单、库存、日志等。
   架构优势：
   高内聚低耦合： 各层职责明确，便于团队并行开发（前端、后端、数据库）。
   可维护性与扩展性： 修改界面或业务规则时，影响范围被限制在特定层次。
   性能： C/S架构在局域网内能提供快速响应，满足餐厅高峰期的性能需求。
2. 数据库设计 (ER图)
   
   核心关系： USER（员工）管理ORDER，ORDER在TABLE上产生，包含多个ORDER_ITEM（菜品项），每个DISH消耗多种INGREDIENT（食材），INVENTORY记录食材库存。
   关键设计：
   DISH_INGREDIENT 表实现了菜品与食材的多对多关系，并记录了每道菜对每种食材的消耗量，这是实现“售出后自动扣减库存”的基础。
   TABLE表的状态（status）字段是实现桌台图形化实时管理的核心。

第三部分：Alpha任务分配计划

1. 迭代目标与功能选取
   迭代周期： Alpha阶段（2周）
   团队总工时： 5人 × 10天 × 6小时/天 = 约300小时
   本迭代目标： 实现餐厅核心营业流程的MVP（最小可行产品），支持完成一次完整的顾客用餐服务。
   选取的Product Backlog项（按优先级排序）：
   用户登录与权限验证
   桌台管理模块（图形化状态展示与预订）
   菜品信息管理（增删改查）
   核心订单流程（点餐、下单、后厨打印、结账）
   基础库存管理（入库、出库记录，并与订单联动扣减）

2. Sprint Backlog任务分解
   使用Leangoo看板进行管理，任务示例如下：
   用户登录模块:

任务描述	负责人	预估工时
设计登录UI界面	黄泽鹏	4
实现后端登录认证API	罗凯夫	6
连接数据库验证用户信息	黄泽鹏	6

桌台管理模块:

任务描述	负责人	预估工时
设计桌台状态管理UI	李易时	4
数据库Table表设计与创建	李易时	6

菜品管理模块：

任务描述	负责人	预估工时
设计菜品管理UI（增删改查）	江家乐	4
实现创建订单、修改订单后端逻辑	李易时	6

3. 迭代计划与目标
   计划会议： 已召开，明确上述Sprint Backlog。

每日站会： 固定时间进行15分钟站会，同步进度、识别风险。

评审会议： 迭代结束时，向导师和同学们演示Alpha版本，展示核心业务流程。

回顾会议： 团队内部总结本迭代在流程、协作、技术上的改进点。

第四部分：测试计划

1. 测试策略
   测试阶段： 与开发同步进行，采用敏捷测试方法。

测试类型：

单元测试： 由开发人员负责，对核心业务逻辑（如订单计算、库存扣减）进行测试。

集成测试： 测试数据库连接、模块接口（如前端与后端、后端与数据库）。

系统测试： 由测试人员（李易时）主导，对完整的核心流程进行端到端测试。

用户验收测试（UAT）： Alpha版本完成后，邀请同学模拟不同角色进行体验测试。

2. 测试范围与责任人

任务描述	测试内容	主要责任人
功能测试	用户登录、桌台状态切换、点餐下单、结账、库存扣减	李易时
性能测试	多用户同时点餐的响应时间与系统稳定性	林烁
UI/UX测试	界面易用性、操作流程是否符合预期	罗凯夫、江家乐
数据一致性测试	订单生成后，库存是否正确扣减	黄泽鹏

3. 资源与时间安排
   测试环境： 与开发环境隔离的测试服务器与数据库。

测试数据： 准备模拟的菜品、桌台、用户数据。

时间安排：

第1周： 伴随开发进行单元测试和模块集成测试。

第2周中： 开始系统测试，并记录Bug。

第2周末： 进行Bug修复验证和回归测试，准备发布Alpha版本。