软件工程实践结对编程作业（需求分析与原型设计）

PSP

附:客户现实困扰

学长学姐去哪儿——了解实验室或社团历史上的那些学长学姐们的去向和现状

了解实验室学长们去向的现状：

除了实验室群里长期潜水或偶尔冒泡的学长、导师口中的零星去向、临近的学长，似乎就无法了解了。好久以前的没见过的学长们，去了哪里。这不仅仅是?是否?选择这个实验室的依据之一，还是今后找工作的内推的重要支柱。可惜现状就不是很明确和了解，知晓的渠道也很有限。

学长们其实也很想了解学弟们现在在做什么研究，有没有什么擅长的技能，比如会某个研究方向或数学建模技能的，也很希望能帮忙协助内推，比如这位学长，就只能给我发消息，也无法有效传递。

另外，建一个实验室群，也不是很方便，因为在群里，你也不好意思经常问：学长们，你们在哪啊。

甚至，等你工作了，和你同一个公司或一个组的同事，可能就是实验室同门，你们都相见不相识，多遗憾。

结对过程

结对之后，我们在一起讨论了有关本次问题的需求。通过阅读构建之法第三章与第八章，学习NACBD等系统知识，具体分析了关于本次“实验室”问题的不同参与人员的主要需求，并确定了实现方式。在画完草图之后，开始学习axure的使用，将我们的草图模型内容展现出来。最后再通过讨论对局部进行总结修正。

NACBD模型分析

N（need）

实验室学弟学妹的需求：
就算是可能有群，实验室的学弟学妹们也还是不容易知道想要了解的前辈的去处，当想要了解更多未来的工作方面信息，也不好开口。所以需要一个能够自行阅览的平台让他们知道学长学姐的部分信息，并且在需要进一步交流的情况得知联系方式。

学长学姐的需求：
想要知道有没有学弟学妹和他们做一样的方向，或者来到了同一家公司还是同一个城市，可能想要知道年轻的学弟学妹的未来规划，想和同实验室的学弟学妹共同工作。所以当有公司内推或其他有关信息的时候能高效地传播给不认识的学弟学妹。也可以分享关于职场上或者科研上的一些心得经验，毕竟对方是同一实验室的成员，所以这些有关个人信息的东西可以放心地发布。

A（approach）

明确需求之后，我们准备的是一款面向同一实验室不同届的各个成员使用的app，由一个个“小型私密论坛”组成。在这里展现同实验室的成员个人信息，联系方式等。学长们通过发帖的形式发布各种信息，同实验室的成员可以浏览。

B（Benefit）

其中之一好处是简单高效。在加入一个实验室后，看到对方想让看到的信息与联系方式，在这里我们将此产品定义为重要的信息发布渠道以及特殊的人脉连接，而不是可以实时联系的通讯工具。我们主打以论坛形式将重要信息发布起来，例如有内推渠道时，同学可以很快重视到信息，看到需要，并且自我进行判断或者用发布者的联系方式进行咨询，或者回帖发表想法，但不提供app内的通信方式，这样会影响本app的高效性。使用者并不需要经常的使用本app，当重要的即时信息发布时可以获得通知，这样照顾了很多现如今懒得去应付社交的人群，毕竟前辈们已经选择将联系方式发布了，就不应该在app里打扰别人
另外一个好处是……（补充—）

C（Competitors）

节约时间，减少多余的沟通。我们的竞争力在于抛弃了很流行的通讯功能，将app变成一个正式的有用的工具，而不是可有可无时不时会浪费使用者的时间……当使用者群体（学长学姐）正式接触这个产品后会感到非常的轻松实用，而学弟学妹也同样能快速获得想要了解的内容。当你发布内推信息或者咨询帖子时，别人会知道这是很重要的信息，别人会重视起来。

D（Delivery；data）

可以通过多个年段的实验室群、还有实验室的老师教授可以帮忙发布。事实上，这个app面向的用户不只是“某实验室”的成员，工作室、部门、学生组织……任何团体都可以使用。

原型展示

app首页

登陆注册

团队页面

设置多个实验室，只要报备之后就可以选择实验室

团队详情页-动态页面

团队详情页-成员页面

只有在认证成功才能看到
简略的个人信息

帖子详情页

App的安全性

一个实验室就是一个半私密的小型论坛，在初步的审核之后，一个团体内的大家都可以被视为有一定关系的值得信任的人。而这里面的个人隐私 则通过认证成员的方式大大减少信息泄露的可能性

总结

了解了一个app的原型设计需要注意的内容，学会使用nabcd模型分析需求，学习到了axure的使用规范
当然本次作业过程也有一些困难，比如设计的美感把握，双人合作的顺序进行