团队作业3--需求改进&系统设计—广工闲置市场小程序

这个作业属于哪个课程 https://edu.cnblogs.com/campus/gdgy/Networkengineering1834
这个作业要求在哪里 https://edu.cnblogs.com/campus/gdgy/Networkengineering1834/homework/11151
这个作业的目标 学习 Git 分支管理，学习团队合作的原则以及流程，学习需求分析和原型改进，设计团队项目总体框架，分配 Alpha 任务

目录

一、团队信息

1.1 团队名称及团队宣言

团队名称：网二软工实操小分队
团队宣言：纸上得来终觉浅,绝知此事要躬行

1.2 队员信息

队员 名称 队员 名称
3118005245 刘泽灿（组长） 3218005261 李晓暖
3118005244 林钰朋 3118005224 陈柏雨
3118005223 蔡文钦 3218005262 林漫漫
3118005248 吴立权 3118005246 彭永灿
3118005226 邓振鹏 3218005263 潘茜仪
3118005228 方嘉乐 3118005250 杨振辉
3118005242 廖世浩

1.3 团队特色

  • 主动学习，积极探索，尽快跟上大部队节奏！！
  • 团队内分工明确、各司其职，各个模块都有相应的人负责
  • 团队规定明确，有严格规范，对评分规定、代码规范、Git 分支与提交管理具有详细的规范
  • 团队成员部分具备经验，其他小白乐于学习，各有所长，优势互补

1.4 团队分工

职责 参与成员
项目管理 泽灿
技术顾问 立权
产品设计 泽灿
前端开发 钰朋、文钦，漫漫、茜仪、晓暖、世浩
后端开发 白白、嘉乐，振鹏、永灿、振辉
测试 泽灿、xxxx（待补充）
文档和复审 泽灿、晓暖、振鹏、漫漫

1.5 各成员完成情况

  • 刘泽灿
  1. 完成了博文1-3的撰写，学习了如何排版及制作甘特图等
  2. 学习了 Git 的分支管理办法，学习了如何更好地利用 issue 推进项目以及协作交流
  3. 组织开展了会议，明确第三阶段的基本任务
  4. 参与制定了测试计划

  • 蔡文钦

  • 杨振辉

  • 邓振鹏

  • 李晓暖

  • 彭永灿

  • 林钰朋

  • 潘茜仪

  • 陈柏雨

  • 廖世浩

二、需求 & 原型改进

2.1 用户调研

Persona/典型用户

参考

序号 属性 基本内容 备注
1 名字 大学城广工在校生、教职工
2 年龄 17-26岁 收入平均为1k-1.5k生活费 需求为生活用品、交通工具、学习资源等
34-50岁 收入不等 需求为家具用品等
3 收入 不同年龄和收入的用户有不同的需求
4 代表的用户在市场上的比例和重要性 比例大不等同于重要性高 如付费的用户比例较少，但是影响大，所以更重要
5 使用这个软件的典型场景 学期初 交通工具、生活用品、购买书籍
学期中 活动物资、用品租借、场地租借等
学期末 毕业季、复习资料、旧书籍处理等
6 使用本软件/服务的环境 订单 闲暇时在校园内随时可以
交易 线下近距离交换
7 生活/工作情况 校园生活、学生工作、社会实践、双创比赛
8 知识层次和能力 本科基本水平，熟悉电脑万维网
9 用户的动机、目的和困难 1.解决线下交易难问题 明确交易规则：送货上门，概不退货
（困难 = 需要解决的问题） 2.紧急时刻缺理想物品时 需要确保通用性物资充足
上架物品定价无参考 做智能推荐算法
10 用户的偏好 买方 便宜实惠实用即可
卖方 回本、多少赚一些
中间租借方 有则做，不强求

​ 为了达到更好的用户体验，我们找了班里的同学以及在各种群内投放调查问卷，向他们展示了原型以及对平时对废旧物品的处理进行了探讨，同时也去xxx查看了用户的评论与诉求，进一步与目标用户沟通理解，从而深刻理解了具体需求。

