【1414软工助教】团队作业3——需求改进&系统设计 得分榜

题目

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

作业提交情况情况

本次作业所有团队都按时提交作业。

往期成绩

个人作业1：四则运算控制台	结对项目1：GUI	个人作业2：案例分析
结对项目2：单元测试	团队作业1：团队展示	团队作业2:需求分析&原型设计

总得分映射到百分制的排名

得分情况

博客	Coding	团队	个人项目1	结对项目1	案例分析	结对项目2	团队展示	需求分析&原型设计	需求改进&系统设计	总分	映射到[50-100]
092	092	六六六	5.2	8.5	9.75	5.1	7	4	5.25	44.8	91
093	093	Sugar Free	3.2	9.5	6	3.81	6.25	5.25	4.5	38.51	76
094	094	Sugar Free	6.6	9	4.75	2.81	6.25	5.25	4.5	39.16	78
095	095	六六六	1	8.5	3	3	7	4	5.25	31.75	61
096	096	六六六	7.4	8.5	10.5	4.63	7	4	5.25	47.28	97
097	097	六六六	4.6	8	11	3.5	7	4	5.25	43.35	88
098	098	Runing Guys	6.4	8	11.5	4.44	7	5.5	2.5	45.34	92
099	099	为所欲为	2.6	8.5	8.25	2.69	7	6.75	3.5	39.29	78
100	100	为所欲为	5.2	8.5	13	1.94	7	6.75	3.5	45.89	93
101	101	Runing Guys	5.6	10.5	13.5	3.88	7	5.5	2.5	48.48	100
102	102	Runing Guys	4.4	10.5	6.5	1.63	7	5.5	2.5	38.03	75
103	103	Sugar Free	4.4	10.5	-2	1.44	6.25	5.25	4.5	30.34	57
105	105	为所欲为	4.6	2.5	7.75	0.31	7	6.75	3.5	32.41	62
106	106	Runing Guys	6.6	10.5	4.5	1.38	7	5.5	2.5	37.98	75
107	107	Runing Guys	7.2	10.5	6	5	7	5.5	2.5	43.7	88
108	108	为所欲为	3	0	7.25	0.31	7	6.75	3.5	27.81	51
109	109	Runing Guys	5.2	10	3	2.63	7	5.5	2.5	35.83	70
110	110	217萌萌哒	5.8	9	4	6.25	5.25	3.5	2.75	36.55	72
111	111	217萌萌哒	5	9	3	2.56	5.25	3.5	2.75	31.06	59
112	112	217萌萌哒	4.4	8.5	6	5.25	5.25	3.5	2.75	35.65	70
113	113	217萌萌哒	5.4	9	-1	2.06	5.25	3.5	2.75	26.96	50
114	114	217萌萌哒	4.6	9	6.75	3.31	5.25	3.5	2.75	35.16	69
115	115	六六六	5.6	6	4.75	0.94	7	4	5.25	33.54	65
116	116	为所欲为	4.4	7	4	0.94	7	6.75	3.5	33.59	65
117	117	217萌萌哒	4.8	9	4.75	2.31	5.25	3.5	2.75	32.36	62
118	118	六六六	5.6	7.5	5.75	2.94	7	4	5.25	38.04	75
119	119	Sugar Free	1.6	2.5	11	0.31	6.25	5.25	4.5	31.41	60
120	120	Sugar Free	3.2	9.5	9.25	5	6.25	5.25	4.5	42.95	87
121	121	Sugar Free	1.4	11	4	1.94	6.25	5.25	4.5	34.34	67

评分明细

	需求&原型改进							系统设计		Alpha任务分配计划		测试计划	合计	附加分
	使用前/后的场景	规格说明书的不足	改进的内容	用户场景描述	功能四象限	WBS	估计任务时间	架构设计	数据库设计	需求分析为主	设计为主	测试计划		各种调查方式
团队/分值	1	0.25	0.75	1	0.5	1	0.5	1	1	1	1	1	10	1
Runing Guys	0.25	0	0.25	0.25	0.25	0	0.25	0.25	0	0.25	0.25	0.5	2.5	0
217萌萌哒	0	0	0	0	0	1	0.25	0	0	0.5	0.5	0.5	2.75	0
六六六	0.25	0.25	0.75	0.25	0.25	0	0	0.25	1	0.75	0.5	1	5.25	0
Sugar Free	0.25	0.25	0.75	0	0.5	0	0	0	1	0.75	0.5	0.5	4.5	0
为所欲为	0.75	0.25	0	0.5	0.25	0	0.25	0.25	1	0	0	0.25	3.5	0

