CMMI3 PA之技術解決方案(TS) 過程域解釋和實施指南

項目工期緊，常常成為很多事情的理由。因為趕時間，拿到需求后，不考慮哪種設計方案更合適，想到什么辦法就用什么辦法來做，甚至是沒有設計可言，直接編碼，寫設計文檔變成了浪費時間的一個事情。不少人進行設計的時候，眼光都放得不夠開，不知道公司提供了很多可重用的代碼，直接自己編碼實現數據操作、日志處理、權限認證等事情，結果浪費了時間，而且還不能保證自己的代碼是沒有問題的。很多公司的代碼都是經過嚴格測試的，設計架構良好的，可直接使用或者稍加修改則可以為自己所用。

概要設計和詳細設計的設計準則和規范要考慮增加復用和可擴展性；要提高效率和質量，考慮復用以提高生產率。

不知道您的工作中，在設計方面是否有這樣的一些問題：
1)無設計文檔
2)有設計文檔，但形同虛設
3)設計時沒有考慮可以重用以前項目或者第三方的代碼或組件
4)沒有用需求來驅動設計
5)設計沒有考慮多過一個的方案
6)沒有考慮清楚設計的原則和標準
7)設計的彈性不夠、架構落后？
8)代碼與設計脫節？
9)到處都是面條式代碼
......

典型的大型項目的結構化設計過程所需的設計階段：

1. 定義需求（需求定義）

2. 定義解決方案（系統規范）

3. 概念化的解決方案（系統概要設計）

4. 劃分任務（產品說明）

5. 定義產品設計（產品概要設計）

6. 將產品劃分為組件（組件規范）

7. 定義組件設計（組件概要設計）

8. 將組件劃分為模塊（模塊規范）

9. 細化解決方案（模塊細化設計）

10. 實施解決方案（模塊實施和測試）

技術解決方案這個PA，主要講述的是設計開發、實現方面的問題。在CMM中，對設計、開發、實現面的要求是比較簡單的。

技術解決方案(Technical Solution, TS) 的目的，為設計、開發及實現需求的解決方案。解決方案、設計結果及實現成品包括產品、產品組件，以及與產品相關生命周期的單一過程或適當組合的過程。

提示：產品架構、系統、子系統、性能、組件的解決方案，容易出現沒有記錄和文檔問題；

對于瀑布模型開發來說，系統或產品分解后，架構不能經常變；對于迭代模型開發來說，前一兩個迭代，系統或產品的架構要確定；至于設計，對新的產品或系統，考慮如何設計，對于舊的產品，考慮如何優化設計；

概要設計和詳細設計的設計準則和標準要描述和規范（基于提高復用性，可擴展性；提高效率，質量，考慮復用提高生產率。）設計準則和標準選擇理由加以記錄；選擇的評估會議可以是非正式如周例會；

設計過程：分解到組件后，是自己做還是采購，考慮增加復用和可擴展性；提高效率和質量，考慮復用提高生產率。

特定目標及實踐摘要

SG 1 選擇產品和產品組件解決方案

SP 1.1 開發備選解決方案及評選準則

SP 1.2 選擇產品組件解決方案

SG 2 開發設計：設計產品和產品組件

SP 2.1 設計產品或產品組件

SP 2.2 建立技術相關數據

SP 2.3 使用準則設計接口

SP 2.4 執行自制、購買或再用之分析

SG 3 實現產品設計

SP 3.1 實現設計

SP 3.2 建立產品支持文件

SG1: 選擇產品和產品組件解決方案：從候選方案中選擇產品或者產品組件的解決方案。

這個目標的主要內容就是制定選擇的標準（一般涉及成本、進度、效益、風險、技術性能等），設計候選方案，針對產品規格，依據選擇標準從候選方案中選出合適的產品或產品組件解決方案。解決方案(有時稱為“設計方案”、“設計概念”或“初步設計”)；初步設計或設計方案可能與產品需求和產品組件需求開發同步進行并互動（在開發或獲取客戶需求之后）。

提示：產品架構、系統、子系統、性能、組件的解決方案，容易出現沒有記錄和文檔問題；

SP1.1開發備選解決方案及評選準則：開發詳細的候選方案及選擇的標準。

典型的工作產品

1.備選解決方案篩選準則

2. 新技術的評估報告

3. 備選解決方案

4. 最終選擇的評選準則

5. 對市場現有成品的評估報告

子實踐

