軟件工程結(jié)課論文 敏捷開(kāi)發(fā)在軟件工程中的應(yīng)用 大學(xué)編程作業(yè)（TUST 天津科技大學(xué) 2022 年）

• 軟件工程結(jié)課論文 敏捷開(kāi)發(fā)在軟件工程中的應(yīng)用 大學(xué)編程作業(yè)（TUST 天津科技大學(xué) 2022 年）
  • 一、論文簡(jiǎn)介
  • 二、交流學(xué)習(xí)
• 軟件工程結(jié)課論文 敏捷開(kāi)發(fā)在軟件工程中的應(yīng)用
  • 第一章 引言
    • 1.1 軟件危機(jī)的背景
    • 1.2 軟件工程的提出
    • 1.3 敏捷開(kāi)發(fā)的提出
  • 第二章 軟件工程
    • 2.1 軟件工程的定義
    • 2.2 軟件工程的開(kāi)發(fā)原則
    • 2.3 軟件工程的開(kāi)發(fā)階段
    • 2.4 傳統(tǒng)的軟件工程模型分析
  • 第三章 敏捷開(kāi)發(fā)
    • 3.1 敏捷開(kāi)發(fā)的定義
    • 3.2 敏捷開(kāi)發(fā)的開(kāi)發(fā)原則
    • 3.3 敏捷開(kāi)發(fā)的開(kāi)發(fā)階段
    • 3.4 敏捷開(kāi)發(fā)過(guò)程的典型代表
    • 3.2.1 極限編程（Extreme Programming，XP）
    • 3.2.2 Scrum（迭代式增量軟件開(kāi)發(fā)過(guò)程）
    • 3.2.3 RUP（統(tǒng)一軟件開(kāi)發(fā)過(guò)程）
    • 3.2.4 Crystal（水晶方法）
  • 第四章 總結(jié)
  • 第五章 參考文獻(xiàn)

一、論文簡(jiǎn)介

本文由軟件危機(jī)的產(chǎn)生開(kāi)始，簡(jiǎn)要介紹了傳統(tǒng)軟件工程開(kāi)發(fā)和敏捷開(kāi)發(fā)的基本內(nèi)容，根據(jù)現(xiàn)有軟件工程模型的實(shí)際運(yùn)用對(duì)比，列舉出適合敏捷開(kāi)發(fā)過(guò)程的應(yīng)用場(chǎng)景，并對(duì)常用敏捷開(kāi)發(fā)過(guò)程進(jìn)行分析，為實(shí)現(xiàn)軟件產(chǎn)品的輕量化開(kāi)發(fā)管理交付提供了方法依據(jù)。

這篇文章是我大三寫的，現(xiàn)在回顧已經(jīng)非常粗糙，分享出來(lái)一方面希望可以幫助初學(xué)者，另一方面希望能讓同學(xué)們可以從目前大學(xué)中普遍毫無(wú)價(jià)值的形式主義作業(yè)中解脫出來(lái)，更加高效地學(xué)習(xí)優(yōu)質(zhì)計(jì)算機(jī)知識(shí)和主流編程技術(shù)，一起發(fā)揚(yáng)開(kāi)源精神，感受互聯(lián)網(wǎng)技術(shù)的美好愿景。

二、交流學(xué)習(xí)

互聯(lián)網(wǎng)開(kāi)源精神需要大家一起互相交流學(xué)習(xí)，互相支持奉獻(xiàn)。歡迎大家與我友好交流。

加我 QQ 好友獲取所有項(xiàng)目源碼和項(xiàng)目文檔，感謝大家的支持！

軟件工程結(jié)課論文 敏捷開(kāi)發(fā)在軟件工程中的應(yīng)用

【摘要】 本文由軟件危機(jī)的產(chǎn)生開(kāi)始，簡(jiǎn)要介紹了傳統(tǒng)軟件工程開(kāi)發(fā)和敏捷開(kāi)發(fā)的基本內(nèi)容，根據(jù)現(xiàn)有軟件工程模型的實(shí)際運(yùn)用對(duì)比，列舉出適合敏捷開(kāi)發(fā)過(guò)程的應(yīng)用場(chǎng)景，并對(duì)常用敏捷開(kāi)發(fā)過(guò)程進(jìn)行分析，為實(shí)現(xiàn)軟件產(chǎn)品的輕量化開(kāi)發(fā)管理交付提供了方法依據(jù)。

第一章 引言

1.1 軟件危機(jī)的背景

