12. 項目質量管理

12. 項目質量管理

來自專欄 如何做好甲方項目經理

軟體質量指從軟體產品相關的功能、性能、穩定、安全和文檔等方面，來判別產品預期標準的完成情況，其中完成情況的好壞直接決定了軟體質量的高低。對於甲方項目經理來說，其進行項目質量管理工作的目標主要是通過各種管理手段來規避項目質量風險、解決項目質量問題、提高項目質量，以確保項目產品能夠滿足預定的質量標準。

為了達成質量管理目標，我們可以將甲方項目經理的質量管理工作分為以下四個方面：一是制定質量標準。其應依據項目「完成」的定義，來制定該項目對應的質量標準；二是監測質量情況。在項目建設工作中，其需要依據項目建設的具體情況，結合事前制定的質量標準，來持續不斷的對軟體產品的質量情況進行分析和判別，並形成相應的質量報告；三是防範質量風險。其應依據項目工作情況，結合自身的工作經驗，來採取相應的管理措施，如乙方廠商需求反講、相關技術方案評審、測試案例評審和強化測試等，以避免項目建設過程中出現質量相關的風險；最後時處置質量問題。即在質量問題發生時，其應依據項目的實際情況和個人的工作經驗，同乙方團隊一起對問題原因進行分析，給出相應的處置措施方案並監督其執行情況，如：技術方案調整、代碼修改等。

12.1. 質量標準制定

我們知道，項目「完成」定義主要包含項目建設的四個關鍵要素項，分別為範圍、時間、成本（資源）和質量，其中質量代表項目軟體的質量，範圍代表項目需要實現的功能性和非功能性需求的範圍，時間代表項目最終的完成時間，成本（資源）代表項目需要付出的人力、研發、管理等方面的成本。對於範圍、時間和成本來說，通常都可以給出明確的、可定量的判別標準，但對於質量來說卻很少能夠給出可比較、可管理、可跟蹤的標準，這給質量管理工作帶來了極大的不便。因此，為了能夠在產品質量管理時更有效、更有針對性，同時給負責項目建設的乙方項目團隊提供更明確的質量目標，甲方項目經理應在項目建設開始前制定清晰明了、易於管理、便於跟蹤的項目質量標準。

軟體質量代表了項目最終產品的優劣程度，而質量標準則為其提供了具體的評價標準，使相關成員可以對其做出較為直觀的判別。通常會我們從功能、性能、穩定、安全和文檔等幾個方面來對軟體的整體建設情況進行綜合的評價，所以在制定項目的質量標準時，也主要是圍繞這五個方面來開展的。其中功能指軟體所實現的功能性和非功能性的業務需求；性能指軟體的響應時間、吞吐量、並發數或資源利用率等性能指標；穩定指軟體可以長時間正常運行的能力；安全指軟體遭到外部惡意攻擊的情形下，可以繼續正常運行或防止數據遭篡改、竊取的能力；文檔指項目建設過程中，出於不同的目的而編製的各類文檔。

對於甲方項目經理來說，其需要注意的是項目質量標準不是一成不變的，而是需要其依據項目「完成」定義的變化和項目建設的實際情況，來實時進行調整的。

1. 功能類質量標準

項目功能方面的質量標準，指最終的軟體產品需要實現功能的範圍及要求，其質量的高低主要取決於相關要求的完成情況。因此，對於甲方項目經理來說，功能類的質量標準主要包含兩個方面：一是產品功能應滿足所有業務需求中所描述的功能性需求；二是產品功能在易用性、可用性上，要滿足甲方業務人員的使用要求。

這裡需要注意的是，在實際的項目建設工作中，甲方業務人員由於專業背景的局限，很難在建設工作開始前就給出具體的、可操作的使用方面的標準，其通常是在看到最終的可操作產品後才能夠給出具體的意見。這就使得乙方團隊的建設工作經常會因此而進行返工，從而給項目建設帶來了極大的進度、質量等方面的風險。對此，甲方項目經理需要儘可能的將功能使用標準的提出時間提前，以最大限度的降低對項目工作的影響。依據筆者的個人經驗來看，其可以通過以下的方式：對於關鍵的業務功能，在開始建設前應要求乙方團隊給出高保真的演示原型，通過其來使相關的業務人員了解該功能的操作、展示等方面的內容，從而使得其在建設工作開始前就可以給出具體的使用要求。

