We are pleased to announce that Jama Connect™ was selected as a Top-Rated Application Lifecycle Management (ALM) Tool for 2019 by TrustRadius.
The annual Top-Rated ALM Tool award showcases today’s top-of-the-line products in ALM based solely on user feedback and satisfaction scores. These awards make the voice of the market the primary decider into the industry’s best ALM software.
According to TrustRadius, the Top-Rated awards are the most trusted in the industry because they are never influenced by analyst opinion, the vendor’s size, popularity, or status as a TrustRadius customer.
“We are proud to be recognized as a top ALM tool by TrustRadius alongside Jira Software from Atlassian,” said Jama Software CEO Scott Roth. “We’ve worked hard to deliver the best requirements, risk, and test management platform available on the market, and are honored to receive this recognition from such a highly regarded source.”
Enterprise Product Development Requires Modern ALM Tools
Though customers noted a variety of features and capabilities as the reason they rated Jama Connect so favorably in the ALM software category — end-to-end traceability, Review Center, and ease of use among the most commonly mentioned — it all came down to the superiority of the product.
“Jama Connect has won a Top-Rated award for application lifecycle management software based directly on feedback from their customers,” said Megan Headley, VP of Research at TrustRadius. “Reviewers praise the product’s core traceability and defect logging capabilities, and its overall superiority for requirements management and QA across development stages.”
And while TrustRadius boasts dozens of verified reviews from happy Jama Software customers — over 70% coming from large enterprises — one was highlighted in the ALM award announcement.
“Through Jama, we have been able to fully document our functional and technical requirements for multiple products/projects. Jama allows us to go through change cycle reviews with our client to show them the changes we have made during a cycle for their approval or clarification,” said Thai Trinh, Senior Business Analyst for an IT and services company. “This gives us accountability and traceability that could not be achieved in other more manual requirement gathering methods… For any project in which you need to document detailed requirements, especially software development, Jama would be well suited for use.”
Jama Connect Shares the Award with Jira Software
With both platforms earning an average of over 8/10 stars, TrustRadius actually named two award winners in the ALM tool category: Jama Connect and Jira Software.
Jira Software, the leading project management software, was rightly recognized for its unique organizational schema such as stories and epics, and overall flexible workflow, making it an ideal ALM tool for managing the work of developers and fostering collaboration among teams. Many organizations accelerate product development by connecting Jama Software and Jira Software for a bi-directional information flow of requirements and tasks.
The Future is Bright for Our Customers
All of us at Jama Software take pride in winning this award, but it wouldn’t be possible without our customers.
Over the coming months and years, we will be deeply focused on making improvements across our product line, adding new features, expanding our integration partners, and broadening our services offerings. These steps will ensure our customers have the most effective platform for requirements, risk, and test management available.
“Our customers are at the forefront of every decision we make, and we’re dedicated to providing them with a premier platform, outstanding customer service, and seamless integrations with other best-of-breed tools,” said Roth.
You’ll gain more confidence that your recently-released products avoid recalls, fines, or worse if you perform failure mode and effects analysis (FMEA) as part of your risk management.
Over the course of the hour-long webinar, Quillinan and Jama’s senior product manager, Joel Hutchinson, provided some key elements around the value of risk management and FMEA, and the importance of modernizing your risk management process to accommodate.
At the conclusion of the webinar’s presentation, the pair answered a range of questions from the hundreds of participants in attendance. Unfortunately, they weren’t able to get to everyone’s questions, but luckily they took some extra time afterward to answer some of those remaining, touching on everything from risk mitigation in aerospace to specific standards like ISO 14971.
We’ve compiled the questions (some of which have been slightly modified for clarity) below and encourage you to check out the full webinar and Q&A session here.
Q: Given that FMEA teams in companies can be non-permanent and have a fluid scope, which role should own and drive the activity overall?
Bethany Quillinan: I think the ownership role should align with those of the design/new product introduction process. If there is a project lead, then that person would make the most sense. There may also be a particular functional group who is given ownership of risk management, like Quality or Compliance teams. I think it really depends on the organization. What we want is alignment and integration within the design process, not a separate “silo” for risk management.
Q: Do you have any suggestions for criteria that would help when selecting a good FMEA facilitator?
Quillinan: A good facilitator will be someone who is well-versed in the FMEA process and the organization’s particular methodology, rating scales, etc. Additionally, the facilitator should be skilled in well, facilitation, and by that I mean having meeting management skills — things like tracking time, noticing when energy is low and a break is needed, drawing out quieter members, dealing with overly-dominant members, and generally equalizing the field. The facilitator should not get involved in the “content” of the FMEA, just the process itself. Ideally, there is also a content leader who can keep the team focused on the scope of the FMEA. That said, the facilitator should be aware of the scope, in case the team gets way off track and no one is calling it.
Gain Confidence in Your Risk Management Plan with Jama Connect. Learn how.
Q: Any suggestions for facilitators to keep people from taking things personally?
Quillinan: One engineer I worked with who had facilitated a lot of FMEAs shared a good technique — to ask people, “How could you make it fail?” And that turned around defensiveness to creativity. From a facilitation aspect, I think emphasizing that the analysis is “potential,” that we’re not saying it’s going to happen, but that it’s a just a possibility to consider. Depersonalizing statements can help — talk about “the design” vs. “your design,” for example. If someone is super defensive, the facilitator may need to call a break to let things cool down and talk to the person offline. Diplomacy is important!
Q: What you talked about is used in the automotive field which is very effective, but the aerospace industry tends to use FMEAs focused on managing the effects and quantitative failure rates (assuming constant failure rates). How do you get the benefits of automotive FMEA and, at the same time, satisfy aerospace FMEA requirements?
Quillinan: Having quantitative failure rate data to inform the discussion of the probability of occurrence is a big benefit. Failure mode, effects and criticality analysis (FMECA), where “C” is criticality analysis brings in more of the quantitative factor, and I see that terminology used more in aerospace. Satisfying specific Aerospace requirements is somewhat out of the scope of this presentation. In the context of the AS9100 quality management system standard, the requirement is to perform risk management, and FMEA is not prescribed but is a possible tool. Bottom line, I see FMEA as a prioritization tool rather than a reliability prediction. (In the early days, the military hoped to use FMECA to calculate an actual reliability metric, but it didn’t work out that way.)
Learn why Frost & Sullivan likes Jama Connect as a modern solution for risk management. Read the brief.
Q: What happens when multiple users are creating individual risk analyses? How do they collaborate if they are analyzing similar things?
Joel Hutchinson: As Bethany mentioned during her presentation, we understand that there’s going to be overlap in various FMEAs. An example of this is subsystems, which may have additional functionality that is only present at the system level. Risk management in Jama Connect helps the cross-functional team that works together to perform a risk analysis and has the ability to add view-only roles for context. One way of addressing this would be for the moderators of the two overlapping risk analyses to add each other as view-only roles to their respective analyses. This way, each cross-functional team is aware of what the other team is doing and how they’ve scoped their risk analysis.
Do you know where, when, and how intended Use FMEA (uFMEA for medical devices, per IEC 62366-1:2015) and software FMEA (life cycle requirements for medical device software per IEC 62304:2006+A1:2016)integrate into the requirements management process and product development timeline?
Quillinan: Generally speaking, risk management for usability, software, or any other aspect of a design should be integrated with the design process as soon as these aspects enter the design conversation. For example, early on during the initial “concept” phase, we need to be thinking about usability risks to inform the design concept and assist in evaluating different design routes to take. I also think useability/human factors could potentially be considered at any level of the product, so it could follow the same general timeline I showed in the presentation.
Likewise, for software, at the concept phase, the conversation will likely include software needs for satisfying customer expectations. From a systems standpoint, I feel the sooner the better. (I often use the initial rollout of the Healthcare.gov website for the Affordable Care Act (ACA) marketplace as an example of a “silo’d” approach to design. Each module was developed and tested in isolation and the “validation” of interfaces between modules was when it went live… and crashed.
We have to remember that the ultimate focus is at the system level — the end-user interaction with the product. In a medical device setting, most consultants are going to advise you to build in human factors considerations throughout the design process rather than waiting until the final human factors validation test on the finished design, for all the same reasons I described in the presentation.
Find out how to better manage medical device development in accordance withISO 14971. Read our guide.
Q: Risk Priority Numbers (RPNs) seem to always be subjective from one party to another, specifically the occurrence and detection. The occurrence is difficult to gauge when the failure mode and risks are new or when little-to-no history is available. For detection, we’ve had difficulty assessing the controls in place and how to rate them in terms of efficiency.
Quillinan: One way to help make the RPNs more objective is to establish and use consistent rating scales with descriptions that are relevant to your organization’s products and processes.
When there is no history and risks are new, the typical practice is to be conservative and give them high ratings. I often find that people have difficulty distinguishing prevention controls from detection controls.
Preventive controls typically act on the inputs to a process or are the controls during the process — think of mistake-proofing, for example not being able to choose an obsolete revision of a component for a bill of material (BOM) or having design guidelines to follow. Detection controls are after the fact and are inspections of the output of a process. In design, a typical detection control is a second person (or more) performing a design review.
Q: What is the relationship between design failure mode and effect analysis (DFMEA) and process failure mode and effect analysis (PFMEA), in terms of the failure modes and causes?
Quillinan: In DFMEA, we are looking at how the product could fail, and causes are from the design process itself; the assumption is that the process is being run correctly. In PFMEA, we’re looking at how the process could fail, assuming the product is designed correctly. Of course, this depends on FMEA scope. If we’re looking at a design for manufacturability, then we’re looking at how the design process could fail in terms of designing the product in a way that it can be easily and efficiently built.
https://www.jamasoftware.com/media/2019/07/Frost_and_Sullivan_Regulated_Industries.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2019-07-23 04:00:402023-01-12 16:51:32Answers to Your Questions About Risk Management and FMEA
No one sets out to create a product that’s an abject failure, which is one of the reasons Failure Mode and Effects Analysis (FMEA) exists.
FMEA is one way to identify the many ways something could go wrong with, among other things, a product or service. Understanding how a product could malfunction and what can be done to prevent it is an especially important task in safety-critical markets such as aviation, automotive, and medical devices.
Even still, development teams are under such tight deadlines to bring products to market quickly that approaches like FMEA can get brushed aside. Then, when a problem with an already-released product emerges, there’s a mad dash to correct things, which can throw an organization’s momentum, strategies, and resources off course.
“Do you want to think about this stuff early and ahead of time, when it’s private and less expensive?,” asks Bethany Quillinan, Senior Quality Systems Consultant with Oregon Bioscience Association, “Or, do you want to wait until it’s public, embarrassing, and you’ve had a big recall, or you’re testifying in front of Congress?”
What is FMEA?
Failure Mode and Effects Analysis (FMEA) originally started in the military in the 1940s, as a way to test mission-critical safety. It’s since expanded into a variety of industries, perhaps most notably in the automotive industry.
It’s mainly used for risk management with international standards like ISO 14971 and ISO 13485 (medical devices), IATF 16949 (automotive), and AS9100 (aerospace). In these types of regulated industries, FMEA is a way to accomplish a lot of risk management tasks to provide proof of compliance.
FMEA’s value extends far beyond the simple checking of a box for compliances purposes though. In performing FMEA, you’re not only capturing organizational knowledge around a given product, but you’re also simultaneously preserving that information for future development cycles. And by collecting that data, you’re including not only what could go wrong with a product, but also the decisions that were made, actions that were taken, and suggestions that were rejected.
“It preserves history for people,” Quillinan says. “It’s that hackneyed saying of, ‘If you don’t remember your history, you’re doomed to repeat it.’ We don’t want to do that in product development.”
Why Use FMEA?
One of the biggest mistakes a company can make around risk is thinking you’re infallible from a gigantic misstep. And when something like that does happen, it can be a major shock, complete with bad publicity, recalls, product corrections, lawsuits, and worse.
Even if those heavy consequences don’t come to bear, even light issues with your product can eat at your reputation and bottom line, sending everyone from engineers to your customer service team running backward and extinguishing fires. And if your teams are constantly running around firefighting, they’re not spending that time designing new features or pushing your product forward.
“So often, we’re reworking things, we’re rewriting things, we’re doing failure analysis, we’re appeasing unhappy customers, we’re fixing bugs,” Quillinan says. “From that day-to-day level, it’s a huge energy, time, and money drain of dealing with stuff after the fact.”
Plus, when it comes time to develop the next generation of product, you’ll likely already be behind on time and, odds are, the competition.
When to do FMEA?
It’d be hard to imagine a company releasing a product after a single design review.
In a similar way, FMEA is not a one-time endeavor limited to just the risk management process. FMEA should be done continuously throughout the development cycle and be used for different objectives at different points.
Unfortunately, many developers look at FMEA initially, realize it’s going to be a lot of effort, and try and do it all at once. And that can become overwhelming for everyone involved, further limiting the work to only those who are involved in the risk management process.
To ensure the best results with FMEA and risk analysis, it helps to have as many cross-functional minds thinking about what could go wrong with your product as soon as possible.
https://www.jamasoftware.com/media/2019/07/Product_Requirements_Document_Header_Image.png5121024Jama Software/media/jama-logo-primary.svgJama Software2019-07-02 04:00:392023-01-12 16:51:34Why You Need to Make More Time for FMEA
In some ways, developing a medical device, vehicle, or cell phone is similar to writing a hit song. Competition is high, relevancy is tied to continued innovation, and there’s constant pressure to focus on fast execution and speed to market.
With the upcoming release of the movie “Yesterday” — in which a struggling singer-songwriter wakes up to find himself in an alternate reality where no one has heard of The Beatles — we wanted to take a moment to recognize the similarities between collaborative engineering and songwriting.
And what better reference point for team collaboration than one of the most famous songwriting duos of all time: The Beatles’ John Lennon and Paul McCartney.
Emerging from Liverpool, England, in the early-1960s, McCartney (bass) and Lennon (guitar), alongside drummer Ringo Starr and guitarist George Harrison, formed The Beatles and changed the entire musical landscape for decades.
The Beatles’ primary songwriting team of McCartney and Lennon were also the epitome of collaborative engineering.
Collaborative engineering is about connecting cross-functional roles across an enterprise to creatively and easily work together for the purpose of faster innovation. It’s about breaking down barriers, adding agility, and organizing the right people for faster decisions.
And with a refined collaborative product design process, you can repeatedly capitalize on great ideas within your teams.
“I think someone building a car suddenly knows when the design is right or when the engine sounds good,” McCartney told Paste Magazine in 2015. “After a while, you get used to that, and you say, ‘Yeah, this is the way you go.’”
How Lennon and McCartney Used Collaborative Engineering
Much has been written about how The Beatles’ influence has stretched far beyond music and into a variety of other industries, including technology. Steve Jobs once famously described the Fab Four as nothing less than his model for business.
“They were four very talented guys who kept each other’s kind of negative tendencies in check,” Jobs told “60 Minutes.” “They balanced each other. And the total was greater than the sum of the parts. That’s how I see business: great things in business are never done by one person, they’re done by a team of people.”
As the core songwriting team within The Beatles, Lennon and McCartney propelled the group to sell 1.6 billion singles in the United States alone, with worldwide album sales hovering around 600 million to date.
If we observe these musical “engineers,” we witness the power and necessity of collaborative engineering to build a process that can yield better outcomes than any single person could manage individually.
Developing complex products with partners requires a common vision. Learn how better requirements management helps better facilitate the collaboration process by watching our webinar.
Lennon and McCartney would work for hours on a song in close proximity, which fostered the creative process and leveraged each other’s strengths. Some say that McCartney brought a left brain (creative, free flowing, muse oriented) influence to the team while Lennon provided the right brain (discipline, form, execution).
“People used to ask me and John [Lennon], ‘Who does what? Who writes the words? Who writes the music? How do you do this?,’” McCartney told Paste. “And we say, ‘There’s no one way.’ Sometimes it will be me. Sometimes it will be John.”
However they did it, the two Beatles combined to work through the requirements of various songs in a way that become much greater than if each was working on the tunes alone. And in doing this, they created a process that deviated from rigid, assigned roles to one where the focus was fueled by total team collaboration.
The result was producing quality work that has withstood the test of time (“Abbey Road” still hangs out in the top ten of vinyl purchases to this day) and that others simply can’t replicate.
Listening to Outside Voices
It’s worth noting, too, that even perhaps the greatest songwriting team of all time did not work in a silo. Given how successful they were, it would be easy to see McCartney and Lennon shutting out the other two Beatles — Harrison and Starr — from all songwriting functions. Countless lesser bands make that same mistake constantly.
That wasn’t nearly the case at all for The Beatles. Harrison, especially, was an excellent songwriter in his own right, but even when there was a Lennon and McCartney composition being worked out in real time, key decisions did emerge from outside the core songwriting team. Here we see cross-collaboration without limits (aka leveraging the enterprise).
For instance, it’s been said that near the end of the songwriting session for “Eleanor Rigby,” Harrison suggested the “Ah look at all the lonely people” line as a contribution. Thanks to this idea from a band member outside of the core songwriting team, “Eleanor Rigby” really came to life and, in fact, helped add not just the first line of the song but the overall theme that ended up defining it.
Yes, Lennon and McCartney get the bulk of the credit for The Beatles’ music (and rightly so), but there are plenty more examples throughout the band’s rich history that show more than a willingness to turn over songwriting control to others. Both Harrison and Starr penned classic songs for The Beatles and, other times, all four members are credited. It’s also worth noting that The Beatles’ legendary producer, George Martin, is sometimes referred to as the fifth Beatle given his many contributions to the band’s music.
Read how Jama Connect improved collaboration for a medical device developer, saving it $150,000 per project, in this customer story.
Leveraging Collaborative Engineering
The level of success Lennon and McCartney reached would not have been possible without both being open to others’ ideas and harnessing direct, team collaboration.
The collaborative engineering style The Beatles used to innovate around the requirements and design of their songs became one of the band’s greatest strengths. It also worked to enable the efficient, quality construction of tunes with an intended purpose/outcome.
In songwriting, construction can loosely be defined as the most efficient and appropriate application of song form and structure (e.g. the coding of the song). In today’s engineering world, construction means the software’s coding or the hardware’s design.
The brilliance of “Eleanor Rigby” is partly in its simple construction (just two chords: E minor and C major). Today, structured collaboration can simplify downstream software development and hardware design, which results in bigger gains in efficiency and maintainability.
Of course, in today’s engineering world, it’s not always as simple as getting great minds into a room for hours and hammering out incredible requirements. Teams have a lot of competing priorities and often are not even in the same location or even country.
One advantage engineering teams do have today that Lennon and McCartney didn’t is modern technology. There are many simple, intuitive, and flexible ways for all of the right people to creatively contribute to requirements definition, change, and reviews throughout collaborative product design.
“When you think about it, when you’re writing a song, you’re always trying to write something that you love and the people will love,” McCartney told Paste.
The same is true for products. The best way to build them is not in silos, but with direct input from team members across your organization… and the universe.
Learn how a modern approach to complex product development increases efficiency with the ability to foster collaboration and share knowledge by watching our Jama Connect demo.
https://www.jamasoftware.com/media/2017/02/Connected_Medical_Devices.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2019-06-25 04:00:042023-01-12 16:51:35What The Beatles Can Teach Us About Collaborative Engineering
Companies are facing intense pressures to bring complex products to market faster than ever. In addition, those delivering products in safety-critical markets must also create and execute against a risk management plan for expanding standards and regulatory oversight.
In these cases, inefficiencies and blind spots in the development process can lead to risk management errors which not only throw releases off schedule but can put lives in jeopardy.
To help raise awareness around these issues, prominent research and consulting firm Frost & Sullivan recently observed the product development landscape and its relationship to risk. The output is a recently-released brief, “Safeguarding Regulated Products Amidst Growing Complexity,” that spotlights Jama Connect™ as a remedy for ineffective risk analysis in product development.
Symptoms of Ineffective Risk Management
The Frost & Sullivan brief outlines the current competitive environment facing organizations producing products in regulated industries and makes the case that relying on outdated processes impedes success.
“Many businesses in these spaces have invested heavily over the years in their document-based systems to manage their product development process and are hesitant to upgrade to unknown technologies or solutions,” writes Frost & Sullivan. “These antiquated systems are often static and spreadsheet- or even paper-based. And while they may offer a (possibly false) sense of reassurance against the costs and risks associated with a live digital system, they end up creating more costs and causing more harm.”
As we’ve heard from many companies, performing requirements management and risk analysis through versioned spreadsheets and extensive meetings not only drains resources, slows development, and creates errors, but it’s just no longer an effective strategy when you need to build safe products quickly.
Gain a stronger handle on ISO 14971 — the FDA’s mandatory standard for risk assessment in medical devices — by grabbing our whitepaper.
Strengthening Collaboration During Development
One other notion dispelled by Frost & Sullivan is the idea that remote development teams can operate at maximum efficiency without a powerful, shared solution for centralized enablement.
For instance, with regulated companies, there’s too much at stake to leave issues around requirements, risk mitigation, and compliance up to emailed documents.
“A strong, platform-based solution can provide a virtual space in which different but interdependent teams can collaborate, key stakeholders can review and weigh in on decisions, and regulators can trace end-to-end compliance,” writes Frost & Sullivan. “It can also enable risk mitigation as an ongoing, semi-automated process that catches and integrates changing conditions. Such a solution can help ensure compliance across processes, functions and locations, as well as with product definitions and design, processes and test cases.”
Learn how how a Fortune 100 semiconductor company is meeting the challenges of developing automotive-related technology by downloading our case study.
A Better Risk Management Solution
For businesses still hesitant to invest in improvements to their risk management process, it’s not always strictly a question of budget. The move involves a change in mindset and executable process, according to Frost & Sullivan. For instance, tracking and managing risk needs to be an intrinsic, collaborative, ongoing part of the development process, and not something performed by a specialized team in a silo.
Some organizations, especially newcomers to regulated industries, may not even be sure where to start with complex standards like ISO 14971, let alone assembling a risk management plan. It’s in these cases you’re more likely to see a development team dig into a risk management framework in the later stages of development, potentially adding rework and cost when schedules and budgets may not allow for either.
Frost & Sullivan contends Jama Connect is worth a look for all organizations interested in mitigating product risk, as it can “provide risk management, collaboration, efficiency and regulatory compliance as aspects that strengthen, rather than complicate, each other.”
Whichever path a company chooses, what Frost & Sullivan make clear is that staying the course with an ineffective risk management process isn’t really an option at all.
“Teams will otherwise struggle to get their people up to speed, across the globe and across groups,” writes Frost & Sullivan. “A team-based approach… is the ideal solution in heavily regulated industries.”
Access the full Frost & Sullivan brief, “Safeguarding Regulated Products Amidst Growing Complexity” by downloading it now.
There are three main aspects of a project that tend to be in regular tension with one another: quality, schedule, cost. Typically, project management is about managing the tension that arises as focus and prioritization shift between these three elements.
Many times, organizations are forced to decide between pushing schedules, reducing costs, spending more on resources, and maintaining quality throughout the life of a product’s development. As a part of a product development lifecycle, requirements play a very important role in attempting to reduce or at least mitigate the tension between these areas.
Know What You’re Developing, and Why
Quality is, of course, a highly significant aspect of any product development effort. For many organizations, quality is paramount — especially in the case of highly-regulated industries like medical devices or automobiles, where quality concerns essentially amount to safety risks.
To ensure quality, you need to know what you are developing and why. And then, what are the requirements that meet those needs? In other words, a product should be defined to a meaningful degree before development begins. The distinction and order of “why” and “how” before “what” is a key element of requirements management.
This certainly does not mean that the product must be fully defined and agreed upon before any development happens. However, there should be enough definition to demonstrate that stakeholders agree on the needs and the high-level requirements meeting those needs, including acceptance criteria.
This is where a single source system becomes crucial, allowing cross-functional visibility to facilitate feedback and reviews to reduce the time and work between definition and development.
Requirements and Quality Assurance
Requirements are used to define the qualities of a system, features, or subsystem that meet actual user needs. A dedicated requirements management platform, like Jama Connect, helps ensure that development activities trace to actual needs and builds confidence that those needs are being addressed through gap analysis.
A gap in coverage happens when a need has been identified, but the engineering response to that need has not been provided. We often see this when higher level requirements don’t relate to anything, such as when an epic might be lacking stories.
Another aspect of improving quality is getting the right people involved at the right time. More eyes can sometimes be a hindrance to speed, but having people show up late to a discussion is usually worse. It’s important to make sure that not only the correct people are involved, but that the process for collaboration and reviews is clearly defined and well supported with a purpose-built solution, like Jama Connect.
Lastly, a discussion about quality would be incomplete without verification and validation (V&V). When writing requirements, it’s important to remember that the ability for a requirement to be verified is a key quality of a good requirement.
Typically, verification will happen against each requirement and is established by acceptance criteria determined while defining requirements. Validation, on the other hand, is concerned with whether or not you built the right product.
Through verification, you may determine that the product or feature works, but validation is focused on answering whether you actually met the need you set out to fulfill.
When considering the decisions and trade-offs made around quality, especially in relation to cost and schedule, having verification and validation activities closely tied into requirements definition can bring quality discussions closer to the front-end of an effort and avoid impacts of finding issues late in the lifecycle. Having a live and actionable trace matrix is essential in supporting this, especially where a product’s quality is non-negotiable.
Staying on Schedule Requires Visibility and Tracking
Schedules are mostly concerned with timelines and meeting time-based delivery of the product or its features.
In order to manage a project, the approach needs to be determined and then the infrastructure put in place to support that approach. From a product definition standpoint, the requirements may need to be organized in a way that makes sense for decomposition and capturing the granularity needed to properly define and align the product and teams. From there, development teams will collect those requirements into backlogs of work and manage the development of activities using a preferred methodology.
A quick way to build efficiency into this process, regardless of the methodologies implemented, is to manage at the level of discrete, individual items and move away from documents.
In terms of releasing pressure on the schedule, the idea is that instead of gating development and work based on large documents, manage the state of individual requirements, moving them independently through definition, acceptance and into development. Of course, logical groupings of requirements will necessitate some structure, but just identifying that appropriate organization will minimize the collection size and improve speed.
An obvious detriment to the schedule is people working on the wrong things. This can happen when teams do not have visibility into how what they are working on connects to the larger product definition.
To avoid this, consider the trace to a defined need as part of the approval and criteria for adding requirements into the backlog. Working on requirements lacking this trace runs the risk of working on the wrong thing. Of course, as you get into development cycles, new work may be discovered that helps facilitate and enable development, but this should be considered as potential scope creep.
Lastly, when it comes to schedule, it’s important that teams are tracking their work. You’ll likely be asking different questions at different phases of the effort. The important thing is that you clearly identify what you need to track to ensure progress and minimize issues that might fall through the cracks.
Once you know what you need to track, then you need to capture that data. In Jama Connect, as an example, you can track the state of requirements across the workflow, from draft through approval, which helps determine progress and find roadblocks. At a minimum, you’ll want to consider tracking the status of testing as well. That information is not the only key to the schedule but is also very important when assessing quality.
Avoid Rework by Defining, Agreeing, and then Developing
From a project management standpoint, the key metric related to cost is typically actuals again budget, where we’d take a baseline of the estimated cost and compare it to the actual cost to date. However, the cost is about more than money spent against the budget. It is also concerned with the cost of missed opportunities or lost market share.
One of the most expensive occurrences in product development is rework. Rework happens when teams get through some development activities only to find that they didn’t build the right thing or that the user needs are not actually fulfilled by what was developed.
To avoid or at least reduce rework, teams must define, agree, and then develop. The more teams can align around what it is you’re actually building and just how that thing will be verified, the better-aligned development activities will be. Additionally, as requirements are generated, verification should be defined at each level of abstraction.
Another way that teams can avoid cost and potentially positively impact their schedule is to reduce the time that teams are waiting to begin activities. This tends to happen when visibility across a development lifecycle is low and access to information is limited.
Using a single source system, like Jama Connect, and providing individual requirement status allows teams to start acting on information as it’s available and ready. As an example, if requirements are accessible and their status is visible, quality teams who handle V&V activities can begin their planning and verification activities much earlier than if they were waiting for documents to be released.
Change is another aspect of cost that’s often overlooked. Change is inevitable as we learn new information and get feedback throughout the product lifecycle. However, the cost of change can be mitigated by identifying and evaluating the impact of that change across the product. Change to a single requirement could impact definition and verification across multiple degrees of separation. Using trace, costs can be avoided by identifying and communicating these impacts early, even before applying the change.
Inform and Justify Decisions to Understand Impacts
In order to balance the three elements of project management discussed here, consider decisions that are being made and the tradeoffs determined during the lifecycle of your product development effort. In most cases, the decisions are working to balance quality, schedule, and cost.
The key to project management is being able to inform decision-making, justify these decisions, and understand the impacts. Properly managing your requirements can inform these decisions by being able to track requirements by their individual state, assess the trace for impacts and gaps, and ensure visibility and communication across teams.
Want to learn more about successfully managing every project? Check out our eBook “Project Management Best Practices” for 21 tips on taking the pain out of project management.
https://www.jamasoftware.com/media/2019/05/Balancing_Cost_Schedule_Quality-1.png5121024Zeb Geary/media/jama-logo-primary.svgZeb Geary2019-05-07 10:49:482023-01-12 16:51:39How to Balance Quality, Cost, and Schedule in Product Development
As in the majority of industries today, the complexity of avionics products is rapidly expanding. In contrast, budgets and development schedules are shrinking as teams work to ensure that product safety remains the first priority.
To help Jama’s avionics customers develop safe, quality products on expedited timelines, we’ve teamed up with the safety-critical experts at AFuzion. The result is our Avionics Services offering, which provides teams with an out-of-the-box configuration of Jama Connect specifically tailored for avionics development along with customized training and documentation templates.
Given the forward-thinking nature of our avionics customers, we knew we needed a trusted partner and thought leader to put together this comprehensive package. With offices in New York and Los Angeles, as well as more around the world, AFuzion offers safety-critical certification and consulting for innovators on the cutting edge of avionics, in addition to training and workshops.
Vance Hilderman, CEO and cofounder of AFuzion, calls his team “senior aviation and safety-critical engineers with an average of 20-plus years of engineering experience – plenty of gray hair and hopefully gray matter.”
Q: Can you talk briefly talk about AFuzion, the industries you serve, and the value you offer your customers?
A: Most of our work is aviation, but we also do automotive, satellites, ground systems, spacecraft, missiles, civil aircraft, and military aircraft. Our engineers have worked with 95 of the world’s 100 largest aviation companies. Though most of our work is engineering development, we also do certification, mentoring, and training. Interestingly, we’ve trained 22,000 engineers in aviation development standards, which is more than all 30 of our competitors combined. We also have a large library of safety-critical whitepapers, all developed by us.
Q: Why is requirements management a central concern for your customers?
A: AFuzion teaches that good requirements and good requirements management are key to avoiding erroneous assumptions and creating project success. Project success is created, planned, executed, and measured. You need great tools for that, and such is our reason for standardizing on Jama Connect.
Q: What AFuzion solutions or services are currently available with Jama, and what benefits do they deliver for our customers?
A: AFuzion’s safety-critical checklists and templates are hugely popular, especially for aviation. Companies get a working solution out of the box and can avoid rework and delays – it’s a huge jump-start to success, especially when used in conjunction with Jama Connect. And AFuzion can provide standards training while Jama provides the corresponding requirements management training. For the clients, it’s a win-win-win.
Q: What’s the best way to leverage Jama to comply with DO-178, DO-254, and ISO 26262 or IEC-61508?
A: First, get training in requirements management from Jama and the relevant standard from AFuzion. Then initiate Jama deployment and AFuzion’s processes and templates. Consider a gap analysis from AFuzion to show how to best minimize rework and optimize successful project certification and compliance.
Q: What are some of the biggest mistakes or misconceptions you see avionics professionals make when they’re first starting to develop safety-critical products?
A: One: Proceeding without a written plan and alternatives. Two: Outsourcing. Engineering is incredibly complex already and it helps when you are all in the same room, same time zone, and speaking the same language. Outsourcing without a CMMI level 4 compliance playbook increases risk. Now, we don’t mind when companies try that: Over half of our clients come to us after they fail at that. But we’d rather see them reduce costs by succeeding first and avoiding failure.
Q: Are aerospace companies doing their best to keep their products secure? What are the cybersecurity threats facing the aerospace industry?
A: Great question. In fact, the FAA and EASA just escalated cybersecurity to the highest level and mandated that all aviation companies deploy proven solutions based upon DO-326A (ED-202A in Europe) before year-end 2019. AFuzion’s aviation cybersecurity whitepaper is very popular and available for free download at our website.
Companies need training, frameworks, and cybersecurity tools throughout development and product deployment/operations, and AFuzion handles all of this. Our new aviation cybersecurity DO-326A / ED-202A training is proving hugely popular: We just had a sold-out class in Munich during Aerospace Tech Week. Threats are rapidly increasing worldwide, so the solutions need to keep up. AFuzion will help ensure that happens.
Q: What are some success stories you’ve heard from people using AFuzion’s services?
A: In just the past three months, we’ve helped companies certify 20-plus aviation products; taught 1,500 engineers how to succeed with DO-178C, DO-254, and ARP4754A; co-developed 10 aviation airborne- and ground-based systems; and have maintained a 100% client repeat rate, where clients call us back for additional work or say they intend to. That’s honestly the greatest reward. Many people think aerospace is staid and boring. Actually, it’s quite the opposite. Aerospace is real technology, real money, real results.
View our datasheet to learn more aboutJama Software’s Avionics Services package. And, to see more information specific to the aerospace and defense industries, we’ve compiled a handy list of valuable resources for you!
https://www.jamasoftware.com/media/2019/04/Why_teams_new_RM_Solution-1.png5121024Jama Software/media/jama-logo-primary.svgJama Software2019-04-25 09:36:252023-01-12 16:51:40Build and Manage Safety-Critical Avionics Systems with Jama Connect and AFuzion
At a conference I attended recently, I listened to teamsdiscuss the challenges they faced in deploying software in their organizations. The consensus was thatthe software is easy; the people are hard.That is to say, getting up to speed with a newsoftware solution itself is relatively easy compared to getting people to change their behaviorand successfully adopt new software.
ROIRequires that TeamsActually Use the Solution
One of the speakers said something that really stuck with me. This personsaid, “There is no return on investment without adoption, and there is no adoption without user acceptance.” And while that may seem obvious, many times the end user of the software is forgotten. Other priorities — like budget, schedule, and various agendas —put a lot of pressure on the deployment plan. The human aspect, as important as it is, gets lost.
Gaining Acceptance Later in the Implementation Will Cost You
When implementing a new solution, it’s imperativethat you get your team on board from the get-go – and not just for the purpose of keeping them happy. Just as it’s more costly to identify inaccurate requirements late in the product delivery lifecycle, the same principle holds true for user acceptance. Resistance from users identified late is always going to be more costly than adoption issuesidentified and addressed early.
While implementing a new solution may be a top–down decision, it’s important to remember that the users are the ones who will need to adapt to the change. The primary impacted stakeholders (i.e. the end–users) will be more receptive to a major change if they are participating in the process, rather than being told that they must adopt a new tool.
Change is difficult, and without a full understanding of the benefits ofa new solution, teams may feel frustrated or resistant. One way to preemptively combat resistance is by identifying long- and short-term goals for each team member and encouraging users to be involved in the implementation process.
Having worked in professional services for over a decade, I have come to see just how valuable it is to understand the people side of deployments. In my years as a business analyst, I’ve seen from the inside just how difficult it can be to get people on board with new solutions, particularly those that also come with process changes, and how to make those changes stick.
My interest in this topic goes even deeper. A few years ago, I completed a master’s program in psychologywhere I studied human behavior and why people do or do not change. I’ve found that what I learned during my study of psychology has translated quite well to the consulting world.
In this post I won’t be able to outline the perfect adoption plan for your organization; this would be futile as no two companies have the same needs or challenges. But I will discuss the approach we recommend when planning for a solution rollout that maximizes adoption.
If You’re Taking a Trip, Bring the Whole Team Along
I’m going to start with an analogy:
Let’s say you’ve pretty much determined that everyone on your team could benefit from a vacation. You’ve even heard people say so. You’ve had some good conversations about what people want and need, and with that knowledge you pick out a destination that’s going to recharge everyone.
Next, you have to figure out what kind of transportation you’re going to use to get everyone to the identified location. You’ve gone online and talked to some others about what kind of vehicle works best for teams like yours.
So, with the information you have, you go ahead and buy the perfect car for this trip. It has all the things you need.
In case you haven’t figured out how the pieces of my analogy fit into the rollout of a new solution, here it is:
The people are those who would benefit from a new process and solution to meet their business objectives
The “destination” is that ultimate goal, where the benefits are realized
The “car” is the newsoftware solution that gets you to that ultimate goal
But here’s something you have to consider before you embark on this journey: You have to figure out where everyone lives, what kind of baggage they’re bringing with them, and how you’re going to organize picking them all up so you can all be in the car at the same time, happily enjoying the journey to your destination. More on that in a bit.
Key Factors in Planning a Successful Software Deployment
If you’ve ever actually planned an out-of-town experience with coworkers (or family, for that matter), you know it’s impossible to make everyone happy all the time. Introducinga new way of working to your teams can be even more difficult. Why?
Before I answer that, remember that these are the main things to keep top-of-mind when planning a successful deployment:
Bringing new teams into a new solution, with new processes, is not simply a functional or technical issue;it is a people-centric change.
Benefits that require that people adopt the solution inherently require that those people change behavior.
The longer adoption problems go unaddressed the more difficultand expensivethey are to address.
New data for 2019 revealsthe growing gap between product complexity and requirements management. Find out more by downloading our report.
Design Your Approach Based on the Specific Needs of Your Team
Change is hard – especially when people are involved. You can put up your pie chart or line graph with anticipated benefits and have everyone nodding their heads in agreement, and you can find the perfect “car” to get you there.But you cannot assume that pointing at that amazing vacation spot on a map or showing off your awesome new vehiclewill translate to motivation and acceptance for the people whomust be on board in the end.
Of course, some will be on board immediately, so make sure you identify those people and train them to evangelize for the effort. Theseadvocates are a great asset as you complete your rollout to the rest of the organization. Successful organizations often pair these early adopters with new users to help them get up to speed with the new process.
Others may need more attention, and youmust pay careful attention to their fears and objections and speak to them early and often.
Consider the Delta Between Where Your Team is Today and Where You Want to Be
You must considerthe maturity of your organization and teams. Of course, it doesn’t have anything to do with the emotional maturity of the individuals (though that could come into play), but the maturity of theirprocesses and toolset and how they’re accustomed to getting their work done today. In my experience as a consultant, I find that team maturity ranges widely, especially when it comes to requirements management processes and supportingtools.
Knowing where teamsare — or theirlevel of maturity — is important for a number of reasons, not least of which is anticipating resistance. Think about the person who is currently using a Word doc that they keep somewhere on their laptop to manage the requirements for a really complex product. This might be considered a pretty basic level of maturity.
Now, before bringing this person into a new solution, it is important to think about the degree of change being asked of this person. What does a single-source collaborative system feel like to a person coming from Word files on their computer? What resistance can you anticipate and what will be your approach? Again, communication early and often is going to be key to getting this person on board with a new solution.
When change is introduced, the initial reaction from most is to resist. This isn’t necessarily a bad thing, as not all change is good. But if you don’t address resistance, it can lead to rigidity, causing teams to dig their heels in and get stuck.
When you are bringing on a new team into your deployment effort, don’t just set up training on how to usethe tool. You’ll want to engage with your peopleat a personal level so you can uncovertheir anxieties and address them. You’ll need to anticipate their questions and welcome their concerns. When you know their concerns, you can address them; it’s the concerns you don’t know about that can manifest very late and cause problems for the whole deployment.
For example: Consider a person who has yet to log into the software even a month after deployment. What did we not know about this person that let them slip through the cracks? A quick way to find out is to simply ask them.
Remember that unanswered questions today turn into resistance tomorrow. Provide opportunities for people to voice their questions early so you can address them. Consider establishing clear channels for communication with users.
Adopt a Change Management Model to Give Your Project Structure
There are many change management models out there, and I recommend researching these until you find one that make sense for the size of your company, itsculture, and your strategic goals. I personally like the ADKAR model from Prosci.
The five parts of this specific change management model fit well with how we’ve been discussing bringing on teams to improve adoption:
Awareness of the need for change.
Desire to participate and support the change.
Knowledge on how to change.
Ability to implement required skills and behaviors.
A good change management model, like ADKAR, will help you consider the approach you want to take as you get started on your deployment plan. You’ll want to think about:
How you will build awareness, not just of new processes and solutions, but also why you’re taking on this initiative and what you hope it will do for your organization.
How you will communicate the benefits of using the solution, particularly the “what’s in it for me” for each individual or each team.
How you will build knowledge about how the solution works, relative to the current tool, and how to get the most of it.
How will you ensure people gain the ability to use the solution with the proper training for their position, in a style that will help them feel empowered and not burdened through the learning curve.
What kind of reinforcements you can use to ensure that the process change sticks and the initiative’s objectives are met.
These are just a few examples of how to use the ADKAR modelbut the key is to engage with this line of thinking early and be open to adjusting as you learn more.
https://www.jamasoftware.com/media/2015/10/Elucent.png5121024Zeb Geary/media/jama-logo-primary.svgZeb Geary2019-04-11 10:00:132023-01-12 16:51:42Why Your Rollout Strategy Must Put People First
In 1967, computer scientist and programmer Melvin Conway coined the adage that carries his name: “Organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations.”
In other words, a system will tend to reflect the structure of the organization that designed it. Conway’s law is based on the logic that effective, functional software requires frequent communication between stakeholders. Further, Conway’s law assumes that the structure of a system will reflect the social boundaries and conditions of the organization that created it.
One example of Conway’s law in action, identified back in 1999 by UX expert Nigel Bevan, is corporate website design: Companies tend to create websites with structure and content that mirror the company’s internal concerns — rather than speaking to the needs of the user.
The widely accepted solution to Conway’s law is to create smaller teams focused around single projects so they can iterate rapidly, delivering creative solutions and responding adroitly to changing customer needs. Like anything else, though, this approach has its drawbacks, and being aware of those downsides in advance can help you mitigate their impact.
Here, we’ll unpack the benefits of leveraging smaller teams; assess whether Conway’s law holds up to scrutiny by researchers; and lay out how to balance the efficiency of small, independent teams against organizational cohesion and identity to build better products.
Smaller Teams Can Yield Better Results
Plenty of leading tech companies, including Amazon and Netflix, are structured as multiple (relatively) small teams, each responsible for a small part of the overall organizational ecosystem. These teams own the whole lifecycle of their product, system, or service, giving them much more autonomy than bigger teams with rigid codebases. Multiple smaller teams allow your organization to experiment with best practices and respond to change faster and more efficiently, while ossified, inflexible systems are slow to adapt to meet evolving business needs.
When your organization structure and your software aren’t in alignment, tensions and miscommunication are rife. If this is your situation, look for ways to break up monolithic systems by business function to allow for more fine-grained communication between stakeholders throughout the development lifecycle.
Testing Conway’s Law
In 1967, the Harvard Business Review rejected Conway’s original paper, saying he hadn’t proved his thesis. Nevertheless, software developers eventually came to accept Conway’s law because it was true to their experiences, and by 2008, a team of researchers at MIT and Harvard Business School had begun analyzing different codebases to see if they could prove the hypothesis.
For this study, researchers took multiple examples of software created to serve the same purpose (for example, word processing or financial management). Codebases created by open-source teams were compared with those crafted by more tightly coupled teams. The study found “strong evidence” to support Conway’s law, concluding that “distributed teams tend to develop more modular products.”
In other words, there’s definitely some justification for the idea that smaller teams will work more effectively and produce better results, while bigger groups may lack cohesion and exhibit dysfunction.
Organization First, Team Second
As a recent Forbes article noted, there are potential drawbacks to letting Conway’s law guide the structure of your organization. The thinking goes that “once you entrench small teams in this way, their respect and loyalty for that team often comes to outweigh their allegiance to the organization as a whole… Teams in disparate locations end up forming strong but exclusive identities as individual departments.”
So how do you balance the benefits of small, nimble groups against an organization-wide sense of solidarity, cooperation, and transparency?
Platforms that enable organization-wide collaboration can break down the barriers erected by Conway’s law without robbing small teams of their independence and agility. Josh McKenty, a vice president at Pivotal, argues that using collaborative platforms can neutralize the sense of otherness, of separateness, that can inhibit organization-wide cohesion: “Platforms can allow businesses to cultivate a sense of ‘we’re all in this together,’ in which everyone is respected, treated with mutual regard, and can clean up each other’s messes – regardless of whether they created the mess in the first place,” McKenty told a conference audience in 2017, according to Forbes.
That solidarity is crucial in complex product and systems development, where rapidly shifting requirements, evolving standards, and updated customer specs require consistent and dedicated communication within and across teams. If your teams are forming strong bonds, that’s terrific, but you don’t want those bonds to become exclusionary. If teams are turning into cliques, your organization has lost its internal cohesion.
A collaborative platform that unites disparate teams across functions and locations can help you actualize the benefits of small, focused teams without losing coherence.
https://www.jamasoftware.com/media/2019/04/Conways-law.png5121024Eira Long May/media/jama-logo-primary.svgEira Long May2019-04-04 04:00:432023-01-12 16:51:43What Can Development Teams Learn from Conway’s Law?
Close gaps in product development with Jama Connect™ and LDRA
Interested in closing gaps in your product development lifecycle? It’s no secret that developers of mission-critical software are facing increasingly complex system requirements and stringent standards for safety and efficacy. That’s why Jama Software has partnered with LDRA to deliver a test validation and verification solution for safety- and security-critical embedded software. LDRA has been a market leader in verification and software quality tools for over 40 years. They serve customers across the aerospace and defense, industrial energy, automotive, rail, and medical device industries.
Integrating TÜV SÜD-certified Jama Connect with the LDRA tool suite gives teams bidirectional traceability across the development lifecycle. This transparency helps development teams build higher-quality products and get to market faster while mitigating risk. Whether teams are working from a standards-based V model or applying an Agile, Spiral, or Waterfall methodology, employing Jama Connect in concert with the TÜV SÜD- and TÜV SAAR-certified LDRA tool suite closes the verification gaps in the development lifecycle, helping to ensure the delivery of safe and secure software.
Let’s dive into some details to understand the value of using Jama Connect and the LDRA tool suite.
Requirements and test cases form the bond between Jama Connect™ and LDRA
Product managers and engineers use Jama Connect to manage requirements and testing from idea through development, integration, and launch. Managing requirements in the Jama Connect platform allows users to align teams, track decisions, and move forward with confidence that they are building the product or system they set out to build.
LDRA imports Jama requirements and test cases, mirroring the structure and levels of traceability established from the decomposition of stakeholder requirements down to software requirements and test cases. With the Jama artifacts in the LDRA tool suite, traceability down to the code can be realized and verification and validation of requirements can begin.
During the Jama test case import, the user can choose the type of test case it corresponds to (e.g. unit test, system test, code review test) and let LDRA create a test artifact that will invoke the proper part of the LDRA tool suite and realize that test case type.
Part of realizing Jama test cases in the LDRA tool suite includes the ability to follow the steps defined in the Jama test case description (e.g. inputs, outputs, expected results). Test cases executed by the LDRA tool suite can be executed either on a host machine, in a virtual environment, or on the actual target hardware. Verification results are captured, and Pass/Fail status results are produced. The verification results can then be exported from the LDRA tool suite into the Jama test case verification status field.
By way of the Jama Test Run feature, the change in verification status and included user notes can be logged and committed. Additionally, if the user desires, the LDRA tool suite verification results can also be exported into the Jama requirement verification status field, giving the Jama user additional touch points to analyze.
Another benefit of the integration is Jama’s ability to create, link, assign, track, and manage defects discovered during testing with the LDRA tool suite.
Partnering with standards and safety experts on product development
Many industries and their applications have safety-critical requirements drawn from process standards like ISO 14971 and ISO 26262. These requirements demand a higher level of visibility and traceability that can be achieved with the Jama-LDRA integration.
LDRA is heavily involved in the international standards body. They help lead the DO-178 standard in the aerospace market for safety in avionics. LDRA is also a significant contributor to the MISRA software coding standard and other standards like CERT. Their tool suite is ISO 9001:2008-certified as a quality management system and TÜV SÜD- and TÜV SAAR-certified.
The Jama-LDRA partnership benefits not only LDRA customers in the military and aerospace needing to comply with standards like DO-178B/C, but also one of the fastest-growing industries, and the one that keeps LDRA the busiest: the automotive industry and their need to comply with ISO 26262. The Jama-LDRA partnership also addresses applications for safety and security in the medical device industry (IEC 62304), rail (EN 50128), and industrial controls and energy (IEC 61508).
LDRA helps users achieve certification in standards like DO-178B/C, DO-331, ISO 26262, Future Airborne Capability Environment (FACE), IEC 61508, and others. The LDRA tool suite lays out a set of objectives for the relevant process standard, along with corresponding artifact placeholders and sample template documents. This guiding project structure with built-in progress metrics gives the user an intuitive understanding of what is required to achieve certification and the day-to-day gains toward that goal.
A major key benefit to customers is LDRA’s ability to perform on target hardware testing or Run-For-Score (RFS). These customers have a very strict process for achieving certification wherein step-by-step testing is followed and results are logged and eye-witnessed.
LDRA also has its own proprietary code analysis engine. Starting with static code analysis, a debugging method that examines the source code before the program is run, LDRA generally finds potential coding flaws and security vulnerabilities prior to code compilation. Once the code has been compiled, testing can be further complemented by LDRA’s dynamic testing, structural coverage, and unit testing.
Build with certainty
The complementary capabilities and automation offered by Jama and LDRA deliver a powerful solution for the development and test verification of software systems in the product development lifecycle. Whatever software development approach your team chooses to employ, requirements- combined with Jama’s product lifecycle management capacities can help you deliver safe, compliant products on time and on budget.
https://www.jamasoftware.com/media/2019/03/LDRA.png5121024Jama Software/media/jama-logo-primary.svgJama Software2019-03-28 09:45:032023-01-12 16:51:44Close the Gaps in Your Product Development Cycle with Jama Connect™ and LDRA
