IPD_-技術開發(fā)流程

Page1 Content 概述技術規(guī)劃流程 TPP 技術 平臺開發(fā)流程 TPD 領域架構 DSSE CBB管理 Page2 什么是CBB CBB CommonBuildingBlock共用基礎模塊 基礎模塊 BB 是系統(tǒng)中一組實現(xiàn)特定功能 具備接口要素 性能及規(guī)格的實體單元 而CBB指可共用的基礎模塊即可兩個或兩個以上的產(chǎn)品系統(tǒng)中直接應用的基礎模塊 CBB可分為 自制件CBB 外購件CBB CBB具備以下特征共用性 可集成界面清晰 功能 性能指標明確 可維護 可測試 有完善的資料手冊 CBB的來源基于架構開發(fā)的CBB基于已開發(fā)系統(tǒng)后向整理CBB 遵循技術趨勢與技術歸納 規(guī)劃出的共用模塊外購的CBB Page3 高價值BB和高價值CBB 高價值BB CBB 為公司帶來較高價值或可能產(chǎn)生重大影響的BB CBB 高價值BB必須滿足下列條件之一 占公司或產(chǎn)品線硬件發(fā)貨額80 的產(chǎn)品所應用的BB 占公司或產(chǎn)品線軟件發(fā)貨代碼總量80 的產(chǎn)品所應用的BB 對公司或產(chǎn)品線產(chǎn)品發(fā)展影響較大 有戰(zhàn)略意義的BB 價值下跌很快且采購成本很高的外購件 如CPU 主板 對產(chǎn)品制約很大 有較大采購風險的外購件 供應商獨家供貨的外購件 對采購成本影響較大的外購件 對總體方案有較大影響的關鍵器件 Page4 什么是平臺 平臺是特定架構及基于此架構的一組技術構件的有機集合 平臺為產(chǎn)品提供通用基礎能力 產(chǎn)品以平臺為基礎加上客戶化特性能快速形成不同產(chǎn)品系列 平臺的特征 基于特定架構共享性 通用性具有較高的戰(zhàn)略價值高度可集成性 可快速實施具備二次開發(fā)能力 極易擴充與產(chǎn)品之間的界面清晰 可實現(xiàn)上層應用的技術無關性 Page5 技術體系流程及周邊流程關系 SourcingPlan流程 CBB管理流程 TPD流程 概念 計劃 開發(fā) 遷移 需求管理流程 IPD流程 概念 計劃 開發(fā) 驗證 發(fā)布 LC 執(zhí)行 啟動 分析 融合和優(yōu)化 TPP流程 技術CDP 預研流程 架構開發(fā)流程 MM SP MM ABP CDP MM流程 Page6 技術管理體系相關團隊 IRB ITMT PL IPMT C PMT PL PMT PL TMT C TMT C TMG TDT PL TMG TDT PF BMT PDT C GTO PL GTD ITMT IntegratedTechnologyManagementTeamTMT TechnologyManagementTeamTDT TechnologyDevelopmentTeamGTO CorperationGeneralTechnologyOfficeGTD GeneralTechnologyDepartmentTMG TechnologyManagementGroup Page7 技術規(guī)劃流程TPP Page8 技術規(guī)劃流程與MM流程的銜接 啟動 分析 融合和優(yōu)化 執(zhí)行 技術規(guī)劃流程 TPP 公司戰(zhàn)略和業(yè)務方向技術趨勢競爭對手信息上期路標及執(zhí)行情況業(yè)務計劃 產(chǎn)品路標 技術趨勢分析報告 產(chǎn)品線目標 市場技術信息 技術路標 技術 平臺開發(fā)應領先產(chǎn)品開發(fā)6個月 MM SP 產(chǎn)業(yè)與投資方向 MM BP 里程碑落實 年度目標策略及預算 MM Charter 初始產(chǎn)品包商業(yè)計劃制定 市場管理流程 MM 交叉評審 Page9 技術規(guī)劃流程 TPP 框架 執(zhí)行階段 啟動階段 分析階段 融合優(yōu)化階段 輸出 輸入 主要活動 Page10 技術規(guī)劃團隊角色定義 Page11 技術 平臺項目Charter開發(fā)流程 產(chǎn)品線技術規(guī)劃PDC結果客戶需求 OR 技術發(fā)展趨勢分析報告 技術 平臺CDP 技術平臺項目任務書材料包技術平臺項目任務書 適用范圍 所有技術 平臺開發(fā)項目 包括 架構 平臺 子系統(tǒng) CBB 技術開發(fā) 技術 平臺Charter開發(fā)小組 組長 規(guī)劃師 TDT代表 用戶TDT PDT代表 RME Charter開發(fā)小組 責任主體仍然是TMT 輸入 輸出 Page12 業(yè)務分層模型 MM IPD 市場機會面向客戶數(shù)據(jù)收集業(yè)務規(guī)劃投資決策 各層次通過MM流程 根據(jù)不同層次特點進行裁剪 面向外部市場 通過OR流程收集信息數(shù)據(jù) 通過IPD進行開發(fā) 支撐產(chǎn)品發(fā)展影響IPMT決策架構開發(fā)CBB技術規(guī)劃 技術體系負責內(nèi)部層次 根據(jù)TPP進行技術規(guī)劃 根據(jù)TPD開發(fā)架構 平臺 CBB及技術 外部層次 內(nèi)部層次 集成服務層 外部市場 解決方案層 技術層 產(chǎn)品層 子系統(tǒng)層 平臺層 TPP TPD 業(yè)務分層就是按照業(yè)務類別和價值鏈劃分的層次分類 依據(jù)銷售狀況和應用范圍進一步劃分為外部業(yè)務分層和內(nèi)部業(yè)務分層 Page13 異步開發(fā) AsynchronousDevelopment 框架 異步層的相互配合關系應該在早期的業(yè)務規(guī)劃和路標定義時就得到明確 PMT和TMT在產(chǎn)品規(guī)劃和技術規(guī)劃活動中形成互動 明確定義技術和平臺的每個R版本所支持的產(chǎn)品的R版本 其主要特性和需求 以及R版本TDCP時間 PDT product 平臺參考架構 系統(tǒng)參考模型 技術管理體系 技術路標 版本火車 核心能力中心 CBB 業(yè)務分層 依賴關系管理 技術戰(zhàn)略 業(yè)務戰(zhàn)略 IBT Page14 技術 平臺開發(fā)流程TPD Page15 平臺與產(chǎn)品有何不同 Page16 平臺與產(chǎn)品的差異決定了開發(fā)流程的不同 基于平臺和產(chǎn)品的差異 開發(fā)流程除需在技術和質(zhì)量標準等方面有較高要求外 還要考慮了以下方面的差異 市場 平臺重點關注戰(zhàn)略支撐 不直接對外銷售 不涉及定價 預測 訂單履行等 Marketing代表的職責重在需求控制和平臺內(nèi)部推廣 財務 財務核算重點關注成本核算和目標成本的達成 不關注收入和利潤 技術支持 平臺的客戶是用戶PDT 技術支持方式有別于產(chǎn)品 主要職責是支持用戶PDT進行二次開發(fā) 其技能要求和服務模式與產(chǎn)品的要求有較大差異 研發(fā) 平臺是產(chǎn)品的一個部件 需在產(chǎn)品中集成驗證后才能達到量產(chǎn)要求 流程中需有一個遷移階段來保證平臺順利遷移到產(chǎn)品 并有效支持產(chǎn)品驗證和轉產(chǎn) 制造 平臺需要集成到產(chǎn)品才能完成最后的轉產(chǎn)過程 因此平臺開發(fā)流程不需要獨立定義相應的量產(chǎn)活動 TPD流程體現(xiàn)了平臺的差異性 是客戶化的IPD流程 Page17 TPD流程在各個階段充分考慮了平臺的特點 完成初始技術 平臺的開發(fā)關注于平臺的遷移準備和發(fā)布平臺最終規(guī)格和相關文檔 完成初始產(chǎn)品的開發(fā)開發(fā)集成配置器 開始營銷宣傳 向定價 預測提供支持 逐步上量準備 關注于從PDCP到TDCP項目計劃關注平臺向產(chǎn)品遷移及如何向用戶PDT提供技術支持的遷移計劃 關注于PDCP到GA的項目計劃關注盈利計劃 訂單履行計劃 轉產(chǎn)及生命周期管理計劃 產(chǎn)品包需求關注為所支撐的多個產(chǎn)品系列提供核心能力的通用需求側重于評估平臺的技術競爭力及目標成本的可達性 產(chǎn)品包需求關注于來自特定客戶群的 可提供差異化競爭能力的市場需求側重于評估市場競爭及盈利能力 將平臺遷移給用戶PDT 根據(jù)遷移計劃支持各個用戶PDTTR4到GA的所有活動 保證平臺有效集成到產(chǎn)品中 驗證產(chǎn)品 Beta SVT 標竿等 開展ESP 發(fā)布最終產(chǎn)品規(guī)格及相關文檔 發(fā)布產(chǎn)品 制造足夠數(shù)量的滿足客戶需求的產(chǎn)品 遷移階段 重點關注對產(chǎn)品戰(zhàn)略的支持 重點關注對業(yè)務計劃的支持 開發(fā)階段 計劃階段 概念階段 驗證階段 發(fā)布階段 Charter IPD流程 TPD流程 監(jiān)控生產(chǎn) 營銷和銷售 客戶服務和支持等方面的績效 直到EOX 生命周期 Page18 平臺和技術的遷移 遷移到PDT1 遷移到PDTn 責任主體仍然在TDT 活動主要通過遷移計劃來指導 由以FAE為主維護團隊提供后期技術支持服務工作 遷移計劃完成 TDT合同關閉 此時遷移計劃中所標識的用戶PDT已經(jīng)全部通過ADCP 技術 平臺合同評估活動啟動 TDCP為遷移階段的起始點 而不是終止點 TDCP主要評估技術 平臺向用戶產(chǎn)品遷移準備度是否達到要求 遷移階段的終止點為技術 平臺生命周期結束點 也就是所有使用此技術 平臺的用戶產(chǎn)品生命周期結束 Page19 遷移策略與計劃 遷移計劃是遷移階段TDT活動的核心指導 是遷移階段TDT的項目計劃 它明確了TDT需要支持那些用戶PDT 對于每個用戶PDT需要支持哪些活動 需要哪些資源等 遷移計劃由TDT經(jīng)理組織開發(fā) 發(fā)布前需要各用戶PDT充分溝通并得到其認可 最終經(jīng)ITMT PL IPMT的批準生效 概念階段主要集中在遷移策略的制定 計劃階段完成詳細計劃 TDCP前根據(jù)開發(fā)階段活動狀態(tài)進一步優(yōu)化 遷移計劃的執(zhí)行期限為從TDCP開始到合同結束點終止 在遷移計劃執(zhí)行期間 TDT仍作為一個獨立的責任主體存在 是技術支持的責任人 負責管理和維護遷移計劃的執(zhí)行狀態(tài) 遷移計劃完成后 技術支持服務工作轉由以FAE為主的維護組負責 Page20 中小技術項目操作指導 需求明確 低風險項目 TR1與TR2可合并 CDCP與PDCP可合并 設計規(guī)格明確 TR1 TR2可與TR3合并 CDCP可合并到PDCP 基于原有架構的增量開發(fā) AR可合并到TR2中 注 TR的合并或裁減由SE提出 PQA確認后寫入質(zhì)量計劃 同時需在相應DCP業(yè)務計劃中明確 純軟件的項目 TR4A可合并到TR5中操作 對于小項目 Charter一般合并到PDCP中 Page21 DSSE流程和方法 Page22 背景知識 架構定義及內(nèi)涵 SEI給出的架構定義 架構是指一個系統(tǒng)的一個或多個結構 視圖 它包括組成系統(tǒng)的元素 元素的外部可見屬性以及元素之間的相互關系 IEEE給出的架構定義 架構是以構件 構件之間的關系 構件與環(huán)境之間的關系為內(nèi)容的某一系統(tǒng)的基本組織結構 以及指導系統(tǒng)設計與演化的原理 談論架構時 首先要界定 系統(tǒng) 在界定了系統(tǒng)后 再考慮刻畫系統(tǒng)的元素 組件 有那些 另外架構是對設計的約束 其約束的作用域也需要明確 組成系統(tǒng)的元素 組件是一類元素 元素的外部屬性及元素之相的關系是系統(tǒng)架構的三個要素 因此 在進行架構設計時不要把精力放到不屬于架構范疇的元素內(nèi)部細節(jié)上面 SEI的定義強調(diào)了架構的多結構 多視圖 IEEE的定義中強調(diào)了架構包含的 設計原理 二者不是矛盾的 而是互補的 架構的交付除多個視圖外 還包括設計規(guī)范 原理 SEI的定義明確指出一個系統(tǒng)包含了多個結構 視圖 其中任何一個結構都不能和系統(tǒng)的架構劃等號 如下圖 一個系統(tǒng)包含三個視圖 每一視圖對應于系統(tǒng)不同的側面 每個系統(tǒng)都有自己的架構 架構獨立于架構的描述而存在 經(jīng)常所說的一個系統(tǒng) 沒架構 往往是指這個系統(tǒng)架構不好 質(zhì)量太差 或者說沒有將架構進行編檔 顯現(xiàn)出來 系統(tǒng) 部署視圖 動態(tài)視圖 靜態(tài)視圖 模塊 進程 單板 Page23 背景知識 領域及領域架構 期望大家關注領域的架構 即領域架構 其對應的 系統(tǒng) 和 元素 是 系統(tǒng) 具有相近需求的一組產(chǎn)品應用構成的領域 Domain 元素 不僅僅是分析元素 更重要的是設計元素 為何要關注領域架構 為了產(chǎn)品應用間的重用 即實現(xiàn)基于領域架構的重用 領域架構特征 面向一個嚴格定義的問題域 是對整個領域的合適程度的抽象 具有普遍性 使其可以用于指導和約束領域中某個特定應用的開發(fā) 具備有該領域穩(wěn)定的在開發(fā)過程中可重用元素 領域及領域架構舉例 基站領域架構 VISA RB基站控制器領域架構 VISA RC GSM BTS CDMA BTS WCDMA NodeB 基站領域 GBSC CBSC WRNC 基站控制器領域 Page24 背景知識 雙生命周期模型 應用領域和產(chǎn)品應用都是我們的開發(fā)對象 可以此來分層地組織和實施全流程開發(fā)活動 以領域為開發(fā)對象的活動稱之為領域工程 以單個產(chǎn)品應用為開發(fā)對象的活動稱之為應用工程 領域工程和應用工程相對獨立 又相互關聯(lián) 領域工程各階段的輸出都能作為應用工程的輸入 從而被一組產(chǎn)品應用而重用 應用工程在領域工程結果的基礎上構造新產(chǎn)品 領域工程也要從應用工程中獲得反饋或結合新產(chǎn)品的需求進入新一輪發(fā)展周期 即產(chǎn)品線演化 基于領域視野開展分析 設計和實現(xiàn)工作 可主動實現(xiàn)領域內(nèi)最大重用 領域分析 領域設計 領域?qū)崿F(xiàn) 領域模型 領域架構 平臺 CBB 需求分析 系統(tǒng)設計 系統(tǒng)實現(xiàn) 領域工程 應用工程 產(chǎn)品需求 產(chǎn)品 核心資源 平臺 CBB Developmentforreuse Developmentwithreuse 領域需求 Time DevelopedObject 公共開發(fā) 產(chǎn)品化開發(fā) Page25 什么是DSSE DSSE Domain SpecificSystemEngineering 是一套領域系統(tǒng)分析和設計的流程和方法 DSSE的理論基礎來自于軟件工程業(yè)界的 產(chǎn)品線 工程 方法上借鑒了UP UnifiedProcess 方法以及瑞研所為無線某基站平臺開發(fā)所提供的設計方法 模型表述上遵從UML規(guī)范 DSSE適用范圍嵌入式應用領域 也適用于網(wǎng)管軟件和服務器軟件產(chǎn)品應用領域 DSSE的設計思想可被借鑒到產(chǎn)品的系統(tǒng)設計活動中 DSSE的特點面向特定領域的復用技術用例驅(qū)動的開發(fā)以架構為中心支持以迭代方式開發(fā)系統(tǒng)使用UML建立可視化的模型交付版本DSSEV1 1 DSSEV1 0版本2005年年中在總體技術體系內(nèi)部已發(fā)布試用 Page26 架構管理體系概述 ITMT C TMT C GTO 架構與設計管理部 PL IPMT PL TMT 下轄架構委員會 PL GTD 架構設計部 制定規(guī)劃技術決策 依據(jù)決策和規(guī)劃例行管理和監(jiān)控 組織或承擔架構設計任務負責架構管理與維護 跨產(chǎn)品線領域架構 產(chǎn)品線內(nèi)領域架構 業(yè)務決策規(guī)劃審批 ITMT PL IPMT負責領域架構的規(guī)劃審批 以及同架構相關的業(yè)務決策 C TMT PL TMT負責制定架構規(guī)劃 架構相關的技術決策 該職責也可委托相應的架構委員會來行使 C GTO PL GTD負責依據(jù)上級決策和規(guī)劃 例行管理和監(jiān)控架構項目 總體辦架構與設計管理部負責組織跨產(chǎn)品線的領域架構設計 管理及維護工作 產(chǎn)品線架構設計部負責產(chǎn)品線內(nèi)的領域架構設計 管理及維護工作 Page27 架構設計部與系統(tǒng)設計團隊的關系 架構設計部負責領域分析和領域架構設計 含新形態(tài)產(chǎn)品的架構設計 產(chǎn)品SEG負責產(chǎn)品的系統(tǒng)設計 平臺SEG負責平臺的系統(tǒng)設計 產(chǎn)品線架構設計部在設計業(yè)務上指導和約束產(chǎn)品系統(tǒng)設計團隊和平臺系統(tǒng)設計團隊 一方面 產(chǎn)品系統(tǒng)設計和平臺系統(tǒng)設計要遵從領域架構的設計約束 另一方面 在系統(tǒng)設計活動中 平臺和產(chǎn)品間的技術沖突也需要架構設計部來協(xié)調(diào)和仲裁 PL IPMT 研發(fā)部 PL TMT PL GTD 架構設計部 平臺開發(fā)部 系統(tǒng)部 產(chǎn)品族開發(fā)部 PDT SEG TDT SEG 系統(tǒng)部 平臺設計 產(chǎn)品設計 架構設計 Page28 DSSE流程的階段 需求分析階段組建項目組 基于目標領域系統(tǒng)所在上下文網(wǎng)絡語境 建立業(yè)務模型和領域模型 分析領域包需求 使用用例分析方法和質(zhì)量屬性場景方法定義系統(tǒng)需求規(guī)格 參考需求分析的結果 制定 或調(diào)整 項目計劃 邏輯架構設計階段對目標領域系統(tǒng)內(nèi)部進行功能分析 分解得到分析模塊 建立分析模型 參考分析模型 進行邏輯架構設計 以支持領域的質(zhì)量屬性需求 實現(xiàn)分析階段對邏輯架構及其構建塊DM進行實現(xiàn)分析 劃分出領域內(nèi)公共的核心資產(chǎn) 平臺 CBB 核心資產(chǎn)的需求規(guī)格 以及他們和產(chǎn)品應用件的界限 獲得軟件 硬件模塊等實現(xiàn)組件 得到領域內(nèi)核心資產(chǎn) 平臺 CBB 實現(xiàn)架構 可選 物理架構設計階段 可選階段 規(guī)劃單板和進程 并部署DM IM到單板和進程 定義單板間物理接口 進程之間的并發(fā)關系 Page29 DSSE流程的角色 ITMT PL IPMT 負責項目的計劃決策 PDCP 交付決策 TDCP 等業(yè)務決策 TMT 初審架構項目立項charter 發(fā)起架構評估活動并負責技術決策 項目經(jīng)理 負責項目開工 項目計劃管理 項目監(jiān)控 組織領域需求評審 及其他項目管理活動 分析師 負責收集和分析領域需求 業(yè)務建模 構造系統(tǒng)用例 輸出領域系統(tǒng)需求 架構師 組織完成領域邏輯架構 實現(xiàn)分析 準備架構評估材料 回答架構評估的問題 提出典型產(chǎn)品應用的物理架構建議 架構師外圍組成員角色 復用工程師 收集并維護公司及領域范圍的平臺 CBB信息 對本領域IM SWM HWM的復用方案提出建議 屬性工程師 負責某類質(zhì)量屬性 DFx 的專項設計活動 如可靠性設計 UCD設計 可服務性設計 性能設計 可制造性設計 成本設計等 設計工程師 負責某類功能業(yè)務的設計 如操作維護業(yè)務設計 呼叫業(yè)務功能設計等 Page30 領域分析和設計方法 DSSE分析與設計活動包括如下6個工作流 Workflow BusinessModeling 理解目標系統(tǒng)所處的網(wǎng)絡 或更大系統(tǒng) 的結構 業(yè)務及其動態(tài)特性 DomainRequirements 確定領域系統(tǒng)需要考慮的需求 規(guī)范刻畫系統(tǒng)需求規(guī)格 DomainAnalysis 基于問題域視角 探索系統(tǒng)內(nèi)部 建立領域的分析模型 LogicalArchitectureDesign 基于解域 計算機域 視角 構建設計模型 獲得領域架構 ImplementationAnalysis 選擇實現(xiàn)技術 構建實現(xiàn)模型 確定領域平臺 CBB與產(chǎn)品的邊界PhysicalArchitectureDesign 構建部署模型 獲得平臺及產(chǎn)品的物理架構 BusinessModeling DomainRequirements LogicalArchitectureDesign DomainAnalysis ImplementationAnalysis PhysicalArchitectureDesign Phase1 RequirementAnalysis Phase2 LogicalArchitectureDesign Phase3 ImplementationAnalysis Phase4 PhysicalArchitectureDesign Page31 架構評估的目 特點及評估時機 架構評估