多元化時代敏捷軟件開發的崛起與傳統軟件工程的延續

?

多元化時代敏捷軟件開發的崛起與傳統軟件工程的延續

?

1.傳統軟件開發模式

? 1.1瀑布模型

? ? 1.1.1概念

? ? ? 瀑布模型,顧名思義,軟件開發的過程如同瀑布飛流一般,自上而下,逐級下落。瀑布模型的核心思想是將問題按照工序進行簡化,將軟件結構的設計與軟件功能的實現分隔開來,同時運用結構化的分析與設計方法,將軟件的物理基礎與邏輯實現也分隔開來。瀑布模型將軟件開發周期按照順序線性地分為了六個基本活動階段,分別為制定計劃階段、需求分析階段、軟件設計階段、程序編寫階段、軟件測試階段以及運行維護階段。這六個階段線性排列,相互銜接,具有嚴格的執行順序。瀑布模型的提出很大程度上體現了流程化的設計思想,便于進行分工與協作。

? ? 1.1.2優點

? ? ? 瀑布模型正是由于其嚴格的階段化流程,因而在流程設計上具有十分明顯的優勢。該模型使得項目本身就可具備了天然的檢查點,階段的劃分為軟件開發者提供了定時檢查的可能,是較強的標準化措施。而對于軟件開發者來說,每一階段的完成既象征著下一階段的開始,也意味著上一階段的完結,因而能夠讓開發人員集中更多的精力于后續的開發,而不再考慮之前的設計,大大提高了開發的效率,也提高了項目本身的標準化程度。

? ? 1.1.3缺陷

? ? ? 由于瀑布模型基于了嚴格的階段設計,而不同的階段的執行順序也是線性的,雖然對于軟件開發人員來說規定好了開發的路線,也為不同的階段劃定了嚴格的界限。然而也正是這種界限,使得項目開發的各個階段之間缺乏必要的交流與探討,也沒有相關的情況反饋,因而對項目的完整性和交互性沒有很好地約束。另外,順序化的執行方式意味著我們只能在項目生命周期的后期才能看到軟件開發的初步結果,使得留給后續測試反饋等工作的時間過少,某些意義上拖長了整個產品的生命周期。除此之外,為了嚴格按照既定時間完成各階段的內容,常常要求我們用一些強制性的措施來跟蹤項目的發展過程,從而保證項目進度的正常,這就意味著整個項目開發的過程過于死板,難以變通,不具備良好的反應能力,更不適應用戶的需求變化。

? 1.2迭代模型

? ? 1.2.1概念

? ? ? 迭代開發是一個大規模的迭代過程,它將整個項目分解成了若干個小項目,而每一個小項目在一定程度上也可以再繼續劃分成更小的項目,而對于每一個這樣的劃分出來的小項目,我們都可以基于瀑布模型對其進行完整的一輪開發,在很短的周期內產生一個可發布的產品,而這個產品則是最終產品的一個子集。迭代開發由若干個這樣的過程組成,類似于小型瀑布開發項目的集合。迭代開發適用于早期需求不斷變化的項目,并且要求分析設計人員對項目所設計的領域具有相當高的熟悉程度。總而言之,對于那些風險度較高,用戶參與程度較高,同時要用到面向對象建模的項目,只要軟件開發團隊中具有高素質的管理者,開發人員之間協作模式良好,那么迭代開發模型將是很好地開發方式。

? ? 1.2.2優點

? ? ? 由于將整個大項目變成了若干個小項目的迭代和,因而迭代模型很大程度上降低了項目開發過程中在一個增量上的開支風險,倘若開發人員在某一迭代上出現了問題,也只會在此個迭代上進行風險的評估,對于其他迭代的影響不大。另外該模式降低了產品無法按照既定進度進駐市場的風險,因為在迭代的早期我們就可以預估出開發過程中面臨的風險,從而提早作出規劃,避免了開發過程中遇見風險后的手忙腳亂導致的一系列難以預料的問題。迭代風險通過不斷的迭代加快了開發人員的開發效率,因為在迭代的過程中會有一個不動點,開發人員只要把握準這個不動點,就可以確定問題的焦點所在,從而進行高效率的開發,加快項目工作的進度。而相對于單純的瀑布模型,迭代模型對于用戶的需求更改則顯得更為適應,在這種模型下,用戶的需求在開發前期并不十分明確,并且常常隨著開發過程的進行在不斷變化,迭代的過程也正是對新需求的適應過程,完美的解決了用戶需求的更改與產品開發之間的沖突問題。

? ? 1.2.3缺陷

? ? ? 迭代開發由于要進行不斷的迭代來完善產品,以適應用戶的需求變化,因而如果用戶的需求相對較為固定,如果仍然采用邊寫邊重構的方式進行開發,無疑會增加很多無謂的重復工作。加之在迭代前期對產品的形態缺乏最終概念的時候,如果對于迭代的方向把握不準確則很容易偏離最初的意圖,造成不必要的損失,因而迭代開發模式更加要求開發人員的設計水平以及全局觀念,更需要一個較強的架構師進行架構管理,這也是迭代開發的一個難以普及的難點。

? 1.3其他模型

? ? 1.3.1快速原型模型

? ? ? 快速原型模型是在開發真實系統之前先構造一個系統原型,并在該原型的基礎上進一步地逐漸進行整個系統的全面開發工作。開發原型的過程事實上也是與用戶進行交互的過程,獲取用戶對原型的評價,從而在后續的開發過程中根據評價有針對性的對系統作出調整和修改,使其一步一步滿足用戶的需求。該模型克服了瀑布模型的缺點,減少了由于軟件需求的不明確而帶來的開發風險,但與此同時快速建立的系統模型結構以及重復多次的連續修改會使得產品的質量相對較低,并且限制了開發人員開發項目的創新性。

? ? 1.3.2螺旋模型

? ? ? 螺旋模型以前面幾個模型為基礎,基于一個快速形成的模型,以進化的開發方式為中心,定義了四個項目階段,并且在每個階段周期都采用迭代開發的方法,使得軟件開發路徑沿著螺旋線迭代前進,從而帶來了層次的不斷遞進。螺旋開發強調了風險的分析,它要求每個開發人員都要了解每一個層次可能出現的風險,并且及時對風險進行分析,采取相應的措施,減少風險帶來的損害。螺旋模型很好的解決了開發高風險系統的軟件開發過程的實現。

2.敏捷軟件開發模式

? 2.1何為敏捷開發

? ? ? 所謂敏捷開發,自然是相對于“非敏捷開發”而言的。而相比“非敏捷開發”,敏捷開發最重要的就是程序員團隊與業務專家之間的緊密合作、團隊成員之間的面對面的溝通交流以及頻繁的軟件版本的交付。而這樣的軟件開發方式極大地適應了當前社會情形下用戶需求不斷更改的特點,敏捷開發可以對用戶的新要求迅速作出反應,適合小規模團隊開發軟件使用,更凸顯了每個“人”在軟件開發周期中的作用。

? 2.2敏捷開發的特點

? ? ? 在敏捷聯盟的官方網站上,我們可以看到這樣的四句宣言:個人與溝通勝過過程與工具;可工作的軟件勝過面面俱到的文檔;客戶協作勝過合同談判;相應變化勝過遵循計劃。這四句話完美的概括了敏捷開發的四個特點,體現了使開發團隊快速工作并具有應變能力的價值觀和原則。敏捷開發看重團體中每個“人”的作用,強調每個開發人員相互之間的溝通與協作,開發過程和開發工具在“人”的面前就要稍低一等。而這個“人”也不僅僅指的是開發人員,還包括了需要服務的客戶,核心思想就是以本設計團體為中心,和外界各類人員進行配合。敏捷開發重視的是實際產品的開發與交付,一個能實際工作的軟件遠遠要好于求全責備的各種文檔。另外敏捷開發注重交互,尤其是與用戶之間的交互,開發人員根據用戶的需求的變化,不斷調整軟件的功能為用戶提供不同版本的可運行的軟件。

? 2.3開發原則

? ? ? 敏捷開發事實上是基于用戶需求的一種開發方法,因而開發的深度應當隨用戶的需求的不斷展開而逐步深入。因而在項目開發的初期,敏捷開發不提倡過度的需求分析,保證對需求的變化的響應是動態且及時的。另外敏捷開發的項目在設計上應當分為數個迭代周期,在每個周期內都應當產出可交付的軟件產品,并且將用戶的反饋作為下一次迭代開發的基礎。總結來說,可交付的可執行軟件是評判敏捷開發項目進展以及成果的最主要的依據,而整個開發過程又是自反饋的,這種迭代式的自反饋使得開發的過程也是不斷改進,不斷完善的過程。

