17秋 软件工程 结对项目 第一次作业(队友副本)

17秋 软件工程 结对项目 第一次作业

成员

• 陈翔，031502209；
• 李鸣，031502316。

客户需求

0.背景

开学初加入学生会部门的迫切需求——选择部门和课余时间冲突之烦恼

选择部门的现状：

各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下：

• 部门纳新人数和面试时间必须事先申报确定；
• 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
• 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
• 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
• 未参加部门面试的学生不能纳入部门。

现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。

现在，现在，现在，我们很想做这样一个系统，请你和你的“对友” 设计一个原型系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。

1.需求，Need

细分为三个方向、两个时间段。

三个方向为：

• (1)学生 => 部门；
• (2)部门 => 学生；
• (3)部门 <=> 部门

两个时间段：

• A.纳新；
• B.运行时

说明：

(1)学生 => 部门

A.纳新：

• 学生填写基本信息；
• 选择少于五个部门，向部门提出报名申请；

B.运行时：

• 学生接收来自部门的活动消息，如果有冲突即时反馈部门管理人员；
• 学生请假，提交请假申请。

(2)部门 => 学生

A.纳新：

• 推送纳新通知，体现纳新总人数、面试时间以及常规活动时间；
• 给出部门信息主页，允许学生对部门进行全方面了解；
• 接收来自学生的报名申请，及时反馈学生信息；
• 纳新结束之后，批准、回拒学生申请，推送消息反馈学生。

B.运行时：

• 推送平时部门通知、活动消息，接收来自学生的反馈信息并加以调整；
• 进行人员管理，能够查看成员请假次数，淘汰成员，并消息推送。

(3)部门 <=> 部门

A.纳新：

• 推送纳新通知，也能够查看其它部门的信息及情况。

B.运行时：

• 接收来自其他部门的活动信息；
• 向其他部门推送平时活动信息，私密信息可以选择不推送。

2.方法，Approach

A.满足要求规则：

1.部门：事先申报确定部门纳新人数和面试时间；

部门发布公告消息，推送学生和其他部门，说明包括纳新人数、面试时间、常规活动时间等信息。

2.部门：部门活动时间包括常规活动时间（如每周三19点-20点，纳新时公布）和临时活动时间；

部门在发布纳新公告时发布常规活动时间，临时活动时间在平时以推送消息的形式发往各个同学。

3.部门：如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；

学生在平时可以向部门提交请假申请，部门方由人员管理模块实时记录，并在某一位同学请假超过6次之后自动推送信息，由部门管理人员进入管理模块对该同学进行淘汰审核。

4.学生：学生最多加入5个部门，但是要考虑部门活动时间冲突次数；

部门信息透明化、公开化，学生选择部门时，能够得知部门常规活动时间，并加以判断；

学生选择超过五个部门时，给出提示；

学生加入部门之后，在接收到来自部门的平时活动消息推送之后，若有冲突，能够及时、迅速通过消息回复管理者，管理者重新制定、发布消息。

5.学生、部门：未参加部门面试的学生不能纳入部门。

部门接收到来自某一个同学的申请之后，将该同学列入待审核对象；在面试结束之后管理者进入人员管理模块，统一批准、拒绝申请。

B.解决现状困扰：

各个部门手工发放申请表，手工收集汇总。

学生在注册时填写相关信息，如学号、个人优势等，进入部门报名申请之后选择部门发出申请，部门自动接收，并消息推送管理人员，管理人员查看学生申请和个人信息并审核。

各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。

部门之间活动信息公开，与部员线上交流获取课程时间，安排活动时间时避免冲突。

学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。

通过部门、学生间信息交互，建立了双向完全透明公开的信息渠道，避免了上述问题。

3.优势，Benefits

• 实时推送消息，社团交流实时敏捷；
• 部门间信息交流公开透明，同时保留一定私密空间；
• 纳新流程自动化，对用户来说屏蔽了一系列不必要的细节；
• 管理人员发生误操作容易补救；
• 解决用户痛点的同时，预留了增加功能的空间。

4.竞争，Competitors

优势：

• 相对于现有发布的一些设计而言，技术上实现并不困难；
• 既考虑特定场景(纳新)，也考虑常见场景(运行时)；
• 领域专用，针对性强；
• 使用简单方便；
• 占用空间比小；
• 没有繁杂冗余功能；
• 需求变更，更改方便。

劣势：

• 由于领域专用，不适合拓展到其他领域；
• 暂无其他功能。

5.推广，Delivery

• 1.微信公众号推送；
• 2.QQ班群；
• 3.贴吧、知乎、微博大V推送；
• 4.在福州大学学生常用APP，如福大助手的显眼位置，或者启动时推送广告；
• 5.一区、三区门口传单；
• 6.教学楼、院楼海报；
• 7.联系各大社团领导者，免费试用；
• 8.十月份社团纳新时，在各个社团的帐篷旁宣传，更高级的是附加二维码，扫一扫注册，选择社团。

原型设计：

移步：http://www.cnblogs.com/zxlmhh/p/7572275.html

