結隊項目——第一次做業

結隊項目——第一次做業

1. 結對成員：

031502614 賴志平
031502627 王國華

2. NABCD

N (Need, 需求)

首先，提出的需求以下：

要解決的困擾：流程繁瑣複雜，各個部門手工發放申請表，手工收集彙總，各個部門之間信息溝通不順暢，致使很多學生加入幾個部門後，因爲活動時間衝突而被淘汰，浪費時間和精力。學生在加入部門前對部門的狀況瞭解有限；部門在學生申請以前對學生也不瞭解，稀裏糊塗，不可言說，就接收了，致使後續配合存在隱患和困擾。
學生的篩選和淘汰規則：

• 部門納新人數和麪試時間必須事先申報肯定；
• 部門活動時間包括常規活動時間（如每週三19點-20點）和臨時活動時間，常規活動時間在納新時候就要公佈；
• 若是一個學生常規部門活動時間請假超過6次，將面臨被淘汰；
• 學生最多加入5個部門，可是要考慮部門活動時間衝突次數；
• 未參加部門面試的學生不能歸入部門。

要解決的問題是：讓部門選擇的過程可以信息化起來，讓學生和部門之間能夠雙向選擇。

這個系統應當分紅學生端和部門端來作。
首先是學生端，根據提出的需求，學生可能會碰到的問題有：部門活動時間衝突、加入部門時不瞭解部門、因爲活動時間衝突請假次數過多被淘汰。首先，在學生報部門的時候應當集中寫出部門的介紹，而且將部門的常規活動時間統一以相似課程表的形式直觀地列出來，方便學生在申請部門的時候比對參考。在學生加入部門以後，能夠直觀地看到活動時間表，若是有重複的活動能夠選擇請假，在同一個部門請假第 6 次的時候系統會提示再次請假會被淘汰。
部門端則須要申請納新、管理學生，包括學生的評分和淘汰、還有活動的申請。
部門和學生之間要雙向選擇，部門之間要有一些信息的交流。

A (Approach, 作法)

首先，學生端主要的就是對部門的瞭解以及申請部門的時候考慮到時間的因素。咱們就須要把部門的信息按照統一的標準來收集並展現給學生。
部門段最主要的就是在活動上的協調。咱們在部門申請活動時能夠看到其餘部門已經安排好的時間，而且能夠看到各個活動中本身部門的成員的參與人數，能夠參考參與人數來安排活動，保證最多的學生能夠參加活動。這一部分真正實現的話應該會使用數據庫來提供數據，不過這都是後話了。

B (Benefit, 好處)

這樣的設計首先保證了學生能夠根據部門活動的時間、本身的興趣來選擇參加的部門。這樣基本上能夠避免學生部門活動衝突的現象。只有學生在提交申請以後纔有機會進入部門。在學生請假的時候加以提醒來防止學生請假次數過多而被淘汰。
對於部門，系統能夠方便的管理學生，在設定活動時間的時候也能夠查看其餘部門的時間，保證最多的學生能夠參加，保障了部門之間的信息交流。
這些設計首先知足了提出的需求，而且功能分類較爲清除，方便以後添加功能，便於維護。

C (Competitions, 競爭)

咱們的系統的優點之處在於部門與部門、部門與學生之間打破了信息隔絕，能夠直觀地進行信息交流，避免了以前的稀裏糊塗的狀況。而且咱們的系統仿照教務處的邏輯，能夠直接放入易班學工處或者教務處的系統，更加利於使用。

D (Delivery, 推廣)

至於推廣，因爲咱們的系統是仿照教務處系統的模式，能夠直接加入易班。易班是每一個學生都有帳號的，不少學生工做、各種申請、學習、住宿等事宜均可以登錄易班系統來解決。部門屬於學生工做的範疇，放入易班十分方便，而且只須要不多的推廣就能夠廣泛使用。

3. 原型系統

在通過需求分析後，咱們得出了得出了這個系統的主要的功能，並據這些功能設計出了一個基本的原型系統，原型系統採用Asure8.0RP製做，主要包括了部門端和用戶端兩個版本，首先每一個部門都有一個管理本部門的帳號，部員也有一個本身帳號。部門帳號登進去爲部門端界面，部員登進去爲學生端，下面分別結合做出的原型進行說明：