评分标准

检查项		分值
需求&原型改进	使用前的场景（痛点） 使用后的场景（痛点的解决）	1	主要回答： 1.客户的问题的场景我们是不是真的找到了？ 2.我们为产品设定的使用场景是否真的会发生？ 如果找不出有与目标用户沟通的痕迹，比如只是单纯的重复之前说过的用户痛点，可给 0 分或给低分
	描述上次规格说明书不足的地方	0.25
	规格说明书具体改进的内容发布在随笔上	0.75
	用户场景描述	1	以完成某个目的为导向，按顺序描述各个操作步骤得1分。参照《构建之法》P211的例子。 对登陆注册过于详细而主要功能简单扣0.5； 好几项目的混合的用户场景扣0.25分
	功能四象限	0.5	将登陆和注册放到第一象限的不得分； 最能体现APP竞争力的功能没放在第一象限扣0.25分； 将基本功能放在第一象限扣0.25分； 没有使用四象限表格的形式扣0.25分；
	WBS	1	子节点覆盖父节点包含的所有内容 0.5分； 叶子节点的粒度天内能完成0.25分； 按模块划分0.25分； 完全见不到WBS结构的倒扣1分
	各成员估计完成任务需要的时间	0.5	给出的是这次作业的时间倒扣0.5分； 没有标注成员对应哪个部分扣0.25分；
系统设计	架构设计	1	有分层且与项目模块结合0.5； 各种图示建模0.5；
	数据库设计	1	表结构 或 ER图 至少要有一个
Alpha任务分配计划	以需求分析为主，选择和排序本次迭代需要实现的订单条目	1	所列任务组合起来不能够使应用达到差不多能用，扣0.25分； 缺少杀手功能的初步实现，扣0.25分； 由于题目没有指明哪种排序方法，不对排序评分； 任务粒度太大扣0.25分； 任务量过少，扣0.25分； 如果描述的不是 Alpha 版本的功能，该项不得分；
	以设计为主，确定系统设计方案和工作内容	1	没有分配任务给团队成员，扣0.25分； 没有描述针对各个任务所要采用的技术方案，扣0.5分
测试计划	测试计划	1
合计		10
附加分	用户痛点部分使用各种调查方式	1

助教说

1. 每当我看到一次作业发布时，其实已经做好 同学们不会认真去看作业要求 的准备了。这也不完全是同学们的问题。
   
   由于没有理解好题目的要求，导致的作业做不到位，极大地影响了分数。
   
   如何走出这个困境？除了寄希望于发布的作业能够有更加清晰的描述，同学们能做的改进就是向老师和助教问清楚作业的要求（当然也可能有其他方法）。
   
   明确作业的要求，可以说和软件工程中的“确认需求”相似。但是考虑到同学们刚接触软件工程，知识迁移的难度极大。因此我提出这样的思路，希望对同学们能有帮助。
2. 是否阅读作业中所列材料，也是一个问题。从实际情况看来，有一部分同学没有去看这些扩展链接，甚至《构建之法》里的内容都没有去看。
   
   例如团队作业2——需求分析和原型，里面的NABCD仍然没有做好。这里要体现的是和竞品的比较，而应该有不少同学没有去看书上的这部分内容，仍然忽视有竞品的存在而只描述自己作品的优点。
   
   要想少做无用功，就要清楚应该往哪个方向去做。否则发现自己辛辛苦苦做的东西居然没有得到 自己预想的 相应的回报，也是很受打击的。
3. 软件需求规格说明书的问题在于，没有把重点的部分做好。当然，如何知道重点是另一个问题了……
   
   重点的部分需要花时间和精力去做好，非重点的部分可以少做，甚至在时间有限的情况下可以不做，这些扣的分完全可以通过做好重点部分来弥补。
   
   软件需求规格说明书的重点有四个：
   • 软件功能
     
     描述软件都有哪些功能
   • 原型图
     
     让读者从视觉上比较直观地感受这些功能
   • 用户场景
     
     让读者从流程上感受这些功能
   • 验收标准
     
     作为软件开发过程中的依据，使得开发的时候有着明确的目标。到底开发得怎么样，如何来衡量？可以通过验证是否符合验收标准所描述的内容来衡量。
4. 文档的格式推荐使用 Markdown 。如果觉得 Markdown 的排版不适合写这种文档，例如文档第一页的那种效果，可以将 word 转换成 pdf 文件。这个可以在 Office 中通过 “另存为PDF” 来得到。
   
   最厉害的情况是用 LaTeX 来写，不过成本太高，有精力的同学可以尝试。