1.1.
管理基礎
1.1.1.計畫
1.估算工作時程;
2.決定多少人參與這個專案，需要什麼樣的技術能力，何時增加人員，是誰決定如何組織這個團隊;
3.選擇使用何種生命週期模型 4.
危機管理 5.
對如何控制產品的功能設定和是否購買或自製產品的每一部分等議題，做策略性的決定
rapid development
cmmi中的pp目錄
估算工作時程
人力成本估計（
effort and cost estimation
：）專案時程（
project schedule
：mpp
）決定多少人參與這個專案，需要什麼樣的技術能力，何時增加人員，是誰決定如何組織這個團隊
資源需求（
resource requirement
） 工作責任矩陣圖（
task responsibility matrix
）組織架構圖
(project team structure)
人力需求（
human resource requirement
）軟硬體需求（
software/hardware requirement
）教育訓練：
(training)
選擇使用何種生命週期模型
專案流程（
project process
：類別，生命週期模式，流程除錯）
危機管理
風險管理計畫（
risk management plan）
對如何控制產品的功能設定和是否購買或自製產品的每一部分等議題，做策略性的決定
決策分析
(decision analysis and resolution)
專案基本資料（
project profile:
客戶名，專案名代號，型別，起訖日期）
專案目的及專案範圍（
project purposes and project scope
） 專案目標（
project objects
：完成內容，管理目標，合約交付專案驗收條件）
專案環境（
project environment
：開發/
建制環境）
缺失 專案相關計畫（
relative project plan）
專案監控（
project monitoring and control
）關鍵人員參予與溝通計畫（
stakeholder involvement and communication plan
） 質量保證計畫（
process and product quality assurance plan
） 專案驗證與確認計畫（
svvp
） 建構管理計畫（
configuration management plan
）度量與分析計畫（
measurement and analysis plan
）專案門坎管理
(project threshold management)
供貨商管理計畫（
supplier management plan
） 包裝、安裝與交貨計畫
教育訓練與技術移轉計畫
驗收與結案計畫
(驗收審查會議
) 缺失
裁適準則
(tailoring guideline) 缺失
組織重用和發展計畫
(resuse & plan)
1.1.2.追蹤
依照計畫去追蹤和確認各項事宜：時程進度，成本，品質目標。
典型的管理層級追蹤控制：工作表，進度會議，進度報告，定期檢視，預算報告，不時的巡視管理。
典型的技術層級追蹤控制：技術審核，技術檢視，依里程碑所做的品質審閱。
狀況測量對於專案管理來說是必要和重要的成功因素。
在專案進行中很少知道情況進展如何是一種危險的事，應該對專案進展瞭如指掌。
追蹤是軟體管理的基礎，是預知危機提前解決的保證，也是盡快發現延遲設法彌補的保證。
1.1.3.量測
當你的老闆說：我們可以在
9個月內開發這個產品嗎？
你可以說：我們組織開發這樣的產品從來沒有少於
11個月，平均都是
13個月。
這是量測得作用之一
有資料比只靠直覺來得好。
1.2.
技術基礎
1.2.1.
需求管理
收集需求管理變更：紀錄在檔案，郵件，能執行的原型中，追蹤與其相關的設計和編碼，然後管理其他部分相關的改變。
需求分析方法學：結構分析，資料結構分析，物件導向分析
系統模型實作：古典圖，資料流程圖，實體關係圖，資料字典，狀態變化圖。
通訊實作：合作系統開發
使用者皆免原型，一般會談方法。
需求管理與不同生命週期模型之間的關係：漸進式原型，階段性發行，螺旋型，瀑布型，編碼與修改。
典型的專案在需求上會有
25%的改變。
一開始就得到正確的需求資詢所花的成本，會比直到建構或維護時才發現少50到
200倍。
1.2.2.設計
主要設計風格
(物件設計，架構設計，資料結構設計)
基礎設計概念（諮詢隱藏，模組性，抽象化，封裝，對稱，層級結構，繼承，基本演演算法，基本資料架構）
對典型挑戰的標準設計方法
(例外處理，國際化
/本地化，可移植性，字串儲存，輸入
/輸出，記憶體管理，資料儲存，浮點運算，資料庫設計，效能，和再使用)
對你所正在進行的應用程式領域作特殊的設計考量（財物應用程式，科學應用程式，嵌入式系統，即使系統，安全危機軟體，其他）
架構模式（系統組織化，層級，附屬系統溝通風格，典型系統構架）
使用設計工具
設計提供架構，專案工作時程，專案追蹤，和專案控制的基礎。
1.2.3.建構
編碼實作
（命名，格式，檔案）
資料相關概念（變數範圍，以致性，連線時間）
對使用特定資料形態的指導方針（）
與控制有關的概念
1.2.4.
軟體配置管理
版本控制
1.3.
品質確認基礎 l
品質確認
1h會在專案後期省下
3~10h
l直到建構或維修階段才處理需求錯誤的成本會比在需求階段就處理的成本多50到
200倍 l
一般而言，在前期
(需求或設計階段
)沒有偵查處的錯誤，會在後期（測試階段）花10到
100倍的成本去修改。越晚發現的錯誤會花越多的成本去修改。
1.3.1.
錯誤傾向模組
百分之80%的錯誤產生在
20%的模組上。
錯誤傾向模組的每個功能點成本是正常模組的4倍。
如果模組的錯誤比率達到每一千行有十行錯誤，或過長，或結構不好，這時重頭來重新設計模組和執行，錯誤傾向模組的確認和重新設計是必須要優先處理的。
1.3.2.測試
個人測試：開發者檢查自己的編碼並確認運作正確(發現
10%~15%
的錯誤)
系統測試：專業測試者檢查系統操作是否如預期。(發現
20%~60%
的錯誤)
其他錯誤不是終端使用者發現就是在技術檢閱中發現。
當測試時發現產品的品質低到不足以上市的時，進度一定要延後直到改善。
1.3.3.
技術檢閱
對需求，設計，測試個案，和所有專案其他非自然訊號作全盤性偵測錯誤的檢閱。 排演
(walkthroughs)
兩人或兩人以上的開發人員
(not only pg)
，以改善品質為目的而作檢閱技術工作的會議
編碼閱讀
編碼者把程式碼交給兩位或兩位以上的檢閱者，檢閱者閱讀並指出錯誤。
發現錯誤的效率是測試的兩倍。 審查
(inspections)
審查的效率比測試高20倍
仲裁者(moderator)
，確定待審的工作產品
檢閱者(reviewers)
，在會議前檢閱產品並詳細列出檢閱結果 作者
(author)
，對被審查專案進行說明，確認檢閱者發現的錯誤 紀錄
(scribe)
，紀錄錯誤，
主席，製作審查報告，說明每項錯誤並指出如何改正。收集有關資料
(錯誤，修改花費時間，審查花費時間)
1.3.4.
對技術檢閱的意見
修改錯誤要趁他們還小，還容易控制的時候。
1.4.
跟隨指示
油漆波音
747飛機，一層油漆就重達
400到
800磅，風雨會以每小時
600英里的速度打在油漆上。
《微軟開發快速秘籍》讀書筆記3 危機管理
你不主動攻擊危機，危機就會主動攻擊你。最高層次，確認取出可能造成危機的所有根源 至少也要在 pp階段預防 最壞就是救火式的在危機變成問題後再處理 危機管理 危機評估 危機確認 危機分析 危機優先性 危機控制 危機管理計畫 危機解決 危機監控 1.1.危機確認 危機列表 工作時程創造 時程，資源，產品...
讀書筆記 《快速閱讀》筆記
1.要有閱讀的目標，為什麼讀，要獲得什麼，重點是什麼 2.快速閱讀，去除默讀，一次聚焦一句話，擴充套件視野 3.集中注意力，放輕鬆 冥想訓練 坐著閉眼，只注意自己的呼吸，慢慢放鬆 4.繪製思維導圖 5.進行複述讀過的內容，並且閉上眼睛，用影像的方式再現讀過的內容 1.明確閱讀目標 為什麼讀，要獲得什...
《自適應軟體開發》讀書筆記
自適應軟體開發 這本書，剛讀時，覺得是有點理想化，但是我對把生態系統的概念引入到軟體開發管理非常欣賞。書還未讀完，從晚上發現別人寫的書評，有點極端，但也不無道理。故先 作為自己讀書筆記的第一步。聽人談了一些對於這本書的看法，感覺不是很同意他所欣賞並轉述的書的內容。所以昨天去書店站著看了大半本，覺得他...