While becoming more and more complex, product development lifecycles are increasingly managed in an integrated manner. Hardware engineering, software development, and service innovation are approached with an emphasis on their contribution to a single end product. In the era of IoT, this gives way to an integrated view of an overarching product lifecycle.
The integrated approach transcends company limits and is increasingly extended to suppliers, giving rise to the practice of white-box development. Read on to find out more about how white-box development is expected to shape manufacturer-supplier relations in the future.
Integrating Suppliers in NPD
In the case of sophisticated products, increasing software content and fast-paced tech innovation forces product developers to involve suppliers in their processes tighter than ever. This is most apparent in the automotive sector, where the role of suppliers in new product development (NPD) has always been strong and is growing exponentially, but the process can also be seen in other industry verticals.
The effort to tightly integrate lifecycles, as well as all the stakeholders involved, is made a necessity by an ever-increasing focus on product quality, standards compliance, and collaboration (think Agile, DevOps) in product development.
In safety-critical industries, regulations require developers to thoroughly ensure the quality of their products, forcing them to vet the development processes used by their suppliers. White-box development is gaining traction to enable manufacturers the required level of transparency on lifecycle processes.
What is white-box development?
White-box development takes its name from a form of software testing. There, “white-box” refers to a granular and comprehensive method of testing where the tester validates a software product’s internal framework, components, and processes rather than just looking at whether the software works as expected.
Also known as glass-box testing, structural testing, or code-based testing, white-box testing essentially takes a look “under the hood” of a piece of software, aiming to verify all the possible ways the software could operate. It is fundamentally different to black-box testing, where only the typical GUI paths that a user would take are tested to see if the outputs are correct. During black-box testing, the tester simply looks at whether the software works as expected, without analyzing how exactly it operates.
So how does this white-box or glass-box concept apply to product development? Essentially, it means that a manufacturer demands complete transparency throughout the development of a component by a supplier.
It is very different to the traditional way suppliers are contracted. In black-box development, the buyer will only specify a set of requirements and let the supplier proceed on its own to deliver a part that fits those specifications. They will then simply integrate that product component in their own product. In white-box development, however, the manufacturer will want to be involved every step of the way, integrating the supplier very tightly into the process of product development. The buyer will want to be able to trace test cases to requirements through a documented trail of artifacts, as if the component was developed in-house.
Providing this level of transparency across company boundaries could be a problem for suppliers – not only from a process point of view, but also from a technical standpoint. Simply put, tool friction between the manufacturer and supplier’s development environment could inhibit transparency.
Advantages & Challenges of White-box Development
To overcome these technical challenges of supplier integration, the tools used by both buyer and supplier need to be integrated. Development maturity mandates that they are both using a holistically integrated platform such as codeBeamer ALM to manage their development lifecycles. (Integrating and maintaining the interfaces of several single-point tools across company boundaries is far from being rational or even feasible).
With both parties using codeBeamer ALM, taking supplier integration to the next level is smooth and efficient. Using its ReqIF roundtrip feature, you can easily exchange granular lifecycle data between two instances of codeBeamer ALM.
To simplify white-box development, codeBeamer lets you simply export a ReqIF file containing artifacts with all their relations. Upon importing the file, you can flexibly configure field mapping and import options, and save these configurations for later. Migrating any and all changes back to the original project takes just a few clicks. Reuse the import configuration, and you’ll see all changes reflected in the original project.
With the ReqIF roundtrip feature, codeBeamer ALM greatly facilitates transparent supplier integration. Implementing white-box development is smooth, effortless, and lets manufacturers and suppliers work together efficiently.