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

1、page 1,content,概述 技術規(guī)劃流程（tpp） 技術/平臺開發(fā)流程（tpd） 領域架構（dsse） cbb,page 2,什么是cbb,cbb ( common building block 共用基礎模塊） 基礎模塊(bb)是系統(tǒng)中一組實現(xiàn)特定功能，具備接口要素、性能及規(guī)格的實體單元，而cbb指可共用的基礎模塊即可兩個或兩個以上的產品系統(tǒng)中直接應用的基礎模塊。cbb可分為：自制件cbb、外購件cbb,cbb具備以下特征 共用性、可集成 界面清晰； 功能、性能指標明確； 可維護、可測試； 有完善的資料手冊,cbb的來源 基于架構開發(fā)的cbb 基于已開發(fā)系統(tǒng)后向整理cbb： 遵循技術趨

2、勢與技術歸納/規(guī)劃出的共用模塊 外購的cbb,page 3,高價值bb和高價值cbb,高價值bb/cbb：為公司帶來較高價值或可能產生重大影響的bb/cbb,高價值bb必須滿足下列條件之一： 占公司或產品線硬件發(fā)貨額80的產品所應用的bb ； 占公司或產品線軟件發(fā)貨代碼總量80的產品所應用的bb； 對公司或產品線產品發(fā)展影響較大/有戰(zhàn)略意義的bb； 價值下跌很快且采購成本很高的外購件，如cpu、主板； 對產品制約很大、有較大采購風險的外購件； 供應商獨家供貨的外購件； 對采購成本影響較大的外購件； 對總體方案有較大影響的關鍵器件；,page 4,什么是平臺,平臺是特定架構及基于此架構的一組技術

3、構件的有機集合。平臺為產品提供通用基礎能力，產品以平臺為基礎加上客戶化特性能快速形成不同產品系列,平臺的特征: 基于特定架構 共享性、通用性 具有較高的戰(zhàn)略價值 高度可集成性、可快速實施 具備二次開發(fā)能力、極易擴充 與產品之間的界面清晰，可實現(xiàn)上層應用的技術無關性,page 5,技術體系流程及周邊流程關系,sourcing plan 流程,cbb管理流程,tpd流程,概念,計劃,開發(fā),遷移,需求管理流程,ipd流程,概念,計劃,開發(fā),驗證,發(fā)布,lc,執(zhí)行,啟動,分析,融合和 優(yōu)化,tpp流程,技術cdp,預研流程,架構開發(fā)流程,mm-sp,mm- abp/cdp,mm流程,page 6,技術

4、管理體系相關團隊,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: integrated technology management team tmt: technology management team tdt: technology development team gto: corperation general technology office gtd:general technology department tmg: technology m

5、anagement group,page 7,技術規(guī)劃流程 tpp,page 8,技術規(guī)劃流程與mm流程的銜接,啟動,分析,融合和優(yōu)化,執(zhí)行,技術規(guī)劃流程（tpp,公司戰(zhàn)略和業(yè)務方向 技術趨勢 競爭對手信息 上期路標及執(zhí)行情況 業(yè)務計劃,產品路標,技術趨勢 分析報告,產品線目 標、市場 技術信息,技術路標,技術/平臺開發(fā)應領先產品開發(fā)6個月,mm-sp產業(yè)與投資方向,mm-bp里程碑落實/年度目標策略 及預算,mm-charter初始產品包商業(yè)計劃制定,市場管理流程（mm,交叉評審,page 9,技術規(guī)劃流程（tpp）框架,執(zhí)行階段,啟動階段,分析階段,融合優(yōu)化階段,輸出,輸入,主要 活動,p

6、age 10,技術規(guī)劃團隊角色定義,page 11,技術/平臺項目charter開發(fā)流程,產品線技術規(guī)劃 pdc結果 客戶需求(or) 技術發(fā)展趨勢分析報告,技術/平臺cdp,技術平臺項目任務書材料包 技術平臺項目任務書,適用范圍： 所有技術/平臺開發(fā)項目，包括：架構、平臺、子系統(tǒng)、cbb、技術開發(fā),技術/平臺charter開發(fā)小組,組 長,規(guī)劃師,tdt代表,用戶tdt/ pdt代表,rme,charter開發(fā)小組,責任主體仍然是tmt,輸入/輸出,page 12,業(yè)務分層模型,mm/ipd,市場機會 面向客戶 數(shù)據收集 業(yè)務規(guī)劃 投資決策,各層次通過mm流程（根據不同層次特點進行裁剪）面向

7、外部市場，通過or流程收集信息數(shù)據，通過ipd進行開發(fā),支撐產品發(fā)展 影響ipmt決策 架構開發(fā) cbb 技術規(guī)劃,技術體系負責內部層次，根據tpp進行技術規(guī)劃，根據tpd開發(fā)架構、平臺、cbb及技術,外部層次,內部層次,集成服務層,外部市場,解決方案層,技術層,產品層,子系統(tǒng)層,平臺層,tpp/tpd,業(yè)務分層就是按照業(yè)務類別和價值鏈劃分的層次分類，依據銷售狀況和應用范圍進一步劃分為外部業(yè)務分層和內部業(yè)務分層,page 13,異步開發(fā)（asynchronous development）框架,異步層的相互配合關系應該在早期的業(yè)務規(guī)劃和路標定義時就得到明確。 pmt和tmt在產品規(guī)劃和技術規(guī)劃活

8、動中形成互動，明確定義技術和平臺的每個r版本所支持的產品的r版本、其主要特性和需求、以及r版本tdcp時間,pdt,product,平臺參考架構,系統(tǒng)參考模型,技術管理體系,技術路標,版本火車,核心能力中心,cbb,業(yè)務分層,依賴關 系管理,技 術 戰(zhàn) 略,業(yè) 務 戰(zhàn) 略,ibt,page 14,技術/平臺開發(fā)流程 tpd,page 15,平臺與產品有何不同,page 16,平臺與產品的差異決定了開發(fā)流程的不同,基于平臺和產品的差異，開發(fā)流程除需在技術和質量標準等方面有較高要求外，還要考慮了以下方面的差異： 市場：平臺重點關注戰(zhàn)略支撐，不直接對外銷售，不涉及定價、預測、訂單履行等，market

9、ing代表的職責重在需求控制和平臺內部推廣； 財務：財務核算重點關注成本核算和目標成本的達成，不關注收入和利潤 ； 技術支持：平臺的客戶是用戶pdt，技術支持方式有別于產品，主要職責是支持用戶pdt進行二次開發(fā)，其技能要求和服務模式與產品的要求有較大差異； 研發(fā)：平臺是產品的一個部件，需在產品中集成驗證后才能達到量產要求，流程中需有一個遷移階段來保證平臺順利遷移到產品，并有效支持產品驗證和轉產； 制造：平臺需要集成到產品才能完成最后的轉產過程，因此平臺開發(fā)流程不需要獨立定義相應的量產活動,tpd流程體現(xiàn)了平臺的差異性，是客戶化的ipd流程,page 17,tpd流程在各個階段充分考慮了平臺的特

10、點,完成初始技術/平臺的開發(fā) 關注于平臺的遷移準備和發(fā)布平臺最終規(guī)格和相關文檔,完成初始產品的開發(fā) 開發(fā)集成配置器，開始營銷宣傳，向定價、預測提供支持，逐步上量準備,關注于從pdcp到tdcp項目計劃 關注平臺向產品遷移及如何向用戶pdt提供技術支持的遷移計劃,關注于pdcp到ga的項目計劃 關注盈利計劃、訂單履行計劃、轉產及生命周期管理計劃,產品包需求關注為所支撐的多個產品系列提供核心能力的通用需求 側重于評估平臺的技術競爭力及目標成本的可達性,產品包需求關注于來自特定客戶群的，可提供差異化競爭能力的市場需求 側重于評估市場競爭及盈利能力,將平臺遷移給用戶pdt，根據遷移計劃支持各個用戶pd

11、t tr4到ga的所有活動，保證平臺有效集成到產品中,驗證產品（beta/svt/標竿等），開展esp，發(fā)布最終產品規(guī)格及相關文檔,發(fā)布產品，制造足夠數(shù)量的滿足客戶需求的產品,遷 移 階 段,重點關注對產品戰(zhàn)略的支持,重點關注對業(yè)務計劃的支持,開發(fā) 階段,計劃 階段,概念 階段,驗證 階段,發(fā)布 階段,charter,ipd流程,tpd流程,監(jiān)控生產、營銷和銷售、客戶服務和支持等方面的績效，直到eox,生命周期,page 18,平臺和技術的遷移,責任主體仍然在tdt，活動主要通過遷移計劃來指導,由以fae為主維護團隊提供后期技術支持服務工作,遷移計劃完成，tdt合同關閉，此時遷移計劃中所標識的

12、用戶pdt已經全部通過adcp，技術/平臺合同評估活動啟動,tdcp為遷移階段的起始點，而不是終止點，tdcp主要評估技術/平臺向用戶產品遷移準備度是否達到要求,遷移階段的終止點為技術/平臺生命周期結束點，也就是所有使用此技術/平臺的用戶產品生命周期結束,page 19,遷移策略與計劃,遷移計劃是遷移階段tdt活動的核心指導，是遷移階段tdt的項目計劃。它明確了tdt需要支持那些用戶pdt，對于每個用戶pdt需要支持哪些活動，需要哪些資源等。 遷移計劃由tdt經理組織開發(fā)，發(fā)布前需要各用戶pdt充分溝通并得到其認可，最終經itmt/pl_ipmt的批準生效； 概念階段主要集中在遷移策略的制定，

13、計劃階段完成詳細計劃，tdcp前根據開發(fā)階段活動狀態(tài)進一步優(yōu)化； 遷移計劃的執(zhí)行期限為從tdcp開始到合同結束點終止。 在遷移計劃執(zhí)行期間，tdt仍作為一個獨立的責任主體存在，是技術支持的責任人，負責管理和維護遷移計劃的執(zhí)行狀態(tài)。遷移計劃完成后，技術支持服務工作轉由以fae為主的維護組負責,page 20,中小技術項目操作指導,需求明確、低風險項目，tr1與tr2可合并，cdcp與pdcp可合并；設計規(guī)格明確，tr1、tr2可與tr3合并，cdcp可合并到pdcp,基于原有架構的增量開發(fā)，ar可合并到tr2中,注：tr的合并或裁減由se提出，pqa確認后寫入質量計劃，同時需在相應dcp業(yè)務計劃

14、中明確,純軟件的項目，tr4a可合并到tr5中操作,對于小項目，charter一般合并到pdcp中,page 21,dsse流程和方法,page 22,背景知識：架構定義及內涵,sei給出的架構定義：架構是指一個系統(tǒng)的一個或多個結構(視圖)，它包括組成系統(tǒng)的元素，元素的外部可見屬性以及元素之間的相互關系； ieee給出的架構定義：架構是以構件、構件之間的關系、構件與環(huán)境之間的關系為內容的某一系統(tǒng)的基本組織結構，以及指導系統(tǒng)設計與演化的原理； 談論架構時，首先要界定“系統(tǒng)”，在界定了系統(tǒng)后，再考慮刻畫系統(tǒng)的元素（組件）有那些，另外架構是對設計的約束，其約束的作用域也需要明確； 組成系統(tǒng)的元素（組

15、件是一類元素）、元素的外部屬性及元素之相的關系是系統(tǒng)架構的三個要素，因此，在進行架構設計時不要把精力放到不屬于架構范疇的元素內部細節(jié)上面； sei 的定義強調了架構的多結構（多視圖），ieee的定義中強調了架構包含的“設計原理”，二者不是矛盾的，而是互補的，架構的交付除多個視圖外，還包括設計規(guī)范(原理)； sei 的定義明確指出一個系統(tǒng)包含了多個結構（視圖），其中任何一個結構都不能和系統(tǒng)的架構劃等號（如下圖，一個系統(tǒng)包含三個視圖），每一視圖對應于系統(tǒng)不同的側面； 每個系統(tǒng)都有自己的架構。架構獨立于架構的描述而存在。 經常所說的一個系統(tǒng)“沒架構”，往往是指這個系統(tǒng)架構不好，質量太差，或者說沒有將

16、架構進行編檔，顯現(xiàn)出來,系統(tǒng),部署視圖,動態(tài)視圖,靜態(tài)視圖,模塊,進程,單板,page 23,背景知識：領域及領域架構,期望大家關注領域的架構，即領域架構，其對應的“系統(tǒng)”和“元素”是： 系統(tǒng)：具有相近需求的一組產品應用構成的領域(domain)； 元素：不僅僅是分析元素，更重要的是設計元素。 為何要關注領域架構? 為了產品應用間的重用，即實現(xiàn)基于領域架構的重用！ 領域架構特征： 面向一個嚴格定義的問題域，是對整個領域的合適程度的抽象； 具有普遍性，使其可以用于指導和約束領域中某個特定應用的開發(fā)； 具備有該領域穩(wěn)定的在開發(fā)過程中可重用元素。 領域及領域架構舉例： 基站領域架構：visa-rb

17、基站控制器領域架構: visa-rc,gsm-bts,cdma-bts,wcdma-nodeb,基站領域,gbsc,cbsc,wrnc,基站控制器領域,page 24,背景知識：雙生命周期模型,應用領域和產品應用都是我們的開發(fā)對象，可以此來分層地組織和實施全流程開發(fā)活動。以領域為開發(fā)對象的活動稱之為領域工程，以單個產品應用為開發(fā)對象的活動稱之為應用工程。 領域工程和應用工程相對獨立，又相互關聯(lián)，領域工程各階段的輸出都能作為應用工程的輸入，從而被一組產品應用而重用；應用工程在領域工程結果的基礎上構造新產品，領域工程也要從應用工程中獲得反饋或結合新產品的需求進入新一輪發(fā)展周期，即產品線演化； 基于

18、領域視野開展分析、設計和實現(xiàn)工作，可主動實現(xiàn)領域內最大重用,領域分析,領域設計,領域實現(xiàn),領域模型,領域架構,平臺/cbb,需求分析,系統(tǒng)設計,系統(tǒng)實現(xiàn),領域工程,應用工程,產品需求,產品,核心資源 （平臺/ cbb,development for reuse,development with reuse,領域需求,time,developed object,公共開發(fā),產品化開發(fā),page 25,什么是dsse ,dsse：domain-specific system engineering，是一套領域系統(tǒng)分析和設計的流程和方法；dsse的理論基礎來自于軟件工程業(yè)界的“產品線”工程，方法上借鑒

19、了up（unified process）方法以及瑞研所為無線某基站平臺開發(fā)所提供的設計方法，模型表述上遵從uml規(guī)范； dsse適用范圍 嵌入式應用領域，也適用于網管軟件和服務器軟件產品應用領域; dsse的設計思想可被借鑒到產品的系統(tǒng)設計活動中。 dsse的特點 面向特定領域的復用技術 用例驅動的開發(fā) 以架構為中心 支持以迭代方式開發(fā)系統(tǒng) 使用uml建立可視化的模型 交付版本 dsse v1.1（dsse v1.0版本2005年年中在總體技術體系內部已發(fā)布試用,page 26,架構管理體系概述,itmt,c-tmt,c-gto,架構與設計管理部,pl-ipmt,pl-tmt (下轄架構委員會

20、,pl-gtd,架構設計部,制定規(guī)劃 技術決策,依據決策和規(guī)劃 例行管理和監(jiān)控,組織或承擔 架構設計任務 負責架構管理與維護,跨產品線領域架構,產品線內領域架構,業(yè)務決策 規(guī)劃審批,itmt/pl-ipmt負責領域架構的規(guī)劃審批、以及同架構相關的業(yè)務決策； c-tmt/pl-tmt負責制定架構規(guī)劃、架構相關的技術決策，該職責也可委托相應的架構委員會來行使； c-gto/pl-gtd負責依據上級決策和規(guī)劃，例行管理和監(jiān)控架構項目； 總體辦架構與設計管理部負責組織跨產品線的領域架構設計、管理及維護工作； 產品線架構設計部負責產品線內的領域架構設計、管理及維護工作,page 27,架構設計部與系統(tǒng)設

21、計團隊的關系,架構設計部負責領域分析和領域架構設計（含新形態(tài)產品的架構設計），產品seg負責產品的系統(tǒng)設計，平臺seg負責平臺的系統(tǒng)設計； 產品線架構設計部在設計業(yè)務上指導和約束產品系統(tǒng)設計團隊和平臺系統(tǒng)設計團隊：一方面，產品系統(tǒng)設計和平臺系統(tǒng)設計要遵從領域架構的設計約束，另一方面，在系統(tǒng)設計活動中，平臺和產品間的技術沖突也需要架構設計部來協(xié)調和仲裁,pl-ipmt/研發(fā)部,pl-tmt,pl-gtd,架構設計部,平臺開發(fā)部,系統(tǒng)部,產品族開發(fā)部,pdt-seg,tdt-seg,系統(tǒng)部,平臺設計,產品設計,架構設計,page 28,dsse流程的階段,需求分析階段 組建項目組； 基于目標領域系

22、統(tǒng)所在上下文網絡語境，建立業(yè)務模型和領域模型； 分析領域包需求，使用用例分析方法和質量屬性場景方法定義系統(tǒng)需求規(guī)格； 參考需求分析的結果，制定（或調整）項目計劃。 邏輯架構設計階段 對目標領域系統(tǒng)內部進行功能分析，分解得到分析模塊，建立分析模型； 參考分析模型，進行邏輯架構設計，以支持領域的質量屬性需求。 實現(xiàn)分析階段 對邏輯架構及其構建塊dm進行實現(xiàn)分析，劃分出領域內公共的核心資產（平臺/cbb), 核心資產的需求規(guī)格，以及他們和產品應用件的界限； 獲得軟件/硬件模塊等實現(xiàn)組件，得到領域內核心資產（平臺/cbb)實現(xiàn)架構。（可選） 物理架構設計階段( 可選階段 ） 規(guī)劃單板和進程，并部署dm

23、/im到單板和進程； 定義單板間物理接口、進程之間的并發(fā)關系,page 29,dsse流程的角色,itmt / pl-ipmt：負責項目的計劃決策（pdcp）、交付決策（tdcp）等業(yè)務決策； tmt：初審架構項目立項charter，發(fā)起架構評估活動并負責技術決策； 項目經理：負責項目開工、項目計劃管理、項目監(jiān)控、組織領域需求評審，及其他項目管理活動； 分析師：負責收集和分析領域需求，業(yè)務建模，構造系統(tǒng)用例，輸出領域系統(tǒng)需求； 架構師：組織完成領域邏輯架構、實現(xiàn)分析；準備架構評估材料，回答架構評估的問題，提出典型產品應用的物理架構建議； 架構師外圍組成員角色： 復用工程師：收集并維護公司及領域

24、范圍的平臺/cbb信息，對本領域im、swm、hwm的復用方案提出建議； 屬性工程師：負責某類質量屬性（dfx）的專項設計活動，如可靠性設計、ucd設計/可服務性設計、性能設計、可制造性設計、成本設計等； 設計工程師：負責某類功能業(yè)務的設計，如操作維護業(yè)務設計、呼叫業(yè)務功能設計等,page 30,領域分析和設計方法,dsse分析與設計活動包括如下6個工作流（workflow）： business modeling: 理解目標系統(tǒng)所處的網絡（或更大系統(tǒng)）的結構、業(yè)務及其動態(tài)特性； domain requirements: 確定領域系統(tǒng)需要考慮的需求，規(guī)范刻畫系統(tǒng)需求規(guī)格； domain anal

25、ysis: 基于問題域視角，探索系統(tǒng)內部，建立領域的分析模型； logical architecture design: 基于解域(計算機域)視角，構建設計模型，獲得領域架構； implementation analysis: 選擇實現(xiàn)技術，構建實現(xiàn)模型，確定領域平臺/cbb與產品的邊界 physical architecture design: 構建部署模型，獲得平臺及產品的物理架構,business modeling,domain requirements,logical architecture design,domain analysis,implementation analysis,physical architecture design,phase1: requirement analysis,phase2: logical architecture design,phase3: implementation analysis,phase4: physical architecture design,page 31,架構評估的目、特點及評估時機,