班级 21辅修班
作业要求 团队作业3
这个作业需要做什么 需求改进、系统设计、Alpha任务分配计划、测试计划

一、需求&原型改进 - 20分

1.针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改 （5分）

  • 问题1：对于任务的分类与分组，使用什么进行分类，是你们进行分类还是用户自行输入分类？

  • 修改1：改用重要紧急作为横纵坐标分为四个模块：重要且紧急、重要不紧急、不重要紧急、不重要也不紧急。

  • 问题2：对于提醒的功能，怎么样界定提醒的时间？

  • 修改2：对于长期的任务例如期末考试，专业考证、大型比赛等重要的需要长期准备的任务，分别在截止日期前14天、7天、3天、1天提醒。对于那种日常的任务，可以自设定如晚上八点钟提醒任务。

  • 问题3：那这样怎么分类，是按轻重缓急分还是按照长期和日常分类？

  • 修改3：把提醒功能与任务分类分开来，将建立好的任务使用拖动或者选择的方式，在单独的提醒功能模块进行分类提醒。

2.修改完善上周提交的需求规格说明书（10分）

  • 改进了提醒功能和分类功能具体的分类方法，和用户体验感受

2.1任务分类功能改进

改用重要紧急作为横纵坐标分为四个模块：重要且紧急、重要不紧急、不重要紧急、不重要也不紧急。

2.2任务提醒功能改进

对于长期的任务例如期末考试，专业考证、大型比赛等重要的需要长期准备的任务，分别在截止日期前14天、7天、3天、1天提醒。对于那种日常的任务，可以自设定如晚上八点钟提醒任务。

2.3用户使用感改进

把提醒功能与任务分类分开来，将建立好的任务使用拖动或者选择的方式，在单独的提醒功能模块进行分类提醒。

3.参考《构建之法》5节功能的定位和优先级，给出功能分析的四个象限（2分）

根据《构建之法》第五章节中对功能的定位和优先级的讨论，功能分析可以划分为以下四个象限：

第一象限：核心且紧急的功能

这些功能对于产品或服务来说是至关重要的，且需求迫切。它们直接关联到产品的核心价值，是用户最关心、最依赖的部分。这些功能往往具有高度的用户满意度和忠诚度潜力，是产品成功的关键。因此，它们应该被优先开发，并确保其质量和稳定性。

第二象限：核心但不紧急的功能

这些功能同样对产品的核心价值有着重要影响，但可能不是当前最迫切的需求。它们可能代表着产品的长期发展方向或未来竞争优势。虽然这些功能不是立即需要实现的，但应当给予足够的重视，并在适当的时机进行开发。通过不断迭代和优化这些功能，可以提升产品的整体竞争力和用户满意度。

第三象限：非核心但紧急的功能

这些功能可能不是产品的核心组成部分，但由于某种原因（如市场趋势、竞争对手的动作等）而变得紧急。虽然它们可能不直接关联到产品的核心价值，但为了满足当前的市场需求或应对竞争压力，可能需要快速实现这些功能。然而，需要注意的是，过度关注这些非核心功能可能导致资源分散，影响核心功能的开发进度和质量。

第四象限：非核心且不紧急的功能

这些功能对于产品来说既不是核心也不是紧急的。它们可能是一些辅助性的、锦上添花的功能，或者是一些长期规划中的功能。在资源有限的情况下，这些功能可以暂时放在次要位置，等待合适的时机再进行开发。同时，也需要不断审视这些功能是否真的有必要，避免陷入“功能蔓延”的陷阱。

通过对功能进行这四个象限的划分，可以更加清晰地了解每个功能的定位和优先级，从而制定出更加合理、高效的产品开发计划。在实际操作中，还需要根据市场变化、用户需求等因素不断调整和优化这些象限的划分和功能的优先级。

4.根据修改后的需求，调整任务分解WBS及相应的项目进度计划（3分）分而治之（WBS,Work Breakdown Structure）

那如何做到WBS呢？书中说得很清楚：从最终的产品开始，一层一层往下，把大型交付件（Deliverable）分割为小型、具体的交付件。WBS分割的结果是一棵树。

二、系统设计 - 50分

1.最大限度地实现这些需求，系统的架构设计如下

一、软件层次结构

任务管理器的软件层次结构可以分为以下几个层次：