軟件危機(jī)（software crisis），20 世紀(jì) 60 年代以前，計(jì)算機(jī)剛剛投入實(shí)際使用，軟件設(shè)計(jì)往往只是為了一個(gè)特定的應(yīng)用而在指定的計(jì)算機(jī)上設(shè)計(jì)和編制，采用密切依賴于計(jì)算機(jī)的機(jī)器代碼或匯編語(yǔ)言，軟件的規(guī)模比較小，文檔資料通常也不存在，很少使用系統(tǒng)化的開(kāi)發(fā)方法，設(shè)計(jì)軟件往往等同于編制程序，基本上是個(gè)人設(shè)計(jì)、個(gè)人使用、個(gè)人操作、自給自足的私人化的軟件生產(chǎn)方式。

60 年代中期，大容量、高速度計(jì)算機(jī)的出現(xiàn)，使計(jì)算機(jī)的應(yīng)用范圍迅速擴(kuò)大，軟件開(kāi)發(fā)急劇增長(zhǎng)。高級(jí)語(yǔ)言開(kāi)始出現(xiàn)；操作系統(tǒng)的發(fā)展引起了計(jì)算機(jī)應(yīng)用方式的變化；大量數(shù)據(jù)處理導(dǎo)致第一代數(shù)據(jù)庫(kù)管理系統(tǒng)的誕生。軟件系統(tǒng)的規(guī)模越來(lái)越大，復(fù)雜程度越來(lái)越高，軟件可靠性問(wèn)題也越來(lái)越突出。原來(lái)的個(gè)人設(shè)計(jì)、個(gè)人使用的方式不再能滿足要求，迫切需要改變軟件生產(chǎn)方式，提高軟件生產(chǎn)率，軟件危機(jī)開(kāi)始爆發(fā) 。

1968 年，北大西洋公約組織（NATO）在聯(lián)邦德國(guó)的國(guó)際學(xué)術(shù)會(huì)議創(chuàng)造軟件危機(jī)（Software crisis）一詞。而 1960 年代中期開(kāi)始爆發(fā)眾所周知的軟件危機(jī)，為了解決問(wèn)題，在 1968、1969 年連續(xù)召開(kāi)兩次著名的 NATO 會(huì)議，并同時(shí)提出軟件工程的概念。[文獻(xiàn) 1]

1.2 軟件工程的提出

軟件工程在提出后，其目標(biāo)便是付出較低開(kāi)發(fā)成本；達(dá)到要求的功能；取得較好的性能；開(kāi)發(fā)的軟件易于移植；只需較低的維護(hù)費(fèi)用；能按時(shí)完成開(kāi)發(fā)任務(wù)，及時(shí)交付使用；開(kāi)發(fā)的軟件可靠性高。

軟件工程概括來(lái)說(shuō)，就是應(yīng)用計(jì)算機(jī)科學(xué)、數(shù)學(xué)、邏輯學(xué)及管理科學(xué)等原理，開(kāi)發(fā)軟件的工程。軟件工程借鑒傳統(tǒng)工程的原則、方法，以提高質(zhì)量、降低成本和改進(jìn)算法。其中，計(jì)算機(jī)科學(xué)、數(shù)學(xué)用于構(gòu)建模型與算法，工程科學(xué)用于制定規(guī)范、設(shè)計(jì)范型（paradigm）、評(píng)估成本及確定權(quán)衡，管理科學(xué)用于計(jì)劃、資源、質(zhì)量、成本等管理。

1.3 敏捷開(kāi)發(fā)的提出

隨著信息化技術(shù)的高速發(fā)展以及網(wǎng)絡(luò)產(chǎn)品的普及，客戶對(duì)于軟件產(chǎn)品的版本穩(wěn)定性及交付周期都提出了更為嚴(yán)格的要求，軟件工程理念的引入正迎合了這一需求。

軟件工程采用工程的概念、原理、技術(shù)、方法來(lái)開(kāi)發(fā)與維護(hù)軟件，利用軟件工程模型整合資源、縮短開(kāi)發(fā)周期，在實(shí)際運(yùn)用中取得了良好效果。然而，在版本維護(hù)周期縮短，版本迭代速度提升的前提下，原有的軟件工程模型在客戶需求和開(kāi)發(fā)時(shí)間的雙重壓力下，被開(kāi)發(fā)負(fù)責(zé)人分解為多個(gè)相互聯(lián)系也可獨(dú)立運(yùn)行的小模型并分別完成，在此過(guò)程中軟件一直處于可使用狀態(tài)，這就是敏捷開(kāi)發(fā)。

敏捷開(kāi)發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法。[文獻(xiàn) 2] 在敏捷開(kāi)發(fā)中，軟件項(xiàng)目的構(gòu)建被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過(guò)測(cè)試，具備集成和可運(yùn)行的特征。本文通過(guò)分析軟件工程模型的基礎(chǔ)上，總結(jié)出敏捷開(kāi)發(fā)應(yīng)用的特點(diǎn)，在項(xiàng)目實(shí)際運(yùn)用中具有參考價(jià)值。

第二章 軟件工程

2.1 軟件工程的定義

