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