學生端

首先登陸進去爲歡迎界面，點擊而且有三個按鈕：部門簡介，個人報名和部門活動。
點擊部門活動界面，會出現不少個框，每一個框裏有各部門的簡介。
若是是在納新期，則在個人報名界面能夠進行填下相應的報名信息，爲了防止因時間衝突而被淘汰的狀況，下面還有每一個部門的活動時間做爲填報的參考，若是填寫的五個志願有時間衝突的，會在有衝突的志願後面進行提醒，保證填寫的志願的有效性；若是是在非納新期，此界面將被鎖定。沒法填寫。

最後一個界面是部門活動界面。活動的相關內容用表格的形式進行顯示，同時標明是常規活動仍是臨時活動。
若是請假能夠點擊相應活動的請假按鈕，若是要是常規活動會給出在該部門請假的次數，並給出提醒，超過6次請假會提醒已被部門淘汰，而且再也不接受此部門的活動信息。

部門端

首先登陸進去爲歡迎界面，點擊而且有四個按鈕：部門管理，活動管理，成員活動和申訴狀況。

部門管理界面能夠看到部門的相關信息。

活動管理界面能夠進行活動的申請，還能夠看到其它部門的活動狀況以及本身部門的部員在這些部們中的人數，方便安排，減小時間上的衝突。

在成員管理界面能夠看到相應的部門成員面試，請假等的信息。能夠在這個頁面裏看到學生的具體狀況，看到學生請假次數和違紀次數，而且能夠操做，移除成員或者將移除的成員恢復。

若是還未進行納新，那還能夠點擊納新申請，提出納新的申請，包括時間地點，納新人數等。只有在規定的時間內纔會容許納新。

4. PSP表格

PSP2.1	Personal Software Process Stages	預估耗時（分鐘	實際耗時（分鐘
Planning	計劃	20	20
.Estimate ·	估計這個任務須要多少時間	20	20
Development	開發	1080	1080
.Analysis	需求分析 (包括學習新技術)	600	600
.Design Spec	生成設計文檔	20	20
.Design Review	設計複審 (和同事審覈設計文檔)	30	30
.Coding Standard	代碼規範 (爲目前的開發制定合適的規範)	30	30
.Design	具體設計	20	60
.Coding	具體編碼	100	120
.Code Review	代碼複審	80	80
.Test	測試（自我測試，修改代碼，提交修改）	80	80
Reporting	報告	80	60
.Test Report	測試報告	30	30
.Size Measurement	計算工做量	20	20
.Postmortem & Process Improvement Plan	過後總結, 並提出過程改進計劃	30	30
合計		1180	1240

5. 討論照片

姿式比較怪，可是這不是重點，重點是那認真的小眼神。

6. 心得體會

志平

軟工的做業真的是名不虛傳，不過大做業和小做業都是可以讓人熬夜，每次都有新的東西。此次的設計部門管理系統，從需求分析階段到實際的原型的出來，通過三四個晚上的夜戰，終於大部分實現。因爲咱們採用的是Asure RP，這款軟件的用法相對墨刀等來講上手難度我以爲是比較大的，花了大量時間在學習這款軟件上，同時咱們選擇的是網頁版的設計，這對於咱們的設計更是提出了很大的挑戰，如今初步原型出來，我以爲儘管還有些地方咱們仍是沒有真正地考慮到，但願客戶在看到了咱們的原型後可以給咱們提供提供進一步的改進意見，同時也是十分期待下一次的編碼實現階段，可以真正地把這些功能實現。

國華

這一次的結對首先學會了設計一個項目的始末，包括需求分析，具體功能，實現方式，產品的邏輯的分析。學會了 Axure 的使用，雖然還有瑕疵可是已經基本成型，也考慮了將來會有的一些功能。這是我第一次結隊做業，結隊做業就要和對方溝通交流好，互相檢查，互相學習。在開始的時候一塊兒分析交流產品的細節，在實現的時候作出來一點就要和對方分享，對方有好的地方能夠借鑑，有缺漏的地方也能夠提醒本身。這一次只是作出來一個原型，還不是真正的編程，十分期待將來結隊編程的做業，感觸與收穫應該會比如今更多。