团队作业6——复审与事后分析
团队作业6——复审与事后分析
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 软件工程 |
| 这个作业要求在哪里 | 作业要求 |
Alpha阶段项目复审
团队复审人：彭正嵩
| 小组的名字和链接 | 优点 | 缺点，bug报告（至少140字） | 最终名次（无并列） |
|---|---|---|---|
| Born To Win | 1.题目的增加、修改、删除 2. 管理员点击编辑数据进入对应题目的数据列表 3.管理员可以增添，修改删除对应题目的数据 |
1.前端后台的数据请求时数据格式不统一 2.登陆时不合法用户(没有在数据库内)也能登陆 3.用户新建数据后，没有展示在数据列表，但是在题目详情有展示 4.在题目修改和数据修改部分，仅不改的地方会修改为空 |
1 |
| 四带二 | 1.图片管理功能：随时更换顺眼的头像，拥有一天的好心情。 2.个人资料管理：用户可随时更改登录密码，保证用户信息不被泄露。 3.博客管理：用户可随时随地增、删、改博客信息，通过指定用户id或博客id的形式查看该用户博客信息。在博客广场，可以看到所有用户的博客内容，浏览一篇篇博客，发现有趣的内容， 4.界面简洁，功能简单，脱去繁重的花里胡哨的功能，仅保留一个博客网站的基础功能，保持初心，专注内容。 |
1.删除博客功能后没能与数据库连接上。 2.生成图片url过长导致无法存入数据库、不可跨域、本地查看不安全 3.修改博客后提交，接口返回已成功，但博客管理页面还是原博客内容 4.提交成功后，虽有提示但是博客输入框没有做到清空内容，易造成用户误以为未提交成功。 |
2 |
| PH-VIP | 1.用户注册及数据保存 2.可选关挑战 3.游玩乐趣高 |
1.人物不同动作的不同动画没做出来 2.这种情况不能做到封闭 3.偶尔会出现选关后人物突然跳到屏幕顶端再下降 4.窗口全屏没能设置好 |
3 |
| 二佬带带我 | 1.卡片的上传修改删除与卡包下载删除 2.艾宾浩斯抗遗忘曲线算法 3.卡片的背诵界面 4.卡包的共享 |
1.创建卡包页面闪退 2.获取不到卡包内容 3.创建卡包失败 |
4 |
| QAQ~ | 1.Web项目API的管理功能。包括API的创建、编辑、统计功能，项目成员共享、分组以及API操作日志功能。 2.Web项目API的测试功能。测试功能包括根据API发送请求，获取并格式化返回结果 |
1.状态码文档的分组页面：新建状态码到对应分组，只出现在所有状态码一栏，并未真正归入到相应分组里； 2.权限管理页面：对分组进行编辑操作后，出现前端开发人员，后端开发人员等分组； 3.离开权限管理页面再重新回到权限管理页面，所有分组消失； |
5 |
| 这段代码到底哪里不队 | 1.显示打卡信息、学习按钮和复习按钮。用户可修改所需词典和每日打卡单词数，查看当前日期，当日打卡剩余单词数，已打卡天数以及当前词典打卡进度，通过两个按钮进入对应页面进行学习 2.用户点击复习模块后可通过做题巩固背过的单词、查看当前单词的信息 |
1.存在可点击元素的响应区域过小 2.ipad页面显示不全，出现下拉条 3.修改信息弹窗及主页修改打卡目标弹窗中的输入框部分被遮挡 |
6 |
| Bugames | 1.音乐播放系统 2.读取地图与音效文件 3.基本音游判定效果 |
1.整体操作很难，因为判定比较短,歌曲bpm比较快 2.暂无人物上下跳跃动画 |
7 |
| 绝不加班 | 1.游戏可玩性较高 2.怪物设计有趣 3.游戏玩法新颖 |
1.怪物移动轨迹与预期不相符 2.角色、怪物的碰撞形状与图片差异过大 |
8 |
| gdut_名媛 | 1.能够让用户在平台上面发布任务。 2.用户能够在平台上面接单。 3.通过学号构建信誉信息，给双方提供保障 4.后台不会隔三差五崩坏，UI给用户体验舒服。 |
0信用分可以变成负数；用户提交订单后未跳转至订单详情页 | 9 |
| PG | 1.阅读界面简洁方便 2.搜索引擎强大，搜索小说方便 |
在进行用户登录注册功能的时候容易卡机 | 10 |
| 梦之航 | 1.课程数据真实有依据，源自教务处； 2.我们在程序设计初步完成后面向部分大学生开放，并获取他们的体验感受，然后对程序进行维护优化，来强化程序的可靠性、可维护性； 3.课程表，是帮助学生了解课程安排的一种简单表格，在大学，提倡自律性学习，而课程表则能很好地帮助大学生提前获取课程安排从而有效率地规划自己的预习计划。 |
贴吧发布页面按钮修改样式无法渲染 | 11 |
| 智商OverFlow | 1.失主可以在平台上发布丢失的学生卡或者其他物品的相关信息的帖子 2.用户可以查看自己发布的信息的状态 3.失主可以通过搜索来寻找是否有与自己的失物相似的丢失物品的信息 |
在写代码的时候，没有想得足够周到，容易出现异常，鲁棒性不高 | 12 |
| fumbleFish | 1.可以对实际端口进行扫描 2.有图形化界面，即使是普通用户，也可以进行简单操作 3.通过扫描，可以让我们确切的了解到自己的网络环境，这是很有价值的 |
1.在前台点击“运行”之后，由于等待后台运行结果存在一定的时间，在等待阶段前台窗口会有些卡顿，难以让用户满意 2.对用户输入的数据仍然无法做到错误鉴别，无法完全确保程序运行时的数据格式都是正确的，这样会增加程序报错的次数 3.指定了正确的域名之后，google子域名查询有时候还是查不出结果 4.指定了正确的域名之后，子域名查询结果可能过少的问题 |
13 |
| 广工扫“蝗”小分队 | 1.大部分大学新生想要购买的东西许多，也有许多购买的需求，所以我们这个软件就是为了便利学生当前的需求。 2.只要能让它推向市场，学生受到优惠与便利，效果会很明显。 3.只要能给大学新生带来便利，满足他们的需求，效果会很明显。 4.这个软件就是为了让新生可以更快的适应大学生活 |
1.前端显示界面 展示 2.商品支付系统页面是否跳转成功 3.搜索相关商品，展示搜索返回的商品列表 4.注册登陆功能是否正常 5.个人购物车有无 6.个人购买的商品是否有记录 |
14 |
事后诸葛亮分析
会议照片
项目Postmortem结果
整理:彭正嵩
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
是
2.是否有充足的时间来做计划?
是
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
主要通过微信解决，大家比较随和，没有较大冲突。
计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大多数做完了，有小部分因为时间不足没有完成。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
没有
3.是否每一项任务都有清楚定义和衡量的交付件?
有清楚定义 但交付件因能力受限只能做到基本功能
4.是否项目的整个过程都按照计划进行?
前半部分是，后半部分按紧急程度优先完成
5.在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，原来认为没有必要，后来发现还是有用的。主要是各人进度不一，有些模块不断地有一些小问题，花了很长时间才能做好。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
缓冲区延长
资源
1.我们有足够的资源来完成各项任务么?
有
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
开始精度很粗略，后来随着项目任务的加重，大家只顾得上干活，没时间考虑精度问题。
3.用户测试的时间，人力和软件/硬件资源是否足够?
用户测试人数不够
4.你有没有感到你做的事情可以让别人来做（更有效率）?
没有
变更管理
1.每个相关的员工都及时知道了变更的消息?
是的 通过微信交流
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
全体投票法
3.项目的出口条件（Exit Criteria）是否得到清晰的定义?
是的
4.对于可能的变更是否能制定应急计划?
能
5.员工是否能够有效地处理意料之外的工作请求？
能
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在工程还未开始时 由彭正嵩来完成，是
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有 由专人全权负责
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
没
4.什么功能产生的Bug最多，为什么？
选择转盘产生的bug最多
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
是
测试/发布
1.团队是否有一个测试计划？为什么没有？
我们有测试计划，而且因为有了计划，测试人员好像不再像无头苍蝇胡乱测试
2.是否进行了正式的验收测试？
是
3.团队是否有测试工具来帮助测试？
有。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
用手机运行小程序进行测量 有用
5.在发布的过程中发现了哪些意外问题？
无
假设团体总分100分
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 彭正嵩 | 队长 | 20 | 编写博客，设计页面 |
| 沈权斌 | 前端开发 | 22 | 前端开发 |
| 区德明 | PM | 19 | 统领工作安排，召开会议 |
| 李文静 | 后端开发 | 20 | 后端开发 |
| 杜维佳 | 前端开发 | 19 | 前端开发 |