軟件工程是研究和應(yīng)用如何以系統(tǒng)性的、規(guī)范化的、可定量的過(guò)程化方法去開(kāi)發(fā)和維護(hù)軟件，以及如何把經(jīng)過(guò)時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來(lái)的學(xué)科。它涉及到程序設(shè)計(jì)語(yǔ)言、數(shù)據(jù)庫(kù)、軟件開(kāi)發(fā)工具、系統(tǒng)平臺(tái)、標(biāo)準(zhǔn)、設(shè)計(jì)模式等方面。

軟件工程內(nèi)涵有兩部分：

一、軟件工程過(guò)程是指為獲得軟件產(chǎn)品，在軟件工具的支持下由軟件工程師完成的一系列軟件工程活動(dòng)，包括以下四個(gè)方面：

P（Plan）——軟件規(guī)格說(shuō)明。規(guī)定軟件的功能及其運(yùn)行時(shí)的限制。

D（DO）——軟件開(kāi)發(fā)。開(kāi)發(fā)出滿足規(guī)格說(shuō)明的軟件。

C（Check）——軟件確認(rèn)。確認(rèn)開(kāi)發(fā)的軟件能夠滿足用戶的需求。

A（Action）——軟件演進(jìn)。軟件在運(yùn)行過(guò)程中不斷改進(jìn)以滿足客戶新的需求。

二、從軟件開(kāi)發(fā)的觀點(diǎn)看，它就是使用適當(dāng)?shù)馁Y源（包括人員，軟硬件資源，時(shí)間等），為開(kāi)發(fā)軟件進(jìn)行的一組開(kāi)發(fā)活動(dòng)，在活動(dòng)結(jié)束時(shí)輸入（即用戶的需求）轉(zhuǎn)化為輸出（最終符合用戶需求的軟件產(chǎn)品）。

2.2 軟件工程的開(kāi)發(fā)原則

軟件工程的原則是指圍繞工程設(shè)計(jì)、工程支持以及工程管理在軟件開(kāi)發(fā)過(guò)程中必須遵循的原則。

軟件工程的原則有以下四項(xiàng)基本原則：

一、選取適宜開(kāi)發(fā)范型，該原則與系統(tǒng)設(shè)計(jì)有關(guān)。在系統(tǒng)設(shè)計(jì)中，軟件需求、硬件需求以及其他因素之間是相互制約、相互影響的，經(jīng)常需要權(quán)衡。因此，必須認(rèn)識(shí)需求定義的易變性，采用適宜的開(kāi)發(fā)范型予以控制，以保證軟件產(chǎn)品滿足用戶的要求。

二、采用合適的設(shè)計(jì)方法，在軟件設(shè)計(jì)中，通常要考慮軟件的模塊化、抽象與信息隱蔽、局部化、一致性以及適應(yīng)性等特征。合適的設(shè)計(jì)方法有助于這些特征的實(shí)現(xiàn)，以達(dá)到軟件工程的目標(biāo)。

三、提供高質(zhì)量的工程支持，“工欲善其事，必先利其器”。在軟件工程中，軟件工具與環(huán)境對(duì)軟件過(guò)程的支持頗為重要。軟件工程項(xiàng)目的質(zhì)量與開(kāi)銷直接取決于對(duì)軟件工程所提供的支撐質(zhì)量和效用。

四、重視開(kāi)發(fā)過(guò)程的管理，軟件工程的管理，直接影響可用資源的有效利用，生產(chǎn)滿足目標(biāo)的軟件產(chǎn)品，提高軟件組織的生產(chǎn)能力等問(wèn)題。因此，僅當(dāng)軟件過(guò)程得以有效管理時(shí)，才能實(shí)現(xiàn)有效的軟件工程。

2.3 軟件工程的開(kāi)發(fā)階段

軟件開(kāi)發(fā)生命周期，亦叫做軟件生命周期或者系統(tǒng)開(kāi)發(fā)生命周期，是直到生命周期結(jié)束的軟件生成生命周期。有問(wèn)題定義，可行性分析，總體描述，系統(tǒng)設(shè)計(jì)，編碼，調(diào)試和測(cè)試，驗(yàn)收。

將整個(gè)軟件開(kāi)發(fā)生命周期劃分為多個(gè)階段，以便每個(gè)階段都有明確的任務(wù)，從而可以輕松地控制和管理具有大規(guī)模，復(fù)雜結(jié)構(gòu)和復(fù)雜管理的軟件開(kāi)發(fā)。通常，軟件開(kāi)發(fā)周期包括可行性分析和開(kāi)發(fā)計(jì)劃，需求分析，設(shè)計(jì)（摘要設(shè)計(jì)和詳細(xì)設(shè)計(jì)），編碼，測(cè)試，維護(hù)等，可以按照適當(dāng)?shù)姆绞椒峙浣o不同的階段：

一、需求階段：

