1. 程式人生 > >人月神話5

人月神話5

神話 說明 技術 集合 策略 單個 不同 展開 成了

1.未雨綢繆這章我開始還原來一直記成了是講風險,但是仔細閱讀後發現主要講如何快速適應變化。在敏捷軟件開放中我們強調通過叠代和快速交互等各種方法來適應變化。在大型軟件工程中我們看到仍然需要考慮如何適應變化,很多時候對於大型的軟件和系統,我們一開始往往很難設計的很清楚,所以只有先假設一種方案,然後對其開發原型進行驗證,只有通過驗證後才能開始後續的計劃,否則就必須提出新的假設。
  一切事物皆無常,都處於動態的發展變化中,唯一不變的就是變化本身。不但目標上的變化不可避免,而且設計策略和技術上的變化也不可避免。拋棄原型概念本身就是對事實的接受——隨著學習的過程更改設計。所以以此為展開分別開始談軟件開發生命周期的各個階段都必須要適應變化。

  • 為變更而計劃並不是要求我們範圍不明確,而是計劃過程應該是叠代式的漸進細化過程。
  • 為變更而設計組織結構,如外科手術團隊,要求最小化團隊成員接口並最方便系統修改和擴展。
  • 為變更而發布講如何提高軟件產品可維護性,如何解決Bug的修復會引入新的Bug的問題。

  2.對於大型軟件系統,產品集成和集成測試具有重要的地位,為了系統的有計劃的降低系統集成調試的困難性我們需要采取多種方法和措施。其中包括了首先對於單個構建必須經過充分的單元測試,否則單元測試的問題將遺留到集成測試階段導致問題復雜化;其次是搭建充分的測試平臺,測試平臺往往需要編寫測試代碼,特別是還可能開發各種偽構件來驗證數據集成的正確性。最後是在集成期間要嚴格控制變更,最好是階段化的定期變更。


  3.用戶需要不同級別的文檔。某些用戶僅僅偶爾使用程序,有些用戶必須依賴程序,還有一些用戶必須根據環境和目的的變動對程序進行修改。在需要什麽樣的文檔一段從使用程序,驗證程序和修改程序三個方面來談如何寫文檔,文檔內容應該包含哪些核心要素。使用程序方面的文檔發生在程序編寫前,要描述清楚程序的目的,範圍,場景,輸入,輸出等各項重要內容。每一個發布的程序需要附加驗證說明,即準備我們常做的測試用例,這個發生在驗證測試階段。最後,調整程序或者修復程序需要更多的信息。顯然,這要求了解全部的細節,並且這些細節已經記錄在註釋良好的列表中。

  4.一個相互牽制關聯的概念結構,是軟件實體必不可少的部分,它包括:數據集合、數據條目之間的關系、算法、功能調用等等。這些要素本身是抽象的,體現在相同的概念構架中,可以存在不同的表現形式。盡管如此,它仍然是內容豐富和高度精確的。我認為軟件開發中困難的部分是規格化、設計和測試這些概念上的結構,而不是對概念進行表達和對實現逼真程度進行驗證。當然,我們還是會犯一些語法錯誤,但是和絕大多數系統中的概念錯誤相比,它們是微不足道的。如果這是事實,那麽軟件開發總是非常困難的,天生就沒有銀彈。然後具體從軟件開發的復雜性,一致性,可變性和不可見性進行了詳細分析。

個人感想:

  對於我們來說適應能力是我們不管生活中還是工作中都是必不可少的技能。對於我們來說,隨著時間的流逝,也許項目的總的目標是不變的,但是一些小的細節隨著生活的改變而改變,這就需要我們適應這些變化,對於這些變化做出適當的改變來適應這些變化。對於我們來說,軟件的集成和測試也是非常重要的,這是軟件工程裏很重要的步驟。而寫文檔對於我們來說也是非常重要的,老師說,對於我們軟件工程的學生來說,很重要的一項本領就是如何寫文檔,我們軟件工程就是一門與人交流的學科,只有寫好文檔才能更好地和他人進行交流。

人月神話5