1.4 PDM and SCM

---

Different people with different roles are engaged in the development or use of a product. These people are often interested in certain data about the product that are important for a specific phase or particular process in which they are involved. Examples of such data are requirement documents created during the early phases of the product development but also used during test phases to verify the product’s function and to validate the product. Common to all data, irrespective of the phase in which it is created, is that it belongs to the product. More precisely specified, it should be related to the product, or, even better, to the correct part of the product. And vice versa—for a given product, it should be possible to find all data relevant to it.

The domain managing such product data during the product’s entire life cycle is called PDM. PDM is an engineering discipline that includes different methods, standards, and tools. First, it manages data related to products: structures of the products, including lists of their components, and product configurations that identify all artifacts (components and documents versions) belonging to a particular product version. Second, it supports procedures during the PLC (e.g., peoples’ roles in the processes, including their authorities and assigned activities, change management, workflow management, and even project management). PDM also deals with the development and production infrastructure, which means that it provides information for all activities. This means, for example, that PDM does not include design methods, but makes possible the availability of all information needed for a successful design process. Traditionally, PDM deals with hardware products, while it usually has not been used in development of software products.

As previously mentioned, the software development phase is frequently characterized by collaboration and coordination of many developers. To cope with this type of complexity a domain called SCM was established. The scope of SCM is to keep track of all of the files and modules constituting the product and—especially—all of the changes made to these items during their entire lives. It also takes care of all documentation related to the product.

As the alert reader now understands, PDM and SCM must have many requirements and much functionality in common. Also, even though these areas have a different history, they are both growing and increasingly incorporate more and more of the total need for managing product data, resulting in a significant overlap. This overlap is now so extensive that some people advocate that they need only one of them, their choice being determined by whether software or hardware is being developed. Our experience, however, is that there are still differences originating from the nature of the artifacts and differences in the processes. Hardware products are visible as their components. The product structure defined at design time corresponds to its physical structure. Software products are not visible in the same way as hardware products. They are embedded in specific (special purpose computers) or in standard hardware (common desktop computers). The structure of software systems during design is often very different from the structure of the system during its execution. Because the production phase of hardware products is extremely important and demanding, the focus of PDM on the production phase is very high. For software products, the production is much simpler than the development phase. The implementation process for software systems is extremely dynamic; that is why SCM focuses mostly on the implementation phase.

As long as the hardware and software development processes are isolated from each other, we can accept that PDM and SCM, although similar in principle, are different in implementation. We use one or the other tool depending on the development and production process we have. The real problem begins when we produce products that consist of both hardware and software. The first thing we would consider is the question of whether we can reduce costs by using one tool instead of two. The second question would be how we can achieve an integrated support during the entire PLC independently of whether we develop software or hardware parts. This is what this book is about! In the rest of this book, we will give a more detailed description of PDM and SCM and their respective goals and functionality. We will compare them function by function, and we will compare the use of their respective tools. After this analysis, we will arrive at a conclusion, whether we need support from both domains or we can manage with one of them, and certainly explain why. Studies of several cases will illustrate use of PDM and SCM in practice. Where both PDM and SCM are used, we will discuss the possible solutions to their integration.

---