结队项目——第一次做业

031502412

031502414

1、问题背景

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

新生入学初，总会被学校、学院内各种形形色色的部门所吸引。可是，新生仅能从部门制做的宣传媒介以及自发组织的扫楼中了解到极少的关于部门的信息，若想要报名也须要自行填写纸质报名表并投递至该部门，报名流程与筛选流程繁冗。同时，新生因为新鲜感会同时报名面试多个部门，对本身所报部门职能是否重叠不够了解，部门对报名者自身的实际状况、所报选的部门数量也没法得知，没法让新生正确地在部门中获得锻炼，同时也会极大地增长部门将来的工做负担。这种现象在各大高校持续存在，新生的思惟误区与部门的纳新工做对新生群体以及部门的管理者存在极大困扰。

2、需求分析－－NABCD模型

N（Need,需求）

根据客户的诉求，我与队友通过讨论，以为作主要的客户需求就是部门管理信息化,以实现学生与部门间的双向互选。
如下为一些需求细节：

• 部门纳新阶段 ：纳新人数、纳新时间、纳新地点等都要提早申报肯定，并经过这个平台发布信息，同时须要将部门的常规活动发布出来，以便让新生了解部门基本纳新状况。新生可在平台上提交本身的简历，根据部门的公告信息，参与部门的人工筛选（面试）。

• 部门管理阶段 ：学生进入学生会部门后，经过这个平台安排本身平常的部门活动。部门在这个平台上，发布部门的常规活动及临时活动内容，管理部员参与活动的状况。部门管理员还可上传部门的活动内容和总结，方便往后交流和记念。

• 部门淘汰规则 ：这个平台须要实现学生和部门的双向互选，因此学生加入的全部部门对部门管理人员来讲是彻底透明的，若学生加入的部门超过5个，须要考虑活动时间的冲突次数。若学生在部门常规活动中请假超过6次，将面临淘汰。

  A（Approach,作法）

• 设计移动端：移动端管理操做等都比web端方便实用。

• 设计两个客户端：

  1. 学生端：学生经过学号注册，填写本身的我的基本信息。在平台中找到各个部门的纳新信息，根据本身的兴趣提交简历报名，在该平台获取部门发布的面试等信息。加入部门后，学生还可获取部门的活动信息，造成方便快捷的安排本身的部门活动。平台还提供聊天功能，方便小伙伴之间的交流。
  2. 部门管理人员端：部门管理人员可在平台中发布部门的基本信息和特点，并发布纳新信息，让新生可以全方面的了解部门，加强新生报名的热情。后期部门活动管理也经过这个平台，可根据这些活动参与的信息，对部员进行奖惩，透明而公平。还能够上传已经办过的活动的资料和照片。

B (Benefit,好处)

