系分論文：論軟件過程的改進
軟件過程的改進是一項需要長期不斷地進行下去的工作。以我們公司來說，做為一家軟件公司，過去對軟件的開發(fā)過程并不重視，接到項目后首先考慮的是如何用盡量短的時間來完成，而忽略了軟件的質(zhì)量，結果也往往是欲速則不達，甚至因為產(chǎn)品的不成熟使工期一拖再拖。
在2001年8月，我們要對公司原有的《城鎮(zhèn)職工基本醫(yī)療保險》產(chǎn)品進行升級。這個產(chǎn)品是為了配合國家的公費醫(yī)療制改革，由公費醫(yī)療改為基本醫(yī)療保險而開發(fā)的。產(chǎn)品由各地勞動部門下屬的醫(yī)療保險管理中心組織建設，中心機房設在醫(yī)保中心，通過城域網(wǎng)連接到各定點醫(yī)療機構（醫(yī)院和藥店），參保職工可持醫(yī)保卡在定點醫(yī)療機構直接消費，由醫(yī)療機構為病人墊付費用，事后再與醫(yī)保中心結算。原產(chǎn)品為兩層C/S結構，各定點醫(yī)療機構的前臺為脫機消費，定時傳送數(shù)據(jù)。這次產(chǎn)品升級首先將系統(tǒng)架構由原來的兩層C/S升級為三層C/S，中間層采用比較流行的Weblogic或SilverStream做應用服務器，用J2EE實現(xiàn)業(yè)務邏輯，并采用標準的程序接口與各前臺程序連接，以方便與第三方軟件與我們的系統(tǒng)集成。網(wǎng)絡傳輸也由原來的定時傳送改為實時連接，軟件功能上也需要突破由于原產(chǎn)品設計時沒考慮周全而帶來的限制，如原系統(tǒng)為實現(xiàn)脫機消費，采用了IC卡帶金方式，但系統(tǒng)設計時沒有考慮到IC卡本身可能存在質(zhì)量問題，而經(jīng)常發(fā)生醫(yī)保個人帳戶透支問題，在新系統(tǒng)中我們就采用了個人帳戶在醫(yī)保中心統(tǒng)一管理，IC卡只是作為一個身份識別的工具來解決這個問題。因此在項目起動時，對這個產(chǎn)品的定位就是一個全新的產(chǎn)品，而不是對原有產(chǎn)品進行修改。在這個項目里,我擔任了項目經(jīng)理一職。
1、做好項目規(guī)劃
在項目的規(guī)劃階段，我們意識到公司原有的軟件過程存在很大的弊端，首先，原來的軟件過程中，設計與開發(fā)職責不分，甚至存在分析、設計、開發(fā)、測試全由一個人承擔的做法，這樣做不但是對人力資源的浪費，同時軟件質(zhì)量也得不到保證。開發(fā)和測試由一人承擔，不利于測試出軟件中存在的錯誤，整個過程由一個人來做，做出來的軟件究竟對不對，沒有一個說法，只有到***程序拿給用戶去用時問題才能暴露出來。再者在這樣的過程中，開發(fā)人員往往會忽略文檔的重要性，這對后期的維護也會帶來一些問題。針對這一點，我們首先將項目組分為設計、開發(fā)、測試三個組，設計和開發(fā)組由系統(tǒng)總設計師負責，測試組有一個專門的組長。設計組負責軟件的分析和設計，形成設計文檔，設計文檔首先要做同行評審，評審內(nèi)容一般是文檔的規(guī)范性以及對開發(fā)人員的指導性方面，同行評審后由系統(tǒng)總設計師來做專家評審，評審的內(nèi)容是設計是否符合業(yè)務需求。開發(fā)組負責根據(jù)設計人員的設計文檔編寫出代碼，代碼編寫出來后要通過同行評審，評審內(nèi)容是代碼的編寫是否符合編碼規(guī)范、是否具有可讀性和可維護性。測試組負責根據(jù)需求和設計文檔編寫測試用例，并對開發(fā)出來的代碼進行測試。通過這樣的改進，我們充分調(diào)動了各員工的積極性，也明確了各自的責任，使得整個過程處于受控狀態(tài)。
2、加強版本控制
在原來的軟件過程中，我們對軟件的版本控制不嚴密，沒有采用必要的工具，而是完全由版本控制員手工進行操作，且版本控制員還要兼一部分開發(fā)任務。在這種情況下，版本控制經(jīng)常出問題，有時同一代碼被不同的人員同時修改，有時將本應發(fā)給甲用戶的程序發(fā)給了乙用戶，又或者開發(fā)人員自以為自已手上的代碼是***的，而出現(xiàn)已改過的BUG又重復出現(xiàn)的現(xiàn)象。這樣做的另一個問題是版本的歷史很難追蹤，由什么人在什么時候做了什么樣的修改完全沒法掌握。在這個項目里，我們意識到這一點，首先，設立了專門的版本控制人員，同時使用了ClearCase版本控制軟件，所有對文檔和代碼的修改必須先從版本控制服務器上Check Out，改完后再Check In。這樣做就杜絕了版本的覆蓋問題，而且版本歷史也是一目了然，任何修改都會形成日志，這也為問題責任的追究提供了依據(jù)。
3、加強測試工作
在這個項目里，我們特別加強了測試人員的作用。在這之前，公司也設立過測試部，但由于存在部門之間的溝通問題，測試部很難參與到項目中來，即使參與進來也發(fā)揮不了應有的作用，測試部曾一度被撒消。這一次參與測試的是新成立的測試部，而測試人員加入到項目組，業(yè)務上測試組是受項目經(jīng)理領導，人事上仍受測試部領導并考核。這樣做，首先消除了測試與開發(fā)之間的溝通隔閡，而測試人員也少了其他項目的打擾，可以專心只為一個項目做測試。而以前出現(xiàn)的因部門間隔不讓測試人員參與直接由開發(fā)人員自已測試的情況也就不存在了。
由于以前的軟件過程存成那么多的問題，使我們的產(chǎn)品不是一個成熟的產(chǎn)品，不成熟的產(chǎn)品后期施工的成本是很高的，因為存在太多的問題，維護人員要做大量的維護，而前期開發(fā)并沒有留下什么文檔，也給后期的維護帶來很多困難，維護人員每修改一段代碼首先需要讀懂原來的程序，往往讀不懂時就直接在原來的程序上加上一段通過設置條件來跳過原來的代碼，這樣使得程序越來越難讀懂，問題也越改越多。這樣的產(chǎn)品拿到一個點去施工時往往需要二個月甚至更長的時間。在這次的升級中，由于采用了較好的軟件過程，產(chǎn)品的成熟度得到了很大的提高，而設計文檔也是我們這一次重點控制的對象。這樣的產(chǎn)品為后期的施工提供了很好的條件，現(xiàn)在，產(chǎn)品在一個點的實施時間可以縮短到四十天以內(nèi)，大大地減少了施工成本。
而好的設計文檔也為產(chǎn)品的本地化修改提供了好的條件，維護人員讀懂設計文檔比讀懂程序要容易得多，在這樣的基礎上做修改出現(xiàn)的問題也越來越少。
盡管在這個項目里我們做了這么多的改進，但也存在不少的問題，首先我們使用的ClearCase版本控制軟件存在問題，這個軟件要求所有開發(fā)人員將自已的機器加入到由服務器控制的域里，否則，就只能取到版本快照而不能進行版本更新。由于這樣做，域管理員具有比本機超級用戶更高的權力來控制每臺機器，使得開發(fā)人員不愿意這樣做，于是出現(xiàn)了多人用服務器超級用戶遠程控制服務器來取版本的現(xiàn)象，使得版本的責任追究出現(xiàn)問題。而我們使用的ClearCase版本不支持Windows XP，也使這個版本控制軟件的使用出現(xiàn)了問題。
另外，我們的軟件過程制度化方面也沒做好，在項目的早期，各項工作流程都被很好的執(zhí)行，各種文檔也非常完整。由于我們這一次的升級只是針對的整個產(chǎn)品的一個部分進行的，在這之后我們又對這個產(chǎn)品進行了一次更大的升級，使得我們的產(chǎn)品能覆蓋更大的范圍。但后面的這次升級由于規(guī)模比這一次大，人員也大量的增加了。而新加入進來的人員并沒有很好地進行規(guī)范培訓，好的軟件過程標準也沒有形成有效的制度，再加上項目工期非常緊，包括同行評審、專家評審這樣的流程都開始有些流于形式甚至被忽略。開發(fā)組編碼時也沒有完全按制定的規(guī)范進行。因此，產(chǎn)品質(zhì)量上就出來了一些反復。我們這個產(chǎn)品是個可分可合的產(chǎn)品。因些在后來的產(chǎn)品實施上出現(xiàn)了這樣一種情況：如果一個點只實施前一次升級的那部分，施工難度很小，能在短期內(nèi)完工，本地化開發(fā)工作也很好完成。而要全面實施整個產(chǎn)品的話，工期就會被拖得很長，本地化開發(fā)工作也存在很大的問題。
針對出現(xiàn)的這種情況，我們公司意識到了軟件過程改進的重要性，針對版本控制軟件問題，我們改用了功能雖然沒有ClearCase強，但更適合于我們的VSS。而在制度化方面，更是下了大力氣，從印度請來了專家為我們的改進做參謀，現(xiàn)在公司的情況已有很大改觀，各項制度已不再流于形式，而公司更是在并在去年年底順利地通過了CMM3的認證。軟件過程改進的路還很長，但有一點是不變的，只有通過軟件過程的改進，我們的產(chǎn)品才能不斷地走向成熟。也只有產(chǎn)品成熟了，我們才能在競爭中永遠立于不敗之地。
【相關文章】