通過(guò)溝通交流，產(chǎn)出需求文檔，包含頁(yè)面的內(nèi)容，則需要對(duì)應(yīng)的進(jìn)行設(shè)計(jì)稿的設(shè)計(jì)。通過(guò)評(píng)審會(huì)，使涉及到的人都有自己的了解，同時(shí)對(duì)需求進(jìn)行改進(jìn)。

二、開(kāi)發(fā)階段：

開(kāi)發(fā)：編碼，自行測(cè)試。

產(chǎn)品：對(duì)產(chǎn)品進(jìn)行驗(yàn)收。

測(cè)試：編寫測(cè)試用例，進(jìn)行測(cè)試用例的評(píng)審會(huì)議。該階段需要涉及人進(jìn)行一個(gè)測(cè)試用例的評(píng)審會(huì)。

三、測(cè)試階段：

測(cè)試人員根據(jù)測(cè)試用例進(jìn)行測(cè)試，并進(jìn)行問(wèn)題反饋，編寫測(cè)試報(bào)告，開(kāi)發(fā)人員進(jìn)行 bug 的修復(fù)，如有需求不確認(rèn)的，再找分析/產(chǎn)品/PM 等進(jìn)行確認(rèn)。bug 修復(fù)完成后，測(cè)試再進(jìn)行回歸測(cè)試，同時(shí)測(cè)試還需要兼容性的測(cè)試，對(duì)依賴項(xiàng)或者機(jī)器都進(jìn)行對(duì)應(yīng)的測(cè)試。

灰度發(fā)布：（內(nèi)部灰度，外部灰度）

為了防止在正式區(qū)發(fā)生問(wèn)題，會(huì)有一個(gè)特定的環(huán)境，類似于線上環(huán)境，提供給到測(cè)試，防止后期出現(xiàn)問(wèn)題，提前解決問(wèn)題。

四、發(fā)布階段：

發(fā)布階段，為了防止會(huì)有依賴項(xiàng)出現(xiàn)問(wèn)題，所以會(huì)對(duì)多臺(tái)服務(wù)器進(jìn)行控制，分批進(jìn)行發(fā)布。

2.4 傳統(tǒng)的軟件工程模型分析

軟件工程過(guò)程模型是一種策略，這種策略是由軟件工程師在具體的實(shí)踐工程活動(dòng)當(dāng)中設(shè)計(jì)并提煉出來(lái)，能夠覆蓋軟件過(guò)程的基本階段確定設(shè)計(jì)的方法、過(guò)程及工具。*[文獻(xiàn) 3]*在實(shí)際中應(yīng)用最多的軟件工程模型主要包括瀑布模型、螺旋模型、迭代模型和原型模型，下表以表格的形式對(duì)這四種模型進(jìn)行分析：

模型名稱形式優(yōu)勢(shì)劣勢(shì)

瀑布模型	線性順序模型。過(guò)程嚴(yán)格按照"需求一分析一設(shè)計(jì)一編碼一測(cè)試"的步驟進(jìn)行。每個(gè)階段都要定義明確的產(chǎn)出物及驗(yàn)證準(zhǔn)則。	可以保證軟件產(chǎn)品具有較高的質(zhì)量：保證提前發(fā)現(xiàn)和解決存在的缺陷；保證軟件系統(tǒng)在整體上具有充分的把握，從而保證系統(tǒng)具備良好的可維護(hù)性和擴(kuò)展性。	瀑布模型沒(méi)有反饋環(huán)，難以完善和滿足用戶的需求，一旦需求發(fā)生變化后者需求增多，則瀑布模型就顯示出了很大的劣勢(shì)。
螺旋模型	螺旋模型每一次迭代僅僅包含了瀑布模型的某一個(gè)或者個(gè)階段。	螺旋模型遵循了瀑布模型的模式，隨著項(xiàng)目成本的逐漸增加，風(fēng)險(xiǎn)性則逐漸減小。有利于已有軟件的重用，有助于把軟件質(zhì)量作為軟件開(kāi)發(fā)的重要目標(biāo)。	缺點(diǎn)是對(duì)于風(fēng)險(xiǎn)評(píng)估比較困難。
迭代模型	迭代模型是指在進(jìn)行較大規(guī)模的項(xiàng)目任務(wù)時(shí)，將迭代開(kāi)發(fā)分為若干次，第一次迭代完成項(xiàng)目各階段的基本業(yè)務(wù)，但是不包含較為復(fù)雜的業(yè)務(wù)和邏輯，通過(guò)第二個(gè)功能則針對(duì)相關(guān)的邏輯和業(yè)務(wù)逐漸補(bǔ)充完整并進(jìn)行細(xì)化。	迭代模型能夠較早得到用戶的反饋，不斷的測(cè)試和整合,是項(xiàng)目短期里程碑。主要適用于系統(tǒng)需求不穩(wěn)定的情況，所包含的活動(dòng)與瀑布模型一樣，包括軟件的需求分析和設(shè)計(jì)、代碼生成測(cè)試及維護(hù)。	迭代周期以及每次迭代的內(nèi)容難以規(guī)劃，對(duì)于項(xiàng)目架構(gòu)師要求較高。
原型模型	原型模型能夠快速實(shí)現(xiàn)一個(gè)可以實(shí)際運(yùn)作的系統(tǒng)初步模型，適用于有結(jié)構(gòu)的系統(tǒng)或者需求不明確的系統(tǒng)。	原型模型是很好的啟發(fā)方法，可以迅速地挖掘用戶的需求并與用戶達(dá)成一致，避免在簽字時(shí)發(fā)現(xiàn)需求并不是客戶所滿意的東西。	沒(méi)有反饋環(huán)。原型模型—服不單獨(dú)采用，往往是與瀑布模型和迭代模型一起使用。

