Last posting for the MKS BlogSpot:

MKS now a PTC Company

We’d like to Thank ALL of our loyal visitors for coming to the MKS Corporate Blog! We are excited to announce that MKS is now part of PTC and we will continue to provide our Integrity solution through the Integrity Business Unit at PTC.

Please continue to follow us at our new Blog as our industry experts will continue to post interesting articles on software engineering topics ranging from Requirements Management, Lifecycle Traceability, Risk Management to Functional Safety in the following industries: Automotive, Aerospace & Defense, Medical Devices, High Tech Electronics, Government, Financial Services, Life Sciences, and Telecommunications. We look forward to seeing you at our new new home at PTC.com.

About PTC Integrity Business Unit
PTC’s Integrity Business Unit, enables organizations to reduce the overwhelming complexity of developing software intensive products thereby removing barriers to rapid innovation.

Integrity a PTC Product, is the leading Software System Lifecycle Management (SSLM) solution that manages all software system development processes and connects all software engineering artifacts, including requirements, models, code and test, ensuring comprehensive lifecycle traceability.

Integrity's open architecture integrates disparate tools into a streamlined software system engineering process, allowing orchestration of software change and collaboration across the technology supply chain. With Integrity, development teams improve productivity and quality, streamline compliance and gain complete product visibility, which ultimately drives more innovative products into the market.

For any other information on Integrity, a PTC Product please visit our website at www.ptc.com/products/integrity.

SSLM for All the Right Reasons - Music to My Ears

Last week I had the pleasure of meeting with a customer who builds advanced industrial control systems. Like many others in the high tech electronics space, this customer has seen software become an increasingly important part of their overall product development. The topic of this particular meeting was the benefits of unified System & Software Lifecycle Management. Attendees included representatives from various product management groups, systems engineering, software development, as well as V & V. 

It's been my observation that the high tech electronics space is different from other systems engineering industry verticals in that their need for software and systems engineering improvements is driven more by market forces than by regulatory forces. It was nice to have this validated by our customer when, while discussing the benefits of comprehensive lifecycle traceability, one of the Systems Engineering team leaders said the following: 

"It might be difficult to quantify, but the traceability we've seen is outstanding. If you're making products for the FDA it can make or break your business, but that's not the case here. For us, traceability is all about making sure we don't miss stuff and end up doing rework. It's all about avoiding rework - we don't have agency requirements or those kinds of things that dictate traceability. We're trying to get repeatable and predictable in our product development process and this is a great enabler for that." 

He went on to talk about some of the implications of rework avoidance; improved  productivity, predictability, and time to market. He's right, of course. Traceability in a unified SSLM environment is great for compliance and it's great for Product Management and readiness assessment. It's great for reuse and product family management. And it's great for product maintenance, for instance, when a component has a bug in it and we need to find the source of that bug and what other components may also be affected. With all this greatness going around, let's not forget that traceability is absolutely foundational for effective product line engineering. 

There are good and practical reasons for regulation, standardization, and compliance in medical devices, aerospace, automotive, and other safety-critical industries. But it is wonderful to work with a product engineering company in a low-regulatory environment that is adopting modern software and systems engineering practices not because a government or international standards body or industry group tells them to, but because it will help them be more productive, better serve their customers, and get higher quality products to market sooner. 

About the title - I sat next to Greg Liszt on a flight from Denver to Boston earlier this week. Greg introduced himself as a banjo player with the bluegrass bands Crooked Still and The Deadly Gentlemen. It turns out Greg was a bit modest in describing his accomplishments. He has succeeded in making a living a life as a professional musician, and that in itself is no easy task. TDG's latest CD is called "Carry Me To Home". Music to my ears... and yours, should you decide to give a listen.

Agile Manifestations

Agility is Not Enough: Beyond the Manifesto, written by Forbes columnist Steve Denning, challenges those “still living within the confines of the Agile Manifesto” to consider Agile in the context of today’s business world. Customer delight is the new bottom line for business, according to Denning, and Agile methods must evolve if they are to embrace this new reality.

What’s fascinating about this article is not the so much content, but the conversation that ensues. In the comments section, reader Kevin Ross puts up both a spirited defense of the manifesto and a thoughtful, reasoned challenge to Denning assertions. Denning, to his credit, takes Ross’ respectful criticism and responds in a second post, Agile Part 2: Can the Manifesto be Defended as well as a third, where The Conversation Continues.