? 2.4開發流程

? ? ? 敏捷開發大體上將項目管理開發的生命周期分為了三個階段,分別為項目規劃階段、項目啟動階段以及迭代開發與發布階段。項目規劃階段類似于傳統開發過程中的可行性分析和需求分析階段,在這一階段內開發人員需要確定軟件開發的計劃以及對客戶的需求進行初步的了解分析。項目啟動階段是一個過渡階段,用于軟硬件環境的準備、開發場地布置、資源準備等等。在必要的情況下還可以對前一階段的需求分析進行更詳盡的處理。迭代開發與發布階段是整個流程的核心部分,項目組會根據目標系統的發布版本,將這一階段分成多個迭代重復的過程,并且每一次的過程都是一次目標系統的增量在開發環境中實現,并從開發環境到生產環境進行遷移。這里需要強調的是在這個階段里最重要的過程既不是開發過程,也不是測試過程,而是常常被傳統開發過程所忽視的發布過程。因為在敏捷開發模型中,產品的第一次發布會在較早的時間產生,而這個版本的發布會對客戶的投資以及市場的反饋還有后續的項目走向調整產生重要的意義。

? 2.5優點

? ? ??敏捷開發采用了簡單的計劃策略,因而開發的周期較短,適合于中小規模項目的開發。并且在敏捷開發的整個開發過程中,我們都采用了迭代增量開發,不斷反饋修正,不斷測試的方法,既有力的保障了軟件的質量。最重要的一點是敏捷開發很好地適應了用戶瞬息萬變的需求,能夠做到及時響應,及時調整,為用戶能夠提供高質量的軟件。

3.敏捷開發模型與傳統軟件開發模型的對比

? 3.1與瀑布開發模型的對比

?

? ? ?圖 3 - 1

?

? ? ? 瀑布模型將軟件開發周期分為六個基本活動,并且規定了其自上而下的銜接順序,雖然這樣的開發方式易于使用并且方便實用,但是很難表達出用戶的需求,不適應于需求的變化。

? ? ??圖 3 - 2

?

? ? ? 敏捷開發以人為核心,將軟件項目切分成多個子項目,各個子項目都經過測試,具備集成和可運行的特征,即把大項目分解成為多個相互聯系但也可以獨立運行的小項目,在這個過程中,軟件一直處于可運行的狀態。

? 3.2與迭代開發模型的對比

? ? ? 敏捷開發與迭代開發都強調在較短的開發周期內提交軟件,但是基于Scrum的迭代開發卻會在一個較長的迭代周期頻率下不斷交付。在迭代開發的過程中我們不允許有不斷改變的需求,否則迭代的方向會不停的改變,使得偏離預想的路線,因而在這樣的一些場景下就會使得迭代變得十分困難。與此同時,迭代開發在項目的估算方面難度很大,導致對項目的安排缺乏宏觀性,不容易作出相關的一些承諾。相比較而言敏捷開發則是適應型的開發方法,更有利于處理變化的需求,而其具備的小團隊的特點則有利于開發人員之間的溝通交流以及用戶代表與開發團隊之間的交流,這種交互是很關鍵的反饋模式。“人與交互”帶來的是知識的迅速傳播以及思維共享。

? 3.3與螺旋開發模型的對比

? ? ? 與螺旋開發模型相比,敏捷開發的方法強調更多的是適應性而非預見性。螺旋開發的本質是將瀑布模型和快速原型模型結合起來,并且對其他模型所忽視的風險加以分析,因而適用于大型的系統。螺旋模型的特點在于我們不需要在開始的時候就完全定義清楚客戶的需求以及軟件開發的基線,我們只需要定義清楚最主要的功能,然后不斷的迭代,從客戶的意見與反饋修正迭代方向,從而完善軟件的功能。我們可以這樣認為,螺旋開發模型很大程度上是由風險驅動的,我們不可能在不對每個階段進行風險評估的情況下進行循環迭代,因而在螺旋開發的模型中,風險評估往往是很重要的一部分。而對于敏捷開發來說,在整個開發周期內,很多情況的發生都具有不可預見性,因而敏捷開發強調的不是風險的預估而是對風險的適應,如何快速集中地適應發生的變化,才是敏捷開發最需要研究的問題。

