軟件過程模型軟件工程內容何為軟件過程模型基本概念和特點有哪些軟件過程模型有什么類別，各有什么優缺點3.如何來選擇軟件過程模型軟件過程模型的選擇方式和策略1.1軟件開發的特點基于智力的協作過程智力活動：基于邏輯思維來構造軟件交流協作：多方參與、相互間的交流和討論軟件項目實施復雜性介入的人多、涉及的內容多、產生的制品多不同要素間存在關聯循序漸進的開發過程開展有序的開發活動，如編碼、分析、設計體現了工程的思想：按步驟、分階段、循序漸進按照什么樣的過程和步驟來有序地開發軟件？1.2軟件過程過程(Process)活動：明確要做哪些事情，包括具體的活動關系：活動間存在邏輯關系，如依賴和先后次序示例：考研的過程軟件過程(SoftwareProcess)按照項目進度、成本和質量要求，遵循用戶需求，開發和維護軟件、管理軟件項目的一系列有序軟件開發活動軟件開發活動：技術活動和管理活動1.3軟件過程模型軟件過程模型(SoftwareProcessModel)定義了軟件開發的具體活動以及活動間的邏輯關系開發活動1開發活動2開發活動3開發活動n任務、目標、輸入和輸出投入人員、工具、資源和成本等軟件制品思考和討論：軟件開發應該按照什么樣的過程？先做什么，然后再做什么，最后做什么為什么要按照這樣的過程？內容何為軟件過程模型基本概念和特點有哪些軟件過程模型有什么類別，各有什么特點和優缺點如何來選擇軟件過程模型軟件過程模型的選擇方式和策略2.1軟件過程模型的產生背景作坊式的個人創作聚焦于編寫代碼關注時空利用，精雕細琢程序規模小且功能單一依靠個體技能，缺乏合作無系統性方法和標準流程軟件工程產生之前的軟件開發軟件過程模型的產生背景IBMOS/360超大型軟件項目(1963年-1965年)通用系統，支持多道程序，最多可同時運行15道程序軟件工程師超2000人，花費超5億美元，工作量超5000人年有史以來最可怕的軟件開發泥潭Brooks，《人月神話》TheMythicalMan-Month作者、圖靈獎獲得者凸顯了軟件過程及其管理的重要性典型的軟件過程模型瀑布模型增量模型迭代模型原型模型螺旋模型基于構件的過程模型UP模型需要系統、規范性的軟件過程模型的指導每種軟件過程模型有其各自的特點和適用場所2.2瀑布模型(WaterfallModel)需求分析概要設計詳細設計編碼實現集成測試確認測試特點與軟件生命周期相互一致每個活動結束后需要評審相鄰活動間存在因果關系優點簡單，一目了然，易理解、掌握、應用和管理適合于需求易于定義、不易變動的軟件系統1970提出的第一個軟件過程模型需求分析(RequirementAnalysis)活動任務：定義軟件需求，包括功能、非功能需求關注點：要做什么？(What,Problem)層次和視角：用戶角度，僅描述問題和需求方法依據：用戶的期望和要求不斷與用戶進行交流和商討，抽象、問題分解、多視點等技術產出軟件需求模型、軟件需求文檔、軟件確認測試計劃產生文檔類的軟件制品明確問題是什么？概要設計(ArchitectureDesign)活動任務：建立軟件總體架構、制定集成測試計劃關注點：軟件高層設計？(How,Solution)層次和視角：宏觀、全局、整體、戰略性方法依據：軟件需求文檔自頂向下,逐步求精,抽象,模塊化,局部化，信息隱藏…...產出軟件概要設計模型、軟件概要設計文檔、軟件集成測試計劃產生文檔類的軟件制品明確問題如何解決？詳細設計(DetailedDesign)活動任務：設計模塊內部細節(算法、數據結構)，制訂單元測試計劃關注點：詳細設計？(How，Solution)層次和視角：微觀、局部、細節性方法依據：概要設計文檔、軟件需求文檔高質量的軟件設計原則，如單入口單出口產出軟件詳細設計模型、軟件詳細設計文檔、單元測試計劃產生文檔類的軟件制品明確問題如何解決？編程實現(Implementation)活動任務：編寫程序代碼并進行單元測試和調試關注點：如何最終做出這個東西?(How，Code)層次和視角：最終的實現代碼方法依據：軟件概要和詳細設計文檔、單元測試計劃采用某種程序設計語言(如C、C++、Java)產出經過單元測試的源程序代碼產生程序類的軟件制品明確如何實際解決問題集成測試(IntegrationTest)活動任務：組裝軟件模塊并進行測試以發現問題關注點：集成后軟件中的缺陷（Bug）層次和視角：自底向上組裝、全局

