嵌入式系统开发项目管理
項目生命周期五大階段
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的工作量。
表述方式(樹狀圖+列表)
- image-20201110210209743
-
變更管理
所有的變更一定要經過CCB(Change Control Board，變更管理委員會，即與此變更有關的關系人參與決策的會談)的同意，并造出新的計劃書，嚴禁接受客戶私下變更規格的請托。
- image-20201110211121028
(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模型估算成本
- image-20201110225129815
-
成本估算誤差來源：
基礎數據不足，項目仍存在許多不定因素
項目成本對需求敏感
經驗不足或低劣的成本估算技術
簽約前后不連貫
只有等WBS做出來后，且工作被分割的越細，估算才能最接近實際。但往往實際工作做不可能等你做完WBS才報價。推薦《人月神話：軟件項目管理之道》。在嵌入式軟件項目中人力成本是總成本最主要的部分；
-
掙值管理
主要用于項目成本和進度的監控，它將目前為止所完成的工作與項目計劃里的估計值比較，以提供關于項目距離完成還有多遠的估量，PM可以得到距離項目完成還需花費多少資源。
(4)項目質量(Quality)管理
-
基本思想
質量是規劃出來的，而不是檢查出來的，預防重于治療，要在規劃階段就做好“質量計劃”，并明文公布；可以先粗線條定下baseline，再制定細則。
項目質量是所有開發人員工作質量之積；
質量管理并非一次性活動，而是貫穿整項目生命周期；
質量等級是相對的，以客戶需求和價格而定；
質量管理是一種精神，并非通過ISO9000或CMM就能做出有質量的產品。
質量管理系統：ISO9000或CMMI
- CMM的5級管理體系
-
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、項目執行/控制階段
軟件工程與項目管理如何配合執行？
- image-20201114130434239
軟件工程包含三個循環過程：
開發過程定義：包含軟件需求、軟件開發過程、軟件配置管理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管理、變更管理等)記錄下來，并定期備份。
明確規定執行項目結項流程的起訖時間，最好不超過一周，并于項目成員的部門主管以及現任的項目經理溝通與協調，請這些同事們在某段時間內幫這個項目最后的忙。
總結
以上是生活随笔為你收集整理的嵌入式系统开发项目管理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 项目管理习题及解答
- 下一篇： windows编译librtmp