团队项目-需求分析报告

 

[toc]
组长博客链接

---

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分）

第02组-评审表

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分）

第02组-需求分析报告

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	学会画燃尽图