費(fèi)寧

摘 要：當(dāng)前，新軟件工程開發(fā)方法開創(chuàng)了軟件全生命周期的協(xié)作化生產(chǎn)的組織、管理及運(yùn)行新模式，本文面向敏捷開發(fā)，設(shè)計(jì)了一個多種軟件工程開發(fā)方法的試驗(yàn)平臺，從而證明若項(xiàng)目需求固定，合適瀑布型。而需求更新比較快，則適合靈活的敏捷開發(fā)模式，同時培養(yǎng)學(xué)生實(shí)踐創(chuàng)新能力和團(tuán)隊(duì)能力。

關(guān)鍵詞：敏捷開發(fā) 瀑布模型 軟件開發(fā)

中圖分類號：G71 文獻(xiàn)標(biāo)識碼：A 文章編號：1672-3791（2013）03（c）-0203-01

要想使高校培養(yǎng)出來的學(xué)生能夠滿足企業(yè)的需要，就要不斷緊跟企業(yè)，甚至要走在前面，即及時更新技術(shù)手段，加強(qiáng)自身的實(shí)踐能力。當(dāng)前，一些軟件公司已經(jīng)不再是采取簡單的瀑布模型，新的觀點(diǎn)，新的軟件開發(fā)模式，層出不窮。作為從事軟件開發(fā)的畢業(yè)生，僅僅知道瀑布模型是遠(yuǎn)遠(yuǎn)不夠的，對軟件工程的深入理解，了解技術(shù)前沿才能使我們培養(yǎng)出來的學(xué)生盡快的適應(yīng)社會和企業(yè)的選拔。

1 敏捷開發(fā)對軟件工程人才培養(yǎng)的作用

1.1 軟件開發(fā)模型

軟件開發(fā)過程是隨著開發(fā)技術(shù)的演化而隨之改進(jìn)的，從瀑布開發(fā)模型到最近開始興起的敏捷開發(fā)方法，展示出了在不同的時代軟件產(chǎn)業(yè)對于開發(fā)過程的不同的認(rèn)識，以及對于不同類型項(xiàng)目的理解方法。

瀑布模型（Waterfall Model）于1970年提出的，大型軟件開發(fā)可分為：分析與編程。其主旨是把軟件工程分成各種工序，每個工序可以進(jìn)一步細(xì)分成更小的工序。該模型成為軟件開發(fā)企業(yè)使用最多的開發(fā)模型。瀑布模型的特點(diǎn)一是強(qiáng)調(diào)文檔，二是對反饋沒有涉及。目前針對瀑布模型的反對意見不少，原因主要是：瀑布模型過于呆板，不適合需求不斷變化的軟件開發(fā)；同時，重復(fù)性的工作使得開發(fā)者無法得到新的學(xué)習(xí)和鍛煉。

敏捷開發(fā)（agile development）概念由2001年17名編程大師發(fā)表的“敏捷軟件開發(fā)”宣言得來。敏捷開發(fā)強(qiáng)調(diào)：1）編程中開發(fā)者的自我特長發(fā)揮；2）軟件開發(fā)的產(chǎn)品是軟件，而不是文檔；3）客戶與開發(fā)者的關(guān)系是協(xié)作，而不是互相制約的關(guān)系；4）要適應(yīng)客戶需求的變化，同時能根據(jù)環(huán)境的變化，修改自己的設(shè)計(jì)。敏捷軟件開發(fā)是一個新的開發(fā)軟件管理模式，其關(guān)注點(diǎn)從文檔轉(zhuǎn)移到開發(fā)者，管理方式也從流水線轉(zhuǎn)移到團(tuán)隊(duì)的自我放松式組織[1]。

1.2 軟件工程人才培養(yǎng)的新思路

眾所周知，當(dāng)今的軟件已經(jīng)成為多人參與、分工明確、通力協(xié)作的大型工程。是使用傳統(tǒng)的瀑布模式，還是新穎的敏捷開發(fā)模型，還是將兩者結(jié)合，是軟件開發(fā)組織者面臨的新課題，這顯然就需要利用軟件工程的思想和方法。

在實(shí)踐傳統(tǒng)和前沿軟件工程的基礎(chǔ)上，根據(jù)具體情況選擇最合適的軟件工程實(shí)施模式很重要，教會學(xué)生如何思考這些問題才是關(guān)鍵。所以，應(yīng)該讓學(xué)生不停地自我詢問：如果要完成這個項(xiàng)目，會選擇什么語言，什么操作系統(tǒng)，什么環(huán)境？如果是項(xiàng)目開發(fā)人員，在某種特定的情況下，會選用什么樣的開發(fā)模式，什么樣的算法，什么樣的系統(tǒng)體系結(jié)構(gòu)？本課題的主旨就是讓學(xué)生在不斷自建自檢的過程中，理解不同的開發(fā)模式的優(yōu)劣，以及在何種情況下，應(yīng)該使用何種開發(fā)模式。

2 軟件開發(fā)教學(xué)試驗(yàn)平臺設(shè)計(jì)的實(shí)施過程和成果

