【正文】 試 開發(fā)未找到 構(gòu)件的部分 應(yīng)用系統(tǒng)工程 應(yīng)用系統(tǒng) 領(lǐng)域工程 軟件工程課程 概論 111/151 ? 領(lǐng)域工程的目的是構(gòu)建領(lǐng)域模型、領(lǐng)域基準體系結(jié)構(gòu)和可復(fù)用構(gòu)件庫。 ?領(lǐng)域分析分析該領(lǐng)域中各種應(yīng)用系統(tǒng)的公共部分或相似部分，構(gòu)建領(lǐng)域模型和領(lǐng)域基準體系結(jié)構(gòu)（ reference architecture），標識領(lǐng)域的候選構(gòu)件。 ?對候選構(gòu)件進行可變性分析，以適應(yīng)多個應(yīng)用系統(tǒng)的需要。 ?構(gòu)建可復(fù)用構(gòu)件，經(jīng)嚴格測試和包裝后存入可復(fù)用構(gòu)件庫（稱為構(gòu)件工程）。 軟件工程課程 概論 112/151 ? 應(yīng)用系統(tǒng)工程的目的是使用可復(fù)用構(gòu)件組裝應(yīng)用系統(tǒng)。 ?分析待開發(fā)的應(yīng)用系統(tǒng)，設(shè)計應(yīng)用系統(tǒng)的體系結(jié)構(gòu)，標識應(yīng)用系統(tǒng)所需的構(gòu)件。 ?在可復(fù)用構(gòu)件庫中查找合適的構(gòu)件（也可購買第三方的構(gòu)件）。 ?特化選中的構(gòu)件，必要時作適當?shù)男薷?，以適應(yīng)該應(yīng)用系統(tǒng)的需要。 ?開發(fā)那些未找到合適構(gòu)件的應(yīng)用部分。 ?組裝應(yīng)用系統(tǒng)。 ?評價構(gòu)件的復(fù)用情況，以改進可復(fù)用構(gòu)件，同時對新開發(fā)的部分進行評價，并向構(gòu)件工程推薦候選構(gòu)件。 軟件工程課程 概論 113/151 ? 根據(jù) ATamp。T、 Ericsson、 HP公司的經(jīng)驗，有的軟件復(fù)用率高達 90%以上，產(chǎn)品上市時間可縮短 2～ 5倍，錯誤率減少 5～10倍，開發(fā)成本減少 15%～ 75%。僅管這些結(jié)論出自一些較好使用基于構(gòu)件開發(fā)的實例，但毫無疑問，基于構(gòu)件的開發(fā)模型對提高軟件生產(chǎn)率、提高軟件質(zhì)量、降低成本、提早上市時間起到很大的作用。 軟件工程課程 概論 114/151 形式方法模型 ? 形式化方法（ formal methods）是建立在嚴格數(shù)學基礎(chǔ)上的一種軟件開發(fā)方法。軟件開發(fā)的全過程中，從需求分析、規(guī)約、設(shè)計、編程、系統(tǒng)集成、測試、文檔生成、直至維護各個階段，凡是采用嚴格的數(shù)學語言，具有精確的數(shù)學語義的方法，都稱為形式化方法。 ? 形式化方法用嚴格的數(shù)學語言和語義描述功能規(guī)約和設(shè)計規(guī)約，通過數(shù)學的分析和推導(dǎo)，易于發(fā)現(xiàn)需求的岐義性、不完整性和不一致性，易于對分析模型、設(shè)計模型和程序進行驗證。通過數(shù)學的演算，使得從形式化功能規(guī)約到形式化設(shè)計規(guī)約，以及從形式化設(shè)計規(guī)約到程序代碼的轉(zhuǎn)換成為可能。 軟件工程課程 概論 115/151 凈室過程模型 系 統(tǒng) 工 程 需求 收集 代碼 審查 盒結(jié)構(gòu)規(guī)約 形式化設(shè)計 正確性驗證 代碼 生成 統(tǒng)計 使用 測試 認證 測 試 計 劃 增量 1 需求 收集 代碼 審查 盒結(jié)構(gòu)規(guī)約 形式化設(shè)計 正確性驗證 代碼 生成 統(tǒng)計使用測試 認證 測 試 計 劃 需求 收集 代碼 審查 盒結(jié)構(gòu)規(guī)約 形式化設(shè)計 正確性驗證 代碼 生成 統(tǒng)計使用測試 認證 測 試 計 劃 增量 2 增量 3 軟件工程課程 概論 116/151 內(nèi)容摘要 ? 計算機軟件 ? 軟件工程 ? 軟件過程 ? 軟件過程模型 ? 敏捷軟件開發(fā) ? CASE工具與環(huán)境 軟件工程課程 概論 117/151 敏捷軟件開發(fā) ? 軟件開發(fā)的新挑戰(zhàn) ?快速的市場進入時間，要求高生產(chǎn)率 ?快速變化的需求 ?快速發(fā)展的技術(shù) ? 傳統(tǒng)的軟件開發(fā)方法 ?強調(diào)過程 ?強調(diào)文檔 ?開發(fā)人員負擔過重 稱為重載 (Heavyweight)方法 軟件工程課程 概論 118/151 ? 針對上述問題，產(chǎn)生了一系列輕載(Lightweight)方法，如 XP、 SCRUM等。 ? 2022年 2月，新方法的一些創(chuàng)始人在美國猶他州成立了敏捷軟件開發(fā)聯(lián)盟 ，簡稱 Agile 聯(lián)盟。 ? Agile 聯(lián)盟起草了一個敏捷軟件開發(fā)宣言，該宣言由四個價值觀聲明組成，并提煉出敏捷軟件開發(fā)方法必須遵循的 12條原則。 ? Agile方法是在保證軟件開發(fā)有成功產(chǎn)出的前提下，盡量減少開發(fā)過程中的活動和制品的方法。籠統(tǒng)的講就是， “ 剛剛好 ” （ Just enough），即開發(fā)中的活動及制品既不要太多也不要太少。 軟件工程課程 概論 119/151 Agile方法的價值觀 ? 個人和交互高于過程和工具 不是否定過程和工具的重要性，而是更強調(diào)軟件開發(fā)中人的作用和交流的作用。 軟件是由人組成的團隊來開發(fā)的，與軟件項目相關(guān)的各類人員通過充分的交流和有效的合作，才能成功地開發(fā)出得到用戶滿意的軟件。 如果光有定義良好的過程和先進的工具，而人員的技能很差，又不能很好地交流和協(xié)作，軟件是很難成功地開發(fā)的。 軟件工程課程 概論 120/151 ? 可運行軟件高于詳盡的文檔 通過執(zhí)行一個可運行的軟件來了解軟件做了什么，遠比閱讀厚厚的文檔要容易得多。 敏捷軟件開發(fā)強調(diào)不斷地快速地向用戶提交可運行的軟件（不一定是完整的軟件），以得到用戶的認可。 好的必要的文檔仍是需要的，它能幫助我們理解軟件做什么，怎么做以及如何使用，但軟件開發(fā)的主要目標是創(chuàng)建可運行的軟件。 軟件工程課程 概論 121/151 ? 與客戶協(xié)作高于合同（契約）談判 只有客戶才能明確說明需要什么樣的軟件，然而，大量的實踐表明，在開發(fā)的早期客戶常常不能完整地表達他們的全部需求，有些早期確定的需求，以后也可能會改變。 要想通過合同談判的方式，將需求固定下來常常是困難的。 敏捷軟件開發(fā)強調(diào)與客戶的協(xié)作，通過與客戶的交流和緊密合作來發(fā)現(xiàn)用戶的需求。 軟件工程課程 概論 122/151 ? 對變更及時做出反應(yīng)高于遵循計劃 任何軟件項目的開發(fā)都應(yīng)該制訂一個項目計劃，以確定各開發(fā)任務(wù)的優(yōu)先順序和起止日期。然而，隨著項目的進展，需求、業(yè)務(wù)環(huán)境、技術(shù)等都可能變化，任務(wù)的優(yōu)先順序和起止日期也可能因種種原因會改變。 因此，項目計劃應(yīng)具有可塑性，有變動的余地。當出現(xiàn)變化時及時做出反應(yīng)，修訂計劃以適應(yīng)變化。 軟件工程課程 概論 123/151 Agile方法的指導(dǎo)原則 （ 1） 最優(yōu)先的是通過盡早地和不斷地提交有價值的軟件使客戶滿意 （ 2） 歡迎變化的需求 ， 即使該變化出現(xiàn)在開發(fā)的后期 ， 為了提升對客戶的競爭優(yōu)勢 ，Agile過程利用變化作為動力 （ 3） 以幾周到幾個月為周期 ， 盡快 、 不斷地發(fā)布可運行軟件 （ 4） 在整個項目過程中 ， 業(yè)務(wù)人員和開發(fā)人員必須天天一起工作 軟件工程課程 概論 124/151 （ 5） 以積極向上的員工為中心建立項目組 ，給予他們所需的環(huán)境和支持 ， 對他們的工作予以充分的信任 （ 6） 項目組內(nèi)效率最高 、 最有效的信息傳遞方式是面對面的交流 （ 7） 測量項目進展的首要依據(jù)是可運行的軟件 （ 8） 敏捷過程提倡可持續(xù)的開發(fā) ， 項目發(fā)起者 、 開發(fā)者和用戶應(yīng)能長期保持恒定的速度 軟件工程課程 概論 125/151 （ 9） 應(yīng)時刻關(guān)注技術(shù)上的精益求精和好的設(shè)計 ， 以增強敏捷性 （ 10） 簡單化是必不可少的 ， 這是盡可能減少不必要工作的藝術(shù) （ 11） 最好的構(gòu)架 、 需求和設(shè)計出自于自我組織的團隊 （ 12） 團隊要定期反思怎樣才能更有效 ， 并據(jù)此調(diào)整自己的行為 軟件工程課程 概論 126/151 Agile方法的適用范圍 Martin Fowler認為：新方法不是到處可適用的 適合采用 Agile方法的情況： ? 需求不確定、易揮發(fā)（ Volatile,意指今天的要求明天就不需要了） ? 有責任感和積極向上的開發(fā)人員 ? 用戶容易溝通并能參與 軟件工程課程 概論 127/151 Agile的典型方法 ? Extreme Programming (簡稱 XP) ? SCRUM ? Crystal Methodologies (簡稱 Crystal) ? Feature Driven Development(簡稱 FDD) ? Dynamic Systems Development Methodology(簡稱 DSDM) ? Adaptive Software Development(簡稱ASD) ? Pragmatic Programming等 軟件工程課程 概論 128/151 XP方法 ? 由 Kent Beck提出，是 Agile方法中最引人注目的一個 ? XP最初實踐于 1997年 Crysler公司的 C3項目 (Smalltalk開發(fā)） ? 適用于 10人以下項目組、開發(fā)地點集中的場合 ? 廣泛用于需求模糊和揮發(fā)性強的場合 ? IONA公司的 Obix技術(shù)支持小組在采用了 XP方法后，軟件生產(chǎn)率提高了 67% 軟件工程課程 概論 129/151 XP方法的 4個價值觀 ? 交流（ Communication） ? 實踐表明，項目失敗的重要原因之一是交流不暢，使得客戶的需求不能準確地傳遞給開發(fā)人員，造成開發(fā)人員不能充分理解需求；模型或設(shè)計的變動未能及時告知相關(guān)人員，造成系統(tǒng)的不一致和集成的困難 ? 所有項目相關(guān)人員之間充分的有效的交流是軟件開發(fā)成功所必不可少的 ? XP方法提倡面對面的交流，這是一種有效的也是效率最高的交流方式 軟件工程課程 概論 130/151 ? 簡單（ Simplicity） ? 指在確保得到客戶滿意的軟件的前提下，做最簡潔的工作（簡單的過程、模型、文檔、設(shè)計和實現(xiàn)） ? 在開發(fā)中不斷優(yōu)化設(shè)計，時刻保持代碼簡潔、無冗余 ? 體現(xiàn)了敏捷開發(fā)的 “ 剛剛好 (Just enough)”思想，即開發(fā)中的活動及制品既不要太多也不要太少，剛好即可 軟件工程課程 概論 131/151 ? 反饋（ Feedback） 及時有效的反饋能確定開發(fā)工作是否正確，及時發(fā)現(xiàn)開發(fā)工作的偏差并加以糾正。 強調(diào)各種形式的反饋，如非正式的評審（走查， Walkthrough）、小發(fā)布等 軟件工程課程 概論 132/151 ? 勇氣（ Courage） 采用敏捷軟件開發(fā)需要勇氣 ： ?信任合作的同事，也相信自己 ?做能做到的最簡單的事 ?只有在絕對需要的時候才創(chuàng)建文檔 ?讓業(yè)務(wù)人員制定業(yè)務(wù)決策，技術(shù)人員制定技術(shù)決策 ?用可能的最簡單的工具，例如白板和紙，只有在復(fù)雜建模工具能提供可能的最好價值時才去使用它們 ?相信程序員能制定設(shè)計決策，不需要給他們提供過多的細節(jié) ?需要勇氣來承認自己是會犯錯誤的，需要勇氣來相信自己明天能克服明天出現(xiàn)的問題。 軟件工程課程 概論 133/151 XP方法的 12個核心實踐 （ Whole Team） ? 所有的小組成員應(yīng)在同一個工作地點工作 ? 成員中必須有一個現(xiàn)場用戶（ Onsite User）由他提出需求，確定開發(fā)優(yōu)先級 ? 通常還設(shè)一個 “ 教練 ” （ Coach）角色 教練指導(dǎo) XP方法的實施，以及與外部的溝通和協(xié)調(diào) （ Planning Game） 包括兩類：發(fā)布計劃和迭代（ Iteration）計劃 軟件工程課程 概論 134/151 3. 系統(tǒng)比喻 （ Metaphor） 系統(tǒng)比喻是待開發(fā)軟件的一個每個成員都熟悉的形象化比喻，相當于一個粗略的軟件體系結(jié)構(gòu) 4. 小發(fā)布（ Small release） 經(jīng)常、不斷地發(fā)布可運行的、具有商業(yè)價值的小軟件版本，供現(xiàn)場用戶評估或最終使用 5. 測試（ testing） XP方法提倡測試優(yōu)先，即先寫測試后編代碼（ testing then coding） 6. 簡單設(shè)計（ Simple Design） ? 設(shè)計只考慮當前定義的功能而不考慮以后需求的變化 ? 該設(shè)計是完成目前功能所需的最簡潔的設(shè)計 軟件工程課程 概論 135/151 7. 結(jié)對編程（ Pair Programming） 一個程序員編程的同時，另一個程序員負責檢查程序的正確性和可讀性 結(jié)對的伙伴 可以動態(tài)調(diào)整 8. 設(shè)計改進（ Design Improvement） 在不影響程序的外部可見行為的情況下，按高內(nèi)聚低耦合的原則對程序結(jié)構(gòu)進行改進，保持代碼簡潔、無冗余 9. 持續(xù)集成（ Continuous Integration） 每完成一個模塊的開發(fā)（包括該模塊的單元測試）后，立即將其組裝到系統(tǒng)中，并進行集成測試，完成該集成測試后才能進行下一次集成 軟件工程課程