2. 性能類質量標準

項目性能方面的質量標準，指最終的軟體產品需要達到的各項性能指標，這些指標主要來自於業務需求中的非功能性需求對性能的要求，主要包含軟體的響應時間、吞吐量、並發數和資源利用率等性能指標。對於乙方團隊來說，這種類型的標準屬於硬性標準，是其無論如何都需要達成的建設要求。其評價標準較為清晰，就是最終軟體產品的性能能否達到預定的標準。

這裡需要注意的是，在通常情況下，軟體的性能與其所運行的硬體環境有著直接的關係，同樣的軟體在不同的硬體環境下，其性能可能會存在較大的差異。因此，對於甲方項目經理來說，其提出的性能類質量標準通常只是針對運行在生產環境上的最終產品，而與運行在其它環境上的產品沒有太多的關係。

3. 穩定類質量標準

項目穩定方面的質量標準，指最終的軟體產品在給定的運行環境下，能夠持續無故障運行的時間。其中無故障運行時間應在非功能性需求中給出明確的要求，常見的有5*8（每周連續5天，每天持續運行8小時。或是工作日的8小時內正常運行）、5*12（每周連續5天，每天持續運行12小時。或是工作日的12小時內正常運行）、7*24（每周連續7天，每天持續運行24小時。或是永不間斷的正常運行）等。對於甲方項目經理來說，其在確定無故障運行時間時，只需要滿足業務開展的需要即可，而不應是越長越好，這是因為無故障運行時間越長，產品的結構就越複雜，在項目建設時需要投入的時間、成本就越多。

這裡需要注意的是，軟體運行的穩定性不僅僅取決於其自身的結構，同時還受到軟硬體運行環境、網路情況、後續業務開展情況、上線後運維等其他因素的影響。因此，甲方項目經理在所提出的性能類質量標準時，需要注意以下幾方面：一是該標準只針對運行在生產環境上的最終產品，而與運行在其它環境上的產品沒有太多的關係；二是該標準不僅針對項目建設團隊，還針對項目運維團隊；三是產品在驗收時確定滿足該標準的要求，並不意味著其在運行期間就不會出現穩定相關的問題。

4. 安全類質量標準

項目安全方面的質量標準，指軟體在遭受外部惡意攻擊時，軟體能夠繼續正常運行或防止文件、數據遭受篡改或竊取的能力。一般情況下，項目的安全標準可以在《信息安全等級保護管理辦法》中的規定安全等級五級分類的基礎上，結合項目建設要求，提出更具體、更有針對性的安全要求，如文件防篡改、數據加密等等。對於甲方項目經理來說，其在確定安全標準時，只需要滿足業務開展的需要即可，而不應是越高越好，這是因為安全性標準要求越高，項目建設過程中需要付出的成本就越高、時間就越長，甚至會倒逼業務功能做出相應的調整。

這裡需要注意的是，軟體的安全不僅僅取決於其自身的結構，同時還受到軟硬體安全設計、網路情況、上線後運維等其他因素的影響。因此，甲方項目經理在所提出的安全類質量標準時，需要注意以下幾方面：一是該標準只針對運行在生產環境上的最終產品，而與運行在其它環境上的產品沒有太多的關係；二是該標準不僅針對項目建設團隊，還針對項目運維團隊；三是隨著黑客技術的不斷發展，並不意味著已滿足軟體安全標準的軟體產品永遠都是安全的。

5. 文檔類質量標準

項目文檔方面的質量標準，指在項目建設過程中應編製的文檔列表及其編製要求。對於甲方項目經理來說，其在項目建設開始前，應依據甲方機構相關的管理要求，參照其他項目或自身工作經驗，結合該項目的建設要求來提出具體的文檔標準。其中，文檔相關的質量標準主要包含以下三個方面：一是給出項目所需文檔的列表，具體內容有：文檔名稱、文檔功能簡述、文檔編寫機構等；二是通過文檔模板或是文字描述來給出各個文檔的編製要求；三是通過工作計劃來明確各個文檔的開始、完成日期。

