基于COMAC需求工程最佳实践的DOORS方案.ppt

上传人(卖家):三亚风情 文档编号:3138809 上传时间:2022-07-20 格式:PPT 页数:42 大小:2.94MB
下载 相关 举报
基于COMAC需求工程最佳实践的DOORS方案.ppt_第1页
第1页 / 共42页
基于COMAC需求工程最佳实践的DOORS方案.ppt_第2页
第2页 / 共42页
基于COMAC需求工程最佳实践的DOORS方案.ppt_第3页
第3页 / 共42页
基于COMAC需求工程最佳实践的DOORS方案.ppt_第4页
第4页 / 共42页
基于COMAC需求工程最佳实践的DOORS方案.ppt_第5页
第5页 / 共42页
点击查看更多>>
资源描述

1、IBM Rational系统工程解决方案商飞案例分析 内容安排内容安排 客户背景、现状和面临挑战客户背景、现状和面临挑战 IBM Rational 提供的解决方案提供的解决方案 解决方案实施过程概述解决方案实施过程概述 解决方案实施效果解决方案实施效果 后续合作计划和总结后续合作计划和总结2COMAC简介 中国商飞公司是实施国家大型飞机重大专项中大型客机项目的主体,也是统筹干线飞机和支线飞机发展、实现我国民用飞机产业化的主要载体,主要从事民用飞机及相关产品的科研、生产、试验试飞,从事民用飞机销售及服务、租赁和运营等相关业务。产品包括C919和ARJ系列商用飞机。3上飞设计院飞控航电液压电气动力

2、环控适航IT通信导航指示记录总体系统COMAC 现状和工作模式 国际通行的集成-分包模式 C919项目核心系统 航电、飞控、动力、液压等选定了供应商,签署了供货协议 C919项目已经通过JDP(联合设计阶段)4Customer Reqts DefinitionPreliminary DesignSystemIntegrationSystemReqtsDefinitionDetailed DesignSystemValidationSupport/MaintainceSystemProductionCustomer Requirement Review(CRR)System Requiremen

3、t Review(SRR)Preliminary Design Review(PDR)Critical Design Review(CDR)Test Readiness Review(TRR)Production Readiness Review(PRR)JCDPJDPDDPIntegration ValidationCertification-EIS商飞的挑战 循规4SAE ARP 4754A,Do178B/Do254 多领域的协作4牵涉到众多的专业团队,如何能够增进有效协作沟通,对需求保持统一的认识、理解和遵循 跟踪4如何记录需求分析分解的过程4如何具有跟踪需求过程/需求状态的能力,特别是

4、项目的关键阶段 变更4如何增强洞察变更影响的能力,有效分析变更影响的范围 供应商沟通和管理4更好的与供应商进行协作,更好的管理 系统集成4在生命周期早期做功能验证以增加交付的可预测性、缩短交付时间、减少子系统的集成风险 内容安排内容安排 客户背景、现状和面临挑战客户背景、现状和面临挑战 IBM Rational 提供的解决方案提供的解决方案 解决方案实施过程概述解决方案实施过程概述 解决方案实施效果解决方案实施效果 后续合作计划和总结后续合作计划和总结6IBM Rational 提供的解决方案提供的解决方案7Rational DOORS(产品)+Requirement Based Engine

5、ering Process(流程服 务)+需求数据库信息架构(需求库服务)+需求方法培训(方法培训)-作为系统工程的起点和主线-为规章遵循,领域协作,变更管理,供应商管理,系统集成奠定坚实基础Rational Change(产品)+变更流程定义和PDM工具集成(服务)-实现统一产品变更流程问题Rational Rhapsody(产品)+Harmony/SE 方法论(服务)-建立适合的系统综合设计流程和需求开发方法-实现模型驱动的系统设计,以及系统设计的可验证Platform for Systems Development Definition,Development,Construction

