1軟件開發(fā)過程

1、軟件開發(fā)過程四川華迪信息技術有限公司四川華迪信息技術有限公司version1.0version1.02021-11-13hwadee2overview 課程介紹 需求分析 分析設計 實施 部署課程介紹課程介紹2021-11-13hwadee4關于本次課程o 課程目標o 預備知識o 目標聽眾o 日程表o 詞匯表2021-11-13hwadee5課程目標o了解軟件開發(fā)活動的流程o了解軟件開發(fā)活動的規(guī)范要求2021-11-13hwadee6目標聽眾o 項目組成員2021-11-13hwadee7預備知識o 了解軟件工程知識2021-11-13hwadee8日程表o 總課時:130分鐘o 授課大綱：0

2、:20介紹常用的軟件開發(fā)模式0:20需求分析0:20分析設計0:30實施0:20測試0:20部署共計: 130分鐘2021-11-13hwadee9ocmm：能力成熟度模型（capability maturity model） osqa：軟件質量保證（software quality assurance）詞匯表2021-11-13hwadee10什么是軟件開發(fā)過程o 用以開發(fā)和維護軟件及其相關產(chǎn)品（如，項目計劃、設計文檔、代碼、測試用例、用戶手冊等等）的一組活動、方法、實踐和變換2021-11-13hwadee112021-11-13hwadee12常用的軟件開發(fā)過程 瀑布式開發(fā) 迭代式開發(fā)

3、增量式開發(fā) 演化式開發(fā) 原型式開發(fā)2021-11-13hwadee13瀑布式開發(fā)模型立項立項需求分析需求分析分析設計分析設計編碼、測試編碼、測試結項結項o生存周期表現(xiàn)為線形的一組開發(fā)活動。o開發(fā)階段有明確的輸入和輸出，一個階段的輸出是下一個階段的輸入。o從一個階段進入到下一個階段，需要滿足特定的條件。 2021-11-13hwadee14迭代式開發(fā)模型先啟階段先啟階段精化階段精化階段構件階段構件階段產(chǎn)品化階段產(chǎn)品化階段 迭代開發(fā)模型將開發(fā)過程分成多個為期數(shù)周的迭代，而每個迭代包括了迭代計劃、需求分析、系統(tǒng)設計、編程、測試及評估，而每個迭代完成時都會產(chǎn)生一個可運行的版本2021-11-13hwa

4、dee15選擇生命周期模型o 沒有適合所有人的 “帽子”o 生命周期選擇應考慮：需求架構系統(tǒng)演進風險管理費用中途變更用戶對系統(tǒng)進展的可視情況管理者對系統(tǒng)進展的可視情況管理與開發(fā)經(jīng)驗2021-11-13hwadee16選擇生命周期模型2021-11-13hwadee17軟件開發(fā)角色劃分o 項目經(jīng)理o 設計人員o 編碼人員o 測試人員o 配置人員o sqao .需求分析2021-11-13hwadee19需求的重要性o 開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么。最為困難的概念性工作就是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。同時這也是一旦做錯，將最終會給系統(tǒng)帶來

5、極大損害的部分，并且以后再對它進行修改也極為困難。2021-11-13hwadee20需求問題 軟件開發(fā)中的問題1. 客戶表面上同意需求，但完成的產(chǎn)品并不能滿足需求2. 需求總是變化，無法穩(wěn)定3. 需求太多，無法在給定的時間完成4. 設計人員抱怨測試人員沒有拿最新的需求版本來設計測試5. 項目經(jīng)理發(fā)覺開發(fā)人員獨自增加了新的功能，新的功能用了很長的時間進行開發(fā)，但客戶認為價值不大6. 客戶總是不想對項目進行驗收，他們擔心系統(tǒng)無法最終滿足需要2021-11-13hwadee21需求活動的目的 定義系統(tǒng)的邊界和功能、非功能需求，以便涉眾(客戶、最終用戶)和項目組對所開發(fā)的內(nèi)容達成一致。 使項目組能夠

