Tag Archive for: Requirements & Requirements Management Page 4
Tag Archive for: Requirements & Requirements Management
In this blog, we’ll recap a section of our eBook, “Fueling Progress: Solutions to the Biggest Challenges Slowing Oil & Gas Projects” – Click HERE to read the entire thing.
Fueling Progress: Solutions to the Biggest Challenges Slowing Oil & Gas Projects
The oil and gas industry is a cornerstone of the global economy, but it faces a growing set of challenges in an increasingly complex and competitive landscape. From fluctuating market dynamics and stringent
environmental regulations to technological advancements and the demand for operational efficiency, companies in this sector must navigate a series of critical obstacles to remain resilient and sustainable.
In this eBook, we explore the top challenges shaping the future of the oil and gas industry, providing insights into how businesses can adapt and thrive amid these shifting pressures.
Energy Transition and Decarbonization
The global shift toward clean energy and reducing carbon emissions poses a significant challenge for oil and gas companies. The pressure to decarbonize operations, meet regulatory standards, and invest in renewable energy sources is growing. Balancing the need to reduce greenhouse gas emissions while maintaining energy supply and profitability remains a key issue.
Investment in carbon capture, utilization, and storage (CCUS) technologies is becoming crucial for oil and gas companies as they seek to reduce their carbon footprints while continuing operations. CCUS can help mitigate the environmental impact of fossil fuel production by capturing CO2 emissions before they are released into the atmosphere. Additionally, oil and gas companies are increasingly expanding into renewable energy sectors like solar, wind, and hydrogen to diversify their portfolios and align with global efforts to decarbonize energy. Navigating complex carbon regulations, such as emissions trading systems and carbon pricing, also requires strategic planning to minimize costs while meeting government and international compliance targets.
KEY CONSIDERATIONS
Investment in carbon capture, utilization, and storage (CCUS) technologies.
Expanding into renewable energy sectors like solar, wind, and hydrogen.
Navigating complex carbon regulations and pricing mechanisms.
Volatile Market Conditions
The oil and gas market is highly sensitive to global political, economic, and environmental factors. Fluctuations in oil prices due to geopolitical tensions, supply chain disruptions, or demand fluctuations (such as those caused by pandemics or global economic shifts) can severely impact profitability and investment planning.
Geopolitical risks, such as conflicts in oil-producing regions or shifts in international relations, can lead to sudden and significant fluctuations in oil prices. This volatility is further exacerbated by disruptions to global supply chains, economic recessions, and unpredictable demand patterns due to factors like pandemics or rapid changes in energy consumption behavior. Oil and gas companies must remain agile, continuously assessing market conditions and adjusting their production strategies accordingly. Managing these fluctuations requires strong financial risk management, flexible supply chains, and forward-thinking strategies to hedge against market downturns.
KEY CONSIDERATIONS
Geopolitical risks, such as conflicts in oil-rich regions.
Supply and demand imbalances.
Economic slowdowns affecting global oil consumption.
Technological Innovation and Digital Transformation
As the industry evolves, there is increasing pressure to adopt new technologies that will improve operational efficiency, safety, and sustainability. The integration of digital tools like artificial intelligence (AI), automation, and the Internet of Things (IoT) can help reduce costs and improve performance, but the high cost of implementation and cybersecurity risks are barriers.
Digital transformation in the oil and gas industry presents an opportunity to enhance operational efficiency, but implementing these technologies comes with challenges. Predictive analytics, driven by artificial intelligence and machine learning, can optimize production processes and enable predictive maintenance, which reduces downtime and improves asset longevity. However, with the increasing reliance on digital systems, cybersecurity risks also rise, making data protection a critical concern. Additionally, digital transformation requires a workforce with new skills, and companies must address these gaps through retraining and attracting tech-savvy talent to ensure successful implementation of these innovations.
KEY CONSIDERATIONS
Leveraging data analytics for predictive maintenance and production optimization.
Enhancing cybersecurity in increasingly digitized operations.
Addressing workforce skill gaps to support digital transformation.
Oil & gas companies that develop products such as undersea robots that support exploration and delivery face their own set of challenges. First, the use of document-based technology or siloed point software solutions fails to keep up with the increasingly complex hardware and software systems and subsystems that must perform flawlessly together. Second, reliance on manual tools that are not optimized for managing a complex development process often results in inefficient teamwork and late detection of defects.
As a result, companies find themselves:
Relying on inefficient meetings or email communications involving internal, partner and supplier teams to discuss, review and approve product requirements and tests
Missing opportunities to detect defects and other issues early in the development process when it is typically easier and less costly to ensure product quality and performance
Incurring contractual penalties or losing revenue due to delayed availability or delivery of products
https://www.jamasoftware.com/media/2024/11/2024-10_fueling-progress-challenges-oil-and-gas-ebook-1.jpg512986Jama Software/media/jama-logo-primary.svgJama Software2024-11-26 03:00:262024-11-21 10:43:49Fueling Progress: Solutions to the Biggest Challenges Slowing Oil & Gas Projects
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:182025-04-03 10:12:56The Clear Choice: Why Jama Connect® Surpasses Codebeamer for Requirements Management and End-to-End Traceability
In the world of automotive and semiconductors, where the pace of technological innovation seems to accelerate daily, staying ahead of trends is critical. That’s why we sat down with Neil Stroud, Jama Software’s industry expert with decades of experience spanning major players like Intel, Arm, and Samsung. Neil has been at the forefront of the functional safety and semiconductor evolution, witnessing firsthand the challenges and transformative changes that shape these industries.
In this exclusive interview, Neil shares his unique perspective on the latest industry dynamics, the impact of global supply constraints, and how the automotive industry’s strategic relationships with semiconductor vendors are evolving. He also discusses Jama Software’s role in helping both sectors address increasingly complex requirements and integration challenges, driving efficiency and reducing risk across the supply chain. Join us in exploring how Jama Connect empowers companies to manage complexity, enhance traceability, and accelerate their time to market.
Driving Innovation: Quarterly Automotive & Semiconductor Trends with Neil Stroud
Kenzie Jonsson: Thanks for sitting down with me today, Neil! I’d love it if you could spend a little bit of time telling us about your background and career path.
Neil Stroud: Prior to joining Jama Software back in April of this year, I’d spent most of my career in the semiconductor industry, working for companies like Samsung, NEC, and PMC-Sierra. I also spent 12 years with Intel, and then moved into the IP space with Arm who are one of the key players in semiconductor IP. Directly before joining Jama Software, I spent time with CoreAVI, a niche software company in the safety-critical graphics space. Almost twenty years of my career has been spent in the functional safety domain. It wasn’t by design; it was more by accident. I didn’t set out to get into that domain at all. It all came about through my time at Intel where I was calling on a big industrial automation company and they asked me the question, “Hey, so when are you going to start supporting functional safety with Intel architecture?”
Of course, at that point, I didn’t know what it was, what it meant, what it was all about. One thing led to another, and I stumbled into the world of functional safety and was given a great opportunity at Intel to go… I was going to say, go and lead it, but it was more me volunteering and saying, I think we should be doing this. And Intel the senior leadership at Intel saying, “Oh, go on then, go do it.” That’s exactly what I did. So, it was quite nice because you’re acting as a startup within the safety of a big corporation like Intel. At that point you start to look at the fundamentals – what does safety look like? What do we need to do as a company? How do we sell it? How do we make money out of it? What are the technical issues? What problems are the industry facing? That kind of stuff. So, I pretty much became a GM of my own startup at that point, which was a great experience.
That was back in the day when complex semiconductor functional safety wasn’t really a thing. So, we were blazing the trail, not just for Intel but for the whole industry. So, little did I know back then where it would lead. It’s been so much fun. That’s also what took me to Arm – to drive the whole functional safety strategy across their ecosystem. So, all of that obviously led me into adjacent businesses especially automotive, as safety is of paramount importance where I worked with the big OEMs and throughout the supply chain. Now here I am at Jama Software bringing all of that experience of semiconductor, automotive, and software and apply that into the requirements management tools domain to drive our presence and growth in the automotive and semiconductor segments.
Jonsson: What changes have you been part of at Jama Software recently to help us better meet the needs of our customers?
Stroud: It’s a really interesting time to join Jama Software. Obviously, we’ve been successful as a company over the preceding years. I’m amazed by the number of different market segments that are using Jama Connect. There are some obvious ones like automotive, semiconductor, medical, consumer electronics, and aerospace and defense. But there are some emerging segments as well, which is great to see, like insurance companies and state departments and beyond. Clearly, Jama Connect is a tool that transcends verticals. But of course, we need to be able to tweak and tailor that to accommodate the unique needs of each market segment. Functional safety and cybersecurity are great examples of these differences. That’s what’s exciting as part of the change with Francisco Partners acquiring us back in April for $1.2 billion. That to me is a leading indicator that they’re betting on us to continue growing and we are investing heavily to continue to delight our current customers and of course help new customers achieve new levels of innovation. Placing that bet is exciting for all of us at the company. As a result, one of the changes we made at that time was to really double down on the vertical focus. So, bringing in an organizational structure that allows us to do and in turn drive even more alignment with the needs of each market segment.
It’s good for us. But more importantly, it’s good for the customers because we can talk in their language, we can better understand their problems, and of course we can partner with them to solve their problems. And that in turn means tailoring our product to better suit their needs. So, it’s a win-win. It’s a confirmation of the importance of those verticals to Jama Software and sends a clear message to that we are listening and here to partner with them on their growth journey. So, it’s exciting for me and I see that excitement across the whole company.
Jonsson: Can you tell us what you’re seeing in the industry with the conversations that you’re having with our customers and prospects?
Stroud: Well, I cover both automotive and semiconductor industries. There’s obviously a lot of overlap between the two, and I think that’s an increasing trend we’ve seen over the last few years. The automotive guys have been building a lot more of a strategic relationship with the semiconductor vendors. Not least because when the supply constraints kicked in a couple of years ago, production lines were coming to a halt because they couldn’t get hold of the smallest, tiniest, cheapest components. And at that point, it is interesting how it created a real forcing function. The automotive segment said at that point, “Right, we aren’t going to get burnt again.”
So, they did one or two things. Some went out and tried to tie down the semiconductor vendors contractually to say, “Look, in the event that this happens again,..” and it will happen again because the semiconductor industry tends to work on about a seven-year cycle of oversupply versus constraint, “we want to guarantee our component supply.” The car OEMs and tier-one suppliers obviously didn’t want to get caught in that again. I don’t have visibility into how successful those discussions were, but I don’t think it will necessarily prevent a recurrence. The good news is that there is huge investment going into building new fabs that will provide significant capacity increases in the coming years.
The other interesting dynamic that happened was some of the auto guys said, “Well, screw that. We’re going to do our own silicon.” It sounds easy when you say it quickly, but there’s an awful lot to it when you commit to that solution. Questions like, “Okay, so how are you going to do that?”, “Are we going to go and engage with a design house or we’re going to hire a team of semiconductor design engineers,” “Which fab supplier will we use?” “Will they guarantee supply?”
It’s not a trivial undertaking and to make it work from an ROI perspective it’s probably a ten-year journey. And in the meantime, you’ve still got to work with what you’ve got. The other issue is once you get down that path, you are committed and it’s an expensive commitment to make. The downside is you don’t get the benefit of volume that the big guys like Qualcomm, Samsung, MediaTek, or NVIDIA can offer you. They build millions and millions of chips and can amortize the cost across many customers and markets. If you’re building your own, you don’t get that advantage, but you mostly own your own destiny. So, pros and cons.
So that’s one dynamic. I think the other dynamic we’ve seen in automotive generally over the last five years is a repositioning of what’s important. If we go back, even just five years, we all thought we would be driving autonomous vehicles right now. There’d be mass deployment. You and I would both have one on the drive. Of course, that hasn’t happened because we all realized how difficult it is. I think we were in denial for a while, but that forced us to pivot to solving the software defined vehicle challenge. If we can get that taken care of, then that kind of leads us to the autonomous world anyway. And we can solve it in bite-sized chunks. So thankfully the automotive industry and the semiconductor industry, and probably lots of other industries now are focused on a software-defined vehicle as an intermediate step.
Solving this challenge doesn’t just apply to road vehicles. I think when you look at industrial automation, that’s the same. Do they want to get full autonomy? Of course they do. Is it a challenge? Yeah, it is. So, software-defined has a role to play there. Same in A&D, same in a lot of the other verticals. So, there are a lot of synergies between the verticals as well. That created, I think, clarity, but it also created a seismic shift for the car OEMs in that the OEMs themselves, and I’m talking more about the incumbent suppliers, the big guys like VW, Mercedes, Ford, GM and others. History shows they’re so used to being completely in charge of their own destiny – when you need something, you just put a team together and you go build it. Those days are gone. You look at complexity in a modern vehicle, whether it’s the hardware or the software, you just can’t do that these days. It’s not scalable.
So, you have to rely on the supply chain to drive the innovation and deliver those pieces, those elements, and then you as the OEM have to integrate them. But that’s not a world they’re used to. And it obviously introduces a whole world of complexity.
Stroud: That’s another area where using Jama Software really pays dividends to ensure the whole supply chain is seamlessly connected from a requirements perspective resulting in faster design and delivery across multiple vendors and a better-quality product overall. A modern vehicle can have upwards of 100 million lines of code going into a modern high-end vehicle and this is increasing exponentially. Those software elements are coming from a hundred different vendors. Some of those are safety-related, and some of those are security-related. All of a sudden as an OEM, I’m responsible for integrating all of that, checking it works together, checking it’s still safe, checking it’s still secure, and then rolling it out through the door for consumers to go and purchase a new vehicle.
At the same time, vehicle suppliers can use this new SDV approach to drive new business models that allow post-sales upgrades and updates. If a car doesn’t have a feature on the day of sale, in a year’s time the owner could say, “Hmm, it’d be nice to have that new feature.” You log into your account, put your credit card details in, and as if by magic, the new feature arrives over the air to your vehicle the next day. That’s a whole new world and we are only scratching the surface today.
So, I guess the punchline is from our perspective, and doing what we do, it’s all about efficient requirements management and traceability. This applies not just to the OEMs, but throughout the supply chain as well, to ensure the elements from those hundreds of different vendors all come together. Those requirements have got to be exquisitely accurate and all the independent interdependencies mapped out correctly to be sure that you’re not violating a safety goal or creating a bug in the system.
This way you get into traceability… How well is my project going? How healthy is it? How many of those requirements are covered right now and tested and using that capability to reduce the number of recalls, drive efficiency in the design team, reduce the risk, all those good things. Of course, this level of detail isn’t just important to the engineering teams. It can also be rolled out to senior management who are likely more interested in risk, cost, time-to-market and so on.
So, the market’s really coming to us. Jama Software is now the largest supplier of requirement management solutions overall, which we’re immensely proud of. But we have to learn from the market and our customers how Jama Connect changes grows and morphs as a solution to enable that ubiquitous risk reduction and efficiency improvement. So, there are some big factors at play.
We’ve done very well in the semiconductor space overall, but it still frightens me to see how many spreadsheets are used to manage the business in the big semiconductor companies. And that’s speaking from experience because I lived in that world for a long time. There are way too many spreadsheets out there for doing requirements tracking. When you’re working that way, there’s no single source of truth and that will get you into trouble, guaranteed. It will cost you big with bugs in the silicon. So, it’s imperative to partner with the semiconductor industry and really drive change, accelerate innovation and solve tomorrow’s supply constraints. That’s on the chip design side, but also more recently, we’ve got the CHIPS Act, which is kick-starting a massive investment in the semiconductor industry to drive fab capacity to meet the huge growth in demand for chips.
So, we see the big players such as Intel, Samsung, and TSMC, all investing billions and billions of dollars to put fabs into place to meet this growth in demand and technology, which is exciting. The challenges are different to the auto market but guess what, these chip manufacturers need robust requirements management to run their business. And again, a lot of it’s been running on spreadsheets for a long time.
Now, we’re seeing, of course, headwinds in both industries. We still see that with EV vendors on the automotive side. We see even today challenges in the semiconductor industry with some consolidation of cost and trying to get costs under control. Jama Software has a critical role to play in that transformation. We can help drive efficiency and shorten cycles and time-to-revenue. All those things play into huge cost reductions for all. We are using our expertise in both product and deployment to educate and drive incremental success for our customers.
Kenzie Jonsson: Thank you for your time today, Neil! I really enjoyed this conversation, and I look forward to catching up with you next quarter!
https://www.jamasoftware.com/media/2024/11/2024-10-3-driving-innovation-neil-stroud-1.jpg512986Neil Stroud/media/jama-logo-primary.svgNeil Stroud2024-11-06 03:00:512024-11-06 09:38:21Driving Innovation: Quarterly Automotive & Semiconductor Trends with Neil Stroud
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.
https://www.jamasoftware.com/media/2022/11/FIF-Req-Advisor-5in5-intro-22.jpg10801920Katie Huckett/media/jama-logo-primary.svgKatie Huckett2024-11-01 03:00:132024-11-05 09:13:20Jama Connect® Features in Five: Jama Connect Advisor™
Tackling Industrial Manufacturing’s Biggest Challenges: Solutions That Work
Industrial manufacturing is undergoing a transformation driven by technology, market demands, and a rapidly evolving workforce. However, this evolution brings its own set of challenges that manufacturers must navigate to remain competitive. Below, we’ll explore the top challenges in industrial manufacturing and offer practical solutions to address them.
1. Supply Chain Disruptions
The Challenge: Global events like the pandemic and geopolitical tensions have exposed the vulnerabilities of supply chains. Material shortages, delays, and fluctuating costs have become routine, making it difficult for manufacturers to meet production targets.
The Solution:
Diversified Sourcing: Manufacturers should explore multiple suppliers, ideally in different regions, to reduce the impact of disruptions in one area.
Advanced Analytics and Forecasting: By leveraging data analytics, manufacturers can predict potential disruptions and adjust procurement strategies to maintain inventory levels.
Digital Supply Chain Management: Implementing technology like real-time tracking and automated inventory management systems ensures better visibility and responsiveness across the supply chain.
2. Talent Shortage and Skills Gap
The Challenge: As industrial processes become more automated and technical, there’s a growing need for skilled labor, particularly in areas like robotics, data analytics, and equipment maintenance. However, the industry faces a shortage of qualified workers due to retirements and a lack of interest from younger generations.
The Solution:
Reskilling and Upskilling Programs: Companies can invest in training programs for existing employees, focusing on emerging technologies and technical expertise.
Collaboration with Educational Institutions: Partnering with local schools and universities to create apprenticeship programs and internships can help build a pipeline of future talent.
Adoption of Automation: Automating repetitive or dangerous tasks can offset the impact of labor shortages while enhancing operational efficiency.
The Challenge: Industry 4.0 technologies, including IoT, AI, and machine learning, offer vast opportunities for improving manufacturing processes. However, integrating these technologies can be expensive and complex, especially for small and medium-sized enterprises.
The Solution:
Start Small, Scale Gradually: Manufacturers should begin by digitizing a single aspect of their production (e.g., predictive maintenance) and expand as they see ROI.
Cloud-Based Solutions: Cloud platforms offer scalable, cost-effective ways to implement Industry 4.0 tools without a significant upfront investment in infrastructure.
Cross-Department Collaboration: Ensure alignment between IT, engineering, and operations teams to facilitate seamless integration and minimize disruptions during implementation.
4. Meeting Sustainability Goals
The Challenge: Governments and consumers are increasingly demanding sustainable practices from manufacturers. This includes reducing emissions, minimizing waste, and adopting environmentally friendly materials. However, transitioning to green manufacturing can be costly and complex.
The Solution:
Energy Efficiency Audits: Conduct regular audits to identify areas where energy consumption can be reduced, whether through upgrading equipment or adopting renewable energy sources.
Circular Economy Practices: Embrace recycling and remanufacturing to minimize waste, both in production and post-consumer use of products.
Collaboration with Stakeholders: Partner with suppliers and customers to promote sustainable practices across the entire value chain.
5. Cybersecurity Risks
The Challenge: With the growing adoption of digital technologies comes an increased risk of cyberattacks. These attacks can disrupt production, compromise sensitive data, and damage a manufacturer’s reputation.
The Solution:
Regular Security Audits: Conduct frequent assessments of your digital infrastructure to identify and address vulnerabilities.
Employee Training: Train staff on cybersecurity best practices, particularly in recognizing phishing attacks and securing devices.
Robust Incident Response Plans: Develop and test response plans to minimize downtime in case of a cyberattack, ensuring quick recovery and damage mitigation.
The Challenge: Manufacturers are under pressure to produce more custom products, reduce lead times, and improve quality—all while maintaining efficiency. Meeting these demands often strains existing processes and resources.
The Solution:
Lean Manufacturing: Implement lean principles to eliminate waste in production and streamline processes, improving both speed and efficiency.
Automation and Robotics: Invest in robotic process automation to handle repetitive tasks, reducing human error and speeding up production.
Flexible Manufacturing Systems: Adopt systems that can easily switch between different product types, accommodating the increasing demand for customization without sacrificing efficiency.
Conclusion
Industrial manufacturing is facing unprecedented challenges, but with the right strategies and technology, companies can navigate these obstacles and position themselves for long-term success. From investing in workforce development to embracing digital transformation, the solutions are within reach. By proactively addressing these challenges, manufacturers can enhance their competitive edge in an increasingly dynamic market.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Steven Meadows and Kenzie Jonsson.
https://www.jamasoftware.com/media/2024/10/2024-10-24-tackling-industrial-manufacturing-challenges-1.jpg512986McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2024-10-24 03:00:092024-10-15 13:24:13Tackling Industrial Manufacturing’s Biggest Challenges: Solutions That Work
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.![[Webinar Recap] Key Systems Engineering Skills: Critical Thinking and Problem Framing](https://www.jamasoftware.com/media/2024/03/Key-Systems-Engineering-Skills-Critical-Thinking-and-Problem-Framing.png "[Webinar Recap] Key Systems Engineering Skills: Critical Thinking and Problem Framing")