在項目的質量管理過程中，甲方項目經理可以根據項目建設的實際情況來對文檔標準進行調整。

12.2.質量情況監測

對於甲方項目經理來說，其開展項目質量管理工作的前提是要對產品的質量情況有清晰、全面、直觀的了解。這就需要其在項目建設過程中，依據項目建設的具體情況，結合事前制定的質量標準，來持續不斷的對軟體產品的質量情況進行分析和判別，以及時發現存在的質量風險或質量問題，從而通過相應的處置手段來確保項目產品能夠滿足預定的質量標準。

依據筆者的個人經驗，甲方項目經理可以通過以下幾種方式來獲取項目的質量情況：一是日常的工作溝通會。通過工作溝通會，甲方項目經理能夠及時的掌握乙方團隊建設工作的開展情況，一方面可以判別其是否會造成質量風險或質量問題，另一方面則可以對已發現的質量風險或質量問題的解決情況進行跟蹤；二是乙方工作方案或代碼評審。通過乙方團隊的軟體實現方案或軟體代碼評審的方式，甲方項目經理可以直觀的掌握軟體產品的質量情況。但這種方法存在較大的局限性，一方面需要甲方項目經理有非常強的技術能力，另一方面其不可能對所有軟體代碼或實現方案進行評審；三是軟體測試。這是最常見的一種方式，通過各種類型的測試工作，甲方項目經理可以充分、全面的掌握軟體產品的質量情況。

對於甲方項目經理來說，如其在質量檢測過程中發現質量問題或質量風險時，應當在項目質量情況表中將其記錄下來，並通過該表來對相應的處置工作進行跟蹤。其中，項目質量情況表是甲方項目經理在對項目的質量情況有了深入的了解後，結合自身的工作經驗而整理的，是其對項目質量問題跟蹤、管理的主要工具。主要包含以下的內容：質量問題或風險、對應解決方案、處理計劃、處理進度以及結果確認。如表12.1所示：

表 12.1

12.3. 質量風險防範

對於甲方項目經理來說，其進行項目質量管理工作的一個非常重要的職責就是通過相應的管理手段來降低質量風險發生的可能性。我們知道，在項目建設過程中，一旦出現了質量問題，不論解決方案有多完善、處置的有多及時，都無法避免的會對項目工作造成一定程度的影響，有時甚至會導致項目失敗。因此，甲方項目經理在項目質量管理工作中應該更多的考慮如何主動防範質量風險的發生，而不是等待出現質量問題後被動的進行解決。

依據筆者個人的工作經驗來看，導致項目建設過程中出現質量風險的原因主要有以下幾種：需求發生變更、項目建設時間不足、開發團隊成員需求理解不準確、實現方案存在缺陷、測試不充分和開發團隊成員能力不足等。因此，甲方項目經理在進行項目質量管理時，應通過各種防範措施來確保項目建設工作中不會出現上述的情況，從而避免軟體質量風險的發生。一般情況下，常見的防範措施主要有以下幾種：

1. 加強業務需求學習

我們知道，業務需求是所有項目建設工作的實現目標和工作基礎，乙方項目建設團隊只有對業務需求有充分的認識和正確的理解後，才能夠確保其後續的功能設計、產品架構、代碼開發等項目建設工作滿足業務需求的要求，否則的話勢必會導致軟體產品出現無法滿足業務需求的質量風險。

對於甲方項目經理來說，其可以通過以下方式來加強乙方項目團隊對業務需求的學習和理解：一是邀請業務部門的相關同事來為乙方團隊成員講解業務需求；二是要求乙方團隊成員在對需求有了充分的了解後，向甲方項目經理和業務部門人員進行需求反講。

2. 重視相關工作評審

我們知道，實現方案和產品設計等文檔是乙方項目團隊在對業務需求進行了深入的分析後，形成的項目建設思路和實施方法，是後續的具體建設工作在紙面上的預演。可以說，實現方案和產品設計等文檔中存在的問題，最終都會體現到項目產品上去，從而使得軟體產品出現質量相關的問題。因此，甲方項目經理有必要在項目建設工作開始前，對這些文檔的內容進行評審，以規避因設計方案缺陷而導致的質量風險。