表 1 軟件工程 4 種模型對(duì)比

由上表分析可知，在軟件工程實(shí)際運(yùn)用中，只采用單一種模型顯然不能適應(yīng)實(shí)際項(xiàng)目復(fù)雜的需求變更，采用各種模型組合開(kāi)發(fā)的形式在實(shí)際運(yùn)用中較為廣泛，然而一些瀑布模型版本允許生命周期中相鄰階段的迭代，在大系統(tǒng)中肯定存在較晚階段浮現(xiàn)的不能快速定位的問(wèn)題，因而往往瀑布模型在實(shí)際運(yùn)用中結(jié)束于大規(guī)模的迭代，那些迭代包括越來(lái)越多的生命周期階段。生命周期的累加必然會(huì)造成開(kāi)發(fā)周期的延長(zhǎng)從而耽誤交付時(shí)間，從而增加了軟件開(kāi)發(fā)的風(fēng)險(xiǎn)。因此采用面向?qū)ο蟮乃枷朐趥鹘y(tǒng)軟件模型基礎(chǔ)上進(jìn)行演進(jìn)而產(chǎn)生的敏捷開(kāi)發(fā)，就擁有了更多的應(yīng)用場(chǎng)景。

第三章 敏捷開(kāi)發(fā)

3.1 敏捷開(kāi)發(fā)的定義

稱敏捷開(kāi)發(fā)是一種從 1990 年代開(kāi)始逐漸引起廣泛關(guān)注的一些新型軟件開(kāi)發(fā)方法，是一種應(yīng)對(duì)快速變化的需求的一種軟件開(kāi)發(fā)能力。它們的具體名稱、理念、過(guò)程、術(shù)語(yǔ)都不盡相同，相對(duì)于"非敏捷"，更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專家之間的緊密協(xié)作、面對(duì)面的溝通（認(rèn)為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊(duì)、能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊(duì)組織方法，也更注重軟件開(kāi)發(fā)中人的作用

敏捷開(kāi)發(fā)以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開(kāi)發(fā)。在敏捷開(kāi)發(fā)中，軟件項(xiàng)目在構(gòu)建初期被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過(guò)測(cè)試，具備可視、可集成和可運(yùn)行使用的特征。換言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過(guò)程中軟件一直處于可使用狀態(tài)。

3.2 敏捷開(kāi)發(fā)的開(kāi)發(fā)原則

一、快速迭代：

相對(duì)那種半年一次的大版本發(fā)布來(lái)說(shuō)，小版本的需求、開(kāi)發(fā)和測(cè)試更加簡(jiǎn)單快速。一些公司，一年發(fā)布僅 2~3 個(gè)版本，發(fā)布流程緩慢，它們?nèi)圆捎闷俨奸_(kāi)發(fā)模式，更嚴(yán)重的是對(duì)敏捷開(kāi)發(fā)模式存在誤解。

二、讓測(cè)試人員和開(kāi)發(fā)者參與需求討論：

需求討論以研討組的形式展開(kāi)最有效率。研討組，需要包括測(cè)試人員和開(kāi)發(fā)者，這樣可以更加輕松定義可測(cè)試的需求，將需求分組并確定優(yōu)先級(jí)。 同時(shí)，該種方式也可以充分利用團(tuán)隊(duì)成員間的互補(bǔ)特性。如此確定的需求往往比開(kāi)需求討論大會(huì)的形式效率更高，大家更活躍，參與感更強(qiáng)。

三、編寫可測(cè)試的需求文檔：

開(kāi)始就要用"用戶故事"（User Story）的方法來(lái)編寫需求文檔。這種方法，可以讓我們將注意力放在需求上，而不是解決方法和實(shí)施技術(shù)上。過(guò)早的提及技術(shù)實(shí)施方案，會(huì)降低對(duì)需求的注意力。

四、多溝通，盡量減少文檔：

