软工实践2019第四次作业

软件工程实践2019第四次作业——结对编程的需求分析与原型模型设计

031702112 蓝飞鹏
031702349 吴斯桓
写在前面：
       本次结对完成需求分析与原型开发，怎么说呢，这次不像以往，每次都是一个人孤军奋战、埋头拉车。有时候市场陷入崩溃死胡同，想不出任何好的灵感和道路。但是这次的结对合作，让我们两个人之间有了更多的交流机会，在交流中迸发出更多的灵感，提高效率。并且两个人之间还会彼此的监督和促进。实现了真正意义上的1+1>2。
需求分析：

>>>Need<<<

    nbsp;   老师的困扰：都说铁打的营盘流水的兵。老师，总会经历结识新生、相处多年的本科生和研究生毕业、又一批新生加入等年复一年周而复始的过程。这既是老师这个职业的悲哀，也许也是老师这个职业有活力的地方。作为老师，夜深人静时，偶尔会想，几年前毕业的某某学生，现在怎么样了啊；某某学生，在哪里工作啊，发展如何啊。但是又不好主动去问。不知道是不便打扰，还是老师太矜持，还是想想就够了而答案不重要。也许默默地关注着学生的动态就够了；不一定非得等到教师节，才收到学生在问候中也许包含的关于现状的描述。
    萌新学生的困扰：作为萌新学生，我不知道要选择哪个老师作为我的毕设导师，或选择哪个老师作为我的研究生导师。除了了解导师的个人主页介绍、和老师邮件沟通以外，其实最有效、客观、避免踩坑的方法是和老师现在带的或之前带的已经毕业的学姐学长交流一下，听听他们对于老师的评价、看法和对我的建议。这也许对我选择老师会更有帮助呢。看看已毕业的学姐学长们的去向和现状，我也能知道我加入实验室后，我今后可能的发展前途和趋势是什么样的。
    在读学生的困扰：学姐学长们都是谁啊，该怎么联系啊。我要找工作了，应该如何准备公司面试或进一步深造啊，有没有同门学姐学长可以给我内推的机会啊。我应该如何和他们联系呢。
    已毕业学生的困扰：偶尔想念老师啦。主动敲老师的现状，会很尴尬吧；老师也没有特别有空吧。现在实验室的学弟妹们都有谁啊，他们都在研究什么课题，做什么项目啊。我能不能提供工作招聘的内推机会给他们啊，这样我也能顺便得到内推奖金😁，两全其美，何乐而不为。可是学弟妹是谁呢，有谁需要呢，如何联系呢。
    需要这样一个网站系统、或APP、或轻度社交软件、或依附于微信的轻度社交小程序，能把同门的家族关系建立起来。具有动态分享和社交的功能；具有一定隐私性，外人只能查看基本信息，无法窥探细节；但假如是家族树的人，可以知道同门家族的前驱后继，自己的前人和后来者，自己的导师，乃至导师的导师的导师的导师，上翻18代，也许是牛顿。微软在很多年前，就有 发布 ”学术家族树“ 的应用，但是没有社交的功能，也仅止于学术的信息。我希望的是，每个节点，都是一个活生生的人物和用户；分享和互动，也是其中有的功能。不准确地说，也许是高校实验室版的“领英”。究竟应该做成什么样呢？请你和你的结对伙伴一起讨论思考吧。

——引用自<<< here >>>

    可以看出，四类群体需求各不相同。老师的需求是默默关注自己所教过的学生的发展情况；萌新学生则是想了解毕设导师or研究生导师具体信息——希望可以和师兄师姐详尽地交流以获取准确的信息；在读学生希望可以联系学长学姐传授一些深造or公司面试的经验；已毕业学生的需求是在老师不知道的情况下了解老师及师弟师妹们的现状并获得师弟师妹的联系方式——现在实验室的师弟师妹都有谁啊，他们都在研究什么课题，做什么项目啊。我能不能提供工作招聘的内推机会给他们啊。
    诚然，上面的分析是总体上分析，具体细节看原型设计。考虑到应用的适应性，我们一致认为做一个依附于微信的小程序比较好些。

