項目生命週期五大階段

1、項目啓動階段

（1）項目可行性分析

一個成功的產品，應該從以下3個方面來觀察評估：

設計產品：商業行爲
- 產品設計前，要做好市場調查和評估，要考慮產品的時效性、市場需求和技術可行性；
- 產品設計結束後要寫下詳細的產品規格（技術層次、人力資源、開發費用、產品成本）
- 儘量避免中途更改產品規格；
- 凡事以最終用戶需求或體驗爲準。
管理項目：管理行爲
- 項目經理必須清楚瞭解其任務事在規定的期限內完成質量可接受的產品開發，在此前提下必須衡量人力及其它相關資源，只做該做的事，能夠因時制宜。
開發系統：技術行爲
- 不要追求完美，只需達到在規定的時限，有限的資源條件下，設計開發出“足夠好”的滿足需求的產品就好。
- 設計工作一定要確實執行，絕對要文件化。不能爲了敢進度而跳過設計直接進行程序編寫。

需求管理者確定 ——> 需求分析&Review ——> 項目規模估算 ——> 項目風險分析 ——> 初步項目執行計劃&Review

（2）項目授權書

明確說明項目目標與管理方向

明確對授權PM

任何與項目有關的信息

（3）理清必要的約束

確認產品規格（成本/性能/質量/。。。需求）

確認產品限制

初步確認將參與項目的公司與單位

確認開發模式（S/W Development Life Cycle）

Waterfall Model

Prototype Model（初期需求不明確）

Spiral Model（Waterfall + Prototype的多次迭代）

。。。

2、項目規劃階段

初期規劃：是否該接這個項目？

沒規劃，一定掛！在確定接項目前，一定要做過極爲仔細的分析。
完成不可能的任務！因爲客戶交付的項目肯定不會太簡單。

（1）Scope/Time/Cost/Quality Plan

（2）Resource/Communication Plan

（3）Risk Plan

（4）Configuration Plan

（1）項目範圍（Scope）管理

妥協的藝術：進度 VS 規格

質能守衡原則，如果客戶一再壓縮進度，那隻能降低規格；若客戶一再變更規格，那隻能delay進度。

當項目啓動後，首先就是要花時間做好項目的範圍管理（哪些該做，哪些不該做），唯有定義出正確的範圍，之後做的進度、成本和人力計劃纔是有意義的。

項目管理工具——Work Breakdown Structure,WBS和變更管理

WBS
- 工作分解，其它項目計劃最重要的依據
- 分解的標準：
- 按“功能組成”分解
- 按“項目生命週期”分解
- 按照“系統架構”分解
- WBS的最小分解單元（Work Package）要非常具體，至少拆分到一週或40HRs的工作量。
- 表述方式（樹狀圖+列表）
變更管理
- 所有的變更一定要經過CCB（Change Control Board，變更管理委員會，即與此變更有關的關係人參與決策的會談）的同意，並造出新的計劃書，嚴禁接受客戶私下變更規格的請託。

（2）項目進度（Time/Schedule）管理

時間與其他資源特性不同，它具有單向性、不可重複性、不可替代性。
規劃“進度計劃”：
- 從WBS中取得所有的最小活動單元（樹狀圖中的葉節點leaf）
- 確認各任務間的關係（持續時間、次序關係）
- FS（Finish to Start）：任務A結束後，任務B纔可以開始；
- FF（Finish to Finish）：任務A結束後，任務B纔可以結束；
- SF（Start to Finish）：任務A結束後，任務B纔可以結束；
- SS（Start to Start）：任務A開始後，任務B纔可以開始；
- 進度管理圖表（Gantt圖+網絡圖）
- 甘特圖描述各任務的起訖時間，也可用來執行“進度追蹤”；
- 網絡圖描述各任務間的先後關係（節點代表任務，箭頭指示任務次序，箭頭邊的數字代表所需時間），用來找到關鍵路徑CPM（圖中用時最長的路徑），唯有縮短關鍵路徑上任務的時間，才能縮短整個項目的週期。
管理預留
- 爲整個項目預留時間（一般是整個項目週期的10-15%），不到不得已，不要拿出來用。
- 根據帕金森定律，不論你給員工多少時間，他總傾向於用完分配給他的時間。
需知道的原則
- 進度計劃是用來遵守而不是修改的。當延遲發生時，PM和主管應該積極設法解決問題並設法趕上進度，而不是修改進度。
- 規劃進度表時，應該由粗到細，協調並整合各單位的意見，切記閉門造車。
- 進度與成本呈反比。
- WBS分解的好壞直接影響項目進度計劃
- 執行時期必須不斷檢查項目計劃與實際進度是否存在偏差，並及時追蹤和處理。