在項目建設工作中，實現方案和產品設計相關的文檔主要有：需求規格說明書、技術方案、軟體原型、資料庫設計、產品框架設計等。這些文檔針對著軟體產品的不同方面，甲方項目經理在對其進行評審時，需要有針對性的邀請相關方面的專家：對需求規格說明書評審時，應邀請業務、技術相關的專家；對技術方案、資料庫設計和產品框架設計評審時，只邀請技術相關的專家即可；對軟體原型評審時，則應以業務相關人員為主。

最後需要注意的是，實現方案和產品設計等文檔一旦發生調整，甲方項目經理都需要重新對其進行評審，但可以依據調整範圍和影響程度來確定是否邀請外部專家參與。

3. 緊抓軟體測試工作

軟體測試工作是指在規定的條件下，通過人工或自動的手段來運行或測定某個軟體系統的過程，其目的是發現軟體中存在的bug或問題，以確保軟體能夠按要求正常運行。可以說，其是軟體質量最主要的保障手段之一。依據筆者個人的經驗來看，測試不盡責、測試案例不全面等問題可能會使得最終的軟體產品帶有一些隱藏的bug，而這些未被發現的bug會導致軟體產品出現質量風險。因此，甲方項目經理需要加強產品的測試工作，以儘可能的減少產品中隱藏的bug，從而降低因測試不充分而導致的質量風險發生的可能性。

在項目建設過程中，涉及到的測試類型主要有以下幾種：軟體測試按照是否涉及內部結構可以分為黑盒測試、白盒測試和灰盒測試；按照程序是否執行可以分為動態測試和靜態測試；按照測試階段有單元測試、集成測試、確認測試、系統測試和驗收測試等。同時還有一些軟體功能測試之外的其他測試，有性能測試、壓力測試、安全測試、文檔測試等。甲方項目經理可以依據軟體產品的具體情況和質量標準，來要求乙方團隊、第三方測試團隊和甲方機構開展相應的測試工作，以達到預期的質量管理要求。

對於甲方項目經理來說，為了確保測試工作的質量，其在測試過程中應要求各參與方遵循以下的測試原則：

1) 測試工作應儘早進行。問題發現的越早，對系統造成的影響越小，解決成本也越低；

2) 除去單元測試，測試工作應由專門的測試人員或第三方機構來負責；

3) 測試用例是基於需求規格說明書的，在編製時應包含正常情況和異常情況，同時要對各種邊界條件著重處理，特殊情況下還要製造極端狀態和意外狀態，如網路異常中斷、電源斷電等；

4) 測試用例需要通過相應的評審；

5) 對錯誤結果要進行一個確認過程。一般應由雙人交叉確認，嚴重的或影響較大的錯誤可以召開專門的評審會議進行討論和分析，對測試結果要進行嚴格地確認，是否真的存在這個問題以及嚴重程度等；

6) 重視安全、性能和文檔等非功能性的測試工作；

7) 確保測試時間，短時間內是無法完成一個高質量的測試；

8) 妥善保存測試用例、出錯統計和最終測試報告，為後續的運維工作提供方便。

12.4. 質量問題處置

在項目建設過程中，當項目出現質量問題的時候，甲方項目經理需要結合項目建設的實際情況，同乙方項目團隊一起找出問題的原因並給出可行的解決方案，然後監督解決方案的執行情況，以確保項目質量能夠滿足預期的質量標準。

這裡需要注意的是，在項目建設過程中一旦出現了質量問題，那麼就勢必會對項目建設工作的進度造成一定程度的影響，這是由於乙方團隊對質量問題進行處置時，所付出的工作都是計劃外的。這就要求甲方項目經理在制定質量問題的處置方案時，不僅要能夠解決質量問題，還要盡量減小對項目進度的影響。依據筆者的個人經驗來看，甲方項目經理在處理質量問題的時候，可以採用以下幾個步驟：一是深入分析問題原因，確定問題類型以及危害程度；二是對乙方項目團隊給出的解決方案和調整後的工作計划進行評審；三是監督乙方項目團隊解決方案的執行情況。