6、更好的理解需求，并達成一致。 建立軟件需求基線供軟件工程和管理使用。 軟件計劃、產(chǎn)品和活動同軟件需求保持一致。 為其它軟件工程活動提供基礎（如管理活動、測試活動）。2021-11-13hwadee22需求分析流程制定需求管理計劃1提取業(yè)務需求2需求開發(fā)3需求批準4基線化需求5需求變更控制6需求狀態(tài)評審7制定需求管理計劃提取業(yè)務需求需求開發(fā)需求批準基線化需求需求變更控制需求狀態(tài)評審2021-11-13hwadee23制定需求管理計劃o 定義角色和職責 o 建立跟蹤機制 o 選擇需求屬性 o 定義需求管理機制 o 編寫需求管理計劃制定需求管理計劃1提取業(yè)務需求2需求開發(fā)3需求批準4基線化需求5需求

7、變更控制6需求狀態(tài)評審7制定需求管理計劃編寫用于需求管理活動的計劃。項目經(jīng)理2021-11-13hwadee24提取業(yè)務需求o 收集用戶初始需求（業(yè)務需求）o 標識需求項制定需求管理計劃1獲取業(yè)務需求2需求開發(fā)3需求批準4基線化需求5需求變更控制6需求狀態(tài)評審7提取業(yè)務需求到用戶方進行需求調(diào)查，以獲得項目的初始需求。項目組成員2021-11-13hwadee25需求開發(fā)對客戶的需要進行分析，并用清晰合理的方式進行描述，使客戶方和開發(fā)方對開發(fā)的內(nèi)容達成一致。需求開發(fā)制定需求管理計劃1提取業(yè)務需求2需求開發(fā)3需求批準4基線化需求5需求變更控制6需求狀態(tài)評審7需求開發(fā)項目成員2021-11-13hw

8、adee26確認需求正式作為項目管理和其它工程活動的基礎，并作為客戶之間承諾對系統(tǒng)進行驗收的基準。需求批準制定需求管理計劃1提取業(yè)務需求2需求開發(fā)3需求批準4基線化需求5需求變更控制6需求狀態(tài)評審7需求批準客戶、高級管理者o 需求批準是一種正式的管理過程，代表相關各方達成一致的承諾o 經(jīng)過需求評審的需求工件作為批準的內(nèi)容2021-11-13hwadee27此活動的目的是在經(jīng)過客戶和項目組的授權下，將批準的正式的軟件需求工件放入配置管理系統(tǒng)。基線化需求制定需求管理計劃1提取業(yè)務需求2需求開發(fā)3需求批準4基線化需求5需求變更控制6需求狀態(tài)評審7基線化需求配置經(jīng)理 o 基線化正式的需求工件正式的軟件

9、需求工件、需求跟蹤工件進入配置庫，作為其它相關活動（管理、設計、測試等）的基礎。2021-11-13hwadee28需求變更控制制定需求管理計劃1提取業(yè)務需求2需求開發(fā)3需求批準4基線化需求5需求變更控制6需求狀態(tài)評審7需求變更控制配置經(jīng)理 o 需求一旦建立基線后，需要通過控制流程來改變o 需求的變更需要經(jīng)過雙方的批準o 變更后的需求需要經(jīng)過客戶、用戶和相關組的評審進入配置管理庫，作為工作基線2021-11-13hwadee29需求評審制定需求管理計劃1提取業(yè)務需求2需求開發(fā)3需求批準4基線化需求5需求變更控制6需求狀態(tài)評審7需求狀態(tài)評審o 舉行評審會議舉行評審會議 舉行需求規(guī)格說明書評審會議

