本篇主要聊一下CMMI中的系統設計過程。
系統設計（System Design, SD）是指設計軟體系統的體系結構、使用者界面、資料庫、子產品等，進而在需求與代碼之間建立橋梁，指導開發人員去實作能滿足使用者需求的軟體産品。
系統設計過程域是SPP模型的重要組成部分。本規範闡述了系統設計過程域的四個主要規程：
² 體系結構設計 [SPP-PROC-SD-ARCHITECTURE]
² 使用者界面設計 [SPP-PROC-RM-UI]
² 資料庫設計 [SPP-PROC-RM-DATABASE]
² 子產品設計 [SPP-PROC-RM-MODULE]
上述每個規程的“目标”、“角色與職責”、“啟動準則”、“輸入”、“主要步驟”、“輸出”、“完成準則”和“度量”均已定義。
本規範适用于國内IT企業的軟體研發項目。建議使用者根據自身情況（如商業目标、研發實力等）适當地修改本規範，然後推廣使用。
11.1 介紹
系統設計過程域分為兩個階段：高層設計階段和詳細設計階段。
高層設計階段的重點是軟體系統的體系結構設計。詳細設計階段的重點是使用者界面設計、資料庫設計和子產品設計。
系統設計過程域産生的主要文檔有：
² 《體系結構設計報告》，模闆見
[SPP-TEMP-SD-ARCHITECTURE]。
² 《使用者界面設計報告》，模闆見
[SPP-TEMP-SD-UI]。
² 《資料庫設計報告》，模闆見
[SPP-TEMP-SD-DATABASE]。
² 《子產品設計報告》，模闆見
[SPP-TEMP-SD-MODULE]。
11.2 體系結構設計
11.2.1 目的
l 分析與設計軟體的體系結構。通過系統分解，确定子系統的功能和子系統之間的關系，以及子產品的功能和子產品之間的關系，産生《體系結構設計報告》。
11.2.2 角色與職責
l 項目經理指定若幹名開發人員從事體系結構設計（以下稱為體系結構設計人員）。
11.2.3 啟動準則
l 體系結構設計人員已經确定。
11.2.4 輸入
l 需求文檔如《産品需求規格說明書》
11.2.5 主要步驟
[Step1] 設計準備
l 項目經理或者技術負責人配置設定系統設計任務，包括體系結構設計、子產品設計、使用者界面設計、資料庫設計等。本活動可能産生一份階段性的開發計劃，如《系統設計計劃》，視工作量而定。
l 體系結構設計人員閱讀需求文檔，明确設計任務。
l 體系結構設計人員準備相關的設計工具（如Rational Rose）和資料。
[Step2] 确定影響系統設計的限制因素
l 需求限制。體系結構設計人員從需求文檔如《軟體需求規格說明書》中提取需求限制，例如：
² 本系統應當遵循的标準或規範
² 軟體、硬體環境（包括運作環境和開發環境）的限制
² 接口/協定的限制
² 使用者界面的限制
² 軟體品質的限制，如正确性、健壯性、可靠性、效率（性能）、易用性、清晰性、安全性、可擴充性、相容性、可移植性等等。
l 隐含限制。有一些假設或依賴并沒有在需求文檔中明确指出，但可能會對系統設計産生影響，設計人員應當盡可能地在此處說明。例如對使用者教育程度、計算機技能的一些假設或依賴，對支撐本系統的軟體硬體的假設或依賴等。
[Step3] 确定設計政策
l 體系結構設計人員根據産品的需求與發展戰略，确定設計政策（Design Strategy）。例如：
² 擴充政策。說明為了友善本系統在将來擴充功能，現在有什麼措施。
² 複用政策。說明本系統在目前以及将來的複用政策。
² 折衷政策。說明當兩個目标難以同時優化時如何折衷，例如“時－空”效率折衷，複雜性與實用性折衷。
[Step4] 系統分解與設計
l 體系結構設計人員：
² 将系統分解為若幹子系統，确定每個子系統的功能以及子系統之間的關系。
² 将子系統分解為若幹子產品，确定每個子產品的功能以及子產品之間的關系。
² 确定系統開發、測試、運作所需的軟硬體環境。
[Step5] 撰寫體系結構設計文檔
l 體系結構設計人員根據指定的模闆撰寫《體系結構設計報告》，主要内容包括：
² 軟體系統概述
² 影響設計的限制因素
² 設計政策
² 系統總體結構
² 子系統的結構與子產品功能
² 開發、測試、運作所需的軟硬體環境
[Step6] 體系結構設計評審
l 體系結構設計人員邀請同行專家、開發人員對體系結構進行正式技術評審，評審流程請參考 [SPP-PROC-TR-FTR]。
l 體系結構評審的重點不是“對還是錯”，而是“好還是差”。主要評審要素包括：
² 合适性。考察該體系結構是否适合于産品需求，是否可在預定計劃内實作。
² 系統的綜合能力（Capability）。例如“時－空”效率（性能，容量等），可擴充性，可管理性（可維護性），可複用性，安全性等等，視産品特征而定。
[後續活動]
l 體系結構設計完成後進入詳細設計階段（使用者界面設計、資料庫設計、子產品設計等）。
11.2.6 輸出
l 《體系結構設計報告》
11.2.7 結束準則
l 《體系結構設計報告》已經完成，并且通過了技術評審。
11.2.8 度量
l 體系結構設計人員統計工作量以及文檔的規模，彙報給項目經理。
11.3 使用者界面設計
11.3.1 目的
l 設計軟體的使用者界面，産生《使用者界面設計報告》。
l 制作使用者界面的資源如圖像、圖示或者界面專用元件等。
11.3.2 角色與職責
l 項目經理指定若幹名開發人員從事使用者界面設計（以下稱為界面設計人員）。
l 如果可能的話，邀請使用者或美勞工員協助設計使用者界面。
11.3.3 啟動準則
l 需求文檔已經完成。
l 體系結構設計已經完成。
11.3.4 輸入
l 需求文檔
l 體系結構設計文檔
11.3.5 主要步驟
[Step1] 設計準備
l 界面設計人員閱讀需求文檔和體系結構設計文檔，明确界面設計任務。
l 界面設計人員與使用者交流，了解使用者的工作習慣和他們對界面的看法。
l 界面設計人員準備相關的設計工具和資料，收集或創作基本的界面資源如圖像、圖示以及通用的元件。
l 界面設計人員确定本軟體的使用者界面設計規則（或指南），主要包括：
² 優秀界面的特征或通用的設計原則；
² 軟體主界面（如主視窗、首頁面）的設計規則；
² 軟體子界面（如子視窗、子頁面）的設計規則；
² 标準控件的使用規則；
² 美學設計規則。
[Step2] 使用者界面設計
使用者界面設計一般要經曆“
原型創作—>原型評估－>細化”等步驟，通常疊代進行。
l
[Step2.1] 原型創作界面設計人員創作界面原型：
² 先徒手畫，或者用Visio 等工具繪制界面的視圖；
² 再用軟體開發工具實作可以運作的原型。
l
[Step2.2] 原型評估² 界面設計人員邀請使用者和同行們評估界面的原型，彙集意見，及時改進。
l
[Step2.3] 細化² 界面設計人員細化界面原型，例如美工處理，添加細節等。
補充說明：開發人員在本階段不必關心界面原型的代碼品質，因為界面原型可能不斷地被修改甚至被抛棄。
[Step3] 撰寫使用者界面設計文檔
l 使用者界面定型之後，界面設計人員根據指定的模闆撰寫《使用者界面設計報告》，主要内容包括：
² 應當遵循的界面設計規範；
² 界面的關系圖和工作流程圖；
² 主界面的視圖、功能說明、操作方式；
² 子界面的視圖、功能說明、操作方式；
² 美學設計說明。
[Step4] 使用者界面設計評審
l 界面設計人員邀請使用者和同行們對定型後的界面進行正式技術評審，盡最大努力使界面變得更加美觀、易用。評審流程請參考 [SPP-PROC-TR-FTR]。
l 使用者界面的主要評審要素包括：
² 合适性
² 簡潔易用
² 一緻性
² 美觀
² 動态回報
² 功能屏蔽和出錯處理
² 使用者控制
² 國際化（相容性和可移植性）
² 适應性（針對各種使用者）
[後續活動]
l 在系統設計工作結束之後，開發人員編寫界面的代碼，并和使用者一起通過各種途徑測試界面，進而不斷地完善使用者界面。（請參考有關測試的文檔）
l 界面設計人員總結經驗教訓，不斷地完善适用于本機構的“使用者界面設計指南”。
11.3.6 輸出
l 《使用者界面設計報告》
11.3.7 結束準則
l 《使用者界面設計報告》已經完成，界面原型已經通過評審。
11.3.8 度量
l 界面設計人員統計工作量以及文檔的規模，彙報給項目經理。
11.4 資料庫設計
11.4.1 目的
l 設計軟體的資料庫，産生《資料庫設計報告》。
11.4.2 角色與職責
l 項目經理指定若幹名開發人員從事資料庫設計（以下稱為資料庫設計人員）。
11.4.3 啟動準則
l 需求文檔已經完成。
l 體系結構設計已經完成。
11.4.4 輸入
l 需求文檔
l 體系結構設計文檔
11.4.5 主要步
[Step1] 設計準備
l 資料庫設計人員閱讀需求文檔和體系結構設計文檔，明确資料庫設計任務。
l 資料庫設計人員準備相關的設計工具和資料。
l 資料庫設計人員确定本軟體的資料庫設計規則（或指南），主要包括：
² 資料庫命名規則
² 邏輯設計規則（或指南）
² 實體設計規則（或指南）
² 安全性設計規則（或指南）
² 優化規則（或指南）
² 資料庫管理與維護規則（或指南）
[Step2] 資料庫設計
資料庫設計一般要經曆“
邏輯設計—>實體設計－>安全性設計－>優化”等步驟，通常要疊代進行。
l
[Step2.1] 邏輯設計² 資料庫設計人員根據需求文檔，建立與資料庫相關的那部分實體關系圖（ERD）。如果采用面向對象方法（OOAD），這裡實體相當于類（class）。
l
[Step2.2] 實體設計² 設計表結構。一般地，實體對應于表，實體的屬性對應于表的列，實體之間的關系成為表的限制。邏輯設計中的實體大部分可以轉換成實體設計中的表，但是它們并不一定是一一對應的。資料庫表的參考格式如表11-1所示。
² 對表結構進行規範化處理（第三範式）。
表名
功能說明
列名
資料類型（精度範圍）
空/非空
限制條件
補充說明
表11-1 資料庫表的參考格式
l
[Step2.3] 安全性設計 提高軟體系統的安全性應當從“管理”和“設計”兩方面着手。這裡僅考慮資料庫的安全性設計。
² 使用者隻能用帳号登陸到應用軟體，通過應用軟體通路資料庫，而沒有其它途徑可以操作資料庫。
² 對使用者帳号的密碼進行加密處理，確定在任何地方都不會出現密碼的明文。
² 确定每個角色對資料庫表的操作權限，如建立、檢索、更新、删除等。每個角色擁有剛好能夠完成任務的權限，不多也不少。在應用時再為使用者配置設定角色，則每個使用者的權限等于他所兼角色的權限之和。
l
[Step2.4] 優化分析并優化資料庫的“時－空”效率，盡可能地“提高處理速度”并且“降低資料占用的空間”。
² 分析“時－空”效率的瓶頸，找出優化對象（目标），并确定優先級。
² 當優化對象（目标）之間存在對抗時，給出折衷方案。
² 給出優化的具體措施，例如優化資料庫環境參數，對表格進行反規範化處理等。
[Step3] 撰寫資料庫設計文檔
l 資料庫設計人員根據指定的模闆撰寫《資料庫設計報告》，主要内容包括：
² 資料庫環境說明
² 資料庫的命名規則
² 邏輯設計
² 實體設計
² 安全性設計
² 優化
² 資料庫管理與維護說明
[Step4] 資料庫設計評審
l 資料庫設計人員邀請同行們對資料庫進行正式技術評審，評審流程請參考 [SPP-PROC-TR-FTR]。
l 資料庫的主要評審要素包括：
² 正确性、完整性、一緻性
² 安全性
² “時－空”效率
[後續活動]
l 在系統設計工作結束之後，開發人員将編寫與資料庫相關的代碼，并和使用者一起通過各種途徑測試資料庫，進而不斷地完善資料庫。（請參考有關測試的文檔）
l 資料庫設計人員總結經驗教訓，不斷地完善适用于本機構的《資料庫設計指南》。
l 軟體傳遞給使用者後，由使用者管理與維護資料庫。
11.4.6 輸出
l 《資料庫設計報告》
11.4.7 結束準則
l 《資料庫設計報告》已經完成，并且通過了技術評審。
11.4.8 度量
l 資料庫設計人員統計工作量以及文檔的規模，彙報給項目經理。
11.5 子產品設計
11.5.1 目的
l 設計軟體所有子產品的主要接口與屬性、資料結構和算法，産生《子產品設計報告》。
11.5.2 角色與職責
l 項目經理指定若幹名開發人員從事子產品的設計（以下稱為子產品設計人員），子產品設計人員将在實作階段編寫這些子產品的代碼。
11.5.3 啟動準則
l 需求文檔已經完成。
l 體系結構設計已經完成。
11.5.4 輸入
l 需求文檔
l 體系結構設計文檔
11.5.5 主要步驟
[Step1] 設計準備
l 子產品設計人員閱讀需求文檔和體系結構設計文檔，明确子產品設計任務。
l 子產品設計人員準備相關的設計工具和資料。
l 子產品設計人員确定本軟體的程式設計規範，確定子產品設計文檔的風格與代碼的風格保持一緻。
[Step2] 子產品設計
子產品設計一般要經曆“接口與屬性設計—>資料結構與算法設計”等步驟，并且通常需要反複疊代。
建議：由于現代的軟體開發工具越來越先進，子產品的詳細設計和程式設計可以很好地融合一起，而且效率相當高，有些工具甚至具有代碼自動生成功能。是以在系統設計階段，子產品設計究竟要詳細到什麼地步，應當視問題複雜性以及所采用的開發工具而定。一般地，隻要确定了每個子產品的主要接口、資料結構與算法，能夠清楚地指導子產品程式設計即可。總之，不必花太多時間用于設計子產品的細節。l
[Step2.1] 接口與屬性設計² 子產品設計人員設計每個子產品的主要接口與屬性。如果采用面向對象方法（OOAD），相當于設計類的函數和成員變量。
l
[Step2.2] 資料結構與算法設計² 子產品設計人員設計每個子產品的資料結構與算法（如果存在的話）。
[Step3] 撰寫子產品設計文檔
l 子產品設計人員根據指定的模闆撰寫《子產品設計報告》，主要内容包括：
² 子產品彙總
² 每個子產品的主要接口與屬性
² 每個子產品的資料結構與算法（如果存在的話）
[Step4] 子產品設計評審
l 子產品設計人員邀請同行們對子產品設計文檔進行正式技術評審或者非正式技術評審（由技術負責人決定采用何種評審方式），評審流程請參考 [SPP-PROC-TR]。
l 子產品的主要評審要素包括：
² 資訊隐藏（獨立性）
² 強内聚、低耦合
² 資料結構與算法的效率
[後續活動]
l 子產品的代碼實作可以與子產品設計同步進行，也可以在子產品設計完成之後進行。
11.5.6 輸出
l 《子產品設計報告》
11.5.7 結束準則
l 《子產品設計報告》已經完成，并且通過了技術評審。
11.5.8 度量
l 子產品設計人員統計工作量以及文檔的規模，彙報給項目經理。
11.6 實施建議
l 先對系統設計人員進行“專題”教育訓練，讓他們掌握必要的系統設計技能。
l 由于國内絕大多數的大學不開設“使用者界面設計課程”，這導緻大部分軟體開發人員不善于設計使用者界面。項目開發小組應當設法邀請使用者界面設計專家參與（或指導）本軟體的界面設計。
l 系統設計人員可以根據産品的特征，适當地修改《體系結構設計報告》、《使用者界面設計報告》、《資料庫設計報告》和《子產品設計報告》的模闆。
l 對系統設計過程中産生的所有有價值的文檔進行配置管理。
![pcb設計實戰與應用智能手機_大咖問答07期：李崇偉傳授PCB設計實操技巧與常見問題解決方法...[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)