任何項(xiàng)目中，溝通都是一個(gè)常見(jiàn)的問(wèn)題。好的溝通，是敏捷開(kāi)發(fā)的先決條件。在圈子里面混得越久，越會(huì)強(qiáng)調(diào)良好高效的溝通的重要性。

團(tuán)隊(duì)要確保日常的交流，面對(duì)面溝通比郵件強(qiáng)得多。

五、做好產(chǎn)品原型：

建議使用草圖和模型來(lái)闡明用戶界面。并不是所有人都可以理解一份復(fù)雜的文檔，但人人都會(huì)看圖。

六、及早考慮測(cè)試：

及早地考慮測(cè)試在敏捷開(kāi)發(fā)中很重要。傳統(tǒng)的軟件開(kāi)發(fā)，測(cè)試用例很晚才開(kāi)始寫，這導(dǎo)致過(guò)晚發(fā)現(xiàn)需求中存在的問(wèn)題，使得改進(jìn)成本過(guò)高。較早地開(kāi)始編寫測(cè)試用例，當(dāng)需求完成時(shí)，可以接受的測(cè)試用例也基本一塊完成了。[文獻(xiàn) 4]

3.3 敏捷開(kāi)發(fā)的開(kāi)發(fā)階段

敏捷開(kāi)發(fā)流程的八個(gè)步驟包括：

一、目標(biāo)制定，目標(biāo)對(duì)齊：

通過(guò)市場(chǎng)調(diào)研、業(yè)務(wù)思路、風(fēng)險(xiǎn)評(píng)估制定公司規(guī)劃和目標(biāo)，根據(jù)這一目標(biāo)產(chǎn)生所有部門的目標(biāo)并實(shí)現(xiàn)對(duì)齊。

二、產(chǎn)品規(guī)劃：

產(chǎn)品研發(fā)部門根據(jù)目標(biāo)制定產(chǎn)品關(guān)鍵路線圖，這個(gè)路線圖中分布著不同的產(chǎn)品特性和其完成時(shí)間。

三、組織產(chǎn)品待辦列表：

產(chǎn)品規(guī)劃產(chǎn)生的需求、客戶需求、市場(chǎng)人員收集到的缺陷等將組成產(chǎn)品待辦列表。

四、需求梳理：

然后產(chǎn)品負(fù)責(zé)人（Product Ower）對(duì)這個(gè)列表進(jìn)行梳理，并在需求梳理會(huì)（Backlog Grooming Meeting）講解具體每一個(gè)需求，團(tuán)隊(duì)成員根據(jù)需求的復(fù)雜程度評(píng)估每個(gè)任務(wù)的工作量，輸出本次迭代的待辦事項(xiàng)列表，完成優(yōu)先級(jí)排序等工作。

五、迭代規(guī)劃：

通過(guò) Sprint 計(jì)劃會(huì)，明確要執(zhí)行的工作、沖刺目標(biāo)等。

六、迭代開(kāi)發(fā)：

期間會(huì)進(jìn)行每日站會(huì)、性能測(cè)試、CodeReview、Demo、測(cè)試等工作。

七、Sprint 評(píng)審：

由每個(gè)任務(wù)的負(fù)責(zé)人演示其完整的工作，由 PO 確定 Sprint 目標(biāo)是否完成，版本什么時(shí)候?qū)ν獍l(fā)布，新增 bug 的緊急程度等等。

八、開(kāi)回顧會(huì)議：

回顧會(huì)議由 Scrum 團(tuán)隊(duì)檢視自身在過(guò)去的 Sprint 的表現(xiàn)，包括人 、關(guān)系、過(guò)程、工具等，思考在下一個(gè) Sprint 中怎么樣可以表現(xiàn)得更好，更高效，怎么樣可以和團(tuán)隊(duì)合作地更愉快。

圖 1 敏捷開(kāi)發(fā)的流程圖

3.4 敏捷開(kāi)發(fā)過(guò)程的典型代表

面向?qū)ο蟮乃枷胧前严到y(tǒng)定義為一組正在交互的對(duì)象，是一種不同以往的思考形式。敏捷開(kāi)發(fā)所遵循的基本價(jià)值觀可以總結(jié)為以下幾點(diǎn)：

開(kāi)發(fā)團(tuán)隊(duì)和他們之間的交互比開(kāi)發(fā)過(guò)程和所使用的工具更重要。

在軟件產(chǎn)品上多下功夫比廣泛的文檔編制更重要。

在開(kāi)發(fā)過(guò)程中間客戶的良好協(xié)作比簽訂合同的談判更重要。

積極面對(duì)需求的變更比實(shí)現(xiàn)一個(gè)完美的計(jì)劃更重要。

在這一價(jià)值觀引導(dǎo)下，敏捷開(kāi)發(fā)的開(kāi)發(fā)過(guò)程主要是：