? 3.4與CMMI模型的對比

? ? ? CMMI標準是目前對軟件組織能力進行評價時使用的最為廣泛的模型,它能夠規范軟件開發的過程,并且產生和維護大量的文檔,所以被稱為“重載方法”,與此相對,敏捷開發因為其較高的軟件開發效率而被稱作“輕載方法”。雖然敏捷開發能夠提高軟件開發的效率,克服了傳統軟件工程中認識和實踐上的弱點,但是其本身也存在很多不足,比如在工程上和管理過程上缺乏一致性和充分性的考慮,并且常常只使用于中小型軟件的開發,對于大中型的軟件支持不足。因而在某種意義上來說,CMMI與敏捷開發既是對立的,也是是互補的。CMMI是一個非常好的框架,它強調了機構性的過程管理,但是如果沒有很好的理解和正確的實施,常常會造成不必要的浪費和損失。敏捷開發強調的是可實現功能的軟件,追求開發的效率,盡量縮短開發周期,并且開發是面向非結構性的,具有應變的時間。

? 3.5宏觀對比

? ? ? 總結而言,敏捷開發一部分程度上是基于傳統的開發方法而改進的,但它能夠吸收其他方法的優點,而盡量減少其缺點,正所謂融百家之所長。然而在繼承的基礎上,敏捷開發也很好地做到了改進。

? ? ? 比如在分工方面,傳統方法階段的劃分分明,一般來說不同階段的工作由不同的人來完成,每個人都有標準的分工。但是對于某些需要全體成員積極參與的項目比如課程設計或者畢業設計這樣的項目,采用傳統的方法意味著告訴前面已完成工作的開發人員不必要再關注后續部分的工作,這樣既降低了所有人的項目參與度,也不利于互相之間的交流學習。敏捷開發很好地解決了這個問題,團隊的每個成員從與客戶的交互到代碼的編寫,都需要親身體驗,這就保證了各個成員的參與度。

? ? ? 又比如在用戶需求方面,傳統方法常常要求用戶提供明確的需求,并且開發人員也只能在正確的需求條件下才能完成正確的開發。但是我們都知道一方面是因為計算機的發展速度之快,以致于固定的需求已經不再是軟件的基本要求,而應當是跟隨市場的反饋而追求不斷的變化與創新,隨著時間的推移而產生巨大的變化,另一方面是顧客與開發人員之間的溝通可能存在不到位的情況,致使理解出現了偏差,導致對需求的明確度不高。所以傳統開發模型對于變化的需求不能很好地適應,這一點遠遠比不上敏捷開發極強的適應性。

? ? ? 還比如多數傳統的開發方法是由文檔驅動的,在開發的每一個階段都需要相應的文檔進行總結分析,并指出后續的開發要點,因而如果前面的階段沒有完成或是沒有及時編寫文檔,開發人員是無法繼續進行下一階段的工作的。敏捷開發則不同,它是由功能驅動的,因而重點在于每一階段的測試工作的完成,這很有利于小規模團體之間的交流協作與提升開發興趣。

? ? ? 再比如說傳統開發方法中對于顧客的定位是觀察者,而不是參與者,這就決定了顧客與開發團隊之間的利益博弈的關系,用戶的參與度不高,常常導致開發團隊交付的軟件與用戶預想的結果有較大的差異。在敏捷開發模型中,顧客與團隊是相輔相成的,顧客可以直接參與軟件的開發過程并及時提出相應的修改意見,一旦有了交互的過程,就意味著開發出來的軟件具有極高的適用性,能夠促進客戶與團隊之間關系的良性循環。

? ? ? 最后我們看看軟件模塊的集成。傳統開發方法的的集成工作常常會堆在開發的末期進行處理,這就使得在集成的過程中如果出現問題的話很難有足夠的時間進行調試和修改,而敏捷開發在每個階段都會有一次模塊的集成,每一次的集成對于軟件的改動相對較小,因而發現問題可以及時定位糾正。事實上,敏捷開發的測試往往是自動化的,所以這也給開發人員減輕了很多壓力與負擔。另外,傳統軟件開發的周期比較長,獲得可執行軟件的時間也比較晚,而敏捷開發的周期較短,并且很早就能獲得第一版可執行軟件,留給用戶進行反饋的時間也比較充分。