10、，需求評審人員高級管理者和項目經(jīng)理通過需求狀態(tài)評審監(jiān)控需求管理的狀態(tài)。項目組通過需求狀態(tài)評審對需求狀況達成一致分析設計2021-11-13hwadee31分析設計o目的軟件分析設計活動是建立系統(tǒng)的構架，將系統(tǒng)的軟件需求分配給軟件結構，使設計適應具體的實施環(huán)境。 2021-11-13hwadee32分析設計活動流程軟件詳細設計軟件構架設計軟件構架設計評審軟件詳細設計評審基線化構架基線化詳細設計軟件需求工件軟件開發(fā)計劃軟件構架設計工件軟件詳細設計工件2021-11-13hwadee33分析設計o角色構架設計師 設計員 配置管理員 構架評審人員 詳細設計評審人員 2021-11-13hwadee34

11、分析設計o進入準則需求已經(jīng)基線化 軟件開發(fā)計劃已指派了分析設計活動 2021-11-13hwadee35分析設計o輸入軟件需求工件軟件開發(fā)計劃2021-11-13hwadee36分析設計活動介紹o構架設計 建立軟件系統(tǒng)的構架，將系統(tǒng)的軟件需求分配給軟件結構2021-11-13hwadee37分析設計活動介紹o構架設計評審 檢查軟件系統(tǒng)構架設計是否合理 ，包括如下幾點：發(fā)現(xiàn)和修復缺陷 一致性確認 2021-11-13hwadee38分析設計活動介紹o基線化構架設計 將評審通過的軟件構架設計工件置于配置管理 ，作為詳細設計的基礎 2021-11-13hwadee39分析設計活動介紹o軟件詳細設計

12、根據(jù)需求工件、構架設計工件，進一步精確描述軟件系統(tǒng)，并使之適于具體的實施環(huán)境 2021-11-13hwadee40分析設計活動介紹o詳細設計評審 檢查軟件系統(tǒng)詳細設計是否合理 ，包括如下幾點：發(fā)現(xiàn)和修復缺陷 一致性確認 2021-11-13hwadee41分析設計活動介紹o基線化詳細設計 將評審通過的軟件詳細設計工件置于配置管理，作為實施活動的基礎 2021-11-13hwadee42分析設計活動介紹o輸出軟件構架設計工件： 概要設計說明書、數(shù)據(jù)庫設計說明書 等軟件詳細設計工件 ： 詳細設計說明書評審記錄 實 施2021-11-13hwadee44q目的：單元編碼、單元測試、缺陷修復以及系統(tǒng)集

13、成等工作 q主要任務：制定集成計劃單元編碼、測試/評審集成系統(tǒng)基線化目的2021-11-13hwadee45編碼的任務o 編碼階段的任務就是將詳細設計翻譯成計算機最終可運行的軟件單元、集成工作版本。 軟件構架詳細設計工作版本軟件開發(fā)計劃編碼2021-11-13hwadee46編碼的任務o 編碼工作對一個程序員來說是司空見慣的事，然而，如何編寫出高質量的程序，還是有很多值得討論的問題。如何選擇程序設計語言?如何評價程序的質量?程序設計的風格等等。2021-11-13hwadee47詞匯表 o 代碼評審代碼評審(code review)代碼評審是檢查源代碼與編碼標準的符合性以及程序邏輯的正確性的活

14、動，目的是發(fā)現(xiàn)缺陷或者是提出改進措施。o 系統(tǒng)集成系統(tǒng)集成(system integration)系統(tǒng)集成指的是將單獨的軟件單元合并成一個整體的軟件開發(fā)活動。集成活動可以分級、分階段進行。o 工作版本工作版本(build)工作版本既可以是軟件系統(tǒng)的可操作版本，也可以是具有最終產(chǎn)品部分功能的軟件系統(tǒng)組成部分。o 程序單元程序單元(unit)程序單元是項目定義的軟件最小可測試單元。 2021-11-13hwadee48軟件實施活動流程圖 2021-11-13hwadee49角色 o 編碼員編碼員 編碼員負責編碼、修復代碼缺陷； o 集成員集成員 負責制定集成計劃、集成程序單元，創(chuàng)建工作版本基線；o

