第02组 团队项目-需求分析报告
2019-10-27 22:48 君莫笑哈哈哈 阅读(126) 评论(0) 编辑 收藏 举报目录
组长博客链接
1. 整体计划安排（2分）
| 时间段 | 阶段任务 | 完成情况 |
|---|---|---|
| 9.25~10.23 | 确定小组选题，并完成展示 | 已完成 |
| 10.18~10.28 | 需求分析，并完成展示 | 已完成 |
| 10.27~11.02 | 团队编程、Alpha冲刺前期准备 | 未完成 |
| 11.03~11.15 | Alpha冲刺 | 未完成 |
| 11.16~11.20 | Beta冲刺前期准备 | 未完成 |
| 11.21~11.29 | Beta冲刺 | 未完成 |
| 11.30~12.13 | 测试并完善优化，制作用户手册，总结 | 未完成 |
2. 团队分工（5分）
2.1. alpha 版本需要做的事情
基本实现先前规定好的功能需求
2.2. 分工明细及 TODO list
| 组员 | 分工 |
|---|---|
| 张越洋 | 产品经理+前端 |
| 邓志雄 | 产品经理 |
| 林文涛 | 前端+小组长 |
| 陈文彬 | 前端 |
| 林宏海 | 前端 |
| 龚洋林 | 前端 |
| 杨世杰 | 后端+小组长 |
| 林小棠 | 后端 |
| 苏伟欢 | 后端 |
| 王淇弘 | 后端 |
2.3. 燃尽图
3. 思维导图（2分）
4. 团队贡献比例评估（2分）
描述为撰写需求规格说明书的工作流程、组员分工、组员工作量比例
评估标准：被分配的任务的完成质量
质量：优（↑）、符合预期（-）、差（↓）
| 组员 | 百分比 | 分工 |
|---|---|---|
| 杨世杰 | 14% | 评审表设计（↓）、小组评审（↓）、组织后端讨论（↑）、回答别的小组对我们的提问（-） |
| 林文涛 | 13% | 类图设计（↑） |
| 林小棠 | 13% | 类图设计（↑） |
| 林宏海 | 11% | PDF制作（↑） |
| 陈文彬 | 11% | 思维导图设计（↓）、回答别的小组对我们的提问（-） |
| 龚洋林 | 10% | PDF制作（-） |
| 张越洋 | 10% | 博客撰写（↓）、PPT展示（↓）、任务分配（↓） |
| 王淇弘 | 8% | PPT制作（↓） |
| 邓志雄 | 5% | 思维导图设计（↓） |
| 苏伟欢 | 5% | 小组提问（↓） |
5. 评审表格设计（1分）
6. UML（10分）
6.1. 用例图
用例图描述
(1)描述了我们软件必须完成的任务，定义了必须完成的软件功能;
(2)基本呈现用户与用例之间的具体关系;
(3)基本表达系统的基本功能;
(4)基本表达系统的具体行为。
6.2. 类图
任务悬赏类图描述:
(1)描述了我们软件必须完成的类、接口以及它们之间的静态结构和关系。
(2)类的部分:用户、接单人、用户中心、排行榜、市场、任务、发布者、通讯、评分。
(3)关系部分:依赖、实现、泛化、关联。
校园百科描述:
(1)描述了我们软件必须完成的类、接口以及它们之间的静态结构和关系。
(2)类的部分:用户、百科信息、用户私聊信息、消息栏、信息展示栏。
(3)关系部分:依赖、关联。
6.3. 活动图
活动图描述:
(1)校园百科搜索
(2)任务悬赏发布任务、承包任务
6.4. 状态图
描述了校园百科中社区回答问题的状态↓
任务悬赏中发布任务的状态↓
任务悬赏中草稿箱编写状态↓
任务悬赏中任务发布及承包状态↓
6.5. 实体关系图
7. 工具选择（2分）
StarUML
8. 使用后对工具的评价（2分）
免费好用！
9. 答辩总结（9分）
9.1. 求出本组的现场答辩得分
去除最高总分，最低总分，求平均分（保留2位小数）
| 平均分 | 第1组 | 第2组 | 第3组 | 第4组 | 第5组 | 第6组 | 第7组 | 第8组 | 第9组 | 第10组 | 第11组 | 第12组 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 47.64 | 51 | 53.4 | 47.8 | 没打分 | 49.2 | 46.8 | 42 | 46.8 | 45 | 52.2 | 48 | 38.4 |
9.2. 回答其他小组对本小组的提问
每少回答一点，该项得分扣除5%，扣完为止
| 提问小组 | 问题 | 解答 |
|---|---|---|
| 1 | 如何防止别人恶意刷赏金排行榜呢？ | 若有可疑刷榜行为我们会进行核实(如发单接单均为同一人，且短时间内数量多)若真实存在会采取封号 |
| 2 | 无 | |
| 3 | 对于任务发布的真实性如何审查，如何避免有人恶意发布虚假任务以至于让接任务的同学浪费时间 | 前期只能进行人工审核任务数量，如一个用户有大量未结算订单，核实恶意发布会采取封号 |
| 4 | 无 | |
| 5 | 对于任务的定义是否太过广泛会导致到时候消息过于杂乱？ | 任务均会进行分类，可以只查看指定类型的任务 |
| 6 | 如何防范一些违法的任务发布？ | 前期人工审核任务，发现会采取封号，后续会进一步采取任务发布时的关键词检测。 |
| 7 | 发布任务与接收任务双方产生分歧平台如何处理？ | 价格均在发布消息时会公开，产生分歧时平台进行仲裁，双方提供协商记录，平台进行判定即可。 |
| 8 | 如果物品出现受到损坏或者是丢失的情况，而且对方的信息有缺真实性时，如何解决？ | 在任务过程中产生的分歧可申请平台仲裁，参见上条。信息均会在后台进行审核(发布敏感任务会要求上传学生证等信息) |
| 9 | 平台对任务怎么做到监管避免奇怪的任务。 | 前期人工审核，后期逐渐跟进发布任务时的关键词审核。 |
| 10 | 无 | |
| 11 | 如何杜绝违法的任务？ | 前期人工审核，后期逐渐跟进发布任务时的关键词审核。 |
| 12 | 对于任务的发布是否有审查机制？校园百科的编辑权限是怎样的？ | 前期人工审核，后期逐渐跟进发布任务时的关键词审核。编辑权限:由创始人所有，他人若有异议在底下进行评论，词条创建者需在指定时间内回应是否采纳并修正，若超时平台会进行修正/回应。 |
9.3. 需求分析报告的修改
根据答辩中其他组提出的意见和建议修改完善本组需求分析报告，并标明修改之处
| 指出的问题 | 修改 |
|---|---|
| PDF中存在大量格式错误 | 订正 |
| 缺少平台的审核、仲裁机制，容易被钻空子 | 增加平台的人工审核、关键词审核机制 |
10. 《需求规格说明书》（1分）
11. 遇到的困难及解决方法（2分）
| 困难描述 | 做过哪些尝试 | 是否解决 | 有何收获 |
|---|---|---|---|
| 时间非常紧张 | 翘课、通宵 | 有 | 年轻真好 |
12. PSP（1分）
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 60 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 60 |
| Development | 开发 | 880 | 1380 |
| · Analysis | · 需求分析 (包括学习新技术) | 200 | 300 |
| · Design Spec | · 生成设计文档 | 500 | 800 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 100 | 150 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| · Design | · 具体设计 | 50 | 100 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 75 | 90 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 15 | 30 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 60 | 60 |
| 合计 | 985 | 1530 |
13. 学习进度条（1分）
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 0 | 0 | 无 |
| 2 | 300 | 300 | 5 | 5 | 不应毫无规划就打代码 |
| 3 | 1100 | 1400 | 23 | 28 | 学习网络接口的使用、学习pygame模块的使用 |
| 4 | 0 | 1400 | 15 | 43 | 学会画燃尽图 |
