结对成员：
[张旗 031502243](http://www.cnblogs.com/neveslalala/) [周琪文 031502642](http://www.cnblogs.com/qiwenzhou/)
需求分析 （NABCD模型）
N （Need）
本软件意图建立在大学中，学生管理的部门，社团和学生群体之间的信息交流平台，主要是解决在大学新生入学后，在部门和社团纳新活动的推广、宣传和管理。比起传统的方式，例如“发宣传单”，“扫楼”，“广场纳新”等，更加节约时间和人工。 普通学生在使用了软件之后，能够避免盲目加入社团部门和不知道加入什么社团部门的处境。社团或部门的成员使用软件之后，能更便捷地管理现有成员，安排活动，并在纳新面对新生时，取得新生的基本信息，去掉这其中的成本。
A （Approach）
建立一个基于学生信息的平台，在平台之上，新生可以浏览、了解各个部门与社团，而且可以向其提出自己的问题，完成提交面试、活动安排等动作，而社团管理人员能初步了解新生个人信息。 使用Android来编写程序，通过和教务系统的相连，导入新生的信息，新生可直接使用身份证号等方式登入。在软件中，设置部门或社团的主页来实现对自身的介绍等功能。
B（Benefit）
普通学生在使用了软件之后，能够避免盲目加入社团部门和不知道加入什么社团部门的处境。社团或部门的成员使用软件之后，能更便捷地管理现有成员，安排活动，并在纳新面对新生时，取得新生的基本信息，去掉这其中的成本。 做到这些，用户至于要一台智能安卓手机。后期可推广到iOS平台。
C（Competition）
在福大范围内没有类似的软件和平台，虽然有着像超级课程表中超级社团的模块，但推广程度低，功能也不够针对。
D（Delivery）
我们会和老师沟通，就像福大教务通一样，作为学校推广的软件之一，毕竟是面向整个福州大学的同学的软件。功能完善之后，就像新生推广（比如说18级大一学生）。由于时间关系和我们的能力有限，我们的产品可能还知识个雏形，我们以后会继续对它进行改善，期待新的完美产品面世。
原型系统
app名称：选我
页面：44个页面
模型内容：
模型登陆后，主要分为四个部分，分别是：首页、部门、日程安排、个人设置。每一个部分都有信箱功能，可以实现接收与发送部门与联系人的消息，例如收到部门面试与开会等消息，如需请假也可以回复与请假相关事宜。
首页：
1. 通过轮播图展示社团和部门的风采； 2. 通知每一位学生一些重要的事件，比如说社联纳新事件地点等； 3. 从首页直接进入我的部门，可以实现对部门的管理与参与部门的讨论。
-
所有的部门都有一个主页，主页按照帖子的方式展现自己部门的特色，同时想要询问关于部门信息的学生可以在帖子下方留言，有助于学生们全面了解社团，而不是稀里糊涂加入了自己不熟悉的社团。同时每一个部门的主页都可以一键申请，实现线上申请部门的功能。
-
我的部门有两部分，一部分是我管理的社团，一部分是我参与的社团。
- 我管理的社团（此模型为院·实践外联部（副部长）为例），可以实现功能如下：
- 进入主页：进入部门帖子主页，浏览与编辑已经发布的帖子。
- 发布日程：可以发布日程给所有部员，例如：面试时间地点、开会时间地点等等。同时在 日程安排 上自动生成日程，如有部员冲突，则会提示有多少部员冲突，实现防止日程冲突功能。
- 申请信息：可以浏览同学们从网上报名的信息，可以通过申请与拒绝申请，实现线上部门与学生互选功能。
- 人员管理：可以对已经加入部门的成员进行管理（删除、标星功能）。
- 发帖（模型中未展示）：在主页上发帖，更全面的展示自己的部门。
- 评论回复（模型中未展示）：可以浏览学生们在主页的帖子上的评论，并进行回复。
- 我加入的社团（此模型为院·文化部为例），可实现功能如下：
- 浏览部门首页帖子并可以评论。
- 我管理的社团（此模型为院·实践外联部（副部长）为例），可以实现功能如下：
部门：
此部分可以展示所有的部门与社团（校学生会、社联、院学生会（用户的学院）、社团），可以通过搜索功能查找想要了解的部门，每一个部门通过主页的形式呈现，每一个主页有很多帖子，用户可以进行评论功能，具体同“我的部门”中“文化部”形式相同。可以一键申请加入。
在模型中只展示了院学生会中的文化部与实践外联部，其余在实现上类似。
日程安排：
以日历的形式展现日程，清晰明了。红色代表当天，白色代表无安排，绿色代表有安排，日历只会显示用户已经加入的部门的日程。
个人设置：
个人设置分为以下几个部分：
1. 修改头像，因为存在帖子这样交互的功能，所以用户喜爱的头像也是必不可少的，点击头像位置即可设置头像。 2. 个人中心。个人中心可以实现以下功能： - 修改头像功能，同上。 - 修改非固定信息（固定信息：姓名，性别，学院，专业，年级，年制）。 - 退出登录。
-
空间清理。交互式网站浏览帖子不免会产生缓存文件，所以特设空间清理功能。
-
关于我们。描述了一些作者信息。
-
意见反馈。用户可以通过这个部分提出一些建议，方便app的改进。
以下为app模型展示：
开发工具
墨刀。建议新手使用，简单易懂。
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 570 | 750 |
| · Estimate | · 估计这个任务需要多少时间 | 9.5*60 | 12.5*60 |
| Development | 开发 | 440 | 600 |
| · Analysis | · 需求分析 (包括学习新技术) | 2*60 | 2.5*60 |
| · Design Spec | · 生成设计文档 | 1*60 | 1*60 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 20 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 3*60 | 5*60 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 1*60 | 70 |
| Reporting | 报告 | 130 | 150 |
| · Test Report | · 测试报告 | 1.5*60 | 100 |
| · Size Measurement | · 计算工作量 | 10 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 570 | 750 |
结对过程
分为四个阶段
- 一起讨论。讨论出需求分析，并且有了最初的想法与模型。 - 一起开发。墨刀有团队作业的功能，于是我们通过语音聊天，在各自宿舍，共同完成了app模型的设计。 - 模型修改。初步模型建立完成之后，还做了很多的添加和修改，完善了模型。 - 一起写博客。需求分析、psp表格为周琪文编写，其余内容为张旗编写。