以下是针对调查得到的信息所进行的分析

用户访谈记录1

用户访谈记录2

2.2 需求改进

参考

在向目标用户展示原型之后，针对用户真是现场问答，我们用一个场景，像讲故事 （User Story）那样，描述用户怎么使用几个相联系的功能，解决了用户的问题：

针对提出的问题，我们做出如下改进：

问题1：

改进1：

问题2：

改进2：

问题3：

改进3：

问题4：

改进4：

问题5：

改进5：

2.3 功能分析的四个象限

我们参考《构建之法》5节功能的定位和优先级,给出功能分析的四个象限

需求、功能 外围功能 杀手功能
必须需求 主页显示、商品分类、在线交易 用户中心
辅助需求 信息发布、消息推送 慈善捐赠

2.4 任务分解 WBS 调整

参考分而治之WBS
根据用户提出的问题，调整任务分解 WBS 如下：

2.5 项目进度计划调整

对前面的分析与探讨，我们对具体的功能需求做出调整，并参考了Scrum/Sprint Alpha 任务分配计划 如下

功能 功能详情 所属版本
登录注册 用户注册一个账号 用户使用账号密码登录 Alpha 1.0
用户信息管理 修改密码 修改头像 修改手机号码 修改邮箱 等个人信息的修改 Alpha 1.0
用户中心 用户可以查看我的收藏、并且进行我的收藏的删除与添加等操作 Alpha 1.0
系统消息 用户收到用户评论等信息是时进行提醒，用户可进行消息的删除等操作 Alpha 1.0
添加闲置 填写闲置物品基本信息，包括基本的图片、定价、类别等 Alpha 1.0
定购物品 物品从上架状态变成被订购状态，限时确认是否交易，再确认是否交易成功 Alpha 1.0
闲置物品的详情管理 查看物品 编辑物品信息 更新物品信息 确定更改 Alpha 2.0
闲置物品的评论 展示相关评论 评论相关物品 删除部分评论 Alpha 2.0
闲置物品的收藏 展示该物品的收藏数量 添加物品至我的收藏 移除物品出我的收藏 Alpha 2.0
闲置卖家的收藏 展示卖家信息 添加卖家至我的收藏 移除卖家出我的收藏 Alpha 2.0
闲置物品的想要 展示该物品想要的数量 为该物品点“想要”取消想要 Alpha 2.0
闲置物品的展示 展示相关物品作品于首页 Alpha 3.0
首页的闲置物品搜索 于首页内进行闲置物品的搜索，可按照分类、关键词等信息进行搜索 Alpha 3.0
首页的精品闲置物品 根据综合考虑，展示精品闲置物品于首页 Alpha 3.0
闲置物品的不同排序方式 图片的展示中，可根据个人需求改变闲置物品的排序方式 Alpha 3.0

2.6 完善需求规格说明书

我们主对功能需求列表的部分做出了修改，以解决用户提出的问题，修改后的功能列表如下：
|功能|功能详情|
|---|---|---|
|登录注册 |授权微信号，id返回数据库 |
|用户信息管理 |微信id号、昵称、授权头像、修改手机号码、个性签名、五星评价（）等个人信息的修改|
|用户中心 |用户可以查看我的收藏、并且进行我的收藏的删除与添加等操作|
|系统消息 |用户收到用户评论等信息是时进行提醒，用户可进行消息的删除等操作|
|添加闲置| 填写闲置物品基本信息，包括基本的图片、定价、类别等|
|定购物品| 物品从上架状态变成被订购状态，限时确认是否交易，再确认是否交易成功|
|闲置物品的详情管理 |查看物品 编辑物品信息 更新物品信息 确定更改
|闲置物品的评论| 展示相关评论 评论相关物品 删除部分评论|
|| 展示该物品的收藏数量 添加物品至我的收藏 移除物品出我的收藏
| 关注| 展示卖家信息 添加卖家至我的收藏 移除卖家出我的收藏
|闲置物品的想要| 展示该物品想要的数量 为该物品点“想要”取消想要|
|闲置物品的展示 |展示相关物品作品于首页 |
|我的宝贝| 上架物品以及已销物品（留交易对象等信息） | |
|聊天功能| 聊天显示双方信息，确保能线下练习，正常对话|
|公告|针对首次接收公告用户发布弹窗（一开小程序就弹） | |