6、and Verification&Validation Stakeholder RequirementsSystem Reqs(Subsystem)Subsystem SW ReqsSystem Arch.(SysML)Subsystem HW ReqsSW Design(UML)CodeUnit TestsSW Component TestsSystem TestsAcceptance TestsSW Integration TestsCode generationHW Design:Mechanical Design,Electrical Design,.DOORSRhapsodyCati

7、a,ProEngineer,xCAD.Rhapsody TC,RTRTDOORS/RQMPLM/PDM:Hardware Change&CMClearQuest or Change:change managementPLM/PDM+ClearQuest or Change:integrated product change managementPlatform for Systems Development(II)Change Management and Configuration Management Stakeholder RequirementsSystem ReqsSubsystem

8、 SW ReqsSystem Arch.(SysML)Subsystem HW ReqsSW Design(UML)CodeUnit TestsSW Component TestsSystem TestsAcceptance TestsSW Integration TestsCode generationHW Design:Mechanical Design,Electrical Design,.ClearCase or Synergy:code&models CMTeam Concert:code&models CMPLM/PDM+Team Concert:integrated produc

9、t change management系统和软件工程的平台定义,开发,构建,验证和确认用户需求用户需求系统需求系统需求子系统需求子系统需求软件需求软件需求系统架构系统架构.(SysML)子系统需求子系统需求硬件需求硬件需求系统设计系统设计(UML)代码代码单元测试单元测试软件模块测试软件模块测试系统测试系统测试验收测试验收测试软件集成测试软件集成测试代码生成硬件设计:硬件设计:机械设计,机械设计,电气设计电气设计DOORSRhapsody非非IBM产品:产品:Catia,ProEngineer,xCAD.Rhapsody Test ConductorTest RealTimeDOORS/RQM

10、PLM/PDM:硬件的变更和构型硬件的变更和构型IBM ClearQuest 或或 Change:变更管理变更管理PLM/PDM(其他厂商)(其他厂商)+IBM ClearQuest 或或 Change:集成的产品变更管理集成的产品变更管理系统和软件工程的平台(II)变更和配置管理(配置管理又称构型管理)用户需求用户需求系统需求系统需求子系统需求子系统需求硬件需求硬件需求系统架构系统架构(SysML)子系统子系统硬件需求硬件需求软件设计软件设计(UML)代码代码单元测试单元测试软件模块测试软件模块测试系统测试系统测试验收测试验收测试软件集成测试软件集成测试代码生成硬件设计:硬件设计:机械设计,

11、机械设计,电气设计电气设计IBM:ClearCase 或或 Synergy:代码和模型代码和模型的配置管理的配置管理IBM:Team Concert:代码和模型的配置代码和模型的配置管理管理PLM/PDM(其他厂商)(其他厂商)+IBM Team Concert:集成的产品变更管理集成的产品变更管理IBM Team Concert =ClearQuest+ClearCase=Change+Synergy内容安排内容安排 客户背景、现状和面临挑战客户背景、现状和面临挑战 IBM Rational 提供的解决方案提供的解决方案 解决方案实施过程概述解决方案实施过程概述 解决方案实施效果解决方案实施

12、效果 后续合作计划和总结后续合作计划和总结12IBM Rational 提供的解决方案提供的解决方案13Rational DOORS(产品)+Requirement Based Engineering Process(流程服 务)+需求数据库信息架构(需求库服务)+需求方法培训(方法培训)-作为系统工程的起点和主线-为规章遵循,领域协作,变更管理,供应商管理,系统集成奠定坚实基础Rational Change(产品)+变更流程定义和PDM工具集成(服务)-实现统一产品变更流程问题Rational Rhapsody(产品)+Harmony/SE 方法论(服务)-建立适合的系统综合设计流程和需求开