用户界面层：负责与用户进行交互，展示任务列表、任务详情、项目信息等，并接收用户的输入和操作。

业务逻辑层：处理任务管理器的核心业务逻辑，包括任务的创建、编辑、分配、状态更新等。该层与数据库进行交互，实现数据的增删改查操作。

数据访问层：负责与数据库进行通信，执行SQL语句，获取或存储数据。该层提供对数据库的抽象和封装，使业务逻辑层能够专注于业务处理，而无需关心具体的数据库操作。

数据存储层：存储任务管理器的相关数据，如任务、用户、项目等信息的数据库。

二、功能模块划分

任务管理器可以划分为以下几个功能模块：

用户管理模块：负责用户的注册、登录、权限管理等操作。

项目管理模块：负责项目的创建、编辑、删除以及项目下任务的管理。

任务管理模块：负责任务的创建、编辑、分配、状态更新等操作，以及任务的查询和统计功能。

通知与提醒模块：负责向用户发送任务相关的通知和提醒，如任务到期提醒、任务分配通知等。

三、系统交互流程

用户登录：用户通过用户界面层输入用户名和密码进行登录，业务逻辑层验证用户信息，并返回登录结果。

任务创建与分配：用户在用户界面层创建任务，并指定任务的属性（如名称、描述、优先级等）。业务逻辑层接收用户的输入，将任务信息存储到数据库中，并更新任务状态。如果需要分配任务给用户，业务逻辑层还会更新任务的分配者信息，并发送通知给相关用户。

任务查询与统计：用户可以通过用户界面层查询任务列表或特定任务的信息，业务逻辑层根据用户的查询条件从数据库中获取数据，并返回给用户。同时，系统还可以提供任务的统计功能，如任务完成情况统计、任务数量统计等。

任务状态更新与提醒：用户可以在用户界面层更新任务的状态（如进行中、已完成等），业务逻辑层将状态更新信息存储到数据库中，并触发相应的通知与提醒模块，向相关用户发送状态更新通知或提醒。

四、扩展考虑

安全性考虑：在系统架构设计中，需要充分考虑安全性因素，如用户身份验证、数据加密传输、防止SQL注入等，以确保系统的安全性。

性能优化：针对大规模数据处理和高并发访问的场景，可以采用缓存机制、分布式数据库等技术手段，提高系统的性能和响应速度。

可扩展性考虑：系统架构设计应具备良好的可扩展性，以便在未来根据业务需求进行功能的扩展和升级。

2.完成团队项目的数据库设计

一、表结构

用户表（Users）
UserID (主键，自增)
Username (用户名)
Password (密码，哈希加密存储)
Email (邮箱)
Phone (手机号)
CreatedAt (创建时间)
项目表（Projects）
ProjectID (主键，自增)
ProjectName (项目名称)
Description (项目描述)
CreatorID (创建者ID，外键，关联Users表的UserID)
CreatedAt (创建时间)
UpdatedAt (更新时间)
任务表（Tasks）
TaskID (主键，自增)
TaskName (任务名称)
Description (任务描述)
ProjectID (所属项目ID，外键，关联Projects表的ProjectID)
AssigneeID (分配者ID，外键，关联Users表的UserID)
StartDate (开始日期)
EndDate (结束日期)
Status (任务状态，如待处理、进行中、已完成等)
Priority (任务优先级，如高、中、低等)
CreatedAt (创建时间)
UpdatedAt (更新时间)
二、关系说明

一个用户（Users）可以创建多个项目（Projects），一个项目只能有一个创建者（CreatorID）。
一个项目（Projects）可以包含多个任务（Tasks），一个任务只能属于一个项目（ProjectID）。
一个任务（Tasks）可以被分配给一个用户（AssigneeID），一个用户可以负责多个任务。
三、索引与约束

在每个表的主键字段（UserID、ProjectID、TaskID）上设置主键约束，确保数据的唯一性。
在外键字段（如CreatorID、ProjectID、AssigneeID）上设置外键约束，确保数据的引用完整性。
根据查询需求，可以在某些字段上创建索引，提高查询性能。
四、扩展考虑

如果需要记录任务的进度信息，可以添加一个进度表（Progress），记录每个任务的进度更新历史。
如果需要支持任务的评论或讨论功能，可以添加一个评论表（Comments），记录用户对任务的评论信息。
根据实际需求，还可以考虑添加其他相关表，如标签表（Tags）、附件表（Attachments）等，以丰富任务管理器的功能。

