软件工程第二次团队作业

航班信息管理系统 - 迭代改进报告

项目地址（Alpha）：https://github.com/OokukiooO/flight_info_management

2.1 问题与修改

在项目的第一阶段完成后，通过自我评估和模拟用户场景，发现了一些潜在的优化点。虽然本项目为独立开发，但仍可借鉴团队作业的思路进行迭代改进：

问题1：用户注册/登录流程可以更便捷
- 当前状态：系统已实现基于用户名和密码的注册和登录功能。
- 潜在修改1：
  - 简化注册流程，考虑仅保留用户名和密码为必填项。
  - 未来可考虑引入第三方授权登录（如微信、GitHub等），进一步提升便捷性。
问题2：航班查询功能可以更强大
- 当前状态：系统支持根据出发地、到达地和航班号进行模糊查询。
- 潜在修改2：
  - 优化模糊搜索算法，提高准确性。
  - 未来可增加按日期范围、航空公司等更多维度进行筛选。
问题3：订单信息展示较为基础
- 当前状态：订单管理页面展示乘客姓名、证件号、座位号和航班ID。
- 潜在修改3：
  - 考虑在订单列表中加入更详细的航班信息（如起降时间），或提供快速链接到航班详情。
  - 若系统扩展，可增加订单状态（如已支付、已出行、已取消）的展示和管理。
问题4：系统界面和交互可以持续优化
- 当前状态：系统使用Ant Design组件库，保证了基础的UI质量和一致性。各管理页面布局清晰。
- 潜在修改4：
  - 在数据量大的表格中增加前端分页或服务端分页，提升加载速度和用户体验。
  - 对表单校验提示信息进行优化，使其更友好。
问题5：目前缺乏用户反馈机制
- 当前状态：系统未包含用户反馈功能。
- 潜在修改5：
  - 未来可以考虑增加一个简单的用户反馈渠道，例如一个反馈表单，允许用户提交使用意见和建议。

2.2 用户调查与原型改进

由于是个人项目，此阶段主要通过自我扮演不同角色用户（管理员、普通旅客）进行模拟使用和反思。

用户调查过程 (模拟)
- 目标用户 (模拟)：
  - 管理员小张：需要频繁进行航班信息的添加、修改、删除操作，关注操作效率和数据准确性。
  - 旅客小王：偶尔查询航班信息，希望查询过程简单快捷，信息展示清晰。
- 调查方式 (模拟)：自我体验、功能走查、与朋友交流获取初步反馈。
- 调查场景 (模拟)：
  - 场景1：管理员小张需要紧急添加一条新的航班信息，并修改一条已有航班的起飞时间。
  - 场景2：旅客小王计划出行，需要查询从A地到B地的所有航班。
  - 场景3：管理员小张需要查看当前系统的用户、航班和订单总量。
用户反馈与改进 (模拟与自我反思)
- 用户痛点 (反思)：
  - 对于管理员，批量操作航班（如批量导入）可能会有需求，目前仅支持单条操作。
  - 航班查询结果的排序和进一步筛选功能可以增强。
  - 订单管理的编辑和删除功能缺失。
- 改进措施 (思考)：
  - 优化航班管理：未来可以考虑增加批量导入/导出航班数据的功能。航班修改操作后可以给出更明显的成功提示，并自动刷新列表。
  - 增强航班查询：增加按时间、价格（若有）等排序功能，提供更多筛选条件。
  - 完善订单管理：考虑增加订单修改（如修改旅客信息）和删除（取消订单）的功能，并进行相应权限控制。

(注：由于是个人项目，此部分用户调查和原型改进偏向于自我评估和未来规划。)

2.3 需求规格说明书改进

基于以上反思，对原有的隐性需求规格进行梳理和明确化：

原需求规格说明书不足 (自我审视)
- 功能考虑不全：初期主要关注核心CRUD，对用户体验细节、管理后台的统计细化等方面考虑不足。
- 描述不清晰：部分API接口参数和返回值的具体格式在初期设计时可能仅有大致构想。
- 用户场景缺失：虽然有基本的用户角色区分，但具体操作路径和异常处理场景未完全文档化。
改进后的需求规格说明书 (部分示例)
- 用户注册与登录
  - 功能描述：支持用户名和密码注册。登录成功后，应有明确的会话保持机制（当前通过客户端路由跳转模拟）。
  - 用户故事：管理员输入正确的用户名和密码后，系统验证通过，跳转到数据看板页面。