? ? ? “取其精華,去其糟粕”,這是敏捷開發方法之于傳統軟件開發方法之間最重要的區別與聯系。

4.新軟件形勢下的敏捷開發

? 4.1實現敏捷開發在實際項目中的應用

? ? 4.1.1國內軟件開發環境

? ? ? (1)中小型企業較多,大中型企業較少,很多企業開發的項目達不到所預期的效果;

? ? ? (2)多數公司對于軟件開發的測試過程不夠重視,不足以應對敏捷開發所要求的測試技能以及需求的變化;

? ? ? (3)無論是什么開發方式都要求團隊之間的配合度和和諧性,但是很多團隊目前的默契度不足以支持敏捷開發的各個階段;

? ? ? (4)目前很少有企業領導對敏捷開發方式有足夠高的重視度,如果不能自上而下的實行,底層開發團隊往往有心無力;

? ? ? (5)中小型公司缺乏相關的專業人才,很難普及相應的模式;

? ? ? (6)公司常常注重的是個人能力,相信的是少數人的能力,以此來保證軟件的開發,但是這種信任則是冒著很大的風險;也有的公司更加看重項目的流程,對項目本身的效率造成了很大的影響,難以產生高的效益。

? ? 4.1.2敏捷開發與企業架構的兼容性

? ? ? 我們知道敏捷開發常常適用于中小項目的開發,并且開發團隊以3-5人為宜,而這顯然是與傳統企業的架構是格格不入的。但是面對著客戶需求由“單一化”到“動態化”的新型軟件格局的普遍化,傳統軟件工程的開發方法受到了相當嚴重的打擊。我們知道傳統的軟件開發模型大多都是線性流程,這種流程帶來的最大的問題就是架構單一,難于變通和創新。因而敏捷開發的思想在當前的環境下就顯得格外重要。那么敏捷開發如何實際應用于傳統軟件企業當中呢?事實上敏捷開發與企業架構是可兼容的,但是我們需要為之付出不小的努力。從目標來看,企業架構以及敏捷開發的目的都是向顧客交付功能與需求對齊的高質量軟件,并且不斷響應過程中需求的變更,然而兩者的實現方式截然不同。事實上從某種程度上來講,對于一項工程,無論是哪種開發方式的缺失都有可能帶來一些微小的問題。比如對于一個文檔處理系統來說,僅僅使用敏捷開發方式雖然效率很高,但是很難協調處理好企業架構的需要,類似跨越需求,接口或是操作性的問題。或者比如說一個使用瀑布模型開發的系統,很完美地處理好了企業架構的問題,但是卻不能在較早的時間向客戶展示系統的價值,也幾乎不可能通過迭代解決可能遇到的風險。所以均衡這兩者是軟件開發最為平衡的模式。我們可以這樣實現二者的均衡:對于一個敏捷開發團隊,它可以屬于一個企業架構組,團隊中的成員有必要與組內成員互相交流,互相聯系。敏捷開發在保證自身工作完整性的條件下兼容組織架構的運行,使得兩者相互包容,和諧相處。

? ? 4.1.3敏捷開發與CMMI模型的共存

? ? ? 在這里我們需要強調兩個概念,融合與共存。

? ? ? 什么是融合?一杯牛奶和一杯咖啡,各取半杯混成一杯,這就叫融合。但是融合成的這一杯牛奶咖啡真的好喝么?也許合適的比例下得到的產物味道很好,但是這樣能夠給予我們多大的好處呢?對于敏捷開發和CMMI來說,融合并不是一個好的選擇,因為一旦融合就意味著必然有一者會消失被另一個吞并,或是兩者都消失,轉化成新的東西。從理論上來講,CMMI與敏捷開發兩個行業的差別很大,所解決的問題,所要面臨的問題以及自身的客觀規律也都相差很大,而CMMI與敏捷開發在行業中的定位僅僅只是方法,因而如果不能使得行業本身或是其自身規律融合,僅僅只有方法的融合,這是不協調的。目前的狀況是我們很難找到不同問題之間的融合點,因而這兩個方法之間的融合也成了無稽之談。

? ? ? 不能融合并不代表不能共存。什么是共存?老虎獅子各自在自己的領域中活動,必要時相互協作,這是共存。CMMI與敏捷開發的關系就如同家里的桌椅之間的關系,桌子和椅子單獨使用總是不能夠盡善盡美,但是也沒有什么融合的必要,而如果桌椅擺放在一起就能協調運轉,完成相應的功能。

