軟件項目管理：質(zhì)量先行

1、軟件項目管理：質(zhì)量先行軟件開發(fā)為何不能像硬件開發(fā)那樣可控？軟件質(zhì)量之旅將帶給我們一些啟 示。提到軟件產(chǎn)品開發(fā)，我們的腦海里總是浮現(xiàn)出這樣的情景：開發(fā)組的每一 位成員都在辛苦地工作，加班加點，甚至通宵達旦。雖然項目經(jīng)理一次又一次 地修改了進度計劃，而實際的開發(fā)情況卻總是令人擔憂，以至于每次向領(lǐng)導匯 報工作的時候，總是覺得以前制定的計劃沒有很好完成，總是覺得人力資源不 夠，總是覺得沒有太多的時間。等到代碼終于開發(fā)完成了，測試進度同樣非常 令人擔憂，每一個小BUG都要花很長的時間去查找，改了某一個小錯誤卻又引 起了很多新的錯誤，結(jié)果產(chǎn)品發(fā)布遙遙無期，而項目組里的每一位成員已經(jīng)筋 疲力盡。怎樣擺脫這樣

2、的困境？為何軟件開發(fā)項目管理這么困難？為何我們做的計 劃總是不能按時完成？為何軟件開發(fā)不能像硬件開發(fā)那樣可以控制？軟件開發(fā)是完全依靠人的大腦思維產(chǎn)生出產(chǎn)品，而每個人的大腦思維是不 一樣的，因此在軟件開發(fā)過程中有太多不確定、可變化的因素。那么我們怎樣 把握住這些變化因素呢？軟件項目管理一一質(zhì)量先行，如果我們能夠控制軟件生命周期每一個階段 的質(zhì)量，就能很好地控制了軟件開發(fā)的整個過程。軟件產(chǎn)品的質(zhì)量是個很大的概念，因為軟件產(chǎn)品完全是人們大腦思維的產(chǎn) 物，是將大腦里無形的思維變成可以解決實際問題的一組界面或者組件。在這 樣一個復雜的過程中，應該如何保證質(zhì)量呢？有人想到了 IS0900Q CMM,也 有

3、人提出反對意見，認為應該用敏捷開發(fā)。其實，不管用什么樣的開發(fā)過程， 關(guān)鍵是找到這些過程的本質(zhì)。有人說，ISO和CMM到中國來怎么就變了味了？其實，我們只學到了怎樣去做，但是不知道為什么要這樣做。大家都知道在產(chǎn)品立項之前要寫市場分析 報告，但不了解為什么要寫，市場分析報告的重要性有多高？不是資深開發(fā)人 員很難理解其重要性，如果是簡單地去寫一篇形式上的文檔，那么，除了負擔 之外就沒有其它用途了。有些人又想到了測試，覺得是我們測試的力度不夠，所以產(chǎn)品質(zhì)量不過 關(guān)。其實，軟件開發(fā)的質(zhì)量保證從初就應該開始了，如果到了測試階段才重視 就已經(jīng)晚了。軟件產(chǎn)品開發(fā)過程，不管采用瀑布式模型還是迭代式模型，都離 不

4、開需求、設(shè)計、編碼、測試這幾個階段。在迭代式開發(fā)中，這幾個階段也是 周期性出現(xiàn)的。怎樣把握好每個階段的質(zhì)量，確實不是一件容易的事。對于軟件產(chǎn)品的測 試，不管是單元測試還是集成、系統(tǒng)測試，這方面的介紹已經(jīng)很多了，因此重 點介紹一下需求、設(shè)計和編碼階段的質(zhì)量保證。讓我們開始一次質(zhì)量之旅吧，站就是需求分析。在需求分析過程中，如何進行質(zhì)量保證呢？我們平時可能更多地關(guān)注需求 本身，卻忽視了一個很重要的因素，那就是市場。因為我們開發(fā)出來的產(chǎn)品是 直接面向市場的，如果費了很多的人力物力開發(fā)出來一個沒有市場前景，缺乏 競爭力的產(chǎn)品，那么所有的努力都是白費。如何充分考慮市場因素，具體可以 從以下幾個方面進行。首

5、先，判斷需求是否符合愿景目標，所謂愿景目標就是我們開發(fā)出來的產(chǎn) 品能夠給我們的用戶帶來什么樣的好處？如果有些需求沒有被包含在愿景目標 里，那么這樣的需求其實就背離了我們開發(fā)產(chǎn)品的初衷。其次，判斷產(chǎn)品需求 能夠給企業(yè)帶來多大的利潤，如果某個需求只是代表個別用戶的需求，并不能 給企業(yè)帶來較大的利潤，但又花費甚高，就可以考慮刪除。后，與競爭對手相 比核心競爭力有哪些？如果核心競爭力不夠，就應該考慮重新進行需求分析， 因為如果沒有核心競爭力，開發(fā)出來的產(chǎn)品就沒有市場。在排除了市場因素產(chǎn)生的風險之后，我們應該保證需求描述的質(zhì)量。人與 人的交流總會存在一些誤會，同樣一句話，心情不好與心情好的時候聽起來可

