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