? ? ? 所以在兩者可以共存的前提下,我們需要考慮的是面對什么項目應當選取哪種開發方式,在哪些階段使用哪種開發方式,兩者能否結合使用這些問題。我們可以通過一些切入點來思考這些問題:

? ? ? (1)??? 明確軟件整體的發展方向,認準軟件發展形勢,在提高自身競爭力的前提下選擇合適的開發模式;

? ? ? (2)??? 根據企業自身的規模以及發展情況適當選取模型,拿小型公司來說,CMMI對于企業劃分成五個等級,小公司自身處于CMMI所規定的等級中的較低級,在這樣一種情況下貿然采用敏捷開發是有相當大的風險的。而對于中等規模的公司來說,在項目過程達到要求的情況下可以適當選擇敏捷開發以提升開發的效率。對于大公司來講,大公司講究的是企業的基礎和文化,并且擁有優秀的開發和測試人員,因而最好不要輕易的改變自身的項目開發模型,但是可以現在小型項目上進行試驗,以此來積累經驗減小風險。

? ? ? (3)??? 對于特定的項目開發,我們如果既能符合CMMI的規范,又能采用敏捷開發提高效率,那當然是再好不過了,這樣我們便可以獲得真正意義上的開發的可重復性以及成本風險的可預測性等等好處。

? ? ? (4)??? 采用敏捷開發一定要考慮到自身的利益,以及未來發展的期望,目光長遠才能穩定發展,不能急功近利,只看眼前。

? 4.2敏捷開發在項目開發中的要點

? ? ? 近些年來,越來越多的開發團隊開始采用敏捷開發的開發方式對軟件進行開發,并且取得了較好的效果。而敏捷開發模型其實也是一把雙刃劍,合理利用可以極大的提升開發的效率,一旦沒有把握開發中的要點,有可能帶來資源的浪費以及成本的損失。所以對于敏捷開發人員來說,需要在開發周期中重視下面幾個要點,這些要點也常常與傳統開發方式的要點相反:

? ? ? (1)??? 敏捷開發需要重視概念和架構的設計,適當看淡產品的詳細設計,強調的是產品的路線規劃、市場趨勢、客戶價值、技術趨勢、實現方式、層次分布、層次關系設計等,而不是具體的設計和做法以及API接口;

? ? ? (2)??? 建立系統化的分析方法,對產品進行SWOT分析,注重客戶的需求,適應市場的變化;

? ? ? (3)??? 開發由業務和客戶進行驅動,而不應由開發技術進行驅動,或者說不要從技術方面盲目的擴大需求,這種需求往往并不是客戶真正想要的需求。另外就是敏捷開發雖然擁抱變化,但不歡迎盲目的變化,它崇尚簡單的設計而不是顛覆性的設計,意味著如果我們需要做出一些改動,務必保證版本遷移的平滑性; ?

? ? ? (4)??? 測試優先,在編碼之前應當先編寫測試。與傳統的開發模型恰恰相反,先編寫測試用例,既是一種驗證,更是一種設計,在這個過程中,我們可以發現某些需求設計上的缺陷從而便于更改需求和設計,避免付出無謂的勞動,造成無意義的浪費;

? ? ? (5)??? 時刻考慮版本的兼容性,當設計變動的時候,要時刻考慮產品的架構,產品的規劃以及上一個版本的兼容性,以方便后期的維護工作;

? ? ? (6)??? 不看重的文檔,但并不意味著不撰寫文檔,敏捷開發重視溝通,文檔也是溝通的一種方式。敏捷開發所排斥的是開發過程中的冗余文檔,有利于節省大量的時間和成本;

? ? ? (7)??? 敏捷開發提倡溝通,溝通才能使效益最大化,這里的溝通既包含了團隊內開發人員的相互溝通,更包括了開發人員與客戶之間的溝通,溝通的效果會直接影響軟件的質量、成本以及軟件能否順利交付;

? ? ? (8)??? 時刻保證開發團隊的活力與激情,只有這樣才能隨時適應需求等設計的變化,從而做出更高質量的軟件。

5.總結