（3）項目成本（Cost）管理

軟件系統的項目成本預估永遠不會很精確，只能依靠經驗或業界共識來提高精度。
項目是商業行爲，開發出一件不賺錢的產品不如不開發。一切要爲成本讓步。
成本的幾個主要來源：
- 管理成本
- 硬件/結構設計成本
- 生產&材料成本
- 軟件開發成本（代碼行、函數點、人月。。。）
- COCOMO模型估算成本
成本估算誤差來源：
- 基礎數據不足，項目仍存在許多不定因素
- 項目成本對需求敏感
- 經驗不足或低劣的成本估算技術
- 簽約前後不連貫
只有等WBS做出來後，且工作被分割的越細，估算才能最接近實際。但往往實際工作做不可能等你做完WBS才報價。推薦《人月神話：軟件項目管理之道》。在嵌入式軟件項目中人力成本是總成本最主要的部分；
掙值管理

主要用於項目成本和進度的監控，它將目前爲止所完成的工作與項目計劃裏的估計值比較，以提供關於項目距離完成還有多遠的估量，PM可以得到距離項目完成還需花費多少資源。

（4）項目質量（Quality）管理

基本思想
- 質量是規劃出來的，而不是檢查出來的，預防重於治療，要在規劃階段就做好“質量計劃”，並明文公佈；可以先粗線條定下baseline，再製定細則。
- 項目質量是所有開發人員工作質量之積；
- 質量管理並非一次性活動，而是貫穿整項目生命週期；
- 質量等級是相對的，以客戶需求和價格而定；
- 質量管理是一種精神，並非通過ISO9000或CMM就能做出有質量的產品。
- 質量管理系統：ISO9000或CMMI
QA（Quality Assurance）

專注在流程的正確性上，是一種管理職能。QA的主要目的就是確保產品在既定進度與預算下，能達成預期質量水平與可靠度目標。QA的工具就是稽覈（Audit），從計劃擬定、模塊設計、Code Review、測試計劃、生產流程、備料計劃等各階段都要進行稽覈。規劃階段的工作產品是制定質量規劃書，明確項目採用的質量標準，確定如何滿足該標準的要求。特別是：
- 完成了某個里程碑
- 提出了變更要求
- 項目即將進入下階段時
QC（Quality Control）

專注在流程bug的查找和追蹤上，是一種檢查職能。QC必須確定項目結果與質量標準是否相符，同時查找不符的原因（bug）和跟蹤是否妥善解決（每個bug的處理流程都必須記錄下來）。規劃階段的工作產品是制定測試計劃。

（5）項目人力資源（Human Resource）管理

人員的組織管理是否得當，是影響軟件項目的決定性因素。
MS有一個明確的規則——項目組的人員不要超過10人。
組織結構：
- 職能型組織（組織與項目利益可能衝突）
- 項目型組織（資源重複，無法貫徹公司策略）
- 矩陣型組織（職能或部門經理與項目經理的衝突）
- 強矩陣組織
團隊管理
- 創建由實際存在感的項目團隊
- 建立獎勵機制
- 確立良好的人際關係
- 設定工作授權系統
- 激勵理論：因才適所、投其所好

（6）項目溝通（Communication）管理

