執行階段
圖 5-1 執行階段的任務和工件
分析產品的關鍵需求、對架構設計有影響的需求和風險較高的需求，直到分析的程度能開展足界面原型設計和架構設計工作。
《需求規格說明書》的內容包括：
商業或業務需求 |
從商業或業務角度宏觀上對產品或系統的要求。它主要在宏觀的層面歸納總結為滿足客戶提出的要求或贏得市場競爭所必須實現的功能、性能、質量等要求。
- 做什么
- 做的范圍
- 對結果的要求
|
使用者需求 |
從客戶對軟件產品或系統使用方案的角度出發，描述和總結使用者利用該軟件產品或系統能夠做的事或能夠完成的任務。 |
功能需求 |
根據上述使用者需求列出的使用方案，列出開發者必須為軟件產品或系統實現的功能。 |
性能需求 |
- 運行速度、容量、并發性能
- 對資源的利用率
- 對外界輸入的反饋速度和準確性
- 對差錯的負荷能力
|
系統需求 |
（包括運行平臺、網絡及其他硬件要求）
（包括與操作系統、數據庫、瀏覽器及其他應用軟件的兼容要求）
|
質量需求 |
（可靠性、效率性、靈活性、安全性、互操作性、穩定性、健全性、可用性）
（可維護性、多用轉換性、重復使用性、可測試性） |
其他需求 |
不屬于上述需求范圍的，但受到其他環境和商業合同影響的要求。
- 國家或地區的任何特別的標準
- 軟件使用界面的特別要求
- 與知識產權有關的要求
- 軟件所面對的市場和行業的規范
- 客戶的特別要求
|
開發的局限 |
對開發的成功與否起很大影響的因素，是開發能力的局限：
- 人員的局限
- 技術的制約和局限
- 客戶的特別要求
|
表 5-1 需求分析告
《需求分析報告》的編制方式可以是多樣的，例如把所有“非功能性需求”組織成“外部接口需求”、“質量屬性需求”和“需求約束”。【如：圖5-2】
圖 5-2 需求規格說明書
明確了系統的關鍵需求后，就可以進行界面原型設計工作，獲取用戶的反饋，盡快確定產品的界面基調。同時要編寫一份《界面設計概要》文檔，作為后續的界面設計工作的指導。
《界面設計概要》的內容包括：
- 設計的理念
- 理念的來源或參考
- 設計的要點
- 與類似產品界面的對比
架構設計從關鍵需求開始，建立概念性的架構，并逐步細化和驗證。最終生成架構設計說明書和架構基線代碼。
架構設計的方法：可以從幾個不同的視角進行架構設計，然后匯總綜合得出完整的設計。（架構設計的五個視圖【如：圖5-3】）
圖 5-3 架構設計的五視圖
《架構設計說明書》的內容包括：
概 述 |
說明編寫的目的、適用范圍以及設計原則等。 |
邏輯架構 |
關注功能。其設計著重考慮功能需求。
- 細化功能單元
- 發現通用機制
- 細化領域模型
- 確定子系統接口和交互機制
|
開發架構 |
關注程序包。其設計著重考慮開發期質量屬性，如可擴展性、可重用性、可移植性、易理解性和易測試性等。
- 確定要開發或直接利用的程序包之間的依賴關系
- 確定采用的技術、框架等
|
數據架構 |
關注持久化數據的存儲方案。其設計著重考慮“數據需求”。
- 持久化數據存儲方案
- 數據傳遞、數據復制、數據同步等策略
|
運行架構 |
關注進程、線程、對象等運行時概念，以及相關的并發、同步、通信等問題。其設計著重考慮運行期質量屬性，例如性能、可伸縮性、持續可用性和安全性等。
- 確定引入哪些進程與線程
- 確定主動對象、被動對象，以及控制關系
- 處理進程線程的創建、銷毀、通信機制、資源爭用等
- 協議設計
|
物理架構 |
關注軟件系統最終如何安裝或部署到物理機器。其設計著重考慮“安裝和部署需求”。
- 確定物理配置方案
- 確定如何將目標程序映射到物理節點
|
總 結 |
基于上述的設計進行總結，并描述架構基線。 |
表 5-2 架構設計說明書
架構設計的另一個重要任務是編寫架構基線代碼，基線代碼表述和驗證架構，同時也是指導后續開發的基礎代碼。架構基線代碼的內容包括：
- 所有工程項目
- 工程目錄結構
- 軟件包結構
- 導入所有依賴包
- 基礎公共代碼
- 架構框架代碼
- 架構框架示例代碼和測試代碼
- 數據庫框架
圖 5-4 和圖 5-5 展示了軟件架構師的工作和成功的軟件架構設計包含的內容：
圖 5-4 軟件架構師的工作
圖 5-5 成功的軟件架構設計
1 軟件構建
軟件可以分階段進行構建，每個階段可以使用增量的方式開發，用通過若干個Build構建，最后發布階段性產品成果。
（注意：在這里 ，名詞“階段”的含義和本文其他地方的含義不一樣）
構建階段計劃的內容包括：
- 確定本階段要實現的功能
- 列出階段任務
- 計劃Build構建數量
- 細化《開發進度表》中本階段的工作內容
詳見：下一節
構建階段完成后發布階段產品成果，向用戶展示并接受用戶反饋，同時做好階段總結。
《發布清單》的內容包括：
- 產品版本號和日期
- 改正的Bug
- 修改的功能
- 實現的新功能
- 其他說明
《階段總結報告》的內容包括：
- 階段任務的完成情況
- 進度計劃的執行情況
- 用戶的反饋情況
- 本階段碰到的主要問題
- 下一階段的改進建議
2 Build 構建
Build構建以增量的方式執行階段的開發任務，每個Build構建的周期一般不超過兩星期，每一次Build構建都會發布為一個內部版本，并提交測試。測試發現的問題留待以后的Build構建解決。
《Build計劃》的內容包括：
- 本次Build的版本號
- 本次Build的歷時
- 本次Build的工作任務
- 要解決的遺留Bug
- 本應由以前的Build實現的，但推遲到本次Build實現的功能
- 要實現的新功能
- 其他工作任務
- 工作任務分配
根據《Build計劃》，細化本次Build要實現的需求，細化到能進行詳細設計為止。有了細化的需求后就編寫本次Build的測試計劃。
《測試計劃》的內容包括：
- 其他測試（性能測試、邊界測試、使用界面測試、可用性測試、安全性測試等）
- 。。。。。。
根據細化的需求設計用戶界面，當界面確定后即可編寫測試用例。
《測試用例》的內容包括：
- 測試用例對應的功能模塊
- 測試用例的性質（功能測試用例、性能測試用例、。。。。。。）
- 輸入（或操作步驟）
- 期望輸出
- 實際輸出（執行測試后再填寫）
- 是否通過（執行測試后再填寫）
詳細實際每項需求的實現方法，對于重要的設計決策、算法、公共模塊和外部接口等必須以模塊設計文檔的形式進行記錄。《模塊設計文檔》的內容包括：
- 模塊名稱
- 設計思想
- 設計圖表（類圖、流程圖等）
- 要點描述（包、接口、類、方法、算法、設計模式）
- 測試方式
編碼和單元測試是開發人員的工作，對于重要的代碼都必須進行單元測試，編寫代碼必須遵守下列準則：
- 遵守編碼規范
- 編碼前必須充分理解相關的需求
- 編碼前先進行設計，把流程理順
- 注意設計方法和設計模式的靈活運用
- 總體考慮問題，使代碼遵從架構并容易測試
- 設計時要充分考慮異常情況和臨界條件
- 嚴禁Copy-Paste，注意提取公共代碼，在編碼過程中實現重構
- 異常處理必須記錄日志，嚴禁草率地直接打印異常信息
- 靈活運用ASSERT() / VERIFY()等斷言來幫助調試程序
- 單元測試是程序員的工作，所以編碼完成后必須對代碼嚴格測試
- 功能代碼完成后必須先做以下4件事情：
- 編譯代碼，保證編譯通過
- （不運行程序）對代碼進行全面檢查
- 用調試模式啟動程序，一行一行單步執行代碼，并注意調試輸出
- 改變條件，讓代碼盡可能走遍所有程序分支
- Check In代碼前必須保證能編譯通過
代碼集成發布前需凍結代碼，所有人把要提交的代碼Check In，并保證編譯后的程序能在測試服務器上正常啟動，界面能正常打開。同時還要提交Build清單。
《Build清單》的內容包括：
- Build版本號和日期
- 改正的Bug
- 修改的功能
- 實現的新功能
- 其他說明
按照《測試計劃》針對《Build清單》執行《測試用例》，測試完成后編寫測試報告。
《測試報告》的內容包括：
- 測試用例匯總（用例數量、通過的用例數量、未通過的用例數量等）
- Bug匯總（Bug總數、新增Bug數量、關閉Bug數量、Bug趨勢圖表等）
- 測試計劃執行情況
- 測試總結
該文章在 2012/4/9 10:50:44 編輯過
400 186 1886
