## 结对成员： ### 031501102 叶文滔 ### 031502409 杜宏庆
## 需求分析： 我们觉得，需要为客户解决的主要是学生与部门之间相互信息获知的问题。目前的现状是：新生们在面对眼花缭乱的部门时，不了解所有部门的常规活动时间，导致进入了多个部门后，部门活动与课程时间或部门活动之间协调不过来，而另一方面部门不清楚报名的学生同时申请了多少部门，这名学生所申请的部门是否有与本部门活动时间冲突等等。因此实际上要解决客户的困难，应该从让两方在决定进行面试之前就相互明确地了解对方这些重要信息，我们所设计的原型模型就是基于这个理念。接下来我想先用NABCD模型进行一个系统化的需求分析。
N：
学生方面：需要了解各个部门的常规活动时间与面试时间，从琳琅满目的部门中选择时间安排合适的不多于五个部门。 部门方面：对部门来说，面对一波一波的小鲜肉，不仅需要筛选出符合部门需要的人员，还要确保新生在面试之前就先确保自身时间不会冲突，且不会报名过多的部门。
A：
我们的做法参考了福州大学的选课系统，具体做法如下： ① 一个同时可以选择进入“学生”或“部门”模块的Home界面，根据所选择的角色不同进行登录 ② 学生登录后首先来到他们已选择的部门页面，在该页面同时可以进入补填他们信息的页面以及选择部门的页面，部门选择页面通过表格的方式呈现每一个已经填写好部门信息并开始纳新的部门，这些信息包括上面所说的“常规活动时间”“以及“面试时间”两个重要信息，因为这两个信息应该是部门在纳新开始前就已经申报确定的，所以可以在此时直接填写在部门信息中。新生通过页面中部门的简介选择自己喜欢的部门（多选，至多选择五个），按下“投递简历”按钮即可将已经填写好的简历发送到部门端，同时回到已选择的部门界面，在这个界面此时还可以进行撤回简历的操作，但若部门已同意面试，则不可撤回。 ③ 部门登录后来的已投递给该部门的学生列表的界面，在这个界面部门负责人可以多选学生，进行同意面试操作以及拒绝简历操作，另外在这个界面还要通往填写部门信息页面的按钮。 ④ 具体的内容将在下面的原型模型中展示。
B： ① 界面友好，操作简单，所有的界面都十分简洁，没有难懂的操作。 ② 对学生而言，在选择部门界面将一次性展示所有所需要知道的必要信息，不必多花费时间二次了解。 ③ 对部门而言，同样可以在选择学生界面一次性得到关于学生的具体信息，且由于软件硬性设置，不必担心学生选择过多部门。 ④ 对学生与部门而言，所有的操作批量进行，一次性即可完成双向选择操作，效率十分高。
C： 竞争必然存在，但我们的产品直接针对用户需求，做到一刀去病，没有任何副作用，也就是没有任何使得软件变得更加复杂的不必要功能，我觉得这是我们的特色，可以让我们在后续的维护中针对双方信息交换这一个点做到最好，而不需要去考虑很多繁杂的其他模块。而假如在后续如果客户有其他更新的需求，比如要加入部门持续对学生进行管理的模块，我们可以直接另外再建立一个新的模块来完成需求，最终将二者整合成一个软件，由一个接口选择通往两个不同的模块，所以客户也不必担心我们产品的拓展问题。
D： 推广计划希望在我们的产品基本完善以后，由校方官方的队伍，或者联合部门校部门进行试用推广，只有通过更高层更大的力量才能真正将我们这样一款实用的软件有效率的铺满为数众多的新手群体。
## 原型系统展示： ### 所用工具：Axure RP ## Home界面： ### 从Home界面选择进入学生端还是部门端  ## 学生界面： ### 先进入学生端，输入登录信息登录  ### 进入已选择的部门界面，可以看到已选部门的基本信息，并且在下方有提示六次缺席常规活动后果的语句，供学生们选择时间合适的部门。  ### 先通过下方的“完善个人简历”按钮进入信息补填界面  ### 点击保存后，操作成功，个人简历已保存  ### 返回到主界面，也就是已选部门界面  ### 接着点击“开始投递简历”选择部门投递  ### 点击蓝色的部门名，可以查看部门的详细介绍，再按返回即可回到选择界面  ### 选择完部门之后，点击“投递简历”，即可将简历发送给选择的部门端，弹出确认窗口（之后确认窗口不再截图展示）  ### 返回主界面  ## 部门界面： ### 负责人输入登录信息  ### 进入部门主界面，显示已收到简历的学生信息  ### 点击完善部门信息，即可进入部门信息填写页面，填写相关信息，保存后回到主界面  ### 在主界面点击蓝色简介可以查看学生写的详细介绍，点击返回回到选择界面  ### 选择完学生后，点击同意面试，会在学生端显示“已接收简历”，点击拒绝简历，将在学生端删除已选信息 ## 展示结束
## PSP表格：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | 10 | 15 |
| Development | 开发 | 15 | 30 |
| · Analysis | · 需求分析 (包括学习新技术) | ||
| · Design Spec | · 生成设计文档 | 10 | 20 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 20 | 35 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 30 | 0 |
| · Design | · 具体设计 | 40 | 60 |
| · Coding | · 具体编码 | 30 | 0 |
| · Code Review | · 代码复审 | 30 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 10 | 45 |
| Reporting | 报告 | ||
| · Test Report | · 测试报告 | 10 | 15 |
| · Size Measurement | · 计算工作量 | 20 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 40 |
| 合计 | 255 | 280 |
## 结对过程展示：   以及一张尴尬的照片：  因为我们是在教室，不太好意思麻烦其他在学习的同学帮忙拍照，就用手机录像，之后再截图的方式取照片，结果发现这个角度的录像一直没拍到头，所以就……但是衣服还是可以证明确实是我们两个的！
## 结对体会与总结：
叶文滔：
首先这次结对项目确实对我而言是比较新颖的体验，因为我接触代码、软件设计等计算机方面的专业只是都是在进入计算机专业以后，一直以来都是一个人完成作业之类的编码任务，也有少数几次与多个同学合作完成一个项目，但这是第一次与仅仅一名同学来合作。这个过程中我们需要单独来沟通各自的思路，所以初次交谈的时候还是有些紧张，会有些不知从何说起的尴尬，但是很快我们就适应了这个项目，讨论过程中也开始熟悉起来，在此之前我和杜宏庆同学是完全不认识的，所以我觉得不仅是收获到了如何进行原型设计（尽管不得不承认我们做的模型还是比较丑的），还提前学到了更重要的工作交际的能力，确实感觉很棒。
而关于本次项目，我觉得首先是学到了设计软件的一种新思路，即构建之法上的NABCD模型，确实让我对如何系统的去构造软件有了一个比较清晰的思路，第二点是新软件的学习，其实在之前我完全不知道原型模型是什么玩意，而且很奇妙的是百度上也没有关于原型模型比较简单具体的解释，基本都是原型模型有什么作用之类的，所以弄懂这个东西还花费了我一天的时间，才知道大概就是做一个预览界面，也通过这次学习了一些Axure RP这个此前从未接触过的软件，所以阅历上的收获还是很大的。
杜宏庆：
队友比较有经验，给我推荐Axure这款原型工具，我用了之后感觉挺好上手，不懂的地方还可以问他。结对相比于个人，可以取长补短，互相督促，大大提高了效率，我觉得这就是两人合作所带来的优势。
关于本次项目，目的是实现学生和部门之间双向选择的一个原型系统，让学生和部门之间可以双向选择。设计好界面后，把学生信息和部门信息收集起来，进行统一的管理，大大方便了部门和学生的选择。另外，我发现需求分析是一个项目不可或缺的一部分，起到至关重要的作用，只有把需求分析做好，才能顺利开展后面的工作。《构建之法》第8章中的NABCD模型可以很好地完成需求分析。