結隊項目——第一次做業

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。在與隊友的合做中，咱們互相交流各自的想法，把用戶需求和原型不斷完善，合做完成的原型設計功能還算完備，挺有成就感的。真的以爲原型設計的工做蠻有意思的！！！我喜歡！！！