Tag Archive for: Product Development & Management

2025 Expert Predictions for Medical Device & Life Sciences: Innovations in Patient-Centered Care and the Future of Medical Device Design

2025 Expert Predictions for Medical Device & Life Sciences: Innovations in Patient-Centered Care and the Future of Medical Device Design

As patient-centered care takes center stage, the medical industry is witnessing an unprecedented transformation in how devices are designed, developed, and regulated. From the rise of direct-to-patient products and AI-enabled diagnostics to the challenges posed by cybersecurity and evolving regulatory landscapes, 2025 promises to be a pivotal year for medical innovation.

In part five of our annual predictions series, Richard Matt – Medical Product Consultant at Aspen Medical Risk Consulting, and Vincent Balgos – Director, Solutions & Consulting at Jama Software, share their insights on the future of medical devices. Together, they explore how digital solutions are reshaping patient care, the hurdles the industry must overcome, and the exciting possibilities for advancing remote monitoring, telehealth, and AI-powered solutions.

We like to stay on top of trends in other industries as well. Read our predictions for Industrial & Consumer Electronics (ICE) HERE, Automotive HERE, Semiconductor HERE, and Aerospace & Defense HERE – Plus, stay tuned for our future topic, AECO.

With patient-centered care becoming increasingly important, how do you see software and digital solutions transforming the design and development of medical devices in the next few years?

Richard Matt: Software development needs to mature to a place of contributing equally with other specialties instead of excelling independently. Far too many companies are being held back by technical siloing, usually led by software. The tragedy is that software personnel are among the most creative and productive employees. Their collaboration needs to mature to a place of creating opportunities for other specialties to be as efficient and achieve this together.

Vincent Balgos: There is a growing trend of direct-to-patient products (hearing aids, CGM’s, smartwatch apps) that includes complex software and digital solutions. In addition, most traditional med devices are now connected to the internet or other devices. I’d expect this trend to continue in this digital age, but with that growth, there will be some unintended side effects. Specifically, cybersecurity threats will continue to become a significant factor during the design, development, and on-market phases of the product.


RELATED: Integrate Cybersecurity and Safety Risk Management in Jama Connect® to Simplify and Accelerate Medical Device Development


Regulatory compliance and data security are paramount in life sciences. What advancements in software do you think will be most effective in managing compliance and protecting sensitive patient data?

Matt: Big data will become more available and utilized systematically to provide answers to questions that have been answered inadequately for decades. Protecting patient data is a simple matter of awareness and giving cybersecurity the sliver of attention it needs to close off the dominant attack vectors.

Balgos: In recent conferences I’ve attended (and read about), AI/ML continue to dominate the discussion around software advancements. Whether providing internal value to organizations, or external facing with AI/ML enabled devices, the impact that AI/ML has (generative, predictive) will play a major factor in the security of data (whether positive or negative). The regulatory guidance of AI/ML is still evolving so it’ll be interesting to see how it unfolds in the future.

As AI and machine learning continue to evolve, what role do you see these technologies playing in medical diagnostics, treatment personalization, and device functionality by 2025?

Matt: AI and ML will continue to evolve, as they have for generations. We have made recent, significant steps forward in natural language recognition, but the integration of that forward movement with diagnostics and treatment personalization will continue to be slow and incremental.

Balgos: The expansion of AI/ML in various traditional areas of med devices is continuing to grow at an exponential rate. Looking at FDA’s dataset, the # of authorized AI/ML enabled devices continue to grow YoY as much as 40% with applications in new areas. Currently, predictive AI is supporting medical professions with their clinical assessment/decisions in a supportive role and seems to be the common use case. But there are current talks now on how generative AI could add potential value in these device areas as well.

What are the biggest hurdles the industry faces in adopting cutting-edge software solutions in device manufacturing and patient care? How can companies proactively address these challenges?

Matt: The biggest hurdle is technical siloing, which software leads very capably. Companies can proactively address this challenge by implementing a systems-approach to problem solving / product development that respects all the technical contributions needed to succeed and ensures software personnel use their exceptional abstraction abilities to work in collaboration with the rest of the company.

Balgos: Some of the biggest hurdles my customers talk to me about are the evolving regulatory landscape, continuing pressures to accelerate development, scalability and ongoing resource and budget constrictions. For changing regulatory, I do recommend folks to work with a qualified regulatory affairs profession for guidance (and is now required in EU). For acceleration, scalability and resource constraints, companies are proactively looking for ways to maximize efficiency and looking to innovative ways to help organizations (e.g., AI applications).


RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences


How do you foresee the growing demand for remote patient monitoring and telehealth impacting product development for medical devices? What innovations do you think are necessary to support these shifts?

Matt: COVID was an unplanned stress test on our remote work capabilities. We need to analyze the results of that stress test to identify strengths and weaknesses to build into our next generation products and services.

Balgos: Based on the new FDA CDRH Director’s speech at MedTech Conf 2024, these demands coincide with their Home as a Health Care Hub initiative where these homestead digital solutions are becoming more at the forefront of healthcare for many patients. With these increasing interests and demands, I think connectivity of these devices will continue to rise, AI/ML will play a major factor in delivering value, and also improvements in the human factors/usability aspects of these devices will be something to watch. Transitioning from a professionally trained clinical staff to the general population, there will need to be a shift in developing these at home devices to be extremely ‘easy to use’, especially with those that struggle with technology, complex processes, and tedious tactile tasks.

With these innovations, there will be some side effects such as cybersecurity, post market updates, and the interoperability of all these devices. While they seem daunting, I’m confident that industry will rise to the challenge as they have with other previous challenges

Are there any additional insights you have regarding predictions, events, or trends you anticipate happening in 2025 and beyond?

Balgos: In early 2026, the FDA’s final rule on the Quality Management System Regulation (QMSR) will be effective, thereby incorporating ISO 13485 elements into the current Quality System Regulation (QSR). QMSR will supersede QSR.

Jama Connect® Enables DevSecOps Through Robust API and Integrations That Connect All Activity to Requirements

In this blog, we overview our new datasheet – Click HERE to read it in its entirety.

Jama Connect® Enables DevSecOps Through Robust API and Integrations That Connect All Activity to Requirements

DevSecOps involves integrating security into all phases of the software development lifecycle. Rather than waiting to start analysis of potential vulnerabilities until after the software product, system, or subsystem is completed, this strategy puts security at the center of software development from the start to identify issues when the cost of resolving them is lowest. It also enlists everyone to play a part in identifying, assessing, and mitigating security risks in their individual development-related activities.

Comprehensive Security Risk Management and Seamless Tool Integration

The biggest challenge in achieving DevSecOps success is the need to assess and manage security risks across all software development tools and teams in an efficient and comprehensive manner. DevSecOps leaders choose Jama Connect because it is the only requirements management solution that provides the automation and collaboration required. Its robust REST API provides alignment with an integrated CI/CD pipeline including Jira, Azure DevOps, Git, GitLab, Subversion, Jenkins, Splunk, Kubernetes, Visual Studio, and Coverity. The Jama Connect platform delivers Live Traceability™, connecting all DevSecOps activity to the singular common element that defines value across all steps in the process — the requirement. It provides intuitive, accessible collaboration and review capabilities for internal and external teams.


RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution


Enable Cybersecure-by-Design Compliance with DO-326A Standards

