l 以文字為主的文件，如word、powerpoint文件。l 用圖形為主構造的模型，如mindmap，erd，dfd，uml的各種圖，甚至包括flow chart流程圖
l 用數學語言的描述，如viennadevelopment method
l 用類自然語言+**構造的描述，如literateprogramming
l 源**加注釋也能描述
實體關係圖
略。
各種圖示建模方法的大致特定
各種分析建模方法從結構化資料的角度看
從物件導向的角度看
從控制的角度看
強調靜態
erdclass diagram
強調動態、互動
dfd、ucd、activity diagram
sequence diagram
fsm, flow chart，uml state machine
略1.估計開發任務所需的時間，他會參考以前同類任務所需花費的實際時間，以及其他同事的時間估計。
2.小飛會試著寫一些快速原型的**，看看效果會怎樣。期間他發現了若干問題，與pm溝通後，最終達成一致意見。
3.在看到初始效果和了解了實現的細節後，小飛開始寫設計文件（technical spec、design document），寫好之後，他可以請同事一起來複審設計文件。
4.設計文件寫好後，小飛就會按照設計文件寫**。在實現過程中，他又發現了一些意想不到的問題，與pm溝通後，找到了解決方案。
5.寫好**後，小飛對照設計文件和**指南進行自我複審，重構**。
6.建立或更新單元測試。
7.進行單元測試（不僅要自己建立或更新單元測試，還要通過整個模組/系統的單元測試）。
8.得到乙個可以測試的版本，交給相關的測試人員進行測試，或者在網上進行某種公開測試，如a/b測試等。
9.修復測試人員或使用者發現的問題，等到問題都解決得差不多了，就請同事進行**複審。
10.根據**複審的意見修改**，完善單元測試和其他相關文件，然後把**嵌入到**庫中。
1.根據場景和開發任務來決定整合的次序2.互相依賴的任務要一起整合
3.在測試場景時，要保證端到端的測試
4.場景的所有者必須保證場景完全通過測試，然後把場景的狀態改為「解決」
**完成就是指工程師認為所有應該寫的**都寫完了，所有應該實現的功能都實現了（但未必沒有問題）。
當場景、功能都計畫好的時候，要給員工足夠多的時間，讓他們投入到工作中去，而不要經常打斷他們。
在我們的全球調查中，我們發現成功公司中有94%每天或至少每週完成構建，而不成功公司絕大多數每月甚至更少去做構建……當有乙個能執行的系統時，即使只是乙個簡單的系統，（團隊的）積極性也會上公升。
構建大師做下面的事：
1.負責管理構建伺服器
2.除錯構建，負責找錯，並分析出錯的原因。
3.負責把「構建大師」稱號和責任交給下乙個導致構建失敗的成員。
不審勢即寬嚴皆誤，從來治蜀要深思。《構建之法》讀書筆記第3章
第三章講的是軟體工程師的發展。主要從軟體工程師的評價方法，團隊期望和技能的反面進行闡述，並對應的分為3個小節。在第一小節中講的是個人能力的衡量與發展。對於初級軟體工程師的成長，從以下5個方面開始 積累軟體開發相關的知識，提公升技術技能 積累問題領域的知識和經驗 例如 對醫療或金融行業的了解 對通用的...
《構建之法》讀書筆記第1 2章
之前因為助教工作閱讀過一遍 構建之法 現在回頭重新翻看這本書，越發覺得這本書值得深入閱讀。本週先將前兩周的讀書筆記記錄如下 第一章從淺入深，以航空業的發展歷程作為模型，模擬軟體工程的發展。玩具 紙飛機 業餘愛好 沙灘椅 氦氣球 探索 萊特兄弟 產業 容納百萬人就業的航空業。類似的，軟體也從簡單的 h...
構建之法第4 17章讀書筆記
第四章 兩人合作 問題1 4.2中注釋這一版塊，因為之前有學長跟我強調過 規範的問題，所以對這方面比較重視，後來當使用每個ide的時候，都會去注意 縮排的快捷鍵，比如idea的ctrl alt l等等 我對自己寫的 還算比較滿意，但是在注釋這一塊確毫無頭緒，不知道什麼是標準，以前看過標準的注釋，記得...