方法依據：軟件概要設計文檔、軟件集成測試計劃軟件集成測試工具產出經過集成測試、修復缺陷的源程序代碼，集成測試報告產生數據、文檔和代碼類的軟件制品明確問題解決如何？軟件有缺陷嗎？確認測試(ValidationTest)活動任務：測試軟件是否滿足用戶需求關注點：軟件在滿足用戶需求方面是否存在缺陷層次和視角：從用戶角度，聚焦需求是否得以正確實現方法依據：軟件確認測試計劃、軟件需求文檔軟件測試支撐工具產出經過確認測試、修復缺陷后的代碼，軟件確認測試報告產生數據、文檔和代碼類的軟件制品明確問題解決如何？軟件有缺陷嗎？思考和討論：瀑布模型的局限性？需求分析概要設計詳細設計編碼實現集成測試確認測試優點是什么有何不足需求確定，過于理想化缺乏變通，難應對變化軟件需求具有易變、多變的特點怎么辦？2.3改進的瀑布模型：帶反饋和回溯需求分析概要設計詳細設計編碼實現集成測試確認測試回溯后期活動發現有問題后，可返回到前面活動加以解決提高了過程模型的靈活性不足軟件開發處于動蕩之中需等到所有功能實現后，才能得到可運行軟件2.4增量模型(IncrementalModel)需求分析概要設計詳細設計編碼實現集成測試確認測試詳細設計編碼實現集成測試增量1增量n漸進式、增量式地實現軟件功能優點：漸進快速交付，并行開發，提高效率增量模型的局限性？結合課程綜合實踐思考不足軟件需求可確定且不易于變化增量1增量n2.5迭代模型(IterativeModel)需求分析概要設計詳細設計編碼實現軟件測試迭代1需求分析概要設計詳細設計編碼實現軟件測試迭代2迭代n每次迭代完成部分可確定的軟件需求迭代模型的特點每次迭代是一完整過程體現了小步快跑的開發理念適合需求難導出、不易確定且持續變動的軟件迭代模型的局限性？結合課程綜合實踐思考不足迭代多少次不確定管理較為復雜思考和討論：增量模型與迭代模型二者有何共性和區別？增量模型迭代模型增量1增量n軟件需求獲取是關鍵和瓶頸問題軟件需求非常關鍵軟件開發的基礎、驗收的依據用戶講不清楚軟件需求有哪些、是什么？說不清、道不明，尤其當軟件較為復雜和龐大之時用戶與軟件工程師對軟件需求理解存在偏差對軟件需求描述的歧義性、二義性、不準確等造成的“應該是這樣的”、“實際是這樣的”如果軟件需求分析結果不正確、不完整、有歧義，會帶來什么樣的問題？軟件需求的偏差需求偏差有多大如何來解決軟件需求偏差問題？2.6原型模型(PrototypeModel)特點軟件原型作為交流載體和媒介支持用戶參與到軟件開發中持續、漸進地導出用戶要求適合于需求難導出、不易確定且持續變動的軟件快速設計采集和細化需求建造原型客戶使用評價原型獲得反饋開發軟件系統何為軟件原型？用戶界面執行流程2.7螺旋模型(SpiralModel)集成迭代模型和原型模型引入風險分析，風險驅動的過程模型每個迭代四個階段，若干活動適合于需求不明確、開發風險高、開發過程中需求變更大的軟件項目不足：管理復雜軟件風險使軟件開發受到影響和損失、甚至導致失敗的、可能會發生的事件不同軟件過程模型的特點模型名稱指導思想關注點適合軟件管理難度瀑布模型提供系統性指導與軟件生命周期相一致需求變動不大、較為明確、可預先定義的應用易原型模型以原型為媒介指導用戶的需求導出和評價需求獲取、導出和確認理解需求難以表述清楚、不易導出和獲取的應用易增量模型快速交付和并行開發軟件詳細設計、編碼和測試的增量式完成需求變動不大、較為明確、可預先定義的應用易迭代模型多次迭代，每次僅針對部分明確軟件需求分多次迭代來開發軟件，每次僅關注部分需求需求變動大、難以一次性說清楚的應用中等螺旋模型集成迭代模型和原型模型，引入風險分析軟件計劃制定和實施，軟件風險管理，基于原型的迭代式開發開發風險大，需求難以確定的應用難內容何為軟件過程模型基本概念和特點有哪些軟件過程模型有什么類別，各有什么特點和優缺點3.如何來選擇軟件過程模型軟件過程模型的選擇方式和策略如何為軟件項目開發選擇合適的軟件過程模型軟件項目及開發團隊的具體特點軟件過程模型特點、優點和局限分析和對比3.1軟件過程模型的選擇考慮軟件項目的特點尤其是所開發軟件的業務特點，如業務領域是否明確、軟件需求是否易于確定、用戶需求是否會經常性變化等等是否可以預估到潛在的軟件開發風險考慮開發團隊的水平需要結合軟件開發團隊的能力和水平來選擇過程模型，以防開發團隊和管理人員無法掌控和駕馭過程模型結合軟件過程模型特點優缺點以及適合的場所示例：如何選擇合適的過程互聯網應用軟件的開發過程模型特點：軟件需求不確定且快速變化如：12306APP軟件，微信軟件，淘寶軟件選用瀑布模型不合適，迭代模型較為合適裝備軟件的開發過程模型特點：軟件需求確定且較為穩定，質量要求高如：飛行控制軟件可考慮選用瀑布模型，用迭代模型不是很合適思考和討論結合課程綜合實踐的具體特點和要求，思考選用什么樣的軟件過程模型較為合適，為什么？軟件有創意：問題及基于軟件的解決方法有新意軟件上規模：軟件具有一定規模，代碼量>15000+LOC如空巢老人看護軟件、多無人機聯合搜尋軟件課程實踐軟件項目有何特點？軟件項目開發團隊有何特點？3.2傳統軟件過程模型的特點和不足軟件開發和運維的大量工作用于撰寫軟件文檔，而非去編寫程序代碼軟件開發過程中會花費大量時間和精力用于軟件文檔的評審，以確保軟件質量一旦軟件需求發生變化，開發人員需要修改軟件需求文檔，并據此來調整其他的一系列文檔，最后再修改程序代碼等較長時間才能得到可運行軟件系統以文檔為中心的重型軟件開發方法，非常笨重瀑布模型增量模型迭代模型原型模型螺旋模型……軟件文檔敏捷軟件開發方法(AgileMethod)的產生重視人和交互、重視可運行軟件系統、重視客戶合作、重視響應用戶需求變化少寫軟件文檔，以代碼為中心，快速響應變化拓展閱讀軟件科學與工程-學科發展戰略，梅宏等著，高等教育出版社，2021.課后作業和課程實訓訪問/paths/1944完成第四章“軟件過程模型和開發方法”的實訓闖關任務本章知識圖譜小結軟件開發需要過程指導明確步驟、活動、次序、關系多樣化的軟件過程模型瀑布、增量、迭代、原型、螺旋等，各自有其優缺點選擇合適軟件過程模型考慮軟件項目特點和要求、團隊的經驗和水平及各個軟件過程模型的優缺點傳統軟件過程模型不足以文檔是中心，非常笨重，難以快速應對需求變化，怎么辦？布置課程綜合實踐任務綜合實踐1：閱讀、分析和維護開源軟件結合代碼閱讀以及sonarqube工具掃描，分析小米便簽開源軟件的質量，撰寫質量分析報告要求：分析代碼質量（從軟件設計到代碼規范）好的一面；存在的不足和問題，在具體開發中應用高質量的軟件開發規范和實踐綜合實踐2：開發有創意、上規模和高質量的軟件結合要求構思軟件需求，撰寫軟件需求構思和描述文檔要求：有創意，上規模；力爭將軟件需求講清楚：what&why思考題迭代模型能夠有效的支持課程實踐軟件項目的開發和管理工作？為什么？敏捷軟件開發方法軟件工程內容何為敏捷開發方法基本思想和原則特點和應用具體敏捷開發方法極限編程測試驅動開發方法Scrum方法DevOps方法1.1傳統重型軟件開發方法的特點和不足遵循嚴格的過程和計劃定義廣泛適用的過程并通過團隊來執行該過程，從而指導軟件開發以預測性為主，傾向于預先制定詳細的計劃，并通過該計劃來指導軟件項目的實施，并期望軟件開發過程與計劃之間的偏差越少越好以文檔為中心通過文檔記錄各個階段的成果，將文檔作為交互的媒介需對文檔進行持續改進和評審難以有效應對軟件需求的變化等到開發后期才能得到可運行軟件編碼是開發的后期工作1.2什么是敏捷方法（AgileMethod）？一種輕量級軟件開發方法相對于重量級的軟件開發方法而言主張軟件開發要以代碼為中心，快速、輕巧和主動應對需求變化，持續、及時交付可運行的軟件系統輕便、輕巧提供了一組思想和策略，指導快速響應用戶需求的變化，快速交付可運行的軟件制品1.3敏捷開發方法的基本價值觀較之于過程和工具，應更加重視人和交互的價值較之于面面俱到文檔，應更加重視可運行軟件系統的價值較之于合同談判，應更加重視客戶合作的價值較之于遵循計劃，應更加重視響應用戶需求變化的價值要以快速滿足用戶需求為目標，以此來改變軟件開發的理念、思想和方法敏捷方法的指導思想強化可運行的軟件，弱化軟件文檔以可運行軟件為中心來開展軟件開發以適應變化為目的，提升應變能力針對變化不斷進行優化和調整任務、產品和計劃等以人為本，讓方法等服務于人敏捷軟件開發是面向人的而不是面向過程的，讓方法、技術、工具、過程等來適應人，而不是讓人來適應它們敏捷意味著：輕盈、靈巧；無過多的負擔；迅速響應變化1.4敏捷準則基于四項價值觀，人們進一步提出12條敏捷開發原則以指導開發人員運用敏捷開發方法來開發軟件實踐這些原則使得敏捷方法更具可操作性敏捷價值觀敏捷開發原則軟件開發實踐產生指導敏捷準則(1/2)盡早和持續地交付有價值的軟件，以使用戶滿意即使到了軟件開發后期，也歡迎用戶需求的變化不斷交付可運行軟件系統，交付周期可以從幾周到幾個月在整個軟件項目開發期間，用戶和開發人員最好能每天一起工作由積極主動的人來承擔項目開發，給他們提供所需環境和支持，信任他們的能力團隊內部最有效的信息傳遞方式是面對面的交談敏捷準則(2/2)將可運行軟件作為衡量軟件開發進度的首要標準可持續性的開發，出資方、開發方和用戶方應當保持長期、恒定的開發速度關注優秀的技能和良好的設計會增強敏捷性采用簡單化的方法來完成任務最好的架構、需求和設計出自于自組織的團隊軟件開發團隊應定期就如何提高工作效率的問題進行反思，并進行相應的調整敏捷軟件開發對技術提出的要求如何快速開發出可運行的軟件系統?當需求改變時，如何快速應對變化?如何給出可有效應對變化的軟件設計？在文檔缺乏情況下如何保證軟件質量?如何提高軟件開發的效率?1.5支持敏捷軟件開發的技術極限編程(eXtremeProgramming,XP)測試驅動開發（TestDrivenDevelopment,TDD）Scrum方法DevOps方法適應性軟件開發（AdaptiveSoftwareDevelopment，ASD）特征驅動開發（FeatureDrivenDevelopment,FDD）敏捷設計動態系統開發方法（DynamicSystemDevelopmentMethod,DSDM）敏捷開發方法是一大類方法統稱，它們均遵循敏捷思想內容何為敏捷開發方法基本思想和原則特點和應用具體敏捷開發方法極限編程測試驅動開發方法Scrum方法DevOps方法2.1極限編程的基本思想由KentBeck提出的一種特殊的敏捷軟件開發方法四條核心思想交流，強調基于口頭（而非文檔、報表和計劃）的交流反饋，通過持續、明確反饋來獲得軟件狀態簡單，用最簡單的技術來解決問題勇氣，快速開發并在必要時具有重新進行開發的信心將經過數十年檢驗的準則結合在一起，定義了五條指導性原則和十二條須遵循的核心準則極限編程的5條指導原則快速反饋從用戶處迅速得到有關軟件的反饋，確認開發是否滿足用戶需求，通過自動化測試迅速了解軟件運行狀況簡單性假設開發人員只考慮當前迭代所面臨問題，無需考慮下一次迭代的問題，用簡單方法和技術來解決問題。逐步更改通過一系列修改來逐步解決問題和完善系統，不要期望一次迭代就開發出完整的軟件系統。支持變化歡迎用戶改變需求，支持用戶需求動態變化。高量的工作采用諸如測試驅動開發等技術高質量地開展工作，確保軟件質量。極限編程的12條核心準則(1/3)計劃游戲軟件開發團隊快速制定下一次迭代的軟件開發計劃隱喻(Metaphor)使用業務相關術語來描述需求，促使開發人員和業務人員對系統達成共同和一致的理解小型發布經常性發布可運行軟件系統，每次發布的軟件系統僅提供少量功能簡單設計只為當前的需求做設計，程序能運行所有測試、沒有重復邏輯、包含盡可能少的類和方法極限編程的12條核心準則(2/3)測試測試應在編寫代碼之前進行重構在不改變程序代碼功能的前提下，改進程序代碼的設計，使程序代碼更加簡單，更易于擴展結對編程兩名程序員同時在一臺計算機上共同開展編程工作代碼集體擁有開發小組的任何成員都可以查看并修改任何部分的代碼極限編程的12條核心準則(3/3)持續集成經常性地進行集成每周工作40小時倡導質量優先現場用戶用戶代表在現場辦公，參與開發全過程，確保能及時得到反饋編碼標準遵循統一編碼標準，以提高軟件系統的可理解性和可維護性2.2傳統軟件開發的局限程序員先編寫程序代碼，然后再對程序代碼進行測試基于已有的程序代碼進行測試局限性測試常被視為是附加工作，由于進度壓力，常被忽視，導致沒有足夠時間對代碼進行詳盡和充分的測試當文檔與程序代碼不一致時，對程序代碼進行測試就會存在許多問題測試通常是在程序代碼編寫完成之后才進行的，因而無法保證編寫程序和測試同步測試被視為是乏味的工作，人員缺乏積極性和成就感測試驅動開發的思想在編寫業務代碼之前，先確定和編寫測試程序員首先要思考如何對某個功能進行測試，設計好相應的測試用例，編寫好相關的測試代碼，然后編寫相應的程序代碼以通過軟件測試測試驅動開發的過程選擇功能增加測試編寫測試編譯測試重構代碼運行測試運行測試修改代碼修改代碼修改代碼測試驅動開發的特點根據測試來編寫代碼編寫測試的目的不僅是為了測試程序代碼能夠正常工作，而且被用于定義程序代碼的內涵確保任何程序代碼都是可測試的編碼完成后即完工易于維護、質量保證2.3Scrum方法旨在通過增量或迭代的方式加強軟件項目的管理以及快速提交可運行的軟件產品BackLogSprintLog軟件產品產品訂單庫沖刺訂單庫沖刺開發交付的軟件產品1-4周左右的沖刺Scrum方法的大致流程首先，產品擁有者需創建軟件產品訂單庫即“Backblog”描述軟件產品需提供的功能需求以及它們的優先級排序其次，篩選出最應該實現的軟件需求，Scrum主人基于“Backblog”中各項軟件需求及其優先級，形成待實現的軟件產品沖刺訂單庫，即“SprintLog”然后，軟件開發將進入沖刺“Sprint”周期以實現選定軟件訂單，每個沖刺就是一次增量開發，一般持續1到4周最后，共同開展Scrum評審一次沖刺完成后，每個團隊成員演示自己的開發成果，大家共同審查成果是否高質量地實現了既定功能，并就其中的問題進行反思，以指導和改進下一次沖刺2.4DevOps方法的基本思想傳統方法將軟件開發和運維的分離開來DevOps是由“Development”和“Operations”二個英文單詞的縮寫連接而成反映了要將軟件開發和軟件運維二個階段的工作統一和集成在一起加以考慮，實現二者之間的無縫連接DevOps方法將敏捷的理念和思想從軟件開發階段延伸到軟件運維階段DevOps方法實際上是一種特殊的敏捷開發方法DevOps方法與其他方法的對比持續集成、持續交付和持續部署(1/2)持續集成（ContinuousIntegration，CI）軟件開發團隊成員經常性地集成他們的工作成果（如程序代碼），把團隊個人研發的部分代碼向團隊軟件整體部分交付持續交付（ContinuousDelivery，CD）在持續集成的基礎上，通過自動化測試，將集成后的代碼部署到更貼近真實運行的環境之中，從而為持續部署奠定基礎持續部署（ContinuousDeployment，CD）當交付的代碼通過評審之后，自動部署到軟件系統的實際和真實運行環境中持續集成、持續交付和持續部署(2/2)DevOps的工具支持為了實現持續集成、持續交付和持續部署，DevOps方法需要借助于一系列的工具常見的持續集成CASE工具包括Jenkins、GitLabCI、TravisCI、CircleCI、Maven等,它們可以與GitLab、GitHub、Bitbucket等版本控制系統集成使用常見的持續交付和持續部署工具包括Ansible、Puppet、Chef等，它們可以自動化部署和管理基礎設施以及應用程序使用監控工具（如Nagios、Zabbix、Prometheus等）對部署的應用程序進行監控和故障排查，對系統資源、應用程序性能、日志等方面進行監控，并提供報警、自愈等功能。2.5敏捷方法的特點小和少生成少量軟件文檔，每個文檔規模要小每次迭代要實現軟件功能的數量和規模要小，迭代周期要小簡技術、工具以及每次迭代要解決的問題盡可能簡單只關注當前欲實現的功能需求，而不要考慮將來的問題快快速響應變化、從用戶處獲得反饋，給用戶提交有價值軟件，對軟件產品進行迭代和更新變允許需求動態變化，要以變應變，開發團隊應是自組織的重型方法與敏捷方法對比方法名稱重型開發方法敏捷開發方法基本理念以文檔為中心以代碼為中心交付特點交付慢、開發持續時間長、難以快速應對需求變化交付快、開發持續時間短、可快速應對需求的變化適合項目對軟件文檔和過程要求高、軟件需求演變不快的軟件系統，如要求遵循CMM規范的軍用軟件系統開發需求經常變化的軟件，如互聯網軟件典型代表瀑布模型、增量模型、迭代模型、原型模型、螺旋模型等測試驅動開發、Scrum、DevOps方法等示例：12306軟件開發采用敏捷方法Mini-12306軟件的邊界不確定，需求動態變化，客戶要求開發方盡早和持續交付軟件系統針對該項目軟件需求特點及交付要求，項目組可考慮采用迭代、敏捷的方法來開展該軟件系統的開發每次迭代或每個Scrum周期針對若干明確的軟件需求項開展開發工作，每隔一段時間給客戶交付可運行軟件系統思考和討論敏捷開發方法與瀑布過程模型等的本質區別是什么？敏捷開發方法適合于哪些類別的軟件開發？DevOps方法如何體現敏捷開發的思想？拓展閱讀敏捷軟件開發，[美]

