讀《構建之法》後的問題.

Q1. 在泛讀《構建之法》這本書時，我在第一章看到這樣一段文字（歷史學家們說計算機系統的第一個Bug是一個蛾子，所以你們把軟件的缺陷叫作Bug.其實很多工程師在那以前都用」Bug「來統稱系統中的問題），有這個問題（Bug到底是什麼？到底是軟件使用或者測試過程當中，忽然出了須要維護的問題；仍是軟件開發人員和用戶的需求之間產生的分歧？爲何對於Bug沒有一個明確的解釋?）。我查了資料發現存在這樣的說法（所謂「（Bug）」，是指電腦系統的硬件、系統軟件（如操做系統）或應用軟件（如文字處理軟件）出錯。硬件的出錯有兩個緣由，一是設計錯誤，一是硬件部件老化失效等。軟件的錯誤全是廠家設計錯誤。那種說用戶執行了非法操做的提示，是軟件廠商不負責的胡說八道。用戶可能會執行不正確的操做，好比原本是作加法但按了減法鍵。這樣用戶會獲得一個不正確的結果，但不會引發bug發做。軟件廠商在設計產品時的一個基本要求，就是不容許用戶作非法的操做。只要容許用戶作的，都是合法的。用戶根本就沒有辦法知道廠家內心是怎麼想的，哪些操做序列是非法的。），可是根據我爲數很少的實踐，我有這樣的經驗（硬件中的Bug我不太瞭解，可是軟件中的Bug僅僅是來自程序代碼的出錯。）。可是我仍是不太懂，個人困惑是（雖然bug不可消除，可是用戶和軟件開發人員之間的表述不清和功能分歧這是屬於溝通領域，已經不關軟件自己的問題了，怎麼能夠以偏概全都叫bug），但願在之後的學習中能夠解決這一問題，並深化本身對軟件工程總體的理解。

Q2.我在第七章看到這樣一段文字（軟件工程，惟一不變的就是變化。因此乾脆乾脆別幻想用戶的需求會在第一時刻很明確。而後保持不會變。但要注意，咱們是預期變化，不是指望變化。），有這個問題（雖然軟件開發過程是一個連續修改的過程，力求最合適用戶，可是一直變化，會不會出現太屢次大幅度的修改，而後出現開發方向嚴重偏離或者打擊開發者的信心？）。我查了資料發現存在這樣的說法（這就須要在需求分析階段多溝通多瞭解，先肯定方向，再尋求長期的比較廣度的發展，也須要團隊保持敏捷的應對方式，符合msf團隊模型），可是我依舊以爲（須要團隊之間的默契和協做，必須讓團隊中的每一個人都明白彼此的想法，但需求變化依舊是不可控的，但願能有更好的解決辦法。）

Q3.我在第八章看到競爭性需求分析的框架，有這個問題（最新型，有創新點的軟件設計，必定就是最符合用戶心目中的軟件嗎？）。我仔細看了書發現存在這樣的說法（從需求、作法、競爭、推廣多方面分析來看，軟件開發市場須要必定的創新和競爭力，但一個公司可能有多種軟件產品和服務，它們各有不一樣的戰略意義。一個軟件或服務也由不少功能組成，它們有機地結合起來，才能解決用戶的問題，產生效益，要更用心地去優化軟件，後期準確的表達與介紹產品的核心價值，體現不一樣類型的功能，就也許能夠取得好評。），基本解決了個人疑惑。