軟體工程的事實與謬誤

標籤：

軟體工程的事實與謬誤
   Robert L. Glass
事實1：在軟體開發中，最重要的因素不是程式員採用的工具和技術，而是程式員自身的品質。
事實2：對“個體差異”研究表明，最好的程式員要比最差的程式員強28倍之多，即使他們的報酬不同，優秀程式員仍是軟體業中最廉價的勞動力。
事實3：（Brook法則）給延期的項目增加人手會使項目進一步延期。
事實4：工作環境對工作效率和產品品質有深刻影響。
事實5：多數軟體工具對於效率和品質的提高幅度僅為5%~35%，但是總有人反覆說提高幅度是數量級的。
事實6：學習新工具和新技術的初期，程式員的工作效率和產品品質都會下降，只有克服了學習曲線以後，才可能得到實質性的收益。
事實7：軟體開發人員對工具說得多，評估得少，買得多，用得少。
事實8：項目失控的兩個主要原因之一是糟糕的預算。
事實9：許多估算是在軟體生命週期開始時王承德，後來，我們才認識到在需求定義以前，即理解問題之前盡心項目估算是不正確的；也就是說，估算時機是錯誤的。
事實10：許多軟體項目是由高層管理員獲行銷人員來估算，而不是真正構建軟體的人或是他們的主管來進行估算。因此，估算軟體的人員是錯誤的。
事實11：軟體估算很少根據項目進度進行調整。因此，這些估算通常是錯誤的人在錯誤的時間得出的錯誤結果。
事實12：因為估算的資料是如此的糟糕，所以在軟體項目不能達到估算目標時，不應該再考慮估算。但無論如何，每個人都在考慮它。
事實13：在管理者和程式員之間存在隔閡。對於一個未滿足估算目標的項目的調查表明：從管理者看來失敗的一個項目，而是技術人員看來卻是最成功的項目。
事實14：對於可行性調研的回答幾乎總是可行。
事實15：小規模的複用（子程式庫）開始於50多年以前，這個問題已經得到很好的解決。
事實16：雖然每個人都認為大規模的複用（組件）非常重要，非常急需，但這個問題至今還沒有基本解決。
事實17：大規模複用最好使用於相關的系統，也就是依賴於具體應用領域，這樣就限制了它的應用。
事實18：有關複用問題，有兩個“三倍法則”：（1）構建可複用組件比使用組件難三倍。（2）在將組件收錄到複用庫並成為萬用群組件之前，應該在三個不同的應用中嘗試應用該組件。
事實19:修改複用的代碼特別容易引起錯誤。在一個組件中超過20%~25%的代碼需要修改，那麼重新實現效率會更高。
事實20：設計模式複用是解決代碼複用中固有問題的一種方法。
             設計模式源於實踐，而不是理論。
事實21：問題的複雜性增加25%，解決方案的複雜性就增加100%。這不是一個可改變的條件（即使人們努力降低複雜性），而是客觀存在的。
事實22：80%的軟體工作是智力活動，相當大的比例是創造性的活動，很少是文書性的工作。
事實23：導致項目失控的兩個常見原因之一是不穩定的需求。
事實24：在產品完成時修訂需求錯誤的代價的最大，在開發早期修訂需求錯誤的代價的最小。
事實25：遺漏需求是最難修訂的需求錯誤。
最持久的軟體錯誤是遺漏邏輯錯誤，它可以逃離軟體測試過程，進入發布的產品中。遺漏需求導致遺漏邏輯。
事實26：從需求轉入設計時，因為制定方案的複雜性，會激生出大量的衍生需求（針對一種特定設計方案的需求）。設計需求是原始需求的50倍之多。
事實27：對於一個軟體問題，通常不存在唯一的最佳設計方案。
事實28：設計是一個複雜的迭代的過程，最初的設計方案可能是錯誤的，當然也不是最優的。
事實29：從設計轉向編碼階段，設計者按照自己的水平，已經將問題分解成原語。如果編程者和設計者不是同一個人，二者的原語不吻合，就會出現問題。
事實30：COBOL語言是一種非常糟糕的語言，但是其他的（用於商業資料處理的）語言也同樣糟糕。
事實31：錯誤消除是軟體生命週期中最耗時的階段。
         Checkout 檢出testing 測試 verification and validation 驗證和確認