1. 功能類質量問題

功能類質量問題主要指由於需求理解偏差、實現方案缺陷、代碼錯誤、乙方團隊成員能力不足等方面的原因而使得軟體產品無法滿足業務需求中對功能的要求。簡單的來說就是軟體存在bug使得其無法滿足業務需求，需要注意的是在大多數情況下，軟體bug和該類問題是等同的。對於甲方項目經理來說，這類問題佔據了項目質量問題的絕大部分，是其在進行質量管理時重點關注的對象。

依據筆者的個人經驗，甲方項目經理在對這類問題進行處置時，需要注意以下幾點：一是要對其產生原因和影響範圍有一個清晰的認識，並在此基礎上制定可行的處置方案；二是在對該問題產生原因分析的基礎上，考慮相應的規避手段，以防止再次發生同類型的問題。常用的處置流程如下：

1) 要求乙方團隊分析該問題的原因及影響範圍；

2) 要求乙方團隊以書面的方式給出可行的解決方案，需包含所有待修改代碼列表；

3) 甲方項目經理應對乙方團隊提交的解決方案進行評審，只有通過評審後才可以開展後續的實施工作；

4) 乙方團隊按照解決方案的規劃來對軟體進行修改。如有必要還需要對相關的項目文檔，如技術方案、實現方案、工作計劃等，進行調整；

5) 甲方項目經理負責監督該解決方案的執行情況，並組織相關人員對所有修改點以及關聯功能進行驗證；

6) 基於該問題產生的原因，對其他類似功能進行分析，防止同類型錯誤再次發生。

2. 文檔類質量問題

文檔類質量問題主要指項目文檔無法滿足項目建設工作的需要，主要表現在兩個方面：一是無法提供文檔標準中所要求的相關文檔；二是文檔內容與實際工作情況不一致。其中，第二種情況在實際工作中出現的要更多一些，涉及的文檔主要有：需求規格說明書、實現方案、技術方案、工作計劃、測試案例等。依據筆者的個人經驗來看，導致這種類型問題的原因主要有：需求變更頻繁、實現方案調整、建設時間緊張等。

對於甲方項目經理來說，其在對這種類型的質量問題進行處置時，可以依據項目的實際情況來採用相應的處置方案，具體如下：

1) 相關文檔需要及時的進行處理。該方案適用於建設時間充足的情況，儘管文檔維護工作會對項目進度造成一定程度的影響，但其可以有效規避因項目規模大、人員多、周期長而造成變更信息在團隊內傳遞失真的風險，從而確保了變更後的信息可以如實的傳達給項目組的每一位成員，保障了建設標準的一致性。其不足就是文檔修改、評審等工作會佔用一定的項目建設時間，進而導致項目出現進度問題；

2) 相關文檔不需要及時的進行處理，而應在某個約定的時間集中進行處理。該方案適用於建設時間少且參與人員較少的情況，主要有兩方面的原因：一方面由於此時項目通常對進度有較高的要求，而文檔維護工作所帶來的進度延期是其無法接受的，另一方面由於項目團隊成員較少，信息溝通、傳遞不存在信息丟失或失真問題。因此，為了確保項目建設進度，甲方項目經理通常會要求乙方團隊將相關的變更記錄下來，待後續再統一維護到相關文檔上；

3) 部分文檔需要及時的進行處理，其他文檔則延後處理。該方案適用於建設時間較少但參與人員較多的情況，這樣做的好處是在有限時間內可以確保核心信息能夠通過文檔來準確、無誤的傳遞給所有項目組成員，但又不會對項目進度造成很大的影響。在實際建設工作中，甲方項目經理應依據項目建設的需要來指定應當優先解決的文檔列表，剩餘的文檔則應要求乙方團隊在約定的時間統一進行處理。

3. 性能類質量問題

