《高级软件工程》结对第一次作业
第一次结对作业
结对人员：
潘伟靖 170320077
张 松 170320079
方案分析
我们对所供的资料进行分析，如下：
从提供的资料可以看出，需要解决的问题以及满足的需求主要有两类目标用户，各自有不同的情况需要解决。
从社团负责人角度看：
- 目前纳新工作仍然是传统手工发放、学生填表、部门相关人员梳理，统计的流程。
- 筛选申请人员时对申请人的信息不了解。
- 在对于常规活动请假超过6次的学生的统计上，需要额外工作。
从学生角度看：
- 在申请加入社团之前，对于社团的了解也仅仅局限于在广场上看到的纳新宣传，了解并不充分。
- 对于自己申报这个社团，是否有时间冲突，可能需要进行查表等操作，相当于加大了工作量。
因此，在对我们所掌握的资料进行分析之后，我们通过NABCD模型进行方案的设计：
N(Need)
- 无论是从社团负责人角度看，还是从申请人的角度看，他们共同的痛点，就是目前的社团纳新工作流程不够电子化，信息化。
- 申请人，需要了解社团的详情、曾经的活动、本次纳新人数、常规活动时间等常规的信息。他们需要的是随时的、尽早的了解、对比，而不是到社团纳新当天在广场上匆忙的抉择。
- 学生需要有一个系统，能够提醒他是否他所要申请的社团与已加入的社团的常规活动时间存在冲突。
- 对于社团的负责人来说，需要的是便捷的处理申请，在申请中，需要看到申请人的申请资料来进行筛选或拒绝操作。
- 社团负责人需要对常规活动请假次数超过6次的社团成员进行相应的操作。
A(Approach)
在具体的做法上，
- 首先需要电子化，信息化的工作，那么，就需要先选择出做什么形式的软件。由于移动app的移动性较好，可以做到学生随时随地了解、对比社团以及社团负责人随时进行处理的需求，故选择以基于Android的app的方式处理。
在学生端：
- app启动->学生登陆->社团展示->申请加入->提交资料申请->完成提交。
- 查看申请动向以及取消申请。
社团负责人端：
- 查看以及发布活动内容等信息。
- 对于申请的学生进行管理，如拒绝、发送面试邀请等操作。
- 对于常规活动请假次数超过6次的学生进行操作。
B(Benifit)
- 对于学生来讲，较早的了解社团详情，较早产生申请社团的候选名单，不至于匆忙决定。
- 对于社团负责人来说，对申请人的操作，不必再去一张一张的申请表去查找，遴选等，对于申请人再申请时的一些附加信息也可以通过手机看到，减少了人工本。
C(Competitors)
- 为了充分估计该系统的应用价值和市场空间，碰巧又赶上福大社团招新活动，所以我们简要询问和观察了各社团招新的活动过程。观察结果表明：
- 社团招新使用的是传统的手工填表的方式进行信息统计；而社团的面试通知和活动通知一般是使用邮箱或短信这种低效率的方式进行；
- 各个社团之间相互独立，信息不通，彼此之间没有太多的交流；社团活动申请需要一系列繁琐的程序，包括人工审核等；
- 没有相应的平台供社团管理人对社团人员进行有效的管理并将信息及时反馈给社团人员。
- 我们可以判断出目前并没有可用的社团活动管理软件。对于高校社团管理这一市场我们可以说是捷足先登，有着不可多得的先发优势。而且基于手机端的app方便目标用户的使用。我们的软件能有效的帮助社团管理人员管理社团事物，同时能够帮助希望加入社团的学生更有效地掌握社团招新动态。此外，在后续的版本中我们可能还会加入社团间的活动功能，方便社团间的交流。
D(Delivery)
- 本着方便管理服务学生的原则，我们会把软件的推广重心放在各社团管理部门:
- 联系校方相关人员进行软件的展示和推广，最好能打入学校管理内部，成为学校官方主推的管理方案；
- 其次，联系各社团负责人进行软件的宣传和推广，让他们能看到该软件带来的便利和效率，建议他们在社团管理活动中使用。当然，只要该软件被学校和社团方面接纳了，学生方面就不成问题。
- 为了利于推广和使用，我们可以将软件上架各大应用商城。在社团招新时使用该软件进行学生信息的录入和社团申请，使学生主动使用该管理软件。
原型模型的设计
原型模型必须采用专用的原型模型设计工具实现，经过使用和比较，我们最终采用了Axure Rp 8.0作为本次设计的工具。Axure Rp提供了丰富的原型模型设计的模板和资源，同时简单易用使得用户能很快设计出理想的模型。
设计的原型图如下：
从图中的展示我们可以看到，本系统的客户端是基于Android app。而客户端主要是针对两类不同的用户而设计。
首先用户进行注册登陆，系统从用户登录信息可以判断出该用户是学生还是社团负责人；对于学生来说：进入系统后可在主页上看到各社团的简介；点击简介进入社团详细信息页面，同时可以申请加入该社团；提交申请后可以取消，也可以等待社团负责人的面试通知；收到通知后可进行面试；面试通过后方可加入该社团。
对于社团负责人来说:进入系统后直接看到关于自己所管理社团的申请情况；负责人可以对点击对应申请查看申请详情，同时可以向申请人发出面试通知；在确定某同学面试通过后可向其发出面试通过消息；此外，负责人可以在该系统中记录平时的社团活动，查看社团成员详情等。
效能分析与PSP
此次结对的效能分析和PSP如下：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 20 |
| Development | 开发 | 540 | 620 |
| · Analysis | · 需求分析 (包括学习新技术) | 100 | 120 |
| · Design Spec | · 生成设计文档 | 80 | 80 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 30 | 30 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 40 | 40 |
| · Design | · 具体设计 | 60 | 60 |
| · Coding | · 具体编码 | 200 | 260 |
| · Code Review | · 代码复审 | 10 | 10 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 20 | 20 |
| Reporting | 报告 | 140 | 150 |
| · Test Report | · 测试报告 | 50 | 55 |
| · Size Measurement | · 计算工作量 | 40 | 45 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 50 | 50 |
| 合计 | 700 | 790 |
