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

题目

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

作业提交情况情况

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

往期成绩

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

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

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

得分情况

博客 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 来写,不过成本太高,有精力的同学可以尝试。
上一篇:PHP每日签到时怎么实现


下一篇:08OC之Foundation框架