? ? ? 在當下日益發展的計算機軟件環境下,敏捷開發已然成為軟件開發者不可或缺的一種開發模式,當然其自身仍然存在著一些尚未解決的缺陷,而我們要做的就是合理運用敏捷開發的模式,并與傳統開發模式相結合,因地制宜,對癥下藥,這樣才能有效地降低開發的成本,提高開發的效率,適應軟件社會的發展趨勢。

6.參考文獻

[1] 張林、張德勇,敏捷開發在軟件產品項目中的應用實踐[A].2011.

[2] Roger S Pressman,軟件工程-實踐者的研究方法[M].北京:機械工業出版社,1999.

[3] Jakobsen C R,Sutherland J.Scrum and CMMI going from good to great[C].Chicago,IL:IEEE,2009:333-337.

[4] 鄧輝,敏捷軟件開發:原則、模式與實踐.清華大學出版社,2003:9,132.

[5] 蘇敬凱,敏捷軟件開發[M].機械工業出版社,2008,1.

[6] CMMI Product Team. CMMI for development,version 1.2[M].Pittsburgh:Carnegie Mellon University Software Engineering Institute,2006.

轉載于:https://www.cnblogs.com/ztc14061055/p/5985127.html

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/254155.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/254155.shtml
英文地址,請注明出處:http://en.pswp.cn/news/254155.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

Linux中的cron計劃任務配置詳解

cron來源于希臘單詞chronos&#xff08;意為“時間”&#xff09;&#xff0c;指Linux系統下一個自動執行指定任務的程序&#xff08;計劃任務&#xff09; ####1. crontab命令選項代碼如下: #crontab -u <-l, -r, -e> -u指定一個用戶 -l列出某個用戶的任務計劃 -r刪除某…

new和delete

和 sizeof 類似&#xff0c;sizeof不是函數&#xff0c;它是一個操作符&#xff0c;它在編譯期就完成了計算&#xff0c;在函數運行期間它已經是一個常數值了。 int a;sizeof(int) 4;sizeof(a) 4;sizeof a ——也是4 不需要括號&#xff01;此時要注意&#xff1a;sizeof in…

char a[]和char *a的比較,數組名,數組首地址,a,a,a[0]

char a[]和char *a的比較 指針和數組存在著一些本質的區別。當然&#xff0c;在某種情況下&#xff0c;比如數組作為函數的參數進行傳遞時&#xff0c;由于該數組自動退化為同類型的指針&#xff0c;所以在函數內部&#xff0c;作為函數參數傳遞進來的指針與數組確實具有一定的…

Java中繼承thread類與實現Runnable接口的區別

Java中線程的創建有兩種方式&#xff1a; 1&#xff0e; 通過繼承Thread類&#xff0c;重寫Thread的run()方法&#xff0c;將線程運行的邏輯放在其中 2&#xff0e; 通過實現Runnable接口&#xff0c;實例化Thread類 在實際應用中&#xff0c;我們經常用到多線程&#xff0c;…

【VMware vSAN 6.6】6.2.啟用性能服務:vSAN硬件服務器解決方案

目錄 1. 簡介 1.1.適用于HCI的企業級存儲2. 體系結構 2.1.帶有本地存儲的服務器2.2.存儲控制器虛擬系統套裝的缺點2.3.vSAN在vSphere Hypervisor中自帶2.4.集群類型2.5.硬件部署選項3. 啟用vSAN 3.1.啟用vSAN3.2.輕松安裝3.3.主動測試4. 可用性 4.1.對象和組件安置4.2.重新構建…

Android eclipse導入項目后出現Unable to resolve target #39;android-17#39;解決方法

eclipse導入項目后出現Unable to resolve target android-17解決方法。在最后附帶還有一種編譯邏輯不成功情況解決方法。 一、問題情況 二、解決的方法 1、改動項目的目標版本號與當前Android sdk相相應的版本號 2、自己主動修復一下項目 三、這個問題不是上面的。是另外情況&a…

多個圓點,鼠標選取兩個,求兩個點的距離,用于計算像素尺寸(halcon實現)