13、发方法-实现模型驱动的系统设计,以及系统设计的可验证基于需求的工程流程贯穿整个系统生命周期 基于需求的工程(RBE)4覆盖整个从理解客户需求、翻译及把需求传递给设计团队、开发解决方案、证明中间的设计/产品满足相应层次的需求然后最终证明交付给客户的产品满足他们的需求的全工程生命周期 基于需求的工程不仅仅是需求工程DOORS 实施概述 第一轮152010年3月至6月,以航电部门为试点单位,启动了需求管理平台试点项目 -先抛开工具,梳理流程,成果是 COMAC REQUIREMENTS BASED ENGINEERING PROCESS基于需求的工程流程工程流程word文档-结合 COMAC REQ

14、UIREMENTS BASED ENGINEERING PROCESS基于需求的工程流程,指定需求信息架构信息架构(目录结构,文档组成,属性组成,视图组成)。成果是 Information Architecture for COMAC word文档-再用DOORS工具,将上述成果落地,形成基本数据库。并给出工具使用工具使用手册手册RBE DOORS User Guide for COMACSystem/Equipment Installation ReqsEquipment Installation DiagramEquipment SpecificationRequirement Based

15、 onAssessment Result Or ReportRequirement from other teams,such as hydraulic,fuelMarket Requirement&GoalAircraft RequirementHLRHLRAvionics System RequirementHLRHLRComponent SpecificationStructure WorldAvionics Design SpecAnalysis ModelsHLRHLRICDHLRHLRSubsystem SpecificationSafety AssessmentFHAPSSASS

16、A(FTA,CCA)Maintainability AnalysisReliability AnalysisCertificationHLRHLRSubsystem Design SpecAnalysis ModelsIn DOORSNot In DOORSSpecial Domain ActivityRequirementSpecificationAnalysis&DesignV&VV&V PlanHLRHLRV&V ProcedureHLRHLRV&V EvidenceV&V ReportHLRHLRV&V ProcedureHLRHLRV&V EvidenceV&V PlanV&V Re

17、portV&V PlanHLRHLRV&V ProcedureHLRHLRV&V EvidenceV&V ReportInformation ModelPackage SpecGenerated Report2011年3月整个公司进行推广需求管理系统 Rational DOORS跨越整个生命周期和各个部门来管理和跟踪飞机研发的全部需求 各部门需求管理流程的评审、分析和设计,包括流程、现有需求文档和模板 各部门需求信息架构的评审、分析、设计和实现,包括数据库架构和属性 各部门需求管理流程、步骤和信息架构的实现和验证。各部门需求管理流程、步骤和信息架构的最终用户培训 所有需求文档全部入库 开始在D

18、OORS环境中工作.1718飞行器详细信息架构案例演示案例演示IBM Rational 提供的解决方案提供的解决方案20Rational DOORS(产品)+Requirement Based Engineering Process(流程服 务)+需求数据库信息架构(需求库服务)+需求方法培训(方法培训)-作为系统工程的起点和主线-为规章遵循,领域协作,变更管理,供应商管理,系统集成奠定坚实基础Rational Change(产品)+变更流程定义和PDM工具集成(服务)-实现统一产品变更流程问题Rational Rhapsody(产品)+Harmony/SE 方法论(服务)-建立适合的系统综合

19、设计流程和需求开发方法-实现模型驱动的系统设计,以及系统设计的可验证 项目情况简介 当前现状4该客户目前已经有PDM平台支持基于文档的版本的变更管理。4使用DOORS将需求进行条目化的管理。面临问题4研发过程中,针对频率较为频繁的小版本修改,或者基于条目的需求内容的变更,如何采取适当的流程对变更过程进行控制跟踪,确保DOORS中的数据被有效控制和管理。4针对大版本的变更,PDM平台能控制变更的结果和文件,怎样将PDM的评审流程和IBM有关变更管理的最佳实践结合起来。21解决方案解决方案 -Enterprise Change Process以下流程是IBM结合业界经验而提取的最佳实践流程。用一个

