??不景氣的經(jīng)濟，不斷高漲的油價，嚴重影響了商業(yè)活動，每一個人都在尋找新的途徑，用來抵消新增加的成本：能源。這里提供了10種減少軟件開發(fā)成本的方法。
??1、 良好的功能需求文檔
??沒有文檔化的需求，系統(tǒng)就存在不能滿足客戶期望的隱患。“比如，也許它不能按照客戶認為應(yīng)該的方式工作，即便是開發(fā)團隊認為他們的工作一直符合歸檔的需求。這將導(dǎo)致項目返工、延期發(fā)布、增加成本以及客戶和軟件團隊之間潛在的矛盾。
??2、 非功能的需求應(yīng)盡早定義，盡早明確
??大多數(shù)組織都集中在系統(tǒng)的功能方面，即它做什么，而不是它怎么做?！胺枪δ艿囊匕ㄒ磺?，從性能到安全再到可用性。
??缺少清晰的、盡早定義的非功能的需求，發(fā)布后的系統(tǒng)可能和客戶想的功能一樣——但它太難用、速度奇慢、不安全、不可靠或者擴展性太差?！斑@將再一次”導(dǎo)致開發(fā)組返工——些非功能的領(lǐng)域?qū)τ诋a(chǎn)品的設(shè)計是必須的，再沒有重新啟動項目的情況下，很難去修正它們?！?br /> ??3、保 證適當(dāng)?shù)淖兏刂七^程
??沒有變更控制，系統(tǒng)開發(fā)會發(fā)現(xiàn)自己處于不確定的狀態(tài)?！袄纾盇dcock解釋說，“隨著項目的進行，越來越多的需求面臨著變更，每個變更都沒有正確的影響評估?！泵恳粋€變更都應(yīng)該被嚴格控制。每一個允許的變更都應(yīng)該在完整的影響評估之后，要分析它對項目的時間進度和成本的影響。
??4、 使用配置管理系統(tǒng)管理代碼、數(shù)據(jù)和文檔
??沒有配置單管理系統(tǒng)，做高質(zhì)量的測試是不可能的?！斑@是因為你不確定正在測試的軟件或者文檔是不是正確的版本，或者發(fā)布給用戶的版本是不是完全測試的。”配置管理比較差的組織可能測試的是一個版本，而發(fā)布的是另外一個版本，其中包含了還沒有經(jīng)過測試的特性。
??5、 集中在缺陷預(yù)防，而不是測試
??項目開始時在需求文檔中修正一個錯誤遠比它開發(fā)完成后再修正更快速更便宜?！斑@已經(jīng)被證明很多次，在項目周期中越晚發(fā)現(xiàn)一個缺陷，修正它花費就越多。”
??6、在需求定義階段開始設(shè)計用戶驗收測試
??7、在系統(tǒng)設(shè)計階段開始設(shè)計系統(tǒng)測試
??8、重點關(guān)注單元測試
??每一個人都知道，在開發(fā)過程中越早的發(fā)現(xiàn)缺陷，修復(fù)它就越容易、越快速、越便宜。對藏身于代碼中的缺陷來說，單元測試是發(fā)現(xiàn)它們*早的階段。
??9 、計劃基于風(fēng)險的測試
??由于各種原因，比如固定的發(fā)布期限，開發(fā)組的拖延，測試時間總是非常有限的，這將意味著并不是所有原先計劃的測試都能得到執(zhí)行?！霸谶@個項目中，那些被認為是對產(chǎn)品成功非常重要的元素被充分測試。所以，測試應(yīng)該總是集中在系統(tǒng)的“* 高風(fēng)險級”的區(qū)域，根據(jù)測試時間的要求，然后是“中等風(fēng)險”和低風(fēng)險的元素?！?br /> ??當(dāng)面臨時間壓力時，這種基于風(fēng)險的方法可以保 證系統(tǒng)中還沒有測試的元素都處于* 低風(fēng)險區(qū)域。
??10、 在發(fā)現(xiàn)錯誤更便宜更的時候，盡早使用工具來發(fā)現(xiàn)功能和非功能方面的錯誤
??在開發(fā)的早期開始階段，如果創(chuàng)建并維護好一套自動化的測試工具，它就可以重復(fù)使用做“冒煙測試”?！斑@種方法可以很快的、更早的發(fā)現(xiàn)潛在的很多缺陷，為以后的測試階段節(jié)省寶貴的時間。”
??另外一些特別的工具有時還能發(fā)現(xiàn)系統(tǒng)設(shè)計上的缺點，這些缺點應(yīng)該發(fā)現(xiàn)的越早越好?！袄?，早期對部分系統(tǒng)的性能測試可以暴露設(shè)計很差的模塊，它發(fā)布后會拖累整個系統(tǒng)的性能到用戶的容忍度以外?！边@種情況下，該模塊很容易被確認并被隔離，很容易修正或者重寫。如果在系統(tǒng)交付測試后或者發(fā)布前才去做性能測試，這種確定過程將困難很多。