（1）随笔开头，给出结队两个同学的学号。（1‘）PS：结对成员不能是同一团队成员。
- 031502509
- 031501118
（2）对客户需求进行需求分析 ，可采用NABCD模型。（5‘）
- 客户需要的是一个能简化流程，能通过其中如下的功能选择到合适的部员的，能加强学生和部门之间相互了解的一个系统。
- N：
- 1：线上申请线上收集网络申请（对自己简介加入部门的一些问题）（痛点1：流程繁琐人工耗费时间）
- 2：能看到常规时间活动及加入临时活动（痛点2：不了解部门及各部门信息不畅通）
- 3：部门介绍及部门风采（同2）
- 4：通过表格内的设定及算法上设定，有效缓解，解决筛选淘汰问题。包括：
- 1：如果IF（请假超过6次）则被“一键淘汰”键淘汰
- 2：如果IF(加入部门超过5个)则提醒“加入部门超过五个，请重新选择”并禁止继续选择，否则，如果少于5个，那么，在选择部门时候，如果时间冲突则提醒“当前部门活动冲突，请重新选择”。
- 3：如果IF（未面试）则淘汰。
- 5：学生信息管理员和部门人员的查看和填写。
- 6：发布部门通知，和活动地点申请。
- A：
- 1.能简化流程，线上收集及人工和系统自动筛选（人工：例如下面3中那个打游戏问题；系统自动：筛选和淘汰条件），解决人工申请步骤复杂的问题；
- 2.能使各个部门信息公开化，（能通过对活动时间以自动生成活动表形式的公布，在填写申请表的时候就能看到，和在选择部门时候以点选的形式以系统内部算法辅助提醒，
例如“您所选的时间冲突”及“您选择的部门超过5个”等提示语的形式，用人的主观断定和系统的辅助断定）解决各部门信息沟通不畅，导致活动时间冲突而被淘汰的问题； - 3.通过部门介绍及在申请表格时候由部门的人对学生设置小问题（除了日常问题，可设定是否打游戏，等等诸如此类的问题），
这两方面来使学生和部门之间相互了解，解决因相互不了解而被淘汰问题。 - 4.辅助功能可以录入活动时间信息和编辑部门通知等。
- 5.宣传不利这方面就是第一句话的解决方法还没想到，只能说线上这些例如用微博微信公众号qq推广的方式只能缓解这些线下宣传的弊端，并不能用系统来解决这个问题。
- 独特的方式：独特之处在于1.我们的界面设计友好合理。我觉得大多数男同胞的界面做的都像我一样烂，但是我们有女队员可以将界面做的很好。
- 下面的对比，好坏一目了然。选择女队员是明智的选择。
- 我做的：
- 她做的：
- 我做的：
- 我们还有一个优势就是在查看表格时候，有一个申请和淘汰选项，先在人工查看之前淘汰一部分的不符合条件的人。
- B:
- 好处：这么设计有什么好处呢？
- 1:首先，使流程简单化。2：解决信息不同造成的问题。3：通过这个新系统（可能和别人差不多的功能）来实现对这个问题的解决。
- C:
- 和其他人的竞争，我们的优势是什么呢？我觉得就是一键淘汰和一键通过及提醒和时间表。通过人，机结合达到我们所想达到的目的，平手的地方呢？页面功能大多数都一样啦。就是那我们的劣势呢，就是像用户（学长）说的设计太死板没有新意。
- D:
- 推广：首先要是学生部门采用，然后可以在新生的群里推广，让他们知道有这么一个系统。
- N：
（3）为客户需求设计一个原型系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。要求样式清晰、图文并茂，并说明你所采用的原型开发工具。（5‘）
- 1.上面讲了那么多，接下来就是展示了，首先就是登陆界面，虽然和普通的看起来没什么两样，但是，里面在我前面的总结的学生和部门的痛点中,解决一个了，那就是部门信息的发放。在各部门告示中，各部门的管理员可以发布一些常规活动时间，以此来解决各部门信息交流不畅导致的常规活动时间冲突而导致学生缺席常规活动次数过多而被意外淘汰。
至于下载专区里面放的是一些活动场地申请表，以及部门的报名表。
还有上面的重要的活动时间表，在以上三个告示栏中就可以体现。还可以以部门人员和申请人员的身份，进入系统。注册及找回密码。
- 2.点击登录，以学生身份登录学生子系统，可以完善学生信息，申请成为管理员，可以点击查看各个部门信息，这和前面公告栏不一样。最后是最最重要的，报名，和时间表，这个报名放在最后一个，我觉得完全符合人的视角及工程力学。（。。。）就是最重要的放在最后这个道理嘛。还有时间表，这就是学生他自己能够查看，能够自行判断时间是否冲突，再加上算法，两者结合来避免冲突。
- 3.这个就是学生信息完善了。
- 4.这里是提交申请表，申请成为管理员。这可是很重要的啊，学生变成部员，有意愿直接从部员变成管理员。
- 5.最重要的就是它了，那些筛选算法和其他问题类就在这里，管理员可以在本地添加表格，在线上审核。进入这里的学生，就可以提交申请表，选择部门。整体提交。在这里学生就可以填写那些特殊问题，并且有一个时间表提醒和提示语提醒。
- 6.管理员界面的功能和学生界面不同，管理员信息，查看报名表并进行一键筛选及人工筛选。发布首页的部门通知。查看部门系统有志愿想当管理员的申请。还有最重要的是部门活动地点的提前申请。抢占先机，线上线下，一起，我觉得会取得比只在线下宣传的更好的效果。
- 7.管理员信息的完善。
- 8.独特的功能一键淘汰及人工查看功能，使删选更功能化简单化，不符合条件的（就是上面的6个淘汰条件）通过算法，一键淘汰，符合第一步的，再由人工审核，并决定通过与否。关于人工与电脑筛选的顺序，会在使用文档中给出我们的建议
- 9.部门的活动地点申请，抢占先机的关键。
- 10.管理员申请表的确定及评审。
- 我所用的是Axure RP 8，她用的是GUI，之所以选择她的是因为我界面实在太差。她真是女孩子做的比我好太多。以后要多多努力。
（4）记录本次作业的PSP表格，包括预估耗时及实际耗时。（1‘）
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 20 | 30 |
| · Estimate | · 估计这个任务需要多少时间 | 25 | 60 |
| Development | 开发 | 3800 | |
| · Analysis | · 需求分析 (包括学习新技术) | 100 | 160 |
| · Design Spec | · 生成设计文档 | 100 | 50 |
| · Design Review | · 设计复审 (和同事审核设计文档 | 30 | 60 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 45 | |
| · Design | · 具体设计 | 180 | 200 |
| · Coding | · 具体编码 | 1000 | |
| · Code Review | · 代码复审 | 200 | |
| · Test | · 测试（自我测试，修改代码，提交修改） | 720 | |
| Reporting | 报告 | 500 | |
| · Test Report | · 测试报告 | 300 | |
| · Size Measurement | · 计算工作量 | 100 | 120 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 100 | 200 |
| 合计 | 7120 |
（5）描述结对的过程，提供非摆拍的两人在讨论、细化和使用专用原型模型工具时的结对照片。（1‘）
- 在班里所有人都结对完以后，我搭上了末班车，和现在的搭档一起合作，正所谓山重水复，柳暗花明。我觉得合作很成功。从一开始的预想共同讨论，她的思路比我清晰，中间在qq交流。交流想法，最后成型。很开心一起合作。构建之法里说，两个人合作，一定要相互谦让。我觉得就是这么和谐的体现吧。
（6）第一次和结队的TA合作肯定感慨万千，分享本次结队的心得和本次项目的总结 。PS：需注明是哪位同学的心得体会。（2‘）
- 杜实得031502509：通过这一次，我懂得了NABCD模型，了解了可能是用户交互体验设计师的工作步骤，也学会了Axure RP 8的使用，可能以后还要学习一下怎么设计更好的界面，app什么的也可以用到啊。还学会了双人合作，确实和独自战斗不一样，如果分工合理，那么确实很省力。还有，如果通过，那么我觉得自己学会了一点分析需求，还有用模型文字把它表达出来。我觉得这是很重要的。特别鸣谢我的伙伴，合作愉快！！！
- 黄梅玲031501118：第一次接触到这种结队项目，其实刚开始还是比较迷茫，不知道该从哪里做起。然后看了《构建之法》这本书，感觉了解了一些概念，知道了大体的实践步骤，但是真正运用到实际还是不知道从哪里着手。所以，首先要有一个方向，即清楚自己想要做出一个什么样的效果，以及自己做出来的项目要有什么样的功能，要考虑是否能够满足用户需求，因为自己作为一名大学生，经历过大一加入部门时的不便之处，所以可以设身处地地想用户会需要什么功能。有了大体模型之后，就开始学习建模工具的使用，这点我的合作伙伴还是比较擅长，可以很快学会建模工具的使用。建模过程中遇到一些问题也会讨论，寻求更好的解决方法，因为每个人的见世面不同，所以对于一些问题的看法也不同，这样才能解决所遇到的困难，我想这就是合作的意义吧。