031502614 賴志平
031502627 王國華
n (need, 需求)
首先，提出的需求如下：
要解決的困擾：流程繁瑣複雜，各個部門手工發放申請表，手工收集彙總，各個部門之間資訊溝通不暢，導致不少學生加入幾個部門後，由於活動時間衝突而被淘汰，浪費時間和精力。學生在加入部門前對部門的情況了解有限；部門在學生申請之前對學生也不了解，稀里糊塗，不可言說，就接收了，導致後續配合存在隱患和困擾。學生的篩選和淘汰規則：
要解決的問題是：讓部門選擇的過程能夠資訊化起來，讓學生和部門之間可以雙向選擇。這個系統應當分成學生端和部門端來做。
首先是學生端，根據提出的需求，學生可能會碰到的問題有：部門活動時間衝突、加入部門時不了解部門、由於活動時間衝突請假次數過多被淘汰。首先，在學生報部門的時候應當集中寫出部門的介紹，並且將部門的常規活動時間統一以類似課程表的形式直觀地列出來，方便學生在申請部門的時候比對參考。在學生加入部門之後，可以直觀地看到活動時間表，如果有重複的活動可以選擇請假，在同乙個部門請假第 6 次的時候系統會提示再次請假會被淘汰。
部門端則需要申請納新、管理學生，包括學生的評分和淘汰、還有活動的申請。
部門和學生之間要雙向選擇，部門之間要有一些資訊的交流。
首先，學生端主要的就是對部門的了解以及申請部門的時候考慮到時間的因素。我們就需要把部門的資訊按照統一的標準來收集並展示給學生。
部門段最主要的就是在活動上的協調。我們在部門申請活動時可以看到其他部門已經安排好的時間，並且可以看到各個活動中自己部門的成員的參與人數，可以參考參與人數來安排活動，保證最多的學生可以參加活動。這一部分真正實現的話應該會使用資料庫來提供資料，不過這都是後話了。
b (benefit, 好處)
這樣的設計首先保證了學生可以根據部門活動的時間、自己的興趣來選擇參加的部門。這樣基本上可以避免學生部門活動衝突的現象。只有學生在提交申請之後才有機會進入部門。在學生請假的時候加以提醒來防止學生請假次數過多而被淘汰。
對於部門，系統可以方便的管理學生，在設定活動時間的時候也可以檢視其他部門的時間，保證最多的學生可以參加，保障了部門之間的資訊交流。
這些設計首先滿足了提出的需求，並且功能分類較為清除，方便之後新增功能，便於維護。
c (competitions, 競爭)
我們的系統的優勢之處在於部門與部門、部門與學生之間打破了資訊隔絕，可以直觀地進行資訊交流，避免了之前的稀里糊塗的情況。並且我們的系統仿照教務處的邏輯，可以直接放入易班學工處或者教務處的系統，更加利於使用。
d (delivery, 推廣)
至於推廣，由於我們的系統是仿照教務處系統的模式，可以直接加入易班。易班是每個學生都有賬號的，很多學生工作、各類申請、學習、住宿等事宜都可以登陸易班系統來解決。部門屬於學生工作的範疇，放入易班十分方便，並且只需要很少的推廣就可以普遍使用。
在經過需求分析後，我們得出了得出了這個系統的主要的功能，並據這些功能設計出了乙個基本的原型系統，原型系統採用asure8.0rp製作，主要包括了部門端和使用者端兩個版本，首先每個部門都有乙個管理本部門的賬號，部員也有乙個自己賬號。部門賬號登進去為部門端介面，部員登進去為學生端，下面分別結合作出的原型進行說明：學生端
部門端首先登入進去為歡迎介面，點選並且有三個按鈕：部門管理，活動管理和成員活動。
部門管理介面可以看到部門的相關資訊。
活動管理介面可以進行活動的申請，還可以看到其它部門的活動情況以及自己部門的部員在這些部們中的人數，方便安排，減少時間上的衝突。
在成員管理介面可以看到相應的部門成員面試，請假等的資訊。
如果還未進行納新，那還可以點選納新申請，提出納新的申請，包括時間地點，納新人數等。
姿勢比較怪，但是這不是重點，重點是那認真的小眼神。
志平
軟工的作業真的是名不虛傳，不過大作業和小作業都是能夠讓人熬夜，每次都有新的東西。這次的設計部門管理系統，從需求分析階段到實際的原型的出來，經過三四個晚上的夜戰，終於大部分實現。由於我們採用的是asure rp，這款軟體的用法相對墨刀等來說上手難度我覺得是比較大的，花了大量時間在學習這款軟體上，同時我們選擇的是網頁版的設計，這對於我們的設計更是提出了很大的挑戰，現在初步原型出來，我覺得儘管還有些地方我們還是沒有真正地考慮到，希望客戶在看到了我們的原型後能夠給我們提供提供進一步的改進意見，同時也是十分期待下一次的編碼實現階段，能夠真正地把這些功能實現。這一次的結對首先學會了設計乙個專案的始末，包括需求分析，具體功能，實現方式，產品的邏輯的分析。學會了 axure 的使用，雖然還有瑕疵但是已經基本成型，也考慮了未來會有的一些功能。這是我第一次結隊作業，結隊作業就要和對方溝通交流好，互相檢查，互相學習。在開始的時候一起分析交流產品的細節，在實現的時候做出來一點就要和對方分享，對方有好的地方可以借鑑，有缺漏的地方也可以提醒自己。這一次只是做出來乙個原型，還不是真正的程式設計，十分期待未來結隊程式設計的作業，感觸與收穫應該會比現在更多。軟體工程實踐2017結對專案 第一次作業
031502537 葉己峰 031502518 練斐弘 這次的結對作業，我們嚴格遵守了棟哥上課講過的規則，即先定需求，規劃，建模，越遲開始產品實現越優，因此，我們的準備工作做的較充分。採用了nabcd模型，首先分析了顧客需求，從部門和新生兩個角度來考慮 其次是實現方法，採用web端實現，用mockp...
軟體工程實踐2017第一次作業
第一次寫部落格，寫得不好，請老師多多見諒。閱讀與思考 1 回想一下你初入大學時對計算機專業的暢想 當初你是如何做出選擇計算機專業的決定的？這兩年學到了不少的知識，但與我對計算機專業的期待有些落差。以前以為計算機只要程式設計，沒想到數學和硬體也很重要 但都學了我還是不會實際運用，而且我感覺到在學校學習...
軟體工程實踐2017第一次作業
在看過這些博主的文章之前，也看過了不少的類似的的勵志小故事，不同的是以前看的幾乎都是那種泛泛而談，諸如教你在大學要努力啊，要各方面都去嘗試啊，而沒有針對性，沒有針對於我們這個專業的一些比較好的建議。以前的自己也是覺得自己好像在某些方面已經達到了所謂完美大學的要求，開始有所懈怠。看完這些博主的文章覺得...