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.
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.
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.)
https://www.jamasoftware.com/media/2024/12/2024-12-19-predictions-Semiconductor-2025.png5121024Jama Software/media/jama-logo-primary.svgJama Software2024-12-19 03:00:232024-12-20 12:30:022025 Expert Predictions for the Semiconductor Industry: Innovations, Sustainability, and Globalization
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.
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.
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.
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.
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.
https://www.jamasoftware.com/media/2024/11/2024-10_dod-mil-std-882e-risk-management-w-systems-engineering-datasheet-2-1.jpg512986Jama Software/media/jama-logo-primary.svgJama Software2024-11-25 03:00:272024-11-20 11:51:07Integrate DoD MIL-STD-882E Risk Management with Systems Engineering Using Jama Connect® for Defense Systems
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.
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.
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.
https://www.jamasoftware.com/media/2024/03/Key-Systems-Engineering-Skills-Critical-Thinking-and-Problem-Framing.png5121024Vincent Balgos/media/jama-logo-primary.svgVincent Balgos2024-11-21 03:00:452024-11-18 10:07:27[Webinar Recap] 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?
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.
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.
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.
https://www.jamasoftware.com/media/2024/11/Richard-Matt-Benefit-Risk-Medical-Application-1.png496882Richard Matt/media/jama-logo-primary.svgRichard Matt2024-11-20 03:00:282024-11-18 09:50:07Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications
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.
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.
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.
https://www.jamasoftware.com/media/2024/11/2024-11-19-stragegies-mitigating-software-defined-vehicle-risk-1.jpg512986Jama Software/media/jama-logo-primary.svgJama Software2024-11-19 03:00:032024-11-15 16:02:48Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls
In this blog, we recap our recent webinar, “Achieving ASPICE 4.0: Overcoming Key Challenges” – Click HERE to watch the entire thing.
Achieving ASPICE 4.0: Overcoming Key Challenges
The path to ASPICE 4.0 compliance can be complex. Gaining a deeper understanding of traceability requirements, process consistency, verification criteria, and special characteristics is essential to improving your development processes and achieving compliance.
How to implement robust traceability methods for ASPICE 4.0
Techniques to maintain consistency across processes
How to define and implement effective verification criteria
The significance of special characteristics in automotive software development
BELOW IS AN ABBREVIATED SECTION OF THIS TRANSCRIPT
Ronald Melster: Thank you for the warm introduction and thank you very much for inviting me to today’s webinar. I’m excited to be here with all of you to discuss the challenges and updates that we encounter in the latest version of the ASPICE standard. So let’s get started and explore what these changes mean to our industry and how we can best adapt to them. Why are we doing this webinar? The release of ASPICE 4.0 has brought new requirements and expectations and created some confusion.
In this session, we will discuss four key areas of change that are especially challenging and potentially misleading. This webinar is designed to clarify these updates and help you understand the implications. Here are the four changes I will talk about. First, we will look at the changes on how to connect elements across the V-model. Then we move on to consistency, as there is an increased emphasis on maintaining consistency across work products. I would share how this topic impacts your daily work. Then we discuss our favorite topic, the verification criteria. The base practice and the work product for the verification criteria have been removed from the standard. The question is if the need for a verification criteria is gone as well. And the last change I will talk about today are the special characteristics. This new concept was introduced with PAM for 0.0. I will explain why this is necessary and how it can be implemented.
Some of you may know me already, but for those of you who don’t yet, let me introduce myself briefly. I’m Ronald Melster or simply Ron in the automotive world. As one of Europe’s longest-serving ASPICE assessors, competent since 2005 and now principle, I’ve dedicated my career to guiding organizations through process improvements, always striving to balance structure with pragmatism. After my early work in software engineering and quality assurance at Fraunhofer, where I researched on knowledge management and 3D visualizations, I entered the automotive industry in the year 2000. Over the years, I found that meaningful assessments involve much more than simply rating. It’s about helping people to understand the why behind each process. Today, I coach companies and teams through their ASPICE improvement projects, working with companies like Bosch, Audi, and Porsche to help them reach the capability levels one, two, and even three. Together we are shaping more effective motivated teams that understand not just the how, but the purpose behind the ASPICE standard.
Melster: The first topic I will talk about is traceability. A very common misunderstanding is that a trace must be a direct link to click on, and then I end up at the target element. This was never the expectation and has been clarified with PAM 4.0 in the respective VDA guidelines. Before I run you through the possible traceability techniques, let’s discuss why traceability is essential for successful project management and product development, starting with the impact analysis of change requests. Traceability allows us to clearly track the origin and implications of each change request. By establishing traces, we can see where a change affects other components, documents, or requirements. This is particularly crucial for ensuring that safety and security requirements are met consistently. Next, we have root cause analysis of problems. With traceability, we can identify not only the immediate issue, but also trace it back to the process step where it was introduced.
This can help to prevent similar issues in future cycles by allowing us to adjust processes or documentation at the root cause level, instead of merely fixing surface-level symptoms. And traceability can help to show the completeness of work products. Traceability helps us to verify that all necessary parts of the system are complete and that each requirement has been successfully implemented. This is especially critical in safety and security cases, where missing traces could mean non-compliance or safety issues, or vulnerabilities.
Finally, traceability enables progress tracking. By using trace links, we have a clear and consistent overview of how far along each requirement is in the process. This enables project managers to track progress more accurately. In essence, traceability ties every piece of the project together, ensuring that we understand the why and how behind each element, and helping us maintain quality, safety, and security. Let’s have a look at the first traceability technique, which are naming conventions. The idea is to use the name of one artifact to identify another artifact. For example, the name of the unit, which is defined as part of the detail design, is used to identify the source code file or the function in the source code. Of course, the naming convention has to be described in a central document to make it available to everyone in the project.
Our next traceability technique are editorial references. This method uses the same ID as a text reference across documents that need to be connected. It’s a straightforward approach, often called traceability light, because it doesn’t require complex tools at the start, just the ability to update text in both documents. The question remains how to trace back. There are a few approaches that we can take. The first one is contextual searching. In the traceability strategy, we can specify how to search within the databases or text documents for these IDs, allowing to navigate across documents. Another method is to create a mapping table serving as a lookup tool that aligns IDs from one document to another. Finally, we can use tools like Rectify, that scan the text documents and provide statistics about the coverage of the traces.
Melster: Our third traceability technique is hyperlinking. This approach creates direct connections between tools, making it easier to trace items across different systems. With hyperlinking, each item has a direct link embedded in the document or tool, so rather than manually searching for information, you simply click the hyperlink and it brings you straight to the related item in another tool or document. Our fourth and last technique for establishing traceability are tool links. Many modern tools can create direct links or traces between different elements or requirements, streamlining the process of tracking dependencies and relationships across the project. Tool links often add semantic context to each trace, such as implements or is implemented by. This provides clarity on how the elements are related, making it easier to understand the purpose behind each link. One powerful feature these tools provide are suspect links. These are automated flags that notify us when a linked requirement or element is modified. This way we can quickly perform impact analysis and assess whether changes in one area affect other linked elements, helping us manage risks and ensure consistency across the project.
Another change that comes with PAM 4.0 are clusters of elements. This means that instead of establishing links from one single element to another single element, we can now create traceability links at a higher level. For example, we can trace groups of requirements that share common goals, we can trace two architectural elements within a particular subsystem, or we can trace software units associated with a specific functionality. This flexibility allows us to handle complex systems more efficiently, as we are not restricted to tracing every single element individually. However, this comes with more responsibility, as it is more important to remember that the level of traceability must still be appropriate for the product, and it is more complicated to provide the statistics for coverage, because we cannot just simply count items which are connected. And finally, the justification for consistency becomes much more important. For example, do the test cases which are linked to a cluster of requirements completely cover this cluster, or is there something missing?
Another important change I would like to highlight is that it’s now possible to trace from stakeholder requirements on SYS.1 directly to software requirements SW.1. There is no need to link via the system requirements to the system architecture to the software requirements anymore, if the stakeholder requirements are specific enough and have no impact on any other part of the system other than the software. This approach is often used in software-only projects, where the stakeholder requirements are already very specific. However, in system projects, the impact on the system must be considered in a comprehensive way. The same approach can be used for hardware requirements and mechanical requirements as well.
Another big change from PAM 3.1 to 4.0 is that there’s now a combined base practice for traceability and consistency. In ASPICE PAM versions 2.5 and earlier, we used to assess consistency and traceability together in one based practice. In PAM 3.1, they were split into two based practices for traceability and consistency, and VDA guidelines define the strong relationship between these two base practices, because these two concepts are inherently connected. To explain why, let’s consider this. Consistency depends on having effective traceability. Without solid traceability between work products, we are not able to guarantee that the elements align correctly throughout the development process. For example, if requirements are not traced to elements of the architecture or test cases, showing the evidence for consistency between these artifacts becomes nearly impossible. Therefore, checking for both consistency and traceability as a unified practice makes sense, as it ensures that all pieces are in sync and meet the intended quality standards.
Melster: Let’s have a closer look at an example for consistency, which base practice or base practices in SW.1. Software requirements analysis deal with consistency. Obviously, base practice five directly addresses consistency by requiring us to establish bi-directional traceability between software requirements and the system architecture, and software requirements and system requirements. This base practice ensures that each software requirement is directly aligned with the system architecture and linked back to the respective system requirements. The idea here is to maintain clear connections, ensuring that the requirements are accurately reflected across all levels of design. The second base practice, which deals with consistency is base practice number one, it’s a little bit hidden in node two. This node defines characteristics for requirements like verifiability, comprehensibility, freedom form implementation and surprise surprise, not contradicting other requirements, which is the synonym for consistency.
So we have two types of consistency in software requirements, external and internal. External consistency ensures alignment between software requirements, system requirements, and the elements of the system architecture. Each of these checks involves typically two different documents and it compares different artifacts, software requirements with system requirements, and software requirements with the elements of the system architecture. This is why I call this consistency, external consistency. And we have to fulfill BP-1, which can be done checking for internal consistency. For SW.1, that means software requirements are checked against other software requirements. This activity is essential for ensuring the integrity of our requirements. The primary goal of this verification is to ensure that the requirements do not contradict each other. There are many references and standards such as ISO IEEE 29148, ISO 26262-8, and the INCOSE Guide for Writing Requirements. They have one characteristic in common, that requirements shall not contradict each other.
This is one of my favorite topics. I have had discussions about this for years. Do we need an explicit verification criteria, yes or no? Now the base practice and the work product have been removed. What does this mean? This removal of the explicit verification criteria requirement in ASPICE PAM 4.0 marks a significant change, streamlining the base practices for evidence of verifiability. While previous versions of ASPICE emphasized having a separate verification criteria as a formal step, this requirement has been softened in PAM 4.0. However, demonstrating variability remains a crucial practice as we have seen. Projects must still make sure that there’s an evidence that each requirement is verifiable, though it’s no longer mandatory to document a distinct verification criteria for each requirement. This adjustment suggests that verification is evolving in focus. Instead of a string and isolated criteria, there are other ways to ensure the verifiability, performing review by the test team for example.
Melster: This ensures that requirements can be tested or writing simpler requirements if this is possible, of course, but for straightforward requirements, there’s no need to have an explicit verification criteria. However, for more complex system requirements, writing a verification criteria might still be recommended, so writing a verification criteria has become a best practice instead of a base practice. The decision and the responsibility for justifying this decision lies with the development projects now. And the last topic I would like to talk about are special characteristics. What are they and where do they come from? These special characteristics are often identified through structured risk assessments, such as FMEA, failure mode and effects analysis, which is commonly used to prioritize potential failure risks. Or HARA, hazard analysis and risk assessment, which helps identify safety critical elements. And of course TARA, threat analysis and risk assessment, which focuses on cyber security and vulnerabilities.
In terms of application standards, like IATF 16949, specify that these special characteristics should be integrated into the system architecture, as well into the hardware design. This ensures that all key attributes affecting system safety and compliance are identified from the start. An essential part of managing special characteristics is ensuring that they are verifiable. According to VDA volume one, special characteristics must be documented in a way, so that they can be reviewed and validated. This verifiability ensures that all compliance and safety requirements are traceable and systematically implemented. This concludes our little journey into the changes and challenges with PAM 4.0. If you want to learn about RSPICE, consider joining the Melster Academy or book a personal meeting with me to find out how you can elevate your ASPICE expertise. I am looking forward to support your journey. Thank you very much for your attention. I will now hand it back to Sathiya and I will be happy to answer any questions you may have at the end of the webinar.
In this blog, we recap a section of our eBook, “The Clear Choice: Why Jama Connect Surpasses Codebeamer for Requirements Management and End-to-End Traceability” – Click HERE to read it in its entirety.
The Clear Choice: Why Jama Connect® Surpasses Codebeamer for Requirements Management and End-to-End Traceability
To adapt to increasing industry challenges and complexities, innovative organizations are now requiring best-in-class software to scale development, reduce risk, save time, and ensure compliance to quality, safety, and security regulations.
As organizations strive to deliver innovative products while navigating regulatory requirements, the tools they use for requirements management and traceability can make or break their success. This eBook is designed to help you understand the critical differences between Jama Connect® and Codebeamer, two leading requirements management solutions, so you can make an informed decision.
The Requirements Sector
The landscape of requirements management has undergone significant transformation. Traditional tools (like IBM® DOORS®) which once dominated the market, are now considered outdated. These legacy systems often lack the flexibility, ease of use, and integration capabilities required by modern teams. As a result, organizations are turning to modern solutions like Jama Connect that are built to meet the needs of today’s dynamic development environments.
Why Jama Connect?
Jama Connect stands out as a leading requirements management solution because it is designed with the user in mind. Its modern, user-friendly interface, combined with powerful features like comprehensive traceability and real-time collaboration, ensures that teams can manage requirements and risks effectively throughout the product, systems, and software lifecycle. Jama Connect also emphasizes customer success, offering expert support and training to help teams maximize their investment. Ease of use, rapid deployment, pre-configured well-documented industry frameworks, and in-house subject matter experts provide the fastest time-to-value/ROI without sacrificing quality or safety.
The Clear Advantages of Jama Connect Over Codebeamer
If you’re comparing Jama Connect to Codebeamer, one thing is clear — Jama Connect is the only purpose-built requirements management platform that delivers Live TraceabilityTM which allows engineering and other teams to
quickly and easily access the latest and most complete information for any requirement, no matter the stage of development or tools used. This real-time capability boosts productivity by ensuring teams work with the latest data and reduces risks like delays and defects by finding issues early. In addition, Jama Connect accelerates your product, systems, and software development by managing user needs and product information across the end-to-end development lifecycle.
Only Jama Connect Delivers Live Traceability™ Across Best-of-Breed Tools
Other vendors lock you into inferior platforms. Only Jama Connect seamlessly integrates with your tools of choice across engineering teams. Only Jama Connect can manage the state of development across all integrated teams and tools. Jama Connect’s unique and industry-specific Traceability Information Models define the relationships and expected behavior across teams and tools.
Our customers consistently tell us that they chose Jama Connect over Codebeamer for the following reasons:
1. Ease of Use and High Adoptability
Jama Connect’s intuitive design and user-friendly interface make it easy for teams to adopt and use. Unlike Codebeamer, which can be complex and challenging for new users, Jama Connect ensures that teams can start managing requirements effectively with minimal training. Users insist on a requirements management and traceability solution that is easy to use so that both internal and external stakeholders can efficiently access, share, and review information in a single source of truth, increasing and speeding up the adoption across teams for a better ROI.
The ease-of-use is not only imperative for users but also for administrators. Jama Connect offers an intuitive and user-friendly administration interface that enables admins to adapt the tool to their organization’s needs without having to learn overcomplicated configuration settings and concepts.
2. Modern Integration and Collaboration Capabilities
Jama Connect provides comprehensive traceability and impact analysis, enabling teams to manage change effectively and reduce the risk of errors. The platform seamlessly integrates with other best-of-breed tools (including Jira and Azure DevOps) in the development ecosystem, ensuring that teams can work efficiently without having to change their other development tools. In contrast, Codebeamer focuses on working solely with other PTC tools and its own limited application lifecycle management (ALM) capabilities.
Modern product and software development requires optimal real-time collaboration between stakeholders. Jama Connect provides an enhanced collaboration experience with its communication streams and advanced Review Center, enabling both internal and external stakeholders with the capabilities to perform formal and iterative reviews.
3. Intelligent Engineering Management
Jama Connect empowers Intelligent Engineering Management by addressing a critical challenge faced by engineering and product development organizations: the lack of real-time KPIs and metrics during development. This gap often leads to delays, budget overruns, and product defects or recalls. Jama Connect uniquely transforms traceability into a measurable instrument, enabling teams to track real-time metrics and KPIs throughout the product development process. By providing a comprehensive overview of project progress and aligning it with required processes, teams can identify gaps early, mitigate risks, and avoid missed requirements. With its Live Traceability™ and integrations with other best-in-breed engineering tools, Jama Connect ensures that both internal and external data are seamlessly managed, driving informed decision-making and on-time project delivery.
4. Strong Customer Support
We know that our customers need a support team that makes them a priority. That’s why Jama Connect offers unparalleled customer support (including 24/7 support for any production outages), with dedicated customer success teams that work closely with you to ensure you achieve your goals. In contrast, Codebeamer’s support can be limited, making it difficult for your teams to get the help they need when they need it.
5. Scalable and Flexible
Jama Connect is highly adaptable, making it suitable for a wide range of industries and project sizes. Whether your organization is in automotive, aerospace, medical devices, or another industry, Jama Connect can be tailored to meet your specific needs, often getting you up-and-running quickly with custombuilt data frameworks to satisfy your industries regulations and best practices. Additionally, the platform offers flexible deployment options, including cloud and self-hosted, giving you the freedom to choose the best setup for your organization.
6. Fastest Time to Market/ROI
Deploy Jama Connect’s easy-to-use interface in weeks, not months, with easy updates and high performance. Preconfigured frameworks are built-in to satisfy industry regulations and help teams ease the path to compliance, along with in-house industry focused subject-matter experts and exceptional customer support.
7. Lowest Total Cost of Ownership
With simple and straightforward administration and no need for custom scripting or continuous updating, Jama Connect has the lowest total cost of ownership in comparison to Codebeamer. Jama Connect scales easily without big infrastructure investment, and with unlimited no-cost access for extended internal/external stakeholders, all team members can be involved with additional costs.
https://www.jamasoftware.com/media/2024/11/2024-10_codebeamer-compare-ebook-1-2.jpg512986Jama Software/media/jama-logo-primary.svgJama Software2024-11-12 03:00:182024-12-03 11:25:11The Clear Choice: Why Jama Connect® Surpasses Codebeamer for Requirements Management and End-to-End Traceability
In this blog, we recap our webinar, “Standardizing Requirements Management Across the Organization” – Click HERE to watch it in its entirety.
Standardizing Requirements Management Across the Organization
Is your organization struggling with costly production failures?
A survey by Engineering.com revealed that a staggering 83% of companies faced production outcome failures — such as significant delays, cost overruns, product defects, compliance gaps, recalls, omitted requirements, and extensive rework — often stemming from inadequate requirements management.
In contrast, implementing standardized requirements management can lead to enhanced consistency, repeatability, predictability, and a distinct competitive advantage.
In this webinar, Matt Mickle – Director, Solutions & Consulting at Jama Software, explores the advantages of establishing, implementing, and enforcing requirements management standards within your organization.
In this session, you will learn:
The key benefits of standardizing requirements management across your organization
Common challenges encountered during the standardization process
How to leverage Jama Connect® to implement best practices and streamline your requirements management standards
BELOW IS AN ABBREVIATED SECTION OF THIS TRANSCRIPT
Matt Mickle: Hello and thank you all for joining today. Perhaps requirements management is a new task for you, or perhaps you have been doing it for many years. Hopefully, I can provide some value for any of those people listening regarding standardizing requirements management within their organization. Personally over the last 10 years working at Jama Software as a consultant and over hundreds of implementations that I’ve worked on with our customers on developing their process and modernizing their requirements elicitation, I have developed a strong bias towards the need for standardization is definitely a crucial area which if correctly developed within an organization, will actually improve the speed of product development rather than slowing it down.
So on the agenda today, we will talk about how standardizing requirements management processes can benefit your organization and also the challenges that organizations commonly face when developing a standardized process. Then we’ll dive into how Jama Connect can make the successful and sustainable implementation of standardized requirements management processes within your organization a reality. Before we get started, let’s make sure that we are aligned on what we mean when we say requirements management.
Requirements management, sometimes called requirements engineering or requirements definition is the process of documenting, analyzing, tracing, prioritizing, and agreeing on requirements, and then of course controlling change in communication to relevant stakeholders. It is a continuous process throughout product development and the process that companies use to take their raw ideas and turn them into detailed requirements. The pillars of requirements management include requirement definition, requirement verification and validation, and requirements change management. The most fundamental aspect of any requirements management activity is the need for communicating effectively.
Mickle: While requirements are originally elicited within the first step of the product development lifecycle, it is important that we keep in mind that they are part of a bigger picture and that ownership of that bigger picture may vary. For example, the governance of requirements management processes may fall under your organization’s project or portfolio management office and can be controlled centrally or sometimes companies may choose to control that in a project-specific way. Just as there are multiple approaches to the ownership of requirements processes, there is no one-size-fits-all requirements management standard framework, and there are many standards that are proven to work. Examples include those defined in the system engineering body of knowledge or the business analyst body of knowledge or others listed here. I’d like to point out a great quote from Aristotle. “It is the mark of an educated mind to be able to entertain a thought without accepting it.”
I think this really represents the value for considering and taking in from multiple approaches within your organizations in order to drive for successful adaptation of standards. So now that we have level set on our definition of requirements management and have established that ownership and approach can vary from company to company and even from project to project, let’s move on to our main topic. Standardizing requirements management across the organization, a concept that can be entirely agnostic and universally beneficial no matter your product development structure or methodology.
Now there is no argument that requirements management has increased in prominence in the recent years and regardless of industry, it is largely no longer considered a nice to have for development, but rather an absolute necessity. Yet for most implementation details often remain ambiguous and therefore difficult to apply. We can be entirely committed to getting the requirements right with a little consensus on what getting the requirements right actually means. It can be hard to escape the manifestations of the Mobius strip and requirements management such as the statement requirements management is planned in the requirements management plan. This is where standardization arrives to save the day.
The standard becomes our requirements management plan versus being a separate effort for each product or project that detracts from effort that could be focused instead on development. There is a massive evidence demonstrating the benefits of defining, deploying, and enforcing requirements management standards for your organization. Those benefits include providing a framework for efficiency, predictability, repeatability, and a benchmark for improvement, better traceability, mitigation of risk, easier training and onboarding, and the elimination of unnecessary rework. Additionally, standardization allows organizations to leverage a diverse array of resources while maintaining consistent results, and it also provides transparency both in process and in work performed.
Just as the concept of reusing our requirements and leveraging the work that is done already, which is highly appealing, standardization of requirements management processes could be viewed as reusing our processes for managing requirements for repeatability of success. A strong case for standardization is illustrated in the quote, “Quality is free but only to those who are willing to pay heavily for it.” What you put in is what you get out. Valuable products are a result of high-quality inputs as well as high-quality processes. Even perfect requirements can’t withstand the damaging effects of a poor process. The pressure to reduce development time is only ever-increasing and standardization liberates development teams from worrying about the mechanics of development process and allows them to instead give their full focus to solution development.
Consider the quote from Lee Iacocca, the former CEO of Chrysler. “You can have brilliant ideas, but if you can’t get them across, your ideas won’t get you anywhere.” Now imagine a new tech company that is developing a revolutionary product, but everyone is trusted with their own process. This causes teams to work in silos. They develop strong processes but with little alignment. Eventually, their misinterpretation with one another can lead to bugs or the wrong things being developed, causing delays and extensive meetings to try and realign. What they can do is define a standard process for communicating and aligning on the requirements. And with a communication plan and regular alignment meetings, this will them to coordinate more effectively and have the same vision about what they’re building.
Earlier I stated that the most fundamental aspect of requirements management is the need to communicate effectively. If establishing requirements management standards seems like a heavy-handed approach, then just try polling a cross-section of your development team to define the difference between validation and verification, and maybe you’ll reconsider. It is critical that the foundations of your requirements management process are uniformly understood and applied across your organization in order to ensure quality with your final product. Now you might be wondering if the case for standardization is so strong, then why isn’t everyone doing it? This is a fair question and the rationale is likely due to previous challenges they have faced or perceived challenges. So let’s take a few minutes to explore what challenges teams may face in their efforts for standardization.
Mickle: One common challenge is that we need to correct the misconception that standardization stifles creativity and response time. Standardization of requirements management is about removing the things that get in the way of your work rather than adding more work to your work. Other common misconceptions that face a standardization effort are that it’s too time-consuming or it’s too costly to implement or that it will disrupt development and progress. Given the overwhelming statistical correlation between poor requirements and project failure, it’s pretty hard to bear these arguments too much weight. The basic thought is that if you can make time to fix your problems, then you can definitely make time to plan so that those problems don’t occur.
Okay, so now we have discussed some of the benefits and the perceived challenges to a standardization of a requirements management approach. Let’s take a minute to reconsider how to move forward. The first step is the definition of a process framework. That process framework may include policies and standards, processes, procedures, training and tools, and please note that there’s a surprising amount of debate over the definitions for the hierarchy between the terms listed on this slide.
My intent is to illustrate the importance of establishing the framework not to prescribe the individual elements or their order. Over the past several years, Jama Software has developed comprehensive solution offerings in many industries. Those include a process, framework, definition, or the different verticals. We are constantly working on improving those frameworks as the industry changes, as new standards and maturity models are introduced, and as we learn from our customers and industry experts that we work very closely with.
Here is an example just to give you an idea of what a concept of a process framework would look like. Basically taking the foundations and breaking them into standards or policies and then into processes and supporting procedures. Here are some additional supporting elements that are extremely critical and must be taken into consideration. People, put the necessary resources in place to properly apply requirements management and recognize and develop the skills needed for the functions needed. Processes, it’s important to standardize and formalize processes at the project and product levels in order to ensure good requirements management practices are consistently applied.
https://www.jamasoftware.com/media/2024/11/Standardizing-Requirements-Management-Across-the-Organization.png5121024Matt Mickle/media/jama-logo-primary.svgMatt Mickle2024-11-05 03:00:062024-11-01 12:11:07[Webinar Recap] Standardizing Requirements Management Across the Organization
Jama Connect® Features in Five: Jama Connect Advisor™
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, Katie Huckett, Senior Product Manager at Jama Software, will introduce viewers to Jama Connect Advisor™, Jama Connect’s natural language processing (NLP) tool, designed to improve requirement quality.
In this video, learn how Jama Connect Advisor enhances your product management by:
Reducing authoring errors
Increasing clarity
Optimizing foundational product needs and requirements managed in Jama Connect Cloud
VIDEO TRANSCRIPT
Katie Huckett: Hi. I’m Katie Huckett, Senior Product Manager at Jama Software. In this video, I’ll introduce you to Jama Connect Advisor, an add-on to Jama Connect Cloud that uses engineering-based natural language processing to optimize requirements authoring. It helps you write effective, well-organized requirements with speed and accuracy.
We’ll explore how Jama Connect Advisor can enhance your product development by reducing errors, increasing clarity, and optimizing the foundational requirements managed within Jama Connect Cloud. Jama Connect Advisor is designed to help teams author complex requirements quickly and accurately using AI and engineering-focused natural language processing. It minimizes disruption to engineering workflows while improving quality. How does it work?
Jama Connect Advisor applies the globally recognized INCOSE requirements rules and EARS syntax patterns. Even experienced engineers find it challenging to follow all forty INCOSE rules and six EARS patterns while writing even a single requirement.
That’s where Jama Connect Advisor steps in to streamline the process and enhance productivity. Now I’d like to show you a demonstration of how Jama Connect Advisor enables teams to intelligently improve requirements quality and usability, minimize requirement ambiguity and contradictions, which are the source of seventy to eighty-five percent of rework, and save time authoring, reviewing, analyzing, and updating requirement statements.
Huckett: There are a few different ways that you can use Jama Connect Advisor within the Jama Connect Cloud application.
Let’s start by adding a new requirement. Once you’ve added your requirement into the description field, you’ll notice the highlighted text to analyze the prompt underneath the description field. Once you’re ready, go ahead and select the text that you’d like to analyze and select analyze selection.
Underneath the description field, you’ll see a quick summary of your INCOSE score as well as any errors found, if any. You can move on at this point and save your item, or you can go ahead and view the details if you’d like to make changes at this point. So I can see on the slide over panel, the text that’s been analyzed, what my INCOSE score is, eighty-seven percent, and then the different identifiers that I’ve flagged it for the INCOSE rules. Underneath, you’ll see the EARS errors, if any were found. You’ll also see some information about the EARS notation pattern that your requirement might align with. I’m gonna go ahead and save this item, and I’ll wait to make my changes in a moment.
Now that I’ve saved that, let’s say I want to analyze a whole group of existing requirements. I’m going to go ahead and analyze all items within my set on the side here. So I’ll select all items and you’ll notice the batch analyze button, appears in the top right-hand corner. Once you select that, you’ll be given a summary view of what will be analyzed. So you can see I’ve got seventeen items selected here. All seventeen of those items happen to have a Jama Connect Advisor-enabled field on it, and then we have thirty-four fields per, these items. So it appears we have two Jama Connect Advisor enabled fields, per each item within this group.
Once you select analyze, the slide of our panel will pop up on the right-hand side. You’ll notice your group of requirements. Each item is listed at the top within this drop-down. You can navigate with the drop-down or the directional arrows. And then underneath, we also have a field drop-down. So as I mentioned, we have two fields per item type on this particular example. So I can swap between those as well either using the drop down or the directional arrows to move through.
So now that I’ve come in here and I see the, recommendations, I’d like to go in and edit my item to make some changes. So here, I want to remove some of the items that were flagged. I’m gonna remove this and just update this to say, you know, users can create a login using we don’t wanna use pronouns, per that flag. So I’m gonna change this to using an Apple ID, email.
Huckett: I’m gonna update this to be an actual logical condition with or social media. And then I’m gonna remove the example of LinkedIn because I don’t necessarily need that, and I’ll just update that to end the sentence there. Once I’ve made my changes, I can select the text again in the edit quick edit mode, analyze the selection, and I can see here my INCOSE rule score is now a hundred percent. I still have to deal with my ears errors, but so far so good on INCOSE.
I can view my details again in the slide-over panel and update here. I can also close that back out, and I can return to my batch analysis results by selecting the latest analysis link at the top, and that will take me right back in where I was before I made those changes. Now I can go ahead and save my item and complete those changes going forward. If I want to work through these requirements across multiple sessions or maybe I just wanna have a benchmark of what my score was before I started making my edits, you can then generate a report within the slide-over panel.
That will open up in your reports history page where you can download the report into Excel.
Once you open the report that was generated, we have a few different tabs you can work through in the worksheet. The first one just gives you some general information. What’s the average score of your requirements, the minimum, and maximum score, your total number of valid requirements, and then if you did have any invalid requirements as well. The file analysis reports, tab will give you a complete breakdown of all the requirements that were analyzed, their score, and then any corresponding INCOSE flags that may have popped up within the analysis.
We also have an explanation of each INCOSE flag as long as with their associated description. And then if your, report did happen to include any invalid requirements for any reason, those will be included in their separate sheet as well. Thank you for watching this demonstration of Jama Connect Advisor. If you would like to learn more about how Jamala Connect can optimize your product development process, please visit our website at jamasoftware.com
If you are already a Jama Connect customer and would like more information about Jama Connect Advisor, please contact your Customer Success Manager or Jama Software Consultant.
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.