- 航班信息模糊查询
  - 功能描述：用户可以在航班查询页面，通过输入出发地、到达地或航班号的关键字进行模糊搜索。后端API应能正确处理这些参数并返回匹配的航班列表。
  - 用户故事：旅客小王在出发地输入“北京”，系统应返回所有从北京出发的航班信息。
- 航班信息管理 (增删改)
  - 功能描述：管理员应能添加新的航班信息（航班号、起降地、时间等）。能够修改已有航班的信息。能够删除指定的航班信息，并有确认提示。
  - 用户故事：管理员小张发现某航班时间录入错误，通过航班管理页面找到该航班，点击修改，更新时间后保存成功。

2.4 功能分析象限

基于当前已实现的功能和未来可能的扩展方向，进行功能分析：

象限	功能描述	优先级
重要且紧急	用户注册与登录、航班查询、航班管理（增删改查）、订单查看、数据看板	高 (已基本实现)
重要但不紧急	用户反馈功能、更细致的权限管理、航班数据批量导入导出、高级筛选与排序	中 (部分可作为下一阶段优化)
不重要但紧急	UI细节微调（如特定场景下的加载状态、空状态显示优化）、部分表单校验规则增强	中 (可在测试阶段根据反馈调整)
不重要且不紧急	复杂数据分析与报表（如旅客出行趋势）、第三方登录集成、消息推送（如航班变动）	低 (远期规划，当前系统核心功能不依赖)

2.5 任务分解WBS及项目进度计划调整

由于是个人项目，WBS主要体现为模块开发顺序和时间预估。基于上一份报告的时间计划，若要加入部分上述“问题与修改”中提到的内容（如初步的UI优化和后端逻辑调整），进度可能需要微调。

原任务分解WBS (参考上一报告)
(此处略，参考上一份报告的表格)

调整后的任务分解WBS (若考虑迭代)
假设在原有基础上，增加一些UI优化和后端逻辑健壮性调整：

任务阶段	开始时间	结束时间	负责人	调整说明
需求分析与系统设计	2025-04-01	2025-04-07	OokukiooO	(不变)
UI设计 (Adobe XD)	2025-04-08	2025-04-12	OokukiooO	(不变)
数据库开发与调试	2025-04-10	2025-04-15	OokukiooO	(不变)
后端开发	2025-04-13	2025-04-29	OokukiooO	增加API接口参数校验、错误处理优化 (+2天)
前端开发	2025-04-20	2025-05-12	OokukiooO	增加表单反馈优化、部分页面交互细节调整 (+2天)
测试与优化	2025-05-13	2025-05-20	OokukiooO	针对调整的功能点增加测试时间 (+2天)
文档编写与总结	2025-05-21	2025-05-24	OokukiooO	(不变)
部署与维护	2025-05-25	持续	OokukiooO	(不变)

调整原因：
- 前端开发：针对发现的UI体验问题进行优化，如表单提示、加载效果等，需要额外时间。
- 后端开发：为提高系统健壮性，对API的输入验证和错误返回机制进行完善。
- 测试：新增的优化点需要额外的测试时间来确保修改的正确性和未引入新问题。

3.1 系统架构设计

本航班信息管理系统采用前后端分离的架构，均基于Next.js框架开发。

表示层（前端）
- 职责：负责用户界面的展示、用户交互的处理以及向后端API发送请求。
- 技术栈：
  - Next.js (App Router): 构建页面和组件，处理客户端路由。
  - React: UI库。
  - Ant Design: UI组件库，用于快速搭建专业美观的界面。
  - TypeScript: 提供静态类型检查。
  - Tailwind CSS: 原子化CSS框架，用于自定义样式。
- 主要功能模块对应页面：
  - 用户注册与登录 (/regist, /login)
  - 数据看板 (/dashboard)
  - 航班查询 (/flightSearching)
  - 航班管理 (列表展示、跳转添加/修改) (/flightManage)
  - 添加航班 (/flightAdd)
  - 修改航班 (/flightEdit)
  - 订单管理 (/orderManage)
页面效果展示
登陆页面
注册页面
数据看板
演示GIF浏览
业务逻辑层（后端 API）
- 职责：处理前端请求，执行业务逻辑（如用户认证、数据校验、数据库操作等），并返回响应数据。
- 技术栈：
  - Next.js (API Routes): 快速构建RESTful API。
  - TypeScript: 保证后端代码的类型安全。
- 主要功能API：
  - 用户认证与授权 (/api/user/register, /api/user/login, /api/user/logout, /api/user/info)
  - 航班信息管理 (/api/flight/add, /api/flight/delete, /api/flight/search, /api/flight/update)
  - 订单信息管理 (/api/order/create, /api/order/list)
  - 数据看板统计 (/api/dashboard/stats)
数据访问层（数据库）
- 职责：负责数据的持久化存储和管理。
- 技术栈：
  - SQLite: 轻量级文件数据库。
  - better-sqlite3: Node.js操作SQLite的库。
- 主要数据表：UserInfo, FlightInfo, PassengerInfo。

3.2 数据库设计

根据 src/db/schema.sql 和 src/db/init.ts 文件，数据库表设计如下：

UserInfo 表

字段名	数据类型	描述
id	INTEGER	用户ID (主键,自增)
username	TEXT	用户名 (非空,唯一)
password	TEXT	密码 (非空)
email	TEXT	邮箱 (非空,唯一)
created_at	DATETIME	创建时间 (默认当前时间)

FlightInfo 表

字段名	数据类型	描述
id	INTEGER	航班ID (主键,自增)
flight_number	TEXT	航班号 (非空,唯一)
departure	TEXT	出发地 (非空)
arrival	TEXT	目的地 (非空)
departure_time	DATETIME	出发时间 (非空)
arrival_time	DATETIME	到达时间 (非空)
created_at	DATETIME	创建时间 (默认当前时间)

PassengerInfo 表 (根据 src/db/init.ts 中 PassengerInfo 定义) (注意 src/db/schema.sql 中此表结构有差异，此处以 init.ts 为准，因为它在实际代码中被使用来创建表结构)

字段名	数据类型	描述
id	INTEGER	旅客ID (主键,自增)
name	TEXT	旅客姓名 (非空)
passport_number	TEXT	证件号码 (非空,唯一)
seatNumber	TEXT	座位号
flightId	INTEGER	航班ID (非空)
created_at	DATETIME	创建时间 (默认当前时间)

(注: src/db/schema.sql 中 PassengerInfo 表包含 flight_id 和 user_id 并设有外键，而 src/db/init.ts 中创建的 PassengerInfo 表结构为 name, passport_number, seatNumber, flightId。报告基于 init.ts，因为这是实际执行的建表语句。)

4. Alpha任务分配计划

由于是个人独立开发项目，此部分将模拟Alpha阶段的任务规划。

4.1 迭代计划会议 (自我规划)

目标：
- 确定下一阶段（或一个开发周期，如一周）要实现或优化的核心功能。
- 将这些功能分解为更小的可执行任务。
- 预估每个任务的时间。
流程：
- 回顾项目当前状态和最初设定的目标。
- 根据2.4节的功能分析象限，优先选择“重要且紧急”以及部分“重要但不紧急”中的可快速迭代实现的功能。
- 分析功能间的依赖关系。
- 制定任务列表和大致的时间节点。

4.2 功能项选择与分解 (示例)

假设在Alpha阶段，我选择优先完善核心的航班管理和用户体验。

功能模块优先级 (Alpha阶段选择)

功能模块	优先级	依赖关系
用户注册与登录	高	无 (已基本完成，可优化体验)
航班信息管理 (增删改查)	高	无 (已基本完成，可优化交互和校验)
航班查询	高	无 (已基本完成，可优化筛选)
订单/旅客信息查看	中	航班信息 (已基本完成)
数据看板	中	用户/航班/订单数据 (已基本完成)

任务分解 (Alpha阶段针对性优化任务示例)

功能项	任务描述	预估时间	负责人
用户体验优化 (登录/注册)	优化登录/注册页面的表单校验提示信息和加载状态。	2小时	OokukiooO
航班管理优化	航班添加/修改成功后，自动刷新列表并给出更清晰的提示。	3小时	OokukiooO
	对航班删除操作增加二次确认后的反馈信息。	1小时	OokukiooO