Jama Connect for Airborne Systems supports a DevSecOps strategy by applying a cybersecure-by-design approach to meeting DO-326A standards. With Live Traceability, Jama Connect overcomes the disconnectedness of processes in the tool ecosystem that causes certification delays, cost overruns, product failures, audit findings, late identification of defects, and lack of visibility. It makes change management between software and hardware easier and reduces the effort needed to demonstrate requirements and test traceability required for certification.

KEY BENEFITS:

  • Integrate security across all DevOps and testing software Jama Connect’s robust open REST API and market-proven integrations with best-of-breed DevOps and testing software tools make it possible to connect all DevSecOps activity to the common element that defines value across all steps in the process – requirements.
  • Start identifying security vulnerabilities early in the development process Jama Connect reduces the risk of releasing code with security vulnerabilities by focusing on security requirements and
    testing from the early stages of development.
  • Empower the entire team to contribute to DevSecOps Jama Connect’s easy-to-use collaboration and review capabilities provide an inclusive, safe, and collaborative environment for internal and
    external development, security, and operations teams to build software that is efficient and secure.

Managing DevSecOps in Jama Connect

This image shows a figure 8 type charge that portrays the easy workflow of managing DevSecOps in Jama Connect.


TO READ THIS DATASHEET IN ITS ENTIRETY, VISIT:
Jama Connect® Enables DevSecOps Through Robust API and Integrations That Connect All Activity to Requirements


This image shows a clock wearing a graduation cap to portray that this is a quick, informative video on the topic of Live Trace Explorer.

Jama Connect Features in Five: Live Trace Explorer

Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of Jama Connect’s powerful features… in under five minutes.

In this Features in Five video, Francis Trudeau, Product Manager at Jama Software, will introduce viewers to Jama Connect’s Live Trace Explorer, which auto-detects risk by bringing comprehensive and detailed insights into your complex development processes.

Please note that Live Trace Explorer is currently in beta and available for all Jama Connect Cloud customers to try.

VIDEO TRANSCRIPT


Francis Trudeau: Hello and welcome to the segment of Features in Five. My name is Francis Trudeau, and I’m a Product Manager at Jama Software. This video is an overview of Jama Connect’s Live Trace Explorer feature. Note that Live Trace Explorer is currently in beta and available for all Cloud customers to try.

The Live Trace Explorer is like a real-time map of the V-model, helping you check coverage completeness and validity across your project. It actively tracks metrics to spot gaps and risks between engineering teams so you can address issues early. This leads to a smoother development process, higher quality products, and faster time to market. This capability is a significant step in our vision to provide metrics for managing the development process through data.

To enable the Live Trace Explorer, go to the Admin tab, navigate to the Details section, find the Live Trace Explorer line, click Configure, check the box, and save. Once enabled, the feature appears in Admin Project settings and is available for Organization and Project Admins.


RELATED: Best Practices Guide to Requirements & Requirements Management


Trudeau: If permission is granted by their admins, users with a creator license can fully utilize the feature to load and configure existing diagrams. Once enabled, the Live Trace Explorer can be launched by right-clicking a project component or set to create a focused diagram for the selected node or right-clicking the project route to generate a comprehensive diagram showing all components and sets in sequence from top to bottom.

The resulting diagram visually represents the V-model with stakeholder needs, system requirements, designs, and components on the left, and their associated verifications and validations on the right. Each tile represents a component or set connected by trace paths. These paths are gray if there are no relationships between items and adjacent tiles, or they turn green and red to indicate the number of healthy or suspect relationships between them.

On the right side, the Verifications and Validation branch shows the number of Test Cases linked to items within the container on the left, no matter where they appear in the project. At the bottom of each tile, you’ll find a metric representing the ratio of these Test Cases included in a Test Plan. On the requirements side, the top part of each tile displays stats, including the number of items by type and any open conversations.


RELATED: How to Achieve Live Traceability™ with Jira® for Software Development Teams


Trudeau: In the bottom half, you’ll find coverage metrics, essentially the ratio of active relationships to expected ones as defined by the traceability information model. For example, the model indicates that each high-level requirement should have two relationships downstream. Out of my four high-level requirements, three are covered by validations, giving me 75% coverage. Two are related to mid-level requirements, resulting in a score of 50%. In the Actions menu, you can access configuration settings to customize what’s displayed and measured. You can globally turn off item types, exclude specific relationships from consideration, or you can configure each tile separately.

A common use case consists of configuring your diagram for disabling relationships you are not expected to have at an early stage of your project. Then you may want to disable lower-level requirement items and relationships pointing downstream to them. Once applied, the coverage and total score will update automatically. Make sure to save your diagram once you have configured it to your liking. Live Trace Explorer updates in real-time, so any changes to project data instantly affect the metrics. For example, I can address a gap by clicking on the incomplete coverage. This will open Trace View where I can then establish a relationship to a mid-level requirement. Back in Live Trace Explorer, the metrics and total score summarizing all coverage will be updated after a refresh. You can keep a record and share these metrics by exporting a diagram as a PDF from the Actions menu at the top.

If you’d like to learn more about how Jama Connect can optimize your product, software, and systems development processes, please visit our website at jamasoftware.com.


To view more Jama Connect Features in Five topics, visit:
Jama Connect Features in Five Video Series


This image shows a speaker who will give a presentation on ARP4754B.

In this blog, we recap our webinar, “The New ARP4754B: Tips for Engineers & Quality Teams” – Click HERE to watch it in its entirety.

Navigating the updates to ARP4754B can be challenging.

Understanding new safety analysis methods, validation and verification flexibility, and strategies to mitigate unintended behaviors is crucial for advancing aerospace development and ensuring compliance.

Join us as Cary Bryczek, Director of Aerospace and Defense Solutions at Jama Software, shares practical tips for engineers and quality teams to navigate the most impactful changes in ARP4754B.

Gain Insights On:

  • Changes from ARP4754A to ARP4754B
  • Model-Based Safety Analysis (MBSA) and Cascading effects Analysis (CEA)
  • Identifying and mitigating unintended system behaviors
  • Tying your safety analyses to requirements in Jama Connect
  • The updates to verification and validation methods

Below is an abbreviated transcript and a recording of our webinar.


The video above is a preview of this webinar – Click HERE to watch it in its entirety!

VIDEO TRANSCRIPT

The New ARP4754B: Tips for Engineers & Quality Teams

Cary Bryczek: We’re going to have fun talking about the changes from ARP4754B revision A to revision B. We’ll spend some time a little bit more deeply on its emphasis on model-based design and safety. I’ll talk about enhanced integration of safety and requirements management and some of the changes to validation and verification. At the end, we’ll have some time for Q&A.

A quick refresher on what ARP4754B is. Its title is Guidelines for Development of Civil Aircraft. It’s an industry guideline developed by SAE International that provides recommended practices for the development of complex civil aircraft and systems. It outlines a structured systems engineering process for the integrating of hardware, software, and human factors to ensure safety, reliability, and performance across the system lifecycle. The document emphasizes traceability, verification, and validation from initial concept through to certification with a strong focus on meeting regulatory safety and design assurance standards.

ARP4754B also aligns and is used in conjunction with other key aerospace standards like DO-178C and DO-254 offering detailed guidance on how to meet safety and certification requirements in the context of modern integrated aircraft systems. ARP4754 revision B is meant to expedite consistency with ARP4761 revision A, the safety assessment process, which was it was released on the same day in December of 2023.