3.2.1 極限編程（Extreme Programming，XP）

極限編程是一套能快速開(kāi)發(fā)高質(zhì)量軟件所需的價(jià)值觀、原則和活動(dòng)的集合，使軟件能夠快速開(kāi)發(fā)出來(lái)并向客戶提供最高效益*[文獻(xiàn) 5]*。極限編程的極限就在于它將眾所周知的軟件開(kāi)發(fā)"最佳實(shí)踐"都發(fā)揮到極致：

計(jì)劃游戲：在需求和實(shí)現(xiàn)間取得平衡。

小版本：在每個(gè)迭代周期交付可執(zhí)行的版本，根據(jù)客戶提供的評(píng)價(jià)獲得反饋。

簡(jiǎn)單設(shè)計(jì)：只設(shè)計(jì)立刻需要的東西。

測(cè)試：程序員編寫單元測(cè)試,使得他們對(duì)程序的信心成為程序的一部分。

重構(gòu)：更改現(xiàn)有程序從而使添加功能變得簡(jiǎn)單。

結(jié)對(duì)編程：所有的生產(chǎn)代碼都由兩個(gè)人使用同一臺(tái)計(jì)算機(jī)完成。

集體所有權(quán)：任何人有發(fā)現(xiàn)改進(jìn)代碼的機(jī)會(huì)，馬上執(zhí)行改進(jìn)。

持續(xù)集成：幾個(gè)小時(shí)的開(kāi)發(fā)后對(duì)代碼進(jìn)行集成和測(cè)試。

現(xiàn)場(chǎng)客戶：真實(shí)的客戶同開(kāi)發(fā)團(tuán)隊(duì)坐在一起，隨時(shí)回答問(wèn)題。

編碼標(biāo)準(zhǔn)：人員交換和代碼重構(gòu)的要求，追求最小工作量。

圖 2 極限編程（Extreme Programming，XP）的流程圖

3.2.2 Scrum（迭代式增量軟件開(kāi)發(fā)過(guò)程）

Scrum 是一種迭代的增量化過(guò)程，用于產(chǎn)品開(kāi)發(fā)或工作管理，其將項(xiàng)目分成短期迭代，或者"短跑"（sprints）,每個(gè) sprint 在開(kāi)發(fā)團(tuán)隊(duì)和團(tuán)隊(duì)管理間有個(gè)短會(huì)跟蹤進(jìn)展，在每個(gè) sprint 期間開(kāi)發(fā)目標(biāo)保持不變*[文獻(xiàn) 6]*。在一個(gè) sprint 運(yùn)作期間，新需求的加入會(huì)規(guī)劃到下一個(gè) sprint 中去，從而保證每個(gè) sprint 中的開(kāi)發(fā)目標(biāo)保持不變。

Scrum 是一種對(duì)已存在系統(tǒng)的管理、提高和維護(hù)方法，在 Scrum 中發(fā)布產(chǎn)品的重要性高于一切，其主要關(guān)注項(xiàng)目的客戶需求、時(shí)間壓力、競(jìng)爭(zhēng)、質(zhì)量、版本和資源。

圖 3 Scrum（迭代式增量軟件開(kāi)發(fā)過(guò)程）的流程圖

3.2.3 RUP（統(tǒng)一軟件開(kāi)發(fā)過(guò)程）

RUP 將一個(gè)項(xiàng)目分解成多個(gè)開(kāi)發(fā)周期，將每個(gè)開(kāi)發(fā)周期分解成多個(gè)階段：先啟階段、精化階段、構(gòu)建階段和移交（產(chǎn)品化）階段。每個(gè)階段由依次的開(kāi)發(fā)迭代組成，每個(gè)迭代產(chǎn)生可執(zhí)行的產(chǎn)出物。RUP 在軟件開(kāi)發(fā)中確定了一系列的"工作流"：業(yè)務(wù)建模、需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、部署、配置和變更管理、項(xiàng)目管理、環(huán)境管理。所有的工作流在每個(gè)階段都會(huì)涉及。

RUP 在每個(gè)階段為每個(gè)開(kāi)發(fā)成員都提供了行為準(zhǔn)則、模板和工具指導(dǎo)，建立了簡(jiǎn)潔和清晰的過(guò)程結(jié)構(gòu)，為開(kāi)發(fā)過(guò)程提供較大的通用性，但是 RUP 只是一個(gè)過(guò)程，沒(méi)有涵蓋軟件工程的全部?jī)?nèi)容。例如缺少軟件運(yùn)行和支持方面的內(nèi)容*[文獻(xiàn) 7]*，在實(shí)際運(yùn)用中可以結(jié)合軟件工程的整體計(jì)劃進(jìn)行改進(jìn)。

圖 4 RUP（統(tǒng)一軟件開(kāi)發(fā)過(guò)程）的流程圖

