Model-Driven IV&V Management with Arcadia and Capella

Transcription

1 Model-Driven IV&V Management with Arcadia and Capella THALES CSDM, PARIS, 2015 Jean-Luc Voirin, Stéphane Bonnet

2 The Problem INTEGRATION VERIFICATION VALIDATION IS COMPLEX AND COSTLY

3 Limits of Traditional Requirement-Based Approach Definition and subsystem specification Requirement validation process Customer Textual Requirements Tests description Requirements IV&V Management System Requirements Unformalized Design Product Breakdown Coherency? Text Req Text Req Test Campaign Test Case Test Case Test Results Sub-Contractor Textual Requirements 3 Subsystem Design

4 Consequences on Engineering and IV&V (Some) Consequences on engineering Requirements are allocated but solution is often insufficiently described Definition of suppliers delivery is weak and not sufficient Justification of definition is poor and unreliable Checking quality of the definition is not possible before IV&V Integration verification validation is too expensive due to Wrong estimates and unbalanced incremental IVV Missing components when running planned tests Difficulty to precisely localize / analyze defects Costly & complex non regression testing Poor mastering of changes impact and IVV configurations These problems increase along with system or project complexity 4

5 Foreword: Arcadia and Capella A PUBLIC MODEL-BASED METHOD FOR SYSTEMS, HARWARE AND SOFTWARE ARCHITECTURAL DESIGN AN SOURCE MODELLING WORKBENCH SUPPORTING ARCADIA, WIDELY DEPLOYED IN ALL THALES BUSINESS UNITS WORLDWIDE

6 ARChitecture Analysis and Design Integrated Approach A model-based method devoted to systems, software, and hardware architecture engineering, Understand the real customer need, Define and share the system architecture among stakeholders, Early evaluate, validate and justify the system architectural design, Ease and master IVVQ 6

7 Model-Based Systems Engineering with Arcadia Textual Reqs + Model driven Customer Textual Requirements Tests description Requirements Requirements System Model Need Solution (Derived, reconstructed link) Tests description System Requirements Unformalized Design Product Breakdown Coherency? Product Breakdown Sub-Contractor Textual Requirements Sub-Contractor Textual Requirements Subsystem Model 7 Subsystem Design Need Solution

8 Capella Modelling Workbench, an Overview METHODOLOGICAL BROWSER MULTI-VIEWPOINT ANALYSIS FUNCTIONS, DATAFLOWS STRUCTURE INTERFACES BEHAVIOUR BEHAVIOUR 8

9 Model-Based IV&V Management HOW ARCHITECTURE MODELS HELP SECURE AND OPTIMIZE IV&V ACTIVITIES Hengelo, 2015

10 Test, Integration, Verification, Validation Principles Requirements Model IV&V Management Text Req Text Req Function Capability Scenario IVV Version (RV/DV) Test Campaign Test Case Test Results Function Test Case Function Functional Chain (Derived, reconstructed link) 10

11 The Capella «Release Management and IV&V» Viewpoint Core Principles Plan IV&V activities based on model iterations, master the ups and downs, optimize the validation efforts - Plan Requested and Developed Versions (RVs, DVs) - Define the functional expectations for these versions - Automatically compute the expectations on the architecture model (components, interfaces, etc.) Assess the maturity of deliveries Compare RVs and DVs, previsualize them on diagrams, 11

12 Principles: Content Definition for Requested and Developed Versions Define operational content expected for each project milestone Deduce functional content and components to be delivered Define components versions and content 12

13 Example: Define an IV&V Strategy IVV Steps & Deliveries are based on Operational Capabilities & Scenarios Example: «in V1 integrate detection, then V2 classification, then V3 identification» - Better Customer visibility and understanding - Secured delivery of prime operational capabilities - Enhanced progressiveness of IVV - More relevant development planning The tool identifies the architecture components to be integrated Example: «to integrate sonobuoys drop, you need radio altimeter, FMS, and store management» - Better mastering of required configurations for each delivery - Quality and robustness of component provisioning Plan 13

14 Principles: Master the Content of Deliveries Blue: Software Yellow: hardware 14

15 Principles: Compare Requested vs Developed Versions Red: Delayed, missing Grey: expected in further version 15

16 Example: IVV in Progress : Mastering Real Life Ups & Downs Step or Delivery contents are defined and updated based on real availability of components at integration time Example: «what if radio altimeter is not available for V3.5?» 16 - Adaptation to delay and low maturity of components - Check of consistency between System version and components versions Tool identifies gaps between expected operational contents and available components Example: «Then Rescue Raft release & Submarine hunting (Sonoboys) are not possible» - Mastering of delivered functional contents and operational limits - Less spoilt time: Tests that have low chance of success are postponed

17 Tooling Support: Previsualization of Version Contents on Diagrams Release management viewpoint: Automated visualization of versions 17

18 Tooling Support: Previsualization of Version Contents on Diagrams Developed Version 1 Available elements in BLUE 18

19 Tooling Support: Previsualization of Version Contents on Diagrams Developed Version 2 Available elements in CYAN 19

20 Tooling Support: Previsualization of Version Contents on Diagrams Developed Versions 1 & 2 Common available elements in GREY 20

21 Tooling Support: Mastering Ups and Downs 21

22 Next Steps: Comprehensive IV&V Optimization Tests and Delivery contents are defined and managed consistently between engineering levels Example: «no need to test radar tracking at system level because run at radar level» - IVV Cost reduction thanks to less redundant test campaigns Test Means can be automatically specified from model, including versions according to IVV strategy Example: «no need for nav unit simulation before V3.6» - Better definition & anticipation of Test Means - Reduced constraints on Test Means Development & Cost Tool can check adequacy between delivery contents and available Test Means Example: «no way to run planned scenario X in V4.8: nav unit simulation is late» 22 - Less spoilt time: Tests with low chance of success are postponed - Adaptation to delay and low maturity in Test Means delivery

23 Thank You! Questions? Capella website: LinkedIn Twitter Arcadia forum: Capella forum: Sample model & doc.: