1 前言
体育馆作为提供体育活动设施的重要场所，其使用和管理效率对于满足公众需求、提高体育活动质量具有重要意义。然而，传统体育馆场地预约方式仍然存在流程繁琐、效率低下等问题，已无法满足现代社会的需求。旨在提高体育馆的预约和管理效率，为用户提供更加便捷、高效的体育活动服务。本章将给出项目目标、背景等项目初始内容，分析任务可行性，制定项目招投标计划。
1.1项目目标
本项目的目标是实现以下目标：
1. 提供用户便捷的预约体验：用户可以通过系统随时随地进行体育馆预约，无需人工操作，大大简化了预约流程，使得预约过程更加便捷。
2. 提高体育馆管理效率：系统能够实现自动化管理，减少人工干预，从而提高管理效率，降低运营成本。
3. 优化体育馆资源利用：通过系统的数据分析功能，可以实现体育馆资源的合理分配和利用，减少资源浪费，提高利用率。
4. 增加用户粘性：通过系统提供的个性化推荐等功能，可以增加用户的使用频率和粘性，提高用户满意度。
1.2项目背景
学校的体育馆部分场地预约仍然沿用着纸质申请的方式，这种传统的预约方式不仅效率低下，而且容易出错，无法满足学生日益增长的体育练习需求。特别是到了期末考试期间，学生们需要更多的场地进行体育练习，以备战考试。学校需要采取更加先进、便捷的预约方式来满足学生的需求。通过开发体育馆场地预约系统来实现这一目标。这样可以避免信息错误和管理效率低下的弊端，提高管理效率和服务质量.
1.3项目可行性分析
1.3.1技术可行性
1. Web开发技术：系统采用JavaWeb技术，使用Servlet和JSP进行动态网页开发。
2. 数据库技术：使用MySQL作为数据库管理系统，存储场地信息、预约记录等数据。
3. 用户界面设计：系统需提供直观、易用的用户界面，方便用户进行场地预约操作。
4. 系统安全性：系统应保证数据的安全性，防止未经授权的访问和数据泄露。
1.3.2经济可行性
1. 目标市场：该项目主要面向学校的学生、教职工及校友，提供体育馆场地预约服务。考虑到学校内体育活动的需求稳定且持续，预计市场规模较大。
2. 竞争情况：目前市场上已有部分体育馆场地预约系统，但大多数学校仍采用传统的现场预约方式。因此，开发面向学校的体育馆场地预约系统具有一定的竞争优势。
2 需求分析
本章将进行需求建模，完成所选项目的任务分解结构，给出项目需求说明，说明项目的范围确定因素。
2.1 功能性需求
2.1.1 总体描述
本系统系统使用角色分为体育馆场地管理员和用户两种：
用户有以下功能：
1. 用户注册登录模块：用户注册并登录系统，系统验证用户信息。
2. 查看场地信息模块：展示体育馆的场地信息，包括场地名称、位置、可用时间段等。
3. 场地预约模块：用户可以根据自己的需求预约场地，系统根据场地可用性进行判断，如果场地可用，则预约成功并生成预约记录。
4. 预约记录查询模块：用户可以查询自己的预约记录，包括预约时间、场地信息等。
5.取消预约模块：对已预约的场地进行取消预约。
体育馆场地管理员有以下功能：
1.管理员登录模块：管理员登录系统。
2.用户管理模块：管理员可以管理用户信息。
3.场地管理模块：对体育馆场地进行增删查改功能。
4.预约管理模块：对用户的预约进行管理。
2.1.2用户需求
本系统的用户会有教职工、学生、体育馆管理员、校外人员等，用户数量大。
学生和教职工因为需要上课，时间不太灵活，因此需要简洁、快速、方便的系统，系统界面的易读性要强。
校外人员对学校可能不太了解，因此体育馆场地位置、开放时间、大小等信息需要有完善的描述，便于校外人员的到来与使用。
体育馆管理员对体育馆最为熟悉，在实际的使用过程中可能有特殊情况预约，因此，系统需要有灵活性、可调整。
2.1.3范围和边界
（一）范围
用户范围：该系统主要面向学校的学生和教职工，以及其他需要使用体育馆场地的人员。学生和教师可以通过各自的校园卡或教工卡进行身份认证，其他校内人员则需要通过管理员手动添加账号和密码进行认证。
场地范围：该系统可以管理学校的多个体育馆场地，包括室内和室外场地。每个场地都有其相应的信息，如名称、面积、设施、可预约时间等。用户可以在系统中查看各个场地的信息，并选择自己需要的场地进行预约。
时间范围：该系统可以管理不同时间段内的场地预约，包括日间和夜间。每个场地都有其相应的开放时间和可使用时间，用户可以在系统中查看各个时间段的信息，并选择自己需要的时间段进行预约。
（二）边界
该系统主要针对体育馆场地的预约和管理，不涉及其他业务领域。同时，该系统也需要与其他校内系统进行对接，如学生管理系统和教师管理系统等，以实现用户信息的共享和同步。
2.1.4组织图
系统组织分为三大模块，对应用户不同阶段的功能。
图1 组织图
在体育馆场地预约系统的业务流中，主要涉及以下几个方面：
1. 用户注册与登录：用户首先需要注册账户并登录系统，才能使用预约功能。
2. 场地查询与选择：用户可以在系统中查询可用的体育馆场地，并根据需求选择合适的场地。
3. 预约提交与支付：选择场地后，用户需要提交预约申请，并完成支付。
4. 状态查询与取消：用户可以查询预约状态，并在需要的情况下取消预约。
5. 场地使用与评价：预约成功后，用户可以在指定时间使用体育馆场地，并在使用后对场地进行评价。
图2 业务流程图
在本系统中，主要有三个方面的数据流：
1. 登录模块的数据流：用户输入用户名和密码，系统验证用户信息，如果验证通过，则返回登录成功的信息，否则返回错误信息。
2. 预约模块的数据流：用户选择预约的场地和时间，系统检查场地是否可用，如果可用，则接受预约，并返回预约成功的信息，否则返回错误信息。
3. 场地管理模块的数据流：管理员可以添加、修改和删除场地信息，同时可以查看场地的预约情况。
图5 第2层数据流图
- 用户表
| 名称 | 类型 | 说明 |
| user_id | CHAR(10) | 账号，主键 |
| username | VARCHAR(50) | 昵称 |
| password | CHAR(10) | 密码，加密存储 |
| phone_number | CHAR(11) | 联系电话 |
| 名称 | 类型 | 说明 |
| court_id | CHAR(10) | 场地编号，主键 |
| court_type | VARCHAR(50) | 场地类型（篮球场、羽毛球馆等） |
| court_status | VARCHAR(50) | 场地状态（可用、预约中等） |
| court_price | INT | 价格 |
- 场地表
- 预约表（订单）
| 名称 | 类型 | 说明 |
| reservation_id | CHAR(10) | 预约订单号，主键 |
| user_id | INT | 账号，外键关联用户表 |
| court_id | INT | 场地编号，外键关联场地表 |
| start_time | TIME | 预约开始时间 |
| end_time | TIME | 预约结束时间 |
- 预约记录
| 名称 | 类型 | 说明 |
| reservation_date | DATE | 预约时间，主键 |
| user_id | INT | 账号，外键关联用户表 |
| court_id | INT | 场地编号，外键关联场地表 |
- 体育馆场地管理员
| 名称 | 类型 | 说明 |
| root_id | CHAR(10) | 工号，主键 |
| root_name | VARCHAR(50) | 姓名 |
| root_password | CHAR(10) | 管理员密码，加密存储 |
（一）实体属性
- 体育馆场地管理员
管理员有三个属性：工号、密码、姓名。工号作为主码，确定是哪一位管理员，工号和密码用于管理员登录操作，姓名为管理员基本信息。
图6 场地管理员实体属性图
- 用户
用户实体有四个属性：账号、用户密码、昵称、电话。账号作为主码，不可重复，用于确定用户，账号与密码用于该用户的登录操作、电话用于管理员与预定用户及时联系，昵称为用户基本信息。
图7 用户实体属性图
- 场地
场地有四个属性：编号、类型、状态、预约价格。编号作为主码，类型、状态方便用户查找自己需要的书，当用户预定场地后，被预定时间的场地状态将改变为不可预定，预约价格为场地的基本信息。
图8 场地实体属性图
- 订单
订单有五个属性：订单号、账号、编号、预约开始时间、预约结束时间。
图9 订单实体属性图
（二）E-R图
经分析，以上属性有三种联系：
图10 体育馆场地预约系统E-R图
（三）关系模型
将E-R图中4个实体和联系转换为以下关系模型，该关系模型由5个关系模式组成：
场地：（编号，类型，状态，预约价格）
体育馆场地管理员：（工号，姓名，密码）
用户：（账号，昵称，电话，用户密码）
订单：（订单号，账号，编号，预约开始时间、预约结束时间）
预约：（账号，编号，时间）
2.2 非功能性需求
体育馆场地预约系统的性能需求包括以下几个方面：
1. 预约灵活性：系统应该能够支持不同种类的场地预约，包括按小时、按天、按周等不同时间单位的预约，同时应该支持长期预约和短期预约。
2. 场地管理：系统应该能够对场地进行详细的管理，包括场地的使用状态、设施信息、位置信息等。
3. 用户管理：系统应该能够对用户进行详细的管理，包括用户信息、用户权限、用户预约记录等。
4. 预约提醒：系统应该能够在预约时间前对用户进行提醒，以避免用户错过预约时间。
5. 数据分析：系统应该能够对预约数据进行详细的分析，包括使用频率、使用时间、用户行为等，以帮助体育馆更好地管理场地和改进服务。
6. 安全性：系统应该具备必要的安全性，包括数据加密、用户验证、权限控制等，以确保系统的稳定性和用户信息的安全性。
7. 可扩展性：系统应该能够支持未来的扩展和升级，包括添加新的场地、新的功能、新的用户类型等。
8. 易用性：系统应该具备易于使用的特点，包括界面设计、操作流程等，以方便用户使用。
9. 响应速度：系统应该具备快速的响应速度，不超过5秒，以避免用户等待时间过长。
体育馆场地预约系统的外部接口需求主要包括以下几部分：
1. 用户接口：需要提供简单、直观、易用的界面，方便用户查看场地可用性、预定场地、支付费用等操作。同时，应该提供多渠道的接口，如手机APP、微信小程序、网页端等，以满足不同用户的需求。
2. 场地接口：需要提供准确的场地信息，包括场地类型、大小、设施、可用时间等，以便用户能够根据需求选择合适的场地。同时，应该提供场地预订状态通知接口，及时向用户发送预订结果通知。
3. 支付接口：需要与第三方支付平台合作，提供安全、便捷的支付方式，如支付宝、微信支付等。同时，应该提供支付状态通知接口，及时向用户发送支付结果通知。
1. 用户信息：用户需要登记个人信息，包括姓名、联系方式等，以便记录预订信息和后续沟通。
2. 日期和时间：用户需要选择预订的日期和时间，但预订时间必须在体育馆的开放时间范围内。
3. 场地类型：体育馆内提供多种不同类型的场地，如篮球场、羽毛球场、游泳池等，用户需要根据自己的运动项目选择合适的场地类型。
4. 场地预定：不能在同一段时间内预定多个场地。
5. 费用支付：用户需要支付预订场地的费用，费用金额根据场地类型、日期和时间等因素确定。
6. 特殊情况：对于一些特殊情况，如天气恶劣、场地维修等，限制用户的预订或调整场地的使用。
3 系统设计
基于UML，完成需求建模。
3.1 架构设计
本系统使用MySQL作为数据库，Java Web作为后端框架，Tomcat作为Web服务器，以及SELVER作为代理服务器。
3.2详细设计
3.2.1用例图
系统用例图描述了整个体育馆场地预约系统的宏观架构和各类用户以及各个功能模块之间的关系。
图11 系统用例图
场地用例图描述了与场地相关的功能和用户之间的关系。
图12 场地用例图
预约用例图描述了用户预约场地的流程和管理员管理预约订单的相关功能。
图13 预约用例图
个人信息管理用例图描述了用户个人信息的维护和管理的功能。
图14 个人信息管理用例图
（一）用户预约场地时序图
1. 用户登录系统
2. 查看场地
3. 系统从数据库中调用场地信息并显示给用户
4. 用户选择预约场地
5. 系统验证场地是否可用
6. 如果可用，系统接受预约，并保存相关信息
7. 系统更新场地状态为已预约
8. 系统发送预约订单给用户
9. 用户确认预约信息
图15 用户预约场地时序图
（二）场地管理员管理场地信息时序图
1. 管理员登录系统
2. 进入主界面
3. 查看所有场地信息
4. 系统请求信息并返回给管理员
5. 选择管理场地
6. 系统更新场地信息并保存
7. 管理员可以查看更新后的场地状态
8. 管理员可以删除或修改已预约的场地信息
9. 系统会发送更新后的页面给管理员和用户
图16 场地管理员管理场地信息时序图
本小结将3.2.2的两个时序图转换为协作图：
图17 场地预约协作图
图18 场地管理员管理场地信息协作图
在本系统中用活动图表示预约过程：
- 用户进入体育馆预约系统
2. 用户选择预约功能。
3. 用户选择预约的场地（时间）。
4. 如果场地可被预约，则用户选择支付方式，否则重新选择预约场地。
5. 系统生成预约订单并收款。
6. 管理员更改场地状态信息。
7. 用户可以在预约的时间内前往体育馆。
图19 用户预约体育馆场地活动图
本章根据WBS确定每个工作包所需任务或活动，尽可能详尽，以表格的形式给出。确定任务以及任务之间的逻辑关系，给出相应的PDM，完成项目规模估算、历时估算、成本估算。找出关键路径并求出关键路径长度。给出项目网络图，并用正推法和逆推法给出各个任务的最早开始时间、最早完成时间、最晚开始时间和最晚完成时间。编排进度计划，给出甘特图。
WBS工作分解结构明确项目目标、提高项目透明度、优化资源分配、便于监控和控制。
图20 WBS工作分解结构图
PDM促进项目设计和开发过程，优化产品生命周期管理。为了更好的分析项目的规模、成本以及历时。
图21 项目网络图
4.3.1进度计划表
表1 进度计划表
| 任务名称 | 工期 | 开始时间 | 完成时间 | 前置任务 |
| 项目规划 | 3 个工作日 | 2023年12月12日 | 2023年12月14日 | |
| 组件项目团队 | 7 个工作日 | 2023年12月15日 | 2023年12月25日 | 1 |
| 制定项目预算 | 3 个工作日 | 2023年12月15日 | 2023年12月19日 | 1 |
| 可行性分析 | 2 个工作日 | 2023年12月26日 | 2023年12月27日 | 2 |
| 技术可行性分析 | 2 个工作日 | 2023年12月28日 | 2023年12月29日 | 4 |
| 经济可行性分析 | 2 个工作日 | 2023年12月28日 | 2023年12月29日 | 4 |
| 操作可行性分析 | 2 个工作日 | 2023年12月28日 | 2023年12月29日 | 4 |
| 法律可行性分析 | 2 个工作日 | 2023年12月28日 | 2023年12月29日 | 4 |
| 社会可行性分析 | 2 个工作日 | 2023年12月28日 | 2023年12月29日 | 4 |
| 用户需求获取 | 5 个工作日 | 2024年01月01日 | 2024年01月05日 | 5,6,7,8,9 |
| 用户需求分析 | 3 个工作日 | 2024年01月08日 | 2024年01月10日 | 10 |
| 系统功能性分析 | 2 个工作日 | 2024年01月11日 | 2024年01月12日 | 11 |
| 系统非功能性分析 | 1 个工作日 | 2024年01月11日 | 2024年01月11日 | 11 |
| 需求确认 | 1 个工作日 | 2024年01月15日 | 2024年01月15日 | 12,13 |
| 项目计划评审 | 2 个工作日 | 2024年01月16日 | 2024年01月17日 | 14 |
| 体系结构设计 | 2 个工作日 | 2024年01月18日 | 2024年01月19日 | 15 |
| 技术选择 | 1 个工作日 | 2024年01月22日 | 2024年01月22日 | 16 |
| 模块设计 | 2 个工作日 | 2024年01月23日 | 2024年01月24日 | 17 |
| 实体联系设计 | 2 个工作日 | 2024年01月25日 | 2024年01月26日 | 18 |
| 数据库设计 | 1 个工作日 | 2024年01月29日 | 2024年01月29日 | 19 |
| 界面设计 | 3 个工作日 | 2024年01月23日 | 2024年01月25日 | 17 |
| 层次结构设计 | 2 个工作日 | 2024年01月22日 | 2024年01月23日 | 16 |
| 场地管理模块设计 | 3 个工作日 | 2024年01月24日 | 2024年01月26日 | 22 |
| 用户管理模块设计 | 1 个工作日 | 2024年01月24日 | 2024年01月24日 | 22 |
| 预约子模块设计 | 3 个工作日 | 2024年01月24日 | 2024年01月26日 | 22 |
| 硬件设计 | 5 个工作日 | 2024年01月22日 | 2024年01月26日 | 16 |
| 可维护性设计 | 1 个工作日 | 2024年01月30日 | 2024年01月30日 | 20,21,22,23,24,25,26 |
| 测试计划 | 3 个工作日 | 2024年01月31日 | 2024年02月02日 | 27 |
| 编码 | 7 个工作日 | 2024年01月31日 | 2024年02月08日 | 27 |
| 单元测试 | 2 个工作日 | 2024年02月09日 | 2024年02月12日 | 29,28 |
| 集成测试 | 1 个工作日 | 2024年02月13日 | 2024年02月13日 | 30 |
| 系统测试 | 3 个工作日 | 2024年02月14日 | 2024年02月16日 | 31 |
| 部署 | 2 个工作日 | 2024年02月19日 | 2024年02月20日 | 32 |
| 维护 | 3 个工作日 | 2024年02月21日 | 2024年02月23日 | 33 |
| 撰写用户手册 | 3 个工作日 | 2024年02月19日 | 2024年02月21日 | 32 |
4.3.2甘特图
甘特图通过条状图形来显示任务项之间的关系及其在时间上的前后顺序。
图22 体育馆场地预约系统甘特图
关键路径是指直接影响项目完成日期的一系列任务，这些任务被称为关键活动，如果其中任何一个活动被延迟，整个项目就会被延迟。根据细化的网络图算出每个项目最早开始时间、最晚开始时间、最早结束时间、最晚结束时间，找出浮动为0的项目得到关键路径。
图23 项目网络图细化
由上图可知，项目的关键路径是： A->B->D->E->J->K->L->N->O->P->Q->R->S->T->A'->C'->D'->E'->F'->G'->H'
4.5项目规模估算
1. 场地预订系统：包括场地预订、预订状态查询、预订提醒等功能。根据校园内体育馆场地的数量和使用情况，预计需要开发10个左右的预订功能点。
2. 用户管理系统：包括用户注册、登录、信息修改等功能。根据校园用户数量和使用频率，预计需要开发10个左右的用户管理功能点。
4.6项目成本估算
1. 人力成本：开发人员3名，测试人员2名，项目管理人员1名，共计6人。以每人年薪10万元计算，总人力成本为60万元。
2. 系统硬件成本：包括服务器、网络设备、传感器等设备费用，预计为20万元。
3. 软件成本：包括系统开发、测试、部署等费用，预计为30万元。
4. 其他成本：包括培训、维护、升级等费用，预计为10万元。
总成本 = 人力成本 + 系统硬件成本 + 软件成本 + 其他成本 = 60 + 20 + 30 + 10 = 120万元。
4.7项目历时估算
根据项目规模和复杂度，预计项目开发周期为55个工作日，具体分为以下阶段：
- 总体项目规划阶段：11个工作日：主要规划项目、组件团队、进行项目预算。
- 可行性分析阶段：4个工作日：主要对项目的各种可行性进行分析。
3. 需求分析阶段：13个工作日，主要对项目需求进行获取、详细分析和梳理。
4. 系统设计阶段：9个工作日，根据需求分析结果，进行系统架构和功能设计。
5. 系统开发阶段：7个工作日，根据设计文档进行代码编写和测试。
6. 系统测试阶段：6个工作日，对开发完成的系统进行全面测试，确保系统稳定性和可靠性。
7. 系统部署维护阶段：5个工作日，将系统进行宣传部署、维护并撰写用户手册。
本章给出此项目的质量目标及质量计划标准。
1.结合软件项目的开发过程，确保交付的软件项目能够满足客户对于项目的具体需求。
2.开发过程中必须保证代码质量，每一个功能模块分配给不同的开发人员进行开发，并且在开发一个阶段过后相互间进行代码审查。
3.开发进行到一定阶段后，引入测试流程，分模块分阶段进行详细的测试，保证软件按照需求进行运行。
4.在开发结束的时候需要对用户的安全，用户访问量的峰值以及数据库的使用做大量的测试。
5.软件项目的开发过程中，要对软件项目进行阶段性评审、验收以及日常检查，确保软件项目的质量。
表2 体现了质量活动的进度计划
| 任务 | 质量活动 | 进度计划 |
| 项目准备 | 项目规划 | 3 个工作日 |
| 组件项目团队 | 7 个工作日 | |
| 可行性分析 | 可行性分析 | 2 个工作日 |
| 技术可行性分析 | 2 个工作日 | |
| 经济可行性分析 | 2 个工作日 | |
| 操作可行性分析 | 2 个工作日 | |
| 法律可行性分析 | 2 个工作日 | |
| 社会可行性分析 | 2 个工作日 | |
| 需求分析 | 用户需求获取 | 5 个工作日 |
| 用户需求分析 | 3 个工作日 | |
| 系统功能性分析 | 2 个工作日 | |
| 需求确认 | 1 个工作日 | |
| 项目计划评审 | 2 个工作日 | |
| 概要设计 | 体系结构设计 | 2 个工作日 |
| 技术选择 | 1 个工作日 | |
| 模块设计 | 2 个工作日 | |
| 实体联系设计 | 2 个工作日 | |
| 数据库设计 | 1 个工作日 | |
| 详细设计 | 层次结构设计 | 2 个工作日 |
| 场地管理模块设计 | 3 个工作日 | |
| 用户管理模块设计 | 1 个工作日 | |
| 预约子模块设计 | 3 个工作日 | |
| 编码测试 | 测试计划 | 3 个工作日 |
| 编码 | 7 个工作日 | |
| 单元测试 | 2 个工作日 | |
| 集成测试 | 1 个工作日 | |
| 系统测试 | 3 个工作日 |
本章给出此项目的TOP10风险分析表。
表3 风险分析表
| 排序 | 输入 | 风险事件 | 可能性 | 影响 | 风险值 | 采取的措施 |
| 1 | 项目规划 | 没有足够的时间详细的规划项目 | 50% | 60% | 20% | 在开发过程中，尽量选择已有的开发成果和技术，减少不必要的工作。 |
| 2 | 系统功能排序 | 功能顺序不合理，使用体验不佳 | 30% | 20% | 6% | 进行用户调研，根据用户需求调整功能排序。 |
| 3 | 用户输入 | 用户输入错误信息，导致预约失败 | 40% | 30% | 12% | 增加输入验证，提示用户检查信息准确性。 |
| 4 | 系统性能 | 系统崩溃，无法处理高并发请求 | 25% | 40% | 10% | 优化系统性能，实施负载均衡策略。 |
| 5 | 数据库 | 数据丢失或损坏，无法恢复 | 20% | 35% | 7% | 定期备份数据，实施数据恢复计划。 |
| 6 | 与第三方系统的接口对接 | 接口不兼容，数据传输错误 | 15% | 25% | 4% | 进行接口测试，确保与第三方系统的兼容性。 |
| 7 | 系统安全配置和访问权限 | 系统被攻击，用户数据泄露 | 10% | 45% | 5% | 加强系统安全配置，实施访问控制策略。 |
| 8 | 用户体验 | 界面复杂，操作流程繁琐，用户体验不佳 | 25% | 30% | 7.5% | 优化界面设计，简化操作流程。 |
| 9 | 故障应对策略和预案 | 系统故障无法及时处理，影响用户正常使用 | 15% | 20% | 3% | 制定故障应对策略和预案，进行定期演练。 |
| 10 | 技术更新和升级计划 | 技术更新导致系统不稳定或数据丢失 | 10% | 20% | 2% | 进行技术更新和升级时进行充分测试，确保系统的稳定性和数据安全性。 |
该项目旨在开发一个完善的统一的体育馆场地预约系统，代替传统线下预约，提高场地利用率、 提升用户体验，简化预约流程、确保系统稳定性和安全性。项目包含系统设计、开发、测试、部署方面。通过管理本项目，积累了宝贵的项目管理经验，熟练了画UML图和使用各种分析工具与方法。
扫一扫
4943
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
