MBSE Archives

Tag Archive for: MBSE

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.

Figure 1 – Adaptive Acquisition Framework (AAF)

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.

RELATED: Jama Connect^®: Accelerating Systems Development with Requirements Management and Live Traceability™

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.

RELATED: Ensure Product Quality with These Review Process Best Practices

Conclusion

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.

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.

Related: Requirements Traceability Benchmark

What about Integration and Customization?

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.

Related: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering (MBSE)

MBSE Platform, Decision Making, and Traceability

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 Companion 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.

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.

Watch the full webinar to learn more about 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

Watch the full webinar to learn more about The Real Intent of MBSE

This blog contains excerpts from a whitepaper titled, The Comprehensive Guide to Successfully Adopting MBSE, written by Lou Wheatcraft.

Adopting MBSE: 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.

Visit our interactive content page for ROI Calculators and more!

Combating Opposition to Change

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

Get Team Buy-In

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.

Get Management Buy-In

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.

Adopting MBSE: The Road to Success

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.

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.

To Get Started With Your Free Data Model Diagnostic™ Consultation: CLICK HERE

04: Determine the Future State the Organization Needs to Be At

The descriptions made previously for each of the ten areas of capability represent the level of capabilities an organization should be at for a complete transformation from a document-centric to data-centric practice of SE. However, for each area, there is a range of capability levels, it is not just an either-or determination.

It is important for the enterprise to decide how, and to what extent, they are going to address each of the ten areas resulting in reaching the future state that is best for their organization. This decision must be based on the needs of the enterprise while being scaled to the level of rigor that allows the system development life cycle process activities to be performed by the projects with an acceptable level of risk and that will result in the needed outcomes.

It is important to realize that this journey towards practicing SE from a data-centric perspective can be made in a series of small steps. The enterprise doesn’t have to jump to a completely data-centric practice of SE at the beginning of their journey.

Some organizations may want to start with an electronic (vs. hard copy documents) requirement capability which supports allocation and traceability as well as can manage requirements (and other work products) across all system lifecycle process activities. This will help link requirements to the stakeholder needs from which they were transformed, to design outputs, and to verification and validation work products. The project can identify measures to track system development activities and identify and manage risks. The managers can then add the capability to use non-language-based diagrams as single entities without the underlying data, e.g., functional flow diagrams or context diagrams, and link the requirements to those diagrams. From there, the capability for analytical modeling can be added where the various diagrams, requirements, and other work products are visualizations of underlying sets of data (only if there is some benefit to be gained from doing so.)

The future state for each of the ten areas of data-centric capability can be expressed as a range of capability levels (CL) (e.g., 0 – 3). The MBSE Implementation Project team can define what capabilities are in terms of each of these levels. For each of the ten areas of capability, the level defined represents a goal which the project team will strive to meet along with any specific measurable objectives for each goal.

05: Identify the Gaps

Once the organization has assessed the current state of their practice of SE, they will need to address each of the ten areas in terms of what level of capability is best for the organization.

From an IT infrastructure requirements perspective, it is best for the projects to communicate the end state envisioned, so their IT department can provide the IT infrastructure and PM and SE toolsets that are scalable to be able to handle the needs of the organization for the envisioned end state.

Central to successfully implementing the levels of data-centric capabilities the organization needs to be at involves the selection of the SE tools that will be used. What capabilities are needed from an SE toolset depends on the product line, its complexity, green-field vs brown-field products, issues the organization is having and wants to address, and the workforce knowledge and experience.

Organizations need to understand what data and information best meets their needs and which set of SE tools they need to work with and manage this data. SE tools are like any other software application…one size does not fit all. The SE toolset that is best for an organization is the toolset that meets the organization’s requirements management, systems engineering, and modeling needs. Consider the outcomes needed as a result of using SE tools and the ROI resulting from these outcomes.

Table 2 shows the ten areas of capability, the present state (P) and future state (F) in terms of capability level as defined by the MBSE implementation project team. The difference between the present state and future state represents a “gap” which the project team will fill as part of their project.