The guideline describes generic aircraft system development process, which establishes a framework for discussing the process. ARP4754B doesn’t imply a preferred method or process, nor does it imply a specific organizational structure. At its simplest, it emphasizes the flow down of intended aircraft function through the system requirements management process and allocation of function to systems, subsystems, and hardware and software items.

Integral processes in the context of 4754B refer to key processes that are interwoven throughout the entire development lifecycle of aerospace systems from concept to design, integration, verification, and certification. Now, these processes ensure that various engineering disciplines, your systems engineering teams, your hardware and software engineering safety are fully integrated, aligned, and contribute to the overall success of the project.


RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Aerospace


Bryczek: This diagram from 4754B outlines the key stages of the aircraft system development process and provides a framework for understanding how safety is integrated into each stage. The safety are the ones that are in the lightest white or gray. The standard approach ensures that the safety risks are identified, analyzed, and mitigated early in the design process, and are continuously assessed throughout the system lifecycle.

I want to point out that lifecycle phases really are iterative and independent. 4754B emphasizes that the phases of system development aren’t strictly linear. For example, design and development may loop back to earlier phases such as the requirement’s definition. If issues are found during those later stages, sort of this iterative approach ensures that safety concerns can be identified and corrected throughout the lifecycle.

You’ll also notice that safety and hazard analysis is integrated throughout the development phases. Safety assessments are continuous activities throughout the development process. Safety considerations such as your functional hazard assessments, your fault tree analysis to your cascading effects analysis are embedded within multiple phases, particularly the design, development, and verification phases.

Let’s get to the meat of what has changed. So ARP4754B builds on the foundation laid by 4754A but offers a much more structured, detailed, and modern approach to developing complex aerospace systems. This is in response to the increasing complexity of our modern aircraft, tighter safety requirements, and evolving certification processes, particularly the need for rigorous system integration, traceability, and safety assessment practices. It provides greater clarity around the development assurance levels and how they relate to the overall system and safety requirements.


RELATED: Jama Connect Airborne Systems


Bryczek: While A provided a basic framework, B refines the application of DALs throughout the system lifecycle. B expands the understanding of development assurance levels in the context of aircraft and system development, and it places a greater emphasis on safety, traceability, and integration across the lifecycle stages. The updated standard provides a more comprehensive guidance on managing the DALs and aligning the safety assessments with the system requirements, and it ensures that development processes are rigorous enough to meet the increasing complexity of the modern aircraft systems.

With the increased use of model-based techniques, 4754B highlights the benefits of using models to perform safety assessments. It recognizes that simulation-based safety analysis can help engineers assess the safety of complex integrated systems much more efficiently by modeling different failure scenarios and responses, so the standard supports using simulation tools to model those failure scenarios and validate the robustness of safety-critical systems. And this all just improves the accuracy of safety analysis, and it helps identify the potential issues earlier in the design process.


THIS HAS BEEN A PREVIEW OF OUR WEBINAR, WATCH IT IN ITS ENTIRETY:
The New ARP4754B: Tips for Engineers & Quality Teams


2025 Expert Predictions for the Semiconductor Industry: Innovations, Sustainability, and Globalization

2025 Expert Predictions for the Semiconductor Industry: Innovations, Sustainability, and Globalization

The semiconductor industry is navigating a transformative era, marked by groundbreaking innovations and pressing challenges. As AI and machine learning demand faster, more efficient chips, semiconductor design and manufacturing are evolving at an unprecedented pace.

In part three of our annual predictions series, Michael Luciano, Senior Account Executive at Jama Software, explores the key trends shaping the industry. From advancements in silicon photonics and memory technologies to innovations in cooling systems and power delivery, these developments are poised to revolutionize chip performance while addressing critical energy efficiency needs.

Michael also addresses growing concerns about the environmental impact of chip production. With the immense power demands of AI-driven data centers and the continued use of harmful chemicals in manufacturing, the industry is turning to nuclear energy, novel materials, and refined processes as potential solutions. Emerging markets like India and China also play a pivotal role in future growth, highlighting the importance of global collaboration and infrastructure investment.

We like to stay on top of trends in other industries as well. Read our predictions for Industrial & Consumer Electronics (ICE) HERE, and Automotive HERE – Plus, stay tuned for future topics, including Aerospace & Defense, Medical Device & Life Sciences, and AECO.

With AI and machine learning driving demand for faster, more efficient chips, what key innovations in semiconductor design do you predict will transform these technologies, and how can companies balance performance with energy efficiency?

Michael Luciano: This is a great question. Key innovations in semiconductor design coming from increased demand with AI and machine learning (ML) will likely be on-chip optical communication using silicon photonics, continued memory innovation (i.e. HBM and GDDR7), backside or alternative power delivery, liquid cooling systems for Graphics Processing Unit (GPU) server clusters and superclusters.


RELATED: How to Manage Cybersecurity in Jama Connect® for Automotive and Semiconductor Industries


Do you have any concerns or anticipate any negative impacts as it pertains to AI & ML?

Luciano: It’s understandable that people have concerns. Like every other tool that man has created, it’s important to create safeguards to prevent misuse and abuse. Agreeing on the exact safeguards and corresponding regulations is a highly contested and complex topic with wildly ranging global opinions. It’s undeniable that as AI systems and tools continue to evolve, these systems will replace some people’s jobs. This is already starting to happen. I am cautiously optimistic. As AI technologies become more advanced, with every negative impact I believe there will be an equal or greater level of positive impact for society and mankind elsewhere. Artificial superintelligence (ASI) is a hypothetical AI system with an intellectual scope beyond human intelligence. Mankind needs to see eye-to-eye before ASI comes to fruition or we are all in trouble. But don’t worry, we still have some time.

As chip production faces increased scrutiny for environmental impact, what role do you see for sustainable materials and manufacturing practices in the semiconductor industry, and how can software contribute to optimizing these efforts?

Luciano: In the context of the AI boom – the power required to operate gigawatt+ data centers is immense. Nuclear power is likely the most environmentally friendly way to go about it. Amazon and Google are currently investing heavily and recently formalized several key partnerships in this space. In the context of individual chip/device manufacturing – modern fabs also require a lot of energy/power. Nuclear powered systems will be the long-term answer. There are also a lot of nasty chemicals and gases that are used in chip production. I don’t see a clear way to fix this now, but as academia continues to study alternatives and companies continue to invest heavily in Research and Development (R&D) there is a possibility individual process steps can be adjusted/refined to incorporate novel materials or find other ways to help mitigate detrimental environmental impacts.


RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries


As the semiconductor industry becomes increasingly globalized, what emerging markets or regions do you see as pivotal to future growth, and how can companies foster effective cross-border partnerships and innovation?

Luciano: I identify Asia-Pacific (APAC) as the largest emerging market – specifically India and China, due to their populations. Companies can foster effective cross-border partnerships and innovation through significant investment in key infrastructure in those markets.

Are there any additional insights you have regarding predictions, events, or trends you anticipate happening in 2025 and beyond?

Luciano: AI Agents will mature and become widely used. This will significantly change how companies operate and go-to-market (GTM.)

[Webinar Recap] Write Better Requirements with Jama Connect Advisor™

