Integrity, a PTC Product - Software System Lifecycle Management

Last posting for the MKS BlogSpot:

2011-10-03T11:36:00.024-04:00

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

2011-09-21T16:12:00.000-04:00

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

2011-08-30T13:32:00.003-04:00

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?

2011-08-04T11:08:00.014-04:00

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

2011-07-07T15:33:00.012-04:00

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?

2011-07-05T21:49:00.012-04:00

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

2011-05-12T12:17:00.000-04:00

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.

Real-time Release Readiness across Product Lines

2011-04-25T13:40:00.005-04:00

By Ahmad Fatah, Customer Solutions Engineer, MKS Inc
In collaboration with Kurt Battick, Customer Solutions Engineer, MKS Inc

Do you have visibility into the release readiness of your products at any time in the lifecycle? Although seemingly obvious, the four areas that define product readiness are rarely considered holistically: Quality, Compliance, Functionality and Budget & Schedule. Product Release Readiness is vital - in order to forecast availability to customers, maintain customer confidence, meet tight, predicable product launch windows and provide quicker response time to issues as they arise.

The traditional approaches of milestone based development often lead to non continuous awareness along with the risk of filtered/massaged data. When this happens, the paradigm of component readiness (versus product) tends to creep in. From cradle to grave an SSLM, Software and System Lifecycle Management, based solution allows for full transparency at any point in the lifecycle of product development.

An SSLM solution provides real-time access to dynamically calculated data that allows for visibility into release readiness at any point of the lifecycle, not just at the milestones. The benefits of real time data are two-fold:

Data is collected at the source of work automatically without impeding productivity

Deviations are flagged immediately and corrective action can be taken in real-time

This translates into having access to a dynamic early warning system where full traceability produces objective and non-filtered data. Business logic can be defined based on the specific criteria and process. Individual project components no longer stand alone but can contribute to overall product status. Costs, schedules and quality measures all contribute to Product readiness. By utilizing and calculating metrics against real product deliverables, product metrics can be accessed instantly.

Product design & development today, requires a higher level of collaboration across all engineering disciplines, find out more...

Feel free to comment and let us know what metrics you have in place to determine product release readiness?

There IS an "I" in Team: Integration is the key to success in complex engineering systems

2011-04-21T18:01:00.029-04:00

Software has effectively become the driving force of innovation in engineering and, in particular, provides the foundation of design in mechatronic systems. As these systems increase in complexity, the ability to effectively manage and communicate the business-critical elements of the software development process can broadly and deeply affect the success of the entire organization.

The movement towards model-based development (MBD) brings the software development process to the forefront. In MBD, the system model is developed in the initial conception phase of the product and provides a common link to other development artifacts that are dependent on its design. Model simulations are used to confirm, refine and validate requirements early in the product development lifecycle, when changes are easier to accommodate, and can be reused later in the software lifecycle to develop and verify acceptance criteria just prior to release. Faster design iterations and reduced design costs are realized by using MBD, expanding an organization's innovation capacity.

So why are organizations that have already adopted Model-Based Development processes, still facing significant challenges in the development of their software products?

As the pace of change increases and products continue to grow in complexity, the risks and costs of manual and disconnected processes between development teams can diminish the benefits of modeling and simulation, resulting in:

Inconsistency in mapping the current design to the most current requirements

Costly, error-prone and time-consuming manual communication of requirements change when it impacts models/simulations

Difficult and time-consuming to perform root cause analysis on failed test cases

Costly and time-consuming to demonstrate compliance with regulations and governance demands

Integration is the key to helping multi-disciplinary teams overcome the challenges that are prevalent in complex engineering systems. A system and software lifecycle management (SSLM) solution can capture, manage and control models and simulations as artifacts in a coherent system. The configuration of and change to these artifacts are effectively managed, and the relationships with upstream and downstream artifacts in the development lifecycle (requirements, test cases, specifications, source code etc.) can be established and are traceable.

Successfully integrating MBD with a SSLM solution makes the following activities possible:

Management visibility of progress at critical parts of the development cycle

Compliance validation at selected points in the process

Design verification at a much earlier stage of product development

Test developed system components using rapid prototyping and Hardware-in-the-loop techniques

Automatically generate and manage multiple iterations of code for deployment

Re-use of designs, configurations and parameter sets

Achieving a high level of control and collaboration over software development greatly increases an organization's ability to predict the final result of their activities. The only way to achieve this control and collaboration is through the use of a coherent System and Software Lifecycle Management solution, and fully integrating a Model-Based Development process with these solutions.

Please feel free to comment on whether you are considering adopting model-based development processes, and what challenges you are facing in doing so.

Implementer 10.1 now available

2011-02-18T09:49:00.014-05:00

We are rolling out a new release of our IBM i ALM offering known as Implementer 10.1 this week.

The major theme of this release was to simplify administration of patches and service packs. As such, this release includes an application (we call it Implementer Update) that sits on the desktop and manages the installation of patches and new releases to Implementer. While you can read the standard official published information in our Release Notes, I thought I'd share one insight about the development of this change.

This feature started as a rather simple request to reduce the number of manual steps in applying patches. We could have made a narrow scoped change to meet some of the initial requirements; we instead decided to look at the overall patch and service pack installation process from the ground up. As part of the exercise we looked at installation of other software products, consulted with customers and came up with a wizard-like console that sits on the desktop that allows you to centrally manage all instances of Implementer and the deployment agents, Implementer Receivers. We believe the end result is that Implementer will be significantly easier to administer, particularly for our larger customers with worldwide installations.

This release really highlighted the importance of working with all stakeholders to deliver the best value to the largest set of users possible.