06: Develop Action Plans

For each of the ten areas, the MBSE Implementation Project Team will develop an action plan. Each action plan represents a sub-project that will have its own mission statement, goals, objectives, measures of success, needs, requirements, budget, schedule, and stakeholders. Actions that will need to be addressed for each area include:

Developing enterprise, business management, and business operations level policies, processes, and procedures needed to implement SE from a data-centric perspective.
Providing requirements to the IT department concerning the IT infrastructure needed, so these capabilities can be realized.
Selecting and procuring PM and SE toolsets that support the level of data-centricity decided on.
Training their managers and systems engineers in the use of the PM and SE toolsets and processes from a data-centric perspective.

07: Implement the Action Plans

The project team will also need to assign a priority to each area of capability.It is important to realize that this journey towards practicing SE from a data-centric perspective can be made in a series of small steps.

Successfully providing the capability to practice SE from a data-centric perspective requires three key things to be addressed: people, process, and tools. All three are highly dependent. One of the first areas that should be addressed is the selection of the SE tools that will be used by all the product development teams. Tool selection will be influenced by the data governance policies, data and information management procedures, product line, culture, and work force. The product development process will need to be updated to reflect the levels of data-centricity decided on as well as the SE tools selected. The product development teams will then need to be trained in the processes and SE tools.

Use a Pilot Project

There is an old saying “The devil is in the details.” To bring the people, process, and tools together, the MBSE Implementation Project Team should choose a pilot project. A pilot project can be used to demonstrate the benefits and ROI of adopting MBSE and moving towards a data-centric practice of SE. It will allow the organization to gain an understanding of what works (provides value, ROI), what doesn’t, what is liked, what isn’t liked, and tailor the processes to best fit the needs of the organization.

This pilot project can develop an example PMP, SEMP, and IMP that can be used as a template for other projects. A project ontology and schema can be developed that can also be reused by other projects. If the product that is the focus of the pilot project is highly regulated, the pilot project can import standards and regulations into the SE toolset, enabling their reuse for future projects. Armed with the lessons learned from the pilot project, the organization can fine tune their various processes, policies, and work instructions to help the organization move closer to achieving their mission, goals, and objectives to practice SE from a data-centric perspective.

Several key steps include:

Develop a practical process that implements the chosen SCL. The process needs to fit the product line, domain, and culture of the organization. The implementation needs to be tailored to the project. Don’t try to follow a process developed by a tool vendor for some other organization or product line.
Invest in training in the proposed chosen processes and SE tools.
Pick a pilot project to apply the process and assign the grass roots data-centric SE advocates to that project.
Define and use measures so metrics can help document the ROI can be clearly communicated concerning the agreed-to level of data-centricity.
Show management how measures and metrics maintained within the PM and SE tools will help them better track the health and status of the project, enabling them to be better project managers and systems engineers.
Encourage team members to be actively involved in organizations like INCOSE and join working groups whose members can aid the implementation process.
Invest in an outside consultant who has a proven track record in implementing SE capabilities consistent with the chosen level of data-centricity and chosen SE toolset. Often tool vendors will be able to provide that person or persons who can work with both the MBSE Implementation Project Team as well as the product development pilot project team members. The tool vendor will be able to help integrate their tool into the organization’s IT infrastructure as well as help the pilot project team members tailor the tool to their needs and be readily available to assist when issues come up.

Once the pilot project is completed successfully (an assumption), the project can be used as an example for future projects. The core grass roots folks can be spread out among other projects and mentor other project managers and systems engineers and train them and their teams in the concept of practicing SE from a data-centric perspective and in the use of the chosen SE toolset.

In many of the cases where adoption has been successful, there has been both advocacy at the top as well as a strong grass roots support that has gradually gained acceptance across the organization, but typically only after one team has proven success.

Parting Thoughts

Success is possible if the organization addresses the key factors of success discussed above. Of particular importance is understanding the overall puzzle in which the MBSE puzzle piece must fit as well as understanding the importance of all the pieces concerning the various areas of data-centric capabilities that make up MBSE.

