軟體工程學習筆記

標籤：

《構建之法》第一章 概論

讀過了第一章概論，讓我對軟體工程有了新的認識。我認為如果將程式比作人，那麼軟體工程就是他的衣著，所以有了“軟體=程式+軟體工程”這句話。軟體工程來源於現實問題，現實中的各種需求會形成一個個便於人們解決問題和使用的程式，軟體工程便是針對程式保駕護航的重要因素。

1.軟體的構建：源於人們的需求，形成了來源程式，這隻是軟體工程的服務物件而非我之前認為的“寫出了程式就是成功了”。寫程式的能力不可或缺，但是這不是全部。

2.軟體測試：寫出的程式必須是能夠有效解決問題的產品。

3.軟體的生命週期：隨著時間的推移，程式可能會失效或者需要更好地解決原問題，也可以是在長期使用中發現了程式有更大的進步空間，這就需要程式員進行修改維護。

4.使用者體驗：在同樣功能的兩個軟體中，細節決定成敗，比如A軟體的軟體介面更讓人看著舒服，介面布置得合理，便於使用，那麼他肯定是優於其它同類軟體了。

5.軟體開發過程的五大難題：複雜性，不可見度，易變性，服從性以及非連續性。人和機器的交流是單向的，機器不會說話，只能通過結果來反饋給程式員，這無疑是給程式的開發帶來了巨大難度。

6.創造足夠好的軟體：上文已經提到，既然是服務於現實問題的，那麼它的品質肯定是人們最關心的元素，包括四點（1）使用者滿意度：軟體有很多問題，影響使用者體驗（2）可靠性：軟體盡量有較高的使用成功率（3）軟體流程的品質：由於團隊和開發流程問題太多，無法按時交付軟體（4）可維護性：軟體應該要便於維護。

第五章 團隊和流程

團隊精神是在軟體開發中不可或缺的，因為有著同樣的目標，大家分工合作，共同完成任務，事半功倍，集合團隊中眾人的智慧往往能使產品更容易被接受。現在大多都是用瀑布模型來開發軟體。

當然，瀑布模型也有很多局限性：比如軟體需求作為軟體開發項目中的一個關鍵因素，無法進行合適的測試，直至一個工作系統被開發出來並能示範給終端使用者。事實上，好幾個研究工作已經指出軟體需求規約的錯誤通常在最後才被檢測到（直至執行系統測試或驗收測試才能被檢測到），並且需要花費最大的代價對其進行糾正。

只有在生存周期的後期才能得到一個工作的系統。因此，直到系統幾乎可以運行時，一個重要的設計或效能問題才有可能被發現，到那時通常已經太晚了，以至於無法採取有效措施。

針對以上局限性，人們又提出了瀑布模型的各種變形。比如生魚片模型，大瀑布帶著小瀑布等。

第十七章 人，績效和職業道德

這一章節更像是在教我們在這門課程開始的時候，端正自己的人品和道德，積極做好自己分內的事，為團隊出力，不偷懶，不打醬油。

1.軟體工程師的行為應與公眾利益一致。

2.軟體工程師應以其客戶和僱主利益最大化的方式做事，與公眾利益保持一致。

3.軟體工程師應當確保自己的產品以及相關的修改滿足最高的專業標準，

4.軟體工程師應當具備完整且獨立的專業判斷。

5.軟體項目的經理和領導人應該提倡並親自採用符合道德規範的方法來管理軟體的開發與維護。

6.在與公眾利益一致的原則下，軟體工程師應當保證其職業的誠信和信譽。

7.軟體工程師應當公平對待同級，並予以支援和協助。

8.軟體工程師應當終生學習以提高自身的專業水平，並在工作實踐中推動落實道德準則。

軟體工程學習筆記