团队作业3——需求改进&系统设计

1、需求&原型改进

1.1 经典用户说明：

1.1.1 问题

1. 新生使用这款软件是否真的能更好的融入校园生活？
2. 便捷性与社交性如何体现？

1.1.2 问题修改与完善

1. 针对第一个问题，我们内嵌一个校园趣事榜（具体参见广工帮帮：）通过掌握校园的最新资讯以及在此发布生活趣事来增加对学校的认同感与归属感。
2. 针对第二个问题，我们为已注册用户提供：“与陌生人聊天功能”，这样就能减少添加只会聊一两句的陌生人，减少社交成本，

1.1.3 上周文档描述少的部分

特别是：功能考虑不全或需求文档描述缺少的地方。
缺少描述：“与陌生人聊天功能”，减少添加只会聊一两句的陌生人，减少社交成本，

1.2 场景刻画

用户A：新生；

用户B：想要参加各种比赛的大二学生；

用户C：各种社团/团队的负责人对新渠道的拓展；

场景一： 新生A：初踏入校园，想要快速融入校园生活，但是又不想遇到一个人就加，毕竟很多人也就是想说一句话，添加好麻烦，不加又不行，苦恼……。

解决方案：有时只是需要问一件简单的事但是不想浪费好友位的你可以，对在同一个群的人直接私聊，而不需要添加其为好友，减少社交成本。

场景二：B：学校的各种事宜只发布在新闻通知网，可是每次登录都需要密码，好麻烦……也不知道有没有团队需要打工人……

解决方案：新闻模块可同步校级新闻+本学院的院内新闻，通过对信息的筛选+评论功能，可以快速找到自己想要的信息以及有需求的团队；

场景三：C: 有时候校园资源获取困难，身边的同学也不了解，不知道从什么地方咨询……

解决方案：用户可以根据“校园趣事榜”这个社区一线吃瓜，感受广工人的喜怒哀乐。

1.3 《构建之法》5节功能的定位和优先级

1.4 根据修改后的需求，调整任务分解WBS及相应的项目进度计划

2、系统设计

2.1 系统架构图

2.2 数据库设计

2.2.1 ER图

2.2.2 数据库架构图

3、Alpha任务分配计划

3.1 待实现的功能项

3.2 待实现功能项分解

3.3 甘特图

4、测试计划

4.1 测试总纲

由于本项目为一个校园版聊天系统，需要测试点大概如下：

1. 单元测试，确保各个模块抽象且可用。由于编程这个任务由多位成员共同完成，在 commit 前各成员需要做好单元测试，确保自己代码功能正常；封装好自己函数功能接口，确保其他成员能够轻易调用。
2. 安全测试，确保系统安全运行，维护用户信息安全。由于该系统将暴露于外界环境，当用户信息多起来之后，用户的信息安全也尤为重要，需要通过白盒和黑盒方式对系统进行安全测试。
3. 功能测试，确保系统正常运行，满足正常业务。一个聊天系统是否受欢迎挺大程度上取决于系统是否方便，能否满足人们的需求，因此我们需要通过对系统实现的功能进行测试，主要通过进行正常的使用以及模拟可能出现的特殊情况测试系统功能的完备性以及健壮性。
4. 兼容测试，主要测试前端页面能否适配多种操作系统、能否适配不同的浏览器、可视化界面是否美观。
5. 压力测试，系统正式上线前需要进行压力测试，确保正式上线时不会有崩溃、卡顿等现象。

4.2 测试日程

4.3 质量目标

1. 通过单元测试，开发人员能够实现每个功能并封装好代码，确保在交接代码时不会被其他成员打
2. 通过安全测试，系统不能轻易被入侵，市面上流通的扫描工具无法黑进我们系统，维护信息安全
3. 通过功能测试，确保系统能够正常运行，满足正常业务，解决一些已知 bug
4. 通过兼容测试，能够在 windows、mac、linux系统使用，能够在 chrome和 firefox 等主流浏览器使用
5. 通过压力测试，在测试版本能够支持100人同时在线

4.4 测试资源

• 程序猿三枚
• 测试猿三枚
• 漏洞扫描器一批
• 人眼六双
• 电脑六台
• ...