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

Posted 2020-08-09 火尘降

结对者：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）
师生沟通便捷：通过平台交流了解（不用打电话，发邮件）
最新的数据：导师剩余名额一目了然（有效避免扎堆）
操作简单便捷：只要一小会，导师在我手

Ps解决选课冲突：不论学生选择的同一导师的人数是否多于这个导师所带的学生人数，教师界面中的学生排列都是先按志愿排列的，志愿相同照绩点排列；如果多个教师选择同一名学生，则按学生的志愿先后确定导师。

C（Competitors，竞争）
作为app，相对web端，界面的信息不能太多，我们能做到的尽量使简洁，明了；相对其他同类app，我们将尽量突出自己app的UI界面，完善功能，令用户满意。
做好自己，做出特色，做出亮点

D（Delivery,推广）
可以先在自己学院老师之间推广，如果用户满意的话，自然可以通过学校的各个平台推广。

 

四、原型设计

学生界面：

           

          

             

              

教师界面：

             

                

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

PSP（Personal Software Process，个人软件过程）

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

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