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