第二次作业——结对项目需求分析与原型设计

结对者：031402140李严 0314026617林瑞斌

---

需求分析与原型设计

---

NABCD模型

N（Need，需求）:

• 收集信息的过程太过繁琐，有班级总负责人需汇总每一个同学的志愿并填入excel表中，上交年级负责人，年级负责人再将信息通过excel表导入
• 时效太慢，要想完成一次选导师的任务工作，需要收集每一个人的意愿，再将信息通过复杂的算法，尽量照顾到每一个同学的情况下，把导师分配完
• 学生分配不均衡。有的老师可能有5-6，而有的老师就只有3个
• 师生之间互不了解
  学生对老师的不了解：只能够通过学院官方网站以及学长学姐口中得知，只能得知老师的方向以及老师好不好（毕设好不好过），其他几乎都一概不知
  老师对学生的不了解：老师不了解学生的学习状况以及其能力，只能在分配完之后才得知，原来我分配了几个学生，都是怎样的
• 志愿提交后就几乎不能更改。都说了，收集信息的过程太过繁琐，所以在选择导师志愿的时候就格外慎重，因为一旦提交了，就几乎不能更改

A（Approach,方法）:

• 老师学生互选的方式，可以大大缩短完整选导师的时间
• 采用安卓客户端，但起初的话web端的更好用，但由于考虑到选导师只是每年一次，使用次数较少，若在移动端得到用户的支持，可将其附加到例如福大教务处这样啊app上
• 师生之间充分了解，老师的信息中添加了一栏，是近三年来毕设课题以及优秀毕设的连接，让同学更加深刻充分地了解老师的方向，老师也可以充分了解学生的计划与经历
• 轮选时间制度，就想学习的选课制度一样，在一定的时间内学生选择导师，时间截止后由老师反选，待老师反选完后，再进行第二轮选导师，由未分配到的同学选择
• 心仪老师选择，能够在更小更精确地范围内选择导师，而不是大范围地去筛选老师，除此之外还可以利用筛选来缩小心仪老师的选择范围

B（Benefit,好处）:

• 信息获取更为方便和充实（不用再通过各种小道途径来了解老师了，咦，生物信息学是什么方向，毕设要做什么？看完老师信息后，奥~我懂了。）
• 时效性更大（就像选课一样，可以有几轮选导师的情况，但所花费时间不会太长）
• 规定的时间内可以更换自己的志愿（可能在选导师的那几天，不知何种原因不喜欢这个老师了，但是却把ta放在了第一志愿怎么办，怕什么，我可以改啊）
• 老师可以适当的挑选学生（都跟负责人说了不要那么多学生，怎么还分配了这么多，有这个app，我就有选几个学生，什么样学生的权利啦）
• 快捷方便操作简单（画面简洁，易操作，交互性好）

C（Competitors，竞争）：

• 与web之间的竞争：
  劣势：移动端需要下载使用，而web无需下载
  优势：操作简单快捷方便，在选导师的最后一天，对于有拖延症晚期的同学，恰巧身边有没有电脑，移动端就很好的解决了这个问题
  （对于移动+web的队，我只能说，可以在杀手功能上ko）
• 与师生沟通模式的竞争：
  劣势：没有良好的师生交互
  优势：师生交互只是为了更好地了解老师以ta所研究的方向，只要学生从老师信息中get到他们想要的信息，也就不会有多余的交互
  （学生人数>老师人数，在选导师的时学生可以私信老师，那么老师面对众多学生的询问，是不是都应该回答呢）

D（Delivery，推广）

该APP针对的用户是广大学生和老师，要做到推广，拥有用户，可以先与自己系的负责人安利该app，通过使用后，若获得一致好评后，可以融入到福大教务通里，毕竟一年只是用一次。

---

原型设计

原型模型设计工具

AxureRp 8.0

结对照片

登录界面

由于信息是从教务处导入，所以不需要注册

学生端----首页界面

主页面以及筛选滑块

从主页面点击查看老师信息，由于老师的信息比较多，所以带有滚动条

学生端----心仪老师界面

学生端----已选择界面

点击修改便可进入修改志愿的界面，志愿选择框里是已存的心仪老师的名字

学生端----个人信息界面

教师端----个人信息界面

点击修改资料便可进入教师个人资料修改界面

教师端----首页界面

首页面点击学生的列表便可转到学生信息界面

教师端----已选学生界面

---

效能分析

内容	需求分析	手绘原型草图+确定方案	原型工具的使用	markdown的使用+文档
时间（h）	1.5	1+0.5	6	3

---

PSP

项目耗时记录表

	估计时长	需求分析	生成设计文档	设计复审	代码规范	具体设计	具体编码	代码复审	测试	测试报告	计算工作量	事后总结
时间（%）	6	5	4	3	4	9	45	6	10	3	2	3

计划

• 估计时长：28天，将近一个月

开发

• 需求分析：找到目前的痛点，在针对用户需求的基础上加以创新
  
• 生成设计文档：有利于更清晰的了解模块和界面的衔接，便于编码
  
• 设计复审：由两人共同完成，复审则检查一些遗漏的细节便可
  
• 代码规范:查看代码规范文档，并列出我们需要注意的点
  
• 具体设计:界面设计、数据库设计等
  
• 具体编码：严格意义上老说两个人都是小白，所以编码上花费时间较多
  
• 代码复审：由于采用的结对编程，所以代码复审在模块或界面完成后
  
• 测试：采用黑盒白盒测试和真实的测试，获取测试结果并分析

报告

• 测试报告:黑盒白盒测试的报告
  
• 计算工作量：在过程中下来每天都做了哪些工作，从而来计算工作量
  
• 事后总结：总结在过程中遇到的困难，以及其改正方法和下次避免

---

小结

首次设计原型，由于对于原型工具的使用不太熟练，以及结对人员中某一位的细节强迫症，导致原型设计耗时超了原来的计划。在Markdown编译器下，排版变得更加简洁明了，与之前未用Markdown写的两篇随笔简直是渣，好吧，那个细节强迫症就是我，原始模型工具的使用并没有什么困难，然而不知为何用了6个小时来做。另外，给《构建之法》的作者点个赞，最起码读起来不像其他一下书，枯燥无味，不知不觉就看完了耶，然后需求分析和原型设计才会比较轻松，希望我的计划时间估计犹如“何书桓”八年抗日的估计一样准确，就不是不准确，也要是提前= =

---

附件

链接：http://pan.baidu.com/s/1dFxAPCP 密码：tof0

转载于:https://www.cnblogs.com/lymm/p/5880449.html