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:推廣

• 首先在校園內部分實驗室做試點，盡量選擇已成立多年，在校生和畢業生人數都不少的實驗室。在某些獎勵機制下，通過試點人群向外發散，因為大組可能包括了許多同時也在其他實驗室的成員。
• 同時盡量選擇多個領域的實驗室進行試點，因為用戶發散的能力在跨領域中效果極為有限。

設計原型展示

動態與消息頁面

人脈·機遇頁面

問題區

“我的”頁面

流程圖

老師

學生（包括在校生和畢業生）