性能類的質量問題指軟體的響應時間、吞吐量、並發數或資源利用率等性能指標無法達到預期的目標或是無法滿足軟體正常使用的要求，一般是由軟體設計、軟硬體架構、硬體性能或網路等方面的原因所共同導致的。但這裡需要注意的是，在大多數情況下性能問題都是針對運行在生產環境上的最終產品，而此時軟體的建設工作、部署工作都已基本完成，任何一點改動都會對軟體造成極大的影響。因此甲方項目經理在對該類問題進行處置時，需要把握以下原則：一是不能改變軟體已有的功能；二是盡量避免對軟體架構和軟體代碼做出調整；三是優先考慮通過增強硬體配置的方式來提升性能。

依據筆者的個人經驗，甲方項目經理在處置該類問題時可以採用以下的方法：一是增強硬體配置，在預算允許的情況下，這種方法見效最快，且不會影響已有的軟體結構；二是減少軟體前後台的交互，通過減少交互次數的方式來提升效率。但需要對相關的功能重新進行設計，對軟體的功能和結構會造成較大的影響；三是優化邏輯演算法，通過改進演算法複雜度的方式，來提升運行速度。這種方式對相關人員的能力要求較高，且需要對代碼有較大的改動；四是優化資料庫及查詢SQL，通過創建索引、優化SQL等方式，增加數據查詢效率、縮短查詢時間，從而提升整體性能。其中，減少前後台交互和優化邏輯這兩種方法，均需要對軟體的設計、架構進行大的修改，一方面會增加項目的進度風險，另一方面大量的代碼修改，也會增加軟體的質量風險。因此甲方項目經理在使用時，需要根據實際情況謹慎使用。

4. 穩定類質量問題

穩定類的質量問題指軟體系統在指定的運行環境下，因某些軟硬體層面的故障而導致其無法長時間正常運行的情況。通常情況下，導致此類問題的原因主要有：軟硬體的架構問題、操作系統和應用軟體的漏洞、未發現的bug等。該類問題可以分為必然問題和偶然問題兩種，其中必然問題指在滿足某些特定要求時，一定會發生的問題，如登陸用戶超過某一數值時系統會崩潰等；而偶然問題則是指發生原因無法預測，且很難重現的問題，如數據丟失等。對於甲方項目經理來說，其在對此類問題進行處置時應遵循以下原則：對於必然問題來說，首先對導致該問題的原因進行深入的分析，其次在分析結果的基礎上進行相應的處理，以防止同類型的問題再次發生；對於偶然問題來說，由於導致該問題的原因無法明確，因此甲方項目經理可以依據問題的表象來制定相應的預防、止損措施，從而降低該問題對軟體的影響。

但這裡需要注意的是，和性能類問題一樣，穩定問題也是針對運行在生產環境上的最終產品，而此時軟體的建設工作、部署工作都已基本完成，任何一點改動都會對軟體造成極大的影響。因此甲方項目經理在對該類問題進行處置時，如非必要盡量不要對軟體架構和軟體代碼進行調整。依據筆者的個人經驗，甲方項目經理在對穩定問題進行處置時，可以參照如下的方法：一是軟體產品相關的伺服器在架構上應採用雙機熱備的形式，這樣在某一台伺服器出現故障時，還有另外一台伺服器可以繼續提供服務，從而有效的確保了服務的延續性；二是資料庫應採用熱備技術，如ORACLE

RAC，可以有效的保護數據不受故障、災難、錯誤和崩潰的影響；三是定期對相關的軟、硬體環境進行巡檢、維護和升級工作，以確保相關運行環境的穩定性；四是對軟體架構進行重構，從而構建更加健壯的架構體系。

5. 安全類質量問題

安全類的質量問題指軟體系統在遭到外部惡意攻擊時，無法繼續正常運行或相關的文件、數據被篡改或竊取。通常情況下，導致此類問題的原因主要有：軟硬體架構、軟體設計、代碼編寫、操作系統或應用軟體漏洞以及網路等。這裡需要注意的是，軟體系統一旦出現了安全方面的問題，就勢必會導致其無法繼續對外提供業務服務，從而造成嚴重的生產事故。因此，對於甲方項目經理來說，儘管此類問題針對的是運行在生產環境上的最終產品，但其在對問題進行處置時並不需要考慮是否會對軟體產品造成影響。

