团队项目-需求分析报告
目录
组长博客链接
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 | 学会画燃尽图 |