羅伯特·C.馬丁（Robert，C.，Martin）,清華大學出版社，2020.DevOps實踐指南（第2版）,人民郵電出版社，2024.課后作業和課程實訓訪問/paths/1944完成第四章“軟件過程模型和開發方法”的實訓闖關任務本章知識圖譜小結敏捷開發方法的本質應對軟件需求變化，解決傳統過程模型的不足敏捷開發方法的特點小、簡、快、變、體，輕量級方法，以代碼為中心的方法敏捷開發方法的構成由許多具體的方法組成，如Scrum方法、極限編程等問題和討論群體化軟件開發方法軟件工程內容開源軟件的開發要求特點和開發要求何為群體化軟件開發方法基本理念和思想如何實現群體化軟件開發關鍵軟件工程技術1.1閉源軟件何為閉源軟件軟件代碼不對用戶開放的一類軟件，購買軟件時只提供可運行軟件或服務，沒有提供源代碼以使用許可證（License）的方式授權用戶使用軟件閉源軟件的特點無法獲得源代碼（無渠道）無權使用源代碼（合法性）閉源軟件帶來的問題無法掌握軟件內部實現情況（如是否存在惡意代碼），難可信；無法修改和完善軟件，影響了開發者的創新自由閉源軟件只提供可執行代碼，不提供源代碼閉源軟件及企業示例典型軟件Windows、Office軟件、Oracle軟件等典型企業微軟、IBM、Oracle等1.2開源軟件(OpenSourceSoftware)何為開源軟件一種源代碼可以自由獲取和傳播的計算機軟件，其擁有者通過開源許可證賦予被許可人對軟件進行使用、修改和傳播開源軟件的特點源程序代碼對外開放自由使用、修改和傳播任何人都可獲得開源軟件的代碼開源軟件對源代碼開放，并允許你修改和傳播示例：開源軟件操作系統Linux、Ubuntu、麒麟、鴻蒙、OpenEuler等數據庫系統MySQL、PostgreSQL、MongoDB、Redis等開發平臺Eclipse、Junit、SonarQube、Kubernetes等人工智能Tensorflow、Opencv、Caffe、Deeplearning4j等網絡安全Nmap、curityOnion、Suricata、Bro等……你需要的軟件都可以找到相應的開源軟件示例：Gitee上的OpenHarmony開源軟件開源鴻蒙軟件1.3開源軟件的開發要求吸引大眾參與和貢獻任何人可參與開源開發在互聯網上進行開發實現隨時隨地參與開發代碼可實現充分共享代碼可以被任何人獲取思考和討論你知道有哪些開源軟件？免費使用軟件等同于開源軟件嗎？微信、12306等軟件是開源軟件嗎？開源軟件是如何開發出來的？內容開源軟件的開發要求特點和軟件開發要求何為群體化軟件開發基本理念和思想如何實現群體化軟件開發關鍵軟件工程技術2.1軟件開發是創作和生產的過程軟件創作發揮軟件工程師的智慧，結合創作者的愛好和興趣，開展軟件創作如構思需求、開展設計、精雕代碼等軟件生產任務分工，集中管理計劃驅動，有序開發評審測試，保證質量交流溝通，促進合作創作生產基于團隊的軟件開發方法及其組織模式軟件制品特定組織（如微軟、IBM、華為）的人員所組成軟件項目團隊組織內軟件開發者參與開發邊界封閉組織外軟件開發者無法加入團隊不能獲得軟件制品對外不可共享的軟件倉庫基于團隊軟件開發方法的特點開發團隊邊界封閉域外人員無法參與人員以及資源有限項目的成果不共享集中化的管理模式關注生產而非創作軟件制品無法充分利用團隊之外的力量，阻礙大眾參與軟件創作和生產示例：Windows軟件開發團隊組成Windows7軟件項目的團隊組織核心開發團隊大約有1000人25個功能小組，每個小組大約有40個人每個小組包括三類人員：程序經理，開發工程師，測試工程師全部是Microsoft員工Windows7源代碼是微軟商業機密，不對外共享和開放微軟之外的其他組織無法獲得產品的任何信息和資源示例：IBMOS/360軟件開發團隊1960s初IBMOS/360大型軟件項目通用系統，支持多道程序，最多可同時運行15道程序軟件工程師超2000人，工作量超5000人年IBM之外的其他組織無法獲得產品的任何信息和資源2.2開源軟件項目的開發和組織模式開放項目邊界大眾參與開發程序代碼共享軟件倉庫互聯網用戶互聯網用戶由少數核心開發人員和大量互聯網大眾（外圍）所組成的群體化開發開放的項目邊界可共享的代碼倉庫互聯網大眾能做什么樣的貢獻？構思軟件需求，增強軟件功能-創作發現軟件問題，指出軟件缺陷-創作編寫程序代碼，提交開發成果-創作+生產參與代碼評審，評價貢獻質量-生產……創作生產將軟件創作和生產融合在一起，充分發揮大眾的智慧和力量高手在民間，高手在互聯網上示例：OpenHarmony中的群體化貢獻提出問題和需求貢獻和提交代碼開源鴻蒙充分利用群體的智慧來推動軟件的創作和生產2.3何為群體化開發方法依托互聯網平臺來吸引、匯聚、組織和管理互聯網上的大規模軟件開發人員，通過競爭、合作、協商等多種自主協同方式，讓他們參與軟件開發、分享軟件開發知識和成果、貢獻智慧和力量的一種新穎軟件開發方法軟件倉庫互聯網用戶互聯網用戶思考和討論沒有互聯網平臺能開展群體化軟件開發嗎？為什么？軟件倉庫互聯網用戶互聯網用戶基于互聯網的群體化開發平臺Github（國際）和Gitee（國內）群體化開發平臺提供的開發支持提出需求創意、發現軟件缺陷、提交程序代碼、標注開發任務、討論軟件需求、評審代碼質量等等2.4群體化軟件開發方法的特點軟件開發邊界開放互聯網大眾自由參與利用海量的大眾資源共享源程序代碼兼顧軟件創作和生產依托互聯網平臺群體化軟件開發是一種基于社區的軟件開發模式開發社區而非團隊：社區和團隊的區別大教堂與集市大教堂（基于團隊的閉源軟件開發）傳統大型軟件公司的開發模式就像艱難緩慢的大教堂建造工程，嚴密的組織和集中式結構特點是封閉式建設、成本高、周期長、品質優集市（基于群體的開源軟件開發）