In this blog, we recap the “Write Better Requirements with Jama Connect Advisor™” webinar.
Click HERE to watch it in its entirety! 


Achieve Project Success with Clear, Effective Requirements

In this webinar, the speakers provide insights on how to leverage Jama Connect Advisor™, an easy-to-use, cutting-edge requirements authoring, editing, and analysis tool. Jama Connect Advisor uses Natural Language Processing (NLP) and evaluates and scores requirements against INCOSE EARS guidelines, enabling teams to create industry-compliant requirements, reduce risk, and improve efficiency throughout development.

You will learn how to:

  • Boost requirements clarity and writing speed as well as develop team skills with guided authoring
  • Track progress and improve requirements quality over time with downloadable reports
  • Improve the quality and usability of large volumes of requirement statements effortlessly with Batch Analysis
  • Save time on authoring, reviewing, and updating requirements
  • Confidently assess project readiness through requirements maturity analysis
  • Minimize rework risk due to ambiguity and contradictions

Below is an abbreviated transcript and a recording of our webinar.


The video above is a preview of this webinar – Click HERE to watch it in its entirety!

VIDEO TRANSCRIPT

Write Better Requirements with Jama Connect Advisor

Jeremy Johnson: Thank you so much to everybody that’s joining us today. This is a pretty special time for us to be able to take a new capability to market. From a product management and product development standpoint, it’s an extremely exciting time for us. So again, I appreciate everybody’s time in joining us here today.

Before we transition into the main portion of the session here, I want to provide a short introduction and an overview of our agenda. We’ll talk a little bit, for those who aren’t familiar with us, a little bit about Jama Software. We’ll talk a little bit about the trends in product development, and some of the challenges that we see in requirements authoring. We’ll also of course introduce you to Jama Connect Advisor, who it’s for, and how it works. We’ll get into a demonstration. We’ll also talk a little bit about our customer success program, specifically our customer success authoring workshop, and how we are now including and embedding the technology and the capabilities around Jama Connect Advisor into that consulting offering.

And then, as Juliette mentioned, our special guest, Sheila King will go into the requirements quality focus that she’s helping implement at Rockwell Automation, and we’re super excited and happy to have her. And then, we should have some time at the end of the session for some questions as well.

But again, starting with and moving into Jama Software’s role in the product development ecosystem, our vision and our purpose as an organization is to ensure that innovators succeed. And as you’ll see from today’s discussion and demonstration, that’s really at the core of what drove our introduction of Jama Connect Advisor.

From a broader solution standpoint, Jama Connect is the number one requirements management provider in the marketplace. We help teams with requirement management and product development through live traceability that also spans not only requirements, but the verification and validation components on the test side, risk management, and other key data that drives those processes forward.

The value that we hope these innovative organizations, our customers, derive is really focused around things like cycle time reduction, helping speed time to market, enabling through live traceability the ability to gain visibility and control over the organization’s product development processes, and really drive streamlining, really drive a tremendous amount of value, and ultimately ensure compliance and managing risk.

As far as organizations that we work with, we span medical device, automotive, industrial, machinery,and software, and this is just a sampling of the customers that we have the pleasure of partnering with. We have over 800 customers globally. These organizations span from smaller startup organizations to large global enterprises.

So with that very short intro to Jama Software, I now would like to review some of the complexity and challenges that we see today in product development, and of course to introduce you to Jama Connect Advisor.


Related: Jama Connect Advisor™ Datasheet


Katie Huckett: Thanks, Jeremy. I’m really excited to talk about Jama Connect Advisor today and some of the things that are happening in the environment that led us to develop this solution. Today’s systems have become much more complex, and the emergence of the system of systems architecture has become the dominant approach for devices in all sectors, whether it’s aerospace, automotive, medical, and even consumer products. The system of systems is actually a collection of independent subsystems that are integrated into larger systems and deliver the unique capabilities required by users. The challenge is that it is difficult to predict accurate, predictable models of all emergent behaviors. So global systems of systems performance is difficult to design. That leads to testing and verification. Verifying upgrades to existing systems of systems is difficult and expensive as well, which is hard to scale. These are some of the factors that have led us to think about how we can help.

Another question we asked ourselves is why is requirements authoring so hard? If we look at the industry approaches for requirements authoring, we looked at the International Council on Systems Engineering’s (INCOSE) Guide for Writing Requirements. There’s a need to exercise a core subset of 40 rules in the INCOSE Rules for Writing Requirements, and in addition to that, an assessment of 49 requirement attributes. So just following INCOSE alone requires a substantial amount of training and understanding and then applying it, which can take a lot of time.

We’ve also found that EARS, the Easy Approach to Requirements Syntax, is being adopted by many organizations developing complex systems of systems. That includes Airbus, Bosch, Dyson, Honeywell, Intel, NASA, Siemens, and others. What EARS does is gently constrain the textual requirements. The EARS patterns provide guidance for writing a requirement sentence and provides syntax structure with an underlying rule set. Even these industry preferred approaches are challenging to apply, so we’re looking at how we might address that.

So today, just as a brief example, product requirements quality drives fidelity and efficiency in the product development cycle. If you look at this automotive example, there are many systems. It’s a complex system of systems that are dependent on each other. Any of these systems can lead to confusing the operator or systems operating optimally. If you look at the traditional V model of approaching systems engineering, the requirements are fundamental at the very early phase. So immediately after your needs analysis, you need to have really clear, concise, accurate requirements definitions.

The negative outcomes of poorly written requirements has been well-documented. It often leads to delayed time to market, late stage errors in the product, inaccurate translation of stakeholder needs into product attributes, and the lack of development team synergy. As teams are very organic today, the requirements need to be documented clearly and in an understandable way so that the team can execute with high performance. And then, ultimately failure and verification and validation can happen without high quality requirements.


Related: How the EARS Notation Supports Effective Requirements Management and Live Traceability™ 


Huckett: A secondary challenge is the training and reinforcement of requirements authoring skills. The lack of proper requirements can lead to product issues, and it’s a significant challenge in today’s environment. 30% of engineering degree holders are nearing retirement globally, and in the US 79% of American workers agree that to retain or increase their future employability, they need to continue with their learning and development. Computer scientists, 47.5% participate in work-related training to maintain and extend their skills, and engineers almost 60% do the same. So onboarding, retaining, and training system engineers remains a significant challenge.

With those items as a background, I’d like to introduce Jama Connect Advisor. Jama Connect Advisor is an add-on for Jama Connect Cloud. It’s an intelligent natural language advisor that improves the quality of requirements. It allows you to author intricate product requirements quickly, easily, and with precision. It is powered by engineering-based natural language processing, so not a general-purpose aid. It is engineering language-based. The advice provided is based on the industry-recommended best practices for the INCOSE rules and EARS notations.

Jama Connect Advisor has a very significant side benefit, while you use it, it augments skills and reinforces organizational preferences while authoring. So not only is Jama Connect Advisor doing the pragmatic work of improving requirements quality, but your systems engineers are learning how to do that more quickly and efficiently over time with its use.

When we look at Jama Connect Advisor’s capabilities, its features include analysis and advice from industry-leading practices, INCOSE rules, and EARS notation. The application is designed to put these two together to increase the quality, accuracy, and efficiency of requirement statements. So that’s its unique value. The guidance is provided seamlessly while you are editing in Jama Connect, which we’ll demonstrate in a moment. So really, the advantages are that experts can work faster confirming the application of INCOSE and EARS as they go, sharing their expert knowledge across the organization.