read_image (Image, C:/Users/22967/Desktop/晶圓找位置/0.bmp) dev_close_window () dev_open_window_fit_image (Image, 0, 0, -1, -1, WindowHandle) dev_display (Image)binary_threshold (Image, Region1, max_separability, dark, UsedThreshold) connection (Region1, C…

修改UBOOT和LINUX調試串口(TI達芬奇芯片--DM6467)

Posted on 2011-10-31 10:53 jamiedu 閱讀(889) 評論(0) 編輯 收藏 1.1 概述 TI針對DM6467提供的UBOOT和內核默認都是串口0作為調試串口輸出的&#xff0c;但現在我需要使用DM6467的UART0的modem功能&#xff0c;所以修改代碼&#xff0c;改變調試串口為串口2。 需要修改的主要…

Java List與數組之間的轉換

http://blog.csdn.net/kingzone_2008/article/details/8444678轉載于:https://www.cnblogs.com/longshiyVip/p/5985981.html

受歡迎的五個開源可視化工具——你的選擇是?

摘要&#xff1a;大數據時代&#xff0c;數據為王&#xff0c;還在對一堆數據而發愁嗎&#xff1f;試試可視化工具吧&#xff0c;相信本文提到的五款工具有一款能夠幫助到你。人工智能時代&#xff0c;數據和算法以及硬件資源是非常重要的&#xff0c;相關行業的大公司也越來越…

halcon車刀崩邊檢測

list_files (新建文件夾, files, Files) read_image (Image, Files[0]) dev_close_window () get_image_size (Image, Width, Height) dev_open_window (0, 0, Width/1.5, Height/1.5, black, WindowHandle) dev_set_draw (margin) dev_set_colored (12) for Index:0 to |Files…

FFMPEG解碼264文件步驟

本文以H264視頻流為例&#xff0c;講解解碼流數據的步驟。 為突出重點&#xff0c;本文只專注于討論解碼視頻流數據&#xff0c;不涉及其它&#xff08;如開發環境的配置等&#xff09;。如果您需要這方面的信息&#xff0c;請和我聯系。 準備變量 定義AVCodecContext。如果…

Storm概念學習系列之storm的特性

不多說&#xff0c;直接上干貨&#xff01; storm的特性 Storm 是一個開源的分布式實時計算系統&#xff0c;可以簡單、可靠地處理大量的數據流。 Storm支持水平擴展&#xff0c;具有高容錯性&#xff0c;保證每個消息都會得到處理&#xff0c;而且處理速度很快&#xff08;在一…

Confluence 6 配置服務器基礎地址示例

2019獨角獸企業重金招聘Python工程師標準>>> 如果 Confluence 的安裝是沒有安裝在非根目錄路徑&#xff08;這個是上下文路徑&#xff09;&#xff0c;然后服務器基礎 URL 地址應該包括上下文地址。例如&#xff0c;你的 Confluence 正在運行在下面的地址&#xff1…

BootstrapValidator驗證

bootstrap&#xff1a;能夠增加兼容性的強大框架. 因為項目需要數據驗證&#xff0c;看bootstrapValidator 還不錯&#xff0c;就上手一直&#xff0c;完美兼容&#xff0c;話不多說。 需要引用css&#xff1a; bootstrap.min.css bootstrapValidator.min.css js: jquery-1.10.…

基于ARM9的視頻采集傳輸系統

http://www.ic37.com/htm_tech/2007-11/77189_618093.htm

halcon找矩形頂點的一種方法

主程序&#xff1a; read_image (Image11, 11)*畫仿射矩形 dev_set_color (green) draw_rectangle2 (3600, Row, Column, Phi, Length1, Length2)*生成仿射矩形xld gen_rectangle2_contour_xld (Rectangle, Row, Column, Phi, Length1, Length2) *找頂點工具&#xff08;基于卡…

老男孩linux運維50期

一、自我介紹&#xff1a;我是來自老男孩Linux運維脫產50期的楊國峰&#xff0c;我以前是學軟件編碼的&#xff0c;但在大學里基本沒怎么學&#xff0c;每一門課都一知半解的&#xff0c;甚至有些連軟件都不會裝&#xff0c;在校期間&#xff0c;我對JAVA、網頁設計等都不感興趣…

博客收藏

http://www.dreamfairy.cn/blog/category/unity3d/轉載于:https://www.cnblogs.com/wantnon/p/5989843.html

移動開發平臺性能比較

jquerymobile是一個mobile平臺下的js框架,跟phonegap沒有一毛錢關系.phonegap實際上在國內占有率不高的,非常多人為了體驗喜歡做傳統的原生手機應用. 而Webapp如今的占有率越來越少,由于越來越多的人不喜歡用手機瀏覽器去體驗專門為移動平臺搭建的站點.我認為你的比較對象應該是…