《構建之法》已經到手了，但是還沒開始看，只翻看了前幾頁，和傳統的教材區別很大，沒有大篇幅的理論，比教材看起來有意思。第一章中還提到了『bug』的由來，第一次聽說，感覺挺有意思。
第一周上課老師提問什麼是軟體，同學們認為軟體就是程式，我也是這麼想的。但是為什麼他要叫軟體，而不叫程式呢？對於程式，比較通用的定義是：程式=演算法+資料結構。但是演算法和資料結構組合起來能構成軟體嗎？答案是不夠的。所以《軟體工程概論》中，將軟體定義為程式、資料及其相關文件的完整集合（軟體=程式+資料+文件）。程式可以沒有輸入資料，可以沒有文件，但是軟體不行。軟體是要根據使用者的輸入需求，進行計算，將結果反饋給使用者，所以軟體要由資料組成。同時，軟體需要維護，如果沒有文件記錄，這樣的軟體一定不能長久存活。隨著軟體越做越大，**越來越來，沒有文件輔助解釋，對於後續的軟體工程師來說，很難理解之前的程式，也就很難進行維護完善。在《構建之法》的開篇，同樣給了軟體的定義，這本書中將軟體定義為：軟體=程式+軟體工程。通過兩個概念的對比，我們可以推出乙個結論就是：軟體工程=資料+文件。如果就是這樣的話，那麼兩個定義就沒什麼區別。軟體工程又是什麼呢？書中也做了介紹，軟體工程的核心部分是構建管理、源**管理、軟體設計、專案管理等這些和軟體開發活動相關的內容。仔細想想，這些內容從某種意義可以說是資料和開發文件的組合，所以兩本書中關於軟體的定義實際上是沒有什麼區別的。
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\分割線\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
關於如何衡量個人在團隊的績效
首先想到的肯定是誰做的部分多、難，誰的分高。但是接下來的問題也很多
1.如何定義每個人的工作量或者效率
如果單純的以工作時間以及**行數來作為衡量標準，那麼會造成程式設計師故意把程式寫的複雜冗長。本來只需要3條指令可以完成的事，為了增加**長度，可以增加到10條、20條，但是這對整個專案來說不僅是沒有好處，還會帶來危害。**是越短越好的，那我們是不是可以根據誰的**短來評價成員的工作呢？這也是不行的，首先，組內每個成員的分到的任務就是不一樣的，有點任務比較複雜，有點比較簡單。那麼對應的**肯定不一樣的。而且如果特意減少**，很有可能會有潛在的bug。我覺得這部分不能很好的定義，所以我的策略是不考慮這一部分。
2.關於工作時間
顯然，工作時間也不是越長越好的。所以我的策略是，規定好每個成員的工作時間，對於缺勤並且沒完成任務的進行處罰，對工作時間超過個人計畫的時間，不進行懲罰，也不鼓勵，只要按時完成分配給他的任務就行了。
3.關於工作難度
誰解決關鍵問題，應該獲得更多的得分。但是，分配給每個人的任務不一樣。如果為了得到這部分的成績，那麼每個人都會要求做最難的部分，誰去做簡單的任務呢？而且，也不是每個人都能解決得了。所以，對於這一部分，我的想法是每個組員的成績都一樣，組長根據小組專案的成績比組員多一點分數。
最後，我的結論是：個人成績=小組成績+組長加分+未完成任務扣分
第一章思考題
1 軟體過程模型 包括軟體產品開發 執行和維護中有關過程 活動和任務的框架，覆蓋了從系統的需求定義到系統的使用終止。軟體生存週期 軟體生命週期是軟體的產生直到報廢或停止使用的生命週期。包括從軟體定義到開發到執行。軟體生命週期內有問題定義 可行性分析 總體描述 系統設計 編碼 除錯和測試 驗收與執行 ...
數值分析思考題 鐘爾傑版 參考解答 第一章
在數學中，演算法通常是按照一定 規則解決某一類問題的明確和有限的步驟。計算誤差有截斷誤差和捨入誤差。由實際問題建立起來的數學模型，在很多情況下要得到準確解是困難的，通常要用數值方法求出它的近似解。例如常用有限過程逼近無限過程，用能計算的問題代替不能計算的問題。這種數學模型的精確解與由數值方法求出的近...
第5章思考題
目的 要求開發人員準確地理解使用者需要什麼，進行細緻地調查分析，將使用者的需求陳述轉化為完整的需求定義，再由需求定義轉化為相應的軟體需求規格說明。作用 需求分析雖處於軟體開發的初期階段，但它對於整個軟體開發過程以及產品質量至關重要。只有做好需求分析才能做出符合需要的軟體功能。業務需求 busines...