CLICK HERE TO WATCH THE ENTIRE WEBINAR:
Write Better Requirements with Jama Connect Advisor™


This image shows a cta for visitors to sign up for a trial of Jama Connect Advisor.

Integrate DoD MIL-STD-882E Risk Management with Systems Engineering Using Jama Connect® for Defense Systems

In this blog, we recap a section of our Datasheet, “Jama Connect for Defense Systems: Integrate DoD MIL-STE-882E Risk Management with Systems Engineering” – Click HERE to read it in its entirety.

Integrate DoD MIL-STD-882E Risk Management with Systems Engineering Using Jama Connect® for Defense Systems

Align hardware and software systems safety using Jama Connect as your single, secure platform for requirements engineering, risk analysis, and test management.

Military departments and defense agencies must follow the MIL-STD-882E Standard Practice for System Safety to ensure safety throughout the entire lifecycle of military systems, including development, testing, production, use, and disposal.

A key challenge to compliance is the need to integrate risk management and collaboration into the systems engineering process systematically across system and fire protection safety and occupational and environmental health disciplines.

Relying on a manual, document-approach using Word and Excel to manage the MIL-STD-882E risk register is inefficient and error-prone. A more reliable and intelligent solution is Jama Connect for Defense Systems which provides a single, secure platform for requirements, risk, and test management throughout the development lifecycle. It enables alignment of software and hardware development teams to achieve speed and quality, auto-detection of safety and environmental hazards and risks for early identification and mitigation, and robust collaboration and reviews involving internal teams, supply chain partners and government agencies.


RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Aerospace


Key Benefits

  • Align the hardware and software systems’ team safety activities. Manage risk management for hardware and software system safety in Jama Connect which provides a single source of truth that integrates with best-of-breed software tools chosen by various teams.
  • Identify hazards and risks for early mitigation. Teams benefit from a single system and integrated data model for architecture, hazard assessment, analysis, safety requirements, and tests.
  • Accelerate development by streamlining collaboration and reviews. Avoid development delays by making it easy for internal and external teams to participate in MIL-STD-882E activities with Jama Connect’s Review Center and collaboration intuitive capabilities.
  • Get the most out of your requirements management and traceability solution. Use the same Jama Connect solution for managing and documenting your product requirements AND your MIL-STD-882E activities to maximize your return on investment from Jama Connect.

By leveraging Jama Connect, DoD systems development teams can significantly improve their efficiency, reduce risk, enhance safety, and expedite development while maintaining the highest standards of regulatory compliance with MIL-STD- 882E, contract requirements, defense data standards, interface standards, design criteria standards, manufacturing process standards, standard practices, and test method standards.


TO READ THIS DATASHEET IN ITS ENTIRETY, VISIT:
Integrate DoD MIL-STD-882E Risk Management with Systems Engineering Using Jama Connect® for Defense Systems


[Webinar Recap] Key Systems Engineering Skills: Critical Thinking and Problem Framing

In this blog, we recap our webinar, “Key Systems Engineering Skills: Critical Thinking and Problem Framing” – Click HERE to watch it in its entirety.

Key Systems Engineering Skills: Critical Thinking and Problem Framing

Elevate your team’s success by exploring the role of critical thinking in a system engineering competency model.

In this insightful session, Chris Unger, Retired GE Healthcare Chief Systems Engineering Officer and Principal at PracticalSE LLC, and Vincent Balgos, Director of Medical Device Solutions at Jama Software®, discuss how critical thinking and decision-making skills are integral to systems engineering.

In this insightful session, you will learn:

  • Explore the vital role of critical thinking and decision-making in systems engineering.
  • Learn practical techniques for decision framing and closure.
  • Gain insight on how systems engineers should manage design decisions on a project.
  • See a simple model of how and when to engage with stakeholders in design decisions.

Below is an abbreviated transcript of our webinar.

Chris Unger: We’re going to talk today about a follow-up to the last webinar, where I’m going to talk about some of the most important systems engineering skills, critical thinking, and problem framing. So, how do skills in general, and soft skills, fit into improving systems engineering? So, in prior talks, I’ve suggested you keep your processes very simple but make them effective, and that’s easy to say but hard to do. That means you have to understand the system of the SE processes, how they connect, and where the diminishing value of the processes, the source process heading off, happens. As an example, a topic could be a technical risk, or it could be a trade-off between different possible solutions. So, we want to understand how those to the risk management and the decision process interact.

In order to do that, the best systems engineers have to have really good judgment. In addition, we have to influence people. Being simplistic, hardware and software engineers design things, things do what they’re told. I know it’s oversimplified, but our deliverables are instructions on how the software and hardware engineers do things. So, the best systems engineers here have an area of depth that they’re experts in, so they bring some technical credibility. They have systems of breadth, they understand all the systems processes and how they interact, and they have great interpersonal skills. Today I’m going to focus on how you achieve a balanced and optimized design, how you focus on your cost versus risk, and doing that through basically decision making.

So, first I want to talk about the Helix Model. So, the Helix Project was a project funded by the government and, the US government, and their concern was for big aerospace and NASA projects you tend to produce a major, billion-dollar development every 10 years, and then you do 10 years of support. So, people often move on. They were worried about how you create the truly brilliant leader systems engineers from a team that may be a little bit sparse. They developed this model up here in the front and simplistically, you start with things you learn in school, how to do good mechanical engineering, electrical engineering, and software engineering techniques. You then go into an organization, and so you spend the first five years learning about your company. Things like, well, if you’re going to be doing a say glucose monitor, what does blood chemistry look like? What does a sensor look like? What’s a workflow? So, you become a good organization-specific mechanical engineer.

Then you learn about lifecycle. How do you go from womb to tomb, from customer needs to disposal and disposition with all the regulations across the world in terms of chemical safety? So, after five, maybe 10 years, you understand your domain, you understand the lifecycle and you understand your technology. What differentiates after that? What they found was the skills on the bottom half of this page, the Systems Mindset, so big picture thinking, and paradoxical mindset. You’ve all heard that joke about fast, good and cheap, pick two of the three. Well, that’s the world in which systems engineers live. We make trade-offs between things that are inherently conflicting. The other thing is, we’ve got to make decisions quickly, so you’ve got to have a flexible comfort zone. You’ve got to be willing to wait till you have the critical information but make a decision without all the information you want.


RELATED: A Path to Model-Based Systems Engineering (MBSE) with Jama Connect®


Unger: In terms of the middle column, Interpersonal Skills, just the obvious stuff as I mentioned. You’ve got to influence the other engineers to make a good decision. Then finally here in Technical Leadership, balanced decision-making, and risk-taking. So, I had a general manager one time say, “We’re in the business of managing risks, not avoiding risks.” The least-risk program is also a boring one, but you also don’t want to take moonshots and everything. So, you really want to balance. It’s another case of a paradoxical mindset. Balance risk-taking with hitting a schedule predictably. So, these are the kinds of skills that really differentiate as systems engineering leaders, 10 to 15 years into your career. I’m going to talk more about these, decision-making, stakeholder management, and barrier-breaking.

