首页 > 代码库 > 结队项目--需求分析与原型设计

结队项目--需求分析与原型设计

结对者:031402324 巫振格 031402338 解宇虹

pdf文件:http://files.cnblogs.com/files/gzwu/作业.pdf

工具:Axure Up 8.0

烦恼:
1.过程繁琐,数据信息多级传递,费时费力,过程不透明
2.大部分学生与老师都只能被动分配,难有自由选择
3.学生无法与老师沟通,难以清楚的了解到导师的研究方向与项目,也为之后毕设埋下隐患
4.难以时时了解到选每个导师的学生数,可能导致学生扎堆选某一个老师,而有的导师却少有人问津
5.每个导师对于期望的学生数不同,难以满足各自心愿

NABCD模型:
竞争型需求分析的框架
N(Need,需求)
信息收集:传统方式太过繁琐,费时费力,急需一个简便迅速的方式代替
自由选择:传统方式大部分师生都是被动分配,需要一个师生都能够有主动权的方式
互相了解:传统方式学生很难准确了解到老师的主攻方向和项目,因此需要一个交流的平台实现沟通
时时更新:传统方式学生不能知道有多少学生跟你选了同一老师,在选择的时候是茫然的,因此需要一个平台能够时时显示剩余名额等数据
自主:传统方式不能实现符合每个老师心意的学生人数,因此能够有数据统计实现教师心怡学生人数这也是一个需求

A(Approach,方法)
信息了解:学生教师的基本信息发布在个人平台上,教师可以通过平台了解学生信息,学生亦可以了解教师信息
私信:通过师生交流互相了解,主动选择
互选查看:师生可以时时查看中选情况
退选:当学生或者老师在规定时间内有权退选,中选信息也是在最后才发布,主要为了防止学生或导师意愿变更
安卓客户端:采用安卓客户端方式,界面操作简单易懂

B(Benefit,好处)
信息获取迅速:平台信息直接浏览(不用到处询问)
选与退选方便:一个按钮解决问题(不在烦恼word或者excel)
师生沟通便捷:通过平台交流了解(不用打电话,发邮件)
最新的数据:导师剩余名额一目了然(有效避免扎堆)
操作简单便捷:只要一小会,导师在我手

C(Competitors,竞争)
这么多码神,学霸都在做这个,竞争压力不言而喻
做好自己,做出特色,做出亮点

D(Delivery,推广)
这个目前很难实现,一般同学之间互相介绍吧(一脸嫌弃)

原型设计

技术分享

技术分享

学生界面:

技术分享           技术分享

技术分享          技术分享

技术分享             技术分享

技术分享              技术分享

教师界面:

技术分享             技术分享

技术分享                技术分享

效能分析
因为还没有编码,所以也就还没考虑到降低程序代码复杂度

PSP(Personal Software Process,个人软件过程)

技术分享

因为编码工作尚未真正开始,很多东西只能是预估,只有在编码过程中不断记录更新,学习

总结:过程不算顺利,从一开始在决定是Web端还是安卓端我们就讨论了许久,一直觉得Web端会相对容易一些,毕竟和上学期的数据库有些类似,但仔细想象过后,我们还是决定采用没有任何经历的安卓端,要说为什么的话,也许就是当初选择栋哥的原因吧。原型设计我们两人讨论了许久,从用笔画草图到软件绘图,都花费了相当的一份心血!然而这只是开始,后面的路更加难走,对于没有学过Java的我们,可能似难于上青天,但相信我们会走到最后!当然栋哥要带飞啊

结队项目--需求分析与原型设计