教學(xué)計(jì)劃中有課程設(shè)計(jì)，主要是組織學(xué)生進(jìn)行相關(guān)企業(yè)級項(xiàng)目的開發(fā)。這個過程中，讓學(xué)生理論聯(lián)系實(shí)際，加深對軟件開發(fā)流程的理解。具體步驟如下：首先把學(xué)生分成兩組，一個小組按傳統(tǒng)瀑布模型開發(fā)，另一個小組按敏捷模式開發(fā)。對于敏捷開發(fā)小組，下一步是選擇出一個項(xiàng)目負(fù)責(zé)人，其余成員構(gòu)成團(tuán)隊(duì)[2]。然后，團(tuán)隊(duì)一起制定計(jì)劃，項(xiàng)目負(fù)責(zé)人為大家說明項(xiàng)目需求的優(yōu)先級順序，團(tuán)員可以提出疑問，團(tuán)隊(duì)一起尋求答案，同時補(bǔ)充項(xiàng)目描述或調(diào)整優(yōu)先級。在一問一答中，整個團(tuán)隊(duì)對項(xiàng)目有一個認(rèn)識，同時達(dá)成共識，即對項(xiàng)目的規(guī)模進(jìn)行估算，這有利于任務(wù)按時進(jìn)行。敏捷開發(fā)過程中，每天固定舉行簡短的“每日站立會議”；會議在固定地點(diǎn)和固定時間舉行；在會議上，每個團(tuán)隊(duì)成員需要回答三個問題：今天完成了哪些工作？明天做什么？完成目標(biāo)是否存在障礙[2]？

在項(xiàng)目實(shí)訓(xùn)中，選取了兩種類型的項(xiàng)目實(shí)例：一個是嵌入式平臺的中間件的開發(fā)；另外一個是企業(yè)網(wǎng)站遷移到Web 2.0。前一組需求復(fù)雜，但變化頻率比較少；后一組需求簡單，但改動頻繁。試驗(yàn)平臺按照人力資源的消耗，程序包含的bug數(shù)作為比較參數(shù)，從這兩個方面分析敏捷開發(fā)和瀑布模型的優(yōu)劣及適用的項(xiàng)目實(shí)例。

在嵌入式開發(fā)項(xiàng)目中，敏捷開發(fā)花費(fèi)的人力比瀑布模型高。分析得出：每日站立會議花費(fèi)了額外的時間，學(xué)生解釋自己的工作內(nèi)容并不容易。而瀑布模型需求分析充分，所以資源消耗明顯較少。在質(zhì)量上，敏捷編程的提高也并不明顯，因?yàn)榍度胧巾?xiàng)目模塊之間接口相對較少。但通過對bug根本原因的分析發(fā)現(xiàn)，敏捷開發(fā)中的結(jié)對編程有效地降低了學(xué)生編碼過程中的偶然性錯誤。對于項(xiàng)目二，需求更改的頻率顯著增加。此時，瀑布模型所花費(fèi)的人力資源遠(yuǎn)高于敏捷開發(fā)。因?yàn)槊看涡枨笞儎?，瀑布模型需要重新進(jìn)行需求分析、架構(gòu)設(shè)計(jì)和模塊設(shè)計(jì)和代碼編寫。而敏捷開發(fā)的及時溝通有助于需求的更改，同時降低代碼耦合性，采取功能邏輯和用戶界面分離的形式，有效地提高了效率。在軟件質(zhì)量方面，根據(jù)記錄發(fā)現(xiàn)，傳統(tǒng)瀑布型開發(fā)中的bug數(shù)較多，部分bug是對需求分析不夠透徹。

從試驗(yàn)結(jié)果得知：對于不同的項(xiàng)目可以采取相應(yīng)的開發(fā)模式。若項(xiàng)目需求固定，適合瀑布型。而對于創(chuàng)新型項(xiàng)目，需求更新快，則適合敏捷開發(fā)模式。要提供高效率的項(xiàng)目流程，要實(shí)行開發(fā)過程的有效管理，只有敏捷開發(fā)模型，或者只有瀑布模型是遠(yuǎn)遠(yuǎn)無法滿足千變?nèi)f化的需求的，所以針對項(xiàng)目的特點(diǎn)對兩種模型有所選擇，并有效融合，發(fā)揮各自長處，這才是重點(diǎn)。

3 結(jié)語

真正的軟件人才不再是寫代碼的程序員，而是整個體系結(jié)構(gòu)的分析、設(shè)計(jì)、標(biāo)準(zhǔn)制定、協(xié)調(diào)人員。所以在培養(yǎng)軟件工程人才時，應(yīng)該以人為中心，以項(xiàng)目類型為中心，軟件開發(fā)者能夠?qū)浖こ痰拈_發(fā)模型進(jìn)行正確的選擇，同時鍛煉學(xué)生們相互之間的協(xié)作能力，這也正是本課題的主旨。

參考文獻(xiàn)

[1]從瀑布模型、極限編程到敏捷開發(fā)[EB/OL].http：//wenku.baidu.com/view/0267645d804d2b160b4ec057.html.

[2]http：//baike.baidu.com/view/1528674.htm.

[3]http：//baike.baidu.com/view/309926.htm.

[4]Kim H.Pries，Jon M.Quigley.Scrum Project Management[M].CRC Press Inc，2010.