第五次作业———原型设计（结对）
结对成员
031502516 李佳莹
031502528 苏媛
[PDF文件] (http://pan.baidu.com/s/1miOfa5M)
原型设计工具
最先我们是先尝试了GUI Design Studio，究其原因是我看一些人的评价说是它较为简单一点。就下载的角度来说它倒是确实不难，但在我们开始在网上寻找它的使用教程和自主钻研的时候，我才真正地意识到了小马过河故事的意义所在。小马在自己下河走之前不会知道河水到底有多深，而我们在亲自使用之前也永远不会明白一个软件到底适不适合自己。
总之在下完它之后我们一筹莫展了良久，主要问题在于我们的英文水平不够，无法很好的理解每一个功能和按键，而网上又很难找到比较有亲和力的教程视频，所以最后我们选择换一个工具使用。
这次选用的是Mockplus，是在好友的倾情推荐下开始接触的。不得不说语言真的是一个巨大的鸿沟，跨越了之后的使用感觉较之前真的是轻松了不少。这款原型设计工具使用前需要先注册账号，并不是冗杂的举动，在注册后会收到官方发来的邮件，里面有着该工具的使用教程链接，可以说是非常贴心了。将它与先前下的GUI Design Studio做对比的话，个人感觉优势最大之处是在页面链接时，Mockplus可以直接用鼠标连过去，相较起来真的是显得格外便利。
NABCD模型
- N（Need，需求）
从本次题目中可以看出，我们总共有两种客户，一个是普通的，需要加入部门的学生，另一个则是部门里负责招生的那一部分管理员。
从困扰的现状中，我们可以看出，学生最大的难题是无法集中地获得各部门的活动时间，从而导致了个人的时间安排不畅，平白浪费了时间与精力。所以对于一个刚步入校园，想要加入部门的新生来说，他的需求就主要表现在对各部门信息的获取上。
而对于各纳新部门的负责人来说，他们手工发放申请表，手工汇总，再人工通知时间信息，太过混乱，所以需要一种更简便，更省时省力的信息处理手段。
- A（Approach，做法）
我们可以建立一个网站，提供一个平台为客户获取信息。
- B（Benefit，好处）
学生可以在上面获取自己想要的部门信息，如果有了想要加入的部门，也可以直接点击申请。他们还可以在上面看到自己所面临的面试和部门活动的时间地点，一目了然，不会出现因为遗忘或者疏忽而导致时间相碰无法处理的情况。
而负责纳新的部门管理员则可以在上面发布自己部门的简介，在未来的部门活动中，也可以发布临时通知，从而能够统一告知部员临时活动等事情的具体信息。学生可以在上面直接报名，因此负责人也不再需要手工发放宣传单和报名表。非常直接地在物力人力方面免去了他们很大一部分负担。
- C（Competitors，竞争）
呃，现在的竞争对手基本上应该是班里其他的结对CP 了。要论我方小组的优势的话，
可能就是我们特别情比金坚了，我们将报名的手续最大的简化。只需让学生一次性在个人信息页面将基础信息填好，报名时就只要在报名页面点击报名按钮即可，无需重复填写报名表单。
会有这样的想法，主要是当一个人报名多个部门时，报名表上的很大一部分基础信息都是重复的，反复填写这些信息很容易令人产生厌倦情绪，这极有可能会提前结束了部分学生探寻适合自己部门的步伐，在纳新期过去之后才觉得自己错过良多，这就很可惜了。嗯，当然，更主要的是，我们设计这个原型系统，最大的目标本就是能够将这段流程进行简化，能够让用户少动一点手，总归是没有坏处的。
这个做法也可能会出现一点弊端，比如每个部门获取到的信息相同，没有差异性。但这个问题可以很轻易的在面试环节中更一步了解到，所以我们认为，瑕不掩瑜。
- D（Delivery，推广）
理论上来说，推广一个用于学生与部门之间的产品，首先要从部门开始入手，部门接受了这个产品，就有了稳定的信息来源，自然就能吸引新生使用。
结对&照片
我们相性比较好，生肖比较配。
遇到的困难和解决方法
最大的困难就是最开头不得不更换原型模型工具，前面提过了，这里就暂不赘述了。
还有就是我们两人对于题目的理解在初级阶段发生了冲突，提出的想法也很有多相异之处。但万事胜在沟通，我们互相列举了自己思路的历程和提出这个想法的理由，在一条条慢慢梳理下达成了共通，也就形成了目前的这个设计。
设计说明
本次设计的项目树如下图：
登录界面
- 学生
- 管理员
学生登录
- 首页
- 部门列表
- 某部门界面
- 学生日程
- 个人信息
- 我的申请
- 我的社团
管理员登录
- 部门详情
- 部门纳新
- 部门成员
- 临时通知
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 15 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 15 |
| Development | 开发 | 360 | 535 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 200 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 30 | 30 |
| · Coding | · 具体编码 | 180 | 250 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 30 | 55 |
| Reporting | 报告 | 75 | 78 |
| · Test Report | · 测试报告 | 60 | 60 |
| · Size Measurement | · 计算工作量 | 5 | 3 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 15 |
| 合计 | 455 | 628 |