6、能會截然相反，正是因為人們之間存在著理解上的偏差，在描述需求的語言上 就應該注意盡量避免歧義的產(chǎn)生。如果對 UML 比較熟悉的話，需求分析可以利 用 UML 工具進行，這樣可以減少一些自然語言引起的歧義，但是并不是所有的 用戶都了解 UML 各種圖形的意思，與用戶溝通起來存在障礙，除了工具之外， 我們可以從以下幾個方面來保證需求描述的質(zhì)量。首先，看句子和段落是否簡短。長句子看起來會非常困難，很難弄懂真正 的需求：另外，過長的句子和段落容易讓人忽視一些需求。所以，如果一個句 子不能完全描述清楚需求，應該將其拆分成多個小句子。其次，句子是否有語法錯誤，還要注意標點符號，有時，標點符號點錯了 就完全

7、成了另外一個意思。再次，是否存在模糊不清的需求，出現(xiàn) “可能，大 概，或者 ”等詞匯表述。后，注意是否存在形容詞及比較性詞語，比如：容易的、快速的、方便 的、有效的、許多、很少、簡單、復雜、新的、界面友好的、減少、擴大，不 小于等等，需要將描述性詞語進行量化，并且給出具體值或者范圍。另外，保證需求質(zhì)量的一個很重要的因素就是需求是否細化，如果需求不 細化就很容易造成代碼的返工，出現(xiàn)程序員盡管加班加點卻總是不能如期完成任務的情景。怎樣才能判斷需求細化的程度呢？需求細化程度確實很難把握， 什么樣的需求可以算是比較細了，不用再進行細化了呢？答案是：是否可以將需求寫出相應的測試用例，如果寫不出來，就說明

8、需 求還不是很細，還需要進一步進行細化。把握住了需求分析這一關(guān)，下一站我們就可以進行設(shè)計了。軟件架構(gòu)設(shè)計在軟件產(chǎn)品開發(fā)周期中占有很重要的位置，我們開發(fā)出來的 軟件產(chǎn)品在開發(fā)伊始到產(chǎn)品發(fā)布會涉及到方方面面的角色。例如：用戶、項目管理人員、程序員、測試員、維護人員等等。不同的角 色對架構(gòu)設(shè)計的要求也不相同。對于程序員來說更關(guān)注模塊是否清晰，類的功 能是否單一等等，對于測試人員來說，關(guān)注的是系統(tǒng)的可測試性。對于維護人 員來講，系統(tǒng)的擴展性、可維護性如何？一個高質(zhì)量的軟件架構(gòu)，應該限度的考慮并滿足不同角色的不同要求。因 此我們在進行軟件設(shè)計的時候，應該進行全面的考慮。一般用來衡量軟件設(shè)計 質(zhì)量的標準可

9、以從以下幾個方面來考慮：功能性包括完全性、正確性、安全性、兼容性、互用性。效率產(chǎn)品運行的時間效率和利用的硬件資源兩方面。維護性包括架構(gòu)的可改正性，可擴充性以及可測試性。如果用戶的一個很小的需 求變更會引起架構(gòu)設(shè)計很大的變化，那么這樣的架構(gòu)設(shè)計的可改正性和可擴充 性就比較差。可移植性包括硬件的獨立性、軟件獨立性、可安裝性、可重用性。軟件設(shè)計是否模 塊化、可復用性都是應該考慮的因素。可靠性包括無缺陷性、容錯性、可用性。使用性包括可理解性、易學習性、可操作性、易溝通性。我們軟件的終目的是讓 用戶來使用的，如果易用性不好，可操作性不好都會影響用戶對軟件的接納程 度。因此軟件的可用性也是非常重要的。完成

10、了設(shè)計之后，接下來就要進行編碼了。在編碼階段，應該怎樣保證我 們的編碼質(zhì)量呢？兩個比較有效的方法就是代碼走查和單元測試。代碼走查可以以組為單位進行，代碼走查可以發(fā)現(xiàn)代碼是否符合代碼規(guī) 范，是否存在拼寫錯誤，是否具有可讀性，類和方法是否過于冗長，類之間是 否存在高耦合性。代碼質(zhì)量的一個很重要的標準就是代碼的可讀性，可讀性不一定是簡單的 代碼，而是容易理解的代碼，因為過于復雜的代碼難以測試和維護，同時出錯 的幾率也會更高。如果一個方法內(nèi)部的代碼很長，而且使用了很多令人難以理解的數(shù)據(jù)集， 就會帶來代碼維護的困難，因為很少有人能夠有效地分析它們，因此也就容易 出現(xiàn)缺陷和錯誤。類之間的耦合度會造成類與類之間的相互關(guān)聯(lián)，當一個類發(fā) 生改變時會使其他的類發(fā)生意想不到的變化，一般從導入類的個數(shù)判斷類之間 的耦合度，如果導入類的個數(shù)很多，或者該類的 public 方法太多都會導致類之 間的高耦合性增加。編碼階段另一個非常重要的手段就是單元測試。單元測試是一個模塊的功 能及常規(guī)錯誤測試，單元測試是由程序員進行的，一般單元測試能夠捕獲 80% 的 bug 。因此單元測試對保證代碼質(zhì)量方面占有很重要的地位，由于這方面內(nèi)容 比較多，我