丹東思凱電子發(fā)展有限責任公司 關嘉旺
摘要：本文通過對《IC卡水表管理系統(tǒng)》各階段的發(fā)展過程，闡述質量管理在項目開發(fā)的各階段的實現過程。
關鍵字：需求分析、開發(fā)設計、文檔管理、配置管理、測試
引言
《IC卡水表管理系統(tǒng)》是為吉林自來水公司建立的一套針對用戶的數據采集和統(tǒng)計分析系統(tǒng)。通過這套系統(tǒng)可以對這些數據的分析，便于及時發(fā)現可能發(fā)生的隱患，提高計量設備管理水平，減少供銷差率都具有重要的意義。同時極大的提升自來水公司的服務水平和企業(yè)形象。
本人通過項目的開發(fā)深刻感受到認真細致的項目管理，對保證項目周期和項目質量的重要性。項目的質量高低取決于其是否符合包括功能性、可靠性、易用性、效率、可維護性、可移植性等六個方面的要求。而要達到這六個方面質量要求，就必須對軟件開發(fā)過程中各個環(huán)節(jié)進行全過程的質量管理，從需求分析、設計、編碼、測試等各個方面和環(huán)節(jié)進行控制。
一、需求分析
需求分析是開發(fā)人員對系統(tǒng)需要做什么和如何做的定義過程，這個過程往往是個循序漸進的過程，一次性對系統(tǒng)形成完整的認識是困難的。只有不斷地和客戶、領域專家進行交流確認，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質量。
吉林自來水公司與我單位有長期的合作關系，我單位數據集統(tǒng)計分析領域的優(yōu)勢和長年積累的經驗，客戶的需求非常明確，同時在本項目中，請領域專家參與到系統(tǒng)開發(fā)的早期階段;開發(fā)系統(tǒng)原型，原型包括功能性的原型和用戶界面性的原型，用這些原型確認用戶的需求。讓領域專家參與開發(fā)的早期階段，保證分析人員有充足的時間和領域專家進行充分的交流和確認。在這個階段，原型在提交到用戶之前，首先被領域專家確認，這樣保證了原型被認可的程度和認可過程耗費的時間，從而在提高效率的同時保證了質量。
在開發(fā)方內部還有三項保證措施:系統(tǒng)分析委員會保證系統(tǒng)分析集思廣益;質量監(jiān)督組對分析工作的監(jiān)督;技術支持人員參與需求調研。
分析委員會負責分析人員在提交其所分析部分的分析說明書前，必須通過委員會的共同審議，委員會的成員根據各自的分析經驗和自身所分析的部分對他人的分析報告提出質疑。如此審議過后保證了各部分間相互關聯(lián)的部分被明確定義，避免了由于“疏忽”造成系統(tǒng)在后期進行整合時出現較嚴重的系統(tǒng)鴻溝或系統(tǒng)重疊。
質量監(jiān)督組在項目的任何階段都提出監(jiān)督計劃。按照監(jiān)督計劃分配相應的資源來保證某階段的開發(fā)質量。分析階段的監(jiān)督計劃會在分析任務之前被項目經理、項目負責人、系統(tǒng)分析員以及技術支持所了解。為保證分析工作高質量進行，同時分析工作又不被過分打擾，質量監(jiān)督組則主要針對《系統(tǒng)分析報告》進行復審，并在認為確實有必要的情況下才召開質量復審會議。質量復審會議的主要參與者是項目經理、項目負責人、分析人員和質量監(jiān)督組組長。會議的主要議題是提出質量質疑，給出改進建議即可。具體是否存在質量問題，是否需要改進，不在會議中進行討論，以此保證了會議參與的人數較少，會議的時間盡可能的短。
二、開發(fā)設計
開發(fā)設計是產品質量形成的最為關鍵的階段。設計一旦完成，產品的固有質量也就隨之確定。搞好產品開發(fā)設計階段的質量管理，確保開發(fā)設計的質量，是企業(yè)至關重要的環(huán)節(jié)。
（1）搞好設計策劃 在項目開發(fā)設計初期，根椐實際情況和產品的特點，確定產品開發(fā)的工作程序和設計進度，明確劃分研制階段，在每階段建立評審點，實施分階段質量控制。同時，確定各有關部門和人員的職責、權限、組織和技術接口以及所需的各種資源。 針對每項開發(fā)和設計活動單獨編制質量計劃。產品質量計劃應針對具體產品的特殊要求，以及應重點控制的項目 ，編制各階段的質量控制方案，規(guī)定各階段主要質量活動的內容，提出專題試驗研究項目或技術攻關課題。
（2）進行早期預防 為確保開發(fā)設計質量，防止和識別設計工作中的偏差和錯誤，使用以下方法進行預防報警。
設計評審 ：及早發(fā)現、防止和彌補設計本身的缺陷，在產品開發(fā)設計過程各階段決策點上，組織與產品形成過程有關、但不直接參與或對產品開發(fā)設計不負直接責任的專家，對產品設計及可能出現的缺陷進行評審。可達到以下目的： 及早發(fā)現和補救設計中的問題。 防止設計缺陷帶到生產中去，影響制造成本、產品性能等。
設計驗證： 在設計的適當階段，應開展設計驗證活動?？筛鶕唧w情況靈活運用以下方法：變換方法計算；將設計與已證實的類似設計進行比較；對發(fā)放前的設計階段文件進行評審；進行試驗和驗證。一般同時采取兩種或兩種以上方法進行驗證。其目的是：確保設計輸出滿足輸入的要求。
故障分析 ：為了防止產生影響產品可靠性和安全性的故障，在開發(fā)設計過程中，對可能產生的故障及其潛在原因進行系統(tǒng)的研究。
（3）廣泛使用質量工程技術 質量工程技術為產品研制設計、技術改進提供了合理而高效的技術方法。
（4）確立基準 把世界上同類產品公認的領先的名牌產品作為自已產品的基準。通過與基準產品在性能、成本、款式、交貨期、生產過程、質量和服務水平等到全方位的比較，確定自已所處的地位和努力方向。通過模仿和不斷的改進，達到超越競爭對手的目的。 基準化過程一般要遵循下述步驟：
a、確定基準化的對象，確認競爭對手或本領域的領先者。
b、建立信息系統(tǒng)，收集數據資料。
c、歸納并分析數據：分析的目的是針對所有有關項目制定最佳的實踐目標。
d、通過對比，制定和實施行動計劃，最終達到或超過競爭對手的標準。
（5）、設計人員要面向市場調查，新產品設計動機來自于顧客的期望和思想。因此，開發(fā)設計人員一定要從辦公室里走出來，面向市場和顧客，從事產品銷售和服務維修工作，真誠地傾聽顧客的聲音。
三、文檔管理
為了控制系統(tǒng)開發(fā)過程中的往復，不至于產生重大過失和往復的泛濫，文檔組和質量監(jiān)督組協(xié)同完成軟件開發(fā)的配置管理。同時為了使軟件文檔能起到多種橋梁作用，使它有助于程序員編制程序，有助于管理人員監(jiān)督和管理軟件開發(fā)，有助于用戶了解軟件的工作和應做的操作，有助于維護人員進行有效 的修改和擴充，文檔的編制必須保證一定的質量。質量差的軟件文檔不僅使讀者難于理解，給使用者造成許多不便，而且會削弱對 軟件的管理(管理人員難以確認和評價開發(fā)工作的進展)，增高軟件的成本(一些工作可能被迫返工)，甚至造成更加有害的后果 (如誤操作等)。造成軟件文檔質量不高的原因可能是：
l缺乏實踐經驗，缺乏評價文檔質量的標準。
l不重視文檔編寫工作或是對文檔編寫工作的安排不恰當。
最常見到的情況是，軟件開發(fā)過程中不能按給出的進度， 分階段及時完成文檔的編制工作，而是在開發(fā)工作接近完成時集中人力和時間專門編寫文檔。另一方面，和程序工作相比，許多 人對編制文檔不感興趣。于是在程序工作完成以后，不得不應付一下，把要求提供的文檔趕寫出來。這樣的做法不可能得到高質量的文檔。實際上，要得到真正高質量的文檔并不容易，除去應在認識上對文檔工作給予足夠的重視外，常常需要經過編寫初稿，聽取意見進行修改，甚至要經過重新改寫的過程。
高質量的文檔應當體現在以下一些方面：
l 針對性
文檔編制以前應分清讀者對象，按不同的類型、不同層次的讀者，決定怎樣適應他們的需要。例如，管理文檔主要是面 向管理人員的，用戶文檔主要是面向用戶的，這兩類文檔不應像開發(fā) 文檔(面向軟件開發(fā)人員)那樣過多地使用軟件的專業(yè)術語。
l 精確性
文檔的行文應當十分確切，不能出現多義性的描 述。同一課題若干文檔內容應該協(xié)調一致，應是沒矛盾的。
l 清晰性
文檔編寫應力求簡明，如有可能，配以適當的圖 表，以增強其清晰性。
l 完整性
任何一個文檔都應當是完整的、獨立的，它應自成體系 。
l 靈活性
各個不同的軟件項目，其規(guī)模和復雜程度有著許 多實際差別，不能一律看待。對于較小的或比較簡單的項目，可做適當調整或合 并。比如，可將用戶手冊和操作手冊合并成用戶操作手冊；軟件需求說明書可包括對數據的要求，從而去掉數據要求說明書；概要設 計說明書與詳細設計說明書合并成軟件設計說明書等。
l 可追溯性
由于各開發(fā)階段編制的文檔與各階段完成的工作有著緊密的關系，前后兩個階段生成的文檔，隨著開發(fā)工作的逐步 擴展，具有一定的繼承關系。在一個項目各開發(fā)階段之間提供文檔 必定存在著可追溯的關系。例如，某一項軟件需求，必定在設計說明書，測試計劃以至用戶手冊中有所體現。必要時應能做到跟蹤追查。
四、配置管理
“配置管理”過程的目的在于運用配置標識、配置控制、配置狀態(tài)統(tǒng)計和配置審核，建立和維護工作產品的完整性。軟件配置管理的目的在于控制軟件開發(fā)過程中的“變化”，這種變化可能是外部引起的，如需求的變化。也可能是來自于內部的變化，如早期設計的某個部件不夠完備，需要修改等。為了控制這些變化，把變化引起的波動盡可能的控制在有限的范圍內。
配置項是指需要進行控制的任何文檔單元，它可能是需求說明報告，也可能是需求說明報告的某個點。在本項目中需要控制的內部配置項包括需求報告，設計報告，組件代碼，組件接口文檔，構件及相關構件。
本系統(tǒng)通過配置管理，確定所選工作產品的配置；這些工作產品構成給定時間點的基線；控制對配置項的變更；為構造配置管理系統(tǒng)的工作產品建立或提供規(guī)范；維護基線的完整性；向開發(fā)者、最終用戶和顧客提供準確的狀態(tài)和現行配置管理數據。
五、測試
軟件測試的定義：根據軟件的規(guī)格說明及程序結構，設計一批測試用例，運行程序查找程序錯誤。
軟件測試的目的：是要發(fā)現程序的錯誤。一個好的測試用例，就是能發(fā)現程序中至今未發(fā)現的錯誤。一個成功的測試就是發(fā)現了程序中至今未發(fā)現的錯誤?？梢钥闯?，測試的目的是證明程序有錯誤，而不是為了證明程序是正確的。
軟件測試的原則：
1. 要把“盡早地不斷地測試”作為座右銘。
2. 測試用例應該同時包括測試輸入數據和預期的輸出結果。
3. 程序員應避免測試自己的程序。
4. 設計的測試用例應包括合理、有效、可驗證程序正確的那些數據，以及不合理的、無效的、證明程序做了不該做的事情的數據。
5. 如果程序中查出的錯誤越多，則未查出的錯誤也越多。
6. 仔細檢驗測試結果
7. 嚴格執(zhí)行測試計劃
8. 妥善保管測試計劃、測試用例和結果，供維護時使用。
一般把測試方法分為兩類：白盒法是著眼于邏輯結構，主要是進行結構測試；黑盒法主要著眼于功能。我們的測試人員對應用軟件的測試，主要采用的就是黑盒法。在黑盒測試中，邊值分析法和因果圖法是常用的兩種方法。邊值分析法是對程序輸入輸出的邊界情況進行測試。具體設計原則是：
1. 如果輸入條件規(guī)定了取值的范圍，應選擇正好等于邊界的值，略小于最小值和/或略大于最大值的值作為測試數據。
2. 如果輸入條件規(guī)定了值的個數，應選擇最小的個數、最大的個數、略小于最小和略大于最大的個數作為測試數據。
3. 對于輸出條件，若規(guī)定了取值范圍，則可以用類似1中的方法。
4. 對于輸出條件，若規(guī)定了值的個數，可以使用類似2中的方法。
5. 輸入、輸出項若是一個有序的集合，則選擇第一個元素和最末元素作為測試數據。
因果圖法適用于輸入條件之間關系比較復雜，不同的條件組合會產生若干動作的情況。通過判定表的形式，可以很好地表達多種條件組合產生不止一個動作，其中輸入條件就是因，輸出條件就是果。通過對《IC卡水表管理系統(tǒng)》的測試，測試情況分析如下：
1、 手工過多，缺少測試工具，自動化測試方式缺失。傳統(tǒng)的項目測試還是以手工為主，測試人員根據需求規(guī)格說明書的要求，與測試對象進行“人機對話”。這種測試的弊端為：
l 大量的手工使項目人力成本、溝通成本居高不下；
l 人工操作的低效率使項目耗時增加，帶來進度風險；
l 人員素質及其他不確定因素會影響手工測試的結果，導致差錯率的增加。
2、 缺乏文檔測試、檢查
文檔是項目的重要產品之一，產品需求、功能分析、架構設計、詳細設計、用戶手冊、維護手冊等等，對于項目的測試、上線、維護等過程起到至關重要的參考、指導作用，所以它們的質量應該是項目重點關注點之一。令人遺憾的是，許多軟件項目對于文檔的重視只停留在口頭隨著需求不斷變更、補充，業(yè)務、技術人員忙于應付，無法騰出精力來進行文檔內容的修改及完善，往往是將包含需求變更內容的工作聯(lián)系單往需求文檔后一附了事，而不去更新需求與其他相關文檔；另一方面，項目變更管理還不夠完善，管理重點往往集中于開發(fā)，而輕視文檔質量管理，未留出充分的文檔更新時間，導致文檔更新嚴重滯后于編碼進度。為保證文檔質量，必須定期進行文檔測試，但測試要花成本，項目高層不愿意付此代價。
文檔若可讀性低，便會影響用戶的理解；若與編碼不一致，便起不到參考作用，編碼測試就沒有可靠的測試依據。路都看不清楚，怎么往前走呀？所以，強烈建議進行文檔測試，并將其置于測試管理的首位。
當前文檔測試的方法沒有什么特別的形式，還缺乏測試工具支持，通常是通過靜態(tài)審查方式“走查”來進行的，主要查看文檔的可讀性，內容真實性、可靠性、全面性。另外，在項目里程碑時期召集相關領域專家對重要文檔進行集中審核，也是一種檢查方式。
3、 單元測試引入交叉測試方法
單元測試是對軟件基本組成單元進行的測試，測試對象是軟件模塊。通常，單元測試是由開發(fā)人員來完成，而且往往是各人測各人的。這樣就存在問題隱患，技術人員是軟件模塊的制造者，自己來測自己的軟件，角色便從制造者變成了審查者，而前一個角色的目的是為了保證軟件正確，后一個角色的目的是為了發(fā)現更多的缺陷，讓一個人同時來扮演兩種目的不同的角色，好比讓他既當裁判員又當運動員。
解決方法通常有兩種，一種是：由測試人員來進行單元測試，這種方式要求測試人員要有較高的軟件技術知識；另一種是：將軟件人員分組，在模塊開發(fā)告一段落時進行交叉測試，這種方法只需要測試者了解被測方的軟件需求，不需要另外的知識培訓，而且測試出發(fā)點較為客觀。
六、結束語
項目管理是一個系統(tǒng)工程，主要目標是保證項目在規(guī)定時間內高質量地完成。軟件過程是一個組織實現其軟件能力改進的杠桿支點。本文通過對軟件過程的質量管理，旨在提高其對軟件產品或服務的開發(fā)。
參考文獻
1、《軟件配置管理策略與IBM Rational ClearCase》 作者：[美]David E.Bellagio,
Tom J.Milligan 著， 王海鵬譯，人民郵電出版社
2、《軟件開發(fā)管理的實踐》 作者：張少仲，李遠明等編著，清華大學出版社
3、《IT項目管理實踐》 作者：劉慧，陳虔等編著，電子工業(yè)出版社出版
4、《IT項目管理》 作者：（美）凱西.施瓦爾貝著，鄧世忠等譯,機械工業(yè)出版社出版