20、统一的方式来处理研发过程中的任务分配,变更(新功能和改动)管理和缺陷管理,大大方便用户的采纳和吸收。其中整合了需求变更控制流程项目成果展示-Change与DOORS集成AssignedReviewApprovedAppliedStart HereCreated设计人员测试人员orDOORS中提交设计人员测试人员orChange中提交架构师复审测试经理设计经理分配测试人员设计人员or变更实施人员获取授权 修改需求 发送复审科室主任应用 DOORSChange目前项目主要成果目前项目主要成果 IBM根据行业最佳实践的Enterprise Change Process流程设计思路,建立适合试点部门的

21、业务模式的需求变更流程 建立问题报告(PR)、ECP(Enterprise Change Proposal)、ECM(Enterprise Change Memo)、需求变更单(RCR:Requirement Change Request)流程之间关联,实现变更请求之间的追溯 建立DOORS与Rational Change集成环境,确保DOORS中数据变更经过分析、授权、评审过程控制,实现需求变更管理功能 成功实现了IDEAL与Rational Change集成。和DOORS实施类似,先从航电试验至全院铺开,2011年5月至今应用场景的信息流应用场景的信息流ECRECPRCRRCRModule

22、ModuleModulePDFIDEALRational ChangeRational DoorsClose ECP after Verify Signature1nECP请求1.IBM Rational 提供的解决方案提供的解决方案26Rational DOORS(产品)+Requirement Based Engineering Process(流程服 务)+需求数据库信息架构(需求库服务)+需求方法培训(方法培训)-作为系统工程的起点和主线-为规章遵循,领域协作,变更管理,供应商管理,系统集成奠定坚实基础Rational Change(产品)+变更流程定义和PDM工具集成(服务)-实现统

23、一产品变更流程问题Rational Rhapsody(产品)+Harmony/SE 方法论(服务)-建立适合的系统综合设计流程和需求开发方法-实现模型驱动的系统设计,以及系统设计的可验证 简介 背景4已具备基本的工作流,使用DOORS系统,尚未应用模型驱动的系统设计和需求开发的最佳实践 面临问题4需求定义和管理的工作通过DOORS来完成,而如何更进一步保证DOORS中的需求的完整性、正确性和无歧义。这是此次模型驱动的系统开发方法和Rhapsody的工具的核心意义所在。通过利用SysML环境,系统工程师可以清晰明确地捕获需求和设计信息。4优化整个公司系统设计团队之间的沟通、协作4在生命周期早期做

24、功能验证以增加交付的可预测性、缩短交付时间、减少子系统的集成风险27 可视化的需求、系统和软件建模 通过早期系统原型找出最佳系统设计方案 建立模型和需求的追踪关系 保证设计遵循行业标准和安全规范 模型级别的仿真,保证系统设计缺陷在早期被发现 快速响应用户需求或系统架构的变化,保证端到端的追踪 增加团队的协作性 系统工程最佳实践Harmony/SE方法Rational DOORSRational RhapsodyRational Harmony/SE基于模型的系统工程方法(Harmony/SE)和支撑工具(Rhapsody)基于模型的系统工程方法 最佳实践 Harmony/SE项目采用的基于模型

25、的系统工程方法 第一阶段:需求分析阶段:场景进行需求分析,包括定义相关用例(Use Cases),即,定义功能需求范围,以及功能需求分配给用例的分配关系30需求分析阶段示例:飞机具备的系统能力为UseCase:TakeOff;与飞机起飞有关的外部系统为Actor:Pilots、ATC、CabinCrew。31Aircraft基于模型的系统工程方法的第二阶段 需求分析阶段:场景进行需求分析,包括定义相关用例(Use Cases),即,定义功能需求范围,以及功能需求分配给用例的分配关系 系统功能分析阶段,包括:41)建立可执行的用例模型;42)通过模型的执行验证和确认用例模型和相关的需求;43)进

