軟件工程：理論、技術及實踐 課件 第3章 軟件過程

第3章軟件過程軟件生命周期模型1統一過程2敏捷開發(fā)3開源軟件4軟件過程的改進5軟件過程軟件過程是生產軟件的方式，不同的軟件組織有不同的軟件生產過程。例如：初創(chuàng)公司的資本和人力條件有限，因此為開發(fā)出能迅速響應市場需求的軟件產品，會更關注完成產品的核心功能并盡早發(fā)布，新功能的加入以及產品質量的提高往往放在軟件交付以后。長期開發(fā)行業(yè)應用軟件的公司對同類產品需求的把握更精準，對設計和實現軟件所需要花費的工作量和時間的估算更準確，從而能更“有秩序”地進行相關軟件生產，提交給用戶穩(wěn)定、可靠的軟件產品。

軟件生命周期模型：對構建軟件所應遵循的步驟的理論性描述。

軟件生命周期模型是跨越整個生存期的系統開發(fā)、運作和維護所實施的全部過程、活動和任務的結構框架。

瀑布模型快速原型模型

增量模型 螺旋模型

噴泉模型

可以用過程流來描述組織框架活動、動作和任務的次序，分為線性、迭代、演化和并行。軟件過程瀑布模型（waterfallmodel）是在1970年由WinstonRoyce提出的，其過程流是線性的。瀑布模型的關鍵是每個階段要完成指定的文檔并且該階段的產品被軟件質量保證小組認可之后，才能進入下一個階段。3.1軟件生命周期模型3.1.1瀑布模型圖3-1瀑布模型軟件生命周期模型3.1瀑布模型被稱為經典的軟件生命周期模型。在有明確需求并且需求保持穩(wěn)定的情況下，它是一個非常有效的過程模型。瀑布模型不適應軟件需求不明確或者在開發(fā)過程中需求經常變化的情況。軟件生命周期模型3.1.1瀑布模型3.1快速原型模型通過使用原型來輔助軟件開發(fā)。在需求分析階段要得到準確、合理的需求說明可能比較困難，用戶可能并不清楚自己需要的是什么樣的系統?？焖僭湍Ｐ瓦m合預先不能確切定義需求的軟件系統的開發(fā)。

軟件生命周期模型3.1.2快速原型模型3.1圖3-2快速原型模型

軟件產品的開發(fā)基本上是線性順序進行的。

軟件生命周期模型3.1快速原型模型最大的特點在于“快速”。對于采用何種形式、何種策略運用快速原型主要取決于軟件項目的特點、團隊成員素質、可供支持的原型開發(fā)工具和技術等，需要根據實際情況來做出決定。軟件生命周期模型3.1.2快速原型模型3.1如果軟件有明確需求，整個開發(fā)過程不要求按照線性過程流執(zhí)行，同時要求團隊迅速為用戶提供一套功能有限的軟件產品，并允許在后續(xù)版本中再進行細化和擴展，在這種情況下，可采用增量模型比較適用。

軟件生命周期模型3.1.3增量模型3.1圖3-3增量模型

軟件生命周期模型3.1增量模型的最大特點就是將待開發(fā)的軟件系統模塊化和組件化。增量式開發(fā)有利于從總體上降低軟件項目的技術風險。但增量模型對軟件設計有更高的技術要求：軟件體系結構具有良好的開放性與穩(wěn)定性，能夠順利地實現構件集成；同時增量構件應具有很強的功能獨立性，能夠方便地與系統集成。軟件生命周期模型3.1.3增量模型3.1為了讓軟件開發(fā)能更適應風險的控制，Barry

Boehm在1988年提出軟件系統開發(fā)的螺旋模型，將瀑布模型和快速原型模型結合起來，強調風險分析。螺旋模型以快速原型法為基礎，以進化的開發(fā)方式為中心，在每個項目階段使用瀑布模型法。它的基本做法是在每一個開發(fā)階段前引入風險識別、風險分析和風險控制。軟件生命周期模型3.1.4螺旋模型3.1圖3-4螺旋模型軟件生命周期模型3.1B.H.Sollers和J.M.Edwards在1990年提出的噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面向對象的軟件開發(fā)過程。軟件生命周期模型3.1.5噴泉模型3.1圖3-5噴泉模型1994年10月，JamesRumbaugh和GradyBooch開始合作致力于建模語言工作，于1995年10月發(fā)布了統一方法UM0.8（UnitiedMethod0.8）。1995年，經過Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發(fā)布了UML0.9和UML0.91，并將UM重新命名為統一建模語言（UnifiedModelingLanguage，UML）。UML是現今較為成熟的軟件建模技術和語言。3.2.1RUP的產生3.2統一過程在創(chuàng)建UML開始階段，UML的三位創(chuàng)始人就認識到軟件開發(fā)除了需要建模技術和語言之外，還需要一個更高層次、能夠指導軟件開發(fā)人員進行開發(fā)活動的開發(fā)過程方法學。1998年，統一過程（RationalUnifiedProcess，RUP）正式發(fā)布，并且將UML作為其建模語言。RUP并不是具體的一系列步驟，而應被視為一種自適應的方法學，可以根據實際開發(fā)的軟件產品進行修改。3.2.1RUP的產生3.2統一過程圖3-6RUP發(fā)展過程

3.2.1RUP的產生統一過程3.2圖3-7RUP過程模型

RUP軟件過程模型是一個二維的軟件開發(fā)模型，也是一種用例驅動、以體系結構為核心、迭代遞增的軟件過程框架。3.2.2RUP的過程模型統一過程3.2RUP包含了軟件開發(fā)積累下來的六大經驗：1.迭代和遞增式開發(fā)2.管理需求3.基于組件的體系結構4.可視化建模5.驗證軟件質量6.控制軟件變更

3.2.3RUP的特點統一過程3.22001年，17位在當時被稱為“輕量級方法學家”的軟件開發(fā)者、軟件工程作家以及軟件咨詢師（敏捷聯盟）共同簽署了“敏捷軟件開發(fā)宣言”。3.3.1敏捷原則3.3敏捷開發(fā)敏捷軟件開發(fā)宣言個體和交互勝過過程和工具可以工作的軟件

勝過

面面俱到的文檔

客戶合作

勝過

合同談判

響應變化

勝過

遵循計劃“我們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發(fā)方法。通過這項工作，我們認識到：雖然右項也具有價值，但我們認為左項具有更大的價值。”敏捷開發(fā)3.3敏捷聯盟制定了12項原則，將敏捷理念落實到具體可操作的層面。敏捷軟件開發(fā)項目以12項原則為基石，但并不是每一個敏捷模型都同等使用這12項原則，一些模型可以選擇忽略或淡化其中的一項或多項原則的重要性。敏捷開發(fā)3.33.3.1敏捷原則（1）最優(yōu)先要做的是通過盡早、持續(xù)地交付有價值的軟件來使客戶滿意。（2）即使在開發(fā)的后期，也歡迎需求變更。敏捷過程利用變更為客戶創(chuàng)造競爭優(yōu)勢。（3）經常交付可運行軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。（4）在整個項目開發(fā)期間，業(yè)務人員和開發(fā)人員必須每天都在一起工作。（5）激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖?。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。（6）不論團隊內外，傳遞信息效果最好和效率最高的方式是面對面的交談。敏捷開發(fā)3.3（7）可工作的軟件是進度的首要度量標準。（8）敏捷過程倡導可持續(xù)開發(fā)。責任人、開發(fā)人員和用戶要能夠共同維持其步調穩(wěn)定延續(xù)。（9）不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力。（10）要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。（11）最好的架構、需求和設計來自于自組織團隊。（12）每隔一定時間，團隊要反思如何才能更有效地工作，并相應調整自己的行為。敏捷開發(fā)3.3極限編程（XP）Scrum精益開發(fā)（Lean）OpenUP3.3.2敏捷過程應用最廣泛的敏捷開發(fā)方法框架有：敏捷開發(fā)3.3極限編程（ExtremeProgramming，XP）是目前敏捷軟件開發(fā)使用最為廣泛的方法之一，其主要目標在于降低因需求變更而帶來的成本。極限編程的創(chuàng)始人KentBeck為XP的實施確定了五個基礎要素：溝通、簡明、反饋、鼓勵和尊重。3.3.3極限編程敏捷開發(fā)3.3圖3-8

XP過程

