|
|
|
|
@ -0,0 +1,215 @@
|
|
|
|
|
# 实验一软件项目计划个人报告
|
|
|
|
|
|
|
|
|
|
## 个人基本信息
|
|
|
|
|
- **姓名**：仇新宇
|
|
|
|
|
- **学号**：2023210444
|
|
|
|
|
- **班级**：计科 231
|
|
|
|
|
- **小组**：G12 组
|
|
|
|
|
- **角色**：项目经理
|
|
|
|
|
- **实验日期**：2025-11-03
|
|
|
|
|
- **提交日期**：2025-11-07
|
|
|
|
|
|
|
|
|
|
## 个人任务完成情况
|
|
|
|
|
|
|
|
|
|
### 1. 个人负责的功能模块分析
|
|
|
|
|
作为项目经理，我负责的核心功能模块为 "查询天气及动态展示"，该模块是天气查询应用的核心功能，直接影响用户体验。模块主要包含以下子功能：
|
|
|
|
|
- **城市天气查询功能**：支持用户通过输入城市名称或定位获取目标城市天气
|
|
|
|
|
- **实时天气数据展示**：以动态方式呈现温度、天气状况、湿度、风力等实时数据
|
|
|
|
|
- **预报数据展示**：展示未来 7 天天气预报及小时级降水趋势，支持动态交互
|
|
|
|
|
- **动态效果展示**：包括天气状态动画、数据更新动画、界面切换过渡效果等
|
|
|
|
|
- **个性化动态设置**：允许用户开启/关闭动态效果、切换动态背景模式
|
|
|
|
|
|
|
|
|
|
### 2. EA 模型设计
|
|
|
|
|
|
|
|
|
|
#### 需求图
|
|
|
|
|
- **类型和用途**：需求层次图，用于展示 "查询天气及动态展示" 模块的需求层次结构和各需求间的关系，明确功能边界和优先级。
|
|
|
|
|
- **主要元素和关系**：
|
|
|
|
|
- 核心需求：查询天气并动态展示（顶层需求）
|
|
|
|
|
- 一级子需求：实时数据查询与展示、预报数据查询与展示、动态交互效果、个性化设置
|
|
|
|
|
- 二级子需求：各一级需求的细化（如实时数据包括温度、天气状况等）
|
|
|
|
|
- 关系：采用 "包含" 关系表示需求间的层级结构，用 "依赖" 关系表示需求间的关联
|
|
|
|
|
- **设计思路体现**：通过层次化展示，明确核心功能与辅助功能的关系，突出 "动态展示" 作为差异化特色的设计思路，确保用户体验需求优先于其他次要需求。
|
|
|
|
|
|
|
|
|
|
#### 用例图
|
|
|
|
|
- **类型和用途**：用例图，用于描述模块的参与者与用例之间的关系，明确功能范围和用户交互场景。
|
|
|
|
|
- **主要元素和关系**：
|
|
|
|
|
- 参与者：普通用户
|
|
|
|
|
- 核心用例：查询天气并动态展示
|
|
|
|
|
- 子用例：动态展示实时天气、动态展示预报数据、动态展示扩展信息、触发动态交互效果、设置动态展示偏好
|
|
|
|
|
- 关系：核心用例通过 "包含" 关系关联实时展示和预报展示等必要子用例，通过 "扩展" 关系关联个性化设置等可选功能
|
|
|
|
|
- **设计思路体现**：清晰区分核心功能与可选功能，突出动态展示作为核心体验的设计理念，明确用户与系统的交互边界。
|
|
|
|
|
|
|
|
|
|
#### 甘特图
|
|
|
|
|
- **类型和用途**：项目进度甘特图，用于规划模块开发的时间安排、任务分解和进度控制。
|
|
|
|
|
- **主要元素和关系**：
|
|
|
|
|
- 任务节点：需求分析、原型设计、UI 开发、功能开发、单元测试、集成测试等
|
|
|
|
|
- 时间轴：以天为单位，覆盖整个开发周期（2025-11-05 至 2025-11-25）
|
|
|
|
|
- 依赖关系：展示任务间的先后依赖（如原型设计完成后才能开始 UI 开发）
|
|
|
|
|
- 里程碑：需求确认、功能完成、测试通过三个关键节点
|
|
|
|
|
- **设计思路体现**：采用迭代开发思想，将动态展示功能拆分为基础展示和高级动画两个阶段，优先保证核心功能可用，再逐步增强用户体验。
|
|
|
|
|
|
|
|
|
|
#### 软件过程模型图
|
|
|
|
|
- **类型和用途**：增量模型图，说明模块采用的开发过程和方法。
|
|
|
|
|
- **主要元素和关系**：
|
|
|
|
|
- 阶段：需求分析、设计、开发、测试、部署
|
|
|
|
|
- 增量：分为三个增量（基础查询功能、基本动态展示、高级动态交互）
|
|
|
|
|
- 迭代关系：每个增量均包含完整的开发流程，后一增量基于前一增量迭代
|
|
|
|
|
- **设计思路体现**：通过增量模型实现功能的逐步完善，先确保查询功能的稳定性，再逐步加入动态展示效果，降低开发风险。
|
|
|
|
|
|
|
|
|
|
### 3. 测试用例设计
|
|
|
|
|
|
|
|
|
|
| 测试用例 ID | 测试功能 | 测试目的 | 输入数据 | 预期结果 | 测试步骤 | 优先级 |
|
|
|
|
|
|------------|---------|---------|---------|---------|---------|--------|
|
|
|
|
|
| TC001 | 城市天气查询 | 验证查询功能正确性 | 输入 "北京市" | 正确显示北京当前天气和预报 | 1. 打开应用<br>2. 在搜索框输入 "北京市"<br>3. 点击查询<br>4. 观察显示结果 | 高 |
|
|
|
|
|
| TC002 | 实时天气动态展示 | 验证实时数据动态效果 | 定位至当前城市 | 温度数字平滑滚动，天气图标动态展示 | 1. 打开应用<br>2. 允许定位<br>3. 观察实时天气展示效果 | 高 |
|
|
|
|
|
| TC003 | 预报数据滑动展示 | 验证预报数据动态切换功能 | 左右滑动预报区域 | 平滑切换不同日期的预报数据 | 1. 进入天气详情页<br>2. 在预报区域左右滑动<br>3. 观察切换效果和数据准确性 | 中 |
|
|
|
|
|
| TC004 | 动态效果开关 | 验证动态效果开关功能 | 关闭 "动态效果" 设置 | 所有动态效果消失，界面静态展示 | 1. 进入设置页面<br>2. 关闭 "动态效果" 选项<br>3. 返回首页观察效果 | 中 |
|
|
|
|
|
| TC005 | 异常城市查询 | 验证异常输入处理能力 | 输入不存在的城市名称 "天空市" | 显示友好错误提示，不崩溃 | 1. 在搜索框输入 "天空市"<br>2. 点击查询<br>3. 观察系统反应 | 高 |
|
|
|
|
|
|
|
|
|
|
- **覆盖功能点**：测试用例覆盖了核心查询功能、动态展示效果、用户交互、异常处理等关键功能点
|
|
|
|
|
- **边界条件**：包括无效输入处理、功能开关切换等边界场景
|
|
|
|
|
- **优先级分析**：查询功能正确性和异常处理的优先级最高，确保系统稳定可用；动态效果细节优先级次之，保证核心体验
|
|
|
|
|
|
|
|
|
|
### 4. 个人工作总结与甘特图分析
|
|
|
|
|
|
|
|
|
|
#### 主要工作内容和完成情况
|
|
|
|
|
- 完成 "查询天气及动态展示" 模块的需求分析，明确功能边界和用户场景
|
|
|
|
|
- 使用 EA 工具完成需求图、用例图、甘特图和软件过程模型图的设计
|
|
|
|
|
- 设计了 5 个关键测试用例，覆盖核心功能和边界条件
|
|
|
|
|
- 制定了详细的开发计划，明确了各任务的时间节点和依赖关系
|
|
|
|
|
- 目前所有计划工作均按预期进度完成，需求分析和模型设计已通过小组评审。
|
|
|
|
|
|
|
|
|
|
#### 时间安排和进度控制分析
|
|
|
|
|
根据甘特图安排，模块开发周期为 21 天（2025-11-05 至 2025-11-25），目前处于需求分析和设计阶段（第 1-3 天），进度符合预期。通过设置每日检查点，确保任务按计划推进。
|
|
|
|
|
|
|
|
|
|
#### 遇到的问题和解决方案
|
|
|
|
|
- **问题**：动态展示效果的需求描述不够清晰，团队成员理解不一致
|
|
|
|
|
**解决方案**：组织小组讨论，通过原型草图统一认识，形成书面需求说明
|
|
|
|
|
- **问题**：EA 工具使用不熟练，建模效率低<br>**解决方案**：查阅教程，请教老师，组织小组内工具使用培训
|
|
|
|
|
|
|
|
|
|
#### 收获和体会
|
|
|
|
|
- 项目计划需要充分考虑功能优先级和资源分配，不能贪大求全
|
|
|
|
|
- 建模工具能有效梳理思路，提高团队沟通效率
|
|
|
|
|
- 测试用例设计需要从用户角度出发，考虑各种使用场景
|
|
|
|
|
|
|
|
|
|
#### 改进措施
|
|
|
|
|
- 提高 EA 工具使用熟练度，减少建模时间
|
|
|
|
|
- 加强需求调研深度，提前识别潜在需求变更
|
|
|
|
|
- 细化任务拆分，提高进度控制精度
|
|
|
|
|
|
|
|
|
|
### 5. 甘特图应用分析
|
|
|
|
|
|
|
|
|
|
#### 时间节点和工期安排
|
|
|
|
|
- **需求分析**：2025-11-05 至 2025-11-07（3 天）
|
|
|
|
|
- **原型设计**：2025-11-08 至 2025-11-10（3 天）
|
|
|
|
|
- **UI 开发**：2025-11-11 至 2025-11-15（5 天）
|
|
|
|
|
- **功能开发**：2025-11-16 至 2025-11-20（5 天）
|
|
|
|
|
- **测试与修复**：2025-11-21 至 2025-11-25（5 天）
|
|
|
|
|
|
|
|
|
|
总工期 21 天，关键里程碑为 11 月 10 日的原型确认和 11 月 25 日的功能交付。
|
|
|
|
|
|
|
|
|
|
#### 与其他团队成员的依赖关系
|
|
|
|
|
- 依赖数据接口团队在 11 月 15 日前完成 API 封装
|
|
|
|
|
- 为前端集成团队提供 11 月 20 日前完成的功能模块
|
|
|
|
|
- 与测试团队协作，在 11 月 21 日前提供测试版本
|
|
|
|
|
|
|
|
|
|
#### 关键路径影响分析
|
|
|
|
|
本模块位于项目关键路径上，任何延期都会影响整体项目进度。特别是 UI 开发和功能开发阶段，直接决定了后续测试和集成的时间，需要重点监控。
|
|
|
|
|
|
|
|
|
|
#### 甘特图指导价值评估
|
|
|
|
|
甘特图清晰展示了任务安排和时间节点，帮助我：
|
|
|
|
|
- 合理分配时间，避免任务堆积
|
|
|
|
|
- 识别关键任务和依赖关系，提前规划
|
|
|
|
|
- 跟踪进度偏差，及时调整计划
|
|
|
|
|
- 向团队成员清晰传达任务安排
|
|
|
|
|
|
|
|
|
|
## 实验一相关问题思考
|
|
|
|
|
|
|
|
|
|
### 问题 1：项目计划的重要性
|
|
|
|
|
软件项目计划是软件开发的基础和指南，它的重要性体现在：
|
|
|
|
|
- 明确项目目标和范围，避免开发过程中的需求蔓延
|
|
|
|
|
- 合理分配资源，提高开发效率
|
|
|
|
|
- 设定清晰的时间节点，便于进度控制
|
|
|
|
|
- 识别潜在风险，提前制定应对策略
|
|
|
|
|
|
|
|
|
|
以银行 ATM 系统为例，项目计划可指导后续开发：
|
|
|
|
|
- 通过需求分析明确取款、存款、转账等核心功能的优先级
|
|
|
|
|
- 规划安全模块的开发时间和测试重点，确保系统安全性
|
|
|
|
|
- 制定分阶段交付计划，先实现基础功能，再逐步增加高级功能
|
|
|
|
|
- 安排充分的集成测试时间，确保与银行核心系统的兼容性
|
|
|
|
|
|
|
|
|
|
### 问题 2：甘特图的应用价值
|
|
|
|
|
甘特图在项目管理中的作用和优势：
|
|
|
|
|
- 直观展示任务时间安排，便于理解和沟通
|
|
|
|
|
- 清晰显示任务间的依赖关系，帮助识别关键路径
|
|
|
|
|
- 便于跟踪进度，及时发现延期风险
|
|
|
|
|
- 支持资源分配可视化，避免资源冲突
|
|
|
|
|
|
|
|
|
|
在天气查询系统项目中，甘特图的帮助体现在：
|
|
|
|
|
- 明确各模块开发顺序，如先开发数据接口，再开发 UI 展示
|
|
|
|
|
- 合理安排测试时间，确保有足够时间修复问题
|
|
|
|
|
- 协调团队成员工作，避免重复劳动或工作空白
|
|
|
|
|
- 为项目里程碑提供明确时间点，便于进度汇报和控制
|
|
|
|
|
|
|
|
|
|
## 工具使用体会
|
|
|
|
|
|
|
|
|
|
### EA（Enterprise Architect）使用体会
|
|
|
|
|
使用 EA 的主要功能包括创建需求图、用例图、甘特图和软件过程模型图，操作流程是先创建项目，再添加相应的图表元素，最后建立元素间的关系。
|
|
|
|
|
|
|
|
|
|
**EA 的优势**：
|
|
|
|
|
- 支持多种建模语言和图表类型，满足不同阶段的建模需求
|
|
|
|
|
- 元素间关系管理清晰，便于维护复杂模型
|
|
|
|
|
- 支持团队协作和版本控制，适合团队开发
|
|
|
|
|
|
|
|
|
|
**EA 的不足**：
|
|
|
|
|
- 界面较为复杂，新手入门难度大
|
|
|
|
|
- 部分操作不够直观，需要记忆较多操作步骤
|
|
|
|
|
- 对中文支持不够友好，偶尔出现显示问题
|
|
|
|
|
|
|
|
|
|
使用中遇到的困难主要是初期不熟悉操作界面和元素关系建立方法，通过查阅官方文档和在线教程逐步解决。建议通过实际案例练习来提高使用效率，同时可以自定义快捷键简化常用操作。
|
|
|
|
|
|
|
|
|
|
### TRAE 辅助工具使用体会
|
|
|
|
|
TRAE 辅助工具主要用于辅助生成项目文档，能够根据模型自动生成部分文档内容，减少手动编写的工作量。
|
|
|
|
|
|
|
|
|
|
**TRAE 的价值**：
|
|
|
|
|
- 提高文档生成效率，减少重复劳动
|
|
|
|
|
- 保证文档与模型的一致性，避免两者脱节
|
|
|
|
|
- 提供标准化的文档模板，保证文档质量
|
|
|
|
|
|
|
|
|
|
**TRAE 的局限性**：
|
|
|
|
|
- 自动生成的内容较为基础，需要大量人工修改和补充
|
|
|
|
|
- 对模型的规范性要求高，否则生成的文档质量差
|
|
|
|
|
- 模板定制不够灵活，难以满足特定格式需求
|
|
|
|
|
|
|
|
|
|
使用体会：TRAE 作为辅助工具能有效提高文档工作效率，但不能完全替代人工编写。AI 辅助工具在软件开发中前景广阔，特别是在需求分析、文档生成和测试用例设计等方面，有望大幅提高开发效率。
|
|
|
|
|
|
|
|
|
|
### Git 版本控制使用体会
|
|
|
|
|
使用 Git 进行版本控制的基本操作包括初始化仓库、提交修改、创建分支、合并分支和解决冲突等。
|
|
|
|
|
|
|
|
|
|
**Git 在团队协作中的重要性**：
|
|
|
|
|
- 允许多人同时开发，避免代码冲突
|
|
|
|
|
- 保留完整的修改历史，便于追溯问题
|
|
|
|
|
- 支持分支管理，便于并行开发不同功能
|
|
|
|
|
- 提供代码审查机制，提高代码质量
|
|
|
|
|
|
|
|
|
|
使用中遇到的主要问题是分支合并时的代码冲突，通过提前沟通分工、频繁合并和使用可视化工具解决冲突来应对。Git 分支管理策略各有优缺点，单一主分支策略简单但不适合复杂项目，多分支策略灵活但管理成本高，应根据项目规模和团队情况选择合适的策略。
|
|
|
|
|
|
|
|
|
|
## 附录
|
|
|
|
|
|
|
|
|
|
### 附录 A：个人设计的 EA 模型图
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### 附录 B：个人测试用例表
|
|
|
|
|
（同 3. 测试用例设计中的表格）
|
|
|
|
|
|
|
|
|
|
### 附录 C：个人工作日志
|
|
|
|
|
|
|
|
|
|
| 日期 | 工作内容 | 工作时长 | 完成情况 | 遇到的问题 | 解决方案 |
|
|
|
|
|
|------|---------|---------|---------|-----------|--------|
|
|
|
|
|
| 2025-11-03 | 需求分析和功能模块划分 | 3 小时 | 完成 80% | 动态展示需求不明确 | 查阅竞品分析，明确效果范围 |
|
|
|
|
|
| 2025-11-04 | 完成需求分析，开始 EA 模型设计 | 4 小时 | 完成 100% | EA 工具操作不熟练 | 观看教程，练习基本操作 |
|
|
|
|
|
| 2025-11-05 | 设计需求图和用例图 | 3 小时 | 完成 100% | 用例关系梳理不清 | 参考示例，请教老师 |
|
|
|
|
|
| 2025-11-06 | 设计甘特图和软件过程模型图 | 3 小时 | 完成 100% | 任务时间估算不准 | 参考类似项目，团队讨论确定 |
|
|
|
|
|
| 2025-11-07 | 设计测试用例，撰写报告 | 4 小时 | 完成 100% | 测试场景考虑不全 | 从用户角度梳理使用场景 |
|