管理中70%的錯誤是因爲不善於溝通造成的，PM 80%以上的時間是用在溝通上。
溝通計劃：
- 溝通需求：哪些人、哪些時候、需要哪些需求？
- 溝通內容：溝通的格式、內容、詳細程度等
- 溝通方法：明確溝通方式與溝通管道（會議、bug管理軟件、工作報告）
- 溝通職責：誰發送消息，誰接收消息
- 溝通安排：在項目計劃中必須包含重要溝通事件的Schedule。（例如review meeting）
溝通渠道計算：若項目中有N個人，那麼需要建立N(N-1)/2條溝通渠道，相當於溝通成本就很高。

（7）項目風險（Risk）管理

Risk三要素：
- 是某個事件
- 有發生的概率
- 會對項目造成一定的影響
風險管理最容易被忽略也是最難以管理的
風險管理流程（循環往復）：
- 風險識別：列出風險列表
- 項目缺乏可見度
- 新技術的吸引力
- 技術兼容性風險
- 性能風險：增加執行設計階段的力度、製作原型（Prototype）等
- 倉促上線風險
- 可用性問題
- 缺料、零件漲價
- 合約風險：同法務詳細檢查合約內容
- 需求變更風險：提前以書面形式約定好變更處理流程
- 溝通不良風險：項目溝通計劃制定與公佈
- 缺乏高層支持風險
- 進度風險：若Schedule無法調整，則儘量多獲取資源與預算，或者分階段交付產品。
- 質量風險：慎重製定項目質量策略，成立質控小組。
- 團隊成員能力風險：提前培訓或變更成員。
- 團隊合作風險：目標明確，績效制度公平。
- 人員流動風險：核心工作分派給多人執行。
- 協助廠商風險：合作前即制定審覈稽覈與驗收流程。
- 風險評估
- 定性分析
  - 列出概率/嚴重性矩陣
  - 對項目的薄弱環節有一定的瞭解
- 定量分析：基於定性分析成果的數學處理與表達
- 列出風險排行榜（概率 X 嚴重性）
- 風險規劃（處理）
- 迴避風險：主動放棄或拒絕使用導致風險的方案，尋找替代方案
- 轉移風險：將風險轉移給外包公司
- 損失控制：減緩風險發生時的危害程度
- 承擔風險：對發生概率低或影響小的風險，可選擇先不處理
- 風險控制

（8）項目採購/合約管理

軟件外包：實際比自身開發的淨投資多15%至20%
外包項目的管理比自己開發更復雜：
- 技術難度
- 溝通複雜度
- 外包成本
外包項目注意事項：
- 溝通問題
- 做好詳細計劃
- 避免延誤
- 明確驗收標準（軟件規格與API。。。）

（9）項目配置（Configuration）管理

貫徹開發的全過程，目的是用於建立和維護產品的完整性和可追溯性
對應軟件開發項目中成熟的版本控制流程
軟件配置管理——簡單說就是項目資產管理，對開發過程中的產品進行標識、追蹤、控制的過程，包括：
- 項目的全貌，包含產品規格與設計規格。
- 項目原始的計劃，以及項目運行期間所有曾做過的變更。
- 設計階段的任何重大轉折點、與項目運行期間技術上的重大突破。
- 軟件開發期間曾遇到哪些問題，解決的方式是什麼？對應的程序代碼是什麼？
- 重要軟件版本或項目里程碑所代表的意義，以及該事件點項目狀況的快照
- 硬件設計與生產階段的問題履歷即解決方式。

3、項目執行/控制階段

軟件工程與項目管理如何配合執行？

軟件工程包含三個循環過程：

開發過程定義：包含軟件需求、軟件開發過程、軟件配置管理SCM
軟件開發：包含軟件設計、軟件構建、測試、維護和更新
軟件質量保證：軟件質量

項目管理過程包含三個循環過程：

項目規劃
項目實施
項目監控

（1）產品規格設計

產品規格寫完，最後必須再讓客戶確認一次並簽字！以後所有設計工作必須以此爲模板。一旦客戶要將新的需求變成“規格”，必須改動已通過審查的正式文件，而這要經過質量管理體系的同意。

一般來說產品規格包含以下方面：

硬件規格簡介
產品設計理念、限制與應用範圍
使用者功能說明書
操作流程圖
使用者界面與美工圖案
性能規定
特殊注意事項