甲方項目經理在對安全類質量問題進行處置時，其通常可以採取以下步驟：一是暫停軟體產品對外的所有服務，以避免進一步的損失；二是分析問題原因並評估該問題的影響範圍；三是依據項目實際情況，結合相應的分析結果給出可行的解決方案；四是對乙方項目團隊的執行情況進行監督，並對最終結果驗證；五是通過備份文件，來恢復相應的數據，並重啟對外的服務。依據筆者的個人經驗，甲方項目經理在對安全問題進行處置時，可以參照如下的方法：

1) 加強關鍵數據加密處理。對涉密或敏感的文件、數據進行加密保護，以防止關鍵數據資產被篡改或竊取，同時要確保不影響用戶正常使用；

2) 增強訪問控制。依據用戶的身份、許可權等屬性來對其可操作的功能、可查看的數據和文檔做控制，確保數據不會被許可權以外的用戶接觸到；

3) 強化用戶認證。對系統中的所有用戶都採用UKEY來對其身份進行認證，保證了相關用戶身份的安全性和可信性。另外，應制定強制性的密碼標準，減少因人為因素而導致的安全風險；

4) 數據傳輸加密。系統在數據傳輸時，應支持常用的AES、RC4、3DES等多種演算法，支持隨機密鑰和統一密鑰兩種方式，以保障數據傳輸安全，防止被惡意篡改；

5) 藉助外部硬體。將UKEY作為用戶身份的認證標識，同時也可以用其作為數據傳輸加密的基礎。或者是增加相關的硬體安全設備，如堡壘機等；

6) 藉助外部力量，可以藉助專業的第三方安全服務機構，提供安全整體解決方案；

7) 定期對操作系統、應用軟體進行升級，防止系統漏洞影響軟體的安全。

12.5. 常見的質量問題

在本節中，筆者依據自身的工作經驗，對項目建設過程中經常出現質量問題進行了梳理，主要涉及需求、設計、測試和人員等多個方面，並基於個人的經驗給出了相應的解決方案和注意事項。具體如下：

1. 軟體功能不可用

軟體功能不可用是項目建設過程中經常出現的一種功能類質量問題，主要指軟體產品因代碼bug、邏輯錯誤、需求理解錯誤、架構缺陷、網路異常等原因而使得軟體用戶的相關操作，如登陸、查詢、新增、修改或刪除等，無法得到預期的結果。這類問題通常會導致軟體產品的部分功能或全部功能處於不可用的狀態，從而使其無法繼續對外提供相應的業務支持服務。可以說，這類問題是所有質量問題中對軟體影響最為嚴重的一種，主要體現在以下兩個方面：一是在建設階段，其會因軟體不可用而導致項目工作進度的延期或停滯；二是在正式使用後，其會對軟體產品的可用性、可靠性和穩定性造成嚴重的影響。因此，為了避免其對軟體使用的影響，甲方項目經理應加強對軟體測試工作的管理，以確保能夠儘可能的消除所有的此類問題。

對於甲方項目經理來說，其在對此類問題進行處置時應遵循以下原則：一是必須解決。此類問題一旦出現就必須予以解決，不能因任何理由而置之不理；二是優先處理。相對於項目中存在的其他問題，此類問題應該優先予以解決。依據筆者的個人經驗，甲方項目經理在進行處置時，可以採用如下步驟：一是要求乙方廠商分析該問題產生的原因，並評估其影響範圍；二是依據問題原因制定可行的解決方案，必要時可以邀請外部專家進行評審；三是監督該解決方案的執行情況；四是對類似的功能進行梳理，以防止發生同類型問題。

2. 乙方建設方案缺陷

乙方建設方案指乙方團隊為完成項目建設工作而編製的各類文檔，如需求規格說明書、技術方案、產品設計等。這些文檔均為乙方項目團隊在對業務需求充分理解的基礎上，結合自身的工作經驗和技術特色而制定的項目建設實施措施和工作規劃，是乙方項目團隊後續項目建設工作的主要依據和實現標準。因乙方建設方案缺陷而導致的質量問題，主要指乙方項目團隊成員由於對業務需求理解不充分、制定方案時考慮不全面或是成員能力限制等方面的原因，而造成相關的建設方案在後續的代碼開發過程中無法滿足項目建設要求的情況。

