首页 > 代码库 > 2016/9/18结对编程之需求分析与原型设计。
2016/9/18结对编程之需求分析与原型设计。
结对学生:031402418 汪培侨
031402618 林宇晨
使用工具:Axure Rp 7.0
PDF链接:百度云 (超过10M没法上传只能百度云了) https://pan.baidu.com/s/1c282qoK
一、需求分析(采用NABCD模型)
N (Need)
年级负责人:
- 需要向同学收集各种自己选择志愿的信息,收集麻烦
- 需要通过手动汇总信息,并提交给相应的分配负责人,汇总麻烦
分配负责人:
- 根据年级负责人收集的信息,进行相应规则的算法排序,分配好相应的老师,有时候需要一定人工分配,只是单纯的分配,没有导师选择学生这一个环节
- 有时候处理的不好,可能会导致一些学生的分配不合理(当然这方面比较靠近算法)
老师:
- 只能是被动听从分配负责人的安排,失去自己选择学生的权利
- 不能够控制自己所带学生的个数,从以往来说,一般都是3个
- 对自己的学生不够了解,有时候连自己的学生的大体情况都不了解
学生:
- 对可选导师的了解不够详细,选导师的时候也是迷迷糊糊,比如说是导师的研究方向,导师的选题内容
- 学生联系导师的方式,也不能够直接去获得,比如导师电话,原有情况下,只能够通过询问其他老师,或者不同的方式去获得,缺少了透明性。
A(Approach)
本次课题我们采用了APP进行对该系统的分配
- 登入界面,我们设想是调用教务处登入的接口,进行账号密码的匹配
- 首先有一个系统推送消息,先通知学生老师开始选择的时间,然后第一步,由导师先提前登入提交自己本次所选学生人数区间,学生登入填写自己的相应资料,比如推荐利用,以及毕业方向。
- 然 后学生端的导师选择界面通过导师确定的人数,自动生成可选导师的列表,并且可以通过点击导师的姓名得到导师相应的信息,进行相应志愿的选择次序,然后选择 提交,到对应截至时间,就无法更改,期间可完成任意次的提交,最新一次的提交覆盖上面的提交。学生最多可以选择五个志愿,最少选择一个志愿。
- 接 着就是导师端,对学生进行选择,导师可以查看选自己的学生列表,并通过点击学生的姓名进入到学生信息的页面,查看学生的推荐,以及他的基本信息。导师可以 通过这些信息,对相应同学进行筛选,如果不要则点击X,如果要则点击钩,然后也是有一个截至时间,期间也可以通过多次提交,最后一次即最终确认,然后这个 选择是对应于自己当初的选择区间,不能大于最大区间,可小于最大区间。当然期间会出现一种特殊情况,就是多个老师选择了同一个学生,则通过消息在第二轮选 导师之前,讲消息发送给学生,由学生自己选择这些选择他的导师。
- 这样第一轮选导师差不多完了。
- 第二轮第三轮第四轮选导师的方式与第一轮选导师的方式一样。
- 第五轮的时候,还是通过采用提交志愿的形势,不过这次选择的方式就跟传统的分配方法一样,如果没有到自己想要的导师那里去,只能通过随机分配。
- 上述轮次中,如果在某轮已经分配完毕后,则通过系统消息反馈,导师分配已结束,不在进行下一轮的筛选。
流程图如下所示
B(Benefit)
- 可以化年级负责人收集的方式为提交,可以直接省去年级负责人这个职位
- 可以更加便捷的去了解导师,以及他们联系方式,不用在想法设法去找了
- 实现了双向选择的机制
- 减少了随机分配分到不是自己选择导师的概率
C(competitors)
- 相比于其他设计者而言,我们原型界面的设计是参考了 MOOC课程APP Coursera的界面风格,扁平化简单易操作。
- 我们的功能基本上可满足用户的需求,但是用户的满意度上,是有可以改进的地方,比如对导师进行分配时候,导师分类上。
- 加入了消息功能模块,不必向以往QQ群之类的推送消息,学生和导师即可通过消息模块进行消息信息的获取。
- 相 比较与Web端的,我觉得应该是55开,Web端通过网页查看,电脑屏幕大,可以对条目看的更加的清楚,日后可整合到教务处的功能内部,而我们APP端的 则是适应了当前时代的潮流,可以更加便捷的在何处何地,查看内部的信息,日后可以整合到福大教务通,或者西二在线之类的应用里去。
D(Delivery)
- 首先可以在我们周边的同学进行试用,如果好用的话,整合到福大教务通离去,然后可以推荐给周围学校的人,然后可以收获一定的利润。
二、原型设计
第一步
首先我们进行需求的讨论,并粗略的画了几张手画图
双方美术都很差,有很大进步空间
第二步
用原型工具Axure Rp 7.0进行我们界面的展示
我们界面大小采用了720*1280的屏幕
我们经过一起对界面标准进行了一定的统一,以及交换制作
一、首先二话不说一来肯定是登入界面
可以根据你是老师还是学生,选择对应的账号密码进行登入。
4.查看自己导师界面:当已经选上导师后,可以在该界面显示自己老师的信息
5.学生消息推送界面:可进行一些信息的公布,比如第几轮选课开始了之类的东西,以及上述所提到,多个老师同时选了同一个学生的话,也可以通过该界面,向学生进行提示
三、PSP
PSP | |
计划 | 估计需要三周的时间 |
开发 | 需求分析:实现导师与学生之间的双向选择,增强导师和学生之间的了解 |
生成设计文档:通过攥写的随笔生成PDF | |
设计复审:两个人一起交流,让文档设计更加趋于完善 | |
代码规范:条例清楚,写好注释,以及方法名字,变量名要易于理解他是用于干什么的 | |
具体设计:数据库设计,界面UI设计,代码逻辑设计 | |
具体编码:JAVA | |
代码复审:完成一个功能部分,复审一次 | |
测试:每一个部分功能完成后,反复测试 | |
记录用时 | 大概三周时间把 |
测试报告 | 把所有可能性的测试都写出来 |
计算工作量 | 感觉对于两个安卓小白来说这工作量一开始感觉不是一般的大 |
事后总结 | 还没有完成。。。 |
提供过程改进过程 | 还没有完成。。。 |
四、效能分析
前期需求分析,功能过程讨论,手绘图各自表达自己的观点 | 3H |
用Axure RP设计界面 | 5H |
后期攥写随笔 | 4H |
前期讨论的时候比较集中时间,到设计原型界面的时候,时间用的有点零散,导致有时候衔接不上,上次做的有些细节,这次没记住,我觉得以后要集中精力,找个时间连续的做下去,不能零零散散,随笔写的相对较慢,也是有参考了其他同学的文档风格。
五、感想
1、本次实验作业,我们两个初步了解了团队合作的重要性,刚开始我们还尝试着分开各自做自己端分配的任务,后面发现后面两个人所做的界面有点不兼容,虽然之前有具体讨论定义了标准,但是经验还是告诉我们,还是得面对面的交流工作才能得到想要的结果。
2、还有就是有一些细节还是要全方位的考虑,中间的时候就是突然想到某些问题,然后中间一直加一直改,导致完成效率可能会有点慢。
3、还是就是对Axure RP的使用上,笔者还是第一次使用这个软件,主要是通过队友的帮助,(队友之前有制作的经验)于是摸爬滚打也慢慢学习了这个软件的皮毛之处,还有一些小图标的获取道路。详情见此网站:http://www.iconfont.cn/collections
4、还有就是对构建之法NABCD模型的理解,我们明白了,做一个软件的动机,以及全面了解自己产品的优略,才是一个合格的团队需要考虑的方方面面。
5、还有就是一个考虑,我们两个还是一个安卓小白,虽然有了想法,但是如何把它实现出来还是一个任重道远的事情。
2016/9/18结对编程之需求分析与原型设计。