2016/9/18结对编程之需求分析与原型设计。

Posted 2020-08-09 403forbidden

结对学生：031402418 汪培侨

　　　　　031402618 林宇晨

使用工具：Axure Rp 7.0

PDF链接：百度云 （超过10M没法上传只能百度云了） https://pan.baidu.com/s/1c282qoK

一、需求分析(采用NABCD模型)

N (Need)

年级负责人：

• 需要向同学收集各种自己选择志愿的信息，收集麻烦
• 需要通过手动汇总信息，并提交给相应的分配负责人，汇总麻烦

分配负责人：

• 根据年级负责人收集的信息，进行相应规则的算法排序，分配好相应的老师，有时候需要一定人工分配，只是单纯的分配，没有导师选择学生这一个环节
• 有时候处理的不好，可能会导致一些学生的分配不合理（当然这方面比较靠近算法）

老师：

• 只能是被动听从分配负责人的安排，失去自己选择学生的权利
• 不能够控制自己所带学生的个数，从以往来说，一般都是3个
• 对自己的学生不够了解，有时候连自己的学生的大体情况都不了解

学生：

• 对可选导师的了解不够详细，选导师的时候也是迷迷糊糊，比如说是导师的研究方向，导师的选题内容
• 学生联系导师的方式，也不能够直接去获得，比如导师电话，原有情况下，只能够通过询问其他老师，或者不同的方式去获得，缺少了透明性。

A(Approach)

本次课题我们采用了APP进行对该系统的分配

1.  登入界面，我们设想是调用教务处登入的接口，进行账号密码的匹配
2. 首先有一个系统推送消息，先通知学生老师开始选择的时间，然后第一步，由导师先提前登入提交自己本次所选学生人数区间，学生登入填写自己的相应资料，比如推荐利用，以及毕业方向。
3. 然 后学生端的导师选择界面通过导师确定的人数，自动生成可选导师的列表，并且可以通过点击导师的姓名得到导师相应的信息，进行相应志愿的选择次序，然后选择 提交，到对应截至时间，就无法更改，期间可完成任意次的提交，最新一次的提交覆盖上面的提交。学生最多可以选择五个志愿，最少选择一个志愿。
4. 接 着就是导师端，对学生进行选择，导师可以查看选自己的学生列表，并通过点击学生的姓名进入到学生信息的页面，查看学生的推荐，以及他的基本信息。导师可以 通过这些信息，对相应同学进行筛选，如果不要则点击X，如果要则点击钩，然后也是有一个截至时间，期间也可以通过多次提交，最后一次即最终确认，然后这个 选择是对应于自己当初的选择区间，不能大于最大区间，可小于最大区间。当然期间会出现一种特殊情况，就是多个老师选择了同一个学生，则通过消息在第二轮选 导师之前，讲消息发送给学生，由学生自己选择这些选择他的导师。

• 这样第一轮选导师差不多完了。
• 第二轮第三轮第四轮选导师的方式与第一轮选导师的方式一样。
• 第五轮的时候，还是通过采用提交志愿的形势，不过这次选择的方式就跟传统的分配方法一样，如果没有到自己想要的导师那里去，只能通过随机分配。
• 上述轮次中，如果在某轮已经分配完毕后，则通过系统消息反馈，导师分配已结束，不在进行下一轮的筛选。

　　流程图如下所示             

    

B(Benefit)

• 可以化年级负责人收集的方式为提交，可以直接省去年级负责人这个职位
• 可以更加便捷的去了解导师，以及他们联系方式，不用在想法设法去找了
• 实现了双向选择的机制
• 减少了随机分配分到不是自己选择导师的概率

C(competitors)

 

• 相比于其他设计者而言，我们原型界面的设计是参考了 MOOC课程APP Coursera的界面风格，扁平化简单易操作。
• 我们的功能基本上可满足用户的需求，但是用户的满意度上，是有可以改进的地方，比如对导师进行分配时候，导师分类上。
• 加入了消息功能模块，不必向以往QQ群之类的推送消息，学生和导师即可通过消息模块进行消息信息的获取。
• 相 比较与Web端的，我觉得应该是55开，Web端通过网页查看，电脑屏幕大，可以对条目看的更加的清楚，日后可整合到教务处的功能内部，而我们APP端的 则是适应了当前时代的潮流，可以更加便捷的在何处何地，查看内部的信息，日后可以整合到福大教务通，或者西二在线之类的应用里去。

D(Delivery)

• 首先可以在我们周边的同学进行试用，如果好用的话，整合到福大教务通离去，然后可以推荐给周围学校的人，然后可以收获一定的利润。

 

 

二、原型设计

第一步

      首先我们进行需求的讨论，并粗略的画了几张手画图

 

双方美术都很差，有很大进步空间

 

第二步

　　　用原型工具Axure Rp 7.0进行我们界面的展示

　　　我们界面大小采用了720*1280的屏幕

我们经过一起对界面标准进行了一定的统一，以及交换制作

一、首先二话不说一来肯定是登入界面

可以根据你是老师还是学生，选择对应的账号密码进行登入。

 

二、导师端界面： （用操作步骤进行描述）

1.人数选择：首先是导师首先确定本次要收的人数，可以按两个数字，表示自己选择的区间。

 

2.导师资料的修改：即展示给学生看的信息。在第一轮选导师之前提交

3.学生选择界面：对选择自己的学生，进行选择，打勾则表示需要，打叉则表示不要该学生。选学生中

4.查看学生信息的界面：通过点击上述选择学生的学生姓名可以链接到该学生界面。

5.查看学生界面：查看已经是自己学生的界面，列表中都是自己的学生。每轮选导师后会更新。

6.消息界面：即定期传递给导师的信息，即第几轮选课开始，还有自己的注意事项。

 

 二、学生端界面： （用操作步骤进行描述）

1.自我推荐界面：首先学生先进行自我推荐信息的填写，方便导师对自己的了解

2.选择导师界面：即选导师开始的时候，进行的选择，可通过下拉框，选择对应的志愿编号

3.老师信息的查看，点击上述的老师可以链接到老师对应的界面中去，方便了解老师

 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、还有就是一个考虑，我们两个还是一个安卓小白，虽然有了想法，但是如何把它实现出来还是一个任重道远的事情。