Developing the roadmap discussed as well as using a pilot project are key to success. Since one size doesn’t fit all, an organization needs to assess the data-centric capabilities that best fit its domain, product line (degree of complexity), and culture. The level of 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.

Based on the needs of the organization and level of SE capability they choose, they will need to choose the appropriate SE toolset, update their processes, and train their people in these tools and processes.

Thank you for joining us for tips on successful MBSE adoption!

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE

This is Part 3 of a blog series covering a whitepaper titled,The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part I, Part II, and Part IV.

Developing a roadmap to successfully adopting MBSE within your organization

In this section, we provide a general approach or roadmap to be used in your company’s journey in successfully adopting MBSE within your organization. We say “journey” because that is what it is. Transforming an organization doesn’t happen overnight. There are a lot of pieces of the puzzle to address so it is important to take small steps and not try to do everything at once. Success includes addressing the key factors of success discussed earlier and define a roadmap. This journey could take several years depending on the size of your organization.

As stated earlier, the organization should form a dedicated MBSE Implementation Project Team with membership from each of the key organizational elements that have a stake and role in the adoption of MBSE within the organization. A general roadmap the project team can follow is shown in Figure 1:

Figure 1: Roadmap to Successful Adoption of MBSE

01: Get Management Buy-In

As discussed earlier, 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 to adopt MBSE and move 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 doing 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.”

02: Understand the Need to Move Toward a Data-Centric Practice of SE

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 it… 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.

The more effective the 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 how the change will benefit them. Changing culture is often met with opposition and existing stovepipes/silos often resist change.

To combat this opposition, determine which stakeholders are for and against the change and why. For each individual or group, identify their concerns and devise a strategy to get the change adversaries to become change advocates. Start with those stakeholders that have the most influence and convince them by addressing their concerns. The aid of other stakeholders may need to be obtained to help influence those that oppose the change.

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!

People at all levels must 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.

03: Access the Organization’s Current Practice of SE

To do this, they need to first assess the organization’s current state of practice of SE in terms of the ten areas of capability associated with data-centricity discussed previously. Table 1 shows an example of what the results may look like for organizations that are firmly rooted in a document-centric practice of SE. Sadly, this is the state of many of today’s organizations!

Visit these links for the rest of this series: Part I, Part II, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE

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.

So how do you achieve Live Traceability?

Step 1: Define a Traceability Model

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 sample exception management dashboard in Jama Connect.

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

This is Part 2 of a blog series covering a whitepaper titled,The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part I, Part III, and Part IV.

Adopting MBSE

What does it mean to practice SE from a data-centric perspective?

Successfully adopting MBSE and moving toward a data-centric practice of SE is much more than just acquiring and using a specific tool, set of tools, or focusing on the use of a specific type of model. As stated previously, MBSE is not just about the development of SysML or other language-based models nor just practicing model-based design. MBSE is itself made up of puzzle pieces, all of which contribute to the successful adoption of MBSE. To be successful, the following ten areas of capability associated with data-centricity must be addressed.

01: Holistic Product Development

A key tenet of data-centricity is taking a holistic view of product development and managing data and information within an integrated/federated environment. The focus is on multidiscipline, collaborative, project teams (e.g., integrated product teams). Many organizations still operate in organizational silos, with team members’ loyalty toward their specific silo rather than to the project team. When issues occur, the tendency is to blame those in other silos. Each silo often has its own processes, specific toolsets, data, and artifacts. Often the data and information are generated independently from those in other silos and are not in a form to enable sharing. This can result in inconsistencies, correctness, completeness, and currency issues of the data maintained in these artifacts. When moving toward data-centricity, organizations must have a holistic view of product development, minimizing the silos, encouraging collaboration, and improving communications not only between team members but between different tools used to generate and maintain data and information. Rather than treating Systems Engineering separate from Project Management (PM), projects must integrate both sets of functions such that there is a single project team that does both functions.

02: Manage Product Development Across the Lifecycle