So, I put together a very simple Systems Engineering Competency Model. I started with the NASA handbook and the NASA lifecycle. I simplified it, into that they had scope and requirements management separated, and I actually agree with those being different. But in reality, on the size of programs that we typically implemented, the people who did one typically did the other. Same thing, the architecture and the design, those were typically the same people. So, you have the upfront design, you have implementation. So, managing the subsystems actually do the implementation of what the design asks them to do, and you integrate it, such that you find your defects early. Then you manage all the lifecycle, the serviceability, manufacturability, disposability, and all the “ilities.”

Then leadership, obviously, there the interpersonal skills. This was developed for GE Healthcare, so I just picked it from our existing leadership skillset and I simplified it. What you’ll notice here is I put down at the bottom, critical thinking, as a technical skill. For many executives, and for other functional engineers, critical thinking is important, but as I mentioned, since we deliver instructions and designs to other engineers, framing decisions, taking vague things from product management and marketing, and turning them into clearer problems or functions to solve, I consider that a core technical excellence of systems engineering. But that’s vague. How do I actually measure that? So, I came up with this fairly simple set of observable behaviors. So, first of all, framing problems takes an ambiguous problem identifies the critical stakeholders, and turns them into a clear problem a more junior engineer can solve.

So, first, let’s talk about framing the problem. Even an entry-level person has to be able to understand a problem that’s been framed for them. But as you get to more senior people, the 10 to 15-year level, you have to be able to frame a complex problem, see around corners, use foresight to sort out essentials from the detail, and identify risks and emergent behavior that need to be incorporated in the decision, that other engineers might not see. Even at the strategist level, you can take a complex and ambiguous problem clarify the ambiguity, and turn it into simply just a complex and interconnected problem.

So, if we’re talking about maybe the 10 to 15-year-old person, not the most senior executives, you’ll be able to take a complex problem, identify ahead of time problems other people don’t see, and capture that. Balance cost, schedule, technical risk, and team capabilities, and make a trade-off based on sound evidence and data. Balance your intuition, when you don’t have all the data with waiting and gathering data where you need it. Then finally, making the decision is maybe the easy part. You have to make sure the team follows your leadership. Take accountability for making the right decisions, delegate where you can, and then ensure that the entire team buys into the decisions that the team or you have made. So, that’s the theory.


RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences


Unger: Let’s talk about how we manage design decisions. First of all, why? Why is this a critical skill? By identifying the critical design decisions, it allows the team to focus on the most important thing, and separate out the core from the distractions. It helps teams identify work items. So, for example, one time when I was working with the ultrasound team in Japan, we had a bunch of really experienced engineers and they were working on a new ultrasound probe. It had moved an active component into the probe and there was a thermal issue. They were talking in Japanese for about five, 10 minutes when I was asked to frame the problem and I said, “Yeah, you’re talking too fast and too much. This is not that easy. Come back to me and tell me what you’re actually doing.”

They were figuring out how to measure the thermal properties in the lab. I said, “Well, imagine you had a probe that was safe, with maybe 39°C, but that was uncomfortable to handle. Have you worked with the application people on how much value? If you spent $50 more and took the temperature down by 1°C, would that be worth a trade-off? The team, “Oh, that’s interesting.” They were actually focused on the technical feasibility, not the real market and customer acceptance problem. So, by doing this upfront, you can make sure that you have a complete work process for the team. Then once you’ve made the decision, it minimizes rework by making sure the decisions stay closed.

Now, this decision list and prioritization should start early. It would be comfortable to wait until you know everything, but that’s too late. So, it’s a living document. Don’t wait to get started until you have enough information to make a good plan. Start with what you know, and then build out as you continue. So, one of the first things I talk about is, what is a decision? As an example, I’ve had teams come to me saying, “The operating system selection is a decision.” It’s like, “No. It’s actually not typical. It’s typically a collection of decisions.” So, I draw this little arrow here. It’s basically a decision is a point in which you select between different paths going forward and you pick one way versus another. So, deciding whether to include a stretch item in scope or not is a decision. Deciding between very specific designs and implementing a feature is a decision. Setting a critical to-quality parameter or balancing between different parameters, so cost versus reliability or cost versus performance, is a decision.


CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Key Systems Engineering Skills: Critical Thinking and Problem Framing


In this blog, we’ll recap a section of our recent Expert Perspectives video, “A Method to Asses Benefit-Risk More Objectively for Healthcare Applications” – Click HERE to watch it in it entirety.

Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications

Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.

In the complex world of healthcare, evaluating benefit-risk is crucial to successful product development and patient outcomes. Our expert perspectives video, “A Method to Assess Benefit-Risk More Objectively for Healthcare Applications,” offers actionable insights for healthcare innovators aiming to meet rigorous regulatory requirements while ensuring patient safety and efficacy.

In this episode of Expert Perspectives, Richard Matt breaks down a streamlined, objective method for benefit-risk analysis. He explores a structured frameworks and data-driven approach that help teams make balanced decisions, mitigate risks early, and stay compliant with regulatory standards, including FDA and ISO guidelines.

This patent-pending approach helps organizations navigate challenges, foster innovation, and ultimately bring safer, more effective healthcare solutions to market.

Below is a preview of our interview. Click HERE to watch it in its entirety.

Kenzie Jonsson: Welcome to our expert perspective series where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future in their fields. I’m Kenzie, your host, and today, I’m excited to welcome Richard Matt. Formerly educated in mechanical, electrical, and software engineering and mathematics, Richard has more than thirty years of experience in product development and product remediation. Richard has worked with everyone from Honeywell to Pfizer and is now a renowned risk management consultant. Today, Richard will be speaking with us about his patent pending method to assess benefit-risk more objectively in health care. Without further ado, I’d like to welcome Richard Matt.

Richard Matt: Hello. My name is Richard Matt, and I’m delighted to be speaking with you about our general solution to the problem of assessing whether the benefit of a medical action will outweigh its risk. I’ll start my presentation by saying a few words about my background and how this background led to the benefit-risk method you’ll be seeing in the presentation.

To understand my background, it really helps to go back to the first job I got out of undergraduate school. I graduated with a degree in mechanical engineering and an emphasis in fluid flow. And my first job was in the aerospace industry at Arnold Engineering Development Center, at a wind tunnel that Baron von Braun designed. I worked there as a project manager, coordinating various departments with the needs of a client who brought models to be tested. These are pictures of the ADC’s transonic wind tunnel with its twenty-foot by forty-foot long test section that consumes over a quarter million horsepower when running flat out. Those dots in the walls are holes, and a slight suction would pull the out on the outside of the wall to suck the air’s boundary layer through the holes. So a flight vehicle appeared more closely to match its flight air characteristics in free air. It was amazing place to work.

We could talk about aerodynamic issues and thermodynamic issues like why nitrogen condenses out of the air at mach speeds above six or why every jet fighter in every country’s air force has a maximum speed of about mach three and a half. But to stay on the topic of benefit-risk, the reason or my intro to this, the reason I was brought this up was that I saw here firsthand the long looping iterations that came from different technical specialties, each approaching the same problem from the respective of their technical specialty. I found it very frustrating and the, following analogy very apt, after getting, so each of our technical specialties would look at the same problem, the elephant from their own view. And I found myself getting frustrated with my electrical and software engineering coworkers, that they didn’t understand what I was talking about, but I knew realized soon I didn’t understand what they were talking about either.