3.2.4 Crystal（水晶方法）

水晶方法組由一系列以人為本、自適應(yīng)、超輕型、可伸縮的軟件開(kāi)發(fā)方法構(gòu)成。Crystal 方法不僅考慮最佳理論，而且考慮切實(shí)可行，因此希望獲得好的折衷并最終滿足大批需求而取得成果。過(guò)程的形式由項(xiàng)目的大小和種類比例決定，Crystal 經(jīng)驗(yàn)包括：

強(qiáng)調(diào)一組：不同項(xiàng)目需要不同方法;

兩個(gè)主要變數(shù)：開(kāi)發(fā)團(tuán)隊(duì)人數(shù)和可靠性要求;

注重人性：考慮開(kāi)發(fā)者不易遵循嚴(yán)格方法，強(qiáng)調(diào)不很嚴(yán)格但仍能保證成功和容易執(zhí)行的方法。

Crystal 可以說(shuō)是最輕的一類方法，但不惜對(duì)迭代過(guò)程后期評(píng)審加載以及早發(fā)現(xiàn)問(wèn)題和及時(shí)糾正，強(qiáng)調(diào)對(duì)過(guò)程的監(jiān)控，使開(kāi)發(fā)過(guò)程呈現(xiàn)出定制化的特定，是非常人性化的開(kāi)發(fā)方式。

圖 5 Crystal（水晶方法）的流程圖

第四章 總結(jié)

在實(shí)際軟件項(xiàng)目中，只要項(xiàng)目具有一定規(guī)模，不論是設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、部署各個(gè)階段都會(huì)有分解任務(wù)給不同人員，而且這些階段本身也屬于一種任務(wù)的分解，在不同人員間分解任務(wù)就不可避免的引發(fā)額外的溝通成本——培訓(xùn)和相互溝通。因?yàn)檐浖_(kāi)發(fā)本質(zhì)上是一項(xiàng)系統(tǒng)工作——錯(cuò)綜復(fù)雜的關(guān)系下的一種實(shí)踐，溝通、交流的工作量非常大，它很快會(huì)消耗任務(wù)分解所節(jié)省下來(lái)的個(gè)人時(shí)間。

軟件開(kāi)發(fā)中時(shí)間再多一件事情也不可能做的完美，但總有時(shí)間做完一件事情。軟件開(kāi)發(fā)領(lǐng)域，永遠(yuǎn)不可能完美，所以建議我們先把事情做完。這就是敏捷的思想。先把事情做了，再去逐步逼近完美。所以敏捷管理主張持續(xù)交付，快速迭代，及時(shí)反饋，立刻驗(yàn)證，持續(xù)優(yōu)化。

在實(shí)際系統(tǒng)項(xiàng)目運(yùn)用中，是否采用敏捷開(kāi)發(fā)要依據(jù)項(xiàng)目規(guī)模進(jìn)行選擇。對(duì)于系統(tǒng)項(xiàng)目（軟硬件結(jié)合）：要采用軟件工程的理論進(jìn)行宏觀分析，比如采用瀑布+迭代+風(fēng)險(xiǎn)管控的方式進(jìn)行規(guī)劃，而在實(shí)際實(shí)現(xiàn)階段則可引入敏捷開(kāi)發(fā)的理念，實(shí)現(xiàn)輕量化管理交付；對(duì)于純軟件項(xiàng)目則可直接進(jìn)行規(guī)模分解根據(jù)軟件規(guī)模選擇敏捷開(kāi)發(fā)中的開(kāi)發(fā)過(guò)程，從而根據(jù)實(shí)際情況進(jìn)行差異化開(kāi)發(fā)。

第五章 參考文獻(xiàn)

[1]陳增榮.軟件開(kāi)發(fā)方法評(píng)述.中國(guó)大陸 AKA 雜志，[2012-05-22].

[2] 馬丁.敏捷軟件開(kāi)發(fā)-原則、模式與實(shí)現(xiàn).人民郵電出版社，[2008-1-1].

[3] 樊學(xué)東.軟件工程過(guò)程模型及其選擇.西安外事學(xué)院學(xué)報(bào)，[2008-12-4].

[4] TechTarget.敏捷開(kāi)發(fā)的六個(gè)實(shí)戰(zhàn)經(jīng)驗(yàn)，[2015-10-31].

[5] Kent Bec k.解析極限編程——擁抱變化.人民郵電出版社，2002.

[6] Alistair Cockburm，Addison WesleyAgile， Software Development，2000.

[7] Dan Turk，Robert France，Bernhard Rumpe，xprogrammer.敏捷軟件過(guò)程的局限性， [2004-8].

總結(jié)

以上是生活随笔為你收集整理的软件工程结课论文 敏捷开发在软件工程中的应用 大学编程作业（TUST 天津科技大学 2022年）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。