特點是開放式建設、成本低、周期短、品質平庸并行、對等的扁平化開發，參與者大多來自于互聯網上的志愿者，結構松散、來去自由集市大教堂閉源軟件開發和開源軟件開發閉源軟件采用大教堂的開發方式開源軟件

采用集市的開發方式雷蒙德（Raymond,E.S.）著,衛劍釩譯.大教堂與集市,機械工業出版社[M],2014軟件工程經典著作思考和討論基于團隊的軟件開發方法vs基于社區的群體化軟件開發方法基于團隊軟件開發方法基于社區群體化開發方法項目組織方式(團隊/社區)開發成員組成(封閉/開放)程序代碼開放依托平臺協同關注創作和生產可用資源情況(有限/海量)內容開源軟件的開發要求特點和開發要求何為群體化軟件開發基本理念和思想如何實現群體化軟件開發關鍵軟件工程技術群體化軟件開發方法的支撐關鍵技術基于社區的群體化組織基于Issue的任務管理基于Git的分布式版本管理基于Pull/Request的分布式協同開發基于群智的知識分享3.1基于社區的群體化軟件項目組織核心開發人員外圍開發人員大眾化協同持續性評估軟件倉庫需求創意軟件缺陷程序代碼

貢獻和獲取貢獻和獲取群體化軟件開發采用社區和集市的組織模式核心開發人員開源軟件項目的主要貢獻者，主要職責開源軟件的核心貢獻人員（如提供了最初的開源代碼）分析和評估外圍開放大眾所發現的軟件缺陷和提出的軟件需求，將其轉化為生產性的軟件開發計劃評審和分析開放大眾所提交的程序代碼，并將通過評審的代碼融入到軟件倉庫之中人數不多幾個到幾十個不等開源鴻蒙有100多人外圍開發人員開源軟件項目的外圍貢獻者，主要職責借助于互聯網平臺獲得軟件項目信息，結合個人的興趣愛好、經驗和技能，自發地為軟件項目貢獻自己的力量提出需求建議、匯報代碼缺陷、提交程序代碼、評審代碼質量等數量會非常大成百上千，甚至有幾萬人開源鴻蒙有3萬多人依托開源社區來組織不同人員開源軟件社區將核心開發人員與外圍開發人員有機地結合在一起，依托軟件倉庫進行分布式協同開發軟件倉庫自由進出社區遵循社區規定自愿開展工作開放分享代碼開源軟件社區示例：依托社區自由獲取開源代碼克隆、下載開源代碼自由地克隆和下載代碼3.2傳統軟件開發的任務管理軟件項目團隊管理者團隊成員1團隊成員2團隊成員3團隊成員n開發任務的指派基于團隊組織模式和開發方法不適用于開源軟件開發集中管理任務分解強制執行基于Issue的任務管理開源軟件的開發任務不同于傳統的開發任務分解方式開發者群體自主提出，體現了群體創作思想每個任務對應于一個Issue開發任務的二類形式：修復軟件缺陷、功能實現需求基于Issue的軟件開發任務管理創建Issue，提出軟件開發任務討論Issue，分析開發任務的意義和價值指派Issue，安排人員來完成Issue掌控Issue，掌握Issue解決的進展狀況自主提出任務自發完成任務提出Issue清晰地描述任務標題內容特征提供必要的標簽以補充說明任務的性質和特征缺陷or需求程序語言任務標題任務描述任務特征示例：提出Issue任何人均可提出軟件開發任務：代碼缺陷和軟件需求“新建Issue”管理Issue辨別Issue的類別代碼缺陷，新增功能需求給Issue打標簽確認Issue的有效性缺陷是否客觀存在軟件需求是否有意義為Issue貼上適當標簽直觀地展示其特征信息Bug表示缺陷修復任務，duplicate表示這是一個重復任務依靠群體來管理Issue任務標簽示例：管理和討論Issue設置Issue優先級補充log截圖指派Issue何為指派Issue將Issue分配給相應人員加以解決要考慮的因素群體基于興趣和特長來認領相關任務結合開發者的開發技術和經驗考慮開發人員的能力和精力Issue指派并非強制性具有通知和推薦的性質接受到任務指派的人員有權決定是否接受該指派，可自愿參加或拒絕指派示例：指派Issue的負責人跟蹤Issue跟蹤和記錄Issue的解決過程，掌握Issue解決狀況事件的發起者發生的時間點事件的內容等重要的事件提出貼標簽指派負責人等思考和討論在開源軟件社區中，基于Issue的任務管理有何優點？它與集中式管理相比較有何差異性？Issue機制能否支持開源軟件的群體發開發？為什么？傳統軟件開發的集中式版本管理軟件版本庫多人同時需要該代碼時會存在什么樣的問題？訪問和存取訪問和存取開發者

