Your SlideShare is downloading. ×
0
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Model Based Systems and Software Engineering an overview of the IBM Rational solution
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Model Based Systems and Software Engineering an overview of the IBM Rational solution

998

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
998
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
54
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. © 2013 IBM Corporation Innovation for a smarter planet Model Based Systems and Software Engineering an overview of the IBM Rational solution Edmund Mayer, Systems Solution Architect 20 June 2013
  • 2. © 2011 IBM Corporation Software and Systems Engineering | Rational Abstract topics Capturing and enacting workflow descriptions with Method Composer Project planning and collaboration with Team Concert – Work management – Change and process management – Dashboard and metrics Systems and software development with DOORS and Rhapsody Document publishing with Publishing Engine Model based test with Rhapsody TestConductor 2 2
  • 3. © 2011 IBM Corporation Software and Systems Engineering | Rational 3 IBM Rational Solution for DO-178C Process Definition and Enactment Model Based Systems and Software Engineering Testing 3
  • 4. © 2011 IBM Corporation Software and Systems Engineering | Rational IBM Rational Solution for DO178B/C A set of practices, customizable process guidelines, and compatible products to help organizations develop products for certification under DO-178B/C Goal – to help provide evidence of the consistent development of safe software in a cost-effective, efficient, and productive manner The process may be applied to any appropriate development tooling but is specifically optimized for the Rational Systems and Software Solution consisting of tools – Rational Team Concert – Rational DOORS – Rational Rhapsody – Rational Quality Manager
  • 5. © 2011 IBM Corporation Software and Systems Engineering | Rational Rational solution for Systems and Software Engineering QUALITY MANAGEMENT Achieve “quality by design” with an integrated, automated testing process ARCHITECTURE & DESIGN Use modeling to validate requirements, architecture and design throughout the development process REQUIREMENTS MANAGEMENT Manage all system requirements with full traceability across the lifecycle BEST PRACTICES AND SERVICE OFFERINGS Open Services for Lifecycle Collaboration COLLABORATION, PLANNING & CHANGE MANAGEMENT Collaborate across diverse engineering disciplines and development teams 5
  • 6. © 2011 IBM Corporation Software and Systems Engineering | Rational The SSE solution uses both Jazz and OSLC tool integrations OSLC tools: • DOORS 9.5 • SA • Rhapsody • …. Jazz tools: • RTC • RQM • DOORS NG • RDM • …..
  • 7. © 2011 IBM Corporation Software and Systems Engineering | Rational 7 IBM Rational Solution for DO-178C Process Definition and Enactment Model Based Systems and Software Engineering Testing 7
  • 8. © 2011 IBM Corporation Software and Systems Engineering | Rational IBM Rational Solutions for DO178-C process adoption made easy Role-based guidance available as a web site Integrated Software Development Process for DO-178B/C (ISDP-178)
  • 9. © 2011 IBM Corporation Software and Systems Engineering | Rational Characteristics of effective process management and use Authoring and capturing process descriptions Tailoring and configuring process content Process reuse Deploying and accessing process information (in context) Process enactment and workflow enforcement 9
  • 10. © 2011 IBM Corporation Software and Systems Engineering | Rational Integrated process and tools Process enactment through a Rational Team Concert (RTC) “process template” Easy creation of work assignments consistent with the documented practice content Assignable to team members Visible in dashboards Alerts and feeds available
  • 11. © 2011 IBM Corporation Software and Systems Engineering | Rational Rational Team Concert (RTC) Plan Definition
  • 12. © 2011 IBM Corporation Software and Systems Engineering | Rational Rational Team Concert (RTC) Plan Definition Unified view of Information – What - Work Items – Who – Project Area / Team Area – When – Iteration
  • 13. © 2011 IBM Corporation Software and Systems Engineering | Rational 13 Process support across the development organization Sample showing different development teams following different processes
  • 14. © 2011 IBM Corporation Software and Systems Engineering | Rational 14
  • 15. © 2011 IBM Corporation Software and Systems Engineering | Rational Demonstration overview Create new DO-178C project – Process template – roles, plans, views, work items Review System-level project – Personal and mini dashboards – Update plan for changes 15 15
  • 16. © 2011 IBM Corporation Software and Systems Engineering | Rational 16
  • 17. © 2011 IBM Corporation Software and Systems Engineering | Rational 17 IBM Rational Solution for DO-178C Process Definition and Enactment Model Based Systems and Software Engineering Testing 17
  • 18. © 2011 IBM Corporation Software and Systems Engineering | Rational 18 Manage requirements across lifecycle and across disciplines using Rational DOORS 1. 820.30(b) Design and Development Planning Eachmanufacturer shall establishandmaintainplans that describe or reference the designanddevelopment activities anddefine responsibility for implementation. The plansshall identifyanddescribe the interfaceswithdifferent groups or activitiesthat provide, or result in, input tothe designanddevelopment process. The plansshall be reviewedas designanddevelopment evolves. The plansshall be updated as designanddevelopment evolves. The plansshall be approved asdesignanddevelopment evolves. 2. 820.30(c) DesignInput 2.1. Eachmanufacturer shall establishprocedures to ensure that the designrequirements relatingto a device are appropriate and addressthe intended use of the device, includingthe needsof the user andpatient. 2.2. Eachmanufacturer shall maintainprocedures to ensure that the designrequirements relatingto a device are appropriate and addressthe intended use of the device, includingthe needsof the user andpatient. 2.3. The procedures shall include a mechanismfor addressingincomplete requirements. 2.4. The procedures shall include a mechanismfor addressingambiguous requirements. 2.5. The procedures shall include a mechanismfor addressingconflicting requirements. 2.6. The designinput requirements shall be documentedbya designatedindividual(s). 2.7. The designinput requirements shall be reviewedby a designatedindividual(s). 2.8. The designinput requirements shall be approvedbya designatedindividual(s). 2.9. The approval, including the date andsignature of the individual(s) approving the requirements, shall be documented. 2.10.Questions. 2.10.1. Summarize the manufacturer'swrittenprocedure(s) for identification and control of designinput. 2.10.2. Fromwhat sourcesare designinputs sought? 2.10.3. Do design input procedures cover the relevant aspects, suchas: (Markall that applyand list additional aspects.) 2.10.3.1. intendeduse 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits andtolerances 2.10.3.6. riskanalysis 2.10.3.7. toxicityandbiocompatibility 2.10.3.8. electromagnetic compatibility(EMC) 2.10.3.9. compatibility withaccessories/auxiliary devices 2.10.3.10. compatibility withthe environment of intendeduse 2.10.3.11. humanfactors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutoryandregulatory requirements 2.10.3.16. voluntarystandards 2.10.3.17. manufacturingprocesses 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific designcovered, how were the designinput requirementsidentified? 2.10.5. For the specific designcovered, how were the designinput requirementsreviewedfor adequacy? ComplywithFDADesignControl Guidance GMP Regulation 1. Capture design and relatedinformation 1.1. Input electronically formatteddata 1.2. Reference external informationsources 1.3. Reference external documentation 2. Store designandrelatedinformation 2.1. Identify and tagdesign informationasunique “designelements” 2.2. Organize designelements 2.2.1. Organize by Design Control Guidance Element 2.2.2. Organize by inter-relationships 2.3. Ensure all designelements are available 2.3.1. Store designelements by Design Control Guidance Element 2.3.2. Store designelements andtheir historical values 3. Manage all user needs 3.1. Identify the sourceof theuser need 3.2. Identify all user types (groups) 3.3. Identify the customer (s) 3.4. Profile the expected patients 3.5. State the intended use of the product (family) 3.6. Capture the acceptance criteria for eachuser need 4. Manage designinput requirements 4.1. Identify the sourceof therequirement 4.2. Identify the associated user need 4.3. Capture requirement descriptionandattributes 4.4. Capture acceptance criteria 4.5. Assignresponsibility for each requirement 4.6. Manage incomplete requirements 4.7. Manage ambiguous requirements 4.8. Manage conflicting requirements 4.9. Approve all requirements 5. Manage acceptance 5.1. Ensure the acceptance of everyuser need 5.2. Ensure the acceptance of everydesign input requirement 5.3. Document theresultsof every user needacceptance test 5.4. Document theresultsof every design input requirements test 5.5. Make acceptance results available 6. Manage change 6.1. Maintain history of design element changes 6.1.1. Make complete change historyavailable 6.1.2. Maintainhistory withinand acrossany organizational procedure 6.1.3. Maintainhistory withinand acrossany project milestone 6.1.4. Maintainhistory withinand acrossany Design Control Guidance Elements 6.2. Capture frequency andnature of element changes 6.2.1. Provide rationale for change 6.2.2. Describe decisions made 6.2.3. Identifyapproval authorityfor the change 6.2.4. Capture date, time, andsignatureof approving authority 6.3. Identify impacted elements due to a change inanother element 6.3.1. Create backwardtraces todesignelements within and across anyorganizational procedure 6.3.2. Create backwardtraces todesignelements within and across anyproject milestone 1.1. Identifyimpacted elements due toa change inanother element • Traceability Reports: consistency with drivingdesign elements • Impact Reports: other design elements affected • Links toimpacted design elements 1.1.1.Create backward tracesto design elements within and across any organizational procedure • TraceabilityReports: Procedure Attribute 1.1.2.Create backward tracesto design elements within and across any project milestone • TraceabilityReports: Milestone Attribute 1.1.3.Create backward tracesto design elements within and across Design Control Guidance Elements • TraceabilityReports: Linkeddesignelements 1.1.4.Create forward impacts todesignelements withinand across anyorganizational procedure • Impact Reports: Procedure Attribute 1.1.5.Create forward impacts todesignelements withinand across anyproject milestone • Impact Reports: Milestone Attribute 1.1.6.Create forward impacts todesignelements withinand across Design Control Guidance Elements • Impact Reports: Linkeddesign elements 1.2. Associate changeddesign elements withrelated elements • LinkChange Design Object with affected design element(s) • Traceability Links and Reportsfromaffecteddesign element(s) • Impact Links and Reports fromaffected design element(s) 1.2.1.Associate design element changes with decisions, rationale, andapproval authority information • Change DecisionObjects with followingAttributes: • Disposition Attribute • Decision Attribute • Rationale Attribute • Owner Attribute • Management Approval Attribute 1.2.2.Provide associations within and acrossany organizational procedure • Change DesignObject Traceability Link onProcedure Attribute • Change DesignObject Impacts Link onProcedure Attribute 1.2.3.Provide associations within and acrossany project milestone • Change DesignObject Traceability Link onMilestone Attribute • Change DesignObject Impacts Link onMilestone Attribute 1.2.4.Provide associations within and acrossDesign Control Guidance Elements • Change DesignObject Traceability Link totraced design elements • Change DesignObject Impacts Link to linked designelements 1.3. Mange the change process • Design Change Module • Design Change Reports • Object History • Object History Reports • Versions • Baselines 1. 820.30(b) Design and Development Planning Eachmanufacturer shall establishandmaintainplans that describe or reference the designanddevelopment activities anddefine responsibility for implementation. The plansshall identifyanddescribe the interfaceswithdifferent groups or activitiesthat provide, or result in, input tothe designanddevelopment process. The plansshall be reviewedas designanddevelopment evolves. The plansshall be updated as designanddevelopment evolves. The plansshall be approved asdesignanddevelopment evolves. 2. 820.30(c) DesignInput 2.1. Eachmanufacturer shall establishprocedures to ensure that the designrequirements relatingto a device are appropriate and addressthe intended use of the device, includingthe needsof the user andpatient. 2.2. Eachmanufacturer shall maintainprocedures to ensure that the designrequirements relatingto a device are appropriate and addressthe intended use of the device, includingthe needsof the user andpatient. 2.3. The procedures shall include a mechanismfor addressingincomplete requirements. 2.4. The procedures shall include a mechanismfor addressingambiguous requirements. 2.5. The procedures shall include a mechanismfor addressingconflicting requirements. 2.6. The designinput requirements shall be documentedbya designatedindividual(s). 2.7. The designinput requirements shall be reviewedby a designatedindividual(s). 2.8. The designinput requirements shall be approvedbya designatedindividual(s). 2.9. The approval, including the date andsignature of the individual(s) approving the requirements, shall be documented. 2.10.Questions. 2.10.1. Summarize the manufacturer'swrittenprocedure(s) for identification and control of designinput. 2.10.2. Fromwhat sourcesare designinputs sought? 2.10.3. Do design input procedures cover the relevant aspects, suchas: (Markall that applyand list additional aspects.) 2.10.3.1. intendeduse 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits andtolerances 2.10.3.6. riskanalysis 2.10.3.7. toxicityandbiocompatibility 2.10.3.8. electromagnetic compatibility(EMC) 2.10.3.9. compatibility withaccessories/auxiliary devices 2.10.3.10. compatibility withthe environment of intendeduse 2.10.3.11. humanfactors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutoryandregulatory requirements 2.10.3.16. voluntarystandards 2.10.3.17. manufacturingprocesses 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific designcovered, how were the designinput requirementsidentified? 2.10.5. For the specific designcovered, how were the designinput requirementsreviewedfor adequacy? ComplywithFDADesignControl Guidance GMP Regulation 1. Capture design and relatedinformation 1.1. Input electronically formatteddata 1.2. Reference external informationsources 1.3. Reference external documentation 2. Store designandrelatedinformation 2.1. Identify and tagdesign informationasunique “designelements” 2.2. Organize designelements 2.2.1. Organize by Design Control Guidance Element 2.2.2. Organize by inter-relationships 2.3. Ensure all designelements are available 2.3.1. Store designelements by Design Control Guidance Element 2.3.2. Store designelements andtheir historical values 3. Manage all user needs 3.1. Identify the sourceof theuser need 3.2. Identify all user types (groups) 3.3. Identify the customer (s) 3.4. Profile the expected patients 3.5. State the intended use of the product (family) 3.6. Capture the acceptance criteria for eachuser need 4. Manage designinput requirements 4.1. Identify the sourceof therequirement 4.2. Identify the associated user need 4.3. Capture requirement descriptionandattributes 4.4. Capture acceptance criteria 4.5. Assignresponsibility for each requirement 4.6. Manage incomplete requirements 4.7. Manage ambiguous requirements 4.8. Manage conflicting requirements 4.9. Approve all requirements 5. Manage acceptance 5.1. Ensure the acceptance of everyuser need 5.2. Ensure the acceptance of everydesign input requirement 5.3. Document theresultsof every user needacceptance test 5.4. Document theresultsof every design input requirements test 5.5. Make acceptance results available 6. Manage change 6.1. Maintain history of design element changes 6.1.1. Make complete change historyavailable 6.1.2. Maintainhistory withinand acrossany organizational procedure 6.1.3. Maintainhistory withinand acrossany project milestone 6.1.4. Maintainhistory withinand acrossany Design Control Guidance Elements 6.2. Capture frequency andnature of element changes 6.2.1. Provide rationale for change 6.2.2. Describe decisions made 6.2.3. Identifyapproval authorityfor the change 6.2.4. Capture date, time, andsignatureof approving authority 6.3. Identify impacted elements due to a change inanother element 6.3.1. Create backwardtraces todesignelements within and across anyorganizational procedure 6.3.2. Create backwardtraces todesignelements within and across anyproject milestone 1.1. Identifyimpacted elements due to a change in another element • Traceability Reports: consistency with driving design elements • Impact Reports: other designelementsaffected • Links toimpacted design elements 1.1.1.Create backward traces todesignelements withinand across any organizational procedure • Traceability Reports: Procedure Attribute 1.1.2.Create backward traces todesignelements withinand across any project milestone • Traceability Reports: Milestone Attribute 1.1.3.Create backward traces todesignelements withinand across DesignControl Guidance Elements • Traceability Reports: Linked design elements 1.1.4.Create forward impacts to design elementswithin and across any organizational procedure • Impact Reports: Procedure Attribute 1.1.5.Create forward impacts to design elements within and across any project milestone • Impact Reports: Milestone Attribute 1.1.6.Create forward impacts to design elementswithin and across Design Control Guidance Elements • Impact Reports: Linked design elements 1.2. Associate changeddesign elements with related elements • Link Change Design Object with affected design element(s) • Traceability LinksandReportsfromaffected design element(s) • Impact Links andReportsfromaffected design element(s) 1.2.1.Associate design element changes withdecisions, rationale, andapproval authority information • Change Decision Objectswithfollowing Attributes: • Disposition Attribute • Decision Attribute • Rationale Attribute • Owner Attribute • Management Approval Attribute 1.2.2.Provide associations within and across any organizational procedure • Change Design Object Traceability Linkon Procedure Attribute • Change Design Object Impacts Link on Procedure Attribute 1.2.3.Provide associations within and across any project milestone • Change Design Object Traceability Linkon Milestone Attribute • Change Design Object Impacts Link on Milestone Attribute 1.2.4.Provide associations within and across Design Control Guidance Elements • Change Design Object Traceability Linktotraced design elements • Change Design Object Impacts Link to linked design elements 1.3. Mange the change process • DesignChange Module • DesignChange Reports • Object History • Object History Reports • Versions • Baselines User Requirements Test CasesDesign Technical Requirements End-to-end visual validation in one view Traceability to/from work items Traceability to/from tests Requirements change management
  • 19. © 2011 IBM Corporation Software and Systems Engineering | Rational 19 Capabilities Specify, design and develop systems and software for technical, embedded and real- time solutions, including those based on multi-core architectures Validate and verify designs with model based simulation and test throughout the product lifecycle Develop complete C, C++, Java and Ada applications, working in either the code or model while ensuring the two remain in sync Model-Based Systems Engineering and Model-Driven Development for real-time, embedded systems using Rational Rhapsody Benefits Build the right product through optimized communication and collaboration Eliminate defects early and increase quality by continually testing the design Reduce development time by automatically generating applications and documentation
  • 20. © 2011 IBM Corporation Software and Systems Engineering | Rational 20 Rational Publishing Engine Automate the generation of documentation, from multiple sources
  • 21. © 2011 IBM Corporation Software and Systems Engineering | Rational 21
  • 22. © 2011 IBM Corporation Software and Systems Engineering | Rational Demonstration overview Model based functional analysis – Using models to improve the quality of requirements Requirements driven software development – Using models to generate readable and certifiable code 22 22
  • 23. © 2011 IBM Corporation Software and Systems Engineering | Rational 23
  • 24. © 2011 IBM Corporation Software and Systems Engineering | Rational 24 IBM Rational Solution for DO-178C Process Definition and Enactment Model Based Systems and Software Engineering Testing 24
  • 25. © 2011 IBM Corporation Software and Systems Engineering | Rational Define test cases with sequence diagrams, statecharts, flowcharts or even code OMG UML Testing Profile Automate testing tasks Create Test Architecture Execute and monitor tests Host level and target based execution White-Box, Black-Box for design validation “Offline testing” mode - for testing on target C++, C, Java, Ada Supported Definition and management of regression tests Reporting of results, coverage and traceability Rhapsody TestConductor Add-on for Model-Based Testing Traceability across lifecycle – from requirements to integration
  • 26. © 2011 IBM Corporation Software and Systems Engineering | Rational DO-178 qualification of software development and verification tools
  • 27. © 2011 IBM Corporation Software and Systems Engineering | Rational Rhapsody Kit for ISO 26262, IEC 61508, and DO-178B/C Overview Document: describes the contents of the Rhapsody kit Rhapsody Reference workflow: provides an exemplary workflow for modelling, code generation and verification in safety critical Rhapsody TestConductor Add On Workflow: describes testing activities and objectives Rhapsody TestConductor Safety Manual: provides additional information for using TestConductor in safety related applications TÜV SÜD Certificate for Rhapsody TestConductor Add On TÜV SÜD Report on Certificate for ISO 26262 and IEC 61508 Rhapsody TestConductor Add On Validation Suite: separately available test suite for Rhapsody TestConductor to help in qualification efforts Certification kits for the SXF and SMXF real-time execution frameworks
  • 28. © 2011 IBM Corporation Software and Systems Engineering | Rational IBM Rational Rhapsody Reference workflow Rhapsody Reference Workflow for the development of safety-related software – provides guidance on how to fulfill functional safety requirements with model-based development methods and tools – is based on best practices for safety-related projects – addresses various workflow activities relevant for the development of safety-related software with a special focus on verification and validation to develop safe software28
  • 29. © 2012 IBM Corporation IBM Software, Rational 29 www.ibm.com/software/rational 29
  • 30. © 2012 IBM Corporation IBM Software, Rational 30 IBM Rational DOORS Next Generation DOORS concepts improved and much more…. Definition Rich-text documents Diagrams: Process, Use Case Storyboards, UI sketching & flow Project glossaries Templates Collaboration Review & Approval Discussions Email Notification Visibility Customizable dashboards Analysis views Collections Milestone tracking & status Management Structure, Attributes/Types Traceability, Filtering, Tags Baselines, Change History Reuse (reqs & types) Reporting Metrics & Doc. Planning Integrated planning Effort estimation Task Management Lifecycle Central requirements, test, & development repository Common administration and role-based user licensing Warehouse reporting
  • 31. © 2012 IBM Corporation IBM Software, Rational Where does Rhapsody ATG fit with DO-178C testing? DO-178C and DO-331 address software design, code, and verification Verification involves: – review (test requirement, coverage review, …) – analysis (automated MISRA C++ compliance, code coverage analysis, …) – testing activities (mainly requirements based testing) TestConductor directly supports many of the required testing activities and analysis activities (requirements based testing, code coverage, model coverage) ATG provides more automation, but does not address additional verification methods beyond TestConductor Step 1 – define and implement a DO-178C/DO-311 compliant process using Rhapsody, TestConductor, Team Concert Step 2 – if step 1 is working, consider using ATG for more automation
  • 32. © 2012 IBM Corporation IBM Software, Rational RTCA DO-178B is an objective-based standard applied by FAA (Federal Aviation Administration) for the certification of software in avionics systems. Published in 1992, it covers the 5 main processes concerning Planning, Development, Verification, Configuration Management and Quality Assurance. DO-178B outlines the objectives to be met, the work activities to be performed for each objective, and the evidence (output documents) to be supplied for each objective (based on criticality level A-E) Example: RTCA DO-178B Software Criticality Level Failure Condition Category Failure Condition Description Objectives Level A Catastrophic Conditions which would prevent continued safe flight and landing. 66 Level B Haazardous/ Sever-Major Conditions which would reduce aircraft safety margin/functional capabilities, produce a higher workload to the flight crew or have serious adverse effencts on occupants 65 Level C Major Conditions which would not significantly reduce aircraft safety, crew ability to work under adveser operation or produce discomfort to occupants. 57 Level D Minor Conditions which would not significantly reduce aircraft safety, slight increas in crew workload or produce some inconvenience to occupants 28 Level E No Effect Conditions which do not affect the aircraft operations or crew workload. 0

×