2022秋软件工程第一次结对编程时作业

软件工程	FZUSDN社区
作业要求	2022秋软件工程第一次结对编程作业
作业目标	使用NABCD进行需求分析并进行原型设计
成员学号	032002217
成员学号	072003403

墨刀链接

墨刀原型

需求分析NABCD模型

Need

老师需求

• 要求支持多班级
• 尽可能总时间少不影响上课（打开迅速，持续时间短，关闭迅速）
• 防止作弊代签等
• 老师端口有登记迟到功能（第一次签到之后下课之前来说明情况的）

学生需求

• 不希望有锁屏计时功能（很多学生上课要查看ppt或拍照）
• 尽可能耗时短（签完就关）
• 希望能支持多班级（尽量各个课程点名应用统一）
• 不希望有请假功能（反正都要写请假条给导员，多此一举，这样老师还要跟导员确认。不如让学生出示请假批复条）

综合新增

• 老师端要有计数功能，没有签到的缺课次数加一，按时出示请假条的次数减一
• 老师端要有检索功能，学生带请假条或有特殊原因，老师能够按学号检索该学生并修改缺课次数
• 老师端口要能即时发起点名，为了加强防作弊功能，并防止有人签到就离开
• 学生端口要有对应课程上课情况（缺课次数），有则警醒，无则加勉

Approach

• 小程序分为教师端和学生端，教师应事先登入创建课程班级。例如：软件工程（1）班，数据库（2）班等。老师需要点名时就直接进入对应班级点击“开始点名”生成点名二维码。
• 学生登入时完成微信和姓名学号等信息的绑定，并加入对应课程，上课时进入小程序扫码签到。

Benifit

防作弊功能强大，功能简洁方便，学生端口只显示对应课程的缺课信息和迟到信息，并不额外添加显示请假信息或上课时间地点等冗余功能。同时又具备了点名所要达到的一系列规范，不只是点名，但又不过分扩充。例如，迟到10分钟算缺课确实不合理，计入迟到才符合师生的需求。但请假等特殊事件既不符合实际需求（还是要经过导员），也不常用（大多数学生平常都用不到）。

Competitors

• 微信上已有许多点名小程序了，并且看起来很简洁，点名功能也很齐全。但是它们都不够简洁，现在使用手机签到的都是大学生，根本不需要搞什么使用教程，如果有，说明还不够简洁。
• 为了让一个班几十人到最多四百人（学院点名）都能快速进入小程序，尽量并发完成点名，精简是很有必要的。所以“我的”一栏去掉，学生端最多十来门课，往下一拉，都能看到。这样能在有限的负荷下，尽快刷新学生信息，减少一两秒时间。
• 做到从老师开始点击进入小程序开始，到学生点击进入小程序点名完毕，能缩短的时间就缩短。缩短的时间能够做到再发起一次点名（比如课间下课），这样的防作弊更为有效，而且更为有竞争力，一个对用户而言用完就关的东西，用户在乎的永远是浪费了用户多少秒的人生，而不是留意它的功能有多么强大。

Delivery

首先想到的时自己的任课老师，先向他们他们推广使用，进行一段时间的深入评测。当然也可以发空间发说说，在群里发链接等（个人觉得这作用不大，毕竟还是要任课老师来决定）。一段时间后没问题，再向朋友任课老师推广，然后看具体符不符合其它环境下的实际需要再决定推广与否。毕竟这个小程序设计针对普适性活动，如果要有更多的、额外的功能，并不能逐一符合要求。

PSP表格

PSP	Personal Software Process tags	预计耗时分钟数
Planning	计划	20
Estimate	评估完成任务时间	20
Development	开发（实际包含学习技术）	300
Analysis	需求分析	60
Design Spec	生成设计文档	30
Design Review	设计复审	10
Coding Standard	代码规范	30
Design	具体设计	20
Coding	具体编码（实际包含学习时间）	300
Code Review	代码复审	30
Test	测试	100
Reporting	报告	30
Test Report	测试报告	30
Size Measurement	计算工作量	30
Postmortem & Process Improvement Plan	事后总结	20
Total	合计	1030

总结

我们在实际设计墨刀模型时发现，很多具体功能并不能得到充分展示：

• 二维码的间隔刷新机制
• 班级名单以缺课次数降序排列，其次以迟到次序排列
• 学生扫码后的签到页面的展示
  本次设计以简便为基本原则，但具体来实现发现很多功能不得不新增，不然出现某些情况让用户体验变差，终究是要有所调整。