3.3分布式版本管理思想本地工作區暫存區本地版本庫遠程(中心)版本庫開發者的本地計算機遠端計算機采用分級處理方式來區分軟件項目文件的不同狀態工作區、暫存區、本地版本庫建在開發人員自己的計算機之中，遠程版本庫建在遠程的中心服務器上本地工作完成后，可把本地版本庫數據（如代碼）同步推送到遠程版本庫中，也可從遠程版本庫拉取（Pull）最新代碼到本地版本庫創建開發分支分支相當于一條開發線路，是一串代碼提交歷史軟件開發者可利用分支實現不同開發任務的并行執行與變更合并Git版本庫中有二個常見的分支master分支：軟件項目主分支，負責存儲對外發布的項目版本，軟件開發者應該確保master分支的穩定性，一般不輕易直接修改master分支中的代碼，通常只有一個develop分支，軟件項目的開發分支，通常是各分支代碼的匯總分支，始終保持最新完成功能以及修復缺陷后的代碼開發者分支，軟件開發者自己的獨立分支分支軟件開發分支示意圖一個軟件有多個軟件開發分支代碼貢獻Master分支Dev分支Foo分支版本庫開發分支的合并（Merge）Dev分支Foo分支Dev分支Foo分支將多個開發者分支中的代碼修改合并到Dev分支里合并(Merge)Gve分支Gve分支基于Git的協同開發Git分支操作—多人協作（橫向視角）分支：使用分支意味著你可以把你的工作從開發主線上分離開來，以免影響開發主線masterbranch2branch1createmergecommitcreatemergecommit倉庫及分支操作示意圖本地倉庫遠程倉庫pushpullcommitcommitswitch合并請求分支管理工作創建“master”分支“master”分支倉庫處于穩定、可運行和可部署的狀態只有管理人員才有權限把“develop”分支代碼合并到“master”分支中創建“develop”分支屬于開發人員的分支倉庫，只有經過審查和測試的任務分支代碼才可合并到“develop”分支倉庫中只有管理人員才有權限把任務分支合并到“develop”分支上創建開發人員自己的任務分支每個開發人員可根據自身的開發任務創建自己的任務分支代碼合并（Merge）開發人員可通過項目管理人員，將自己編寫代碼同步合并到“develop”分支中思考和討論軟件開發人員編寫好代碼后，如何將自己編寫的代碼合并到原始倉庫中去？3.4基于Pull/Request（P/R）分布式協同開發每個開發人員在本地完成編程工作后，不是直接向中心倉庫推送代碼，而是通過發送一個P/R合并請求，將原始代碼庫的克隆庫推薦合并到中心倉庫之中一個“P/R”顧名思義是指一次合并請求，合并的內容對應于一個代碼修改補丁，它包含了軟件開發人員對軟件的一次代碼修改接收到合并請求后，軟件項目管理團隊和開發人員群體需要對P/R進行審查評估該P/R所貢獻代碼的質量，將符合質量要求的代碼集成到中心代碼庫合適的分支中基于P/R的分布式協同開發1.Fork（復刻）在線平臺和遠程倉庫2.Clone（克隆）3.Push（推送）4.Pull-request（代碼合并請求）復刻倉庫本地倉庫開源軟件原始倉庫李四Pull（拉取）本地機器李四分布式協同開發的操作（1/2）克隆（Clone）/派生（Fork）通過克隆或派生,將軟件項目的倉庫復制到自己的個人空間中，從而獲取軟件倉庫中的軟件代碼本地修改開發人員基于克隆后的軟件倉庫，在本地進行軟件開發活動，如修復缺陷、開發新的功能等，所產生的代碼變更將只影響其本地的克隆庫，而不會影響原始的軟件倉庫提交合并（P/R）開發人員可將變更的代碼以P/R的形式發送到原始的軟件倉庫，提供關于代碼合并的相關信息，包括合并的概要性標題、合并內容，說明該PR完成了哪些工作、代碼測試結果等情況分布式協同開發的操作（2/2）代碼質量保證平臺采用人工審查和自動測試相結合的方式，檢查P/R代碼質量開發人員可自發參與貢獻的審查過程，以評論方式發表意見一些軟件項目還會通過持續集成工具，自動編譯并測試所收到的P/R代碼，并向開發人員反饋測試結果PR的提出者接收到反饋后，可根據評論意見和測試結果，更新原始P/R中的相關代碼合并決策軟件項目核心開發團隊綜合評估上述所有因素，決定接受還是拒絕某項貢獻的合并請求。如果PR被接受，則開發人員所貢獻的代碼和提交的歷史都將被合并到項目的中心倉庫中基于P/R分布式協同開發技術的優勢簡單使用門檻低，開發人員可方便地貢獻代碼、評論他人貢獻，極大提高了開發人員參與軟件項目開發的積極性規范PR機制提供了規范化的協同開發流程，促進互聯網上大眾群體圍繞代碼貢獻的交流與合作，并與大眾評論、軟件測試、代碼審查等環節結合在一起，確保了軟件開發質量透明所有軟件開發歷史信息和社交活動信息都會保留下來，在開發人員主頁或軟件項目主頁中展現示例：mysql項目基于P/R的分布式開發協同開發者對P/R的評論P/R標題合并6次commit到Master分支中3.5基于群體的知識分享軟件開發實踐中遇到問題怎么辦？群體采用提問、回答、評論等多種方式進行在線知識分享基于群體的知識分享參與分享的對象是開放的互聯網大眾分享的內容表現為從問題到解答等多種知識樣式群智知識分享的分布式協同提問（Ask）在社區中進行提問，以獲得其他人員的討論和解答回答（Answer）和討論（Comment）對提問進行回答，或者對提問和回答進行評論必要時可以附上相關的細節，如問題解決的代碼片段接受（Accept）如果某個回答有效地解決了問題，那么提出者可以接受該回答搜索（Retrieve）檢索社區是否有相同或類似的問題，并找到相應的問題解答軟件開發知識分享的互聯網平臺Stackoverflow和CSDN示例：StackOverflow發布的問題信息問題標題問題信息問題描述及代碼示例：StackOverflow的問題回答問題回答問題回答描述回答相關信息接受該問題的回答海量的軟件開發知識SO用戶2400+萬，月訪問用戶量1億，用戶獲幫助450億SO問題2400+萬，3600萬回答，9100萬評論充分利用知識分享社區中的知識來解決課程學習和實踐中遇到的問題開源軟件托管平臺會受到封鎖2022年4月13日起，GitHub開始封鎖受美國制裁公司的俄羅斯企業及軟件開發者賬戶數十個賬戶被屏蔽，其中包括包括SberbankTechnology、SberbankAILab和AlfaBankLaboratory在內的GitHub企業帳戶個體開發商的賬戶建設我國安全可控的開源軟件托管平臺我國的開源軟件托管平臺Gitee拓展閱讀大教堂與集市，EricS.Raymond，機械工業出版社，2014.課后作業和課程實訓訪問/paths/1944完成第四章“軟件過程模型和開發方法”的實訓闖關任務本章知識圖譜小結開放和共享吸引互聯網大眾自主參與，匯聚大眾群體的貢獻和智慧自由分享程序代碼、知識問答等內容組織和管理采用基于社區的組織模式，借助去中心化的分布式協同開發模式借助互聯網平臺的支持，如Github、StackOverflow等多樣化目的既支持軟件開發，也支持軟件開發知識的分享將軟件創作和軟件生產融合在一起來支持軟件開發綜合實踐任務在Educode平臺上開展分布式協同開發創建項目版本庫、創建Issue、提交代碼、合并請求在知士薈上開展群體化學習：討論、分享和共享布置課程綜合實踐任務綜合實踐1：閱讀、分析和維護開源軟件構思小米便簽開源軟件的新需求，發現小米便簽開源代碼缺陷采用群體化開發方法來開展課程綜合實踐基于Issue機制來提出軟件開發任務，基于P/R機制來貢獻代碼綜合實踐2：開發有創意、上規模和高質量的軟件針對要求構思軟件需求，撰寫軟件需求構思和描述文檔要求：有創意，上規模；力爭將軟件需求講清楚：what&why下一節課進行課程實踐的匯報和講評思考題群體化軟件開發方法及其平臺能否用于指導閉源軟件的開發（如課程實踐2項目）？為什么？基于大模型的智能化軟件開發方法軟件工程內容大模型技術的特點問題解決方式變化代表了新質生產力大模型帶來的挑戰可信判斷帶來問題濫用和泛用大模型大模型帶來的機遇深化專業課程建設強化人才能力培養我們進入到大模型的時代(1/2)OpenAI基于GPT4.0的ChatGPT2023-3基于GPT4.0的Copilot2023-3微軟2023-4CognitionAIAI程序員Devin2023-4微軟AI程序員AutoDev2023-4OpenAIChatGPT4O我們進入到大模型的時代(2/2)百度文心一言2023-3華為盤古2023-6騰訊2023-9混元科大訊飛訊飛星火2023-5截至2024年3月，我國共有117個生成式AI的大模型完成了備案3602023-11奇虎-奇元大模型的應用技術通用領域智能軟件開發自然語言處理圖形圖像處理……推動技術研究和革新行業垂直領域教育軟件產業工業制造……推動行業領域變革大模型的應用前景非常廣泛，幾乎滲透到了各個行業和領域大模型代表了新質生產力生成式智能化問題解決–方法獨特性基于自然語言交互方式–交互友好性