三、Alpha任务分配计划 - 20分

(1)从Product Backlog中选取待实现的功能项

1.评估总时间：项目组下周可用的总工作时间大概是四天

2.分析功能模块优先级：考虑用户需求、市场趋势、技术实现难度等因素，将前端构建，和测试计划先做完

3.考虑模块依赖关系：在选取功能项时，要特别注意模块之间的依赖关系。优先选取那些不依赖于其他未完成模块的功能项进行。

(2)分解功能项为任务并构成Sprint Backlog

功能项分解：将选取的每个功能项进一步分解为具体的任务。每个任务应尽可能独立，且完成时间控制在1-10小时之间。

功能项 分解项1 分解项2
前端 页面搭建 页面优化
后端
数据库
测试 测试用例 测试计划

任务描述与评估：为每个任务编写详细的描述，包括任务目标、输入/输出、关键步骤等。同时，评估每个任务的工作量和技术难度。

(3)拟定迭代冲刺计划

确定关键里程碑：根据Sprint Backlog中的任务，确定关键里程碑，如设计完成、编码完成、测试开始等。

绘制甘特图：使用甘特图工具，将每个任务在时间轴上展开。明确每个任务的开始时间、结束时间以及负责人。

标识依赖关系：在甘特图中，使用箭头或线条标识任务之间的依赖关系，以便团队成员了解哪些任务需要先完成。

预留缓冲时间：在计划中预留一定的缓冲时间，以应对可能出现的意外情况或延迟。

分享与讨论：将拟定的迭代冲刺计划分享给团队成员，并邀请大家进行讨论和反馈。根据团队成员的建议，对计划进行必要的调整。

四、测试计划 - 10分

(1)测试目标

1.功能测试

功能测试主要关注任务管理器的各项基本功能是否按照预期工作。针对任务管理器的不同功能模块，如任务创建、编辑、分配、提醒、进度更新等，测试人员会设计并执行相应的测试用例。他们会按照正常操作流程和异常操作流程进行测试，确保所有功能点都能正确实现，没有遗漏或错误。

2.性能测试

性能测试旨在评估任务管理器在不同负载下的性能表现。测试人员会模拟多用户并发操作、大量数据处理等场景，观察软件的响应时间、资源消耗情况等指标。通过性能测试，可以确保任务管理器在高负载下能够保持稳定运行，不会出现卡顿、崩溃等问题。

3.兼容性测试

兼容性测试用于验证任务管理器在不同操作系统、浏览器和设备上的表现是否一致。测试人员会在多种平台上安装和运行任务管理器，检查其界面显示、功能操作、数据交互等方面是否存在问题。通过兼容性测试，可以确保任务管理器具备广泛的适用性和良好的用户体验。

4.安全性测试

安全性测试关注任务管理器是否存在安全漏洞和隐患。测试人员会利用专业的安全测试工具和技术，对软件进行漏洞扫描和攻击模拟。他们会检查软件的身份验证、权限控制、数据加密等方面是否安全可靠。通过安全性测试，可以及时发现并修复潜在的安全问题，保护用户数据和系统安全。

5.用户体验测试

用户体验测试关注任务管理器的用户界面、操作流程和交互体验是否友好和便捷。测试人员会邀请真实用户或专业评测人员进行软件试用，收集他们的反馈和建议。他们会评估软件的易用性、美观性、响应速度等方面，提出改进意见。通过用户体验测试，可以不断优化任务管理器的设计和功能，提升用户满意度。

（2）安排时间

测试准备阶段（第1周）：制定测试计划、编写测试用例、搭建测试环境等。
功能测试阶段（第1周）：对任务管理器的各项功能进行全面测试，记录测试结果和缺陷。
性能测试与兼容性测试阶段（第2周）：对软件性能进行测试，同时验证其在不同平台上的兼容性。
安全性测试与用户体验测试阶段（第2周）：进行安全漏洞扫描和用户体验评估。
缺陷修复与回归测试阶段（第3周）：根据测试结果修复缺陷，并进行回归测试，确保问题得到解决。
测试总结与报告阶段（第3周）：整理测试数据，编写测试报告，总结测试工作。