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