软件工程实践 2017 第一次结对作业
学生和部门互选产品原型——Associator
1. 结对成员
- 吴媛媛 031502336
- 李永盛 031502517
2. 需求分析
我们使用 NABCD 模型来进行需求分析。
2.1 N（Need，需求）
利用批注的方式，一点一点地分析实际需求和问题：
选择部门的现状：
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传。
宣传需要人为占据位置，印发海报传单，可以有一种更快捷高效低成本的方式，例如 APP 中统一的宣传版面；
对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。
申请表数字化可以节省材料成本，便于收集和使用；
各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。
算法可以在宣传中写明，使过程清晰化，双方明了规则；
筛选和淘汰的规则如下：
1，部门纳新人数和面试时间必须事先申报确定。
部门这一用户角色应当先申报，在宣传中写明（宣传海报必须指出纳新人数和面试时间）；
2，部门活动时间包括常规活动时间（如每周三 19 点 - 20 点）和临时活动时间，常规活动时间在纳新时候就要公布。
部门先申报清楚，在宣传中写明，在部员加入的部门信息中写明，常规活动可以提醒部员，临时活动可以临时提交并提醒；
3，如果一个学生常规部门活动时间请假超过 6 次，将面临被淘汰
部员可以在线请假，更加规范化，也方便记录、节省话费、时间；请假 6 次以上向部门和部员提醒；部员可以查询自己的已请假次数；
4，学生最多加入 5 个部门，但是要考虑部门活动时间冲突次数。
学生决定加入（申请）部门时自动提醒冲突和数量限制；
5，未参加部门面试的学生不能纳入部门。
部门对提出申请的学生面试后可选允许加入或拒绝。
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表使用本软件的学生可以提交电子申请表，手工收集汇总自动为部门收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力活动时间冲突提醒影响到的部门和部员，甚至进一步处理。学生在加入部门前对部门的情况了解有限在线部门情况介绍；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。在线学生信息填写以供部门了解，例如性别、爱好、成绩奖项
现在，现在，现在，我们很想做这样一个系统，请你和你的 “对友” 设计一个原型系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。痛点：信息化双向选择
根据以上的批注，和《构建之法》提到的功能分析四个象限，对以上总结整理如下：
2.1.1 必要、中心功能
- 模板化申请表，帮助部门快速制订申请表
- 部门提交与更改常规活动
- 部门提交临时活动
- 提醒部员参加常规与临时活动
- 学生决定加入部门时自动提醒冲突和数量限制
2.1.2 必要、外围功能
- 实现学生和部门之间信息化双向选择
- 部门注册、录入信息（部门情况介绍、筛选算法、常规活动时间）、制订宣传海报和申请表
- 学生注册、录入信息、查看宣传和填写申请表
- 收集汇总申请表供部门筛选，发出面试邀请
- 面试通过后将新部员加入部门，未通过则提醒学生申请失败
- 部门和学生的消息提醒功能（支撑各处的提醒）
- 部门、部员管理（增删改查）
2.1.3 非必要、中心功能
- 部员可以在线请假并记录，请假 6 次以上向部门和部员提醒
- 活动时间冲突提醒影响到的部门和部员，甚至进一步处理，如自动请假
- 模板化宣传海报、海报，帮助部门快速发出宣传
- 部门公告
2.1.4 非必要、外围功能
- 学生已加入的部门录入
- 特殊筛选算法的实现，不需要人工干预。例如某部门只需要女生、月贡献最高的三个部员自动评奖等等
- 部门投票
- 部门交流
- 部门的安排、计划发布与整理
- 部门财务管理
2.2 A（Approach，做法）
- 使用 B/S 模式或者移动端（Android / iOS），更方便用户使用场景，同时构建较为快速
- 做这样的解决方案的不多，可以解决社团与社员的痛点
2.3 B（Benefit，好处）
- 解决痛点，填补这一类需求的空缺——实现学生和部门之间信息化双向选择
- 方便易用， B/S 模式或者移动端（Android / iOS）是当今流行的生活方式，不需要和笨重的传统电脑软件甚至繁复的纸质文档打交道，对部门和学生都是这样
- 特色的活动通知功能，避免错过活动的尴尬
- 去不了活动可以请假，规范化管理更清晰明显
- 部门的申请表和宣传海报可以快速模板化生成
- 活动时间冲突提醒，解决混乱问题
2.4 C（Competitors，竞争）
做这样产品的不多，以上的需求分析如果实现，可能具有较大的先发优势，不仅可以实现稳定、规范化的社团管理（可能这样就能和现有产品持平了），还有一些特殊而实用的功能，例如活动通知、请假等，以至于未来的社团交流、活动安排规划等。
因此这款产品是有较大竞争力的。
2.5 D（Delivery，推广）
- 校园广播、贴吧微博推广
- 传统传单方式
- 与社团团长联系与畅谈，纳新和管理的时候可以水到渠成直接使用我们的产品
2.6 总结
综上，我们的产品——Associator（association 与人结合 的意思）可以解决部门和学生的信息化双向选择需求。我们用移动端构造的方法实现了宣传与申请社团，部门和部员的管理，活动安排与时间冲突的解决等大量功能，带来许多好处，市场上类似产品还较少，可以很好地满足社团与学生们的痛点。同时，我们使用传单、广播，甚至直接联合社团等方法快速分发和传播我们的产品，落地实践不在话下。
3. 原型系统设计
3.1 APP 功能结构
根据上面的需求分析，我们得出了如下的 APP 功能结构，叹号代表非必要、外围部分的功能，留待后期实现。
部门：
- 首页
- ！财务
- 收入、支出列表
- 记录
- ！畅聊
- 聊天
- ！投票
- 投票
学生：
- 部门
- ！已加入部门录入
- 社团列表（提交）
3.2 具体实现
我们使用Mockplus实现我们的想法，截图上的细节较少，请使用 Mockplus 的演示功能（跳转、点击等操作）查看具体产品原型。但 Mockplus 的导出功能限制较多，下载 Mockplus -> 打开 Associator.mp -> 演示 是较好的方案，见谅！
Mockplus 有 在设置某些链接后不会生效、底部导航栏显示白点的 bug，再次见谅。
源文件下载：Associator.mp
一些预览：
4. PSP 表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 15 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 15 |
| Development | 开发 | 785 | 910 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 120 |
| · Design Spec | · 生成设计文档 | 15 | 15 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 210 | 250 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 20 | 30 |
| · Design | · 具体设计 | 400 | 480 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 20 | 15 |
| Reporting | 报告 | 158 | 158 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 8 | 8 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 150 | 150 |
| All | 合计 | 963 | 1083 |
5. 结对过程
我们使用 Teambition 来完成此次结对任务。
利用 Teambition 的任务功能，我们建立了 阅读《构建之法》、需求分析、用摩客创建原型、编写博客 这四个主要的任务。其中阅读《构建之法》是各自完成，其他合作完成。
李永盛先创建了博客的模板，以让我们更明白主要要做些什么。把博客的模板发到 Teambition 的分享功能中，还可以一起编辑。
两者阅读完《构建之法》后（主要是第八章），着手使用 NABCD 方法进行需求分析，在 18 日上午讨论了需要改进的地方，写入博客，且合并进 Teambition 的分享，并开始建立原型。
19 日至 20 日，两者主要进行原型的建立，使用 Teambition 的文件功能共享。期间改动较大较多，耗费了不少的精力，主要是因为没有先考虑好 APP 的功能结构，导致多次不满意而迭代。
21 日至 22 日，主要进一步完善没有做好的原型，并编写博客。
18 日上午的讨论：
第二次讨论：
6. 结对心得与项目总结
6.1 吴媛媛
之前我常和别人组队（ACM赛制），但是探讨的问题和这次结对大不相同。本着锻炼自己编写面向对象代码风格的目的，我找到李永盛同学，征求他组队的意愿，经过尴尬的第一次交流，我们确定了结对。几次会面，我们交流各自想法，一步步做出了最后的原型...
这次结对，我收获很大，李永盛同学十分认真，需求分析阶段很有想法，也很乐于接受不同的意见，设计原型阶段是多亏了他做的整体架构分析，我才能很顺利的做好图形界面的架构。
期待和李永盛同学的下一次合作。
6.2 李永盛
整个项目是花费了不少心思的，从原型设计的工具选择（中文友好，免费功能多的可能 Mockplus 会好一点）到讨论需求分析结果的瑕疵，再到 APP 颜色的布局，甚至原型设计中不满意的地方一像素一像素移动部件等等。事情已经很多，要命的是还有很多其他事情要做。万幸终于堪堪做完，得到一个还算过得去的版本。然而在合作、时间把控、交流等方面还是有一些不足，需要改进，但是时间真的紧，所以应该说尽了最大的努力了。
合作有一个比较大的问题是没有先做好 APP 的功能结构和风格的设计，导致之后一直做一直不满意，重构，浪费了挺多时间，之后需要意识到磨刀不负砍柴功的道理。
和吴媛媛同学合作挺不错的，她设计原型认真，也乐于讨论，虽然很忙但都能尽量挤出时间来，是很好的队友，期待后续的合作。
