结对项目——第一次作业
标签（空格分隔）： 软工实践 结对项目
结对成员
031502404 陈邡031502443 郑书豪
客户需求
开学初加入学生会部门的迫切需求——选择部门和课余时间冲突之烦恼
选择部门的现状：
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下：
- 部门纳新人数和面试时间必须事先申报确定；
- 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
- 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
- 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
- 未参加部门面试的学生不能纳入部门。
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
现在，现在，现在，我们很想做这样一个系统，请你和你的“对友” 设计一个原型系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。
ps:标注了客户在字里行间透露出的无奈和重点需求(233
需求分析
N(Need,需求)
- 学生会部门
- 对部门进行介绍和宣传；
- 申报纳新人数和面试时间；
- 对学生的基本信息有所了解；
- 将面试结果信息化公开；
- 按一定规则对学生进行筛选和淘汰。
- 学生
- 上传学生的基本资料；
- 对学生会各部门的基本信息都有所了解；
- 报名参加各部门面试；
- 加入部门后可以查询部门相关活动信息；
- 获取部门面试相关通知(一般为多轮面试)。
A(Approach,做法)
由于纳新工作只在每年新学期初进行，不需要做成app，只需要在web端实现学生部门双向选择系统就能满足纳新工作需求。
学生会各部门和学生分别使用管理账号和学生账号登入系统，具体互选流程如下。
1.系统准备阶段
系统暂时不对学生账号开放，学生会各部门管理人员通过管理账号进入系统，完善部门信息并申报纳新人数和面试时间。
2.学生选择阶段
(1)系统面向学生账号开放，通过学生账号进入系统，完善基本资料并进行实名认证;
(2)学生通过部门提供信息进行了解和选择，填写申请表，报名参加面试。
3.部门面试阶段
(1)各部门按申报时间对报名学生进行面试；
(2)若部门设有多轮面试，在该轮面试后向通过学生推送通知，告知其参加下一轮面试；
(3)重复以上步骤直至面试阶段结束。
4.部门筛选阶段
(1)各部门在面试阶段完全结束后，将最终纳新名单上传至系统，并向学生推送通知；
(2)若部门纳新人数少于实际需求，可增设加试，继续筛选学生，然后确定最终名单。
5.后续审核阶段
(1)各部门可在系统中对每次活动进行考勤统计；
(2)如果一个学生常规部门活动时间请假超过一定次数(6次)，系统将向部门推送通知，部门可将该学生淘汰。
B(Benefit,好处)
- 学生会各部门和学生之间实现基本信息透明化，可在互相选择之前有所了解；
- 学生填写申请表这一过程实现信息化，让部门在整理信息时更加便捷，同时也能节省资源；
- 各部门可以对学生活动出勤情况进行统计，便于推行淘汰制度；
- 减轻学生会纳新活动中各部门的工作量。
C(Competitors,竞争)
- 优势
- 目前学生会的纳新活动仍然是采用传统的方式，还没有成熟的信息化系统出现，市场竞争很小；
- 加试功能可以满足纳新人数不足的部门的需求；
- 考勤统计系统便于部门对学生进行监督管理。
- 劣势
- 参与软工实践的同学也在做同一项目，其中有许多项目经验丰富的优秀同学参与竞争；
- 组内队员对web端开发很不熟悉，需要一段时间的学习，后续开发
(如果)需要花费大量时间。
D(Delivery,推广)
向本院学生会发出系统试用邀请(舍友是院学生会主席)，协助进行院学生会各部门的纳新工作。如果试用效果较好，可以向其他院系学生会或校级部门进行推荐，更好地推广该系统，并且从中获得建议来对该系统进行改进。
项目特点--"电梯演说"
我们的产品学生部门双向选择系统是为了解决学生会部门的痛苦，他们需要将纳新活动信息化，但是现有的产品并没有很好的解决这些需求。我们有独特的方法：在web端实现学生部门双向选择系统，学生会各部门和学生分别使用管理账号和学生账号登入系统，实现互选信息化。它能给用户带来好处：大大减少纳新活动中的工作量和资源投入，远远超过竞争对手(软工实践中的各组同学)。同时，我们有高效率的邀请院学生会试用并进行推广方法，能很快地让目标用户知道我们的产品，并进一步传播。
原型模型
功能结构图
使用ProcessOn Mind完成
原型图片
-
系统主页， 朴实无华(233，新生可以通过风采展示模块对部门信息进行初步了解
-
学生/部门登录及注册
-
部门主页，各种强(jian)大(dan)功能的入口
，配色丰富= =
-
部门信息页面，可进行编辑修改，主要用来让新生了解部门信息和展示部门风采
-
部门活动安排页面，提供了添加活动，修改活动和删除活动的主要功能
- 添加活动
- 修改活动
-
部门考勤管理页面，对部门活动出勤进行管理统计
，防止二五仔浑水摸鱼
-
部门面试申报页面，纳新工作中的重要一环
-
部门面试名单页面，用于查看报名面试的新生的报名表和基本资料，让部门能对学生有一个初步了解，同时增加了导出名单的功能，方便部门进行面试准备
-
部门面试结果页面，部门将各轮面试的结果在此上传，系统将向通过面试的学生发出通知，参加下轮面试
-
部门公告发布页面，提交申请后由系统管理员审核后发布于公告栏
-
学生主页，各种功能的入口
，一样的配色风格
-
学生我的信息页面，可以进行编辑修改
-
学生我的部门页面，用于加入部门后的同学对部门情况和活动安排进行查询，同时也可以实时关注自己的缺勤统计
，色彩斑斓的界面洋溢着青春的气息= =
-
学生面试报名页面， 参与面试的第一步，报名
- 报名成功后提示面试信息
-
学生面试详情页面，可以对自己参加的面试结果进行查询
原型模型链接
模型链接
原型开发工具：墨刀
(web端轻便快捷，界面看起来比较简单友好)
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 330 | 480 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 120 |
| · Design Spec | · 生成设计文档 | 30 | 60 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 60 | 60 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | - | - |
| · Design | · 具体设计 | 180 | 240 |
| · Coding | · 具体编码 | - | - |
| · Code Review | · 代码复审 | - | - |
| · Test | · 测试（自我测试，修改代码，提交修改） | - | - |
| Reporting | 报告 | 30 | 30 |
| · Test Report | · 测试报告 | - | - |
| · Size Measurement | · 计算工作量 | - | - |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 390 | 540 |
结对过程
附上对友热烈讨论原型模型的照片(左-郑同学，右-陈同学)ps:桌面杂乱= =
- 指点*
- 激昂文字
-
谈笑风生
结对心得及项目总结
郑同学：
第一次参与组队完成的作业，感觉还不错。
在此次结对过程中，由于前期对友忙于数学建模比赛，就由我先开始做需求分析的部分，参考了《构建之法》和历年学长学姐的结对作业(栋哥的博客园置顶是个好东西)，最后用NABCD模型完成了需求分析。然后和对友一起探讨后，对需求分析做出了一些调整和改进，最终定稿。
后来的原型模型设计主要由对友完成主体(出来混早晚要还的233)，然后两个人一起讨论、制作、改进，并进行了一些美化工作，完成了最终的模型。对于墨刀的使用也熟悉了起来。ps：最后就希望下一次结对作业不要让我们去实现这个系统。= =
陈同学：
首先，《构建之法》这本书主要介绍了软件测试、编写代码的规范、团队合作的重要性、软件工程师的成长、还有开发软件项目的总体流程等等，大致粗略的阅读没有很来的及去咀嚼其中的很多精华，书中的内容丰富多彩，跟其他的软件工程书不一样，这本书的内容给读者一种欢快的阅读体会，能让人更加的快速去接受里面的内容，并吸收为自己所用；最重要的是，里面的内容都举例生活中的例子，使人看上去更加的了解软件工程，软件工程就在我们身边。
其次，大致了解了墨刀这一工具的使用，发现其将建立APP而或建立一个web模块化，很多的事情可以有一个一个的小组件构成，使得去做一个简略的界面不在需要计算机的基础，十分的适合大众的使用，其次发现其中的组件结构简单不能很好地完成很多的稍微复杂的事物，这是有待改进的地方。