事實32：普通程式員認為已經徹底測試過的軟體其實只執行了55%~60%的邏輯路徑。採用覆蓋分析器等自動化工具，可以將上述比例提高到85%~90%。幾乎不可能測試軟將中100%的邏輯路徑。
      需求驅動測試（測試是否滿足了需求）
      結構驅動測試（測試已構建的軟體所有組成部分是否正確運行）
      統計驅動測試（隨機測試確定軟體執行的時間和結果）
      風險驅動測試（測試確定是否已經消除了最重要的風險）
事實33：即使測試覆蓋有可能達到100%，這種測試也不夠。大約35%的錯誤來源於邏輯路徑的缺失，還有40%的錯誤來源於執行特定路徑的組合。不可能實現100%的覆蓋。
事實34：沒有工具就無法做好錯誤消除工作。人們常用調試器，很少使用覆蓋分析器等其他工具。
事實35：自動化的測試很很少，也就是說有些測試可以也應該自動完成，但是有許多測試工作不能自動完成。
事實36：程式員在程式中嵌入測試代碼，目標代碼中的編譯參數等方法，都是測試載入器的重要補充。
事實37：在運行第一個測試案例之前進行嚴格的審查可以消除軟體產品中多達90%的錯誤。
事實38：雖然審查有很多優點，但是不能也不應該代替測試。
事實39：事後評審對於瞭解客戶的滿意度和改進軟體過程都很重要。但是很多公司不開展事後評審。
       多數人建議在軟體交付3~12個月進行事後評審。
事實40：同行評審涉及技術和社會兩個方面的問題，忽視任何一方面都回產生嚴重的災難。事實41：維護開支通常占軟體成本的40%~80%（平均60%）。因此，維護可能是軟體愛女生命週期中最重要的階段。
    古老的硬體會被廢棄，古老的軟體每天都在使用。
事實42：增強功能大約佔軟體維護成本的60%，錯誤更正僅佔17%，因此，軟體維護的主題是在舊軟體中加入新功能，而不是更正錯誤。
事實43：維護是解決方案，而不是問題。
事實44：比較軟體開發和軟體維護中的工作，除了維護中“理解現有的產品”這項工作以外，其他工作都一樣。這項工作佔據了大約30%的維護時間，是主要的維護活動。因此可以說維護比開發更難。
事實45：更好的軟體過程開發導致更多而不是更少的維護。
事實46：品質是一組屬性的集合。
        可靠性是指軟體產品滿足預期要求，值得信賴。
人類工程學（可用性）軟體用起來容易舒服。
易理解和易維護性
效率是指軟體產品在已耗用時間和空間消耗上的經濟性。（有些應用中應在首位）
可測試性
可移植性指易於在不同的平台之間移植的軟體產品。
事實47：軟體品質不是使用者滿意，滿足需求，滿足成本和時間表，或者可靠性。
事實48：絕大多數程式員會犯某些錯誤。
N-Version ,fault-tolerant programming容錯編程
事實49：錯誤通常聚集在一起。
事實50：沒有唯一的最好的消除軟體錯誤的方法。
事實51：總會有殘存的錯誤。我們的目標是消除嚴重錯誤，或是使之減少。
事實52：效率主要來自優秀的設計，不是優秀的編碼。
        極限編程運動倡導簡單化的設計方法和快速進入編碼階段。
        極限編程強調：在編碼之後通過持續地重構(refactoring)來修訂設計匯總的低效率和事實53:進階語言代碼配合適當的編譯器最佳化，大約可以達到組合語言的90%的效率。對於一些複雜的現代體繫結構，效率更高。
事實54：在時間和空間之間存在折中，通常改進一方面會降低另一方面。
事實55：許多軟體研究者不是調查，而是鼓吹。
謬誤1：要估算成本和時間表，應首先估算程式碼數。
謬誤2：隨機測試輸入是最佳化測試的好方法。
謬誤3：加入有了足夠的關注，所有的錯誤都顯而易見。
謬誤4：估計將來的維護成本和做出產品更新的決策需求需要參考過去的成本資料。
謬誤5：教別人編程的好方法是教別人寫程式。（應先閱讀）。

軟體工程的事實與謬誤（轉）