【文章內(nèi)容簡介】 個構件庫中，系統(tǒng)將依賴構件的健壯性?！　』诿嫦驅ο蟮哪Ｐ蜆嫾赜檬欠浅Ｖ匾募夹g之一。一方面進行構件開發(fā)，另一方面進行需求開發(fā)，快速建立 OOA、OOD 原型，由重用構件組裝而成，甚至通過組裝可重用的子系統(tǒng)而創(chuàng)建更大的系統(tǒng)?！　』谒拇夹g的原型　　四代語言 完全不用變成方式來構造應用系統(tǒng)，而是利用一些生成器。與通常的軟件工程環(huán)境或計算機輔助軟件工程不同，只側重于支持應用軟件開發(fā)過程中的 設計階段和實現(xiàn)階段，特別是支持界面以及與界面有關的處理過程　 敏捷方法　　敏捷方法的特點　　敏捷方法是“適應性”而非“預設性”的，重型方法在計劃制定完成后拒絕變化，而敏捷方法則歡迎變化?！　　懊嫦蛉说摹倍恰懊嫦蜻^程的”　　傳統(tǒng)的軟件開發(fā)方法的基本思路一般是 只要圖紙設計得合理并考慮充分，施工隊伍可以完全遵照圖紙順利構造?！　〉?，一些設計錯誤只能在編碼和測試時才能發(fā)現(xiàn)。　　傳統(tǒng)正規(guī)開發(fā)方法是 個體不重要，角色才是重要的，盡量減少人的因素對開發(fā)過程的影響，但是敏捷方法正好相反?！　」芾砣藛T已經(jīng)脫離實際開發(fā)活動相當長的時間了，如此設計出來的開發(fā)過程是難以為開發(fā)人員所接受的?！　≈挥性诘谝痪€的開發(fā)人員才能真正掌握和理解開發(fā)過程中的技術細節(jié)，所以技術方面的決定必須由他們來做出?！　∶艚莘椒ㄌ貏e強調(diào) 相關人員之間的信息交流。因為項目失敗的原因最終都可以追溯到信息沒有及時準確地傳遞到應該接受它的人?！　√貏e提倡直接的面對面交流，交流成本遠遠低于文檔的交流。按照高內(nèi)聚、松散耦合的原則 將項目劃分為若干個小組，以增加溝通?！　∶艚莘椒ǖ暮诵乃枷搿　?，利用變化來發(fā)展?！　?，在無過程控制和過于嚴格繁瑣的過程控制中取得一種平衡，以保證軟件的質量。，發(fā)行版本小型化，根據(jù)客戶需求的 優(yōu)先級和開發(fā)風險，制訂版本發(fā)行計劃?！　∶艚莘椒ǖ暮x及其特征重型方法注重開發(fā)文檔的完備和充分性。而敏捷方法認為最根本的文檔應該是源碼?！　∶艚莘椒ǖ倪m用范圍　　實際上，滿足工程設計標準的唯一文檔是源代碼清單。　　敏捷方法比較適合需求變化比較大 或者 開發(fā)前期對需求不是很清晰的項目。敏捷方法對設計者、開發(fā)者、客戶 之間的有效溝通和及時反饋要求比較高，不易在開發(fā)團隊比較龐大的項目中實施?！　∶艚莘椒ǖ闹饕獌?nèi)容　　四個核心價值觀：溝通、簡單、反饋、勇氣?！　『唵危褐灰獫M足當前功能需求，不做假象設計。　　勇氣：用于抉擇，用于實踐，用于重構。12條實踐規(guī)則：簡單設計、測試驅動、代碼重構、結對編程、繼續(xù)集成、現(xiàn)場客戶、開發(fā)版本小型化、系統(tǒng)隱喻、代碼集體所有制、規(guī)劃策略、規(guī)范代碼、40小時工作機制?！　≈饕艚莘椒ê喗椤　O限編程　　水晶系列方法　　開放式源碼，任何人發(fā)現(xiàn)Bug都可以將補丁發(fā)給維護者?！　CRUM　　Coad的功用驅動開發(fā)方法：短時迭代階段 和 可見可用的功能，一個迭代周期一般為兩周，編程人員分為 類程序員、首席程序員?！　SD方法，猜測、合作、學習。　　 RUP　　RUP把軟件開發(fā)生命周期劃分為多個循環(huán)(cycle)，每個cycle生成產(chǎn)品的一個新版本，每個cycle依次由4個連續(xù)階段(phase)組成：　　初始：定義最終產(chǎn)品視圖和業(yè)務模型，并確定系統(tǒng)范圍?！　〖毣褐贫üぷ饔媱澕百Y源要求?！　嬙??！　∫平弧！　〉⒉皇侵貜偷刈鱿嗤氖拢轻槍Σ煌美毣蛯崿F(xiàn)，每一個迭代都是一個完整的開發(fā)過程。　　每個階段結束前有一個里程碑(milestone)評估該階段的工作。如果未能通過該里程碑的評估，則決策者應該做出決定，是取消該項目還是繼續(xù)做該階段的工作?！　UP中的核心概念　　角色(Role)，who的問題，某個人或一個小組的行為與職責。　　活動(Activity)，how的問題，是一個有明確目的的獨立工作單元?！　≈破?Artifact)，what的問題，是活動生成、創(chuàng)建、修改 第一段信息。工作流(Workflow)，when的問題，每個工作流產(chǎn)生一些有價值的產(chǎn)品，并顯示了角色之間的關系?！　UP的特點　　RUP是用例驅動的、以體系結構為中心的、迭代和增量的軟件開發(fā)過程?！　∮美寗樱盒枨蠓治?、設計、實現(xiàn)、測試，都是用例驅動的。　　以體系結構為中心：刻畫了系統(tǒng)的整體設計，去掉了細節(jié)部分，突出了系統(tǒng)的重要特征?！　〔灰蕾囉诰唧w語言，是軟件設計過程的一個層次。　　體系結構層次的設計問題包括：總體組織和全局控制、通訊協(xié)議、同步、數(shù)據(jù)存取、給設計元素分配特定功能、設計元素的組織、物理分布、系統(tǒng)的伸縮性、性能 等?！　∫粋€系統(tǒng)不可能在所有特性上都達到最優(yōu)，對于一個系統(tǒng)，不同人員所關心的內(nèi)容也是不一樣的，對于不同類型的人員，只需提供這類人員關心的視圖即可。　　分析和測試人員關心用例圖，最終用戶關心邏輯視圖，程序員關心實現(xiàn)視圖，系統(tǒng)工程師關心部署視圖?！　UB強調(diào)采用迭代和增量的方法來開發(fā)軟件，每次迭代中，之考慮系統(tǒng)的一部分需求，每次增加一些新的功能實現(xiàn)?！　『锰帲骸　≡缙诰涂梢詫﹃P鍵的、影響大的風險進行處理?！　】梢蕴岢鲆粋€軟件體系結構來指導開發(fā)。　　處理不可避免的需求變更?！　】梢暂^早地得到一個可運行的系統(tǒng)，鼓舞開發(fā)團隊的士氣，增強項目成功的信心?！　「行Чぷ鞯拈_發(fā)過程。　　沒有一個項目會使用RUP中所有的東西，用用RUP時要裁剪，裁剪步驟：　　 需要哪些工作流?！　?。　　(初始階段、細化階段、構造階段、移交階段)如何演進?！　??！?軟件系統(tǒng)工具　　按軟件過程活動將軟件工具分為 軟件開發(fā)工具、軟件維護工具、軟件管理和軟件支持工具?！　≤浖_發(fā)工具有：需求分析工具、設計工具、編碼與排錯工具、測試工具 等。　　需求分析工具，生成完整的、清晰的、一致的功能規(guī)范。功能規(guī)范是軟件開發(fā)者和用戶間的契約，也是軟件設計者的和實現(xiàn)者的依據(jù)。正確、完整 表達清晰的、無歧義的?！　⌒枨蠓治龉ぞ叻譃?基于自然語言或圖形描述的工具，基于形式化需求定義語言的工具。項目管理工具：項目的 計劃、調(diào)度、通信、成本估算、資源分配、質量控制等?！　?需求管理　　需求 最終文檔 經(jīng)過評審批準后，則定義了需求基線 Baseline。構筑了 功能需求 和 非功能需求 的一個 約定Agreement。約定是需求開發(fā)和需求管理之間的橋梁。需求管理是一個 對系統(tǒng) 需求變更、了解和控制 的過程，初始需求導出的同時 就啟動了需求管理規(guī)劃?！　?需求管理原則　　過程能力成熟度模型 CMM，指導軟件過程改進，5個成熟級別，6個關鍵過程域KPA?！　∫坏┬枨?文檔化了，開發(fā)組和有關團隊 需要評審文檔。發(fā)現(xiàn)問題應與客戶或者其他需求源協(xié)商解決。軟件開發(fā)計劃是基于 已確認的需求?！　〗^不要承諾 任何 無法實現(xiàn)的事?！　￡P鍵處理領域 通過版本控制和變更控制 來管理需求文檔。確保與新的需求保持一致?！　?需求規(guī)格說明的版本控制　　版本控制是管理需求的一個必要方面，必須統(tǒng)一確定需求文檔的每一個版本，當需求發(fā)生變更時，及時通知所有涉及人員?！　榱吮M量減少困惑、沖突、誤傳，應該僅允許指定的人員來更新需求。清楚地區(qū)分草稿和文檔定稿版本。　　 需求變更　　遲到的 需求變更 會對已進行的工作產(chǎn)生非常大的影響。　　如果每一個建議的需求變更都采用，該項目將可能永遠無法完成?！　⌒枨笪臋n應該 精確描述 要交付的產(chǎn)品?！　№椖控撠熑?在信息充分的條件下 做出決策?！　∽兏杀居嬎?應該包括 需求文檔的修改、系統(tǒng)修改的設計、實現(xiàn)的成本?！　∽兏刂七^程 并不是給變更設置障礙，相反，它是一個渠道和過濾器，確保采納最合適的變更，使變更產(chǎn)生的負面影響降到最低，變更過程應該做成文檔?！　〗^不能 刪除或者修改 變更請求的 原始文檔?！　∽兏刂莆瘑T會 只要能決定合適的人做正確的事就足夠了，在保證權威性的前提下 應盡可能精簡人員?！　γ總€變更 權衡利弊 做出決定?！　　袄卑?節(jié)省資金 或 額外收入、客戶滿意度、競爭優(yōu)勢、減少上市時間?！　　氨住笔侵?增加開發(fā)費用、推遲交付日期、產(chǎn)品質量下降、減少功能、用戶不滿意。　　變更總是有代價的，即使 拒絕的變更 也因為決策行為 而耗費資源。　　接受了重要的需求變更時，為了適應變更情況 要與管理部門和客戶重新協(xié)商約定。推遲交貨時間、增加人手、推遲實現(xiàn)尚未實現(xiàn)的較低優(yōu)先級的需求，或質量上進行折中。要是不能獲得一些約定的調(diào)整，應該把面臨的風險寫進風險計劃中?！　?需求跟蹤　　需求、體系結構、其他設計部件、源代碼模塊、測試、幫助文件、文檔 等?！　「櫮芰?聯(lián)系)鏈(traceability link)是優(yōu)秀需求規(guī)格說明書的一個特征，確保軟件需求規(guī)格說明包括所有客戶需求?！　「櫮芰β?lián)系鏈 記錄了單個需求之間的 父層、互連、依賴 的關系。不必擁有所有種類的跟蹤能力聯(lián)系鏈，要根據(jù)具體情況調(diào)整?！　?需求變更的代價和風險　　只有在知道變更成本后 才能做出理智的選擇，一個表面上很簡單的變更 也可能轉變成很復雜的局面。影響分析 確定對現(xiàn)有系統(tǒng)做出是修改或者拋棄的決定，創(chuàng)建新系統(tǒng)以及評估每個任務的工作量，進行 影響分析的能力 依賴于 跟蹤能力、數(shù)據(jù)的質量、完整性。 開發(fā)管理　　范圍　　可交付物、架設、約束條件 的基礎上準備詳細的項目范圍說明書，是項目成功的關鍵。　　時間　　進度安排的準確程度可能比成本估計的準確程度更重要。對于成本估計的偏差，可以靠重新定價或大量的銷售來彌補成本的增加，　　如果進度計劃不能得到實施，則會導致市場機會的喪失或用戶不滿意，而且會使成本增加。工作分解結構 Work Breakdown Structure WBS　　 配置管理 文檔管理　　配置管理　　配置項 Configuration Item CI，　　屬于產(chǎn)品組成部分的工作成果，如 需求文檔、設計文檔、源代碼、測試用例 等?！　儆陧椖抗芾砗蜋C構支撐過程域 產(chǎn)生的文檔，如 工作計劃、項目質量報告、項目跟蹤報告 等。每個配置項的主要屬性有 名稱、標識符、文件狀態(tài)、版本、作者、日期 等?！　∥臋n管理　　文檔是影響軟件可維護性的決定因素，使用過程中必然會經(jīng)受多次修改，所以文檔比程序代碼更重要。　　用戶文檔：主要描述系統(tǒng)功能和使用方法。　　系統(tǒng)文檔：描述系統(tǒng)設計、實現(xiàn)、測試 等各方面內(nèi)容?！　≤浖臋n應該滿足下述要求：　　　　 和 管理　　 和 設計　　 和 測試說明用戶操作錯誤時 應該怎樣恢復和重新啟動?！　?軟件開發(fā)的質量與風險　　軟件質量　　IOS9000 對 項目質量 的定義：一組固有特性 滿足需求的 程度?！　≠|量 與 范圍、成本 和 時間，是項目成功的關鍵因素，通過范圍管理 轉換隱含需求為項目需求。質量低 說明產(chǎn)品或服務存在問題，而低等級的產(chǎn)品或服務 不一定存在問題，二者概念不同。　　軟件開發(fā)風險　　認識不足 或者 沒有足夠的力量加以控制?！　×私?、掌握 風險的來源、性質、發(fā)生規(guī)律，進而施行有效的管理?；蛉恍?、不確定性、涉及到某種選擇時，才成為有風險，以上三個是風險定義的必要條件，不是充分條件，具有不確定性的事件不一定是風險。　　 結構化分析與設計　　結構程序設計 較流行的定義為：采用自頂向下 逐步求精 的設計方法 和 單入口單出口的控制構件?！　∽皂斚蛳轮鸩角缶姆椒ㄊ牵合日w后局部，先抽象后具體，一般具有較清晰的層次?！　H使用單入口單出口的控制構件，具有良好的結構特征?！　〔捎媒Y構程序設計，可能會多占用一些時間和空間資源，這也是那些反對從高級語言中排除GOTO語句者的主要依據(jù)。實際上，硬件飛速發(fā)展，這點耗費，不再是重要的因素。　　 面向對象的分析設計　　面向對象的 分析模型主要由 頂層架構圖、用例與用例圖、領域概念模型 構成。　　設計模型包含：　　以包圖表示的 軟件體系結構圖、　　以交互圖表示的 用例實現(xiàn)圖、　　完整精確的類圖、　　針對復雜對象的狀態(tài)圖、描述流程化處理過程的 活動圖 等?！?軟件的重用　　重復使用 相同或相似 軟件元素?！　≤浖兀盒枨蠓治鑫臋n、設計過程、設計文檔、程序代碼、測試用例、領域知識 等，通產(chǎn)這些軟件元素稱為 軟部件?！　〔粩嗟剡M行軟部件的積累，并將它們組織成軟部件庫?！　M向重用(horizontal reuse)：重用不同應用領域中的軟件元素。　　標準函數(shù)庫 是一種 典型的、原始的 橫向重用機制。　　縱向重用廣受矚目，并稱為軟件重用技術的真正希望所在，關鍵點是 域分析，根據(jù)應用領域的 特征 以及 相似性 預測軟部件的可重用性。　　庫的組織結構 直接影響軟部件的檢索效率。由于軟部件大都經(jīng)過嚴格的質量認證，并在實際運行環(huán)境中得到檢驗，因此重用軟部件有助于改善軟件質量?！　?逆向工程與重構工程　　逆向工程 就是 分析已有的程序，尋找比源代碼更高級的抽象表現(xiàn)形式。　　相關概念：　　重構 Restructuring，在同一抽象級別上轉換系統(tǒng)描述形式?！　≡O計恢復 design recovery，　　重構工程 reengineering，也稱 修復和改造工程。　　恢復信息的級別　　逆向工程導出的信息，4個抽象層次　　　　　　　　　　恢復信息的方法，4類：　　　　　　　　2011年軟考系統(tǒng)架構設計師學習筆記第五章　　軟件架構設計　　Software Architecture 簡稱 SA　　 軟件架構設計與生命周期　　需求分析階段需求 和 SA設計 面臨的是不同的對象：一個是問題空間。另一個是解空間。保持二者的可跟蹤性和轉換?！　≡O計階段　　 構件，隨