Managing product and application lifecycles

BY STEFANO RIZZO
Senior Vice President, Strategy &
Business Development
Polarion Software, www.polarion.com  

Ever stopped to think what it takes to get a premium car out of the driveway? The sheer volume and complexity of the software that is behind a car like the BMW i3, with its sophisticated navigation and support systems, and many other consumer products, is rising exponentially every day. Manufacturers are no longer simply responsible for the electronics design; they now must develop additional processes and procedures for the development of complex, embedded software systems.

Fig. 1: The BMW i3.

As the quality and performance of this software can mean life or death for the user, the software process is rigorously controlled and regulated. Failure to meet strict quality assurance standards can result in hefty penalties and even the shutdown of a company.

Over the last several years, automobile manufacturers have recalled millions of vehicles as a result of software errors, and recent studies by the Center for Automotive Embedded Systems Security (CAESS) have shown that it is possible to expose a vehicle to malware and cause it to crash — literally.

This increasingly dominant and potentially volatile presence of software adds a new dimension of complexity within the product engineering and manufacturing process.

How do you manage this complexity?

On the surface, the methods for managing a product's lifecycle via product lifecycle management (PLM) and the lifecycle of a software application via application lifecycle management (ALM) seem to be quite similar. Both PLM and ALM systems are built around an integrated process and set of core disciplines. But the similarities end there.

CIOs and IT managers with a significant investment in a PLM system have tried to use such a platform to manage production as well as the software behind it. A PLM system can manage product-related workflows, specifications, designs, and versions — so why not software as well?

Figure 2: Application lifecycle management.

Relying on a PLM system to help you manage the complexity of the software development process — including iterative development cycles, changing requirements, traceability of items, and relationships between items – pushes this system well beyond the boundaries of its design. Software development process management is a job better suited to ALM (Figure 2), a software-centric discipline specifically oriented around interdependent processes including requirements management, test management, change management, configuration management, task management, release management and build management.

Where is the disconnect?

Today, most ALM and PLM systems operate in parallel universes. An obvious difference between ALM and PLM is that a PLM system is oriented around “parts” that are manufactured to create a physical product while an ALM system is oriented around the management of software files (a requirements document, a piece of code, or a test case) and changes to those files as they occur.

The ALM discipline has traditionally resided within the software development organization. However, in recent years ALM data has become valuable to an increasingly wide number of stakeholders. ALM coverage is extending to new disciplines beyond software development. And, with a greater number of stakeholders comes an increased need for collaboration and easy access to data. Yet, web-based collaboration among team members is one of the most significant hurdles facing traditional PLM system software, which, unlike ALM software, usually offers limited collaboration because many of the systems used by companies today are still not web-centric.

For example, a user in China cannot display a 3D rendering and BOM with traceability links to the software installed into a vehicle's transmission with data stored in a server located in Stuttgart. This kind of capability is years away – unless the manufacturer has done the work of integrating both of his ALM and PLM solutions.

A second area where PLM and ALM differ lies in the way the systems define traceability. In a PLM system, traceability is defined as the “part of” decomposition of a complete system. A car is composed of a frame, an axle, four tires and more. In an ALM system, traceability is defined as the links between files/items belonging to different phases. A change to a requirement may impact a line of code, or require a new test case to be developed to validate the new requirement.

A PLM system will relate and link information to items such as formulas and tolerances. An ALM system will relate and link information related to code such as requirements, change requests, test cases and commit comments. So, how does a manufacturer best manage the growing amount of software that now exists as a component within a part within a product? That's a problem best solved by integrating your PLM and ALM systems.

A common process layer to drive change

ALM technology has evolved over the last number of years to offer an integrated, process-centric solution that enables the traceability and management of items across different development phases. In such evolved platforms, ALM items exist with no replicas, have a version number, are linked to each other, and guarantee consistency over time and changes. Such features allow a better separation of duties between developers and significantly increase their accountability. Modern ALM platforms also simplify compliance activities, which can provide a huge benefit to manufacturers who are inundated daily with an ever increasing number of new standards.

Fig. 3: The relationship among ALM, PLM, and PALM.

In systems engineering today, there is an ongoing debate about the need for mature and coherent processes. On the other hand, defining more and more formal process templates tends to lead to the opposite consequence – whereby engineers feel the pressure to ensure compliance at the expense of innovation. The good news is advanced ALM technology offers the best of both worlds. By embedding process knowledge in the toolset, these systems allow engineers to concentrate on their core competencies, while the tool drives them through the process. This is why a common process layer can be the solution to many of the issues facing engineers today when it comes to managing ALM and PLM – two systems that often require very disparate and unique management processes.

This process layer forms an ideal “backbone” or common integration layer between PLM and ALM systems, providing item uniqueness, workflow management, versioning, traceability and change management to any product and software related information. A connection does exist between lean manufacturing for product development and agile methodologies for software development. “Lean” and “agile” will come together in a complementary way — but only thanks to the process integration layer in this scenario.

 Steps to integration

Some basic yet important steps for achieving integrated product and application lifecycle management (PALM) are:

1. Creating an open common integration layer (used as a PALM backbone) between PLM and ALM systems.
2. Unifying process support, collaboration, requirements management, and test management disciplines to simultaneously cover software and hardware.
3. Introducing a broader definition of traceability in PLM to show the broad impact of change within the system as a whole.
4. Establishing a new, unified PALM platform to govern and manage the delivery of software intensive products.

Manufacturers of innovative technologies, like the self driving car, will have to leverage tight integration of ALM and PLM. The use of embedded systems will continue to expand and the need to manage software and product lifecycles in an integrated way will become more vital than ever.

A number of companies are providing PLM and ALM software. Polarion Software has Polarion ALM available, which is Web-based and lets you manage all phases of the application lifecycle with full traceability from initial requirements to source code to production. Other offerings from the company include Polarion Requirements for online requirements management and Polarion QA, a Web-based collaborative test management platform for Quality Assurance Managers. See www.polarion.com.