【文章內(nèi)容簡介】 是 以生產(chǎn)為中心 。逆向 拉動式 運作模式是 以用戶為中心 。兩種不同的運作模式 適用于不同市場環(huán)境。 4 2021 年軟考系統(tǒng)架構(gòu)設(shè)計師學(xué)習(xí)筆記第四章 軟件開發(fā)方法 軟件開發(fā)生命周期 傳統(tǒng)的軟件生命期 是指軟件產(chǎn)品 從形成概念 (構(gòu)思 )開始，經(jīng)過定義、開發(fā)、使用、維護、廢棄，的全過程。 可以把軟件生命期劃分為 軟件定義、軟件開發(fā)、軟件運行與維護，三個階段。 軟件定義時期 ，目標系統(tǒng) “是什么 ”，系統(tǒng)的定位以及范圍。 ，技術(shù)可行性、經(jīng)濟可行性、操作可行性、社會可行性。 ，確定軟件系統(tǒng)的功能需求、性能需求、運行環(huán)境的約束，寫出需求規(guī)格說明書、軟件系統(tǒng)測試大綱、用戶手冊概要。 充分理解用戶的需求，并以書面形式寫出規(guī)格說明書，這是以后 軟件設(shè)計和驗收的依據(jù) 。用戶也許很難 一次性 說清楚系統(tǒng)應(yīng)該做什么。 系統(tǒng)分析員、軟件開發(fā)人員、用戶，共同完成，逐步細化、一致化、完全化 等。 軟件需求規(guī)格說明 SRS，內(nèi)容可以有 系統(tǒng) (或子系統(tǒng) )名稱、功能描述、接口、基本數(shù)據(jù)結(jié)構(gòu)、性能、設(shè)計需求、開發(fā)標準、驗收原則 等。 軟件開發(fā)時期 軟件開發(fā)時期就是軟件的設(shè)計與實現(xiàn)，概要設(shè)計、詳細設(shè)計、編碼、測試 等。 概要設(shè)計是在軟件需求規(guī)格說明的基礎(chǔ)上，建立系統(tǒng)的 總體結(jié)構(gòu) (含子系統(tǒng)的劃分 ) 和 模塊間的關(guān)系，定義功能模塊及各功能模塊之間的關(guān)系 。 詳細設(shè)計對概要設(shè)計 產(chǎn)生的功能模塊 逐步細化，包括 算法與結(jié)構(gòu)、數(shù)據(jù)分布、數(shù)據(jù)組織、模塊間接口信息、用戶界面 等，寫出詳細設(shè)計報告。 測試可分成 單元測試、集成測試、確認測試、系統(tǒng)測試 等。通常把編碼和測試 稱為 系統(tǒng)的實現(xiàn)。 軟件運行和維護 軟件維護就是盡可能地延長軟件的壽命，沒有維護的價值時，宣告退役，軟件的生命結(jié)束。 軟件開發(fā)模型 軟件生存周期模型 又稱 軟件開發(fā)模型 或 軟件過程模型，模型的特點是 簡單化，是軟件開發(fā)實際過程的 抽象與概括。 為軟件工程管理提供 里程碑和進度表， 為軟件開發(fā)過程提供 原則和方法。軟件過程有各種各樣的模型。 瀑布型 瀑布型的特點是 因果關(guān)系緊密相連，前一個階段工作的結(jié)果是后一個階段工作的輸入，前一個階段的錯漏會隱蔽地帶到后一個階段，每一個階段工作完成后，都要進行審查和確認， 它的出現(xiàn)有利于人員的組織管理，有利于軟件開發(fā)方法和工具的研究。 原型模型 根據(jù)用戶提出的軟件系統(tǒng)的定義，快速地開發(fā)一個原型，包含目標系統(tǒng)的關(guān)鍵問題和反映目標系統(tǒng)的大致面貌。 三種途徑： 利用模擬軟件系統(tǒng)的人機界面和人機交互方式。 真正開發(fā)一個 原型。 找來一個或幾個正在運行的類似軟件進行比較。 實際工作中，由于各種原因，大多數(shù)原型都廢棄不用，僅僅把建立原型的過程 當作幫助定義軟件需要的一種手段。 用戶對系統(tǒng)模糊不清，無法準確回答目標系統(tǒng)的需求。 經(jīng)過對原型若干次修改，應(yīng)該收斂到目標范圍內(nèi)，否則可能會失敗。 對大型軟件來說，如果沒有現(xiàn)成的，就不應(yīng)該考慮用原型法。 螺旋模型 是生命周期模型與原型模型的一個結(jié)合，分成多個階段，每一個階段都由 4 部分組成： ，指定對過程和產(chǎn)品的約束，并且制訂詳細的管理計劃。 ，制訂解決辦法。 ，即開發(fā)軟件產(chǎn)品。 ，確定是否需要進入螺線的下一次回路。 增加一周，軟件系統(tǒng)就生成一個新版本，系統(tǒng)應(yīng)該盡快地收斂到用戶允許或可以接受的目標范圍內(nèi)。 該模型支持大型軟件開發(fā)，適用于面向規(guī)格說明、面向過程、面向?qū)ο? 的軟件開發(fā)方法，也適用于幾種開發(fā)方法的組合。 基于可重用構(gòu)件的模型 把軟件工程項目所創(chuàng)建的 構(gòu)件 不斷地積累和存儲在一個構(gòu)件庫中，系統(tǒng)將依賴構(gòu)件的 健壯性。 基于面向?qū)ο蟮哪Ｐ? 構(gòu)件重用是非常重要的技術(shù)之一。 一方面進行構(gòu)件開發(fā)，另一方面進行需求開發(fā)，快速建立 OOA、 OOD 原型，由重用構(gòu)件組裝而成，甚至通過組裝可重用的子系統(tǒng)而創(chuàng)建更大的系統(tǒng)。 基于四代技術(shù)的原型 四代語言 完全不用變成方式來構(gòu)造應(yīng)用系統(tǒng)，而是利用一些生成器。 與通常的軟件工程環(huán)境或計算機輔助軟件工程不同，只側(cè)重于支持應(yīng)用軟件開發(fā)過程中的 設(shè)計階段和實現(xiàn)階段，特別是支持界面以及與界面有關(guān)的處理過程 敏捷方法 敏捷方法的特點 敏捷方法是 “適應(yīng)性 ”而非 “預(yù)設(shè)性 ”的，重型方法在計劃制定完成后拒絕變化，而敏捷方法則歡迎變化。 “面向人的 ”而非 “面向過程的 ” 傳統(tǒng)的軟件開發(fā)方法的基本思路一般是 只要圖紙設(shè)計得合理并考慮充分，施工隊伍可以完全遵照圖紙順利構(gòu)造。 但是，一些設(shè)計錯誤只能在編碼和測試時才能發(fā)現(xiàn)。 傳統(tǒng)正規(guī)開發(fā)方法是 個體不重要，角色才是重要的，盡量減少人的因素對開發(fā)過程的影響，但是敏捷方法正好相反。 管理人員已經(jīng)脫離實際開發(fā)活動相當長的時間了，如此設(shè)計出來的開發(fā)過程是難以為開發(fā)人員所接受的。 只有在第一線的開發(fā)人員才能真正掌握和理解開發(fā)過程中的技術(shù)細節(jié)，所以技術(shù)方面的決定必須由他們來做出。 敏捷方法特別強調(diào) 相關(guān)人員之間的信息交流。因為項目失敗的原因最終都可以追溯到信息沒有及時準確地傳遞到應(yīng)該接受它的人。 特別提倡直接的面對面交流，交流成本遠遠低于文檔的交流。 按照高內(nèi)聚、松散耦合的原則 將項目劃分為若干個小組，以增加溝通。 敏捷方法的核心思想 ，利用變化來發(fā)展。 ，在無過程控制和過于嚴格繁瑣的過程控制中取得一種平衡，以保證軟件的質(zhì)量。 ，發(fā)行版本小型化，根據(jù)客戶需求的 優(yōu)先級和開發(fā)風(fēng)險，制訂版本發(fā)行計劃。 敏捷方 法的含義及其特征 重型方法注重開發(fā)文檔的完備和充分性 。而敏捷方法認為最根本的文檔應(yīng)該是源碼。 敏捷方法的適用范圍 實際上，滿足工程設(shè)計標準的唯一文檔是源代碼清單。 敏捷方法比較適合需求變化比較大 或者 開發(fā)前期對需求不是很清晰的項目。 敏捷方法對設(shè)計者、開發(fā)者、客戶 之間的有效溝通和及時反饋要求比較高，不易在開發(fā)團隊比較龐大的項目中實施。 敏捷方法的主要內(nèi)容 四個核心價值觀：溝通、簡單、反饋、勇氣。 簡單：只要滿足當前功能需求，不做假象設(shè)計。 勇氣：用于抉擇，用于實踐 ，用于重構(gòu)。 12 條實踐規(guī)則：簡單設(shè)計、測試驅(qū)動、代碼重構(gòu)、結(jié)對編程、繼續(xù)集成、現(xiàn)場客戶、開發(fā)版本小型化、系統(tǒng)隱喻、代碼集體所有制、規(guī)劃策略、規(guī)范代碼、 40 小時工作機制。 主要敏捷方法簡介 極限編程 水晶系列方法 開放式源碼，任何人發(fā)現(xiàn) Bug 都可以將補丁發(fā)給維護者。 SCRUM Coad 的功用驅(qū)動開發(fā)方法：短時迭代階段 和 可見可用的功能，一個迭代周期一般為兩周，編程人員分為 類程序員、首席程序員。 ASD 方法，猜測、合作、學(xué)習(xí)。 RUP RUP 把軟件開發(fā)生命周期劃分為 多個循環(huán) (cycle)，每個 cycle 生成產(chǎn)品的一個新版本，每個 cycle 依次由 4 個連續(xù)階段 (phase)組成： 初始：定義最終產(chǎn)品視圖和業(yè)務(wù)模型，并確定系統(tǒng)范圍。 細化：制定工作計劃及資源要求。 構(gòu)造。 移交。 迭代并不是重復(fù)地做相同的事，而是針對不同用例細化和實現(xiàn)，每一個迭代都是一個完整的開發(fā)過程。 每個階段結(jié)束前有一個里程碑 (milestone)評估該階段的工作。如果未能通過該里程碑的評估，則決策者應(yīng)該做出決定，是取消該項目還是繼續(xù)做該階段的工作。 RUP 中的核心概念 角色 (Role)， who 的問題，某個人或一個小組的行為與職責。 活動 (Activity)， how 的問題，是一個有明確目的的獨立工作單元。 制品 (Artifact)， what 的問題，是活動生成、創(chuàng)建、修改 第一段信息。 工作流 (Workflow)， when 的問題，每個工作流產(chǎn)生一些有價值的產(chǎn)品，并顯示了角色之間的關(guān)系。 RUP 的特點 RUP 是用例驅(qū)動的、以體系結(jié)構(gòu)為中心的、迭代和增量的軟件開發(fā)過程。 用例驅(qū)動：需求分析、設(shè)計、實現(xiàn)、測試，都是用例驅(qū)動的。 以體系結(jié)構(gòu)為中心：刻畫了系統(tǒng) 的整體設(shè)計，去掉了細節(jié)部分，突出了系統(tǒng)的重要特征。 不依賴于具體語言，是軟件設(shè)計過程的一個層次。 體系結(jié)構(gòu)層次的設(shè)計問題包括：總體組織和全局控制、通訊協(xié)議、同步、數(shù)據(jù)存取、給設(shè)計元素分配特定功能、設(shè)計元素的組織、物理分布、系統(tǒng)的伸縮性、性能 等。 一個系統(tǒng)不可能在所有特性上都達到最優(yōu)，對于一個系統(tǒng)，不同人員所關(guān)心的內(nèi)容也是不一樣的，對于不同類型的人員，只需提供這類人員關(guān)心的視圖即可。 分析和測試人員關(guān)心用例圖，最終用戶關(guān)心邏輯視圖，程序員關(guān)心實現(xiàn)視圖，系統(tǒng)工程師關(guān)心部署視圖。 RUB 強調(diào) 采用迭代和增量的方法來開發(fā)軟件，每次迭代中，之考慮系統(tǒng)的一部分需求，每次增加一些新的功能實現(xiàn)。 好處： 早期就可以對關(guān)鍵的、影響大的風(fēng)險進行處理。 可以提出一個軟件體系結(jié)構(gòu)來指導(dǎo)開發(fā)。 處理不可避免的需求變更。 可以較早地得到一個可運行的系統(tǒng)，鼓舞開發(fā)團隊的士氣，增強項目成功的信心。 更有效工作的開發(fā)過程。 沒有一個項目會使用 RUP 中所有的東西，用用 RUP 時要裁剪，裁剪步驟： 需要哪些工作流。 。 (初始階段、細化階段、構(gòu)造階段、移交階段 )如何演進。 。 。 軟件系統(tǒng)工具 按軟件過程活動將軟件工具分為 軟件開發(fā)工具、軟件維護工具、軟件管理和軟件支持工具。 軟件開發(fā)工具有：需求分析工具、設(shè)計工具、編碼與排錯工具、測試工具 等。 需求分析工具，生成完整的、清晰的、一致的功能規(guī)范。功能規(guī)范是軟件開發(fā)者和用戶間的契約，也是軟件設(shè)計者的和實現(xiàn)者的依據(jù)。正確、完整 表達清晰的、無歧義的。 需求分析工具分為 基于自然語言或圖形描述的工具，基于形式化 需求定義語言的工具。 項目管理工具：項目的 計劃、調(diào)度、通信、成本估算、資源分配、質(zhì)量控制等。 需求管理 需求 最終文檔 經(jīng)過評審批準后，則定義了需求基線 Baseline。構(gòu)筑了 功能需求 和 非功能需求 的一個 約定 Agreement。約定是需求開發(fā)和需求管理之間的橋梁。 需求管理是一個 對系統(tǒng) 需求變更、了解和控制 的過程，初始需求導(dǎo)出的同時 就啟動了需求管理規(guī)劃。 需求管理原則 過程能力成熟度模型 CMM，指導(dǎo)軟件過程改進， 5 個成熟級別， 6個關(guān)鍵過程域 KPA。 一旦需求 文檔化了，開 發(fā)組和有關(guān)團隊 需要評審文檔。發(fā)現(xiàn)問題應(yīng)與客戶或者其他需求源協(xié)商解決。軟件開發(fā)計劃是基于 已確認的需求。 絕不要承諾 任何 無法實現(xiàn)的事。 關(guān)鍵處理領(lǐng)域 通過版本控制和變更控制 來管理需求文檔。確保與新的需求保持一致。 需求規(guī)格說明的版本控制 版本控制是管理需求的一個必要方面，必須統(tǒng)一確定需求文檔的每一個版本，當需求發(fā)生變更時，及時通知所有涉及人員。 為了盡量減少困惑、沖突、誤傳，應(yīng)該僅允許指定的人員來更新需求。 清楚地區(qū)分草稿和文檔定稿版本。 需求變更 遲到的 需求變更 會對已進行的 工作產(chǎn)生非常大的影響。 如果每一個建議的需求變更都采用，該項目將可能永遠無法完成。 需求文檔應(yīng)該 精確描述 要交付的產(chǎn)品。 項目負責人 在信息充分的條件下 做出決策。 變更成本計算 應(yīng)該包括 需求文檔的修改、系統(tǒng)修改的設(shè)計、實現(xiàn)的成本。 變更控制過程 并不是給變更設(shè)置障礙，相反，它是一個渠道和過濾器，確保采納最合適的變更，使變更產(chǎn)生的負面影響降到最低，變更過程應(yīng)該做成文檔。 絕不能 刪除或者修改 變更請求的 原始文檔。 變更控制委員會 只要能決定合適的人做正確的事就足夠了，在保證 權(quán)威性的前提下 應(yīng)盡可能精簡人員。 對每個變更 權(quán)衡利弊 做出決定。 “利 ”包括 節(jié)省資金 或 額外收入、客戶滿意度、競爭優(yōu)勢、減少上市時間 。 “弊 ”是指 增加開發(fā)費用、推遲交付日期、產(chǎn)品質(zhì)量下降、減少功能、用戶不滿意。 變更總是有代價的，即使 拒絕的變更 也因為決策行為 而耗費資源。 接受了重要的需求變更時，為了適應(yīng)變更情況 要與管理部門和客戶重新協(xié)商約定。推遲交貨時間、增加人手、推遲實現(xiàn)尚未實現(xiàn)的較低優(yōu)先級的需求，或質(zhì)量上進行折中。 要是不能