15、 測試員測試員 負責執(zhí)行測試活動； o 集成計劃評審人員集成計劃評審人員 參與集成計劃的評審，一般由設計員、測試、配置經(jīng)理、編碼員、構架設計師等組成； o 代碼評審員代碼評審員 評審源代碼，一般由編碼員（非代碼作者）組成 ；2021-11-13hwadee50進入準則 o 詳細設計工件已經(jīng)被基線化o 構架工件已經(jīng)被基線化 2021-11-13hwadee51輸入 o 軟件構架設計工件 構架設計文檔主要描述 備選設計方案、軟件子系統(tǒng)劃分、子系統(tǒng)間接口和錯誤處理機制等； o 軟件詳細設計工件 詳細設計文檔主要描述將構架設計轉化為最小實施單元，產(chǎn)生可以編碼實現(xiàn)的設計； 2021-11-13hwade

16、e52活動o 制定系統(tǒng)集成計劃 o 評審集成計劃 o 單元編碼及缺陷修復o 代碼評審o 執(zhí)行單元測試o 集成程序單元o 執(zhí)行集成測試o 執(zhí)行系統(tǒng)測試o 創(chuàng)建最終工作版本基線2021-11-13hwadee53制定系統(tǒng)集成計劃 o 角色角色 集成員 o 活動描述活動描述 確定系統(tǒng)要實施的部分，以及實施它們的先后順序。 確定集成的工作版本：確定集成的工作版本：根據(jù)開發(fā)計劃的工作內(nèi)容，將它們劃分成不同的工作版本。 確定集成的策略：確定集成的策略：定義系統(tǒng)集成的方式?？梢愿鶕?jù)系統(tǒng)自身的特點，選擇合適的集成策略，以及確定實施測試所需的驅動和樁模塊。 2021-11-13hwadee54評審集成計劃 o

17、角色角色 集成計劃評審人員 o 活動描述活動描述 發(fā)現(xiàn)缺陷，跟蹤并修復缺陷。 發(fā)現(xiàn)和修復缺陷：發(fā)現(xiàn)和修復缺陷：根據(jù)評審規(guī)范，評審集成計劃工件。2021-11-13hwadee55單元編碼及缺陷修復 o 角色角色 編碼員 o 活動描述活動描述 生產(chǎn)出同設計一致的源代碼。 編寫代碼：編寫代碼：按照分配的任務項，編寫新單元的代碼，保證源代碼只是設計的代碼實現(xiàn)，并且源代碼可以成功編譯。 缺陷修復：缺陷修復：按照分配的任務項，修復已有代碼中經(jīng)過測試或代碼評審發(fā)現(xiàn)的缺陷，并保證源代碼可以成功編譯。 2021-11-13hwadee56代碼評審 o 角色角色 代碼評審員 o 活動描述活動描述 通過閱讀他人的

18、代碼，檢查代碼中的缺陷。 檢查編寫缺陷檢查編寫缺陷：依照編碼標準檢查代碼是否符合標準。檢查邏輯缺陷檢查邏輯缺陷：根據(jù)設計工件檢查代碼是否正確反映且僅反映設計的內(nèi)容。2021-11-13hwadee57執(zhí)行單元測試 o角色角色 測試員 o活動描述活動描述 測試員執(zhí)行單元測試的目的是驗證單元的內(nèi)部結構以及單元實現(xiàn)的功能。 執(zhí)行單元測試：執(zhí)行單元測試：按照測試過程手工執(zhí)行單元測試或運行測試腳本自動執(zhí)行單元測試。 記錄單元測試結果：記錄單元測試結果：將單元測試結果作詳細記錄，并將測試結果提交給相關組。 回歸測試：回歸測試：對修改后的單元執(zhí)行回歸測試 2021-11-13hwadee58集成程序單元 o

