建站
咨詢
售后
建站咨詢
新聞中心
本文的作者Capers Jones是Namcook Analytics公司的副總裁和***技術總監(jiān)。他一直在收集軟件質量和開發(fā)效率上的數據。他寫了幾十本關于軟件質量、***實踐方法、評估、測量方面的著作。
十余年的城子河網站建設經驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。成都營銷網站建設的優(yōu)勢是能夠根據用戶設備顯示端的尺寸不同，自動調整城子河建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯從事“城子河網站設計”,“城子河網站推廣”以來，每個客戶項目都認真落實執(zhí)行。
在處理軟件需求時，有三個問題一直折磨著我們，并使軟件項目消耗無數資金。其中很大一部分都產生在項目交付并運行后的新需求的收集工作中。
下面是在軟件需求處理中三個廣泛存在的問題，需要我們去尋找比當前普遍的常規(guī)做法更有效的解決方案：
- 很多需求是非常危險或是有毒的，需要堅決抵制。
- 很多客戶堅持要在軟件中強加入一些額外的、多余的功能。
- 需求永遠提不完，并以每月1%的速率增加。
軟件開發(fā)者道德上有義務、職業(yè)上有責任在這些問題上提醒客戶，并盡可能的幫助他們解決這些問題。換句話說，軟件開發(fā)者需要充當的角色類似于一個醫(yī)生。我們有責任幫助客戶診斷目前已知的需求，并開出有效的處方。
當然，一旦用戶需求收集完成，分析整理完成，承諾的軟件規(guī)格就應該如實的交付給客戶。然而，為了保證軟件能安全有效的交付，危險的或有毒的需求必須被除去，多余的和不必要的需求需要讓用戶知道，潛在的能導致需求滋生的不清晰的地方需要被明確、量化。用戶應該從軟件開發(fā)技術團隊那里獲得專業(yè)的幫助，而不應該在需求收集和分析上被動的扮演旁觀者角色。
不幸的是，需求上的缺陷并不能通過普通的測試來消除。如果需求上的錯誤未能預防而出現，或沒有能夠通過常規(guī)的檢查或其它方法消除，那么，從需求上構造出來的測試用例只能再次證實需求的正確，而不是發(fā)現其中的錯誤。(這就是為什么多少年的軟件測試都不曾發(fā)現并消除”2000年”問題)
另一類需求上的問題，對于一些全新的創(chuàng)造性的軟件應用，很可能最初用戶只有原創(chuàng)者，沒有第二人。參考一些成功的軟件的歷史，如APL編程語言，***個電子制表軟件，早期的Web搜索引擎(之后成為谷歌)。
這些具有革命性的應用軟件全是發(fā)明人自己用來解決他們自己的問題的。他們并不是按照常規(guī)概念上的“用戶需求”開發(fā)出來的。除非演示程序被開發(fā)完成，其他人基本無法認識到這些軟件發(fā)明的價值所在。因此，“用戶需求”對于一些全新的革命性的軟件來說不是能完全適用的，除非它們已經公開發(fā)布。
軟件需求會不斷的發(fā)展、繁殖、變化，在其隨后的設計和編碼階段統計出的數據，每月增加的量大概是1%到4%，基于這種現狀，很顯然，要想達到對需求的完全理解是十分困難的。
需求是軟件開發(fā)的重要一環(huán)節(jié)，但由于摻雜著有毒的需求，缺失的需求和多余的需求，使得簡單的諸如“品質的標準就是照需求完成”這樣的定義成為了軟件工業(yè)的毒藥。
軟件交付之后
“增長的需求”這個問題經常不受重視。一旦軟件應用交付給客戶或用戶，需求并不是終止或不變了。對于大多數的應用，需求的增長的延續(xù)會一直伴隨著應用的使用期間。它們增長的速率***能達到每年15%。
因為需求在增長，軟件應用的體量也會變大——不論從功能點，邏輯代碼量或其它尺度測量。
為了說明這種持續(xù)性增長，下面的表格顯示了一個我研究的大型Java應用的變化。
| 測量周期 | 功能點 | 邏輯代碼量 |
| 1 需求階段結束時 | 10,000 | 530,000 |
| 2 需求補充 | 2,000 | 106,000 |
| 3 計劃交付量 | 12,000 | 636,000 |
| 4 延期的功能量 | - 4,800 | - 254,400 |
| 5 ***提交給客戶的量 | 7,200 | 381,600 |
| 6 一年使用后 | 12,000 | 636,000 |
| 7 2年使用后 | 13,000 | 689,000 |
| 8 3年使用后 | 14,000 | 742,000 |
| 9 4年使用后 (中期提升) | 17,000 | 901,000 |
| 10 5年使用后 | 18,000 | 954,000 |
| 11 6年使用后 | 19,000 | 1,007,000 |
| 12 7年使用后 | 20,000 | 1,060,000 |
| 13 8年使用后 (中期提升) | 23,000 | 1,219,000 |
| 14 9年使用后 | 24,000 | 1,272,000 |
| 15 10年使用后 | 25,000 | 1,325,000 |
這些數字在第4年和第8年有一個超出平均值的增加。對于商業(yè)軟件，為了跟***的其它軟件競爭，有必要增加一些重大的新功能。這叫做“中期提升”。
正如你看到的，需求增加在軟件應用使用期間永不會停止，除非開發(fā)者開發(fā)出相同類型的新產品而放棄對老產品的支持。當然，一些軟件會很好的運行10幾年。例如，美國空中交通管制系統已經使用了超過30年了。
怎么辦…
軟件需求是軟件工程技術中最薄弱的一個環(huán)節(jié)。因為需求總是不完備的，總是含有錯誤的，這就要求軟件開發(fā)者一定要使用***進的軟件需求方法。用戶并沒有培訓過這些需求收集/分析技術，在沒有經過受訓的需求專家的幫助下無法提供完整無誤的需求，更重要的，軟件開發(fā)者應該理解——甚至擁抱——這樣的事實：在軟件交付運行之后，跟用戶關于需求的對話將不會停止。
英文原文：Chronic Requirements Problems
譯文鏈接：http://www.aqee.net/chronic-requirements-problems/
當前名稱：淺談軟件項目上的長期慢性需求問題
文章起源：http://m.5511xx.com/article/cdojigh.html