Despite arguments regarding the need to update a decade-old declaration of policy and principles, Agile methods are constantly being tailored to meet new demands. For example, in A Practical Way to do Agile in an Enterprise ALM Environment, (CM Journal, Volume 9 - No. 7 - July, 2011), PTC’s Harsh Sabikhi describes approaches his clients have taken to tailor Agile methods in the face of regulatory compliance and quality assurance mandates.

As software becomes a more critical component in product development, Agile methods are naturally gaining traction in this space. While the trend has been evident for years, we have reached an inflection point where rapid innovation and product differentiation relies increasingly on the software, rather than the electrical or mechanical, aspects of a product. In the product development environment, software alone is not considered the final deliverable, rather it is an integral aspect of the final deliverable. Is “working software” a sufficient iteration objective or must we incorporate physical and electro-mechanical system aspects in order to provide value? If so, how do we reconcile the different paces of change in the software and hardware aspects of the system?

This is not to say that the physical and electro-mechanical aspects of a product don’t provide opportunities for innovation and differentiation. They can and they certainly do. However, these aspects of the system are relatively well understood and suited for predictive design and manufacturing processes. The software aspect, as we have observed, is extremely malleable, relatively poorly understood, and better suited for empirical and adaptive development processes.

Product development, especially in the context of variant management and product lines, presents an entirely new set of challenges and opportunities as Agile methods manifest themselves in traditionally predictive environments. The Agile Manifesto may be a guiding light, but it is not meant to be a prescriptive solution. Tailored solutions will emerge as organizations on the forefront of product development apply Agile principles and best practices to a proven and pragmatic product development framework.

---

Have You Downloaded the Latest Software Patch for Your BMW 3?

The role of software is changing and nowhere is that more evident than in the world of product manufacturers. Software brings huge benefits, but at the same time significant challenges. In a recent article by Michael Azoff of Ovum in the Technology Spectator, he asserts that, “Warranty Direct shows that electrical faults in cars, including software defects, are on the rise, representing 27 per cent of all faults (averaged across all models)." The reality is that software is on an aggressive growth path, or as Azoff terms this, an "exponential rise" within automobiles and many other manufactured products. Unfortunately, complexity is tending to mirror this trajectory as well, according to many of our customers across automotive, electronics and high tech, medical devices, and aerospace and defense.

So how can product organizations solve this? Azoff goes on to say that "Car manufacturers need to understand better how to create reliable embedded software by defining a role for software lifecycle management in the product world." This is not only true in the world of automotive, but these other verticals as well. Research from other sources including Gartner, in a recent paper entitled Application Life Cycle Management Matters Where Diversity Persists, clearly show that software/application lifecycle management provides significant value to enterprises including:

Agility — Through collaboration and application of "just enough" process

Predictability — Through better estimation, better communication and more repeatable processes

Auditability — Traceability of work back to business needs, accountability for each change or decision made, and the ability to separate concerns

Quality — Through more-effective management of requirements, design and quality processes

Productivity — Through the reduction of rework and continuous improvement of processes and practices, and more-effective use of resources

There are many other implications and advantages that software can provide manufacturers including:

- A huge reduction in the cost of mass manufacturing

- Flexibility to affect change in a product very late in the development cycle

- The ability to create many more industry and customer specific product variants

- Delivery of new features in their products after they have been purchased (e.g. iPhone)

- The ability for customers to receive fixes and patches during the service lifecycle much more rapidly, without having to bring their device to a service center and at a fraction of the cost of traditional service

This last point is critical and a huge opportunity for all manufacturers as Azoff notes, “the typical enterprise IT user is used to downloading software patches regularly, but this is not the practice for car owners (at least not yet).” So why have we not seen more device manufacturers adopt this strategy? Well of course, the device whether it be a phone or automobile, must be architected for this dynamic software upgrade and service model. But another significant impediment is the ability to manage software engineering more like a first class engineering process and less like a growing, critical, differentiating, and valuable afterthought.

Check out these related resources:

ISO 26262 - Effectively Managing the Safety Development Cycle with a Software System Lifecycle Management Platform

EETimes Panel Discussion: Designing Intelligence into the Car

One Size Does Not Fit All in Risk Management

Written by Ryan Lloyd, Customer Requirements Manager, MKS a PTC Company

Risk Management is a critical process in developing safe and effective medical devices as well as a requirement for regulatory approval. However, there is no single best method for managing risk that can be applied in all circumstances. Organizations often need to adapt accepted and new processes to meet their needs and to fully leverage the benefits of Risk Management.

For example, there are multiple approaches to Risk Management, and each approach has its benefits and drawbacks. Traditional approaches, such as FMEA, are often described as 'bottom-up,' and they require examining every design element and ensuring each possible failure is appropriately mitigated. In contrast to this, standards such as ISO 14971, IEC 62304 and regulatory bodies such as the FDA and the EU, emphasize a 'top-down' approach, such as Hazard Analysis, to ensure that safety and effectiveness are considered from the perspective of the device's intended use rather than just how it functions.

Both approaches contribute to the overall safety, effectiveness and quality of a device, and while the industry is moving towards top-down risk management, this doesn't mean that bottom-up approaches such as FMEA shouldn't still be applied. Most organizations use a customized combination of both approaches.

Another difference can be found in how organizations classify risks and hazards. Risk Priority Number (RPN) is a commonly used technique often associated with FMEA, that calculates the priority of a risk based on several characteristics, typically Severity and Occurrence. This is a simple and quantitative means of assessing risks and hazards, but it does have some limitations. For example, in the following chart



several different combinations result in the same value. Does that mean that a critically severe hazard with a remote possibility should be prioritized the same as a hazard that is probable but with minor repercussions? Because RPN is numerical it is useful in statistical analyses, but sometimes too vague and inflexible for dealing with the complexities of modern medical device development.

Another commonly used technique for prioritizing and categorizing hazards is the use of a Risk Index. The organization, or sometimes the specific project, defines what can be classified as Unacceptable, As Low as Reasonably Possible (ALARP), and Acceptable level of risk, not by RPN but by explicitly assigning a risk level to each combination of severity and occurrence.

Therefore, while Risk Management is mandated and an essential part of design and development, organizations need flexibility to tailor it to fit their needs. Risk Management solutions must enable medical device manufacturers to apply Risk Management techniques that fit the organization and the situation, rather than try to shoe-horn development into a pre-defined process. For example, the system should allow the organization to define the computations used for RPN and Risk Indexes for each project. Workflow and artifacts for top-down Risk Management during initial requirements and design, and bottom-up during development, must also be supported. This will also ensure that Risk Management is not conducted as a separate and isolated activity, meaning that Risk Management is not only tailored to the organization and project needs, but is also closely integrated with all of development, reducing effort for Risk Management and demonstrating compliance.

PTC is committed to helping medical device manufacturers succeed.

Feel free to comment on this post or visit our other blog post on Risk Management by Dennis Elenburg, Customer Solutions Engineer at MKS a PTC Company.

Test Faster or More Effectively?

It is possible with the right Requirements Management Tool!
Written by Dennis Elenburg, Customer Solutions Engineer, MKS a PTC Company

A problem that plagues all software development organizations is never having the time to test everything you want to test. Shipping a quality product or bug free application means making hard choices when allocating limited testing resources. Testing faster and more efficiently is always a good idea, but are you testing the right things? Can your testing organization easily access the product requirements and create defects from failed tests, both automated and manual? Do your testers write bug reports that help your developers quickly fix the problem?

You Get What You Measure
Quantity of tests executed doesn't necessarily correlate to product quality. This is especially true when automation is involved. If the metric used to assess quality is "number of tests performed," a tester who automates 1,000 test cases may be rewarded and respected more than the lowly manual tester who is only completing 10 tests in the same period of time. However, if those 1,000 tests pass without uncovering any bugs this may be a false quality indicator. If the manual tester discovers two bugs and an unmet requirement in his 10 manual tests, who contributed more to the quality process?

Test automation is utterly incapable of interpreting the meaning of test failures. Automation speeds up the execution process and comparison of results, but a knowledgeable tester must still determine if a failure was due to the test script or if a defect truly exists. Then, a well written bug report will not only note the failure but indicate how the system behavior doesn’t conform to the requirements. This improves developer productivity in fixing the defect. Efficient knowledge work connects testing, requirements, defects, and even the code.

High value software testing and defect analysis is performed by testers who understand product requirements, have the skills to map tests to requirements, and who can write bug reports that help developers fix defects quickly. This is collaborative knowledge work. You can boost the effectiveness of your knowledge workers by providing them with tools to help them connect the dots. More automation may speed things up, but to really enhance product quality, total visibility and end-to-end connectivity across the software development lifecycle is imperative.

Highly Effective Testing is Collaborative
As a former QA manager who struggled under dictates from senior management to "automate, automate, automate," I can empathize with the desire to run more tests. Test automation vendors make lots of promises, and automation can be great, but it is easy to lose sight of the importance of connectivity when focused on a major automation initiative. How do you translate your test results back into useful knowledge for improving product quality?

A quality metric of "number of tests passed" is not enough, particularly if you're automating hundreds or even thousands of tests. You need metrics on all aspects of your software development process and how they relate to each other: test coverage against requirements, defects per test session, and even defects in requirements are just a few examples. A whole host of metrics are possible when you have total visibility and connectivity across your entire software development process.

If everyone can see the complete lifecycle of the requirements from inception to final delivery, including any defects along the way, then quality becomes a shared responsibility across the enterprise. Silos come down and collaboration improves. Quality depends on everyone doing their part, and that starts with equipping your knowledge workers with access to the information they need to do their jobs. Do you have total visibility into your entire software development organization? If not, let us show you how…

Please feel free to leave comments or answer any of the questions asked throughout this blog. For a demonstration of how your entire software organization can benefit from total visibility, tracing requirements through development and into testing see any of the following resources:

• Forrester Research Report: Selecting the Right Requirements Management Tool


• Requirements Management Datasheet


• Listen to a recent Webcast from June 29 on Automating Risk Management within the Engineering Lifecycle for Medical Devices

Isolated risk management is not effective risk management

Risk Management is an essential requirement for compliance to the European Union and FDA Medical Device regulations. Standards-developing agencies have also focused on the importance of applying Risk Management to medical devices in view of ensuring patient safety, most notably in the ISO 14971 standard.

However, Risk Management is not just a compliance requirement. It is the identification of hazards and hazardous conditions, estimation and evaluation of the associated risks, establishment of controls for those risks and continuous monitoring of the effectiveness of the controls throughout the product lifecycle. When initiated early and employed frequently as an integrated part of development, risk management provides opportunities for product innovation, as well as reducing costs of defects and rework.

The FDA recognizes that Risk Management must be an integrated part of the overall development process.

"Although each participant has a role in managing risks, no participant can be successful alone. Optimal safety can be accomplished only by an integrated system in which the roles and responsibilities, as well as capabilities and limitations, of each participant are known to all." (http://www.fda.gov/Safety/SafetyofSpecificProducts/ucm180580.htm)

Each participant in product development, whether an engineer, medical specialist, compliance specialist, or verification and validation expert, needs to be integrated into Risk Management. They need to collaborate in order to be effective.

Unfortunately, most organizations practice Risk Management as an isolated process, separate from the design, development and verification. The use of standalone Risk Management tools or office software to record and manage the Risk Management process encourages this. This reduces the efficacy of Risk Management and complicates the demonstration of compliance.

To leverage Risk Management's potential for innovation and cost reduction and reduce the effort required for audits, Medical Device Engineering companies need dynamic traceability between Risk Management and the other development disciplines. Risks must not only be readily traceable to the identified hazards. Developers and engineers must also be able to easily trace their development artifacts such as system, hardware and software requirements, design, and verification and validation plans to the risk control measures.

When Risk Management is integrated into the development process, design and requirement change impacts can be quickly evaluated without having to sort through pages of spreadsheets and documents. Development has real time visibility into risk coverage and can ensure that hazards and risks are appropriately controlled and that the controls have verification and validation plans in place.

We recently witnessed just how effective this approach can be with a customer using MKS Integrity for Medical Device Engineering. This customer uses Integrity across their entire development process, and when they were audited recently, the auditor stated in his report "This traceability is the absolute best this auditor has ever seen." In addition to this outcome, the customer has compressed development cycles, improved productivity, mitigated risk, and streamlined regulatory and internal reporting.