结对成员：
031502308 付逸豪
031502113 胡俊钦
需求分析
选择学生会部门的现状：
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下：
部门纳新人数和面试时间必须事先申报确定；
部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
未参加部门面试的学生不能纳入部门。
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
Need
- 人工宣传部门和筛选学生需要耗费大量人力资源
- 部门纳新人数和面试时间需要事先申报确定
- 部门需要公布常规活动时间，以及通知临时活动时间
- 需要记录学生的活动出勤率，请假超过六次要淘汰
- 学生申请部门有上限，另外需要考虑各部门的时间冲突
- 需要使学生很部门之间的互相选择过程信息化，加深双方的了解，避免浪费时间和精力
Approach
由于部门和学生之间需要及时进行沟通和互相了解，而能够使消息最快最有效的传达到对方的方式就是通过手机。现在的大学生人手一部手机，手机已经成为了每个人的必备之物。所以，我们打算做一个移动端app，让学生和部门可以随时随地的进行消息互通。另外，对于学生和部门，不同的角色的需求是不同的，所以我们还采用了分角色登录管理的方式，有正对性的满足角色需求。为了管理方便，除了学生和部门两种角色外，我们还添加了一个管理员的角色，用以进行后台管理和相关维护。各角色的功能模块将在下面具体介绍。
Benefit
由于我们的产品只针对学生会，具有很强的针对性，没有复杂冗余的功能，自然也就没有多余的资源开销。我们的app不仅可以最大限度的满足用户需求，而且手机空间占用率很小，界面清晰，操作简单，是学生会的不二之选。
Competitors
我们的产品相比于市场上现有的同类产品，最大的优势就是我们的所有功能都是为学生会量身定做的，没有像超级课程表那样集成了各种各样的功能。对于学生会的需求来说，超级课程表只有超级社团的功能有用，其余的全是冗余的。而且超级社团针对的是所有社团，并不只针对学生会，也导致了大量的冗余功能。我们的专一是我们的优势，但同时也带来了一定的劣势。相比于超级课程表的过度集成，我们的app过度专一化，这就导致了适用群体大大减少。但是我们开发的成本也相对来说低很多，如果能够顺利推广，所得到的利益还是非常可观的。毕竟中国高校的数量还是很多的，每个高校都会有校学生会和院学生会，能够独占学生会市场，那么也是会有巨大收益的。
Delivery
产品能否有效的推广是非常重要的，特别是我们的适用人群本来就少。所以针对产品的推广，我们先想了推广三部曲：作为本院学生会主席的好基友，我们有直接的推广渠道，第一步可以在本院的学生会进行推广，然后通过以前的同学之间的人脉关系，渗透进其他各院的学生会，不久就可以进军校学生会从而占领整个福大学生会的市场。第二步便是号召散播在各个院校的高中同学进行宣传，同时加上本校学生会的用户体验报告，并录制一些宣传视频，到各高校学生会进行推广。在人脉资源已经不足以继续推广的时候，开始第三步的渗透计划。在app中开辟推广模块，凡是使用此产品并且将其推广给其他学生会的用户，可以给其在该学生会获得收益的1%作为回报。至于第四步的推广，等前三步完成之后再行商定。
Elevator speech
基于以上NABCD的分析，我们设计出了“学生会里学生汇”，我们的产品是为了解决学生会部门和学生之间互相选择时过程不够信息化的痛苦，他们需要让彼此之间的互相选择信息化起来，解决学生选择部门和课余时间冲突之烦恼，以达到双向选择的目的。现在市场上并没有专门针对学生会这一组织的产品。诚然有一些诸如“超级课程表”里面的“超级社团”功能可以管理学生和社团之间的信息。但是超级课程表的功能太多，也太繁杂，把学生的基本需求从小到大，全部囊括进去，还有很多并不实用的功能。如果想要使用超级社团，就要把那些并不需要的功能一起下载，极大的浪费了手机空间，而且功能过于繁琐，操作并不是很清晰。而我们的产品只针对学生会的各个部门，为学生会量身定做的，很有针对性，各个功能都具有很强的实用性，没有一点冗余的模块，界面清晰操作简单，手机空间暂用率极小。我们的产品是一个移动端的app应用，采用分角色登录管理的方式，它不仅能让使用者能够直接看到与自己切身相关的信息，至于其他的无关内容则不会出现，同时作为一款功能实用手机资源开销小的app，实在是学生会的不二之选。同时，作为本院学生会主席的好基友，我们有直接的推广渠道，第一步可以在本院的学生会进行推广，然后通过以前的同学之间的人脉关系，渗透进其他各院的学生会，不久就可以进军校学生会从而占领整个福大学生会的市场。第二步便是号召散播在各个院校的高中同学进行宣传，同时加上本校学生会的用户体验报告，并录制一些宣传视频，到各高校学生会进行推广。在人脉资源已经不足以继续推广的时候，开始第三步的渗透计划。在app中开辟推广模块，凡是使用此产品并且将其推广给其他学生会的用户，可以给其在该学生会获得收益的1%作为回报。至于第四步的推广，等前三步完成之后再行商定。
设计过程
在看了作业要求明白了需求之后，我们经过简单的商讨，确定了基本框架之后。便开始尝试设计产品原型，在设计过程中边设计边商讨细节，用的原型设计工具是墨刀设计组件。为了保证设计风格的一致性和模块的统一性，我们在墨刀上创建了一个团队项目，同时进行设计，配上qq进行沟通，双管齐下，提高效率，节省设计时间。我们的产品主要分为部门、学生和管理员三种登录角色，根据角色的不同，设计的界面也略有不同，但大体上是一样的，下面将详细说明。在本次合作中，付少负责部门方面的设计，我负责学生方面的设计。当然，强大的付少还包揽了登录界面和管理员身份的设计。（感到不好意思的我主动揽下了写博客的任务。）
这里附上付少伟岸的背影：
产品介绍
产品主要分为两个模块，登录模块和功能模块，其中功能模块又分为三种三种登录角色，分别为部门、学生和管理员。
登录界面及注册界面
管理员模块
管理员是用来创建一个部门并且提供该部门的相关信息
部门模块
部门模块有以下主要功能
功能介绍：
申请列表：申请列表列出申请部门的学生名单，点击查看可以查看学生的详细信息，包括学生的基本信息、已经申请的部门和学生有课的时间。部门可根据这些信息决定是否同意学生的申请。
发放通知：主要是是用来通知一些部门的相关事宜，也包括临时活动的通知，方便部门成员及时收到消息，以免错过。
消息管理：消息管理用来查看部员或学生向部门发送的消息，包括请假申请和问题咨询等。
基本信息管理：用来管理部门的一些基本信息，便于学生对部门有更深的了解。基本信息包括部门简介、成员介绍和纳新相关的事项。纳新相关事项包括纳新的人数和面试的时间。
时间管理：时间管理用来添加和删除部门的常规活动时间，避免和部门和部门之间、部门和学生之间的时间冲突。
成员管理：成员管理记录每个成员的活动缺席情况，对于缺席次数达到上限或者由于其他原因需要被淘汰的成员可以将其“请出部门”。
下面是各个功能界面的截图
学生模块
学生模块是供学生使用的，主要有以下功能：
功能介绍
部门列表：部门列表列出正在纳新的部门清单单，点击查看可以查看部门的详细信息，包括基本成员信息、部门简介、部门纳新相关事项和部门常规活动时间。学生可根据这些信息决定是否申请加入这个部门。
我的部门：我的部门记录学生参加的部门列表，学生可以在这里选择退出自己不喜欢的部门。
查看通知：学生查看部门发送的通知，及时了解部门的动态，以免错过活动。
基本信息管理：用来管理学生的一些基本信息，便于部门对学生有更深的了解，同时学生可以在这里自我介绍，好赢得部门的认可。基本信息包括学位的基本信息、已报名的部门和有课的时间。学生可自行修改这些信息。
时间管理：时间管理用来添加和删除学生有课的时间，避免和部门和部门之间、部门和学生之间的时间冲突。
发送消息：学生用来向部门发送消息，可以是请假的内容，也可以向部门咨询相关问题，达到消息的互通。
下面是各功能截图
总结与心得
031502308 付逸豪：
在第一次写的不小心全部删除了，好气哦。。。。一开始无意中知道胡老师还没有队友，于是迅速的抱紧大腿，很快的，完成了结对环节。当看到要求的时候还是非常的紧张的，NABCD模型？？原型模型？？都是一些完全没有听说过的词语，不过还好，经过查阅之后大概了解了这些词的意思。于是就开始了沟通。由于一些原因，我们开始做的时候时间已经比较紧迫了，大多数的沟通都是基于QQ聊天的。在沟通的过程中，感觉许多的细节都需要完全的理解对方的意思，才可以更好的进行沟通（不过我们很顺利）。原型模型设计工具我们使用的是墨刀（一大堆名字都是英文的，就他是中文的所以选了他），实际的使用中，感觉墨刀还是非常的好用，非常的强大的（没有和其他的对比过，但是用户体验确实不错），还是值得推荐的。通过这款软件，我们完成了整个原型模型的搭建过程。一开始使用的时候，我们不知道团队功能，打算各做各自的部分，然后拼起来就可以了。但是由于2个人的画风并不一致，最后拼起来的时候可能比较麻烦。于是发现了有团队功能，然后就把我们已经完成的（小小部分）扔进团队项目里面，这样我们可以实时看见对方的修改，这就有利于我们很快的统一了画风（不然各种界面差异太大），还是要感慨一下如果实际完成应用，就想原型模型的设计这样方便快捷，那该多好呀。简单的来说心得有这些：
1.沟通很重要，两个人沟通可以更多的包含一些细节，尽可能完善功能（应该还有较多缺陷）
2.团队合作可以极大的提高效率，一起做明显是很快的
3.一开始要想清楚需求，根据需求入手才可以更好的设计
031502113 胡俊钦：
在上课的时候听到了结对的事情，心中还在纠结我该找谁结对。然而，正在我纠结的时候，旁边的人竟然都已经结好对了，就剩我一个孤家寡人了，年轻人就是太着急了。哎，无奈的我早已做好了跟不认识的人结对的打算。在成功结对的前几天，心中一直很忐忑，没想到这次作业竟然卡在了第一步。一直在想自己到底应该要怎么去跟陌生的人合作，我会不会被嫌弃，万一只剩下女生了怎么办，那多尴尬啊……反正各种担忧。没想到啊，没想到啊。那一天上完一二节的课，无精打采的走向下一间教室，路上看到实验班班草，心想这种大佬怕是早就被人抢了。但是莫名其妙的还是随口一问。我的天呐，山重水尽疑无路，柳暗花明又一村。于是，我就成功跟付少结对，之后便是开心的设计之旅了。虽然成功结完对，但是在时间方面其实双方都是比较紧的。我们很晚才开始着手这次的作业。为了节省时间，我们经过间的商讨，然后就开始设计。多亏墨刀可以创建团队项目，彼此之间可以看到，再加上那个 QQ，基本上沟通是没有问题的。很快，双管齐下，便完成了原型的初步设计。之后便是对原型进行审核，修改一些小细节并且完善了原来的不足。
通过本次作业，我明白了怎么使用原型设计工具进行原型设计和NABCD分析模型，懂得了需求分析对于设计是多么的重要。只有分析透了，才能有针对性的设计出实用的产品，像以前那种漫无目的的瞎想简直是蠢，不仅想半天都想不出结果，而且最终想出来的也是惨不忍睹。除此之外，最大的收获就是体会到原来结对作业可以大大提高效率。如果这次完全由我自己来做的话，怕是要事倍功半。当然，这要建立在双方良好的沟通和配合默契的基础上，幸运的是我们的默契还算不错，配合得很顺利。
PSP
| PSP | Personal Software Process Stages | 预估耗时（小时） | 实际耗时（小时） |
|---|---|---|---|
| Planning | 计划 | 1 | 0.5 |
| ·Estimate | · 估计这个任务需要多少时间 | 1 | 0.5 |
| Development | 开发 | 8 | 6 |
| · Analysis | · 需求分析 (包括学习新技术) | 0.5 | 0.5 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0.5 | 0.5 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 7 | 5 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 3 | 2.5 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 0.5 | 0.2 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 2.5 | 2.3 |
| 合计 | 12 | 9 |