軟件開發(fā)為何不能像硬件開發(fā)那樣可控？軟件質(zhì)量之旅將帶給我們一些啟示。
提到軟件產(chǎn)品開發(fā)，我們的腦海里總是浮現(xiàn)出這樣的情景：開發(fā)組的每一位成員都在辛苦地工作，加班加點，甚至通宵達旦。雖然項目經(jīng)理一次又一次地修改了進度計劃，而實際的開發(fā)情況卻總是令人擔憂，以至于每次向領導匯報工作的時候，總是覺得以前制定的計劃沒有很好完成，總是覺得人力資源不夠，總是覺得沒有太多的時間。等到代碼終于開發(fā)完成了，測試進度同樣非常令人擔憂，每一個小BUG都要花很長的時間去查找，改了某一個小錯誤卻又引起了很多新的錯誤，結(jié)果產(chǎn)品發(fā)布遙遙無期，而項目組里的每一位成員已經(jīng)筋疲力盡。
怎樣擺脫這樣的困境？為何軟件開發(fā)項目管理這么困難？為何我們做的計劃總是不能按時完成？為何軟件開發(fā)不能像硬件開發(fā)那樣可以控制？
軟件開發(fā)是完全依靠人的大腦思維產(chǎn)生出產(chǎn)品，而每個人的大腦思維是不一樣的，因此在軟件開發(fā)過程中有太多不確定、可變化的因素。那么我們怎樣把握住這些變化因素呢？
軟件項目管理——質(zhì)量先行，如果我們能夠控制軟件生命周期每一個階段的質(zhì)量，就能很好地控制了軟件開發(fā)的整個過程。
軟件產(chǎn)品的質(zhì)量是個很大的概念，因為軟件產(chǎn)品完全是人們大腦思維的產(chǎn)物，是將大腦里無形的思維變成可以解決實際問題的一組界面或者組件。在這樣一個復雜的過程中，應該如何保證質(zhì)量呢？有人想到了ISO9000、CMM，也有人提出反對意見，認為應該用敏捷開發(fā)。其實，不管用什么樣的開發(fā)過程，關鍵是找到這些過程的本質(zhì)。
有人說，ISO和CMM到中國來怎么就變了味了？其實，我們只學到了怎樣去做，但是不知道為什么要這樣做。大家都知道在產(chǎn)品立項之前要寫市場分析報告，但不了解為什么要寫，市場分析報告的重要性有多高？不是資深開發(fā)人員很難理解其重要性，如果是簡單地去寫一篇形式上的文檔，那么，除了負擔之外就沒有其它用途了。
有些人又想到了測試，覺得是我們測試的力度不夠，所以產(chǎn)品質(zhì)量不過關。
其實，軟件開發(fā)的質(zhì)量保證從最初就應該開始了，如果到了測試階段才重視就已經(jīng)晚了。軟件產(chǎn)品開發(fā)過程，不管采用瀑布式模型還是迭代式模型，都離不開需求、設計、編碼、測試這幾個階段。在迭代式開發(fā)中，這幾個階段也是周期性出現(xiàn)的。
怎樣把握好每個階段的質(zhì)量，確實不是一件容易的事。對于軟件產(chǎn)品的測試，不管是單元測試還是集成、系統(tǒng)測試，這方面的介紹已經(jīng)很多了，因此筆者重點介紹一下需求、設計和編碼階段的質(zhì)量保證。
讓我們開始一次質(zhì)量之旅吧，第一站就是需求分析。
在需求分析過程中，如何進行質(zhì)量保證呢？我們平時可能更多地關注需求本身，卻忽視了一個很重要的因素，那就是市場。因為我們開發(fā)出來的產(chǎn)品是直接面向市場的，如果費了很多的人力物力開發(fā)出來一個沒有市場前景，缺乏競爭力的產(chǎn)品，那么所有的努力都是白費。如何充分考慮市場因素，具體可以從以下幾個方面進行。
首先，判斷需求是否符合愿景目標，所謂愿景目標就是我們開發(fā)出來的產(chǎn)品能夠給我們的用戶帶來什么樣的好處？如果有些需求沒有被包含在愿景目標里，那么這樣的需求其實就背離了我們開發(fā)產(chǎn)品的初衷。其次，判斷產(chǎn)品需求能夠給企業(yè)帶來多大的利潤，如果某個需求只是代表個別用戶的需求，并不能給企業(yè)帶來較大的利潤，但又花費甚高，就可以考慮刪除。最后，與競爭對手相比核心競爭力有哪些？如果核心競爭力不夠，就應該考慮重新進行需求分析，因為如果沒有核心競爭力，開發(fā)出來的產(chǎn)品就沒有市場。
提到軟件產(chǎn)品開發(fā)，我們的腦海里總是浮現(xiàn)出這樣的情景：開發(fā)組的每一位成員都在辛苦地工作，加班加點，甚至通宵達旦。雖然項目經(jīng)理一次又一次地修改了進度計劃，而實際的開發(fā)情況卻總是令人擔憂，以至于每次向領導匯報工作的時候，總是覺得以前制定的計劃沒有很好完成，總是覺得人力資源不夠，總是覺得沒有太多的時間。等到代碼終于開發(fā)完成了，測試進度同樣非常令人擔憂，每一個小BUG都要花很長的時間去查找，改了某一個小錯誤卻又引起了很多新的錯誤，結(jié)果產(chǎn)品發(fā)布遙遙無期，而項目組里的每一位成員已經(jīng)筋疲力盡。
怎樣擺脫這樣的困境？為何軟件開發(fā)項目管理這么困難？為何我們做的計劃總是不能按時完成？為何軟件開發(fā)不能像硬件開發(fā)那樣可以控制？
軟件開發(fā)是完全依靠人的大腦思維產(chǎn)生出產(chǎn)品，而每個人的大腦思維是不一樣的，因此在軟件開發(fā)過程中有太多不確定、可變化的因素。那么我們怎樣把握住這些變化因素呢？
軟件項目管理——質(zhì)量先行，如果我們能夠控制軟件生命周期每一個階段的質(zhì)量，就能很好地控制了軟件開發(fā)的整個過程。
軟件產(chǎn)品的質(zhì)量是個很大的概念，因為軟件產(chǎn)品完全是人們大腦思維的產(chǎn)物，是將大腦里無形的思維變成可以解決實際問題的一組界面或者組件。在這樣一個復雜的過程中，應該如何保證質(zhì)量呢？有人想到了ISO9000、CMM，也有人提出反對意見，認為應該用敏捷開發(fā)。其實，不管用什么樣的開發(fā)過程，關鍵是找到這些過程的本質(zhì)。
有人說，ISO和CMM到中國來怎么就變了味了？其實，我們只學到了怎樣去做，但是不知道為什么要這樣做。大家都知道在產(chǎn)品立項之前要寫市場分析報告，但不了解為什么要寫，市場分析報告的重要性有多高？不是資深開發(fā)人員很難理解其重要性，如果是簡單地去寫一篇形式上的文檔，那么，除了負擔之外就沒有其它用途了。
有些人又想到了測試，覺得是我們測試的力度不夠，所以產(chǎn)品質(zhì)量不過關。
其實，軟件開發(fā)的質(zhì)量保證從最初就應該開始了，如果到了測試階段才重視就已經(jīng)晚了。軟件產(chǎn)品開發(fā)過程，不管采用瀑布式模型還是迭代式模型，都離不開需求、設計、編碼、測試這幾個階段。在迭代式開發(fā)中，這幾個階段也是周期性出現(xiàn)的。
怎樣把握好每個階段的質(zhì)量，確實不是一件容易的事。對于軟件產(chǎn)品的測試，不管是單元測試還是集成、系統(tǒng)測試，這方面的介紹已經(jīng)很多了，因此筆者重點介紹一下需求、設計和編碼階段的質(zhì)量保證。
讓我們開始一次質(zhì)量之旅吧，第一站就是需求分析。
在需求分析過程中，如何進行質(zhì)量保證呢？我們平時可能更多地關注需求本身，卻忽視了一個很重要的因素，那就是市場。因為我們開發(fā)出來的產(chǎn)品是直接面向市場的，如果費了很多的人力物力開發(fā)出來一個沒有市場前景，缺乏競爭力的產(chǎn)品，那么所有的努力都是白費。如何充分考慮市場因素，具體可以從以下幾個方面進行。
首先，判斷需求是否符合愿景目標，所謂愿景目標就是我們開發(fā)出來的產(chǎn)品能夠給我們的用戶帶來什么樣的好處？如果有些需求沒有被包含在愿景目標里，那么這樣的需求其實就背離了我們開發(fā)產(chǎn)品的初衷。其次，判斷產(chǎn)品需求能夠給企業(yè)帶來多大的利潤，如果某個需求只是代表個別用戶的需求，并不能給企業(yè)帶來較大的利潤，但又花費甚高，就可以考慮刪除。最后，與競爭對手相比核心競爭力有哪些？如果核心競爭力不夠，就應該考慮重新進行需求分析，因為如果沒有核心競爭力，開發(fā)出來的產(chǎn)品就沒有市場。