26、行异常场景的分析。32 黑盒活动图PreTakeOffProcedures表示起飞前预处理程序起飞前飞机需要进行的各个功能操作。33功能性分析阶段示例:对系统用例,进行功能性分析,使用活动图表示系统的不同功能流。功能性分析阶段示例:功能性分析阶段中,使用时序图表示系统工作的各个典型工作场景。时序图可以从活动图中自动产生,用于系统集成和系统集成测试的测试场景。时序图Manual_AutoPilot_Manual表示飞机在起飞过程中,人工模式和自动驾驶模式之间的互相转换设置。34基于模型的系统工程方法的第三阶段 需求分析阶段:场景进行需求分析,包括定义相关用例(Use Cases),即,定义功能需

27、求范围,以及功能需求分配给用例的分配关系 系统功能分析阶段,包括:41)建立可执行的用例模型;42)通过模型的执行验证和确认用例模型和相关的需求;43)进行异常场景的分析。设计综合阶段可分为3个子阶段即飞机系统架构权衡分析、飞机系统架构设计和详细架构设计阶段。4飞机系统权衡分析通过权衡多个不同的解决方案的优缺点,找到一个最佳的飞机系统架构。4架构设计是将起飞和飞行场景功能性需求(系统功能)和非功能性需求分配到既定架构上去。4详细架构设计是定义飞机不同子系统的Port/Interface,以及子系统级别的状态行为和对其的验证。35设计综合阶段:针对系统架构,将系统功能性分析阶段得到系统模型分配到

28、系统的不同部分,优化设计后得到可执行的白盒系统模型。白盒活动图示例起飞前进行预处理程序中,各个子系统需要完成的系统功能。36内容安排内容安排 客户背景、现状和面临挑战客户背景、现状和面临挑战 IBM Rational 提供的解决方案提供的解决方案 解决方案实施过程概述解决方案实施过程概述 解决方案实施效果解决方案实施效果 后续合作计划和总结后续合作计划和总结37解决方案实施效果 COMAC上飞院基本建立一套完整的需求管理体系,从总体到各个科室需求管理系统已经开始运转 COMAC上飞院形成一套完整的变更管理体系,整合了需求变更(DOORS+Change)和系统变更(Windchill IDEAL

29、)2大体系 COMAC上飞院从零开始,将建立先进的基于模型的多系统综合设计能力38内容安排内容安排 客户背景、现状和面临挑战客户背景、现状和面临挑战 IBM Rational 提供的解决方案提供的解决方案 解决方案实施过程概述解决方案实施过程概述 解决方案实施效果解决方案实施效果 后续合作计划和总结后续合作计划和总结39合作路线图MaturityStage 4Stage 3Stage 1Stage 2Product Line EngineeringAnd OtherModel Driven Systems DevelopmentEnterprise Integration Quality Ma

30、nagement Enterprise ReportingTimeRequirement Management Change Management2010201120122013系统工程从需求管理开始u引入系统工程是一段旅程u“小步快跑”比“大步跳跃”要好u试图一下次跳跃到很高的成熟度是非常危险的u从最基本的开始做起 但做好计划,准备好快速的前进IBM 系统工程解决方案帮助商飞应对挑战 循规4SAE ARP 4754A,Do178B/Do254 多领域的协作4牵涉到众多的专业团队,如何能够增进有效协作沟通,对需求保持统一的认识、理解和遵循 跟踪4如何记录需求分析分解的过程4如何具有跟踪需求过程/需求状态的能力,特别是项目的关键阶段 变更4如何增强洞察变更影响的能力,有效分析变更影响的范围 供应商沟通和管理4更好的与供应商进行协作,更好的管理 系统集成4在生命周期早期做功能验证以增加交付的可预测性、缩短交付时间、减少子系统的集成风险

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 办公、行业 > 各类PPT课件(模板)
版权提示 | 免责声明

1,本文(基于COMAC需求工程最佳实践的DOORS方案.ppt)为本站会员(三亚风情)主动上传,163文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。
2,用户下载本文档,所消耗的文币(积分)将全额增加到上传者的账号。
3, 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(发送邮件至3464097650@qq.com或直接QQ联系客服),我们立即给予删除!


侵权处理QQ:3464097650--上传资料QQ:3464097650

【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。


163文库-Www.163Wenku.Com |网站地图|