• 部门管理信息化：不管是学生仍是部门管理人员均可以方便快捷管理部门活动，就像课表同样～（不再用去好几个通知群看消息，忘了这个，丢了那个，不再会被部长骂了(´･_･`)）

• 各部门信息集中：学校各个部门的信息全都在一个平台上，信息全面，分类展现，学生能够看到尽览一切信息，不再怕错过那个心仪中的部门了（啊！我要是知道这个部门！我也去面试了！后悔orz...）

• 部门奖惩制度透明化：平台上记录着部门中各个部员的活动记录，奖惩制度也公开透明（哼！看大家这群小崽子还敢不敢随便翘班！再翘班，学长学姐就不翻你牌子了(￣^￣)ゞ）

• 信息收集方便：新生报名信息直接在线上提交、统计，避免了报名表丢失形成的不便（哇！我不再怕错过这群可爱的小萌新们了～_～）

• 部门资料集中管理：可上传部门的活动资料、照片等。（OMG!连部门网盘都省了！怎么会有这么好用的app！）

• 部门消息统一通知：部门管理员可经过这个平台统一发布部门消息通知。（耶！不用群发短信了！麻麻不再用担忧个人话费了（≧∇≦））

• 具有聊天功能：给小伙伴们提供增近感情的机会（来自学长学姐意味深长的笑容 嘿嘿嘿）

  
  

C (Competitors,竞争)

优点

除了做业要求中的五点需求，咱们还增添了其余的功能：

• 全部部门的信息整合，且分类显示。

• 学生能够在平台上直接提交报名表，部门管理员也能够直接发布纳新信息。

• 部门管理员能够在平台上管理部员的参与活动状况，进行奖惩，还可上传部门的资料、照片，部门管理方便实用。

• 提供了部门人员之间交互的功能。

劣势

• 功能复杂，实现难度略大。

• 有些功能与现有的部门qq群的功能重复，推广有些难度

• 你们脑洞这么大，确定还有比咱们更有趣的想法。

D (Delivery,推广)

能够联系学校较大的学生组织，如校会、社联、校青协等，将咱们制做出来的app二维码印在纳新宣传册中，扫码下载app，直接线上报名；经过运行微信公众号、制做H5宣传页等新媒体途径扩大宣传范围，迎合大学生群体的宣传需求，受众面大，接受的人数数多，推广力度较大，宣传效果也会很好～

3、原型设计

开发工具：墨刀

参考app：Teambition

原型介绍：

登陆界面：两种身份（学生、部门）登录方式,红色问号❓表示忘记密码操做。学生登录后填写本身的基本信息，部门填写部门基本介绍。

部门端首页：

部门管理：部门经过这个功能实现部员的管理，包括纳新面试是否经过、部员奖惩状况。

活动发布：部门在这里发布部门活动、纳新面试信息等。

扫码签到：部门端生成签到二维码，提供给参加活动的部员扫一扫签到，方便签到制度的管理

部门资料：部门活动资料和照片在这里快捷上传

学生端首页

部门介绍：学生能够在这里查看全面的分类整理的部门信息，直接对本身中意的部门提交报名表。

活动行程：直接呈现学生不一样时间段的不一样部门活动，简单明了。

个人部门：查看各部门的活动状况。

个人：这个界面包括查看任务、文件以及本身收藏的功能。

任务：学生能够在这个界面手动添加部门会议中安排的我的任务 部门可添加部门近期活动计划

文件：学生和部门均可以在这里看到参与的部门活动资料、照片等,看到本身喜欢的文件能够添加到收藏中。

收藏：保留部门活动美好的回忆~~

通知：

• 学生在这里能够看到部门新发布的活动提醒，以及部门一些通知事项，并可直接表示参加或请假。
• 部门在这里能够看到部员的活动请假等消息，且若部员触犯了淘汰规则这里也会出现系统提醒。

聊天：学生和部员之间均可以直接在这里聊天，交流感情。

看了这么多介绍也以为眼花撩乱了吧，不如动手一试比较直观呀～_～

(能够经过点击两个不一样的身份进入不一样身份界面哦～)
墨刀

4、PSP

PSP2.1	Personal Software Process Stages	预估耗时	实际耗时
Planning	计划	20	10
· Estimate	· 估计这个任务须要多少时间	20	10
Development	开发	440	320
· Analysis	· 需求分析 (包括学习新技术)	120	90
· Design Spec	· 生成设计文档	60	60
· Design Review	· 设计复审 (和同事审核设计文档)	20	20
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	---	---
· Design	· 具体设计	180	120
· Coding	· 具体编码	---	---
· Code Review	· 代码复审	---	---
· Test	· 测试（自我测试，修改代码，提交修改）	60	30
Reporting	报告	115	130
· Test Report	· 测试报告	90	120
· Size Measurement	· 计算工做量	5	5
· Postmortem & Process Improvement Plan	· 过后总结, 并提出过程改进计划	20	5
合计		575	460

5、结对过程

照片

（咱们都比较害羞，因此没有人入镜）

心得

李佳铭：第一次结队合做完成做业，两我的合做得仍是挺顺利的，一共开了3次会，而后交流也是挺多的，此次结队做业让我认识到结队中多交流会让合做的项目更好更顺利。需求分析部分是极其重要的部分，只有分析透彻了，才会知足客户要求，让客户满意。而对于原型系统，从刚开始彻底不了解它是什么，到后来咱们也利用墨刀作出了一个原型系统，虽然作得不专业，但刚开始学能够作成这样子仍是挺满意的，但愿下次结队做业也能够和此次同样顺利。


  黄若岚：通过这一次的做业，我收获蛮多的。学习到了NABCD模型需求分析报告的书写，也学会了用墨刀设计原型，我以为设计原型挺有意思的，至少不用敲代码hhh。在与队友的合做中，咱们互相交流各自的想法，把用户需求和原型不断完善，合做完成的原型设计功能还算完备，挺有成就感的。真的以为原型设计的工做蛮有意思的！！！我喜欢！！！