三、系统设计

3.1 后端框架文档

3.1.1 总体框架图

3.1.2 数据库表结构

在本次数据库表结构的构建中，我们经过不断地讨论与改进，先后生成了三份数据库表结构文档（数据库表结构 V3.1.md、数据库表结构 V3.2.md、数据库表结构 V3.3.md，详细见相关 GitHub 链接），最新版本的各个表结构如下：

3.1.3 ER 图

3.1.4 后台规范文档

为了更好地协作，我们还制定了后台代码规范，详见[ 代码规范](

3.2 前端设计文档

3.2.1 基础功能划分

页面 功能概述 功能描述
主页面 导航栏 1.LOGO 2.分类页面 3.搜索框 4.当前商品展示
搜索 1.关键词文字匹配搜索 2.分类搜索
主内容 1.部分热门图片 2.部分最新图片
商品信息页 预览 显示当前商品
属性 显示作品相关标签
卖家 显示该卖家主要信息
想要，关注 给商品“想要”，给卖家加关注
闲置物品状态 上架中、x人想要、已下架
添加闲置页面 上传功能 提供用户上传闲置物品信息接口
预览 决定最终上传前预览
分类选择 选择预设的各种分类
说明 可以给闲置物品添加备注
我的页面 个人信息 个人信息的展示及修改
登陆注册 提供用户注册和进入社区的入口
个人闲置 显示自己上传的闲置物品状态
收藏 显示收藏的图片
关注 显示关注的作者
消息 1.系统消息 2.私信 3.各类通知
错误提示页 多种错误提示 1.注册失败 2.登陆失败 3.浏览失败 4.上传失败 5.修改失败 6.评论失败

3.2.2 页面设计

首页
个人管理页面

我的收藏

3.2.3 前端规范文档

为了更好地协作，我们还制定了前端代码规范，详见前端规范文档.md

3.3 大小与性能

本系统采用的软件架构可以很好的支持以下性能需求：

系统的平均响应时间应该在500ms以内
系统的平均吞吐量应该达到300TPS以上
系统应该至少能够承载10万以上的总用户量
系统应该支持300以上的并发用户数

四、测试计划

参考了

4.1 使用人群

项目经理、开发人员、测试人员、特定范围内的用户（在全校范围内）

4.2 测试类型

  • 单元测试
    用户信息管理模块、消息管理模块、评论模块、图片模块、智能化功能模块、搜索与推荐模块

  • 压力测试
    对数据的承载量测试

  • 安全测试
    对系统的安全性能进行测试

  • 整体测试
    把不同的模块连结后，看看联合工作情况如何

4.3 测试策略

4.3.1 单元测试

4.3.2 压力测试

通过 http 协议发送访问请求，收集服务器响应速度，监控服务器运行状态和资源耗用情况

4.3.3 安全测试

测试人员模拟非法入侵，采用各种方法冲破防线。记录各项攻击数据，破防时间，攻击地点，攻击方式及代价。

4.3.4 整体测试

包括 Alpha 测试和 Beta 测试，分别是开发组内部人员测试以及开放给用户使用进行测试

4.4 测试环境

CentOS8

4.5 输出文档

《项目测试计划书》
《项目测试报告书》

五、个人感想

  • 刘泽灿

  • 蔡文钦

  • 杨振辉

  • 邓振鹏

  • 李晓暖

  • 彭永灿

  • 林钰朋

  • 潘茜仪

  • 陈柏雨

  • 廖世浩

posted @ 2020-11-22 11:52  Zack_灿  阅读(151)  评论(0)    收藏  举报