以下文字來自《軟體工程的事實與謬誤》。僅僅閱讀這些文字，有很多你可能會一頭霧水，不要緊，花17元就能買到正版書，仔細閱讀你就會明白了。
軟體專案很多問題的根源從以下事實和謬誤中我們都能找到答案。專案管理有完整的體系和方法，並且在不斷改進。但如果想做好it行業的專案管理，對軟體工程的本質的東西看不透是不可能做好專案管理的。因此，我把書中的主要內容花了近3個小時敲了一遍奉獻給大家，希望能看到這篇文字的朋友都去看看這本書。如果你囊中羞澀，就在書店多泡會也行。知識和智慧型是最大的財富，知識是智慧型的源泉！無論多忙，別忘記學習！
管理：1.1人員
事實1：在軟體開發中，最重要的因素不是程式設計師採用的工具和技術，而是程式設計師自身的質量
事實2：對「個體差異」的研究表明，最好的程式設計師要比最差的程式設計師強28倍之多。即使他們的報酬不同，優秀程式設計師也是軟體業中最廉價的勞動力。
事實3：給延期的專案增加人手會使專案進一步延期。
事實4：工作環境對工作效率和產品質量具有深刻影響。
1.2工具和技術
事實5：誇大宣傳是軟體的瘟疫。多數軟體工具對於效率和質量的提高幅度僅為5%~35%。但是總有人反覆說提高幅度是「數量級」的
事實6：在學習新工具或者新技術的初期，程式設計師的工作效率和產品質量都會下降。只有克服了學習曲線以後，才可能得到實質性的效益。只有滿足下面兩個條件，採用新工具或新技術才有意義：（a）新東西確實有用；（b）要想獲得真正的收益，必須耐心等待。
事實7：軟體開發者對於工具說的多，評估的少，買的多，用的少。
1.3估算
事實8：專案失控的兩個最主要的原因之一是糟糕的估算（另乙個原因見事實23）
事實9：許多估算是在軟體生命週期開始時完成的。後來，我們才認識到在需求定義之前，即理解問題之前進行專案估算是不正確的；也就是說，估算時機是錯誤的。
事實10：許多軟體專案都是由高層管理人員或者營銷人員來估算，而不是由真正構建軟體的人或者他們的主管來進行估算。因此，估算軟體的人員是錯誤的。
事實11：軟體估算很少根據專案進度進行調整。因此，這些估算通常是錯誤的人在錯誤的時間得出的錯誤的結果。
事實12：因為估算的資料如此糟糕，所以在軟體專案不能達到估算目標時，不應該再考慮估算。但是無論如何，每個人都在考慮它。
事實13：在管理者和程式設計師之間存在隔閡。對於乙個未滿足估算目標的專案的調查表明：從管理者看來這是乙個失敗的專案，而在技術人員看來確實最成功的專案。
事實14：對於可行性調研的回答幾乎總是「可行」。
1.4復用
事實15：小規模的復用（子程式庫）開始於50多年以前，這個問題已經得到很好的解決。
事實16：雖然每個人都認為大規模復用（元件）非常重要、非常急需，但是這個問題至今還沒有基本解決。
事實17：大規模復用最好適用於相關的系統，也就是依賴於具體應用領域，這樣就限制了它的應用範圍。
事實18：有關復用問題，有兩個「三倍原則」：（a）構建可復用的元件比使用元件難三倍；（b）在將元件收錄到復用庫並成為通用元件之前，應該在三個不同的應用中嘗試應用該元件。
事實19：修改復用的**特別容易引起錯誤。如果乙個元件中超過20%~25%的**需要修改，那麼重新實現的效率會更高。
由此引出的另外乙個事實是：修改經過打包的商業性軟體系統通常是錯誤的。
事實20：設計模式復用是解決**復用中固有問題的一種方法。
1.5複雜性
事實21：問題的複雜性每增加25%，解決方案的複雜性就增加100%。這不是乙個可改變的條件（即使人們都努力降低複雜性），而是客觀存在的。
事實22：80%的軟體工作是智力活動。相當大的比例是創造性地活動。很少是文書性的工作。
生命週期
2.1需求
事實23：導致專案失控的兩個最常見原因之一是不穩定的需求（另乙個見事實8所說的專案估算失誤）。
事實24：在產品完成時修訂需求錯誤的代價最大，在開發早期修訂需求錯誤的代價最小。
事實25：遺漏需求是最難修訂的需求錯誤。
該事實的乙個必然結論是：最持久的軟體錯誤是遺漏邏輯錯誤，它可以逃過軟體測試過程，進入發布的產品中。遺漏需求會導致遺漏邏輯。
2.2設計
事實26：從需求轉入設計時，因為制定方案過程的複雜性，會激增出大量的衍生需求（針對一種特定設計方案的需求）。設計需求是原始需求的50倍之多。
事實27：對於乙個軟體問題，通常不存在唯一的最佳設計方案。
事實28：設計是乙個複雜的、迭代的過程。最初的設計方案可能是錯誤的，當然也不是最優的。
事實29：從設計到編碼階段時，設計者按照自己掌握的水平，已經將問題分解為「原語」。如果程式設計者和設計者不是同乙個人，二者的「原語」不吻合，就會出問題。
事實30：cobol是一種非常糟糕的語言，但是其他的（用於商業資料處理的）語言也同樣糟糕。
事實31：錯誤消除是軟體生命週期中最耗時的階段。
事實32：普通程式設計師認為已經徹底測試過的軟體其實只執行了55%~60%的邏輯路徑。採用覆蓋分析器等自動工具，可以將上述比例提高到85%~90%。幾乎不可能測試軟體中100%的邏輯路徑。
事實33：即使測試覆蓋有可能達到100%，這種測試也不夠。大約35%的錯誤是源於邏輯路徑的缺失，還有40%的錯誤源於執行特定的路徑組合。不可能實現100%的覆蓋。
事實34：沒有工具就無法做好錯誤消除工作。人們常用偵錯程式，很少使用覆蓋分析器等其他工具。
事實35：自動測試很少，也就是說有些測試可以也應該自動化，但是有許多測試任務不能自動完成。
事實36：程式設計師在程式中嵌入測試**、目標**中的編譯引數等方法，都是測試工具的重要補充。
事實37：在執行第乙個測試用例之前進行嚴格審查可以消除軟體產品中多大90%的錯誤。
事實38：雖然嚴格審查有很多優點，但是不能也不應該代替測試。
事實39：通常認為，事後評審對於了解客戶的滿意度和改進過程都很重要。但是很多軟體公司不開展事後評審。
事實40：同行評審涉及技術和社會兩方面問題，忽視任何一方面都回產生嚴重的災難。
2.7維護
事實41：維護開支通常佔軟體成本的40%~80%（平均為60%）。因此，維護可能是軟體生命週期中最重要的階段。
由此引出的乙個必然結論：古老的硬幣會被拋棄，古老的軟體每天都在使用。
事實42：增強功能大約佔軟體維護成本的60%，錯誤更正僅佔17%。因此，軟體維護的主體是在舊軟體中加入新功能，而不是更正錯誤。
事實43：維護是解決方案，而不是解決問題。
事實44：比較軟體開發和軟體維護中的工作，除了維護中「理解現有的產品」這項工作之外，其他工作都一樣。這項工作佔據了大約30%的維護時間，是主要的維護活動。因此可以說維護比開發更難。
質量 3.1質量
事實46：質量是一組屬性的集合。
事實47：軟體質量不是使用者滿意、滿足需求、滿足成本和時間表目標，或者可靠性。
3.2可靠性
事實48：絕大多數程式設計師都會犯某些錯誤。
事實49：錯誤通常聚集在一起。
事實50：沒有唯一最好的消除軟體錯誤的方法。
事實51：總會有殘存的錯誤。我們的目標應該是消除嚴重錯誤，或者使之最少。
3.3效率
事實52：效率主要來自於優秀的設計，而不是優秀的編碼。
事實53：高階語言（high-order language,hol）**配合適當的編譯器優化，大約可以達到組合語言90%的效率。對於一些複雜的現代體系結構，效率更高。
事實54：在空間和時間之間存在折中。通常，改進一方面會降低另一方面。 研究
事實55：許多軟體研究者不是做調查，而是鼓吹。因此，（a）有些概念比鼓吹的糟糕、更少；（b）缺少有助於確定這些概念真是價值的評估性研究。
5+5謬誤
管理謬誤1：你不能管理自己無法度量的東西。
謬誤2：可以管理軟體產品的質量。
5.1人員
謬誤3：可以，也應該「忘我」地程式設計。
5.2工具和技術
謬誤4：工具和技術是通用的。
5.3估算
謬誤6：要估算成本和時間表，應首先估算**行數。
生命週期
6.1測試
謬誤7：隨機測試輸入是優化測試的好方法。
謬誤8：「假如有了足夠多的關注，所有的bug都顯而易見。」
6.2維護
謬誤10：教別人程式設計的方法是教別人寫程式。
軟體工程的事實與謬誤
軟體工程的事實與謬誤 robert l.glass 事實1 在軟體開發中，最重要的因素不是程式設計師採用的工具和技術，而是程式設計師自身的質量。事實2 對 個體差異 研究表明，最好的程式設計師要比最差的程式設計師強28倍之多，即使他們的報酬不同，優秀程式設計師仍是軟體業中最廉價的勞動力。事實3 br...
軟體工程的真實與謬誤
上收藏的一篇書評，隨手翻譯了一些，原文在 有些條款不理解，也沒有上下文，譯得暴爛 人 1 軟體工作中最重要的因素是程式設計師的質量。2 最優秀的程式設計師比最糟糕的程式設計師好上28倍。3 在延期的工程中加入人員，會使工程更為延期。4 工作環境對生產力和工作質量有深刻的影響。工具和技術 對工具和技術...
軟體工程的事實
軟體工程的事實 一 管理1 在軟體開發過程中，重要的不是程式設計師使用的工具和技術，而是程式設計師本身 2 最差的程式設計師同最優的程式設計師，差距可以達到30倍 3 工作環境同效率和質量有深刻的影響 4 軟體工具對效率和質量的提高幾乎只有5 35 間。5 每個人都認為大規模的復用 主件或者構建 是...