1. 界定篩選準則，以作為選擇備選解決方案的考慮因素

2.界定現有技術與具競爭優勢的新產品技術

3.界定能滿足需求的備選現成品:供方

4. 產生備選方案

5. 取得每一備選解決方案的完整需求配置。

6. 開發選擇最佳備選解決方案的準則

SP 1.2選擇產品組件解決方案：

選擇最符合要求的產品組件解決方案（設計方案）。針對每個產品組件描述操作概念、場景、環境、操作模式和操作狀態等選擇產品組件解決方案（設計方案）。

典型的工作產品

1. 產品組件選擇決策及理由

2. 需求及產品組件間相關性的記錄

3. 解決方案、評估及選擇理由的記錄

子實踐

1. 依據操作概念、操作方式及操作狀態所建立的評選準則，評估各備選解決方案/解決方案組。針對每一個備選解決方案，開發產品操作及使用者互動的時序場景。

2. 依據備選解決方案的評估，評?評選準則之適用性，必要時，更新準則。

3. 界定并解決與備選技術方案及需求有關的問題。

4. 選擇能滿足已建立之評選準則的最佳解決方案。

5. 建立與所選擇之備選方案關聯的需求，此即為該產品組件的配置需求。

6. 界定將再用（重用）或取得的產品組件解決方案。

7. 建立并維護解決方案、評估及選擇理由的文件。維護選擇理由對后續決策十分重要，可以使后續干系人免于返工，也可在某些適用的應用環境下，提供對技術應用的深入見解。

SG1講述的是如何找出最合適的設計方案，我們很多開發人員，做編碼之前都不太喜歡認真思考設計方案，迫于時間壓力，不仔細考慮設計方案是否合適，就直接開展工作，這樣做的風險是非常大的。

SP1.1講述的是先考慮好我們設計方案的選擇標準，并找出可能的候選方案。SP1.2要求我們對產品的規格進行詳細的表述，因為我們的方案是要滿足這些規格的，也只有這樣，我們才能更好地找出合適的解決方案。根據選擇標準選出最佳方案。

有人可能有這樣的疑問，有些項目很簡單，或者設計方案很明確，沒有必要搞什么候選方案和選擇標準，直接設計就可以了。設計方案除了針對整個項目的大的設計方案，還包括組成產品的各個組件的設計方案，絕大部分情況下，一個項目肯定會有部分地方技術不太明確需要仔細分析的。另外，不管怎樣，都應該根據項目的實際情況，定出這個項目的設計標準，就算只有一個方案，也需要用該設計標準來檢驗該方案。大部分情況下，認為不需要考慮多個設計方案、不考慮設計標準，都是“懶惰”思想作怪，不做這樣的考慮，項目的風險是比較大的。

SG2: 開發設計

開發產品或者產品組件設計。最佳候選方案確定后，就可以開展具體的設計工作了。設計不僅是為了實現，也是為了產品生命周期階段如修正、重新采購、維護、及安裝等。設計文件提供給相關的干系人，以方便對設計的相互了解提供參考，并在產品的開發與后續的生命周期階段設計上的改變。完整的設計描述，記錄與技術數據包內。

SP2.1 設計產品或產品組件：開發產品或者產品組件的設計。產品設計一般包含兩個階段，在執行上可能相互重疊：概要設計與詳細設計。

概要設計建立產品功能和框架，包含產品組成區塊、產品組件界定、系統狀態與模式、主要的內外部接口和界面設計。常見的概要設計說明書問題有（功能模塊設計、數據庫設計包括邏輯設計和物理設計及安全性能設計、模塊接口和界面設計）：軟件性能描述不具體；性能的解決方案沒有記錄和文檔；數據庫設計包括邏輯設計和物理設計及安全性能設計不具體等；

詳細設計：完整定義產品組件的結構和功能。詳細設計說明書是為編碼人員所寫，要詳細描述實現方法、算法；如是面向結構或數據流方法，、數據結構和處理流程（輸入、轉換、輸出數據流）；如是面向對象方法，設計類的函數和成員變量，并明確對象之間的相互關系。常見問題是詳細設計說明書過于簡單，和概要設計一樣，接口（內部和外部）設計不具體；

典型的工作產品

1. 產品架構

2. 產品組件設計

子實踐

1. 建立并維護準則，以評估設計。