甲方項目經理在處理這種類型的問題時，可以採用以下兩種方案：一種方案是要求乙方項目團隊重新制定相關的建設方案，然後基於新的方案對系統進行全方位的調整。該方案的好處是修正了建設方案中的缺陷，確保了項目向著正確的方向前進，但壞處則是因對項目的軟體架構、程序結構等造成較大的改動，可能會導致已完成工作部分重做或全部重做，進而造成項目延期的風險；另一種方案是保持當前的建設方案不變，通過修改業務需求的方式，使相關方案能夠滿足項目建設要求，即通過技術、時間來對業務進行倒逼，使其做出相應的改變。該方案的好處是保持了技術框架的完整，但壞處也是顯而易見的，就是無法滿足業務需求。

在實際的項目中，甲方項目經理並不會單獨的採用某一方案來處理該類問題，而是會基於項目實際情況來綜合這兩種方案從而給出最終的解決方案：一方面同業務負責人就業務需求進行溝通，將可以調整的需求進行變更；另一方面，在變更後的需求基礎上對技術方案或產品設計進行調整。其中，兩種解決方案的協調標準就是項目「完成」定義，如其傾向於時間，則應增加業務的調整而減少對軟體的調整；如其傾向於功能，則應減少業務的調整而增加對軟體的調整。

3. 文檔與工作不一致

在項目建設過程中，我們有時會遇到項目文檔內容與實際工作不一致的情況，如乙方團隊按照變更的業務需求對代碼進行了調整，但未對需求規格說明書、技術方案、產品設計和測試案例等文檔進行相應的修改，從而使得實際的軟體功能與文檔中所描述的內容存在一定程度上的差異。依據筆者的個人經驗來看，造成這種情況的原因主要有以下兩點：一是為了確保項目的最終完成時間，甲方項目經理同意乙方團隊先行實現軟體的相關功能，待時間允許後再對文檔進行修改；二是相關人員因工作疏忽或不盡責等方面的原因，未能及時對相應的文檔進行修改。

對於甲方項目經理來說，儘管這類問題在有限的時間內有效的保證了軟體功能的實現，但由於缺乏相應文檔的支持，還是會給項目建設工作造成一定程度的影響，主要有以下幾個方面：一是不利於甲方項目經理管理工作的開展。大多數情況下，甲方項目經理都是通過相應的文檔來了解和掌握乙方團隊的實現方案、設計思路等建設相關的內容。但這類問題會使得其無法全面、真實的掌握乙方團隊工作情況，從而導致其項目管理工作無法有效的開展；二是不利於變更信息在團隊內部的傳遞。如不將變更信息落實到相關文檔上，那麼變更信息就只能通過口頭、郵件等個人途徑進行傳遞，一方面無法確保變更信息在團隊內形成統一的認識，另一方面相關信息在傳遞過程中也可能會存在丟失或失真的情況；三是不利於團隊協作。團隊成員通過項目文檔獲取到的信息與實際工作情況不一致，可能會導致不同成員之間的工作成果因參照標準的不同而無法形成為一個有機的整體；四是不利於工作的交接。對於工作交接人員來說，項目文檔是其了解和掌握項目建設工作的主要途徑，但如果文檔內容與實際工作存在不一致或衝突的情況，勢必會使其無法有效的開展後續的工作。

依據筆者的個人經驗來看，甲方項目經理在處理這種質量問題時，可以採取以下方案：一是明確文檔的責任人。對於文檔責任人不清晰的情況，甲方項目經理應要求乙方團隊明確具體的責任人，由其來負責對相關文檔的修改、維護工作；二是制定文檔修改計劃。對於無法立即完成修改的文檔，可以通過制定修改計劃的方式，來使相關的修改工作處於可管理的狀態；三是編製信息變更表。為了避免因無法對文檔進行維護而導致的相關問題，甲方項目經理應要求乙方團隊通過編製信息變更表的方式來記錄所有信息變更的內容，從而確保變更信息可以及時、準確的傳遞給所有團隊成員，並為其他工作的開展提供參考依據。其中，信息變更表如下表12.2所示：

表 12.2

推薦閱讀：