1.组队信息
学号： 170320074 170320076
2.NABCD模型
1.N（Need，需求）
管理端
• 管理部门。
• 管理纳新的开始结束。
学生
• 能获取部门的信息。
• 能获取纳新期间所有信息和通知以及可以在线申请。
• 能了解部门常规活动时间并制定出不冲突的申请计划。
• 加入部门后能获取部门的临时活动以及通知。
• 在临时活动存在冲突时，可以反馈到部门。
• 在无法出席部门组织的活动时，可以请假。
• 可以申请退部。
部门
• 能了解其他部门的安排信息，并制定自己部门的安排计划。
• 管理发布部门纳新相关信息。
• 能获取并查看全部申请人的相关信息。
• 在面试后能设置评分并排序，可以筛选人员并通知。
• 可以将纳新过程中的消息通知到申请人。
• 能避免选择中常规活动冲突的新部员。
• 可以发布部门的临时活动和通知，发布时有活动冲突提示。
• 可以分配活动的参与部员。
• 可以记录并查看活动中部员的出勤情况。
• 可以审批和查看部员的请假情况。
• 可以选择淘汰部员。
2.A（Approach，做法）
• 为了更好平衡同学自由选择以及社团间的常规活动冲突问题，采取申请前提醒，确选时强制，部门中优先确定部员的先录取，其余活动冲突的部门将不可再录取。
• 在学生的数据上可以接入教务处的数据。
3.B（Benefit，好处）
• 让部门间以及同学与部门间有足够的了解。
• 简化申请流程，免除花费人力扫楼和发放收集申请表。
• 部门与部员的互动都存有记录，可以及时获取以及回头查看。
4.C（Competitiors，竞争）
• 这个项目有一定的特殊性，不同的学校或者学院一般都有特定的需求，所以这次的竞争对手差不多就是这次做这道题的同学。本项目有较好拓展性，可以应对接下来的微变更需求或者更细致的需求，有较强的竞争力。
5.D（delivery，推广）
• 应用主要用于特定的学校或者学院，推广主要在同学和部门间。
• 应用易于操作，部门和同学在下载应用后能很快上手，易于推广。
3.功能结构
根据以上分析，我们制定了下面的功能结构图：
4.原型设计
1.学生端
登录界面（三个客户端的登录界面一致）
首页
部门查看
纳新宣传
部门申请
添加部门申请计划
部门通知
活动
活动安排
活动参加情况
请假管理
请假申请
我的（个人信息修改）
2.管理端
首页
部门信息
纳新管理
纳新申请
部员管理
通知管理
发布通知
通知详情
修改通知
活动管理
超级管理端
首页
纳新
部门查看
部门恢复
恢复确认
设置部长
删除确认
修改密码
5.结对过程
在独立阅读完后题目后，我们先互相讨论题目的要求以及完成需求制定前的一些注意事项。接着，按照NABCD模型编写需求以及解决方法的描述文档，这一过程也是边讨论边进行文档的编辑。后面，使用思维导图的方式描述系统的功能点，进一步详细需求的解决方法。最后，根据功能结构图，使用墨刀平台进行系统原型开发，在这一过程中，我们先一起完成常出现的界面元素（后面有利于“复用”），然后再分工完成剩余部分，最后互审对方的设计，并做进一步的改善。
照片1（写NABCD模型）
照片2（画功能结构图）
照片3（使用“墨刀”设计原型）
6.结对感想
170320074
相比于个人独立开发，结对开发很大的不同在于队友随时都有可能对你的想法提出质疑。无论这质疑是对是错，首先要做的是理清自己的思路，向队友较好地解释自己的看法。可能在解释过程确实发现自己是错误的，但更多的情况是在基于自己的想法双方讨论出一个更好的解决方案。而独立开发就有可能一股脑地按照自己的思路做下去，难免就会发生“碰壁”，而且也不会强迫自己去优化解决方法。需要注意一点的是，虽然结对讨论很重要，但更重要的是在讨论前双方需要各自进行独立的思考，这样可以避免讨论过程中出现“人云亦云”的问题产生，才能更好的做到“1+1>2”的目标。
在本次作业中，对需求分析有了新的认识。因为我们队伍在细化问题的时候，发现“需求点”不断膨胀，有些是“假需求”，也就是可能成为“鸡肋”的功能点，而有些则是“拓展需求”，是配套解决问题而连带产生的。我们的做法是删减需求点，立足于根本问题，主要体现在：1、加入该需求点，是否有利于问题的解决，是否能简化日常的操作（在不使用系统下的情形）；2、加入该需求点，是否让解决问题的流程变长，也就是说会增加更多的操作（在使用系统下的情形）。根据这两个判断标准，删繁就简，也能较好地符合“简单设计”的原则。
170320076
1.结对与个人相比，能注意到更多的设计缺陷和细节，能使初期的临时成品更好。
2.有时会出现双方思想冲突的情况，而且双方又都有一定道理，这时候就难以决定。
3.做作业过程中，由于时间安排和工作量原因，并非完全时时刻刻都是两个人在一起，有一些工作是分任务分开做的，比如原型设计，因此导致了部分设计风格有些不同。
4.在此次过程中学习了原型设计软件墨刀。原本是打算使用Axure Rp的，不过在考虑到可能有一部分任务要分别做，最后采用了墨刀，可以时时查看对方完成的进度以及调整风格。一开始上手也是束手束脚，做个简单的界面都要很久，后面熟悉了就越来越快。
5.在有些问题的确定中很纠结，甚至无法确定。比如确定做app或者web，最后还是觉得到大一同学可能不会带电脑，所以做了app端。在设计功能的时候，觉得有些功能应该加的，不过又觉得工作量太大，做了妥协的精简。在设计时考虑到实现，又是让人很纠结，因为画原型的话，其实基本流程都定了，但是牵扯到比较多部分的时候觉得需要考虑实现，需要比较详细的设计，但同时觉得详细设计又不应该在这个阶段做，左右为难等等。
6.最后惯例吐槽自己的糟糕审美导致的原型UI设计。一开始的一些部分是分开做的，做了两三个界面跟我的结对伙伴比了一下，简直不能看。最后还是照着他的样子去做原型。
7.PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 15 | 15 |
| · Estimate | · 估计这个任务需要多少时间 | 15 | 15 |
| Development | 开发 | 470 | 500 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 130 |
| · Design Spec | · 生成设计文档 | 30 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 20 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 300 | 320 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 45 | 35 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 15 | 15 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 20 |
| 合计 | 530 | 550 |