后端API健壮性提升	完善各API接口的参数校验和统一错误处理机制。	4小时	OokukiooO
订单管理页面优化	在订单列表考虑加入航班号信息，或关联查询。	2小时	OokukiooO

4.3 迭代冲刺计划（Alpha阶段）

因为是个人项目，Alpha阶段的冲刺计划更像是一个集中的开发和优化周期。我会按照上述任务分解，集中在一段时间内（例如一周）完成这些优化和完善工作，并进行自测。

5. 测试计划

针对个人项目，测试计划会相对简化，但仍会覆盖关键环节。

5.1 测试目标

确保所有核心功能（用户、航班、订单的CRUD，查询，统计）按预期工作。
保证系统的基本稳定性和数据操作的准确性。
验证UI界面在主流浏览器上的兼容性和响应式布局（虽然本项目UI较为简单）。
确保用户操作流程的顺畅性。

5.2 测试范围

用户管理模块：注册、登录、登出、用户信息获取。
航班信息模块：添加、修改、删除、查询航班。
订单管理模块：创建订单（当前简化）、列表查看订单。
数据看板模块：统计数据展示的准确性。

5.3 测试类型

单元测试 (主要针对后端API逻辑)：对每个API Route的核心逻辑进行测试，确保输入输出符合预期。
集成测试 (API与数据库交互)：测试API与SQLite数据库的交互是否正确，数据读写是否无误。
系统测试 (端到端测试)：模拟用户在前端界面的完整操作流程，例如从登录到查询航班，再到管理航班信息等。
用户验收测试 (自我验收)：以最终用户的视角，对整个系统进行体验和评估。

5.4 测试时间安排

结合项目进度计划调整，测试时间大致安排如下：

测试阶段	开始时间	结束时间	负责人
单元测试 (后端)	2025-04-25	2025-04-29	OokukiooO
集成测试	2025-04-28	2025-05-01	OokukiooO
系统测试 (端到端)	2025-05-02	2025-05-08	OokukiooO
用户验收测试	2025-05-09	2025-05-12	OokukiooO

5.5 测试资源

工具：
- 浏览器开发者工具（用于调试前端和网络请求）。
- Postman或类似API测试工具（用于单独测试后端API接口）。
- SQLite数据库客户端（用于检查数据一致性）。
环境：本地开发环境。
人员：OokukiooO (开发者兼测试者)。

5.6 测试总纲 (部分核心用例)

用户注册与登录功能
- 测试用例：
  - 注册：成功注册新用户；用户名已存在导致注册失败；密码为空导致注册失败。
  - 登录：使用正确的用户名密码成功登录；用户名或密码错误导致登录失败。
- 预期结果：
  - 注册成功后跳转登录页面，失败则显示相应的错误提示。
  - 登录成功后跳转到数据看板页面，失败则显示错误提示。
航班信息管理与查询功能
- 测试用例：
  - 添加航班：所有字段填写完整后成功添加；部分必填字段为空导致添加失败。
  - 查询航班：不输入任何条件查询所有航班；按出发地、到达地、航班号分别或组合查询。
  - 修改航班：成功修改航班信息；尝试修改不存在的航班ID。
  - 删除航班：成功删除指定航班；尝试删除不存在的航班ID。
- 预期结果：
  - 添加/修改/删除操作成功后，前端列表应能正确反映变化，并有成功提示。
  - 查询结果应准确匹配查询条件。
订单管理功能
- 测试用例：
  - (若实现创建订单前端) 测试订单创建功能，所有字段填写正确及部分字段缺失的情况。
  - 查看订单列表，确认数据展示正确。
- 预期结果：
  - 订单创建成功后能在列表中看到，失败则有提示。
  - 订单列表数据与数据库一致。

5.7 测试报告

由于是个人迭代，测试报告将以内部记录的形式存在，主要包含：

测试结果：记录各模块核心功能的测试通过情况。
缺陷记录：描述测试过程中发现的问题、复现步骤、严重程度及修复状态。
测试总结：对当前版本系统稳定性和功能完整性的评估，以及后续可能的改进点。

posted @ 2025-05-22 01:33 terran## 阅读(70) 评论(0) 收藏举报

刷新页面返回顶部

Terran