原型设计（结对第一次）
结对成员
林翔170327041
李明皇170327037
NABCD模型
Need
针对本次作业这个案例来说，用户最基础的需求为：提供一个学生部门纳新时能够让学生和学生会双向互选的平台。确定了最基础的需求后，我们分析了学生会部门纳新的整体流程：
- 学生会各部门向所有学生发布纳新通知和常规活动时间和面试时间；
- 学生填写表格后提交学生会；
- 学生通过面试，部门将学生纳入部门；
- 学生按照部门规定的常规活动时间参加活动，若未能参加需提交请假申请，当同一部门请假时间超过6次后部门管理人员将其淘汰；
根据以上流程，我们认为这个平台的需求有：
- 部门
- 部门纳新信息公开；
- 部门发布常规活动时间时，警告与其他部门常规活动时间冲突；
- 部门管理人员可在系统上发布纳新通知等相关内容，临时活动，部门人员管理；
- 学生
- 申请前了解所有部门情况；
- 简化学生申请流程，学生若想申请多个部门无需重复填写申请表；
- 学生报名时，不同部门常规活动时间重叠警告；
Approach
- 部门管理人员发布纳新信息，其中包括面试时间地点和常规活动时间。若和其他部门常规活动时间冲突（+-2小时）将收到警告；
- 学生凭学号和密码登录该管理系统后，在个人信息界面填入个人资料。该资料作为申请部门的简历，可重复使用。在个人资料填写内容我们参考了福州大学研究生会的纳新表格。这一部分需要设计一个数据库来实现；
- 学生在部门信息处可以看到系统管理员发布的纳新通知，可在该处进行职位的选择和申请。若存在部门常规活动或面试时间冲突将受到警告；
Benefit
- 简化了申请流程，公开了部门情况；
- 面试时间、常规活动时间、请假次数一目了然；
- 部门信息沟通更流畅，提升工作效率；
Competitors
- 操作简单，功能齐全；
- 作为大学生我们更能了解部门纳新时的流程和过程的繁琐，能更好的简化流程；
Delivery
参考教务管理系统的模式，系统以web的方式实现。经过内部的测试后向同学推荐，经过改进后联系学校的部门进行推广。
原型模型
原型工具
学生界面原型
-
首页界面
-
登录界面
-
个人中心
-
部门申请，学生可以在这里申请加入发布了纳新通知的部门，若已申请部门的常规活动时间或者面试时间冲突，将收到警告
-
活动安排，学生可以在这里看到自己已加入部门的活动安排，当有部门活动冲突时将用红色标注。学生可以在这进行请假操作并能看到当前请假次数
-
我的消息，学生能在这里收到管理人员发送的通知
系统管理员界面原型
-
通知管理，管理员可以在这里发布新的通知和修改旧的通知
-
活动管理，管理员可以在这里发布新的临时活动和修改旧的常规活动
-
纳新管理，管理员在这发布新的纳新通知，若检测到常规活动时间或面试时间和其他部门冲突将收到警告
-
成员管理，管理员在这里看到申请成员的信息和请假次数，可以对人员进行加入和删除的操作
结对过程
这次合作过程比较愉快。第一天，我们先是看了发布的需求和构建之法的第三章，第四章和第八章之后大致了解了结对是怎样一种状态。第二，三天我们先是一起分析了需求，然后一起设计原型。在设计原型的过程中，确定了大概的网页框架后李明皇负责设计学生部分的页面，林翔负责设计管理员部分的页面。第四天，林翔开始设计需求分析报告的大致架构。最后我们互相检查对方的工作作出补充和修改。最后李明皇补充了PSP表格。
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 15 |
| Development | 开发 | 295 | 505 |
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 60 |
| · Design Spec | · 生成设计文档 | 60 | 100 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 15 |
| · Design | · 具体设计 | 180 | 300 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 15 | 30 |
| Reporting | 报告 | 60 | 90 |
| · Test Report | · 测试报告 | 20 | 20 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 60 |
| 合计 | 365 | 610 |