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