PSP Table：

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	15	10
Estimate	估计这个任务需要多少时间	15	10
Development	开发	200	260
Analysis	需求分析 (包括学习新技术)	60	90
Design Spec	生成设计文档	110	150
Design Review	设计复审 (和同事审核设计文档)	30	20
Coding Standard	代码规范 (为目前的开发制定合适的规范)	None	None
Design	具体设计	None	None
Coding	具体编码	None	None

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Code Review	代码复审	None	None
Test	测试（自我测试，修改代码，提交修改）	None	None
Reporting	报告	25	20
Test Report	测试报告	None	None
Size Measurement	计算工作量	10	5
Design Review	设计复审 (和同事审核设计文档)	10	5
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	5	10
合计		240	290

总结

李鸣：这是第一次结对作业，能和我翔男神一起结对就很舒服，我们这次一共花了三个晚上，第一个晚上在福大三区的贡茶讨论了NABCD模型，后两次是在我的宿舍设计原型模型，我们使用的是墨刀这款功能强大的原型设计工具，在暑假我也做过一点网页界面，大体也知道一个流程，但是对于墨刀工具并不是很了解，以至于到快做完的时候才发现墨刀还有很多其他很符合人性化的功能，感觉很神奇，也希望之后能够再深入了解它的强大之处，不过，我对我们做的模型还是比较满意的，个人也是比较喜欢简洁的APP，每次看到黑白，墨画的APP，都会好感度提升很多，所以设计自己的模型时候就挺喜欢这种简单美。至于这次在完成的过程中，也没有那么顺利，因为是第一次和别人合作做东西，才发现原来事情没那么简单，在一些细节上面也会出现分歧，也会有一些意见不同，但是最终都能找到一个折中的办法。总的来说这次学到了挺多新的东西的，也希望在下次的结对作业中能和我翔男神更好的磨（P）合（Y），最后一句，我翔牛逼！！！！

陈翔：结对的过程是很经典的起步早、结束晚：在课程上说明结对编程之前就已经获取了要结对的信息，先一步与我鸣结对。按道理来说是会快人一步的，但是两个人事情都是相对其他对来说比较多的，我们这一周才刚刚开始着手做这个事情。我比较关心需求分析的这一步，因此最终提交的原型图直到截止日期前一天晚上才完成，花了一个晚上奶茶局讨论用户需求，画workflow，看《构建之法》、历年学长学姐的博客，边做边逐步完善，最后成型，相比预估花了不少的时间。虽然最后比较赶，但是最后还是及时踩点完成了。收获的经验除了NABCD需求分析之外，还认识到了预估时间后安排时间的重要性。和我鸣的结对是非常轻松加愉快，虽然狗粮满满。。但是对友的椅子真的很舒服！

真实需求, 17/9/27

信息渠道: 某大型社团负责人。

需要增加的功能

• 1.搜索功能: 纳新时，搜索对应申请人员的申请表格；运行时，搜索对应部员的信息；
• 2.评分功能：在应用中给面试的对象打分；
• 3.排序功能：面试结束之后，点击结束按钮，自动按(1)分数 (2)性别 进行排序，择优选择。

上述功能应用背景：今年纳新共收到了100多份申请表格，如果要找到对应的申请人是非常麻烦的一件事情；在面试的时候需要调出相关人员的资料，面试结束之后对于该对象的评分也需要记录，并人工对所有面试对象进行分数排序。此外对于男生和女生，每个部门都预留有对应的纳新人数，因此对于性别来说十分重视(都想招小姐姐)。

• 4.生日提醒功能：在某个部员生日将要来临的时候，系统自动推送消息给社团管理人员。

上述功能应用背景：部长需要根据部员的生日分布来决定部门聚会、娱乐活动的时间段。

• 5.收到信息之后，部员点击确认自动回复。

上述功能应用背景：组建了一个部门，就会有自己的群，然后群里会有通知，但是没办法保证每个人收到，所以必须再发一次短信，很麻烦。

解决方案

搜索功能: 纳新时，搜索对应申请人员的申请表格；运行时，搜索对应部员的信息

在原有界面中增加搜索框，支持姓名、学号搜索。如果是部门成员则返回他/她的注册信息；如果是申请人员返回一个有两个模块的界面，一个模块是注册信息，另一个是纳新评分表格(如果有)。

2.评分功能：在应用中给面试的对象打分；
3.排序功能：面试结束之后，点击结束按钮，自动按(1)分数 (2)性别 进行排序，择优选择。

暂定：在部门界面中为纳新新增一个版块“纳新”，有以下几个子模块：

• (1)生成评价表格：用于面试官在面试前生成评分表格，提供几个基本的评分表项，如"礼貌(10分): ___"，并支持自定义表项和对应分值。
• (2)面试评分：提供搜索栏，在纳新时搜索对应申请人员，返回一个有两个模块的界面，一个模块是注册信息，另一个是纳新评分表格；面试结束之后可以将评分填入模块并保存。
• (3)面试结果：生成三个表格，可以通过下拉框选择，一个是所有人总得分的排名，一个是男生总得分的排名，一个是女生总得分的排名；将之前的“申请管理”合并到该模块，如果通过直接在排名旁勾选即可；有保存和发布按钮。

4.生日提醒功能：在某个部员生日将要来临的时候，系统自动推送消息给社团管理人员。

在人员注册时，新增“生日”选项(下拉选择)；在运行时，如果部员生日即将来临，系统自动推送生日提醒给指定的几名管理人员(能够通过设置更改)，方便管理人员作出决策。

5.收到信息之后，部员点击确认自动回复。

在“查看信息”模块，新增确认按钮和自定义回复框，默认回复“已收到”，也可以在自定义回复框中输入回复内容。