2. 界定、開發或取得適合于產品的設計方法。選擇適合的方法并在一定的工具支持下對設計提供很大的幫助，一般常用的技術和方法：原型法、面向結構化設計方法、面向對象設計方法、E-R模型、設計復用、設計模式等；

3. 確保設計遵循所應用的設計標準與準則。

4. 確保設計遵循已配置的需求。

5. 記錄設計。

SP2.2建立和維護技術數據包。

建立和維護技術數據包。這個Practice的字面意思比較難理解，其實意思很簡單，就是要建立和維護一套管理所有設計文檔、數據的方法或者體制，對設計過程的數據、文檔進行有效的管理。技術數據包是給開發人員的做的（主要是需求、設計資料等），設計人員不想做，開發人員非常需要。完備的技術數據包為開發者提供了開發產品或組件的綜合性描述，還提供了有關產品類型的以下信息：產品架構描述、分配需求、產品組件的描述、產品相關生命周期過程描述、關鍵產品特性、必需的物理特征和約束、接口需求、用于確保實現需求的驗證準則等。

SP2.3 使用準則設計接口

根據所建立和維護的標準，設計接口。考慮外部接口和內部接口；與原來系統的關系；

典型的工作產品

1. 接口設計規格說明

2. 接口控制文件

3. 接口規格準則

4. 所選之接口設計的理由

子實踐

1. 定義接口準則。一般是組織過程資產的一部分

2. 界定與其它產品組件相關的接口。

3. 界定與外部相關的接口。

4. 界定介于產品組件與產品相關生命周期過程的介面。

5.  應用準則于接口設計的備選方案。

6. 記錄已選取的接口設計與理由。

SP2.4執行自制、購買或再用之分析：根據制定的標準評估哪些產品組件需要開發、購買或者重用。

技術狀況是對開發或采購產品組件作出選擇的重要理由；在開發工作很復雜時，可能以采購現有組件為佳，而擁有先進工具及充足人員情況下則支持自己開發。畢竟有時購買現有的組件，可能不夠完備或不能完全滿足系統的需要。一旦作出采購現有組件（或外包開發）的決定，就要在供應商協議中進行落實。

典型的工作產品

1. 設計與產品組件再用的準則

2. 自制或采購分析

3. 選擇現有成品組件的指引

子實踐

1. 開發產品組件設計再用的準則。

2. 分析設計以決定產品組件要自行開發、再用或采購。

3. 當采購或選擇非開發的(現成品、政府的成品及再用)時，分析維護所隱藏的代價。

SG3:實現產品設計：實施產品設計并開發相應的支持文檔。

SP3.1 實現設計：實施產品組件的設計，簡單地說就是依據設計進行編碼活動了。

典型的工作產品

1. 已實現的設計

子實踐

1. 使用有效的方法實現產品組件。比如結構化編程、面向對象編程、自動代碼生成、軟件代碼復用、應用合適的設計模式等。

2. 遵循適當的標準與準則。比如編碼規范、過程及質量標準、編碼時遵循模塊化、明確、簡單、可靠、安全、可維護等準則；編碼規范描述內容（如編碼模塊的復雜度和內聚性等）

3.對選定的產品組件，執行同行審查。可以通過代碼走查、測試等多種方式來實現；單元測試是驗證是否實現設計；單元測試要提到接口測試；

4. 適當時對產品組件執行單元測試。 這里單元測試不局限于軟件，涵蓋個別硬件、軟件單元或先前已整合的相關組合；

5. 必要時修訂產品組件。在實現階段發生了未能與設計階段預見的問題，就是修訂產品組件時機的范例之一。

SP3.2建立產品支持文檔：開發和維護用于產品安裝、操作及維護的相關文檔，如用戶手冊、安裝手冊、管理員手冊、在線幫助等。

典型的工作產品

1. 終端使用者培訓教材

2. 使用者手冊

3. 操作手冊

4. 維護手冊

5. 在線求助

子實踐

1. 審查需求、設計、產品及測試結果，以確保影響安裝、操作及維護等項文件的相關議題已被界定并解決。

2. 使用有效的方法，制作安裝、操作及維護的文件。

3. 遵循適當的文件制作標準。如《技術文檔編制規范》

4. 在生命周期的初期階段就制作安裝、操作及維護等文件的初始版本，以供相關的干系人審查。

5. 執行安裝、操作及維護等文件的同行審查。

6. 必要時修訂安裝、操作及維護文件。一般為需求、產品、設計、產品實現變更時 。