Leveraging Agile in an ALM World

2011-01-31T12:14:00.011-05:00

By John Hennessy, Customer Solutions Director, MKS Inc.

A common perception is that going Agile is the panacea for large project failings. Agile sounds wonderful. It makes perfect sense, right? "Shorter cycles giving rapid feedback and faster time to market", "Constant re-prioritization allowing agility as business priorities change", "Deliver highest value items first, with actual working software" and of course happy smiling programmers. Utopia!

However, as you press for change within the enterprise, the reality of resistance to change sinks in.

The version of 'Scrum but' you hear is, "We would love to do SCRUM, but we don’t have executive support..", "But the timing is wrong..", "But our clients gave us their "approved" requirements documents", "But we need electronic signature support..", "But the processes are validated..", "But we must follow the approved SDLC.." etc.

Where do you start? You can't change everything overnight. Leverage what's working well such as the real-time visibility, traceability, impact analysis and enterprise metrics from ALM (Application Lifecycle Management) and don't try to change everything at once.

Development teams wishing to do SCRUM can easily work within your existing ALM framework by taking the enterprise-level requirements and creating user stories from these, to form product backlogs for the Agile teams, while teams not doing SCRUM can continue with business as usual on their parts of the projects.

Having taken Jeff Sutherland's Certified Scrum Master course, I found his "ScrumBut test" or "Nokia test" very interesting. It became clear to me that Agile teams can score very well in this test working within existing enterprise frameworks without changing everything.

The Nokia Test (Are you doing SCRUM?)

Do you have fixed iterations 4-6 weeks in length?
Have you working software at the end of the iteration?
Have you good user stories tracing to specifications?
Are you testing during your sprint?
Have you a Product Owner who motivates the Team?
Is the Product Owner’s Product backlog prioritized by business value and estimated accurately by the Team based on Planning Poker?
Do you have burndown charts and does the team know its velocity?
Are the teams self organizing and allowed to work without interruption?

By starting with a product backlog of user stories generated from and traced back to the projects requirements, you get the best of both worlds. The enterprise cohesiveness of ALM remains intact and the development teams become more productive with increased agility.

If you want to know how an Agile ALM solution can support an organizational Agile transformation watch this ADTMag.com Supercast. MKS is a recognized leader in Agile for the enterprise; if you’d like to learn more click here to see a video of the Agile Solution Overview.

Please send your comments and let me know your thoughts on working with Agile in an ALM framework.

From Technical Competence to Technical Excellence

2011-01-28T14:20:00.009-05:00

This past Tuesday at the Communitech Agile P2P session, Kevin Tureski from Kevin Tureski Consulting, held a very engaging discussion about his past experience at Alias during their transition to Agile. It is unfortunate that there was no time for questions at the end, but the stories were all riveting.

Prior to its adoption of agile, Alias faced some problems that most of us can recognize with. While their product, Maya (and its predecessor PowerAnimator) was extremely powerful and capable, Alias found they were biting more than they could chew. Consequently, they were "killing" their teams to deliver on the promises made. Maya's functionality was also limited as the cycles to add more capability were simply not available. Then there was the "feature freeze convergence hell"; modules were developed independently and worked very well standalone but collapsed when integrated together. "Big fix death matches" were not infrequent, release dates sometimes slipped and inter-team communication was poor.

The initiative to move to Agile came from the R&D leadership who realized they were in hot water; they knew they were getting things out the door but that their productivity was not sustainable as their workforce was collapsing under the pressure to deliver. There was also the need to improve ability to react to the market and agile practices offered this flexibility.

The move to agile began with professional consulting to analyze the current processes and suggest viable improvement plans. Anyone that had anything to do with the product was trained on Agile. This training took about a year to complete. Kevin Tate, who was then Chief Product Architect at Alias, went on to write "Sustainable Software Development" which discusses the principles that will create software that is maintainable and sustainable. These principles include:

A working product that is shippable in a short period of time
Emphasis on design, not by doing up-front large-scale designs but by a continuous refinement of design through regular feedback
Continuous refinement of the processes in place
Defect prevention by ruthless testing. This includes testing by developers who are required to ensure their code works as expected before handing it off to QA

Alias used standard Agile practices to develop their processes. Some practices, however, were particularly helpful:

Planning poker was not used a lot, but Alias ensured that effort, time and risk estimates were gathered at every level, from Support to Developer to Architect.
Abstractions using user stories was very helpful. Product Owners developed personas that might not have made a huge difference in quality but facilitated understanding and communication between teams.
Iterations were short to avoid feature freeze mess and the iteration length varied by the work done. Alias had major releases roughly once a year. At the beginning of development work, when there was more "heavy-weight lifting", the iterations were longer, about 6 weeks. This duration reduced to 4 weeks when the major pieces were in place and then dropped to about 2 weeks.
Regression suites were run daily. These were critical in identifying and fixing regressions as soon as they were introduced.
There was a dedicated room with physical planning boards for all teams. The board included all information that was needed to give an on-looker an update on the team's status, including a printout for burn-down charts. Camera shots were sent to geographically removed team members and their feedback was included into the status by a local team member.

The stress on testing and low bug count was resonant throughout Kevin's talk, and to put this into perspective he shared a very inspiring story about SketchBookPro which was targeted primarily for tablet pcs. In its adoption of agile, the SketchBookPro team members were co-located such that even sales was situated in the same area as the developers, testers and others who worked on SketchBookPro. The bug pile was never allowed to get larger than what could be fixed within a week, and the team invested heavily in automated testing tools.

At the time version 1.0 was released, tablet pcs were not very popular in the North American market. During the development of version 2.0, the sales force found an opportunity in the Japanese market where 100,000 PCs could be pre-packaged with SketchBookPro. The challenge, however, was that version 1.0 was not internationalized. Version 2.0 was fully internationalized but it was still under development. Since the team's bug count was always low, they were able to stabalize version 2.0 is a very short period of time. They then created a branch off the 2.0 version's development path and turned off all the 2.0 features so that it "looked" like version 1.0 with support for internationalization. The team shipped this version to the Japanese market within 6 weeks!

The low-bug count rule also allowed teams to produce much more stable product alphas which were then used to get user feedback. This feedback was much more helpful at the alpha stage than it would have been at the beta stage when most development work is complete and there is not much room for change.

Alias' complete transformation to Agile took about 5 years, but Kevin reiterated that this time investment was well worth it. When asked if there was ever a time during this transformation when people threw up their hands in frustration over being worse-off than they were before, Kevin said he does not recall such a reaction. The improvement in code quality was backed by increased customer satisfaction and a noticeable drop in level 1 critical bugs. Statistics such as these substantiated the cost of reduced pace in delivering new features, and convinced upper management that the investment in moving towards Agile had put Alias on the move from technical competence to technical excellence.

Requirements Management in an Agile World - Yes it does make sense!

2011-01-27T14:55:00.014-05:00

By Harsh Sabikhi, Certified ScrumMaster, MKS Inc. in collaboration with Doug Akers, Director of Customer Requirements, MKS Inc.

The main benefit of today's Agile development methodologies such as Scrum or XP is the promise of delivering working software in a shorter period of time and the value derived from having the flexibility to adjust which features need to be implemented for the next iteration or release. But does this type of approach allow for requirements management? Or a better question is do we need to manage both requirements and backlog items such as user stories? Or are requirements and user stories analogous? Well -- does the need to deliver what the requirement originally requested go away? Does the desire to control change to the requirement go away? Of course not, and neither does the need for requirements management under these newer methodologies. The nature of RM will change, certainly, but the fundamental principles will not.

In working with enterprise customers across various industries such as aerospace, embedded engineering (high-tech electronics companies) and financial institutions, I find myself wondering whether the term requirements management really means what people think it means. The term 'requirements management' is being used to describe a whole slew of different processes, tools, capabilities that have absolutely nothing to do with managing requirements – which is probably the contributing factor to some believing that RM has no place in an Agile world.

Within an Agile environment, let's take Scrum as an example, you need the ability to define an overall product backlog which houses all outstanding feature requests the Scrum teams will eventually work on. For some organizations, call it a backlog item, user story, or feature request, this is the same artifact that the development team will see and break down into tasks during their sprint/iteration planning meeting. The job of a Product Owner would be to constantly sift through that pool of artifacts to identify candidates for the next release. However, some organizations that are now transitioning into an Agile development methodology typically are coming from a traditional methodology where they had 'formal' requirements management. By 'formal' I mean the requirements documents needed sign-off either from the key stakeholders in the company or their end customer. Let’s take the example of a cell phone manufacturer who gets most of their requirements from their carriers. These requirements typically come in a Word document format containing hundreds of requirements. Requirements management doesn’t go away in this scenario - it is just as important to ensure that the requirement is met, tested, and controlled in terms of change over the shorter development periods that these methodologies represent. What I have noticed is these requirements are sometimes very high-level and there is a need to decompose these into either Epic or User Stories to be placed in the Product Backlog. A RM solution can bring forth the visibility necessary to ensure that requirements are satisfied appropriately, reflect the current needs of the business and are communicated to end customer and key stakeholders.

What the Agile methodologies are also doing is that they are forcing requirements to be decomposed much earlier in the lifecycle such that their scope can be understood and mapped to an Epic or User Story in the backlog to be prioritized. We find ourselves moving away from a system of Business Requirements documents tracing to Technical Requirements documents tracing to System Requirements documents to one where the Business, Technical and System requirements for a given feature or request are fully defined and become the new Requirements Document. Once we have the Requirements Document, the Product Owners can decompose these into more granular User Stories so development can start building the end product. Pure Scrum does not talk about formal Requirements document because it is "too heavy weight". However, there are companies out there that need to communicate progress in term of the requirements originally received and not in terms of backlog items such as user stories. The reason being the same document that came in needs to be sent back showing the status of each requirement. This holds true in the automotive industry as well where the OEM (automotive company) and parts suppliers need to communicate using the standard Requirements Interchange Format(RIF).

Under this environment the Development and Test (QA) teams have greater visibility into the entire request, from the business level through to the system level, and can make design and test decisions armed with that knowledge. Furthermore, requirements traceability becomes about how these requests and the User Stories themselves relate to each other rather than how the high level requirements are decomposed into lower level requirements.

All that said, the requirements within these documents still need to be managed – scope and change to them needs to be controlled and more importantly communicated – and they still need to be linked to the rest of the application development lifecycle - the designs, the test cases and the source code. So in a nutshell, we are talking about Lean development. See Brad Appleton's article exploring the need for traceability and transparency in Agile development in his article - "Lean Traceability" CM Journal, September 2007 (Vol. 6 No. 9) (see http://cmwiki.com/AgileSCMArticles).

Remember, software methodologies need to be applied in a way that matches the strategy of your business. Whether Waterfall, Iterative, Agile or some combination of all of them, you still need to define what your customer wants, even when they change their minds (and they will!). -- You need to know what you are building and how to adapt to those changes. In the end, you need to be able to match the deliverable back to what the customer originally asked for, and this requires a repository and change management for requirements, with traceability over the requirements throughout the lifecycle – sounds like RM to me.

Please feel free to comment on what your thoughts are on RM in an Agile World.

If you would like to learn more on Agile Requirements Management register for this upcoming LIVE Webinar on February 16, 2011 "Agile Journal: Agile Requirements Management - When User Stories Are Not Enough". Our strength in supporting Agile development projects is what drives both analyst recognition and customer adoption of our solutions. One other resource you can check, click here to see the Agile Video.

Agile Programming: Building Applications Your Users Are Sure to Like

2011-01-25T11:24:00.006-05:00

Discover Scrum and learn how to deliver build better, higher-quality applications.
By Marty Acks, Customer Requirements Manager, MKS Inc.

Agile programming has gained significant momentum recently by changing the way in which organizations develop software. When I was first introduced to agile programming a few years ago by a colleague, I politely listened to his enthusiastic description, but it really did not resonate for me. The more I learned, the more fascinated I became. Now, our organization is in the process of moving to Scrum, which is a well-known agile programming methodology.

This article will introduce you to the basic concepts of Scrum development and help you determine if Scrum is right for you. Scrum terminology is probably rather different from what you currently use. Although some of the terminology maps closely to what you may do today, much does not. While Scrum tends to talk about "products" a lot, Scrum is equally appropriate for both IT organizations and ISVs.

Click here to see the full article posted on MC Press Online.

Looking for an Agile ALM Vendor?

2010-12-16T13:44:00.005-05:00

Posted on behalf of Harsh Sabikhi, Certified ScrumMaster, MKS Inc.

The top 3 criteria in picking an Agile ALM vendor are:

Flexible platform that supports various software development methodologies. Agile is key but how well does it incorporate into the rest of the lifecycle? For example, are formal requirements management needed in your organization? If so, you might require a vendor that can allow you to trace from Requirements to User Stories.

Configurable platform that can allow you to change the workflow/process and metadata associated with Agile artifacts such as Sprints/Iterations, User Stories, and Tasks. It is good to see which vendor offers a solution template but for scalability and adaptability of the solution in the enterprise, it is important to know you can modify it to your needs.

Allow you to run traditional and Agile projects in parallel. This is key when you want to collect metrics for executives who need visibility into both Agile and waterfall projects.

If you would like another point of view, Forrester Research, Inc. recently assessed the state of the Agile development management (ADM) tools market, reviewing application lifecycle management (ALM) vendors and Agile project management tools against 152 criteria. Click here for your complimentary copy of this report.

Tell us what you think is important in finding an Agile ALM Vendor?

Designing for everyone

2010-11-21T17:53:00.004-05:00

At the last Communitech usability peer-to-peer meeting, Adam Baker, UI Designer at Google, took us through an interesting exercise. Working in teams of four, we had to design the user interface for an application used to order pizza. Each team was given a constraint to work with. My team's constraint was that our user has an old blackberry and is travelling home from work, on a train.

All my team members had had sufficient time to introduce ourselves to each other, and we did not find it very hard to communicate our ideas, to talk about our design decisions and come to a compromise where needed. Our design met the simplicity criteria and consisted of one screen that asked for input for the telephone number, the delivery address and the delivery time. We considered using one screen per input to accommodate the small screen size, but settled on the one-screen design for ease of readability and navigation.

At the end of the eight minutes allotted for the exercise, we were asked to merge with another team and to re-design to accommodate the second set of constraints. The new constraint we had to deal with was that our user is blind. To adapt to this new constraint, we adopted the merging team’s idea of a voice-enabled application that tried to automatically get all the input from information already stored on the blackberry, and then repeated all this information to ask for a verbal confirmation. Since we were also working with an old blackberry, we designed the application to simply dial the phone number of the pizza store and to let the computer system at the store handle the voice input processing. We also switched to our original design consideration of one screen per input to simplify voice processing.

Our merge flustered us a little bit initially, but we thought the new constraint did not change the user interface design enough to cause us much concern. However, we were asked to merge yet again. This time, we moved from eight team members to sixteen, and we took on two more constraints; the first was that we were dealing with a first-time online user, and the second constraint was that the user had only two minutes to order the pizza.

The last merge was more challenging, particularly because the team size was too large to be able to gather and ponder over every person’s input, and because we had the least amount of time to make design changes. We were faced with numerous questions; are we mandated to use an online application, instead of an installed application? How will a voice-enabled system be able to verify all the input within two minutes? If the application is dependent on a phone connection, and the user is travelling on a train, what will happen if the train goes through a tunnel and the connection is lost? Our blind user will be caught unawares in this situation. How will the application recover from this and will the user have to start all over?

We did not have enough time to answer these questions in a satisfactory manner. There were, however, many lessons to learn.

The exercise tries to simulate what it is like to design for an extremely large audience, all with different constraints.
The larger the design team, the harder it is to come up with a simple solution.
Different design teams bring different perspectives into the design process.
One solution is not necessarily correct.
The more constraints there are, the more complex the interface becomes, and it risks becoming inconsistent.*

Here are some general guidelines and retrospectives that Adam shared with us:

Understanding your users requires creativity. You have to be able to differentiate between different users and recognise common patterns in order to group your users. Instrumentation and A/B Testing are two techniques commonly used to recognise usage patterns. We can measure by answering questions such as how long, how many, how often and when.
Designing Google’s Search UI was like designing for the back-country, where everything must be light-weight, multi-purpose, fast and adaptable.
Little things matter. Simply changing the shade of a line colour can make a large difference in the user’s satisfaction.
Intent is ambiguous. What does it mean when a user types in “TV” into the search UI? Does the user want to know the difference between a plasma and an LCD TV, or does the user just want to know what’s on TV? Keeping in mind sensitive issues, what results do you display when someone types in “Where do babies come from?”?
The design of Google’s search UI was all about co-operation between people from various disciplines.
The aim is for speed and simplicity of design. While most people do not search all day, many people search something every day, so speed is crucial. Similarly, a simple UI should highlight the obvious, and then provide details that users can delve into if they want.
The design commonly reflects trade-offs between speed and elegance.

* The combinations of constraints other teams dealt with were:

The user is a nine-year old with an I-Pad, and is ‘just like us’.
The user has both an I-Pad and an old blackberry, has two minutes to order the pizza, and cannot type.
The user is a nine-year old, is blind and illiterate and wants to order hundred pizzas for hundred separate locations.

What drives the need for Safer Systems Development Processes with ISO 26262

2010-11-09T11:34:00.005-05:00

Posted on behalf of Christoph Bräuchle,
Customer Requirements Manager, MKS Inc.

As ISO 26262, the new standard for functional safety in road vehicles, comes closer to the final publication stage (the final draft international standard will be released in December), automotive manufacturers and suppliers must prepare to meet these requirements in development processes, work products and documentation. MKS supports automotive engineering organizations to be compliant while maintaining efficiency and productivity.

Process management and full support for most parts of ISO/DIS 26262
MKS provides extended support for hazard analysis and risk assessment and provides rich functionality for creating functional safety concepts (ISO/DIS 26262 part 3). Through all phases in product development (part 4-6) MKS manages processes, activities and work products. Full traceability between the work products from Requirements to Test assets on system, hardware or software level is one of the core strengths of MKS Integrity. Most of the supporting processes, such as Change and Configuration Management across all domains and development phases can be managed in MKS Integrity.

Safety Manual and reference process
Alongside with the FDIS of the standard MKS will release a safety manual for MKS Integrity providing guidance how to apply best practices and processes for functional safety management to existing processes managed in MKS Integrity. A reference process implementation will give a starting point for organizations that want to quickly adapt MKS Integrity for functional safety development and management.

Close cooperation with certification bodies
MKS cooperates with certification bodies with a long history and experience in functional safety management to relieve its customers from the burden of tool qualification according to ISO 26262 and ensure safe production use even in development projects with high ASIL levels.

To Learn more, register for the on-demand webinar on "ISO 26262 and its Impact on Engineering: Eliminating Risks Based on Mal-Functional Behavior of Embedded Systems" – Featuring Juergen Belz, CEO, PROMETO and Christoph Braeuchle, Customer Requirements Manager, MKS Solutions for Automotive, MKS

Metrics Matter – Real-time 360 Degree Visibility Improves Project Outcomes

2010-11-09T11:34:00.001-05:00

Posted on behalf of Doug Akers,
Director, Product Management, MKS Inc.

It has been some time since we last took a deep look at metrics and how to measure the various aspects of development. At the time when I wrote "Metrics Matter" the market was very much centered around IT organizations and doing more with less and so the types of numbers being prescribed aligned with cost savings and maximizing productivity as would be expected. We grouped the metrics that were of most interest to CIO's into five categories – team efficiency (productivity), process efficiency (predictability), project efficiency (cost/schedule), value and effectiveness (alignment) and quality (uh quality) and today, for the most part, these categories still hold true (although we call them by new names).

Since then though a number of things happened to the market that cause us to take a different approach to what we focus on, the value of or at least the priority of metrics and measurements that inform our decision making processes.

First of all, software has busted out of IT in a huge way. In the last 5 years the amount of software in complex products like automobiles, airplanes, operating theaters and mobile phones for example has grown exponentially. What's more in these highly competitive industries software is THE differentiator and THE source of greatest innovation for the manufacturers. The numbers informing IT are vastly different than the numbers driving product organizations. Don't get me wrong, cost and productivity are important to these companies, but quality and cycle time – whether its defect fix cycle, change review cycle or product release cycle – are critical in these highly competitive markets. The value of reuse statistics, change propagation metrics, test coverage and risk mitigation numbers is what gets organizations ahead of the curve (or the auditor as the case may be).

Second there's the ground swell of Agile and other development methodologies intermixing with more traditional ways and means of delivering applications. Velocity, rework percentage, or running tested features are all examples of the types of project or business level metrics that are born out of the Agile era that most organizations hadn’t even heard of 5 years ago.

Third, the cost of failure has grown as competition expands, pace increases and innovation comes from unexpected areas. You may argue this one but from my observations of the customers and businesses I've been in touch with – never before has hitting a market window been so critical to the continued success of an organization. Where you were producing one device or product annually, now its 5 – oh and there is 50 variants of each of those across geographies, OEM's, carriers, or some other orthogonal dimension. But you still need to hit the 3 week window before the holidays.

Finally, we've just gotten better at this. We understand more about process, the right process and right amount of process. We know more about what metrics are useful and which are not (hello Kloc, I'm talking to you). And we know that that measurement is essential to continuous improvement – the question is not if we use metrics to inform our business but rather which measures will provide the most value.

There is definitely lots to think about for sure and there are a ton of resources out there (just google "Agile metrics" for example) to inform our thinking. But every once in a while it's a good idea to look back at something like "Metrics Matter" just to ensure that the core principles still hold true. Personally, I am glad they do – simple frameworks are often best and will stand the test of time.

Visit our website to learn more on MKS Integrity or sign up today for our Webinar on "Metrics that Matter to the Engineering Organization"

What I Learned at the AGILE 2010 Conference

2010-08-31T10:22:00.020-04:00

Posted on behalf of Harsh Sabikhi,
Customer Solutions Engineer, MKS Inc.

Day 3 - Thursday, August 12th

Today I concentrated on learning more about Kanban, Scrum, and how it scales to large organizations. I truly believe Kanban is the next "buzz" or "flavor" in the developer community. I have been thinking of how to extend our current Agile solution to support Kanban. From a metrics standpoint, we can easily add support.

I also attended a session on managing your requirements separate from your user stories. I got a few ideas that I will prototype. The authors were suggesting a maturity model for requirements and only those that are fully scoped should turn into backlog items.

Day 2 - Wednesday, August 11th

General Observation
Most of the people here including the purist are very anti-tooling for some things. They look at tools as a nice to have. The interaction of a whiteboard leads to team collaboration hence better Agile teams. This is why Rally's of the world provide interactive storyboards. But some purists still think this is "fluff".

Hansoft
I had a conversation the Marketing Manager at Hansoft. They have a product very similar to ours which is a platform rather than a solution. Hansoft's value proposition is similar to ours as well: they can manage both Agile, Waterfall, lean, and Kanban projects. What they lack is a version control, and full RM capabilities. They integrate with CVS, perforce, and Subversion.

Collabnet
I met with a Corporate Account Manager based in Atlanta. They recently went to a SaaS model for trials and small customers only. I have briefly talked about this internally but we should seriously look at this and come up with a strategy. I think majority of the Agile vendors have a free trial/eval and we should consider this.

AppFolio Inc. - based in Santa Barbara, CA.
Met with the Scrum Master at AppFolio. They have a team of 20 developers. They are primarily using Excel.

Sessions for today:
Lean and Agile - This was a panel discussion about how to use Lean principles within Agile. The experts all agreed and said Agile is a subset of Lean. What was great and something we should look at developing are "Lean" type metrics. For example, Cycle Time - how long does it take to deliver a feature and not just a User Story in a time-boxed iteration? Management can see and track at the feature level and commit to their end customers on a timeline. Along the metrics conversation, testing was mentioned again.

Managing your product backlog
This session was okay. They just talked about visualizing your backlog and using charts such as priority (x-axis) and cost (y-axis) both measured in story points. The key here was that there are different patterns of shifting priorities.

Portfolio Management
In this session they talked about different allocations of products (New, Now, and Platform) and how we should use different techniques for each. New should use Agile, Now should use Lean and Platform should use Kanban. In addition, sustaining projects should use Lean because you want to deliver slight more value but also manage risk and resources.

Agile Program Management
This session was not what I expected. We did a simulation and created a basket and flowers! The goal was to show multiple project teams working from different backlogs towards a single Program initiative.

Day 1 - Tuesday, August 10th

Meetings for today:
I met with the Offshore Principle from Thoughtworks during my last session of the day. We exchanged business cards and I gave him some collateral on our solution. Thoughtworks is an IT consulting organization.

At the end of the day, I also met with an Analyst from VDC Research. I gave him an overview of Integrity and our platform. Also told him the competitive advantages of our Agile solution and gave him a brief demo. VDC would like MKS to sponsor their "Software & System Lifecycle Management Tools" research.

9 AM - Agile 2010 Keynote session with Dave Thomas

There was a lot of talk around Test Driven Development and Continuous Integration. In general, he was anti-tooling. I have been thinking about this for a while as well and would like to understand where we stand with this especially CI. It will be beneficial for us in the field to have great examples of an integration with Hudson for example.

Dave talked about Sprint 0 which is a learning sprint for a new Agile team. RBC called this out in their process framework document as well.

Learned teams should plan at only 80% of their capacity during Sprint Planning

Learned Lean is a top down process whereas, Agile is a bottom up.

Cumulative Flow Diagrams are being used by a lot of end customers now because this gives them a full end-to-end trend analysis on all system artifacts (Time spent on User Stories, remaining effort on tasks, defects, etc). They typically do this by exporting to Excel. I don't think we can do this in Integrity anytime soon so I have an idea for this. Basically utilize our Export to Excel.

Learned an interesting concept that feature backlog is measured in business values whereas, a component backlog is measured in feature values.

11:00 AM - Upstream Kanban session

Kanban is quantitative workflow management. It is about mapping the "value stream". It is similar to Agile but encompasses high-level managers in the organization to work in a single team.

Kanban uses an interactive story/task board just like scrum with a few changes. Each stage has a "Work In Progress" limit. Kanban limits the amount of work that can be pulled in from upstream marketing organizations to development because it uses a "pull" method.

Advantage is this interactive board is visible to marketing which has a downstream view on the activities R&D is working on and vice versa.

Advantage of Kanban is also executives get a report that shows how many calendar days a feature will take from SLA t o Production.

1:30 PM - Lean Pyramid

Lean principles - deliver a continuous flow of value to the end customer. Create a learning organization and a continuous improving organization.

Lean is about communicating the "vision" from the key stakeholders in the form of requirements or Epics down to User Stories in R&D.

Learned an interesting concept of categorizing user stories in a "Canoe Analysis".

Talked about WIP again and got me thinking how we can do this in Integrity.

A "Cleaner" role might be needed for cross-team collaboration. The "Cleaners" role is just to re-factor component code.

TDD was mentioned again and so were CFD.

3:30 PM - Agile in distributed environment

This was more of a hands-on technical session. Not what I was expecting.

We spent an hour talking about "Development practices" such as XP, TDD, FDD and how they scale to distributed teams. What the challenges are and how to overcome them.

We also learned the difference between Distributed Teams and Dispersed teams.

Plan for the rest of the week will be for me to concentrate on "Business" tracks. This is the first time I have attended, so I am learning to focus on each track. I think the business track will help me with the industry trends and how other organizations are doing things. This can then help us shape our product for the future.

Visit MKS to see our solution for the Agile environment.

The Cost of Compliance

2010-08-23T16:27:00.015-04:00

It seems that every industry today is plagued with a growing mound of compliance related red tape. According to Jorge Lopez of Gartner Research, "Over the last few years...budgets that were dedicated to dealing with regulations were rising at a rate that was twice as fast as the IT budgets." This coupled with economic pressures to do more with less people is quite overwhelming to many organizations. For this article we will focus on the automotive industry and the medical device industry, but similar challenges exist in many other industries. Specifically, we will look at the challenges they face and how automation plays a significant role in enabling organizations to overcome these obstacles.

Compliance in the Automotive Industry
You need not know much about the automotive industry to know that the economy has taken a severe toll on most if not all global automotive manufacturers. In addition, there have been several high profile safety recalls in recent years as well that have impacted all manufacturers. Many in the industry suggest that the complexity of the modern automobile has much to do with the inability of most manufacturers to control quality and safety to the highest levels. In fact, the next generation S-Class Mercedes is reported to have in excess of 100 Million lines of software code embedded in the various systems that control almost every aspect of the vehicle. This is astounding considering most cars were just topping a million lines of code just a few years ago.

The result of these challenges and recognized complexity is the introduction of much more stringent functional safety requirements in the new ISO 26262 regulations that move into full force in 2011. These types of compliance standards are not really new as ISO 26262 is derived from the IEC 61508 which is related to FAA DO-178b and other standards, but nonetheless complying with these standards is no trivial matter and will undoubted cost the automotive industry $100s of millions if not into the billions of dollars.

In preparation, most auto OEMs and suppliers are looking to technology partners such as MKS to supply them with solutions that are more cost and time effective in proving compliance. These systems must include the following capabilities, just to name a few:

Manage all engineering assets from requirements and design at the front end to final validation and verification test procedures and results with many other assets in between.

Manage end to end traceability of these assets such that they can show that each and every requirement has been validated as well as traceability from requirements down into the code.

Manage all identified risks and clearly show mitigation of these risks by the appropriate requirements using some system such as FMEA.

Manage all relevant metadata such as Calibration Data as part of the solution.

Ensure strict change management procedures are adhered to across all lifecycle assets

Automate and enforce compliance requirements for model driven development (MDD) providing trace through model support.

The solution should be certified by TUV or some similar compliance certification organization to ensure compliance of the solution.

Current tools in place for most automotive companies are just not adequate to handle these requirements as most have complex networks of disparate tools and repositories with brittle integrations that cannot provide the end to end traceability, visibility, and reporting required to show compliance. If they could make current systems work, the solutions would be both cost and time prohibitive.

Compliance in the Medical Device Industry
Although not as conspicuous, the medical device industry is under very similar constraints and challenges with tough FDA and EU regulations. Recalls and regulatory compliance pressure for medical devices, especially for Class 1 and 2 device manufacturers, can be extremely costly and time consuming. One recent company we worked with cited 6 weeks of effort for a team of resources had to be tacked on to the end of the development process exclusively for preparing documentation, reports, and trace information to ensure compliance for an FDA 510K submission.

According to one source, the FDA has doubled and maybe tripled the number of inspectors just during the Obama administration. These medical device companies are feeling the pain of compliance using the manual and disparate systems most currently have in place. The costs for manually managing compliance is well in to the millions of dollars annually for many, but the threat of non-compliance or safety related recalls using these error prone systems is actually much greater. This is forcing many into searching for a more automated and comprehensive solution.

An automated platform that would ensure cost effective compliance with these rigorous requirements would need to employ an analogous set of capabilities including:

Rigorous management of requirements, specs, design, risks, test protocols, etc. across hardware and software.

Comprehensive traceability across all related engineering assets

Automated production of EU and FDA specific reports including the Design History File (DHF)

A solution that has undergone a computer systems validation (CSV) ensuring 21 CFR Part 11 compliance.

The MKS Integrity Platform
Many automotive and medical device companies rely on the MKS Integrity platform for helping them ensure compliance. The Integrity platform was architected to manage the diverse set of related engineering assets that span the lifecycle. Integrity has received numerous accolades as having best in class functionality in various disciplines including requirements management, software change and configuration management.

The key lies in the ability for Integrity to provide full configuration and change management for all assets in a highly scalable and flexible single platform. Automated work-flow provides hyper productivity while ensuring compliance with industry and company specific standards. Out of the box solution templates for many industries ensure rapid deployment and near instant time to value.

The Conclusion
Compliance does not have to be nearly as costly as it currently is for most organizations. With the right solution in place organizations can drastically reduce the time and cost of compliance while improving overall product quality and safety. Please contact MKS for more information about our solutions.

Implementer 2010 is Here

2010-07-30T19:45:00.026-04:00

MKS just released Implementer 2010 today, which features over 100 separate improvements. Implementer is an integral part of our MKS Integrity offering that focuses on the change control and ALM needs of the IBM i community. Our development team and many others worked very hard on the project to meet both quality and schedule commitments. Kudos are in order for all.

As a product manager here at MKS my sense of timing could come into question on this release. I planned (or perhaps did not plan) this release to coincide with the last day of our fiscal quarter (a hectic time for some), before a holiday weekend in Canada (where corporate HQ is), and right before I go away for a "staycation" in downtown Chicago next week. No big deal... I had great confidence in the team to deliver the release on time. Our development team may have other words for this. In the end, the release rolled out very smoothly. I spent the last couple days crossing t's and dotting i's and getting in the way. One change to our roll-out plan this time around was the addition of an "update social media" activity. So here I am blogging away on a Friday night, now that the release is on the shelf.

Here are some of the nuts and bolts of the release. First and foremost, the features in this release were driven by listening to our customers and working closely with IBM on the latest release of the IBM i operating system. This new release is chock full of support for and utilization of new IBM i 7.1 capabilities like data encryption (SQL field procedures), solid state devices (SSDs), new SQL XML data type, and SQL Alter Table changes. On the integrations front, support is included for LANSA 12 and IBM Rational Developer for Power Systems 7.6 (and 7.5). Numerous improvements in our CA 2E support have also been made. Host-based developers will also notice improvements when checking out, compiling, promoting, rejecting locks, and working with projects. Expanded support for SQL will help those modernizing their applications and development practices. And for our Japanese customers, the RD for Power integration (including RDi and WDSC) has been translated into Japanese and now supports DBCS development. CCSID 1399 is also supported. There is more, but that hits most of the high points.

Over the last couple of years I had requested via the Common User Group and in passing conversations with IBM DB2 gurus Kent Milligan and Mike Cain to change SQL Alter Table to support inserting columns somewhere besides the end of the table.... So not long ago I had a thought. SQL Tables should be able to be altered and retain the column order of another table. I told IBM. Now look at IBM i 7.1. I told them what to do and they did it. I'm Marty Acks. I'm a Power System and IBM i 7.1 was my idea.. When I start channeling Microsoft commercials something is wrong in the world.

Registered customers can find out more about Implementer 2010 at the MKS Customer Community at www.mks.com/community. Others can check us out at www.mks.com or feel free to contact me directly at macks@mks.com.

IBM i local user groups go to back to school

2010-07-26T12:12:00.000-04:00

I recently returned from the a day-long conference hosted by the Ocean User Group of Southern California. As is the case at most of the volunteer driven events, it was well run by a core group of dedicated volunteers. Ocean and other local user groups are always looking for a few extra volunteers. The user groups I have seen thrive have a good mix of new and old blood. Give your local user group a call or e-mail to see how you can help.

While the primary business purpose for my attendance, I suppose, is to find new customers, as a product manager at MKS I find these events to be a great chance to get in front of people in the Power Systems and IBM i community and see what they are really doing with the platform. We are continuing our participation in these conferences this fall and into next year. I'd encourage you to get out one to one of these when it comes to your area. They all offer something a different. Check out their agendas and speakers in detail before you choose the one that is right for you. These conferences are a great opportunity to improve job skills and find out what other companies are doing. If you have never been to one of these, now might just be the time to start. To see a list of conferences MKS will be at, see our conference calendar at http://www.mks.com/resources/mksevents/tradeshows. By the way, there are also a few non-IBM i shows here also.

One trend that I have noticed with conferences run by local user groups is the move from hotels to university campus settings this year. The recent Ocean conference was held at National University in Costa Mesa, California. Recent Detroit-area Mitec conference run by Southeast Michigan iSeries User Group and the Toronto User Group for Power Conference were also held in university settings. In talking to the organizers, this allows these groups to significant lower their conference fees. For example, one hotel was charging up to $3.50 for soft drink with a 35% surcharge on top of that alone, when you adding up the food and other incidentals the costs can be rather significant. And you thought room service was expensive. Plus there was a nice sense of bonding as some of us stayed around at the end of the day and helped clean up.

Recognized as A Core Vendor of ALM

2010-07-11T14:35:00.000-04:00

In a recent article published by ITKnowledgeExchange MKS was recognized as a leader in ALM:

According to Theresa Lanowitz, founder of IT analyst firm voke inc., the core vendors in the Application Lifecycle Management market are HP, IBM, Microsoft and MKS. That’s not to say there aren’t other vendors that are making strides in ALM. “I see two other types of vendors emerging: vendors with a unique take on the application lifecycle approach and vendors who are delivering tremendous innovation in the application lifecycle with unique product offerings for the dynamic environment that is ALM,” Lanowitz said. Her firm’s research on the ALM marketplace and its players can be found on the voke site’s Lifecycle Transformation page.

Click here for complete article by IT Knowledge Exchange

An Overview of Application Lifecycle Management

2010-03-24T15:59:00.001-04:00

ALM Boundaries are Expanding in Application Development

2010-02-18T10:25:00.000-05:00

While the pool of application lifecycle management (ALM) vendors tends to be dominated by four big swimmers -- IBM, HP, MKS and Microsoft -- it's a crowded space, with many players offering pieces of the solution. But the next wave is making the pool itself deeper, as the definition of "lifecycle" broadens, encompassing not only the development/test lifecycle, but requirements and architecture, portfolio management and operations.

"People are beginning to see a broader lifecycle of the application," said Mark Sarbiewski, senior director of products and solutions marketing, HP Software & Solutions. "For a while everyone focused on the SDLC [software development lifecycle], then you go live and it's somebody else's problem." ALM, he said, "needs to happen upstream through the full life of the application and ultimately until you retire it."

Agile development is also broadening the definition of ALM, he said. "When you change the way you deliver, when you change how often software is delivered, how frequently you touch the application, and who's involved in the business -- those are some of big points—clearly that touches automation. So how do you automate not just testing but deployment, monitoring and change in production?"

Click here for complete article by SearchSoftwareQuality
by Colleen Frye of SearchSoftwareQuality