Rather than having tools that are specific to a given organizational silo, a key characteristic of data centricity it that related data and information that represents lifecycle activities and associated artifacts can be linked resulting in “digital threads” that link related information together across the product lifecycle. This linkage enables project team members to work collaboratively and establish traceability between needs, design input requirements, system analysis artifacts, diagrams, models, architecture, design, system verification artifacts, and system validation artifacts. Traceability aids in change impact assessment across the product lifecycle helping ensure completeness, correctness, consistency, and currency of the data and information and resulting artifacts.

03: Enterprise Level Data and Governance Policy, Processes, & Procedures

Because of the dependence of not just the project teams, but the overall organization on electronic forms of data and information and increasing threats associated with the security of this data and information; enterprise-level policies, processes, and procedures concerning data governance and information management must be defined, implemented, and enforced.

04: Project Level Data and Information Management

Within the context of the enterprise-level data governance and information policies, each project must include their specific implementation of these policies within their Project Management Plan (PMP) and Systems Engineering Management Plan (SEMP). Because of the importance of managing the project’s data and information, the project is encouraged to develop and enforce a project-level Information Management Plan (IMP). Other supporting plans (e.g., requirements management plan) need to comply with the data management policies within the higher-level plans for both the project and enterprise.

05: Master Ontology

Terminology and language are key to successful communications not only between team members but between tools. For a given enterprise, an enterprise-level ontology (data dictionary and glossary) must be developed to clearly define specific terminology and relationships of various terms used within the organization and the project. This is critical when there are product lines, multiple project teams, and the need to share data and information between current projects as well as reuse data and information for future projects. Within the enterprise-level ontology, individual project teams can define their project-specific ontology consistent with the enterprise-level ontology.

06: Master Schema

Here the word “schema” is used to describe how the data and information are organized and managed within individual tools and associated databases. It includes the naming of individual data and information items, defining relationships between data items, and the import and export of data and information. From both an enterprise and project perspective it is important to define a master schema that the SE and PM tools within their toolset are compliant in order to enable data integration, shareability, and reuse.

07: Use of Attributes and Associated Measures

Data centricity enables the project to define and use attributes that can be used to manage project activities across all system life cycle stages. For needs and requirements, attributes can include rationale, priority, criticality, source, owner, traceability, risk, maturity of needs definition, needs and requirements definition status, design implementation, system verification, and system validation. Attributes can be defined to aid in reusability and product line management. Attributes can also be associated with key measures defined by stakeholders within their goals and objectives. These measures include key performance indicators (KPI), measures of suitability (MOS), measures of effectiveness (MOE), measures of performance (MOP), key performance measures KPP), technical performance measures (TPM), and leading indicators (LI). Data representing these measures and attributes can be used within the SE and PM tools to generate reports, dashboards, etc. which are used to better manage the project and system engineering processes providing managers near real-time status information and enabling them to identify and correct possible issues before they become problems.

08: Configuration Management

Adopting data-centricity, the project’s artifacts and underlying data and information are developed, analyzed, and managed holistically within the data and information model. Because the data and information are managed within the project’s data and information model, this model represents a single source of truth (SSoT) for the project. Rather than configuration control of each individual artifact represented by the data and information in the model, the project team can configuration control the model which represents the baseline state of the artifacts represented by the data and information in the model at any given time. “Visualizations” of the data and information in the form of the various artifacts represent the baseline version of that artifact. Even when these visualizations are extracted as reports, the SSoT is still the data and information model from which they were generated.

Note: for many organizations, this is often their biggest challenge in that it requires the organization to redefine its concept of configuration management. However, as stated previously, configuration management of individual artifacts requires significant overhead in both cost and time to individually configuration manage individual documents as compared to managing the data and information model that is representative of moving towards a data-centric practice of SE and PM.

09: Systems Engineering (SE) Tool Set

Data centricity requires projects to move beyond the use of common office applications: word processing, spreadsheets, presentations, basic drawing and diagraming tools, and requirement only management tools to define, analyze, record, and manage needs and requirements and other SE artifacts. Rather, projects must transform their SE process such that SE artifacts are developed using SE tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the SE tools within the project’s toolset as well as shareable with the project’s PM tools. When selecting specific SE tools to be included in the project’s toolset, it is important that the project determine the types of information and methods of analysis that are needed based on their specific product line, culture, and workforce.

10: Project Management (PM) Tool Set

Data centricity also requires projects to move beyond the use of common office applications for project management e.g., budgeting, scheduling, cost management, risk management). Rather, projects must transform their PM process such that most of the PM artifacts are being developed using PM tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the PM tools within the project’s toolset as well as shareable with the project’s SE tools. For example, Work Breakdown Structures (WBS) can be linked to Product Breakdown Structures (PBS) and physical architectures to enable management of budgets, schedules, resources, and risks associated with each system and system element within the product physical architecture.

Visit these links for the rest of this series: Part I, Part III, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE

Tag Archive for: MBSE

DOD 5000 Series

RELATED: Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™

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

DOD 5000.02 Acquisition Lifecycles

RELATED: Ensure Product Quality with These Review Process Best Practices

Conclusion

Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™

The Cost of Discovering Late-Stage Issues

Related: Requirements Traceability Benchmark

What about Integration and Customization?

Related: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering (MBSE)

MBSE Platform, Decision Making, and Traceability

RELATED

Best Practices for Data Migration Towards MBSE

Drawing an Information Model

How do we get your legacy data into an MBSE framework?

Jama Connect® for MBSE

The Real Intent of MBSE

Keeping Up with Complexity

An MBSE Approach

Adopting MBSE: Challenging the Status Quo in Product Development

Understand the Need to Move for Change

What is the Risk of Staying with the Status Quo?

What is the ROI of Adopting MBSE?

Combating Opposition to Change

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

Get Team Buy-In

RELATED POST: Systems Engineers Career Path – How to Elevate

Get Management Buy-In

RELATED POST: Whitepaper: A Path to Model Based Engineering (MBSE) with Jama Connect

Adopting MBSE: The Road to Success

Requirements Traceability – Does My Data Model Matter?

RELATED READING: Requirements Traceability – How to Go Live

To Get Started With Your Free Data Model Diagnostic™ Consultation: CLICK HERE

READ MORE ON REQUIREMENTS TRACEABILITY

04: Determine the Future State the Organization Needs to Be At

RELATED POST: MBSE Is Not SYSML

05: Identify the Gaps

RELATED POST: The Real Intent of Model-Based Systems Engineering

06: Develop Action Plans

07: Implement the Action Plans

Use a Pilot Project

Parting Thoughts

Developing a roadmap to successfully adopting MBSE within your organization

RELATED POST: The Real Intent of Model-Based Systems Engineering

01: Get Management Buy-In

02: Understand the Need to Move Toward a Data-Centric Practice of SE

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

03: Access the Organization’s Current Practice of SE

Requirements Traceability – How to Go Live

Live Traceability vs. After-the-fact Traceability

RELATED POST: Requirements Management Guide: Requirements Traceability

So how do you achieve Live Traceability?

Step 1: Define a Traceability Model

Step 2: Setup Continuous Sync for Siloed Tools/Spreadsheets

Step 3: Monitor for Exceptions

Benefits of Live Traceability

LEARN MORE

Adopting MBSE

What does it mean to practice SE from a data-centric perspective?

01: Holistic Product Development

02: Manage Product Development Across the Lifecycle

03: Enterprise Level Data and Governance Policy, Processes, & Procedures

04: Project Level Data and Information Management

RELATED POST: The Real Intent of Model-Based Systems Engineering

05: Master Ontology

06: Master Schema

07: Use of Attributes and Associated Measures

08: Configuration Management

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

09: Systems Engineering (SE) Tool Set

10: Project Management (PM) Tool Set

RELATED: Jama Connect^®: Accelerating Systems Development with Requirements Management and Live Traceability™

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

Jama Connect^®: Accelerating Systems Development with Requirements Management and Live Traceability™