整體概況
- 1、整體框架與NABCD構架
- 2、面向部門
- 3、面向同學
- 4、MockPlus框架圖一覽 可實現版 [腦洞版]（由於沒管住自己的手，結果把項目升級成了團隊項目，沒有會員的我只能默默地看不能另存了，如果需要運行，我提供賬號密碼，在雲上運行一下吧。）
- 5、圖表項
- 6、心得體會，以及我和我的隊友 > _ > 031502106_陳涵 031502634_楊光海天
1、整體框架與NABCD構架
- 具體內容我們通過MockPlus（在搜索Balsamiq Mockups的額外產物，同時也有知乎和CSDN推薦， 一下子被MockPlus簡潔的界面吸引了）進行了原型設計，分為面向部門，面向同學，針對管理員部分，我們在現階段還沒有具體設計，但是有了一些打算。
1>Need篇
痛點的概述
1）部門的痛點
- 身處學校的廣播台，今年已經是第三年了，對於納新已經再熟悉不過了，眼下又是一輪新的納新周期，我也由此對我周圍的部長進行了一些調研，不難看出和我的想法是基本一致的，那就是我們不了解新生的作息，包括課程的安排和一些其他部門的安排，痛點很簡單也很一致，那就是我們不知道這個同學進入了幾個部門，他們部門是什么，最關鍵的就是不知道他們部門的工作量是多少。
關鍵痛點1：多部門已納，而面試者未知
- 部門的工作量其實最直觀的反應就是他們的部門名稱，如果知道了名稱，那么我們是很容易了解到他現在所需要的工作性質。 打個比方，比如一位同學，加入了校主持隊，加入了校社聯，加入了校記者團……如果一個學生的能力還不錯的話，他們如果已經加了上述三個部門或以上，我想我們是不會選擇納入這名學生的。因為他的工作量實在是太大了，同時，例會的沖突可能也在所難免，我把它歸結為一個痛點，同時這也就是本次最關鍵的痛點。
關鍵痛點2：專業因素沖突，影響部門工作
- 但是即便是他沒有上述的一些部門，但是如果他的專業是建築類的話，可能我們也要再三考慮，因為這個專業的課程可能不只是BT這么簡單了。他有沒有能力勝任這份工作，這是我們需要考慮的，但是如果我們不知道他的專業，這個問題可能直到他來面試，才會了解，這將會使他和我們無故的增加一些工作量。此為痛點二。
2）學生的痛點
級別不清，部門、社團、學生會，工作性質不明
- 周圍的一些同學，恰恰是一些班導，而自己的新生群中，也有很多的新生，因此我了解過他們的難處，那就是"這個部門，那個社團，或者這個社聯究竟是什么？"校級，院級？究竟有什么區別，我要做什么？"，總結了一下他們的痛點，那就是了解部門，社團，社聯的概念，並且分類依據需要不同的級別！但是題目所給的是部門的概況，因此我只是單單以部門模型為例，區分校級、院級的不同。以此作為問題的痛點。
2>Approach篇
依托數據庫的解決之道
-
首先想澄清一點，我們的想法很多，但考慮到后期實現的困難程度，因此我們對自己的高要求進行了"落地"操作，取消了一些我們看上去能夠實現，但是能力和時間所限無法實現的問題。並且對一些研究過於詳細，實現難度大的問題進行了模型的簡化。
-
其次，介紹一下部門的管理，此為重中之重，我們的功能也主要是面向部門。我們提供了部門成員的整體管理，新生的納入，請假情況的詳查，以及新生被占時間為例會的查詢，目的很簡單，解決痛點，提供給部門一個明明白白的新生框架。由此我們建立三張表來處理這個需求。在面向部門之處會詳細介紹。
-
之后，對於學生，我們想通過支持學生注冊的方式，對學生進行管理，學生不想參加的話，沒有必要透露個人信息。而學生的痛點，在於不了解部門，因此目前任何人都可以查詢部門的狀況。由於部門是公開的，所以也沒有必要對其進行細化，以后可以單獨給學生創立一個界面，完成學生自己的申請操作。
-
整體的實現框架
3>Benefit篇
一線需求者，同時也是一線的制作者
- 和一般軟件一樣，數據庫不需要什么硬件消費，同時做自己最了解的事情，當然自己也應該擅長這一方面的策划。解決問題的軟件，才是好軟件。深受問題影響的人，也是最可能解決問題的人。可能自己的能力有限，沒有好看的UI，可能距離移動到移動平台還有些時日，但是模型，關鍵需求的滿足是每一個軟件設計者必須的東西。可能，我們只是展現一下這方面的造詣。
4>Competitors篇
Sum = (選修軟工實踐人數) / 2;
- 開一個玩笑。由於沒有正式的類似軟件上線管理，因此我們都算是一個競爭者，而目前為止，我們的對手就是所有班需要做這道題的同學。我方優勢：原版的方式較為簡化，上手方便。 我方劣勢：沒有開發經歷，掌握的開發工具比較薄弱。沒有優質的算法實現。
5>Delivery篇
強大的自媒體社交與傳統的推廣
- 自己的納新環節必定可以作為一個參考，來審核一下自己到底哪些地方不好，哪些地方做的還可以。自己這個試驗場還可以推廣到自己的部長，甚至是以后作為部長的部員，下一步推廣到認識的朋友，在別的部門工作的人，甚至是以前的同學，不同學校，我想，這一定不是我們一個學校的問題，也是眾多學校共有的問題。
2、面向部門
- 講了那么多介紹，下面來一些干貨，首先是面向部門的規划和提供的功能。
3、面向學生
- 提供基礎查詢，簡化模型，無需登錄
4、MockPlus框架圖
- 首先安利一波MockPlus的學習教程，很好很強大 ->點擊這里
可實現版
- 登錄及注冊界面
- 部門登錄
- 部門和學生注冊
- 部門管理
- 學生查詢部門
腦洞版
- 整體構架
- 登錄界面
- 部門注冊界面
- 學生注冊界面
- 學生登錄個人管理界面
- 部門首頁功能介紹
- 部門模塊功能介紹
- 頁面流程圖
- 新腦洞版，在ios上運行，並且增加了一些額外，如學生和部門的互選功能，學生可以查詢到自己的面試得分和面試每輪的在線題目（如需要）。更加明晰要納入學生的具體狀態，以及對於時間沖突學生的判定。
- 該版本主體由楊光海天具體制作，我來負責前期一些規划和后期的一些修改。
5、圖表項
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 30 | 30 |
| · Estimate | · 估計這個任務需要多少時間 | 30 | 30 |
| Development | 開發 | 330 | 330 |
| · Analysis | · 需求分析 (包括學習新技術) | 120 | 100 |
| · Design Spec | · 生成設計文檔 | 60 | 120 |
| · Design Review | · 設計復審 (和同事審核設計文檔) | 30 | 30 |
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | 0 | 0 |
| · Design | · 具體設計 | 120 | 80 |
| · Coding | · 具體編碼 | 0 | 0 |
| · Code Review | · 代碼復審 | 0 | 0 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | 0 | 0 |
| Reporting | 報告 | 90 | 70 |
| · Test Report | · 測試報告 | 30 | 20 |
| · Size Measurement | · 計算工作量 | 30 | 20 |
| · Postmortem & Process Improvement Plan | · 事后總結, 並提出過程改進計划 | 30 | 30 |
| 合計 | 450 | 430 |
6、心得體會，以及我和我的隊友
1>心得體會及項目總結
陳涵
-
第一次不是一個人上路了，第一次想法可以有一個共享的平台，我喜歡這種感覺，第一次嘗試了一下組織，安排工作，我喜歡這樣一個輕松的氛圍，說實話，不知道自己的想法會不會被采納，的確有很多的想法和希望，但是由於各種各樣自身的原因，難以實現，這也反映了自己的能力還遠遠不夠，自己會的工具還是太少，當然，就像我第一次作業說的，我會按照自己的計划，按部就班地做下去，而不是希望那種競爭氣太重，或者抱着一個大腿，成為一個“優質“的附庸者，我覺得既然報了軟工實踐，就要給自己一點空間去真正的實踐，既然選擇了棟哥，就要把自己的極限往上升一個檔次。我希望的結對和團隊都是希望每一個人能夠親身經歷這個過程，每個人或多或少都可以參加一部分的工作，可以說不論是結對還是組隊，我們都不強，都沒有一個真正的靠山，但是我覺得這種危機意識，以及無法依靠大腿的意識，會敦促我們按時按質的完成自己的任務，同時，我更傾向一個和諧的團隊氛圍，我們可以有爭論，我們可以有不同想法，但是都不要過分地夾雜情緒的影響，而使自己過於強勢，我們可以問，可以想，也可以提，可以看。團隊是你的家，而不會漠視任何一個人的存在。我理想的Team就是以上這樣子。
-
同時附上理想（qiang po zheng）的自己：對於自己感興趣的事，要么不做，要么做，做就做好。
楊光海天
- 剛聽到本門課程的作業需要結對完成的時候，不免有些茫然失措。平時並不十分努力的我，該如何結對呢？更何況不能和組隊的人員沖突。
- 在這危難關頭，他向我拋出了橄欖枝，說實話有種受寵若驚的感覺。同樣是來自北京的同學，能力上的差距已然顯而易見。我想，自己的步伐既然已經慢了很多，有一位優秀的同學願意帶帶我，必然是我受益匪淺，所以欣然接受了他的邀請。
- 畢竟開學第一周，需要忙碌的事着實不少，終於在9月16日周六晚上，在活動室針對本次作業進行了研究討論。雖然是研究討論，不過大佬就是大佬，已經准備了很多內容，並且分享了他對於本次作業的大致想法，而我只不過在此基礎上，提供了一些建議。當我第一次看到作業內容的時候，不知道具體應該運用什么知識來解決，而隊友提出了運用數據庫的方式來達到實踐目的。的確是比較合適的解決方案，同時也比較簡潔，相對應該會比較容易實現。
- 第一次作業，僅僅是個開始，我相信以后我一定可以在隊友的引導下，不斷提升。
2>我和我的隊友
-
講什么呢…………講得太多怕坑了他，講的太少怕他不滿意，圖太正面感覺毀三觀……
-
所以就送一張圖吧（正在MockPlus上作討論）
9.22 更新腦洞設計界面