Over Look
队友INFO
NABCD应用
采用的原型设计工具
进行时
遇到的困难及解决方法
关键代码or设计说明
PSP
记录自己的学习进度条（每周追加）
Come On,Let's Go!
-
队友INFO
林松雄，031502126，负责开发，唱歌，跳舞
黄显东，031502114，负责复审
-
NABCD应用
-
N(Need,需求)
从学生会的角度来说，为了更好的纳新需要进行一系列的工作，如占据广场的有利位置，还要提供传单的发放和回收，最后进行手工筛选和处理。从学生的角度来说，一方面从传单上了解到的信息是很少的而且有可能会因记不住自己的课余时间为哪一段而导致部门上的时间冲突。综合两个方面来说对谁都是很麻烦的事情。所以我们给出一个方案，利用互联网平台将社团部门信息和学生信息集中起来，通过合理的筛选算法，给部门和学生们提供一个良好的环境。这样不仅解决了社团占位，发放传单，处理筛选的烦恼，还解决了学生对部门信息不了解、时间冲突的问题。 -
A(Approach,做法)
利用网页平台，实现线上纳新活动。为了提供良好的信息交互界面，我们设计为一个登录入口，学生可用自己的学好和教务处密码登录，并完善个人信息，其中“已加入部门”一栏由系统检测填写。学生会部门有专用的账号和密码，部门管理人员登录完善信息，包括纳新人数，面试时间，和常规部门活动时间等，部门可以发布动态和任务，学生进入部门详情页可了解到部门信息。学生申请加入部门以投递简历方式向心仪的部门申请，部门处理筛选之后反馈录取信息。没有投递简历申请的学生不得参加面试和纳入部门。针对筛选进入部门后淘汰的规则，我们有如下方案：各个部门活动时进行签到，若系统检测到有部员请假次数过多但未超标，系统会发送提醒信息，若超标之后系统通知部门处理。投递简历时，学生可投多个部门，系统筛选时，获取该学生已加入部门数，到达5个部门则不允许再投递简历，且部门也不能纳入该生。 -
B(Benefit,好处)
线上功能减少了部门纳新繁琐的程序，省去了不必要的开销，而且使过程更加简化明了，易于管理。同时也能加强学生和部门之间的信息交流，使学生更容易、方便、快捷的了解到自己想关注的部门信息。也部门管理部员更加轻松、高效。 -
C(Competitors,竞争)
相比于其他的见过的线上报名社团部门，他们做的只是提供一个线上表单而已，其面试时间地点和各个方面的通知还要进行手工联系同学，而我们则是提供动态的方式，学生只要登录主页即可查看相应得最新消息。当然，其他队员也有类似的功能，而我们要尽可能做到我们预期的效果。 -
D(Delivery,推广)
推广的形式只需一张二维码即可，上面有我们网站的主页。纳新之前学生会向广大新生宣传线上纳新平台，新生只需要拿出手机扫一扫即可登录网站主页了解到各个部门的信息。 -
采用的原型设计工具
刚开始接触作业里面提供的几款原型模型设计工具时，简直是一无所知，无从下手，更不用说他们的差别和特点了。但凡事都要实践过才知道嘛！于是我们两个屁颠儿的把他们全都下了一遍看看，果真看不出他们有什么差别（滑稽）。于是知乎了一下看看有没有大神再用这些软件，果然被我发现了有个人专业用Axure RP的，看了他写的[文章](https://zhihu.com/question/24574207/answer/60830220)，于是我们决定使用Axure RP，然后发现了一个不错的学习Axure RP的网站，附带传送门[biubiubiu~](http://www.webppd.com/forum-28-1.html) -
进行时
嗯？结对的过程？听起来gay里gay气的，哈哈哈，我们两个本来就很合拍，都睡了彼此那么久了（舍友），我们的默契可谓是一目了然，不言而喻啊。选原型模型设计工具时我们也很快的得出了一致的结果，虽然在制作过程相互嫌弃彼此的切的图
，但还是很愉快的把作业做好了。
附上工作进行时的图：
FJU9VN35_VPT@0.png)
-
遇到的困难及解决方法
由于之前听也没听说过几这款原型模型设计工具，所以我们可以说是现学现卖了，在大量的搜索和联系之后我们还是没能掌握其精髓
但能做出了基本界面和项目相关的要求，这方面我们会加把劲儿学好怎么更好的使用这款软件。
还有在分析NABCD时也感到模糊，老是不知道从何下手，最后在精读了第八章和基友间的讨论之后也相应得出了结果。
-
键代码or设计说明
登录界面
学生界面
编辑资料栏目是为了完善信息，方便申请时不用重新填写（也可修改）直接申请，类似投简历。
我的申请
向发布纳新的部门发出申请
我的面试
罗列需要面试的安排表
我的活动
罗列已加入的部门的常规活动和临时活动
部门界面
发布纳新
时间线表示各部门面试时间避免安排冲突
临时活动
申请者信息
罗列满足“学生最多进入5个部门”和“请假不超过六次”的申请者，以签到的方式来判定是否参加了面试
PDF版
-
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | 120 | 128 |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 40 | 50 |
| · Design Spec | · 生成设计文档 | 10 | 10 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 10 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 30 | 45 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | ||
| · Test Report | · 测试报告 | 10 | 10 |
| · Size Measurement | · 计算工作量 | 5 | 3 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 30 |
| 合计 | 215 | 436 |
学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时 ) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 第一周 | 100 | 100 | 725 | 725 | github的使用，项目分析技巧等 |
| 第二周 | 200 | 300 | 436 | 1161 | 学习了aurex rp的使用，以及php的入门 |