Integrate Jama Connect® and Sparx Systems’ Enterprise Architect (EA) using LemonTree.Connect to align business and engineering objectives.
Join our experts Philipp Kalenda, Head of Consulting & Training at LieberLieber and Cary Bryczek, Director of Solution Architecture at Jama Software ® to discover how this powerful collaboration eliminates the gap between requirements engineering, system architecture, design, and product management.
You will gain a thorough understanding of these topics and more:
- How Jama Connect®’s Live Traceability™ capabilities allow for seamless integration across best-of-breed tools.
- How leveraging Jama Connect Traceable MBSE™ can act as a starting point for your MBSE efforts.
- How to create a workflow for deriving systems architecture based on requirements from Jama Connect.
- How LemonTree.Connect enables standard engineering domain practices for configuration management.
- How to facilitate streamlined evidence that proves your architecture is satisfying requirements.
Below is a preview of our webinar. Click HERE to watch it in its entirety.
The following is an abbreviated transcript of our webinar.
Bridging ALM and MBSE: Strategies for Seamless Integration
Cary Bryczek: My name is Cary Bryczek. I’m the Director of Aerospace & Defense Solutions here at Jama Software. I’m really looking forward to speaking with you today on this particular topic and looking forward to Philipp’s presentation as well. So to kick things off, we are going to set … I just want to set the stage with some trends across the A&D industry that we’re seeing. I’ll talk about how those trends are creating challenges for chief engineers and describe what’s keeping them up at night. Then I’ll set the stage for Philipp’s presentation by showing you what Jama Connect’s Traceable MBSE™ looks like and how that’s designed to solve some of those challenges, and Philipp’s going to definitely take you on a deeper dive to show you how system models in Jama Connect interoperate.
In the aerospace and defense industry, developing a new system has a complexity that far exceeds commercial product development. For example, the FAA’s program to develop the unmanned aircraft traffic management system involves not just the pilot and his drone but is designed to enable autonomous and semi-autonomous operation of multiple aerial systems, including passenger and cargo delivery in a tightly integrated civil aerospace. The elements in blue that you see are all distinct systems of their own, and the new traffic management system needs to be able to integrate communications and data across all of those systems to provide this new capability.
In the highly constrained environment of outer space, NASA’s Cislunar and the Artemis program, for example, are focusing on the operation and survivability of autonomous systems. To develop a space system, NASA does not do this alone but has many contracts with companies to deliver parts of the system. For example, Blue Origin, they have two programs like the Friction Stir Additive Manufacturing Program and the Metallic Thermal Protection System are two examples of just parts of the system.
RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Aerospace
Bryczek: Canopy Aerospace, they’re developing a low-cost reusable thermal protection system. Roccor AKA Redwire in Erie, Colorado, they’re developing a characterization of high aspect ratio booms for these large apertures and so many more. This ecosystem of partners and contributing to a whole brings its own challenges to the pool when trying to collaborate, share data, and execute common systems engineering processes. Like the NASA’s Cislunar and Artemis initiatives for space exploration, they’re focusing on operation and survivability.
In the defense domain, we’re seeing all sorts of cases in unmanned aerial systems as well to aid tactical situations and help with strategic planning. The underlying theme of these large systems is the integration and the collaborative approaches to developing these different weapon systems and aerospace systems in very constrained environments.
So from a strategy perspective, what are these agencies trying to really do? Government agencies and aerospace and defense companies are always evolving their strategies to be able to deal with this complexity and to help streamline their engineering processes. For example, the Department of Defense (DOD) has published a new adaptive acquisition framework. This pathway is intended for large-scale traditional hardware acquisitions to facilitate rapid and iterative development and delivery of software capability to the user.
RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries
Bryczek: In 2018, the Digital Engineering strategy outlines a vision to modernize how the department designs, develops, delivers, and operates, as well as sustains systems securely and safely. Their vision is to connect people, processes, data, and capabilities across an end-to-end digital enterprise. The International Council on Systems Engineering (INCOSE) published its recent Vision 2035 document, and it is intended to inspire and guide the strategic direction of systems engineering, the practice of systems engineering for the global systems community.
MOSA, the Modular Open Systems Approach, it uses a system architecture that allows major subsystem components at the appropriate level to be incrementally added, removed, and replaced throughout the lifecycle of the major system. The DOD’s systems engineering and architecture group is focusing on modernizing the systems engineering practice. They’re leveraging capabilities from CERC. They’re using MOSA to build systems that can be upgraded and to incorporate new technology faster to respond to emerging threats.
When we look at this in a little bit larger view with this new modernization of the systems engineering approach, the DOD has moved away from visualizing its process using a V model in favor of what truly takes place from a process standpoint, which is that modern systems engineering is highly cyclic. You can see the outermost ring is as close to that old V model, where a concept definition is in the upper right, it moves the system definition through architecture and design and over to V & V and back-to-start around on the next cycle.
What’s important is that there’s a strong emphasis on measuring not just the system being built, but the process that’s building the system, your system’s engineering process and that data and models are at the heart of it all. To the fullest extent, models should be used in favor of documents and data should inform decision-making.
What is the industry saying? There’s a challenge to using data-driven approaches and models. The DOD has highlighted there’s a lack of an integrated approach to the implementation of these systems engineering focus areas, and it’s creating a delay in the full implementation of the digital transformation, which is necessary to ensure relevant guidance and skills.
RELATED: Leading Ground-to-Air Communications Systems Developer Indra Park Air Takes Off with Jama Connect®
Bryczek: Continuing to use legacy tools and approaches is what is making integrated approaches not possible. What is necessary is to take a federated approach to data across the tool ecosystem and to use tools with more robust APIs, and modern architectures that are standards-based. An MBSE approach requires an integrated approach to connect the system models, architecture, and requirements to the program teams the software teams, and the hardware teams. It doesn’t mean to use a siloed system modeling tool and expect those teams to be able to consume and understand that model.
What we hear quite often is, “How do I achieve the benefits of MBSE when no other engineers can access model parameters that they need for downstream decision-making?” Those with technical oversight, chief engineers who have technical oversight and responsibility for program success, executing MBSE, or even just traditional systems engineering commonly raise the following questions, “How do I know if the architecture and system requirements are satisfying all the needs? How do I know if a change in the architecture will impact testing? How do I know if a change in the architecture will impact downstream hardware or software teams? How do I detect unallocated systems architecture and requirements?”
So the question of, “How do I achieve the benefits of MBSE when no other engineers can access model parameters?” can be answered by using traceable MBSE. Now, the reality at most companies is that the end-to-end systems development process is fragmented into domain-specific tools and spreadsheets that have no built-in collaboration. Now, this leads to fragmented requirements traceability and requires significant manual effort through emails and meetings and sometimes luck to try and prevent delays rework, or cost overruns.
Most companies have come to accept the situation as an unchangeable reality given the lack of a single platform to enable this entire process, nor a method to integrate spreadsheets and desktop tools. Using Traceable MBSE, the system model in the modeling tool is joined with the Jama Connect model. Jama Connect is continually calculating traceability and coverage and provides scores that can be used to identify high-risk areas that can be drilled into to determine corrective actions. The system model can detect those changes and the modeling engineers can take the corrective actions.