19、 角色角色 集成員 o 活動描述活動描述 提供一個可以測試的集成工作版本。 生成集成工作版本生成集成工作版本：按照集成計劃集成并編譯已經(jīng)通過單元測試的程序單元。判斷集成結束判斷集成結束：根據(jù)集成計劃判斷集成是否結束。 2021-11-13hwadee59創(chuàng)建最終工作版本基線 o 角色角色 集成員 o 活動描述活動描述 建立一個完整的基線化的軟件工作版本。配置最終工作版本基線：配置最終工作版本基線：創(chuàng)建最終工作版本基線。2021-11-13hwadee60輸出 o 軟件程序單元 包括了所有編碼員完成的程序單元源代碼； o 工作版本 按照集成計劃創(chuàng)建的各個集成工作版本； o 集成計劃軟件工作版本的

20、定義、工作版本的內(nèi)容、集成的策略以及實施的先后順序等； o 評審記錄 記錄評審內(nèi)容、評審結果、評審意見、參與人員等； 2021-11-13hwadee61退出準則 o 最終工作版本被基線化 2021-11-13hwadee62編碼標準o 編制易于修改和維護的代碼；o 編制易于測試的代碼；o 必須將編程與編文檔的工作統(tǒng)一起來；o 編程中采用統(tǒng)一的標準和約定，降低程序復雜性；o 限定每一層的副作用，減少耦合度；o 盡可能地重用。2021-11-13hwadee63編程風格概述o 編程風格是在不影響性能的前提下，有效地編排和組織程序，以提高可讀性和可維護性。o 從軟件工程的角度來說，程序的質量主要取

21、決于設計的質量，而編程風格在很大的程度上影響著程序的可讀性、可測試性和可維護性；o 軟件開發(fā)的很大部分的成本消耗在編碼、測試和維護階段，因此，努力追求軟件的可讀性、可測試性和可維護性極其重要。2021-11-13hwadee64編程風格（一）o 節(jié)儉化（economy） 提供盡可能簡潔的代碼。o 模塊化（modularity） 把代碼劃分為內(nèi)聚度高、富有意義的功能塊。通常是把常且復雜的程序段或子程序分解為小且定義良好的程序段。o 簡單化（simplicity） 去掉過分復雜和不必要的矯揉造作。2021-11-13hwadee65編程風格（二）o 結構化（structure） 把程序的各個構件組

22、織成一個有效的系統(tǒng)。o 文檔化（documentation） 程序能夠自說明。o 格式化（layout） 盡量使程序布局合理、清晰、明了。測 試2021-11-13hwadee67測試 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程 軟件測試是根據(jù)程序開發(fā)階段的規(guī)格說明及程序內(nèi)部結構而精心設計的一批測試用例（輸入數(shù)據(jù)及其預期結果的集合），并利用這些測試用例去運行程序，以發(fā)現(xiàn)錯誤的過程2021-11-13hwadee68測試流程制訂測試計劃設計測試執(zhí)行單元測試執(zhí)行集成測試執(zhí)行系統(tǒng)測試評估測試制訂測試計劃制訂測試計劃設計測試設計測試執(zhí)行單元測試執(zhí)行單元測試執(zhí)行集成測試執(zhí)行集成測試執(zhí)行系統(tǒng)測試執(zhí)行系統(tǒng)測試評估測試評估測試2021-11-13hwadee69角色和職責o 測試設計員測試設計員制定和維護測試計劃。設計測試用例及測試過程。評估測試，生成測試分析報告。 o 測試員測試員執(zhí)行集成測試和系統(tǒng)測試。記錄測試結果。 o 設計員設計員設計測試需要的驅動程序和穩(wěn)定樁。o 編碼員編碼員編寫測試驅動程序和穩(wěn)定樁。執(zhí)行單元測試。2021-11-13hwadee70測試產(chǎn)生工件階段產(chǎn)生工件制訂測試計劃測試計劃設計測試測試用例