>>>Approach<<<

    我们用思维导图构思了一下，如下：

     从上图可以看到，这个小程序功能还挺多的:smile:本次原型开发工具使用的是*MockingBot*。做成这个样子是为了更好满足用户需求，但是却没满足*可以查看导师的导师，上翻几十代——家族树~~(后来又添了)~~。* ##>>>Benefit<<<     Apparently，老师可以通过班级班级来关注所有学生，实现默默地关注已毕业学生的发展情况；萌新学生可以去*专业园*顶部获取导师基本信息，又可以熟悉本专业，还可以和同专业学长学姐了解更准确详细的信息；在读学生可以在*发帖社区*关注是否有学长学姐的内推以及深造or就业也可以发帖求助，还可以在*专业园*私聊学长学姐；已毕业学生可以通过之前关注的老师发的共享动态来初步了解老师近况，也可以去*机构专区*来获悉自己之前所在实验室发展情况和研究话题，内推可以通过发帖或发动态让老师看到*(具有不确定性)*或私聊老师让老师介绍给学生。总之，用户不满意可以反馈意见。 ##>>>Competitors<<<     我们这款产品逻辑结构比较好——如下图： 

       其次我们采用的是"微信小程序"作为开发对象，可能比较实用，因为不用每次都登录，相比于QQ，web，etc.来说是优势；但是，用户如果变更了微信就得重新输入个人信息。还有用户需求具有时间波动性，所以我们打算设置“意见反馈”途径，让我们维护人员尽可能有效地满足用户新增的需求。我们看了一下已提交的作品，他们思路可能不一样，有自己独特的创意。

>>>Delivery<<<

    由于我们设计(微信小程序)，可以很好绑定在微信公众号上，如福州大学微信公众号，还可以通过学生老师来推广，就像福大助手推广的那样。其实我们觉得全体同学肯定有人没有作业博文说的那样的困扰；所以应该尽可能交付到需求欲望大的人群中去。
因为电脑是Mac环境，所以我才用了sketch来实现这个app的UI界面。
原型开发：
       打开小程序后，首先要允许微信获取你的姓名、头像等基本信息。然后注册的时候，需要获取你的学校、入学年份、学号、导师的真实信息。（由后台数据库自行判断，若每项信息都真实存在即通过注册），这样可以最大程度上的保证每个学生的隐私。

         

        首先，你会自动加入到你导师的园子内，你可以看到导师曾经学生和现在学生发的动态。这些动态可是是学生平常的日常生活，或者实验室与工作上遇到的困难。老师也可以发布自己最近的科研成果等，这样子就可以更好的作为老师和学生之间的纽带。不会出现老师不敢主动问，学生怕尴尬不好意思开口问的这个难题。 其次，在这里在校学生可以发布自己寻求内推的需求，已经毕业的学长可以发布自己企业有的内推名额。 最后，可以帮助萌新在选导师的时候，能详细的看到老师的资料避免踩雷。

       

在搜索界面你可以搜索关键字，获得你所需要的博文或者内推，招聘需求。

        你可以发表自己的动态并且设置权限，即园内和全站。如果你设置的动态权限是园内，那这条动态只有你家族树的直系才能看得到。倘若你需要这条信息被尽可能多的人看到，那你就可设置全站权限，这样解决了有时候动态的不同需求的问题。

上图是新动态的设计图。

上图是消息界面的设计图。

上图是联系人界面的设计图。

上图是个人主页展示的设计图。

上图是汇总在一起的整体感观情况。

总结：
       通过本次作业，我们都知道了有些事一个人办起来可能费劲，但是两个人可以取长补短，相互促进，更利于开发出完善的作品，正如大型游戏是由一个开发团队开发的一样；我们还可以用“1+1>2”来形容两个人结对完成某件事的效率。需求分析环节是至关重要的，如果需求分析存在偏差，其产品可能与用户想法背道而驰，“失之毫厘谬以千里”嘛。总之，通过本次作业，我们学会了如何充分发挥两个人的长处，以及简单的需求分析与原型设计。
PS:pdf(zip)download
结对照片：