3.3.3極限編程敏捷開發(fā)3.3Scrum最早由JeffSutherland在1993年提出，KenSchwaber在1995年OOPSLA會議上形式化了Scrum開發(fā)過程，并向業(yè)界公布。Scrum已經是業(yè)界常用的敏捷開發(fā)方法之一。使用Scrum的產品生命周期一般包含三個階段：●產品定義（計劃）：進行迭代所需要的項目準備、項目計劃和技術分析?！竦_發(fā)（執(zhí)行）：在固定時間的迭代中實現需求（產品待辦列表中的條目）?！窠Y束：準備最終的發(fā)布，結束項目。3.3.4Scrum敏捷開發(fā)3.3圖3-9Scrum過程敏捷開發(fā)3.3每個過程模式定義了一系列開發(fā)活動：●待辦列表（Backlog）：能為用戶提供商業(yè)價值的項目需求或者特征的優(yōu)先級列表?！駴_刺（sprint）：是由一系列必須在規(guī)定時間完成的工作單元組成，這些工作單元是為了實現待定需求而必需的。在沖刺過程中，不允許進行任何變更，以確保短期內的穩(wěn)定性●Scrum例會：團隊每天召開短會，幫助團隊盡早發(fā)現問題。●演示：向客戶交付軟件增量，由客戶對其進行評價。3.3.4Scrum敏捷開發(fā)3.31.產品負責人2.ScrumMaster3.Scrum團隊1.產品代辦列表2.發(fā)布燃盡圖3.Sprint代辦列表4.Sprint燃盡圖1.Sprint2.發(fā)布計劃會議3.Sprint計劃會議4.每日例會5.Sprint評審會6.Sprint回顧會議Scrum敏捷過程由三個角色、四個工件、六個時間箱組成。三個角色四個工件六個時間箱敏捷開發(fā)3.3圖3-10

Scrum中的燃盡圖敏捷開發(fā)3.31998年，BrucePerens和EricRaymond創(chuàng)立了開放源代碼促進會（OpenSourceInitiative），發(fā)起了“開放源代碼”運動。開源已經成為軟件領域技術、產品創(chuàng)新的一種重要模式，也是驅動信息產業(yè)變革、強化信息產業(yè)基礎的關鍵要素。在云計算、大數據等新興領域，基于開源模式的技術創(chuàng)新對產業(yè)發(fā)展的影響力日益提升。移動網絡、云計算、大數據等技術的不斷創(chuàng)新，帶動了OpenStack、Hadoop等開源軟件的迅速發(fā)展。3.4.1開源軟件的發(fā)展3.4開源軟件針對開源軟件開發(fā)的特點，Raymond提出兩種開源軟件開發(fā)模型的概念。一種是在每個軟件版本之中源代碼均可以獲得，但是能夠開發(fā)不同版本代碼的人員僅限于項目開發(fā)組內部。另一種是指通過Internet來組織代碼開發(fā)，它允許有很多底層的變化，代碼經?？梢缘玫叫拚瑢τ趤碜酝獠康拇a也來者不拒。大部分的開源開發(fā)屬于第二種模型。開發(fā)者和軟件的使用者構成了開源社區(qū)。形成開源社區(qū)的兩個基本特征是：①社區(qū)成員有一個共同目標，即所要開發(fā)的軟件；②基于這個共同目標，社區(qū)成員遵循一些標準和原則執(zhí)行各自的開發(fā)任務。3.4.2開源軟件的開發(fā)過程開源軟件3.4開源軟件過程與傳統不開源軟件過程比較有以下不同：需求的確定性設計意圖更容易取得團隊認可。分散開發(fā)、配置管理嚴格。積極查找與改進缺陷的態(tài)度。代碼實現與測試交替進行。3.4.2開源軟件的開發(fā)過程開源軟件3.4表3-1軟件過程特性3.5.1軟件過程特性3.5軟件過程的改進能力成熟度模型（CMM）是美國卡內基·梅隆大學軟件工程研究所（SEI）在美國國防部資助下建立的，是一組用于改進軟件過程的相關策略。該模型最初是為了提供一種評價軟件承接方能力的方法，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據，后來同時被軟件組織用于改進其軟件過程。3.5.2能力成熟度模型軟件過程的改進3.5表3-2CMM的五個等級軟件過程的改進3.5圖3-11IDEAL過程改進模型3.5.3IDEAL模型美國卡內基·梅隆大學軟件工程研究所提出了IDEAL過程改進模型。軟件過程的改進3.53.5.4個人軟件過程美國卡內基·梅隆大學軟件工程研究所的WattsS.Humphrey主持開發(fā)了個人軟件