|
為什么我在這里主要討論迭代式軟件開發(fā),？本文在此拋開千篇一律的理論，擬就根據(jù)多年的實踐,，總結(jié)出一套比較務實,、可操作性強的方法，以期望在有限的資源下確保軟件質(zhì)量得到較大保證,。一家之見,，紕漏之處還請大家多多指正。 迭代式軟件開發(fā)模式簡要流程如下： 上圖綠色大框內(nèi),，我們就稱之為一個迭代周期,。每一個迭代，都可以形成一個可交付的小版本,。事實上,，每一個迭代周期內(nèi)，對于編碼和測試也可以進行多次迭代,。通過快速發(fā)布測試構(gòu)建的方式,，驗證開發(fā)完成的新功能，再通過測試發(fā)現(xiàn)問題來驅(qū)動開發(fā)人員對軟件進行修改完善,，循環(huán)往復,。即：根據(jù)開發(fā)情況有針對性地組織測試，根據(jù)測試結(jié)果反作用于開發(fā)人員去完善軟件質(zhì)量,。以這種小步快跑的方式,，經(jīng)過若干測試構(gòu)建后，軟件質(zhì)量可以在較短時間內(nèi)達到穩(wěn)定狀態(tài),。 質(zhì)量保證,，需要系統(tǒng)性的方法。那么在迭代式開發(fā)的各個階段,，都需要怎樣的措施呢,？ 1）需求 這個階段的主要工作是需求制定與評審。該階段的工作分三步走：收集原始需求 ->制定產(chǎn)品需求 -> 產(chǎn)品需求評審,。具體說來,，首先我們通過各種渠道收集原始需求，由于原始需求多半是概念性的,、模糊的,，不能直接用來指導開發(fā)工作,，所以需要進行歸類、篩選,，整合為產(chǎn)品需求,。基本原則是,，結(jié)合當前開發(fā)產(chǎn)品的特性,，爭取以最小的改動以及最大的可擴展性來制定產(chǎn)品需求。降低風險,，同時提高靈活性,。經(jīng)驗告訴我們，在需求沒有考慮透徹的情況下,，不要貿(mào)然開始設(shè)計并實現(xiàn),，可能導致大量返工，費時費力,。產(chǎn)品需求制定好后,，需要進行評審,，一定不要覺得浪費時間而不去評審,，磨刀不誤砍柴工嘛！ 2） 設(shè)計 這個階段的主要工作是將產(chǎn)品需求轉(zhuǎn)化為設(shè)計需求,，指導后續(xù)的編碼工作,。軟件行業(yè)有一名老話是：軟件質(zhì)量是設(shè)計出來的，對于迭代式開發(fā)也是如此,。設(shè)計的好壞直接決定了軟件質(zhì)量的高低,。設(shè)計需求一般闡述了產(chǎn)品需求的詳細設(shè)計方案，包括頁面布局,、數(shù)據(jù)結(jié)構(gòu),、算法以及易用性、安全性,、可擴展性,、健壯性和性能等諸多方面的設(shè)計思路。即使讓不同的開發(fā)人員根據(jù)設(shè)計需求來進行編碼,，開發(fā)出的功能也八九不離十,。有此可見，設(shè)計需求是非常必要的,。也就是說,，我們在正式編碼前，必須針對需求寫出相應的設(shè)計文檔來指導后續(xù)的編碼工作,。這樣做有兩大好處：一是在編碼之前就充分預見到將來可能遇到的問題,，可以盡早規(guī)避風險,；二是為開發(fā)工作搭好框架，降低因開發(fā)人員的差異導致開發(fā)過程的不確定性,，避免出現(xiàn)“一千個人心中有一千個對需求的理解”,。 3） 編碼 這個階段的主要工作是嚴格按照設(shè)計需求來完成編碼，并組織進行代碼評審,。每一行代碼都是軟件大廈的一磚一瓦,，我們拒絕豆腐渣工程，所以我們重視每一行代碼,。進行代碼評審可以有效保證代碼質(zhì)量,，借助一些IT管理工具可以輕松進行代碼評審和代碼管理。筆者曾經(jīng)使用過青銅器RDM軟件來做代碼評審（CodeReview）,，十分方便,。代碼評審的重點應該是對程序結(jié)構(gòu)的審查，發(fā)現(xiàn)深層次的軟件錯誤,，而不要停留在表面,。同時，建議大家在做代碼評審時,，以代碼的一個“提交”為單位進行評審,。這樣做的前提是，每個“提交”里包含相對完整的功能,。對于迭代式開發(fā),，我們要盡量保證，每一個編碼-測試迭代里,，都要完成相對獨立,、可測試性強的功能點。 4） 測試 測試實質(zhì)上是一種鑒定性的工作,，是對軟件質(zhì)量的鑒定和最后一道把關(guān),。這個階段的主要工作是，在每一個測試構(gòu)建中,，盡可能多地覆蓋需求點,，并根據(jù)輕重緩急合理安排測試優(yōu)先級，盡可能將影響較大的缺陷提前暴露出來,。測試優(yōu)先級的安排應遵循以下原則： a,、先測試經(jīng)過變更的部分，然后測試沒有變更的部分 b,、先測試程序的核心功能,，然后測試一般功能 c、先測試邏輯性的功能,，然后測試業(yè)務性的功能 d,、先測試常規(guī)情況,，然后測試異常情況 e、先測試功能,，然后測試性能 按照上述原則進行測試,，可以更快地發(fā)現(xiàn)更多軟件中的嚴重錯誤，這是使軟件能盡快穩(wěn)定下來的一個關(guān)鍵因素,。除此以外,，在每一個迭代周期結(jié)束之前還要進行系統(tǒng)測試。 編碼-測試的不斷迭代,，保證了每個測試構(gòu)建里的新功能沒有問題,，但整個軟件系統(tǒng)的質(zhì)量還沒有得到充分驗證，系統(tǒng)測試就是為此而生,。在版本發(fā)布前的最后沖刺階段,，“車輪戰(zhàn)”是很管用的一個手段，即：調(diào)集測試人員,、開發(fā)人員等全面參與測試,，將這些人員分為若干個小組，每個小組分別對系統(tǒng)進行測試,。每個測試模塊由多人進行測試,，可以有效降低缺陷的遺漏率。但需要注意的是,，開發(fā)人員應該避免測試自己開發(fā)的功能,，即進行交叉測試。 軟件質(zhì)量保證的實質(zhì)是,，使用一些流程、方法來管控軟件開發(fā)過程,，從而使最終交付的軟件產(chǎn)品質(zhì)量得到最大程度的保證,。同時，相信大家可以看出,，在整個產(chǎn)品開發(fā)過程中會產(chǎn)生很多數(shù)據(jù),，如需求、設(shè)計文檔,、代碼,、測試用例、缺陷等,。使用IT管理工具可以有效提高工作效率,，青銅器RDM全面實現(xiàn)CodeReview+Testlink + Mantis功能組合，可以管理需求,、測試用例,、缺陷,、代碼評審等，對于小規(guī)模團隊,，已經(jīng)足夠用了,。 |
|
|
