This post was originally published on January 7, 2022.
Requirements Traceability – How to Go Live
Requirements traceability is required by many industry standards to ensure product quality and safety. The industry standards are based on decades of progress made in systems and quality engineering research with requirements traceability at the core. Benefits from requirements traceability are achieved if and only if traceability is used as a tool during the product development process. These benefits include greatly reduced or eliminated delays, defects, cost overruns, and rework. Here is an overview of the best practice approach to achieve Live Traceability™.
Live Traceability vs. After-the-fact Traceability
Let’s start with some definitions to make sure we are all on the same page. Requirement traceability is defined as tracking the development progress of product requirements from definition and design through development, testing, verification, and validation. There are two forms of requirement traceability: after-the-fact traceability and Live Traceability.
After-the-fact traceability occurs after the product has been developed and is typically a highly manual effort to try and re-create artifacts to demonstrate traceability that should have occurred during the development process but did not. This effort is undertaken solely for complying with industry standards and satisfying auditor requests for demonstration of process maturity.
Live Traceability occurs in real time as the product development process progresses to improve overall productivity (by ensuring engineers across disciplines are always working off the most recent and correct versions) and to reduce the risk of negative product outcomes (delays, defects, rework, cost overruns, recalls, etc.) through early detection of issues. The benefits of early detection of issues are significant. Research by INCOSE found that issues not found until verification and validation are 40 to 110 times more costly than if found during design. For this reason, most companies want Live Traceability but are stuck with legacy tools and spreadsheets that do not support it. Since each engineering discipline is allowed to choose its own tooling, the result is a large number of tools with no relationship rules or mechanisms to create Live Traceability across them.
Live Traceability requires a model of the key process elements and their relationship rules to monitor during the development process. The systems engineering V Model is a useful framework to start with for data object and relationship definition. Jama Connect® uniquely provides a point and click, configurable, relationship rule capability to enable Live Traceability. Below you see a sample relationship rule diagram from Jama Connect. Relationship rules vary by industry and company-specific requirements. Best practice templates are provided to comply with industry standards and configured to meet client-specific needs. The definition of a traceability model forms the foundation for model-based systems engineering since it defines model elements and their relationship to each other in a consistent manner across the entire system architecture.
Step 2: Setup Continuous Sync for Siloed Tools/Spreadsheets
Once the relationship rules are defined, the next step is to set up continuous sync with best-of-breed tools and spreadsheets used by the various engineering disciplines. The traceability diagram below shows a typical example of best-of-breed tools and where they sync in the Jama Connect relationship model to deliver Live Traceability.
Most companies prioritize the areas of the traceability model that are most prone to lead to costly issues in the absence of a continuous sync. Most commonly, these areas are:
Software task management – directly linking the decomposition of requirements into user stories enables Live Traceability through the software development process through testing and defect management. The most common best-of-breed tools used are Jira and Azure Dev Ops.
Test automation – test cases are managed in Jama Connect to align to requirements and ensure traceability across all engineering disciplines with the test automation results sync’d to the traceability model at the verification step. The most common test automation tools are TestRail and qTest.
Risk analysis (DFMEA/FMEA) – is most often conducted in multiple Microsoft Excel spreadsheets and the assumption has been that Live Traceability was not possible with Excel. Jama Connect is the first requirements management solution to enable Live Traceability with Excel functions and spreadsheets. Risk teams can now work in their preferred spreadsheets AND for the first time achieve live traceability to stay in sync with changes made by any engineering team. Ansys Medini is also a supported integration.
Model-based systems engineering (MBSE) – the first step in MBSE is to define a relationship model between all product requirements. Once a relationship model is defined, then specifications can be determined through modeling. Jama Connect uniquely provides model-based requirements to sync logically with a SysML modeling tool like Cameo No Magic. Other requirements management tools do not ensure a model-based approach, which most often leads to inconsistent and conflicting fields across teams and projects and provides no coherent relationship model.
Step 3: Monitor for Exceptions
Live Traceability provides the ability, for the first time, to manage by exception the end-to-end product development process across all engineering disciplines. The traceability model defines expected process behavior that can be compared to actual activity to generate exceptions. These exceptions are the early warning indicators of issues that most often lead to delays, cost overruns, rework, defects, and recalls. Below is a view of our Live Trace Explorer that shows you the LIVE state of development for any level of the development project you choose – from the entire cross-discipline effort down to a specific sub-component. Areas of greatest risk appear in red to show where requirement or verification coverage is lacking. Traceability is now a measurement that can be managed and improved with an overall Traceability Score and coverage and verification percentages..
Benefits of Live Traceability
The main benefits of Live Traceability across best-of-breed tools are as follows:
Reduce the risk of delays, cost overruns, rework, defects, and recalls with early detection of issues through exception management and save 40 to 110 times the cost of issues identified late in the process.
Comply with industry standards with no after-the-fact manual effort.
No disruption to engineering teams that continue working in their chosen best-of-breed tools with no need to change tools, fields, values or processes.
Increase productivity and satisfaction of engineers with the confidence that they are always working on the latest version, reflective of all changes and comments.
LEARN MORE
https://www.jamasoftware.com/media/2022/01/2022-01-07-v2-requirements-traceability-how-to-go-live.jpg5121024Marc Osofsky/media/jama-logo-primary.svgMarc Osofsky2024-10-30 06:00:452024-11-01 12:01:01Requirements Traceability – How to Go Live
Jama Connect and CATIA: Traceable MBSE™ Integration through Cameo DataHub
For teams taking a model-based systems engineering (MBSE) approach to systems development, managing complexity and ensuring traceability are crucial. Jama Software’s integration with CATIA Magic, powered by Cameo DataHub, offers a streamlined solution collaboration between requirements, architectures, and mission needs. This integration bridges the gap between Jama Connect and CATIA’s tools, allowing teams to enable a federated data architecture approach and equip stakeholders with a deeper understanding of the system model.
As a leader in MBSE solutions, CATIA Magic supports SysML standards. Its commitment to following these standards allows for seamless customization to industry-specific needs, making it a powerful choice for complex system engineering projects.
Integration Benefits
This integration enables real-time synchronization of any Jama Connect data or model element with CATIA Magic, ensuring that teams can collaborate effectively while maintaining traceability across both tools. This connection simplifies complex workflows and enhances the accuracy of a system model’s requirements and architecture, eliminating manual work and reducing errors.
By supporting custom data mappings, bidirectional synchronization, and standard authentication methods, this integration empowers system engineers to trace changes, visualize updates, and maintain alignment across their tools — ensuring not only more informed decision making but also an increased confidence in the system design, and a more efficient engineering process.
Capabilities from a dedicated requirements management tool such as Jama Connect have built-in collaboration, configuration management, baselines, managing traceability across multiple levels of objects, managing the verification and validation activities, controlling access and change to objects using role-based permissions, and showing real-time workflow states at the object level. Jama Connect’s built-in workflow engine and dashboards give any stakeholder a 1000-foot view, a measurable view of status and progress, and exceptions to the defined systems engineering process.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Cary Bryczek, Matt Macias, Kenzie Jonsson, and Decoteau Wilkerson.
https://www.jamasoftware.com/media/2024/09/2024-9-24-jama-connect-with-catia-via-cameo-datahub.png512986Jama Software/media/jama-logo-primary.svgJama Software2024-09-24 03:00:492024-10-04 10:06:18Jama Connect® and CATIA: Traceable MBSE™ Integration through Cameo DataHub
This post was originally published December 18, 2020, and has been recently updated.
Digital Thread Defined
Digital Thread Definition – a data-driven architecture that links together information generated from across the product lifecycle and is envisioned to be the primary or authoritative data and communication platform for a company’s products at any instance of time.
This is the best definition of Digital Thread we are aware of and is from an excellent 2018 paper by Singh and Willcox at MIT entitled Engineering with a Digital Thread. The term Digital Thread was first used in the 2006 with the publication of the Global Horizons report from USAF Global Science and Technology Vision task force. (If you have an earlier reference please share in the comments). In this document, Digital Thread is defined as “the use of digital tools and representations for design, evaluation, and life cycle management.”
As with many business terms, Digital Thread has now become over-used by consultants and software vendors. The definition of it — and how it differs from Digital Twin — have been interspersed with more general concepts of integration, simulation, data, and analytics and has lost the original, more precise meaning.
Digital Thread Components
Let’s break down the definition of Digital Thread into its components to better understand the concept and share the most common approaches we see as companies move to make the Digital Thread a reality. Here is the definition breakdown:
1 – a data-driven architecture
This recognizes that the use of a single common platform is impossible across all engineering disciplines (software, hardware, electrical, systems, risk, QA, etc.). Instead, a data-driven approach is required that determines the key information required from multiple tools. It’s important to remember that data-driven does not mean “gather all your data” but rather that you should be using data to answer questions. In other words, do not fall into the trap of tool focus, but rather focus on the questions and collect data to provide the answer.
2 – that links together information generated from across the product lifecycle
From initial requirement definition through to product release, significant information is generated across multiple tools. The challenge is to identify what information is most relevant and how to best link the information to make it actionable. The most common link we see is the definition of value to be delivered (user and system requirements). The most typical information captured across the product lifecycle are process statuses and exceptions (e.g., requirements that have not been approved, require rework, or are not fully addressed, gaps in testing or risk analyses). By linking these process statuses to requirements and tracking them through the product lifecycle it is possible to reduce the risk of negative product outcomes (e.g., delays, defects, cost overruns).
3 – and is envisioned to be the primary or authoritative data and communication platform
Most companies refer to this as a “system of record” or a “single version of the truth.” A Digital Thread is much more than simply integration or a data lake. By tying the definition of what is to be delivered (requirements) to the most critical downstream process meta-data, a Digital Thread create the ability to understand the state of the product development process, what risks are visible and what corrective actions should be considered. Without a Digital Thread, a company is flying blind in terms of the risks it faces in product development.
4 – or a company’s products at any instance of time
For a Digital Thread to be truly useful it must always reflect the current state of the product development process. The value is in seeing the product development process for the first time across fragmented teams and tools, to be able to identify process exceptions and early indicators of potential downstream risks. A static database of days or weeks old data will not be sufficient for a process that is changing rapidly across multiple, siloed teams.
Why the Digital Thread is So Important
The product development process is often fragmented across siloed teams and tools which leads to significant risk of product delays, defects, cost overruns, failed verification and validation, recalls, etc. End-to-end process visibility is required for better cross-team collaboration and the early detection of anomalies to reduce these risks. To solve for this, organizations often attempt to force everyone to use one common software platform, forgoing their choice best-of-breed tools. This solution is neither practical — nor particularly realistic — since engineers are (and should continue to be) allowed to choose discipline-specific tooling which optimize their activities.
What is required is a loosely coupled approach that ties together the necessary metadata across these disparate tools in a way that connects the desired outcome (user and system requirements) to downstream activities – the Digital Thread. The Digital Thread is the best approach to reduce the risk of negative product outcomes while preserving engineering autonomy and productivity.
Click here to learn how Jama Connect’s Live Traceability™ enables a digital thread.
https://www.jamasoftware.com/media/2020/12/2020-12-18-Digital-Thread-MarcO.jpg5121024Marc Osofsky/media/jama-logo-primary.svgMarc Osofsky2024-09-18 03:00:232024-09-26 11:31:10What is the Definition of a Digital Thread?
In this blog, we’ll recap our recent webinar, “Elevating MBSE with SysML: Jama Connect® and CATIA Magic in Action” – Click HERE to watch it in its entirety.
Elevating MBSE with SysML: Jama Connect® and CATIA Magic in Action
What happens when Jama Software®’s Traceable MBSE™ combines with Dassault Systèmes’ enterprise and system architecture modeling expertise in systems engineering?
This powerful and intuitive integration between CATIA/Cameo Systems Modeler and Jama Connect® aligns business and engineering, bridging the gap between requirements management, system architecture, design, and product management.
Key trends shaping the future of MBSE across the aerospace & defense industry
Challenges keeping Systems Engineers up at night
The impact of Jama Connect Traceable MBSE in defense applications
How Cameo Systems Engineering enhances system architecture
A live demonstration of Cameo DataHub’s integration with Jama Connect
Don’t miss this opportunity to see how this integration can transform your MBSE approach, driving success from concept to deployment.
Below is an abbreviated transcript of our webinar.
Cary Bryczek: To kick things off, I want to set the stage with some trends across the aerospace and defense industry that we’re seeing. I’ll talk about how those trends are creating challenges for chief engineers and describing what keeps them up at night, then I’ll set the stage for Saulius’s presentation by showing you what Jama Connect’s Traceable MBSE looks like and how it’s designed to solve those challenges. Saulius is going to take you on a deeper dive to show you how system models and Jama Connect interoperate.
So in the aerospace and defense industry, we are developing a new system that has complexity that far exceeds commercial product development. For example, the FAA’s program to develop the Unmanned Aircraft Traffic Management system involves not just a pilot and drone, but is designed to enable autonomous and semi-autonomous operation of multiple air systems, including the passenger and cargo delivery, in a really tightly integrated civil airspace. The elements in blue on the diagram are all distinct systems of their own, and the new traffic management system needs to integrate communications and data across all of those systems to provide this new capability.
In the highly constrained environment of outer space, for example, NASA’s Cislunar and I’m pretty sure the Artemis programs are focusing on the operation and survivability of autonomous systems. To develop a space system, NASA doesn’t do this in their own silo, but they have lots and lots of contracts and companies that they work with deliver parts of the system, just like in the DoD. For example, you have Blue Origin. They are developing a friction stir additive manufacturing part of the system in partnership with Langley, right? You have Redwire out of Erie, Colorado. They are developing another in-space manufacturing system. You have Canopy out of Denver. Colorado seems to be a popular place for space. They’re developing low-cost reusable thermal protection systems, right? And there’s really dozens more. The Cislunar and the Artemis programs are developing ecosystems and the ecosystems of those partners, right?
In the government agencies and aerospace and defense companies, they’re always evolving their strategies to be able to deal with this high degree of complexity to help streamline their engineering processes. For example, the DoD, they have published a new adaptive acquisition framework. So even not just in the engineering parts of it but the acquisition parts of it as well, there’s a new framework. This particular pathway is intended for large-scale traditional hardware acquisitions to help facilitate rapid and iterative delivery, like what the software capability programs are doing.
In 2018, we had the Digital Engineering Strategy outlining a vision to modernize how DoD designs develops, delivers, operates, and even sustains systems, right? By connecting people and process and data and developing these end-to-end digital enterprises.
The DoD’s Systems Engineering and Architecture group within the DoD itself is focusing on modernizing the systems engineering practice and they’re leveraging the capabilities coming out of SERC and MOSA to build systems that can be upgraded to incorporate new technology and respond to emerging threats, right?
With this new modernization of the SE approach, and now I know this is sort of an eye chart, you guys can look at it after the fact, the DoD has moved away from visualizing its process using that shape of the V model in favor of what more realistically takes place from a process standpoint, which is that modern systems engineering is highly cyclic in nature. Now, the outermost ring is as close to what the old V model, where concept definition is in the upper left, moves to system definition through architecture and design, over to V&V, and back around to start the next cycle. What’s important is that there’s a strong emphasis on measuring not just the system being built, but the process to build that system 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 the decision-making.
There really is a challenge to using a data-driven approach in the models. The DoD, I love this quote, “There’s a lack of an integrated approach to implementing systems engineering focus areas that’s creating a delay in implementing the digital transformation, which is necessary to ensure relevant guidance, skills, and training are available to deliver a disciplined approach to acquiring a weapon system.” Continuing to use legacy tools and approaches is what making integrated approaches gravely difficult. What’s necessary is to take a federated approach to data across the tool ecosystem and use tools with robust APIs, modern architectures that are standards-based. An MBSE approach requires an integrated approach to connect that system model’s architecture and requirements to program teams and software and hardware teams. It doesn’t mean using a siloed system modeling tool and expect those teams to be able to consume and understand that model. In fact, kind of what I hear a lot is, “How do I achieve the benefits of MBSE when no other engineers can access model parameters they need to use to make downstream decision-making, and how do I make decisions on tests and other things that’s downstream from the system model?” I hear that quite a lot.
Bryczek: Those with technical oversight and responsibility for program success who are executing MBSE or even just traditional systems engineering commonly raise these following questions. This is what I think keeps chief engineers up at night. “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 those needs?” “How do I know if a change in the architecture will impact hardware or software teams?” And, “How do I streamline model design reviews?” I have a fourth one, too, “How do I detect unallocated systems architecture and requirements that sort of transcends the system model area and goes into the software models and the hardware models?” So that’s another favorite that I have.
So these questions really, we think, can be answered using what we term Traceable MBSE. The reality at most companies is that the end-to-end systems development processes is fragmented into domain-specific tools and spreadsheets that really don’t have a lot of collaboration or any, and this leads to fragmented requirements traceability and requires significant manual effort through emails and meetings and maybe even luck to try and prevent delays, defects, rework, cost overruns, right? Most companies have come to accept this 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 corrective action.
Keep in mind that model-based systems engineering is more than using the power of SysML. It is powerful. Systems engineering’s superpower to enable digital transformation comes when it’s able to connect to the entire development effort and facilitate software and mechanical teams with the ability to align their efforts to the system model, systems engineers being able to manage the state of development across the disciplines and automatically identifying risks through all stages of development.
So let’s maybe see what this looks like in Jama [Connect.] This is Jama Connect in a web browser. I’m showing a Traceable MBSE project for development of a cube set. In it, I’m managing the end-to-end development of the program mission goals and objectives, stakeholder needs, concept of operations, system requirements, subsystems, software and hardware requirements, architecture, safety risks, verification and validation, and even user stories from Jira. Jama [Connect] is going to provide that measurable end-to-end traceability for all of their elements. Their version control and baselines provide design, review, and approval, plus make the data visible onto a series of dashboards.
All the interactions with Jama [Connect] are done in this web browser. Just to give you a little bit of navigation overview, if you’ve never seen Jama [Connect], you can see the data. You can organize the data pretty much however you want. You’re not constrained to how you want to call the data. Want to look inside stuff, you can open up and look inside the dashboards. The series of dashboards can be laid out however you want. You can have multiple dashboards. So this is my main one. I want to see a trace exception dashboard, I’m able to just organize them how I want, surface up that information. And they’re live too, so if I wanted to go and look at what any of these are, show me my objectives, needs, or goals, I can just click on them and it takes me pretty much right to where I want to be.
One of the things that makes Jama [Connect] special is the ability to define a data model for the information that you’re going to be managing in the model or the Jama [Connect] project and define how the traces are related together. And then our Live Trace Explorer™ is used to show real-time progress against expected traceability. So I open up my Live Trace Explorer for this particular project. The Live Trace Explorer is used to show the real-time state of progress of all of the items that are being managed in the system against the expected traceability according to those rule sets. When integrated with system modeling tools, like managing architecture, Jira managing the flow of tasks, using Live Trace Explorer, you can obtain this holistic view of quality across your entire system development and software factory process.
So this left-hand side shows requirements coverage and the right-hand side of the Live Trace Explorer shows test coverage, similar to a V model. Here you can see the program system-level requirements. So here we scroll down, we have the program system level requirements and all of the relationships established for traceability. This is based on the project’s traceability rule set, remember? Your project might use different names than what you see here. You’re not really constrained to using what comes out-of-the-box Jama [Connect] at all.
Bryczek: The Trace Explorer in the upper right, this Trace Score™ shows an overall traceability score for your project that you can use to gauge how quality changes, hopefully improves over time. So all of these metrics are real-time from what’s happening right now, and so 64% traceability, this is probably maybe early to midstream in development. We’re still seeing people still establishing traceability, right? But by increasing your traceability score, we really hope to reduce the risk of defects, cost overruns, and delays.
So what about some of those questions that keep chief engineers and program managers up at night? What about the ones that we were asked about? So question one is, “How do I know if architecture and system requirements are satisfying all the needs?” This is tracked in our Live Trace Explorer as a percentage of coverage between the linkages. So here we see a 55% coverage between these stakeholder expectations, which we have 36 stakeholder expectations, so 55% traceability established so far between those. And we only have, and if you scroll down, if you want to see what the architecture is, the architecture, we only have 50% coverage between the architecture and requirements.
So what about, “How do I know if a change in architecture is going to impact testing”? You can really easily see that here, the changes between what’s happening to testing. You can even see a percentage of the suspect changes. So right now, I might’ve already changed some of the requirements of your architecture. 11% is showing suspect. Right now, I don’t have a lot of test plan coverage. Still kind of in the early phases as well.
What about the third question, “How do I know if a change in architecture will impact hardware or software teams?” Right? Again, you can easily see any of the downstream traces to different things. And this is live, too, so if I wanted to see exactly, show me those objects, I can just click, it’s all interactive, and see exactly what the traceability between architecture and system requirements look like. I want to add more information to the view, maybe I want to see what the rationale is or the status, I can add that kind of view really super easily to my view. Jama [Connect] is really designed to make it easy for anyone to come in, understand what’s going on in the program, click and see instant traceability based on what you’re looking at.
So another question is, “How do I detect unallocated system architecture and requirements?” Unallocated activity can be used by running a query. So I have a filter that says, “Show me all of the unallocated architecture.” So I have four architectural elements that have no traces for requirements, and if I turn my trace view on, you can see these are just standalone objects. There’s no traceability either up or downstream to requirements of any kind. We really want to make this as easy as possible, as powerful as possible for people to measure in real time what does their traceability look like, how do I use traceability to effectively enhance the process and remediate actions before they might possibly happen.
So in summary, as systems development continues to increase in velocity, engineering leaders and program managers really need answers to those really tough questions. System modeling tools alone don’t easily provide that. With Jama [Connect]’s Live Trace Explorer, this is providing that real-time traceability score. Our approach for managing and controlling process is using actual data. Jama [Connect] is really the only one that can provide that holistic view. Very exciting.
And now, Saulius would love to show us how Dassault is connecting Jama [Connect] and CATIA Magic.
Saulius Pavalkis: So you saw the Jama [Connect]site. Now we’ll talk about the integration part with CATIA Magic leading SysML and MBSE solution for system architecture. So what is the reason, what is the differentiator, why it is the leading solution? So this was first product to support SysML v1, and pretty much all the versions from that was supported with the complete standard, following already for almost 20 years, as we can see, of the SysML appearance. Now we’ll be working on SysML v2, which will be another evolution and, again, the same goals. We became de facto standard for the many different project types in the industry, and pretty much the quality and scalability of the product and strict following of the standard enabled that. You can’t support all the big clients with the custom solutions unless you will follow some standard approach which allows to customize for each specific one later on.
And that brings us to our core values. So it is completely open. Also, as we will see here also from OpenAPI side, because that enabled us integrate in the proper way with the requirement management solution, Jama Software.
Standard compliance, another big deal because if you support the standard, maybe it is a bit harder than to integrate specifically for specific needs, right? But once you follow that, it’ll apply for all the different purposes, plus it will be clear which part of the integration needs to be updated with the standard update and with the tool development, which is not the case when you don’t follow the standards, right?
Efficiency and user-friendliness, ability to customize, and that’s like one of the most significant values because again, if you follow the standard, you get the 90% for the industry needs, but then you need to customize for specific industry, like what type of the data you want, as you saw in the Jama [Connect], you can select data set, what’s needed for specific project, have ability to create your own data set and then synchronize only on that data set and work on that model.
We support mostly system engineering community needs, and that is pretty much 90% or something of the product, because standard compliance is one thing, but then actually system engineering to enable better results with the model than PowerPoint, better tables and data management, and Excel is the key differentiator when you want to work with the model sufficiently.
The big part is continuity to disciplines. As you saw, traceability is big part of the Jama Software solution. Same for us, we dedicate most the attention for these integrations with the rest of the ecosystem. This is perhaps one of the most popular integrations, maybe the most popular integrations which we have. But in general, these are disciplines in engineering and analysis.
And also system engineering life cycle, as Cary mentioned, design reviews, this is very important process. Every organization goes through it and also in collaboration with suppliers, and that’s technically insight but also other processes which requires formal process with the approvals and baselines.
So talking about this integration specifically, we are using DataHub as integration framework. What are the highlights? It comes as a plugin actually for CATIA Magic. It’s built in in CATIA Magic. And this integration is also not an exception. It’s using this major integration framework, which is mostly for requirement tools integration. One of the most used integrations which we have is actually requirement management tools, and the most useful integration, used integration likely will be Jama Software integration from requirements management side. It provides similar experience for all the integrations and already set up operations which are common for the users, not to expect some surprises, but it is also redesigned to be more optimal, more user-friendly, and supports the standards like OSLC v2, but in our case, we are using direct API to Jama Connect, which is always the best case when you have ability to leverage that, and that shows again the openness of Jama Software and CATIA Magic.
Pavalkis: The workflow is very simple, so pretty much you connect the data source to Jama [Connect]. Jama [Connect] can be on the cloud, on premises. You select the scope for the synchronization. We support only one operation, copy and synchronize, which is by far the most popular one from all the experience we have. We then select the mapping based on the data sets selected, you know, could be new requirement types, could be new relations and so, and then we synchronize, first of all, by copying the data, but later on by checking changes, seeing the changes available and acting on those changes, synchronizing and acting on those changes with suspect links in our site. And also, on top of that, we support diagrams as an image interchange, which is a big deal because then you can actually work independently without all these requiring to see another solution for the part of the data.
Now, when we work together, what are the key connection highlights? So we support advanced authentication methods, simple authentication, and OAuth 2.0. On project selection, we select the data which will be available, what type of data will be available, and that data will allow us to map just to those elements from Jama Software type and see them synchronized to CATIA Magic using DataHub. As you can see here, we have this Cameo DataHub view in CATIA Magic, Cameo, and it is based on the same selected data in Jama Software for the project, right? And then you can see it with the icons with the exact representation that allows you to have the seamless interface.
The leverage, the same dedicated UI for identifying changes, what’s new, what is modified, move, delete it out of scope, and this allows us to see the change before synchronizing, so you can even apply element-by-element synchronization and, based on the direction of synchronization, you can choose one or another way to synchronize, which is always good to choose in advance not to have the conflicts on the authoritative source of truth.
We have number of items, type of elements in Jama Software which we synchronize. You can see the full list. It’s far more than just requirement, the different other types of attachments and so on. We allow, as I said before, to import the images to CATIA Magic and from CATIA Magic export diagrams as images to Jama, which allows you to review the diagrams in Jama Software and also see the architecture views from Jama Software and CATIA Magic and act on them.
https://www.jamasoftware.com/media/2024/09/Elevating-MBSE-with-SysML-Jama-Connect®-and-CATIA-Magic-in-Action-1.png5121024Cary Bryczek/media/jama-logo-primary.svgCary Bryczek2024-09-17 03:00:032024-09-19 11:03:35[Webinar Recap] Elevating MBSE with SysML: Jama Connect® and CATIA Magic in Action
DOD 5000 Series
DOD 5000 Series consists of policy guidance and is backed by a collection of directives that describe a disciplined management approach for acquiring systems and materiel to satisfy valid military needs.
Six pathways of the adaptive acquisition framework: urgent capability acquisition; middle tier of acquisition (MTA); major capability acquisition; software acquisition; defense business systems (DBS); and defense acquisition of services. Up until a few years ago, it used to be that every program large and small had to follow the exact same acquisition process. Today, programs that are small and short-lived can follow a different process than that of a large multi-decade weapons system acquisition program. DOD 5000.02 policy encourages program managers to tailor, combine, and transition between pathways to create their own program strategies.
All programs regardless of the pathway share functional areas that must be considered during program execution. Acquisition Intelligence, Cybersecurity, Intellectual Property (IP) Policy, Mission Engineering, Systems Engineering, and Test & Evaluation are key areas every program must practice. Digital Engineering is a key constituent of program execution, and its vision is articulated by the Department of Defense 2018 Digital Engineering Strategy. It clearly highlights model-based systems engineering (MBSE) as a new approach to take. Digital Engineering crosses these functional areas and is where Jama Connect® assists program managers the most.
Jama Connect® gives program managers and their acquisition team the ability to use Digital Engineering MBSE right from the start in an easy-to-use browser interface
The early phases of all DOD 5000.02 acquisition pathways require the definition of mission capabilities and needs. Instead of capturing this information in Word, Excel, or a SysML tool which requires a deep level of expertise; the Jama Connect solution will provide an Excel and Word-like experience but also segregate data as discrete model elements. An early acquisition MBSE approach in Jama Connect provides numerous benefits to the program team such as categorization of information; prioritization; version history of changes; status monitoring through workflow; real-time metrics on dashboards; exportable dashboard widgets for PowerPoint presentations; built-in document generation; activity monitoring; and more.
These MBSE data capabilities provide real-time monitoring of progress of the definition of mission needs and capabilities and more importantly gives all stakeholders the opportunity to participate in the capture and writing of the data. The learning curve of Jama Connect is five minutes to half a day compared to six months for SysML tools. This is especially important when there are urgent operational needs and other quick reaction capabilities need to be acquired. DoDD 5000.71 and DoDI 5000.81 both provide instruction for program management techniques to follow.
Jama Connect dashboard widgets.
DOD 5000.02 Acquisition Lifecycles
DOD 5000.02 instructions call for numerous reviews to take place throughout the acquisition lifecycles.
Acquisition Intelligence example use case: DOD 5000.86 Instruction provides policy and guidance on how to integrate intelligence information into the acquisition lifecycle. Typically, this is performed as a siloed activity with information captured in documents, passed back and forth, and reviews taking place in face-to-face meetings. Jama Connect enables the extension of the needs and requirements in the MBSE data model to threats, adversary capabilities, and adversary intentions. Jama Connect’s Live Traceability™ gives the program and intelligence teams the ability to share information and analyze it in a single model. Contextual collaboration mechanisms such as Review Center reduce cycle times spent on document review and approval. This integration of intelligence supports: (1) Characterization of the threat. (2) Identification of intelligence supportability plans, risks, and cost drivers. (3) Residual risk to inform stakeholders.
Cybersecurity example use case: DOD 5000.90 Instruction provides policy and guidance on how to incorporate cyber threat information produced by the Intelligence Community in development of their cyber security strategy and assessment of risk. Jama Connect lets the acquisition team see the relationships between designs and architectures and the identified risks. Live Traceability enables more informed decision making and could act as a conduit to the risk management framework (RMF) system. When new threats emerge, Jama Connect can provide instant impact analysis to a program’s existing mission requirements.
Systems Engineering example: DoDI 5000.88 begins by stating that engineering begins “at the identification of a military need and continues throughout sustainment of the end item.” Jama Connect can be used during all phases of the acquisition lifecycle and allows a systems engineering discipline to become central to program management rather than a siloed activity. Mission needs are captured in Jama Connect as discrete elements rather than Word documents or PowerPoint slides and can be reviewed, approved, and captured in the concept baseline. An element approach (aka digital engineering) allows for the easy consumption of data by digital tools in the tool ecosystem.
As ME products are developed in response to the mission needs and provide mission-based inputs to the requirements process, Jama Connect will establish trace relationships between needs, ME products, and the requirements. Live Traceability gives the ability for any stakeholder at any time to see the most up to date and complete upstream and downstream information for any requirement — no matter the stage of systems development or how many siloed tools and teams it spans. This enables the engineering process to be managed through data, and its performance improved in real time.
DoDI5000.88 calls for many technical and assessments throughout the life of a program. Digital engineering reviews in Jama Connect give the technical and non-technical engineer to not only redline, comment on, provide approval for the data itself, but allows for teams to give traceable reference. If the technical review is that of requirements, then reviewers would have the context to see the related mission needs, any analysis, architecture, any tests, as well as understand the evolution of change to each individual requirement in that review. Reviews in this manner provide significant reduction of cycle times and retains a traceable audit trail of commentors and approvers.
Jama Connect Review Center, participant progress view.
Jama Connect can provide capabilities to assist government program management teams execute parts of the adaptive acquisition framework and tie together information via Live Traceability and collaboration mechanisms. Program decisions are informed by real time data and is accessible to engineering and non-engineering stakeholders alike.
In summary, there are many opportunities to use Jama Connect as a key enabler of Digital Engineering across all phases of the adaptive acquisition framework no matter which pathway is chosen.
https://www.jamasoftware.com/media/2022/11/2022-10-25-jama-connect-helps-program-managers-with-dod-5000-1-1.jpg5121024Cary Bryczek/media/jama-logo-primary.svgCary Bryczek2022-11-17 03:00:132024-01-18 13:06:21How Jama Connect Helps Program Managers with DOD 5000 Adaptive Acquisition Framework
Jama Software is always on the lookout for news and content to benefit and inform our industry partners. As such, we’ve curated a series of articles that we found insightful. In this blog post, we share content sourced from Lifecycle Insights – Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™ – which was originally published on August 17, 2022, by John McMillan.
Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™
How does Jama Software®’s approach to managing the vast array of complex engineering requirements provide organizations a competitive advantage? Their approach is a software solution developed specifically to provide unified requirements management and traceability across organization development processes whether that be the traditional V-model, Waterfall, Agile, or otherwise. Jama Connect requirements management software with Live Traceability was designed to help development and engineering organizations improve quality, reduce rework, ensure compliance, and get high-quality complex products, systems, and software to market faster and on budget.
Historically in product development, each engineering discipline utilizes tools that are specifically suited to maximize their ability to be innovative and productive in their own design space. Communication between other disciplines and the broader organization however has historically been siloed or fragmented and often managed through “throw-over-the-wall” manual approaches. Those approaches are error-prone and often result in discovering late-stage issues downstream that result in design rework, delay product delivery, and create cost overruns that impact the organizations’ bottom line.
The Cost of Discovering Late-Stage Issues
When late-stage issues are discovered during integration testing, systems testing, and during final acceptance testing they are expensive to fix. Jama Connect platform was developed to enable organizations to detect and correct requirement and testing issues and solve disjointed discipline problems. This is provided through a requirements management platform designed specifically to help engineering organizations align people, processes, and tools in one concise application early on and throughout product development- when the cost of change is lowest.
Jama Connect was designed to provide unique real-time visibility and actionable insights for the end-to-end product, systems, and software development processes. Within the application, users develop relationship models between each discipline’s tools by way of data elements. These data elements are connected with direct tool integrations with Live Traceability. Once the flow of each element’s connections is defined and reflected throughout the system – should a data element be modified, the connected element stakeholders are alerted, and each discipline can review and address any changes accordingly. The application’s unique open architecture allows integrations with a range of premium solutions across the full ALM-PLM tool ecosystem.
Jama Connects list of supported tools and plug-in integrations for Live Traceability is already quite extensive and is growing.
For Design and Simulation model-based requirements management Connect seamlessly integrates with MBSE and SysML tools including Ansys, MathWorks, Enterprise Architecture, and Catia’s No Magic.
For Task Management, Live Traceability is directly supported for Jira, Bugzilla, Azure DevOps, and TFS without any changes required by software developers’ preferred tools, methodology, or field values.
For PLM and PLE link requirements to hardware specifications and product line engineering for traceability and impact analysis are seamlessly supported for Teamcenter, Windchill, Aras, Pure-Systems, and BigLever.
For Test Automation, live trace requirements and test cases to automated testing results are supported from tools including Tricentis, Ansys, LDRA, TestRail, ZEPHYR, Vector, Jenkins, Bugzilla, and Parasoft.
For Risk Management, traceability is supported from Ansys FMEA/DFMEA calculations as well as Microsoft Excel including functions and spreadsheets, is also supported without any changes required to Risk team’s tooling or approaches.
For DevOps, Live Traceability is extended down to source code with applications including GitLab, GitHub, and Azure DevOps with no changes required to software developers’ tools or methodologies.
Though Jama Connect provides users with the ability to develop custom model system frameworks, it also includes the frameworks for plans, templates, and checklists that are specifically aligned to industry standards for medical devices, automotive, semiconductor, aerospace, defense/government, software development, and industrial manufacturing. In addition, an extensive list of industry standards and regulations are supported including ISO, IEC, FDA, EU, SEBoK, ARP, DO, and more. These industry-specific standards help organizations ensure end-to-end compliance, mitigate risk, and overall process improvement guidance.
Addressing risk management with system analysis that is tailored to each product’s industry standards and regulations, “left-shifts” risk management throughout the product’s development flow and in turn serves as an integral part of the product lifecycle process. Organizations can standardize and integrate their own risk analysis, evaluation, and risk management processes within Jama Connect’s platform to create a single source of truth for everything risk related.
In addition to risk management, Jama Connect provides critical verification and validation requirements for complex systems via test management. The tool supports customized reporting for proof of regulatory compliance and performs manual user-acceptance testing to ensure products are designed with end-users in mind. The tool generates links to disparate processes, sources, and people that increase visibility and simplifies the user’s path to compliance with traceability of tests back to its requirement. It also traces failed tests to new and existing defects for quick resolution, enabling users to reuse validated requirements saving time when testing consistent features across products.
MBSE (Model Based System Engineering) is another key area that Jama Connect provides a streamlined and collaborative data-driven approach to in the product development cycle. Jama Connect’s Traceable MBSE™ platform combines requirements, architectures, behaviors, verification, and validation into a single model of the system by applying structure and rules for data and a consistent interface language between the parts of the system. The MBSE platform is designed to help organizations formalize the development, integration, and use of models to inform enterprise and program decision-making. It also allows non-technical stakeholders to visualize a model of the system of interest and interact with its data in familiar views like documents and spreadsheets.
A leading problem that product engineering organizations face is complying with traceability spanning siloed teams and tools (e.g., design, hardware, software, test, risk, quality) creating an increased risk of negative outcomes such as extensive rework, delays, & cost overruns. Requirements traceability across the entire systems development lifecycle is a core tenant of the systems engineering discipline and underpins industry standards to ensure higher quality, faster cycle times, and less costly rework.
RELATED
https://www.jamasoftware.com/media/2022/09/2022-09-20-jama-connect-accelerating-systems-development-1.jpg5121024Decoteau Wilkerson/media/jama-logo-primary.svgDecoteau Wilkerson2022-09-20 03:00:382024-07-10 15:51:07Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™
In this blog, we recap a webinar discussing Best Practices for Data Migration Towards MBSE (model-based system engineering.)
Data is one of the most valuable assets for organizations, but are we giving it enough attention? The prospect of moving to Model-Based Systems Engineering (MBSE) is tantalizing but often seems difficult when considering the move from existing engineering assets.
In this webinar, Richard Watson, VP Practice Director at Jama Software, will discuss this topic and give best practices on how to formalize the process of MBSE migration to reduce risk of data loss. He will also walk through the risks of legacy requirements management tools and provide solutions for migration.
In this session we will cover:
What MBSE is and how it differs from SysML
Benefits of building a common data model for engineering
How to approach moving data towards MBSE
Best practices for data migration when moving away from legacy solutions
Below is an abbreviated transcript and a recording of our webinar.
Best Practices for Data Migration Towards MBSE
Richard Watson: Hi, everybody. Today, we’re going to look at what MBSE is, and also, how you can get data into MBSE to provide benefits to your organization to get more consistency. So we’re going to jump straight into looking a little bit about what exactly is MBSE. So MBSE, model-based systems engineering, is something that is a concept come up from the OMG. So I thought it would be a good idea to give you their definition. I’m going to read it out. It’s the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design for… Oh, wait a minute. So, looking at this words, it’s really, really complicated to read, and really, by the end of it, you don’t fully understand well what actually is model-based systems engineering.
If you read between the lines, model-based systems engineering is the elimination of documents to combine all of your different engineering datas. So that’s requirements, architecture, behavior, verification, and validation into single data-driven model environments, all tied together with relationships. So, many people think MBSE is modeling, and modeling does form part of it but it’s not only visual modeling. It’s actually data modeling.
If we take another angle of what is MBSE, again, lots of words, this is, for this time, from Lou Wheatcraft. Lou is co-chair for the INCOSE’s Requirements Working Group, which is the largest working group in INCOSE. He explains that MBSE can’t be effectively practiced when viewed from just one perspective. Now, that means, if you do just look at MBSE from a modeling perspective, you don’t see the whole of MBSE. If you just look at MBSE from a requirements perspective, you don’t see the whole of MBSE. So, it’s lots of different types of data interconnected together with relationships, viewed from different angles or dimensions.
Drawing an Information Model
Richard Watson: I’ve tried to draw this in a picture. So here you can see the different site types of data that you might have, but we all know that you can’t look at architecture without seeing how it ties to behavior. You can’t do verification without seeing how it ties to requirements. All of these different disciplines tie themselves together, and they tie themselves together with relationships. Okay, this test case must verify that requirement or this architecture realizes that requirement, this design iterates that architecture. Once you understand how your data relates together, you can draw an information model. And that information model, the bit in the middle, is an MBSE systems model. This is MBSE, not the model itself, but the fact that it’s data and relationships with between data.
This is tool agnostic, you’ve not looked at any systems that will manipulate this yet. Once you have an understanding of all of the different engineering data in your organization, then you can break it down and say, “Well, what would be the best tool to look at and manipulate the data in your MBSE framework?” So you might have requirements, tools, modeling tools, change management systems, development tools, et cetera. All of those different applications will have some visibility into your MBSE data model. And collectively, this is MBSE. So MBSE is a collection of all of these different systems interacting with all of your engineering data and making sure that when you’re sitting in any of these systems, be it requirements, design, test, deployment, simulation, you have access, not just to the data that that system itself manages, but also you have a view of the relationships to the data that sits inside of other systems. So from the design, you can see relationships to the requirements. From simulation, you can see relationships back to the design, back to the requirements. So, MBSE is the data model-based systems engineering.
So if you’ve followed so far, it’s quite a strong structure, and once you have an understanding of it and once you can move your organization towards it, it brings a lot of benefits. Jama Software have actually produced an MBSE framework, it’s almost like a kick starting your process. So you can use Jama Software to have a beginning of an understanding of what your MBSE data model should look like. And then you can look to figuring out which aspects of it are tied to different tools to manipulate your engineering information. The benefit of that framework is that, it saves you time and it accelerates the speed that you can get to actually doing some engineering and the speed that you can produce actual systems at the end. It makes requirements and all of the data, all of the relationships between the data accessible across your organization and anybody that you work with. So these frameworks are a really good way of accelerating that process.
How do we get your legacy data into an MBSE framework?
Richard Watson: But there’s a big question. So if you start MBSE framework, is that assuming that you’re going to start with a blank page, that you’re going to start without any information or any data? And of course, it’s very rare these days for an organization or a project to sit in a room and say, “Right, we’ve got absolutely nothing. What are we going to create today?” More commonly, we’re finding that projects build themselves from other projects and existing datas.
So now, not only are you understanding what is an MBSE framework and how does your engineering data relate to each other, but also you’ve got existing data. How do you get that existing data into your MBSE framework, such that then you’ve got a consistent set of data that you can deploy to your teams? Consistent data is very significant because, firstly, it makes it far cheaper for your engineers. Engineers can move from project to project and understand what the data should look like. It also makes it far quicker to integrate other systems too. So you do want this consistent data approach, this model-based systems engineering approach, but you don’t want to forget your legacy, your original data.
So let’s see how we make that switch. How do we get your legacy data into an MBSE framework? If you consider the value of your data, it’s far higher, typically, than money that you’ve invested in anything else. The money that you spend in the tools to manipulate your data around MBSE, actually they’re not expensive compared to the value of the actual data that you’re manipulating. One reason migration typically either fails or it fails to leave users satisfied is that, we are not giving the data the respect it demands and deserves because of its value. Organizations have approached migration literally just with a give-it-a-go attitude. What I mean by that is, they simply press the button and say, “Okay, migrate.” They migrate until something goes wrong, and then they fix the thing that goes wrong.
Jama Connect® for MBSE
Richard Watson: And then they press the button again, and say, “Well, continue to migrate,” and they continue to do that over and over and over again until the migration process is finished. The difficulty with that is, it’s very, very difficult to predict how long will that migration process take. And even once you’ve done migration using this mechanism, when you go to your users, your users will be very distrusting because they will have witnessed the process that you just went through to do data migration, and they’ll have very little reassurance that the data that’s in the new system has any or all of the resemblance of the data that it had in your original place. So for example, if you’re migrating data from DOORS into Jama Connect, you need to know and recognize the data in Jama Connect was the data you originally worked on in DOORS.
Now, the problem is not necessarily about a single tool vendor. The process side of migration can be wholly generic. Okay? And that’s the key, having a process around migration gives you a way of making it predictable. And I’m just about to share with you a process for migration that is tool agnostic. It doesn’t matter where your data comes from or where your data goes to. It gives you a holistic process that you can use to migrate your data. And each step of the process, you just decide where is the data coming from and how do I take it and transform it into where it’s going to. Jama Software do provide migration tools towards an MBSE framework. And the examples through this presentation will be showing you how to migrate data from DOORS, IBM DOORS, into Jama Software’s Jama Connect product.
https://www.jamasoftware.com/media/2022/02/2022-02-02_data-migration_social-blog-image.png10801920Jama Software/media/jama-logo-primary.svgJama Software2022-03-03 03:00:072023-01-19 13:25:41[Webinar Recap] Best Practices for Data Migration Towards MBSE
In this blog, we recap a webinar discussing the real intent of MBSE (model-based system engineering.)
Today’s products are becoming increasingly complex and software intensive. This presents major challenges for organizations being able to effectively manage all the data, information, and artifacts across the lifecycle for these types of systems — and one of the key reasons that Model-Based Systems Engineering (MBSE) is fast becoming the standard approach to systems engineering for digital transformation today.
Since one size doesn’t fit all, an organization needs to assess the SE capabilities that best fit its domain, product line (degree of complexity), and culture. The level of SE capability an organization establishes needs to be tailored to the size and complexity of systems developed by the organization, whether small, medium, or large projects.
In this webinar, we will cover the following topics:
Challenges associated using 20th century document-based approach to Systems Engineering
What is MBSE?
What is the real intent of MBSE?
Is MBSE the same thing as SysML?
Benefits of implementing Systems Engineering from a data-centric perspective
How Jama Connect helps SE practitioners address these challenges
This webinar will be especially beneficial for those in the aerospace, automotive, defense, and medical industries.
Below is an abbreviated transcript and a recording of our webinar.
The Real Intent of MBSE
Joseph Pitarresi: Well, hello everyone. This is Joseph Pitarresi and I’m the senior product manager for Jama Software labs. I’m very excited about today’s topic, The Real Intent of Model Based Systems Engineering and Keeping up With Complexity. And I’m pleased to introduce our two industry experts for this webinar. First is Lou Wheatcraft, he’s the managing of Wheatland Consulting. Lou has over 50 years experience in MBSE thought leadership and his specialties are in needs and requirements, definition and management and verification and validation. Lou currently co-chairs the INCOSE Requirements Working Group, and he has consulted with global leaders in the sectors of aerospace and defense, medical devices, consumer goods, transportation, and energy.
Very pleased to have Lou with us today. Our second area expert is Jama Software’s own Cary Bryczek. Cary serves as a principal systems engineer and aerospace defense for Jama Software. She’s been with Jama Software for over eight years and has over 15 years in systems engineering leadership roles. Now, with those introductions, let’s get started. Over to you Lou.
Lou Wheatcraft: Well, thank you for having me. It’s an honor to participate in this webinar. The subject is The Real Intent of Model-Based Systems Engineering- Keeping Up With Complexity. This presentation is a follow on to the Whitepaper published by Jama in early December. Today’s increasingly complex centric systems are becoming more than norm how we practice system engineering needs to evolve to help us better develop and manage these more software centric or software intensive systems. Yesterday’s electro-mechanical systems had fewer interactions both internally and externally. Interfaces could be shown on drawings. It isn’t too long ago for a lot of our electro-mechanical systems didn’t contain a single computer chip and now today’s systems like automobiles can have over a hundred computer chips and associated embedded software and all the complexities of interaction between the software in those computer chips and with the hardware mechanical systems.
For software centric systems, internal and external interactions have increased orders of magnitude as have threats and the vulnerabilities. Critical functions in today’s software centric systems are carried out mainly by the software and really the electro-mechanical parts of the system are enablers for the softwares that carry out their key functionality. In INCOSE vision 2025, they recognize this complexity, this set of constant themes throughout the evolution of systems engineering is the ever-increasingly complexity of systems, which can be observed in terms of the number of system functions, components and interfaces and their non-linear interactions, and emerging properties. Each of these indicators, the complexities increased dramatically over the last 50 years and will continue to increase due to the capabilities that stakeholders are demanding and advancement in the technologies that enable these capabilities.
Keeping Up with Complexity
Lou Wheatcraft: This complexity presents organizations with challenges that need to be addressed. Failures can result in tremendous loss. These challenges result in increases in complexity in our systems, increases the role software has in the software architecture. So software centric, software intensive systems are the norm. Dependencies and number of interactions has dramatically increased between parts of the system. Interactions also between the system and the macro system is a part. The number of threats across the interface boundaries and vulnerabilities to those threats, dependencies between project management and the systems engineering, dependencies between system engineering and life cycle process activities and artifacts. The increases in oversight, competition, the pressure and need to reduce development time and time to market. The increases in risk, not just program and project risk, but also development risk, manufacturing, risk, system integration, system verification, system validation, and risk during operations.
And the number of projects that are over budget and experiencing schedule slippage. To address these challenges we must change how we practice system engineering. To address these challenges, it’s important projects incorporate systems thinking into all phases of product development. Projects must manage the integrated system and associate SE artifacts from beginning with the focus on the interdependencies, the parts that make up the system, interactions, both internal and external, integrated system behavior and emerging properties. And this is important because the behavior of the system is a function of the interaction of the parts, both the parts internal, but also interactions of the system within the macro system as part. When we were developing integrated system, they have emerging properties that were not indicated within our needs and requirements and relationships between the engineer and artifacts across the system life cycle. During development of our system, the different life cycle phases involved in developing products each has its own set of artifacts and these artifacts are related to each other.
We need to think about the relationships of the different life cycle processes and the resulting artifacts. And shouldn’t be developed and managed in a silo. Understanding the role of textual needs and requirements as well as diagram/models, which form is the best to communicate specific thing. It’s like two sides of the same coin. One is not sufficient. We need both the textual needs and requirements as well as we need diagrams and models as key analysis tools from which the needs and requirements are derived. We need to establish traceability between all data information across the system life cycle. So the focus of the rest of this presentation is addressing the real intent of model based systems engineering or MBSE for short. From the INCOSE System Engineering handbook, they talk about MBSE versus a Document-Centric Approach System Engineering. And they say, “In a document based system engineering approach, there’s often considerable information generated about the system that’s contained in documents and other artifacts such as specifications, interface control documents, system description documents, trade studies, analysis reports, and verification plans, procedures, and reports.
An MBSE Approach
Lou Wheatcraft: The information that obtained within these documents is often difficult to maintain and synchronize and difficult to assess in terms of quality, correctness, completeness, and consistency.” The document centric approach to system engineering, there are several key issues. The sheer volume of documentation has become overwhelming. We have a large number of documents for a project, each containing key data and information. All this has to be documented, reviewed, baseline configuration managed. Often these documents are done thoroughly at different times, and because of this, it’s nearly impossible to keep data and information in sync, current, correct, consistent resulting in no real single source approved. The vast number of documents results in cost and time overhead that consume a significant part of development cost eating into profit margins.
For projects that are still using the document centric approach system engineering, the development times and time to market are longer for many products, making the company less competitive. To avoid these issues, organizations must move from a document centric to a data centric perspective of systems engineering. The model based system engineering approach addresses many of the problems from the document centric approach to SE. From the INCOSE System Engineering handbook and the MBSE approach, much of this information is captured electronically in the system model or set of models. The system model is a primary artifact of the system engineering process. MBSE formalizes the application, the system engineering through the use of models. The degree to which this information is captured in models and maintained throughout the life cycle, depends on the scope of MBSE effort
https://www.jamasoftware.com/media/2022/02/2022-02-23_The-Real-Intent-of-MBSE_blog-social.png10801920Jama Software/media/jama-logo-primary.svgJama Software2022-02-23 03:00:542023-01-19 13:28:04[Webinar Recap] The Real Intent of MBSE – Keeping Up with Complexity
AdoptingMBSE: Challenging the Status Quo in Product Development
For product development teams to successfully implement a practice such as model-based systems engineering (MBSE), it requires the willingness of an organization to perhaps change processes and even tooling. Often, companies choose to stay with the status quo, but at what cost? Here’s a look at how adopting MBSE might help your teams, and the cost of not adopting MBSE.
Understand the Need to Move for Change
What is the Risk of Staying with the Status Quo?
For the MBSE Implementation Project Team to be successful, management must recognize the need to change. How can management be convinced? Three words – RETURN ON INVESTMENT (ROI)!
Think about these questions:
What has been the impact of the current, poorly executed product development efforts?
What is the overhead associated with the current document-based approach?
What are the current quality issues facing the organization that is catering it to profits: Failures, recalls, returns, warranty costs, lawsuits, negative reviews on social media, decreasing market share?
The ROI argument usually works with management especially when they can be convinced that by investing in a data-centric practice of SE tailored to the organization’s needs, the overall product development process, product quality, time to market, and profitability can be improved as discussed previously.
What is the ROI of Adopting MBSE?
To entice anyone — especially an entire organization — to make a change, proving ROI on the resource investment is key. Here are some key points to consider:
The more effective the Systems Engineer (SE) processes, the less rework and fewer cost and schedule overruns.
By moving to a data-centric practice of SE, the probability of achieving a competitive advantage can be improved by removing obstacles to being able to deliver products on time, on budget, and that meet or exceed customer and quality expectations.
From a cultural perspective, the personnel responsible for product development and will be most affected by the change must be shown, and how the change will benefit them.
A good process is not one that is something people have to do in addition to their job, rather it is one that helps people do their job more effectively. – LOU WHEATCRAFT
To get buy in from the product development teams, the MBSE Implementation Project Team must:
Understand what problems the product development teams are having and show them how moving to a more data-centric practice of SE will address those problems and make their job easier than the current document-centric approach. If the change results in more work or makes communication harder, the battle will be lost. For example, the lead engineer or project manager may already be over their head and working 50–60-hour weeks. Requiring them to learn how to use a new tool or set of tools and implement a new process may be too much of a load for them to bear! However, if they are provided with a dedicated person that has the training, knowledge, and experience in the new processes and tools to help implement the changes and train other team members, they will be much more receptive. They will also be much more receptive if this results in them having to work fewer hours and having fewer crises to deal with each day!
Be convinced of the utility of the changes, how the changes result in a better product and result in less rework for them. Frequently the reason project team members are working long hours is because they are always fighting fires, going from one crisis to another, which resulted from the lack of the proper SE tools, processes, data, and information in the first place! The culture needs to be changed from one of firefighting to one of fire prevention. As time passes, they will become advocates for the changes that have been made and welcome further change.
The MBSE Implementation Project Team’s mission statement will be something like: “Improve our product development processes by adopting MBSE within the organization by moving from a document-centric to a data-centric practice of systems engineering.” Along with this mission statement, they will need to define a set of specific goals and objectives along with measures of success. Once defined, they will need to get agreement from management on these goals, objectives, and measures.
Project success is dependent on having a high-level, C-suite project champion and getting management buy in. A major challenge for the project will be convincing management and other key stakeholders that it is time for adopting MBSE and moving from a document-centric to a data-centric practice of SE and knocking down the walls of resistance. Some common reasons for them not wanting to move to a data-centric practice of SE include:
“We have been doing product development using our current processes for years, why should we change?”
“Implementing SE from a data-centric perspective may work for others, but not for us.”
“This all seems very complicated, we don’t have the knowledge, experience, or tools.”
“Our current SE work products, like requirements, are managed in an RMT. FFBDs, and other diagrams we are currently using are models, so aren’t we already adopting MBSE?”
“It is too expensive to procure the needed SE toolset, maintain the tools, and train our people to use those tools.”
“We don’t have the budget to incorporate SE from a data-centric perspective at this time.”
“The expense and associated process to get new SE toolset installed on organizational computers is too great.”
“We would have to make signification IT infrastructure upgrades to accommodate the additional volume of data and performance requirements of the new SE tools.”
“We deal with the development of classified systems; controlling access and maintaining security will be too difficult.”
Sound familiar? Often the pushback can be attributed to a lack of understanding the risks associated with the current state of the organization, understanding the benefits of moving toward a more data-centric practice of SE, and what level of SE capability is appropriate for the organization.
To inspire a shift from a document-centric to a data-centric practice of SE in your organization, it’s vital to show both teams and management the value and expected ROI in doing so. Moving away from a current way of doing things isn’t always an easy road, but the risks of staying with the status quo are often great—and the rewards for changing processes and culture are often even greater.
An organization will be successful in practicing SE from a data-centric perspective when it is considered to be the “gold standard” for system development within the organization. However, the road to success is long — it takes very strong, unwavering leadership and experience to get this done right. It is human nature to try to push back and say that it isn’t possible, but it is.
https://www.jamasoftware.com/media/2022/02/2022-02-10-v2-mbse-challenging-status-quo.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2022-02-10 03:00:202024-07-10 15:48:47Adopting MBSE: Challenging the Status Quo
Requirements Traceability – Does My Data Model Matter?
Nearly all engineering organizations have one or more initiatives underway to improve their product development process. Live Traceability™, Model-Based Systems Engineering (MBSE), and digital engineering are the most common areas of focus. As engineers look over the fence and make fun of marketing types for being distracted by shiny objects, marketeers look back and see a similar behavior – just with geekier objects like SysML, digital twins, and simulation. The recurring pattern we see is that at some point during the early stages of the initiative, the realization hits that the data model for requirements across teams and projects is highly inconsistent and lacks consistent relationship rules among data objects. It becomes clear at this point that further progress on the initiatives cannot be made without first fixing the inconsistent and lacking data model.
Some teams will resist an effort to establish a consistent core data model. These teams will ask to keep the flexibility to refine their own engineering data shape and that is OK. The keyword is “refine” and not “define.” Having a consistent core data model, that some teams are allowed to refine for themselves, allows for innovation around the engineering process while still enabling process-wide, integration automation, Live Traceability, model-based systems engineering (MBSE), and digital engineering.
Current Requirements Data Model
For most companies, the data model mess came into existence through a project- and document-centric mindset with legacy requirements management tools. Each project team was allowed to modify their own data structures and each set of requirements lived alone as a document in a repository. This provided project teams with flexibility but over time and over dozens, hundreds, or thousands of projects has led to a challenging situation. We often find that teams have defined the same information in numerous different ways and that even within the same teams there is significant variance across documents. In short, the best way to describe the situation is as a repository of thousands of self-contained documents and no data model exists nor even a common definition of objects upon which to achieve Live Traceability, reuse across projects, MBSE, or digital engineering.
Jama Software®‘s Live Traceability™ allows engineering teams to quickly and easily access the latest and most complete information for any requirement, no matter the stage of development or tools used. This real-time capability boosts productivity by ensuring teams work with the latest data and reduces risks like delays and defects by finding issues early. Research shows that issues found late can be much more expensive to fix, which is why Live Traceability is so important. Jama Connect® helps overcome the limitations of older tools, leading to better results in many industries such as automotive, medical devices, aerospace & defense, and more. To learn more, visit Buyer’s Guide: Selecting a Requirements Management and Traceability Solution
What is Necessary to Move Forward
Organizations invest in software tools but have forgotten to invest in their data. A consistent data model is the best way to maximize the benefits of software tooling, but can only be achieved by spending time on analysis.
Jama Software has developed a Data Model Diagnostic™ (DMD) to help tackle this challenge, taking data from your legacy tool (IBM® DOORS®), understanding its shape and size, and transitioning the data into a model-based framework (Jama Connect™). The DMD automates the analysis of the existing documents to determine the most common object definitions upon which to base a consistent data model going forward. Once a data model has been determined, the next step is to implement a model-based, requirements management solution that ensures compliance is maintained. As opposed to a legacy, document-centric requirements management tool, a model-based one ensures consistent application of all objects AND defines and maintains the relationship rules among the objects. This forms a model representation of the requirements in a consistent manner across projects and is a necessary requirement for MBSE and SysML modeling.
To Get Started With Your Free Data Model Diagnostic™ Consultation:CLICK HERE
https://www.jamasoftware.com/media/2022/01/2022-02-04-req-traceability-data-model-1.jpg5121024Richard Watson/media/jama-logo-primary.svgRichard Watson2022-02-04 03:00:262024-07-26 15:54:34Requirements Traceability – Does My Data Model Matter?
