一、结对成员
- 李芳凯 031502315
- 汪志彬 031502332
二、需求分析（采用NABCD模型）
- N（Need,需求）
- 学生的痛点
- 作为入学新生对于各个部门信息、职能了解较少
- 不了解部门时间冲突、未记录自己缺席次数而被淘汰
- 部门的痛点
- 张贴海报、发传单等传统宣传方式覆盖面不广且耗费人力
- 各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰
- 各个部门手工发放申请表，手工收集汇总，过程繁琐，工作量大，并可能出现信息丢失的情况
- 存在学生缺勤过多会被淘汰制度，人工记录活动签到情况并汇总到个人总的缺勤情况里较为麻烦
- 学生的痛点
- A（Approach，做法）
- app与web端的选择：为了便于随时随地查看、发布、修改信息等，我们觉得做成app会比较好
- 申请表提交与人员的录取均在app上完成
- 若所申请的部门上限已达五个或者所申请部门间存在冲突则提醒用户具体情况
- 临时活动可直接在app上发布，通过弹窗通知的方式提醒部员
- 通过每次活动是否签到记录每个部员的出勤情况
- B（Benefit，好处）
- 提供了一个新生了解部门、部门向新生宣传的渠道
- 省去了繁琐的表单整理
- 部门信息可以互通，可以知道每个学生加入的部门
- 特殊活动可以及时通知到每个部员
- 自动记录每个部员缺勤次数开除方便，同时学生也能了解自己缺勤次数避免因此被淘汰
- C（Competitors，竞争）
- 我方优势
- 功能简单，没有一些臃肿的可以被替代的功能（例如聊天功能我们就觉得没有必要，完全可以在qq或者微信上建立群聊替代）
- 操作简单，学习成本低。一目了然，没有什么隐藏得很深的功能。
- 我方劣势
- 界面不是很美观（原谅我们的审美）
- 可能有一些实用的功能我们并没有考虑到
- 我方优势
- D（Delivery，推广）
- 首先先联系一个部门进行推广使用，如果效果好的话就可以依靠口碑，推广到整个院学生会，到校学生会，以此类推。
三、原型系统
- 开发工具：MockingBot
- 登录界面。有两种身份登录方式：1、部门管理员与学生
- 管理员身份下
- 主菜单（包含四个模块）
-
部门信息管理点击后进行部门基础信息设置，点击更多信息之后可以上传一些展现部门风采的海报等
-
部门人员管理内可查看部门人员信息，查看缺勤次数，进行部门人员开除与纳新，可以对已报名我部门学生进行录取审核，点击查看可以看到该生信息
-
部门活动管理用来发布活动和活动签到信息管理（点击+可以发布新活动），签到采取双向签到，即学生签到后还需管理员确认才能确认该生有参与活动
-
- 主菜单（包含四个模块）
- 学生身份下
- 主菜单
-
个人信息设置，设置自己的基本信息
-
我的部门里可以查看已加入部门，查看缺勤次数，进行退部操作
-
部门活动里有我所参加的各个部门发布的活动，可以点击活动名称了解详情并进行签到
-
我的申请里面展示了有各个部门，点击可查看部门信息，了解自己的申请状态，并进行申请和申请的撤回操作（当我所申请的部门达到五个或申请的部门存在冲突时，系统会有弹窗提示）
-
- 主菜单
四、PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 45 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 45 |
| Development | 开发 | 370 | 430 |
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 40 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 300 | 330 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 20 | 20 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 10 |
| 合计 | 380 | 435 |
五、结对过程（有图有真相）
是在微信班群上结对完成的，因为是同班同学，所以也不会生疏，合作得也比较顺利，不用有互相熟悉的过程（没想到图片上传居然是歪的，2333，应该可以治好程序员多年的颈椎病）
六、心得体会与项目总结
- 项目总结：在本次项目中，我们大体完成了利益相关者所提出的需求，但是可能还是一些没有考虑完善的地方可以改进，界面设计还有很大的优化空间。
- 心得体会：
- 李芳凯：这是大学以来首次与他人合作完成作业（实践课除外）。合作的过程是有趣的、有益的。体验双人合作的好处，不仅可以互相交流想法，还可以轮流工作，产生了一加一大于二的效果，为今后团队合作打下基础。之前并不了解原型设计是什么，在完成此次作业后，基本掌握了如何进行原型设计，并了解了原型设计的作用（早上栋哥的课上刚讲过）。同时学会了如何用NABCD模型进行需求分析（确实是一个很强大的模型，条理清晰）。总而言之，此次结对作业收获颇多，不仅有知识上的收获，而且还学会了如何与人合作与交流，相信这将是一笔宝贵的财富。也愈加期待之后的合作。
- 汪志彬：这次的结对作业是关于部门管理的，是在大学社团管理经常会用到的功能，所以软件的现实意义很强。自己在这一次的实践中大概了解了软件功能实现的全部步骤，更加深入地理解了“自顶向下，逐步求精”的设计方法。还学会使用功能强大的墨刀编辑界面的方法。在这次和李芳凯（031502315）的合作中，感到十分的愉快。这也算是学习计算机一来第一次和别人合作完成任务。大的方面都是芳凯操刀，我只是在旁边给他给他点建议，帮助修修改改，确实是抱了他的大腿，哈哈。这也警惕我，要加强学习，以后可以不那么狼狈。谢谢芳凯在合作过程中的体谅和指导。