結隊項目——第一次作業

本次作業 deadline： 2017-9-22 10:00pm

1.閱讀

閱讀《建構之法》第4章和第8章的内容，并在下方作業裡展現出閱讀後的成果。特别是第8章中的NABCD模型。

閱讀下方的客戶描述的現實困擾，請你們能将整套流程資訊化，以共同釋出一份部落格随筆的形式，設計一套方案，向客戶推銷。描述大緻方案，以向客戶證明你正确了解了客戶的需求（即進行需求分析）、提供給客戶可行的優化的步驟建議，給出原型模型。要求：

文字準确、樣式清晰、圖文并茂。字數在1000字左右。
原型模型必須采用專用的原型模型設計工具實作：如Axure Rp、Balsamiq Mockup、Prototype Composer、GUI Design Studio、Adobe、墨刀設計元件等等。在博文中說明你所采用的原型開發工具。
再次推薦部落格排版采用部落格園的markdown排版，範老師提供了說明：http://www.cnblogs.com/math/p/se-tools-001.html 。（納入作業評分細項要求中）
結對成員不能是同一團隊成員。

最終客戶将以評論的方式給出接納與否或修改完善的建議。如果客戶接納，該方案将作為你們結對項目的第三次作業。如果客戶不接納，下周你們的結對就将無法繼續編碼本次的内容，将完成老師命題的作業。

選擇部門的現狀：

各個部門在開學初占據學校青春廣場有利位置，通過張貼海報、發傳單等形式向學生宣傳；對某個部門感興趣的同學，填寫加入部門申請表交給各部門負責人。各部門負責人通過一種說不清道不明的算法對申請的學生進行人工篩選，人工篩選留下的學生也面臨被淘汰問題。篩選和淘汰的規則如下：

現狀困擾的是：流程繁瑣複雜，各個部門手工發放申請表，手工收集彙總，各個部門之間資訊溝通不暢，導緻不少學生加入幾個部門後，由于活動時間沖突而被淘汰，浪費時間和精力。學生在加入部門前對部門的情況了解有限；部門在學生申請之前對學生也不了解，稀裡糊塗，不可言說，就接收了，導緻後續配合存在隐患和困擾。

現在，現在，現在，我們很想做這樣一個系統，請你和你的“對友” 設計一個原型系統，讓部門選擇的過程能夠資訊化起來，讓學生和部門之間可以雙向選擇。

将博文釋出到個人部落格上，且需包含以下6個内容。

1）随筆開頭，給出結隊兩個同學的學号。（1‘）PS：結對成員不能是同一團隊成員。

2）對客戶需求進行需求分析，可采用NABCD模型。（5‘）

3）為客戶需求設計一個原型系統，讓部門選擇的過程能夠資訊化起來，讓學生和部門之間可以雙向選擇。要求樣式清晰、圖文并茂，并說明你所采用的原型開發工具。（5‘）

4）記錄本次作業的PSP表格，包括預估耗時及實際耗時。（1‘）

5）描述結對的過程，提供非擺拍的兩人在讨論、細化和使用專用原型模型工具時的結對照片。（1‘）

6）第一次和結隊的TA合作肯定感慨萬千，分享本次結隊的心得和本次項目的總結。PS：需注明是哪位同學的心得體會。（2‘）

本次作業評分由2部分組成，共20分，分别是

（1）部落格 — 15分，分數組成在博文規範中。

（2）客戶評分 — 5分，由客戶針對你的解決方案進行評分。

（3）注意事項：

按時間完成并送出——正常評分
晚交一周以内——0分
晚交一周以上或不交——倒扣本次作業分數
抄襲——倒扣2倍本次作業分數【嚴禁代碼與部落格等一切形式的抄襲！部落格園支援了對部落格的查重功能，我們也有專用的代碼查重系統進行代碼查重。請各位同學千萬不要觸碰底線，勿謂言之不預也！】

附：PSP 2.1表格

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