【文章內容簡介】 FS+UI Bug Fixed Regress IRL 集成 需求分析 編碼設計 簡單測試 定版發(fā)行 原始軟件開發(fā) 軟件開發(fā)的階段劃分 （續(xù)） 軟件開發(fā)的階段劃分及目標 國外流行軟件開發(fā)模式 軟件工程理論指導下的軟件開發(fā)管理模式也存在一定的問題 ， 那就是有些環(huán)節(jié)的可操作性較差 。 主要表現(xiàn)在需求分析到總體設計這個環(huán)節(jié) 。 需求分析是文檔性的描述 ， 一般是軟件開發(fā)人員對用戶需求的一種理解 ， 這種文字描述一般很難精確可視地展現(xiàn)未來軟件的情況 ， 而用戶也很難說清楚自己的需求 ， 這就使得用戶很難鑒別需求分析的精確性 。往往導致軟件交付后的大量修改 。 有一篇 “ Client / Server軟件開發(fā)常犯錯誤 ” 的文章說得好 ， “ 用戶不知自己需要什么樣的系統(tǒng) ， 但知道不要什么樣的系統(tǒng) ” 。 軟件工程理論 為避免軟件開發(fā)中需求分析到總體設計這個環(huán)節(jié)的歧異性問題 。 目前 ， 國際流行的軟件開發(fā)模式中增加了 FS+UI（ 功能規(guī)范和用戶界面 ） 這個環(huán)節(jié) ， 這個環(huán)節(jié)不但解決了用戶在需求分析理解上的困難 ， 同時也解決了軟件開發(fā)過程各種角色人員的并行工作問題 ， 便于軟件開發(fā)工期的縮短 ， 有利軟件開發(fā)質量與成本的控制 [ FS+UI（ 功能規(guī)范和用戶界面 ） 見后面章節(jié) ]。 原始的軟件開發(fā)模式很是簡單 ， 有些項目連需求分析都不完整 ， 軟件測試只是相當于模塊集成一級的測試 ， 沒有規(guī)范的軟件測試 。 軟件質量取決于編程者個人的技術水平 ， 質量無法保證 ， 也很難控制 。 在滿足用戶需求方面取決于編程者個人的理解 ， 軟件交付后經常發(fā)生大面積的修改 。 項目似乎完成得很快 ， 交付后大面積的修改經常導致延誤工期 ， 修改后的軟件缺乏必要的測試手段 ，往往導致極大的售后服務支持成本 。 造成項目表面贏利 、 實際虧損的局面 。 原始軟件開發(fā) 軟件開發(fā)的階段目標 軟件開發(fā)的階段劃分及目標 ? 可行性研究 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 產品策略 資源分析 投資回報分析 市場推廣策略 產品銷售策略 產品服務策略 其它 項目定義 技術分析 市場分析 ?包括產品的技術策略與產品線的市場定位等方面的內容 ； ?已有資源包括資金資源 、 人力資源 、 技術資源等的分析 ， 及所需資源分析等 ； ?項目投資總額 、 項目成本核算 、 項目收益 、 投資回報等 ； ?可能的市場推廣模式與手段 ； ?可能的銷售手段與價格策略 ； ?產品應提供的標準服務與增殖服務 ； ?項目或產品立項其它應考慮的因素； ?主要是對項目或產品有一個切確的描述 ， 鉤畫出該產品的主要功能 ， 并對產品運行環(huán)境 、 用戶特征以及制約因數(shù)進行全面的描述 ； ?主要對項目或產品采用的主要技術加以必要的分析 ， 包括項目的開發(fā)環(huán)境與運行環(huán)境所涉及的各方面技術 。 在此應對這些技術的發(fā)展狀況 ， 成熟情況及未來的技術走勢應有細致的闡述 。 同時 ， 對采用該種技術存在的風險加以分析說明 ； ?包括國內外行業(yè)發(fā)展現(xiàn)狀 、 市場格局 、 發(fā)展趨勢 ， 在市場容量統(tǒng)計數(shù)據(jù)的基礎上 ， 推測我們產品可能的市場占有率及銷售情況 ； 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? 需求分析 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 需求分析是軟件項目正式實施開始的第一個階段，需求分析應該遵循可行性分析確定的基調，包括技術路線、產品基本功能、產品運行環(huán)境及市場定位。 需求分析主要應完成對用戶應用流程的描述，即完成商業(yè)邏輯分析。并根據(jù)商業(yè)邏輯的需要確定軟件的功能列表及描述。 ? 目的： ? 在客戶和軟件項目需求之間建立共同理解； ? 需求管理包括 : ? 文檔化和控制顧客需求 ? 保持計劃、產品、活動和需求的一致性 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? 需求分析 ? 要求： ? 軟件需求必須文檔化，軟件需求是受控的； ? 軟件需求可簡可煩，簡單的備忘錄，煩雜的多卷規(guī)格說明 ? 需求更改文檔化，全部需求更改必須可跟蹤和驗證。 ? 軟件計劃與軟件需求保持一致 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? FS+UI 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 FS+UI（ FS： 功能描述； UI： 用戶界面 ） A. 總體描述 ， 包括應用平臺及應用限制 ， … B. 功能列表 C. 用戶界面 FS+UI的合格與否取決于能否完成以下二方面的工作 。 ① 完成用戶手冊的編寫 ！ ② 準備測試計劃 、 測試用例及確定驗收標準 ！ FS+UI是產品管理部門與軟件開發(fā)部門的接口 。 對于項目型開發(fā)是軟件開發(fā)商與用戶責任劃分的重要依據(jù) 。 FS+UI不同于需求分析 ， 它提供給用戶的是一個清晰可見的用戶界面與完整的功能說明 ， 方便用戶的理解與確認 。 軟件開發(fā)據(jù)此進行下一步工作就有了堅實的基礎 ， 避免軟件交付后的大量修改工作 ， 有利于軟件質量與進度的控制 。 同時 ， 便于軟件開發(fā)并行工作的展開 。 FS+UI是軟件總體設計及軟件 α測試的基礎。 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? 初步設計 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 總體設計的依據(jù)是 FS+UI文檔 ， 其目的是根據(jù) FS+UI要求 ， 依據(jù)具體采用的開發(fā)工具與技術平臺 ， 確定軟件實現(xiàn)的對象關系與數(shù)據(jù)庫結構 。 并非項目組每個成員均參加總體設計 ， 一般來講 ， 一般中小項目總體設計為一到二個人 ， 中大型項目一般為一個總體設計小組 ， 由項目總設計師負責將項目進行分解為可操作的大小 ， 交由不同設計小組完成相關功能的總體設計 ， 總設計師負責協(xié)調各子項之間的協(xié)調關系 ， 從而完成大型的總體設計 。 總體設計設計深度情況直接影響下一步的詳細設計 。 過細的總體設計也是不必要的 ， 少量的人員進行過細的設計必然影響整個項目的設計周期 ， 而過粗的總體設計當然也不利于詳細設計設計任務的分配與設計展開 。 總體設計是軟件詳細設計及軟件集成測試的基礎 。 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? 詳細設計 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 詳細設計是總體設計的繼續(xù) ， 主要目的是完成總體設計完成的對象內部的商業(yè)邏輯的實現(xiàn)設計 。 在總體設計完成后可以將不同的設計對象交由不同的設計人員來完成 。 原則上講 ， 在開始軟件編碼之前應完成所有的設計細節(jié) ， 避免在編碼中進行設計工作 。 詳細設計是編碼及軟件模塊測試的基礎 。 (Object Internal Relationship Diagram)OIR 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? 詳細設計 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? 編碼 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 編碼是軟件詳細設計的一種再現(xiàn) 。 設定編程語言標準和內部版本標準 。 編碼中最重要的是要遵從相關開發(fā)工具的設計規(guī)范及數(shù)據(jù)庫設計規(guī)范 ， 另外 ， 養(yǎng)成一個良好的編程習慣是一個軟件公司和軟件編程人員最基本的職業(yè)素質 。 對于軟件應用可靠性要求嚴格的案例 ， 所有軟件模塊必須通過模塊測試 ， 對一般應用軟件中的重要模塊也應進行模塊測試 。 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? 集成 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 由開發(fā)人員將模塊整合 ， 根據(jù)項目總體設計測試接口工作是否完好 ？ 確保主要功能達到預期要求 。 測試受控于 QA組和項目經理 。 然后提交 CMO生成新版本 。 集成是軟件開發(fā)中重要的一環(huán) ， 如果缺乏前期的模塊測試 ，必然會導致集成時間的加長 ， 同時也會加重后期的 α測試及問題處理的工作量 。 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? α測試 （ Alpha Testing） 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 黑盒測試滿足功能規(guī)范中定義的功能與性能需求 。 α測試是在軟件集成結束后軟件開發(fā)進入的下一個環(huán)節(jié) ， 它標志著軟件開發(fā)從設計級段進入軟件測試階段 。 一般情況下 ，軟件開發(fā)從設計進入測試是通過 CMO來完成這一過程 。 測試前： ① 編制測試計劃 、 編制測試用例 ② 測試接受標準 ③ 評價與接受 測試后： ① 問題報告 ， 處理與改進 ② 測試結論 （ 包括問題報告 ） 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? α測試 （ Alpha Testing） （續(xù)） 需求分析 可行性研究 初步設計 詳細設計 編碼 FS+UI Bug Fixed Regress IRL 集成 一般而言 ， 測試工作基本上可以分為如下幾個輪回： 第一輪測試 問題處理 第二輪測試 問題處理 第三輪測試 問題處理 測試組 開發(fā)組 α測試是軟件公司對自身產品的一次自我測試， α測試結束后，測試部門會提供一個軟件測試評價報告，這個評價報告在某種程度上決定了該軟件是否適應商業(yè)銷售。 一般來講，軟件通過測試并不意味著軟件沒有任何問題，只是意味軟件通過了可接受測試條件。軟件測試的問題報告是軟件公司售后服務與產品升級的重要參考因素之一。 Alpha Testing 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? α測試 （ Alpha Testing） （續(xù)） 需求分析 可行性研究 初步設計 詳細設計 編碼 FS+UI Bug Fixed Regress IRL 集成 Alpha Testing 黑盒測試 白盒測試 兩種測試方法從不同的角度出發(fā)，反映了軟件的不同側面，也適用于不同的開發(fā)環(huán)境 白盒測試 又稱 結構測試 、邏輯驅動測試或基于程序本身的測試，也可成為 程序員測試 ，主要應用于結構化開發(fā)環(huán)境 黑盒測試 又稱 功能測試 、數(shù)據(jù)驅動測試或基于規(guī)格說明的測試，也可被成為 用戶測試 ，主要應用于快速應用開發(fā)（ RAD） 環(huán)境 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? 問題處理與設計文檔改進 （ Bug Fixed Regress） 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 問題處理是軟件開發(fā)組交付測試后的重要任務之一 ， 及時解決軟件測試過程中發(fā)現(xiàn)的問題 ， 以便進行下一輪測試 。 軟件開發(fā)人員在交付測試后的另一重要任務就是將編碼過程中對設計的修改及時反映到總體設計文檔和詳細設計文檔中去 ， 確保定版的軟件與其設計文檔的一致性 。 軟件開發(fā)的階段目標 （續(xù)） 軟件開發(fā)的階段劃分及目標 ? IRL內部定版 需求分析 可行性研究 初步設計 詳細設計 編碼 Alpha Testing FS+UI Bug Fixed Regress IRL 集成 測試合格的軟件在軟件開發(fā)部內部定版 ， 進