（2）硬件設計

硬件設計階段的工作如下，除了外觀與結構設計外，固件工程師應儘量參與：

CPU選擇
主要芯片選擇
電路設計
Layout
零件、物料管理
產品外形設計
結構設計
開模前的模型製作

在此階段輸出的文件有：

硬件設計規格書
BOM表
3D外觀圖
結構圖
原理圖
Layout圖

（3）系統設計

根據項目大小或硬件環境，選擇合適的設計方法。如果是CPU主頻僅有幾十M，且內存又很小，建議選擇結構化方法設計，並選擇C語言進行開發。如果項目較大，CPU主頻幾百M，且存儲資源豐富，則選擇面向對象方法，語言上可選擇C++或Java語言。

（4）測試計劃設計

軟件測試也有標準，IEEE 829詳細描述了測試計劃書的規定與注意事項，但實際情況是，要按照項目本身特點，傳承該標準的思想和精神。在測試前，需要着重瞭解較複雜的功能、新功能、客戶特殊的要求或規格書中描述較模糊的地帶，然後才設計測試個案testing case和計劃。

（5）風險評估

最普遍的風險有以下幾個：

進度拖延
需求膨脹
人員流失
規格崩潰
績效低落
技術落差
文化差異
軟硬件整合
生產製造問題

風險識別流程：

面對風險的4種處理方法：

迴避：不去碰觸會產生風險的部分
抑制：準備足夠的時間與金錢，在風險成型時砸下去
舒緩：在風險成型前，就先採取某些措施
逃避：什麼都不做，祈求老天保佑

（6）動手編碼前先寫設計文件

從項目開始就應該準備一個服務器存放並管理項目的所有文件，並讓所有項目成員都可以很容易取得所需的文件或記錄。

應該被記錄的文件包含:

產品規格
schedule
硬件設計相關文件（CPU PIN腳配置圖、原理圖、Layout圖等）
技術文件-芯片的datasheet、3rd party軟件函式庫的API等
系統架構設計規格書（包含各模塊API）
測試計劃書
測試報告及bug sheets
質量文件
重要會議記錄
重要郵件備份
其它需要記錄的文檔

（7）設計審查（design review）

設計審查的原則：

設計審查必須師漸進式的。且要貫穿設計的全過程
設計審查時要邀請該設計的客戶參加
越是大範圍的設計，越要召集所有項目人員參加。

（8）實作階段

當所有設計文件都通過審查後，就可以進入實作階段了。其包含以下內容：

程序開發與調試
硬件（電子、結構）開發
軟件與硬件測試
質量相同執行
工廠試產

項目的每一個階段都應該根據PDCA（Plan、Do、Chick、Act）循環。當在程序編寫時發現設計有問題，切不可自行修改，必須暫時局部停下實作的腳步，找出對策，確認影響範圍，通過相關單位的設計審查後，纔可以再繼續實作。也即就是“設計變更”流程

嵌入式相同開發的成果最終要產品化，所以不可避免要和工廠打交道。

軟件工程師必須交付給工廠的項目有：
- 用來燒錄的Binary File
- 生產線專用自動測試程序與說明書
- 環境測試專用的測試程序
硬件、電子工程師必須交付給工廠的項目爲：
- 電子電路
- 電氣工程規格
- 特殊規格測試說明（工廠之前沒生產過的功能）
結構工程師必須交付給工廠的項目爲：
- 組合圖（把所有零件一一展開）
- 特殊部品外形圖
- 特殊加工組合圖

4、項目結項階段

（1）對外合約結項

（2）對內項目結項

項目資料歸檔

技術數據歸檔

記錄經驗，累計企業的項目資產

close meeting，人員解散

在項目執行期間，制定流程，並使用自動化工具，將項目開發的軌跡（包含程序、文件、bug管理、issue管理、變更管理等）記錄下來，並定期備份。

明確規定執行項目結項流程的起訖時間，最好不超過一週，並於項目成員的部門主管以及現任的項目經理溝通與協調，請這些同事們在某段時間內幫這個項目最後的忙。

嵌入式項目管理一般方法