適合廣泛的行業和領域–應用泛化性改變工作的方式和手段–影響深遠性示例：基于大模型的智能化軟件開發基于大模型的智能化軟件開發需求分析軟件設計編碼實現軟件測試測試設計需求代碼支持軟件開發的全生命周期生成軟件需求產生軟件設計方案生成程序代碼生成測試用例及方案大模型對軟件開發產生了系統性和深層次影響基于大模型的智能化軟件開發（1/5）智能化的需求獲取和分析包括自動化需求收集、理解及驗證等方面，利用自然語言處理技術從多種數據源收集并識別用戶需求應用文本分析技術理解并提取需求中的關鍵信息，檢測需求文檔中的缺失、模糊及不一致內容，并自動完善需求文檔示例：基于ChatGPT的軟件需求生成根據用戶的提示，生成軟件需求的描述創建與項目目標一致的需求描述，進而生成用戶使用場景的案例，并推薦軟件系統的產品功能開發者以此為基礎，將抽象、籠統的概念轉化為明確、詳實的軟件需求12306軟件的需求是什么？示例：基于ChatGPT的軟件需求生成進一步細化和完善需求提供軟件需求的細節生成需求的用戶故事基于大模型的智能化軟件開發（2/5）智能化軟件設計包括軟件架構生成與推薦、設計評估及優化等方面，基于需求分析結果，自動化生成軟件架構及設計文檔推薦符合需求的設計模式及架構風格建議評估不同設計方案成本及性能并進行優化，確保設計滿足需求規范示例：基于ChatGPT的軟件架構設計為開發團隊提供設計建議及架構模式幫助團隊快速地確定合適的架構方案提醒設計需要關注的問題如何進行12306軟件的設計？示例：基于ChaGPT的詳細設計根據提示給出使用SpringBoot進行實現的詳細設計為后續編碼實現奠定基礎基于大模型的智能化軟件開發（3/5）自動化代碼生成該方法是智能化軟件開發方法的核心，通過利用人工智能模型及自然語言處理技術，根據自然語言描述或其他規范自動生成軟件代碼，涵蓋從系統架構到代碼片段，從業務邏輯到測試驗證等不同粒度、階段的代碼生成智能化代碼推薦通過對開發者的編程習慣以及用戶當前上下文進行學習，從現有代碼庫中推薦開發者需要的代碼片段或模板，支持開發者高效復用已有高質量代碼輔助軟件開發過程示例：基于ChatGPT的代碼生成對TicketService接口中車票查詢功能提供類代碼用自然語言解釋說明代碼的實現邏輯12306軟件的代碼是什么？基于大模型的智能化軟件開發（4/5）軟件缺陷預測及自動修復使用機器學習算法分析歷史缺陷數據，預測軟件中潛在的缺陷位置以及對應的缺陷類型，通過搜索方法或生成式人工智能模型給出修復補丁，減少人工審查代碼和修復缺陷的開銷自動化代碼測試包括自動生成測試用例、自動化執行測試、測試結果分析等方面，包括單元測試、集成測試、系統測試等各個層面，輔助開發者高效編寫測試代碼并提前發現錯誤，保證軟件質量示例：基于ChatGPT的測試用例生成生成四個測試用例說明測試的目的、步驟和預期結果考慮對應場景下的邊界條件和異常情況提供測試代碼示例12306軟件測試用例是什么？基于大模型的智能化軟件開發（5/5）自動化文檔生成該方法通過基于大規模代碼和自然語言文本的學習，根據源代碼或其它軟件制品，自動化生成和維護文檔內容，包括需求文檔、設計文檔、API文檔等軟件開發過程文檔，以及代碼注釋、提交消息等內容，減少開發人員在維護軟件文檔過程中的精力智能化輔助決策基于軟件開發數據的支持項目管理者做出更加合理的項目管理決策，包括項目開發時間規劃、項目資源分配、項目風險評估等等大模型對于計算機專業影響的滲透性和泛化性計算機科學與技術軟件工程人工智能網絡工程信息安全物聯網工程數據科學與大數據技術…….統一、新穎的問題解決方法自動化開發：軟件工程長期努力的目標創造性思維的結果（需求+設計等）基于自然語言軟件生成的結果（程序代碼）程序設計語言軟件工程致力于將自然語言表述的創作結果最終由程序設計語言來表示e.g.,1970-軟件開發自動化，形式化的需求規約語言及其轉換和生成成本高、代價大，工程層面上實用性不強，未能得到廣泛的應用工具或人思維結果的中介表示（需求+設計等）規約語言+建模語言工具或人自動化智能化：大模型從軟件開發自動化到軟件開發智能化形式化描述(e.g.,邏輯、Z)形式化方法(e.g.,推理、證明)自動產生高質量代碼問題20世紀70-90年代的軟件開發形式化和自動化工作自然語言描述(e.g.,英語、漢語)生成式方法(e.g.,學習、訓練)生成高質量代碼問題2020年之后基于大模型的智能化開發工作基于大模型的結對軟件開發成為趨勢基于大模型的智能體計算機工程師人機協同開發Copilot等基于智能化的編程助手（如CopilotX），人機協同編程會成為趨勢越來越多程序員使用CopilotX等智能化工具進行軟件開發，AIPair編程正在成為新的編程范式，幫助程序員編代碼、單元測試、調試、寫文檔等結對編程會怎樣發展？以人為主AI為輔以AI為主人為輔AI軟件工程師隨著大模型技術及智能化工具的發展，結對編程的方式會發生變化大模型技術提供了強大的工具常用的CASE工具基于大模型技術的CASE工具什么都能干干得快，效率高干得好，質量好Copilot已參與到微軟全體云代碼倉庫中的46%，幫助開發人員將編程速度提高了55%使用Copilot的開發人員中有90%表示可以更快地完成任務，73%的開發人員能更好地保持順暢并節省精力，75%的開發人員感到更有成就感，大模型在計算機領域可能帶來的變化強者越強

–提升效率和質量，創新軟件產品善于利用大模型工具的人