軟體工程的事實與謬誤
robert l. glass
事實1：在軟體開發中，最重要的因素不是程式設計師採用的工具和技術，而是程式設計師自身的質量。
事實2：對「個體差異」研究表明，最好的程式設計師要比最差的程式設計師強28倍之多，即使他們的報酬不同，優秀程式設計師仍是軟體業中最廉價的勞動力。
事實3：（brook法則）給延期的專案增加人手會使專案進一步延期。
事實4：工作環境對工作效率和產品質量有深刻影響。
事實5：多數軟體工具對於效率和質量的提高幅度僅為5%~35%，但是總有人反覆說提高幅度是數量級的。
事實6：學習新工具和新技術的初期，程式設計師的工作效率和產品質量都會下降，只有克服了學習曲線以後，才可能得到實質性的收益。
事實7：軟體開發者對工具說得多，評估得少，買得多，用得少。
事實8：專案失控的兩個主要原因之一是糟糕的預算。
事實9：許多估算是在軟體生命週期開始時王承德，後來，我們才認識到在需求定義以前，即理解問題之前盡心專案估算是不正確的；也就是說，估算時機是錯誤的。
事實10：許多軟體專案是由高層管理人員獲營銷人員來估算，而不是真正構建軟體的人或是他們的主管來進行估算。因此，估算軟體的人員是錯誤的。
事實11：軟體估算很少根據專案進度進行調整。因此，這些估算通常是錯誤的人在錯誤的時間得出的錯誤結果。
事實12：因為估算的資料是如此的糟糕，所以在軟體專案不能達到估算目標時，不應該再考慮估算。但無論如何，每個人都在考慮它。
事實13：在管理者和程式設計師之間存在隔閡。對於乙個未滿足估算目標的專案的調查表明：從管理者看來失敗的乙個專案，而是技術人員看來卻是最成功的專案。
事實14：對於可行性調研的回答幾乎總是可行。
事實15：小規模的復用（子程式庫）開始於50多年以前，這個問題已經得到很好的解決。
事實16：雖然每個人都認為大規模的復用（元件）非常重要，非常急需，但這個問題至今還沒有基本解決。
事實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%的邏輯路徑。
需求驅動測試（測試是否滿足了需求）
結構驅動測試（測試已構建的軟體所有組成部分是否正確執行）
統計驅動測試（隨機測試確定軟體執行的時間和結果）
風險驅動測試（測試確定是否已經消除了最重要的風險）
事實34：沒有工具就無法做好錯誤消除工作。人們常用偵錯程式，很少使用覆蓋分析器等其他工具。
事實35：自動測試很很少，也就是說有些測試可以也應該自動完成，但是有許多測試任務不能自動完成。
事實36：程式設計師在程式中嵌入測試**，目標**中的編譯引數等方法，都是測試工具的重要補充。
事實37：在執行第乙個測試用例之前進行嚴格的審查可以消除軟體產品中多達90%的錯誤。
事實38：雖然審查有很多優點，但是不能也不應該代替測試。
事實39：事後評審對於了解客戶的滿意度和改進軟體過程都很重要。但是很多公司不開展事後評審。
多數人建議在軟體交付3~12個月進行事後評審。
事實40：同行評審涉及技術和社會兩個方面的問題，忽視任何一方面都回產生嚴重的災難。事實41：維護開支通常佔軟體成本的40%~80%（平均60%）。因此，維護可能是軟體愛女生命週期中最重要的階段。
古老的硬體會被廢棄，古老的軟體每天都在使用。
事實42：增強功能大約佔軟體維護成本的60%，錯誤更正僅佔17%，因此，軟體維護的主題是在舊軟體中加入新功能，而不是更正錯誤。
事實43：維護是解決方案，而不是問題。
事實44：比較軟體開發和軟體維護中的工作，除了維護中「理解現有的產品」這項工作以外，其他工作都一樣。這項工作佔據了大約30%的維護時間，是主要的維護活動。因此可以說維護比開發更難。
事實46：質量是一組屬性的集合。
可靠性是指軟體產品滿足預期要求，值得信賴。
人類工程學（可用性）軟體用起來容易舒服。
易理解和易維護性
效率是指軟體產品在執行時間和空間消耗上的經濟性。（有些應用中應在首位）
可測試性
可移植性指易於在不同的平台之間移植的軟體產品。
事實47：軟體質量不是使用者滿意，滿足需求，滿足成本和時間表，或者可靠性。
事實48：絕大多數程式設計師會犯某些錯誤。
n-version ,fault-tolerant programming容錯程式設計
事實49：錯誤通常聚集在一起。
事實50：沒有唯一的最好的消除軟體錯誤的方法。
事實51：總會有殘存的錯誤。我們的目標是消除嚴重錯誤，或是使之減少。
事實52：效率主要來自優秀的設計，不是優秀的編碼。
極限程式設計運動倡導簡單化的設計方法和快速進入編碼階段。
極限程式設計強調：在編碼之後通過持續地重構(refactoring)來修訂設計彙總的低效率和事實53:高階語言**配合適當的編譯器優化，大約可以達到組合語言的90%的效率。對於一些複雜的現代體系結構，效率更高。
事實54：在時間和空間之間存在折中，通常改進一方面會降低另一方面。
事實55：許多軟體研究者不是調查，而是鼓吹。
謬誤1：要估算成本和時間表，應首先估算**行數。
謬誤2：隨機測試輸入是優化測試的好方法。
謬誤3：加入有了足夠的關注，所有的錯誤都顯而易見。
《軟體工程的事實與謬誤》核心內容摘抄
以下文字來自 軟體工程的事實與謬誤 僅僅閱讀這些文字，有很多你可能會一頭霧水，不要緊，花17元就能買到正版書，仔細閱讀你就會明白了。軟體專案很多問題的根源從以下事實和謬誤中我們都能找到答案。專案管理有完整的體系和方法，並且在不斷改進。但如果想做好it行業的專案管理，對軟體工程的本質的東西看不透是不可...
軟體工程的真實與謬誤
上收藏的一篇書評，隨手翻譯了一些，原文在 有些條款不理解，也沒有上下文，譯得暴爛 人 1 軟體工作中最重要的因素是程式設計師的質量。2 最優秀的程式設計師比最糟糕的程式設計師好上28倍。3 在延期的工程中加入人員，會使工程更為延期。4 工作環境對生產力和工作質量有深刻的影響。工具和技術 對工具和技術...
軟體工程的事實
軟體工程的事實 一 管理1 在軟體開發過程中，重要的不是程式設計師使用的工具和技術，而是程式設計師本身 2 最差的程式設計師同最優的程式設計師，差距可以達到30倍 3 工作環境同效率和質量有深刻的影響 4 軟體工具對效率和質量的提高幾乎只有5 35 間。5 每個人都認為大規模的復用 主件或者構建 是...