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