Page 1Content概述概述技术规划流程（技术规划流程（TPP）技术技术/平台开发流程（平台开发流程（TPD）领域架构（领域架构（DSSE）CBB管理管理Page 2什么是什么是CBBCBBCBB ( Common Building Block 共用基础模块）基础模块(BB)是系统中一组实现特定功能，具备接口要素、性能及规格的实体单元，而CBB指可共用的基础模块即可两个或两个以上的产品系统中直接应用的基础模块。CBB可分为：自制件CBB、外购件CBBCBBCBB具备以下特征具备以下特征共用性、可集成界面清晰；功能、性能指标明确；可维护、可测试；有完善的资料手册 CBBCBB的来源的来源基于架构开发的CBB基于已开发系统后向整理CBB：遵循技术趋势与技术归纳/规划出的共用模块外购的CBB可共享与重用的部件可共享与重用的部件可共享与重用的部件可共享与重用的部件不同的产品不同的产品不同的产品不同的产品服务器工作站PC便携硬盘、内存、CPU、软驱、标准接口、底层软件、协议、键盘、鼠标Page 3高价值高价值BBBB和高价值和高价值CBBCBB高价值高价值BB/CBBBB/CBB：为公司带来较高价值或可能产生重大影响的BB/CBB .高价值高价值BBBB必须满足下列条件之一：必须满足下列条件之一：占公司或产品线硬件发货额80的产品所应用的BB ；占公司或产品线软件发货代码总量80的产品所应用的BB；对公司或产品线产品发展影响较大/有战略意义的BB；价值下跌很快且采购成本很高的外购件，如CPU、主板；对产品制约很大、有较大采购风险的外购件；供应商独家供货的外购件；对采购成本影响较大的外购件；对总体方案有较大影响的关键器件；Page 4什么是平台？什么是平台？平台平台是特定架构及基于此架构的一组技术构件的有机集合。平台为产品提供通用基础能力，产品以平台为基础加上客户化特性能快速形成不同产品系列。ATCA, Mini ComputerHardwareLinux, UnixMiddlewareApp lApp2App nApp3OSMiddlewareApplications (product specific)APIAPIAPIPlatform 平台的特征:基于特定架构共享性、通用性具有较高的战略价值高度可集成性、可快速实施具备二次开发能力、极易扩充与产品之间的界面清晰，可实现上层应用的技术无关性Page 5技术体系流程及周边流程关系技术体系流程及周边流程关系CBBCBB管理流程管理流程CBB库平台子系统技术TPDTPD流程流程概念计划开发迁移 需求管理流程需求管理流程华为商业战略华为历史数据客户需求技术趋势IPDIPD流程流程概念计划开发验证发布LC执行启动分析融合和优化TPPTPP流程流程技术技术CDPCDP预研流程预研流程架构开发流程架构开发流程MM-SPMM-SPMM-MM-ABP/CDPABP/CDPMMMM流程流程Page 6技术管理体系相关团队技术管理体系相关团队IRBITMTPL-IPMTC-PMTPL-PMTPL-TMTC-TMTC-TMG/TDTPL-TMG/TDTPF-BMT/PDTC-GTOPL-GTDITMT: 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技术规划流程技术规划流程 TPPPage 8技术规划流程与技术规划流程与MM流程的衔接流程的衔接启动启动分析分析融合和优化融合和优化执行执行技术规划流程（技术规划流程（TPPTPP）公司战略和业务方向公司战略和业务方向技术趋势技术趋势竞争对手信息竞争对手信息 上期路标及执行情况上期路标及执行情况业务计划业务计划产品路标产品路标技术趋势技术趋势分析报告分析报告产品线目产品线目标、市场标、市场技术信息技术信息技术路标技术路标技术技术/ /平台开平台开发应领先产发应领先产品开发品开发6 6个月个月MM-SPMM-SP产业与投资方向产业与投资方向MM-BPMM-BP里程碑落实里程碑落实/ /年度目标策略年度目标策略及预算及预算MM-CharterMM-Charter初始产品包商业计划制定初始产品包商业计划制定理解市场理解市场 进行组进行组合分析合分析管理业管理业务计划务计划并评估并评估绩效绩效融合和融合和优化业优化业务计划务计划制定业务制定业务战略与计战略与计划划进行市场进行市场细分细分市场及市场及客户欲客户欲望与需望与需要要市场管理流程（市场管理流程（MMMM）交交叉叉评评审审TPPTPPMMMM规划规划内容内容架构/平台/子系统/技术产品/解决方案规划规划者者TMTPMT输出输出平台/技术战略、平台/技术路标业务战略、产品/解决方案路标Page 9技术规划流程（技术规划流程（TPP）框架）框架执行阶段启动阶段分析阶段融合优化阶段定义平台/技术战略和目标启动技术规划公司战略和业务方向上期技术规划执行情况市场和竞争对手信息客户需求平台/技术战略和目标技术规划日历开工会材料包制定公司技术规划跨产品线融合和优化 产品线/平台部技术规划初稿公司技术规划终稿产品线技术规划终稿制定任务书监控技术项目进展并评估绩效经过审批的公司技术规划经过审批的产品线/平台部技术规划初稿项目任务书纠正措施计划技术趋势分析产品技术发展需求制订内部业务分层及异步开发策略技术路标规划市场和竞争对手信息上期技术规划执行情况客户需求、产品技术需求产品/解决方案路标规划供应商路标规划公共技术能力目标业界技术趋势分析报告产品技术发展需求分析报告技术规划初稿（含各类清单）输出输出输入输入主要主要活动活动Page 10技术规划团队角色定义技术规划团队角色定义规规划划师师组长组长核心组核心组采购代表采购代表制造代表制造代表财务代表财务代表跨领域产品系统部跨领域产品系统部SEMKT代表代表扩展组扩展组技术规划团队（技术规划团队（Technology Planning Team, TPT）成本代表成本代表RME可靠性可靠性专家专家测试测试技术技术专家专家架架构构师师平台平台专家专家专项专项技术技术专家专家QA/PL-TMT执行执行秘书秘书领域内领域内产品产品系统部系统部SE内部内部规范规范专家专家可服可服务性务性专家专家预研预研/标准标准代表代表CBBFocalPoint可制可制造性造性专家专家Page 11技术技术/平台项目平台项目Charter开发流程开发流程产品线技术规划PDC结果客户需求(OR)技术发展趋势分析报告 技术技术/ /平台平台CDPCDP技术平台项目任务书材料包技术平台项目任务书 适用范围：适用范围： 所有技术/平台开发项目，包括：架构、平台、子系统、CBB、技术开发技术技术/ /平台平台CharterCharter开发小组开发小组 组组 长长规规划划师师TDTTDT代代表表用户用户TDT/TDT/PDTPDT代表代表RMERME角色角色职责职责组长按TMT要求的时间启动任务书的开发。制定小组工作计划，监控项目进度。组织小组执行本流程规定的活动，输出项目任务书材料包和项目任务书，并对输出的结果负责。规划师分析技术发展趋势；分析竞争对手状况；分析用户平台/产品需求 TDT代表分析用户平台/产品需求；技术/平台竞争力分析；实现的可行性分析 RME跟踪管理来自客户的对该技术/平台的需求 用户TDT/PDT代表分析用户平台/产品需求 CharterCharter开发小组开发小组责任主体责任主体仍然是仍然是TMTTMT输入输入/ /输出输出: :Page 12业务分层模型业务分层模型MM/IPD市场机会市场机会面向客户面向客户数据收集数据收集业务规划业务规划投资决策投资决策 各层次通过MM流程（根据不同层次特点进行裁剪）面向外部市场，通过OR流程收集信息数据，通过IPD进行开发。支撑产品发展支撑产品发展影响影响IPMTIPMT决策决策架构开发架构开发CBBCBB技术规划技术规划 技术体系负责内部层次，根据TPP进行技术规划，根据TPD开发架构、平台、CBB及技术。外外部部层层次次内内部部层层次次集成服务层集成服务层外部市场外部市场解决方案层解决方案层技术层技术层产品层产品层子系统层子系统层平台层平台层TPP/TPD业务分层就是按照业务类别和价值链划分的层次分类，依据销售状况和应用范围进一步划分为外部业务分层和内部业务分层。Page 13异步开发（异步开发（Asynchronous Development）框架）框架 异步层的相互配合关系应该在早期的业务规划和路标定义时就得到明确。异步层的相互配合关系应该在早期的业务规划和路标定义时就得到明确。 PMT和TMT在产品规划和技术规划活动中形成互动，明确定义技术和平台的每个R版本所支持的产品的R版本、其主要特性和需求、以及R版本TDCP时间TMGTPPTDTTPDTDTCBB/BBTMGTPPTDTTPDTDTCBB/BBCEGTPPOutsourcing TeamSQ&PPOSTCBB/BBTMTTPPTDTTPDTDTplatformPMTMMPDTIPDPDTproductSMTMMSPDTIPDSPDTSolution子系统/技术平台产品解决方案平台参平台参考架构考架构系统系统参考参考模型模型CBB技术管技术管理体系理体系技术技术路标路标版版本本火火车车核心能核心能力中心力中心CBBCBB业务业务分层分层依赖关依赖关系管理系管理技技术术战战略略业业务务战战略略IBTIBTPage 14技术技术/平台开发流程平台开发流程 TPDPage 15平台与产品有何不同？平台与产品有何不同？平台产品开发目的平台的开发重点在于对产品战略的支撑，关注于中长期战略目标的达成产品开发侧重于业务计划的实现，关注于短期业务目标达成预算来源预算主要来自公司的战略预算。从财务角度关注其成本的竞争能力预算主要来自于各产品线的业务规划。从财务角度关注其收入和盈利能力需求来源平台的需求是在综合多个产品需求的基础上，基于架构和技术的要求转换而来产品需求主要直接来自外部客户功能差异平台主要侧重为多个提供通用的核心能力，具有高可靠性，高性能、易扩展产品在平台的基础上快速进行二次开发，重在满足个性化的功能特性交付对象用户PDT外部客户交付形态产品部件，需要进一步集成实现个性化需求的产品部件来形成产品。只用集成到产品并进行充分验证后，才能和产品一起达到量产质量要求最终的产品，通过运行服务终端用户，实现用户价值客户服务支持用户PDT二次开发，保证产品快速推出服务外部客户，保证持续运营和不间断的服务Page 16平台与产品的差异决定了开发流程的不同平台与产品的差异决定了开发流程的不同基于平台和产品的差异，开发流程除需在技术和质量标准等方面有较高要求外，还要考虑了以下方面的差异：市市场：平台重点关注战略支撑，不直接对外销售，不涉及定价、预测、订单履行等，Marketing代表的职责重在需求控制和平台内部推广；财务：财务核算重点关注成本核算和目标成本的达成，不关注收入和利润 ；技技术支持：支持：平台的客户是用户PDT，技术支持方式有别于产品，主要职责是支持用户PDT进行二次开发，其技能要求和服务模式与产品的要求有较大差异；研研发：平台是产品的一个部件，需在产品中集成验证后才能达到量产要求，流程中需有一个迁移阶段来保证平台顺利迁移到产品，并有效支持产品验证和转产；制造：制造：平台需要集成到产品才能完成最后的转产过程，因此平台开发流程不需要独立定义相应的量产活动；Page 17TPDTPD流程在各个阶段充分考虑了平台的特点流程在各个阶段充分考虑了平台的特点1.完成初始技术/平台的开发2.关注于平台的迁移准备和发布平台最终规格和相关文档1.完成初始产品的开发2.开发集成配置器，开始营销宣传，向定价、预测提供支持，逐步上量准备1.关注于从PDCP到TDCP项目计划2.关注平台向产品迁移及如何向用户PDT提供技术支持的迁移计划1.关注于PDCP到GA的项目计划2.关注盈利计划、订单履行计划、转产及生命周期管理计划1.产品包需求关注为所支撑的多个产品系列提供核心能力的通用需求2.侧重于评估平台的技术竞争力及目标成本的可达性1.产品包需求关注于来自特定客户群的，可提供差异化竞争能力的市场需求2.侧重于评估市场竞争及盈利能力将平台迁移给用户PDT，根据迁移计划支持各个用户PDT TR4到GA的所有活动，保证平台有效集成到产品中。验证产品（Beta/SVT/标竿等），开展ESP，发布最终产品规格及相关文档.发布产品，制造足够数量的满足客户需求的产品迁迁移移阶阶段段重点关注对产品战略的支持重点关注对业务计划的支持开发开发阶段阶段计划计划阶段阶段概念概念阶段阶段验证验证阶段阶段发布发布阶段阶段CharterIPD流程TPD流程监控生产、营销和销售、客户服务和支持等方面的绩效，直到EOX生命生命周期周期Page 18平台和技术的迁移平台和技术的迁移迁移结束点，也是生命周期结束点迁移到PDT1迁移到PDT n合同结束点合同有效期迁移阶段前期迁移阶段后期TR4TR6PDT 1 R0xxxCDCPTR5TR4APDCPADCPGACharterPDT n R0xxxCDCPTR5TR6TR4PDCPADCPGACharterTR4A技术/平台R0xxxCDCPPDCPTDCPCharter责任主体仍然在TDT，活动主要通过迁移计划来指导由以FAE为主维护团队提供后期技术支持服务工作迁移计划完成，TDT合同关闭，此时迁移计划中所标识的用户PDT已经全部通过ADCP，技术/平台合同评估活动启动TDCP为迁移阶段的起始点，而不是终止点，TDCP主要评估技术/平台向用户产品迁移准备度是否达到要求迁移阶段的终止点为技术/平台生命周期结束点，也就是所有使用此技术/平台的用户产品生命周期结束Page 19迁移策略与计划迁移策略与计划迁移计划是迁移阶段TDT活动的核心指导，是迁移阶段TDT的项目计划。它明确了TDT需要支持那些用户PDT，对于每个用户PDT需要支持哪些活动，需要哪些资源等。迁移计划由TDT经理组织开发，发布前需要各用户PDT充分沟通并得到其认可，最终经ITMT/PL_IPMT的批准生效；概念阶段主要集中在迁移策略的制定，计划阶段完成详细计划，TDCP前根据开发阶段活动状态进一步优化；迁移计划的执行期限为从TDCP开始到合同结束点终止。在迁移计划执行期间，TDT仍作为一个独立的责任主体存在，是技术支持的责任人，负责管理和维护迁移计划的执行状态。迁移计划完成后，技术支持服务工作转由以FAE为主的维护组负责。Page 20中小技术项目操作指导中小技术项目操作指导项目类别开发工作量流程关键点说明 大项目100人月Charter、TR1、CDCP、AR、TR2、TR3、PDCPTR4、TR4A、TR5、TDCP大项目按照TPD流程进行，DCP、TR不允许裁剪，其它非关键活动可以根据项目实际情况进行裁剪。 中项目30人月100人月CharterTR3（TR1/ AR /TR2）PDCP（CDCP）TR4TR5(TR4A)TDCP此类项目需成立TDT来开发；TR5(TR4A)表示TR4A的关键要素可以合并到TR5中一起操作，也可以单独操作，甚至裁剪，其它类同。 小项目30人月Charter（PDCP） TDCP 此类项目可以不成立TDT来开发，产品线可根据实际情况成立技术开发小组等方式来开发。 需求明确、低风险项目，TR1与TR2可合并，CDCP与PDCP可合并；设计规格明确，TR1、TR2可与TR3合并，CDCP可合并到PDCP基于原有架构的增量开发，AR可合并到TR2中注：TR的合并或裁减由SE提出，PQA确认后写入质量计划，同时需在相应DCP业务计划中明确纯软件的项目，TR4A可合并到TR5中操作对于小项目，Charter一般合并到PDCP中。Page 21DSSE流程和方法流程和方法Page 22背景知识：架构定义及内涵背景知识：架构定义及内涵lSEISEI给出的架构定义给出的架构定义：架构是指一个系统的一个或多个结构(视图)，它包括组成系统的元素元素，元素的外部可见属性元素的外部可见属性以及元素之间的相互关系元素之间的相互关系；lIEEEIEEE给出的架构定义给出的架构定义：架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构，以及指导系统设计与演化的原理指导系统设计与演化的原理；l谈论架构时，首先要界定首先要界定“系统系统”，在界定了系统后，再考虑刻画系统的元素（组件）再考虑刻画系统的元素（组件）有那些，另外架构是对设计的约束，其约束的作用域作用域也需要明确；l组成系统的元素元素（组件是一类元素）、元素的外部属性元素的外部属性及元素之相的关系元素之相的关系是系统架构的三个要素，因此，在进行架构设计时不要把精力放到不属于架构范畴的元素内部细节上面；lSEI 的定义强调了架构的多结构（多视图），IEEE的定义中强调了架构包含的“设计原理”，二者不是矛盾的，而是互补的，架构的交付除多个视图外，还包括设计规范(原理)；lSEI 的定义明确指出一个系统包含了多个结构（视图），个系统包含了多个结构（视图），其中任何一个结构都不能和系统的架构划等号（如下图，一个系统包含三个视图），每一视图对应于系统不同的侧面；l每个系统都有自己的架构每个系统都有自己的架构。架构独立于架构的描述而存在。 经常所说的一个系统“没架构”，往往是指这个系统架构不好，质量太差，或者说没有将架构进行编档，显现出来。系统部署视图动态视图静态视图模块进程单板Page 23背景知识：领域及领域架构背景知识：领域及领域架构l期望大家关注领域的架构，即领域架构，其对应的“系统”和“元素”是：l系统：具有相近需求的一组产品应用构成的领域(Domain)；l元素：不仅仅是分析元素，更重要的是设计元素。l为何要关注领域架构? 为了产品应用间的重用，即实现基于领域架构的重用！为了产品应用间的重用，即实现基于领域架构的重用！l领域架构特征领域架构特征：l面向一个严格定义的问题域，是对整个领域的合适程度的抽象；l具有普遍性，使其可以用于指导和约束领域中某个特定应用的开发；l具备有该领域稳定的在开发过程中可重用元素。l领域及领域架构举例领域及领域架构举例：l基站领域架构：VISA-RBl基站控制器领域架构: VISA-RCGSM-BTSCDMA-BTSWCDMA-NodeB基站领域GBSCCBSCWRNC基站控制器领域Page 24背景知识：双生命周期模型背景知识：双生命周期模型l应用领域应用领域和产品应用产品应用都是我们的开发对象，可以此来分层地组织和实施全流程开发活动。以领域为开发对象的活动称之为领域工程领域工程，以单个产品应用为开发对象的活动称之为应用工程应用工程。l领域工程和应用工程相对独立，又相互关联，领域工程各阶段的输出都能作为应用工程的输入，从而被一组产品应用而重用；应用工程在领域工程结果的基础上构造新产品，领域工程也要从应用工程中获得反馈或结合新产品的需求进入新一轮发展周期，即产品线演化；l基于领域视野开展分析、设计和实现工作，可主动实现领域内最大重用。领域分析领域设计领域实现领域模型领域架构平台/CBB需求分析系统设计系统实现领域工程领域工程应用工程应用工程产品需求产品核心资源 （平台/ CBB）Development for reuseDevelopment with reuse领域需求TimeDeveloped Object公共开发产品化开发Page 25什么是什么是DSSE ？lDSSE：Domain-Specific System Engineering，是一套领域系统分析和设计的流程和方法；DSSE的理论基础来自于软件工程业界的“产品线”工程，方法上借鉴了UP（Unified Process）方法以及瑞研所为无线某基站平台开发所提供的设计方法，模型表述上遵从UML规范；lDSSE适用范围适用范围l嵌入式应用领域，也适用于网管软件和服务器软件产品应用领域;lDSSE的设计思想可被借鉴到产品的系统设计活动中。lDSSE的特点的特点l面向特定领域的复用技术l用例驱动的开发l以架构为中心l支持以迭代方式开发系统l使用UML建立可视化的模型l交付版本交付版本lDSSE V1.1（DSSE V1.0版本2005年年中在总体技术体系内部已发布试用）Page 26架构管理体系概述架构管理体系概述ITMTC-TMTC-GTO架构与设计管理部PL-IPMTPL-TMT(下辖架构委员会)PL-GTD架构设计部制定规划技术决策依据决策和规划例行管理和监控组织或承担架构设计任务负责架构管理与维护跨产品线领域架构产品线内领域架构业务决策规划审批lITMT/PL-IPMT负责领域架构的规划审批、以及同架构相关的业务决策；lC-TMT/PL-TMT负责制定架构规划、架构相关的技术决策，该职责也可委托相应的架构委员会来行使；lC-GTO/PL-GTD负责依据上级决策和规划，例行管理和监控架构项目；l总体办架构与设计管理部负责组织跨产品线的领域架构设计、管理及维护工作；l产品线架构设计部负责产品线内的领域架构设计、管理及维护工作。Page 27架构设计部与系统设计团队的关系架构设计部与系统设计团队的关系l架构设计部负责领域分析和领域架构设计（含新形态产品的架构设计），产品SEG负责产品的系统设计，平台SEG负责平台的系统设计；l产品线架构设计部在设计业务上在设计业务上指导和约束产品系统设计团队和平台系统设计团队：一方面，产品系统设计和平台系统设计要遵从领域架构的设计约束，另一方面，在系统设计活动中，平台和产品间的技术冲突也需要架构设计部来协调和仲裁。PL-IPMT/研发部PL-TMTPL-GTD架构设计部平台开发部系统部产品族开发部PDT-SEGTDT-SEG系统部平台设计平台设计产品设计产品设计架构设计架构设计Page 28DSSE流程的阶段流程的阶段需求分析阶段需求分析阶段l组建项目组；l基于目标领域系统所在上下文网络语境，建立业务模型和领域模型；l分析领域包需求，使用用例分析方法和质量属性场景方法定义系统需求规格；l参考需求分析的结果，制定（或调整）项目计划。逻辑架构设计阶段逻辑架构设计阶段l对目标领域系统内部进行功能分析，分解得到分析模块，建立分析模型；l参考分析模型，进行逻辑架构设计，以支持领域的质量属性需求。实现分析阶段实现分析阶段l对逻辑架构及其构建块DM进行实现分析，划分出领域内公共的核心资产（平台/CBB), 核心资产的需求规格，以及他们和产品应用件的界限；l获得软件/硬件模块等实现组件，得到领域内核心资产（平台/CBB)实现架构。（可可选）物理架构设计阶段物理架构设计阶段( ( 可选阶段可选阶段 ）l规划单板和进程，并部署DM/IM到单板和进程；l定义单板间物理接口、进程之间的并发关系。Page 29DSSE流程的角色流程的角色lITMT / PL-IPMTITMT / PL-IPMT：负责项目的计划决策（PDCP）、交付决策（TDCP）等业务决策；lTMTTMT：初审架构项目立项charter，发起架构评估活动并负责技术决策；l项目经理：项目经理：负责项目开工、项目计划管理、项目监控、组织领域需求评审，及其他项目管理活动；l分析师：分析师：负责收集和分析领域需求，业务建模，构造系统用例，输出领域系统需求；l架构师：架构师：组织完成领域逻辑架构、实现分析；准备架构评估材料，回答架构评估的问题，提出典型产品应用的物理架构建议；l架构师外围组成员角色：架构师外围组成员角色： l复用工程复用工程师：收集并维护公司及领域范围的平台/CBB信息，对本领域IM、SWM、HWM的复用方案提出建议；l属性工程属性工程师：负责某类质量属性（DFx）的专项设计活动，如可靠性设计、UCD设计/可服务性设计、性能设计、可制造性设计、成本设计等；l设计工程工程师：负责某类功能业务的设计，如操作维护业务设计、呼叫业务功能设计等。 Page 30领域分析和设计方法领域分析和设计方法lDSSE分析与设计活动包括如下6个工作流（Workflow）：lBusiness Modeling: 理解目标系统所处的网络（或更大系统）的结构、业务及其动态特性；lDomain Requirements: 确定领域系统需要考虑的需求，规范刻画系统需求规格；lDomain Analysis: 基于问题域视角，探索系统内部，建立领域的分析模型；lLogical Architecture Design: 基于解域(计算机域)视角，构建设计模型，获得领域架构；lImplementation Analysis: 选择实现技术，构建实现模型，确定领域平台/CBB与产品的边界lPhysical Architecture Design: 构建部署模型，获得平台及产品的物理架构Business ModelingDomain RequirementsLogical Architecture DesignDomain AnalysisImplementation AnalysisPhysical Architecture DesignPhase1: Requirement AnalysisPhase2: Logical Architecture Design Phase3: Implementation AnalysisPhase4: Physical Architecture DesignPage 31架构评估的目、特点及评估时机架构评估的目、特点及评估时机l架构评估的目的架构评估的目的l评价架构是否能够实现业务需求和质量属性需求；l评价架构的适宜性和竞争力；l发现架构的风险和改进点。l架构评估方法的特点架构评估方法的特点lATAM(架构权衡分析方法)是业界最常用的架构评估方法，我们在ATAM评估方法的基础上，结合我司实际情况，强调架构竞争性分析，形成了一套架构评估方法；l强调场景化、具体化的质量属性需求；l明确架构方案，分析架构方案对质量属性的实现；l强调获取利益相关人的观点，强调对架构决策进行验证。l架构评估的时机架构评估的时机l对于新设计的架构，根据DSSE流程定义，在完成架构设计后，应该进行架构评估；l对已经存在的历史架构，可以在任何时间进行架构评估。推荐在以下时机进行架构评估：l出现新领域时对现有架构的适应性进行评估；l新需求引起架构变化或演进，在制定架构修改方案前对现有架构进行评估；l制定架构修改方案后对新架构方案进行评估。l架构评估中采用的分析方法，也可以在架构设计阶段使用，用于小范围的评估或问题分析。Page 32CBB管理管理Page 33共用基础模块共用基础模块CBBCBBCBBCBB是提升产品开发效率的加速器是提升产品开发效率的加速器TR1TR2PDCPTR4SE-05RDPDT-30明确每个备选概念/技术所使用的共用硬件和软件CDCPTR3IPMT-20IPMT-40评估产品使用CBB的达成情况EE-30SWE-30ME-30项目级重用技术分析IPMTIPMT在在DCPDCP中评审产品开发过程中应用中评审产品开发过程中应用CBBCBB达成情况达成情况在技术规划中给出CBB规划和预算使用TPD流程开发CBB在TPD（技术）和IPD（产品）中使用CBB总体技术部负责维护总体技术部负责监控IPMTIPMT保证保证CBBCBB按计划进行开发按计划进行开发IPMTIPMT在评审技术规划时评审并批准在评审技术规划时评审并批准CBBCBB预算预算高复用价值和复用机会多的CBB是我们建设CBB关注的重点！关键器件路标规划由归一化行业管理组(如电源、处理器)制定。20082008年目标：年目标：产品化开发比例为产品化开发比例为45（即平台（即平台/CBB复用到复用到55%）；设计与实现分离）；设计与实现分离www.huawei.comThank You www.huawei.com