结对作业一

1、我和队友

李嘉群 061500513

刘双玉 031502424

2、项目定位

针对单个学院的部门/学生互选系统。只完成宣传到最终录取的过程，不包括后续管理。（至于原因，总觉得如果志愿填报跟福大教务处在一起会很怪异，说白了也是懒。）

3、需求分析

<1>N(Need,需求)

• 新生痛点
  • 信息获取方式被动，途径单一，效率低下。部门宣讲纳新时间有限，如果新生错过摆摊扫楼，很可能拿不到申请表。而且被扫楼会很厌烦，后期会有抵触心理。只要依托网上平台展现部门信息就可以给予新生全面信息。
  • 信息误差，盲目心态。就算知道部门基本情况也不能保证选择好部门。可能部门介绍与新生想象还有实际情况都不是一回事。可能新生自己都不知道自己适合什么部门。觉得可以弄个在线咨询，后面一想，在线很麻烦，不如留一个微信群或者qq群，水群去吧。但这只是加深了解，不能完全解决问题。有些东西还是要亲身体会。
• 部门痛点
  • 前期：宣传麻烦，统计麻烦，通知麻烦。扫楼腿跑断，宣讲口讲干，收表格看龙飞凤舞，记电话要揣摩圣意。通知面试要一个个输电话。可以采取线上报名，线上通知。
  • 面试：协调麻烦，筛选麻烦。部门面试时间可能与其他部门面试，新生个人时间冲突，活动室可能不够用，协调起来谁也不好将就谁。可以报告上级，交由主席团统筹，写个算法，把活动室，新生空余时间排一排。最后部门给出可选择时间，由新生自由选择一个时间。筛选人员的时候可能要在几十份甚至上百份报名表找一个人，解决方法是编号，根据网上报名时间，排定序号，跟打印出来的申请表采取同样序号。
• 针对题目需求
  • 时间冲突，面试时间冲突可以由主席团统筹，例会时间，个人时间冲突系统不会强制筛选，但是会显示提供参考。
  • 部门数目限制，请假次数记录。在部门面试结束，通过面试学生有反选部门权利，会限制在5个以内，但是请假属于后续管理，不记录。

<2>A(Approach,做法)

由于不考虑实现（貌似下次作业也不是实现）那就在这个板块说一些我们在思考实现过程中有争议的地方吧。ps:希望没有跑偏。

• 到底是做web还是app，产品定位是只负责纳新，那就是一次就扔，web更符合，但是新生没有电脑，使用手机大概app更合适。
• 报名是借用第三方网站，比如问卷星还是在当前网站报名。如果采用当前网站报名，考虑数据库存储，每个部门申请表格式可能就不是很个性化。如果用问卷星，跟系统匹配就不是很好。比如填写了问卷星，却没有点击系统的报名按钮。
• 在需求分析这里，发现了一个好玩的地方，本来是打算就有争议的地方弄一个调查问卷，比如新生最想了解部门的哪些情况，就在部门页面展示相应情况，但是后面发现会产生用户需求不一致情况，比如：部门不希望告知同学未被录取原因，但是新生却想知道。

<3>B(Benefit,好处)

• 对学生：信息更全面，世界更清静。
• 对部门：处理纳新更方便。

<4>C(Competitors,竞争)

• 优势：细节考虑更到位。
• 劣势：只有纳新，功能略显单薄。如果实现，页面很不友好。

<5>D(Delivery,推广)

官方途径更有效，像教务处给教务通打广告，易班为抽屉打广告，如果系统具体实现没有问题，可以考虑直接找辅导员。

4、原型系统设计

1.使用的原型工具：墨刀
2.首页登录界面

3.部门界面

4.学生界面

5.额外说明，部门页面修改用于填写介绍信息，面试时间等。学生查看部门信息，点击会进入部门主页，在纳新那里申请加入（这里没有画图），另外，别说页面丑，因为你如果了解过去的页面，你会原谅现在的页面。给张图你们感受一下

5、PSP表格

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

6、结对过程和照片

看一下我们。。。。。。。。。。的电脑。

7、心得体会

李嘉群

• 以前作业啊，任务啊，基本都是一个人完成，很少有这种结对作业或者团队作业。这也算是一个机会，考验一下两个人的默契和与人的相处。跟队友相处挺好的，我们俩都算挺主动的，一起讨论了几次。说实在的，两个人做确实比一个人做要做的更好，一开始讨论分工，各种安排，界面设计的之类的，也讨论了很久，到底要怎么做，怎么做才能满足题目中的需求，同时又有自己的创意在其中。两个人在一起会考虑的更多，更全面，往往自己漏掉的东西队友想到了，这就是细节吧，细节方面的还是要好好做，毕竟细节决定成败。
• 两个人一起做事会比较有节奏，有方向。怎么说呢，在设计界面的时候，看起来总是感觉这样做不好看，那样做也不好看，于是找队友商讨了一下，两个人一起讨论界面怎么排好看等，各自说出自己的想法，通过讨论，确定了界面的设计情况。分工方面也是，队友做一部分，然后我做一部分，这样效率也挺高的。不知道自己做的如何，但是不管怎么样，会尽力去做。
• 这是软工第一次结对作业，通过这次作业，促进了与小伙伴的交流，小伙伴的编码能力比我强，想法也比较奇特，自己应多向她学习，同时也期待下一次的合作。
• 这作业可以说是继数据库大作业的又一次软件设计，它比数据库作业要考虑的更多，考虑的更全面，比数据库作业多了很多的流程，正是由于这些流程，让我们了解了该如何去设计好一个软件，做这个软件如何满足用户的需求，而不是盲目的去做这个软件。从需求分析，界面设计中学到了很多，原型设计的软件也是第一次接触。我感觉设计软件，分析需求，更多的教会我的是如何去思考，如何去考虑的更全面，更完美，这是比做出一个软件更重要的。希望在以后的学习中，自己能不断的去思考，不断的进步。

刘双玉

• 做作业的感受：越分析越绝望，这个系统真的有用吗？因为开始有考虑具体实现。线上通知到手机办不到，只能自己查看录取状态，线上填表，是考虑插入数据库。还不一定能够打印。那对于新生，就只有部门信息展示功能，对于部门，只有线上填表的便捷。我也有跟舍友还有高中同学讨论，她们最终不约而同地说出来：”这个系统好麻烦啊，要它何用。“但是我死守着自己的倔强（线上填表，少了人工汇总的麻烦），总觉得它有点用。但是最后被舍友一句“线上填表用问卷星啊” 打败了。好在后绪作业不需要实现，那就可以emmmm。
• 结对的感受：有队友在，不好意思颓废啊。第一次讨论的时候，我们决定采用问卷调查确定可能存在争议的需求，之后确定初步分工，两头开工了。我是负责问卷调查与部门的原型设计。我本来雄心壮志，想着夜晚搞定问卷，第二天分析需求，夜晚画出原型，博客再一写就好了。问卷设计后我觉得问题太少就开始问舍友问同学，结果心态谈崩了。第二天身体不适，完全不想写作业，但是队友那边都在条不紊的进行。我消极怠工了两天，队友连博客都写的差不多了，实在是不好意思，以至于我大半夜写心得。我是想七想八，却不行动，从队友身上学到的就是效率，执行力！
• 结对的不足：沟通太少，感觉结对侧重于分工，交流太少了，原型设计，自己画自己的部分，完工了再来交流。看图片就知道了，大小什么都没有约定。大概我们都害羞吧，哈哈哈哈