|
|
|
|
@ -0,0 +1,368 @@
|
|
|
|
|
# 实验一软件项目计划小组报告
|
|
|
|
|
|
|
|
|
|
## 小组基本信息
|
|
|
|
|
- **小组名称**:G1组
|
|
|
|
|
- **项目名称**:快递代取系统
|
|
|
|
|
- **小组组长**:董玉坤
|
|
|
|
|
- **小组成员**:董玉坤(2023210447)、程璟琦(2023210442)、董文远(2023210446)、范孝宝(2023210450)
|
|
|
|
|
- **实验日期**:2024-11-03至2024-11-07
|
|
|
|
|
- **提交日期**:2024-11-08
|
|
|
|
|
|
|
|
|
|
## 一、小组任务完成情况
|
|
|
|
|
|
|
|
|
|
### 1. 项目概述与目标
|
|
|
|
|
|
|
|
|
|
#### 1.1 项目背景与意义
|
|
|
|
|
随着电子商务的快速发展,校园快递数量急剧增加,传统的自行取件模式面临着取件时间冲突、快递堆积等问题。本项目旨在开发一个智能快递代取系统,通过连接有取件需求的学生和愿意提供代取服务的学生,解决校园快递取件难题,提高校园快递处理效率,为师生提供便利的快递服务体验。
|
|
|
|
|
|
|
|
|
|
#### 1.2 项目目标与预期成果
|
|
|
|
|
- **系统目标**:开发一个安全、高效、易用的校园快递代取系统,实现快递信息发布、代取任务承接、费用支付、状态跟踪等核心功能。
|
|
|
|
|
- **预期成果**:
|
|
|
|
|
- 完成系统核心功能模块开发
|
|
|
|
|
- 实现用户友好的界面设计
|
|
|
|
|
- 确保系统安全性和稳定性
|
|
|
|
|
- 提供完整的用户使用文档
|
|
|
|
|
- 支持校园内主要快递点的快递代取服务
|
|
|
|
|
|
|
|
|
|
#### 1.3 项目范围
|
|
|
|
|
本项目主要针对校园环境下的快递代取服务,覆盖学生用户、代取员用户和系统管理员三种角色,支持快递信息发布、代取任务管理、支付结算、数据统计等功能。系统将支持主流移动设备访问,确保用户在校园内任何地点都能便捷使用。
|
|
|
|
|
|
|
|
|
|
### 2. 功能需求分析
|
|
|
|
|
|
|
|
|
|
#### 2.1 总体功能架构
|
|
|
|
|
快递代取系统采用模块化设计,主要包含用户注册登录模块、人员交互功能模块、订单与支付管理模块以及数据统计与可视化模块。各模块之间通过清晰的接口进行交互,确保系统的可维护性和可扩展性。
|
|
|
|
|
|
|
|
|
|
#### 2.2 核心功能模块需求
|
|
|
|
|
|
|
|
|
|
##### 2.2.1 用户注册登录模块(负责人:范孝宝)
|
|
|
|
|
- **功能描述**:实现用户身份认证和账号管理功能。
|
|
|
|
|
- **主要功能点**:
|
|
|
|
|
- 人员注册:支持新用户创建账号,需验证学生身份
|
|
|
|
|
- 账号登录:提供用户登录功能,支持记住密码
|
|
|
|
|
- 密码找回:提供密码重置功能,通过手机或邮箱验证
|
|
|
|
|
- **安全性考虑**:
|
|
|
|
|
- 密码加密存储
|
|
|
|
|
- 防暴力破解机制
|
|
|
|
|
- 多因素身份验证
|
|
|
|
|
- **用户体验设计**:
|
|
|
|
|
- 界面简洁直观
|
|
|
|
|
- 错误提示友好
|
|
|
|
|
- 操作流程流畅
|
|
|
|
|
|
|
|
|
|
##### 2.2.2 人员交互功能模块(负责人:董文远)
|
|
|
|
|
- **功能描述**:实现用户之间的信息交流和任务协作功能。
|
|
|
|
|
- **主要功能点**:
|
|
|
|
|
- 任务发布:用户发布快递代取需求
|
|
|
|
|
- 任务接受:代取员查看并接受任务
|
|
|
|
|
- 消息通知:系统消息和用户间消息传递
|
|
|
|
|
- 权限管理:不同角色(学生、代取员、管理员)权限控制
|
|
|
|
|
- **交互流程设计**:
|
|
|
|
|
- 用户界面原型设计
|
|
|
|
|
- 交互流程图绘制
|
|
|
|
|
- 响应式布局适配
|
|
|
|
|
|
|
|
|
|
##### 2.2.3 订单与支付管理模块(负责人:程璟琦)
|
|
|
|
|
- **功能描述**:实现快递代取订单的创建、管理和支付功能。
|
|
|
|
|
- **主要功能点**:
|
|
|
|
|
- 订单创建:用户填写订单信息,包含取件信息、收货地址、时间要求、报酬设置等
|
|
|
|
|
- 订单状态管理:待支付、待接单、进行中、已完成、已取消等多种状态流转
|
|
|
|
|
- 支付功能:支持微信、支付宝等多种支付方式
|
|
|
|
|
- 订单查询与筛选:支持按状态、时间、类型等条件查询订单
|
|
|
|
|
- 支付记录管理:记录所有支付流水,支持查询和对账
|
|
|
|
|
- **业务流程**:
|
|
|
|
|
- 订单创建 → 支付处理 → 接单匹配 → 任务执行 → 完成确认 → 评价反馈
|
|
|
|
|
- **安全性保障**:
|
|
|
|
|
- 支付加密传输
|
|
|
|
|
- 订单状态流转控制
|
|
|
|
|
- 数据一致性管理
|
|
|
|
|
|
|
|
|
|
##### 2.2.4 数据统计与可视化模块(负责人:董玉坤)
|
|
|
|
|
- **功能描述**:实现系统数据的收集、处理、分析和可视化展示功能。
|
|
|
|
|
- **主要功能点**:
|
|
|
|
|
- 数据采集:收集系统中的订单数据、用户行为数据、支付数据等
|
|
|
|
|
- 数据处理:对采集的数据进行清洗、转换、聚合等预处理
|
|
|
|
|
- 统计分析:实现订单量统计、用户活跃度分析、收入统计等核心分析功能
|
|
|
|
|
- 可视化展示:通过图表、仪表盘等形式直观展示分析结果
|
|
|
|
|
- 导出功能:支持将统计数据和图表导出为Excel、PDF等格式
|
|
|
|
|
- **数据流程**:
|
|
|
|
|
- 数据采集 → ETL处理 → 数据存储 → 统计分析 → 可视化展示
|
|
|
|
|
- **质量保障**:
|
|
|
|
|
- 数据校验规则
|
|
|
|
|
- 定期数据审计
|
|
|
|
|
- 异常数据报警机制
|
|
|
|
|
|
|
|
|
|
#### 2.3 非功能性需求
|
|
|
|
|
- **性能需求**:系统响应时间不超过3秒,支持至少5000用户并发访问
|
|
|
|
|
- **安全需求**:数据加密存储,访问权限控制,防SQL注入等安全措施
|
|
|
|
|
- **可用性需求**:系统可用性达到99.9%,支持7×24小时不间断运行
|
|
|
|
|
- **可扩展性需求**:模块化设计,支持功能扩展和性能扩展
|
|
|
|
|
- **兼容性需求**:支持主流浏览器和移动设备访问
|
|
|
|
|
|
|
|
|
|
### 3. 资源计划与分配
|
|
|
|
|
|
|
|
|
|
#### 3.1 人力资源规划
|
|
|
|
|
- **项目经理**:董玉坤(负责整体项目管理和数据统计与可视化模块)
|
|
|
|
|
- **开发人员**:
|
|
|
|
|
- 范孝宝(负责用户注册登录模块)
|
|
|
|
|
- 董文远(负责人员交互功能模块)
|
|
|
|
|
- 程璟琦(负责订单与支付管理模块)
|
|
|
|
|
- **测试人员**:全体成员(负责各自模块的测试工作)
|
|
|
|
|
|
|
|
|
|
#### 3.2 工具与技术资源
|
|
|
|
|
- **开发工具**:
|
|
|
|
|
- 前端:HTML5、CSS3、JavaScript、React
|
|
|
|
|
- 后端:Java、Spring Boot、MyBatis
|
|
|
|
|
- 数据库:MySQL
|
|
|
|
|
- 建模工具:Enterprise Architect
|
|
|
|
|
- **测试工具**:Junit、Postman
|
|
|
|
|
- **版本控制**:Git
|
|
|
|
|
- **项目管理工具**:Trello、Microsoft Project
|
|
|
|
|
|
|
|
|
|
#### 3.3 资金资源规划
|
|
|
|
|
项目开发阶段无需外部资金,主要利用现有实验室设备和软件资源。后期运营可考虑引入校园创业基金支持。
|
|
|
|
|
|
|
|
|
|
### 4. 进度计划
|
|
|
|
|
|
|
|
|
|
#### 4.1 总体时间规划
|
|
|
|
|
- **需求分析阶段**:2024-11-03至2024-11-04(2天)
|
|
|
|
|
- **系统设计阶段**:2024-11-04至2024-11-05(2天)
|
|
|
|
|
- **开发实现阶段**:2024-11-05至2024-11-06(2天)
|
|
|
|
|
- **测试调试阶段**:2024-11-06至2024-11-07(2天)
|
|
|
|
|
- **文档编写与提交**:2024-11-07至2024-11-08(1天)
|
|
|
|
|
|
|
|
|
|
#### 4.2 任务分解与时间安排
|
|
|
|
|
| 任务ID | 任务名称 | 负责人 | 开始日期 | 结束日期 | 持续时间 | 前置任务 |
|
|
|
|
|
|--------|----------|--------|----------|----------|----------|----------|
|
|
|
|
|
| T001 | 需求分析与功能规划 | 全体成员 | 2024-11-03 | 2024-11-04 | 2天 | 无 |
|
|
|
|
|
| T002 | 系统架构设计 | 全体成员 | 2024-11-04 | 2024-11-05 | 2天 | T001 |
|
|
|
|
|
| T003 | 用户注册登录模块开发 | 范孝宝 | 2024-11-05 | 2024-11-06 | 2天 | T002 |
|
|
|
|
|
| T004 | 人员交互功能模块开发 | 董文远 | 2024-11-05 | 2024-11-06 | 2天 | T002 |
|
|
|
|
|
| T005 | 订单与支付管理模块开发 | 程璟琦 | 2024-11-05 | 2024-11-06 | 2天 | T002 |
|
|
|
|
|
| T006 | 数据统计与可视化模块开发 | 董玉坤 | 2024-11-05 | 2024-11-06 | 2天 | T002 |
|
|
|
|
|
| T007 | 系统测试与调试 | 全体成员 | 2024-11-06 | 2024-11-07 | 2天 | T003,T004,T005,T006 |
|
|
|
|
|
| T008 | 文档编写与提交 | 全体成员 | 2024-11-07 | 2024-11-08 | 1天 | T007 |
|
|
|
|
|
|
|
|
|
|
#### 4.3 里程碑设置
|
|
|
|
|
- **里程碑1**:需求分析完成(2024-11-04)
|
|
|
|
|
- **里程碑2**:系统设计完成(2024-11-05)
|
|
|
|
|
- **里程碑3**:核心功能开发完成(2024-11-06)
|
|
|
|
|
- **里程碑4**:系统测试通过(2024-11-07)
|
|
|
|
|
- **里程碑5**:项目文档提交(2024-11-08)
|
|
|
|
|
|
|
|
|
|
### 5. 团队组织与协作
|
|
|
|
|
|
|
|
|
|
#### 5.1 团队角色与职责分配
|
|
|
|
|
- **项目经理(董玉坤)**:负责项目整体规划、协调各成员工作、进度监控、风险管理以及数据统计与可视化模块的开发。
|
|
|
|
|
- **开发人员(范孝宝)**:负责用户注册登录模块的需求分析、设计、开发和测试工作。
|
|
|
|
|
- **开发人员(董文远)**:负责人员交互功能模块的需求分析、设计、开发和测试工作。
|
|
|
|
|
- **开发人员(程璟琦)**:负责订单与支付管理模块的需求分析、设计、开发和测试工作。
|
|
|
|
|
|
|
|
|
|
#### 5.2 沟通与协作机制
|
|
|
|
|
- **日常沟通**:每日早会15分钟,同步进度和问题
|
|
|
|
|
- **周例会**:每周五下午进行周总结和下周计划
|
|
|
|
|
- **文档共享**:使用Google Drive进行文档协作
|
|
|
|
|
- **代码协作**:使用Git进行版本控制
|
|
|
|
|
- **即时通讯**:使用微信群进行日常沟通
|
|
|
|
|
|
|
|
|
|
#### 5.3 冲突管理策略
|
|
|
|
|
- **预防策略**:明确任务分工,设定清晰的目标和期望
|
|
|
|
|
- **解决机制**:遇到冲突时,首先进行内部讨论,如无法达成一致,由项目经理协调解决
|
|
|
|
|
- **反馈机制**:定期收集团队成员反馈,及时调整工作方式和分配
|
|
|
|
|
|
|
|
|
|
### 6. 风险分析与应对
|
|
|
|
|
|
|
|
|
|
#### 6.1 技术风险
|
|
|
|
|
- **风险1**:支付系统集成复杂,可能影响开发进度
|
|
|
|
|
- **应对措施**:提前研究第三方支付接口文档,采用成熟的SDK,预留充足的集成和测试时间
|
|
|
|
|
- **风险2**:数据安全问题,用户敏感信息泄露
|
|
|
|
|
- **应对措施**:实施严格的数据加密机制,采用HTTPS协议,定期进行安全审计
|
|
|
|
|
- **风险3**:系统性能问题,并发访问时响应缓慢
|
|
|
|
|
- **应对措施**:进行性能测试,优化数据库查询,使用缓存技术,考虑分布式架构
|
|
|
|
|
|
|
|
|
|
#### 6.2 项目管理风险
|
|
|
|
|
- **风险1**:需求变更频繁,导致范围蔓延
|
|
|
|
|
- **应对措施**:建立需求变更管理流程,评估变更影响,严格控制变更范围
|
|
|
|
|
- **风险2**:团队成员进度不一致,影响整体交付
|
|
|
|
|
- **应对措施**:加强进度监控,及时发现和解决进度滞后问题,必要时进行资源调整
|
|
|
|
|
- **风险3**:团队协作不畅,沟通效率低
|
|
|
|
|
- **应对措施**:定期组织团队建设活动,建立有效的沟通机制,提高团队凝聚力
|
|
|
|
|
|
|
|
|
|
#### 6.3 外部风险
|
|
|
|
|
- **风险1**:第三方服务不可用,如支付平台故障
|
|
|
|
|
- **应对措施**:集成多个第三方服务提供商,实现服务冗余,制定应急预案
|
|
|
|
|
- **风险2**:学校网络环境限制,影响系统部署
|
|
|
|
|
- **应对措施**:提前与学校网络中心沟通,了解网络环境要求,必要时进行技术调整
|
|
|
|
|
|
|
|
|
|
### 7. 质量保证计划
|
|
|
|
|
|
|
|
|
|
#### 7.1 质量目标
|
|
|
|
|
- **功能完整性**:确保所有需求功能点都已实现
|
|
|
|
|
- **系统稳定性**:系统运行稳定,无严重bug
|
|
|
|
|
- **性能达标**:满足规定的性能指标要求
|
|
|
|
|
- **用户满意度**:用户对系统使用体验满意
|
|
|
|
|
|
|
|
|
|
#### 7.2 质量控制措施
|
|
|
|
|
- **代码审查**:实行双人代码审查制度,确保代码质量
|
|
|
|
|
- **单元测试**:每个模块必须编写单元测试,测试覆盖率达到80%以上
|
|
|
|
|
- **集成测试**:各模块完成后进行集成测试,验证模块间接口正确性
|
|
|
|
|
- **系统测试**:完成所有功能开发后进行系统测试,验证系统功能和性能
|
|
|
|
|
- **用户测试**:邀请目标用户进行测试,收集反馈意见
|
|
|
|
|
|
|
|
|
|
#### 7.3 质量保证工具与方法
|
|
|
|
|
- **静态代码分析**:使用SonarQube进行代码质量分析
|
|
|
|
|
- **自动化测试**:使用Selenium进行前端自动化测试
|
|
|
|
|
- **性能测试**:使用JMeter进行性能测试
|
|
|
|
|
- **Bug跟踪**:使用Jira进行Bug管理和跟踪
|
|
|
|
|
|
|
|
|
|
## 二、EA模型设计
|
|
|
|
|
|
|
|
|
|
### 1. 组织结构图
|
|
|
|
|
|
|
|
|
|
#### 1.1 设计说明
|
|
|
|
|
使用Enterprise Architect设计的组织结构图展示了快递代取系统的开发团队组织结构和职责分配。该图清晰地展示了团队成员的角色、职责和汇报关系,有助于明确团队协作方式。
|
|
|
|
|
|
|
|
|
|
#### 1.2 模型图中的主要元素
|
|
|
|
|
- **项目经理**:董玉坤,负责整体项目管理和数据统计与可视化模块
|
|
|
|
|
- **开发人员**:
|
|
|
|
|
- 范孝宝:负责用户注册登录模块
|
|
|
|
|
- 董文远:负责人员交互功能模块
|
|
|
|
|
- 程璟琦:负责订单与支付管理模块
|
|
|
|
|
- **测试团队**:全体成员参与测试工作
|
|
|
|
|
|
|
|
|
|
#### 1.3 设计思路与特点
|
|
|
|
|
采用扁平化的组织结构设计,减少管理层次,提高沟通效率。项目经理负责整体协调,各开发人员独立负责各自模块,同时通过团队协作确保系统整体一致性。
|
|
|
|
|
|
|
|
|
|
### 2. 甘特图
|
|
|
|
|
|
|
|
|
|
#### 2.1 设计说明
|
|
|
|
|
使用Enterprise Architect设计的甘特图展示了快递代取系统开发的时间规划和任务安排。该图详细列出了每个任务的开始时间、结束时间、持续时间、负责人和前置任务,有助于项目进度管理和监控。
|
|
|
|
|
|
|
|
|
|
#### 2.2 模型图中的主要元素
|
|
|
|
|
- **任务**:需求分析、系统设计、各模块开发、测试调试、文档编写等
|
|
|
|
|
- **时间线**:从2024-11-03到2024-11-08的项目周期
|
|
|
|
|
- **里程碑**:关键时间节点,如需求分析完成、系统设计完成、功能开发完成等
|
|
|
|
|
- **依赖关系**:任务之间的先后顺序关系
|
|
|
|
|
|
|
|
|
|
#### 2.3 设计思路与特点
|
|
|
|
|
采用WBS(工作分解结构)方法将项目分解为可管理的任务,合理安排任务顺序和资源分配。通过关键路径分析,识别对项目进度影响最大的任务,重点关注这些任务的执行情况。
|
|
|
|
|
|
|
|
|
|
### 3. 用例图与UCP估算
|
|
|
|
|
|
|
|
|
|
#### 3.1 设计说明
|
|
|
|
|
使用Enterprise Architect设计的用例图展示了快递代取系统的用户与系统交互场景。该图描述了不同角色的用户(普通用户、代取员、管理员)与系统功能之间的交互关系,有助于明确系统功能边界。
|
|
|
|
|
|
|
|
|
|
#### 3.2 模型图中的主要元素
|
|
|
|
|
- **参与者**:
|
|
|
|
|
- 用户:需要代取快递的学生
|
|
|
|
|
- 代取员:提供代取服务的学生
|
|
|
|
|
- 管理员:系统管理人员
|
|
|
|
|
- **用例**:
|
|
|
|
|
- 用户管理:注册、登录、密码找回
|
|
|
|
|
- 任务管理:发布任务、接受任务、完成任务
|
|
|
|
|
- 订单管理:创建订单、查询订单、取消订单
|
|
|
|
|
- 支付管理:支付订单、查询支付记录
|
|
|
|
|
- 数据统计:查看统计报表、导出数据
|
|
|
|
|
- 系统管理:用户管理、权限设置、系统配置
|
|
|
|
|
|
|
|
|
|
#### 3.3 UCP估算过程
|
|
|
|
|
根据用例点(UCP)方法进行项目规模估算:
|
|
|
|
|
- **参与者权重**:用户(简单,1点)、代取员(简单,1点)、管理员(平均,2点)
|
|
|
|
|
- **用例权重**:基础用例(简单,5点)、核心用例(平均,10点)、复杂用例(复杂,15点)
|
|
|
|
|
- **技术复杂度因子**:分布式系统(2)、性能要求(2)、安全要求(3)、集成要求(2)
|
|
|
|
|
- **环境复杂度因子**:团队经验(2)、开发工具(3)、需求稳定性(1)
|
|
|
|
|
- **UCP计算**:未调整UCP × (0.65 + 0.01 × 调整因子之和)
|
|
|
|
|
|
|
|
|
|
### 4. 需求模型图
|
|
|
|
|
|
|
|
|
|
#### 4.1 设计说明
|
|
|
|
|
使用Enterprise Architect设计的需求模型图展示了快递代取系统的需求层次结构和依赖关系。该图从高层需求逐步分解到具体功能点,有助于全面理解系统需求。
|
|
|
|
|
|
|
|
|
|
#### 4.2 模型图中的主要元素
|
|
|
|
|
- **根需求**:快递代取系统
|
|
|
|
|
- **一级需求**:用户管理、任务管理、订单管理、支付管理、数据统计、系统管理
|
|
|
|
|
- **二级需求**:各一级需求下的具体功能模块
|
|
|
|
|
- **三级需求**:具体的功能点和特性
|
|
|
|
|
|
|
|
|
|
#### 4.3 设计思路与特点
|
|
|
|
|
采用层次化的需求分解方法,将复杂的系统需求分解为可管理的需求单元。通过需求间的依赖关系描述,明确需求之间的关联和影响,有助于需求变更管理。
|
|
|
|
|
|
|
|
|
|
### 5. 软件过程与测试模型图
|
|
|
|
|
|
|
|
|
|
#### 5.1 设计说明
|
|
|
|
|
使用Enterprise Architect设计的软件过程与测试模型图展示了快递代取系统的开发流程和测试策略。该图描述了从需求分析到系统交付的完整软件开发生命周期,以及各阶段的测试活动。
|
|
|
|
|
|
|
|
|
|
#### 5.2 模型图中的主要元素
|
|
|
|
|
- **开发阶段**:需求分析、系统设计、编码实现、测试调试、部署交付
|
|
|
|
|
- **测试活动**:单元测试、集成测试、系统测试、用户测试、验收测试
|
|
|
|
|
- **文档产出**:需求规格说明书、设计文档、测试计划、用户手册等
|
|
|
|
|
|
|
|
|
|
#### 5.3 设计思路与特点
|
|
|
|
|
采用迭代增量的开发模式,结合瀑布模型的严谨性和敏捷方法的灵活性。在每个开发阶段都进行相应的测试活动,确保系统质量。通过持续集成和自动化测试,提高开发效率和产品质量。
|
|
|
|
|
|
|
|
|
|
## 三、工具使用总结
|
|
|
|
|
|
|
|
|
|
### 1. Enterprise Architect工具使用情况
|
|
|
|
|
本项目使用Enterprise Architect进行需求建模、用例分析、项目规划和系统设计。通过EA工具,团队成员能够直观地展示系统架构和业务流程,提高了沟通效率和设计质量。主要使用了EA的需求图、用例图、甘特图、组织结构图等功能,这些功能对于项目的规划和管理起到了重要作用。
|
|
|
|
|
|
|
|
|
|
### 2. 版本控制工具使用情况
|
|
|
|
|
项目使用Git进行代码版本控制,通过分支管理和代码合并,确保了团队成员的协作开发。使用GitHub作为代码托管平台,实现了代码的远程存储和共享。
|
|
|
|
|
|
|
|
|
|
### 3. 项目管理工具使用情况
|
|
|
|
|
使用Trello进行任务管理和进度跟踪,通过看板方式展示任务状态,提高了团队协作效率。使用Microsoft Project进行项目进度计划制定,通过甘特图直观展示项目时间线和任务依赖关系。
|
|
|
|
|
|
|
|
|
|
## 四、项目管理实践
|
|
|
|
|
|
|
|
|
|
### 1. 项目启动与规划
|
|
|
|
|
项目启动阶段,团队成员共同讨论了项目背景、目标和范围,明确了项目的业务价值和技术挑战。通过需求分析会议,收集和整理了系统需求,形成了需求规格说明书。在项目规划阶段,制定了详细的项目计划,包括时间安排、资源分配和风险管理计划。
|
|
|
|
|
|
|
|
|
|
### 2. 需求管理
|
|
|
|
|
建立了需求变更管理流程,对需求变更进行评估和控制。通过需求跟踪矩阵,确保每个需求都得到实现和验证。定期与利益相关者沟通,收集反馈意见,及时调整需求优先级和实现方案。
|
|
|
|
|
|
|
|
|
|
### 3. 进度管理
|
|
|
|
|
通过甘特图和每日进度报告,监控项目进度执行情况。对于进度滞后的任务,及时分析原因并采取措施,确保项目按时交付。设立了里程碑检查点,在每个里程碑完成后进行评审,确保项目质量。
|
|
|
|
|
|
|
|
|
|
### 4. 质量管理
|
|
|
|
|
建立了质量保证体系,包括代码审查、测试流程和质量标准。通过自动化测试工具,提高了测试效率和覆盖率。定期进行质量评审,及时发现和解决质量问题。
|
|
|
|
|
|
|
|
|
|
### 5. 风险管理
|
|
|
|
|
在项目启动阶段进行了风险识别和评估,制定了风险应对策略。在项目执行过程中,持续监控风险状态,及时调整风险管理计划。对于已发生的风险事件,采取有效的应对措施,减少对项目的影响。
|
|
|
|
|
|
|
|
|
|
## 五、项目成果与反思
|
|
|
|
|
|
|
|
|
|
### 1. 项目成果
|
|
|
|
|
- 完成了快递代取系统的需求分析和设计文档
|
|
|
|
|
- 设计了完整的EA模型,包括需求图、用例图、甘特图等
|
|
|
|
|
- 制定了详细的项目计划和管理方案
|
|
|
|
|
- 建立了团队协作机制和沟通渠道
|
|
|
|
|
- 完成了各功能模块的初步设计和规划
|
|
|
|
|
|
|
|
|
|
### 2. 经验总结
|
|
|
|
|
- **团队协作**:有效的团队协作是项目成功的关键,通过明确的分工和良好的沟通,提高了工作效率
|
|
|
|
|
- **需求管理**:需求的准确性和完整性对项目质量至关重要,需要持续关注需求变更和验证
|
|
|
|
|
- **进度控制**:及时的进度监控和调整,有助于项目按时交付
|
|
|
|
|
- **风险管理**:提前识别和应对风险,能够减少项目执行过程中的不确定性
|
|
|
|
|
|
|
|
|
|
### 3. 改进方向
|
|
|
|
|
- 加强需求分析的深度和广度,确保需求的全面性和准确性
|
|
|
|
|
- 优化项目计划的制定方法,提高计划的可执行性
|
|
|
|
|
- 加强团队成员的技术培训,提高技术能力和协作水平
|
|
|
|
|
- 改进测试策略,提高测试覆盖率和效率
|
|
|
|
|
|
|
|
|
|
## 六、附录
|
|
|
|
|
|
|
|
|
|
### 1. 参考资料
|
|
|
|
|
- 《软件工程导论》(第6版),张海藩,清华大学出版社
|
|
|
|
|
- 《软件项目管理》(第2版),王如龙,清华大学出版社
|
|
|
|
|
- 《需求工程实践》,骆斌,高等教育出版社
|
|
|
|
|
|
|
|
|
|
### 2. 团队成员贡献说明
|
|
|
|
|
- **董玉坤**:项目经理,负责整体项目管理、数据统计与可视化模块设计和EA模型中的需求图、甘特图设计
|
|
|
|
|
- **范孝宝**:开发人员,负责用户注册登录模块设计和EA模型中的用例图设计
|
|
|
|
|
- **董文远**:开发人员,负责人员交互功能模块设计和EA模型中的组织结构图设计
|
|
|
|
|
- **程璟琦**:开发人员,负责订单与支付管理模块设计和EA模型中的软件过程与测试模型图设计
|
|
|
|
|
|
|
|
|
|
### 3. 会议记录
|
|
|
|
|
- **第一次会议**(2024-11-03):项目启动,确定项目范围和团队分工
|
|
|
|
|
- **第二次会议**(2024-11-04):需求分析评审,确认系统功能需求
|
|
|
|
|
- **第三次会议**(2024-11-05):系统设计评审,讨论技术方案和架构设计
|
|
|
|
|
- **第四次会议**(2024-11-07):项目总结,分享经验教训,讨论改进方向
|