軟體是由多人合作完成的，不同人員的工作相互有依賴關係。例如，乙個人寫的模組被其他人寫的模組呼叫。軟體的很多錯誤**於程式設計師對模組功能的誤解、疏忽或不了解模組的變化。如何能讓自己負責的模組功能定義盡量明確，模組內部的改變不會影響其他模組，而且模組的質量能得到穩定的、量化的保證？單元測試就是乙個很有效的解決方案。
單元測試是指對軟體中的最小可測試單元進行檢查和驗證。單元測試（模組測試）是開發者編寫的一小段**，用於檢驗被測**的乙個很小的、很明確的功能是否正確。通常而言，乙個單元測試是用於判斷某個特定條件（或者場景）下某個特定函式的行為。根據我的理解，我明白了單元測試是為了檢驗一段**的功能。
把單元測試的責任和**作者繫結在一起後，**作者就能更真切地體會到複雜**的***，因為驗證複雜**的正確性要困難得多。要注意：100%的**覆蓋率並不等於100%的正確性！分析如下：a.**覆蓋率對於「應該寫但是沒有寫的**」無能為力。例如**申請了記憶體或其他資源，但並沒有釋放。又如，**中並沒有處理錯誤情況。就像沒有處理和檔案、網路相關的一些異常情況，例如檔案不存在、許可權有問題，等等。
b.**中有效能問題，雖然**執行了，並且也正確地返回了，但是**效率非常低。有些情況下，可以針對**效率寫乙個單元測試。
c.多執行緒環境中地同步問題，這個問題和**執行的時序、共享資源的鎖定有關。
d.其他與外部條件相關的問題（例如與裝置、網路相關的問題）。
**覆蓋是軟體測試中的一種度量，描述程式中源**被測試的比例和程度，所得比例稱為**覆蓋率。在做單元測試時，**覆蓋率常常被拿來作為衡量測試好壞的指標，甚至，用**覆蓋率來考核測試任務完成情況，比如，**覆蓋率必須達到80%或90%。
mvp的指導思想和漸進交付相似，但是它更強調更早獲得使用者反饋，為此可以在產品完成之前就發布，它也強調產品的核心價值（產品最區別於競爭產品的地方），為了突出核心功能，別的輔助功能可以不考慮或者用別的平台提供的服務來代替。
第二步：決定當前的衝刺需要解決的事情整個產品的實現被劃分為幾個互相聯絡的衝刺。產品訂單上的任務被進一步細化了，被分解為以小時為單位。如果乙個任務的估計時間太長（如超過16個小時），那麼它就應該被進一步分解。訂單上的任務是團隊成員根據自己的情況來認領。團隊成員能主導任務的估計和分配，他們的能動性得到較大的發揮。
msf過程模型的基本元素是階段和里程碑。所謂「階段」，就是在這一段時間裡團隊集中精力做一類事情，每個階段的結束都代表了專案的進展和團隊工作重心的變化。比如在「開發階段」結束後，團隊就不再允許設計/實現新的功能，除非有理由充分的「變更請求」。
軟體工程15 個人閱讀作業2 提出問題
快速通讀教材 構建之法 並參照提問模板，提出5個問題 q1.p94早期軟體行業採用瀑布模型 它從別的成熟行業 硬體設計，建築工程 借用了不少經驗和模型。在那些 硬 的行業中，產品大多遵循 分析 設計 實現 製造 銷售 維護 這個流程。q2.p107 根據微軟msdn上的敏捷流程圖所得出的敏捷的步驟中...
軟體工程網路15個人閱讀作業2 提出問題
2018 3 18 10 00pm，以提交至班級部落格時間為準。快速通讀教材 構建之法 並參照提問模板，提出5個問題。如何提出有價值的問題？請看這個文章 以及 在網際網路時代如何提問題。還有這些要點 乙個模板可以是這樣 我看了這一段文字 引用文字 有這個問題 提出問題 我查了資料，有這些說法 引用說...
軟體工程網路15個人閱讀作業2 提出問題
快速通讀教材 構建之法 並參照提問模板，提出5個問題。q1 如果這位年輕人的想法是改進電報技術，一定會收到歡迎，這一類創新是改良式的 incremental innovation 但是，有些創新是顛覆式的 disruptive innovation 這些想法一旦出現，便會引起現有技術擁有者的極大不安...