团队作业3--需求改进&系统设计
| 这个作业属于哪个课程 | 软件工程 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | 团队作业3-《需求改进&系统设计》 |
需求&原型改进
问题的解决
问题1:怎么解决这个安全性的问题？
修改1：使用学号，学籍信息作为担保。
问题2:怎么确保任务是被完成了呢？
修改2：首先由接跑腿的人发图片给用户，然后由用户判定，用户判定完以后，再确定是否要接受。
假如有争议的话，交给平台来处理。
项目的调查问卷
事实证明，帮帮小程序在大学生群体中是确实被需要的。！！！！
一.需求规格说明书（2.0）
1.1.1编写目的
为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。
1.1.2产品说明
- 产品名称：帮帮
- 产品类型：微信小程序
- 界面语言：简体中文
- 使用人群：大学生
- 产品功能：提供一个社交平台，用户能够发布任务，能够接受人家发布的任务。
1.2 项目阐述
1.2.1产品功能
提供一个社交平台，用户能够发布任务，能够接受人家发布的任务。提供信誉保证。
1.2.2面向的用户分析
(1).用户画像：
因为身体原因不方便的同学,忙碌的同学，懒得下楼拿东西的同学，宅在宿舍的年轻人群体。总结：“不方便”,“懒”。
(2).为什么他们需要别人帮忙（用户的需求）
1.年轻人群体的拿快递，拿外卖，打印需求很多，当这些需求多的时候，肯定存在一部分人不想去干，或者确实不能去干。
2.宅文化在年轻人群体中流行，尤其是大学生，除了上课都想足不出户。
(3).用户数量级：
| 阶段 | 用户数量 |
|---|---|
| 广东工业大学的学生 | 2k以下 |
| 小谷围岛 | 15k以下 |
| 未定 | 未定 |
1.2.3用户可能使用的情景
1.体测完腿脚不便，不合适爬楼梯这种人群。
推广下就是运动过度或者意外受伤而又不想麻烦舍友的人群可以考虑。2.不想下楼拿外卖。
3.人在工一，没想到团委要收东西，叫人去打印，然后给团委。
4.到了期末了，宿舍东西太多了，搬宿舍要拿下楼。
1.2.4真实性
代跑腿的群确实存在，并且每天的需求量很多。
1.2.5可用性
构建一个微信小平台，轻松满足用户的需求。
1.2.6独特性
暂时还没有校园类平台实现这样的功能
1.2.7产品的逻辑分析（见下面的系统设计）
1.用户在平台发布任务，并且提交任务的“赏金”（没有人接单将会退还）。
2.根据接单人的信誉值判定他是否能接受任务。
3.接单人完成任务。
4.发布人检查用户是否完成，完成的话平台将“赏金“给接单人，没完成的话，
应该先由两个人自行商议，商议失败后，提交材料给平台，平台进行审核。（信誉分扣除）。
1.2.8价值所在
是给用户需要跑腿的行为提供一个平台，并且提供一个信誉保障。
能给代跑腿的用户一个平台接单，并且提供第三方的审核，缓解纠纷。
1.3产品的需求分析
1.3.1功能需求分析
(1).满足用户“随叫随到”的需求，体验出产品对客户需求完成的及时性。
用户发出任务后，能够及时的被接单，同时任务也能及时被完成。
(2).满足用户“有求必应”的需求，体现出产品对客户需求完成的响应性。
用户发出任务后，任务大概率不会没人接。
(3)满足用户“安全完成”的需求，提现出产品对客户需求完成的安全性。
用户发出任务后，任务能被安全的完成，保证不会有财物损失。
(4)满足用户“有单能接”的需求，让用户能有机会去接单，能拿到外快。
保证接单的人，能够在完成任务以后，拿到应得的酬劳。
1.4WBS图
上面每个小框框都会有前后端的接口
| 需要完成的任务 | 完成的情况 |
|---|---|
| 发布类型 | |
| 发布金额的 | |
| 发布内容 | |
| 发布人的信用评估 | |
| 验收逻辑 | |
| 按类型接受 | |
| 接单人的信用评估 | |
| 完成逻辑 | |
| 超时未完成的处理 | |
| 接的单 | |
| 发的单 | |
| 信用 | |
| 登录 | |
| 退出 | |
| 资料卡 |
1.5项目原型
2.0系统设计
| 前端页面 | 直接与用户打交道，与用户进行交互 |
|---|---|
| 后端系统 | 负责处理用户的请求，为用户提供其想要的数据 |
使用ajax请求给后台减少压力，并且返回json统一后数据
| 阶段时间 | 阶段任务 | 完成情况 |
|---|---|---|
| 第6周 | 1.团队组队、团队博客 | 已完成 |
| 2.团队介绍、成员展示、角色分配、选题确定 | 已完成 | |
| 3.制定团队计划安排，团队贡献分的规定 | 已完成 | |
| 第7周 | 1.需求规格说明书 | 已完成 |
| 2.原型设计，队员估计任务难度并学习必要的技术 | 已完成 | |
| 3.编码规范完成、平台环境搭建完成、初步架构搭建 | 已完成 | |
| 第8周 | 原型改进（给目标用户展现原型，并进一步理解需求） | 已完成 |
| 2.架构设计，WBS, 团队成员估计各自任务所需时间 | 已完成 | |
| 3.测试计划 | 已完成 | |
| 第9、10周 | 1. 团队项目Alpha任务分配计划 | 已完成 |
| 2. 数据库设计完成 | 已完成 | |
| 3. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | 待完成 | |
| 第11周 | 1.用户反馈+测试计划改进 | 待完成 |
| 2. 团队Alpha阶段个人总结 | 待完成 | |
| 3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 | 待完成 | |
| 第12周 | 1. 团队项目Alpha博客，事后分析 | 待完成 |
3.0本周任务分配计划
| 任务 | 关键内容 | 负责人 |
|---|---|---|
| git相关知识学习 | 学会代码的提交和下载。 | 全体成员 |
| 前端学习 | 完成小程序的学习。 | 刘志鸿，詹栩丹。 |
| 后台学习 | 完成后台的学习。 | 郭裕霖，刘世轩。 |
| 测试学习 | 完成测试的学习。 | 丁科文。 |
| 项目的基本搭建 | 配置好项目的基本环境，确定好分包和使用的技术，部署服务器。 | 郭裕霖。 |
| 初步代码实现 | 尝试初步实现用户信息的管理。 | 郭裕霖，刘世轩。 |
| 完成与感想汇报 | 汇报这周的完成情况 | 全体成员 |
4.0alpha任务
| 任务大类 | 任务 | 预计时长 |
|---|---|---|
| 环境搭建 | 服务器环境搭建 | 5h |
| 后台接口实现 | 发布订单,接受订单,处理订单,订单逻辑,登录/退出,个人信息处理，订单分类查询，订单准确查询 | 每个2h |
| 前端实现 | 页面设计，以及上面的每个小接口 | 每个3h |
| 总计 | 完成基础接单功能（支付还没接入） | 75h |
甘特图
测试计划：
测试范围有三大模块：‘首页’、‘订单详情’、‘我的’
登录功能：用户使用账号密码登录、用户注册一个账号。
查看订单详情：用户登录后点击订单页面，即可切换至订单界面。
发布订单：用户在订单界面，编辑订单详情，点击发布即可正常发出订单。
修改订单：在订单界面，点击订单，即可进行备注和取消。
接收订单：跑腿人在订单界面，点击接收即可接收订单。
修改个人信息：点击‘我的’进入我的模块，点击头像即可进行编辑。
测试安排：
测试人员：丁科文
登录功能：11.8
订单功能：11.10
修改功能：11.12