IPD_-技术开发流程-TPP TPD CBB.ppt

* * * * * * * * * * * * * * * * * * * 平台和技术的迁移 迁移结束点， 也是生命周期 结束点 迁移到PDT1 迁移到PDT n 合同结束点 合同有效期 迁移阶段前期 迁移阶段后期 TR4 TR6 PDT 1 R0xxx CDCP TR5 TR4A PDCP ADCP GA Charter PDT n R0xxx CDCP TR5 TR6 TR4 PDCP ADCP GA Charter TR4A 技术/平台 R0xxx CDCP PDCP TDCP Charter 责任主体仍然在TDT，活动主要通过迁移计划来指导 由以FAE为主维护团队提供后期技术支持服务工作 迁移计划完成，TDT合同关闭，此时迁移计划中所标识的用户PDT已经全部通过ADCP，技术/平台合同评估活动启动 TDCP为迁移阶段的起始点，而不是终止点，TDCP主要评估技术/平台向用户产品迁移准备度是否达到要求 迁移阶段的终止点为技术/平台生命周期结束点，也就是所有使用此技术/平台的用户产品生命周期结束 迁移策略与计划 迁移计划是迁移阶段TDT活动的核心指导，是迁移阶段TDT的项目计划。它明确了TDT需要支持那些用户PDT，对于每个用户PDT需要支持哪些活动，需要哪些资源等。 迁移计划由TDT经理组织开发，发布前需要各用户PDT充分沟通并得到其认可，最终经ITMT/PL_IPMT的批准生效； 概念阶段主要集中在迁移策略的制定，计划阶段完成详细计划，TDCP前根据开发阶段活动状态进一步优化； 迁移计划的执行期限为从TDCP开始到合同结束点终止。 在迁移计划执行期间，TDT仍作为一个独立的责任主体存在，是技术支持的责任人，负责管理和维护迁移计划的执行状态。迁移计划完成后，技术支持服务工作转由以FAE为主的维护组负责。 中小技术项目操作指导 项目类别 开发工作量 流程关键点 说明 大项目 >100人月 Charter、TR1、CDCP、 AR、TR2、TR3、PDCP TR4、TR4A、TR5、TDCP 大项目按照TPD流程进行，DCP、TR不允许裁剪，其它非关键活动可以根据项目实际情况进行裁剪。 中项目 30人月－100人月 Charter TR3（TR1/ AR /TR2） PDCP（CDCP） TR4 TR5(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中。 DSSE流程和方法 背景知识：架构定义及内涵 SEI给出的架构定义：架构是指一个系统的一个或多个结构(视图)，它包括组成系统的元素，元素的外部可见属性以及元素之间的相互关系； IEEE给出的架构定义：架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构，以及指导系统设计与演化的原理； 谈论架构时，首先要界定“系统”，在界定了系统后，再考虑刻画系统的元素（组件）有那些，另外架构是对设计的约束，其约束的作用域也需要明确； 组成系统的元素（组件是一类元素）、元素的外部属性及元素之相的关系是系统架构的三个要素，因此，在进行架构设计时不要把精力放到不属于架构范畴的元素内部细节上面； SEI 的定义强调了架构的多结构（多视图），IEEE的定义中强调了架构包含的“设计原理”，二者不是矛盾的，而是互补的，架构的交付除多个视图外，还包括设计规范(原理)； SEI 的定义明确指出一个系统包含了多个结构（视图），其中任何一个结构都不能和系统的架构划等号（如下图，一个系统包含三个视图），每一视图对应于系统不同的侧面； 每个系统都有自己的架构。架构独立于架构的描述而存在。 经常所说的一个系统“没架构”，往往是指这个系统架构不好，质量太差，或者说没有将架构进行编档，显现出来。 系统 部署视图 动态视图 静态视图 模块 进程 单板 背景知识：领域及领域架构 期望大家关注领域的架构，即领域架构，其对应的“系统”和“元素”是： 系统：具有相近需求的一组产品应用构成的领域(Domain)； 元素：不仅仅是分析元素，更重要的是设计元素。 为何要关注领域架构?