《IPD技术开发流程ppt课件.ppt》由会员分享，可在线阅读，更多相关《IPD技术开发流程ppt课件.ppt（34页珍藏版）》请在三一办公上搜索。
1、Page 1,Content,概述技术规划流程（TPP）技术/平台开发流程（TPD）领域架构（DSSE）CBB管理,Page 2,什么是CBB,CBB ( Common Building Block 共用基础模块）基础模块(BB)是系统中一组实现特定功能，具备接口要素、性能及规格的实体单元，而CBB指可共用的基础模块即可两个或两个以上的产品系统中直接应用的基础模块。CBB可分为：自制件CBB、外购件CBB,CBB具备以下特征共用性、可集成界面清晰；功能、性能指标明确；可维护、可测试；有完善的资料手册,CBB的来源基于架构开发的CBB基于已开发系统后向整理CBB：遵循技术趋势与技术归纳/规划出的
2、共用模块外购的CBB,Page 3,高价值BB和高价值CBB,高价值BB/CBB：为公司带来较高价值或可能产生重大影响的BB/CBB .,高价值BB必须满足下列条件之一：占公司或产品线硬件发货额80的产品所应用的BB ；占公司或产品线软件发货代码总量80的产品所应用的BB；对公司或产品线产品发展影响较大/有战略意义的BB；价值下跌很快且采购成本很高的外购件，如CPU、主板；对产品制约很大、有较大采购风险的外购件；供应商独家供货的外购件；对采购成本影响较大的外购件；对总体方案有较大影响的关键器件；,Page 4,什么是平台？,平台是特定架构及基于此架构的一组技术构件的有机集合。平台为产品提供通用
3、基础能力，产品以平台为基础加上客户化特性能快速形成不同产品系列。,平台的特征:基于特定架构共享性、通用性具有较高的战略价值高度可集成性、可快速实施具备二次开发能力、极易扩充与产品之间的界面清晰，可实现上层应用的技术无关性,Page 5,技术体系流程及周边流程关系,Sourcing Plan流程,CBB管理流程,TPD流程,概念,计划,开发,迁移,需求管理流程,IPD流程,概念,计划,开发,验证,发布,LC,执行,启动,分析,融合和优化,TPP流程,技术CDP,预研流程,架构开发流程,MM-SP,MM-ABP/CDP,MM流程,Page 6,技术管理体系相关团队,IRB,ITMT,PL-IPMT
4、,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 OfficeGTD:General Technology Department TMG: Technology Management Group,Page 7,技术规
5、划流程 TPP,Page 8,技术规划流程与MM流程的衔接,启动,分析,融合和优化,执行,技术规划流程（TPP）,公司战略和业务方向技术趋势竞争对手信息 上期路标及执行情况业务计划,产品路标,技术趋势分析报告,产品线目标、市场技术信息,技术路标,技术/平台开发应领先产品开发6个月,MM-SP产业与投资方向,MM-BP里程碑落实/年度目标策略及预算,MM-Charter初始产品包商业计划制定,市场管理流程（MM）,交叉评审,Page 9,技术规划流程（TPP）框架,执行阶段,启动阶段,分析阶段,融合优化阶段,输出,输入,主要活动,Page 10,技术规划团队角色定义,Page 11,技术/平台项
6、目Charter开发流程,产品线技术规划PDC结果客户需求(OR)技术发展趋势分析报告,技术/平台CDP,技术平台项目任务书材料包技术平台项目任务书,适用范围： 所有技术/平台开发项目，包括：架构、平台、子系统、CBB、技术开发,技术/平台Charter开发小组,组 长,规划师,TDT代表,用户TDT/PDT代表,RME,Charter开发小组,责任主体仍然是TMT,输入/输出:,Page 12,业务分层模型,MM/IPD,市场机会面向客户数据收集业务规划投资决策,各层次通过MM流程（根据不同层次特点进行裁剪）面向外部市场，通过OR流程收集信息数据，通过IPD进行开发。,支撑产品发展影响IPM
7、T决策架构开发CBB技术规划,技术体系负责内部层次，根据TPP进行技术规划，根据TPD开发架构、平台、CBB及技术。,外部层次,内部层次,集成服务层,外部市场,解决方案层,技术层,产品层,子系统层,平台层,TPP/TPD,业务分层就是按照业务类别和价值链划分的层次分类，依据销售状况和应用范围进一步划分为外部业务分层和内部业务分层。,Page 13,异步开发（Asynchronous Development）框架,异步层的相互配合关系应该在早期的业务规划和路标定义时就得到明确。 PMT和TMT在产品规划和技术规划活动中形成互动，明确定义技术和平台的每个R版本所支持的产品的R版本、其主要特性和需求
8、、以及R版本TDCP时间,PDT,product,平台参考架构,系统参考模型,技术管理体系,技术路标,版本火车,核心能力中心,CBB,业务分层,依赖关系管理,技术战略,业务战略,IBT,Page 14,技术/平台开发流程 TPD,Page 15,平台与产品有何不同？,Page 16,平台与产品的差异决定了开发流程的不同,基于平台和产品的差异，开发流程除需在技术和质量标准等方面有较高要求外，还要考虑了以下方面的差异：市场：平台重点关注战略支撑，不直接对外销售，不涉及定价、预测、订单履行等，Marketing代表的职责重在需求控制和平台内部推广；财务：财务核算重点关注成本核算和目标成本的达成，不关
9、注收入和利润 ；技术支持：平台的客户是用户PDT，技术支持方式有别于产品，主要职责是支持用户PDT进行二次开发，其技能要求和服务模式与产品的要求有较大差异；研发：平台是产品的一个部件，需在产品中集成验证后才能达到量产要求，流程中需有一个迁移阶段来保证平台顺利迁移到产品，并有效支持产品验证和转产；制造：平台需要集成到产品才能完成最后的转产过程，因此平台开发流程不需要独立定义相应的量产活动；,TPD流程体现了平台的差异性，是客户化的IPD流程,Page 17,TPD流程在各个阶段充分考虑了平台的特点,完成初始技术/平台的开发关注于平台的迁移准备和发布平台最终规格和相关文档,完成初始产品的开发开发集
10、成配置器，开始营销宣传，向定价、预测提供支持，逐步上量准备,关注于从PDCP到TDCP项目计划关注平台向产品迁移及如何向用户PDT提供技术支持的迁移计划,关注于PDCP到GA的项目计划关注盈利计划、订单履行计划、转产及生命周期管理计划,产品包需求关注为所支撑的多个产品系列提供核心能力的通用需求侧重于评估平台的技术竞争力及目标成本的可达性,产品包需求关注于来自特定客户群的，可提供差异化竞争能力的市场需求侧重于评估市场竞争及盈利能力,将平台迁移给用户PDT，根据迁移计划支持各个用户PDT TR4到GA的所有活动，保证平台有效集成到产品中。,验证产品（Beta/SVT/标竿等），开展ESP，发布最终
11、产品规格及相关文档.,发布产品，制造足够数量的满足客户需求的产品,迁移阶段,重点关注对产品战略的支持,重点关注对业务计划的支持,开发阶段,计划阶段,概念阶段,验证阶段,发布阶段,Charter,IPD流程,TPD流程,监控生产、营销和销售、客户服务和支持等方面的绩效，直到EOX,生命周期,Page 18,平台和技术的迁移,迁移到PDT1,迁移到PDT n,责任主体仍然在TDT，活动主要通过迁移计划来指导,由以FAE为主维护团队提供后期技术支持服务工作,迁移计划完成，TDT合同关闭，此时迁移计划中所标识的用户PDT已经全部通过ADCP，技术/平台合同评估活动启动,TDCP为迁移阶段的起始点，而不
12、是终止点，TDCP主要评估技术/平台向用户产品迁移准备度是否达到要求,迁移阶段的终止点为技术/平台生命周期结束点，也就是所有使用此技术/平台的用户产品生命周期结束,Page 19,迁移策略与计划,迁移计划是迁移阶段TDT活动的核心指导，是迁移阶段TDT的项目计划。它明确了TDT需要支持那些用户PDT，对于每个用户PDT需要支持哪些活动，需要哪些资源等。迁移计划由TDT经理组织开发，发布前需要各用户PDT充分沟通并得到其认可，最终经ITMT/PL_IPMT的批准生效；概念阶段主要集中在迁移策略的制定，计划阶段完成详细计划，TDCP前根据开发阶段活动状态进一步优化；迁移计划的执行期限为从TDCP开
13、始到合同结束点终止。在迁移计划执行期间，TDT仍作为一个独立的责任主体存在，是技术支持的责任人，负责管理和维护迁移计划的执行状态。迁移计划完成后，技术支持服务工作转由以FAE为主的维护组负责。,Page 20,中小技术项目操作指导,需求明确、低风险项目，TR1与TR2可合并，CDCP与PDCP可合并；设计规格明确，TR1、TR2可与TR3合并，CDCP可合并到PDCP,基于原有架构的增量开发，AR可合并到TR2中,注：TR的合并或裁减由SE提出，PQA确认后写入质量计划，同时需在相应DCP业务计划中明确,纯软件的项目，TR4A可合并到TR5中操作,对于小项目，Charter一般合并到PDCP中
14、。,Page 21,DSSE流程和方法,Page 22,背景知识：架构定义及内涵,SEI给出的架构定义：架构是指一个系统的一个或多个结构(视图)，它包括组成系统的元素，元素的外部可见属性以及元素之间的相互关系；IEEE给出的架构定义：架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构，以及指导系统设计与演化的原理；谈论架构时，首先要界定“系统”，在界定了系统后，再考虑刻画系统的元素（组件）有那些，另外架构是对设计的约束，其约束的作用域也需要明确；组成系统的元素（组件是一类元素）、元素的外部属性及元素之相的关系是系统架构的三个要素，因此，在进行架构设计时不要把精力放
15、到不属于架构范畴的元素内部细节上面；SEI 的定义强调了架构的多结构（多视图），IEEE的定义中强调了架构包含的“设计原理”，二者不是矛盾的，而是互补的，架构的交付除多个视图外，还包括设计规范(原理)；SEI 的定义明确指出一个系统包含了多个结构（视图），其中任何一个结构都不能和系统的架构划等号（如下图，一个系统包含三个视图），每一视图对应于系统不同的侧面；每个系统都有自己的架构。架构独立于架构的描述而存在。 经常所说的一个系统“没架构”，往往是指这个系统架构不好，质量太差，或者说没有将架构进行编档，显现出来。,系统,部署视图,动态视图,静态视图,模块,进程,单板,Page 23,背景知识：领
16、域及领域架构,期望大家关注领域的架构，即领域架构，其对应的“系统”和“元素”是：系统：具有相近需求的一组产品应用构成的领域(Domain)；元素：不仅仅是分析元素，更重要的是设计元素。为何要关注领域架构? 为了产品应用间的重用，即实现基于领域架构的重用！领域架构特征：面向一个严格定义的问题域，是对整个领域的合适程度的抽象；具有普遍性，使其可以用于指导和约束领域中某个特定应用的开发；具备有该领域稳定的在开发过程中可重用元素。领域及领域架构举例：基站领域架构：VISA-RB基站控制器领域架构: VISA-RC,GSM-BTS,CDMA-BTS,WCDMA-NodeB,基站领域,GBSC,CBSC,
17、WRNC,基站控制器领域,Page 24,背景知识：双生命周期模型,应用领域和产品应用都是我们的开发对象，可以此来分层地组织和实施全流程开发活动。以领域为开发对象的活动称之为领域工程，以单个产品应用为开发对象的活动称之为应用工程。领域工程和应用工程相对独立，又相互关联，领域工程各阶段的输出都能作为应用工程的输入，从而被一组产品应用而重用；应用工程在领域工程结果的基础上构造新产品，领域工程也要从应用工程中获得反馈或结合新产品的需求进入新一轮发展周期，即产品线演化；基于领域视野开展分析、设计和实现工作，可主动实现领域内最大重用。,领域分析,领域设计,领域实现,领域模型,领域架构,平台/CBB,需求
18、分析,系统设计,系统实现,领域工程,应用工程,产品需求,产品,核心资源 （平台/ CBB）,Development for reuse,Development with reuse,领域需求,Time,Developed Object,公共开发,产品化开发,Page 25,什么是DSSE ？,DSSE：Domain-Specific System Engineering，是一套领域系统分析和设计的流程和方法；DSSE的理论基础来自于软件工程业界的“产品线”工程，方法上借鉴了UP（Unified Process）方法以及瑞研所为无线某基站平台开发所提供的设计方法，模型表述上遵从UML规范；DSS
19、E适用范围嵌入式应用领域，也适用于网管软件和服务器软件产品应用领域;DSSE的设计思想可被借鉴到产品的系统设计活动中。DSSE的特点面向特定领域的复用技术用例驱动的开发以架构为中心支持以迭代方式开发系统使用UML建立可视化的模型交付版本DSSE V1.1（DSSE V1.0版本2005年年中在总体技术体系内部已发布试用）,Page 26,架构管理体系概述,ITMT,C-TMT,C-GTO,架构与设计管理部,PL-IPMT,PL-TMT(下辖架构委员会),PL-GTD,架构设计部,制定规划技术决策,依据决策和规划例行管理和监控,组织或承担架构设计任务负责架构管理与维护,跨产品线领域架构,产品线内
20、领域架构,业务决策规划审批,ITMT/PL-IPMT负责领域架构的规划审批、以及同架构相关的业务决策；C-TMT/PL-TMT负责制定架构规划、架构相关的技术决策，该职责也可委托相应的架构委员会来行使；C-GTO/PL-GTD负责依据上级决策和规划，例行管理和监控架构项目；总体办架构与设计管理部负责组织跨产品线的领域架构设计、管理及维护工作；产品线架构设计部负责产品线内的领域架构设计、管理及维护工作。,Page 27,架构设计部与系统设计团队的关系,架构设计部负责领域分析和领域架构设计（含新形态产品的架构设计），产品SEG负责产品的系统设计，平台SEG负责平台的系统设计；产品线架构设计部在设计
21、业务上指导和约束产品系统设计团队和平台系统设计团队：一方面，产品系统设计和平台系统设计要遵从领域架构的设计约束，另一方面，在系统设计活动中，平台和产品间的技术冲突也需要架构设计部来协调和仲裁。,PL-IPMT/研发部,PL-TMT,PL-GTD,架构设计部,平台开发部,系统部,产品族开发部,PDT-SEG,TDT-SEG,系统部,平台设计,产品设计,架构设计,Page 28,DSSE流程的阶段,需求分析阶段组建项目组；基于目标领域系统所在上下文网络语境，建立业务模型和领域模型；分析领域包需求，使用用例分析方法和质量属性场景方法定义系统需求规格；参考需求分析的结果，制定（或调整）项目计划。逻辑架
22、构设计阶段对目标领域系统内部进行功能分析，分解得到分析模块，建立分析模型；参考分析模型，进行逻辑架构设计，以支持领域的质量属性需求。实现分析阶段对逻辑架构及其构建块DM进行实现分析，划分出领域内公共的核心资产（平台/CBB), 核心资产的需求规格，以及他们和产品应用件的界限；获得软件/硬件模块等实现组件，得到领域内核心资产（平台/CBB)实现架构。（可选）物理架构设计阶段( 可选阶段 ）规划单板和进程，并部署DM/IM到单板和进程；定义单板间物理接口、进程之间的并发关系。,Page 29,DSSE流程的角色,ITMT / PL-IPMT：负责项目的计划决策（PDCP）、交付决策（TDCP）等业
23、务决策；TMT：初审架构项目立项charter，发起架构评估活动并负责技术决策；项目经理：负责项目开工、项目计划管理、项目监控、组织领域需求评审，及其他项目管理活动；分析师：负责收集和分析领域需求，业务建模，构造系统用例，输出领域系统需求；架构师：组织完成领域逻辑架构、实现分析；准备架构评估材料，回答架构评估的问题，提出典型产品应用的物理架构建议；架构师外围组成员角色： 复用工程师：收集并维护公司及领域范围的平台/CBB信息，对本领域IM、SWM、HWM的复用方案提出建议；属性工程师：负责某类质量属性（DFx）的专项设计活动，如可靠性设计、UCD设计/可服务性设计、性能设计、可制造性设计、成本
24、设计等；设计工程师：负责某类功能业务的设计，如操作维护业务设计、呼叫业务功能设计等。,Page 30,领域分析和设计方法,DSSE分析与设计活动包括如下6个工作流（Workflow）：Business Modeling: 理解目标系统所处的网络（或更大系统）的结构、业务及其动态特性；Domain Requirements: 确定领域系统需要考虑的需求，规范刻画系统需求规格；Domain Analysis: 基于问题域视角，探索系统内部，建立领域的分析模型；Logical Architecture Design: 基于解域(计算机域)视角，构建设计模型，获得领域架构；Implementation
25、 Analysis: 选择实现技术，构建实现模型，确定领域平台/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: I
26、mplementation Analysis,Phase4: Physical Architecture Design,Page 31,架构评估的目、特点及评估时机,架构评估的目的评价架构是否能够实现业务需求和质量属性需求；评价架构的适宜性和竞争力；发现架构的风险和改进点。架构评估方法的特点ATAM(架构权衡分析方法)是业界最常用的架构评估方法，我们在ATAM评估方法的基础上，结合我司实际情况，强调架构竞争性分析，形成了一套架构评估方法；强调场景化、具体化的质量属性需求；明确架构方案，分析架构方案对质量属性的实现；强调获取利益相关人的观点，强调对架构决策进行验证。架构评估的时机对于新设计的架构
27、，根据DSSE流程定义，在完成架构设计后，应该进行架构评估；对已经存在的历史架构，可以在任何时间进行架构评估。推荐在以下时机进行架构评估：出现新领域时对现有架构的适应性进行评估；新需求引起架构变化或演进，在制定架构修改方案前对现有架构进行评估；制定架构修改方案后对新架构方案进行评估。架构评估中采用的分析方法，也可以在架构设计阶段使用，用于小范围的评估或问题分析。,Page 32,CBB管理,Page 33,共用基础模块,CBB,CBB是提升产品开发效率的加速器,TR1,TR2,PDCP,TR4,SE-05RDPDT-30明确每个备选概念/技术所使用的共用硬件和软件,CDCP,TR3,IPMT-
28、20,IPMT-40,评估产品使用CBB的达成情况,EE-30SWE-30ME-30项目级重用技术分析,IPMT在DCP中评审产品开发过程中应用CBB达成情况,规划,开发,使用,维护,监控,在技术规划中给出CBB规划和预算,使用TPD流程开发CBB,在TPD（技术）和IPD（产品）中使用CBB,总体技术部负责维护,总体技术部负责监控,IPMT保证CBB按计划进行开发,IPMT在评审技术规划时评审并批准CBB预算,高复用价值和复用机会多的CBB是我们建设CBB关注的重点！关键器件路标规划由归一化行业管理组(如电源、处理器)制定。,2008年目标：产品化开发比例为45（即平台/CBB复用到55%）；设计与实现分离,Thank You,