So I decided I wanted to become part of the solution to that problem by going back to graduate school and getting myself rounded out and my education so I could talk to these folks from their perspective also. So I went back to grad after mechanical and undergraduate, went back to graduate school in electrical and mathematics and picked up enough software. I started teaching, programming also in college. I developed there a solution for the robot arms in those wind tunnels to to control a robot arm for every possible one, two, or three rotational degree of freedom arm, and that was my graduate thesis. After I completed my thesis, I felt empowered to start, my work doing going wherever I wanted doing whatever I wanted to do and realized that if I wanted to do anything significant, it would take many years, and I decided to focus on teamwork. Does that sound pretty good?


RELATED: Jama Connect® for Medical Device & Life Sciences Development Datasheet


Matt: My ability to work across technical boundaries enabled me to bring exceptional products to the market. For instance, I brought an Internet of Thing  (IoT) device to the market during the nineteen nineties before Internet of Things was a thing. And I rapidly advanced while I was working as a VP of engineering at a boutique design firm in the Silicon Valley. These are a few of the clients that I had, through the work that I’ve done over the years.

And, the combination of the breadth of my formal training and my system perspective for solving problems has really helped me work across continue to work across boundaries, so that I’ve worked for companies to help them establish their pro product requirements, trace requirements, do V and V work. I’ve done a lot of post-market surveillance work. I established internal audit programs. I’ve been the lead auditee when my firm is audited. Done had significant success accelerating product development and has been on work on. So mixed in with all of these works, I special I started specializing into risk management as consulting focus versus something I just did normally during development.

And since the defense of a patent requires notice, I’ll mention that the material here is being pursued on the patent, and, would like to talk with anyone who finds this interesting to pursue after you’ve learned about it. So let me start my presentation on benefit risk analysis by talking about how important it is to all branches of medicine and the many problems we have implementing it. The solution I’m gonna come up with, I’ll just outline here briefly so you can follow as we’re going through the presentation. I’m gonna first establish a single and much more objective metric to measure benefit and risk than people traditionally use. I’ll be accumulating overall benefit and risk with sets of metric values from this first metric. And finally, we’ll show how to draw a conclusion from the overall benefits and risk measurements of which is bigger benefit or risk.

So in terms of importance, historically, benefit-risk has been with medicine for millennia. It’s a basic tenant to all of medicine. The first do no harm goes all the way back to the quarter of Hammurabi 2,000 BC, and it legally required physicians to think not just about how they can help patients with treatment or what harm they might cause to treatment and making sure that the balance of those two favor the patient is very much the benefit-risk balance that we look at today. The result we’re gonna talk about is gonna be used everywhere throughout medicine with devices, with drugs, with biologics, even with clinical trials.

So is that fundamental cross medicine? How it’s used currently?

If you are in one of the ways developing new products, benefit-risk determinations have to be used in clinical trials to show that they’re ethical to perform, that we’re not putting people in danger needlessly. Benefit-risk determinations are the final gate before a new product is released for use to patients. And I have a quote here from a paper put out by AstraZeneca saying the benefit-risk determination is the Apex deliverable of any r and d organization. There’s a lot of truth to that. It’s the final thing that’s being put together to justify a product’s release. And so it has a very important role here for FDA and has a very important role for pretty much the regulatory structure of every country, including the EU.


RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences


Matt: In terms of creating a quality system, every medical company is required to have one. Benefit-risk determinations are used to assess a company’s quality system. This is per the FDA notice about factors on benefit-risk analysis. When regulators are evaluating company’s quality system, they’ll use benefit-risk to determine if nothing should be done, if a product should be redesigned, if they should take legal actions against a company of a range of possibilities from replacing things in the field to stopping products from being shipped. It’s also a key in favorite target for product liability lawsuits, because of how subjective it is, and we’ll get to that in a moment. It can also be used for legal actions against officers. So benefit risk is a really foundational concept for getting products out and keeping products out and keeping companies running well. Just a bit of historical perspective of medical documentation and development. We have here, I cited four different provisions of the laws, regarding medical devices in the United States. This is a small sampling.

The point I’m trying to make here is that each of these summaries of the laws discuss continually evolving, continually growing, more rigorous standards for evidence, more detailed requests for information from the regulators to the instrumentation development companies to the product development companies. So first, medical products are heavily regulated. We have the trend of increasing analysis and rigor. Per ISO 142471, and this is an application standard that is highly respected in the medical device field. A decision as to whether risks are outweighed with benefits is essentially a matter of judgment by experienced and knowledgeable individuals.

And this is our current state of the art.

Not that everybody does it this way, but this is the most common method of performing benefit-risk analysis. And benefit-risk analysis by this method, has a lot of problems because it’s based on the judgment and it’s based on individuals, and both of those can change with different settings. That’s why it’s a favorite point of attack for product liability lawsuits.

This quote was true in 1976, when medical devices were put under FDA regulation, but significantly remains unchanged nearly fifty years laters. Benefit-risk determinations are an aberration and that unlike the rest of medicine, they have not improved over time. They’ve remained a judgment by a group of individuals. In, twenty eighteen, FDA was, approached by congress to set a goal for itself of increasing the clarity, transparency, and consistency of benefit risk assessments from the FDA.

This was in human drug review as the subject, and the issue was that various drug companies had gotten very frustrated with the FDA for disagreeing with their assessments of what benefit-risk should look like. And to repeat again, when you have a group of individuals making a judgment, that’s gonna lead to inconsistencies because both the group and their own individual judgment will vary from one situation to the next. I have another, quote here from the article from AstraZeneca. The field of formal and structured benefit-risk assessments is relatively new.


RELATED: Application of Risk Analysis Techniques in Jama Connect to Satisfy ISO 14971


Matt: Over the last twenty years, there’s still a lack of consistent operating detail in terms of best practice by sponsors and health authorities. So this is an understatement, but a true statement. We have had a lot of increasing effort over the last few years because if people are dissatisfied with the state of benefit-risk assessments, they want to do better than this judgment approach. And so there have been a plethora of new methods developed. I’ve found one survey here that summarize fifty different methods just to give you an idea of how many attempts there are. And I went through those fifty methods.

The other thing that’s interesting to see is the FDA’s attempt to clarify benefit-risk assessments. I have here five guidance documents from the FTA, and I would put forth the proposition that anytime you need five temps five attempts to explain something, it means you didn’t understand the thing well in the first place or failing about a bit trying to get it done right. I think this is also held up by the drug companies, pressure on congress to get FDA to improve their clarity and consistency of benefit-risk assessments.

So here’s the, fifty methods that I found in one study of benefit-risk assessments. They have them grouped into, a framework, metrics, estimate techniques, and utility surveys. These are the fifty different methods, and I’ve gone through each one of them. And they all have fundamental problems. They, I’m going through them a bit slowly. Like, here’s one, from the FDA, another benefit risk assessment. Health-adjusted life years are one of the few that uses the same metric for benefit and risk. Number needed to treat is a very popular indication for a single characteristic, but you can’t integrate that across the many factors that needed to do benefit-risk assessment.

And so we’ve gone down the rest of these, methods. If I group these fifty methods by how they accumulate risk, I get a rather useful collection. Most of the methods do not consider all the risk-benefit factors for benefit-risk situation. They will pick on just one factor. And you can’t combine the factors with themselves or with others. It’s simply looking at one factor by itself. So it’s an extremely narrow view of benefit-risk for most of these. The few methods that do look at all the risk-benefit factors, most of them start with what I call the judgment method, where you’re forced to distill all the factors down to the most significant few, only four maybe four to seven methods, four to seven factors.

