2020软工第三次作业（结对编程第一次作业）

这个作业属于哪个课程	软件工程2020秋
这个作业要求在哪里	第三次作业（结对编程第一次作业）
这个作业的目标	锻炼协作能力，提出初步解决方案
学号	031804103、051806129

PSP表格

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

背景

学长学姐去哪儿——了解实验室或社团历史上的那些学长学姐们的去向和现状
了解实验室学长们去向的现状：
除了实验室群里长期潜水或偶尔冒泡的学长、导师口中的零星去向、临近的学长，似乎就无法了解了。好久以前的没见过的学长们，去了哪里。这不仅仅是?是否?选择这个实验室的依据之一，还是今后找工作的内推的重要支柱。可惜现状就不是很明确和了解，知晓的渠道也很有限。
学长们其实也很想了解学弟们现在在做什么研究，有没有什么擅长的技能，比如会某个研究方向或数学建模技能的，也很希望能帮忙协助内推，比如这位学长，就只能给我发消息，也无法有效传递。
另外，建一个实验室群，也不是很方便，因为在群里，你也不好意思经常问：学长们，你们在哪啊。
甚至，等你工作了，和你同一个公司或一个组的同事，可能就是实验室同门，你们都相见不相识，多遗憾。

题目

请你和对友设计一套信息化的解决方案，兼顾实用性、有效性、安全性、隐私性、封闭性。
可以是一个软件、APP或小程序，不仅仅包含主要界面和功能的原型，还需要描述不同角色用户，如何注册、添加、删除、认证加入等，从使用频率、使用便利度、使用有效性等角度出发，考虑如何维护该系统，如何确保安全性、隐私性、时效性和相对封闭性等，可以是软件化的方式实现上述特点，也可以依赖流程制度实现上述特性。但无论哪一种，都需要你们通过原型图、流程图、文字化方案来描述。清晰呈现一套也许你们也需要、客户也需要的完美的解决方案。

GitHub

讨论剪影

解决方案

主要参照《构建之法》第八章中所介绍的NABCD模型提出我们的解决方案。

N:需求

站在用户的角度思考与分析问题。本问题主要面向三类用户：老师、在校生、毕业生

• 老师

长期以来扮演着在校生和毕业生之间互相认识的媒介，但是科研任务繁忙，也无法完全记住每个同学的技能树和具体的研究进度，导致有些时候在校生和毕业生之间的交流难以成行。

• 在校生

在校生处在求学科研找工作的多重压力下，急需同门学长学姐分享科研经验经验或者帮助内推。然而在校生缺乏了解同门前辈的渠道，不知道前辈们曾经的研究方向是什么、在何处工作、是否能提供帮助。不管是一个一个加好友私聊还是直接在群聊中广播提问都不合适。

• 毕业生

毕业生拥有丰富的科研经验，同时也已经在产业界或学术界有了一番耕耘，有些时候遇到难题也希望求助与实验室同门师弟师妹们。然而毕业生离开实验室后难以了解实验室的新人，不知道新人们有何需求、新人们有何技能、新人们的研究方向和进度。更多时候只能通过老师了解哪些师弟师妹拥有自己所需要的技能。

A:做法

我们的做法是，让导师成为一个组织者，而不是在校生和毕业生之间认识的媒介，建立一个让所有实验室同门们互相了解的平台。

• 在这个平台上大家可以互相了解，除了有个人简介和个人技能树之外，还可以找到每个人在各大社交平台（例如微博、知乎、GitHub等）的ID以互相了解，还可以利用平台提供的用户微信号加好友深入交流。
• 平台力求做到相对封闭和安全，只有老师可以新建组织，实验室内部所有人员都可以邀请新人，但是必须经过导师的认证同意，实验室内部信息只有成员可见。
• 平台允许一个用户处在多个组织中，且在每个组织中的身份可以不同，例如对于一个博士在读生，在本科阶段和硕士阶段所在实验室中的身份是毕业生，而在博士阶段所在实验室的身份则是在校生。用户发布的问题可以设置为部分所在组织成员可见或所有所在组织成员可见。
• 平台力求实现时效性。每个用户可在自己的主页添加个人tag，可以是自己擅长的领域、擅长的技能、当前的研究方向和曾经的研究方向。在发布问题时发布者可以选择添加问题tag，平台将通过公众号推送给具有和问题tag相同或相关个人tag的问题可见成员，提醒有与自己相关的问题发布，而不是向所有实验室成员广播推送消息（这样的话和直接在QQ群、微信群提问没有区别）。

B:好处

在校生和毕业生的互相了解可以直接通过平台完成，导师除了前期组织以外无需花费太多的组织成本。成员间可以通过基本资料、技能树、各大社交平台互相了解，还可以通过发布问题的方式具体寻找某些技能拥有者或能提供帮助的用户。
平台能够保证相对封闭和安全，进入组织需要导师的认证同意，而组织内部的内容对外部用户不可见，个人资料也只有同一组织的用户才可以访问和查看。

C:竞争

优势：

• 作为功能型小程序，本方案的封闭性和安全性完全足够，因为只有通过自己微信的小程序才能登录自己的账号，且经过导师认证通过后的实验室内部用户较为可信，个人页面可以发布一些较为详细的个人信息，而不必担心隐私被实验室外部人群窃取。
• 特殊的推送功能。通过每个用户添加个人tag，每个提问者在问题中添加问题tag，能够针对问题推送给潜在的目标用户，规避了一部分无效推送造成的垃圾信息。

劣势：

• 组织建立前期因为个人页面不完整、成员数量少，使用体验可能较差，推广任务较为艰巨。
• 个人tag的设置与问题tag之间可能有差距，需要设计一个推送算法，尽量减小错误推送和遗漏推送。

D:推广

• 首先在校园内部分实验室做试点，尽量选择已成立多年，在校生和毕业生人数都不少的实验室。在某些奖励机制下，通过试点人群向外发散，因为大组可能包括了许多同时也在其他实验室的成员。
• 同时尽量选择多个领域的实验室进行试点，因为用户发散的能力在跨领域中效果极为有限。

设计原型展示

动态与消息页面

人脉·机遇页面

问题区

“我的”页面

流程图

老师

学生（包括在校生和毕业生）