電子公文傳輸系統團隊專案

目錄團隊作業（二）：需求分析

其他團隊作業（三）：確定分工

團隊作業（四）：描述設計

團隊作業（五）：衝刺總結

參考鄒欣老師的部落格《現代軟體工程講義 4 團隊和流程》和《現代軟體工程講義 5 團隊合作的階段》，在接下來的時間裡，我們將嘗試以團隊為單位完成一些任務。

使用團隊賬號，每隊發表一篇隨筆，內容包括：

《需求規格說明書》要求：

參考《軟體需求規格說明書》國標規範文字，撰寫對應專案的軟體需求規格說明書。

除形式上滿足規範文字要求外，整體內容必須圍繞專案實質展開，對所要開發的專案確保盡力做到清晰完整準確。

採用分層形式描述，隨著「層」的深入，描述的內容細節越具體。

使用一致的圖形符號和文字描述內容。

所有的縮寫須事先定義。

**並茂，通篇文件有乙個統一的樣式風格（對於該md檔案，要求團隊內每個人都需進行相應的commit，作為團隊開發的第一次嘗試）。

將自己置於讀者的立場——如果對軟體專案不熟悉的人員，通過閱讀這份文件，能否完全讀懂軟體要做什麼。

訪問軟體專案的真實使用者，確保軟體真正體現使用者的需求，為軟體最終可用奠定基礎。

需求規格說明書裡描述的細分功能、邊界範圍等，限定於本學期期末驗收時能達到的功能，最終答辯驗收將對照需求規格說明書進行。亮點以及未來預期完成的功能，可在需求規格說明書裡獨立專章描述。

團隊協作，加強分工，需要描述每個成員的具體分工及佔整個文件任務的工作量比例。

checklist:

討論制定團隊的編碼規範，討論之前和討論之後，隊員閱讀《構建之法》第四章內容，並討論總結。將**規範和編碼原則發布在隨筆上，並說說你們這麼選擇的理由。（5'）

通過powerdesigner完成團隊專案的資料庫設計，並在隨筆中提供相應er圖。(10')

進行專案的後端架構設計，要與需求規格說明書中的介面原型設計相對應。（15'）

確定團隊分工。請參考"分而治之(wbs - work breakdown structure)"，提供下述內容：（15'）

描述組員在上述任務中的分工和工作量比例。

以上內容發表成一篇隨筆，alpha 版本的發布時間安排在5月下旬，請各個團隊注意時間結點，盡快開始開發。

附錄同學們已經做了需求的分析，也做了詳細的系統設計，畫過了一些小小的類圖/用例圖，對自己要做什麼應該有比較清晰的認識了。接下來，我們要怎麼做便成了問題。有同學會說，我大概已經知道怎麼做了，在腦海裡比劃著，很多東西都有大致的想法，45度仰頭思考片刻，有了一張巨集偉的藍圖，感覺差不多可以施工了。

**出問題了呢？很顯然是溝通問題，乙個人的想法和理解，即使自己覺得很完整，很美好，但是能讓別人理解一致嗎？不見得，同一件事情，如果不溝通清楚，兩個人的理解可能是千差萬別的，所以需要有充分的溝通，盡可能減少歧義的溝通。

至於uml的基礎知識，課上我們講過了。這裡個人理解：把uml作為一種溝通工具來使用。溝通什麼呢？溝通設計思想。

要做什麼？

團隊分工（5分）

描述團隊的每個成員分別完成了uml圖的哪些部分，可以選擇多種方式呈現，推薦泳道圖。

uml（需求規格說明書裡已經練習過了整個系統的uml設計，這裡不需要對整個系統建模，只需要每個團隊成員找到自己負責部分的核心或最複雜模組做uml練習）（20分）

注：對於每個圖，需描述對應的是系統哪部分、這部分面臨什麼樣的問題、這樣的設計解決了哪些問題？

因為乙個團隊為完成乙個專案，為了資訊完整，須將每個人的成果匯集到一篇部落格中，由組長提交到作業中。

衝刺（7次 scrum）

除上述部落格內容外，每次 scrum 衝刺部落格都需要提供當天站立式會議**一張，發布專案燃盡圖，並描述專案整體的進展情況。

做中教，做中學，實踐中共同進步！

如果你覺得本文對你有幫助，請點一下左下角的「好文要頂」和「收藏該文」