So either the methods consider only one type of, one factor at a time, or they force you to throw away most of the methods and consider maybe four or seven factors is the second method. The third method is they assign numbers to the factors, they’ll add the factors together, and they’ll divide the benefit sum by the risk sum. And if the division is bigger than one, they’ll say the benefit’s bigger than the risk. And if the division is less than one, they’ll say the risk is bigger than the benefit.


CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications


Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls

In this blog, we recap a section of our whitepaper, “Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls” – Click HERE to read it in its entirety.

Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls

Reduce the risks of product rework and recalls by using tools that enhance the efficiency and accuracy of requirements management and aid in compliance with UL 4600, the Standard for Safety for the Evaluation of Autonomous Products.

The shift to software defined vehicles (SDVs) marks a pivotal change in the automotive industry’s journey toward full autonomy. Initially, there was a rush toward developing fully autonomous vehicles, but the complexity of this task led the industry to adopt a more gradual, phased approach. This market transition has given rise to SDVs, but unlike traditional vehicles, which remained largely unchanged after purchase and are based on dated architecture topologies, vehicle OEM’s can now scale their software investments and simplify and optimize the vehicle architecture. This has benefits not only for the developer — resulting in a reduced total cost of ownership, potential acceleration of development, and improved safety and security — but also for the consumer in the form of increased choice, new business models, and post-sales updates and fixes.

Improving product and software development processes and the tools that support them can more effectively enhance safety and security standards while mitigating the risk of costly midcycle rework and after-sales recalls.

In 2023, there were over 300 recalls affecting more than 25 million vehicles, with costs potentially reaching millions of dollars per recall.

The automotive industry has advanced significantly from even a decade ago. Once-basic features, like touchscreen navigation, have evolved into sophisticated connectivity options, voice assistance, app ecosystems, and more. These changes bring several development challenges, including:

Managing increased software complexity

As vehicles become more software defined, managing multiple software components provided by many different vendors that perform entirely different functions increases complexity. For instance, an electronic control unit might operate the antilock braking system, while a cockpit domain controller is responsible for a very different task. In a software defined vehicle these distinct software systems must work seamlessly across the vehicle without issues, adding further complexity to an already challenging development cycle.

Ensuring functional safety and security compliance

With increased complexity, automotive companies face additional challenges in keeping up with safety and security standards and the associated regulatory compliance. The development community has relied on ISO 26262 for many years as the required functional safety standard. But, while it has historically served as an excellent baseline, the standard did not account for software defined vehicles, autonomous vehicles, or many of the new use cases.

Standards are evolving to keep up, and new ones, such as UL 4600, have been created that directly tie to autonomous vehicles. However, these standards continue to require companies to build requirements, test those requirements, and demonstrate that they have done everything possible to build a safe and secure product.

The process is complex with SDVs, especially when considering the hundreds of millions of lines of code involved. Companies must show that no faulty code exists and that they have not inadvertently introduced back doors that could create security issues or conditions that could violate a safety goal. As a result, there is a need to reconsider old processes and tools for requirements management to meet the current development environment and support mitigating potential risks.

Difficulty in meeting accelerated timelines

The pressure to deliver products and software faster is a significant challenge. Technology evolves rapidly, and no sooner have you developed a vehicle than consumer needs and opportunities emerge, leaving you to redesign to keep up with the market, differentiate, and stand out.

However, meeting accelerated timelines can conflict with maintaining quality and compliance, making it critical to strike the right balance. Adopting tools that allow for automation and faster processes can help keep up with these demands while aligning with safety requirements and standards. As more and more companies adopt an Agile development methodology, it’s increasingly important that the associated development tools do not stifle the benefits that Agile can offer. One great example is the concept of Traceable Agile™ that facilitates instantaneous, in-cycle insight into coverage for Agile development teams.


RELATED: A Guide to Road Vehicle Cybersecurity According to ISO 21434


Managing the dramatic increase of third-party software

Advancements in automotive development have led original equipment manufacturers (OEMs) to source software from multiple vendors. Integrating this level of diverse software while avoiding safety and security issues can be challenging. Now, you not only have to integrate hardware from various suppliers but also manage a massive software bill of materials (BOM) from different vendors, ensuring that everything works seamlessly together.

You also need to ensure that you’re not introducing bugs due to incompatibilities between systems, which can cause unexpected glitches, security vulnerabilities and safety issues. These are very expensive, can potentially delay product launches, and create negative brand impact.

Often, hundreds or even thousands of software elements come together, with tens of millions of lines of code. Ensuring that all these elements work together while remaining safe and secure, and meeting consumer expectations for a modern vehicle, is critical.

Four Major Challenges with Software Defined Vehicles

1. Managing increased software complexity. The industry is shifting quickly due to the integration of software in vehicles, which presents challenges in effectively and efficiently developing and deploying SDV’s.

2. Ensuring functional safety and security compliance. Automotive companies face challenges meeting safety and security standards and regulatory compliance, particularly with complex software systems.

3. Difficulty meeting accelerated timelines. The pressure to deliver products faster in the SDV space is a key challenge.

4. Managing the dramatic increase of third-party software. OEMs are sourcing software from multiple vendors and integrating this level of diversity while avoiding safety and security issues is difficult.

Solid engineering practices involve deciding what to build, defining a set of requirements, building it, and then testing it. This development lifecycle process ensures that you’re solving for the correct problem and is centered around requirements management.

However, many organizations use Excel sheets or Word documents to house requirements. Initially, this approach might not seem problematic, but as products become more complex and requirements grow, the spreadsheet approach becomes unmanageable. Copying and pasting requirements across documents creates opportunities for errors, a lack of a single-source-of-truth and a lack of traceability introducing the risk of expensive product or software issues.

You can address this challenge by replacing legacy processes involving spreadsheets and other solutions with a more robust, automated tool specifically designed for requirements management. This change eliminates manual processes that open the door to errors, improves efficiency, and reduces the risk of missed requirements — resulting in potentially millions of dollars of savings.


RELATED: Why Choose Jama Connect® Over Microsoft Word and Excel Documents for Requirements Management


How Ford Selected a Single Requirements Tool for SDV Architecture

In 2022, Ford selected Jama Connect as a single requirements tool. The company started to deploy the tool focused on the development of a future software defined vehicle architecture.

Before Adopting Jama Connect

  • Engineers often lacked formal training in writing requirements.
  • Unconstrained natural language often contained large specifications (non-atomic).
  • Poor requirements were the standard, and engineers had no automatic ways to receive feedback.
  • Suppliers received thousands of requirement specifications in PDF, but some didn’t apply.
  • Signing-off on products was a manual process, with engineers often having to chase down test results.

After Adopting Jama Connect

  • Requirements engineering is a discipline with training easily available and just-in-time.
  • Engineers receive immediate and automatic feedback on requirements quality.
  • Product-line engineering automatically defines what is applicable to a variant of a product.
  • Dashboards show real-time and transparent progression of product sign-off.

Read the full Ford story HERE.


CLICK HERE TO READ THIS WHITEPAPER IN ITS ENTIRETY:
Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls