軟件企業(yè)如何“捉蟲”？

軟件缺陷（也稱Bug，俗稱臭蟲）是長期困擾軟件企業(yè)的一個問題，為了盡量減少“臭蟲”的侵襲，軟件企業(yè)也是煞費苦心。近來，美國的一些軟件公司開始采用應(yīng)用軟件生命周期管理，試圖消除軟件錯誤，以減少因此帶來的損失。

下述糟糕的經(jīng)歷屢見不鮮：

● 4月，一個軟件故障導(dǎo)致美國航空集團公司損失數(shù)千美元，因為有些機票的價格被誤定為1.86美元；

● 在最近的一次美國總統(tǒng)選舉中，使用新型計算機化投票系統(tǒng)的幾個選區(qū)傳出計票不正確的說法；

● 2003年8月導(dǎo)致北美東北部大規(guī)模停電事故的罪魁禍首也是一個軟件錯誤，數(shù)百萬人因此而陷入一片黑暗當中。

類似的事例還有很多。目前看來，軟件問題似乎正變得越來越糟。美國技術(shù)標準研究所經(jīng)常引用的一個數(shù)字表明，2002年存在缺陷的軟件讓美國經(jīng)濟虧損600億美元。如今這個數(shù)額更高，這點沒有人懷疑。

低劣的軟件幾乎困擾著每一個使用計算機的組織：導(dǎo)致計算機停用期間工作時間減少、錯失銷售機會、IT支持和維護成本居高不下、客戶滿意度低下。人們沮喪之余開始認真分析錯誤是如何進入應(yīng)用軟件開發(fā)流程的，為什么預(yù)防錯誤似乎那么困難。

關(guān)注軟件應(yīng)用生命周期

大量的調(diào)查研究表明：低劣的軟件質(zhì)量不是由于某個具體的失誤所致，而是由于參與規(guī)劃、開發(fā)、測試及維護每個應(yīng)用軟件的IT專家彼此缺少溝通和聯(lián)系。

從事軟件研究的人士說，問題在于沒有對軟件的整個生命周期進行管理，也沒有認識到：提高軟件質(zhì)量的任何工作都必須涵蓋應(yīng)用軟件生命周期的每個階段，從初期規(guī)劃、部署到維護。

美國伯克希爾人壽保險公司是設(shè)在紐約的美國嘉定人壽保險公司的子公司，它一直在想方設(shè)法探究在應(yīng)用軟件生命周期的各個階段提高質(zhì)量。

Sorin Fiscu是伯克希爾人壽保險公司的項目經(jīng)理，他解釋道：“這是我們在過去的一年里，分析了自己的開發(fā)流程、需求的征集方法以及監(jiān)控系統(tǒng)的方式后總結(jié)出來的經(jīng)驗。”

Fiscu對開發(fā)團隊做了一些調(diào)整，譬如請質(zhì)量保證（QA）人員參與早期規(guī)劃、征求業(yè)務(wù)分析員的意見、提高測試階段的自動化。這些變化讓這家公司能夠達到或超出軟件部署后的兩個目標: 保證應(yīng)用軟件的可用性和用戶對應(yīng)用軟件的整體滿意度。

在伯克希爾人壽保險公司，應(yīng)用軟件開發(fā)最初的一個步驟就是，把業(yè)務(wù)人員和IT人員召集起來，就應(yīng)用軟件的功能規(guī)格達成一致，列出業(yè)務(wù)人員需要的從屏幕流程到數(shù)據(jù)字段名稱的每項特性和功能。

Fiscu說:“在整個過程中，人們非常詳細地描述了應(yīng)用軟件以及它在將來如何使用。這個過程中的關(guān)鍵在于事先讓每個人進行交流，測試員、分析員和開發(fā)員都需要盡量充分地交流，而軟件應(yīng)用生命周期管理有助于實現(xiàn)這一過程?！?

應(yīng)用軟件生命周期管理（ALM）的基本目的相當簡單，包括: 確保負責每個階段的隊伍進行了充分溝通; 防止錯誤進入以后的階段，因為在開發(fā)流程的后期階段解決錯誤其成本要明顯高于開始階段。

Gartner的分析師Theresa Lanowitz堅稱: “實行生命周期管理很必要，但大多數(shù)組織（近90%左右）并不知道如何有效地管理生命周期。如果生命周期真正被合適的人員、流程和技術(shù)所運用，我們就會看到質(zhì)量較高的軟件、效率較高的IT組織。實際上，大多數(shù)IT組織浪費了相當多的預(yù)算，就因為它們的商業(yè)實踐沒有滿足需求，也沒有管理項目以達到進度、成本和質(zhì)量方面的目標?！?

質(zhì)量控制始于需求定義

開發(fā)人員、測試人員和業(yè)務(wù)人員之間建立清晰的溝通渠道對生命周期管理的成功至關(guān)重要。因此，需要在規(guī)劃階段把這一步作為流程的一部分。

斯特普爾斯公司（Staples Inc.）強調(diào)的重點就是，參與應(yīng)用軟件開發(fā)、測試和使用的每個人都要加強協(xié)作。Kathy Murray是這家總部設(shè)在馬薩諸塞州弗雷明漢的辦公用品零售公司負責質(zhì)量管理的高級經(jīng)理。她說：“我們與業(yè)務(wù)合作伙伴一起開會，討論業(yè)務(wù)需求，QA人員也到場，這樣他們也能明白需求。我們在需求定義階段投入的時間越多，以后階段的狀況就越好。有調(diào)查表明，60%到70%的錯誤是在需求定義階段引入的，我們的實踐證明也的確如此?！?

Arthur Povlot是提供質(zhì)量保證服務(wù)的Tescom軟件系統(tǒng)測試公司派駐亞特蘭大的企業(yè)發(fā)展經(jīng)理，他說，不正確的需求是造成大多軟件質(zhì)量問題的根源，“很少有公司在需求定義階段嚴把‘質(zhì)量關(guān)’。事實上，你應(yīng)當讓參與各方：業(yè)務(wù)分析員、營銷經(jīng)理和專題專家審查需求，并得到他們的認可。”

編程人員往往喜歡按自己的方式行事。雖然利用一套規(guī)矩捆住開發(fā)人員的手腳可能達不到目的，但針對一致性和質(zhì)量控制實施一些流程和程序卻是個好辦法。

Fiscu強烈建議: 開發(fā)人員把自己編寫的代碼（連同錯誤）交給質(zhì)量控制人員進行測試之前，先要對代碼進行特定的測試。他說：“我們的開發(fā)隊伍會收到一組單元測試腳本，就像是一份高級檢查表。惟有核對完畢后，開發(fā)才算完成。這樣，我們可以確保不會把缺陷從開發(fā)階段帶入到測試環(huán)境?！?

開發(fā)當中導(dǎo)致軟件錯誤的另一個常見問題就是，難以跟蹤軟件變更和版本。配置管理和變更管理策略及工具有助于為編寫及測試代碼執(zhí)行標準流程。

譬如說，設(shè)在克里夫蘭的美國賀卡公司就依靠冠群公司（CA）的AllFusion變更管理器，跟蹤代碼在整個開發(fā)過程中的變更情況，并且執(zhí)行公司的開發(fā)標準。

美國賀卡公司的軟件經(jīng)理Tom Brown說：“比如，誰也不能決定使用不同的編譯器，或者略過測試，因為這完全被融入流程當中。管理生命周期意味著，對我們使用的流程和編譯器的類型而言，需要確保源代碼內(nèi)容最新、保持一致?！?

測試、測試、再測試

雖然開發(fā)人員自己應(yīng)當進行一些早期測試，但成熟的測試流程和部門對查找及解決錯誤至關(guān)重要。開發(fā)人員編完代碼后，應(yīng)當對代碼進行全面的檢查，包括功能測試（評估程序的流程和功能正確與否）、集成測試、性能測試、安全測試以及對程序更新和變更進行的回歸測試（Regression Testing）。

芝加哥交易所平時對應(yīng)用軟件進行許多人工和自動測試，包括開發(fā)人員進行的單元測試、使用Compuware公司的QACenter進行的性能測試、用戶驗收測試，以及由將來使用該軟件的交易人和經(jīng)紀人進行的功能測試。芝加哥交易所在進行測試時還關(guān)注將來的發(fā)展以及更繁重的流量。

芝加哥交易所質(zhì)量保證主管David Burkhart說: “我們應(yīng)積極主動，而不是消極應(yīng)對，我們針對系統(tǒng)將來可能遇到的負荷進行測試?！?

由于時間、技術(shù)和人員能力所限，連最敏感的關(guān)鍵任務(wù)系統(tǒng)經(jīng)測試后也不能保證100%的正確性。于是問題出來了：要進行多少測試？需要測試多長時間？Povlot建議為應(yīng)用軟件最重要的需求全部建立測試用例（test case）。測試用例具體列出了測試特定的一項特性所需的用戶意見和預(yù)期響應(yīng)。他說，總的來講，你至少應(yīng)當對全部需求的90%進行測試。

自動化工具有助于加快測試規(guī)劃和執(zhí)行，尤其是回歸測試?！拔覀儼褱y試周期所需的工時縮減了50%，從而把測試對象擴大了300%?！盡urray說，他把這種改進歸功于斯特普爾斯公司使用Segue軟件公司的SilkTest和Star Quality公司的StarTest。

伯克希爾人壽保險公司使用Empirix公司的e-Test Suite來管理測試流程，并加快回歸測試。Fiscu說：“我們所做的改進越多，測試的回歸階段用時就越長?，F(xiàn)在，自動化工具節(jié)省了資源，還確保了一致性。”

將軟件開發(fā)過程變成閉環(huán)

一旦應(yīng)用軟件部署完畢，就要加以監(jiān)控及維護。軟件更新后，很快就會開始新一輪的應(yīng)用軟件生命周期，所以實際使用期間收集的信息必須反饋到下一個版本的需求規(guī)劃當中。

這正是密歇根州米德蘭的陶氏化學公司所采用的策略。陶氏公司的IT人員使用Mercury Interactive公司的LoadRunner，對新的應(yīng)用軟件運行各種測試腳本。部署后，這些腳本有許多還要再次運行，不過為了比較結(jié)果，這回用的是Mercury公司的監(jiān)控軟件包之一：Topaz或者SiteScope。如果發(fā)現(xiàn)應(yīng)用軟件存在問題，陶氏公司的操作人員就會進行事故分析流程，以查明原因。

陶氏化學公司信息系統(tǒng)部門的首席架構(gòu)專家Rich Guidotti說: “隨后，我們把這些信息反饋給開發(fā)隊伍，或者是基礎(chǔ)設(shè)施或服務(wù)隊伍，以便進行適當?shù)淖兏??！?

芝加哥交易所也使用Compuware監(jiān)控軟件來發(fā)現(xiàn)問題。Burkhart說：“在應(yīng)用軟件投入實際使用后，我們還會進行跟蹤。要是投入實際使用后出現(xiàn)問題，我們會開會討論，獲得的反饋信息會直接轉(zhuǎn)給質(zhì)量控制人員。”

眾多IT廠商提供軟件應(yīng)用生命周期的一個或多個階段的工具。幾家廠商正開始組合面向生命周期全面管理系統(tǒng)的套件。IBM的Rational部門就提供全面的產(chǎn)品線，從用于收集需求的RequisitePro、建模工具和測試工具，到IBM的Tivoli軟件中的部署后進行監(jiān)控及維護工具，應(yīng)有盡有。Borland也有類似的比較全面的工具。

同樣，Mercury、Compuware、冠群和Segue軟件公司都聲稱或者計劃擴大產(chǎn)品范圍，覆蓋應(yīng)用生命周期的各個重要階段。

雖然綜合平臺是很理想，但更普遍的情況是，一家組織必須從不同廠商選擇不同產(chǎn)品，以便對生命周期的某部分實現(xiàn)自動化，譬如需求管理、自動化功能測試和部署后監(jiān)控。有些廠商還提供與互補產(chǎn)品間的接口。但許多廠商不提供，或者至少不是為客戶擁有的每個互補產(chǎn)品都提供接口。

不過對生命周期管理而言，流程與用來支持生命周期管理的自動化技術(shù)工具同樣重要。所以，專家們說，無論是不是綜合平臺，ALM的目的就是盡量減少錯誤和疏忽，提高產(chǎn)品質(zhì)量?；蛘?，正如芝加哥交易所的Burkhart所言，這是個吸取以往經(jīng)驗、不讓過去的錯誤在應(yīng)用軟件的新周期中重演的問題。他說：“我的基本目標之一就是絕不讓錯誤重演。誰都會犯錯誤，要是大家不犯錯，我們也就用不著測試什么了。不過我們竭力落實質(zhì)量流程，就是為了防止我們再犯錯誤?！保ㄉ蚪缱g自《Computerworld》）

鏈接

軟件開發(fā)方法之ABC

軟件開發(fā)界有幾種廣為人知的方法。一種常用方法就是IBM Rational公司的Rational統(tǒng)一過程，即RUP。這個框架包括了最佳實踐和技術(shù)工具，并且明確了應(yīng)用軟件開發(fā)的四個階段：起始階段、細化階段、構(gòu)造階段和移交階段。RUP的擴展方案—企業(yè)統(tǒng)一流程（Enterprise Unified Process）由Ronin國際公司的Scott Ambler創(chuàng)建，他在RUP的基礎(chǔ)上增加了兩個階段：生產(chǎn)階段和停用階段。

另一個標準是軟件工程協(xié)會（SEI）的能力成熟度模型集成（CMMI），這是SEI早期的能力成熟度模型（CMM）的升級版。CMMI認為，周期性反饋和改進這個概念是品質(zhì)一流的IT組織的一個特點。CMMI定義了軟件流程成熟度的五個級別：從第一級（初始階段，特點是采用臨時方法，結(jié)果不可預(yù)測）到第五級（優(yōu)化階段，組織對流程不斷改進，改進效果可以衡量）。另一種知名的方法是極限編程即XP，它也強調(diào)迭代開發(fā)、不斷測試及合作開發(fā)。

設(shè)在佛羅里達州杰克遜維爾的Ajilon LLC的顧問Joshua Barnes說，迭代開發(fā)是一個關(guān)鍵問題。 它不像“瀑布法”，項目順序地從一個階段進入到下一個階段，而迭代開發(fā)是讓項目的每次遞進都要經(jīng)歷一個循環(huán)周期，以便不斷獲得反饋和糾正。Barnes說: “在我看來，使用瀑布法根本沒有幫助。但迭代方法是一種文化上的變化，人們要采用它往往難度很大。”

來源：CCW